[PATCH] remove non-existent files from MAINTAINERS

[Christian Kujau]

Inspired by some recent cleanups in MAINTAINERS the following
files (F:) cannot be found any more in the tree:

* arch/arm/mach-s5pv210/mach-aquila.c
* arch/arm/mach-s5pv210/mach-goni.c

  Those two got removed in 28c8331 ("ARM: S5PV210: Remove support for board 
files").
  Cc: Tomasz Figa 
  Cc: Kyungmin Park 

* arch/arm/configs/genmai_defconfig

  This one got removed in 3ed27bd9 ("ARM: shmobile: genmai: remove 
defconfig").
  Cc: Simon Horman 
  Cc: Magnus Damm 

* drivers/mmc/host/sdhci-st.c

  This one was sent to be included in June 2014 but got dropped shortly 
after:
  "mmc: sdhci-st: Intial support for ST SDHCI controller"
  https://lkml.org/lkml/2014/6/4/446
  https://lkml.org/lkml/2014/7/9/340
  Cc: Peter Griffin 
  Cc: Ulf Hansson 

* drivers/rtc/rtc-sec.c

  A MAINTAINERS fix was attempted in November 2012, but dismissed as 
rtc-sec.c
  was still being worked on. Alas, it's still not there.
  "MAINTAINERS: fix drivers/rtc/rtc-sec.c"
  http://lkml.iu.edu/hypermail/linux/kernel/1211.2/04820.html
  Cc: Sangbeom Kim 
  Cc: Cesar Eduardo Barros 

Signed-off-by: Christian Kujau 

diff --git a/MAINTAINERS b/MAINTAINERS
index 7e2eb4c..7831e8d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1303,8 +1303,7 @@ ARM/SAMSUNG MOBILE MACHINE SUPPORT
 M: Kyungmin Park 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
-F: arch/arm/mach-s5pv210/mach-aquila.c
-F: arch/arm/mach-s5pv210/mach-goni.c
+F: arch/arm/mach-s5pv210/

 ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
 M: Kyungmin Park 
@@ -1347,7 +1346,6 @@ F:arch/arm/boot/dts/sh*
 F: arch/arm/configs/ape6evm_defconfig
 F: arch/arm/configs/armadillo800eva_defconfig
 F: arch/arm/configs/bockw_defconfig
-F: arch/arm/configs/genmai_defconfig
 F: arch/arm/configs/koelsch_defconfig
 F: arch/arm/configs/kzm9g_defconfig
 F: arch/arm/configs/lager_defconfig
@@ -1383,7 +1381,6 @@ F:drivers/pinctrl/pinctrl-st.c
 F: drivers/media/rc/st_rc.c
 F: drivers/i2c/busses/i2c-st.c
 F: drivers/tty/serial/st-asc.c
-F: drivers/mmc/host/sdhci-st.c

 ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
 M: Lennert Buytenhek 
@@ -7809,7 +7806,6 @@ S:Supported
 F: drivers/mfd/sec*.c
 F: drivers/regulator/s2m*.c
 F: drivers/regulator/s5m*.c
-F: drivers/rtc/rtc-sec.c
 F: include/linux/mfd/samsung/

 SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS
-- 
BOFH excuse #419:

Repeated reboots of the system failed to solve problem
--
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] memblock, memhotplug: Fix wrong type in memblock_find_in_range_node().

[Tang Chen]

In memblock_find_in_range_node(), we defeind ret as int. But it shoule
be phys_addr_t because it is used to store the return value from
__memblock_find_range_bottom_up().

The bug has not been triggered because when allocating low memory near
the kernel end, the "int ret" won't turn out to be minus. When we started
to allocate memory on other nodes, and the "int ret" could be minus.
Then the kernel will panic.

A simple way to reproduce this: comment out the following code in numa_init(),

memblock_set_bottom_up(false);

and the kernel won't boot.

Reported-by: Xishi Qiu 
Signed-off-by: Tang Chen 
---
 mm/memblock.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 6d2f219..70fad0c 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -192,8 +192,7 @@ phys_addr_t __init_memblock 
memblock_find_in_range_node(phys_addr_t size,
phys_addr_t align, phys_addr_t start,
phys_addr_t end, int nid)
 {
-   int ret;
-   phys_addr_t kernel_end;
+   phys_addr_t kernel_end, ret;
 
/* pump up @end */
if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
-- 
1.8.3.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 1/1] memblock, memhotplug: Fix wrong type in memblock_find_in_range_node().

[tangchen]

Sorry, add Xishi Qiu 

On 08/10/2014 02:12 PM, Tang Chen wrote:

In memblock_find_in_range_node(), we defeind ret as int. But it shoule
be phys_addr_t because it is used to store the return value from
__memblock_find_range_bottom_up().

The bug has not been triggered because when allocating low memory near
the kernel end, the "int ret" won't turn out to be minus. When we started
to allocate memory on other nodes, and the "int ret" could be minus.
Then the kernel will panic.

A simple way to reproduce this: comment out the following code in numa_init(),

 memblock_set_bottom_up(false);

and the kernel won't boot.

Reported-by: Xishi Qiu 
Signed-off-by: Tang Chen 
---
  mm/memblock.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 6d2f219..70fad0c 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -192,8 +192,7 @@ phys_addr_t __init_memblock 
memblock_find_in_range_node(phys_addr_t size,
phys_addr_t align, phys_addr_t start,
phys_addr_t end, int nid)
  {
-   int ret;
-   phys_addr_t kernel_end;
+   phys_addr_t kernel_end, ret;
  
  	/* pump up @end */

if (end == MEMBLOCK_ALLOC_ACCESSIBLE)


--
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] Flipped jump labels

[Ingo Molnar]

[same mail, with Jason's email address corrected.]

* Ingo Molnar  wrote:

> * Borislav Petkov  wrote:
> 
> > Hi dudes,
> > 
> > with the current impl. of jump labels, people can't really do the
> > following:
> > 
> > ---
> > JMP unlikely_code
> > likely_code
> > 
> > unlikely_code:
> > unlikely code
> > ---
> > 
> > and after some initialization queries overwrite the JMP with a NOP so
> > that the likely code gets executed at 0 cost.
> > 
> > The issue is that jump labels unconditionally add NOPs by default
> > (see arch_static_branch). For example, native_sched_clock() gets the
> > following code layout here:
> > 
> > --
> > NOP
> > unlikely code (which computes time in ns from jiffies)
> > likely code (which does RDTSC)
> > --
> > 
> > Yes, unlikely code comes first.
> > 
> > when the jump labels get initialized and all checks done, at runtime we
> > have this:
> > 
> >0x8100ce40 :push   %rbp
> >0x8100ce41 :  mov%rsp,%rbp
> >0x8100ce44 :  and$0xfff0,%rsp
> > 
> > unconditional JMP!!!
> > 
> >0x8100ce48 :  jmpq   0x8100ce70 
> > 
> > 
> > unlikely code using jiffies
> > 
> >0x8100ce4d : mov0x9a71ac(%rip),%r8   
> >  # 0x819b4000 
> >0x8100ce54 : movabs $0xffc2f745d964b800,%rax
> >0x8100ce5e : leaveq 
> >0x8100ce5f : imul   $0x3d0900,%r8,%rdx
> >0x8100ce66 : add%rdx,%rax
> >0x8100ce69 : retq   
> >0x8100ce6a : nopw   0x0(%rax,%rax,1)
> > 
> > likely code using RDTSC, see JMP target address.
> > 
> >0x8100ce70 : rdtsc
> > 
> > 
> > so what we end up getting is not really helping because we always get to
> > pay for that JMP on all modern systems which sport RDTSC even though we
> > shouldn't really.
> > 
> > And remember this is not something cheap: sched_clock uses the TSC
> > even if it is unstable so we're always jumping like insane and
> > unconditionally.
> > 
> > So, long story short, we want this, instead:
> > 
> >0x8100cf10 :push   %rbp
> >0x8100cf11 :  mov%rsp,%rbp
> >0x8100cf14 :  and$0xfff0,%rsp
> > 
> > unconditional JMP is nopped out
> > 
> >0x8100cf18 :  data32 data32 data32 xchg 
> > %ax,%ax
> > 
> > likely code which comes first in the function so all the advantages from
> > it to front end, branch pred, yadda yadda, get to be enjoyed :)
> > 
> >0x8100cf1d : rdtsc  
> >0x8100cf1f : mov%eax,%esi
> >0x8100cf21 : mov%rdx,%rax
> >0x8100cf24 : shl$0x20,%rax
> >0x8100cf28 : or %rsi,%rax
> >0x8100cf2b : mov%rax,%rcx
> >0x8100cf2e : incl   %gs:0xb8e0
> >0x8100cf36 : mov%gs:0x1d0c30,%rsi
> >0x8100cf3f : mov%gs:0x1d0c38,%rax
> >0x8100cf48 : cmp%rax,%rsi
> >0x8100cf4b : jne0x8100cf90 
> > 
> >0x8100cf4d : mov(%rsi),%eax
> >0x8100cf4f : mul%rcx
> >0x8100cf52 : shrd   $0xa,%rdx,%rax
> >0x8100cf57 : add0x8(%rsi),%rax
> >0x8100cf5b : decl   %gs:0xb8e0
> >0x8100cf63 : je 0x8100cf88 
> > 
> >0x8100cf65 : leaveq 
> >0x8100cf66 : retq   
> > 
> > Done, we return here.
> > 
> >0x8100cf67 : nop
> > 
> > unlikely code which does the jiffies math.
> > 
> >0x8100cf68 : mov0x9a7091(%rip),%rax  
> >   # 0x819b4000 
> >0x8100cf6f : leaveq 
> >0x8100cf70 : imul   $0x3d0900,%rax,%rdx
> >...
> > 
> > 
> > So basically what I'm proposing is a jump label type which is
> > initialized by default to jump to the unlikely code and once
> > initialization has happened, JMP gets overwritten.
> > 
> > The things to pay attention here is
> > 
> > * this label should be used in places where it is very likely for the
> > jump to get overwritten. Basically the opposite to tracepoints for which
> > the jump labels were created initially, to be mostly off.
> > 
> > * It must be used in places where JMP gets overwritten only after some
> > initialization done first.
> > 
> > Anyway, below is a concept patch for myself to try the idea first - it
> > seems to work here. Constructive ideas and suggestions are welcome, as
> > always.
> > 
> > ---
> > diff --git a/arch/x86/include/asm/jump_label.h 
> > b/arch/x86/include/asm/jump_label.h
> > index 6a2cefb4395a..2d963c6489a8 100644
> > --- a/arch/x86/include/asm/jump_label.h
> > +++ b/arch/x86/include/asm/jump_label.h
> > @@ -30,6 +30,22 @@ l_yes:
> > return true;
> >  }
> >  
> > +static __always_inline bool arch_static_branch_active(struct static_key 
> > *key)
> > +{
> > +   asm_volatile_goto("1:"
> > +   

Re: [RFC PATCH] Flipped jump labels

[Ingo Molnar]

* Borislav Petkov  wrote:

> Hi dudes,
> 
> with the current impl. of jump labels, people can't really do the
> following:
> 
> ---
> JMP unlikely_code
> likely_code
> 
> unlikely_code:
> unlikely code
> ---
> 
> and after some initialization queries overwrite the JMP with a NOP so
> that the likely code gets executed at 0 cost.
> 
> The issue is that jump labels unconditionally add NOPs by default
> (see arch_static_branch). For example, native_sched_clock() gets the
> following code layout here:
> 
> --
> NOP
> unlikely code (which computes time in ns from jiffies)
> likely code (which does RDTSC)
> --
> 
> Yes, unlikely code comes first.
> 
> when the jump labels get initialized and all checks done, at runtime we
> have this:
> 
>  0x8100ce40 :push   %rbp
>  0x8100ce41 :  mov%rsp,%rbp
>  0x8100ce44 :  and$0xfff0,%rsp
> 
> unconditional JMP!!!
> 
>  0x8100ce48 :  jmpq   0x8100ce70 
> 
> 
> unlikely code using jiffies
> 
>  0x8100ce4d : mov0x9a71ac(%rip),%r8   
>  # 0x819b4000 
>  0x8100ce54 : movabs $0xffc2f745d964b800,%rax
>  0x8100ce5e : leaveq 
>  0x8100ce5f : imul   $0x3d0900,%r8,%rdx
>  0x8100ce66 : add%rdx,%rax
>  0x8100ce69 : retq   
>  0x8100ce6a : nopw   0x0(%rax,%rax,1)
> 
> likely code using RDTSC, see JMP target address.
> 
>  0x8100ce70 : rdtsc
> 
> 
> so what we end up getting is not really helping because we always get to
> pay for that JMP on all modern systems which sport RDTSC even though we
> shouldn't really.
> 
> And remember this is not something cheap: sched_clock uses the TSC
> even if it is unstable so we're always jumping like insane and
> unconditionally.
> 
> So, long story short, we want this, instead:
> 
>  0x8100cf10 :push   %rbp
>  0x8100cf11 :  mov%rsp,%rbp
>  0x8100cf14 :  and$0xfff0,%rsp
> 
> unconditional JMP is nopped out
> 
>  0x8100cf18 :  data32 data32 data32 xchg 
> %ax,%ax
> 
> likely code which comes first in the function so all the advantages from
> it to front end, branch pred, yadda yadda, get to be enjoyed :)
> 
>  0x8100cf1d : rdtsc  
>  0x8100cf1f : mov%eax,%esi
>  0x8100cf21 : mov%rdx,%rax
>  0x8100cf24 : shl$0x20,%rax
>  0x8100cf28 : or %rsi,%rax
>  0x8100cf2b : mov%rax,%rcx
>  0x8100cf2e : incl   %gs:0xb8e0
>  0x8100cf36 : mov%gs:0x1d0c30,%rsi
>  0x8100cf3f : mov%gs:0x1d0c38,%rax
>  0x8100cf48 : cmp%rax,%rsi
>  0x8100cf4b : jne0x8100cf90 
> 
>  0x8100cf4d : mov(%rsi),%eax
>  0x8100cf4f : mul%rcx
>  0x8100cf52 : shrd   $0xa,%rdx,%rax
>  0x8100cf57 : add0x8(%rsi),%rax
>  0x8100cf5b : decl   %gs:0xb8e0
>  0x8100cf63 : je 0x8100cf88 
> 
>  0x8100cf65 : leaveq 
>  0x8100cf66 : retq   
> 
> Done, we return here.
> 
>  0x8100cf67 : nop
> 
> unlikely code which does the jiffies math.
> 
>  0x8100cf68 : mov0x9a7091(%rip),%rax  
>   # 0x819b4000 
>  0x8100cf6f : leaveq 
>  0x8100cf70 : imul   $0x3d0900,%rax,%rdx
>  ...
> 
> 
> So basically what I'm proposing is a jump label type which is
> initialized by default to jump to the unlikely code and once
> initialization has happened, JMP gets overwritten.
> 
> The things to pay attention here is
> 
> * this label should be used in places where it is very likely for the
> jump to get overwritten. Basically the opposite to tracepoints for which
> the jump labels were created initially, to be mostly off.
> 
> * It must be used in places where JMP gets overwritten only after some
> initialization done first.
> 
> Anyway, below is a concept patch for myself to try the idea first - it
> seems to work here. Constructive ideas and suggestions are welcome, as
> always.
> 
> ---
> diff --git a/arch/x86/include/asm/jump_label.h 
> b/arch/x86/include/asm/jump_label.h
> index 6a2cefb4395a..2d963c6489a8 100644
> --- a/arch/x86/include/asm/jump_label.h
> +++ b/arch/x86/include/asm/jump_label.h
> @@ -30,6 +30,22 @@ l_yes:
>   return true;
>  }
>  
> +static __always_inline bool arch_static_branch_active(struct static_key *key)
> +{
> + asm_volatile_goto("1:"
> + "jmp %l[l_yes]\n\t"
> + ".byte " __stringify(GENERIC_NOP3) "\n\t"
> + ".pushsection __jump_table,  \"aw\" \n\t"
> + _ASM_ALIGN "\n\t"
> + _ASM_PTR "1b, %l[l_yes], %c0 \n\t"
> + ".popsection \n\t"
> + : :  "

Re: Loading initrd above 4G causes freeze on boot

[Yinghai Lu]

On Sat, Aug 9, 2014 at 3:45 PM, Mantas Mikulėnas  wrote:
> On Sat, Aug 9, 2014 at 10:23 PM, Matt Fleming  wrote:
> [However... Whether it's five chunks, four (after making the initrd
> smaller), or just one (with your efi=nochunk), I noticed that it
> *always* hangs during the *last* read, and the allocated memory always
> ends at roughly the same address (0x137fffXXX). I wonder if it's
> selecting a memory location already in use, or something like that...]
>
> (The laptop is Asus K52JT, AMI firmware v206, no updates available.)

wonder if  efi_file_read return with wrong chunksize.

Can you try attached patch ?

Thanks

Yinghai
---
 drivers/firmware/efi/libstub/efi-stub-helper.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-2.6/drivers/firmware/efi/libstub/efi-stub-helper.c
===
--- linux-2.6.orig/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ linux-2.6/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -431,7 +431,8 @@ efi_status_t handle_cmdline_files(efi_sy
 status = efi_file_read(files[j].handle,
 		   &chunksize,
 		   (void *)addr);
-if (status != EFI_SUCCESS) {
+if (status != EFI_SUCCESS ||
+chunksize > size || !chunksize) {
 	pr_efi_err(sys_table_arg, "Failed to read file\n");
 	goto free_file_total;
 }

[GIT PULL] platform/chrome: Updates for 3.17

[Olof Johansson]

Hi Linus,

The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:

  Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/olof/chrome-platform.git 
tags/for-linus

for you to fetch changes up to 5502486a2077e4280c618b82e8a77ed35932956f:

  platform/chrome: chromeos_laptop - Add a limit for deferred retries 
(2014-07-15 18:02:01 -0700)


platform/chrome: Updates for 3.17

Updates to the Chromebook/box platform drivers:

- A bugfix to pstore registration that makes it also work on non-Google
  systems
- Addition of new shipped Chromebooks (later models have more probing
  through ACPI so the need for these updates will be less over time).
- A couple of minor coding style updates


Benson Leung (2):
  platform/chrome: chromeos_laptop - Add HP Chromebook 14
  platform/chrome: chromeos_laptop - Add a limit for deferred retries

Gene Chen (1):
  platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch

Michael Mullin (1):
  platform/chrome: Add support for the acer c720p touchscreen.

Mika Westerberg (1):
  platform/chrome: chromeos_laptop - Add support for Acer C720

Mohammed Habibulla (1):
  platform/chrome: chromeos_laptop - Add Dell Chromebook 11 touch

Olof Johansson (1):
  platform/chrome: pstore: fix dmi table to match all chrome systems

Robin Schroer (1):
  platform/chrome: coding style fixes

 drivers/platform/chrome/chromeos_laptop.c | 140 +++---
 drivers/platform/chrome/chromeos_pstore.c |  14 +--
 2 files changed, 132 insertions(+), 22 deletions(-)
--
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] ARM: SoC fixes

[Olof Johansson]

Hi Linus,

The following changes since commit c309bfa9b481e7dbd3e1ab819271bf3009f44859:

  Merge tag 'for-linus-20140808' of git://git.infradead.org/linux-mtd 
(2014-08-08 18:13:21 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/fixes-for-linus

for you to fetch changes up to ee34fb97a96ceac3334705ebab8b541ca291699f:

  ARM: dts: exynos5420: remove disp_pd (2014-08-09 08:25:50 -0700)


ARM: SoC fixes for 3.17 merge window

- A short branch of OMAP fixes that we didn't merge before the window opened.
- A small cleanup that sorts the rk3288 dts entries properly
- A build fix due to a reference to a removed DT node on exynos


Doug Anderson (1):
  ARM: dts: Fix the sort ordering of EHCI and HSIC in rk3288.dtsi

Jeremy Vial (2):
  ARM: OMAP3: Fix choice of omap3_restore_es function in OMAP34XX rev3.1.2 
case.
  ARM: OMAP3: Fix coding style problems in arch/arm/mach-omap2/control.c

Olof Johansson (1):
  Merge tag 'omap-for-v3.17/soc-fixes' of 
git://git.kernel.org/.../tmlind/linux-omap into fixes

Paul Walmsley (1):
  ARM: OMAP2+: clock: allow omap2_dpll_round_rate() to round to next-lowest 
rate

Stephen Rothwell (1):
  ARM: dts: exynos5420: remove disp_pd

Tomasz Figa (1):
  ARM: EXYNOS: Fix suspend/resume sequences

Tony Lindgren (1):
  Merge tag 'for-v3.17/omap-clock-b' of 
git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.17/soc

 arch/arm/boot/dts/exynos5420.dtsi |   1 -
 arch/arm/boot/dts/rk3288.dtsi |  40 +-
 arch/arm/mach-exynos/pm.c | 163 ++
 arch/arm/mach-omap2/clkt_dpll.c   |  28 +--
 arch/arm/mach-omap2/control.c |   6 +-
 arch/arm/mach-omap2/dpll3xxx.c|  13 ++-
 drivers/cpuidle/cpuidle-exynos.c  |  25 +-
 7 files changed, 135 insertions(+), 141 deletions(-)
--
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/

[sched] 143e1e28cb4: +17.9% aim7.jobs-per-min, -9.7% hackbench.throughput

[Fengguang Wu]

Hi Vincent,

FYI, we noticed some performance ups/downs on

commit 143e1e28cb40bed836b0a06567208bd7347c9672 ("sched: Rework sched_domain 
topology definition")

107437febd495a5  143e1e28cb40bed836b0a0656  testbox/testcase/testparams
---  -  ---
  0.09 ± 3% +88.2%   0.17 ± 1%  nhm4/ebizzy/200%-100x-10s
  0.09 ± 3% +88.2%   0.17 ± 1%  TOTAL 
ebizzy.throughput.per_thread.stddev_percent

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
128529 ± 1% +17.9% 151594 ± 0%  brickland1/aim7/6000-page_test
128529 ± 1% +17.9% 151594 ± 0%  TOTAL aim7.jobs-per-min

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
156539 ± 1%  -4.3% 149885 ± 0%  
lkp-snb01/hackbench/1600%-process-pipe
116465 ± 1% -17.1%  96542 ± 1%  wsm/hackbench/1600%-process-pipe
273004 ± 1%  -9.7% 246428 ± 0%  TOTAL hackbench.throughput

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  12451869 ± 0%  -2.9%   12087560 ± 0%  
brickland3/vm-scalability/300s-lru-file-readonce
  12451869 ± 0%  -2.9%   12087560 ± 0%  TOTAL vm-scalability.throughput

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  1980 ± 0%  -2.4%   1933 ± 0%  nhm4/ebizzy/200%-100x-10s
  1980 ± 0%  -2.4%   1933 ± 0%  TOTAL 
ebizzy.throughput.per_thread.min

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
 4.446e+08 ± 0%  -1.9%  4.364e+08 ± 0%  lkp-nex04/pigz/100%-128K
 4.446e+08 ± 0%  -1.9%  4.364e+08 ± 0%  TOTAL pigz.throughput

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
 27.18 ± 0%  -1.5%  26.78 ± 0%  nhm4/ebizzy/200%-100x-10s
 27.18 ± 0%  -1.5%  26.78 ± 0%  TOTAL ebizzy.time.user

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  2083 ± 0%  +1.3%   2110 ± 0%  nhm4/ebizzy/200%-100x-10s
  2083 ± 0%  +1.3%   2110 ± 0%  TOTAL 
ebizzy.throughput.per_thread.max

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
 32335 ± 0%  -1.0%  32012 ± 0%  nhm4/ebizzy/200%-100x-10s
 32335 ± 0%  -1.0%  32012 ± 0%  TOTAL ebizzy.throughput

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  6626 ± 5% -88.7%751 ±36%  
brickland3/vm-scalability/300s-lru-file-readonce
  6626 ± 5% -88.7%751 ±36%  TOTAL cpuidle.C3-IVT.usage

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  14204402 ±19% -71.5%4050186 ±34%  
brickland3/vm-scalability/300s-lru-file-readonce
  14204402 ±19% -71.5%4050186 ±34%  TOTAL cpuidle.C3-IVT.time

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  0.38 ±32%+218.1%   1.20 ± 4%  wsm/hackbench/1600%-process-pipe
  0.38 ±32%+218.1%   1.20 ± 4%  TOTAL 
perf-profile.cpu-cycles.__schedule.schedule.pipe_wait.pipe_read.do_sync_read

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
 76064 ± 3% -32.2%  51572 ± 6%  brickland1/aim7/6000-page_test
269053 ± 1% -57.9% 113386 ± 1%  
brickland3/vm-scalability/300s-lru-file-readonce
345117 ± 1% -52.2% 164959 ± 2%  TOTAL cpuidle.C6-IVT.usage

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  59366697 ± 3% -46.1%   32017187 ± 7%  brickland1/aim7/6000-page_test
  59366697 ± 3% -46.1%   32017187 ± 7%  TOTAL cpuidle.C1-IVT.time

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  2815 ± 2% +83.3%   48893253 ± 2%  lkp-nex04/pigz/100%-128K
  2815 ± 2% +83.3%   48893253 ± 2%  TOTAL cpuidle.C1E-NHM.time

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  2561 ± 7% -42.9%   1463 ± 9%  brickland1/aim7/6000-page_test
  2561 ± 7% -42.9%   1463 ± 9%  TOTAL numa-numastat.node2.other_node

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
116864 ± 2% +77.4% 207322 ± 2%  lkp-nex04/pigz/100%-128K
116864 ± 2% +77.4% 207322 ± 2%  TOTAL cpuidle.C1E-NHM.usage

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  0.65 ±22% +55.4%   1.02 ± 5%  lkp-nex04/pigz/100%-128K
  0.65 ±22% +55.4%   1.02 ± 5%  TOTAL 
perf-profile.cpu-cycles.intel_idle.cpuidle_enter_state.cpuidle_enter.cpu_startup_entry.start_secondary

107437febd495a5  143e1e28cb40bed836b0a0656  
---  -  
  9926 ± 2% -43.8%   5577 ± 4%  brick

Re: [PATCH RFC] sched: deferred set priority (dprio)

[Mike Galbraith]

On Sun, 2014-08-10 at 05:13 +0200, Mike Galbraith wrote: 
> On Sat, 2014-08-09 at 20:04 +0200, Andi Kleen wrote: 
> > > NAK.  There it is, my imaginary NAK to imaginary realtime priorities :)
> > 
> > Ok, but do you have any alternative proposal yourself how to solve the
> > lockholder preemption problem? I assume you agree it's a real problem.
> > 
> > Just being negative is not very constructive.
> 
> I both acknowledged the problem problem, and made alternative
> suggestions.

Note who I replied to

https://lkml.org/lkml/2014/7/28/77

--
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: Runtime trouble with commit dbd952127d (seccomp: introduce writer locking)

[Kees Cook]

On Sat, Aug 9, 2014 at 6:47 PM, Guenter Roeck  wrote:
> Hi folks,
>
> I am having some trouble with commit dbd952127d (seccomp: introduce
> writer locking) when running my qemu tests on the upstream kernel.

Eek, sorry this is causing you trouble!

> With powerpc, I get the following crash.
>
> ftrace: allocating 20093 entries in 59 pages
> [ cut here ]
> kernel BUG at kernel/fork.c:1108!

For your tree, does this resolve to copy_seccomp()'s

BUG_ON(!spin_is_locked(¤t->sighand->siglock));

line?

> Oops: Exception in kernel mode, sig: 5 [#1]
> PREEMPT PowerMac
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 3.16.0-yocto-standard+ #1
> task: c08a03d0 ti: c08e4000 task.ti: c08e4000
> NIP: c002b98c LR: c002b988 CTR: c03837ec
> REGS: c08e5e30 TRAP: 0700   Not tainted  (3.16.0-yocto-standard+)
> MSR: 00021032   CR: 22282048  XER: 2000
>
> GPR00: c002b988 c08e5ee0 c08a03d0 0001 c0a9b878 0800 c783603c
> 0020
> GPR08: c783603c 0003 0001 c08f61fc 2044  07c5ac10
> 00800300
> GPR16: c787 0010  07de7fa4  c08f594c c08f
> c78702d0
> GPR24:  c08f c08f5940 c000422c c08a8ea0 c7870310 
> c7808400
> NIP [c002b98c] copy_process.part.52+0x794/0x13e4
> LR [c002b988] copy_process.part.52+0x790/0x13e4
> Call Trace:
> [c08e5ee0] [c002b988] copy_process.part.52+0x790/0x13e4 (unreliable)
> [c08e5f60] [c002c768] do_fork+0xb8/0x3bc
> [c08e5fa0] [c00041c8] rest_init+0x30/0x94
> [c08e5fb0] [c083cf98] start_kernel+0x368/0x37c
> [c08e5ff0] [3438] 0x3438
> Instruction dump:
> 7d400124 3861 48027e95 55e903e1 41820b84 80e202c0 90f002c0 81420570
> 91500570 3861 48027e75 3941 <0f0a> 81420568 8162056c 91500568
> ---[ end trace dc8fa200cb88537f ]---
>
> With  mips (both 32 bit and 64 bit), I get
>
> NR_IRQS:256
> CPU frequency 200.00 MHz
> Console: colour dummy device 80x25
> console [tty0] enabled
> bootconsole [uart0] disabled
>
> [ and then there is silence ]
>
> In all cases I bisected the problem to the above mentioned commit.
>
> Failures are seen in both linux-next and the tip of Linus' tree.
> Test results are on http://server.roeck-us.net:8010/builders
> (look for qwmu results). Build and test scripts are in the mips,
> mips64, and powerpc subdirectories of
> https://github.com/groeck/linux-build-test/tree/master/rootfs.
>
> Any idea, anyone, what might be going on, or how I could do to
> help tracking this down ?

Can you send me your .config for the powerpc case? There must be
something going on here with the spinlock, but I don't see how, since
the lines immediately before the copy_seccomp call take the lock...

Is there something special going on here for the "pid 0" case?

-Kees

-- 
Kees Cook
Chrome OS Security
--
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] sched: deferred set priority (dprio)

[Mike Galbraith]

On Sat, 2014-08-09 at 20:04 +0200, Andi Kleen wrote: 
> > NAK.  There it is, my imaginary NAK to imaginary realtime priorities :)
> 
> Ok, but do you have any alternative proposal yourself how to solve the
> lockholder preemption problem? I assume you agree it's a real problem.
> 
> Just being negative is not very constructive.

I both acknowledged the problem problem, and made alternative
suggestions.

-Mike

--
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: CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Mario Kleiner]

Resent this time without HTML formatting which lkml doesn't like. Sorry.

On 08/09/2014 03:58 PM, Thomas Hellstrom wrote:

On 08/09/2014 03:33 PM, Konrad Rzeszutek Wilk wrote:

On August 9, 2014 1:39:39 AM EDT, Thomas Hellstrom  
wrote:

Hi.


Hey Thomas!


IIRC I don't think the TTM DMA pool allocates coherent pages more than
one page at a time, and _if that's true_ it's pretty unnecessary for
the
dma subsystem to route those allocations to CMA. Maybe Konrad could
shed
some light over this?

It should allocate in batches and keep them in the TTM DMA pool for some time 
to be reused.

The pages that it gets are in 4kb granularity though.

Then I feel inclined to say this is a DMA subsystem bug. Single page
allocations shouldn't get routed to CMA.

/Thomas


Yes, seems you're both right. I read through the code a bit more and 
indeed the TTM DMA pool allocates only one page during each 
dma_alloc_coherent() call, so it doesn't need CMA memory. The current 
allocators don't check for single page CMA allocations and therefore try 
to get it from the CMA area anyway, instead of skipping to the much 
cheaper fallback.


So the callers of dma_alloc_from_contiguous() could need that little 
optimization of skipping it if only one page is requested. For


dma_generic_alloc_coherent  
  
andintel_alloc_coherent   
 this seems easy to do. Looking at the arm arch variants, e.g.,

http://lxr.free-electrons.com/source/arch/arm/mm/dma-mapping.c#L1194

and

http://lxr.free-electrons.com/source/arch/arm64/mm/dma-mapping.c#L44

i'm not sure if it is that easily done, as there aren't any fallbacks 
for such a case and the code looks to me as if that's at least somewhat 
intentional.


As far as TTM goes, one quick one-line fix to prevent it from using the 
CMA at least on SWIOTLB, NOMMU and Intel IOMMU (when using the above 
methods) would be to clear the __GFP_WAIT 
 flag from the passed 
gfp_t flags. That would trigger the well working fallback. So, is


__GFP_WAIT    needed for those 
single page allocations that go through__ttm_dma_alloc_page  
?

It would be nice to have such a simple, non-intrusive one-line patch 
that we still could get into 3.17 and then backported to older stable 
kernels to avoid the same desktop hangs there if CMA is enabled. It 
would be also nice for actual users of CMA to not use up lots of CMA 
space for gpu's which don't need it. I think DMA_CMA was introduced 
around 3.12.



The other problem is that probably TTM does not reuse pages from the DMA 
pool. If i trace the __ttm_dma_alloc_page 
 and 
__ttm_dma_free_page 
 calls for 
those single page allocs/frees, then over a 20 second interval of 
tracing and switching tabs in firefox, scrolling things around etc. i 
find about as many alloc's as i find free's, e.g., 1607 allocs vs. 1648 
frees.


This bit of code fromttm_dma_unpopulate 
()  (line 954 
in 3.16) looks suspicious:


http://lxr.free-electrons.com/source/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c#L954

Alloc's from a tt_cached cached pool ( if (is_cached)...) always get 
freed and are not given back to the cached pool. But in the uncached 
case, there's logic to make sure the pool doesn't grow forever (line 
955, checking against _manager->options.max_size), but before that check 
in line 954 there's an uncoditional assignment of npages = count; which 
seems to force freeing all pages as well, instead of recycling? Is this 
some debug code left over, or intentional and just me not understanding 
what happens there?


thanks,
-mario



/Thomas


On 08/08/2014 07:42 PM, Mario Kleiner wrote:

Hi all,

there is a rather severe performance problem i accidentally found

when

trying to give Linux 3.16.0 a final test on a x86_64 MacBookPro under
Ubuntu 14.04 LTS with nouveau as graphics driver.

I was lazy and just installed the Ubuntu precompiled mainline kernel.
That kernel happens to have CONFIG_DMA_CMA=y set, with a default CMA
(contiguous memory allocator) size of 64 MB. Older Ubuntu kernels
weren't compiled with CMA, so i only observed this on 3.16, but
previous kernels would likely be affected too.

After a few minutes of regular desktop use like switching workspaces,
scrolling text in a terminal window, Firefox with multiple tabs open,
Thunderbird etc. (tested with KDE/Kwin, with/without desktop
composition), i get chunky desktop updates, then multi-second

freezes,

after a few minutes the desktop hangs for over a minute on almost any
GUI action like switching windows etc. --> Unuseable.

ftrace'ing shows the culprit being t

Re: [PATCH 3.16 00/17] 3.16.1-stable review

[Olof Johansson]

On Sat, Aug 9, 2014 at 6:21 PM, Stephen Rothwell  wrote:
> Hi Linus,
>
> On Sat, 9 Aug 2014 10:43:51 -0700 Linus Torvalds 
>  wrote:
>>
>> On Sat, Aug 9, 2014 at 10:15 AM, Guenter Roeck  wrote:
>> >
>> > ERROR (phandle_references): Reference to non-existent node or label
>> > "disp_pd"
>> >
>> > ERROR: Input tree has errors, aborting (use -f to force output)
>> > make[1]: *** [arch/arm/boot/dts/exynos5420-arndale-octa.dtb] Error 2
>>
>> Ok, so it's something else that was apparently known about in -next,
>> but not mentioned when pushing to me. Oh well.

Yeah, I had missed this one since I thought the DRM guys would fix it
in their tree when it was reported.

It didn't show up for me since when I did my build/test before sending
pull requests since that was done with a mainline branch that hadn't
merged DRM yet.

>> The new disp_dt use was added by commit 5a8da524049c ("ARM: dts:
>> exynos5420: add dsi node"), while commit d51cad7df871 ("ARM: dts:
>> remove display power domain for exynos5420") removed the node.
>>
>> I'll leave it broken until the ARM people get around to fixing it.
>> Likely by just removing the disp_dt line from the dsi node, but I'll
>> let the proper people sort it out.
>
> Yeah, that's the correct fix (it was even tested).  Olof has the patch
> for you.

Yep, I've got the patch to do that in my current fixes branch that
I'll send tonight.


-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/

Runtime trouble with commit dbd952127d (seccomp: introduce writer locking)

[Guenter Roeck]

Hi folks,

I am having some trouble with commit dbd952127d (seccomp: introduce
writer locking) when running my qemu tests on the upstream kernel.

With powerpc, I get the following crash.

ftrace: allocating 20093 entries in 59 pages
[ cut here ]
kernel BUG at kernel/fork.c:1108!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT PowerMac
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.16.0-yocto-standard+ #1
task: c08a03d0 ti: c08e4000 task.ti: c08e4000
NIP: c002b98c LR: c002b988 CTR: c03837ec
REGS: c08e5e30 TRAP: 0700   Not tainted  (3.16.0-yocto-standard+)
MSR: 00021032   CR: 22282048  XER: 2000

GPR00: c002b988 c08e5ee0 c08a03d0 0001 c0a9b878 0800 c783603c 0020
GPR08: c783603c 0003 0001 c08f61fc 2044  07c5ac10 00800300
GPR16: c787 0010  07de7fa4  c08f594c c08f c78702d0
GPR24:  c08f c08f5940 c000422c c08a8ea0 c7870310  c7808400
NIP [c002b98c] copy_process.part.52+0x794/0x13e4
LR [c002b988] copy_process.part.52+0x790/0x13e4
Call Trace:
[c08e5ee0] [c002b988] copy_process.part.52+0x790/0x13e4 (unreliable)
[c08e5f60] [c002c768] do_fork+0xb8/0x3bc
[c08e5fa0] [c00041c8] rest_init+0x30/0x94
[c08e5fb0] [c083cf98] start_kernel+0x368/0x37c
[c08e5ff0] [3438] 0x3438
Instruction dump:
7d400124 3861 48027e95 55e903e1 41820b84 80e202c0 90f002c0 81420570
91500570 3861 48027e75 3941 <0f0a> 81420568 8162056c 91500568
---[ end trace dc8fa200cb88537f ]---

With  mips (both 32 bit and 64 bit), I get

NR_IRQS:256
CPU frequency 200.00 MHz
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [uart0] disabled

[ and then there is silence ]

In all cases I bisected the problem to the above mentioned commit.

Failures are seen in both linux-next and the tip of Linus' tree.
Test results are on http://server.roeck-us.net:8010/builders
(look for qwmu results). Build and test scripts are in the mips,
mips64, and powerpc subdirectories of
https://github.com/groeck/linux-build-test/tree/master/rootfs.

Any idea, anyone, what might be going on, or how I could do to
help tracking this down ?

Thanks,
Guenter

--
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/

mm: compaction: buffer overflow in isolate_migratepages_range

[Sasha Levin]

Hi all,

While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel with the KASAN patchset, I've stumbled on the following spew:


[ 3837.070452] 
==
[ 3837.073101] AddressSanitizer: buffer overflow in 
isolate_migratepages_range+0x85f/0xd90 at addr 88051b70eb49
[ 3837.076310] page:ea00146dc380 count:0 mapcount:0 mapping:  
(null) index:0x0
[ 3837.079876] page flags: 0xaf80008000(tail)
[ 3837.114592] page dumped because: kasan error
[ 3837.115897] CPU: 4 PID: 29613 Comm: trinity-c467 Not tainted 
3.16.0-next-20140808-sasha-00051-gf368221 #1051
[ 3837.118024]  00fc  ea00146dc380 
8801f326f718
[ 3837.119837]  97e0d344 8801f326f7e8 8801f326f7d8 
9342d5bc
[ 3837.121708]  ea00085163c0  8801f326f8e0 
93fe02fb
[ 3837.123704] Call Trace:
[ 3837.124272] dump_stack (lib/dump_stack.c:52)
[ 3837.125166] kasan_report_error (mm/kasan/report.c:98 mm/kasan/report.c:166)
[ 3837.126128] ? trace_hardirqs_on_thunk (arch/x86/lib/thunk_64.S:33)
[ 3837.127462] ? retint_restore_args (arch/x86/kernel/entry_64.S:828)
[ 3837.128753] __asan_load8 (mm/kasan/kasan.c:364)
[ 3837.129914] ? isolate_migratepages_range 
(./arch/x86/include/asm/bitops.h:311 include/linux/pagemap.h:70 
include/linux/balloon_compaction.h:131 include/linux/balloon_compaction.h:156 
mm/compaction.c:596)
[ 3837.131613] isolate_migratepages_range (./arch/x86/include/asm/bitops.h:311 
include/linux/pagemap.h:70 include/linux/balloon_compaction.h:131 
include/linux/balloon_compaction.h:156 mm/compaction.c:596)
[ 3837.132838] compact_zone (mm/compaction.c:877 mm/compaction.c:1044)
[ 3837.133818] compact_zone_order (mm/compaction.c:1106)
[ 3837.134982] try_to_compact_pages (mm/compaction.c:1161)
[ 3837.135970] __alloc_pages_direct_compact (mm/page_alloc.c:2313)
[ 3837.137217] ? next_zones_zonelist (mm/mmzone.c:72)
[ 3837.138861] __alloc_pages_nodemask (mm/page_alloc.c:2640 
mm/page_alloc.c:2806)
[ 3837.139897] ? check_chain_key (kernel/locking/lockdep.c:2190)
[ 3837.141220] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 3837.142434] alloc_pages_vma (mm/mempolicy.c:2046)
[ 3837.143479] ? do_huge_pmd_wp_page (mm/huge_memory.c:774 
mm/huge_memory.c:1123)
[ 3837.144663] do_huge_pmd_wp_page (mm/huge_memory.c:774 mm/huge_memory.c:1123)
[ 3837.145653] handle_mm_fault (mm/memory.c:3312 mm/memory.c:3370)
[ 3837.146717] ? vmacache_find (mm/vmacache.c:100 (discriminator 1))
[ 3837.147404] ? find_vma (mm/mmap.c:2024)
[ 3837.147982] __do_page_fault (arch/x86/mm/fault.c:1231)
[ 3837.148613] ? context_tracking_user_exit (kernel/context_tracking.c:184)
[ 3837.149388] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 3837.150212] ? trace_hardirqs_off_caller (kernel/locking/lockdep.c:2641 
(discriminator 8))
[ 3837.150977] ? trace_hardirqs_off (kernel/locking/lockdep.c:2647)
[ 3837.151686] trace_do_page_fault (arch/x86/mm/fault.c:1314 
include/linux/jump_label.h:115 include/linux/context_tracking_state.h:27 
include/linux/context_tracking.h:45 arch/x86/mm/fault.c:1315)
[ 3837.152870] do_async_page_fault (arch/x86/kernel/kvm.c:279)
[ 3837.153886] async_page_fault (arch/x86/kernel/entry_64.S:1313)
[ 3837.155293] Read of size 8 by thread T29613:
[ 3837.156058] Memory state around the buggy address:
[ 3837.156885]  88051b70e880: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc 
fc
[ 3837.158141]  88051b70e900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[ 3837.159492]  88051b70e980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[ 3837.160863]  88051b70ea00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[ 3837.162165]  88051b70ea80: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc 
fc
[ 3837.163552] >88051b70eb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[ 3837.164866]   ^
[ 3837.165914]  88051b70eb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[ 3837.167317]  88051b70ec00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[ 3837.168616]  88051b70ec80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[ 3837.169898]  88051b70ed00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[ 3837.171298]  88051b70ed80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[ 3837.172611] 
==


Thanks,
Sasha
--
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 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()

[Paul E. McKenney]

On Sat, Aug 09, 2014 at 08:33:55PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 08, 2014 at 01:58:26PM -0700, Paul E. McKenney wrote:
> > 
> > > And on that, you probably should change rcu_sched_rq() to read:
> > > 
> > >   this_cpu_inc(rcu_sched_data.passed_quiesce);
> > > 
> > > That avoids touching the per-cpu data offset.
> > 
> > Hmmm...  Interrupts are disabled,
> 
> No they are not, __schedule()->rcu_note_context_switch()->rcu_sched_qs()
> is only called with preemption disabled.
> 
> We only disable IRQs later, where we take the rq->lock.

You want me not to disable irqs before invoking rcu_preempt_qs() from
rcu_preempt_note_context_switch(), I get that.  But right now, they
really are disabled courtesy of the local_irq_save() before the call
to rcu_preempt_qs() from rcu_preempt_note_context_switch().

> > so no need to further disable
> > interrupts.  Storing 1 works fine, no need to increment.  If I followed
> > the twisty per_cpu passages correctly, my guess is that you would like
> > me to do something like this:
> > 
> > __this_cpu_write(rcu_sched_data.passed_quiesce, 1);
> > 
> > Does that work?
> 
> Yeah, should be more or less similar, the inc might be encoded shorter
> due to not requiring an immediate, but who cares :-)
> 
> void rcu_sched_qs(int cpu)
> {
>   if (trace_rcu_grace_period_enabled()) {
>   if (!__this_cpu_read(rcu_sched_data.passed_quiesce))
>   trace_rcu_grace_period(...);
>   }
>   __this_cpu_write(rcu_sched_data.passed_quiesce, 1);
> }
> 
> Would further avoid emitting the conditional in the normal case where
> the tracepoint is inactive.

It might be better to avoid storing to rcu_sched_data.passed_quiesce when
it is already 1, though the difference would be quite hard to measure.
In that case, this would work nicely:

static void rcu_preempt_qs(int cpu)
{
if (rdp->passed_quiesce == 0) {
trace_rcu_grace_period(TPS("rcu_preempt"), rdp->gpnum, 
TPS("cpuqs"));
>   __this_cpu_write(rcu_sched_data.passed_quiesce, 1);
}
current->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_NEED_QS;
}

> Steve does it make sense to have __DO_TRACE() emit __trace_##name() to
> avoid the double static_branch thing?
> 
> > > And it would be very good if we could avoid the unconditional IRQ flag
> > > fiddling in rcu_preempt_note_context_switch(), them expensive, this
> > > looks entirely feasibly in the 'normal' case where
> > > t->rcu_read_unlock_special doesn't have RCU_READ_UNLOCK_NEED_QS set.
> > 
> > Agreed, but sometimes RCU_READ_UNLOCK_NEED_QS is set.
> > 
> > That said, I should probably revisit RCU_READ_UNLOCK_NEED_QS.  A lot has
> > changed since I wrote that code.
> 
> Sure, but a conditional testing RCU_READ_UNLOCK_NEED_QS is far cheaper
> than poking the IRQ flags. That said, its not entirely clear to me why
> that needs IRQs disabled at all, then again I didn't look long and I'm
> sure its all subtle.

This bit gets set from the scheduler-clock interrupt, so disabling
interrupts is the standard approach to avoid confusion.  Might be possible
to avoid it in this case, or make it less frequent, or whatever.  As I
said, I haven't thought much about it since the initial implementation
some years back, so worth worrying about again.

Thanx, Paul

--
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] [PATCH 45/53] drm/i915/bdw: Do not call intel_runtime_pm_get() in an interrupt

[Rafael J. Wysocki]

On Saturday, August 09, 2014 10:53:03 AM Daniel Vetter wrote:
> On Sat, Aug 9, 2014 at 3:21 AM, Alan Stern  wrote:
> > On Sat, 9 Aug 2014, Rafael J. Wysocki wrote:
> >
> >> > > > Well it works currently. So where do you see the problem?
> >> > >
> >> > > Sampling registers from an timer - in particular, we really do not want
> >> > > to disable runtime pm whilst trying to monitor the impact of runtime 
> >> > > pm.
> >> >
> >> > In that case you can grab a runtime pm reference iff the device is 
> >> > powered
> >> > on already. Which won't call anything scary, just amounts to an
> >> > atomic_add_unless or so, and then drop it again.
> >> >
> >> > Unfortunately there doesn't seem to be such a thing around already, so
> >> > need to add it first. Greg, how much would you freak out if we add
> >> > something like
> >> >
> >> > /**
> >> >  * pm_runtime_get_unless_suspended - grab a rpm ref if the device is on
> >> >  *
> >> >  * Returns true if an rpm ref has been acquire, false otherwise. Can be
> >> >  * called from atomic context to e.g. sample perfomance counters (where 
> >> > we
> >> >  * obviously don't want to disturb system state if everything is off 
> >> > atm).
> >> >  */
> >> > static inline bool pm_runtime_get_unless_suspended(struct device *dev)
> >> > {
> >> > return atomic_add_unless(&dev->power.usage_count, 1, 0);
> >> > }
> >>
> >> I don't think it'll work universally.
> >>
> >> That'd need to be synchronized with other stuff done under the spinlock
> >> and in fact, what you're interested in is runtime_status (and that being
> >> RPM_ACTIVE) and not just the usage count.
> >
> > That's right.  You'd need to acquire the spinlock, test runtime_status,
> > do the register sampling if the status is RPM_ACTIVE, and then drop the
> > spinlock.
> >
> > I suppose wrapper routines for acquiring and releasing the spinlock
> > could be added to the runtime-PM API.  Something like this:
> >
> > #define pm_runtime_lock(dev, flags) \
> > spin_lock_irqsave(&(dev)->power.lock, flags)
> > #define pm_runtime_unlock(dev, flags)   \
> > spin_unlock_irqrestore(&(dev)->power.lock, flags)
> >
> > It looks a little silly but it would work.
> 
> Oh right, I've totally ignored all the async resuming/suspending
> stuff. Anyway what we want to do is sample a perf monitoring unit on
> the gpu from an hrtimer and then expose that as a perf pmu. But we
> don't want to wake up the gpu for the sampling or hold a special
> reference, since that disturbs the sampling and also tends to upset
> the gpu.

The way to go is as Alan said: take the spinlock, check the runtime status,
do stuff and release the spinlock.

Rafael

--
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 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()

[Paul E. McKenney]

On Sat, Aug 09, 2014 at 08:24:00PM +0200, Peter Zijlstra wrote:
> On Sat, Aug 09, 2014 at 08:19:20PM +0200, Peter Zijlstra wrote:
> > How about we simply assume 'idle' code, as defined by the rcu idle hooks
> > are safe? Why do we want to bend over backwards to cover this?
> 
> The thing is, we already have the special rcu trace hooks for tracing
> inside this rcu-idle section, so why go beyond this now?

I have to defer to Steven and Masami on this one, but I would guess that
they want the ability to trace the idle loop for the same reasons they
stated earlier.

Thanx, Paul

--
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 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()

[Paul E. McKenney]

On Sat, Aug 09, 2014 at 08:19:20PM +0200, Peter Zijlstra wrote:
> On Sat, Aug 09, 2014 at 09:01:37AM -0700, Paul E. McKenney wrote:
> > > That's so wrong its not funny. If you need some abortion to deal with
> > > NOHZ_FULL then put it under CONFIG_NOHZ_FULL, don't burden the entire
> > > world with it.
> > 
> > Peter, the polling approach actually -reduces- the common-case
> > per-context-switch burden, as in when RCU-tasks isn't doing anything.
> > See your own code above.
> 
> I'm not seeing it, CONFIG_PREEMPT already touches a per task cacheline
> for each context switch. And for !PREEMPT this thing should pretty much
> reduce to rcu_sched.

Except when you do the wakeup operation, in which case you have something
that is either complex, slow and non-scalable, or both.  I am surprised
that you want anything like that on that path.

> Would not the thing I proposed be a valid rcu_preempt implementation?
> one where its rcu read side primitives run from (voluntary) schedule()
> to (voluntary) schedule() call and therefore entirely cover smaller
> sections.

In theory, sure.  In practice, blocking on tasks that are preempted
outside of an RCU read-side critical section would not be a good thing
for normal RCU, which has frequent update operations.  Among other things.

> > > As for idle tasks, I'm not sure about those, I think that we should say
> > > NO to anything that would require waking idle CPUs, push the pain to
> > > ftrace/kprobes, we should _not_ be waking idle cpus.
> > 
> > So the current patch set wakes an idle task once per RCU-tasks grace
> > period, but only when that idle task did not otherwise get awakened.
> > This is not a real problem.
> 
> And on the other hand we're trying to reduce random wakeups, so this
> sure is a problem. If we don't start, we don't have to fix later.

I doubt that a wakeup at the end of certain ftrace operations is going
to be a real problem.

> > And it could probably be reduced further, for example, for architectures
> > where the program counter of sleeping CPUs can be remotely accessed and
> > where the address of the am-asleep code is known.  I doubt that this
> > would really be worth it, but it could be done, in theory anyway.  Or, as
> > Steven suggested earlier, there could be a per-CPU variable that was set
> > (with approapriate memory ordering) when the CPU was actually sleeping.
> > 
> > So I don't believe that the current wakeup rate is a problem, and it
> > can be reduced if it proves to be a problem.
> 
> How about we simply assume 'idle' code, as defined by the rcu idle hooks
> are safe? Why do we want to bend over backwards to cover this?

Steven covered this earlier in this thread.  One addition might be "For
the same reason that event tracing provides the _rcuidle suffix."

Thanx, Paul

--
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.16 00/17] 3.16.1-stable review

[Stephen Rothwell]

Hi Linus,

On Sat, 9 Aug 2014 10:43:51 -0700 Linus Torvalds 
 wrote:
>
> On Sat, Aug 9, 2014 at 10:15 AM, Guenter Roeck  wrote:
> >
> > ERROR (phandle_references): Reference to non-existent node or label
> > "disp_pd"
> >
> > ERROR: Input tree has errors, aborting (use -f to force output)
> > make[1]: *** [arch/arm/boot/dts/exynos5420-arndale-octa.dtb] Error 2
> 
> Ok, so it's something else that was apparently known about in -next,
> but not mentioned when pushing to me. Oh well.
> 
> The new disp_dt use was added by commit 5a8da524049c ("ARM: dts:
> exynos5420: add dsi node"), while commit d51cad7df871 ("ARM: dts:
> remove display power domain for exynos5420") removed the node.
>
> I'll leave it broken until the ARM people get around to fixing it.
> Likely by just removing the disp_dt line from the dsi node, but I'll
> let the proper people sort it out.

Yeah, that's the correct fix (it was even tested).  Olof has the patch
for you.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

[PATCH] staging: lustre: lustre: ptlrpc: nrs.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist 
---
 drivers/staging/lustre/lustre/ptlrpc/nrs.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/lustre/lustre/ptlrpc/nrs.c 
b/drivers/staging/lustre/lustre/ptlrpc/nrs.c
index 12151aa..a914447 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/nrs.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/nrs.c
@@ -1162,6 +1162,7 @@ int ptlrpc_nrs_policy_register(struct ptlrpc_nrs_pol_conf 
*conf)
GOTO(fail, rc = -ENOMEM);
 
strncpy(desc->pd_name, conf->nc_name, NRS_POL_NAME_MAX);
+   desc->pd_name[NRS_POL_NAME_MAX - 1] = '\0';
desc->pd_ops = conf->nc_ops;
desc->pd_compat  = conf->nc_compat;
desc->pd_compat_svc_name = conf->nc_compat_svc_name;
-- 
1.7.10.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/

[PATCH] staging: lustre: lustre: obdclass: genops.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist 
---
 drivers/staging/lustre/lustre/obdclass/genops.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/lustre/lustre/obdclass/genops.c 
b/drivers/staging/lustre/lustre/obdclass/genops.c
index 3210ad8..082b5b9 100644
--- a/drivers/staging/lustre/lustre/obdclass/genops.c
+++ b/drivers/staging/lustre/lustre/obdclass/genops.c
@@ -328,6 +328,7 @@ struct obd_device *class_newdev(const char *type_name, 
const char *name)
result->obd_type = type;
strncpy(result->obd_name, name,
sizeof(result->obd_name) - 1);
+   result->obd_name[sizeof(result->obd_name) - 1] = '\0';
obd_devs[i] = result;
}
}
-- 
1.7.10.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/

[PATCH] staging: lustre: lustre: libcfs: workitem.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist 
---
 drivers/staging/lustre/lustre/libcfs/workitem.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/lustre/lustre/libcfs/workitem.c 
b/drivers/staging/lustre/lustre/libcfs/workitem.c
index 0a03bf7..60326f2 100644
--- a/drivers/staging/lustre/lustre/libcfs/workitem.c
+++ b/drivers/staging/lustre/lustre/libcfs/workitem.c
@@ -365,6 +365,7 @@ cfs_wi_sched_create(char *name, struct cfs_cpt_table *cptab,
return -ENOMEM;
 
strncpy(sched->ws_name, name, CFS_WS_NAME_LEN);
+   sched->ws_name[CFS_WS_NAME_LEN - 1] = '\0';
sched->ws_cptab = cptab;
sched->ws_cpt = cpt;
 
-- 
1.7.10.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/

[PATCH] misc: ti-st: st_kim.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist 
---
 drivers/misc/ti-st/st_kim.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/ti-st/st_kim.c b/drivers/misc/ti-st/st_kim.c
index 9d3dbb2..bce4468 100644
--- a/drivers/misc/ti-st/st_kim.c
+++ b/drivers/misc/ti-st/st_kim.c
@@ -593,6 +593,7 @@ static ssize_t store_dev_name(struct device *dev,
struct kim_data_s *kim_data = dev_get_drvdata(dev);
pr_debug("storing dev name >%s<", buf);
strncpy(kim_data->dev_name, buf, count);
+   kim_data->dev_name[count - 1] = '\n';
pr_debug("stored dev name >%s<", kim_data->dev_name);
return count;
 }
-- 
1.7.10.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/

[PATCH] misc: c2port: core.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist 
---
 drivers/misc/c2port/core.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/c2port/core.c b/drivers/misc/c2port/core.c
index 464419b..62b0baa 100644
--- a/drivers/misc/c2port/core.c
+++ b/drivers/misc/c2port/core.c
@@ -933,6 +933,7 @@ struct c2port_device *c2port_device_register(char *name,
dev_set_drvdata(c2dev->dev, c2dev);
 
strncpy(c2dev->name, name, C2PORT_NAME_LEN);
+   c2dev->name[C2PORT_NAME_LEN - 1] = '\0';
c2dev->ops = ops;
mutex_init(&c2dev->mutex);
 
-- 
1.7.10.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/

[PATCH] message: fusion: mptbase.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist 
---
 drivers/message/fusion/mptbase.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index ebc0af7..66324f8 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -7706,8 +7706,10 @@ mpt_display_event_info(MPT_ADAPTER *ioc, 
EventNotificationReply_t *pEventReply)
ds = "Unknown";
break;
}
-   if (ds)
+   if (ds) {
strncpy(evStr, ds, EVENT_DESCR_STR_SZ);
+   evStr[EVENT_DESCR_STR_SZ - 1] = '\0';
+   }
 
 
devtprintk(ioc, printk(MYIOC_s_DEBUG_FMT
-- 
1.7.10.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/

[PATCH] net: ethernet: ti: cpmac.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist 
---
 drivers/net/ethernet/ti/cpmac.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/ti/cpmac.c b/drivers/net/ethernet/ti/cpmac.c
index 7399a52..ad268a3 100644
--- a/drivers/net/ethernet/ti/cpmac.c
+++ b/drivers/net/ethernet/ti/cpmac.c
@@ -1125,6 +1125,7 @@ static int cpmac_probe(struct platform_device *pdev)
strncpy(mdio_bus_id, "fixed-0", MII_BUS_ID_SIZE); /* fixed phys 
bus */
phy_id = pdev->id;
}
+   mdio_bus_id[sizeof(mdio_bus_id) - 1] = '\0';
 
dev = alloc_etherdev_mq(sizeof(*priv), CPMAC_QUEUES);
if (!dev)
-- 
1.7.10.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/

[PATCH] net: ethernet: myricom: myri10ge: myri10ge.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist 
---
 drivers/net/ethernet/myricom/myri10ge/myri10ge.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c 
b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
index f3d5d79..de327b6 100644
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
@@ -574,6 +574,7 @@ myri10ge_validate_firmware(struct myri10ge_priv *mgp,
 
/* save firmware version for ethtool */
strncpy(mgp->fw_version, hdr->version, sizeof(mgp->fw_version));
+   mgp->fw_version[sizeif(mgp->fw_version) - 1] = '\0';
 
sscanf(mgp->fw_version, "%d.%d.%d", &mgp->fw_ver_major,
   &mgp->fw_ver_minor, &mgp->fw_ver_tiny);
-- 
1.7.10.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/

[PATCH] net: wireless: ipw2x00: ipw2200.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist 
---
 drivers/net/wireless/ipw2x00/ipw2200.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c 
b/drivers/net/wireless/ipw2x00/ipw2200.c
index c5aa404..389656b 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -9853,6 +9853,7 @@ static int ipw_wx_get_wireless_mode(struct net_device 
*dev,
strncpy(extra, "unknown", MAX_WX_STRING);
break;
}
+   extra[MAX_WX_STRING - 1] = '\0';
 
IPW_DEBUG_WX("PRIV GET MODE: %s\n", extra);
 
-- 
1.7.10.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: [PATCH] vfio: Fix build failure seen if vfio is built as module and EEH is enabled

[Guenter Roeck]

On 08/09/2014 04:18 PM, Alex Williamson wrote:

On Sat, 2014-08-09 at 15:28 -0700, Guenter Roeck wrote:

On 08/09/2014 12:28 PM, Alex Williamson wrote:

On Sat, 2014-08-09 at 10:04 -0700, Guenter Roeck wrote:

The following build failure is seen with ppc:allmodconfig.

ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko] 
undefined!
ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!

Simply exporting the missing symbols is insufficient, since drivers/vfio
can be built as module but drivers/vfio/vfio_spapr_eeh.c depends on
EEH which is boolean. The combination of obj-m for drivers/vfio and obj-y
for drivers/vfio/vfio_spapr_eeh.o results in the symbols being missed even
if exported.

Export missing symbols and introduce new tristate configuration option
VFIO_EEH depending on both EEH and VFIO to fix the problem.

Cc: Gavin Shan 
Cc: Benjamin Herrenschmidt 
Signed-off-by: Guenter Roeck 


Please try:

git://github.com/awilliam/linux-vfio.git next

This will be part of the next linux-next build, should resolve the
problem, and I plan to ask for a pull early this coming week.  Thanks,



That should do for the most part, but it will select VFIO_SPAPR_EEH
even if EEH is not configured. You would need something like
select VFIO_SPAPR_EEH if (PPC_POWERNV || PPC_PSERIES) && EEH
to prevent that.


Feel free to post a patch against this branch.  Thanks,



I'll wait for -next to see if there are any problems in practice.

Guenter

--
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/

BUG: early intel microcode update violating alignment rules

[Henrique de Moraes Holschuh]

Hello x86 maintainers,

While adding some paranoia to the Intel Microcode driver, I noticed the
early Intel microcode update driver is not enforcing a 16-byte alignment
when it attempts to send the microcode update data to the processor via
WRMSR 79H.

This 16-byte alignment requirement is stated in the Intel SDM, vol 3A,
section 9.11.6, page 9-34.

Apparently at least some of the recent processors don't need the full
16-byte alignment, as a microcode update that is NOT aligned to 16 bytes,
but which is aligned to 4 bytes seems to work fine on a Xeon X5550 and on a
2nd-gen Core i5.

I detected the problem by adding an alignment test in
apply_microcode_early(), on file arch/x86/kernel/microcode_intel_early.c:

if ((unsigned long)(mc_intel->bits) % 16)
return -1;

Which fired on the next reboot, skipping the early update on the BSP and
APs.

This will only happen when the microcode update file data inside the early
initramfs archive is not 16-byte aligned.  Unfortunately, the cpio format
used in the early initramfs aligns the member file data just to 4-byte
boundaries.

Is there a way to fix this in the kernel for the BSP?  We already have
several microcode updates that are >16KiB in size and they seem to be
getting bigger and bigger, so doing it on the stack is out.

Maybe there is a 64KiB scratch area that could be used just to get the BSP
microcode update done?  vmalloc isn't available that early, but it can be
used to fix the issue for the APs.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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] vfio: Fix build failure seen if vfio is built as module and EEH is enabled

[Alex Williamson]

On Sat, 2014-08-09 at 15:28 -0700, Guenter Roeck wrote:
> On 08/09/2014 12:28 PM, Alex Williamson wrote:
> > On Sat, 2014-08-09 at 10:04 -0700, Guenter Roeck wrote:
> >> The following build failure is seen with ppc:allmodconfig.
> >>
> >> ERROR: ".vfio_spapr_iommu_eeh_ioctl" 
> >> [drivers/vfio/vfio_iommu_spapr_tce.ko] undefined!
> >> ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
> >> ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] 
> >> undefined!
> >>
> >> Simply exporting the missing symbols is insufficient, since drivers/vfio
> >> can be built as module but drivers/vfio/vfio_spapr_eeh.c depends on
> >> EEH which is boolean. The combination of obj-m for drivers/vfio and obj-y
> >> for drivers/vfio/vfio_spapr_eeh.o results in the symbols being missed even
> >> if exported.
> >>
> >> Export missing symbols and introduce new tristate configuration option
> >> VFIO_EEH depending on both EEH and VFIO to fix the problem.
> >>
> >> Cc: Gavin Shan 
> >> Cc: Benjamin Herrenschmidt 
> >> Signed-off-by: Guenter Roeck 
> >
> > Please try:
> >
> > git://github.com/awilliam/linux-vfio.git next
> >
> > This will be part of the next linux-next build, should resolve the
> > problem, and I plan to ask for a pull early this coming week.  Thanks,
> >
> 
> That should do for the most part, but it will select VFIO_SPAPR_EEH
> even if EEH is not configured. You would need something like
>   select VFIO_SPAPR_EEH if (PPC_POWERNV || PPC_PSERIES) && EEH
> to prevent that.

Feel free to post a patch against this branch.  Thanks,

Alex


--
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/3] mm/hugetlb: add migration entry check in hugetlb_change_protection

[Hugh Dickins]

On Fri, 1 Aug 2014, Naoya Horiguchi wrote:

> There is a race condition between hugepage migration and change_protection(),
> where hugetlb_change_protection() doesn't care about migration entries and
> wrongly overwrites them. That causes unexpected results like kernel crash.
> 
> This patch adds is_hugetlb_entry_(migration|hwpoisoned) check in this
> function and skip all such entries.
> 
> Signed-off-by: Naoya Horiguchi 
> Cc:   # [3.12+]
> ---
>  mm/hugetlb.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git mmotm-2014-07-22-15-58.orig/mm/hugetlb.c 
> mmotm-2014-07-22-15-58/mm/hugetlb.c
> index 863f45f63cd5..1da7ca2e2a02 100644
> --- mmotm-2014-07-22-15-58.orig/mm/hugetlb.c
> +++ mmotm-2014-07-22-15-58/mm/hugetlb.c
> @@ -3355,7 +3355,13 @@ unsigned long hugetlb_change_protection(struct 
> vm_area_struct *vma,
>   spin_unlock(ptl);
>   continue;
>   }
> - if (!huge_pte_none(huge_ptep_get(ptep))) {
> + pte = huge_ptep_get(ptep);
> + if (unlikely(is_hugetlb_entry_migration(pte) ||
> +  is_hugetlb_entry_hwpoisoned(pte))) {

Another instance of this pattern.  Oh well, perhaps we have to continue
this way while backporting fixes, but the repetition irritates me.
Or use is_swap_pte() as follow_hugetlb_page() does?

More importantly, the regular change_pte_range() has to
make_migration_entry_read() if is_migration_entry_write():
why is that not necessary here?

And have you compared hugetlb codepaths with normal codepaths, to see
if there are other huge places which need to check for a migration entry
now?  If you have checked, please reassure us in the commit message:
we would prefer not to have these fixes coming in one by one.

(I first thought __unmap_hugepage_range() would need it, but since
zap_pte_range() only checks it for rss stats, and hugetlb does not
participate in rss stats, it looks like no need.)

Hugh

> + spin_unlock(ptl);
> + continue;
> + }
> + if (!huge_pte_none(pte)) {
>   pte = huge_ptep_get_and_clear(mm, address, ptep);
>   pte = pte_mkhuge(huge_pte_modify(pte, newprot));
>   pte = arch_make_huge_pte(pte, vma, NULL, 0);
> -- 
> 1.9.3
--
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/3] mm/hugetlb: use get_page_unless_zero() in hugetlb_fault()

[Hugh Dickins]

On Fri, 1 Aug 2014, Naoya Horiguchi wrote:

> After fixing locking in follow_page(FOLL_GET) for hugepages, I start to
> observe the BUG of "get_page() on refcount 0 page" in hugetlb_fault() in
> the same test.
> 
> I'm not exactly sure about how this race is triggered, but hugetlb_fault()
> calls pte_page() and get_page() outside page table lock, so it's not safe.
> This patch checks the refcount of the gotten page, and aborts the page fault
> if the refcount is 0, expecting to retry.
> 

Fixes: 66aebce747ea ("hugetlb: fix race condition in hugetlb_fault()")

> Signed-off-by: Naoya Horiguchi 
> Cc:   # [3.12+]


I disagree with your 3.12+ annotation there: you may have hit the issue
in testing your hugepage migration work, but it's older than that: the
problematic get_page() was introduced in 3.4, and has been backported
to 3.2-stable: so 3.2+.

I was suspicious of this patch at first, then on the point of giving it
an Ack, and then realized that I had been right to be suspicious of it.

You're not the first the get the sequence wrong here; and it won't be
surprising if there are other instances of subtle get_page_unless_zero()
misuse elsewhere in the tree (I dare not look!  someone else please do).

It's not the use of get_page_unless_zero() itself that is wrong, it's
the unjustified confidence in it: what's wrong is the lock_page() after.

As you have found, and acknowledged with get_page_unless_zero(), is
that the page here may be stale, it might be already freed, it might
be already reused.  If reused, then its page_count will no longer be 0,
but the new user expects to have sole ownership of the page.  The new
owner might be using __set_page_locked() (or one of the other nonatomic
flags operations), or "if (!trylock_page(newpage)) BUG()" like
migration's move_to_new_page().

We are dealing with a recently-hugetlb page here: that might make the
race I'm describing even less likely than with usual order:0 pages,
but I don't think it eliminates it.

What to do instead?  The first answer that occurs to me is to move the
the pte_page,get_page down after the pte_same check inside the spin_lock,
and only then do trylock_page(), backing out to wait_on_page_locked and
retry or refault if not.

Though if doing that, it might be more sensible only to trylock_page
before dropping ptl inside hugetlb_cow().  That would be a bigger,
maybe harder to backport, rearrangement.

What do you think?

Hugh

> ---
>  mm/hugetlb.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git mmotm-2014-07-22-15-58.orig/mm/hugetlb.c 
> mmotm-2014-07-22-15-58/mm/hugetlb.c
> index 4437896cd6ed..863f45f63cd5 100644
> --- mmotm-2014-07-22-15-58.orig/mm/hugetlb.c
> +++ mmotm-2014-07-22-15-58/mm/hugetlb.c
> @@ -3189,7 +3189,8 @@ int hugetlb_fault(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>* so no worry about deadlock.
>*/
>   page = pte_page(entry);
> - get_page(page);
> + if (!get_page_unless_zero(page))
> + goto out_put_pagecache;
>   if (page != pagecache_page)
>   lock_page(page);
>  
> @@ -3215,15 +3216,14 @@ int hugetlb_fault(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>  
>  out_ptl:
>   spin_unlock(ptl);
> -
> + if (page != pagecache_page)
> + unlock_page(page);
> + put_page(page);
> +out_put_pagecache:
>   if (pagecache_page) {
>   unlock_page(pagecache_page);
>   put_page(pagecache_page);
>   }
> - if (page != pagecache_page)
> - unlock_page(page);
> - put_page(page);
> -
>  out_mutex:
>   mutex_unlock(&htlb_fault_mutex_table[hash]);
>   return ret;
> -- 
> 1.9.3
--
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 1/3] mm/hugetlb: take refcount under page table lock in follow_huge_pmd()

[Hugh Dickins]

On Fri, 1 Aug 2014, Naoya Horiguchi wrote:

> We have a race condition between move_pages() and freeing hugepages,
> where move_pages() calls follow_page(FOLL_GET) for hugepages internally
> and tries to get its refcount without preventing concurrent freeing.
> This race crashes the kernel, so this patch fixes it by moving FOLL_GET
> code for hugepages into follow_huge_pmd() with taking the page table lock.
> 
> This patch passes the following test. And libhugetlbfs test shows no
> regression.
> 
>   $ cat movepages.c
>   #include 
>   #include 
>   #include 
> 
>   #define ADDR_INPUT  0x7000UL
>   #define HPS 0x20
>   #define PS  0x1000
> 
>   int main(int argc, char *argv[]) {
>   int i;
>   int nr_hp = strtol(argv[1], NULL, 0);
>   int nr_p  = nr_hp * HPS / PS;
>   int ret;
>   void **addrs;
>   int *status;
>   int *nodes;
>   pid_t pid;
> 
>   pid = strtol(argv[2], NULL, 0);
>   addrs  = malloc(sizeof(char *) * nr_p + 1);
>   status = malloc(sizeof(char *) * nr_p + 1);
>   nodes  = malloc(sizeof(char *) * nr_p + 1);
> 
>   while (1) {
>   for (i = 0; i < nr_p; i++) {
>   addrs[i] = (void *)ADDR_INPUT + i * PS;
>   nodes[i] = 1;
>   status[i] = 0;
>   }
>   ret = numa_move_pages(pid, nr_p, addrs, nodes, status,
> MPOL_MF_MOVE_ALL);
>   if (ret == -1)
>   err("move_pages");
> 
>   for (i = 0; i < nr_p; i++) {
>   addrs[i] = (void *)ADDR_INPUT + i * PS;
>   nodes[i] = 0;
>   status[i] = 0;
>   }
>   ret = numa_move_pages(pid, nr_p, addrs, nodes, status,
> MPOL_MF_MOVE_ALL);
>   if (ret == -1)
>   err("move_pages");
>   }
>   return 0;
>   }
> 
>   $ cat hugepage.c
>   #include 
>   #include 
>   #include 
> 
>   #define ADDR_INPUT  0x7000UL
>   #define HPS 0x20
> 
>   int main(int argc, char *argv[]) {
>   int nr_hp = strtol(argv[1], NULL, 0);
>   char *p;
> 
>   while (1) {
>   p = mmap((void *)ADDR_INPUT, nr_hp * HPS, PROT_READ | 
> PROT_WRITE,
>MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);
>   if (p != (void *)ADDR_INPUT) {
>   perror("mmap");
>   break;
>   }
>   memset(p, 0, nr_hp * HPS);
>   munmap(p, nr_hp * HPS);
>   }
>   }
> 
>   $ sysctl vm.nr_hugepages=40
>   $ ./hugepage 10 &
>   $ ./movepages 10 $(pgrep -f hugepage)
> 
> Note for stable inclusion:
>   This patch fixes e632a938d914 ("mm: migrate: add hugepage migration code
>   to move_pages()"), so is applicable to -stable kernels which includes it.
> 
> ChangeLog v2:
> - introduce follow_huge_pmd_lock() to do locking in arch-independent code.
> 
> Signed-off-by: Naoya Horiguchi 
> Cc:   # [3.12+]
> ---
>  include/linux/hugetlb.h |  3 +++
>  mm/gup.c| 17 ++---
>  mm/hugetlb.c| 27 +++
>  3 files changed, 32 insertions(+), 15 deletions(-)
> 
> diff --git mmotm-2014-07-22-15-58.orig/include/linux/hugetlb.h 
> mmotm-2014-07-22-15-58/include/linux/hugetlb.h
> index 41272bcf73f8..194834853d6f 100644
> --- mmotm-2014-07-22-15-58.orig/include/linux/hugetlb.h
> +++ mmotm-2014-07-22-15-58/include/linux/hugetlb.h
> @@ -101,6 +101,8 @@ struct page *follow_huge_pmd(struct mm_struct *mm, 
> unsigned long address,
>   pmd_t *pmd, int write);
>  struct page *follow_huge_pud(struct mm_struct *mm, unsigned long address,
>   pud_t *pud, int write);
> +struct page *follow_huge_pmd_lock(struct vm_area_struct *vma,
> + unsigned long address, pmd_t *pmd, int flags);
>  int pmd_huge(pmd_t pmd);
>  int pud_huge(pud_t pmd);
>  unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
> @@ -134,6 +136,7 @@ static inline void hugetlb_show_meminfo(void)
>  }
>  #define follow_huge_pmd(mm, addr, pmd, write)NULL
>  #define follow_huge_pud(mm, addr, pud, write)NULL
> +#define follow_huge_pmd_lock(vma, addr, pmd, flags)  NULL
>  #define prepare_hugepage_range(file, addr, len)  (-EINVAL)
>  #define pmd_huge(x)  0
>  #define pud_huge(x)  0
> diff --git mmotm-2014-07-22-15-58.orig/mm/gup.c 
> mmotm-2014-07-22-15-58/mm/gup.c
> index 91d044b1600d..e4bd59efe686 100644
> --- mmotm-2014-07-22-15-58.orig/mm/gup.c
> +++ mmotm-2014-07-22-15-58/mm/gup.c
> @@ -174,21 +174,8 @@ struct page *follow_page_mask(struct vm_area_struct *vma,
>   pmd

Re: [PATCH] [next-20140808] [staging] [lustre] Fix coding style in llite/remote_perm.c

[Aaro Koskinen]

On Sat, Aug 09, 2014 at 08:22:48PM +, Junien Fridrick wrote:
> Sorry for the noise, this is part of task 10 of the Eudyptula Challenge.

Nothing wrong with the patch itself, but maybe in the future you could
put such comments after the "---" line so that they won't be included
in the git commit logs when the patch is applied (and will end
up being "noise").

A.
--
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: Loading initrd above 4G causes freeze on boot

[Mantas Mikulėnas]

On Sat, Aug 9, 2014 at 10:23 PM, Matt Fleming  wrote:
>
> On Sat, 09 Aug, at 09:44:55AM, Yinghai Lu wrote:
> > On Sat, Aug 9, 2014 at 7:23 AM, Mantas Mikulėnas  wrote:
> > > As of commit 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G"),
> > > the kernel freezes at the earliest possible moment when trying to boot
> > > via UEFI on my Asus laptop. (It still boots via BIOS.)
> > >
> > > If I revert that commit on current master (c309bfa9b481), it boots
> > > correctly again [although I see "setup_efi_pci() failed" being printed].
> > >
> > > (Seems like it freezes when handle_cmdline_files() attempts to read
> > > the last chunk of the initramfs -- the last call to efi_file_read()
> > > never returns. Figuring out why that happens is beyond me, though.)
> > >
> >
> > Matt found that efi_file_read()/firmware has problem that could not do
> > several reading. Please check if reverting that commit have any
> > difference.
> >
> > ---
> > I spent some time playing around with this bug and it appears to be
> > triggered by the read-a-chunk-at-a-time logic in handle_cmdline_files(),
> > (which is itself a bug workaround) introduced here,
> >
> >   commit 2d2da60fb40a
> >   Author: Maarten Lankhorst 
> >   Date:   Fri Dec 16 13:30:58 2011 +0100
> >
> >   x86, efi: Break up large initrd reads
>
> Right, I committed a patch to workaround this problem here,
>
>   
> http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=next&id=1c24a2bef39f041eb578189207240d0457ef0ac3
>
> since on my ASUS machine the combination of breaking up initrd reads
> into chunks and reading into a buffer above 4G actually triggers a whole
> new bug.
>
> Mantas, could you try out the patch referenced above and pass
> "efi=nochunk" on the command line to the EFI boot stub. I'm hoping that
> fixes your problem.

Thanks for the patch, I've just tested it but the problem remains; the
system freezes even when reading the entire initramfs at once.

[However... Whether it's five chunks, four (after making the initrd
smaller), or just one (with your efi=nochunk), I noticed that it
*always* hangs during the *last* read, and the allocated memory always
ends at roughly the same address (0x137fffXXX). I wonder if it's
selecting a memory location already in use, or something like that...]

(The laptop is Asus K52JT, AMI firmware v206, no updates available.)

-- 
Mantas Mikulėnas 
--
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] vfio: Fix build failure seen if vfio is built as module and EEH is enabled

[Guenter Roeck]

On 08/09/2014 12:28 PM, Alex Williamson wrote:

On Sat, 2014-08-09 at 10:04 -0700, Guenter Roeck wrote:

The following build failure is seen with ppc:allmodconfig.

ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko] 
undefined!
ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!

Simply exporting the missing symbols is insufficient, since drivers/vfio
can be built as module but drivers/vfio/vfio_spapr_eeh.c depends on
EEH which is boolean. The combination of obj-m for drivers/vfio and obj-y
for drivers/vfio/vfio_spapr_eeh.o results in the symbols being missed even
if exported.

Export missing symbols and introduce new tristate configuration option
VFIO_EEH depending on both EEH and VFIO to fix the problem.

Cc: Gavin Shan 
Cc: Benjamin Herrenschmidt 
Signed-off-by: Guenter Roeck 


Please try:

git://github.com/awilliam/linux-vfio.git next

This will be part of the next linux-next build, should resolve the
problem, and I plan to ask for a pull early this coming week.  Thanks,



That should do for the most part, but it will select VFIO_SPAPR_EEH
even if EEH is not configured. You would need something like
select VFIO_SPAPR_EEH if (PPC_POWERNV || PPC_PSERIES) && EEH
to prevent that.

Guenter

--
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] mm, hugetlb_cgroup: align hugetlb cgroup limit to hugepage size

[David Rientjes]

On Sat, 9 Aug 2014, Aneesh Kumar K.V wrote:

> > diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
> > --- a/mm/hugetlb_cgroup.c
> > +++ b/mm/hugetlb_cgroup.c
> > @@ -275,6 +275,7 @@ static ssize_t hugetlb_cgroup_write(struct 
> > kernfs_open_file *of,
> > ret = res_counter_memparse_write_strategy(buf, &val);
> > if (ret)
> > break;
> > +   val = ALIGN(val, 1ULL << huge_page_shift(&hstates[idx]));
> 
> Do we really need ULL ? max value should fit in unsigned long right ?
> 

I usually just go for type agreement.

> > ret = res_counter_set_limit(&h_cg->hugepage[idx], val);
> > break;
> > default:
> 
> 
--
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 v6 3/7] arm: Support restart through restart handler call chain

[Guenter Roeck]

On 08/09/2014 01:01 PM, Heiko Stübner wrote:

Hi Guenter,

Am Montag, 4. August 2014, 18:48:54 schrieb Guenter Roeck:

The kernel core now supports a restart handler call chain for system
restart functions.

With this change, the arm_pm_restart callback is now optional, so check
if it is set before calling it. Only call the kernel restart handler
if arm_pm_restart is not set.

Signed-off-by: Guenter Roeck 
Acked-by: Catalin Marinas 
Acked-by: Heiko Stuebner 
---
v6: No change.
v5: Renamed restart function to do_kernel_restart
v4: No change.
v3: Use wrapper function to execute notifier call chain.
v2: Only call notifier call chain if arm_pm_restart is not set.
 Do not include linux/watchdog.h.

  arch/arm/kernel/process.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 81ef686..84ca0d5 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -230,7 +230,10 @@ void machine_restart(char *cmd)
local_irq_disable();
smp_send_stop();

-   arm_pm_restart(reboot_mode, cmd);
+   if (arm_pm_restart)
+   arm_pm_restart(reboot_mode, cmd);
+   else
+   do_kernel_restart(cmd);

/* Give a grace period for failure to restart of 1s */
mdelay(1000);


shouldn't you also get rid of

void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd) = 
null_restart;


Yes. Looks like I'll need another revision.

Even worse, the current upstream code is somewhat broken and doesn't really
like the following instructions.
drivers/watchdog/moxart_wdt.c:  arm_pm_restart = NULL;
drivers/watchdog/sunxi_wdt.c:   arm_pm_restart = NULL;

Fortunately that code is only executed if those drivers are built as modules
and unloaded.

Guenter


like a previous attempt at unifying the restart handling [0] did.

Because when testing the current series on my Rockchip boards, there was
always an arm_pm_restart defined ... namely the null_restart mentioned above.
So do_kernel_restart is never reached until I disable the null_restart.


Heiko


[0] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/277042

--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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/

Re: [PATCH v6 3/7] arm: Support restart through restart handler call chain

[Heiko Stübner]

Hi Guenter,

Am Montag, 4. August 2014, 18:48:54 schrieb Guenter Roeck:
> The kernel core now supports a restart handler call chain for system
> restart functions.
> 
> With this change, the arm_pm_restart callback is now optional, so check
> if it is set before calling it. Only call the kernel restart handler
> if arm_pm_restart is not set.
> 
> Signed-off-by: Guenter Roeck 
> Acked-by: Catalin Marinas 
> Acked-by: Heiko Stuebner 
> ---
> v6: No change.
> v5: Renamed restart function to do_kernel_restart
> v4: No change.
> v3: Use wrapper function to execute notifier call chain.
> v2: Only call notifier call chain if arm_pm_restart is not set.
> Do not include linux/watchdog.h.
> 
>  arch/arm/kernel/process.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 81ef686..84ca0d5 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -230,7 +230,10 @@ void machine_restart(char *cmd)
>   local_irq_disable();
>   smp_send_stop();
> 
> - arm_pm_restart(reboot_mode, cmd);
> + if (arm_pm_restart)
> + arm_pm_restart(reboot_mode, cmd);
> + else
> + do_kernel_restart(cmd);
> 
>   /* Give a grace period for failure to restart of 1s */
>   mdelay(1000);

shouldn't you also get rid of 

void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd) = 
null_restart;

like a previous attempt at unifying the restart handling [0] did.

Because when testing the current series on my Rockchip boards, there was
always an arm_pm_restart defined ... namely the null_restart mentioned above.
So do_kernel_restart is never reached until I disable the null_restart.


Heiko


[0] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/277042

--
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] Input: wacom - Fix compiler warning if !CONFIG_PM

[Jiri Kosina]

On Sat, 9 Aug 2014, Geert Uytterhoeven wrote:

> If CONFIG_PM is not set:
> 
> drivers/hid/wacom_sys.c:1436: warning: ‘wacom_reset_resume’ defined but
> not used
> 
> Protect the unused functions by #ifdef CONFIG_PM to fix this.
> 
> Signed-off-by: Geert Uytterhoeven 

Thanks Geert.

hid-wacom is in a sort of temporary mode of operation, being moved from 
Input to HID driver.

Adding Benjamin and Dmitry to CC, as this will likely still go through 
Dmitry's queue.

> ---
>  drivers/hid/wacom_sys.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 3e388ec31da8..f0db7eca9023 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -1416,6 +1416,7 @@ static void wacom_remove(struct hid_device *hdev)
>   kfree(wacom);
>  }
>  
> +#ifdef CONFIG_PM
>  static int wacom_resume(struct hid_device *hdev)
>  {
>   struct wacom *wacom = hid_get_drvdata(hdev);
> @@ -1436,6 +1437,7 @@ static int wacom_reset_resume(struct hid_device *hdev)
>  {
>   return wacom_resume(hdev);
>  }
> +#endif /* CONFIG_PM */
>  
>  static struct hid_driver wacom_driver = {
>   .name = "wacom",
> -- 
> 1.9.1
> 

-- 
Jiri Kosina
SUSE Labs
--
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] [next-20140808] [staging] [lustre] Fix coding style in llite/remote_perm.c

[Junien Fridrick]

Sorry for the noise, this is part of task 10 of the Eudyptula Challenge.

Signed-off-by: Junien Fridrick 
---
 drivers/staging/lustre/lustre/llite/remote_perm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/remote_perm.c 
b/drivers/staging/lustre/lustre/llite/remote_perm.c
index f61fefc..3a9c8e8 100644
--- a/drivers/staging/lustre/lustre/llite/remote_perm.c
+++ b/drivers/staging/lustre/lustre/llite/remote_perm.c
@@ -100,7 +100,7 @@ void free_rmtperm_hash(struct hlist_head *hash)
struct ll_remote_perm *lrp;
struct hlist_node *next;
 
-   if(!hash)
+   if (!hash)
return;
 
for (i = 0; i < REMOTE_PERM_HASHSIZE; i++)
-- 
2.0.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/

[PATCH v2] clk: rockchip: add restart handler

[Heiko Stübner]

Add infrastructure to write the correct value to the restart register and
register the restart notifier for both rk3188 (including rk3066) and rk3288.

Signed-off-by: Heiko Stuebner 
---
This of course needs the restart generalization from Guenter Roeck
and would need to go with that series.

changes since v1:
- adapt to changed restart notifier handling

 drivers/clk/rockchip/clk-rk3188.c |  2 ++
 drivers/clk/rockchip/clk-rk3288.c |  2 ++
 drivers/clk/rockchip/clk.c| 25 +
 drivers/clk/rockchip/clk.h|  1 +
 4 files changed, 30 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index a83a6d8..71b661a 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -631,6 +631,8 @@ static void __init rk3188_common_clk_init(struct 
device_node *np)
 
rockchip_register_softrst(np, 9, reg_base + RK2928_SOFTRST_CON(0),
  ROCKCHIP_SOFTRST_HIWORD_MASK);
+
+   rockchip_register_restart_notifier(RK2928_GLB_SRST_FST);
 }
 
 static void __init rk3066a_clk_init(struct device_node *np)
diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 0d8c6c5..b604217 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -713,5 +713,7 @@ static void __init rk3288_clk_init(struct device_node *np)
 
rockchip_register_softrst(np, 9, reg_base + RK3288_SOFTRST_CON(0),
  ROCKCHIP_SOFTRST_HIWORD_MASK);
+
+   rockchip_register_restart_notifier(RK3288_GLB_SRST_FST);
 }
 CLK_OF_DECLARE(rk3288_cru, "rockchip,rk3288-cru", rk3288_clk_init);
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index 278cf9d..aa41433 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "clk.h"
 
 /**
@@ -242,3 +243,27 @@ void __init rockchip_clk_register_branches(
rockchip_clk_add_lookup(clk, list->id);
}
 }
+
+static unsigned int reg_restart;
+static int rockchip_restart_notify(struct notifier_block *this,
+  unsigned long mode, void *cmd)
+{
+   writel(0xfdb9, reg_base + reg_restart);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block rockchip_restart_handler = {
+   .notifier_call = rockchip_restart_notify,
+   .priority = 128,
+};
+
+void __init rockchip_register_restart_notifier(unsigned int reg)
+{
+   int ret;
+
+   reg_restart = reg;
+   ret = register_restart_handler(&rockchip_restart_handler);
+   if (ret)
+   pr_err("%s: cannot register restart handler, %d\n",
+  __func__, ret);
+}
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index 887cbde..0b5eab5 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -329,6 +329,7 @@ void rockchip_clk_register_branches(struct 
rockchip_clk_branch *clk_list,
unsigned int nr_clk);
 void rockchip_clk_register_plls(struct rockchip_pll_clock *pll_list,
unsigned int nr_pll, int grf_lock_offset);
+void rockchip_register_restart_notifier(unsigned int reg);
 
 #define ROCKCHIP_SOFTRST_HIWORD_MASK   BIT(0)
 
-- 
2.0.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/

[PULL] nfsd changes for 3.17

[J. Bruce Fields]

Please pull nfsd changes for 3.17 from

  git://linux-nfs.org/~bfields/linux.git for-3.17

This includes a major rewrite of the NFSv4 state code, which has always
depended on a single mutex.  As an example, open creates are no longer
serialized, fixing a performance regression on NFSv3->NFSv4 upgrades.
Thanks to Jeff, Trond, and Benny, and to Christoph for review.

Also some RDMA fixes from Chuck Lever and Steve Wise, and miscellaneous
fixes from Kinglong Mee and others.

--b.


Christoph Hellwig (1):
  nfsd: fix file access refcount leak when nfsd4_truncate fails

Chuck Lever (3):
  svcrdma: Select NFSv4.1 backchannel transport based on forward channel
  svcrdma: Add zero padding if the client doesn't send it
  svcrdma: Double the default credit limit

Himangi Saraogi (1):
  nfsd4: convert comma to semicolon

J. Bruce Fields (11):
  nfsd: fix rare symlink decoding bug
  nfsd: make NFSv2 null terminate symlink data
  nfsd: let nfsd_symlink assume null-terminated data
  nfsd4: rename cr_linkname->cr_data
  nfsd4: remove unused defer_free argument
  nfsd4: define svcxdr_dupstr to share some common code
  nfsd4: remove nfs4_acl_new
  nfsd4: replace defer_free by svcxdr_tmpalloc
  nfsd4: zero op arguments beyond the 8th compound op
  nfsd4: CREATE_SESSION should update backchannel immediately
  nfsd4: fix out of date comment

Jeff Layton (77):
  nfsd: add __force to opaque verifier field casts
  nfsd: clean up sparse endianness warnings in nfscache.c
  nfsd: nfsd_splice_read and nfsd_readv should return __be32
  nfsd: add appropriate __force directives to filehandle generation code
  nfsd: fix return of nfs4_acl_write_who
  nfsd: properly handle embedded newlines in fault_injection input
  nfsd: add a new /proc/fs/nfsd/max_connections file
  nfsd: declare v4.1+ openowners confirmed on creation
  nfsd: Allow lockowners to hold several stateids
  nfsd: clean up nfsd4_release_lockowner
  nfsd: properly convert return from commit_metadata to __be32
  nfsd: add a nfserrno mapping for -E2BIG to nfserr_fbig
  nfsd: Allow struct nfsd4_compound_state to cache the nfs4_client
  nfsd: close potential race between delegation break and laundromat
  nfsd: reduce some spinlocking in put_client_renew
  nfsd: refactor nfs4_file_get_access and nfs4_file_put_access
  nfsd: remove nfs4_file_put_fd
  nfsd: shrink st_access_bmap and st_deny_bmap
  nfsd: set stateid access and deny bits in nfs4_get_vfs_file
  nfsd: clean up reset_union_bmap_deny
  nfsd: always hold the fi_lock when bumping fi_access refcounts
  nfsd: make deny mode enforcement more efficient and close races in it
  nfsd: cleanup and rename nfs4_check_open
  nfsd: eliminate nfsd4_init_callback
  nfsd: Avoid taking state_lock while holding inode lock in 
nfsd_break_one_deleg
  nfsd: nfs4_alloc_init_lease should take a nfs4_file arg
  nfsd: silence sparse warning about accessing credentials
  nfsd: fix race that grants unrecallable delegation
  nfsd: bump dl_time when unhashing delegation
  nfsd: ensure that st_access_bmap and st_deny_bmap are initialized to 0
  nfsd: Do not let nfs4_file pin the struct inode
  nfsd: fully unhash delegations when revoking them
  nfsd: ensure that clp->cl_revoked list is protected by clp->cl_lock
  nfsd: drop unused stp arg to alloc_init_deleg
  nfsd: clean up arguments to nfs4_open_delegation
  nfsd: clean up nfs4_set_delegation
  nfsd: give block_delegation and delegation_blocked its own spinlock
  nfsd: remove dl_fh field from struct nfs4_delegation
  nfsd: print status when nfsd4_open fails to open file it just created
  nfsd4: use cl_lock to synchronize all stateid idr calls
  nfsd: do filp_close in sc_free callback for lock stateids
  nfsd: Add locking to protect the state owner lists
  nfsd: clean up races in lock stateid searching and creation
  nfsd: ensure atomicity in nfsd4_free_stateid and nfsd4_validate_stateid
  nfsd: Add reference counting to state owners
  nfsd: Add a mutex to protect the NFSv4.0 open owner replay cache
  nfsd: clean up lockowner refcounting when finding them
  nfsd: add an operation for unhashing a stateowner
  nfsd: clean up refcounting for lockowners
  nfsd: make openstateids hold references to their openowners
  nfsd: don't allow CLOSE to proceed until refcount on stateid drops
  nfsd: clean up and reorganize release_lockowner
  nfsd: add locking to stateowner release
  nfsd: optimize destroy_lockowner cl_lock thrashing
  nfsd: close potential race in nfsd4_free_stateid
  nfsd: reduce cl_lock thrashing in release_openowner
  nfsd: don't thrash the cl_lock while freeing an open stateid
  nfsd: rename unhash_generic_stateid to unhash_ol_stateid

Re: [PATCH] i2c: qup: disable clks and return instead of just returning error

[Wolfram Sang]

(Ooops, this mail got somehow into my postponed folder. Sending
anyhow...)

On Wed, Aug 06, 2014 at 06:03:25PM +0530, Pramod Gurav wrote:
> This fixes a error handling scenario where clocks were not being disabled
> when QUP_OUTPUT_BLOCK_SIZE returns a size greater than the size of blk_sizes
> array. So this patch adds a statement to jump to the fail lable to release the
> clocks.
> 
> CC: Wolfram Sang 
> CC: Grant Likely 
> CC: Bjorn Andersson 
> CC: Andy Gross 
> CC: "Ivan T. Ivanov" 
> 
> Signed-off-by: Pramod Gurav 

Applied to for-next with Ivan's ack from V2, thanks!

Please use "[PATCH V3]" and alike in the future to make it more obvious
which version is the most recent.



signature.asc
Description: Digital signature

Re: [PATCH] vfio: Fix build failure seen if vfio is built as module and EEH is enabled

[Alex Williamson]

On Sat, 2014-08-09 at 10:04 -0700, Guenter Roeck wrote:
> The following build failure is seen with ppc:allmodconfig.
> 
> ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko] 
> undefined!
> ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
> ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!
> 
> Simply exporting the missing symbols is insufficient, since drivers/vfio
> can be built as module but drivers/vfio/vfio_spapr_eeh.c depends on
> EEH which is boolean. The combination of obj-m for drivers/vfio and obj-y
> for drivers/vfio/vfio_spapr_eeh.o results in the symbols being missed even
> if exported.
> 
> Export missing symbols and introduce new tristate configuration option
> VFIO_EEH depending on both EEH and VFIO to fix the problem.
> 
> Cc: Gavin Shan 
> Cc: Benjamin Herrenschmidt 
> Signed-off-by: Guenter Roeck 

Please try:

git://github.com/awilliam/linux-vfio.git next

This will be part of the next linux-next build, should resolve the
problem, and I plan to ask for a pull early this coming week.  Thanks,

Alex

> ---
>  drivers/vfio/Kconfig  | 6 ++
>  drivers/vfio/Makefile | 2 +-
>  drivers/vfio/vfio_spapr_eeh.c | 4 
>  3 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index af7b204..06adecd 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -8,12 +8,18 @@ config VFIO_IOMMU_SPAPR_TCE
>   depends on VFIO && SPAPR_TCE_IOMMU
>   default n
>  
> +config VFIO_EEH
> + tristate
> + depends on VFIO && EEH
> + default n
> +
>  menuconfig VFIO
>   tristate "VFIO Non-Privileged userspace driver framework"
>   depends on IOMMU_API
>   select VFIO_IOMMU_TYPE1 if X86
>   select VFIO_IOMMU_SPAPR_TCE if (PPC_POWERNV || PPC_PSERIES)
>   select ANON_INODES
> + select VFIO_EEH if EEH
>   help
> VFIO provides a framework for secure userspace device drivers.
> See Documentation/vfio.txt for more details.
> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> index 50e30bc..26016cd 100644
> --- a/drivers/vfio/Makefile
> +++ b/drivers/vfio/Makefile
> @@ -1,5 +1,5 @@
>  obj-$(CONFIG_VFIO) += vfio.o
>  obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
>  obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
> -obj-$(CONFIG_EEH) += vfio_spapr_eeh.o
> +obj-$(CONFIG_VFIO_EEH) += vfio_spapr_eeh.o
>  obj-$(CONFIG_VFIO_PCI) += pci/
> diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
> index f834b4c..e827309 100644
> --- a/drivers/vfio/vfio_spapr_eeh.c
> +++ b/drivers/vfio/vfio_spapr_eeh.c
> @@ -9,6 +9,7 @@
>   * published by the Free Software Foundation.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -18,11 +19,13 @@ int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
>  {
>   return eeh_dev_open(pdev);
>  }
> +EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
>  
>  void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
>  {
>   eeh_dev_release(pdev);
>  }
> +EXPORT_SYMBOL(vfio_spapr_pci_eeh_release);
>  
>  long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>   unsigned int cmd, unsigned long arg)
> @@ -85,3 +88,4 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
>  
>   return ret;
>  }
> +EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl);



--
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: [sched] Out of memory: Kill process 2999 (rc) score 9 or sacrifice child

[Oleg Nesterov]

On 08/09, Peter Zijlstra wrote:
>
> That would suggest we're failing to do the TASK_DEAD thing properly, and
> ARGH! bloody obvious why, see the this_rq() comment right before the
> finish_task_switch() call in context_switch().

Heh ;) and a similar comment in __schedule() after context_switch().

rq->dead_task or something similar should work I guess, but i should be
nullified before finish_lock_switch()...

Oleg.

--
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: Loading initrd above 4G causes freeze on boot

[Matt Fleming]

On Sat, 09 Aug, at 09:44:55AM, Yinghai Lu wrote:
> On Sat, Aug 9, 2014 at 7:23 AM, Mantas Mikulėnas  wrote:
> > As of commit 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G"),
> > the kernel freezes at the earliest possible moment when trying to boot
> > via UEFI on my Asus laptop. (It still boots via BIOS.)
> >
> > If I revert that commit on current master (c309bfa9b481), it boots
> > correctly again [although I see "setup_efi_pci() failed" being printed].
> >
> > (Seems like it freezes when handle_cmdline_files() attempts to read
> > the last chunk of the initramfs -- the last call to efi_file_read()
> > never returns. Figuring out why that happens is beyond me, though.)
> >
> 
> Matt found that efi_file_read()/firmware has problem that could not do
> several reading. Please check if reverting that commit have any
> difference.
> 
> ---
> I spent some time playing around with this bug and it appears to be
> triggered by the read-a-chunk-at-a-time logic in handle_cmdline_files(),
> (which is itself a bug workaround) introduced here,
> 
>   commit 2d2da60fb40a
>   Author: Maarten Lankhorst 
>   Date:   Fri Dec 16 13:30:58 2011 +0100
> 
>   x86, efi: Break up large initrd reads

Right, I committed a patch to workaround this problem here,

  
http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=next&id=1c24a2bef39f041eb578189207240d0457ef0ac3

since on my ASUS machine the combination of breaking up initrd reads
into chunks and reading into a buffer above 4G actually triggers a whole
new bug.

Mantas, could you try out the patch referenced above and pass
"efi=nochunk" on the command line to the EFI boot stub. I'm hoping that
fixes your problem.

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/

INFO

[GORDON C]

Hello,
 
My name is Gordon Chang and I work in a reputable bank. I have a transaction 
that I believe will be of mutual benefits to both of us. It involves an 
investment portfolio in our organization which I like to acquire with your help 
and assistance. This will be executed under a legitimate arrangement that will 
protect you from any breach of the law and you will be You will be compensated 
adequately according to agreed commissions.
 
All I require from you is your trust and honest cooperation to enable us see 
this transaction through. You will have to show commitments to the cause as 
time will be of great importance in what we have to do. If you are interested 
and prepared to work with me according to these dictates, please reply to this 
mail immediately so that we can discuss, make assessments and after your basic 
understanding of the whole business, commence the process by which we will 
actualize the project. I wish you a pleasant day as I hope to read from you on 
my private email chang...@qq.com
 
Yours sincerely,

Gordon
--
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: [sched] Out of memory: Kill process 2999 (rc) score 9 or sacrifice child

[Peter Zijlstra]

On Sat, Aug 09, 2014 at 10:30:34PM +0800, Fengguang Wu wrote:
> Hi Peter,
> 
> We noticed the below changes on
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/wait
> commit d58d631b474c552dce72da2dce9dd276d731b79a ("sched: Fix 
> finish_task_switch vs prev_state")
> 
> test case: vm-vp-quantal-x86_64/boot/1
> 
> 9e6e6179961e8dd  d58d631b474c552dce72da2dc  testbox/testcase/testparams
> ---  -  ---
>  0   +Inf%  1 ± 0%  TOTAL 
> dmesg.Out_of_memory:Kill_process
>  0   +Inf%  0 ±50%  TOTAL 
> dmesg.Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes
> 
> In commit 9e6e6179961e8dd, the boot dmesg is
> 
> [7.537598] Freeing unused kernel memory: 3352K (8223 - 
> 82576000)
> [7.558273] random: init urandom read with 11 bits of entropy available
> [7.687132] init: Failed to create pty - disabling logging for job
> [7.688578] init: Temporary process spawn error: No space left on device
> [   68.298970] reboot: Restarting system
> 
> In d58d631b474c552dce72da2dc, the OOM occurred immediately after the
> "No space left on device" line. The qemu has mem=320M and the initrds
> are 24M in total. What's interesting is, in the 5 boot tests for
> d58d631b47 and its parent commit, this OOM message is 100%
> reproducible on commit d58d631b47, while its parent boots all fine. 

That would suggest we're failing to do the TASK_DEAD thing properly, and
ARGH! bloody obvious why, see the this_rq() comment right before the
finish_task_switch() call in context_switch().

Oleg any clever ideas or do I store in a scratch per-cpu variable or
something daft like that?

---
commit d58d631b474c552dce72da2dce9dd276d731b79a
Author: Peter Zijlstra 
Date:   Tue Jul 29 11:22:37 2014 +0200

sched: Fix finish_task_switch vs prev_state

Oleg wondered about the prev_state comment in finish_task_switch().

Aside from it being confusingly worded -- we neither initially
understood the actual problem being described -- we found that we'd
broken the scenario described.

Ever since commit e4a52bcb9a18 ("sched: Remove rq->lock from the first
half of ttwu()") we don't actually acquire rq->lock on wakeups anymore
and therefore holding rq->lock after the switch is no good.

Even if we did, __ARCH_WANT_UNLOCKED_CTXSW was already broken, because
it explicitly didn't hold the rq->lock anymore.

We could fix things by placing a full barrier between the prev->state
read and the next->on_cpu = 0 store, seeing how the remote wakeup code
waits for ->on_cpu to become false before proceeding with the wakeup
(so as to avoid having the task running on two cpus at the same time),
however full barriers are expensive.

Instead we read prev->state before the context switch and propagate it
unto finish_task_switch. This trivially solves the problem without
adding extra (and costly) memory barriers.

I'm not sure why we've never seen crashes due to this, it appears
entirely possible.

Fixes: e4a52bcb9a18 ("sched: Remove rq->lock from the first half of ttwu()")
Cc: Ingo Molnar 
Cc: John Stultz 
Cc: Thomas Gleixner 
Cc: Frederic Weisbecker 
Cc: Dave Jones 
Cc: Andrey Ryabinin 
Cc: Sasha Levin 
Cc: Manfred Spraul 
Reported-by: Oleg Nesterov 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20140729092237.gu12...@laptop.lan
---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1211575a2208..df2f691f09f6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2190,6 +2190,7 @@ prepare_task_switch(struct rq *rq, struct task_struct 
*prev,
  * finish_task_switch - clean up after a task-switch
  * @rq: runqueue associated with task-switch
  * @prev: the thread we just switched away from.
+ * @prev_state: the state of @prev before we switched away from it.
  *
  * finish_task_switch must be called after the context switch, paired
  * with a prepare_task_switch call before the context switch.
@@ -2201,26 +2202,14 @@ prepare_task_switch(struct rq *rq, struct task_struct 
*prev,
  * with the lock held can cause deadlocks; see schedule() for
  * details.)
  */
-static void finish_task_switch(struct rq *rq, struct task_struct *prev)
+static void
+finish_task_switch(struct rq *rq, struct task_struct *prev, long prev_state)
__releases(rq->lock)
 {
struct mm_struct *mm = rq->prev_mm;
-   long prev_state;
 
rq->prev_mm = NULL;
 
-   /*
-* A task struct has one reference for the use as "current".
-* If a task dies, then it sets TASK_DEAD in tsk->state and calls
-* schedule one last time. The schedule call will never return, and
-* the scheduled task must drop that reference.
-* The test for TASK_DEAD must occur while the runqueue locks are
-* still held, otherwise prev could be scheduled on another cpu, die
-* there before we look at prev->state, and then the reference would
-* be dropped

Re: [PATCH v3 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()

[Peter Zijlstra]

On Fri, Aug 08, 2014 at 01:58:26PM -0700, Paul E. McKenney wrote:
> 
> > And on that, you probably should change rcu_sched_rq() to read:
> > 
> > this_cpu_inc(rcu_sched_data.passed_quiesce);
> > 
> > That avoids touching the per-cpu data offset.
> 
> Hmmm...  Interrupts are disabled,

No they are not, __schedule()->rcu_note_context_switch()->rcu_sched_qs()
is only called with preemption disabled.

We only disable IRQs later, where we take the rq->lock.

> so no need to further disable
> interrupts.  Storing 1 works fine, no need to increment.  If I followed
> the twisty per_cpu passages correctly, my guess is that you would like
> me to do something like this:
> 
>   __this_cpu_write(rcu_sched_data.passed_quiesce, 1);
> 
> Does that work?

Yeah, should be more or less similar, the inc might be encoded shorter
due to not requiring an immediate, but who cares :-)

void rcu_sched_qs(int cpu)
{
if (trace_rcu_grace_period_enabled()) {
if (!__this_cpu_read(rcu_sched_data.passed_quiesce))
trace_rcu_grace_period(...);
}
__this_cpu_write(rcu_sched_data.passed_quiesce, 1);
}

Would further avoid emitting the conditional in the normal case where
the tracepoint is inactive.

Steve does it make sense to have __DO_TRACE() emit __trace_##name() to
avoid the double static_branch thing?

> > And it would be very good if we could avoid the unconditional IRQ flag
> > fiddling in rcu_preempt_note_context_switch(), them expensive, this
> > looks entirely feasibly in the 'normal' case where
> > t->rcu_read_unlock_special doesn't have RCU_READ_UNLOCK_NEED_QS set.
> 
> Agreed, but sometimes RCU_READ_UNLOCK_NEED_QS is set.
> 
> That said, I should probably revisit RCU_READ_UNLOCK_NEED_QS.  A lot has
> changed since I wrote that code.

Sure, but a conditional testing RCU_READ_UNLOCK_NEED_QS is far cheaper
than poking the IRQ flags. That said, its not entirely clear to me why
that needs IRQs disabled at all, then again I didn't look long and I'm
sure its all subtle.


pgpZhrUd88Wwi.pgp
Description: PGP signature

Re: [PATCH v3 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()

[Peter Zijlstra]

On Sat, Aug 09, 2014 at 08:19:20PM +0200, Peter Zijlstra wrote:
> How about we simply assume 'idle' code, as defined by the rcu idle hooks
> are safe? Why do we want to bend over backwards to cover this?

The thing is, we already have the special rcu trace hooks for tracing
inside this rcu-idle section, so why go beyond this now?


pgpGDVQ1oHpC5.pgp
Description: PGP signature

Re: [PATCH v3 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()

[Peter Zijlstra]

On Sat, Aug 09, 2014 at 09:01:37AM -0700, Paul E. McKenney wrote:
> > That's so wrong its not funny. If you need some abortion to deal with
> > NOHZ_FULL then put it under CONFIG_NOHZ_FULL, don't burden the entire
> > world with it.
> 
> Peter, the polling approach actually -reduces- the common-case
> per-context-switch burden, as in when RCU-tasks isn't doing anything.
> See your own code above.

I'm not seeing it, CONFIG_PREEMPT already touches a per task cacheline
for each context switch. And for !PREEMPT this thing should pretty much
reduce to rcu_sched.

Would not the thing I proposed be a valid rcu_preempt implementation?
one where its rcu read side primitives run from (voluntary) schedule()
to (voluntary) schedule() call and therefore entirely cover smaller
sections.

> > As for idle tasks, I'm not sure about those, I think that we should say
> > NO to anything that would require waking idle CPUs, push the pain to
> > ftrace/kprobes, we should _not_ be waking idle cpus.
> 
> So the current patch set wakes an idle task once per RCU-tasks grace
> period, but only when that idle task did not otherwise get awakened.
> This is not a real problem.

And on the other hand we're trying to reduce random wakeups, so this
sure is a problem. If we don't start, we don't have to fix later.

> And it could probably be reduced further, for example, for architectures
> where the program counter of sleeping CPUs can be remotely accessed and
> where the address of the am-asleep code is known.  I doubt that this
> would really be worth it, but it could be done, in theory anyway.  Or, as
> Steven suggested earlier, there could be a per-CPU variable that was set
> (with approapriate memory ordering) when the CPU was actually sleeping.
> 
> So I don't believe that the current wakeup rate is a problem, and it
> can be reduced if it proves to be a problem.

How about we simply assume 'idle' code, as defined by the rcu idle hooks
are safe? Why do we want to bend over backwards to cover this?


pgpROOz4alYgS.pgp
Description: PGP signature

Re: [PATCH RFC] sched: deferred set priority (dprio)

[Andi Kleen]

> NAK.  There it is, my imaginary NAK to imaginary realtime priorities :)

Ok, but do you have any alternative proposal yourself how to solve the
lockholder preemption problem? I assume you agree it's a real problem.

Just being negative is not very constructive.

-Andi
--
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] mips: Fix nlm_xlp_defconfig build error

[Guenter Roeck]

The nlm_xlp_defconfig build fails with

./arch/mips/include/asm/mach-netlogic/topology.h:15:0:
error: "topology_core_id" redefined [-Werror]
In file included from include/linux/smp.h:59:0,
[ ...]
 from arch/mips/mm/dma-default.c:12:
./arch/mips/include/asm/smp.h:41:0:
note: this is the location of the previous definition

and similar errors.

This is caused by commit bda4584cd943d7 ("MIPS: Support CPU topology files
in sysfs") which adds the defines to arch/mips/include/asm/smp.h.

Remove the defines from arch/mips/include/asm/mach-netlogic/topology.h
as no longer necessary.

Cc: Huacai Chen 
Cc: Andreas Herrmann 
Signed-off-by: Guenter Roeck 
---
 arch/mips/include/asm/mach-netlogic/topology.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/mips/include/asm/mach-netlogic/topology.h 
b/arch/mips/include/asm/mach-netlogic/topology.h
index ceeb1f5..0eb43c8 100644
--- a/arch/mips/include/asm/mach-netlogic/topology.h
+++ b/arch/mips/include/asm/mach-netlogic/topology.h
@@ -10,13 +10,6 @@
 
 #include 
 
-#ifdef CONFIG_SMP
-#define topology_physical_package_id(cpu)  cpu_to_node(cpu)
-#define topology_core_id(cpu)  (cpu_logical_map(cpu) / NLM_THREADS_PER_CORE)
-#define topology_thread_cpumask(cpu)   (&cpu_sibling_map[cpu])
-#define topology_core_cpumask(cpu) cpumask_of_node(cpu_to_node(cpu))
-#endif
-
 #include 
 
 #endif /* _ASM_MACH_NETLOGIC_TOPOLOGY_H */
-- 
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] staging: soc_camera: soc_camera_platform.c: Fixed a Missing blank line coding style issue

[Hans Verkuil]

On 08/09/2014 07:36 PM, Guennadi Liakhovetski wrote:
> Hi Suman,
> 
> On Sat, 9 Aug 2014, Suman Kumar wrote:
> 
>> Fixes a coding style issue reported by checkpatch.pl
> 
> Thanks for your patch. To my taste checkpatch.pl has unfortunately become 
> too noisy with meaningless / unimportant warnings like this one. Is this 
> in CodingStyle? If not, my intention is to drop this.

I don't see it being mentioned explicitly in the CodingStyle, but the coding
style follows K&R, and they put an empty line between local variables and the
start of the code. And I like it that way as well, it makes it easier to review.

If you don't want to be bothered by such patches, just delegate them to me in
patchwork, I don't mind.

Regards,

Hans

> However, Mauro may 
> override by either taking this himself or asking me to apply this.
> 
> Thanks
> Guennadi
> 
>>
>> Signed-off-by: Suman Kumar 
>> ---
>>  drivers/media/platform/soc_camera/soc_camera_platform.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/media/platform/soc_camera/soc_camera_platform.c 
>> b/drivers/media/platform/soc_camera/soc_camera_platform.c
>> index ceaddfb..fe15a80 100644
>> --- a/drivers/media/platform/soc_camera/soc_camera_platform.c
>> +++ b/drivers/media/platform/soc_camera/soc_camera_platform.c
>> @@ -27,12 +27,14 @@ struct soc_camera_platform_priv {
>>  static struct soc_camera_platform_priv *get_priv(struct platform_device 
>> *pdev)
>>  {
>>  struct v4l2_subdev *subdev = platform_get_drvdata(pdev);
>> +
>>  return container_of(subdev, struct soc_camera_platform_priv, subdev);
>>  }
>>  
>>  static int soc_camera_platform_s_stream(struct v4l2_subdev *sd, int enable)
>>  {
>>  struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
>> +
>>  return p->set_capture(p, enable);
>>  }
>>  
>> -- 
>> 1.8.2
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" 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/

Re: [PATCH 3.16 00/17] 3.16.1-stable review

[Linus Torvalds]

On Sat, Aug 9, 2014 at 10:15 AM, Guenter Roeck  wrote:
>
> ERROR (phandle_references): Reference to non-existent node or label
> "disp_pd"
>
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[1]: *** [arch/arm/boot/dts/exynos5420-arndale-octa.dtb] Error 2

Ok, so it's something else that was apparently known about in -next,
but not mentioned when pushing to me. Oh well.

The new disp_dt use was added by commit 5a8da524049c ("ARM: dts:
exynos5420: add dsi node"), while commit d51cad7df871 ("ARM: dts:
remove display power domain for exynos5420") removed the node.

I'll leave it broken until the ARM people get around to fixing it.
Likely by just removing the disp_dt line from the dsi node, but I'll
let the proper people sort it out.

   Linus
--
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] staging: soc_camera: soc_camera_platform.c: Fixed a Missing blank line coding style issue

[Guennadi Liakhovetski]

Hi Suman,

On Sat, 9 Aug 2014, Suman Kumar wrote:

> Fixes a coding style issue reported by checkpatch.pl

Thanks for your patch. To my taste checkpatch.pl has unfortunately become 
too noisy with meaningless / unimportant warnings like this one. Is this 
in CodingStyle? If not, my intention is to drop this. However, Mauro may 
override by either taking this himself or asking me to apply this.

Thanks
Guennadi

> 
> Signed-off-by: Suman Kumar 
> ---
>  drivers/media/platform/soc_camera/soc_camera_platform.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/media/platform/soc_camera/soc_camera_platform.c 
> b/drivers/media/platform/soc_camera/soc_camera_platform.c
> index ceaddfb..fe15a80 100644
> --- a/drivers/media/platform/soc_camera/soc_camera_platform.c
> +++ b/drivers/media/platform/soc_camera/soc_camera_platform.c
> @@ -27,12 +27,14 @@ struct soc_camera_platform_priv {
>  static struct soc_camera_platform_priv *get_priv(struct platform_device 
> *pdev)
>  {
>   struct v4l2_subdev *subdev = platform_get_drvdata(pdev);
> +
>   return container_of(subdev, struct soc_camera_platform_priv, subdev);
>  }
>  
>  static int soc_camera_platform_s_stream(struct v4l2_subdev *sd, int enable)
>  {
>   struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
> +
>   return p->set_capture(p, enable);
>  }
>  
> -- 
> 1.8.2
> 
--
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: [PULL REQUEST] i2c for 3.17

[Linus Torvalds]

On Sat, Aug 9, 2014 at 6:56 AM, Wolfram Sang  wrote:
>
> here is the pull request for 3.17 for the I2C subsystem. Highlights:

Lowlight: selecting ACPI support (which used to be the default if ACPI
was enabled) now forces i2c to be built-in.

I've pulled this, but it's broken. You need to fix it someway.

The reason for this is

  config I2C
 tristate "I2C support"
  ...
  config I2C_ACPI
 bool "I2C ACPI support"
 select I2C
 depends on ACPI
   ...

where if I2C_APCI is on (y), then that "select I2C" will cause I2C to
be upgraded to 'y' as well.

This seems to be intentional, judging by the commit message, but it's
wrong. Distributions etc generally compile i2c as a module, and you've
now broken that.

This is a regression. Change the "select I2C" to a "depends on I2C",
and test the end result. Don't force people to build things into the
kernel.

 Linus
--
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] staging: soc_camera: soc_camera_platform.c: Fixed a Missing blank line coding style issue

[Suman Kumar]

Fixes a coding style issue reported by checkpatch.pl

Signed-off-by: Suman Kumar 
---
 drivers/media/platform/soc_camera/soc_camera_platform.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/soc_camera/soc_camera_platform.c 
b/drivers/media/platform/soc_camera/soc_camera_platform.c
index ceaddfb..fe15a80 100644
--- a/drivers/media/platform/soc_camera/soc_camera_platform.c
+++ b/drivers/media/platform/soc_camera/soc_camera_platform.c
@@ -27,12 +27,14 @@ struct soc_camera_platform_priv {
 static struct soc_camera_platform_priv *get_priv(struct platform_device *pdev)
 {
struct v4l2_subdev *subdev = platform_get_drvdata(pdev);
+
return container_of(subdev, struct soc_camera_platform_priv, subdev);
 }
 
 static int soc_camera_platform_s_stream(struct v4l2_subdev *sd, int enable)
 {
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
+
return p->set_capture(p, enable);
 }
 
-- 
1.8.2

--
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.16 00/17] 3.16.1-stable review

[Guenter Roeck]

On 08/09/2014 09:07 AM, Linus Torvalds wrote:

On Sat, Aug 9, 2014 at 8:04 AM, Guenter Roeck  wrote:


There are two arm build failures in Linus' tree which are not seen
in -next.


Ugh. Did I screw up the semantic merge wrt the devm_phy_create()
argument changes despite having an example patch from Stephen? Or is
this something else due to something that just wasn't in -next?

Can you post the build failures?



Building arm:multi_v7_defconfig ... failed
Building arm:exynos_defconfig ... failed
--
Error log (same for both builds):

ERROR (phandle_references): Reference to non-existent node or label "disp_pd"

ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [arch/arm/boot/dts/exynos5420-arndale-octa.dtb] Error 2

and:

$ git grep disp_pd
arch/arm/boot/dts/exynos5420.dtsi:  samsung,power-domain = 
<&disp_pd>;

So, yes, disp_pd is not defined.

If I understand -next correctly, it includes a fixup which removes disp_pd
from the file. From the -next build log:

Applying: ARM: dts: exynos5420: remove disp_pd

Copying Stephen for additional input.

Guenter

--
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] staging: soc_camera: soc_camera_platform.c: Fixed a Missing blank line coding style issue

[Suman Kumar]

Fixes a coding style issue reported by checkpatch.pl

Signed-off-by: Suman Kumar 
---
 drivers/media/platform/soc_camera/soc_camera_platform.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/soc_camera/soc_camera_platform.c 
b/drivers/media/platform/soc_camera/soc_camera_platform.c
index ceaddfb..fe15a80 100644
--- a/drivers/media/platform/soc_camera/soc_camera_platform.c
+++ b/drivers/media/platform/soc_camera/soc_camera_platform.c
@@ -27,12 +27,14 @@ struct soc_camera_platform_priv {
 static struct soc_camera_platform_priv *get_priv(struct platform_device *pdev)
 {
struct v4l2_subdev *subdev = platform_get_drvdata(pdev);
+
return container_of(subdev, struct soc_camera_platform_priv, subdev);
 }
 
 static int soc_camera_platform_s_stream(struct v4l2_subdev *sd, int enable)
 {
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
+
return p->set_capture(p, enable);
 }
 
-- 
1.8.2

--
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] Input: wacom - Fix compiler warning if !CONFIG_PM

[Geert Uytterhoeven]

If CONFIG_PM is not set:

drivers/hid/wacom_sys.c:1436: warning: ‘wacom_reset_resume’ defined but
not used

Protect the unused functions by #ifdef CONFIG_PM to fix this.

Signed-off-by: Geert Uytterhoeven 
---
 drivers/hid/wacom_sys.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 3e388ec31da8..f0db7eca9023 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -1416,6 +1416,7 @@ static void wacom_remove(struct hid_device *hdev)
kfree(wacom);
 }
 
+#ifdef CONFIG_PM
 static int wacom_resume(struct hid_device *hdev)
 {
struct wacom *wacom = hid_get_drvdata(hdev);
@@ -1436,6 +1437,7 @@ static int wacom_reset_resume(struct hid_device *hdev)
 {
return wacom_resume(hdev);
 }
+#endif /* CONFIG_PM */
 
 static struct hid_driver wacom_driver = {
.name = "wacom",
-- 
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/

[PATCH] mtd: nand: Use ULL-suffix for big u64 constant

[Geert Uytterhoeven]

drivers/mtd/nand/nand_timings.c:45: warning: integer constant is too large for 
‘long’ type

Signed-off-by: Geert Uytterhoeven 
---
 drivers/mtd/nand/nand_timings.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/nand_timings.c b/drivers/mtd/nand/nand_timings.c
index 8b36253420fa..e81470a8ac67 100644
--- a/drivers/mtd/nand/nand_timings.c
+++ b/drivers/mtd/nand/nand_timings.c
@@ -42,7 +42,7 @@ static const struct nand_sdr_timings onfi_sdr_timings[] = {
.tRHZ_max = 20,
.tRLOH_min = 0,
.tRP_min = 5,
-   .tRST_max = 2500,
+   .tRST_max = 2500ULL,
.tWB_max = 20,
.tRR_min = 4,
.tWC_min = 10,
-- 
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: [GIT PULL] x86/apic changes for v3.17

[Borislav Petkov]

On Fri, Aug 08, 2014 at 03:21:44PM -0700, David Rientjes wrote:
> On Thu, 7 Aug 2014, Ingo Molnar wrote:
> 
> > Linus, please pull the latest x86-apic-for-linus git tree from:
> > 
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> > x86-apic-for-linus
> > 
> ># HEAD: 5e3bf215f4f2efc0af89e6dbc5da789744aeb5d7 x86/apic/vsmp: Make 
> > is_vsmp_box() static
> > 
> > 
> > The main changes in this cycle are:
> > 
> > * Remove obsolete APIC driver abstractions. (David Rientjes)
> > 
> 
> These changes are unrelated from the other issues and can still be pulled 
> from
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rientjes/linux.git 
> x86/apic 
> 
> if we want the cleanups for 3.17.  The x86 pull request was originally at 
> http://marc.info/?l=linux-kernel&m=140678961924050.
> 
> It would be a shame to miss out on that because the changes share the same 
> tip branch.

Actually, that whole branch could go in now, especially since Thomas
picked up the stable IRQ numbers assignment during s/r fix:

https://lkml.kernel.org/r/tip-3eec595235c17a74094daa1e02d1b0af2e9a7...@git.kernel.org

@tglx: I don't know about IOAPIC reference count:

https://lkml.kernel.org/r/1407209178-18644-3-git-send-email-jiang@linux.intel.com

This looks like a bugfix too.

With those two applied, tip/x86/apic is good to go IMHO. The only thing
that remains are the IOMMU IOPFs which we'll deal accordingly later -
they need shutting up only anyway.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] vfio: Fix build failure seen if vfio is built as module and EEH is enabled

[Guenter Roeck]

The following build failure is seen with ppc:allmodconfig.

ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko] 
undefined!
ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!

Simply exporting the missing symbols is insufficient, since drivers/vfio
can be built as module but drivers/vfio/vfio_spapr_eeh.c depends on
EEH which is boolean. The combination of obj-m for drivers/vfio and obj-y
for drivers/vfio/vfio_spapr_eeh.o results in the symbols being missed even
if exported.

Export missing symbols and introduce new tristate configuration option
VFIO_EEH depending on both EEH and VFIO to fix the problem.

Cc: Gavin Shan 
Cc: Benjamin Herrenschmidt 
Signed-off-by: Guenter Roeck 
---
 drivers/vfio/Kconfig  | 6 ++
 drivers/vfio/Makefile | 2 +-
 drivers/vfio/vfio_spapr_eeh.c | 4 
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index af7b204..06adecd 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -8,12 +8,18 @@ config VFIO_IOMMU_SPAPR_TCE
depends on VFIO && SPAPR_TCE_IOMMU
default n
 
+config VFIO_EEH
+   tristate
+   depends on VFIO && EEH
+   default n
+
 menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
select VFIO_IOMMU_TYPE1 if X86
select VFIO_IOMMU_SPAPR_TCE if (PPC_POWERNV || PPC_PSERIES)
select ANON_INODES
+   select VFIO_EEH if EEH
help
  VFIO provides a framework for secure userspace device drivers.
  See Documentation/vfio.txt for more details.
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 50e30bc..26016cd 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_VFIO) += vfio.o
 obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
 obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
-obj-$(CONFIG_EEH) += vfio_spapr_eeh.o
+obj-$(CONFIG_VFIO_EEH) += vfio_spapr_eeh.o
 obj-$(CONFIG_VFIO_PCI) += pci/
diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
index f834b4c..e827309 100644
--- a/drivers/vfio/vfio_spapr_eeh.c
+++ b/drivers/vfio/vfio_spapr_eeh.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -18,11 +19,13 @@ int vfio_spapr_pci_eeh_open(struct pci_dev *pdev)
 {
return eeh_dev_open(pdev);
 }
+EXPORT_SYMBOL_GPL(vfio_spapr_pci_eeh_open);
 
 void vfio_spapr_pci_eeh_release(struct pci_dev *pdev)
 {
eeh_dev_release(pdev);
 }
+EXPORT_SYMBOL(vfio_spapr_pci_eeh_release);
 
 long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
unsigned int cmd, unsigned long arg)
@@ -85,3 +88,4 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
 
return ret;
 }
+EXPORT_SYMBOL(vfio_spapr_iommu_eeh_ioctl);
-- 
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/

[PATCH] clk: st: remove null pointer dereference

[Himangi Saraogi]

If clk_data is NULL, it is not possible to access its clk_num field. So
if the NULL test succeeds the control sequence mush jump after the loop.
So, a new label is introduced and the labels are renamed to err0 and
err1. If clk_data is NULL, only parents need to be freed and hence the
goto now points to err0.

This problem was found using the following Coccinelle semantic match:

// 
@@
expression E, E1;
identifier f;
statement S1,S2,S3;
@@

* if (E == NULL)
{
  ... when != if (E == NULL) S1 else S2
  when != E = E1
* E->f
  ... when any
  return ...;
}
else S3
// 

Signed-off-by: Himangi Saraogi 
Acked-by: Julia Lawall 
---
Not compile tested.
 drivers/clk/st/clkgen-mux.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/st/clkgen-mux.c b/drivers/clk/st/clkgen-mux.c
index 79dc40b..385b3d0 100644
--- a/drivers/clk/st/clkgen-mux.c
+++ b/drivers/clk/st/clkgen-mux.c
@@ -723,14 +723,14 @@ void __init st_of_clkgen_vcc_setup(struct device_node *np)
 
clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
if (!clk_data)
-   goto err;
+   goto err0;
 
clk_data->clk_num = VCC_MAX_CHANNELS;
clk_data->clks = kzalloc(clk_data->clk_num * sizeof(struct clk *),
 GFP_KERNEL);
 
if (!clk_data->clks)
-   goto err;
+   goto err1;
 
for (i = 0; i < clk_data->clk_num; i++) {
struct clk *clk;
@@ -791,7 +791,7 @@ void __init st_of_clkgen_vcc_setup(struct device_node *np)
kfree(gate);
kfree(div);
kfree(mux);
-   goto err;
+   goto err1;
}
 
pr_debug("%s: parent %s rate %u\n",
@@ -807,7 +807,7 @@ void __init st_of_clkgen_vcc_setup(struct device_node *np)
of_clk_add_provider(np, of_clk_src_onecell_get, clk_data);
return;
 
-err:
+err1:
for (i = 0; i < clk_data->clk_num; i++) {
struct clk_composite *composite;
 
@@ -821,10 +821,11 @@ err:
kfree(container_of(composite->mux_hw, struct clk_mux, hw));
}
 
-   if (clk_data)
-   kfree(clk_data->clks);
+   kfree(clk_data->clks);
 
kfree(clk_data);
+
+err0:
kfree(parents);
 }
 CLK_OF_DECLARE(clkgen_vcc, "st,clkgen-vcc", st_of_clkgen_vcc_setup);
-- 
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 3.13 061/259] thermal: hwmon: Make the check for critical temp valid consistent

[edubez...@gmail.com]

Hello,

On Fri, Aug 8, 2014 at 4:38 PM, Kamal Mostafa  wrote:
> 3.13.11.6 -stable review patch.  If anyone has any objections, please let me 
> know.
>
> --
>
> From: Aaron Lu 
>
> commit e8db5d6736a712a3e2280c0e31f4b301d85172d8 upstream.
>
> On 05/21/2014 04:22 PM, Aaron Lu wrote:
>> On 05/21/2014 01:57 PM, Kui Zhang wrote:
>>> Hello,
>>>
>>> I get following error when rmmod thermal.
>>>
>>> rmmod  thermal
>>> Killed
>
> While dealing with this problem, I found another problem that also
> results in a kernel crash on thermal module removal:
>
> From: Aaron Lu 
> Date: Wed, 21 May 2014 16:05:38 +0800
> Subject: [PATCH] thermal: hwmon: Make the check for critical temp valid 
> consistent
>
> We used the tz->ops->get_crit_temp && !tz->ops->get_crit_temp(tz, temp)
> to decide if we need to create the temp_crit attribute file but we just
> check if tz->ops->get_crit_temp exists to decide if we need to remove
> that attribute file. Some ACPI thermal zone doesn't have a valid critical
> trip point and that would result in removing a non-existent device file
> on thermal module unload.
>
> Signed-off-by: Aaron Lu 
> Signed-off-by: Zhang Rui 
> Signed-off-by: Kamal Mostafa 

Acked-by: Eduardo Valentin 

> ---
>  drivers/thermal/thermal_hwmon.c | 33 ++---
>  1 file changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
> index fdb0719..1967bee 100644
> --- a/drivers/thermal/thermal_hwmon.c
> +++ b/drivers/thermal/thermal_hwmon.c
> @@ -140,6 +140,12 @@ thermal_hwmon_lookup_temp(const struct 
> thermal_hwmon_device *hwmon,
> return NULL;
>  }
>
> +static bool thermal_zone_crit_temp_valid(struct thermal_zone_device *tz)
> +{
> +   unsigned long temp;
> +   return tz->ops->get_crit_temp && !tz->ops->get_crit_temp(tz, &temp);
> +}
> +
>  int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
>  {
> struct thermal_hwmon_device *hwmon;
> @@ -189,21 +195,18 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device 
> *tz)
> if (result)
> goto free_temp_mem;
>
> -   if (tz->ops->get_crit_temp) {
> -   unsigned long temperature;
> -   if (!tz->ops->get_crit_temp(tz, &temperature)) {
> -   snprintf(temp->temp_crit.name,
> -sizeof(temp->temp_crit.name),
> +   if (thermal_zone_crit_temp_valid(tz)) {
> +   snprintf(temp->temp_crit.name,
> +   sizeof(temp->temp_crit.name),
> "temp%d_crit", hwmon->count);
> -   temp->temp_crit.attr.attr.name = temp->temp_crit.name;
> -   temp->temp_crit.attr.attr.mode = 0444;
> -   temp->temp_crit.attr.show = temp_crit_show;
> -   sysfs_attr_init(&temp->temp_crit.attr.attr);
> -   result = device_create_file(hwmon->device,
> -   &temp->temp_crit.attr);
> -   if (result)
> -   goto unregister_input;
> -   }
> +   temp->temp_crit.attr.attr.name = temp->temp_crit.name;
> +   temp->temp_crit.attr.attr.mode = 0444;
> +   temp->temp_crit.attr.show = temp_crit_show;
> +   sysfs_attr_init(&temp->temp_crit.attr.attr);
> +   result = device_create_file(hwmon->device,
> +   &temp->temp_crit.attr);
> +   if (result)
> +   goto unregister_input;
> }
>
> mutex_lock(&thermal_hwmon_list_lock);
> @@ -250,7 +253,7 @@ void thermal_remove_hwmon_sysfs(struct 
> thermal_zone_device *tz)
> }
>
> device_remove_file(hwmon->device, &temp->temp_input.attr);
> -   if (tz->ops->get_crit_temp)
> +   if (thermal_zone_crit_temp_valid(tz))
> device_remove_file(hwmon->device, &temp->temp_crit.attr);
>
> mutex_lock(&thermal_hwmon_list_lock);
> --
> 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/



-- 
Eduardo Bezerra Valentin
--
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] drivers: fixed spelling of "celcius" to "celsius"

[edubez...@gmail.com]

Hello Ankit,

On Sat, Aug 9, 2014 at 4:02 AM, Ankit  wrote:
> Fixed spelling issue -- changed celcius to celsius
>
> Kernel version: mainline
>
> Signed-off-by: Ankit 

On the thermal part,

Acked-by: Eduardo Valentin 

but I think might be worth splitting the change per domain, so we
avoid merge conflicts. The change is just one liner though.

> ---
>  drivers/gpu/drm/nouveau/core/engine/graph/nv10.c  | 4 ++--
>  drivers/gpu/drm/nouveau/core/engine/graph/nv20.c  | 2 +-
>  drivers/gpu/drm/nouveau/core/engine/graph/nv25.c  | 2 +-
>  drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 2 +-
>  drivers/power/ds2780_battery.c| 2 +-
>  drivers/power/ds2782_battery.c| 2 +-
>  drivers/thermal/thermal_core.c| 2 +-
>  7 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv10.c 
> b/drivers/gpu/drm/nouveau/core/engine/graph/nv10.c
> index 4532f7e..1faeeb1 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nv10.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nv10.c
> @@ -451,7 +451,7 @@ nv10_graph_sclass[] = {
> { 0x0093, &nv04_graph_ofuncs }, /* surf3d */
> { 0x0094, &nv04_graph_ofuncs }, /* ttri */
> { 0x0095, &nv04_graph_ofuncs }, /* mtri */
> -   { 0x0056, &nv04_graph_ofuncs }, /* celcius */
> +   { 0x0056, &nv04_graph_ofuncs }, /* celsius */
> {},
>  };
>
> @@ -474,7 +474,7 @@ nv15_graph_sclass[] = {
> { 0x0093, &nv04_graph_ofuncs }, /* surf3d */
> { 0x0094, &nv04_graph_ofuncs }, /* ttri */
> { 0x0095, &nv04_graph_ofuncs }, /* mtri */
> -   { 0x0096, &nv04_graph_ofuncs }, /* celcius */
> +   { 0x0096, &nv04_graph_ofuncs }, /* celsius */
> {},
>  };
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c 
> b/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c
> index d145e08..eb00689 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c
> @@ -31,7 +31,7 @@ nv20_graph_sclass[] = {
> { 0x0072, &nv04_graph_ofuncs, NULL }, /* beta4 */
> { 0x0089, &nv04_graph_ofuncs, NULL }, /* sifm */
> { 0x008a, &nv04_graph_ofuncs, NULL }, /* ifc */
> -   { 0x0096, &nv04_graph_ofuncs, NULL }, /* celcius */
> +   { 0x0096, &nv04_graph_ofuncs, NULL }, /* celsius */
> { 0x0097, &nv04_graph_ofuncs, NULL }, /* kelvin */
> { 0x009e, &nv04_graph_ofuncs, NULL }, /* swzsurf */
> { 0x009f, &nv04_graph_ofuncs, NULL }, /* imageblit */
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv25.c 
> b/drivers/gpu/drm/nouveau/core/engine/graph/nv25.c
> index 7a80d00..fcfe1c5 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nv25.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nv25.c
> @@ -28,7 +28,7 @@ nv25_graph_sclass[] = {
> { 0x0072, &nv04_graph_ofuncs, NULL }, /* beta4 */
> { 0x0089, &nv04_graph_ofuncs, NULL }, /* sifm */
> { 0x008a, &nv04_graph_ofuncs, NULL }, /* ifc */
> -   { 0x0096, &nv04_graph_ofuncs, NULL }, /* celcius */
> +   { 0x0096, &nv04_graph_ofuncs, NULL }, /* celsius */
> { 0x009e, &nv04_graph_ofuncs, NULL }, /* swzsurf */
> { 0x009f, &nv04_graph_ofuncs, NULL }, /* imageblit */
> { 0x0597, &nv04_graph_ofuncs, NULL }, /* kelvin */
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c 
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
> index f5786d5..b0f7ab0 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
> @@ -1264,7 +1264,7 @@ static ssize_t qlcnic_hwmon_show_temp(struct device 
> *dev,
> value = QLC_SHARED_REG_RD32(adapter, QLCNIC_ASIC_TEMP);
>
> temperature = qlcnic_get_temp_val(value);
> -   /* display millidegree celcius */
> +   /* display millidegree celsius */
> temperature *= 1000;
> return sprintf(buf, "%u\n", temperature);
>  }
> diff --git a/drivers/power/ds2780_battery.c b/drivers/power/ds2780_battery.c
> index 9f418fa..bf7d4bd 100644
> --- a/drivers/power/ds2780_battery.c
> +++ b/drivers/power/ds2780_battery.c
> @@ -210,7 +210,7 @@ static int ds2780_get_temperature(struct 
> ds2780_device_info *dev_info,
> return ret;
>
> /*
> -* Temperature is measured in units of 0.125 degrees celcius, the
> +* Temperature is measured in units of 0.125 degrees celsius, the
>  * power_supply class measures temperature in tenths of degrees
>  * celsius. The temperature value is stored as a 10 bit number, plus
>  * sign in the upper bits of a 16 bit register.
> diff --git a/drivers/power/ds2782_battery.c b/drivers/power/ds2782_battery.c
> index 041f9b6..adc7d32 100644
> --- a/drivers/power/ds2782_battery.c
> +++ b/drivers/power/ds2782_battery.c
> @@ -104,7 +104,7 @@ static int ds278x_get_temp(struct ds278x_info *info, int 
> *temp)
>   

[PATCH] staging: soc_camera: soc_camera_platform.c: Fixed a Missing blank line coding style issue

[Suman Kumar]

Fixes a coding style issue reported by checkpatch.pl

Signed-off-by: Suman Kumar 
---
 drivers/media/platform/soc_camera/soc_camera_platform.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/platform/soc_camera/soc_camera_platform.c 
b/drivers/media/platform/soc_camera/soc_camera_platform.c
index ceaddfb..fe15a80 100644
--- a/drivers/media/platform/soc_camera/soc_camera_platform.c
+++ b/drivers/media/platform/soc_camera/soc_camera_platform.c
@@ -27,12 +27,14 @@ struct soc_camera_platform_priv {
 static struct soc_camera_platform_priv *get_priv(struct platform_device *pdev)
 {
struct v4l2_subdev *subdev = platform_get_drvdata(pdev);
+
return container_of(subdev, struct soc_camera_platform_priv, subdev);
 }
 
 static int soc_camera_platform_s_stream(struct v4l2_subdev *sd, int enable)
 {
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
+
return p->set_capture(p, enable);
 }
 
-- 
1.8.2

--
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] hdlc: Remove typedefs from struct names

[Himangi Saraogi]

The Linux kernel coding style guidelines suggest not using typedefs
for structure types. This patch gets rid of the typedefs for
fr_hdr and pvc_device. Also, the names of the structs are changed to
drop the _t, to make the name look less typedef-like.

The following Coccinelle semantic patch detects the case fr_hdr and a
similar one detects the case for pvc_device.

@tn1@
type td;
@@

typedef struct { ... } td;

@script:python tf@
td << tn1.td;
tdres;
@@

coccinelle.tdres = td;

@@
type tn1.td;
identifier tf.tdres;
@@

-typedef
 struct
+  tdres
   { ... }
-td
 ;

@@
type tn1.td;
identifier tf.tdres;
@@

-td
+ struct tdres

Signed-off-by: Himangi Saraogi 
Acked-by: Julia Lawall 
---
To send to: Krzysztof Halasa 
,net...@vger.kernel.org,linux-kernel@vger.kernel.org
 drivers/net/wan/hdlc_fr.c | 63 ---
 1 file changed, 32 insertions(+), 31 deletions(-)

diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index 7cc64ea..e5c7e61 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net/wan/hdlc_fr.c
@@ -90,7 +90,7 @@
 #define LMI_ANSI_LENGTH  14
 
 
-typedef struct {
+struct fr_hdr {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
unsigned ea1:   1;
unsigned cr:1;
@@ -112,14 +112,14 @@ typedef struct {
unsigned de:1;
unsigned ea2:   1;
 #endif
-}__packed fr_hdr;
+} __packed;
 
 
-typedef struct pvc_device_struct {
+struct pvc_device {
struct net_device *frad;
struct net_device *main;
struct net_device *ether;   /* bridged Ethernet interface   */
-   struct pvc_device_struct *next; /* Sorted in ascending DLCI order */
+   struct pvc_device *next;/* Sorted in ascending DLCI order */
int dlci;
int open_count;
 
@@ -132,11 +132,11 @@ typedef struct pvc_device_struct {
unsigned int becn: 1;
unsigned int bandwidth; /* Cisco LMI reporting only */
}state;
-}pvc_device;
+};
 
 struct frad_state {
fr_proto settings;
-   pvc_device *first_pvc;
+   struct pvc_device *first_pvc;
int dce_pvc_count;
 
struct timer_list timer;
@@ -174,9 +174,9 @@ static inline struct frad_state* state(hdlc_device *hdlc)
 }
 
 
-static inline pvc_device* find_pvc(hdlc_device *hdlc, u16 dlci)
+static inline struct pvc_device *find_pvc(hdlc_device *hdlc, u16 dlci)
 {
-   pvc_device *pvc = state(hdlc)->first_pvc;
+   struct pvc_device *pvc = state(hdlc)->first_pvc;
 
while (pvc) {
if (pvc->dlci == dlci)
@@ -190,10 +190,10 @@ static inline pvc_device* find_pvc(hdlc_device *hdlc, u16 
dlci)
 }
 
 
-static pvc_device* add_pvc(struct net_device *dev, u16 dlci)
+static struct pvc_device *add_pvc(struct net_device *dev, u16 dlci)
 {
hdlc_device *hdlc = dev_to_hdlc(dev);
-   pvc_device *pvc, **pvc_p = &state(hdlc)->first_pvc;
+   struct pvc_device *pvc, **pvc_p = &state(hdlc)->first_pvc;
 
while (*pvc_p) {
if ((*pvc_p)->dlci == dlci)
@@ -203,7 +203,7 @@ static pvc_device* add_pvc(struct net_device *dev, u16 dlci)
pvc_p = &(*pvc_p)->next;
}
 
-   pvc = kzalloc(sizeof(pvc_device), GFP_ATOMIC);
+   pvc = kzalloc(sizeof(*pvc), GFP_ATOMIC);
 #ifdef DEBUG_PVC
printk(KERN_DEBUG "add_pvc: allocated pvc %p, frad %p\n", pvc, dev);
 #endif
@@ -218,13 +218,13 @@ static pvc_device* add_pvc(struct net_device *dev, u16 
dlci)
 }
 
 
-static inline int pvc_is_used(pvc_device *pvc)
+static inline int pvc_is_used(struct pvc_device *pvc)
 {
return pvc->main || pvc->ether;
 }
 
 
-static inline void pvc_carrier(int on, pvc_device *pvc)
+static inline void pvc_carrier(int on, struct pvc_device *pvc)
 {
if (on) {
if (pvc->main)
@@ -246,11 +246,11 @@ static inline void pvc_carrier(int on, pvc_device *pvc)
 
 static inline void delete_unused_pvcs(hdlc_device *hdlc)
 {
-   pvc_device **pvc_p = &state(hdlc)->first_pvc;
+   struct pvc_device **pvc_p = &state(hdlc)->first_pvc;
 
while (*pvc_p) {
if (!pvc_is_used(*pvc_p)) {
-   pvc_device *pvc = *pvc_p;
+   struct pvc_device *pvc = *pvc_p;
 #ifdef DEBUG_PVC
printk(KERN_DEBUG "freeing unused pvc: %p\n", pvc);
 #endif
@@ -263,7 +263,8 @@ static inline void delete_unused_pvcs(hdlc_device *hdlc)
 }
 
 
-static inline struct net_device** get_dev_p(pvc_device *pvc, int type)
+static inline struct net_device **get_dev_p(struct pvc_device *pvc,
+   int type)
 {
if (type == ARPHRD_ETHER)
return &pvc->ether;
@@ -342,7 +343,7 @@ static int fr_hard_header(struct sk_buff **skb_p, u16 dlci)
 
 static int pvc_open(struct net_device *dev)
 {
-   pvc_device *pvc = dev->ml_priv;
+   struct pvc_device *pvc = dev->ml_priv;
 
if ((pvc->frad->flags & IFF_UP) == 0)
return -EIO;  /* Frad must be

[PATCH] airo_cs: Remove typedef local_info_t

[Himangi Saraogi]

The Linux kernel coding style guidelines suggest not using typedefs
for structure types. This patch gets rid of the typedef for
local_info_t. Also, the name of the struct is changed to drop the _t,
to make the name look less typedef-like.

The following Coccinelle semantic patch detects the case:

@tn@
identifier i;
type td;
@@

-typedef
 struct i { ... }
-td
 ;

@@
type tn.td;
identifier tn.i;
@@

-td
+ struct i

Signed-off-by: Himangi Saraogi 
Acked-by: Julia Lawall 
---
 drivers/net/wireless/airo_cs.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/airo_cs.c b/drivers/net/wireless/airo_cs.c
index 7e9ede6..d9ed22b 100644
--- a/drivers/net/wireless/airo_cs.c
+++ b/drivers/net/wireless/airo_cs.c
@@ -56,18 +56,18 @@ static void airo_release(struct pcmcia_device *link);
 
 static void airo_detach(struct pcmcia_device *p_dev);
 
-typedef struct local_info_t {
+struct local_info {
struct net_device *eth_dev;
-} local_info_t;
+};
 
 static int airo_probe(struct pcmcia_device *p_dev)
 {
-   local_info_t *local;
+   struct local_info *local;
 
dev_dbg(&p_dev->dev, "airo_attach()\n");
 
/* Allocate space for private device-specific data */
-   local = kzalloc(sizeof(local_info_t), GFP_KERNEL);
+   local = kzalloc(sizeof(*local), GFP_KERNEL);
if (!local)
return -ENOMEM;
 
@@ -82,10 +82,11 @@ static void airo_detach(struct pcmcia_device *link)
 
airo_release(link);
 
-   if (((local_info_t *)link->priv)->eth_dev) {
-   stop_airo_card(((local_info_t *)link->priv)->eth_dev, 0);
+   if (((struct local_info *)link->priv)->eth_dev) {
+   stop_airo_card(((struct local_info *)link->priv)->eth_dev,
+  0);
}
-   ((local_info_t *)link->priv)->eth_dev = NULL;
+   ((struct local_info *)link->priv)->eth_dev = NULL;
 
kfree(link->priv);
 } /* airo_detach */
@@ -101,7 +102,7 @@ static int airo_cs_config_check(struct pcmcia_device 
*p_dev, void *priv_data)
 
 static int airo_config(struct pcmcia_device *link)
 {
-   local_info_t *dev;
+   struct local_info *dev;
int ret;
 
dev = link->priv;
@@ -121,10 +122,10 @@ static int airo_config(struct pcmcia_device *link)
ret = pcmcia_enable_device(link);
if (ret)
goto failed;
-   ((local_info_t *)link->priv)->eth_dev =
+   ((struct local_info *)link->priv)->eth_dev =
init_airo_card(link->irq,
   link->resource[0]->start, 1, &link->dev);
-   if (!((local_info_t *)link->priv)->eth_dev)
+   if (!((struct local_info *)link->priv)->eth_dev)
goto failed;
 
return 0;
@@ -142,7 +143,7 @@ static void airo_release(struct pcmcia_device *link)
 
 static int airo_suspend(struct pcmcia_device *link)
 {
-   local_info_t *local = link->priv;
+   struct local_info *local = link->priv;
 
netif_device_detach(local->eth_dev);
 
@@ -151,7 +152,7 @@ static int airo_suspend(struct pcmcia_device *link)
 
 static int airo_resume(struct pcmcia_device *link)
 {
-   local_info_t *local = link->priv;
+   struct local_info *local = link->priv;
 
if (link->open) {
reset_airo_card(local->eth_dev);
-- 
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: Loading initrd above 4G causes freeze on boot

[Yinghai Lu]

On Sat, Aug 9, 2014 at 7:23 AM, Mantas Mikulėnas  wrote:
> As of commit 4bf7111f5016 ("x86/efi: Support initrd loaded above 4G"),
> the kernel freezes at the earliest possible moment when trying to boot
> via UEFI on my Asus laptop. (It still boots via BIOS.)
>
> If I revert that commit on current master (c309bfa9b481), it boots
> correctly again [although I see "setup_efi_pci() failed" being printed].
>
> (Seems like it freezes when handle_cmdline_files() attempts to read
> the last chunk of the initramfs -- the last call to efi_file_read()
> never returns. Figuring out why that happens is beyond me, though.)
>

Matt found that efi_file_read()/firmware has problem that could not do
several reading. Please check if reverting that commit have any
difference.

---
I spent some time playing around with this bug and it appears to be
triggered by the read-a-chunk-at-a-time logic in handle_cmdline_files(),
(which is itself a bug workaround) introduced here,

  commit 2d2da60fb40a
  Author: Maarten Lankhorst 
  Date:   Fri Dec 16 13:30:58 2011 +0100

  x86, efi: Break up large initrd reads
---
--
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/4] driver core: enable drivers to use deferred probe from init

[Luis R. Rodriguez]

On Wed, Jul 30, 2014 at 03:11:07PM -0700, David Miller wrote:
> From: "Luis R. Rodriguez" 
> Date: Mon, 28 Jul 2014 11:28:28 -0700
> 
> > Tetsuo bisected and found that commit 786235ee "kthread: make
> > kthread_create() killable" modified kthread_create() to bail as
> > soon as SIGKILL is received. This is causing some issues with
> > some drivers and at times boot. Joseph then found that failures
> > occur as the systemd-udevd process sends SIGKILL to modprobe if
> > probe on a driver takes over 30 seconds. When this happens probe
> > will fail on any driver, its why booting on some system will fail
> > if the driver happens to be a storage related driver. Some folks
> > have suggested fixing this by modifying kthread_create() to not
> > leave upon SIGKILL [3], upon review Oleg rejected this change and
> > the discussion was punted out to systemd to see if the default
> > timeout could be increased from 30 seconds to 120. The opinion of
> > the systemd maintainers is that the driver's behavior should
> > be fixed [4]. Linus seems to agree [5], however more recently even
> > networking drivers have been reported to fail on probe since just
> > writing the firmware to a device and kicking it can take easy over
> > 60 seconds [6]. Benjamim was able to trace the issues recently
> > reported on cxgb4 down to the same systemd-udevd 30 second timeout [6].
> > 
> > This is an alternative solution which enables drivers that are
> > known to take long to use deferred probe workqueue. This avoids
> > the 30 second timeout and lets us annotate drivers with long
> > init sequences.
> > 
> > As drivers determine a component is not yet available and needs
> > to defer probe you'll be notified this happen upon init for each
> > device but now with a message such as:
> > 
> > pci :03:00.0: Driver cxgb4 requests probe deferral on init
> > 
> > You should see one of these per struct device probed.
> 
> It seems we're still discussing this.
> 
> I think I understand all of the underlying issues, and what I'll say
> is that perhaps we should use what Greg KH requested but via a helper
> that is easy to grep for.
> 
> I don't care if it's something like "module_long_probe_init()" and
> "module_long_probe_exit()", but it just needs to be some properly
> named interface which does the whole kthread or whatever bit.

I've tested the alternative kthread_run() proposal but unfortunately it
does not help resolve the issue, the timeout is still hit and a SIGKILL
still kills the driver probe. Please let me know how you'd all like us
to proceed, these defer probe patches do help cure the issue though.

I should also note that these work around patches can only be done once we
already know a driver fails to go over the timeout, root causing and
associating driver issues to the timeout has been very difficult with a few
drivers already, for this reason I've submitted a change for systemd to issue a
warning instead of killing kmod usage on udev after a timeout, that would make
this regression non-fatal, and let us more easily then hunt drivers that need
fixing much easily [0] [1]. As noted we'd still want to have drivers easily
annotated which require fixing, this orignal series would allow us to do that
by hunting for delay_probe. If there alternative and preferred strategies
please let me know.

[0] http://lists.freedesktop.org/archives/systemd-devel/2014-August/021812.html
[1] http://lists.freedesktop.org/archives/systemd-devel/2014-August/021821.html

  Luis
--
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] mfd: menelaus: remove null pointer dereference

[Himangi Saraogi]

If vtg is NULL, it is not possible to access its mode_reg field. At all
sites where the static function menelaus_set_voltage is called, the first
argument is the address of a structure defined in the file. So, the null
test is unnecessary and is removed. Also, a label is done away with.

This problem was found using the following Coccinelle semantic match:

// 
@@
expression E, E1;
identifier f;
statement S1,S2,S3;
@@

* if (E == NULL)
{
  ... when != if (E == NULL) S1 else S2
  when != E = E1
* E->f
  ... when any
  return ...;
}
else S3
// 

Signed-off-by: Himangi Saraogi 
Acked-by: Julia Lawall 
---
Not compile tested.
 drivers/mfd/menelaus.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 5e2667a..18ff56f 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -466,8 +466,6 @@ static int menelaus_set_voltage(const struct menelaus_vtg 
*vtg, int mV,
struct i2c_client *c = the_menelaus->client;
 
mutex_lock(&the_menelaus->lock);
-   if (!vtg)
-   goto set_voltage;
 
ret = menelaus_read_reg(vtg->vtg_reg);
if (ret < 0)
@@ -482,7 +480,6 @@ static int menelaus_set_voltage(const struct menelaus_vtg 
*vtg, int mV,
ret = menelaus_write_reg(vtg->vtg_reg, val);
if (ret < 0)
goto out;
-set_voltage:
ret = menelaus_write_reg(vtg->mode_reg, mode);
 out:
mutex_unlock(&the_menelaus->lock);
-- 
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/

[PATCH] atmel: Remove typedef atmel_priv_ioctl

[Himangi Saraogi]

The Linux kernel coding style guidelines suggest not using typedefs
for structure types. This patch gets rid of the typedef for
atmel_priv_ioctl. 

The following Coccinelle semantic patch detects the case:

@tn@
identifier i;
type td;
@@

-typedef
 struct i { ... }
-td
 ;

@@
type tn.td;
identifier tn.i;
@@

-td
+ struct i

Signed-off-by: Himangi Saraogi 
Acked-by: Julia Lawall 
---
 drivers/net/wireless/atmel.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c
index 1fe41af..9183f1c 100644
--- a/drivers/net/wireless/atmel.c
+++ b/drivers/net/wireless/atmel.c
@@ -2598,11 +2598,11 @@ static const iw_handler atmel_private_handler[] =
NULL,   /* SIOCIWFIRSTPRIV */
 };
 
-typedef struct atmel_priv_ioctl {
+struct atmel_priv_ioctl {
char id[32];
unsigned char __user *data;
unsigned short len;
-} atmel_priv_ioctl;
+};
 
 #define ATMELFWL   SIOCIWFIRSTPRIV
 #define ATMELIDIFC ATMELFWL + 1
@@ -2615,7 +2615,7 @@ static const struct iw_priv_args atmel_private_args[] = {
.cmd = ATMELFWL,
.set_args = IW_PRIV_TYPE_BYTE
| IW_PRIV_SIZE_FIXED
-   | sizeof (atmel_priv_ioctl),
+   | sizeof(struct atmel_priv_ioctl),
.get_args = IW_PRIV_TYPE_NONE,
.name = "atmelfwl"
}, {
@@ -2645,7 +2645,7 @@ static int atmel_ioctl(struct net_device *dev, struct 
ifreq *rq, int cmd)
 {
int i, rc = 0;
struct atmel_private *priv = netdev_priv(dev);
-   atmel_priv_ioctl com;
+   struct atmel_priv_ioctl com;
struct iwreq *wrq = (struct iwreq *) rq;
unsigned char *new_firmware;
char domain[REGDOMAINSZ + 1];
-- 
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 v3 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()

[Paul E. McKenney]

On Sat, Aug 09, 2014 at 08:44:39AM -0400, Steven Rostedt wrote:
> On Sat, 9 Aug 2014 08:15:14 +0200
> Peter Zijlstra  wrote:
> 
> 
> > As for idle tasks, I'm not sure about those, I think that we should say
> > NO to anything that would require waking idle CPUs, push the pain to
> > ftrace/kprobes, we should _not_ be waking idle cpus.
> 
> I agree, but I haven't had a chance to review the patch set (will
> probably do that on Monday, just got back from vacation last week and
> was inundated by other things).

Let me get v5 out first.  I expect to have it out by end of Monday.

> Does the idle waking happen only when
> there's something queued in the call_rcu_tasks()? It should definitely
> not be waking all the time. That's just wrong.
> 
> But if it only wakes when something is queued, it wouldn't be burdening
> anything, unless it is needed.

Indeed, idle waking only happens when there is an RCU-tasks grace period
in progress.  No RCU-tasks grace period, no RCU-tasks idle waking.

Thanx, Paul

--
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] com20020_cs: Remove typedef com20020_dev_t

[Himangi Saraogi]

The Linux kernel coding style guidelines suggest not using typedefs
for structure types. This patch gets rid of the typedef for
com20020_dev_t. Also, the name of the struct is changed to drop the
_t, to make the name look less typedef-like.

The following Coccinelle semantic patch detects the case:

@tn@
identifier i;
type td;
@@

-typedef
 struct i { ... }
-td
 ;

@@
type tn.td;
identifier tn.i;
@@

-td
+ struct i

Signed-off-by: Himangi Saraogi 
Acked-by: Julia Lawall 
---
To send to: net...@vger.kernel.org,linux-kernel@vger.kernel.org 
 drivers/net/arcnet/com20020_cs.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/arcnet/com20020_cs.c b/drivers/net/arcnet/com20020_cs.c
index 326a612..1a790a2 100644
--- a/drivers/net/arcnet/com20020_cs.c
+++ b/drivers/net/arcnet/com20020_cs.c
@@ -112,20 +112,20 @@ static void com20020_detach(struct pcmcia_device *p_dev);
 
 /**/
 
-typedef struct com20020_dev_t {
+struct com20020_dev {
 struct net_device   *dev;
-} com20020_dev_t;
+};
 
 static int com20020_probe(struct pcmcia_device *p_dev)
 {
-com20020_dev_t *info;
+struct com20020_dev *info;
 struct net_device *dev;
 struct arcnet_local *lp;
 
 dev_dbg(&p_dev->dev, "com20020_attach()\n");
 
 /* Create new network device */
-info = kzalloc(sizeof(struct com20020_dev_t), GFP_KERNEL);
+info = kzalloc(sizeof(*info), GFP_KERNEL);
 if (!info)
goto fail_alloc_info;
 
@@ -160,7 +160,7 @@ fail_alloc_info:
 
 static void com20020_detach(struct pcmcia_device *link)
 {
-struct com20020_dev_t *info = link->priv;
+struct com20020_dev *info = link->priv;
 struct net_device *dev = info->dev;
 
 dev_dbg(&link->dev, "detach...\n");
@@ -199,7 +199,7 @@ static void com20020_detach(struct pcmcia_device *link)
 static int com20020_config(struct pcmcia_device *link)
 {
 struct arcnet_local *lp;
-com20020_dev_t *info;
+struct com20020_dev *info;
 struct net_device *dev;
 int i, ret;
 int ioaddr;
@@ -291,7 +291,7 @@ static void com20020_release(struct pcmcia_device *link)
 
 static int com20020_suspend(struct pcmcia_device *link)
 {
-   com20020_dev_t *info = link->priv;
+   struct com20020_dev *info = link->priv;
struct net_device *dev = info->dev;
 
if (link->open)
@@ -302,7 +302,7 @@ static int com20020_suspend(struct pcmcia_device *link)
 
 static int com20020_resume(struct pcmcia_device *link)
 {
-   com20020_dev_t *info = link->priv;
+   struct com20020_dev *info = link->priv;
struct net_device *dev = info->dev;
 
if (link->open) {
-- 
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 3.16 00/17] 3.16.1-stable review

[Linus Torvalds]

On Sat, Aug 9, 2014 at 8:04 AM, Guenter Roeck  wrote:
>
> There are two arm build failures in Linus' tree which are not seen
> in -next.

Ugh. Did I screw up the semantic merge wrt the devm_phy_create()
argument changes despite having an example patch from Stephen? Or is
this something else due to something that just wasn't in -next?

Can you post the build failures?

  Linus
--
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 tip/core/rcu 1/9] rcu: Add call_rcu_tasks()

[Paul E. McKenney]

On Sat, Aug 09, 2014 at 08:15:14AM +0200, Peter Zijlstra wrote:
> On Fri, Aug 08, 2014 at 01:58:26PM -0700, Paul E. McKenney wrote:
> > On Fri, Aug 08, 2014 at 09:13:26PM +0200, Peter Zijlstra wrote:
> > > 
> > > 
> > > So I think you can make the entire thing work with
> > > rcu_note_context_switch().
> > > 
> > > If we have the sync thing do something like:
> > > 
> > > 
> > >   for_each_task(t) {
> > >   atomic_inc(&rcu_tasks);
> > >   atomic_or(&t->rcu_attention, RCU_TASK);
> > >   smp_mb__after_atomic();
> > >   if (!t->on_rq) {
> > >   if (atomic_test_and_clear(&t->rcu_attention, RCU_TASK))
> > >   atomic_dec(&rcu_tasks);
> > >   }
> > >   }
> > > 
> > >   wait_event(&rcu_tasks_wq, !atomic_read(&rcu_tasks));
> > > 
> > > 
> > > And then we have rcu_task_note_context_switch() (as called from
> > > rcu_note_context_switch) do:
> > > 
> > > 
> > >   /* we want actual context switches, ignore preemption */
> > >   if (preempt_count() & PREEMPT_ACTIVE)
> > >   return;
> > > 
> > >   /* if not marked for RCU attention, bail */
> > >   if (!(atomic_read(&t->rcu_attention) & RCU_TASK))
> > >   return;
> > > 
> > >   /* raced with sync_rcu_task(), all done */
> > >   if (!atomic_test_and_clear(&t->rcu_attention, RCU_TASK))
> > >   return;
> > > 
> > >   /* not the last.. */
> > >   if (!atomic_dec_and_test(&rcu_tasks))
> > >   return;
> > > 
> > >   wake_up(&rcu_task_rq);
> > > 
> > > 
> > > The idea is to share rcu_attention with rcu_preempt, such that we only
> > > touch a single 'extra' cacheline in case RCU doesn't need to pay
> > > attention to this task.
> > > 
> > > Also, it would be good if we can manage to squeeze this variable in a
> > > cacheline that's already touched by the schedule() so as not to incur
> > > undue overhead.
> > 
> > This approach does not get me the idle tasks and the NO_HZ_FULL usermode
> > tasks.  I am pretty sure that I am stuck polling in those cases, so I
> > might as well poll.
> 
> That's so wrong its not funny. If you need some abortion to deal with
> NOHZ_FULL then put it under CONFIG_NOHZ_FULL, don't burden the entire
> world with it.

Peter, the polling approach actually -reduces- the common-case
per-context-switch burden, as in when RCU-tasks isn't doing anything.
See your own code above.

> Also, I thought RCU already knew which CPUs were in nohz_full userspace,
> so we can insta check that in the sync, together with the !->on_rq test,
> if the task is running on a nohz_full cpu in rcu quiescent state, also
> clear the task.

RCU does know which are in nohz_full userspace, but it needs to handle
the case where they are not nohz_full at the beginning of the RCU-tasks
grace period.  Yes, I could hook into rcu_user_enter(), but that is
backwards from the viewpoint of the common case where there is no
RCU-tasks happening.

> As for idle tasks, I'm not sure about those, I think that we should say
> NO to anything that would require waking idle CPUs, push the pain to
> ftrace/kprobes, we should _not_ be waking idle cpus.

So the current patch set wakes an idle task once per RCU-tasks grace
period, but only when that idle task did not otherwise get awakened.
This is not a real problem.

And it could probably be reduced further, for example, for architectures
where the program counter of sleeping CPUs can be remotely accessed and
where the address of the am-asleep code is known.  I doubt that this
would really be worth it, but it could be done, in theory anyway.  Or, as
Steven suggested earlier, there could be a per-CPU variable that was set
(with approapriate memory ordering) when the CPU was actually sleeping.

So I don't believe that the current wakeup rate is a problem, and it
can be reduced if it proves to be a problem.

Thanx, Paul

--
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] ethernet: amd: Remove typedef local_info_t

[Himangi Saraogi]

The Linux kernel coding style guidelines suggest not using typedefs
for structure types. This patch gets rid of the typedef for local_info_t.
Also, the name of the struct is changed to drop the _t, to make the
name look less typedef-like.

The following Coccinelle semantic patch detects the case:

@tn@
identifier i;
type td;
@@

-typedef
 struct i { ... }
-td
 ;

@@
type tn.td;
identifier tn.i;
@@

-td
+ struct i

Signed-off-by: Himangi Saraogi 
Acked-by: Julia Lawall 
---
 drivers/net/ethernet/xircom/xirc2ps_cs.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/xircom/xirc2ps_cs.c 
b/drivers/net/ethernet/xircom/xirc2ps_cs.c
index 7c81ffb..d56f869 100644
--- a/drivers/net/ethernet/xircom/xirc2ps_cs.c
+++ b/drivers/net/ethernet/xircom/xirc2ps_cs.c
@@ -266,7 +266,7 @@ static void xirc2ps_detach(struct pcmcia_device *p_dev);
 
 static irqreturn_t xirc2ps_interrupt(int irq, void *dev_id);
 
-typedef struct local_info_t {
+struct local_info {
struct net_device   *dev;
struct pcmcia_device*p_dev;
 
@@ -281,7 +281,7 @@ typedef struct local_info_t {
 unsigned last_ptr_value; /* last packets transmitted value */
 const char *manf_str;
 struct work_struct tx_timeout_task;
-} local_info_t;
+};
 
 /
  * Some more prototypes
@@ -475,12 +475,12 @@ static int
 xirc2ps_probe(struct pcmcia_device *link)
 {
 struct net_device *dev;
-local_info_t *local;
+struct local_info *local;
 
 dev_dbg(&link->dev, "attach()\n");
 
 /* Allocate the device structure */
-dev = alloc_etherdev(sizeof(local_info_t));
+dev = alloc_etherdev(sizeof(struct local_info));
 if (!dev)
return -ENOMEM;
 local = netdev_priv(dev);
@@ -536,7 +536,7 @@ static int
 set_card_type(struct pcmcia_device *link)
 {
 struct net_device *dev = link->priv;
-local_info_t *local = netdev_priv(dev);
+struct local_info *local = netdev_priv(dev);
 u8 *buf;
 unsigned int cisrev, mediaid, prodid;
 size_t len;
@@ -690,7 +690,7 @@ static int
 xirc2ps_config(struct pcmcia_device * link)
 {
 struct net_device *dev = link->priv;
-local_info_t *local = netdev_priv(dev);
+struct local_info *local = netdev_priv(dev);
 unsigned int ioaddr;
 int err;
 u8 *buf;
@@ -931,7 +931,7 @@ xirc2ps_release(struct pcmcia_device *link)
 
if (link->resource[2]->end) {
struct net_device *dev = link->priv;
-   local_info_t *local = netdev_priv(dev);
+   struct local_info *local = netdev_priv(dev);
if (local->dingo)
iounmap(local->dingo_ccr - 0x0800);
}
@@ -975,7 +975,7 @@ static irqreturn_t
 xirc2ps_interrupt(int irq, void *dev_id)
 {
 struct net_device *dev = (struct net_device *)dev_id;
-local_info_t *lp = netdev_priv(dev);
+struct local_info *lp = netdev_priv(dev);
 unsigned int ioaddr;
 u_char saved_page;
 unsigned bytes_rcvd;
@@ -1194,8 +1194,8 @@ xirc2ps_interrupt(int irq, void *dev_id)
 static void
 xirc2ps_tx_timeout_task(struct work_struct *work)
 {
-   local_info_t *local =
-   container_of(work, local_info_t, tx_timeout_task);
+   struct local_info *local =
+   container_of(work, struct local_info, tx_timeout_task);
struct net_device *dev = local->dev;
 /* reset the card */
 do_reset(dev,1);
@@ -1206,7 +1206,7 @@ xirc2ps_tx_timeout_task(struct work_struct *work)
 static void
 xirc_tx_timeout(struct net_device *dev)
 {
-local_info_t *lp = netdev_priv(dev);
+struct local_info *lp = netdev_priv(dev);
 dev->stats.tx_errors++;
 netdev_notice(dev, "transmit timed out\n");
 schedule_work(&lp->tx_timeout_task);
@@ -1215,7 +1215,7 @@ xirc_tx_timeout(struct net_device *dev)
 static netdev_tx_t
 do_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
-local_info_t *lp = netdev_priv(dev);
+struct local_info *lp = netdev_priv(dev);
 unsigned int ioaddr = dev->base_addr;
 int okay;
 unsigned freespace;
@@ -1300,7 +1300,7 @@ static void set_address(struct set_address_info *sa_info, 
char *addr)
 static void set_addresses(struct net_device *dev)
 {
unsigned int ioaddr = dev->base_addr;
-   local_info_t *lp = netdev_priv(dev);
+   struct local_info *lp = netdev_priv(dev);
struct netdev_hw_addr *ha;
struct set_address_info sa_info;
int i;
@@ -1362,7 +1362,7 @@ set_multicast_list(struct net_device *dev)
 static int
 do_config(struct net_device *dev, struct ifmap *map)
 {
-local_info_t *local = netdev_priv(dev);
+struct local_info *local = netdev_priv(dev);
 
 pr_debug("do_config(%p)\n", dev);
 if (map->port != 255 && map->port != dev->if_port) {
@@ -1387,7 +1387,7 @@ do_config(struct net_device *dev, struct ifmap *map)
 static int
 do_open(struct net_device *dev)
 {
-local_info_t *lp = netdev_priv(dev);
+struct loc

Re: [PATCH 3.16 00/17] 3.16.1-stable review

[Greg Kroah-Hartman]

On Sat, Aug 09, 2014 at 08:43:01AM -0600, Shuah Khan wrote:
> On 08/08/2014 03:35 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.16.1 release.
> >There are 17 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Sun Aug 10 21:34:49 UTC 2014.
> >Anything received after that time might be too late.
> >
> >The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.1-rc1.gz
> >and the diffstat can be found below.
> >
> >thanks,
> >
> >greg k-h
> >
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h
--
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] staging: nokia_h4: use more consistent name for intermediate object

[Pavel Machek]

On Thu 2014-08-07 13:24:07, Greg KH wrote:
> On Thu, Aug 07, 2014 at 10:13:29AM +0200, Pavel Machek wrote:
> > 
> > Signed-off-by: Pavel Machek 
> > 
> > diff --git a/drivers/staging/nokia_h4p/Makefile 
> > b/drivers/staging/nokia_h4p/Makefile
> > index 9625db4..daffe3c 100644
> > --- a/drivers/staging/nokia_h4p/Makefile
> > +++ b/drivers/staging/nokia_h4p/Makefile
> > @@ -1,6 +1,6 @@
> >  
> > -obj-$(CONFIG_BT_NOKIA_H4P) += btnokia_h4p.o
> > -btnokia_h4p-objs := nokia_core.o nokia_fw.o nokia_uart.o nokia_fw-csr.o \
> > +obj-$(CONFIG_BT_NOKIA_H4P) += hci_h4p.o
> > +hci_h4p-objs := nokia_core.o nokia_fw.o nokia_uart.o nokia_fw-csr.o \
> > nokia_fw-bcm.o nokia_fw-ti1273.o
> >  
> >  ccflags-y += -D__CHECK_ENDIAN__
> 
> You just changed the kernel module name, did you really mean to do that?
> 
> Why?
> 
> It's not an "intermediate" object here, it's a .ko file, right?

Ok, lets not do that now. btnokia_h4p is really strange name, and it
will probably need to be fixed in future, but now may not be a good
time.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/

Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current->real_parent field

[Greg Kroah-Hartman]

On Sat, Aug 09, 2014 at 10:34:36AM -0400, Oleg Drokin wrote:
> 
> > Because maybe these stats preceed the introduction of perf and other
> > tracing/debug tools?  I don't know, it's really low down on the list of
> > reasons why lustre can't be merged out of staging at the moment, you all
> > have much bigger issues to address first.
> 
> I wonder what is the prioritized list you have in mind?

Do I really have to spell out what is wrong with that codebase that
needs to be fixed up?  It took me 50+ patches for 3.17-rc1 to just fix
up a _portion_ of the include file mess that is in there.  Now is the
first time the code actually _builds_ properly in the kernel tree (i.e.
no magic header file include path modifications in Makefiles preventing
individual files from being built correctly.)

If you all don't know what needs to be done here, then I might as well
just delete the drivers/staging/lustre/ tree right now.

greg k-h
--
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] staging: nokia_h4: merge firmware together so that we can reduce ammount of exports

[Pavel Machek]

Hi!


> > +
> > +   skb_queue_tail(&info->txq, fw_skb);
> > +   spin_lock_irqsave(&info->lock, flags);
> > +   hci_h4p_outb(info, UART_IER, hci_h4p_inb(info, UART_IER) |
> > +   UART_IER_THRI);
> > +   spin_unlock_irqrestore(&info->lock, flags);
> > +}
> 
> and as I explained before, this crazy can not continue. Bluetooth drivers can 
> provide a hdev->setup callback for loading firmware and doing other setup 
> details. You can just bring up the HCI transport. We are providing 
> __hci_cmd_sync for easy loading of the firmware. Especially if the firmware 
> just consists of HCI commands. Which is clearly the case with the Nokia 
> firmware files.
> 

I know that this crazyness can not continue; but I need to be able to
move "bad" code around to get the cleanups, ok? Because you also asked
me to reduce ammount of exports.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/

Re: [PATCH] pinctrl: Add mux options 3 and 4 for rockchip pinctrl

[Heiko Stübner]

Am Freitag, 8. August 2014, 15:29:09 schrieb Doug Anderson:
> Newer Rockchip SoCs have more muxing slots.  Add slots 3 and 4 since
> the rk3288 table goes all the way up to 4.
> 
> Signed-off-by: Doug Anderson 

Reviewed-by: Heiko Stuebner 


> ---
>  Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 6 +++---
>  include/dt-bindings/pinctrl/rockchip.h | 2 ++
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index
> 4658b69..388b213 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> @@ -2,8 +2,8 @@
> 
>  The Rockchip Pinmux Controller, enables the IC
>  to share one PAD to several functional blocks. The sharing is done by
> -multiplexing the PAD input/output signals. For each PAD there are up to
> -4 muxing options with option 0 being the use as a GPIO.
> +multiplexing the PAD input/output signals. For each PAD there are several
> +muxing options with option 0 being the use as a GPIO.
> 
>  Please refer to pinctrl-bindings.txt in this directory for details of the
>  common pinctrl bindings used by client devices, including the meaning of
> the @@ -58,7 +58,7 @@ Deprecated properties for gpio sub nodes:
>  Required properties for pin configuration node:
>- rockchip,pins: 3 integers array, represents a group of pins mux and
> config setting. The format is rockchip,pins =  &phandle>. -The MUX 0 means gpio and MUX 1 to 3 mean the specific
> device function. +The MUX 0 means gpio and MUX 1 to N mean the specific
> device function. The phandle of a node containing the generic pinconfig
> options to use, as described in pinctrl-bindings.txt in this directory.
> 
> diff --git a/include/dt-bindings/pinctrl/rockchip.h
> b/include/dt-bindings/pinctrl/rockchip.h index cd5788b..743e66a 100644
> --- a/include/dt-bindings/pinctrl/rockchip.h
> +++ b/include/dt-bindings/pinctrl/rockchip.h
> @@ -28,5 +28,7 @@
>  #define RK_FUNC_GPIO 0
>  #define RK_FUNC_11
>  #define RK_FUNC_22
> +#define RK_FUNC_33
> +#define RK_FUNC_44
> 
>  #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/

Re: linux-next: build failures after merge of the drm tree

[Olof Johansson]

On Fri, Aug 8, 2014 at 2:40 PM, Olof Johansson  wrote:
> On Mon, Aug 4, 2014 at 11:02 PM, YoungJun Cho  wrote:
>> Hi Stephen and Dave,
>>
>>
>> On 08/05/2014 12:09 PM, Stephen Rothwell wrote:
>>>
>>> Hi Dave,
>>>
>>> After merging the drm tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> ERROR: "drm_sysfs_connector_remove" [drivers/gpu/drm/i2c/tda998x.ko]
>>> undefined!
>>> ERROR: "drm_sysfs_connector_add" [drivers/gpu/drm/i2c/tda998x.ko]
>>> undefined!
>>>
>>> Caused by commit c707c3619ca8 ("drm/i2c: tda998x: add component
>>> support") interacting with commit 34ea3d386347 ("drm: add register and
>>> unregister functions for connectors").  Maybe it should have been fixed
>>> up in the merge commit 920f946428b7 ("Merge branch 'tda998x-devel' of
>>> git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next")?
>>>
>>> I reverted commit c707c3619ca8 for today.
>>>
>>> But then the arm multi_v7_defconfig build produced these errors:
>>>
>>> ERROR (phandle_references): Reference to non-existent node or label
>>> "disp_pd"
>>>
>>> ERROR: Input tree has errors, aborting (use -f to force output)
>>> make[2]: *** [arch/arm/boot/dts/exynos5420-arndale-octa.dtb] Error 2
>>> make[2]: *** Waiting for unfinished jobs
>>> ERROR (phandle_references): Reference to non-existent node or label
>>> "disp_pd"
>>>
>>> ERROR: Input tree has errors, aborting (use -f to force output)
>>> make[2]: *** [arch/arm/boot/dts/exynos5420-smdk5420.dtb] Error 2
>>> ERROR (phandle_references): Reference to non-existent node or label
>>> "disp_pd"
>>>
>>> ERROR: Input tree has errors, aborting (use -f to force output)
>>> ERROR (phandle_references): Reference to non-existent node or label
>>> "disp_pd"
>>>
>>> make[2]: *** [arch/arm/boot/dts/exynos5800-peach-pi.dtb] Error 2
>>> ERROR: Input tree has errors, aborting (use -f to force output)
>>>
>>> Caused by commit 5a8da524049c ("ARM: dts: exynos5420: add dsi node")
>>> interacting with commit d51cad7df871 ("ARM: dts: remove display power
>>> domain for exynos5420") from the arm-soc tree.
>>>
>>
>> I missed the patch "ARM: dts: remove display power domain for exynos5420" in
>> linux-samsung-soc mail thread.
>>
>> In my test without power domain property, the exynos5420 dsi master driver
>> works well.
>>
>>
>>> I applied this merge fix patch:
>>>
>>> From: Stephen Rothwell 
>>> Date: Tue, 5 Aug 2014 13:03:01 +1000
>>> Subject: [PATCH] ARM: dts: exynos5420: remove disp_pd
>>>
>>> per comit d51cad7df871 ("ARM: dts: remove display power
>>> domain for exynos5420").
>>>
>>> Signed-off-by: Stephen Rothwell 
>>> ---
>>>   arch/arm/boot/dts/exynos5420.dtsi | 1 -
>>>   1 file changed, 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
>>> b/arch/arm/boot/dts/exynos5420.dtsi
>>> index 95ec37dff3e8..bfe056d9148c 100644
>>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>>> @@ -525,7 +525,6 @@
>>> compatible = "samsung,exynos5410-mipi-dsi";
>>> reg = <0x1450 0x1>;
>>> interrupts = <0 82 0>;
>>> -   samsung,power-domain = <&disp_pd>;
>>> phys = <&mipi_phy 1>;
>>> phy-names = "dsim";
>>> clocks = <&clock CLK_DSIM1>, <&clock CLK_SCLK_MIPI1>;
>>>
>>
>> Tested-by: YoungJun Cho 
>
> Sigh, now Linus' tree is broken because of this because nobody picked it up.
>
> Dave, can you revert the original change, please? (5a8da524049c).
>
> DTS changes like these shouldn't go through driver trees in the first place. 
> :(

Still no reply? I'm including the above patch in my current set of fixes.


-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 v5][next-20140804] ARM: EXYNOS: Fix suspend/resume sequences

[Olof Johansson]

On Tue, Aug 05, 2014 at 02:43:10PM +0200, Bartlomiej Zolnierkiewicz wrote:
> From: Tomasz Figa 
> 
> Due to recent consolidation of Exynos suspend and cpuidle code, some
> parts of suspend and resume sequences are executed two times, once from
> exynos_pm_syscore_ops and then from exynos_cpu_pm_notifier() and thus it
> breaks suspend, at least on Exynos4-based boards. In addition, simple
> core power down from a cpuidle driver could, in case of CPU 0 could
> result in calling functions that are specific to suspend and deeper idle
> states.
> 
> This patch fixes the issue by moving those operations outside the CPU PM
> notifier into suspend and AFTR code paths. This leads to a bit of code
> duplication, but allows additional code simplification, so in the end
> more code is removed than added.
> 
> Fixes: 85f9f90808b4 ("ARM: EXYNOS: Use the cpu_pm notifier for pm")
> Cc: Kukjin Kim 
> Cc: Arnd Bergmann 
> Cc: Olof Johansson 
> Cc: a...@kernel.org
> Signed-off-by: Tomasz Figa 
> [b.zolnierkie: ported patch over current changes]
> [b.zolnierkie: fixed exynos_aftr_finisher() return value]
> Signed-off-by: Bartlomiej Zolnierkiewicz 

Applied to fixes.


-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 3.16 00/17] 3.16.1-stable review

[Guenter Roeck]

On 08/09/2014 07:16 AM, Greg Kroah-Hartman wrote:
[ .. ]

Just for reference, in mainline, we currently have
total: 133 pass: 127 fail: 6
plus four (!) qemu tests failing (arm, mips, mips64, and ppc),
meaning there will be three more dropped configurations (all arm
as far as I can see), and there is already a bunch of failures.
This is with v3.16-9794-g8065be8. next-20140808 build result is
total: 133 pass: 121 fail: 12
with the same failed qemu tests, so it will only get worse :-(.

Some improved quality assurance may be helpful going forward,
especially since many of the failures seem to be due to lack of
(build) testing and could easily have been avoided. Something
to discuss in Chicago, maybe.


I wonder if it is just due to the merge not being finished yet?  The
0-day built-bot should have caught any major build issues before now
with the individual trees, so there shouldn't be any reason you should
be seeing failures :(



There are two arm build failures in Linus' tree which are not seen
in -next. Those are either merge problems, or maybe there is some
other series of arm patches coming. Either case, the arm folks are
pretty good at tracking failures, so I assume those will be fixed
soon (especially since multi_v7_defconfig is one of the failing
builds). The other build failures are all seen in -next as well,
so they _should_ be known.

For the qemu failures, they are all the same in -next and in the
tip of Linus' tree, so I guess no one tested the configurations
I use for qemu tests. I only recently added -next to the list of
branches to test, so I only noticed the failures after they showed up
in Linus' tree.

Guenter

--
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.16 00/17] 3.16.1-stable review

[Shuah Khan]

On 08/08/2014 03:35 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.16.1 release.
There are 17 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Aug 10 21:34:49 UTC 2014.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.16.1-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

-- Shuah

--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
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.15 00/26] 3.15.10-stable review

[Shuah Khan]

On 08/08/2014 03:35 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.15.10 release.
There are 26 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Aug 10 21:34:03 UTC 2014.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.15.10-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

-- Shuah


--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
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.10 00/24] 3.10.53-stable review

[Shuah Khan]

On 08/08/2014 03:34 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.10.53 release.
There are 24 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Aug 10 21:33:26 UTC 2014.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.53-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

-- Shuah

--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
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.14 00/39] 3.14.17-stable review

[Shuah Khan]

On 08/08/2014 03:34 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.14.17 release.
There are 39 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Aug 10 21:33:45 UTC 2014.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.17-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

-- Shuah

--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
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.4 00/23] 3.4.103-stable review

[Shuah Khan]

On 08/08/2014 03:34 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.4.103 release.
There are 23 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Aug 10 21:33:01 UTC 2014.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.103-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h



Compiled and booted on my test system. No dmesg regressions.

-- Shuah


--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
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] staging/lustre: use rcu_dereference to access rcu protected current->real_parent field

[Oleg Drokin]

> Because maybe these stats preceed the introduction of perf and other
> tracing/debug tools?  I don't know, it's really low down on the list of
> reasons why lustre can't be merged out of staging at the moment, you all
> have much bigger issues to address first.

I wonder what is the prioritized list you have in mind?

Bye,
Oleg
--
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 1/5] proc: intoduce proc_inode->pid_entry and is_tgid_pid_entry()

[Oleg Nesterov]

On 08/09, Cyrill Gorcunov wrote:
>
> On Fri, Aug 08, 2014 at 08:57:47PM +0200, Oleg Nesterov wrote:
> ...
> > +++ b/fs/proc/inode.c
> > @@ -73,6 +73,7 @@ static struct inode *proc_alloc_inode(struct super_block 
> > *sb)
> > ei->pde = NULL;
> > ei->sysctl = NULL;
> > ei->sysctl_entry = NULL;
> > +   ei->pid_entry = NULL;
> > ei->ns.ns = NULL;
> > ei->ns.ns_ops = NULL;
> > inode = &ei->vfs_inode;
>
> Hi Oleg, sorry for not responding to previous emails, will try to review this
> things tomorrow (from a glance looks quite good!). Btw, this moment strike my
> eyes -- why don't we use kmem_cache_zalloc here but do assign nils again and
> again, maybe worth to address as well?

Probably because this doesn't make sense to nullify proc_inode->vfs_inode,
it will be reinitialized at least by inode_init_always() anyway.

Oleg.

--
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/

[sched] Out of memory: Kill process 2999 (rc) score 9 or sacrifice child

[Fengguang Wu]

Hi Peter,

We noticed the below changes on

git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/wait
commit d58d631b474c552dce72da2dce9dd276d731b79a ("sched: Fix finish_task_switch 
vs prev_state")

test case: vm-vp-quantal-x86_64/boot/1

9e6e6179961e8dd  d58d631b474c552dce72da2dc  testbox/testcase/testparams
---  -  ---
 0   +Inf%  1 ± 0%  TOTAL 
dmesg.Out_of_memory:Kill_process
 0   +Inf%  0 ±50%  TOTAL 
dmesg.Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes

In commit 9e6e6179961e8dd, the boot dmesg is

[7.537598] Freeing unused kernel memory: 3352K (8223 - 
82576000)
[7.558273] random: init urandom read with 11 bits of entropy available
[7.687132] init: Failed to create pty - disabling logging for job
[7.688578] init: Temporary process spawn error: No space left on device
[   68.298970] reboot: Restarting system

In d58d631b474c552dce72da2dc, the OOM occurred immediately after the
"No space left on device" line. The qemu has mem=320M and the initrds
are 24M in total. What's interesting is, in the 5 boot tests for
d58d631b47 and its parent commit, this OOM message is 100%
reproducible on commit d58d631b47, while its parent boots all fine. 

Thanks,
Fengguang
early console in setup code
early console in decompress_kernel

Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.16.0-00918-gd58d631 (kbuild@lkp-hsx01) (gcc 
version 4.8.2 (Debian 4.8.2-18) ) #11 SMP Sat Aug 9 07:13:50 CST 2014
[0.00] Command line: user=lkp 
job=/lkp/scheduled/vm-vp-quantal-x86_64-47/bisect_boot-1-x86_64-nfsroot-d58d631b474c552dce72da2dce9dd276d731b79a-4.yaml
 ARCH=x86_64 
BOOT_IMAGE=/kernel/x86_64-nfsroot/d58d631b474c552dce72da2dce9dd276d731b79a/vmlinuz-3.16.0-00918-gd58d631
 kconfig=x86_64-nfsroot commit=d58d631b474c552dce72da2dce9dd276d731b79a 
initrd=/kernel-tests/initrd/quantal-core-x86_64.cgz root=/dev/ram0 
lkp_initrd=/lkp/lkp/lkp-x86_64.cgz 
modules_initrd=/kernel/x86_64-nfsroot/d58d631b474c552dce72da2dce9dd276d731b79a/modules.cgz
 
RESULT_ROOT=/result/vm-vp-quantal-x86_64/boot/1/x86_64-nfsroot/d58d631b474c552dce72da2dce9dd276d731b79a/0
 ip=vm-vp-quantal-x86_64-47::dhcp oops=panic earlyprintk=ttyS0,115200 debug 
apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=10 
softlockup_panic=1 nmi_watchdog=panic load_ramdisk=2 prompt_ramdisk=0 
console=ttyS0,115200 console=tty0 vga=normal rw drbd.minor_count=8
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   Centaur CentaurHauls
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x167fdfff] usable
[0.00] BIOS-e820: [mem 0x167fe000-0x167f] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] bootconsole [earlyser0] enabled
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011
[0.00] Hypervisor detected: KVM
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x167fe max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 008000 mask FF8000 uncachable
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] PAT not supported by CPU.
[0.00] Scan for SMP in [mem 0x-0x03ff]
[0.00] Scan for SMP in [mem 0x0009fc00-0x0009]
[0.00] Scan for SMP in [mem 0x000f-0x000f]
[0.00] found SMP MP-table at [mem 0x000fdac0-0x000fdacf] mapped at 
[880fdac0]
[0.00]   mpc: fdad0-fdbec
[0.00] Scanning 1 areas for low memory corruption
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x03509000, 0x03509fff] PGTABLE
[0.0

Re: [PATCH V3] Thermal: imx: add i.mx6sx thermal support

[Eduardo Valentin]

Hello Anson,

On Wed, Aug 06, 2014 at 03:12:09PM +0800, Anson Huang wrote:
> i.MX6SX has some new features of thermal interrupt function,
> there are LOW, HIGH and PANIC irq for thermal sensor, so add
> platform data to separate different thermal version;
> 
> The reset value of LOW ALARM is 0 which means the highest
> temp, so the LOW ALARM will be triggered once irq is enabled,
> so we need to correct it before enabling thermal irq;
> 
> Enable PANIC ALARM as critical trip point, it will trigger
> system reset via SRC module once PANIC IRQ is triggered, it
> is pure hardware function, so use it instead of software
> reset by cooling device.
> 
> Signed-off-by: Anson Huang 
> ---

Pulled. Thanks.

>  .../devicetree/bindings/thermal/imx-thermal.txt|5 +-
>  drivers/thermal/imx_thermal.c  |   91 
> +---
>  2 files changed, 82 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> index 1f0f672..3c67bd5 100644
> --- a/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
> @@ -1,7 +1,10 @@
>  * Temperature Monitor (TEMPMON) on Freescale i.MX SoCs
>  
>  Required properties:
> -- compatible : "fsl,imx6q-thermal"
> +- compatible : "fsl,imx6q-tempmon" for i.MX6Q, "fsl,imx6sx-tempmon" for 
> i.MX6SX.
> +  i.MX6SX has two more IRQs than i.MX6Q, one is IRQ_LOW and the other is 
> IRQ_PANIC,
> +  when temperature is below than low threshold, IRQ_LOW will be triggered, 
> when temperature
> +  is higher than panic threshold, system will auto reboot by SRC module.
>  - fsl,tempmon : phandle pointer to system controller that contains TEMPMON
>control registers, e.g. ANATOP on imx6q.
>  - fsl,tempmon-data : phandle pointer to fuse controller that contains TEMPMON
> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> index 2c516f2..461bf3d 100644
> --- a/drivers/thermal/imx_thermal.c
> +++ b/drivers/thermal/imx_thermal.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,6 +32,11 @@
>  
>  #define MISC00x0150
>  #define MISC0_REFTOP_SELBIASOFF  (1 << 3)
> +#define MISC10x0160
> +#define MISC1_IRQ_TEMPHIGH   (1 << 29)
> +/* Below LOW and PANIC bits are only for TEMPMON_IMX6SX */
> +#define MISC1_IRQ_TEMPLOW(1 << 28)
> +#define MISC1_IRQ_TEMPPANIC  (1 << 27)
>  
>  #define TEMPSENSE0   0x0180
>  #define TEMPSENSE0_ALARM_VALUE_SHIFT 20
> @@ -43,6 +49,12 @@
>  
>  #define TEMPSENSE1   0x0190
>  #define TEMPSENSE1_MEASURE_FREQ  0x
> +/* Below TEMPSENSE2 is only for TEMPMON_IMX6SX */
> +#define TEMPSENSE2   0x0290
> +#define TEMPSENSE2_LOW_VALUE_SHIFT   0
> +#define TEMPSENSE2_LOW_VALUE_MASK0xfff
> +#define TEMPSENSE2_PANIC_VALUE_SHIFT 16
> +#define TEMPSENSE2_PANIC_VALUE_MASK  0xfff
>  
>  #define OCOTP_ANA1   0x04e0
>  
> @@ -66,6 +78,21 @@ enum imx_thermal_trip {
>  #define FACTOR1  15976
>  #define FACTOR2  4297157
>  
> +#define TEMPMON_IMX6Q1
> +#define TEMPMON_IMX6SX   2
> +
> +struct thermal_soc_data {
> + u32 version;
> +};
> +
> +static struct thermal_soc_data thermal_imx6q_data = {
> + .version = TEMPMON_IMX6Q,
> +};
> +
> +static struct thermal_soc_data thermal_imx6sx_data = {
> + .version = TEMPMON_IMX6SX,
> +};
> +
>  struct imx_thermal_data {
>   struct thermal_zone_device *tz;
>   struct thermal_cooling_device *cdev;
> @@ -79,8 +106,21 @@ struct imx_thermal_data {
>   bool irq_enabled;
>   int irq;
>   struct clk *thermal_clk;
> + const struct thermal_soc_data *socdata;
>  };
>  
> +static void imx_set_panic_temp(struct imx_thermal_data *data,
> +signed long panic_temp)
> +{
> + struct regmap *map = data->tempmon;
> + int critical_value;
> +
> + critical_value = (data->c2 - panic_temp) / data->c1;
> + regmap_write(map, TEMPSENSE2 + REG_CLR, TEMPSENSE2_PANIC_VALUE_MASK);
> + regmap_write(map, TEMPSENSE2 + REG_SET, critical_value <<
> + TEMPSENSE2_PANIC_VALUE_SHIFT);
> +}
> +
>  static void imx_set_alarm_temp(struct imx_thermal_data *data,
>  signed long alarm_temp)
>  {
> @@ -142,13 +182,17 @@ static int imx_get_temp(struct thermal_zone_device *tz, 
> unsigned long *temp)
>   /* See imx_get_sensor_data() for formula derivation */
>   *temp = data->c2 - n_meas * data->c1;
>  
> - /* Update alarm value to next higher trip point */
> - if (data->alarm_temp == data->temp_passive && *temp >= 
> data->temp_passive)
> - imx_set_alarm_temp(data, data->te