date:20170302

fanotify: Support for file creation and deletion

2017-03-02 Thread Andreas Schärtl

Hello,

we are a group of students, for a course we would like to create an
efficient backup/file synchronization tool that supports file system
trees with lots of directories. Currently such tools use the inotify
interface but we would rather not use it because (1) inotify requires
a watch descriptor for each watched directory and (2) we would rather
not create new watches every time a directory was created.

fanotify already supports watching full mount points without needing
many watch descriptors. It can log file modifications with the
FAN_MODIFY mask, but we also need a way to get notified when files are
created/deleted. We would like to extend fanotify to support those
events.

The problem with the current fanotify_event_metadata is that it
doesn't support a way to do this. This is why we want to extend the
struct with the path of the newly {created, deleted} file or
directory. To facilitate this, we are considering the following
structure for create and delete events:

struct fanotify_event_metadata {
__u32 event_len;
__u8 vers;
__u8 reserved;
__u16 metadata_len;
__aligned_u64 mask;
__s32 fd;
__s32 pid;
__u32 path_len;
char path[];
};

One thing we do not quite understand is the difference between
event_len and metadata_len. If metadata_len is actually the length of
the not variable part (anything but path), path_len is not
necessary. It may make sense to introduce a new structure just for the
create and delete events.

We are wondering what you think about this proposal. Whether it makes
sense to follow this idea or if you have other ideas. Thank you!

-- Andreas

[PATCH 3/3] Staging:wilc1000:host_interface: Integrated two 'if' statements to a single 'if' statement

2017-03-02 Thread Georgios Emmanouil

Removed unnecessary 'if' statement and integrated the condition to the
previous 'if' statement.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/host_interface.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index bbe1a09..4936e80 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1355,13 +1355,11 @@ static s32 Handle_RcvdGnrlAsyncInfo(struct wilc_vif 
*vif,
} else {
strConnectInfo.status = 
pstrConnectRespInfo->status;

-   if (strConnectInfo.status == 
SUCCESSFUL_STATUSCODE) {
-   if 
(pstrConnectRespInfo->ies) {
-   
strConnectInfo.resp_ies_len = pstrConnectRespInfo->ies_len;
-   
strConnectInfo.resp_ies = kmalloc(pstrConnectRespInfo->ies_len, GFP_KERNEL);
-   
memcpy(strConnectInfo.resp_ies, pstrConnectRespInfo->ies,
-  
pstrConnectRespInfo->ies_len);
-   }
+   if (strConnectInfo.status == 
SUCCESSFUL_STATUSCODE && pstrConnectRespInfo->ies) {
+   
strConnectInfo.resp_ies_len = pstrConnectRespInfo->ies_len;
+   strConnectInfo.resp_ies 
= kmalloc(pstrConnectRespInfo->ies_len, GFP_KERNEL);
+   
memcpy(strConnectInfo.resp_ies, pstrConnectRespInfo->ies,
+  
pstrConnectRespInfo->ies_len);
}

if (pstrConnectRespInfo) {
--
2.1.4

fanotify: Support for file creation and deletion

2017-03-02 Thread Andreas Schärtl

Hello,

we are a group of students, for a course we would like to create an
efficient backup/file synchronization tool that supports file system
trees with lots of directories. Currently such tools use the inotify
interface but we would rather not use it because (1) inotify requires
a watch descriptor for each watched directory and (2) we would rather
not create new watches every time a directory was created.

fanotify already supports watching full mount points without needing
many watch descriptors. It can log file modifications with the
FAN_MODIFY mask, but we also need a way to get notified when files are
created/deleted. We would like to extend fanotify to support those
events.

The problem with the current fanotify_event_metadata is that it
doesn't support a way to do this. This is why we want to extend the
struct with the path of the newly {created, deleted} file or
directory. To facilitate this, we are considering the following
structure for create and delete events:

struct fanotify_event_metadata {
__u32 event_len;
__u8 vers;
__u8 reserved;
__u16 metadata_len;
__aligned_u64 mask;
__s32 fd;
__s32 pid;
__u32 path_len;
char path[];
};

One thing we do not quite understand is the difference between
event_len and metadata_len. If metadata_len is actually the length of
the not variable part (anything but path), path_len is not
necessary. It may make sense to introduce a new structure just for the
create and delete events.

We are wondering what you think about this proposal. Whether it makes
sense to follow this idea or if you have other ideas. Thank you!

-- Andreas

[PATCH 3/3] Staging:wilc1000:host_interface: Integrated two 'if' statements to a single 'if' statement

2017-03-02 Thread Georgios Emmanouil

Removed unnecessary 'if' statement and integrated the condition to the
previous 'if' statement.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/host_interface.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index bbe1a09..4936e80 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1355,13 +1355,11 @@ static s32 Handle_RcvdGnrlAsyncInfo(struct wilc_vif 
*vif,
} else {
strConnectInfo.status = 
pstrConnectRespInfo->status;

-   if (strConnectInfo.status == 
SUCCESSFUL_STATUSCODE) {
-   if 
(pstrConnectRespInfo->ies) {
-   
strConnectInfo.resp_ies_len = pstrConnectRespInfo->ies_len;
-   
strConnectInfo.resp_ies = kmalloc(pstrConnectRespInfo->ies_len, GFP_KERNEL);
-   
memcpy(strConnectInfo.resp_ies, pstrConnectRespInfo->ies,
-  
pstrConnectRespInfo->ies_len);
-   }
+   if (strConnectInfo.status == 
SUCCESSFUL_STATUSCODE && pstrConnectRespInfo->ies) {
+   
strConnectInfo.resp_ies_len = pstrConnectRespInfo->ies_len;
+   strConnectInfo.resp_ies 
= kmalloc(pstrConnectRespInfo->ies_len, GFP_KERNEL);
+   
memcpy(strConnectInfo.resp_ies, pstrConnectRespInfo->ies,
+  
pstrConnectRespInfo->ies_len);
}

if (pstrConnectRespInfo) {
--
2.1.4

[PATCH 14/26] [media] dvb-frontends: reduce stack size in i2c access

2017-03-02 Thread Arnd Bergmann

A typical code fragment was copied across many dvb-frontend
drivers and causes large stack frames when built with
-fsanitize-address-use-after-scope, e.g.

drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

By marking the register access functions as noinline_for_kasan,
we can completely avoid this problem.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/dvb-frontends/ascot2e.c   |  3 ++-
 drivers/media/dvb-frontends/cxd2841er.c |  4 ++--
 drivers/media/dvb-frontends/drx39xyj/drxj.c | 14 +++---
 drivers/media/dvb-frontends/helene.c|  4 ++--
 drivers/media/dvb-frontends/horus3a.c   |  2 +-
 drivers/media/dvb-frontends/itd1000.c   |  2 +-
 drivers/media/dvb-frontends/mt312.c |  2 +-
 drivers/media/dvb-frontends/si2165.c| 14 +++---
 drivers/media/dvb-frontends/stb0899_drv.c   |  2 +-
 drivers/media/dvb-frontends/stb6100.c   |  2 +-
 drivers/media/dvb-frontends/stv0367.c   |  2 +-
 drivers/media/dvb-frontends/stv090x.c   |  2 +-
 drivers/media/dvb-frontends/stv6110.c   |  2 +-
 drivers/media/dvb-frontends/stv6110x.c  |  2 +-
 drivers/media/dvb-frontends/tda8083.c   |  2 +-
 drivers/media/dvb-frontends/zl10039.c   |  2 +-
 16 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/drivers/media/dvb-frontends/ascot2e.c 
b/drivers/media/dvb-frontends/ascot2e.c
index 0ee0df53b91b..435eb4d3f3ef 100644
--- a/drivers/media/dvb-frontends/ascot2e.c
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -153,7 +153,8 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
return 0;
 }
 
-static int ascot2e_write_reg(struct ascot2e_priv *priv, u8 reg, u8 val)
+static noinline_for_kasan int ascot2e_write_reg(struct ascot2e_priv *priv,
+   u8 reg, u8 val)
 {
return ascot2e_write_regs(priv, reg, , 1);
 }
diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 614bfb3740f1..01f7ec4d42c1 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -258,7 +258,7 @@ static int cxd2841er_write_regs(struct cxd2841er_priv *priv,
return 0;
 }
 
-static int cxd2841er_write_reg(struct cxd2841er_priv *priv,
+static noinline_for_kasan int cxd2841er_write_reg(struct cxd2841er_priv *priv,
   u8 addr, u8 reg, u8 val)
 {
return cxd2841er_write_regs(priv, addr, reg, , 1);
@@ -306,7 +306,7 @@ static int cxd2841er_read_regs(struct cxd2841er_priv *priv,
return 0;
 }
 
-static int cxd2841er_read_reg(struct cxd2841er_priv *priv,
+static noinline_for_kasan int cxd2841er_read_reg(struct cxd2841er_priv *priv,
  u8 addr, u8 reg, u8 *val)
 {
return cxd2841er_read_regs(priv, addr, reg, val, 1);
diff --git a/drivers/media/dvb-frontends/drx39xyj/drxj.c 
b/drivers/media/dvb-frontends/drx39xyj/drxj.c
index daeaf965dd56..0e6540709e09 100644
--- a/drivers/media/dvb-frontends/drx39xyj/drxj.c
+++ b/drivers/media/dvb-frontends/drx39xyj/drxj.c
@@ -1516,7 +1516,7 @@ static int drxdap_fasi_read_block(struct i2c_device_addr 
*dev_addr,
 *
 **/
 
-static int drxdap_fasi_read_reg16(struct i2c_device_addr *dev_addr,
+static noinline_for_kasan int drxdap_fasi_read_reg16(struct i2c_device_addr 
*dev_addr,
 u32 addr,
 u16 *data, u32 flags)
 {
@@ -1549,7 +1549,7 @@ static int drxdap_fasi_read_reg16(struct i2c_device_addr 
*dev_addr,
 *
 **/
 
-static int drxdap_fasi_read_reg32(struct i2c_device_addr *dev_addr,
+static noinline_for_kasan int drxdap_fasi_read_reg32(struct i2c_device_addr 
*dev_addr,
 u32 addr,
 u32 *data, u32 flags)
 {
@@ -1722,7 +1722,7 @@ static int drxdap_fasi_write_block(struct i2c_device_addr 
*dev_addr,
 *
 **/
 
-static int drxdap_fasi_write_reg16(struct i2c_device_addr *dev_addr,
+static noinline_for_kasan int drxdap_fasi_write_reg16(struct i2c_device_addr 
*dev_addr,
  u32 addr,
  u16 data, u32 flags)
 {
@@ -1795,7 +1795,7 @@ static int

[PATCH 14/26] [media] dvb-frontends: reduce stack size in i2c access

2017-03-02 Thread Arnd Bergmann

A typical code fragment was copied across many dvb-frontend
drivers and causes large stack frames when built with
-fsanitize-address-use-after-scope, e.g.

drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

By marking the register access functions as noinline_for_kasan,
we can completely avoid this problem.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/dvb-frontends/ascot2e.c   |  3 ++-
 drivers/media/dvb-frontends/cxd2841er.c |  4 ++--
 drivers/media/dvb-frontends/drx39xyj/drxj.c | 14 +++---
 drivers/media/dvb-frontends/helene.c|  4 ++--
 drivers/media/dvb-frontends/horus3a.c   |  2 +-
 drivers/media/dvb-frontends/itd1000.c   |  2 +-
 drivers/media/dvb-frontends/mt312.c |  2 +-
 drivers/media/dvb-frontends/si2165.c| 14 +++---
 drivers/media/dvb-frontends/stb0899_drv.c   |  2 +-
 drivers/media/dvb-frontends/stb6100.c   |  2 +-
 drivers/media/dvb-frontends/stv0367.c   |  2 +-
 drivers/media/dvb-frontends/stv090x.c   |  2 +-
 drivers/media/dvb-frontends/stv6110.c   |  2 +-
 drivers/media/dvb-frontends/stv6110x.c  |  2 +-
 drivers/media/dvb-frontends/tda8083.c   |  2 +-
 drivers/media/dvb-frontends/zl10039.c   |  2 +-
 16 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/drivers/media/dvb-frontends/ascot2e.c 
b/drivers/media/dvb-frontends/ascot2e.c
index 0ee0df53b91b..435eb4d3f3ef 100644
--- a/drivers/media/dvb-frontends/ascot2e.c
+++ b/drivers/media/dvb-frontends/ascot2e.c
@@ -153,7 +153,8 @@ static int ascot2e_write_regs(struct ascot2e_priv *priv,
return 0;
 }
 
-static int ascot2e_write_reg(struct ascot2e_priv *priv, u8 reg, u8 val)
+static noinline_for_kasan int ascot2e_write_reg(struct ascot2e_priv *priv,
+   u8 reg, u8 val)
 {
return ascot2e_write_regs(priv, reg, , 1);
 }
diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 614bfb3740f1..01f7ec4d42c1 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -258,7 +258,7 @@ static int cxd2841er_write_regs(struct cxd2841er_priv *priv,
return 0;
 }
 
-static int cxd2841er_write_reg(struct cxd2841er_priv *priv,
+static noinline_for_kasan int cxd2841er_write_reg(struct cxd2841er_priv *priv,
   u8 addr, u8 reg, u8 val)
 {
return cxd2841er_write_regs(priv, addr, reg, , 1);
@@ -306,7 +306,7 @@ static int cxd2841er_read_regs(struct cxd2841er_priv *priv,
return 0;
 }
 
-static int cxd2841er_read_reg(struct cxd2841er_priv *priv,
+static noinline_for_kasan int cxd2841er_read_reg(struct cxd2841er_priv *priv,
  u8 addr, u8 reg, u8 *val)
 {
return cxd2841er_read_regs(priv, addr, reg, val, 1);
diff --git a/drivers/media/dvb-frontends/drx39xyj/drxj.c 
b/drivers/media/dvb-frontends/drx39xyj/drxj.c
index daeaf965dd56..0e6540709e09 100644
--- a/drivers/media/dvb-frontends/drx39xyj/drxj.c
+++ b/drivers/media/dvb-frontends/drx39xyj/drxj.c
@@ -1516,7 +1516,7 @@ static int drxdap_fasi_read_block(struct i2c_device_addr 
*dev_addr,
 *
 **/
 
-static int drxdap_fasi_read_reg16(struct i2c_device_addr *dev_addr,
+static noinline_for_kasan int drxdap_fasi_read_reg16(struct i2c_device_addr 
*dev_addr,
 u32 addr,
 u16 *data, u32 flags)
 {
@@ -1549,7 +1549,7 @@ static int drxdap_fasi_read_reg16(struct i2c_device_addr 
*dev_addr,
 *
 **/
 
-static int drxdap_fasi_read_reg32(struct i2c_device_addr *dev_addr,
+static noinline_for_kasan int drxdap_fasi_read_reg32(struct i2c_device_addr 
*dev_addr,
 u32 addr,
 u32 *data, u32 flags)
 {
@@ -1722,7 +1722,7 @@ static int drxdap_fasi_write_block(struct i2c_device_addr 
*dev_addr,
 *
 **/
 
-static int drxdap_fasi_write_reg16(struct i2c_device_addr *dev_addr,
+static noinline_for_kasan int drxdap_fasi_write_reg16(struct i2c_device_addr 
*dev_addr,
  u32 addr,
  u16 data, u32 flags)
 {
@@ -1795,7 +1795,7 @@ static int drxdap_fasi_read_modify_write_reg16(struct

[PATCH 26/26] kasan: rework Kconfig settings

2017-03-02 Thread Arnd Bergmann

We get a lot of very large stack frames using gcc-7.0.1 with the default
-fsanitize-address-use-after-scope --param asan-stack=1 options, which
can easily cause an overflow of the kernel stack, e.g.

drivers/acpi/nfit/core.c:2686:1: warning: the frame size of 4080 bytes is 
larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/amd/amdgpu/si.c:1756:1: warning: the frame size of 7304 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/i915/gvt/handlers.c:2200:1: warning: the frame size of 43752 
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:952:1: warning: the frame size of 6032 
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/isdn/hardware/avm/b1.c:637:1: warning: the frame size of 13200 bytes is 
larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3089:1: warning: the frame size of 5880 
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/i2c/cx25840/cx25840-core.c:4964:1: warning: the frame size of 
93992 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:4994:1: warning: the frame size 
of 23928 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/staging/dgnc/dgnc_tty.c:2788:1: warning: the frame size of 7072 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
fs/ntfs/mft.c:2762:1: warning: the frame size of 7432 bytes is larger than 2048 
bytes [-Wframe-larger-than=]
lib/atomic64_test.c:242:1: warning: the frame size of 12648 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]

To reduce this risk, -fsanitize-address-use-after-scope is now split out
into a separate Kconfig option, vhich cannot be selected at the same
time as KMEMCHECK, leading to stack frames that are smaller than 2
kilobytes most of the time on x86_64. An earlier version of this
patch also prevented combining KASAN_EXTRA with KASAN_INLINE, but that
is no longer necessary with the latest gcc-7.0.1 snapshot.

A lot of warnings with KASAN_EXTRA go away if we disable KMEMCHECK,
as -fsanitize-address-use-after-scope seems to understand the builtin
memcpy, but adds checking code around an extern memcpy call. I had
to work around a circular dependency, as DEBUG_SLAB/SLUB depended
on !KMEMCHECK, while KASAN did it the other way round. Now we handle
both the same way.

All patches to get the frame size below 3072 bytes with KASAN_EXTRA,
and below 2048 bytes without it have been submitted, so we can make
those the default now. Note that KASAN is only supported on arm64
and x86_64 at the moment, and both use 2048 byte stacks by default.
This reverts parts of commit commit 3f181b4 ("lib/Kconfig.debug:
disable -Wframe-larger-than warnings with KASAN=y").

I experimented a bit more with smaller stack frames and have another
follow-up series that reduces the warning limit for 64-bit architectures
to 1280 bytes and 1536 when CONFIG_KASAN (but not KASAN_EXTRA) is
enabled, this requires another ~25 patches to address the additional
warnings.

Signed-off-by: Arnd Bergmann 
---
 lib/Kconfig.debug  |  9 -
 lib/Kconfig.kasan  | 11 ++-
 lib/Kconfig.kmemcheck  |  1 +
 scripts/Makefile.kasan |  3 +++
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 97d62c2da6c2..27c838c40a36 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -216,10 +216,9 @@ config ENABLE_MUST_CHECK
 config FRAME_WARN
int "Warn for stack frames larger than (needs gcc 4.4)"
range 0 8192
-   default 0 if KASAN
-   default 2048 if GCC_PLUGIN_LATENT_ENTROPY
+   default 3072 if KASAN_EXTRA
default 1024 if !64BIT
-   default 2048 if 64BIT
+   default 1280 if 64BIT
help
  Tell gcc to warn at build time for stack frames larger than this.
  Setting this too low will cause a lot of warnings.
@@ -499,7 +498,7 @@ config DEBUG_OBJECTS_ENABLE_DEFAULT
 
 config DEBUG_SLAB
bool "Debug slab memory allocations"
-   depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
+   depends on DEBUG_KERNEL && SLAB && !KMEMCHECK && !KASAN
help
  Say Y here to have the kernel do limited verification on memory
  allocation as well as poisoning memory on free to catch use of freed
@@ -511,7 +510,7 @@ config DEBUG_SLAB_LEAK
 
 config SLUB_DEBUG_ON
bool "SLUB debugging on by default"
-   depends on SLUB && SLUB_DEBUG && !KMEMCHECK
+   depends on SLUB && SLUB_DEBUG && !KMEMCHECK && !KASAN
default n
help
  Boot with debugging on by default. SLUB boots by default with
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index bd38aab05929..e88ce7cc13bb 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -5,7 +5,7 @@ if HAVE_ARCH_KASAN
 
 config KASAN
bool "KASan: runtime memory debugger"
-   depends on SLUB || (SLAB && !DEBUG_SLAB)
+   depends on SLUB || SLAB

[PATCH 26/26] kasan: rework Kconfig settings

2017-03-02 Thread Arnd Bergmann

We get a lot of very large stack frames using gcc-7.0.1 with the default
-fsanitize-address-use-after-scope --param asan-stack=1 options, which
can easily cause an overflow of the kernel stack, e.g.

drivers/acpi/nfit/core.c:2686:1: warning: the frame size of 4080 bytes is 
larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/amd/amdgpu/si.c:1756:1: warning: the frame size of 7304 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/i915/gvt/handlers.c:2200:1: warning: the frame size of 43752 
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:952:1: warning: the frame size of 6032 
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/isdn/hardware/avm/b1.c:637:1: warning: the frame size of 13200 bytes is 
larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3089:1: warning: the frame size of 5880 
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/i2c/cx25840/cx25840-core.c:4964:1: warning: the frame size of 
93992 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:4994:1: warning: the frame size 
of 23928 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/staging/dgnc/dgnc_tty.c:2788:1: warning: the frame size of 7072 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
fs/ntfs/mft.c:2762:1: warning: the frame size of 7432 bytes is larger than 2048 
bytes [-Wframe-larger-than=]
lib/atomic64_test.c:242:1: warning: the frame size of 12648 bytes is larger 
than 2048 bytes [-Wframe-larger-than=]

To reduce this risk, -fsanitize-address-use-after-scope is now split out
into a separate Kconfig option, vhich cannot be selected at the same
time as KMEMCHECK, leading to stack frames that are smaller than 2
kilobytes most of the time on x86_64. An earlier version of this
patch also prevented combining KASAN_EXTRA with KASAN_INLINE, but that
is no longer necessary with the latest gcc-7.0.1 snapshot.

A lot of warnings with KASAN_EXTRA go away if we disable KMEMCHECK,
as -fsanitize-address-use-after-scope seems to understand the builtin
memcpy, but adds checking code around an extern memcpy call. I had
to work around a circular dependency, as DEBUG_SLAB/SLUB depended
on !KMEMCHECK, while KASAN did it the other way round. Now we handle
both the same way.

All patches to get the frame size below 3072 bytes with KASAN_EXTRA,
and below 2048 bytes without it have been submitted, so we can make
those the default now. Note that KASAN is only supported on arm64
and x86_64 at the moment, and both use 2048 byte stacks by default.
This reverts parts of commit commit 3f181b4 ("lib/Kconfig.debug:
disable -Wframe-larger-than warnings with KASAN=y").

I experimented a bit more with smaller stack frames and have another
follow-up series that reduces the warning limit for 64-bit architectures
to 1280 bytes and 1536 when CONFIG_KASAN (but not KASAN_EXTRA) is
enabled, this requires another ~25 patches to address the additional
warnings.

Signed-off-by: Arnd Bergmann 
---
 lib/Kconfig.debug  |  9 -
 lib/Kconfig.kasan  | 11 ++-
 lib/Kconfig.kmemcheck  |  1 +
 scripts/Makefile.kasan |  3 +++
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 97d62c2da6c2..27c838c40a36 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -216,10 +216,9 @@ config ENABLE_MUST_CHECK
 config FRAME_WARN
int "Warn for stack frames larger than (needs gcc 4.4)"
range 0 8192
-   default 0 if KASAN
-   default 2048 if GCC_PLUGIN_LATENT_ENTROPY
+   default 3072 if KASAN_EXTRA
default 1024 if !64BIT
-   default 2048 if 64BIT
+   default 1280 if 64BIT
help
  Tell gcc to warn at build time for stack frames larger than this.
  Setting this too low will cause a lot of warnings.
@@ -499,7 +498,7 @@ config DEBUG_OBJECTS_ENABLE_DEFAULT
 
 config DEBUG_SLAB
bool "Debug slab memory allocations"
-   depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
+   depends on DEBUG_KERNEL && SLAB && !KMEMCHECK && !KASAN
help
  Say Y here to have the kernel do limited verification on memory
  allocation as well as poisoning memory on free to catch use of freed
@@ -511,7 +510,7 @@ config DEBUG_SLAB_LEAK
 
 config SLUB_DEBUG_ON
bool "SLUB debugging on by default"
-   depends on SLUB && SLUB_DEBUG && !KMEMCHECK
+   depends on SLUB && SLUB_DEBUG && !KMEMCHECK && !KASAN
default n
help
  Boot with debugging on by default. SLUB boots by default with
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index bd38aab05929..e88ce7cc13bb 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -5,7 +5,7 @@ if HAVE_ARCH_KASAN
 
 config KASAN
bool "KASan: runtime memory debugger"
-   depends on SLUB || (SLAB && !DEBUG_SLAB)
+   depends on SLUB || SLAB
select

[PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

2017-03-02 Thread Arnd Bergmann

When CONFIG_KASAN is enabled, the READ_ONCE/WRITE_ONCE macros cause
rather large kernel stacks, e.g.:

mm/vmscan.c: In function 'shrink_page_list':
mm/vmscan.c:1333:1: error: the frame size of 3456 bytes is larger than 3072 
bytes [-Werror=frame-larger-than=]
block/cfq-iosched.c: In function 'cfqg_stats_add_aux':
block/cfq-iosched.c:750:1: error: the frame size of 4048 bytes is larger than 
3072 bytes [-Werror=frame-larger-than=]
fs/btrfs/disk-io.c: In function 'open_ctree':
fs/btrfs/disk-io.c:3314:1: error: the frame size of 3136 bytes is larger than 
3072 bytes [-Werror=frame-larger-than=]
fs/btrfs/relocation.c: In function 'build_backref_tree':
fs/btrfs/relocation.c:1193:1: error: the frame size of 4336 bytes is larger 
than 3072 bytes [-Werror=frame-larger-than=]
fs/fscache/stats.c: In function 'fscache_stats_show':
fs/fscache/stats.c:287:1: error: the frame size of 6512 bytes is larger than 
3072 bytes [-Werror=frame-larger-than=]
fs/jbd2/commit.c: In function 'jbd2_journal_commit_transaction':
fs/jbd2/commit.c:1139:1: error: the frame size of 3760 bytes is larger than 
3072 bytes [-Werror=frame-larger-than=]

This attempts a rewrite of the two macros, using a simpler implementation
for the most common case of having a naturally aligned 1, 2, 4, or (on
64-bit architectures) 8  byte object that can be accessed with a single
instruction.  For these, we go back to a volatile pointer dereference
that we had with the ACCESS_ONCE macro.

READ_ONCE/WRITE_ONCE also try to handle unaligned objects and objects
of other sizes by forcing either a word-size access (which may trap
on some architectures) or doing a non-atomic memcpy. I could not figure
out what these are actually used for, but they appear to be done
intentionally, so I'm leaving that code untouched.

I had to fix up a couple of files that either use WRITE_ONCE() as an
implicit typecast, or ignore the result of READ_ONCE(). In all cases,
the modified code seems no worse to me than the original.

Cc: Christian Borntraeger 
Cc: Paul McKenney 
Signed-off-by: Arnd Bergmann 
---
 arch/x86/include/asm/switch_to.h |  2 +-
 fs/overlayfs/util.c  |  6 ++---
 include/linux/compiler.h | 47 
 3 files changed, 42 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index fcc5cd387fd1..0c243dd569fe 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -30,7 +30,7 @@ static inline void prepare_switch_to(struct task_struct *prev,
 *
 * To minimize cache pollution, just follow the stack pointer.
 */
-   READ_ONCE(*(unsigned char *)next->thread.sp);
+   (void)READ_ONCE(*(unsigned char *)next->thread.sp);
 #endif
 }
 
diff --git a/fs/overlayfs/util.c b/fs/overlayfs/util.c
index 952286f4826c..1c10632a48bb 100644
--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -222,8 +222,8 @@ void ovl_dentry_update(struct dentry *dentry, struct dentry 
*upperdentry)
 
 void ovl_inode_init(struct inode *inode, struct inode *realinode, bool 
is_upper)
 {
-   WRITE_ONCE(inode->i_private, (unsigned long) realinode |
-  (is_upper ? OVL_ISUPPER_MASK : 0));
+   WRITE_ONCE(inode->i_private, (void *)((unsigned long) realinode |
+  (is_upper ? OVL_ISUPPER_MASK : 0)));
 }
 
 void ovl_inode_update(struct inode *inode, struct inode *upperinode)
@@ -231,7 +231,7 @@ void ovl_inode_update(struct inode *inode, struct inode 
*upperinode)
WARN_ON(!upperinode);
WARN_ON(!inode_unhashed(inode));
WRITE_ONCE(inode->i_private,
-  (unsigned long) upperinode | OVL_ISUPPER_MASK);
+  (void *)((unsigned long) upperinode | OVL_ISUPPER_MASK));
if (!S_ISDIR(upperinode->i_mode))
__insert_inode_hash(inode, (unsigned long) upperinode);
 }
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 56b90897a459..b619f5853af8 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -288,6 +288,10 @@ static __always_inline void __write_once_size(volatile 
void *p, void *res, int s
}
 }
 
+#define __ALIGNED_WORD(x)  \
+   ((sizeof(x) == 1 || sizeof(x) == 2 || sizeof(x) == 4 || \
+ sizeof(x) == sizeof(long)) && (sizeof(x) == __alignof__(x)))  \
+
 /*
  * Prevent the compiler from merging or refetching reads or writes. The
  * compiler is also forbidden from reordering successive instances of
@@ -309,8 +313,13 @@ static __always_inline void __write_once_size(volatile 
void *p, void *res, int s
  * mutilate accesses that either do not require ordering or that interact
  * with an explicit memory barrier or atomic instruction that provides the
  * required ordering.
+ *
+ * Unaligned data is particularly tricky here: if the type that gets
+ * passed in is not

[PATCH 13/26] rtl8180: reduce stack size for KASAN

2017-03-02 Thread Arnd Bergmann

When CONFIG_KASAN is set, we see overly large stack frames from inlining
functions with local variables:

drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c: In function 
'rtl8225se_rf_init':
drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c:431:1: warning: the 
frame size of 4384 bytes is larger than 3072 bytes [-Wframe-larger-than=]

This marks them noinline_for_kasan.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c 
b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c
index fde89866fa8d..1efa098a2e32 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c
@@ -174,14 +174,14 @@ static void rtl8187se_three_wire_io(struct ieee80211_hw 
*dev, u8 *data,
} while (0);
 }
 
-static u32 rtl8187se_rf_readreg(struct ieee80211_hw *dev, u8 addr)
+static noinline_for_kasan u32 rtl8187se_rf_readreg(struct ieee80211_hw *dev, 
u8 addr)
 {
u32 dataread = addr & 0x0F;
rtl8187se_three_wire_io(dev, (u8 *), 16, 0);
return dataread;
 }
 
-static void rtl8187se_rf_writereg(struct ieee80211_hw *dev, u8 addr, u32 data)
+static noinline_for_kasan void rtl8187se_rf_writereg(struct ieee80211_hw *dev, 
u8 addr, u32 data)
 {
u32 outdata = (data << 4) | (u32)(addr & 0x0F);
rtl8187se_three_wire_io(dev, (u8 *), 16, 1);
-- 
2.9.0

[PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

2017-03-02 Thread Arnd Bergmann

When CONFIG_KASAN is enabled, the READ_ONCE/WRITE_ONCE macros cause
rather large kernel stacks, e.g.:

mm/vmscan.c: In function 'shrink_page_list':
mm/vmscan.c:1333:1: error: the frame size of 3456 bytes is larger than 3072 
bytes [-Werror=frame-larger-than=]
block/cfq-iosched.c: In function 'cfqg_stats_add_aux':
block/cfq-iosched.c:750:1: error: the frame size of 4048 bytes is larger than 
3072 bytes [-Werror=frame-larger-than=]
fs/btrfs/disk-io.c: In function 'open_ctree':
fs/btrfs/disk-io.c:3314:1: error: the frame size of 3136 bytes is larger than 
3072 bytes [-Werror=frame-larger-than=]
fs/btrfs/relocation.c: In function 'build_backref_tree':
fs/btrfs/relocation.c:1193:1: error: the frame size of 4336 bytes is larger 
than 3072 bytes [-Werror=frame-larger-than=]
fs/fscache/stats.c: In function 'fscache_stats_show':
fs/fscache/stats.c:287:1: error: the frame size of 6512 bytes is larger than 
3072 bytes [-Werror=frame-larger-than=]
fs/jbd2/commit.c: In function 'jbd2_journal_commit_transaction':
fs/jbd2/commit.c:1139:1: error: the frame size of 3760 bytes is larger than 
3072 bytes [-Werror=frame-larger-than=]

This attempts a rewrite of the two macros, using a simpler implementation
for the most common case of having a naturally aligned 1, 2, 4, or (on
64-bit architectures) 8  byte object that can be accessed with a single
instruction.  For these, we go back to a volatile pointer dereference
that we had with the ACCESS_ONCE macro.

READ_ONCE/WRITE_ONCE also try to handle unaligned objects and objects
of other sizes by forcing either a word-size access (which may trap
on some architectures) or doing a non-atomic memcpy. I could not figure
out what these are actually used for, but they appear to be done
intentionally, so I'm leaving that code untouched.

I had to fix up a couple of files that either use WRITE_ONCE() as an
implicit typecast, or ignore the result of READ_ONCE(). In all cases,
the modified code seems no worse to me than the original.

Cc: Christian Borntraeger 
Cc: Paul McKenney 
Signed-off-by: Arnd Bergmann 
---
 arch/x86/include/asm/switch_to.h |  2 +-
 fs/overlayfs/util.c  |  6 ++---
 include/linux/compiler.h | 47 
 3 files changed, 42 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index fcc5cd387fd1..0c243dd569fe 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -30,7 +30,7 @@ static inline void prepare_switch_to(struct task_struct *prev,
 *
 * To minimize cache pollution, just follow the stack pointer.
 */
-   READ_ONCE(*(unsigned char *)next->thread.sp);
+   (void)READ_ONCE(*(unsigned char *)next->thread.sp);
 #endif
 }
 
diff --git a/fs/overlayfs/util.c b/fs/overlayfs/util.c
index 952286f4826c..1c10632a48bb 100644
--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -222,8 +222,8 @@ void ovl_dentry_update(struct dentry *dentry, struct dentry 
*upperdentry)
 
 void ovl_inode_init(struct inode *inode, struct inode *realinode, bool 
is_upper)
 {
-   WRITE_ONCE(inode->i_private, (unsigned long) realinode |
-  (is_upper ? OVL_ISUPPER_MASK : 0));
+   WRITE_ONCE(inode->i_private, (void *)((unsigned long) realinode |
+  (is_upper ? OVL_ISUPPER_MASK : 0)));
 }
 
 void ovl_inode_update(struct inode *inode, struct inode *upperinode)
@@ -231,7 +231,7 @@ void ovl_inode_update(struct inode *inode, struct inode 
*upperinode)
WARN_ON(!upperinode);
WARN_ON(!inode_unhashed(inode));
WRITE_ONCE(inode->i_private,
-  (unsigned long) upperinode | OVL_ISUPPER_MASK);
+  (void *)((unsigned long) upperinode | OVL_ISUPPER_MASK));
if (!S_ISDIR(upperinode->i_mode))
__insert_inode_hash(inode, (unsigned long) upperinode);
 }
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 56b90897a459..b619f5853af8 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -288,6 +288,10 @@ static __always_inline void __write_once_size(volatile 
void *p, void *res, int s
}
 }
 
+#define __ALIGNED_WORD(x)  \
+   ((sizeof(x) == 1 || sizeof(x) == 2 || sizeof(x) == 4 || \
+ sizeof(x) == sizeof(long)) && (sizeof(x) == __alignof__(x)))  \
+
 /*
  * Prevent the compiler from merging or refetching reads or writes. The
  * compiler is also forbidden from reordering successive instances of
@@ -309,8 +313,13 @@ static __always_inline void __write_once_size(volatile 
void *p, void *res, int s
  * mutilate accesses that either do not require ordering or that interact
  * with an explicit memory barrier or atomic instruction that provides the
  * required ordering.
+ *
+ * Unaligned data is particularly tricky here: if the type that gets
+ * passed in is not naturally aligned, we cast to a type of higher
+ * alignment, which

[PATCH 13/26] rtl8180: reduce stack size for KASAN

2017-03-02 Thread Arnd Bergmann

When CONFIG_KASAN is set, we see overly large stack frames from inlining
functions with local variables:

drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c: In function 
'rtl8225se_rf_init':
drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c:431:1: warning: the 
frame size of 4384 bytes is larger than 3072 bytes [-Wframe-larger-than=]

This marks them noinline_for_kasan.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c 
b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c
index fde89866fa8d..1efa098a2e32 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c
@@ -174,14 +174,14 @@ static void rtl8187se_three_wire_io(struct ieee80211_hw 
*dev, u8 *data,
} while (0);
 }
 
-static u32 rtl8187se_rf_readreg(struct ieee80211_hw *dev, u8 addr)
+static noinline_for_kasan u32 rtl8187se_rf_readreg(struct ieee80211_hw *dev, 
u8 addr)
 {
u32 dataread = addr & 0x0F;
rtl8187se_three_wire_io(dev, (u8 *), 16, 0);
return dataread;
 }
 
-static void rtl8187se_rf_writereg(struct ieee80211_hw *dev, u8 addr, u32 data)
+static noinline_for_kasan void rtl8187se_rf_writereg(struct ieee80211_hw *dev, 
u8 addr, u32 data)
 {
u32 outdata = (data << 4) | (u32)(addr & 0x0F);
rtl8187se_three_wire_io(dev, (u8 *), 16, 1);
-- 
2.9.0

[PATCH 19/26] [media] r820t: mark register functions as noinline_for_kasan

2017-03-02 Thread Arnd Bergmann

With KASAN, we get an overly long stack frame due to inlining
the register access function:

drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is 
larger than 2048 bytes [-Werror=frame-larger-than=]

An earlier patch I tried used an open-coded r820t_write_reg()
implementation that may have been more efficent, while this
version simply adds the annotation, which has a lower risk for
regressions.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/tuners/r820t.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c
index ba80376a3b86..0fbfa6416e38 100644
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -396,7 +396,7 @@ static int r820t_write(struct r820t_priv *priv, u8 reg, 
const u8 *val,
return 0;
 }
 
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static noinline_for_kasan int r820t_write_reg(struct r820t_priv *priv, u8 reg, 
u8 val)
 {
return r820t_write(priv, reg, , 1);
 }
@@ -411,7 +411,7 @@ static int r820t_read_cache_reg(struct r820t_priv *priv, 
int reg)
return -EINVAL;
 }
 
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static noinline_for_kasan int r820t_write_reg_mask(struct r820t_priv *priv, u8 
reg, u8 val,
u8 bit_mask)
 {
int rc = r820t_read_cache_reg(priv, reg);
-- 
2.9.0

[PATCH 19/26] [media] r820t: mark register functions as noinline_for_kasan

2017-03-02 Thread Arnd Bergmann

With KASAN, we get an overly long stack frame due to inlining
the register access function:

drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is 
larger than 2048 bytes [-Werror=frame-larger-than=]

An earlier patch I tried used an open-coded r820t_write_reg()
implementation that may have been more efficent, while this
version simply adds the annotation, which has a lower risk for
regressions.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/tuners/r820t.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c
index ba80376a3b86..0fbfa6416e38 100644
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -396,7 +396,7 @@ static int r820t_write(struct r820t_priv *priv, u8 reg, 
const u8 *val,
return 0;
 }
 
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static noinline_for_kasan int r820t_write_reg(struct r820t_priv *priv, u8 reg, 
u8 val)
 {
return r820t_write(priv, reg, , 1);
 }
@@ -411,7 +411,7 @@ static int r820t_read_cache_reg(struct r820t_priv *priv, 
int reg)
return -EINVAL;
 }
 
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static noinline_for_kasan int r820t_write_reg_mask(struct r820t_priv *priv, u8 
reg, u8 val,
u8 bit_mask)
 {
int rc = r820t_read_cache_reg(priv, reg);
-- 
2.9.0

[RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

2017-03-02 Thread Brijesh Singh

If kernel_maps_pages_in_pgd is called early in boot process to change the
memory attributes then it fails to allocate memory when spliting large
pages. The patch extends the cpa_data to provide the support to use
memblock_alloc when slab allocator is not available.

The feature will be used in Secure Encrypted Virtualization (SEV) mode,
where we may need to change the memory region attributes in early boot
process.

Signed-off-by: Brijesh Singh 
---
 arch/x86/mm/pageattr.c |   51 
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 46cc89d..9e4ab3b 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -37,6 +38,7 @@ struct cpa_data {
int flags;
unsigned long   pfn;
unsignedforce_split : 1;
+   unsignedforce_memblock :1;
int curpage;
struct page **pages;
 };
@@ -627,9 +629,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 
 static int
 __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
-  struct page *base)
+ pte_t *pbase, unsigned long new_pfn)
 {
-   pte_t *pbase = (pte_t *)page_address(base);
unsigned long ref_pfn, pfn, pfninc = 1;
unsigned int i, level;
pte_t *tmp;
@@ -646,7 +647,7 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
return 1;
}
 
-   paravirt_alloc_pte(_mm, page_to_pfn(base));
+   paravirt_alloc_pte(_mm, new_pfn);
 
switch (level) {
case PG_LEVEL_2M:
@@ -707,7 +708,8 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
 * pagetable protections, the actual ptes set above control the
 * primary protection behavior:
 */
-   __set_pmd_pte(kpte, address, mk_pte(base, __pgprot(_KERNPG_TABLE)));
+   __set_pmd_pte(kpte, address,
+   native_make_pte((new_pfn << PAGE_SHIFT) + _KERNPG_TABLE));
 
/*
 * Intel Atom errata AAH41 workaround.
@@ -723,21 +725,50 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
return 0;
 }
 
+static pte_t *try_alloc_pte(struct cpa_data *cpa, unsigned long *pfn)
+{
+   unsigned long phys;
+   struct page *base;
+
+   if (cpa->force_memblock) {
+   phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+   if (!phys)
+   return NULL;
+   *pfn = phys >> PAGE_SHIFT;
+   return (pte_t *)__va(phys);
+   }
+
+   base = alloc_pages(GFP_KERNEL | __GFP_NOTRACK, 0);
+   if (!base)
+   return NULL;
+   *pfn = page_to_pfn(base);
+   return (pte_t *)page_address(base);
+}
+
+static void try_free_pte(struct cpa_data *cpa, pte_t *pte)
+{
+   if (cpa->force_memblock)
+   memblock_free(__pa(pte), PAGE_SIZE);
+   else
+   __free_page((struct page *)pte);
+}
+
 static int split_large_page(struct cpa_data *cpa, pte_t *kpte,
unsigned long address)
 {
-   struct page *base;
+   pte_t *new_pte;
+   unsigned long new_pfn;
 
if (!debug_pagealloc_enabled())
spin_unlock(_lock);
-   base = alloc_pages(GFP_KERNEL | __GFP_NOTRACK, 0);
+   new_pte = try_alloc_pte(cpa, _pfn);
if (!debug_pagealloc_enabled())
spin_lock(_lock);
-   if (!base)
+   if (!new_pte)
return -ENOMEM;
 
-   if (__split_large_page(cpa, kpte, address, base))
-   __free_page(base);
+   if (__split_large_page(cpa, kpte, address, new_pte, new_pfn))
+   try_free_pte(cpa, new_pte);
 
return 0;
 }
@@ -2035,6 +2066,7 @@ int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned 
long address,
unsigned numpages, unsigned long page_flags)
 {
int retval = -EINVAL;
+   int use_memblock = !slab_is_available();
 
struct cpa_data cpa = {
.vaddr = ,
@@ -2044,6 +2076,7 @@ int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned 
long address,
.mask_set = __pgprot(0),
.mask_clr = __pgprot(0),
.flags = 0,
+   .force_memblock = use_memblock,
};
 
if (!(__supported_pte_mask & _PAGE_NX))

[RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

2017-03-02 Thread Brijesh Singh

If kernel_maps_pages_in_pgd is called early in boot process to change the
memory attributes then it fails to allocate memory when spliting large
pages. The patch extends the cpa_data to provide the support to use
memblock_alloc when slab allocator is not available.

The feature will be used in Secure Encrypted Virtualization (SEV) mode,
where we may need to change the memory region attributes in early boot
process.

Signed-off-by: Brijesh Singh 
---
 arch/x86/mm/pageattr.c |   51 
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 46cc89d..9e4ab3b 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -37,6 +38,7 @@ struct cpa_data {
int flags;
unsigned long   pfn;
unsignedforce_split : 1;
+   unsignedforce_memblock :1;
int curpage;
struct page **pages;
 };
@@ -627,9 +629,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,
 
 static int
 __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
-  struct page *base)
+ pte_t *pbase, unsigned long new_pfn)
 {
-   pte_t *pbase = (pte_t *)page_address(base);
unsigned long ref_pfn, pfn, pfninc = 1;
unsigned int i, level;
pte_t *tmp;
@@ -646,7 +647,7 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
return 1;
}
 
-   paravirt_alloc_pte(_mm, page_to_pfn(base));
+   paravirt_alloc_pte(_mm, new_pfn);
 
switch (level) {
case PG_LEVEL_2M:
@@ -707,7 +708,8 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
 * pagetable protections, the actual ptes set above control the
 * primary protection behavior:
 */
-   __set_pmd_pte(kpte, address, mk_pte(base, __pgprot(_KERNPG_TABLE)));
+   __set_pmd_pte(kpte, address,
+   native_make_pte((new_pfn << PAGE_SHIFT) + _KERNPG_TABLE));
 
/*
 * Intel Atom errata AAH41 workaround.
@@ -723,21 +725,50 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
return 0;
 }
 
+static pte_t *try_alloc_pte(struct cpa_data *cpa, unsigned long *pfn)
+{
+   unsigned long phys;
+   struct page *base;
+
+   if (cpa->force_memblock) {
+   phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+   if (!phys)
+   return NULL;
+   *pfn = phys >> PAGE_SHIFT;
+   return (pte_t *)__va(phys);
+   }
+
+   base = alloc_pages(GFP_KERNEL | __GFP_NOTRACK, 0);
+   if (!base)
+   return NULL;
+   *pfn = page_to_pfn(base);
+   return (pte_t *)page_address(base);
+}
+
+static void try_free_pte(struct cpa_data *cpa, pte_t *pte)
+{
+   if (cpa->force_memblock)
+   memblock_free(__pa(pte), PAGE_SIZE);
+   else
+   __free_page((struct page *)pte);
+}
+
 static int split_large_page(struct cpa_data *cpa, pte_t *kpte,
unsigned long address)
 {
-   struct page *base;
+   pte_t *new_pte;
+   unsigned long new_pfn;
 
if (!debug_pagealloc_enabled())
spin_unlock(_lock);
-   base = alloc_pages(GFP_KERNEL | __GFP_NOTRACK, 0);
+   new_pte = try_alloc_pte(cpa, _pfn);
if (!debug_pagealloc_enabled())
spin_lock(_lock);
-   if (!base)
+   if (!new_pte)
return -ENOMEM;
 
-   if (__split_large_page(cpa, kpte, address, base))
-   __free_page(base);
+   if (__split_large_page(cpa, kpte, address, new_pte, new_pfn))
+   try_free_pte(cpa, new_pte);
 
return 0;
 }
@@ -2035,6 +2066,7 @@ int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned 
long address,
unsigned numpages, unsigned long page_flags)
 {
int retval = -EINVAL;
+   int use_memblock = !slab_is_available();
 
struct cpa_data cpa = {
.vaddr = ,
@@ -2044,6 +2076,7 @@ int kernel_map_pages_in_pgd(pgd_t *pgd, u64 pfn, unsigned 
long address,
.mask_set = __pgprot(0),
.mask_clr = __pgprot(0),
.flags = 0,
+   .force_memblock = use_memblock,
};
 
if (!(__supported_pte_mask & _PAGE_NX))

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

2017-03-02 Thread Christian Borntraeger

On 03/02/2017 05:38 PM, Arnd Bergmann wrote:
> When CONFIG_KASAN is enabled, the READ_ONCE/WRITE_ONCE macros cause
> rather large kernel stacks, e.g.:
> 
> mm/vmscan.c: In function 'shrink_page_list':
> mm/vmscan.c:1333:1: error: the frame size of 3456 bytes is larger than 3072 
> bytes [-Werror=frame-larger-than=]
> block/cfq-iosched.c: In function 'cfqg_stats_add_aux':
> block/cfq-iosched.c:750:1: error: the frame size of 4048 bytes is larger than 
> 3072 bytes [-Werror=frame-larger-than=]
> fs/btrfs/disk-io.c: In function 'open_ctree':
> fs/btrfs/disk-io.c:3314:1: error: the frame size of 3136 bytes is larger than 
> 3072 bytes [-Werror=frame-larger-than=]
> fs/btrfs/relocation.c: In function 'build_backref_tree':
> fs/btrfs/relocation.c:1193:1: error: the frame size of 4336 bytes is larger 
> than 3072 bytes [-Werror=frame-larger-than=]
> fs/fscache/stats.c: In function 'fscache_stats_show':
> fs/fscache/stats.c:287:1: error: the frame size of 6512 bytes is larger than 
> 3072 bytes [-Werror=frame-larger-than=]
> fs/jbd2/commit.c: In function 'jbd2_journal_commit_transaction':
> fs/jbd2/commit.c:1139:1: error: the frame size of 3760 bytes is larger than 
> 3072 bytes [-Werror=frame-larger-than=]
> 
> This attempts a rewrite of the two macros, using a simpler implementation
> for the most common case of having a naturally aligned 1, 2, 4, or (on
> 64-bit architectures) 8  byte object that can be accessed with a single
> instruction.  For these, we go back to a volatile pointer dereference
> that we had with the ACCESS_ONCE macro.

We had changed that back then because gcc 4.6 and 4.7 had a bug that could
removed the volatile statement on aggregate types like the following one

union ipte_control {
unsigned long val;
struct {
unsigned long k  : 1;
unsigned long kh : 31;
unsigned long kg : 32;
};
};

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145

If I see that right, your __ALIGNED_WORD(x)
macro would say that for above structure  sizeof(x) == sizeof(long)) is true,
so it would fall back to the old volatile cast and might reintroduce the 
old compiler bug?

Could you maybe you fence your simple macro for anything older than 4.9? After
all there was no kasan support anyway on these older gcc version.

Christian

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

2017-03-02 Thread Christian Borntraeger

On 03/02/2017 05:38 PM, Arnd Bergmann wrote:
> When CONFIG_KASAN is enabled, the READ_ONCE/WRITE_ONCE macros cause
> rather large kernel stacks, e.g.:
> 
> mm/vmscan.c: In function 'shrink_page_list':
> mm/vmscan.c:1333:1: error: the frame size of 3456 bytes is larger than 3072 
> bytes [-Werror=frame-larger-than=]
> block/cfq-iosched.c: In function 'cfqg_stats_add_aux':
> block/cfq-iosched.c:750:1: error: the frame size of 4048 bytes is larger than 
> 3072 bytes [-Werror=frame-larger-than=]
> fs/btrfs/disk-io.c: In function 'open_ctree':
> fs/btrfs/disk-io.c:3314:1: error: the frame size of 3136 bytes is larger than 
> 3072 bytes [-Werror=frame-larger-than=]
> fs/btrfs/relocation.c: In function 'build_backref_tree':
> fs/btrfs/relocation.c:1193:1: error: the frame size of 4336 bytes is larger 
> than 3072 bytes [-Werror=frame-larger-than=]
> fs/fscache/stats.c: In function 'fscache_stats_show':
> fs/fscache/stats.c:287:1: error: the frame size of 6512 bytes is larger than 
> 3072 bytes [-Werror=frame-larger-than=]
> fs/jbd2/commit.c: In function 'jbd2_journal_commit_transaction':
> fs/jbd2/commit.c:1139:1: error: the frame size of 3760 bytes is larger than 
> 3072 bytes [-Werror=frame-larger-than=]
> 
> This attempts a rewrite of the two macros, using a simpler implementation
> for the most common case of having a naturally aligned 1, 2, 4, or (on
> 64-bit architectures) 8  byte object that can be accessed with a single
> instruction.  For these, we go back to a volatile pointer dereference
> that we had with the ACCESS_ONCE macro.

We had changed that back then because gcc 4.6 and 4.7 had a bug that could
removed the volatile statement on aggregate types like the following one

union ipte_control {
unsigned long val;
struct {
unsigned long k  : 1;
unsigned long kh : 31;
unsigned long kg : 32;
};
};

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145

If I see that right, your __ALIGNED_WORD(x)
macro would say that for above structure  sizeof(x) == sizeof(long)) is true,
so it would fall back to the old volatile cast and might reintroduce the 
old compiler bug?

Could you maybe you fence your simple macro for anything older than 4.9? After
all there was no kasan support anyway on these older gcc version.

Christian

Re: [PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

2017-03-02 Thread Vivek Gautam

Hi Kishon,


On Wed, Feb 22, 2017 at 9:29 AM, Vivek Gautam
 wrote:
> Hi Kishon,
>
>
> On Fri, Jan 27, 2017 at 11:54 AM, Vivek Gautam
>  wrote:
>>
>>
>> On 01/26/2017 11:45 PM, Bjorn Andersson wrote:
>>>
>>> On Tue 24 Jan 01:19 PST 2017, Kishon Vijay Abraham I wrote:

 On Monday 23 January 2017 03:43 PM, Vivek Gautam wrote:
>
> On Wed, Jan 18, 2017 at 11:33 PM, Bjorn Andersson
>>>
>>> [..]
>
> Yes, that's correct. The QMP and QUSB2 phy init sequences are a bunch
> of static values for a particular IP version. These values hardly give a
> meaningful data to put few phy bindings that could be referenced
> to configure the phy further.

 Not really. You can have clearly defined phy binding to give meaningful
 data.
 Every driver doing the same configuration bloats the driver and these
 configuration values are just magic values which hardly can be reviewed
 by anyone.
>>
>> Further more moving this blob to devicetree will not allow us to treat
>> the various QMP configurations as one HW block, as there are other
>> differences as well.
>>
>> Like many other drivers it's possible to create a generic version that
>> has every bit of logic driven by configuration from devicetree, but
>> like
>> most of those cases this is not the way we split things.
>>
>> And this has the side effect of keeping the dts files human readable,
>> human understandable and human maintainable.

 right. That's why I recommend having clearly defined bindings.
 phy,tx- = 
 phy,tx- = 
 phy,tx- = 
>>>
>>> There's no doubt that this table needs to be encoded somewhere, so the
>>> question is should we hard code this in a C file or in a DTSI file.
>>>
>>> Skimming through [1] I see examples of things that differs based on how
>>> the specific component is integrated in a SoC or on a particular board -
>>> properties that are relevant to a "system integrator".
>>>
>>> As far as I can tell this blob will, if ever, only be changed by a
>>> driver developer and as such it's not carry information about how this
>>> component relates to the rest of the system and should as such not be
>>> part of the device tree.
>>>
>>>
>>> If there are properties of the hardware that is affected by how the
>>> component is integrated in the system I really would like for those to
>>> be exposed as human-readable properties that I can understand and alter
>>> without deep knowledge about the register map of the hardware block.
>>
>>
>> I am reaching out to our internal teams to get more information
>> on different possible phy configurations, based on which the registers
>> values are decided.
>> This is something that i tried to understand in the past as well, but
>> couldn't
>> grab much information that time.
>> Will come back with relevant information on this.
>>
>
> We have started looking into understanding the PHYs on msm and
> eventually create a set of generic phy bindings that can serve multiple
> platforms.
> But this task, I presume, will take its course and will involve multi-party
> discussions.
>
> For these QUSB2 and QMP phy drivers, a good amount of work has
> already gone in getting these drivers in upstream state.
> The common QMP phy driver supports a bunch of controllers on msm
> platforms - USB, PCIe and UFS and there are platforms such as DB820c
> and others that want to pull in these changes from upstream.
> The future phy controllers also depend on these drivers and we don't want
> to hold other developers to contribute to these drivers.
> So, we wish to not delay these drivers further because of the phy bindings.
> I see that there are phys that still program the registers-value pairs for
> phy initialization.
>
> We will keep working on the bindings while these patches
> make way to upstream.
>
> Can you consider pulling in these drivers?
> I can send the next version of these drivers with other comments addressed.
> Please let me know your comments.

Gentle ping. Any thoughts on this ?

>>
 [1] -> https://www.linuxplumbersconf.org/2016/ocw/proposals/4047
>>>
>>> Regards,
>>> Bjorn


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

Re: [PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

2017-03-02 Thread Vivek Gautam

Hi Kishon,


On Wed, Feb 22, 2017 at 9:29 AM, Vivek Gautam
 wrote:
> Hi Kishon,
>
>
> On Fri, Jan 27, 2017 at 11:54 AM, Vivek Gautam
>  wrote:
>>
>>
>> On 01/26/2017 11:45 PM, Bjorn Andersson wrote:
>>>
>>> On Tue 24 Jan 01:19 PST 2017, Kishon Vijay Abraham I wrote:

 On Monday 23 January 2017 03:43 PM, Vivek Gautam wrote:
>
> On Wed, Jan 18, 2017 at 11:33 PM, Bjorn Andersson
>>>
>>> [..]
>
> Yes, that's correct. The QMP and QUSB2 phy init sequences are a bunch
> of static values for a particular IP version. These values hardly give a
> meaningful data to put few phy bindings that could be referenced
> to configure the phy further.

 Not really. You can have clearly defined phy binding to give meaningful
 data.
 Every driver doing the same configuration bloats the driver and these
 configuration values are just magic values which hardly can be reviewed
 by anyone.
>>
>> Further more moving this blob to devicetree will not allow us to treat
>> the various QMP configurations as one HW block, as there are other
>> differences as well.
>>
>> Like many other drivers it's possible to create a generic version that
>> has every bit of logic driven by configuration from devicetree, but
>> like
>> most of those cases this is not the way we split things.
>>
>> And this has the side effect of keeping the dts files human readable,
>> human understandable and human maintainable.

 right. That's why I recommend having clearly defined bindings.
 phy,tx- = 
 phy,tx- = 
 phy,tx- = 
>>>
>>> There's no doubt that this table needs to be encoded somewhere, so the
>>> question is should we hard code this in a C file or in a DTSI file.
>>>
>>> Skimming through [1] I see examples of things that differs based on how
>>> the specific component is integrated in a SoC or on a particular board -
>>> properties that are relevant to a "system integrator".
>>>
>>> As far as I can tell this blob will, if ever, only be changed by a
>>> driver developer and as such it's not carry information about how this
>>> component relates to the rest of the system and should as such not be
>>> part of the device tree.
>>>
>>>
>>> If there are properties of the hardware that is affected by how the
>>> component is integrated in the system I really would like for those to
>>> be exposed as human-readable properties that I can understand and alter
>>> without deep knowledge about the register map of the hardware block.
>>
>>
>> I am reaching out to our internal teams to get more information
>> on different possible phy configurations, based on which the registers
>> values are decided.
>> This is something that i tried to understand in the past as well, but
>> couldn't
>> grab much information that time.
>> Will come back with relevant information on this.
>>
>
> We have started looking into understanding the PHYs on msm and
> eventually create a set of generic phy bindings that can serve multiple
> platforms.
> But this task, I presume, will take its course and will involve multi-party
> discussions.
>
> For these QUSB2 and QMP phy drivers, a good amount of work has
> already gone in getting these drivers in upstream state.
> The common QMP phy driver supports a bunch of controllers on msm
> platforms - USB, PCIe and UFS and there are platforms such as DB820c
> and others that want to pull in these changes from upstream.
> The future phy controllers also depend on these drivers and we don't want
> to hold other developers to contribute to these drivers.
> So, we wish to not delay these drivers further because of the phy bindings.
> I see that there are phys that still program the registers-value pairs for
> phy initialization.
>
> We will keep working on the bindings while these patches
> make way to upstream.
>
> Can you consider pulling in these drivers?
> I can send the next version of these drivers with other comments addressed.
> Please let me know your comments.

Gentle ping. Any thoughts on this ?

>>
 [1] -> https://www.linuxplumbersconf.org/2016/ocw/proposals/4047
>>>
>>> Regards,
>>> Bjorn


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

Re: [Outreachy kernel] [PATCH] staging: nvec: cleanup USLEEP_RANGE checkpatch checks

2017-03-02 Thread Julia Lawall



On Thu, 2 Mar 2017, SIMRAN SINGHAL wrote:

>
>
> On Thursday, March 2, 2017 at 8:31:23 PM UTC+5:30, Julia Lawall wrote:
>
>
>   On Thu, 2 Mar 2017, SIMRAN SINGHAL wrote:
>
>   >
>   >
>   > On Thursday, March 2, 2017 at 8:06:40 PM UTC+5:30, Julia
>   Lawall wrote:
>   >
>   >
>   >       On Thu, 2 Mar 2017, simran singhal wrote:
>   >
>   >       > Resolve strict checkpatch USLEEP_RANGE checks by
>   converting
>   >       delays and
>   >       > sleeps as described in
>   >       ./Documentation/timers/timers-howto.txt.
>   >       >
>   >       > CHECK: usleep_range is preferred over udelay; see
>   >       Documentation/
>   >       > timers/timers-howto.txt
>   >       >
>   >       > Signed-off-by: simran singhal 
>   >       > ---
>   >       >  drivers/staging/nvec/nvec.c | 4 ++--
>   >       >  1 file changed, 2 insertions(+), 2 deletions(-)
>   >       >
>   >       > diff --git a/drivers/staging/nvec/nvec.c
>   >       b/drivers/staging/nvec/nvec.c
>   >       > index c1feccf..cd35e64 100644
>   >       > --- a/drivers/staging/nvec/nvec.c
>   >       > +++ b/drivers/staging/nvec/nvec.c
>   >       > @@ -631,7 +631,7 @@ static irqreturn_t
>   nvec_interrupt(int irq,
>   >       void *dev)
>   >       >  break;
>   >       >  case 2:/* first byte after
>   command */
>   >       >  if (status == (I2C_SL_IRQ | RNW |
>   RCVD)) {
>   >       > -udelay(33);
>   >       > +usleep_range(33, 100);
>   >
>   >       How did you choose the upper limit.
>   >
>   >       I believe that Greg previously suggested not to make
>   these
>   >       changes if you
>   >       have no way to test them.
>   >
>   > Julia, After going through the reply given by Nicholas Mc
>   Guire 
>   >
>   
> https://www.mail-archive.com/kernelnewbies@kernelnewbies.org/msg16464.html
>   > in this reply he has mentioned that even the range of 10
>   microsecond is
>   > enough,
>   > so I prefer to take 100 as upper limit.  
>
>   Than you for the link.
>
>   It looks like he suggests to change 33 to 30-40, not to 33-100.
>    In any
>   case, you have three choices for this kind of issue:
>   1. Don't make the change, because you can't test the result
>   2. Make the change, and explain the commit log what your
>   rationale is
>   3. Make the change, and explain below the --- that you have no
>   idea what
>   you are doing, and you are just proposing the patch as something
>   concrete
>   to start a discussion.
>
>   But your preference is not a suitable justification.  The
>   hardware does
>   something, and the choice can only really be made by the person
>   who knows
>   what it does.
>
>  
> Thanks, 
> Julia I'll keep this in mind from next time.
>
> I choose the range from 33 to 100 for being on more safer side.
> Should I make it 30-40 and send v2.

I thought that the maintainer already responded saying that one shouldnot
change this code?

julia

>
>   julia
>
>   >  
>   > Simran
>   >
>   >       julia
>   >
>   >
>   >       >  if (nvec->rx->data[0] !=
>   0x01) {
>   >       >  dev_err(nvec->dev,
>   >       >  "Read without
>   prior
>   >       read command\n");
>   >       > @@ -718,7 +718,7 @@ static irqreturn_t
>   nvec_interrupt(int irq,
>   >       void *dev)
>   >       >   * We experience less incomplete messages
>   with this
>   >       delay than without
>   >       >   * it, but we don't know why. Help is
>   appreciated.
>   >       >   */
>   >       > -udelay(100);
>   >       > +usleep_range(100, 200);
>   >       >
>   >       >  return IRQ_HANDLED;
>   >       >  }
>   >       > --
>   >       > 2.7.4
>   >       >
>   >       > --
>   >       > You received this message because you are subscribed
>   to the
>   >       Google Groups "outreachy-kernel" group.
>   >       > To unsubscribe from this group and stop receiving
>   emails from
>   >       it, send an email to outreachy-kern...@googlegroups.com.
>   >       > To post to this group, send email to
>   >       outreach...@googlegroups.com.
>   >       > To view this discussion on the 
> webvisithttps://groups.google.com/d/msgid/outreachy-kernel/20170302142418.GA16
>   773%4
>   >       0singhal-Inspiron-5558.
>   >       > For more options, visit
>   https://groups.google.com/d/optout.
>   >       >
>   >

Re: [Outreachy kernel] [PATCH] staging: nvec: cleanup USLEEP_RANGE checkpatch checks

2017-03-02 Thread Julia Lawall



On Thu, 2 Mar 2017, SIMRAN SINGHAL wrote:

>
>
> On Thursday, March 2, 2017 at 8:31:23 PM UTC+5:30, Julia Lawall wrote:
>
>
>   On Thu, 2 Mar 2017, SIMRAN SINGHAL wrote:
>
>   >
>   >
>   > On Thursday, March 2, 2017 at 8:06:40 PM UTC+5:30, Julia
>   Lawall wrote:
>   >
>   >
>   >       On Thu, 2 Mar 2017, simran singhal wrote:
>   >
>   >       > Resolve strict checkpatch USLEEP_RANGE checks by
>   converting
>   >       delays and
>   >       > sleeps as described in
>   >       ./Documentation/timers/timers-howto.txt.
>   >       >
>   >       > CHECK: usleep_range is preferred over udelay; see
>   >       Documentation/
>   >       > timers/timers-howto.txt
>   >       >
>   >       > Signed-off-by: simran singhal 
>   >       > ---
>   >       >  drivers/staging/nvec/nvec.c | 4 ++--
>   >       >  1 file changed, 2 insertions(+), 2 deletions(-)
>   >       >
>   >       > diff --git a/drivers/staging/nvec/nvec.c
>   >       b/drivers/staging/nvec/nvec.c
>   >       > index c1feccf..cd35e64 100644
>   >       > --- a/drivers/staging/nvec/nvec.c
>   >       > +++ b/drivers/staging/nvec/nvec.c
>   >       > @@ -631,7 +631,7 @@ static irqreturn_t
>   nvec_interrupt(int irq,
>   >       void *dev)
>   >       >  break;
>   >       >  case 2:/* first byte after
>   command */
>   >       >  if (status == (I2C_SL_IRQ | RNW |
>   RCVD)) {
>   >       > -udelay(33);
>   >       > +usleep_range(33, 100);
>   >
>   >       How did you choose the upper limit.
>   >
>   >       I believe that Greg previously suggested not to make
>   these
>   >       changes if you
>   >       have no way to test them.
>   >
>   > Julia, After going through the reply given by Nicholas Mc
>   Guire 
>   >
>   
> https://www.mail-archive.com/kernelnewbies@kernelnewbies.org/msg16464.html
>   > in this reply he has mentioned that even the range of 10
>   microsecond is
>   > enough,
>   > so I prefer to take 100 as upper limit.  
>
>   Than you for the link.
>
>   It looks like he suggests to change 33 to 30-40, not to 33-100.
>    In any
>   case, you have three choices for this kind of issue:
>   1. Don't make the change, because you can't test the result
>   2. Make the change, and explain the commit log what your
>   rationale is
>   3. Make the change, and explain below the --- that you have no
>   idea what
>   you are doing, and you are just proposing the patch as something
>   concrete
>   to start a discussion.
>
>   But your preference is not a suitable justification.  The
>   hardware does
>   something, and the choice can only really be made by the person
>   who knows
>   what it does.
>
>  
> Thanks, 
> Julia I'll keep this in mind from next time.
>
> I choose the range from 33 to 100 for being on more safer side.
> Should I make it 30-40 and send v2.

I thought that the maintainer already responded saying that one shouldnot
change this code?

julia

>
>   julia
>
>   >  
>   > Simran
>   >
>   >       julia
>   >
>   >
>   >       >  if (nvec->rx->data[0] !=
>   0x01) {
>   >       >  dev_err(nvec->dev,
>   >       >  "Read without
>   prior
>   >       read command\n");
>   >       > @@ -718,7 +718,7 @@ static irqreturn_t
>   nvec_interrupt(int irq,
>   >       void *dev)
>   >       >   * We experience less incomplete messages
>   with this
>   >       delay than without
>   >       >   * it, but we don't know why. Help is
>   appreciated.
>   >       >   */
>   >       > -udelay(100);
>   >       > +usleep_range(100, 200);
>   >       >
>   >       >  return IRQ_HANDLED;
>   >       >  }
>   >       > --
>   >       > 2.7.4
>   >       >
>   >       > --
>   >       > You received this message because you are subscribed
>   to the
>   >       Google Groups "outreachy-kernel" group.
>   >       > To unsubscribe from this group and stop receiving
>   emails from
>   >       it, send an email to outreachy-kern...@googlegroups.com.
>   >       > To post to this group, send email to
>   >       outreach...@googlegroups.com.
>   >       > To view this discussion on the 
> webvisithttps://groups.google.com/d/msgid/outreachy-kernel/20170302142418.GA16
>   773%4
>   >       0singhal-Inspiron-5558.
>   >       > For more options, visit
>   https://groups.google.com/d/optout.
>   >       >
>   >
>   > --
>

[RFC PATCH v2 13/32] KVM: SVM: Enable SEV by setting the SEV_ENABLE CPU feature

2017-03-02 Thread Brijesh Singh

From: Tom Lendacky 

Modify the SVM cpuid update function to indicate if Secure Encrypted
Virtualization (SEV) is active in the guest by setting the SEV KVM CPU
features bit. SEV is active if Secure Memory Encryption is enabled in
the host and the SEV_ENABLE bit of the VMCB is set.

Signed-off-by: Tom Lendacky 
---
 arch/x86/kvm/cpuid.c |4 +++-
 arch/x86/kvm/svm.c   |   18 ++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 1639de8..e0c40a8 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -601,7 +601,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
entry->edx = 0;
break;
case 0x8000:
-   entry->eax = min(entry->eax, 0x801a);
+   entry->eax = min(entry->eax, 0x801f);
break;
case 0x8001:
entry->edx &= kvm_cpuid_8000_0001_edx_x86_features;
@@ -634,6 +634,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
break;
case 0x801d:
break;
+   case 0x801f:
+   break;
/*Add support for Centaur's CPUID instruction*/
case 0xC000:
/*Just support up to 0xC004 now*/
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 75b0645..36d61ff 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -46,6 +46,7 @@
 #include 
 
 #include 
+#include 
 #include "trace.h"
 
 #define __ex(x) __kvm_handle_fault_on_reboot(x)
@@ -5005,10 +5006,27 @@ static void svm_cpuid_update(struct kvm_vcpu *vcpu)
 {
struct vcpu_svm *svm = to_svm(vcpu);
struct kvm_cpuid_entry2 *entry;
+   struct vmcb_control_area *ca = >vmcb->control;
+   struct kvm_cpuid_entry2 *features, *sev_info;
 
/* Update nrips enabled cache */
svm->nrips_enabled = !!guest_cpuid_has_nrips(>vcpu);
 
+   /* Check for Secure Encrypted Virtualization support */
+   features = kvm_find_cpuid_entry(vcpu, KVM_CPUID_FEATURES, 0);
+   if (!features)
+   return;
+
+   sev_info = kvm_find_cpuid_entry(vcpu, 0x801f, 0);
+   if (!sev_info)
+   return;
+
+   if (ca->nested_ctl & SVM_NESTED_CTL_SEV_ENABLE) {
+   features->eax |= (1 << KVM_FEATURE_SEV);
+   cpuid(0x801f, _info->eax, _info->ebx,
+ _info->ecx, _info->edx);
+   }
+
if (!kvm_vcpu_apicv_active(vcpu))
return;

[RFC PATCH v2 13/32] KVM: SVM: Enable SEV by setting the SEV_ENABLE CPU feature

2017-03-02 Thread Brijesh Singh

From: Tom Lendacky 

Modify the SVM cpuid update function to indicate if Secure Encrypted
Virtualization (SEV) is active in the guest by setting the SEV KVM CPU
features bit. SEV is active if Secure Memory Encryption is enabled in
the host and the SEV_ENABLE bit of the VMCB is set.

Signed-off-by: Tom Lendacky 
---
 arch/x86/kvm/cpuid.c |4 +++-
 arch/x86/kvm/svm.c   |   18 ++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 1639de8..e0c40a8 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -601,7 +601,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
entry->edx = 0;
break;
case 0x8000:
-   entry->eax = min(entry->eax, 0x801a);
+   entry->eax = min(entry->eax, 0x801f);
break;
case 0x8001:
entry->edx &= kvm_cpuid_8000_0001_edx_x86_features;
@@ -634,6 +634,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
break;
case 0x801d:
break;
+   case 0x801f:
+   break;
/*Add support for Centaur's CPUID instruction*/
case 0xC000:
/*Just support up to 0xC004 now*/
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 75b0645..36d61ff 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -46,6 +46,7 @@
 #include 
 
 #include 
+#include 
 #include "trace.h"
 
 #define __ex(x) __kvm_handle_fault_on_reboot(x)
@@ -5005,10 +5006,27 @@ static void svm_cpuid_update(struct kvm_vcpu *vcpu)
 {
struct vcpu_svm *svm = to_svm(vcpu);
struct kvm_cpuid_entry2 *entry;
+   struct vmcb_control_area *ca = >vmcb->control;
+   struct kvm_cpuid_entry2 *features, *sev_info;
 
/* Update nrips enabled cache */
svm->nrips_enabled = !!guest_cpuid_has_nrips(>vcpu);
 
+   /* Check for Secure Encrypted Virtualization support */
+   features = kvm_find_cpuid_entry(vcpu, KVM_CPUID_FEATURES, 0);
+   if (!features)
+   return;
+
+   sev_info = kvm_find_cpuid_entry(vcpu, 0x801f, 0);
+   if (!sev_info)
+   return;
+
+   if (ca->nested_ctl & SVM_NESTED_CTL_SEV_ENABLE) {
+   features->eax |= (1 << KVM_FEATURE_SEV);
+   cpuid(0x801f, _info->eax, _info->ebx,
+ _info->ecx, _info->edx);
+   }
+
if (!kvm_vcpu_apicv_active(vcpu))
return;

[RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

2017-03-02 Thread Brijesh Singh

From: Tom Lendacky 

Early in the boot process, add checks to determine if the kernel is
running with Secure Encrypted Virtualization (SEV) active by issuing
a CPUID instruction.

During early compressed kernel booting, if SEV is active the pagetables are
updated so that data is accessed and decompressed with encryption.

During uncompressed kernel booting, if SEV is the memory encryption mask is
set and a flag is set to indicate that SEV is enabled.

Signed-off-by: Tom Lendacky 
---
 arch/x86/boot/compressed/Makefile  |2 +
 arch/x86/boot/compressed/head_64.S |   16 +++
 arch/x86/boot/compressed/mem_encrypt.S |   75 
 arch/x86/include/uapi/asm/hyperv.h |4 ++
 arch/x86/include/uapi/asm/kvm_para.h   |3 +
 arch/x86/kernel/mem_encrypt_init.c |   24 ++
 6 files changed, 124 insertions(+)
 create mode 100644 arch/x86/boot/compressed/mem_encrypt.S

diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 44163e8..51f9cd0 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -72,6 +72,8 @@ vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/head_$(BITS).o 
$(obj)/misc.o \
$(obj)/string.o $(obj)/cmdline.o $(obj)/error.o \
$(obj)/piggy.o $(obj)/cpuflags.o
 
+vmlinux-objs-$(CONFIG_X86_64) += $(obj)/mem_encrypt.o
+
 vmlinux-objs-$(CONFIG_EARLY_PRINTK) += $(obj)/early_serial_console.o
 vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/kaslr.o
 ifdef CONFIG_X86_64
diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index d2ae1f8..625b5380 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -130,6 +130,19 @@ ENTRY(startup_32)
  /*
   * Build early 4G boot pagetable
   */
+   /*
+* If SEV is active set the encryption mask in the page tables. This
+* will insure that when the kernel is copied and decompressed it
+* will be done so encrypted.
+*/
+   callsev_enabled
+   xorl%edx, %edx
+   testl   %eax, %eax
+   jz  1f
+   subl$32, %eax   /* Encryption bit is always above bit 31 */
+   bts %eax, %edx  /* Set encryption mask for page tables */
+1:
+
/* Initialize Page tables to 0 */
lealpgtable(%ebx), %edi
xorl%eax, %eax
@@ -140,12 +153,14 @@ ENTRY(startup_32)
lealpgtable + 0(%ebx), %edi
leal0x1007 (%edi), %eax
movl%eax, 0(%edi)
+   addl%edx, 4(%edi)
 
/* Build Level 3 */
lealpgtable + 0x1000(%ebx), %edi
leal0x1007(%edi), %eax
movl$4, %ecx
 1: movl%eax, 0x00(%edi)
+   addl%edx, 0x04(%edi)
addl$0x1000, %eax
addl$8, %edi
decl%ecx
@@ -156,6 +171,7 @@ ENTRY(startup_32)
movl$0x0183, %eax
movl$2048, %ecx
 1: movl%eax, 0(%edi)
+   addl%edx, 4(%edi)
addl$0x0020, %eax
addl$8, %edi
decl%ecx
diff --git a/arch/x86/boot/compressed/mem_encrypt.S 
b/arch/x86/boot/compressed/mem_encrypt.S
new file mode 100644
index 000..8313c31
--- /dev/null
+++ b/arch/x86/boot/compressed/mem_encrypt.S
@@ -0,0 +1,75 @@
+/*
+ * AMD Memory Encryption Support
+ *
+ * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ *
+ * Author: Tom Lendacky 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+   .text
+   .code32
+ENTRY(sev_enabled)
+   xor %eax, %eax
+
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+   push%ebx
+   push%ecx
+   push%edx
+
+   /* Check if running under a hypervisor */
+   movl$0x4000, %eax
+   cpuid
+   cmpl$0x4001, %eax
+   jb  .Lno_sev
+
+   movl$0x4001, %eax
+   cpuid
+   bt  $KVM_FEATURE_SEV, %eax
+   jnc .Lno_sev
+
+   /*
+* Check for memory encryption feature:
+*   CPUID Fn8000_001F[EAX] - Bit 0
+*/
+   movl$0x801f, %eax
+   cpuid
+   bt  $0, %eax
+   jnc .Lno_sev
+
+   /*
+* Get memory encryption information:
+*   CPUID Fn8000_001F[EBX] - Bits 5:0
+* Pagetable bit position used to indicate encryption
+*/
+   movl%ebx, %eax
+   andl$0x3f, %eax
+   movl%eax, sev_enc_bit(%ebp)
+   jmp .Lsev_exit
+
+.Lno_sev:
+   xor %eax, %eax
+
+.Lsev_exit:
+   pop %edx
+   pop %ecx
+   pop %ebx
+
+#endif /* CONFIG_AMD_MEM_ENCRYPT */
+
+   ret
+ENDPROC(sev_enabled)
+
+   .bss
+sev_enc_bit:
+   .word   0
diff --git

[RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

2017-03-02 Thread Brijesh Singh

From: Tom Lendacky 

Early in the boot process, add checks to determine if the kernel is
running with Secure Encrypted Virtualization (SEV) active by issuing
a CPUID instruction.

During early compressed kernel booting, if SEV is active the pagetables are
updated so that data is accessed and decompressed with encryption.

During uncompressed kernel booting, if SEV is the memory encryption mask is
set and a flag is set to indicate that SEV is enabled.

Signed-off-by: Tom Lendacky 
---
 arch/x86/boot/compressed/Makefile  |2 +
 arch/x86/boot/compressed/head_64.S |   16 +++
 arch/x86/boot/compressed/mem_encrypt.S |   75 
 arch/x86/include/uapi/asm/hyperv.h |4 ++
 arch/x86/include/uapi/asm/kvm_para.h   |3 +
 arch/x86/kernel/mem_encrypt_init.c |   24 ++
 6 files changed, 124 insertions(+)
 create mode 100644 arch/x86/boot/compressed/mem_encrypt.S

diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 44163e8..51f9cd0 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -72,6 +72,8 @@ vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/head_$(BITS).o 
$(obj)/misc.o \
$(obj)/string.o $(obj)/cmdline.o $(obj)/error.o \
$(obj)/piggy.o $(obj)/cpuflags.o
 
+vmlinux-objs-$(CONFIG_X86_64) += $(obj)/mem_encrypt.o
+
 vmlinux-objs-$(CONFIG_EARLY_PRINTK) += $(obj)/early_serial_console.o
 vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/kaslr.o
 ifdef CONFIG_X86_64
diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index d2ae1f8..625b5380 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -130,6 +130,19 @@ ENTRY(startup_32)
  /*
   * Build early 4G boot pagetable
   */
+   /*
+* If SEV is active set the encryption mask in the page tables. This
+* will insure that when the kernel is copied and decompressed it
+* will be done so encrypted.
+*/
+   callsev_enabled
+   xorl%edx, %edx
+   testl   %eax, %eax
+   jz  1f
+   subl$32, %eax   /* Encryption bit is always above bit 31 */
+   bts %eax, %edx  /* Set encryption mask for page tables */
+1:
+
/* Initialize Page tables to 0 */
lealpgtable(%ebx), %edi
xorl%eax, %eax
@@ -140,12 +153,14 @@ ENTRY(startup_32)
lealpgtable + 0(%ebx), %edi
leal0x1007 (%edi), %eax
movl%eax, 0(%edi)
+   addl%edx, 4(%edi)
 
/* Build Level 3 */
lealpgtable + 0x1000(%ebx), %edi
leal0x1007(%edi), %eax
movl$4, %ecx
 1: movl%eax, 0x00(%edi)
+   addl%edx, 0x04(%edi)
addl$0x1000, %eax
addl$8, %edi
decl%ecx
@@ -156,6 +171,7 @@ ENTRY(startup_32)
movl$0x0183, %eax
movl$2048, %ecx
 1: movl%eax, 0(%edi)
+   addl%edx, 4(%edi)
addl$0x0020, %eax
addl$8, %edi
decl%ecx
diff --git a/arch/x86/boot/compressed/mem_encrypt.S 
b/arch/x86/boot/compressed/mem_encrypt.S
new file mode 100644
index 000..8313c31
--- /dev/null
+++ b/arch/x86/boot/compressed/mem_encrypt.S
@@ -0,0 +1,75 @@
+/*
+ * AMD Memory Encryption Support
+ *
+ * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ *
+ * Author: Tom Lendacky 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+   .text
+   .code32
+ENTRY(sev_enabled)
+   xor %eax, %eax
+
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+   push%ebx
+   push%ecx
+   push%edx
+
+   /* Check if running under a hypervisor */
+   movl$0x4000, %eax
+   cpuid
+   cmpl$0x4001, %eax
+   jb  .Lno_sev
+
+   movl$0x4001, %eax
+   cpuid
+   bt  $KVM_FEATURE_SEV, %eax
+   jnc .Lno_sev
+
+   /*
+* Check for memory encryption feature:
+*   CPUID Fn8000_001F[EAX] - Bit 0
+*/
+   movl$0x801f, %eax
+   cpuid
+   bt  $0, %eax
+   jnc .Lno_sev
+
+   /*
+* Get memory encryption information:
+*   CPUID Fn8000_001F[EBX] - Bits 5:0
+* Pagetable bit position used to indicate encryption
+*/
+   movl%ebx, %eax
+   andl$0x3f, %eax
+   movl%eax, sev_enc_bit(%ebp)
+   jmp .Lsev_exit
+
+.Lno_sev:
+   xor %eax, %eax
+
+.Lsev_exit:
+   pop %edx
+   pop %ecx
+   pop %ebx
+
+#endif /* CONFIG_AMD_MEM_ENCRYPT */
+
+   ret
+ENDPROC(sev_enabled)
+
+   .bss
+sev_enc_bit:
+   .word   0
diff --git a/arch/x86/include/uapi/asm/hyperv.h 
b/arch/x86/include/uapi/asm/hyperv.h
index 9b1a918..8278161 100644

Re: rxrpc: Fix deadlock between call creation and sendmsg/recvmsg

2017-03-02 Thread David Howells

Colin Ian King  wrote:

> I think the following part of the patch is problematic:
> 
> call = rxrpc_find_call_by_user_ID(rx, user_call_ID);
> if (!call) {
> +   ret = -EBADSLT;
> if (cmd != RXRPC_CMD_SEND_DATA)
> -   return -EBADSLT;
> +   goto error_release_sock;
> +   ret = -EBUSY;
> 
> At this point call is null, so the following code is performing a null
> pointer dereference on call when accessing call->state.
> 
> Detected by CoverityScan CID#1414316 ("Dereference after null check")
> 
> +   if (call->state == RXRPC_CALL_UNINITIALISED ||
> +   call->state == RXRPC_CALL_CLIENT_AWAIT_CONN ||
> +   call->state == RXRPC_CALL_SERVER_PREALLOC ||
> +   call->state == RXRPC_CALL_SERVER_SECURING ||
> +   call->state == RXRPC_CALL_SERVER_ACCEPTING)
> +   goto error_release_sock;
> call = rxrpc_new_client_call_for_sendmsg(rx, msg,
> user_call_ID,

Good catch, thanks,  I put the state check in the wrong half of the
if-statement.

David

[PATCH 21/26] drm/bridge: ps8622: reduce stack size for KASAN

2017-03-02 Thread Arnd Bergmann

When CONFIG_KASAN is set, each call to ps8622_set() adds an object to the
stack frame, leading to a warning about possible stack overflow:

drivers/gpu/drm/bridge/parade-ps8622.c: In function 'ps8622_send_config':
drivers/gpu/drm/bridge/parade-ps8622.c:338:1: error: the frame size of 5872 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

Marking this as noinline_for_kasan completely avoids the problem.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c 
b/drivers/gpu/drm/bridge/parade-ps8622.c
index ac8cc5b50d9f..6b995edd2a46 100644
--- a/drivers/gpu/drm/bridge/parade-ps8622.c
+++ b/drivers/gpu/drm/bridge/parade-ps8622.c
@@ -79,7 +79,7 @@ static inline struct ps8622_bridge *
return container_of(connector, struct ps8622_bridge, connector);
 }
 
-static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
+static noinline_for_kasan int ps8622_set(struct i2c_client *client, u8 page, 
u8 reg, u8 val)
 {
int ret;
struct i2c_adapter *adap = client->adapter;
-- 
2.9.0

Re: rxrpc: Fix deadlock between call creation and sendmsg/recvmsg

2017-03-02 Thread David Howells

Colin Ian King  wrote:

> I think the following part of the patch is problematic:
> 
> call = rxrpc_find_call_by_user_ID(rx, user_call_ID);
> if (!call) {
> +   ret = -EBADSLT;
> if (cmd != RXRPC_CMD_SEND_DATA)
> -   return -EBADSLT;
> +   goto error_release_sock;
> +   ret = -EBUSY;
> 
> At this point call is null, so the following code is performing a null
> pointer dereference on call when accessing call->state.
> 
> Detected by CoverityScan CID#1414316 ("Dereference after null check")
> 
> +   if (call->state == RXRPC_CALL_UNINITIALISED ||
> +   call->state == RXRPC_CALL_CLIENT_AWAIT_CONN ||
> +   call->state == RXRPC_CALL_SERVER_PREALLOC ||
> +   call->state == RXRPC_CALL_SERVER_SECURING ||
> +   call->state == RXRPC_CALL_SERVER_ACCEPTING)
> +   goto error_release_sock;
> call = rxrpc_new_client_call_for_sendmsg(rx, msg,
> user_call_ID,

Good catch, thanks,  I put the state check in the wrong half of the
if-statement.

David

[PATCH 21/26] drm/bridge: ps8622: reduce stack size for KASAN

2017-03-02 Thread Arnd Bergmann

When CONFIG_KASAN is set, each call to ps8622_set() adds an object to the
stack frame, leading to a warning about possible stack overflow:

drivers/gpu/drm/bridge/parade-ps8622.c: In function 'ps8622_send_config':
drivers/gpu/drm/bridge/parade-ps8622.c:338:1: error: the frame size of 5872 
bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

Marking this as noinline_for_kasan completely avoids the problem.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c 
b/drivers/gpu/drm/bridge/parade-ps8622.c
index ac8cc5b50d9f..6b995edd2a46 100644
--- a/drivers/gpu/drm/bridge/parade-ps8622.c
+++ b/drivers/gpu/drm/bridge/parade-ps8622.c
@@ -79,7 +79,7 @@ static inline struct ps8622_bridge *
return container_of(connector, struct ps8622_bridge, connector);
 }
 
-static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
+static noinline_for_kasan int ps8622_set(struct i2c_client *client, u8 page, 
u8 reg, u8 val)
 {
int ret;
struct i2c_adapter *adap = client->adapter;
-- 
2.9.0

[PATCH 17/26] [media] i2c: ks0127: reduce stack frame size for KASAN

2017-03-02 Thread Arnd Bergmann

When CONFIG_KASAN is set, inlining of functions with local variables
causes excessive stack usage:

drivers/media/i2c/ks0127.c: In function 'ks0127_s_routing':
drivers/media/i2c/ks0127.c:541:1: error: the frame size of 3136 bytes is larger 
than 2048 bytes [-Werror=frame-larger-than=]

Marking one functions as noinline_for_kasan solves the problem in this
driver.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/i2c/ks0127.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ks0127.c b/drivers/media/i2c/ks0127.c
index ab536c4a7115..eb2fccdc0602 100644
--- a/drivers/media/i2c/ks0127.c
+++ b/drivers/media/i2c/ks0127.c
@@ -349,7 +349,7 @@ static void ks0127_write(struct v4l2_subdev *sd, u8 reg, u8 
val)
 
 
 /* generic bit-twiddling */
-static void ks0127_and_or(struct v4l2_subdev *sd, u8 reg, u8 and_v, u8 or_v)
+static noinline_for_kasan void ks0127_and_or(struct v4l2_subdev *sd, u8 reg, 
u8 and_v, u8 or_v)
 {
struct ks0127 *ks = to_ks0127(sd);
 
-- 
2.9.0

[PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan

2017-03-02 Thread Arnd Bergmann

When CONFIG_KASAN is enabled, we have several functions that use rather
large kernel stacks, e.g.

drivers/isdn/hardware/eicon/message.c: In function 'group_optimization':
drivers/isdn/hardware/eicon/message.c:14841:1: warning: the frame size of 864 
bytes is larger than 500 bytes [-Wframe-larger-than=]
drivers/isdn/hardware/eicon/message.c: In function 'add_b1':
drivers/isdn/hardware/eicon/message.c:7925:1: warning: the frame size of 1008 
bytes is larger than 500 bytes [-Wframe-larger-than=]
drivers/isdn/hardware/eicon/message.c: In function 'add_b23':
drivers/isdn/hardware/eicon/message.c:8551:1: warning: the frame size of 928 
bytes is larger than 500 bytes [-Wframe-larger-than=]
drivers/isdn/hardware/eicon/message.c: In function 'sig_ind':
drivers/isdn/hardware/eicon/message.c:6113:1: warning: the frame size of 2112 
bytes is larger than 500 bytes [-Wframe-larger-than=]

To be on the safe side, and to enable a lower frame size warning limit, let's
just mark this driver as broken when KASAN is in use. I have tried to reduce
the stack size as I did with dozens of other drivers, but failed to come up
with a good solution for this one.

Signed-off-by: Arnd Bergmann 
---
 drivers/isdn/hardware/eicon/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/isdn/hardware/eicon/Kconfig 
b/drivers/isdn/hardware/eicon/Kconfig
index 6082b6a5ced3..b64496062421 100644
--- a/drivers/isdn/hardware/eicon/Kconfig
+++ b/drivers/isdn/hardware/eicon/Kconfig
@@ -31,6 +31,7 @@ config ISDN_DIVAS_PRIPCI
 
 config ISDN_DIVAS_DIVACAPI
tristate "DIVA CAPI2.0 interface support"
+   depends on !KASAN || BROKEN
help
  You need this to provide the CAPI interface
  for DIVA Server cards.
-- 
2.9.0

[PATCH 17/26] [media] i2c: ks0127: reduce stack frame size for KASAN

2017-03-02 Thread Arnd Bergmann

When CONFIG_KASAN is set, inlining of functions with local variables
causes excessive stack usage:

drivers/media/i2c/ks0127.c: In function 'ks0127_s_routing':
drivers/media/i2c/ks0127.c:541:1: error: the frame size of 3136 bytes is larger 
than 2048 bytes [-Werror=frame-larger-than=]

Marking one functions as noinline_for_kasan solves the problem in this
driver.

Signed-off-by: Arnd Bergmann 
---
 drivers/media/i2c/ks0127.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ks0127.c b/drivers/media/i2c/ks0127.c
index ab536c4a7115..eb2fccdc0602 100644
--- a/drivers/media/i2c/ks0127.c
+++ b/drivers/media/i2c/ks0127.c
@@ -349,7 +349,7 @@ static void ks0127_write(struct v4l2_subdev *sd, u8 reg, u8 
val)
 
 
 /* generic bit-twiddling */
-static void ks0127_and_or(struct v4l2_subdev *sd, u8 reg, u8 and_v, u8 or_v)
+static noinline_for_kasan void ks0127_and_or(struct v4l2_subdev *sd, u8 reg, 
u8 and_v, u8 or_v)
 {
struct ks0127 *ks = to_ks0127(sd);
 
-- 
2.9.0

[PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan

2017-03-02 Thread Arnd Bergmann

When CONFIG_KASAN is enabled, we have several functions that use rather
large kernel stacks, e.g.

drivers/isdn/hardware/eicon/message.c: In function 'group_optimization':
drivers/isdn/hardware/eicon/message.c:14841:1: warning: the frame size of 864 
bytes is larger than 500 bytes [-Wframe-larger-than=]
drivers/isdn/hardware/eicon/message.c: In function 'add_b1':
drivers/isdn/hardware/eicon/message.c:7925:1: warning: the frame size of 1008 
bytes is larger than 500 bytes [-Wframe-larger-than=]
drivers/isdn/hardware/eicon/message.c: In function 'add_b23':
drivers/isdn/hardware/eicon/message.c:8551:1: warning: the frame size of 928 
bytes is larger than 500 bytes [-Wframe-larger-than=]
drivers/isdn/hardware/eicon/message.c: In function 'sig_ind':
drivers/isdn/hardware/eicon/message.c:6113:1: warning: the frame size of 2112 
bytes is larger than 500 bytes [-Wframe-larger-than=]

To be on the safe side, and to enable a lower frame size warning limit, let's
just mark this driver as broken when KASAN is in use. I have tried to reduce
the stack size as I did with dozens of other drivers, but failed to come up
with a good solution for this one.

Signed-off-by: Arnd Bergmann 
---
 drivers/isdn/hardware/eicon/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/isdn/hardware/eicon/Kconfig 
b/drivers/isdn/hardware/eicon/Kconfig
index 6082b6a5ced3..b64496062421 100644
--- a/drivers/isdn/hardware/eicon/Kconfig
+++ b/drivers/isdn/hardware/eicon/Kconfig
@@ -31,6 +31,7 @@ config ISDN_DIVAS_PRIPCI
 
 config ISDN_DIVAS_DIVACAPI
tristate "DIVA CAPI2.0 interface support"
+   depends on !KASAN || BROKEN
help
  You need this to provide the CAPI interface
  for DIVA Server cards.
-- 
2.9.0

[PATCH] Staging:wilc1000:wilc_sdio: Modified comment style to preferred kernel comment style

2017-03-02 Thread Georgios Emmanouil

Modified comment style to preferred kernel comment style.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/wilc_sdio.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index cd6b8ba..ad4eb0f 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -1,11 +1,8 @@
-/* // 
*/
-/*  */
-/* Copyright (c) Atmel Corporation.  All rights reserved. */
-/*  */
-/* Module Name:  wilc_sdio.c */
-/*  */
-/*  */
-/* 
 */
+/*
+ * Copyright (c) Atmel Corporation.  All rights reserved.
+ *
+ * Module Name:  wilc_sdio.c
+ */

 #include 
 #include "wilc_wlan_if.h"
--
2.1.4

[PATCH] Staging:wilc1000:wilc_sdio: Modified comment style to preferred kernel comment style

2017-03-02 Thread Georgios Emmanouil

Modified comment style to preferred kernel comment style.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/wilc_sdio.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index cd6b8ba..ad4eb0f 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -1,11 +1,8 @@
-/* // 
*/
-/*  */
-/* Copyright (c) Atmel Corporation.  All rights reserved. */
-/*  */
-/* Module Name:  wilc_sdio.c */
-/*  */
-/*  */
-/* 
 */
+/*
+ * Copyright (c) Atmel Corporation.  All rights reserved.
+ *
+ * Module Name:  wilc_sdio.c
+ */

 #include 
 #include "wilc_wlan_if.h"
--
2.1.4

[PATCH] clk: tegra: fix disable unused for clocks sharing enable bit

2017-03-02 Thread Peter De Schrijver

In case 2 clocks share an enable bit and one of them is enabled by a driver
and the other one is not, CCF will think it's enabled because it will only
look at the hw state. Therefor it will disable the clock and thus also
disable the other clock which was enabled. Solve this by reading the
initial state of the enable bit and incrementing the refcount if it's set.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-periph-gate.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/tegra/clk-periph-gate.c 
b/drivers/clk/tegra/clk-periph-gate.c
index 8812782..303ef32 100644
--- a/drivers/clk/tegra/clk-periph-gate.c
+++ b/drivers/clk/tegra/clk-periph-gate.c
@@ -159,6 +159,9 @@ struct clk *tegra_clk_register_periph_gate(const char *name,
gate->enable_refcnt = enable_refcnt;
gate->regs = pregs;
 
+   if (read_enb(gate) & periph_clk_to_bit(gate))
+   enable_refcnt[clk_num]++;
+
/* Data in .init is copied by clk_register(), so stack variable OK */
gate->hw.init = 
 
-- 
1.9.1

[PATCH] clk: tegra: fix disable unused for clocks sharing enable bit

2017-03-02 Thread Peter De Schrijver

In case 2 clocks share an enable bit and one of them is enabled by a driver
and the other one is not, CCF will think it's enabled because it will only
look at the hw state. Therefor it will disable the clock and thus also
disable the other clock which was enabled. Solve this by reading the
initial state of the enable bit and incrementing the refcount if it's set.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-periph-gate.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/tegra/clk-periph-gate.c 
b/drivers/clk/tegra/clk-periph-gate.c
index 8812782..303ef32 100644
--- a/drivers/clk/tegra/clk-periph-gate.c
+++ b/drivers/clk/tegra/clk-periph-gate.c
@@ -159,6 +159,9 @@ struct clk *tegra_clk_register_periph_gate(const char *name,
gate->enable_refcnt = enable_refcnt;
gate->regs = pregs;
 
+   if (read_enb(gate) & periph_clk_to_bit(gate))
+   enable_refcnt[clk_num]++;
+
/* Data in .init is copied by clk_register(), so stack variable OK */
gate->hw.init = 
 
-- 
1.9.1

Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

2017-03-02 Thread Cyrille Pitchen

Le 02/03/2017 à 15:29, Boris Brezillon a écrit :
> On Thu, 2 Mar 2017 19:24:43 +0530
> Vignesh R  wrote:
> 
>> 
> Not really, I am debugging another issue with UBIFS on DRA74 EVM (ARM
> cortex-a15) wherein pages allocated by vmalloc are in highmem region
> that are not addressable using 32 bit addresses and is backed by LPAE.
> So, a 32 bit DMA cannot access these buffers at all.
> When dma_map_sg() is called to map these pages by spi_map_buf() the
> physical address is just truncated to 32 bit in pfn_to_dma() (as part of
> dma_map_sg() call). This results in random crashes as DMA starts
> accessing random memory during SPI read.
>
> IMO, there may be more undiscovered caveat with using dma_map_sg() for
> non kmalloc'd buffers and its better that spi-nor starts handling these
> buffers instead of relying on spi_map_msg() and working around every
> time something pops up.
>  
 Ok, I had a closer look at the SPI framework, and it seems there's a
 way to tell to the core that a specific transfer cannot use DMA
 (->can_dam()). The first thing you should do is fix the spi-davinci
 driver:

 1/ implement ->can_dma()
 2/ patch davinci_spi_bufs() to take the decision to do DMA or not on a
per-xfer basis and not on a per-device basis
  
>>
>> This would lead to poor perf defeating entire purpose of using DMA.
> 
> Hm, that's not really true. For all cases where you have a DMA-able
> buffer it would still use DMA. For other cases (like the UBI+SPI-NOR
> case we're talking about here), yes, it will be slower, but slower is
> still better than buggy.
> So, in any case, I think the fixes pointed by Frode are needed.
> 
>>
 Then we can start thinking about how to improve perfs by using a bounce
 buffer for large transfers, but I'm still not sure this should be done
 at the MTD level...  
>>
>> If its at SPI level, then I guess each individual drivers which cannot
>> handle vmalloc'd buffers will have to implement bounce buffer logic.
> 
> Well, that's my opinion. The only one that can decide when to do
> PIO, when to use DMA or when to use a bounce buffer+DMA is the SPI
> controller.
> If you move this logic to the SPI NOR layer, you'll have to guess what
> is the best approach, and I fear the decision will be wrong on some
> platforms (leading to perf degradation).
>

True. For instance, Atmel SAMA5* SoCs don't need this bounce buffer
since their L1 data cache uses a PIPT scheme.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0433c/CHDFAHBD.html

"""
2.1.4. Data side memory system

Data Cache Unit

The Data Cache Unit (DCU) consists of the following sub-blocks:

The Level 1 (L1) data cache controller, which generates the control
signals for the associated embedded tag, data, and dirty memory (RAMs)
and arbitrates between the different sources requesting access to the
memory resources. The data cache is 4-way set associative and uses a
Physically Indexed Physically Tagged (PIPT) scheme for lookup which
enables unambiguous address management in the system.
"""

So for those SoCs, spi_map_msg() should be safe to handle vmalloc'ed
buffers since they don't have to worry about the cache aliases issue or
address truncation.

That's why I don't think setting the SNOR_F_USE_BOUNCE_BUFFER in *all*
cases in m25p80 is the right solution since it would not fair to degrade
the performances of some devices when it's not needed hence not justified.

I still agree with the idea of patch 1 but about patch 2, if m25p80
users want to take advantage of this new spi-nor bounce buffer, we have
to agree on a reliable mechanism that clearly tells whether or not the
SNOR_F_USE_BOUNCE_BUFFER is to be set from m25p80.


> You're mentioning code duplication in each SPI controller, I agree,
> this is far from ideal, but what you're suggesting is not necessarily
> better. What if another SPI user starts passing vmalloc-ed buffers to
> the SPI controller? You'll have to duplicate the bounce-buffer logic in
> this user as well.
> 
>>
>> Or SPI core can be extended in a way similar to this RFC. That is, SPI
>> master driver will set a flag to request SPI core to use of bounce
>> buffer for vmalloc'd buffers. And spi_map_buf() just uses bounce buffer
>> in case buf does not belong to kmalloc region based on the flag.
> 
> That's a better approach IMHO. Note that the decision should not only
> be based on the buffer type, but also on the transfer length and/or
> whether the controller supports transferring non physically contiguous
> buffers.
> 
> Maybe we should just extend ->can_dma() to let the core know if it
> should use a bounce buffer.
> 
> Regarding the bounce buffer allocation logic, I'm not sure how it
> should be done. The SPI user should be able to determine a max transfer
> len (at least this is the case for SPI NORs) and inform the SPI layer
> about this boundary so that the SPI core can

Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

2017-03-02 Thread Cyrille Pitchen

Le 02/03/2017 à 15:29, Boris Brezillon a écrit :
> On Thu, 2 Mar 2017 19:24:43 +0530
> Vignesh R  wrote:
> 
>> 
> Not really, I am debugging another issue with UBIFS on DRA74 EVM (ARM
> cortex-a15) wherein pages allocated by vmalloc are in highmem region
> that are not addressable using 32 bit addresses and is backed by LPAE.
> So, a 32 bit DMA cannot access these buffers at all.
> When dma_map_sg() is called to map these pages by spi_map_buf() the
> physical address is just truncated to 32 bit in pfn_to_dma() (as part of
> dma_map_sg() call). This results in random crashes as DMA starts
> accessing random memory during SPI read.
>
> IMO, there may be more undiscovered caveat with using dma_map_sg() for
> non kmalloc'd buffers and its better that spi-nor starts handling these
> buffers instead of relying on spi_map_msg() and working around every
> time something pops up.
>  
 Ok, I had a closer look at the SPI framework, and it seems there's a
 way to tell to the core that a specific transfer cannot use DMA
 (->can_dam()). The first thing you should do is fix the spi-davinci
 driver:

 1/ implement ->can_dma()
 2/ patch davinci_spi_bufs() to take the decision to do DMA or not on a
per-xfer basis and not on a per-device basis
  
>>
>> This would lead to poor perf defeating entire purpose of using DMA.
> 
> Hm, that's not really true. For all cases where you have a DMA-able
> buffer it would still use DMA. For other cases (like the UBI+SPI-NOR
> case we're talking about here), yes, it will be slower, but slower is
> still better than buggy.
> So, in any case, I think the fixes pointed by Frode are needed.
> 
>>
 Then we can start thinking about how to improve perfs by using a bounce
 buffer for large transfers, but I'm still not sure this should be done
 at the MTD level...  
>>
>> If its at SPI level, then I guess each individual drivers which cannot
>> handle vmalloc'd buffers will have to implement bounce buffer logic.
> 
> Well, that's my opinion. The only one that can decide when to do
> PIO, when to use DMA or when to use a bounce buffer+DMA is the SPI
> controller.
> If you move this logic to the SPI NOR layer, you'll have to guess what
> is the best approach, and I fear the decision will be wrong on some
> platforms (leading to perf degradation).
>

True. For instance, Atmel SAMA5* SoCs don't need this bounce buffer
since their L1 data cache uses a PIPT scheme.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0433c/CHDFAHBD.html

"""
2.1.4. Data side memory system

Data Cache Unit

The Data Cache Unit (DCU) consists of the following sub-blocks:

The Level 1 (L1) data cache controller, which generates the control
signals for the associated embedded tag, data, and dirty memory (RAMs)
and arbitrates between the different sources requesting access to the
memory resources. The data cache is 4-way set associative and uses a
Physically Indexed Physically Tagged (PIPT) scheme for lookup which
enables unambiguous address management in the system.
"""

So for those SoCs, spi_map_msg() should be safe to handle vmalloc'ed
buffers since they don't have to worry about the cache aliases issue or
address truncation.

That's why I don't think setting the SNOR_F_USE_BOUNCE_BUFFER in *all*
cases in m25p80 is the right solution since it would not fair to degrade
the performances of some devices when it's not needed hence not justified.

I still agree with the idea of patch 1 but about patch 2, if m25p80
users want to take advantage of this new spi-nor bounce buffer, we have
to agree on a reliable mechanism that clearly tells whether or not the
SNOR_F_USE_BOUNCE_BUFFER is to be set from m25p80.


> You're mentioning code duplication in each SPI controller, I agree,
> this is far from ideal, but what you're suggesting is not necessarily
> better. What if another SPI user starts passing vmalloc-ed buffers to
> the SPI controller? You'll have to duplicate the bounce-buffer logic in
> this user as well.
> 
>>
>> Or SPI core can be extended in a way similar to this RFC. That is, SPI
>> master driver will set a flag to request SPI core to use of bounce
>> buffer for vmalloc'd buffers. And spi_map_buf() just uses bounce buffer
>> in case buf does not belong to kmalloc region based on the flag.
> 
> That's a better approach IMHO. Note that the decision should not only
> be based on the buffer type, but also on the transfer length and/or
> whether the controller supports transferring non physically contiguous
> buffers.
> 
> Maybe we should just extend ->can_dma() to let the core know if it
> should use a bounce buffer.
> 
> Regarding the bounce buffer allocation logic, I'm not sure how it
> should be done. The SPI user should be able to determine a max transfer
> len (at least this is the case for SPI NORs) and inform the SPI layer
> about this boundary so that the SPI core can allocate a bounce

[PATCH] clk: tegra: Implement reset control reset

2017-03-02 Thread Peter De Schrijver

From: Mikko Perttunen 

For completeness, also implement this reset framework API for Tegra.

Signed-off-by: Mikko Perttunen 
Reviewed-by: Peter De Schrijver 
Reviewed-by: Arto Merilainen 
---
 drivers/clk/tegra/clk.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
index b2cdd9a..ba923f0 100644
--- a/drivers/clk/tegra/clk.c
+++ b/drivers/clk/tegra/clk.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -182,6 +183,20 @@ static int tegra_clk_rst_deassert(struct 
reset_controller_dev *rcdev,
return -EINVAL;
 }
 
+static int tegra_clk_rst_reset(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   int err;
+
+   err = tegra_clk_rst_assert(rcdev, id);
+   if (err)
+   return err;
+
+   udelay(1);
+
+   return tegra_clk_rst_deassert(rcdev, id);
+}
+
 const struct tegra_clk_periph_regs *get_reg_bank(int clkid)
 {
int reg_bank = clkid / 32;
@@ -274,6 +289,7 @@ void __init tegra_init_from_table(struct 
tegra_clk_init_table *tbl,
 static const struct reset_control_ops rst_ops = {
.assert = tegra_clk_rst_assert,
.deassert = tegra_clk_rst_deassert,
+   .reset = tegra_clk_rst_reset,
 };
 
 static struct reset_controller_dev rst_ctlr = {
-- 
1.9.1

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

2017-03-02 Thread Darrick J. Wong

On Thu, Mar 02, 2017 at 05:16:06PM +0100, Michal Hocko wrote:
> I've just realized that Darrick was not on the CC list. Let's add him.
> I believe this patch should go in in the current cycle because
> 5d17a73a2ebe was merged in this merge window and it can be abused...
> 
> The other patch [1] is not that urgent.
> 
> [1] http://lkml.kernel.org/r/20170302154541.16155-2-mho...@kernel.org

Both patches look ok to me.  I'll take both patches for rc2.
Reviewed-by: Darrick J. Wong 

(Annoyingly I missed the whole thread yesterday due to vger slowness, in
case anyone was wondering why I didn't reply.)

--D

> 
> On Thu 02-03-17 16:45:40, Michal Hocko wrote:
> > From: Michal Hocko 
> > 
> > Even though kmem_zalloc_greedy is documented it might fail the current
> > code doesn't really implement this properly and loops on the smallest
> > allowed size for ever. This is a problem because vzalloc might fail
> > permanently - we might run out of vmalloc space or since 5d17a73a2ebe
> > ("vmalloc: back off when the current task is killed") when the current
> > task is killed. The later one makes the failure scenario much more
> > probable than it used to be because it makes vmalloc() failures
> > permanent for tasks with fatal signals pending.. Fix this by bailing out
> > if the minimum size request failed.
> > 
> > This has been noticed by a hung generic/269 xfstest by Xiong Zhou.
> > 
> > fsstress: vmalloc: allocation failure, allocated 12288 of 20480 bytes, 
> > mode:0x14080c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_ZERO), nodemask=(null)
> > fsstress cpuset=/ mems_allowed=0-1
> > CPU: 1 PID: 23460 Comm: fsstress Not tainted 4.10.0-master-45554b2+ #21
> > Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 
> > 10/05/2016
> > Call Trace:
> >  dump_stack+0x63/0x87
> >  warn_alloc+0x114/0x1c0
> >  ? alloc_pages_current+0x88/0x120
> >  __vmalloc_node_range+0x250/0x2a0
> >  ? kmem_zalloc_greedy+0x2b/0x40 [xfs]
> >  ? free_hot_cold_page+0x21f/0x280
> >  vzalloc+0x54/0x60
> >  ? kmem_zalloc_greedy+0x2b/0x40 [xfs]
> >  kmem_zalloc_greedy+0x2b/0x40 [xfs]
> >  xfs_bulkstat+0x11b/0x730 [xfs]
> >  ? xfs_bulkstat_one_int+0x340/0x340 [xfs]
> >  ? selinux_capable+0x20/0x30
> >  ? security_capable+0x48/0x60
> >  xfs_ioc_bulkstat+0xe4/0x190 [xfs]
> >  xfs_file_ioctl+0x9dd/0xad0 [xfs]
> >  ? do_filp_open+0xa5/0x100
> >  do_vfs_ioctl+0xa7/0x5e0
> >  SyS_ioctl+0x79/0x90
> >  do_syscall_64+0x67/0x180
> >  entry_SYSCALL64_slow_path+0x25/0x25
> > 
> > fsstress keeps looping inside kmem_zalloc_greedy without any way out
> > because vmalloc keeps failing due to fatal_signal_pending.
> > 
> > Reported-by: Xiong Zhou 
> > Analyzed-by: Tetsuo Handa 
> > Signed-off-by: Michal Hocko 
> > ---
> >  fs/xfs/kmem.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c
> > index 339c696bbc01..ee95f5c6db45 100644
> > --- a/fs/xfs/kmem.c
> > +++ b/fs/xfs/kmem.c
> > @@ -34,6 +34,8 @@ kmem_zalloc_greedy(size_t *size, size_t minsize, size_t 
> > maxsize)
> > size_t  kmsize = maxsize;
> >  
> > while (!(ptr = vzalloc(kmsize))) {
> > +   if (kmsize == minsize)
> > +   break;
> > if ((kmsize >>= 1) <= minsize)
> > kmsize = minsize;
> > }
> > -- 
> > 2.11.0
> > 
> 
> -- 
> Michal Hocko
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] clk: tegra: Implement reset control reset

2017-03-02 Thread Peter De Schrijver

From: Mikko Perttunen 

For completeness, also implement this reset framework API for Tegra.

Signed-off-by: Mikko Perttunen 
Reviewed-by: Peter De Schrijver 
Reviewed-by: Arto Merilainen 
---
 drivers/clk/tegra/clk.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
index b2cdd9a..ba923f0 100644
--- a/drivers/clk/tegra/clk.c
+++ b/drivers/clk/tegra/clk.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -182,6 +183,20 @@ static int tegra_clk_rst_deassert(struct 
reset_controller_dev *rcdev,
return -EINVAL;
 }
 
+static int tegra_clk_rst_reset(struct reset_controller_dev *rcdev,
+   unsigned long id)
+{
+   int err;
+
+   err = tegra_clk_rst_assert(rcdev, id);
+   if (err)
+   return err;
+
+   udelay(1);
+
+   return tegra_clk_rst_deassert(rcdev, id);
+}
+
 const struct tegra_clk_periph_regs *get_reg_bank(int clkid)
 {
int reg_bank = clkid / 32;
@@ -274,6 +289,7 @@ void __init tegra_init_from_table(struct 
tegra_clk_init_table *tbl,
 static const struct reset_control_ops rst_ops = {
.assert = tegra_clk_rst_assert,
.deassert = tegra_clk_rst_deassert,
+   .reset = tegra_clk_rst_reset,
 };
 
 static struct reset_controller_dev rst_ctlr = {
-- 
1.9.1

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

2017-03-02 Thread Darrick J. Wong

On Thu, Mar 02, 2017 at 05:16:06PM +0100, Michal Hocko wrote:
> I've just realized that Darrick was not on the CC list. Let's add him.
> I believe this patch should go in in the current cycle because
> 5d17a73a2ebe was merged in this merge window and it can be abused...
> 
> The other patch [1] is not that urgent.
> 
> [1] http://lkml.kernel.org/r/20170302154541.16155-2-mho...@kernel.org

Both patches look ok to me.  I'll take both patches for rc2.
Reviewed-by: Darrick J. Wong 

(Annoyingly I missed the whole thread yesterday due to vger slowness, in
case anyone was wondering why I didn't reply.)

--D

> 
> On Thu 02-03-17 16:45:40, Michal Hocko wrote:
> > From: Michal Hocko 
> > 
> > Even though kmem_zalloc_greedy is documented it might fail the current
> > code doesn't really implement this properly and loops on the smallest
> > allowed size for ever. This is a problem because vzalloc might fail
> > permanently - we might run out of vmalloc space or since 5d17a73a2ebe
> > ("vmalloc: back off when the current task is killed") when the current
> > task is killed. The later one makes the failure scenario much more
> > probable than it used to be because it makes vmalloc() failures
> > permanent for tasks with fatal signals pending.. Fix this by bailing out
> > if the minimum size request failed.
> > 
> > This has been noticed by a hung generic/269 xfstest by Xiong Zhou.
> > 
> > fsstress: vmalloc: allocation failure, allocated 12288 of 20480 bytes, 
> > mode:0x14080c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_ZERO), nodemask=(null)
> > fsstress cpuset=/ mems_allowed=0-1
> > CPU: 1 PID: 23460 Comm: fsstress Not tainted 4.10.0-master-45554b2+ #21
> > Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 
> > 10/05/2016
> > Call Trace:
> >  dump_stack+0x63/0x87
> >  warn_alloc+0x114/0x1c0
> >  ? alloc_pages_current+0x88/0x120
> >  __vmalloc_node_range+0x250/0x2a0
> >  ? kmem_zalloc_greedy+0x2b/0x40 [xfs]
> >  ? free_hot_cold_page+0x21f/0x280
> >  vzalloc+0x54/0x60
> >  ? kmem_zalloc_greedy+0x2b/0x40 [xfs]
> >  kmem_zalloc_greedy+0x2b/0x40 [xfs]
> >  xfs_bulkstat+0x11b/0x730 [xfs]
> >  ? xfs_bulkstat_one_int+0x340/0x340 [xfs]
> >  ? selinux_capable+0x20/0x30
> >  ? security_capable+0x48/0x60
> >  xfs_ioc_bulkstat+0xe4/0x190 [xfs]
> >  xfs_file_ioctl+0x9dd/0xad0 [xfs]
> >  ? do_filp_open+0xa5/0x100
> >  do_vfs_ioctl+0xa7/0x5e0
> >  SyS_ioctl+0x79/0x90
> >  do_syscall_64+0x67/0x180
> >  entry_SYSCALL64_slow_path+0x25/0x25
> > 
> > fsstress keeps looping inside kmem_zalloc_greedy without any way out
> > because vmalloc keeps failing due to fatal_signal_pending.
> > 
> > Reported-by: Xiong Zhou 
> > Analyzed-by: Tetsuo Handa 
> > Signed-off-by: Michal Hocko 
> > ---
> >  fs/xfs/kmem.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c
> > index 339c696bbc01..ee95f5c6db45 100644
> > --- a/fs/xfs/kmem.c
> > +++ b/fs/xfs/kmem.c
> > @@ -34,6 +34,8 @@ kmem_zalloc_greedy(size_t *size, size_t minsize, size_t 
> > maxsize)
> > size_t  kmsize = maxsize;
> >  
> > while (!(ptr = vzalloc(kmsize))) {
> > +   if (kmsize == minsize)
> > +   break;
> > if ((kmsize >>= 1) <= minsize)
> > kmsize = minsize;
> > }
> > -- 
> > 2.11.0
> > 
> 
> -- 
> Michal Hocko
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/11] drm/meson: Initial support for HDMI Output

2017-03-02 Thread Neil Armstrong

On 03/02/2017 04:58 PM, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 04:39:56PM +0100, Neil Armstrong wrote:
>> The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
>> in combination with a very custom PHY.
>>
>> This patchset depends on Laurent Pinchart v4 patchset at [1] and my v2
>> patchset at [2] to permit PHY control from outside the dw-hdmi driver.
>>
>> The Synopsys DesignWare HDMI TX Controller is integrated like :
>>  ___
>> |HDMI TOP   |<= HPD
>> |___|
>> |  ||
>> HDMI-TX-|  Synopsys HDMI   |   HDMI PHY |=> TMDS
>> |Controller||
>> |___|<=> DDC
>>
>> And uses the following paths for Pixels Encoding :
>>_   _   
>> vd1---| |-| | | VENC /-|VDAC
>> vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
>> osd1--| |-| | | \  | X--HDMI-TX
>> osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
>>   |  | |
>>   |  \--ENCL---|LVDS
>>   ||
>>
>> The ENCI and ENCP encoders pre-formats the data for the ENCI-DVI and
>> ENCP-DVI encoders. Those DVI encoders will format the pixels for the
>> Synopsys DesignWare HDMI TX Controller.
>>
>> In order to support display modes, the ENCI and ENCP encoders needs very
>> specific parameters for *each* display modes, so usage of the CEA VIC
>> identifier is necessary. But the DVI timings are generated from the
>> drm_mode structure in a generic way.
>>
>> To simplify the first push, only the main CEA modes are supported up to
>> 1920x1080p60. Supporting the 480i and 576i needs tweaking in the dw-hdmi
>> in order to support the Clock Doubling necessary for these modes.
>>
>> Support for more traditional modes like the EDID fallback modes is planned
>> but will need tome additionnal handling along the CEA modes.
>> Support for 4k2k modes needs to be able to get the EDID HDMI modes, but
>> for now only the HDMI 1.4 modes are currently available in the drm_edid
>> implementation.
> 
> Btw, with the neat ascii-art stuff here and in comments in your code, did
> you look into assembling all that into a meson driver documentation
> chapter like the one for vc4 that was just merged?
> -Daniel

Hi Daniel,

Yes, I was thinking about that, but was focused to have all the bits working and
in an upstream-able form.

I will certainly push one in the next few days since I already have a lot of 
text
ready in the comments.

Neil

> 
>>
>> This patchset does :
>>  - Fixes the CRTC handling
>>  - Fixes the registers definitions
>>  - Adds support for device components registration along of-graph
>>  - Adds support for HDMI clocks
>>  - Adds support for HDMI VENC video modes
>>  - Adds support for the Custom HDMI PHY using callbacks added in [1] and [2]
>>  - Adds CMA node to reserve enougth memory for 1080p display
>>  - Adds the HDMI controller et connector modes on selected boards
>>  - Adds a proper dt-bindings for the HDMI controller et connector
>>  - Updates the MAINTAINERS file to track the new files
>>
>> [1] 
>> http://lkml.kernel.org/r/20170301223915.29888-1-laurent.pinchart+rene...@ideasonboard.com
>> [2] 
>> http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
>>
>> Neil Armstrong (11):
>>   drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable
>> sync for vsync commit
>>   drm/meson: Add missing HDMI register
>>   drm/meson: Add support for components
>>   drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available
>>   drm/meson: add support for HDMI clock support
>>   drm/meson: Add support for HDMI venc modes and settings
>>   drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY
>>   ARM64: dts: meson-gx: Add shared CMA dma memory pool
>>   ARM64: dts: meson-gx: Add support for HDMI output
>>   dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension
>>   MAINTAINERS: update files for Amlogic DRM Driver
>>
>>  .../bindings/display/amlogic,meson-dw-hdmi.txt |  111 ++
>>  MAINTAINERS|1 +
>>  .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |   39 +
>>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi  |   40 +
>>  .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts|   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi   |   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   12 +
>>  .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts |   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi |   13 +
>>  .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxm.dtsi |4 +
>>  drivers/gpu/drm/meson/Kconfig  |6 +
>>

Re: [PATCH 00/11] drm/meson: Initial support for HDMI Output

2017-03-02 Thread Neil Armstrong

On 03/02/2017 04:58 PM, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 04:39:56PM +0100, Neil Armstrong wrote:
>> The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
>> in combination with a very custom PHY.
>>
>> This patchset depends on Laurent Pinchart v4 patchset at [1] and my v2
>> patchset at [2] to permit PHY control from outside the dw-hdmi driver.
>>
>> The Synopsys DesignWare HDMI TX Controller is integrated like :
>>  ___
>> |HDMI TOP   |<= HPD
>> |___|
>> |  ||
>> HDMI-TX-|  Synopsys HDMI   |   HDMI PHY |=> TMDS
>> |Controller||
>> |___|<=> DDC
>>
>> And uses the following paths for Pixels Encoding :
>>_   _   
>> vd1---| |-| | | VENC /-|VDAC
>> vd2---| VIU |-| VPP |-|-ENCI/-ENCI_DVI-|\
>> osd1--| |-| | | \  | X--HDMI-TX
>> osd2--|_|-|_| |  |\-ENCP--ENCP_DVI-|/
>>   |  | |
>>   |  \--ENCL---|LVDS
>>   ||
>>
>> The ENCI and ENCP encoders pre-formats the data for the ENCI-DVI and
>> ENCP-DVI encoders. Those DVI encoders will format the pixels for the
>> Synopsys DesignWare HDMI TX Controller.
>>
>> In order to support display modes, the ENCI and ENCP encoders needs very
>> specific parameters for *each* display modes, so usage of the CEA VIC
>> identifier is necessary. But the DVI timings are generated from the
>> drm_mode structure in a generic way.
>>
>> To simplify the first push, only the main CEA modes are supported up to
>> 1920x1080p60. Supporting the 480i and 576i needs tweaking in the dw-hdmi
>> in order to support the Clock Doubling necessary for these modes.
>>
>> Support for more traditional modes like the EDID fallback modes is planned
>> but will need tome additionnal handling along the CEA modes.
>> Support for 4k2k modes needs to be able to get the EDID HDMI modes, but
>> for now only the HDMI 1.4 modes are currently available in the drm_edid
>> implementation.
> 
> Btw, with the neat ascii-art stuff here and in comments in your code, did
> you look into assembling all that into a meson driver documentation
> chapter like the one for vc4 that was just merged?
> -Daniel

Hi Daniel,

Yes, I was thinking about that, but was focused to have all the bits working and
in an upstream-able form.

I will certainly push one in the next few days since I already have a lot of 
text
ready in the comments.

Neil

> 
>>
>> This patchset does :
>>  - Fixes the CRTC handling
>>  - Fixes the registers definitions
>>  - Adds support for device components registration along of-graph
>>  - Adds support for HDMI clocks
>>  - Adds support for HDMI VENC video modes
>>  - Adds support for the Custom HDMI PHY using callbacks added in [1] and [2]
>>  - Adds CMA node to reserve enougth memory for 1080p display
>>  - Adds the HDMI controller et connector modes on selected boards
>>  - Adds a proper dt-bindings for the HDMI controller et connector
>>  - Updates the MAINTAINERS file to track the new files
>>
>> [1] 
>> http://lkml.kernel.org/r/20170301223915.29888-1-laurent.pinchart+rene...@ideasonboard.com
>> [2] 
>> http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
>>
>> Neil Armstrong (11):
>>   drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable
>> sync for vsync commit
>>   drm/meson: Add missing HDMI register
>>   drm/meson: Add support for components
>>   drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available
>>   drm/meson: add support for HDMI clock support
>>   drm/meson: Add support for HDMI venc modes and settings
>>   drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY
>>   ARM64: dts: meson-gx: Add shared CMA dma memory pool
>>   ARM64: dts: meson-gx: Add support for HDMI output
>>   dt-bindings: Add bindings for the Amlogic Meson dw-hdmi extension
>>   MAINTAINERS: update files for Amlogic DRM Driver
>>
>>  .../bindings/display/amlogic,meson-dw-hdmi.txt |  111 ++
>>  MAINTAINERS|1 +
>>  .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |   39 +
>>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi  |   40 +
>>  .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts|   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi   |   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   12 +
>>  .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts |   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi |   13 +
>>  .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |   23 +
>>  arch/arm64/boot/dts/amlogic/meson-gxm.dtsi |4 +
>>  drivers/gpu/drm/meson/Kconfig  |6 +
>>

Re: nios2 crash/hang in mainline due to 'lib: update LZ4 compressor module'

2017-03-02 Thread Tobias Klauser

On 2017-03-01 at 20:45:21 +0100, Guenter Roeck  wrote:
> On Wed, Mar 01, 2017 at 07:58:17PM +0100, Sven Schmidt wrote:
> > Hi Guenter, Tobias and Sandra,
> > 
> > thanks for your effort here.
> > 
> > On Tue, Feb 28, 2017 at 10:14:13AM -0800, Guenter Roeck wrote:
> > > On Tue, Feb 28, 2017 at 10:53:56AM -0700, Sandra Loosemore wrote:
> > > > On 02/28/2017 08:53 AM, Tobias Klauser wrote:
> > > > >(adding Sandra Loosemore to Cc due to possible relation to gcc/binutils
> > > > >for nios2)
> > > > >
> > > > >On 2017-02-26 at 22:03:38 +0100, Guenter Roeck  
> > > > >wrote:
> > > > >>Hi Sven,
> > > > >>
> > > > >>my qemu test for nios2 started failing with commit 4e1a33b105dd ("lib:
> > > > >>update LZ4 compressor module"). The test hangs early during boot 
> > > > >>before
> > > > >>any console output is seen. Reverting the offending patch as well as 
> > > > >>the
> > > > >>subsequent lz4 related patches fixes the problem. Disabling 
> > > > >>CONFIG_RD_LZ4
> > > > >>and with it other LZ4 options also fixes it (as does adding "return 
> > > > >>-EINVAL;"
> > > > >>at the top of the LZ4 decompression code). For reference, bisect log
> > > > >>is attached.
> > > > >>
> > > > >>I tried with buildroot toolchains using gcc 6.1.0 as well as 6.3.0
> > > > >>and binutils 2.26.1. Scripts used to run the tests are available at
> > > > >>https://github.com/groeck/linux-build-test/tree/master/rootfs/nios2.
> > > > >>Qemu is from qemu mainline or qemu v2.8 with nios2 patches applied.
> > > > >
> > > > >Looks like this is somehow related to gcc/binutils. Using GCC 4.8.3 and
> > > > >binutils 2.24.51 (both from from Sourcery CodeBench Lite 2014.05) I can
> > > > >get a kernel booting on latest master branch. AFAICT, none of the
> > > > >LZ4_decompress_* functions are called during boot.
> > > > >
> > 
> > It seems a bit strange that code which is not actually called causes 
> > problems like that.
> > 
> Yes, it is, though it is always possible. The code isn't exactly easy to
> understand; there may be some hidden caveats such as global variables. It may
> also be that some jump target exceeds its range (though why that would only
> be seen with the LZ4 code is another question), or that the compiler gets
> confused by the forced inlines (disabling that didn't make a difference,
> though, nor did disabling -O3).
> 
> > Please let me know if and how I may help you figure out what's happening, 
> > especially
> > regarding the differences between the previous LZ4 and the current 
> > implementation.
> > 
> 
> For my part I am all but clueless. Unless someone has an idea, we may to
> disable LZ4 support for nios2 for the time being. Does anyone have thoughts
> on that ? Of course, that would not help if the problem also affects
> recent gcc/binutil versions on other architectures.

After some further investigations, I'd say this isn't "caused" by LZ4
specifically but by a more general problem with one of the nios2 arch
specific tools involved.

I manually enabled random additional CONFIG_* options and in some cases
I got the kernel to boot (with CONFIG_RD_LZ4 enabled and no return
-EINVAL in place) while in others I didn't. So I'd rather suspect this
problem to be connected to the size or structure of the generated vmlinux
image.

Or could this even be a problem with qemu? Did anyone already verify
this on the 10m50 devboard? (Unfortunately I don't have any nios2
devboard available right now, otherwise I would have done this...)

Other than that I'm also becoming all but clueless... One option I
thought of was using the QEMU monitor to dump the CPU state after the
hang but so far I didn't manage to get it to work (hints appreciated ;)

Thanks
Tobias

Re: nios2 crash/hang in mainline due to 'lib: update LZ4 compressor module'

2017-03-02 Thread Tobias Klauser

On 2017-03-01 at 20:45:21 +0100, Guenter Roeck  wrote:
> On Wed, Mar 01, 2017 at 07:58:17PM +0100, Sven Schmidt wrote:
> > Hi Guenter, Tobias and Sandra,
> > 
> > thanks for your effort here.
> > 
> > On Tue, Feb 28, 2017 at 10:14:13AM -0800, Guenter Roeck wrote:
> > > On Tue, Feb 28, 2017 at 10:53:56AM -0700, Sandra Loosemore wrote:
> > > > On 02/28/2017 08:53 AM, Tobias Klauser wrote:
> > > > >(adding Sandra Loosemore to Cc due to possible relation to gcc/binutils
> > > > >for nios2)
> > > > >
> > > > >On 2017-02-26 at 22:03:38 +0100, Guenter Roeck  
> > > > >wrote:
> > > > >>Hi Sven,
> > > > >>
> > > > >>my qemu test for nios2 started failing with commit 4e1a33b105dd ("lib:
> > > > >>update LZ4 compressor module"). The test hangs early during boot 
> > > > >>before
> > > > >>any console output is seen. Reverting the offending patch as well as 
> > > > >>the
> > > > >>subsequent lz4 related patches fixes the problem. Disabling 
> > > > >>CONFIG_RD_LZ4
> > > > >>and with it other LZ4 options also fixes it (as does adding "return 
> > > > >>-EINVAL;"
> > > > >>at the top of the LZ4 decompression code). For reference, bisect log
> > > > >>is attached.
> > > > >>
> > > > >>I tried with buildroot toolchains using gcc 6.1.0 as well as 6.3.0
> > > > >>and binutils 2.26.1. Scripts used to run the tests are available at
> > > > >>https://github.com/groeck/linux-build-test/tree/master/rootfs/nios2.
> > > > >>Qemu is from qemu mainline or qemu v2.8 with nios2 patches applied.
> > > > >
> > > > >Looks like this is somehow related to gcc/binutils. Using GCC 4.8.3 and
> > > > >binutils 2.24.51 (both from from Sourcery CodeBench Lite 2014.05) I can
> > > > >get a kernel booting on latest master branch. AFAICT, none of the
> > > > >LZ4_decompress_* functions are called during boot.
> > > > >
> > 
> > It seems a bit strange that code which is not actually called causes 
> > problems like that.
> > 
> Yes, it is, though it is always possible. The code isn't exactly easy to
> understand; there may be some hidden caveats such as global variables. It may
> also be that some jump target exceeds its range (though why that would only
> be seen with the LZ4 code is another question), or that the compiler gets
> confused by the forced inlines (disabling that didn't make a difference,
> though, nor did disabling -O3).
> 
> > Please let me know if and how I may help you figure out what's happening, 
> > especially
> > regarding the differences between the previous LZ4 and the current 
> > implementation.
> > 
> 
> For my part I am all but clueless. Unless someone has an idea, we may to
> disable LZ4 support for nios2 for the time being. Does anyone have thoughts
> on that ? Of course, that would not help if the problem also affects
> recent gcc/binutil versions on other architectures.

After some further investigations, I'd say this isn't "caused" by LZ4
specifically but by a more general problem with one of the nios2 arch
specific tools involved.

I manually enabled random additional CONFIG_* options and in some cases
I got the kernel to boot (with CONFIG_RD_LZ4 enabled and no return
-EINVAL in place) while in others I didn't. So I'd rather suspect this
problem to be connected to the size or structure of the generated vmlinux
image.

Or could this even be a problem with qemu? Did anyone already verify
this on the 10m50 devboard? (Unfortunately I don't have any nios2
devboard available right now, otherwise I would have done this...)

Other than that I'm also becoming all but clueless... One option I
thought of was using the QEMU monitor to dump the CPU state after the
hang but so far I didn't manage to get it to work (hints appreciated ;)

Thanks
Tobias

Re: [PATCH 6/7] net: stmmac: dwc-qos: Split out ->probe() and ->remove()

2017-03-02 Thread Joao Pinto

Às 5:24 PM de 2/23/2017, Thierry Reding escreveu:
> From: Thierry Reding 
> 
> Split out the binding specific parts of ->probe() and ->remove() to
> enable the driver to support variants of the binding. This is useful in
> order to keep backwards-compatibility while making it easy for a sub-
> driver to deal only with the updated bindings rather than having to add
> compatibility quirks all over the place.
> 
> Signed-off-by: Thierry Reding 
> ---
>  .../ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c| 114 
> -
>  1 file changed, 88 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
> index 1a3fa3d9f855..5071d3c15adc 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -106,13 +107,70 @@ static int dwc_eth_dwmac_config_dt(struct 
> platform_device *pdev,
>   return 0;
>  }
>  
> +static void *dwc_qos_probe(struct platform_device *pdev,
> +struct plat_stmmacenet_data *plat_dat,
> +struct stmmac_resources *stmmac_res)
> +{
> + int err;
> +
> + plat_dat->stmmac_clk = devm_clk_get(>dev, "apb_pclk");
> + if (IS_ERR(plat_dat->stmmac_clk)) {
> + dev_err(>dev, "apb_pclk clock not found.\n");
> + return ERR_CAST(plat_dat->stmmac_clk);
> + }
> +
> + clk_prepare_enable(plat_dat->stmmac_clk);
> +
> + plat_dat->pclk = devm_clk_get(>dev, "phy_ref_clk");
> + if (IS_ERR(plat_dat->pclk)) {
> + dev_err(>dev, "phy_ref_clk clock not found.\n");
> + err = PTR_ERR(plat_dat->pclk);
> + goto disable;
> + }
> +
> + clk_prepare_enable(plat_dat->pclk);
> +
> + return NULL;
> +
> +disable:
> + clk_disable_unprepare(plat_dat->stmmac_clk);
> + return ERR_PTR(err);
> +}
> +
> +static int dwc_qos_remove(struct platform_device *pdev)
> +{
> + struct net_device *ndev = platform_get_drvdata(pdev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> +
> + clk_disable_unprepare(priv->plat->pclk);
> + clk_disable_unprepare(priv->plat->stmmac_clk);
> +
> + return 0;
> +}
> +
> +struct dwc_eth_dwmac_data {
> + void *(*probe)(struct platform_device *pdev,
> +struct plat_stmmacenet_data *data,
> +struct stmmac_resources *res);
> + int (*remove)(struct platform_device *pdev);
> +};
> +
> +static const struct dwc_eth_dwmac_data dwc_qos_data = {
> + .probe = dwc_qos_probe,
> + .remove = dwc_qos_remove,
> +};
> +
>  static int dwc_eth_dwmac_probe(struct platform_device *pdev)
>  {
> + const struct dwc_eth_dwmac_data *data;
>   struct plat_stmmacenet_data *plat_dat;
>   struct stmmac_resources stmmac_res;
>   struct resource *res;
> + void *priv;
>   int ret;
>  
> + data = of_device_get_match_data(>dev);
> +
>   memset(_res, 0, sizeof(struct stmmac_resources));
>  
>   /**
> @@ -138,39 +196,26 @@ static int dwc_eth_dwmac_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(plat_dat))
>   return PTR_ERR(plat_dat);
>  
> - plat_dat->stmmac_clk = devm_clk_get(>dev, "apb_pclk");
> - if (IS_ERR(plat_dat->stmmac_clk)) {
> - dev_err(>dev, "apb_pclk clock not found.\n");
> - ret = PTR_ERR(plat_dat->stmmac_clk);
> - plat_dat->stmmac_clk = NULL;
> - goto err_remove_config_dt;
> - }
> - clk_prepare_enable(plat_dat->stmmac_clk);
> -
> - plat_dat->pclk = devm_clk_get(>dev, "phy_ref_clk");
> - if (IS_ERR(plat_dat->pclk)) {
> - dev_err(>dev, "phy_ref_clk clock not found.\n");
> - ret = PTR_ERR(plat_dat->pclk);
> - plat_dat->pclk = NULL;
> - goto err_out_clk_dis_phy;
> + priv = data->probe(pdev, plat_dat, _res);
> + if (IS_ERR(priv)) {
> + ret = PTR_ERR(priv);
> + dev_err(>dev, "failed to probe subdriver: %d\n", ret);
> + goto remove_config;
>   }
> - clk_prepare_enable(plat_dat->pclk);
>  
>   ret = dwc_eth_dwmac_config_dt(pdev, plat_dat);
>   if (ret)
> - goto err_out_clk_dis_aper;
> + goto remove;
>  
>   ret = stmmac_dvr_probe(>dev, plat_dat, _res);
>   if (ret)
> - goto err_out_clk_dis_aper;
> + goto remove;
>  
> - return 0;
> + return ret;
>  
> -err_out_clk_dis_aper:
> - clk_disable_unprepare(plat_dat->pclk);
> -err_out_clk_dis_phy:
> - clk_disable_unprepare(plat_dat->stmmac_clk);
> -err_remove_config_dt:
> +remove:
> + data->remove(pdev);
> +remove_config:
>   stmmac_remove_config_dt(pdev, plat_dat);
>  
>   return ret;
> @@ -178,11 +223,28 @@

Re: [PATCH 6/7] net: stmmac: dwc-qos: Split out ->probe() and ->remove()

2017-03-02 Thread Joao Pinto

Às 5:24 PM de 2/23/2017, Thierry Reding escreveu:
> From: Thierry Reding 
> 
> Split out the binding specific parts of ->probe() and ->remove() to
> enable the driver to support variants of the binding. This is useful in
> order to keep backwards-compatibility while making it easy for a sub-
> driver to deal only with the updated bindings rather than having to add
> compatibility quirks all over the place.
> 
> Signed-off-by: Thierry Reding 
> ---
>  .../ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c| 114 
> -
>  1 file changed, 88 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c 
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
> index 1a3fa3d9f855..5071d3c15adc 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -106,13 +107,70 @@ static int dwc_eth_dwmac_config_dt(struct 
> platform_device *pdev,
>   return 0;
>  }
>  
> +static void *dwc_qos_probe(struct platform_device *pdev,
> +struct plat_stmmacenet_data *plat_dat,
> +struct stmmac_resources *stmmac_res)
> +{
> + int err;
> +
> + plat_dat->stmmac_clk = devm_clk_get(>dev, "apb_pclk");
> + if (IS_ERR(plat_dat->stmmac_clk)) {
> + dev_err(>dev, "apb_pclk clock not found.\n");
> + return ERR_CAST(plat_dat->stmmac_clk);
> + }
> +
> + clk_prepare_enable(plat_dat->stmmac_clk);
> +
> + plat_dat->pclk = devm_clk_get(>dev, "phy_ref_clk");
> + if (IS_ERR(plat_dat->pclk)) {
> + dev_err(>dev, "phy_ref_clk clock not found.\n");
> + err = PTR_ERR(plat_dat->pclk);
> + goto disable;
> + }
> +
> + clk_prepare_enable(plat_dat->pclk);
> +
> + return NULL;
> +
> +disable:
> + clk_disable_unprepare(plat_dat->stmmac_clk);
> + return ERR_PTR(err);
> +}
> +
> +static int dwc_qos_remove(struct platform_device *pdev)
> +{
> + struct net_device *ndev = platform_get_drvdata(pdev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> +
> + clk_disable_unprepare(priv->plat->pclk);
> + clk_disable_unprepare(priv->plat->stmmac_clk);
> +
> + return 0;
> +}
> +
> +struct dwc_eth_dwmac_data {
> + void *(*probe)(struct platform_device *pdev,
> +struct plat_stmmacenet_data *data,
> +struct stmmac_resources *res);
> + int (*remove)(struct platform_device *pdev);
> +};
> +
> +static const struct dwc_eth_dwmac_data dwc_qos_data = {
> + .probe = dwc_qos_probe,
> + .remove = dwc_qos_remove,
> +};
> +
>  static int dwc_eth_dwmac_probe(struct platform_device *pdev)
>  {
> + const struct dwc_eth_dwmac_data *data;
>   struct plat_stmmacenet_data *plat_dat;
>   struct stmmac_resources stmmac_res;
>   struct resource *res;
> + void *priv;
>   int ret;
>  
> + data = of_device_get_match_data(>dev);
> +
>   memset(_res, 0, sizeof(struct stmmac_resources));
>  
>   /**
> @@ -138,39 +196,26 @@ static int dwc_eth_dwmac_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(plat_dat))
>   return PTR_ERR(plat_dat);
>  
> - plat_dat->stmmac_clk = devm_clk_get(>dev, "apb_pclk");
> - if (IS_ERR(plat_dat->stmmac_clk)) {
> - dev_err(>dev, "apb_pclk clock not found.\n");
> - ret = PTR_ERR(plat_dat->stmmac_clk);
> - plat_dat->stmmac_clk = NULL;
> - goto err_remove_config_dt;
> - }
> - clk_prepare_enable(plat_dat->stmmac_clk);
> -
> - plat_dat->pclk = devm_clk_get(>dev, "phy_ref_clk");
> - if (IS_ERR(plat_dat->pclk)) {
> - dev_err(>dev, "phy_ref_clk clock not found.\n");
> - ret = PTR_ERR(plat_dat->pclk);
> - plat_dat->pclk = NULL;
> - goto err_out_clk_dis_phy;
> + priv = data->probe(pdev, plat_dat, _res);
> + if (IS_ERR(priv)) {
> + ret = PTR_ERR(priv);
> + dev_err(>dev, "failed to probe subdriver: %d\n", ret);
> + goto remove_config;
>   }
> - clk_prepare_enable(plat_dat->pclk);
>  
>   ret = dwc_eth_dwmac_config_dt(pdev, plat_dat);
>   if (ret)
> - goto err_out_clk_dis_aper;
> + goto remove;
>  
>   ret = stmmac_dvr_probe(>dev, plat_dat, _res);
>   if (ret)
> - goto err_out_clk_dis_aper;
> + goto remove;
>  
> - return 0;
> + return ret;
>  
> -err_out_clk_dis_aper:
> - clk_disable_unprepare(plat_dat->pclk);
> -err_out_clk_dis_phy:
> - clk_disable_unprepare(plat_dat->stmmac_clk);
> -err_remove_config_dt:
> +remove:
> + data->remove(pdev);
> +remove_config:
>   stmmac_remove_config_dt(pdev, plat_dat);
>  
>   return ret;
> @@ -178,11 +223,28 @@ static int dwc_eth_dwmac_probe(struct

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

2017-03-02 Thread Andy Lutomirski

On Wed, Mar 1, 2017 at 3:28 PM, Mickaël Salaün  wrote:
>
>
> On 01/03/2017 23:20, Andy Lutomirski wrote:
>> On Wed, Mar 1, 2017 at 2:14 PM, Mickaël Salaün  wrote:
>>>
>>> On 28/02/2017 21:01, Andy Lutomirski wrote:
 On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün  wrote:
>>> This design makes it possible for a process to add more constraints to
>>> its children on the fly. I think it is a good feature to have and a
>>> safer default inheritance mechanism, but it could be guarded by an
>>> option flag if we want both mechanism to be available. The same design
>>> could be used by seccomp filter too.
>>>
>>
>> Then let's do it right.
>>
>> Currently each task has an array of seccomp filter layers.  When a
>> task forks, the child inherits the layers.  All the layers are
>> presently immutable.  With Landlock, a layer can logically be a
>> syscall fitler layer or a Landlock layer.  This fits in to the
>> existing model just fine.
>>
>> If we want to have an interface to allow modification of an existing
>> layer, let's make it so that, when a layer is added, you have to
>> specify a flag to make the layer modifiable (by current, presumably,
>> although I can imagine other policies down the road).  Then have a
>> separate API that modifies a layer.
>>
>> IOW, I think your patch is bad for three reasons, all fixable:
>>
>> 1. The default is wrong.  A layer should be immutable to avoid an easy
>> attack in which you try to sandbox *yourself* and then you just modify
>> the layer to weaken it.
>
> This is not possible, there is only an operation for now:
> SECCOMP_ADD_LANDLOCK_RULE. You can only add more rules to the list (as
> for seccomp filter). There is no way to weaken a sandbox. The question
> is: how do we want to handle the rules *tree* (from the kernel point of
> view)?
>

Fair enough.  But I still think that immutability (like regular
seccomp) should be the default.  For security, simplicity is
important.  I guess there could be two ways to relax immutability:
allowing making the layer stricter and allowing any change at all.

As a default, though, programs should be able to expect that:

seccomp(SECCOMP_ADD_WHATEVER, ...);
fork();

[parent gets compromised]
[in parent]seccomp(anything whatsoever);

will not affect the child,  If the parent wants to relax that, that's
fine, but I think it should be explicit.

>>
>> 2. The API that adds a layer should be different from the API that
>> modifies a layer.
>
> Right, but it doesn't apply now because we can only add rules.

That's not what the code appears to do, though.  Sometimes it makes a
new layer without modifying tasks that share the layer and sometimes
it modifies the layer.

Both operations are probably okay, but they're not the same operation
and they shouldn't pretend to be.


>
>>
>> 3. The whole modification mechanism should be a separate patch to be
>> reviewed on its own merits.
>
> For a rule *replacement*, sure!

And for modification of policy for non-current tasks.  That's a big
departure from normal seccomp and should be reviewed as such.

Re: [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

2017-03-02 Thread Andy Lutomirski

On Wed, Mar 1, 2017 at 3:28 PM, Mickaël Salaün  wrote:
>
>
> On 01/03/2017 23:20, Andy Lutomirski wrote:
>> On Wed, Mar 1, 2017 at 2:14 PM, Mickaël Salaün  wrote:
>>>
>>> On 28/02/2017 21:01, Andy Lutomirski wrote:
 On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün  wrote:
>>> This design makes it possible for a process to add more constraints to
>>> its children on the fly. I think it is a good feature to have and a
>>> safer default inheritance mechanism, but it could be guarded by an
>>> option flag if we want both mechanism to be available. The same design
>>> could be used by seccomp filter too.
>>>
>>
>> Then let's do it right.
>>
>> Currently each task has an array of seccomp filter layers.  When a
>> task forks, the child inherits the layers.  All the layers are
>> presently immutable.  With Landlock, a layer can logically be a
>> syscall fitler layer or a Landlock layer.  This fits in to the
>> existing model just fine.
>>
>> If we want to have an interface to allow modification of an existing
>> layer, let's make it so that, when a layer is added, you have to
>> specify a flag to make the layer modifiable (by current, presumably,
>> although I can imagine other policies down the road).  Then have a
>> separate API that modifies a layer.
>>
>> IOW, I think your patch is bad for three reasons, all fixable:
>>
>> 1. The default is wrong.  A layer should be immutable to avoid an easy
>> attack in which you try to sandbox *yourself* and then you just modify
>> the layer to weaken it.
>
> This is not possible, there is only an operation for now:
> SECCOMP_ADD_LANDLOCK_RULE. You can only add more rules to the list (as
> for seccomp filter). There is no way to weaken a sandbox. The question
> is: how do we want to handle the rules *tree* (from the kernel point of
> view)?
>

Fair enough.  But I still think that immutability (like regular
seccomp) should be the default.  For security, simplicity is
important.  I guess there could be two ways to relax immutability:
allowing making the layer stricter and allowing any change at all.

As a default, though, programs should be able to expect that:

seccomp(SECCOMP_ADD_WHATEVER, ...);
fork();

[parent gets compromised]
[in parent]seccomp(anything whatsoever);

will not affect the child,  If the parent wants to relax that, that's
fine, but I think it should be explicit.

>>
>> 2. The API that adds a layer should be different from the API that
>> modifies a layer.
>
> Right, but it doesn't apply now because we can only add rules.

That's not what the code appears to do, though.  Sometimes it makes a
new layer without modifying tasks that share the layer and sometimes
it modifies the layer.

Both operations are probably okay, but they're not the same operation
and they shouldn't pretend to be.


>
>>
>> 3. The whole modification mechanism should be a separate patch to be
>> reviewed on its own merits.
>
> For a rule *replacement*, sure!

And for modification of policy for non-current tasks.  That's a big
departure from normal seccomp and should be reviewed as such.

[PATCH 2/4] staging: speakup: spaces preferred around operator

2017-03-02 Thread Arushi Singhal

Fixed the checkpatch.pl issues like:
CHECK: spaces preferred around that '&' (ctx:VxV)
CHECK: spaces preferred around that '|' (ctx:VxV)
CHECK: spaces preferred around that '-' (ctx:VxV)
CHECK: spaces preferred around that '+' (ctx:VxV)
etc.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/serialio.c   |  4 ++--
 drivers/staging/speakup/speakup.h| 12 ++--
 drivers/staging/speakup/speakup_acntpc.c |  4 ++--
 drivers/staging/speakup/speakup_decpc.c  | 22 +++---
 drivers/staging/speakup/speakup_dtlk.c   | 16 
 drivers/staging/speakup/speakup_keypc.c  | 12 ++--
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 7 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/speakup/serialio.c 
b/drivers/staging/speakup/serialio.c
index 657a48b6f8d3..aade52ee15a0 100644
--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -120,8 +120,8 @@ static void start_serial_interrupt(int irq)
outb(UART_MCR_DTR | UART_MCR_RTS | UART_MCR_OUT2,
speakup_info.port_tts + UART_MCR);
/* Turn on Interrupts */
-   outb(UART_IER_MSI|UART_IER_RLSI|UART_IER_RDI,
-   speakup_info.port_tts + UART_IER);
+   outb(UART_IER_MSI | UART_IER_RLSI | UART_IER_RDI,
+speakup_info.port_tts + UART_IER);
inb(speakup_info.port_tts + UART_LSR);
inb(speakup_info.port_tts + UART_RX);
inb(speakup_info.port_tts + UART_IIR);
diff --git a/drivers/staging/speakup/speakup.h 
b/drivers/staging/speakup/speakup.h
index b203f0f883a9..7a2c3e5ad564 100644
--- a/drivers/staging/speakup/speakup.h
+++ b/drivers/staging/speakup/speakup.h
@@ -20,7 +20,7 @@
 #define A_CAP 0x0007
 #define B_NUM 0x0008
 #define NUM 0x0009
-#define ALPHANUM (B_ALPHA|B_NUM)
+#define ALPHANUM (B_ALPHA | B_NUM)
 #define SOME 0x0010
 #define MOST 0x0020
 #define PUNC 0x0040
@@ -30,13 +30,13 @@
 #define B_EXNUM 0x0100
 #define CH_RPT 0x0200
 #define B_CTL 0x0400
-#define A_CTL (B_CTL+SYNTH_OK)
+#define A_CTL (B_CTL + SYNTH_OK)
 #define B_SYM 0x0800
-#define B_CAPSYM (B_CAP|B_SYM)
+#define B_CAPSYM (B_CAP | B_SYM)
 
-#define IS_WDLM(x) (spk_chartab[((u_char)x)]_WDLM)
-#define IS_CHAR(x, type) (spk_chartab[((u_char)x)])
-#define IS_TYPE(x, type) ((spk_chartab[((u_char)x)]) == type)
+#define IS_WDLM(x) (spk_chartab[((u_char)x)] & B_WDLM)
+#define IS_CHAR(x, type) (spk_chartab[((u_char)x)] & type)
+#define IS_TYPE(x, type) ((spk_chartab[((u_char)x)] & type) == type)
 
 int speakup_thread(void *data);
 void spk_reset_default_chars(void);
diff --git a/drivers/staging/speakup/speakup_acntpc.c 
b/drivers/staging/speakup/speakup_acntpc.c
index cf6fcd63498d..bca386d9fbd1 100644
--- a/drivers/staging/speakup/speakup_acntpc.c
+++ b/drivers/staging/speakup/speakup_acntpc.c
@@ -280,7 +280,7 @@ static int synth_probe(struct spk_synth *synth)
if (port_val == 0x53fc) {
/* 'S' and out bits */
synth_port_control = synth_portlist[i];
-   speakup_info.port_tts = synth_port_control+1;
+   speakup_info.port_tts = synth_port_control + 1;
break;
}
}
@@ -303,7 +303,7 @@ static int synth_probe(struct spk_synth *synth)
 static void accent_release(void)
 {
if (speakup_info.port_tts)
-   synth_release_region(speakup_info.port_tts-1, SYNTH_IO_EXTENT);
+   synth_release_region(speakup_info.port_tts - 1, 
SYNTH_IO_EXTENT);
speakup_info.port_tts = 0;
 }
 
diff --git a/drivers/staging/speakup/speakup_decpc.c 
b/drivers/staging/speakup/speakup_decpc.c
index 6bf38e49a96d..600eb057f830 100644
--- a/drivers/staging/speakup/speakup_decpc.c
+++ b/drivers/staging/speakup/speakup_decpc.c
@@ -251,7 +251,7 @@ static int dt_getstatus(void)
 static void dt_sendcmd(u_int cmd)
 {
outb_p(cmd & 0xFF, speakup_info.port_tts);
-   outb_p((cmd >> 8) & 0xFF, speakup_info.port_tts+1);
+   outb_p((cmd >> 8) & 0xFF, speakup_info.port_tts + 1);
 }
 
 static int dt_waitbit(int bit)
@@ -273,7 +273,7 @@ static int dt_wait_dma(void)
if (!dt_waitbit(STAT_dma_ready))
return 0;
while (--timeout > 0) {
-   if ((dt_getstatus()_dma_state) == state)
+   if ((dt_getstatus() & STAT_dma_state) == state)
return 1;
udelay(50);
}
@@ -287,11 +287,11 @@ static int dt_ctrl(u_int cmd)
 
if (!dt_waitbit(STAT_cmd_ready))
return -1;
-   outb_p(0, speakup_info.port_tts+2);
-   outb_p(0, speakup_info.port_tts+3);
+   outb_p(0, speakup_info.port_tts + 2);
+   outb_p(0, speakup_info.port_tts + 3);
dt_getstatus();
-   dt_sendcmd(CMD_control|cmd);
-   outb_p(0, speakup_info.port_tts+6);
+

[PATCH 2/4] staging: speakup: spaces preferred around operator

2017-03-02 Thread Arushi Singhal

Fixed the checkpatch.pl issues like:
CHECK: spaces preferred around that '&' (ctx:VxV)
CHECK: spaces preferred around that '|' (ctx:VxV)
CHECK: spaces preferred around that '-' (ctx:VxV)
CHECK: spaces preferred around that '+' (ctx:VxV)
etc.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/serialio.c   |  4 ++--
 drivers/staging/speakup/speakup.h| 12 ++--
 drivers/staging/speakup/speakup_acntpc.c |  4 ++--
 drivers/staging/speakup/speakup_decpc.c  | 22 +++---
 drivers/staging/speakup/speakup_dtlk.c   | 16 
 drivers/staging/speakup/speakup_keypc.c  | 12 ++--
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 7 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/staging/speakup/serialio.c 
b/drivers/staging/speakup/serialio.c
index 657a48b6f8d3..aade52ee15a0 100644
--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -120,8 +120,8 @@ static void start_serial_interrupt(int irq)
outb(UART_MCR_DTR | UART_MCR_RTS | UART_MCR_OUT2,
speakup_info.port_tts + UART_MCR);
/* Turn on Interrupts */
-   outb(UART_IER_MSI|UART_IER_RLSI|UART_IER_RDI,
-   speakup_info.port_tts + UART_IER);
+   outb(UART_IER_MSI | UART_IER_RLSI | UART_IER_RDI,
+speakup_info.port_tts + UART_IER);
inb(speakup_info.port_tts + UART_LSR);
inb(speakup_info.port_tts + UART_RX);
inb(speakup_info.port_tts + UART_IIR);
diff --git a/drivers/staging/speakup/speakup.h 
b/drivers/staging/speakup/speakup.h
index b203f0f883a9..7a2c3e5ad564 100644
--- a/drivers/staging/speakup/speakup.h
+++ b/drivers/staging/speakup/speakup.h
@@ -20,7 +20,7 @@
 #define A_CAP 0x0007
 #define B_NUM 0x0008
 #define NUM 0x0009
-#define ALPHANUM (B_ALPHA|B_NUM)
+#define ALPHANUM (B_ALPHA | B_NUM)
 #define SOME 0x0010
 #define MOST 0x0020
 #define PUNC 0x0040
@@ -30,13 +30,13 @@
 #define B_EXNUM 0x0100
 #define CH_RPT 0x0200
 #define B_CTL 0x0400
-#define A_CTL (B_CTL+SYNTH_OK)
+#define A_CTL (B_CTL + SYNTH_OK)
 #define B_SYM 0x0800
-#define B_CAPSYM (B_CAP|B_SYM)
+#define B_CAPSYM (B_CAP | B_SYM)
 
-#define IS_WDLM(x) (spk_chartab[((u_char)x)]_WDLM)
-#define IS_CHAR(x, type) (spk_chartab[((u_char)x)])
-#define IS_TYPE(x, type) ((spk_chartab[((u_char)x)]) == type)
+#define IS_WDLM(x) (spk_chartab[((u_char)x)] & B_WDLM)
+#define IS_CHAR(x, type) (spk_chartab[((u_char)x)] & type)
+#define IS_TYPE(x, type) ((spk_chartab[((u_char)x)] & type) == type)
 
 int speakup_thread(void *data);
 void spk_reset_default_chars(void);
diff --git a/drivers/staging/speakup/speakup_acntpc.c 
b/drivers/staging/speakup/speakup_acntpc.c
index cf6fcd63498d..bca386d9fbd1 100644
--- a/drivers/staging/speakup/speakup_acntpc.c
+++ b/drivers/staging/speakup/speakup_acntpc.c
@@ -280,7 +280,7 @@ static int synth_probe(struct spk_synth *synth)
if (port_val == 0x53fc) {
/* 'S' and out bits */
synth_port_control = synth_portlist[i];
-   speakup_info.port_tts = synth_port_control+1;
+   speakup_info.port_tts = synth_port_control + 1;
break;
}
}
@@ -303,7 +303,7 @@ static int synth_probe(struct spk_synth *synth)
 static void accent_release(void)
 {
if (speakup_info.port_tts)
-   synth_release_region(speakup_info.port_tts-1, SYNTH_IO_EXTENT);
+   synth_release_region(speakup_info.port_tts - 1, 
SYNTH_IO_EXTENT);
speakup_info.port_tts = 0;
 }
 
diff --git a/drivers/staging/speakup/speakup_decpc.c 
b/drivers/staging/speakup/speakup_decpc.c
index 6bf38e49a96d..600eb057f830 100644
--- a/drivers/staging/speakup/speakup_decpc.c
+++ b/drivers/staging/speakup/speakup_decpc.c
@@ -251,7 +251,7 @@ static int dt_getstatus(void)
 static void dt_sendcmd(u_int cmd)
 {
outb_p(cmd & 0xFF, speakup_info.port_tts);
-   outb_p((cmd >> 8) & 0xFF, speakup_info.port_tts+1);
+   outb_p((cmd >> 8) & 0xFF, speakup_info.port_tts + 1);
 }
 
 static int dt_waitbit(int bit)
@@ -273,7 +273,7 @@ static int dt_wait_dma(void)
if (!dt_waitbit(STAT_dma_ready))
return 0;
while (--timeout > 0) {
-   if ((dt_getstatus()_dma_state) == state)
+   if ((dt_getstatus() & STAT_dma_state) == state)
return 1;
udelay(50);
}
@@ -287,11 +287,11 @@ static int dt_ctrl(u_int cmd)
 
if (!dt_waitbit(STAT_cmd_ready))
return -1;
-   outb_p(0, speakup_info.port_tts+2);
-   outb_p(0, speakup_info.port_tts+3);
+   outb_p(0, speakup_info.port_tts + 2);
+   outb_p(0, speakup_info.port_tts + 3);
dt_getstatus();
-   dt_sendcmd(CMD_control|cmd);
-   outb_p(0, speakup_info.port_tts+6);
+   dt_sendcmd(CMD_control | cmd);
+

[PATCH 03/11] drm/meson: Add support for components

2017-03-02 Thread Neil Armstrong

This patch adds support for optional components connected through the
Device Tree endpoints scheme.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_drv.c | 113 +-
 1 file changed, 99 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 8d17d0e..f381088 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -162,9 +163,9 @@ static bool meson_vpu_has_available_connectors(struct 
device *dev)
.max_register   = 0x1000,
 };
 
-static int meson_drv_probe(struct platform_device *pdev)
+static int meson_drv_bind(struct device *dev)
 {
-   struct device *dev = >dev;
+   struct platform_device *pdev = to_platform_device(dev);
struct meson_drm *priv;
struct drm_device *drm;
struct resource *res;
@@ -227,6 +228,15 @@ static int meson_drv_probe(struct platform_device *pdev)
 
drm_vblank_init(drm, 1);
drm_mode_config_init(drm);
+   drm->mode_config.max_width = 3840;
+   drm->mode_config.max_height = 2160;
+   drm->mode_config.funcs = _mode_config_funcs;
+
+   /* Hardware Initialization */
+
+   meson_venc_init(priv);
+   meson_vpp_init(priv);
+   meson_viu_init(priv);
 
/* Encoder Initialization */
 
@@ -234,11 +244,11 @@ static int meson_drv_probe(struct platform_device *pdev)
if (ret)
goto free_drm;
 
-   /* Hardware Initialization */
-
-   meson_venc_init(priv);
-   meson_vpp_init(priv);
-   meson_viu_init(priv);
+   ret = component_bind_all(drm->dev, drm);
+   if (ret) {
+   dev_err(drm->dev, "Couldn't bind all components\n");
+   goto free_drm;
+   }
 
ret = meson_plane_create(priv);
if (ret)
@@ -253,9 +263,6 @@ static int meson_drv_probe(struct platform_device *pdev)
goto free_drm;
 
drm_mode_config_reset(drm);
-   drm->mode_config.max_width = 8192;
-   drm->mode_config.max_height = 8192;
-   drm->mode_config.funcs = _mode_config_funcs;
 
priv->fbdev = drm_fbdev_cma_init(drm, 32,
 drm->mode_config.num_connector);
@@ -280,9 +287,9 @@ static int meson_drv_probe(struct platform_device *pdev)
return ret;
 }
 
-static int meson_drv_remove(struct platform_device *pdev)
+static void meson_drv_unbind(struct device *dev)
 {
-   struct drm_device *drm = dev_get_drvdata(>dev);
+   struct drm_device *drm = dev_get_drvdata(dev);
struct meson_drm *priv = drm->dev_private;
 
drm_dev_unregister(drm);
@@ -292,9 +299,88 @@ static int meson_drv_remove(struct platform_device *pdev)
drm_vblank_cleanup(drm);
drm_dev_unref(drm);
 
-   return 0;
 }
 
+static const struct component_master_ops meson_drv_master_ops = {
+   .bind   = meson_drv_bind,
+   .unbind = meson_drv_unbind,
+};
+
+static int compare_of(struct device *dev, void *data)
+{
+   DRM_DEBUG_DRIVER("Comparing of node %s with %s\n",
+of_node_full_name(dev->of_node),
+of_node_full_name(data));
+
+   return dev->of_node == data;
+}
+
+/* Possible connectors nodes to ignore */
+static const struct of_device_id connectors_match[] = {
+   { .compatible = "composite-video-connector" },
+   { .compatible = "svideo-connector" },
+   { .compatible = "hdmi-connector" },
+   { .compatible = "dvi-connector" },
+   {}
+};
+
+static int meson_probe_remote(struct platform_device *pdev,
+ struct component_match **match,
+ struct device_node *parent,
+ struct device_node *remote)
+{
+   struct device_node *ep, *remote_node;
+   int count = 1;
+
+   /* If node is a connector, return and do not add to match table */
+   if (of_match_node(connectors_match, remote))
+   return 1;
+
+   component_match_add(>dev, match, compare_of, remote);
+
+   for_each_endpoint_of_node(remote, ep) {
+   remote_node = of_graph_get_remote_port_parent(ep);
+   if (!remote_node ||
+   remote_node == parent || /* Ignore parent endpoint */
+   !of_device_is_available(remote_node))
+   continue;
+
+   count += meson_probe_remote(pdev, match, remote, remote_node);
+
+   of_node_put(remote_node);
+   }
+
+   return count;
+}
+
+static int meson_drv_probe(struct platform_device *pdev)
+{
+   struct component_match *match = NULL;
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *ep, *remote;
+   int count = 0;
+
+   for_each_endpoint_of_node(np, ep) {
+   remote =

[PATCH 03/11] drm/meson: Add support for components

2017-03-02 Thread Neil Armstrong

This patch adds support for optional components connected through the
Device Tree endpoints scheme.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_drv.c | 113 +-
 1 file changed, 99 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 8d17d0e..f381088 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -162,9 +163,9 @@ static bool meson_vpu_has_available_connectors(struct 
device *dev)
.max_register   = 0x1000,
 };
 
-static int meson_drv_probe(struct platform_device *pdev)
+static int meson_drv_bind(struct device *dev)
 {
-   struct device *dev = >dev;
+   struct platform_device *pdev = to_platform_device(dev);
struct meson_drm *priv;
struct drm_device *drm;
struct resource *res;
@@ -227,6 +228,15 @@ static int meson_drv_probe(struct platform_device *pdev)
 
drm_vblank_init(drm, 1);
drm_mode_config_init(drm);
+   drm->mode_config.max_width = 3840;
+   drm->mode_config.max_height = 2160;
+   drm->mode_config.funcs = _mode_config_funcs;
+
+   /* Hardware Initialization */
+
+   meson_venc_init(priv);
+   meson_vpp_init(priv);
+   meson_viu_init(priv);
 
/* Encoder Initialization */
 
@@ -234,11 +244,11 @@ static int meson_drv_probe(struct platform_device *pdev)
if (ret)
goto free_drm;
 
-   /* Hardware Initialization */
-
-   meson_venc_init(priv);
-   meson_vpp_init(priv);
-   meson_viu_init(priv);
+   ret = component_bind_all(drm->dev, drm);
+   if (ret) {
+   dev_err(drm->dev, "Couldn't bind all components\n");
+   goto free_drm;
+   }
 
ret = meson_plane_create(priv);
if (ret)
@@ -253,9 +263,6 @@ static int meson_drv_probe(struct platform_device *pdev)
goto free_drm;
 
drm_mode_config_reset(drm);
-   drm->mode_config.max_width = 8192;
-   drm->mode_config.max_height = 8192;
-   drm->mode_config.funcs = _mode_config_funcs;
 
priv->fbdev = drm_fbdev_cma_init(drm, 32,
 drm->mode_config.num_connector);
@@ -280,9 +287,9 @@ static int meson_drv_probe(struct platform_device *pdev)
return ret;
 }
 
-static int meson_drv_remove(struct platform_device *pdev)
+static void meson_drv_unbind(struct device *dev)
 {
-   struct drm_device *drm = dev_get_drvdata(>dev);
+   struct drm_device *drm = dev_get_drvdata(dev);
struct meson_drm *priv = drm->dev_private;
 
drm_dev_unregister(drm);
@@ -292,9 +299,88 @@ static int meson_drv_remove(struct platform_device *pdev)
drm_vblank_cleanup(drm);
drm_dev_unref(drm);
 
-   return 0;
 }
 
+static const struct component_master_ops meson_drv_master_ops = {
+   .bind   = meson_drv_bind,
+   .unbind = meson_drv_unbind,
+};
+
+static int compare_of(struct device *dev, void *data)
+{
+   DRM_DEBUG_DRIVER("Comparing of node %s with %s\n",
+of_node_full_name(dev->of_node),
+of_node_full_name(data));
+
+   return dev->of_node == data;
+}
+
+/* Possible connectors nodes to ignore */
+static const struct of_device_id connectors_match[] = {
+   { .compatible = "composite-video-connector" },
+   { .compatible = "svideo-connector" },
+   { .compatible = "hdmi-connector" },
+   { .compatible = "dvi-connector" },
+   {}
+};
+
+static int meson_probe_remote(struct platform_device *pdev,
+ struct component_match **match,
+ struct device_node *parent,
+ struct device_node *remote)
+{
+   struct device_node *ep, *remote_node;
+   int count = 1;
+
+   /* If node is a connector, return and do not add to match table */
+   if (of_match_node(connectors_match, remote))
+   return 1;
+
+   component_match_add(>dev, match, compare_of, remote);
+
+   for_each_endpoint_of_node(remote, ep) {
+   remote_node = of_graph_get_remote_port_parent(ep);
+   if (!remote_node ||
+   remote_node == parent || /* Ignore parent endpoint */
+   !of_device_is_available(remote_node))
+   continue;
+
+   count += meson_probe_remote(pdev, match, remote, remote_node);
+
+   of_node_put(remote_node);
+   }
+
+   return count;
+}
+
+static int meson_drv_probe(struct platform_device *pdev)
+{
+   struct component_match *match = NULL;
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *ep, *remote;
+   int count = 0;
+
+   for_each_endpoint_of_node(np, ep) {
+   remote = of_graph_get_remote_port_parent(ep);
+

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

2017-03-02 Thread Sakari Ailus

Hi Steve,

On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
> v4l2_pipeline_inherit_controls() will add the v4l2 controls from
> all subdev entities in a pipeline to a given video device.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/media/v4l2-core/v4l2-mc.c | 48 
> +++
>  include/media/v4l2-mc.h   | 25 
>  2 files changed, 73 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
> b/drivers/media/v4l2-core/v4l2-mc.c
> index 303980b..09d4d97 100644
> --- a/drivers/media/v4l2-core/v4l2-mc.c
> +++ b/drivers/media/v4l2-core/v4l2-mc.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -238,6 +239,53 @@ int v4l_vb2q_enable_media_source(struct vb2_queue *q)
>  }
>  EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
>  
> +int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +  struct media_entity *start_entity)

I have a few concerns / questions:

- What's the purpose of this patch? Why not to access the sub-device node
  directly?

- This implementation is only workable as long as you do not modify the
  pipeline. Once you disable a link along the pipeline, a device where the
  control was inherited from may no longer be a part of the pipeline.
  Depending on the hardware, it could be a part of another pipeline, in
  which case it certainly must not be accessible through an unrelated video
  node. As the function is added to the framework, I would expect it to
  handle such a case correctly.

- I assume it is the responsibility of the caller of this function to ensure
  the device in question will not be powered off whilst the video node is
  used as another user space interface to such a sub-device. If the driver
  uses the generic PM functions in the same file, this works, but it still
  has to be documented.

> +{
> + struct media_device *mdev = start_entity->graph_obj.mdev;
> + struct media_entity *entity;
> + struct media_graph graph;
> + struct v4l2_subdev *sd;
> + int ret;
> +
> + ret = media_graph_walk_init(, mdev);
> + if (ret)
> + return ret;
> +
> + media_graph_walk_start(, start_entity);
> +
> + while ((entity = media_graph_walk_next())) {
> + if (!is_media_entity_v4l2_subdev(entity))
> + continue;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
> + sd->ctrl_handler,
> + NULL);
> + if (ret)
> + break;
> + }
> +
> + media_graph_walk_cleanup();
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(__v4l2_pipeline_inherit_controls);
> +
> +int v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +struct media_entity *start_entity)
> +{
> + struct media_device *mdev = start_entity->graph_obj.mdev;
> + int ret;
> +
> + mutex_lock(>graph_mutex);
> + ret = __v4l2_pipeline_inherit_controls(vfd, start_entity);
> + mutex_unlock(>graph_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_pipeline_inherit_controls);
> +
>  /* 
> -
>   * Pipeline power management
>   *
> diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h
> index 2634d9d..9848e77 100644
> --- a/include/media/v4l2-mc.h
> +++ b/include/media/v4l2-mc.h
> @@ -171,6 +171,17 @@ void v4l_disable_media_source(struct video_device *vdev);
>   */
>  int v4l_vb2q_enable_media_source(struct vb2_queue *q);
>  
> +/**
> + * v4l2_pipeline_inherit_controls - Add the v4l2 controls from all
> + *   subdev entities in a pipeline to
> + *   the given video device.
> + * @vfd: the video device
> + * @start_entity: Starting entity
> + */
> +int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +  struct media_entity *start_entity);
> +int v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +struct media_entity *start_entity);
>  
>  /**
>   * v4l2_pipeline_pm_use - Update the use count of an entity
> @@ -231,6 +242,20 @@ static inline int v4l_vb2q_enable_media_source(struct 
> vb2_queue *q)
>   return 0;
>  }
>  
> +static inline int __v4l2_pipeline_inherit_controls(
> + struct video_device *vfd,
> + struct media_entity *start_entity)
> +{
> + return 0;
> +}
> +
> +static inline int v4l2_pipeline_inherit_controls(
> + struct video_device *vfd,
> + struct media_entity *start_entity)
> +{
> + return 0;
> +}
> +
>  static inline int v4l2_pipeline_pm_use(struct media_entity *entity, int use)
>  {
>   return 0;

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

2017-03-02 Thread Sakari Ailus

Hi Steve,

On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
> v4l2_pipeline_inherit_controls() will add the v4l2 controls from
> all subdev entities in a pipeline to a given video device.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/media/v4l2-core/v4l2-mc.c | 48 
> +++
>  include/media/v4l2-mc.h   | 25 
>  2 files changed, 73 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
> b/drivers/media/v4l2-core/v4l2-mc.c
> index 303980b..09d4d97 100644
> --- a/drivers/media/v4l2-core/v4l2-mc.c
> +++ b/drivers/media/v4l2-core/v4l2-mc.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -238,6 +239,53 @@ int v4l_vb2q_enable_media_source(struct vb2_queue *q)
>  }
>  EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
>  
> +int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +  struct media_entity *start_entity)

I have a few concerns / questions:

- What's the purpose of this patch? Why not to access the sub-device node
  directly?

- This implementation is only workable as long as you do not modify the
  pipeline. Once you disable a link along the pipeline, a device where the
  control was inherited from may no longer be a part of the pipeline.
  Depending on the hardware, it could be a part of another pipeline, in
  which case it certainly must not be accessible through an unrelated video
  node. As the function is added to the framework, I would expect it to
  handle such a case correctly.

- I assume it is the responsibility of the caller of this function to ensure
  the device in question will not be powered off whilst the video node is
  used as another user space interface to such a sub-device. If the driver
  uses the generic PM functions in the same file, this works, but it still
  has to be documented.

> +{
> + struct media_device *mdev = start_entity->graph_obj.mdev;
> + struct media_entity *entity;
> + struct media_graph graph;
> + struct v4l2_subdev *sd;
> + int ret;
> +
> + ret = media_graph_walk_init(, mdev);
> + if (ret)
> + return ret;
> +
> + media_graph_walk_start(, start_entity);
> +
> + while ((entity = media_graph_walk_next())) {
> + if (!is_media_entity_v4l2_subdev(entity))
> + continue;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
> + sd->ctrl_handler,
> + NULL);
> + if (ret)
> + break;
> + }
> +
> + media_graph_walk_cleanup();
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(__v4l2_pipeline_inherit_controls);
> +
> +int v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +struct media_entity *start_entity)
> +{
> + struct media_device *mdev = start_entity->graph_obj.mdev;
> + int ret;
> +
> + mutex_lock(>graph_mutex);
> + ret = __v4l2_pipeline_inherit_controls(vfd, start_entity);
> + mutex_unlock(>graph_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_pipeline_inherit_controls);
> +
>  /* 
> -
>   * Pipeline power management
>   *
> diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h
> index 2634d9d..9848e77 100644
> --- a/include/media/v4l2-mc.h
> +++ b/include/media/v4l2-mc.h
> @@ -171,6 +171,17 @@ void v4l_disable_media_source(struct video_device *vdev);
>   */
>  int v4l_vb2q_enable_media_source(struct vb2_queue *q);
>  
> +/**
> + * v4l2_pipeline_inherit_controls - Add the v4l2 controls from all
> + *   subdev entities in a pipeline to
> + *   the given video device.
> + * @vfd: the video device
> + * @start_entity: Starting entity
> + */
> +int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +  struct media_entity *start_entity);
> +int v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +struct media_entity *start_entity);
>  
>  /**
>   * v4l2_pipeline_pm_use - Update the use count of an entity
> @@ -231,6 +242,20 @@ static inline int v4l_vb2q_enable_media_source(struct 
> vb2_queue *q)
>   return 0;
>  }
>  
> +static inline int __v4l2_pipeline_inherit_controls(
> + struct video_device *vfd,
> + struct media_entity *start_entity)
> +{
> + return 0;
> +}
> +
> +static inline int v4l2_pipeline_inherit_controls(
> + struct video_device *vfd,
> + struct media_entity *start_entity)
> +{
> + return 0;
> +}
> +
>  static inline int v4l2_pipeline_pm_use(struct media_entity *entity, int use)
>  {
>   return 0;

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH 2/2] dt-bindings: display: imx: entry for LAUSCR

2017-03-02 Thread Rob Herring

On Mon, Feb 27, 2017 at 11:56:42AM +0100, Martin Kaiser wrote:
> Allow setting the LCDC AUS Mode Control Register from the device tree.
> This setting is optional, the register is available only on imx21 and
> compatible chipsets.
> 
> Signed-off-by: Martin Kaiser 
> ---
>  Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt 
> b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
> index 7a5c0e2..bd5077f 100644
> --- a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
> @@ -13,6 +13,8 @@ Required nodes:
>   Additional, the display node has to define properties:
>   - bits-per-pixel: Bits per pixel
>   - fsl,pcr: LCDC PCR value
> + A display node may optionally define
> + - fsl,lauscr: LCDC AUS Mode Control Register value (only for imx21)

Looks like we already got one, but generally we don't just put magic 
register values in the DT. What does this register control?

Re: [PATCH 2/2] dt-bindings: display: imx: entry for LAUSCR

2017-03-02 Thread Rob Herring

On Mon, Feb 27, 2017 at 11:56:42AM +0100, Martin Kaiser wrote:
> Allow setting the LCDC AUS Mode Control Register from the device tree.
> This setting is optional, the register is available only on imx21 and
> compatible chipsets.
> 
> Signed-off-by: Martin Kaiser 
> ---
>  Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt 
> b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
> index 7a5c0e2..bd5077f 100644
> --- a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
> @@ -13,6 +13,8 @@ Required nodes:
>   Additional, the display node has to define properties:
>   - bits-per-pixel: Bits per pixel
>   - fsl,pcr: LCDC PCR value
> + A display node may optionally define
> + - fsl,lauscr: LCDC AUS Mode Control Register value (only for imx21)

Looks like we already got one, but generally we don't just put magic 
register values in the DT. What does this register control?

Re: [PATCH v2 2/3] printk: rename selected_console -> preferred_console

2017-03-02 Thread Sergey Senozhatsky

On (03/02/17 10:01), Steven Rostedt wrote:
> > The variable selected_console is set in __add_preferred_console()
> > to point to the last console parameter that was added to the
> > console_cmdline array.
> > 
> > Rename it to preferred_console so that the name reflects the usage.
> 
> As I said previously, I prefer "selected_console" but since
> "__add_preferred_console()" sets it, I'm fine with this change.
> Although, I would probably have changed that function to
> "__add_selected_console()" :)
> 
> Acked-by: Steven Rostedt (VMware) 

agree, I'd *probably* do a function rename. just 3 lines of code to
touch (afaics).

Reviewed-by: Sergey Senozhatsky 

-ss

Re: [PATCH v2 2/3] printk: rename selected_console -> preferred_console

2017-03-02 Thread Sergey Senozhatsky

On (03/02/17 10:01), Steven Rostedt wrote:
> > The variable selected_console is set in __add_preferred_console()
> > to point to the last console parameter that was added to the
> > console_cmdline array.
> > 
> > Rename it to preferred_console so that the name reflects the usage.
> 
> As I said previously, I prefer "selected_console" but since
> "__add_preferred_console()" sets it, I'm fine with this change.
> Although, I would probably have changed that function to
> "__add_selected_console()" :)
> 
> Acked-by: Steven Rostedt (VMware) 

agree, I'd *probably* do a function rename. just 3 lines of code to
touch (afaics).

Reviewed-by: Sergey Senozhatsky 

-ss

Re: [PATCH V5 6/6] proc: show MADV_FREE pages info in smaps

2017-03-02 Thread Michal Hocko

On Thu 02-03-17 09:01:01, Johannes Weiner wrote:
> On Wed, Mar 01, 2017 at 07:57:35PM +0100, Michal Hocko wrote:
> > On Wed 01-03-17 13:31:49, Johannes Weiner wrote:
[...]
> > > The error when reading a specific smaps should be completely ok.
> > > 
> > > In numbers: even if your process is madvising from 16 different CPUs,
> > > the error in its smaps file will peak at 896K in the worst case. That
> > > level of concurrency tends to come with much bigger memory quantities
> > > for that amount of error to matter.
> > 
> > It is still an unexpected behavior IMHO and an implementation detail
> > which leaks to the userspace.
> 
> We have per-cpu fuzz in every single vmstat counter. Look at
> calculate_normal_threshold() in vmstat.c and the sample thresholds for
> when per-cpu deltas are flushed. In the vast majority of machines, the
> per-cpu error in these counters is much higher than what we get with
> pagevecs holding back a few pages.

Yes but vmstat counters have a different usecase AFAIK. You mostly look
at those when debugging or watching the system. /proc//smaps is
quite often used to do per task metrics which are then used for some
decision making so it should be less fuzzy if that is possible.

> It's not that I think you're wrong: it *is* an implementation detail.
> But we take a bit of incoherency from batching all over the place, so
> it's a little odd to take a stand over this particular instance of it
> - whether demanding that it'd be fixed, or be documented, which would
> only suggest to users that this is special when it really isn't etc.

I am not aware of other counter printed in smaps that would suffer from
the same problem, but I haven't checked too deeply so I might be wrong. 

Anyway it seems that I am alone in my position so I will not insist.
If we have any bug report then we can still fix it.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH V5 6/6] proc: show MADV_FREE pages info in smaps

2017-03-02 Thread Michal Hocko

On Thu 02-03-17 09:01:01, Johannes Weiner wrote:
> On Wed, Mar 01, 2017 at 07:57:35PM +0100, Michal Hocko wrote:
> > On Wed 01-03-17 13:31:49, Johannes Weiner wrote:
[...]
> > > The error when reading a specific smaps should be completely ok.
> > > 
> > > In numbers: even if your process is madvising from 16 different CPUs,
> > > the error in its smaps file will peak at 896K in the worst case. That
> > > level of concurrency tends to come with much bigger memory quantities
> > > for that amount of error to matter.
> > 
> > It is still an unexpected behavior IMHO and an implementation detail
> > which leaks to the userspace.
> 
> We have per-cpu fuzz in every single vmstat counter. Look at
> calculate_normal_threshold() in vmstat.c and the sample thresholds for
> when per-cpu deltas are flushed. In the vast majority of machines, the
> per-cpu error in these counters is much higher than what we get with
> pagevecs holding back a few pages.

Yes but vmstat counters have a different usecase AFAIK. You mostly look
at those when debugging or watching the system. /proc//smaps is
quite often used to do per task metrics which are then used for some
decision making so it should be less fuzzy if that is possible.

> It's not that I think you're wrong: it *is* an implementation detail.
> But we take a bit of incoherency from batching all over the place, so
> it's a little odd to take a stand over this particular instance of it
> - whether demanding that it'd be fixed, or be documented, which would
> only suggest to users that this is special when it really isn't etc.

I am not aware of other counter printed in smaps that would suffer from
the same problem, but I haven't checked too deeply so I might be wrong. 

Anyway it seems that I am alone in my position so I will not insist.
If we have any bug report then we can still fix it.

-- 
Michal Hocko
SUSE Labs

Re: [Outreachy kernel] [PATCH v2] staging: speakup: Comparison to NULL could be written

2017-03-02 Thread Alison Schofield

On Thu, Mar 02, 2017 at 02:13:02PM +0530, Arushi Singhal wrote:
> Fixed coding style for null comparisons in speakup driver to be more
> consistant with the rest of the kernel coding style.
> 
> Signed-off-by: Arushi Singhal 
> ---
>  changes in v2
>  - fixed coding style error and upto the coding style.

Hi Arushi,

Take another look at Joe's message about checkpatch on the patch
file. Looks like you missed that.

Here's some tips on styling your commit and log messages:

You've probably seen feedback of putting the message into
the "imperative".  ie...it's as if you are directing/commanding
what is to happen. Best way I've found to get that to sink in
is to look at your predecessors...and look at more than one
because poor messages do sneak in occasionally.

For this one, I might do this:

> staging/speakup$ gitpretty *.c | grep NULL
> (my alias: alias gitpretty='git log --pretty=oneline --abbrev-commit')
> 
> d3da1cb staging: speakup: (coding style) Rewrite comparisons to NULL
> a90624c Staging: speakup: kobjects.c: Remove explicit NULL comparison
> 114885e Staging: speakup: serialio.c: Remove explicit NULL comparison
> 562c4798 Staging: speakup: devsynth.c: Remove explicit NULL comparison
> ff52fc3 Staging: speakup: varhandlers.c: Remove explicit NULL comparison
> 
Then, go further into one that looks like it might match your change:

> staging/speakup$ git log a90624c
> commit a90624cf253cc74e9464b42d54aa4825575edefe
> Author: Shraddha Barke 
> Date:   Fri Sep 11 11:32:28 2015 +0530
>  
> Staging: speakup: kobjects.c: Remove explicit NULL comparison
>  >
> Remove explicit NULL comparison and write it in its simpler form.
> 
> 

This would give me confidence in the commit message and log.
And, since I tend toward the obsessive ;), if the next day I do this
fix in another directory, I would repeat this process on that directory
and file because styles can vary by driver/subsystem.  Perhaps not on
such a simple fix, but more so as you dive deeper.

alisons

> 
>  drivers/staging/speakup/fakekey.c  |  2 +-
>  drivers/staging/speakup/kobjects.c |  2 +-
>  drivers/staging/speakup/main.c | 38 
> +++---
>  3 files changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/staging/speakup/fakekey.c 
> b/drivers/staging/speakup/fakekey.c
> index d76da0a1382c..294c74b47224 100644
> --- a/drivers/staging/speakup/fakekey.c
> +++ b/drivers/staging/speakup/fakekey.c
> @@ -56,7 +56,7 @@ int speakup_add_virtual_keyboard(void)
>  
>  void speakup_remove_virtual_keyboard(void)
>  {
> - if (virt_keyboard != NULL) {
> + if (virt_keyboard) {
>   input_unregister_device(virt_keyboard);
>   virt_keyboard = NULL;
>   }
> diff --git a/drivers/staging/speakup/kobjects.c 
> b/drivers/staging/speakup/kobjects.c
> index 5d871ec3693c..2fef55569bfd 100644
> --- a/drivers/staging/speakup/kobjects.c
> +++ b/drivers/staging/speakup/kobjects.c
> @@ -391,7 +391,7 @@ static ssize_t synth_store(struct kobject *kobj, struct 
> kobj_attribute *attr,
>   len--;
>   new_synth_name[len] = '\0';
>   spk_strlwr(new_synth_name);
> - if ((synth != NULL) && (!strcmp(new_synth_name, synth->name))) {
> + if (synth && !strcmp(new_synth_name, synth->name)) {
>   pr_warn("%s already in use\n", new_synth_name);
>   } else if (synth_init(new_synth_name) != 0) {
>   pr_warn("failed to init synth %s\n", new_synth_name);
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index c2f70ef5b9b3..a12ec2b061fe 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -299,7 +299,7 @@ static void speakup_shut_up(struct vc_data *vc)
>   spk_shut_up |= 0x01;
>   spk_parked &= 0xfe;
>   speakup_date(vc);
> - if (synth != NULL)
> + if (synth)
>   spk_do_flush();
>  }
>  
> @@ -441,7 +441,7 @@ static void speak_char(u_char ch)
>   synth_printf("%s", spk_str_caps_stop);
>   return;
>   }
> - if (cp == NULL) {
> + if (!cp) {
>   pr_info("speak_char: cp == NULL!\n");
>   return;
>   }
> @@ -1157,7 +1157,7 @@ static void do_handle_shift(struct vc_data *vc, u_char 
> value, char up_flag)
>  {
>   unsigned long flags;
>  
> - if (synth == NULL || up_flag || spk_killed)
> + if (!synth || up_flag || spk_killed)
>   return;
>   spin_lock_irqsave(_info.spinlock, flags);
>   if (cursor_track == read_all_mode) {
> @@ -1195,7 +1195,7 @@ static void do_handle_latin(struct vc_data *vc, u_char 
> value, char up_flag)
>   spin_unlock_irqrestore(_info.spinlock, flags);
>   return;
>   }
> - if (synth == NULL || spk_killed) {
> + if (!synth || spk_killed) {
>   spin_unlock_irqrestore(_info.spinlock, flags);
>   return;
>   }
> @@

Re: [Outreachy kernel] [PATCH v2] staging: speakup: Comparison to NULL could be written

2017-03-02 Thread Alison Schofield

On Thu, Mar 02, 2017 at 02:13:02PM +0530, Arushi Singhal wrote:
> Fixed coding style for null comparisons in speakup driver to be more
> consistant with the rest of the kernel coding style.
> 
> Signed-off-by: Arushi Singhal 
> ---
>  changes in v2
>  - fixed coding style error and upto the coding style.

Hi Arushi,

Take another look at Joe's message about checkpatch on the patch
file. Looks like you missed that.

Here's some tips on styling your commit and log messages:

You've probably seen feedback of putting the message into
the "imperative".  ie...it's as if you are directing/commanding
what is to happen. Best way I've found to get that to sink in
is to look at your predecessors...and look at more than one
because poor messages do sneak in occasionally.

For this one, I might do this:

> staging/speakup$ gitpretty *.c | grep NULL
> (my alias: alias gitpretty='git log --pretty=oneline --abbrev-commit')
> 
> d3da1cb staging: speakup: (coding style) Rewrite comparisons to NULL
> a90624c Staging: speakup: kobjects.c: Remove explicit NULL comparison
> 114885e Staging: speakup: serialio.c: Remove explicit NULL comparison
> 562c4798 Staging: speakup: devsynth.c: Remove explicit NULL comparison
> ff52fc3 Staging: speakup: varhandlers.c: Remove explicit NULL comparison
> 
Then, go further into one that looks like it might match your change:

> staging/speakup$ git log a90624c
> commit a90624cf253cc74e9464b42d54aa4825575edefe
> Author: Shraddha Barke 
> Date:   Fri Sep 11 11:32:28 2015 +0530
>  
> Staging: speakup: kobjects.c: Remove explicit NULL comparison
>  >
> Remove explicit NULL comparison and write it in its simpler form.
> 
> 

This would give me confidence in the commit message and log.
And, since I tend toward the obsessive ;), if the next day I do this
fix in another directory, I would repeat this process on that directory
and file because styles can vary by driver/subsystem.  Perhaps not on
such a simple fix, but more so as you dive deeper.

alisons

> 
>  drivers/staging/speakup/fakekey.c  |  2 +-
>  drivers/staging/speakup/kobjects.c |  2 +-
>  drivers/staging/speakup/main.c | 38 
> +++---
>  3 files changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/staging/speakup/fakekey.c 
> b/drivers/staging/speakup/fakekey.c
> index d76da0a1382c..294c74b47224 100644
> --- a/drivers/staging/speakup/fakekey.c
> +++ b/drivers/staging/speakup/fakekey.c
> @@ -56,7 +56,7 @@ int speakup_add_virtual_keyboard(void)
>  
>  void speakup_remove_virtual_keyboard(void)
>  {
> - if (virt_keyboard != NULL) {
> + if (virt_keyboard) {
>   input_unregister_device(virt_keyboard);
>   virt_keyboard = NULL;
>   }
> diff --git a/drivers/staging/speakup/kobjects.c 
> b/drivers/staging/speakup/kobjects.c
> index 5d871ec3693c..2fef55569bfd 100644
> --- a/drivers/staging/speakup/kobjects.c
> +++ b/drivers/staging/speakup/kobjects.c
> @@ -391,7 +391,7 @@ static ssize_t synth_store(struct kobject *kobj, struct 
> kobj_attribute *attr,
>   len--;
>   new_synth_name[len] = '\0';
>   spk_strlwr(new_synth_name);
> - if ((synth != NULL) && (!strcmp(new_synth_name, synth->name))) {
> + if (synth && !strcmp(new_synth_name, synth->name)) {
>   pr_warn("%s already in use\n", new_synth_name);
>   } else if (synth_init(new_synth_name) != 0) {
>   pr_warn("failed to init synth %s\n", new_synth_name);
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index c2f70ef5b9b3..a12ec2b061fe 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -299,7 +299,7 @@ static void speakup_shut_up(struct vc_data *vc)
>   spk_shut_up |= 0x01;
>   spk_parked &= 0xfe;
>   speakup_date(vc);
> - if (synth != NULL)
> + if (synth)
>   spk_do_flush();
>  }
>  
> @@ -441,7 +441,7 @@ static void speak_char(u_char ch)
>   synth_printf("%s", spk_str_caps_stop);
>   return;
>   }
> - if (cp == NULL) {
> + if (!cp) {
>   pr_info("speak_char: cp == NULL!\n");
>   return;
>   }
> @@ -1157,7 +1157,7 @@ static void do_handle_shift(struct vc_data *vc, u_char 
> value, char up_flag)
>  {
>   unsigned long flags;
>  
> - if (synth == NULL || up_flag || spk_killed)
> + if (!synth || up_flag || spk_killed)
>   return;
>   spin_lock_irqsave(_info.spinlock, flags);
>   if (cursor_track == read_all_mode) {
> @@ -1195,7 +1195,7 @@ static void do_handle_latin(struct vc_data *vc, u_char 
> value, char up_flag)
>   spin_unlock_irqrestore(_info.spinlock, flags);
>   return;
>   }
> - if (synth == NULL || spk_killed) {
> + if (!synth || spk_killed) {
>   spin_unlock_irqrestore(_info.spinlock, flags);
>   return;
>   }
> @@ -1279,7 +1279,7 @@ void spk_reset_default_chars(void)
>  
>

Re: [tpmdd-devel] [PATCH v2] tpm: Apply a sane minimum adapterlimit value for retransmission.

2017-03-02 Thread Enric Balletbo i Serra



On 02/03/17 14:43, Peter Huewe wrote:
> 
> 
> Am 2. März 2017 13:55:43 MEZ schrieb Jarkko Sakkinen 
> :
>> On Wed, Mar 01, 2017 at 04:36:17PM +0100, Enric Balletbo i Serra wrote:
>>> From: Bryan Freed 
>>>
>>> When the I2C Infineon part is attached to an I2C adapter that imposes
>>> a size limitation, large requests will fail with -EOPNOTSUPP. Retry
>>> them with a sane minimum size without re-issuing the 0x05 command
>>> as this appears to occasionally put the TPM in a bad state.
>>
>> What is 0x05 command?
> 0x05 is the address of the fifo.
> I honestly think that it needs toll be repeated after a stop condition.
> I'll look that up.
> 
>>
>> /Jarkko
>>
>>> Signed-off-by: Bryan Freed 
>>> [rework the patch to adapt to the feedback received]
>>> Signed-off-by: Enric Balletbo i Serra 
>>> ---
>>> This is a reworked version of the original patch based on the
>>> suggestion made by Wolfram Sang to simply fall back to a sane minimum
>>> when the maximum fails.
>>>

>> Hi Enric
>>
>> Maybe you should remember that you need to use smaller transfers? If
>> you don't remember, but use the full size message every time and only
>> drop back on error, the i2c core is going to log rate limited
>> messages. By remembering, there will only be one such message in the
>> log.
>>

Maybe I did not explain well but this is what the code does, when i2c-core 
fails with -EOPNOTSUPP because the msg is too long for this adapter it loop 
with a smaller chunk of fixed size, so you only see the i2c-core message once.

>>Andrew
>>> Changes since v1:
>>>  - Check the correct return value (-EOPNOTSUPP instead of -EINVAL)
>>>  - Fall back len to I2C_SMBUS_BLOCK_MAX if fails.
>>>
>>>  drivers/char/tpm/tpm_i2c_infineon.c | 45
>> +
>>>  1 file changed, 26 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/char/tpm/tpm_i2c_infineon.c
>> b/drivers/char/tpm/tpm_i2c_infineon.c
>>> index 62ee44e..88bf947 100644
>>> --- a/drivers/char/tpm/tpm_i2c_infineon.c
>>> +++ b/drivers/char/tpm/tpm_i2c_infineon.c
>>> @@ -107,39 +107,27 @@ static int iic_tpm_read(u8 addr, u8 *buffer,
>> size_t len)
>>> .len = len,
>>> .buf = buffer
>>> };
>>> -   struct i2c_msg msgs[] = {msg1, msg2};
>>>  
>>> int rc = 0;
>>> int count;
>>> +   unsigned int adapterlimit = len;
>>>  
>>> /* Lock the adapter for the duration of the whole sequence. */
>>> if (!tpm_dev.client->adapter->algo->master_xfer)
>>> return -EOPNOTSUPP;
>>> i2c_lock_adapter(tpm_dev.client->adapter);
>>>  
>>> -   if (tpm_dev.chip_type == SLB9645) {
> Why are you / bryan removing this code path here?
> I put it there for a good reason (i.e. faster transfers)
> 

Good question, I might be wrong as the original code is not mine but I think 
that is for safety.

I'm wondering what will happen if you connect a SLB9645 with a bus that has the 
max_read_len quirk defined and you try to read a message greater than the 
max_read_len. In such case __i2c_transfer will fail with -EOPNOTSUPP and do not 
work.

Thinking about this maybe we can do this here:

if (tpm_dev.chip_type == SLB9645) {
   /* fast transfer */
   rc = __i2c...
   ...
} else {
   /* normal transfer */
   rc = __i2c...
   ...
}

/* If the transfer failed try with chunks of 32 */
if (rc == -EOPNOTSUPP)
  rc = __i2c...



> Thanks,
> Peter
>>> -   /* use a combined read for newer chips
>>> -* unfortunately the smbus functions are not suitable due to
>>> -* the 32 byte limit of the smbus.
>>> -* retries should usually not be needed, but are kept just to
>>> -* be on the safe side.
>>> -*/
>>> -   for (count = 0; count < MAX_COUNT; count++) {
>>> -   rc = __i2c_transfer(tpm_dev.client->adapter, msgs, 2);
>>> -   if (rc > 0)
>>> -   break;  /* break here to skip sleep */
>>> -   usleep_range(SLEEP_DURATION_LOW, SLEEP_DURATION_HI);
>>> -   }
>>> -   } else {
>>> +   /* Expect to send one command message and one data message, but
>>> +* support looping over each or both if necessary.
>>> +*/
>>> +   while (len > 0) {if (rc == -EOPNOTSUPP)
>>> /* slb9635 protocol should work in all cases */
>>> for (count = 0; count < MAX_COUNT; count++) {
>>> rc = __i2c_transfer(tpm_dev.client->adapter, , 1);
>>> if (rc > 0)
>>> -   break;  /* break here to skip sleep */
>>> -
>>> +   break;
>>> usleep_range(SLEEP_DURATION_LOW, SLEEP_DURATION_HI);
>>> }
>>> -
>>> if (rc <= 0)
>>> goto out;
>>>  
>>> @@ -148,11 +136,30 @@ static int iic_tpm_read(u8 addr, u8 *buffer,
>> size_t len)
>>>  * retrieving the

Re: [tpmdd-devel] [PATCH v2] tpm: Apply a sane minimum adapterlimit value for retransmission.

2017-03-02 Thread Enric Balletbo i Serra



On 02/03/17 14:43, Peter Huewe wrote:
> 
> 
> Am 2. März 2017 13:55:43 MEZ schrieb Jarkko Sakkinen 
> :
>> On Wed, Mar 01, 2017 at 04:36:17PM +0100, Enric Balletbo i Serra wrote:
>>> From: Bryan Freed 
>>>
>>> When the I2C Infineon part is attached to an I2C adapter that imposes
>>> a size limitation, large requests will fail with -EOPNOTSUPP. Retry
>>> them with a sane minimum size without re-issuing the 0x05 command
>>> as this appears to occasionally put the TPM in a bad state.
>>
>> What is 0x05 command?
> 0x05 is the address of the fifo.
> I honestly think that it needs toll be repeated after a stop condition.
> I'll look that up.
> 
>>
>> /Jarkko
>>
>>> Signed-off-by: Bryan Freed 
>>> [rework the patch to adapt to the feedback received]
>>> Signed-off-by: Enric Balletbo i Serra 
>>> ---
>>> This is a reworked version of the original patch based on the
>>> suggestion made by Wolfram Sang to simply fall back to a sane minimum
>>> when the maximum fails.
>>>

>> Hi Enric
>>
>> Maybe you should remember that you need to use smaller transfers? If
>> you don't remember, but use the full size message every time and only
>> drop back on error, the i2c core is going to log rate limited
>> messages. By remembering, there will only be one such message in the
>> log.
>>

Maybe I did not explain well but this is what the code does, when i2c-core 
fails with -EOPNOTSUPP because the msg is too long for this adapter it loop 
with a smaller chunk of fixed size, so you only see the i2c-core message once.

>>Andrew
>>> Changes since v1:
>>>  - Check the correct return value (-EOPNOTSUPP instead of -EINVAL)
>>>  - Fall back len to I2C_SMBUS_BLOCK_MAX if fails.
>>>
>>>  drivers/char/tpm/tpm_i2c_infineon.c | 45
>> +
>>>  1 file changed, 26 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/char/tpm/tpm_i2c_infineon.c
>> b/drivers/char/tpm/tpm_i2c_infineon.c
>>> index 62ee44e..88bf947 100644
>>> --- a/drivers/char/tpm/tpm_i2c_infineon.c
>>> +++ b/drivers/char/tpm/tpm_i2c_infineon.c
>>> @@ -107,39 +107,27 @@ static int iic_tpm_read(u8 addr, u8 *buffer,
>> size_t len)
>>> .len = len,
>>> .buf = buffer
>>> };
>>> -   struct i2c_msg msgs[] = {msg1, msg2};
>>>  
>>> int rc = 0;
>>> int count;
>>> +   unsigned int adapterlimit = len;
>>>  
>>> /* Lock the adapter for the duration of the whole sequence. */
>>> if (!tpm_dev.client->adapter->algo->master_xfer)
>>> return -EOPNOTSUPP;
>>> i2c_lock_adapter(tpm_dev.client->adapter);
>>>  
>>> -   if (tpm_dev.chip_type == SLB9645) {
> Why are you / bryan removing this code path here?
> I put it there for a good reason (i.e. faster transfers)
> 

Good question, I might be wrong as the original code is not mine but I think 
that is for safety.

I'm wondering what will happen if you connect a SLB9645 with a bus that has the 
max_read_len quirk defined and you try to read a message greater than the 
max_read_len. In such case __i2c_transfer will fail with -EOPNOTSUPP and do not 
work.

Thinking about this maybe we can do this here:

if (tpm_dev.chip_type == SLB9645) {
   /* fast transfer */
   rc = __i2c...
   ...
} else {
   /* normal transfer */
   rc = __i2c...
   ...
}

/* If the transfer failed try with chunks of 32 */
if (rc == -EOPNOTSUPP)
  rc = __i2c...



> Thanks,
> Peter
>>> -   /* use a combined read for newer chips
>>> -* unfortunately the smbus functions are not suitable due to
>>> -* the 32 byte limit of the smbus.
>>> -* retries should usually not be needed, but are kept just to
>>> -* be on the safe side.
>>> -*/
>>> -   for (count = 0; count < MAX_COUNT; count++) {
>>> -   rc = __i2c_transfer(tpm_dev.client->adapter, msgs, 2);
>>> -   if (rc > 0)
>>> -   break;  /* break here to skip sleep */
>>> -   usleep_range(SLEEP_DURATION_LOW, SLEEP_DURATION_HI);
>>> -   }
>>> -   } else {
>>> +   /* Expect to send one command message and one data message, but
>>> +* support looping over each or both if necessary.
>>> +*/
>>> +   while (len > 0) {if (rc == -EOPNOTSUPP)
>>> /* slb9635 protocol should work in all cases */
>>> for (count = 0; count < MAX_COUNT; count++) {
>>> rc = __i2c_transfer(tpm_dev.client->adapter, , 1);
>>> if (rc > 0)
>>> -   break;  /* break here to skip sleep */
>>> -
>>> +   break;
>>> usleep_range(SLEEP_DURATION_LOW, SLEEP_DURATION_HI);
>>> }
>>> -
>>> if (rc <= 0)
>>> goto out;
>>>  
>>> @@ -148,11 +136,30 @@ static int iic_tpm_read(u8 addr, u8 *buffer,
>> size_t len)
>>>  * retrieving the data
>>>  */
>>> for (count = 0; count < MAX_COUNT; count++) {
>>> +

Re: [PATCHv2 1/2] mfd: cpcap: implement irq sense helper

2017-03-02 Thread Tony Lindgren

* Sebastian Reichel  [170301 16:24]:
> CPCAP can sense if IRQ is currently set or not. This
> functionality is required for a few subdevices, such
> as the power button and usb phy modules.
> 
> Signed-off-by: Sebastian Reichel 
> ---
> Changes since PATCHv1:
>  - Newly introduced patch
> ---
>  drivers/mfd/motorola-cpcap.c   | 25 +
>  include/linux/mfd/motorola-cpcap.h |  2 ++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> index 6aeada7d7ce5..b2a53750d579 100644
> --- a/drivers/mfd/motorola-cpcap.c
> +++ b/drivers/mfd/motorola-cpcap.c
> @@ -32,6 +32,31 @@ struct cpcap_ddata {
>   struct regmap *regmap;
>  };
>  
> +static int cpcap_sense_irq(struct regmap *regmap, int irq)
> +{
> + int reg = CPCAP_REG_INTS1 + (irq / 16) * 4;
> + int mask = 1 << (irq % 16);
> + int err, val;
> +
> + if (irq < 0 || irq > 64)
> + return -EINVAL;
> +
> + err = regmap_read(regmap, reg, );
> + if (err)
> + return err;
> +
> + return !!(val & mask);
> +}
> +
> +int cpcap_sense_virq(struct regmap *regmap, int virq)
> +{
> + struct regmap_irq_chip_data *d = irq_get_chip_data(virq);
> + int base = regmap_irq_chip_get_base(d);
> +
> + return cpcap_sense_irq(regmap, virq - base);
> +}
> +EXPORT_SYMBOL_GPL(cpcap_sense_irq);

You have a typo here, should be cpcap_sense_virq for the exported one :)

Other than that my ack is still valid.

Regards,

Tony

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

2017-03-02 Thread Michal Hocko

I've just realized that Darrick was not on the CC list. Let's add him.
I believe this patch should go in in the current cycle because
5d17a73a2ebe was merged in this merge window and it can be abused...

The other patch [1] is not that urgent.

[1] http://lkml.kernel.org/r/20170302154541.16155-2-mho...@kernel.org

On Thu 02-03-17 16:45:40, Michal Hocko wrote:
> From: Michal Hocko 
> 
> Even though kmem_zalloc_greedy is documented it might fail the current
> code doesn't really implement this properly and loops on the smallest
> allowed size for ever. This is a problem because vzalloc might fail
> permanently - we might run out of vmalloc space or since 5d17a73a2ebe
> ("vmalloc: back off when the current task is killed") when the current
> task is killed. The later one makes the failure scenario much more
> probable than it used to be because it makes vmalloc() failures
> permanent for tasks with fatal signals pending.. Fix this by bailing out
> if the minimum size request failed.
> 
> This has been noticed by a hung generic/269 xfstest by Xiong Zhou.
> 
> fsstress: vmalloc: allocation failure, allocated 12288 of 20480 bytes, 
> mode:0x14080c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_ZERO), nodemask=(null)
> fsstress cpuset=/ mems_allowed=0-1
> CPU: 1 PID: 23460 Comm: fsstress Not tainted 4.10.0-master-45554b2+ #21
> Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016
> Call Trace:
>  dump_stack+0x63/0x87
>  warn_alloc+0x114/0x1c0
>  ? alloc_pages_current+0x88/0x120
>  __vmalloc_node_range+0x250/0x2a0
>  ? kmem_zalloc_greedy+0x2b/0x40 [xfs]
>  ? free_hot_cold_page+0x21f/0x280
>  vzalloc+0x54/0x60
>  ? kmem_zalloc_greedy+0x2b/0x40 [xfs]
>  kmem_zalloc_greedy+0x2b/0x40 [xfs]
>  xfs_bulkstat+0x11b/0x730 [xfs]
>  ? xfs_bulkstat_one_int+0x340/0x340 [xfs]
>  ? selinux_capable+0x20/0x30
>  ? security_capable+0x48/0x60
>  xfs_ioc_bulkstat+0xe4/0x190 [xfs]
>  xfs_file_ioctl+0x9dd/0xad0 [xfs]
>  ? do_filp_open+0xa5/0x100
>  do_vfs_ioctl+0xa7/0x5e0
>  SyS_ioctl+0x79/0x90
>  do_syscall_64+0x67/0x180
>  entry_SYSCALL64_slow_path+0x25/0x25
> 
> fsstress keeps looping inside kmem_zalloc_greedy without any way out
> because vmalloc keeps failing due to fatal_signal_pending.
> 
> Reported-by: Xiong Zhou 
> Analyzed-by: Tetsuo Handa 
> Signed-off-by: Michal Hocko 
> ---
>  fs/xfs/kmem.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c
> index 339c696bbc01..ee95f5c6db45 100644
> --- a/fs/xfs/kmem.c
> +++ b/fs/xfs/kmem.c
> @@ -34,6 +34,8 @@ kmem_zalloc_greedy(size_t *size, size_t minsize, size_t 
> maxsize)
>   size_t  kmsize = maxsize;
>  
>   while (!(ptr = vzalloc(kmsize))) {
> + if (kmsize == minsize)
> + break;
>   if ((kmsize >>= 1) <= minsize)
>   kmsize = minsize;
>   }
> -- 
> 2.11.0
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCHv2 1/2] mfd: cpcap: implement irq sense helper

2017-03-02 Thread Tony Lindgren

* Sebastian Reichel  [170301 16:24]:
> CPCAP can sense if IRQ is currently set or not. This
> functionality is required for a few subdevices, such
> as the power button and usb phy modules.
> 
> Signed-off-by: Sebastian Reichel 
> ---
> Changes since PATCHv1:
>  - Newly introduced patch
> ---
>  drivers/mfd/motorola-cpcap.c   | 25 +
>  include/linux/mfd/motorola-cpcap.h |  2 ++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> index 6aeada7d7ce5..b2a53750d579 100644
> --- a/drivers/mfd/motorola-cpcap.c
> +++ b/drivers/mfd/motorola-cpcap.c
> @@ -32,6 +32,31 @@ struct cpcap_ddata {
>   struct regmap *regmap;
>  };
>  
> +static int cpcap_sense_irq(struct regmap *regmap, int irq)
> +{
> + int reg = CPCAP_REG_INTS1 + (irq / 16) * 4;
> + int mask = 1 << (irq % 16);
> + int err, val;
> +
> + if (irq < 0 || irq > 64)
> + return -EINVAL;
> +
> + err = regmap_read(regmap, reg, );
> + if (err)
> + return err;
> +
> + return !!(val & mask);
> +}
> +
> +int cpcap_sense_virq(struct regmap *regmap, int virq)
> +{
> + struct regmap_irq_chip_data *d = irq_get_chip_data(virq);
> + int base = regmap_irq_chip_get_base(d);
> +
> + return cpcap_sense_irq(regmap, virq - base);
> +}
> +EXPORT_SYMBOL_GPL(cpcap_sense_irq);

You have a typo here, should be cpcap_sense_virq for the exported one :)

Other than that my ack is still valid.

Regards,

Tony

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

2017-03-02 Thread Michal Hocko

I've just realized that Darrick was not on the CC list. Let's add him.
I believe this patch should go in in the current cycle because
5d17a73a2ebe was merged in this merge window and it can be abused...

The other patch [1] is not that urgent.

[1] http://lkml.kernel.org/r/20170302154541.16155-2-mho...@kernel.org

On Thu 02-03-17 16:45:40, Michal Hocko wrote:
> From: Michal Hocko 
> 
> Even though kmem_zalloc_greedy is documented it might fail the current
> code doesn't really implement this properly and loops on the smallest
> allowed size for ever. This is a problem because vzalloc might fail
> permanently - we might run out of vmalloc space or since 5d17a73a2ebe
> ("vmalloc: back off when the current task is killed") when the current
> task is killed. The later one makes the failure scenario much more
> probable than it used to be because it makes vmalloc() failures
> permanent for tasks with fatal signals pending.. Fix this by bailing out
> if the minimum size request failed.
> 
> This has been noticed by a hung generic/269 xfstest by Xiong Zhou.
> 
> fsstress: vmalloc: allocation failure, allocated 12288 of 20480 bytes, 
> mode:0x14080c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_ZERO), nodemask=(null)
> fsstress cpuset=/ mems_allowed=0-1
> CPU: 1 PID: 23460 Comm: fsstress Not tainted 4.10.0-master-45554b2+ #21
> Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/05/2016
> Call Trace:
>  dump_stack+0x63/0x87
>  warn_alloc+0x114/0x1c0
>  ? alloc_pages_current+0x88/0x120
>  __vmalloc_node_range+0x250/0x2a0
>  ? kmem_zalloc_greedy+0x2b/0x40 [xfs]
>  ? free_hot_cold_page+0x21f/0x280
>  vzalloc+0x54/0x60
>  ? kmem_zalloc_greedy+0x2b/0x40 [xfs]
>  kmem_zalloc_greedy+0x2b/0x40 [xfs]
>  xfs_bulkstat+0x11b/0x730 [xfs]
>  ? xfs_bulkstat_one_int+0x340/0x340 [xfs]
>  ? selinux_capable+0x20/0x30
>  ? security_capable+0x48/0x60
>  xfs_ioc_bulkstat+0xe4/0x190 [xfs]
>  xfs_file_ioctl+0x9dd/0xad0 [xfs]
>  ? do_filp_open+0xa5/0x100
>  do_vfs_ioctl+0xa7/0x5e0
>  SyS_ioctl+0x79/0x90
>  do_syscall_64+0x67/0x180
>  entry_SYSCALL64_slow_path+0x25/0x25
> 
> fsstress keeps looping inside kmem_zalloc_greedy without any way out
> because vmalloc keeps failing due to fatal_signal_pending.
> 
> Reported-by: Xiong Zhou 
> Analyzed-by: Tetsuo Handa 
> Signed-off-by: Michal Hocko 
> ---
>  fs/xfs/kmem.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c
> index 339c696bbc01..ee95f5c6db45 100644
> --- a/fs/xfs/kmem.c
> +++ b/fs/xfs/kmem.c
> @@ -34,6 +34,8 @@ kmem_zalloc_greedy(size_t *size, size_t minsize, size_t 
> maxsize)
>   size_t  kmsize = maxsize;
>  
>   while (!(ptr = vzalloc(kmsize))) {
> + if (kmsize == minsize)
> + break;
>   if ((kmsize >>= 1) <= minsize)
>   kmsize = minsize;
>   }
> -- 
> 2.11.0
> 

-- 
Michal Hocko
SUSE Labs

Re: Problem with RSA test from testmgr

2017-03-02 Thread Tadeusz Struk

On 03/01/2017 10:21 PM, Corentin Labbe wrote:
> I am finishing a patch that made testmgr test both (padded and unpadded).

Even if you patch the test vectors there is no guarantee that a user
of the API will always have the plain text padded.
It can be anything between 1 and the key size.
This needs to be the driver who adds padding if needed.
See how other implementations handle it.
Thanks,
-- 
Tadeusz

Re: Problem with RSA test from testmgr

2017-03-02 Thread Tadeusz Struk

On 03/01/2017 10:21 PM, Corentin Labbe wrote:
> I am finishing a patch that made testmgr test both (padded and unpadded).

Even if you patch the test vectors there is no guarantee that a user
of the API will always have the plain text padded.
It can be anything between 1 and the key size.
This needs to be the driver who adds padding if needed.
See how other implementations handle it.
Thanks,
-- 
Tadeusz

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

2017-03-02 Thread Christoph Hellwig

Looks fine,

Reviewed-by: Christoph Hellwig

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

2017-03-02 Thread Christoph Hellwig

Looks fine,

Reviewed-by: Christoph Hellwig

Re: [PATCH v3 2/2] crypto: vmx - Use skcipher for xts fallback

2017-03-02 Thread Herbert Xu

On Wed, Mar 01, 2017 at 11:00:00AM -0300, Paulo Flabiano Smorigo wrote:
> Signed-off-by: Paulo Flabiano Smorigo 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v3 2/2] crypto: vmx - Use skcipher for xts fallback

2017-03-02 Thread Herbert Xu

On Wed, Mar 01, 2017 at 11:00:00AM -0300, Paulo Flabiano Smorigo wrote:
> Signed-off-by: Paulo Flabiano Smorigo 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Problem with RSA test from testmgr

2017-03-02 Thread Tadeusz Struk

Hi Stephan,
On 03/01/2017 10:08 PM, Stephan Müller wrote:
>>  memset(ptextp, 0, 256);
>>  memcpy(ptextp + 64 - 8, ptext_ex, plen);
> I actually have tested that and it did not return the data the kernel 
> implementation would return

It did for me:
Result 64 plen=8
63 1c cd 7b e1 7e e4 de c9 a8 89 a1 74 cb 3c 63 7d 24 ec 83 c3 15 e4 7f 73 05 
34 d1 ec 22 bb 8a 5e 32 39 6d c1 1d 7d 50 3b 9f 7a ad f0 2e 25 53 9f 6e bd 4c 
55 84 0c 9b cf 1a 4b 51 1e 9e 0c 06

Are you sure you are compering this with the fist test vector?
http://lxr.free-electrons.com/source/crypto/testmgr.h#L183

Thanks,
-- 
Tadeusz

Re: Problem with RSA test from testmgr

2017-03-02 Thread Tadeusz Struk

Hi Stephan,
On 03/01/2017 10:08 PM, Stephan Müller wrote:
>>  memset(ptextp, 0, 256);
>>  memcpy(ptextp + 64 - 8, ptext_ex, plen);
> I actually have tested that and it did not return the data the kernel 
> implementation would return

It did for me:
Result 64 plen=8
63 1c cd 7b e1 7e e4 de c9 a8 89 a1 74 cb 3c 63 7d 24 ec 83 c3 15 e4 7f 73 05 
34 d1 ec 22 bb 8a 5e 32 39 6d c1 1d 7d 50 3b 9f 7a ad f0 2e 25 53 9f 6e bd 4c 
55 84 0c 9b cf 1a 4b 51 1e 9e 0c 06

Are you sure you are compering this with the fist test vector?
http://lxr.free-electrons.com/source/crypto/testmgr.h#L183

Thanks,
-- 
Tadeusz

Re: [PATCH 2/2] ASoC: es7134: add dt-bindings for the es7134 dac

2017-03-02 Thread Rob Herring

On Mon, Feb 27, 2017 at 04:47:24PM +0100, Jerome Brunet wrote:
> Signed-off-by: Jerome Brunet 
> ---
>  Documentation/devicetree/bindings/sound/everest,es7134.txt | 10 ++
>  1 file changed, 10 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/everest,es7134.txt

Acked-by: Rob Herring

Re: [PATCH 2/2] ASoC: es7134: add dt-bindings for the es7134 dac

2017-03-02 Thread Rob Herring

On Mon, Feb 27, 2017 at 04:47:24PM +0100, Jerome Brunet wrote:
> Signed-off-by: Jerome Brunet 
> ---
>  Documentation/devicetree/bindings/sound/everest,es7134.txt | 10 ++
>  1 file changed, 10 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/everest,es7134.txt

Acked-by: Rob Herring

Re: Kernel bio layer is sending bio size more than our block device is capable of handling

2017-03-02 Thread Christoph Hellwig

Please post your driver to the linux-block list, and test a recent
kernel.

Re: Kernel bio layer is sending bio size more than our block device is capable of handling

2017-03-02 Thread Christoph Hellwig

Please post your driver to the linux-block list, and test a recent
kernel.

[PATCH] Staging:wilc1000:linux_wlan: Modified the 'if-else' statement

2017-03-02 Thread Georgios Emmanouil

Modified the 'if-else' statement to make it more readable.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/linux_wlan.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 2eebc62..d82f0ff 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -867,15 +867,10 @@ static int wilc_mac_open(struct net_device *ndev)
 wilc_get_vif_idx(vif),
 wl->open_ifcs);
} else {
-   if (memcmp(wl->vif[i ^ 1]->bssid,
-  wl->vif[i ^ 1]->src_addr, 6))
-   wilc_set_wfi_drv_handler(vif,
-wilc_get_vif_idx(vif),
-0);
+   if (memcmp(wl->vif[i ^ 1]->bssid, wl->vif[i ^ 
1]->src_addr, 6))
+   wilc_set_wfi_drv_handler(vif, 
wilc_get_vif_idx(vif), 0);
else
-   wilc_set_wfi_drv_handler(vif,
-wilc_get_vif_idx(vif),
-1);
+   wilc_set_wfi_drv_handler(vif, 
wilc_get_vif_idx(vif), 1);
}
wilc_set_operation_mode(vif, vif->iftype);

--
2.1.4

[PATCH] Staging:wilc1000:linux_wlan: Modified the 'if-else' statement

2017-03-02 Thread Georgios Emmanouil

Modified the 'if-else' statement to make it more readable.

Signed-off-by: Georgios Emmanouil 
---
 drivers/staging/wilc1000/linux_wlan.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 2eebc62..d82f0ff 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -867,15 +867,10 @@ static int wilc_mac_open(struct net_device *ndev)
 wilc_get_vif_idx(vif),
 wl->open_ifcs);
} else {
-   if (memcmp(wl->vif[i ^ 1]->bssid,
-  wl->vif[i ^ 1]->src_addr, 6))
-   wilc_set_wfi_drv_handler(vif,
-wilc_get_vif_idx(vif),
-0);
+   if (memcmp(wl->vif[i ^ 1]->bssid, wl->vif[i ^ 
1]->src_addr, 6))
+   wilc_set_wfi_drv_handler(vif, 
wilc_get_vif_idx(vif), 0);
else
-   wilc_set_wfi_drv_handler(vif,
-wilc_get_vif_idx(vif),
-1);
+   wilc_set_wfi_drv_handler(vif, 
wilc_get_vif_idx(vif), 1);
}
wilc_set_operation_mode(vif, vif->iftype);

--
2.1.4

Re: [PATCH v2 2/2] drm: bridge: Move HPD handling to PHY operations

2017-03-02 Thread Laurent Pinchart

Hi Neil,

Thank you for the patch.

On Thursday 02 Mar 2017 16:29:32 Neil Armstrong wrote:
> The HDMI TX controller support HPD and RXSENSE signaling from the PHY
> via it's STAT0 PHY interface, but some vendor PHYs can manage these
> signals independently from the controller, thus these STAT0 handling
> should be moved to PHY specific operations and become optional.
> 
> The existing STAT0 HPD and RXSENSE handling code is refactored into
> a supplementaty set of default PHY operations that are used automatically
> when the platform glue doesn't provide its own operations.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 134 +---
>  include/drm/bridge/dw_hdmi.h |   8 +++
>  2 files changed, 104 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c index 653ecd7..58dcf7d 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1098,10 +1098,50 @@ static enum drm_connector_status
> dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi, connector_status_connected :
> connector_status_disconnected;
>  }
> 
> +static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> +bool force, bool disabled, bool rxsense)
> +{
> + if (force || disabled || !rxsense)
> + hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
> + else
> + hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
> +}
> +
> +static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* setup HPD and RXSENSE interrupt polarity */
> + hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
> +}
> +
> +static void dw_hdmi_phy_configure_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* enable cable hot plug irq */
> + hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> +}
> +
> +static void dw_hdmi_phy_clear_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* Clear Hotplug interrupts */
> + hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
> + HDMI_IH_PHY_STAT0);
> +}
> +
> +static void dw_hdmi_phy_unmute_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* Unmute Hotplug interrupts */
> + hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | 
HDMI_IH_PHY_STAT0_RX_SENSE),
> + HDMI_IH_MUTE_PHY_STAT0);
> +}

Do we really need all those new operations ? It looks to me like a bit of 
refactoring could help lowering the number of operations. We essentially need

- an init function called at probe time (or likely rather at runtime PM resume 
time when we'll implement runtime PM) 

- an interrupt enable/disable function roughly equivalent to 
dw_hdmi_update_phy_mask()

- a read function to report the detection results called from 
dw_hdmi_connector_detect()

>  static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
>   .init = dw_hdmi_phy_init,
>   .disable = dw_hdmi_phy_disable,
>   .read_hpd = dw_hdmi_phy_read_hpd,
> + .update_hpd = dw_hdmi_phy_update_hpd,
> + .setup_hpd = dw_hdmi_phy_setup_hpd,
> + .configure_hpd = dw_hdmi_phy_configure_hpd,
> + .clear_hpd = dw_hdmi_phy_clear_hpd,
> + .unmute_hpd = dw_hdmi_phy_unmute_hpd,
>  };
> 
>  /* 
> @@ -1507,11 +1547,12 @@ static int dw_hdmi_fb_registered(struct dw_hdmi
> *hdmi) HDMI_PHY_I2CM_CTLINT_ADDR);
> 
>   /* enable cable hot plug irq */
> - hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> + if (hdmi->phy.ops->configure_hpd)
> + hdmi->phy.ops->configure_hpd(hdmi, hdmi->phy.data);
> 
>   /* Clear Hotplug interrupts */
> - hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
> - HDMI_IH_PHY_STAT0);
> + if (hdmi->phy.ops->clear_hpd)
> + hdmi->phy.ops->clear_hpd(hdmi, hdmi->phy.data);

The probe function contains the same code. Let's inline this function into 
probe, group all HPD-related initialization together and extract that into a 
function to keep probe easy to read. I think you can do that in a separate 
patch.

>   return 0;
>  }
> @@ -1622,13 +1663,14 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi
> *hdmi) {
>   u8 old_mask = hdmi->phy_mask;
>
> - if (hdmi->force || hdmi->disabled || !hdmi->rxsense)
> - hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
> - else
> - hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
> + if (hdmi->phy.ops->update_hpd)
> + hdmi->phy.ops->update_hpd(hdmi, hdmi->phy.data,
> +   hdmi->force, hdmi->disabled,
> +   hdmi->rxsense);
> 
> - if (old_mask != hdmi->phy_mask)
> - hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> + if (old_mask != hdmi->phy_mask &&

phy_mask isn't accessible to glue code, so this test will never be true with

Re: [PATCH v2 2/2] drm: bridge: Move HPD handling to PHY operations

2017-03-02 Thread Laurent Pinchart

Hi Neil,

Thank you for the patch.

On Thursday 02 Mar 2017 16:29:32 Neil Armstrong wrote:
> The HDMI TX controller support HPD and RXSENSE signaling from the PHY
> via it's STAT0 PHY interface, but some vendor PHYs can manage these
> signals independently from the controller, thus these STAT0 handling
> should be moved to PHY specific operations and become optional.
> 
> The existing STAT0 HPD and RXSENSE handling code is refactored into
> a supplementaty set of default PHY operations that are used automatically
> when the platform glue doesn't provide its own operations.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 134 +---
>  include/drm/bridge/dw_hdmi.h |   8 +++
>  2 files changed, 104 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c index 653ecd7..58dcf7d 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1098,10 +1098,50 @@ static enum drm_connector_status
> dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi, connector_status_connected :
> connector_status_disconnected;
>  }
> 
> +static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> +bool force, bool disabled, bool rxsense)
> +{
> + if (force || disabled || !rxsense)
> + hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
> + else
> + hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
> +}
> +
> +static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* setup HPD and RXSENSE interrupt polarity */
> + hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
> +}
> +
> +static void dw_hdmi_phy_configure_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* enable cable hot plug irq */
> + hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> +}
> +
> +static void dw_hdmi_phy_clear_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* Clear Hotplug interrupts */
> + hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
> + HDMI_IH_PHY_STAT0);
> +}
> +
> +static void dw_hdmi_phy_unmute_hpd(struct dw_hdmi *hdmi, void *data)
> +{
> + /* Unmute Hotplug interrupts */
> + hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | 
HDMI_IH_PHY_STAT0_RX_SENSE),
> + HDMI_IH_MUTE_PHY_STAT0);
> +}

Do we really need all those new operations ? It looks to me like a bit of 
refactoring could help lowering the number of operations. We essentially need

- an init function called at probe time (or likely rather at runtime PM resume 
time when we'll implement runtime PM) 

- an interrupt enable/disable function roughly equivalent to 
dw_hdmi_update_phy_mask()

- a read function to report the detection results called from 
dw_hdmi_connector_detect()

>  static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
>   .init = dw_hdmi_phy_init,
>   .disable = dw_hdmi_phy_disable,
>   .read_hpd = dw_hdmi_phy_read_hpd,
> + .update_hpd = dw_hdmi_phy_update_hpd,
> + .setup_hpd = dw_hdmi_phy_setup_hpd,
> + .configure_hpd = dw_hdmi_phy_configure_hpd,
> + .clear_hpd = dw_hdmi_phy_clear_hpd,
> + .unmute_hpd = dw_hdmi_phy_unmute_hpd,
>  };
> 
>  /* 
> @@ -1507,11 +1547,12 @@ static int dw_hdmi_fb_registered(struct dw_hdmi
> *hdmi) HDMI_PHY_I2CM_CTLINT_ADDR);
> 
>   /* enable cable hot plug irq */
> - hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> + if (hdmi->phy.ops->configure_hpd)
> + hdmi->phy.ops->configure_hpd(hdmi, hdmi->phy.data);
> 
>   /* Clear Hotplug interrupts */
> - hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
> - HDMI_IH_PHY_STAT0);
> + if (hdmi->phy.ops->clear_hpd)
> + hdmi->phy.ops->clear_hpd(hdmi, hdmi->phy.data);

The probe function contains the same code. Let's inline this function into 
probe, group all HPD-related initialization together and extract that into a 
function to keep probe easy to read. I think you can do that in a separate 
patch.

>   return 0;
>  }
> @@ -1622,13 +1663,14 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi
> *hdmi) {
>   u8 old_mask = hdmi->phy_mask;
>
> - if (hdmi->force || hdmi->disabled || !hdmi->rxsense)
> - hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
> - else
> - hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
> + if (hdmi->phy.ops->update_hpd)
> + hdmi->phy.ops->update_hpd(hdmi, hdmi->phy.data,
> +   hdmi->force, hdmi->disabled,
> +   hdmi->rxsense);
> 
> - if (old_mask != hdmi->phy_mask)
> - hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> + if (old_mask != hdmi->phy_mask &&

phy_mask isn't accessible to glue code, so this test will never be true with 
vendor PHYs.

> +

Re: [PATCH 0/6] cpufreq: schedutil: fixes for flags updates

2017-03-02 Thread Vincent Guittot

On 2 March 2017 at 16:45, Patrick Bellasi  wrote:
> The current version of schedutil has some issues related to the management
> of update flags used by systems with frequency domains spawning multiple CPUs.
>
> Each time a CPU utilisation update is issued by the scheduler a set of flags
> are configured to define (mainly) which class is asking for a utilisation
> update. These flags are then used by the frequency selection policy to
> identify the OPP to choose.
>
> In the current implementation, CPU flags are overridden each time the
> scheduler calls schedutil for an update. Such a behaviour produces issues
> in these scenarios, where we assume CPU1 and CPU2 share the same frequency
> domain:
> a) a RT task which executed on CPU1 can keep the domain at an high frequency
>for a long period of time, even if there are no longer RT tasks on
>CPUs in that domain

Normally this is dropped after a tick.
Nevertheless, there is an issue if the freq_update_delay_ns is shorter
than a tick because of sugov RT thread

> b) a FAIR task co-scheduled in the same CPU of a RT task can override the
>flags configured by the RT task and potentially this can cause an
>unwanted frequency drop
>
> These misbehaviours have been verified using a set of simple rt-app based
> synthetic workloads, running on a ARM's Juno board, and results are
> available in this Notebook [1].
>
> This series proposes a set of fixes for the aforementioned issues as well
> as a small improvement to speedup the selection of the maximum frequency
> when RT tasks enter a CPU.
>
> This series is based on top of today's tip/sched/core and is public available
> from this repository:
>
>   git://www.linux-arm.com/linux-pb eas/schedutil/flags_fixes
>
> Cheers Patrick
>
> [1] https://gist.github.com/d6a21b459a18091b2b058668a550010d
>
> Patrick Bellasi (6):
>   cpufreq: schedutil: reset sg_cpus's flags at IDLE enter
>   cpufreq: schedutil: ignore the sugov kthread for frequencies
> selections
>   cpufreq: schedutil: ensure max frequency while running RT/DL tasks
>   cpufreq: schedutil: relax rate-limiting while running RT/DL tasks
>   cpufreq: schedutil: avoid utilisation update when not necessary
>   sched/rt: fast switch to maximum frequency when RT tasks are scheduled
>
>  include/linux/sched.h|  1 +
>  kernel/sched/cpufreq_schedutil.c | 59 
> ++--
>  kernel/sched/idle_task.c |  4 +++
>  kernel/sched/rt.c| 15 --
>  4 files changed, 68 insertions(+), 11 deletions(-)
>
> --
> 2.7.4
>

Re: [PATCH 0/6] cpufreq: schedutil: fixes for flags updates

2017-03-02 Thread Vincent Guittot

On 2 March 2017 at 16:45, Patrick Bellasi  wrote:
> The current version of schedutil has some issues related to the management
> of update flags used by systems with frequency domains spawning multiple CPUs.
>
> Each time a CPU utilisation update is issued by the scheduler a set of flags
> are configured to define (mainly) which class is asking for a utilisation
> update. These flags are then used by the frequency selection policy to
> identify the OPP to choose.
>
> In the current implementation, CPU flags are overridden each time the
> scheduler calls schedutil for an update. Such a behaviour produces issues
> in these scenarios, where we assume CPU1 and CPU2 share the same frequency
> domain:
> a) a RT task which executed on CPU1 can keep the domain at an high frequency
>for a long period of time, even if there are no longer RT tasks on
>CPUs in that domain

Normally this is dropped after a tick.
Nevertheless, there is an issue if the freq_update_delay_ns is shorter
than a tick because of sugov RT thread

> b) a FAIR task co-scheduled in the same CPU of a RT task can override the
>flags configured by the RT task and potentially this can cause an
>unwanted frequency drop
>
> These misbehaviours have been verified using a set of simple rt-app based
> synthetic workloads, running on a ARM's Juno board, and results are
> available in this Notebook [1].
>
> This series proposes a set of fixes for the aforementioned issues as well
> as a small improvement to speedup the selection of the maximum frequency
> when RT tasks enter a CPU.
>
> This series is based on top of today's tip/sched/core and is public available
> from this repository:
>
>   git://www.linux-arm.com/linux-pb eas/schedutil/flags_fixes
>
> Cheers Patrick
>
> [1] https://gist.github.com/d6a21b459a18091b2b058668a550010d
>
> Patrick Bellasi (6):
>   cpufreq: schedutil: reset sg_cpus's flags at IDLE enter
>   cpufreq: schedutil: ignore the sugov kthread for frequencies
> selections
>   cpufreq: schedutil: ensure max frequency while running RT/DL tasks
>   cpufreq: schedutil: relax rate-limiting while running RT/DL tasks
>   cpufreq: schedutil: avoid utilisation update when not necessary
>   sched/rt: fast switch to maximum frequency when RT tasks are scheduled
>
>  include/linux/sched.h|  1 +
>  kernel/sched/cpufreq_schedutil.c | 59 
> ++--
>  kernel/sched/idle_task.c |  4 +++
>  kernel/sched/rt.c| 15 --
>  4 files changed, 68 insertions(+), 11 deletions(-)
>
> --
> 2.7.4
>

[PATCH 02/11] drm/meson: Add missing HDMI register

2017-03-02 Thread Neil Armstrong

Add missing VPU HDMI register.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_registers.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/meson/meson_registers.h 
b/drivers/gpu/drm/meson/meson_registers.h
index 6adf9c1..2847381 100644
--- a/drivers/gpu/drm/meson/meson_registers.h
+++ b/drivers/gpu/drm/meson/meson_registers.h
@@ -1319,6 +1319,7 @@
 #define VPU_MISC_CTRL 0x2740
 #define VPU_ISP_GCLK_CTRL0 0x2741
 #define VPU_ISP_GCLK_CTRL1 0x2742
+#define VPU_HDMI_FMT_CTRL 0x2743
 #define VPU_VDIN_ASYNC_HOLD_CTRL 0x2743
 #define VPU_VDISP_ASYNC_HOLD_CTRL 0x2744
 #define VPU_VPUARB2_ASYNC_HOLD_CTRL 0x2745
-- 
1.9.1

[PATCH 02/11] drm/meson: Add missing HDMI register

2017-03-02 Thread Neil Armstrong

Add missing VPU HDMI register.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_registers.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/meson/meson_registers.h 
b/drivers/gpu/drm/meson/meson_registers.h
index 6adf9c1..2847381 100644
--- a/drivers/gpu/drm/meson/meson_registers.h
+++ b/drivers/gpu/drm/meson/meson_registers.h
@@ -1319,6 +1319,7 @@
 #define VPU_MISC_CTRL 0x2740
 #define VPU_ISP_GCLK_CTRL0 0x2741
 #define VPU_ISP_GCLK_CTRL1 0x2742
+#define VPU_HDMI_FMT_CTRL 0x2743
 #define VPU_VDIN_ASYNC_HOLD_CTRL 0x2743
 #define VPU_VDISP_ASYNC_HOLD_CTRL 0x2744
 #define VPU_VPUARB2_ASYNC_HOLD_CTRL 0x2745
-- 
1.9.1

[PATCH 01/11] drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable sync for vsync commit

2017-03-02 Thread Neil Armstrong

Clean the crtc_enable by using the proper crtc_state instead of the state
of the primary plane state data.

Also fix the dependency to commit the plane changes even if enable is called
after the flush.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_crtc.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
b/drivers/gpu/drm/meson/meson_crtc.c
index 0fe49ec..c986eb0 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -82,11 +82,18 @@ static void meson_crtc_disable_vblank(struct drm_crtc *crtc)
 static void meson_crtc_enable(struct drm_crtc *crtc)
 {
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
-   struct drm_plane *plane = meson_crtc->priv->primary_plane;
+   struct drm_crtc_state *crtc_state = crtc->state;
struct meson_drm *priv = meson_crtc->priv;
 
+   DRM_DEBUG_DRIVER("\n");
+
+   if (!crtc_state) {
+   DRM_ERROR("Invalid crtc_state\n");
+   return;
+   }
+
/* Enable VPP Postblend */
-   writel(plane->state->crtc_w,
+   writel(crtc_state->mode.hdisplay,
   priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
 
writel_bits_relaxed(VPP_POSTBLEND_ENABLE, VPP_POSTBLEND_ENABLE,
@@ -101,6 +108,7 @@ static void meson_crtc_disable(struct drm_crtc *crtc)
struct meson_drm *priv = meson_crtc->priv;
 
priv->viu.osd1_enabled = false;
+   priv->viu.osd1_commit = false;
 
/* Disable VPP Postblend */
writel_bits_relaxed(VPP_POSTBLEND_ENABLE, 0,
@@ -137,8 +145,7 @@ static void meson_crtc_atomic_flush(struct drm_crtc *crtc,
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct meson_drm *priv = meson_crtc->priv;
 
-   if (priv->viu.osd1_enabled)
-   priv->viu.osd1_commit = true;
+   priv->viu.osd1_commit = true;
 }
 
 static const struct drm_crtc_helper_funcs meson_crtc_helper_funcs = {
-- 
1.9.1

[PATCH 01/11] drm/meson: Use crtc_state for hdisplay and fix atomic flush/enable sync for vsync commit

2017-03-02 Thread Neil Armstrong

Clean the crtc_enable by using the proper crtc_state instead of the state
of the primary plane state data.

Also fix the dependency to commit the plane changes even if enable is called
after the flush.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_crtc.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
b/drivers/gpu/drm/meson/meson_crtc.c
index 0fe49ec..c986eb0 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -82,11 +82,18 @@ static void meson_crtc_disable_vblank(struct drm_crtc *crtc)
 static void meson_crtc_enable(struct drm_crtc *crtc)
 {
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
-   struct drm_plane *plane = meson_crtc->priv->primary_plane;
+   struct drm_crtc_state *crtc_state = crtc->state;
struct meson_drm *priv = meson_crtc->priv;
 
+   DRM_DEBUG_DRIVER("\n");
+
+   if (!crtc_state) {
+   DRM_ERROR("Invalid crtc_state\n");
+   return;
+   }
+
/* Enable VPP Postblend */
-   writel(plane->state->crtc_w,
+   writel(crtc_state->mode.hdisplay,
   priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
 
writel_bits_relaxed(VPP_POSTBLEND_ENABLE, VPP_POSTBLEND_ENABLE,
@@ -101,6 +108,7 @@ static void meson_crtc_disable(struct drm_crtc *crtc)
struct meson_drm *priv = meson_crtc->priv;
 
priv->viu.osd1_enabled = false;
+   priv->viu.osd1_commit = false;
 
/* Disable VPP Postblend */
writel_bits_relaxed(VPP_POSTBLEND_ENABLE, 0,
@@ -137,8 +145,7 @@ static void meson_crtc_atomic_flush(struct drm_crtc *crtc,
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct meson_drm *priv = meson_crtc->priv;
 
-   if (priv->viu.osd1_enabled)
-   priv->viu.osd1_commit = true;
+   priv->viu.osd1_commit = true;
 }
 
 static const struct drm_crtc_helper_funcs meson_crtc_helper_funcs = {
-- 
1.9.1

[RFC PATCH v2 11/32] x86: Unroll string I/O when SEV is active

2017-03-02 Thread Brijesh Singh

From: Tom Lendacky 

Secure Encrypted Virtualization (SEV) does not support string I/O, so
unroll the string I/O operation into a loop operating on one element at
a time.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/io.h |   26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 833f7cc..b596114 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -327,14 +327,32 @@ static inline unsigned type in##bwl##_p(int port) 
\
\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {  \
-   asm volatile("rep; outs" #bwl   \
-: "+S"(addr), "+c"(count) : "d"(port));\
+   if (sev_active()) { \
+   unsigned type *value = (unsigned type *)addr;   \
+   while (count) { \
+   out##bwl(*value, port); \
+   value++;\
+   count--;\
+   }   \
+   } else {\
+   asm volatile("rep; outs" #bwl   \
+: "+S"(addr), "+c"(count) : "d"(port));\
+   }   \
 }  \
\
 static inline void ins##bwl(int port, void *addr, unsigned long count) \
 {  \
-   asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+   if (sev_active()) { \
+   unsigned type *value = (unsigned type *)addr;   \
+   while (count) { \
+   *value = in##bwl(port); \
+   value++;\
+   count--;\
+   }   \
+   } else {\
+   asm volatile("rep; ins" #bwl\
+: "+D"(addr), "+c"(count) : "d"(port));\
+   }   \
 }
 
 BUILDIO(b, b, char)

[RFC PATCH v2 11/32] x86: Unroll string I/O when SEV is active

2017-03-02 Thread Brijesh Singh

From: Tom Lendacky 

Secure Encrypted Virtualization (SEV) does not support string I/O, so
unroll the string I/O operation into a loop operating on one element at
a time.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/io.h |   26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 833f7cc..b596114 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -327,14 +327,32 @@ static inline unsigned type in##bwl##_p(int port) 
\
\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {  \
-   asm volatile("rep; outs" #bwl   \
-: "+S"(addr), "+c"(count) : "d"(port));\
+   if (sev_active()) { \
+   unsigned type *value = (unsigned type *)addr;   \
+   while (count) { \
+   out##bwl(*value, port); \
+   value++;\
+   count--;\
+   }   \
+   } else {\
+   asm volatile("rep; outs" #bwl   \
+: "+S"(addr), "+c"(count) : "d"(port));\
+   }   \
 }  \
\
 static inline void ins##bwl(int port, void *addr, unsigned long count) \
 {  \
-   asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port));\
+   if (sev_active()) { \
+   unsigned type *value = (unsigned type *)addr;   \
+   while (count) { \
+   *value = in##bwl(port); \
+   value++;\
+   count--;\
+   }   \
+   } else {\
+   asm volatile("rep; ins" #bwl\
+: "+D"(addr), "+c"(count) : "d"(port));\
+   }   \
 }
 
 BUILDIO(b, b, char)

RE: [PATCH V2] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

2017-03-02 Thread Patel, Mayurkumar

>
>Hi Bjorn,
>
>On 2/28/2017 1:57 PM, Patel, Mayurkumar wrote:
>>> I was trying to figure out when to use saved values vs. the values in
>>> registers by looking at the enable_cnt.
>>> enable_cnt is 0 during boot on my system.
>> enable_cnt for the root port on my system is set to 1 for "root port" 
>> already without saving
>> any ASPM related settings.
>>
>>
>
>What would be the best way to figure out when to save power-on values from
>the registers?
>

So in my case, pci_enable_device() for root port is called from 
pcie_port_device_register() at the boot time which
Is called from pcie_portdrv_probe() function which does not call 
pcie_aspm_init_link_state() but
Increment's enable_cnt field. When the Endpoint get plugged in, 
pcie_aspm_init_link_state() is called
from hotplug routine on "Root port" but due to enable_cnt is already 
incremented we do not set
right policy and aspm gets disabled by aspm driver.

Shall we introduce new atomic variable along with aspm_default in struct 
pci_dev and increment it in when called
first time pcie_aspm_init_link_state()  to save power-on values ( I have tested 
it locally, if you think could be good approach
I can upload the diffs) because enable_cnt in pci_enable_device() can be 
triggered
from multiple places at boot time so it might not be safe to use it? 
or adding pcie_aspm_init_link_state() in pcie_port_device_register() for ports 
before calling pci_enable_device()
although I am not sure whether it's the right approach and that would work for 
all the devices!

@Kaya/Bjorn: Do you have any other suggestions or Could you also please help by 
comment what would make sense?

>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
>Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
>Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH 05/11] drm/meson: add support for HDMI clock support

2017-03-02 Thread Neil Armstrong

This patchs adds support for the supported HDMI modes clocks frequencies.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_vclk.c  | 624 +++-
 drivers/gpu/drm/meson/meson_vclk.h  |   6 +-
 drivers/gpu/drm/meson/meson_venc_cvbs.c |   9 +-
 3 files changed, 623 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_vclk.c 
b/drivers/gpu/drm/meson/meson_vclk.c
index 252cfd4..45cf1f6 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -27,9 +27,26 @@
  * VCLK is the "Pixel Clock" frequency generator from a dedicated PLL.
  * We handle the following encodings :
  * - CVBS 27MHz generator via the VCLK2 to the VENCI and VDAC blocks
- *
- * What is missing :
  * - HDMI Pixel Clocks generation
+ * What is missing :
+ * - Genenate Pixel clocks for 2K/4K 10bit formats
+ *
+ * Clock generator scheme :
+ *  __   __
+ * |  | | |  | |--ENCI
+ * | HDMI PLL |-| PLL_DIV |--- VCLK--| |--ENCL
+ * |__| |_| \| MUX |--ENCP
+ *   --VCLK2-| |--VDAC
+ *   |_|--HDMI-TX
+ *
+ * Final clocks can take input for either VCLK or VCLK2, but
+ * VCLK is the preferred path for HDMI clocking and VCLK2 is the
+ * preferred path for CVBS VDAC clocking.
+ *
+ * VCLK and VCLK2 have fixed divided clocks paths for /1, /2, /4, /6 or /12.
+ *
+ * The PLL_DIV can achieve an additional fractional dividing like
+ * 1.5, 3.5, 3.75... to generate special 2K and 4K 10bit clocks.
  */
 
 /* HHI Registers */
@@ -50,11 +67,34 @@
 #define VCLK2_SOFT_RESET   BIT(15)
 #define VCLK2_DIV1_EN  BIT(0)
 #define HHI_VID_CLK_DIV0x164 /* 0x59 offset in data sheet */
+#define VCLK_DIV_MASK  0xff
+#define VCLK_DIV_ENBIT(16)
+#define VCLK_DIV_RESET BIT(17)
+#define CTS_ENCP_SEL_MASK  (0xf << 24)
+#define CTS_ENCP_SEL_SHIFT 24
 #define CTS_ENCI_SEL_MASK  (0xf << 28)
 #define CTS_ENCI_SEL_SHIFT 28
+#define HHI_VID_CLK_CNTL   0x17c /* 0x5f offset in data sheet */
+#define VCLK_ENBIT(19)
+#define VCLK_SEL_MASK  (0x7 << 16)
+#define VCLK_SEL_SHIFT 16
+#define VCLK_SOFT_RESETBIT(15)
+#define VCLK_DIV1_EN   BIT(0)
+#define VCLK_DIV2_EN   BIT(1)
+#define VCLK_DIV4_EN   BIT(2)
+#define VCLK_DIV6_EN   BIT(3)
+#define VCLK_DIV12_EN  BIT(4)
 #define HHI_VID_CLK_CNTL2  0x194 /* 0x65 offset in data sheet */
 #define CTS_ENCI_ENBIT(0)
+#define CTS_ENCP_ENBIT(2)
 #define CTS_VDAC_ENBIT(4)
+#define HDMI_TX_PIXEL_EN   BIT(5)
+#define HHI_HDMI_CLK_CNTL  0x1cc /* 0x73 offset in data sheet */
+#define HDMI_TX_PIXEL_SEL_MASK (0xf << 16)
+#define HDMI_TX_PIXEL_SEL_SHIFT16
+#define CTS_HDMI_SYS_SEL_MASK  (0x7 << 9)
+#define CTS_HDMI_SYS_DIV_MASK  (0x7f)
+#define CTS_HDMI_SYS_ENBIT(8)
 
 #define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
 #define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
@@ -69,6 +109,126 @@
 #define HDMI_PLL_RESET BIT(28)
 #define HDMI_PLL_LOCK  BIT(31)
 
+/* VID PLL Dividers */
+enum {
+   VID_PLL_DIV_1 = 0,
+   VID_PLL_DIV_2,
+   VID_PLL_DIV_2p5,
+   VID_PLL_DIV_3,
+   VID_PLL_DIV_3p5,
+   VID_PLL_DIV_3p75,
+   VID_PLL_DIV_4,
+   VID_PLL_DIV_5,
+   VID_PLL_DIV_6,
+   VID_PLL_DIV_6p25,
+   VID_PLL_DIV_7,
+   VID_PLL_DIV_7p5,
+   VID_PLL_DIV_12,
+   VID_PLL_DIV_14,
+   VID_PLL_DIV_15,
+};
+
+void meson_vid_pll_set(struct meson_drm *priv, unsigned int div)
+{
+   unsigned int shift_val = 0;
+   unsigned int shift_sel = 0;
+
+   /* Disable vid_pll output clock */
+   regmap_update_bits(priv->hhi, HHI_VID_PLL_CLK_DIV, VID_PLL_EN, 0);
+   regmap_update_bits(priv->hhi, HHI_VID_PLL_CLK_DIV, VID_PLL_PRESET, 0);
+
+   switch (div) {
+   case VID_PLL_DIV_2:
+   shift_val = 0x0aaa;
+   shift_sel = 0;
+   break;
+   case VID_PLL_DIV_2p5:
+   shift_val = 0x5294;
+   shift_sel = 2;
+   break;
+   case VID_PLL_DIV_3:
+   shift_val = 0x0db6;
+   shift_sel = 0;
+   break;
+   case VID_PLL_DIV_3p5:
+   shift_val = 0x36cc;
+   shift_sel = 1;
+   break;
+   case VID_PLL_DIV_3p75:
+   shift_val = 0x;
+   shift_sel = 2;
+   break;
+   case VID_PLL_DIV_4:
+   shift_val = 0x0ccc;
+   shift_sel = 0;
+   break;
+   case VID_PLL_DIV_5:
+   shift_val = 0x739c;
+   shift_sel = 2;
+   break;
+   case VID_PLL_DIV_6:
+   shift_val = 0x0e38;
+

RE: [PATCH V2] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

2017-03-02 Thread Patel, Mayurkumar

>
>Hi Bjorn,
>
>On 2/28/2017 1:57 PM, Patel, Mayurkumar wrote:
>>> I was trying to figure out when to use saved values vs. the values in
>>> registers by looking at the enable_cnt.
>>> enable_cnt is 0 during boot on my system.
>> enable_cnt for the root port on my system is set to 1 for "root port" 
>> already without saving
>> any ASPM related settings.
>>
>>
>
>What would be the best way to figure out when to save power-on values from
>the registers?
>

So in my case, pci_enable_device() for root port is called from 
pcie_port_device_register() at the boot time which
Is called from pcie_portdrv_probe() function which does not call 
pcie_aspm_init_link_state() but
Increment's enable_cnt field. When the Endpoint get plugged in, 
pcie_aspm_init_link_state() is called
from hotplug routine on "Root port" but due to enable_cnt is already 
incremented we do not set
right policy and aspm gets disabled by aspm driver.

Shall we introduce new atomic variable along with aspm_default in struct 
pci_dev and increment it in when called
first time pcie_aspm_init_link_state()  to save power-on values ( I have tested 
it locally, if you think could be good approach
I can upload the diffs) because enable_cnt in pci_enable_device() can be 
triggered
from multiple places at boot time so it might not be safe to use it? 
or adding pcie_aspm_init_link_state() in pcie_port_device_register() for ports 
before calling pci_enable_device()
although I am not sure whether it's the right approach and that would work for 
all the devices!

@Kaya/Bjorn: Do you have any other suggestions or Could you also please help by 
comment what would make sense?

>--
>Sinan Kaya
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
>Technologies, Inc.
>Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
>Foundation Collaborative Project.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

[PATCH 05/11] drm/meson: add support for HDMI clock support

2017-03-02 Thread Neil Armstrong

This patchs adds support for the supported HDMI modes clocks frequencies.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_vclk.c  | 624 +++-
 drivers/gpu/drm/meson/meson_vclk.h  |   6 +-
 drivers/gpu/drm/meson/meson_venc_cvbs.c |   9 +-
 3 files changed, 623 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_vclk.c 
b/drivers/gpu/drm/meson/meson_vclk.c
index 252cfd4..45cf1f6 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -27,9 +27,26 @@
  * VCLK is the "Pixel Clock" frequency generator from a dedicated PLL.
  * We handle the following encodings :
  * - CVBS 27MHz generator via the VCLK2 to the VENCI and VDAC blocks
- *
- * What is missing :
  * - HDMI Pixel Clocks generation
+ * What is missing :
+ * - Genenate Pixel clocks for 2K/4K 10bit formats
+ *
+ * Clock generator scheme :
+ *  __   __
+ * |  | | |  | |--ENCI
+ * | HDMI PLL |-| PLL_DIV |--- VCLK--| |--ENCL
+ * |__| |_| \| MUX |--ENCP
+ *   --VCLK2-| |--VDAC
+ *   |_|--HDMI-TX
+ *
+ * Final clocks can take input for either VCLK or VCLK2, but
+ * VCLK is the preferred path for HDMI clocking and VCLK2 is the
+ * preferred path for CVBS VDAC clocking.
+ *
+ * VCLK and VCLK2 have fixed divided clocks paths for /1, /2, /4, /6 or /12.
+ *
+ * The PLL_DIV can achieve an additional fractional dividing like
+ * 1.5, 3.5, 3.75... to generate special 2K and 4K 10bit clocks.
  */
 
 /* HHI Registers */
@@ -50,11 +67,34 @@
 #define VCLK2_SOFT_RESET   BIT(15)
 #define VCLK2_DIV1_EN  BIT(0)
 #define HHI_VID_CLK_DIV0x164 /* 0x59 offset in data sheet */
+#define VCLK_DIV_MASK  0xff
+#define VCLK_DIV_ENBIT(16)
+#define VCLK_DIV_RESET BIT(17)
+#define CTS_ENCP_SEL_MASK  (0xf << 24)
+#define CTS_ENCP_SEL_SHIFT 24
 #define CTS_ENCI_SEL_MASK  (0xf << 28)
 #define CTS_ENCI_SEL_SHIFT 28
+#define HHI_VID_CLK_CNTL   0x17c /* 0x5f offset in data sheet */
+#define VCLK_ENBIT(19)
+#define VCLK_SEL_MASK  (0x7 << 16)
+#define VCLK_SEL_SHIFT 16
+#define VCLK_SOFT_RESETBIT(15)
+#define VCLK_DIV1_EN   BIT(0)
+#define VCLK_DIV2_EN   BIT(1)
+#define VCLK_DIV4_EN   BIT(2)
+#define VCLK_DIV6_EN   BIT(3)
+#define VCLK_DIV12_EN  BIT(4)
 #define HHI_VID_CLK_CNTL2  0x194 /* 0x65 offset in data sheet */
 #define CTS_ENCI_ENBIT(0)
+#define CTS_ENCP_ENBIT(2)
 #define CTS_VDAC_ENBIT(4)
+#define HDMI_TX_PIXEL_EN   BIT(5)
+#define HHI_HDMI_CLK_CNTL  0x1cc /* 0x73 offset in data sheet */
+#define HDMI_TX_PIXEL_SEL_MASK (0xf << 16)
+#define HDMI_TX_PIXEL_SEL_SHIFT16
+#define CTS_HDMI_SYS_SEL_MASK  (0x7 << 9)
+#define CTS_HDMI_SYS_DIV_MASK  (0x7f)
+#define CTS_HDMI_SYS_ENBIT(8)
 
 #define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
 #define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
@@ -69,6 +109,126 @@
 #define HDMI_PLL_RESET BIT(28)
 #define HDMI_PLL_LOCK  BIT(31)
 
+/* VID PLL Dividers */
+enum {
+   VID_PLL_DIV_1 = 0,
+   VID_PLL_DIV_2,
+   VID_PLL_DIV_2p5,
+   VID_PLL_DIV_3,
+   VID_PLL_DIV_3p5,
+   VID_PLL_DIV_3p75,
+   VID_PLL_DIV_4,
+   VID_PLL_DIV_5,
+   VID_PLL_DIV_6,
+   VID_PLL_DIV_6p25,
+   VID_PLL_DIV_7,
+   VID_PLL_DIV_7p5,
+   VID_PLL_DIV_12,
+   VID_PLL_DIV_14,
+   VID_PLL_DIV_15,
+};
+
+void meson_vid_pll_set(struct meson_drm *priv, unsigned int div)
+{
+   unsigned int shift_val = 0;
+   unsigned int shift_sel = 0;
+
+   /* Disable vid_pll output clock */
+   regmap_update_bits(priv->hhi, HHI_VID_PLL_CLK_DIV, VID_PLL_EN, 0);
+   regmap_update_bits(priv->hhi, HHI_VID_PLL_CLK_DIV, VID_PLL_PRESET, 0);
+
+   switch (div) {
+   case VID_PLL_DIV_2:
+   shift_val = 0x0aaa;
+   shift_sel = 0;
+   break;
+   case VID_PLL_DIV_2p5:
+   shift_val = 0x5294;
+   shift_sel = 2;
+   break;
+   case VID_PLL_DIV_3:
+   shift_val = 0x0db6;
+   shift_sel = 0;
+   break;
+   case VID_PLL_DIV_3p5:
+   shift_val = 0x36cc;
+   shift_sel = 1;
+   break;
+   case VID_PLL_DIV_3p75:
+   shift_val = 0x;
+   shift_sel = 2;
+   break;
+   case VID_PLL_DIV_4:
+   shift_val = 0x0ccc;
+   shift_sel = 0;
+   break;
+   case VID_PLL_DIV_5:
+   shift_val = 0x739c;
+   shift_sel = 2;
+   break;
+   case VID_PLL_DIV_6:
+   shift_val = 0x0e38;
+   shift_sel = 0;
+

< 5 6 7 8 9 10 11 12 13 14 >

901 - 1000 of 1740 matches

Mail list logo