Re: linux-next: build failure after merge of the clk tree

[Olof Johansson]

On Mon, Jul 27, 2015 at 02:11:17PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the clk tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> drivers/clk/ti/clk-814x.c:11:25: error: array type has incomplete element type
>  static struct ti_dt_clk dm814_clks[] = {
>  ^
> drivers/clk/ti/clk-814x.c:12:2: error: implicit declaration of function 
> 'DT_CLK' [-Werror=implicit-function-declaration]
>   DT_CLK(NULL, "devosc_ck", "devosc_ck"),
>   ^
> drivers/clk/ti/clk-814x.c:21:2: error: field name not in record or union 
> initializer
>   { .node_name = NULL },
>   ^
> drivers/clk/ti/clk-814x.c:21:2: error: (near initialization for 'dm814_clks')
> drivers/clk/ti/clk-814x.c: In function 'dm814x_dt_clk_init':
> drivers/clk/ti/clk-814x.c:26:2: error: implicit declaration of function 
> 'ti_dt_clocks_register' [-Werror=implicit-function-declaration]
>   ti_dt_clocks_register(dm814_clks);
>   ^
> drivers/clk/ti/clk-814x.c:28:2: error: implicit declaration of function 
> 'omap2_clk_enable_init_clocks' [-Werror=implicit-function-declaration]
>   omap2_clk_enable_init_clocks(NULL, 0);
>   ^
> drivers/clk/ti/clk-814x.c: At top level:
> drivers/clk/ti/clk-814x.c:11:25: warning: 'dm814_clks' defined but not used 
> [-Wunused-variable]
>  static struct ti_dt_clk dm814_clks[] = {
>  ^
> 
> Caused by commit
> 
>   9cf705de06a2 ("ARM: OMAP2+: Add support for initializing dm814x clocks")
> 
> from the omap tree interacting with commit
> 
>   a3314e9cf69c ("clk: ti: move some public definitions to private header")
> 
> from the clk tree.
> 
> I have applied the following merge fix patch:
> 
> From: Stephen Rothwell 
> Date: Mon, 27 Jul 2015 14:07:23 +1000
> Subject: [PATCH] clk: ti: fix for definition movement
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/clk/ti/clk-814x.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
> index d490d427cc20..e172920798ea 100644
> --- a/drivers/clk/ti/clk-814x.c
> +++ b/drivers/clk/ti/clk-814x.c
> @@ -8,6 +8,8 @@
>  #include 
>  #include 
>  
> +#include "clock.h"
> +
>  static struct ti_dt_clk dm814_clks[] = {
>   DT_CLK(NULL, "devosc_ck", "devosc_ck"),
>   DT_CLK(NULL, "mpu_ck", "mpu_ck"),

Thanks, I've now applied this to the same branch where 9cf705de06a2 was merged.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 12/14] arm64: Check for selected granule support

[Steve Capper]

On 13 August 2015 at 12:34, Suzuki K. Poulose  wrote:
> From: "Suzuki K. Poulose" 
>
> Ensure that the selected page size is supported by the
> CPU(s).
>
> Cc: Mark Rutland 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Signed-off-by: Suzuki K. Poulose 
> ---
>  arch/arm64/include/asm/sysreg.h |6 ++
>  arch/arm64/kernel/head.S|   24 +++-
>  2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index a7f3d4b..e01d323 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -87,4 +87,10 @@ static inline void config_sctlr_el1(u32 clear, u32 set)
>  }
>  #endif
>
> +#define ID_AA64MMFR0_TGran4_SHIFT  28
> +#define ID_AA64MMFR0_TGran64_SHIFT 24
> +
> +#define ID_AA64MMFR0_TGran4_ENABLED0x0
> +#define ID_AA64MMFR0_TGran64_ENABLED   0x0
> +
>  #endif /* __ASM_SYSREG_H */
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 01b8e58..0cb04db 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -31,10 +31,11 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>
>  #define __PHYS_OFFSET  (KERNEL_START - TEXT_OFFSET)
> @@ -606,9 +607,25 @@ ENDPROC(__secondary_switched)
>   *  x27 = *virtual* address to jump to upon completion
>   *
>   * other registers depend on the function called upon completion
> + * Checks if the selected granule size is supported by the CPU.
>   */
> +#ifdefined(CONFIG_ARM64_64K_PAGES)
> +
> +#define ID_AA64MMFR0_TGran_SHIFT   ID_AA64MMFR0_TGran64_SHIFT
> +#define ID_AA64MMFR0_TGran_ENABLED ID_AA64MMFR0_TGran64_ENABLED
> +
> +#else
> +
> +#define ID_AA64MMFR0_TGran_SHIFT   ID_AA64MMFR0_TGran4_SHIFT
> +#define ID_AA64MMFR0_TGran_ENABLED ID_AA64MMFR0_TGran4_ENABLED
> +
> +#endif
> .section".idmap.text", "ax"
>  __enable_mmu:
> +   mrs x1, ID_AA64MMFR0_EL1
> +   ubfxx2, x1, #ID_AA64MMFR0_TGran_SHIFT, 4
> +   cmp x2, #ID_AA64MMFR0_TGran_ENABLED
> +   b.ne__no_granule_support
> ldr x5, =vectors
> msr vbar_el1, x5
> msr ttbr0_el1, x25  // load TTBR0
> @@ -626,3 +643,8 @@ __enable_mmu:
> isb
> br  x27
>  ENDPROC(__enable_mmu)
> +
> +__no_granule_support:
> +   wfe
> +   b __no_granule_support
> +ENDPROC(__no_granule_support)
> --
> 1.7.9.5
>

Hi Suzuki,
Is is possible to tell the user that the kernel has failed to boot due
to the kernel granule being unsupported?

Cheers,
--
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ath9k: match wait_for_completion_timeout return type

[Kalle Valo]

> Return type of wait_for_completion_timeout is unsigned long not int.
> As time_left is exclusively used for wait_for_completion_timeout here its
> type is simply changed to unsigned long.
> 
> API conformance testing for completions with coccinelle spatches are being
> used to locate API usage inconsistencies:
> ./drivers/net/wireless/ath/ath9k/link.c:197
> int return assigned to unsigned long
> 
> Patch was compile tested with x86_64_defconfig + CONFIG_ATH_CARDS=m,
> 
> Patch is against 4.1-rc3 (localversion-next is -next-20150514)
> 
> Signed-off-by: Nicholas Mc Guire 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ath9k_htc: wmi: match wait_for_completion_timeout return type

[Kalle Valo]

> Return type of wait_for_completion_timeout is unsigned long not int.
> As time_left is exclusively used for wait_for_completion_timeout here its
> type is simply changed to unsigned long.
> 
> API conformance testing for completions with coccinelle spatches are being
> used to locate API usage inconsistencies:
> ./drivers/net/wireless/ath/ath9k/wmi.c:331
>   int return assigned to unsigned long
> 
> Patch was compile tested with x86_64_defconfig + CONFIG_ATH_CARDS=m,
> CONFIG_ATH9K_HTC=m
> 
> Patch is against 4.1-rc3 (localversion-next is -next-20150514)
> 
> Signed-off-by: Nicholas Mc Guire 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ath9k_htc: drv_init: match wait_for_completion_timeout return type

[Kalle Valo]

> Return type of wait_for_completion_timeout is unsigned long not int.
> As time_left is exclusively used for wait_for_completion_timeout here its
> type is simply changed to unsigned long.
> 
> API conformance testing for completions with coccinelle spatches are being
> used to locate API usage inconsistencies:
> ./drivers/net/wireless/ath/ath9k/htc_drv_init.c:81
>   int return assigned to unsigned long
> 
> Patch was compile tested with x86_64_defconfig + CONFIG_ATH_CARDS=m,
> CONFIG_ATH9K_HTC=m
> 
> Patch is against 4.1-rc3 (localversion-next is -next-20150514)
> 
> Signed-off-by: Nicholas Mc Guire 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] pinctrl: baytrail: Serialize all register access

[Linus Walleij]

On Tue, Aug 4, 2015 at 2:03 PM, Mika Westerberg
 wrote:

> There is a hardware issue in Intel Baytrail where concurrent GPIO register
> access might result reads of 0x and writes might get dropped
> completely.
>
> Prevent this from happening by taking the serializing lock in all places
> where it is possible that more than one thread might be accessing the
> hardware concurrently.
>
> Signed-off-by: Mika Westerberg 

Patch applied.

Same comment here about the fastpath and the RT raw spinlocks.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] pinctrl: baytrail: Drop FSF mailing address

[Linus Walleij]

On Tue, Aug 4, 2015 at 2:03 PM, Mika Westerberg
 wrote:

> The FSF address is already mentioned in the COPYING file. No need to
> duplicate that information to individual files.
>
> Signed-off-by: Mika Westerberg 

Patch applied.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ath9k_htc: match wait_for_completion_timeout return type

[Kalle Valo]

> Return type of wait_for_completion_timeout is unsigned long not int.
> As time_left is exclusively used for wait_for_completion_timeout here its
> type is simply changed to unsigned long.
> 
> API conformance testing for completions with coccinelle spatches are being
> used to locate API usage inconsistencies:
> ./drivers/net/wireless/ath/ath9k/htc_hst.c:171
>   int return assigned to unsigned long
> ./drivers/net/wireless/ath/ath9k/htc_hst.c:277
>   int return assigned to unsigned long
> ./drivers/net/wireless/ath/ath9k/htc_hst.c:206
>   int return assigned to unsigned long
> 
> Patch was compile tested with x86_64_defconfig + CONFIG_ATH_CARDS=m,
> CONFIG_ATH9K_HTC=m
> 
> Patch is against 4.1-rc3 (localversion-next is -next-20150514)
> 
> 
> Signed-off-by: Nicholas Mc Guire 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 3/6] drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel

[Thierry Reding]

On Wed, Jul 29, 2015 at 04:30:02PM +0800, Jianwei Wang wrote:
> This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
> simple panel driver.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> Acked-by: Daniel Vetter 
> ---
>  .../bindings/panel/nec,nl4827hc19_05b.txt  |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> 
> diff --git a/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt 
> b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> new file mode 100644
> index 000..20e9473
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> @@ -0,0 +1,7 @@
> +NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "nec,nl4827hc19_05b"

Underscores are deprecated in compatible strings, so I've applied this
with "nec,nl4827hc19-05b".

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v5 2/2] pinctrl: rockchip: only enable gpio clock when it setting

[Linus Walleij]

On Tue, Aug 11, 2015 at 12:12 PM, Lin Huang  wrote:

> gpio can keep state even the clock disable, for save power
> consumption, only enable gpio clock when it setting
>
> Signed-off-by: Lin Huang 
> Reviewed-by: Heiko Stuebner 
> ---
> Changes in v5:
> -rebase patch

Patch applied with Doug's test tags etc.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [V2] rtlwifi: misspelled code and comments corrected.

[Kalle Valo]

> Signed-off-by: Cheolhyun Park 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] nohz_full: Offload task_tick to remote housekeeping cpus for nohz_full cpus

[Peter Zijlstra]

On Thu, Aug 13, 2015 at 02:55:36PM +0530, Vatika Harlalka wrote:
> This patchset is for offloading task_tick() to a remote housekeeping
> cpu. The larger aim is to stop ticks on nohz_full cpus. For this, extra
> work must be done by housekeeping cpus. So, task_tick is called from a
> delayed workqueue for nohz_full cpus and the work is requeued every second
> for those nohz_full cpus whose ticks are stopped while they are busy. In
> the rest of the cases it will lead to redundant accounting. To facilitate
> this, a new function tick_nohz_remote_tick_stopped is added to indicate
> whether ticks are stopped on a remote cpu.
> Tick related code in core.c is moved to tick.c

*sigh* of course you didn't read what I've written on this topic..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 3/6] drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel

[Thierry Reding]

On Wed, Jul 29, 2015 at 04:30:02PM +0800, Jianwei Wang wrote:
> This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
> simple panel driver.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> Acked-by: Daniel Vetter 
> ---
>  .../bindings/panel/nec,nl4827hc19_05b.txt  |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH] pinctrl/mediatek: fix spelling mistake in dev_err error message

[Linus Walleij]

On Mon, Aug 3, 2015 at 1:10 AM, Colin King  wrote:

> From: Colin Ian King 
>
> Trivial change, fix spelling mistake 'invaild' -> 'invalid' in
> dev_err message.
>
> Signed-off-by: Colin Ian King 

Patch applied with Hongzhou's ACK.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] paride: fix a return in pd_detect()

[Sudip Mukherjee]

On Thu, Aug 13, 2015 at 12:08:43AM +0300, Dan Carpenter wrote:
> In this function returning non-zero means the hardware was detected and
> zero means it wasn't.  This is a failure path so we should return zero.
> 
> Fixes: 9f4ba6b05869 ('paride: use new parport device model')
> Signed-off-by: Dan Carpenter 

Acked-by: Sudip Mukherjee 

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 41/46] sched/fair: add triggers for OPP change requests

[Vincent Guittot]

On 12 August 2015 at 17:15, Juri Lelli  wrote:
> On 11/08/15 17:37, Vincent Guittot wrote:
>> On 11 August 2015 at 17:07, Juri Lelli  wrote:
>>> Hi Vincent,
>>>
>>> On 11/08/15 12:41, Vincent Guittot wrote:
 On 11 August 2015 at 11:08, Juri Lelli  wrote:
> On 10/08/15 16:07, Vincent Guittot wrote:
>> On 10 August 2015 at 15:43, Juri Lelli  wrote:
>>>
>>> Hi Vincent,
>>>
>>> On 04/08/15 14:41, Vincent Guittot wrote:
 Hi Juri,

 On 7 July 2015 at 20:24, Morten Rasmussen  
 wrote:
> From: Juri Lelli 

 [snip]

>  }
> @@ -4393,6 +4416,23 @@ static void dequeue_task_fair(struct rq *rq, 
> struct task_struct *p, int flags)
> if (!se) {
> sub_nr_running(rq, 1);
> update_rq_runnable_avg(rq, 1);
> +   /*
> +* We want to trigger a freq switch request only for 
> tasks that
> +* are going to sleep; this is because we get here 
> also during
> +* load balancing, but in these cases it seems wise 
> to trigger
> +* as single request after load balancing is done.
> +*
> +* Also, we add a margin (same ~20% used for the 
> tipping point)
> +* to our request to provide some head room if p's 
> utilization
> +* further increases.
> +*/
> +   if (sched_energy_freq() && task_sleep) {
> +   unsigned long req_cap = 
> get_cpu_usage(cpu_of(rq));
> +
> +   req_cap = req_cap * capacity_margin
> +   >> SCHED_CAPACITY_SHIFT;
> +   cpufreq_sched_set_cap(cpu_of(rq), req_cap);

 Could you clarify why you want to trig a freq switch for tasks that
 are going to sleep ?
 The cpu_usage should not changed that much as the se_utilization of
 the entity moves from utilization_load_avg to utilization_blocked_avg
 of the rq and the usage and the freq are updated periodically.
>>>
>>> I think we still need to cover multiple back-to-back dequeues. Suppose
>>> that you have, let's say, 3 tasks that get enqueued at the same time.
>>> After some time the first one goes to sleep and its utilization, as you
>>> say, gets moved to utilization_blocked_avg. So, nothing changes, and
>>> the trigger is superfluous (even if no freq change I guess will be
>>> issued as we are already servicing enough capacity). However, after a
>>> while, the second task goes to sleep. Now we still use get_cpu_usage()
>>> and the first task contribution in utilization_blocked_avg should have
>>> been decayed by this time. Same thing may than happen for the third task
>>> as well. So, if we don't check if we need to scale down in
>>> dequeue_task_fair, it seems to me that we might miss some opportunities,
>>> as blocked contribution of other tasks could have been successively
>>> decayed.
>>>
>>> What you think?
>>
>> The tick is used to monitor such variation of the usage (in both way,
>> decay of the usage of sleeping tasks and increase of the usage of
>> running tasks). So in your example, if the duration between the sleep
>> of the 2 tasks is significant enough, the tick will handle this
>> variation
>>
>
> The tick is used to decide if we need to scale up (to max OPP for the
> time being), but we don't scale down. It makes more logical sense to

 why don't you want to check if you need to scale down ?

>>>
>>> Well, because if I'm still executing something the cpu usage is only
>>> subject to raise.
>>
>> This is only true for  system with NO HZ idle
>>
>
> Well, even with !NO_HZ_IDLE usage only decreases when cpu is idle. But,

Well, thanks for this obvious statement that usage only decreases when
cpu is idle but my question has never been about usage variation of
idle/running cpu but about the tick.

> I think I got your point; for !NO_HZ_IDLE configurations we might end
> up not scaling down frequency even if we have the tick running and
> the cpu is idle. I might need some more time to think this through, but
> it seems to me that we are still fine without an explicit trigger in
> task_tick_fair(); if we are running a !NO_HZ_IDLE system we are probably
> not so much concerned about power savings and still we react
> to tasks waking up, sleeping, leaving or moving around (which seems the
> real important events to me); OTOH, we might add that trigger, but this
> will generate unconditional checks at tick time for NO_HZ_IDLE

That will be far less critical than unconditionally check during all
task wake up or sleep. A task 

[PATCH] spi: Mediatek: fixup cpu_to_le32 incorrect usage

[Leilk Liu]

writel() already does a cpu_to_le32 conversion, so
remove cpu_to_le32().

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index ae645fa..519f50c 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -359,11 +359,9 @@ static void mtk_spi_setup_dma_addr(struct spi_master 
*master,
struct mtk_spi *mdata = spi_master_get_devdata(master);
 
if (mdata->tx_sgl)
-   writel((__force u32)cpu_to_le32(xfer->tx_dma),
-  mdata->base + SPI_TX_SRC_REG);
+   writel(xfer->tx_dma, mdata->base + SPI_TX_SRC_REG);
if (mdata->rx_sgl)
-   writel((__force u32)cpu_to_le32(xfer->rx_dma),
-  mdata->base + SPI_RX_DST_REG);
+   writel(xfer->rx_dma, mdata->base + SPI_RX_DST_REG);
 }
 
 static int mtk_spi_fifo_transfer(struct spi_master *master,
-- 
1.8.1.1.dirty

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

Re: [PATCH v2 00/22] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 13/08/15 11:36, Tony Lindgren wrote:
> * Roger Quadros  [150813 00:17]:
>> On 11/08/15 15:48, Tony Lindgren wrote:
>>>
>>> OK. Yeah let's make sure no regressions are caused by this.. We also
>>> still have the omap3 legacy booting around, have you checked that it
>>> keeps on working?
>>
>> I don't have any omap3 board with legacy support with me. I have omap3-beagle
>> but looks like legacy boot is dropped for it already.
>>
>> I'll try to revert the patch that drops beagle support and test it on that 
>> one.
> 
> OK yeah that should work just fine.
> 

Just verified that with the change in patch 6 it works on omap3-beagle legacy 
boot.
I have fixed some checkpatch issues in this series as well. Will post a v3
after you have gone one pass over this series.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

[Ville Syrjälä]

On Thu, Aug 13, 2015 at 08:52:23AM +0200, Sedat Dilek wrote:
> On Wed, Aug 12, 2015 at 9:26 PM, Ville Syrjälä
>  wrote:
> > On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
> >> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek  wrote:
> >> > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek  
> >> > wrote:
> >> >> Hi,
> >> >>
> >> >> this my first build of a 4.2-rcN Linux-kernel and I see this...
> >> >>
> >> >
> >> > Just FYI:
> >> >
> >> > I am *not* seeing this with drm-intel-nightly from below url.
> >> >
> >> > Also, I plan to test Linux v4.2-rc5.
> >> >
> >>
> >> [ CC Linus ]
> >>
> >> Knock Knock Knock.
> >>
> >> This issue still remains here (with CONFIG_DRM_I915=m)...
> >>
> >> [   18.269792] ==
> >> [   18.269798] [ INFO: possible circular locking dependency detected ]
> >> [   18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
> >> [   18.269810] ---
> >> [   18.269816] modprobe/727 is trying to acquire lock:
> >> [   18.269822]  (init_mutex){+.+.+.}, at: []
> >> acpi_video_get_backlight_type+0x17/0x164 [video]
> >> [   18.269840]
> >> [   18.269840] but task is already holding lock:
> >> [   18.269848]  (&(_notifier)->rwsem){..}, at:
> >> [] __blocking_notifier_call_chain+0x39/0x70
> >> [   18.269864]
> >> [   18.269864] which lock already depends on the new lock.
> >> [   18.269864]
> >> [   18.269875]
> >> [   18.269875] the existing dependency chain (in reverse order) is:
> >> [   18.269884]
> >> ...
> >>
> >> Full dmesg log and kernel-config attached.
> >>
> >> Shall I add Rusty and modules/modprobe folks?
> >
> > Just got back from vacation and was greeted by this same lockdep splat.
> >
> > On a hunch I reverted
> >
> > commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
> > Author: Hans de Goede 
> > Date:   Tue Jun 16 16:27:52 2015 +0200
> >
> > ACPI / video: Move backlight notifier to video_detect.c
> >
> > and the problem seems to be gone. Hans, any thoughts?
> >
> 
> Reverting this commit on top of Linux v4.2-rc6 causes troubles here.
> 
> $ LC_ALL=C git revert 93a291dfaf9c328ca5a9cea1733af1
> error: could not revert 93a291dfaf9c... ACPI / video: Move backlight
> notifier to video_detect.c
> hint: after resolving the conflicts, mark the corrected paths
> hint: with 'git add ' or 'git rm '
> hint: and commit the result with 'git commit'
> 
> Provide a suitable patch and I test for you.

Hmm. Oh yeah, I had to revert a couple of other ones to get the first
one to revert cleanly:

commit d0a530ba424ec1be7630f7fce2db9860b9429b8f
Author: Hans de Goede 
Date:   Tue Jun 16 16:28:12 2015 +0200

acpi-video-detect: Remove old API

commit e7d024c00a4a7b617390db863bdd5b9dc65821f7
Author: Hans de Goede 
Date:   Tue Jun 16 16:28:13 2015 +0200

ACPI / video: Make acpi_video_unregister_backlight() private

> 
> - Sedat -
> 
> >>
> >> - Sedat -
> >>
> >> > - Sedat -
> >> >
> >> > [1] 
> >> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
> >> > [2] 
> >> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-994.201508010158_amd64.deb
> >> >
> >> >> [   24.001043] [drm] Memory usable by graphics device = 2048M
> >> >> [   24.001118] [drm] Replacing VGA console driver
> >> >> [   24.011642] [drm] Supports vblank timestamp caching Rev 2 
> >> >> (21.10.2013).
> >> >> [   24.011646] [drm] Driver supports precise vblank timestamp query.
> >> >> [   24.012480] vgaarb: device changed decodes:
> >> >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> >> >> [   24.028005]
> >> >> [   24.028014] ==
> >> >> [   24.028020] [ INFO: possible circular locking dependency detected ]
> >> >> [   24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
> >> >> [   24.028032] ---
> >> >> [   24.028038] modprobe/740 is trying to acquire lock:
> >> >> [   24.028043]  (init_mutex){+.+.+.}, at: []
> >> >> acpi_video_get_backlight_type+0x17/0x164 [video]
> >> >> [   24.028060]
> >> >> [   24.028060] but task is already holding lock:
> >> >> [   24.028068]  (&(_notifier)->rwsem){..}, at:
> >> >> [] __blocking_notifier_call_chain+0x39/0x70
> >> >> [   24.028083]
> >> >> [   24.028083] which lock already depends on the new lock.
> >> >> [   24.028083]
> >> >> [   24.028095]
> >> >> [   24.028095] the existing dependency chain (in reverse order) is:
> >> >> [   24.028103]
> >> >> [   24.028103] -> #1 (&(_notifier)->rwsem){..}:
> >> >> [   24.028113][] lock_acquire+0xcf/0x280
> >> >> [   24.028121][] down_write+0x49/0x80
> >> >> [   24.028129][]
> >> >> blocking_notifier_chain_register+0x21/0xb0
> >> >> [   24.028138][] 
> >> >> backlight_register_notifier+0x18/0x20
> >> >> [   24.028147][]
> >> >> acpi_video_get_backlight_type+0xfa/0x164 [video]
> >> 

Re: [PATCH v2 16/22] memory: omap-gpmc: Support general purpose input for WAITPINs

[Roger Quadros]

On 07/08/15 12:12, Roger Quadros wrote:
> OMAPs can have 2 to 4 WAITPINs that can be used as general purpose
> input if not used for memory wait state insertion.
> 
> The first user will be the OMAP NAND chip to get the NAND
> read/busy status using gpiolib.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/memory/omap-gpmc.c | 122 
> +++--
>  1 file changed, 117 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index 30d9c21..264009d 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -223,6 +224,11 @@ struct omap3_gpmc_regs {
>   struct gpmc_cs_config cs_context[GPMC_CS_NUM];
>  };
>  
> +struct gpmc_device {
> + struct device *dev;
> + struct gpio_chip gpio_chip;
> +};
> +
>  static struct resource   gpmc_mem_root;
>  static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
>  static DEFINE_SPINLOCK(gpmc_mem_lock);
> @@ -1919,10 +1925,69 @@ err:
>   return ret;
>  }
>  
> +static int gpmc_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
> +{
> + return 1;   /* we're input only */
> +}
> +
> +static int gpmc_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
> +{
> + return 0;   /* we're input only */
> +}
> +
> +static int gpmc_gpio_direction_output(struct gpio_chip *chip, unsigned 
> offset,
> +   int value)
> +{
> + return -EINVAL; /* we're input only */
> +}
> +
> +static void gpmc_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
> +{
> +}
> +
> +static int gpmc_gpio_get(struct gpio_chip *chip, unsigned offset)
> +{
> + u32 reg;
> +
> + offset += 8;
> +
> + reg = gpmc_read_reg(GPMC_STATUS) & BIT(offset);
> +
> + return !!reg;
> +}
> +
> +static int gpmc_gpio_init(struct gpmc_device *gpmc)
> +{
> + int ret;
> +
> + gpmc->gpio_chip.dev = gpmc->dev;
> + gpmc->gpio_chip.owner = THIS_MODULE;
> + gpmc->gpio_chip.label = DEVICE_NAME;
> + gpmc->gpio_chip.ngpio = gpmc_nr_waitpins;
> + gpmc->gpio_chip.get_direction = gpmc_gpio_get_direction;
> + gpmc->gpio_chip.direction_input = gpmc_gpio_direction_input;
> + gpmc->gpio_chip.direction_output = gpmc_gpio_direction_output;
> + gpmc->gpio_chip.set = gpmc_gpio_set;
> + gpmc->gpio_chip.get = gpmc_gpio_get;
> + gpmc->gpio_chip.base = -1;
> +
> + ret = gpiochip_add(>gpio_chip);
> + if (ret < 0) {
> + dev_err(gpmc->dev, "could not register gpio chip: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void gpmc_gpio_exit(struct gpmc_device *gpmc)
> +{
> + gpiochip_remove(>gpio_chip);
> +}
> +
>  static int gpmc_probe_dt(struct platform_device *pdev)
>  {
>   int ret;
> - struct device_node *child;
>   const struct of_device_id *of_id =
>   of_match_device(gpmc_dt_ids, >dev);
>  
> @@ -1950,6 +2015,17 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>   return ret;
>   }
>  
> + dev_info(>dev, "num-cs %d, num-wait %d\n",
> +  gpmc_cs_num, gpmc_nr_waitpins);
> +
> + return 0;
> +}
> +
> +static int gpmc_probe_dt_children(struct platform_device *pdev)
> +{
> + int ret;
> + struct device_node *child;
> +
>   for_each_available_child_of_node(pdev->dev.of_node, child) {
>  
>   if (!child->name)
> @@ -1959,6 +2035,9 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>   ret = gpmc_probe_onenand_child(pdev, child);
>   else
>   ret = gpmc_probe_generic_child(pdev, child);
> +
> + if (ret)
> + return ret;
>   }
>  
>   return 0;
> @@ -1968,6 +2047,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
>  {
>   return 0;
>  }
> +
> +static int gpmc_probe_dt_children(struct platform_device *pdev)
> +{
> + return 0;
> +}
>  #endif
>  
>  static int gpmc_probe(struct platform_device *pdev)
> @@ -1975,6 +2059,7 @@ static int gpmc_probe(struct platform_device *pdev)
>   int rc;
>   u32 l;
>   struct resource *res;
> + struct gpmc_device *gpmc;
>  
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   if (res == NULL)
> @@ -2005,6 +2090,17 @@ static int gpmc_probe(struct platform_device *pdev)
>   return -EINVAL;
>   }
>  
> + rc = gpmc_probe_dt(pdev);
> + if (rc)
> + return rc;
> +
> + gpmc = devm_kzalloc(>dev, sizeof(*gpmc), GFP_KERNEL);
> + if (!gpmc)
> + return -ENOMEM;
> +
> + gpmc->dev = >dev;
> + platform_set_drvdata(pdev, gpmc);
> +
>   pm_runtime_enable(>dev);
>   pm_runtime_get_sync(>dev);
>  
> @@ -2032,24 +2128,40 @@ static int gpmc_probe(struct platform_device *pdev)
>GPMC_REVISION_MINOR(l));
>  

Re: [PATCH] mac80211: fix invalid read in minstrel_sort_best_tp_rates()

[Johannes Berg]

On Tue, 2015-07-28 at 10:30 +0200, Adrien Schildknecht wrote:
> At the last iteration of the loop, j may equal zero and thus
> tp_list[j - 1] causes an invalid read.
> Changed the logic of the loop so that j - 1 is always >= 0.
> 
> Signed-off-by: Adrien Schildknecht 
> 
Applied, I added Cc stable.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] scsi: Export SCSI Inquiry data to sysfs

[Johannes Thumshirn]

Export the RAW SCSI Inquiry to sysfs as binfile. This way the data can be
used by userlang without the need to have and ioctl or use the sg_inq tool.

Here is an example of the provided data

linux:~ # hexdump /sys/class/scsi_device/1\:0\:0\:0/device/inquiry
000 8005 3205 001f  4551 554d 2020 2020
010 4551 554d 4420 4456 522d 4d4f 2020 2020
020 2e32 2e33
024

Signed-off-by: Johannes Thumshirn 
---
 drivers/scsi/scsi_sysfs.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 9ad4116..5ecb65d 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -773,6 +773,29 @@ static struct bin_attribute dev_attr_vpd_##_page = {   
\
 sdev_vpd_pg_attr(pg83);
 sdev_vpd_pg_attr(pg80);
 
+static ssize_t show_inquiry(struct file *filep, struct kobject *kobj,
+   struct bin_attribute *bin_attr,
+   char *buf, loff_t off, size_t count)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct scsi_device *sdev = to_scsi_device(dev);
+
+   if (!sdev->inquiry)
+   return -EINVAL;
+
+   return memory_read_from_buffer(buf, count, , sdev->inquiry,
+  sdev->inquiry_len);
+}
+
+static struct bin_attribute dev_attr_inquiry = {
+   .attr = {
+   .name = "inquiry",
+   .mode = S_IRUGO,
+   },
+   .size = 0,
+   .read = show_inquiry,
+};
+
 static ssize_t
 show_iostat_counterbits(struct device *dev, struct device_attribute *attr,
char *buf)
@@ -957,6 +980,7 @@ static struct attribute *scsi_sdev_attrs[] = {
 static struct bin_attribute *scsi_sdev_bin_attrs[] = {
_attr_vpd_pg83,
_attr_vpd_pg80,
+   _attr_inquiry,
NULL
 };
 static struct attribute_group scsi_sdev_attr_group = {
-- 
2.5.0

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

Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Emil Velikov]

On 13 August 2015 at 01:56, Eric Anholt  wrote:
> This is the start of a full VC4 driver.  Right now this just supports
> configuring the display using a pre-existing video mode (because
> changing the pixel clock isn't available yet, and doesn't work when it
> is).  However, this is enough for fbcon and bringing up X using
> xf86-video-modesetting.
>
> Signed-off-by: Eric Anholt 
...
> --- /dev/null
> +++ b/drivers/gpu/drm/vc4/Makefile
> @@ -0,0 +1,18 @@
> +ccflags-y := -Iinclude/drm
> +
> +# Please keep these build lists sorted!
> +
> +# core driver code
> +vc4-y := \
> +   vc4_bo.o \
> +   vc4_crtc.o \
> +   vc4_drv.o \
> +   vc4_kms.o \
> +   vc4_hdmi.o \
> +   vc4_hvs.o \
> +   vc4_plane.o \
> +   $()
> +
In case anyone is curious - this is the first sentinel in the whole
kernel (some 2000+ Makefiles) :-)

-Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 3/7] arm64: Kprobes with single stepping support

[Steve Capper]

Hi David,

On 11 August 2015 at 01:52, David Long  wrote:
> From: Sandeepa Prabhu 
>
> Add support for basic kernel probes(kprobes) and jump probes
> (jprobes) for ARM64.
>
> Kprobes utilizes software breakpoint and single step debug
> exceptions supported on ARM v8.
>
> A software breakpoint is placed at the probe address to trap the
> kernel execution into the kprobe handler.
>
> ARM v8 supports enabling single stepping before the break exception
> return (ERET), with next PC in exception return address (ELR_EL1). The
> kprobe handler prepares an executable memory slot for out-of-line
> execution with a copy of the original instruction being probed, and
> enables single stepping. The PC is set to the out-of-line slot address
> before the ERET. With this scheme, the instruction is executed with the
> exact same register context except for the PC (and DAIF) registers.
>
> Debug mask (PSTATE.D) is enabled only when single stepping a recursive
> kprobe, e.g.: during kprobes reenter so that probed instruction can be
> single stepped within the kprobe handler -exception- context.
> The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
> any further re-entry is prevented by not calling handlers and the case
> counted as a missed kprobe).
>
> Single stepping from the x-o-l slot has a drawback for PC-relative accesses
> like branching and symbolic literals access as the offset from the new PC
> (slot address) may not be ensured to fit in the immediate value of
> the opcode. Such instructions need simulation, so reject
> probing them.
>
> Instructions generating exceptions or cpu mode change are rejected
> for probing.
>
> Instructions using Exclusive Monitor are rejected too.
>
> System instructions are mostly enabled for stepping, except MSR/MRS
> accesses to "DAIF" flags in PSTATE, which are not safe for
> probing.
>
> Thanks to Steve Capper and Pratyush Anand for several suggested
> Changes.
>
> Signed-off-by: Sandeepa Prabhu 
> Signed-off-by: Steve Capper 

Please remove my SoB, we can replace it with a Reviewed-by hopefully soon :-).


> Signed-off-by: David A. Long 
> ---
>  arch/arm64/Kconfig  |   1 +
>  arch/arm64/include/asm/debug-monitors.h |   5 +
>  arch/arm64/include/asm/kprobes.h|  62 
>  arch/arm64/include/asm/probes.h |  50 +++
>  arch/arm64/include/asm/ptrace.h |   3 +-
>  arch/arm64/kernel/Makefile  |   1 +
>  arch/arm64/kernel/debug-monitors.c  |  35 ++-
>  arch/arm64/kernel/kprobes-arm64.c   |  68 
>  arch/arm64/kernel/kprobes-arm64.h   |  28 ++
>  arch/arm64/kernel/kprobes.c | 537 
> 
>  arch/arm64/kernel/kprobes.h |  24 ++
>  arch/arm64/kernel/vmlinux.lds.S |   1 +
>  arch/arm64/mm/fault.c   |  25 ++
>  13 files changed, 829 insertions(+), 11 deletions(-)
>  create mode 100644 arch/arm64/include/asm/kprobes.h
>  create mode 100644 arch/arm64/include/asm/probes.h
>  create mode 100644 arch/arm64/kernel/kprobes-arm64.c
>  create mode 100644 arch/arm64/kernel/kprobes-arm64.h
>  create mode 100644 arch/arm64/kernel/kprobes.c
>  create mode 100644 arch/arm64/kernel/kprobes.h
>

[...]

> +
> +void __kprobes kprobe_handler(struct pt_regs *regs)
> +{
> +   struct kprobe *p, *cur;
> +   struct kprobe_ctlblk *kcb;
> +   unsigned long addr = instruction_pointer(regs);
> +
> +   kcb = get_kprobe_ctlblk();
> +   cur = kprobe_running();
> +
> +   p = get_kprobe((kprobe_opcode_t *) addr);
> +
> +   if (p) {
> +   if (cur) {
> +   if (reenter_kprobe(p, regs, kcb))
> +   return;
> +   } else if (!p->ainsn.check_condn ||
> +  p->ainsn.check_condn(p, regs)) {
> +   /* Probe hit and conditional execution check ok. */
> +   set_current_kprobe(p);
> +   kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> +
> +   /*
> +* If we have no pre-handler or it returned 0, we
> +* continue with normal processing.  If we have a
> +* pre-handler and it returned non-zero, it prepped
> +* for calling the break_handler below on re-entry,
> +* so get out doing nothing more here.
> +*
> +* pre_handler can hit a breakpoint and can step thru
> +* before return, keep PSTATE D-flag enabled until
> +* pre_handler return back.
> +*/
> +   if (!p->pre_handler || !p->pre_handler(p, regs)) {
> +   kcb->kprobe_status = KPROBE_HIT_SS;
> +   setup_singlestep(p, regs, kcb, 0);
> +   return;
> +   }
> +   } else {
> 

Re: [PATCH v2] Remove unselectable rule for arm-exynos-cpufreq.o

[Krzysztof Kozlowski]

2015-08-13 20:33 GMT+09:00 Viresh Kumar :
> On 13-08-15, 13:28, Jonas Rabenstein wrote:
>> Commit "cpufreq: exynos: remove Exynos4x12 specific cpufreq driver
>> support" deleted option ARM_EXYNOS_CPUFREQ but missed to delete a rule
>> in drivers/cpufreq/Makefile which depends on that option.
>>
>> Remove unselectable rule for arm-exynos-cpufreq.o from
>> drivers/cpufreq/Makefile.
>>
>> Signed-off-by: Jonas Rabenstein 
>> ---
>> I found this inconsistency using the undertaker and
>> undertaker-checkpatch tools (https://undertaker.cs.fau.de/).
>>
>>  drivers/cpufreq/Makefile | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index bbc4a9f..958be2b 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -52,7 +52,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += 
>> arm_big_little_dt.o
>>
>>  obj-$(CONFIG_ARCH_DAVINCI)   += davinci-cpufreq.o
>>  obj-$(CONFIG_UX500_SOC_DB8500)   += dbx500-cpufreq.o
>> -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += arm-exynos-cpufreq.o
>>  obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
>>  obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)   += highbank-cpufreq.o
>>  obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ)  += hisi-acpu-cpufreq.o
>
> Acked-by: Viresh Kumar 

And again from me:
Reviewed-by: Krzysztof Kozlowski 

Dear Kukjin,
Can you take it and send in (updated) pull request with Exynos4x12
cpufreq patches?

BR,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/6] mailbox: Add generic mechanism for testing Mailbox Controllers

[Lee Jones]

On Thu, 13 Aug 2015, Jassi Brar wrote:

> On Thu, Aug 13, 2015 at 4:30 PM, Lee Jones  wrote:
> > On Thu, 13 Aug 2015, Jassi Brar wrote:
> >
> >> On Thu, Aug 13, 2015 at 3:53 PM, Lee Jones  wrote:
> >> > On Thu, 13 Aug 2015, Jassi Brar wrote:
> >> >
> >> >> On Thu, Aug 13, 2015 at 2:49 PM, Lee Jones  wrote:
> >> >> > On Thu, 13 Aug 2015, Jassi Brar wrote:
> >> >>
> >> >> >> >> > +
> >> >> >> >> > +static void mbox_test_prepare_message(struct mbox_client 
> >> >> >> >> > *client, void *message)
> >> >> >> >> > +{
> >> >> >> >> > +   struct mbox_test_device *tdev = 
> >> >> >> >> > dev_get_drvdata(client->dev);
> >> >> >> >> > +
> >> >> >> >> > +   if (tdev->mmio)
> >> >> >> >> > +   memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
> >> >> >> >> >
> >> >> >> >> This is unlikely to work. Those platforms that need to send a 2 
> >> >> >> >> part
> >> >> >> >> message, they do :
> >> >> >> >> (a) Signal/Command/Target code via some controller register (via
> >> >> >> >> mbox_send_message).
> >> >> >> >> (b) Setup the payload in Shared-Memory (via tx_prepare).
> >> >> >> >>
> >> >> >> >> This test driver assumes both are the same. I think you have to
> >> >> >> >> declare something like
> >> >> >> >
> >> >> >> > This driver assumes that the framework will call 
> >> >> >> > client->tx_prepare()
> >> >> >> > first, which satisfies (b).  It then assumes 
> >> >> >> > controller->send_data()
> >> >> >> > will be invoked, which will send the platform specific
> >> >> >> > signal/command/target code, which then satisfies (a).
> >> >> >> >
> >> >> >> Yeah, but what would be that code? Who provides that?
> >> >> >>
> >> >> >> > In what way does it assume they are the same?
> >> >> >> >
> >> >> >> notice the 'message' pointer in
> >> >> >> mbox_send_message(tdev->tx_channel, message);
> >> >> >> and
> >> >> >> memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
> >> >> >>
> >> >> >> >> struct mbox_test_message { /* same for TX and RX */
> >> >> >> >>   unsigned sig_len;
> >> >> >> >>   void *signal;   /* rx/tx via mailbox api */
> >> >> >> >>   unsigned pl_len;
> >> >> >> >>   void *payload;   /* rx/tx via shared-memory */
> >> >> >> >> };
> >> >> >> >
> >> >> >> > How do you think this should be set and use these?
> >> >> >> >
> >> >> >> The userspace would want to specify the command code (32bits or not)
> >> >> >> that would be passed via the fifo/register of the controller. So we
> >> >> >> need signal[]
> >> >> >>
> >> >> >> The data to be passed via share-memory could be provided by userspace
> >> >> >> via the payload[] array.
> >> >> >
> >> >> > Okay, so would the solution be two userspace files 'signal' and
> >> >> > 'message', so in the case of a client specified signal we can write it
> >> >> > into there first.
> >> >> >
> >> >> > echo 255  > signal
> >> >> > echo test > message
> >> >> >
> >> >> > ... or in the case where no signal is required, or the controller
> >> >> > driver taking care of it, we just don't write anything to signal?
> >> >> >
> >> >> file_operations.write() should parse signal and message, coming from
> >> >> userspace, into a local structure before routing them via
> >> >> mbox_send_message and tx_prepare respectively.
> >> >
> >> > Okay.  So before I code this up we should agree on syntax.
> >> >
> >> > How would you like to represent the break between signal and message?
> >> > Obviously ' ' would be a bad idea, as some clients may want to send
> >> > messages with white space contained.  How about '\t' or '\n'?
> >> >
> >> Yeah, I am not a fan of markers and flags either.
> >>
> >> Maybe we should share with userspace
> >>   struct mbox_test_message { /* same for TX and RX */
> >>unsigned sig_len;
> >>void __user *signal;/* rx/tx via mailbox api */
> >>unsigned pl_len;
> >>void __user *payload;/* rx/tx via shared-memory */
> >>   };
> >>
> >> First copy_from_user the structure of length sizof(struct
> >> mbox_test_message) and then copy_from_user length sig_len and pl_len
> >> from signal[] and payload[] respectively (usually ioctls would carry
> >> such data).
> >
> > Simplicity and ease of use should be the goals here.  Testers should
> > not have to write applications to use this driver.  Can we come up
> > with a simple/effective method that uses SYSFS/DEBUGFS please?
> >
> > The easiest way I can think of which avoids markers/separators AND the
> > requirement for users to have to write applications is to have two
> > files, 'signal' and 'message' as mentioned before.  Once both are
> > populated I can get this driver to draft the message appropriately and
> > fire it off.
> >
> And then write to more files for RX data? ... which should also be in
> the form of 'signal' and 'message'.
> 
> BTW like for spi there is a stock application in
> Documentation/spi/spidev_test.c we could do the same?

Coming from personal experience, testing drivers with 

[PATCH 05/14] arm64: Handle 4 level page table for swapper

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

At the moment, we only support maximum of 3-level page table for
swapper. With 48bit VA, 64K has only 3 levels and 4K uses section
mapping. Add support for 4-level page table for swapper, needed
by 16K pages.

Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/kernel/head.S |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 46670bf..01b8e58 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -271,7 +271,10 @@ ENDPROC(preserve_boot_args)
  */
.macro  create_pgd_entry, tbl, virt, tmp1, tmp2
create_table_entry \tbl, \virt, PGDIR_SHIFT, PTRS_PER_PGD, \tmp1, \tmp2
-#if SWAPPER_PGTABLE_LEVELS == 3
+#if SWAPPER_PGTABLE_LEVELS > 3
+   create_table_entry \tbl, \virt, PUD_SHIFT, PTRS_PER_PUD, \tmp1, \tmp2
+#endif
+#if SWAPPER_PGTABLE_LEVELS > 2
create_table_entry \tbl, \virt, SWAPPER_TABLE_SHIFT, PTRS_PER_PTE, 
\tmp1, \tmp2
 #endif
.endm
-- 
1.7.9.5

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

[PATCH 06/14] arm64: Clean config usages for page size

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

We use !CONFIG_ARM64_64K_PAGES for CONFIG_ARM64_4K_PAGES
(and vice versa) in code. It all worked well, so far since
we only had two options. Now, with the introduction of 16K,
these cases will break. This patch cleans up the code to
use the required CONFIG symbol expression without the assumption
that !64K => 4K (and vice versa)

Cc: Ard Biesheuvel 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Steve Capper 
Acked-by: Mark Rutland 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/Kconfig   |4 ++--
 arch/arm64/Kconfig.debug |2 +-
 arch/arm64/include/asm/thread_info.h |2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 78b89fa..d1fb2a3 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -550,7 +550,7 @@ config ARCH_WANT_GENERAL_HUGETLB
def_bool y
 
 config ARCH_WANT_HUGE_PMD_SHARE
-   def_bool y if !ARM64_64K_PAGES
+   def_bool y if ARM64_4K_PAGES
 
 config HAVE_ARCH_TRANSPARENT_HUGEPAGE
def_bool y
@@ -762,7 +762,7 @@ source "fs/Kconfig.binfmt"
 
 config COMPAT
bool "Kernel support for 32-bit EL0"
-   depends on !ARM64_64K_PAGES || EXPERT
+   depends on ARM64_4K_PAGES || EXPERT
select COMPAT_BINFMT_ELF
select HAVE_UID16
select OLD_SIGSUSPEND3
diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index d6285ef..c24d6ad 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug
@@ -77,7 +77,7 @@ config DEBUG_RODATA
   If in doubt, say Y
 
 config DEBUG_ALIGN_RODATA
-   depends on DEBUG_RODATA && !ARM64_64K_PAGES
+   depends on DEBUG_RODATA && ARM64_4K_PAGES
bool "Align linker sections up to SECTION_SIZE"
help
  If this option is enabled, sections that may potentially be marked as
diff --git a/arch/arm64/include/asm/thread_info.h 
b/arch/arm64/include/asm/thread_info.h
index dcd06d1..d9c8c9f 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -23,7 +23,7 @@
 
 #include 
 
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_4K_PAGES
 #define THREAD_SIZE_ORDER  2
 #endif
 
-- 
1.7.9.5

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

[PATCH 04/14] arm64: Calculate size for idmap_pg_dir at compile time

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

Now that we can calculate the number of levels required for
mapping a va width, reserve exact number of pages that would
be required to cover the idmap. The idmap should be able to handle
the maximum physical address size supported.

Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/include/asm/boot.h   |1 +
 arch/arm64/include/asm/kernel-pgtable.h |7 +--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/boot.h b/arch/arm64/include/asm/boot.h
index 81151b6..678b63e 100644
--- a/arch/arm64/include/asm/boot.h
+++ b/arch/arm64/include/asm/boot.h
@@ -2,6 +2,7 @@
 #ifndef __ASM_BOOT_H
 #define __ASM_BOOT_H
 
+#include 
 #include 
 
 /*
diff --git a/arch/arm64/include/asm/kernel-pgtable.h 
b/arch/arm64/include/asm/kernel-pgtable.h
index 5876a36..def7168 100644
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -33,16 +33,19 @@
  * map to pte level. The swapper also maps the FDT (see __create_page_tables
  * for more information). Note that the number of ID map translation levels
  * could be increased on the fly if system RAM is out of reach for the default
- * VA range, so 3 pages are reserved in all cases.
+ * VA range, so pages required to map highest possible PA are reserved in all
+ * cases.
  */
 #if ARM64_SWAPPER_USES_SECTION_MAPS
 #define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS - 1)
+#define IDMAP_PGTABLE_LEVELS   (ARM64_HW_PGTABLE_LEVELS(PHYS_MASK_SHIFT) - 1)
 #else
 #define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS)
+#define IDMAP_PGTABLE_LEVELS   (ARM64_HW_PGTABLE_LEVELS(PHYS_MASK_SHIFT))
 #endif
 
 #define SWAPPER_DIR_SIZE   (SWAPPER_PGTABLE_LEVELS * PAGE_SIZE)
-#define IDMAP_DIR_SIZE (3 * PAGE_SIZE)
+#define IDMAP_DIR_SIZE (IDMAP_PGTABLE_LEVELS * PAGE_SIZE)
 
 /* Initial memory map size */
 #if ARM64_SWAPPER_USES_SECTION_MAPS
-- 
1.7.9.5

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

[PATCH 01/14] arm64: Move swapper pagetable definitions

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

Move the kernel pagetable (both swapper and idmap) definitions
from the generic asm/page.h to a new file, asm/kernel-pgtable.h.

This is mostly a cosmetic change, to clean up the asm/page.h to
get rid of the arch specific details which are not needed by the
generic code.

Also renames the symbols to prevent conflicts. e.g,
BLOCK_SHIFT => SWAPPER_BLOCK_SHIFT

Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/include/asm/kernel-pgtable.h |   65 +++
 arch/arm64/include/asm/page.h   |   18 -
 arch/arm64/kernel/head.S|   37 --
 arch/arm64/kernel/vmlinux.lds.S |1 +
 4 files changed, 74 insertions(+), 47 deletions(-)
 create mode 100644 arch/arm64/include/asm/kernel-pgtable.h

diff --git a/arch/arm64/include/asm/kernel-pgtable.h 
b/arch/arm64/include/asm/kernel-pgtable.h
new file mode 100644
index 000..622929d
--- /dev/null
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -0,0 +1,65 @@
+/*
+ * asm/kernel-pgtable.h : Kernel page table mapping
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#ifndef __ASM_KERNEL_PGTABLE_H
+#define __ASM_KERNEL_PGTABLE_H
+
+/*
+ * The idmap and swapper page tables need some space reserved in the kernel
+ * image. Both require pgd, pud (4 levels only) and pmd tables to (section)
+ * map the kernel. With the 64K page configuration, swapper and idmap need to
+ * map to pte level. The swapper also maps the FDT (see __create_page_tables
+ * for more information). Note that the number of ID map translation levels
+ * could be increased on the fly if system RAM is out of reach for the default
+ * VA range, so 3 pages are reserved in all cases.
+ */
+#ifdef CONFIG_ARM64_64K_PAGES
+#define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS)
+#else
+#define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS - 1)
+#endif
+
+#define SWAPPER_DIR_SIZE   (SWAPPER_PGTABLE_LEVELS * PAGE_SIZE)
+#define IDMAP_DIR_SIZE (3 * PAGE_SIZE)
+
+/* Initial memory map size */
+#ifdef CONFIG_ARM64_64K_PAGES
+#define SWAPPER_BLOCK_SHIFTPAGE_SHIFT
+#define SWAPPER_BLOCK_SIZE PAGE_SIZE
+#define SWAPPER_TABLE_SHIFTPMD_SHIFT
+#else
+#define SWAPPER_BLOCK_SHIFTSECTION_SHIFT
+#define SWAPPER_BLOCK_SIZE SECTION_SIZE
+#define SWAPPER_TABLE_SHIFTPUD_SHIFT
+#endif
+
+
+/*
+ * Initial memory map attributes.
+ */
+#define SWAPPER_PTE_FLAGS  PTE_TYPE_PAGE | PTE_AF | PTE_SHARED
+#define SWAPPER_PMD_FLAGS  PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S
+
+#ifdef CONFIG_ARM64_64K_PAGES
+#define SWAPPER_MM_MMUFLAGSPTE_ATTRINDX(MT_NORMAL) | SWAPPER_PTE_FLAGS
+#else
+#define SWAPPER_MM_MMUFLAGSPMD_ATTRINDX(MT_NORMAL) | SWAPPER_PMD_FLAGS
+#endif
+
+
+#endif
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 7d9c7e4..3c9ce8c 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -28,24 +28,6 @@
 #define PAGE_SIZE  (_AC(1,UL) << PAGE_SHIFT)
 #define PAGE_MASK  (~(PAGE_SIZE-1))
 
-/*
- * The idmap and swapper page tables need some space reserved in the kernel
- * image. Both require pgd, pud (4 levels only) and pmd tables to (section)
- * map the kernel. With the 64K page configuration, swapper and idmap need to
- * map to pte level. The swapper also maps the FDT (see __create_page_tables
- * for more information). Note that the number of ID map translation levels
- * could be increased on the fly if system RAM is out of reach for the default
- * VA range, so 3 pages are reserved in all cases.
- */
-#ifdef CONFIG_ARM64_64K_PAGES
-#define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS)
-#else
-#define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS - 1)
-#endif
-
-#define SWAPPER_DIR_SIZE   (SWAPPER_PGTABLE_LEVELS * PAGE_SIZE)
-#define IDMAP_DIR_SIZE (3 * PAGE_SIZE)
-
 #ifndef __ASSEMBLY__
 
 #include 
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index a055be6..46670bf 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -46,32 +47,10 @@
 #error TEXT_OFFSET must be less than 2MB
 #endif
 
-#ifdef CONFIG_ARM64_64K_PAGES
-#define BLOCK_SHIFTPAGE_SHIFT
-#define BLOCK_SIZE PAGE_SIZE
-#define 

[PATCH 03/14] arm64: Introduce helpers for page table levels

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

Introduce helpers for finding the number of page table
levels required for a given VA width, shift for a particular
page table level.

Convert the existing users to the new helpers. More users
to follow.

Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/include/asm/pgtable-hwdef.h |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
b/arch/arm64/include/asm/pgtable-hwdef.h
index 24154b0..ce18389 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -16,13 +16,21 @@
 #ifndef __ASM_PGTABLE_HWDEF_H
 #define __ASM_PGTABLE_HWDEF_H
 
+/*
+ * Number of page-table levels required to address 'va_bits' wide
+ * address, without section mapping
+ */
+#define ARM64_HW_PGTABLE_LEVELS(va_bits) (((va_bits) - 4) / (PAGE_SHIFT - 3))
+#define ARM64_HW_PGTABLE_LEVEL_SHIFT(level) \
+   ((PAGE_SHIFT - 3) * (level) + 3)
+
 #define PTRS_PER_PTE   (1 << (PAGE_SHIFT - 3))
 
 /*
  * PMD_SHIFT determines the size a level 2 page table entry can map.
  */
 #if CONFIG_PGTABLE_LEVELS > 2
-#define PMD_SHIFT  ((PAGE_SHIFT - 3) * 2 + 3)
+#define PMD_SHIFT  ARM64_HW_PGTABLE_LEVEL_SHIFT(2)
 #define PMD_SIZE   (_AC(1, UL) << PMD_SHIFT)
 #define PMD_MASK   (~(PMD_SIZE-1))
 #define PTRS_PER_PMD   PTRS_PER_PTE
@@ -32,7 +40,7 @@
  * PUD_SHIFT determines the size a level 1 page table entry can map.
  */
 #if CONFIG_PGTABLE_LEVELS > 3
-#define PUD_SHIFT  ((PAGE_SHIFT - 3) * 3 + 3)
+#define PUD_SHIFT  ARM64_HW_PGTABLE_LEVEL_SHIFT(3)
 #define PUD_SIZE   (_AC(1, UL) << PUD_SHIFT)
 #define PUD_MASK   (~(PUD_SIZE-1))
 #define PTRS_PER_PUD   PTRS_PER_PTE
@@ -42,7 +50,8 @@
  * PGDIR_SHIFT determines the size a top-level page table entry can map
  * (depending on the configuration, this level can be 0, 1 or 2).
  */
-#define PGDIR_SHIFT((PAGE_SHIFT - 3) * CONFIG_PGTABLE_LEVELS + 3)
+#define PGDIR_SHIFT\
+   ARM64_HW_PGTABLE_LEVEL_SHIFT(CONFIG_PGTABLE_LEVELS)
 #define PGDIR_SIZE (_AC(1, UL) << PGDIR_SHIFT)
 #define PGDIR_MASK (~(PGDIR_SIZE-1))
 #define PTRS_PER_PGD   (1 << (VA_BITS - PGDIR_SHIFT))
-- 
1.7.9.5

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

[PATCH 10/14] arm: kvm: Move fake PGD handling to arch specific files

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

Rearrange the code for fake pgd handling, which is applicable
to only ARM64. The intention is to keep the common code cleaner,
unaware of the underlying hacks.

Cc: kvm...@lists.cs.columbia.edu
Cc: christoffer.d...@linaro.org
Cc: marc.zyng...@arm.com
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm/include/asm/kvm_mmu.h   |7 ++
 arch/arm/kvm/mmu.c   |   44 +-
 arch/arm64/include/asm/kvm_mmu.h |   43 +
 3 files changed, 55 insertions(+), 39 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 405aa18..1c9aa8a 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -173,6 +173,13 @@ static inline unsigned int kvm_get_hwpgd_size(void)
return PTRS_PER_S2_PGD * sizeof(pgd_t);
 }
 
+static inline pgd_t *kvm_setup_fake_pgd(pgd_t *pgd)
+{
+   return pgd;
+}
+
+static inline void kvm_free_fake_pgd(pgd_t *pgd) {}
+
 struct kvm;
 
 #define kvm_flush_dcache_to_poc(a,l)   __cpuc_flush_dcache_area((a), (l))
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 7b42012..b210622 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -677,43 +677,11 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
 * guest, we allocate a fake PGD and pre-populate it to point
 * to the next-level page table, which will be the real
 * initial page table pointed to by the VTTBR.
-*
-* When KVM_PREALLOC_LEVEL==2, we allocate a single page for
-* the PMD and the kernel will use folded pud.
-* When KVM_PREALLOC_LEVEL==1, we allocate 2 consecutive PUD
-* pages.
 */
-   if (KVM_PREALLOC_LEVEL > 0) {
-   int i;
-
-   /*
-* Allocate fake pgd for the page table manipulation macros to
-* work.  This is not used by the hardware and we have no
-* alignment requirement for this allocation.
-*/
-   pgd = kmalloc(PTRS_PER_S2_PGD * sizeof(pgd_t),
-   GFP_KERNEL | __GFP_ZERO);
-
-   if (!pgd) {
-   kvm_free_hwpgd(hwpgd);
-   return -ENOMEM;
-   }
-
-   /* Plug the HW PGD into the fake one. */
-   for (i = 0; i < PTRS_PER_S2_PGD; i++) {
-   if (KVM_PREALLOC_LEVEL == 1)
-   pgd_populate(NULL, pgd + i,
-(pud_t *)hwpgd + i * PTRS_PER_PUD);
-   else if (KVM_PREALLOC_LEVEL == 2)
-   pud_populate(NULL, pud_offset(pgd, 0) + i,
-(pmd_t *)hwpgd + i * PTRS_PER_PMD);
-   }
-   } else {
-   /*
-* Allocate actual first-level Stage-2 page table used by the
-* hardware for Stage-2 page table walks.
-*/
-   pgd = (pgd_t *)hwpgd;
+   pgd = kvm_setup_fake_pgd(hwpgd);
+   if (IS_ERR(pgd)) {
+   kvm_free_hwpgd(hwpgd);
+   return PTR_ERR(pgd);
}
 
kvm_clean_pgd(pgd);
@@ -820,9 +788,7 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
 
unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
kvm_free_hwpgd(kvm_get_hwpgd(kvm));
-   if (KVM_PREALLOC_LEVEL > 0)
-   kfree(kvm->arch.pgd);
-
+   kvm_free_fake_pgd(kvm->arch.pgd);
kvm->arch.pgd = NULL;
 }
 
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 6150567..2567fe8 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -198,6 +198,49 @@ static inline unsigned int kvm_get_hwpgd_size(void)
return PTRS_PER_S2_PGD * sizeof(pgd_t);
 }
 
+/*
+ * Allocate fake pgd for the page table manipulation macros to
+ * work.  This is not used by the hardware and we have no
+ * alignment requirement for this allocation.
+ */
+static inline pgd_t* kvm_setup_fake_pgd(pgd_t *hwpgd)
+{
+   int i;
+   pgd_t *pgd;
+
+   if (!KVM_PREALLOC_LEVEL)
+   return hwpgd;
+   /*
+* When KVM_PREALLOC_LEVEL==2, we allocate a single page for
+* the PMD and the kernel will use folded pud.
+* When KVM_PREALLOC_LEVEL==1, we allocate 2 consecutive PUD
+* pages.
+*/
+   pgd = kmalloc(PTRS_PER_S2_PGD * sizeof(pgd_t),
+   GFP_KERNEL | __GFP_ZERO);
+
+   if (!pgd)
+   return ERR_PTR(-ENOMEM);
+
+   /* Plug the HW PGD into the fake one. */
+   for (i = 0; i < PTRS_PER_S2_PGD; i++) {
+   if (KVM_PREALLOC_LEVEL == 1)
+   pgd_populate(NULL, pgd + i,
+(pud_t *)hwpgd + i * PTRS_PER_PUD);
+   else if (KVM_PREALLOC_LEVEL == 2)
+   pud_populate(NULL, 

[PATCH 12/14] arm64: Check for selected granule support

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

Ensure that the selected page size is supported by the
CPU(s).

Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/include/asm/sysreg.h |6 ++
 arch/arm64/kernel/head.S|   24 +++-
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index a7f3d4b..e01d323 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -87,4 +87,10 @@ static inline void config_sctlr_el1(u32 clear, u32 set)
 }
 #endif
 
+#define ID_AA64MMFR0_TGran4_SHIFT  28
+#define ID_AA64MMFR0_TGran64_SHIFT 24
+
+#define ID_AA64MMFR0_TGran4_ENABLED0x0
+#define ID_AA64MMFR0_TGran64_ENABLED   0x0
+
 #endif /* __ASM_SYSREG_H */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 01b8e58..0cb04db 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -31,10 +31,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #define __PHYS_OFFSET  (KERNEL_START - TEXT_OFFSET)
@@ -606,9 +607,25 @@ ENDPROC(__secondary_switched)
  *  x27 = *virtual* address to jump to upon completion
  *
  * other registers depend on the function called upon completion
+ * Checks if the selected granule size is supported by the CPU.
  */
+#ifdefined(CONFIG_ARM64_64K_PAGES)
+
+#define ID_AA64MMFR0_TGran_SHIFT   ID_AA64MMFR0_TGran64_SHIFT
+#define ID_AA64MMFR0_TGran_ENABLED ID_AA64MMFR0_TGran64_ENABLED
+
+#else
+
+#define ID_AA64MMFR0_TGran_SHIFT   ID_AA64MMFR0_TGran4_SHIFT
+#define ID_AA64MMFR0_TGran_ENABLED ID_AA64MMFR0_TGran4_ENABLED
+
+#endif
.section".idmap.text", "ax"
 __enable_mmu:
+   mrs x1, ID_AA64MMFR0_EL1
+   ubfxx2, x1, #ID_AA64MMFR0_TGran_SHIFT, 4
+   cmp x2, #ID_AA64MMFR0_TGran_ENABLED
+   b.ne__no_granule_support
ldr x5, =vectors
msr vbar_el1, x5
msr ttbr0_el1, x25  // load TTBR0
@@ -626,3 +643,8 @@ __enable_mmu:
isb
br  x27
 ENDPROC(__enable_mmu)
+
+__no_granule_support:
+   wfe
+   b __no_granule_support
+ENDPROC(__no_granule_support)
-- 
1.7.9.5

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

[PATCH 07/14] arm64: Kconfig: Fix help text about AArch32 support with 64K pages

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

Update the help text for ARM64_64K_PAGES to reflect the reality
about AArch32 support.

Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index d1fb2a3..b247897 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -449,8 +449,8 @@ config ARM64_64K_PAGES
help
  This feature enables 64KB pages support (4KB by default)
  allowing only two levels of page tables and faster TLB
- look-up. AArch32 emulation is not available when this feature
- is enabled.
+ look-up. AArch32 emulation requires applications compiled
+ with 64K aligned segments.
 
 endchoice
 
-- 
1.7.9.5

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

[PATCH 08/14] arm64: kvm: Fix {V}TCR_EL2_TG0 mask

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

{V}TCR_EL2_TG0 is a 2bit wide field, where:

 00 - 4K
 01 - 64K
 10 - 16K

But we use only 1 bit, which has worked well so far since
we never cared about 16K. Fix it for 16K support.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Marc Zyngier 
Cc: Christoffer Dall 
Cc: kvm...@lists.cs.columbia.edu
Acked-by: Mark Rutland 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/include/asm/kvm_arm.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index ac6fafb..52dc9cc 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -98,7 +98,7 @@
 #define TCR_EL2_TBI(1 << 20)
 #define TCR_EL2_PS (7 << 16)
 #define TCR_EL2_PS_40B (2 << 16)
-#define TCR_EL2_TG0(1 << 14)
+#define TCR_EL2_TG0(3 << 14)
 #define TCR_EL2_SH0(3 << 12)
 #define TCR_EL2_ORGN0  (3 << 10)
 #define TCR_EL2_IRGN0  (3 << 8)
@@ -110,7 +110,7 @@
 
 /* VTCR_EL2 Registers bits */
 #define VTCR_EL2_PS_MASK   (7 << 16)
-#define VTCR_EL2_TG0_MASK  (1 << 14)
+#define VTCR_EL2_TG0_MASK  (3 << 14)
 #define VTCR_EL2_TG0_4K(0 << 14)
 #define VTCR_EL2_TG0_64K   (1 << 14)
 #define VTCR_EL2_SH0_MASK  (3 << 12)
-- 
1.7.9.5

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

[PATCH 11/14] arm64: kvm: Rewrite fake pgd handling

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

The existing fake pgd handling code assumes that the stage-2 entry
level can only be one level down that of the host, which may not be
true always(e.g, with the introduction of 16k pagesize).

e.g.
With 16k page size and 48bit VA and 40bit IPA we have the following
split for page table levels:

level:  0   1 2 3
bits : [47] [46 - 36] [35 - 25] [24 - 14] [13 - 0]
 ^   ^ ^
 |   | |
   host entry| x stage-2 entry
 |
IPA -x

The stage-2 entry level is 2, due to the concatenation of 16tables
at level 2(mandated by the hardware). So, we need to fake two levels
to actually reach the hyp page table. This case cannot be handled
with the existing code, as, all we know about is KVM_PREALLOC_LEVEL
which kind of stands for two different pieces of information.

1) Whether we have fake page table entry levels.
2) The entry level of stage-2 translation.

We loose the information about the number of fake levels that
we may have to use. Also, KVM_PREALLOC_LEVEL computation itself
is wrong, as we assume the hw entry level is always 1 level down
from the host.

This patch introduces two seperate indicators :
1) Accurate entry level for stage-2 translation - HYP_PGTABLE_ENTRY_LEVEL -
   using the new helpers.
2) Number of levels of fake pagetable entries. (KVM_FAKE_PGTABLE_LEVELS)

The following conditions hold true for all cases(with 40bit IPA)
1) The stage-2 entry level <= 2
2) Number of fake page-table entries is in the inclusive range [0, 2].

Cc: kvm...@lists.cs.columbia.edu
Cc: christoffer.d...@linaro.org
Cc: marc.zyng...@arm.com
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/include/asm/kvm_mmu.h |  114 --
 1 file changed, 61 insertions(+), 53 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 2567fe8..72cfd9e 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -41,18 +41,6 @@
  */
 #define TRAMPOLINE_VA  (HYP_PAGE_OFFSET_MASK & PAGE_MASK)
 
-/*
- * KVM_MMU_CACHE_MIN_PAGES is the number of stage2 page table translation
- * levels in addition to the PGD and potentially the PUD which are
- * pre-allocated (we pre-allocate the fake PGD and the PUD when the Stage-2
- * tables use one level of tables less than the kernel.
- */
-#ifdef CONFIG_ARM64_64K_PAGES
-#define KVM_MMU_CACHE_MIN_PAGES1
-#else
-#define KVM_MMU_CACHE_MIN_PAGES2
-#endif
-
 #ifdef __ASSEMBLY__
 
 /*
@@ -80,6 +68,26 @@
 #define KVM_PHYS_SIZE  (1UL << KVM_PHYS_SHIFT)
 #define KVM_PHYS_MASK  (KVM_PHYS_SIZE - 1UL)
 
+/*
+ * At stage-2 entry level, upto 16 tables can be concatenated and
+ * the hardware expects us to use concatenation, whenever possible.
+ * So, number of page table levels for KVM_PHYS_SHIFT is always
+ * the number of normal page table levels for (KVM_PHYS_SHIFT - 4).
+ */
+#define HYP_PGTABLE_LEVELS ARM64_HW_PGTABLE_LEVELS(KVM_PHYS_SHIFT - 4)
+/* Number of bits normally addressed by HYP_PGTABLE_LEVELS */
+#define HYP_PGTABLE_SHIFT  ARM64_HW_PGTABLE_LEVEL_SHIFT(HYP_PGTABLE_LEVELS 
+ 1)
+#define HYP_PGDIR_SHIFT
ARM64_HW_PGTABLE_LEVEL_SHIFT(HYP_PGTABLE_LEVELS)
+#define HYP_PGTABLE_ENTRY_LEVEL(4 - HYP_PGTABLE_LEVELS)
+
+/*
+ * KVM_MMU_CACHE_MIN_PAGES is the number of stage2 page table translation
+ * levels in addition to the PGD and potentially the PUD which are
+ * pre-allocated (we pre-allocate the fake PGD and the PUD when the Stage-2
+ * tables use one level of tables less than the kernel.
+ */
+#define KVM_MMU_CACHE_MIN_PAGES(HYP_PGTABLE_LEVELS - 1)
+
 int create_hyp_mappings(void *from, void *to);
 int create_hyp_io_mappings(void *from, void *to, phys_addr_t);
 void free_boot_hyp_pgd(void);
@@ -145,56 +153,41 @@ static inline bool kvm_s2pmd_readonly(pmd_t *pmd)
 #define kvm_pud_addr_end(addr, end)pud_addr_end(addr, end)
 #define kvm_pmd_addr_end(addr, end)pmd_addr_end(addr, end)
 
-/*
- * In the case where PGDIR_SHIFT is larger than KVM_PHYS_SHIFT, we can address
- * the entire IPA input range with a single pgd entry, and we would only need
- * one pgd entry.  Note that in this case, the pgd is actually not used by
- * the MMU for Stage-2 translations, but is merely a fake pgd used as a data
- * structure for the kernel pgtable macros to work.
- */
-#if PGDIR_SHIFT > KVM_PHYS_SHIFT
-#define PTRS_PER_S2_PGD_SHIFT  0
+/* Number of concatenated tables in stage-2 entry level */
+#if KVM_PHYS_SHIFT > HYP_PGTABLE_SHIFT
+#define S2_ENTRY_TABLES_SHIFT  (KVM_PHYS_SHIFT - HYP_PGTABLE_SHIFT)
 #else
-#define PTRS_PER_S2_PGD_SHIFT  (KVM_PHYS_SHIFT - PGDIR_SHIFT)
+#define S2_ENTRY_TABLES_SHIFT  0
 #endif
+#define S2_ENTRY_TABLES(1 << (S2_ENTRY_TABLES_SHIFT))
+
+/* Number of page table levels we fake to reach the hw pgtable for hyp */
+#define KVM_FAKE_PGTABLE_LEVELS(CONFIG_PGTABLE_LEVELS - 
HYP_PGTABLE_LEVELS)
+

[PATCH 14/14] arm64: 36 bit VA

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

36bit VA lets us use 2 level page tables while limiting the
available address space to 64GB.

Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/Kconfig |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8327edf..0407fd3 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -164,6 +164,7 @@ config FIX_EARLYCON_MEM
 
 config PGTABLE_LEVELS
int
+   default 2 if ARM64_16K_PAGES && ARM64_VA_BITS_36
default 2 if ARM64_64K_PAGES && ARM64_VA_BITS_42
default 3 if ARM64_64K_PAGES && ARM64_VA_BITS_48
default 3 if ARM64_4K_PAGES && ARM64_VA_BITS_39
@@ -472,6 +473,10 @@ choice
  space sizes. The level of translation table is determined by
  a combination of page size and virtual address space size.
 
+config ARM64_VA_BITS_36
+   bool "36-bit"
+   depends on ARM64_16K_PAGES
+
 config ARM64_VA_BITS_39
bool "39-bit"
depends on ARM64_4K_PAGES
@@ -491,6 +496,7 @@ endchoice
 
 config ARM64_VA_BITS
int
+   default 36 if ARM64_VA_BITS_36
default 39 if ARM64_VA_BITS_39
default 42 if ARM64_VA_BITS_42
default 47 if ARM64_VA_BITS_47
@@ -564,7 +570,7 @@ config ARCH_WANT_GENERAL_HUGETLB
def_bool y
 
 config ARCH_WANT_HUGE_PMD_SHARE
-   def_bool y if ARM64_4K_PAGES || ARM64_16K_PAGES
+   def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
 
 config HAVE_ARCH_TRANSPARENT_HUGEPAGE
def_bool y
-- 
1.7.9.5

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

[PATCH 09/14] arm64: Cleanup VTCR_EL2 computation

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

No functional changes. Group the common bits for VCTR_EL2
initialisation for better readability. The granule size
and the entry level are controlled by the page size.

Cc: Christoffer Dall 
Cc: Marc Zyngier 
Cc: kvm...@lists.cs.columbia.edu
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/include/asm/kvm_arm.h |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 52dc9cc..dcaf799 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -138,6 +138,9 @@
  * The magic numbers used for VTTBR_X in this patch can be found in Tables
  * D4-23 and D4-25 in ARM DDI 0487A.b.
  */
+#define VTCR_EL2_COMMON_BITS   (VTCR_EL2_SH0_INNER | VTCR_EL2_ORGN0_WBWA | \
+VTCR_EL2_IRGN0_WBWA | VTCR_EL2_T0SZ_40B)
+
 #ifdef CONFIG_ARM64_64K_PAGES
 /*
  * Stage2 translation configuration:
@@ -145,9 +148,8 @@
  * 64kB pages (TG0 = 1)
  * 2 level page tables (SL = 1)
  */
-#define VTCR_EL2_FLAGS (VTCR_EL2_TG0_64K | VTCR_EL2_SH0_INNER | \
-VTCR_EL2_ORGN0_WBWA | VTCR_EL2_IRGN0_WBWA | \
-VTCR_EL2_SL0_LVL1 | VTCR_EL2_T0SZ_40B)
+#define VTCR_EL2_FLAGS (VTCR_EL2_TG0_64K | VTCR_EL2_SL0_LVL1 | \
+VTCR_EL2_COMMON_BITS)
 #define VTTBR_X(38 - VTCR_EL2_T0SZ_40B)
 #else
 /*
@@ -156,9 +158,8 @@
  * 4kB pages (TG0 = 0)
  * 3 level page tables (SL = 1)
  */
-#define VTCR_EL2_FLAGS (VTCR_EL2_TG0_4K | VTCR_EL2_SH0_INNER | \
-VTCR_EL2_ORGN0_WBWA | VTCR_EL2_IRGN0_WBWA | \
-VTCR_EL2_SL0_LVL1 | VTCR_EL2_T0SZ_40B)
+#define VTCR_EL2_FLAGS (VTCR_EL2_TG0_4K | VTCR_EL2_SL0_LVL1 | \
+VTCR_EL2_COMMON_BITS)
 #define VTTBR_X(37 - VTCR_EL2_T0SZ_40B)
 #endif
 
-- 
1.7.9.5

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

[PATCH 02/14] arm64: Handle section maps for swapper/idmap

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

We use section maps with 4K page size to create the
swapper/idmaps. So far we have used !64K or 4K checks
to handle the case where we use the section maps. This
patch adds a symbol to make it clear those cases.

Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/include/asm/kernel-pgtable.h |   31 +-
 arch/arm64/mm/mmu.c |   70 ++-
 2 files changed, 51 insertions(+), 50 deletions(-)

diff --git a/arch/arm64/include/asm/kernel-pgtable.h 
b/arch/arm64/include/asm/kernel-pgtable.h
index 622929d..5876a36 100644
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -19,6 +19,13 @@
 #ifndef __ASM_KERNEL_PGTABLE_H
 #define __ASM_KERNEL_PGTABLE_H
 
+/* With 4K pages, we use section maps. */
+#ifdef CONFIG_ARM64_4K_PAGES
+#define ARM64_SWAPPER_USES_SECTION_MAPS 1
+#else
+#define ARM64_SWAPPER_USES_SECTION_MAPS 0
+#endif
+
 /*
  * The idmap and swapper page tables need some space reserved in the kernel
  * image. Both require pgd, pud (4 levels only) and pmd tables to (section)
@@ -28,26 +35,28 @@
  * could be increased on the fly if system RAM is out of reach for the default
  * VA range, so 3 pages are reserved in all cases.
  */
-#ifdef CONFIG_ARM64_64K_PAGES
-#define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS)
-#else
+#if ARM64_SWAPPER_USES_SECTION_MAPS
 #define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS - 1)
+#else
+#define SWAPPER_PGTABLE_LEVELS (CONFIG_PGTABLE_LEVELS)
 #endif
 
 #define SWAPPER_DIR_SIZE   (SWAPPER_PGTABLE_LEVELS * PAGE_SIZE)
 #define IDMAP_DIR_SIZE (3 * PAGE_SIZE)
 
 /* Initial memory map size */
-#ifdef CONFIG_ARM64_64K_PAGES
-#define SWAPPER_BLOCK_SHIFTPAGE_SHIFT
-#define SWAPPER_BLOCK_SIZE PAGE_SIZE
-#define SWAPPER_TABLE_SHIFTPMD_SHIFT
-#else
+#if ARM64_SWAPPER_USES_SECTION_MAPS
 #define SWAPPER_BLOCK_SHIFTSECTION_SHIFT
 #define SWAPPER_BLOCK_SIZE SECTION_SIZE
 #define SWAPPER_TABLE_SHIFTPUD_SHIFT
+#else
+#define SWAPPER_BLOCK_SHIFTPAGE_SHIFT
+#define SWAPPER_BLOCK_SIZE PAGE_SIZE
+#define SWAPPER_TABLE_SHIFTPMD_SHIFT
 #endif
 
+/* The size of the initial kernel direct mapping */
+#define SWAPPER_INIT_MAP_SIZE  (_AC(1, UL) << SWAPPER_TABLE_SHIFT)
 
 /*
  * Initial memory map attributes.
@@ -55,10 +64,10 @@
 #define SWAPPER_PTE_FLAGS  PTE_TYPE_PAGE | PTE_AF | PTE_SHARED
 #define SWAPPER_PMD_FLAGS  PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S
 
-#ifdef CONFIG_ARM64_64K_PAGES
-#define SWAPPER_MM_MMUFLAGSPTE_ATTRINDX(MT_NORMAL) | SWAPPER_PTE_FLAGS
-#else
+#if ARM64_SWAPPER_USES_SECTION_MAPS
 #define SWAPPER_MM_MMUFLAGSPMD_ATTRINDX(MT_NORMAL) | SWAPPER_PMD_FLAGS
+#else
+#define SWAPPER_MM_MMUFLAGSPTE_ATTRINDX(MT_NORMAL) | SWAPPER_PTE_FLAGS
 #endif
 
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 9211b85..71230488 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -353,14 +354,11 @@ static void __init map_mem(void)
 * memory addressable from the initial direct kernel mapping.
 *
 * The initial direct kernel mapping, located at swapper_pg_dir, gives
-* us PUD_SIZE (4K pages) or PMD_SIZE (64K pages) memory starting from
-* PHYS_OFFSET (which must be aligned to 2MB as per
-* Documentation/arm64/booting.txt).
+* us PUD_SIZE (with SECTION maps, i.e, 4K) or PMD_SIZE (without
+* SECTION maps, i.e, 64K pages) memory starting from PHYS_OFFSET
+* (which must be aligned to 2MB as per 
Documentation/arm64/booting.txt).
 */
-   if (IS_ENABLED(CONFIG_ARM64_64K_PAGES))
-   limit = PHYS_OFFSET + PMD_SIZE;
-   else
-   limit = PHYS_OFFSET + PUD_SIZE;
+   limit = PHYS_OFFSET + SWAPPER_INIT_MAP_SIZE;
memblock_set_current_limit(limit);
 
/* map all the memory banks */
@@ -371,21 +369,24 @@ static void __init map_mem(void)
if (start >= end)
break;
 
-#ifndef CONFIG_ARM64_64K_PAGES
-   /*
-* For the first memory bank align the start address and
-* current memblock limit to prevent create_mapping() from
-* allocating pte page tables from unmapped memory.
-* When 64K pages are enabled, the pte page table for the
-* first PGDIR_SIZE is already present in swapper_pg_dir.
-*/
-   if (start < limit)
-   start = ALIGN(start, PMD_SIZE);
-   if (end < limit) {
-   limit = end & PMD_MASK;
-   memblock_set_current_limit(limit);
+   if (ARM64_SWAPPER_USES_SECTION_MAPS) {
+   /*
+* For the first memory bank align the start address and
+  

[PATCH 13/14] arm64: Add 16K page size support

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

This patch turns on the 16K page support in the kernel. We
support 48bit VA (4 level page tables) and 47bit VA (3 level
page tables).

Cc: Mark Rutland 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Steve Capper 
Signed-off-by: Suzuki K. Poulose 
---
 arch/arm64/Kconfig   |   25 -
 arch/arm64/include/asm/fixmap.h  |4 +++-
 arch/arm64/include/asm/kvm_arm.h |   12 
 arch/arm64/include/asm/page.h|2 ++
 arch/arm64/include/asm/sysreg.h  |2 ++
 arch/arm64/include/asm/thread_info.h |2 ++
 arch/arm64/kernel/head.S |7 ++-
 arch/arm64/mm/proc.S |4 +++-
 8 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b247897..8327edf 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -167,7 +167,8 @@ config PGTABLE_LEVELS
default 2 if ARM64_64K_PAGES && ARM64_VA_BITS_42
default 3 if ARM64_64K_PAGES && ARM64_VA_BITS_48
default 3 if ARM64_4K_PAGES && ARM64_VA_BITS_39
-   default 4 if ARM64_4K_PAGES && ARM64_VA_BITS_48
+   default 3 if ARM64_16K_PAGES && ARM64_VA_BITS_47
+   default 4 if !ARM64_64K_PAGES && ARM64_VA_BITS_48
 
 source "init/Kconfig"
 
@@ -444,6 +445,13 @@ config ARM64_4K_PAGES
help
  This feature enables 4KB pages support.
 
+config ARM64_16K_PAGES
+   bool "16KB"
+   help
+ The system will use 16KB pages support. AArch32 emulation
+ requires applications compiled with 16K(or multiple of 16K)
+ aligned segments.
+
 config ARM64_64K_PAGES
bool "64KB"
help
@@ -457,6 +465,7 @@ endchoice
 choice
prompt "Virtual address space size"
default ARM64_VA_BITS_39 if ARM64_4K_PAGES
+   default ARM64_VA_BITS_47 if ARM64_16K_PAGES
default ARM64_VA_BITS_42 if ARM64_64K_PAGES
help
  Allows choosing one of multiple possible virtual address
@@ -471,6 +480,10 @@ config ARM64_VA_BITS_42
bool "42-bit"
depends on ARM64_64K_PAGES
 
+config ARM64_VA_BITS_47
+   bool "47-bit"
+   depends on ARM64_16K_PAGES
+
 config ARM64_VA_BITS_48
bool "48-bit"
 
@@ -480,6 +493,7 @@ config ARM64_VA_BITS
int
default 39 if ARM64_VA_BITS_39
default 42 if ARM64_VA_BITS_42
+   default 47 if ARM64_VA_BITS_47
default 48 if ARM64_VA_BITS_48
 
 config CPU_BIG_ENDIAN
@@ -550,7 +564,7 @@ config ARCH_WANT_GENERAL_HUGETLB
def_bool y
 
 config ARCH_WANT_HUGE_PMD_SHARE
-   def_bool y if ARM64_4K_PAGES
+   def_bool y if ARM64_4K_PAGES || ARM64_16K_PAGES
 
 config HAVE_ARCH_TRANSPARENT_HUGEPAGE
def_bool y
@@ -587,6 +601,7 @@ config XEN
 config FORCE_MAX_ZONEORDER
int
default "14" if (ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE)
+   default "12" if (ARM64_16K_PAGES && TRANSPARENT_HUGEPAGE)
default "11"
 
 menuconfig ARMV8_DEPRECATED
@@ -773,9 +788,9 @@ config COMPAT
  the user helper functions, VFP support and the ptrace interface are
  handled appropriately by the kernel.
 
- If you also enabled CONFIG_ARM64_64K_PAGES, please be aware that you
- will only be able to execute AArch32 binaries that were compiled with
- 64k aligned segments.
+ If you use a page size other than 4KB(i.e, 16KB or 64KB), please be 
aware
+ that you will only be able to execute AArch32 binaries that were 
compiled
+ with page size aligned segments.
 
  If you want to execute 32-bit userspace applications, say Y.
 
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index c0739187..f44a390 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -55,8 +55,10 @@ enum fixed_addresses {
 * Temporary boot-time mappings, used by early_ioremap(),
 * before ioremap() is functional.
 */
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdefined(CONFIG_ARM64_64K_PAGES)
 #define NR_FIX_BTMAPS  4
+#elif  defined (CONFIG_ARM64_16K_PAGES)
+#define NR_FIX_BTMAPS  16
 #else
 #define NR_FIX_BTMAPS  64
 #endif
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index dcaf799..4d6a022 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -113,6 +113,7 @@
 #define VTCR_EL2_TG0_MASK  (3 << 14)
 #define VTCR_EL2_TG0_4K(0 << 14)
 #define VTCR_EL2_TG0_64K   (1 << 14)
+#define VTCR_EL2_TG0_16K   (2 << 14)
 #define VTCR_EL2_SH0_MASK  (3 << 12)
 #define VTCR_EL2_SH0_INNER (3 << 12)
 #define VTCR_EL2_ORGN0_MASK(3 << 10)
@@ -134,6 +135,8 @@
  *
  * Note that when using 4K pages, we concatenate two first level page tables
  * together.
+ * With 16K pages, we concatenate 16 first level page tables and enter at
+ * level 2.
  *
  * The magic numbers used for VTTBR_X in this patch can be found in 

[PATCH 00/14] arm64: 16K translation granule support

[Suzuki K. Poulose]

From: "Suzuki K. Poulose" 

This series enables the 16K page size support on Linux for arm64.
This series adds support for 48bit VA(4 level), 47bit VA(3 level) and
36bit VA(2 level) with 16K. 16K was a late addition to the architecture
and is not implemented by all CPUs. Added a check to ensure the
selected granule size is supported by the CPU, failing which the CPU
won't proceed with booting.

KVM bits have been tested on a fast model with GICv3 using Andre's kvmtool
with gicv3 support[1].

Patches 1-7 cleans up the kernel page size handling code.
Patches 8-11 Fixes some issues with the KVM bits, mainly the fake PGD
 handling code.
Patch 12Adds a check to ensure the CPU supports the selected granule size.
Patch 13-14 Adds the 16k page size support bits.

This series applies on top of for-next/core branch of the aarch64 tree and is
also available here:

git://linux-arm.org/linux-skp.git  16k/v1

[1] git://linux-arm.org/kvmtool.git gicv3/v4

TODO:
 1) Testing on a silicon
 2) Analyse the performance of HugePages with 16K (32MB) on a
silicon.
 3) SMMU driver

Suzuki K. Poulose (14):
  arm64: Move swapper pagetable definitions
  arm64: Handle section maps for swapper/idmap
  arm64: Introduce helpers for page table levels
  arm64: Calculate size for idmap_pg_dir at compile time
  arm64: Handle 4 level page table for swapper
  arm64: Clean config usages for page size
  arm64: Kconfig: Fix help text about AArch32 support with 64K pages
  arm64: kvm: Fix {V}TCR_EL2_TG0 mask
  arm64: Cleanup VTCR_EL2 computation
  arm: kvm: Move fake PGD handling to arch specific files
  arm64: kvm: Rewrite fake pgd handling
  arm64: Check for selected granule support
  arm64: Add 16K page size support
  arm64: 36 bit VA

 arch/arm/include/asm/kvm_mmu.h  |7 ++
 arch/arm/kvm/mmu.c  |   44 ++
 arch/arm64/Kconfig  |   37 +++--
 arch/arm64/Kconfig.debug|2 +-
 arch/arm64/include/asm/boot.h   |1 +
 arch/arm64/include/asm/fixmap.h |4 +-
 arch/arm64/include/asm/kernel-pgtable.h |   77 ++
 arch/arm64/include/asm/kvm_arm.h|   29 +--
 arch/arm64/include/asm/kvm_mmu.h|  135 +--
 arch/arm64/include/asm/page.h   |   20 +
 arch/arm64/include/asm/pgtable-hwdef.h  |   15 +++-
 arch/arm64/include/asm/sysreg.h |8 ++
 arch/arm64/include/asm/thread_info.h|4 +-
 arch/arm64/kernel/head.S|   71 +---
 arch/arm64/kernel/vmlinux.lds.S |1 +
 arch/arm64/mm/mmu.c |   70 +++-
 arch/arm64/mm/proc.S|4 +-
 17 files changed, 337 insertions(+), 192 deletions(-)
 create mode 100644 arch/arm64/include/asm/kernel-pgtable.h

-- 
1.7.9.5

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

Re: [PATCH v2] Remove unselectable rule for arm-exynos-cpufreq.o

[Viresh Kumar]

On 13-08-15, 13:28, Jonas Rabenstein wrote:
> Commit "cpufreq: exynos: remove Exynos4x12 specific cpufreq driver
> support" deleted option ARM_EXYNOS_CPUFREQ but missed to delete a rule
> in drivers/cpufreq/Makefile which depends on that option.
> 
> Remove unselectable rule for arm-exynos-cpufreq.o from
> drivers/cpufreq/Makefile.
> 
> Signed-off-by: Jonas Rabenstein 
> ---
> I found this inconsistency using the undertaker and
> undertaker-checkpatch tools (https://undertaker.cs.fau.de/).
> 
>  drivers/cpufreq/Makefile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index bbc4a9f..958be2b 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -52,7 +52,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += 
> arm_big_little_dt.o
>  
>  obj-$(CONFIG_ARCH_DAVINCI)   += davinci-cpufreq.o
>  obj-$(CONFIG_UX500_SOC_DB8500)   += dbx500-cpufreq.o
> -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += arm-exynos-cpufreq.o
>  obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
>  obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)   += highbank-cpufreq.o
>  obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ)  += hisi-acpu-cpufreq.o

Acked-by: Viresh Kumar 

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH, RFC 2/2] dax: use range_lock instead of i_mmap_lock

[Jan Kara]

On Wed 12-08-15 07:48:22, Dave Chinner wrote:
> On Tue, Aug 11, 2015 at 04:51:22PM +, Wilcox, Matthew R wrote:
> > The race that you're not seeing is page fault vs page fault.  Two
> > threads each attempt to store a byte to different locations on the
> > same page.  With a read-mutex to exclude truncates, each thread
> > calls ->get_block.  One of the threads gets back a buffer marked
> > as BH_New and calls memset() to clear the page.  The other thread
> > gets back a buffer which isn't marked as BH_New and simply inserts
> > the mapping, returning to userspace, which stores the byte ...
> > just in time for the other thread's memset() to write a zero over
> > the top of it.
> 
> So, this is not a truncate race that the XFS MMAPLOCK solves.
> 
> However, that doesn't mean that the DAX code needs to add locking to
> solve it. The race here is caused by block initialisation being
> unserialised after a ->get_block call allocates the block (which the
> filesystem serialises via internal locking). Hence two simultaneous
> ->get_block calls to the same block is guaranteed to have the DAX
> block initialisation race with the second ->get_block call that says
> the block is already allocated.
> 
> IOWs, the way to handle this is to have the ->get_block call handle
> the block zeroing for new blocks instead of doing it after the fact
> in the generic DAX code where there is no fine-grained serialisation
> object available. By calling dax_clear_blocks() in the ->get_block
> callback, the filesystem can ensure that the second racing call will
> only make progress once the block has been fully initialised by the
> first call.
> 
> IMO the fix is - again - to move the functionality into the
> filesystem where we already have the necessary exclusion in place to
> avoid this race condition entirely.

I'm somewhat sad to add even more functionality into the already loaded
block mapping interface - we can already allocate delalloc blocks, unwritten
blocks, uninitialized blocks, and now also pre-zeroed blocks. But I agree
fs already synchronizes block allocation for a given inode so adding the
pre-zeroing there is pretty easy. Also getting rid of unwritten extent
handling from DAX code is a nice bonus so all in all I'm for this approach.

Honza
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] Remove unselectable rule for arm-exynos-cpufreq.o

[Jonas Rabenstein]

Commit "cpufreq: exynos: remove Exynos4x12 specific cpufreq driver
support" deleted option ARM_EXYNOS_CPUFREQ but missed to delete a rule
in drivers/cpufreq/Makefile which depends on that option.

Remove unselectable rule for arm-exynos-cpufreq.o from
drivers/cpufreq/Makefile.

Signed-off-by: Jonas Rabenstein 
---
I found this inconsistency using the undertaker and
undertaker-checkpatch tools (https://undertaker.cs.fau.de/).

 drivers/cpufreq/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index bbc4a9f..958be2b 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ)   += 
arm_big_little_dt.o
 
 obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += arm-exynos-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)   += exynos5440-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
 obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ)+= hisi-acpu-cpufreq.o
-- 
2.5.0

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

Re: [PATCH] pinctrl: cherryview: Serialize all register access

[Linus Walleij]

On Mon, Aug 3, 2015 at 11:46 AM, Mika Westerberg
 wrote:

> There is a hardware issue in Intel Braswell/Cherryview where concurrent
> GPIO register access might results reads of 0x and writes might get
> dropped.
>
> Prevent this from happening by taking the serializing lock for all places
> where it is possible that more than one thread might be accessing the
> hardware concurrently.
>
> Signed-off-by: Mika Westerberg 

Patch applied.

When we are on the topic of this spinlock, I noticed that you
take it in some IRQ functions:

static void chv_gpio_irq_ack(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
struct chv_pinctrl *pctrl = gpiochip_to_pinctrl(gc);
int pin = chv_gpio_offset_to_pin(pctrl, irqd_to_hwirq(d));
u32 intr_line;

spin_lock(>lock);
(...)

The Realtime tree have recently started to push raw spinlocks
into GPIO drivers that handle IRQs. Can you look into this
for the Intel drivers, I think maybe this needs to be a raw
spinlock to play nicely with realtime.

Cf:
http://marc.info/?l=linux-gpio=143749603401220=2

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] x86/KASAN updates for 4.3

[Will Deacon]

On Thu, Aug 13, 2015 at 12:02:26PM +0100, Andrey Ryabinin wrote:
> 2015-08-13 12:01 GMT+03:00 Will Deacon :
> > Yes please, works for me! If we're targetting 4.3, then please can you base
> > on 4.2-rc4, as that's what our current arm64 queue is using?
> >
> 
> Does this mean that we are targeting arm64 part for 4.3 too?

It depends on how well it merges with our current queue and whether it
holds up to regression testing. The patches have been reviewed, so I'm
comfortable with the content, but we're not at a stage where we can debug
and fix any failures that might crop up from the merge.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 00/21] Compile-time stack validation

[Josh Poimboeuf]

On Wed, Aug 12, 2015 at 04:24:49PM -0500, Chris J Arges wrote:
> I still get build failures and I've pared it down to x86_64 defconfig plus:
> CONFIG_MODVERSIONS=y
> CONFIG_STACK_VALIDATION=y
> 
> And it seems like some modules may get the .tmp_foo.o treatment while
> others end up foo.o so something like the following will not work:
> 
> cmd_stackvalidate = $(if $(patsubst n%,, \
> $(STACKVALIDATE_$(basetarget).o)$(STACKVALIDATE)y), \
> $(__stackvalidate) $(nofp) "$(@D)/.tmp_$(@F)";)

Does this fix it?

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index ec96c51..0181915 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -263,8 +263,8 @@ endif # CONFIG_STACK_VALIDATION
 define rule_cc_o_c
$(call echo-cmd,checksrc) $(cmd_checksrc) \
$(call echo-cmd,cc_o_c) $(cmd_cc_o_c);\
-   $(cmd_stackvalidate)  \
$(cmd_modversions)\
+   $(cmd_stackvalidate)  \
$(call echo-cmd,record_mcount)\
$(cmd_record_mcount)  \
scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,cc_o_c)' >\
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] at91: defconfig for 4.3 #2

[Alexandre Belloni]

On 13/08/2015 at 12:09:38 +0200, Olof Johansson wrote :
> On Fri, Aug 07, 2015 at 06:27:54PM +0200, Alexandre Belloni wrote:
> > Arnd, Olof, Kevin,
> > 
> > A little defconfig update. That will probably be all for this cycle.
> > 
> > Thanks, bye,
> > 
> > 
> > The following changes since commit eff7f41572a645bf14a96a6f844be4f1c88cd9dd:
> > 
> >   ARM: at91: at91_dt_defconfig: enable ISI and ov2640 support (2015-07-30 
> > 14:17:31 +0200)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> > tags/at91-ab-defconfig2
> > 
> > for you to fetch changes up to ea7bf603fd494391acc1f42acbfc34260b965c44:
> > 
> >   ARM: at91/defconfig: at91_dt: remove ARM_AT91_ETHER (2015-08-07 12:07:50 
> > +0200)
> 
> Nicolas had sent me one patch which you've also included here but it's not in
> the pull request ("enable ISI and ov2640 support"). That caused a conflict
> here, so to avoid having the patch in the tree twice I instead also directly
> applied your patches from this branch instead of merging.
> 
> Sorry about that, it started due to Nicolas sending the discrete patch to us.
> So it seems like we'll apply at91 defconfig updates directly this release, in
> case there are any more. No big deal I hope. :)
> 

That's not a big deal and there will most probably be all for that cycle
anyway.

However, I'm wondering how I should have done. From the PR, if you get
eff7f41572a645bf14a96a6f844be4f1c88cd9dd..tags/at91-ab-defconfig2, it
correctly excludes "enable ISI and ov2640 support" so I was thinking it
was fine.
Be cause the first patch was taken as a patch, should I have prepared a
branch without it?

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: UniPhier: PH1-Pro5: add I2C ch6 pin-mux setting

[Linus Walleij]

On Sat, Aug 1, 2015 at 5:38 AM, Masahiro Yamada
 wrote:

> The initial version of this driver missed to add I2C ch6 pin-muxing.
>
> Signed-off-by: Masahiro Yamada 

Patch applied.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory

[Will Deacon]

On Thu, Aug 13, 2015 at 10:24:32AM +0100, Matt Fleming wrote:
> On Thu, 13 Aug, at 10:19:17AM, Ingo Molnar wrote:
> > * Matt Fleming  wrote:
> > 
> > > From: "Jonathan (Zhixiong) Zhang" 
> > > 
> > > With ACPI APEI firmware first handling, generic hardware error
> > > record is updated by firmware in GHES memory region. On an arm64
> > > platform, firmware updates GHES memory region with uncached
> > > access attribute, and then Linux reads stale data from cache.
> > 
> > So this paragraph does not parse for me ...
> > 
> > If it tries to explain a bug it falls very short of doing a proper job of 
> > that.
> 
> I'll let Jonathan provide more details but I understood the problem to
> be a cache (in)coherency issue.
> 
> The kernel currently maps the the GHES memory region as cacheable
> (PAGE_KERNEL) for all architectures. This memory region is used as a
> communication buffer for reporting hardware errors from the firmware to
> kernel. Essentially the firmware writes hardware error records there,
> trigger an NMI/interrupt, and the GHES driver goes off and grabs the
> error record from the GHES region.
> 
> Since the firmware gets first crack at inspecting the error this
> mechanism is referred to as "firmware first" in the ACPI spec.
> 
> Now, there's a mismatch on arm64 platforms between how the kernel maps
> the GHES region (PAGE_KERNEL) and how the firmware maps it
> (EFI_MEMORY_UC, i.e. uncacheable), leading to the possibility of the
> kernel GHES driver reading stale data from the cache when it receives
> the NMI/interrupt.
> 
> As for exactly why the arm64 firmware uses an uncached mapping, I
> presume it's to avoid relying on the kernel to get the necessary cache
> flushing correct.
> 
> The proposed solution is to query the EFI memory map to ensure the
> kernel uses a compatible mapping.
> 
> None of this should affect x86, it still uses PAGE_KERNEL because we're
> yet to see any hardware that has an EFI memory map entry for the GHES
> region that's incompatible with PAGE_KERNEL.
> 
> Jonathan, would you like to provide more details?

FWIW, that matches my understanding of the problem too. The ARM architecture
refers to this situation as "mismatched memory attributes" and typically
requires some explicit cache maintenance to achieve portable behaviour in
this scenario.

It's much better to avoid the mismatch in the first place, if you can,
which is what this is all about.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] xen: bug fixes for 4.2-rc6

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.2-rc6-tag

xen: bug fixes for 4.2-rc6

- - Revert a fix from 4.2-rc5 that was causing lots of WARNING spam.
- - Fix a memory leak affecting backends in HVM guests.
- - Fix PV domU hang with certain configurations.

Thanks.

David

 arch/x86/xen/Makefile|  4 ++--
 arch/x86/xen/xen-ops.h   |  6 ++---
 drivers/xen/events/events_base.c | 10 
 drivers/xen/events/events_fifo.c | 45 
 drivers/xen/events/events_internal.h |  7 --
 drivers/xen/xenbus/xenbus_client.c   |  4 +++-
 6 files changed, 16 insertions(+), 60 deletions(-)

David Vrabel (1):
  Revert "xen/events/fifo: Handle linked events when closing a port"

Jason A. Donenfeld (1):
  x86/xen: build "Xen PV" APIC driver for domU as well

Julien Grall (1):
  xen/xenbus: Don't leak memory when unmapping the ring on HVM backend
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVzHvNAAoJEFxbo/MsZsTRRScH/RANDlEDyDQEj0I1YQ5oc3mx
p1B73DZ/wblB4Y07dZVgANXHORa6aaprLFns0WpnaW+PSYS+flQ3D9OI2W7zzRcE
s9AZojXLbwUbAZkQeeUIEsyp01WPJ7b3rvBlZ/gzylPCCVKfe56QoguqFoOz3NLG
N5LBWTG9AmfRrccYl+lL/jlSiok8UdsBnl4RjfpWGKRHUYd/yk0tdMPZwgN+3KPm
MVyX5OoJdVGz7CVp9dJGgKOR3OQGK7eGw1nzQzHMy6iwxcxlhUYc7QJOZYQmwWFi
aY0qrZGdZslSotVhRsFTlj/52kDHd64w5UlmOelmdRWFwOSPQlllO1K7O5gVVYo=
=qQy/
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/4] gpio: brcmstb: support wakeup from S5 cold boot

[Linus Walleij]

On Sat, Aug 1, 2015 at 3:17 AM, Gregory Fong  wrote:

> For wake from S5, we need to:
> - register a reboot handler
> - set wakeup capability before requesting IRQ so wakeup count is
>   incremented
> - mask all GPIO IRQs and clear any pending interrupts during driver
>   probe to since no driver will yet be registered to handle any IRQs
>   carried over from boot at that time, and it's possible that the
>   booted kernel does not request the same IRQ anyway.
>
> This means that /sys/.../power/wakeup_count is valid at boot time, and
> we can properly account for S5 wakeup stats. e.g.:
>
>   ### After waking from S5 from a GPIO key
>   # cat /sys/bus/platform/drivers/brcmstb-gpio/f04172c0.gpio/power/wakeup
>   enabled
>   # cat 
> /sys/bus/platform/drivers/brcmstb-gpio/f04172c0.gpio/power/wakeup_count
>   1
>
> Signed-off-by: Gregory Fong 
> ---
> v4: rename __brcmstb_gpio_irq_set_wake() to brcmstb_gpio_priv_set_wake().

Patch applied.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/4] gpio: brcmstb: Add interrupt and wakeup source support

[Linus Walleij]

On Sat, Aug 1, 2015 at 3:17 AM, Gregory Fong  wrote:

> Uses the gpiolib irqchip helpers.  For this to work, the irq setup
> function is called once per bank instead of once per device.  Note
> that all known uses of this block have a BCM7120 L2 interrupt
> controller as a parent.  Supports interrupts for all GPIOs.
>
> In the IRQ handler, we check for raised IRQs for invalid GPIOs and
> warn (ratelimited) if they're encountered.
>
> Also, several drivers (e.g. gpio-keys) allow for GPIOs to be
> configured as wakeup sources, and this GPIO controller supports that
> through a separate interrupt path.
>
> The de-facto standard DT property "wakeup-source" is checked, since
> that indicates whether the GPIO controller hardware can wake.  Uses
> the IRQCHIP_MASK_ON_SUSPEND irq_chip flag because UPG GIO doesn't have
> any of its own wakeup source configuration.
>
> Aside regarding gpiolib irqchip helpers: It wasn't obvious (to me)
> that you can have multiple chained irqchips and associated IRQ domains
> for a single parent IRQ, and as long as the xlate function is written
> correctly, a GPIO IRQ request end up checking the correct domain and
> will get associated with the correct IRQ.  What helps make this clear
> is to read
>   drivers/gpio/gpiolib-of.c:
>- of_gpiochip_find_and_xlate()
>- of_get_named_gpiod_flags()
>   drivers/gpio/gpiolib.c:
>- gpiochip_find()
>
> Signed-off-by: Gregory Fong 
> ---
> v4:
> - when checking parent_irq, use <= 0 or > 0 since 0 is NO_IRQ.

Patch applied, but:


> +   if (of_property_read_bool(np, "interrupt-controller")) {
> +   priv->parent_irq = platform_get_irq(pdev, 0);
> +   if (priv->parent_irq <= 0) {
> +   dev_err(dev, "Couldn't get IRQ");
> +   return -ENOENT;
> +   }
> +   } else {
> +   priv->parent_irq = -ENOENT;
> +   }
> +
> if (brcmstb_gpio_sanity_check_banks(dev, np, res))
> return -EINVAL;

This patch does not apply cleanly because the version in my
tree has INIT_LIST_HEAD(>bank_list);
before the sanity check.

I applied it manually, but check that things are working right.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/6] mailbox: Add generic mechanism for testing Mailbox Controllers

[Jassi Brar]

On Thu, Aug 13, 2015 at 4:30 PM, Lee Jones  wrote:
> On Thu, 13 Aug 2015, Jassi Brar wrote:
>
>> On Thu, Aug 13, 2015 at 3:53 PM, Lee Jones  wrote:
>> > On Thu, 13 Aug 2015, Jassi Brar wrote:
>> >
>> >> On Thu, Aug 13, 2015 at 2:49 PM, Lee Jones  wrote:
>> >> > On Thu, 13 Aug 2015, Jassi Brar wrote:
>> >>
>> >> >> >> > +
>> >> >> >> > +static void mbox_test_prepare_message(struct mbox_client 
>> >> >> >> > *client, void *message)
>> >> >> >> > +{
>> >> >> >> > +   struct mbox_test_device *tdev = 
>> >> >> >> > dev_get_drvdata(client->dev);
>> >> >> >> > +
>> >> >> >> > +   if (tdev->mmio)
>> >> >> >> > +   memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
>> >> >> >> >
>> >> >> >> This is unlikely to work. Those platforms that need to send a 2 part
>> >> >> >> message, they do :
>> >> >> >> (a) Signal/Command/Target code via some controller register (via
>> >> >> >> mbox_send_message).
>> >> >> >> (b) Setup the payload in Shared-Memory (via tx_prepare).
>> >> >> >>
>> >> >> >> This test driver assumes both are the same. I think you have to
>> >> >> >> declare something like
>> >> >> >
>> >> >> > This driver assumes that the framework will call client->tx_prepare()
>> >> >> > first, which satisfies (b).  It then assumes controller->send_data()
>> >> >> > will be invoked, which will send the platform specific
>> >> >> > signal/command/target code, which then satisfies (a).
>> >> >> >
>> >> >> Yeah, but what would be that code? Who provides that?
>> >> >>
>> >> >> > In what way does it assume they are the same?
>> >> >> >
>> >> >> notice the 'message' pointer in
>> >> >> mbox_send_message(tdev->tx_channel, message);
>> >> >> and
>> >> >> memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
>> >> >>
>> >> >> >> struct mbox_test_message { /* same for TX and RX */
>> >> >> >>   unsigned sig_len;
>> >> >> >>   void *signal;   /* rx/tx via mailbox api */
>> >> >> >>   unsigned pl_len;
>> >> >> >>   void *payload;   /* rx/tx via shared-memory */
>> >> >> >> };
>> >> >> >
>> >> >> > How do you think this should be set and use these?
>> >> >> >
>> >> >> The userspace would want to specify the command code (32bits or not)
>> >> >> that would be passed via the fifo/register of the controller. So we
>> >> >> need signal[]
>> >> >>
>> >> >> The data to be passed via share-memory could be provided by userspace
>> >> >> via the payload[] array.
>> >> >
>> >> > Okay, so would the solution be two userspace files 'signal' and
>> >> > 'message', so in the case of a client specified signal we can write it
>> >> > into there first.
>> >> >
>> >> > echo 255  > signal
>> >> > echo test > message
>> >> >
>> >> > ... or in the case where no signal is required, or the controller
>> >> > driver taking care of it, we just don't write anything to signal?
>> >> >
>> >> file_operations.write() should parse signal and message, coming from
>> >> userspace, into a local structure before routing them via
>> >> mbox_send_message and tx_prepare respectively.
>> >
>> > Okay.  So before I code this up we should agree on syntax.
>> >
>> > How would you like to represent the break between signal and message?
>> > Obviously ' ' would be a bad idea, as some clients may want to send
>> > messages with white space contained.  How about '\t' or '\n'?
>> >
>> Yeah, I am not a fan of markers and flags either.
>>
>> Maybe we should share with userspace
>>   struct mbox_test_message { /* same for TX and RX */
>>unsigned sig_len;
>>void __user *signal;/* rx/tx via mailbox api */
>>unsigned pl_len;
>>void __user *payload;/* rx/tx via shared-memory */
>>   };
>>
>> First copy_from_user the structure of length sizof(struct
>> mbox_test_message) and then copy_from_user length sig_len and pl_len
>> from signal[] and payload[] respectively (usually ioctls would carry
>> such data).
>
> Simplicity and ease of use should be the goals here.  Testers should
> not have to write applications to use this driver.  Can we come up
> with a simple/effective method that uses SYSFS/DEBUGFS please?
>
> The easiest way I can think of which avoids markers/separators AND the
> requirement for users to have to write applications is to have two
> files, 'signal' and 'message' as mentioned before.  Once both are
> populated I can get this driver to draft the message appropriately and
> fire it off.
>
And then write to more files for RX data? ... which should also be in
the form of 'signal' and 'message'.

BTW like for spi there is a stock application in
Documentation/spi/spidev_test.c we could do the same?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

13.08.2015 01:00, Andy Lutomirski пишет:

On Wed, Aug 12, 2015 at 2:50 PM, Stas Sergeev  wrote:

13.08.2015 00:37, Andy Lutomirski пишет:


On Wed, Aug 12, 2015 at 1:55 PM, Stas Sergeev  wrote:

12.08.2015 23:47, Andy Lutomirski пишет:


On Wed, Aug 12, 2015 at 1:45 PM, Stas Sergeev  wrote:

12.08.2015 23:28, Andy Lutomirski пишет:


On Wed, Aug 12, 2015 at 1:14 PM, Stas Sergeev  wrote:

12.08.2015 23:01, Andy Lutomirski пишет:

On Wed, Aug 12, 2015 at 12:55 PM, Stas Sergeev  wrote:

12.08.2015 22:20, Andy Lutomirski пишет:

current kernels, it stays switched.  If we change this, it won't
stay
switched.  Even ignoring old ABI, it's not really clear to me what
the
right thing to do is.

There can be the following cases:
- switch_userspace_thread() switches fs to non-zero selector
- switch_userspace_thread() switches the fs base via syscall
- switch_userspace_thread() switches fs in sigcontext
- switch_userspace_thread() switches fs_base in sigcontext (???)
What exactly case do you have in mind?
I'd say, the way x86_32 is doing things - is good, but the
bases... perhaps, in ideal world, they should be a part of
the sigcontext as well?

Any of the above.  What do you want the kernel to do, and how does
the
kernel know you want to do that?  The kernel has to pick *some*
semantics here.

Assuming the bases are made the part of a sigcontext,
I'd say there would be no ambiguities remained at all:
whatever you change in a sigcontext, will be "applied" by
the sigreturn(). Whatever you put in the registers
(either segregs or MSRs), is valid until sigreturn(), then
forgotten forever.
The mess only comes in when some things are part of
sigcontext and some are not. But if you have _all_ things
accessable in sigcontext, then the user has a way of expressing
his needs very clearly: he'll either touch sigcontext or direct
values, depending on what he need.

Is this right?

Maybe, except that doing this might break existing code (Wine and Java
come to mind).  I'm not really sure.

Yes, but that's why I was talking about some new
flag. Maybe a new sigaction() flag? Or something else that
will allow the user to request explicitly the new handling
where the things are all switched by the kernel. Then
the old programs that don't use that flag, will remain
unaffected. I realize this may be a lot of work... But please
note that there will be no more a chance like this one,
when things are already badly broken. :)

I think that, with my patch, we get the best of both worlds.  We keep
the old behavior in cases where it would work, and we switch to the
new behavior in cases where the old behavior would result in killing
the task.

But I mean also fs/TLS.
There is a chance now to fix things for good, all at once. :)
With such an ss patch applied to stable, there will be no more
such a chance ever. What's your opinion on the possibility of
fixing the TLS problem?
Also I am not sure about the sigreturn()'s detection: is it
a subject of the subsequent patch, or you dropped an idea?

I think these things shouldn't be conflated.  If we can fix it
transparently (i.e. if my patch works), then I think we should do
something like my patch.

OK.
I'll try to test the patch tomorrow, but I think the sigreturn()'s
capability detection is still needed to easily replace the iret trampoline
in userspace (without generating a signal and testing by hands).
Can of course be done with a run-time kernel version check...

That feature is so specialized that I think you should just probe it.

void foo(...) {
   sigcontext->ss = 7;
}

modify_ldt(initialize descriptor 0);
sigaction(SIGUSR1, foo, SA_SIGINFO);
if (ss == 7)
   yay;

Fortunately, all kernels that restore ss also have espfix64, so you
don't need to worry about esp[31:16] corruption on those kernels
either.

Unfortunately, this doesn't help.
I made a simple patch that checks the kernel version:
https://github.com/stsp/dosemu2/commit/098413ef8de98972ca795e078351ae9f3cc07ffe
but iret is still used when switching to DOS code from dosemu
code, rather than from signal handler. So espfix64 doesn't help
much.
I guess the only real solution to this would be to "rewrite" dosemu
so that the DOS code is run in a clone(CLONE_VM) separate process...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 9/8] don't fool lockdep in freeze_super() and thaw_super() paths

[Jan Kara]

On Wed 12-08-15 15:11:38, Oleg Nesterov wrote:
> On 08/11, Oleg Nesterov wrote:
> >
> > The only essential change is that I dropped the lockdep improvements
> > as we discussed. This means that 8/8 was changed a bit, and I decided
> > to add the new documentation patch, see 3/8.
> 
> Update: The recent
> 
>   [PATCH 0/2] xfs: kill lockdep false positives from readdir
> 
> changes from Dave fixed the problems ILOCK false-positives. So we can
> add the additional patch which (modulo comments) just turns v2 back into
> v1.
> 
> Dave, Jan, you seem to agree with these patches. How should we route
> this all?

Regarding the routing, ideally Al Viro should take these as a VFS
maintainer.
 
> ---
> Subject: [PATCH v2 9/8] don't fool lockdep in freeze_super() and thaw_super() 
> paths
> 
> sb_wait_write()->percpu_rwsem_release() fools lockdep to avoid the
> false-positives. Now that xfs was fixed by Dave we can remove it and
> change freeze_super() and thaw_super() to run with s_writers.rw_sem
> locks held; we add two trivial helpers for that, sb_freeze_release()
> and sb_freeze_acquire().
> 
> While at it, kill the outdated part of the comment above sb_wait_write.
> 
> Signed-off-by: Oleg Nesterov 

The patch looks good. Just one nit:

> + for (level = SB_FREEZE_LEVELS; --level >= 0; )
> + percpu_rwsem_release(sb->s_writers.rw_sem + level, 0, 
> _THIS_IP_);

It is more common (and to me more readable) to have the loop written as:

for (level = SB_FREEZE_LEVELS - 1; level >= 0; level--)

I agree what you do is shorter but IMHO it's just an unnecessary
obfuscation :)

Otherwise feel free to add:

Reviewed-by: Jan Kara 

Honza

> +}
> +
> +/*
> + * Tell lockdep we are holding these locks before we call ->unfreeze_fs(sb).
> + */
> +static void sb_freeze_acquire(struct super_block *sb)
>  {
>   int level;
>  
>   for (level = 0; level < SB_FREEZE_LEVELS; ++level)
>   percpu_rwsem_acquire(sb->s_writers.rw_sem + level, 0, 
> _THIS_IP_);
> +}
> +
> +static void sb_freeze_unlock(struct super_block *sb)
> +{
> + int level;
>  
>   for (level = SB_FREEZE_LEVELS; --level >= 0; )
>   percpu_up_write(sb->s_writers.rw_sem + level);
> @@ -1329,6 +1336,7 @@ int freeze_super(struct super_block *sb)
>* sees write activity when frozen is set to SB_FREEZE_COMPLETE.
>*/
>   sb->s_writers.frozen = SB_FREEZE_COMPLETE;
> + sb_freeze_release(sb);
>   up_write(>s_umount);
>   return 0;
>  }
> @@ -1355,11 +1363,14 @@ int thaw_super(struct super_block *sb)
>   goto out;
>   }
>  
> + sb_freeze_acquire(sb);
> +
>   if (sb->s_op->unfreeze_fs) {
>   error = sb->s_op->unfreeze_fs(sb);
>   if (error) {
>   printk(KERN_ERR
>   "VFS:Filesystem thaw failed\n");
> + sb_freeze_release(sb);
>   up_write(>s_umount);
>   return error;
>   }
> -- 
> 1.5.5.1
> 
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] x86/KASAN updates for 4.3

[Andrey Ryabinin]

2015-08-13 12:01 GMT+03:00 Will Deacon :
> Hi Ingo,
>
> On Thu, Aug 13, 2015 at 09:16:41AM +0100, Ingo Molnar wrote:
>> * Ingo Molnar  wrote:
>> > * Andrey Ryabinin  wrote:
>> >
>> > > These 2 patches taken from v5 'KASAN for arm64' series.
>> > > The only change is updated changelog in second patch.
>> > >
>> > > I hope this is not too late to queue these for 4.3,
>> > > as this allow us to merge arm64/KASAN patches in v4.4
>> > > through arm64 tree.
>> > >
>> > > Andrey Ryabinin (2):
>> > >   x86/kasan: define KASAN_SHADOW_OFFSET per architecture
>> > >   x86/kasan, mm: introduce generic kasan_populate_zero_shadow()
>> > >
>> > >  arch/x86/include/asm/kasan.h |   3 +
>> > >  arch/x86/mm/kasan_init_64.c  | 123 ++
>> > >  include/linux/kasan.h|  10 ++-
>> > >  mm/kasan/Makefile|   2 +-
>> > >  mm/kasan/kasan_init.c| 152 
>> > > +++
>> > >  5 files changed, 170 insertions(+), 120 deletions(-)
>> > >  create mode 100644 mm/kasan/kasan_init.c
>> >
>> > It's absolutely too late in the -rc cycle for v4.3!
>>
>> Stupid me, I have read 'v4.2' ...
>>
>> So yes, it's still good for v4.3, the development window is still open.
>>
>> The rest still stands:
>>
>> > I can create a stable topic tree for it, tip:mm/kasan or so, which arm64 
>> > could
>> > pull and base its own ARM specific work on, if that's OK with everyone.

OK with me.


> Yes please, works for me! If we're targetting 4.3, then please can you base
> on 4.2-rc4, as that's what our current arm64 queue is using?
>

Does this mean that we are targeting arm64 part for 4.3 too?


> Cheers,
>
> Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/6] irqchip: crossbar: fix irq masking at suspend

[Sudeep Holla]

On 13/08/15 11:17, Grygorii Strashko wrote:

On 08/13/2015 12:30 PM, Sudeep Holla wrote:



On 12/08/15 18:46, Grygorii Strashko wrote:

All ARM GIC IRQs have to masked during suspend if they are not
wakeup source. Now this is not happen, since switching to
use IRQ domain hierarchy, because suspend_device_irq() only checks flags
in the last IRQ chip in hierarchy for IRQCHIP_MASK_ON_SUSPEND
bit set. And in the case of TI OMAP DRA7 the last IRQ chip is TI Crossbar
which do not have this flag set.

In case of TI OMAP DRA7 the following IRQ hierarchy is defined:
ARM GIC <- OMAP wakeupgen <- TI CBAR
ARM GIC - IRQCHIP_MASK_ON_SUSPEND=n


May be this won't affect your platform or this patch but even GIC marks
IRQCHIP_MASK_ON_SUSPEND=y now since GIC doesn't provide any facility to
configure the wakeup source and keeps all the interrupt source enabled.


That's true for next, bur not true for 4.2-rc6 or 4.1 :(



True, I just wanted to ensure there is no assumption.

[...]


Also the beginning of the commit message contradicts when you also say
in the following statement IRQCHIP_MASK_ON_SUSPEND=n. So you may need to
update the log.


I'll try to reword. What I've tried to mention that IRQs masking on
suspend is default expected behavior and that how it was before
switching to IRQ domain hierarchy.

"All ARM GIC IRQs have to masked during suspend if they are not
  wakeup source - this is expected behavior and that's how it was before
  switching to IRQ domain hierarchy. ..."
ok?



My mistake I referred the code after it was converted to use stack
domains. So I missed to understand that you were using gic_arch_extn
flags before to override GIC flags as gic_set_irqchip_flags was not
used when I removed it. Sorry for the noise, you can retain the commit
log as is.

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/6] mailbox: Add generic mechanism for testing Mailbox Controllers

[Lee Jones]

On Thu, 13 Aug 2015, Jassi Brar wrote:

> On Thu, Aug 13, 2015 at 3:53 PM, Lee Jones  wrote:
> > On Thu, 13 Aug 2015, Jassi Brar wrote:
> >
> >> On Thu, Aug 13, 2015 at 2:49 PM, Lee Jones  wrote:
> >> > On Thu, 13 Aug 2015, Jassi Brar wrote:
> >>
> >> >> >> > +
> >> >> >> > +static void mbox_test_prepare_message(struct mbox_client *client, 
> >> >> >> > void *message)
> >> >> >> > +{
> >> >> >> > +   struct mbox_test_device *tdev = 
> >> >> >> > dev_get_drvdata(client->dev);
> >> >> >> > +
> >> >> >> > +   if (tdev->mmio)
> >> >> >> > +   memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
> >> >> >> >
> >> >> >> This is unlikely to work. Those platforms that need to send a 2 part
> >> >> >> message, they do :
> >> >> >> (a) Signal/Command/Target code via some controller register (via
> >> >> >> mbox_send_message).
> >> >> >> (b) Setup the payload in Shared-Memory (via tx_prepare).
> >> >> >>
> >> >> >> This test driver assumes both are the same. I think you have to
> >> >> >> declare something like
> >> >> >
> >> >> > This driver assumes that the framework will call client->tx_prepare()
> >> >> > first, which satisfies (b).  It then assumes controller->send_data()
> >> >> > will be invoked, which will send the platform specific
> >> >> > signal/command/target code, which then satisfies (a).
> >> >> >
> >> >> Yeah, but what would be that code? Who provides that?
> >> >>
> >> >> > In what way does it assume they are the same?
> >> >> >
> >> >> notice the 'message' pointer in
> >> >> mbox_send_message(tdev->tx_channel, message);
> >> >> and
> >> >> memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
> >> >>
> >> >> >> struct mbox_test_message { /* same for TX and RX */
> >> >> >>   unsigned sig_len;
> >> >> >>   void *signal;   /* rx/tx via mailbox api */
> >> >> >>   unsigned pl_len;
> >> >> >>   void *payload;   /* rx/tx via shared-memory */
> >> >> >> };
> >> >> >
> >> >> > How do you think this should be set and use these?
> >> >> >
> >> >> The userspace would want to specify the command code (32bits or not)
> >> >> that would be passed via the fifo/register of the controller. So we
> >> >> need signal[]
> >> >>
> >> >> The data to be passed via share-memory could be provided by userspace
> >> >> via the payload[] array.
> >> >
> >> > Okay, so would the solution be two userspace files 'signal' and
> >> > 'message', so in the case of a client specified signal we can write it
> >> > into there first.
> >> >
> >> > echo 255  > signal
> >> > echo test > message
> >> >
> >> > ... or in the case where no signal is required, or the controller
> >> > driver taking care of it, we just don't write anything to signal?
> >> >
> >> file_operations.write() should parse signal and message, coming from
> >> userspace, into a local structure before routing them via
> >> mbox_send_message and tx_prepare respectively.
> >
> > Okay.  So before I code this up we should agree on syntax.
> >
> > How would you like to represent the break between signal and message?
> > Obviously ' ' would be a bad idea, as some clients may want to send
> > messages with white space contained.  How about '\t' or '\n'?
> >
> Yeah, I am not a fan of markers and flags either.
> 
> Maybe we should share with userspace
>   struct mbox_test_message { /* same for TX and RX */
>unsigned sig_len;
>void __user *signal;/* rx/tx via mailbox api */
>unsigned pl_len;
>void __user *payload;/* rx/tx via shared-memory */
>   };
> 
> First copy_from_user the structure of length sizof(struct
> mbox_test_message) and then copy_from_user length sig_len and pl_len
> from signal[] and payload[] respectively (usually ioctls would carry
> such data).

Simplicity and ease of use should be the goals here.  Testers should
not have to write applications to use this driver.  Can we come up
with a simple/effective method that uses SYSFS/DEBUGFS please?

The easiest way I can think of which avoids markers/separators AND the
requirement for users to have to write applications is to have two
files, 'signal' and 'message' as mentioned before.  Once both are
populated I can get this driver to draft the message appropriately and
fire it off.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Remove unselectable rule for arm-exynos-cpufreq.o

[Viresh Kumar]

On 13-08-15, 19:53, Krzysztof Kozlowski wrote:
> 2015-08-13 19:32 GMT+09:00 Jonas Rabenstein
> :
> > With commit 2907ed4377d9 ("cpufreq: exynos: remove Exynos4x12 specific
> > cpufreq driver support"), the last specific Exynos-cpufreq driver
> > depending on ARM_EXYNOS_CPUFREQ was removed. As there is no
> > Exynos-specific cpufreq driver depending on the code in
> > drivers/cpufreq/exynos-cpufreq.c (selected by ARM_EXYNOS_CPUFREQ),
> > this file was deleted and ARM_EXYNOS_CPUFREQ removed from Kconfig.
> > After all, the rule in drivers/cpufreq/Makefile, to combine all
> > specific cpufreq drivers depending on the generic code for Exynos into
> > one objectfile is obsolete and can be removed.
> >
> > Remove unselectable rule for arm-exynos-cpufreq.o from
> > drivers/cpufreq/Makefile, which - if selectable - would generate an
> > always empty objectfile.
> 
> That's a lot, really a lot of words, just to say that
> ARM_EXYNOS_CPUFREQ option was removed and we should get rid of any
> left-overs. The patch is of course valid... but could you trim this to
> a short sentence giving the reason? Mentioned commit ID comes from
> linux-next (or maintainer branch which may rebase) so it won't work
> long-term. I think you can just leave the title of the commit.
> 
> When re-spinning:
> Reviewed-by: Krzysztof Kozlowski 
> 
> Viresh,
> Do you want this to go through samsung-soc tree?

That's Rafael's call, but even he can't take it right now. This patch
has dependency on the samsung pull request. So it should go that way
only.

But if you are already late, then Rafael can apply this after 4.3-rc1
is out.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sched: sync with the cfs_rq when changing sched class

[Byungchul Park]

On Thu, Aug 13, 2015 at 10:15:28AM +0800, Yuyang Du wrote:
> On Thu, Aug 13, 2015 at 05:21:27PM +0900, Byungchul Park wrote:
> > 
> > yuyang said that switched_to don't need to consider task's load because it
> > can have meaningless value. but i think considering task's load is better
> > than leaving it unattended at all. and we can also use switched_to if we 
> > consider task's load in switched_to.
> 
> when did I say "don't need to consider..."?
> 
> Doing more does not mean better, or just trivial. BTW, the task switched_to
> does not have to be switched_from before. 

i see.. i need to add initialization routine for fair class..

thanks,
byungchul

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Remove unselectable rule for arm-exynos-cpufreq.o

[Krzysztof Kozlowski]

2015-08-13 19:32 GMT+09:00 Jonas Rabenstein
:
> With commit 2907ed4377d9 ("cpufreq: exynos: remove Exynos4x12 specific
> cpufreq driver support"), the last specific Exynos-cpufreq driver
> depending on ARM_EXYNOS_CPUFREQ was removed. As there is no
> Exynos-specific cpufreq driver depending on the code in
> drivers/cpufreq/exynos-cpufreq.c (selected by ARM_EXYNOS_CPUFREQ),
> this file was deleted and ARM_EXYNOS_CPUFREQ removed from Kconfig.
> After all, the rule in drivers/cpufreq/Makefile, to combine all
> specific cpufreq drivers depending on the generic code for Exynos into
> one objectfile is obsolete and can be removed.
>
> Remove unselectable rule for arm-exynos-cpufreq.o from
> drivers/cpufreq/Makefile, which - if selectable - would generate an
> always empty objectfile.

That's a lot, really a lot of words, just to say that
ARM_EXYNOS_CPUFREQ option was removed and we should get rid of any
left-overs. The patch is of course valid... but could you trim this to
a short sentence giving the reason? Mentioned commit ID comes from
linux-next (or maintainer branch which may rebase) so it won't work
long-term. I think you can just leave the title of the commit.

When re-spinning:
Reviewed-by: Krzysztof Kozlowski 

Viresh,
Do you want this to go through samsung-soc tree?

Best regards,
Krzysztof

>
> Signed-off-by: Jonas Rabenstein 
> ---
> I found this inconsistency using the undertaker and
> undertaker-checkpatch tools (https://undertaker.cs.fau.de/).
>
>  drivers/cpufreq/Makefile | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index bbc4a9f..958be2b 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -52,7 +52,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ)   += 
> arm_big_little_dt.o
>
>  obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
>  obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
> -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += arm-exynos-cpufreq.o
>  obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)   += exynos5440-cpufreq.o
>  obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
>  obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ)+= hisi-acpu-cpufreq.o
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:ras/core] x86/ras: Move AMD MCE injector to arch/x86/ras/

[tip-bot for Borislav Petkov]

Commit-ID:  6c36dfe949187dc2729abfad4b083758ac5c2e0e
Gitweb: http://git.kernel.org/tip/6c36dfe949187dc2729abfad4b083758ac5c2e0e
Author: Borislav Petkov 
AuthorDate: Wed, 12 Aug 2015 18:29:45 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:54 +0200

x86/ras: Move AMD MCE injector to arch/x86/ras/

This is an x86-specific module and would benefit from being
closer to the arch code. Move it there. Update copyright while
at it.

Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Link: http://lkml.kernel.org/r/1439396985-12812-14-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/Makefile|  2 ++
 arch/x86/ras/Kconfig | 11 +++
 arch/x86/ras/Makefile|  2 ++
 {drivers/edac => arch/x86/ras}/mce_amd_inj.c |  6 +++---
 drivers/edac/Kconfig | 10 --
 drivers/edac/Makefile|  1 -
 drivers/ras/Kconfig  |  3 +++
 7 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 118e6de..0f38418 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -212,6 +212,8 @@ drivers-$(CONFIG_PM) += arch/x86/power/
 
 drivers-$(CONFIG_FB) += arch/x86/video/
 
+drivers-$(CONFIG_RAS) += arch/x86/ras/
+
 
 # boot loader support. Several targets are kept for legacy purposes
 
diff --git a/arch/x86/ras/Kconfig b/arch/x86/ras/Kconfig
new file mode 100644
index 000..10fea5f
--- /dev/null
+++ b/arch/x86/ras/Kconfig
@@ -0,0 +1,11 @@
+config AMD_MCE_INJ
+   tristate "Simple MCE injection interface for AMD processors"
+   depends on RAS && EDAC_DECODE_MCE && DEBUG_FS
+   default n
+   help
+ This is a simple debugfs interface to inject MCEs and test different
+ aspects of the MCE handling code.
+
+ WARNING: Do not even assume this interface is staying stable!
+
+
diff --git a/arch/x86/ras/Makefile b/arch/x86/ras/Makefile
new file mode 100644
index 000..dd2c98b
--- /dev/null
+++ b/arch/x86/ras/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_AMD_MCE_INJ)  += mce_amd_inj.o
+
diff --git a/drivers/edac/mce_amd_inj.c b/arch/x86/ras/mce_amd_inj.c
similarity index 98%
rename from drivers/edac/mce_amd_inj.c
rename to arch/x86/ras/mce_amd_inj.c
index 4c73e4d0..17e35b5 100644
--- a/drivers/edac/mce_amd_inj.c
+++ b/arch/x86/ras/mce_amd_inj.c
@@ -6,7 +6,7 @@
  * This file may be distributed under the terms of the GNU General Public
  * License version 2.
  *
- * Copyright (c) 2010-14:  Borislav Petkov 
+ * Copyright (c) 2010-15:  Borislav Petkov 
  * Advanced Micro Devices Inc.
  */
 
@@ -19,7 +19,7 @@
 #include 
 #include 
 
-#include "mce_amd.h"
+#include "../kernel/cpu/mcheck/mce-internal.h"
 
 /*
  * Collect all the MCi_XXX settings
@@ -195,7 +195,7 @@ static void do_inject(void)
i_mce.status |= MCI_STATUS_MISCV;
 
if (inj_type == SW_INJ) {
-   amd_decode_mce(NULL, 0, _mce);
+   mce_inject_log(_mce);
return;
}
 
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 8677ead..ef25000 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -61,16 +61,6 @@ config EDAC_DECODE_MCE
  which occur really early upon boot, before the module infrastructure
  has been initialized.
 
-config EDAC_MCE_INJ
-   tristate "Simple MCE injection interface"
-   depends on EDAC_DECODE_MCE && DEBUG_FS
-   default n
-   help
- This is a simple debugfs interface to inject MCEs and test different
- aspects of the MCE handling code.
-
- WARNING: Do not even assume this interface is staying stable!
-
 config EDAC_MM_EDAC
tristate "Main Memory EDAC (Error Detection And Correction) reporting"
select RAS
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 28ef2a5..ae3c5f3 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -17,7 +17,6 @@ edac_core-y   += edac_pci.o edac_pci_sysfs.o
 endif
 
 obj-$(CONFIG_EDAC_GHES)+= ghes_edac.o
-obj-$(CONFIG_EDAC_MCE_INJ) += mce_amd_inj.o
 
 edac_mce_amd-y := mce_amd.o
 obj-$(CONFIG_EDAC_DECODE_MCE)  += edac_mce_amd.o
diff --git a/drivers/ras/Kconfig b/drivers/ras/Kconfig
index e5f0a43..4c3c67d 100644
--- a/drivers/ras/Kconfig
+++ b/drivers/ras/Kconfig
@@ -29,4 +29,7 @@ menuconfig RAS
  data corruption.
 
 if RAS
+
+source arch/x86/ras/Kconfig
+
 endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] sched: make task_move_group_fair simple by using switched_to(from)_fair

[byungchul . park]

From: Byungchul Park 

i introduced need_vruntime_adjust() to check if do or not adjust vruntime
when attaching/detaching a se to/from its cfs_rq, and use it.

i made the best use of switched_to(from)_fair for attach(detach)
operations in task_move_group_fair().

Signed-off-by: Byungchul Park 
---
 kernel/sched/fair.c |   80 +++
 1 file changed, 29 insertions(+), 51 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d91e4da..5ec846f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7904,6 +7904,31 @@ prio_changed_fair(struct rq *rq, struct task_struct *p, 
int oldprio)
check_preempt_curr(rq, p, 0);
 }
 
+static inline int need_vruntime_adjust(struct task_struct *p, int queued)
+{
+   struct sched_entity *se = >se;
+
+   /*
+* When !queued, vruntime of the task has usually NOT been normalized.
+* But there are some cases where it has already been normalized:
+*
+* - Moving a forked child which is waiting for being woken up by
+*   wake_up_new_task().
+* - Moving a task which has been woken up by try_to_wake_up() and
+*   waiting for actually being woken up by sched_ttwu_pending().
+*/
+   if (queued)
+   return 0;
+
+   if (!se->sum_exec_runtime || p->state == TASK_WAKING)
+   return 0;
+
+   if (p->state != TASK_RUNNING)
+   return 1;
+
+   return 0;
+}
+
 static void switched_from_fair(struct rq *rq, struct task_struct *p)
 {
struct sched_entity *se = >se;
@@ -7918,7 +7943,7 @@ static void switched_from_fair(struct rq *rq, struct 
task_struct *p)
 * have normalized the vruntime, if it's !queued, then only when
 * the task is sleeping will it still have non-normalized vruntime.
 */
-   if (!task_on_rq_queued(p) && p->state != TASK_RUNNING) {
+   if (need_vruntime_adjust(p, task_on_rq_queued(p))) {
/*
 * Fix up our vruntime so that the current sleep doesn't
 * cause 'unlimited' sleep bonus.
@@ -7939,7 +7964,6 @@ static void switched_from_fair(struct rq *rq, struct 
task_struct *p)
 static void switched_to_fair(struct rq *rq, struct task_struct *p)
 {
struct sched_entity *se = >se;
-
 #ifdef CONFIG_FAIR_GROUP_SCHED
/*
 * Since the real-depth could have been changed (only FAIR
@@ -7964,7 +7988,7 @@ static void switched_to_fair(struct rq *rq, struct 
task_struct *p)
 * has non-normalized vruntime, if it's !queued, then it still 
has
 * normalized vruntime.
 */
-   if (p->state != TASK_RUNNING)
+   if (need_vruntime_adjust(p, task_on_rq_queued(p)))
se->vruntime += cfs_rq_of(se)->min_vruntime;
return;
}
@@ -8014,55 +8038,9 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
 #ifdef CONFIG_FAIR_GROUP_SCHED
 static void task_move_group_fair(struct task_struct *p, int queued)
 {
-   struct sched_entity *se = >se;
-   struct cfs_rq *cfs_rq;
-
-   /*
-* If the task was not on the rq at the time of this cgroup movement
-* it must have been asleep, sleeping tasks keep their ->vruntime
-* absolute on their old rq until wakeup (needed for the fair sleeper
-* bonus in place_entity()).
-*
-* If it was on the rq, we've just 'preempted' it, which does convert
-* ->vruntime to a relative base.
-*
-* Make sure both cases convert their relative position when migrating
-* to another cgroup's rq. This does somewhat interfere with the
-* fair sleeper stuff for the first placement, but who cares.
-*/
-   /*
-* When !queued, vruntime of the task has usually NOT been normalized.
-* But there are some cases where it has already been normalized:
-*
-* - Moving a forked child which is waiting for being woken up by
-*   wake_up_new_task().
-* - Moving a task which has been woken up by try_to_wake_up() and
-*   waiting for actually being woken up by sched_ttwu_pending().
-*
-* To prevent boost or penalty in the new cfs_rq caused by delta
-* min_vruntime between the two cfs_rqs, we skip vruntime adjustment.
-*/
-   if (!queued && (!se->sum_exec_runtime || p->state == TASK_WAKING))
-   queued = 1;
-
-   cfs_rq = cfs_rq_of(se);
-   if (!queued)
-   se->vruntime -= cfs_rq->min_vruntime;
-
-#ifdef CONFIG_SMP
-   /* synchronize task with its prev cfs_rq */
-   detach_entity_load_avg(cfs_rq, se);
-#endif
+   switched_from_fair(task_rq(p), p);
set_task_rq(p, task_cpu(p));
-   se->depth = se->parent ? se->parent->depth + 1 : 0;
-   cfs_rq = cfs_rq_of(se);
-   if (!queued)
-   se->vruntime += cfs_rq->min_vruntime;
-
-#ifdef 

[PATCH 1/2] sched: sync a se with its cfs_rq when attaching and dettaching

[byungchul . park]

From: Byungchul Park 

current code seems to be wrong with cfs_rq's avg loads when changing
a task's cgroup(=cfs_rq) to another. i tested with "echo pid > cgroup" and
found that e.g. cfs_rq->avg.load_avg became larger and larger whenever i
changed a cgroup to another again and again. we have to sync se's average
load with both *prev* cfs_rq and next cfs_rq when changing its group.
we also need to sync it with cfs_rq when it returns back to fair class
after it has leaved from fair class.

in addition, i introduced two functions for attaching/detaching a se load
from/to its cfs_rq, and let them use those functions. and i place that
function call to where a se is attached/detached to/from cfs_rq.

Signed-off-by: Byungchul Park 
---
 kernel/sched/fair.c |   82 ++-
 1 file changed, 48 insertions(+), 34 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7f0040c..d91e4da 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2709,6 +2709,31 @@ static inline void update_load_avg(struct sched_entity 
*se, int update_tg)
update_tg_load_avg(cfs_rq, 0);
 }
 
+static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
+{
+   se->avg.last_update_time = cfs_rq->avg.last_update_time;
+   cfs_rq->avg.load_avg += se->avg.load_avg;
+   cfs_rq->avg.load_sum += se->avg.load_sum;
+   cfs_rq->avg.util_avg += se->avg.util_avg;
+   cfs_rq->avg.util_sum += se->avg.util_sum;
+}
+
+static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
+{
+   __update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq_of(cfs_rq)),
+   >avg, se->on_rq * scale_load_down(se->load.weight),
+   cfs_rq->curr == se, NULL);
+
+   cfs_rq->avg.load_avg =
+   max_t(long, cfs_rq->avg.load_avg - se->avg.load_avg, 0);
+   cfs_rq->avg.load_sum =
+   max_t(s64, cfs_rq->avg.load_sum - se->avg.load_sum, 0);
+   cfs_rq->avg.util_avg =
+   max_t(long, cfs_rq->avg.util_avg - se->avg.util_avg, 0);
+   cfs_rq->avg.util_sum =
+   max_t(s32, cfs_rq->avg.util_sum - se->avg.util_sum, 0);
+}
+
 /* Add the load generated by se into cfs_rq's load average */
 static inline void
 enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
@@ -2717,27 +2742,20 @@ enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct 
sched_entity *se)
u64 now = cfs_rq_clock_task(cfs_rq);
int migrated = 0, decayed;
 
-   if (sa->last_update_time == 0) {
-   sa->last_update_time = now;
+   if (sa->last_update_time == 0)
migrated = 1;
-   }
-   else {
+   else
__update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
-   se->on_rq * scale_load_down(se->load.weight),
-   cfs_rq->curr == se, NULL);
-   }
+   se->on_rq * scale_load_down(se->load.weight),
+   cfs_rq->curr == se, NULL);
 
decayed = update_cfs_rq_load_avg(now, cfs_rq);
 
cfs_rq->runnable_load_avg += sa->load_avg;
cfs_rq->runnable_load_sum += sa->load_sum;
 
-   if (migrated) {
-   cfs_rq->avg.load_avg += sa->load_avg;
-   cfs_rq->avg.load_sum += sa->load_sum;
-   cfs_rq->avg.util_avg += sa->util_avg;
-   cfs_rq->avg.util_sum += sa->util_sum;
-   }
+   if (migrated)
+   attach_entity_load_avg(cfs_rq, se);
 
if (decayed || migrated)
update_tg_load_avg(cfs_rq, 0);
@@ -7911,17 +7929,7 @@ static void switched_from_fair(struct rq *rq, struct 
task_struct *p)
 
 #ifdef CONFIG_SMP
/* Catch up with the cfs_rq and remove our load when we leave */
-   __update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq), >avg,
-   se->on_rq * scale_load_down(se->load.weight), cfs_rq->curr == 
se, NULL);
-
-   cfs_rq->avg.load_avg =
-   max_t(long, cfs_rq->avg.load_avg - se->avg.load_avg, 0);
-   cfs_rq->avg.load_sum =
-   max_t(s64, cfs_rq->avg.load_sum - se->avg.load_sum, 0);
-   cfs_rq->avg.util_avg =
-   max_t(long, cfs_rq->avg.util_avg - se->avg.util_avg, 0);
-   cfs_rq->avg.util_sum =
-   max_t(s32, cfs_rq->avg.util_sum - se->avg.util_sum, 0);
+   detach_entity_load_avg(cfs_rq, se);
 #endif
 }
 
@@ -7940,6 +7948,11 @@ static void switched_to_fair(struct rq *rq, struct 
task_struct *p)
se->depth = se->parent ? se->parent->depth + 1 : 0;
 #endif
 
+#ifdef CONFIG_SMP
+   /* synchronize task with its cfs_rq */
+   attach_entity_load_avg(cfs_rq_of(>se), >se);
+#endif
+
if (!task_on_rq_queued(p)) {
 
/*
@@ -8032,23 +8045,24 @@ static void task_move_group_fair(struct task_struct *p, 
int queued)
if (!queued && (!se->sum_exec_runtime || p->state == 

[tip:ras/core] x86/mce: Add a wrapper around mce_log() for injection

[tip-bot for Borislav Petkov]

Commit-ID:  a79da38494ec23f1a7d6ee734e07e9575fd18b58
Gitweb: http://git.kernel.org/tip/a79da38494ec23f1a7d6ee734e07e9575fd18b58
Author: Borislav Petkov 
AuthorDate: Wed, 12 Aug 2015 18:29:44 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:53 +0200

x86/mce: Add a wrapper around mce_log() for injection

Will be used by an injector module in a following patch.

Additionally, add a missing module export reported by 0-DAY
kernel test.

Reported-by: kbuild test robot 
Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Link: http://lkml.kernel.org/r/1439396985-12812-13-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/mcheck/mce-internal.h | 2 ++
 arch/x86/kernel/cpu/mcheck/mce.c  | 8 
 2 files changed, 10 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h 
b/arch/x86/kernel/cpu/mcheck/mce-internal.h
index ea8b622..547720e 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-internal.h
+++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h
@@ -79,3 +79,5 @@ static inline int apei_clear_mce(u64 record_id)
return -EINVAL;
 }
 #endif
+
+void mce_inject_log(struct mce *m);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index b979711..e4e6646 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -199,6 +199,14 @@ void mce_log(struct mce *mce)
set_bit(0, _need_notify);
 }
 
+void mce_inject_log(struct mce *m)
+{
+   mutex_lock(_chrdev_read_mutex);
+   mce_log(m);
+   mutex_unlock(_chrdev_read_mutex);
+}
+EXPORT_SYMBOL_GPL(mce_inject_log);
+
 static struct notifier_block mce_srao_nb;
 
 void mce_register_decode_chain(struct notifier_block *nb)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:ras/core] x86/mce: Rename rcu_dereference_check_mce() to mce_log_get_idx_check()

[tip-bot for Borislav Petkov]

Commit-ID:  9a7783d02197f299f71b4fa2364a345c05f92b83
Gitweb: http://git.kernel.org/tip/9a7783d02197f299f71b4fa2364a345c05f92b83
Author: Borislav Petkov 
AuthorDate: Wed, 12 Aug 2015 18:29:43 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:53 +0200

x86/mce: Rename rcu_dereference_check_mce() to mce_log_get_idx_check()

The "rcu_" prefix misleads for it being a proper RCU interface
which is not. It basically checks whether we're preemptible or
holding the chrdev_read mutex.

Rename it accordingly.

Signed-off-by: Borislav Petkov 
Acked-by: Paul E. McKenney 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Link: http://lkml.kernel.org/r/1439396985-12812-12-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index ee5272d..b979711 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -52,11 +52,11 @@
 
 static DEFINE_MUTEX(mce_chrdev_read_mutex);
 
-#define rcu_dereference_check_mce(p) \
+#define mce_log_get_idx_check(p) \
 ({ \
rcu_lockdep_assert(rcu_read_lock_sched_held() || \
   lockdep_is_held(_chrdev_read_mutex), \
-  "suspicious rcu_dereference_check_mce() usage"); \
+  "suspicious mce_log_get_idx_check() usage"); \
smp_load_acquire(&(p)); \
 })
 
@@ -165,7 +165,7 @@ void mce_log(struct mce *mce)
mce->finished = 0;
wmb();
for (;;) {
-   entry = rcu_dereference_check_mce(mcelog.next);
+   entry = mce_log_get_idx_check(mcelog.next);
for (;;) {
 
/*
@@ -1812,7 +1812,7 @@ static ssize_t mce_chrdev_read(struct file *filp, char 
__user *ubuf,
goto out;
}
 
-   next = rcu_dereference_check_mce(mcelog.next);
+   next = mce_log_get_idx_check(mcelog.next);
 
/* Only supports full reads right now */
err = -EINVAL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:ras/core] RAS: Add a menuconfig option with descriptive text

[tip-bot for Borislav Petkov]

Commit-ID:  9b45ef443acde55526485db37440cd3e8f03d544
Gitweb: http://git.kernel.org/tip/9b45ef443acde55526485db37440cd3e8f03d544
Author: Borislav Petkov 
AuthorDate: Wed, 12 Aug 2015 18:29:42 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:53 +0200

RAS: Add a menuconfig option with descriptive text

Text taken a previous patch from "Gong Chen" .

Signed-off-by: Borislav Petkov 
Cc: Gong Chen 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Link: http://lkml.kernel.org/r/1439396985-12812-11-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 drivers/ras/Kconfig | 34 --
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/ras/Kconfig b/drivers/ras/Kconfig
index f9da613..e5f0a43 100644
--- a/drivers/ras/Kconfig
+++ b/drivers/ras/Kconfig
@@ -1,2 +1,32 @@
-config RAS
-   bool
+menuconfig RAS
+   bool "Reliability, Availability and Serviceability (RAS) features"
+   help
+ Reliability, availability and serviceability (RAS) is a computer
+ hardware engineering term. Computers designed with higher levels
+ of RAS have a multitude of features that protect data integrity
+ and help them stay available for long periods of time without
+ failure.
+
+ Reliability can be defined as the probability that the system will
+ produce correct outputs up to some given time. Reliability is
+ enhanced by features that help to avoid, detect and repair hardware
+ faults.
+
+ Availability is the probability a system is operational at a given
+ time, i.e. the amount of time a device is actually operating as the
+ percentage of total time it should be operating.
+
+ Serviceability or maintainability is the simplicity and speed with
+ which a system can be repaired or maintained; if the time to repair
+ a failed system increases, then availability will decrease.
+
+ Note that Reliability and Availability are distinct concepts:
+ Reliability is a measure of the ability of a system to function
+ correctly, including avoiding data corruption, whereas Availability
+ measures how often it is available for use, even though it may not
+ be functioning correctly. For example, a server may run forever and
+ so have ideal availability, but may be unreliable, with frequent
+ data corruption.
+
+if RAS
+endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:ras/core] x86/mce: Clear Local MCE opt-in before kexec

[tip-bot for Ashok Raj]

Commit-ID:  8838eb6c0bf3b6a6494a163947ab3d1700ab45d2
Gitweb: http://git.kernel.org/tip/8838eb6c0bf3b6a6494a163947ab3d1700ab45d2
Author: Ashok Raj 
AuthorDate: Wed, 12 Aug 2015 18:29:40 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:52 +0200

x86/mce: Clear Local MCE opt-in before kexec

kexec could boot a kernel that could be legacy with no knowledge
of LMCE. Hence we should make sure we clear LMCE optin before
kexec reboot.

Signed-off-by: Ashok Raj 
Signed-off-by: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Aravind Gopalakrishnan 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/1439396985-12812-9-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/mce.h |  4 
 arch/x86/kernel/cpu/mcheck/mce.c   | 30 ++
 arch/x86/kernel/cpu/mcheck/mce_intel.c | 19 ++-
 arch/x86/kernel/process.c  |  2 ++
 arch/x86/kernel/smp.c  |  2 ++
 5 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 38d3a1a8..2dbc0bf 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -151,10 +151,12 @@ extern int mce_p5_enabled;
 #ifdef CONFIG_X86_MCE
 int mcheck_init(void);
 void mcheck_cpu_init(struct cpuinfo_x86 *c);
+void mcheck_cpu_clear(struct cpuinfo_x86 *c);
 void mcheck_vendor_init_severity(void);
 #else
 static inline int mcheck_init(void) { return 0; }
 static inline void mcheck_cpu_init(struct cpuinfo_x86 *c) {}
+static inline void mcheck_cpu_clear(struct cpuinfo_x86 *c) {}
 static inline void mcheck_vendor_init_severity(void) {}
 #endif
 
@@ -181,12 +183,14 @@ DECLARE_PER_CPU(struct device *, mce_device);
 
 #ifdef CONFIG_X86_MCE_INTEL
 void mce_intel_feature_init(struct cpuinfo_x86 *c);
+void mce_intel_feature_clear(struct cpuinfo_x86 *c);
 void cmci_clear(void);
 void cmci_reenable(void);
 void cmci_rediscover(void);
 void cmci_recheck(void);
 #else
 static inline void mce_intel_feature_init(struct cpuinfo_x86 *c) { }
+static inline void mce_intel_feature_clear(struct cpuinfo_x86 *c) { }
 static inline void cmci_clear(void) {}
 static inline void cmci_reenable(void) {}
 static inline void cmci_rediscover(void) {}
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 32b586e..ee5272d 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1606,6 +1606,17 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
}
 }
 
+static void __mcheck_cpu_clear_vendor(struct cpuinfo_x86 *c)
+{
+   switch (c->x86_vendor) {
+   case X86_VENDOR_INTEL:
+   mce_intel_feature_clear(c);
+   break;
+   default:
+   break;
+   }
+}
+
 static void mce_start_timer(unsigned int cpu, struct timer_list *t)
 {
unsigned long iv = check_interval * HZ;
@@ -1673,6 +1684,25 @@ void mcheck_cpu_init(struct cpuinfo_x86 *c)
 }
 
 /*
+ * Called for each booted CPU to clear some machine checks opt-ins
+ */
+void mcheck_cpu_clear(struct cpuinfo_x86 *c)
+{
+   if (mca_cfg.disabled)
+   return;
+
+   if (!mce_available(c))
+   return;
+
+   /*
+* Possibly to clear general settings generic to x86
+* __mcheck_cpu_clear_generic(c);
+*/
+   __mcheck_cpu_clear_vendor(c);
+
+}
+
+/*
  * mce_chrdev: Character device /dev/mcelog to read and clear the MCE log.
  */
 
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c 
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index 70f567f..c5c0032 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -434,7 +434,7 @@ static void intel_init_cmci(void)
cmci_recheck();
 }
 
-void intel_init_lmce(void)
+static void intel_init_lmce(void)
 {
u64 val;
 
@@ -447,9 +447,26 @@ void intel_init_lmce(void)
wrmsrl(MSR_IA32_MCG_EXT_CTL, val | MCG_EXT_CTL_LMCE_EN);
 }
 
+static void intel_clear_lmce(void)
+{
+   u64 val;
+
+   if (!lmce_supported())
+   return;
+
+   rdmsrl(MSR_IA32_MCG_EXT_CTL, val);
+   val &= ~MCG_EXT_CTL_LMCE_EN;
+   wrmsrl(MSR_IA32_MCG_EXT_CTL, val);
+}
+
 void mce_intel_feature_init(struct cpuinfo_x86 *c)
 {
intel_init_thermal(c);
intel_init_cmci();
intel_init_lmce();
 }
+
+void mce_intel_feature_clear(struct cpuinfo_x86 *c)
+{
+   intel_clear_lmce();
+}
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 397688b..b20ef18 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -319,6 +320,7 @@ void stop_this_cpu(void *dummy)
 */
set_cpu_online(smp_processor_id(), false);

[tip:ras/core] x86/mce: Reenable CMCI banks when swiching back to interrupt mode

[tip-bot for Xie XiuQi]

Commit-ID:  1b48465500611a2dc5e75800c61ac352e22d41c3
Gitweb: http://git.kernel.org/tip/1b48465500611a2dc5e75800c61ac352e22d41c3
Author: Xie XiuQi 
AuthorDate: Wed, 12 Aug 2015 18:29:41 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:52 +0200

x86/mce: Reenable CMCI banks when swiching back to interrupt mode

Zhang Liguang reported the following issue:

1) System detects a CMCI storm on the current CPU.

2) Kernel disables the CMCI interrupt on banks owned by the
   current CPU and switches to poll mode

3) After the CMCI storm subsides, kernel switches back to
   interrupt mode

4) We expect the system to reenable the CMCI interrupt on banks
   owned by the current CPU

   mce_intel_adjust_timer
   |-> cmci_reenable
   |-> cmci_discover # owned banks are ignored here

  static void cmci_discover(int banks)
...
for (i = 0; i < banks; i++) {
...
if (test_bit(i, owned)) # ownd banks is ignore here
continue;

So convert cmci_storm_disable_banks() to
cmci_toggle_interrupt_mode() which controls whether to enable or
disable CMCI interrupts with its argument.

NB: We cannot clear the owned bit because the banks won't be
polled, otherwise. See:

  27f6c573e0f7 ("x86, CMCI: Add proper detection of end of CMCI storms")

for more info.

Reported-by: Zhang Liguang 
Signed-off-by: Xie XiuQi 
Signed-off-by: Borislav Petkov 
Cc:  # v3.15+
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: huawei.li...@huawei.com
Cc: linux-edac 
Cc: rui.xi...@huawei.com
Link: http://lkml.kernel.org/r/1439396985-12812-10-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/mcheck/mce_intel.c | 41 +++---
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c 
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index c5c0032..1e8bb6c 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -146,6 +146,27 @@ void mce_intel_hcpu_update(unsigned long cpu)
per_cpu(cmci_storm_state, cpu) = CMCI_STORM_NONE;
 }
 
+static void cmci_toggle_interrupt_mode(bool on)
+{
+   unsigned long flags, *owned;
+   int bank;
+   u64 val;
+
+   raw_spin_lock_irqsave(_discover_lock, flags);
+   owned = this_cpu_ptr(mce_banks_owned);
+   for_each_set_bit(bank, owned, MAX_NR_BANKS) {
+   rdmsrl(MSR_IA32_MCx_CTL2(bank), val);
+
+   if (on)
+   val |= MCI_CTL2_CMCI_EN;
+   else
+   val &= ~MCI_CTL2_CMCI_EN;
+
+   wrmsrl(MSR_IA32_MCx_CTL2(bank), val);
+   }
+   raw_spin_unlock_irqrestore(_discover_lock, flags);
+}
+
 unsigned long cmci_intel_adjust_timer(unsigned long interval)
 {
if ((this_cpu_read(cmci_backoff_cnt) > 0) &&
@@ -175,7 +196,7 @@ unsigned long cmci_intel_adjust_timer(unsigned long 
interval)
 */
if (!atomic_read(_storm_on_cpus)) {
__this_cpu_write(cmci_storm_state, CMCI_STORM_NONE);
-   cmci_reenable();
+   cmci_toggle_interrupt_mode(true);
cmci_recheck();
}
return CMCI_POLL_INTERVAL;
@@ -186,22 +207,6 @@ unsigned long cmci_intel_adjust_timer(unsigned long 
interval)
}
 }
 
-static void cmci_storm_disable_banks(void)
-{
-   unsigned long flags, *owned;
-   int bank;
-   u64 val;
-
-   raw_spin_lock_irqsave(_discover_lock, flags);
-   owned = this_cpu_ptr(mce_banks_owned);
-   for_each_set_bit(bank, owned, MAX_NR_BANKS) {
-   rdmsrl(MSR_IA32_MCx_CTL2(bank), val);
-   val &= ~MCI_CTL2_CMCI_EN;
-   wrmsrl(MSR_IA32_MCx_CTL2(bank), val);
-   }
-   raw_spin_unlock_irqrestore(_discover_lock, flags);
-}
-
 static bool cmci_storm_detect(void)
 {
unsigned int cnt = __this_cpu_read(cmci_storm_cnt);
@@ -223,7 +228,7 @@ static bool cmci_storm_detect(void)
if (cnt <= CMCI_STORM_THRESHOLD)
return false;
 
-   cmci_storm_disable_banks();
+   cmci_toggle_interrupt_mode(false);
__this_cpu_write(cmci_storm_state, CMCI_STORM_ACTIVE);
r = atomic_add_return(1, _storm_on_cpus);
mce_timer_kick(CMCI_STORM_INTERVAL);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock()

[Will Deacon]

On Wed, Aug 12, 2015 at 06:59:38PM +0100, Paul E. McKenney wrote:
> On Wed, Aug 12, 2015 at 08:43:46AM -0700, Paul E. McKenney wrote:
> > On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote:
> > > The generic relaxed atomics are now queued in -tip, so it would be really
> > > good to see this Documentation update land in 4.3 if at all possible. I
> > > appreciate it's late in the cycle, but it's always worth asking.
> > 
> > Can't hurt to give it a try.  I have set -rcu's rcu/next branch to this
> > commit, and if it passes a few day's worth of testing, I will see what
> > Ingo has to say about a pull request.
> > 
> > This commit also privatizes smp_mb__after_unlock_lock() as well as
> > updating documentation.  Looks like we need to strengthen powerpc's
> > locking primitives, then get rid of smp_mb__after_unlock_lock() entirely.
> > Or did that already happen and I just missed it?
> 
> And just for completeness, here is the current version of that commit.
> 
>   Thanx, Paul
> 
> 
> 
>  b/Documentation/memory-barriers.txt   |   71 
> +-
>  b/arch/powerpc/include/asm/spinlock.h |2 
>  b/include/linux/spinlock.h|   10 
>  b/kernel/rcu/tree.h   |   12 +
>  4 files changed, 16 insertions(+), 79 deletions(-)
> 
> commit 12d560f4ea87030667438a169912380be00cea4b
> Author: Paul E. McKenney 
> Date:   Tue Jul 14 18:35:23 2015 -0700
> 
> rcu,locking: Privatize smp_mb__after_unlock_lock()
> 
> RCU is the only thing that uses smp_mb__after_unlock_lock(), and is
> likely the only thing that ever will use it, so this commit makes this
> macro private to RCU.
> 
> Signed-off-by: Paul E. McKenney 
> Cc: Will Deacon 
> Cc: Peter Zijlstra 
> Cc: Benjamin Herrenschmidt 
> Cc: "linux-a...@vger.kernel.org" 

Acked-by: Will Deacon 

I don't think the PowerPC spinlock change is queued anywhere (I sent it
out as a diff for discussion, but that was it). This patch doesn't rely
on that though, right?

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 8/8] change sb_writers to use percpu_rw_semaphore

[Jan Kara]

On Tue 11-08-15 19:04:19, Oleg Nesterov wrote:
> We can remove everything from struct sb_writers except frozen
> and add the array of percpu_rw_semaphore's instead.
> 
> This patch doesn't remove sb_writers->wait_unfrozen yet, we keep
> it for get_super_thawed(). We will probably remove it later.
> 
> This change tries to address the following problems:
> 
>   - Firstly, __sb_start_write() looks simply buggy. It does
> __sb_end_write() if it sees ->frozen, but if it migrates
> to another CPU before percpu_counter_dec(), sb_wait_write()
> can wrongly succeed if there is another task which holds
> the same "semaphore": sb_wait_write() can miss the result
> of the previous percpu_counter_inc() but see the result
> of this percpu_counter_dec().
> 
>   - As Dave Hansen reports, it is suboptimal. The trivial
> microbenchmark that writes to a tmpfs file in a loop runs
> 12% faster if we change this code to rely on RCU and kill
> the memory barriers.
> 
>   - This code doesn't look simple. It would be better to rely
> on the generic locking code.
> 
> According to Dave, this change adds the same performance
> improvement.
> 
> Note: with this change both freeze_super() and thaw_super() will do
> synchronize_sched_expedited() 3 times. This is just ugly. But:
> 
>   - This will be "fixed" by the rcu_sync changes we are going
> to merge. After that freeze_super()->percpu_down_write()
> will use synchronize_sched(), and thaw_super() won't use
> synchronize() at all.
> 
> This doesn't need any changes in fs/super.c.
> 
>   - Once we merge rcu_sync changes, we can also change super.c
> so that all wb_write->rw_sem's will share the single ->rss
> in struct sb_writes, then freeze_super() will need only one
> synchronize_sched().
> 
> Signed-off-by: Oleg Nesterov 

The patch looks good. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  fs/super.c |  107 
> ++--
>  include/linux/fs.h |   19 +++--
>  2 files changed, 35 insertions(+), 91 deletions(-)
> 
> diff --git a/fs/super.c b/fs/super.c
> index 75436e2..8762997 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -142,7 +142,7 @@ static void destroy_super_work(struct work_struct *work)
>   int i;
>  
>   for (i = 0; i < SB_FREEZE_LEVELS; i++)
> - percpu_counter_destroy(>s_writers.counter[i]);
> + percpu_free_rwsem(>s_writers.rw_sem[i]);
>   kfree(s);
>  }
>  
> @@ -193,13 +193,11 @@ static struct super_block *alloc_super(struct 
> file_system_type *type, int flags)
>   goto fail;
>  
>   for (i = 0; i < SB_FREEZE_LEVELS; i++) {
> - if (percpu_counter_init(>s_writers.counter[i], 0,
> - GFP_KERNEL) < 0)
> + if (__percpu_init_rwsem(>s_writers.rw_sem[i],
> + sb_writers_name[i],
> + >s_writers_key[i]))
>   goto fail;
> - lockdep_init_map(>s_writers.lock_map[i], sb_writers_name[i],
> -  >s_writers_key[i], 0);
>   }
> - init_waitqueue_head(>s_writers.wait);
>   init_waitqueue_head(>s_writers.wait_unfrozen);
>   s->s_bdi = _backing_dev_info;
>   s->s_flags = flags;
> @@ -1161,47 +1159,10 @@ out:
>   */
>  void __sb_end_write(struct super_block *sb, int level)
>  {
> - percpu_counter_dec(>s_writers.counter[level-1]);
> - /*
> -  * Make sure s_writers are updated before we wake up waiters in
> -  * freeze_super().
> -  */
> - smp_mb();
> - if (waitqueue_active(>s_writers.wait))
> - wake_up(>s_writers.wait);
> - rwsem_release(>s_writers.lock_map[level-1], 1, _RET_IP_);
> + percpu_up_read(sb->s_writers.rw_sem + level-1);
>  }
>  EXPORT_SYMBOL(__sb_end_write);
>  
> -static int do_sb_start_write(struct super_block *sb, int level, bool wait,
> - unsigned long ip)
> -{
> - if (wait)
> - rwsem_acquire_read(>s_writers.lock_map[level-1], 0, 0, ip);
> -retry:
> - if (unlikely(sb->s_writers.frozen >= level)) {
> - if (!wait)
> - return 0;
> - wait_event(sb->s_writers.wait_unfrozen,
> -sb->s_writers.frozen < level);
> - }
> -
> - percpu_counter_inc(>s_writers.counter[level-1]);
> - /*
> -  * Make sure counter is updated before we check for frozen.
> -  * freeze_super() first sets frozen and then checks the counter.
> -  */
> - smp_mb();
> - if (unlikely(sb->s_writers.frozen >= level)) {
> - __sb_end_write(sb, level);
> - goto retry;
> - }
> -
> - if (!wait)
> - 

[tip:ras/core] x86/mce: Remove unused function declarations

[tip-bot for Ashok Raj]

Commit-ID:  4d1d5cdc345d15e09518a2410f7fcd069465ffac
Gitweb: http://git.kernel.org/tip/4d1d5cdc345d15e09518a2410f7fcd069465ffac
Author: Ashok Raj 
AuthorDate: Wed, 12 Aug 2015 18:29:39 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:52 +0200

x86/mce: Remove unused function declarations

Remove unused function declarations.

Signed-off-by: Ashok Raj 
Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: linux-edac 
Link: http://lkml.kernel.org/r/1439396985-12812-8-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/mce.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 982dfc3..38d3a1a8 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -185,16 +185,12 @@ void cmci_clear(void);
 void cmci_reenable(void);
 void cmci_rediscover(void);
 void cmci_recheck(void);
-void lmce_clear(void);
-void lmce_enable(void);
 #else
 static inline void mce_intel_feature_init(struct cpuinfo_x86 *c) { }
 static inline void cmci_clear(void) {}
 static inline void cmci_reenable(void) {}
 static inline void cmci_rediscover(void) {}
 static inline void cmci_recheck(void) {}
-static inline void lmce_clear(void) {}
-static inline void lmce_enable(void) {}
 #endif
 
 #ifdef CONFIG_X86_MCE_AMD
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:ras/core] x86/mce: Avoid potential deadlock due to printk() in MCE context

[tip-bot for Chen, Gong]

Commit-ID:  f29a7aff4bd60ebc3da4982f80144a4158c4c74a
Gitweb: http://git.kernel.org/tip/f29a7aff4bd60ebc3da4982f80144a4158c4c74a
Author: Chen, Gong 
AuthorDate: Wed, 12 Aug 2015 18:29:37 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:51 +0200

x86/mce: Avoid potential deadlock due to printk() in MCE context

Printing in MCE context is a no-no, currently, as printk() is
not NMI-safe. If some of the notifiers on the MCE chain call do
so, we may deadlock. In order to avoid that, delay printk() to
process context where it is safe.

Reported-by: Xie XiuQi 
Signed-off-by: Chen, Gong 
[ Fold in subsequent patch from Boris for early boot logging. ]
Signed-off-by: Tony Luck 
[ Kick irq_work in mce_log() directly. ]
Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1439396985-12812-6-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/mcheck/mce-apei.c  | 1 -
 arch/x86/kernel/cpu/mcheck/mce.c   | 4 ++--
 arch/x86/kernel/cpu/mcheck/mce_intel.c | 1 -
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce-apei.c 
b/arch/x86/kernel/cpu/mcheck/mce-apei.c
index a1aef95..34c89a3 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-apei.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-apei.c
@@ -57,7 +57,6 @@ void apei_mce_report_mem_error(int severity, struct 
cper_sec_mem_err *mem_err)
 
m.addr = mem_err->physical_addr;
mce_log();
-   mce_notify_irq();
 }
 EXPORT_SYMBOL_GPL(apei_mce_report_mem_error);
 
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 8260369..9568bb5 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -159,7 +159,8 @@ void mce_log(struct mce *mce)
/* Emit the trace record: */
trace_mce_record(mce);
 
-   atomic_notifier_call_chain(_mce_decoder_chain, 0, mce);
+   if (!mce_gen_pool_add(mce))
+   irq_work_queue(_irq_work);
 
mce->finished = 0;
wmb();
@@ -1122,7 +1123,6 @@ void do_machine_check(struct pt_regs *regs, long 
error_code)
/* assuming valid severity level != 0 */
m.severity = severity;
m.usable_addr = mce_usable_address();
-   mce_gen_pool_add();
 
mce_log();
 
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c 
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index 844f56c..70f567f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -246,7 +246,6 @@ static void intel_threshold_interrupt(void)
return;
 
machine_check_poll(MCP_TIMESTAMP, this_cpu_ptr(_banks_owned));
-   mce_notify_irq();
 }
 
 /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:ras/core] x86/mce: Kill drain_mcelog_buffer()

[tip-bot for Borislav Petkov]

Commit-ID:  eef4dfa0cb83899c782935ac5345532f47073cea
Gitweb: http://git.kernel.org/tip/eef4dfa0cb83899c782935ac5345532f47073cea
Author: Borislav Petkov 
AuthorDate: Wed, 12 Aug 2015 18:29:38 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:52 +0200

x86/mce: Kill drain_mcelog_buffer()

This used to flush out MCEs logged during early boot and which
were in the MCA registers from a previous system run. No need
for that now, since we've moved to a genpool.

Suggested-by: Tony Luck 
Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1439396985-12812-7-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/mce.h   |  2 +-
 arch/x86/kernel/cpu/mcheck/mce.c | 44 ++--
 drivers/acpi/acpi_extlog.c   |  2 +-
 drivers/edac/i7core_edac.c   |  2 +-
 drivers/edac/mce_amd.c   |  2 +-
 drivers/edac/sb_edac.c   |  2 +-
 6 files changed, 7 insertions(+), 47 deletions(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index dfaa4de..982dfc3 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -140,7 +140,7 @@ struct mce_vendor_flags {
 extern struct mce_vendor_flags mce_flags;
 
 extern struct mca_config mca_cfg;
-extern void mce_register_decode_chain(struct notifier_block *nb, bool drain);
+extern void mce_register_decode_chain(struct notifier_block *nb);
 extern void mce_unregister_decode_chain(struct notifier_block *nb);
 
 #include 
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 9568bb5..32b586e 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -199,55 +199,15 @@ void mce_log(struct mce *mce)
set_bit(0, _need_notify);
 }
 
-static void drain_mcelog_buffer(void)
-{
-   unsigned int next, i, prev = 0;
-
-   next = ACCESS_ONCE(mcelog.next);
-
-   do {
-   struct mce *m;
-
-   /* drain what was logged during boot */
-   for (i = prev; i < next; i++) {
-   unsigned long start = jiffies;
-   unsigned retries = 1;
-
-   m = [i];
-
-   while (!m->finished) {
-   if (time_after_eq(jiffies, start + 2*retries))
-   retries++;
-
-   cpu_relax();
-
-   if (!m->finished && retries >= 4) {
-   pr_err("skipping error being logged 
currently!\n");
-   break;
-   }
-   }
-   smp_rmb();
-   atomic_notifier_call_chain(_mce_decoder_chain, 0, 
m);
-   }
-
-   memset(mcelog.entry + prev, 0, (next - prev) * sizeof(*m));
-   prev = next;
-   next = cmpxchg(, prev, 0);
-   } while (next != prev);
-}
-
 static struct notifier_block mce_srao_nb;
 
-void mce_register_decode_chain(struct notifier_block *nb, bool drain)
+void mce_register_decode_chain(struct notifier_block *nb)
 {
/* Ensure SRAO notifier has the highest priority in the decode chain. */
if (nb != _srao_nb && nb->priority == INT_MAX)
nb->priority -= 1;
 
atomic_notifier_chain_register(_mce_decoder_chain, nb);
-
-   if (drain)
-   drain_mcelog_buffer();
 }
 EXPORT_SYMBOL_GPL(mce_register_decode_chain);
 
@@ -2028,7 +1988,7 @@ __setup("mce", mcheck_enable);
 int __init mcheck_init(void)
 {
mcheck_intel_therm_init();
-   mce_register_decode_chain(_srao_nb, false);
+   mce_register_decode_chain(_srao_nb);
mcheck_vendor_init_severity();
 
INIT_WORK(_work, mce_process_work);
diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
index 07e012e..b3842ff 100644
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@ -286,7 +286,7 @@ static int __init extlog_init(void)
 */
old_edac_report_status = get_edac_report_status();
set_edac_report_status(EDAC_REPORTING_DISABLED);
-   mce_register_decode_chain(_mce_dec, true);
+   mce_register_decode_chain(_mce_dec);
/* enable OS to be involved to take over management from BIOS */
((struct extlog_l1_head *)extlog_l1_addr)->flags |= FLAG_OS_OPTIN;
 
diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index 13d77f4..01087a3 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -2424,7 +2424,7 @@ static int __init i7core_init(void)
pci_rc = pci_register_driver(_driver);
 
if (pci_rc >= 0) {
-   mce_register_decode_chain(_mce_dec, true);
+   mce_register_decode_chain(_mce_dec);
return 0;
}
 
diff --git a/drivers/edac/mce_amd.c 

[tip:ras/core] x86/mce: Remove the MCE ring for Action Optional errors

[tip-bot for Chen, Gong]

Commit-ID:  fd4cf79fcc4b5130ced8fd8c40378d3cec2e5fa8
Gitweb: http://git.kernel.org/tip/fd4cf79fcc4b5130ced8fd8c40378d3cec2e5fa8
Author: Chen, Gong 
AuthorDate: Wed, 12 Aug 2015 18:29:36 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:51 +0200

x86/mce: Remove the MCE ring for Action Optional errors

Use unified genpool to save Action Optional error events and put
Action Optional error handling in the same notification chain as
MCE error decoding.

Signed-off-by: Chen, Gong 
[ Fold in subsequent patch from Boris for early boot logging. ]
Signed-off-by: Tony Luck 
[ Correct a lot. ]
Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1439396985-12812-5-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/mce.h   |   2 +-
 arch/x86/kernel/cpu/mcheck/mce.c | 135 +--
 drivers/acpi/acpi_extlog.c   |   2 +-
 drivers/edac/i7core_edac.c   |   2 +-
 drivers/edac/mce_amd.c   |   2 +-
 drivers/edac/sb_edac.c   |   2 +-
 6 files changed, 65 insertions(+), 80 deletions(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 982dfc3..dfaa4de 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -140,7 +140,7 @@ struct mce_vendor_flags {
 extern struct mce_vendor_flags mce_flags;
 
 extern struct mca_config mca_cfg;
-extern void mce_register_decode_chain(struct notifier_block *nb);
+extern void mce_register_decode_chain(struct notifier_block *nb, bool drain);
 extern void mce_unregister_decode_chain(struct notifier_block *nb);
 
 #include 
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 456f8d7..8260369 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -114,6 +114,7 @@ static struct work_struct mce_work;
 static struct irq_work mce_irq_work;
 
 static void (*quirk_no_way_out)(int bank, struct mce *m, struct pt_regs *regs);
+static int mce_usable_address(struct mce *m);
 
 /*
  * CPU/chipset specific EDAC code can register a notifier call here to print
@@ -234,11 +235,18 @@ static void drain_mcelog_buffer(void)
} while (next != prev);
 }
 
+static struct notifier_block mce_srao_nb;
 
-void mce_register_decode_chain(struct notifier_block *nb)
+void mce_register_decode_chain(struct notifier_block *nb, bool drain)
 {
+   /* Ensure SRAO notifier has the highest priority in the decode chain. */
+   if (nb != _srao_nb && nb->priority == INT_MAX)
+   nb->priority -= 1;
+
atomic_notifier_chain_register(_mce_decoder_chain, nb);
-   drain_mcelog_buffer();
+
+   if (drain)
+   drain_mcelog_buffer();
 }
 EXPORT_SYMBOL_GPL(mce_register_decode_chain);
 
@@ -462,61 +470,6 @@ static inline void mce_gather_info(struct mce *m, struct 
pt_regs *regs)
}
 }
 
-/*
- * Simple lockless ring to communicate PFNs from the exception handler with the
- * process context work function. This is vastly simplified because there's
- * only a single reader and a single writer.
- */
-#define MCE_RING_SIZE 16   /* we use one entry less */
-
-struct mce_ring {
-   unsigned short start;
-   unsigned short end;
-   unsigned long ring[MCE_RING_SIZE];
-};
-static DEFINE_PER_CPU(struct mce_ring, mce_ring);
-
-/* Runs with CPU affinity in workqueue */
-static int mce_ring_empty(void)
-{
-   struct mce_ring *r = this_cpu_ptr(_ring);
-
-   return r->start == r->end;
-}
-
-static int mce_ring_get(unsigned long *pfn)
-{
-   struct mce_ring *r;
-   int ret = 0;
-
-   *pfn = 0;
-   get_cpu();
-   r = this_cpu_ptr(_ring);
-   if (r->start == r->end)
-   goto out;
-   *pfn = r->ring[r->start];
-   r->start = (r->start + 1) % MCE_RING_SIZE;
-   ret = 1;
-out:
-   put_cpu();
-   return ret;
-}
-
-/* Always runs in MCE context with preempt off */
-static int mce_ring_add(unsigned long pfn)
-{
-   struct mce_ring *r = this_cpu_ptr(_ring);
-   unsigned next;
-
-   next = (r->end + 1) % MCE_RING_SIZE;
-   if (next == r->start)
-   return -1;
-   r->ring[r->end] = pfn;
-   wmb();
-   r->end = next;
-   return 0;
-}
-
 int mce_available(struct cpuinfo_x86 *c)
 {
if (mca_cfg.disabled)
@@ -526,7 +479,7 @@ int mce_available(struct cpuinfo_x86 *c)
 
 static void mce_schedule_work(void)
 {
-   if (!mce_ring_empty())
+   if (!mce_gen_pool_empty() && keventd_up())
schedule_work(_work);
 }
 
@@ -553,6 +506,27 @@ static void mce_report_event(struct pt_regs *regs)
irq_work_queue(_irq_work);
 }
 
+static int srao_decode_notifier(struct notifier_block *nb, unsigned long val,
+   void *data)
+{
+   struct mce *mce = (struct mce *)data;
+   unsigned long pfn;
+
+   if (!mce)
+   return NOTIFY_DONE;
+
+   if 

[tip:ras/core] x86/mce: Provide a lockless memory pool to save error records

[tip-bot for Chen, Gong]

Commit-ID:  648ed94038c030245a06e4be59744fd5cdc18c40
Gitweb: http://git.kernel.org/tip/648ed94038c030245a06e4be59744fd5cdc18c40
Author: Chen, Gong 
AuthorDate: Wed, 12 Aug 2015 18:29:34 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:50 +0200

x86/mce: Provide a lockless memory pool to save error records

printk() is not safe to use in MCE context. Add a lockless
memory allocator pool to save error records in MCE context.
Those records will be issued later, in a printk-safe context.
The idea is inspired by the APEI/GHES driver.

We're very conservative and allocate only two pages for it but
since we're going to use those pages throughout the system's
lifetime, we allocate them statically to avoid early boot time
allocation woes.

Signed-off-by: Chen, Gong 
[ Rewrite. ]
Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Link: http://lkml.kernel.org/r/1439396985-12812-3-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/Kconfig  |  1 +
 arch/x86/kernel/cpu/mcheck/Makefile   |  2 +-
 arch/x86/kernel/cpu/mcheck/mce-genpool.c  | 99 +++
 arch/x86/kernel/cpu/mcheck/mce-internal.h | 12 
 arch/x86/kernel/cpu/mcheck/mce.c  |  8 ++-
 5 files changed, 120 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b3a1a5d..06dbb5d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -955,6 +955,7 @@ config X86_REROUTE_FOR_BROKEN_BOOT_IRQS
 
 config X86_MCE
bool "Machine Check / overheating reporting"
+   select GENERIC_ALLOCATOR
default y
---help---
  Machine Check support allows the processor to notify the
diff --git a/arch/x86/kernel/cpu/mcheck/Makefile 
b/arch/x86/kernel/cpu/mcheck/Makefile
index bb34b03..a3311c8 100644
--- a/arch/x86/kernel/cpu/mcheck/Makefile
+++ b/arch/x86/kernel/cpu/mcheck/Makefile
@@ -1,4 +1,4 @@
-obj-y  =  mce.o mce-severity.o
+obj-y  =  mce.o mce-severity.o mce-genpool.o
 
 obj-$(CONFIG_X86_ANCIENT_MCE)  += winchip.o p5.o
 obj-$(CONFIG_X86_MCE_INTEL)+= mce_intel.o
diff --git a/arch/x86/kernel/cpu/mcheck/mce-genpool.c 
b/arch/x86/kernel/cpu/mcheck/mce-genpool.c
new file mode 100644
index 000..0a85010
--- /dev/null
+++ b/arch/x86/kernel/cpu/mcheck/mce-genpool.c
@@ -0,0 +1,99 @@
+/*
+ * MCE event pool management in MCE context
+ *
+ * Copyright (C) 2015 Intel Corp.
+ * Author: Chen, Gong 
+ *
+ * This file is licensed under GPLv2.
+ */
+#include 
+#include 
+#include 
+#include 
+#include "mce-internal.h"
+
+/*
+ * printk() is not safe in MCE context. This is a lock-less memory allocator
+ * used to save error information organized in a lock-less list.
+ *
+ * This memory pool is only to be used to save MCE records in MCE context.
+ * MCE events are rare, so a fixed size memory pool should be enough. Use
+ * 2 pages to save MCE events for now (~80 MCE records at most).
+ */
+#define MCE_POOLSZ (2 * PAGE_SIZE)
+
+static struct gen_pool *mce_evt_pool;
+static LLIST_HEAD(mce_event_llist);
+static char gen_pool_buf[MCE_POOLSZ];
+
+void mce_gen_pool_process(void)
+{
+   struct llist_node *head;
+   struct mce_evt_llist *node;
+   struct mce *mce;
+
+   head = llist_del_all(_event_llist);
+   if (!head)
+   return;
+
+   head = llist_reverse_order(head);
+   llist_for_each_entry(node, head, llnode) {
+   mce = >mce;
+   atomic_notifier_call_chain(_mce_decoder_chain, 0, mce);
+   gen_pool_free(mce_evt_pool, (unsigned long)node, sizeof(*node));
+   }
+}
+
+bool mce_gen_pool_empty(void)
+{
+   return llist_empty(_event_llist);
+}
+
+int mce_gen_pool_add(struct mce *mce)
+{
+   struct mce_evt_llist *node;
+
+   if (!mce_evt_pool)
+   return -EINVAL;
+
+   node = (void *)gen_pool_alloc(mce_evt_pool, sizeof(*node));
+   if (!node) {
+   pr_warn_ratelimited("MCE records pool full!\n");
+   return -ENOMEM;
+   }
+
+   memcpy(>mce, mce, sizeof(*mce));
+   llist_add(>llnode, _event_llist);
+
+   return 0;
+}
+
+static int mce_gen_pool_create(void)
+{
+   struct gen_pool *tmpp;
+   int ret = -ENOMEM;
+
+   tmpp = gen_pool_create(ilog2(sizeof(struct mce_evt_llist)), -1);
+   if (!tmpp)
+   goto out;
+
+   ret = gen_pool_add(tmpp, (unsigned long)gen_pool_buf, MCE_POOLSZ, -1);
+   if (ret) {
+   gen_pool_destroy(tmpp);
+   goto out;
+   }
+
+   mce_evt_pool = tmpp;
+
+out:
+   return ret;
+}
+
+int mce_gen_pool_init(void)
+{
+   /* Just init mce_gen_pool once. */
+   if (mce_evt_pool)
+   return 0;
+
+   return mce_gen_pool_create();
+}
diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h 
b/arch/x86/kernel/cpu/mcheck/mce-internal.h
index fe32074..ea8b622 100644
--- 

[tip:ras/core] x86/mce: Don't use percpu workqueues

[tip-bot for Chen, Gong]

Commit-ID:  061120aed7081b9a4393fbe07b558192f40ad911
Gitweb: http://git.kernel.org/tip/061120aed7081b9a4393fbe07b558192f40ad911
Author: Chen, Gong 
AuthorDate: Wed, 12 Aug 2015 18:29:35 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:51 +0200

x86/mce: Don't use percpu workqueues

An MCE is a rare event. Therefore, there's no need to have
per-CPU instances of both normal and IRQ workqueues. Make them
both global.

Signed-off-by: Chen, Gong 
[ Fold in subsequent patch from Rui/Boris/Tony for early boot logging. ]
Signed-off-by: Tony Luck 
[ Massage commit message. ]
Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1439396985-12812-4-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index a41c014..456f8d7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -110,7 +110,8 @@ DEFINE_PER_CPU(mce_banks_t, mce_poll_banks) = {
  */
 mce_banks_t mce_banks_ce_disabled;
 
-static DEFINE_PER_CPU(struct work_struct, mce_work);
+static struct work_struct mce_work;
+static struct irq_work mce_irq_work;
 
 static void (*quirk_no_way_out)(int bank, struct mce *m, struct pt_regs *regs);
 
@@ -526,11 +527,9 @@ int mce_available(struct cpuinfo_x86 *c)
 static void mce_schedule_work(void)
 {
if (!mce_ring_empty())
-   schedule_work(this_cpu_ptr(_work));
+   schedule_work(_work);
 }
 
-static DEFINE_PER_CPU(struct irq_work, mce_irq_work);
-
 static void mce_irq_work_cb(struct irq_work *entry)
 {
mce_notify_irq();
@@ -551,7 +550,7 @@ static void mce_report_event(struct pt_regs *regs)
return;
}
 
-   irq_work_queue(this_cpu_ptr(_irq_work));
+   irq_work_queue(_irq_work);
 }
 
 /*
@@ -1742,8 +1741,6 @@ void mcheck_cpu_init(struct cpuinfo_x86 *c)
__mcheck_cpu_init_generic();
__mcheck_cpu_init_vendor(c);
__mcheck_cpu_init_timer();
-   INIT_WORK(this_cpu_ptr(_work), mce_process_work);
-   init_irq_work(this_cpu_ptr(_irq_work), _irq_work_cb);
 }
 
 /*
@@ -2064,6 +2061,9 @@ int __init mcheck_init(void)
mcheck_intel_therm_init();
mcheck_vendor_init_severity();
 
+   INIT_WORK(_work, mce_process_work);
+   init_irq_work(_irq_work, mce_irq_work_cb);
+
return 0;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:ras/core] x86/mce: Reuse one of the u16 padding fields in ' struct mce'

[tip-bot for Borislav Petkov]

Commit-ID:  20d51a426fe9a0d0a63cc3a7488f621c8bac37e1
Gitweb: http://git.kernel.org/tip/20d51a426fe9a0d0a63cc3a7488f621c8bac37e1
Author: Borislav Petkov 
AuthorDate: Wed, 12 Aug 2015 18:29:33 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 13 Aug 2015 10:12:50 +0200

x86/mce: Reuse one of the u16 padding fields in 'struct mce'

... to save the error severity of the MCE and whether the
reported address of the error is usable.

Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Link: http://lkml.kernel.org/r/1439396985-12812-2-git-send-email...@alien8.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/uapi/asm/mce.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/uapi/asm/mce.h b/arch/x86/include/uapi/asm/mce.h
index a0eab85..76880ed 100644
--- a/arch/x86/include/uapi/asm/mce.h
+++ b/arch/x86/include/uapi/asm/mce.h
@@ -15,7 +15,8 @@ struct mce {
__u64 time; /* wall time_t when error was detected */
__u8  cpuvendor;/* cpu vendor as encoded in system.h */
__u8  inject_flags; /* software inject flags */
-   __u16  pad;
+   __u8  severity;
+   __u8  usable_addr;
__u32 cpuid;/* CPUID 1 EAX */
__u8  cs;   /* code segment */
__u8  bank; /* machine check bank */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: UniPhier: drop v7_invalidate_l1 call at secondary entry

[Olof Johansson]

On Sat, Aug 08, 2015 at 09:13:44PM +0900, Masahiro Yamada wrote:
> This is unnecessary since commit 02b4e2756e01 ("ARM: v7 setup
> function should invalidate L1 cache").
> 
> Signed-off-by: Masahiro Yamada 
> ---

Applied, thanks.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] at91: dt for 4.3 #2

[Olof Johansson]

On Fri, Aug 07, 2015 at 05:45:44PM +0200, Alexandre Belloni wrote:
> 
> Arnd, Olof, Kevin,
> 
> This is the second batch of DT changes for 4.3.
> It is mainly some preparation to support properly getting the slow clock
> from each driver so that the dtsis are ready when the driver change
> lands in each subsystem.
> 
> It also adds support for the lcd controller on at91sam9x5 and
> at91sam9n12. The driver changes have been submitted but didn't yet land
> in the drm and mfd subsystem however, I don't expect any issue getting
> those in.
> 
> Thanks, best regards,
> 
> The following changes since commit 22b5a0f7bc07ac4b4e4aab9a7f8cf2521819c1c4:
> 
>   ARM: at91/dt: add minimal sama5d2 Xplained board (2015-07-30 18:44:44 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> tags/at91-ab-dt2
> 
> for you to fetch changes up to 761c5867ef031fae244d030bc17c93f5a3df106f:
> 
>   ARM: at91/dt: sama5d2: use slow clock where necessary (2015-08-07 17:33:54 
> +0200)

Merged, thanks!


-Olof

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

Re: [PATCH] ARM: Feroceon: use of_iomap() to map register base

[Olof Johansson]

On Sat, Aug 08, 2015 at 09:11:39PM +0900, Masahiro Yamada wrote:
> The sequence of of_address_to_resource() and ioremap() can be
> replaced with of_iomap().
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Olof Johansson 

Please submit this to Russell's patch tracker, he's usually the one who merges
patches to arch/arm/mm/*.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] Samsung mach fixes for 4.2

[Olof Johansson]

On Mon, Aug 10, 2015 at 11:04:25AM +0900, Kukjin Kim wrote:
> Hi arm-soc guys,
> 
> Can you please pull this into arm-soc fixes for v4.2 directly?
> I don't have other samsung fixes in my tree at this moment.
> 
> Thanks,
> Kukjin
> 
> Krzysztof Kozlowski wrote:
> > 
> > Dear Kukjin,
> > 
> > Please find latest two fixes for v4.2 cycle. You can find more detailed
> > description with the tag.
> > 
> > Best regards,
> > Krzysztof
> > 
> > 
> > The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
> > 
> >   Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
> > 
> > are available in the git repository at:
> > 
> >   https://github.com/krzk/linux.git tags/samsung-mach-fixes-4.2
> > 
> > for you to fetch changes up to 3e9f798784b30293012682021d5a0352f78658b8:
> > 
> >   ARM: EXYNOS: fix double of_node_put() on error path (2015-07-31 10:12:17 
> > +0900)

Merged, thanks.


-Olof

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

Re: [GIT PULL] at91: defconfig for 4.3 #2

[Olof Johansson]

On Fri, Aug 07, 2015 at 06:27:54PM +0200, Alexandre Belloni wrote:
> Arnd, Olof, Kevin,
> 
> A little defconfig update. That will probably be all for this cycle.
> 
> Thanks, bye,
> 
> 
> The following changes since commit eff7f41572a645bf14a96a6f844be4f1c88cd9dd:
> 
>   ARM: at91: at91_dt_defconfig: enable ISI and ov2640 support (2015-07-30 
> 14:17:31 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
> tags/at91-ab-defconfig2
> 
> for you to fetch changes up to ea7bf603fd494391acc1f42acbfc34260b965c44:
> 
>   ARM: at91/defconfig: at91_dt: remove ARM_AT91_ETHER (2015-08-07 12:07:50 
> +0200)

Nicolas had sent me one patch which you've also included here but it's not in
the pull request ("enable ISI and ov2640 support"). That caused a conflict
here, so to avoid having the patch in the tree twice I instead also directly
applied your patches from this branch instead of merging.

Sorry about that, it started due to Nicolas sending the discrete patch to us.
So it seems like we'll apply at91 defconfig updates directly this release, in
case there are any more. No big deal I hope. :)


-Olof

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

Re: [GIT PULL] RPi DT changes due for v4.3

[Olof Johansson]

Hi,

On Tue, Aug 11, 2015 at 05:06:42PM +0100, Lee Jones wrote:
> ARM SoC Chaps,
> 
> Please find a couple of simple RPi changes pertaining to Firmware.
> 
> The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:
> 
>   Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git 
> tags/rpi-dt-for-armsoc-4.3
> 
> for you to fetch changes up to fd26f8830979de48eb3f1c253eb9d2ee2e468eb6:
> 
>   dt/bindings: Add binding for the Raspberry Pi firmware driver (2015-08-11 
> 16:56:41 +0100)

I've merged this but I'm a little confused about bcm2835 maintainership:
I got a MAINTAINERS update from Florian earlier grouped in a set of
other bcm changes (adding Eric), and now this directly from you.

In general the bcm platforms are quite diverse and we've asked Florian
to be the funnel for all of the new ones, but I don't think we talked
much about 2835 at that time. Should we expect to see merges directly
from you and the other maintainers there or will it go through Florian?

Either way is OK with me, just looking to clarify.


Thanks!

-Olof

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

Re: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register

[Krzysztof Kozlowski]

W dniu 13.08.2015 o 19:02, Krzysztof Kozlowski pisze:
> W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>> buffer via setting WUDR bit to high after ctrl register is updated.
> 
> Hi,
> 
> I cannot find this information in S2MPS14 datasheet. On which page is it?
> 
> 
>>
>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>> used to 12 hour mode in Odroid-XU3 board.
> 
> Two questions here:
> 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
> Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
> S2MP14)? There are some minor differences between them so I would not be
> surprised if only some of them required this action.
> 
> 2. The driver operates in 24-hour omode. Actually it sets the 24-hour
> mode just before your new regmap_update_bits() call. What do you mean by
> 12-hour mode?
> 
>> Signed-off-by: Joonyoung Shim 
>> Cc: 
> 
> Thanks for putting a cc-stable tag. How far this should be ported? If
> this is needed only for S2MPS11 then v4.1. If all of them then probably
> for earlier version?
> 
> Best regards,
> Krzysztof

One more doubt. On my Odroid XU3 first and consecutive executions
(including first) of rtctest run fine. They pass. Can you describe
exactly observable issue and how to reproduce it? This is also important
as a reason for stable backport.

I tested it on next-20150729 on board with Hardkernel bootloader. Maybe
the bootloader sets 12-hour mode which cannot be switched to 24-hour?

Best regards,
Krzysztof



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

Re: [PATCH v2 5/6] mailbox: Add generic mechanism for testing Mailbox Controllers

[Jassi Brar]

On Thu, Aug 13, 2015 at 3:53 PM, Lee Jones  wrote:
> On Thu, 13 Aug 2015, Jassi Brar wrote:
>
>> On Thu, Aug 13, 2015 at 2:49 PM, Lee Jones  wrote:
>> > On Thu, 13 Aug 2015, Jassi Brar wrote:
>>
>> >> >> > +
>> >> >> > +static void mbox_test_prepare_message(struct mbox_client *client, 
>> >> >> > void *message)
>> >> >> > +{
>> >> >> > +   struct mbox_test_device *tdev = dev_get_drvdata(client->dev);
>> >> >> > +
>> >> >> > +   if (tdev->mmio)
>> >> >> > +   memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
>> >> >> >
>> >> >> This is unlikely to work. Those platforms that need to send a 2 part
>> >> >> message, they do :
>> >> >> (a) Signal/Command/Target code via some controller register (via
>> >> >> mbox_send_message).
>> >> >> (b) Setup the payload in Shared-Memory (via tx_prepare).
>> >> >>
>> >> >> This test driver assumes both are the same. I think you have to
>> >> >> declare something like
>> >> >
>> >> > This driver assumes that the framework will call client->tx_prepare()
>> >> > first, which satisfies (b).  It then assumes controller->send_data()
>> >> > will be invoked, which will send the platform specific
>> >> > signal/command/target code, which then satisfies (a).
>> >> >
>> >> Yeah, but what would be that code? Who provides that?
>> >>
>> >> > In what way does it assume they are the same?
>> >> >
>> >> notice the 'message' pointer in
>> >> mbox_send_message(tdev->tx_channel, message);
>> >> and
>> >> memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
>> >>
>> >> >> struct mbox_test_message { /* same for TX and RX */
>> >> >>   unsigned sig_len;
>> >> >>   void *signal;   /* rx/tx via mailbox api */
>> >> >>   unsigned pl_len;
>> >> >>   void *payload;   /* rx/tx via shared-memory */
>> >> >> };
>> >> >
>> >> > How do you think this should be set and use these?
>> >> >
>> >> The userspace would want to specify the command code (32bits or not)
>> >> that would be passed via the fifo/register of the controller. So we
>> >> need signal[]
>> >>
>> >> The data to be passed via share-memory could be provided by userspace
>> >> via the payload[] array.
>> >
>> > Okay, so would the solution be two userspace files 'signal' and
>> > 'message', so in the case of a client specified signal we can write it
>> > into there first.
>> >
>> > echo 255  > signal
>> > echo test > message
>> >
>> > ... or in the case where no signal is required, or the controller
>> > driver taking care of it, we just don't write anything to signal?
>> >
>> file_operations.write() should parse signal and message, coming from
>> userspace, into a local structure before routing them via
>> mbox_send_message and tx_prepare respectively.
>
> Okay.  So before I code this up we should agree on syntax.
>
> How would you like to represent the break between signal and message?
> Obviously ' ' would be a bad idea, as some clients may want to send
> messages with white space contained.  How about '\t' or '\n'?
>
Yeah, I am not a fan of markers and flags either.

Maybe we should share with userspace
  struct mbox_test_message { /* same for TX and RX */
   unsigned sig_len;
   void __user *signal;/* rx/tx via mailbox api */
   unsigned pl_len;
   void __user *payload;/* rx/tx via shared-memory */
  };

First copy_from_user the structure of length sizof(struct
mbox_test_message) and then copy_from_user length sig_len and pl_len
from signal[] and payload[] respectively (usually ioctls would carry
such data).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

[Jan Kara]

On Tue 11-08-15 19:04:16, Oleg Nesterov wrote:
> Of course, this patch is ugly as hell. It will be (partially)
> reverted later. We add it to ensure that other WIP changes in
> percpu_rw_semaphore won't break fs/super.c.
> 
> We do not even need this change right now, percpu_free_rwsem()
> is fine in atomic context. But we are going to change this, it
> will be might_sleep() after we merge the rcu_sync() patches.
> 
> And even after that we do not really need destroy_super_work(),
> we will kill it in any case. Instead, destroy_super_rcu() should
> just check that rss->cb_state == CB_IDLE and do call_rcu() again
> in the (very unlikely) case this is not true.
> 
> So this is just the temporary kludge which helps us to avoid the
> conflicts with the changes which will be (hopefully) routed via
> rcu tree.
> 
> Signed-off-by: Oleg Nesterov 

Looking into this again, it would seem somewhat cleaner to me to move the
destruction to deactivate_locked_super() instead. We already do this for
list_lru_destroy() because that can sleep as well and so I'd prefer to keep
these two things together. You have to be somewhat careful with the failure
path in alloc_super() but that's easily doable...

Honza

> ---
>  fs/super.c |   23 +++
>  include/linux/fs.h |3 ++-
>  2 files changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/super.c b/fs/super.c
> index 89b58fb..75436e2 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -135,6 +135,24 @@ static unsigned long super_cache_count(struct shrinker 
> *shrink,
>   return total_objects;
>  }
>  
> +static void destroy_super_work(struct work_struct *work)
> +{
> + struct super_block *s = container_of(work, struct super_block,
> + destroy_work);
> + int i;
> +
> + for (i = 0; i < SB_FREEZE_LEVELS; i++)
> + percpu_counter_destroy(>s_writers.counter[i]);
> + kfree(s);
> +}
> +
> +static void destroy_super_rcu(struct rcu_head *head)
> +{
> + struct super_block *s = container_of(head, struct super_block, rcu);
> + INIT_WORK(>destroy_work, destroy_super_work);
> + schedule_work(>destroy_work);
> +}
> +
>  /**
>   *   destroy_super   -   frees a superblock
>   *   @s: superblock to free
> @@ -143,16 +161,13 @@ static unsigned long super_cache_count(struct shrinker 
> *shrink,
>   */
>  static void destroy_super(struct super_block *s)
>  {
> - int i;
>   list_lru_destroy(>s_dentry_lru);
>   list_lru_destroy(>s_inode_lru);
> - for (i = 0; i < SB_FREEZE_LEVELS; i++)
> - percpu_counter_destroy(>s_writers.counter[i]);
>   security_sb_free(s);
>   WARN_ON(!list_empty(>s_mounts));
>   kfree(s->s_subtype);
>   kfree(s->s_options);
> - kfree_rcu(s, rcu);
> + call_rcu(>rcu, destroy_super_rcu);
>  }
>  
>  /**
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 78ac768..6addccc 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1346,7 +1347,7 @@ struct super_block {
>   struct list_lru s_dentry_lru cacheline_aligned_in_smp;
>   struct list_lru s_inode_lru cacheline_aligned_in_smp;
>   struct rcu_head rcu;
> -
> + struct work_struct  destroy_work;
>   /*
>* Indicates how deep in a filesystem stack this SB is
>*/
> -- 
> 1.5.5.1
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Remove unselectable rule for arm-exynos-cpufreq.o

[Viresh Kumar]

On 13-08-15, 12:32, Jonas Rabenstein wrote:
> With commit 2907ed4377d9 ("cpufreq: exynos: remove Exynos4x12 specific
> cpufreq driver support"), the last specific Exynos-cpufreq driver
> depending on ARM_EXYNOS_CPUFREQ was removed. As there is no
> Exynos-specific cpufreq driver depending on the code in
> drivers/cpufreq/exynos-cpufreq.c (selected by ARM_EXYNOS_CPUFREQ),
> this file was deleted and ARM_EXYNOS_CPUFREQ removed from Kconfig.
> After all, the rule in drivers/cpufreq/Makefile, to combine all
> specific cpufreq drivers depending on the generic code for Exynos into
> one objectfile is obsolete and can be removed.
> 
> Remove unselectable rule for arm-exynos-cpufreq.o from
> drivers/cpufreq/Makefile, which - if selectable - would generate an
> always empty objectfile.
> 
> Signed-off-by: Jonas Rabenstein 
> ---
> I found this inconsistency using the undertaker and
> undertaker-checkpatch tools (https://undertaker.cs.fau.de/).
> 
>  drivers/cpufreq/Makefile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index bbc4a9f..958be2b 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -52,7 +52,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += 
> arm_big_little_dt.o
>  
>  obj-$(CONFIG_ARCH_DAVINCI)   += davinci-cpufreq.o
>  obj-$(CONFIG_UX500_SOC_DB8500)   += dbx500-cpufreq.o
> -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += arm-exynos-cpufreq.o
>  obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
>  obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)   += highbank-cpufreq.o
>  obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ)  += hisi-acpu-cpufreq.o

Acked-by: Viresh Kumar 

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/6] genirq: fix irqchip_set_wake_parent if IRQCHIP_SKIP_SET_WAKE

[Sudeep Holla]

On 13/08/15 10:51, Grygorii Strashko wrote:

On 08/13/2015 11:54 AM, Sudeep Holla wrote:



On 12/08/15 18:45, Grygorii Strashko wrote:


[...]


diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6de638b..bdb1b9d 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1024,6 +1024,10 @@ int irq_chip_set_vcpu_affinity_parent(struct
irq_data *data, void *vcpu_info)
   int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
   {
   data = data->parent_data;
+
+if (irq_data_get_irq_chip(data)->flags & IRQCHIP_SKIP_SET_WAKE)
+return 0;
+


[Nit] I think the irq core can access data->chip directly. Either way,
it's better to be consistent, the statement following doesn't use helper
function.


thanks. I'll change it to:
if (data->chip->flags & IRQCHIP_SKIP_SET_WAKE)
return 0;



Otherwise looks good to me.


Does it means that I can add your Reviewed-by: with above change?



Yes you can.

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Remove unselectable rule for arm-exynos-cpufreq.o

[Jonas Rabenstein]

With commit 2907ed4377d9 ("cpufreq: exynos: remove Exynos4x12 specific
cpufreq driver support"), the last specific Exynos-cpufreq driver
depending on ARM_EXYNOS_CPUFREQ was removed. As there is no
Exynos-specific cpufreq driver depending on the code in
drivers/cpufreq/exynos-cpufreq.c (selected by ARM_EXYNOS_CPUFREQ),
this file was deleted and ARM_EXYNOS_CPUFREQ removed from Kconfig.
After all, the rule in drivers/cpufreq/Makefile, to combine all
specific cpufreq drivers depending on the generic code for Exynos into
one objectfile is obsolete and can be removed.

Remove unselectable rule for arm-exynos-cpufreq.o from
drivers/cpufreq/Makefile, which - if selectable - would generate an
always empty objectfile.

Signed-off-by: Jonas Rabenstein 
---
I found this inconsistency using the undertaker and
undertaker-checkpatch tools (https://undertaker.cs.fau.de/).

 drivers/cpufreq/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index bbc4a9f..958be2b 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ)   += 
arm_big_little_dt.o
 
 obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += arm-exynos-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)   += exynos5440-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
 obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ)+= hisi-acpu-cpufreq.o
-- 
2.5.0

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

Re: [PATCH v2 2/6] genirq: fix irqchip_set_wake_parent if IRQCHIP_SKIP_SET_WAKE

[Grygorii Strashko]

On 08/13/2015 01:01 PM, Marc Zyngier wrote:

On 12/08/15 18:45, Grygorii Strashko wrote:

The irqchip_set_wake_parent should not fail if IRQ chip
specifies IRQCHIP_SKIP_SET_WAKE. Otherwise, IRQ wakeup
configuration can't be propagated properly through IRQ
domains hierarchy.

In case of TI OMAP DRA7 the issue reproduced with following
configuration:
ARM GIC<-OMAP wakeupgen<-TI CBAR<-GPIO<-GPIO pcf857x<-gpio_key

gpio_key is wakeup source

Failure is reproduced during suspend/resume to RAM:
suspend:
  - gpio_keys_suspend
enable_irq_wake
  + pcf857x_irq_set_wake
+ omap_gpio_wake_enable
  + TI CBAR irq_chip_set_wake_parent
+ OMAP wakeupgen has no .irq_set_wake()


Most importantly, wakeupgen has IRQCHIP_SKIP_SET_WAKE set.


and -ENOSYS will be returned

resume:
  - gpio_keys_resume
+ disable_irq_wake
  + irq_set_irq_wake
+ WARN(1, "Unbalanced IRQ %d wake disable\n", irq);

Fixes: 08b55e2a9208 ('genirq: Add irqchip_set_wake_parent')
Signed-off-by: Grygorii Strashko 
---
  kernel/irq/chip.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6de638b..bdb1b9d 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1024,6 +1024,10 @@ int irq_chip_set_vcpu_affinity_parent(struct irq_data 
*data, void *vcpu_info)
  int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
  {
data = data->parent_data;
+
+   if (irq_data_get_irq_chip(data)->flags & IRQCHIP_SKIP_SET_WAKE)
+   return 0;
+
if (data->chip->irq_set_wake)
return data->chip->irq_set_wake(data, on);




We have a more general issue with chip flags, and how they combine
within a stack of irqchips.


Indeed. Problem looks similar to IRQCHIP_MASK_ON_SUSPEND flag usage.



What if you remove the irq_chip_set_wake_parent from the crossbar
driver, and instead set IRQCHIP_SKIP_SET_WAKE?


I've thought about this and it should work for me.
One question - what if crossbar will be not the last one in
IRQ domains hierarchy?


--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm/hwpoison: fix race between soft_offline_page and unpoison_memory

[Wanpeng Li]

On 8/13/15 6:04 PM, Naoya Horiguchi wrote:
> On Thu, Aug 13, 2015 at 05:18:56PM +0800, Wanpeng Li wrote:
>> On 8/13/15 4:53 PM, Naoya Horiguchi wrote:
> ...
>>> I think that unpoison is used only in testing so this race never affects
>>> our end-users/customers, so going back to this migratetype change stuff
>>> looks unworthy to me.
>> Migratetype stuff is just removed by you two months ago, then this bug
>> occurs recently since the more and more patches which you fix some races.
> Yes, this race (which existed before my recent changes) became more visible

IIUC, no. The page will be freed before PageHWPoison is set. So the race
doesn't exist.

> with that changes. But I don't think that simply reverting them is a right 
> solution.
>
>>> If I read correctly, the old migratetype approach has a few problems:
>>>   1) it doesn't fix the problem completely, because
>>>  set_migratetype_isolate() can fail to set MIGRATE_ISOLATE to the
>>>  target page if the pageblock of the page contains one or more
>>>  unmovable pages (i.e. has_unmovable_pages() returns true).
>>>   2) the original code changes migratetype to MIGRATE_ISOLATE forcibly,
>>>  and sets it to MIGRATE_MOVABLE forcibly after soft offline, regardless
>>>  of the original migratetype state, which could impact other subsystems
>>>  like memory hotplug or compaction.
>> Maybe we can add a "FIXME" comment on the Migratetype stuff, since the
>> current linus tree calltrace and it should be fixed immediately, and I
>> don't see obvious bugs appear on migratetype stuffs at least currently,
>> so "FIXME" is enough. :-)
> Sorry if confusing, but my intention in saying about "FIXME" comment was
> that we can find another solution for this race rather than just reverting,
> so adding comment about the reported bug in current code (keeping code from
> 4491f712606) is OK for very short term.
> I understand that leaving a race window of BUG_ON is not the best thing, but
> as I said, this race shouldn't affect end-users, so this is not an urgent bug.
> # It's enough if testers know this.

The 4.2 is coming, this patch can be applied as a temporal solution in
order to fix the broken linus tree, and the any final solution can be
figured out later.

Regards,
Wanpeng Li

>
>>> So in my opinion, the best option is to fix this within unpoison code,
>>> but it might be hard because we don't know whether the target page is
>> Exactly.
>>
>>> under migration. The second option is to add a race check in the if (reason
>>> == MR_MEMORY_FAILURE) branch in unmap_and_move(), although this looks ad-hoc
>> You have already add MR_MEMORY_FAILURE, however, that is not enough to
>> fix unpoison race.
> Right, some additional code is necessary. I'll try the second approach.
>
> Thanks,
> Naoya Horiguchi
>
>>> and need testing. The third option is to leave it with some "FIXME" comment.
>> I *prefer* add "FIXME" to migratetype stuffs.
>>
>> Regards,
>> Wanpeng Li
>>
>>> Thanks,
>>> Naoya Horiguchi
>>>
 ---
  include/linux/page-isolation.h |5 +
  mm/memory-failure.c|   16 
  mm/migrate.c   |3 +--
  mm/page_isolation.c|4 ++--
  4 files changed, 20 insertions(+), 8 deletions(-)

 diff --git a/include/linux/page-isolation.h 
 b/include/linux/page-isolation.h
 index 047d647..ff5751e 100644
 --- a/include/linux/page-isolation.h
 +++ b/include/linux/page-isolation.h
 @@ -65,6 +65,11 @@ undo_isolate_page_range(unsigned long start_pfn, 
 unsigned long end_pfn,
  int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn,
bool skip_hwpoisoned_pages);

 +/*
 + *  Internal functions. Changes pageblock's migrate type.
 + */
 +int set_migratetype_isolate(struct page *page, bool 
 skip_hwpoisoned_pages);
 +void unset_migratetype_isolate(struct page *page, unsigned migratetype);
  struct page *alloc_migrate_target(struct page *page, unsigned long 
 private,
int **resultp);

 diff --git a/mm/memory-failure.c b/mm/memory-failure.c
 index eca613e..0ed3814 100644
 --- a/mm/memory-failure.c
 +++ b/mm/memory-failure.c
 @@ -1647,8 +1647,6 @@ static int __soft_offline_page(struct page *page, 
 int flags)
inc_zone_page_state(page, NR_ISOLATED_ANON +
page_is_file_cache(page));
list_add(>lru, );
 -  if (!TestSetPageHWPoison(page))
 -  atomic_long_inc(_poisoned_pages);
ret = migrate_pages(, new_page, NULL, MPOL_MF_MOVE_ALL,
MIGRATE_SYNC, MR_MEMORY_FAILURE);
if (ret) {
 @@ -1663,8 +1661,9 @@ static int __soft_offline_page(struct page *page, 
 int flags)
pfn, ret, page->flags);
if (ret > 0)

[PATCH] usb: phy: phy-generic: Fix reset behaviour on legacy boot

[Roger Quadros]

The gpio-desc migration done in v4.0 caused a regression
with legacy boots due to reversed reset logic.
e.g. omap3-beagle USB host breaks on legacy boot.

Request the reset GPIO with GPIOF_ACTIVE_LOW flag so that
it matches the driver logic and pin behaviour.

Fixes: e9f2cefb0cdc ("usb: phy: generic: migrate to gpio_desc")
Cc:  # 4.0+
Signed-off-by: Roger Quadros 
---
 drivers/usb/phy/phy-generic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index deee68e..0cd85f2 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -230,7 +230,8 @@ int usb_phy_gen_create_phy(struct device *dev, struct 
usb_phy_generic *nop,
clk_rate = pdata->clk_rate;
needs_vcc = pdata->needs_vcc;
if (gpio_is_valid(pdata->gpio_reset)) {
-   err = devm_gpio_request_one(dev, pdata->gpio_reset, 0,
+   err = devm_gpio_request_one(dev, pdata->gpio_reset,
+   GPIOF_ACTIVE_LOW,
dev_name(dev));
if (!err)
nop->gpiod_reset =
-- 
2.1.4

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

Re: [RFC PATCH v4 6/9] arm: hisi_defconfig: remove CONFIG_MMC_DW_IDMAC

[Wei Xu]

On 8/6/2015 7:45 AM, Shawn Lin wrote:
> DesignWare MMC Controller's transfer mode should be decided
> at runtime instead of compile-time. So we remove this config
> option and read dw_mmc's register to select DMA master.
> 
> Signed-off-by: Shawn Lin 

Acked-by: Wei Xu 

> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/configs/hisi_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
> index 5997dbc..b2e340b 100644
> --- a/arch/arm/configs/hisi_defconfig
> +++ b/arch/arm/configs/hisi_defconfig
> @@ -69,7 +69,6 @@ CONFIG_NOP_USB_XCEIV=y
>  CONFIG_MMC=y
>  CONFIG_RTC_CLASS=y
>  CONFIG_MMC_DW=y
> -CONFIG_MMC_DW_IDMAC=y
>  CONFIG_MMC_DW_PLTFM=y
>  CONFIG_RTC_DRV_PL031=y
>  CONFIG_DMADEVICES=y
> 

Thanks!

Best Regards,
Wei

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

Re: [PATCH V3 0/5] clk: support clocks which requires parent clock on during operation

[Dong Aisheng]

On Tue, Aug 04, 2015 at 05:45:57PM +0800, Dong Aisheng wrote:
> On Tue, Jul 28, 2015 at 10:38:25PM +0800, Dong Aisheng wrote:
> > On Tue, Jul 28, 2015 at 09:19:40PM +0800, Dong Aisheng wrote:
> > > This patch series adds support in clock framework for clocks which 
> > > operations
> > > requires its parent clock is on.
> > > 
> > > Such clock type is initially met on Freescale i.MX7D platform that all 
> > > clocks
> > > operations, including enable/disable, rate change and re-parent, requires 
> > > its
> > > parent clock on. No sure if any other SoC has the similar clock type.
> > > 
> > > Current clock core can not support such type of clock well.
> > > 
> > > This patch introduce a new flag CLK_SET_PARENT_ON to handle this special 
> > > case
> > > in clock core that enable its parent clock firstly for each operation and 
> > > disable
> > > it later after operation complete.
> > > 
> > > The most special case is for set_parent() operation which requires both 
> > > parent,
> > > old one and new one, to be enabled at the same time during the operation.
> > > 
> > > The patch series is based on for-next branch of Michael's git:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
> > > 
> > > Change Log:
> > > v2->v3:
> > >  * rebased version, no other changes.
> > > 
> > > v1->v2:
> > >  Mainly addressed Stephen Boyd's comments
> > >  * remove dupliciated code with __clk_set_parent_after
> > >  * introduce more clk_core_x APIs for core easily use
> > >  * move clk_disable_unused code position
> > >  * use clk_core_x API to make code more clean and easily read
> > > 
> > > Dong Aisheng (5):
> > >   clk: remove duplicated code with __clk_set_parent_after
> > >   clk: introduce clk_core_enable_lock and clk_core_disable_lock
> > > functions
> > >   clk: move clk_disable_unused after clk_core_disable_unprepare function
> > >   clk: core: add CLK_OPS_PARENT_ON flags to support clocks require
> > > parent on
> > >   clk: core: add CLK_OPS_PARENT_ON flags to support clocks require
> > > parent on
> > > 
> > >  drivers/clk/clk.c| 338 
> > > +--
> > >  include/linux/clk-provider.h |   5 +
> > >  2 files changed, 200 insertions(+), 143 deletions(-)
> > > 
> > 
> > Sorry, forgot to update Mike's new email address.
> > Updated.
> > 
> 
> Ping...
> 

Hi Mike,

It's been quite a long time.
Can you help pick this?

Regards
Dong Aisheng

> Regards
> Dong Aisheng
> 
> > Regards
> > Dong Aisheng
> > 
> > > -- 
> > > 1.9.1
> > > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/6] mailbox: Add generic mechanism for testing Mailbox Controllers

[Lee Jones]

On Thu, 13 Aug 2015, Jassi Brar wrote:

> On Thu, Aug 13, 2015 at 2:49 PM, Lee Jones  wrote:
> > On Thu, 13 Aug 2015, Jassi Brar wrote:
> 
> >> >> > +
> >> >> > +static void mbox_test_prepare_message(struct mbox_client *client, 
> >> >> > void *message)
> >> >> > +{
> >> >> > +   struct mbox_test_device *tdev = dev_get_drvdata(client->dev);
> >> >> > +
> >> >> > +   if (tdev->mmio)
> >> >> > +   memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
> >> >> >
> >> >> This is unlikely to work. Those platforms that need to send a 2 part
> >> >> message, they do :
> >> >> (a) Signal/Command/Target code via some controller register (via
> >> >> mbox_send_message).
> >> >> (b) Setup the payload in Shared-Memory (via tx_prepare).
> >> >>
> >> >> This test driver assumes both are the same. I think you have to
> >> >> declare something like
> >> >
> >> > This driver assumes that the framework will call client->tx_prepare()
> >> > first, which satisfies (b).  It then assumes controller->send_data()
> >> > will be invoked, which will send the platform specific
> >> > signal/command/target code, which then satisfies (a).
> >> >
> >> Yeah, but what would be that code? Who provides that?
> >>
> >> > In what way does it assume they are the same?
> >> >
> >> notice the 'message' pointer in
> >> mbox_send_message(tdev->tx_channel, message);
> >> and
> >> memcpy(tdev->mmio, message, MBOX_MAX_MSG_LEN);
> >>
> >> >> struct mbox_test_message { /* same for TX and RX */
> >> >>   unsigned sig_len;
> >> >>   void *signal;   /* rx/tx via mailbox api */
> >> >>   unsigned pl_len;
> >> >>   void *payload;   /* rx/tx via shared-memory */
> >> >> };
> >> >
> >> > How do you think this should be set and use these?
> >> >
> >> The userspace would want to specify the command code (32bits or not)
> >> that would be passed via the fifo/register of the controller. So we
> >> need signal[]
> >>
> >> The data to be passed via share-memory could be provided by userspace
> >> via the payload[] array.
> >
> > Okay, so would the solution be two userspace files 'signal' and
> > 'message', so in the case of a client specified signal we can write it
> > into there first.
> >
> > echo 255  > signal
> > echo test > message
> >
> > ... or in the case where no signal is required, or the controller
> > driver taking care of it, we just don't write anything to signal?
> >
> file_operations.write() should parse signal and message, coming from
> userspace, into a local structure before routing them via
> mbox_send_message and tx_prepare respectively.

Okay.  So before I code this up we should agree on syntax.

How would you like to represent the break between signal and message?
Obviously ' ' would be a bad idea, as some clients may want to send
messages with white space contained.  How about '\t' or '\n'?

> > Just for clarification, in the case where a signal is required, do
> > clients usually pass that through mbox_send_message() too?
> >
> >   mbox_send_message(tdev->tx_channel, signal);
> >   mbox_send_message(tdev->tx_channel, message);
> >
> No. Command/Signal code is passed via mbox_send_message(signal). The
> payload is passed via Shared-Memory during tx_prepare(message)

Okay, I see.  Thanks for the clarification.

> >> >> > +static void mbox_test_message_sent(struct mbox_client *client,
> >> >> > +  void *message, int r)
> >> >> > +{
> >> >> > +   if (r)
> >> >> > +   dev_warn(client->dev,
> >> >> > +"Client: Message could not be sent: %d\n", 
> >> >> > r);
> >> >> > +   else
> >> >> > +   dev_info(client->dev,
> >> >> > +"Client: Message sent\n");
> >> >> > +}
> >> >> > +
> >> >> > +static struct mbox_chan *
> >> >> > +mbox_test_request_channel(struct platform_device *pdev, const char 
> >> >> > *name)
> >> >> > +{
> >> >> > +   struct mbox_client *client;
> >> >> > +
> >> >> > +   client = devm_kzalloc(>dev, sizeof(*client), 
> >> >> > GFP_KERNEL);
> >> >> > +   if (!client)
> >> >> > +   return ERR_PTR(-ENOMEM);
> >> >> > +
> >> >> > +   client->dev = >dev;
> >> >> > +   client->rx_callback = mbox_test_receive_message;
> >> >> > +   client->tx_prepare  = mbox_test_prepare_message;
> >> >> > +   client->tx_done = mbox_test_message_sent;
> >> >> > +   client->tx_block= true;
> >> >> > +   client->knows_txdone= false;
> >> >> > +   client->tx_tout = 500;
> >> >> > +
> >> >> > +   return mbox_request_channel_byname(client, name);
> >> >> > +}
> >> >> > +
> >> >> > +static int mbox_test_probe(struct platform_device *pdev)
> >> >> > +{
> >> >> > +   struct mbox_test_device *tdev;
> >> >> > +   struct resource *res;
> >> >> > +   int ret;
> >> >> > +
> >> >> > +   tdev = devm_kzalloc(>dev, sizeof(*tdev), GFP_KERNEL);
> >> >> > +   if (!tdev)
> >> >> 

Re: [Xen-devel] [PATCHv3 01/10] mm: memory hotplug with an existing resource

[David Vrabel]

On 30/07/15 18:03, David Vrabel wrote:
> Add add_memory_resource() to add memory using an existing "System RAM"
> resource.  This is useful if the memory region is being located by
> finding a free resource slot with allocate_resource().
> 
> Xen guests will make use of this in their balloon driver to hotplug
> arbitrary amounts of memory in response to toolstack requests.

Ping?  This enables a useful feature for Xen guests.

> Signed-off-by: David Vrabel 
> Cc: Andrew Morton 
> ---
>  include/linux/memory_hotplug.h |  2 ++
>  mm/memory_hotplug.c| 28 +---
>  2 files changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 6ffa0ac..c76d371 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -11,6 +11,7 @@ struct zone;
>  struct pglist_data;
>  struct mem_section;
>  struct memory_block;
> +struct resource;
>  
>  #ifdef CONFIG_MEMORY_HOTPLUG
>  
> @@ -266,6 +267,7 @@ static inline void remove_memory(int nid, u64 start, u64 
> size) {}
>  extern int walk_memory_range(unsigned long start_pfn, unsigned long end_pfn,
>   void *arg, int (*func)(struct memory_block *, void *));
>  extern int add_memory(int nid, u64 start, u64 size);
> +extern int add_memory_resource(int nid, struct resource *resource);
>  extern int zone_for_memory(int nid, u64 start, u64 size, int zone_default);
>  extern int arch_add_memory(int nid, u64 start, u64 size);
>  extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 003dbe4..169770a 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1224,23 +1224,21 @@ int zone_for_memory(int nid, u64 start, u64 size, int 
> zone_default)
>  }
>  
>  /* we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG */
> -int __ref add_memory(int nid, u64 start, u64 size)
> +int __ref add_memory_resource(int nid, struct resource *res)
>  {
> + u64 start, size;
>   pg_data_t *pgdat = NULL;
>   bool new_pgdat;
>   bool new_node;
> - struct resource *res;
>   int ret;
>  
> + start = res->start;
> + size = resource_size(res);
> +
>   ret = check_hotplug_memory_range(start, size);
>   if (ret)
>   return ret;
>  
> - res = register_memory_resource(start, size);
> - ret = -EEXIST;
> - if (!res)
> - return ret;
> -
>   {   /* Stupid hack to suppress address-never-null warning */
>   void *p = NODE_DATA(nid);
>   new_pgdat = !p;
> @@ -1290,6 +1288,22 @@ out:
>   mem_hotplug_done();
>   return ret;
>  }
> +EXPORT_SYMBOL_GPL(add_memory_resource);
> +
> +int __ref add_memory(int nid, u64 start, u64 size)
> +{
> + struct resource *res;
> + int ret;
> +
> + res = register_memory_resource(start, size);
> + if (!res)
> + return -EEXIST;
> +
> + ret = add_memory_resource(nid, res);
> + if (ret < 0)
> + release_memory_resource(res);
> + return ret;
> +}
>  EXPORT_SYMBOL_GPL(add_memory);
>  
>  #ifdef CONFIG_MEMORY_HOTREMOVE
> 

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

Re: [PATCH v2 3/8] document rwsem_release() in sb_wait_write()

[Jan Kara]

On Tue 11-08-15 19:04:04, Oleg Nesterov wrote:
> Not only we need to avoid the warning from lockdep_sys_exit(), the
> caller of freeze_super() can never release this lock. Another thread
> can do this, so there is another reason for rwsem_release().
> 
> Plus the comment should explain why we have to fool lockdep.
> 
> Signed-off-by: Oleg Nesterov 

Looks good. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  fs/super.c |   12 +---
>  1 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/super.c b/fs/super.c
> index d0fdd49..89b58fb 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -1236,11 +1236,17 @@ static void sb_wait_write(struct super_block *sb, int 
> level)
>  {
>   s64 writers;
>  
> + rwsem_acquire(>s_writers.lock_map[level-1], 0, 0, _THIS_IP_);
>   /*
> -  * We just cycle-through lockdep here so that it does not complain
> -  * about returning with lock to userspace
> +  * We are going to return to userspace and forget about this lock, the
> +  * ownership goes to the caller of thaw_super() which does unlock.
> +  *
> +  * FIXME: we should do this before return from freeze_super() after we
> +  * called sync_filesystem(sb) and s_op->freeze_fs(sb), and thaw_super()
> +  * should re-acquire these locks before s_op->unfreeze_fs(sb). However
> +  * this leads to lockdep false-positives, so currently we do the early
> +  * release right after acquire.
>*/
> - rwsem_acquire(>s_writers.lock_map[level-1], 0, 0, _THIS_IP_);
>   rwsem_release(>s_writers.lock_map[level-1], 1, _THIS_IP_);
>  
>   do {
> -- 
> 1.5.5.1
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] ipv4: off-by-one in continuation handling in /proc/net/route

[Andy Whitcroft]

When generating /proc/net/route we emit a header followed by a line for
each route.  When a short read is performed we will restart this process
based on the open file descriptor.  When calculating the start point we
fail to take into account that the 0th entry is the header.  This leads
us to skip the first entry when doing a continuation read.

This can be easily seen with the comparison below:

  while read l; do echo "$l"; done A
  cat /proc/net/route >B
  diff -bu A B | grep '^[+-]'

On my example machine I have approximatly 10KB of route output.  There we
see the very first non-title element is lost in the while read case,
and an entry around the 8K mark in the cat case:

  +wlan0  02021EAC 0003 0 0 400  0 0 0
  -tun1  00C0AC0A  0001 0 0 950 00C0 0 0 0

Fix up the off-by-one when reaquiring position on continuation.

BugLink: http://bugs.launchpad.net/bugs/1483440
Signed-off-by: Andy Whitcroft 
---
 net/ipv4/fib_trie.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

From code inspection I belive this was introduced by the Fixes
below, but I have not tested this to confirm.

Fixes: 8be33e955cb9 ("ipv4: off-by-one in continuation handling in 
/proc/net/route")

diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 37c4bb8..b0c6258 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2465,7 +2465,7 @@ static struct key_vector *fib_route_get_idx(struct 
fib_route_iter *iter,
key = l->key + 1;
iter->pos++;
 
-   if (pos-- <= 0)
+   if (--pos <= 0)
break;
 
l = NULL;
-- 
2.5.0

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