[PATCH] Revert "drm/sun4i: add lvds mode_valid function"

[megous]

From: Ondrej Jirman 

The reverted commit broke LVDS output on TBS A711 Tablet. That tablet
has simple-panel node that has fixed pixel clock-frequency that A83T
SoC used in the tablet can't generate exactly.

Requested rate is 5200 and rounded_rate is calculated as 51857142.
It's close enough for it to work in practice, but with strict check
in the reverted commit, the mode is rejected needlessly in this case.

DT allows to specify a range of values for simple-panel/clock-frequency,
but driver doesn't respect that ATM. Given that TBS A711 is the single
user of sun4i-lvds driver, let's revert that commit for now, until
a better solution for the problem is found.

Also see: https://patchwork.kernel.org/patch/9446385/ for relevant
discussion (or search for "[RFC] drm/sun4i: rgb: Add 5% tolerance
to dot clock frequency check").

Fixes: e4e4b7ad50cf ("drm/sun4i: add lvds mode_valid function")
Reported-by: Ondrej Jirman 
Signed-off-by: Ondrej Jirman 
---
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 --
 1 file changed, 55 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index b4c9fbf5..be3f14d7746d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -94,64 +94,9 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder 
*encoder)
}
 }
 
-static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct drm_encoder 
*crtc,
- const struct 
drm_display_mode *mode)
-{
-   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc);
-   struct sun4i_tcon *tcon = lvds->tcon;
-   u32 hsync = mode->hsync_end - mode->hsync_start;
-   u32 vsync = mode->vsync_end - mode->vsync_start;
-   unsigned long rate = mode->clock * 1000;
-   long rounded_rate;
-
-   DRM_DEBUG_DRIVER("Validating modes...\n");
-
-   if (hsync < 1)
-   return MODE_HSYNC_NARROW;
-
-   if (hsync > 0x3ff)
-   return MODE_HSYNC_WIDE;
-
-   if ((mode->hdisplay < 1) || (mode->htotal < 1))
-   return MODE_H_ILLEGAL;
-
-   if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
-   return MODE_BAD_HVALUE;
-
-   DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
-
-   if (vsync < 1)
-   return MODE_VSYNC_NARROW;
-
-   if (vsync > 0x3ff)
-   return MODE_VSYNC_WIDE;
-
-   if ((mode->vdisplay < 1) || (mode->vtotal < 1))
-   return MODE_V_ILLEGAL;
-
-   if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
-   return MODE_BAD_VVALUE;
-
-   DRM_DEBUG_DRIVER("Vertical parameters OK\n");
-
-   tcon->dclk_min_div = 7;
-   tcon->dclk_max_div = 7;
-   rounded_rate = clk_round_rate(tcon->dclk, rate);
-   if (rounded_rate < rate)
-   return MODE_CLOCK_LOW;
-
-   if (rounded_rate > rate)
-   return MODE_CLOCK_HIGH;
-
-   DRM_DEBUG_DRIVER("Clock rate OK\n");
-
-   return MODE_OK;
-}
-
 static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
.disable= sun4i_lvds_encoder_disable,
.enable = sun4i_lvds_encoder_enable,
-   .mode_valid = sun4i_lvds_encoder_mode_valid,
 };
 
 static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
-- 
2.17.0

[PATCH] Revert "drm/sun4i: add lvds mode_valid function"

[megous]

From: Ondrej Jirman 

The reverted commit broke LVDS output on TBS A711 Tablet. That tablet
has simple-panel node that has fixed pixel clock-frequency that A83T
SoC used in the tablet can't generate exactly.

Requested rate is 5200 and rounded_rate is calculated as 51857142.
It's close enough for it to work in practice, but with strict check
in the reverted commit, the mode is rejected needlessly in this case.

DT allows to specify a range of values for simple-panel/clock-frequency,
but driver doesn't respect that ATM. Given that TBS A711 is the single
user of sun4i-lvds driver, let's revert that commit for now, until
a better solution for the problem is found.

Also see: https://patchwork.kernel.org/patch/9446385/ for relevant
discussion (or search for "[RFC] drm/sun4i: rgb: Add 5% tolerance
to dot clock frequency check").

Fixes: e4e4b7ad50cf ("drm/sun4i: add lvds mode_valid function")
Reported-by: Ondrej Jirman 
Signed-off-by: Ondrej Jirman 
---
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 --
 1 file changed, 55 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index b4c9fbf5..be3f14d7746d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -94,64 +94,9 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder 
*encoder)
}
 }
 
-static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct drm_encoder 
*crtc,
- const struct 
drm_display_mode *mode)
-{
-   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc);
-   struct sun4i_tcon *tcon = lvds->tcon;
-   u32 hsync = mode->hsync_end - mode->hsync_start;
-   u32 vsync = mode->vsync_end - mode->vsync_start;
-   unsigned long rate = mode->clock * 1000;
-   long rounded_rate;
-
-   DRM_DEBUG_DRIVER("Validating modes...\n");
-
-   if (hsync < 1)
-   return MODE_HSYNC_NARROW;
-
-   if (hsync > 0x3ff)
-   return MODE_HSYNC_WIDE;
-
-   if ((mode->hdisplay < 1) || (mode->htotal < 1))
-   return MODE_H_ILLEGAL;
-
-   if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
-   return MODE_BAD_HVALUE;
-
-   DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
-
-   if (vsync < 1)
-   return MODE_VSYNC_NARROW;
-
-   if (vsync > 0x3ff)
-   return MODE_VSYNC_WIDE;
-
-   if ((mode->vdisplay < 1) || (mode->vtotal < 1))
-   return MODE_V_ILLEGAL;
-
-   if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
-   return MODE_BAD_VVALUE;
-
-   DRM_DEBUG_DRIVER("Vertical parameters OK\n");
-
-   tcon->dclk_min_div = 7;
-   tcon->dclk_max_div = 7;
-   rounded_rate = clk_round_rate(tcon->dclk, rate);
-   if (rounded_rate < rate)
-   return MODE_CLOCK_LOW;
-
-   if (rounded_rate > rate)
-   return MODE_CLOCK_HIGH;
-
-   DRM_DEBUG_DRIVER("Clock rate OK\n");
-
-   return MODE_OK;
-}
-
 static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
.disable= sun4i_lvds_encoder_disable,
.enable = sun4i_lvds_encoder_enable,
-   .mode_valid = sun4i_lvds_encoder_mode_valid,
 };
 
 static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
-- 
2.17.0

[PATCH] Revert "f2fs: introduce f2fs_set_page_dirty_nobuffer"

[Jaegeuk Kim]

This patch reverts copied f2fs_set_page_dirty_nobuffer to use generic function
for stability.

This reverts commit fe76b796fc5194cc3d57265002e3a748566d073f.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c |  2 +-
 fs/f2fs/data.c   | 33 +
 fs/f2fs/f2fs.h   |  1 -
 fs/f2fs/node.c   |  2 +-
 4 files changed, 3 insertions(+), 35 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 2e23b953d304..8fc55d42ba25 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -384,7 +384,7 @@ static int f2fs_set_meta_page_dirty(struct page *page)
if (!PageUptodate(page))
SetPageUptodate(page);
if (!PageDirty(page)) {
-   f2fs_set_page_dirty_nobuffers(page);
+   __set_page_dirty_nobuffers(page);
inc_page_count(F2FS_P_SB(page), F2FS_DIRTY_META);
SetPagePrivate(page);
f2fs_trace_pid(page);
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index d32bf363cb60..5477fc09c3cd 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -19,8 +19,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 
@@ -2471,35 +2469,6 @@ int f2fs_release_page(struct page *page, gfp_t wait)
return 1;
 }
 
-/*
- * This was copied from __set_page_dirty_buffers which gives higher performance
- * in very high speed storages. (e.g., pmem)
- */
-void f2fs_set_page_dirty_nobuffers(struct page *page)
-{
-   struct address_space *mapping = page->mapping;
-   unsigned long flags;
-
-   if (unlikely(!mapping))
-   return;
-
-   spin_lock(>private_lock);
-   lock_page_memcg(page);
-   SetPageDirty(page);
-   spin_unlock(>private_lock);
-
-   xa_lock_irqsave(>i_pages, flags);
-   WARN_ON_ONCE(!PageUptodate(page));
-   account_page_dirtied(page, mapping);
-   radix_tree_tag_set(>i_pages,
-   page_index(page), PAGECACHE_TAG_DIRTY);
-   xa_unlock_irqrestore(>i_pages, flags);
-   unlock_page_memcg(page);
-
-   __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
-   return;
-}
-
 static int f2fs_set_data_page_dirty(struct page *page)
 {
struct address_space *mapping = page->mapping;
@@ -2523,7 +2492,7 @@ static int f2fs_set_data_page_dirty(struct page *page)
}
 
if (!PageDirty(page)) {
-   f2fs_set_page_dirty_nobuffers(page);
+   __set_page_dirty_nobuffers(page);
update_dirty_page(inode, page);
return 1;
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 0c72908f3185..9f2bc78a9f5b 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2939,7 +2939,6 @@ int f2fs_fiemap(struct inode *inode, struct 
fiemap_extent_info *fieinfo,
u64 start, u64 len);
 bool should_update_inplace(struct inode *inode, struct f2fs_io_info *fio);
 bool should_update_outplace(struct inode *inode, struct f2fs_io_info *fio);
-void f2fs_set_page_dirty_nobuffers(struct page *page);
 int __f2fs_write_data_pages(struct address_space *mapping,
struct writeback_control *wbc,
enum iostat_type io_type);
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index f202398e20ea..ae83ca9d2d31 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1753,7 +1753,7 @@ static int f2fs_set_node_page_dirty(struct page *page)
if (!PageUptodate(page))
SetPageUptodate(page);
if (!PageDirty(page)) {
-   f2fs_set_page_dirty_nobuffers(page);
+   __set_page_dirty_nobuffers(page);
inc_page_count(F2FS_P_SB(page), F2FS_DIRTY_NODES);
SetPagePrivate(page);
f2fs_trace_pid(page);
-- 
2.17.0.484.g0c8726318c-goog

[PATCH] Revert "f2fs: introduce f2fs_set_page_dirty_nobuffer"

[Jaegeuk Kim]

This patch reverts copied f2fs_set_page_dirty_nobuffer to use generic function
for stability.

This reverts commit fe76b796fc5194cc3d57265002e3a748566d073f.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c |  2 +-
 fs/f2fs/data.c   | 33 +
 fs/f2fs/f2fs.h   |  1 -
 fs/f2fs/node.c   |  2 +-
 4 files changed, 3 insertions(+), 35 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 2e23b953d304..8fc55d42ba25 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -384,7 +384,7 @@ static int f2fs_set_meta_page_dirty(struct page *page)
if (!PageUptodate(page))
SetPageUptodate(page);
if (!PageDirty(page)) {
-   f2fs_set_page_dirty_nobuffers(page);
+   __set_page_dirty_nobuffers(page);
inc_page_count(F2FS_P_SB(page), F2FS_DIRTY_META);
SetPagePrivate(page);
f2fs_trace_pid(page);
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index d32bf363cb60..5477fc09c3cd 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -19,8 +19,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 
@@ -2471,35 +2469,6 @@ int f2fs_release_page(struct page *page, gfp_t wait)
return 1;
 }
 
-/*
- * This was copied from __set_page_dirty_buffers which gives higher performance
- * in very high speed storages. (e.g., pmem)
- */
-void f2fs_set_page_dirty_nobuffers(struct page *page)
-{
-   struct address_space *mapping = page->mapping;
-   unsigned long flags;
-
-   if (unlikely(!mapping))
-   return;
-
-   spin_lock(>private_lock);
-   lock_page_memcg(page);
-   SetPageDirty(page);
-   spin_unlock(>private_lock);
-
-   xa_lock_irqsave(>i_pages, flags);
-   WARN_ON_ONCE(!PageUptodate(page));
-   account_page_dirtied(page, mapping);
-   radix_tree_tag_set(>i_pages,
-   page_index(page), PAGECACHE_TAG_DIRTY);
-   xa_unlock_irqrestore(>i_pages, flags);
-   unlock_page_memcg(page);
-
-   __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
-   return;
-}
-
 static int f2fs_set_data_page_dirty(struct page *page)
 {
struct address_space *mapping = page->mapping;
@@ -2523,7 +2492,7 @@ static int f2fs_set_data_page_dirty(struct page *page)
}
 
if (!PageDirty(page)) {
-   f2fs_set_page_dirty_nobuffers(page);
+   __set_page_dirty_nobuffers(page);
update_dirty_page(inode, page);
return 1;
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 0c72908f3185..9f2bc78a9f5b 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2939,7 +2939,6 @@ int f2fs_fiemap(struct inode *inode, struct 
fiemap_extent_info *fieinfo,
u64 start, u64 len);
 bool should_update_inplace(struct inode *inode, struct f2fs_io_info *fio);
 bool should_update_outplace(struct inode *inode, struct f2fs_io_info *fio);
-void f2fs_set_page_dirty_nobuffers(struct page *page);
 int __f2fs_write_data_pages(struct address_space *mapping,
struct writeback_control *wbc,
enum iostat_type io_type);
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index f202398e20ea..ae83ca9d2d31 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1753,7 +1753,7 @@ static int f2fs_set_node_page_dirty(struct page *page)
if (!PageUptodate(page))
SetPageUptodate(page);
if (!PageDirty(page)) {
-   f2fs_set_page_dirty_nobuffers(page);
+   __set_page_dirty_nobuffers(page);
inc_page_count(F2FS_P_SB(page), F2FS_DIRTY_NODES);
SetPagePrivate(page);
f2fs_trace_pid(page);
-- 
2.17.0.484.g0c8726318c-goog

Re: general protection fault in smc_setsockopt

[syzbot]

syzbot has found reproducer for the following crash on upstream commit
83beed7b2b26f232d782127792dd0cd4362fdc41 (Fri Apr 20 17:56:32 2018 +)
Merge branch 'fixes' of  
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=9045fc589fcd196ef522


So far this crash happened 124 times on net-next, upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6522155797839872
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=5566093930266624
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=6661555940753408
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=1808800213120130118

compiler: gcc (GCC) 8.0.1 20180413 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9045fc589fcd196ef...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 4520 Comm: syzkaller696326 Not tainted 4.17.0-rc1+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:smc_setsockopt+0x8b/0x120 net/smc/af_smc.c:1287
RSP: 0018:8801b433fcc8 EFLAGS: 00010206
RAX: dc00 RBX:  RCX: 2000
RDX: 0005 RSI: 873e3bf6 RDI: 0028
RBP: 8801b433fcf8 R08:  R09: ed00359a3780
R10: ed00359a3780 R11: 8801acd1bc03 R12: 8801b433fd40
R13: 0021 R14: 000d R15: 2000
FS:  00b01880() GS:8801daf0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 562e1fa410d0 CR3: 0001acf1e000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 __sys_setsockopt+0x1bd/0x390 net/socket.c:1903
 __do_sys_setsockopt net/socket.c:1914 [inline]
 __se_sys_setsockopt net/socket.c:1911 [inline]
 __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43fd19
RSP: 002b:7ffccc4960f8 EFLAGS: 0217 ORIG_RAX: 0036
RAX: ffda RBX: 004002c8 RCX: 0043fd19
RDX: 000d RSI: 0021 RDI: 0004
RBP: 006ca018 R08:  R09: 004002c8
R10: 2000 R11: 0217 R12: 00401640
R13: 004016d0 R14:  R15: 
Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 93 00 00 00 48 8b 9b 50 04 00 00 48  
b8 00 00 00 00 00 fc ff df 48 8d 7b 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00  
75 62 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 28 49

RIP: smc_setsockopt+0x8b/0x120 net/smc/af_smc.c:1287 RSP: 8801b433fcc8
---[ end trace 3858d0cd9ce5e4d4 ]---

Re: general protection fault in smc_setsockopt

[syzbot]

syzbot has found reproducer for the following crash on upstream commit
83beed7b2b26f232d782127792dd0cd4362fdc41 (Fri Apr 20 17:56:32 2018 +)
Merge branch 'fixes' of  
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=9045fc589fcd196ef522


So far this crash happened 124 times on net-next, upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=6522155797839872
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=5566093930266624
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=6661555940753408
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=1808800213120130118

compiler: gcc (GCC) 8.0.1 20180413 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9045fc589fcd196ef...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 4520 Comm: syzkaller696326 Not tainted 4.17.0-rc1+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:smc_setsockopt+0x8b/0x120 net/smc/af_smc.c:1287
RSP: 0018:8801b433fcc8 EFLAGS: 00010206
RAX: dc00 RBX:  RCX: 2000
RDX: 0005 RSI: 873e3bf6 RDI: 0028
RBP: 8801b433fcf8 R08:  R09: ed00359a3780
R10: ed00359a3780 R11: 8801acd1bc03 R12: 8801b433fd40
R13: 0021 R14: 000d R15: 2000
FS:  00b01880() GS:8801daf0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 562e1fa410d0 CR3: 0001acf1e000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 __sys_setsockopt+0x1bd/0x390 net/socket.c:1903
 __do_sys_setsockopt net/socket.c:1914 [inline]
 __se_sys_setsockopt net/socket.c:1911 [inline]
 __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43fd19
RSP: 002b:7ffccc4960f8 EFLAGS: 0217 ORIG_RAX: 0036
RAX: ffda RBX: 004002c8 RCX: 0043fd19
RDX: 000d RSI: 0021 RDI: 0004
RBP: 006ca018 R08:  R09: 004002c8
R10: 2000 R11: 0217 R12: 00401640
R13: 004016d0 R14:  R15: 
Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 93 00 00 00 48 8b 9b 50 04 00 00 48  
b8 00 00 00 00 00 fc ff df 48 8d 7b 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00  
75 62 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 28 49

RIP: smc_setsockopt+0x8b/0x120 net/smc/af_smc.c:1287 RSP: 8801b433fcc8
---[ end trace 3858d0cd9ce5e4d4 ]---

loan offer

[info]

DO YOU NEED FINANCIAL HELP? $5000 to $20,000,000.00 No credit check 

Repaid over 1 year to maximum of 30 years at a low interest rate of 3%. 

Approval in 15-30 minutes Open 7 days a week from 24/7 Service available 

nationwide E-MAIL  globalsolutionfinanc...@yahoo.com

loan offer

[info]

DO YOU NEED FINANCIAL HELP? $5000 to $20,000,000.00 No credit check 

Repaid over 1 year to maximum of 30 years at a low interest rate of 3%. 

Approval in 15-30 minutes Open 7 days a week from 24/7 Service available 

nationwide E-MAIL  globalsolutionfinanc...@yahoo.com

[PATCH] staging: android: ion: remove duplicate buffer field initializes

[Todd Poynor]

As a result of various previous patches, ion_buffer_create() now
has two sets of identical statements for initializing two fields of
the buffer struct, next to each other.  Remove one set.

Move the initialization of these two fields together with the
statements that initialize the other two fields from the function
parameters, prior to the heap allocate() call, for consistency.

Signed-off-by: Todd Poynor 
---
 drivers/staging/android/ion/ion.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e74db7902549..269a431646be 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -74,6 +74,8 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 
buffer->heap = heap;
buffer->flags = flags;
+   buffer->dev = dev;
+   buffer->size = len;
 
ret = heap->ops->allocate(heap, buffer, len, flags);
 
@@ -93,11 +95,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
goto err1;
}
 
-   buffer->dev = dev;
-   buffer->size = len;
 
-   buffer->dev = dev;
-   buffer->size = len;
INIT_LIST_HEAD(>attachments);
mutex_init(>lock);
mutex_lock(>buffer_lock);
-- 
2.17.0.484.g0c8726318c-goog

[PATCH] staging: android: ion: remove duplicate buffer field initializes

[Todd Poynor]

As a result of various previous patches, ion_buffer_create() now
has two sets of identical statements for initializing two fields of
the buffer struct, next to each other.  Remove one set.

Move the initialization of these two fields together with the
statements that initialize the other two fields from the function
parameters, prior to the heap allocate() call, for consistency.

Signed-off-by: Todd Poynor 
---
 drivers/staging/android/ion/ion.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e74db7902549..269a431646be 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -74,6 +74,8 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 
buffer->heap = heap;
buffer->flags = flags;
+   buffer->dev = dev;
+   buffer->size = len;
 
ret = heap->ops->allocate(heap, buffer, len, flags);
 
@@ -93,11 +95,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
goto err1;
}
 
-   buffer->dev = dev;
-   buffer->size = len;
 
-   buffer->dev = dev;
-   buffer->size = len;
INIT_LIST_HEAD(>attachments);
mutex_init(>lock);
mutex_lock(>buffer_lock);
-- 
2.17.0.484.g0c8726318c-goog

[no subject]

[Maratovich Fridman]

I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.

Check the link below for confirmation:

http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604

Reply as soon as possible with further directives.

Best Regards,
Mikhail Fridman.

[no subject]

[Maratovich Fridman]

I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.

Check the link below for confirmation:

http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604

Reply as soon as possible with further directives.

Best Regards,
Mikhail Fridman.

[no subject]

[Fridman M. Maratovich]

I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.

Check the link below for confirmation:

http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604

Reply as soon as possible with further directives.

Best Regards,
Mikhail Fridman.

[no subject]

[Fridman M. Maratovich]

I Mikhail Fridman. has selected you specially as one of my beneficiaries
for my Charitable Donation, Just as I have declared on May 23, 2016 to give
my fortune as charity.

Check the link below for confirmation:

http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604

Reply as soon as possible with further directives.

Best Regards,
Mikhail Fridman.

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Rob Herring]

On Fri, Apr 20, 2018 at 6:41 PM, Stephen Boyd  wrote:
> Quoting Rob Herring (2018-04-20 11:15:04)
>> On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd  wrote:
>> > Quoting Rob Herring (2018-04-18 15:29:05)
>> >> diff --git a/Documentation/devicetree/bindings/example-schema.yaml 
>> >> b/Documentation/devicetree/bindings/example-schema.yaml
>> >> new file mode 100644
>> >> index ..fe0a3bd1668e
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/example-schema.yaml
>> >> @@ -0,0 +1,149 @@
>> >> +
>> >> +  The end of the description is marked by indentation less than the 
>> >> first line
>> >> +  in the description.
>> >> +
>> >> +select: false
>> >> +  # 'select' is a schema applied to a DT node to determine if this 
>> >> binding
>> >> +  # schema should be applied to the node. It is optional and by default 
>> >> the
>> >> +  # possible compatible strings are extracted and used to match.
>> >
>> > Can we get a concrete example here?
>>
>> select: true
>>
>> :) Which is apply to every node.
>>
>> A better one is from the memory node schema ('$nodename' gets added :
>>
>> select:
>>   required: ["$nodename"]
>>   properties:
>> $nodename:
>>   oneOf:
>> - pattern: "^memory@[0-9a-f]*"
>> - const: "memory" # 'memory' only allowed for selecting
>>
>>
>> I expect the vast majority of device bindings will not use select at
>> all and rely on compatible string matching.
>
> Thanks! I was looking to see how the select syntax would work and this
> shows one example nicely. I suppose another way would be to show how a
> compatible string would be matched through select, even though it's
> redundant.
>
> Is there a way we can enforce node names through the schema too? For
> example to enforce that a clock controller is called 'clock-controller'
> or a spi master is called 'spi'.

Yes, that's something I'd like to do. I think the easiest is to just
treat node name as a property. We already generate a $nodename
property when parsing the yaml format DT.

>>
>> >> +
>> >> +properties:
>> > [...]
>> >> +
>> >> +  interrupts:
>> >> +# Either 1 or 2 interrupts can be present
>> >> +minItems: 1
>> >> +maxItems: 2
>> >> +items:
>> >> +  - description: tx or combined interrupt
>> >> +  - description: rx interrupt
>> >> +
>> >> +description: |
>> >
>> > The '|' is needed to make yaml happy?
>>
>> Yes, this is simply how you do literal text blocks in yaml.
>>
>> We don't really need for this one really, but for the top-level
>> 'description' we do. The long term intent is 'description' would be
>> written in sphinx/rst and can be extracted into the DT spec (for
>> common bindings). Grant has experimented with that some.
>
> Ok. That sounds cool. Then we could embed links to datasheets and SVGs
> too.
>
>>
>> >> +  A variable number of interrupts warrants a description of what 
>> >> conditions
>> >> +  affect the number of interrupts. Otherwise, descriptions on 
>> >> standard
>> >> +  properties are not necessary.
>> >> +
>> >> +  interrupt-names:
>> >> +# minItems must be specified here because the default would be 2
>> >> +minItems: 1
>> >> +items:
>> >> +  - const: "tx irq"
>> >> +  - const: "rx irq"
>> >> +
>> >> +  # Property names starting with '#' must be quoted
>> >> +  '#interrupt-cells':
>> >> +# A simple case where the value must always be '2'.
>> >> +# The core schema handles that this must be a single integer.
>> >> +const: 2
>> >> +
>> >> +  interrupt-controller: {}
>> >
>> > Does '{}' mean nothing to see here?
>>
>> Yes. It's just an empty schema that's always valid.
>
> Could we include another schema to indicate that this is an interrupt
> controller? I'm sort of asking for multi-schema inheritance.

Yes, but there's no need to do that here. Another schema can select on
"interrupt-controller" property and be applied independently. There's
already an example of that for the root node in my yaml-bindings repo.

Rob

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Rob Herring]

On Fri, Apr 20, 2018 at 6:41 PM, Stephen Boyd  wrote:
> Quoting Rob Herring (2018-04-20 11:15:04)
>> On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd  wrote:
>> > Quoting Rob Herring (2018-04-18 15:29:05)
>> >> diff --git a/Documentation/devicetree/bindings/example-schema.yaml 
>> >> b/Documentation/devicetree/bindings/example-schema.yaml
>> >> new file mode 100644
>> >> index ..fe0a3bd1668e
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/example-schema.yaml
>> >> @@ -0,0 +1,149 @@
>> >> +
>> >> +  The end of the description is marked by indentation less than the 
>> >> first line
>> >> +  in the description.
>> >> +
>> >> +select: false
>> >> +  # 'select' is a schema applied to a DT node to determine if this 
>> >> binding
>> >> +  # schema should be applied to the node. It is optional and by default 
>> >> the
>> >> +  # possible compatible strings are extracted and used to match.
>> >
>> > Can we get a concrete example here?
>>
>> select: true
>>
>> :) Which is apply to every node.
>>
>> A better one is from the memory node schema ('$nodename' gets added :
>>
>> select:
>>   required: ["$nodename"]
>>   properties:
>> $nodename:
>>   oneOf:
>> - pattern: "^memory@[0-9a-f]*"
>> - const: "memory" # 'memory' only allowed for selecting
>>
>>
>> I expect the vast majority of device bindings will not use select at
>> all and rely on compatible string matching.
>
> Thanks! I was looking to see how the select syntax would work and this
> shows one example nicely. I suppose another way would be to show how a
> compatible string would be matched through select, even though it's
> redundant.
>
> Is there a way we can enforce node names through the schema too? For
> example to enforce that a clock controller is called 'clock-controller'
> or a spi master is called 'spi'.

Yes, that's something I'd like to do. I think the easiest is to just
treat node name as a property. We already generate a $nodename
property when parsing the yaml format DT.

>>
>> >> +
>> >> +properties:
>> > [...]
>> >> +
>> >> +  interrupts:
>> >> +# Either 1 or 2 interrupts can be present
>> >> +minItems: 1
>> >> +maxItems: 2
>> >> +items:
>> >> +  - description: tx or combined interrupt
>> >> +  - description: rx interrupt
>> >> +
>> >> +description: |
>> >
>> > The '|' is needed to make yaml happy?
>>
>> Yes, this is simply how you do literal text blocks in yaml.
>>
>> We don't really need for this one really, but for the top-level
>> 'description' we do. The long term intent is 'description' would be
>> written in sphinx/rst and can be extracted into the DT spec (for
>> common bindings). Grant has experimented with that some.
>
> Ok. That sounds cool. Then we could embed links to datasheets and SVGs
> too.
>
>>
>> >> +  A variable number of interrupts warrants a description of what 
>> >> conditions
>> >> +  affect the number of interrupts. Otherwise, descriptions on 
>> >> standard
>> >> +  properties are not necessary.
>> >> +
>> >> +  interrupt-names:
>> >> +# minItems must be specified here because the default would be 2
>> >> +minItems: 1
>> >> +items:
>> >> +  - const: "tx irq"
>> >> +  - const: "rx irq"
>> >> +
>> >> +  # Property names starting with '#' must be quoted
>> >> +  '#interrupt-cells':
>> >> +# A simple case where the value must always be '2'.
>> >> +# The core schema handles that this must be a single integer.
>> >> +const: 2
>> >> +
>> >> +  interrupt-controller: {}
>> >
>> > Does '{}' mean nothing to see here?
>>
>> Yes. It's just an empty schema that's always valid.
>
> Could we include another schema to indicate that this is an interrupt
> controller? I'm sort of asking for multi-schema inheritance.

Yes, but there's no need to do that here. Another schema can select on
"interrupt-controller" property and be applied independently. There's
already an example of that for the root node in my yaml-bindings repo.

Rob

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Rob Herring]

On Fri, Apr 20, 2018 at 4:00 PM, Frank Rowand  wrote:
> Hi Rob,
>
> Thanks for the example.  It was a good starting tutorial of sorts for me
> to understand the format a bit.
>
>
> On 04/18/18 15:29, Rob Herring wrote:
>> The current DT binding documentation format of freeform text is painful
>> to write, review, validate and maintain.
>>
>> This is just an example of what a binding in the schema format looks
>> like. It's using jsonschema vocabulary in a YAML encoded document. Using
>> jsonschema gives us access to existing tooling. A YAML encoding gives us
>> something easy to edit.
>>
>> This example is just the tip of the iceberg, but it the part most
>> developers writing bindings will interact with. Backing all this up
>> are meta-schema (to validate the binding schemas), some DT core schema,
>> YAML encoded DT output with dtc, and a small number of python scripts to
>> run validation. The gory details including how to run end-to-end
>> validation can be found here:
>>
>> https://www.spinics.net/lists/devicetree-spec/msg00649.html
>>
>> Signed-off-by: Rob Herring 
>> ---
>> Cc list,
>> You all review and/or write lots of binding documents. I'd like some feedback
>> on the format.
>>
>> Thanks,
>> Rob
>>
>>  .../devicetree/bindings/example-schema.yaml| 149 
>> +
>>  1 file changed, 149 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/example-schema.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/example-schema.yaml 
>> b/Documentation/devicetree/bindings/example-schema.yaml
>> new file mode 100644
>> index ..fe0a3bd1668e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/example-schema.yaml
>
> I'm guessing by the path name that this is in the Linux kernel source tree.

Yes, well, my kernel tree. Most of the work still lives here:

https://github.com/robherring/yaml-bindings/

>> @@ -0,0 +1,149 @@
>> +# SPDX-License-Identifier: BSD-2-Clause
>
> If in the Linux kernel source tree, then allow gpl-v2 as a possible license.

Why? BSD is compatible. The license of the above repo is all BSD.

Of course there's all the existing docs which default to GPLv2 and
we'll probably have to maintain that.

>> +# Copyright 2018 Linaro Ltd.
>> +%YAML 1.2
>> +---
>> +# All the top-level keys are standard json-schema keywords except for
>> +# 'maintainers' and 'select'
>> +
>> +# $id is a unique idenifier based on the filename
>
>  ^  identifier
>
>> +$id: "http://devicetree.org/schemas/example-schema.yaml#;
>
> Does this imply that all schemas will be at devicetree.org instead
> of in the Linux kernel source tree?  This would be counter to my
> earlier guess about where this patch is applied.

They could be, but not necessarily. This is just convention in
jsonschema is the best I understand it.

I don't think you'd want validation to require an internet connection.
For the base meta-schema, for example, it does exist at
http://json-schema.org/draft-06/schema, but that's also distributed
with implementations of jsonschema validators.

A large part (not that any part is large) of the tools Grant and I
have written is doing the cross reference resolution of files which
uses the $id field.


>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
>
> How is $schema used?

Tells the validator what meta-schema this schema follows. Typically
you see draft04 or draft06 here if you haven't written a meta-schema.

> Is it accessed across the network?

Could be, but generally no.


>> +
>> +# Only 1 version supported for now
>> +version: 1
>> +
>> +title: An example schema annotated with jsonschema details
>> +
>> +maintainers:
>> +  - Rob Herring 
>> +
>> +description: |
>> +  A more detailed multi-line description of the binding.
>> +
>> +  Details about the hardware device and any links to datasheets can go here.
>> +
>> +  The end of the description is marked by indentation less than the first 
>> line
>> +  in the description.
>> +
>> +select: false
>> +  # 'select' is a schema applied to a DT node to determine if this binding
>> +  # schema should be applied to the node. It is optional and by default the
>> +  # possible compatible strings are extracted and used to match.
>
> My first reaction was that 'node' should somehow be included in the name
> of 'select'.  But my second thought was that maybe 'node' is implied,
> because every schema file describes a single node???  This is where my
> lack of knowledge kicks in - I'll go read stuff in your yaml-bindings
> repo to get a better background...

Yes, schema are applied to nodes and most of the current uses of
select are based on node name. We walk the DT and apply all the schema
for a node that select (either in the doc or generated from
compatible) is valid.


>> +
>> +properties:
>> +  # A dictionary of DT properties for this binding schema
>> +  compatible:
>> +# More complicated schema can use 

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Rob Herring]

On Fri, Apr 20, 2018 at 4:00 PM, Frank Rowand  wrote:
> Hi Rob,
>
> Thanks for the example.  It was a good starting tutorial of sorts for me
> to understand the format a bit.
>
>
> On 04/18/18 15:29, Rob Herring wrote:
>> The current DT binding documentation format of freeform text is painful
>> to write, review, validate and maintain.
>>
>> This is just an example of what a binding in the schema format looks
>> like. It's using jsonschema vocabulary in a YAML encoded document. Using
>> jsonschema gives us access to existing tooling. A YAML encoding gives us
>> something easy to edit.
>>
>> This example is just the tip of the iceberg, but it the part most
>> developers writing bindings will interact with. Backing all this up
>> are meta-schema (to validate the binding schemas), some DT core schema,
>> YAML encoded DT output with dtc, and a small number of python scripts to
>> run validation. The gory details including how to run end-to-end
>> validation can be found here:
>>
>> https://www.spinics.net/lists/devicetree-spec/msg00649.html
>>
>> Signed-off-by: Rob Herring 
>> ---
>> Cc list,
>> You all review and/or write lots of binding documents. I'd like some feedback
>> on the format.
>>
>> Thanks,
>> Rob
>>
>>  .../devicetree/bindings/example-schema.yaml| 149 
>> +
>>  1 file changed, 149 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/example-schema.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/example-schema.yaml 
>> b/Documentation/devicetree/bindings/example-schema.yaml
>> new file mode 100644
>> index ..fe0a3bd1668e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/example-schema.yaml
>
> I'm guessing by the path name that this is in the Linux kernel source tree.

Yes, well, my kernel tree. Most of the work still lives here:

https://github.com/robherring/yaml-bindings/

>> @@ -0,0 +1,149 @@
>> +# SPDX-License-Identifier: BSD-2-Clause
>
> If in the Linux kernel source tree, then allow gpl-v2 as a possible license.

Why? BSD is compatible. The license of the above repo is all BSD.

Of course there's all the existing docs which default to GPLv2 and
we'll probably have to maintain that.

>> +# Copyright 2018 Linaro Ltd.
>> +%YAML 1.2
>> +---
>> +# All the top-level keys are standard json-schema keywords except for
>> +# 'maintainers' and 'select'
>> +
>> +# $id is a unique idenifier based on the filename
>
>  ^  identifier
>
>> +$id: "http://devicetree.org/schemas/example-schema.yaml#;
>
> Does this imply that all schemas will be at devicetree.org instead
> of in the Linux kernel source tree?  This would be counter to my
> earlier guess about where this patch is applied.

They could be, but not necessarily. This is just convention in
jsonschema is the best I understand it.

I don't think you'd want validation to require an internet connection.
For the base meta-schema, for example, it does exist at
http://json-schema.org/draft-06/schema, but that's also distributed
with implementations of jsonschema validators.

A large part (not that any part is large) of the tools Grant and I
have written is doing the cross reference resolution of files which
uses the $id field.


>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
>
> How is $schema used?

Tells the validator what meta-schema this schema follows. Typically
you see draft04 or draft06 here if you haven't written a meta-schema.

> Is it accessed across the network?

Could be, but generally no.


>> +
>> +# Only 1 version supported for now
>> +version: 1
>> +
>> +title: An example schema annotated with jsonschema details
>> +
>> +maintainers:
>> +  - Rob Herring 
>> +
>> +description: |
>> +  A more detailed multi-line description of the binding.
>> +
>> +  Details about the hardware device and any links to datasheets can go here.
>> +
>> +  The end of the description is marked by indentation less than the first 
>> line
>> +  in the description.
>> +
>> +select: false
>> +  # 'select' is a schema applied to a DT node to determine if this binding
>> +  # schema should be applied to the node. It is optional and by default the
>> +  # possible compatible strings are extracted and used to match.
>
> My first reaction was that 'node' should somehow be included in the name
> of 'select'.  But my second thought was that maybe 'node' is implied,
> because every schema file describes a single node???  This is where my
> lack of knowledge kicks in - I'll go read stuff in your yaml-bindings
> repo to get a better background...

Yes, schema are applied to nodes and most of the current uses of
select are based on node name. We walk the DT and apply all the schema
for a node that select (either in the doc or generated from
compatible) is valid.


>> +
>> +properties:
>> +  # A dictionary of DT properties for this binding schema
>> +  compatible:
>> +# More complicated schema can use oneOf (XOR), anyOf (OR), or allOf 
>> (AND)
>> +# to 

Re: [PATCH 5/5] x86, pti: filter at vma->vm_page_prot population

[Nadav Amit]

Dave Hansen  wrote:

> 
> From: Dave Hansen 
> 
> 0day reported warnings at boot on 32-bit systems without NX support:
> 
> [   12.349193] attempted to set unsupported pgprot: 8025 bits: 
> 8000 supported: 7fff
> [   12.350792] WARNING: CPU: 0 PID: 1 at arch/x86/include/asm/pgtable.h:540 
> handle_mm_fault+0xfc1/0xfe0:
>   check_pgprot at 
> arch/x86/include/asm/pgtable.h:535
>(inlined by) pfn_pte at 
> arch/x86/include/asm/pgtable.h:549
>(inlined by) do_anonymous_page 
> at mm/memory.c:3169
>(inlined by) handle_pte_fault 
> at mm/memory.c:3961
>(inlined by) __handle_mm_fault 
> at mm/memory.c:4087
>(inlined by) handle_mm_fault 
> at mm/memory.c:4124
> 
> The problem was that we stopped massaging page permissions at PTE creation
> time, so vma->vm_page_prot was passed unfiltered to PTE creation.
> 
> To fix it, filter the page protections before they are installed in
> vma->vm_page_prot.
> 
> Signed-off-by: Dave Hansen 
> Reported-by: Fengguang Wu 
> Fixes: fb43d6cb91 ("x86/mm: Do not auto-massage page protections")
> Cc: Andrea Arcangeli 
> Cc: Andy Lutomirski 
> Cc: Arjan van de Ven 
> Cc: Borislav Petkov 
> Cc: Dan Williams 
> Cc: David Woodhouse 
> Cc: Greg Kroah-Hartman 
> Cc: Hugh Dickins 
> Cc: Josh Poimboeuf 
> Cc: Juergen Gross 
> Cc: Kees Cook 
> Cc: Linus Torvalds 
> Cc: Nadav Amit 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: linux...@kvack.org
> Cc: Ingo Molnar 
> ---
> 
> b/arch/x86/Kconfig   |4 
> b/arch/x86/include/asm/pgtable.h |5 +
> b/mm/mmap.c  |   11 ++-
> 3 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff -puN arch/x86/include/asm/pgtable.h~pti-glb-protection_map 
> arch/x86/include/asm/pgtable.h
> --- a/arch/x86/include/asm/pgtable.h~pti-glb-protection_map   2018-04-20 
> 14:10:08.251749151 -0700
> +++ b/arch/x86/include/asm/pgtable.h  2018-04-20 14:10:08.260749151 -0700
> @@ -601,6 +601,11 @@ static inline pgprot_t pgprot_modify(pgp
> 
> #define canon_pgprot(p) __pgprot(massage_pgprot(p))
> 
> +static inline pgprot_t arch_filter_pgprot(pgprot_t prot)
> +{
> + return canon_pgprot(prot);
> +}
> +
> static inline int is_new_memtype_allowed(u64 paddr, unsigned long size,
>enum page_cache_mode pcm,
>enum page_cache_mode new_pcm)
> diff -puN arch/x86/Kconfig~pti-glb-protection_map arch/x86/Kconfig
> --- a/arch/x86/Kconfig~pti-glb-protection_map 2018-04-20 14:10:08.253749151 
> -0700
> +++ b/arch/x86/Kconfig2018-04-20 14:10:08.260749151 -0700
> @@ -52,6 +52,7 @@ config X86
>   select ARCH_HAS_DEVMEM_IS_ALLOWED
>   select ARCH_HAS_ELF_RANDOMIZE
>   select ARCH_HAS_FAST_MULTIPLIER
> + select ARCH_HAS_FILTER_PGPROT
>   select ARCH_HAS_FORTIFY_SOURCE
>   select ARCH_HAS_GCOV_PROFILE_ALL
>   select ARCH_HAS_KCOVif X86_64
> @@ -273,6 +274,9 @@ config ARCH_HAS_CPU_RELAX
> config ARCH_HAS_CACHE_LINE_SIZE
>   def_bool y
> 
> +config ARCH_HAS_FILTER_PGPROT
> + def_bool y
> +
> config HAVE_SETUP_PER_CPU_AREA
>   def_bool y
> 
> diff -puN mm/mmap.c~pti-glb-protection_map mm/mmap.c
> --- a/mm/mmap.c~pti-glb-protection_map2018-04-20 14:10:08.256749151 
> -0700
> +++ b/mm/mmap.c   2018-04-20 14:10:08.261749151 -0700
> @@ -100,11 +100,20 @@ pgprot_t protection_map[16] __ro_after_i
>   __S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111
> };
> 
> +#ifndef CONFIG_ARCH_HAS_FILTER_PGPROT
> +static inline pgprot_t arch_filter_pgprot(pgprot_t prot)
> +{
> + return prot;
> +}
> +#endif
> +
> pgprot_t vm_get_page_prot(unsigned long vm_flags)
> {
> - return __pgprot(pgprot_val(protection_map[vm_flags &
> + pgprot_t ret = __pgprot(pgprot_val(protection_map[vm_flags &
>   (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
>   pgprot_val(arch_vm_get_page_prot(vm_flags)));
> +
> + return arch_filter_pgprot(ret);
> }
> EXPORT_SYMBOL(vm_get_page_prot);

Wouldn’t it be simpler or at least cleaner to change the protection map if
NX is not supported? I presume it can be done paging_init() similarly to the
way other archs (e.g., arm, mips) do.

RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Botello Ortega, Luis]

Hi all:

We tested GLK DMC 1.04 FW in last week of September 2017, using the latest 
drm-tip version for that time (4.14.0-rc2) and according to our results we 
could declare this FW as acceptable and healthy to be used with kernel version 
4.14 . 
However, we cannot guarantee quality and healthy of this FW if it is used in 
top of current drm-tip kernel (4.17-rc0).

Best Regards
Luis Botello


-Original Message-
From: Srivatsa, Anusha 
Sent: Friday, April 20, 2018 1:30 PM
To: Vivi, Rodrigo ; Jani Nikula 
; Botello Ortega, Luis 
; Martinez Monroy, Elio 

Cc: Ian W MORRISON ; airl...@linux.ie; Greg KH 
; intel-...@lists.freedesktop.org; 
linux-kernel@vger.kernel.org; sta...@vger.kernel.org; 
dri-de...@lists.freedesktop.org; Wajdeczko, Michal 
Subject: RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake



>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, April 20, 2018 11:04 AM
>To: Jani Nikula 
>Cc: Srivatsa, Anusha ; Ian W MORRISON 
>; airl...@linux.ie; Greg KH 
>; intel-...@lists.freedesktop.org; linux- 
>ker...@vger.kernel.org; sta...@vger.kernel.org; dri- 
>de...@lists.freedesktop.org; Wajdeczko, Michal 
>
>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for 
>Geminilake
>
>On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote:
>> On Mon, 16 Apr 2018, "Srivatsa, Anusha"  wrote:
>> >>-Original Message-
>> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >>Sent: Wednesday, April 11, 2018 5:27 AM
>> >>To: Ian W MORRISON 
>> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha 
>> >>; Wajdeczko, Michal 
>> >>; Greg KH ; 
>> >>airl...@linux.ie; joonas.lahti...@linux.intel.com; 
>> >>linux-kernel@vger.kernel.org; sta...@vger.kernel.org; 
>> >>intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org
>> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE 
>> >>for Geminilake
>> >>
>> >>On Wed, 11 Apr 2018, Ian W MORRISON  wrote:
>> >>> 
>> >>>
>> 
>>  NAK on indiscriminate Cc: stable. There are zero guarantees that 
>>  older kernels will work with whatever firmware you throw at them.
>> 
>> >>>
>> >>> I included 'Cc: stable' so the patch would get added to the v4.16 
>> >>> and
>> >>> v4.15 kernels which I have tested with the patch. I found that 
>> >>> earlier kernels didn't support the 'linux-firmware' package 
>> >>> required to get wifi working on Intel's new Gemini Lake NUC.
>> >>
>> >>You realize that this patch should have nothing to do with wifi?
>> >>
>> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please 
>> >>indicate the specific versions of stable it is appropriate for.
>> >
>> > Hi Jani,
>> >
>> > The stable kernel version is 4.12 and beyond.
>> > It is appropriate to add the CC: stable in my opinion
>>
>> Who tested the firmware with v4.12 and later? We only have the CI 
>> results against *current* drm-tip. We don't even know about v4.16.
>>
>
>I understand your concerns, but the problem was that our old process 
>was a bit
>(lot?) messed and there was the unreliable time until the firmware 
>really lands on linux-firmware.git. So MODULE_FIRMWARE call was only 
>added after firmware was really there on firmware repository but it wasn't 
>about the testing.
>
>In other words, the bump version patch was merged after tested, but 
>MODULE_FIRMWARE was left behind because firmware blob took a while to 
>get pulled into linux-firmware.git and we end up forgetting to add it there.
>
>In my opinion it should be safe to add the MODULE_FIRMWARE there based 
>on the tests from when the version was bumped.

Luis, Elio, can you guys confirm that this firmware is tested and healthy? And 
also, give a tested-by to this patch please?

Thanks,
Anusha 
>> I'm not going to ack and take responsibility for the stable backports 
>> unless someone actually comes forward with credible Tested-bys.
>>
>> BR,
>> Jani.
>>
>>
>> >
>> > Anusha
>> >>BR,
>> >>Jani.
>> >>
>> >>>
>> 
>>  PS. How is this a "RESEND"? I haven't seen this before.
>> 
>> >>>
>> >>> It is a 'RESEND' for that very reason. I initially sent the patch 
>> >>> to the same people as a similar patch
>> >>> (https://patchwork.kernel.org/patch/10143637/) however after 
>> >>> realising this omitted required addresses I added them and resent 
>> >>> the
>patch.
>> >>>
>> >>> Best regards,
>> >>> Ian
>> >>
>> >>--
>> >>Jani Nikula, Intel Open Source Technology Center
>>
>> --
>> Jani Nikula, Intel Open Source 

Re: [PATCH 5/5] x86, pti: filter at vma->vm_page_prot population

[Nadav Amit]

Dave Hansen  wrote:

> 
> From: Dave Hansen 
> 
> 0day reported warnings at boot on 32-bit systems without NX support:
> 
> [   12.349193] attempted to set unsupported pgprot: 8025 bits: 
> 8000 supported: 7fff
> [   12.350792] WARNING: CPU: 0 PID: 1 at arch/x86/include/asm/pgtable.h:540 
> handle_mm_fault+0xfc1/0xfe0:
>   check_pgprot at 
> arch/x86/include/asm/pgtable.h:535
>(inlined by) pfn_pte at 
> arch/x86/include/asm/pgtable.h:549
>(inlined by) do_anonymous_page 
> at mm/memory.c:3169
>(inlined by) handle_pte_fault 
> at mm/memory.c:3961
>(inlined by) __handle_mm_fault 
> at mm/memory.c:4087
>(inlined by) handle_mm_fault 
> at mm/memory.c:4124
> 
> The problem was that we stopped massaging page permissions at PTE creation
> time, so vma->vm_page_prot was passed unfiltered to PTE creation.
> 
> To fix it, filter the page protections before they are installed in
> vma->vm_page_prot.
> 
> Signed-off-by: Dave Hansen 
> Reported-by: Fengguang Wu 
> Fixes: fb43d6cb91 ("x86/mm: Do not auto-massage page protections")
> Cc: Andrea Arcangeli 
> Cc: Andy Lutomirski 
> Cc: Arjan van de Ven 
> Cc: Borislav Petkov 
> Cc: Dan Williams 
> Cc: David Woodhouse 
> Cc: Greg Kroah-Hartman 
> Cc: Hugh Dickins 
> Cc: Josh Poimboeuf 
> Cc: Juergen Gross 
> Cc: Kees Cook 
> Cc: Linus Torvalds 
> Cc: Nadav Amit 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Cc: linux...@kvack.org
> Cc: Ingo Molnar 
> ---
> 
> b/arch/x86/Kconfig   |4 
> b/arch/x86/include/asm/pgtable.h |5 +
> b/mm/mmap.c  |   11 ++-
> 3 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff -puN arch/x86/include/asm/pgtable.h~pti-glb-protection_map 
> arch/x86/include/asm/pgtable.h
> --- a/arch/x86/include/asm/pgtable.h~pti-glb-protection_map   2018-04-20 
> 14:10:08.251749151 -0700
> +++ b/arch/x86/include/asm/pgtable.h  2018-04-20 14:10:08.260749151 -0700
> @@ -601,6 +601,11 @@ static inline pgprot_t pgprot_modify(pgp
> 
> #define canon_pgprot(p) __pgprot(massage_pgprot(p))
> 
> +static inline pgprot_t arch_filter_pgprot(pgprot_t prot)
> +{
> + return canon_pgprot(prot);
> +}
> +
> static inline int is_new_memtype_allowed(u64 paddr, unsigned long size,
>enum page_cache_mode pcm,
>enum page_cache_mode new_pcm)
> diff -puN arch/x86/Kconfig~pti-glb-protection_map arch/x86/Kconfig
> --- a/arch/x86/Kconfig~pti-glb-protection_map 2018-04-20 14:10:08.253749151 
> -0700
> +++ b/arch/x86/Kconfig2018-04-20 14:10:08.260749151 -0700
> @@ -52,6 +52,7 @@ config X86
>   select ARCH_HAS_DEVMEM_IS_ALLOWED
>   select ARCH_HAS_ELF_RANDOMIZE
>   select ARCH_HAS_FAST_MULTIPLIER
> + select ARCH_HAS_FILTER_PGPROT
>   select ARCH_HAS_FORTIFY_SOURCE
>   select ARCH_HAS_GCOV_PROFILE_ALL
>   select ARCH_HAS_KCOVif X86_64
> @@ -273,6 +274,9 @@ config ARCH_HAS_CPU_RELAX
> config ARCH_HAS_CACHE_LINE_SIZE
>   def_bool y
> 
> +config ARCH_HAS_FILTER_PGPROT
> + def_bool y
> +
> config HAVE_SETUP_PER_CPU_AREA
>   def_bool y
> 
> diff -puN mm/mmap.c~pti-glb-protection_map mm/mmap.c
> --- a/mm/mmap.c~pti-glb-protection_map2018-04-20 14:10:08.256749151 
> -0700
> +++ b/mm/mmap.c   2018-04-20 14:10:08.261749151 -0700
> @@ -100,11 +100,20 @@ pgprot_t protection_map[16] __ro_after_i
>   __S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111
> };
> 
> +#ifndef CONFIG_ARCH_HAS_FILTER_PGPROT
> +static inline pgprot_t arch_filter_pgprot(pgprot_t prot)
> +{
> + return prot;
> +}
> +#endif
> +
> pgprot_t vm_get_page_prot(unsigned long vm_flags)
> {
> - return __pgprot(pgprot_val(protection_map[vm_flags &
> + pgprot_t ret = __pgprot(pgprot_val(protection_map[vm_flags &
>   (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) |
>   pgprot_val(arch_vm_get_page_prot(vm_flags)));
> +
> + return arch_filter_pgprot(ret);
> }
> EXPORT_SYMBOL(vm_get_page_prot);

Wouldn’t it be simpler or at least cleaner to change the protection map if
NX is not supported? I presume it can be done paging_init() similarly to the
way other archs (e.g., arm, mips) do.

RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Botello Ortega, Luis]

Hi all:

We tested GLK DMC 1.04 FW in last week of September 2017, using the latest 
drm-tip version for that time (4.14.0-rc2) and according to our results we 
could declare this FW as acceptable and healthy to be used with kernel version 
4.14 . 
However, we cannot guarantee quality and healthy of this FW if it is used in 
top of current drm-tip kernel (4.17-rc0).

Best Regards
Luis Botello


-Original Message-
From: Srivatsa, Anusha 
Sent: Friday, April 20, 2018 1:30 PM
To: Vivi, Rodrigo ; Jani Nikula 
; Botello Ortega, Luis 
; Martinez Monroy, Elio 

Cc: Ian W MORRISON ; airl...@linux.ie; Greg KH 
; intel-...@lists.freedesktop.org; 
linux-kernel@vger.kernel.org; sta...@vger.kernel.org; 
dri-de...@lists.freedesktop.org; Wajdeczko, Michal 
Subject: RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake



>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, April 20, 2018 11:04 AM
>To: Jani Nikula 
>Cc: Srivatsa, Anusha ; Ian W MORRISON 
>; airl...@linux.ie; Greg KH 
>; intel-...@lists.freedesktop.org; linux- 
>ker...@vger.kernel.org; sta...@vger.kernel.org; dri- 
>de...@lists.freedesktop.org; Wajdeczko, Michal 
>
>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for 
>Geminilake
>
>On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote:
>> On Mon, 16 Apr 2018, "Srivatsa, Anusha"  wrote:
>> >>-Original Message-
>> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >>Sent: Wednesday, April 11, 2018 5:27 AM
>> >>To: Ian W MORRISON 
>> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha 
>> >>; Wajdeczko, Michal 
>> >>; Greg KH ; 
>> >>airl...@linux.ie; joonas.lahti...@linux.intel.com; 
>> >>linux-kernel@vger.kernel.org; sta...@vger.kernel.org; 
>> >>intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org
>> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE 
>> >>for Geminilake
>> >>
>> >>On Wed, 11 Apr 2018, Ian W MORRISON  wrote:
>> >>> 
>> >>>
>> 
>>  NAK on indiscriminate Cc: stable. There are zero guarantees that 
>>  older kernels will work with whatever firmware you throw at them.
>> 
>> >>>
>> >>> I included 'Cc: stable' so the patch would get added to the v4.16 
>> >>> and
>> >>> v4.15 kernels which I have tested with the patch. I found that 
>> >>> earlier kernels didn't support the 'linux-firmware' package 
>> >>> required to get wifi working on Intel's new Gemini Lake NUC.
>> >>
>> >>You realize that this patch should have nothing to do with wifi?
>> >>
>> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please 
>> >>indicate the specific versions of stable it is appropriate for.
>> >
>> > Hi Jani,
>> >
>> > The stable kernel version is 4.12 and beyond.
>> > It is appropriate to add the CC: stable in my opinion
>>
>> Who tested the firmware with v4.12 and later? We only have the CI 
>> results against *current* drm-tip. We don't even know about v4.16.
>>
>
>I understand your concerns, but the problem was that our old process 
>was a bit
>(lot?) messed and there was the unreliable time until the firmware 
>really lands on linux-firmware.git. So MODULE_FIRMWARE call was only 
>added after firmware was really there on firmware repository but it wasn't 
>about the testing.
>
>In other words, the bump version patch was merged after tested, but 
>MODULE_FIRMWARE was left behind because firmware blob took a while to 
>get pulled into linux-firmware.git and we end up forgetting to add it there.
>
>In my opinion it should be safe to add the MODULE_FIRMWARE there based 
>on the tests from when the version was bumped.

Luis, Elio, can you guys confirm that this firmware is tested and healthy? And 
also, give a tested-by to this patch please?

Thanks,
Anusha 
>> I'm not going to ack and take responsibility for the stable backports 
>> unless someone actually comes forward with credible Tested-bys.
>>
>> BR,
>> Jani.
>>
>>
>> >
>> > Anusha
>> >>BR,
>> >>Jani.
>> >>
>> >>>
>> 
>>  PS. How is this a "RESEND"? I haven't seen this before.
>> 
>> >>>
>> >>> It is a 'RESEND' for that very reason. I initially sent the patch 
>> >>> to the same people as a similar patch
>> >>> (https://patchwork.kernel.org/patch/10143637/) however after 
>> >>> realising this omitted required addresses I added them and resent 
>> >>> the
>patch.
>> >>>
>> >>> Best regards,
>> >>> Ian
>> >>
>> >>--
>> >>Jani Nikula, Intel Open Source Technology Center
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center 
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/13] staging: iio: tsl2x7x: use GPL-2.0+ SPDX license identifier

[Brian Masney]

The summary text for the GPL is not needed since the SPDX identifier
is a legally binding shorthand that can be used instead.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 10 +-
 drivers/staging/iio/light/tsl2x7x.h | 14 +-
 2 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index eeccfbb0eb1f..9cdcc8c9e812 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -5,15 +5,7 @@
  * Copyright (c) 2012, TAOS Corporation.
  * Copyright (c) 2017-2018 Brian Masney 
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
+ * SPDX-License-Identifier: GPL-2.0+
  */
 
 #include 
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index d382cdbb976e..992ee2465609 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -4,19 +4,7 @@
  *
  * Copyright (c) 2012, TAOS Corporation.
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ * SPDX-License-Identifier: GPL-2.0+
  */
 
 #ifndef __TSL2X7X_H
-- 
2.14.3

[PATCH 02/13] staging: iio: tsl2x7x: use GPL-2.0+ SPDX license identifier

[Brian Masney]

The summary text for the GPL is not needed since the SPDX identifier
is a legally binding shorthand that can be used instead.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 10 +-
 drivers/staging/iio/light/tsl2x7x.h | 14 +-
 2 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index eeccfbb0eb1f..9cdcc8c9e812 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -5,15 +5,7 @@
  * Copyright (c) 2012, TAOS Corporation.
  * Copyright (c) 2017-2018 Brian Masney 
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
+ * SPDX-License-Identifier: GPL-2.0+
  */
 
 #include 
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index d382cdbb976e..992ee2465609 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -4,19 +4,7 @@
  *
  * Copyright (c) 2012, TAOS Corporation.
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ * SPDX-License-Identifier: GPL-2.0+
  */
 
 #ifndef __TSL2X7X_H
-- 
2.14.3

[PATCH 03/13] staging: iio: tsl2x7x: don't return error in IRQ handler

[Brian Masney]

tsl2x7x_event_handler() could return an error and this could cause the
interrupt to remain masked. We shouldn't return an error in the
interrupt handler so this patch always returns IRQ_HANDLED. An error
will be logged if one occurs.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 9cdcc8c9e812..95a00b965c5e 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -1320,7 +1320,7 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
 
ret = tsl2x7x_read_status(chip);
if (ret < 0)
-   return ret;
+   return IRQ_HANDLED;
 
/* What type of interrupt do we need to process */
if (ret & TSL2X7X_STA_PRX_INTR) {
@@ -1341,9 +1341,7 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
   timestamp);
}
 
-   ret = tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_PROXALS_INT_CLR);
-   if (ret < 0)
-   return ret;
+   tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_PROXALS_INT_CLR);
 
return IRQ_HANDLED;
 }
-- 
2.14.3

[PATCH 04/13] staging: iio: tsl2x7x: simplify tsl2x7x_clear_interrupts function

[Brian Masney]

tsl2x7x_clear_interrupts() takes a reg argument but there are only
two callers to this function and both callers pass the same value.
Since this function was introduced, interrupts are now working
properly for this driver, and several unnecessary calls to
tsl2x7x_clear_interrupts() were removed. This patch removes the
tsl2x7x_clear_interrupts() function and replaces the two callers
with the i2c_smbus_write_byte() call instead.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 95a00b965c5e..f37fc74b8fbc 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -271,20 +271,6 @@ static const u8 device_channel_config[] = {
ALSPRX2
 };
 
-static int tsl2x7x_clear_interrupts(struct tsl2X7X_chip *chip, int reg)
-{
-   int ret;
-
-   ret = i2c_smbus_write_byte(chip->client,
-  TSL2X7X_CMD_REG | TSL2X7X_CMD_SPL_FN | reg);
-   if (ret < 0)
-   dev_err(>client->dev,
-   "%s: failed to clear interrupt status %x: %d\n",
-   __func__, reg, ret);
-
-   return ret;
-}
-
 static int tsl2x7x_read_status(struct tsl2X7X_chip *chip)
 {
int ret;
@@ -714,9 +700,15 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
if (ret < 0)
return ret;
 
-   ret = tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_PROXALS_INT_CLR);
-   if (ret < 0)
+   ret = i2c_smbus_write_byte(chip->client,
+  TSL2X7X_CMD_REG | TSL2X7X_CMD_SPL_FN |
+  TSL2X7X_CMD_PROXALS_INT_CLR);
+   if (ret < 0) {
+   dev_err(>client->dev,
+   "%s: failed to clear interrupt status: %d\n",
+   __func__, ret);
return ret;
+   }
 
chip->tsl2x7x_chip_status = TSL2X7X_CHIP_WORKING;
 
@@ -1341,7 +1333,13 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
   timestamp);
}
 
-   tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_PROXALS_INT_CLR);
+   ret = i2c_smbus_write_byte(chip->client,
+  TSL2X7X_CMD_REG | TSL2X7X_CMD_SPL_FN |
+  TSL2X7X_CMD_PROXALS_INT_CLR);
+   if (ret < 0)
+   dev_err(>client->dev,
+   "%s: failed to clear interrupt status: %d\n",
+   __func__, ret);
 
return IRQ_HANDLED;
 }
-- 
2.14.3

[PATCH 03/13] staging: iio: tsl2x7x: don't return error in IRQ handler

[Brian Masney]

tsl2x7x_event_handler() could return an error and this could cause the
interrupt to remain masked. We shouldn't return an error in the
interrupt handler so this patch always returns IRQ_HANDLED. An error
will be logged if one occurs.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 9cdcc8c9e812..95a00b965c5e 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -1320,7 +1320,7 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
 
ret = tsl2x7x_read_status(chip);
if (ret < 0)
-   return ret;
+   return IRQ_HANDLED;
 
/* What type of interrupt do we need to process */
if (ret & TSL2X7X_STA_PRX_INTR) {
@@ -1341,9 +1341,7 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
   timestamp);
}
 
-   ret = tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_PROXALS_INT_CLR);
-   if (ret < 0)
-   return ret;
+   tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_PROXALS_INT_CLR);
 
return IRQ_HANDLED;
 }
-- 
2.14.3

[PATCH 04/13] staging: iio: tsl2x7x: simplify tsl2x7x_clear_interrupts function

[Brian Masney]

tsl2x7x_clear_interrupts() takes a reg argument but there are only
two callers to this function and both callers pass the same value.
Since this function was introduced, interrupts are now working
properly for this driver, and several unnecessary calls to
tsl2x7x_clear_interrupts() were removed. This patch removes the
tsl2x7x_clear_interrupts() function and replaces the two callers
with the i2c_smbus_write_byte() call instead.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 95a00b965c5e..f37fc74b8fbc 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -271,20 +271,6 @@ static const u8 device_channel_config[] = {
ALSPRX2
 };
 
-static int tsl2x7x_clear_interrupts(struct tsl2X7X_chip *chip, int reg)
-{
-   int ret;
-
-   ret = i2c_smbus_write_byte(chip->client,
-  TSL2X7X_CMD_REG | TSL2X7X_CMD_SPL_FN | reg);
-   if (ret < 0)
-   dev_err(>client->dev,
-   "%s: failed to clear interrupt status %x: %d\n",
-   __func__, reg, ret);
-
-   return ret;
-}
-
 static int tsl2x7x_read_status(struct tsl2X7X_chip *chip)
 {
int ret;
@@ -714,9 +700,15 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
if (ret < 0)
return ret;
 
-   ret = tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_PROXALS_INT_CLR);
-   if (ret < 0)
+   ret = i2c_smbus_write_byte(chip->client,
+  TSL2X7X_CMD_REG | TSL2X7X_CMD_SPL_FN |
+  TSL2X7X_CMD_PROXALS_INT_CLR);
+   if (ret < 0) {
+   dev_err(>client->dev,
+   "%s: failed to clear interrupt status: %d\n",
+   __func__, ret);
return ret;
+   }
 
chip->tsl2x7x_chip_status = TSL2X7X_CHIP_WORKING;
 
@@ -1341,7 +1333,13 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
   timestamp);
}
 
-   tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_PROXALS_INT_CLR);
+   ret = i2c_smbus_write_byte(chip->client,
+  TSL2X7X_CMD_REG | TSL2X7X_CMD_SPL_FN |
+  TSL2X7X_CMD_PROXALS_INT_CLR);
+   if (ret < 0)
+   dev_err(>client->dev,
+   "%s: failed to clear interrupt status: %d\n",
+   __func__, ret);
 
return IRQ_HANDLED;
 }
-- 
2.14.3

[PATCH 05/13] staging: iio: tsl2x7x: remove unnecessary chip status checks in suspend/resume

[Brian Masney]

tsl2x7x_suspend() and tsl2x7x_resume() both check to see what the
current chip status is. These checks are not necessary so this patch
removes those checks.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index f37fc74b8fbc..8d8af0cf9768 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -1682,27 +1682,15 @@ static int tsl2x7x_probe(struct i2c_client *clientp,
 static int tsl2x7x_suspend(struct device *dev)
 {
struct iio_dev *indio_dev = dev_get_drvdata(dev);
-   struct tsl2X7X_chip *chip = iio_priv(indio_dev);
-   int ret = 0;
-
-   if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_WORKING) {
-   ret = tsl2x7x_chip_off(indio_dev);
-   chip->tsl2x7x_chip_status = TSL2X7X_CHIP_SUSPENDED;
-   }
 
-   return ret;
+   return tsl2x7x_chip_off(indio_dev);
 }
 
 static int tsl2x7x_resume(struct device *dev)
 {
struct iio_dev *indio_dev = dev_get_drvdata(dev);
-   struct tsl2X7X_chip *chip = iio_priv(indio_dev);
-   int ret = 0;
 
-   if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_SUSPENDED)
-   ret = tsl2x7x_chip_on(indio_dev);
-
-   return ret;
+   return tsl2x7x_chip_on(indio_dev);
 }
 
 static int tsl2x7x_remove(struct i2c_client *client)
-- 
2.14.3

[PATCH 05/13] staging: iio: tsl2x7x: remove unnecessary chip status checks in suspend/resume

[Brian Masney]

tsl2x7x_suspend() and tsl2x7x_resume() both check to see what the
current chip status is. These checks are not necessary so this patch
removes those checks.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index f37fc74b8fbc..8d8af0cf9768 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -1682,27 +1682,15 @@ static int tsl2x7x_probe(struct i2c_client *clientp,
 static int tsl2x7x_suspend(struct device *dev)
 {
struct iio_dev *indio_dev = dev_get_drvdata(dev);
-   struct tsl2X7X_chip *chip = iio_priv(indio_dev);
-   int ret = 0;
-
-   if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_WORKING) {
-   ret = tsl2x7x_chip_off(indio_dev);
-   chip->tsl2x7x_chip_status = TSL2X7X_CHIP_SUSPENDED;
-   }
 
-   return ret;
+   return tsl2x7x_chip_off(indio_dev);
 }
 
 static int tsl2x7x_resume(struct device *dev)
 {
struct iio_dev *indio_dev = dev_get_drvdata(dev);
-   struct tsl2X7X_chip *chip = iio_priv(indio_dev);
-   int ret = 0;
 
-   if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_SUSPENDED)
-   ret = tsl2x7x_chip_on(indio_dev);
-
-   return ret;
+   return tsl2x7x_chip_on(indio_dev);
 }
 
 static int tsl2x7x_remove(struct i2c_client *client)
-- 
2.14.3

[PATCH 08/13] staging: iio: tsl2x7x: add range checking to three sysfs attributes

[Brian Masney]

The sysfs attributes in_illuminance0_target_input,
in_illuminance0_calibrate, and in_proximity0_calibrate did not have
proper range checking in place so this patch adds the correct range
checks.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 56730baea927..15bc0af1bb6c 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -835,9 +835,10 @@ static ssize_t in_illuminance0_target_input_store(struct 
device *dev,
if (kstrtoul(buf, 0, ))
return -EINVAL;
 
-   if (value)
-   chip->settings.als_cal_target = value;
+   if (value < 0 || value > 65535)
+   return -ERANGE;
 
+   chip->settings.als_cal_target = value;
ret = tsl2x7x_invoke_change(indio_dev);
if (ret < 0)
return ret;
@@ -853,14 +854,12 @@ static ssize_t in_illuminance0_calibrate_store(struct 
device *dev,
bool value;
int ret;
 
-   if (strtobool(buf, ))
+   if (kstrtobool(buf, ) || !value)
return -EINVAL;
 
-   if (value) {
-   ret = tsl2x7x_als_calibrate(indio_dev);
-   if (ret < 0)
-   return ret;
-   }
+   ret = tsl2x7x_als_calibrate(indio_dev);
+   if (ret < 0)
+   return ret;
 
ret = tsl2x7x_invoke_change(indio_dev);
if (ret < 0)
@@ -946,14 +945,12 @@ static ssize_t in_proximity0_calibrate_store(struct 
device *dev,
bool value;
int ret;
 
-   if (strtobool(buf, ))
+   if (kstrtobool(buf, ) || !value)
return -EINVAL;
 
-   if (value) {
-   ret = tsl2x7x_prox_cal(indio_dev);
-   if (ret < 0)
-   return ret;
-   }
+   ret = tsl2x7x_prox_cal(indio_dev);
+   if (ret < 0)
+   return ret;
 
ret = tsl2x7x_invoke_change(indio_dev);
if (ret < 0)
-- 
2.14.3

[PATCH 08/13] staging: iio: tsl2x7x: add range checking to three sysfs attributes

[Brian Masney]

The sysfs attributes in_illuminance0_target_input,
in_illuminance0_calibrate, and in_proximity0_calibrate did not have
proper range checking in place so this patch adds the correct range
checks.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 56730baea927..15bc0af1bb6c 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -835,9 +835,10 @@ static ssize_t in_illuminance0_target_input_store(struct 
device *dev,
if (kstrtoul(buf, 0, ))
return -EINVAL;
 
-   if (value)
-   chip->settings.als_cal_target = value;
+   if (value < 0 || value > 65535)
+   return -ERANGE;
 
+   chip->settings.als_cal_target = value;
ret = tsl2x7x_invoke_change(indio_dev);
if (ret < 0)
return ret;
@@ -853,14 +854,12 @@ static ssize_t in_illuminance0_calibrate_store(struct 
device *dev,
bool value;
int ret;
 
-   if (strtobool(buf, ))
+   if (kstrtobool(buf, ) || !value)
return -EINVAL;
 
-   if (value) {
-   ret = tsl2x7x_als_calibrate(indio_dev);
-   if (ret < 0)
-   return ret;
-   }
+   ret = tsl2x7x_als_calibrate(indio_dev);
+   if (ret < 0)
+   return ret;
 
ret = tsl2x7x_invoke_change(indio_dev);
if (ret < 0)
@@ -946,14 +945,12 @@ static ssize_t in_proximity0_calibrate_store(struct 
device *dev,
bool value;
int ret;
 
-   if (strtobool(buf, ))
+   if (kstrtobool(buf, ) || !value)
return -EINVAL;
 
-   if (value) {
-   ret = tsl2x7x_prox_cal(indio_dev);
-   if (ret < 0)
-   return ret;
-   }
+   ret = tsl2x7x_prox_cal(indio_dev);
+   if (ret < 0)
+   return ret;
 
ret = tsl2x7x_invoke_change(indio_dev);
if (ret < 0)
-- 
2.14.3

[PATCH 06/13] staging: iio: tsl2x7x: simplify tsl2x7x_write_interrupt_config return

[Brian Masney]

tsl2x7x_write_interrupt_config() has an unnecessary return value check
at the end of the function. This patch changes the function to just
return the value from the call to tsl2x7x_invoke_change().

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 8d8af0cf9768..d202bc7e1f4f 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -982,18 +982,13 @@ static int tsl2x7x_write_interrupt_config(struct iio_dev 
*indio_dev,
  int val)
 {
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
-   int ret;
 
if (chan->type == IIO_INTENSITY)
chip->settings.als_interrupt_en = val ? true : false;
else
chip->settings.prox_interrupt_en = val ? true : false;
 
-   ret = tsl2x7x_invoke_change(indio_dev);
-   if (ret < 0)
-   return ret;
-
-   return 0;
+   return tsl2x7x_invoke_change(indio_dev);
 }
 
 static int tsl2x7x_write_event_value(struct iio_dev *indio_dev,
-- 
2.14.3

[PATCH 07/13] staging: iio: tsl2x7x: simplify device id verification

[Brian Masney]

This patch renames tsl2x7x_device_id() to tsl2x7x_device_id_verif(),
removes the unnecessary pointer on the id parameter, and only calls
the verification function once.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index d202bc7e1f4f..56730baea927 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -1277,22 +1277,22 @@ static DEVICE_ATTR_WO(in_proximity0_calibrate);
 static DEVICE_ATTR_RW(in_illuminance0_lux_table);
 
 /* Use the default register values to identify the Taos device */
-static int tsl2x7x_device_id(int *id, int target)
+static int tsl2x7x_device_id_verif(int id, int target)
 {
switch (target) {
case tsl2571:
case tsl2671:
case tsl2771:
-   return (*id & 0xf0) == TRITON_ID;
+   return (id & 0xf0) == TRITON_ID;
case tmd2671:
case tmd2771:
-   return (*id & 0xf0) == HALIBUT_ID;
+   return (id & 0xf0) == HALIBUT_ID;
case tsl2572:
case tsl2672:
case tmd2672:
case tsl2772:
case tmd2772:
-   return (*id & 0xf0) == SWORDFISH_ID;
+   return (id & 0xf0) == SWORDFISH_ID;
}
 
return -EINVAL;
@@ -1612,8 +1612,7 @@ static int tsl2x7x_probe(struct i2c_client *clientp,
if (ret < 0)
return ret;
 
-   if ((!tsl2x7x_device_id(, id->driver_data)) ||
-   (tsl2x7x_device_id(, id->driver_data) == -EINVAL)) {
+   if (tsl2x7x_device_id_verif(ret, id->driver_data) <= 0) {
dev_info(>client->dev,
 "%s: i2c device found does not match expected id\n",
__func__);
-- 
2.14.3

[PATCH 09/13] staging: iio: tsl2x7x: move power and diode settings into header file

[Brian Masney]

The power and diode defines are needed for the platform data so this
patch moves the defines out of the .c file and into the header file. A
comment for the diode is also cleaned up while this code is touched.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 12 
 drivers/staging/iio/light/tsl2x7x.h | 12 
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 15bc0af1bb6c..87b99deef7a8 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -103,18 +103,6 @@
 #define TSL2X7X_CNTL_PROXPON_ENBL  0x0F
 #define TSL2X7X_CNTL_INTPROXPON_ENBL   0x2F
 
-/*Prox diode to use */
-#define TSL2X7X_DIODE0 0x01
-#define TSL2X7X_DIODE1 0x02
-#define TSL2X7X_DIODE_BOTH 0x03
-
-/* LED Power */
-#define TSL2X7X_100_mA 0x00
-#define TSL2X7X_50_mA  0x01
-#define TSL2X7X_25_mA  0x02
-#define TSL2X7X_13_mA  0x03
-#define TSL2X7X_MAX_TIMER_CNT  0xFF
-
 #define TSL2X7X_MIN_ITIME  3
 
 /* TAOS txx2x7x Device family members */
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index 992ee2465609..2c96f0b39b1e 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -23,6 +23,18 @@ struct tsl2x7x_lux {
 #define TSL2X7X_DEFAULT_TABLE_BYTES (sizeof(struct tsl2x7x_lux) * \
 TSL2X7X_DEF_LUX_TABLE_SZ)
 
+/* Proximity diode to use */
+#define TSL2X7X_DIODE0  0x01
+#define TSL2X7X_DIODE1  0x02
+#define TSL2X7X_DIODE_BOTH  0x03
+
+/* LED Power */
+#define TSL2X7X_100_mA  0x00
+#define TSL2X7X_50_mA   0x01
+#define TSL2X7X_25_mA   0x02
+#define TSL2X7X_13_mA   0x03
+#define TSL2X7X_MAX_TIMER_CNT   0xFF
+
 /**
  * struct tsl2x7x_default_settings - power on defaults unless
  *   overridden by platform data.
-- 
2.14.3

[PATCH 13/13] staging: iio: tsl2x7x: rename prox_config to als_prox_config

[Brian Masney]

The configuration register on the device is represented with the
prox_config member on the tsl2x7x_settings structure. According to the
TSL2772 data sheet, this register can hold: 1) the proximity drive
level, 2) ALS/Proximity long wait, and 3) the ALS gain level. This
patch renames prox_config to als_prox_config since ALS settings can
be stored here as well.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 7 ---
 drivers/staging/iio/light/tsl2x7x.h | 5 +++--
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 05c0f3d5fac0..708b2c6bdf4b 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -56,7 +56,7 @@
 #define TSL2X7X_PRX_MAXTHRESHLO0X0A
 #define TSL2X7X_PRX_MAXTHRESHHI0X0B
 #define TSL2X7X_PERSISTENCE0x0C
-#define TSL2X7X_PRX_CONFIG 0x0D
+#define TSL2X7X_ALS_PRX_CONFIG 0x0D
 #define TSL2X7X_PRX_COUNT  0x0E
 #define TSL2X7X_GAIN   0x0F
 #define TSL2X7X_NOTUSED0x10
@@ -207,7 +207,7 @@ static const struct tsl2x7x_settings 
tsl2x7x_default_settings = {
.prox_time = 255, /* 2.73 ms */
.prox_gain = 0,
.wait_time = 255,
-   .prox_config = 0,
+   .als_prox_config = 0,
.als_gain_trim = 1000,
.als_cal_target = 150,
.als_persistence = 1,
@@ -594,7 +594,8 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
/* Non calculated parameters */
chip->tsl2x7x_config[TSL2X7X_PRX_TIME] = chip->settings.prox_time;
chip->tsl2x7x_config[TSL2X7X_WAIT_TIME] = chip->settings.wait_time;
-   chip->tsl2x7x_config[TSL2X7X_PRX_CONFIG] = chip->settings.prox_config;
+   chip->tsl2x7x_config[TSL2X7X_ALS_PRX_CONFIG] =
+   chip->settings.als_prox_config;
 
chip->tsl2x7x_config[TSL2X7X_ALS_MINTHRESHLO] =
(chip->settings.als_thresh_low) & 0xFF;
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index 85d8fe7a94c8..6e30e71a2127 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -48,7 +48,8 @@ struct tsl2x7x_lux {
  *  increments. Total integration time is
  *  (256 - prx_time) * 2.73.
  *  @prox_gain: Index into the tsl2x7x_prx_gain array.
- *  @prox_config:   Prox configuration filters.
+ *  @als_prox_config:   The value of the ALS / Proximity configuration
+ *  register.
  *  @als_cal_target:Known external ALS reading for calibration.
  *  @als_persistence:   H/W Filters, Number of 'out of limits' ALS 
readings.
  *  @als_interrupt_en:  Enable/Disable ALS interrupts
@@ -73,7 +74,7 @@ struct tsl2x7x_settings {
int wait_time;
int prox_time;
int prox_gain;
-   int prox_config;
+   int als_prox_config;
int als_cal_target;
u8 als_persistence;
bool als_interrupt_en;
-- 
2.14.3

[PATCH 01/13] staging: iio: tsl2x7x: move integration_time* attributes to IIO_INTENSITY channel

[Brian Masney]

The integration_time* attributes are currently associated with the
IIO_LIGHT channel but should be associated with the IIO_INTENSITY
channel. Directory listing of the sysfs attributes for a TSL2772
with this patch applied:

dev
events
in_illuminance0_calibrate
in_illuminance0_calibscale_available
in_illuminance0_input
in_illuminance0_lux_table
in_illuminance0_target_input
in_intensity0_calibbias
in_intensity0_calibscale
in_intensity0_integration_time
in_intensity0_integration_time_available
in_intensity0_raw
in_intensity1_raw
in_proximity0_calibrate
in_proximity0_calibscale
in_proximity0_calibscale_available
in_proximity0_raw
name
of_node
power
subsystem
uevent

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 9991b0483956..eeccfbb0eb1f 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -827,7 +827,7 @@ in_illuminance0_calibscale_available_show(struct device 
*dev,
 
 static IIO_CONST_ATTR(in_proximity0_calibscale_available, "1 2 4 8");
 
-static IIO_CONST_ATTR(in_illuminance0_integration_time_available,
+static IIO_CONST_ATTR(in_intensity0_integration_time_available,
".00272 - .696");
 
 static ssize_t in_illuminance0_target_input_show(struct device *dev,
@@ -1358,7 +1358,7 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
 
 static struct attribute *tsl2x7x_ALS_device_attrs[] = {
_attr_in_illuminance0_calibscale_available.attr,
-   _const_attr_in_illuminance0_integration_time_available
+   _const_attr_in_intensity0_integration_time_available
.dev_attr.attr,
_attr_in_illuminance0_target_input.attr,
_attr_in_illuminance0_calibrate.attr,
@@ -1373,7 +1373,7 @@ static struct attribute *tsl2x7x_PRX_device_attrs[] = {
 
 static struct attribute *tsl2x7x_ALSPRX_device_attrs[] = {
_attr_in_illuminance0_calibscale_available.attr,
-   _const_attr_in_illuminance0_integration_time_available
+   _const_attr_in_intensity0_integration_time_available
.dev_attr.attr,
_attr_in_illuminance0_target_input.attr,
_attr_in_illuminance0_calibrate.attr,
@@ -1389,7 +1389,7 @@ static struct attribute *tsl2x7x_PRX2_device_attrs[] = {
 
 static struct attribute *tsl2x7x_ALSPRX2_device_attrs[] = {
_attr_in_illuminance0_calibscale_available.attr,
-   _const_attr_in_illuminance0_integration_time_available
+   _const_attr_in_intensity0_integration_time_available
.dev_attr.attr,
_attr_in_illuminance0_target_input.attr,
_attr_in_illuminance0_calibrate.attr,
@@ -1489,13 +1489,13 @@ static const struct tsl2x7x_chip_info 
tsl2x7x_chip_info_tbl[] = {
.type = IIO_LIGHT,
.indexed = 1,
.channel = 0,
-   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |
- BIT(IIO_CHAN_INFO_INT_TIME),
+   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
}, {
.type = IIO_INTENSITY,
.indexed = 1,
.channel = 0,
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+   BIT(IIO_CHAN_INFO_INT_TIME) |
BIT(IIO_CHAN_INFO_CALIBSCALE) |
BIT(IIO_CHAN_INFO_CALIBBIAS),
.event_spec = tsl2x7x_events,
@@ -1529,13 +1529,13 @@ static const struct tsl2x7x_chip_info 
tsl2x7x_chip_info_tbl[] = {
.type = IIO_LIGHT,
.indexed = 1,
.channel = 0,
-   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |
- BIT(IIO_CHAN_INFO_INT_TIME),
+   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
}, {
.type = IIO_INTENSITY,
.indexed = 1,
.channel = 0,
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+   BIT(IIO_CHAN_INFO_INT_TIME) |
BIT(IIO_CHAN_INFO_CALIBSCALE) |
BIT(IIO_CHAN_INFO_CALIBBIAS),
.event_spec = tsl2x7x_events,
@@ -1578,13 +1578,13 @@ static const struct tsl2x7x_chip_info 
tsl2x7x_chip_info_tbl[] = {
.type = IIO_LIGHT,
.indexed = 1,
.channel = 0,
-   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |
- BIT(IIO_CHAN_INFO_INT_TIME),
+   

[PATCH 06/13] staging: iio: tsl2x7x: simplify tsl2x7x_write_interrupt_config return

[Brian Masney]

tsl2x7x_write_interrupt_config() has an unnecessary return value check
at the end of the function. This patch changes the function to just
return the value from the call to tsl2x7x_invoke_change().

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 8d8af0cf9768..d202bc7e1f4f 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -982,18 +982,13 @@ static int tsl2x7x_write_interrupt_config(struct iio_dev 
*indio_dev,
  int val)
 {
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
-   int ret;
 
if (chan->type == IIO_INTENSITY)
chip->settings.als_interrupt_en = val ? true : false;
else
chip->settings.prox_interrupt_en = val ? true : false;
 
-   ret = tsl2x7x_invoke_change(indio_dev);
-   if (ret < 0)
-   return ret;
-
-   return 0;
+   return tsl2x7x_invoke_change(indio_dev);
 }
 
 static int tsl2x7x_write_event_value(struct iio_dev *indio_dev,
-- 
2.14.3

[PATCH 07/13] staging: iio: tsl2x7x: simplify device id verification

[Brian Masney]

This patch renames tsl2x7x_device_id() to tsl2x7x_device_id_verif(),
removes the unnecessary pointer on the id parameter, and only calls
the verification function once.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index d202bc7e1f4f..56730baea927 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -1277,22 +1277,22 @@ static DEVICE_ATTR_WO(in_proximity0_calibrate);
 static DEVICE_ATTR_RW(in_illuminance0_lux_table);
 
 /* Use the default register values to identify the Taos device */
-static int tsl2x7x_device_id(int *id, int target)
+static int tsl2x7x_device_id_verif(int id, int target)
 {
switch (target) {
case tsl2571:
case tsl2671:
case tsl2771:
-   return (*id & 0xf0) == TRITON_ID;
+   return (id & 0xf0) == TRITON_ID;
case tmd2671:
case tmd2771:
-   return (*id & 0xf0) == HALIBUT_ID;
+   return (id & 0xf0) == HALIBUT_ID;
case tsl2572:
case tsl2672:
case tmd2672:
case tsl2772:
case tmd2772:
-   return (*id & 0xf0) == SWORDFISH_ID;
+   return (id & 0xf0) == SWORDFISH_ID;
}
 
return -EINVAL;
@@ -1612,8 +1612,7 @@ static int tsl2x7x_probe(struct i2c_client *clientp,
if (ret < 0)
return ret;
 
-   if ((!tsl2x7x_device_id(, id->driver_data)) ||
-   (tsl2x7x_device_id(, id->driver_data) == -EINVAL)) {
+   if (tsl2x7x_device_id_verif(ret, id->driver_data) <= 0) {
dev_info(>client->dev,
 "%s: i2c device found does not match expected id\n",
__func__);
-- 
2.14.3

[PATCH 09/13] staging: iio: tsl2x7x: move power and diode settings into header file

[Brian Masney]

The power and diode defines are needed for the platform data so this
patch moves the defines out of the .c file and into the header file. A
comment for the diode is also cleaned up while this code is touched.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 12 
 drivers/staging/iio/light/tsl2x7x.h | 12 
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 15bc0af1bb6c..87b99deef7a8 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -103,18 +103,6 @@
 #define TSL2X7X_CNTL_PROXPON_ENBL  0x0F
 #define TSL2X7X_CNTL_INTPROXPON_ENBL   0x2F
 
-/*Prox diode to use */
-#define TSL2X7X_DIODE0 0x01
-#define TSL2X7X_DIODE1 0x02
-#define TSL2X7X_DIODE_BOTH 0x03
-
-/* LED Power */
-#define TSL2X7X_100_mA 0x00
-#define TSL2X7X_50_mA  0x01
-#define TSL2X7X_25_mA  0x02
-#define TSL2X7X_13_mA  0x03
-#define TSL2X7X_MAX_TIMER_CNT  0xFF
-
 #define TSL2X7X_MIN_ITIME  3
 
 /* TAOS txx2x7x Device family members */
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index 992ee2465609..2c96f0b39b1e 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -23,6 +23,18 @@ struct tsl2x7x_lux {
 #define TSL2X7X_DEFAULT_TABLE_BYTES (sizeof(struct tsl2x7x_lux) * \
 TSL2X7X_DEF_LUX_TABLE_SZ)
 
+/* Proximity diode to use */
+#define TSL2X7X_DIODE0  0x01
+#define TSL2X7X_DIODE1  0x02
+#define TSL2X7X_DIODE_BOTH  0x03
+
+/* LED Power */
+#define TSL2X7X_100_mA  0x00
+#define TSL2X7X_50_mA   0x01
+#define TSL2X7X_25_mA   0x02
+#define TSL2X7X_13_mA   0x03
+#define TSL2X7X_MAX_TIMER_CNT   0xFF
+
 /**
  * struct tsl2x7x_default_settings - power on defaults unless
  *   overridden by platform data.
-- 
2.14.3

[PATCH 13/13] staging: iio: tsl2x7x: rename prox_config to als_prox_config

[Brian Masney]

The configuration register on the device is represented with the
prox_config member on the tsl2x7x_settings structure. According to the
TSL2772 data sheet, this register can hold: 1) the proximity drive
level, 2) ALS/Proximity long wait, and 3) the ALS gain level. This
patch renames prox_config to als_prox_config since ALS settings can
be stored here as well.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 7 ---
 drivers/staging/iio/light/tsl2x7x.h | 5 +++--
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 05c0f3d5fac0..708b2c6bdf4b 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -56,7 +56,7 @@
 #define TSL2X7X_PRX_MAXTHRESHLO0X0A
 #define TSL2X7X_PRX_MAXTHRESHHI0X0B
 #define TSL2X7X_PERSISTENCE0x0C
-#define TSL2X7X_PRX_CONFIG 0x0D
+#define TSL2X7X_ALS_PRX_CONFIG 0x0D
 #define TSL2X7X_PRX_COUNT  0x0E
 #define TSL2X7X_GAIN   0x0F
 #define TSL2X7X_NOTUSED0x10
@@ -207,7 +207,7 @@ static const struct tsl2x7x_settings 
tsl2x7x_default_settings = {
.prox_time = 255, /* 2.73 ms */
.prox_gain = 0,
.wait_time = 255,
-   .prox_config = 0,
+   .als_prox_config = 0,
.als_gain_trim = 1000,
.als_cal_target = 150,
.als_persistence = 1,
@@ -594,7 +594,8 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
/* Non calculated parameters */
chip->tsl2x7x_config[TSL2X7X_PRX_TIME] = chip->settings.prox_time;
chip->tsl2x7x_config[TSL2X7X_WAIT_TIME] = chip->settings.wait_time;
-   chip->tsl2x7x_config[TSL2X7X_PRX_CONFIG] = chip->settings.prox_config;
+   chip->tsl2x7x_config[TSL2X7X_ALS_PRX_CONFIG] =
+   chip->settings.als_prox_config;
 
chip->tsl2x7x_config[TSL2X7X_ALS_MINTHRESHLO] =
(chip->settings.als_thresh_low) & 0xFF;
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index 85d8fe7a94c8..6e30e71a2127 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -48,7 +48,8 @@ struct tsl2x7x_lux {
  *  increments. Total integration time is
  *  (256 - prx_time) * 2.73.
  *  @prox_gain: Index into the tsl2x7x_prx_gain array.
- *  @prox_config:   Prox configuration filters.
+ *  @als_prox_config:   The value of the ALS / Proximity configuration
+ *  register.
  *  @als_cal_target:Known external ALS reading for calibration.
  *  @als_persistence:   H/W Filters, Number of 'out of limits' ALS 
readings.
  *  @als_interrupt_en:  Enable/Disable ALS interrupts
@@ -73,7 +74,7 @@ struct tsl2x7x_settings {
int wait_time;
int prox_time;
int prox_gain;
-   int prox_config;
+   int als_prox_config;
int als_cal_target;
u8 als_persistence;
bool als_interrupt_en;
-- 
2.14.3

[PATCH 01/13] staging: iio: tsl2x7x: move integration_time* attributes to IIO_INTENSITY channel

[Brian Masney]

The integration_time* attributes are currently associated with the
IIO_LIGHT channel but should be associated with the IIO_INTENSITY
channel. Directory listing of the sysfs attributes for a TSL2772
with this patch applied:

dev
events
in_illuminance0_calibrate
in_illuminance0_calibscale_available
in_illuminance0_input
in_illuminance0_lux_table
in_illuminance0_target_input
in_intensity0_calibbias
in_intensity0_calibscale
in_intensity0_integration_time
in_intensity0_integration_time_available
in_intensity0_raw
in_intensity1_raw
in_proximity0_calibrate
in_proximity0_calibscale
in_proximity0_calibscale_available
in_proximity0_raw
name
of_node
power
subsystem
uevent

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 9991b0483956..eeccfbb0eb1f 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -827,7 +827,7 @@ in_illuminance0_calibscale_available_show(struct device 
*dev,
 
 static IIO_CONST_ATTR(in_proximity0_calibscale_available, "1 2 4 8");
 
-static IIO_CONST_ATTR(in_illuminance0_integration_time_available,
+static IIO_CONST_ATTR(in_intensity0_integration_time_available,
".00272 - .696");
 
 static ssize_t in_illuminance0_target_input_show(struct device *dev,
@@ -1358,7 +1358,7 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
 
 static struct attribute *tsl2x7x_ALS_device_attrs[] = {
_attr_in_illuminance0_calibscale_available.attr,
-   _const_attr_in_illuminance0_integration_time_available
+   _const_attr_in_intensity0_integration_time_available
.dev_attr.attr,
_attr_in_illuminance0_target_input.attr,
_attr_in_illuminance0_calibrate.attr,
@@ -1373,7 +1373,7 @@ static struct attribute *tsl2x7x_PRX_device_attrs[] = {
 
 static struct attribute *tsl2x7x_ALSPRX_device_attrs[] = {
_attr_in_illuminance0_calibscale_available.attr,
-   _const_attr_in_illuminance0_integration_time_available
+   _const_attr_in_intensity0_integration_time_available
.dev_attr.attr,
_attr_in_illuminance0_target_input.attr,
_attr_in_illuminance0_calibrate.attr,
@@ -1389,7 +1389,7 @@ static struct attribute *tsl2x7x_PRX2_device_attrs[] = {
 
 static struct attribute *tsl2x7x_ALSPRX2_device_attrs[] = {
_attr_in_illuminance0_calibscale_available.attr,
-   _const_attr_in_illuminance0_integration_time_available
+   _const_attr_in_intensity0_integration_time_available
.dev_attr.attr,
_attr_in_illuminance0_target_input.attr,
_attr_in_illuminance0_calibrate.attr,
@@ -1489,13 +1489,13 @@ static const struct tsl2x7x_chip_info 
tsl2x7x_chip_info_tbl[] = {
.type = IIO_LIGHT,
.indexed = 1,
.channel = 0,
-   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |
- BIT(IIO_CHAN_INFO_INT_TIME),
+   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
}, {
.type = IIO_INTENSITY,
.indexed = 1,
.channel = 0,
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+   BIT(IIO_CHAN_INFO_INT_TIME) |
BIT(IIO_CHAN_INFO_CALIBSCALE) |
BIT(IIO_CHAN_INFO_CALIBBIAS),
.event_spec = tsl2x7x_events,
@@ -1529,13 +1529,13 @@ static const struct tsl2x7x_chip_info 
tsl2x7x_chip_info_tbl[] = {
.type = IIO_LIGHT,
.indexed = 1,
.channel = 0,
-   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |
- BIT(IIO_CHAN_INFO_INT_TIME),
+   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
}, {
.type = IIO_INTENSITY,
.indexed = 1,
.channel = 0,
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+   BIT(IIO_CHAN_INFO_INT_TIME) |
BIT(IIO_CHAN_INFO_CALIBSCALE) |
BIT(IIO_CHAN_INFO_CALIBBIAS),
.event_spec = tsl2x7x_events,
@@ -1578,13 +1578,13 @@ static const struct tsl2x7x_chip_info 
tsl2x7x_chip_info_tbl[] = {
.type = IIO_LIGHT,
.indexed = 1,
.channel = 0,
-   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED) |
- BIT(IIO_CHAN_INFO_INT_TIME),
+   .info_mask_separate = 

[PATCH 00/13] iio: tsl2x7x: staging cleanups

[Brian Masney]

Here is another round of staging cleanups for this driver mostly based
on Jonathon's feedback. We're very close to a staging graduation and I
only have a few items remaining on my todo list:
 
- Remove wildcards from the driver name. Jonathan suggested tsl2571.
- Don't make the events/ directory available to user space via sysfs if
  an interrupt pin is not configured.
- Go through the newer ALS part numbers on AMS's site and see if there
  are other part numbers that can be added to this driver.
- I found this week an issue with the integration_time sysfs attribute.

Hopefully I'll have time to wrap this up next week.

Brian Masney (13):
  staging: iio: tsl2x7x: move integration_time* attributes to
IIO_INTENSITY channel
  staging: iio: tsl2x7x: use GPL-2.0+ SPDX license identifier
  staging: iio: tsl2x7x: don't return error in IRQ handler
  staging: iio: tsl2x7x: simplify tsl2x7x_clear_interrupts function
  staging: iio: tsl2x7x: remove unnecessary chip status checks in
suspend/resume
  staging: iio: tsl2x7x: simplify tsl2x7x_write_interrupt_config return
  staging: iio: tsl2x7x: simplify device id verification
  staging: iio: tsl2x7x: add range checking to three sysfs attributes
  staging: iio: tsl2x7x: move power and diode settings into header file
  staging: iio: tsl2x7x: rename prx to prox for consistency
  staging: iio: tsl2x7x: use device defaults for als_time, prox_time and
wait_time
  staging: iio: tsl2x7x: various comment cleanups
  staging: iio: tsl2x7x: rename prox_config to als_prox_config

 drivers/staging/iio/light/tsl2x7x.c | 217 ++--
 drivers/staging/iio/light/tsl2x7x.h |  81 +++---
 2 files changed, 125 insertions(+), 173 deletions(-)

-- 
2.14.3

[PATCH 00/13] iio: tsl2x7x: staging cleanups

[Brian Masney]

Here is another round of staging cleanups for this driver mostly based
on Jonathon's feedback. We're very close to a staging graduation and I
only have a few items remaining on my todo list:
 
- Remove wildcards from the driver name. Jonathan suggested tsl2571.
- Don't make the events/ directory available to user space via sysfs if
  an interrupt pin is not configured.
- Go through the newer ALS part numbers on AMS's site and see if there
  are other part numbers that can be added to this driver.
- I found this week an issue with the integration_time sysfs attribute.

Hopefully I'll have time to wrap this up next week.

Brian Masney (13):
  staging: iio: tsl2x7x: move integration_time* attributes to
IIO_INTENSITY channel
  staging: iio: tsl2x7x: use GPL-2.0+ SPDX license identifier
  staging: iio: tsl2x7x: don't return error in IRQ handler
  staging: iio: tsl2x7x: simplify tsl2x7x_clear_interrupts function
  staging: iio: tsl2x7x: remove unnecessary chip status checks in
suspend/resume
  staging: iio: tsl2x7x: simplify tsl2x7x_write_interrupt_config return
  staging: iio: tsl2x7x: simplify device id verification
  staging: iio: tsl2x7x: add range checking to three sysfs attributes
  staging: iio: tsl2x7x: move power and diode settings into header file
  staging: iio: tsl2x7x: rename prx to prox for consistency
  staging: iio: tsl2x7x: use device defaults for als_time, prox_time and
wait_time
  staging: iio: tsl2x7x: various comment cleanups
  staging: iio: tsl2x7x: rename prox_config to als_prox_config

 drivers/staging/iio/light/tsl2x7x.c | 217 ++--
 drivers/staging/iio/light/tsl2x7x.h |  81 +++---
 2 files changed, 125 insertions(+), 173 deletions(-)

-- 
2.14.3

[PATCH 12/13] staging: iio: tsl2x7x: various comment cleanups

[Brian Masney]

This patch removes several unnecessary comments, changes some comments
so that the use as much of the allowable 80 characters as possible, adds
the proper whitespace, removes some structure members from the kernel
docs that are no longer present, and improves the existing kernel doc
information for some existing structure members.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 59 +
 drivers/staging/iio/light/tsl2x7x.h | 48 +++---
 2 files changed, 51 insertions(+), 56 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 293810ff11b9..05c0f3d5fac0 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -1,6 +1,6 @@
 /*
- * Device driver for monitoring ambient light intensity in (lux)
- * and proximity detection (prox) within the TAOS TSL2X7X family of devices.
+ * Device driver for monitoring ambient light intensity in (lux) and proximity
+ * detection (prox) within the TAOS TSL2X7X family of devices.
  *
  * Copyright (c) 2012, TAOS Corporation.
  * Copyright (c) 2017-2018 Brian Masney 
@@ -21,7 +21,7 @@
 #include 
 #include "tsl2x7x.h"
 
-/* Cal defs*/
+/* Cal defs */
 #define PROX_STAT_CAL  0
 #define PROX_STAT_SAMP 1
 #define MAX_SAMPLES_CAL200
@@ -34,10 +34,11 @@
 /* Lux calculation constants */
 #define TSL2X7X_LUX_CALC_OVER_FLOW 65535
 
-/* TAOS Register definitions - note:
- * depending on device, some of these register are not used and the
- * register address is benign.
+/*
+ * TAOS Register definitions - Note: depending on device, some of these 
register
+ * are not used and the register address is benign.
  */
+
 /* 2X7X register offsets */
 #define TSL2X7X_MAX_CONFIG_REG 16
 
@@ -342,15 +343,14 @@ static int tsl2x7x_read_autoinc_regs(struct tsl2X7X_chip 
*chip, int lower_reg,
  * @indio_dev: pointer to IIO device
  *
  * The raw ch0 and ch1 values of the ambient light sensed in the last
- * integration cycle are read from the device.
- * Time scale factor array values are adjusted based on the integration time.
- * The raw values are multiplied by a scale factor, and device gain is obtained
- * using gain index. Limit checks are done next, then the ratio of a multiple
- * of ch1 value, to the ch0 value, is calculated. Array tsl2x7x_device_lux[]
- * is then scanned to find the first ratio value that is just above the ratio
- * we just calculated. The ch0 and ch1 multiplier constants in the array are
- * then used along with the time scale factor array values, to calculate the
- * lux.
+ * integration cycle are read from the device. Time scale factor array values
+ * are adjusted based on the integration time. The raw values are multiplied
+ * by a scale factor, and device gain is obtained using gain index. Limit
+ * checks are done next, then the ratio of a multiple of ch1 value, to the
+ * ch0 value, is calculated. Array tsl2x7x_device_lux[] is then scanned to
+ * find the first ratio value that is just above the ratio we just calculated.
+ * The ch0 and ch1 multiplier constants in the array are then used along with
+ * the time scale factor array values, to calculate the lux.
  */
 static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
 {
@@ -363,7 +363,6 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
mutex_lock(>als_mutex);
 
if (chip->tsl2x7x_chip_status != TSL2X7X_CHIP_WORKING) {
-   /* device is not enabled */
dev_err(>client->dev, "%s: device is not enabled\n",
__func__);
ret = -EBUSY;
@@ -374,7 +373,6 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
if (ret < 0)
goto out_unlock;
 
-   /* is data new & valid */
if (!(ret & TSL2X7X_STA_ADC_VALID)) {
dev_err(>client->dev,
"%s: data not valid yet\n", __func__);
@@ -430,12 +428,12 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
lux = (lux + (chip->als_time_scale >> 1)) /
chip->als_time_scale;
 
-   /* adjust for active gain scale
-* The tsl2x7x_device_lux tables have a factor of 256 built-in.
-* User-specified gain provides a multiplier.
+   /*
+* adjust for active gain scale. The tsl2x7x_device_lux tables have a
+* factor of 256 built-in. User-specified gain provides a multiplier.
 * Apply user-specified gain before shifting right to retain precision.
-* Use 64 bits to avoid overflow on multiplication.
-* Then go back to 32 bits before division to avoid using div_u64().
+* Use 64 bits to avoid overflow on multiplication. Then go back to
+* 32 bits before division to avoid using div_u64().
 */
 
lux64 = lux;
@@ -713,14 +711,13 @@ static 

[PATCH 12/13] staging: iio: tsl2x7x: various comment cleanups

[Brian Masney]

This patch removes several unnecessary comments, changes some comments
so that the use as much of the allowable 80 characters as possible, adds
the proper whitespace, removes some structure members from the kernel
docs that are no longer present, and improves the existing kernel doc
information for some existing structure members.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 59 +
 drivers/staging/iio/light/tsl2x7x.h | 48 +++---
 2 files changed, 51 insertions(+), 56 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 293810ff11b9..05c0f3d5fac0 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -1,6 +1,6 @@
 /*
- * Device driver for monitoring ambient light intensity in (lux)
- * and proximity detection (prox) within the TAOS TSL2X7X family of devices.
+ * Device driver for monitoring ambient light intensity in (lux) and proximity
+ * detection (prox) within the TAOS TSL2X7X family of devices.
  *
  * Copyright (c) 2012, TAOS Corporation.
  * Copyright (c) 2017-2018 Brian Masney 
@@ -21,7 +21,7 @@
 #include 
 #include "tsl2x7x.h"
 
-/* Cal defs*/
+/* Cal defs */
 #define PROX_STAT_CAL  0
 #define PROX_STAT_SAMP 1
 #define MAX_SAMPLES_CAL200
@@ -34,10 +34,11 @@
 /* Lux calculation constants */
 #define TSL2X7X_LUX_CALC_OVER_FLOW 65535
 
-/* TAOS Register definitions - note:
- * depending on device, some of these register are not used and the
- * register address is benign.
+/*
+ * TAOS Register definitions - Note: depending on device, some of these 
register
+ * are not used and the register address is benign.
  */
+
 /* 2X7X register offsets */
 #define TSL2X7X_MAX_CONFIG_REG 16
 
@@ -342,15 +343,14 @@ static int tsl2x7x_read_autoinc_regs(struct tsl2X7X_chip 
*chip, int lower_reg,
  * @indio_dev: pointer to IIO device
  *
  * The raw ch0 and ch1 values of the ambient light sensed in the last
- * integration cycle are read from the device.
- * Time scale factor array values are adjusted based on the integration time.
- * The raw values are multiplied by a scale factor, and device gain is obtained
- * using gain index. Limit checks are done next, then the ratio of a multiple
- * of ch1 value, to the ch0 value, is calculated. Array tsl2x7x_device_lux[]
- * is then scanned to find the first ratio value that is just above the ratio
- * we just calculated. The ch0 and ch1 multiplier constants in the array are
- * then used along with the time scale factor array values, to calculate the
- * lux.
+ * integration cycle are read from the device. Time scale factor array values
+ * are adjusted based on the integration time. The raw values are multiplied
+ * by a scale factor, and device gain is obtained using gain index. Limit
+ * checks are done next, then the ratio of a multiple of ch1 value, to the
+ * ch0 value, is calculated. Array tsl2x7x_device_lux[] is then scanned to
+ * find the first ratio value that is just above the ratio we just calculated.
+ * The ch0 and ch1 multiplier constants in the array are then used along with
+ * the time scale factor array values, to calculate the lux.
  */
 static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
 {
@@ -363,7 +363,6 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
mutex_lock(>als_mutex);
 
if (chip->tsl2x7x_chip_status != TSL2X7X_CHIP_WORKING) {
-   /* device is not enabled */
dev_err(>client->dev, "%s: device is not enabled\n",
__func__);
ret = -EBUSY;
@@ -374,7 +373,6 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
if (ret < 0)
goto out_unlock;
 
-   /* is data new & valid */
if (!(ret & TSL2X7X_STA_ADC_VALID)) {
dev_err(>client->dev,
"%s: data not valid yet\n", __func__);
@@ -430,12 +428,12 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
lux = (lux + (chip->als_time_scale >> 1)) /
chip->als_time_scale;
 
-   /* adjust for active gain scale
-* The tsl2x7x_device_lux tables have a factor of 256 built-in.
-* User-specified gain provides a multiplier.
+   /*
+* adjust for active gain scale. The tsl2x7x_device_lux tables have a
+* factor of 256 built-in. User-specified gain provides a multiplier.
 * Apply user-specified gain before shifting right to retain precision.
-* Use 64 bits to avoid overflow on multiplication.
-* Then go back to 32 bits before division to avoid using div_u64().
+* Use 64 bits to avoid overflow on multiplication. Then go back to
+* 32 bits before division to avoid using div_u64().
 */
 
lux64 = lux;
@@ -713,14 +711,13 @@ static int tsl2x7x_chip_off(struct iio_dev *indio_dev)

[PATCH 10/13] staging: iio: tsl2x7x: rename prx to prox for consistency

[Brian Masney]

The driver mostly uses the 'prox' naming convention for most of the
proximity settings, however prx_time and tsl2x7x_prx_gain was present.
This patch renames these to prox_time and tsl2x7x_prox_gain for
consistency with everything else in the driver.

The kernel documentation for prx_gain is corrected to prox_gain so that
it matches what is actually in the structure.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 12 ++--
 drivers/staging/iio/light/tsl2x7x.h |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 87b99deef7a8..a7b4fcba7935 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -203,7 +203,7 @@ static const struct tsl2x7x_lux 
*tsl2x7x_default_lux_table_group[] = {
 static const struct tsl2x7x_settings tsl2x7x_default_settings = {
.als_time = 219, /* 101 ms */
.als_gain = 0,
-   .prx_time = 254, /* 5.4 ms */
+   .prox_time = 254, /* 5.4 ms */
.prox_gain = 0,
.wait_time = 245,
.prox_config = 0,
@@ -230,7 +230,7 @@ static const s16 tsl2x7x_als_gain[] = {
120
 };
 
-static const s16 tsl2x7x_prx_gain[] = {
+static const s16 tsl2x7x_prox_gain[] = {
1,
2,
4,
@@ -594,7 +594,7 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
u8 *dev_reg, reg_val;
 
/* Non calculated parameters */
-   chip->tsl2x7x_config[TSL2X7X_PRX_TIME] = chip->settings.prx_time;
+   chip->tsl2x7x_config[TSL2X7X_PRX_TIME] = chip->settings.prox_time;
chip->tsl2x7x_config[TSL2X7X_WAIT_TIME] = chip->settings.wait_time;
chip->tsl2x7x_config[TSL2X7X_PRX_CONFIG] = chip->settings.prox_config;
 
@@ -1021,7 +1021,7 @@ static int tsl2x7x_write_event_value(struct iio_dev 
*indio_dev,
if (chan->type == IIO_INTENSITY)
time = chip->settings.als_time;
else
-   time = chip->settings.prx_time;
+   time = chip->settings.prox_time;
 
y = (TSL2X7X_MAX_TIMER_CNT - time) + 1;
z = y * TSL2X7X_MIN_ITIME;
@@ -1090,7 +1090,7 @@ static int tsl2x7x_read_event_value(struct iio_dev 
*indio_dev,
time = chip->settings.als_time;
mult = chip->settings.als_persistence;
} else {
-   time = chip->settings.prx_time;
+   time = chip->settings.prox_time;
mult = chip->settings.prox_persistence;
}
 
@@ -1153,7 +1153,7 @@ static int tsl2x7x_read_raw(struct iio_dev *indio_dev,
if (chan->type == IIO_LIGHT)
*val = tsl2x7x_als_gain[chip->settings.als_gain];
else
-   *val = tsl2x7x_prx_gain[chip->settings.prox_gain];
+   *val = tsl2x7x_prox_gain[chip->settings.prox_gain];
ret = IIO_VAL_INT;
break;
case IIO_CHAN_INFO_CALIBBIAS:
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index 2c96f0b39b1e..408e5a89edb1 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -44,9 +44,9 @@ struct tsl2x7x_lux {
  *  aperture effects.
  *  @wait_time: Time between PRX and ALS cycles
  *  in 2.7 periods
- *  @prx_time:  5.2ms prox integration time -
+ *  @prox_time: 5.2ms prox integration time -
  *  decrease in 2.7ms periods
- *  @prx_gain:  Proximity gain index
+ *  @prox_gain: Proximity gain index
  *  @prox_config:   Prox configuration filters.
  *  @als_cal_target:Known external ALS reading for
  *  calibration.
@@ -68,7 +68,7 @@ struct tsl2x7x_settings {
int als_gain;
int als_gain_trim;
int wait_time;
-   int prx_time;
+   int prox_time;
int prox_gain;
int prox_config;
int als_cal_target;
-- 
2.14.3

[PATCH 11/13] staging: iio: tsl2x7x: use device defaults for als_time, prox_time and wait_time

[Brian Masney]

This patch changes the defaults of the als_time, prox_time and
wait_time to match the defaults according to the TSL2772 datasheet.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index a7b4fcba7935..293810ff11b9 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -201,11 +201,11 @@ static const struct tsl2x7x_lux 
*tsl2x7x_default_lux_table_group[] = {
 };
 
 static const struct tsl2x7x_settings tsl2x7x_default_settings = {
-   .als_time = 219, /* 101 ms */
+   .als_time = 255, /* 2.73 ms */
.als_gain = 0,
-   .prox_time = 254, /* 5.4 ms */
+   .prox_time = 255, /* 2.73 ms */
.prox_gain = 0,
-   .wait_time = 245,
+   .wait_time = 255,
.prox_config = 0,
.als_gain_trim = 1000,
.als_cal_target = 150,
-- 
2.14.3

[PATCH 11/13] staging: iio: tsl2x7x: use device defaults for als_time, prox_time and wait_time

[Brian Masney]

This patch changes the defaults of the als_time, prox_time and
wait_time to match the defaults according to the TSL2772 datasheet.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index a7b4fcba7935..293810ff11b9 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -201,11 +201,11 @@ static const struct tsl2x7x_lux 
*tsl2x7x_default_lux_table_group[] = {
 };
 
 static const struct tsl2x7x_settings tsl2x7x_default_settings = {
-   .als_time = 219, /* 101 ms */
+   .als_time = 255, /* 2.73 ms */
.als_gain = 0,
-   .prox_time = 254, /* 5.4 ms */
+   .prox_time = 255, /* 2.73 ms */
.prox_gain = 0,
-   .wait_time = 245,
+   .wait_time = 255,
.prox_config = 0,
.als_gain_trim = 1000,
.als_cal_target = 150,
-- 
2.14.3

[PATCH 10/13] staging: iio: tsl2x7x: rename prx to prox for consistency

[Brian Masney]

The driver mostly uses the 'prox' naming convention for most of the
proximity settings, however prx_time and tsl2x7x_prx_gain was present.
This patch renames these to prox_time and tsl2x7x_prox_gain for
consistency with everything else in the driver.

The kernel documentation for prx_gain is corrected to prox_gain so that
it matches what is actually in the structure.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 12 ++--
 drivers/staging/iio/light/tsl2x7x.h |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 87b99deef7a8..a7b4fcba7935 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -203,7 +203,7 @@ static const struct tsl2x7x_lux 
*tsl2x7x_default_lux_table_group[] = {
 static const struct tsl2x7x_settings tsl2x7x_default_settings = {
.als_time = 219, /* 101 ms */
.als_gain = 0,
-   .prx_time = 254, /* 5.4 ms */
+   .prox_time = 254, /* 5.4 ms */
.prox_gain = 0,
.wait_time = 245,
.prox_config = 0,
@@ -230,7 +230,7 @@ static const s16 tsl2x7x_als_gain[] = {
120
 };
 
-static const s16 tsl2x7x_prx_gain[] = {
+static const s16 tsl2x7x_prox_gain[] = {
1,
2,
4,
@@ -594,7 +594,7 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
u8 *dev_reg, reg_val;
 
/* Non calculated parameters */
-   chip->tsl2x7x_config[TSL2X7X_PRX_TIME] = chip->settings.prx_time;
+   chip->tsl2x7x_config[TSL2X7X_PRX_TIME] = chip->settings.prox_time;
chip->tsl2x7x_config[TSL2X7X_WAIT_TIME] = chip->settings.wait_time;
chip->tsl2x7x_config[TSL2X7X_PRX_CONFIG] = chip->settings.prox_config;
 
@@ -1021,7 +1021,7 @@ static int tsl2x7x_write_event_value(struct iio_dev 
*indio_dev,
if (chan->type == IIO_INTENSITY)
time = chip->settings.als_time;
else
-   time = chip->settings.prx_time;
+   time = chip->settings.prox_time;
 
y = (TSL2X7X_MAX_TIMER_CNT - time) + 1;
z = y * TSL2X7X_MIN_ITIME;
@@ -1090,7 +1090,7 @@ static int tsl2x7x_read_event_value(struct iio_dev 
*indio_dev,
time = chip->settings.als_time;
mult = chip->settings.als_persistence;
} else {
-   time = chip->settings.prx_time;
+   time = chip->settings.prox_time;
mult = chip->settings.prox_persistence;
}
 
@@ -1153,7 +1153,7 @@ static int tsl2x7x_read_raw(struct iio_dev *indio_dev,
if (chan->type == IIO_LIGHT)
*val = tsl2x7x_als_gain[chip->settings.als_gain];
else
-   *val = tsl2x7x_prx_gain[chip->settings.prox_gain];
+   *val = tsl2x7x_prox_gain[chip->settings.prox_gain];
ret = IIO_VAL_INT;
break;
case IIO_CHAN_INFO_CALIBBIAS:
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index 2c96f0b39b1e..408e5a89edb1 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -44,9 +44,9 @@ struct tsl2x7x_lux {
  *  aperture effects.
  *  @wait_time: Time between PRX and ALS cycles
  *  in 2.7 periods
- *  @prx_time:  5.2ms prox integration time -
+ *  @prox_time: 5.2ms prox integration time -
  *  decrease in 2.7ms periods
- *  @prx_gain:  Proximity gain index
+ *  @prox_gain: Proximity gain index
  *  @prox_config:   Prox configuration filters.
  *  @als_cal_target:Known external ALS reading for
  *  calibration.
@@ -68,7 +68,7 @@ struct tsl2x7x_settings {
int als_gain;
int als_gain_trim;
int wait_time;
-   int prx_time;
+   int prox_time;
int prox_gain;
int prox_config;
int als_cal_target;
-- 
2.14.3

Re: [PATCH v2] KVM: Extend MAX_IRQ_ROUTES to 4096 for all archs

[Wanpeng Li]

2018-04-20 22:21 GMT+08:00 Cornelia Huck :
> On Fri, 20 Apr 2018 21:51:13 +0800
> Wanpeng Li  wrote:
>
>> 2018-04-20 15:15 GMT+08:00 Cornelia Huck :
>> > On Thu, 19 Apr 2018 17:47:28 -0700
>> > Wanpeng Li  wrote:
>> >
>> >> From: Wanpeng Li 
>> >>
>> >> Our virtual machines make use of device assignment by configuring
>> >> 12 NVMe disks for high I/O performance. Each NVMe device has 129
>> >> MSI-X Table entries:
>> >> Capabilities: [50] MSI-X: Enable+ Count=129 Masked-Vector table: BAR=0 
>> >> offset=2000
>> >> The windows virtual machines fail to boot since they will map the number 
>> >> of
>> >> MSI-table entries that the NVMe hardware reported to the bus to msi 
>> >> routing
>> >> table, this will exceed the 1024. This patch extends MAX_IRQ_ROUTES to 
>> >> 4096
>> >> for all archs, in the future this might be extended again if needed.
>> >>
>> >> Cc: Paolo Bonzini 
>> >> Cc: Radim Krčmář 
>> >> Cc: Tonny Lu 
>> >> Cc: Cornelia Huck 
>> >> Signed-off-by: Wanpeng Li 
>> >> Signed-off-by: Tonny Lu 
>> >> ---
>> >> v1 -> v2:
>> >>  * extend MAX_IRQ_ROUTES to 4096 for all archs
>> >>
>> >>  include/linux/kvm_host.h | 6 --
>> >>  1 file changed, 6 deletions(-)
>> >>
>> >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> >> index 6930c63..0a5c299 100644
>> >> --- a/include/linux/kvm_host.h
>> >> +++ b/include/linux/kvm_host.h
>> >> @@ -1045,13 +1045,7 @@ static inline int mmu_notifier_retry(struct kvm 
>> >> *kvm, unsigned long mmu_seq)
>> >>
>> >>  #ifdef CONFIG_HAVE_KVM_IRQ_ROUTING
>> >>
>> >> -#ifdef CONFIG_S390
>> >>  #define KVM_MAX_IRQ_ROUTES 4096 //FIXME: we can have more than that...
>> >
>> > What about /* might need extension/rework in the future */ instead of
>> > the FIXME?
>>
>> Yeah, I guess the maintainers can help to fix it when applying. :)
>>
>> >
>> > As far as I understand, 4096 should cover most architectures and the
>> > sane end of s390 configurations, but will not be enough at the scarier
>> > end of s390. (I'm not sure how much it matters in practice.)
>> >
>> > Do we want to make this a tuneable in the future? Do some kind of
>> > dynamic allocation? Not sure whether it is worth the trouble.
>>
>> I think keep as it is currently.
>
> My main question here is how long this is enough... the number of
> virtqueues per device is up to 1K from the initial 64, which makes it
> possible to hit the 4K limit with fewer virtio devices than before (on
> s390, each virtqueue uses a routing table entry). OTOH, we don't want
> giant tables everywhere just to accommodate s390.

I suspect there is no real scenario to futher extend for s390 since no
guys report.

> If the s390 maintainers tell me that nobody is doing the really insane
> stuff, I'm happy as well :)

Christian, any thoughts?

Regards,
Wanpeng Li

Re: [PATCH v2] KVM: Extend MAX_IRQ_ROUTES to 4096 for all archs

[Wanpeng Li]

2018-04-20 22:21 GMT+08:00 Cornelia Huck :
> On Fri, 20 Apr 2018 21:51:13 +0800
> Wanpeng Li  wrote:
>
>> 2018-04-20 15:15 GMT+08:00 Cornelia Huck :
>> > On Thu, 19 Apr 2018 17:47:28 -0700
>> > Wanpeng Li  wrote:
>> >
>> >> From: Wanpeng Li 
>> >>
>> >> Our virtual machines make use of device assignment by configuring
>> >> 12 NVMe disks for high I/O performance. Each NVMe device has 129
>> >> MSI-X Table entries:
>> >> Capabilities: [50] MSI-X: Enable+ Count=129 Masked-Vector table: BAR=0 
>> >> offset=2000
>> >> The windows virtual machines fail to boot since they will map the number 
>> >> of
>> >> MSI-table entries that the NVMe hardware reported to the bus to msi 
>> >> routing
>> >> table, this will exceed the 1024. This patch extends MAX_IRQ_ROUTES to 
>> >> 4096
>> >> for all archs, in the future this might be extended again if needed.
>> >>
>> >> Cc: Paolo Bonzini 
>> >> Cc: Radim Krčmář 
>> >> Cc: Tonny Lu 
>> >> Cc: Cornelia Huck 
>> >> Signed-off-by: Wanpeng Li 
>> >> Signed-off-by: Tonny Lu 
>> >> ---
>> >> v1 -> v2:
>> >>  * extend MAX_IRQ_ROUTES to 4096 for all archs
>> >>
>> >>  include/linux/kvm_host.h | 6 --
>> >>  1 file changed, 6 deletions(-)
>> >>
>> >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> >> index 6930c63..0a5c299 100644
>> >> --- a/include/linux/kvm_host.h
>> >> +++ b/include/linux/kvm_host.h
>> >> @@ -1045,13 +1045,7 @@ static inline int mmu_notifier_retry(struct kvm 
>> >> *kvm, unsigned long mmu_seq)
>> >>
>> >>  #ifdef CONFIG_HAVE_KVM_IRQ_ROUTING
>> >>
>> >> -#ifdef CONFIG_S390
>> >>  #define KVM_MAX_IRQ_ROUTES 4096 //FIXME: we can have more than that...
>> >
>> > What about /* might need extension/rework in the future */ instead of
>> > the FIXME?
>>
>> Yeah, I guess the maintainers can help to fix it when applying. :)
>>
>> >
>> > As far as I understand, 4096 should cover most architectures and the
>> > sane end of s390 configurations, but will not be enough at the scarier
>> > end of s390. (I'm not sure how much it matters in practice.)
>> >
>> > Do we want to make this a tuneable in the future? Do some kind of
>> > dynamic allocation? Not sure whether it is worth the trouble.
>>
>> I think keep as it is currently.
>
> My main question here is how long this is enough... the number of
> virtqueues per device is up to 1K from the initial 64, which makes it
> possible to hit the 4K limit with fewer virtio devices than before (on
> s390, each virtqueue uses a routing table entry). OTOH, we don't want
> giant tables everywhere just to accommodate s390.

I suspect there is no real scenario to futher extend for s390 since no
guys report.

> If the s390 maintainers tell me that nobody is doing the really insane
> stuff, I'm happy as well :)

Christian, any thoughts?

Regards,
Wanpeng Li

Re: [PATCH] KVM: s390: reset crypto attributes for all vcpus

[kbuild test robot]

Hi Tony,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on s390/features]
[also build test ERROR on v4.17-rc1 next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Tony-Krowiak/KVM-s390-reset-crypto-attributes-for-all-vcpus/20180421-050734
base:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
config: s390-allyesconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All error/warnings (new ones prefixed by >>):

   arch/s390/kvm/kvm-s390.c: In function 'kvm_s390_vcpu_crypto_reset_all':
>> arch/s390/kvm/kvm-s390.c:800:10: error: implicit declaration of function 
>> 'kvm_s390_vcpu_crypto_setup'; did you mean 'kvm_s390_vcpu_crypto_reset_all'? 
>> [-Werror=implicit-function-declaration]
 kvm_s390_vcpu_crypto_setup(vcpu);
 ^~
 kvm_s390_vcpu_crypto_reset_all
   arch/s390/kvm/kvm-s390.c: At top level:
>> arch/s390/kvm/kvm-s390.c:805:13: warning: conflicting types for 
>> 'kvm_s390_vcpu_crypto_setup'
static void kvm_s390_vcpu_crypto_setup(struct kvm_vcpu *vcpu);
^~
>> arch/s390/kvm/kvm-s390.c:805:13: error: static declaration of 
>> 'kvm_s390_vcpu_crypto_setup' follows non-static declaration
   arch/s390/kvm/kvm-s390.c:800:10: note: previous implicit declaration of 
'kvm_s390_vcpu_crypto_setup' was here
 kvm_s390_vcpu_crypto_setup(vcpu);
 ^~
   arch/s390/kvm/kvm-s390.c: In function 'kvm_s390_vm_set_crypto':
   arch/s390/kvm/kvm-s390.c:810:6: warning: unused variable 'i' 
[-Wunused-variable]
 int i;
 ^
   arch/s390/kvm/kvm-s390.c:809:19: warning: unused variable 'vcpu' 
[-Wunused-variable]
 struct kvm_vcpu *vcpu;
  ^~~~
   cc1: some warnings being treated as errors

vim +800 arch/s390/kvm/kvm-s390.c

   791  
   792  void kvm_s390_vcpu_crypto_reset_all(struct kvm *kvm)
   793   {
   794  int i;
   795  struct kvm_vcpu *vcpu;
   796  
   797  kvm_s390_vcpu_block_all(kvm);
   798  
   799  kvm_for_each_vcpu(i, vcpu, kvm)
 > 800  kvm_s390_vcpu_crypto_setup(vcpu);
   801  
   802  kvm_s390_vcpu_unblock_all(kvm);
   803  }
   804  
 > 805  static void kvm_s390_vcpu_crypto_setup(struct kvm_vcpu *vcpu);
   806  

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


.config.gz
Description: application/gzip

Re: [PATCH] KVM: s390: reset crypto attributes for all vcpus

[kbuild test robot]

Hi Tony,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on s390/features]
[also build test ERROR on v4.17-rc1 next-20180420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Tony-Krowiak/KVM-s390-reset-crypto-attributes-for-all-vcpus/20180421-050734
base:   https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
config: s390-allyesconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All error/warnings (new ones prefixed by >>):

   arch/s390/kvm/kvm-s390.c: In function 'kvm_s390_vcpu_crypto_reset_all':
>> arch/s390/kvm/kvm-s390.c:800:10: error: implicit declaration of function 
>> 'kvm_s390_vcpu_crypto_setup'; did you mean 'kvm_s390_vcpu_crypto_reset_all'? 
>> [-Werror=implicit-function-declaration]
 kvm_s390_vcpu_crypto_setup(vcpu);
 ^~
 kvm_s390_vcpu_crypto_reset_all
   arch/s390/kvm/kvm-s390.c: At top level:
>> arch/s390/kvm/kvm-s390.c:805:13: warning: conflicting types for 
>> 'kvm_s390_vcpu_crypto_setup'
static void kvm_s390_vcpu_crypto_setup(struct kvm_vcpu *vcpu);
^~
>> arch/s390/kvm/kvm-s390.c:805:13: error: static declaration of 
>> 'kvm_s390_vcpu_crypto_setup' follows non-static declaration
   arch/s390/kvm/kvm-s390.c:800:10: note: previous implicit declaration of 
'kvm_s390_vcpu_crypto_setup' was here
 kvm_s390_vcpu_crypto_setup(vcpu);
 ^~
   arch/s390/kvm/kvm-s390.c: In function 'kvm_s390_vm_set_crypto':
   arch/s390/kvm/kvm-s390.c:810:6: warning: unused variable 'i' 
[-Wunused-variable]
 int i;
 ^
   arch/s390/kvm/kvm-s390.c:809:19: warning: unused variable 'vcpu' 
[-Wunused-variable]
 struct kvm_vcpu *vcpu;
  ^~~~
   cc1: some warnings being treated as errors

vim +800 arch/s390/kvm/kvm-s390.c

   791  
   792  void kvm_s390_vcpu_crypto_reset_all(struct kvm *kvm)
   793   {
   794  int i;
   795  struct kvm_vcpu *vcpu;
   796  
   797  kvm_s390_vcpu_block_all(kvm);
   798  
   799  kvm_for_each_vcpu(i, vcpu, kvm)
 > 800  kvm_s390_vcpu_crypto_setup(vcpu);
   801  
   802  kvm_s390_vcpu_unblock_all(kvm);
   803  }
   804  
 > 805  static void kvm_s390_vcpu_crypto_setup(struct kvm_vcpu *vcpu);
   806  

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


.config.gz
Description: application/gzip

Re: [PATCH 1/3] fs: move documentation for thaw_super() where appropriate

[Randy Dunlap]

On 04/20/18 17:07, Luis R. Rodriguez wrote:
> On Sat, Apr 21, 2018 at 12:01:31AM +, Bart Van Assche wrote:
>> On Fri, 2018-04-20 at 16:59 -0700, Luis R. Rodriguez wrote:
>>> +/**
>>> + * thaw_super -- unlock filesystem
>>> + * @sb: the super to thaw
>>> + *
>>> + * Unlocks the filesystem and marks it writeable again after 
>>> freeze_super().
>>> + */
>>
>> Have you verified the output generated by scripts/kernel-doc? Last
>> time I checked the output for headers containing a double dash looked
>> weird.
> 
> No, I just moved the block of kdoc crap. Randy would have this memorized I'm
> sure though so I should just fix the kdoc if its bad while at it.
> 
>   Luis
> 

"--" does sound odd.  I've never seen it used on purpose.
FWIW, I just go by what is in Documentation/doc-guide/kernel-doc.rst:

Function documentation
--

The general format of a function and function-like macro kernel-doc comment is::

  /**
   * function_name() - Brief description of function.
   * @arg1: Describe the first argument.
   * @arg2: Describe the second argument.
   *One can provide multiple line descriptions
   *for arguments.



-- 
~Randy

Re: [PATCH 1/3] fs: move documentation for thaw_super() where appropriate

[Randy Dunlap]

On 04/20/18 17:07, Luis R. Rodriguez wrote:
> On Sat, Apr 21, 2018 at 12:01:31AM +, Bart Van Assche wrote:
>> On Fri, 2018-04-20 at 16:59 -0700, Luis R. Rodriguez wrote:
>>> +/**
>>> + * thaw_super -- unlock filesystem
>>> + * @sb: the super to thaw
>>> + *
>>> + * Unlocks the filesystem and marks it writeable again after 
>>> freeze_super().
>>> + */
>>
>> Have you verified the output generated by scripts/kernel-doc? Last
>> time I checked the output for headers containing a double dash looked
>> weird.
> 
> No, I just moved the block of kdoc crap. Randy would have this memorized I'm
> sure though so I should just fix the kdoc if its bad while at it.
> 
>   Luis
> 

"--" does sound odd.  I've never seen it used on purpose.
FWIW, I just go by what is in Documentation/doc-guide/kernel-doc.rst:

Function documentation
--

The general format of a function and function-like macro kernel-doc comment is::

  /**
   * function_name() - Brief description of function.
   * @arg1: Describe the first argument.
   * @arg2: Describe the second argument.
   *One can provide multiple line descriptions
   *for arguments.



-- 
~Randy

Re: [PATCH 1/3] fs: move documentation for thaw_super() where appropriate

[Luis R. Rodriguez]

On Sat, Apr 21, 2018 at 12:01:31AM +, Bart Van Assche wrote:
> On Fri, 2018-04-20 at 16:59 -0700, Luis R. Rodriguez wrote:
> > +/**
> > + * thaw_super -- unlock filesystem
> > + * @sb: the super to thaw
> > + *
> > + * Unlocks the filesystem and marks it writeable again after 
> > freeze_super().
> > + */
> 
> Have you verified the output generated by scripts/kernel-doc? Last
> time I checked the output for headers containing a double dash looked
> weird.

No, I just moved the block of kdoc crap. Randy would have this memorized I'm
sure though so I should just fix the kdoc if its bad while at it.

  Luis

Re: [PATCH 1/3] fs: move documentation for thaw_super() where appropriate

[Luis R. Rodriguez]

On Sat, Apr 21, 2018 at 12:01:31AM +, Bart Van Assche wrote:
> On Fri, 2018-04-20 at 16:59 -0700, Luis R. Rodriguez wrote:
> > +/**
> > + * thaw_super -- unlock filesystem
> > + * @sb: the super to thaw
> > + *
> > + * Unlocks the filesystem and marks it writeable again after 
> > freeze_super().
> > + */
> 
> Have you verified the output generated by scripts/kernel-doc? Last
> time I checked the output for headers containing a double dash looked
> weird.

No, I just moved the block of kdoc crap. Randy would have this memorized I'm
sure though so I should just fix the kdoc if its bad while at it.

  Luis

Re: [PATCH 0/3] fs: minor fs thaw fixes and adjustments

[Luis R. Rodriguez]

On Fri, Apr 20, 2018 at 04:59:01PM -0700, Luis R. Rodriguez wrote:
> Here's a few minor fs thaw fixes and adjustments I ran accross
> as I started to refresh my development for to use freeze_fs on
> suspend/hibernation [0]. These are just prep commits for the real
> work, I'm still reviewing feedback and adjusting the code for
> that.

And I forgot to provide the URL, for those that missed the old series
I was working on:

[0] https://lkml.kernel.org/r/20171129232356.28296-1-mcg...@kernel.org

  Luis
> 
> I've tested the patches with generic/085 on xfs and found no regressions.
> 
> Luis R. Rodriguez (3):
>   fs: move documentation for thaw_super() where appropriate
>   fs: make thaw_super_locked() really just a helper
>   fs: fix corner case race on freeze_bdev() when sb disappears
> 
>  fs/block_dev.c |  4 +++-
>  fs/super.c | 39 ++-
>  2 files changed, 29 insertions(+), 14 deletions(-)
> 
> -- 
> 2.16.3
> 
> 

-- 
Do not panic

Re: [PATCH 0/3] fs: minor fs thaw fixes and adjustments

[Luis R. Rodriguez]

On Fri, Apr 20, 2018 at 04:59:01PM -0700, Luis R. Rodriguez wrote:
> Here's a few minor fs thaw fixes and adjustments I ran accross
> as I started to refresh my development for to use freeze_fs on
> suspend/hibernation [0]. These are just prep commits for the real
> work, I'm still reviewing feedback and adjusting the code for
> that.

And I forgot to provide the URL, for those that missed the old series
I was working on:

[0] https://lkml.kernel.org/r/20171129232356.28296-1-mcg...@kernel.org

  Luis
> 
> I've tested the patches with generic/085 on xfs and found no regressions.
> 
> Luis R. Rodriguez (3):
>   fs: move documentation for thaw_super() where appropriate
>   fs: make thaw_super_locked() really just a helper
>   fs: fix corner case race on freeze_bdev() when sb disappears
> 
>  fs/block_dev.c |  4 +++-
>  fs/super.c | 39 ++-
>  2 files changed, 29 insertions(+), 14 deletions(-)
> 
> -- 
> 2.16.3
> 
> 

-- 
Do not panic

Re: [PATCH 1/3] fs: move documentation for thaw_super() where appropriate

[Bart Van Assche]

On Fri, 2018-04-20 at 16:59 -0700, Luis R. Rodriguez wrote:
> +/**
> + * thaw_super -- unlock filesystem
> + * @sb: the super to thaw
> + *
> + * Unlocks the filesystem and marks it writeable again after freeze_super().
> + */

Have you verified the output generated by scripts/kernel-doc? Last
time I checked the output for headers containing a double dash looked
weird.

Bart.

Re: [PATCH 1/3] fs: move documentation for thaw_super() where appropriate

[Bart Van Assche]

On Fri, 2018-04-20 at 16:59 -0700, Luis R. Rodriguez wrote:
> +/**
> + * thaw_super -- unlock filesystem
> + * @sb: the super to thaw
> + *
> + * Unlocks the filesystem and marks it writeable again after freeze_super().
> + */

Have you verified the output generated by scripts/kernel-doc? Last
time I checked the output for headers containing a double dash looked
weird.

Bart.

[PATCH 3/3] fs: fix corner case race on freeze_bdev() when sb disappears

[Luis R. Rodriguez]

freeze_bdev() will bail but leave the bd_fsfreeze_count incremented
if the get_active_super() does not find the superblock on our
super_blocks list to match.

This issue has been present since v2.6.29 during the introduction of the
ioctl_fsfreeze() and ioctl_fsthaw() via commit fcccf502540e3 ("filesystem
freeze: implement generic freeze feature").

I am not aware of any existing races which have triggered this
situation, however, if it does trigger it could mean leaving a
superblock with bd_fsfreeze_count always positive.

Fixes: fcccf502540e3 ("filesystem freeze: implement generic freeze feature")
Signed-off-by: Luis R. Rodriguez 
---
 fs/block_dev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index b54966679833..7a532aa58c07 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -507,8 +507,10 @@ struct super_block *freeze_bdev(struct block_device *bdev)
}
 
sb = get_active_super(bdev);
-   if (!sb)
+   if (!sb) {
+   bdev->bd_fsfreeze_count--;
goto out;
+   }
if (sb->s_op->freeze_super)
error = sb->s_op->freeze_super(sb);
else
-- 
2.16.3

[PATCH 3/3] fs: fix corner case race on freeze_bdev() when sb disappears

[Luis R. Rodriguez]

freeze_bdev() will bail but leave the bd_fsfreeze_count incremented
if the get_active_super() does not find the superblock on our
super_blocks list to match.

This issue has been present since v2.6.29 during the introduction of the
ioctl_fsfreeze() and ioctl_fsthaw() via commit fcccf502540e3 ("filesystem
freeze: implement generic freeze feature").

I am not aware of any existing races which have triggered this
situation, however, if it does trigger it could mean leaving a
superblock with bd_fsfreeze_count always positive.

Fixes: fcccf502540e3 ("filesystem freeze: implement generic freeze feature")
Signed-off-by: Luis R. Rodriguez 
---
 fs/block_dev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index b54966679833..7a532aa58c07 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -507,8 +507,10 @@ struct super_block *freeze_bdev(struct block_device *bdev)
}
 
sb = get_active_super(bdev);
-   if (!sb)
+   if (!sb) {
+   bdev->bd_fsfreeze_count--;
goto out;
+   }
if (sb->s_op->freeze_super)
error = sb->s_op->freeze_super(sb);
else
-- 
2.16.3

[PATCH 1/3] fs: move documentation for thaw_super() where appropriate

[Luis R. Rodriguez]

On commit 08fdc8a0138a ("buffer.c: call thaw_super during emergency thaw")
Mateusz added thaw_super_locked() and made thaw_super() use it, but
forgot to move the documentation.

Signed-off-by: Luis R. Rodriguez 
---
 fs/super.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/super.c b/fs/super.c
index 5fa9a8d8d865..9d0eb5e20a1f 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1532,12 +1532,6 @@ int freeze_super(struct super_block *sb)
 }
 EXPORT_SYMBOL(freeze_super);
 
-/**
- * thaw_super -- unlock filesystem
- * @sb: the super to thaw
- *
- * Unlocks the filesystem and marks it writeable again after freeze_super().
- */
 static int thaw_super_locked(struct super_block *sb)
 {
int error;
@@ -1573,6 +1567,12 @@ static int thaw_super_locked(struct super_block *sb)
return 0;
 }
 
+/**
+ * thaw_super -- unlock filesystem
+ * @sb: the super to thaw
+ *
+ * Unlocks the filesystem and marks it writeable again after freeze_super().
+ */
 int thaw_super(struct super_block *sb)
 {
down_write(>s_umount);
-- 
2.16.3

[PATCH 2/3] fs: make thaw_super_locked() really just a helper

[Luis R. Rodriguez]

thaw_super_locked() was added via commit 08fdc8a0138a ("buffer.c: call
thaw_super during emergency thaw") merged on v4.17 to help with the
ability so that the caller can take charge of handling the s_umount lock,
however, it has left all* of the failure handling including unlocking
lock of s_umount inside thaw_super_locked().

This does not make thaw_super_locked() flexible. For instance we may
later want to use it with the abilty to handle unfolding of the locks
ourselves.

Change thaw_super_locked() to really just be a helper, and let the
callers deal with all the error handling.

This commit introeuces no functional changes.

Signed-off-by: Luis R. Rodriguez 
---
 fs/super.c | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/fs/super.c b/fs/super.c
index 9d0eb5e20a1f..82bc74a16f06 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -937,10 +937,15 @@ void emergency_remount(void)
 
 static void do_thaw_all_callback(struct super_block *sb)
 {
+   int error;
+
down_write(>s_umount);
if (sb->s_root && sb->s_flags & MS_BORN) {
emergency_thaw_bdev(sb);
-   thaw_super_locked(sb);
+   error = thaw_super_locked(sb);
+   if (error)
+   up_write(>s_umount);
+   deactivate_locked_super(sb);
} else {
up_write(>s_umount);
}
@@ -1532,14 +1537,13 @@ int freeze_super(struct super_block *sb)
 }
 EXPORT_SYMBOL(freeze_super);
 
+/* Caller takes the sb->s_umount rw_semaphore lock and handles active count */
 static int thaw_super_locked(struct super_block *sb)
 {
int error;
 
-   if (sb->s_writers.frozen != SB_FREEZE_COMPLETE) {
-   up_write(>s_umount);
+   if (sb->s_writers.frozen != SB_FREEZE_COMPLETE)
return -EINVAL;
-   }
 
if (sb_rdonly(sb)) {
sb->s_writers.frozen = SB_UNFROZEN;
@@ -1554,7 +1558,6 @@ static int thaw_super_locked(struct super_block *sb)
printk(KERN_ERR
"VFS:Filesystem thaw failed\n");
lockdep_sb_freeze_release(sb);
-   up_write(>s_umount);
return error;
}
}
@@ -1563,7 +1566,6 @@ static int thaw_super_locked(struct super_block *sb)
sb_freeze_unlock(sb);
 out:
wake_up(>s_writers.wait_unfrozen);
-   deactivate_locked_super(sb);
return 0;
 }
 
@@ -1575,7 +1577,18 @@ static int thaw_super_locked(struct super_block *sb)
  */
 int thaw_super(struct super_block *sb)
 {
+   int error;
+
down_write(>s_umount);
-   return thaw_super_locked(sb);
+   error = thaw_super_locked(sb);
+   if (error) {
+   up_write(>s_umount);
+   goto out;
+   }
+
+   deactivate_locked_super(sb);
+
+out:
+   return error;
 }
 EXPORT_SYMBOL(thaw_super);
-- 
2.16.3

Re: unregister_netdevice: waiting for DEV to become free

[syzbot]

syzbot has found reproducer for the following crash on  
https://github.com/google/kmsan.git/master commit

48c6a2b0ab1b752451cdc40b5392471ed1a2a329 (Mon Apr 16 08:42:26 2018 +)
mm/kmsan: fix origin calculation in kmsan_internal_check_memory
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=2dfb68e639f0621b19fb


So far this crash happened 180 times on  
https://github.com/google/kmsan.git/master, net-next, upstream.

C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4936564132020224
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=5817131010621440
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=6313498770407424
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6627248707860932248

compiler: clang version 7.0.0 (trunk 329391)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2dfb68e639f0621b1...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
unregister_netdevice: waiting for lo to become free. Usage count = 3

[PATCH 1/3] fs: move documentation for thaw_super() where appropriate

[Luis R. Rodriguez]

On commit 08fdc8a0138a ("buffer.c: call thaw_super during emergency thaw")
Mateusz added thaw_super_locked() and made thaw_super() use it, but
forgot to move the documentation.

Signed-off-by: Luis R. Rodriguez 
---
 fs/super.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/super.c b/fs/super.c
index 5fa9a8d8d865..9d0eb5e20a1f 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -1532,12 +1532,6 @@ int freeze_super(struct super_block *sb)
 }
 EXPORT_SYMBOL(freeze_super);
 
-/**
- * thaw_super -- unlock filesystem
- * @sb: the super to thaw
- *
- * Unlocks the filesystem and marks it writeable again after freeze_super().
- */
 static int thaw_super_locked(struct super_block *sb)
 {
int error;
@@ -1573,6 +1567,12 @@ static int thaw_super_locked(struct super_block *sb)
return 0;
 }
 
+/**
+ * thaw_super -- unlock filesystem
+ * @sb: the super to thaw
+ *
+ * Unlocks the filesystem and marks it writeable again after freeze_super().
+ */
 int thaw_super(struct super_block *sb)
 {
down_write(>s_umount);
-- 
2.16.3

[PATCH 2/3] fs: make thaw_super_locked() really just a helper

[Luis R. Rodriguez]

thaw_super_locked() was added via commit 08fdc8a0138a ("buffer.c: call
thaw_super during emergency thaw") merged on v4.17 to help with the
ability so that the caller can take charge of handling the s_umount lock,
however, it has left all* of the failure handling including unlocking
lock of s_umount inside thaw_super_locked().

This does not make thaw_super_locked() flexible. For instance we may
later want to use it with the abilty to handle unfolding of the locks
ourselves.

Change thaw_super_locked() to really just be a helper, and let the
callers deal with all the error handling.

This commit introeuces no functional changes.

Signed-off-by: Luis R. Rodriguez 
---
 fs/super.c | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/fs/super.c b/fs/super.c
index 9d0eb5e20a1f..82bc74a16f06 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -937,10 +937,15 @@ void emergency_remount(void)
 
 static void do_thaw_all_callback(struct super_block *sb)
 {
+   int error;
+
down_write(>s_umount);
if (sb->s_root && sb->s_flags & MS_BORN) {
emergency_thaw_bdev(sb);
-   thaw_super_locked(sb);
+   error = thaw_super_locked(sb);
+   if (error)
+   up_write(>s_umount);
+   deactivate_locked_super(sb);
} else {
up_write(>s_umount);
}
@@ -1532,14 +1537,13 @@ int freeze_super(struct super_block *sb)
 }
 EXPORT_SYMBOL(freeze_super);
 
+/* Caller takes the sb->s_umount rw_semaphore lock and handles active count */
 static int thaw_super_locked(struct super_block *sb)
 {
int error;
 
-   if (sb->s_writers.frozen != SB_FREEZE_COMPLETE) {
-   up_write(>s_umount);
+   if (sb->s_writers.frozen != SB_FREEZE_COMPLETE)
return -EINVAL;
-   }
 
if (sb_rdonly(sb)) {
sb->s_writers.frozen = SB_UNFROZEN;
@@ -1554,7 +1558,6 @@ static int thaw_super_locked(struct super_block *sb)
printk(KERN_ERR
"VFS:Filesystem thaw failed\n");
lockdep_sb_freeze_release(sb);
-   up_write(>s_umount);
return error;
}
}
@@ -1563,7 +1566,6 @@ static int thaw_super_locked(struct super_block *sb)
sb_freeze_unlock(sb);
 out:
wake_up(>s_writers.wait_unfrozen);
-   deactivate_locked_super(sb);
return 0;
 }
 
@@ -1575,7 +1577,18 @@ static int thaw_super_locked(struct super_block *sb)
  */
 int thaw_super(struct super_block *sb)
 {
+   int error;
+
down_write(>s_umount);
-   return thaw_super_locked(sb);
+   error = thaw_super_locked(sb);
+   if (error) {
+   up_write(>s_umount);
+   goto out;
+   }
+
+   deactivate_locked_super(sb);
+
+out:
+   return error;
 }
 EXPORT_SYMBOL(thaw_super);
-- 
2.16.3

Re: unregister_netdevice: waiting for DEV to become free

[syzbot]

syzbot has found reproducer for the following crash on  
https://github.com/google/kmsan.git/master commit

48c6a2b0ab1b752451cdc40b5392471ed1a2a329 (Mon Apr 16 08:42:26 2018 +)
mm/kmsan: fix origin calculation in kmsan_internal_check_memory
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=2dfb68e639f0621b19fb


So far this crash happened 180 times on  
https://github.com/google/kmsan.git/master, net-next, upstream.

C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4936564132020224
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=5817131010621440
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=6313498770407424
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6627248707860932248

compiler: clang version 7.0.0 (trunk 329391)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2dfb68e639f0621b1...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
device bridge_slave_1 left promiscuous mode
bridge0: port 2(bridge_slave_1) entered disabled state
device bridge_slave_0 left promiscuous mode
bridge0: port 1(bridge_slave_0) entered disabled state
unregister_netdevice: waiting for lo to become free. Usage count = 3

[PATCH 0/3] fs: minor fs thaw fixes and adjustments

[Luis R. Rodriguez]

Here's a few minor fs thaw fixes and adjustments I ran accross
as I started to refresh my development for to use freeze_fs on
suspend/hibernation [0]. These are just prep commits for the real
work, I'm still reviewing feedback and adjusting the code for
that.

I've tested the patches with generic/085 on xfs and found no regressions.

Luis R. Rodriguez (3):
  fs: move documentation for thaw_super() where appropriate
  fs: make thaw_super_locked() really just a helper
  fs: fix corner case race on freeze_bdev() when sb disappears

 fs/block_dev.c |  4 +++-
 fs/super.c | 39 ++-
 2 files changed, 29 insertions(+), 14 deletions(-)

-- 
2.16.3

[PATCH 0/3] fs: minor fs thaw fixes and adjustments

[Luis R. Rodriguez]

Here's a few minor fs thaw fixes and adjustments I ran accross
as I started to refresh my development for to use freeze_fs on
suspend/hibernation [0]. These are just prep commits for the real
work, I'm still reviewing feedback and adjusting the code for
that.

I've tested the patches with generic/085 on xfs and found no regressions.

Luis R. Rodriguez (3):
  fs: move documentation for thaw_super() where appropriate
  fs: make thaw_super_locked() really just a helper
  fs: fix corner case race on freeze_bdev() when sb disappears

 fs/block_dev.c |  4 +++-
 fs/super.c | 39 ++-
 2 files changed, 29 insertions(+), 14 deletions(-)

-- 
2.16.3

Re: [RFC PATCH 00/79] Generic page write protection and a solution to page waitqueue

[Tim Chen]

On 04/20/2018 03:19 PM, Jerome Glisse wrote:
> On Fri, Apr 20, 2018 at 12:57:41PM -0700, Tim Chen wrote:
>> On 04/04/2018 12:17 PM, jgli...@redhat.com wrote:
>>
>>
>> Your approach seems useful if there are lots of locked pages sharing
>> the same wait queue.  
>>
>> That said, in the original workload from our customer with the long wait 
>> queue
>> problem, there was a single super hot page getting migrated, and it
>> is being accessed by all threads which caused the big log jam while they 
>> wait for
>> the migration to get completed.  
>> With your approach, we will still likely end up with a long queue 
>> in that workload even if we have per page wait queue.
>>
>> Thanks.
> 
> Ok so i re-read the thread, i was writting this cover letter from memory
> and i had bad recollection of your issue, so sorry.
> 
> First, do you have a way to reproduce the issue ? Something easy would
> be nice :)

Unfortunately it is a customer workload that they guard closely and wouldn't 
let us
look at the source code.  We have to profile and backtrace its behavior.

Mel made a quick attempt to reproduce the behavior with a hot page migration, 
but he wasn't quite able to duplicate the pathologic behavior.

> 
> So what i am proposing for per page wait queue would only marginaly help
> you (it might not even be mesurable in your workload). It would certainly
> make the code smaller and easier to understand i believe.

In certain cases if we have lots of pages sharing a page wait queue,
your solution would help, and we wouldn't be wasting time checking
waiters not waiting on the page that's being unlocked.  Though I
don't have a specific workload that has such behavior.

> 
> Now that i have look back at your issue i think there is 2 things we
> should do. First keep migration page map read only, this would at least
> avoid CPU read fault. In trace you captured i wasn't able to ascertain
> if this were read or write fault.
> 
> Second idea i have is about NUMA, everytime we NUMA migrate a page we
> could attach a temporary struct to the page (using page->mapping). So
> if we scan that page again we can inspect information about previous
> migration and see if we are not over migrating that page (ie bouncing
> it all over). If so we can mark the page (maybe with a page flag if we
> can find one) to protect it from further migration. That temporary
> struct would be remove after a while, ie autonuma would preallocate a
> bunch of those and keep an LRU of them and recycle the oldest when it
> needs a new one to migrate another page.

The goal to migrate a hot page with care, or avoid bouncing it around 
frequently makes sense.  If it is a hot page shared by many threads
running on different NUMA nodes, and moving it will only mildly improve NUMA
locality, we should avoid the migration.

Tim

> 
> 
> LSF/MM slots:
> 
> Michal can i get 2 slots to talk about this ? MM only discussion, one
> to talk about doing migration with page map read only but write
> protected while migration is happening. The other one to talk about
> attaching auto NUMA tracking struct to page.
> 
> Cheers,
> Jérôme
> 

Re: [RFC PATCH 00/79] Generic page write protection and a solution to page waitqueue

[Tim Chen]

On 04/20/2018 03:19 PM, Jerome Glisse wrote:
> On Fri, Apr 20, 2018 at 12:57:41PM -0700, Tim Chen wrote:
>> On 04/04/2018 12:17 PM, jgli...@redhat.com wrote:
>>
>>
>> Your approach seems useful if there are lots of locked pages sharing
>> the same wait queue.  
>>
>> That said, in the original workload from our customer with the long wait 
>> queue
>> problem, there was a single super hot page getting migrated, and it
>> is being accessed by all threads which caused the big log jam while they 
>> wait for
>> the migration to get completed.  
>> With your approach, we will still likely end up with a long queue 
>> in that workload even if we have per page wait queue.
>>
>> Thanks.
> 
> Ok so i re-read the thread, i was writting this cover letter from memory
> and i had bad recollection of your issue, so sorry.
> 
> First, do you have a way to reproduce the issue ? Something easy would
> be nice :)

Unfortunately it is a customer workload that they guard closely and wouldn't 
let us
look at the source code.  We have to profile and backtrace its behavior.

Mel made a quick attempt to reproduce the behavior with a hot page migration, 
but he wasn't quite able to duplicate the pathologic behavior.

> 
> So what i am proposing for per page wait queue would only marginaly help
> you (it might not even be mesurable in your workload). It would certainly
> make the code smaller and easier to understand i believe.

In certain cases if we have lots of pages sharing a page wait queue,
your solution would help, and we wouldn't be wasting time checking
waiters not waiting on the page that's being unlocked.  Though I
don't have a specific workload that has such behavior.

> 
> Now that i have look back at your issue i think there is 2 things we
> should do. First keep migration page map read only, this would at least
> avoid CPU read fault. In trace you captured i wasn't able to ascertain
> if this were read or write fault.
> 
> Second idea i have is about NUMA, everytime we NUMA migrate a page we
> could attach a temporary struct to the page (using page->mapping). So
> if we scan that page again we can inspect information about previous
> migration and see if we are not over migrating that page (ie bouncing
> it all over). If so we can mark the page (maybe with a page flag if we
> can find one) to protect it from further migration. That temporary
> struct would be remove after a while, ie autonuma would preallocate a
> bunch of those and keep an LRU of them and recycle the oldest when it
> needs a new one to migrate another page.

The goal to migrate a hot page with care, or avoid bouncing it around 
frequently makes sense.  If it is a hot page shared by many threads
running on different NUMA nodes, and moving it will only mildly improve NUMA
locality, we should avoid the migration.

Tim

> 
> 
> LSF/MM slots:
> 
> Michal can i get 2 slots to talk about this ? MM only discussion, one
> to talk about doing migration with page map read only but write
> protected while migration is happening. The other one to talk about
> attaching auto NUMA tracking struct to page.
> 
> Cheers,
> Jérôme
> 

Re: [PATCH 2/2] drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+

[Eric Anholt]

Daniel Vetter  writes:

> On Thu, Apr 19, 2018 at 12:20:35PM -0700, Eric Anholt wrote:
>> This driver will be used to support Mesa on the Broadcom 7268 and 7278
>> platforms.
>> 
>> V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's
>> complicated CL/shader validation scheme.  This massively changes the
>> GEM behavior, so I've forked off to a new driver.
>> 
>> Signed-off-by: Eric Anholt 
>
> Read through the entire thing, ignored the hw details, but dropped a few
> comments all over. With those addressed one way or another this has my
>
> Acked-by: Daniel Vetter 
>
> Can I call in a return favour for
> https://patchwork.freedesktop.org/series/41219/ ?

Done.

>> diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
>> index d3ab6abae838..f982558fc25d 100644
>> --- a/Documentation/gpu/drivers.rst
>> +++ b/Documentation/gpu/drivers.rst
>> @@ -10,6 +10,7 @@ GPU Driver Documentation
>> tegra
>> tinydrm
>> tve200
>> +   v3d
>> vc4
>> bridge/dw-hdmi
>> xen-front
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index bca3c32fb141..7314d66833fd 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -4795,6 +4795,15 @@ S:Maintained
>>  F:  drivers/gpu/drm/omapdrm/
>>  F:  Documentation/devicetree/bindings/display/ti/
>>  
>> +DRM DRIVERS FOR V3D
>> +M:  Eric Anholt 
>> +T:  git git://github.com/anholt/linux
>
> This one also official? If it's just for now I'd drop it ...

Sure.

>> +/* Pins the shmem pages, fills in the .pages and .sgt fields of the BO, and 
>> maps
>> + * it for DMA.
>> + */
>> +static int
>> +v3d_bo_get_pages(struct v3d_bo *bo)
>> +{
>> +struct drm_gem_object *obj = >base;
>> +struct drm_device *dev = obj->dev;
>> +int npages = obj->size >> PAGE_SHIFT;
>> +int ret = 0;
>> +
>> +mutex_lock(>lock);
>> +if (bo->pages_refcount++ != 0)
>> +goto unlock;
>> +
>> +if (!obj->import_attach) {
>> +bo->pages = drm_gem_get_pages(obj);
>> +if (IS_ERR(bo->pages)) {
>> +ret = PTR_ERR(bo->pages);
>> +goto unlock;
>> +}
>> +
>> +bo->sgt = drm_prime_pages_to_sg(bo->pages, npages);
>> +if (IS_ERR(bo->sgt)) {
>> +ret = PTR_ERR(bo->sgt);
>> +goto put_pages;
>> +}
>> +} else {
>> +bo->pages = kcalloc(npages, sizeof(*bo->pages), GFP_KERNEL);
>> +if (!bo->pages)
>> +goto put_pages;
>> +
>> +drm_prime_sg_to_page_addr_arrays(bo->sgt, bo->pages,
>> + NULL, npages);
>> +}
>> +
>> +/* Map the pages for use by the GPU. */
>> +dma_map_sg(dev->dev, bo->sgt->sgl,
>> +   bo->sgt->nents, DMA_BIDIRECTIONAL);
>
> For dma-buf you already get a mapped sgt, and the idea at least is to not
> noodle around in internals like drm_prime_sg_to_page_addr_arrays does ...
> That was just a hack Dave did to avoid rewriting all of ttm, which imo
> shouldn't be copied all over the place (but it happens).
>
> Since you immediately convert the page list back into a mapped sg table
> it's a bit silly.
>
> I guess longer-term we could switch the gem helpers to just use sg tables
> directly, instead of going through pages arrays. But core mm folks just
> got nasty on us doing that, so I'm not sure which direction we should go
> here longer-term.

I moved the map/unmap to the !import case.  We still need the pages
array for v3d_gem_fault().  If we have an alternative for that that
isn't a linear walk of the sg at fault time, I'd be up for that.

>> +int v3d_gem_fault(struct vm_fault *vmf)
>> +{
>> +struct vm_area_struct *vma = vmf->vma;
>> +struct drm_gem_object *obj = vma->vm_private_data;
>> +struct v3d_bo *bo = to_v3d_bo(obj);
>> +unsigned long pfn;
>> +pgoff_t pgoff;
>> +int ret;
>> +
>> +/* We don't use vmf->pgoff since that has the fake offset: */
>> +pgoff = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
>> +pfn = page_to_pfn(bo->pages[pgoff]);
>
> Freaked out for a bit, then noticed you're pinning everything. That makes
> the bo->pages_refcount a bit confusing since totally not needed.
>
> I guess if you do have longer-term plans to roll out a shrinker I'd put at
> least a FIXME here.

Yep, long-term shrinker plans.  Added a note to the kerneldoc about why
we don't shrink yet.

>> +int v3d_mmap(struct file *filp, struct vm_area_struct *vma)
>> +{
>> +int ret;
>> +
>> +ret = drm_gem_mmap(filp, vma);
>> +if (ret)
>> +return ret;
>> +
>> +v3d_set_mmap_vma_flags(vma);
>
> If it'd actually understand what these vma flag frobberies in most drivers
> do I might come up with an idea how we can avoid the copypaste. Oh well.
> Maybe a drm_gem_mmap_wc?

drm_gem_mmap seems to already be wc, just with different vma flags.  If
you ever figure 

Re: [PATCH 2/2] drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+

[Eric Anholt]

Daniel Vetter  writes:

> On Thu, Apr 19, 2018 at 12:20:35PM -0700, Eric Anholt wrote:
>> This driver will be used to support Mesa on the Broadcom 7268 and 7278
>> platforms.
>> 
>> V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's
>> complicated CL/shader validation scheme.  This massively changes the
>> GEM behavior, so I've forked off to a new driver.
>> 
>> Signed-off-by: Eric Anholt 
>
> Read through the entire thing, ignored the hw details, but dropped a few
> comments all over. With those addressed one way or another this has my
>
> Acked-by: Daniel Vetter 
>
> Can I call in a return favour for
> https://patchwork.freedesktop.org/series/41219/ ?

Done.

>> diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
>> index d3ab6abae838..f982558fc25d 100644
>> --- a/Documentation/gpu/drivers.rst
>> +++ b/Documentation/gpu/drivers.rst
>> @@ -10,6 +10,7 @@ GPU Driver Documentation
>> tegra
>> tinydrm
>> tve200
>> +   v3d
>> vc4
>> bridge/dw-hdmi
>> xen-front
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index bca3c32fb141..7314d66833fd 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -4795,6 +4795,15 @@ S:Maintained
>>  F:  drivers/gpu/drm/omapdrm/
>>  F:  Documentation/devicetree/bindings/display/ti/
>>  
>> +DRM DRIVERS FOR V3D
>> +M:  Eric Anholt 
>> +T:  git git://github.com/anholt/linux
>
> This one also official? If it's just for now I'd drop it ...

Sure.

>> +/* Pins the shmem pages, fills in the .pages and .sgt fields of the BO, and 
>> maps
>> + * it for DMA.
>> + */
>> +static int
>> +v3d_bo_get_pages(struct v3d_bo *bo)
>> +{
>> +struct drm_gem_object *obj = >base;
>> +struct drm_device *dev = obj->dev;
>> +int npages = obj->size >> PAGE_SHIFT;
>> +int ret = 0;
>> +
>> +mutex_lock(>lock);
>> +if (bo->pages_refcount++ != 0)
>> +goto unlock;
>> +
>> +if (!obj->import_attach) {
>> +bo->pages = drm_gem_get_pages(obj);
>> +if (IS_ERR(bo->pages)) {
>> +ret = PTR_ERR(bo->pages);
>> +goto unlock;
>> +}
>> +
>> +bo->sgt = drm_prime_pages_to_sg(bo->pages, npages);
>> +if (IS_ERR(bo->sgt)) {
>> +ret = PTR_ERR(bo->sgt);
>> +goto put_pages;
>> +}
>> +} else {
>> +bo->pages = kcalloc(npages, sizeof(*bo->pages), GFP_KERNEL);
>> +if (!bo->pages)
>> +goto put_pages;
>> +
>> +drm_prime_sg_to_page_addr_arrays(bo->sgt, bo->pages,
>> + NULL, npages);
>> +}
>> +
>> +/* Map the pages for use by the GPU. */
>> +dma_map_sg(dev->dev, bo->sgt->sgl,
>> +   bo->sgt->nents, DMA_BIDIRECTIONAL);
>
> For dma-buf you already get a mapped sgt, and the idea at least is to not
> noodle around in internals like drm_prime_sg_to_page_addr_arrays does ...
> That was just a hack Dave did to avoid rewriting all of ttm, which imo
> shouldn't be copied all over the place (but it happens).
>
> Since you immediately convert the page list back into a mapped sg table
> it's a bit silly.
>
> I guess longer-term we could switch the gem helpers to just use sg tables
> directly, instead of going through pages arrays. But core mm folks just
> got nasty on us doing that, so I'm not sure which direction we should go
> here longer-term.

I moved the map/unmap to the !import case.  We still need the pages
array for v3d_gem_fault().  If we have an alternative for that that
isn't a linear walk of the sg at fault time, I'd be up for that.

>> +int v3d_gem_fault(struct vm_fault *vmf)
>> +{
>> +struct vm_area_struct *vma = vmf->vma;
>> +struct drm_gem_object *obj = vma->vm_private_data;
>> +struct v3d_bo *bo = to_v3d_bo(obj);
>> +unsigned long pfn;
>> +pgoff_t pgoff;
>> +int ret;
>> +
>> +/* We don't use vmf->pgoff since that has the fake offset: */
>> +pgoff = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
>> +pfn = page_to_pfn(bo->pages[pgoff]);
>
> Freaked out for a bit, then noticed you're pinning everything. That makes
> the bo->pages_refcount a bit confusing since totally not needed.
>
> I guess if you do have longer-term plans to roll out a shrinker I'd put at
> least a FIXME here.

Yep, long-term shrinker plans.  Added a note to the kerneldoc about why
we don't shrink yet.

>> +int v3d_mmap(struct file *filp, struct vm_area_struct *vma)
>> +{
>> +int ret;
>> +
>> +ret = drm_gem_mmap(filp, vma);
>> +if (ret)
>> +return ret;
>> +
>> +v3d_set_mmap_vma_flags(vma);
>
> If it'd actually understand what these vma flag frobberies in most drivers
> do I might come up with an idea how we can avoid the copypaste. Oh well.
> Maybe a drm_gem_mmap_wc?

drm_gem_mmap seems to already be wc, just with different vma flags.  If
you ever figure out the flag frobbing, please let me know. :(

>> +
>> +return ret;
>> +}

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Stephen Boyd]

Quoting Rob Herring (2018-04-20 11:15:04)
> On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd  wrote:
> > Quoting Rob Herring (2018-04-18 15:29:05)
> >> diff --git a/Documentation/devicetree/bindings/example-schema.yaml 
> >> b/Documentation/devicetree/bindings/example-schema.yaml
> >> new file mode 100644
> >> index ..fe0a3bd1668e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/example-schema.yaml
> >> @@ -0,0 +1,149 @@
> >> +
> >> +  The end of the description is marked by indentation less than the first 
> >> line
> >> +  in the description.
> >> +
> >> +select: false
> >> +  # 'select' is a schema applied to a DT node to determine if this binding
> >> +  # schema should be applied to the node. It is optional and by default 
> >> the
> >> +  # possible compatible strings are extracted and used to match.
> >
> > Can we get a concrete example here?
> 
> select: true
> 
> :) Which is apply to every node.
> 
> A better one is from the memory node schema ('$nodename' gets added :
> 
> select:
>   required: ["$nodename"]
>   properties:
> $nodename:
>   oneOf:
> - pattern: "^memory@[0-9a-f]*"
> - const: "memory" # 'memory' only allowed for selecting
> 
> 
> I expect the vast majority of device bindings will not use select at
> all and rely on compatible string matching.

Thanks! I was looking to see how the select syntax would work and this
shows one example nicely. I suppose another way would be to show how a
compatible string would be matched through select, even though it's
redundant.

Is there a way we can enforce node names through the schema too? For
example to enforce that a clock controller is called 'clock-controller'
or a spi master is called 'spi'.

> 
> >> +
> >> +properties:
> > [...]
> >> +
> >> +  interrupts:
> >> +# Either 1 or 2 interrupts can be present
> >> +minItems: 1
> >> +maxItems: 2
> >> +items:
> >> +  - description: tx or combined interrupt
> >> +  - description: rx interrupt
> >> +
> >> +description: |
> >
> > The '|' is needed to make yaml happy?
> 
> Yes, this is simply how you do literal text blocks in yaml.
> 
> We don't really need for this one really, but for the top-level
> 'description' we do. The long term intent is 'description' would be
> written in sphinx/rst and can be extracted into the DT spec (for
> common bindings). Grant has experimented with that some.

Ok. That sounds cool. Then we could embed links to datasheets and SVGs
too.

> 
> >> +  A variable number of interrupts warrants a description of what 
> >> conditions
> >> +  affect the number of interrupts. Otherwise, descriptions on standard
> >> +  properties are not necessary.
> >> +
> >> +  interrupt-names:
> >> +# minItems must be specified here because the default would be 2
> >> +minItems: 1
> >> +items:
> >> +  - const: "tx irq"
> >> +  - const: "rx irq"
> >> +
> >> +  # Property names starting with '#' must be quoted
> >> +  '#interrupt-cells':
> >> +# A simple case where the value must always be '2'.
> >> +# The core schema handles that this must be a single integer.
> >> +const: 2
> >> +
> >> +  interrupt-controller: {}
> >
> > Does '{}' mean nothing to see here?
> 
> Yes. It's just an empty schema that's always valid.

Could we include another schema to indicate that this is an interrupt
controller? I'm sort of asking for multi-schema inheritance.

> 
> >> +  foo-gpios:
> >> +maxItems: 1
> >> +description: A connection of the 'foo' gpio line.
> >> +
> >> +  vendor,int-property:
> >> +description: Vendor specific properties must have a description
> >> +type: integer # A type is also required
> >> +enum: [2, 4, 6, 8, 10]
> >> +
> >> +  vendor,bool-property:
> >> +description: Vendor specific properties must have a description
> >> +type: boolean
> >> +
> >> +required:
> >> +  - compatible
> >> +  - reg
> >> +  - interrupts
> >> +  - interrupt-controller
> >
> > Can the required or optional parts go under each property instead of
> > having a different section?
> 
> No, because then it is not json-schema language.
> 
> > Or does that make the schema parser
> > difficult to implement?
> 
> Yes, because then we have to implement a schema parser.

:/

Re: [RFC PATCH] dt-bindings: add a jsonschema binding example

[Stephen Boyd]

Quoting Rob Herring (2018-04-20 11:15:04)
> On Fri, Apr 20, 2018 at 11:47 AM, Stephen Boyd  wrote:
> > Quoting Rob Herring (2018-04-18 15:29:05)
> >> diff --git a/Documentation/devicetree/bindings/example-schema.yaml 
> >> b/Documentation/devicetree/bindings/example-schema.yaml
> >> new file mode 100644
> >> index ..fe0a3bd1668e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/example-schema.yaml
> >> @@ -0,0 +1,149 @@
> >> +
> >> +  The end of the description is marked by indentation less than the first 
> >> line
> >> +  in the description.
> >> +
> >> +select: false
> >> +  # 'select' is a schema applied to a DT node to determine if this binding
> >> +  # schema should be applied to the node. It is optional and by default 
> >> the
> >> +  # possible compatible strings are extracted and used to match.
> >
> > Can we get a concrete example here?
> 
> select: true
> 
> :) Which is apply to every node.
> 
> A better one is from the memory node schema ('$nodename' gets added :
> 
> select:
>   required: ["$nodename"]
>   properties:
> $nodename:
>   oneOf:
> - pattern: "^memory@[0-9a-f]*"
> - const: "memory" # 'memory' only allowed for selecting
> 
> 
> I expect the vast majority of device bindings will not use select at
> all and rely on compatible string matching.

Thanks! I was looking to see how the select syntax would work and this
shows one example nicely. I suppose another way would be to show how a
compatible string would be matched through select, even though it's
redundant.

Is there a way we can enforce node names through the schema too? For
example to enforce that a clock controller is called 'clock-controller'
or a spi master is called 'spi'.

> 
> >> +
> >> +properties:
> > [...]
> >> +
> >> +  interrupts:
> >> +# Either 1 or 2 interrupts can be present
> >> +minItems: 1
> >> +maxItems: 2
> >> +items:
> >> +  - description: tx or combined interrupt
> >> +  - description: rx interrupt
> >> +
> >> +description: |
> >
> > The '|' is needed to make yaml happy?
> 
> Yes, this is simply how you do literal text blocks in yaml.
> 
> We don't really need for this one really, but for the top-level
> 'description' we do. The long term intent is 'description' would be
> written in sphinx/rst and can be extracted into the DT spec (for
> common bindings). Grant has experimented with that some.

Ok. That sounds cool. Then we could embed links to datasheets and SVGs
too.

> 
> >> +  A variable number of interrupts warrants a description of what 
> >> conditions
> >> +  affect the number of interrupts. Otherwise, descriptions on standard
> >> +  properties are not necessary.
> >> +
> >> +  interrupt-names:
> >> +# minItems must be specified here because the default would be 2
> >> +minItems: 1
> >> +items:
> >> +  - const: "tx irq"
> >> +  - const: "rx irq"
> >> +
> >> +  # Property names starting with '#' must be quoted
> >> +  '#interrupt-cells':
> >> +# A simple case where the value must always be '2'.
> >> +# The core schema handles that this must be a single integer.
> >> +const: 2
> >> +
> >> +  interrupt-controller: {}
> >
> > Does '{}' mean nothing to see here?
> 
> Yes. It's just an empty schema that's always valid.

Could we include another schema to indicate that this is an interrupt
controller? I'm sort of asking for multi-schema inheritance.

> 
> >> +  foo-gpios:
> >> +maxItems: 1
> >> +description: A connection of the 'foo' gpio line.
> >> +
> >> +  vendor,int-property:
> >> +description: Vendor specific properties must have a description
> >> +type: integer # A type is also required
> >> +enum: [2, 4, 6, 8, 10]
> >> +
> >> +  vendor,bool-property:
> >> +description: Vendor specific properties must have a description
> >> +type: boolean
> >> +
> >> +required:
> >> +  - compatible
> >> +  - reg
> >> +  - interrupts
> >> +  - interrupt-controller
> >
> > Can the required or optional parts go under each property instead of
> > having a different section?
> 
> No, because then it is not json-schema language.
> 
> > Or does that make the schema parser
> > difficult to implement?
> 
> Yes, because then we have to implement a schema parser.

:/

Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

[Jacob Pan]

On Fri, 20 Apr 2018 19:25:34 +0100
Jean-Philippe Brucker  wrote:

> On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote:
> [...]
> > > + /* Assign guest PASID table pointer and size order */
> > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) |
> > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS);  
> > 
> > Where does this IOMMU API interface define that base_ptr is 4K
> > aligned or the format of the PASID table?  Are these all
> > standardized or do they vary by host IOMMU?  If they're standards,
> > maybe we could note that and the spec which defines them when we
> > declare base_ptr.  If they're IOMMU specific then I don't
> > understand how we'll match a user provided PASID table to the
> > requirements and format of the host IOMMU. Thanks,  
> 
> On SMMUv3 the minimum alignment for base_ptr is 64 bytes, so a guest
> under a vSMMU might pass a pointer that's not aligned on 4k.
> 
PASID table pointer for VT-d is 4K aligned. 
> Maybe this information could be part of the data passed to userspace
> about IOMMU table formats and features? They're not part of this
> series, but I think we wanted to communicate IOMMU-specific features
> via sysfs.
> 
Agreed, I believe Yi Liu is working on a sysfs interface such that QEMU
can match IOMMU model and features.

Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

[Jacob Pan]

On Fri, 20 Apr 2018 19:25:34 +0100
Jean-Philippe Brucker  wrote:

> On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote:
> [...]
> > > + /* Assign guest PASID table pointer and size order */
> > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) |
> > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS);  
> > 
> > Where does this IOMMU API interface define that base_ptr is 4K
> > aligned or the format of the PASID table?  Are these all
> > standardized or do they vary by host IOMMU?  If they're standards,
> > maybe we could note that and the spec which defines them when we
> > declare base_ptr.  If they're IOMMU specific then I don't
> > understand how we'll match a user provided PASID table to the
> > requirements and format of the host IOMMU. Thanks,  
> 
> On SMMUv3 the minimum alignment for base_ptr is 64 bytes, so a guest
> under a vSMMU might pass a pointer that's not aligned on 4k.
> 
PASID table pointer for VT-d is 4K aligned. 
> Maybe this information could be part of the data passed to userspace
> about IOMMU table formats and features? They're not part of this
> series, but I think we wanted to communicate IOMMU-specific features
> via sysfs.
> 
Agreed, I believe Yi Liu is working on a sysfs interface such that QEMU
can match IOMMU model and features.

Re: [PATCH] [v2] scsi: ips: fix firmware timestamps for 32-bit

[Martin K. Petersen]

Arnd,

> do_gettimeofday() is deprecated since it will stop working in 2038 on
> 32-bit platforms, leading to incorrect times passed to the firmware.
> On 64-bit platforms the current code appears to be fine, as the
> calculation passes an 8-bit century number into the firmware that can
> represent times long in the future (possibly until 25599).
>
> Using ktime_get_real_seconds() to get a 64-bit seconds value and
> time64_to_tm() to convert it into the firmware format greatly
> simplifies the ips timekeeping code, makes 32-bit and 64-bit behave
> the same way here, and gets us closer to removing the deprecated
> interfaces.

Applied to 4.18/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] [v2] scsi: ips: fix firmware timestamps for 32-bit

[Martin K. Petersen]

Arnd,

> do_gettimeofday() is deprecated since it will stop working in 2038 on
> 32-bit platforms, leading to incorrect times passed to the firmware.
> On 64-bit platforms the current code appears to be fine, as the
> calculation passes an 8-bit century number into the firmware that can
> represent times long in the future (possibly until 25599).
>
> Using ktime_get_real_seconds() to get a 64-bit seconds value and
> time64_to_tm() to convert it into the firmware format greatly
> simplifies the ips timekeeping code, makes 32-bit and 64-bit behave
> the same way here, and gets us closer to removing the deprecated
> interfaces.

Applied to 4.18/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] [RESEND 2] scsi: esas2r: use ktime_get_real_seconds()

[Martin K. Petersen]

Arnd,

> do_gettimeofday() is deprecated because of the y2038 overflow.  Here,
> we use the result to pass into a 32-bit field in the firmware, which
> still risks an overflow, but if the firmware is written to expect
> unsigned values, it can at least last until y2106, and there is not
> much we can do about it.
>
> This changes do_gettimeofday() to ktime_get_real_seconds(), which at
> least simplifies the code a bit, and avoids the deprecated
> interface. I'm adding a comment about the overflow to document what
> happens.

Applied to 4.18/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] [RESEND 2] scsi: esas2r: use ktime_get_real_seconds()

[Martin K. Petersen]

Arnd,

> do_gettimeofday() is deprecated because of the y2038 overflow.  Here,
> we use the result to pass into a 32-bit field in the firmware, which
> still risks an overflow, but if the firmware is written to expect
> unsigned values, it can at least last until y2106, and there is not
> much we can do about it.
>
> This changes do_gettimeofday() to ktime_get_real_seconds(), which at
> least simplifies the code a bit, and avoids the deprecated
> interface. I'm adding a comment about the overflow to document what
> happens.

Applied to 4.18/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH] fscrypt: use unbound workqueue for decryption

[Eric Biggers]

Improve fscrypt read performance by switching the decryption workqueue
from bound to unbound.  With the bound workqueue, when multiple bios
completed on the same CPU, they were decrypted on that same CPU.  But
with the unbound queue, they are now decrypted in parallel on any CPU.

Although fscrypt read performance can be tough to measure due to the
many sources of variation, this change is most beneficial when
decryption is slow, e.g. on CPUs without AES instructions.  For example,
I timed tarring up encrypted directories on f2fs.  On x86 with AES-NI
instructions disabled, the unbound workqueue improved performance by
about 25-35%, using 1 to NUM_CPUs jobs with 4 or 8 CPUs available.  But
with AES-NI enabled, performance was unchanged to within ~2%.

I also did the same test on a quad-core ARM CPU using xts-speck128-neon
encryption.  There performance was usually about 10% better with the
unbound workqueue, bringing it closer to the unencrypted speed.

The unbound workqueue may be worse in some cases due to worse locality,
but I think it's still the better default.  dm-crypt uses an unbound
workqueue by default too, so this change makes fscrypt match.

Signed-off-by: Eric Biggers 
---
 fs/crypto/crypto.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c
index ce654526c0fb..984e190f9b89 100644
--- a/fs/crypto/crypto.c
+++ b/fs/crypto/crypto.c
@@ -427,8 +427,17 @@ int fscrypt_initialize(unsigned int cop_flags)
  */
 static int __init fscrypt_init(void)
 {
+   /*
+* Use an unbound workqueue to allow bios to be decrypted in parallel
+* even when they happen to complete on the same CPU.  This sacrifices
+* locality, but it's worthwhile since decryption is CPU-intensive.
+*
+* Also use a high-priority workqueue to prioritize decryption work,
+* which blocks reads from completing, over regular application tasks.
+*/
fscrypt_read_workqueue = alloc_workqueue("fscrypt_read_queue",
-   WQ_HIGHPRI, 0);
+WQ_UNBOUND | WQ_HIGHPRI,
+num_online_cpus());
if (!fscrypt_read_workqueue)
goto fail;
 
-- 
2.17.0.484.g0c8726318c-goog

[PATCH] fscrypt: use unbound workqueue for decryption

[Eric Biggers]

Improve fscrypt read performance by switching the decryption workqueue
from bound to unbound.  With the bound workqueue, when multiple bios
completed on the same CPU, they were decrypted on that same CPU.  But
with the unbound queue, they are now decrypted in parallel on any CPU.

Although fscrypt read performance can be tough to measure due to the
many sources of variation, this change is most beneficial when
decryption is slow, e.g. on CPUs without AES instructions.  For example,
I timed tarring up encrypted directories on f2fs.  On x86 with AES-NI
instructions disabled, the unbound workqueue improved performance by
about 25-35%, using 1 to NUM_CPUs jobs with 4 or 8 CPUs available.  But
with AES-NI enabled, performance was unchanged to within ~2%.

I also did the same test on a quad-core ARM CPU using xts-speck128-neon
encryption.  There performance was usually about 10% better with the
unbound workqueue, bringing it closer to the unencrypted speed.

The unbound workqueue may be worse in some cases due to worse locality,
but I think it's still the better default.  dm-crypt uses an unbound
workqueue by default too, so this change makes fscrypt match.

Signed-off-by: Eric Biggers 
---
 fs/crypto/crypto.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/crypto/crypto.c b/fs/crypto/crypto.c
index ce654526c0fb..984e190f9b89 100644
--- a/fs/crypto/crypto.c
+++ b/fs/crypto/crypto.c
@@ -427,8 +427,17 @@ int fscrypt_initialize(unsigned int cop_flags)
  */
 static int __init fscrypt_init(void)
 {
+   /*
+* Use an unbound workqueue to allow bios to be decrypted in parallel
+* even when they happen to complete on the same CPU.  This sacrifices
+* locality, but it's worthwhile since decryption is CPU-intensive.
+*
+* Also use a high-priority workqueue to prioritize decryption work,
+* which blocks reads from completing, over regular application tasks.
+*/
fscrypt_read_workqueue = alloc_workqueue("fscrypt_read_queue",
-   WQ_HIGHPRI, 0);
+WQ_UNBOUND | WQ_HIGHPRI,
+num_online_cpus());
if (!fscrypt_read_workqueue)
goto fail;
 
-- 
2.17.0.484.g0c8726318c-goog

Re: [PATCH][V2] isci: Fix infinite loop in while loop

[Martin K. Petersen]

Colin,

> In the case when the phy_mask is bitwise anded with the phy_index bit
> is zero the continue statement currently jumps to the next iteration
> of the while loop and phy_index is never actually incremented,
> potentially causing an infinite loop if phy_index is less than
> SCI_MAX_PHS. Fix this by turning the while loop into a for loop.

Applied to 4.17/scsi-fixes. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH][V2] isci: Fix infinite loop in while loop

[Martin K. Petersen]

Colin,

> In the case when the phy_mask is bitwise anded with the phy_index bit
> is zero the continue statement currently jumps to the next iteration
> of the while loop and phy_index is never actually incremented,
> potentially causing an infinite loop if phy_index is less than
> SCI_MAX_PHS. Fix this by turning the while loop into a for loop.

Applied to 4.17/scsi-fixes. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] perf tools: set kernel end address properly

[Kim Phillips]

On Fri, 20 Apr 2018 08:59:15 +0900
Namhyung Kim  wrote:

> The map_groups__fixup_end() was called to set end addresses of kernel
> map and module maps.  But now machine__create_modules() is set the end
> address of modules properly, the only remaining piece is the kernel map.
> We can set it with adjacent module's address directly instead of calling
> the map_groups__fixup_end().  If there's no module after the kernel map,
> the end address will be ~0ULL.
> 
> Since it also changes the start address of the kernel map, it needs to
> re-insert the map to the kmaps in order to keep a correct ordering.  Kim
> reported that it caused problems on ARM64.
> 
> Reported-by: Kim Phillips 
> Signed-off-by: Namhyung Kim 
> ---

Acked-by: Kim Phillips 

Thanks,

Kim

Re: [PATCH] perf tools: set kernel end address properly

[Kim Phillips]

On Fri, 20 Apr 2018 08:59:15 +0900
Namhyung Kim  wrote:

> The map_groups__fixup_end() was called to set end addresses of kernel
> map and module maps.  But now machine__create_modules() is set the end
> address of modules properly, the only remaining piece is the kernel map.
> We can set it with adjacent module's address directly instead of calling
> the map_groups__fixup_end().  If there's no module after the kernel map,
> the end address will be ~0ULL.
> 
> Since it also changes the start address of the kernel map, it needs to
> re-insert the map to the kmaps in order to keep a correct ordering.  Kim
> reported that it caused problems on ARM64.
> 
> Reported-by: Kim Phillips 
> Signed-off-by: Namhyung Kim 
> ---

Acked-by: Kim Phillips 

Thanks,

Kim

Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

[Jacob Pan]

On Tue, 17 Apr 2018 13:10:47 -0600
Alex Williamson  wrote:

> On Mon, 16 Apr 2018 14:48:53 -0700
> Jacob Pan  wrote:
> 
> > Add Intel VT-d ops to the generic iommu_bind_pasid_table API
> > functions.
> > 
> > The primary use case is for direct assignment of SVM capable
> > device. Originated from emulated IOMMU in the guest, the request
> > goes through many layers (e.g. VFIO). Upon calling host IOMMU
> > driver, caller passes guest PASID table pointer (GPA) and size.
> > 
> > Device context table entry is modified by Intel IOMMU specific
> > bind_pasid_table function. This will turn on nesting mode and
> > matching translation type.
> > 
> > The unbind operation restores default context mapping.
> > 
> > Signed-off-by: Jacob Pan 
> > Signed-off-by: Liu, Yi L 
> > Signed-off-by: Ashok Raj 
> > ---
> >  drivers/iommu/intel-iommu.c   | 119
> > ++
> > include/linux/dma_remapping.h |   1 + 2 files changed, 120
> > insertions(+)
> > 
> > diff --git a/drivers/iommu/intel-iommu.c
> > b/drivers/iommu/intel-iommu.c index a0f81a4..d8058be 100644
> > --- a/drivers/iommu/intel-iommu.c
> > +++ b/drivers/iommu/intel-iommu.c
> > @@ -2409,6 +2409,7 @@ static struct dmar_domain
> > *dmar_insert_one_dev_info(struct intel_iommu *iommu,
> > info->ats_supported = info->pasid_supported = info->pri_supported =
> > 0; info->ats_enabled = info->pasid_enabled = info->pri_enabled = 0;
> > info->ats_qdep = 0;
> > +   info->pasid_table_bound = 0;
> > info->dev = dev;
> > info->domain = domain;
> > info->iommu = iommu;
> > @@ -5132,6 +5133,7 @@ static void
> > intel_iommu_put_resv_regions(struct device *dev, 
> >  #ifdef CONFIG_INTEL_IOMMU_SVM
> >  #define MAX_NR_PASID_BITS (20)
> > +#define MIN_NR_PASID_BITS (5)
> >  static inline unsigned long intel_iommu_get_pts(struct intel_iommu
> > *iommu) {
> > /*
> > @@ -5258,6 +5260,119 @@ struct intel_iommu
> > *intel_svm_device_to_iommu(struct device *dev) 
> > return iommu;
> >  }
> > +
> > +static int intel_iommu_bind_pasid_table(struct iommu_domain
> > *domain,
> > +   struct device *dev, struct pasid_table_config
> > *pasidt_binfo) +{  
> 
> Never validates pasidt_binfo->{version,bytes}
> 
good catch, will do.
> > +   struct intel_iommu *iommu;
> > +   struct context_entry *context;
> > +   struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> > +   struct device_domain_info *info;
> > +   struct pci_dev *pdev;
> > +   u8 bus, devfn, host_table_pasid_bits;
> > +   u16 did, sid;
> > +   int ret = 0;
> > +   unsigned long flags;
> > +   u64 ctx_lo;
> > +
> > +   iommu = device_to_iommu(dev, , );
> > +   if (!iommu)
> > +   return -ENODEV;
> > +   /* VT-d spec section 9.4 says pasid table size is encoded
> > as 2^(x+5) */
> > +   host_table_pasid_bits = intel_iommu_get_pts(iommu) +
> > MIN_NR_PASID_BITS;
> > +   if (!pasidt_binfo || pasidt_binfo->pasid_bits >
> > host_table_pasid_bits ||
> > +   pasidt_binfo->pasid_bits < MIN_NR_PASID_BITS) {
> > +   pr_err("Invalid gPASID bits %d, host range %d -
> > %d\n",
> > +   pasidt_binfo->pasid_bits,
> > +   MIN_NR_PASID_BITS, host_table_pasid_bits);
> > +   return -ERANGE;
> > +   }
> > +   if (!ecap_nest(iommu->ecap)) {
> > +   dev_err(dev, "Cannot bind PASID table, no nested
> > translation\n");
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }  
> 
> Gratuitous use of pr_err, some of these look user reachable, for
> instance can vfio know in advance the supported widths or can the user
> trigger that pr_err at will?
Yes, the current IOMMU sysfs for vt-d does show the content of
capability registers so user could know in advance whether the nested
mode is supported. But I think we are in need of some generic interface
to enumerate IOMMU features. Here I am trying to prepare for the worst.
Are you concerned about security if user can trigger that error at
will? Sorry I didn't get the point.

>  Some of these errno values are also
> maybe not as descriptive as they could be.  For instance if the iommu
> doesn't support nesting, that's not a calling argument error, that's
> an unsupported device error, right?
> 
your are right, that is not invalid argument. You mean use ENODEV?

> > +   pdev = to_pci_dev(dev);
> > +   sid = PCI_DEVID(bus, devfn);
> > +   info = dev->archdata.iommu;
> > +
> > +   if (!info) {
> > +   dev_err(dev, "Invalid device domain info\n");
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }
> > +   if (info->pasid_table_bound) {
> > +   dev_err(dev, "Device PASID table already bound\n");
> > +   ret = -EBUSY;
> > +   goto out;
> > +   }
> > +   if (!info->pasid_enabled) {
> > +   ret = pci_enable_pasid(pdev, info->pasid_supported
> > & ~1);
> > +   if (ret) {
> > +   

Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

[Jacob Pan]

On Tue, 17 Apr 2018 13:10:47 -0600
Alex Williamson  wrote:

> On Mon, 16 Apr 2018 14:48:53 -0700
> Jacob Pan  wrote:
> 
> > Add Intel VT-d ops to the generic iommu_bind_pasid_table API
> > functions.
> > 
> > The primary use case is for direct assignment of SVM capable
> > device. Originated from emulated IOMMU in the guest, the request
> > goes through many layers (e.g. VFIO). Upon calling host IOMMU
> > driver, caller passes guest PASID table pointer (GPA) and size.
> > 
> > Device context table entry is modified by Intel IOMMU specific
> > bind_pasid_table function. This will turn on nesting mode and
> > matching translation type.
> > 
> > The unbind operation restores default context mapping.
> > 
> > Signed-off-by: Jacob Pan 
> > Signed-off-by: Liu, Yi L 
> > Signed-off-by: Ashok Raj 
> > ---
> >  drivers/iommu/intel-iommu.c   | 119
> > ++
> > include/linux/dma_remapping.h |   1 + 2 files changed, 120
> > insertions(+)
> > 
> > diff --git a/drivers/iommu/intel-iommu.c
> > b/drivers/iommu/intel-iommu.c index a0f81a4..d8058be 100644
> > --- a/drivers/iommu/intel-iommu.c
> > +++ b/drivers/iommu/intel-iommu.c
> > @@ -2409,6 +2409,7 @@ static struct dmar_domain
> > *dmar_insert_one_dev_info(struct intel_iommu *iommu,
> > info->ats_supported = info->pasid_supported = info->pri_supported =
> > 0; info->ats_enabled = info->pasid_enabled = info->pri_enabled = 0;
> > info->ats_qdep = 0;
> > +   info->pasid_table_bound = 0;
> > info->dev = dev;
> > info->domain = domain;
> > info->iommu = iommu;
> > @@ -5132,6 +5133,7 @@ static void
> > intel_iommu_put_resv_regions(struct device *dev, 
> >  #ifdef CONFIG_INTEL_IOMMU_SVM
> >  #define MAX_NR_PASID_BITS (20)
> > +#define MIN_NR_PASID_BITS (5)
> >  static inline unsigned long intel_iommu_get_pts(struct intel_iommu
> > *iommu) {
> > /*
> > @@ -5258,6 +5260,119 @@ struct intel_iommu
> > *intel_svm_device_to_iommu(struct device *dev) 
> > return iommu;
> >  }
> > +
> > +static int intel_iommu_bind_pasid_table(struct iommu_domain
> > *domain,
> > +   struct device *dev, struct pasid_table_config
> > *pasidt_binfo) +{  
> 
> Never validates pasidt_binfo->{version,bytes}
> 
good catch, will do.
> > +   struct intel_iommu *iommu;
> > +   struct context_entry *context;
> > +   struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> > +   struct device_domain_info *info;
> > +   struct pci_dev *pdev;
> > +   u8 bus, devfn, host_table_pasid_bits;
> > +   u16 did, sid;
> > +   int ret = 0;
> > +   unsigned long flags;
> > +   u64 ctx_lo;
> > +
> > +   iommu = device_to_iommu(dev, , );
> > +   if (!iommu)
> > +   return -ENODEV;
> > +   /* VT-d spec section 9.4 says pasid table size is encoded
> > as 2^(x+5) */
> > +   host_table_pasid_bits = intel_iommu_get_pts(iommu) +
> > MIN_NR_PASID_BITS;
> > +   if (!pasidt_binfo || pasidt_binfo->pasid_bits >
> > host_table_pasid_bits ||
> > +   pasidt_binfo->pasid_bits < MIN_NR_PASID_BITS) {
> > +   pr_err("Invalid gPASID bits %d, host range %d -
> > %d\n",
> > +   pasidt_binfo->pasid_bits,
> > +   MIN_NR_PASID_BITS, host_table_pasid_bits);
> > +   return -ERANGE;
> > +   }
> > +   if (!ecap_nest(iommu->ecap)) {
> > +   dev_err(dev, "Cannot bind PASID table, no nested
> > translation\n");
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }  
> 
> Gratuitous use of pr_err, some of these look user reachable, for
> instance can vfio know in advance the supported widths or can the user
> trigger that pr_err at will?
Yes, the current IOMMU sysfs for vt-d does show the content of
capability registers so user could know in advance whether the nested
mode is supported. But I think we are in need of some generic interface
to enumerate IOMMU features. Here I am trying to prepare for the worst.
Are you concerned about security if user can trigger that error at
will? Sorry I didn't get the point.

>  Some of these errno values are also
> maybe not as descriptive as they could be.  For instance if the iommu
> doesn't support nesting, that's not a calling argument error, that's
> an unsupported device error, right?
> 
your are right, that is not invalid argument. You mean use ENODEV?

> > +   pdev = to_pci_dev(dev);
> > +   sid = PCI_DEVID(bus, devfn);
> > +   info = dev->archdata.iommu;
> > +
> > +   if (!info) {
> > +   dev_err(dev, "Invalid device domain info\n");
> > +   ret = -EINVAL;
> > +   goto out;
> > +   }
> > +   if (info->pasid_table_bound) {
> > +   dev_err(dev, "Device PASID table already bound\n");
> > +   ret = -EBUSY;
> > +   goto out;
> > +   }
> > +   if (!info->pasid_enabled) {
> > +   ret = pci_enable_pasid(pdev, info->pasid_supported
> > & ~1);
> > +   if (ret) {
> > +   dev_err(dev, "Failed to enable PASID\n");
> > +   goto out;
> > +   }
> > +   }
> > +   

Re: [PATCH v3 0/6] scsi: handle special return codes for ABORTED COMMAND

[Martin K. Petersen]

Martin,

> Here is another attempt to handle the special return codes for ABORTED
> COMMAND for certain SCSI devices. Following MKP's recommendation, I've
> created two new BLIST flags, simplifying the code in scsi_error.c
> compared to the previous versions. Rather than using "free" bits, I
> increased the length of blist_flag_t to 64 bit, and used previously
> unused bits. I also added checking for obsolete and unused bits.
>
> For the blist_flag_t size increase, I used sparse to try and avoid
> regressions; that necessitated fixing sparse's errors for the current
> code first.

Much better, thanks for reworking this. Applied to 4.18/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v3 0/6] scsi: handle special return codes for ABORTED COMMAND

[Martin K. Petersen]

Martin,

> Here is another attempt to handle the special return codes for ABORTED
> COMMAND for certain SCSI devices. Following MKP's recommendation, I've
> created two new BLIST flags, simplifying the code in scsi_error.c
> compared to the previous versions. Rather than using "free" bits, I
> increased the length of blist_flag_t to 64 bit, and used previously
> unused bits. I also added checking for obsolete and unused bits.
>
> For the blist_flag_t size increase, I used sparse to try and avoid
> regressions; that necessitated fixing sparse's errors for the current
> code first.

Much better, thanks for reworking this. Applied to 4.18/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [patch V2 0/8] rslib: Cleanup and VLA removal

[Kees Cook]

On Thu, Apr 19, 2018 at 3:04 AM, Thomas Gleixner  wrote:
> Kees tried to get rid of the Variable Length Arrays in the Reed-Solomon
> library by replacing them with fixed length arrays on stack. Though they
> are rather large and Andrew did not fall in love with that solution.
>
> This series addresses that in a different way by splitting the rs control
> structure up, so that each invocation of rs_init() returns a new instance
> in which the decoder buffers are allocated. The polynom tables which build
> the base for the RS codecs are still shareable between the instances to
> avoid large allocations and initializations of the same data over and over.
>
> The usage sites have been audited and fixed up where necessary to
> accomodate the decoder change which forbids parallel decoder invocation for
> a particular rs control instance to prevent buffer corruption.
>
> While at it the patch set tidies up the code and converts the related files
> over to use SPDX license identifiers.
>
> Changes since V1:
>
>Simplify error path in the diskonchip code and use the proper
>function to free the decoder.
>
> As this spawns multiple subsystems it should either go through Andrews tree
> or Kees can route it with his other hardening stuff.

I can start collecting ignored VLA patches. I haven't done that yet as
most maintainers have been taking them. There are only a handful
unapplied. Should I start the tree with rslib? :)

Either way:

Reviewed-by: Kees Cook 

-Kees

-- 
Kees Cook
Pixel Security

Re: [patch V2 0/8] rslib: Cleanup and VLA removal

[Kees Cook]

On Thu, Apr 19, 2018 at 3:04 AM, Thomas Gleixner  wrote:
> Kees tried to get rid of the Variable Length Arrays in the Reed-Solomon
> library by replacing them with fixed length arrays on stack. Though they
> are rather large and Andrew did not fall in love with that solution.
>
> This series addresses that in a different way by splitting the rs control
> structure up, so that each invocation of rs_init() returns a new instance
> in which the decoder buffers are allocated. The polynom tables which build
> the base for the RS codecs are still shareable between the instances to
> avoid large allocations and initializations of the same data over and over.
>
> The usage sites have been audited and fixed up where necessary to
> accomodate the decoder change which forbids parallel decoder invocation for
> a particular rs control instance to prevent buffer corruption.
>
> While at it the patch set tidies up the code and converts the related files
> over to use SPDX license identifiers.
>
> Changes since V1:
>
>Simplify error path in the diskonchip code and use the proper
>function to free the decoder.
>
> As this spawns multiple subsystems it should either go through Andrews tree
> or Kees can route it with his other hardening stuff.

I can start collecting ignored VLA patches. I haven't done that yet as
most maintainers have been taking them. There are only a handful
unapplied. Should I start the tree with rslib? :)

Either way:

Reviewed-by: Kees Cook 

-Kees

-- 
Kees Cook
Pixel Security

[PATCH v4] mtd: spi-nor: clear Winbond Extended Address Reg on switch to 3-byte addressing.

[NeilBrown]

Winbond spi-nor flash 32MB and larger have an 'Extended Address
Register' as one option for addressing beyond 16MB (Macronix
has the same concept, Spansion has EXTADD bits in the Bank Address
Register).

According to section
   8.2.7 Write Extended Address Register (C5h)

of the Winbond W25Q256FV data sheet (256M-BIT SPI flash)

   The Extended Address Register is only effective when the device is
   in the 3-Byte Address Mode.  When the device operates in the 4-Byte
   Address Mode (ADS=1), any command with address input of A31-A24
   will replace the Extended Address Register values. It is
   recommended to check and update the Extended Address Register if
   necessary when the device is switched from 4-Byte to 3-Byte Address
   Mode.

So the documentation suggests clearing the EAR after switching to
3-byte mode.  Experimentation shows that the EAR is *always* one after
the switch to 3-byte mode, so clearing the EAR is mandatory at
shutdown for a subsequent 3-byte-addressed reboot to work.

Note that some SOCs (e.g. MT7621) do not assert a reset line at normal
reboot, so we cannot rely on hardware reset.  The MT7621 does assert a
reset line at watchdog-reset.

Acked-by: Marek Vasut 
Signed-off-by: NeilBrown 
---

Changes since v3:
 Removed Fixes/stable tags. Added Acked-by from Marek.
Changes sinc3 v2:
  Fixed comment style.


 drivers/mtd/spi-nor/spi-nor.c | 14 ++
 include/linux/mtd/spi-nor.h   |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 5bfa36e95f35..42ae9a1529bb 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -284,6 +284,20 @@ static inline int set_4byte(struct spi_nor *nor, const 
struct flash_info *info,
if (need_wren)
write_disable(nor);
 
+   if (!status && !enable &&
+   JEDEC_MFR(info) == SNOR_MFR_WINBOND) {
+   /*
+* On Winbond W25Q256FV, leaving 4byte mode causes
+* the Extended Address Register to be set to 1, so all
+* 3-byte-address reads come from the second 16M.
+* We must clear the register to enable normal behavior.
+*/
+   write_enable(nor);
+   nor->cmd_buf[0] = 0;
+   nor->write_reg(nor, SPINOR_OP_WREAR, nor->cmd_buf, 1);
+   write_disable(nor);
+   }
+
return status;
default:
/* Spansion style */
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index de36969eb359..e60da0d34cc1 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -62,6 +62,8 @@
 #define SPINOR_OP_RDCR 0x35/* Read configuration register */
 #define SPINOR_OP_RDFSR0x70/* Read flag status register */
 #define SPINOR_OP_CLFSR0x50/* Clear flag status register */
+#define SPINOR_OP_RDEAR0xc8/* Read Extended Address 
Register */
+#define SPINOR_OP_WREAR0xc5/* Write Extended Address 
Register */
 
 /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
 #define SPINOR_OP_READ_4B  0x13/* Read data bytes (low frequency) */
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

[PATCH v4] mtd: spi-nor: clear Winbond Extended Address Reg on switch to 3-byte addressing.

[NeilBrown]

Winbond spi-nor flash 32MB and larger have an 'Extended Address
Register' as one option for addressing beyond 16MB (Macronix
has the same concept, Spansion has EXTADD bits in the Bank Address
Register).

According to section
   8.2.7 Write Extended Address Register (C5h)

of the Winbond W25Q256FV data sheet (256M-BIT SPI flash)

   The Extended Address Register is only effective when the device is
   in the 3-Byte Address Mode.  When the device operates in the 4-Byte
   Address Mode (ADS=1), any command with address input of A31-A24
   will replace the Extended Address Register values. It is
   recommended to check and update the Extended Address Register if
   necessary when the device is switched from 4-Byte to 3-Byte Address
   Mode.

So the documentation suggests clearing the EAR after switching to
3-byte mode.  Experimentation shows that the EAR is *always* one after
the switch to 3-byte mode, so clearing the EAR is mandatory at
shutdown for a subsequent 3-byte-addressed reboot to work.

Note that some SOCs (e.g. MT7621) do not assert a reset line at normal
reboot, so we cannot rely on hardware reset.  The MT7621 does assert a
reset line at watchdog-reset.

Acked-by: Marek Vasut 
Signed-off-by: NeilBrown 
---

Changes since v3:
 Removed Fixes/stable tags. Added Acked-by from Marek.
Changes sinc3 v2:
  Fixed comment style.


 drivers/mtd/spi-nor/spi-nor.c | 14 ++
 include/linux/mtd/spi-nor.h   |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 5bfa36e95f35..42ae9a1529bb 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -284,6 +284,20 @@ static inline int set_4byte(struct spi_nor *nor, const 
struct flash_info *info,
if (need_wren)
write_disable(nor);
 
+   if (!status && !enable &&
+   JEDEC_MFR(info) == SNOR_MFR_WINBOND) {
+   /*
+* On Winbond W25Q256FV, leaving 4byte mode causes
+* the Extended Address Register to be set to 1, so all
+* 3-byte-address reads come from the second 16M.
+* We must clear the register to enable normal behavior.
+*/
+   write_enable(nor);
+   nor->cmd_buf[0] = 0;
+   nor->write_reg(nor, SPINOR_OP_WREAR, nor->cmd_buf, 1);
+   write_disable(nor);
+   }
+
return status;
default:
/* Spansion style */
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index de36969eb359..e60da0d34cc1 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -62,6 +62,8 @@
 #define SPINOR_OP_RDCR 0x35/* Read configuration register */
 #define SPINOR_OP_RDFSR0x70/* Read flag status register */
 #define SPINOR_OP_CLFSR0x50/* Clear flag status register */
+#define SPINOR_OP_RDEAR0xc8/* Read Extended Address 
Register */
+#define SPINOR_OP_WREAR0xc5/* Write Extended Address 
Register */
 
 /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
 #define SPINOR_OP_READ_4B  0x13/* Read data bytes (low frequency) */
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

Re: Representative Needed.

[PPMC OFFSHORE]

Good day,

  I am seeking your concept with great gratitude to present you as a 
representative to carry out business transactions with a reasonable share upon 
your interest and cooperation to work with us in trust. If interested please 
get back.

Regards
Kingsley

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Representative Needed.

[PPMC OFFSHORE]

Good day,

  I am seeking your concept with great gratitude to present you as a 
representative to carry out business transactions with a reasonable share upon 
your interest and cooperation to work with us in trust. If interested please 
get back.

Regards
Kingsley

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus