Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

[David Carrillo-Cisneros]

On Thu, Jan 19, 2017 at 6:32 PM, Vikas Shivappa
 wrote:
> Resending including Thomas , also with some changes. Sorry for the spam
>
> Based on Thomas and Peterz feedback Can think of two design
> variants which target:
>
> -Support monitoring and allocating using the same resctrl group.
> user can use a resctrl group to allocate resources and also monitor
> them (with respect to tasks or cpu)
>
> -Also allows monitoring outside of resctrl so that user can
> monitor subgroups who use the same closid. This mode can be used
> when user wants to monitor more than just the resctrl groups.
>
> The first design version uses and modifies perf_cgroup, second version
> builds a new interface resmon.

The second version would require to build a whole new set of tools,
deploy them and maintain them. Users will have to run perf for certain
events and resmon (or whatever is named the new tool) for rdt. I see
it as too complex and much prefer to keep using perf.

> The first version is close to the patches
> sent with some additions/changes. This includes details of the design as
> per Thomas/Peterz feedback.
>
> 1> First Design option: without modifying the resctrl and using perf
> 
> 
>
> In this design everything in resctrl interface works like
> before (the info, resource group files like task schemata all remain the
> same)
>
>
> Monitor cqm using perf
> --
>
> perf can monitor individual tasks using the -t
> option just like before.
>
> # perf stat -e llc_occupancy -t PID1,PID2
>
> user can monitor the cpu occupancy using the -C option in perf:
>
> # perf stat -e llc_occupancy -C 5
>
> Below shows how user can monitor cgroup occupancy:
>
> # mount -t cgroup -o perf_event perf_event /sys/fs/cgroup/perf_event/
> # mkdir /sys/fs/cgroup/perf_event/g1
> # mkdir /sys/fs/cgroup/perf_event/g2
> # echo PID1 > /sys/fs/cgroup/perf_event/g2/tasks
>
> # perf stat -e intel_cqm/llc_occupancy/ -a -G g2
>
> To monitor a resctrl group, user can group the same tasks in resctrl
> group into the cgroup.
>
> To monitor the tasks in p1 in example 2 below, add the tasks in resctrl
> group p1 to cgroup g1
>
> # echo 5678 > /sys/fs/cgroup/perf_event/g1/tasks
>
> Introducing a new option for resctrl may complicate monitoring because
> supporting cgroup 'task groups' and resctrl 'task groups' leads to
> situations where:
> if the groups intersect, then there is no way to know what
> l3_allocations contribute to which group.
>
> ex:
> p1 has tasks t1, t2, t3
> g1 has tasks t2, t3, t4
>
> The only way to get occupancy for g1 and p1 would be to allocate an RMID
> for each task which can as well be done with the -t option.

That's simply recreating the resctrl group as a cgroup.

I think that the main advantage of doing allocation first is that we
could use the context switch in rdt allocation and greatly simplify
the pmu side of it.

If resctrl groups could lift the restriction of one resctl per CLOSID,
then the user can create many resctrl in the way perf cgroups are
created now. The advantage is that there wont be cgroup hierarchy!
making things much simpler. Also no need to optimize perf event
context switch to make llc_occupancy work.

Then we only need a way to express that monitoring must happen in a
resctl to the perf_event_open syscall.

My first thought is to have a "rdt_monitor" file per resctl group. A
user passes it to perf_event_open in the way cgroups are passed now.
We could extend the meaning of the flag PERF_FLAG_PID_CGROUP to also
cover rdt_monitor files. The syscall can figure if it's a cgroup or a
rdt_group. The rdt_monitoring PMU would only work with rdt_monitor
groups

Then the rdm_monitoring PMU will be pretty dumb, having neither task
nor CPU contexts. Just providing the pmu->read and pmu->event_init
functions.

Task monitoring can be done with resctrl as well by adding the PID to
a new resctl and opening the event on it. And, since we'd allow CLOSID
to be shared between resctrl groups, allocation wouldn't break.

It's a first idea, so please dont hate too hard ;) .

David

>
> Monitoring cqm cgroups Implementation
> -
>
> When monitoring two different cgroups in the same hierarchy (ex say g11
> has an ancestor g1 which are both being monitored as shown below) we
> need the g11 counts to be considered for g1 as well.
>
> # mount -t cgroup -o perf_event perf_event /sys/fs/cgroup/perf_event/
> # mkdir /sys/fs/cgroup/perf_event/g1
> # mkdir /sys/fs/cgroup/perf_event/g1/g11
>
> When measuring for g1 llc_occupancy we cannot write two different RMIDs
> (because we need to count for g11 as well)
> during context switch to measure the occupancy for both g1 and g11.
> Hence the driver maintains this information and writes the RMID of the
> lowest member in the ancestory which is being monitored during ctx
> 

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

[David Carrillo-Cisneros]

On Thu, Jan 19, 2017 at 6:32 PM, Vikas Shivappa
 wrote:
> Resending including Thomas , also with some changes. Sorry for the spam
>
> Based on Thomas and Peterz feedback Can think of two design
> variants which target:
>
> -Support monitoring and allocating using the same resctrl group.
> user can use a resctrl group to allocate resources and also monitor
> them (with respect to tasks or cpu)
>
> -Also allows monitoring outside of resctrl so that user can
> monitor subgroups who use the same closid. This mode can be used
> when user wants to monitor more than just the resctrl groups.
>
> The first design version uses and modifies perf_cgroup, second version
> builds a new interface resmon.

The second version would require to build a whole new set of tools,
deploy them and maintain them. Users will have to run perf for certain
events and resmon (or whatever is named the new tool) for rdt. I see
it as too complex and much prefer to keep using perf.

> The first version is close to the patches
> sent with some additions/changes. This includes details of the design as
> per Thomas/Peterz feedback.
>
> 1> First Design option: without modifying the resctrl and using perf
> 
> 
>
> In this design everything in resctrl interface works like
> before (the info, resource group files like task schemata all remain the
> same)
>
>
> Monitor cqm using perf
> --
>
> perf can monitor individual tasks using the -t
> option just like before.
>
> # perf stat -e llc_occupancy -t PID1,PID2
>
> user can monitor the cpu occupancy using the -C option in perf:
>
> # perf stat -e llc_occupancy -C 5
>
> Below shows how user can monitor cgroup occupancy:
>
> # mount -t cgroup -o perf_event perf_event /sys/fs/cgroup/perf_event/
> # mkdir /sys/fs/cgroup/perf_event/g1
> # mkdir /sys/fs/cgroup/perf_event/g2
> # echo PID1 > /sys/fs/cgroup/perf_event/g2/tasks
>
> # perf stat -e intel_cqm/llc_occupancy/ -a -G g2
>
> To monitor a resctrl group, user can group the same tasks in resctrl
> group into the cgroup.
>
> To monitor the tasks in p1 in example 2 below, add the tasks in resctrl
> group p1 to cgroup g1
>
> # echo 5678 > /sys/fs/cgroup/perf_event/g1/tasks
>
> Introducing a new option for resctrl may complicate monitoring because
> supporting cgroup 'task groups' and resctrl 'task groups' leads to
> situations where:
> if the groups intersect, then there is no way to know what
> l3_allocations contribute to which group.
>
> ex:
> p1 has tasks t1, t2, t3
> g1 has tasks t2, t3, t4
>
> The only way to get occupancy for g1 and p1 would be to allocate an RMID
> for each task which can as well be done with the -t option.

That's simply recreating the resctrl group as a cgroup.

I think that the main advantage of doing allocation first is that we
could use the context switch in rdt allocation and greatly simplify
the pmu side of it.

If resctrl groups could lift the restriction of one resctl per CLOSID,
then the user can create many resctrl in the way perf cgroups are
created now. The advantage is that there wont be cgroup hierarchy!
making things much simpler. Also no need to optimize perf event
context switch to make llc_occupancy work.

Then we only need a way to express that monitoring must happen in a
resctl to the perf_event_open syscall.

My first thought is to have a "rdt_monitor" file per resctl group. A
user passes it to perf_event_open in the way cgroups are passed now.
We could extend the meaning of the flag PERF_FLAG_PID_CGROUP to also
cover rdt_monitor files. The syscall can figure if it's a cgroup or a
rdt_group. The rdt_monitoring PMU would only work with rdt_monitor
groups

Then the rdm_monitoring PMU will be pretty dumb, having neither task
nor CPU contexts. Just providing the pmu->read and pmu->event_init
functions.

Task monitoring can be done with resctrl as well by adding the PID to
a new resctl and opening the event on it. And, since we'd allow CLOSID
to be shared between resctrl groups, allocation wouldn't break.

It's a first idea, so please dont hate too hard ;) .

David

>
> Monitoring cqm cgroups Implementation
> -
>
> When monitoring two different cgroups in the same hierarchy (ex say g11
> has an ancestor g1 which are both being monitored as shown below) we
> need the g11 counts to be considered for g1 as well.
>
> # mount -t cgroup -o perf_event perf_event /sys/fs/cgroup/perf_event/
> # mkdir /sys/fs/cgroup/perf_event/g1
> # mkdir /sys/fs/cgroup/perf_event/g1/g11
>
> When measuring for g1 llc_occupancy we cannot write two different RMIDs
> (because we need to count for g11 as well)
> during context switch to measure the occupancy for both g1 and g11.
> Hence the driver maintains this information and writes the RMID of the
> lowest member in the ancestory which is being monitored during ctx
> switch.
>
> The cqm_info is added 

Re: [PATCH 1/3] drm/exynos/decon5433: do not disable video after reset

[Inki Dae]

Applied including other two patches.

Thanks.

2017년 01월 17일 23:15에 Andrzej Hajda 이(가) 쓴 글:
> decon_commit is called just after reset so video is disabled anyway.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 634cfd7..6fd2b11 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -158,8 +158,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>   m->crtc_vsync_end = m->crtc_vsync_start + 1;
>   }
>  
> - decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID, 0);
> -
>   /* enable clock gate */
>   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>   writel(val, ctx->addr + DECON_CMU);
> 

Re: [PATCH 1/3] drm/exynos/decon5433: do not disable video after reset

[Inki Dae]

Applied including other two patches.

Thanks.

2017년 01월 17일 23:15에 Andrzej Hajda 이(가) 쓴 글:
> decon_commit is called just after reset so video is disabled anyway.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 634cfd7..6fd2b11 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -158,8 +158,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>   m->crtc_vsync_end = m->crtc_vsync_start + 1;
>   }
>  
> - decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID, 0);
> -
>   /* enable clock gate */
>   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>   writel(val, ctx->addr + DECON_CMU);
> 

Re: [PATCH v11 2/8] power: add power sequence library

[Peter Chen]

On Tue, Jan 10, 2017 at 03:02:41PM +0800, Peter Chen wrote:
> On Sat, Jan 07, 2017 at 10:54:56AM +0200, Krzysztof Kozlowski wrote:
> > On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote:
> > > We have an well-known problem that the device needs to do some power
> > > sequence before it can be recognized by related host, the typical
> > > example like hard-wired mmc devices and usb devices.
> > > 
> > > This power sequence is hard to be described at device tree and handled by
> > > related host driver, so we have created a common power sequence
> > > library to cover this requirement. The core code has supplied
> > > some common helpers for host driver, and individual power sequence
> > > libraries handle kinds of power sequence for devices. The pwrseq
> > > librares always need to allocate extra instance for compatible
> > > string match.
> > > 
> > > pwrseq_generic is intended for general purpose of power sequence, which
> > > handles gpios and clocks currently, and can cover other controls in
> > > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > > if only one power sequence is needed, else call of_pwrseq_on_list
> > > /of_pwrseq_off_list instead (eg, USB hub driver).
> > > 
> > > For new power sequence library, it can add its compatible string
> > > to pwrseq_of_match_table, then the pwrseq core will match it with
> > > DT's, and choose this library at runtime.
> > > 
> > > Signed-off-by: Peter Chen 
> > > Tested-by: Maciej S. Szmigiero 
> > > Tested-by Joshua Clayton 
> > > Reviewed-by: Matthias Kaehlcke 
> > > Tested-by: Matthias Kaehlcke 
> > 
> > Acked-by: Krzysztof Kozlowski 
> > Tested on Odroid U3 (reset sequence for LAN9730):
> > Tested-by: Krzysztof Kozlowski 
> > 
> 
> A nice ping...
> 

Rafael, would you please review it? This series was discussed about
half a year, and many people need it, I hope it can be in v4.11-rc1,
thanks.

-- 

Best Regards,
Peter Chen

Re: [PATCH v11 2/8] power: add power sequence library

[Peter Chen]

On Tue, Jan 10, 2017 at 03:02:41PM +0800, Peter Chen wrote:
> On Sat, Jan 07, 2017 at 10:54:56AM +0200, Krzysztof Kozlowski wrote:
> > On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote:
> > > We have an well-known problem that the device needs to do some power
> > > sequence before it can be recognized by related host, the typical
> > > example like hard-wired mmc devices and usb devices.
> > > 
> > > This power sequence is hard to be described at device tree and handled by
> > > related host driver, so we have created a common power sequence
> > > library to cover this requirement. The core code has supplied
> > > some common helpers for host driver, and individual power sequence
> > > libraries handle kinds of power sequence for devices. The pwrseq
> > > librares always need to allocate extra instance for compatible
> > > string match.
> > > 
> > > pwrseq_generic is intended for general purpose of power sequence, which
> > > handles gpios and clocks currently, and can cover other controls in
> > > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > > if only one power sequence is needed, else call of_pwrseq_on_list
> > > /of_pwrseq_off_list instead (eg, USB hub driver).
> > > 
> > > For new power sequence library, it can add its compatible string
> > > to pwrseq_of_match_table, then the pwrseq core will match it with
> > > DT's, and choose this library at runtime.
> > > 
> > > Signed-off-by: Peter Chen 
> > > Tested-by: Maciej S. Szmigiero 
> > > Tested-by Joshua Clayton 
> > > Reviewed-by: Matthias Kaehlcke 
> > > Tested-by: Matthias Kaehlcke 
> > 
> > Acked-by: Krzysztof Kozlowski 
> > Tested on Odroid U3 (reset sequence for LAN9730):
> > Tested-by: Krzysztof Kozlowski 
> > 
> 
> A nice ping...
> 

Rafael, would you please review it? This series was discussed about
half a year, and many people need it, I hope it can be in v4.11-rc1,
thanks.

-- 

Best Regards,
Peter Chen

[PATCH v1] soc: renesas: rcar-sysc:- Prevent resource leake and NULL-pointer error

[Arvind Yadav]

If rcar_sysc_pd_init will fail, Handle ERROR properly.
 -Release memory
 -Unmap I/O memory from kernel address space.

In rcar_sysc_init, If ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.

Signed-off-by: Arvind Yadav 
---
 drivers/soc/renesas/rcar-sysc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 225c35c..17df921 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -349,7 +349,7 @@ static int __init rcar_sysc_pd_init(void)
domains = kzalloc(sizeof(*domains), GFP_KERNEL);
if (!domains) {
error = -ENOMEM;
-   goto out_put;
+   goto out_iounmap;
}
 
domains->onecell_data.domains = domains->domains;
@@ -380,7 +380,7 @@ static int __init rcar_sysc_pd_init(void)
pd = kzalloc(sizeof(*pd) + strlen(area->name) + 1, GFP_KERNEL);
if (!pd) {
error = -ENOMEM;
-   goto out_put;
+   goto out_kfree;
}
 
strcpy(pd->name, area->name);
@@ -400,6 +400,10 @@ static int __init rcar_sysc_pd_init(void)
 
error = of_genpd_add_provider_onecell(np, >onecell_data);
 
+out_kfree:
+   kfree(domains);
+out_iounmap:
+   iounmap(base);
 out_put:
of_node_put(np);
return error;
@@ -414,6 +418,8 @@ void __init rcar_sysc_init(phys_addr_t base, u32 syscier)
return;
 
rcar_sysc_base = ioremap_nocache(base, PAGE_SIZE);
+   if (!rcar_sysc_base)
+   return;
 
/*
 * Mask all interrupt sources to prevent the CPU from receiving them.
-- 
1.9.1

[PATCH v1] soc: renesas: rcar-sysc:- Prevent resource leake and NULL-pointer error

[Arvind Yadav]

If rcar_sysc_pd_init will fail, Handle ERROR properly.
 -Release memory
 -Unmap I/O memory from kernel address space.

In rcar_sysc_init, If ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.

Signed-off-by: Arvind Yadav 
---
 drivers/soc/renesas/rcar-sysc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 225c35c..17df921 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -349,7 +349,7 @@ static int __init rcar_sysc_pd_init(void)
domains = kzalloc(sizeof(*domains), GFP_KERNEL);
if (!domains) {
error = -ENOMEM;
-   goto out_put;
+   goto out_iounmap;
}
 
domains->onecell_data.domains = domains->domains;
@@ -380,7 +380,7 @@ static int __init rcar_sysc_pd_init(void)
pd = kzalloc(sizeof(*pd) + strlen(area->name) + 1, GFP_KERNEL);
if (!pd) {
error = -ENOMEM;
-   goto out_put;
+   goto out_kfree;
}
 
strcpy(pd->name, area->name);
@@ -400,6 +400,10 @@ static int __init rcar_sysc_pd_init(void)
 
error = of_genpd_add_provider_onecell(np, >onecell_data);
 
+out_kfree:
+   kfree(domains);
+out_iounmap:
+   iounmap(base);
 out_put:
of_node_put(np);
return error;
@@ -414,6 +418,8 @@ void __init rcar_sysc_init(phys_addr_t base, u32 syscier)
return;
 
rcar_sysc_base = ioremap_nocache(base, PAGE_SIZE);
+   if (!rcar_sysc_base)
+   return;
 
/*
 * Mask all interrupt sources to prevent the CPU from receiving them.
-- 
1.9.1

Re: [PATCH v3 2/3] spi: pxa2xx: Prepare for edge-triggered interrupts

[Robert Jarzmik]

Jan Kiszka  writes:

> When using the a device with edge-triggered interrupts, such as MSIs,
> the interrupt handler has to ensure that there is a point in time during
> its execution where all interrupts sources are silent so that a new
> event can trigger a new interrupt again.
>
> This is achieved here by disabling all interrupt sources for a moment
> before processing them according to the status register. If a new
> interrupt should have arrived after we read the status, it will now
> re-trigger the interrupt, even in edge mode.
>
> Signed-off-by: Jan Kiszka 
Acked-by: Robert Jarzmik 

Cheers.

--
Robert
 

Re: [PATCH v3 2/3] spi: pxa2xx: Prepare for edge-triggered interrupts

[Robert Jarzmik]

Jan Kiszka  writes:

> When using the a device with edge-triggered interrupts, such as MSIs,
> the interrupt handler has to ensure that there is a point in time during
> its execution where all interrupts sources are silent so that a new
> event can trigger a new interrupt again.
>
> This is achieved here by disabling all interrupt sources for a moment
> before processing them according to the status register. If a new
> interrupt should have arrived after we read the status, it will now
> re-trigger the interrupt, even in edge mode.
>
> Signed-off-by: Jan Kiszka 
Acked-by: Robert Jarzmik 

Cheers.

--
Robert
 

Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board

[Shawn Lin]

On 2017/1/20 15:07, Eddie Cai wrote:

2017-01-20 10:29 GMT+08:00 Shawn Lin :


On 2017/1/19 10:11, Eddie Cai wrote:


This patch add basic support for RK3288-Tinker board. We can boot in to rootfs
with this patch.

Signed-off-by: Eddie Cai 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/rk3288-tinker.dts | 556 
 2 files changed, 557 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..4fc05b7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -679,6 +679,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-popmetal.dtb \
rk3288-r89.dtb \
rk3288-rock2-square.dtb \
+   rk3288-tinker.dtb \
rk3288-veyron-brain.dtb \
rk3288-veyron-jaq.dtb \
rk3288-veyron-jerry.dtb \
diff --git a/arch/arm/boot/dts/rk3288-tinker.dts 
b/arch/arm/boot/dts/rk3288-tinker.dts
new file mode 100644
index 000..37cb431
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-tinker.dts
@@ -0,0 +1,556 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3288.dtsi"
+
+/ {
+   model = "Rockchip RK3288 Tinker Board";
+   compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
+
+   memory {
+   reg = <0x0 0x8000>;
+   device_type = "memory";
+   };
+
+   ext_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <12500>;
+   clock-output-names = "ext_gmac";
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   autorepeat;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <>;
+
+   button@0 {
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   linux,code = <116>;
+   label = "GPIO Key Power";
+   linux,input-type = <1>;
+   gpio-key,wakeup = <1>;
+   debounce-interval = <100>;
+   };
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   pwr-led {
+   gpios = < 2 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-on";
+   };
+
+   act-led {
+   gpios=< 3 GPIO_ACTIVE_LOW>;
+   linux,default-trigger="mmc0";
+   };
+   };
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,name = "rockchip,tinker-codec";
+   simple-audio-card,mclk-fs = <512>;
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   

Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board

[Shawn Lin]

On 2017/1/20 15:07, Eddie Cai wrote:

2017-01-20 10:29 GMT+08:00 Shawn Lin :


On 2017/1/19 10:11, Eddie Cai wrote:


This patch add basic support for RK3288-Tinker board. We can boot in to rootfs
with this patch.

Signed-off-by: Eddie Cai 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/rk3288-tinker.dts | 556 
 2 files changed, 557 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..4fc05b7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -679,6 +679,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-popmetal.dtb \
rk3288-r89.dtb \
rk3288-rock2-square.dtb \
+   rk3288-tinker.dtb \
rk3288-veyron-brain.dtb \
rk3288-veyron-jaq.dtb \
rk3288-veyron-jerry.dtb \
diff --git a/arch/arm/boot/dts/rk3288-tinker.dts 
b/arch/arm/boot/dts/rk3288-tinker.dts
new file mode 100644
index 000..37cb431
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-tinker.dts
@@ -0,0 +1,556 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3288.dtsi"
+
+/ {
+   model = "Rockchip RK3288 Tinker Board";
+   compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
+
+   memory {
+   reg = <0x0 0x8000>;
+   device_type = "memory";
+   };
+
+   ext_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <12500>;
+   clock-output-names = "ext_gmac";
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   autorepeat;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <>;
+
+   button@0 {
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   linux,code = <116>;
+   label = "GPIO Key Power";
+   linux,input-type = <1>;
+   gpio-key,wakeup = <1>;
+   debounce-interval = <100>;
+   };
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   pwr-led {
+   gpios = < 2 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-on";
+   };
+
+   act-led {
+   gpios=< 3 GPIO_ACTIVE_LOW>;
+   linux,default-trigger="mmc0";
+   };
+   };
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,name = "rockchip,tinker-codec";
+   simple-audio-card,mclk-fs = <512>;
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   };
+   

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

[Michael Schmitz]

Hi Finn,

Am 15.01.2017 um 17:42 schrieb Finn Thain:

>> No, we can't check either FDC or SCSI interrupts (or indeed any chip 
>> registers) without touching the ST-DMA. The moment we select a FDC or 
>> SCSI register for read, DMA is terminated no questions asked.
>>
> 
> Perhaps we can convert DMA operations to PDMA (by polling with local irqs 
> disabled) and avoid the whole problem of interrupt handlers executing 
> during DMA transfers. The docs suggest that it is doable.
> 
> "Poll or service the Disk Driver Controller interrupt on the MK68901 MFP 
> General Purpose I/O Register to detect the completion of a WD1772 FDC 
> command. Do not poll the FDC Busy or DMA Sector Count Zero status bits." 
> -- ST HW Spec, p. 36.
> http://dev-docs.atariforge.org/files/ST_HW_Spec_1-7-1986.pdf

The MFP interrupt in question is the same as the one used by IDE
(wired-OR of IDE, FDC and SCSI), so we would still have to figure out
where the interrupt originated. Polling instead of taking the interrupt
does not change that fundamental problem (unless I'm missing something).

> 
> On page 18 there is an algorithm for floppy writes which is interesting.

That one (and the ACSI algorithm which would apply to SCSI for Falcon)
does suggest it won't be possible to peek at the sector count register
to detect end of DMA. The addendum (note 841017G) makes it clear that a
write to the DMA mode register is required to look at the status
register error bit (which might terminate DMA).

Maybe the DMA address register can be used to check for DMA completion
... it's used to check for residual or lost bytes anyway so that appears
to work. And the FDC driver does use the same strategy to check if
enough track data have been read.

Leaves the case where DMA hasn't completed but may have been aborted by
a NCR5380 interrupt. I suppose we can detect that by checking for any
change in the DMA address while repeatedly reading the DMA address
register. No change means the DMA has got stuck. Not exactly pretty but
all I can come up with.

> 
> I suspect that we will need to keep the FDC idle during SCSI transfers 
> (and vice versa) much as the present stdma.c lock does.
> 
> "The interrupt outputs of the internal floppy disk controller and the 
> external ACSI DMA port are logically OR'ed. The pin of the MFP GPIP will 
> read as a '0' if either the FDC or a selected ACSI device controller is 
> asserting its interrupt request."
> -- ACSI/DMA Integration Guide, p.16.
> http://dev-docs.atariforge.org/files/ACSI_DMA_Guide_6-28-1991.pdf

On Falcon, the IDE interrupt is also OR'ed to the above two interrupt
lines, hence the need for including IDE in the locking scheme there.

> 
> Polling the logically OR'ed interrupt sources to detect end-of-DMA will 
> not be reliable unless we disable those sources that aren't relevant. 
> Otherwise we access the DMA registers too early (which IIUC would kill the 
> transfer). I'm afraid we shall have to expect that a few transfers will be 
> interrupted by other devices in this way, and carefully check for this. 
> 
> For example, the 5380 SCSI bus reset interrupt is not maskable, which 
> could affect FDC transfers. If this terminated the polling for DMA 
> completion, the FDC driver then has to access the FDC registers and 
> confirm that the transfer was not terminated early.
> 

We'll have to make sure FDC and SCSI don't clash in their DMA and
interrupt use.

Cheers,

Michael

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

[Michael Schmitz]

Hi Finn,

Am 15.01.2017 um 17:42 schrieb Finn Thain:

>> No, we can't check either FDC or SCSI interrupts (or indeed any chip 
>> registers) without touching the ST-DMA. The moment we select a FDC or 
>> SCSI register for read, DMA is terminated no questions asked.
>>
> 
> Perhaps we can convert DMA operations to PDMA (by polling with local irqs 
> disabled) and avoid the whole problem of interrupt handlers executing 
> during DMA transfers. The docs suggest that it is doable.
> 
> "Poll or service the Disk Driver Controller interrupt on the MK68901 MFP 
> General Purpose I/O Register to detect the completion of a WD1772 FDC 
> command. Do not poll the FDC Busy or DMA Sector Count Zero status bits." 
> -- ST HW Spec, p. 36.
> http://dev-docs.atariforge.org/files/ST_HW_Spec_1-7-1986.pdf

The MFP interrupt in question is the same as the one used by IDE
(wired-OR of IDE, FDC and SCSI), so we would still have to figure out
where the interrupt originated. Polling instead of taking the interrupt
does not change that fundamental problem (unless I'm missing something).

> 
> On page 18 there is an algorithm for floppy writes which is interesting.

That one (and the ACSI algorithm which would apply to SCSI for Falcon)
does suggest it won't be possible to peek at the sector count register
to detect end of DMA. The addendum (note 841017G) makes it clear that a
write to the DMA mode register is required to look at the status
register error bit (which might terminate DMA).

Maybe the DMA address register can be used to check for DMA completion
... it's used to check for residual or lost bytes anyway so that appears
to work. And the FDC driver does use the same strategy to check if
enough track data have been read.

Leaves the case where DMA hasn't completed but may have been aborted by
a NCR5380 interrupt. I suppose we can detect that by checking for any
change in the DMA address while repeatedly reading the DMA address
register. No change means the DMA has got stuck. Not exactly pretty but
all I can come up with.

> 
> I suspect that we will need to keep the FDC idle during SCSI transfers 
> (and vice versa) much as the present stdma.c lock does.
> 
> "The interrupt outputs of the internal floppy disk controller and the 
> external ACSI DMA port are logically OR'ed. The pin of the MFP GPIP will 
> read as a '0' if either the FDC or a selected ACSI device controller is 
> asserting its interrupt request."
> -- ACSI/DMA Integration Guide, p.16.
> http://dev-docs.atariforge.org/files/ACSI_DMA_Guide_6-28-1991.pdf

On Falcon, the IDE interrupt is also OR'ed to the above two interrupt
lines, hence the need for including IDE in the locking scheme there.

> 
> Polling the logically OR'ed interrupt sources to detect end-of-DMA will 
> not be reliable unless we disable those sources that aren't relevant. 
> Otherwise we access the DMA registers too early (which IIUC would kill the 
> transfer). I'm afraid we shall have to expect that a few transfers will be 
> interrupted by other devices in this way, and carefully check for this. 
> 
> For example, the 5380 SCSI bus reset interrupt is not maskable, which 
> could affect FDC transfers. If this terminated the polling for DMA 
> completion, the FDC driver then has to access the FDC registers and 
> confirm that the transfer was not terminated early.
> 

We'll have to make sure FDC and SCSI don't clash in their DMA and
interrupt use.

Cheers,

Michael

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

[David Carrillo-Cisneros]

On Thu, Jan 19, 2017 at 9:41 AM, Thomas Gleixner  wrote:
> On Wed, 18 Jan 2017, David Carrillo-Cisneros wrote:
>> On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner  wrote:
>> There are use cases where the RMID to CLOSID mapping is not that simple.
>> Some of them are:
>>
>> 1. Fine-tuning of cache allocation. We may want to have a CLOSID for a thread
>> during phases that initialize relevant data, while changing it to another 
>> during
>> phases that pollute cache. Yet, we want the RMID to remain the same.
>
> That's fine. I did not say that you need fixed RMD <-> CLOSID mappings. The
> point is that monitoring across different CLOSID domains is pointless.
>
> I have no idea how you want to do that with the proposed implementation to
> switch the RMID of the thread on the fly, but that's a different story.
>
>> A different variation is to change CLOSID to increase/decrease the size of 
>> the
>> allocated cache when high/low contention is detected.
>>
>> 2. Contention detection. I start with:
>>- T1 has RMID 1.
>>- T1 changes RMID to 2.
>>  will expect llc_occupancy(1) to decrease while llc_occupancy(2) increases.
>
> Of course does RMID1 decrease because it's not longer in use. Oh well.
>
>> The rate of change will be relative to the level of cache contention present
>> at the time. This all happens without changing the CLOSID.
>
> See above.
>
>> >
>> > So when I monitor CPU4, i.e. CLOSID 1 and T1 runs on CPU4, then I do not
>> > care at all about the occupancy of T1 simply because that is running on a
>> > seperate reservation.
>>
>> It is not useless for scenarios where CLOSID and RMIDs change dynamically
>> See above.
>
> Above you are talking about the same CLOSID and different RMIDS and not
> about changing both.

The scenario I talked about implies changing CLOSID without affecting
monitoring.
It happens when the allocation needs for a thread/cgroup/CPU change
dynamically. Forcing to change the RMID together with the CLOSID would
give wrong monitoring values unless the old RMID is kept around until
becomes free, which is ugly and would waste a RMID.

>
>> > Trying to make that an aggregated value in the first
>> > place is completely wrong. If you want an aggregate, which is pretty much
>> > useless, then user space tools can generate it easily.
>>
>> Not useless, see above.
>
> It is prettey useless, because CPU4 has CLOSID1 while T1 has CLOSID4 and
> making an aggregate over those two has absolutely nothing to do with your
> scenario above.

That's true. It is useless in the case you mentioned. I erroneously
interpreted the "useless" in your comment as a general statement about
aggregating RMID occupancies.

>
> If you want the aggregate value, then create it in user space and oracle
> (or should I say google) out of it whatever you want, but do not impose
> that to the kernel.
>
>> Having user space tools to aggregate implies wasting some of the already
>> scarce RMIDs.
>
> Oh well. Can you please explain how you want to monitor the scenario I
> explained above:
>
> CPU4  CLOSID 1
> T1CLOSID 4
>
> So if T1 runs on CPU4 then it uses CLOSID 4 which does not at all affect
> the cache occupancy of CLOSID 1. So if you use the same RMID then you
> pollute either the information of CPU4 (CLOSID1) or the information of T1
> (CLOSID4)
>
> To gather any useful information for both CPU1 and T1 you need TWO
> RMIDs. Everything else is voodoo and crystal ball analysis and we are not
> going to support that.
>

Correct. Yet, having two RMIDs to monitor the same task/cgroup/CPU
just because the CLOSID changed is wasteful.

>> > The whole approach you and David have taken is to whack some desired cgroup
>> > functionality and whatever into CQM without rethinking the overall
>> > design. And that's fundamentaly broken because it does not take cache (and
>> > memory bandwidth) allocation into account.
>>
>> Monitoring and allocation are closely related yet independent.
>
> Independent to some degree. Sure you can claim they are completely
> independent, but lots of the resulting combinations make absolutely no
> sense at all. And we really don't want to support non-sensical measurements
> just because we can. The outcome of this is complexity, inaccuracy and code
> which is too horrible to look at.
>
>> I see the advantages of allowing a per-cpu RMID as you describe in the 
>> example.
>>
>> Yet, RMIDs and CLOSIDs should remain independent to allow use cases beyond
>> one simply monitoring occupancy per allocation.
>
> I agree there are use cases where you want to monitor across allocations,
> like monitoring a task which has no CLOSID assigned and runs on different
> CPUs and therefor potentially on different CLOSIDs which are assigned to
> the different CPUs.
>
> That's fine and you want a seperate RMID for this.
>
> But once you have a fixed CLOSID association then reusing and aggregating
> across CLOSID domains is more than useless.
>

Correct. But 

Re: [PATCH v2] mm: add arch-independent testcases for RODATA

[kbuild test robot]

Hi Jinbum,

[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.10-rc4 next-20170119]
[cannot apply to tip/x86/core]
[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/Jinbum-Park/mm-add-arch-independent-testcases-for-RODATA/20170120-134329
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: x86_64-nfsroot (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "rodata_test_data" [arch/x86/kernel/test_nx.ko] undefined!

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


.config.gz
Description: application/gzip

Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes

[David Carrillo-Cisneros]

On Thu, Jan 19, 2017 at 9:41 AM, Thomas Gleixner  wrote:
> On Wed, 18 Jan 2017, David Carrillo-Cisneros wrote:
>> On Wed, Jan 18, 2017 at 12:53 AM, Thomas Gleixner  wrote:
>> There are use cases where the RMID to CLOSID mapping is not that simple.
>> Some of them are:
>>
>> 1. Fine-tuning of cache allocation. We may want to have a CLOSID for a thread
>> during phases that initialize relevant data, while changing it to another 
>> during
>> phases that pollute cache. Yet, we want the RMID to remain the same.
>
> That's fine. I did not say that you need fixed RMD <-> CLOSID mappings. The
> point is that monitoring across different CLOSID domains is pointless.
>
> I have no idea how you want to do that with the proposed implementation to
> switch the RMID of the thread on the fly, but that's a different story.
>
>> A different variation is to change CLOSID to increase/decrease the size of 
>> the
>> allocated cache when high/low contention is detected.
>>
>> 2. Contention detection. I start with:
>>- T1 has RMID 1.
>>- T1 changes RMID to 2.
>>  will expect llc_occupancy(1) to decrease while llc_occupancy(2) increases.
>
> Of course does RMID1 decrease because it's not longer in use. Oh well.
>
>> The rate of change will be relative to the level of cache contention present
>> at the time. This all happens without changing the CLOSID.
>
> See above.
>
>> >
>> > So when I monitor CPU4, i.e. CLOSID 1 and T1 runs on CPU4, then I do not
>> > care at all about the occupancy of T1 simply because that is running on a
>> > seperate reservation.
>>
>> It is not useless for scenarios where CLOSID and RMIDs change dynamically
>> See above.
>
> Above you are talking about the same CLOSID and different RMIDS and not
> about changing both.

The scenario I talked about implies changing CLOSID without affecting
monitoring.
It happens when the allocation needs for a thread/cgroup/CPU change
dynamically. Forcing to change the RMID together with the CLOSID would
give wrong monitoring values unless the old RMID is kept around until
becomes free, which is ugly and would waste a RMID.

>
>> > Trying to make that an aggregated value in the first
>> > place is completely wrong. If you want an aggregate, which is pretty much
>> > useless, then user space tools can generate it easily.
>>
>> Not useless, see above.
>
> It is prettey useless, because CPU4 has CLOSID1 while T1 has CLOSID4 and
> making an aggregate over those two has absolutely nothing to do with your
> scenario above.

That's true. It is useless in the case you mentioned. I erroneously
interpreted the "useless" in your comment as a general statement about
aggregating RMID occupancies.

>
> If you want the aggregate value, then create it in user space and oracle
> (or should I say google) out of it whatever you want, but do not impose
> that to the kernel.
>
>> Having user space tools to aggregate implies wasting some of the already
>> scarce RMIDs.
>
> Oh well. Can you please explain how you want to monitor the scenario I
> explained above:
>
> CPU4  CLOSID 1
> T1CLOSID 4
>
> So if T1 runs on CPU4 then it uses CLOSID 4 which does not at all affect
> the cache occupancy of CLOSID 1. So if you use the same RMID then you
> pollute either the information of CPU4 (CLOSID1) or the information of T1
> (CLOSID4)
>
> To gather any useful information for both CPU1 and T1 you need TWO
> RMIDs. Everything else is voodoo and crystal ball analysis and we are not
> going to support that.
>

Correct. Yet, having two RMIDs to monitor the same task/cgroup/CPU
just because the CLOSID changed is wasteful.

>> > The whole approach you and David have taken is to whack some desired cgroup
>> > functionality and whatever into CQM without rethinking the overall
>> > design. And that's fundamentaly broken because it does not take cache (and
>> > memory bandwidth) allocation into account.
>>
>> Monitoring and allocation are closely related yet independent.
>
> Independent to some degree. Sure you can claim they are completely
> independent, but lots of the resulting combinations make absolutely no
> sense at all. And we really don't want to support non-sensical measurements
> just because we can. The outcome of this is complexity, inaccuracy and code
> which is too horrible to look at.
>
>> I see the advantages of allowing a per-cpu RMID as you describe in the 
>> example.
>>
>> Yet, RMIDs and CLOSIDs should remain independent to allow use cases beyond
>> one simply monitoring occupancy per allocation.
>
> I agree there are use cases where you want to monitor across allocations,
> like monitoring a task which has no CLOSID assigned and runs on different
> CPUs and therefor potentially on different CLOSIDs which are assigned to
> the different CPUs.
>
> That's fine and you want a seperate RMID for this.
>
> But once you have a fixed CLOSID association then reusing and aggregating
> across CLOSID domains is more than useless.
>

Correct. But there may not be a fixed CLOSID 

Re: [PATCH v2] mm: add arch-independent testcases for RODATA

[kbuild test robot]

Hi Jinbum,

[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.10-rc4 next-20170119]
[cannot apply to tip/x86/core]
[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/Jinbum-Park/mm-add-arch-independent-testcases-for-RODATA/20170120-134329
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: x86_64-nfsroot (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "rodata_test_data" [arch/x86/kernel/test_nx.ko] undefined!

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


.config.gz
Description: application/gzip

Re: amdgpu: Corrupted video on 32 bit systems (possible fix)

[Nils Holland]

On Fri, Jan 20, 2017 at 11:47:53AM +0900, Michel Dänzer wrote:
> On 20/01/17 04:35 AM, Nils Holland wrote:
> > 
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2016-12-11 
> > 20:17:54.0 +0100
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2017-01-19 
> > 15:38:56.972034489 +0100
> > @@ -372,6 +372,10 @@
> > if (!drm_arch_can_wc_memory())
> > bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
> >  
> > +   #ifdef CONFIG_X86_32
> > +   bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
> > +   #endif
> > +
> > amdgpu_fill_placement_to_bo(bo, placement);
> > /* Kernel allocation are uninterruptible */
> > r = ttm_bo_init(>mman.bdev, >tbo, size, type,
> 
> The corresponding code in the radeon driver has changed quite a bit
> since this original fix. It would be better to bring the amdgpu code in
> line with the current radeon code.
> 
> 
> > With this patch, the amdgpu driver works fine for me on my 32 bit
> > kernel: All graphics output looks the way it's supposed to, even with
> > full acceleration enabled - great!
> > 
> > I'd suggest that it might be a good idea to put to apply the above
> > patch or something similar to the official sources.
> 
> Indeed. Do you want to create a proper patch and submit it to the
> amd-gfx mailing list for review? See Documentation/SubmittingPatches for
> more information.

Sounds like a good idea! I was a bit heasitant because, to be honest,
I'm not at all an expert about the code in question and basically only
saw how you fixed the issue in radeon and thought: "Well, let's see if
I can do the same thing in amdgpu and if so, if it helps there, too".
;-)

However, since you've said that a 32 bit fix in amdgpu generally seems
like a good idea, I would indeed use a little time on the weekend to
get a proper patch ready and submit it for review. Even if the "no wc
for x86_32" part is probably the only thing it'll contain - more of
"bringing the amdgpu code in line with the current radeon code" might,
for the time being, be beyond my capabilities, at least if we assume
that the code should stay in a sane and working condition. ;-)

Thanks and greetings
Nils

Re: amdgpu: Corrupted video on 32 bit systems (possible fix)

[Nils Holland]

On Fri, Jan 20, 2017 at 11:47:53AM +0900, Michel Dänzer wrote:
> On 20/01/17 04:35 AM, Nils Holland wrote:
> > 
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2016-12-11 
> > 20:17:54.0 +0100
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2017-01-19 
> > 15:38:56.972034489 +0100
> > @@ -372,6 +372,10 @@
> > if (!drm_arch_can_wc_memory())
> > bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
> >  
> > +   #ifdef CONFIG_X86_32
> > +   bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
> > +   #endif
> > +
> > amdgpu_fill_placement_to_bo(bo, placement);
> > /* Kernel allocation are uninterruptible */
> > r = ttm_bo_init(>mman.bdev, >tbo, size, type,
> 
> The corresponding code in the radeon driver has changed quite a bit
> since this original fix. It would be better to bring the amdgpu code in
> line with the current radeon code.
> 
> 
> > With this patch, the amdgpu driver works fine for me on my 32 bit
> > kernel: All graphics output looks the way it's supposed to, even with
> > full acceleration enabled - great!
> > 
> > I'd suggest that it might be a good idea to put to apply the above
> > patch or something similar to the official sources.
> 
> Indeed. Do you want to create a proper patch and submit it to the
> amd-gfx mailing list for review? See Documentation/SubmittingPatches for
> more information.

Sounds like a good idea! I was a bit heasitant because, to be honest,
I'm not at all an expert about the code in question and basically only
saw how you fixed the issue in radeon and thought: "Well, let's see if
I can do the same thing in amdgpu and if so, if it helps there, too".
;-)

However, since you've said that a 32 bit fix in amdgpu generally seems
like a good idea, I would indeed use a little time on the weekend to
get a proper patch ready and submit it for review. Even if the "no wc
for x86_32" part is probably the only thing it'll contain - more of
"bringing the amdgpu code in line with the current radeon code" might,
for the time being, be beyond my capabilities, at least if we assume
that the code should stay in a sane and working condition. ;-)

Thanks and greetings
Nils

Re: [PATCH 2/2] m68k: replaced gcc specific macros with ones from compiler.h

[Geert Uytterhoeven]

On Thu, Jan 19, 2017 at 9:31 PM, kbuild test robot <l...@intel.com> wrote:
> Hi Gideon,
>
> [auto build test ERROR on m68k/for-next]
> [also build test ERROR on v4.10-rc4 next-20170119]
> [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/Gideon-Israel-Dsouza/compiler-gcc-h-Added-new-macro-for-gcc-attribute/20170120-032332
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git 
> for-next
> config: m68k-allmodconfig (attached as .config)

Hmm, although Gideon seems to have use git-send-email, there's no
"In-Reply-To" header in the email containing the second patch, hence
the kbuild test robot didn't consider the dependency on the first
patch...

Gideon: what exactly did you use to send this emai series?

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 2/2] m68k: replaced gcc specific macros with ones from compiler.h

[Geert Uytterhoeven]

On Thu, Jan 19, 2017 at 9:31 PM, kbuild test robot  wrote:
> Hi Gideon,
>
> [auto build test ERROR on m68k/for-next]
> [also build test ERROR on v4.10-rc4 next-20170119]
> [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/Gideon-Israel-Dsouza/compiler-gcc-h-Added-new-macro-for-gcc-attribute/20170120-032332
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git 
> for-next
> config: m68k-allmodconfig (attached as .config)

Hmm, although Gideon seems to have use git-send-email, there's no
"In-Reply-To" header in the email containing the second patch, hence
the kbuild test robot didn't consider the dependency on the first
patch...

Gideon: what exactly did you use to send this emai series?

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 v3 1/3] mmc: dt-bindings: update Mediatek MMC bindings

[Daniel Kurtz]

On Thu, Jan 19, 2017 at 6:19 PM, Yong Mao  wrote:
>
> From: yong mao 
>
> Add description for mtk-hs200-cmd-int-delay
> Add description for mtk-hs400-cmd-int-delay
> Add description for mtk-hs400-cmd-resp-sel
>
> Signed-off-by: Yong Mao 
> ---
>  Documentation/devicetree/bindings/mmc/mtk-sd.txt |9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
> b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 0120c7f..149f472 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -21,6 +21,12 @@ Optional properties:
>  - assigned-clocks: PLL of the source clock
>  - assigned-clock-parents: parent of source clock, used for HS400 mode to get 
> 400Mhz source clock
>  - hs400-ds-delay: HS400 DS delay setting
> +- mtk-hs200-cmd-int-delay: HS200 command internal delay setting.
> +  The value is an integer from 0 to 31
> +- mtk-hs400-cmd-int-delay: HS400 command internal delay setting
> +  The value is an integer from 0 to 31

I think last time Rob meant that you should add a vendor prefixes like this:
  mediatek,hs200-cmd-int-delay

> +- mtk-hs400-cmd-resp-sel:  HS400 command response sample selection
> +  The value is an integer from 0 to 1

Last time Rob stated this looks like a boolean, and to state that and
make the default the more common case.

So, this could be something like:

  mediatek,hs200-cmd-resp-sample-rising: A boolean.
  If present, HS400 command responses are sampled on rising edges.
  If not present, HS400 command responses are sampled on falling edges.


>
>  Examples:
>  mmc0: mmc@1123 {
> @@ -38,4 +44,7 @@ mmc0: mmc@1123 {
> assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
> assigned-clock-parents = < CLK_TOP_MSDCPLL_D2>;
> hs400-ds-delay = <0x14015>;
> +   mtk-hs200-cmd-int-delay = <26>;
> +   mtk-hs400-cmd-int-delay = <14>;
> +   mtk-hs400-cmd-resp-sel = <0>; /* 0: rising, 1: falling */
>  };
> --
> 1.7.9.5
>

Re: [PATCH v3 1/3] mmc: dt-bindings: update Mediatek MMC bindings

[Daniel Kurtz]

On Thu, Jan 19, 2017 at 6:19 PM, Yong Mao  wrote:
>
> From: yong mao 
>
> Add description for mtk-hs200-cmd-int-delay
> Add description for mtk-hs400-cmd-int-delay
> Add description for mtk-hs400-cmd-resp-sel
>
> Signed-off-by: Yong Mao 
> ---
>  Documentation/devicetree/bindings/mmc/mtk-sd.txt |9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
> b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 0120c7f..149f472 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -21,6 +21,12 @@ Optional properties:
>  - assigned-clocks: PLL of the source clock
>  - assigned-clock-parents: parent of source clock, used for HS400 mode to get 
> 400Mhz source clock
>  - hs400-ds-delay: HS400 DS delay setting
> +- mtk-hs200-cmd-int-delay: HS200 command internal delay setting.
> +  The value is an integer from 0 to 31
> +- mtk-hs400-cmd-int-delay: HS400 command internal delay setting
> +  The value is an integer from 0 to 31

I think last time Rob meant that you should add a vendor prefixes like this:
  mediatek,hs200-cmd-int-delay

> +- mtk-hs400-cmd-resp-sel:  HS400 command response sample selection
> +  The value is an integer from 0 to 1

Last time Rob stated this looks like a boolean, and to state that and
make the default the more common case.

So, this could be something like:

  mediatek,hs200-cmd-resp-sample-rising: A boolean.
  If present, HS400 command responses are sampled on rising edges.
  If not present, HS400 command responses are sampled on falling edges.


>
>  Examples:
>  mmc0: mmc@1123 {
> @@ -38,4 +44,7 @@ mmc0: mmc@1123 {
> assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
> assigned-clock-parents = < CLK_TOP_MSDCPLL_D2>;
> hs400-ds-delay = <0x14015>;
> +   mtk-hs200-cmd-int-delay = <26>;
> +   mtk-hs400-cmd-int-delay = <14>;
> +   mtk-hs400-cmd-resp-sel = <0>; /* 0: rising, 1: falling */
>  };
> --
> 1.7.9.5
>

[tip:sched/core] sched/clock: Fix hotplug crash

[tip-bot for Peter Zijlstra]

Commit-ID:  acb04058de49458010c44bb35b849d45113fd668
Gitweb: http://git.kernel.org/tip/acb04058de49458010c44bb35b849d45113fd668
Author: Peter Zijlstra 
AuthorDate: Thu, 19 Jan 2017 14:36:33 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 20 Jan 2017 02:38:46 +0100

sched/clock: Fix hotplug crash

Mike reported that he could trigger the WARN_ON_ONCE() in
set_sched_clock_stable() using hotplug.

This exposed a fundamental problem with the interface, we should never
mark the TSC stable if we ever find it to be unstable. Therefore
set_sched_clock_stable() is a broken interface.

The reason it existed is that not having it is a pain, it means all
relevant architecture code needs to call clear_sched_clock_stable()
where appropriate.

Of the three architectures that select HAVE_UNSTABLE_SCHED_CLOCK ia64
and parisc are trivial in that they never called
set_sched_clock_stable(), so add an unconditional call to
clear_sched_clock_stable() to them.

For x86 the story is a lot more involved, and what this patch tries to
do is ensure we preserve the status quo. So even is Cyrix or Transmeta
have usable TSC they never called set_sched_clock_stable() so they now
get an explicit mark unstable.

Reported-by: Mike Galbraith 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: 9881b024b7d7 ("sched/clock: Delay switching sched_clock to stable")
Link: 
http://lkml.kernel.org/r/20170119133633.gb6...@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
---
 arch/ia64/kernel/setup.c|  2 ++
 arch/parisc/kernel/setup.c  |  2 ++
 arch/x86/kernel/cpu/amd.c   |  6 --
 arch/x86/kernel/cpu/centaur.c   |  6 --
 arch/x86/kernel/cpu/common.c|  3 +++
 arch/x86/kernel/cpu/cyrix.c |  2 ++
 arch/x86/kernel/cpu/intel.c |  6 --
 arch/x86/kernel/cpu/transmeta.c |  3 +++
 arch/x86/kernel/kvmclock.c  |  2 +-
 include/linux/sched.h   |  1 -
 kernel/sched/clock.c| 29 -
 11 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index 7ec7acc..c483ece 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -619,6 +619,8 @@ setup_arch (char **cmdline_p)
check_sal_cache_flush();
 #endif
paging_init();
+
+   clear_sched_clock_stable();
 }
 
 /*
diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
index 2e66a88..068ed36 100644
--- a/arch/parisc/kernel/setup.c
+++ b/arch/parisc/kernel/setup.c
@@ -36,6 +36,7 @@
 #undef PCI_DEBUG
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -176,6 +177,7 @@ void __init setup_arch(char **cmdline_p)
conswitchp = _con;/* we use do_take_over_console() later 
! */
 #endif
 
+   clear_sched_clock_stable();
 }
 
 /*
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 71cae73..1bb253a 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -548,8 +548,10 @@ static void early_init_amd(struct cpuinfo_x86 *c)
if (c->x86_power & (1 << 8)) {
set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC);
-   if (!check_tsc_unstable())
-   set_sched_clock_stable();
+   if (check_tsc_unstable())
+   clear_sched_clock_stable();
+   } else {
+   clear_sched_clock_stable();
}
 
/* Bit 12 of 8000_0007 edx is accumulated power mechanism. */
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 1661d8e..2c234a6 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -1,5 +1,5 @@
-#include 
-#include 
+
+#include 
 
 #include 
 #include 
@@ -104,6 +104,8 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_SYSENTER32);
 #endif
+
+   clear_sched_clock_stable();
 }
 
 static void init_centaur(struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index dc1697c..3457186 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -83,6 +83,7 @@ static void default_init(struct cpuinfo_x86 *c)
strcpy(c->x86_model_id, "386");
}
 #endif
+   clear_sched_clock_stable();
 }
 
 static const struct cpu_dev default_cpu = {
@@ -1055,6 +1056,8 @@ static void identify_cpu(struct cpuinfo_x86 *c)
 */
if (this_cpu->c_init)
this_cpu->c_init(c);
+   else
+   clear_sched_clock_stable();
 
/* Disable the PN if appropriate */
squash_the_stupid_serial_number(c);
diff --git a/arch/x86/kernel/cpu/cyrix.c 

[tip:sched/core] sched/clock: Fix hotplug crash

[tip-bot for Peter Zijlstra]

Commit-ID:  acb04058de49458010c44bb35b849d45113fd668
Gitweb: http://git.kernel.org/tip/acb04058de49458010c44bb35b849d45113fd668
Author: Peter Zijlstra 
AuthorDate: Thu, 19 Jan 2017 14:36:33 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 20 Jan 2017 02:38:46 +0100

sched/clock: Fix hotplug crash

Mike reported that he could trigger the WARN_ON_ONCE() in
set_sched_clock_stable() using hotplug.

This exposed a fundamental problem with the interface, we should never
mark the TSC stable if we ever find it to be unstable. Therefore
set_sched_clock_stable() is a broken interface.

The reason it existed is that not having it is a pain, it means all
relevant architecture code needs to call clear_sched_clock_stable()
where appropriate.

Of the three architectures that select HAVE_UNSTABLE_SCHED_CLOCK ia64
and parisc are trivial in that they never called
set_sched_clock_stable(), so add an unconditional call to
clear_sched_clock_stable() to them.

For x86 the story is a lot more involved, and what this patch tries to
do is ensure we preserve the status quo. So even is Cyrix or Transmeta
have usable TSC they never called set_sched_clock_stable() so they now
get an explicit mark unstable.

Reported-by: Mike Galbraith 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: 9881b024b7d7 ("sched/clock: Delay switching sched_clock to stable")
Link: 
http://lkml.kernel.org/r/20170119133633.gb6...@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
---
 arch/ia64/kernel/setup.c|  2 ++
 arch/parisc/kernel/setup.c  |  2 ++
 arch/x86/kernel/cpu/amd.c   |  6 --
 arch/x86/kernel/cpu/centaur.c   |  6 --
 arch/x86/kernel/cpu/common.c|  3 +++
 arch/x86/kernel/cpu/cyrix.c |  2 ++
 arch/x86/kernel/cpu/intel.c |  6 --
 arch/x86/kernel/cpu/transmeta.c |  3 +++
 arch/x86/kernel/kvmclock.c  |  2 +-
 include/linux/sched.h   |  1 -
 kernel/sched/clock.c| 29 -
 11 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index 7ec7acc..c483ece 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -619,6 +619,8 @@ setup_arch (char **cmdline_p)
check_sal_cache_flush();
 #endif
paging_init();
+
+   clear_sched_clock_stable();
 }
 
 /*
diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
index 2e66a88..068ed36 100644
--- a/arch/parisc/kernel/setup.c
+++ b/arch/parisc/kernel/setup.c
@@ -36,6 +36,7 @@
 #undef PCI_DEBUG
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -176,6 +177,7 @@ void __init setup_arch(char **cmdline_p)
conswitchp = _con;/* we use do_take_over_console() later 
! */
 #endif
 
+   clear_sched_clock_stable();
 }
 
 /*
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 71cae73..1bb253a 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -548,8 +548,10 @@ static void early_init_amd(struct cpuinfo_x86 *c)
if (c->x86_power & (1 << 8)) {
set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC);
-   if (!check_tsc_unstable())
-   set_sched_clock_stable();
+   if (check_tsc_unstable())
+   clear_sched_clock_stable();
+   } else {
+   clear_sched_clock_stable();
}
 
/* Bit 12 of 8000_0007 edx is accumulated power mechanism. */
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 1661d8e..2c234a6 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -1,5 +1,5 @@
-#include 
-#include 
+
+#include 
 
 #include 
 #include 
@@ -104,6 +104,8 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_SYSENTER32);
 #endif
+
+   clear_sched_clock_stable();
 }
 
 static void init_centaur(struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index dc1697c..3457186 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -83,6 +83,7 @@ static void default_init(struct cpuinfo_x86 *c)
strcpy(c->x86_model_id, "386");
}
 #endif
+   clear_sched_clock_stable();
 }
 
 static const struct cpu_dev default_cpu = {
@@ -1055,6 +1056,8 @@ static void identify_cpu(struct cpuinfo_x86 *c)
 */
if (this_cpu->c_init)
this_cpu->c_init(c);
+   else
+   clear_sched_clock_stable();
 
/* Disable the PN if appropriate */
squash_the_stupid_serial_number(c);
diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index bd9dcd6..47416f9 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 

Re: [PATCH v6 00/25] Support qcom's HSIC USB and rewrite USB2 HS support

[Peter Chen]

On Wed, Dec 28, 2016 at 02:56:46PM -0800, Stephen Boyd wrote:
> The state of USB ChipIdea support on Qualcomm's platforms is not great.
> The DT description of these devices requires up to three different nodes
> for what amounts to be the same hardware block, when there should really
> only be one. Furthermore, the "phy" driver that is in mainline (phy-msm-usb.c)
> duplicates the OTG state machine and touches the ci controller wrapper
> registers when it should really be focused on the phy and the ULPI accesses
> needed to get the phy working. There's also a slimmed down phy driver for
> the msm8916 platform, but really the phy hardware is the same as other MSMs,
> so we have two drivers doing pretty much the same thing. This leads to a
> situtaion where we have the chipidea core driver, the "phy" driver, and
> sometimes the ehci-msm.c driver operating the same device all at the same
> time with very little coordination. This just isn't very safe and is
> confusing from a driver perspective when trying to figure out who does what.
> Finally, there isn't any HSIC support on platforms like apq8074 so we
> should add that.
> 
> This patch series updates the ChipIdea driver and the MSM wrapper
> (ci_hdrc_msm.c) to properly handle the PHY and wrapper bits at the right
> times in the right places. To get there, we update the ChipIdea core to
> have support for the ULPI phy bus introduced by Heikki. Along the way
> we fix bugs with the extcon handling for peripheral and OTG mode controllers
> and move the parts of phy-usb-msm.c that are touching the CI controller
> wrapper into the wrapper driver (ci_hdrc_msm.c). Finally we add support
> for the HSIC phy based on the ULPI bus and rewrite the HS phy driver
> (phy-usb-msm.c) as a standard ULPI phy driver.
> 
> Once this series is accepted, we should be able to delete the phy-usb-msm.c,
> phy-qcom-8x16-usb.c, and ehci-msm.c drivers from the tree and use the ULPI
> based phy driver (which also lives in drivers/phy/ instead of 
> drivers/usb/phy/)
> and the chipidea host core instead.
> 
> I've also sent separate patches for other minor pieces to make this
> all work. The full tree can be found here[1], hacks and all to get
> things working. I've tested this on the db410c, apq8074 dragonboard,
> and ifc6410 with configfs gadgets and otg cables.
> 
> Patches based on v4.10-rc1
> 
> Changes from v5:
>  * Replaced "Emulate OTGSC interrupt enable path" patch with a patch
>from Peter
>  * Updated HS phy driver to support set_mode callback to handle pullup
>  * New patch to set the mode to device or host in chipidea udc pullup
>function to toggle the pullup for HS mode
>  * New patch to drop lock around event_notify callback to avoid lockdep
>issues
>  * Removal of extcon usage from HS phy driver
>  * Picked up acks from Heikki and Peter on ULPI core patch
> 

Hi Stephen,

I have pushed your first 22 patches to my ci-for-usb-next, fixed the
conflict for patch 10, and dropped your patch 23.

Peter

> Changes from v4:
>  * Picked up Acks from Rob
>  * Updated HS phy init sequence DT property to restrict it to offsets
> 
> Changes from v3:
>  * Picked up Acks from Peter
>  * Updated extcon consolidation patch per Peter's comments
>  * Folded in simplification from Heikki for ULPI DT matching
> 
> Changes from v2:
>  * Added SoC specific compatibles in phy bindings
>  * Dropped AVVIS patch for OTG statemachine
>  * New patch to consolidate extcon handlers
>  * Picked up Acks from Peter
>  * Rebased onto v4.8-rc1
>  * Reworked ULPI OF code to look at vid == 0 instead of pid == 0
>  * Dropped ULPI bindings for vid and pid overrides
> 
> Changes from v1:
>  * Reworked ULPI device probing to keep using vendor/product ids that
>come from DT if needed and falls back to OF style match when product id
>is 0
>  * PHY init later patch was rejected so that moved to a quirk flag and
>the msm wrapper started managing the phy on/off
>  * Updated clk requirements for HSIC phy in binding doc
>  * Added optional clk in wrapper for "housekeeping" found on older qcom
>platforms
>  * Bug fix to OTGSC polling function
>  * Changed runtime PM patch to set as active instead of get/put
> 
> TODO:
>  * DMA fails on arm64 so we need something like [2] to make it work.
>  * The db410c needs a driver to toggle the onboard switch to connect
>the usb hub instead of micro port when the usb cable is disconnected.
>I've sent a patch set for this[3], which needs some further
>discussion/development.
>  * apq8064 platforms need a vbus regulator to really use otg and I haven't
>tried out the RPM based regulators yet
>  * The HSIC phy on the apq8074 dragonboard is connected to a usb4604
>device which requires the i2c driver to probe and send an i2c
>sequence before the HSIC controller enumerates or HSIC doesn't work.
>Right now I have a hack to force the controller to probe defer
>once so that usb4604 probes first. This needs a more proper solution
>

Re: [PATCH v6 00/25] Support qcom's HSIC USB and rewrite USB2 HS support

[Peter Chen]

On Wed, Dec 28, 2016 at 02:56:46PM -0800, Stephen Boyd wrote:
> The state of USB ChipIdea support on Qualcomm's platforms is not great.
> The DT description of these devices requires up to three different nodes
> for what amounts to be the same hardware block, when there should really
> only be one. Furthermore, the "phy" driver that is in mainline (phy-msm-usb.c)
> duplicates the OTG state machine and touches the ci controller wrapper
> registers when it should really be focused on the phy and the ULPI accesses
> needed to get the phy working. There's also a slimmed down phy driver for
> the msm8916 platform, but really the phy hardware is the same as other MSMs,
> so we have two drivers doing pretty much the same thing. This leads to a
> situtaion where we have the chipidea core driver, the "phy" driver, and
> sometimes the ehci-msm.c driver operating the same device all at the same
> time with very little coordination. This just isn't very safe and is
> confusing from a driver perspective when trying to figure out who does what.
> Finally, there isn't any HSIC support on platforms like apq8074 so we
> should add that.
> 
> This patch series updates the ChipIdea driver and the MSM wrapper
> (ci_hdrc_msm.c) to properly handle the PHY and wrapper bits at the right
> times in the right places. To get there, we update the ChipIdea core to
> have support for the ULPI phy bus introduced by Heikki. Along the way
> we fix bugs with the extcon handling for peripheral and OTG mode controllers
> and move the parts of phy-usb-msm.c that are touching the CI controller
> wrapper into the wrapper driver (ci_hdrc_msm.c). Finally we add support
> for the HSIC phy based on the ULPI bus and rewrite the HS phy driver
> (phy-usb-msm.c) as a standard ULPI phy driver.
> 
> Once this series is accepted, we should be able to delete the phy-usb-msm.c,
> phy-qcom-8x16-usb.c, and ehci-msm.c drivers from the tree and use the ULPI
> based phy driver (which also lives in drivers/phy/ instead of 
> drivers/usb/phy/)
> and the chipidea host core instead.
> 
> I've also sent separate patches for other minor pieces to make this
> all work. The full tree can be found here[1], hacks and all to get
> things working. I've tested this on the db410c, apq8074 dragonboard,
> and ifc6410 with configfs gadgets and otg cables.
> 
> Patches based on v4.10-rc1
> 
> Changes from v5:
>  * Replaced "Emulate OTGSC interrupt enable path" patch with a patch
>from Peter
>  * Updated HS phy driver to support set_mode callback to handle pullup
>  * New patch to set the mode to device or host in chipidea udc pullup
>function to toggle the pullup for HS mode
>  * New patch to drop lock around event_notify callback to avoid lockdep
>issues
>  * Removal of extcon usage from HS phy driver
>  * Picked up acks from Heikki and Peter on ULPI core patch
> 

Hi Stephen,

I have pushed your first 22 patches to my ci-for-usb-next, fixed the
conflict for patch 10, and dropped your patch 23.

Peter

> Changes from v4:
>  * Picked up Acks from Rob
>  * Updated HS phy init sequence DT property to restrict it to offsets
> 
> Changes from v3:
>  * Picked up Acks from Peter
>  * Updated extcon consolidation patch per Peter's comments
>  * Folded in simplification from Heikki for ULPI DT matching
> 
> Changes from v2:
>  * Added SoC specific compatibles in phy bindings
>  * Dropped AVVIS patch for OTG statemachine
>  * New patch to consolidate extcon handlers
>  * Picked up Acks from Peter
>  * Rebased onto v4.8-rc1
>  * Reworked ULPI OF code to look at vid == 0 instead of pid == 0
>  * Dropped ULPI bindings for vid and pid overrides
> 
> Changes from v1:
>  * Reworked ULPI device probing to keep using vendor/product ids that
>come from DT if needed and falls back to OF style match when product id
>is 0
>  * PHY init later patch was rejected so that moved to a quirk flag and
>the msm wrapper started managing the phy on/off
>  * Updated clk requirements for HSIC phy in binding doc
>  * Added optional clk in wrapper for "housekeeping" found on older qcom
>platforms
>  * Bug fix to OTGSC polling function
>  * Changed runtime PM patch to set as active instead of get/put
> 
> TODO:
>  * DMA fails on arm64 so we need something like [2] to make it work.
>  * The db410c needs a driver to toggle the onboard switch to connect
>the usb hub instead of micro port when the usb cable is disconnected.
>I've sent a patch set for this[3], which needs some further
>discussion/development.
>  * apq8064 platforms need a vbus regulator to really use otg and I haven't
>tried out the RPM based regulators yet
>  * The HSIC phy on the apq8074 dragonboard is connected to a usb4604
>device which requires the i2c driver to probe and send an i2c
>sequence before the HSIC controller enumerates or HSIC doesn't work.
>Right now I have a hack to force the controller to probe defer
>once so that usb4604 probes first. This needs a more proper solution
>

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Ulf Hansson]

On 20 January 2017 at 03:42, Shawn Lin  wrote:
> On 2017/1/19 22:13, Ulf Hansson wrote:
>>
>> +Shawn
>>
>> On 13 January 2017 at 06:29, Matt Ranostay 
>> wrote:
>>>
>>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>>> This can be abstracted to other chipsets if needed in the future.
>>>
>>> Cc: Tony Lindgren 
>>> Cc: Ulf Hansson 
>>> Signed-off-by: Matt Ranostay 
>>> ---
>>>  drivers/mmc/core/Kconfig |  10 
>>>  drivers/mmc/core/Makefile|   1 +
>>>  drivers/mmc/core/pwrseq_sd8787.c | 117
>>> +++
>>>  3 files changed, 128 insertions(+)
>>>  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>>
>>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>>> --- a/drivers/mmc/core/Kconfig
>>> +++ b/drivers/mmc/core/Kconfig
>>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>>>   This driver can also be built as a module. If so, the module
>>>   will be called pwrseq_emmc.
>>>
>>> +config PWRSEQ_SD8787
>>> +   tristate "HW reset support for SD8787 BT + Wifi module"
>>> +   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>>> +   help
>>> + This selects hardware reset support for the SD8787 BT + Wifi
>>> + module. By default this option is set to n.
>>> +
>>> + This driver can also be built as a module. If so, the module
>>> + will be called pwrseq_sd8787.
>>> +
>>>  config PWRSEQ_SIMPLE
>>> tristate "Simple HW reset support for MMC"
>>> default y
>>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>>> index b2a257dc644f..0f81464fa824 100644
>>> --- a/drivers/mmc/core/Makefile
>>> +++ b/drivers/mmc/core/Makefile
>>> @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
>>>quirks.o slot-gpio.o
>>>  mmc_core-$(CONFIG_OF)  += pwrseq.o
>>>  obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
>>> +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
>>>  obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
>>>  mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
>>>  obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
>>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c
>>> b/drivers/mmc/core/pwrseq_sd8787.c
>>> new file mode 100644
>>> index ..f4080fe6439e
>>> --- /dev/null
>>> +++ b/drivers/mmc/core/pwrseq_sd8787.c
>>> @@ -0,0 +1,117 @@
>>> +/*
>>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi
>>> chip
>>> + *
>>> + * Copyright (C) 2016 Matt Ranostay 
>>> + *
>>> + * Based on the original work pwrseq_simple.c
>>> + *  Copyright (C) 2014 Linaro Ltd
>>> + *  Author: Ulf Hansson 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +#include "pwrseq.h"
>>> +
>>> +struct mmc_pwrseq_sd8787 {
>>> +   struct mmc_pwrseq pwrseq;
>>> +   struct gpio_desc *reset_gpio;
>>> +   struct gpio_desc *pwrdn_gpio;
>>> +};
>>> +
>>> +#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787,
>>> pwrseq)
>>> +
>>> +static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
>>> +{
>>> +   struct mmc_pwrseq_sd8787 *pwrseq =
>>> to_pwrseq_sd8787(host->pwrseq);
>>> +
>>> +   gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
>>> +
>>> +   msleep(300);
>>> +   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
>>> +}
>>> +
>>> +static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
>>> +{
>>> +   struct mmc_pwrseq_sd8787 *pwrseq =
>>> to_pwrseq_sd8787(host->pwrseq);
>>> +
>>> +   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
>>> +   gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
>>> +}
>>> +
>>> +static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
>>> +   .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
>>> +   .power_off = mmc_pwrseq_sd8787_power_off,
>>> +};
>>> +
>>> +static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
>>> +   { .compatible = "mmc-pwrseq-sd8787",},
>>> +   {/* sentinel */},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
>>> +
>>> +static int mmc_pwrseq_sd8787_probe(struct 

Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Ulf Hansson]

On 20 January 2017 at 03:42, Shawn Lin  wrote:
> On 2017/1/19 22:13, Ulf Hansson wrote:
>>
>> +Shawn
>>
>> On 13 January 2017 at 06:29, Matt Ranostay 
>> wrote:
>>>
>>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>>> This can be abstracted to other chipsets if needed in the future.
>>>
>>> Cc: Tony Lindgren 
>>> Cc: Ulf Hansson 
>>> Signed-off-by: Matt Ranostay 
>>> ---
>>>  drivers/mmc/core/Kconfig |  10 
>>>  drivers/mmc/core/Makefile|   1 +
>>>  drivers/mmc/core/pwrseq_sd8787.c | 117
>>> +++
>>>  3 files changed, 128 insertions(+)
>>>  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>>
>>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>>> --- a/drivers/mmc/core/Kconfig
>>> +++ b/drivers/mmc/core/Kconfig
>>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>>>   This driver can also be built as a module. If so, the module
>>>   will be called pwrseq_emmc.
>>>
>>> +config PWRSEQ_SD8787
>>> +   tristate "HW reset support for SD8787 BT + Wifi module"
>>> +   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>>> +   help
>>> + This selects hardware reset support for the SD8787 BT + Wifi
>>> + module. By default this option is set to n.
>>> +
>>> + This driver can also be built as a module. If so, the module
>>> + will be called pwrseq_sd8787.
>>> +
>>>  config PWRSEQ_SIMPLE
>>> tristate "Simple HW reset support for MMC"
>>> default y
>>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>>> index b2a257dc644f..0f81464fa824 100644
>>> --- a/drivers/mmc/core/Makefile
>>> +++ b/drivers/mmc/core/Makefile
>>> @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
>>>quirks.o slot-gpio.o
>>>  mmc_core-$(CONFIG_OF)  += pwrseq.o
>>>  obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
>>> +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
>>>  obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
>>>  mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
>>>  obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
>>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c
>>> b/drivers/mmc/core/pwrseq_sd8787.c
>>> new file mode 100644
>>> index ..f4080fe6439e
>>> --- /dev/null
>>> +++ b/drivers/mmc/core/pwrseq_sd8787.c
>>> @@ -0,0 +1,117 @@
>>> +/*
>>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi
>>> chip
>>> + *
>>> + * Copyright (C) 2016 Matt Ranostay 
>>> + *
>>> + * Based on the original work pwrseq_simple.c
>>> + *  Copyright (C) 2014 Linaro Ltd
>>> + *  Author: Ulf Hansson 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +#include "pwrseq.h"
>>> +
>>> +struct mmc_pwrseq_sd8787 {
>>> +   struct mmc_pwrseq pwrseq;
>>> +   struct gpio_desc *reset_gpio;
>>> +   struct gpio_desc *pwrdn_gpio;
>>> +};
>>> +
>>> +#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787,
>>> pwrseq)
>>> +
>>> +static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
>>> +{
>>> +   struct mmc_pwrseq_sd8787 *pwrseq =
>>> to_pwrseq_sd8787(host->pwrseq);
>>> +
>>> +   gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
>>> +
>>> +   msleep(300);
>>> +   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
>>> +}
>>> +
>>> +static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
>>> +{
>>> +   struct mmc_pwrseq_sd8787 *pwrseq =
>>> to_pwrseq_sd8787(host->pwrseq);
>>> +
>>> +   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
>>> +   gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
>>> +}
>>> +
>>> +static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
>>> +   .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
>>> +   .power_off = mmc_pwrseq_sd8787_power_off,
>>> +};
>>> +
>>> +static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
>>> +   { .compatible = "mmc-pwrseq-sd8787",},
>>> +   {/* sentinel */},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
>>> +
>>> +static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
>>> +{
>>> +   struct mmc_pwrseq_sd8787 *pwrseq;
>>> +   struct device *dev = >dev;
>>> +
>>> +   pwrseq = devm_kzalloc(dev, 

Re: [PATCH v2] jump_label: reduce the size of struct static_key

[Ingo Molnar]

* Jason Baron  wrote:

>  struct static_key {
>   atomic_t enabled;
> +/*
> + * bit 0 => 1 if key is initially true
> + *   0 if initially false
> + * bit 1 => 1 if points to struct static_key_mod
> + *   0 if points to struct jump_entry
> + */
> + union {
> + unsigned long type;
> + struct jump_entry *entries;
> + struct static_key_mod *next;
> + };


> + key->type = (unsigned long)jlm2 | static_key_type(key);

> + key->type = (unsigned long)jlm | static_key_type(key);

> + *prev = (struct static_key_mod *)((unsigned long)jlm->next |
> + ((unsigned long)*prev & JUMP_TYPE_MASK));

> + key->type = (unsigned long)jlm->entries |
> + static_key_type(key);

I really hate these very ugly type conversions. Is there no cleaner way?

For example the last line could sure be written as:

key->entries = jlm->entries;
key->type |= static_key_type(key);

right?

Thanks,

Ingo

Re: [PATCH v2] jump_label: reduce the size of struct static_key

[Ingo Molnar]

* Jason Baron  wrote:

>  struct static_key {
>   atomic_t enabled;
> +/*
> + * bit 0 => 1 if key is initially true
> + *   0 if initially false
> + * bit 1 => 1 if points to struct static_key_mod
> + *   0 if points to struct jump_entry
> + */
> + union {
> + unsigned long type;
> + struct jump_entry *entries;
> + struct static_key_mod *next;
> + };


> + key->type = (unsigned long)jlm2 | static_key_type(key);

> + key->type = (unsigned long)jlm | static_key_type(key);

> + *prev = (struct static_key_mod *)((unsigned long)jlm->next |
> + ((unsigned long)*prev & JUMP_TYPE_MASK));

> + key->type = (unsigned long)jlm->entries |
> + static_key_type(key);

I really hate these very ugly type conversions. Is there no cleaner way?

For example the last line could sure be written as:

key->entries = jlm->entries;
key->type |= static_key_type(key);

right?

Thanks,

Ingo

Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board

[Eddie Cai]

2017-01-20 10:29 GMT+08:00 Shawn Lin :
>
> On 2017/1/19 10:11, Eddie Cai wrote:
>>
>> This patch add basic support for RK3288-Tinker board. We can boot in to 
>> rootfs
>> with this patch.
>>
>> Signed-off-by: Eddie Cai 
>> ---
>>  arch/arm/boot/dts/Makefile  |   1 +
>>  arch/arm/boot/dts/rk3288-tinker.dts | 556 
>> 
>>  2 files changed, 557 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 7327250..4fc05b7 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -679,6 +679,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>> rk3288-popmetal.dtb \
>> rk3288-r89.dtb \
>> rk3288-rock2-square.dtb \
>> +   rk3288-tinker.dtb \
>> rk3288-veyron-brain.dtb \
>> rk3288-veyron-jaq.dtb \
>> rk3288-veyron-jerry.dtb \
>> diff --git a/arch/arm/boot/dts/rk3288-tinker.dts 
>> b/arch/arm/boot/dts/rk3288-tinker.dts
>> new file mode 100644
>> index 000..37cb431
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/rk3288-tinker.dts
>> @@ -0,0 +1,556 @@
>> +/*
>> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "rk3288.dtsi"
>> +
>> +/ {
>> +   model = "Rockchip RK3288 Tinker Board";
>> +   compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
>> +
>> +   memory {
>> +   reg = <0x0 0x8000>;
>> +   device_type = "memory";
>> +   };
>> +
>> +   ext_gmac: external-gmac-clock {
>> +   compatible = "fixed-clock";
>> +   #clock-cells = <0>;
>> +   clock-frequency = <12500>;
>> +   clock-output-names = "ext_gmac";
>> +   };
>> +
>> +   gpio-keys {
>> +   compatible = "gpio-keys";
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   autorepeat;
>> +
>> +   pinctrl-names = "default";
>> +   pinctrl-0 = <>;
>> +
>> +   button@0 {
>> +   gpios = < 5 GPIO_ACTIVE_LOW>;
>> +   linux,code = <116>;
>> +   label = "GPIO Key Power";
>> +   linux,input-type = <1>;
>> +   gpio-key,wakeup = <1>;
>> +   debounce-interval = <100>;
>> +   };
>> +   };
>> +
>> +   gpio-leds {
>> +   compatible = "gpio-leds";
>> +
>> +   pwr-led {
>> +   gpios = < 2 GPIO_ACTIVE_HIGH>;
>> +   linux,default-trigger = "default-on";
>> +   };
>> +
>> +   act-led {
>> +   gpios=< 3 GPIO_ACTIVE_LOW>;
>> +   linux,default-trigger="mmc0";
>> +

Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board

[Eddie Cai]

2017-01-20 10:29 GMT+08:00 Shawn Lin :
>
> On 2017/1/19 10:11, Eddie Cai wrote:
>>
>> This patch add basic support for RK3288-Tinker board. We can boot in to 
>> rootfs
>> with this patch.
>>
>> Signed-off-by: Eddie Cai 
>> ---
>>  arch/arm/boot/dts/Makefile  |   1 +
>>  arch/arm/boot/dts/rk3288-tinker.dts | 556 
>> 
>>  2 files changed, 557 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 7327250..4fc05b7 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -679,6 +679,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>> rk3288-popmetal.dtb \
>> rk3288-r89.dtb \
>> rk3288-rock2-square.dtb \
>> +   rk3288-tinker.dtb \
>> rk3288-veyron-brain.dtb \
>> rk3288-veyron-jaq.dtb \
>> rk3288-veyron-jerry.dtb \
>> diff --git a/arch/arm/boot/dts/rk3288-tinker.dts 
>> b/arch/arm/boot/dts/rk3288-tinker.dts
>> new file mode 100644
>> index 000..37cb431
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/rk3288-tinker.dts
>> @@ -0,0 +1,556 @@
>> +/*
>> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "rk3288.dtsi"
>> +
>> +/ {
>> +   model = "Rockchip RK3288 Tinker Board";
>> +   compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
>> +
>> +   memory {
>> +   reg = <0x0 0x8000>;
>> +   device_type = "memory";
>> +   };
>> +
>> +   ext_gmac: external-gmac-clock {
>> +   compatible = "fixed-clock";
>> +   #clock-cells = <0>;
>> +   clock-frequency = <12500>;
>> +   clock-output-names = "ext_gmac";
>> +   };
>> +
>> +   gpio-keys {
>> +   compatible = "gpio-keys";
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   autorepeat;
>> +
>> +   pinctrl-names = "default";
>> +   pinctrl-0 = <>;
>> +
>> +   button@0 {
>> +   gpios = < 5 GPIO_ACTIVE_LOW>;
>> +   linux,code = <116>;
>> +   label = "GPIO Key Power";
>> +   linux,input-type = <1>;
>> +   gpio-key,wakeup = <1>;
>> +   debounce-interval = <100>;
>> +   };
>> +   };
>> +
>> +   gpio-leds {
>> +   compatible = "gpio-leds";
>> +
>> +   pwr-led {
>> +   gpios = < 2 GPIO_ACTIVE_HIGH>;
>> +   linux,default-trigger = "default-on";
>> +   };
>> +
>> +   act-led {
>> +   gpios=< 3 GPIO_ACTIVE_LOW>;
>> +   linux,default-trigger="mmc0";
>> +   };
>> +   };
>> +
>> +   sound {
>> +

[PATCH 1/3 v2] ahci: qoriq: added a condition to enable dma coherence

[yuantian.tang]

From: Tang Yuantian 

Enable DMA coherence in SATA controller on condition that
dma-coherent property exists in sata node in DTS.

Signed-off-by: Tang Yuantian 
---
v2:
  - use of_dma_is_coherent() instead of open-coding.

 drivers/ata/ahci_qoriq.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 9884c8c..01ef662 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -59,6 +59,7 @@ struct ahci_qoriq_priv {
struct ccsr_ahci *reg_base;
enum ahci_qoriq_type type;
void __iomem *ecc_addr;
+   bool is_dmacoherent;
 };
 
 static const struct of_device_id ahci_qoriq_of_match[] = {
@@ -164,26 +165,31 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
*hpriv)
writel(LS1021A_PORT_PHY4, reg_base + PORT_PHY4);
writel(LS1021A_PORT_PHY5, reg_base + PORT_PHY5);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
-   writel(AHCI_PORT_AXICC_CFG, reg_base + LS1021A_AXICC_ADDR);
+   if (qpriv->is_dmacoherent)
+   writel(AHCI_PORT_AXICC_CFG,
+   reg_base + LS1021A_AXICC_ADDR);
break;
 
case AHCI_LS1043A:
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
-   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+   if (qpriv->is_dmacoherent)
+   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
 
case AHCI_LS2080A:
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
-   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+   if (qpriv->is_dmacoherent)
+   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
 
case AHCI_LS1046A:
writel(LS1046A_SATA_ECC_DIS, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
-   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+   if (qpriv->is_dmacoherent)
+   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
}
 
@@ -221,6 +227,7 @@ static int ahci_qoriq_probe(struct platform_device *pdev)
if (IS_ERR(qoriq_priv->ecc_addr))
return PTR_ERR(qoriq_priv->ecc_addr);
}
+   qoriq_priv->is_dmacoherent = of_dma_is_coherent(np);
 
rc = ahci_platform_enable_resources(hpriv);
if (rc)
-- 
2.1.0.27.g96db324

[PATCH 1/3 v2] ahci: qoriq: added a condition to enable dma coherence

[yuantian.tang]

From: Tang Yuantian 

Enable DMA coherence in SATA controller on condition that
dma-coherent property exists in sata node in DTS.

Signed-off-by: Tang Yuantian 
---
v2:
  - use of_dma_is_coherent() instead of open-coding.

 drivers/ata/ahci_qoriq.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 9884c8c..01ef662 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -59,6 +59,7 @@ struct ahci_qoriq_priv {
struct ccsr_ahci *reg_base;
enum ahci_qoriq_type type;
void __iomem *ecc_addr;
+   bool is_dmacoherent;
 };
 
 static const struct of_device_id ahci_qoriq_of_match[] = {
@@ -164,26 +165,31 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
*hpriv)
writel(LS1021A_PORT_PHY4, reg_base + PORT_PHY4);
writel(LS1021A_PORT_PHY5, reg_base + PORT_PHY5);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
-   writel(AHCI_PORT_AXICC_CFG, reg_base + LS1021A_AXICC_ADDR);
+   if (qpriv->is_dmacoherent)
+   writel(AHCI_PORT_AXICC_CFG,
+   reg_base + LS1021A_AXICC_ADDR);
break;
 
case AHCI_LS1043A:
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
-   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+   if (qpriv->is_dmacoherent)
+   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
 
case AHCI_LS2080A:
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
-   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+   if (qpriv->is_dmacoherent)
+   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
 
case AHCI_LS1046A:
writel(LS1046A_SATA_ECC_DIS, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
-   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+   if (qpriv->is_dmacoherent)
+   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
}
 
@@ -221,6 +227,7 @@ static int ahci_qoriq_probe(struct platform_device *pdev)
if (IS_ERR(qoriq_priv->ecc_addr))
return PTR_ERR(qoriq_priv->ecc_addr);
}
+   qoriq_priv->is_dmacoherent = of_dma_is_coherent(np);
 
rc = ahci_platform_enable_resources(hpriv);
if (rc)
-- 
2.1.0.27.g96db324

[PATCH 2/3 v2] ahci: qoriq: report error when ecc register address is missing in dts

[yuantian.tang]

From: Tang Yuantian 

For ls1021a, and armv8 chasis 2 socs, sata ecc must be disabled.
If ecc register is not found in sata node in dts, report error.

This is a chip erratum described as bellow:
The Read DMA operations get early termination indication from the
controller. This issue is observed as CRC error in the status registers.
The issue is due to address collision at address 0 in the dual port
memory. The read is a dummy read to flush out the header, but due to
collision the controller logs the mbit error reported by the ECC check
logic. This results in the early termination of the Read DMA operation
by the controller. The issue happens to all the interface
speeds(GEN1/2/3) for all the products.

Workaround:
Disable ECC feature on those platforms.

Signed-off-by: Tang Yuantian 
---
v2:
  - refine the title and description
  - change reporting warning to reporting error

 drivers/ata/ahci_qoriq.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 01ef662..137b1c7 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -46,7 +46,7 @@
 #define LS1021A_AXICC_ADDR 0xC0
 
 #define SATA_ECC_DISABLE   0x0002
-#define LS1046A_SATA_ECC_DIS   0x8000
+#define ECC_DIS_ARMV8_CH2  0x8000
 
 enum ahci_qoriq_type {
AHCI_LS1021A,
@@ -158,6 +158,8 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
 
switch (qpriv->type) {
case AHCI_LS1021A:
+   if (!qpriv->ecc_addr)
+   return -EINVAL;
writel(SATA_ECC_DISABLE, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(LS1021A_PORT_PHY2, reg_base + PORT_PHY2);
@@ -171,6 +173,9 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
break;
 
case AHCI_LS1043A:
+   if (!qpriv->ecc_addr)
+   return -EINVAL;
+   writel(ECC_DIS_ARMV8_CH2, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
if (qpriv->is_dmacoherent)
@@ -185,7 +190,9 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
break;
 
case AHCI_LS1046A:
-   writel(LS1046A_SATA_ECC_DIS, qpriv->ecc_addr);
+   if (!qpriv->ecc_addr)
+   return -EINVAL;
+   writel(ECC_DIS_ARMV8_CH2, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
if (qpriv->is_dmacoherent)
-- 
2.1.0.27.g96db324

[PATCH 3/3 v2] ahci: qoriq: added ls2088a platforms support

[yuantian.tang]

From: Tang Yuantian 

Ls2088a is new introduced arm-based soc with sata support with
following features:
1. Complies with the serial ATA 3.0 specification and the AHCI 1.3.1
   specification
2. Contains a high-speed descriptor-based DMA controller
3. Supports the following:
   a. Speeds of 1.5 Gb/s (first-generation SATA), 3 Gb/s
  (second-generation SATA), and 6 Gb/s (third-generation SATA)
   b. FIS-based switching
   c. Native command queuing (NCQ) commands
   d. Port multiplier operation
   e. Asynchronous notification
   f. SATA BIST mode

Signed-off-by: Tang Yuantian 
---
v2:
  - no change

 drivers/ata/ahci_qoriq.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 137b1c7..85d8332 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -53,6 +53,7 @@ enum ahci_qoriq_type {
AHCI_LS1043A,
AHCI_LS2080A,
AHCI_LS1046A,
+   AHCI_LS2088A,
 };
 
 struct ahci_qoriq_priv {
@@ -67,6 +68,7 @@ static const struct of_device_id ahci_qoriq_of_match[] = {
{ .compatible = "fsl,ls1043a-ahci", .data = (void *)AHCI_LS1043A},
{ .compatible = "fsl,ls2080a-ahci", .data = (void *)AHCI_LS2080A},
{ .compatible = "fsl,ls1046a-ahci", .data = (void *)AHCI_LS1046A},
+   { .compatible = "fsl,ls2088a-ahci", .data = (void *)AHCI_LS2088A},
{},
 };
 MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match);
@@ -198,6 +200,13 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
*hpriv)
if (qpriv->is_dmacoherent)
writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
+
+   case AHCI_LS2088A:
+   writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
+   writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
+   if (qpriv->is_dmacoherent)
+   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+   break;
}
 
return 0;
-- 
2.1.0.27.g96db324

[PATCH 2/3 v2] ahci: qoriq: report error when ecc register address is missing in dts

[yuantian.tang]

From: Tang Yuantian 

For ls1021a, and armv8 chasis 2 socs, sata ecc must be disabled.
If ecc register is not found in sata node in dts, report error.

This is a chip erratum described as bellow:
The Read DMA operations get early termination indication from the
controller. This issue is observed as CRC error in the status registers.
The issue is due to address collision at address 0 in the dual port
memory. The read is a dummy read to flush out the header, but due to
collision the controller logs the mbit error reported by the ECC check
logic. This results in the early termination of the Read DMA operation
by the controller. The issue happens to all the interface
speeds(GEN1/2/3) for all the products.

Workaround:
Disable ECC feature on those platforms.

Signed-off-by: Tang Yuantian 
---
v2:
  - refine the title and description
  - change reporting warning to reporting error

 drivers/ata/ahci_qoriq.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 01ef662..137b1c7 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -46,7 +46,7 @@
 #define LS1021A_AXICC_ADDR 0xC0
 
 #define SATA_ECC_DISABLE   0x0002
-#define LS1046A_SATA_ECC_DIS   0x8000
+#define ECC_DIS_ARMV8_CH2  0x8000
 
 enum ahci_qoriq_type {
AHCI_LS1021A,
@@ -158,6 +158,8 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
 
switch (qpriv->type) {
case AHCI_LS1021A:
+   if (!qpriv->ecc_addr)
+   return -EINVAL;
writel(SATA_ECC_DISABLE, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(LS1021A_PORT_PHY2, reg_base + PORT_PHY2);
@@ -171,6 +173,9 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
break;
 
case AHCI_LS1043A:
+   if (!qpriv->ecc_addr)
+   return -EINVAL;
+   writel(ECC_DIS_ARMV8_CH2, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
if (qpriv->is_dmacoherent)
@@ -185,7 +190,9 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
break;
 
case AHCI_LS1046A:
-   writel(LS1046A_SATA_ECC_DIS, qpriv->ecc_addr);
+   if (!qpriv->ecc_addr)
+   return -EINVAL;
+   writel(ECC_DIS_ARMV8_CH2, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
if (qpriv->is_dmacoherent)
-- 
2.1.0.27.g96db324

[PATCH 3/3 v2] ahci: qoriq: added ls2088a platforms support

[yuantian.tang]

From: Tang Yuantian 

Ls2088a is new introduced arm-based soc with sata support with
following features:
1. Complies with the serial ATA 3.0 specification and the AHCI 1.3.1
   specification
2. Contains a high-speed descriptor-based DMA controller
3. Supports the following:
   a. Speeds of 1.5 Gb/s (first-generation SATA), 3 Gb/s
  (second-generation SATA), and 6 Gb/s (third-generation SATA)
   b. FIS-based switching
   c. Native command queuing (NCQ) commands
   d. Port multiplier operation
   e. Asynchronous notification
   f. SATA BIST mode

Signed-off-by: Tang Yuantian 
---
v2:
  - no change

 drivers/ata/ahci_qoriq.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 137b1c7..85d8332 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -53,6 +53,7 @@ enum ahci_qoriq_type {
AHCI_LS1043A,
AHCI_LS2080A,
AHCI_LS1046A,
+   AHCI_LS2088A,
 };
 
 struct ahci_qoriq_priv {
@@ -67,6 +68,7 @@ static const struct of_device_id ahci_qoriq_of_match[] = {
{ .compatible = "fsl,ls1043a-ahci", .data = (void *)AHCI_LS1043A},
{ .compatible = "fsl,ls2080a-ahci", .data = (void *)AHCI_LS2080A},
{ .compatible = "fsl,ls1046a-ahci", .data = (void *)AHCI_LS1046A},
+   { .compatible = "fsl,ls2088a-ahci", .data = (void *)AHCI_LS2088A},
{},
 };
 MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match);
@@ -198,6 +200,13 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
*hpriv)
if (qpriv->is_dmacoherent)
writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
break;
+
+   case AHCI_LS2088A:
+   writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
+   writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
+   if (qpriv->is_dmacoherent)
+   writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
+   break;
}
 
return 0;
-- 
2.1.0.27.g96db324

Re: [patch] mm, oom: header nodemask is NULL when cpusets are disabled

[Hillf Danton]

On Friday, January 20, 2017 6:58 AM David Rientjes wrote: 
> 
> Commit 82e7d3abec86 ("oom: print nodemask in the oom report") implicitly
> sets the allocation nodemask to cpuset_current_mems_allowed when there is
> no effective mempolicy.  cpuset_current_mems_allowed is only effective
> when cpusets are enabled, which is also printed by dump_header(), so
> setting the nodemask to cpuset_current_mems_allowed is redundant and
> prevents debugging issues where ac->nodemask is not set properly in the
> page allocator.
> 
> This provides better debugging output since
> cpuset_print_current_mems_allowed() is already provided.
> 
> Suggested-by: Vlastimil Babka 
> Signed-off-by: David Rientjes 
> ---
Acked-by: Hillf Danton 

>  mm/oom_kill.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -403,12 +403,14 @@ static void dump_tasks(struct mem_cgroup *memcg, const 
> nodemask_t *nodemask)
> 
>  static void dump_header(struct oom_control *oc, struct task_struct *p)
>  {
> - nodemask_t *nm = (oc->nodemask) ? oc->nodemask : 
> _current_mems_allowed;
> -
> - pr_warn("%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, 
> order=%d, oom_score_adj=%hd\n",
> - current->comm, oc->gfp_mask, >gfp_mask,
> - nodemask_pr_args(nm), oc->order,
> - current->signal->oom_score_adj);
> + pr_warn("%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=",
> + current->comm, oc->gfp_mask, >gfp_mask);
> + if (oc->nodemask)
> + pr_cont("%*pbl", nodemask_pr_args(oc->nodemask));
> + else
> + pr_cont("(null)\n");

Nit: no newline needed.

> + pr_cont(",  order=%d, oom_score_adj=%hd\n",
> + oc->order, current->signal->oom_score_adj);
>   if (!IS_ENABLED(CONFIG_COMPACTION) && oc->order)
>   pr_warn("COMPACTION is disabled!!!\n");
> 
> @@ -417,7 +419,7 @@ static void dump_header(struct oom_control *oc, struct 
> task_struct *p)
>   if (oc->memcg)
>   mem_cgroup_print_oom_info(oc->memcg, p);
>   else
> - show_mem(SHOW_MEM_FILTER_NODES, nm);
> + show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
>   if (sysctl_oom_dump_tasks)
>   dump_tasks(oc->memcg, oc->nodemask);
>  }
> 

Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board

[Eddie Cai]

2017-01-19 17:58 GMT+08:00 Heiko Stuebner :
> Hi Eddie,
>
> Am Donnerstag, 19. Januar 2017, 10:11:59 CET schrieb Eddie Cai:
>> This patch add basic support for RK3288-Tinker board. We can boot in to
>> rootfs with this patch.
>>
>> Signed-off-by: Eddie Cai 
>
> looks good in general, just some small question down below.
>
> [...]
>
>> + /*
>> +  * NOTE: vcc_sd isn't hooked up on v1.0 boards where power comes from
>> +  * vcc_io directly.  Those boards won't be able to power cycle SD cards
>> +  * but it shouldn't hurt to toggle this pin there anyway.
>> +  */
>
> just to clarify, later board will have that pin connected, right?
Copy from rk3288-evb.dtsi. forgot to delete it. I will remove it in next version
>
>> + vcc_sd: sdmmc-regulator {
>> + compatible = "regulator-fixed";
>> + gpio = < 11 GPIO_ACTIVE_LOW>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pwr>;
>> + regulator-name = "vcc_sd";
>> + regulator-min-microvolt = <330>;
>> + regulator-max-microvolt = <330>;
>> + startup-delay-us = <10>;
>> + vin-supply = <_io>;
>> + };
>> +};
>
> [...]
>
>> + {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + #sound-dai-cells = <0>;
>> + ddc-i2c-bus = <>;
>> + status = "okay";
>> + /* Don't use vopl for HDMI */
>> + ports {
>> + hdmi_in: port {
>> + /delete-node/ endpoint@1;
>> + };
>
> what is the reason for this? You enable both VOPs below and the linux display
> subsystem should be able to select an appropriate VOP for output just fine on
> its own. So there should be no reason for capping the hdmi's connection to one
> of the vops.
The VOP big support 4k display. is designed for HDMI  4K display. VOP
little is for other display(eDP, LVDS, Mipi etc)
>
>> + };
>> +};
>
> [...]
>
>> +_host0_ehci {
>> + no-relinquish-port;
>
> This seems like an unused/undocumented property
I will remove it in next version
>
>> + status = "okay";
>> +};
>
> [...]
>
>> + {
>> + status = "okay";
>> + /* Don't use vopl for HDMI */
>> + vopl_out: port {
>> + /delete-node/ endpoint@0;
>> + };
>
> see comment at the hdmi node
>
>> +};
>
>
> Thanks
> Heiko

Re: [PATCH 2/2] Input: tca8418 - switch to using generic device properties

[Maxime Ripard]

On Thu, Jan 19, 2017 at 02:48:03PM -0800, Dmitry Torokhov wrote:
> Let's drop legacy platform data support (there are no users in mainline)
> and switch to using generic device properties, which will make the driver
> simpler (non-OF boards can use property sets to describe hardware).
> 
> Signed-off-by: Dmitry Torokhov 

Reviewed-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board

[Eddie Cai]

2017-01-19 17:58 GMT+08:00 Heiko Stuebner :
> Hi Eddie,
>
> Am Donnerstag, 19. Januar 2017, 10:11:59 CET schrieb Eddie Cai:
>> This patch add basic support for RK3288-Tinker board. We can boot in to
>> rootfs with this patch.
>>
>> Signed-off-by: Eddie Cai 
>
> looks good in general, just some small question down below.
>
> [...]
>
>> + /*
>> +  * NOTE: vcc_sd isn't hooked up on v1.0 boards where power comes from
>> +  * vcc_io directly.  Those boards won't be able to power cycle SD cards
>> +  * but it shouldn't hurt to toggle this pin there anyway.
>> +  */
>
> just to clarify, later board will have that pin connected, right?
Copy from rk3288-evb.dtsi. forgot to delete it. I will remove it in next version
>
>> + vcc_sd: sdmmc-regulator {
>> + compatible = "regulator-fixed";
>> + gpio = < 11 GPIO_ACTIVE_LOW>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pwr>;
>> + regulator-name = "vcc_sd";
>> + regulator-min-microvolt = <330>;
>> + regulator-max-microvolt = <330>;
>> + startup-delay-us = <10>;
>> + vin-supply = <_io>;
>> + };
>> +};
>
> [...]
>
>> + {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + #sound-dai-cells = <0>;
>> + ddc-i2c-bus = <>;
>> + status = "okay";
>> + /* Don't use vopl for HDMI */
>> + ports {
>> + hdmi_in: port {
>> + /delete-node/ endpoint@1;
>> + };
>
> what is the reason for this? You enable both VOPs below and the linux display
> subsystem should be able to select an appropriate VOP for output just fine on
> its own. So there should be no reason for capping the hdmi's connection to one
> of the vops.
The VOP big support 4k display. is designed for HDMI  4K display. VOP
little is for other display(eDP, LVDS, Mipi etc)
>
>> + };
>> +};
>
> [...]
>
>> +_host0_ehci {
>> + no-relinquish-port;
>
> This seems like an unused/undocumented property
I will remove it in next version
>
>> + status = "okay";
>> +};
>
> [...]
>
>> + {
>> + status = "okay";
>> + /* Don't use vopl for HDMI */
>> + vopl_out: port {
>> + /delete-node/ endpoint@0;
>> + };
>
> see comment at the hdmi node
>
>> +};
>
>
> Thanks
> Heiko

Re: [PATCH 2/2] Input: tca8418 - switch to using generic device properties

[Maxime Ripard]

On Thu, Jan 19, 2017 at 02:48:03PM -0800, Dmitry Torokhov wrote:
> Let's drop legacy platform data support (there are no users in mainline)
> and switch to using generic device properties, which will make the driver
> simpler (non-OF boards can use property sets to describe hardware).
> 
> Signed-off-by: Dmitry Torokhov 

Reviewed-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [patch] mm, oom: header nodemask is NULL when cpusets are disabled

[Hillf Danton]

On Friday, January 20, 2017 6:58 AM David Rientjes wrote: 
> 
> Commit 82e7d3abec86 ("oom: print nodemask in the oom report") implicitly
> sets the allocation nodemask to cpuset_current_mems_allowed when there is
> no effective mempolicy.  cpuset_current_mems_allowed is only effective
> when cpusets are enabled, which is also printed by dump_header(), so
> setting the nodemask to cpuset_current_mems_allowed is redundant and
> prevents debugging issues where ac->nodemask is not set properly in the
> page allocator.
> 
> This provides better debugging output since
> cpuset_print_current_mems_allowed() is already provided.
> 
> Suggested-by: Vlastimil Babka 
> Signed-off-by: David Rientjes 
> ---
Acked-by: Hillf Danton 

>  mm/oom_kill.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -403,12 +403,14 @@ static void dump_tasks(struct mem_cgroup *memcg, const 
> nodemask_t *nodemask)
> 
>  static void dump_header(struct oom_control *oc, struct task_struct *p)
>  {
> - nodemask_t *nm = (oc->nodemask) ? oc->nodemask : 
> _current_mems_allowed;
> -
> - pr_warn("%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, 
> order=%d, oom_score_adj=%hd\n",
> - current->comm, oc->gfp_mask, >gfp_mask,
> - nodemask_pr_args(nm), oc->order,
> - current->signal->oom_score_adj);
> + pr_warn("%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=",
> + current->comm, oc->gfp_mask, >gfp_mask);
> + if (oc->nodemask)
> + pr_cont("%*pbl", nodemask_pr_args(oc->nodemask));
> + else
> + pr_cont("(null)\n");

Nit: no newline needed.

> + pr_cont(",  order=%d, oom_score_adj=%hd\n",
> + oc->order, current->signal->oom_score_adj);
>   if (!IS_ENABLED(CONFIG_COMPACTION) && oc->order)
>   pr_warn("COMPACTION is disabled!!!\n");
> 
> @@ -417,7 +419,7 @@ static void dump_header(struct oom_control *oc, struct 
> task_struct *p)
>   if (oc->memcg)
>   mem_cgroup_print_oom_info(oc->memcg, p);
>   else
> - show_mem(SHOW_MEM_FILTER_NODES, nm);
> + show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
>   if (sysctl_oom_dump_tasks)
>   dump_tasks(oc->memcg, oc->nodemask);
>  }
> 

Re: powerpc/nvram: Move an assignment for the variable "ret" in dev_nvram_write()

[SF Markus Elfring]

> I think you really could have squashed patches 1-3 into a single patch
> that returns directly after any failure.

Thanks for your constructive feedback.

I have got software development concerns around such patch squashing.


> At this point you might as well remove that label and move the kfree(tmp) 
> call up
> and return directly after the failure and at the nvram_write() call site
> doing away completely with the "ret" variable.

Your idea might look nice at first glance. But I would interpret the previous
implementation of the discussed function in the way that the memory which was
dynamically allocated here should always (not only in the failure case) be 
released
before returning here.

Would you really like to change the life time for this “temporary” data item?

Regards,
Markus

Re: powerpc/nvram: Move an assignment for the variable "ret" in dev_nvram_write()

[SF Markus Elfring]

> I think you really could have squashed patches 1-3 into a single patch
> that returns directly after any failure.

Thanks for your constructive feedback.

I have got software development concerns around such patch squashing.


> At this point you might as well remove that label and move the kfree(tmp) 
> call up
> and return directly after the failure and at the nvram_write() call site
> doing away completely with the "ret" variable.

Your idea might look nice at first glance. But I would interpret the previous
implementation of the discussed function in the way that the memory which was
dynamically allocated here should always (not only in the failure case) be 
released
before returning here.

Would you really like to change the life time for this “temporary” data item?

Regards,
Markus

[tip:timers/core] timerqueue: Use rb_entry_safe() instead of open-coding it

[tip-bot for Geliang Tang]

Commit-ID:  d852d39432f5d9822dd0ea8760573448338caf41
Gitweb: http://git.kernel.org/tip/d852d39432f5d9822dd0ea8760573448338caf41
Author: Geliang Tang 
AuthorDate: Tue, 20 Dec 2016 21:57:44 +0800
Committer:  Thomas Gleixner 
CommitDate: Fri, 20 Jan 2017 08:03:42 +0100

timerqueue: Use rb_entry_safe() instead of open-coding it

Signed-off-by: Geliang Tang 
Cc: Andrew Morton 
Cc: John Stultz 
Link: 
http://lkml.kernel.org/r/0d5cf199ac43792df0b6f7e2145545c30fa1dbbe.148135.git.geliangt...@gmail.com
Signed-off-by: Thomas Gleixner 

---
 lib/timerqueue.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/timerqueue.c b/lib/timerqueue.c
index adc6ee0..4a720ed 100644
--- a/lib/timerqueue.c
+++ b/lib/timerqueue.c
@@ -80,8 +80,7 @@ bool timerqueue_del(struct timerqueue_head *head, struct 
timerqueue_node *node)
if (head->next == node) {
struct rb_node *rbn = rb_next(>node);
 
-   head->next = rbn ?
-   rb_entry(rbn, struct timerqueue_node, node) : NULL;
+   head->next = rb_entry_safe(rbn, struct timerqueue_node, node);
}
rb_erase(>node, >head);
RB_CLEAR_NODE(>node);

[tip:timers/core] timerqueue: Use rb_entry_safe() instead of open-coding it

[tip-bot for Geliang Tang]

Commit-ID:  d852d39432f5d9822dd0ea8760573448338caf41
Gitweb: http://git.kernel.org/tip/d852d39432f5d9822dd0ea8760573448338caf41
Author: Geliang Tang 
AuthorDate: Tue, 20 Dec 2016 21:57:44 +0800
Committer:  Thomas Gleixner 
CommitDate: Fri, 20 Jan 2017 08:03:42 +0100

timerqueue: Use rb_entry_safe() instead of open-coding it

Signed-off-by: Geliang Tang 
Cc: Andrew Morton 
Cc: John Stultz 
Link: 
http://lkml.kernel.org/r/0d5cf199ac43792df0b6f7e2145545c30fa1dbbe.148135.git.geliangt...@gmail.com
Signed-off-by: Thomas Gleixner 

---
 lib/timerqueue.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/timerqueue.c b/lib/timerqueue.c
index adc6ee0..4a720ed 100644
--- a/lib/timerqueue.c
+++ b/lib/timerqueue.c
@@ -80,8 +80,7 @@ bool timerqueue_del(struct timerqueue_head *head, struct 
timerqueue_node *node)
if (head->next == node) {
struct rb_node *rbn = rb_next(>node);
 
-   head->next = rbn ?
-   rb_entry(rbn, struct timerqueue_node, node) : NULL;
+   head->next = rb_entry_safe(rbn, struct timerqueue_node, node);
}
rb_erase(>node, >head);
RB_CLEAR_NODE(>node);

[PATCH 6/7] drm/exynos/decon5433: signal vblank only on odd fields

[Andrzej Hajda]

In case of interlace mode irq is generated for odd and even fields, but
vblank should be signaled only for the last emitted field.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++
 include/video/exynos5433_decon.h  | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 46434ba9..ad8b93a 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -591,6 +591,13 @@ static irqreturn_t decon_irq_handler(int irq, void *dev_id)
 
if (val) {
writel(val, ctx->addr + DECON_VIDINTCON1);
+   if (ctx->out_type & IFTYPE_HDMI) {
+   val = readl(ctx->addr + DECON_VIDOUTCON0);
+   val &= VIDOUT_INTERLACE_EN_F | VIDOUT_INTERLACE_FIELD_F;
+   if (val ==
+   (VIDOUT_INTERLACE_EN_F | VIDOUT_INTERLACE_FIELD_F))
+   return IRQ_HANDLED;
+   }
drm_crtc_handle_vblank(>crtc->base);
}
 
diff --git a/include/video/exynos5433_decon.h b/include/video/exynos5433_decon.h
index b26511a..ef8e2a8 100644
--- a/include/video/exynos5433_decon.h
+++ b/include/video/exynos5433_decon.h
@@ -89,6 +89,7 @@
 #define VIDCON0_ENVID_F(1 << 0)
 
 /* VIDOUTCON0 */
+#define VIDOUT_INTERLACE_FIELD_F   (1 << 29)
 #define VIDOUT_INTERLACE_EN_F  (1 << 28)
 #define VIDOUT_LCD_ON  (1 << 24)
 #define VIDOUT_IF_F_MASK   (0x3 << 20)
-- 
2.7.4

[PATCH 6/7] drm/exynos/decon5433: signal vblank only on odd fields

[Andrzej Hajda]

In case of interlace mode irq is generated for odd and even fields, but
vblank should be signaled only for the last emitted field.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++
 include/video/exynos5433_decon.h  | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 46434ba9..ad8b93a 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -591,6 +591,13 @@ static irqreturn_t decon_irq_handler(int irq, void *dev_id)
 
if (val) {
writel(val, ctx->addr + DECON_VIDINTCON1);
+   if (ctx->out_type & IFTYPE_HDMI) {
+   val = readl(ctx->addr + DECON_VIDOUTCON0);
+   val &= VIDOUT_INTERLACE_EN_F | VIDOUT_INTERLACE_FIELD_F;
+   if (val ==
+   (VIDOUT_INTERLACE_EN_F | VIDOUT_INTERLACE_FIELD_F))
+   return IRQ_HANDLED;
+   }
drm_crtc_handle_vblank(>crtc->base);
}
 
diff --git a/include/video/exynos5433_decon.h b/include/video/exynos5433_decon.h
index b26511a..ef8e2a8 100644
--- a/include/video/exynos5433_decon.h
+++ b/include/video/exynos5433_decon.h
@@ -89,6 +89,7 @@
 #define VIDCON0_ENVID_F(1 << 0)
 
 /* VIDOUTCON0 */
+#define VIDOUT_INTERLACE_FIELD_F   (1 << 29)
 #define VIDOUT_INTERLACE_EN_F  (1 << 28)
 #define VIDOUT_LCD_ON  (1 << 24)
 #define VIDOUT_IF_F_MASK   (0x3 << 20)
-- 
2.7.4

[PATCH 2/7] drm/exynos/hdmi: fix VSI infoframe registers

[Andrzej Hajda]

VSI infoframe registers address space is non-contiguous, so infoframe write
should be split into two chunks.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bef8965..223b872 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -797,7 +797,8 @@ static void hdmi_reg_infoframes(struct hdmi_context *hdata)
sizeof(buf));
if (ret > 0) {
hdmi_reg_writeb(hdata, HDMI_VSI_CON, HDMI_VSI_CON_EVERY_VSYNC);
-   hdmi_reg_write_buf(hdata, HDMI_VSI_HEADER0, buf, ret);
+   hdmi_reg_write_buf(hdata, HDMI_VSI_HEADER0, buf, 3);
+   hdmi_reg_write_buf(hdata, HDMI_VSI_DATA(0), buf + 3, ret - 3);
}
 
ret = hdmi_audio_infoframe_init();
-- 
2.7.4

[PATCH 2/7] drm/exynos/hdmi: fix VSI infoframe registers

[Andrzej Hajda]

VSI infoframe registers address space is non-contiguous, so infoframe write
should be split into two chunks.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bef8965..223b872 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -797,7 +797,8 @@ static void hdmi_reg_infoframes(struct hdmi_context *hdata)
sizeof(buf));
if (ret > 0) {
hdmi_reg_writeb(hdata, HDMI_VSI_CON, HDMI_VSI_CON_EVERY_VSYNC);
-   hdmi_reg_write_buf(hdata, HDMI_VSI_HEADER0, buf, ret);
+   hdmi_reg_write_buf(hdata, HDMI_VSI_HEADER0, buf, 3);
+   hdmi_reg_write_buf(hdata, HDMI_VSI_DATA(0), buf + 3, ret - 3);
}
 
ret = hdmi_audio_infoframe_init();
-- 
2.7.4

[PATCH 4/7] drm/exynos/hdmi: add bridge support

[Andrzej Hajda]

In some platforms there is attached another device to the end of HDMI.
The patch adds support for it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 56 +---
 1 file changed, 46 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a73b192..41fb894 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -133,6 +134,7 @@ struct hdmi_context {
struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
struct regulator*reg_hdmi_en;
struct exynos_drm_clk   phy_clk;
+   struct drm_bridge   *bridge;
 };
 
 static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
@@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
*encoder)
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
 
-   return 0;
+   if (hdata->bridge) {
+   encoder->bridge = hdata->bridge;
+   hdata->bridge->encoder = encoder;
+   ret = drm_bridge_attach(encoder->dev, hdata->bridge);
+   if (ret)
+   DRM_ERROR("Failed to attach bridge\n");
+   }
+
+   return ret;
 }
 
 static bool hdmi_mode_fixup(struct drm_encoder *encoder,
@@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
*clk, bool enable)
hdmiphy_disable(hdata);
 }
 
+static int hdmi_bridge_init(struct hdmi_context *hdata)
+{
+   struct device *dev = hdata->dev;
+   struct device_node *ep, *np;
+
+   ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
+   if (!ep)
+   return 0;
+
+   np = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
+   if (!np) {
+   DRM_ERROR("failed to get remote port parent");
+   return -EINVAL;
+   }
+
+   hdata->bridge = of_drm_find_bridge(np);
+   of_node_put(np);
+
+   if (!hdata->bridge)
+   return -EPROBE_DEFER;
+
+   return 0;
+}
+
 static int hdmi_resources_init(struct hdmi_context *hdata)
 {
struct device *dev = hdata->dev;
@@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
 
hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
 
-   if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
-   return 0;
+   if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
+   if (IS_ERR(hdata->reg_hdmi_en))
+   return PTR_ERR(hdata->reg_hdmi_en);
 
-   if (IS_ERR(hdata->reg_hdmi_en))
-   return PTR_ERR(hdata->reg_hdmi_en);
-
-   ret = regulator_enable(hdata->reg_hdmi_en);
-   if (ret)
-   DRM_ERROR("failed to enable hdmi-en regulator\n");
+   ret = regulator_enable(hdata->reg_hdmi_en);
+   if (ret) {
+   DRM_ERROR("failed to enable hdmi-en regulator\n");
+   return ret;
+   }
+   }
 
-   return ret;
+   return hdmi_bridge_init(hdata);
 }
 
 static struct of_device_id hdmi_match_types[] = {
-- 
2.7.4

[PATCH 4/7] drm/exynos/hdmi: add bridge support

[Andrzej Hajda]

In some platforms there is attached another device to the end of HDMI.
The patch adds support for it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 56 +---
 1 file changed, 46 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a73b192..41fb894 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -133,6 +134,7 @@ struct hdmi_context {
struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
struct regulator*reg_hdmi_en;
struct exynos_drm_clk   phy_clk;
+   struct drm_bridge   *bridge;
 };
 
 static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
@@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
*encoder)
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
 
-   return 0;
+   if (hdata->bridge) {
+   encoder->bridge = hdata->bridge;
+   hdata->bridge->encoder = encoder;
+   ret = drm_bridge_attach(encoder->dev, hdata->bridge);
+   if (ret)
+   DRM_ERROR("Failed to attach bridge\n");
+   }
+
+   return ret;
 }
 
 static bool hdmi_mode_fixup(struct drm_encoder *encoder,
@@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
*clk, bool enable)
hdmiphy_disable(hdata);
 }
 
+static int hdmi_bridge_init(struct hdmi_context *hdata)
+{
+   struct device *dev = hdata->dev;
+   struct device_node *ep, *np;
+
+   ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
+   if (!ep)
+   return 0;
+
+   np = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
+   if (!np) {
+   DRM_ERROR("failed to get remote port parent");
+   return -EINVAL;
+   }
+
+   hdata->bridge = of_drm_find_bridge(np);
+   of_node_put(np);
+
+   if (!hdata->bridge)
+   return -EPROBE_DEFER;
+
+   return 0;
+}
+
 static int hdmi_resources_init(struct hdmi_context *hdata)
 {
struct device *dev = hdata->dev;
@@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
 
hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
 
-   if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
-   return 0;
+   if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
+   if (IS_ERR(hdata->reg_hdmi_en))
+   return PTR_ERR(hdata->reg_hdmi_en);
 
-   if (IS_ERR(hdata->reg_hdmi_en))
-   return PTR_ERR(hdata->reg_hdmi_en);
-
-   ret = regulator_enable(hdata->reg_hdmi_en);
-   if (ret)
-   DRM_ERROR("failed to enable hdmi-en regulator\n");
+   ret = regulator_enable(hdata->reg_hdmi_en);
+   if (ret) {
+   DRM_ERROR("failed to enable hdmi-en regulator\n");
+   return ret;
+   }
+   }
 
-   return ret;
+   return hdmi_bridge_init(hdata);
 }
 
 static struct of_device_id hdmi_match_types[] = {
-- 
2.7.4

[PATCH 1/7] drm/exynos/hdmi: add 297MHz pixel clock support

[Andrzej Hajda]

297MHz is used by Ultra HD modes.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5ed8b1e..bef8965 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -587,6 +587,15 @@ static const struct hdmiphy_config hdmiphy_5433_configs[] 
= {
0x08, 0x10, 0x01, 0x01, 0x48, 0x4a, 0x00, 0x40,
},
},
+   {
+   .pixel_clock = 29700,
+   .conf = {
+   0x01, 0x51, 0x3E, 0x05, 0x40, 0xF0, 0x88, 0xC2,
+   0x52, 0x53, 0x44, 0x8C, 0x27, 0x00, 0x7C, 0xAC,
+   0xD6, 0x2B, 0x67, 0x00, 0x00, 0x04, 0x00, 0x30,
+   0x08, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
+   },
+   },
 };
 
 static const char * const hdmi_clk_gates4[] = {
-- 
2.7.4

[PATCH 0/7] drm/exynos: add Ultra HD and interlace modes support to Exynos5433

[Andrzej Hajda]

Hi Inki,

This patchset adds support for UltraHD and intrelace modes on DECON and HDMI
drivers of Exynos5433 chipset. To fully support it on TM2(e) platforms MHL
patches are alse required which will be posted in separate patchset.

Krzysztof, DTS patch do not depend on the previous patches, so there is
no need to synchronize branches.

Regards
Andrzej


Andrzej Hajda (7):
  drm/exynos/hdmi: add 297MHz pixel clock support
  drm/exynos/hdmi: fix VSI infoframe registers
  drm/exynos/hdmi: fix PLL for 27MHz settings
  drm/exynos/hdmi: add bridge support
  drm/exynos/decon5433: add support for interlace modes
  drm/exynos/decon5433: signal vblank only on odd fields
  arm64: dts: exynos: configure TV path clocks for Ultra HD modes

 arch/arm64/boot/dts/exynos/exynos5433.dtsi|  3 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 52 -
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 80 +--
 include/video/exynos5433_decon.h  |  2 +
 4 files changed, 107 insertions(+), 30 deletions(-)

-- 
2.7.4

[PATCH 3/7] drm/exynos/hdmi: fix PLL for 27MHz settings

[Andrzej Hajda]

Current settings for 27MHz and 27.027MHz do not work. Use the settings from
vendor code instead.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 223b872..a73b192 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -509,9 +509,9 @@ static const struct hdmiphy_config hdmiphy_5433_configs[] = 
{
{
.pixel_clock = 2700,
.conf = {
-   0x01, 0x51, 0x22, 0x51, 0x08, 0xfc, 0x88, 0x46,
-   0x72, 0x50, 0x24, 0x0c, 0x24, 0x0f, 0x7c, 0xa5,
-   0xd4, 0x2b, 0x87, 0x00, 0x00, 0x04, 0x00, 0x30,
+   0x01, 0x51, 0x2d, 0x75, 0x01, 0x00, 0x88, 0x02,
+   0x72, 0x50, 0x44, 0x8c, 0x27, 0x00, 0x7c, 0xac,
+   0xd6, 0x2b, 0x67, 0x00, 0x00, 0x04, 0x00, 0x30,
0x08, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
},
},
@@ -519,9 +519,9 @@ static const struct hdmiphy_config hdmiphy_5433_configs[] = 
{
.pixel_clock = 27027000,
.conf = {
0x01, 0x51, 0x2d, 0x72, 0x64, 0x09, 0x88, 0xc3,
-   0x71, 0x50, 0x24, 0x14, 0x24, 0x0f, 0x7c, 0xa5,
-   0xd4, 0x2b, 0x87, 0x00, 0x00, 0x04, 0x00, 0x30,
-   0x28, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
+   0x71, 0x50, 0x44, 0x8c, 0x27, 0x00, 0x7c, 0xac,
+   0xd6, 0x2b, 0x67, 0x00, 0x00, 0x04, 0x00, 0x30,
+   0x08, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
},
},
{
-- 
2.7.4

[PATCH 5/7] drm/exynos/decon5433: add support for interlace modes

[Andrzej Hajda]

Some registers should be programmed differently in interlace mode.
Additionally IP does not signal stop state properly in interlaced
mode, so warning has been removed.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 45 +++
 include/video/exynos5433_decon.h  |  1 +
 2 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 042d6ef..46434ba9 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -146,6 +146,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
struct drm_display_mode *m = >base.mode;
+   bool interlaced = false;
u32 val;
 
if (test_bit(BIT_SUSPENDED, >flags))
@@ -156,12 +157,16 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
m->crtc_hsync_end = m->crtc_htotal - 92;
m->crtc_vsync_start = m->crtc_vdisplay + 1;
m->crtc_vsync_end = m->crtc_vsync_start + 1;
+   if (m->flags & DRM_MODE_FLAG_INTERLACE)
+   interlaced = true;
}
 
decon_setup_trigger(ctx);
 
/* lcd on and use command if */
val = VIDOUT_LCD_ON;
+   if (interlaced)
+   val |= VIDOUT_INTERLACE_EN_F;
if (ctx->out_type & IFTYPE_I80) {
val |= VIDOUT_COMMAND_IF;
} else {
@@ -170,15 +175,21 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
 
writel(val, ctx->addr + DECON_VIDOUTCON0);
 
-   val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
-   VIDTCON2_HOZVAL(m->hdisplay - 1);
+   if (interlaced)
+   val = VIDTCON2_LINEVAL(m->vdisplay / 2 - 1) |
+   VIDTCON2_HOZVAL(m->hdisplay - 1);
+   else
+   val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
+   VIDTCON2_HOZVAL(m->hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON2);
 
if (!(ctx->out_type & IFTYPE_I80)) {
-   val = VIDTCON00_VBPD_F(
-   m->crtc_vtotal - m->crtc_vsync_end - 1) |
-   VIDTCON00_VFPD_F(
-   m->crtc_vsync_start - m->crtc_vdisplay - 1);
+   int vbp = m->crtc_vtotal - m->crtc_vsync_end;
+   int vfp = m->crtc_vsync_start - m->crtc_vdisplay;
+
+   if (interlaced)
+   vbp = vbp / 2 - 1;
+   val = VIDTCON00_VBPD_F(vbp - 1) | VIDTCON00_VFPD_F(vfp - 1);
writel(val, ctx->addr + DECON_VIDTCON00);
 
val = VIDTCON01_VSPW_F(
@@ -293,12 +304,22 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
if (test_bit(BIT_SUSPENDED, >flags))
return;
 
-   val = COORDINATE_X(state->crtc.x) | COORDINATE_Y(state->crtc.y);
-   writel(val, ctx->addr + DECON_VIDOSDxA(win));
+   if (crtc->base.mode.flags & DRM_MODE_FLAG_INTERLACE) {
+   val = COORDINATE_X(state->crtc.x) |
+   COORDINATE_Y(state->crtc.y / 2);
+   writel(val, ctx->addr + DECON_VIDOSDxA(win));
+
+   val = COORDINATE_X(state->crtc.x + state->crtc.w - 1) |
+   COORDINATE_Y((state->crtc.y + state->crtc.h) / 2 - 1);
+   writel(val, ctx->addr + DECON_VIDOSDxB(win));
+   } else {
+   val = COORDINATE_X(state->crtc.x) | COORDINATE_Y(state->crtc.y);
+   writel(val, ctx->addr + DECON_VIDOSDxA(win));
 
-   val = COORDINATE_X(state->crtc.x + state->crtc.w - 1) |
-   COORDINATE_Y(state->crtc.y + state->crtc.h - 1);
-   writel(val, ctx->addr + DECON_VIDOSDxB(win));
+   val = COORDINATE_X(state->crtc.x + state->crtc.w - 1) |
+   COORDINATE_Y(state->crtc.y + state->crtc.h - 1);
+   writel(val, ctx->addr + DECON_VIDOSDxB(win));
+   }
 
val = VIDOSD_Wx_ALPHA_R_F(0x0) | VIDOSD_Wx_ALPHA_G_F(0x0) |
VIDOSD_Wx_ALPHA_B_F(0x0);
@@ -370,8 +391,6 @@ static void decon_swreset(struct decon_context *ctx)
udelay(10);
}
 
-   WARN(tries == 0, "failed to disable DECON\n");
-
writel(VIDCON0_SWRESET, ctx->addr + DECON_VIDCON0);
for (tries = 2000; tries; --tries) {
if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_SWRESET)
diff --git a/include/video/exynos5433_decon.h b/include/video/exynos5433_decon.h
index 0098a52..b26511a 100644
--- a/include/video/exynos5433_decon.h
+++ b/include/video/exynos5433_decon.h
@@ -89,6 +89,7 @@
 #define VIDCON0_ENVID_F(1 << 0)
 
 /* VIDOUTCON0 */
+#define VIDOUT_INTERLACE_EN_F  (1 << 28)
 #define VIDOUT_LCD_ON  (1 << 24)
 #define VIDOUT_IF_F_MASK   (0x3 << 20)
 #define 

[PATCH 1/7] drm/exynos/hdmi: add 297MHz pixel clock support

[Andrzej Hajda]

297MHz is used by Ultra HD modes.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5ed8b1e..bef8965 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -587,6 +587,15 @@ static const struct hdmiphy_config hdmiphy_5433_configs[] 
= {
0x08, 0x10, 0x01, 0x01, 0x48, 0x4a, 0x00, 0x40,
},
},
+   {
+   .pixel_clock = 29700,
+   .conf = {
+   0x01, 0x51, 0x3E, 0x05, 0x40, 0xF0, 0x88, 0xC2,
+   0x52, 0x53, 0x44, 0x8C, 0x27, 0x00, 0x7C, 0xAC,
+   0xD6, 0x2B, 0x67, 0x00, 0x00, 0x04, 0x00, 0x30,
+   0x08, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
+   },
+   },
 };
 
 static const char * const hdmi_clk_gates4[] = {
-- 
2.7.4

[PATCH 0/7] drm/exynos: add Ultra HD and interlace modes support to Exynos5433

[Andrzej Hajda]

Hi Inki,

This patchset adds support for UltraHD and intrelace modes on DECON and HDMI
drivers of Exynos5433 chipset. To fully support it on TM2(e) platforms MHL
patches are alse required which will be posted in separate patchset.

Krzysztof, DTS patch do not depend on the previous patches, so there is
no need to synchronize branches.

Regards
Andrzej


Andrzej Hajda (7):
  drm/exynos/hdmi: add 297MHz pixel clock support
  drm/exynos/hdmi: fix VSI infoframe registers
  drm/exynos/hdmi: fix PLL for 27MHz settings
  drm/exynos/hdmi: add bridge support
  drm/exynos/decon5433: add support for interlace modes
  drm/exynos/decon5433: signal vblank only on odd fields
  arm64: dts: exynos: configure TV path clocks for Ultra HD modes

 arch/arm64/boot/dts/exynos/exynos5433.dtsi|  3 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 52 -
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 80 +--
 include/video/exynos5433_decon.h  |  2 +
 4 files changed, 107 insertions(+), 30 deletions(-)

-- 
2.7.4

[PATCH 3/7] drm/exynos/hdmi: fix PLL for 27MHz settings

[Andrzej Hajda]

Current settings for 27MHz and 27.027MHz do not work. Use the settings from
vendor code instead.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 223b872..a73b192 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -509,9 +509,9 @@ static const struct hdmiphy_config hdmiphy_5433_configs[] = 
{
{
.pixel_clock = 2700,
.conf = {
-   0x01, 0x51, 0x22, 0x51, 0x08, 0xfc, 0x88, 0x46,
-   0x72, 0x50, 0x24, 0x0c, 0x24, 0x0f, 0x7c, 0xa5,
-   0xd4, 0x2b, 0x87, 0x00, 0x00, 0x04, 0x00, 0x30,
+   0x01, 0x51, 0x2d, 0x75, 0x01, 0x00, 0x88, 0x02,
+   0x72, 0x50, 0x44, 0x8c, 0x27, 0x00, 0x7c, 0xac,
+   0xd6, 0x2b, 0x67, 0x00, 0x00, 0x04, 0x00, 0x30,
0x08, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
},
},
@@ -519,9 +519,9 @@ static const struct hdmiphy_config hdmiphy_5433_configs[] = 
{
.pixel_clock = 27027000,
.conf = {
0x01, 0x51, 0x2d, 0x72, 0x64, 0x09, 0x88, 0xc3,
-   0x71, 0x50, 0x24, 0x14, 0x24, 0x0f, 0x7c, 0xa5,
-   0xd4, 0x2b, 0x87, 0x00, 0x00, 0x04, 0x00, 0x30,
-   0x28, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
+   0x71, 0x50, 0x44, 0x8c, 0x27, 0x00, 0x7c, 0xac,
+   0xd6, 0x2b, 0x67, 0x00, 0x00, 0x04, 0x00, 0x30,
+   0x08, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
},
},
{
-- 
2.7.4

[PATCH 5/7] drm/exynos/decon5433: add support for interlace modes

[Andrzej Hajda]

Some registers should be programmed differently in interlace mode.
Additionally IP does not signal stop state properly in interlaced
mode, so warning has been removed.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 45 +++
 include/video/exynos5433_decon.h  |  1 +
 2 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 042d6ef..46434ba9 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -146,6 +146,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
struct drm_display_mode *m = >base.mode;
+   bool interlaced = false;
u32 val;
 
if (test_bit(BIT_SUSPENDED, >flags))
@@ -156,12 +157,16 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
m->crtc_hsync_end = m->crtc_htotal - 92;
m->crtc_vsync_start = m->crtc_vdisplay + 1;
m->crtc_vsync_end = m->crtc_vsync_start + 1;
+   if (m->flags & DRM_MODE_FLAG_INTERLACE)
+   interlaced = true;
}
 
decon_setup_trigger(ctx);
 
/* lcd on and use command if */
val = VIDOUT_LCD_ON;
+   if (interlaced)
+   val |= VIDOUT_INTERLACE_EN_F;
if (ctx->out_type & IFTYPE_I80) {
val |= VIDOUT_COMMAND_IF;
} else {
@@ -170,15 +175,21 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
 
writel(val, ctx->addr + DECON_VIDOUTCON0);
 
-   val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
-   VIDTCON2_HOZVAL(m->hdisplay - 1);
+   if (interlaced)
+   val = VIDTCON2_LINEVAL(m->vdisplay / 2 - 1) |
+   VIDTCON2_HOZVAL(m->hdisplay - 1);
+   else
+   val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
+   VIDTCON2_HOZVAL(m->hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON2);
 
if (!(ctx->out_type & IFTYPE_I80)) {
-   val = VIDTCON00_VBPD_F(
-   m->crtc_vtotal - m->crtc_vsync_end - 1) |
-   VIDTCON00_VFPD_F(
-   m->crtc_vsync_start - m->crtc_vdisplay - 1);
+   int vbp = m->crtc_vtotal - m->crtc_vsync_end;
+   int vfp = m->crtc_vsync_start - m->crtc_vdisplay;
+
+   if (interlaced)
+   vbp = vbp / 2 - 1;
+   val = VIDTCON00_VBPD_F(vbp - 1) | VIDTCON00_VFPD_F(vfp - 1);
writel(val, ctx->addr + DECON_VIDTCON00);
 
val = VIDTCON01_VSPW_F(
@@ -293,12 +304,22 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
if (test_bit(BIT_SUSPENDED, >flags))
return;
 
-   val = COORDINATE_X(state->crtc.x) | COORDINATE_Y(state->crtc.y);
-   writel(val, ctx->addr + DECON_VIDOSDxA(win));
+   if (crtc->base.mode.flags & DRM_MODE_FLAG_INTERLACE) {
+   val = COORDINATE_X(state->crtc.x) |
+   COORDINATE_Y(state->crtc.y / 2);
+   writel(val, ctx->addr + DECON_VIDOSDxA(win));
+
+   val = COORDINATE_X(state->crtc.x + state->crtc.w - 1) |
+   COORDINATE_Y((state->crtc.y + state->crtc.h) / 2 - 1);
+   writel(val, ctx->addr + DECON_VIDOSDxB(win));
+   } else {
+   val = COORDINATE_X(state->crtc.x) | COORDINATE_Y(state->crtc.y);
+   writel(val, ctx->addr + DECON_VIDOSDxA(win));
 
-   val = COORDINATE_X(state->crtc.x + state->crtc.w - 1) |
-   COORDINATE_Y(state->crtc.y + state->crtc.h - 1);
-   writel(val, ctx->addr + DECON_VIDOSDxB(win));
+   val = COORDINATE_X(state->crtc.x + state->crtc.w - 1) |
+   COORDINATE_Y(state->crtc.y + state->crtc.h - 1);
+   writel(val, ctx->addr + DECON_VIDOSDxB(win));
+   }
 
val = VIDOSD_Wx_ALPHA_R_F(0x0) | VIDOSD_Wx_ALPHA_G_F(0x0) |
VIDOSD_Wx_ALPHA_B_F(0x0);
@@ -370,8 +391,6 @@ static void decon_swreset(struct decon_context *ctx)
udelay(10);
}
 
-   WARN(tries == 0, "failed to disable DECON\n");
-
writel(VIDCON0_SWRESET, ctx->addr + DECON_VIDCON0);
for (tries = 2000; tries; --tries) {
if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_SWRESET)
diff --git a/include/video/exynos5433_decon.h b/include/video/exynos5433_decon.h
index 0098a52..b26511a 100644
--- a/include/video/exynos5433_decon.h
+++ b/include/video/exynos5433_decon.h
@@ -89,6 +89,7 @@
 #define VIDCON0_ENVID_F(1 << 0)
 
 /* VIDOUTCON0 */
+#define VIDOUT_INTERLACE_EN_F  (1 << 28)
 #define VIDOUT_LCD_ON  (1 << 24)
 #define VIDOUT_IF_F_MASK   (0x3 << 20)
 #define VIDOUT_RGB_IF  

[PATCH 7/7] arm64: dts: exynos: configure TV path clocks for Ultra HD modes

[Andrzej Hajda]

Ultra HD modes requires clock ticking at increased rate.

Signed-off-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index f120d99..314d928 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -764,6 +764,9 @@
clock-names = "pclk", "aclk_decon", "aclk_smmu_decon0x",
  "aclk_xiu_decon0x", "pclk_smmu_decon0x",
  "sclk_decon_vclk", "sclk_decon_eclk";
+   assigned-clocks = <_mif 
CLK_MOUT_SCLK_DECON_TV_ECLK_A>, <_mif CLK_DIV_SCLK_DECON_TV_ECLK>, 
<_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>, <_disp 
CLK_MOUT_SCLK_DECON_TV_ECLK>;
+   assigned-clock-parents = <_mif 
CLK_MOUT_BUS_PLL_DIV2>, <0>, <_mif CLK_SCLK_DECON_TV_ECLK_DISP>, <_disp 
CLK_MOUT_SCLK_DECON_TV_ECLK_USER>;
+   assigned-clock-rates = <0>, <4>;
samsung,disp-sysreg = <_disp>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = ,
-- 
2.7.4

[PATCH 7/7] arm64: dts: exynos: configure TV path clocks for Ultra HD modes

[Andrzej Hajda]

Ultra HD modes requires clock ticking at increased rate.

Signed-off-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index f120d99..314d928 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -764,6 +764,9 @@
clock-names = "pclk", "aclk_decon", "aclk_smmu_decon0x",
  "aclk_xiu_decon0x", "pclk_smmu_decon0x",
  "sclk_decon_vclk", "sclk_decon_eclk";
+   assigned-clocks = <_mif 
CLK_MOUT_SCLK_DECON_TV_ECLK_A>, <_mif CLK_DIV_SCLK_DECON_TV_ECLK>, 
<_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>, <_disp 
CLK_MOUT_SCLK_DECON_TV_ECLK>;
+   assigned-clock-parents = <_mif 
CLK_MOUT_BUS_PLL_DIV2>, <0>, <_mif CLK_SCLK_DECON_TV_ECLK_DISP>, <_disp 
CLK_MOUT_SCLK_DECON_TV_ECLK_USER>;
+   assigned-clock-rates = <0>, <4>;
samsung,disp-sysreg = <_disp>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = ,
-- 
2.7.4

Re: [PATCH 1/2] pwm: pca9685: fix period change with same duty cycle

[Thierry Reding]

On Tue, Dec 13, 2016 at 04:52:50PM +0100, Clemens Gruber wrote:
> When first implementing support for changing the output frequency, an
> optimization was added to continue the PWM after changing the prescaler
> without having to reprogram the ON and OFF registers for the duty cycle,
> in case the duty cycle stayed the same.
> This was flawed, because we compared the absolute value of the duty
> cycle in nanoseconds instead of the ratio to the period.
> 
> Fix the problem by removing the shortcut.
> 
> Fixes: 01ec8472009c9 ("pwm-pca9685: Support changing the output
> frequency")
> Cc:  # v4.3+
> Signed-off-by: Clemens Gruber 
> ---
>  drivers/pwm/pwm-pca9685.c | 11 ---
>  1 file changed, 11 deletions(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: linux-next: manual merge of the scsi tree with the tip tree

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi James,
> 
> Today's linux-next merge of the scsi tree got a conflict in:
> 
>   drivers/scsi/mpt3sas/mpt3sas_scsih.c
> 
> between commit:
> 
>   e963b7088dac ("scsi: mpt3sas: Fix hang on ata passthru commands")
> 
> from the tip tree and commit:
> 
>   ffb584565894 ("scsi: mpt3sas: fix hang on ata passthrough commands")
> 
> from the scsi tree.
> 
> I fixed it up (slightly different versions of the same patch - I used
> the latter version) and can carry the fix as necessary. This is now
> fixed as far as linux-next is concerned, but any non trivial conflicts
> should be mentioned to your upstream maintainer when your tree is
> submitted for merging.  You may also want to consider cooperating with
> the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

I only had that patch for testing and it went into the -next branch by accident 
- 
I have removed it so the conflict should be gone next time -next is integrated.

Thanks,

Ingo

Re: [PATCH 1/2] pwm: pca9685: fix period change with same duty cycle

[Thierry Reding]

On Tue, Dec 13, 2016 at 04:52:50PM +0100, Clemens Gruber wrote:
> When first implementing support for changing the output frequency, an
> optimization was added to continue the PWM after changing the prescaler
> without having to reprogram the ON and OFF registers for the duty cycle,
> in case the duty cycle stayed the same.
> This was flawed, because we compared the absolute value of the duty
> cycle in nanoseconds instead of the ratio to the period.
> 
> Fix the problem by removing the shortcut.
> 
> Fixes: 01ec8472009c9 ("pwm-pca9685: Support changing the output
> frequency")
> Cc:  # v4.3+
> Signed-off-by: Clemens Gruber 
> ---
>  drivers/pwm/pwm-pca9685.c | 11 ---
>  1 file changed, 11 deletions(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: linux-next: manual merge of the scsi tree with the tip tree

[Ingo Molnar]

* Stephen Rothwell  wrote:

> Hi James,
> 
> Today's linux-next merge of the scsi tree got a conflict in:
> 
>   drivers/scsi/mpt3sas/mpt3sas_scsih.c
> 
> between commit:
> 
>   e963b7088dac ("scsi: mpt3sas: Fix hang on ata passthru commands")
> 
> from the tip tree and commit:
> 
>   ffb584565894 ("scsi: mpt3sas: fix hang on ata passthrough commands")
> 
> from the scsi tree.
> 
> I fixed it up (slightly different versions of the same patch - I used
> the latter version) and can carry the fix as necessary. This is now
> fixed as far as linux-next is concerned, but any non trivial conflicts
> should be mentioned to your upstream maintainer when your tree is
> submitted for merging.  You may also want to consider cooperating with
> the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

I only had that patch for testing and it went into the -next branch by accident 
- 
I have removed it so the conflict should be gone next time -next is integrated.

Thanks,

Ingo

[PATCH net] r8152: fix rtl8152_post_reset function

[Hayes Wang]

The rtl8152_post_reset() should sumbit rx urb and interrupt transfer,
otherwise the rx wouldn't work and the linking change couldn't be
detected.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3b48ad..0e99af0 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3545,12 +3545,14 @@ static int rtl8152_post_reset(struct usb_interface 
*intf)
if (netif_carrier_ok(netdev)) {
mutex_lock(>control);
tp->rtl_ops.enable(tp);
+   rtl_start_rx(tp);
rtl8152_set_rx_mode(netdev);
mutex_unlock(>control);
netif_wake_queue(netdev);
}
 
napi_enable(>napi);
+   usb_submit_urb(tp->intr_urb, GFP_KERNEL);
 
return 0;
 }
-- 
2.7.4

[PATCH net] r8152: fix rtl8152_post_reset function

[Hayes Wang]

The rtl8152_post_reset() should sumbit rx urb and interrupt transfer,
otherwise the rx wouldn't work and the linking change couldn't be
detected.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3b48ad..0e99af0 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3545,12 +3545,14 @@ static int rtl8152_post_reset(struct usb_interface 
*intf)
if (netif_carrier_ok(netdev)) {
mutex_lock(>control);
tp->rtl_ops.enable(tp);
+   rtl_start_rx(tp);
rtl8152_set_rx_mode(netdev);
mutex_unlock(>control);
netif_wake_queue(netdev);
}
 
napi_enable(>napi);
+   usb_submit_urb(tp->intr_urb, GFP_KERNEL);
 
return 0;
 }
-- 
2.7.4

Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone

[Hillf Danton]

On Thursday, January 19, 2017 6:08 PM Mel Gorman wrote: 
> 
> If it's definitely required and is proven to fix the
> infinite-loop-without-oom workload then I'll back off and withdraw my
> objections. However, I'd at least like the following untested patch to
> be considered as an alternative. It has some weaknesses and would be
> slower to OOM than your patch but it avoids reintroducing zone counters
> 
> ---8<---
> mm, vmscan: Wait on a waitqueue when too many pages are isolated
> 
> When too many pages are isolated, direct reclaim waits on congestion to clear
> for up to a tenth of a second. There is no reason to believe that too many
> pages are isolated due to dirty pages, reclaim efficiency or congestion.
> It may simply be because an extremely large number of processes have entered
> direct reclaim at the same time. However, it is possible for the situation
> to persist forever and never reach OOM.
> 
> This patch queues processes a waitqueue when too many pages are isolated.
> When parallel reclaimers finish shrink_page_list, they wake the waiters
> to recheck whether too many pages are isolated.
> 
> The wait on the queue has a timeout as not all sites that isolate pages
> will do the wakeup. Depending on every isolation of LRU pages to be perfect
> forever is potentially fragile. The specific wakeups occur for page reclaim
> and compaction. If too many pages are isolated due to memory failure,
> hotplug or directly calling migration from a syscall then the waiting
> processes may wait the full timeout.
> 
> Note that the timeout allows the use of waitqueue_active() on the basis
> that a race will cause the full timeout to be reached due to a missed
> wakeup. This is relatively harmless and still a massive improvement over
> unconditionally calling congestion_wait.
> 
> Direct reclaimers that cannot isolate pages within the timeout will consider
> return to the caller. This is somewhat clunky as it won't return immediately
> and make go through the other priorities and slab shrinking. Eventually,
> it'll go through a few iterations of should_reclaim_retry and reach the
> MAX_RECLAIM_RETRIES limit and consider going OOM.
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 91f69aa0d581..3dd617d0c8c4 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -628,6 +628,7 @@ typedef struct pglist_data {
>   int node_id;
>   wait_queue_head_t kswapd_wait;
>   wait_queue_head_t pfmemalloc_wait;
> + wait_queue_head_t isolated_wait;
>   struct task_struct *kswapd; /* Protected by
>  mem_hotplug_begin/end() */
>   int kswapd_order;
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 43a6cf1dc202..1b1ff6da7401 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1634,6 +1634,10 @@ static enum compact_result compact_zone(struct zone 
> *zone, struct compact_contro
>   count_compact_events(COMPACTMIGRATE_SCANNED, cc->total_migrate_scanned);
>   count_compact_events(COMPACTFREE_SCANNED, cc->total_free_scanned);
> 
> + /* Page reclaim could have stalled due to isolated pages */
> + if (waitqueue_active(>zone_pgdat->isolated_wait))
> + wake_up(>zone_pgdat->isolated_wait);
> +
>   trace_mm_compaction_end(start_pfn, cc->migrate_pfn,
>   cc->free_pfn, end_pfn, sync, ret);
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 8ff25883c172..d848c9f31bff 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5823,6 +5823,7 @@ static void __paginginit free_area_init_core(struct 
> pglist_data *pgdat)
>  #endif
>   init_waitqueue_head(>kswapd_wait);
>   init_waitqueue_head(>pfmemalloc_wait);
> + init_waitqueue_head(>isolated_wait);
>  #ifdef CONFIG_COMPACTION
>   init_waitqueue_head(>kcompactd_wait);
>  #endif
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 2281ad310d06..c93f299fbad7 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1603,16 +1603,16 @@ int isolate_lru_page(struct page *page)
>   * the LRU list will go small and be scanned faster than necessary, leading 
> to
>   * unnecessary swapping, thrashing and OOM.
>   */
> -static int too_many_isolated(struct pglist_data *pgdat, int file,
> +static bool safe_to_isolate(struct pglist_data *pgdat, int file,
>   struct scan_control *sc)

I prefer the current function name.

>  {
>   unsigned long inactive, isolated;
> 
>   if (current_is_kswapd())
> - return 0;
> + return true;
> 
> - if (!sane_reclaim(sc))
> - return 0;
> + if (sane_reclaim(sc))
> + return true;

We only need a one-line change.
> 
>   if (file) {
>   inactive = node_page_state(pgdat, NR_INACTIVE_FILE);
> @@ -1630,7 +1630,7 @@ static int too_many_isolated(struct pglist_data *pgdat, 
> int file,
>   if ((sc->gfp_mask & (__GFP_IO | __GFP_FS)) == (__GFP_IO | __GFP_FS))
>   inactive >>= 

Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone

[Hillf Danton]

On Thursday, January 19, 2017 6:08 PM Mel Gorman wrote: 
> 
> If it's definitely required and is proven to fix the
> infinite-loop-without-oom workload then I'll back off and withdraw my
> objections. However, I'd at least like the following untested patch to
> be considered as an alternative. It has some weaknesses and would be
> slower to OOM than your patch but it avoids reintroducing zone counters
> 
> ---8<---
> mm, vmscan: Wait on a waitqueue when too many pages are isolated
> 
> When too many pages are isolated, direct reclaim waits on congestion to clear
> for up to a tenth of a second. There is no reason to believe that too many
> pages are isolated due to dirty pages, reclaim efficiency or congestion.
> It may simply be because an extremely large number of processes have entered
> direct reclaim at the same time. However, it is possible for the situation
> to persist forever and never reach OOM.
> 
> This patch queues processes a waitqueue when too many pages are isolated.
> When parallel reclaimers finish shrink_page_list, they wake the waiters
> to recheck whether too many pages are isolated.
> 
> The wait on the queue has a timeout as not all sites that isolate pages
> will do the wakeup. Depending on every isolation of LRU pages to be perfect
> forever is potentially fragile. The specific wakeups occur for page reclaim
> and compaction. If too many pages are isolated due to memory failure,
> hotplug or directly calling migration from a syscall then the waiting
> processes may wait the full timeout.
> 
> Note that the timeout allows the use of waitqueue_active() on the basis
> that a race will cause the full timeout to be reached due to a missed
> wakeup. This is relatively harmless and still a massive improvement over
> unconditionally calling congestion_wait.
> 
> Direct reclaimers that cannot isolate pages within the timeout will consider
> return to the caller. This is somewhat clunky as it won't return immediately
> and make go through the other priorities and slab shrinking. Eventually,
> it'll go through a few iterations of should_reclaim_retry and reach the
> MAX_RECLAIM_RETRIES limit and consider going OOM.
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 91f69aa0d581..3dd617d0c8c4 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -628,6 +628,7 @@ typedef struct pglist_data {
>   int node_id;
>   wait_queue_head_t kswapd_wait;
>   wait_queue_head_t pfmemalloc_wait;
> + wait_queue_head_t isolated_wait;
>   struct task_struct *kswapd; /* Protected by
>  mem_hotplug_begin/end() */
>   int kswapd_order;
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 43a6cf1dc202..1b1ff6da7401 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1634,6 +1634,10 @@ static enum compact_result compact_zone(struct zone 
> *zone, struct compact_contro
>   count_compact_events(COMPACTMIGRATE_SCANNED, cc->total_migrate_scanned);
>   count_compact_events(COMPACTFREE_SCANNED, cc->total_free_scanned);
> 
> + /* Page reclaim could have stalled due to isolated pages */
> + if (waitqueue_active(>zone_pgdat->isolated_wait))
> + wake_up(>zone_pgdat->isolated_wait);
> +
>   trace_mm_compaction_end(start_pfn, cc->migrate_pfn,
>   cc->free_pfn, end_pfn, sync, ret);
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 8ff25883c172..d848c9f31bff 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5823,6 +5823,7 @@ static void __paginginit free_area_init_core(struct 
> pglist_data *pgdat)
>  #endif
>   init_waitqueue_head(>kswapd_wait);
>   init_waitqueue_head(>pfmemalloc_wait);
> + init_waitqueue_head(>isolated_wait);
>  #ifdef CONFIG_COMPACTION
>   init_waitqueue_head(>kcompactd_wait);
>  #endif
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 2281ad310d06..c93f299fbad7 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1603,16 +1603,16 @@ int isolate_lru_page(struct page *page)
>   * the LRU list will go small and be scanned faster than necessary, leading 
> to
>   * unnecessary swapping, thrashing and OOM.
>   */
> -static int too_many_isolated(struct pglist_data *pgdat, int file,
> +static bool safe_to_isolate(struct pglist_data *pgdat, int file,
>   struct scan_control *sc)

I prefer the current function name.

>  {
>   unsigned long inactive, isolated;
> 
>   if (current_is_kswapd())
> - return 0;
> + return true;
> 
> - if (!sane_reclaim(sc))
> - return 0;
> + if (sane_reclaim(sc))
> + return true;

We only need a one-line change.
> 
>   if (file) {
>   inactive = node_page_state(pgdat, NR_INACTIVE_FILE);
> @@ -1630,7 +1630,7 @@ static int too_many_isolated(struct pglist_data *pgdat, 
> int file,
>   if ((sc->gfp_mask & (__GFP_IO | __GFP_FS)) == (__GFP_IO | __GFP_FS))
>   inactive >>= 

Re: [PATCH 2/2] pwm: pca9685: fix prescaler initialization

[Thierry Reding]

On Thu, Jan 19, 2017 at 05:52:10PM +0100, Clemens Gruber wrote:
> On Thu, Jan 19, 2017 at 06:10:08PM +0200, Andy Shevchenko wrote:
> > Combining with your proposal I would see the best approach is to set
> > pca->period_ns accordingly to current prescaler value if you want to.
> 
> Yes, I agree.
> 
> > In your patch I see no benefit, since it's quite unlikely user will want
> > to have 5ms period among all possibilities.
> 
> It is the hardware default, but you are right, the user probably does
> not care about that.
> 
> > So, summarize, I prefer (in order of preference from high to low):
> > - enforce default prescaler value based on default period (it's just one
> > line to write a register)
> > - calculate default period based on actual prescaler value
> 
> Let's go with this one. I'll spin up a v2 where I calculate the
> period_ns value from the current prescaler value in the probe function.

This effectively ends up duplicating much of what the atomic API is
supposed to be doing.

So generally before the atomic API there is no way for the PWM driver
(and consequently the PWM users) to know what the current setting is.
That implies that we either can't care about the settings that were
programmed by some bootloader or that we force the PWM to a setting
on ->probe().

The result is inconsistent behaviour across drivers, and that's just
fine for many cases. But for some cases it is really not something that
we can work with.

So perhaps another possibility would be for this driver to implement the
atomic API. This should give you the necessary infrastructure to do
exactly what you want.

> Thierry: I think you could merge v1 of patch 1/2 from my series
> independently.

Okay, will do.

> I'll send v2 of patch 2/2 with aforementioned changes in the next
> days.

Like I said above, I think atomic API conversion wouldn't be very
difficult for this driver and it has the added advantage of giving you
the proper infrastructure to do this rather than having to duplicate
it in the driver.

That would be my preference, but I'm willing to take v2 of 2/2 as well
if it ends up being really nice and compact. =)

Thierry


signature.asc
Description: PGP signature

Re: [PATCH 2/2] pwm: pca9685: fix prescaler initialization

[Thierry Reding]

On Thu, Jan 19, 2017 at 05:52:10PM +0100, Clemens Gruber wrote:
> On Thu, Jan 19, 2017 at 06:10:08PM +0200, Andy Shevchenko wrote:
> > Combining with your proposal I would see the best approach is to set
> > pca->period_ns accordingly to current prescaler value if you want to.
> 
> Yes, I agree.
> 
> > In your patch I see no benefit, since it's quite unlikely user will want
> > to have 5ms period among all possibilities.
> 
> It is the hardware default, but you are right, the user probably does
> not care about that.
> 
> > So, summarize, I prefer (in order of preference from high to low):
> > - enforce default prescaler value based on default period (it's just one
> > line to write a register)
> > - calculate default period based on actual prescaler value
> 
> Let's go with this one. I'll spin up a v2 where I calculate the
> period_ns value from the current prescaler value in the probe function.

This effectively ends up duplicating much of what the atomic API is
supposed to be doing.

So generally before the atomic API there is no way for the PWM driver
(and consequently the PWM users) to know what the current setting is.
That implies that we either can't care about the settings that were
programmed by some bootloader or that we force the PWM to a setting
on ->probe().

The result is inconsistent behaviour across drivers, and that's just
fine for many cases. But for some cases it is really not something that
we can work with.

So perhaps another possibility would be for this driver to implement the
atomic API. This should give you the necessary infrastructure to do
exactly what you want.

> Thierry: I think you could merge v1 of patch 1/2 from my series
> independently.

Okay, will do.

> I'll send v2 of patch 2/2 with aforementioned changes in the next
> days.

Like I said above, I think atomic API conversion wouldn't be very
difficult for this driver and it has the added advantage of giving you
the proper infrastructure to do this rather than having to duplicate
it in the driver.

That would be my preference, but I'm willing to take v2 of 2/2 as well
if it ends up being really nice and compact. =)

Thierry


signature.asc
Description: PGP signature

Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

[Trevor Cordes]

On 2017-01-19 Michal Hocko wrote:
> On Thu 19-01-17 03:48:50, Trevor Cordes wrote:
> > On 2017-01-17 Michal Hocko wrote:  
> > > On Tue 17-01-17 14:21:14, Mel Gorman wrote:  
> > > > On Tue, Jan 17, 2017 at 02:52:28PM +0100, Michal Hocko
> > > > wrote:
> > > > > On Mon 16-01-17 11:09:34, Mel Gorman wrote:
> > > > > [...]
> > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > > > index 532a2a750952..46aac487b89a 100644
> > > > > > --- a/mm/vmscan.c
> > > > > > +++ b/mm/vmscan.c
> > > > > > @@ -2684,6 +2684,7 @@ static void shrink_zones(struct
> > > > > > zonelist *zonelist, struct scan_control *sc) continue;
> > > > > >  
> > > > > > if (sc->priority != DEF_PRIORITY &&
> > > > > > +   !buffer_heads_over_limit &&
> > > > > > !pgdat_reclaimable(zone->zone_pgdat))
> > > > > > continue;   /* Let
> > > > > > kswapd poll it */
> > > > > 
> > > > > I think we should rather remove pgdat_reclaimable here. This
> > > > > sounds like a wrong layer to decide whether we want to reclaim
> > > > > and how much.   
> > > > 
> > > > I had considered that but it'd also be important to add the
> > > > other 32-bit patches you have posted to see the impact. Because
> > > > of the ratio of LRU pages to slab pages, it may not have an
> > > > impact but it'd need to be eliminated.
> > > 
> > > OK, Trevor you can pull from
> > > git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree
> > > fixes/highmem-node-fixes branch. This contains the current mmotm
> > > tree
> > > + the latest highmem fixes. I also do not expect this would help
> > > much in your case but as Mel've said we should rule that out at
> > > least.  
> > 
> > Hi!  The git tree above version oom'd after < 24 hours (3:02am) so
> > it doesn't solve the bug.  If you need a oom messages dump let me
> > know.  
> 
> Yes please.

The first oom from that night attached.  Note, the oom wasn't as dire
with your mhocko/4.9.0+ as it usually is with stock 4.8.x: my oom
detector and reboot script was able to do its thing cleanly before the
system became unusable.

I'll await further instructions and test right away.  Maybe I'll try a
few tuning ideas until then.  Thanks!

> > Let me know what to try next, guys, and I'll test it out.
> >   
> > > > Before prototyping such a thing, I'd like to hear the outcome of
> > > > this heavy hack and then add your 32-bit patches onto the list.
> > > > If the problem is still there then I'd next look at taking slab
> > > > pages into account in pgdat_reclaimable() instead of an
> > > > outright removal that has a much wider impact. If that doesn't
> > > > work then I'll prototype a heavy-handed forced slab reclaim
> > > > when lower zones are almost all slab pages.  
> > 
> > I don't think I've tried the "heavy hack" patch yet?  It's not in
> > the mhocko tree I just tried?  Should I try the heavy hack on top
> > of mhocko git or on vanilla or what?
> > 
> > I also want to mention that these PAE boxes suffer from another
> > problem/bug that I've worked around for almost a year now.  For some
> > reason it keeps gnawing at me that it might be related.  The disk
> > I/O goes to pot on this/these PAE boxes after a certain amount of
> > disk writes (like some unknown number of GB, around 10-ish maybe).
> > Like writes go from 500MB/s to 10MB/s!! Reboot and it's magically
> > 500MB/s again.  I detail this here:
> > https://muug.ca/pipermail/roundtable/2016-June/004669.html
> > My fix was to mem=XG where X is <8 (like 4 or 6) to force the PAE
> > kernel to be more sane about highmem choices.  I never filed a bug
> > because I read a ton of stuff saying Linus hates PAE, don't use over
> > 4G, blah blah.  But the other fix is to:
> > set /proc/sys/vm/highmem_is_dirtyable to 1  
> 
> Yes this sounds like a dirty memory throttling and there were some
> changes in that area. I do not remember when exactly.

I think my PAE-slow-IO bug started way back in Fedora 22 (4.0?), hard
to know exactly when as I didn't discover the bug for maybe a year as I
didn't realize IO was the problem right away.  Too late to bisect that
one, I guess.  I guess it's not related so we can ignore my tangent!

> > I'm not bringing this up to get attention to a new bug, I bring
> > this up because it smells like it might be related.  If something
> > slowly eats away at the box's vm to the point that I/O gets
> > horribly slow, perhaps it's related to the slab and high/lomem
> > issue we have here?  And if related, it may help to solve the oom
> > bug.  If I'm way off base here, just ignore my tangent!  
> 
> >From your OOM reports so far it doesn't really seem related because
> >you  
> never had large number of pages under the writeback when OOM.
> 
> The situation with the PAE kernel is unfortunate but it is really hard
> to do anything about that considering that the kernel and most its
> allocations have to live in a small and scarce lowmem memory. 

Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

[Trevor Cordes]

On 2017-01-19 Michal Hocko wrote:
> On Thu 19-01-17 03:48:50, Trevor Cordes wrote:
> > On 2017-01-17 Michal Hocko wrote:  
> > > On Tue 17-01-17 14:21:14, Mel Gorman wrote:  
> > > > On Tue, Jan 17, 2017 at 02:52:28PM +0100, Michal Hocko
> > > > wrote:
> > > > > On Mon 16-01-17 11:09:34, Mel Gorman wrote:
> > > > > [...]
> > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > > > index 532a2a750952..46aac487b89a 100644
> > > > > > --- a/mm/vmscan.c
> > > > > > +++ b/mm/vmscan.c
> > > > > > @@ -2684,6 +2684,7 @@ static void shrink_zones(struct
> > > > > > zonelist *zonelist, struct scan_control *sc) continue;
> > > > > >  
> > > > > > if (sc->priority != DEF_PRIORITY &&
> > > > > > +   !buffer_heads_over_limit &&
> > > > > > !pgdat_reclaimable(zone->zone_pgdat))
> > > > > > continue;   /* Let
> > > > > > kswapd poll it */
> > > > > 
> > > > > I think we should rather remove pgdat_reclaimable here. This
> > > > > sounds like a wrong layer to decide whether we want to reclaim
> > > > > and how much.   
> > > > 
> > > > I had considered that but it'd also be important to add the
> > > > other 32-bit patches you have posted to see the impact. Because
> > > > of the ratio of LRU pages to slab pages, it may not have an
> > > > impact but it'd need to be eliminated.
> > > 
> > > OK, Trevor you can pull from
> > > git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree
> > > fixes/highmem-node-fixes branch. This contains the current mmotm
> > > tree
> > > + the latest highmem fixes. I also do not expect this would help
> > > much in your case but as Mel've said we should rule that out at
> > > least.  
> > 
> > Hi!  The git tree above version oom'd after < 24 hours (3:02am) so
> > it doesn't solve the bug.  If you need a oom messages dump let me
> > know.  
> 
> Yes please.

The first oom from that night attached.  Note, the oom wasn't as dire
with your mhocko/4.9.0+ as it usually is with stock 4.8.x: my oom
detector and reboot script was able to do its thing cleanly before the
system became unusable.

I'll await further instructions and test right away.  Maybe I'll try a
few tuning ideas until then.  Thanks!

> > Let me know what to try next, guys, and I'll test it out.
> >   
> > > > Before prototyping such a thing, I'd like to hear the outcome of
> > > > this heavy hack and then add your 32-bit patches onto the list.
> > > > If the problem is still there then I'd next look at taking slab
> > > > pages into account in pgdat_reclaimable() instead of an
> > > > outright removal that has a much wider impact. If that doesn't
> > > > work then I'll prototype a heavy-handed forced slab reclaim
> > > > when lower zones are almost all slab pages.  
> > 
> > I don't think I've tried the "heavy hack" patch yet?  It's not in
> > the mhocko tree I just tried?  Should I try the heavy hack on top
> > of mhocko git or on vanilla or what?
> > 
> > I also want to mention that these PAE boxes suffer from another
> > problem/bug that I've worked around for almost a year now.  For some
> > reason it keeps gnawing at me that it might be related.  The disk
> > I/O goes to pot on this/these PAE boxes after a certain amount of
> > disk writes (like some unknown number of GB, around 10-ish maybe).
> > Like writes go from 500MB/s to 10MB/s!! Reboot and it's magically
> > 500MB/s again.  I detail this here:
> > https://muug.ca/pipermail/roundtable/2016-June/004669.html
> > My fix was to mem=XG where X is <8 (like 4 or 6) to force the PAE
> > kernel to be more sane about highmem choices.  I never filed a bug
> > because I read a ton of stuff saying Linus hates PAE, don't use over
> > 4G, blah blah.  But the other fix is to:
> > set /proc/sys/vm/highmem_is_dirtyable to 1  
> 
> Yes this sounds like a dirty memory throttling and there were some
> changes in that area. I do not remember when exactly.

I think my PAE-slow-IO bug started way back in Fedora 22 (4.0?), hard
to know exactly when as I didn't discover the bug for maybe a year as I
didn't realize IO was the problem right away.  Too late to bisect that
one, I guess.  I guess it's not related so we can ignore my tangent!

> > I'm not bringing this up to get attention to a new bug, I bring
> > this up because it smells like it might be related.  If something
> > slowly eats away at the box's vm to the point that I/O gets
> > horribly slow, perhaps it's related to the slab and high/lomem
> > issue we have here?  And if related, it may help to solve the oom
> > bug.  If I'm way off base here, just ignore my tangent!  
> 
> >From your OOM reports so far it doesn't really seem related because
> >you  
> never had large number of pages under the writeback when OOM.
> 
> The situation with the PAE kernel is unfortunate but it is really hard
> to do anything about that considering that the kernel and most its
> allocations have to live in a small and scarce lowmem memory. 

[PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

[Jason Wang]

Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
fixing this by adding a hint (has_data_valid) and set it only on the
receiving path.

Cc: Rolf Neugebauer 
Signed-off-by: Jason Wang 
---
 drivers/net/macvtap.c  | 2 +-
 drivers/net/tun.c  | 2 +-
 drivers/net/virtio_net.c   | 2 +-
 include/linux/virtio_net.h | 6 +-
 net/packet/af_packet.c | 4 ++--
 5 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 5c26653..4026185 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -825,7 +825,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
return -EINVAL;
 
if (virtio_net_hdr_from_skb(skb, _hdr,
-   macvtap_is_little_endian(q)))
+   macvtap_is_little_endian(q), true))
BUG();
 
if (copy_to_iter(_hdr, sizeof(vnet_hdr), iter) !=
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index cd8e02c..2cd10b2 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1360,7 +1360,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
return -EINVAL;
 
if (virtio_net_hdr_from_skb(skb, ,
-   tun_is_little_endian(tun))) {
+   tun_is_little_endian(tun), true)) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
pr_err("unexpected GSO type: "
   "0x%x, gso_size %d, hdr_len %d\n",
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4a10500..3474243 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1104,7 +1104,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff 
*skb)
hdr = skb_vnet_hdr(skb);
 
if (virtio_net_hdr_from_skb(skb, >hdr,
-   virtio_is_little_endian(vi->vdev)))
+   virtio_is_little_endian(vi->vdev), false))
BUG();
 
if (vi->mergeable_rx_bufs)
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 5643647..5209b5e 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -56,7 +56,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
 
 static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
  struct virtio_net_hdr *hdr,
- bool little_endian)
+ bool little_endian,
+ bool has_data_valid)
 {
memset(hdr, 0, sizeof(*hdr));   /* no info leak */
 
@@ -91,6 +92,9 @@ static inline int virtio_net_hdr_from_skb(const struct 
sk_buff *skb,
skb_checksum_start_offset(skb));
hdr->csum_offset = __cpu_to_virtio16(little_endian,
skb->csum_offset);
+   } else if (has_data_valid &&
+  skb->ip_summed == CHECKSUM_UNNECESSARY) {
+   hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
 
return 0;
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index b9e1a13..3d555c7 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1976,7 +1976,7 @@ static int packet_rcv_vnet(struct msghdr *msg, const 
struct sk_buff *skb,
return -EINVAL;
*len -= sizeof(vnet_hdr);
 
-   if (virtio_net_hdr_from_skb(skb, _hdr, vio_le()))
+   if (virtio_net_hdr_from_skb(skb, _hdr, vio_le(), true))
return -EINVAL;
 
return memcpy_to_msg(msg, (void *)_hdr, sizeof(vnet_hdr));
@@ -2237,7 +2237,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct 
net_device *dev,
if (po->has_vnet_hdr) {
if (virtio_net_hdr_from_skb(skb, h.raw + macoff -
sizeof(struct virtio_net_hdr),
-   vio_le())) {
+   vio_le(), true)) {
spin_lock(>sk_receive_queue.lock);
goto drop_n_account;
}
-- 
2.7.4

[PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

[Jason Wang]

Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
fixing this by adding a hint (has_data_valid) and set it only on the
receiving path.

Cc: Rolf Neugebauer 
Signed-off-by: Jason Wang 
---
 drivers/net/macvtap.c  | 2 +-
 drivers/net/tun.c  | 2 +-
 drivers/net/virtio_net.c   | 2 +-
 include/linux/virtio_net.h | 6 +-
 net/packet/af_packet.c | 4 ++--
 5 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 5c26653..4026185 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -825,7 +825,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
return -EINVAL;
 
if (virtio_net_hdr_from_skb(skb, _hdr,
-   macvtap_is_little_endian(q)))
+   macvtap_is_little_endian(q), true))
BUG();
 
if (copy_to_iter(_hdr, sizeof(vnet_hdr), iter) !=
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index cd8e02c..2cd10b2 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1360,7 +1360,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
return -EINVAL;
 
if (virtio_net_hdr_from_skb(skb, ,
-   tun_is_little_endian(tun))) {
+   tun_is_little_endian(tun), true)) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
pr_err("unexpected GSO type: "
   "0x%x, gso_size %d, hdr_len %d\n",
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4a10500..3474243 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1104,7 +1104,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff 
*skb)
hdr = skb_vnet_hdr(skb);
 
if (virtio_net_hdr_from_skb(skb, >hdr,
-   virtio_is_little_endian(vi->vdev)))
+   virtio_is_little_endian(vi->vdev), false))
BUG();
 
if (vi->mergeable_rx_bufs)
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 5643647..5209b5e 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -56,7 +56,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
 
 static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
  struct virtio_net_hdr *hdr,
- bool little_endian)
+ bool little_endian,
+ bool has_data_valid)
 {
memset(hdr, 0, sizeof(*hdr));   /* no info leak */
 
@@ -91,6 +92,9 @@ static inline int virtio_net_hdr_from_skb(const struct 
sk_buff *skb,
skb_checksum_start_offset(skb));
hdr->csum_offset = __cpu_to_virtio16(little_endian,
skb->csum_offset);
+   } else if (has_data_valid &&
+  skb->ip_summed == CHECKSUM_UNNECESSARY) {
+   hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
} /* else everything is zero */
 
return 0;
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index b9e1a13..3d555c7 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1976,7 +1976,7 @@ static int packet_rcv_vnet(struct msghdr *msg, const 
struct sk_buff *skb,
return -EINVAL;
*len -= sizeof(vnet_hdr);
 
-   if (virtio_net_hdr_from_skb(skb, _hdr, vio_le()))
+   if (virtio_net_hdr_from_skb(skb, _hdr, vio_le(), true))
return -EINVAL;
 
return memcpy_to_msg(msg, (void *)_hdr, sizeof(vnet_hdr));
@@ -2237,7 +2237,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct 
net_device *dev,
if (po->has_vnet_hdr) {
if (virtio_net_hdr_from_skb(skb, h.raw + macoff -
sizeof(struct virtio_net_hdr),
-   vio_le())) {
+   vio_le(), true)) {
spin_lock(>sk_receive_queue.lock);
goto drop_n_account;
}
-- 
2.7.4

RE: [PATCH net] r8152: fix the rx doesn't work

[Hayes Wang]

> Subject: [PATCH net] r8152: fix the rx doesn't work
> 
> The rtl8152_post_reset() doesn't submit the rx urb, so the rx wouldn't work.
> 
> Signed-off-by: Hayes Wang 

Excuse me. Please ignore this patch. I would submit another one.

RE: [PATCH net] r8152: fix the rx doesn't work

[Hayes Wang]

> Subject: [PATCH net] r8152: fix the rx doesn't work
> 
> The rtl8152_post_reset() doesn't submit the rx urb, so the rx wouldn't work.
> 
> Signed-off-by: Hayes Wang 

Excuse me. Please ignore this patch. I would submit another one.

Re: [RESEND RFC 3/3] mmc: sdhci: Add more debug info in case of data error

[Ritesh Harjani]

Hi Adrian,

Thanks for reviewing.

On 1/19/2017 5:24 PM, Adrian Hunter wrote:

On 10/01/17 08:41, Ritesh Harjani wrote:

print error log message and dump sdhc registers for debugging
purpose in case of data errors (except when tuning commands
generate CRC/timeout/end bit errors).


It is a bit ugly and probably only useful during driver development, so I am
not at all enthusiastic about this.
Ok, since this patch was anyway for debugging, I will drop this patch 
for now. I will revisit in case if the need really arises, since this 
could be useful in debugging data txfr error and avoid re-test cycle to 
get sdhci register dumps.




Also,
Do you think we should have this below change added? Could you please 
give your thoughts on this. Jeremy and I feel that even below info can 
be helpful along with sdhci_dumpregs -
He requested me to take below diff as another patch in my next revision 
of this series which he has submitted here -


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


diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 71654b9..5911f98 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -47,6 +47,27 @@  static void sdhci_finish_data(struct sdhci_host *);

 static void sdhci_enable_preset_value(struct sdhci_host *host, bool 
enable);


+static void sdhci_dump_rpm_info(struct sdhci_host *host)
+{
+   struct mmc_host *mmc = host->mmc;
+
+	pr_info("%s: 
rpmstatus[pltfm](runtime-suspend:usage_count:disable_depth)(%d:%d:%d)\n",

+   mmc_hostname(mmc), mmc->parent->power.runtime_status,
+   atomic_read(>parent->power.usage_count),
+   mmc->parent->power.disable_depth);
+}
+
+
+static void sdhci_dump_state(struct sdhci_host *host)
+{
+   struct mmc_host *mmc = host->mmc;
+
+   pr_info("%s: clk: %d claimer: %s pwr: %d\n",
+   mmc_hostname(mmc), host->clock,
+   mmc->claimer->comm, host->pwr);
+   sdhci_dump_rpm_info(host);
+}
+
 static void sdhci_dumpregs(struct sdhci_host *host)
 {
pr_err(DRIVER_NAME ": === REGISTER DUMP (%s)===\n",
@@ -100,6 +121,10 @@  static void sdhci_dumpregs(struct sdhci_host *host)
   readl(host->ioaddr + SDHCI_ADMA_ADDRESS));
}

+   if (host->ops->dump_vendor_regs)
+   host->ops->dump_vendor_regs(host);
+
+   sdhci_dump_state(host);
pr_err(DRIVER_NAME ": ===\n");
 }

Regards
Ritesh





Signed-off-by: Ritesh Harjani 
Signed-off-by: Asutosh Das 
---
 drivers/mmc/host/sdhci.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 73a8918..2e51e49 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2616,9 +2616,26 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 
intmask)
host->ops->adma_workaround(host, intmask);
}

-   if (host->data->error)
+   if (host->data->error) {
+   bool pr_msg = true;
+
+   if (intmask & (SDHCI_INT_DATA_CRC | SDHCI_INT_DATA_TIMEOUT |
+   SDHCI_INT_DATA_END_BIT)) {
+   command = SDHCI_GET_CMD(sdhci_readw(host,
+   SDHCI_COMMAND));
+   if (command == MMC_SEND_TUNING_BLOCK_HS200 ||
+   command == MMC_SEND_TUNING_BLOCK)
+   pr_msg = false;
+   }
+   if (pr_msg) {
+   pr_err("%s: data txfr (0x%08x) error: %d\n",
+  mmc_hostname(host->mmc), intmask,
+  host->data->error);
+   sdhci_dumpregs(host);
+   }
+
sdhci_finish_data(host);
-   else {
+   } else {
if (intmask & (SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL))
sdhci_transfer_pio(host);






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

Re: [RESEND RFC 3/3] mmc: sdhci: Add more debug info in case of data error

[Ritesh Harjani]

Hi Adrian,

Thanks for reviewing.

On 1/19/2017 5:24 PM, Adrian Hunter wrote:

On 10/01/17 08:41, Ritesh Harjani wrote:

print error log message and dump sdhc registers for debugging
purpose in case of data errors (except when tuning commands
generate CRC/timeout/end bit errors).


It is a bit ugly and probably only useful during driver development, so I am
not at all enthusiastic about this.
Ok, since this patch was anyway for debugging, I will drop this patch 
for now. I will revisit in case if the need really arises, since this 
could be useful in debugging data txfr error and avoid re-test cycle to 
get sdhci register dumps.




Also,
Do you think we should have this below change added? Could you please 
give your thoughts on this. Jeremy and I feel that even below info can 
be helpful along with sdhci_dumpregs -
He requested me to take below diff as another patch in my next revision 
of this series which he has submitted here -


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


diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 71654b9..5911f98 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -47,6 +47,27 @@  static void sdhci_finish_data(struct sdhci_host *);

 static void sdhci_enable_preset_value(struct sdhci_host *host, bool 
enable);


+static void sdhci_dump_rpm_info(struct sdhci_host *host)
+{
+   struct mmc_host *mmc = host->mmc;
+
+	pr_info("%s: 
rpmstatus[pltfm](runtime-suspend:usage_count:disable_depth)(%d:%d:%d)\n",

+   mmc_hostname(mmc), mmc->parent->power.runtime_status,
+   atomic_read(>parent->power.usage_count),
+   mmc->parent->power.disable_depth);
+}
+
+
+static void sdhci_dump_state(struct sdhci_host *host)
+{
+   struct mmc_host *mmc = host->mmc;
+
+   pr_info("%s: clk: %d claimer: %s pwr: %d\n",
+   mmc_hostname(mmc), host->clock,
+   mmc->claimer->comm, host->pwr);
+   sdhci_dump_rpm_info(host);
+}
+
 static void sdhci_dumpregs(struct sdhci_host *host)
 {
pr_err(DRIVER_NAME ": === REGISTER DUMP (%s)===\n",
@@ -100,6 +121,10 @@  static void sdhci_dumpregs(struct sdhci_host *host)
   readl(host->ioaddr + SDHCI_ADMA_ADDRESS));
}

+   if (host->ops->dump_vendor_regs)
+   host->ops->dump_vendor_regs(host);
+
+   sdhci_dump_state(host);
pr_err(DRIVER_NAME ": ===\n");
 }

Regards
Ritesh





Signed-off-by: Ritesh Harjani 
Signed-off-by: Asutosh Das 
---
 drivers/mmc/host/sdhci.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 73a8918..2e51e49 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2616,9 +2616,26 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 
intmask)
host->ops->adma_workaround(host, intmask);
}

-   if (host->data->error)
+   if (host->data->error) {
+   bool pr_msg = true;
+
+   if (intmask & (SDHCI_INT_DATA_CRC | SDHCI_INT_DATA_TIMEOUT |
+   SDHCI_INT_DATA_END_BIT)) {
+   command = SDHCI_GET_CMD(sdhci_readw(host,
+   SDHCI_COMMAND));
+   if (command == MMC_SEND_TUNING_BLOCK_HS200 ||
+   command == MMC_SEND_TUNING_BLOCK)
+   pr_msg = false;
+   }
+   if (pr_msg) {
+   pr_err("%s: data txfr (0x%08x) error: %d\n",
+  mmc_hostname(host->mmc), intmask,
+  host->data->error);
+   sdhci_dumpregs(host);
+   }
+
sdhci_finish_data(host);
-   else {
+   } else {
if (intmask & (SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL))
sdhci_transfer_pio(host);






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

Re: [PATCH] procfs: change the owner of non-dumpable and writeable files

[Eric W. Biederman]

The patch under discussion just appears wrong.  Part of what we are
detecting when we ask if a task is dumpable is if a process might have
under gone a security transition.  If a process has undergone a security
transition (calling setuid or the like) it is quite possible that
everyone with it's current effective credentials should not be able
to access that process.

Please verify but the ptrace issue that allowed processes in a container
to call setns on our processes should be fixed as of 4.10-rc1.  And the
change has been marked for backporting.

AKA it should be this fix that removes the need for your dumpable setting.
Fixes: bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace 
permission checks")

Now with that said I believe we want to add the following change now
that dumpable is user namespace relative.  That will use not the
GLOBAL_ROOT_UID/GID but instead uid and gid 0 in the namespace
that dumpable is relative too.

But ugh!  Your case is even more confused that I had first noticed.
Saying that a processes is undumpable is completely unnecessary
when you are entering into a new fresh user namespace.  Touching
setgroups at any point where there are other processes in the namespace
makes no sense whatsoever.  Clearing dumpable is to help not leak things
into a container when you call setns on a user namespace.

So my general impression of your use case is don't do that, it isn't
necessary and it causes you problems.

At the same time here is what I am looking at to better set the uids and
gids of proc files.

From: "Eric W. Biederman" 
Date: Tue, 3 Jan 2017 10:23:11 +1300
Subject: [PATCH] proc: Better ownership of files for non-dumpable tasks in user 
namespaces

Instead of making the files owned by the GLOBAL_ROOT_USER.  Make
non-dumpable files whose mm has always lived in a user namespace owned
by the user namespace root.  This allows the container root to have
things work as expected in a container.

Signed-off-by: "Eric W. Biederman" 
---
 fs/proc/base.c | 88 +++---
 fs/proc/fd.c   | 12 +---
 fs/proc/internal.h | 16 ++
 3 files changed, 53 insertions(+), 63 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 8e7e61b28f31..e96487af2307 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1667,12 +1667,55 @@ const struct inode_operations 
proc_pid_link_inode_operations = {
 
 /* building an inode */
 
+void task_dump_owner(struct task_struct *task, mode_t mode,
+kuid_t *ruid, kgid_t *rgid)
+{
+   /* Depending on the state of dumpable compute who should own a
+* proc file for a task.
+*/
+   const struct cred *cred;
+   kuid_t uid;
+   kgid_t gid;
+
+   /* Default to the tasks effective ownership */
+   rcu_read_lock();
+   cred = __task_cred(task);
+   uid = cred->euid;
+   gid = cred->egid;
+   rcu_read_unlock();
+
+   if (mode != (S_IFDIR|S_IRUGO|S_IXUGO)) {
+   struct mm_struct *mm;
+   task_lock(task);
+   mm = task->mm;
+   /* Make non-dumpable tasks owned by some root */
+   if (mm) {
+   if (get_dumpable(mm) != SUID_DUMP_USER) {
+   struct user_namespace *user_ns = mm->user_ns;
+
+   uid = make_kuid(user_ns, 0);
+   if (!uid_valid(uid))
+   uid = GLOBAL_ROOT_UID;
+
+   gid = make_kgid(user_ns, 0);
+   if (!gid_valid(gid))
+   gid = GLOBAL_ROOT_GID;
+   }
+   } else {
+   uid = GLOBAL_ROOT_UID;
+   gid = GLOBAL_ROOT_GID;
+   }
+   task_unlock(task);
+   }
+   *ruid = uid;
+   *rgid = gid;
+}
+
 struct inode *proc_pid_make_inode(struct super_block * sb,
  struct task_struct *task, umode_t mode)
 {
struct inode * inode;
struct proc_inode *ei;
-   const struct cred *cred;
 
/* We need a new inode */
 
@@ -1694,13 +1737,7 @@ struct inode *proc_pid_make_inode(struct super_block * 
sb,
if (!ei->pid)
goto out_unlock;
 
-   if (task_dumpable(task)) {
-   rcu_read_lock();
-   cred = __task_cred(task);
-   inode->i_uid = cred->euid;
-   inode->i_gid = cred->egid;
-   rcu_read_unlock();
-   }
+   task_dump_owner(task, 0, >i_uid, >i_gid);
security_task_to_inode(task, inode);
 
 out:
@@ -1715,7 +1752,6 @@ int pid_getattr(struct vfsmount *mnt, struct dentry 
*dentry, struct kstat *stat)
 {
struct inode *inode = d_inode(dentry);
struct task_struct *task;
-   const struct cred *cred;
struct pid_namespace 

Re: [PATCH] procfs: change the owner of non-dumpable and writeable files

[Eric W. Biederman]

The patch under discussion just appears wrong.  Part of what we are
detecting when we ask if a task is dumpable is if a process might have
under gone a security transition.  If a process has undergone a security
transition (calling setuid or the like) it is quite possible that
everyone with it's current effective credentials should not be able
to access that process.

Please verify but the ptrace issue that allowed processes in a container
to call setns on our processes should be fixed as of 4.10-rc1.  And the
change has been marked for backporting.

AKA it should be this fix that removes the need for your dumpable setting.
Fixes: bfedb589252c ("mm: Add a user_ns owner to mm_struct and fix ptrace 
permission checks")

Now with that said I believe we want to add the following change now
that dumpable is user namespace relative.  That will use not the
GLOBAL_ROOT_UID/GID but instead uid and gid 0 in the namespace
that dumpable is relative too.

But ugh!  Your case is even more confused that I had first noticed.
Saying that a processes is undumpable is completely unnecessary
when you are entering into a new fresh user namespace.  Touching
setgroups at any point where there are other processes in the namespace
makes no sense whatsoever.  Clearing dumpable is to help not leak things
into a container when you call setns on a user namespace.

So my general impression of your use case is don't do that, it isn't
necessary and it causes you problems.

At the same time here is what I am looking at to better set the uids and
gids of proc files.

From: "Eric W. Biederman" 
Date: Tue, 3 Jan 2017 10:23:11 +1300
Subject: [PATCH] proc: Better ownership of files for non-dumpable tasks in user 
namespaces

Instead of making the files owned by the GLOBAL_ROOT_USER.  Make
non-dumpable files whose mm has always lived in a user namespace owned
by the user namespace root.  This allows the container root to have
things work as expected in a container.

Signed-off-by: "Eric W. Biederman" 
---
 fs/proc/base.c | 88 +++---
 fs/proc/fd.c   | 12 +---
 fs/proc/internal.h | 16 ++
 3 files changed, 53 insertions(+), 63 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 8e7e61b28f31..e96487af2307 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1667,12 +1667,55 @@ const struct inode_operations 
proc_pid_link_inode_operations = {
 
 /* building an inode */
 
+void task_dump_owner(struct task_struct *task, mode_t mode,
+kuid_t *ruid, kgid_t *rgid)
+{
+   /* Depending on the state of dumpable compute who should own a
+* proc file for a task.
+*/
+   const struct cred *cred;
+   kuid_t uid;
+   kgid_t gid;
+
+   /* Default to the tasks effective ownership */
+   rcu_read_lock();
+   cred = __task_cred(task);
+   uid = cred->euid;
+   gid = cred->egid;
+   rcu_read_unlock();
+
+   if (mode != (S_IFDIR|S_IRUGO|S_IXUGO)) {
+   struct mm_struct *mm;
+   task_lock(task);
+   mm = task->mm;
+   /* Make non-dumpable tasks owned by some root */
+   if (mm) {
+   if (get_dumpable(mm) != SUID_DUMP_USER) {
+   struct user_namespace *user_ns = mm->user_ns;
+
+   uid = make_kuid(user_ns, 0);
+   if (!uid_valid(uid))
+   uid = GLOBAL_ROOT_UID;
+
+   gid = make_kgid(user_ns, 0);
+   if (!gid_valid(gid))
+   gid = GLOBAL_ROOT_GID;
+   }
+   } else {
+   uid = GLOBAL_ROOT_UID;
+   gid = GLOBAL_ROOT_GID;
+   }
+   task_unlock(task);
+   }
+   *ruid = uid;
+   *rgid = gid;
+}
+
 struct inode *proc_pid_make_inode(struct super_block * sb,
  struct task_struct *task, umode_t mode)
 {
struct inode * inode;
struct proc_inode *ei;
-   const struct cred *cred;
 
/* We need a new inode */
 
@@ -1694,13 +1737,7 @@ struct inode *proc_pid_make_inode(struct super_block * 
sb,
if (!ei->pid)
goto out_unlock;
 
-   if (task_dumpable(task)) {
-   rcu_read_lock();
-   cred = __task_cred(task);
-   inode->i_uid = cred->euid;
-   inode->i_gid = cred->egid;
-   rcu_read_unlock();
-   }
+   task_dump_owner(task, 0, >i_uid, >i_gid);
security_task_to_inode(task, inode);
 
 out:
@@ -1715,7 +1752,6 @@ int pid_getattr(struct vfsmount *mnt, struct dentry 
*dentry, struct kstat *stat)
 {
struct inode *inode = d_inode(dentry);
struct task_struct *task;
-   const struct cred *cred;
struct pid_namespace *pid = dentry->d_sb->s_fs_info;
 

Re: [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"

[Jaehoon Chung]

Hi,

On 01/17/2017 10:38 PM, Romain Perier wrote:
> Hi,
> 
> In my case I can reproduce the issue on the rock2 and the firefly-rk3288. A 
> workaround is to
> 
> comment the line ".pm = <_ops_foo>" .

Sorry for late. I'm checking runtime PM for this. 
After that, i will decide whether revert or not.

Best Regards,
Jaehoon Chung

> 
> Thanks,
> Romain
> 
> 
> Le 17/01/2017 à 14:28, Romain Perier a écrit :
>> Hello,
>>
>> This commit also breaks reboot and poweroff (the pmic no longer turn the 
>> power supply off), see below:
>>
>> # poweroff
>> # Stopping network: ifdown: interface lo not configured
>> OK
>> Saving random seed... done.
>> Stopping logging: OK
>> umount: devtmpfs busy - remounted read-only
>> The system is going down NOW!
>> Sent SIGTERM to all processes
>> Sent SIGKILL to all processes
>> Requesting system poweroff
>> [  243.673159] INFO: task init:168 blocked for more than 120 seconds.
>> [  243.701298]   Not tainted 4.10.0-rc4-13066-gc10b6c6 #108
>> [  243.728802] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
>> this message.
>> [  243.758948] initD0   168  1 0x
>> [  243.786412] [] (__schedule) from [] 
>> (schedule+0x44/0x9c)
>> [  243.815411] [] (schedule) from [] 
>> (schedule_timeout+0x1d8/0x220)
>> [  243.845267] [] (schedule_timeout) from [] 
>> (wait_for_common+0xa4/0x168)
>> [  243.876105] [] (wait_for_common) from [] 
>> (mmc_wait_for_req_done+0x8c/0x110)
>> [  243.907150] [] (mmc_wait_for_req_done) from [] 
>> (mmc_wait_for_cmd+0x58/0x78)
>> [  243.937855] [] (mmc_wait_for_cmd) from [] 
>> (__mmc_switch+0xbc/0x34c)
>> [  243.967791] [] (__mmc_switch) from [] 
>> (mmc_switch+0x28/0x30)
>> [  243.997029] [] (mmc_switch) from [] 
>> (mmc_flush_cache+0x54/0x80)
>> [  244.026955] [] (mmc_flush_cache) from [] 
>> (_mmc_suspend+0x40/0x268)
>> [  244.057529] [] (_mmc_suspend) from [] 
>> (mmc_bus_shutdown+0x40/0x64)
>> [  244.088412] [] (mmc_bus_shutdown) from [] 
>> (device_shutdown+0x144/0x1d8)
>> [  244.120015] [] (device_shutdown) from [] 
>> (kernel_power_off+0x34/0x70)
>> [  244.151235] [] (kernel_power_off) from [] 
>> (SyS_reboot+0x15c/0x1d0)
>> [  244.182037] [] (SyS_reboot) from [] 
>> (ret_fast_syscall+0x0/0x3c)
>> [  366.553025] INFO: task init:168 blocked for more than 120 seconds.
>> [  366.583187]   Not tainted 4.10.0-rc4-13066-gc10b6c6 #108
>> [  366.613053] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
>> this message.
>>
>>
>>
>> Reverting this commit solves the issue.
>>
>> Regards,
>> Romain
>>
>>
>> 2016-12-30 3:50 GMT+01:00 Jaehoon Chung > >:
>>
>> On 12/30/2016 11:44 AM, Randy Li wrote:
>> >
>> >
>> > On 12/30/2016 10:35 AM, Jaehoon Chung wrote:
>> >> On 12/30/2016 12:07 AM, ayaka wrote:
>> >>>
>> >>>
>> >>> On 12/29/2016 10:04 PM, Jaehoon Chung wrote:
>>  Hi,
>> 
>>  On 12/29/2016 09:55 PM, ayaka wrote:
>> > [5.849733] rk_gmac-dwmac ff29.ethernet (unnamed
>> net_device) (uninitialized): Enable RX Mitigation via HW Watchdog
>> Timer
>> > [5.944512] mmc_host mmc1: Bus speed (slot 0) =
>> 5000Hz (slot req 5000Hz, actual 5000HZ div = 0)
>> > [5.958249] mmc1: new ultra high speed DDR50 SDIO card at
>> address 0001
>> > [6.294548] dwmmc_rockchip ff0f.dwmmc: Successfully
>> tuned phase to 177
>> > [6.301591] mmc2: new HS200 MMC card at address 0001
>> > [6.306758] mmc_host mmc0: Bus speed (slot 0) = 30Hz
>> (slot req 30Hz, actual 30HZ div = 0)
>> > [6.316830] mmcblk2: mmc2:0001 AGND3R 14.6 GiB
>> > [6.321881] mmcblk2boot0: mmc2:0001 AGND3R partition 1
>> 4.00 MiB
>> > [6.328331] mmcblk2boot1: mmc2:0001 AGND3R partition 2
>> 4.00 MiB
>> > [6.334792] mmcblk2rpmb: mmc2:0001 AGND3R partition 3
>> 4.00 MiB
>> > [6.344295]  mmcblk2: p1 p2 p3 p4 p5 p6 p7
>> > [6.469892] mmc_host mmc0: Bus speed (slot 0) = 20Hz
>> (slot req 20Hz, actual 20HZ div = 0)
>> > [6.621888] mmc_host mmc0: Bus speed (slot 0) = 187500Hz
>> (slot req 10Hz, actual 93750HZ div = 1)
>> > [6.917883] libphy: stmmac: probed
>> > [6.921319] rk_gmac-dwmac ff29.ethernet eth0: PHY ID
>> 001cc915 at 0 IRQ POLL (stmmac-0:00) active
>> > [6.930476] rk_gmac-dwmac ff29.ethernet eth0: PHY ID
>> 001cc915 at 2 IRQ POLL (stmmac-0:02)
>> > [6.939757] input: gpio-keys as
>> /devices/platform/gpio-keys/input/input0
>> > [6.946937] rtc-hym8563 0-0051: no valid clock/calendar
>> values available
>> > [6.953694] rtc-hym8563 0-0051: hctosys: unable to read
>> the hardware clock
>> > [6.961262] vcc_sd: disabling
>> > [6.964275] dovdd_1v8: disabling
>> > [6.967527] dvdd_1v2: 

Re: [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"

[Jaehoon Chung]

Hi,

On 01/17/2017 10:38 PM, Romain Perier wrote:
> Hi,
> 
> In my case I can reproduce the issue on the rock2 and the firefly-rk3288. A 
> workaround is to
> 
> comment the line ".pm = <_ops_foo>" .

Sorry for late. I'm checking runtime PM for this. 
After that, i will decide whether revert or not.

Best Regards,
Jaehoon Chung

> 
> Thanks,
> Romain
> 
> 
> Le 17/01/2017 à 14:28, Romain Perier a écrit :
>> Hello,
>>
>> This commit also breaks reboot and poweroff (the pmic no longer turn the 
>> power supply off), see below:
>>
>> # poweroff
>> # Stopping network: ifdown: interface lo not configured
>> OK
>> Saving random seed... done.
>> Stopping logging: OK
>> umount: devtmpfs busy - remounted read-only
>> The system is going down NOW!
>> Sent SIGTERM to all processes
>> Sent SIGKILL to all processes
>> Requesting system poweroff
>> [  243.673159] INFO: task init:168 blocked for more than 120 seconds.
>> [  243.701298]   Not tainted 4.10.0-rc4-13066-gc10b6c6 #108
>> [  243.728802] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
>> this message.
>> [  243.758948] initD0   168  1 0x
>> [  243.786412] [] (__schedule) from [] 
>> (schedule+0x44/0x9c)
>> [  243.815411] [] (schedule) from [] 
>> (schedule_timeout+0x1d8/0x220)
>> [  243.845267] [] (schedule_timeout) from [] 
>> (wait_for_common+0xa4/0x168)
>> [  243.876105] [] (wait_for_common) from [] 
>> (mmc_wait_for_req_done+0x8c/0x110)
>> [  243.907150] [] (mmc_wait_for_req_done) from [] 
>> (mmc_wait_for_cmd+0x58/0x78)
>> [  243.937855] [] (mmc_wait_for_cmd) from [] 
>> (__mmc_switch+0xbc/0x34c)
>> [  243.967791] [] (__mmc_switch) from [] 
>> (mmc_switch+0x28/0x30)
>> [  243.997029] [] (mmc_switch) from [] 
>> (mmc_flush_cache+0x54/0x80)
>> [  244.026955] [] (mmc_flush_cache) from [] 
>> (_mmc_suspend+0x40/0x268)
>> [  244.057529] [] (_mmc_suspend) from [] 
>> (mmc_bus_shutdown+0x40/0x64)
>> [  244.088412] [] (mmc_bus_shutdown) from [] 
>> (device_shutdown+0x144/0x1d8)
>> [  244.120015] [] (device_shutdown) from [] 
>> (kernel_power_off+0x34/0x70)
>> [  244.151235] [] (kernel_power_off) from [] 
>> (SyS_reboot+0x15c/0x1d0)
>> [  244.182037] [] (SyS_reboot) from [] 
>> (ret_fast_syscall+0x0/0x3c)
>> [  366.553025] INFO: task init:168 blocked for more than 120 seconds.
>> [  366.583187]   Not tainted 4.10.0-rc4-13066-gc10b6c6 #108
>> [  366.613053] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
>> this message.
>>
>>
>>
>> Reverting this commit solves the issue.
>>
>> Regards,
>> Romain
>>
>>
>> 2016-12-30 3:50 GMT+01:00 Jaehoon Chung > >:
>>
>> On 12/30/2016 11:44 AM, Randy Li wrote:
>> >
>> >
>> > On 12/30/2016 10:35 AM, Jaehoon Chung wrote:
>> >> On 12/30/2016 12:07 AM, ayaka wrote:
>> >>>
>> >>>
>> >>> On 12/29/2016 10:04 PM, Jaehoon Chung wrote:
>>  Hi,
>> 
>>  On 12/29/2016 09:55 PM, ayaka wrote:
>> > [5.849733] rk_gmac-dwmac ff29.ethernet (unnamed
>> net_device) (uninitialized): Enable RX Mitigation via HW Watchdog
>> Timer
>> > [5.944512] mmc_host mmc1: Bus speed (slot 0) =
>> 5000Hz (slot req 5000Hz, actual 5000HZ div = 0)
>> > [5.958249] mmc1: new ultra high speed DDR50 SDIO card at
>> address 0001
>> > [6.294548] dwmmc_rockchip ff0f.dwmmc: Successfully
>> tuned phase to 177
>> > [6.301591] mmc2: new HS200 MMC card at address 0001
>> > [6.306758] mmc_host mmc0: Bus speed (slot 0) = 30Hz
>> (slot req 30Hz, actual 30HZ div = 0)
>> > [6.316830] mmcblk2: mmc2:0001 AGND3R 14.6 GiB
>> > [6.321881] mmcblk2boot0: mmc2:0001 AGND3R partition 1
>> 4.00 MiB
>> > [6.328331] mmcblk2boot1: mmc2:0001 AGND3R partition 2
>> 4.00 MiB
>> > [6.334792] mmcblk2rpmb: mmc2:0001 AGND3R partition 3
>> 4.00 MiB
>> > [6.344295]  mmcblk2: p1 p2 p3 p4 p5 p6 p7
>> > [6.469892] mmc_host mmc0: Bus speed (slot 0) = 20Hz
>> (slot req 20Hz, actual 20HZ div = 0)
>> > [6.621888] mmc_host mmc0: Bus speed (slot 0) = 187500Hz
>> (slot req 10Hz, actual 93750HZ div = 1)
>> > [6.917883] libphy: stmmac: probed
>> > [6.921319] rk_gmac-dwmac ff29.ethernet eth0: PHY ID
>> 001cc915 at 0 IRQ POLL (stmmac-0:00) active
>> > [6.930476] rk_gmac-dwmac ff29.ethernet eth0: PHY ID
>> 001cc915 at 2 IRQ POLL (stmmac-0:02)
>> > [6.939757] input: gpio-keys as
>> /devices/platform/gpio-keys/input/input0
>> > [6.946937] rtc-hym8563 0-0051: no valid clock/calendar
>> values available
>> > [6.953694] rtc-hym8563 0-0051: hctosys: unable to read
>> the hardware clock
>> > [6.961262] vcc_sd: disabling
>> > [6.964275] dovdd_1v8: disabling
>> > [6.967527] dvdd_1v2: disabling
>> > [

Re: [PATCH v2 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family

[Shawn Guo]

On Thu, Jan 19, 2017 at 09:59:52AM +0800, Baoyou Xie wrote:
> This patch adds watchdog controller driver for ZTE's zx2967 family.
> 
> Signed-off-by: Baoyou Xie 
> ---
>  drivers/watchdog/Kconfig  |  10 ++
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/zx2967_wdt.c | 383 
> ++
>  3 files changed, 394 insertions(+)
>  create mode 100644 drivers/watchdog/zx2967_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index acb00b5..05093a2 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -714,6 +714,16 @@ config ASPEED_WATCHDOG
> To compile this driver as a module, choose M here: the
> module will be called aspeed_wdt.
>  
> +config ZX2967_WATCHDOG
> + tristate "ZTE zx2967 SoCs watchdog support"
> + depends on ARCH_ZX
> + select WATCHDOG_CORE
> + help
> +   Say Y here to include support for the watchdog timer
> +   in ZTE zx2967 SoCs.
> +   To compile this driver as a module, choose M here: the
> +   module will be called zx2967_wdt.
> +
>  # AVR32 Architecture
>  
>  config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 0c3d35e..bf2d296 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -82,6 +82,7 @@ obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
>  obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
>  obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
>  obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
> +obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
>  
>  # AVR32 Architecture
>  obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/zx2967_wdt.c b/drivers/watchdog/zx2967_wdt.c
> new file mode 100644
> index 000..35eaecd
> --- /dev/null
> +++ b/drivers/watchdog/zx2967_wdt.c
> @@ -0,0 +1,383 @@
> +/*
> + * watchdog driver for ZTE's zx2967 family
> + *
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie 
> + *
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ZX2967_WDT_CFG_REG   0x4
> +#define ZX2967_WDT_LOAD_REG  0x8
> +#define ZX2967_WDT_REFRESH_REG   0x18
> +#define ZX2967_WDT_START_REG 0x1c
> +
> +#define ZX2967_WDT_REFRESH_MASK  0x3f
> +
> +#define ZX2967_WDT_CFG_DIV(n)n) & 0xff) - 1) << 
> 8)
> +#define ZX2967_WDT_START_EN  0x1
> +
> +#define ZX2967_WDT_WRITEKEY  0x1234
> +
> +#define ZX2967_WDT_DIV_DEFAULT   16
> +#define ZX2967_WDT_DEFAULT_TIMEOUT   32
> +#define ZX2967_WDT_MIN_TIMEOUT   1
> +#define ZX2967_WDT_MAX_TIMEOUT   500
> +#define ZX2967_WDT_MAX_COUNT 0x
> +
> +#define ZX2967_WDT_FLAG_REBOOT_MON   (1 << 0)
> +
> +#define ZX2967_RESET_MASK_REG0xb0
> +
> +struct zx2967_wdt {
> + struct device   *dev;
> + struct clk  *clock;
> + void __iomem*reg_base;
> + unsigned intconf;
> + unsigned intload;
> + unsigned intflags;
> + struct watchdog_device  wdt_device;
> + struct notifier_block   restart_handler;
> + struct notifier_block   reboot_handler;
> +};
> +
> +#define zx2967_wdt_read_reg(r)  readl_relaxed(r)
> +
> +static inline void
> +zx2967_wdt_write_reg(u32 val, void __iomem *addr)
> +{
> + writel_relaxed(val | ZX2967_WDT_WRITEKEY, addr);
> +}

static inline u32 zx2967_wdt_readl(struct zx2967_wdt *wdt, u16 reg)
{
return readl_relaxed(wdt->reg_base + reg);
}

static inline void zx2967_wdt_writel(struct zx2967_wdt *wdt, u16 reg, u32 val)
{
writel_relaxed(val | ZX2967_WDT_WRITEKEY, wdt->reg_base + reg);
}

This is what I would suggest to make the caller a bit easier.  Anyway,
it's just a suggestion, not a strong opinion.

> +
> +static void zx2967_wdt_refresh(struct zx2967_wdt *wdt)
> +{
> + u32 val;
> +
> + val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_REFRESH_REG);
> + val ^= ZX2967_WDT_REFRESH_MASK;
> + zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_REFRESH_REG);
> +}
> +
> +static unsigned int
> +__zx2967_wdt_set_timeout(struct zx2967_wdt *wdt, unsigned int timeout)
> +{
> + unsigned int freq = clk_get_rate(wdt->clock);
> + unsigned int divisor = ZX2967_WDT_DIV_DEFAULT;
> + unsigned int count;
> +
> + count = timeout * freq;
> + if (count > divisor * ZX2967_WDT_MAX_COUNT)
> + divisor = DIV_ROUND_UP(count, ZX2967_WDT_MAX_COUNT);
> + count = DIV_ROUND_UP(count, divisor);
> + zx2967_wdt_write_reg(ZX2967_WDT_CFG_DIV(divisor),
> + 

Re: [PATCH v2 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family

[Shawn Guo]

On Thu, Jan 19, 2017 at 09:59:52AM +0800, Baoyou Xie wrote:
> This patch adds watchdog controller driver for ZTE's zx2967 family.
> 
> Signed-off-by: Baoyou Xie 
> ---
>  drivers/watchdog/Kconfig  |  10 ++
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/zx2967_wdt.c | 383 
> ++
>  3 files changed, 394 insertions(+)
>  create mode 100644 drivers/watchdog/zx2967_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index acb00b5..05093a2 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -714,6 +714,16 @@ config ASPEED_WATCHDOG
> To compile this driver as a module, choose M here: the
> module will be called aspeed_wdt.
>  
> +config ZX2967_WATCHDOG
> + tristate "ZTE zx2967 SoCs watchdog support"
> + depends on ARCH_ZX
> + select WATCHDOG_CORE
> + help
> +   Say Y here to include support for the watchdog timer
> +   in ZTE zx2967 SoCs.
> +   To compile this driver as a module, choose M here: the
> +   module will be called zx2967_wdt.
> +
>  # AVR32 Architecture
>  
>  config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 0c3d35e..bf2d296 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -82,6 +82,7 @@ obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
>  obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
>  obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
>  obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
> +obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
>  
>  # AVR32 Architecture
>  obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/zx2967_wdt.c b/drivers/watchdog/zx2967_wdt.c
> new file mode 100644
> index 000..35eaecd
> --- /dev/null
> +++ b/drivers/watchdog/zx2967_wdt.c
> @@ -0,0 +1,383 @@
> +/*
> + * watchdog driver for ZTE's zx2967 family
> + *
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie 
> + *
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ZX2967_WDT_CFG_REG   0x4
> +#define ZX2967_WDT_LOAD_REG  0x8
> +#define ZX2967_WDT_REFRESH_REG   0x18
> +#define ZX2967_WDT_START_REG 0x1c
> +
> +#define ZX2967_WDT_REFRESH_MASK  0x3f
> +
> +#define ZX2967_WDT_CFG_DIV(n)n) & 0xff) - 1) << 
> 8)
> +#define ZX2967_WDT_START_EN  0x1
> +
> +#define ZX2967_WDT_WRITEKEY  0x1234
> +
> +#define ZX2967_WDT_DIV_DEFAULT   16
> +#define ZX2967_WDT_DEFAULT_TIMEOUT   32
> +#define ZX2967_WDT_MIN_TIMEOUT   1
> +#define ZX2967_WDT_MAX_TIMEOUT   500
> +#define ZX2967_WDT_MAX_COUNT 0x
> +
> +#define ZX2967_WDT_FLAG_REBOOT_MON   (1 << 0)
> +
> +#define ZX2967_RESET_MASK_REG0xb0
> +
> +struct zx2967_wdt {
> + struct device   *dev;
> + struct clk  *clock;
> + void __iomem*reg_base;
> + unsigned intconf;
> + unsigned intload;
> + unsigned intflags;
> + struct watchdog_device  wdt_device;
> + struct notifier_block   restart_handler;
> + struct notifier_block   reboot_handler;
> +};
> +
> +#define zx2967_wdt_read_reg(r)  readl_relaxed(r)
> +
> +static inline void
> +zx2967_wdt_write_reg(u32 val, void __iomem *addr)
> +{
> + writel_relaxed(val | ZX2967_WDT_WRITEKEY, addr);
> +}

static inline u32 zx2967_wdt_readl(struct zx2967_wdt *wdt, u16 reg)
{
return readl_relaxed(wdt->reg_base + reg);
}

static inline void zx2967_wdt_writel(struct zx2967_wdt *wdt, u16 reg, u32 val)
{
writel_relaxed(val | ZX2967_WDT_WRITEKEY, wdt->reg_base + reg);
}

This is what I would suggest to make the caller a bit easier.  Anyway,
it's just a suggestion, not a strong opinion.

> +
> +static void zx2967_wdt_refresh(struct zx2967_wdt *wdt)
> +{
> + u32 val;
> +
> + val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_REFRESH_REG);
> + val ^= ZX2967_WDT_REFRESH_MASK;
> + zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_REFRESH_REG);
> +}
> +
> +static unsigned int
> +__zx2967_wdt_set_timeout(struct zx2967_wdt *wdt, unsigned int timeout)
> +{
> + unsigned int freq = clk_get_rate(wdt->clock);
> + unsigned int divisor = ZX2967_WDT_DIV_DEFAULT;
> + unsigned int count;
> +
> + count = timeout * freq;
> + if (count > divisor * ZX2967_WDT_MAX_COUNT)
> + divisor = DIV_ROUND_UP(count, ZX2967_WDT_MAX_COUNT);
> + count = DIV_ROUND_UP(count, divisor);
> + zx2967_wdt_write_reg(ZX2967_WDT_CFG_DIV(divisor),
> +  wdt->reg_base + ZX2967_WDT_CFG_REG);
> + 

[PATCH net] r8152: fix the rx doesn't work

[Hayes Wang]

The rtl8152_post_reset() doesn't submit the rx urb, so the rx wouldn't work.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3b48ad..e8f4f88 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3545,6 +3545,7 @@ static int rtl8152_post_reset(struct usb_interface *intf)
if (netif_carrier_ok(netdev)) {
mutex_lock(>control);
tp->rtl_ops.enable(tp);
+   rtl_start_rx(tp);
rtl8152_set_rx_mode(netdev);
mutex_unlock(>control);
netif_wake_queue(netdev);
-- 
2.7.4

[PATCH net] r8152: fix the rx doesn't work

[Hayes Wang]

The rtl8152_post_reset() doesn't submit the rx urb, so the rx wouldn't work.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3b48ad..e8f4f88 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3545,6 +3545,7 @@ static int rtl8152_post_reset(struct usb_interface *intf)
if (netif_carrier_ok(netdev)) {
mutex_lock(>control);
tp->rtl_ops.enable(tp);
+   rtl_start_rx(tp);
rtl8152_set_rx_mode(netdev);
mutex_unlock(>control);
netif_wake_queue(netdev);
-- 
2.7.4

Re: [RESEND RFC 1/3] mmc: sdhci: Add platform_dumpregs callback support to sdhci_ops.

[Ritesh Harjani]

On 1/19/2017 4:13 PM, Adrian Hunter wrote:

On 18/01/17 09:57, Ritesh Harjani wrote:

Hi Shawn,

On 1/10/2017 2:45 PM, Shawn Lin wrote:

On 2017/1/10 14:41, Ritesh Harjani wrote:

From: Sahitya Tummala 

Add new host operation ->platform_dumpregs to provide a
mechanism through which host drivers can dump platform
specific registers in addition to SDHC registers
during error conditions.



Although we have been preventing from adding new callback
for sdhci core, this one makes sense as there are more and more
vendor registers outside the scope of SDHCI spec.


We are not prevented from adding new callbacks, but they have to represent
logical functions not quirks.

This patch seems fine to me except the name "platform_dumpregs" because

I took platform prefix similar to platform_execute_tuning.



"platform" doesn't mean "platform" here.  Just plain "dumpregs" is better.

Sure, I will only keep "dumpregs" in next revision.



--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



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

Re: [RESEND RFC 1/3] mmc: sdhci: Add platform_dumpregs callback support to sdhci_ops.

[Ritesh Harjani]

On 1/19/2017 4:13 PM, Adrian Hunter wrote:

On 18/01/17 09:57, Ritesh Harjani wrote:

Hi Shawn,

On 1/10/2017 2:45 PM, Shawn Lin wrote:

On 2017/1/10 14:41, Ritesh Harjani wrote:

From: Sahitya Tummala 

Add new host operation ->platform_dumpregs to provide a
mechanism through which host drivers can dump platform
specific registers in addition to SDHC registers
during error conditions.



Although we have been preventing from adding new callback
for sdhci core, this one makes sense as there are more and more
vendor registers outside the scope of SDHCI spec.


We are not prevented from adding new callbacks, but they have to represent
logical functions not quirks.

This patch seems fine to me except the name "platform_dumpregs" because

I took platform prefix similar to platform_execute_tuning.



"platform" doesn't mean "platform" here.  Just plain "dumpregs" is better.

Sure, I will only keep "dumpregs" in next revision.



--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



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

Re: [RESEND RFC 2/3] mmc: sdhci-msm: Implement platform_dumpregs callback in sdhci-msm

[Ritesh Harjani]

Hi Adrian,

On 1/19/2017 4:25 PM, Adrian Hunter wrote:

On 10/01/17 08:41, Ritesh Harjani wrote:

From: Sahitya Tummala 

Implement ->platform_dumpregs host operation to print the
platform specific registers in addition to standard SDHC
register during error conditions.


You could add an example of the prints so we can see it looks nice.
Sure. Below is an example, taken during bootup. That's why you see all 
registers as 0.


http://pastebin.com/7j94punq





Signed-off-by: Sahitya Tummala 
Signed-off-by: Ritesh Harjani 
---
 drivers/mmc/host/sdhci-msm.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 32879b8..1241dbd 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -29,6 +29,11 @@
 #define CORE_VERSION_MAJOR_MASK(0xf << 
CORE_VERSION_MAJOR_SHIFT)
 #define CORE_VERSION_MINOR_MASK0xff

+#define CORE_MCI_DATA_CNT  0x30
+#define CORE_MCI_STATUS0x34
+#define CORE_MCI_FIFO_CNT  0x44
+#define CORE_MCI_STATUS2   0x6c
+
 #define CORE_HC_MODE   0x78
 #define HC_MODE_EN 0x1
 #define CORE_POWER 0x0
@@ -77,6 +82,10 @@
 #define CORE_HC_SELECT_IN_HS400(6 << 19)
 #define CORE_HC_SELECT_IN_MASK (7 << 19)

+#define CORE_VENDOR_SPEC_FUNC2 0x110
+#define CORE_VENDOR_SPEC_ADMA_ERR_ADDR00x114
+#define CORE_VENDOR_SPEC_ADMA_ERR_ADDR10x118
+
 #define CORE_CSR_CDC_CTLR_CFG0 0x130
 #define CORE_SW_TRIG_FULL_CALIBBIT(16)
 #define CORE_HW_AUTOCAL_ENABIT(17)
@@ -658,6 +667,30 @@ static int sdhci_msm_hs400_dll_calibration(struct 
sdhci_host *host)
return ret;
 }

+static void sdhci_msm_dumpregs(struct sdhci_host *host)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+
+   pr_err("--- PLATFORM REGISTER DUMP ---\n");


"PLATFORM" isn't right here.  It should be something that identifies the IP
/ driver. e.g. "SDHCI MSM"

Sure.




+
+   pr_err("Data cnt: 0x%08x | Fifo cnt: 0x%08x | Int sts: 0x%08x | Int sts2: 
0x%08x\n",


What sdhci_dumpregs() should do is prefix the message with the host name i.e.


I feel it may be redundant info. As all sdhci-msm register dump with 
come with mmc0/mmc1 prefixed with it.
Instead I see sdhci_dumpregs already adds hostname in the starting 
header of register dump. So this may not be required I guess.

I have added an example dumpregs (http://pastebin.com/7j94punq).

Please let me know if you still think otherwise.

Regards
Ritesh




pr_err("%s: sdhci: Sys addr: 0x%08x | Version:  0x%08x\n",
   sdhci_readl(host, SDHCI_DMA_ADDRESS),
   sdhci_readw(host, SDHCI_HOST_VERSION),
   mmc_hostname(host->mmc));

And then we should do that here too.


+  readl_relaxed(msm_host->core_mem + CORE_MCI_DATA_CNT),
+  readl_relaxed(msm_host->core_mem + CORE_MCI_FIFO_CNT),
+  readl_relaxed(msm_host->core_mem + CORE_MCI_STATUS),
+  readl_relaxed(msm_host->core_mem + CORE_MCI_STATUS2));
+   pr_err("DLL cfg:  0x%08x | DLL sts:  0x%08x | SDCC ver: 0x%08x\n",
+  readl_relaxed(host->ioaddr + CORE_DLL_CONFIG),
+  readl_relaxed(host->ioaddr + CORE_DLL_STATUS),
+  readl_relaxed(msm_host->core_mem + CORE_MCI_VERSION));
+   pr_err("Vndr func: 0x%08x | Vndr adma err : addr0: 0x%08x addr1: 
0x%08x\n",
+  readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC),
+  readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC_ADMA_ERR_ADDR0),
+  readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC_ADMA_ERR_ADDR1));
+   pr_err("Vndr func2: 0x%08x\n",
+  readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC_FUNC2));
+}
+
 static int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode)
 {
int tuning_seq_cnt = 3;
@@ -1035,6 +1068,7 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
.set_bus_width = sdhci_set_bus_width,
.set_uhs_signaling = sdhci_msm_set_uhs_signaling,
.voltage_switch = sdhci_msm_voltage_switch,
+   .platform_dumpregs = sdhci_msm_dumpregs,
 };

 static const struct sdhci_pltfm_data sdhci_msm_pdata = {



--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



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

Re: [RESEND RFC 2/3] mmc: sdhci-msm: Implement platform_dumpregs callback in sdhci-msm

[Ritesh Harjani]

Hi Adrian,

On 1/19/2017 4:25 PM, Adrian Hunter wrote:

On 10/01/17 08:41, Ritesh Harjani wrote:

From: Sahitya Tummala 

Implement ->platform_dumpregs host operation to print the
platform specific registers in addition to standard SDHC
register during error conditions.


You could add an example of the prints so we can see it looks nice.
Sure. Below is an example, taken during bootup. That's why you see all 
registers as 0.


http://pastebin.com/7j94punq





Signed-off-by: Sahitya Tummala 
Signed-off-by: Ritesh Harjani 
---
 drivers/mmc/host/sdhci-msm.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 32879b8..1241dbd 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -29,6 +29,11 @@
 #define CORE_VERSION_MAJOR_MASK(0xf << 
CORE_VERSION_MAJOR_SHIFT)
 #define CORE_VERSION_MINOR_MASK0xff

+#define CORE_MCI_DATA_CNT  0x30
+#define CORE_MCI_STATUS0x34
+#define CORE_MCI_FIFO_CNT  0x44
+#define CORE_MCI_STATUS2   0x6c
+
 #define CORE_HC_MODE   0x78
 #define HC_MODE_EN 0x1
 #define CORE_POWER 0x0
@@ -77,6 +82,10 @@
 #define CORE_HC_SELECT_IN_HS400(6 << 19)
 #define CORE_HC_SELECT_IN_MASK (7 << 19)

+#define CORE_VENDOR_SPEC_FUNC2 0x110
+#define CORE_VENDOR_SPEC_ADMA_ERR_ADDR00x114
+#define CORE_VENDOR_SPEC_ADMA_ERR_ADDR10x118
+
 #define CORE_CSR_CDC_CTLR_CFG0 0x130
 #define CORE_SW_TRIG_FULL_CALIBBIT(16)
 #define CORE_HW_AUTOCAL_ENABIT(17)
@@ -658,6 +667,30 @@ static int sdhci_msm_hs400_dll_calibration(struct 
sdhci_host *host)
return ret;
 }

+static void sdhci_msm_dumpregs(struct sdhci_host *host)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+
+   pr_err("--- PLATFORM REGISTER DUMP ---\n");


"PLATFORM" isn't right here.  It should be something that identifies the IP
/ driver. e.g. "SDHCI MSM"

Sure.




+
+   pr_err("Data cnt: 0x%08x | Fifo cnt: 0x%08x | Int sts: 0x%08x | Int sts2: 
0x%08x\n",


What sdhci_dumpregs() should do is prefix the message with the host name i.e.


I feel it may be redundant info. As all sdhci-msm register dump with 
come with mmc0/mmc1 prefixed with it.
Instead I see sdhci_dumpregs already adds hostname in the starting 
header of register dump. So this may not be required I guess.

I have added an example dumpregs (http://pastebin.com/7j94punq).

Please let me know if you still think otherwise.

Regards
Ritesh




pr_err("%s: sdhci: Sys addr: 0x%08x | Version:  0x%08x\n",
   sdhci_readl(host, SDHCI_DMA_ADDRESS),
   sdhci_readw(host, SDHCI_HOST_VERSION),
   mmc_hostname(host->mmc));

And then we should do that here too.


+  readl_relaxed(msm_host->core_mem + CORE_MCI_DATA_CNT),
+  readl_relaxed(msm_host->core_mem + CORE_MCI_FIFO_CNT),
+  readl_relaxed(msm_host->core_mem + CORE_MCI_STATUS),
+  readl_relaxed(msm_host->core_mem + CORE_MCI_STATUS2));
+   pr_err("DLL cfg:  0x%08x | DLL sts:  0x%08x | SDCC ver: 0x%08x\n",
+  readl_relaxed(host->ioaddr + CORE_DLL_CONFIG),
+  readl_relaxed(host->ioaddr + CORE_DLL_STATUS),
+  readl_relaxed(msm_host->core_mem + CORE_MCI_VERSION));
+   pr_err("Vndr func: 0x%08x | Vndr adma err : addr0: 0x%08x addr1: 
0x%08x\n",
+  readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC),
+  readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC_ADMA_ERR_ADDR0),
+  readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC_ADMA_ERR_ADDR1));
+   pr_err("Vndr func2: 0x%08x\n",
+  readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC_FUNC2));
+}
+
 static int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode)
 {
int tuning_seq_cnt = 3;
@@ -1035,6 +1068,7 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
.set_bus_width = sdhci_set_bus_width,
.set_uhs_signaling = sdhci_msm_set_uhs_signaling,
.voltage_switch = sdhci_msm_voltage_switch,
+   .platform_dumpregs = sdhci_msm_dumpregs,
 };

 static const struct sdhci_pltfm_data sdhci_msm_pdata = {



--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



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

Re: [PATCH v4 2/5] ia64: reuse append_elf_note() and final_note() functions

[Michael Ellerman]

Hari Bathini  writes:

> Get rid of multiple definitions of append_elf_note() & final_note()
> functions. Reuse these functions compiled under CONFIG_CRASH_CORE
> Also, define Elf_Word and use it instead of generic u32 or the more
> specific Elf64_Word.
>
> Signed-off-by: Hari Bathini 
> ---
>
> Changes from v3:
> * Dropped hard-coded values and used DIV_ROUND_UP().
>
> Changes from v2:
> * Added a definition for Elf_Word.
> * Used IA64 version of append_elf_note() and final_note() functions.
>
>
>  arch/ia64/kernel/crash.c   |   22 --
>  include/linux/crash_core.h |4 
>  include/linux/elf.h|2 ++
>  kernel/crash_core.c|   34 ++
>  kernel/kexec_core.c|   28 
>  5 files changed, 20 insertions(+), 70 deletions(-)

Do the powerpc patches later in the series actually depend on this one?
Or is this just an unrelated cleanup?

As it is I can't merge the series until we at least get an ack on this
from the ia64 folks.

If you can just split this out as a separate patch that would make it a
lot easier to get the rest merged.

cheers

Re: [PATCH v4 2/5] ia64: reuse append_elf_note() and final_note() functions

[Michael Ellerman]

Hari Bathini  writes:

> Get rid of multiple definitions of append_elf_note() & final_note()
> functions. Reuse these functions compiled under CONFIG_CRASH_CORE
> Also, define Elf_Word and use it instead of generic u32 or the more
> specific Elf64_Word.
>
> Signed-off-by: Hari Bathini 
> ---
>
> Changes from v3:
> * Dropped hard-coded values and used DIV_ROUND_UP().
>
> Changes from v2:
> * Added a definition for Elf_Word.
> * Used IA64 version of append_elf_note() and final_note() functions.
>
>
>  arch/ia64/kernel/crash.c   |   22 --
>  include/linux/crash_core.h |4 
>  include/linux/elf.h|2 ++
>  kernel/crash_core.c|   34 ++
>  kernel/kexec_core.c|   28 
>  5 files changed, 20 insertions(+), 70 deletions(-)

Do the powerpc patches later in the series actually depend on this one?
Or is this just an unrelated cleanup?

As it is I can't merge the series until we at least get an ack on this
from the ia64 folks.

If you can just split this out as a separate patch that would make it a
lot easier to get the rest merged.

cheers

Re: [PATCH 2/2] security: Change name of CONFIG_DEBUG_SET_MODULE_RONX

[kbuild test robot]

Hi Laura,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc4]
[cannot apply to next-20170119]
[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/Laura-Abbott/Better-hardening-names/20170119-200343
config: i386-randconfig-c0-01201130 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/built-in.o: In function `ftrace_arch_code_modify_prepare':
>> (.text+0x3fcb7): undefined reference to `set_all_modules_text_rw'
   arch/x86/built-in.o: In function `ftrace_arch_code_modify_post_process':
>> (.text+0x3fcc3): undefined reference to `set_all_modules_text_ro'

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


.config.gz
Description: application/gzip

Re: [PATCH 2/2] security: Change name of CONFIG_DEBUG_SET_MODULE_RONX

[kbuild test robot]

Hi Laura,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc4]
[cannot apply to next-20170119]
[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/Laura-Abbott/Better-hardening-names/20170119-200343
config: i386-randconfig-c0-01201130 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/built-in.o: In function `ftrace_arch_code_modify_prepare':
>> (.text+0x3fcb7): undefined reference to `set_all_modules_text_rw'
   arch/x86/built-in.o: In function `ftrace_arch_code_modify_post_process':
>> (.text+0x3fcc3): undefined reference to `set_all_modules_text_ro'

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


.config.gz
Description: application/gzip