Re: [PATCH 1/7] sched/core: uclamp: add CPU clamp groups accounting

[Patrick Bellasi]

On 13-Apr 11:46, Peter Zijlstra wrote:
> On Mon, Apr 09, 2018 at 05:56:09PM +0100, Patrick Bellasi wrote:
> > +static inline void uclamp_cpu_get(struct task_struct *p, int cpu, int 
> > clamp_id)
> > +{
> > +   struct uclamp_cpu *uc_cpu = &cpu_rq(cpu)->uclamp[clamp_id];
> > +   int clamp_value;
> > +   int group_id;
> > +
> > +   /* Get task's specific clamp value */
> > +   clamp_value = p->uclamp[clamp_id].value;
> > +   group_id = p->uclamp[clamp_id].group_id;
> > +
> > +   /* No task specific clamp values: nothing to do */
> > +   if (group_id == UCLAMP_NONE)
> > +   return;
> > +
> > +   /* Increment the current group_id */
> 
> That I think qualifies being called a bad comment.

my bad :/

> > +   uc_cpu->group[group_id].tasks += 1;
> > +
> > +   /* Mark task as enqueued for this clamp index */
> > +   p->uclamp_group_id[clamp_id] = group_id;
> 
> Why exactly do we need this? we got group_id from @p in the first place.

The idea is to back-annotate on the task the group in which it has
been refcounted. That allows a much simpler and less racy refcount
decrements at dequeue/migration time.

That's also why we have a single call-back, uclamp_task_update(),
for both enqueue/dequeue. Depending on the check performed by
uclamp_task_affects() we know if we have to get or put the refcounter.

> I suspect this is because when we update p->uclamp[], we don't update
> this active value (when needed), is that worth it?

What you mean by "we don't update this active value"?

> > +   /*
> > +* If this is the new max utilization clamp value, then we can update
> > +* straight away the CPU clamp value. Otherwise, the current CPU clamp
> > +* value is still valid and we are done.
> > +*/
> > +   if (uc_cpu->value < clamp_value)
> > +   uc_cpu->value = clamp_value;
> > +}

-- 
#include 

Patrick Bellasi

Re: [PATCH] memcg: Remove memcg_cgroup::id from IDR on mem_cgroup_css_alloc() failure

[Kirill Tkhai]

On 13.04.2018 14:02, Michal Hocko wrote:
> On Fri 13-04-18 12:35:22, Kirill Tkhai wrote:
>> On 13.04.2018 11:55, Michal Hocko wrote:
>>> On Thu 12-04-18 17:52:04, Kirill Tkhai wrote:
>>> [...]
 @@ -4471,6 +4477,7 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state 
 *parent_css)
  
return &memcg->css;
  fail:
 +  mem_cgroup_id_remove(memcg);
mem_cgroup_free(memcg);
return ERR_PTR(-ENOMEM);
  }
>>>
>>> The only path which jumps to fail: here (in the current mmotm tree) is 
>>> error = memcg_online_kmem(memcg);
>>> if (error)
>>> goto fail;
>>>
>>> AFAICS and the only failure path in memcg_online_kmem
>>> memcg_id = memcg_alloc_cache_id();
>>> if (memcg_id < 0)
>>> return memcg_id;
>>>
>>> I am not entirely clear on memcg_alloc_cache_id but it seems we do clean
>>> up properly. Or am I missing something?
>>
>> memcg_alloc_cache_id() may allocate a lot of memory, in case of the system 
>> reached
>> memcg_nr_cache_ids cgroups. In this case it iterates over all LRU lists, and 
>> double
>> size of every of them. In case of memory pressure it can fail. If this 
>> occurs,
>> mem_cgroup::id is not unhashed from IDR and we leak this id.
> 
> OK, my bad I was looking at the bad code path. So you want to clean up
> after mem_cgroup_alloc not memcg_online_kmem. Now it makes much more
> sense. Sorry for the confusion on my end.
> 
> Anyway, shouldn't we do the thing in mem_cgroup_free() to be symmetric
> to mem_cgroup_alloc?

We can't, since it's called from mem_cgroup_css_free(), which doesn't have a 
deal
with idr freeing. All the asymmetry, we see, is because of the trick to unhash 
ID
earlier, then from mem_cgroup_css_free().

Kirill

Re: [PATCH 1/7] sched/core: uclamp: add CPU clamp groups accounting

[Patrick Bellasi]

On 13-Apr 12:22, Peter Zijlstra wrote:
> On Fri, Apr 13, 2018 at 10:26:48AM +0200, Peter Zijlstra wrote:
> > On Mon, Apr 09, 2018 at 05:56:09PM +0100, Patrick Bellasi wrote:
> > > +static inline void uclamp_cpu_get(struct task_struct *p, int cpu, int 
> > > clamp_id)
> > > +{
> > > + struct uclamp_cpu *uc_cpu = &cpu_rq(cpu)->uclamp[clamp_id];
> > 
> > > +static inline void uclamp_cpu_put(struct task_struct *p, int cpu, int 
> > > clamp_id)
> > > +{
> > > + struct uclamp_cpu *uc_cpu = &cpu_rq(cpu)->uclamp[clamp_id];
> > 
> > That all seems daft, since you already have rq at the call site.
> > 
> > > +static inline void uclamp_task_update(struct rq *rq, struct task_struct 
> > > *p)
> > > +{
> > > + int cpu = cpu_of(rq);
> > > + int clamp_id;
> > > +
> > > + /* The idle task does not affect CPU's clamps */
> > > + if (unlikely(p->sched_class == &idle_sched_class))
> > > + return;
> > > + /* DEADLINE tasks do not affect CPU's clamps */
> > > + if (unlikely(p->sched_class == &dl_sched_class))
> > > + return;
> > 
> > This is wrong; it misses the stop_sched_class.
> > 
> > And since you're looking at sched_class anyway, maybe put a marker in
> > there:
> > 
> > if (!p->sched_class->has_clamping)
> > return;
> 
> Alternatively, we could simply add uclamp_task_{en,de}queue() into
> {en,de}queue_task_{fair,rt}().

I like better your first proposal, I think it makes sense to factor
out in core code used by both RT and FAIR the same way.

Do you have a strong preference?

> > > + for (clamp_id = 0; clamp_id < UCLAMP_CNT; ++clamp_id) {
> > > + if (uclamp_task_affects(p, clamp_id))
> > > + uclamp_cpu_put(p, cpu, clamp_id);
> > > + else
> > > + uclamp_cpu_get(p, cpu, clamp_id);
> > > + }
> > > +}

-- 
#include 

Patrick Bellasi

Re: [PATCH] memcg: Remove memcg_cgroup::id from IDR on mem_cgroup_css_alloc() failure

[Michal Hocko]

On Fri 13-04-18 12:35:22, Kirill Tkhai wrote:
> On 13.04.2018 11:55, Michal Hocko wrote:
> > On Thu 12-04-18 17:52:04, Kirill Tkhai wrote:
> > [...]
> >> @@ -4471,6 +4477,7 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state 
> >> *parent_css)
> >>  
> >>return &memcg->css;
> >>  fail:
> >> +  mem_cgroup_id_remove(memcg);
> >>mem_cgroup_free(memcg);
> >>return ERR_PTR(-ENOMEM);
> >>  }
> > 
> > The only path which jumps to fail: here (in the current mmotm tree) is 
> > error = memcg_online_kmem(memcg);
> > if (error)
> > goto fail;
> > 
> > AFAICS and the only failure path in memcg_online_kmem
> > memcg_id = memcg_alloc_cache_id();
> > if (memcg_id < 0)
> > return memcg_id;
> > 
> > I am not entirely clear on memcg_alloc_cache_id but it seems we do clean
> > up properly. Or am I missing something?
> 
> memcg_alloc_cache_id() may allocate a lot of memory, in case of the system 
> reached
> memcg_nr_cache_ids cgroups. In this case it iterates over all LRU lists, and 
> double
> size of every of them. In case of memory pressure it can fail. If this occurs,
> mem_cgroup::id is not unhashed from IDR and we leak this id.

OK, my bad I was looking at the bad code path. So you want to clean up
after mem_cgroup_alloc not memcg_online_kmem. Now it makes much more
sense. Sorry for the confusion on my end.

Anyway, shouldn't we do the thing in mem_cgroup_free() to be symmetric
to mem_cgroup_alloc?
-- 
Michal Hocko
SUSE Labs

[PATCH] thermal/drivers/exynos_tmu: Fix warnings in temp_to_code / code_to_temp

[Daniel Lezcano]

The latest driver cleanup introduced a compilation warning

 drivers/thermal/samsung/exynos_tmu.c: In function ‘exynos_get_temp’:
 drivers/thermal/samsung/exynos_tmu.c:931:37: warning: ‘temp’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   *temp = code_to_temp(data, value) * MCELSIUS;
^

 drivers/thermal/samsung/exynos_tmu.c: In function ‘temp_to_code’
 drivers/thermal/samsung/exynos_tmu.c:304:9: warning: ‘temp_code’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
  return temp_code;
   ^

The compiler gives a warning because semantically speaking the
function has no default value. However the code path, were the
variable is never initialized is a dead branch because the switch
statement always choose one of the two cases as the data->cal_type is
initialized in the init function to one of both values.

This is unclear as it adds a dependency on the initialization function
and it is prone to error. Make things clearer by converting the
functions with if ... return statements, thus showing we are expecting
the values to be correctly filled before calling this function.

This change fixes the couple of function warnings.

Signed-off-by: Daniel Lezcano 
---
 drivers/thermal/samsung/exynos_tmu.c | 46 ++--
 1 file changed, 12 insertions(+), 34 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 2ec8548..197f267 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -284,24 +284,13 @@ static void exynos_report_trigger(struct exynos_tmu_data 
*p)
  */
 static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
 {
-   int temp_code;
-
-   switch (data->cal_type) {
-   case TYPE_TWO_POINT_TRIMMING:
-   temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
-   (data->temp_error2 - data->temp_error1) /
-   (EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) +
-   data->temp_error1;
-   break;
-   case TYPE_ONE_POINT_TRIMMING:
-   temp_code = temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
-   break;
-   default:
-   WARN_ON(1);
-   break;
-   }
+   if (data->cal_type == TYPE_ONE_POINT_TRIMMING)
+   return temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
 
-   return temp_code;
+   return (temp - EXYNOS_FIRST_POINT_TRIM) *
+   (data->temp_error2 - data->temp_error1) /
+   (EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) +
+   data->temp_error1;
 }
 
 /*
@@ -310,24 +299,13 @@ static int temp_to_code(struct exynos_tmu_data *data, u8 
temp)
  */
 static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
 {
-   int temp;
-
-   switch (data->cal_type) {
-   case TYPE_TWO_POINT_TRIMMING:
-   temp = (temp_code - data->temp_error1) *
-   (EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) /
-   (data->temp_error2 - data->temp_error1) +
-   EXYNOS_FIRST_POINT_TRIM;
-   break;
-   case TYPE_ONE_POINT_TRIMMING:
-   temp = temp_code - data->temp_error1 + EXYNOS_FIRST_POINT_TRIM;
-   break;
-   default:
-   WARN_ON(1);
-   break;
-   }
+   if (data->cal_type == TYPE_ONE_POINT_TRIMMING)
+   return temp_code - data->temp_error1 + EXYNOS_FIRST_POINT_TRIM;
 
-   return temp;
+   return (temp_code - data->temp_error1) *
+   (EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) /
+   (data->temp_error2 - data->temp_error1) +
+   EXYNOS_FIRST_POINT_TRIM;
 }
 
 static void sanitize_temp_error(struct exynos_tmu_data *data, u32 trim_info)
-- 
2.7.4

Applied "spi: spi-topcliff-pch: Replace GFP_ATOMIC with GFP_KERNEL in pch_spi_handle_dma" to the spi tree

[Mark Brown]

The patch

   spi: spi-topcliff-pch: Replace GFP_ATOMIC with GFP_KERNEL in 
pch_spi_handle_dma

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From d16cd3eb8e5c62cd349987f57e3511b59cbe0198 Mon Sep 17 00:00:00 2001
From: Jia-Ju Bai 
Date: Tue, 10 Apr 2018 17:06:16 +0800
Subject: [PATCH] spi: spi-topcliff-pch: Replace GFP_ATOMIC with GFP_KERNEL in
 pch_spi_handle_dma

pch_spi_handle_dma() is never called in atomic context.
This function is only called by pch_spi_process_messages().
pch_spi_process_messages() is only set as a parameter of INIT_WORK() in
pch_spi_pd_probe().

Despite never getting called from atomic context,
pch_spi_handle_dma() calls kcalloc() with GFP_ATOMIC,
which does not sleep for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-topcliff-pch.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-topcliff-pch.c b/drivers/spi/spi-topcliff-pch.c
index 97d137591b18..dc93ca9e001c 100644
--- a/drivers/spi/spi-topcliff-pch.c
+++ b/drivers/spi/spi-topcliff-pch.c
@@ -1007,7 +1007,7 @@ static void pch_spi_handle_dma(struct pch_spi_data *data, 
int *bpw)
spin_unlock_irqrestore(&data->lock, flags);
 
/* RX */
-   dma->sg_rx_p = kcalloc(num, sizeof(*dma->sg_rx_p), GFP_ATOMIC);
+   dma->sg_rx_p = kcalloc(num, sizeof(*dma->sg_rx_p), GFP_KERNEL);
sg_init_table(dma->sg_rx_p, num); /* Initialize SG table */
/* offset, length setting */
sg = dma->sg_rx_p;
@@ -1067,7 +1067,7 @@ static void pch_spi_handle_dma(struct pch_spi_data *data, 
int *bpw)
head = 0;
}
 
-   dma->sg_tx_p = kcalloc(num, sizeof(*dma->sg_tx_p), GFP_ATOMIC);
+   dma->sg_tx_p = kcalloc(num, sizeof(*dma->sg_tx_p), GFP_KERNEL);
sg_init_table(dma->sg_tx_p, num); /* Initialize SG table */
/* offset, length setting */
sg = dma->sg_tx_p;
-- 
2.17.0

Applied "ASoC: intel: skl_rt286: Replace GFP_ATOMIC with GFP_KERNEL in skylake_audio_probe" to the asoc tree

[Mark Brown]

The patch

   ASoC: intel: skl_rt286: Replace GFP_ATOMIC with GFP_KERNEL in 
skylake_audio_probe

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From b614aa81e07d7b9cf1c64b61d02a01d66ef43ed6 Mon Sep 17 00:00:00 2001
From: Jia-Ju Bai 
Date: Mon, 9 Apr 2018 18:49:58 +0800
Subject: [PATCH] ASoC: intel: skl_rt286: Replace GFP_ATOMIC with GFP_KERNEL in
 skylake_audio_probe

skylake_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".

Despite never getting called from atomic context,
skylake_audio_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: Mark Brown 
---
 sound/soc/intel/boards/skl_rt286.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/skl_rt286.c 
b/sound/soc/intel/boards/skl_rt286.c
index 737d5615b0ef..38a1495c29cf 100644
--- a/sound/soc/intel/boards/skl_rt286.c
+++ b/sound/soc/intel/boards/skl_rt286.c
@@ -527,7 +527,7 @@ static int skylake_audio_probe(struct platform_device *pdev)
 {
struct skl_rt286_private *ctx;
 
-   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_ATOMIC);
+   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
-- 
2.17.0

Applied "ASoC: intel: skl_nau88l25_ssm4567: Replace GFP_ATOMIC with GFP_KERNEL in skylake_audio_probe" to the asoc tree

[Mark Brown]

The patch

   ASoC: intel: skl_nau88l25_ssm4567: Replace GFP_ATOMIC with GFP_KERNEL in 
skylake_audio_probe

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From fe552c82476f2fb16e87a76ee178465325e57f61 Mon Sep 17 00:00:00 2001
From: Jia-Ju Bai 
Date: Mon, 9 Apr 2018 18:49:34 +0800
Subject: [PATCH] ASoC: intel: skl_nau88l25_ssm4567: Replace GFP_ATOMIC with
 GFP_KERNEL in skylake_audio_probe

skylake_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".

Despite never getting called from atomic context,
skylake_audio_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: Mark Brown 
---
 sound/soc/intel/boards/skl_nau88l25_ssm4567.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/skl_nau88l25_ssm4567.c 
b/sound/soc/intel/boards/skl_nau88l25_ssm4567.c
index 212ac8971e55..b0610bba3cfa 100644
--- a/sound/soc/intel/boards/skl_nau88l25_ssm4567.c
+++ b/sound/soc/intel/boards/skl_nau88l25_ssm4567.c
@@ -696,7 +696,7 @@ static int skylake_audio_probe(struct platform_device *pdev)
struct skl_nau88125_private *ctx;
struct skl_machine_pdata *pdata;
 
-   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_ATOMIC);
+   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
-- 
2.17.0

Applied "ASoC: trace: remove snd_soc_codec" to the asoc tree

[Mark Brown]

The patch

   ASoC: trace: remove snd_soc_codec

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 03a364502bebb5f464853c6ec5d49e85195600ca Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Wed, 28 Mar 2018 02:18:13 +
Subject: [PATCH] ASoC: trace: remove snd_soc_codec

snd_soc_codec is replaced to snd_soc_component,
and it is not used in this file.
Let's remove it

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 include/trace/events/asoc.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index ccd1a3bdff46..40c300fe704d 100644
--- a/include/trace/events/asoc.h
+++ b/include/trace/events/asoc.h
@@ -12,7 +12,6 @@
 #define DAPM_ARROW(dir) (((dir) == SND_SOC_DAPM_DIR_OUT) ? "->" : "<-")
 
 struct snd_soc_jack;
-struct snd_soc_codec;
 struct snd_soc_card;
 struct snd_soc_dapm_widget;
 struct snd_soc_dapm_path;
-- 
2.17.0

Applied "ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"" to the asoc tree

[Mark Brown]

The patch

   ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 78a7d414d5a8e3ea7bc5a636311cfb7ce593ce37 Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Fri, 30 Mar 2018 16:44:20 +0100
Subject: [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" ->
 "Stopping"

Trivial fix to spelling mistake in pr_debug message text

Signed-off-by: Colin Ian King 
Acked-by: Alexandre Belloni 
Acked-by: Nicolas Ferre 
Signed-off-by: Mark Brown 
---
 sound/soc/atmel/atmel_ssc_dai.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index a1e2c5682dcd..1c7af0ca98ec 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -820,7 +820,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
*substream,
if (ret < 0) {
printk(KERN_WARNING
"atmel_ssc_dai: request_irq failure\n");
-   pr_debug("Atmel_ssc_dai: Stoping clock\n");
+   pr_debug("Atmel_ssc_dai: Stopping clock\n");
clk_disable(ssc_p->ssc->clk);
return ret;
}
-- 
2.17.0

Applied "ASoC: max9860: switch to using .probe_new" to the asoc tree

[Mark Brown]

The patch

   ASoC: max9860: switch to using .probe_new

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From ba4e62f653656a0077322eb29c7b8dde3c84399e Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Wed, 11 Apr 2018 14:42:37 +0200
Subject: [PATCH] ASoC: max9860: switch to using .probe_new

Use the new probe style for i2c drivers.

Signed-off-by: Peter Rosin 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/max9860.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/sound/soc/codecs/max9860.c b/sound/soc/codecs/max9860.c
index 5bbf889ad98e..96b2db3f2ddd 100644
--- a/sound/soc/codecs/max9860.c
+++ b/sound/soc/codecs/max9860.c
@@ -598,8 +598,7 @@ static const struct dev_pm_ops max9860_pm_ops = {
SET_RUNTIME_PM_OPS(max9860_suspend, max9860_resume, NULL)
 };
 
-static int max9860_probe(struct i2c_client *i2c,
-const struct i2c_device_id *id)
+static int max9860_probe(struct i2c_client *i2c)
 {
struct device *dev = &i2c->dev;
struct max9860_priv *max9860;
@@ -736,7 +735,7 @@ static const struct of_device_id max9860_of_match[] = {
 MODULE_DEVICE_TABLE(of, max9860_of_match);
 
 static struct i2c_driver max9860_i2c_driver = {
-   .probe  = max9860_probe,
+   .probe_new  = max9860_probe,
.remove = max9860_remove,
.id_table   = max9860_i2c_id,
.driver = {
-- 
2.17.0

Applied "ASoC: intel: bxt_da7219_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in broxton_audio_probe" to the asoc tree

[Mark Brown]

The patch

   ASoC: intel: bxt_da7219_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in 
broxton_audio_probe

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 8f2f9215aa14904ddd9775f3b4e7af2d94189dea Mon Sep 17 00:00:00 2001
From: Jia-Ju Bai 
Date: Mon, 9 Apr 2018 18:46:21 +0800
Subject: [PATCH] ASoC: intel: bxt_da7219_max98357a: Replace GFP_ATOMIC with
 GFP_KERNEL in broxton_audio_probe

broxton_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".

Despite never getting called from atomic context,
broxton_audio_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: Mark Brown 
---
 sound/soc/intel/boards/bxt_da7219_max98357a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c 
b/sound/soc/intel/boards/bxt_da7219_max98357a.c
index 668c0934e942..40eb979d5ac1 100644
--- a/sound/soc/intel/boards/bxt_da7219_max98357a.c
+++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c
@@ -571,7 +571,7 @@ static int broxton_audio_probe(struct platform_device *pdev)
 {
struct bxt_card_private *ctx;
 
-   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_ATOMIC);
+   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
-- 
2.17.0

Applied "ASoC: intel: skl_nau88l25_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in skylake_audio_probe" to the asoc tree

[Mark Brown]

The patch

   ASoC: intel: skl_nau88l25_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in 
skylake_audio_probe

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 6618d2e864ac0e869c6de47bc85d1552e7443b22 Mon Sep 17 00:00:00 2001
From: Jia-Ju Bai 
Date: Mon, 9 Apr 2018 18:48:56 +0800
Subject: [PATCH] ASoC: intel: skl_nau88l25_max98357a: Replace GFP_ATOMIC with
 GFP_KERNEL in skylake_audio_probe

skylake_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".

Despite never getting called from atomic context,
skylake_audio_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: Mark Brown 
---
 sound/soc/intel/boards/skl_nau88l25_max98357a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/skl_nau88l25_max98357a.c 
b/sound/soc/intel/boards/skl_nau88l25_max98357a.c
index 9a7a0646bffe..3ff6646cfa21 100644
--- a/sound/soc/intel/boards/skl_nau88l25_max98357a.c
+++ b/sound/soc/intel/boards/skl_nau88l25_max98357a.c
@@ -643,7 +643,7 @@ static int skylake_audio_probe(struct platform_device *pdev)
struct skl_nau8825_private *ctx;
struct skl_machine_pdata *pdata;
 
-   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_ATOMIC);
+   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
-- 
2.17.0

Applied "ASoC: intel: bxt_rt298: Replace GFP_ATOMIC with GFP_KERNEL in broxton_audio_probe" to the asoc tree

[Mark Brown]

The patch

   ASoC: intel: bxt_rt298: Replace GFP_ATOMIC with GFP_KERNEL in 
broxton_audio_probe

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From ac6c5ea121e78b4c5caef2e307d59a0e35a65a88 Mon Sep 17 00:00:00 2001
From: Jia-Ju Bai 
Date: Mon, 9 Apr 2018 18:47:07 +0800
Subject: [PATCH] ASoC: intel: bxt_rt298: Replace GFP_ATOMIC with GFP_KERNEL in
 broxton_audio_probe

broxton_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".

Despite never getting called from atomic context,
broxton_audio_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: Mark Brown 
---
 sound/soc/intel/boards/bxt_rt298.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/bxt_rt298.c 
b/sound/soc/intel/boards/bxt_rt298.c
index c7e9024e65ef..b68c289558a8 100644
--- a/sound/soc/intel/boards/bxt_rt298.c
+++ b/sound/soc/intel/boards/bxt_rt298.c
@@ -593,7 +593,7 @@ static int broxton_audio_probe(struct platform_device *pdev)
}
}
 
-   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_ATOMIC);
+   ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
-- 
2.17.0

Applied "ASoC: intel: cht_bsw_max98090_ti: Replace GFP_ATOMIC with GFP_KERNEL in snd_cht_mc_probe" to the asoc tree

[Mark Brown]

The patch

   ASoC: intel: cht_bsw_max98090_ti: Replace GFP_ATOMIC with GFP_KERNEL in 
snd_cht_mc_probe

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From f0a0bdcf34579b08acfe0179ad46da4dc123fc91 Mon Sep 17 00:00:00 2001
From: Jia-Ju Bai 
Date: Mon, 9 Apr 2018 18:48:10 +0800
Subject: [PATCH] ASoC: intel: cht_bsw_max98090_ti: Replace GFP_ATOMIC with
 GFP_KERNEL in snd_cht_mc_probe

snd_cht_mc_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".

Despite never getting called from atomic context,
snd_cht_mc_probe() calls devm_kzalloc() with GFP_ATOMIC,
which waits busily for allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
to avoid busy waiting and improve the possibility of sucessful allocation.

This is found by a static analysis tool named DCNS written by myself.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: Mark Brown 
---
 sound/soc/intel/boards/cht_bsw_max98090_ti.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/boards/cht_bsw_max98090_ti.c 
b/sound/soc/intel/boards/cht_bsw_max98090_ti.c
index d3e1c7e12004..db6976f4ddaa 100644
--- a/sound/soc/intel/boards/cht_bsw_max98090_ti.c
+++ b/sound/soc/intel/boards/cht_bsw_max98090_ti.c
@@ -391,7 +391,7 @@ static int snd_cht_mc_probe(struct platform_device *pdev)
int ret_val = 0;
struct cht_mc_private *drv;
 
-   drv = devm_kzalloc(&pdev->dev, sizeof(*drv), GFP_ATOMIC);
+   drv = devm_kzalloc(&pdev->dev, sizeof(*drv), GFP_KERNEL);
if (!drv)
return -ENOMEM;
 
-- 
2.17.0

Applied "ASoC: TSCS42xx: Shorten lines and other cleanup" to the asoc tree

[Mark Brown]

The patch

   ASoC: TSCS42xx: Shorten lines and other cleanup

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From ca5b2b061e41ed97b1bc041bf0c0db2f40643863 Mon Sep 17 00:00:00 2001
From: Steven Eckhoff 
Date: Wed, 4 Apr 2018 16:49:50 -0500
Subject: [PATCH] ASoC: TSCS42xx: Shorten lines and other cleanup

Shorten lines greater than 80 chars
Add const to struct snd_soc_component_driver

Signed-off-by: Steven Eckhoff 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/tscs42xx.c | 87 +++--
 1 file changed, 55 insertions(+), 32 deletions(-)

diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c
index bbfc73a79b18..5ad68e5538ae 100644
--- a/sound/soc/codecs/tscs42xx.c
+++ b/sound/soc/codecs/tscs42xx.c
@@ -204,7 +204,8 @@ static int power_up_audio_plls(struct snd_soc_component 
*component)
break;
default:
ret = -EINVAL;
-   dev_err(component->dev, "Unrecognized PLL output freq (%d)\n", 
ret);
+   dev_err(component->dev,
+   "Unrecognized PLL output freq (%d)\n", ret);
return ret;
}
 
@@ -261,7 +262,8 @@ static int power_down_audio_plls(struct snd_soc_component 
*component)
 static int coeff_ram_get(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol)
 {
-   struct snd_soc_component *component = 
snd_soc_kcontrol_component(kcontrol);
+   struct snd_soc_component *component =
+   snd_soc_kcontrol_component(kcontrol);
struct tscs42xx *tscs42xx = snd_soc_component_get_drvdata(component);
struct coeff_ram_ctl *ctl =
(struct coeff_ram_ctl *)kcontrol->private_value;
@@ -280,7 +282,8 @@ static int coeff_ram_get(struct snd_kcontrol *kcontrol,
 static int coeff_ram_put(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol)
 {
-   struct snd_soc_component *component = 
snd_soc_kcontrol_component(kcontrol);
+   struct snd_soc_component *component =
+   snd_soc_kcontrol_component(kcontrol);
struct tscs42xx *tscs42xx = snd_soc_component_get_drvdata(component);
struct coeff_ram_ctl *ctl =
(struct coeff_ram_ctl *)kcontrol->private_value;
@@ -363,7 +366,8 @@ static int dapm_micb_event(struct snd_soc_dapm_widget *w,
 static int pll_event(struct snd_soc_dapm_widget *w,
 struct snd_kcontrol *kcontrol, int event)
 {
-   struct snd_soc_component *component = 
snd_soc_dapm_to_component(w->dapm);
+   struct snd_soc_component *component =
+   snd_soc_dapm_to_component(w->dapm);
int ret;
 
if (SND_SOC_DAPM_EVENT_ON(event))
@@ -377,7 +381,8 @@ static int pll_event(struct snd_soc_dapm_widget *w,
 static int dac_event(struct snd_soc_dapm_widget *w,
 struct snd_kcontrol *kcontrol, int event)
 {
-   struct snd_soc_component *component = 
snd_soc_dapm_to_component(w->dapm);
+   struct snd_soc_component *component =
+   snd_soc_dapm_to_component(w->dapm);
struct tscs42xx *tscs42xx = snd_soc_component_get_drvdata(component);
int ret;
 
@@ -819,16 +824,19 @@ static int setup_sample_format(struct snd_soc_component 
*component,
dev_err(component->dev, "Unsupported format width (%d)\n", ret);
return ret;
}
-   ret = snd_soc_component_update_bits(component, R_AIC1, RM_AIC1_WL, 
width);
+   ret = snd_soc_component_update_bits(component,
+   R_AIC1, RM_AIC1_WL, width);
if (ret < 0) {
-   dev_err(component->dev, "Failed to set sample width (%d)\n", 
ret);
+   dev_err(component->dev,
+   "Failed to set sample width (%d)\n", ret);
return ret;
}
 
return 0;
 }
 
-static int setup_sample_rate(struct snd_soc_component *component, unsigned int 
rate)
+static int setup_sample_rate(struct snd_soc_component *component,
+   unsigned int rate)
 {
struct tscs42xx *tscs42xx = snd_soc_component_get_drvdata(component);
unsigned int br, bm;
@@ -881,24 +889,

Re: [PATCH] sound: soc: intel: bxt_da7219_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in broxton_audio_probe

[Mark Brown]

On Fri, Apr 13, 2018 at 06:54:15PM +0800, Jia-Ju Bai wrote:

> I looked at previous related patches, and find the subject should be "ASoC:
> Intel: "
> I will follow it in my future patches.

Right, that's it for these thanks.

> Do I need to send V2 patches?

No, it's OK - I already applied them.


signature.asc
Description: PGP signature

Applied "ASoC: TSCS42xx: Cleanup private data members" to the asoc tree

[Mark Brown]

The patch

   ASoC: TSCS42xx: Cleanup private data members

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From bc85b750bfc4a1ac69c145208f95dda03dc41d60 Mon Sep 17 00:00:00 2001
From: Steven Eckhoff 
Date: Wed, 4 Apr 2018 16:49:51 -0500
Subject: [PATCH] ASoC: TSCS42xx: Cleanup private data members

Remove blrcm from private data
Remove dev from private data

Signed-off-by: Steven Eckhoff 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/tscs42xx.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c
index 5ad68e5538ae..bf207b0345f1 100644
--- a/sound/soc/codecs/tscs42xx.c
+++ b/sound/soc/codecs/tscs42xx.c
@@ -31,7 +31,6 @@ struct tscs42xx {
 
int bclk_ratio;
int samplerate;
-   unsigned int blrcm;
struct mutex audio_params_lock;
 
u8 coeff_ram[COEFF_RAM_SIZE];
@@ -41,8 +40,6 @@ struct tscs42xx {
struct mutex pll_lock;
 
struct regmap *regmap;
-
-   struct device *dev;
 };
 
 struct coeff_ram_ctl {
@@ -1404,12 +1401,11 @@ static int tscs42xx_i2c_probe(struct i2c_client *i2c,
return ret;
}
i2c_set_clientdata(i2c, tscs42xx);
-   tscs42xx->dev = &i2c->dev;
 
tscs42xx->regmap = devm_regmap_init_i2c(i2c, &tscs42xx_regmap);
if (IS_ERR(tscs42xx->regmap)) {
ret = PTR_ERR(tscs42xx->regmap);
-   dev_err(tscs42xx->dev, "Failed to allocate regmap (%d)\n", ret);
+   dev_err(&i2c->dev, "Failed to allocate regmap (%d)\n", ret);
return ret;
}
 
@@ -1417,21 +1413,21 @@ static int tscs42xx_i2c_probe(struct i2c_client *i2c,
 
ret = part_is_valid(tscs42xx);
if (ret <= 0) {
-   dev_err(tscs42xx->dev, "No valid part (%d)\n", ret);
+   dev_err(&i2c->dev, "No valid part (%d)\n", ret);
ret = -ENODEV;
return ret;
}
 
ret = regmap_write(tscs42xx->regmap, R_RESET, RV_RESET_ENABLE);
if (ret < 0) {
-   dev_err(tscs42xx->dev, "Failed to reset device (%d)\n", ret);
+   dev_err(&i2c->dev, "Failed to reset device (%d)\n", ret);
return ret;
}
 
ret = regmap_register_patch(tscs42xx->regmap, tscs42xx_patch,
ARRAY_SIZE(tscs42xx_patch));
if (ret < 0) {
-   dev_err(tscs42xx->dev, "Failed to apply patch (%d)\n", ret);
+   dev_err(&i2c->dev, "Failed to apply patch (%d)\n", ret);
return ret;
}
 
@@ -1439,10 +1435,10 @@ static int tscs42xx_i2c_probe(struct i2c_client *i2c,
mutex_init(&tscs42xx->coeff_ram_lock);
mutex_init(&tscs42xx->pll_lock);
 
-   ret = devm_snd_soc_register_component(tscs42xx->dev,
+   ret = devm_snd_soc_register_component(&i2c->dev,
&soc_codec_dev_tscs42xx, &tscs42xx_dai, 1);
if (ret) {
-   dev_err(tscs42xx->dev, "Failed to register codec (%d)\n", ret);
+   dev_err(&i2c->dev, "Failed to register codec (%d)\n", ret);
return ret;
}
 
-- 
2.17.0

Applied "ASoC: TSCS42xx: Add CCF support to get sysclk" to the asoc tree

[Mark Brown]

The patch

   ASoC: TSCS42xx: Add CCF support to get sysclk

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 8dc0e2a1f5c587f1afa227ec46012b92cea6d7a7 Mon Sep 17 00:00:00 2001
From: Steven Eckhoff 
Date: Wed, 4 Apr 2018 16:49:52 -0500
Subject: [PATCH] ASoC: TSCS42xx: Add CCF support to get sysclk

The TSCS42xx relies on set_sysclk to get a unique clock id and rate,
which prevents it from being used with the simple-card.

Remove set_sysclk callback
Add CCF support to get clock id and rate
Add clocks and clock-names to device tree binding

Signed-off-by: Steven Eckhoff 
Signed-off-by: Mark Brown 
---
 .../devicetree/bindings/sound/tscs42xx.txt|   6 +
 sound/soc/codecs/tscs42xx.c   | 104 --
 sound/soc/codecs/tscs42xx.h   |   2 +-
 3 files changed, 75 insertions(+), 37 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/tscs42xx.txt 
b/Documentation/devicetree/bindings/sound/tscs42xx.txt
index 2ac2f0996697..7eea32e9d078 100644
--- a/Documentation/devicetree/bindings/sound/tscs42xx.txt
+++ b/Documentation/devicetree/bindings/sound/tscs42xx.txt
@@ -8,9 +8,15 @@ Required Properties:
- reg : <0x71> for analog mic
<0x69> for digital mic
 
+   - clock-names:  Must one of  the following "mclk1", "xtal", "mclk2"
+
+   - clocks:   phandle of the clock that provides the codec sysclk
+
 Example:
 
 wookie: codec@69 {
compatible = "tempo,tscs42A2";
reg = <0x69>;
+   clock-names = "xtal";
+   clocks = <&audio_xtal>;
 };
diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c
index bf207b0345f1..d18ff17719cc 100644
--- a/sound/soc/codecs/tscs42xx.c
+++ b/sound/soc/codecs/tscs42xx.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -40,6 +41,9 @@ struct tscs42xx {
struct mutex pll_lock;
 
struct regmap *regmap;
+
+   struct clk *sysclk;
+   int sysclk_src_id;
 };
 
 struct coeff_ram_ctl {
@@ -1251,13 +1255,46 @@ static int tscs42xx_set_dai_bclk_ratio(struct 
snd_soc_dai *codec_dai,
return 0;
 }
 
-static int tscs42xx_set_dai_sysclk(struct snd_soc_dai *codec_dai,
-   int clk_id, unsigned int freq, int dir)
+static const struct snd_soc_dai_ops tscs42xx_dai_ops = {
+   .hw_params  = tscs42xx_hw_params,
+   .mute_stream= tscs42xx_mute_stream,
+   .set_fmt= tscs42xx_set_dai_fmt,
+   .set_bclk_ratio = tscs42xx_set_dai_bclk_ratio,
+};
+
+static int part_is_valid(struct tscs42xx *tscs42xx)
 {
-   struct snd_soc_component *component = codec_dai->component;
+   int val;
int ret;
+   unsigned int reg;
+
+   ret = regmap_read(tscs42xx->regmap, R_DEVIDH, ®);
+   if (ret < 0)
+   return ret;
 
-   switch (clk_id) {
+   val = reg << 8;
+   ret = regmap_read(tscs42xx->regmap, R_DEVIDL, ®);
+   if (ret < 0)
+   return ret;
+
+   val |= reg;
+
+   switch (val) {
+   case 0x4A74:
+   case 0x4A73:
+   return true;
+   default:
+   return false;
+   };
+}
+
+static int set_sysclk(struct snd_soc_component *component)
+{
+   struct tscs42xx *tscs42xx = snd_soc_component_get_drvdata(component);
+   unsigned long freq;
+   int ret;
+
+   switch (tscs42xx->sysclk_src_id) {
case TSCS42XX_PLL_SRC_XTAL:
case TSCS42XX_PLL_SRC_MCLK1:
ret = snd_soc_component_write(component, R_PLLREFSEL,
@@ -1285,6 +1322,7 @@ static int tscs42xx_set_dai_sysclk(struct snd_soc_dai 
*codec_dai,
return -EINVAL;
}
 
+   freq = clk_get_rate(tscs42xx->sysclk);
ret = set_pll_ctl_from_input_freq(component, freq);
if (ret < 0) {
dev_err(component->dev,
@@ -1295,41 +1333,13 @@ static int tscs42xx_set_dai_sysclk(struct snd_soc_dai 
*codec_dai,
return 0;
 }
 
-static const struct snd_soc_dai_ops tscs42xx_dai_ops = {
-   .hw_params  = tscs42xx_hw_params,
-   .mute_stream= tscs42xx_mute_stream,
-   .set_fmt= tscs42xx_set_dai_fmt,
-   .set_bclk_

Re: [PATCH] sound: soc: intel: bxt_da7219_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in broxton_audio_probe

[Jia-Ju Bai]

On 2018/4/13 18:41, Mark Brown wrote:

On Mon, Apr 09, 2018 at 06:46:21PM +0800, Jia-Ju Bai wrote:

broxton_audio_probe() is never called in atomic context.
This function is only set as ".probe" in "struct platform_driver".

Please submit patches using subject lines reflecting the style for the
subsystem.  This makes it easier for people to identify relevant
patches.  Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.


Oh, sorry for my improper subjects.
Thanks for your very helpful advice :)
I looked at previous related patches, and find the subject should be 
"ASoC: Intel: "

I will follow it in my future patches.

Do I need to send V2 patches?


Best wishes,
Jia-Ju Bai

[PATCH] configfs: inherit file and directory owners

[Gwendal Grignou]

All entries in configfs are currently owned by root,
regardless of context. Instead, this preserves the
current ownership, allowing userspace to choose who
has permissions to configure the system through
any particular configfs subsystem.

This means anyone who can create a group will now
have the ability to create any groups inside of that
group.

Signed-off-by: Daniel Rosenberg 
Signed-off-by: Gwendal Grignou 
---
 fs/configfs/inode.c | 38 +++---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/fs/configfs/inode.c b/fs/configfs/inode.c
index ad718e5e37bb..1b55374de953 100644
--- a/fs/configfs/inode.c
+++ b/fs/configfs/inode.c
@@ -54,6 +54,28 @@ static const struct inode_operations 
configfs_inode_operations ={
.setattr= configfs_setattr,
 };
 
+static struct iattr *alloc_iattr(struct configfs_dirent *sd_parent,
+   struct configfs_dirent *sd)
+{
+   struct iattr *sd_iattr;
+
+   sd_iattr = kzalloc(sizeof(struct iattr), GFP_KERNEL);
+   if (!sd_iattr)
+   return NULL;
+   /* assign default attributes */
+   sd_iattr->ia_mode = sd->s_mode;
+   if (sd_parent && sd_parent->s_iattr) {
+   sd_iattr->ia_uid = sd_parent->s_iattr->ia_uid;
+   sd_iattr->ia_gid = sd_parent->s_iattr->ia_gid;
+   } else {
+   sd_iattr->ia_uid = GLOBAL_ROOT_UID;
+   sd_iattr->ia_gid = GLOBAL_ROOT_GID;
+   }
+   sd_iattr->ia_atime = sd_iattr->ia_mtime =
+   sd_iattr->ia_ctime = CURRENT_TIME;
+   return sd_iattr;
+}
+
 int configfs_setattr(struct dentry * dentry, struct iattr * iattr)
 {
struct inode * inode = d_inode(dentry);
@@ -68,15 +90,9 @@ int configfs_setattr(struct dentry * dentry, struct iattr * 
iattr)
sd_iattr = sd->s_iattr;
if (!sd_iattr) {
/* setting attributes for the first time, allocate now */
-   sd_iattr = kzalloc(sizeof(struct iattr), GFP_KERNEL);
+   sd_iattr = alloc_iattr(NULL, sd);
if (!sd_iattr)
return -ENOMEM;
-   /* assign default attributes */
-   sd_iattr->ia_mode = sd->s_mode;
-   sd_iattr->ia_uid = GLOBAL_ROOT_UID;
-   sd_iattr->ia_gid = GLOBAL_ROOT_GID;
-   sd_iattr->ia_atime = sd_iattr->ia_mtime =
-   sd_iattr->ia_ctime = current_time(inode);
sd->s_iattr = sd_iattr;
}
/* attributes were changed atleast once in past */
@@ -184,6 +200,7 @@ int configfs_create(struct dentry * dentry, umode_t mode, 
void (*init)(struct in
struct inode *inode = NULL;
struct configfs_dirent *sd;
struct inode *p_inode;
+   struct dentry *parent;
 
if (!dentry)
return -ENOENT;
@@ -192,6 +209,13 @@ int configfs_create(struct dentry * dentry, umode_t mode, 
void (*init)(struct in
return -EEXIST;
 
sd = dentry->d_fsdata;
+   parent = dget_parent(dentry);
+   if (parent && !sd->s_iattr) {
+   sd->s_iattr = alloc_iattr(parent->d_fsdata, sd);
+   if (!sd->s_iattr)
+   return -ENOMEM;
+   }
+   dput(parent);
inode = configfs_new_inode(mode, sd, dentry->d_sb);
if (!inode)
return -ENOMEM;
-- 
2.17.0.484.g0c8726318c-goog

Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration

[Baolin Wang]

On 13 April 2018 at 18:11, Vinod Koul  wrote:
> On Fri, Apr 13, 2018 at 02:41:48PM +0800, Baolin Wang wrote:
>> On 13 April 2018 at 14:36, Vinod Koul  wrote:
>> > On Fri, Apr 13, 2018 at 02:17:34PM +0800, Baolin Wang wrote:
>> >
>> >> > Agreed, users only care about grabbing a channel, setting a descriptor 
>> >> > and
>> >> > submitting that.
>> >> >
>> >> > I think you need to go back and think about this a bit, please do go 
>> >> > thru
>> >> > dmaengine documentation and see other driver examples.
>> >> >
>> >> > We don't typically expose these to users, they give us a transfer and 
>> >> > we set
>> >> > that up in hardware for efficient. Its DMA so people expect us to use 
>> >> > fastest
>> >> > mechanism available.
>> >>
>> >> But there are some configuration are really special for Spreadtrum
>> >> DMA, and must need user to specify how to configure, especially some
>> >> scenarios of audio. So I wander if we can add one pointer for
>> >> 'dma_slave_config' to expand some special DMA configuration
>> >> requirements, like:
>> >>
>> >> struct dma_slave_config {
>> >> ..
>> >> unsigned int slave_id;
>> >> void *platform_data;
>> >> };
>> >>
>> >> So if some DMA has some special configuration (such as Spreadtrum
>> >> DMA), they can user this platform_data pointer. Like xilinx DMA, they
>> >> also have some special configuration.
>> >
>> > Well we all think our HW is special and needs some additional stuff, most 
>> > of
>> > the cases turns out not to be the case.
>> >
>> > Can you explain how audio in this case additional configuration...
>> >
>>
>> Beside the general configuration, our audio driver will configure the
>> fragment length, block length, maybe transaction length, and they must
>> specify the request type and interrupt type, these are what we want to
>> export for users.
>
> First doesn't it use sound dmaengine library, it should :)

I do not think so. That's the DMA configuration need to set before
audio use it. Not only audio, but also other drivers using DMA need to
configure these configuration what we exported in sprd_dma_config.

>
> Second, I think you should calculate the lengths based on given input. Audio
> is circular buffer so you shall create a circular linked list and submit.
> See how other driver implement circular prepare callback

Yes,  we have not implemented the link list mode for audio now, but in
our plan. So firstly we want to export these necessary configuration
for users to configure.

-- 
Baolin.wang
Best Regards

Re: [PATCH] mm: vmalloc: Remove double execution of vunmap_page_range

[Chintan Pandya]

On 4/13/2018 4:10 PM, Anshuman Khandual wrote:

On 04/13/2018 03:47 PM, Chintan Pandya wrote:



On 4/13/2018 3:29 PM, Anshuman Khandual wrote:

On 04/13/2018 02:46 PM, Chintan Pandya wrote:

Unmap legs do call vunmap_page_range() irrespective of
debug_pagealloc_enabled() is enabled or not. So, remove
redundant check and optional vunmap_page_range() routines.


vunmap_page_range() tears down the page table entries and does
not really flush related TLB entries normally unless page alloc
debug is enabled where it wants to make sure no stale mapping is
still around for debug purpose. Deferring TLB flush improves
performance. This patch will force TLB flush during each page
table tear down and hence not desirable.


Deferred TLB invalidation will surely improve performance. But force
flush can help in detecting invalid access right then and there. I


Deferred TLB invalidation was a choice made some time ago with the
commit db64fe02258f1507e ("mm: rewrite vmap layer") as these vmalloc
mappings wont be used other than inside the kernel and TLB gets
flushed when they are reused. This way it can still avail the benefit
of deferred TLB flushing without exposing itself to invalid accesses.


chose later. May be I should have clean up the vmap tear down code
as well where it actually does the TLB invalidation.

Or make TLB invalidation in free_unmap_vmap_area() be dependent upon
debug_pagealloc_enabled().


Immediate TLB invalidation needs to be dependent on debug_pagealloc_
enabled() and should be done only for debug purpose. Contrary to that
is not desirable.


Okay. I will raise v2 for that.

Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

Re: [PATCH] sound: soc: intel: bxt_da7219_max98357a: Replace GFP_ATOMIC with GFP_KERNEL in broxton_audio_probe

[Mark Brown]

On Mon, Apr 09, 2018 at 06:46:21PM +0800, Jia-Ju Bai wrote:
> broxton_audio_probe() is never called in atomic context.
> This function is only set as ".probe" in "struct platform_driver".

Please submit patches using subject lines reflecting the style for the
subsystem.  This makes it easier for people to identify relevant
patches.  Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.


signature.asc
Description: PGP signature

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Bartlomiej Zolnierkiewicz]

On Friday, April 13, 2018 12:30:04 PM Daniel Lezcano wrote:
> On 13/04/2018 11:28, Bartlomiej Zolnierkiewicz wrote:
> 
> [ ... ]
> 
> >>> It is okay to return 0 because this code-path (the default one) will be
> >>> never hit by the driver (probe makes sure of it) - the default case is
> >>> here is just to silence compilation errors..
> >>
> >> The init function is making sure cal_type is one or another. Can you fix
> >> it correctly by replacing the 'switch' by a 'if' instead of adding dead
> >> branches to please gcc?
> >>
> >> if (data->cal_type == TYPE_TWO_POINT_TRIMMING) {
> >>return ...;
> >> }
> >>
> >> return ...;
> > 
> > I'm not the one that added this switch statement (it has been there since
> > 2011) and I would be happy to remove it. 
> 
> Actually the switch statement was fine until the cleanup.

I don't see how it was fine before as the driver has never used the default
case (always used TYPE_ONE_POINT_TRIMMING or TYPE_TWO_POINT_TRIMMING).

Could you please explain this more?

> > However could we please defer
> > this to v4.17 and merge the current set of Exynos thermal fixes/cleanups
> > (they simplify the driver a lot and make ground for future changes)?
> 
> Regarding the latest comment, this can be fixed properly by 'return' (or
> whatever you want which does not get around of gcc warnings).

Do you mean that you want the patch with switch statement removal?

Is incremental fix OK or do you want something else?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH] mm: vmalloc: Remove double execution of vunmap_page_range

[Anshuman Khandual]

On 04/13/2018 03:47 PM, Chintan Pandya wrote:
> 
> 
> On 4/13/2018 3:29 PM, Anshuman Khandual wrote:
>> On 04/13/2018 02:46 PM, Chintan Pandya wrote:
>>> Unmap legs do call vunmap_page_range() irrespective of
>>> debug_pagealloc_enabled() is enabled or not. So, remove
>>> redundant check and optional vunmap_page_range() routines.
>>
>> vunmap_page_range() tears down the page table entries and does
>> not really flush related TLB entries normally unless page alloc
>> debug is enabled where it wants to make sure no stale mapping is
>> still around for debug purpose. Deferring TLB flush improves
>> performance. This patch will force TLB flush during each page
>> table tear down and hence not desirable.
>>
> Deferred TLB invalidation will surely improve performance. But force
> flush can help in detecting invalid access right then and there. I

Deferred TLB invalidation was a choice made some time ago with the
commit db64fe02258f1507e ("mm: rewrite vmap layer") as these vmalloc
mappings wont be used other than inside the kernel and TLB gets
flushed when they are reused. This way it can still avail the benefit
of deferred TLB flushing without exposing itself to invalid accesses.

> chose later. May be I should have clean up the vmap tear down code
> as well where it actually does the TLB invalidation.
> 
> Or make TLB invalidation in free_unmap_vmap_area() be dependent upon
> debug_pagealloc_enabled().

Immediate TLB invalidation needs to be dependent on debug_pagealloc_
enabled() and should be done only for debug purpose. Contrary to that
is not desirable.

Re: [PATCH v2 2/2] dmaengine: stm32-mdma: Fix incomplete Hw descriptors allocator

[Geert Uytterhoeven]

Hi Vinod,

On Fri, Apr 13, 2018 at 12:09 PM, Vinod Koul  wrote:
> On Fri, Apr 13, 2018 at 10:39:48AM +0200, Geert Uytterhoeven wrote:
>> On Fri, Apr 13, 2018 at 6:02 AM, Vinod Koul  wrote:
>> > On Wed, Apr 11, 2018 at 04:44:39PM +0200, Pierre-Yves MORDRET wrote:
>> >
>> >>  struct stm32_mdma_desc {
>> >>   struct virt_dma_desc vdesc;
>> >>   u32 ccr;
>> >> - struct stm32_mdma_hwdesc *hwdesc;
>> >> - dma_addr_t hwdesc_phys;
>> >>   bool cyclic;
>> >>   u32 count;
>> >> + struct stm32_mdma_desc_node node[];
>> >
>> > some ppl use node[0] for this but i think either is fine..
>>
>> node[] is the correct one, node[0] may hide future bugs, cfr. commit
>> a158531f3c92467d ("gpio: 74x164: Fix crash during .remove()")
>
> Yeah but it this case it is the last element. But yes it helps to avoid such
> mistakes in future..

It was the last element in 74x164, too. Unless someone changed that.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] powerpc/sparse: fix plain integer as NULL pointer warning

[kbuild test robot]

Hi Mathieu,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on powerpc/next]
[also build test WARNING on v4.16 next-20180413]
[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/Mathieu-Malaterre/powerpc-sparse-fix-plain-integer-as-NULL-pointer-warning/20180413-144954
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/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=powerpc 

All warnings (new ones prefixed by >>):

   drivers/macintosh/via-pmu.c: In function 'pmu_present':
>> drivers/macintosh/via-pmu.c:1752:9: warning: return makes integer from 
>> pointer without a cast [-Wint-conversion]
 return via;
^~~

vim +1752 drivers/macintosh/via-pmu.c

  1748  
  1749  int
  1750  pmu_present(void)
  1751  {
> 1752  return via;
  1753  }
  1754  

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


.config.gz
Description: application/gzip

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Daniel Lezcano]

On 13/04/2018 11:28, Bartlomiej Zolnierkiewicz wrote:

[ ... ]

>>> It is okay to return 0 because this code-path (the default one) will be
>>> never hit by the driver (probe makes sure of it) - the default case is
>>> here is just to silence compilation errors..
>>
>> The init function is making sure cal_type is one or another. Can you fix
>> it correctly by replacing the 'switch' by a 'if' instead of adding dead
>> branches to please gcc?
>>
>> if (data->cal_type == TYPE_TWO_POINT_TRIMMING) {
>>  return ...;
>> }
>>
>> return ...;
> 
> I'm not the one that added this switch statement (it has been there since
> 2011) and I would be happy to remove it. 

Actually the switch statement was fine until the cleanup.

> However could we please defer
> this to v4.17 and merge the current set of Exynos thermal fixes/cleanups
> (they simplify the driver a lot and make ground for future changes)?

Regarding the latest comment, this can be fixed properly by 'return' (or
whatever you want which does not get around of gcc warnings).

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Bartlomiej Zolnierkiewicz]

On Friday, April 13, 2018 03:08:03 AM Eduardo Valentin wrote:
> On Fri, Apr 13, 2018 at 01:39:05PM +0800, Zhang Rui wrote:
> > Hi, Eduardo,
> > 
> > On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> > > Hello,
> > > 
> > > On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > > > 
> > > > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
> > > > wrote:
> > > > > 
> > > > > 
> > > > > could you please illustrate me what the kconfig & warning is?
> > > > Just "make allmodconfig" and the warning is about a uninitialized
> > > > variable.
> > > > 
> > > > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > > > history
> > > > is to be believed.
> > > > 
> > > > Linus
> > > Yeah, this has also passed my local compilation error. Somehow my
> > > gcc4.9
> > > is not catching it. Using an older gcc (gcc4.6) does catch it.
> > > 
> > > Anyways, given that the conversion functions are written to cover
> > > for unexpected cal_type, the right way of fixing this is to rewrite
> > > the conversion functions to allow for returning error codes and
> > > adjusting the callers as expected.
> > > 
> > > Rui, bzolnier, please consider the following fix:
> > > 
> > as it is late in this merge window, I'd prefer to
> > 1. drop all the thermal-soc material in the first pull request which I
> > will send out soon.
> > 2. you can prepare another pull request containing the thermal-soc
> > materials except the exynos fixes
> > 3. exynos fixes with the problem solved can be queued for -rc2 or
> > later.
> > 
> 
> Agreed

What should I do now to help resolve the issue?

[ There has been no action from you on Arnd's fix for over two weeks and
  also you have not commented on it now.. ]

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Eduardo Valentin]

On Fri, Apr 13, 2018 at 03:08:03AM -0700, Eduardo Valentin wrote:
> On Fri, Apr 13, 2018 at 01:39:05PM +0800, Zhang Rui wrote:
> > Hi, Eduardo,
> > 
> > On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> > > Hello,
> > > 
> > > On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > > > 
> > > > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
> > > > wrote:
> > > > > 
> > > > > 
> > > > > could you please illustrate me what the kconfig & warning is?
> > > > Just "make allmodconfig" and the warning is about a uninitialized
> > > > variable.
> > > > 
> > > > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > > > history
> > > > is to be believed.
> > > > 
> > > > Linus
> > > Yeah, this has also passed my local compilation error. Somehow my
> > > gcc4.9
> > > is not catching it. Using an older gcc (gcc4.6) does catch it.
> > > 
> > > Anyways, given that the conversion functions are written to cover
> > > for unexpected cal_type, the right way of fixing this is to rewrite
> > > the conversion functions to allow for returning error codes and
> > > adjusting the callers as expected.
> > > 
> > > Rui, bzolnier, please consider the following fix:
> > > 
> > as it is late in this merge window, I'd prefer to
> > 1. drop all the thermal-soc material in the first pull request which I
> > will send out soon.
> > 2. you can prepare another pull request containing the thermal-soc
> > materials except the exynos fixes

Sent you this
https://marc.info/?l=linux-pm&m=152361492711499&w=2

> > 3. exynos fixes with the problem solved can be queued for -rc2 or
> > later.

I see there is still some discussion around the topic of how to fix
this. So, once we get to a point of agreement, I will send the remaining
with exynos fixes.

> > 
> 
> Agreed
> 

Re: [PATCH 1/7] sched/core: uclamp: add CPU clamp groups accounting

[Peter Zijlstra]

On Fri, Apr 13, 2018 at 10:26:48AM +0200, Peter Zijlstra wrote:
> On Mon, Apr 09, 2018 at 05:56:09PM +0100, Patrick Bellasi wrote:
> > +static inline void uclamp_cpu_get(struct task_struct *p, int cpu, int 
> > clamp_id)
> > +{
> > +   struct uclamp_cpu *uc_cpu = &cpu_rq(cpu)->uclamp[clamp_id];
> 
> > +static inline void uclamp_cpu_put(struct task_struct *p, int cpu, int 
> > clamp_id)
> > +{
> > +   struct uclamp_cpu *uc_cpu = &cpu_rq(cpu)->uclamp[clamp_id];
> 
> That all seems daft, since you already have rq at the call site.
> 
> > +static inline void uclamp_task_update(struct rq *rq, struct task_struct *p)
> > +{
> > +   int cpu = cpu_of(rq);
> > +   int clamp_id;
> > +
> > +   /* The idle task does not affect CPU's clamps */
> > +   if (unlikely(p->sched_class == &idle_sched_class))
> > +   return;
> > +   /* DEADLINE tasks do not affect CPU's clamps */
> > +   if (unlikely(p->sched_class == &dl_sched_class))
> > +   return;
> 
> This is wrong; it misses the stop_sched_class.
> 
> And since you're looking at sched_class anyway, maybe put a marker in
> there:
> 
>   if (!p->sched_class->has_clamping)
>   return;

Alternatively, we could simply add uclamp_task_{en,de}queue() into
{en,de}queue_task_{fair,rt}().

> > +   for (clamp_id = 0; clamp_id < UCLAMP_CNT; ++clamp_id) {
> > +   if (uclamp_task_affects(p, clamp_id))
> > +   uclamp_cpu_put(p, cpu, clamp_id);
> > +   else
> > +   uclamp_cpu_get(p, cpu, clamp_id);
> > +   }
> > +}

[GIT PULL V2] Thermal SoC management updates for v4.17-rc1

[Eduardo Valentin]

Hello Rui,

Please find thermal-soc changes for v4.17-rc1 as follows.

- New i.MX7 thermal sensor
- Mediatek driver now supports MT7622 SoC
- Removal of min max cpu cooling dt property

Differences in V2:
- Reordered the patches to drop exynos changes for now until we get
agreement on the fix on that driver for the compilation warns
caused by the confusing conversion functions.

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

  Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus

for you to fetch changes up to 82709e9467829e4e0dbcc6a0dd6fb01901d3f45b:

  dt-bindings: thermal: Remove "cooling-{min|max}-level" properties (2018-04-13 
03:05:35 -0700)


Anson Huang (1):
  thermal: imx: add i.MX7 thermal sensor support

Bartlomiej Zolnierkiewicz (1):
  dt-bindings: thermal: remove no longer needed samsung thermal properties

Sean Wang (2):
  dt-bindings: thermal: add binding for MT7622 SoC
  thermal: mediatek: add support for MT7622 SoC

Viresh Kumar (1):
  dt-bindings: thermal: Remove "cooling-{min|max}-level" properties

 .../devicetree/bindings/thermal/exynos-thermal.txt |  23 +-
 .../devicetree/bindings/thermal/imx-thermal.txt|   9 +-
 .../bindings/thermal/mediatek-thermal.txt  |   1 +
 .../devicetree/bindings/thermal/thermal.txt|  16 +-
 drivers/thermal/imx_thermal.c  | 295 -
 drivers/thermal/mtk_thermal.c  |  35 +++
 6 files changed, 281 insertions(+), 98 deletions(-)

Re: [PATCH] mm: vmalloc: Remove double execution of vunmap_page_range

[Chintan Pandya]

On 4/13/2018 3:29 PM, Anshuman Khandual wrote:

On 04/13/2018 02:46 PM, Chintan Pandya wrote:

Unmap legs do call vunmap_page_range() irrespective of
debug_pagealloc_enabled() is enabled or not. So, remove
redundant check and optional vunmap_page_range() routines.


vunmap_page_range() tears down the page table entries and does
not really flush related TLB entries normally unless page alloc
debug is enabled where it wants to make sure no stale mapping is
still around for debug purpose. Deferring TLB flush improves
performance. This patch will force TLB flush during each page
table tear down and hence not desirable.


Deferred TLB invalidation will surely improve performance. But force
flush can help in detecting invalid access right then and there. I
chose later. May be I should have clean up the vmap tear down code
as well where it actually does the TLB invalidation.

Or make TLB invalidation in free_unmap_vmap_area() be dependent upon
debug_pagealloc_enabled().

Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Eduardo Valentin]

On Fri, Apr 13, 2018 at 01:39:05PM +0800, Zhang Rui wrote:
> Hi, Eduardo,
> 
> On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> > Hello,
> > 
> > On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > > 
> > > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
> > > wrote:
> > > > 
> > > > 
> > > > could you please illustrate me what the kconfig & warning is?
> > > Just "make allmodconfig" and the warning is about a uninitialized
> > > variable.
> > > 
> > > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > > history
> > > is to be believed.
> > > 
> > > Linus
> > Yeah, this has also passed my local compilation error. Somehow my
> > gcc4.9
> > is not catching it. Using an older gcc (gcc4.6) does catch it.
> > 
> > Anyways, given that the conversion functions are written to cover
> > for unexpected cal_type, the right way of fixing this is to rewrite
> > the conversion functions to allow for returning error codes and
> > adjusting the callers as expected.
> > 
> > Rui, bzolnier, please consider the following fix:
> > 
> as it is late in this merge window, I'd prefer to
> 1. drop all the thermal-soc material in the first pull request which I
> will send out soon.
> 2. you can prepare another pull request containing the thermal-soc
> materials except the exynos fixes
> 3. exynos fixes with the problem solved can be queued for -rc2 or
> later.
> 

Agreed

Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration

[Vinod Koul]

On Fri, Apr 13, 2018 at 02:41:48PM +0800, Baolin Wang wrote:
> On 13 April 2018 at 14:36, Vinod Koul  wrote:
> > On Fri, Apr 13, 2018 at 02:17:34PM +0800, Baolin Wang wrote:
> >
> >> > Agreed, users only care about grabbing a channel, setting a descriptor 
> >> > and
> >> > submitting that.
> >> >
> >> > I think you need to go back and think about this a bit, please do go thru
> >> > dmaengine documentation and see other driver examples.
> >> >
> >> > We don't typically expose these to users, they give us a transfer and we 
> >> > set
> >> > that up in hardware for efficient. Its DMA so people expect us to use 
> >> > fastest
> >> > mechanism available.
> >>
> >> But there are some configuration are really special for Spreadtrum
> >> DMA, and must need user to specify how to configure, especially some
> >> scenarios of audio. So I wander if we can add one pointer for
> >> 'dma_slave_config' to expand some special DMA configuration
> >> requirements, like:
> >>
> >> struct dma_slave_config {
> >> ..
> >> unsigned int slave_id;
> >> void *platform_data;
> >> };
> >>
> >> So if some DMA has some special configuration (such as Spreadtrum
> >> DMA), they can user this platform_data pointer. Like xilinx DMA, they
> >> also have some special configuration.
> >
> > Well we all think our HW is special and needs some additional stuff, most of
> > the cases turns out not to be the case.
> >
> > Can you explain how audio in this case additional configuration...
> >
> 
> Beside the general configuration, our audio driver will configure the
> fragment length, block length, maybe transaction length, and they must
> specify the request type and interrupt type, these are what we want to
> export for users.

First doesn't it use sound dmaengine library, it should :)

Second, I think you should calculate the lengths based on given input. Audio
is circular buffer so you shall create a circular linked list and submit.
See how other driver implement circular prepare callback

-- 
~Vinod

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Auger Eric]

Hi Philipp,

On 13/04/18 11:22, Philipp Zabel wrote:
[..]
> That also means it is impossible to use just one of the devices that
> share a reset line for vfio individually, while the other ones are still
> in use by the host. Currently the reset line is a shared resource
> similar to the iommu for devices in the same iommu_group.
> 
> Is there any mechanism in vfio that would allow modeling other shared
> resources apart from iommu?

No we only check the VFIO group viability at IOMMU level.
> 
> [...]
>>> For some of those it may be possible, but that is basically just a work-
>>> around for reality not matching expectations. There may be other cases
>>> where devices sharing a reset line are not even in the same parent node
>>> because they are controlled via a different bus. In general, I don't
>>> think it is feasible or desirable to force grouping of devices that
>>> share the same reset line into a common parent node.
>>
>> At least for Renesas R-Car SoCs, I think this is feasible, as all affected
>> devices are currently grouped under the same /soc node.
>> I added subnodes for all devices sharing resets (one for pwm, 4 for USB2,
>> and one for USB3; display doesn't have resets yet), and it still boots ;-)
> 
> Is this grouping enough to make sure all of the pwm/usb2/usb3 devices
> are only ever configured for vfio use together?
> 
> Assuming I have pwm[1-4] all sharing the same reset line, and I want
> pwm2 to be used by a vfio guest, I first have to make sure that all of
> pwm[1-4] are unbound, releasing their shared resets, before vfio-
> platform can request the same reset line as exclusive.
> 
> Thinking about it, if the pwm drivers keep their requested reset control
> around for the duration the device is bound, the reset controller
> framework should already kind of handle this - while any of the shared
> reset control handles is kept around, any exclusive request for the same
> reset control will fail with -EBUSY (and the other way around).
> But that requires all drivers to request the reset control during probe
> and release it during remove.
> 
>> However, ehci_platform_probe() cannot get its (optional) resets anymore.
>> Probably the reset controller framework needs to be taught to look for
>> shared resets in the parent node, too?
> 
> Hm, a generic framework shouldn't do such a thing, the parent node could
> be covered by a completely different binding.
> 
>>> My suggestion would be to relax the language in the reset.txt DT
>>> bindings doc.
>>
>> Which is fine to keep the status quo with the hardware designers, but makes
>> it less likely for non-whitelisted generic reset controller support to
>> become acceptable for the vfio people...
> 
> I still may be missing context, but I fail to see how
> 
>   pwm@0 {
>   resets = <&shared_reset_control>;
>   };
> 
>   pwm@1 {
>   resets = <&shared_reset_control>;
>   };
> 
> ->
> 
>   pwms {
>   resets = <&shared_reset_control>;
> 
>   pwm@0 {
>   };
> 
>   pwm@1 {
>   };
>   };
> 
> makes any difference here, unless pwms gets bound to an actual driver
> that is used for vfio?

I don't think we are ready to assign pwms with VFIO as Alex emphasized
VFIO was meant to be used with IOMMU and I guess those devices do not
belong to any iommu group.

Thanks

Eric
> 
> regards
> Philipp
> 

Re: [PATCH 0/2] tools/memory-model: Model 'smp_store_mb()'

[Andrea Parri]

On Thu, Apr 12, 2018 at 02:06:27PM -0700, Paul E. McKenney wrote:
> On Thu, Apr 12, 2018 at 02:22:48PM +0200, Andrea Parri wrote:
> > Hi,
> > 
> > This (tiny) series adds 'smp_store_mb()' to the model (patch 1/2), and
> > it fixes a stylistic discrepancy in 'linux-kernel.def (patch 2/2).
> 
> I applied them both, thank you!
> 
> I had to apply 2/2 by hand for reasons that are not at all clear to
> me.  Please check to make sure I got it right.

It's OK for me.  Thanks,

  Andrea


> 
>   Thanx, Paul
> 
> > Cheers,
> >   Andrea
> > 
> > Andrea Parri (2):
> >   tools/memory-model: Model 'smp_store_mb()'
> >   tools/memory-model: Fix coding style in 'linux-kernel.def'
> > 
> >  tools/memory-model/linux-kernel.def | 29 +++--
> >  1 file changed, 15 insertions(+), 14 deletions(-)
> > 
> > -- 
> > 2.7.4
> > 
> 

Re: [PATCH v2 2/2] dmaengine: stm32-mdma: Fix incomplete Hw descriptors allocator

[Vinod Koul]

On Fri, Apr 13, 2018 at 10:39:48AM +0200, Geert Uytterhoeven wrote:
> Hi Vinod,
> 
> On Fri, Apr 13, 2018 at 6:02 AM, Vinod Koul  wrote:
> > On Wed, Apr 11, 2018 at 04:44:39PM +0200, Pierre-Yves MORDRET wrote:
> >
> >>  struct stm32_mdma_desc {
> >>   struct virt_dma_desc vdesc;
> >>   u32 ccr;
> >> - struct stm32_mdma_hwdesc *hwdesc;
> >> - dma_addr_t hwdesc_phys;
> >>   bool cyclic;
> >>   u32 count;
> >> + struct stm32_mdma_desc_node node[];
> >
> > some ppl use node[0] for this but i think either is fine..
> 
> node[] is the correct one, node[0] may hide future bugs, cfr. commit
> a158531f3c92467d ("gpio: 74x164: Fix crash during .remove()")

Yeah but it this case it is the last element. But yes it helps to avoid such
mistakes in future..

-- 
~Vinod

Re: WARNING: bad unlock balance in xfs_iunlock

[Dmitry Vyukov]

On Fri, Apr 6, 2018 at 6:10 PM, Darrick J. Wong  wrote:
> On Fri, Apr 06, 2018 at 07:38:44AM +1000, Dave Chinner wrote:
>> On Thu, Apr 05, 2018 at 08:54:50PM +0200, Dmitry Vyukov wrote:
>> > On Tue, Apr 3, 2018 at 6:38 AM, Dave Chinner  wrote:
>> > > On Mon, Apr 02, 2018 at 07:01:02PM -0700, syzbot wrote:
>> > >> Hello,
>> > >>
>> > >> syzbot hit the following crash on upstream commit
>> > >> 86bbbebac1933e6e95e8234c4f7d220c5ddd38bc (Mon Apr 2 18:47:07 2018 +)
>> > >> Merge branch 'ras-core-for-linus' of
>> > >> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>> > >> syzbot dashboard link:
>> > >> https://syzkaller.appspot.com/bug?extid=84a67953651a971809ba
>> > >>
>> > >> C reproducer: 
>> > >> https://syzkaller.appspot.com/x/repro.c?id=5719304272084992
>> > >> syzkaller reproducer:
>> > >> https://syzkaller.appspot.com/x/repro.syz?id=5767783983874048
>> > >
>> > > What a mess. A hand built, hopelessly broken filesystem image made
>> > > up of hex dumps, written into a mmap()d region of memory, then
>> > > copied into a tmpfs file and mounted with the loop device.
>> > >
>> > > Engineers that can debug broken filesystems don't grow on trees.  If
>> > > we are to have any hope of understanding what the hell this test is
>> > > doing, the bot needs to supply us with a copy of the built
>> > > filesystem image the test uses. We need to be able to point forensic
>> > > tools at the image to decode all the structures into human readable
>> > > format - if we are forced to do that by hand or jump through hoops
>> > > to create our own filesystem image than I'm certainly not going to
>> > > waste time looking at these reports...
>> >
>> > Hi Dave,
>> >
>> > Here is the image:
>> > https://drive.google.com/file/d/1jzhGGe5SBJcqfsjxCLHoh4Kazke1oTfC/view
>> > (took me about a minute to extract from test by replacing memfd_create
>> > with open and running the program).
>>
>> Says the expert who knows exactly how it's all put together. It took
>> me a couple of hours just to understand WTF the syzbot reproducer
>> was actually doing
>>
>> > Then do the following to trigger the bug:
>> > losetup /dev/loop0 xfs.repro
>> > mkdir xfs
>> > mount -t xfs -o nouuid,prjquota,noikeep,quota /dev/loop0 xfs
>> >
>> > To answer your more general question: syzbot is not a system to test
>> > solely file systems, it finds bugs in hundreds of kernel subsystems.
>> > Generating image for file systems, media files for sound and
>> > FaceDancer programs that crash host when  FaceDancer device is plugged
>> > into USB is not feasible. And in the end it's not even clear what
>>
>> I don't care how syzbot generates the filesystem image it uses.
>>
>> > kernel subsystem is at fault and even if it somehow figures out that
>> > it's a filesystem, it's unclear that it's exactly an image that
>> > provokes the bug. syzbot provides C reproducers which is a reasonable
>>
>> It doesn't matter *what subsystem breaks*. If syzbot is generating a
>> filesystem image and then mounting it, it needs to provide that
>> filesystem image to to people who end up having to debug the
>> problem. It's a basic "corrupt filesystem" bug triage step.
>>
>> > Some bugs are so involved that only an
>> > expert in a particular subsystem can figure out what happens there.
>>
>> And that's clearly the case here, whether you like it or not.
>>
>> You want us to do things that make syzbot more useful as a tool but
>> you don't want to do things that make syzbot a useful tool for us.
>> It's a two way street

Hi Dave, Darrick,

It's not that we don't want to make the system more useful, it's just
that we don't see what reasonably can be done here. The system does
not have notion of images, sound files, USB devices. It feeds data
into system calls, and that's what it provides as reproducers. Also
see the last paragraph.

> ...here's my take on this whole situation:
>
> So far as I can tell, this syzbot daemon grew the ability to fuzz
> filesystems and started emitting bug report after bug report, with
> misleading commit ids that have nothing to do with the complaint.

Please elaborate re commits. It's a basic rule of any good bug report
-- communicate exact state of source code when the bug was hit, i.e.
provide the commit hash.

>  Your
> maintainers (Dave, Eric, and me) have spent a few hours trying to figure
> out what's going on, to some frustration.  The bug reports themselves
> miss the public engagement detail of saying something like "Hey XFS
> engineers, if you'd like to talk to the syzbot engineers they can be
> reached at ."  Instead it merely says "direct
> questions to " like this is some press release and the only thing
> on the other end of the line will be some disinterested bureaucracy.
> Or some robot.

This is quite subjective and we hear opinions all possible ways. I
don't think there is one size fits all. E.g. +Ted argued in exactly
the opposite direction: make reports more laconic, formal,
table-formatted with dry information. There 

Re: [PATCH] mm: vmalloc: Remove double execution of vunmap_page_range

[Anshuman Khandual]

On 04/13/2018 02:46 PM, Chintan Pandya wrote:
> Unmap legs do call vunmap_page_range() irrespective of
> debug_pagealloc_enabled() is enabled or not. So, remove
> redundant check and optional vunmap_page_range() routines.

vunmap_page_range() tears down the page table entries and does
not really flush related TLB entries normally unless page alloc
debug is enabled where it wants to make sure no stale mapping is
still around for debug purpose. Deferring TLB flush improves
performance. This patch will force TLB flush during each page
table tear down and hence not desirable.

Re: [PATCH] memory-model: fix cheat sheet typo

[Andrea Parri]

On Thu, Apr 12, 2018 at 02:18:36PM -0700, Paul E. McKenney wrote:
> On Thu, Apr 12, 2018 at 01:21:55PM +0200, Andrea Parri wrote:
> > 
> > The litmus test that first comes to my mind when I think of cumulativity
> > (at least, 'cumulativity' as intended in LKMM) is:
> > 
> >WRC+pooncerelease+rmbonceonce+Once.litmus
> 
> Removing the "cumul-fence* ;" from "let prop" does cause this test to be
> allowed, so looks plausible.
> 
> > for 'propagation', I could mention:
> > 
> >IRIW+mbonceonces+OnceOnce.litmus
> 
> And removing the "acyclic pb as propagation" causes this one to be allowed,
> so again plausible.
> 
> > (both tests are availabe in tools/memory-model/litmus-tests/). It would
> > be a nice to mention these properties in the test descriptions, indeed.
> 
> Please see below.

Matching what I had in mind ;) thanks!

  Andrea


> 
>   Thanx, Paul
> 
> > You might find it useful to also visualize the 'valid' executions (with
> > the main events/relations) associated to each of these tests; for this,
> > 
> >$ herd7 -conf linux-kernel.cfg litmus-tests/your-test.litmus \
> > -show all -gv
> > 
> > (assuming you have 'gv' installed).
> 
> 
> 
> commit 494f11d10dd7d86e4a381cbe79e77f04cb0cee04
> Author: Paul E. McKenney 
> Date:   Thu Apr 12 14:15:57 2018 -0700
> 
> EXP tools/memory-model: Flag "cumulativity" and "propagation" tests
> 
> This commit flags WRC+pooncerelease+rmbonceonce+Once.litmus as being
> forbidden by LKMM cumulativity and IRIW+mbonceonces+OnceOnce.litmus as
> being forbidden by LKMM propagation.
> 
> Suggested-by: Andrea Parri 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus 
> b/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
> index 50d5db9ea983..98a3716efa37 100644
> --- a/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
> +++ b/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
> @@ -7,7 +7,7 @@ C IRIW+mbonceonces+OnceOnce
>   * between each pairs of reads.  In other words, is smp_mb() sufficient to
>   * cause two different reading processes to agree on the order of a pair
>   * of writes, where each write is to a different variable by a different
> - * process?
> + * process?  This litmus test exercises LKMM's "propagation" rule.
>   *)
>  
>  {}
> diff --git a/tools/memory-model/litmus-tests/README 
> b/tools/memory-model/litmus-tests/README
> index 6919909bbd0f..178941d2a51a 100644
> --- a/tools/memory-model/litmus-tests/README
> +++ b/tools/memory-model/litmus-tests/README
> @@ -23,7 +23,8 @@ IRIW+mbonceonces+OnceOnce.litmus
>   between each pairs of reads.  In other words, is smp_mb()
>   sufficient to cause two different reading processes to agree on
>   the order of a pair of writes, where each write is to a different
> - variable by a different process?
> + variable by a different process?  This litmus test is an example
> + that is forbidden by LKMM propagation.
>  
>  IRIW+poonceonces+OnceOnce.litmus
>   Test of independent reads from independent writes with nothing
> @@ -121,6 +122,7 @@ WRC+poonceonces+Once.litmus
>  WRC+pooncerelease+rmbonceonce+Once.litmus
>   These two are members of an extension of the MP litmus-test class
>   in which the first write is moved to a separate process.
> + The second is an example that is forbidden by LKMM cumulativity.
>  
>  Z6.0+pooncelock+pooncelock+pombonce.litmus
>   Is the ordering provided by a spin_unlock() and a subsequent
> diff --git 
> a/tools/memory-model/litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus 
> b/tools/memory-model/litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus
> index 97fcbffde9a0..5bda4784eb34 100644
> --- 
> a/tools/memory-model/litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus
> +++ 
> b/tools/memory-model/litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus
> @@ -5,7 +5,8 @@ C WRC+pooncerelease+rmbonceonce+Once
>   *
>   * This litmus test is an extension of the message-passing pattern, where
>   * the first write is moved to a separate process.  Because it features
> - * a release and a read memory barrier, it should be forbidden.
> + * a release and a read memory barrier, it should be forbidden.  This
> + * litmus test exercises LKMM cumulativity.
>   *)
>  
>  {}
> 

[PATCH] x86/tsc: fix 64bit divisor be truncated in calc_hpet_ref

[Xiaoming Gao]

From ba3d2fb699c4d8ee61b05d7e70be48b9c4e22baf Mon Sep 17 00:00:00 2001
From: Xiaoming Gao 
Date: Fri, 13 Apr 2018 17:05:18 +0800
Subject: [PATCH] x86/tsc: fix 64bit divisor be truncated in calc_hpet_ref

the HPET frequency got larger on intel skylake, thus could cause tmp to
exceed 32bits.
do_div will truncate 64bits tmp to 32bits, so the frequency calced via
HPET will be wrong, use div64_u64 can fix it.

Signed-off-by: Xiaoming Gao 
---
 arch/x86/kernel/tsc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 9714a7a..8700269 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -160,7 +160,7 @@ static unsigned long calc_hpet_ref(u64 deltatsc, u64 
hpet1, u64 hpet2)

 hpet2 -= hpet1;
 tmp = ((u64)hpet2 * hpet_readl(HPET_PERIOD));
 do_div(tmp, 100);
-    do_div(deltatsc, tmp);
+    deltatsc = div64_u64(deltatsc, tmp);

 return (unsigned long) deltatsc;
 }
--
1.7.1


From ba3d2fb699c4d8ee61b05d7e70be48b9c4e22baf Mon Sep 17 00:00:00 2001
From: Xiaoming Gao 
Date: Fri, 13 Apr 2018 17:05:18 +0800
Subject: [PATCH] x86/tsc: fix 64bit divisor be truncated in calc_hpet_ref

the HPET frequency got larger on intel skylake, thus could cause tmp to
exceed 32bits.
do_div will truncate 64bits tmp to 32bits, so the frequency calced via
HPET will be wrong, use div64_u64 can fix it.

Signed-off-by: Xiaoming Gao 
---
 arch/x86/kernel/tsc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 9714a7a..8700269 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -160,7 +160,7 @@ static unsigned long calc_hpet_ref(u64 deltatsc, u64 hpet1, 
u64 hpet2)
hpet2 -= hpet1;
tmp = ((u64)hpet2 * hpet_readl(HPET_PERIOD));
do_div(tmp, 100);
-   do_div(deltatsc, tmp);
+   deltatsc = div64_u64(deltatsc, tmp);
 
return (unsigned long) deltatsc;
 }
-- 
1.7.1

Re: [PATCH v2 1/2] dmaengine: stm32-mdma: align TLEN and buffer length on burst

[Pierre Yves MORDRET]

Hi Robin

On 04/11/2018 05:14 PM, Robin Murphy wrote:
> On 11/04/18 15:44, Pierre-Yves MORDRET wrote:
>> Both buffer Transfer Length (TLEN if any) and transfer size have to be
>> aligned on burst size (burst beats*bus width).
>>
>> Signed-off-by: Pierre-Yves MORDRET 
>> ---
>>Version history:
>>  v1:
>> * Initial
>>  v2:
>> ---
>> ---
>>   drivers/dma/stm32-mdma.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/stm32-mdma.c b/drivers/dma/stm32-mdma.c
>> index daa1602..fbcffa2 100644
>> --- a/drivers/dma/stm32-mdma.c
>> +++ b/drivers/dma/stm32-mdma.c
>> @@ -413,7 +413,7 @@ static u32 stm32_mdma_get_best_burst(u32 buf_len, u32 
>> tlen, u32 max_burst,
>>  u32 best_burst = max_burst;
>>  u32 burst_len = best_burst * width;
>>   
>> -while ((burst_len > 0) && (tlen % burst_len)) {
>> +while ((burst_len > 0) && (((tlen | buf_len) & (burst_len - 1)) != 0)) {
>>  best_burst = best_burst >> 1;
>>  burst_len = best_burst * width;
>>  }
> 
> FWIW, doesn't that whole loop come down to just:
> 
>   burst_len = min(ffs(tlen | buf_len), max_burst * width);

No sure it ends as expected. or I miss something or don't understand this 
statement
I tried with "relevant value" : i.e. best_burst = 32, Tlen=128(default) and
buf_len = 64, width= 4. This statements gets me something wrong output => 7
instead of 16 * 4.
I doubt :)

> 
> ?
> 
> Robin.
> 

Re: [PATCH 1/7] sched/core: uclamp: add CPU clamp groups accounting

[Peter Zijlstra]

On Mon, Apr 09, 2018 at 05:56:09PM +0100, Patrick Bellasi wrote:
> +static inline void uclamp_cpu_get(struct task_struct *p, int cpu, int 
> clamp_id)
> +{
> + struct uclamp_cpu *uc_cpu = &cpu_rq(cpu)->uclamp[clamp_id];
> + int clamp_value;
> + int group_id;
> +
> + /* Get task's specific clamp value */
> + clamp_value = p->uclamp[clamp_id].value;
> + group_id = p->uclamp[clamp_id].group_id;
> +
> + /* No task specific clamp values: nothing to do */
> + if (group_id == UCLAMP_NONE)
> + return;
> +
> + /* Increment the current group_id */

That I think qualifies being called a bad comment.

> + uc_cpu->group[group_id].tasks += 1;
> +
> + /* Mark task as enqueued for this clamp index */
> + p->uclamp_group_id[clamp_id] = group_id;

Why exactly do we need this? we got group_id from @p in the first place.

I suspect this is because when we update p->uclamp[], we don't update
this active value (when needed), is that worth it?

> + /*
> +  * If this is the new max utilization clamp value, then we can update
> +  * straight away the CPU clamp value. Otherwise, the current CPU clamp
> +  * value is still valid and we are done.
> +  */
> + if (uc_cpu->value < clamp_value)
> + uc_cpu->value = clamp_value;
> +}

Re: [PATCH] vfio: platform: Fix using devices in PM Domains

[Auger Eric]

Hi Geert,

On 13/04/18 11:19, Geert Uytterhoeven wrote:
> Hi Eric,
> 
> On Fri, Apr 13, 2018 at 11:14 AM, Auger Eric  wrote:
>> On 11/04/18 11:24, Geert Uytterhoeven wrote:
>>> If a device is part of a PM Domain (e.g. power and/or clock domain), its
>>> power state is managed using Runtime PM.  Without Runtime PM, the device
>>> may not be powered up, causing subtle failures, crashes, or system
>>> lock-ups when the device is accessed by the guest.
>> the device may not be powered up/clcoked or power/clock may be switched
>> off while the guest uses it.
>>>
>>> Fix this by adding Runtime PM support, powering the device when the VFIO
>>> device is opened by the guest.
>>>
>>> Note that while more fine-grained power management could be implemented
>>> on the guest side, if exported, this would be inherently unsafe, as
>>> abusing it may kill the whole system.
>>
>> Please can you elaborate on this remark please?
> 
> If power-management of the device would be delegated to the guest, and the
> guest forgets to enable device power before accessing the device's registers,
> this could lock up the system, and thus disturb both the host and other 
> guests.
Wouldn't you need to assign another device or use para-virt to allow the
guest to perform this power management control? I think you can remove
this paragraph from the commit message.

Thanks

Eric
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

[Russell King - ARM Linux]

On Thu, Apr 12, 2018 at 10:22:15AM -0700, Linus Torvalds wrote:
> On Thu, Apr 12, 2018 at 10:20 AM, Russell King - ARM Linux
>  wrote:
> >
> > This file was created to contain FPE_FIXME, by the "signal/arm: Document
> > conflicts with SI_USER and SIGFPE" commit so if we're removing it, it
> > would be better to remove the whole file.
> 
> Fair enough. I'm not going to commit that anyway since I can't test
> it, but yes, if it tests ok that sounds like the right thing to do.

Yes, it does solve the problem at hand with strace - the exact patch I
tested against 4.16 is below.

Testing this exact code path (exceptions set to VFP_EXCEPTION_ERROR)
is something that can only happen if the hardware does something stupid,
and I don't have a way of making it do that, so the code path can't be
tested.

However, FPE_FLTUNK is not defined in older kernels, so while we can
fix it this way for the current merge window, that doesn't help 4.16.
How we solve that depends what happens with Eric's patch (266da65e9156
("signal: Add FPE_FLTUNK si_code for undiagnosable fp exceptions"))
that introduces FPE_FLTUNK - and there's also the problem of NSIGFPE,
which kernel/signal.c uses in the path that selects the siginfo layout.

Given that the path we're talking about is unlikely to happen (as
mentioned in my second paragraph) I still think reverting Eric's patch
is the right way forward for older kernels.

(Note, my previous comment about the si_code initialiser was incorrect.)

diff --git a/arch/arm/include/uapi/asm/siginfo.h 
b/arch/arm/include/uapi/asm/siginfo.h
deleted file mode 100644
index d0513880be21..
--- a/arch/arm/include/uapi/asm/siginfo.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef __ASM_SIGINFO_H
-#define __ASM_SIGINFO_H
-
-#include 
-
-/*
- * SIGFPE si_codes
- */
-#ifdef __KERNEL__
-#define FPE_FIXME  0   /* Broken dup of SI_USER */
-#endif /* __KERNEL__ */
-
-#endif
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 4c375e11ae95..8a1a5e6048d2 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -28,6 +28,10 @@
 #include 
 #include 
 
+#ifndef FPE_FLTUNK
+#define FPE_FLTUNK 14
+#endif
+
 #include "vfpinstr.h"
 #include "vfp.h"
 
@@ -257,7 +261,7 @@ static void vfp_raise_exceptions(u32 exceptions, u32 inst, 
u32 fpscr, struct pt_
 
if (exceptions == VFP_EXCEPTION_ERROR) {
vfp_panic("unhandled bounce", inst);
-   vfp_raise_sigfpe(FPE_FIXME, regs);
+   vfp_raise_sigfpe(FPE_FLTUNK, regs);
return;
}
 


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH 0/2] drm: Make it compilable without CONFIG_HDMI and CONFIG_I2C

[Thomas Huth]

By enabling the DRM code for virtio-gpu on S390, you currently also get
all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automatically.
This is quite ugly, since on S390, there is no HDMI and no I2C. Thus it
would be great if the DRM code could also be compiled without CONFIG_HDMI
and CONFIG_I2C. These two patches now refactor the DRM code a little bit
so that we can compile it also without CONFIG_HDMI and CONFIG_I2C.

Thomas Huth (2):
  drivers/gpu/drm: Move CONFIG_HDMI-dependent code to a separate file
  drivers/gpu/drm: Make the DRM code compilable without CONFIG_I2C

 drivers/gpu/drm/Kconfig |   6 +-
 drivers/gpu/drm/Makefile|  17 ++--
 drivers/gpu/drm/drm_crtc_internal.h |   2 +
 drivers/gpu/drm/drm_edid.c  | 173 ++
 drivers/gpu/drm/drm_hdmi.c  | 182 
 5 files changed, 206 insertions(+), 174 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_hdmi.c

-- 
1.8.3.1

[PATCH 2/2] drm: Make the DRM code compilable without CONFIG_I2C

[Thomas Huth]

Selecting CONFIG_HDMI for S390 is inappropriate - there is no real
graphic hardware on this architecture. The drm subsystem is only
enabled here for using the virtual graphics card "virtio-gpu". So
it should be possible to compile the drm subsystem also without
CONFIG_I2C. Tweak the Makefile to only compile the affected files
with CONFIG_I2C=y and disable some I2C-related code in drm_edid.c.

Signed-off-by: Thomas Huth 
---
 drivers/gpu/drm/Kconfig|  4 ++--
 drivers/gpu/drm/Makefile   | 16 +---
 drivers/gpu/drm/drm_edid.c | 10 +++---
 3 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 298a518..c9df67f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -10,8 +10,8 @@ menuconfig DRM
select DRM_PANEL_ORIENTATION_QUIRKS
select HDMI if !S390
select FB_CMDLINE
-   select I2C
-   select I2C_ALGOBIT
+   select I2C if !S390
+   select I2C_ALGOBIT if !S390
select DMA_SHARED_BUFFER
select SYNC_FILE
help
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 16fd8e3..4cf53ba 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -7,10 +7,9 @@ drm-y   := drm_auth.o drm_bufs.o drm_cache.o \
drm_context.o drm_dma.o \
drm_file.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o \
-   drm_scatter.o drm_pci.o \
+   drm_scatter.o drm_pci.o drm_info.o \
drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
-   drm_info.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
@@ -20,6 +19,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o
 
+drm-$(CONFIG_I2C) += drm_encoder_slave.o
 drm-$(CONFIG_HDMI) += drm_hdmi.o
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
@@ -32,11 +32,13 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 
-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
-   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
-   drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
-   drm_simple_kms_helper.o drm_modeset_helper.o \
-   drm_scdc_helper.o drm_gem_framebuffer_helper.o
+drm_kms_helper-y := drm_crtc_helper.o drm_probe_helper.o \
+   drm_plane_helper.o drm_atomic_helper.o \
+   drm_gem_framebuffer_helper.o drm_kms_helper_common.o \
+   drm_simple_kms_helper.o drm_modeset_helper.o
+
+drm_kms_helper-$(CONFIG_I2C) += drm_dp_helper.o drm_dp_mst_topology.o \
+   drm_dp_dual_mode_helper.o drm_scdc_helper.o
 
 drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3820763..0d0d5af 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1467,11 +1467,14 @@ bool drm_edid_is_valid(struct edid *edid)
 static int
 drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int block, size_t len)
 {
-   struct i2c_adapter *adapter = data;
-   unsigned char start = block * EDID_LENGTH;
unsigned char segment = block >> 1;
unsigned char xfers = segment ? 3 : 2;
-   int ret, retries = 5;
+   int ret = -1;
+
+#if IS_ENABLED(CONFIG_I2C)
+   struct i2c_adapter *adapter = data;
+   unsigned char start = block * EDID_LENGTH;
+   int retries = 5;
 
/*
 * The core I2C driver will automatically retry the transfer if the
@@ -1512,6 +1515,7 @@ bool drm_edid_is_valid(struct edid *edid)
break;
}
} while (ret != xfers && --retries);
+#endif /* CONFIG_I2C */
 
return ret == xfers ? 0 : -1;
 }
-- 
1.8.3.1

[PATCH] percpu_counter: Remove debug_object_free call twice

[Gaurav Kohli]

During percpu_counter destroy, debug_object_free is calling
twice which may create race. So removing once instance of call
from debug_percpu_counter_deactivate.

Signed-off-by: Gaurav Kohli 

diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index c72577e..68ad030 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -48,7 +48,6 @@ static inline void debug_percpu_counter_activate(struct 
percpu_counter *fbc)
 static inline void debug_percpu_counter_deactivate(struct percpu_counter *fbc)
 {
debug_object_deactivate(fbc, &percpu_counter_debug_descr);
-   debug_object_free(fbc, &percpu_counter_debug_descr);
 }
 
 #else  /* CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER */
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH 1/2] drm: Move CONFIG_HDMI-dependent code to a separate file

[Thomas Huth]

Selecting CONFIG_HDMI for S390 is inappropriate - there is no real
graphic hardware on this architecture. The drm subsystem is only
enabled here for using the virtual graphics card "virtio-gpu". So
it should be possible to compile the drm subsystem also without
CONFIG_DRM. Let's move the related code to a separate file for this.

Signed-off-by: Thomas Huth 
---
 drivers/gpu/drm/Kconfig |   2 +-
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm_crtc_internal.h |   2 +
 drivers/gpu/drm/drm_edid.c  | 163 +---
 drivers/gpu/drm/drm_hdmi.c  | 182 
 5 files changed, 188 insertions(+), 162 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_hdmi.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index deeefa7..298a518 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -8,7 +8,7 @@ menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
support)"
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
select DRM_PANEL_ORIENTATION_QUIRKS
-   select HDMI
+   select HDMI if !S390
select FB_CMDLINE
select I2C
select I2C_ALGOBIT
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff..16fd8e3 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -20,6 +20,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o
 
+drm-$(CONFIG_HDMI) += drm_hdmi.o
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 3c2b828..0804348 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -220,3 +220,5 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
 
 /* drm_edid.c */
 void drm_mode_fixup_1366x768(struct drm_display_mode *mode);
+u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match);
+bool drm_valid_hdmi_vic(u8 vic);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 134069f..3820763 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -29,7 +29,6 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -3062,7 +3061,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
  *
  * Returns the HDMI Video ID (VIC) of the mode or 0 if it isn't one.
  */
-static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
+u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
 {
u8 vic;
 
@@ -3085,7 +3084,7 @@ static u8 drm_match_hdmi_mode(const struct 
drm_display_mode *to_match)
return 0;
 }
 
-static bool drm_valid_hdmi_vic(u8 vic)
+bool drm_valid_hdmi_vic(u8 vic)
 {
return vic > 0 && vic < ARRAY_SIZE(edid_4k_modes);
 }
@@ -4817,76 +4816,6 @@ void drm_set_preferred_mode(struct drm_connector 
*connector,
 EXPORT_SYMBOL(drm_set_preferred_mode);
 
 /**
- * drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe with
- *  data from a DRM display mode
- * @frame: HDMI AVI infoframe
- * @mode: DRM display mode
- * @is_hdmi2_sink: Sink is HDMI 2.0 compliant
- *
- * Return: 0 on success or a negative error code on failure.
- */
-int
-drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
-const struct drm_display_mode *mode,
-bool is_hdmi2_sink)
-{
-   int err;
-
-   if (!frame || !mode)
-   return -EINVAL;
-
-   err = hdmi_avi_infoframe_init(frame);
-   if (err < 0)
-   return err;
-
-   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
-   frame->pixel_repeat = 1;
-
-   frame->video_code = drm_match_cea_mode(mode);
-
-   /*
-* HDMI 1.4 VIC range: 1 <= VIC <= 64 (CEA-861-D) but
-* HDMI 2.0 VIC range: 1 <= VIC <= 107 (CEA-861-F). So we
-* have to make sure we dont break HDMI 1.4 sinks.
-*/
-   if (!is_hdmi2_sink && frame->video_code > 64)
-   frame->video_code = 0;
-
-   /*
-* HDMI spec says if a mode is found in HDMI 1.4b 4K modes
-* we should send its VIC in vendor infoframes, else send the
-* VIC in AVI infoframes. Lets check if this mode is present in
-* HDMI 1.4b 4K modes
-*/
-   if (frame->video_code) {
-   u8 vendor_if_vic = drm_match_hdmi_mode(mode);
-   bool is_s3d = mode->flags & DRM_MODE_FLAG_3D_MASK;
-
-   if (drm_valid_hdmi_vic(vendor_if_vic) && !is_s3d)
-   frame->video_code = 0;
-   }
-
-   frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
-
- 

Re: [PATCH 1/7] sched/core: uclamp: add CPU clamp groups accounting

[Peter Zijlstra]

On Fri, Apr 13, 2018 at 11:30:05AM +0200, Peter Zijlstra wrote:
> On Mon, Apr 09, 2018 at 05:56:09PM +0100, Patrick Bellasi wrote:
> > +struct uclamp_group {
> > +   /* Utilization clamp value for tasks on this clamp group */
> > +   int value;
> > +   /* Number of RUNNABLE tasks on this clamp group */
> > +   int tasks;
> > +};
> 
> > +struct uclamp_cpu {
> > +   /* Utilization clamp value for a CPU */
> > +   int value;
> > +   /* Utilization clamp groups affecting this CPU */
> > +   struct uclamp_group group[CONFIG_UCLAMP_GROUPS_COUNT + 1];
> > +};
> 
> > @@ -811,6 +885,11 @@ struct rq {
> > unsigned long   cpu_capacity;
> > unsigned long   cpu_capacity_orig;
> >  
> > +#ifdef CONFIG_UCLAMP_TASK
> > +   /* util_{min,max} clamp values based on CPU's active tasks */
> > +   struct uclamp_cpu uclamp[UCLAMP_CNT];
> > +#endif
> > +
> > struct callback_head*balance_callback;
> >  
> > unsigned char   idle_balance;
> 
> So that is:
> 
> struct rq {
> 
>   struct uclamp_cpu {
>   int value;
> 
>   /* 4 byte hole */
> 
>   struct uclamp_group {
>   int value;
>   int tasks;
>   } [COUNT + 1];  // size: COUNT+2 * 8 [bytes]
> 
>   } [2]; // size: 2 * COUNT+2 * 8 [bytes]
> 
> };

Note that you can slightly compress the data structure if you do
something like:

struct rq {

int active_clamp[2];

struct uclamp_group {
int value;
int task;
} [COUNT + 1][2]; // XXX check array order of C
};

It also avoids the active values being split over 2 lines; and we need
those values every time, even if there are no active clamp tasks on the
system.

Re: [PATCH] memcg: Remove memcg_cgroup::id from IDR on mem_cgroup_css_alloc() failure

[Kirill Tkhai]

On 13.04.2018 11:55, Michal Hocko wrote:
> On Thu 12-04-18 17:52:04, Kirill Tkhai wrote:
> [...]
>> @@ -4471,6 +4477,7 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state 
>> *parent_css)
>>  
>>  return &memcg->css;
>>  fail:
>> +mem_cgroup_id_remove(memcg);
>>  mem_cgroup_free(memcg);
>>  return ERR_PTR(-ENOMEM);
>>  }
> 
> The only path which jumps to fail: here (in the current mmotm tree) is 
>   error = memcg_online_kmem(memcg);
>   if (error)
>   goto fail;
> 
> AFAICS and the only failure path in memcg_online_kmem
>   memcg_id = memcg_alloc_cache_id();
>   if (memcg_id < 0)
>   return memcg_id;
> 
> I am not entirely clear on memcg_alloc_cache_id but it seems we do clean
> up properly. Or am I missing something?

memcg_alloc_cache_id() may allocate a lot of memory, in case of the system 
reached
memcg_nr_cache_ids cgroups. In this case it iterates over all LRU lists, and 
double
size of every of them. In case of memory pressure it can fail. If this occurs,
mem_cgroup::id is not unhashed from IDR and we leak this id.

After further iterations, all IDs may be occupied, and there won't be able to 
create
a memcg in the system ever. You may reproduce the situation with the patch:

[root@localhost ~]# cd /sys/fs/cgroup/memory/
[root@localhost memory]# mkdir 1
mkdir: cannot create directory `1': Cannot allocate memory
[root@localhost memory]# for i in {1..65535}; do mkdir 1 2>/dev/null; done
[root@localhost memory]# mkdir 1
mkdir: cannot create directory `1': No space left on device

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 3e7942c301a8..5e17bfee9e6f 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2156,6 +2156,7 @@ static int memcg_alloc_cache_id(void)
err = memcg_update_all_caches(size);
if (!err)
err = memcg_update_all_list_lrus(size);
+   err = -ENOMEM;
if (!err)
memcg_nr_cache_ids = size;
 
@@ -4422,7 +4423,7 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state 
*parent_css)
 {
struct mem_cgroup *parent = mem_cgroup_from_css(parent_css);
struct mem_cgroup *memcg;
-   long error = -ENOMEM;
+   long error = -ENOSPC;
 
memcg = mem_cgroup_alloc();
if (!memcg)

ENOSPC was added to the second hunk to show that the function fails on IDR 
allocation.

Kirill

Re: [PATCH 1/7] sched/core: uclamp: add CPU clamp groups accounting

[Peter Zijlstra]

On Mon, Apr 09, 2018 at 05:56:09PM +0100, Patrick Bellasi wrote:
> +struct uclamp_group {
> + /* Utilization clamp value for tasks on this clamp group */
> + int value;
> + /* Number of RUNNABLE tasks on this clamp group */
> + int tasks;
> +};

> +struct uclamp_cpu {
> + /* Utilization clamp value for a CPU */
> + int value;
> + /* Utilization clamp groups affecting this CPU */
> + struct uclamp_group group[CONFIG_UCLAMP_GROUPS_COUNT + 1];
> +};

> @@ -811,6 +885,11 @@ struct rq {
>   unsigned long   cpu_capacity;
>   unsigned long   cpu_capacity_orig;
>  
> +#ifdef CONFIG_UCLAMP_TASK
> + /* util_{min,max} clamp values based on CPU's active tasks */
> + struct uclamp_cpu uclamp[UCLAMP_CNT];
> +#endif
> +
>   struct callback_head*balance_callback;
>  
>   unsigned char   idle_balance;

So that is:

struct rq {

struct uclamp_cpu {
int value;

/* 4 byte hole */

struct uclamp_group {
int value;
int tasks;
} [COUNT + 1];  // size: COUNT+2 * 8 [bytes]

} [2]; // size: 2 * COUNT+2 * 8 [bytes]

};

Which for the default (4) ends up being 96 bytes, or at least 2 lines.
Do you want some alignment such that we don't span more lines?

Which touch extra on enqueue/dequeue, at least it's only for tasks that
have a clamp set.

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Bartlomiej Zolnierkiewicz]

On Friday, April 13, 2018 11:19:40 AM Daniel Lezcano wrote:
> On 13/04/2018 11:08, Bartlomiej Zolnierkiewicz wrote:
> > On Friday, April 13, 2018 11:00:43 AM Daniel Lezcano wrote:
> >> On 13/04/2018 10:55, Bartlomiej Zolnierkiewicz wrote:
> >>> On Friday, April 13, 2018 01:39:05 PM Zhang Rui wrote:
>  Hi, Eduardo,
> 
>  On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> > Hello,
> >
> > On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> >>
> >> On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
> >> wrote:
> >>>
> >>>
> >>> could you please illustrate me what the kconfig & warning is?
> >> Just "make allmodconfig" and the warning is about a uninitialized
> >> variable.
> >>
> >> Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> >> history
> >> is to be believed.
> >>
> >> Linus
> > Yeah, this has also passed my local compilation error. Somehow my
> > gcc4.9
> > is not catching it. Using an older gcc (gcc4.6) does catch it.
> >
> > Anyways, given that the conversion functions are written to cover
> > for unexpected cal_type, the right way of fixing this is to rewrite
> > the conversion functions to allow for returning error codes and
> > adjusting the callers as expected.
> >
> > Rui, bzolnier, please consider the following fix:
> >
>  as it is late in this merge window, I'd prefer to
>  1. drop all the thermal-soc material in the first pull request which I
>  will send out soon.
>  2. you can prepare another pull request containing the thermal-soc
>  materials except the exynos fixes
>  3. exynos fixes with the problem solved can be queued for -rc2 or
>  later.
> >>>
> >>> Could you please just merge the obvious fix from Arnd instead?
> >>>
> >>> [ it was posted two weeks ago and ACKed by me ]
> >>>
> >>> https://patchwork.kernel.org/patch/10313313/
> >>
> >> I'm not sure these are correct fixes.
> >>
> >> The change 480b5bfc16e1 tells:
> >>
> >> "There should be no functional changes caused by this patch."
> >>
> >> but the fix above returns 0 as a default value instead of '50' or '25'
> >> for the 5440 and that impacts the threshold etc ...
> >>
> >> IMO, the correct fix would be to define a default value '50', override
> >> it at init time to '25' if it is a 5440. And then the variable 'temp'
> >> and 'temp_code' get this value in the default case.
> > 
> > It is okay to return 0 because this code-path (the default one) will be
> > never hit by the driver (probe makes sure of it) - the default case is
> > here is just to silence compilation errors..
> 
> The init function is making sure cal_type is one or another. Can you fix
> it correctly by replacing the 'switch' by a 'if' instead of adding dead
> branches to please gcc?
> 
> if (data->cal_type == TYPE_TWO_POINT_TRIMMING) {
>   return ...;
> }
> 
> return ...;

I'm not the one that added this switch statement (it has been there since
2011) and I would be happy to remove it.  However could we please defer
this to v4.17 and merge the current set of Exynos thermal fixes/cleanups
(they simplify the driver a lot and make ground for future changes)?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH v1 0/2] kexec: Remove "weak" annotations from headers

[Baoquan He]

Hi Bjorn,

There are changes I have made to solve 5-level conflict with
kexec/kdump and also interface unification task, they will involve x86
64 only changes on these functions, I don't think we need remove them if
without any obvious impact or error reported.

Thanks
Baoquan

On 04/13/18 at 11:08am, Philipp Rudo wrote:
> Hi Bjorn,
> 
> in recent patches AKASHI [1] and I [2] made some changes to the declarations
> you are touching and already removed some of the weak statements. The patches
> got accepted on linux-next and will (hopefully) be pulled for v4.17. So you
> should prepare for some merge conflicts. Nevertheless three weak statements
> still remain (arch_kexec_walk_mem & arch_kexec_apply_relocations*) so your
> patch still makes totally sense.
> 
> Thanks
> Philipp
> 
> [1] https://lkml.org/lkml/2018/3/6/201
> [2] https://lkml.org/lkml/2018/3/21/278
> 
> On Thu, 12 Apr 2018 13:23:29 -0500
> Bjorn Helgaas  wrote:
> 
> > "Weak" annotations in header files are error-prone because they make
> > every definition weak.  Remove them from include/linux/kexec.h.
> > 
> > These were introduced in two separate commits, so this is in two
> > patches so they can be easily backported to stable kernels (some of
> > them date back to v4.3 and one only goes back to v4.10).
> > 
> > ---
> > 
> > Bjorn Helgaas (2):
> >   kexec: Remove "weak" from kexec_file function declarations
> >   kexec: Remove "weak" from arch_kexec_walk_mem() declaration
> > 
> > 
> >  include/linux/kexec.h |   24 
> >  1 file changed, 12 insertions(+), 12 deletions(-)
> > 
> > ___
> > kexec mailing list
> > ke...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
> > 
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v2 00/13] kernel/locking: qspinlock improvements

[Catalin Marinas]

On Wed, Apr 11, 2018 at 07:01:07PM +0100, Will Deacon wrote:
>   * Spin for a bounded duration while lock is observed in the
> pending->locked transition

FWIW, I updated my model [1] to include the bounded handover loop and,
as expected, it passes the liveness check (well, assuming fairness of
other operations like fetch_or, cmpxchg etc).

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/kernel-tla.git/tree/qspinlock.tla

-- 
Catalin

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Philipp Zabel]

Hi Geert,

On Thu, 2018-04-12 at 18:02 +0200, Geert Uytterhoeven wrote:
> Hi Philipp,
> 
> On Thu, Apr 12, 2018 at 4:10 PM, Philipp Zabel  wrote:
> > On Thu, 2018-04-12 at 15:12 +0200, Geert Uytterhoeven wrote:
> > > On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya  wrote:
> > > > On 4/12/2018 7:49 AM, Auger Eric wrote:
> > > > > On 12/04/18 13:32, Geert Uytterhoeven wrote:
> > > > > > On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric 
> > > > > >  wrote:
> > > > > > > On 11/04/18 11:15, Geert Uytterhoeven wrote:
> > > > > > > > Vfio-platform requires reset support, provided either by ACPI, 
> > > > > > > > or, on DT
> > > > > > > > platforms, by a device-specific reset driver matching against 
> > > > > > > > the
> > > > > > > > device's compatible value.
> > > > > > > > 
> > > > > > > > On many SoCs, devices are connected to an SoC-internal reset 
> > > > > > > > controller.
> > > > > > > > If the reset hierarchy is described in DT using "resets" 
> > > > > > > > properties,
> > > > > > > > such devices can be reset in a generic way through the reset 
> > > > > > > > controller
> > > > > > > > subsystem.  Hence add support for this, avoiding the need to 
> > > > > > > > write
> > > > > > > > device-specific reset drivers for each single device on 
> > > > > > > > affected SoCs.
> > > > > > > > 
> > > > > > > > Devices that do require a more complex reset procedure can 
> > > > > > > > still provide
> > > > > > > > a device-specific reset driver, as that takes precedence.
> > > > > > > > 
> > > > > > > > Note that this functionality depends on 
> > > > > > > > CONFIG_RESET_CONTROLLER=y, and
> > > > > > > > becomes a no-op (as in: "No reset function found for device") 
> > > > > > > > if reset
> > > > > > > > controller support is disabled.
> > > > > > > > 
> > > > > > > > Signed-off-by: Geert Uytterhoeven 
> > > > > > > > Reviewed-by: Philipp Zabel 
> > > > > > > > --- a/drivers/vfio/platform/vfio_platform_common.c
> > > > > > > > +++ b/drivers/vfio/platform/vfio_platform_common.c
> > > > > > > > @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
> > > > > > > > vfio_platform_device *vdev)
> > > > > > > >   vdev->of_reset = 
> > > > > > > > vfio_platform_lookup_reset(vdev->compat,
> > > > > > > >   
> > > > > > > > &vdev->reset_module);
> > > > > > > >   }
> > > > > > > > + if (vdev->of_reset)
> > > > > > > > + return 0;
> > > > > > > > +
> > > > > > > > + rstc = 
> > > > > > > > of_reset_control_get_exclusive(vdev->device->of_node, NULL);
> > > > > > > 
> > > > > > > Shouldn't we prefer the top level reset_control_get_exclusive()?
> > > > > > 
> > > > > > I guess that should work, too.
> > > > > > 
> > > > > > > To make sure about the exclusive/shared terminology, does
> > > > > > > get_reset_control_get_exclusive() check we have an exclusive wire
> > > > > > > between this device and the reset controller?
> > > > > > 
> > > > > > AFAIU, the "exclusive" means that only a single user can obtain 
> > > > > > access to
> > > > > > the reset, and it does not guarantee that we have an exclusive wire 
> > > > > > between
> > > > > > the device and the reset controller.
> > > > > > 
> > > > > > The latter depends on the SoC's reset topology. If a reset wire is 
> > > > > > shared
> > > > > > by multiple devices (e.g. resets shared by PWM or Display Unit 
> > > > > > devices on
> > > > > > R-Car SoCs), exporting a subset of these devices to a guest is a 
> > > > > > bad idea,
> > > > > > indeed.
> > > > > 
> > > > > So who's going to check this assigned device will not trigger a reset 
> > > > > of
> > > > > other non assigned devices sharing the same reset controller?
> > 
> > If the reset control is requested as exclusive, any other driver
> > requesting the same reset control will fail (or this reset_control_get
> > will fail, whichever comes last).
> > 
> > > > I like the direction in general. I was hoping that you'd call it 
> > > > of_reset_control
> > > > rather than reset_control.
> > > 
> > > You mean vfio_platform_device.of_reset_control?
> > > If we switch to reset_control_get_exclusive(), that doesn't make much 
> > > sense...
> > > 
> > > > Is there anything in the OF spec about what to expect from DT's reset?
> > > 
> > > Documentation/devicetree/bindings/reset/reset.txt says:
> > > 
> > > "A word on where to place reset signal consumers in device tree: It is 
> > > possible
> > >  in hardware for a reset signal to affect multiple logically separate HW 
> > > blocks
> > >  at once. In this case, it would be unwise to represent this reset signal 
> > > in
> > >  the DT node of each affected HW block, since if activated, an unrelated 
> > > block
> > >  may be reset. Instead, reset signals should be represented in the DT node
> > >  where it makes most sense to control it; this may be a bus node if all
> > >  children of the bus are affected by the reset signal, or an individual HW
> > >  block node for dedicat

Re: [PATCH] vfio: platform: Fix using devices in PM Domains

[Geert Uytterhoeven]

Hi Eric,

On Fri, Apr 13, 2018 at 11:14 AM, Auger Eric  wrote:
> On 11/04/18 11:24, Geert Uytterhoeven wrote:
>> If a device is part of a PM Domain (e.g. power and/or clock domain), its
>> power state is managed using Runtime PM.  Without Runtime PM, the device
>> may not be powered up, causing subtle failures, crashes, or system
>> lock-ups when the device is accessed by the guest.
> the device may not be powered up/clcoked or power/clock may be switched
> off while the guest uses it.
>>
>> Fix this by adding Runtime PM support, powering the device when the VFIO
>> device is opened by the guest.
>>
>> Note that while more fine-grained power management could be implemented
>> on the guest side, if exported, this would be inherently unsafe, as
>> abusing it may kill the whole system.
>
> Please can you elaborate on this remark please?

If power-management of the device would be delegated to the guest, and the
guest forgets to enable device power before accessing the device's registers,
this could lock up the system, and thus disturb both the host and other guests.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Daniel Lezcano]

On 13/04/2018 11:08, Bartlomiej Zolnierkiewicz wrote:
> On Friday, April 13, 2018 11:00:43 AM Daniel Lezcano wrote:
>> On 13/04/2018 10:55, Bartlomiej Zolnierkiewicz wrote:
>>> On Friday, April 13, 2018 01:39:05 PM Zhang Rui wrote:
 Hi, Eduardo,

 On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
>
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
>>
>> On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
>> wrote:
>>>
>>>
>>> could you please illustrate me what the kconfig & warning is?
>> Just "make allmodconfig" and the warning is about a uninitialized
>> variable.
>>
>> Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
>> history
>> is to be believed.
>>
>> Linus
> Yeah, this has also passed my local compilation error. Somehow my
> gcc4.9
> is not catching it. Using an older gcc (gcc4.6) does catch it.
>
> Anyways, given that the conversion functions are written to cover
> for unexpected cal_type, the right way of fixing this is to rewrite
> the conversion functions to allow for returning error codes and
> adjusting the callers as expected.
>
> Rui, bzolnier, please consider the following fix:
>
 as it is late in this merge window, I'd prefer to
 1. drop all the thermal-soc material in the first pull request which I
 will send out soon.
 2. you can prepare another pull request containing the thermal-soc
 materials except the exynos fixes
 3. exynos fixes with the problem solved can be queued for -rc2 or
 later.
>>>
>>> Could you please just merge the obvious fix from Arnd instead?
>>>
>>> [ it was posted two weeks ago and ACKed by me ]
>>>
>>> https://patchwork.kernel.org/patch/10313313/
>>
>> I'm not sure these are correct fixes.
>>
>> The change 480b5bfc16e1 tells:
>>
>> "There should be no functional changes caused by this patch."
>>
>> but the fix above returns 0 as a default value instead of '50' or '25'
>> for the 5440 and that impacts the threshold etc ...
>>
>> IMO, the correct fix would be to define a default value '50', override
>> it at init time to '25' if it is a 5440. And then the variable 'temp'
>> and 'temp_code' get this value in the default case.
> 
> It is okay to return 0 because this code-path (the default one) will be
> never hit by the driver (probe makes sure of it) - the default case is
> here is just to silence compilation errors..

The init function is making sure cal_type is one or another. Can you fix
it correctly by replacing the 'switch' by a 'if' instead of adding dead
branches to please gcc?

if (data->cal_type == TYPE_TWO_POINT_TRIMMING) {
return ...;
}

return ...;

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH] mm: vmalloc: Remove double execution of vunmap_page_range

[Chintan Pandya]

Unmap legs do call vunmap_page_range() irrespective of
debug_pagealloc_enabled() is enabled or not. So, remove
redundant check and optional vunmap_page_range() routines.

Signed-off-by: Chintan Pandya 
---
 mm/vmalloc.c | 23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index ebff729..920378a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -603,26 +603,6 @@ static void unmap_vmap_area(struct vmap_area *va)
vunmap_page_range(va->va_start, va->va_end);
 }
 
-static void vmap_debug_free_range(unsigned long start, unsigned long end)
-{
-   /*
-* Unmap page tables and force a TLB flush immediately if pagealloc
-* debugging is enabled.  This catches use after free bugs similarly to
-* those in linear kernel virtual address space after a page has been
-* freed.
-*
-* All the lazy freeing logic is still retained, in order to minimise
-* intrusiveness of this debugging feature.
-*
-* This is going to be *slow* (linear kernel virtual address debugging
-* doesn't do a broadcast TLB flush so it is a lot faster).
-*/
-   if (debug_pagealloc_enabled()) {
-   vunmap_page_range(start, end);
-   flush_tlb_kernel_range(start, end);
-   }
-}
-
 /*
  * lazy_max_pages is the maximum amount of virtual address space we gather up
  * before attempting to purge with a TLB flush.
@@ -756,6 +736,7 @@ static void free_unmap_vmap_area(struct vmap_area *va)
 {
flush_cache_vunmap(va->va_start, va->va_end);
unmap_vmap_area(va);
+   flush_tlb_kernel_range(va->va_start, va->va_end);
free_vmap_area_noflush(va);
 }
 
@@ -1142,7 +1123,6 @@ void vm_unmap_ram(const void *mem, unsigned int count)
BUG_ON(!PAGE_ALIGNED(addr));
 
debug_check_no_locks_freed(mem, size);
-   vmap_debug_free_range(addr, addr+size);
 
if (likely(count <= VMAP_MAX_ALLOC)) {
vb_free(mem, size);
@@ -1499,7 +1479,6 @@ struct vm_struct *remove_vm_area(const void *addr)
va->flags |= VM_LAZY_FREE;
spin_unlock(&vmap_area_lock);
 
-   vmap_debug_free_range(va->va_start, va->va_end);
kasan_free_shadow(vm);
free_unmap_vmap_area(va);
 
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project

Re: [PATCH] vfio: platform: Fix using devices in PM Domains

[Auger Eric]

Hi Geert,

On 11/04/18 11:24, Geert Uytterhoeven wrote:
> If a device is part of a PM Domain (e.g. power and/or clock domain), its
> power state is managed using Runtime PM.  Without Runtime PM, the device
> may not be powered up, causing subtle failures, crashes, or system
> lock-ups when the device is accessed by the guest.
the device may not be powered up/clcoked or power/clock may be switched
off while the guest uses it.
> 
> Fix this by adding Runtime PM support, powering the device when the VFIO
> device is opened by the guest.
> 
> Note that while more fine-grained power management could be implemented
> on the guest side, if exported, this would be inherently unsafe, as
> abusing it may kill the whole system.
Please can you elaborate on this remark please?

Thanks

Eric
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> This depends on "[PATCH v3 2/2] vfio: platform: Add generic DT reset
> support" due to a small contextual change (addition of "#include
> ").
> 
>  drivers/vfio/platform/vfio_platform_common.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index ef9b9e3220ebe939..4db0a143992c3353 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -249,6 +250,8 @@ static void vfio_platform_release(void *device_data)
>   const char *extra_dbg = NULL;
>   int ret;
>  
> + pm_runtime_put(vdev->device);
> +
>   ret = vfio_platform_call_reset(vdev, &extra_dbg);
>   if (ret && vdev->reset_required) {
>   dev_warn(vdev->device, "reset driver is required and 
> reset call failed in release (%d) %s\n",
> @@ -291,6 +294,10 @@ static int vfio_platform_open(void *device_data)
>ret, extra_dbg ? extra_dbg : "");
>   goto err_rst;
>   }
> +
> + ret = pm_runtime_get_sync(vdev->device);
> + if (ret < 0)
> + goto err_rst;
>   }
>  
>   vdev->refcnt++;
> @@ -706,6 +713,7 @@ int vfio_platform_probe_common(struct 
> vfio_platform_device *vdev,
>  
>   mutex_init(&vdev->igate);
>  
> + pm_runtime_enable(vdev->device);
>   return 0;
>  
>  put_iommu:
> @@ -723,6 +731,7 @@ struct vfio_platform_device 
> *vfio_platform_remove_common(struct device *dev)
>   vdev = vfio_del_group_dev(dev);
>  
>   if (vdev) {
> + pm_runtime_disable(vdev->device);
>   vfio_platform_put_reset(vdev);
>   vfio_iommu_group_put(dev->iommu_group, dev);
>   }
> 

Re: [PATCH] sched: support dynamiQ cluster

[Morten Rasmussen]

On Thu, Apr 12, 2018 at 08:22:11PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 10, 2018 at 02:19:50PM +0100, Morten Rasmussen wrote:
> > As said above, I see your point about completion time might suffer in
> > some cases for low utilization tasks, but I don't see how you can fix
> > that automagically. ASYM_PACKING has a lot of problematic side-effects.
> > If use-space knows that completion time is important for a task, there
> > are already ways to improve that somewhat in mainline (task priority and
> > pinning), and more powerful solutions in the Android kernel which
> > Patrick is currently pushing upstream.
> 
> So I tend to side with Morten on this one. I don't particularly like
> ASYM_PACKING much, but we already had it for PPC and it works for the
> small difference in performance ITMI has.
> 
> At the time Morten already objected to using it for ITMI, and I just
> haven't had time to look into his proposal for using capacity.
> 
> But I don't see it working right for big.litte/dynamiq, simply because
> it is a very strong always big preference, which is against the whole
> design premisis of big.little (as Morten has been trying to argue).

In Vincent's defence, vendors do sometimes make design decisions that I
don't quite understand. So there could be users that really want a
non-energy-aware big-first policy, but as I said earlier in this thread,
that could be implemented better with a small tweak to wake_cap() and
using the misfit patches.

We would have to disable big-first policy and go with the current
migrate-big-task-to-big-cpus policy as soon as we care about energy. I'm
happy to give that try and come up with a patch.

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Bartlomiej Zolnierkiewicz]

On Friday, April 13, 2018 11:00:43 AM Daniel Lezcano wrote:
> On 13/04/2018 10:55, Bartlomiej Zolnierkiewicz wrote:
> > On Friday, April 13, 2018 01:39:05 PM Zhang Rui wrote:
> >> Hi, Eduardo,
> >>
> >> On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> >>> Hello,
> >>>
> >>> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> 
>  On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
>  wrote:
> >
> >
> > could you please illustrate me what the kconfig & warning is?
>  Just "make allmodconfig" and the warning is about a uninitialized
>  variable.
> 
>  Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
>  history
>  is to be believed.
> 
>  Linus
> >>> Yeah, this has also passed my local compilation error. Somehow my
> >>> gcc4.9
> >>> is not catching it. Using an older gcc (gcc4.6) does catch it.
> >>>
> >>> Anyways, given that the conversion functions are written to cover
> >>> for unexpected cal_type, the right way of fixing this is to rewrite
> >>> the conversion functions to allow for returning error codes and
> >>> adjusting the callers as expected.
> >>>
> >>> Rui, bzolnier, please consider the following fix:
> >>>
> >> as it is late in this merge window, I'd prefer to
> >> 1. drop all the thermal-soc material in the first pull request which I
> >> will send out soon.
> >> 2. you can prepare another pull request containing the thermal-soc
> >> materials except the exynos fixes
> >> 3. exynos fixes with the problem solved can be queued for -rc2 or
> >> later.
> > 
> > Could you please just merge the obvious fix from Arnd instead?
> > 
> > [ it was posted two weeks ago and ACKed by me ]
> > 
> > https://patchwork.kernel.org/patch/10313313/
> 
> I'm not sure these are correct fixes.
> 
> The change 480b5bfc16e1 tells:
> 
> "There should be no functional changes caused by this patch."
> 
> but the fix above returns 0 as a default value instead of '50' or '25'
> for the 5440 and that impacts the threshold etc ...
> 
> IMO, the correct fix would be to define a default value '50', override
> it at init time to '25' if it is a 5440. And then the variable 'temp'
> and 'temp_code' get this value in the default case.

It is okay to return 0 because this code-path (the default one) will be
never hit by the driver (probe makes sure of it) - the default case is
here is just to silence compilation errors..

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH v1 0/2] kexec: Remove "weak" annotations from headers

[Philipp Rudo]

Hi Bjorn,

in recent patches AKASHI [1] and I [2] made some changes to the declarations
you are touching and already removed some of the weak statements. The patches
got accepted on linux-next and will (hopefully) be pulled for v4.17. So you
should prepare for some merge conflicts. Nevertheless three weak statements
still remain (arch_kexec_walk_mem & arch_kexec_apply_relocations*) so your
patch still makes totally sense.

Thanks
Philipp

[1] https://lkml.org/lkml/2018/3/6/201
[2] https://lkml.org/lkml/2018/3/21/278

On Thu, 12 Apr 2018 13:23:29 -0500
Bjorn Helgaas  wrote:

> "Weak" annotations in header files are error-prone because they make
> every definition weak.  Remove them from include/linux/kexec.h.
> 
> These were introduced in two separate commits, so this is in two
> patches so they can be easily backported to stable kernels (some of
> them date back to v4.3 and one only goes back to v4.10).
> 
> ---
> 
> Bjorn Helgaas (2):
>   kexec: Remove "weak" from kexec_file function declarations
>   kexec: Remove "weak" from arch_kexec_walk_mem() declaration
> 
> 
>  include/linux/kexec.h |   24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

[PATCH v2] selftests: add headers_install to lib.mk

[Anders Roxell]

If the kernel headers aren't installed we can't build all the tests.
Add a new make target rule 'khdr' in the file lib.mk to generate the
kernel headers and that gets include for every test-dir Makefile that
includes lib.mk If the testdir in turn have its own sub-dirs the
top_srcdir needs to be set to the linux-rootdir to be able to generate
the kernel headers.

Signed-off-by: Anders Roxell 
Reviewed-by: Fathi Boudra 
---
 Makefile  | 14 +-
 scripts/subarch.include   | 13 +
 tools/testing/selftests/android/Makefile  |  2 +-
 tools/testing/selftests/android/ion/Makefile  |  1 +
 tools/testing/selftests/bpf/Makefile  |  5 ++---
 tools/testing/selftests/futex/functional/Makefile |  1 +
 tools/testing/selftests/gpio/Makefile |  4 
 tools/testing/selftests/kvm/Makefile  |  6 +-
 tools/testing/selftests/lib.mk| 10 ++
 tools/testing/selftests/vm/Makefile   |  3 ---
 10 files changed, 30 insertions(+), 29 deletions(-)
 create mode 100644 scripts/subarch.include

diff --git a/Makefile b/Makefile
index 74567b0ec2f0..0c47935d48a2 100644
--- a/Makefile
+++ b/Makefile
@@ -286,19 +286,7 @@ KERNELRELEASE = $(shell cat include/config/kernel.release 
2> /dev/null)
 KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
$(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
 export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
 
-# SUBARCH tells the usermode build what the underlying arch is.  That is set
-# first, and if a usermode build is happening, the "ARCH=um" on the command
-# line overrides the setting of ARCH below.  If a native build is happening,
-# then ARCH is assigned, getting whatever value it gets normally, and
-# SUBARCH is subsequently ignored.
-
-SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
- -e s/sun4u/sparc64/ \
- -e s/arm.*/arm/ -e s/sa110/arm/ \
- -e s/s390x/s390/ -e s/parisc64/parisc/ \
- -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
- -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
- -e s/riscv.*/riscv/)
+include scripts/subarch.include
 
 # Cross compiling and selecting different set of gcc/bin-utils
 # ---
diff --git a/scripts/subarch.include b/scripts/subarch.include
new file mode 100644
index ..650682821126
--- /dev/null
+++ b/scripts/subarch.include
@@ -0,0 +1,13 @@
+# SUBARCH tells the usermode build what the underlying arch is.  That is set
+# first, and if a usermode build is happening, the "ARCH=um" on the command
+# line overrides the setting of ARCH below.  If a native build is happening,
+# then ARCH is assigned, getting whatever value it gets normally, and
+# SUBARCH is subsequently ignored.
+
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+ -e s/sun4u/sparc64/ \
+ -e s/arm.*/arm/ -e s/sa110/arm/ \
+ -e s/s390x/s390/ -e s/parisc64/parisc/ \
+ -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
+ -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
+ -e s/riscv.*/riscv/)
diff --git a/tools/testing/selftests/android/Makefile 
b/tools/testing/selftests/android/Makefile
index f6304d2be90c..087390bbad68 100644
--- a/tools/testing/selftests/android/Makefile
+++ b/tools/testing/selftests/android/Makefile
@@ -6,7 +6,7 @@ TEST_PROGS := run.sh
 
 include ../lib.mk
 
-all:
+all: khdr
@for DIR in $(SUBDIRS); do  \
BUILD_TARGET=$(OUTPUT)/$$DIR;   \
mkdir $$BUILD_TARGET  -p;   \
diff --git a/tools/testing/selftests/android/ion/Makefile 
b/tools/testing/selftests/android/ion/Makefile
index e03695287f76..14ecd9805748 100644
--- a/tools/testing/selftests/android/ion/Makefile
+++ b/tools/testing/selftests/android/ion/Makefile
@@ -11,6 +11,7 @@ $(TEST_GEN_FILES): ipcsocket.c ionutils.c
 TEST_PROGS := ion_test.sh
 
 include ../../lib.mk
+top_srcdir = ../../../../../
 
 $(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
 $(OUTPUT)/ionapp_import: ionapp_import.c ipcsocket.c ionutils.c
diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile
index 0a315ddabbf4..cc611a284087 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -16,9 +16,8 @@ LDLIBS += -lcap -lelf -lrt -lpthread
 TEST_CUSTOM_PROGS = $(OUTPUT)/urandom_read
 all: $(TEST_CUSTOM_PROGS)
 
-$(TEST_CUSTOM_PROGS): urandom_read
-
-urandom_read: urandom_read.c
+$(TEST_CUSTOM_PROGS):| khdr
+$(TEST_CUSTOM_PROGS): urandom_read.c
$(CC) -o $(TEST_CUST

Re: [PATCH] kernel/resource: refine find_next_iomem_res() a little

[Wei Yang]

Hello every one,

Someone would like to take a look at this?

On Tue, Mar 27, 2018 at 06:46:06AM +0800, Wei Yang wrote:
>This patch does several refine for find_next_iomem_res()
>
>  * use first_level_children_only directly
>  * remove some local variables
>  * use resrouce_clip()
>
>Signed-off-by: Wei Yang 
>---
> kernel/resource.c | 40 +++-
> 1 file changed, 15 insertions(+), 25 deletions(-)
>
>diff --git a/kernel/resource.c b/kernel/resource.c
>index e270b5048988..769109f20fb7 100644
>--- a/kernel/resource.c
>+++ b/kernel/resource.c
>@@ -351,6 +351,15 @@ int release_resource(struct resource *old)
> 
> EXPORT_SYMBOL(release_resource);
> 
>+static void resource_clip(struct resource *res, resource_size_t min,
>+resource_size_t max)
>+{
>+  if (res->start < min)
>+  res->start = min;
>+  if (res->end > max)
>+  res->end = max;
>+}
>+
> /*
>  * Finds the lowest iomem resource existing within [res->start.res->end).
>  * The caller must specify res->start, res->end, res->flags, and optionally
>@@ -361,31 +370,24 @@ EXPORT_SYMBOL(release_resource);
> static int find_next_iomem_res(struct resource *res, unsigned long desc,
>  bool first_level_children_only)
> {
>-  resource_size_t start, end;
>   struct resource *p;
>-  bool sibling_only = false;
> 
>   BUG_ON(!res);
>-
>-  start = res->start;
>-  end = res->end;
>-  BUG_ON(start >= end);
>-
>-  if (first_level_children_only)
>-  sibling_only = true;
>+  BUG_ON(res->start >= res->end);
> 
>   read_lock(&resource_lock);
> 
>-  for (p = iomem_resource.child; p; p = next_resource(p, sibling_only)) {
>+  for (p = iomem_resource.child; p;
>+  p = next_resource(p, first_level_children_only)) {
>   if ((p->flags & res->flags) != res->flags)
>   continue;
>   if ((desc != IORES_DESC_NONE) && (desc != p->desc))
>   continue;
>-  if (p->start > end) {
>+  if (p->start > res->end) {
>   p = NULL;
>   break;
>   }
>-  if ((p->end >= start) && (p->start < end))
>+  if ((p->end >= res->start) && (p->start < res->end))
>   break;
>   }
> 
>@@ -393,10 +395,7 @@ static int find_next_iomem_res(struct resource *res, 
>unsigned long desc,
>   if (!p)
>   return -1;
>   /* copy data */
>-  if (res->start < p->start)
>-  res->start = p->start;
>-  if (res->end > p->end)
>-  res->end = p->end;
>+  resource_clip(res, p->start, p->end);
>   res->flags = p->flags;
>   res->desc = p->desc;
>   return 0;
>@@ -600,15 +599,6 @@ static resource_size_t simple_align_resource(void *data,
>   return avail->start;
> }
> 
>-static void resource_clip(struct resource *res, resource_size_t min,
>-resource_size_t max)
>-{
>-  if (res->start < min)
>-  res->start = min;
>-  if (res->end > max)
>-  res->end = max;
>-}
>-
> /*
>  * Find empty slot in the resource tree with the given range and
>  * alignment constraints
>-- 
>2.15.1

-- 
Wei Yang
Help you, Help me

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Geert Uytterhoeven]

Hi Eric,

On Fri, Apr 13, 2018 at 10:52 AM, Auger Eric  wrote:
> On 12/04/18 18:02, Geert Uytterhoeven wrote:
>> On Thu, Apr 12, 2018 at 4:10 PM, Philipp Zabel  
>> wrote:
>>> On Thu, 2018-04-12 at 15:12 +0200, Geert Uytterhoeven wrote:
 On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya  wrote:
> On 4/12/2018 7:49 AM, Auger Eric wrote:
>> On 12/04/18 13:32, Geert Uytterhoeven wrote:
>>> On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric  
>>> wrote:
 On 11/04/18 11:15, Geert Uytterhoeven wrote:
> Vfio-platform requires reset support, provided either by ACPI, or, on 
> DT
> platforms, by a device-specific reset driver matching against the
> device's compatible value.
>
> On many SoCs, devices are connected to an SoC-internal reset 
> controller.
> If the reset hierarchy is described in DT using "resets" properties,
> such devices can be reset in a generic way through the reset 
> controller
> subsystem.  Hence add support for this, avoiding the need to write
> device-specific reset drivers for each single device on affected SoCs.
>
> Devices that do require a more complex reset procedure can still 
> provide
> a device-specific reset driver, as that takes precedence.
>
> Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
> becomes a no-op (as in: "No reset function found for device") if reset
> controller support is disabled.
>
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Philipp Zabel 
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
> vfio_platform_device *vdev)
>   vdev->of_reset = 
> vfio_platform_lookup_reset(vdev->compat,
>   
> &vdev->reset_module);
>   }
> + if (vdev->of_reset)
> + return 0;
> +
> + rstc = of_reset_control_get_exclusive(vdev->device->of_node, 
> NULL);

 Shouldn't we prefer the top level reset_control_get_exclusive()?
>>>
>>> I guess that should work, too.
>>>
 To make sure about the exclusive/shared terminology, does
 get_reset_control_get_exclusive() check we have an exclusive wire
 between this device and the reset controller?
>>>
>>> AFAIU, the "exclusive" means that only a single user can obtain access 
>>> to
>>> the reset, and it does not guarantee that we have an exclusive wire 
>>> between
>>> the device and the reset controller.
>>>
>>> The latter depends on the SoC's reset topology. If a reset wire is 
>>> shared
>>> by multiple devices (e.g. resets shared by PWM or Display Unit devices 
>>> on
>>> R-Car SoCs), exporting a subset of these devices to a guest is a bad 
>>> idea,
>>> indeed.
>>
>> So who's going to check this assigned device will not trigger a reset of
>> other non assigned devices sharing the same reset controller?
>>>
>>> If the reset control is requested as exclusive, any other driver
>>> requesting the same reset control will fail (or this reset_control_get
>>> will fail, whichever comes last).
>>>
> I like the direction in general. I was hoping that you'd call it 
> of_reset_control
> rather than reset_control.

 You mean vfio_platform_device.of_reset_control?
 If we switch to reset_control_get_exclusive(), that doesn't make much 
 sense...

> Is there anything in the OF spec about what to expect from DT's reset?

 Documentation/devicetree/bindings/reset/reset.txt says:

 "A word on where to place reset signal consumers in device tree: It is 
 possible
  in hardware for a reset signal to affect multiple logically separate HW 
 blocks
  at once. In this case, it would be unwise to represent this reset signal 
 in
  the DT node of each affected HW block, since if activated, an unrelated 
 block
  may be reset. Instead, reset signals should be represented in the DT node
  where it makes most sense to control it; this may be a bus node if all
  children of the bus are affected by the reset signal, or an individual HW
  block node for dedicated reset signals. The intent of this binding is to 
 give
  appropriate software access to the reset signals in order to manage the 
 HW,
  rather than to slavishly enumerate the reset signal that affects each HW
  block."
>>>
>>> This was written in 2012, and unfortunately the DT binding documentation
>>> does not inform hardware development, and has not been updated since.
>>>
>>> There's generally two kinds of reset uses:
>>> - either to bring a d

Re: [PATCH v3 02/12] KVM: arm/arm64: Document KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

[Peter Maydell]

On 13 April 2018 at 09:20, Eric Auger  wrote:
> We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in
> KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the
> base address and size of a redistributor region
>
> Compared to KVM_VGIC_V3_ADDR_TYPE_REDIST, this new attribute allows
> to declare several separate redistributor regions.
>
> So the whole redist space does not need to be contiguous anymore.
>
> Signed-off-by: Eric Auger 
> ---

Reviewed-by: Peter Maydell 

thanks
-- PMM

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Daniel Lezcano]

On 13/04/2018 10:55, Bartlomiej Zolnierkiewicz wrote:
> On Friday, April 13, 2018 01:39:05 PM Zhang Rui wrote:
>> Hi, Eduardo,
>>
>> On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
>>> Hello,
>>>
>>> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:

 On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
 wrote:
>
>
> could you please illustrate me what the kconfig & warning is?
 Just "make allmodconfig" and the warning is about a uninitialized
 variable.

 Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
 history
 is to be believed.

 Linus
>>> Yeah, this has also passed my local compilation error. Somehow my
>>> gcc4.9
>>> is not catching it. Using an older gcc (gcc4.6) does catch it.
>>>
>>> Anyways, given that the conversion functions are written to cover
>>> for unexpected cal_type, the right way of fixing this is to rewrite
>>> the conversion functions to allow for returning error codes and
>>> adjusting the callers as expected.
>>>
>>> Rui, bzolnier, please consider the following fix:
>>>
>> as it is late in this merge window, I'd prefer to
>> 1. drop all the thermal-soc material in the first pull request which I
>> will send out soon.
>> 2. you can prepare another pull request containing the thermal-soc
>> materials except the exynos fixes
>> 3. exynos fixes with the problem solved can be queued for -rc2 or
>> later.
> 
> Could you please just merge the obvious fix from Arnd instead?
> 
> [ it was posted two weeks ago and ACKed by me ]
> 
> https://patchwork.kernel.org/patch/10313313/

I'm not sure these are correct fixes.

The change 480b5bfc16e1 tells:

"There should be no functional changes caused by this patch."

but the fix above returns 0 as a default value instead of '50' or '25'
for the 5440 and that impacts the threshold etc ...

IMO, the correct fix would be to define a default value '50', override
it at init time to '25' if it is a 5440. And then the variable 'temp'
and 'temp_code' get this value in the default case.




> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: KMSAN: uninit-value in __netif_receive_skb_core

[Toshiaki Makita]

On 2018/04/12 17:03, Dmitry Vyukov wrote:
> On Thu, Apr 12, 2018 at 10:01 AM, syzbot
>  wrote:
>> Hello,
>>
>> syzbot hit the following crash on https://github.com/google/kmsan.git/master
>> commit
>> e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +)
>> kmsan: temporarily disable visitAsmInstruction() to help syzbot
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=b202b7208664142954fa
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>> Raw console output:
>> https://syzkaller.appspot.com/x/log.txt?id=535651643762
>> Kernel config:
>> https://syzkaller.appspot.com/x/.config?id=6627248707860932248
>> compiler: clang version 7.0.0 (trunk 329391)
> 
> +Toshiaki as this seems to be related to the recent vlan tagging changes.

seems not...
"Uninit was stored to memory at:" shows uninitialized memory was stored
before where I modified the code (skb_reorder_vlan_header).

I'm not sure what this uninit memory means.
To me it looks like the memory is initialized by user provided data.

(iov in packet sock -> skb->data -> skb->protocol)

The reproducer provides 4 bytes after ethernet header, so it should be
sufficient for a vlan tag. This will set skb->len to 4 and fill the
4-byte contents in packet_snd(). skb_vlan_untag() is reading the user
provided 4-byte skb->data. It is ensured that skb_vlan_untag() does not
read beyond skb->len since it calls pskb_may_pull(). At this point I am
failing to find what I am missing.

> This also seems to be related to
> https://groups.google.com/d/msg/syzkaller-bugs/VRH9NnUi2k0/90GYsAeRBgAJ
> 
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+b202b720866414295...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> ==
>> BUG: KMSAN: uninit-value in __read_once_size include/linux/compiler.h:197
>> [inline]
>> BUG: KMSAN: uninit-value in deliver_ptype_list_skb net/core/dev.c:1908
>> [inline]
>> BUG: KMSAN: uninit-value in __netif_receive_skb_core+0x4630/0x4a80
>> net/core/dev.c:4545
>> CPU: 0 PID: 5999 Comm: syz-executor3 Not tainted 4.16.0+ #82
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>>  kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>>  __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
>>  __read_once_size include/linux/compiler.h:197 [inline]
>>  deliver_ptype_list_skb net/core/dev.c:1908 [inline]
>>  __netif_receive_skb_core+0x4630/0x4a80 net/core/dev.c:4545
>>  __netif_receive_skb net/core/dev.c:4627 [inline]
>>  process_backlog+0x62d/0xe20 net/core/dev.c:5307
>>  napi_poll net/core/dev.c:5705 [inline]
>>  net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
>>  __do_softirq+0x56d/0x93d kernel/softirq.c:285
>>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040
>>  
>>  do_softirq kernel/softirq.c:329 [inline]
>>  __local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
>>  local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
>>  rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
>>  __dev_queue_xmit+0x2a31/0x2b60 net/core/dev.c:3584
>>  dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
>>  packet_snd net/packet/af_packet.c:2944 [inline]
>>  packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969
>>  sock_sendmsg_nosec net/socket.c:630 [inline]
>>  sock_sendmsg net/socket.c:640 [inline]
>>  sock_write_iter+0x3b9/0x470 net/socket.c:909
>>  do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
>>  do_iter_write+0x30d/0xd40 fs/read_write.c:932
>>  vfs_writev fs/read_write.c:977 [inline]
>>  do_writev+0x3c9/0x830 fs/read_write.c:1012
>>  SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
>>  SyS_writev+0x56/0x80 fs/read_write.c:1082
>>  do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>>  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> RIP: 0033:0x455259
>> RSP: 002b:7fb53ede8c68 EFLAGS: 0246 ORIG_RAX: 0014
>> RAX: ffda RBX: 7fb53ede96d4 RCX: 00455259
>> RDX: 0001 RSI: 200010c0 RDI: 0013
>> RBP: 0072bea0 R08:  R09: 
>> R10:  R11: 0246 R12: 
>> R13: 06cd R14: 006fd3d8 R15: 
>>
>> Uninit was stored to memory at:
>>  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
>>  kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
>>  kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
>>  __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
>>  skb_vlan_untag+0x950/0xee0 include/linux/if_vlan.h:597
>>  __netif_receive_skb_core+0x70a/0x4a80 net/core/dev.c:4460
>>  __netif_receive_skb net/core/dev.c:4627 [i

Re: [PATCH] memcg: Remove memcg_cgroup::id from IDR on mem_cgroup_css_alloc() failure

[Michal Hocko]

On Thu 12-04-18 17:52:04, Kirill Tkhai wrote:
[...]
> @@ -4471,6 +4477,7 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state 
> *parent_css)
>  
>   return &memcg->css;
>  fail:
> + mem_cgroup_id_remove(memcg);
>   mem_cgroup_free(memcg);
>   return ERR_PTR(-ENOMEM);
>  }

The only path which jumps to fail: here (in the current mmotm tree) is 
error = memcg_online_kmem(memcg);
if (error)
goto fail;

AFAICS and the only failure path in memcg_online_kmem
memcg_id = memcg_alloc_cache_id();
if (memcg_id < 0)
return memcg_id;

I am not entirely clear on memcg_alloc_cache_id but it seems we do clean
up properly. Or am I missing something?
-- 
Michal Hocko
SUSE Labs

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Bartlomiej Zolnierkiewicz]

On Friday, April 13, 2018 01:39:05 PM Zhang Rui wrote:
> Hi, Eduardo,
> 
> On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> > Hello,
> > 
> > On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > > 
> > > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
> > > wrote:
> > > > 
> > > > 
> > > > could you please illustrate me what the kconfig & warning is?
> > > Just "make allmodconfig" and the warning is about a uninitialized
> > > variable.
> > > 
> > > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > > history
> > > is to be believed.
> > > 
> > > Linus
> > Yeah, this has also passed my local compilation error. Somehow my
> > gcc4.9
> > is not catching it. Using an older gcc (gcc4.6) does catch it.
> > 
> > Anyways, given that the conversion functions are written to cover
> > for unexpected cal_type, the right way of fixing this is to rewrite
> > the conversion functions to allow for returning error codes and
> > adjusting the callers as expected.
> > 
> > Rui, bzolnier, please consider the following fix:
> > 
> as it is late in this merge window, I'd prefer to
> 1. drop all the thermal-soc material in the first pull request which I
> will send out soon.
> 2. you can prepare another pull request containing the thermal-soc
> materials except the exynos fixes
> 3. exynos fixes with the problem solved can be queued for -rc2 or
> later.

Could you please just merge the obvious fix from Arnd instead?

[ it was posted two weeks ago and ACKed by me ]

https://patchwork.kernel.org/patch/10313313/

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH v3 1/2] vfio: platform: Fix reset module leak in error path

[Auger Eric]

Hi Geert,
On 11/04/18 11:15, Geert Uytterhoeven wrote:
> If the IOMMU group setup fails, the reset module is not released.
> 
> Fixes: b5add544d677d363 ("vfio, platform: make reset driver a requirement by 
> default")
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Eric Auger 
> Reviewed-by: Simon Horman 
Acked-by: Eric Auger 

Thanks

Eric
> ---
> v3:
>   - Add Reviewed-by,
> 
> v2:
>   - Add Reviewed-by.
> ---
>  drivers/vfio/platform/vfio_platform_common.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index 35469af87f88678e..b60bb5326668498c 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -680,18 +680,23 @@ int vfio_platform_probe_common(struct 
> vfio_platform_device *vdev,
>   group = vfio_iommu_group_get(dev);
>   if (!group) {
>   pr_err("VFIO: No IOMMU group for device %s\n", vdev->name);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto put_reset;
>   }
>  
>   ret = vfio_add_group_dev(dev, &vfio_platform_ops, vdev);
> - if (ret) {
> - vfio_iommu_group_put(group, dev);
> - return ret;
> - }
> + if (ret)
> + goto put_iommu;
>  
>   mutex_init(&vdev->igate);
>  
>   return 0;
> +
> +put_iommu:
> + vfio_iommu_group_put(group, dev);
> +put_reset:
> + vfio_platform_put_reset(vdev);
> + return ret;
>  }
>  EXPORT_SYMBOL_GPL(vfio_platform_probe_common);
>  
> 

Re: [PATCH v2] vfio: platform: Make printed error messages more consistent

[Auger Eric]

Hi Geert,On 10/04/18 16:54, Geert Uytterhoeven wrote:
>   - Capitalize the first word of error messages,
>   - Unwrap statements that fit on a single line,
>   - Use "VFIO" instead of "vfio" as the error message prefix.
> 
> Signed-off-by: Geert Uytterhoeven 
> Reviewed-by: Eric Auger 
Acked-by: Eric Auger 

Thanks

Eric
> ---
> v2:
>   - Add Reviewed-by.
> ---
>  drivers/vfio/platform/vfio_platform_common.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index 4c27f4be3c3d0385..35469af87f88678e 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -630,8 +630,7 @@ static int vfio_platform_of_probe(struct 
> vfio_platform_device *vdev,
>   ret = device_property_read_string(dev, "compatible",
> &vdev->compat);
>   if (ret)
> - pr_err("VFIO: cannot retrieve compat for %s\n",
> - vdev->name);
> + pr_err("VFIO: Cannot retrieve compat for %s\n", vdev->name);
>  
>   return ret;
>  }
> @@ -673,7 +672,7 @@ int vfio_platform_probe_common(struct 
> vfio_platform_device *vdev,
>  
>   ret = vfio_platform_get_reset(vdev);
>   if (ret && vdev->reset_required) {
> - pr_err("vfio: no reset function found for device %s\n",
> + pr_err("VFIO: No reset function found for device %s\n",
>  vdev->name);
>   return ret;
>   }
> 

Re: [PATCH v3 2/2] vfio: platform: Add generic DT reset support

[Auger Eric]

Hi Geert, Philipp,

On 12/04/18 18:02, Geert Uytterhoeven wrote:
> Hi Philipp,
> 
> On Thu, Apr 12, 2018 at 4:10 PM, Philipp Zabel  wrote:
>> On Thu, 2018-04-12 at 15:12 +0200, Geert Uytterhoeven wrote:
>>> On Thu, Apr 12, 2018 at 2:36 PM, Sinan Kaya  wrote:
 On 4/12/2018 7:49 AM, Auger Eric wrote:
> On 12/04/18 13:32, Geert Uytterhoeven wrote:
>> On Thu, Apr 12, 2018 at 12:31 PM, Auger Eric  
>> wrote:
>>> On 11/04/18 11:15, Geert Uytterhoeven wrote:
 Vfio-platform requires reset support, provided either by ACPI, or, on 
 DT
 platforms, by a device-specific reset driver matching against the
 device's compatible value.

 On many SoCs, devices are connected to an SoC-internal reset 
 controller.
 If the reset hierarchy is described in DT using "resets" properties,
 such devices can be reset in a generic way through the reset controller
 subsystem.  Hence add support for this, avoiding the need to write
 device-specific reset drivers for each single device on affected SoCs.

 Devices that do require a more complex reset procedure can still 
 provide
 a device-specific reset driver, as that takes precedence.

 Note that this functionality depends on CONFIG_RESET_CONTROLLER=y, and
 becomes a no-op (as in: "No reset function found for device") if reset
 controller support is disabled.

 Signed-off-by: Geert Uytterhoeven 
 Reviewed-by: Philipp Zabel 
 --- a/drivers/vfio/platform/vfio_platform_common.c
 +++ b/drivers/vfio/platform/vfio_platform_common.c
 @@ -127,8 +130,16 @@ static int vfio_platform_get_reset(struct 
 vfio_platform_device *vdev)
   vdev->of_reset = vfio_platform_lookup_reset(vdev->compat,
   
 &vdev->reset_module);
   }
 + if (vdev->of_reset)
 + return 0;
 +
 + rstc = of_reset_control_get_exclusive(vdev->device->of_node, 
 NULL);
>>>
>>> Shouldn't we prefer the top level reset_control_get_exclusive()?
>>
>> I guess that should work, too.
>>
>>> To make sure about the exclusive/shared terminology, does
>>> get_reset_control_get_exclusive() check we have an exclusive wire
>>> between this device and the reset controller?
>>
>> AFAIU, the "exclusive" means that only a single user can obtain access to
>> the reset, and it does not guarantee that we have an exclusive wire 
>> between
>> the device and the reset controller.
>>
>> The latter depends on the SoC's reset topology. If a reset wire is shared
>> by multiple devices (e.g. resets shared by PWM or Display Unit devices on
>> R-Car SoCs), exporting a subset of these devices to a guest is a bad 
>> idea,
>> indeed.
>
> So who's going to check this assigned device will not trigger a reset of
> other non assigned devices sharing the same reset controller?
>>
>> If the reset control is requested as exclusive, any other driver
>> requesting the same reset control will fail (or this reset_control_get
>> will fail, whichever comes last).
>>
 I like the direction in general. I was hoping that you'd call it 
 of_reset_control
 rather than reset_control.
>>>
>>> You mean vfio_platform_device.of_reset_control?
>>> If we switch to reset_control_get_exclusive(), that doesn't make much 
>>> sense...
>>>
 Is there anything in the OF spec about what to expect from DT's reset?
>>>
>>> Documentation/devicetree/bindings/reset/reset.txt says:
>>>
>>> "A word on where to place reset signal consumers in device tree: It is 
>>> possible
>>>  in hardware for a reset signal to affect multiple logically separate HW 
>>> blocks
>>>  at once. In this case, it would be unwise to represent this reset signal in
>>>  the DT node of each affected HW block, since if activated, an unrelated 
>>> block
>>>  may be reset. Instead, reset signals should be represented in the DT node
>>>  where it makes most sense to control it; this may be a bus node if all
>>>  children of the bus are affected by the reset signal, or an individual HW
>>>  block node for dedicated reset signals. The intent of this binding is to 
>>> give
>>>  appropriate software access to the reset signals in order to manage the HW,
>>>  rather than to slavishly enumerate the reset signal that affects each HW
>>>  block."
>>
>> This was written in 2012, and unfortunately the DT binding documentation
>> does not inform hardware development, and has not been updated since.
>>
>> There's generally two kinds of reset uses:
>> - either to bring a device into a known state at a given point in time,
>>   which is often done using a timed assert/deassert sequence,
>> - or just to park a device while not in active use (must deassert any
>>   ti

[PATCH v3] gpio: dwapb: Add support for 1 interrupt per port A GPIO

[Phil Edworthy]

The DesignWare GPIO IP can be configured for either 1 interrupt or 1
per GPIO in port A, but the driver currently only supports 1 interrupt.
See the DesignWare DW_apb_gpio Databook description of the
'GPIO_INTR_IO' parameter.

This change allows the driver to work with up to 32 interrupts, it will
get as many interrupts as specified in the DT 'interrupts' property.
It doesn't do anything clever with the different interrupts, it just calls
the same handler used for single interrupt hardware.

Signed-off-by: Phil Edworthy 
---
One point to mention is that I have made it possible for users to have
unconncted interrupts by specifying holes in the list of interrupts. This is
done by supporting the interrupts-extended DT prop.
However, I have no use for this and had to hack some test case for this.
Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?

v3:
 - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect problems
v2:
 - Replaced interrupt-mask DT prop with support for the interrupts-extended
   prop. This means replacing the call to irq_of_parse_and_map() with calls
   to of_irq_parse_one() and irq_create_of_mapping().

Note: There are a few *code* lines over 80 chars, but this is just guidance,
   right? Especially as there are already some lines over 80 chars.
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |  9 -
 drivers/gpio/gpio-dwapb.c  | 43 +-
 drivers/mfd/intel_quark_i2c_gpio.c |  3 +-
 include/linux/platform_data/gpio-dwapb.h   |  3 +-
 4 files changed, 45 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
index 4a75da7..3c1118b 100644
--- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -26,8 +26,13 @@ controller.
   the second encodes the triger flags encoded as described in
   Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 - interrupt-parent : The parent interrupt controller.
-- interrupts : The interrupt to the parent controller raised when GPIOs
-  generate the interrupts.
+- interrupts : The interrupts to the parent controller raised when GPIOs
+  generate the interrupts. If the controller provides one combined interrupt
+  for all GPIOs, specify a single interrupt. If the controller provides one
+  interrupt for each GPIO, provide a list of interrupts that correspond to each
+  of the GPIO pins. When specifying multiple interrupts, if any are 
unconnected,
+  use the interrupts-extended property to specify the interrupts and set the
+  interrupt controller handle for unused interrupts to 0.
 - snps,nr-gpios : The number of pins in the port, a single cell.
 - resets : Reset line for the controller.
 
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 226977f..3273504 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -441,14 +441,19 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
irq_gc->chip_types[1].handler = handle_edge_irq;
 
if (!pp->irq_shared) {
-   irq_set_chained_handler_and_data(pp->irq, dwapb_irq_handler,
-gpio);
+   int i;
+
+   for (i = 0; i < pp->ngpio; i++) {
+   if (pp->irq[i])
+   irq_set_chained_handler_and_data(pp->irq[i],
+   dwapb_irq_handler, gpio);
+   }
} else {
/*
 * Request a shared IRQ since where MFD would have devices
 * using the same irq pin
 */
-   err = devm_request_irq(gpio->dev, pp->irq,
+   err = devm_request_irq(gpio->dev, pp->irq[0],
   dwapb_irq_handler_mfd,
   IRQF_SHARED, "gpio-dwapb-mfd", gpio);
if (err) {
@@ -524,7 +529,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
if (pp->idx == 0)
port->gc.set_config = dwapb_gpio_set_config;
 
-   if (pp->irq)
+   if (pp->has_irq)
dwapb_configure_irqs(gpio, port, pp);
 
err = gpiochip_add_data(&port->gc, port);
@@ -535,7 +540,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
port->is_registered = true;
 
/* Add GPIO-signaled ACPI event support */
-   if (pp->irq)
+   if (pp->has_irq)
acpi_gpiochip_request_interrupts(&port->gc);
 
return err;
@@ -601,13 +606,33 @@ dwapb_gpio_get_pdata(struct device *dev)
if (dev->of_node && pp->idx == 0 &&
fwnode_property_read_bool(fwnode,
  "interrupt-controller")) {
-   

[PATCH] MIPS: dts: Boston: Fix PCI bus dtc warnings:

[Matt Redfearn]

dtc recently (v1.4.4-8-g756ffc4f52f6) added PCI bus checks. Fix the
warnings now emitted:

arch/mips/boot/dts/img/boston.dtb: Warning (pci_bridge): /pci@1000:
missing bus-range for PCI bridge
arch/mips/boot/dts/img/boston.dtb: Warning (pci_bridge): /pci@1200:
missing bus-range for PCI bridge
arch/mips/boot/dts/img/boston.dtb: Warning (pci_bridge): /pci@1400:
missing bus-range for PCI bridge

Signed-off-by: Matt Redfearn 
---

 arch/mips/boot/dts/img/boston.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/mips/boot/dts/img/boston.dts 
b/arch/mips/boot/dts/img/boston.dts
index 2cd49b60e030..f7aad80c69ab 100644
--- a/arch/mips/boot/dts/img/boston.dts
+++ b/arch/mips/boot/dts/img/boston.dts
@@ -51,6 +51,8 @@
ranges = <0x0200 0 0x4000
  0x4000 0 0x4000>;
 
+   bus-range = <0x00 0xff>;
+
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pci0_intc 1>,
<0 0 0 2 &pci0_intc 2>,
@@ -79,6 +81,8 @@
ranges = <0x0200 0 0x2000
  0x2000 0 0x2000>;
 
+   bus-range = <0x00 0xff>;
+
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pci1_intc 1>,
<0 0 0 2 &pci1_intc 2>,
@@ -107,6 +111,8 @@
ranges = <0x0200 0 0x1600
  0x1600 0 0x10>;
 
+   bus-range = <0x00 0xff>;
+
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &pci2_intc 1>,
<0 0 0 2 &pci2_intc 2>,
-- 
2.7.4

Re: [GIT PULL] Thermal management updates for v4.17-rc1

[Bartlomiej Zolnierkiewicz]

On Thursday, April 12, 2018 09:08:57 PM Eduardo Valentin wrote:
> Hello,

Hi,

> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui  wrote:
> > >
> > > could you please illustrate me what the kconfig & warning is?
> > 
> > Just "make allmodconfig" and the warning is about a uninitialized variable.
> > 
> > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell history
> > is to be believed.
> > 
> > Linus
> 
> Yeah, this has also passed my local compilation error. Somehow my gcc4.9
> is not catching it. Using an older gcc (gcc4.6) does catch it.
> 
> Anyways, given that the conversion functions are written to cover
> for unexpected cal_type, the right way of fixing this is to rewrite
> the conversion functions to allow for returning error codes and
> adjusting the callers as expected.
> 
> Rui, bzolnier, please consider the following fix:
> 
> From 2aaf94f80c0021a21b4122c9f4197acff08ea398 Mon Sep 17 00:00:00 2001
> From: Eduardo Valentin 
> Date: Thu, 12 Apr 2018 21:00:48 -0700
> Subject: [PATCH 1/1] thermal: exynos: fix compilation warning around
>  conversion functions
> 
> In order to fix the warns:
> drivers/thermal/samsung/exynos_tmu.c:931:37: warning: 'temp' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
> drivers/thermal/samsung/exynos_tmu.c:304:9: warning: 'temp_code' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
> 
> the conversion functions should allow return error codes
> and the not mix the converted value with error code.
> 
> This patch change the conversion functions to return
> error code or success and adjusts the callers accordingly.
> 
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/samsung/exynos_tmu.c | 120 
> ---
>  1 file changed, 84 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 2ec8548..b3f0704 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -282,52 +282,54 @@ static void exynos_report_trigger(struct 
> exynos_tmu_data *p)
>   * TMU treats temperature as a mapped temperature code.
>   * The temperature is converted differently depending on the calibration 
> type.
>   */
> -static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
> +static int temp_to_code(struct exynos_tmu_data *data, u8 temp, int 
> *temp_code)
>  {
> - int temp_code;
> + int ret = 0;
>  
>   switch (data->cal_type) {
>   case TYPE_TWO_POINT_TRIMMING:
> - temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
> + *temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
>   (data->temp_error2 - data->temp_error1) /
>   (EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) +
>   data->temp_error1;
>   break;
>   case TYPE_ONE_POINT_TRIMMING:
> - temp_code = temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
> + *temp_code = temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
>   break;
>   default:

Since this condition cannot happen (the driver makes sure of this during
probe) I would prefer much simpler fix from Arnd:

https://patchwork.kernel.org/patch/10313313/

(I've already ACKed it two weeks ago).

>   WARN_ON(1);
> + ret = -EINVAL;
>   break;
>   }
>  
> - return temp_code;
> + return ret;
>  }
>  
>  /*
>   * Calculate a temperature value from a temperature code.
>   * The unit of the temperature is degree Celsius.
>   */
> -static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
> +static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code, int 
> *temp)
>  {
> - int temp;
> + int ret = 0;
>  
>   switch (data->cal_type) {
>   case TYPE_TWO_POINT_TRIMMING:
> - temp = (temp_code - data->temp_error1) *
> + *temp = (temp_code - data->temp_error1) *
>   (EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) /
>   (data->temp_error2 - data->temp_error1) +
>   EXYNOS_FIRST_POINT_TRIM;
>   break;
>   case TYPE_ONE_POINT_TRIMMING:
> - temp = temp_code - data->temp_error1 + EXYNOS_FIRST_POINT_TRIM;
> + *temp = temp_code - data->temp_error1 + EXYNOS_FIRST_POINT_TRIM;
>   break;
>   default:
>   WARN_ON(1);
> + ret = -EINVAL;

ditto

>   break;
>   }
>  
> - return temp;
> + return ret;
>  }

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

Re: [PATCH v7 06/26] timer: Export next wakeup time of a CPU

[Rafael J. Wysocki]

On Thu, Apr 12, 2018 at 1:14 PM, Ulf Hansson  wrote:
> From: Lina Iyer 
>
> Knowing the sleep duration of CPUs, is known to be needed while selecting
> the most energy efficient idle state for a CPU or a group of CPUs.
>
> However, to be able to compute the sleep duration, we need to know at what
> time the next expected wakeup is for the CPU. Therefore, let's export this
> information via a new function, tick_nohz_get_next_wakeup(). Following
> changes make use of it.
>
> Cc: Thomas Gleixner 
> Cc: Daniel Lezcano 
> Cc: Lina Iyer 
> Cc: Frederic Weisbecker 
> Cc: Ingo Molnar 
> Signed-off-by: Lina Iyer 
> Co-developed-by: Ulf Hansson 
> Signed-off-by: Ulf Hansson 
> ---
>  include/linux/tick.h | 10 ++
>  kernel/time/tick-sched.c | 11 +++
>  2 files changed, 21 insertions(+)
>
> diff --git a/include/linux/tick.h b/include/linux/tick.h
> index 389aa25..d341811 100644
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -125,6 +125,7 @@ extern bool tick_nohz_idle_got_tick(void);
>  extern ktime_t tick_nohz_get_sleep_length(ktime_t *delta_next);
>  extern unsigned long tick_nohz_get_idle_calls(void);
>  extern unsigned long tick_nohz_get_idle_calls_cpu(int cpu);
> +extern ktime_t tick_nohz_get_next_wakeup(int cpu);
>  extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
>  extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
>
> @@ -151,6 +152,15 @@ static inline ktime_t tick_nohz_get_sleep_length(ktime_t 
> *delta_next)
> *delta_next = TICK_NSEC;
> return *delta_next;
>  }
> +
> +static inline ktime_t tick_nohz_get_next_wakeup(int cpu)
> +{
> +   ktime_t t;
> +
> +   /* Next wake up is the tick period, assume it starts now */
> +   return ktime_add(tick_nohz_get_sleep_length(&t), ktime_get());
> +}

Well, given that tick_nohz_get_sleep_length() is just the above in
this case, wouldn't it be simpler to return ktime_add(ktime_get(),
TICK_NSEC) from here?

> +
>  static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) { return -1; }
>  static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return -1; }
>
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 646645e..08db7f3 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -1098,6 +1098,17 @@ unsigned long tick_nohz_get_idle_calls(void)
> return ts->idle_calls;
>  }
>
> +/**
> + * tick_nohz_get_next_wakeup - return the next wake up of the CPU
> + */
> +ktime_t tick_nohz_get_next_wakeup(int cpu)
> +{
> +   struct clock_event_device *dev =
> +   per_cpu(tick_cpu_device.evtdev, cpu);

I would avoid breaking the line, honestly.

If you really really want to avoid going above the 80 chars line
length limit, why don't you do

struct clock_event_device *dev;

dev = per_cpu(tick_cpu_device.evtdev, cpu);

> +
> +   return dev->next_event;
> +}
> +
>  static void tick_nohz_account_idle_ticks(struct tick_sched *ts)
>  {
>  #ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
> --

[GIT PULL] overlayfs update for 4.17

[Miklos Szeredi]

Hi Linus,

Please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-linus

In addition to bug fixes and cleanups there are two new features from Amir:

 - Consistent inode number support for the case when layers are not all on
   the same filesystem (feature is dubbed "xino").

 - Optimize overlayfs file handle decoding.  This one touches the exportfs
   interface to allow detecting the disconnected directory case.

Most of the code has been sitting in -next for a while now, but was rebased
due to a bug fix coming in yesterday.  I decided in favor of rebasing on
top of that fix to allow automatic stable backporting.

Thanks,
Miklos

---
Amir Goldstein (13):
  ovl: set i_ino to the value of st_ino for NFS export
  ovl: fix lookup with middle layer opaque dir and absolute path redirects
  ovl: set lower layer st_dev only if setting lower st_ino
  ovl: disambiguate ovl_encode_fh()
  ovl: do not try to reconnect a disconnected origin dentry
  ovl: lookup in inode cache first when decoding lower file handle
  ovl: factor out ovl_map_dev_ino() helper
  ovl: allocate anon bdev per unique lower fs
  ovl: constant st_ino for non-samefs with xino
  ovl: consistent i_ino for non-samefs with xino
  ovl: consistent d_ino for non-samefs with xino
  ovl: add support for "xino" mount and config options
  ovl: update documentation w.r.t "xino" feature

Miklos Szeredi (2):
  ovl: add WARN_ON() for non-dir redirect cases
  ovl: cleanup ovl_update_time()

Vivek Goyal (4):
  ovl: Set d->last properly during lookup
  ovl: Do not check for redirect if this is last layer
  ovl: set d->is_dir and d->opaque for last path element
  ovl: cleanup setting OVL_INDEX

---
 Documentation/filesystems/overlayfs.txt |  39 ++-
 fs/exportfs/expfs.c |   9 ++
 fs/overlayfs/Kconfig|  17 +++
 fs/overlayfs/copy_up.c  |   6 +-
 fs/overlayfs/export.c   |  75 +++--
 fs/overlayfs/inode.c| 188 
 fs/overlayfs/namei.c|  67 
 fs/overlayfs/overlayfs.h|  19 +++-
 fs/overlayfs/ovl_entry.h|  21 +++-
 fs/overlayfs/readdir.c  |  45 +++-
 fs/overlayfs/super.c| 157 ++
 fs/overlayfs/util.c |  39 ++-
 12 files changed, 510 insertions(+), 172 deletions(-)

Re: Query:Regarding percpu_counter debug object destroy

[Kohli, Gaurav]

Hi Nikolay,

Thanks for the comment.

I agree ,like timer , hrtimer we have to mark inactive in destroy function and 
finally freeing the debug object

after destruction of percpu_counter.

But i am still not sure that this double freeing with same address may create 
race or not in debug_object list.

Regards

Gaurav

On 4/13/2018 1:12 PM, Nikolay Borisov wrote:



On 13.04.2018 10:32, Kohli, Gaurav wrote:

Hi ,

I have checked below code and it seems we are calling debug_object_free
twice, ideally we should deactivate and later we
have to destroy.

1st call -> percpu_counter_destroy->debug_percpu_counter_deactivate ->
debug_object_free
2nd call ->
debug_object_free



static bool percpu_counter_fixup_free(void *addr, enum debug_obj_state
state)
{
     struct percpu_counter *fbc = addr;

     switch (state) {
     case ODEBUG_STATE_ACTIVE:
     percpu_counter_destroy(fbc);  -> first call
     debug_object_free(fbc, &percpu_counter_debug_descr); 2nd


Having looked at the code I'd say this is indeed buggy. I'd say it
stemmed from same cargo culting since timer_fixup_free follows the same
structure of code, except that in del_timer_sync there is no code which
does debug_object_free. The situation is similar in work_fixup_free.

So at this point I guess the question is whether we want to leave the
debug_object_free call in percpu_counter_fixup_free and just remove
debug_percpu_counter_deactivate and open-code the call to
debug_object_deactivate in percpu_counter_destroy. Or remove the
explicit call in percpu_counter_fixup_free and leave
debug_percpu_counter_deactivate.


In the end it's a matter of style, so perhaps Tejun, as the maintainer,
has the final say what style he prefers. Personally, I'd go for the
former solution so that the percpu follows the style of the rest of the
kernel.


call
     return true;
     default:
     return false;
     }
}


We are seeing one issue, where one list contain garbage data in
obj_hash, just before element of that is percpu_counter but
still not sure as it is very difficult to reproduce.

Can some one please review above code or can we remove one instance of
debug_object_free from above code.

Regards
Gaurav



--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH] mm, slab: reschedule cache_reap() on the same CPU

[Vlastimil Babka]

On 04/12/2018 02:47 AM, Minchan Kim wrote:
> On Wed, Apr 11, 2018 at 09:00:07AM +0200, Vlastimil Babka wrote:
>> cache_reap() is initially scheduled in start_cpu_timer() via
>> schedule_delayed_work_on(). But then the next iterations are scheduled via
>> schedule_delayed_work(), i.e. using WORK_CPU_UNBOUND.
>>
>> Thus since commit ef557180447f ("workqueue: schedule WORK_CPU_UNBOUND work on
>> wq_unbound_cpumask CPUs") there is no guarantee the future iterations will 
>> run
>> on the originally intended cpu, although it's still preferred. I was able to
>> demonstrate this with /sys/module/workqueue/parameters/debug_force_rr_cpu.
>> IIUC, it may also happen due to migrating timers in nohz context. As a 
>> result,
>> some cpu's would be calling cache_reap() more frequently and others never.
>>
>> This patch uses schedule_delayed_work_on() with the current cpu when 
>> scheduling
>> the next iteration.
> 
> Could you write down part about "so what's the user effect on some 
> condition?".
> It would really help to pick up the patch.

Ugh, so let's continue the last paragraph with something like:

After this patch, cache_reap() executions will always remain on the
expected cpu. This can save some memory that could otherwise remain
indefinitely in array caches of some cpus or nodes, and prevent waste of
cpu cycles by executing cache_reap() too often on other cpus.

Re: [PATCH 1/7] sched/core: uclamp: add CPU clamp groups accounting

[Peter Zijlstra]

On Mon, Apr 09, 2018 at 05:56:09PM +0100, Patrick Bellasi wrote:
> +static inline void uclamp_task_update(struct rq *rq, struct task_struct *p)
> +{
> + int cpu = cpu_of(rq);
> + int clamp_id;
> +
> + /* The idle task does not affect CPU's clamps */
> + if (unlikely(p->sched_class == &idle_sched_class))
> + return;
> + /* DEADLINE tasks do not affect CPU's clamps */
> + if (unlikely(p->sched_class == &dl_sched_class))
> + return;
> +
> + for (clamp_id = 0; clamp_id < UCLAMP_CNT; ++clamp_id) {
> + if (uclamp_task_affects(p, clamp_id))
> + uclamp_cpu_put(p, cpu, clamp_id);
> + else
> + uclamp_cpu_get(p, cpu, clamp_id);
> + }
> +}

Is that uclamp_task_affects() thing there to fix up the fact you failed
to propagate the calling context (enqueue/dequeue) ?

I find this code _really_ hard to read...

> @@ -743,6 +929,7 @@ static inline void enqueue_task(struct rq *rq, struct 
> task_struct *p, int flags)
>   if (!(flags & ENQUEUE_RESTORE))
>   sched_info_queued(rq, p);
>  
> + uclamp_task_update(rq, p);
>   p->sched_class->enqueue_task(rq, p, flags);
>  }
>  
> @@ -754,6 +941,7 @@ static inline void dequeue_task(struct rq *rq, struct 
> task_struct *p, int flags)
>   if (!(flags & DEQUEUE_SAVE))
>   sched_info_dequeued(rq, p);
>  
> + uclamp_task_update(rq, p);
>   p->sched_class->dequeue_task(rq, p, flags);
>  }
>  

Re: [PATCH 2/2] f2fs: support {d,id,did,x}node checksum

[Chao Yu]

Ping again..

Do you have time to discuss this?

On 2018/2/27 22:16, Chao Yu wrote:
> Ping,
> 
> On 2018/2/13 15:34, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2018/2/10 10:52, Chao Yu wrote:
>>> On 2018/2/10 9:41, Jaegeuk Kim wrote:
 On 02/01, Chao Yu wrote:
>
>
> On 2018/2/1 6:15, Jaegeuk Kim wrote:
>> On 01/31, Chao Yu wrote:
>>> On 2018/1/31 10:02, Jaegeuk Kim wrote:
 What if we want to add more entries in addition to node_checksum? Do 
 we have
 to add a new feature flag at every time? How about adding a layout 
 value instead
>>>
>>> Hmm.. for previous implementation, IMO, we'd better add a new feature 
>>> flag at
>>> every time, otherwise, w/ extra_nsize only, in current image, we can 
>>> know a
>>> valid range of extended area in node block, but we don't know which
>>> fields/features are valid/enabled or not.
>>>
>>> One more thing is that if we can add one feature flag for each field, 
>>> we got one
>>> more chance to disable it dynamically.
>>>
 of extra_nsize? For example, layout #1 means node_checksum with 
 extra_nsize=X?


 What does 1017 mean? We need to make this structure more flexibly for 
 new
>>>
>>> Yes, using raw 1017 is not appropriate here.
>>>
 entries. Like this?
union {
struct node_v1;
struct node_v2;
struct node_v3;
...
struct direct_node dn;
struct indirect_node in;
};
};

struct node_v1 {
__le32 data[DEF_ADDRS_PER_BLOCK - V1_NSIZE=1];
__le32 node_checksum;
}

struct node_v2 {
__le32 data[DEF_ADDRS_PER_BLOCK - V2_NSIZE=500];
>>>
>>> Hmm.. If we only need to add one more 4 bytes field in struct node_v2, 
>>> but
>>> V2_NSIZE is defined as fixed 500, there must be 492 bytes wasted.
>>>
>>> Or we can define V2_NSIZE as 8, but if there comes more and more 
>>> extended
>>> fields, node version count can be a large number, it results in 
>>> complicated
>>> version recognization and handling.
>>>
>>> One more question is how can we control which fields are valid or not in
>>> comp[Vx_NSIZE]?
>>>
>>>
>>> Anyway, what I'm thinking is maybe we can restructure layout of node 
>>> block like
>>> the one used by f2fs_inode:
>>>
>>> struct f2fs_node {
>>> union {
>>> struct f2fs_inode i;
>>> union {
>>> struct {
>>> __le32 node_checksum;
>>> __le32 feature_field_1;
>>> __le32 feature_field_2;
>>> 
>>> __le32 addr[];
>>> 
>>> };
>>> struct direct_node dn;
>>> struct indirect_node in;
>>> };
>>> };
>>> struct node_footer footer;
>>> } __packed;
>>>
>>> Moving all extended fields to the head of f2fs_node, so we don't have 
>>> to use
>>> macro to indicate actual size of addr.
>>
>> Thinking what'd be the best way. My concern is, once getting more 
>> entries, we
>
> OK, I think we need more discussion.. ;)
>
>> can't set each of features individually. Like the second entry should 
>> have
>
> Oh, that will be hard. If we have to avoid that, we have to tag in 
> somewhere
> e.g. f2fs_inode::i_flags2 to indicate which new field in f2fs_node is 
> valid, for
> example:
>
> #define F2FS_NODE_CHECKSUM0x0001
> #define F2FS_NODE_FIELD1  0x0002
> #define F2FS_NODE_FIELD2  0x0004
>
>   union {
>   struct {
>   __le32 node_checksum;
>   __le32 field_1;
>   __le32 field_2;
>   
>   __le32 addr[];
>   };
>   struct direct_node dn;
>   struct indirect_node in;
>   };
>
> f2fs_inode::i_flags2 = F2FS_NODE_CHECKSUM | F2FS_NODE_FIELD1
> indicates that f2fs_node::node_checksum and f2fs_node::field_1 are valid;
>
> f2fs_inode::i_flags2 = F2FS_NODE_FIELD1 | F2FS_NODE_FIELD2
> indicates that f2fs_node::field_1 and f2fs_node::field_2 are valid.

 So, that's why I thought we may need a sort of each formats.
>>>
>>> Hmm.. if we have two new added fields, there are (2 << 2) c

Re: [PATCH 1/7] sched/core: uclamp: add CPU clamp groups accounting

[Peter Zijlstra]

On Mon, Apr 09, 2018 at 05:56:09PM +0100, Patrick Bellasi wrote:
> +static inline void init_uclamp(void)

WTH is that inline?

> +{
> + struct uclamp_cpu *uc_cpu;
> + int clamp_id;
> + int cpu;
> +
> + mutex_init(&uclamp_mutex);
> +
> + for (clamp_id = 0; clamp_id < UCLAMP_CNT; ++clamp_id) {
> + /* Init CPU's clamp groups */
> + for_each_possible_cpu(cpu) {
> + uc_cpu = &cpu_rq(cpu)->uclamp[clamp_id];
> + memset(uc_cpu, UCLAMP_NONE, sizeof(struct uclamp_cpu));
> + }
> + }

Those loops are the wrong way around, this shreds your cache. This is a
slow path so it doesn't much matter, but it is sloppy.

> +}

Re: [PATCH v2 2/2] dmaengine: stm32-mdma: Fix incomplete Hw descriptors allocator

[Geert Uytterhoeven]

Hi Vinod,

On Fri, Apr 13, 2018 at 6:02 AM, Vinod Koul  wrote:
> On Wed, Apr 11, 2018 at 04:44:39PM +0200, Pierre-Yves MORDRET wrote:
>
>>  struct stm32_mdma_desc {
>>   struct virt_dma_desc vdesc;
>>   u32 ccr;
>> - struct stm32_mdma_hwdesc *hwdesc;
>> - dma_addr_t hwdesc_phys;
>>   bool cyclic;
>>   u32 count;
>> + struct stm32_mdma_desc_node node[];
>
> some ppl use node[0] for this but i think either is fine..

node[] is the correct one, node[0] may hide future bugs, cfr. commit
a158531f3c92467d ("gpio: 74x164: Fix crash during .remove()")

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2] block: ratelimite pr_err on IO path

[Jinpu Wang]

On Thu, Apr 12, 2018 at 11:20 PM, Martin K. Petersen
 wrote:
>
> Jack,
>
>> + pr_err_ratelimited("%s: ref tag error at 
>> location %llu (rcvd %u)\n",
>
> I'm a bit concerned about dropping records of potential data loss.
>
> Also, what are you doing that compels all these to be logged? This
> should be a very rare occurrence.
>
> --
> Martin K. Petersen  Oracle Linux Engineering
Hi Martin,

Thanks for asking, we updated mpt3sas driver which enables DIX support
(prot_mask=0x7f), all disks are SATA SSDs, no DIF support.
After reboot, kernel reports the IO errors from all the drives behind
HBA, seems for almost every read IO, which turns the system unusable:
[   13.079375] sda: ref tag error at location 0 (rcvd 143196159)
[   13.079989] sda: ref tag error at location 937702912 (rcvd 143196159)
[   13.080233] sda: ref tag error at location 937703072 (rcvd 143196159)
[   13.080407] sda: ref tag error at location 0 (rcvd 143196159)
[   13.080594] sda: ref tag error at location 8 (rcvd 143196159)
[   13.080996] sda: ref tag error at location 0 (rcvd 143196159)
[   13.089878] sdb: ref tag error at location 0 (rcvd 143196159)
[   13.090275] sdb: ref tag error at location 937702912 (rcvd 277413887)
[   13.090448] sdb: ref tag error at location 937703072 (rcvd 143196159)
[   13.090655] sdb: ref tag error at location 0 (rcvd 143196159)
[   13.090823] sdb: ref tag error at location 8 (rcvd 277413887)
[   13.091218] sdb: ref tag error at location 0 (rcvd 143196159)
[   13.095412] sdc: ref tag error at location 0 (rcvd 143196159)
[   13.095859] sdc: ref tag error at location 937702912 (rcvd 143196159)
[   13.096058] sdc: ref tag error at location 937703072 (rcvd 143196159)
[   13.096228] sdc: ref tag error at location 0 (rcvd 143196159)
[   13.096445] sdc: ref tag error at location 8 (rcvd 143196159)
[   13.096833] sdc: ref tag error at location 0 (rcvd 277413887)
[   13.097187] sds: ref tag error at location 0 (rcvd 277413887)
[   13.097707] sds: ref tag error at location 937702912 (rcvd 143196159)
[   13.097855] sds: ref tag error at location 937703072 (rcvd 277413887)

Kernel version 4.15 and 4.14.28, I scan the commits in upstream,
haven't found any relevant.
in  4.4.112, there's no such errors.
Diable DIX support (prot_mask=0x7) in mpt3sas fixes the problem.

Regards,
-- 
Jack Wang
Linux Kernel DeveloperProfitBricks GmbH

Re: [RFC PATCH v2 2/6] sched: Introduce energy models of CPUs

[Quentin Perret]

On Friday 13 Apr 2018 at 09:32:53 (+0530), Viresh Kumar wrote:
[...]
> And for the whole OPP discussion, perhaps we should have another
> architecture specific callback which the scheduler can call to get a
> ready-made energy model with all the structures filled in. That way
> the OPP specific stuff will move to the architecture specific
> callback.

Yes, that's another possible solution indeed. Actually, it's already on
the list of ideas to be dicussed in OSPM ;-)

Thanks,
Quentin

[PATCH] MAINTAINERS: add personal addresses for Sascha and me

[Uwe Kleine-König]

The idea behind using ker...@pengutronix.de (i.e. the mail alias for the
kernel people at Pengutronix) as email address was to have a backup when
a given developer is on vacation or run over by a bus. Make this more
explicit by adding the alias as reviewer and use the personal address
for Sascha and me.

Acked-by: Sascha Hauer 
Signed-off-by: Uwe Kleine-König 
---
Hello,

I'm not sure how feels responsible to apply such a patch. Maybe akpm?

Best regards
Uwe

 MAINTAINERS | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d948bb..efcc1794eea7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1373,7 +1373,8 @@ F:arch/arm/mach-ebsa110/
 F: drivers/net/ethernet/amd/am79c961a.*
 
 ARM/ENERGY MICRO (SILICON LABS) EFM32 SUPPORT
-M: Uwe Kleine-König 
+M: Uwe Kleine-König 
+R: Pengutronix Kernel Team 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 N: efm32
@@ -1401,7 +1402,8 @@ F:arch/arm/mach-footbridge/
 
 ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
 M: Shawn Guo 
-M: Sascha Hauer 
+M: Sascha Hauer 
+R: Pengutronix Kernel Team 
 R: Fabio Estevam 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
@@ -1416,7 +1418,8 @@ F:include/soc/imx/
 
 ARM/FREESCALE VYBRID ARM ARCHITECTURE
 M: Shawn Guo 
-M: Sascha Hauer 
+M: Sascha Hauer 
+R: Pengutronix Kernel Team 
 R: Stefan Agner 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
@@ -5653,7 +5656,8 @@ F:drivers/net/ethernet/freescale/fec.h
 F: Documentation/devicetree/bindings/net/fsl-fec.txt
 
 FREESCALE IMX / MXC FRAMEBUFFER DRIVER
-M: Sascha Hauer 
+M: Sascha Hauer 
+R: Pengutronix Kernel Team 
 L: linux-fb...@vger.kernel.org
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
@@ -12790,7 +12794,8 @@ F:  include/linux/siphash.h
 
 SIOX
 M: Gavin Schenk 
-M: Uwe Kleine-König 
+M: Uwe Kleine-König 
+R: Pengutronix Kernel Team 
 S: Supported
 F: drivers/siox/*
 F: include/trace/events/siox.h
-- 
2.16.3

Re: KMSAN: uninit-value in __netif_receive_skb_core

[Dmitry Vyukov]

On Fri, Apr 13, 2018 at 10:20 AM, Toshiaki Makita
 wrote:
> On 2018/04/12 17:03, Dmitry Vyukov wrote:
>> On Thu, Apr 12, 2018 at 10:01 AM, syzbot
>>  wrote:
>>> Hello,
>>>
>>> syzbot hit the following crash on https://github.com/google/kmsan.git/master
>>> commit
>>> e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +)
>>> kmsan: temporarily disable visitAsmInstruction() to help syzbot
>>> syzbot dashboard link:
>>> https://syzkaller.appspot.com/bug?extid=b202b7208664142954fa
>>>
>>> Unfortunately, I don't have any reproducer for this crash yet.
>>> Raw console output:
>>> https://syzkaller.appspot.com/x/log.txt?id=535651643762
>>> Kernel config:
>>> https://syzkaller.appspot.com/x/.config?id=6627248707860932248
>>> compiler: clang version 7.0.0 (trunk 329391)
>>
>> +Toshiaki as this seems to be related to the recent vlan tagging changes.
>
> seems not...
> "Uninit was stored to memory at:" shows uninitialized memory was stored
> before where I modified the code (skb_reorder_vlan_header).
>
> I'm not sure what this uninit memory means.
> To me it looks like the memory is initialized by user provided data.
>
> (iov in packet sock -> skb->data -> skb->protocol)
>
> The reproducer provides 4 bytes after ethernet header, so it should be
> sufficient for a vlan tag. This will set skb->len to 4 and fill the
> 4-byte contents in packet_snd(). skb_vlan_untag() is reading the user
> provided 4-byte skb->data. It is ensured that skb_vlan_untag() does not
> read beyond skb->len since it calls pskb_may_pull(). At this point I am
> failing to find what I am missing.

Eric,

You mentioned something about assumption that the
__vlan_insert_inner_tag() helper would only be called from
__netif_receive_skb_core(). Can you elaborate?



>> This also seems to be related to
>> https://groups.google.com/d/msg/syzkaller-bugs/VRH9NnUi2k0/90GYsAeRBgAJ
>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+b202b720866414295...@syzkaller.appspotmail.com
>>> It will help syzbot understand when the bug is fixed. See footer for
>>> details.
>>> If you forward the report, please keep this part and the footer.
>>>
>>> ==
>>> BUG: KMSAN: uninit-value in __read_once_size include/linux/compiler.h:197
>>> [inline]
>>> BUG: KMSAN: uninit-value in deliver_ptype_list_skb net/core/dev.c:1908
>>> [inline]
>>> BUG: KMSAN: uninit-value in __netif_receive_skb_core+0x4630/0x4a80
>>> net/core/dev.c:4545
>>> CPU: 0 PID: 5999 Comm: syz-executor3 Not tainted 4.16.0+ #82
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> Call Trace:
>>>  
>>>  __dump_stack lib/dump_stack.c:17 [inline]
>>>  dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>>>  kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>>>  __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
>>>  __read_once_size include/linux/compiler.h:197 [inline]
>>>  deliver_ptype_list_skb net/core/dev.c:1908 [inline]
>>>  __netif_receive_skb_core+0x4630/0x4a80 net/core/dev.c:4545
>>>  __netif_receive_skb net/core/dev.c:4627 [inline]
>>>  process_backlog+0x62d/0xe20 net/core/dev.c:5307
>>>  napi_poll net/core/dev.c:5705 [inline]
>>>  net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
>>>  __do_softirq+0x56d/0x93d kernel/softirq.c:285
>>>  do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040
>>>  
>>>  do_softirq kernel/softirq.c:329 [inline]
>>>  __local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
>>>  local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
>>>  rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
>>>  __dev_queue_xmit+0x2a31/0x2b60 net/core/dev.c:3584
>>>  dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
>>>  packet_snd net/packet/af_packet.c:2944 [inline]
>>>  packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969
>>>  sock_sendmsg_nosec net/socket.c:630 [inline]
>>>  sock_sendmsg net/socket.c:640 [inline]
>>>  sock_write_iter+0x3b9/0x470 net/socket.c:909
>>>  do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
>>>  do_iter_write+0x30d/0xd40 fs/read_write.c:932
>>>  vfs_writev fs/read_write.c:977 [inline]
>>>  do_writev+0x3c9/0x830 fs/read_write.c:1012
>>>  SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
>>>  SyS_writev+0x56/0x80 fs/read_write.c:1082
>>>  do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>>>  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>>> RIP: 0033:0x455259
>>> RSP: 002b:7fb53ede8c68 EFLAGS: 0246 ORIG_RAX: 0014
>>> RAX: ffda RBX: 7fb53ede96d4 RCX: 00455259
>>> RDX: 0001 RSI: 200010c0 RDI: 0013
>>> RBP: 0072bea0 R08:  R09: 
>>> R10:  R11: 0246 R12: 
>>> R13: 06cd R14: 006fd3d8 R15: 
>>>
>>> Uninit was stored to memory at:
>>>  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
>>>  kmsa

Re: [PATCH v2] block: do not use interruptible wait anywhere

[Johannes Thumshirn]

Hi Alan,

On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote:
> # dd if=/dev/sda of=/dev/null iflag=direct & \
>   while killall -SIGUSR1 dd; do sleep 0.1; done & \
>   echo mem > /sys/power/state ; \
>   sleep 5; killall dd  # stop after 5 seconds

Can you please also add a regression test to blktests[1] for this?

[1] https://github.com/osandov/blktests

Thanks,
Johannes
-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: KMSAN: uninit-value in netif_skb_features

[Toshiaki Makita]

On 2018/04/12 17:03, Dmitry Vyukov wrote:
> On Thu, Apr 12, 2018 at 10:01 AM, syzbot
>  wrote:
>> Hello,
>>
>> syzbot hit the following crash on https://github.com/google/kmsan.git/master
>> commit
>> e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +)
>> kmsan: temporarily disable visitAsmInstruction() to help syzbot
>> syzbot dashboard link:
>> https://syzkaller.appspot.com/bug?extid=0bbe42c764feafa82c5a
>>
>> So far this crash happened 30 times on
>> https://github.com/google/kmsan.git/master.
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4850744041668608
>> syzkaller reproducer:
>> https://syzkaller.appspot.com/x/repro.syz?id=6289386287136768
>> Raw console output:
>> https://syzkaller.appspot.com/x/log.txt?id=4577411249209344
>> Kernel config:
>> https://syzkaller.appspot.com/x/.config?id=6627248707860932248
>> compiler: clang version 7.0.0 (trunk 329391)
> 
> +Toshiaki as this seems to be related to the recent vlan tagging changes.

Seems not.
Probably skb_vlan_tagged_multi() needs to call pskb_may_pull() before
accessing skb->data? I'll confirm it later.

> This also seems to be related to
> https://groups.google.com/d/msg/syzkaller-bugs/FNEavkB4QaM/efXl2AeRBgAJ
> 
> 
> 
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+0bbe42c764feafa82...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> ==
>> BUG: KMSAN: uninit-value in eth_type_vlan include/linux/if_vlan.h:283
>> [inline]
>> BUG: KMSAN: uninit-value in skb_vlan_tagged_multi
>> include/linux/if_vlan.h:656 [inline]
>> BUG: KMSAN: uninit-value in vlan_features_check include/linux/if_vlan.h:672
>> [inline]
>> BUG: KMSAN: uninit-value in dflt_features_check net/core/dev.c:2949 [inline]
>> BUG: KMSAN: uninit-value in netif_skb_features+0xd1b/0xdc0
>> net/core/dev.c:3009
>> CPU: 1 PID: 3582 Comm: syzkaller435149 Not tainted 4.16.0+ #82
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>>  kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
>>  __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
>>  eth_type_vlan include/linux/if_vlan.h:283 [inline]
>>  skb_vlan_tagged_multi include/linux/if_vlan.h:656 [inline]
>>  vlan_features_check include/linux/if_vlan.h:672 [inline]
>>  dflt_features_check net/core/dev.c:2949 [inline]
>>  netif_skb_features+0xd1b/0xdc0 net/core/dev.c:3009
>>  validate_xmit_skb+0x89/0x1320 net/core/dev.c:3084
>>  __dev_queue_xmit+0x1cb2/0x2b60 net/core/dev.c:3549
>>  dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
>>  packet_snd net/packet/af_packet.c:2944 [inline]
>>  packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969
>>  sock_sendmsg_nosec net/socket.c:630 [inline]
>>  sock_sendmsg net/socket.c:640 [inline]
>>  sock_write_iter+0x3b9/0x470 net/socket.c:909
>>  do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
>>  do_iter_write+0x30d/0xd40 fs/read_write.c:932
>>  vfs_writev fs/read_write.c:977 [inline]
>>  do_writev+0x3c9/0x830 fs/read_write.c:1012
>>  SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
>>  SyS_writev+0x56/0x80 fs/read_write.c:1082
>>  do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>>  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>> RIP: 0033:0x43ffa9
>> RSP: 002b:7fff2cff3948 EFLAGS: 0217 ORIG_RAX: 0014
>> RAX: ffda RBX: 004002c8 RCX: 0043ffa9
>> RDX: 0001 RSI: 2080 RDI: 0003
>> RBP: 006cb018 R08:  R09: 
>> R10:  R11: 0217 R12: 004018d0
>> R13: 00401960 R14:  R15: 
>>
>> Uninit was created at:
>>  kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
>>  kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
>>  kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
>>  kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
>>  slab_post_alloc_hook mm/slab.h:445 [inline]
>>  slab_alloc_node mm/slub.c:2737 [inline]
>>  __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
>>  __kmalloc_reserve net/core/skbuff.c:138 [inline]
>>  __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
>>  alloc_skb include/linux/skbuff.h:984 [inline]
>>  alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
>>  sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
>>  packet_alloc_skb net/packet/af_packet.c:2803 [inline]
>>  packet_snd net/packet/af_packet.c:2894 [inline]
>>  packet_sendmsg+0x6444/0x8a10 net/packet/af_packet.c:2969
>>  sock_sendmsg_nosec net/socket.c:630 [inline]
>>  sock_sendmsg net/socket.c:640 [inline]
>>  sock_write_iter+0x3b9/0x470 net/socket.c:909
>>  do_iter_readv_writev+0x7bb/0x970 include/lin

Re: [PATCH 1/7] sched/core: uclamp: add CPU clamp groups accounting

[Peter Zijlstra]

On Mon, Apr 09, 2018 at 05:56:09PM +0100, Patrick Bellasi wrote:
> +static inline void uclamp_cpu_get(struct task_struct *p, int cpu, int 
> clamp_id)
> +{
> + struct uclamp_cpu *uc_cpu = &cpu_rq(cpu)->uclamp[clamp_id];

> +static inline void uclamp_cpu_put(struct task_struct *p, int cpu, int 
> clamp_id)
> +{
> + struct uclamp_cpu *uc_cpu = &cpu_rq(cpu)->uclamp[clamp_id];

That all seems daft, since you already have rq at the call site.

> +static inline void uclamp_task_update(struct rq *rq, struct task_struct *p)
> +{
> + int cpu = cpu_of(rq);
> + int clamp_id;
> +
> + /* The idle task does not affect CPU's clamps */
> + if (unlikely(p->sched_class == &idle_sched_class))
> + return;
> + /* DEADLINE tasks do not affect CPU's clamps */
> + if (unlikely(p->sched_class == &dl_sched_class))
> + return;

This is wrong; it misses the stop_sched_class.

And since you're looking at sched_class anyway, maybe put a marker in
there:

if (!p->sched_class->has_clamping)
return;

> + for (clamp_id = 0; clamp_id < UCLAMP_CNT; ++clamp_id) {
> + if (uclamp_task_affects(p, clamp_id))
> + uclamp_cpu_put(p, cpu, clamp_id);
> + else
> + uclamp_cpu_get(p, cpu, clamp_id);
> + }
> +}

Re: [RFC PATCH 04/35] ovl: copy up times

[Amir Goldstein]

On Thu, Apr 12, 2018 at 6:07 PM, Miklos Szeredi  wrote:
> Copy up mtime and ctime to overlay inode after times in real object are
> modified.  Be careful not to dirty cachelines when not necessary.
>
> This is in preparation for moving overlay functionality out of the VFS.
>
> This patch shouldn't have any observable effect.
>
> Signed-off-by: Miklos Szeredi 
> ---
>  fs/overlayfs/dir.c   |  5 +
>  fs/overlayfs/inode.c |  1 +
>  fs/overlayfs/overlayfs.h |  7 +++
>  fs/overlayfs/util.c  | 19 +++
>  4 files changed, 32 insertions(+)
>
> diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
> index 839709c7803a..cd0fa2363723 100644
> --- a/fs/overlayfs/dir.c
> +++ b/fs/overlayfs/dir.c
> @@ -507,6 +507,7 @@ static int ovl_create_or_link(struct dentry *dentry, 
> struct inode *inode,
> else
> err = ovl_create_over_whiteout(dentry, inode, attr,
> hardlink);
> +   ovl_copytimes_with_parent(dentry);
> }
>  out_revert_creds:
> revert_creds(old_cred);
> @@ -768,6 +769,7 @@ static int ovl_do_remove(struct dentry *dentry, bool 
> is_dir)
> drop_nlink(dentry->d_inode);
> }
> ovl_nlink_end(dentry, locked);
> +   ovl_copytimes_with_parent(dentry);
>  out_drop_write:
> ovl_drop_write(dentry);
>  out:
> @@ -1079,6 +1081,9 @@ static int ovl_rename(struct inode *olddir, struct 
> dentry *old,
> ovl_dentry_version_inc(new->d_parent, ovl_type_origin(old) ||
>(d_inode(new) && ovl_type_origin(new)));
>
> +   ovl_copytimes_with_parent(old);
> +   ovl_copytimes_with_parent(new);
> +

All the ovl_copytimes_with_parent() calls you added can be replaced with a
single call in ovl_dentry_version_inc(). Just need to change its name and
pass it the child instead of the parent dentry.

Thanks,
Amir.

[PATCH v3 01/12] KVM: arm/arm64: Set dist->spis to NULL after kfree

[Eric Auger]

in case kvm_vgic_map_resources() fails, typically if the vgic
distributor is not defined, __kvm_vgic_destroy will be called
several times. Indeed kvm_vgic_map_resources() is called on
first vcpu run. As a result dist->spis is freeed more than once
and on the second time it causes a "kernel BUG at mm/slub.c:3912!"

Set dist->spis to NULL to avoid the crash.

Fixes: ad275b8bb1e6 ("KVM: arm/arm64: vgic-new: vgic_init: implement
vgic_init")

Signed-off-by: Eric Auger 
Reviewed-by: Marc Zyngier 

---

v2 -> v3:
- added Marc's R-b and Fixed commit
---
 virt/kvm/arm/vgic/vgic-init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 68378fe..c52f03d 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -308,6 +308,7 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm)
dist->initialized = false;
 
kfree(dist->spis);
+   dist->spis = NULL;
dist->nr_spis = 0;
 
if (vgic_supports_direct_msis(kvm))
-- 
2.5.5

[PATCH v3 04/12] KVM: arm/arm64: Helper to locate free rdist index

[Eric Auger]

We introduce vgic_v3_rdist_free_slot to help identifying
where we can place a new 2x64KB redistributor.

Signed-off-by: Eric Auger 
---
 virt/kvm/arm/vgic/vgic-mmio-v3.c |  3 +--
 virt/kvm/arm/vgic/vgic-v3.c  | 17 +
 virt/kvm/arm/vgic/vgic.h | 11 +++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
index d1aab18..49ca176 100644
--- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
+++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
@@ -593,8 +593,7 @@ int vgic_register_redist_iodev(struct kvm_vcpu *vcpu)
 * function for all VCPUs when the base address is set.  Just return
 * without doing any work for now.
 */
-   rdreg = list_first_entry(&vgic->rd_regions,
-struct vgic_redist_region, list);
+   rdreg = vgic_v3_rdist_free_slot(&vgic->rd_regions);
if (!rdreg)
return 0;
 
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index 94de6cd..820012a 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -444,6 +444,23 @@ bool vgic_v3_check_base(struct kvm *kvm)
return false;
 }
 
+/**
+ * vgic_v3_rdist_free_slot - Look up registered rdist regions and identify one
+ * which has free space to put a new rdist regions
+ *
+ * If any, return this redist region handle, otherwise returns NULL.
+ */
+struct vgic_redist_region *vgic_v3_rdist_free_slot(struct list_head 
*rd_regions)
+{
+   struct vgic_redist_region *rdreg;
+
+   list_for_each_entry(rdreg, rd_regions, list) {
+   if (!vgic_v3_redist_region_full(rdreg))
+   return rdreg;
+   }
+   return NULL;
+}
+
 int vgic_v3_map_resources(struct kvm *kvm)
 {
int ret = 0;
diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
index 830e815..fea32cb 100644
--- a/virt/kvm/arm/vgic/vgic.h
+++ b/virt/kvm/arm/vgic/vgic.h
@@ -251,6 +251,17 @@ static inline int vgic_v3_max_apr_idx(struct kvm_vcpu 
*vcpu)
}
 }
 
+static inline bool
+vgic_v3_redist_region_full(struct vgic_redist_region *region)
+{
+   if (!region->count)
+   return false;
+
+   return (region->free_index >= region->count);
+}
+
+struct vgic_redist_region *vgic_v3_rdist_free_slot(struct list_head *rdregs);
+
 int vgic_its_resolve_lpi(struct kvm *kvm, struct vgic_its *its,
 u32 devid, u32 eventid, struct vgic_irq **irq);
 struct vgic_its *vgic_msi_to_its(struct kvm *kvm, struct kvm_msi *msi);
-- 
2.5.5

[PATCH v3 03/12] KVM: arm/arm64: Replace the single rdist region by a list

[Eric Auger]

At the moment KVM supports a single rdist region. We want to
support several separate rdist regions so let's introduce a list
of them. This patch currently only cares about a single
entry in this list as the functionality to register several redist
regions is not yet there. So this only translates the existing code
into something functionally similar using that new data struct.

The redistributor region handle is stored in the vgic_cpu structure
to allow later computation of the TYPER last bit.

Signed-off-by: Eric Auger 
---
 include/kvm/arm_vgic.h  | 14 +
 virt/kvm/arm/vgic/vgic-init.c   | 16 --
 virt/kvm/arm/vgic/vgic-kvm-device.c | 13 ++--
 virt/kvm/arm/vgic/vgic-mmio-v3.c| 42 -
 virt/kvm/arm/vgic/vgic-v3.c | 20 +++---
 5 files changed, 79 insertions(+), 26 deletions(-)

diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 24f0394..e5c16d1 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -200,6 +200,14 @@ struct vgic_its {
 
 struct vgic_state_iter;
 
+struct vgic_redist_region {
+   uint32_t index;
+   gpa_t base;
+   uint32_t count; /* number of redistributors or 0 if single region */
+   uint32_t free_index; /* index of the next free redistributor */
+   struct list_head list;
+};
+
 struct vgic_dist {
boolin_kernel;
boolready;
@@ -219,10 +227,7 @@ struct vgic_dist {
/* either a GICv2 CPU interface */
gpa_t   vgic_cpu_base;
/* or a number of GICv3 redistributor regions */
-   struct {
-   gpa_t   vgic_redist_base;
-   gpa_t   vgic_redist_free_offset;
-   };
+   struct list_head rd_regions;
};
 
/* distributor enabled */
@@ -310,6 +315,7 @@ struct vgic_cpu {
 */
struct vgic_io_device   rd_iodev;
struct vgic_io_device   sgi_iodev;
+   struct vgic_redist_region *rdreg;
 
/* Contains the attributes and gpa of the LPI pending tables. */
u64 pendbaser;
diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index c52f03d..6456371 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -167,8 +167,11 @@ int kvm_vgic_create(struct kvm *kvm, u32 type)
kvm->arch.vgic.vgic_model = type;
 
kvm->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
-   kvm->arch.vgic.vgic_cpu_base = VGIC_ADDR_UNDEF;
-   kvm->arch.vgic.vgic_redist_base = VGIC_ADDR_UNDEF;
+
+   if (type == KVM_DEV_TYPE_ARM_VGIC_V2)
+   kvm->arch.vgic.vgic_cpu_base = VGIC_ADDR_UNDEF;
+   else
+   INIT_LIST_HEAD(&kvm->arch.vgic.rd_regions);
 
 out_unlock:
for (; vcpu_lock_idx >= 0; vcpu_lock_idx--) {
@@ -303,6 +306,7 @@ int vgic_init(struct kvm *kvm)
 static void kvm_vgic_dist_destroy(struct kvm *kvm)
 {
struct vgic_dist *dist = &kvm->arch.vgic;
+   struct vgic_redist_region *rdreg, *next;
 
dist->ready = false;
dist->initialized = false;
@@ -311,6 +315,14 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm)
dist->spis = NULL;
dist->nr_spis = 0;
 
+   if (kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) {
+   list_for_each_entry_safe(rdreg, next, &dist->rd_regions, list) {
+   list_del(&rdreg->list);
+   kfree(rdreg);
+   }
+   INIT_LIST_HEAD(&dist->rd_regions);
+   }
+
if (vgic_supports_direct_msis(kvm))
vgic_v4_teardown(kvm);
 }
diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c 
b/virt/kvm/arm/vgic/vgic-kvm-device.c
index 10ae6f3..e7b5a86 100644
--- a/virt/kvm/arm/vgic/vgic-kvm-device.c
+++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
@@ -66,6 +66,7 @@ int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64 
*addr, bool write)
int r = 0;
struct vgic_dist *vgic = &kvm->arch.vgic;
phys_addr_t *addr_ptr, alignment;
+   uint64_t undef_value = VGIC_ADDR_UNDEF;
 
mutex_lock(&kvm->lock);
switch (type) {
@@ -84,7 +85,9 @@ int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64 
*addr, bool write)
addr_ptr = &vgic->vgic_dist_base;
alignment = SZ_64K;
break;
-   case KVM_VGIC_V3_ADDR_TYPE_REDIST:
+   case KVM_VGIC_V3_ADDR_TYPE_REDIST: {
+   struct vgic_redist_region *rdreg;
+
r = vgic_check_type(kvm, KVM_DEV_TYPE_ARM_VGIC_V3);
if (r)
break;
@@ -92,8 +95,14 @@ int kvm_vgic_addr(struct kvm *kvm, unsigned long type, u64 
*addr, bool write)
r = vgic_v3_set_redist_base(kvm, *addr);
goto out;
}
-   addr_ptr = &vgic->vgic_redist_base;
+ 

RE: [PATCH v2 2/2] mfd: intel_quark_i2c_gpio: Update Synopsys GPIO interrupts

[Phil Edworthy]

Hi Geert,

On 13 April 2018 09:20 Geert Uytterhoeven wrote:
> On Fri, Apr 13, 2018 at 10:08 AM, Phil Edworthy wrote:
> > Since the way the Synopsys GPIO interrupts are stored has changed,
> > this driver needs to be updated in line with the changes.
> >
> > Signed-off-by: Phil Edworthy 
> > ---
> > v2:
> >  - New patch in v2 to fix the only other user of struct
> dwapb_port_property.
> 
> Thanks for your patch!
> 
> To avoid bisection compile failures due to the changed type of
> dwapb_port_property.irq, I think this should be folded into the first patch,
Right, thanks for pointing this out!
Phil

> > ---
> >  drivers/mfd/intel_quark_i2c_gpio.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
> > b/drivers/mfd/intel_quark_i2c_gpio.c
> > index 90e35de..5bddb84 100644
> > --- a/drivers/mfd/intel_quark_i2c_gpio.c
> > +++ b/drivers/mfd/intel_quark_i2c_gpio.c
> > @@ -233,7 +233,8 @@ static int intel_quark_gpio_setup(struct pci_dev
> *pdev, struct mfd_cell *cell)
> > pdata->properties->idx  = 0;
> > pdata->properties->ngpio= INTEL_QUARK_MFD_NGPIO;
> > pdata->properties->gpio_base= INTEL_QUARK_MFD_GPIO_BASE;
> > -   pdata->properties->irq  = pdev->irq;
> > +   pdata->properties->irq[0]   = pdev->irq;
> > +   pdata->properties->has_irq  = true;
> > pdata->properties->irq_shared   = true;
> >
> > cell->platform_data = pdata;
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-
> m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

[PATCH v3 07/12] KVM: arm/arm64: Adapt vgic_v3_check_base to multiple rdist regions

[Eric Auger]

We introduce a new helper to check there is no overlap between
dist region (if set) and registered rdist regions. This both
handles the case of legacy single rdist region (implicitly sized
with the number of online vcpus) and the new case of multiple
explicitly sized rdist regions.

Signed-off-by: Eric Auger 
---
 virt/kvm/arm/vgic/vgic-v3.c | 26 +-
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index dbcba5f..b80f650 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -432,31 +432,23 @@ bool vgic_v3_rdist_overlap(struct kvm *kvm, gpa_t base, 
size_t size)
 bool vgic_v3_check_base(struct kvm *kvm)
 {
struct vgic_dist *d = &kvm->arch.vgic;
-   gpa_t redist_size = KVM_VGIC_V3_REDIST_SIZE;
-   struct vgic_redist_region *rdreg =
-   list_first_entry(&d->rd_regions,
-struct vgic_redist_region, list);
-
-   redist_size *= atomic_read(&kvm->online_vcpus);
+   struct vgic_redist_region *rdreg;
 
if (!IS_VGIC_ADDR_UNDEF(d->vgic_dist_base) &&
d->vgic_dist_base + KVM_VGIC_V3_DIST_SIZE < d->vgic_dist_base)
return false;
 
-   if (rdreg && (rdreg->base + redist_size < rdreg->base))
-   return false;
+   list_for_each_entry(rdreg, &d->rd_regions, list) {
+   if (rdreg->base + vgic_v3_rd_region_size(kvm, rdreg) <
+   rdreg->base)
+   return false;
+   }
 
-   /* Both base addresses must be set to check if they overlap */
-   if (IS_VGIC_ADDR_UNDEF(d->vgic_dist_base) || !rdreg)
+   if (IS_VGIC_ADDR_UNDEF(d->vgic_dist_base))
return true;
 
-   if (d->vgic_dist_base + KVM_VGIC_V3_DIST_SIZE <= rdreg->base)
-   return true;
-
-   if (rdreg->base + redist_size <= d->vgic_dist_base)
-   return true;
-
-   return false;
+   return !vgic_v3_rdist_overlap(kvm, d->vgic_dist_base,
+ KVM_VGIC_V3_DIST_SIZE);
 }
 
 /**
-- 
2.5.5