[PATCH] kbuild: provide include/asm/asm-prototypes.h for ARM

[Arnd Bergmann]

This adds an asm/asm-prototypes.h header for ARM to fix the
broken symbol versioning for symbols exported from assembler
files.

In addition to the header, we have to do these other small
changes:

- move the 'extern' declarations out of memset_io/memcpy_io
  to make them visible to the symbol version generator
- move the exports from bitops.h to {change,clear,set,...}bit.S
- move the exports from csumpartialgeneric.S into the files
  including it

I couldn't find the correct prototypes for the compiler builtins,
so I went with the fake 'void f(void)' prototypes that we had
before.

Signed-off-by: Arnd Bergmann 

diff --git a/arch/arm/include/asm/asm-prototypes.h 
b/arch/arm/include/asm/asm-prototypes.h
new file mode 100644
index ..04e5616a7b15
--- /dev/null
+++ b/arch/arm/include/asm/asm-prototypes.h
@@ -0,0 +1,34 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+extern void __aeabi_idivmod(void);
+extern void __aeabi_idiv(void);
+extern void __aeabi_lasr(void);
+extern void __aeabi_llsl(void);
+extern void __aeabi_llsr(void);
+extern void __aeabi_lmul(void);
+extern void __aeabi_uidivmod(void);
+extern void __aeabi_uidiv(void);
+extern void __aeabi_ulcmp(void);
+
+extern void __ashldi3(void);
+extern void __ashrdi3(void);
+extern void __bswapdi2(void);
+extern void __bswapsi2(void);
+extern void __divsi3(void);
+extern void __do_div64(void);
+extern void __lshrdi3(void);
+extern void __modsi3(void);
+extern void __muldi3(void);
+extern void __ucmpdi2(void);
+extern void __udivsi3(void);
+extern void __umodsi3(void);
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 51458d8273ad..fbc3695293cf 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -316,11 +316,13 @@ extern void _memset_io(volatile void __iomem *, int, 
size_t);
 #define writesw(p,d,l) __raw_writesw(p,d,l)
 #define writesl(p,d,l) __raw_writesl(p,d,l)
 
+extern void mmioset(void *, unsigned int, size_t);
+extern void mmiocpy(void *, const void *, size_t);
+
 #ifndef __ARMBE__
 static inline void memset_io(volatile void __iomem *dst, unsigned c,
size_t count)
 {
-   extern void mmioset(void *, unsigned int, size_t);
mmioset((void __force *)dst, c, count);
 }
 #define memset_io(dst,c,count) memset_io(dst,c,count)
@@ -328,7 +330,6 @@ static inline void memset_io(volatile void __iomem *dst, 
unsigned c,
 static inline void memcpy_fromio(void *to, const volatile void __iomem *from,
size_t count)
 {
-   extern void mmiocpy(void *, const void *, size_t);
mmiocpy(to, (const void __force *)from, count);
 }
 #define memcpy_fromio(to,from,count) memcpy_fromio(to,from,count)
@@ -336,7 +337,6 @@ static inline void memcpy_fromio(void *to, const volatile 
void __iomem *from,
 static inline void memcpy_toio(volatile void __iomem *to, const void *from,
size_t count)
 {
-   extern void mmiocpy(void *, const void *, size_t);
mmiocpy((void __force *)to, from, count);
 }
 #define memcpy_toio(to,from,count) memcpy_toio(to,from,count)
diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index df06638b327c..afaef2a7faec 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -26,7 +26,6 @@ UNWIND(   .fnstart)
bx  lr
 UNWIND(.fnend  )
 ENDPROC(\name  )
-EXPORT_SYMBOL(\name)
.endm
 
.macro  testop, name, instr, store
@@ -57,7 +56,6 @@ UNWIND(   .fnstart)
 2: bx  lr
 UNWIND(.fnend  )
 ENDPROC(\name  )
-EXPORT_SYMBOL(\name)
.endm
 #else
.macro  bitop, name, instr
@@ -77,7 +75,6 @@ UNWIND(   .fnstart)
ret lr
 UNWIND(.fnend  )
 ENDPROC(\name  )
-EXPORT_SYMBOL(\name)
.endm
 
 /**
@@ -106,6 +103,5 @@ UNWIND( .fnstart)
ret lr
 UNWIND(.fnend  )
 ENDPROC(\name  )
-EXPORT_SYMBOL(\name)
.endm
 #endif
diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
index f4027862172f..005fdd18c509 100644
--- a/arch/arm/lib/changebit.S
+++ b/arch/arm/lib/changebit.S
@@ -13,3 +13,4 @@
 .text
 
 bitop  _change_bit, eor
+EXPORT_SYMBOL(_change_bit)
diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
index f6b75fb64d30..501eff09968d 100644
--- a/arch/arm/lib/clearbit.S
+++ b/arch/arm/lib/clearbit.S
@@ -13,3 +13,4 @@
 .text
 
 bitop  _clear_bit, bic
+EXPORT_SYMBOL(_clear_bit)
diff --git a/arch/arm/lib/csumpartialcopy.S b/arch/arm/lib/csumpartialcopy.S
index 9c3383fed129..bdcc2eea4e5c 100644
--- a/arch/arm/lib/csumpartialcopy.S
+++ b/arch/arm/lib/csumpartialcopy.S
@@ -49,6 +49,7 @@
 
 #define FN_ENTRY   ENTRY(csum_partial_copy_nocheck)
 #define FN_EXITENDPROC(csum_partial_copy_nocheck)
-#define FN_EXPORT  EXPORT_SYMBOL(csum_partial_copy_nocheck)
 
 #include 

Re: [PATCH] phy: rcar-gen3-usb2: add sysfs for usb role swap

[Geert Uytterhoeven]

Hi Shimoda-san,

On Mon, Oct 17, 2016 at 9:10 AM, Yoshihiro Shimoda
 wrote:
> This patch adds sysfs "otg_inputs" for usb role swap. This parameter
> is write-only and if you use them as the following, you can swap
> the usb role.

Thank you for your patch!

> For example:
>  1) connect a usb cable using 2 salvator-x boards
>  2) On A-device (as host), you input the following command:
># echo a_bus_req/ > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs
>  3) On B-device (as peripheral), you input the following command:
># echo b_bus_req > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs

At first, I thought the trailing "/" was a typo...

> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> @@ -0,0 +1,11 @@
> +What:  /sys/devices/platform//otg-inputs
> +Date:  October 2016
> +KernelVersion: 4.10
> +Contact:   Yoshihiro Shimoda 
> +Description:
> +   This write-only file changes the phy mode for role swap of 
> usb.
> +   This file accepts the following strings:
> +"a_bus_req/" - switching from A-Host to A-Peripheral
> +"a_bus_drop" - switching from A-Peripheral to A-Host
> +"b_bus_req"  - switching from B-Peripheral to B-Host
> +"b_bus_req/" - switching from B-Host to B-Peripheral

... until I read the above.

What's the rationale of doing it like this? I.e.
  1. Why differentiate by trailing "/"?
  2. Why the asymmetry ("a_bus_drop" vs. "a_bus_req")?

I do not really follow USB development, so I please accepty my apologies if
I missed the discussion and valid arguments that lead to this.

I did find Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg,
which uses similar naming, but a slightly different mechanism (multiple
sysfs virtual files with 0/1 states).

Thanks!

Gr{oetje,eeting}s,

Geert

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

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

[PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support

[Pan Wen]

Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.

Signed-off-by: Pan Wen 
---
 arch/arm/mach-hisi/Kconfig | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index a3b091a..03d8379 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -1,12 +1,14 @@
 config ARCH_HISI
bool "Hisilicon SoC Support"
-   depends on ARCH_MULTI_V7
select ARM_AMBA
-   select ARM_GIC
+   select ARM_GIC if ARCH_MULTI_V7
+   select ARM_VIC if ARCH_MULTI_V5
select ARM_TIMER_SP804
select POWER_RESET
select POWER_RESET_HISI
select POWER_SUPPLY
+   select PINCTRL
+   select PINCTRL_SINGLE
 
 if ARCH_HISI
 
@@ -18,8 +20,6 @@ config ARCH_HI3xxx
select CACHE_L2X0
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
-   select PINCTRL
-   select PINCTRL_SINGLE
help
  Support for Hisilicon Hi36xx SoC family
 
@@ -48,8 +48,6 @@ config ARCH_HIX5HD2
select CACHE_L2X0
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
-   select PINCTRL
-   select PINCTRL_SINGLE
help
  Support for Hisilicon HIX5HD2 SoC family
 endmenu
-- 
2.9.3

[PATCH 3/3] dts: hisi: add dts files for Hi3516CV300 demo board

[Pan Wen]

Add dts files for Hi3516CV300 demo board.

Signed-off-by: Pan Wen 
---
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/hi3516cv300-demb.dts | 148 
 arch/arm/boot/dts/hi3516cv300.dtsi | 397 +
 3 files changed, 546 insertions(+)
 create mode 100644 arch/arm/boot/dts/hi3516cv300-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3516cv300.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..1f25530 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -171,6 +171,7 @@ dtb-$(CONFIG_ARCH_HIP01) += \
 dtb-$(CONFIG_ARCH_HIP04) += \
hip04-d01.dtb
 dtb-$(CONFIG_ARCH_HISI) += \
+   hi3516cv300-demb.dtb \
hi3519-demb.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += \
hisi-x5hd2-dkb.dtb
diff --git a/arch/arm/boot/dts/hi3516cv300-demb.dts 
b/arch/arm/boot/dts/hi3516cv300-demb.dts
new file mode 100644
index 000..6a75cd6
--- /dev/null
+++ b/arch/arm/boot/dts/hi3516cv300-demb.dts
@@ -0,0 +1,148 @@
+/*
+ * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ */
+
+
+/dts-v1/;
+#include "hi3516cv300.dtsi"
+
+/ {
+   model = "Hisilicon Hi3516CV300 DEMO Board";
+   compatible = "hisilicon,hi3516cv300";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   i2c0 = _bus0;
+   i2c1 = _bus1;
+   spi0 = _bus0;
+   spi1 = _bus1;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>;
+   };
+};
+
+_timer0 {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_bus0 {
+   status = "okay";
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmux>;
+};
+
+_bus1 {
+   status = "okay";
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmux>;
+};
+
+_bus0{
+   status = "disabled";
+   num-cs = <1>;
+   cs-gpios = <_chip0 6 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmux>;
+};
+
+_bus1{
+   status = "okay";
+   num-cs = <2>;
+   cs-gpios = <_chip5 3 0>, <_chip5 4 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pmux>;
+};
+
+ {
+   spi-nor@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <16000>;
+   m25p,fast-read;
+   };
+};
+
+ {
+   phy0: phy@1 {
+   reg = <1>;
+   };
+};
+
+_femac {
+   mac-address = [00 00 00 00 00 00];
+   phy-mode = "rmii";
+   phy-handle = <>;
+   hisilicon,phy-reset-delays-us = <1 1 15>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   i2c0_pmux: i2c0_pmux {
+   pinctrl-single,pins = <
+   0x2c 0x3
+   0x30 0x3>;
+   };
+
+   i2c1_pmux: i2c1_pmux {
+   pinctrl-single,pins = <
+   0x20 0x1
+   0x24 0x1>;
+   };
+
+   spi0_pmux: spi0_pmux {
+   pinctrl-single,pins = <
+   0x28 0x1
+   0x2c 0x1
+   0x30 0x1
+   0x34 0x1>;
+   };
+
+   spi1_pmux: spi1_pmux {
+   pinctrl-single,pins = <
+   0xc4 0x1
+   0xc8 0x1
+   0xcc 0x1
+   0xd0 0x1
+   0xd4 0x1>;
+   };
+};
diff --git a/arch/arm/boot/dts/hi3516cv300.dtsi 
b/arch/arm/boot/dts/hi3516cv300.dtsi
new file mode 100644
index 000..1da41ab
--- /dev/null
+++ b/arch/arm/boot/dts/hi3516cv300.dtsi
@@ -0,0 +1,397 @@
+/*
+ * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; 

Re: [PATCH] shmem: avoid huge pages for small files

[Kirill A. Shutemov]

On Mon, Oct 17, 2016 at 03:18:09PM +0300, Kirill A. Shutemov wrote:
> diff --git a/mm/shmem.c b/mm/shmem.c
> index ad7813d73ea7..c69047386e2f 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -369,6 +369,7 @@ static bool shmem_confirm_swap(struct address_space 
> *mapping,
>  /* ifdef here to avoid bloating shmem.o when not necessary */
>  
>  int shmem_huge __read_mostly;
> +unsigned long long shmem_huge_min_size = HPAGE_PMD_SIZE __read_mostly;

Arghh.. Last second changes...

This should be 

unsigned long long shmem_huge_min_size __read_mostly = HPAGE_PMD_SIZE;


>From fd0b01b9797ddf2bef308c506c42d3dd50f11793 Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov" 
Date: Mon, 17 Oct 2016 14:44:47 +0300
Subject: [PATCH] shmem: avoid huge pages for small files

Huge pages are detrimental for small file: they causes noticible
overhead on both allocation performance and memory footprint.

This patch aimed to address this issue by avoiding huge pages until file
grown to specified size. This would cover most of the cases where huge
pages causes regressions in performance.

By default the minimal file size to allocate huge pages is equal to size
of huge page.

We add two handle to specify minimal file size for huge pages:

  - mount option 'huge_min_size';

  - sysfs file /sys/kernel/mm/transparent_hugepage/shmem_min_size for
in-kernel tmpfs mountpoint;

Few notes:

  - if shmem_enabled is set to 'force', the limit is ignored. We still
want to generate as many pages as possible for functional testing.

  - the limit doesn't affect khugepaged behaviour: it still can collapse
pages based on its settings;

  - remount of the filesystem doesn't affect previously allocated pages,
but the limit is applied for new allocations;

Signed-off-by: Kirill A. Shutemov 
---
 Documentation/vm/transhuge.txt |  6 +
 include/linux/huge_mm.h|  1 +
 include/linux/shmem_fs.h   |  1 +
 mm/huge_memory.c   |  1 +
 mm/shmem.c | 56 ++
 5 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index 2ec6adb5a4ce..40006d193687 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -238,6 +238,12 @@ values:
   - "force":
 Force the huge option on for all - very useful for testing;
 
+Tehre's limit on minimal file size before kenrel starts allocate huge
+pages for it. By default it's size of huge page.
+
+You can adjust the limit using "huge_min_size=" mount option or
+/sys/kernel/mm/transparent_hugepage/shmem_min_size for in-kernel mount.
+
 == Need of application restart ==
 
 The transparent_hugepage/enabled values and tmpfs mount option only affect
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 9b9f65d99873..515b96a5a592 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -52,6 +52,7 @@ extern ssize_t single_hugepage_flag_show(struct kobject *kobj,
struct kobj_attribute *attr, char *buf,
enum transparent_hugepage_flag flag);
 extern struct kobj_attribute shmem_enabled_attr;
+extern struct kobj_attribute shmem_min_size_attr;
 
 #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
 #define HPAGE_PMD_NR (1huge_min_size &&
+   index < (sbinfo->huge_min_size >> PAGE_SHIFT))
+   goto alloc_nohuge;
switch (sbinfo->huge) {
-   loff_t i_size;
pgoff_t off;
case SHMEM_HUGE_NEVER:
goto alloc_nohuge;
case SHMEM_HUGE_WITHIN_SIZE:
off = round_up(index, HPAGE_PMD_NR);
-   i_size = round_up(i_size_read(inode), PAGE_SIZE);
+   i_size = round_up(i_size, PAGE_SIZE);
if (i_size >= HPAGE_PMD_SIZE &&
i_size >> PAGE_SHIFT >= off)
goto alloc_huge;
@@ -3349,6 +3355,10 @@ static int shmem_parse_options(char *options, struct 
shmem_sb_info *sbinfo,
huge != SHMEM_HUGE_NEVER)
goto bad_val;
sbinfo->huge = huge;
+   } else if (!strcmp(this_char, "huge_min_size")) {
+   sbinfo->huge_min_size = memparse(value, );
+   if (*rest)
+   goto bad_val;
 #endif
 #ifdef CONFIG_NUMA
} else if 

Re: [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

[Tomi Valkeinen]

On 17/10/16 14:40, Laurent Pinchart wrote:
> Hello,
> 
> On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
>> On 17/10/16 10:12, Sekhar Nori wrote:
>>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
 On 15/10/16 20:42, Sekhar Nori wrote:
>> diff --git a/arch/arm/boot/dts/da850.dtsi
>> b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..32908ae 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -399,6 +420,14 @@
>>  < 0 1>;
>>  dma-names = "tx", "rx";
>>  };
>> +
>> +display: display@213000 {
>> +compatible = "ti,am33xx-tilcdc", 
>> "ti,da850-tilcdc";
>
> This should instead be:
>
> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>
> as the closest match should appear first in the list.

 Actually I don't think that's correct. The LCDC on da850 is not
 compatible with the LCDC on AM335x. I think it should be just
 "ti,da850-tilcdc".
>>>
>>> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
>>> the case, I wonder how the patch passed testing. Bartosz?
>>
>> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
>> similar, but different.
>>
>> The driver gets the version number from LCDC's register, and acts based
>> on that, so afaik the compatible string doesn't really affect the
>> functionality (as long as it matches).
>>
>> But even if it works with the current driver, I don't think
>> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
> 
> If the hardware provides IP revision information, how about just "ti,lcdc" ?

Maybe, and I agree that's the "correct" way, but looking at the history,
it's not just once or twice when we've suddenly found out some
difference or bug or such in an IP revision, or the integration to a
SoC, that can't be found based on the IP revision.

That's why I feel it's usually safer to have the SoC revision there in
the compatible string.

That said, we have only a few different old SoCs with LCDC (compared to,
say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.

 Tomi



signature.asc
Description: OpenPGP digital signature

[PATCH 2/3] thermal/intel_powerclamp: Convert the kthread to kthread worker API

[Petr Mladek]

Kthreads are currently implemented as an infinite loop. Each
has its own variant of checks for terminating, freezing,
awakening. In many cases it is unclear to say in which state
it is and sometimes it is done a wrong way.

The plan is to convert kthreads into kthread_worker or workqueues
API. It allows to split the functionality into separate operations.
It helps to make a better structure. Also it defines a clean state
where no locks are taken, IRQs blocked, the kthread might sleep
or even be safely migrated.

The kthread worker API is useful when we want to have a dedicated
single thread for the work. It helps to make sure that it is
available when needed. Also it allows a better control, e.g.
define a scheduling priority.

This patch converts the intel powerclamp kthreads into the kthread
worker because they need to have a good control over the assigned
CPUs.

IMHO, the most natural way is to split one cycle into two works.
First one does some balancing and let the CPU work normal
way for some time. The second work checks what the CPU has done
in the meantime and put it into C-state to reach the required
idle time ratio. The delay between the two works is achieved
by the delayed kthread work.

The two works have to share some data that used to be local
variables of the single kthread function. This is achieved
by the new per-CPU struct kthread_worker_data. It might look
as a complication. On the other hand, the long original kthread
function was not nice either.

The patch tries to avoid extra init and cleanup works. All the
actions might be done outside the thread. They are moved
to the functions that create or destroy the worker. Especially,
I checked that the timers are assigned to the right CPU.

The two works are queuing each other. It makes it a bit tricky to
break it when we want to stop the worker. We use the global and
per-worker "clamping" variables to make sure that the re-queuing
eventually stops. We also cancel the works to make it faster.
Note that the canceling is not reliable because the handling
of the two variables and queuing is not synchronized via a lock.
But it is not a big deal because it is just an optimization.
The job is stopped faster than before in most cases.

Signed-off-by: Petr Mladek 
CC: Zhang Rui 
CC: Eduardo Valentin 
CC: Jacob Pan 
CC: Sebastian Andrzej Siewior 
CC: linux...@vger.kernel.org
Acked-by: Jacob Pan 
---
 drivers/thermal/intel_powerclamp.c | 292 +
 1 file changed, 170 insertions(+), 122 deletions(-)

diff --git a/drivers/thermal/intel_powerclamp.c 
b/drivers/thermal/intel_powerclamp.c
index 63657d193db5..a94f7c849a4e 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -86,11 +86,27 @@
  */
 static bool clamping;
 
+static const struct sched_param sparam = {
+   .sched_priority = MAX_USER_RT_PRIO / 2,
+};
+struct powerclamp_worker_data {
+   struct kthread_worker *worker;
+   struct kthread_work balancing_work;
+   struct kthread_delayed_work idle_injection_work;
+   struct timer_list wakeup_timer;
+   unsigned int cpu;
+   unsigned int count;
+   unsigned int guard;
+   unsigned int window_size_now;
+   unsigned int target_ratio;
+   unsigned int duration_jiffies;
+   bool clamping;
+};
 
-static struct task_struct * __percpu *powerclamp_thread;
+static struct powerclamp_worker_data * __percpu worker_data;
 static struct thermal_cooling_device *cooling_dev;
 static unsigned long *cpu_clamping_mask;  /* bit map for tracking per cpu
-  * clamping thread
+  * clamping kthread worker
   */
 
 static unsigned int duration;
@@ -368,103 +384,104 @@ static bool powerclamp_adjust_controls(unsigned int 
target_ratio,
return set_target_ratio + guard <= current_ratio;
 }
 
-static int clamp_thread(void *arg)
+static void clamp_balancing_func(struct kthread_work *work)
 {
-   int cpunr = (unsigned long)arg;
-   DEFINE_TIMER(wakeup_timer, noop_timer, 0, 0);
-   static const struct sched_param param = {
-   .sched_priority = MAX_USER_RT_PRIO/2,
-   };
-   unsigned int count = 0;
-   unsigned int target_ratio;
+   struct powerclamp_worker_data *w_data;
+   int sleeptime;
+   unsigned long target_jiffies;
+   unsigned int compensated_ratio;
+   int interval; /* jiffies to sleep for each attempt */
 
-   set_bit(cpunr, cpu_clamping_mask);
-   set_freezable();
-   init_timer_on_stack(_timer);
-   sched_setscheduler(current, SCHED_FIFO, );
-
-   while (true == clamping && !kthread_should_stop() &&
-   cpu_online(cpunr)) {
-   int sleeptime;
-   unsigned long target_jiffies;
-   unsigned int guard;
-   unsigned int compensated_ratio;
-   int interval; 

[PATCH 3/3] thermal/intel_powerclamp: Convert to CPU hotplug state

[Petr Mladek]

From: Sebastian Andrzej Siewior 

This is a conversation to the new hotplug state machine with
the difference that CPU_DEAD becomes CPU_PREDOWN.

At the same time it makes the handling of the two states symmetrical.
stop_power_clamp_worker() is called unconditionally and the controversial
error message is removed.

Finally, the hotplug state callbacks are removed after the powerclamping
is stopped to avoid a potential race.

Signed-off-by: Sebastian Andrzej Siewior 
[pmla...@suse.com: Fixed the possible race in powerclamp_exit()]
Signed-off-by: Petr Mladek 
---
 drivers/thermal/intel_powerclamp.c | 69 +++---
 1 file changed, 35 insertions(+), 34 deletions(-)

diff --git a/drivers/thermal/intel_powerclamp.c 
b/drivers/thermal/intel_powerclamp.c
index a94f7c849a4e..390e50b97324 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -622,43 +622,35 @@ static void end_power_clamp(void)
}
 }
 
-static int powerclamp_cpu_callback(struct notifier_block *nfb,
-   unsigned long action, void *hcpu)
+static int powerclamp_cpu_online(unsigned int cpu)
 {
-   unsigned long cpu = (unsigned long)hcpu;
+   if (clamping == false)
+   return 0;
+   start_power_clamp_worker(cpu);
+   /* prefer BSP as controlling CPU */
+   if (cpu == 0) {
+   control_cpu = 0;
+   smp_mb();
+   }
+   return 0;
+}
 
-   if (false == clamping)
-   goto exit_ok;
+static int powerclamp_cpu_predown(unsigned int cpu)
+{
+   if (clamping == false)
+   return 0;
 
-   switch (action) {
-   case CPU_ONLINE:
-   start_power_clamp_worker(cpu);
-   /* prefer BSP as controlling CPU */
-   if (cpu == 0) {
-   control_cpu = 0;
-   smp_mb();
-   }
-   break;
-   case CPU_DEAD:
-   if (test_bit(cpu, cpu_clamping_mask)) {
-   pr_err("cpu %lu dead but powerclamping thread is not\n",
-   cpu);
-   stop_power_clamp_worker(cpu);
-   }
-   if (cpu == control_cpu) {
-   control_cpu = smp_processor_id();
-   smp_mb();
-   }
-   }
+   stop_power_clamp_worker(cpu);
+   if (cpu != control_cpu)
+   return 0;
 
-exit_ok:
-   return NOTIFY_OK;
+   control_cpu = cpumask_first(cpu_online_mask);
+   if (control_cpu == cpu)
+   control_cpu = cpumask_next(cpu, cpu_online_mask);
+   smp_mb();
+   return 0;
 }
 
-static struct notifier_block powerclamp_cpu_notifier = {
-   .notifier_call = powerclamp_cpu_callback,
-};
-
 static int powerclamp_get_max_state(struct thermal_cooling_device *cdev,
 unsigned long *state)
 {
@@ -788,6 +780,8 @@ static inline void powerclamp_create_debug_files(void)
debugfs_remove_recursive(debug_dir);
 }
 
+static enum cpuhp_state hp_state;
+
 static int __init powerclamp_init(void)
 {
int retval;
@@ -805,7 +799,14 @@ static int __init powerclamp_init(void)
 
/* set default limit, maybe adjusted during runtime based on feedback */
window_size = 2;
-   register_hotcpu_notifier(_cpu_notifier);
+   retval = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
+  "thermal/intel_powerclamp:online",
+  powerclamp_cpu_online,
+  powerclamp_cpu_predown);
+   if (retval < 0)
+   goto exit_free;
+
+   hp_state = retval;
 
worker_data = alloc_percpu(struct powerclamp_worker_data);
if (!worker_data) {
@@ -830,7 +831,7 @@ static int __init powerclamp_init(void)
 exit_free_thread:
free_percpu(worker_data);
 exit_unregister:
-   unregister_hotcpu_notifier(_cpu_notifier);
+   cpuhp_remove_state_nocalls(hp_state);
 exit_free:
kfree(cpu_clamping_mask);
return retval;
@@ -839,8 +840,8 @@ static int __init powerclamp_init(void)
 
 static void __exit powerclamp_exit(void)
 {
-   unregister_hotcpu_notifier(_cpu_notifier);
end_power_clamp();
+   cpuhp_remove_state_nocalls(hp_state);
free_percpu(worker_data);
thermal_cooling_device_unregister(cooling_dev);
kfree(cpu_clamping_mask);
-- 
1.8.5.6

[PATCH 0/3] thermal/intel_powerclamp: Conversion to kthread worker API and new CPU hotplug state

[Petr Mladek]

The kthread worker API enhancements are in 4.9-rc1. Therefore
we could finally convert the intel_powerclamp kthreads to it.

The API hides a rather tricky code for the sleeping, freezing,
and exiting checks. It should help to avoid races and maintain
these operations.

Sebastian asked me to send also the conversion to the new
CPU hotplug state machine on top of the kthread conversion.

IMPORTANT: 

I have tested this on top of 4.9-rc1. But I needed to add
("sched/fair: Fix sched domains NULL deference in select_idle_sibling()")
from linux-tip, see
https://lkml.kernel.org/r/tip-9cfb38a7ba5a9c27c1af8093fb1af4b699c0a...@git.kernel.org
Otherwise, the CPU hotplug failed very often.


Petr Mladek (2):
  thermal/intel_powerclamp: Remove duplicated code that starts the
kthread
  thermal/intel_powerclamp: Convert the kthread to kthread worker API

Sebastian Andrzej Siewior (1):
  thermal/intel_powerclamp: Convert to CPU hotplug state

 drivers/thermal/intel_powerclamp.c | 374 +
 1 file changed, 209 insertions(+), 165 deletions(-)

-- 
1.8.5.6

[PATCH 1/3] thermal/intel_powerclamp: Remove duplicated code that starts the kthread

[Petr Mladek]

This patch removes a code duplication. It does not modify
the functionality.

Signed-off-by: Petr Mladek 
CC: Zhang Rui 
CC: Eduardo Valentin 
CC: Jacob Pan 
CC: Sebastian Andrzej Siewior 
CC: linux...@vger.kernel.org
Acked-by: Jacob Pan 
---
 drivers/thermal/intel_powerclamp.c | 45 +-
 1 file changed, 20 insertions(+), 25 deletions(-)

diff --git a/drivers/thermal/intel_powerclamp.c 
b/drivers/thermal/intel_powerclamp.c
index 0e4dc0afcfd2..63657d193db5 100644
--- a/drivers/thermal/intel_powerclamp.c
+++ b/drivers/thermal/intel_powerclamp.c
@@ -508,10 +508,27 @@ static void poll_pkg_cstate(struct work_struct *dummy)
schedule_delayed_work(_pkg_cstate_work, HZ);
 }
 
+static void start_power_clamp_thread(unsigned long cpu)
+{
+   struct task_struct **p = per_cpu_ptr(powerclamp_thread, cpu);
+   struct task_struct *thread;
+
+   thread = kthread_create_on_node(clamp_thread,
+   (void *) cpu,
+   cpu_to_node(cpu),
+   "kidle_inject/%ld", cpu);
+   if (IS_ERR(thread))
+   return;
+
+   /* bind to cpu here */
+   kthread_bind(thread, cpu);
+   wake_up_process(thread);
+   *p = thread;
+}
+
 static int start_power_clamp(void)
 {
unsigned long cpu;
-   struct task_struct *thread;
 
set_target_ratio = clamp(set_target_ratio, 0U, MAX_TARGET_RATIO - 1);
/* prevent cpu hotplug */
@@ -527,20 +544,7 @@ static int start_power_clamp(void)
 
/* start one thread per online cpu */
for_each_online_cpu(cpu) {
-   struct task_struct **p =
-   per_cpu_ptr(powerclamp_thread, cpu);
-
-   thread = kthread_create_on_node(clamp_thread,
-   (void *) cpu,
-   cpu_to_node(cpu),
-   "kidle_inject/%ld", cpu);
-   /* bind to cpu here */
-   if (likely(!IS_ERR(thread))) {
-   kthread_bind(thread, cpu);
-   wake_up_process(thread);
-   *p = thread;
-   }
-
+   start_power_clamp_thread(cpu);
}
put_online_cpus();
 
@@ -572,7 +576,6 @@ static int powerclamp_cpu_callback(struct notifier_block 
*nfb,
unsigned long action, void *hcpu)
 {
unsigned long cpu = (unsigned long)hcpu;
-   struct task_struct *thread;
struct task_struct **percpu_thread =
per_cpu_ptr(powerclamp_thread, cpu);
 
@@ -581,15 +584,7 @@ static int powerclamp_cpu_callback(struct notifier_block 
*nfb,
 
switch (action) {
case CPU_ONLINE:
-   thread = kthread_create_on_node(clamp_thread,
-   (void *) cpu,
-   cpu_to_node(cpu),
-   "kidle_inject/%lu", cpu);
-   if (likely(!IS_ERR(thread))) {
-   kthread_bind(thread, cpu);
-   wake_up_process(thread);
-   *percpu_thread = thread;
-   }
+   start_power_clamp_thread(cpu);
/* prefer BSP as controlling CPU */
if (cpu == 0) {
control_cpu = 0;
-- 
1.8.5.6

Re: [PATCH] usb: ehci-platform: increase EHCI_MAX_RSTS to 4

[Greg Kroah-Hartman]

On Mon, Oct 17, 2016 at 08:11:59PM +0900, Masahiro Yamada wrote:
> Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
> needs to handle 4 reset lines for EHCI.

Why?  What makes it different from other EHCI implementations?

thanks,

greg k-h

[PATCH] lpfc: use %zd format string for size_t

[Arnd Bergmann]

A recent bugfix introduced a harmless warning in the lpfc driver:

drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware':
drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error: format '%ld' expects argument of 
type 'long int', but argument 9 has type 'size_t {aka const unsigned int}' 
[-Werror=format=]

'size_t' is always the same width as 'long' in the kernel, but the compiler
doesn't know that. The %z modifier is what the standard expects to be
used here, and this shuts up the warning.

Fixes: 679053c651fb ("scsi: lpfc: Fix fw download on SLI-4 FC adapters")
Signed-off-by: Arnd Bergmann 
---
 drivers/scsi/lpfc/lpfc_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 7be9b8a7bb19..4776fd85514f 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -10332,7 +10332,7 @@ lpfc_write_firmware(const struct firmware *fw, void 
*context)
ftype != LPFC_FILE_TYPE_GROUP || fsize != fw->size) {
lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
"3022 Invalid FW image found. "
-   "Magic:%x Type:%x ID:%x Size %d %ld\n",
+   "Magic:%x Type:%x ID:%x Size %d %zd\n",
magic_number, ftype, fid, fsize, fw->size);
rc = -EINVAL;
goto release_out;
-- 
2.9.0

[PATCH] rtc: cmos: remove all __exit_p annotations

[Corentin Labbe]

I got the following stack trace under qemu:
[7.575243] BUG: unable to handle kernel NULL pointer dereference at 
0010
[7.596098] IP: [] cmos_set_alarm+0x38/0x280
[7.615699] PGD 3ccbe067
[7.615923] PUD 3daf2067
[7.635156] PMD 0

[7.654358] Oops:  [#1] SMP
[7.673869] Modules linked in:
[7.693235] CPU: 0 PID: 1701 Comm: hwclock Tainted: GW   
4.9.0-rc1+ #24
[7.712455] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
[7.753569] task: 88003d88dc40 task.stack: c9224000
[7.773743] RIP: 0010:[]  [] 
cmos_set_alarm+0x38/0x280
[7.794893] RSP: 0018:c9227c10  EFLAGS: 00010296
[7.815890] RAX: 001d RBX: c9227d28 RCX: 8182be78
[7.836057] RDX: 0001 RSI: 0202 RDI: 0202
[7.856612] RBP: c9227c48 R08:  R09: 0001
[7.877561] R10: 01c0 R11: 01c0 R12: 
[7.897072] R13: 88003d96f400 R14: 88003dac6410 R15: 88003dac6420
[7.917403] FS:  7f77f42d9700() GS:88003fc0() 
knlGS:
[7.938293] CS:  0010 DS:  ES:  CR0: 80050033
[7.958364] CR2: 0010 CR3: 3ccbb000 CR4: 06f0
[7.978028] Stack:
[7.997120]  88003dac6000 88003dac6410 58049d01 
c9227d28
[8.016993]  88003dac6000 88003dac6410 88003dac6420 
c9227c98
[8.039505]  814f225d 001800227c98 0009002a 
00090011
[8.059985] Call Trace:
[8.080110]  [] __rtc_set_alarm+0x8d/0xa0
[8.099421]  [] rtc_timer_enqueue+0x119/0x190
[8.119925]  [] rtc_update_irq_enable+0xbe/0x100
[8.140583]  [] rtc_dev_ioctl+0x3c0/0x480
[8.161162]  [] ? user_path_at_empty+0x3a/0x50
[8.182717]  [] do_vfs_ioctl+0x96/0x5c0
[8.204624]  [] ? vfs_stat+0x16/0x20
[8.225994]  [] ? SyS_newstat+0x15/0x30
[8.247043]  [] SyS_ioctl+0x47/0x80
[8.267191]  [] entry_SYSCALL_64_fastpath+0x1a/0xa9
[8.288719] Code: 6a 81 48 89 e5 41 57 41 56 41 55 49 89 fd 41 54 53 48 89 
f3 48 c7 c6 20 c4 78 81 48 83 ec 10 e8 8f 00 ef ff 4d 8b a5 a0 00 00 00 <41> 8b 
44 24 10 85 c0 0f 8e 2b 02 00 00 4c 89 ef 31 c0 b9 53 01
[8.335233] RIP  [] cmos_set_alarm+0x38/0x280
[8.357096]  RSP 
[8.379051] CR2: 0010
[8.401736] ---[ end trace 5cbcd83a1f225ed3 ]---

This occur only when CONFIG_DEBUG_TEST_DRIVER_REMOVE is enabled and
CONFIG_RTC_DRV_CMOS builtin.

When cmos_set_alarm() is called dev is NULL and so trigger the deref via
cmos->irq

The problem comes from that the device is removed but no remove function
are called due to _exit_p().

This patch remove all _exit_p() annotation.

Signed-off-by: Corentin Labbe 
---
 drivers/rtc/rtc-cmos.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index dd3d598..b1f3d64 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -776,7 +776,7 @@ static void cmos_do_shutdown(int rtc_irq)
spin_unlock_irq(_lock);
 }
 
-static void __exit cmos_do_remove(struct device *dev)
+static void cmos_do_remove(struct device *dev)
 {
struct cmos_rtc *cmos = dev_get_drvdata(dev);
struct resource *ports;
@@ -1129,7 +1129,7 @@ static int cmos_pnp_probe(struct pnp_dev *pnp, const 
struct pnp_device_id *id)
pnp_irq(pnp, 0));
 }
 
-static void __exit cmos_pnp_remove(struct pnp_dev *pnp)
+static void cmos_pnp_remove(struct pnp_dev *pnp)
 {
cmos_do_remove(>dev);
 }
@@ -1161,7 +1161,7 @@ static struct pnp_driver cmos_pnp_driver = {
.name   = (char *) driver_name,
.id_table   = rtc_ids,
.probe  = cmos_pnp_probe,
-   .remove = __exit_p(cmos_pnp_remove),
+   .remove = cmos_pnp_remove,
.shutdown   = cmos_pnp_shutdown,
 
/* flag ensures resume() gets called, and stops syslog spam */
@@ -1238,7 +1238,7 @@ static int __init cmos_platform_probe(struct 
platform_device *pdev)
return cmos_do_probe(>dev, resource, irq);
 }
 
-static int __exit cmos_platform_remove(struct platform_device *pdev)
+static int cmos_platform_remove(struct platform_device *pdev)
 {
cmos_do_remove(>dev);
return 0;
@@ -1263,7 +1263,7 @@ static void cmos_platform_shutdown(struct platform_device 
*pdev)
 MODULE_ALIAS("platform:rtc_cmos");
 
 static struct platform_driver cmos_platform_driver = {
-   .remove = __exit_p(cmos_platform_remove),
+   .remove = cmos_platform_remove,
.shutdown   = cmos_platform_shutdown,
.driver = {
.name   = driver_name,
@@ -1305,7 +1305,7 @@ static int __init cmos_init(void)
 }
 module_init(cmos_init);
 
-static void __exit cmos_exit(void)
+static void 

Re: ARM64-cpuinfo: Combine six calls for sequence output into one seq_printf() call in c_show()

[Mark Rutland]

On Mon, Oct 17, 2016 at 01:30:59PM +0200, SF Markus Elfring wrote:
> >> Some data were printed into a sequence by six separate function calls.
> >> Print the same data by a single function call instead.
> > 
> > ... why?
> > 
> > Beyond simply having fewer function calls, is there an upside?
> 
> Will it matter to improve run time characteristics at this source code
> place?

I do not know. If that's not the aim of your existing patch, then I have
no idea what you're trying to achieve.

> > This makes it harder to see the relationship between the format strings
> > and their associated data, and makes the code longer.
> 
> Do you prefer an other layout for the passed data so that the increase
> of line count in my update suggestion would look differently?

I prefer the code as-is. Unless there's a compelling reason to change
it.

Thanks,
Mark.

[RFC PATCH 0/3] ARM: dts: oxnas: Update support for OX820 and use dt-bindings

[Neil Armstrong]

This patchset updates the ARM DTS for the Oxnas platform by :
- Add support for the Oxford Semicondutor OX820 and the PogoPlug V3
- Update the OX810SE to use the dt-bindings includes files introduced in [1] 
and [2]
- Fix the MAINTAINERS entry and add the PogoPlug V3 file maintainance

This patchset remains RFC until dependent patches [1] and [2] are merged.

[1] 
https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg8.html
[2] 
https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg7.html

Neil Armstrong (3):
  ARM: dts: Add support for OX820 and Pogoplug V3
  ARM: dts: OX810: Update with dt-bindings includes
  MAINTAINERS: oxnas: Add new files definitions

 Documentation/devicetree/bindings/arm/oxnas.txt|   5 +
 MAINTAINERS|   3 +-
 arch/arm/boot/dts/Makefile |   3 +-
 .../boot/dts/cloudengines-pogoplug-series-3.dts|  60 +
 arch/arm/boot/dts/ox810se.dtsi |  10 +-
 arch/arm/boot/dts/ox820.dtsi   | 259 +
 6 files changed, 334 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
 create mode 100644 arch/arm/boot/dts/ox820.dtsi

-- 
2.7.0

[RFC PATCH 3/3] MAINTAINERS: oxnas: Add new files definitions

[Neil Armstrong]

Fix the dts files maintained by the OXNAS platform, add a new board.

Signed-off-by: Neil Armstrong 
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 71aa5da..9f4bc60 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1444,8 +1444,9 @@ M:Neil Armstrong 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-oxnas/
-F: arch/arm/boot/dts/oxnas*
+F: arch/arm/boot/dts/ox8*.dtsi
 F: arch/arm/boot/dts/wd-mbwe.dts
+F: arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
 N: oxnas
 
 ARM/Mediatek RTC DRIVER
-- 
2.7.0

[RFC PATCH 1/3] ARM: dts: Add support for OX820 and Pogoplug V3

[Neil Armstrong]

Add device tree for the Oxford Seminconductor OX820 SoC and the
Cloud Engines PogoPlug v3 board.
Add the SoC and board compatible strings to oxnas bindings.

Signed-off-by: Neil Armstrong 
---
 Documentation/devicetree/bindings/arm/oxnas.txt|   5 +
 arch/arm/boot/dts/Makefile |   3 +-
 .../boot/dts/cloudengines-pogoplug-series-3.dts|  60 +
 arch/arm/boot/dts/ox820.dtsi   | 259 +
 4 files changed, 326 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
 create mode 100644 arch/arm/boot/dts/ox820.dtsi

diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt 
b/Documentation/devicetree/bindings/arm/oxnas.txt
index b9e4971..ac64e60 100644
--- a/Documentation/devicetree/bindings/arm/oxnas.txt
+++ b/Documentation/devicetree/bindings/arm/oxnas.txt
@@ -5,5 +5,10 @@ Boards with the OX810SE SoC shall have the following 
properties:
   Required root node property:
 compatible: "oxsemi,ox810se"
 
+Boards with the OX820 SoC shall have the following properties:
+  Required root node property:
+compatible: "oxsemi,ox820"
+
 Board compatible values:
   - "wd,mbwe" (OX810SE)
+  - "cloudengines,pogoplugv3" (OX820)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index faacd52..5d9e8d5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -588,7 +588,8 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
 dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
 dtb-$(CONFIG_ARCH_OXNAS) += \
-   wd-mbwe.dtb
+   wd-mbwe.dtb \
+   cloudengines-pogoplug-series-3.dtb
 dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8060-dragonboard.dtb \
qcom-apq8064-arrow-sd-600eval.dtb \
diff --git a/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts 
b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
new file mode 100644
index 000..78d9149
--- /dev/null
+++ b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
@@ -0,0 +1,60 @@
+/*
+ * cloudengines-pogoplug-series-3.dtsi - Device tree file for Cloud Engines 
PogoPlug Series 3
+ *
+ * Copyright (C) 2016 Neil Armstrong 
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+#include "ox820.dtsi"
+
+/ {
+   model = "Cloud Engines PogoPlug Series 3";
+
+   compatible = "cloudengines,pogoplugv3", "oxsemi,ox820";
+
+   chosen {
+   bootargs = "console=ttyS0,115200n8 earlyprintk=serial";
+   };
+
+   memory {
+   /* 128Mbytes DDR */
+   reg = <0x6000 0x800>;
+   };
+
+   aliases {
+   serial0 = 
+   gpio0 = 
+   gpio1 = 
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   blue {
+   label = "pogoplug:blue";
+   gpios = < 2 0>;
+   default-state = "keep";
+   };
+
+   orange {
+   label = "pogoplug:orange";
+   gpios = < 16 1>;
+   default-state = "keep";
+   };
+
+   green {
+   label = "pogoplug:green";
+   gpios = < 17 1>;
+   default-state = "keep";
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart0>;
+};
diff --git a/arch/arm/boot/dts/ox820.dtsi b/arch/arm/boot/dts/ox820.dtsi
new file mode 100644
index 000..fe251f180
--- /dev/null
+++ b/arch/arm/boot/dts/ox820.dtsi
@@ -0,0 +1,259 @@
+/*
+ * ox820.dtsi - Device tree file for Oxford Semiconductor OX820 SoC
+ *
+ * Copyright (C) 2016 Neil Armstrong 
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "oxsemi,ox820";
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "oxsemi,ox820-smp";
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,arm11mpcore";
+   clocks = <>;
+   reg = <0>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,arm11mpcore";
+   clocks = <>;
+   reg = <1>;
+   };
+   };
+
+   memory {
+   /* Max 512MB @ 0x6000 */
+   reg = <0x6000 0x2000>;
+   };
+
+   clocks {
+   osc: oscillator {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2500>;
+   };
+
+   gmacclk: gmacclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <12500>;
+   };
+

[RFC PATCH 2/3] ARM: dts: OX810: Update with dt-bindings includes

[Neil Armstrong]

Add OX810SE dt-bindings includes files for clocks and resets, replace
resets numbers by human readable defines.

Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/ox810se.dtsi | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/ox810se.dtsi b/arch/arm/boot/dts/ox810se.dtsi
index ce13705..46aa6db 100644
--- a/arch/arm/boot/dts/ox810se.dtsi
+++ b/arch/arm/boot/dts/ox810se.dtsi
@@ -7,6 +7,8 @@
  */
 
 /include/ "skeleton.dtsi"
+#include 
+#include 
 
 / {
compatible = "oxsemi,ox810se";
@@ -242,7 +244,7 @@
   current-speed = <115200>;
   no-loopback-test;
   status = "disabled";
-  resets = < 17>;
+  resets = < RESET_UART1>;
};
 
uart1: serial@30 {
@@ -256,7 +258,7 @@
   current-speed = <115200>;
   no-loopback-test;
   status = "disabled";
-  resets = < 18>;
+  resets = < RESET_UART2>;
};
 
uart2: serial@90 {
@@ -270,7 +272,7 @@
   current-speed = <115200>;
   no-loopback-test;
   status = "disabled";
-  resets = < 22>;
+  resets = < RESET_UART3>;
};
 
uart3: serial@a0 {
@@ -284,7 +286,7 @@
   current-speed = <115200>;
   no-loopback-test;
   status = "disabled";
-  resets = < 23>;
+  resets = < RESET_UART4>;
};
};
 
-- 
2.7.0

Re: [PATCH] rtc: cmos: remove all __exit_p annotations

[Lars-Peter Clausen]

> -static void __exit cmos_exit(void)
> +static void cmos_exit(void)

This annotation is correct and should stay.

>  {
>  #ifdef   CONFIG_PNP
>   if (pnp_driver_registered)
> 

Re: [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

[Laurent Pinchart]

Hi Tomi,

On Monday 17 Oct 2016 15:29:23 Tomi Valkeinen wrote:
> On 17/10/16 14:40, Laurent Pinchart wrote:
> > On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
> >> On 17/10/16 10:12, Sekhar Nori wrote:
> >>> On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
>  On 15/10/16 20:42, Sekhar Nori wrote:
> >> diff --git a/arch/arm/boot/dts/da850.dtsi
> >> b/arch/arm/boot/dts/da850.dtsi
> >> index f79e1b9..32908ae 100644
> >> --- a/arch/arm/boot/dts/da850.dtsi
> >> +++ b/arch/arm/boot/dts/da850.dtsi
> >> @@ -399,6 +420,14 @@
> >>< 0 1>;
> >>dma-names = "tx", "rx";
> >>};
> >> +
> >> +  display: display@213000 {
> >> +  compatible = "ti,am33xx-tilcdc", "ti,da850-
tilcdc";
> > 
> > This should instead be:
> > 
> > compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
> > 
> > as the closest match should appear first in the list.
>  
>  Actually I don't think that's correct. The LCDC on da850 is not
>  compatible with the LCDC on AM335x. I think it should be just
>  "ti,da850-tilcdc".
> >>> 
> >>> So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
> >>> the case, I wonder how the patch passed testing. Bartosz?
> >> 
> >> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
> >> similar, but different.
> >> 
> >> The driver gets the version number from LCDC's register, and acts based
> >> on that, so afaik the compatible string doesn't really affect the
> >> functionality (as long as it matches).
> >> 
> >> But even if it works with the current driver, I don't think
> >> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
> > 
> > If the hardware provides IP revision information, how about just "ti,lcdc"
> > ?
>
> Maybe, and I agree that's the "correct" way, but looking at the history,
> it's not just once or twice when we've suddenly found out some
> difference or bug or such in an IP revision, or the integration to a
> SoC, that can't be found based on the IP revision.
> 
> That's why I feel it's usually safer to have the SoC revision there in
> the compatible string.
> 
> That said, we have only a few different old SoCs with LCDC (compared to,
> say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.

You obviously know more than I do on this topic so I'll trust your opinion. If 
the version register isn't enough I'm fine with multiple compatible strings.

-- 
Regards,

Laurent Pinchart

Re: [PATCHv2 4/4] arm64: dump: Add checking for writable and exectuable pages

[Mark Rutland]

On Wed, Oct 12, 2016 at 03:32:02PM -0700, Laura Abbott wrote:
> +config DEBUG_WX
> + bool "Warn on W+X mappings at boot"
> + select ARM64_PTDUMP_CORE
> + ---help---
> +   Generate a warning if any W+X mappings are found at boot.
> +
> +   This is useful for discovering cases where the kernel is leaving
> +   W+X mappings after applying NX, as such mappings are a security risk.
> +   This check also includes UXN, which should be set on all kernel
> +   mappings.
> +
> +   Look for a message in dmesg output like this:
> +
> + arm64/mm: Checked W+X mappings: passed, no W+X pages found.
> +
> +   or like this, if the check failed:
> +
> + arm64/mm: Checked W+X mappings: FAILED,  W+X pages found.
> +
> +   Note that even if the check fails, your kernel is possibly
> +   still fine, as W+X mappings are not a security hole in
> +   themselves, what they do is that they make the exploitation
> +   of other unfixed kernel bugs easier.
> +
> +   There is no runtime or memory usage effect of this option
> +   once the kernel has booted up - it's a one time check.
> +
> +   If in doubt, say "Y".
> +
> +

Trivial nit: for consistency with the rest of the file, there should
only be one line space between options.

>  config DEBUG_SET_MODULE_RONX
>   bool "Set loadable kernel module data as NX and text as RO"
>   depends on MODULES
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index 8fc0957..6afd847 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -42,5 +42,13 @@ static inline int ptdump_debugfs_register(struct 
> ptdump_info *info,
>   return 0;
>  }
>  #endif
> +void ptdump_check_wx(void);
> +#endif /* CONFIG_ARM64_PTDUMP_CORE */

... ah, here's the missing #endif from patch 1.

Assuming that gets sorted out, this looks good to me, and works on juno,
so FWIW:

Reviewed-by: Mark Rutland 
Tested-by: Mark Rutland 

[...]

> +static void note_prot_uxn(struct pg_state *st, unsigned long addr)
> +{
> + if (!st->check_wx)
> + return;
> +
> + if ((st->current_prot & PTE_UXN) == PTE_UXN)
> + return;
> +
> + WARN_ONCE(1, "arm64/mm: Found non-UXN mapping at address %p/%pS\n",
> +   (void *)st->start_address, (void *)st->start_address);
> +
> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
> +}

As a future thought (I've scope-creeped this enough with the UXN check),
there are some other checks that we could add, like verifying the AP
bits don't allow user data access. That might be worth considering, with
DEBUG_WX becoming a more general kernel page table sanity check.

Thanks,
Mark.

[PATCH] spi: dspi: clear SPI_SR before enable interrupt

[Yuan Yao]

From: Yuan Yao 

Once dspi is used in uboot, the SPI_SR have been set by some value.
At this time, if kernel enable the interrupt before clear the
status flag, that will trigger the wrong interrupt.

Signed-off-by: Yuan Yao 
---
 drivers/spi/spi-fsl-dspi.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 35c0dd9..a67b0ff 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -70,6 +70,7 @@
 #define SPI_SR 0x2c
 #define SPI_SR_EOQF0x1000
 #define SPI_SR_TCFQF   0x8000
+#define SPI_SR_CLEAR   0xdaad
 
 #define SPI_RSER   0x30
 #define SPI_RSER_EOQFE 0x1000
@@ -646,6 +647,11 @@ static const struct regmap_config dspi_regmap_config = {
.max_register = 0x88,
 };
 
+static void dspi_init(struct fsl_dspi *dspi)
+{
+   regmap_write(dspi->regmap, SPI_SR, SPI_SR_CLEAR);
+}
+
 static int dspi_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
@@ -709,6 +715,7 @@ static int dspi_probe(struct platform_device *pdev)
return PTR_ERR(dspi->regmap);
}
 
+   dspi_init(dspi);
dspi->irq = platform_get_irq(pdev, 0);
if (dspi->irq < 0) {
dev_err(>dev, "can't get platform irq\n");
-- 
2.1.0.27.g96db324

linux-next: Moving mmc tree to kernel.org

[Ulf Hansson]

Hi Stephen,

I have moved my mmc tree from linaro.org to kernel.org and I would
appreciate if you could switch to pull my next branch for linux-next
from there instead.

Old tree:
git://git.linaro.org/people/ulf.hansson/mmc.git next

New tree
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next

Kind regards
Uffe

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

[Balbir Singh]

On 17/10/16 23:24, Michael Ellerman wrote:
> Tejun Heo  writes:
> 
>> Hello, Michael.
>>
>> On Tue, Oct 11, 2016 at 10:22:13PM +1100, Michael Ellerman wrote:
>>> The oops happens because we're in enqueue_task_fair() and p->se->cfs_rq
>>> is NULL.
>>>
>>> The cfs_rq is NULL because we did set_task_rq(p, 2048), where 2048 is
>>> NR_CPUS. That causes us to index past the end of the tg->cfs_rq array in
>>> set_task_rq() and happen to get NULL.
>>>
>>> We never should have done set_task_rq(p, 2048), because 2048 is >=
>>> nr_cpu_ids, which means it's not a valid CPU number, and set_task_rq()
>>> doesn't cope with that.
>>
>> Hmm... it doesn't reproduce it here and can't see how the commit would
>> affect this given that it doesn't really change when the kworker
>> kthreads are being created.
> 
> It changes when the pool attributes are created, which is the source of
> the bug.
> 
> The original crash happens because we have a task with an empty cpus_allowed
> mask. That mask originally comes from pool->attrs->cpumask.
> 
> The attrs for the pool are created early via workqueue_init_early() in
> apply_wqattrs_prepare():
> 
>   start_here_common
>   -> start_kernel
>  -> workqueue_init_early
> -> __alloc_workqueue_key
>-> apply_workqueue_attrs
>   -> apply_workqueue_attrs_locked
>  -> apply_wqattrs_prepare
> 
> In there we do:
> 
>   copy_workqueue_attrs(new_attrs, attrs);
>   cpumask_and(new_attrs->cpumask, new_attrs->cpumask, wq_unbound_cpumask);
>   if (unlikely(cpumask_empty(new_attrs->cpumask)))
>   cpumask_copy(new_attrs->cpumask, wq_unbound_cpumask);
>   ...
>   copy_workqueue_attrs(tmp_attrs, new_attrs);
>   ...
>   for_each_node(node) {
>   if (wq_calc_node_cpumask(new_attrs, node, -1, 
> tmp_attrs->cpumask)) {
> + BUG_ON(cpumask_empty(tmp_attrs->cpumask));
>   ctx->pwq_tbl[node] = alloc_unbound_pwq(wq, tmp_attrs);
> 
> 
> The bad case (where we hit the BUG_ON I added above) is where we are
> creating a wq for node 1.
> 
> In wq_calc_node_cpumask() we do:
> 
>   cpumask_and(cpumask, attrs->cpumask, wq_numa_possible_cpumask[node]);
>   return !cpumask_equal(cpumask, attrs->cpumask);
> 
> Which with the arguments inserted is:
> 
>   cpumask_and(tmp_attrs->cpumask, new_attrs->cpumask, 
> wq_numa_possible_cpumask[1]);
>   return !cpumask_equal(tmp_attrs->cpumask, new_attrs->cpumask);
> 
> And that results in tmp_attrs->cpumask being empty, because
> wq_numa_possible_cpumask[1] is an empty cpumask.
> 
> The reason wq_numa_possible_cpumask[1] is an empty mask is because in
> wq_numa_init() we did:
> 
>   for_each_possible_cpu(cpu) {
>   node = cpu_to_node(cpu);
>   if (WARN_ON(node == NUMA_NO_NODE)) {
>   pr_warn("workqueue: NUMA node mapping not available for 
> cpu%d, disabling NUMA support\n", cpu);
>   /* happens iff arch is bonkers, let's just proceed */
>   return;
>   }
>   cpumask_set_cpu(cpu, tbl[node]);
>   }
> 
> And cpu_to_node() returned node 0 for every CPU in the system, despite there
> being multiple nodes.
> 
> That happened because we haven't yet called set_cpu_numa_node() for the 
> non-boot
> cpus, because that happens in smp_prepare_cpus(), and
> workqueue_init_early() is called much earlier than that.
> 
> This doesn't trigger on x86 because it does set_cpu_numa_node() in
> setup_per_cpu_areas(), which is called prior to workqueue_init_early().
> 
> We can (should) probably do the same on powerpc, I'll look at that
> tomorrow. But other arches may have a similar problem, and at the very
> least we need to document that workqueue_init_early() relies on
> cpu_to_node() working.

Don't we do the setup cpu->node mapings in initmem_init()?
Ideally we have setup_arch->intmem_init->numa_setup_cpu

Will look at it tomorrow
Balbir Singh

Re: ARM64-cpuinfo: Combine six calls for sequence output into one seq_printf() call in c_show()

[SF Markus Elfring]

> I prefer the code as-is. Unless there's a compelling reason to change it.

Is the chance for faster log output interesting enough?

Regards,
Markus

[PATCH] MAINTAINERS: mmc: Move the mmc tree to kernel.org

[Ulf Hansson]

Signed-off-by: Ulf Hansson 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a009e00..e685724 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8164,7 +8164,7 @@ F:include/linux/mfd/
 MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
 M: Ulf Hansson 
 L: linux-...@vger.kernel.org
-T: git git://git.linaro.org/people/ulf.hansson/mmc.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
 S: Maintained
 F: Documentation/devicetree/bindings/mmc/
 F: drivers/mmc/
-- 
1.9.1

Re: [PATCH] pci: changing maintainer

[Bjorn Helgaas]

On Thu, Oct 13, 2016 at 06:26:13PM +0100, Joao Pinto wrote:
> 
> Signed-off-by: Joao Pinto 

Applied to for-linus for v4.9, thanks!

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 01bff8e..5ac91d8a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9052,7 +9052,7 @@ S:  Maintained
>  F:   drivers/pci/host/*designware*
>  
>  PCI DRIVER FOR SYNOPSYS PROTOTYPING DEVICE
> -M:   Joao Pinto 
> +M:   Jose Abreu 
>  L:   linux-...@vger.kernel.org
>  S:   Maintained
>  F:   Documentation/devicetree/bindings/pci/designware-pcie.txt
> -- 
> 1.8.1.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] [PATCH] Add a "nolinks" mount option.

[Mattias Nissler]

OK, no more feedback thus far. Is there generally any interest in a
mount option to avoid path name aliasing resulting in target file
confusion? Perhaps a version that only disables symlinks instead of
also hard-disabling files hard-linked to multiple locations (those are
much lower risk for the situation I care about)?

If there is interest, I'm happy to iterate the patch until it's
accepted. If there's no interest, that's fine too - I'll then likely
resort to moving the restrictions desired for Chrome OS into an LSM we
compile into our kernels.

On Fri, Oct 14, 2016 at 6:22 PM, Mattias Nissler  wrote:
> Forgot to mention: I realize my motivation is very specific to Chrome
> OS, however the nolinks option seemed useful also as a mitigation to
> generic privilege escalation symlink attacks, for cases where
> disabling symlinks/hardlinks is acceptable.
>
> On Fri, Oct 14, 2016 at 5:50 PM, Mattias Nissler  
> wrote:
>> On Fri, Oct 14, 2016 at 5:00 PM, Al Viro  wrote:
>>>
>>> On Fri, Oct 14, 2016 at 03:55:15PM +0100, Al Viro wrote:
>>> > > Setting the "nolinks" mount option helps prevent privileged writers
>>> > > from modifying files unintentionally in case there is an unexpected
>>> > > link along the accessed path. The "nolinks" option is thus useful as a
>>> > > defensive measure against persistent exploits (i.e. a system getting
>>> > > re-exploited after a reboot) for systems that employ a read-only or
>>> > > dm-verity-protected rootfs. These systems prevent non-legit binaries
>>> > > from running after reboot. However, legit code typically still reads
>>> > > from and writes to a writable file system previously under full
>>> > > control of the attacker, who can place symlinks to trick file writes
>>> > > after reboot to target a file of their choice. "nolinks" fundamentally
>>> > > prevents this.
>>> >
>>> > Which parts of the tree would be on that "protected" rootfs and which 
>>> > would
>>> > you mount with that option?  Description above is rather vague and I'm
>>> > not convinced that it actually buys you anything.  Details, please...
>>
>> Apologies for the vague description, I'm happy to explain in detail.
>>
>> In case of Chrome OS, we have all binaries on a dm-verity rootfs, so
>> an attacker can't modify any binaries. After reboot, everything except
>> the rootfs is mounted noexec, so there's no way to re-gain code
>> execution after reboot by modifying existing binaries or dropping new
>> ones.
>>
>> We've seen multiple exploits now where the attacker worked around
>> these limitations in two steps:
>>
>> 1. Before reboot, the attacker sets up symlinks on the writeable file
>> system (called "stateful" file system), which are later accessed by
>> legit boot code (such as init scripts) after reboot. For example, an
>> init script that copies file A to B can be abused by an attacker by
>> symlinking or hardlinking B to a location C of their choice, and
>> placing desired data to be written to C in A. That gives the attacker
>> a primitive to write data of their choice to a path of their choice
>> after reboot. Note that this primitive may target locations _outside_
>> the stateful file system the attacker previously had control of.
>> Particularly of interest are targets on /sys, but also tmpfs on /run
>> etc.
>>
>> 2. The second step for a successful attack is finding some legit code
>> invoked in the boot flow that has a vulnerability exploitable by
>> feeding it unexpected data. As an example, there are Linux userspace
>> utilities that read config from /run which may contain shell commands
>> the the utility executes, through which the attacker can gain code
>> execution again.
>>
>> The purpose of the proposed patch is to raise the bar for the first
>> step of the attack: Writing arbitrary files after reboot. I'm
>> intending to mount the stateful file system with the nolinks option
>> (or otherwise prevent symlink traversal). This will help make sure
>> that any legit writes taking place during boot in init scripts etc. go
>> to the files intended by the developer, and can't be redirected by an
>> attacker.
>>
>> Does this make more sense to you?
>>
>>>
>>>
>>> PS: what the hell do restrictions on _following_ symlinks have to _creating_
>>> hardlinks?  I'm trying to imagine a threat model where both would apply or
>>> anything else beyond the word "link" they would have in common...
>>
>> The restriction is not on _creating_ hard links, but _opening_
>> hardlinks. The commonality is in the confusion between the file you're
>> meaning to write vs. the file you actually end up writing to, which
>> stems from the fact that as things stand a file can be accessible on
>> other paths than its canonical one. For Chrome OS, I'd like to get to
>> a point where most privileged code can only access a file via its
>> canonical name (bind mounts are an OK exception as they're not
>> persistent, so out of reach for manipulation).
>>
>>>
>>> The one you've described above might have something to do 

Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user

[Mark Rutland]

On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote:
> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland  wrote:
> > The strncpy_from_user() accessor is effectively a copy_from_user()
> > specialised to copy strings, terminating early at a NUL byte if
> > possible. In other respects it is identical, and can be used to copy an
> > arbitrarily large buffer from userspace into the kernel. Conceptually,
> > it exposes a similar attack surface.
> >
> > As with copy_from_user(), we check the destination range when the kernel
> > is built with KASAN, but unlike copy_from_user() we do not check the
> > destination buffer when using HARDENED_USERCOPY. As strncpy_from_user()
> > calls get_user() in a loop, we must call check_object_size() explicitly.
> >
> > This patch adds this instrumentation to strncpy_from_user(), per the
> > same rationale as with the regular copy_from_user(). In the absence of
> > hardened usercopy this will have no impact as the instrumentation
> > expands to an empty static inline function.

[...]

> Ah, yes, good catch! (And to repeat what you mentioned to me in
> passing in the hall: there appear to be other users of get_user() in a
> loop in other places in the kernel that will likely need some
> attention too.)

I was reminded of this as it just hit mainline; is it worth dropping a
TODO on the KSPP wiki? I suspect I won't have the time to delve much
further into this in the near term, and it might be a good intro task
for someone.

Thanks,
Mark.

Re: [PATCH v4 0/1] Armada 7k/8k CP110 system controller fixes

[Marcin Wojtas]

Hi Stephen,

Since merge window is closed, I kindly remind about remaining patch.

Best regards,
Marcin

2016-10-06 21:24 GMT+02:00 Marcin Wojtas :
> Hi Stephen,
>
> Do you have any further comments on the remaining patch?
>
> Best regards,
> Marcin
>
> 2016-09-25 9:47 GMT+02:00 Marcin Wojtas :
>> Hi,
>>
>> Two patches from the third version of the patchset have already been
>> applied, so I re-send the last one with corrected allocation of
>> clock data, which was pointed in the review.
>>
>> Any feedback would be very welcome.
>>
>> Best regards,
>> Marcin
>>
>> Changelog:
>> v4 <- v3
>> * fix allocation of clock data
>>
>> v3 <- v2
>> * return -ENOMEM on alloc failures
>>
>> v1 <- v2
>> * replace setting CLK_IS_BASIC flag with clearing init structure fields
>>   with memset
>> * minor improvements of allocation and error checking
>> * add migration to clk_hw
>>
>>
>> Marcin Wojtas (1):
>>   clk: mvebu: migrate CP110 system controller to clk_hw API and
>> registration
>>
>>  drivers/clk/mvebu/cp110-system-controller.c | 150 
>> +---
>>  1 file changed, 72 insertions(+), 78 deletions(-)
>>
>> --
>> 1.8.3.1
>>

Re: [PATCH] PCI: layerscape: Fix drvdata usage before assignment

[Bjorn Helgaas]

On Mon, Oct 17, 2016 at 11:39:32AM +0100, Marc Zyngier wrote:
> Commit fefe6733e516 ("PCI: layerscape: Move struct pcie_port setup
> to probe function") changed the init ordering of the pcie structure,
> but started to use the pcie->drvdata field before initializing it.
> Mayhem follows.
> 
> Fix this by moving the drvdata assignment right before the first use.
> Tested on LS2085a.
> 
> Signed-off-by: Marc Zyngier 

Applied to for-linus for v4.9, thanks, Marc!

> ---
>  drivers/pci/host/pci-layerscape.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pci-layerscape.c 
> b/drivers/pci/host/pci-layerscape.c
> index 856d428..27602a3 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -270,6 +270,7 @@ static int __init ls_pcie_probe(struct platform_device 
> *pdev)
>  
>   pp = >pp;
>   pp->dev = dev;
> + pcie->drvdata = match->data;
>   pp->ops = pcie->drvdata->ops;
>  
>   dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> @@ -279,7 +280,6 @@ static int __init ls_pcie_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(pcie->pp.dbi_base);
>   }
>  
> - pcie->drvdata = match->data;
>   pcie->lut = pcie->pp.dbi_base + pcie->drvdata->lut_offset;
>  
>   if (!ls_pcie_is_bridge(pcie))
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: ehci-platform: increase EHCI_MAX_RSTS to 4

[Masahiro Yamada]

Hi Greg,


2016-10-17 21:30 GMT+09:00 Greg Kroah-Hartman :
> On Mon, Oct 17, 2016 at 08:11:59PM +0900, Masahiro Yamada wrote:
>> Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
>> needs to handle 4 reset lines for EHCI.
>
> Why?  What makes it different from other EHCI implementations?
>
> thanks,
>
> greg k-h


This is a generic EHCI driver, but the number of clocks/resets
are SoC-specific.



The following patch you picked up will remind you something?



commit 73577d61799e8d8bb7d69a9acdc54923e5998138
Author: Icenowy Zheng 
Date:   Fri Aug 12 11:06:22 2016 +0800

ehci-platform: add the max clock number to 4

Allwinner A64 EHCI requires 4 clocks to be enabled.

Signed-off-by: Icenowy Zheng 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 






-- 
Best Regards
Masahiro Yamada

Re: [kernel-hardening] [PATCH] lib: harden strncpy_from_user

[Loganaden Velvindron]

On Mon, Oct 17, 2016 at 5:04 PM, Mark Rutland  wrote:
> On Fri, Aug 26, 2016 at 02:57:58PM -0400, Kees Cook wrote:
>> On Fri, Aug 26, 2016 at 10:31 AM, Mark Rutland  wrote:
>> > The strncpy_from_user() accessor is effectively a copy_from_user()
>> > specialised to copy strings, terminating early at a NUL byte if
>> > possible. In other respects it is identical, and can be used to copy an
>> > arbitrarily large buffer from userspace into the kernel. Conceptually,
>> > it exposes a similar attack surface.
>> >
>> > As with copy_from_user(), we check the destination range when the kernel
>> > is built with KASAN, but unlike copy_from_user() we do not check the
>> > destination buffer when using HARDENED_USERCOPY. As strncpy_from_user()
>> > calls get_user() in a loop, we must call check_object_size() explicitly.
>> >
>> > This patch adds this instrumentation to strncpy_from_user(), per the
>> > same rationale as with the regular copy_from_user(). In the absence of
>> > hardened usercopy this will have no impact as the instrumentation
>> > expands to an empty static inline function.
>
> [...]
>
>> Ah, yes, good catch! (And to repeat what you mentioned to me in
>> passing in the hall: there appear to be other users of get_user() in a
>> loop in other places in the kernel that will likely need some
>> attention too.)
>
> I was reminded of this as it just hit mainline; is it worth dropping a
> TODO on the KSPP wiki? I suspect I won't have the time to delve much
> further into this in the near term, and it might be a good intro task
> for someone.
>
> Thanks,
> Mark.

Yes. I believe that it is.

Re: ARM64-cpuinfo: Combine six calls for sequence output into one seq_printf() call in c_show()

[Mark Rutland]

On Mon, Oct 17, 2016 at 02:50:57PM +0200, SF Markus Elfring wrote:
> > I prefer the code as-is. Unless there's a compelling reason to change it.
> 
> Is the chance for faster log output interesting enough?

Is there a particular user that cares today, or are we trying to work
backwards to a rationale?

Thanks,
Mark.

Re: drivers/mcb/mcb-parse.c:152: bad if expression

[Johannes Thumshirn]

On Mon, Oct 17, 2016 at 1:17 PM, David Binderman  wrote:
> Hello there,
>
> drivers/mcb/mcb-parse.c:152:22: warning: logical ‘and’ of mutually exclusive 
> tests is always false [-Wlogical-op]
>
> Source code is
>
>if (bar_count <= 0 && bar_count > CHAMELEON_BAR_MAX)
>
> Maybe better code
>
>if (bar_count <= 0 || bar_count > CHAMELEON_BAR_MAX)
>
> Regards
>
> David Binderman

Hi David,

Looks reasonable, care to send a patch?

Thanks,
Johannes

4.6.4, 3w_sas: timeout too small?

[Harald Dunkel]

Hi folks,

Question about the reset timeout of the 3w_sas:

For an unknown reason my 3ware 9750 RAID controller became
unresponsive. kernel.log:

Oct 16 06:30:42 nasl003b kernel: [4902556.775272] 3w-sas: scsi0: AEN: INFO 
(0x04:0x002B): Verify completed:unit=1.
Oct 16 06:38:29 nasl003b kernel: [4903023.388357] 3w-sas: scsi0: AEN: INFO 
(0x04:0x002B): Verify completed:unit=2.
Oct 16 06:41:33 nasl003b kernel: [4903207.577484] 3w-sas: scsi0: ERROR: 
(0x06:0x000D): Microcontroller Error: clearing.
Oct 16 06:42:11 nasl003b kernel: [4903245.701070] TMR Opcode TARGET_WARM_RESET 
authorization failed for Initiator Node: iqn.2014-01.com.example.ac.srva001
Oct 16 06:42:11 nasl003b kernel: [4903245.706778] TMR Opcode TARGET_WARM_RESET 
authorization failed for Initiator Node: iqn.2014-01.com.example.ac.srva001
Oct 16 06:42:15 nasl003b kernel: [4903249.298778] TMR Opcode TARGET_WARM_RESET 
authorization failed for Initiator Node: iqn.2014-01.com.example.ac.srva002
Oct 16 06:42:15 nasl003b kernel: [4903249.304369] TMR Opcode TARGET_WARM_RESET 
authorization failed for Initiator Node: iqn.2014-01.com.example.ac.srva002
Oct 16 06:42:15 nasl003b kernel: [4903249.318734] TMR Opcode TARGET_WARM_RESET 
authorization failed for Initiator Node: iqn.2014-01.com.example.ac.srva003
Oct 16 06:42:15 nasl003b kernel: [4903249.324122] TMR Opcode TARGET_WARM_RESET 
authorization failed for Initiator Node: iqn.2014-01.com.example.ac.srva003
Oct 16 06:42:41 nasl003b kernel: [4903275.739327] 3w-sas: scsi0: WARNING: 
(0x06:0x0006): Character ioctl (0x108) timed out, resetting card.
Oct 16 06:42:41 nasl003b kernel: [4903275.739402] sd 0:0:0:0: WARNING: 
(0x06:0x002C): Command (0x2a) timed out, resetting card.
Oct 16 06:43:36 nasl003b kernel: [4903330.757153] iSCSI Login timeout on 
Network Portal 172.19.96.217:3260
Oct 16 06:43:36 nasl003b kernel: [4903330.762124] iSCSI Login negotiation 
failed.
Oct 16 06:43:42 nasl003b kernel: [4903336.720892] 3w-sas: scsi0: ERROR: 
(0x06:0x0011): Controller not ready during reset sequence.
Oct 16 06:43:51 nasl003b kernel: [4903345.796529] iSCSI Login timeout on 
Network Portal 172.19.96.217:3260
Oct 16 06:43:51 nasl003b kernel: [4903345.801462] iSCSI Login negotiation 
failed.
Oct 16 06:44:06 nasl003b kernel: [4903360.835920] iSCSI Login timeout on 
Network Portal 172.19.96.217:3260
Oct 16 06:44:06 nasl003b kernel: [4903360.840843] iSCSI Login negotiation 
failed.
Oct 16 06:44:13 nasl003b kernel: [4903367.919662] INFO: task jbd2/sda1-8:235 
blocked for more than 120 seconds.
Oct 16 06:44:13 nasl003b kernel: [4903367.924633]   Tainted: GE 
  4.6.0-0.bpo.1-amd64 #1
Oct 16 06:44:13 nasl003b kernel: [4903367.929624] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 16 06:44:13 nasl003b kernel: [4903367.934751] jbd2/sda1-8 D 
88042d896000 0   235  2 0x
Oct 16 06:44:13 nasl003b kernel: [4903367.934756]  880424c2c440 
88042b43a140 8804249e 8804249dfbc0
Oct 16 06:44:13 nasl003b kernel: [4903367.934760]  7fff 
815c50a0 8804249dfc40 8804000daf00
Oct 16 06:44:13 nasl003b kernel: [4903367.934763]  815c4821 
 815c785f 7fff
Oct 16 06:44:13 nasl003b kernel: [4903367.934766] Call Trace:
Oct 16 06:44:13 nasl003b kernel: [4903367.934783]  [] ? 
bit_wait_timeout+0xa0/0xa0
Oct 16 06:44:13 nasl003b kernel: [4903367.934786]  [] ? 
schedule+0x31/0x80
Oct 16 06:44:13 nasl003b kernel: [4903367.934789]  [] ? 
schedule_timeout+0x22f/0x2c0
Oct 16 06:44:13 nasl003b kernel: [4903367.934794]  [] ? 
blk_peek_request+0x4d/0x280
Oct 16 06:44:13 nasl003b kernel: [4903367.934797]  [] ? 
bit_wait_timeout+0xa0/0xa0
:
:

The interesting point is that apparently the reset didn't succeed.
"Controller not ready during reset sequence" at 06:43:42. The 3ware
web interface says the controller was busy to write the cache to disk:

Oct 16, 2016 06:45:03AM (0x04:0x005E): Cache synchronization completed: unit=0

I have the impression that the timeout (60 secs?) in the driver is
insufficient. Do you think the status check in twl_reset_sequence()
could be improved?

There were no disk failures, of course.


Every helpful comment is highly appreciated.
Harri

Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes

[Peter Zijlstra]

On Mon, Oct 17, 2016 at 12:49:55PM +0100, Dietmar Eggemann wrote:

> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 8b03fb5..8926685 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -2902,7 +2902,8 @@ __update_load_avg(u64 now, int cpu, struct sched_avg 
> > *sa,
> >   */
> >  static inline void update_tg_load_avg(struct cfs_rq *cfs_rq, int force)
> >  {
> > -   long delta = cfs_rq->avg.load_avg - cfs_rq->tg_load_avg_contrib;
> > +   unsigned long load_avg = READ_ONCE(cfs_rq->avg.load_avg);
> > +   long delta = load_avg - cfs_rq->tg_load_avg_contrib;
> >  
> > /*
> >  * No need to update load_avg for root_task_group as it is not used.
> > @@ -2912,7 +2913,7 @@ static inline void update_tg_load_avg(struct cfs_rq 
> > *cfs_rq, int force)
> >  
> > if (force || abs(delta) > cfs_rq->tg_load_avg_contrib / 64) {
> > atomic_long_add(delta, _rq->tg->load_avg);
> > -   cfs_rq->tg_load_avg_contrib = cfs_rq->avg.load_avg;
> > +   cfs_rq->tg_load_avg_contrib = load_avg;
> > }
> >  }
> 
> Tested it on an Ubuntu 16.10 Server (on top of the default 4.8.0-22-generic
> kernel) on a Lenovo T430 and it didn't help.

Right, I don't think that race exists, we update cfs_rq->avg.load_avg
with rq->lock held and have it held here, so it cannot change under us.

This might do with a few lockdep_assert_held() instances to clarify this
though.

> What seems to cure it is to get rid of this snippet (part of the commit
> mentioned earlier in this thread: 3d30544f0212):
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 039de34f1521..16c692049fbf 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -726,7 +726,6 @@ void post_init_entity_util_avg(struct sched_entity *se)
> struct sched_avg *sa = >avg;
> long cap = (long)(SCHED_CAPACITY_SCALE - cfs_rq->avg.util_avg) / 2;
> u64 now = cfs_rq_clock_task(cfs_rq);
> -   int tg_update;
>  
> if (cap > 0) {
> if (cfs_rq->avg.util_avg != 0) {
> @@ -759,10 +758,8 @@ void post_init_entity_util_avg(struct sched_entity *se)
> }
> }
>  
> -   tg_update = update_cfs_rq_load_avg(now, cfs_rq, false);
> +   update_cfs_rq_load_avg(now, cfs_rq, false);
> attach_entity_load_avg(cfs_rq, se);
> -   if (tg_update)
> -   update_tg_load_avg(cfs_rq, false);
>  }
>  
>  #else /* !CONFIG_SMP */
> 
> BTW, I guess we can reach .tg_load_avg up to ~30-40 on such a system
> initially because systemd will create all ~100 services (and therefore the
> corresponding 2. level tg's) at once. In my previous example, there was 500ms
> between the creation of 2 tg's so there was a lot of decaying going on in 
> between.

Cute... on current kernels that translates to simply removing the call
to update_tg_load_avg(), lets see if we can figure out what goes
sideways first though, because it _should_ decay back out. And if that
can fail here, I'm not seeing why that wouldn't fail elsewhere either.

I'll see if I can reproduce this with a script creating heaps of cgroups
in a hurry, I have a total lack of system-disease on all my machines.


/me goes prod..

Re: [patch] ftrace: Fix latency trace header alignment

[Sebastian Andrzej Siewior]

On 2016-10-16 05:08:30 [+0200], Mike Galbraith wrote:
> Line up helper arrows to the right column.

thanks. And while at it I fixed the function tracer header.

> Signed-off-by: Mike Galbraith 

Sebastian

Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop

[Peter Zijlstra]

On Mon, Oct 17, 2016 at 12:44:49PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 13, 2016 at 04:17:21PM +0100, Will Deacon wrote:
> > Hi Peter,
> > 
> > I'm struggling to get my head around the handoff code after this change...
> > 
> > On Fri, Oct 07, 2016 at 04:52:49PM +0200, Peter Zijlstra wrote:
> > > --- a/kernel/locking/mutex.c
> > > +++ b/kernel/locking/mutex.c
> > > @@ -631,13 +631,21 @@ __mutex_lock_common(struct mutex *lock,
> > >  
> > >   lock_contended(>dep_map, ip);
> > >  
> > > + set_task_state(task, state);
> > >   for (;;) {
> > > + /*
> > > +  * Once we hold wait_lock, we're serialized against
> > > +  * mutex_unlock() handing the lock off to us, do a trylock
> > > +  * before testing the error conditions to make sure we pick up
> > > +  * the handoff.
> > > +  */
> > >   if (__mutex_trylock(lock, first))
> > > - break;
> > > + goto acquired;
> > >  
> > >   /*
> > > -  * got a signal? (This code gets eliminated in the
> > > -  * TASK_UNINTERRUPTIBLE case.)
> > > +  * Check for signals and wound conditions while holding
> > > +  * wait_lock. This ensures the lock cancellation is ordered
> > > +  * against mutex_unlock() and wake-ups do not go missing.
> > >*/
> > >   if (unlikely(signal_pending_state(state, task))) {
> > >   ret = -EINTR;
> > > @@ -650,16 +658,27 @@ __mutex_lock_common(struct mutex *lock,
> > >   goto err;
> > >   }
> > >  
> > > - __set_task_state(task, state);
> > >   spin_unlock_mutex(>wait_lock, flags);
> > >   schedule_preempt_disabled();
> > > - spin_lock_mutex(>wait_lock, flags);
> > >  
> > >   if (!first && __mutex_waiter_is_first(lock, )) {
> > >   first = true;
> > >   __mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
> > >   }
> > > +
> > > + set_task_state(task, state);
> > 
> > With this change, we no longer hold the lock wit_hen we set the task
> > state, and it's ordered strictly *after* setting the HANDOFF flag.
> > Doesn't that mean that the unlock code can see the HANDOFF flag, issue
> > the wakeup, but then we come in and overwrite the task state?
> > 
> > I'm struggling to work out whether that's an issue, but it certainly
> > feels odd and is a change from the previous behaviour.
> 
> Right, so I think the code is fine, since in that case the
> __mutex_trylock() must see the handoff and we'll break the loop and
> (re)set the state to RUNNING.
> 
> But you're right in that its slightly odd. I'll reorder them and put the
> set_task_state() above the !first thing.


Humm,.. we might actually rely on this order, since the MB implied by
set_task_state() is the only thing that separates the store of
__mutex_set_flag() from the load of __mutex_trylock(), and those should
be ordered I think.

Argh, completely messed up my brain. I'll not touch it and think on this
again tomorrow.

Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle

[zhong jiang]

On 2016/10/17 20:03, Vitaly Wool wrote:
> Hi Zhong Jiang,
>
> On Mon, Oct 17, 2016 at 3:58 AM, zhong jiang  wrote:
>> Hi,  Vitaly
>>
>> About the following patch,  is it right?
>>
>> Thanks
>> zhongjiang
>> On 2016/10/13 12:02, zhongjiang wrote:
>>> From: zhong jiang 
>>>
>>> At present, zhdr->first_num plus bud can exceed the BUDDY_MASK
>>> in encode_handle, it will lead to the the caller handle_to_buddy
>>> return the error value.
>>>
>>> The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK,
>>> it will be consistent with handle_to_z3fold_header. At the same time,
>>> change the BUDDY_MASK to PAGE_MASK in handle_to_buddy is better.
> are you seeing problems with the existing code? first_num should wrap around
> BUDDY_MASK and this should be ok because it is way bigger than the number
> of buddies.
>
> ~vitaly
>
> .
>
 first_num plus buddies can exceed the BUDDY_MASK. is it right?
 (first_num + buddies) & BUDDY_MASK may be a smaller value than first_num.

  but (handle - zhdr->first_num) & BUDDY_MASK will return incorrect value
  in handle_to_buddy.

  Thanks
  zhongjiang
 

Re: [PATCH] MIPS: IP22: Fix build error in IP22 cache code

[Maciej W. Rozycki]

On Fri, 14 Oct 2016, Matt Redfearn wrote:

> Recent MIPS toolchains complain about the use of an immediate larger
> than 32bits when compiling a 32bit kernel, leading to the following
> build failure:
> {standard input}: Assembler messages:
> {standard input}:131: Error: number (0x90008000) larger than 32
> bits
> {standard input}:154: Error: number (0x90008000) larger than 32
> bits
> {standard input}:191: Error: number (0x90008000) larger than 32
> bits
> 
> Fix this by specifying registers are 64bit via the .set gp=64 directive.
> 
> Since IP22 is the default MIPS machine, this is causing allnoconfig
> build failures.
> 
> Fixes: 1da177e4c3f4
> Signed-off-by: Matt Redfearn 
> 
> Cc: sta...@vger.kernel.org
> ---

 This GAS regression introduced with upstream binutils commit 919731affbef 
("Add MIPS .module directive") has been fixed with commit 22522f880a8e 
("MIPS/GAS: Fix an ISA override not lifting ABI restrictions") and release 
2.27 has been subsequently made.

 Moving forward with your workaround may still make sense, although it 
will bump the minimum binutils version to 2.18, which is when `.set gp=64' 
has been added only, from the advertised version 2.12; it may have already 
effectively happened due to changes elsewhere.  If doing so however, 
please be accurate with your commit description in that versions 2.25 and 
2.26 (and their patch releases) only rather than "recent" have been 
affected.

 See also:  
and the discussion downthread.  Based on the conclusions made there I'd 
rather ban binutils 2.25 and 2.26 from use with the MIPS/Linux kernel as 
the problem with ISA restoration may lead to bad code generation.  So 
maybe we should really leave this piece unchanged, as a fatal trigger for 
unsupported binutils versions in the affected scenarios.

  Maciej

[PATCH 1/1] Staging: gs_fpgaboot: Use octal permissions '0444'

[Shyam Saini]

Fixed following checkpatch warning
WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider
using octal permissions '0444'.

Signed-off-by: Shyam Saini 
---
 drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c 
b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
index 8ed4d39..19b550f 100644
--- a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
+++ b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
@@ -38,7 +38,7 @@ static u8 bits_magic[] = {
 static struct platform_device  *firmware_pdev;
 
 static char*file = "xlinx_fpga_firmware.bit";
-module_param(file, charp, S_IRUGO);
+module_param(file, charp, 0444);
 MODULE_PARM_DESC(file, "Xilinx FPGA firmware file.");
 
 static void read_bitstream(char *bitdata, char *buf, int *offset, int rdsize)
-- 
2.7.4

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

[Mark Rutland]

Hi,

Attempt to revive discussions below...

On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote:
> When kernel.perf_event_paranoid is set to 3 (or greater), disallow
> all access to performance events by users without CAP_SYS_ADMIN.
> 
> This new level of restriction is intended to reduce the attack
> surface of the kernel. Perf is a valuable tool for developers but
> is generally unnecessary and unused on production systems. Perf may
> open up an attack vector to vulnerable device-specific drivers as
> recently demonstrated in CVE-2016-0805, CVE-2016-0819,
> CVE-2016-0843, CVE-2016-3768, and CVE-2016-3843. This new level of
> restriction allows for a safe default to be set on production systems
> while leaving a simple means for developers to grant access [1].
> 
> This feature is derived from CONFIG_GRKERNSEC_PERF_HARDEN by Brad
> Spengler. It is based on a patch by Ben Hutchings [2]. Ben's patches
> have been modified and split up to address on-list feedback.
> 
> kernel.perf_event_paranoid=3 is the default on both Debian [2] and
> Android [3].

While people weren't particularly happy with this global toggle
approach, my understanding from face-to-face discussions at LSS2016 was
that people were happy with a more scoped restriction (e.g. using
capabilities or some other access control mechanism), but no-one had the
time to work on that.

Does that match everyone's understanding, or am I mistaken?

It's also my understanding that for Android, perf_event_paranoid is
lowered when the user enables developer mode (rather than only when an
external debugger is attached); is that correct?

Thanks,
Mark.

Re: [PATCH] lpfc: use %zd format string for size_t

[Johannes Thumshirn]

On Mon, Oct 17, 2016 at 02:35:46PM +0200, Arnd Bergmann wrote:
> A recent bugfix introduced a harmless warning in the lpfc driver:
> 
> drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware':
> drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error: format '%ld' expects argument 
> of type 'long int', but argument 9 has type 'size_t {aka const unsigned int}' 
> [-Werror=format=]
> 
> 'size_t' is always the same width as 'long' in the kernel, but the compiler
> doesn't know that. The %z modifier is what the standard expects to be
> used here, and this shuts up the warning.
> 
> Fixes: 679053c651fb ("scsi: lpfc: Fix fw download on SLI-4 FC adapters")
> Signed-off-by: Arnd Bergmann 
> ---

Looks good,
Reviewed-by: Johannes Thumshirn 

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

Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop

[Boqun Feng]

On Mon, Oct 17, 2016 at 03:24:08PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 17, 2016 at 12:44:49PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 13, 2016 at 04:17:21PM +0100, Will Deacon wrote:
> > > Hi Peter,
> > > 
> > > I'm struggling to get my head around the handoff code after this change...
> > > 
> > > On Fri, Oct 07, 2016 at 04:52:49PM +0200, Peter Zijlstra wrote:
> > > > --- a/kernel/locking/mutex.c
> > > > +++ b/kernel/locking/mutex.c
> > > > @@ -631,13 +631,21 @@ __mutex_lock_common(struct mutex *lock,
> > > >  
> > > > lock_contended(>dep_map, ip);
> > > >  
> > > > +   set_task_state(task, state);
> > > > for (;;) {
> > > > +   /*
> > > > +* Once we hold wait_lock, we're serialized against
> > > > +* mutex_unlock() handing the lock off to us, do a 
> > > > trylock
> > > > +* before testing the error conditions to make sure we 
> > > > pick up
> > > > +* the handoff.
> > > > +*/
> > > > if (__mutex_trylock(lock, first))
> > > > -   break;
> > > > +   goto acquired;
> > > >  
> > > > /*
> > > > -* got a signal? (This code gets eliminated in the
> > > > -* TASK_UNINTERRUPTIBLE case.)
> > > > +* Check for signals and wound conditions while holding
> > > > +* wait_lock. This ensures the lock cancellation is 
> > > > ordered
> > > > +* against mutex_unlock() and wake-ups do not go 
> > > > missing.
> > > >  */
> > > > if (unlikely(signal_pending_state(state, task))) {
> > > > ret = -EINTR;
> > > > @@ -650,16 +658,27 @@ __mutex_lock_common(struct mutex *lock,
> > > > goto err;
> > > > }
> > > >  
> > > > -   __set_task_state(task, state);
> > > > spin_unlock_mutex(>wait_lock, flags);
> > > > schedule_preempt_disabled();
> > > > -   spin_lock_mutex(>wait_lock, flags);
> > > >  
> > > > if (!first && __mutex_waiter_is_first(lock, )) {
> > > > first = true;
> > > > __mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
> > > > }
> > > > +
> > > > +   set_task_state(task, state);
> > > 
> > > With this change, we no longer hold the lock wit_hen we set the task
> > > state, and it's ordered strictly *after* setting the HANDOFF flag.
> > > Doesn't that mean that the unlock code can see the HANDOFF flag, issue
> > > the wakeup, but then we come in and overwrite the task state?
> > > 
> > > I'm struggling to work out whether that's an issue, but it certainly
> > > feels odd and is a change from the previous behaviour.
> > 
> > Right, so I think the code is fine, since in that case the
> > __mutex_trylock() must see the handoff and we'll break the loop and
> > (re)set the state to RUNNING.
> > 
> > But you're right in that its slightly odd. I'll reorder them and put the
> > set_task_state() above the !first thing.
> 
> 
> Humm,.. we might actually rely on this order, since the MB implied by
> set_task_state() is the only thing that separates the store of
> __mutex_set_flag() from the load of __mutex_trylock(), and those should
> be ordered I think.
> 

But __mutex_set_flag() and __mutex_trylock() actually touch the same
atomic word? So we don't need extra things to order them?

Regards,
Boqun

> Argh, completely messed up my brain. I'll not touch it and think on this
> again tomorrow.


signature.asc
Description: PGP signature

Re: [PATCH v4 08/18] x86/intel_rdt: Pick up L3/L2 RDT parameters from CPUID

[Thomas Gleixner]

On Fri, 14 Oct 2016, Fenghua Yu wrote:
> +/**
> + * struct rdt_resource - attributes of an RDT resource
> + * @enabled: Is this feature enabled on this machine
> + * @name:Name to use in "schemata" file
> + * @max_closid:  Maximum number of CLOSIDs supported
> + * @num_closid:  Current number of CLOSIDs available
> + * @max_cbm: Largest Cache Bit Mask allowed
> + * @min_cbm_bits:Minimum number of bits to be set in a cache

That should be 'number of consecutive bits', right?

> + *   bit mask
> + * @domains: All domains for this resource
> + * @num_domains: Number of domains active
> + * @msr_base:Base MSR address for CBMs
> + * @cdp_capable: Code/Data Prioritization available
> + * @cdp_enabled: Code/Data Prioritization enabled

I wonder whether this is the proper abstraction level. We might as well do
the following:

rdtresources[] = {
 {
.name   = "L3",
 },
 {
.name   = "L3Data",
 },
 {
.name   = "L3Code",
 },

and enable either L3 or L3Data+L3Code. Not sure if that makes things
simpler, but it's definitely worth a thought or two.

> +#define for_each_rdt_resource(r) \
> + for (r = rdt_resources_all; r->name; r++) \
> + if (r->enabled)

So the resource array must be NULL terminated, right? You might as well use

   r < rdt_resources_all + ARRAY_SIZE(rdt_resources_all)

as the loop condition. So you avoid the NULL termination.

> +
> +#define IA32_L3_CBM_BASE 0xc90
> +extern struct rdt_resource rdt_resources_all[];

Please visually split this. CBM_BASE has nothing to do with the resource
array.

> +#define domain_init(name) LIST_HEAD_INIT(rdt_resources_all[name].domains)

name is really misleading here. Please use id and make this an inline
function.

> +struct rdt_resource rdt_resources_all[] = {

>  static inline bool get_rdt_resources(void)
>  {
> + struct rdt_resource *r;
>   bool ret = false;
>  
>   if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
> @@ -74,20 +105,53 @@ static inline bool get_rdt_resources(void)
>  
>   if (!boot_cpu_has(X86_FEATURE_RDT_A))
>   return false;
> - if (boot_cpu_has(X86_FEATURE_CAT_L3))
> + if (boot_cpu_has(X86_FEATURE_CAT_L3)) {
> + union cpuid_0x10_1_eax eax;
> + union cpuid_0x10_1_edx edx;
> + u32 ebx, ecx;
> +
> + r = _resources_all[RDT_RESOURCE_L3];
> + cpuid_count(0x0010, 1, , , , );
> + r->max_closid = edx.split.cos_max + 1;
> + r->num_closid = r->max_closid;
> + r->cbm_len = eax.split.cbm_len + 1;
> + r->max_cbm = BIT_MASK(eax.split.cbm_len + 1) - 1;
> + if (boot_cpu_has(X86_FEATURE_CDP_L3))
> + r->cdp_capable = true;
> + r->enabled = true;
> +
>   ret = true;
> + }
> + if (boot_cpu_has(X86_FEATURE_CAT_L2)) {
> + union cpuid_0x10_1_eax eax;
> + union cpuid_0x10_1_edx edx;
> + u32 ebx, ecx;
> +
> + /* CPUID 0x10.2 fields are same format at 0x10.1 */
> + r = _resources_all[RDT_RESOURCE_L2];
> + cpuid_count(0x0010, 2, , , , );
> + r->max_closid = edx.split.cos_max + 1;
> + r->num_closid = r->max_closid;
> + r->cbm_len = eax.split.cbm_len + 1;
> + r->max_cbm = BIT_MASK(eax.split.cbm_len + 1) - 1;
> + r->enabled = true;

Copy and paste is a wonderful thing, right?

static void rdt_get_config(int idx, struct rdt_resource *r)
{
union cpuid_0x10_1_eax eax;
union cpuid_0x10_1_edx edx;
u32 ebx, ecx;

cpuid_count(0x0010, idx, , , , );
r->max_closid = edx.split.cos_max + 1;
r->num_closid = r->max_closid;
r->cbm_len = eax.split.cbm_len + 1;
r->max_cbm = BIT_MASK(eax.split.cbm_len + 1) - 1;
r->enabled = true;
}

and and the call site:

if (boot_cpu_has(X86_FEATURE_CAT_L3)) {
rdt_get_config(1, _resources_all[RDT_RESOURCE_L3]);
if (boot_cpu_has(X86_FEATURE_CDP_L3))
r->cdp_capable = true;
ret = true;
}

if (boot_cpu_has(X86_FEATURE_CAT_L2)) {
rdt_get_config(2, _resources_all[RDT_RESOURCE_L2]);
ret = true;
}

Hmm?

> + for_each_rdt_resource(r)
> + pr_info("Intel RDT %s allocation %s detected\n", r->name,
> + r->cdp_capable ? " (with CDP)" : "");

This want's curly braces around the loop.
  
Thanks,

tglx

Re: [PATCH 0/6] mmc/memstick: rtsx_usb: Fix runtime PM issues

[Ulf Hansson]

On 13 October 2016 at 13:37, Ulf Hansson  wrote:
> The rtsx_usb_sdmmc (mmc/sd) and rtsx_usb_ms (memstick) devices are interfacing
> an rtsx_usb device (managed by an mfd driver) while communicating with the
> cards. The mmc/sd and memstick devices are children of the usb device.
>
> Issues has been reported [1] for rtsx, which have been investigated, 
> discussed,
> fixed, tested, etc, particularly when using mmc/sd cards. During the
> investigation, some changes was proposed and tested successfully. In this
> series I have picked up these changes and created some proper patches with
> change-logs.
>
> It turned out that most of the problems was related to the runtime PM
> deployment in the memstick and the mmc/sd driver, which are fixed in this
> series.
>
> A couple of more issues were also discussed [2], which needs to be fixed as
> well. Although they are out of scope for this series, so we will have to look
> into those at a later point. Here's a brief summary of these leftovers:
>
> *)
> It seems reasonable to turn off autosuspend for usb devices and instead rely 
> on
> the usb device's children to deal with autosuspend. The reason is simply that
> the children has better knowledge of when using autosuspend makes sense.
>
> **)
> Polling card detect mode is used both for mmc/sd and memstick. Because of the
> lack of synchronization between the polling attempts for these subsystems, the
> usb device may be powered on for unnecessary long intervals, thus we are
> wasting power.
>
> Besides the above changes, I folded in a change in the mmc core which improves
> the behaviour for mmc hosts using MMC_CAP2_NO_PRESCAN_POWERUP, which is the
> case for the rtsx_usb_sdmmc driver.  This change should improve the boot time
> with ~100ms per rtsx_usb_sdmmc device.
>
> Finally, as I couldn't find an active maintainer for the memstick
> subsystem/driver and because the author of the drivers can be reached, I
> volunteer to take this all through my mmc tree. Please tell me if that is
> problem to any of you.
>
> [1]
> https://www.spinics.net/lists/linux-usb/msg146998.html
> [2]
> https://www.spinics.net/lists/linux-mmc/msg39235.html
>
>
> Alan Stern (1):
>   memstick: rtsx_usb_ms: Runtime resume the device when polling for
> cards
>
> Ulf Hansson (5):
>   mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when
> unused
>   mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led
>   memstick: rtsx_usb_ms: Manage runtime PM when accessing the device
>   mmc: rtsx_usb_sdmmc: Enable runtime PM autosuspend
>   mmc: core: Don't power off the card when starting the host
>
>  drivers/memstick/host/rtsx_usb_ms.c |  6 ++
>  drivers/mmc/core/core.c |  9 -
>  drivers/mmc/host/rtsx_usb_sdmmc.c   | 10 +-
>  3 files changed, 15 insertions(+), 10 deletions(-)
>
> --
> 1.9.1
>

Patch 1->4 applied for fixes. Holding patch 5->6 for a while, as they
are intended for next!

Kind regards
Uffe

Re: [PATCH 0/2] mmc: sdhci-iproc: Add byte register access support

[Ulf Hansson]

On 12 October 2016 at 20:35, Scott Branden  wrote:
> Add brcm,sdhci-iproc compat string and code for support of newer versions of
> sdhci-iproc controller that allow byte-wise register accesses.
>
> Scott Branden (2):
>   mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings
> document
>   mmc: sdhci-iproc: support standard byte register accesses
>
>  .../devicetree/bindings/mmc/brcm,sdhci-iproc.txt   |  1 +
>  drivers/mmc/host/sdhci-iproc.c | 35 
> --
>  2 files changed, 34 insertions(+), 2 deletions(-)
>
> --
> 2.5.0
>

Thanks, applied for next!

Kind regards
Uffe

Re: [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support

[Arnd Bergmann]

On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
> 
> Signed-off-by: Pan Wen 
> 

Looks ok. I've added Marty Plummer to Cc, he was recently proposing
patches for Hi3520, which I think is closely related to this one.
Please try to work together so the patches don't conflict. It should
be fairly straightforward since you are basically doing the same
change here.

Arnd

Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes

[Vincent Guittot]

On 17 October 2016 at 15:19, Peter Zijlstra  wrote:
> On Mon, Oct 17, 2016 at 12:49:55PM +0100, Dietmar Eggemann wrote:
>
>> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> > index 8b03fb5..8926685 100644
>> > --- a/kernel/sched/fair.c
>> > +++ b/kernel/sched/fair.c
>> > @@ -2902,7 +2902,8 @@ __update_load_avg(u64 now, int cpu, struct sched_avg 
>> > *sa,
>> >   */
>> >  static inline void update_tg_load_avg(struct cfs_rq *cfs_rq, int force)
>> >  {
>> > -   long delta = cfs_rq->avg.load_avg - cfs_rq->tg_load_avg_contrib;
>> > +   unsigned long load_avg = READ_ONCE(cfs_rq->avg.load_avg);
>> > +   long delta = load_avg - cfs_rq->tg_load_avg_contrib;
>> >
>> > /*
>> >  * No need to update load_avg for root_task_group as it is not used.
>> > @@ -2912,7 +2913,7 @@ static inline void update_tg_load_avg(struct cfs_rq 
>> > *cfs_rq, int force)
>> >
>> > if (force || abs(delta) > cfs_rq->tg_load_avg_contrib / 64) {
>> > atomic_long_add(delta, _rq->tg->load_avg);
>> > -   cfs_rq->tg_load_avg_contrib = cfs_rq->avg.load_avg;
>> > +   cfs_rq->tg_load_avg_contrib = load_avg;
>> > }
>> >  }
>>
>> Tested it on an Ubuntu 16.10 Server (on top of the default 4.8.0-22-generic
>> kernel) on a Lenovo T430 and it didn't help.
>
> Right, I don't think that race exists, we update cfs_rq->avg.load_avg
> with rq->lock held and have it held here, so it cannot change under us.

yes I agree. It was just to be sure that an unexpected race condition
doesn't happen

>
> This might do with a few lockdep_assert_held() instances to clarify this
> though.
>
>> What seems to cure it is to get rid of this snippet (part of the commit
>> mentioned earlier in this thread: 3d30544f0212):
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 039de34f1521..16c692049fbf 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -726,7 +726,6 @@ void post_init_entity_util_avg(struct sched_entity *se)
>> struct sched_avg *sa = >avg;
>> long cap = (long)(SCHED_CAPACITY_SCALE - cfs_rq->avg.util_avg) / 2;
>> u64 now = cfs_rq_clock_task(cfs_rq);
>> -   int tg_update;
>>
>> if (cap > 0) {
>> if (cfs_rq->avg.util_avg != 0) {
>> @@ -759,10 +758,8 @@ void post_init_entity_util_avg(struct sched_entity *se)
>> }
>> }
>>
>> -   tg_update = update_cfs_rq_load_avg(now, cfs_rq, false);
>> +   update_cfs_rq_load_avg(now, cfs_rq, false);
>> attach_entity_load_avg(cfs_rq, se);
>> -   if (tg_update)
>> -   update_tg_load_avg(cfs_rq, false);
>>  }
>>
>>  #else /* !CONFIG_SMP */
>>
>> BTW, I guess we can reach .tg_load_avg up to ~30-40 on such a system
>> initially because systemd will create all ~100 services (and therefore the
>> corresponding 2. level tg's) at once. In my previous example, there was 500ms
>> between the creation of 2 tg's so there was a lot of decaying going on in 
>> between.
>
> Cute... on current kernels that translates to simply removing the call
> to update_tg_load_avg(), lets see if we can figure out what goes
> sideways first though, because it _should_ decay back out. And if that

yes, Reaching ~30-40 is not an issue in itself, the problem is
that load_avg has decayed but it has not been reflected in
tg->load_avg in the buggy case

> can fail here, I'm not seeing why that wouldn't fail elsewhere either.
>
> I'll see if I can reproduce this with a script creating heaps of cgroups
> in a hurry, I have a total lack of system-disease on all my machines.
>
>
> /me goes prod..

Re: [PATCH 1/9] perf/jit: improve error messages from JVMTI

[Stephane Eranian]

On Fri, Oct 14, 2016 at 8:20 AM, Arnaldo Carvalho de Melo
 wrote:
> Em Fri, Oct 14, 2016 at 05:57:25AM -0700, Stephane Eranian escreveu:
>> On Fri, Oct 14, 2016 at 4:13 AM, Arnaldo Carvalho de Melo  
>> wrote:
>> > Em Thu, Oct 13, 2016 at 03:05:40PM -0500, Nilay Vaish escreveu:
>> >> Do we not need to release the memory for err_msg if the condition for
>> >> the 'if' statement evaluates to false?  Is it that we are going to
>> >> kill the process, so no need to release the memory?
>
>> > I guess that print_error() is called only when an error was returned
>> > somewhere, that ret parameter, then if there was no error
>> > (JVMTI_ERROR_NONE) in translating that numeric code to an string,
>> > err_msg, it can then be used with warnx() (the main purpose of
>> > print_error()) and then deallocated.
>> >
>> > For err != JVMTI_ERROR_NONE it silently goes back to the caller that
>> > expected it to print something.
>> >
>> > I.e. probably it should have an else clause, something like:
>> >
>> > if (err == JVMTI_ERROR_NONE) {
>> > warnx("%s failed with %s", msg, err_msg);
>> > (*jvmti)->Deallocate(jvmti, (unsigned char *)err_msg);
>> > } else {
>> > warnx("%s failed with an unknown error %d", msg, (int)ret);
>> > }
>> >
>> > Stephane?
>> I will fix all of the comments over the week-end. I am away from office 
>> today.
>
> I have almost all of them fixed, will fix this one too, if you agree
> with the analysis.
>
Ok, the proposed fix is correct.
Thanks for fixing issues.

Now, I am tracking down another issue with the injection of jitdump.
It seems something goes wrong with ordering and timestamps and some
valid jitdump samples are not symbolized. It is not clear what is
causing this yet. It may be the issue raised by Adrian a while ago
about the finished_round processing.


> - Arnaldo

[PATCH v4 4/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature

[H. Nikolaus Schaller]

The tsc2007 chip not only has a resistive touch screen controller but
also an external AUX adc imput which can be used for an ambient
light sensor, battery voltage monitoring or any general purpose.

Additionally it can measure the chip temperature.

This extension provides an iio interface for these adc channels.

Since it is not wasting much resources and is very straightforward,
we simply provide all other adc channels as optional iio interfaces
as weel. This can be used for debugging or special applications.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/tsc2007.c | 151 +++-
 1 file changed, 150 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index c314331..b4a9504 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -61,6 +62,16 @@
 #define READ_X (ADC_ON_12BIT | TSC2007_MEASURE_X)
 #define PWRDOWN(TSC2007_12BIT | TSC2007_POWER_OFF_IRQ_EN)
 
+#define TSC2007_CHAN_IIO(_chan, _name, _type, _chan_info) \
+{ \
+   .datasheet_name = _name, \
+   .type = _type, \
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+   BIT(_chan_info), \
+   .indexed = 1, \
+   .channel = _chan, \
+}
+
 struct ts_event {
u16 x;
u16 y;
@@ -69,9 +80,13 @@ struct ts_event {
 
 struct tsc2007 {
struct input_dev*input;
+#ifdef CONFIG_IIO
+   struct iio_dev  *indio;
+#endif
charphys[32];
 
struct i2c_client   *client;
+   struct mutexmlock;
 
u16 model;
u16 x_plate_ohms;
@@ -192,7 +207,10 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
while (!ts->stopped && tsc2007_is_pen_down(ts)) {
 
/* pen is down, continue with the measurement */
+
+   mutex_lock(>mlock);
tsc2007_read_values(ts, );
+   mutex_unlock(>mlock);
 
rt = tsc2007_calculate_resistance(ts, );
 
@@ -319,6 +337,89 @@ static void tsc2007_close(struct input_dev *input_dev)
tsc2007_stop(ts);
 }
 
+#ifdef CONFIG_IIO
+
+static const struct iio_chan_spec tsc2007_iio_channel[] = {
+   TSC2007_CHAN_IIO(0, "x", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(1, "y", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(2, "z1", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(3, "z2", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(4, "adc", IIO_VOLTAGE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(5, "rt", IIO_VOLTAGE, IIO_CHAN_INFO_RAW), /* Ohms? */
+   TSC2007_CHAN_IIO(6, "pen", IIO_PRESSURE, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(7, "temp0", IIO_TEMP, IIO_CHAN_INFO_RAW),
+   TSC2007_CHAN_IIO(8, "temp1", IIO_TEMP, IIO_CHAN_INFO_RAW),
+};
+
+static int tsc2007_read_raw(struct iio_dev *indio_dev,
+   struct iio_chan_spec const *chan, int *val, int *val2, long mask)
+{
+   struct  tsc2007 *tsc = iio_priv(indio_dev);
+   int adc_chan = chan->channel;
+   int ret = 0;
+
+   if (adc_chan >= ARRAY_SIZE(tsc2007_iio_channel))
+   return -EINVAL;
+
+   if (mask != IIO_CHAN_INFO_RAW)
+   return -EINVAL;
+
+   mutex_lock(>mlock);
+
+   switch (chan->channel) {
+   case 0:
+   *val = tsc2007_xfer(tsc, READ_X);
+   break;
+   case 1:
+   *val = tsc2007_xfer(tsc, READ_Y);
+   break;
+   case 2:
+   *val = tsc2007_xfer(tsc, READ_Z1);
+   break;
+   case 3:
+   *val = tsc2007_xfer(tsc, READ_Z2);
+   break;
+   case 4:
+   *val = tsc2007_xfer(tsc, (ADC_ON_12BIT | TSC2007_MEASURE_AUX));
+   break;
+   case 5: {
+   struct ts_event tc;
+
+   tc.x = tsc2007_xfer(tsc, READ_X);
+   tc.z1 = tsc2007_xfer(tsc, READ_Z1);
+   tc.z2 = tsc2007_xfer(tsc, READ_Z2);
+   *val = tsc2007_calculate_resistance(tsc, );
+   break;
+   }
+   case 6:
+   *val = tsc2007_is_pen_down(tsc);
+   break;
+   case 7:
+   *val = tsc2007_xfer(tsc,
+   (ADC_ON_12BIT | TSC2007_MEASURE_TEMP0));
+   break;
+   case 8:
+   *val = tsc2007_xfer(tsc,
+   (ADC_ON_12BIT | TSC2007_MEASURE_TEMP1));
+   break;
+   }
+
+   /* Prepare for next touch reading - power down ADC, enable PENIRQ */
+   tsc2007_xfer(tsc, PWRDOWN);
+
+   mutex_unlock(>mlock);
+
+   ret = IIO_VAL_INT;
+
+   return ret;
+}
+

[PATCH v2 2/2] i2c: mark device nodes only in case of successful instantiation

[Ralf Ramsauer]

Instantiated I2C device nodes are marked with OF_POPULATE. This was
introduced in 4f001fd. On unloading, loaded device nodes will of course
be unmarked. The problem are nodes that fail during initialisation: If a
node fails, it won't be unloaded and hence not be unmarked.

If a I2C driver module is unloaded and reloaded, it will skip nodes that
failed before.

Skip device nodes that are already populated and mark them only in case
of success.

Note that the same issue exists for SPI.

Fixes: 4f001fd ("i2c: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer 
---
 drivers/i2c/i2c-core.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 5ab6721..1704fc8 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1681,6 +1681,7 @@ static struct i2c_client *of_i2c_register_device(struct 
i2c_adapter *adap,
 static void of_i2c_register_devices(struct i2c_adapter *adap)
 {
struct device_node *bus, *node;
+   struct i2c_client *client;
 
/* Only register child devices if the adapter has a node pointer set */
if (!adap->dev.of_node)
@@ -1695,7 +1696,14 @@ static void of_i2c_register_devices(struct i2c_adapter 
*adap)
for_each_available_child_of_node(bus, node) {
if (of_node_test_and_set_flag(node, OF_POPULATED))
continue;
-   of_i2c_register_device(adap, node);
+
+   client = of_i2c_register_device(adap, node);
+   if (IS_ERR(client)) {
+   dev_warn(>dev,
+"Failed to create I2C device for %s\n",
+node->full_name);
+   of_node_clear_flag(node, OF_POPULATED);
+   }
}
 
of_node_put(bus);
@@ -2299,6 +2307,7 @@ static int of_i2c_notify(struct notifier_block *nb, 
unsigned long action,
if (IS_ERR(client)) {
dev_err(>dev, "failed to create client for 
'%s'\n",
 rd->dn->full_name);
+   of_node_clear_flag(rd->dn, OF_POPULATED);
return notifier_from_errno(PTR_ERR(client));
}
break;
-- 
2.10.1

[PATCH v2 1/2] spi: mark device nodes only in case of successful instantiation

[Ralf Ramsauer]

Instantiated SPI device nodes are marked with OF_POPULATE. This was
introduced in bd6c164. On unloading, loaded device nodes will of course
be unmarked. The problem are nodes that fail during initialisation: If a
node fails, it won't be unloaded and hence not be unmarked.

If a SPI driver module is unloaded and reloaded, it will skip nodes that
failed before.

Skip device nodes that are already populated and mark them only in case
of success.

Note that the same issue exists for I2C.

Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer 
---
 drivers/spi/spi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 5787b72..838783c 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1618,9 +1618,11 @@ static void of_register_spi_devices(struct spi_master 
*master)
if (of_node_test_and_set_flag(nc, OF_POPULATED))
continue;
spi = of_register_spi_device(master, nc);
-   if (IS_ERR(spi))
+   if (IS_ERR(spi)) {
dev_warn(>dev, "Failed to create SPI device for 
%s\n",
nc->full_name);
+   of_node_clear_flag(nc, OF_POPULATED);
+   }
}
 }
 #else
@@ -3131,6 +3133,7 @@ static int of_spi_notify(struct notifier_block *nb, 
unsigned long action,
if (IS_ERR(spi)) {
pr_err("%s: failed to create for '%s'\n",
__func__, rd->dn->full_name);
+   of_node_clear_flag(rd->dn, OF_POPULATED);
return notifier_from_errno(PTR_ERR(spi));
}
break;
-- 
2.10.1

Re: [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

[Bartosz Golaszewski]

2016-10-17 14:29 GMT+02:00 Tomi Valkeinen :
> On 17/10/16 14:40, Laurent Pinchart wrote:
>> Hello,
>>
>> On Monday 17 Oct 2016 10:33:58 Tomi Valkeinen wrote:
>>> On 17/10/16 10:12, Sekhar Nori wrote:
 On Monday 17 October 2016 11:26 AM, Tomi Valkeinen wrote:
> On 15/10/16 20:42, Sekhar Nori wrote:
>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>> b/arch/arm/boot/dts/da850.dtsi
>>> index f79e1b9..32908ae 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -399,6 +420,14 @@
>>>  < 0 1>;
>>>  dma-names = "tx", "rx";
>>>  };
>>> +
>>> +display: display@213000 {
>>> +compatible = "ti,am33xx-tilcdc", 
>>> "ti,da850-tilcdc";
>>
>> This should instead be:
>>
>> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>>
>> as the closest match should appear first in the list.
>
> Actually I don't think that's correct. The LCDC on da850 is not
> compatible with the LCDC on AM335x. I think it should be just
> "ti,da850-tilcdc".

 So if "ti,am33xx-tilcdc" is used, the display wont work at all? If thats
 the case, I wonder how the patch passed testing. Bartosz?
>>>
>>> AM3 has "version 2" of LCDC, whereas DA850 is v1. They are quite
>>> similar, but different.
>>>
>>> The driver gets the version number from LCDC's register, and acts based
>>> on that, so afaik the compatible string doesn't really affect the
>>> functionality (as long as it matches).
>>>
>>> But even if it works with the current driver, I don't think
>>> "ti,am33xx-tilcdc" and "ti,da850-tilcdc" are compatible in the HW level.
>>
>> If the hardware provides IP revision information, how about just "ti,lcdc" ?
>
> Maybe, and I agree that's the "correct" way, but looking at the history,
> it's not just once or twice when we've suddenly found out some
> difference or bug or such in an IP revision, or the integration to a
> SoC, that can't be found based on the IP revision.
>
> That's why I feel it's usually safer to have the SoC revision there in
> the compatible string.
>
> That said, we have only a few different old SoCs with LCDC (compared to,
> say, OMAP DSS) so in this case perhaps just "ti,lcdc" would be fine.
>
>  Tomi
>

I Sekhar is ok with this, I'll send a follow-up patch for that.

Thanks,
Bartosz

[PATCH v4 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / 
swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.

Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.

A new feature is to introduce scaling the min/max ADC values to the screen
size.

This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.

Finally, calculate_pressure has been renamed to calculate_resistance
because that is what it is doing.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller 
---
 .../bindings/input/touchscreen/tsc2007.txt |  20 ++--
 drivers/input/touchscreen/tsc2007.c| 120 +
 include/linux/i2c/tsc2007.h|   8 ++
 3 files changed, 118 insertions(+), 30 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
index ec365e1..6e9fd55 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -6,6 +6,7 @@ Required properties:
 - ti,x-plate-ohms: X-plate resistance in ohms.
 
 Optional properties:
+- generic touch screen properties: see touchscreen binding [2].
 - gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
   The penirq pin goes to low when the panel is touched.
   (see GPIO binding[1] for more details).
@@ -13,17 +14,20 @@ Optional properties:
   (see interrupt binding[0]).
 - interrupts: (gpio) interrupt to which the chip is connected
   (see interrupt binding[0]).
-- ti,max-rt: maximum pressure.
-- ti,fuzzx: specifies the absolute input fuzz x value.
-  If set, it will permit noise in the data up to +- the value given to the fuzz
-  parameter, that is used to filter noise from the event stream.
-- ti,fuzzy: specifies the absolute input fuzz y value.
-- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,max-rt: maximum pressure resistance above which samples are ignored
+  (default: 4095).
+- ti,report-resistance: report resistance (no pressure = max_rt) instead
+  of pressure (no pressure = 0).
+- ti,min-x: minimum value reported by X axis ADC (default 0).
+- ti,max-x: maximum value reported by X axis ADC (default 4095).
+- ti,min-y: minimum value reported by Y axis ADC (default 0).
+- ti,max-y: maximum value reported by Y axis ADC (default 4095).
 - ti,poll-period: how much time to wait (in milliseconds) before reading again 
the
-  values from the tsc2007.
+  values from the tsc2007 (default 1).
 
 [0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 [1]: Documentation/devicetree/bindings/gpio/gpio.txt
+[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 
 Example:
 {
@@ -35,6 +39,8 @@ Example:
interrupts = <0x0 0x8>;
gpios = < 0 0>;
ti,x-plate-ohms = <180>;
+   touchscreen-size-x = <640>;
+   touchscreen-size-y = <480>;
};
 
/* ... */
diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index 5d0cd51..c1d9593 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TSC2007_MEASURE_TEMP0  (0x0 << 4)
 #define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -74,6 +75,14 @@ struct tsc2007 {
 
u16 model;
u16 x_plate_ohms;
+
+   struct touchscreen_properties prop;
+
+   boolreport_resistance;
+   u16 min_x;
+   u16 min_y;
+   u16 max_x;
+   u16 max_y;
u16 max_rt;
unsigned long   poll_period; /* in jiffies */
int fuzzx;
@@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct 
ts_event *tc)
tsc2007_xfer(tsc, PWRDOWN);
 }
 
-static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc)
+static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+   struct ts_event *tc)
 {
u32 rt = 0;
 
@@ -177,12 +187,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
struct ts_event tc;
u32 rt;
 
+   

[PATCH v4 2/8] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does

[H. Nikolaus Schaller]

this should reduce unnecessary input events.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/tsc2007.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index c1d9593..e9d5086 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -94,6 +94,7 @@ struct tsc2007 {
 
wait_queue_head_t   wait;
boolstopped;
+   boolpendown;
 
int (*get_pendown_state)(struct device *);
void(*clear_penirq)(void);
@@ -227,7 +228,11 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
sx, sy, rt);
 
/* report event */
-   input_report_key(input, BTN_TOUCH, 1);
+   if (!ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 1);
+   ts->pendown = true;
+   }
+
touchscreen_report_pos(ts->input, >prop,
(unsigned int) sx,
(unsigned int) sy,
@@ -250,9 +255,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
 
dev_dbg(>client->dev, "UP\n");
 
-   input_report_key(input, BTN_TOUCH, 0);
-   input_report_abs(input, ABS_PRESSURE, 0);
-   input_sync(input);
+   if (ts->pendown) {
+   input_report_key(input, BTN_TOUCH, 0);
+   input_report_abs(input, ABS_PRESSURE, 0);
+   input_sync(input);
+
+   ts->pendown = false;
+   }
 
if (ts->clear_penirq)
ts->clear_penirq();
-- 
2.7.3

Re: MD-RAID: Use seq_putc() in three status functions?

[Hannes Reinecke]

On 10/17/2016 01:43 PM, SF Markus Elfring wrote:
 See above. At the moment _any_ test result from your side would do.
>>>
>>> I imagine that another single result might not be representative.
>>
>> Publish not only results but also everything (complete!) so that anyone
>> can *easily* follow it to check and reproduce the results - especially
>> if you want people with knowledge of other architectures to comment
>> (otherwise they probably won't bother).
> 
> Am I the only software developer so far who would dare to reconsider
> implementation details from three status functions?
> 
No.
But we're waiting for you showing is that it is an improvement.
Which at the moment we don't see.
Hence we're waiting from a proof or validation from your side.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[PATCH v4 6/8] drivers:input:ads7846(+tsc2046): add new common binding names, pre-calibration and flipping

[H. Nikolaus Schaller]

commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.

commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted / 
swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.

Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.

A new feature is to introduce scaling the min/max ADC values to the screen
size.

This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Signed-off-by: H. Nikolaus Schaller 
---
 .../devicetree/bindings/input/ads7846.txt  |  9 +++-
 drivers/input/touchscreen/ads7846.c| 60 ++
 2 files changed, 57 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/ads7846.txt 
b/Documentation/devicetree/bindings/input/ads7846.txt
index 9fc47b0..29f91ed 100644
--- a/Documentation/devicetree/bindings/input/ads7846.txt
+++ b/Documentation/devicetree/bindings/input/ads7846.txt
@@ -26,6 +26,12 @@ Additional required properties:
 
 Optional properties:
 
+You can optionally specify any of the touchscreen parameters described in
+
+   Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+
+This allows to scale, invert or swap coordinates and define the fuzz factors.
+
ti,vref-delay-usecs vref supply delay in usecs, 0 for
external vref (u16).
ti,vref-mv  The VREF voltage, in millivolts (u16).
@@ -33,7 +39,7 @@ Optional properties:
(ADS7846).
ti,keep-vref-on set to keep vref on for differential
measurements as well
-   ti,swap-xy  swap x and y axis
+   ti,swap-xy  deprecated name for 
touchscreen-swapped-x-y
ti,settle-delay-usecSettling time of the analog signals;
a function of Vcc and the capacitance
on the X/Y drivers.  If set to non-zero,
@@ -82,6 +88,7 @@ Example for a TSC2046 chip connected to an McSPI controller 
of an OMAP SoC::
pendown-gpio = < 8 0>;
vcc-supply = <_vcc3>;
 
+   touchscreen-swapped-x-y;
ti,x-min = /bits/ 16 <0>;
ti,x-max = /bits/ 16 <8000>;
ti,y-min = /bits/ 16 <0>;
diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 1ce3ecb..400e421 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -109,8 +110,13 @@ struct ads7846 {
u16 vref_delay_usecs;
u16 x_plate_ohms;
u16 pressure_max;
+   u16 x_min;
+   u16 x_max;
+   u16 y_min;
+   u16 y_max;
+
+   struct touchscreen_properties prop;
 
-   boolswap_xy;
booluse_internal;
 
struct ads7846_packet   *packet;
@@ -825,22 +831,36 @@ static void ads7846_report_state(struct ads7846 *ts)
 */
if (Rt) {
struct input_dev *input = ts->input;
+   int sx, sy;
+
+   dev_dbg(>spi->dev,
+   "Raw point(%4d,%4d), pressure (%4u)\n",
+   x, y, Rt);
+
+   /* scale ADC values to desired output range */
+   sx = (ts->prop.max_x * (x - ts->x_min))
+   / (ts->x_max - ts->x_min);
+   sy = (ts->prop.max_y * (y - ts->y_min))
+   / (ts->y_max - ts->y_min);
 
-   if (ts->swap_xy)
-   swap(x, y);
+   dev_dbg(>spi->dev,
+   "Scaled point(%4d,%4d), pressure (%4u)\n",
+   sx, sy, Rt);
 
+   /* report event */
if (!ts->pendown) {
input_report_key(input, BTN_TOUCH, 1);
ts->pendown = true;
dev_vdbg(>spi->dev, "DOWN\n");
}
 
-   input_report_abs(input, ABS_X, x);
-   input_report_abs(input, ABS_Y, y);
+   touchscreen_report_pos(ts->input, >prop,
+  (unsigned int) sx, (unsigned int) 

[PATCH v4 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Changes V4:
* fix a merge/squash issue resulting in a non-bisectable patch set (suggested 
by kbuid test robot)
* remove some unnecessary #include (suggested by Jonathan Cameron 
)
* make the iio extension depend on CONFIG_IIO rather than selecting it 
(suggested by Jonathan Cameron )
* swapped patch 3/n and patch 4/n to remove internal dependency

2016-09-23 14:41:23: Changes V3:
* fix an issue with swapping
* remove hard clipping to min/max rectangle - some systems expect to handle 
negative coordinates
* make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for 
inverted / swapped axes")

2015-11-13 21:36:07: Changes V2:
* add a patch to make drivers still recognise the old "ti,swap-xy" property 
(suggested by Rob Herring)

2015-11-06 16:14:53: This patch series improves the drivers for the tsc2007 and
ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
OpenPandora and Pyra devices.

New common bindings have been defined by
commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):

Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

which also defines a helper function to parse the DT. These new parameters
allow to specify the fuzz factors (jitter suppression), inversion of x or y 
axis and
swapping of x and y to achieve inversion and rotation so that the touch
coordinate axes match the natural orientation of the display panel.

Another improvement is to better use the min/max ADC values and
scale to the screen size as defined by the DT. This allows to coarsely
calibrate the touch to match the LCD to which it is glued on so that the
touch can quite precisely be operated before any user-space fine-calibration
can be (and needs to be) started.

For the adc7846 we fix an issue with the spi module table.

Finally we add an iio interface for the AUX and temperature ADC channels of
the tsc2007 and also provide the touch screen raw values. This allows to read
an optional ambient light sensor installed on the gta04 board and improves
calibration and hardware monitoring.


H. Nikolaus Schaller (8):
  drivers:input:tsc2007: add new common binding names, pre-calibration,
flipping and rotation
  drivers:input:tsc2007: send pendown and penup only once like
ads7846(+tsc2046) driver does
  drivers:input:tsc2007: check for presence and power down tsc2007
during probe
  drivers:input:tsc2007: add iio interface to read external ADC input
and temperature
  DT:omap3+tsc2007: use new common touchscreen bindings
  drivers:input:ads7846(+tsc2046): add new common binding names,
pre-calibration and flipping
  drivers:input:ads7846(+tsc2046): fix spi module table
  DT:omap3+ads7846: use new common touchscreen bindings

 .../devicetree/bindings/input/ads7846.txt  |   9 +-
 .../bindings/input/touchscreen/tsc2007.txt |  20 +-
 arch/arm/boot/dts/omap3-gta04.dtsi |  25 +-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|   2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi|  17 +-
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi|   3 +-
 drivers/input/touchscreen/ads7846.c|  71 -
 drivers/input/touchscreen/tsc2007.c| 297 +++--
 include/linux/i2c/tsc2007.h|   8 +
 9 files changed, 397 insertions(+), 55 deletions(-)

-- 
2.7.3

Re: [PATCH v3 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Sebastian,
I did wait for the 4.9-rc1 merge window to be closed until I bring up this patch
set again.

> Am 30.09.2016 um 16:40 schrieb H. Nikolaus Schaller :
>> 
>> I do agree with Rob, that the ti,min/max-x/y should become common,
>> though. Also I would do s/minimum value/minimum raw value/g.
> 
> Yes, that is a good idea!
> 
> To me it seems as if "minimum-raw-value-x", "maximum-raw-value-y" could be 
> good.
> 
> Or is the string too long (then we can drop the "-value" or the "imum")? It
> might blow up the DTB and string constant for finding the property?
> 
> If we come to some consensus on this, I can update the patch set.

Now when updating the patch set, I found that using ti,min/max-x/y was not 
really
a new invention. It is already upstream for a while for the ads7846/2046 driver!

This means: by introducing these properties to the tsc2007 as well we just 
extend the
already defined use of ti,min/max-x/y.

Simply changing that as well to use some minimum-raw-value-x etc. would break 
ads7846/2046
boards not in mainline or need ugly code to handle property alias names.

And since they are raw data and quite chip-specific, I think there is no urgent 
need
for harmonization of raw device data. While using the common bindings for output
scaling and fuzz, swap etc. is very important and helpful for board designers.

So I would prefer if we can keep it as is for the moment. And make property name
harmonization and evolution a separate task and discussion.

I will submit v4 in a couple of minutes. It contains some other small fixes as
suggested by the previous discussion.

BR and thanks,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: MD-RAID: Use seq_putc() in three status functions?

[Hannes Reinecke]

On 10/17/2016 01:10 PM, SF Markus Elfring wrote:
>>> * Is a string pointer often longer than a byte?
>>>
>> Always.
> 
> I have got doubts for this specific information.
> 
> 
>> (Which up to now I thought was basic programming knowledge...)
> 
> By the way:
> Run time environments still exist where the size of a pointer can be also
> just one byte, don't they?
> 
Really? Name one.
You can only fit a point in one byte if you are on an 8-bit system.
Which I don't think linux is running on.

>>> How many results would we like to clarify from various hardware
>>> and software combinations?
>>>
>> See above. At the moment _any_ test result from your side would do.
> 
> I imagine that another single result might not be representative.
> How many lessons from test statistics will usually be also relevant here?
> 
> 
As said above, _any_ statistic will do at this point.

>>> How important are the mentioned functions for you within the Linux
>>> programming interface so far?
>>>
>> Not very. The interface is only used in a slow path, and the execution
>> time doesn't affect I/O performance in any way.
> 
> Thanks for another interesting information.
> 
> 
 Case in point: with your patch the x86_64 compiler generates nearly
 identical code for driver/md/raid1.c, but with one instruction _more_
 after your patch has been applied.
>>>
>>> Which software versions and command parameters did you try out
>>> for this information (from an unspecified run time environment)?
>>>
>> # gcc --version
>> gcc (SUSE Linux) 4.8.5
> 
> Thanks for this detail.
> 
> * Did you choose any special optimisation settings for your quick check?
> 
> * Will any compilation results matter if "optimisation" would be
>   switched off there?
> 
> 
These were the results when calling 'make' in the kernel source tree.
With all applicable options.

>> I'm still waiting from results from your side.
> 
> Would any other software developers or testers dare to add related 
> information?
> 
No. It's your patch, _you_ have to do it.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[PATCH 0/7] net: Fix module autoload for several platform drivers

[Javier Martinez Canillas]

Hello David,

I noticed that module autoload won't be working in a bunch of platform
drivers in the net subsystem and this patch series contains the fixes.

Best regards,
Javier


Javier Martinez Canillas (7):
  net: nps_enet: Fix module autoload
  net: ethernet: nb8800: Fix module autoload
  net: hns: Fix hns_dsaf module autoload for OF registration
  net: qcom/emac: Fix module autoload for OF registration
  net: hisilicon: Fix hns_mdio module autoload for OF registration
  net: dsa: b53: Fix module autoload
  net: dsa: bcm_sf2: Fix module autoload for OF registration

 drivers/net/dsa/b53/b53_mmap.c | 1 +
 drivers/net/dsa/bcm_sf2.c  | 1 +
 drivers/net/ethernet/aurora/nb8800.c   | 1 +
 drivers/net/ethernet/ezchip/nps_enet.c | 1 +
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 1 +
 drivers/net/ethernet/hisilicon/hns_mdio.c  | 1 +
 drivers/net/ethernet/qualcomm/emac/emac.c  | 1 +
 7 files changed, 7 insertions(+)

-- 
2.7.4

[PATCH v2 0/2] spi, i2c: mark device nodes only in case of successful instantiation

[Ralf Ramsauer]

Hi,

this one fixes initialisation of I2C/SPI nodes.  Upon failure during
intialisation, nodes were erroneously populated and never unmarked.

This lead to the problem that re-loaded drivers will never probe those devices
again and can easily be fixed by clearing the OF_POPULATE flag when the node
doesn't successfully initialise.

For the discussion of v1, see
https://lkml.org/lkml/2016/10/14/483

  Ralf

changes since v1:
  - also fix I2C core driver
  - keep the atomic test-and-set, as Geert suggested

Ralf Ramsauer (2):
  spi: mark device nodes only in case of successful instantiation
  i2c: mark device nodes only in case of successful instantiation

 drivers/i2c/i2c-core.c | 11 ++-
 drivers/spi/spi.c  |  5 -
 2 files changed, 14 insertions(+), 2 deletions(-)

-- 
2.10.1

Re: [PATCH] btrfs: assign error values to the correct bio structs

[David Sterba]

On Mon, Oct 17, 2016 at 09:20:25AM +0800, Junjie Mao wrote:
> Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio")
> 
> Signed-off-by: Junjie Mao 

Ack, but please resend it with CC: sta...@vger.kernel.org # 4.3+

[PATCH v4 3/8] drivers:input:tsc2007: check for presence and power down tsc2007 during probe

[H. Nikolaus Schaller]

1. check if chip is really present and don't succeed if it isn't.
2. if it succeeds, power down the chip until accessed

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/tsc2007.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/input/touchscreen/tsc2007.c 
b/drivers/input/touchscreen/tsc2007.c
index e9d5086..c314331 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -538,6 +538,15 @@ static int tsc2007_probe(struct i2c_client *client,
 
tsc2007_stop(ts);
 
+   /* power down the chip (TSC2007_SETUP does not ACK on I2C) */
+   err = tsc2007_xfer(ts, PWRDOWN);
+   if (err < 0) {
+   dev_err(>dev,
+   "Failed to setup chip: %d\n", err);
+   iio_device_unregister(indio_dev);
+   return err; /* usually, chip does not respond */
+   }
+
err = input_register_device(input_dev);
if (err) {
dev_err(>dev,
-- 
2.7.3

[PATCH 1/7] net: nps_enet: Fix module autoload

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/net/ethernet/ezchip/nps_enet.ko | grep alias
$

After this patch:

$ modinfo drivers/net/ethernet/ezchip/nps_enet.ko | grep alias
alias:  of:N*T*Cezchip,nps-mgt-enetC*
alias:  of:N*T*Cezchip,nps-mgt-enet

Signed-off-by: Javier Martinez Canillas 
---

 drivers/net/ethernet/ezchip/nps_enet.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/ezchip/nps_enet.c 
b/drivers/net/ethernet/ezchip/nps_enet.c
index f928e6f79c89..223f35cc034c 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -669,6 +669,7 @@ static const struct of_device_id nps_enet_dt_ids[] = {
{ .compatible = "ezchip,nps-mgt-enet" },
{ /* Sentinel */ }
 };
+MODULE_DEVICE_TABLE(of, nps_enet_dt_ids);
 
 static struct platform_driver nps_enet_driver = {
.probe = nps_enet_probe,
-- 
2.7.4

[PATCH 2/7] net: ethernet: nb8800: Fix module autoload

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ $ modinfo drivers/net/ethernet/aurora/nb8800.ko | grep alias
$

After this patch:

$ modinfo drivers/net/ethernet/aurora/nb8800.ko | grep alias
alias:  of:N*T*Csigma,smp8734-ethernetC*
alias:  of:N*T*Csigma,smp8734-ethernet
alias:  of:N*T*Csigma,smp8642-ethernetC*
alias:  of:N*T*Csigma,smp8642-ethernet
alias:  of:N*T*Caurora,nb8800C*
alias:  of:N*T*Caurora,nb8800

Signed-off-by: Javier Martinez Canillas 
---

 drivers/net/ethernet/aurora/nb8800.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/aurora/nb8800.c 
b/drivers/net/ethernet/aurora/nb8800.c
index 453dc0967125..d5f2ad1a5a30 100644
--- a/drivers/net/ethernet/aurora/nb8800.c
+++ b/drivers/net/ethernet/aurora/nb8800.c
@@ -1357,6 +1357,7 @@ static const struct of_device_id nb8800_dt_ids[] = {
},
{ }
 };
+MODULE_DEVICE_TABLE(of, nb8800_dt_ids);
 
 static int nb8800_probe(struct platform_device *pdev)
 {
-- 
2.7.4

[PATCH v4 8/8] DT:omap3+ads7846: use new common touchscreen bindings

[H. Nikolaus Schaller]

The standard touch screen bindings [1] replace the private ti,swap-xy
with touchscreen-swaped-x-y. And for the Openpandora we use
touchscreen-size etc. to match the LCD screen size.

[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt

Tested with OpenPandora.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi  |  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi  | 17 +
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi |  3 ++-
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index fa611a5..b8b3864 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -325,7 +325,7 @@
ti,y-max = /bits/ 16 <3600>;
ti,x-plate-ohms = /bits/ 16 <80>;
ti,pressure-max = /bits/ 16 <255>;
-   ti,swap-xy;
+   touchscreen-swapped-x-y;
 
wakeup-source;
};
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index b0d1551..d12008a 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -700,10 +700,19 @@
pendown-gpio = < 30 GPIO_ACTIVE_HIGH>;
vcc-supply = <>;
 
-   ti,x-min = /bits/ 16 <0>;
-   ti,x-max = /bits/ 16 <8000>;
-   ti,y-min = /bits/ 16 <0>;
-   ti,y-max = /bits/ 16 <4800>;
+   touchscreen-size-x = <800>;
+   touchscreen-size-y = <480>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <16>;
+   touchscreen-fuzz-y = <16>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-x;
+   touchscreen-inverted-y;
+
+   ti,x-min = /bits/ 16 <160>;
+   ti,x-max = /bits/ 16 <3900>;
+   ti,y-min = /bits/ 16 <220>;
+   ti,y-max = /bits/ 16 <3750>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
 
diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi 
b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index 157345b..3627a63 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -66,6 +66,7 @@
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
ti,swap-xy;
-   wakeup-source;
+   touchscreen-swapped-x-y;
+   linux,wakeup;
};
 };
-- 
2.7.3

[PATCH 6/7] net: dsa: b53: Fix module autoload

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/net/dsa/b53/b53_mmap.ko  | grep alias
$

After this patch:

$ modinfo drivers/net/dsa/b53/b53_mmap.ko  | grep alias
alias:  of:N*T*Cbrcm,bcm63xx-switchC*
alias:  of:N*T*Cbrcm,bcm63xx-switch
alias:  of:N*T*Cbrcm,bcm6368-switchC*
alias:  of:N*T*Cbrcm,bcm6368-switch
alias:  of:N*T*Cbrcm,bcm6328-switchC*
alias:  of:N*T*Cbrcm,bcm6328-switch
alias:  of:N*T*Cbrcm,bcm3384-switchC*
alias:  of:N*T*Cbrcm,bcm3384-switch

Signed-off-by: Javier Martinez Canillas 
---

 drivers/net/dsa/b53/b53_mmap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/dsa/b53/b53_mmap.c b/drivers/net/dsa/b53/b53_mmap.c
index 76fb8552c9d9..ef63d24fef81 100644
--- a/drivers/net/dsa/b53/b53_mmap.c
+++ b/drivers/net/dsa/b53/b53_mmap.c
@@ -256,6 +256,7 @@ static const struct of_device_id b53_mmap_of_table[] = {
{ .compatible = "brcm,bcm63xx-switch" },
{ /* sentinel */ },
 };
+MODULE_DEVICE_TABLE(of, b53_mmap_of_table);
 
 static struct platform_driver b53_mmap_driver = {
.probe = b53_mmap_probe,
-- 
2.7.4

[PATCH 7/7] net: dsa: bcm_sf2: Fix module autoload for OF registration

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/net/dsa/bcm_sf2.ko | grep alias
alias:  platform:brcm-sf2

After this patch:

$ modinfo drivers/net/dsa/bcm_sf2.ko | grep alias
alias:  platform:brcm-sf2
alias:  of:N*T*Cbrcm,bcm7445-switch-v4.0C*
alias:  of:N*T*Cbrcm,bcm7445-switch-v4.0

Signed-off-by: Javier Martinez Canillas 

---

 drivers/net/dsa/bcm_sf2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index e218887f18b7..0427009bc924 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1158,6 +1158,7 @@ static const struct of_device_id bcm_sf2_of_match[] = {
{ .compatible = "brcm,bcm7445-switch-v4.0" },
{ /* sentinel */ },
 };
+MODULE_DEVICE_TABLE(of, bcm_sf2_of_match);
 
 static struct platform_driver bcm_sf2_driver = {
.probe  = bcm_sf2_sw_probe,
-- 
2.7.4

[PATCH v4 7/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Fix module table so that the driver is loaded if compiled
as module and requested by DT.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/input/touchscreen/ads7846.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index 400e421..9a5d84d 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1532,6 +1532,17 @@ static int ads7846_remove(struct spi_device *spi)
return 0;
 }
 
+static const struct spi_device_id ads7846_idtable[] = {
+   { "tsc2046", 0 },
+   { "ads7843", 0 },
+   { "ads7845", 0 },
+   { "ads7846", 0 },
+   { "ads7873", 0 },
+   { }
+};
+
+MODULE_DEVICE_TABLE(spi, ads7846_idtable);
+
 static struct spi_driver ads7846_driver = {
.driver = {
.name   = "ads7846",
-- 
2.7.3

[PATCH 5/7] net: hisilicon: Fix hns_mdio module autoload for OF registration

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/net/ethernet/hisilicon//hns_mdio.ko | grep alias
alias:  platform:Hi-HNS_MDIO
alias:  acpi*:HISI0141:*

After this patch:

$ modinfo drivers/net/ethernet/hisilicon//hns_mdio.ko | grep alias
alias:  platform:Hi-HNS_MDIO
alias:  of:N*T*Chisilicon,hns-mdioC*
alias:  of:N*T*Chisilicon,hns-mdio
alias:  of:N*T*Chisilicon,mdioC*
alias:  of:N*T*Chisilicon,mdio
alias:  acpi*:HISI0141:*

Signed-off-by: Javier Martinez Canillas 
---

 drivers/net/ethernet/hisilicon/hns_mdio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/hisilicon/hns_mdio.c 
b/drivers/net/ethernet/hisilicon/hns_mdio.c
index 33f4c483af0f..501eb2090ca6 100644
--- a/drivers/net/ethernet/hisilicon/hns_mdio.c
+++ b/drivers/net/ethernet/hisilicon/hns_mdio.c
@@ -563,6 +563,7 @@ static const struct of_device_id hns_mdio_match[] = {
{.compatible = "hisilicon,hns-mdio"},
{}
 };
+MODULE_DEVICE_TABLE(of, hns_mdio_match);
 
 static const struct acpi_device_id hns_mdio_acpi_match[] = {
{ "HISI0141", 0 },
-- 
2.7.4

[PATCH v4 5/8] DT:omap3+tsc2007: use new common touchscreen bindings

[H. Nikolaus Schaller]

While we fix the GTA04 we add proper pinmux for the
penirq gpio.

Tested on: GTA04A4 and Pyra-Handheld

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index b3a8b1f..64d6ee3 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -273,6 +273,13 @@
OMAP3_CORE1_IOPAD(0x2134, PIN_INPUT_PULLUP | MUX_MODE4) 
/* gpio112 */
>;
};
+
+   penirq_pins: pinmux_penirq_pins {
+   pinctrl-single,pins = <
+   /* here we could enable to wakeup the cpu from suspend 
by a pen touch */
+   OMAP3_CORE1_IOPAD(0x2194, PIN_INPUT_PULLUP | MUX_MODE4) 
/* gpio160 */
+   >;
+   };
 };
 
 _pmx_core2 {
@@ -410,10 +417,24 @@
tsc2007@48 {
compatible = "ti,tsc2007";
reg = <0x48>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
interrupt-parent = <>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
-   gpios = < 0 GPIO_ACTIVE_LOW>;
-   ti,x-plate-ohms = <600>;
+   gpios = < 0 GPIO_ACTIVE_LOW>; /* GPIO_160 */
+   touchscreen-size-x = <480>;
+   touchscreen-size-y = <640>;
+   touchscreen-max-pressure = <1000>;
+   touchscreen-fuzz-x = <3>;
+   touchscreen-fuzz-y = <8>;
+   touchscreen-fuzz-pressure = <10>;
+   touchscreen-inverted-y;
+   ti,min-x = <0x100>;
+   ti,max-x = <0xf00>;
+   ti,min-y = <0x100>;
+   ti,max-y = <0xf00>;
+   ti,max-rt = <4096>;
+   ti,x-plate-ohms = <550>;
};
 
/* RFID EEPROM */
-- 
2.7.3

Re: [PATCH 04/27] perf list: Add support for listing only json events

[Andi Kleen]

> What we do know about the CPU vendor event names is that they are vendor 
> specific, 
> and that's a pretty stable property. So my suggestion would be to simply make 
> it:
> 
>   perf list vendor
> 
> with perhaps add aliases as well:
> 
>   perf list model
>   perf list cpu-model
> 
> ... and 'perf list hardware' should probably also list all the vendor 
> specific 
> hardware events as well.

Sure can change it.

> 
> Could we please work a bit more on making vendor specific hardware event 
> handling 
> more usable to people who don't care about internals?

Do you prefer fully new patches, or are incremential patches ok? 

-Andi

Re: [PATCH] MIPS: KASLR: Fix handling of NULL FDT

[Sergei Shtylyov]

Hello.

On 10/17/2016 01:04 PM, Matt Redfearn wrote:


If platform code returns a NULL pointer to the FDT, initial_boot_params
will not get set to a valid pointer and attempting to find the /chosen
node in it will cause a NULL pointer dereference and the kernel to crash
immediately on startup - with no output to the console.

Fix this by checking that initial_boot_params is valid before using it.

Fixes: 405bc8fd12f5 ("MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE")
Cc:  # 4.7+
Signed-off-by: Matt Redfearn 
---

 arch/mips/kernel/relocate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
index ca1cc30c0891..8810183840ca 100644
--- a/arch/mips/kernel/relocate.c
+++ b/arch/mips/kernel/relocate.c
@@ -200,6 +200,7 @@ static inline __init unsigned long get_random_boot(void)

 #if defined(CONFIG_USE_OF)
/* Get any additional entropy passed in device tree */
+   if (initial_boot_params)
{


   CodingStyle: *if* and { should be on the same line.

[...]

MBR, Sergei

Re: [PATCH] shmem: avoid huge pages for small files

[Michal Hocko]

On Mon 17-10-16 15:30:21, Kirill A. Shutemov wrote:
[...]
> >From fd0b01b9797ddf2bef308c506c42d3dd50f11793 Mon Sep 17 00:00:00 2001
> From: "Kirill A. Shutemov" 
> Date: Mon, 17 Oct 2016 14:44:47 +0300
> Subject: [PATCH] shmem: avoid huge pages for small files
> 
> Huge pages are detrimental for small file: they causes noticible
> overhead on both allocation performance and memory footprint.
> 
> This patch aimed to address this issue by avoiding huge pages until file
> grown to specified size. This would cover most of the cases where huge
> pages causes regressions in performance.
> 
> By default the minimal file size to allocate huge pages is equal to size
> of huge page.

ok

> We add two handle to specify minimal file size for huge pages:
> 
>   - mount option 'huge_min_size';
> 
>   - sysfs file /sys/kernel/mm/transparent_hugepage/shmem_min_size for
> in-kernel tmpfs mountpoint;

Could you explain who might like to change the minimum value (other than
disable the feautre for the mount point) and for what reason?

[...]

> @@ -238,6 +238,12 @@ values:
>- "force":
>  Force the huge option on for all - very useful for testing;
>  
> +Tehre's limit on minimal file size before kenrel starts allocate huge
> +pages for it. By default it's size of huge page.

Smoe tyopse
-- 
Michal Hocko
SUSE Labs

Re: [RFC] [PATCH] Add a "nolinks" mount option.

[Austin S. Hemmelgarn]

On 2016-10-17 09:02, Mattias Nissler wrote:

OK, no more feedback thus far. Is there generally any interest in a
mount option to avoid path name aliasing resulting in target file
confusion? Perhaps a version that only disables symlinks instead of
also hard-disabling files hard-linked to multiple locations (those are
much lower risk for the situation I care about)?

If there is interest, I'm happy to iterate the patch until it's
accepted. If there's no interest, that's fine too - I'll then likely
resort to moving the restrictions desired for Chrome OS into an LSM we
compile into our kernels.
I can see the symlink related part potentially being useful in other 
cases, although if you do get rid of the hardlink portion, I'd suggest 
renaming the mount option to 'nosymlinks'.


One use that comes to mind is securing multi-protocol file servers (for 
example, something serving both NFS and SMB) where at least one protocol 
doesn't directly handle symlinks (or there is inconsistency among the 
protocols in how they're handled).


On Fri, Oct 14, 2016 at 6:22 PM, Mattias Nissler  wrote:

Forgot to mention: I realize my motivation is very specific to Chrome
OS, however the nolinks option seemed useful also as a mitigation to
generic privilege escalation symlink attacks, for cases where
disabling symlinks/hardlinks is acceptable.

On Fri, Oct 14, 2016 at 5:50 PM, Mattias Nissler  wrote:

On Fri, Oct 14, 2016 at 5:00 PM, Al Viro  wrote:


On Fri, Oct 14, 2016 at 03:55:15PM +0100, Al Viro wrote:

Setting the "nolinks" mount option helps prevent privileged writers
from modifying files unintentionally in case there is an unexpected
link along the accessed path. The "nolinks" option is thus useful as a
defensive measure against persistent exploits (i.e. a system getting
re-exploited after a reboot) for systems that employ a read-only or
dm-verity-protected rootfs. These systems prevent non-legit binaries
from running after reboot. However, legit code typically still reads
from and writes to a writable file system previously under full
control of the attacker, who can place symlinks to trick file writes
after reboot to target a file of their choice. "nolinks" fundamentally
prevents this.


Which parts of the tree would be on that "protected" rootfs and which would
you mount with that option?  Description above is rather vague and I'm
not convinced that it actually buys you anything.  Details, please...


Apologies for the vague description, I'm happy to explain in detail.

In case of Chrome OS, we have all binaries on a dm-verity rootfs, so
an attacker can't modify any binaries. After reboot, everything except
the rootfs is mounted noexec, so there's no way to re-gain code
execution after reboot by modifying existing binaries or dropping new
ones.

We've seen multiple exploits now where the attacker worked around
these limitations in two steps:

1. Before reboot, the attacker sets up symlinks on the writeable file
system (called "stateful" file system), which are later accessed by
legit boot code (such as init scripts) after reboot. For example, an
init script that copies file A to B can be abused by an attacker by
symlinking or hardlinking B to a location C of their choice, and
placing desired data to be written to C in A. That gives the attacker
a primitive to write data of their choice to a path of their choice
after reboot. Note that this primitive may target locations _outside_
the stateful file system the attacker previously had control of.
Particularly of interest are targets on /sys, but also tmpfs on /run
etc.

2. The second step for a successful attack is finding some legit code
invoked in the boot flow that has a vulnerability exploitable by
feeding it unexpected data. As an example, there are Linux userspace
utilities that read config from /run which may contain shell commands
the the utility executes, through which the attacker can gain code
execution again.

The purpose of the proposed patch is to raise the bar for the first
step of the attack: Writing arbitrary files after reboot. I'm
intending to mount the stateful file system with the nolinks option
(or otherwise prevent symlink traversal). This will help make sure
that any legit writes taking place during boot in init scripts etc. go
to the files intended by the developer, and can't be redirected by an
attacker.

Does this make more sense to you?




PS: what the hell do restrictions on _following_ symlinks have to _creating_
hardlinks?  I'm trying to imagine a threat model where both would apply or
anything else beyond the word "link" they would have in common...


The restriction is not on _creating_ hard links, but _opening_
hardlinks. The commonality is in the confusion between the file you're
meaning to write vs. the file you actually end up writing to, which
stems from the fact that as things stand a file can be accessible on
other paths than its canonical one. For Chrome OS, I'd like to get to
a point where most privileged code can only access 

Re: [PATCH v2 1/2] spi: mark device nodes only in case of successful instantiation

[Geert Uytterhoeven]

On Mon, Oct 17, 2016 at 3:59 PM, Ralf Ramsauer
 wrote:
> Instantiated SPI device nodes are marked with OF_POPULATE. This was
> introduced in bd6c164. On unloading, loaded device nodes will of course
> be unmarked. The problem are nodes that fail during initialisation: If a
> node fails, it won't be unloaded and hence not be unmarked.
>
> If a SPI driver module is unloaded and reloaded, it will skip nodes that
> failed before.
>
> Skip device nodes that are already populated and mark them only in case
> of success.
>
> Note that the same issue exists for I2C.
>
> Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
> Signed-off-by: Ralf Ramsauer 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 2/7] net: ethernet: nb8800: Fix module autoload

[Måns Rullgård]

Javier Martinez Canillas  writes:

> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ $ modinfo drivers/net/ethernet/aurora/nb8800.ko | grep alias
> $
>
> After this patch:
>
> $ modinfo drivers/net/ethernet/aurora/nb8800.ko | grep alias
> alias:  of:N*T*Csigma,smp8734-ethernetC*
> alias:  of:N*T*Csigma,smp8734-ethernet
> alias:  of:N*T*Csigma,smp8642-ethernetC*
> alias:  of:N*T*Csigma,smp8642-ethernet
> alias:  of:N*T*Caurora,nb8800C*
> alias:  of:N*T*Caurora,nb8800
>
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Mans Rullgard 

> ---
>
>  drivers/net/ethernet/aurora/nb8800.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/aurora/nb8800.c 
> b/drivers/net/ethernet/aurora/nb8800.c
> index 453dc0967125..d5f2ad1a5a30 100644
> --- a/drivers/net/ethernet/aurora/nb8800.c
> +++ b/drivers/net/ethernet/aurora/nb8800.c
> @@ -1357,6 +1357,7 @@ static const struct of_device_id nb8800_dt_ids[] = {
>   },
>   { }
>  };
> +MODULE_DEVICE_TABLE(of, nb8800_dt_ids);
>
>  static int nb8800_probe(struct platform_device *pdev)
>  {
> -- 

-- 
Måns Rullgård

Re: [patch] drivers,connector: Protect send_msg() with a local lock for RT

[Sebastian Andrzej Siewior]

On 2016-10-16 05:11:54 [+0200], Mike Galbraith wrote:
> 

applied with smaller changes. This is v4.8-RT only.

Sebastian

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

[Oliver Neukum]

On Thu, 2016-09-08 at 14:58 +0200, Wim Osterholt wrote:
> On Thu, Sep 08, 2016 at 02:20:38PM +0200, Oliver Neukum wrote:
> > > 
> > > The oops tells things that I didn't all write down, but it says
> > > null pointer dereference at 0246
> > 
> > That is the important part. I am sorry, but without the oops
> > nobody can help you. Please capture it

Hi,

I got one of those devices. However, I don't get a crash.
Could you please give me instructions on how you trigger it?

Regards
Oliver

Re: [PATCH v2 2/2] i2c: mark device nodes only in case of successful instantiation

[Geert Uytterhoeven]

On Mon, Oct 17, 2016 at 3:59 PM, Ralf Ramsauer
 wrote:
> Instantiated I2C device nodes are marked with OF_POPULATE. This was
> introduced in 4f001fd. On unloading, loaded device nodes will of course
> be unmarked. The problem are nodes that fail during initialisation: If a
> node fails, it won't be unloaded and hence not be unmarked.
>
> If a I2C driver module is unloaded and reloaded, it will skip nodes that
> failed before.
>
> Skip device nodes that are already populated and mark them only in case
> of success.
>
> Note that the same issue exists for SPI.
>
> Fixes: 4f001fd ("i2c: Mark instantiated device nodes with OF_POPULATE")
> Signed-off-by: Ralf Ramsauer 

Reviewed-by: Geert Uytterhoeven 

> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c

> @@ -1695,7 +1696,14 @@ static void of_i2c_register_devices(struct i2c_adapter 
> *adap)
> for_each_available_child_of_node(bus, node) {
> if (of_node_test_and_set_flag(node, OF_POPULATED))
> continue;
> -   of_i2c_register_device(adap, node);
> +
> +   client = of_i2c_register_device(adap, node);
> +   if (IS_ERR(client)) {
> +   dev_warn(>dev,
> +"Failed to create I2C device for %s\n",
> +node->full_name);

I don't think there's a need to add this warning, as of_i2c_register_device()
already prints messages in all failure paths.

> +   of_node_clear_flag(node, OF_POPULATED);
> +   }
> }

Gr{oetje,eeting}s,

Geert

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

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

[PATCH 1/3] tools lib traceevent: Add -O2 option to traceevent

[Honggyu Kim]

Since current traceevent somehow does not have an optimization flag,
this patch just adds -O2 to optimize its code.

Signed-off-by: Honggyu Kim 
---
 tools/lib/traceevent/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/traceevent/Makefile b/tools/lib/traceevent/Makefile
index 7851df1..56d223b 100644
--- a/tools/lib/traceevent/Makefile
+++ b/tools/lib/traceevent/Makefile
@@ -124,7 +124,7 @@ else
 endif
 
 # Append required CFLAGS
-override CFLAGS += -fPIC
+override CFLAGS += -O2 -fPIC
 override CFLAGS += $(CONFIG_FLAGS) $(INCLUDES) $(PLUGIN_DIR_SQ)
 override CFLAGS += $(udis86-flags) -D_GNU_SOURCE
 
-- 
2.10.0.rc2.dirty

[PATCH 2/3] tools lib traceevent: Check the return value of asprintf

[Honggyu Kim]

Since asprintf generates a compiler warning when its return value is not
not properly handled, this patch checks that asprintf call is successful
or not.

Signed-off-by: Honggyu Kim 
---
 tools/lib/traceevent/parse-filter.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/tools/lib/traceevent/parse-filter.c 
b/tools/lib/traceevent/parse-filter.c
index 7c214ce..f0fcdcd 100644
--- a/tools/lib/traceevent/parse-filter.c
+++ b/tools/lib/traceevent/parse-filter.c
@@ -2122,7 +2122,8 @@ static char *op_to_str(struct event_filter *filter, 
struct filter_arg *arg)
default:
break;
}
-   asprintf(, val ? "TRUE" : "FALSE");
+   if (asprintf(, val ? "TRUE" : "FALSE") < 0)
+   return NULL;
break;
}
}
@@ -2140,7 +2141,8 @@ static char *op_to_str(struct event_filter *filter, 
struct filter_arg *arg)
break;
}
 
-   asprintf(, "(%s) %s (%s)", left, op, right);
+   if (asprintf(, "(%s) %s (%s)", left, op, right) < 0)
+   return NULL;
break;
 
case FILTER_OP_NOT:
@@ -2156,10 +2158,12 @@ static char *op_to_str(struct event_filter *filter, 
struct filter_arg *arg)
right_val = 0;
if (right_val >= 0) {
/* just return the opposite */
-   asprintf(, right_val ? "FALSE" : "TRUE");
+   if (asprintf(, right_val ? "FALSE" : "TRUE") < 0)
+   return NULL;
break;
}
-   asprintf(, "%s(%s)", op, right);
+   if (asprintf(, "%s(%s)", op, right) < 0)
+   return NULL;
break;
 
default:
@@ -2175,7 +2179,8 @@ static char *val_to_str(struct event_filter *filter, 
struct filter_arg *arg)
 {
char *str = NULL;
 
-   asprintf(, "%lld", arg->value.val);
+   if (asprintf(, "%lld", arg->value.val) < 0)
+   return NULL;
 
return str;
 }
@@ -2233,7 +2238,8 @@ static char *exp_to_str(struct event_filter *filter, 
struct filter_arg *arg)
break;
}
 
-   asprintf(, "%s %s %s", lstr, op, rstr);
+   if (asprintf(, "%s %s %s", lstr, op, rstr) < 0)
+   return NULL;
 out:
free(lstr);
free(rstr);
@@ -2277,7 +2283,8 @@ static char *num_to_str(struct event_filter *filter, 
struct filter_arg *arg)
if (!op)
op = "<=";
 
-   asprintf(, "%s %s %s", lstr, op, rstr);
+   if (asprintf(, "%s %s %s", lstr, op, rstr) < 0)
+   return NULL;
break;
 
default:
@@ -2312,8 +2319,9 @@ static char *str_to_str(struct event_filter *filter, 
struct filter_arg *arg)
if (!op)
op = "!~";
 
-   asprintf(, "%s %s \"%s\"",
-arg->str.field->name, op, arg->str.val);
+   if (asprintf(, "%s %s \"%s\"",
+arg->str.field->name, op, arg->str.val) < 0)
+   return NULL;
break;
 
default:
@@ -2329,7 +2337,8 @@ static char *arg_to_str(struct event_filter *filter, 
struct filter_arg *arg)
 
switch (arg->type) {
case FILTER_ARG_BOOLEAN:
-   asprintf(, arg->boolean.value ? "TRUE" : "FALSE");
+   if (asprintf(, arg->boolean.value ? "TRUE" : "FALSE") < 0)
+   return NULL;
return str;
 
case FILTER_ARG_OP:
-- 
2.10.0.rc2.dirty

Re: [Patch 06/35] media: ti-vpe: vpe: Do not perform job transaction atomically

[Hans Verkuil]

On 09/28/2016 11:20 PM, Benoit Parrot wrote:
> From: Nikhil Devshatwar 
> 
> Current VPE driver does not start the job until all the buffers for
> a transaction are not queued. When running in multiple context, this might

I think this should be: s/not queued/queued/, right?

> increase the processing latency.
> 
> Alternate solution would be to try to continue the same context as long as
> buffers for the transaction are ready; else switch the context. This may
> increase number of context switches but it reduces latency significantly.
> 
> In this approach, the job_ready always succeeds as long as there are
> buffers on the CAPTURE and OUTPUT stream. Processing may start immediately
> as the first 2 iterations don't need extra source buffers. Shift all the
> source buffers after each iteration and remove the oldest buffer.
> 
> Also, with this removes the constraint of pre buffering 3 buffers before
> call to STREAMON in case of de-interlacing.
> 
> Signed-off-by: Nikhil Devshatwar 
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/media/platform/ti-vpe/vpe.c | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/media/platform/ti-vpe/vpe.c 
> b/drivers/media/platform/ti-vpe/vpe.c
> index a0b29685fb69..9c38eff5df46 100644
> --- a/drivers/media/platform/ti-vpe/vpe.c
> +++ b/drivers/media/platform/ti-vpe/vpe.c
> @@ -898,15 +898,14 @@ static struct vpe_ctx *file2ctx(struct file *file)
>  static int job_ready(void *priv)
>  {
>   struct vpe_ctx *ctx = priv;
> - int needed = ctx->bufs_per_job;
>  
> - if (ctx->deinterlacing && ctx->src_vbs[2] == NULL)
> - needed += 2;/* need additional two most recent fields */
> -
> - if (v4l2_m2m_num_src_bufs_ready(ctx->fh.m2m_ctx) < needed)
> - return 0;
> -
> - if (v4l2_m2m_num_dst_bufs_ready(ctx->fh.m2m_ctx) < needed)
> + /*
> +  * This check is needed as this might be called directly from driver
> +  * When called by m2m framework, this will always satisy, but when

typo: satisfy

> +  * called from vpe_irq, this might fail. (src stream with zero buffers)
> +  */
> + if (v4l2_m2m_num_src_bufs_ready(ctx->fh.m2m_ctx) <= 0 ||
> + v4l2_m2m_num_dst_bufs_ready(ctx->fh.m2m_ctx) <= 0)
>   return 0;
>  
>   return 1;
> @@ -1116,19 +1115,20 @@ static void device_run(void *priv)
>   struct sc_data *sc = ctx->dev->sc;
>   struct vpe_q_data *d_q_data = >q_data[Q_DATA_DST];
>  
> - if (ctx->deinterlacing && ctx->src_vbs[2] == NULL) {
> - ctx->src_vbs[2] = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> - WARN_ON(ctx->src_vbs[2] == NULL);
> - ctx->src_vbs[1] = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> - WARN_ON(ctx->src_vbs[1] == NULL);
> - }
> -
>   ctx->src_vbs[0] = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
>   WARN_ON(ctx->src_vbs[0] == NULL);
>   ctx->dst_vb = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
>   WARN_ON(ctx->dst_vb == NULL);
>  
>   if (ctx->deinterlacing) {
> +
> + if (ctx->src_vbs[2] == NULL) {
> + ctx->src_vbs[2] = ctx->src_vbs[0];
> + WARN_ON(ctx->src_vbs[2] == NULL);
> + ctx->src_vbs[1] = ctx->src_vbs[0];
> + WARN_ON(ctx->src_vbs[1] == NULL);
> + }
> +
>   /*
>* we have output the first 2 frames through line average, we
>* now switch to EDI de-interlacer
> @@ -1349,7 +1349,7 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
>   }
>  
>   ctx->bufs_completed++;
> - if (ctx->bufs_completed < ctx->bufs_per_job) {
> + if (ctx->bufs_completed < ctx->bufs_per_job && job_ready(ctx)) {
>   device_run(ctx);
>   goto handled;
>   }
> 

Regards,

Hans

[PATCH 3/7] net: hns: Fix hns_dsaf module autoload for OF registration

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko | grep alias
alias:  acpi*:HISI00B2:*
alias:  acpi*:HISI00B1:*

After this patch:

$ modinfo drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko | grep alias
alias:  acpi*:HISI00B2:*
alias:  acpi*:HISI00B1:*
alias:  of:N*T*Chisilicon,hns-dsaf-v2C*
alias:  of:N*T*Chisilicon,hns-dsaf-v2
alias:  of:N*T*Chisilicon,hns-dsaf-v1C*
alias:  of:N*T*Chisilicon,hns-dsaf-v1

Signed-off-by: Javier Martinez Canillas 
---

 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 8d70377f6624..8ea3d95fa483 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -2751,6 +2751,7 @@ static const struct of_device_id g_dsaf_match[] = {
{.compatible = "hisilicon,hns-dsaf-v2"},
{}
 };
+MODULE_DEVICE_TABLE(of, g_dsaf_match);
 
 static struct platform_driver g_dsaf_driver = {
.probe = hns_dsaf_probe,
-- 
2.7.4

Re: [Patch 01/35] media: ti-vpe: vpdma: Make vpdma library into its own module

[Hans Verkuil]

On 09/28/2016 11:16 PM, Benoit Parrot wrote:
> The VPDMA (Video Port DMA) as found in devices such as DRA7xx is
> used for both the Video Processing Engine (VPE) and the Video Input
> Port (VIP).
> 
> In preparation for this we need to turn vpdma into its own
> kernel module.
> 
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/media/platform/Kconfig |  6 ++
>  drivers/media/platform/ti-vpe/Makefile |  4 +++-
>  drivers/media/platform/ti-vpe/vpdma.c  | 28 +++-
>  3 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index f98ed3fd0efd..3c15c5a53bd5 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -334,6 +334,7 @@ config VIDEO_TI_VPE
>   depends on HAS_DMA
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_MEM2MEM_DEV
> + select VIDEO_TI_VPDMA
>   default n
>   ---help---
> Support for the TI VPE(Video Processing Engine) block
> @@ -347,6 +348,11 @@ config VIDEO_TI_VPE_DEBUG
>  
>  endif # V4L_MEM2MEM_DRIVERS
>  
> +# TI VIDEO PORT Helper Modules
> +# These will be selected by VPE and VIP
> +config VIDEO_TI_VPDMA
> + tristate
> +
>  menuconfig V4L_TEST_DRIVERS
>   bool "Media test drivers"
>   depends on MEDIA_CAMERA_SUPPORT
> diff --git a/drivers/media/platform/ti-vpe/Makefile 
> b/drivers/media/platform/ti-vpe/Makefile
> index e236059a60ad..faca5e115c1d 100644
> --- a/drivers/media/platform/ti-vpe/Makefile
> +++ b/drivers/media/platform/ti-vpe/Makefile
> @@ -1,6 +1,8 @@
>  obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe.o
> +obj-$(CONFIG_VIDEO_TI_VPDMA) += ti-vpdma.o
>  
> -ti-vpe-y := vpe.o sc.o csc.o vpdma.o
> +ti-vpe-y := vpe.o sc.o csc.o
> +ti-vpdma-y := vpdma.o
>  
>  ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG
>  
> diff --git a/drivers/media/platform/ti-vpe/vpdma.c 
> b/drivers/media/platform/ti-vpe/vpdma.c
> index 3e2e3a33e6ed..e55cb58213bf 100644
> --- a/drivers/media/platform/ti-vpe/vpdma.c
> +++ b/drivers/media/platform/ti-vpe/vpdma.c
> @@ -75,6 +75,7 @@ const struct vpdma_data_format vpdma_yuv_fmts[] = {
>   .depth  = 16,
>   },
>  };
> +EXPORT_SYMBOL(vpdma_yuv_fmts);

EXPORT_SYMBOL_GPL?

(Up to you).

Regards,

Hans

Re: [PATCH v2] z3fold: fix the potential encode bug in encod_handle

[zhong jiang]

On 2016/10/17 20:03, Vitaly Wool wrote:
> Hi Zhong Jiang,
>
> On Mon, Oct 17, 2016 at 3:58 AM, zhong jiang  wrote:
>> Hi,  Vitaly
>>
>> About the following patch,  is it right?
>>
>> Thanks
>> zhongjiang
>> On 2016/10/13 12:02, zhongjiang wrote:
>>> From: zhong jiang 
>>>
>>> At present, zhdr->first_num plus bud can exceed the BUDDY_MASK
>>> in encode_handle, it will lead to the the caller handle_to_buddy
>>> return the error value.
>>>
>>> The patch fix the issue by changing the BUDDY_MASK to PAGE_MASK,
>>> it will be consistent with handle_to_z3fold_header. At the same time,
>>> change the BUDDY_MASK to PAGE_MASK in handle_to_buddy is better.
> are you seeing problems with the existing code? first_num should wrap around
> BUDDY_MASK and this should be ok because it is way bigger than the number
> of buddies.
>
> ~vitaly
>
> .
>
 I am curious about the z3fold implement, Thus, I am reviewing the code.

 Thanks
 zhongjiang

[PATCH 4/7] net: qcom/emac: Fix module autoload for OF registration

[Javier Martinez Canillas]

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/net/ethernet/qualcomm/emac/qcom-emac.ko | grep alias
alias:  platform:qcom-emac

After this patch:

$ modinfo drivers/net/ethernet/qualcomm/emac/qcom-emac.ko | grep alias
alias:  platform:qcom-emac
alias:  of:N*T*Cqcom,fsm9900-emacC*
alias:  of:N*T*Cqcom,fsm9900-emac

Signed-off-by: Javier Martinez Canillas 
---

 drivers/net/ethernet/qualcomm/emac/emac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c 
b/drivers/net/ethernet/qualcomm/emac/emac.c
index 9bf3b2b82e95..4fede4b86538 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -575,6 +575,7 @@ static const struct of_device_id emac_dt_match[] = {
},
{}
 };
+MODULE_DEVICE_TABLE(of, emac_dt_match);
 
 #if IS_ENABLED(CONFIG_ACPI)
 static const struct acpi_device_id emac_acpi_match[] = {
-- 
2.7.4

[PATCH 3/3] tools lib traceevent: Fix to set uninitialized variables

[Honggyu Kim]

This patch fixes uninitialized variables to remove remaining compiler
warnings as follows:

  event-parse.c: In function ‘pevent_find_event_by_name’:
  event-parse.c:3513:21: warning: ‘event’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
pevent->last_event = event;
   ^
  event-parse.c: In function ‘pevent_data_lat_fmt’:
  event-parse.c:5156:20: warning: ‘migrate_disable’ may be used uninitialized 
in this function [-Wmaybe-uninitialized]
  trace_seq_printf(s, "%d", migrate_disable);
  ^
  event-parse.c:5163:20: warning: ‘lock_depth’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
  trace_seq_printf(s, "%d", lock_depth);
  ^
  event-parse.c: In function ‘pevent_event_info’:
  event-parse.c:5060:18: warning: ‘len_arg’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
   print_str_arg(, data, size, event,
^
  event-parse.c:4846:6: note: ‘len_arg’ was declared here
int len_arg;
^
  ...
  kbuffer-parse.c: In function ‘__old_next_event’:
  kbuffer-parse.c:339:27: warning: ‘length’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
kbuf->next = kbuf->index + length;
 ^
  kbuffer-parse.c:297:15: note: ‘length’ was declared here
unsigned int length;
 ^

Signed-off-by: Honggyu Kim 
---
 tools/lib/traceevent/event-parse.c | 8 
 tools/lib/traceevent/kbuffer-parse.c   | 2 +-
 tools/lib/traceevent/plugin_function.c | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index 664c90c..2fb9338 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3490,7 +3490,7 @@ struct event_format *
 pevent_find_event_by_name(struct pevent *pevent,
  const char *sys, const char *name)
 {
-   struct event_format *event;
+   struct event_format *event = NULL;
int i;
 
if (pevent->last_event &&
@@ -4843,7 +4843,7 @@ static void pretty_print(struct trace_seq *s, void *data, 
int size, struct event
char format[32];
int show_func;
int len_as_arg;
-   int len_arg;
+   int len_arg = 0;
int len;
int ls;
 
@@ -5102,8 +5102,8 @@ void pevent_data_lat_fmt(struct pevent *pevent,
static int migrate_disable_exists;
unsigned int lat_flags;
unsigned int pc;
-   int lock_depth;
-   int migrate_disable;
+   int lock_depth = -1;
+   int migrate_disable = 0;
int hardirq;
int softirq;
void *data = record->data;
diff --git a/tools/lib/traceevent/kbuffer-parse.c 
b/tools/lib/traceevent/kbuffer-parse.c
index 65984f1..fc8f20c 100644
--- a/tools/lib/traceevent/kbuffer-parse.c
+++ b/tools/lib/traceevent/kbuffer-parse.c
@@ -294,7 +294,7 @@ static unsigned int old_update_pointers(struct kbuffer 
*kbuf)
unsigned int type;
unsigned int len;
unsigned int delta;
-   unsigned int length;
+   unsigned int length = 0;
void *ptr = kbuf->data + kbuf->curr;
 
type_len_ts = read_4(kbuf, ptr);
diff --git a/tools/lib/traceevent/plugin_function.c 
b/tools/lib/traceevent/plugin_function.c
index a00ec19..42dbf73 100644
--- a/tools/lib/traceevent/plugin_function.c
+++ b/tools/lib/traceevent/plugin_function.c
@@ -130,7 +130,7 @@ static int function_handler(struct trace_seq *s, struct 
pevent_record *record,
unsigned long long pfunction;
const char *func;
const char *parent;
-   int index;
+   int index = 0;
 
if (pevent_get_field_val(s, event, "ip", record, , 1))
return trace_seq_putc(s, '!');
-- 
2.10.0.rc2.dirty

Re: [Patch 05/35] media: ti-vpe: Use line average de-interlacing for first 2 frames

[Hans Verkuil]

On 09/28/2016 11:20 PM, Benoit Parrot wrote:
> From: Archit Taneja 
> 
> For n input fields, the VPE de-interlacer creates n - 2 progressive frames.

That's confusing. I think you mean '(n / 2) - 1'? Two fields make one frame, 
right?

Regards,

Hans

> 
> To support this, we use line average mode of de-interlacer for the first 2
> input fields to generate 2 progressive frames. We then revert back to the
> preferred EDI method, and create n - 2 frames, creating a sum of n frames.
> 
> Signed-off-by: Archit Taneja 
> Signed-off-by: Nikhil Devshatwar 
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/media/platform/ti-vpe/vpe.c | 33 +++--
>  1 file changed, 31 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/ti-vpe/vpe.c 
> b/drivers/media/platform/ti-vpe/vpe.c
> index 3921fd8cdf1d..a0b29685fb69 100644
> --- a/drivers/media/platform/ti-vpe/vpe.c
> +++ b/drivers/media/platform/ti-vpe/vpe.c
> @@ -141,7 +141,7 @@ struct vpe_dei_regs {
>   */
>  static const struct vpe_dei_regs dei_regs = {
>   .mdt_spacial_freq_thr_reg = 0x020C0804u,
> - .edi_config_reg = 0x0118100Fu,
> + .edi_config_reg = 0x0118100Cu,
>   .edi_lut_reg0 = 0x08040200u,
>   .edi_lut_reg1 = 0x1010100Cu,
>   .edi_lut_reg2 = 0x10101010u,
> @@ -798,6 +798,23 @@ static void set_dei_shadow_registers(struct vpe_ctx *ctx)
>   ctx->load_mmrs = true;
>  }
>  
> +static void config_edi_input_mode(struct vpe_ctx *ctx, int mode)
> +{
> + struct vpe_mmr_adb *mmr_adb = ctx->mmr_adb.addr;
> + u32 *edi_config_reg = _adb->dei_regs[3];
> +
> + if (mode & 0x2)
> + write_field(edi_config_reg, 1, 1, 2);   /* EDI_ENABLE_3D */
> +
> + if (mode & 0x3)
> + write_field(edi_config_reg, 1, 1, 3);   /* EDI_CHROMA_3D  */
> +
> + write_field(edi_config_reg, mode, VPE_EDI_INP_MODE_MASK,
> + VPE_EDI_INP_MODE_SHIFT);
> +
> + ctx->load_mmrs = true;
> +}
> +
>  /*
>   * Set the shadow registers whose values are modified when either the
>   * source or destination format is changed.
> @@ -,6 +1128,15 @@ static void device_run(void *priv)
>   ctx->dst_vb = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
>   WARN_ON(ctx->dst_vb == NULL);
>  
> + if (ctx->deinterlacing) {
> + /*
> +  * we have output the first 2 frames through line average, we
> +  * now switch to EDI de-interlacer
> +  */
> + if (ctx->sequence == 2)
> + config_edi_input_mode(ctx, 0x3); /* EDI (Y + UV) */
> + }
> +
>   /* config descriptors */
>   if (ctx->dev->loaded_mmrs != ctx->mmr_adb.dma_addr || ctx->load_mmrs) {
>   vpdma_map_desc_buf(ctx->dev->vpdma, >mmr_adb);
> @@ -1865,7 +1891,10 @@ static void vpe_buf_queue(struct vb2_buffer *vb)
>  
>  static int vpe_start_streaming(struct vb2_queue *q, unsigned int count)
>  {
> - /* currently we do nothing here */
> + struct vpe_ctx *ctx = vb2_get_drv_priv(q);
> +
> + if (ctx->deinterlacing)
> + config_edi_input_mode(ctx, 0x0);
>  
>   return 0;
>  }
> 

Re: [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64

[Auger Eric]

Hi Punit,

On 14/10/2016 13:24, Punit Agrawal wrote:
> Hi Eric,
> 
> I am a bit late in joining, but I've tried to familiarise
> myself with earlier discussions on the series.
> 
> Eric Auger  writes:
> 
>> This is the second respin on top of Robin's series [1], addressing Alex' 
>> comments.
>>
>> Major changes are:
>> - MSI-doorbell API now is moved to DMA IOMMU API following Alex suggestion
>>   to put all API pieces at the same place (so eventually in the IOMMU
>>   subsystem)
> 
> IMHO, this is headed in the opposite direction, i.e., away from the
> owner of the information - the doorbells are the property of the MSI
> controller. The MSI controllers know the location, size and interrupt
> remapping capability as well. On the consumer side, VFIO needs access to
> the doorbells to allow userspace to carve out a region in the IOVA.
> 
> I quite liked what you had in v13, though I think you can go further
> though. Instead of adding new doorbell API [un]registration calls, how
> about adding a callback to the irq_domain_ops? The callback will be
> populated for irqdomains registered by MSI controllers.

Thank you for jumping into that thread. Any help/feedback is greatly
appreciated.

Regarding your suggestion, the irq_domain looks dedicated to the
translation between linux irq and HW irq. I tend to think adding an ops
to retrieve the MSI doorbell info at that level looks far from the
original goal of the infrastructure. Obviously the fact there is a list
of such domain is tempting but I preferred to add a separate struct and
separate list.

In the v14 release I moved the "doorbell API" in the dma-iommu API since
Alex recommended to offer a unified API where all pieces would be at the
same place.

Anyway I will follow the guidance of maintainers.


> 
> From VFIO, we can calculate the required aperture reservation by
> iterating over the irqdomains (something like irq_domain_for_each). The
> same callback can also provide information about support for interrupt
> remapping.
> 
> For systems where there are no separate MSI controllers, i.e., the IOMMU
> has a fixed reservation, no MSI callbacks will be populated - which
> tells userspace that no separate MSI reservation is required. IIUC, this
> was one of Alex' concerns on the prior version.

I'am working on a separate series to report to the user-space the usable
IOVA range(s).

Thanks

Eric
> 
> Thoughts, opinions?
> 
> Punit
> 
>> - new iommu_domain_msi_resv struct and accessor through DOMAIN_ATTR_MSI_RESV
>>   domain with mirror VFIO capability
>> - more robustness I think in the VFIO layer
>> - added "iommu/iova: fix __alloc_and_insert_iova_range" since with the 
>> current
>>   code I failed allocating an IOVA page in a single page domain with upper 
>> part
>>   reserved
>>
>> IOVA range exclusion will be handled in a separate series
>>
>> The priority really is to discuss and freeze the API and especially the MSI
>> doorbell's handling. Do we agree to put that in DMA IOMMU?
>>
>> Note: the size computation does not take into account possible page overlaps
>> between doorbells but it would add quite a lot of complexity i think.
>>
>> Tested on AMD Overdrive (single GICv2m frame) with I350 VF assignment.
>>
>> dependency:
>> the series depends on Robin's generic-v7 branch:
>> [1] [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
>> http://www.spinics.net/lists/arm-kernel/msg531110.html
>>
>> Best Regards
>>
>> Eric
>>
>> Git: complete series available at
>> https://github.com/eauger/linux/tree/generic-v7-pcie-passthru-v14
>>
>> the above branch includes a temporary patch to work around a ThunderX pci
>> bus reset crash (which I think unrelated to this series):
>> "vfio: pci: HACK! workaround thunderx pci_try_reset_bus crash"
>> Do not take this one for other platforms.
>>
>>
>> Eric Auger (15):
>>   iommu/iova: fix __alloc_and_insert_iova_range
>>   iommu: Introduce DOMAIN_ATTR_MSI_RESV
>>   iommu/dma: MSI doorbell alloc/free
>>   iommu/dma: Introduce iommu_calc_msi_resv
>>   iommu/arm-smmu: Implement domain_get_attr for DOMAIN_ATTR_MSI_RESV
>>   irqchip/gic-v2m: Register the MSI doorbell
>>   irqchip/gicv3-its: Register the MSI doorbell
>>   vfio: Introduce a vfio_dma type field
>>   vfio/type1: vfio_find_dma accepting a type argument
>>   vfio/type1: Implement recursive vfio_find_dma_from_node
>>   vfio/type1: Handle unmap/unpin and replay for VFIO_IOVA_RESERVED slots
>>   vfio: Allow reserved msi iova registration
>>   vfio/type1: Check doorbell safety
>>   iommu/arm-smmu: Do not advertise IOMMU_CAP_INTR_REMAP
>>   vfio/type1: Introduce MSI_RESV capability
>>
>> Robin Murphy (1):
>>   iommu/dma: Allow MSI-only cookies
>>
>>  drivers/iommu/Kconfig|   4 +-
>>  drivers/iommu/arm-smmu-v3.c  |  10 +-
>>  drivers/iommu/arm-smmu.c |  10 +-
>>  drivers/iommu/dma-iommu.c| 184 ++
>>  drivers/iommu/iova.c |   2 +-
>>  drivers/irqchip/irq-gic-v2m.c|  10 +-
>>  

Re: [patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

[Sebastian Andrzej Siewior]

On 2016-10-16 05:14:22 [+0200], Mike Galbraith wrote:
> 
> In v4.7, the driver switched to percpu compression streams, disabling
> preemption (get/put_cpu_ptr()).  Use get/put_cpu_light() instead.

I am not convinced that this will work. Nothing prevents
zram_bvec_write() to be reentrant on the same CPU what I can tell from
browsing over the code and since it uses zstrm->buffer for compression
it can go wrong. Also I don't know if crypto's tfm handler can be used
in parallel for any ops (it usually does not work for crypto).

I suggest a local lock or a good reason why the this patch works.

Sebastian

Re: [PATCH v2 0/2] Introduce arch specific nmi enable, disable handlers

[Don Zickus]

On Thu, Oct 13, 2016 at 01:38:00PM -0700, Babu Moger wrote:
> During our testing we noticed that nmi watchdogs in sparc could not be 
> disabled or
> enabled dynamically using sysctl/proc interface. Sparc uses its own arch 
> specific
> nmi watchdogs. There is a sysctl and proc 
> interface(proc/sys/kernel/nmi_watchdog)
> to enable/disable nmi watchdogs. However, that is not working for sparc. There
> is no interface to feed this parameter to arch specific nmi watchdogs.
> 
> These patches extend the same sysctl/proc interface to enable or disable
> these arch specific nmi watchdogs dynamically. Introduced new functions
> arch_watchdog_nmi_enable and arch_watchdog_nmi_disable which can be 
> implemented
> in arch specific handlers.
> If you think there is a better way to do this. Please advice.
> 
> Tested on sparc. Compile tested on x86.

Thanks Babu!  Looking through the code it seems appropriate with what I
suggested.  I am running it through my testsuite and things are failing.
But it is most likely my system is misconfigured.  Give me another day or so
to straighten that out.

Cheers,
Don

> 
> v2:
>   a)Sam Ravnborg's comments about making the definitions visible.
>   With the new approach we dont need those definitions((NMI_WATCHDOG_ENABLED,
>   SOFT_WATCHDOG_ENABLED etc..) outside watchdog.c. So no action.
> 
>   b) Made changes per Don Zickus comments.
>   Don, I could not use your patches as is. Reason is sparc does not define
>   CONFIG_HARDLOCKUP_DETECTOR. So, defining default __weak function did not
>   work for me. However, I have used your idea to define __weak functions
>   arch_watchdog_nmi_enable and arch_watchdog_nmi_disable when 
> CONFIG_HARDLOCKUP_DETECTOR
>   is not defined. I feel this should have very less impact on the races you 
> are
>   concerned about. Please take a look. Feel free to suggest.
> 
>   Patch2 changes: I had to introduce new variable nmi_init_done to synchronize
>   watchdog thread and kernel init thread.
> 
> v1:
>  Initial version. Discussion thread here
>  http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1245427.html
> 
> Babu Moger (2):
>   watchdog: Introduce arch_watchdog_nmi_enable and
> arch_watchdog_nmi_disable
>   sparc: Implement arch_watchdog_nmi_enable and
> arch_watchdog_nmi_disable
> 
>  arch/sparc/kernel/nmi.c |   41 +-
>  kernel/watchdog.c   |   65 +++---
>  2 files changed, 84 insertions(+), 22 deletions(-)
> 

Re: [PATCH v14 04/16] iommu/dma: MSI doorbell alloc/free

[Auger Eric]

Hi Punit,

On 14/10/2016 13:25, Punit Agrawal wrote:
> Hi Eric,
> 
> One query and a comment below.
> 
> Eric Auger  writes:
> 
>> We introduce the capability to (un)register MSI doorbells.
>>
>> A doorbell region is characterized by its physical address base, size,
>> and whether it its safe (ie. it implements IRQ remapping). A doorbell
>> can be per-cpu or global. We currently only care about global doorbells.
>>
>> A function returns whether all registered doorbells are safe.
>>
>> MSI controllers likely to work along with IOMMU that translate MSI
>> transaction must register their doorbells to allow device assignment
>> with MSI support.  Otherwise the MSI transactions will cause IOMMU faults.
>>
>> Signed-off-by: Eric Auger 
>>
>> ---
>>
>> v13 -> v14:
>> - previously in msi-doorbell.h/c
>> ---
>>  drivers/iommu/dma-iommu.c | 75 
>> +++
>>  include/linux/dma-iommu.h | 41 ++
>>  2 files changed, 116 insertions(+)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index d45f9a0..d8a7d86 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -43,6 +43,38 @@ struct iommu_dma_cookie {
>>  spinlock_t  msi_lock;
>>  };
>>  
>> +/**
>> + * struct iommu_msi_doorbell_info - MSI doorbell region descriptor
>> + * @percpu_doorbells: per cpu doorbell base address
>> + * @global_doorbell: base address of the doorbell
>> + * @doorbell_is_percpu: is the doorbell per cpu or global?
>> + * @safe: true if irq remapping is implemented
>> + * @size: size of the doorbell
>> + */
>> +struct iommu_msi_doorbell_info {
>> +union {
>> +phys_addr_t __percpu*percpu_doorbells;
> 
> Out of curiosity, have you come across systems that have per-cpu
> doorbells? I couldn't find a system that'd help solidify my
> understanding on it's usage.

This came out after a discussion With Marc. However at the moment I am
not aware of any MSI controller featuring per-cpu doorbell. Not sure
whether it stays relevant to keep this notion at that stage.

> 
>> +phys_addr_t global_doorbell;
>> +};
>> +booldoorbell_is_percpu;
>> +boolsafe;
> 
> Although you've got the comment above, 'safe' doesn't quite convey it's
> purpose. Can this be renamed to something more descriptive -
> 'intr_remapping' or 'intr_isolation' perhaps?

Yes definitively

Thanks

Eric
> 
> Thanks,
> Punit
> 
> 
> [...]
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH -next] irqchip/eznps: drop pointless static qualifier in nps400_of_init()

[Wei Yongjun]

From: Wei Yongjun 

There is no need to have the 'struct irq_domain *nps400_root_domain'
variable static since new value always be assigned before use it.

Signed-off-by: Wei Yongjun 
---
 drivers/irqchip/irq-eznps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-eznps.c b/drivers/irqchip/irq-eznps.c
index ebc2b0b..2a7a388 100644
--- a/drivers/irqchip/irq-eznps.c
+++ b/drivers/irqchip/irq-eznps.c
@@ -135,7 +135,7 @@ static const struct irq_domain_ops nps400_irq_ops = {
 static int __init nps400_of_init(struct device_node *node,
 struct device_node *parent)
 {
-   static struct irq_domain *nps400_root_domain;
+   struct irq_domain *nps400_root_domain;
 
if (parent) {
pr_err("DeviceTree incore ic not a root irq controller\n");

[PATCH] arm64: kernel: numa: fix ACPI boot cpu numa node mapping

[Lorenzo Pieralisi]

Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
bind to node0") removed the numa cpu<->node mapping restriction whereby
logical cpu 0 always corresponds to numa node 0; removing the
restriction was correct, in that it does not really exist in practice
but the commit only updated the early mapping of logical cpu 0 to its
real numa node for the DT boot path, missing the ACPI one, leading to
boot failures on ACPI systems with numa enabled owing to missing
node<->cpu map for logical cpu 0.

Fix the issue by updating the ACPI boot path with code that carries out
the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
what is currently done in the DT boot path.

Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to 
node0")
Signed-off-by: Lorenzo Pieralisi 
Tested-by: Laszlo Ersek 
Reported-by: Laszlo Ersek 
Cc: Will Deacon 
Cc: Laszlo Ersek 
Cc: Hanjun Guo 
Cc: Andrew Jones 
Cc: Zhen Lei 
Cc: Catalin Marinas 
---
 arch/arm64/kernel/smp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d3f151c..8507703 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct 
acpi_madt_generic_interrupt *processor)
return;
}
bootcpu_valid = true;
+   early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
return;
}
 
-- 
2.10.0

[PATCH 13/13] gpio-sx150x: Pass device type in DT match table

[Andrey Smirnov]

Pass the same device type information in DT match table as the one being
passed via i2c_device_id

Signed-off-by: Andrey Smirnov 
---
 drivers/gpio/gpio-sx150x.c | 48 --
 1 file changed, 34 insertions(+), 14 deletions(-)

diff --git a/drivers/gpio/gpio-sx150x.c b/drivers/gpio/gpio-sx150x.c
index bfb1ec3..9263d25 100644
--- a/drivers/gpio/gpio-sx150x.c
+++ b/drivers/gpio/gpio-sx150x.c
@@ -97,8 +97,15 @@ struct sx150x_chip {
struct mutex lock;
 };
 
+enum sx150x_type {
+   SX1508Q = 0,
+   SX1509Q,
+   SX1506Q,
+   SX1502Q,
+};
+
 static const struct sx150x_device_data sx150x_devices[] = {
-   [0] = { /* sx1508q */
+   [SX1508Q] = {
.model = SX150X_789,
.reg_pullup = 0x03,
.reg_pulldn = 0x04,
@@ -116,7 +123,7 @@ static const struct sx150x_device_data sx150x_devices[] = {
},
.ngpios = 8,
},
-   [1] = { /* sx1509q */
+   [SX1509Q] = {
.model = SX150X_789,
.reg_pullup = 0x07,
.reg_pulldn = 0x09,
@@ -134,7 +141,7 @@ static const struct sx150x_device_data sx150x_devices[] = {
},
.ngpios = 16
},
-   [2] = { /* sx1506q */
+   [SX1506Q] = {
.model = SX150X_456,
.reg_pullup = 0x05,
.reg_pulldn = 0x07,
@@ -154,7 +161,7 @@ static const struct sx150x_device_data sx150x_devices[] = {
},
.ngpios = 16
},
-   [3] = { /* sx1502q */
+   [SX1502Q] = {
.model = SX150X_123,
.reg_pullup = 0x02,
.reg_pulldn = 0x03,
@@ -177,19 +184,19 @@ static const struct sx150x_device_data sx150x_devices[] = 
{
 };
 
 static const struct i2c_device_id sx150x_id[] = {
-   {"sx1508q", 0},
-   {"sx1509q", 1},
-   {"sx1506q", 2},
-   {"sx1502q", 3},
+   { "sx1508q", SX1508Q },
+   { "sx1509q", SX1509Q },
+   { "sx1506q", SX1506Q },
+   { "sx1502q", SX1502Q },
{}
 };
 MODULE_DEVICE_TABLE(i2c, sx150x_id);
 
 static const struct of_device_id sx150x_of_match[] = {
-   { .compatible = "semtech,sx1508q" },
-   { .compatible = "semtech,sx1509q" },
-   { .compatible = "semtech,sx1506q" },
-   { .compatible = "semtech,sx1502q" },
+   { .compatible = "semtech,sx1508q", .data = (void *)SX1508Q },
+   { .compatible = "semtech,sx1509q", .data = (void *)SX1509Q },
+   { .compatible = "semtech,sx1506q", .data = (void *)SX1506Q },
+   { .compatible = "semtech,sx1502q", .data = (void *)SX1502Q },
{},
 };
 MODULE_DEVICE_TABLE(of, sx150x_of_match);
@@ -680,13 +687,14 @@ static int sx150x_install_irq_chip(struct sx150x_chip 
*chip)
 }
 
 static int sx150x_probe(struct i2c_client *client,
-   const struct i2c_device_id *id)
+   const struct i2c_device_id *id)
 {
static const u32 i2c_funcs = I2C_FUNC_SMBUS_BYTE_DATA |
 I2C_FUNC_SMBUS_WRITE_WORD_DATA;
struct sx150x_chip *chip;
int rc;
bool oscio_is_gpo;
+   kernel_ulong_t driver_data;
 
if (!i2c_check_functionality(client->adapter, i2c_funcs))
return -ENOSYS;
@@ -699,7 +707,19 @@ static int sx150x_probe(struct i2c_client *client,
oscio_is_gpo = of_property_read_bool(client->dev.of_node,
 "semtech,oscio-is-gpo");
 
-   sx150x_init_chip(chip, client, id->driver_data);
+   if (id) {
+   driver_data = id->driver_data;
+   } else {
+   const struct of_device_id *match;
+
+   match = of_match_device(sx150x_of_match, >dev);
+   if (!match)
+   return -ENODEV;
+
+   driver_data = (kernel_ulong_t)match->data;
+   }
+
+   sx150x_init_chip(chip, client, driver_data);
 
if (oscio_is_gpo)
chip->gpio_chip.ngpio++;
-- 
2.5.5

[PATCH 02/13] gpio-sx150x: Remove 'irq_summary' parameter

[Andrey Smirnov]

Information conveyed by 'irq_summary' paramter can be obtained from
struct i2c_client's irq field. Remove any uses of the former and replace
it with the latter.

Signed-off-by: Andrey Smirnov 
---
 drivers/gpio/gpio-sx150x.c | 19 +++
 1 file changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpio/gpio-sx150x.c b/drivers/gpio/gpio-sx150x.c
index f9d6bec..e80c115 100644
--- a/drivers/gpio/gpio-sx150x.c
+++ b/drivers/gpio/gpio-sx150x.c
@@ -105,12 +105,6 @@ struct sx150x_device_data {
  *   the polarity of that IO line, while clearing it results
  *   in normal polarity. For chips with fewer than 16 IO pins,
  *   high-end bits are ignored.
- * @irq_summary: The 'summary IRQ' line to which the GPIO expander's INT line
- *   is connected, via which it reports interrupt events
- *   across all GPIO lines.  This must be a real,
- *   pre-existing IRQ line.
- *   Setting this value < 0 disables the irq_chip functionality
- *   of the driver.
  * @irq_base: The first 'virtual IRQ' line at which our block of GPIO-based
  *IRQ lines will appear.  Similarly to gpio_base, the expander
  *will create a block of irqs beginning at this number.
@@ -124,7 +118,6 @@ struct sx150x_platform_data {
u16  io_pullup_ena;
u16  io_pulldn_ena;
u16  io_polarity;
-   int  irq_summary;
unsigned irq_base;
bool reset_during_probe;
 };
@@ -133,7 +126,6 @@ struct sx150x_chip {
struct gpio_chip gpio_chip;
struct i2c_client   *client;
const struct sx150x_device_data *dev_cfg;
-   int  irq_summary;
int  irq_base;
int  irq_update;
u32  irq_sense;
@@ -598,7 +590,6 @@ static void sx150x_init_chip(struct sx150x_chip *chip,
chip->irq_chip.irq_set_type= sx150x_irq_set_type;
chip->irq_chip.irq_bus_lock= sx150x_irq_bus_lock;
chip->irq_chip.irq_bus_sync_unlock = sx150x_irq_bus_sync_unlock;
-   chip->irq_summary  = -1;
chip->irq_base = -1;
chip->irq_masked   = ~0;
chip->irq_sense= 0;
@@ -699,12 +690,10 @@ static int sx150x_init_hw(struct sx150x_chip *chip,
 }
 
 static int sx150x_install_irq_chip(struct sx150x_chip *chip,
-   int irq_summary,
-   int irq_base)
+  int irq_base)
 {
int err;
 
-   chip->irq_summary = irq_summary;
chip->irq_base= irq_base;
 
/* Add gpio chip to irq subsystem */
@@ -718,11 +707,10 @@ static int sx150x_install_irq_chip(struct sx150x_chip 
*chip,
}
 
err = devm_request_threaded_irq(>client->dev,
-   irq_summary, NULL, sx150x_irq_thread_fn,
+   chip->client->irq, NULL, sx150x_irq_thread_fn,
IRQF_ONESHOT | IRQF_SHARED | IRQF_TRIGGER_FALLING,
chip->irq_chip.name, chip);
if (err < 0) {
-   chip->irq_summary = -1;
chip->irq_base= -1;
}
 
@@ -759,9 +747,8 @@ static int sx150x_probe(struct i2c_client *client,
if (rc)
return rc;
 
-   if (pdata->irq_summary >= 0) {
+   if (client->irq) {
rc = sx150x_install_irq_chip(chip,
-   pdata->irq_summary,
pdata->irq_base);
if (rc < 0)
return rc;
-- 
2.5.5