date:20160319

[PATCH v2] lightnvm: divide global reverse translation map into per lun

2016-03-19 Thread Wenwei Tao

Divide the target's global reverse translation map into per lun,
to prepare support for the non-continuous lun target creation.

Signed-off-by: Wenwei Tao 
---

Changes since v1
-fix merge/rebase mistake in rrpc_block_map_update().
-remove variables poffset and lun_offset in rrpc structure
since no one use them now.

 drivers/lightnvm/rrpc.c  | 181 +++
 drivers/lightnvm/rrpc.h  |   9 ++-
 include/linux/lightnvm.h |   1 +
 3 files changed, 111 insertions(+), 80 deletions(-)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 3ab6495..88e2ce5 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -23,28 +23,35 @@ static int rrpc_submit_io(struct rrpc *rrpc, struct bio 
*bio,
struct nvm_rq *rqd, unsigned long flags);
 
 #define rrpc_for_each_lun(rrpc, rlun, i) \
-   for ((i) = 0, rlun = &(rrpc)->luns[0]; \
-   (i) < (rrpc)->nr_luns; (i)++, rlun = &(rrpc)->luns[(i)])
+   for ((i) = 0, rlun = &(rrpc)->luns[0]; \
+   (i) < (rrpc)->nr_luns; (i)++, rlun = &(rrpc)->luns[(i)])
+
+static inline u64 lun_poffset(struct nvm_lun *lun, struct nvm_dev *dev)
+{
+   return lun->id * dev->sec_per_lun;
+}
 
 static void rrpc_page_invalidate(struct rrpc *rrpc, struct rrpc_addr *a)
 {
struct rrpc_block *rblk = a->rblk;
-   unsigned int pg_offset;
+   struct rrpc_lun *rlun = rblk->rlun;
+   u64 pg_offset;
 
-   lockdep_assert_held(>rev_lock);
+   lockdep_assert_held(>rev_lock);
 
if (a->addr == ADDR_EMPTY || !rblk)
return;
 
spin_lock(>lock);
 
-   div_u64_rem(a->addr, rrpc->dev->sec_per_blk, _offset);
+   div_u64_rem(a->addr, rrpc->dev->sec_per_blk, (u32 *)_offset);
WARN_ON(test_and_set_bit(pg_offset, rblk->invalid_pages));
rblk->nr_invalid_pages++;
 
spin_unlock(>lock);
 
-   rrpc->rev_trans_map[a->addr - rrpc->poffset].addr = ADDR_EMPTY;
+   pg_offset = lun_poffset(rlun->parent, rrpc->dev);
+   rlun->rev_trans_map[a->addr - pg_offset].addr = ADDR_EMPTY;
 }
 
 static void rrpc_invalidate_range(struct rrpc *rrpc, sector_t slba,
@@ -52,14 +59,15 @@ static void rrpc_invalidate_range(struct rrpc *rrpc, 
sector_t slba,
 {
sector_t i;
 
-   spin_lock(>rev_lock);
for (i = slba; i < slba + len; i++) {
struct rrpc_addr *gp = >trans_map[i];
+   struct rrpc_lun *rlun = gp->rblk->rlun;
 
+   spin_lock(>rev_lock);
rrpc_page_invalidate(rrpc, gp);
+   spin_unlock(>rev_lock);
gp->rblk = NULL;
}
-   spin_unlock(>rev_lock);
 }
 
 static struct nvm_rq *rrpc_inflight_laddr_acquire(struct rrpc *rrpc,
@@ -116,15 +124,6 @@ static int block_is_full(struct rrpc *rrpc, struct 
rrpc_block *rblk)
return (rblk->next_page == rrpc->dev->sec_per_blk);
 }
 
-/* Calculate relative addr for the given block, considering instantiated LUNs 
*/
-static u64 block_to_rel_addr(struct rrpc *rrpc, struct rrpc_block *rblk)
-{
-   struct nvm_block *blk = rblk->parent;
-   int lun_blk = blk->id % (rrpc->dev->blks_per_lun * rrpc->nr_luns);
-
-   return lun_blk * rrpc->dev->sec_per_blk;
-}
-
 /* Calculate global addr for the given block */
 static u64 block_to_addr(struct rrpc *rrpc, struct rrpc_block *rblk)
 {
@@ -291,13 +290,14 @@ static void rrpc_end_sync_bio(struct bio *bio)
 static int rrpc_move_valid_pages(struct rrpc *rrpc, struct rrpc_block *rblk)
 {
struct request_queue *q = rrpc->dev->q;
+   struct rrpc_lun *rlun = rblk->rlun;
struct rrpc_rev_addr *rev;
struct nvm_rq *rqd;
struct bio *bio;
struct page *page;
int slot;
int nr_sec_per_blk = rrpc->dev->sec_per_blk;
-   u64 phys_addr;
+   u64 phys_addr, poffset;
DECLARE_COMPLETION_ONSTACK(wait);
 
if (bitmap_full(rblk->invalid_pages, nr_sec_per_blk))
@@ -315,6 +315,7 @@ static int rrpc_move_valid_pages(struct rrpc *rrpc, struct 
rrpc_block *rblk)
return -ENOMEM;
}
 
+   poffset = lun_poffset(rlun->parent, rrpc->dev);
while ((slot = find_first_zero_bit(rblk->invalid_pages,
nr_sec_per_blk)) < nr_sec_per_blk) {
 
@@ -322,23 +323,23 @@ static int rrpc_move_valid_pages(struct rrpc *rrpc, 
struct rrpc_block *rblk)
phys_addr = rblk->parent->id * nr_sec_per_blk + slot;
 
 try:
-   spin_lock(>rev_lock);
+   spin_lock(>rev_lock);
/* Get logical address from physical to logical table */
-   rev = >rev_trans_map[phys_addr - rrpc->poffset];
+   rev = >rev_trans_map[phys_addr - poffset];
/* already updated by previous regular write */
if (rev->addr == ADDR_EMPTY) {
-   spin_unlock(>rev_lock);
+

[PATCH v2] lightnvm: divide global reverse translation map into per lun

2016-03-19 Thread Wenwei Tao

Divide the target's global reverse translation map into per lun,
to prepare support for the non-continuous lun target creation.

Signed-off-by: Wenwei Tao 
---

Changes since v1
-fix merge/rebase mistake in rrpc_block_map_update().
-remove variables poffset and lun_offset in rrpc structure
since no one use them now.

 drivers/lightnvm/rrpc.c  | 181 +++
 drivers/lightnvm/rrpc.h  |   9 ++-
 include/linux/lightnvm.h |   1 +
 3 files changed, 111 insertions(+), 80 deletions(-)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 3ab6495..88e2ce5 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -23,28 +23,35 @@ static int rrpc_submit_io(struct rrpc *rrpc, struct bio 
*bio,
struct nvm_rq *rqd, unsigned long flags);
 
 #define rrpc_for_each_lun(rrpc, rlun, i) \
-   for ((i) = 0, rlun = &(rrpc)->luns[0]; \
-   (i) < (rrpc)->nr_luns; (i)++, rlun = &(rrpc)->luns[(i)])
+   for ((i) = 0, rlun = &(rrpc)->luns[0]; \
+   (i) < (rrpc)->nr_luns; (i)++, rlun = &(rrpc)->luns[(i)])
+
+static inline u64 lun_poffset(struct nvm_lun *lun, struct nvm_dev *dev)
+{
+   return lun->id * dev->sec_per_lun;
+}
 
 static void rrpc_page_invalidate(struct rrpc *rrpc, struct rrpc_addr *a)
 {
struct rrpc_block *rblk = a->rblk;
-   unsigned int pg_offset;
+   struct rrpc_lun *rlun = rblk->rlun;
+   u64 pg_offset;
 
-   lockdep_assert_held(>rev_lock);
+   lockdep_assert_held(>rev_lock);
 
if (a->addr == ADDR_EMPTY || !rblk)
return;
 
spin_lock(>lock);
 
-   div_u64_rem(a->addr, rrpc->dev->sec_per_blk, _offset);
+   div_u64_rem(a->addr, rrpc->dev->sec_per_blk, (u32 *)_offset);
WARN_ON(test_and_set_bit(pg_offset, rblk->invalid_pages));
rblk->nr_invalid_pages++;
 
spin_unlock(>lock);
 
-   rrpc->rev_trans_map[a->addr - rrpc->poffset].addr = ADDR_EMPTY;
+   pg_offset = lun_poffset(rlun->parent, rrpc->dev);
+   rlun->rev_trans_map[a->addr - pg_offset].addr = ADDR_EMPTY;
 }
 
 static void rrpc_invalidate_range(struct rrpc *rrpc, sector_t slba,
@@ -52,14 +59,15 @@ static void rrpc_invalidate_range(struct rrpc *rrpc, 
sector_t slba,
 {
sector_t i;
 
-   spin_lock(>rev_lock);
for (i = slba; i < slba + len; i++) {
struct rrpc_addr *gp = >trans_map[i];
+   struct rrpc_lun *rlun = gp->rblk->rlun;
 
+   spin_lock(>rev_lock);
rrpc_page_invalidate(rrpc, gp);
+   spin_unlock(>rev_lock);
gp->rblk = NULL;
}
-   spin_unlock(>rev_lock);
 }
 
 static struct nvm_rq *rrpc_inflight_laddr_acquire(struct rrpc *rrpc,
@@ -116,15 +124,6 @@ static int block_is_full(struct rrpc *rrpc, struct 
rrpc_block *rblk)
return (rblk->next_page == rrpc->dev->sec_per_blk);
 }
 
-/* Calculate relative addr for the given block, considering instantiated LUNs 
*/
-static u64 block_to_rel_addr(struct rrpc *rrpc, struct rrpc_block *rblk)
-{
-   struct nvm_block *blk = rblk->parent;
-   int lun_blk = blk->id % (rrpc->dev->blks_per_lun * rrpc->nr_luns);
-
-   return lun_blk * rrpc->dev->sec_per_blk;
-}
-
 /* Calculate global addr for the given block */
 static u64 block_to_addr(struct rrpc *rrpc, struct rrpc_block *rblk)
 {
@@ -291,13 +290,14 @@ static void rrpc_end_sync_bio(struct bio *bio)
 static int rrpc_move_valid_pages(struct rrpc *rrpc, struct rrpc_block *rblk)
 {
struct request_queue *q = rrpc->dev->q;
+   struct rrpc_lun *rlun = rblk->rlun;
struct rrpc_rev_addr *rev;
struct nvm_rq *rqd;
struct bio *bio;
struct page *page;
int slot;
int nr_sec_per_blk = rrpc->dev->sec_per_blk;
-   u64 phys_addr;
+   u64 phys_addr, poffset;
DECLARE_COMPLETION_ONSTACK(wait);
 
if (bitmap_full(rblk->invalid_pages, nr_sec_per_blk))
@@ -315,6 +315,7 @@ static int rrpc_move_valid_pages(struct rrpc *rrpc, struct 
rrpc_block *rblk)
return -ENOMEM;
}
 
+   poffset = lun_poffset(rlun->parent, rrpc->dev);
while ((slot = find_first_zero_bit(rblk->invalid_pages,
nr_sec_per_blk)) < nr_sec_per_blk) {
 
@@ -322,23 +323,23 @@ static int rrpc_move_valid_pages(struct rrpc *rrpc, 
struct rrpc_block *rblk)
phys_addr = rblk->parent->id * nr_sec_per_blk + slot;
 
 try:
-   spin_lock(>rev_lock);
+   spin_lock(>rev_lock);
/* Get logical address from physical to logical table */
-   rev = >rev_trans_map[phys_addr - rrpc->poffset];
+   rev = >rev_trans_map[phys_addr - poffset];
/* already updated by previous regular write */
if (rev->addr == ADDR_EMPTY) {
-   spin_unlock(>rev_lock);
+   spin_unlock(>rev_lock);

arch/xtensa/include/asm/initialize_mmu.h:55: Error: invalid register 'atomctl' for 'wsr' instruction

2016-03-19 Thread kbuild test robot

Hi Max,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1e75a9f34a5ed5902707fb74b468356c55142b71
commit: ca55b2fef3a9373fcfc30f82fd26bc7fccbda732 xtensa: add de212 core variant
date:   5 months ago
config: xtensa-nommu_kc705_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ca55b2fef3a9373fcfc30f82fd26bc7fccbda732
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   arch/xtensa/include/asm/initialize_mmu.h: Assembler messages:
>> arch/xtensa/include/asm/initialize_mmu.h:55: Error: invalid register 
>> 'atomctl' for 'wsr' instruction

vim +55 arch/xtensa/include/asm/initialize_mmu.h

6cb97111 Baruch Siach 2013-12-29  39  
c622b29d Max Filippov 2012-11-19  40  #ifdef __ASSEMBLY__
c622b29d Max Filippov 2012-11-19  41  
c622b29d Max Filippov 2012-11-19  42  #define XTENSA_HWVERSION_RC_2009_0 23
c622b29d Max Filippov 2012-11-19  43  
c622b29d Max Filippov 2012-11-19  44.macro  initialize_mmu
c622b29d Max Filippov 2012-11-19  45  
c622b29d Max Filippov 2012-11-19  46  #if XCHAL_HAVE_S32C1I && 
(XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  47  /*
c622b29d Max Filippov 2012-11-19  48   * We Have Atomic Operation Control 
(ATOMCTL) Register; Initialize it.
c622b29d Max Filippov 2012-11-19  49   * For details see 
Documentation/xtensa/atomctl.txt
c622b29d Max Filippov 2012-11-19  50   */
c622b29d Max Filippov 2012-11-19  51  #if XCHAL_DCACHE_IS_COHERENT
c622b29d Max Filippov 2012-11-19  52movia3, 0x25/* For SMP/MX 
-- internal for writeback,
c622b29d Max Filippov 2012-11-19  53 * RCW otherwise
c622b29d Max Filippov 2012-11-19  54 */
c622b29d Max Filippov 2012-11-19 @55  #else
c622b29d Max Filippov 2012-11-19  56movia3, 0x29/* non-MX -- 
Most cores use Std Memory
c622b29d Max Filippov 2012-11-19  57 * Controlers 
which usually can't use RCW
c622b29d Max Filippov 2012-11-19  58 */
c622b29d Max Filippov 2012-11-19  59  #endif
c622b29d Max Filippov 2012-11-19  60wsr a3, atomctl
c622b29d Max Filippov 2012-11-19  61  #endif  /* XCHAL_HAVE_S32C1I &&
c622b29d Max Filippov 2012-11-19  62 * (XCHAL_HW_MIN_VERSION >= 
XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  63 */

:: The code at line 55 was first introduced by commit
:: c622b29d1f38021411965b7e0170ab01b257 xtensa: initialize atomctl SR

:: TO: Max Filippov 
:: CC: Chris Zankel 

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


.config.gz
Description: Binary data

arch/xtensa/include/asm/initialize_mmu.h:55: Error: invalid register 'atomctl' for 'wsr' instruction

2016-03-19 Thread kbuild test robot

Hi Max,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1e75a9f34a5ed5902707fb74b468356c55142b71
commit: ca55b2fef3a9373fcfc30f82fd26bc7fccbda732 xtensa: add de212 core variant
date:   5 months ago
config: xtensa-nommu_kc705_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ca55b2fef3a9373fcfc30f82fd26bc7fccbda732
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   arch/xtensa/include/asm/initialize_mmu.h: Assembler messages:
>> arch/xtensa/include/asm/initialize_mmu.h:55: Error: invalid register 
>> 'atomctl' for 'wsr' instruction

vim +55 arch/xtensa/include/asm/initialize_mmu.h

6cb97111 Baruch Siach 2013-12-29  39  
c622b29d Max Filippov 2012-11-19  40  #ifdef __ASSEMBLY__
c622b29d Max Filippov 2012-11-19  41  
c622b29d Max Filippov 2012-11-19  42  #define XTENSA_HWVERSION_RC_2009_0 23
c622b29d Max Filippov 2012-11-19  43  
c622b29d Max Filippov 2012-11-19  44.macro  initialize_mmu
c622b29d Max Filippov 2012-11-19  45  
c622b29d Max Filippov 2012-11-19  46  #if XCHAL_HAVE_S32C1I && 
(XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  47  /*
c622b29d Max Filippov 2012-11-19  48   * We Have Atomic Operation Control 
(ATOMCTL) Register; Initialize it.
c622b29d Max Filippov 2012-11-19  49   * For details see 
Documentation/xtensa/atomctl.txt
c622b29d Max Filippov 2012-11-19  50   */
c622b29d Max Filippov 2012-11-19  51  #if XCHAL_DCACHE_IS_COHERENT
c622b29d Max Filippov 2012-11-19  52movia3, 0x25/* For SMP/MX 
-- internal for writeback,
c622b29d Max Filippov 2012-11-19  53 * RCW otherwise
c622b29d Max Filippov 2012-11-19  54 */
c622b29d Max Filippov 2012-11-19 @55  #else
c622b29d Max Filippov 2012-11-19  56movia3, 0x29/* non-MX -- 
Most cores use Std Memory
c622b29d Max Filippov 2012-11-19  57 * Controlers 
which usually can't use RCW
c622b29d Max Filippov 2012-11-19  58 */
c622b29d Max Filippov 2012-11-19  59  #endif
c622b29d Max Filippov 2012-11-19  60wsr a3, atomctl
c622b29d Max Filippov 2012-11-19  61  #endif  /* XCHAL_HAVE_S32C1I &&
c622b29d Max Filippov 2012-11-19  62 * (XCHAL_HW_MIN_VERSION >= 
XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  63 */

:: The code at line 55 was first introduced by commit
:: c622b29d1f38021411965b7e0170ab01b257 xtensa: initialize atomctl SR

:: TO: Max Filippov 
:: CC: Chris Zankel 

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


.config.gz
Description: Binary data

[PATCH] Coccinelle: setup_timer: Add space in front of parentheses

2016-03-19 Thread Vaishali Thakkar

Add space in front of the offending parentheses to silent the
parse error for older Coccinelle versions. This makes the rule
usable with all Coccinelle versions.

Reported-by: Nishanth Menon 
Signed-off-by: Vaishali Thakkar 
---
 scripts/coccinelle/api/setup_timer.cocci | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/coccinelle/api/setup_timer.cocci 
b/scripts/coccinelle/api/setup_timer.cocci
index 8ee0ac3..eb6bd9e 100644
--- a/scripts/coccinelle/api/setup_timer.cocci
+++ b/scripts/coccinelle/api/setup_timer.cocci
@@ -106,7 +106,7 @@ position j0, j1, j2;
 @match_function_and_data_after_init_timer_context
 depends on !patch &&
 !match_immediate_function_data_after_init_timer_context &&
-(context || org || report)@
+ (context || org || report)@
 expression a, b, e1, e2, e3, e4, e5;
 position j0, j1, j2;
 @@
@@ -127,7 +127,7 @@ position j0, j1, j2;
 @r3_context depends on !patch &&
 !match_immediate_function_data_after_init_timer_context &&
 !match_function_and_data_after_init_timer_context &&
-(context || org || report)@
+ (context || org || report)@
 expression c, e6, e7;
 position r1.p;
 position j0, j1;
-- 
2.1.4

[PATCH] Coccinelle: setup_timer: Add space in front of parentheses

2016-03-19 Thread Vaishali Thakkar

Add space in front of the offending parentheses to silent the
parse error for older Coccinelle versions. This makes the rule
usable with all Coccinelle versions.

Reported-by: Nishanth Menon 
Signed-off-by: Vaishali Thakkar 
---
 scripts/coccinelle/api/setup_timer.cocci | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/coccinelle/api/setup_timer.cocci 
b/scripts/coccinelle/api/setup_timer.cocci
index 8ee0ac3..eb6bd9e 100644
--- a/scripts/coccinelle/api/setup_timer.cocci
+++ b/scripts/coccinelle/api/setup_timer.cocci
@@ -106,7 +106,7 @@ position j0, j1, j2;
 @match_function_and_data_after_init_timer_context
 depends on !patch &&
 !match_immediate_function_data_after_init_timer_context &&
-(context || org || report)@
+ (context || org || report)@
 expression a, b, e1, e2, e3, e4, e5;
 position j0, j1, j2;
 @@
@@ -127,7 +127,7 @@ position j0, j1, j2;
 @r3_context depends on !patch &&
 !match_immediate_function_data_after_init_timer_context &&
 !match_function_and_data_after_init_timer_context &&
-(context || org || report)@
+ (context || org || report)@
 expression c, e6, e7;
 position r1.p;
 position j0, j1;
-- 
2.1.4

Re: Nokia N900 - audio TPA6130A2 problems

2016-03-19 Thread Sebastian Reichel

Hi,

On Sat, Mar 19, 2016 at 10:49:57AM +0200, Ivaylo Dimitrov wrote:
> On 18.03.2016 17:04, Sebastian Reichel wrote:
> >On Fri, Mar 18, 2016 at 03:45:26PM +0200, Ivaylo Dimitrov wrote:
> >>On 18.03.2016 15:36, Sebastian Reichel wrote:
> >>Regulator is V28_A, which is always-on, so it is enabled no matter what
> >>probe does. Anyway, I added a various delays after regulator_enable(), to no
> >>success.
> 
> I guess we're getting closer - I put some printks in various functions in
> the twl-regulator.c, here is the result:
> 
> on power-up:
> 
> [2.378601] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0008
> [2.384948] twl4030reg_enable VMMC2 grp 0x0020
> [2.408416] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0008
> [7.196685] twl4030reg_is_enabled VMMC2 state 0x002e
> [7.202819] twl4030reg_is_enabled VMMC2 state 0x002e
> [7.209777] twl4030reg_is_enabled VMMC2 state 0x002e
> [7.215728] twl4030reg_is_enabled VMMC2 state 0x002e
> [7.223205] twl4030reg_is_enabled VMMC2 state 0x002e

Ok, so normal power up results in running VMMC2 (always-on works),
but voltage is not configured correctly. 2.6V is default according
to the TRM. I think this is a "bug" in the regulator framework. It
should setup the minimum allowed voltage before enabling the
always-on regulator.

In case of the tpa6130a2/tpa6140a2 driver it may also be nice to add
something like this to the driver (Vdd may be between 2.5V and 5.5V
according to both datasheets):

if (regulator_can_change_voltage(data->supply))
regulator_set_voltage(data->supply, 250, 550);

> after restart from stock kernel:
> 
> [2.388610] twl4030ldo_get_voltage_sel VMMC2 vsel 0x000a
> [2.394958] twl4030reg_enable VMMC2 grp 0x0028

I had a quick glance at this. I think stock kernel put VMMC2
into sleep mode. Mainline kernel does not expect sleep mode
being set and does not disable it.

> [2.418426] twl4030ldo_get_voltage_sel VMMC2 vsel 0x000a
> [7.186645] twl4030reg_is_enabled VMMC2 state 0x0020
> [7.192718] twl4030reg_is_enabled VMMC2 state 0x0020
> [7.199615] twl4030reg_is_enabled VMMC2 state 0x0020
> [7.205535] twl4030reg_is_enabled VMMC2 state 0x0020
> [7.212951] twl4030reg_is_enabled VMMC2 state 0x0020
> 
> I don't see twl4030ldo_set_voltage_sel() for VMMC2(V28_A) regulator, though
> there are calls for VMMC1 and VAUX3.

I guess that's because the voltage is only configured if at least
one regulator consumer requests anything specific.

> So, it seems to me that V28_A is not enabled or correctly set-up
> and all devices connected to it does not function. And it looks
> like even after power-on VMMC2 is not correctly set-up - it is
> supposed to have voltage of 2.85V (10) but kernel leaves it to
> 2.60V (8). However my twl-fu ends here so any help is appreciated.

So in case of reboot from stock kernel voltage is already configured
to 2.8V, but it does not work, because of the sleep mode.

-- Sebastian


signature.asc
Description: PGP signature

Re: Nokia N900 - audio TPA6130A2 problems

2016-03-19 Thread Sebastian Reichel

Hi,

On Sat, Mar 19, 2016 at 10:49:57AM +0200, Ivaylo Dimitrov wrote:
> On 18.03.2016 17:04, Sebastian Reichel wrote:
> >On Fri, Mar 18, 2016 at 03:45:26PM +0200, Ivaylo Dimitrov wrote:
> >>On 18.03.2016 15:36, Sebastian Reichel wrote:
> >>Regulator is V28_A, which is always-on, so it is enabled no matter what
> >>probe does. Anyway, I added a various delays after regulator_enable(), to no
> >>success.
> 
> I guess we're getting closer - I put some printks in various functions in
> the twl-regulator.c, here is the result:
> 
> on power-up:
> 
> [2.378601] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0008
> [2.384948] twl4030reg_enable VMMC2 grp 0x0020
> [2.408416] twl4030ldo_get_voltage_sel VMMC2 vsel 0x0008
> [7.196685] twl4030reg_is_enabled VMMC2 state 0x002e
> [7.202819] twl4030reg_is_enabled VMMC2 state 0x002e
> [7.209777] twl4030reg_is_enabled VMMC2 state 0x002e
> [7.215728] twl4030reg_is_enabled VMMC2 state 0x002e
> [7.223205] twl4030reg_is_enabled VMMC2 state 0x002e

Ok, so normal power up results in running VMMC2 (always-on works),
but voltage is not configured correctly. 2.6V is default according
to the TRM. I think this is a "bug" in the regulator framework. It
should setup the minimum allowed voltage before enabling the
always-on regulator.

In case of the tpa6130a2/tpa6140a2 driver it may also be nice to add
something like this to the driver (Vdd may be between 2.5V and 5.5V
according to both datasheets):

if (regulator_can_change_voltage(data->supply))
regulator_set_voltage(data->supply, 250, 550);

> after restart from stock kernel:
> 
> [2.388610] twl4030ldo_get_voltage_sel VMMC2 vsel 0x000a
> [2.394958] twl4030reg_enable VMMC2 grp 0x0028

I had a quick glance at this. I think stock kernel put VMMC2
into sleep mode. Mainline kernel does not expect sleep mode
being set and does not disable it.

> [2.418426] twl4030ldo_get_voltage_sel VMMC2 vsel 0x000a
> [7.186645] twl4030reg_is_enabled VMMC2 state 0x0020
> [7.192718] twl4030reg_is_enabled VMMC2 state 0x0020
> [7.199615] twl4030reg_is_enabled VMMC2 state 0x0020
> [7.205535] twl4030reg_is_enabled VMMC2 state 0x0020
> [7.212951] twl4030reg_is_enabled VMMC2 state 0x0020
> 
> I don't see twl4030ldo_set_voltage_sel() for VMMC2(V28_A) regulator, though
> there are calls for VMMC1 and VAUX3.

I guess that's because the voltage is only configured if at least
one regulator consumer requests anything specific.

> So, it seems to me that V28_A is not enabled or correctly set-up
> and all devices connected to it does not function. And it looks
> like even after power-on VMMC2 is not correctly set-up - it is
> supposed to have voltage of 2.85V (10) but kernel leaves it to
> 2.60V (8). However my twl-fu ends here so any help is appreciated.

So in case of reboot from stock kernel voltage is already configured
to 2.8V, but it does not work, because of the sleep mode.

-- Sebastian


signature.asc
Description: PGP signature

[PATCH v20 21/23] vfs: Add richacl permission checking

2016-03-19 Thread Andreas Gruenbacher

Hook the richacl permission checking function into the vfs.

Signed-off-by: Andreas Gruenbacher 
---
 fs/namei.c | 51 +--
 fs/posix_acl.c |  6 +++---
 2 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 28707ae..b55cee6 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "internal.h"
@@ -255,7 +256,40 @@ void putname(struct filename *name)
__putname(name);
 }
 
-static int check_acl(struct inode *inode, int mask)
+static int check_richacl(struct inode *inode, int mask)
+{
+#ifdef CONFIG_FS_RICHACL
+   struct richacl *acl;
+
+   if (mask & MAY_NOT_BLOCK) {
+   acl = get_cached_richacl_rcu(inode);
+   if (!acl)
+   goto no_acl;
+   /* no ->get_richacl() calls in RCU mode... */
+   if (acl == ACL_NOT_CACHED)
+   return -ECHILD;
+   return richacl_permission(inode, acl, mask & ~MAY_NOT_BLOCK);
+   }
+
+   acl = get_richacl(inode);
+   if (IS_ERR(acl))
+   return PTR_ERR(acl);
+   if (acl) {
+   int error = richacl_permission(inode, acl, mask);
+   richacl_put(acl);
+   return error;
+   }
+no_acl:
+#endif
+   if (mask & (MAY_DELETE_SELF | MAY_TAKE_OWNERSHIP |
+   MAY_CHMOD | MAY_SET_TIMES)) {
+   /* File permission bits cannot grant this. */
+   return -EACCES;
+   }
+   return -EAGAIN;
+}
+
+static int check_posix_acl(struct inode *inode, int mask)
 {
 #ifdef CONFIG_FS_POSIX_ACL
struct posix_acl *acl;
@@ -290,11 +324,24 @@ static int acl_permission_check(struct inode *inode, int 
mask)
 {
unsigned int mode = inode->i_mode;
 
+   /*
+* With POSIX ACLs, the (mode & S_IRWXU) bits exactly match the owner
+* permissions, and we can skip checking posix acls for the owner.
+* With richacls, the owner may be granted fewer permissions than the
+* mode bits seem to suggest (for example, append but not write), and
+* we always need to check the richacl.
+*/
+
+   if (IS_RICHACL(inode)) {
+   int error = check_richacl(inode, mask);
+   if (error != -EAGAIN)
+   return error;
+   }
if (likely(uid_eq(current_fsuid(), inode->i_uid)))
mode >>= 6;
else {
if (IS_POSIXACL(inode) && (mode & S_IRWXG)) {
-   int error = check_acl(inode, mask);
+   int error = check_posix_acl(inode, mask);
if (error != -EAGAIN)
return error;
}
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index f24646e..7810c6f 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -100,13 +100,13 @@ struct posix_acl *get_acl(struct inode *inode, int type)
 {
struct posix_acl *acl;
 
+   if (!IS_POSIXACL(inode))
+   return NULL;
+
acl = get_cached_acl(inode, type);
if (acl != ACL_NOT_CACHED)
return acl;
 
-   if (!IS_POSIXACL(inode))
-   return NULL;
-
/*
 * A filesystem can force a ACL callback by just never filling the
 * ACL cache. But normally you'd fill the cache either at inode
-- 
2.5.0

[PATCH v20 21/23] vfs: Add richacl permission checking

2016-03-19 Thread Andreas Gruenbacher

Hook the richacl permission checking function into the vfs.

Signed-off-by: Andreas Gruenbacher 
---
 fs/namei.c | 51 +--
 fs/posix_acl.c |  6 +++---
 2 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 28707ae..b55cee6 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "internal.h"
@@ -255,7 +256,40 @@ void putname(struct filename *name)
__putname(name);
 }
 
-static int check_acl(struct inode *inode, int mask)
+static int check_richacl(struct inode *inode, int mask)
+{
+#ifdef CONFIG_FS_RICHACL
+   struct richacl *acl;
+
+   if (mask & MAY_NOT_BLOCK) {
+   acl = get_cached_richacl_rcu(inode);
+   if (!acl)
+   goto no_acl;
+   /* no ->get_richacl() calls in RCU mode... */
+   if (acl == ACL_NOT_CACHED)
+   return -ECHILD;
+   return richacl_permission(inode, acl, mask & ~MAY_NOT_BLOCK);
+   }
+
+   acl = get_richacl(inode);
+   if (IS_ERR(acl))
+   return PTR_ERR(acl);
+   if (acl) {
+   int error = richacl_permission(inode, acl, mask);
+   richacl_put(acl);
+   return error;
+   }
+no_acl:
+#endif
+   if (mask & (MAY_DELETE_SELF | MAY_TAKE_OWNERSHIP |
+   MAY_CHMOD | MAY_SET_TIMES)) {
+   /* File permission bits cannot grant this. */
+   return -EACCES;
+   }
+   return -EAGAIN;
+}
+
+static int check_posix_acl(struct inode *inode, int mask)
 {
 #ifdef CONFIG_FS_POSIX_ACL
struct posix_acl *acl;
@@ -290,11 +324,24 @@ static int acl_permission_check(struct inode *inode, int 
mask)
 {
unsigned int mode = inode->i_mode;
 
+   /*
+* With POSIX ACLs, the (mode & S_IRWXU) bits exactly match the owner
+* permissions, and we can skip checking posix acls for the owner.
+* With richacls, the owner may be granted fewer permissions than the
+* mode bits seem to suggest (for example, append but not write), and
+* we always need to check the richacl.
+*/
+
+   if (IS_RICHACL(inode)) {
+   int error = check_richacl(inode, mask);
+   if (error != -EAGAIN)
+   return error;
+   }
if (likely(uid_eq(current_fsuid(), inode->i_uid)))
mode >>= 6;
else {
if (IS_POSIXACL(inode) && (mode & S_IRWXG)) {
-   int error = check_acl(inode, mask);
+   int error = check_posix_acl(inode, mask);
if (error != -EAGAIN)
return error;
}
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index f24646e..7810c6f 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -100,13 +100,13 @@ struct posix_acl *get_acl(struct inode *inode, int type)
 {
struct posix_acl *acl;
 
+   if (!IS_POSIXACL(inode))
+   return NULL;
+
acl = get_cached_acl(inode, type);
if (acl != ACL_NOT_CACHED)
return acl;
 
-   if (!IS_POSIXACL(inode))
-   return NULL;
-
/*
 * A filesystem can force a ACL callback by just never filling the
 * ACL cache. But normally you'd fill the cache either at inode
-- 
2.5.0

Re: Linux 3.14.65

2016-03-19 Thread Greg KH

diff --git a/Documentation/filesystems/efivarfs.txt 
b/Documentation/filesystems/efivarfs.txt
index c477af086e65..686a64bba775 100644
--- a/Documentation/filesystems/efivarfs.txt
+++ b/Documentation/filesystems/efivarfs.txt
@@ -14,3 +14,10 @@ filesystem.
 efivarfs is typically mounted like this,
 
mount -t efivarfs none /sys/firmware/efi/efivars
+
+Due to the presence of numerous firmware bugs where removing non-standard
+UEFI variables causes the system firmware to fail to POST, efivarfs
+files that are not well-known standardized variables are created
+as immutable files.  This doesn't prevent removal - "chattr -i" will work -
+but it does prevent this kind of failure from being accomplished
+accidentally.
diff --git a/Makefile b/Makefile
index de41fa82652f..a19c22a77728 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 14
-SUBLEVEL = 64
+SUBLEVEL = 65
 EXTRAVERSION =
 NAME = Remembering Coco
 
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 12664c130d73..78a859ec4946 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -202,7 +202,7 @@ static void dedotify(Elf64_Sym *syms, unsigned int numsyms, 
char *strtab)
if (syms[i].st_shndx == SHN_UNDEF) {
char *name = strtab + syms[i].st_name;
if (name[0] == '.')
-   memmove(name, name+1, strlen(name));
+   syms[i].st_name++;
}
}
 }
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index b3bad672e5d9..87fa70f8472a 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1148,6 +1148,20 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
std r6, VCPU_ACOP(r9)
stw r7, VCPU_GUEST_PID(r9)
std r8, VCPU_WORT(r9)
+   /*
+* Restore various registers to 0, where non-zero values
+* set by the guest could disrupt the host.
+*/
+   li  r0, 0
+   mtspr   SPRN_IAMR, r0
+   mtspr   SPRN_CIABR, r0
+   mtspr   SPRN_DAWRX, r0
+   mtspr   SPRN_TCSCR, r0
+   mtspr   SPRN_WORT, r0
+   /* Set MMCRS to 1<<31 to freeze and disable the SPMC counters */
+   li  r0, 1
+   sldir0, r0, 31
+   mtspr   SPRN_MMCRS, r0
 8:
 
/* Save and reset AMR and UAMOR before turning on the MMU */
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 80c22a3ca688..b6fc5fc64cef 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1555,6 +1555,13 @@ static void add_atomic_switch_msr(struct vcpu_vmx *vmx, 
unsigned msr,
return;
}
break;
+   case MSR_IA32_PEBS_ENABLE:
+   /* PEBS needs a quiescent period after being disabled (to write
+* a record).  Disabling PEBS through VMX MSR swapping doesn't
+* provide that period, so a CPU could write host's record into
+* guest's memory.
+*/
+   wrmsrl(MSR_IA32_PEBS_ENABLE, 0);
}
 
for (i = 0; i < m->nr; ++i)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1777f89875fb..8db66424be97 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1991,6 +1991,8 @@ static void accumulate_steal_time(struct kvm_vcpu *vcpu)
 
 static void record_steal_time(struct kvm_vcpu *vcpu)
 {
+   accumulate_steal_time(vcpu);
+
if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED))
return;
 
@@ -2123,12 +2125,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
if (!(data & KVM_MSR_ENABLED))
break;
 
-   vcpu->arch.st.last_steal = current->sched_info.run_delay;
-
-   preempt_disable();
-   accumulate_steal_time(vcpu);
-   preempt_enable();
-
kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
 
break;
@@ -2818,7 +2814,6 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
vcpu->cpu = cpu;
}
 
-   accumulate_steal_time(vcpu);
kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
 }
 
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 1971f3ccb09a..eeb2fb239934 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -125,23 +125,6 @@ int af_alg_release(struct socket *sock)
 }
 EXPORT_SYMBOL_GPL(af_alg_release);
 
-void af_alg_release_parent(struct sock *sk)
-{
-   struct alg_sock *ask = alg_sk(sk);
-   bool last;
-
-   sk = ask->parent;
-   ask = alg_sk(sk);
-
-   lock_sock(sk);
-   last = !--ask->refcnt;
-   release_sock(sk);
-
-   if (last)
-   sock_put(sk);
-}
-EXPORT_SYMBOL_GPL(af_alg_release_parent);
-
 static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 {
struct sock *sk =

Re: Linux 3.14.65

2016-03-19 Thread Greg KH

diff --git a/Documentation/filesystems/efivarfs.txt 
b/Documentation/filesystems/efivarfs.txt
index c477af086e65..686a64bba775 100644
--- a/Documentation/filesystems/efivarfs.txt
+++ b/Documentation/filesystems/efivarfs.txt
@@ -14,3 +14,10 @@ filesystem.
 efivarfs is typically mounted like this,
 
mount -t efivarfs none /sys/firmware/efi/efivars
+
+Due to the presence of numerous firmware bugs where removing non-standard
+UEFI variables causes the system firmware to fail to POST, efivarfs
+files that are not well-known standardized variables are created
+as immutable files.  This doesn't prevent removal - "chattr -i" will work -
+but it does prevent this kind of failure from being accomplished
+accidentally.
diff --git a/Makefile b/Makefile
index de41fa82652f..a19c22a77728 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 14
-SUBLEVEL = 64
+SUBLEVEL = 65
 EXTRAVERSION =
 NAME = Remembering Coco
 
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 12664c130d73..78a859ec4946 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -202,7 +202,7 @@ static void dedotify(Elf64_Sym *syms, unsigned int numsyms, 
char *strtab)
if (syms[i].st_shndx == SHN_UNDEF) {
char *name = strtab + syms[i].st_name;
if (name[0] == '.')
-   memmove(name, name+1, strlen(name));
+   syms[i].st_name++;
}
}
 }
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S 
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index b3bad672e5d9..87fa70f8472a 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1148,6 +1148,20 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
std r6, VCPU_ACOP(r9)
stw r7, VCPU_GUEST_PID(r9)
std r8, VCPU_WORT(r9)
+   /*
+* Restore various registers to 0, where non-zero values
+* set by the guest could disrupt the host.
+*/
+   li  r0, 0
+   mtspr   SPRN_IAMR, r0
+   mtspr   SPRN_CIABR, r0
+   mtspr   SPRN_DAWRX, r0
+   mtspr   SPRN_TCSCR, r0
+   mtspr   SPRN_WORT, r0
+   /* Set MMCRS to 1<<31 to freeze and disable the SPMC counters */
+   li  r0, 1
+   sldir0, r0, 31
+   mtspr   SPRN_MMCRS, r0
 8:
 
/* Save and reset AMR and UAMOR before turning on the MMU */
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 80c22a3ca688..b6fc5fc64cef 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1555,6 +1555,13 @@ static void add_atomic_switch_msr(struct vcpu_vmx *vmx, 
unsigned msr,
return;
}
break;
+   case MSR_IA32_PEBS_ENABLE:
+   /* PEBS needs a quiescent period after being disabled (to write
+* a record).  Disabling PEBS through VMX MSR swapping doesn't
+* provide that period, so a CPU could write host's record into
+* guest's memory.
+*/
+   wrmsrl(MSR_IA32_PEBS_ENABLE, 0);
}
 
for (i = 0; i < m->nr; ++i)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1777f89875fb..8db66424be97 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1991,6 +1991,8 @@ static void accumulate_steal_time(struct kvm_vcpu *vcpu)
 
 static void record_steal_time(struct kvm_vcpu *vcpu)
 {
+   accumulate_steal_time(vcpu);
+
if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED))
return;
 
@@ -2123,12 +2125,6 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
if (!(data & KVM_MSR_ENABLED))
break;
 
-   vcpu->arch.st.last_steal = current->sched_info.run_delay;
-
-   preempt_disable();
-   accumulate_steal_time(vcpu);
-   preempt_enable();
-
kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
 
break;
@@ -2818,7 +2814,6 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
vcpu->cpu = cpu;
}
 
-   accumulate_steal_time(vcpu);
kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu);
 }
 
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 1971f3ccb09a..eeb2fb239934 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -125,23 +125,6 @@ int af_alg_release(struct socket *sock)
 }
 EXPORT_SYMBOL_GPL(af_alg_release);
 
-void af_alg_release_parent(struct sock *sk)
-{
-   struct alg_sock *ask = alg_sk(sk);
-   bool last;
-
-   sk = ask->parent;
-   ask = alg_sk(sk);
-
-   lock_sock(sk);
-   last = !--ask->refcnt;
-   release_sock(sk);
-
-   if (last)
-   sock_put(sk);
-}
-EXPORT_SYMBOL_GPL(af_alg_release_parent);
-
 static int alg_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 {
struct sock *sk =

Re: [RFC PATCH linux-next] ovs: internal_set_rx_headroom() can be static

2016-03-19 Thread David Miller

From: kbuild test robot 
Date: Sat, 19 Mar 2016 00:54:50 +0800

> Signed-off-by: Fengguang Wu 

Looks good, applied, thanks.

Re: [PATCH v4 2/2] auxdisplay: ht16k33: Driver for LED controller

2016-03-19 Thread Rob Herring

On Wed, Mar 16, 2016 at 04:52:09PM +0100, Robin van der Gracht wrote:
> This is a driver for the Holtek HT16K33 RAM mapping LED controller with 
> keyscan.

Wrap your lines to less than 80 chars.

> Signed-off-by: Robin van der Gracht 
> ---
> 
> Changes in v4:
>  - Removed trailing dot from patch title
>  - Removed unused defines
>  - Fixed brightness range (0 was presumed to be off but its 1/16 duty cycle)
>  - No longer checking 'reschedule' before setting it in ht16k33_keypad_scan()
>  - Use more efficient ffs() to find changed rows in ht16k33_keypad_scan()
>  - Use BIT macro in ht16k33_keypad_scan()
>  - Removed extra space in return line from ht16k33_bl_check_fb()
>  - Removed redundant 'Out of Memory' prints from ht16k33_probe()
>  - Changed bustype from BUS_HOST to BUS_I2C
> 
>  .../devicetree/bindings/display/ht16k33.txt|  42 ++
>  drivers/auxdisplay/Kconfig |   9 +
>  drivers/auxdisplay/Makefile|   1 +
>  drivers/auxdisplay/ht16k33.c   | 563 
> +
>  4 files changed, 615 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/ht16k33.txt
>  create mode 100644 drivers/auxdisplay/ht16k33.c
> 
> diff --git a/Documentation/devicetree/bindings/display/ht16k33.txt 
> b/Documentation/devicetree/bindings/display/ht16k33.txt
> new file mode 100644
> index 000..20ef996
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/ht16k33.txt
> @@ -0,0 +1,42 @@
> +Holtek ht16k33 RAM mapping 16*8 LED controller driver with keyscan
> +---
> +
> +Required properties:
> +- compatible:"ht,ht16k33"
> +- reg:   I2C slave address of the chip.
> +- interrupt-parent:  A phandle pointing to the interrupt controller\

Drop the \

> + serving the interrupt for this chip.
> +- interrupts:Interrupt specification for the key pressed 
> interrupt.
> +- refresh-rate-hz:   Display update interval in HZ.
> +- debounce-delay-ms: Debouncing interval time in microseconds.
> +- linux,keymap:  The keymap for keys as described in the binding
> + document (devicetree/bindings/input/matrix-keymap.txt).
> +
> +Optional properties:
> +- linux,no-autorepeat:   Disable keyrepeat.
> +- default-brightness-level: Initial brightness level [0-15] (default: 15).
> +
> +Example:
> +
> + {
> + ht16k33: ht16k33@70 {
> + compatible = "ht,ht16k33";
> + reg = <0x70>;
> + refresh-rate-hz = <20>;
> + debounce-delay-ms = <50>;
> + interrupt-parent = <>;
> + interrupts = <5 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
> + linux,keymap = <
> + MATRIX_KEY(2, 0, KEY_F6)
> + MATRIX_KEY(3, 0, KEY_F8)
> + MATRIX_KEY(4, 0, KEY_F0)
> + MATRIX_KEY(5, 0, KEY_F4)
> + MATRIX_KEY(6, 0, KEY_F2)
> + MATRIX_KEY(2, 1, KEY_F5)
> + MATRIX_KEY(3, 1, KEY_F7)
> + MATRIX_KEY(4, 1, KEY_F9)
> + MATRIX_KEY(5, 1, KEY_F3)
> + MATRIX_KEY(6, 1, KEY_F1)
> + >;
> + };
> +};

Re: [RFC PATCH linux-next] ovs: internal_set_rx_headroom() can be static

2016-03-19 Thread David Miller

From: kbuild test robot 
Date: Sat, 19 Mar 2016 00:54:50 +0800

> Signed-off-by: Fengguang Wu 

Looks good, applied, thanks.

Re: [PATCH v4 2/2] auxdisplay: ht16k33: Driver for LED controller

2016-03-19 Thread Rob Herring

On Wed, Mar 16, 2016 at 04:52:09PM +0100, Robin van der Gracht wrote:
> This is a driver for the Holtek HT16K33 RAM mapping LED controller with 
> keyscan.

Wrap your lines to less than 80 chars.

> Signed-off-by: Robin van der Gracht 
> ---
> 
> Changes in v4:
>  - Removed trailing dot from patch title
>  - Removed unused defines
>  - Fixed brightness range (0 was presumed to be off but its 1/16 duty cycle)
>  - No longer checking 'reschedule' before setting it in ht16k33_keypad_scan()
>  - Use more efficient ffs() to find changed rows in ht16k33_keypad_scan()
>  - Use BIT macro in ht16k33_keypad_scan()
>  - Removed extra space in return line from ht16k33_bl_check_fb()
>  - Removed redundant 'Out of Memory' prints from ht16k33_probe()
>  - Changed bustype from BUS_HOST to BUS_I2C
> 
>  .../devicetree/bindings/display/ht16k33.txt|  42 ++
>  drivers/auxdisplay/Kconfig |   9 +
>  drivers/auxdisplay/Makefile|   1 +
>  drivers/auxdisplay/ht16k33.c   | 563 
> +
>  4 files changed, 615 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/ht16k33.txt
>  create mode 100644 drivers/auxdisplay/ht16k33.c
> 
> diff --git a/Documentation/devicetree/bindings/display/ht16k33.txt 
> b/Documentation/devicetree/bindings/display/ht16k33.txt
> new file mode 100644
> index 000..20ef996
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/ht16k33.txt
> @@ -0,0 +1,42 @@
> +Holtek ht16k33 RAM mapping 16*8 LED controller driver with keyscan
> +---
> +
> +Required properties:
> +- compatible:"ht,ht16k33"
> +- reg:   I2C slave address of the chip.
> +- interrupt-parent:  A phandle pointing to the interrupt controller\

Drop the \

> + serving the interrupt for this chip.
> +- interrupts:Interrupt specification for the key pressed 
> interrupt.
> +- refresh-rate-hz:   Display update interval in HZ.
> +- debounce-delay-ms: Debouncing interval time in microseconds.
> +- linux,keymap:  The keymap for keys as described in the binding
> + document (devicetree/bindings/input/matrix-keymap.txt).
> +
> +Optional properties:
> +- linux,no-autorepeat:   Disable keyrepeat.
> +- default-brightness-level: Initial brightness level [0-15] (default: 15).
> +
> +Example:
> +
> + {
> + ht16k33: ht16k33@70 {
> + compatible = "ht,ht16k33";
> + reg = <0x70>;
> + refresh-rate-hz = <20>;
> + debounce-delay-ms = <50>;
> + interrupt-parent = <>;
> + interrupts = <5 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
> + linux,keymap = <
> + MATRIX_KEY(2, 0, KEY_F6)
> + MATRIX_KEY(3, 0, KEY_F8)
> + MATRIX_KEY(4, 0, KEY_F0)
> + MATRIX_KEY(5, 0, KEY_F4)
> + MATRIX_KEY(6, 0, KEY_F2)
> + MATRIX_KEY(2, 1, KEY_F5)
> + MATRIX_KEY(3, 1, KEY_F7)
> + MATRIX_KEY(4, 1, KEY_F9)
> + MATRIX_KEY(5, 1, KEY_F3)
> + MATRIX_KEY(6, 1, KEY_F1)
> + >;
> + };
> +};

Re: [PATCH] MAINTAINERS: Update UBIFS entry

2016-03-19 Thread Artem Bityutskiy

On Thu, 2016-03-03 at 14:22 +0100, Richard Weinberger wrote:
> ...to represent the status quo.
> 
> Signed-off-by: Richard Weinberger 
> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Acked-by: Artem Bityutskiy 

Thanks Richard!

Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts

2016-03-19 Thread Sergei Shtylyov


On 3/17/2016 12:41 PM, Alexey Brodkin wrote:


Following commit broke DW GMAC functionality on AXS10x boards:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763


   Note that scripts/checkpatch.pl now enforces certain format for citing 
commits: commit <12-digit SHA1> ("").


[...]

MBR, Sergei

Re: [PATCH] MAINTAINERS: Update UBIFS entry

2016-03-19 Thread Artem Bityutskiy

On Thu, 2016-03-03 at 14:22 +0100, Richard Weinberger wrote:
> ...to represent the status quo.
> 
> Signed-off-by: Richard Weinberger 
> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Acked-by: Artem Bityutskiy 

Thanks Richard!

Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts

2016-03-19 Thread Sergei Shtylyov


On 3/17/2016 12:41 PM, Alexey Brodkin wrote:


Following commit broke DW GMAC functionality on AXS10x boards:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763


   Note that scripts/checkpatch.pl now enforces certain format for citing 
commits: commit <12-digit SHA1> ("").


[...]

MBR, Sergei

[PATCH] ARM: dts: k2: Rename the k2 files to keystone-k2* files

2016-03-19 Thread Nishanth Menon

As reported in [1], rename the k2* dts files to keystone-* files
this will force consistency throughout.

Script for the same (and hand modified for Makefile and MAINTAINERS
files):
for i in arch/arm/boot/dts/k2*
do
b=`basename $i`;
git mv $i arch/arm/boot/dts/keystone-$b;
sed -i -e "s/$b/keystone-$b/g" arch/arm/boot/dts/*[si]
done

NOTE: bootloaders that depend on older dtb names will need to be
updated as well.

[1] http://marc.info/?l=linux-arm-kernel=145637407804754=2

Reported-by: Olof Johansson 
Signed-off-by: Nishanth Menon 
---

Based on next-20160316
Ignored:
 - all the build warnings reported in 
http://www.spinics.net/lists/arm-kernel/msg490058.html
 - k2g* files which for some reason appears in linux-next, but not part of pull 
request:
http://marc.info/?l=linux-arm-kernel=145643709430175=2

 MAINTAINERS   | 2 +-
 arch/arm/boot/dts/Makefile| 6 +++---
 arch/arm/boot/dts/{k2e-clocks.dtsi => keystone-k2e-clocks.dtsi}   | 0
 arch/arm/boot/dts/{k2e-evm.dts => keystone-k2e-evm.dts}   | 2 +-
 arch/arm/boot/dts/{k2e-netcp.dtsi => keystone-k2e-netcp.dtsi} | 0
 arch/arm/boot/dts/{k2e.dtsi => keystone-k2e.dtsi} | 4 ++--
 arch/arm/boot/dts/{k2hk-clocks.dtsi => keystone-k2hk-clocks.dtsi} | 0
 arch/arm/boot/dts/{k2hk-evm.dts => keystone-k2hk-evm.dts} | 2 +-
 arch/arm/boot/dts/{k2hk-netcp.dtsi => keystone-k2hk-netcp.dtsi}   | 0
 arch/arm/boot/dts/{k2hk.dtsi => keystone-k2hk.dtsi}   | 4 ++--
 arch/arm/boot/dts/{k2l-clocks.dtsi => keystone-k2l-clocks.dtsi}   | 0
 arch/arm/boot/dts/{k2l-evm.dts => keystone-k2l-evm.dts}   | 2 +-
 arch/arm/boot/dts/{k2l-netcp.dtsi => keystone-k2l-netcp.dtsi} | 0
 arch/arm/boot/dts/{k2l.dtsi => keystone-k2l.dtsi} | 4 ++--
 14 files changed, 13 insertions(+), 13 deletions(-)
 rename arch/arm/boot/dts/{k2e-clocks.dtsi => keystone-k2e-clocks.dtsi} (100%)
 rename arch/arm/boot/dts/{k2e-evm.dts => keystone-k2e-evm.dts} (98%)
 rename arch/arm/boot/dts/{k2e-netcp.dtsi => keystone-k2e-netcp.dtsi} (100%)
 rename arch/arm/boot/dts/{k2e.dtsi => keystone-k2e.dtsi} (97%)
 rename arch/arm/boot/dts/{k2hk-clocks.dtsi => keystone-k2hk-clocks.dtsi} (100%)
 rename arch/arm/boot/dts/{k2hk-evm.dts => keystone-k2hk-evm.dts} (99%)
 rename arch/arm/boot/dts/{k2hk-netcp.dtsi => keystone-k2hk-netcp.dtsi} (100%)
 rename arch/arm/boot/dts/{k2hk.dtsi => keystone-k2hk.dtsi} (96%)
 rename arch/arm/boot/dts/{k2l-clocks.dtsi => keystone-k2l-clocks.dtsi} (100%)
 rename arch/arm/boot/dts/{k2l-evm.dts => keystone-k2l-evm.dts} (98%)
 rename arch/arm/boot/dts/{k2l-netcp.dtsi => keystone-k2l-netcp.dtsi} (100%)
 rename arch/arm/boot/dts/{k2l.dtsi => keystone-k2l.dtsi} (96%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3c0be602d57c..a00233edbe83 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1260,7 +1260,7 @@ M:Santosh Shilimkar 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-keystone/
-F: arch/arm/boot/dts/k2*
+F: arch/arm/boot/dts/keystone-*
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
 
 ARM/TEXAS INSTRUMENT KEYSTONE CLOCK FRAMEWORK
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0d6bf2875cc7..f06b4b849db2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -158,9 +158,9 @@ dtb-$(CONFIG_ARCH_INTEGRATOR) += \
integratorap.dtb \
integratorcp.dtb
 dtb-$(CONFIG_ARCH_KEYSTONE) += \
-   k2hk-evm.dtb \
-   k2l-evm.dtb \
-   k2e-evm.dtb \
+   keystone-k2hk-evm.dtb \
+   keystone-k2l-evm.dtb \
+   keystone-k2e-evm.dtb \
keystone-k2g-evm.dtb
 dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-b3.dtb \
diff --git a/arch/arm/boot/dts/k2e-clocks.dtsi 
b/arch/arm/boot/dts/keystone-k2e-clocks.dtsi
similarity index 100%
rename from arch/arm/boot/dts/k2e-clocks.dtsi
rename to arch/arm/boot/dts/keystone-k2e-clocks.dtsi
diff --git a/arch/arm/boot/dts/k2e-evm.dts 
b/arch/arm/boot/dts/keystone-k2e-evm.dts
similarity index 98%
rename from arch/arm/boot/dts/k2e-evm.dts
rename to arch/arm/boot/dts/keystone-k2e-evm.dts
index b7e99807f5c2..4c32ebc1425a 100644
--- a/arch/arm/boot/dts/k2e-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2e-evm.dts
@@ -10,7 +10,7 @@
 /dts-v1/;
 
 #include "keystone.dtsi"
-#include "k2e.dtsi"
+#include "keystone-k2e.dtsi"
 
 / {
compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone";
diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi 
b/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
similarity index 100%
rename from arch/arm/boot/dts/k2e-netcp.dtsi
rename to arch/arm/boot/dts/keystone-k2e-netcp.dtsi
diff --git a/arch/arm/boot/dts/k2e.dtsi b/arch/arm/boot/dts/keystone-k2e.dtsi
similarity index 97%
rename from arch/arm/boot/dts/k2e.dtsi
rename to

[PATCH] ARM: dts: k2: Rename the k2 files to keystone-k2* files

2016-03-19 Thread Nishanth Menon

As reported in [1], rename the k2* dts files to keystone-* files
this will force consistency throughout.

Script for the same (and hand modified for Makefile and MAINTAINERS
files):
for i in arch/arm/boot/dts/k2*
do
b=`basename $i`;
git mv $i arch/arm/boot/dts/keystone-$b;
sed -i -e "s/$b/keystone-$b/g" arch/arm/boot/dts/*[si]
done

NOTE: bootloaders that depend on older dtb names will need to be
updated as well.

[1] http://marc.info/?l=linux-arm-kernel=145637407804754=2

Reported-by: Olof Johansson 
Signed-off-by: Nishanth Menon 
---

Based on next-20160316
Ignored:
 - all the build warnings reported in 
http://www.spinics.net/lists/arm-kernel/msg490058.html
 - k2g* files which for some reason appears in linux-next, but not part of pull 
request:
http://marc.info/?l=linux-arm-kernel=145643709430175=2

 MAINTAINERS   | 2 +-
 arch/arm/boot/dts/Makefile| 6 +++---
 arch/arm/boot/dts/{k2e-clocks.dtsi => keystone-k2e-clocks.dtsi}   | 0
 arch/arm/boot/dts/{k2e-evm.dts => keystone-k2e-evm.dts}   | 2 +-
 arch/arm/boot/dts/{k2e-netcp.dtsi => keystone-k2e-netcp.dtsi} | 0
 arch/arm/boot/dts/{k2e.dtsi => keystone-k2e.dtsi} | 4 ++--
 arch/arm/boot/dts/{k2hk-clocks.dtsi => keystone-k2hk-clocks.dtsi} | 0
 arch/arm/boot/dts/{k2hk-evm.dts => keystone-k2hk-evm.dts} | 2 +-
 arch/arm/boot/dts/{k2hk-netcp.dtsi => keystone-k2hk-netcp.dtsi}   | 0
 arch/arm/boot/dts/{k2hk.dtsi => keystone-k2hk.dtsi}   | 4 ++--
 arch/arm/boot/dts/{k2l-clocks.dtsi => keystone-k2l-clocks.dtsi}   | 0
 arch/arm/boot/dts/{k2l-evm.dts => keystone-k2l-evm.dts}   | 2 +-
 arch/arm/boot/dts/{k2l-netcp.dtsi => keystone-k2l-netcp.dtsi} | 0
 arch/arm/boot/dts/{k2l.dtsi => keystone-k2l.dtsi} | 4 ++--
 14 files changed, 13 insertions(+), 13 deletions(-)
 rename arch/arm/boot/dts/{k2e-clocks.dtsi => keystone-k2e-clocks.dtsi} (100%)
 rename arch/arm/boot/dts/{k2e-evm.dts => keystone-k2e-evm.dts} (98%)
 rename arch/arm/boot/dts/{k2e-netcp.dtsi => keystone-k2e-netcp.dtsi} (100%)
 rename arch/arm/boot/dts/{k2e.dtsi => keystone-k2e.dtsi} (97%)
 rename arch/arm/boot/dts/{k2hk-clocks.dtsi => keystone-k2hk-clocks.dtsi} (100%)
 rename arch/arm/boot/dts/{k2hk-evm.dts => keystone-k2hk-evm.dts} (99%)
 rename arch/arm/boot/dts/{k2hk-netcp.dtsi => keystone-k2hk-netcp.dtsi} (100%)
 rename arch/arm/boot/dts/{k2hk.dtsi => keystone-k2hk.dtsi} (96%)
 rename arch/arm/boot/dts/{k2l-clocks.dtsi => keystone-k2l-clocks.dtsi} (100%)
 rename arch/arm/boot/dts/{k2l-evm.dts => keystone-k2l-evm.dts} (98%)
 rename arch/arm/boot/dts/{k2l-netcp.dtsi => keystone-k2l-netcp.dtsi} (100%)
 rename arch/arm/boot/dts/{k2l.dtsi => keystone-k2l.dtsi} (96%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3c0be602d57c..a00233edbe83 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1260,7 +1260,7 @@ M:Santosh Shilimkar 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-keystone/
-F: arch/arm/boot/dts/k2*
+F: arch/arm/boot/dts/keystone-*
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
 
 ARM/TEXAS INSTRUMENT KEYSTONE CLOCK FRAMEWORK
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0d6bf2875cc7..f06b4b849db2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -158,9 +158,9 @@ dtb-$(CONFIG_ARCH_INTEGRATOR) += \
integratorap.dtb \
integratorcp.dtb
 dtb-$(CONFIG_ARCH_KEYSTONE) += \
-   k2hk-evm.dtb \
-   k2l-evm.dtb \
-   k2e-evm.dtb \
+   keystone-k2hk-evm.dtb \
+   keystone-k2l-evm.dtb \
+   keystone-k2e-evm.dtb \
keystone-k2g-evm.dtb
 dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-b3.dtb \
diff --git a/arch/arm/boot/dts/k2e-clocks.dtsi 
b/arch/arm/boot/dts/keystone-k2e-clocks.dtsi
similarity index 100%
rename from arch/arm/boot/dts/k2e-clocks.dtsi
rename to arch/arm/boot/dts/keystone-k2e-clocks.dtsi
diff --git a/arch/arm/boot/dts/k2e-evm.dts 
b/arch/arm/boot/dts/keystone-k2e-evm.dts
similarity index 98%
rename from arch/arm/boot/dts/k2e-evm.dts
rename to arch/arm/boot/dts/keystone-k2e-evm.dts
index b7e99807f5c2..4c32ebc1425a 100644
--- a/arch/arm/boot/dts/k2e-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2e-evm.dts
@@ -10,7 +10,7 @@
 /dts-v1/;
 
 #include "keystone.dtsi"
-#include "k2e.dtsi"
+#include "keystone-k2e.dtsi"
 
 / {
compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone";
diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi 
b/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
similarity index 100%
rename from arch/arm/boot/dts/k2e-netcp.dtsi
rename to arch/arm/boot/dts/keystone-k2e-netcp.dtsi
diff --git a/arch/arm/boot/dts/k2e.dtsi b/arch/arm/boot/dts/keystone-k2e.dtsi
similarity index 97%
rename from arch/arm/boot/dts/k2e.dtsi
rename to arch/arm/boot/dts/keystone-k2e.dtsi
index

Re: RFC on fixing mutex spinning on owner

2016-03-19 Thread Steven Rostedt

On Wed, 16 Mar 2016 16:38:56 -0700
Joel Fernandes  wrote:

> I am not sure if the problem is with the i915 driver, because the
> mutex spin on owner stuff is mutex related so the mutex design may
> potentially need a tweak (I mentioned a proposal of adding mutex
> spinning time outs).
> Also since this is latency issue related (I mentioned preemptoff
> tracer and preempt disabled), I sent it to linux-rt-users. Thanks for
> the tip about sending it to i915 developers, incase no one here has a
> say in the matter, I can drop them a note later as well.

Actually, the preempt off section here is not really an issue:

rcu_read_lock();
while (owner_running(lock, owner)) {
if (need_resched())
break;

cpu_relax_lowlatency();
}
rcu_read_unlock();

Although preemption may be disabled, that "need_resched()" check will
break out of the loop if a higher priority task were to want to run on
this CPU.

I probably should add a hook there to let the preemptoff tracer know
that this is not an issue.

Thanks for the report.

-- Steve

Re: [PATCH] ARC: build: Turn off -Wmaybe-uninitialized for ARC gcc 4.8

2016-03-19 Thread Vineet Gupta

On Friday 18 March 2016 03:59 PM, Arnd Bergmann wrote:
> On Friday 18 March 2016 15:50:11 Vineet Gupta wrote:
>> Sure, but I prefer this to be only for gcc 4.8 as this warning seems to be
>> healthy in small doses  At least it keeps the door open for future discussion
>> with gcc guys !
> 
> FWIW, testing on ARM with gcc-6.0 -O3, I also get tons of maybe-uninitialized
> warnings. It's unlikely that this is architecture specific or fixed in newer
> compiler versions.

So we disable this for good just like -Os.
What a shame - seemed like a reasonable safety net for programming errors.

>> The following nested construct actually works - does that look OK to you ?
>>
>> ARCH_CFLAGS += -O3 $(call cc-ifversion, -lt, 0408, $(call 
>> cc-disable-warning,maybe-uninitialized,))
> 
> Yes, that seems ok.

There was typo actually -lt needed to be -eq

> I don't really understand why -O3 is needed though, maybe it's better to
> assume that it won't be needed in future gcc versions and do

Not sure what you mean, -O3 for triggering the warnings or -O3 in ARC makefile 
at all.
Assuming it's latter, this is how its been forever and was added consciously as
performance seemed better with -O3 than the default -O2.


> 
> ARCH_CFLAGS += $(call cc-ifversion, -lt, 0408, -O3 $(call 
> cc-disable-warning,maybe-uninitialized,))
> 
>   Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: RFC on fixing mutex spinning on owner

2016-03-19 Thread Steven Rostedt

On Wed, 16 Mar 2016 16:38:56 -0700
Joel Fernandes  wrote:

> I am not sure if the problem is with the i915 driver, because the
> mutex spin on owner stuff is mutex related so the mutex design may
> potentially need a tweak (I mentioned a proposal of adding mutex
> spinning time outs).
> Also since this is latency issue related (I mentioned preemptoff
> tracer and preempt disabled), I sent it to linux-rt-users. Thanks for
> the tip about sending it to i915 developers, incase no one here has a
> say in the matter, I can drop them a note later as well.

Actually, the preempt off section here is not really an issue:

rcu_read_lock();
while (owner_running(lock, owner)) {
if (need_resched())
break;

cpu_relax_lowlatency();
}
rcu_read_unlock();

Although preemption may be disabled, that "need_resched()" check will
break out of the loop if a higher priority task were to want to run on
this CPU.

I probably should add a hook there to let the preemptoff tracer know
that this is not an issue.

Thanks for the report.

-- Steve

Re: [PATCH] ARC: build: Turn off -Wmaybe-uninitialized for ARC gcc 4.8

2016-03-19 Thread Vineet Gupta

On Friday 18 March 2016 03:59 PM, Arnd Bergmann wrote:
> On Friday 18 March 2016 15:50:11 Vineet Gupta wrote:
>> Sure, but I prefer this to be only for gcc 4.8 as this warning seems to be
>> healthy in small doses  At least it keeps the door open for future discussion
>> with gcc guys !
> 
> FWIW, testing on ARM with gcc-6.0 -O3, I also get tons of maybe-uninitialized
> warnings. It's unlikely that this is architecture specific or fixed in newer
> compiler versions.

So we disable this for good just like -Os.
What a shame - seemed like a reasonable safety net for programming errors.

>> The following nested construct actually works - does that look OK to you ?
>>
>> ARCH_CFLAGS += -O3 $(call cc-ifversion, -lt, 0408, $(call 
>> cc-disable-warning,maybe-uninitialized,))
> 
> Yes, that seems ok.

There was typo actually -lt needed to be -eq

> I don't really understand why -O3 is needed though, maybe it's better to
> assume that it won't be needed in future gcc versions and do

Not sure what you mean, -O3 for triggering the warnings or -O3 in ARC makefile 
at all.
Assuming it's latter, this is how its been forever and was added consciously as
performance seemed better with -O3 than the default -O2.


> 
> ARCH_CFLAGS += $(call cc-ifversion, -lt, 0408, -O3 $(call 
> cc-disable-warning,maybe-uninitialized,))
> 
>   Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[PATCH 3.19.y-ckt 09/70] ahci: add new Intel device IDs

2016-03-19 Thread Kamal Mostafa

v3.19.8-ckt17 -stable review patch.  If anyone has any objections, please let 
me know.

---8<

From: Alexandra Yates 

commit 56e74338a535cbcc2f2da08b1ea1a92920194364 upstream.

Adding Intel codename Lewisburg platform device IDs for SATA.

Signed-off-by: Alexandra Yates 
Signed-off-by: Tejun Heo 
Signed-off-by: Kamal Mostafa 
---
 drivers/ata/ahci.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 6d7a882..3f64684 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -332,6 +332,16 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x1f37), board_ahci_avn }, /* Avoton RAID */
{ PCI_VDEVICE(INTEL, 0x1f3e), board_ahci_avn }, /* Avoton RAID */
{ PCI_VDEVICE(INTEL, 0x1f3f), board_ahci_avn }, /* Avoton RAID */
+   { PCI_VDEVICE(INTEL, 0xa182), board_ahci }, /* Lewisburg AHCI*/
+   { PCI_VDEVICE(INTEL, 0xa202), board_ahci }, /* Lewisburg AHCI*/
+   { PCI_VDEVICE(INTEL, 0xa184), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0xa204), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0xa186), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0x2822), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0x2826), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0xa18e), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0xa20e), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0x2823), board_ahci }, /* Wellsburg RAID */
{ PCI_VDEVICE(INTEL, 0x2827), board_ahci }, /* Wellsburg RAID */
{ PCI_VDEVICE(INTEL, 0x8d02), board_ahci }, /* Wellsburg AHCI */
-- 
2.7.0

[PATCH 3.19.y-ckt 09/70] ahci: add new Intel device IDs

2016-03-19 Thread Kamal Mostafa

v3.19.8-ckt17 -stable review patch.  If anyone has any objections, please let 
me know.

---8<

From: Alexandra Yates 

commit 56e74338a535cbcc2f2da08b1ea1a92920194364 upstream.

Adding Intel codename Lewisburg platform device IDs for SATA.

Signed-off-by: Alexandra Yates 
Signed-off-by: Tejun Heo 
Signed-off-by: Kamal Mostafa 
---
 drivers/ata/ahci.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 6d7a882..3f64684 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -332,6 +332,16 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x1f37), board_ahci_avn }, /* Avoton RAID */
{ PCI_VDEVICE(INTEL, 0x1f3e), board_ahci_avn }, /* Avoton RAID */
{ PCI_VDEVICE(INTEL, 0x1f3f), board_ahci_avn }, /* Avoton RAID */
+   { PCI_VDEVICE(INTEL, 0xa182), board_ahci }, /* Lewisburg AHCI*/
+   { PCI_VDEVICE(INTEL, 0xa202), board_ahci }, /* Lewisburg AHCI*/
+   { PCI_VDEVICE(INTEL, 0xa184), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0xa204), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0xa186), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0x2822), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0x2826), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0xa18e), board_ahci }, /* Lewisburg RAID*/
+   { PCI_VDEVICE(INTEL, 0xa20e), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0x2823), board_ahci }, /* Wellsburg RAID */
{ PCI_VDEVICE(INTEL, 0x2827), board_ahci }, /* Wellsburg RAID */
{ PCI_VDEVICE(INTEL, 0x8d02), board_ahci }, /* Wellsburg AHCI */
-- 
2.7.0

Re: [PATCH 2/2] bcma: use of_dma_configure() to set initial dma mask

2016-03-19 Thread kbuild test robot

Hi Arnd,

[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160317]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/bcma-fix-building-without-OF_IRQ/20160317-172805
config: xtensa-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/bcma/main.c: In function 'bcma_of_fill_device':
>> drivers/bcma/main.c:213:2: error: incompatible type for argument 1 of 
>> 'of_dma_configure'
 of_dma_configure(core->dev, node);
 ^
   In file included from include/linux/of_platform.h:17:0,
from drivers/bcma/main.c:17:
   include/linux/of_device.h:58:6: note: expected 'struct device *' but 
argument is of type 'struct device'
void of_dma_configure(struct device *dev, struct device_node *np);
 ^

vim +/of_dma_configure +213 drivers/bcma/main.c

   207  node = bcma_of_find_child_device(parent, core);
   208  if (node)
   209  core->dev.of_node = node;
   210  
   211  core->irq = bcma_of_get_irq(parent, core, 0);
   212  
 > 213  of_dma_configure(core->dev, node);
   214  }
   215  
   216  unsigned int bcma_core_irq(struct bcma_device *core, int num)

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


.config.gz
Description: Binary data

Re: [PATCH 2/2] bcma: use of_dma_configure() to set initial dma mask

2016-03-19 Thread kbuild test robot

Hi Arnd,

[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160317]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/bcma-fix-building-without-OF_IRQ/20160317-172805
config: xtensa-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/bcma/main.c: In function 'bcma_of_fill_device':
>> drivers/bcma/main.c:213:2: error: incompatible type for argument 1 of 
>> 'of_dma_configure'
 of_dma_configure(core->dev, node);
 ^
   In file included from include/linux/of_platform.h:17:0,
from drivers/bcma/main.c:17:
   include/linux/of_device.h:58:6: note: expected 'struct device *' but 
argument is of type 'struct device'
void of_dma_configure(struct device *dev, struct device_node *np);
 ^

vim +/of_dma_configure +213 drivers/bcma/main.c

   207  node = bcma_of_find_child_device(parent, core);
   208  if (node)
   209  core->dev.of_node = node;
   210  
   211  core->irq = bcma_of_get_irq(parent, core, 0);
   212  
 > 213  of_dma_configure(core->dev, node);
   214  }
   215  
   216  unsigned int bcma_core_irq(struct bcma_device *core, int num)

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


.config.gz
Description: Binary data

[PATCH v2 6/6] x86/pat: Document PAT initializations

2016-03-19 Thread Toshi Kani

Update PAT documentation to describe how PAT is initialized under
various configurations.

Signed-off-by: Toshi Kani 
Cc: Borislav Petkov 
Cc: Luis R. Rodriguez 
Cc: Juergen Gross 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Thomas Gleixner 
---
 Documentation/x86/pat.txt |   32 
 1 file changed, 32 insertions(+)

diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index 54944c7..f619e1d 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -196,3 +196,35 @@ Another, more verbose way of getting PAT related debug 
messages is with
 "debugpat" boot parameter. With this parameter, various debug messages are
 printed to dmesg log.
 
+PAT Initialization
+--
+
+The following table describes how PAT is initialized under various
+configurations. PAT must be set to enable to initialize PAT MSR in order
+to support WC and WT attributes. Otherwise, PAT keeps PAT MSR value set
+by BIOS. Note, Xen enables WC attribute in BIOS setup for guests.
+
+ MTRR PAT   Call Sequence   PAT State  PAT MSR
+ =
+ EE MTRR -> pat_init()  Enable OS
+ ED MTRR -> pat_init()  Disable-
+ DE MTRR -> pat_disable()   DisableBIOS
+ DD MTRR -> pat_disable()   Disable-
+ -np/E  nopat() -> pat_disable()DisableBIOS
+ -np/D  nopat() -> pat_disable()Disable-
+ E!P/E  MTRR -> pat_init()  DisableBIOS
+ D!P/E  MTRR -> pat_disable()   DisableBIOS
+ !M   !P/E  MTRR stub -> pat_disable()  DisableBIOS
+
+ Legend
+ 
+ EFeature enabled in CPU
+ D   Feature disabled/unsupported in CPU
+ np  "nopat" boot option specified
+ !P  CONFIG_X86_PAT option unset
+ !M  CONFIG_MTRR option unset
+ Enable   PAT state set to enable
+ Disable  PAT state set to disable
+ OS   PAT initializes PAT MSR with OS setup
+ BIOS PAT keeps PAT MSR with BIOS setup
+

[PATCH v2 6/6] x86/pat: Document PAT initializations

2016-03-19 Thread Toshi Kani

Update PAT documentation to describe how PAT is initialized under
various configurations.

Signed-off-by: Toshi Kani 
Cc: Borislav Petkov 
Cc: Luis R. Rodriguez 
Cc: Juergen Gross 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Thomas Gleixner 
---
 Documentation/x86/pat.txt |   32 
 1 file changed, 32 insertions(+)

diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index 54944c7..f619e1d 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -196,3 +196,35 @@ Another, more verbose way of getting PAT related debug 
messages is with
 "debugpat" boot parameter. With this parameter, various debug messages are
 printed to dmesg log.
 
+PAT Initialization
+--
+
+The following table describes how PAT is initialized under various
+configurations. PAT must be set to enable to initialize PAT MSR in order
+to support WC and WT attributes. Otherwise, PAT keeps PAT MSR value set
+by BIOS. Note, Xen enables WC attribute in BIOS setup for guests.
+
+ MTRR PAT   Call Sequence   PAT State  PAT MSR
+ =
+ EE MTRR -> pat_init()  Enable OS
+ ED MTRR -> pat_init()  Disable-
+ DE MTRR -> pat_disable()   DisableBIOS
+ DD MTRR -> pat_disable()   Disable-
+ -np/E  nopat() -> pat_disable()DisableBIOS
+ -np/D  nopat() -> pat_disable()Disable-
+ E!P/E  MTRR -> pat_init()  DisableBIOS
+ D!P/E  MTRR -> pat_disable()   DisableBIOS
+ !M   !P/E  MTRR stub -> pat_disable()  DisableBIOS
+
+ Legend
+ 
+ EFeature enabled in CPU
+ D   Feature disabled/unsupported in CPU
+ np  "nopat" boot option specified
+ !P  CONFIG_X86_PAT option unset
+ !M  CONFIG_MTRR option unset
+ Enable   PAT state set to enable
+ Disable  PAT state set to disable
+ OS   PAT initializes PAT MSR with OS setup
+ BIOS PAT keeps PAT MSR with BIOS setup
+

[RESEND] [PATCH v11 5/6] add TC G210 platform driver

2016-03-19 Thread Joao Pinto

This patch adds a glue platform driver for the Synopsys G210 Test Chip.

Signed-off-by: Joao Pinto 
---
Changes v10->v11 (Arnd Bergmann):
- vops structs are now passed in .data
Changes v0->v10:
- This patch only appeared in v10

 .../devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt |  26 +
 drivers/scsi/ufs/Kconfig   |   9 ++
 drivers/scsi/ufs/Makefile  |   1 +
 drivers/scsi/ufs/tc-dwc-g210-pltfrm.c  | 113 +
 4 files changed, 149 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt
 create mode 100644 drivers/scsi/ufs/tc-dwc-g210-pltfrm.c

diff --git a/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt 
b/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt
new file mode 100644
index 000..6ec9647
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt
@@ -0,0 +1,26 @@
+* Universal Flash Storage (UFS) DesignWare Host Controller
+
+DWC_UFS nodes are defined to describe on-chip UFS host controllers and MPHY.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible   : compatible list must contain the PHY type & version:
+   "snps, g210-tc-6.00-20bit"
+   "snps, g210-tc-6.00-40bit"
+ complemented with the Controller IP version:
+   "snps, dwc-ufshcd-1.40a"
+ complemented with the JEDEC version:
+   "jedec,ufs-1.1"
+   "jedec,ufs-2.0"
+
+- reg  : 
+- interrupts   : 
+
+Example for a setup using a 1.40a DWC Controller with a 6.00 G210 40-bit TC:
+   dwc_ufs@d000 {
+   compatible = "snps, g210-tc-6.00-40bit",
+"snps, dwc-ufshcd-1.40a",
+"jedec,ufs-2.0";
+   reg = < 0xd000 0x1 >;
+   interrupts = < 24 >;
+   };
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 9d218f9..5cfa87b 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -90,3 +90,12 @@ config SCSI_UFS_DWC
 config SCSI_UFS_DWC_TC
bool
select SCSI_UFS_DWC
+
+config SCSI_UFS_DWC_TC_PLATFORM
+   tristate "DesignWare platform support using a G210 Test Chip"
+   depends on SCSI_UFSHCD_PLATFORM
+   select SCSI_UFS_DWC_TC
+   ---help---
+ Synopsys Test Chip is a PHY for prototyping purposes.
+
+ If unsure, say N."
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 9468d7b..a977fe0 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,6 +1,7 @@
 # UFSHCD makefile
 obj-$(CONFIG_SCSI_UFS_DWC) += ufshcd-dwc.o
 obj-$(CONFIG_SCSI_UFS_DWC_TC) += tc-dwc-g210.o
+obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o
 obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
 obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
 obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pltfrm.c 
b/drivers/scsi/ufs/tc-dwc-g210-pltfrm.c
new file mode 100644
index 000..9bffb98
--- /dev/null
+++ b/drivers/scsi/ufs/tc-dwc-g210-pltfrm.c
@@ -0,0 +1,113 @@
+/*
+ * Synopsys G210 Test Chip driver
+ *
+ * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * Authors: Joao Pinto 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ufshcd-pltfrm.h"
+#include "ufshcd-dwc.h"
+#include "tc-dwc-g210.h"
+
+/**
+ * UFS DWC specific variant operations
+ */
+static struct ufs_hba_variant_ops tc_dwc_g210_20bit_pltfm_hba_vops = {
+   .name   = "tc-dwc-g210-pltfm",
+   .link_startup_notify= ufshcd_dwc_link_startup_notify,
+   .custom_phy_initialization = tc_dwc_g210_config_20_bit,
+};
+
+static struct ufs_hba_variant_ops tc_dwc_g210_40bit_pltfm_hba_vops = {
+   .name   = "tc-dwc-g210-pltfm",
+   .link_startup_notify= ufshcd_dwc_link_startup_notify,
+   .custom_phy_initialization = tc_dwc_g210_config_40_bit,
+};
+
+static const struct of_device_id tc_dwc_g210_pltfm_match[] = {
+   {
+   .compatible = "snps, g210-tc-6.00-20bit",
+   .data = _dwc_g210_20bit_pltfm_hba_vops,
+   },
+   {
+   .compatible = "snps, g210-tc-6.00-40bit",
+   .data = _dwc_g210_40bit_pltfm_hba_vops,
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, tc_dwc_g210_pltfm_match);
+
+/**
+ * tc_dwc_g210_pltfm_probe()
+ * @pdev: pointer to platform device structure
+ *
+ */
+static int tc_dwc_g210_pltfm_probe(struct platform_device *pdev)
+{
+   int err;
+   const struct of_device_id *of_id;
+   struct ufs_hba_variant_ops *vops;
+

[PATCH 01/15] ARM: tegra: Correct interrupt type for ARM TWD

2016-03-19 Thread Jon Hunter

The ARM TWD interrupt is a private peripheral interrupt (PPI) and per
the ARM GIC documentation, whether the type for PPIs can be set is
IMPLEMENTATION DEFINED. For Tegra20/30 devices the PPI type cannot be
set and so when we attempt to set the type for the ARM TWD interrupt it
fails. This has done unnoticed because it fails silently and because we
cannot re-configure the type it has had no impact. Nevertheless fix the
type for the TWD interrupt so that it matches the hardware configuration.

Signed-off-by: Jon Hunter 

---
Ideally, we would not be attempting to set the type for an interrupt
where it cannot be programmed but this would require changes to the
device-tree bindings for the GIC. This series adds a WARNING to catch
any of these silent failures.
---
 arch/arm/boot/dts/tegra20.dtsi | 2 +-
 arch/arm/boot/dts/tegra30.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 8fb61b93c226..2207c08e3fa3 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -145,7 +145,7 @@
interrupt-parent = <>;
reg = <0x50040600 0x20>;
interrupts = ;
+   (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>;
clocks = <_car TEGRA20_CLK_TWD>;
};
 
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index c6edc8cea34e..5030065cbdfe 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -230,7 +230,7 @@
reg = <0x50040600 0x20>;
interrupt-parent = <>;
interrupts = ;
+   (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_EDGE_RISING)>;
clocks = <_car TEGRA30_CLK_TWD>;
};
 
-- 
2.1.4

[PATCH 01/15] ARM: tegra: Correct interrupt type for ARM TWD

2016-03-19 Thread Jon Hunter

The ARM TWD interrupt is a private peripheral interrupt (PPI) and per
the ARM GIC documentation, whether the type for PPIs can be set is
IMPLEMENTATION DEFINED. For Tegra20/30 devices the PPI type cannot be
set and so when we attempt to set the type for the ARM TWD interrupt it
fails. This has done unnoticed because it fails silently and because we
cannot re-configure the type it has had no impact. Nevertheless fix the
type for the TWD interrupt so that it matches the hardware configuration.

Signed-off-by: Jon Hunter 

---
Ideally, we would not be attempting to set the type for an interrupt
where it cannot be programmed but this would require changes to the
device-tree bindings for the GIC. This series adds a WARNING to catch
any of these silent failures.
---
 arch/arm/boot/dts/tegra20.dtsi | 2 +-
 arch/arm/boot/dts/tegra30.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 8fb61b93c226..2207c08e3fa3 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -145,7 +145,7 @@
interrupt-parent = <>;
reg = <0x50040600 0x20>;
interrupts = ;
+   (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_EDGE_RISING)>;
clocks = <_car TEGRA20_CLK_TWD>;
};
 
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index c6edc8cea34e..5030065cbdfe 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -230,7 +230,7 @@
reg = <0x50040600 0x20>;
interrupt-parent = <>;
interrupts = ;
+   (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_EDGE_RISING)>;
clocks = <_car TEGRA30_CLK_TWD>;
};
 
-- 
2.1.4

[RESEND] [PATCH v11 5/6] add TC G210 platform driver

2016-03-19 Thread Joao Pinto

This patch adds a glue platform driver for the Synopsys G210 Test Chip.

Signed-off-by: Joao Pinto 
---
Changes v10->v11 (Arnd Bergmann):
- vops structs are now passed in .data
Changes v0->v10:
- This patch only appeared in v10

 .../devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt |  26 +
 drivers/scsi/ufs/Kconfig   |   9 ++
 drivers/scsi/ufs/Makefile  |   1 +
 drivers/scsi/ufs/tc-dwc-g210-pltfrm.c  | 113 +
 4 files changed, 149 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt
 create mode 100644 drivers/scsi/ufs/tc-dwc-g210-pltfrm.c

diff --git a/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt 
b/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt
new file mode 100644
index 000..6ec9647
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt
@@ -0,0 +1,26 @@
+* Universal Flash Storage (UFS) DesignWare Host Controller
+
+DWC_UFS nodes are defined to describe on-chip UFS host controllers and MPHY.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible   : compatible list must contain the PHY type & version:
+   "snps, g210-tc-6.00-20bit"
+   "snps, g210-tc-6.00-40bit"
+ complemented with the Controller IP version:
+   "snps, dwc-ufshcd-1.40a"
+ complemented with the JEDEC version:
+   "jedec,ufs-1.1"
+   "jedec,ufs-2.0"
+
+- reg  : 
+- interrupts   : 
+
+Example for a setup using a 1.40a DWC Controller with a 6.00 G210 40-bit TC:
+   dwc_ufs@d000 {
+   compatible = "snps, g210-tc-6.00-40bit",
+"snps, dwc-ufshcd-1.40a",
+"jedec,ufs-2.0";
+   reg = < 0xd000 0x1 >;
+   interrupts = < 24 >;
+   };
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 9d218f9..5cfa87b 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -90,3 +90,12 @@ config SCSI_UFS_DWC
 config SCSI_UFS_DWC_TC
bool
select SCSI_UFS_DWC
+
+config SCSI_UFS_DWC_TC_PLATFORM
+   tristate "DesignWare platform support using a G210 Test Chip"
+   depends on SCSI_UFSHCD_PLATFORM
+   select SCSI_UFS_DWC_TC
+   ---help---
+ Synopsys Test Chip is a PHY for prototyping purposes.
+
+ If unsure, say N."
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 9468d7b..a977fe0 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,6 +1,7 @@
 # UFSHCD makefile
 obj-$(CONFIG_SCSI_UFS_DWC) += ufshcd-dwc.o
 obj-$(CONFIG_SCSI_UFS_DWC_TC) += tc-dwc-g210.o
+obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o
 obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
 obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
 obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
diff --git a/drivers/scsi/ufs/tc-dwc-g210-pltfrm.c 
b/drivers/scsi/ufs/tc-dwc-g210-pltfrm.c
new file mode 100644
index 000..9bffb98
--- /dev/null
+++ b/drivers/scsi/ufs/tc-dwc-g210-pltfrm.c
@@ -0,0 +1,113 @@
+/*
+ * Synopsys G210 Test Chip driver
+ *
+ * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * Authors: Joao Pinto 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ufshcd-pltfrm.h"
+#include "ufshcd-dwc.h"
+#include "tc-dwc-g210.h"
+
+/**
+ * UFS DWC specific variant operations
+ */
+static struct ufs_hba_variant_ops tc_dwc_g210_20bit_pltfm_hba_vops = {
+   .name   = "tc-dwc-g210-pltfm",
+   .link_startup_notify= ufshcd_dwc_link_startup_notify,
+   .custom_phy_initialization = tc_dwc_g210_config_20_bit,
+};
+
+static struct ufs_hba_variant_ops tc_dwc_g210_40bit_pltfm_hba_vops = {
+   .name   = "tc-dwc-g210-pltfm",
+   .link_startup_notify= ufshcd_dwc_link_startup_notify,
+   .custom_phy_initialization = tc_dwc_g210_config_40_bit,
+};
+
+static const struct of_device_id tc_dwc_g210_pltfm_match[] = {
+   {
+   .compatible = "snps, g210-tc-6.00-20bit",
+   .data = _dwc_g210_20bit_pltfm_hba_vops,
+   },
+   {
+   .compatible = "snps, g210-tc-6.00-40bit",
+   .data = _dwc_g210_40bit_pltfm_hba_vops,
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, tc_dwc_g210_pltfm_match);
+
+/**
+ * tc_dwc_g210_pltfm_probe()
+ * @pdev: pointer to platform device structure
+ *
+ */
+static int tc_dwc_g210_pltfm_probe(struct platform_device *pdev)
+{
+   int err;
+   const struct of_device_id *of_id;
+   struct ufs_hba_variant_ops *vops;
+   struct device *dev = >dev;
+
+

Re: [PATCH 1/2] mm/vmap: Add a notifier for when we run out of vmap address space

2016-03-19 Thread Roman Peniaev

On Thu, Mar 17, 2016 at 1:57 PM, Chris Wilson  wrote:
> On Thu, Mar 17, 2016 at 01:37:06PM +0100, Roman Peniaev wrote:
>> > +   freed = 0;
>> > +   blocking_notifier_call_chain(_notify_list, 0, );
>>
>> It seems to me that alloc_vmap_area() was designed not to sleep,
>> at least on GFP_NOWAIT path (__GFP_DIRECT_RECLAIM is not set).
>>
>> But blocking_notifier_call_chain() might sleep.
>
> Indeed, I had not anticipated anybody using GFP_ATOMIC or equivalently
> restrictive gfp_t for vmap and yes there are such callers.
>
> Would guarding the notifier with gfp & __GFP_DIRECT_RECLAIM and
> !(gfp & __GFP_NORETRY) == be sufficient? Is that enough for GFP_NOFS?

I would use gfpflags_allow_blocking() for that purpose.

Roman

Re: [PATCH 1/2] mm/vmap: Add a notifier for when we run out of vmap address space

2016-03-19 Thread Roman Peniaev

On Thu, Mar 17, 2016 at 1:57 PM, Chris Wilson  wrote:
> On Thu, Mar 17, 2016 at 01:37:06PM +0100, Roman Peniaev wrote:
>> > +   freed = 0;
>> > +   blocking_notifier_call_chain(_notify_list, 0, );
>>
>> It seems to me that alloc_vmap_area() was designed not to sleep,
>> at least on GFP_NOWAIT path (__GFP_DIRECT_RECLAIM is not set).
>>
>> But blocking_notifier_call_chain() might sleep.
>
> Indeed, I had not anticipated anybody using GFP_ATOMIC or equivalently
> restrictive gfp_t for vmap and yes there are such callers.
>
> Would guarding the notifier with gfp & __GFP_DIRECT_RECLAIM and
> !(gfp & __GFP_NORETRY) == be sufficient? Is that enough for GFP_NOFS?

I would use gfpflags_allow_blocking() for that purpose.

Roman

[PART1 RFC v3 12/12] svm: Manage vcpu load/unload when enable AVIC

2016-03-19 Thread Suravee Suthikulpanit

From: Suravee Suthikulpanit 

When a vcpu is loaded/unloaded to a physical core, we need to update
host physical APIC ID information in the Physical APIC-ID table
accordingly.

Also, when vCPU is blocking/un-blocking (due to halt instruction),
we need to make sure that the is-running bit in set accordingly in the
physical APIC-ID table.

Signed-off-by: Suravee Suthikulpanit 
---
 arch/x86/kvm/svm.c | 121 +
 1 file changed, 121 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index d5418c3..c5e8100 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -1334,6 +1335,110 @@ free_avic:
return err;
 }
 
+static int avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu, bool is_load)
+{
+   int h_phy_apic_id;
+   u64 *entry, new_entry;
+   struct vcpu_svm *svm = to_svm(vcpu);
+   int ret = 0;
+
+   if (!svm_vcpu_avic_enabled(svm))
+   return 0;
+
+   if (!svm)
+   return -EINVAL;
+
+   /* Note: APIC ID = 0xff is used for broadcast.
+*   APIC ID > 0xff is reserved.
+*/
+   h_phy_apic_id = __default_cpu_present_to_apicid(cpu);
+
+   if (h_phy_apic_id >= AVIC_PHY_APIC_ID_MAX)
+   return -EINVAL;
+
+   entry = svm->avic_phy_apic_id_cache;
+   if (!entry)
+   return -EINVAL;
+
+   if (is_load) {
+   new_entry = READ_ONCE(*entry);
+
+   BUG_ON(new_entry & AVIC_PHY_APIC_ID__IS_RUN_MSK);
+
+   new_entry &= ~AVIC_PHY_APIC_ID__HOST_PHY_APIC_ID_MSK;
+   new_entry |= (h_phy_apic_id & 
AVIC_PHY_APIC_ID__HOST_PHY_APIC_ID_MSK);
+
+   /**
+* Restore AVIC running flag if it was set during
+* vcpu unload.
+*/
+   if (svm->avic_was_running)
+   new_entry |= AVIC_PHY_APIC_ID__IS_RUN_MSK;
+   else
+   new_entry &= ~AVIC_PHY_APIC_ID__IS_RUN_MSK;
+
+   WRITE_ONCE(*entry, new_entry);
+
+   } else {
+   new_entry = READ_ONCE(*entry);
+
+   /**
+* This handles the case when vcpu is scheduled out
+* and has not yet not called blocking. We save the
+* AVIC running flag so that we can restore later.
+*/
+   if (new_entry & AVIC_PHY_APIC_ID__IS_RUN_MSK) {
+   svm->avic_was_running = true;
+   new_entry &= ~AVIC_PHY_APIC_ID__IS_RUN_MSK;
+   WRITE_ONCE(*entry, new_entry);
+   } else {
+   svm->avic_was_running = false;
+   }
+   }
+
+   return ret;
+}
+
+/**
+ * This function is called during VCPU halt/unhalt.
+ */
+static int avic_set_running(struct kvm_vcpu *vcpu, bool is_run)
+{
+   int ret = 0;
+   int h_phy_apic_id;
+   u64 *entry, new_entry;
+   struct vcpu_svm *svm = to_svm(vcpu);
+
+   if (!svm_vcpu_avic_enabled(svm))
+   return 0;
+
+   /* Note: APIC ID = 0xff is used for broadcast.
+*   APIC ID > 0xff is reserved.
+*/
+   h_phy_apic_id = __default_cpu_present_to_apicid(vcpu->cpu);
+
+   if (h_phy_apic_id >= AVIC_PHY_APIC_ID_MAX)
+   return -EINVAL;
+
+   entry = svm->avic_phy_apic_id_cache;
+   if (!entry)
+   return -EINVAL;
+
+   if (is_run) {
+   /* Handle vcpu unblocking after HLT */
+   new_entry = READ_ONCE(*entry);
+   new_entry |= AVIC_PHY_APIC_ID__IS_RUN_MSK;
+   WRITE_ONCE(*entry, new_entry);
+   } else {
+   /* Handle vcpu blocking due to HLT */
+   new_entry = READ_ONCE(*entry);
+   new_entry &= ~AVIC_PHY_APIC_ID__IS_RUN_MSK;
+   WRITE_ONCE(*entry, new_entry);
+   }
+
+   return ret;
+}
+
 static void svm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
 {
struct vcpu_svm *svm = to_svm(vcpu);
@@ -1476,6 +1581,8 @@ static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
/* This assumes that the kernel never uses MSR_TSC_AUX */
if (static_cpu_has(X86_FEATURE_RDTSCP))
wrmsrl(MSR_TSC_AUX, svm->tsc_aux);
+
+   avic_vcpu_load(vcpu, cpu, true);
 }
 
 static void svm_vcpu_put(struct kvm_vcpu *vcpu)
@@ -1483,6 +1590,8 @@ static void svm_vcpu_put(struct kvm_vcpu *vcpu)
struct vcpu_svm *svm = to_svm(vcpu);
int i;
 
+   avic_vcpu_load(vcpu, 0, false);
+
++vcpu->stat.host_state_reload;
kvm_load_ldt(svm->host.ldt);
 #ifdef CONFIG_X86_64
@@ -1498,6 +1607,16 @@ static void svm_vcpu_put(struct kvm_vcpu *vcpu)
wrmsrl(host_save_user_msrs[i], svm->host_user_msrs[i]);
 }
 
+static void svm_vcpu_blocking(struct

Re: linux-next: manual merge of the rdma tree with the net-next tree

2016-03-19 Thread Linus Torvalds

On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell  wrote:
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Side note: can you change this wording for your manual merge script?
Last merge window (or was it the one before it?) we had confusion with
people who thought that "no action is required" means "you can just
ignore this entirely".

I want people who have known merge issues to at the very least
*mention* them to me when they send the pull request, and I also think
that trees that have merge conflicts that aren't just totally trivial
should also make sure that they have communicated with each other
about why the problem happened.

This is *particularly* true for the complete effing disaster that is
mellanox and rdma-vs-networking.

So please don't say "no action is required". Please make it clear that
there may not be any further action needed for linux-next itself, but
that other action may certainly be required.

Because I'm very close to not taking any rdma changes that touch
networking any more. Ever.

The Mellanox people are on my shit-list until they show that they can
actually act like responsible people and not just monkeys throwing
shit at the walls.

"No action required" is simply not true for Mellanox.

 Linus

[PART1 RFC v3 12/12] svm: Manage vcpu load/unload when enable AVIC

2016-03-19 Thread Suravee Suthikulpanit

From: Suravee Suthikulpanit 

When a vcpu is loaded/unloaded to a physical core, we need to update
host physical APIC ID information in the Physical APIC-ID table
accordingly.

Also, when vCPU is blocking/un-blocking (due to halt instruction),
we need to make sure that the is-running bit in set accordingly in the
physical APIC-ID table.

Signed-off-by: Suravee Suthikulpanit 
---
 arch/x86/kvm/svm.c | 121 +
 1 file changed, 121 insertions(+)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index d5418c3..c5e8100 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -1334,6 +1335,110 @@ free_avic:
return err;
 }
 
+static int avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu, bool is_load)
+{
+   int h_phy_apic_id;
+   u64 *entry, new_entry;
+   struct vcpu_svm *svm = to_svm(vcpu);
+   int ret = 0;
+
+   if (!svm_vcpu_avic_enabled(svm))
+   return 0;
+
+   if (!svm)
+   return -EINVAL;
+
+   /* Note: APIC ID = 0xff is used for broadcast.
+*   APIC ID > 0xff is reserved.
+*/
+   h_phy_apic_id = __default_cpu_present_to_apicid(cpu);
+
+   if (h_phy_apic_id >= AVIC_PHY_APIC_ID_MAX)
+   return -EINVAL;
+
+   entry = svm->avic_phy_apic_id_cache;
+   if (!entry)
+   return -EINVAL;
+
+   if (is_load) {
+   new_entry = READ_ONCE(*entry);
+
+   BUG_ON(new_entry & AVIC_PHY_APIC_ID__IS_RUN_MSK);
+
+   new_entry &= ~AVIC_PHY_APIC_ID__HOST_PHY_APIC_ID_MSK;
+   new_entry |= (h_phy_apic_id & 
AVIC_PHY_APIC_ID__HOST_PHY_APIC_ID_MSK);
+
+   /**
+* Restore AVIC running flag if it was set during
+* vcpu unload.
+*/
+   if (svm->avic_was_running)
+   new_entry |= AVIC_PHY_APIC_ID__IS_RUN_MSK;
+   else
+   new_entry &= ~AVIC_PHY_APIC_ID__IS_RUN_MSK;
+
+   WRITE_ONCE(*entry, new_entry);
+
+   } else {
+   new_entry = READ_ONCE(*entry);
+
+   /**
+* This handles the case when vcpu is scheduled out
+* and has not yet not called blocking. We save the
+* AVIC running flag so that we can restore later.
+*/
+   if (new_entry & AVIC_PHY_APIC_ID__IS_RUN_MSK) {
+   svm->avic_was_running = true;
+   new_entry &= ~AVIC_PHY_APIC_ID__IS_RUN_MSK;
+   WRITE_ONCE(*entry, new_entry);
+   } else {
+   svm->avic_was_running = false;
+   }
+   }
+
+   return ret;
+}
+
+/**
+ * This function is called during VCPU halt/unhalt.
+ */
+static int avic_set_running(struct kvm_vcpu *vcpu, bool is_run)
+{
+   int ret = 0;
+   int h_phy_apic_id;
+   u64 *entry, new_entry;
+   struct vcpu_svm *svm = to_svm(vcpu);
+
+   if (!svm_vcpu_avic_enabled(svm))
+   return 0;
+
+   /* Note: APIC ID = 0xff is used for broadcast.
+*   APIC ID > 0xff is reserved.
+*/
+   h_phy_apic_id = __default_cpu_present_to_apicid(vcpu->cpu);
+
+   if (h_phy_apic_id >= AVIC_PHY_APIC_ID_MAX)
+   return -EINVAL;
+
+   entry = svm->avic_phy_apic_id_cache;
+   if (!entry)
+   return -EINVAL;
+
+   if (is_run) {
+   /* Handle vcpu unblocking after HLT */
+   new_entry = READ_ONCE(*entry);
+   new_entry |= AVIC_PHY_APIC_ID__IS_RUN_MSK;
+   WRITE_ONCE(*entry, new_entry);
+   } else {
+   /* Handle vcpu blocking due to HLT */
+   new_entry = READ_ONCE(*entry);
+   new_entry &= ~AVIC_PHY_APIC_ID__IS_RUN_MSK;
+   WRITE_ONCE(*entry, new_entry);
+   }
+
+   return ret;
+}
+
 static void svm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event)
 {
struct vcpu_svm *svm = to_svm(vcpu);
@@ -1476,6 +1581,8 @@ static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
/* This assumes that the kernel never uses MSR_TSC_AUX */
if (static_cpu_has(X86_FEATURE_RDTSCP))
wrmsrl(MSR_TSC_AUX, svm->tsc_aux);
+
+   avic_vcpu_load(vcpu, cpu, true);
 }
 
 static void svm_vcpu_put(struct kvm_vcpu *vcpu)
@@ -1483,6 +1590,8 @@ static void svm_vcpu_put(struct kvm_vcpu *vcpu)
struct vcpu_svm *svm = to_svm(vcpu);
int i;
 
+   avic_vcpu_load(vcpu, 0, false);
+
++vcpu->stat.host_state_reload;
kvm_load_ldt(svm->host.ldt);
 #ifdef CONFIG_X86_64
@@ -1498,6 +1607,16 @@ static void svm_vcpu_put(struct kvm_vcpu *vcpu)
wrmsrl(host_save_user_msrs[i], svm->host_user_msrs[i]);
 }
 
+static void svm_vcpu_blocking(struct kvm_vcpu *vcpu)
+{
+   avic_set_running(vcpu, false);
+}
+

Re: linux-next: manual merge of the rdma tree with the net-next tree

2016-03-19 Thread Linus Torvalds

On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell  wrote:
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Side note: can you change this wording for your manual merge script?
Last merge window (or was it the one before it?) we had confusion with
people who thought that "no action is required" means "you can just
ignore this entirely".

I want people who have known merge issues to at the very least
*mention* them to me when they send the pull request, and I also think
that trees that have merge conflicts that aren't just totally trivial
should also make sure that they have communicated with each other
about why the problem happened.

This is *particularly* true for the complete effing disaster that is
mellanox and rdma-vs-networking.

So please don't say "no action is required". Please make it clear that
there may not be any further action needed for linux-next itself, but
that other action may certainly be required.

Because I'm very close to not taking any rdma changes that touch
networking any more. Ever.

The Mellanox people are on my shit-list until they show that they can
actually act like responsible people and not just monkeys throwing
shit at the walls.

"No action required" is simply not true for Mellanox.

 Linus

[PATCH v2 6/9] efi/arm: libstub: make screen_info accessible to the UEFI stub

2016-03-19 Thread Ard Biesheuvel

In order to hand over the framebuffer described by the GOP protocol and
discovered by the UEFI stub, make struct screen_info accessible by the
stub. This involves allocating a loader data buffer and passing it to the
kernel proper via a UEFI Configuration Table, since the UEFI stub executes
in the context of the decompressor, and cannot access the kernel's copy of
struct screen_info directly.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/include/asm/efi.h|  3 ++
 arch/arm/kernel/setup.c   |  3 +-
 drivers/firmware/efi/arm-init.c   | 30 +++-
 drivers/firmware/efi/efi.c|  5 +--
 drivers/firmware/efi/libstub/arm32-stub.c | 37 
 include/linux/efi.h   | 11 +-
 6 files changed, 84 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
index ce1aa3454ca8..be12877e8609 100644
--- a/arch/arm/include/asm/efi.h
+++ b/arch/arm/include/asm/efi.h
@@ -63,6 +63,9 @@ void efi_virtmap_unload(void);
 #define __efi_call_early(f, ...)   f(__VA_ARGS__)
 #define efi_is_64bit() (false)
 
+struct screen_info *alloc_screen_info(efi_system_table_t *sys_table_arg);
+void free_screen_info(efi_system_table_t *sys_table, struct screen_info *si);
+
 /*
  * A reasonable upper bound for the uncompressed kernel size is 32 MBytes,
  * so we will reserve that amount of memory. We have no easy way to tell what
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 139791ed473d..2916abd6ec01 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -881,7 +881,8 @@ static void __init request_standard_resources(const struct 
machine_desc *mdesc)
request_resource(_resource, );
 }
 
-#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE)
+#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE) || \
+defined(CONFIG_EFI)
 struct screen_info screen_info = {
  .orig_video_lines = 30,
  .orig_video_cols  = 80,
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..acd44de30504 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -11,12 +11,15 @@
  *
  */
 
+#define pr_fmt(fmt)"efi: " fmt
+
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -53,6 +56,28 @@ static phys_addr_t efi_to_phys(unsigned long addr)
return addr;
 }
 
+static __initdata unsigned long screen_info_table = EFI_INVALID_TABLE_ADDR;
+
+static __initdata efi_config_table_type_t arch_tables[] = {
+   {LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID, NULL, _info_table},
+   {NULL_GUID, NULL, NULL}
+};
+
+static void __init init_screen_info(void)
+{
+   struct screen_info *si;
+
+   if (screen_info_table != EFI_INVALID_TABLE_ADDR) {
+   si = early_memremap_ro(screen_info_table, sizeof(*si));
+   if (!si) {
+   pr_err("Could not map screen_info config table\n");
+   return;
+   }
+   screen_info = *si;
+   early_memunmap(si, sizeof(*si));
+   }
+}
+
 static int __init uefi_init(void)
 {
efi_char16_t *c16;
@@ -108,7 +133,8 @@ static int __init uefi_init(void)
goto out;
}
retval = efi_config_parse_tables(config_tables, efi.systab->nr_tables,
-sizeof(efi_config_table_t), NULL);
+sizeof(efi_config_table_t),
+arch_tables);
 
early_memunmap(config_tables, table_size);
 out:
@@ -206,4 +232,6 @@ void __init efi_init(void)
memblock_mark_nomap(params.mmap & PAGE_MASK,
PAGE_ALIGN(params.mmap_size +
   (params.mmap & ~PAGE_MASK)));
+
+   init_screen_info();
 }
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37dad67a6..cb46165a1fec 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -382,8 +382,9 @@ static __init int match_config_table(efi_guid_t *guid,
for (i = 0; efi_guidcmp(table_types[i].guid, NULL_GUID); i++) {
if (!efi_guidcmp(*guid, table_types[i].guid)) {
*(table_types[i].ptr) = table;
-   pr_cont(" %s=0x%lx ",
-   table_types[i].name, table);
+   if (table_types[i].name)
+   pr_cont(" %s=0x%lx ",
+   table_types[i].name, table);
return 1;
}
}
diff --git a/drivers/firmware/efi/libstub/arm32-stub.c 
b/drivers/firmware/efi/libstub/arm32-stub.c
index 495ebd657e38..83feff5e1b6e 100644
---

[PATCH v2 6/9] efi/arm: libstub: make screen_info accessible to the UEFI stub

2016-03-19 Thread Ard Biesheuvel

In order to hand over the framebuffer described by the GOP protocol and
discovered by the UEFI stub, make struct screen_info accessible by the
stub. This involves allocating a loader data buffer and passing it to the
kernel proper via a UEFI Configuration Table, since the UEFI stub executes
in the context of the decompressor, and cannot access the kernel's copy of
struct screen_info directly.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/include/asm/efi.h|  3 ++
 arch/arm/kernel/setup.c   |  3 +-
 drivers/firmware/efi/arm-init.c   | 30 +++-
 drivers/firmware/efi/efi.c|  5 +--
 drivers/firmware/efi/libstub/arm32-stub.c | 37 
 include/linux/efi.h   | 11 +-
 6 files changed, 84 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
index ce1aa3454ca8..be12877e8609 100644
--- a/arch/arm/include/asm/efi.h
+++ b/arch/arm/include/asm/efi.h
@@ -63,6 +63,9 @@ void efi_virtmap_unload(void);
 #define __efi_call_early(f, ...)   f(__VA_ARGS__)
 #define efi_is_64bit() (false)
 
+struct screen_info *alloc_screen_info(efi_system_table_t *sys_table_arg);
+void free_screen_info(efi_system_table_t *sys_table, struct screen_info *si);
+
 /*
  * A reasonable upper bound for the uncompressed kernel size is 32 MBytes,
  * so we will reserve that amount of memory. We have no easy way to tell what
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 139791ed473d..2916abd6ec01 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -881,7 +881,8 @@ static void __init request_standard_resources(const struct 
machine_desc *mdesc)
request_resource(_resource, );
 }
 
-#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE)
+#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE) || \
+defined(CONFIG_EFI)
 struct screen_info screen_info = {
  .orig_video_lines = 30,
  .orig_video_cols  = 80,
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..acd44de30504 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -11,12 +11,15 @@
  *
  */
 
+#define pr_fmt(fmt)"efi: " fmt
+
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -53,6 +56,28 @@ static phys_addr_t efi_to_phys(unsigned long addr)
return addr;
 }
 
+static __initdata unsigned long screen_info_table = EFI_INVALID_TABLE_ADDR;
+
+static __initdata efi_config_table_type_t arch_tables[] = {
+   {LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID, NULL, _info_table},
+   {NULL_GUID, NULL, NULL}
+};
+
+static void __init init_screen_info(void)
+{
+   struct screen_info *si;
+
+   if (screen_info_table != EFI_INVALID_TABLE_ADDR) {
+   si = early_memremap_ro(screen_info_table, sizeof(*si));
+   if (!si) {
+   pr_err("Could not map screen_info config table\n");
+   return;
+   }
+   screen_info = *si;
+   early_memunmap(si, sizeof(*si));
+   }
+}
+
 static int __init uefi_init(void)
 {
efi_char16_t *c16;
@@ -108,7 +133,8 @@ static int __init uefi_init(void)
goto out;
}
retval = efi_config_parse_tables(config_tables, efi.systab->nr_tables,
-sizeof(efi_config_table_t), NULL);
+sizeof(efi_config_table_t),
+arch_tables);
 
early_memunmap(config_tables, table_size);
 out:
@@ -206,4 +232,6 @@ void __init efi_init(void)
memblock_mark_nomap(params.mmap & PAGE_MASK,
PAGE_ALIGN(params.mmap_size +
   (params.mmap & ~PAGE_MASK)));
+
+   init_screen_info();
 }
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37dad67a6..cb46165a1fec 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -382,8 +382,9 @@ static __init int match_config_table(efi_guid_t *guid,
for (i = 0; efi_guidcmp(table_types[i].guid, NULL_GUID); i++) {
if (!efi_guidcmp(*guid, table_types[i].guid)) {
*(table_types[i].ptr) = table;
-   pr_cont(" %s=0x%lx ",
-   table_types[i].name, table);
+   if (table_types[i].name)
+   pr_cont(" %s=0x%lx ",
+   table_types[i].name, table);
return 1;
}
}
diff --git a/drivers/firmware/efi/libstub/arm32-stub.c 
b/drivers/firmware/efi/libstub/arm32-stub.c
index 495ebd657e38..83feff5e1b6e 100644
---

Re: [PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Sinan Kaya

On 3/18/2016 9:51 AM, Sinan Kaya wrote:
> Another option is I can write
> 
>  engine->sram_dma = swiotlb_dma_to_phys(res->start)

I realized that I made a mistake in the commit message and the code above.

The code is trying to find DMA address from physical address. Not the other
way around. I'll fix it on the next version. 

The correct suggestion above would be 

  engine->sram_dma = swiotlb_phys_to_dmares->start)

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

Re: [PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

2016-03-19 Thread Sinan Kaya

On 3/18/2016 9:51 AM, Sinan Kaya wrote:
> Another option is I can write
> 
>  engine->sram_dma = swiotlb_dma_to_phys(res->start)

I realized that I made a mistake in the commit message and the code above.

The code is trying to find DMA address from physical address. Not the other
way around. I'll fix it on the next version. 

The correct suggestion above would be 

  engine->sram_dma = swiotlb_phys_to_dmares->start)

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

Re: linux-next: manual merge of the rdma tree with the net-next tree

2016-03-19 Thread Doug Ledford

On 3/16/2016 1:18 PM, Linus Torvalds wrote:
> On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell  
> wrote:
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
> 
> Side note: can you change this wording for your manual merge script?
> Last merge window (or was it the one before it?) we had confusion with
> people who thought that "no action is required" means "you can just
> ignore this entirely".

I certainly didn't take it that way regardless of the wording.  I'm
keenly aware of the short leash you have Mellanox (and by extension
myself) on.  I reviewed the merge in detail, enough to satisfy myself
that it was easy, correct, and that the code itself made the merge
obvious (such as the comment that flow table entries need to be last in
the lists in order to support priority transitions, which fairly handily
explained what needed to happen in the merge).

signature.asc
Description: OpenPGP digital signature

Re: linux-next: manual merge of the rdma tree with the net-next tree

2016-03-19 Thread Doug Ledford

On 3/16/2016 1:18 PM, Linus Torvalds wrote:
> On Tue, Mar 15, 2016 at 5:58 PM, Stephen Rothwell  
> wrote:
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
> 
> Side note: can you change this wording for your manual merge script?
> Last merge window (or was it the one before it?) we had confusion with
> people who thought that "no action is required" means "you can just
> ignore this entirely".

I certainly didn't take it that way regardless of the wording.  I'm
keenly aware of the short leash you have Mellanox (and by extension
myself) on.  I reviewed the merge in detail, enough to satisfy myself
that it was easy, correct, and that the code itself made the merge
obvious (such as the comment that flow table entries need to be last in
the lists in order to support priority transitions, which fairly handily
explained what needed to happen in the merge).

signature.asc
Description: OpenPGP digital signature

[PATCH v5 4/4] ARM: STM32: Enable Ethernet in stm32_defconfig

2016-03-19 Thread Alexandre TORGUE

Enable basic Ethernet support (IPV4) for stm32 defconfig.

Signed-off-by: Alexandre TORGUE 

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index ec52505..8b8abe0 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -33,11 +33,20 @@ CONFIG_XIP_PHYS_ADDR=0x08008000
 CONFIG_BINFMT_FLAT=y
 CONFIG_BINFMT_SHARED_FLAT=y
 # CONFIG_COREDUMP is not set
+CONFIG_NET=y
+CONFIG_INET=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_IPV6 is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
 # CONFIG_BLK_DEV is not set
 CONFIG_EEPROM_93CX6=y
+CONFIG_NETDEVICES=y
+CONFIG_STMMAC_ETH=y
+# CONFIG_WLAN is not set
 # CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set
-- 
1.9.1

[PATCH v5 4/4] ARM: STM32: Enable Ethernet in stm32_defconfig

2016-03-19 Thread Alexandre TORGUE

Enable basic Ethernet support (IPV4) for stm32 defconfig.

Signed-off-by: Alexandre TORGUE 

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index ec52505..8b8abe0 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -33,11 +33,20 @@ CONFIG_XIP_PHYS_ADDR=0x08008000
 CONFIG_BINFMT_FLAT=y
 CONFIG_BINFMT_SHARED_FLAT=y
 # CONFIG_COREDUMP is not set
+CONFIG_NET=y
+CONFIG_INET=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_IPV6 is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
 # CONFIG_BLK_DEV is not set
 CONFIG_EEPROM_93CX6=y
+CONFIG_NETDEVICES=y
+CONFIG_STMMAC_ETH=y
+# CONFIG_WLAN is not set
 # CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set
-- 
1.9.1

Re: [PATCH 1/2] pinctrl: sh-pfc: enable to indicate GPSR/IPSR/MOD_SEL for debug

2016-03-19 Thread Kuninori Morimoto


Hi Laurent, Geert

> >  struct pinmux_cfg_reg {
> > +   const char *name;
> 
> This will increase the kernel size, I would remove the name field when 
> compiling the kernel in non-debug mode. You could use CONFIG_DYNAMIC_DEBUG or 
> CONFIG_DEBUG_PINCTRL.

OK, [1/2] patch is not a big deal.
I'm happy if [2/2] was accepted.

Re: [PATCH 1/2] pinctrl: sh-pfc: enable to indicate GPSR/IPSR/MOD_SEL for debug

2016-03-19 Thread Kuninori Morimoto


Hi Laurent, Geert

> >  struct pinmux_cfg_reg {
> > +   const char *name;
> 
> This will increase the kernel size, I would remove the name field when 
> compiling the kernel in non-debug mode. You could use CONFIG_DYNAMIC_DEBUG or 
> CONFIG_DEBUG_PINCTRL.

OK, [1/2] patch is not a big deal.
I'm happy if [2/2] was accepted.

[PATCH v2] net: smc911x: convert pxa dma to dmaengine

2016-03-19 Thread Robert Jarzmik

Convert the dma transfers to be dmaengine based, now pxa has a dmaengine
slave driver. This makes this driver a bit more PXA agnostic.

The driver was only compile tested. The risk is quite small as no
current PXA platform I'm aware of is using smc911x driver.

Signed-off-by: Robert Jarzmik 
Tested-by: Fabio Estevam 
---
Since v1: added Fabio's Tested-by
---
 drivers/net/ethernet/smsc/smc911x.c | 85 -
 drivers/net/ethernet/smsc/smc911x.h | 63 ---
 2 files changed, 82 insertions(+), 66 deletions(-)

diff --git a/drivers/net/ethernet/smsc/smc911x.c 
b/drivers/net/ethernet/smsc/smc911x.c
index bd64eb982e52..3f5711061432 100644
--- a/drivers/net/ethernet/smsc/smc911x.c
+++ b/drivers/net/ethernet/smsc/smc911x.c
@@ -73,6 +73,9 @@ static const char version[] =
 #include 
 #include 
 
+#include 
+#include 
+
 #include 
 
 #include "smc911x.h"
@@ -1174,18 +1177,16 @@ static irqreturn_t smc911x_interrupt(int irq, void 
*dev_id)
 
 #ifdef SMC_USE_DMA
 static void
-smc911x_tx_dma_irq(int dma, void *data)
+smc911x_tx_dma_irq(void *data)
 {
-   struct net_device *dev = (struct net_device *)data;
-   struct smc911x_local *lp = netdev_priv(dev);
+   struct smc911x_local *lp = data;
+   struct net_device *dev = lp->netdev;
struct sk_buff *skb = lp->current_tx_skb;
unsigned long flags;
 
DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
 
DBG(SMC_DEBUG_TX | SMC_DEBUG_DMA, dev, "TX DMA irq handler\n");
-   /* Clear the DMA interrupt sources */
-   SMC_DMA_ACK_IRQ(dev, dma);
BUG_ON(skb == NULL);
dma_unmap_single(NULL, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
dev->trans_start = jiffies;
@@ -1208,18 +1209,16 @@ smc911x_tx_dma_irq(int dma, void *data)
"TX DMA irq completed\n");
 }
 static void
-smc911x_rx_dma_irq(int dma, void *data)
+smc911x_rx_dma_irq(void *data)
 {
-   struct net_device *dev = (struct net_device *)data;
-   struct smc911x_local *lp = netdev_priv(dev);
+   struct smc911x_local *lp = data;
+   struct net_device *dev = lp->netdev;
struct sk_buff *skb = lp->current_rx_skb;
unsigned long flags;
unsigned int pkts;
 
DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
DBG(SMC_DEBUG_RX | SMC_DEBUG_DMA, dev, "RX DMA irq handler\n");
-   /* Clear the DMA interrupt sources */
-   SMC_DMA_ACK_IRQ(dev, dma);
dma_unmap_single(NULL, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
BUG_ON(skb == NULL);
lp->current_rx_skb = NULL;
@@ -1792,6 +1791,9 @@ static int smc911x_probe(struct net_device *dev)
unsigned int val, chip_id, revision;
const char *version_string;
unsigned long irq_flags;
+   struct dma_slave_config config;
+   dma_cap_mask_t mask;
+   struct pxad_param param;
 
DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
 
@@ -1963,11 +1965,40 @@ static int smc911x_probe(struct net_device *dev)
goto err_out;
 
 #ifdef SMC_USE_DMA
-   lp->rxdma = SMC_DMA_REQUEST(dev, smc911x_rx_dma_irq);
-   lp->txdma = SMC_DMA_REQUEST(dev, smc911x_tx_dma_irq);
+
+   dma_cap_zero(mask);
+   dma_cap_set(DMA_SLAVE, mask);
+   param.prio = PXAD_PRIO_LOWEST;
+   param.drcmr = -1UL;
+
+   lp->rxdma =
+   dma_request_slave_channel_compat(mask, pxad_filter_fn,
+, >dev, "rx");
+   lp->txdma =
+   dma_request_slave_channel_compat(mask, pxad_filter_fn,
+, >dev, "tx");
lp->rxdma_active = 0;
lp->txdma_active = 0;
-   dev->dma = lp->rxdma;
+
+   memset(, 0, sizeof(config));
+   config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   config.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   config.src_addr = lp->physaddr + RX_DATA_FIFO;
+   config.dst_addr = lp->physaddr + TX_DATA_FIFO;
+   config.src_maxburst = 32;
+   config.dst_maxburst = 32;
+   retval = dmaengine_slave_config(lp->rxdma, );
+   if (retval) {
+   dev_err(lp->dev, "dma rx channel configuration failed: %d\n",
+   retval);
+   goto err_out;
+   }
+   retval = dmaengine_slave_config(lp->txdma, );
+   if (retval) {
+   dev_err(lp->dev, "dma tx channel configuration failed: %d\n",
+   retval);
+   goto err_out;
+   }
 #endif
 
retval = register_netdev(dev);
@@ -1978,11 +2009,11 @@ static int smc911x_probe(struct net_device *dev)
dev->base_addr, dev->irq);
 
 #ifdef SMC_USE_DMA
-   if (lp->rxdma != -1)
-   pr_cont(" RXDMA %d", lp->rxdma);
+   if (lp->rxdma)
+   pr_cont(" RXDMA %p", lp->rxdma);
 
-   if (lp->txdma != -1)
-   pr_cont("

[PATCH v2] net: smc911x: convert pxa dma to dmaengine

2016-03-19 Thread Robert Jarzmik

Convert the dma transfers to be dmaengine based, now pxa has a dmaengine
slave driver. This makes this driver a bit more PXA agnostic.

The driver was only compile tested. The risk is quite small as no
current PXA platform I'm aware of is using smc911x driver.

Signed-off-by: Robert Jarzmik 
Tested-by: Fabio Estevam 
---
Since v1: added Fabio's Tested-by
---
 drivers/net/ethernet/smsc/smc911x.c | 85 -
 drivers/net/ethernet/smsc/smc911x.h | 63 ---
 2 files changed, 82 insertions(+), 66 deletions(-)

diff --git a/drivers/net/ethernet/smsc/smc911x.c 
b/drivers/net/ethernet/smsc/smc911x.c
index bd64eb982e52..3f5711061432 100644
--- a/drivers/net/ethernet/smsc/smc911x.c
+++ b/drivers/net/ethernet/smsc/smc911x.c
@@ -73,6 +73,9 @@ static const char version[] =
 #include 
 #include 
 
+#include 
+#include 
+
 #include 
 
 #include "smc911x.h"
@@ -1174,18 +1177,16 @@ static irqreturn_t smc911x_interrupt(int irq, void 
*dev_id)
 
 #ifdef SMC_USE_DMA
 static void
-smc911x_tx_dma_irq(int dma, void *data)
+smc911x_tx_dma_irq(void *data)
 {
-   struct net_device *dev = (struct net_device *)data;
-   struct smc911x_local *lp = netdev_priv(dev);
+   struct smc911x_local *lp = data;
+   struct net_device *dev = lp->netdev;
struct sk_buff *skb = lp->current_tx_skb;
unsigned long flags;
 
DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
 
DBG(SMC_DEBUG_TX | SMC_DEBUG_DMA, dev, "TX DMA irq handler\n");
-   /* Clear the DMA interrupt sources */
-   SMC_DMA_ACK_IRQ(dev, dma);
BUG_ON(skb == NULL);
dma_unmap_single(NULL, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
dev->trans_start = jiffies;
@@ -1208,18 +1209,16 @@ smc911x_tx_dma_irq(int dma, void *data)
"TX DMA irq completed\n");
 }
 static void
-smc911x_rx_dma_irq(int dma, void *data)
+smc911x_rx_dma_irq(void *data)
 {
-   struct net_device *dev = (struct net_device *)data;
-   struct smc911x_local *lp = netdev_priv(dev);
+   struct smc911x_local *lp = data;
+   struct net_device *dev = lp->netdev;
struct sk_buff *skb = lp->current_rx_skb;
unsigned long flags;
unsigned int pkts;
 
DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
DBG(SMC_DEBUG_RX | SMC_DEBUG_DMA, dev, "RX DMA irq handler\n");
-   /* Clear the DMA interrupt sources */
-   SMC_DMA_ACK_IRQ(dev, dma);
dma_unmap_single(NULL, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
BUG_ON(skb == NULL);
lp->current_rx_skb = NULL;
@@ -1792,6 +1791,9 @@ static int smc911x_probe(struct net_device *dev)
unsigned int val, chip_id, revision;
const char *version_string;
unsigned long irq_flags;
+   struct dma_slave_config config;
+   dma_cap_mask_t mask;
+   struct pxad_param param;
 
DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
 
@@ -1963,11 +1965,40 @@ static int smc911x_probe(struct net_device *dev)
goto err_out;
 
 #ifdef SMC_USE_DMA
-   lp->rxdma = SMC_DMA_REQUEST(dev, smc911x_rx_dma_irq);
-   lp->txdma = SMC_DMA_REQUEST(dev, smc911x_tx_dma_irq);
+
+   dma_cap_zero(mask);
+   dma_cap_set(DMA_SLAVE, mask);
+   param.prio = PXAD_PRIO_LOWEST;
+   param.drcmr = -1UL;
+
+   lp->rxdma =
+   dma_request_slave_channel_compat(mask, pxad_filter_fn,
+, >dev, "rx");
+   lp->txdma =
+   dma_request_slave_channel_compat(mask, pxad_filter_fn,
+, >dev, "tx");
lp->rxdma_active = 0;
lp->txdma_active = 0;
-   dev->dma = lp->rxdma;
+
+   memset(, 0, sizeof(config));
+   config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   config.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   config.src_addr = lp->physaddr + RX_DATA_FIFO;
+   config.dst_addr = lp->physaddr + TX_DATA_FIFO;
+   config.src_maxburst = 32;
+   config.dst_maxburst = 32;
+   retval = dmaengine_slave_config(lp->rxdma, );
+   if (retval) {
+   dev_err(lp->dev, "dma rx channel configuration failed: %d\n",
+   retval);
+   goto err_out;
+   }
+   retval = dmaengine_slave_config(lp->txdma, );
+   if (retval) {
+   dev_err(lp->dev, "dma tx channel configuration failed: %d\n",
+   retval);
+   goto err_out;
+   }
 #endif
 
retval = register_netdev(dev);
@@ -1978,11 +2009,11 @@ static int smc911x_probe(struct net_device *dev)
dev->base_addr, dev->irq);
 
 #ifdef SMC_USE_DMA
-   if (lp->rxdma != -1)
-   pr_cont(" RXDMA %d", lp->rxdma);
+   if (lp->rxdma)
+   pr_cont(" RXDMA %p", lp->rxdma);
 
-   if (lp->txdma != -1)
-   pr_cont(" TXDMA %d", lp->txdma);
+   if

Re: [PATCH 2/7] dmaengine: xilinx_vdma: Add quirks support to differentiate differnet IP cores

2016-03-19 Thread Laurent Pinchart

Hello,

On Tuesday 15 March 2016 22:53:07 Kedareswara rao Appana wrote:
> This patch adds quirks support in the driver to differentiate differnet IP

s/differnet/different/

(and in the subject line too)

With this series applied the driver will not be vdma-specific anymore. The 
xilinx_vdma_ prefix will thus be confusing. I'd bite the bullet and apply a 
global rename to functions that are not shared between the three DMA IP core 
types before patch 2/7.

> cores.
> 
> Signed-off-by: Kedareswara rao Appana 
> ---
>  drivers/dma/xilinx/xilinx_vdma.c | 36 ++--
>  1 file changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> b/drivers/dma/xilinx/xilinx_vdma.c index 7ab6793..f682bef 100644
> --- a/drivers/dma/xilinx/xilinx_vdma.c
> +++ b/drivers/dma/xilinx/xilinx_vdma.c
> @@ -139,6 +139,8 @@
>  /* Delay loop counter to prevent hardware failure */
>  #define XILINX_VDMA_LOOP_COUNT   100
> 
> +#define AXIVDMA_SUPPORT  BIT(0)
> +
>  /**
>   * struct xilinx_vdma_desc_hw - Hardware Descriptor
>   * @next_desc: Next Descriptor Pointer @0x00
> @@ -240,6 +242,7 @@ struct xilinx_vdma_chan {
>   * @chan: Driver specific VDMA channel
>   * @has_sg: Specifies whether Scatter-Gather is present or not
>   * @flush_on_fsync: Flush on frame sync
> + * @quirks: Needed for different IP cores
>   */
>  struct xilinx_vdma_device {
>   void __iomem *regs;
> @@ -248,6 +251,15 @@ struct xilinx_vdma_device {
>   struct xilinx_vdma_chan *chan[XILINX_VDMA_MAX_CHANS_PER_DEVICE];
>   bool has_sg;
>   u32 flush_on_fsync;
> + u32 quirks;
> +};
> +
> +/**
> + * struct xdma_platform_data - DMA platform structure
> + * @quirks: quirks for platform specific data.
> + */
> +struct xdma_platform_data {

This isn't platform data but device information, I'd rename the structure to 
xdma_device_info (and update the description accordingly).

> + u32 quirks;

I don't think you should call this field quirks as it stores the IP core type. 
Quirks usually refer to non-standard behaviour that requires specific handling 
in the driver, possibly in the form of work-arounds. I would thus call the 
field type and document it as "DMA IP core type". Similarly I'd rename 
AXIVDMA_SUPPORT to XDMA_TYPE_VDMA.

>  };
> 
>  /* Macros */
> @@ -1239,6 +1251,16 @@ static struct dma_chan *of_dma_xilinx_xlate(struct
> of_phandle_args *dma_spec, return
> dma_get_slave_channel(>chan[chan_id]->common);
>  }
> 
> +static const struct xdma_platform_data xvdma_def = {
> + .quirks = AXIVDMA_SUPPORT,
> +};
> +
> +static const struct of_device_id xilinx_vdma_of_ids[] = {
> + { .compatible = "xlnx,axi-vdma-1.00.a", .data = _def},

Missing space before }, did you run checkpatch ?

As the xdma_platform_data structure contains a single integer, you could store 
it in the .data field directly.

> + {}
> +};
> +MODULE_DEVICE_TABLE(of, xilinx_vdma_of_ids);
> +
>  /**
>   * xilinx_vdma_probe - Driver probe function
>   * @pdev: Pointer to the platform_device structure
> @@ -1251,6 +1273,7 @@ static int xilinx_vdma_probe(struct platform_device
> *pdev) struct xilinx_vdma_device *xdev;
>   struct device_node *child;
>   struct resource *io;
> + const struct of_device_id *match;
>   u32 num_frames;
>   int i, err;
> 
> @@ -1259,6 +1282,13 @@ static int xilinx_vdma_probe(struct platform_device
> *pdev) if (!xdev)
>   return -ENOMEM;
> 
> + match = of_match_node(xilinx_vdma_of_ids, pdev->dev.of_node);

You can use of_device_get_match_data() to get the data directly.

> + if (match && match->data) {

I don't think this condition can ever be false.

> + const struct xdma_platform_data *data = match->data;
> +
> + xdev->quirks = data->quirks;
> + }
> +
>   xdev->dev = >dev;
> 
>   /* Request and map I/O memory */
> @@ -1356,12 +1386,6 @@ static int xilinx_vdma_remove(struct platform_device
> *pdev) return 0;
>  }
> 
> -static const struct of_device_id xilinx_vdma_of_ids[] = {
> - { .compatible = "xlnx,axi-vdma-1.00.a",},
> - {}
> -};
> -MODULE_DEVICE_TABLE(of, xilinx_vdma_of_ids);
> -
>  static struct platform_driver xilinx_vdma_driver = {
>   .driver = {
>   .name = "xilinx-vdma",

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/7] dmaengine: xilinx_vdma: Add quirks support to differentiate differnet IP cores

2016-03-19 Thread Laurent Pinchart

Hello,

On Tuesday 15 March 2016 22:53:07 Kedareswara rao Appana wrote:
> This patch adds quirks support in the driver to differentiate differnet IP

s/differnet/different/

(and in the subject line too)

With this series applied the driver will not be vdma-specific anymore. The 
xilinx_vdma_ prefix will thus be confusing. I'd bite the bullet and apply a 
global rename to functions that are not shared between the three DMA IP core 
types before patch 2/7.

> cores.
> 
> Signed-off-by: Kedareswara rao Appana 
> ---
>  drivers/dma/xilinx/xilinx_vdma.c | 36 ++--
>  1 file changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> b/drivers/dma/xilinx/xilinx_vdma.c index 7ab6793..f682bef 100644
> --- a/drivers/dma/xilinx/xilinx_vdma.c
> +++ b/drivers/dma/xilinx/xilinx_vdma.c
> @@ -139,6 +139,8 @@
>  /* Delay loop counter to prevent hardware failure */
>  #define XILINX_VDMA_LOOP_COUNT   100
> 
> +#define AXIVDMA_SUPPORT  BIT(0)
> +
>  /**
>   * struct xilinx_vdma_desc_hw - Hardware Descriptor
>   * @next_desc: Next Descriptor Pointer @0x00
> @@ -240,6 +242,7 @@ struct xilinx_vdma_chan {
>   * @chan: Driver specific VDMA channel
>   * @has_sg: Specifies whether Scatter-Gather is present or not
>   * @flush_on_fsync: Flush on frame sync
> + * @quirks: Needed for different IP cores
>   */
>  struct xilinx_vdma_device {
>   void __iomem *regs;
> @@ -248,6 +251,15 @@ struct xilinx_vdma_device {
>   struct xilinx_vdma_chan *chan[XILINX_VDMA_MAX_CHANS_PER_DEVICE];
>   bool has_sg;
>   u32 flush_on_fsync;
> + u32 quirks;
> +};
> +
> +/**
> + * struct xdma_platform_data - DMA platform structure
> + * @quirks: quirks for platform specific data.
> + */
> +struct xdma_platform_data {

This isn't platform data but device information, I'd rename the structure to 
xdma_device_info (and update the description accordingly).

> + u32 quirks;

I don't think you should call this field quirks as it stores the IP core type. 
Quirks usually refer to non-standard behaviour that requires specific handling 
in the driver, possibly in the form of work-arounds. I would thus call the 
field type and document it as "DMA IP core type". Similarly I'd rename 
AXIVDMA_SUPPORT to XDMA_TYPE_VDMA.

>  };
> 
>  /* Macros */
> @@ -1239,6 +1251,16 @@ static struct dma_chan *of_dma_xilinx_xlate(struct
> of_phandle_args *dma_spec, return
> dma_get_slave_channel(>chan[chan_id]->common);
>  }
> 
> +static const struct xdma_platform_data xvdma_def = {
> + .quirks = AXIVDMA_SUPPORT,
> +};
> +
> +static const struct of_device_id xilinx_vdma_of_ids[] = {
> + { .compatible = "xlnx,axi-vdma-1.00.a", .data = _def},

Missing space before }, did you run checkpatch ?

As the xdma_platform_data structure contains a single integer, you could store 
it in the .data field directly.

> + {}
> +};
> +MODULE_DEVICE_TABLE(of, xilinx_vdma_of_ids);
> +
>  /**
>   * xilinx_vdma_probe - Driver probe function
>   * @pdev: Pointer to the platform_device structure
> @@ -1251,6 +1273,7 @@ static int xilinx_vdma_probe(struct platform_device
> *pdev) struct xilinx_vdma_device *xdev;
>   struct device_node *child;
>   struct resource *io;
> + const struct of_device_id *match;
>   u32 num_frames;
>   int i, err;
> 
> @@ -1259,6 +1282,13 @@ static int xilinx_vdma_probe(struct platform_device
> *pdev) if (!xdev)
>   return -ENOMEM;
> 
> + match = of_match_node(xilinx_vdma_of_ids, pdev->dev.of_node);

You can use of_device_get_match_data() to get the data directly.

> + if (match && match->data) {

I don't think this condition can ever be false.

> + const struct xdma_platform_data *data = match->data;
> +
> + xdev->quirks = data->quirks;
> + }
> +
>   xdev->dev = >dev;
> 
>   /* Request and map I/O memory */
> @@ -1356,12 +1386,6 @@ static int xilinx_vdma_remove(struct platform_device
> *pdev) return 0;
>  }
> 
> -static const struct of_device_id xilinx_vdma_of_ids[] = {
> - { .compatible = "xlnx,axi-vdma-1.00.a",},
> - {}
> -};
> -MODULE_DEVICE_TABLE(of, xilinx_vdma_of_ids);
> -
>  static struct platform_driver xilinx_vdma_driver = {
>   .driver = {
>   .name = "xilinx-vdma",

-- 
Regards,

Laurent Pinchart

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

2016-03-19 Thread Junio C Hamano

Linus Torvalds  writes:

> It's literally just the fact that "git merge" does it with no extra
> flags or checks. I'd like people to have to be aware of what they are
> doing when they merge two different projects, not do it by mistake.
>
> So making it conditional on a flag like "--no-common-root" is what I'd look 
> for.

I think I said essentially the same thing in a separate message; I
am not sure "--no-common-root" is a good name, but I think it is
better to be more explicit than tying this to a strategy.

> I don't think the original "resolve" did it, for example. You can't do
> a three-way merge without a base.

Yes, and that continues to this day:

# Give up if we are given two or more remotes -- not handling octopus.
case "$remotes" in
?*' '?*)
exit 2 ;;
esac

# Give up if this is a baseless merge.
if test '' = "$bases"
then
exit 2
fi

This is a tangent but I wonder if we should say why we refuse to
the standard error before calling these two "exit"s.

Re: divide error: 0000 [#1] SMP in task_numa_migrate - handle_mm_fault vanilla 4.4.6

2016-03-19 Thread Greg KH

On Thu, Mar 17, 2016 at 07:38:03PM +0100, Stefan Priebe wrote:
> Hi,
> 
> while running qemu 2.5 on a host running 4.4.6 the host system has crashed
> (load > 200) 3 times in the last 3 days.
> 
> Always with this stack trace: (copy left here:
> http://pastebin.com/raw/bCWTLKyt)
> 
> [69068.874268] divide error:  [#1] SMP
> [69068.875242] Modules linked in: ebtable_filter ebtables ip6t_REJECT
> nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
> ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
> nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_conntrack
> nf_conntrack ip_set_hash_net ip_set vhost_net tun vhost macvtap macvlan
> kvm_intel nfnetlink_log kvm nfnetlink irqbypass netconsole dlm xt_multiport
> iptable_filter ip_tables x_tables iscsi_tcp libiscsi_tcp libiscsi
> scsi_transport_iscsi nfsd auth_rpcgss oid_registry bonding coretemp 8021q
> garp fuse i2c_i801 i7core_edac edac_core i5500_temp button btrfs xor
> raid6_pq dm_mod raid1 md_mod usb_storage ohci_hcd bcache sg usbhid sd_mod
> ata_generic uhci_hcd ehci_pci ehci_hcd usbcore ata_piix usb_common igb
> i2c_algo_bit mpt3sas raid_class ixgbe scsi_transport_sas i2c_core mdio ptp
> pps_core
> [69068.895604] CPU: 14 PID: 6673 Comm: ceph-osd Not tainted 4.4.6+7-ph #1
> [69068.897052] Hardware name: Supermicro X8DT3/X8DT3, BIOS 2.1 03/17/2012
> [69068.898578] task: 880fc7f28000 ti: 880fda2c4000 task.ti:
> 880fda2c4000
> [69068.900377] RIP: 0010:[]  []
> task_h_load+0xcc/0x100
> [69068.961763] RSP: :880fda2c7b50  EFLAGS: 00010257
> [69069.023910] RAX:  RBX: 880fda2c7c10 RCX:
> 
> [69069.085953] RDX:  RSI: 0001 RDI:
> 880fc7f28000
> [69069.151731] RBP: 880fda2c7bc8 R08: 0001041955df R09:
> 880fffd153f8
> [69069.213757] R10: 0009 R11: 0193 R12:
> 881f6832c780
> [69069.274271] R13: 88203fc35380 R14: 0007 R15:
> 00b6
> [69069.334727] FS:  7f578a3fb700() GS:880fffd0()
> knlGS:
> [69069.396435] CS:  0010 DS:  ES:  CR0: 80050033
> [69069.458522] CR2: 7f5784f18468 CR3: 001fe9738000 CR4:
> 26e0
> [69069.520799] Stack:
> [69069.581430]  860b6855 880fda2c7b78 
> 0005
> [69069.642629]  880fffd0 0015 fe7d
> 0015
> [69069.702815]  00015380 880fda2c7bc8 880fc7f28000
> 01e9
> [69069.761881] Call Trace:
> [69069.819883]  [] ? task_numa_find_cpu+0x225/0x670
> [69069.878368]  [] task_numa_migrate+0x550/0x950
> [69069.936059]  [] ? find_next_bit+0x18/0x20
> [69069.993262]  [] numa_migrate_preferred+0x7d/0x90
> [69070.050528]  [] task_numa_fault+0x7c5/0xaa0
> [69070.106544]  [] ? mpol_misplaced+0x16b/0x1b0
> [69070.163705]  [] __handle_mm_fault+0x9ae/0x11f0
> [69070.220013]  [] ? inet_recvmsg+0x72/0x90
> [69070.276558]  [] ? SYSC_recvfrom+0x12b/0x170
> [69070.332283]  [] handle_mm_fault+0xdf/0x180
> [69070.388515]  [] __do_page_fault+0x164/0x380
> [69070.443897]  [] ? account_user_time+0x73/0x80
> [69070.498534]  [] ? vtime_account_user+0x4e/0x70
> [69070.552598]  [] do_page_fault+0x37/0x90
> [69070.605960]  [] ? syscall_return_slowpath+0x83/0xf0
> [69070.660705]  [] page_fault+0x28/0x30
> [69070.715707] Code: 86 b8 00 00 00 48 89 86 b0 00 00 00 48 85 c9 75 ca 49
> 8b 81 b0 00 00 00 49 8b 49 78 31 d2 48 0f af 87 d8 01 00 00 5d 48 83 c1 01
> <48> f7 f1 c3 4c 89 ce 48 8b 8e c0 00 00 00 48 8b 46 78 4c 89 86
> [69070.835144] RIP  [] task_h_load+0xcc/0x100
> [69070.894095]  RSP 
> [69070.953213] ---[ end trace 8d6f449a03dacfd4 ]---
> 
> Would be nice if we can fix this in 4.4?

Does this also happen in 4.5?  Did this work on 4.4.5?  Some previous
release?  If you can find the offending patch using 'git bisect', that
would be great.

thanks,

greg k-h

Re: [GIT PULL] GPIO bulk changes for kernel v4.6

2016-03-19 Thread Junio C Hamano

Linus Torvalds  writes:

> It's literally just the fact that "git merge" does it with no extra
> flags or checks. I'd like people to have to be aware of what they are
> doing when they merge two different projects, not do it by mistake.
>
> So making it conditional on a flag like "--no-common-root" is what I'd look 
> for.

I think I said essentially the same thing in a separate message; I
am not sure "--no-common-root" is a good name, but I think it is
better to be more explicit than tying this to a strategy.

> I don't think the original "resolve" did it, for example. You can't do
> a three-way merge without a base.

Yes, and that continues to this day:

# Give up if we are given two or more remotes -- not handling octopus.
case "$remotes" in
?*' '?*)
exit 2 ;;
esac

# Give up if this is a baseless merge.
if test '' = "$bases"
then
exit 2
fi

This is a tangent but I wonder if we should say why we refuse to
the standard error before calling these two "exit"s.

Re: divide error: 0000 [#1] SMP in task_numa_migrate - handle_mm_fault vanilla 4.4.6

2016-03-19 Thread Greg KH

On Thu, Mar 17, 2016 at 07:38:03PM +0100, Stefan Priebe wrote:
> Hi,
> 
> while running qemu 2.5 on a host running 4.4.6 the host system has crashed
> (load > 200) 3 times in the last 3 days.
> 
> Always with this stack trace: (copy left here:
> http://pastebin.com/raw/bCWTLKyt)
> 
> [69068.874268] divide error:  [#1] SMP
> [69068.875242] Modules linked in: ebtable_filter ebtables ip6t_REJECT
> nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
> ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
> nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_conntrack
> nf_conntrack ip_set_hash_net ip_set vhost_net tun vhost macvtap macvlan
> kvm_intel nfnetlink_log kvm nfnetlink irqbypass netconsole dlm xt_multiport
> iptable_filter ip_tables x_tables iscsi_tcp libiscsi_tcp libiscsi
> scsi_transport_iscsi nfsd auth_rpcgss oid_registry bonding coretemp 8021q
> garp fuse i2c_i801 i7core_edac edac_core i5500_temp button btrfs xor
> raid6_pq dm_mod raid1 md_mod usb_storage ohci_hcd bcache sg usbhid sd_mod
> ata_generic uhci_hcd ehci_pci ehci_hcd usbcore ata_piix usb_common igb
> i2c_algo_bit mpt3sas raid_class ixgbe scsi_transport_sas i2c_core mdio ptp
> pps_core
> [69068.895604] CPU: 14 PID: 6673 Comm: ceph-osd Not tainted 4.4.6+7-ph #1
> [69068.897052] Hardware name: Supermicro X8DT3/X8DT3, BIOS 2.1 03/17/2012
> [69068.898578] task: 880fc7f28000 ti: 880fda2c4000 task.ti:
> 880fda2c4000
> [69068.900377] RIP: 0010:[]  []
> task_h_load+0xcc/0x100
> [69068.961763] RSP: :880fda2c7b50  EFLAGS: 00010257
> [69069.023910] RAX:  RBX: 880fda2c7c10 RCX:
> 
> [69069.085953] RDX:  RSI: 0001 RDI:
> 880fc7f28000
> [69069.151731] RBP: 880fda2c7bc8 R08: 0001041955df R09:
> 880fffd153f8
> [69069.213757] R10: 0009 R11: 0193 R12:
> 881f6832c780
> [69069.274271] R13: 88203fc35380 R14: 0007 R15:
> 00b6
> [69069.334727] FS:  7f578a3fb700() GS:880fffd0()
> knlGS:
> [69069.396435] CS:  0010 DS:  ES:  CR0: 80050033
> [69069.458522] CR2: 7f5784f18468 CR3: 001fe9738000 CR4:
> 26e0
> [69069.520799] Stack:
> [69069.581430]  860b6855 880fda2c7b78 
> 0005
> [69069.642629]  880fffd0 0015 fe7d
> 0015
> [69069.702815]  00015380 880fda2c7bc8 880fc7f28000
> 01e9
> [69069.761881] Call Trace:
> [69069.819883]  [] ? task_numa_find_cpu+0x225/0x670
> [69069.878368]  [] task_numa_migrate+0x550/0x950
> [69069.936059]  [] ? find_next_bit+0x18/0x20
> [69069.993262]  [] numa_migrate_preferred+0x7d/0x90
> [69070.050528]  [] task_numa_fault+0x7c5/0xaa0
> [69070.106544]  [] ? mpol_misplaced+0x16b/0x1b0
> [69070.163705]  [] __handle_mm_fault+0x9ae/0x11f0
> [69070.220013]  [] ? inet_recvmsg+0x72/0x90
> [69070.276558]  [] ? SYSC_recvfrom+0x12b/0x170
> [69070.332283]  [] handle_mm_fault+0xdf/0x180
> [69070.388515]  [] __do_page_fault+0x164/0x380
> [69070.443897]  [] ? account_user_time+0x73/0x80
> [69070.498534]  [] ? vtime_account_user+0x4e/0x70
> [69070.552598]  [] do_page_fault+0x37/0x90
> [69070.605960]  [] ? syscall_return_slowpath+0x83/0xf0
> [69070.660705]  [] page_fault+0x28/0x30
> [69070.715707] Code: 86 b8 00 00 00 48 89 86 b0 00 00 00 48 85 c9 75 ca 49
> 8b 81 b0 00 00 00 49 8b 49 78 31 d2 48 0f af 87 d8 01 00 00 5d 48 83 c1 01
> <48> f7 f1 c3 4c 89 ce 48 8b 8e c0 00 00 00 48 8b 46 78 4c 89 86
> [69070.835144] RIP  [] task_h_load+0xcc/0x100
> [69070.894095]  RSP 
> [69070.953213] ---[ end trace 8d6f449a03dacfd4 ]---
> 
> Would be nice if we can fix this in 4.4?

Does this also happen in 4.5?  Did this work on 4.4.5?  Some previous
release?  If you can find the offending patch using 'git bisect', that
would be great.

thanks,

greg k-h

Re: [PATCH] Revert "arm64: Increase the max granular size"

2016-03-19 Thread Catalin Marinas

On Thu, Mar 17, 2016 at 09:49:51AM -0500, Timur Tabi wrote:
> Catalin Marinas wrote:
> >>>Yes, that's exactly it.  Ours is an ACPI system, and so we have to have our
> >>>own defconfig for now.  We're holding off on pushing our own defconfig
> >>>changes (enabling drivers, etc) until ACPI is enabled in
> >>>arch/arm64/configs/defconfig.
> 
> >Is there anything that prevents you from providing a dtb/dts for this
> >SoC?
> 
> We don't have a boot loader capable of passing a device tree to the kernel.
> It's an ARM Server chip.  It doesn't do device tree.  It's 100% ACPI.  We
> boot with UEFI that configures the system and generates ACPI tables.

Well, I disagree with the idea that server == ACPI. But I guess you knew
this already.

> I just want to make this crystal clear, because it comes up every now and
> then.  The QDF2432 is an ACPI-only SOC with no device tree support
> whatsoever.  Zero.  Zip.  Nada.  It's not an option.

That's your choice really, I don't care much (as long as current ACPI
support has all the features you need; if it doesn't, there is a good
chance that your SoC won't be supported in mainline until it's sorted).

> Keep in mind that on an ACPI system like ours, the boot loader (UEFI in our
> case) configures the system extensively.  It does a lot of things that the
> kernel would normally do on a device tree system.  For example, pin control
> is handled completely by UEFI.  The kernel does not set the pin muxes or
> GPIO directions.  That means we don't support dynamic pin muxing.  Before
> the kernel is booted, the GPIO pins are fixed.

And that's great. But you are mistaken in thinking that DT requires lots
of drivers in the kernel and prevents the firmware from doing sane
stuff. DT rather gained additional features out of necessity since the
firmware was not always doing a proper job at hardware initialisation.
A DT-enabled kernel does not impose restrictions on such firmware
features. With ACPI, the choice is not as wide and forces vendors to
look into their firmware story from a different angle (until they figure
the _DSD+PRP0001 out and we end up with DT emulated in ACPI).

If the GPIO pins are fixed at boot-time, they don't even need to be
described in the DT, just let the firmware configure them. However, if
they need to be changed at run-time (which does not seem to be your
case), that's where you have a choice of either kernel driver (DT) or
AML code (ACPI) (or both). Otherwise, without this run-time aspect, both
DT and ACPI are just slightly different ways to provide a static
platform description.

> We're not going to create an entire device tree from scratch for this chip,
> and then make the extensive modifications necessary to our boot loader for
> parsing and modifying that device tree.  That would take months of work, and
> it would be all throw-away code.

As I said above, that's your choice and it depends on your timeline and
mainline support requirements. I however disagree with this being
"throw-away code" (or even taking "months of work").

-- 
Catalin

Re: [PATCH] Revert "arm64: Increase the max granular size"

2016-03-19 Thread Catalin Marinas

On Thu, Mar 17, 2016 at 09:49:51AM -0500, Timur Tabi wrote:
> Catalin Marinas wrote:
> >>>Yes, that's exactly it.  Ours is an ACPI system, and so we have to have our
> >>>own defconfig for now.  We're holding off on pushing our own defconfig
> >>>changes (enabling drivers, etc) until ACPI is enabled in
> >>>arch/arm64/configs/defconfig.
> 
> >Is there anything that prevents you from providing a dtb/dts for this
> >SoC?
> 
> We don't have a boot loader capable of passing a device tree to the kernel.
> It's an ARM Server chip.  It doesn't do device tree.  It's 100% ACPI.  We
> boot with UEFI that configures the system and generates ACPI tables.

Well, I disagree with the idea that server == ACPI. But I guess you knew
this already.

> I just want to make this crystal clear, because it comes up every now and
> then.  The QDF2432 is an ACPI-only SOC with no device tree support
> whatsoever.  Zero.  Zip.  Nada.  It's not an option.

That's your choice really, I don't care much (as long as current ACPI
support has all the features you need; if it doesn't, there is a good
chance that your SoC won't be supported in mainline until it's sorted).

> Keep in mind that on an ACPI system like ours, the boot loader (UEFI in our
> case) configures the system extensively.  It does a lot of things that the
> kernel would normally do on a device tree system.  For example, pin control
> is handled completely by UEFI.  The kernel does not set the pin muxes or
> GPIO directions.  That means we don't support dynamic pin muxing.  Before
> the kernel is booted, the GPIO pins are fixed.

And that's great. But you are mistaken in thinking that DT requires lots
of drivers in the kernel and prevents the firmware from doing sane
stuff. DT rather gained additional features out of necessity since the
firmware was not always doing a proper job at hardware initialisation.
A DT-enabled kernel does not impose restrictions on such firmware
features. With ACPI, the choice is not as wide and forces vendors to
look into their firmware story from a different angle (until they figure
the _DSD+PRP0001 out and we end up with DT emulated in ACPI).

If the GPIO pins are fixed at boot-time, they don't even need to be
described in the DT, just let the firmware configure them. However, if
they need to be changed at run-time (which does not seem to be your
case), that's where you have a choice of either kernel driver (DT) or
AML code (ACPI) (or both). Otherwise, without this run-time aspect, both
DT and ACPI are just slightly different ways to provide a static
platform description.

> We're not going to create an entire device tree from scratch for this chip,
> and then make the extensive modifications necessary to our boot loader for
> parsing and modifying that device tree.  That would take months of work, and
> it would be all throw-away code.

As I said above, that's your choice and it depends on your timeline and
mainline support requirements. I however disagree with this being
"throw-away code" (or even taking "months of work").

-- 
Catalin

[RFC v2] Documentation: mmc: Add the introduction for mmc-utils

2016-03-19 Thread Baolin Wang

This patch introduces one mmc test tools called mmc-utils, which is convenient
if someone wants to exercise and test MMC/SD devices from userspace.

Signed-off-by: Baolin Wang 
---
 Documentation/mmc/00-INDEX  |2 ++
 Documentation/mmc/mmc-tools.txt |   34 ++
 2 files changed, 36 insertions(+)
 create mode 100644 Documentation/mmc/mmc-tools.txt

diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX
index a9ba672..4623bc0 100644
--- a/Documentation/mmc/00-INDEX
+++ b/Documentation/mmc/00-INDEX
@@ -6,3 +6,5 @@ mmc-dev-parts.txt
 - info on SD and MMC device partitions
 mmc-async-req.txt
 - info on mmc asynchronous requests
+mmc-tools.txt
+   - info on mmc-utils tools
diff --git a/Documentation/mmc/mmc-tools.txt b/Documentation/mmc/mmc-tools.txt
new file mode 100644
index 000..499b0f4
--- /dev/null
+++ b/Documentation/mmc/mmc-tools.txt
@@ -0,0 +1,34 @@
+MMC tools introduction
+==
+
+There is one MMC test tools called mmc-utils, which is maintained by Chris 
Ball,
+you can find it at the below public git repository:
+http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/
+
+Functions
+=
+
+The mmc-utils tools can do the following:
+ - Print and parse extcsd data.
+ - Determine the eMMC writeprotect status.
+ - Set the eMMC writeprotect status.
+ - Set the eMMC data sector size to 4KB by disabling emulation.
+ - Create general purpose partition.
+ - Enable the enhanced user area.
+ - Enable write reliability per partition.
+ - Print the response to STATUS_SEND (CMD13).
+ - Enable the boot partition.
+ - Set Boot Bus Conditions.
+ - Enable the eMMC BKOPS feature.
+ - Permanently enable the eMMC H/W Reset feature.
+ - Permanently disable the eMMC H/W Reset feature.
+ - Send Sanitize command.
+ - Program authentication key for the device.
+ - Counter value for the rpmb device will be read to stdout.
+ - Read from rpmb device to output.
+ - Write to rpmb device from data file.
+ - Enable the eMMC cache feature.
+ - Disable the eMMC cache feature.
+ - Print and parse CID data.
+ - Print and parse CSD data.
+ - Print and parse SCR data.
-- 
1.7.9.5

[RFC v2] Documentation: mmc: Add the introduction for mmc-utils

2016-03-19 Thread Baolin Wang

This patch introduces one mmc test tools called mmc-utils, which is convenient
if someone wants to exercise and test MMC/SD devices from userspace.

Signed-off-by: Baolin Wang 
---
 Documentation/mmc/00-INDEX  |2 ++
 Documentation/mmc/mmc-tools.txt |   34 ++
 2 files changed, 36 insertions(+)
 create mode 100644 Documentation/mmc/mmc-tools.txt

diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX
index a9ba672..4623bc0 100644
--- a/Documentation/mmc/00-INDEX
+++ b/Documentation/mmc/00-INDEX
@@ -6,3 +6,5 @@ mmc-dev-parts.txt
 - info on SD and MMC device partitions
 mmc-async-req.txt
 - info on mmc asynchronous requests
+mmc-tools.txt
+   - info on mmc-utils tools
diff --git a/Documentation/mmc/mmc-tools.txt b/Documentation/mmc/mmc-tools.txt
new file mode 100644
index 000..499b0f4
--- /dev/null
+++ b/Documentation/mmc/mmc-tools.txt
@@ -0,0 +1,34 @@
+MMC tools introduction
+==
+
+There is one MMC test tools called mmc-utils, which is maintained by Chris 
Ball,
+you can find it at the below public git repository:
+http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/
+
+Functions
+=
+
+The mmc-utils tools can do the following:
+ - Print and parse extcsd data.
+ - Determine the eMMC writeprotect status.
+ - Set the eMMC writeprotect status.
+ - Set the eMMC data sector size to 4KB by disabling emulation.
+ - Create general purpose partition.
+ - Enable the enhanced user area.
+ - Enable write reliability per partition.
+ - Print the response to STATUS_SEND (CMD13).
+ - Enable the boot partition.
+ - Set Boot Bus Conditions.
+ - Enable the eMMC BKOPS feature.
+ - Permanently enable the eMMC H/W Reset feature.
+ - Permanently disable the eMMC H/W Reset feature.
+ - Send Sanitize command.
+ - Program authentication key for the device.
+ - Counter value for the rpmb device will be read to stdout.
+ - Read from rpmb device to output.
+ - Write to rpmb device from data file.
+ - Enable the eMMC cache feature.
+ - Disable the eMMC cache feature.
+ - Print and parse CID data.
+ - Print and parse CSD data.
+ - Print and parse SCR data.
-- 
1.7.9.5

Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods

2016-03-19 Thread Peter Zijlstra

On Thu, Mar 17, 2016 at 06:41:42PM -0400, Chris Metcalf wrote:
> The build bot caught the fact that I missed arch/xtensa since it doesn't use
> LOCK_TEXT, so if you're testing on that (ok maybe unlikely) you can add this:

Ha!, no. regular boring x86_64.

Re: [PATCH v2 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods

2016-03-19 Thread Peter Zijlstra

On Thu, Mar 17, 2016 at 06:41:42PM -0400, Chris Metcalf wrote:
> The build bot caught the fact that I missed arch/xtensa since it doesn't use
> LOCK_TEXT, so if you're testing on that (ok maybe unlikely) you can add this:

Ha!, no. regular boring x86_64.

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

2016-03-19 Thread James Morse

Hi Pratyush,

On 18/03/16 13:29, Pratyush Anand wrote:
> Probably, I can see why does not it work. So, when we are single stepping an
> instruction and page fault occurs, we will come to el1_da in entry.S. Here, we
> do enable_dbg. As soon as we will do this, we will start receiving single step
> exception after each instruction (not sure, probably for each alternate
> instruction). Since, there will not be any matching single step handler for
> these instructions, so we will see warning "Unexpected kernel single-step
> exception at EL1". 
> 
> So, I think, we should 
> 
> (1) may be do not enable debug for el1_da, or
> (2) enable_dbg only when single stepping is not enabled, or
> (3) or disable single stepping during el1_da execution.
> 
> (1) will solve the issue for sure, but not sure if it could be the best 
> choice.

A variation on (3):

In kernel/entry.S when entered from EL0 we test for TIF_SINGLESTEP in the
thread_info flags, and use disable_step_tsk/enable_step_tsk to save/restore the
single-step state.

Could we do this regardless of which EL we came from?


Thanks,

James

Re: [PATCH v11 3/9] arm64: add copy_to/from_user to kprobes blacklist

2016-03-19 Thread James Morse

Hi Pratyush,

On 18/03/16 13:29, Pratyush Anand wrote:
> Probably, I can see why does not it work. So, when we are single stepping an
> instruction and page fault occurs, we will come to el1_da in entry.S. Here, we
> do enable_dbg. As soon as we will do this, we will start receiving single step
> exception after each instruction (not sure, probably for each alternate
> instruction). Since, there will not be any matching single step handler for
> these instructions, so we will see warning "Unexpected kernel single-step
> exception at EL1". 
> 
> So, I think, we should 
> 
> (1) may be do not enable debug for el1_da, or
> (2) enable_dbg only when single stepping is not enabled, or
> (3) or disable single stepping during el1_da execution.
> 
> (1) will solve the issue for sure, but not sure if it could be the best 
> choice.

A variation on (3):

In kernel/entry.S when entered from EL0 we test for TIF_SINGLESTEP in the
thread_info flags, and use disable_step_tsk/enable_step_tsk to save/restore the
single-step state.

Could we do this regardless of which EL we came from?


Thanks,

James

[PATCH 3.19.y-ckt 65/70] ipv6: re-enable fragment header matching in ipv6_find_hdr

2016-03-19 Thread Kamal Mostafa

v3.19.8-ckt17 -stable review patch.  If anyone has any objections, please let 
me know.

---8<

From: Florian Westphal 

commit 5d150a985520bbe3cb2aa1ceef24a7e32f20c15f upstream.

When ipv6_find_hdr is used to find a fragment header
(caller specifies target NEXTHDR_FRAGMENT) we erronously return
-ENOENT for all fragments with nonzero offset.

Before commit 9195bb8e381d, when target was specified, we did not
enter the exthdr walk loop as nexthdr == target so this used to work.

Now we do (so we can skip empty route headers). When we then stumble upon
a frag with nonzero frag_off we must return -ENOENT ("header not found")
only if the caller did not specifically request NEXTHDR_FRAGMENT.

This allows nfables exthdr expression to match ipv6 fragments, e.g. via

nft add rule ip6 filter input frag frag-off gt 0

Fixes: 9195bb8e381d ("ipv6: improve ipv6_find_hdr() to skip empty routing 
headers")
Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/ipv6/exthdrs_core.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c
index 8af3eb5..c7c8f71 100644
--- a/net/ipv6/exthdrs_core.c
+++ b/net/ipv6/exthdrs_core.c
@@ -257,7 +257,11 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int 
*offset,
*fragoff = _frag_off;
return hp->nexthdr;
}
-   return -ENOENT;
+   if (!found)
+   return -ENOENT;
+   if (fragoff)
+   *fragoff = _frag_off;
+   break;
}
hdrlen = 8;
} else if (nexthdr == NEXTHDR_AUTH) {
-- 
2.7.0

[PATCH 3.19.y-ckt 65/70] ipv6: re-enable fragment header matching in ipv6_find_hdr

2016-03-19 Thread Kamal Mostafa

v3.19.8-ckt17 -stable review patch.  If anyone has any objections, please let 
me know.

---8<

From: Florian Westphal 

commit 5d150a985520bbe3cb2aa1ceef24a7e32f20c15f upstream.

When ipv6_find_hdr is used to find a fragment header
(caller specifies target NEXTHDR_FRAGMENT) we erronously return
-ENOENT for all fragments with nonzero offset.

Before commit 9195bb8e381d, when target was specified, we did not
enter the exthdr walk loop as nexthdr == target so this used to work.

Now we do (so we can skip empty route headers). When we then stumble upon
a frag with nonzero frag_off we must return -ENOENT ("header not found")
only if the caller did not specifically request NEXTHDR_FRAGMENT.

This allows nfables exthdr expression to match ipv6 fragments, e.g. via

nft add rule ip6 filter input frag frag-off gt 0

Fixes: 9195bb8e381d ("ipv6: improve ipv6_find_hdr() to skip empty routing 
headers")
Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/ipv6/exthdrs_core.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c
index 8af3eb5..c7c8f71 100644
--- a/net/ipv6/exthdrs_core.c
+++ b/net/ipv6/exthdrs_core.c
@@ -257,7 +257,11 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int 
*offset,
*fragoff = _frag_off;
return hp->nexthdr;
}
-   return -ENOENT;
+   if (!found)
+   return -ENOENT;
+   if (fragoff)
+   *fragoff = _frag_off;
+   break;
}
hdrlen = 8;
} else if (nexthdr == NEXTHDR_AUTH) {
-- 
2.7.0

[PATCH 3.19.y-ckt 62/70] tcp: convert cached rtt from usec to jiffies when feeding initial rto

2016-03-19 Thread Kamal Mostafa

v3.19.8-ckt17 -stable review patch.  If anyone has any objections, please let 
me know.

---8<

From: Konstantin Khlebnikov 

commit 9bdfb3b79e61c60e1a3e2dc05ad164528afa6b8a upstream.

Currently it's converted into msecs, thus HZ=1000 intact.

Signed-off-by: Konstantin Khlebnikov 
Fixes: 740b0f1841f6 ("tcp: switch rtt estimations to usec resolution")
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/ipv4/tcp_metrics.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index ed9c9a9..c90e76c 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -550,7 +550,7 @@ reset:
 */
if (crtt > tp->srtt_us) {
/* Set RTO like tcp_rtt_estimator(), but from cached RTT. */
-   crtt /= 8 * USEC_PER_MSEC;
+   crtt /= 8 * USEC_PER_SEC / HZ;
inet_csk(sk)->icsk_rto = crtt + max(2 * crtt, tcp_rto_min(sk));
} else if (tp->srtt_us == 0) {
/* RFC6298: 5.7 We've failed to get a valid RTT sample from
-- 
2.7.0

Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog

2016-03-19 Thread Laxman Dewangan



On Thursday 17 March 2016 09:16 PM, Rob Herring wrote:

On Thu, Mar 10, 2016 at 05:23:55PM +0530, Laxman Dewangan wrote:

On this case, we have already property "line-name" and passed the name
of the gpio via this property.
The property names is "line-name" which is good for one string. We can
support other property "line-names" with multiple string per GPIO index.

line-names = "wlan-reset", "wlan-enable";

Then what happens when someone wants to selectively disable gpio hogs?

status = "okay", "disabled", "okay";

While I often push things to fewer nodes and more compact descriptions,
I don't think that is the right direction in this case.


I dont think we need to support the individual gpio to be enable/disable 
by status.
We need to support the status property at node level only. if individual 
gpio need to be enabled/disabled by status then it need to break in 
different hog nodes.


This is same as like we have in pincontrol where we can provide the list 
of pin names for some configuration under same node.




There is currently a discussion about the future bindings for subnodes in GPIO
controller nodes. Please have a look at these two mail threads:

"Device tree binding documentation for gpio-switch"
"gpio: of: Add support to have multiple gpios in gpio-hog"

Second one is this patch only. Is it by intention?

The binding details about the gpio-switch and names are given by property
"lable". I think property "label" is standard way of going forward i.e. I
post similar patch for gpio-keys device name from DT after got review
comment.

So here,  we can have the gpio names  under property "label" or "labels".

label is standard. labels you just made up.


Yaah, lables for plural only. Otherwise no issue with "label".




Or am I missing anything?

The point is the more one off changes I see that are all inter-related,
the less willing I am to accept any that don't consider all the cases.
The inter-relationship here is how do we describe gpio lines that don't
otherwise have a connection to another node and how to deal with them if
that changes.

[PATCH 3.19.y-ckt 62/70] tcp: convert cached rtt from usec to jiffies when feeding initial rto

2016-03-19 Thread Kamal Mostafa

v3.19.8-ckt17 -stable review patch.  If anyone has any objections, please let 
me know.

---8<

From: Konstantin Khlebnikov 

commit 9bdfb3b79e61c60e1a3e2dc05ad164528afa6b8a upstream.

Currently it's converted into msecs, thus HZ=1000 intact.

Signed-off-by: Konstantin Khlebnikov 
Fixes: 740b0f1841f6 ("tcp: switch rtt estimations to usec resolution")
Signed-off-by: David S. Miller 
Signed-off-by: Kamal Mostafa 
---
 net/ipv4/tcp_metrics.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index ed9c9a9..c90e76c 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -550,7 +550,7 @@ reset:
 */
if (crtt > tp->srtt_us) {
/* Set RTO like tcp_rtt_estimator(), but from cached RTT. */
-   crtt /= 8 * USEC_PER_MSEC;
+   crtt /= 8 * USEC_PER_SEC / HZ;
inet_csk(sk)->icsk_rto = crtt + max(2 * crtt, tcp_rto_min(sk));
} else if (tp->srtt_us == 0) {
/* RFC6298: 5.7 We've failed to get a valid RTT sample from
-- 
2.7.0

Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog

2016-03-19 Thread Laxman Dewangan



On Thursday 17 March 2016 09:16 PM, Rob Herring wrote:

On Thu, Mar 10, 2016 at 05:23:55PM +0530, Laxman Dewangan wrote:

On this case, we have already property "line-name" and passed the name
of the gpio via this property.
The property names is "line-name" which is good for one string. We can
support other property "line-names" with multiple string per GPIO index.

line-names = "wlan-reset", "wlan-enable";

Then what happens when someone wants to selectively disable gpio hogs?

status = "okay", "disabled", "okay";

While I often push things to fewer nodes and more compact descriptions,
I don't think that is the right direction in this case.


I dont think we need to support the individual gpio to be enable/disable 
by status.
We need to support the status property at node level only. if individual 
gpio need to be enabled/disabled by status then it need to break in 
different hog nodes.


This is same as like we have in pincontrol where we can provide the list 
of pin names for some configuration under same node.




There is currently a discussion about the future bindings for subnodes in GPIO
controller nodes. Please have a look at these two mail threads:

"Device tree binding documentation for gpio-switch"
"gpio: of: Add support to have multiple gpios in gpio-hog"

Second one is this patch only. Is it by intention?

The binding details about the gpio-switch and names are given by property
"lable". I think property "label" is standard way of going forward i.e. I
post similar patch for gpio-keys device name from DT after got review
comment.

So here,  we can have the gpio names  under property "label" or "labels".

label is standard. labels you just made up.


Yaah, lables for plural only. Otherwise no issue with "label".




Or am I missing anything?

The point is the more one off changes I see that are all inter-related,
the less willing I am to accept any that don't consider all the cases.
The inter-relationship here is how do we describe gpio lines that don't
otherwise have a connection to another node and how to deal with them if
that changes.

[PATCH v2] misc: mic: Remove return statements from void functions

2016-03-19 Thread Amitoj Kaur Chawla

Return statements at the end of void functions are useless.

The Coccinelle semantic patch used to make this change is as follows:
//
@@
identifier f;
expression e;
@@
void f(...) {
<...
- return
  e;
...>
}
//

Signed-off-by: Amitoj Kaur Chawla 
---
Changes in v2:
-Resend to add Greg's email id.
 
 drivers/misc/mic/host/mic_boot.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/mic/host/mic_boot.c b/drivers/misc/mic/host/mic_boot.c
index 8c91c99..e047efd 100644
--- a/drivers/misc/mic/host/mic_boot.c
+++ b/drivers/misc/mic/host/mic_boot.c
@@ -76,7 +76,7 @@ static void __mic_free_irq(struct vop_device *vpdev,
 {
struct mic_device *mdev = vpdev_to_mdev(>dev);
 
-   return mic_free_irq(mdev, cookie, data);
+   mic_free_irq(mdev, cookie, data);
 }
 
 static void __mic_ack_interrupt(struct vop_device *vpdev, int num)
@@ -272,7 +272,7 @@ ___mic_free_irq(struct scif_hw_dev *scdev,
 {
struct mic_device *mdev = scdev_to_mdev(scdev);
 
-   return mic_free_irq(mdev, cookie, data);
+   mic_free_irq(mdev, cookie, data);
 }
 
 static void ___mic_ack_interrupt(struct scif_hw_dev *scdev, int num)
@@ -362,7 +362,7 @@ _mic_request_threaded_irq(struct mbus_device *mbdev,
 static void _mic_free_irq(struct mbus_device *mbdev,
  struct mic_irq *cookie, void *data)
 {
-   return mic_free_irq(mbdev_to_mdev(mbdev), cookie, data);
+   mic_free_irq(mbdev_to_mdev(mbdev), cookie, data);
 }
 
 static void _mic_ack_interrupt(struct mbus_device *mbdev, int num)
-- 
1.9.1

[PATCH v2] misc: mic: Remove return statements from void functions

2016-03-19 Thread Amitoj Kaur Chawla

Return statements at the end of void functions are useless.

The Coccinelle semantic patch used to make this change is as follows:
//
@@
identifier f;
expression e;
@@
void f(...) {
<...
- return
  e;
...>
}
//

Signed-off-by: Amitoj Kaur Chawla 
---
Changes in v2:
-Resend to add Greg's email id.
 
 drivers/misc/mic/host/mic_boot.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/mic/host/mic_boot.c b/drivers/misc/mic/host/mic_boot.c
index 8c91c99..e047efd 100644
--- a/drivers/misc/mic/host/mic_boot.c
+++ b/drivers/misc/mic/host/mic_boot.c
@@ -76,7 +76,7 @@ static void __mic_free_irq(struct vop_device *vpdev,
 {
struct mic_device *mdev = vpdev_to_mdev(>dev);
 
-   return mic_free_irq(mdev, cookie, data);
+   mic_free_irq(mdev, cookie, data);
 }
 
 static void __mic_ack_interrupt(struct vop_device *vpdev, int num)
@@ -272,7 +272,7 @@ ___mic_free_irq(struct scif_hw_dev *scdev,
 {
struct mic_device *mdev = scdev_to_mdev(scdev);
 
-   return mic_free_irq(mdev, cookie, data);
+   mic_free_irq(mdev, cookie, data);
 }
 
 static void ___mic_ack_interrupt(struct scif_hw_dev *scdev, int num)
@@ -362,7 +362,7 @@ _mic_request_threaded_irq(struct mbus_device *mbdev,
 static void _mic_free_irq(struct mbus_device *mbdev,
  struct mic_irq *cookie, void *data)
 {
-   return mic_free_irq(mbdev_to_mdev(mbdev), cookie, data);
+   mic_free_irq(mbdev_to_mdev(mbdev), cookie, data);
 }
 
 static void _mic_ack_interrupt(struct mbus_device *mbdev, int num)
-- 
1.9.1

Re: [RESEND PATCH v4 5/5] clocksource: add memory-mapped timer support in arm_arch_timer.c

2016-03-19 Thread Thomas Gleixner

On Fri, 18 Mar 2016, fu@linaro.org wrote:
> +static u32 __init arch_timer_mem_cnttidr(struct acpi_gtdt_timer_block 
> *gt_block)
> +{
> + phys_addr_t cntctlbase_phy;
> + void __iomem *cntctlbase;
> + u32 cnttidr;
> +
> + cntctlbase_phy = (phys_addr_t)gtdt_gt_cntctlbase(gt_block);
> + if (!cntctlbase_phy) {
> + pr_err("Can't find CNTCTLBase.\n");
> + return 0;
> + }
> +
> + /*
> +  * According to ARMv8 Architecture Reference Manual(ARM),
> +  * the size of CNTCTLBase frame of memory-mapped timer
> +  * is SZ_4K(Offset 0x000 – 0xFFF).
> +  */
> + cntctlbase = ioremap(cntctlbase_phy, SZ_4K);
> + if (!cntctlbase) {
> + pr_err("Can't map CNTCTLBase\n");
> + return 0;
> + }

Why are you continuing when you can't find a base address or the remap fails?

> + /*
> +  * Get Generic Timer Counter-timer Timer ID Register
> +  * for Virtual Timer Capability info
> +  */
> + cnttidr = arch_timer_mem_cnttidr(gt_block);

Thanks,

tglx

Re: [RESEND PATCH v4 5/5] clocksource: add memory-mapped timer support in arm_arch_timer.c

2016-03-19 Thread Thomas Gleixner

On Fri, 18 Mar 2016, fu@linaro.org wrote:
> +static u32 __init arch_timer_mem_cnttidr(struct acpi_gtdt_timer_block 
> *gt_block)
> +{
> + phys_addr_t cntctlbase_phy;
> + void __iomem *cntctlbase;
> + u32 cnttidr;
> +
> + cntctlbase_phy = (phys_addr_t)gtdt_gt_cntctlbase(gt_block);
> + if (!cntctlbase_phy) {
> + pr_err("Can't find CNTCTLBase.\n");
> + return 0;
> + }
> +
> + /*
> +  * According to ARMv8 Architecture Reference Manual(ARM),
> +  * the size of CNTCTLBase frame of memory-mapped timer
> +  * is SZ_4K(Offset 0x000 – 0xFFF).
> +  */
> + cntctlbase = ioremap(cntctlbase_phy, SZ_4K);
> + if (!cntctlbase) {
> + pr_err("Can't map CNTCTLBase\n");
> + return 0;
> + }

Why are you continuing when you can't find a base address or the remap fails?

> + /*
> +  * Get Generic Timer Counter-timer Timer ID Register
> +  * for Virtual Timer Capability info
> +  */
> + cnttidr = arch_timer_mem_cnttidr(gt_block);

Thanks,

tglx

Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT

2016-03-19 Thread Arnd Bergmann

On Monday 14 March 2016 18:51:08 Peter Chen wrote:
> On Wed, Mar 09, 2016 at 05:16:50PM -0600, Li Yang wrote:
> > On Tue, Mar 8, 2016 at 9:40 PM, Bjorn Andersson
> >  wrote:
> > > On Tue, Mar 8, 2016 at 11:52 AM, Li Yang  wrote:
> > >> On Wed, Mar 2, 2016 at 4:59 PM, Li Yang  wrote:
> > >>> On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson
> > >>>  wrote:
> >  On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote:
> > >
> > > I had the chance to go through this with Arnd and the verdict is that
> > > devices not described in DT should not do DMA (or allocate buffers for
> > > doing DMA).
> > >
> > > So I believe the solution is to fall back on Peter's description; the
> > > chipidea driver is the core driver and the Qualcomm code should just
> > > be a platform layer.
> > >
> > > My suggestion is that we turn the chipidea core into a set of APIs
> > > that can called by the platform specific pieces. That way we will have
> > > the chipidea core be the device described in the DT.
> > 
> > But like I said, this problem is not just existing for chipidea
> > driver.  We already found that the dwc3 driver is also suffering from
> > the same issue.  I don't know how many other drivers are impacted by
> > this change, but I suspect there will be some. A grep of
> > platform_device_add() in driver/ directory returns many possible
> > drivers to be impacted.  As far as I know, the
> > drivers/net/ethernet/freescale/fman/mac.c is registering child
> > ethernet devices that definitely will do dma.   If you want to do this
> > kind of rework to all these drivers, it will be a really big effort.
> > 
> 
> +1
> 
> Yes, I think this DMA things should be covered by driver core too.
> 

I don't think it's a very widespread problem, there are only very few
developers that intentionally use this method, and some use the
platform_device_register_full() call to create a device with a known
mask, which is generally ok for the limited case where the driver
is only ever going to run on a single platform, but not in the
more general case that of_dma_configure is designed to handle.

I think we should fix the drivers to consistently use the device
that was created by the platform (DT or ACPI or board file)
to pass that into the DMA API, anything else will just cause
more subtle bugs.

Arnd

Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT

2016-03-19 Thread Arnd Bergmann

On Monday 14 March 2016 18:51:08 Peter Chen wrote:
> On Wed, Mar 09, 2016 at 05:16:50PM -0600, Li Yang wrote:
> > On Tue, Mar 8, 2016 at 9:40 PM, Bjorn Andersson
> >  wrote:
> > > On Tue, Mar 8, 2016 at 11:52 AM, Li Yang  wrote:
> > >> On Wed, Mar 2, 2016 at 4:59 PM, Li Yang  wrote:
> > >>> On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson
> > >>>  wrote:
> >  On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote:
> > >
> > > I had the chance to go through this with Arnd and the verdict is that
> > > devices not described in DT should not do DMA (or allocate buffers for
> > > doing DMA).
> > >
> > > So I believe the solution is to fall back on Peter's description; the
> > > chipidea driver is the core driver and the Qualcomm code should just
> > > be a platform layer.
> > >
> > > My suggestion is that we turn the chipidea core into a set of APIs
> > > that can called by the platform specific pieces. That way we will have
> > > the chipidea core be the device described in the DT.
> > 
> > But like I said, this problem is not just existing for chipidea
> > driver.  We already found that the dwc3 driver is also suffering from
> > the same issue.  I don't know how many other drivers are impacted by
> > this change, but I suspect there will be some. A grep of
> > platform_device_add() in driver/ directory returns many possible
> > drivers to be impacted.  As far as I know, the
> > drivers/net/ethernet/freescale/fman/mac.c is registering child
> > ethernet devices that definitely will do dma.   If you want to do this
> > kind of rework to all these drivers, it will be a really big effort.
> > 
> 
> +1
> 
> Yes, I think this DMA things should be covered by driver core too.
> 

I don't think it's a very widespread problem, there are only very few
developers that intentionally use this method, and some use the
platform_device_register_full() call to create a device with a known
mask, which is generally ok for the limited case where the driver
is only ever going to run on a single platform, but not in the
more general case that of_dma_configure is designed to handle.

I think we should fix the drivers to consistently use the device
that was created by the platform (DT or ACPI or board file)
to pass that into the DMA API, anything else will just cause
more subtle bugs.

Arnd

Re: [PATCH 14/15] dt-bindings: arm-gic: Drop 'clock-names' from binding document

2016-03-19 Thread Geert Uytterhoeven

Hi Grygorii,

On Fri, Mar 18, 2016 at 1:47 PM, Grygorii Strashko
 wrote:
> On 03/18/2016 02:05 PM, Geert Uytterhoeven wrote:
>> On Fri, Mar 18, 2016 at 11:56 AM, Jon Hunter  wrote:
>>> On 18/03/16 10:52, Geert Uytterhoeven wrote:
 On Fri, Mar 18, 2016 at 11:13 AM, Jon Hunter  wrote:
> On 18/03/16 09:13, Geert Uytterhoeven wrote:
>> On Thu, Mar 17, 2016 at 3:19 PM, Jon Hunter  wrote:
>>> Commit afbbd2338176 ("irqchip/gic: Document optional Clock and Power
>>> Domain properties") documented optional clock and power-dmoain 
>>> properties
>>> for the ARM GIC. Currently, there are no users of these and for the
>>> Tegra210 Audio GIC (based upon the GIC-400) there are two clocks, a
>>> functional clock and interface clock, that need to be enabled.
>>
>> The reason that there are no users for this is twofold:
>>1. The GIC driver doesn't have Runtime PM support yet,
>>2. There was no clean way to prevent the GIC's clock from being 
>> disabled.
>> Due to this, adding the clocks to the DTSes would mean that they will be
>> disabled during boot up as unused clocks, leading to a system lock-up.
>>
>> I had hoped your series would fix part 1. I gave it a try on 
>> r8a7791/koelsch,
>> but unfortunately it seems the platform driver only supports non-root
>> controllers, while the r8a7791 GIC is the primary one...
>
> Can you try making the following change ...

 Thanks! I gave it a try, but no difference.
>>>
>>> I assume you added the appropriate compatible flag? Any more details you
>>
>> Doh... bad assumption... Silly me.
>>
>>> can share about why it is not working? Is it not registered early enough?
>>
>> With
>>
>> +   { .compatible = "arm,gic-400", },
>>
>> the kernel no longer crashes due to accessing the GIC registers while the
>> GIC module clock is disabled.
>>
>> However, the system doesn't boot completely, and time outs on SPI transfers
>> make me believe interrupts are not working.
>> Both with and without "the following change".
>>
>
> Is my assumption correct that you are trying to enable RPM for primary GIC 
> controller?

That's correct.

> If yes it may help to take a look on clocksource drivers which use 
> early_platform_device/driver
> sh_cmt.c sh_mtu2.c sh_tmu.c
>
> The primary interrupt controller is initialized very early 
> init_IRQ->irqchip_init->of_irq_init()
> (IRQCHIP_DECLARE) and, at least as i can see from st_xxx code, the same case 
> is valid for
> clocksource devices and it was solved using early_platform_device/drive staff.

The GIC now depends on the clock driver, which may be a real platform driver,
not initialized from CLK_OF_DECLARE().

Or do you mean to make the clock driver an early platform driver?

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH 14/15] dt-bindings: arm-gic: Drop 'clock-names' from binding document

2016-03-19 Thread Geert Uytterhoeven

Hi Grygorii,

On Fri, Mar 18, 2016 at 1:47 PM, Grygorii Strashko
 wrote:
> On 03/18/2016 02:05 PM, Geert Uytterhoeven wrote:
>> On Fri, Mar 18, 2016 at 11:56 AM, Jon Hunter  wrote:
>>> On 18/03/16 10:52, Geert Uytterhoeven wrote:
 On Fri, Mar 18, 2016 at 11:13 AM, Jon Hunter  wrote:
> On 18/03/16 09:13, Geert Uytterhoeven wrote:
>> On Thu, Mar 17, 2016 at 3:19 PM, Jon Hunter  wrote:
>>> Commit afbbd2338176 ("irqchip/gic: Document optional Clock and Power
>>> Domain properties") documented optional clock and power-dmoain 
>>> properties
>>> for the ARM GIC. Currently, there are no users of these and for the
>>> Tegra210 Audio GIC (based upon the GIC-400) there are two clocks, a
>>> functional clock and interface clock, that need to be enabled.
>>
>> The reason that there are no users for this is twofold:
>>1. The GIC driver doesn't have Runtime PM support yet,
>>2. There was no clean way to prevent the GIC's clock from being 
>> disabled.
>> Due to this, adding the clocks to the DTSes would mean that they will be
>> disabled during boot up as unused clocks, leading to a system lock-up.
>>
>> I had hoped your series would fix part 1. I gave it a try on 
>> r8a7791/koelsch,
>> but unfortunately it seems the platform driver only supports non-root
>> controllers, while the r8a7791 GIC is the primary one...
>
> Can you try making the following change ...

 Thanks! I gave it a try, but no difference.
>>>
>>> I assume you added the appropriate compatible flag? Any more details you
>>
>> Doh... bad assumption... Silly me.
>>
>>> can share about why it is not working? Is it not registered early enough?
>>
>> With
>>
>> +   { .compatible = "arm,gic-400", },
>>
>> the kernel no longer crashes due to accessing the GIC registers while the
>> GIC module clock is disabled.
>>
>> However, the system doesn't boot completely, and time outs on SPI transfers
>> make me believe interrupts are not working.
>> Both with and without "the following change".
>>
>
> Is my assumption correct that you are trying to enable RPM for primary GIC 
> controller?

That's correct.

> If yes it may help to take a look on clocksource drivers which use 
> early_platform_device/driver
> sh_cmt.c sh_mtu2.c sh_tmu.c
>
> The primary interrupt controller is initialized very early 
> init_IRQ->irqchip_init->of_irq_init()
> (IRQCHIP_DECLARE) and, at least as i can see from st_xxx code, the same case 
> is valid for
> clocksource devices and it was solved using early_platform_device/drive staff.

The GIC now depends on the clock driver, which may be a real platform driver,
not initialized from CLK_OF_DECLARE().

Or do you mean to make the clock driver an early platform driver?

Gr{oetje,eeting}s,

Geert

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

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

Re: Oops from calibrate_delay_is_known on qemu machine with Linux v4.5-1523-g271ecc5253e2

2016-03-19 Thread Richard W.M. Jones

On Thu, Mar 17, 2016 at 01:54:36PM -0400, Josh Boyer wrote:
> Hi Thomas,
> 
> We've had a report [1] of the mainline kernel crashing on a single-cpu
> QEMU machine (not kvm) in Fedora.  It looks as if the emulated machine
> is failing to provide a TSC and the calibrate_delay_is_known function
> is passing NULL to cpumask_any_but for the mask parameter.  At least
> that's all I've been able to discern thus far.
> 
> I was wondering if you had any insight into this issue, given your
> recent commit to change calibrate_delay_is_known to use
> topology_core_cpumask.  The backtrace is below.

Thanks for reporting this upstream Josh.

I've added to the bug a simple test script that reproduces the issue,
not 100% reliably by any means, but some of the time.  See:

  https://bugzilla.redhat.com/show_bug.cgi?id=1318596#c6

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

Re: Suspicious error for CMA stress test

2016-03-19 Thread Joonsoo Kim

2016-03-17 18:24 GMT+09:00 Hanjun Guo :
> On 2016/3/17 14:54, Joonsoo Kim wrote:
>> On Wed, Mar 16, 2016 at 05:44:28PM +0800, Hanjun Guo wrote:
>>> On 2016/3/14 15:18, Joonsoo Kim wrote:
 On Mon, Mar 14, 2016 at 08:06:16AM +0100, Vlastimil Babka wrote:
> On 03/14/2016 07:49 AM, Joonsoo Kim wrote:
>> On Fri, Mar 11, 2016 at 06:07:40PM +0100, Vlastimil Babka wrote:
>>> On 03/11/2016 04:00 PM, Joonsoo Kim wrote:
>>>
>>> How about something like this? Just and idea, probably buggy 
>>> (off-by-one etc.).
>>> Should keep away cost from >> of the
>>> relatively fewer >pageblock_order iterations.
>> Hmm... I tested this and found that it's code size is a little bit
>> larger than mine. I'm not sure why this happens exactly but I guess it 
>> would be
>> related to compiler optimization. In this case, I'm in favor of my
>> implementation because it looks like well abstraction. It adds one
>> unlikely branch to the merge loop but compiler would optimize it to
>> check it once.
> I would be surprised if compiler optimized that to check it once, as
> order increases with each loop iteration. But maybe it's smart
> enough to do something like I did by hand? Guess I'll check the
> disassembly.
 Okay. I used following slightly optimized version and I need to
 add 'max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1)'
 to yours. Please consider it, too.
>>> Hmm, this one is not work, I still can see the bug is there after applying
>>> this patch, did I miss something?
>> I may find that there is a bug which was introduced by me some time
>> ago. Could you test following change in __free_one_page() on top of
>> Vlastimil's patch?
>>
>> -page_idx = pfn & ((1 << max_order) - 1);
>> +page_idx = pfn & ((1 << MAX_ORDER) - 1);
>
> I tested Vlastimil's patch + your change with stress for more than half hour, 
> the bug
> I reported is gone :)

Good to hear!

> I have some questions, Joonsoo, you provided a patch as following:
>
> diff --git a/mm/cma.c b/mm/cma.c
> index 3a7a67b..952a8a3 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -448,7 +448,10 @@ bool cma_release(struct cma *cma, const struct page 
> *pages, unsigned int count)
>
> VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
>
> + mutex_lock(_mutex);
> free_contig_range(pfn, count);
> + mutex_unlock(_mutex);
> +
> cma_clear_bitmap(cma, pfn, count);
> trace_cma_release(pfn, pages, count);
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7f32950..68ed5ae 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1559,7 +1559,8 @@ void free_hot_cold_page(struct page *page, bool cold)
>  * excessively into the page allocator
>  */
> if (migratetype >= MIGRATE_PCPTYPES) {
> -   if (unlikely(is_migrate_isolate(migratetype))) {
> + if (is_migrate_cma(migratetype) ||
> + unlikely(is_migrate_isolate(migratetype))) {
> free_one_page(zone, page, pfn, 0, migratetype);
> goto out;
> }
>
> This patch also works to fix the bug, why not just use this one? is there
> any side effects for this patch? maybe there is performance issue as the
> mutex lock is used, any other issues?

The changes in free_hot_cold_page() would cause unacceptable performance
problem in a big machine, because, with above change,  it takes zone->lock
whenever freeing one page on CMA region.

Thanks.

Re: Oops from calibrate_delay_is_known on qemu machine with Linux v4.5-1523-g271ecc5253e2

2016-03-19 Thread Richard W.M. Jones

On Thu, Mar 17, 2016 at 01:54:36PM -0400, Josh Boyer wrote:
> Hi Thomas,
> 
> We've had a report [1] of the mainline kernel crashing on a single-cpu
> QEMU machine (not kvm) in Fedora.  It looks as if the emulated machine
> is failing to provide a TSC and the calibrate_delay_is_known function
> is passing NULL to cpumask_any_but for the mask parameter.  At least
> that's all I've been able to discern thus far.
> 
> I was wondering if you had any insight into this issue, given your
> recent commit to change calibrate_delay_is_known to use
> topology_core_cpumask.  The backtrace is below.

Thanks for reporting this upstream Josh.

I've added to the bug a simple test script that reproduces the issue,
not 100% reliably by any means, but some of the time.  See:

  https://bugzilla.redhat.com/show_bug.cgi?id=1318596#c6

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

Re: Suspicious error for CMA stress test

2016-03-19 Thread Joonsoo Kim

2016-03-17 18:24 GMT+09:00 Hanjun Guo :
> On 2016/3/17 14:54, Joonsoo Kim wrote:
>> On Wed, Mar 16, 2016 at 05:44:28PM +0800, Hanjun Guo wrote:
>>> On 2016/3/14 15:18, Joonsoo Kim wrote:
 On Mon, Mar 14, 2016 at 08:06:16AM +0100, Vlastimil Babka wrote:
> On 03/14/2016 07:49 AM, Joonsoo Kim wrote:
>> On Fri, Mar 11, 2016 at 06:07:40PM +0100, Vlastimil Babka wrote:
>>> On 03/11/2016 04:00 PM, Joonsoo Kim wrote:
>>>
>>> How about something like this? Just and idea, probably buggy 
>>> (off-by-one etc.).
>>> Should keep away cost from >> of the
>>> relatively fewer >pageblock_order iterations.
>> Hmm... I tested this and found that it's code size is a little bit
>> larger than mine. I'm not sure why this happens exactly but I guess it 
>> would be
>> related to compiler optimization. In this case, I'm in favor of my
>> implementation because it looks like well abstraction. It adds one
>> unlikely branch to the merge loop but compiler would optimize it to
>> check it once.
> I would be surprised if compiler optimized that to check it once, as
> order increases with each loop iteration. But maybe it's smart
> enough to do something like I did by hand? Guess I'll check the
> disassembly.
 Okay. I used following slightly optimized version and I need to
 add 'max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1)'
 to yours. Please consider it, too.
>>> Hmm, this one is not work, I still can see the bug is there after applying
>>> this patch, did I miss something?
>> I may find that there is a bug which was introduced by me some time
>> ago. Could you test following change in __free_one_page() on top of
>> Vlastimil's patch?
>>
>> -page_idx = pfn & ((1 << max_order) - 1);
>> +page_idx = pfn & ((1 << MAX_ORDER) - 1);
>
> I tested Vlastimil's patch + your change with stress for more than half hour, 
> the bug
> I reported is gone :)

Good to hear!

> I have some questions, Joonsoo, you provided a patch as following:
>
> diff --git a/mm/cma.c b/mm/cma.c
> index 3a7a67b..952a8a3 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -448,7 +448,10 @@ bool cma_release(struct cma *cma, const struct page 
> *pages, unsigned int count)
>
> VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
>
> + mutex_lock(_mutex);
> free_contig_range(pfn, count);
> + mutex_unlock(_mutex);
> +
> cma_clear_bitmap(cma, pfn, count);
> trace_cma_release(pfn, pages, count);
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7f32950..68ed5ae 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1559,7 +1559,8 @@ void free_hot_cold_page(struct page *page, bool cold)
>  * excessively into the page allocator
>  */
> if (migratetype >= MIGRATE_PCPTYPES) {
> -   if (unlikely(is_migrate_isolate(migratetype))) {
> + if (is_migrate_cma(migratetype) ||
> + unlikely(is_migrate_isolate(migratetype))) {
> free_one_page(zone, page, pfn, 0, migratetype);
> goto out;
> }
>
> This patch also works to fix the bug, why not just use this one? is there
> any side effects for this patch? maybe there is performance issue as the
> mutex lock is used, any other issues?

The changes in free_hot_cold_page() would cause unacceptable performance
problem in a big machine, because, with above change,  it takes zone->lock
whenever freeing one page on CMA region.

Thanks.

Re: [PATCH v2] staging/comedi/dt282x: avoid integer overflow warning

2016-03-19 Thread Arnd Bergmann

On Thursday 17 March 2016 15:47:57 Hartley Sweeten wrote:
> On Wednesday, March 16, 2016 1:51 PM, Arnd Bergmann wrote:
> 
> Is this a gcc-6 specific issue? Seems line this warning should be showing
> up in a lot of drivers.

Yes, I did not see this before moving to gcc-6.0, but this is the only driver
I've encountered the warning for, in around 7000 randconfig builds.

> > The warning makes sense, though the code is correct as far as I
> > can tell.
> >
> > This disambiguates the operation by making the constant expressions
> > we pass here explicitly 'unsigned', which helps to avoid the warning.
> >
> > As pointed out by Hartley Sweeten, scripts/checkpatch.pl notices that
> > the shifts here are rather unreadable, though the suggested BIT()
> > macro wouldn't work either. I'm changing it to a hexadecimal notation,
> > which hopefully improves readability. I'm leaving the DT2821_CHANCSR_PRESLA
> > alone because it seems wrong.
> 
> BIT() should work for the ones pointed out by checpatch.pl.
> 
> I would argue that the hexadecimal notation is still rather unreadable.
> These ones make my head hurt...
> 
> -#define DT2821_ADCSR_GS(x)   (((x) & 0x3) << 4)
> +#define DT2821_ADCSR_GS(x)  (0x0030u & ((x) << 4))
> 
> -#define DT2821_DACSR_YSEL(x) ((x) << 9)
> +#define DT2821_DACSR_YSEL(x)(0x7e00u & (x) << 9)
> 
> -#define DT2821_SUPCSR_DS_PIO (0 << 10)
> -#define DT2821_SUPCSR_DS_AD_CLK  (1 << 10)
> -#define DT2821_SUPCSR_DS_DA_CLK  (2 << 10)
> -#define DT2821_SUPCSR_DS_AD_TRIG (3 << 10)
> +#define DT2821_SUPCSR_DS_PIO(0x0c00u & (0u << 10))
> +#define DT2821_SUPCSR_DS_AD_CLK (0x0c00u & (1u << 10))
> +#define DT2821_SUPCSR_DS_DA_CLK (0x0c00u & (2u << 10))
> +#define DT2821_SUPCSR_DS_AD_TRIG   (0x0c00u & (3u << 10))

Feel free to come up with a different patch. I've put the patch on
my 'submitted' stack for now and will get back to it after 4.7-rc1 if
the warning remains.

> Also, most of the comedi drivers use the BIT() macro. Are you planning on
> changing all of them to use hexadecimal notation?

No.

Arnd

Re: [PATCH v2] staging/comedi/dt282x: avoid integer overflow warning

2016-03-19 Thread Arnd Bergmann

On Thursday 17 March 2016 15:47:57 Hartley Sweeten wrote:
> On Wednesday, March 16, 2016 1:51 PM, Arnd Bergmann wrote:
> 
> Is this a gcc-6 specific issue? Seems line this warning should be showing
> up in a lot of drivers.

Yes, I did not see this before moving to gcc-6.0, but this is the only driver
I've encountered the warning for, in around 7000 randconfig builds.

> > The warning makes sense, though the code is correct as far as I
> > can tell.
> >
> > This disambiguates the operation by making the constant expressions
> > we pass here explicitly 'unsigned', which helps to avoid the warning.
> >
> > As pointed out by Hartley Sweeten, scripts/checkpatch.pl notices that
> > the shifts here are rather unreadable, though the suggested BIT()
> > macro wouldn't work either. I'm changing it to a hexadecimal notation,
> > which hopefully improves readability. I'm leaving the DT2821_CHANCSR_PRESLA
> > alone because it seems wrong.
> 
> BIT() should work for the ones pointed out by checpatch.pl.
> 
> I would argue that the hexadecimal notation is still rather unreadable.
> These ones make my head hurt...
> 
> -#define DT2821_ADCSR_GS(x)   (((x) & 0x3) << 4)
> +#define DT2821_ADCSR_GS(x)  (0x0030u & ((x) << 4))
> 
> -#define DT2821_DACSR_YSEL(x) ((x) << 9)
> +#define DT2821_DACSR_YSEL(x)(0x7e00u & (x) << 9)
> 
> -#define DT2821_SUPCSR_DS_PIO (0 << 10)
> -#define DT2821_SUPCSR_DS_AD_CLK  (1 << 10)
> -#define DT2821_SUPCSR_DS_DA_CLK  (2 << 10)
> -#define DT2821_SUPCSR_DS_AD_TRIG (3 << 10)
> +#define DT2821_SUPCSR_DS_PIO(0x0c00u & (0u << 10))
> +#define DT2821_SUPCSR_DS_AD_CLK (0x0c00u & (1u << 10))
> +#define DT2821_SUPCSR_DS_DA_CLK (0x0c00u & (2u << 10))
> +#define DT2821_SUPCSR_DS_AD_TRIG   (0x0c00u & (3u << 10))

Feel free to come up with a different patch. I've put the patch on
my 'submitted' stack for now and will get back to it after 4.7-rc1 if
the warning remains.

> Also, most of the comedi drivers use the BIT() macro. Are you planning on
> changing all of them to use hexadecimal notation?

No.

Arnd

Re: [PATCH v3 7/8] Documentation: devicetree: rockchip: Document Landingship

2016-03-19 Thread Rob Herring

On Sun, Mar 06, 2016 at 08:53:56PM +0100, Andreas Färber wrote:
> Use "geekbuying,geekbox-landingship" compatible string, plus those of
> the GeekBox module.
> 
> Signed-off-by: Andreas Färber 
> ---
>  v2 -> v3:
>  * Changed compatible string to include geekbox- (Heiko)
>and clarify that this is for GeekBox module
>  
>  v2: New
>  
>  Documentation/devicetree/bindings/arm/rockchip.txt | 5 +
>  1 file changed, 5 insertions(+)

Acked-by: Rob Herring

Re: [PATCH v3 7/8] Documentation: devicetree: rockchip: Document Landingship

2016-03-19 Thread Rob Herring

On Sun, Mar 06, 2016 at 08:53:56PM +0100, Andreas Färber wrote:
> Use "geekbuying,geekbox-landingship" compatible string, plus those of
> the GeekBox module.
> 
> Signed-off-by: Andreas Färber 
> ---
>  v2 -> v3:
>  * Changed compatible string to include geekbox- (Heiko)
>and clarify that this is for GeekBox module
>  
>  v2: New
>  
>  Documentation/devicetree/bindings/arm/rockchip.txt | 5 +
>  1 file changed, 5 insertions(+)

Acked-by: Rob Herring

[PATCH BlueZ v5] tools/btattach: add marvell support

2016-03-19 Thread Amitkumar Karwar

From: Ganapathi Bhat 

User needs to issue below command for Marvell devices
btattach -P marvell -B /dev/ttyUSB#

---
 tools/btattach.c  | 1 +
 tools/hciattach.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/tools/btattach.c b/tools/btattach.c
index a025bb0..7807e9f 100644
--- a/tools/btattach.c
+++ b/tools/btattach.c
@@ -214,6 +214,7 @@ static const struct {
{ "intel", HCI_UART_INTEL },
{ "bcm",   HCI_UART_BCM   },
{ "qca",   HCI_UART_QCA   },
+   { "marvell", HCI_UART_MRVL   },
{ }
 };
 
diff --git a/tools/hciattach.h b/tools/hciattach.h
index 4279a33..e109c3e 100644
--- a/tools/hciattach.h
+++ b/tools/hciattach.h
@@ -42,6 +42,7 @@
 #define HCI_UART_INTEL 6
 #define HCI_UART_BCM   7
 #define HCI_UART_QCA   8
+#define HCI_UART_MRVL  10
 
 #define HCI_UART_RAW_DEVICE0
 #define HCI_UART_RESET_ON_INIT 1
-- 
1.9.1

[PATCH BlueZ v5] tools/btattach: add marvell support

2016-03-19 Thread Amitkumar Karwar

From: Ganapathi Bhat 

User needs to issue below command for Marvell devices
btattach -P marvell -B /dev/ttyUSB#

---
 tools/btattach.c  | 1 +
 tools/hciattach.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/tools/btattach.c b/tools/btattach.c
index a025bb0..7807e9f 100644
--- a/tools/btattach.c
+++ b/tools/btattach.c
@@ -214,6 +214,7 @@ static const struct {
{ "intel", HCI_UART_INTEL },
{ "bcm",   HCI_UART_BCM   },
{ "qca",   HCI_UART_QCA   },
+   { "marvell", HCI_UART_MRVL   },
{ }
 };
 
diff --git a/tools/hciattach.h b/tools/hciattach.h
index 4279a33..e109c3e 100644
--- a/tools/hciattach.h
+++ b/tools/hciattach.h
@@ -42,6 +42,7 @@
 #define HCI_UART_INTEL 6
 #define HCI_UART_BCM   7
 #define HCI_UART_QCA   8
+#define HCI_UART_MRVL  10
 
 #define HCI_UART_RAW_DEVICE0
 #define HCI_UART_RESET_ON_INIT 1
-- 
1.9.1

Re: [GIT PULL] Score: Fix the check condition of get_sigframe

2016-03-19 Thread Linus Torvalds

On Tue, Mar 15, 2016 at 9:33 AM, Lennox Wu  wrote:
>
>   git://github.com/sctscore/linux-off.git sig

Please use a signed tag for github pull requests. I don't pull
unsigned branches from open hosting sites.

Yeah, yeah, I know this is a one-liner, and I could just eyeball the
end result to make sure it really looks fine, but still.. I really
want signing to be standard procedure for open hosting pulls.

Linus

Re: [GIT PULL] Score: Fix the check condition of get_sigframe

2016-03-19 Thread Linus Torvalds

On Tue, Mar 15, 2016 at 9:33 AM, Lennox Wu  wrote:
>
>   git://github.com/sctscore/linux-off.git sig

Please use a signed tag for github pull requests. I don't pull
unsigned branches from open hosting sites.

Yeah, yeah, I know this is a one-liner, and I could just eyeball the
end result to make sure it really looks fine, but still.. I really
want signing to be standard procedure for open hosting pulls.

Linus

Re: [PATCH 0/2] usb: dwc3: gadget: Fix erratic interrupts and delayed enumeration

2016-03-19 Thread Felipe Balbi


Hi,

Roger Quadros  writes:
> The existing workaround (for STAR#9000525659) of forcing
> DEVSPD to SUPER_SPEED for HIGH_SPEED ports is causing
> another side effect which causes erratic interrupts and delayed gadget
> enumeration of upto 2 seconds.

right, but the real problem is with an SoC which wants to force lower
speed on an IP that can't support it ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 0/2] usb: dwc3: gadget: Fix erratic interrupts and delayed enumeration

2016-03-19 Thread Felipe Balbi


Hi,

Roger Quadros  writes:
> The existing workaround (for STAR#9000525659) of forcing
> DEVSPD to SUPER_SPEED for HIGH_SPEED ports is causing
> another side effect which causes erratic interrupts and delayed gadget
> enumeration of upto 2 seconds.

right, but the real problem is with an SoC which wants to force lower
speed on an IP that can't support it ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 4/4] dma: qcom_hidma: read the channel id from HW

2016-03-19 Thread Rob Herring

On Fri, Mar 11, 2016 at 04:49:54PM -0500, Sinan Kaya wrote:
> Removing the flexibility to choose the event channel as there is no real
> use case right now. We have been using the values in ACPI that match the HW
> defaults. OS is reading the event-channel from the HW register now.
> 
> Signed-off-by: Sinan Kaya 
> ---
>  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  3 --

Acked-by: Rob Herring 

>  drivers/dma/qcom/hidma.c   | 39 
> +-
>  2 files changed, 1 insertion(+), 41 deletions(-)

Re: [PATCH 4/4] dma: qcom_hidma: read the channel id from HW

2016-03-19 Thread Rob Herring

On Fri, Mar 11, 2016 at 04:49:54PM -0500, Sinan Kaya wrote:
> Removing the flexibility to choose the event channel as there is no real
> use case right now. We have been using the values in ACPI that match the HW
> defaults. OS is reading the event-channel from the HW register now.
> 
> Signed-off-by: Sinan Kaya 
> ---
>  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  3 --

Acked-by: Rob Herring 

>  drivers/dma/qcom/hidma.c   | 39 
> +-
>  2 files changed, 1 insertion(+), 41 deletions(-)

Re: [PATCH 4/5] rtc: jz4740_rtc: Add support for acting as the system power controller

2016-03-19 Thread Alexandre Belloni

On 05/03/2016 at 23:38:50 +0100, Paul Cercueil wrote :
> + if (of_device_is_system_power_controller(pdev->dev.of_node)) {
> + if (!pm_power_off) {
> + /* Default: 60ms */
> + rtc->reset_pin_assert_time = 60;
> + device_property_read_u32(>dev,

It is probably more efficient to use of_property_read_u32 directly. Any
particular reason to use device_property_read_u32?

> + } else {
> + dev_err(>dev,
> + "Poweroff handler already present!\n");

I'm not found of that alignement, it is probably better to let the
string go over 80 chars. checkpatch will not complain.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 4/5] rtc: jz4740_rtc: Add support for acting as the system power controller

2016-03-19 Thread Alexandre Belloni

On 05/03/2016 at 23:38:50 +0100, Paul Cercueil wrote :
> + if (of_device_is_system_power_controller(pdev->dev.of_node)) {
> + if (!pm_power_off) {
> + /* Default: 60ms */
> + rtc->reset_pin_assert_time = 60;
> + device_property_read_u32(>dev,

It is probably more efficient to use of_property_read_u32 directly. Any
particular reason to use device_property_read_u32?

> + } else {
> + dev_err(>dev,
> + "Poweroff handler already present!\n");

I'm not found of that alignement, it is probably better to let the
string go over 80 chars. checkpatch will not complain.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 3664 matches

Mail list logo