Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Gabriel C]

On 18.02.2017 00:25, Cong Wang wrote:

On Fri, Feb 17, 2017 at 3:16 PM, Gabriel C  wrote:



On 17.02.2017 23:38, Cong Wang wrote:


On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C  wrote:


Hi all,

while poking at a different issue I found the following on my logs :

[85362.132770] BUG: sleeping function called from invalid context at
kernel/irq/manage.c:110
[85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153, name:
systemd-journal
[85362.132772] no locks held by systemd-journal/1153.
[85362.132772] irq event stamp: 60088359
[85362.132777] hardirqs last  enabled at (60088359): []
vprintk_emit+0x432/0x470
[85362.132779] hardirqs last disabled at (60088358): []
vprintk_emit+0x5c/0x470
[85362.132782] softirqs last  enabled at (60088258): []
__do_softirq+0x22d/0x290
[85362.132784] softirqs last disabled at (60088233): []
irq_exit+0x6a/0xd0
[85362.132784] Preemption disabled at:
[85362.132787] [] write_msg+0x4e/0xf0
[85362.132790] CPU: 0 PID: 1153 Comm: systemd-journal Tainted: G
I
4.10.0-rc8-debug-1-ga1015e374d94-dirty #5
[85362.132791] Hardware name: FUJITSU  PRIMERGY
TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709
02/04/2013
[85362.132792] Call Trace:
[85362.132796]  dump_stack+0x86/0xc1
[85362.132799]  ___might_sleep+0x213/0x230
[85362.132801]  __might_sleep+0x6b/0x80
[85362.132803]  synchronize_irq+0x33/0x90
[85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
[85362.132807]  ? __disable_irq_nosync+0x4e/0x60
[85362.132808]  disable_irq+0x17/0x20




Hmm, your kernel base version is 4.10.0-rc8 but the symbols here
look like prior to my commit, because with my commit here should
be disable_hardirq() calling synchronize_hardirq().

Did you revert it or make any local changes?



The kernel is -rc8 with reverted d966564fcdc19e13eb6ba1fbe6b8101070339c3d
+
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=202461e2f3c15dbfb05825d29ace0d20cdf55fa4
+ an debug patch from Thomas to find these goldfish issues.
(
http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/goldfish-debug.patch
)

No other changes..


That is weird, the stack trace doesn't match the source code for some reason.
Can you objdump your e1000.ko module to see if that is true?



My card seems to use the e1000e driver which is buit-in..

Anyway here an objdump -x :

http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/objdump-x_e1000.ko.txt

Re: [PATCH 4.4 00/20] 4.4.50-stable review

[Greg Kroah-Hartman]

On Fri, Feb 17, 2017 at 11:28:43AM -0800, kernelci.org bot wrote:
> stable-rc boot: 31 boots: 0 failed, 31 passed (v4.4.49-21-g967e7e889dce)

Better than the 4.9 number of boots, but still odd...

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Gabriel C]

On 18.02.2017 00:25, Cong Wang wrote:

On Fri, Feb 17, 2017 at 3:16 PM, Gabriel C  wrote:



On 17.02.2017 23:38, Cong Wang wrote:


On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C  wrote:


Hi all,

while poking at a different issue I found the following on my logs :

[85362.132770] BUG: sleeping function called from invalid context at
kernel/irq/manage.c:110
[85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153, name:
systemd-journal
[85362.132772] no locks held by systemd-journal/1153.
[85362.132772] irq event stamp: 60088359
[85362.132777] hardirqs last  enabled at (60088359): []
vprintk_emit+0x432/0x470
[85362.132779] hardirqs last disabled at (60088358): []
vprintk_emit+0x5c/0x470
[85362.132782] softirqs last  enabled at (60088258): []
__do_softirq+0x22d/0x290
[85362.132784] softirqs last disabled at (60088233): []
irq_exit+0x6a/0xd0
[85362.132784] Preemption disabled at:
[85362.132787] [] write_msg+0x4e/0xf0
[85362.132790] CPU: 0 PID: 1153 Comm: systemd-journal Tainted: G
I
4.10.0-rc8-debug-1-ga1015e374d94-dirty #5
[85362.132791] Hardware name: FUJITSU  PRIMERGY
TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709
02/04/2013
[85362.132792] Call Trace:
[85362.132796]  dump_stack+0x86/0xc1
[85362.132799]  ___might_sleep+0x213/0x230
[85362.132801]  __might_sleep+0x6b/0x80
[85362.132803]  synchronize_irq+0x33/0x90
[85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
[85362.132807]  ? __disable_irq_nosync+0x4e/0x60
[85362.132808]  disable_irq+0x17/0x20




Hmm, your kernel base version is 4.10.0-rc8 but the symbols here
look like prior to my commit, because with my commit here should
be disable_hardirq() calling synchronize_hardirq().

Did you revert it or make any local changes?



The kernel is -rc8 with reverted d966564fcdc19e13eb6ba1fbe6b8101070339c3d
+
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=202461e2f3c15dbfb05825d29ace0d20cdf55fa4
+ an debug patch from Thomas to find these goldfish issues.
(
http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/goldfish-debug.patch
)

No other changes..


That is weird, the stack trace doesn't match the source code for some reason.
Can you objdump your e1000.ko module to see if that is true?



My card seems to use the e1000e driver which is buit-in..

Anyway here an objdump -x :

http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/objdump-x_e1000.ko.txt

Re: [PATCH 4.4 00/20] 4.4.50-stable review

[Greg Kroah-Hartman]

On Fri, Feb 17, 2017 at 11:28:43AM -0800, kernelci.org bot wrote:
> stable-rc boot: 31 boots: 0 failed, 31 passed (v4.4.49-21-g967e7e889dce)

Better than the 4.9 number of boots, but still odd...

Re: [PATCH 4.9 00/32] 4.9.11-stable review

[Greg Kroah-Hartman]

On Fri, Feb 17, 2017 at 11:28:44AM -0800, kernelci.org bot wrote:
> stable-rc boot: 4 boots: 0 failed, 4 passed (v4.9.10-33-gf6f9e9361112)

That's a small number of boots, really small, what went wrong here?

Do you all need more time?

thanks,

greg k-h

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Cong Wang]

On Fri, Feb 17, 2017 at 3:38 PM, Gabriel C  wrote:
>
> My card seems to use the e1000e driver which is buit-in..
>
> Anyway here an objdump -x :
>
> http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/objdump-x_e1000.ko.txt
>

Found disable_hardirq() but not disable_irq().

Are you sure the kernel warning was emitted by this binary rather than
some old one?

Re: [PATCH 4.9 00/32] 4.9.11-stable review

[Greg Kroah-Hartman]

On Fri, Feb 17, 2017 at 11:28:44AM -0800, kernelci.org bot wrote:
> stable-rc boot: 4 boots: 0 failed, 4 passed (v4.9.10-33-gf6f9e9361112)

That's a small number of boots, really small, what went wrong here?

Do you all need more time?

thanks,

greg k-h

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Cong Wang]

On Fri, Feb 17, 2017 at 3:38 PM, Gabriel C  wrote:
>
> My card seems to use the e1000e driver which is buit-in..
>
> Anyway here an objdump -x :
>
> http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/objdump-x_e1000.ko.txt
>

Found disable_hardirq() but not disable_irq().

Are you sure the kernel warning was emitted by this binary rather than
some old one?

Re: [PATCH net-next v2 2/6] net: dsa: mv88e6xxx: move ATU code in its own file

[David Miller]

From: Andrew Lunn 
Date: Fri, 17 Feb 2017 23:36:51 +0100

> Please take your time to do this right. Lots of small patches, which
> are obviously correct.

Agreed.

Re: [PATCH net-next v2 2/6] net: dsa: mv88e6xxx: move ATU code in its own file

[David Miller]

From: Andrew Lunn 
Date: Fri, 17 Feb 2017 23:36:51 +0100

> Please take your time to do this right. Lots of small patches, which
> are obviously correct.

Agreed.

[PATCH] Make mtdblock can handle partition bigger than 4G.

[Lepton Wu]

Signed-off-by: Lepton Wu 
---
 drivers/mtd/mtdblock.c| 33 +
 drivers/mtd/mtdblock_ro.c |  4 ++--
 2 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
index bb4c14f83c75..3d2da76287a7 100644
--- a/drivers/mtd/mtdblock.c
+++ b/drivers/mtd/mtdblock.c
@@ -61,8 +61,8 @@ static void erase_callback(struct erase_info *done)
wake_up(wait_q);
 }
 
-static int erase_write (struct mtd_info *mtd, unsigned long pos,
-   int len, const char *buf)
+static int erase_write(struct mtd_info *mtd, loff_t pos, int len,
+  const char *buf)
 {
struct erase_info erase;
DECLARE_WAITQUEUE(wait, current);
@@ -88,8 +88,7 @@ static int erase_write (struct mtd_info *mtd, unsigned long 
pos,
if (ret) {
set_current_state(TASK_RUNNING);
remove_wait_queue(_q, );
-   printk (KERN_WARNING "mtdblock: erase of region [0x%lx, 0x%x] "
-"on \"%s\" failed\n",
+   pr_warn("mtdblock: erase of region [0x%llx, 0x%x] on \"%s\" 
failed\n",
pos, len, mtd->name);
return ret;
}
@@ -139,23 +138,24 @@ static int write_cached_data (struct mtdblk_dev *mtdblk)
 }
 
 
-static int do_cached_write (struct mtdblk_dev *mtdblk, unsigned long pos,
-   int len, const char *buf)
+static int do_cached_write(struct mtdblk_dev *mtdblk, loff_t pos,
+  int len, const char *buf)
 {
struct mtd_info *mtd = mtdblk->mbd.mtd;
unsigned int sect_size = mtdblk->cache_size;
size_t retlen;
int ret;
 
-   pr_debug("mtdblock: write on \"%s\" at 0x%lx, size 0x%x\n",
+   pr_debug("mtdblock: write on \"%s\" at 0x%llx, size 0x%x\n",
mtd->name, pos, len);
 
if (!sect_size)
return mtd_write(mtd, pos, len, , buf);
 
while (len > 0) {
-   unsigned long sect_start = (pos/sect_size)*sect_size;
-   unsigned int offset = pos - sect_start;
+   unsigned int offset;
+   loff_t sect_start =
+   div_u64_rem(pos, sect_size, ) * sect_size;
unsigned int size = sect_size - offset;
if( size > len )
size = len;
@@ -209,23 +209,24 @@ static int do_cached_write (struct mtdblk_dev *mtdblk, 
unsigned long pos,
 }
 
 
-static int do_cached_read (struct mtdblk_dev *mtdblk, unsigned long pos,
-  int len, char *buf)
+static int do_cached_read(struct mtdblk_dev *mtdblk, loff_t pos,
+ int len, char *buf)
 {
struct mtd_info *mtd = mtdblk->mbd.mtd;
unsigned int sect_size = mtdblk->cache_size;
size_t retlen;
int ret;
 
-   pr_debug("mtdblock: read on \"%s\" at 0x%lx, size 0x%x\n",
+   pr_debug("mtdblock: read on \"%s\" at 0x%llx, size 0x%x\n",
mtd->name, pos, len);
 
if (!sect_size)
return mtd_read(mtd, pos, len, , buf);
 
while (len > 0) {
-   unsigned long sect_start = (pos/sect_size)*sect_size;
-   unsigned int offset = pos - sect_start;
+   unsigned int offset;
+   loff_t sect_start =
+   div_u64_rem(pos, sect_size, ) * sect_size;
unsigned int size = sect_size - offset;
if (size > len)
size = len;
@@ -259,7 +260,7 @@ static int mtdblock_readsect(struct mtd_blktrans_dev *dev,
  unsigned long block, char *buf)
 {
struct mtdblk_dev *mtdblk = container_of(dev, struct mtdblk_dev, mbd);
-   return do_cached_read(mtdblk, block<<9, 512, buf);
+   return do_cached_read(mtdblk, (loff_t)block<<9, 512, buf);
 }
 
 static int mtdblock_writesect(struct mtd_blktrans_dev *dev,
@@ -275,7 +276,7 @@ static int mtdblock_writesect(struct mtd_blktrans_dev *dev,
 * return -EAGAIN sometimes, but why bother?
 */
}
-   return do_cached_write(mtdblk, block<<9, 512, buf);
+   return do_cached_write(mtdblk, (loff_t)block<<9, 512, buf);
 }
 
 static int mtdblock_open(struct mtd_blktrans_dev *mbd)
diff --git a/drivers/mtd/mtdblock_ro.c b/drivers/mtd/mtdblock_ro.c
index fb5dc89369de..92829e3fb3b7 100644
--- a/drivers/mtd/mtdblock_ro.c
+++ b/drivers/mtd/mtdblock_ro.c
@@ -31,7 +31,7 @@ static int mtdblock_readsect(struct mtd_blktrans_dev *dev,
 {
size_t retlen;
 
-   if (mtd_read(dev->mtd, (block * 512), 512, , buf))
+   if (mtd_read(dev->mtd, (loff_t)block << 9, 512, , buf))
return 1;
return 0;
 }
@@ -41,7 +41,7 @@ static int mtdblock_writesect(struct mtd_blktrans_dev *dev,
 {
size_t retlen;
 
-   if (mtd_write(dev->mtd, (block * 512), 512, , buf))
+   if 

[PATCH] Make mtdblock can handle partition bigger than 4G.

[Lepton Wu]

Signed-off-by: Lepton Wu 
---
 drivers/mtd/mtdblock.c| 33 +
 drivers/mtd/mtdblock_ro.c |  4 ++--
 2 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/mtd/mtdblock.c b/drivers/mtd/mtdblock.c
index bb4c14f83c75..3d2da76287a7 100644
--- a/drivers/mtd/mtdblock.c
+++ b/drivers/mtd/mtdblock.c
@@ -61,8 +61,8 @@ static void erase_callback(struct erase_info *done)
wake_up(wait_q);
 }
 
-static int erase_write (struct mtd_info *mtd, unsigned long pos,
-   int len, const char *buf)
+static int erase_write(struct mtd_info *mtd, loff_t pos, int len,
+  const char *buf)
 {
struct erase_info erase;
DECLARE_WAITQUEUE(wait, current);
@@ -88,8 +88,7 @@ static int erase_write (struct mtd_info *mtd, unsigned long 
pos,
if (ret) {
set_current_state(TASK_RUNNING);
remove_wait_queue(_q, );
-   printk (KERN_WARNING "mtdblock: erase of region [0x%lx, 0x%x] "
-"on \"%s\" failed\n",
+   pr_warn("mtdblock: erase of region [0x%llx, 0x%x] on \"%s\" 
failed\n",
pos, len, mtd->name);
return ret;
}
@@ -139,23 +138,24 @@ static int write_cached_data (struct mtdblk_dev *mtdblk)
 }
 
 
-static int do_cached_write (struct mtdblk_dev *mtdblk, unsigned long pos,
-   int len, const char *buf)
+static int do_cached_write(struct mtdblk_dev *mtdblk, loff_t pos,
+  int len, const char *buf)
 {
struct mtd_info *mtd = mtdblk->mbd.mtd;
unsigned int sect_size = mtdblk->cache_size;
size_t retlen;
int ret;
 
-   pr_debug("mtdblock: write on \"%s\" at 0x%lx, size 0x%x\n",
+   pr_debug("mtdblock: write on \"%s\" at 0x%llx, size 0x%x\n",
mtd->name, pos, len);
 
if (!sect_size)
return mtd_write(mtd, pos, len, , buf);
 
while (len > 0) {
-   unsigned long sect_start = (pos/sect_size)*sect_size;
-   unsigned int offset = pos - sect_start;
+   unsigned int offset;
+   loff_t sect_start =
+   div_u64_rem(pos, sect_size, ) * sect_size;
unsigned int size = sect_size - offset;
if( size > len )
size = len;
@@ -209,23 +209,24 @@ static int do_cached_write (struct mtdblk_dev *mtdblk, 
unsigned long pos,
 }
 
 
-static int do_cached_read (struct mtdblk_dev *mtdblk, unsigned long pos,
-  int len, char *buf)
+static int do_cached_read(struct mtdblk_dev *mtdblk, loff_t pos,
+ int len, char *buf)
 {
struct mtd_info *mtd = mtdblk->mbd.mtd;
unsigned int sect_size = mtdblk->cache_size;
size_t retlen;
int ret;
 
-   pr_debug("mtdblock: read on \"%s\" at 0x%lx, size 0x%x\n",
+   pr_debug("mtdblock: read on \"%s\" at 0x%llx, size 0x%x\n",
mtd->name, pos, len);
 
if (!sect_size)
return mtd_read(mtd, pos, len, , buf);
 
while (len > 0) {
-   unsigned long sect_start = (pos/sect_size)*sect_size;
-   unsigned int offset = pos - sect_start;
+   unsigned int offset;
+   loff_t sect_start =
+   div_u64_rem(pos, sect_size, ) * sect_size;
unsigned int size = sect_size - offset;
if (size > len)
size = len;
@@ -259,7 +260,7 @@ static int mtdblock_readsect(struct mtd_blktrans_dev *dev,
  unsigned long block, char *buf)
 {
struct mtdblk_dev *mtdblk = container_of(dev, struct mtdblk_dev, mbd);
-   return do_cached_read(mtdblk, block<<9, 512, buf);
+   return do_cached_read(mtdblk, (loff_t)block<<9, 512, buf);
 }
 
 static int mtdblock_writesect(struct mtd_blktrans_dev *dev,
@@ -275,7 +276,7 @@ static int mtdblock_writesect(struct mtd_blktrans_dev *dev,
 * return -EAGAIN sometimes, but why bother?
 */
}
-   return do_cached_write(mtdblk, block<<9, 512, buf);
+   return do_cached_write(mtdblk, (loff_t)block<<9, 512, buf);
 }
 
 static int mtdblock_open(struct mtd_blktrans_dev *mbd)
diff --git a/drivers/mtd/mtdblock_ro.c b/drivers/mtd/mtdblock_ro.c
index fb5dc89369de..92829e3fb3b7 100644
--- a/drivers/mtd/mtdblock_ro.c
+++ b/drivers/mtd/mtdblock_ro.c
@@ -31,7 +31,7 @@ static int mtdblock_readsect(struct mtd_blktrans_dev *dev,
 {
size_t retlen;
 
-   if (mtd_read(dev->mtd, (block * 512), 512, , buf))
+   if (mtd_read(dev->mtd, (loff_t)block << 9, 512, , buf))
return 1;
return 0;
 }
@@ -41,7 +41,7 @@ static int mtdblock_writesect(struct mtd_blktrans_dev *dev,
 {
size_t retlen;
 
-   if (mtd_write(dev->mtd, (block * 512), 512, , buf))
+   if (mtd_write(dev->mtd, 

Re: [PATCH] PCI,pciehp: Don't handle PDC for cards with attention button

[Yinghai Lu]

On Fri, Feb 17, 2017 at 2:39 PM, Bjorn Helgaas  wrote:
> On Thu, Feb 16, 2017 at 10:12:47PM -0800, Yinghai Lu wrote:
>
> I don't think it really makes sense to tie PDC handling with the
> attention button.  It might happen to avoid the problem on your
> system, but I don't see the logical connection between them.

but in pcie_enable_notification() we don't enable PDCE when ATTN is not there.

cmd = PCI_EXP_SLTCTL_DLLSCE;
if (ATTN_BUTTN(ctrl))
cmd |= PCI_EXP_SLTCTL_ABPE;
else
cmd |= PCI_EXP_SLTCTL_PDCE;
if (!pciehp_poll_mode)
cmd |= PCI_EXP_SLTCTL_HPIE | PCI_EXP_SLTCTL_CCIE;

mask = (PCI_EXP_SLTCTL_PDCE | PCI_EXP_SLTCTL_ABPE |
PCI_EXP_SLTCTL_PFDE |
PCI_EXP_SLTCTL_HPIE | PCI_EXP_SLTCTL_CCIE |
PCI_EXP_SLTCTL_DLLSCE);

pcie_write_cmd_nowait(ctrl, cmd, mask);

should we remove that check there ?

>
> Can you reproduce this by disabling pciehp and driving this sequence
> manually with setpci?  I suspect that we are tripping over our own
> feet because we read PCI_EXP_SLTSTA once, clear it (probably too
> early), then queue multiple events, then process those events possibly
> simultaneously.

sca15-2243-0a818158:~ # echo 1 > /sys/bus/pci/devices/\:3b\:00.0/remove
[  171.769322] pci :3b:00.0: PME# disabled
[  171.774459] iommu: Removing device :3b:00.0 from group 36
[  171.780984] pci :3b:00.0: freeing pci_dev info
sca15-2243-0a818158:~ # setpci -s :3a:00.0 0xa8.w
01cb
sca15-2243-0a818158:~ # setpci -s :3a:00.0 0xaa.w
0050
sca15-2243-0a818158:~ # setpci -s :3a:00.0 0xa8.w=0x05cb
sca15-2243-0a818158:~ # setpci -s :3a:00.0 0xaa.w
0158

so after power off, status bit 3 the PDC get set.

Re: [PATCH] PCI,pciehp: Don't handle PDC for cards with attention button

[Yinghai Lu]

On Fri, Feb 17, 2017 at 2:39 PM, Bjorn Helgaas  wrote:
> On Thu, Feb 16, 2017 at 10:12:47PM -0800, Yinghai Lu wrote:
>
> I don't think it really makes sense to tie PDC handling with the
> attention button.  It might happen to avoid the problem on your
> system, but I don't see the logical connection between them.

but in pcie_enable_notification() we don't enable PDCE when ATTN is not there.

cmd = PCI_EXP_SLTCTL_DLLSCE;
if (ATTN_BUTTN(ctrl))
cmd |= PCI_EXP_SLTCTL_ABPE;
else
cmd |= PCI_EXP_SLTCTL_PDCE;
if (!pciehp_poll_mode)
cmd |= PCI_EXP_SLTCTL_HPIE | PCI_EXP_SLTCTL_CCIE;

mask = (PCI_EXP_SLTCTL_PDCE | PCI_EXP_SLTCTL_ABPE |
PCI_EXP_SLTCTL_PFDE |
PCI_EXP_SLTCTL_HPIE | PCI_EXP_SLTCTL_CCIE |
PCI_EXP_SLTCTL_DLLSCE);

pcie_write_cmd_nowait(ctrl, cmd, mask);

should we remove that check there ?

>
> Can you reproduce this by disabling pciehp and driving this sequence
> manually with setpci?  I suspect that we are tripping over our own
> feet because we read PCI_EXP_SLTSTA once, clear it (probably too
> early), then queue multiple events, then process those events possibly
> simultaneously.

sca15-2243-0a818158:~ # echo 1 > /sys/bus/pci/devices/\:3b\:00.0/remove
[  171.769322] pci :3b:00.0: PME# disabled
[  171.774459] iommu: Removing device :3b:00.0 from group 36
[  171.780984] pci :3b:00.0: freeing pci_dev info
sca15-2243-0a818158:~ # setpci -s :3a:00.0 0xa8.w
01cb
sca15-2243-0a818158:~ # setpci -s :3a:00.0 0xaa.w
0050
sca15-2243-0a818158:~ # setpci -s :3a:00.0 0xa8.w=0x05cb
sca15-2243-0a818158:~ # setpci -s :3a:00.0 0xaa.w
0158

so after power off, status bit 3 the PDC get set.

[RFC/RFT PATCH 3/3] Input: ad7879 - allow exporting AUX/VBAT/GPIO pin via device property

[Dmitry Torokhov]

Up until now only platforms using legacy platform data were able to switch
AUX/VBAT/GPIO pin in GPIO mode and use it as regular GPIO line. Let's
allow platforms using generic device properties to do the same.

Signed-off-by: Dmitry Torokhov 
---
 .../devicetree/bindings/input/touchscreen/ad7879.txt  |  1 +
 drivers/input/touchscreen/ad7879.c| 15 +--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt 
b/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt
index e3f22d23fc8f..323b6098be19 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt
@@ -35,6 +35,7 @@ Optional properties:
 - adi,conversion-interval: : 0: convert one time only
  1-255: 515us + val * 35us (up to 9.440ms)
  This property has to be a '/bits/ 8' value
+- gpio-controller  : Switch AUX/VBAT/GPIO pin to GPIO mode
 
 Example:
 
diff --git a/drivers/input/touchscreen/ad7879.c 
b/drivers/input/touchscreen/ad7879.c
index b7ab7f9767ca..b6da5cee80eb 100644
--- a/drivers/input/touchscreen/ad7879.c
+++ b/drivers/input/touchscreen/ad7879.c
@@ -454,17 +454,28 @@ static void ad7879_gpio_set_value(struct gpio_chip *chip,
 static int ad7879_gpio_add(struct ad7879 *ts,
   const struct ad7879_platform_data *pdata)
 {
+   bool gpio_export;
+   int gpio_base;
int ret = 0;
 
+   if (pdata) {
+   gpio_export = pdata->gpio_export;
+   gpio_base = pdata->gpio_base;
+   } else {
+   gpio_export = device_property_read_bool(ts->dev,
+   "gpio-controller");
+   gpio_base = -1;
+   }
+
mutex_init(>mutex);
 
-   if (pdata && pdata->gpio_export) {
+   if (gpio_export) {
ts->gc.direction_input = ad7879_gpio_direction_input;
ts->gc.direction_output = ad7879_gpio_direction_output;
ts->gc.get = ad7879_gpio_get_value;
ts->gc.set = ad7879_gpio_set_value;
ts->gc.can_sleep = 1;
-   ts->gc.base = pdata->gpio_base;
+   ts->gc.base = gpio_base;
ts->gc.ngpio = 1;
ts->gc.label = "AD7879-GPIO";
ts->gc.owner = THIS_MODULE;
-- 
2.11.0.483.g087da7b7c-goog

[RFC/RFT PATCH 3/3] Input: ad7879 - allow exporting AUX/VBAT/GPIO pin via device property

[Dmitry Torokhov]

Up until now only platforms using legacy platform data were able to switch
AUX/VBAT/GPIO pin in GPIO mode and use it as regular GPIO line. Let's
allow platforms using generic device properties to do the same.

Signed-off-by: Dmitry Torokhov 
---
 .../devicetree/bindings/input/touchscreen/ad7879.txt  |  1 +
 drivers/input/touchscreen/ad7879.c| 15 +--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt 
b/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt
index e3f22d23fc8f..323b6098be19 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ad7879.txt
@@ -35,6 +35,7 @@ Optional properties:
 - adi,conversion-interval: : 0: convert one time only
  1-255: 515us + val * 35us (up to 9.440ms)
  This property has to be a '/bits/ 8' value
+- gpio-controller  : Switch AUX/VBAT/GPIO pin to GPIO mode
 
 Example:
 
diff --git a/drivers/input/touchscreen/ad7879.c 
b/drivers/input/touchscreen/ad7879.c
index b7ab7f9767ca..b6da5cee80eb 100644
--- a/drivers/input/touchscreen/ad7879.c
+++ b/drivers/input/touchscreen/ad7879.c
@@ -454,17 +454,28 @@ static void ad7879_gpio_set_value(struct gpio_chip *chip,
 static int ad7879_gpio_add(struct ad7879 *ts,
   const struct ad7879_platform_data *pdata)
 {
+   bool gpio_export;
+   int gpio_base;
int ret = 0;
 
+   if (pdata) {
+   gpio_export = pdata->gpio_export;
+   gpio_base = pdata->gpio_base;
+   } else {
+   gpio_export = device_property_read_bool(ts->dev,
+   "gpio-controller");
+   gpio_base = -1;
+   }
+
mutex_init(>mutex);
 
-   if (pdata && pdata->gpio_export) {
+   if (gpio_export) {
ts->gc.direction_input = ad7879_gpio_direction_input;
ts->gc.direction_output = ad7879_gpio_direction_output;
ts->gc.get = ad7879_gpio_get_value;
ts->gc.set = ad7879_gpio_set_value;
ts->gc.can_sleep = 1;
-   ts->gc.base = pdata->gpio_base;
+   ts->gc.base = gpio_base;
ts->gc.ngpio = 1;
ts->gc.label = "AD7879-GPIO";
ts->gc.owner = THIS_MODULE;
-- 
2.11.0.483.g087da7b7c-goog

[RFC/RFT PATCH 1/3] Input: ad7879 - convert to use regmap

[Dmitry Torokhov]

Instead of rolling our own infrastructure to provide uniform access to I2C
and SPI buses, let's switch to using regmap.

Signed-off-by: Dmitry Torokhov 
---

Michael,

I am a bit (actually a lot) confused how this driver was working with SPI
and Blackfin, which is, as far as I understand, little-endian, because from
my reading of the spec the data on wire is big-endian. If this is not
correct we need to change spi regmap config to be:

static const struct regmap_config ad7879_spi_regmap_config = {
.reg_bits = 16,
.val_bits = 16,
.max_register = 15,
.read_flag_mask = AD7879_CMD_MAGIC | AD7879_CMD_READ,
.write_flag_mask = AD7879_CMD_MAGIC,
.reg_format_endian_default = REGMAP_ENDIAN_LITTLE,
.val_format_endian_default = REGMAP_ENDIAN_LITTLE,
};

Also, the original ad7879_spi_xfer was funky to tell the least. We
allocated n+2 spi_transfer structures, then smashed the beginning of the
first one with u16 command, then basically "restored" it???

Anyway, if you could try it out (and fix ;) ), that would be great.

Thanks.

 drivers/input/touchscreen/ad7879-i2c.c |  50 ---
 drivers/input/touchscreen/ad7879-spi.c | 112 ++---
 drivers/input/touchscreen/ad7879.c |  46 +-
 drivers/input/touchscreen/ad7879.h |  12 +---
 4 files changed, 63 insertions(+), 157 deletions(-)

diff --git a/drivers/input/touchscreen/ad7879-i2c.c 
b/drivers/input/touchscreen/ad7879-i2c.c
index 58f72e0246ab..25aa9b89a6aa 100644
--- a/drivers/input/touchscreen/ad7879-i2c.c
+++ b/drivers/input/touchscreen/ad7879-i2c.c
@@ -12,53 +12,23 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ad7879.h"
 
 #define AD7879_DEVID   0x79/* AD7879-1/AD7889-1 */
 
-/* All registers are word-sized.
- * AD7879 uses a high-byte first convention.
- */
-static int ad7879_i2c_read(struct device *dev, u8 reg)
-{
-   struct i2c_client *client = to_i2c_client(dev);
-
-   return i2c_smbus_read_word_swapped(client, reg);
-}
-
-static int ad7879_i2c_multi_read(struct device *dev,
-u8 first_reg, u8 count, u16 *buf)
-{
-   struct i2c_client *client = to_i2c_client(dev);
-   u8 idx;
-
-   i2c_smbus_read_i2c_block_data(client, first_reg, count * 2, (u8 *)buf);
-
-   for (idx = 0; idx < count; ++idx)
-   buf[idx] = swab16(buf[idx]);
-
-   return 0;
-}
-
-static int ad7879_i2c_write(struct device *dev, u8 reg, u16 val)
-{
-   struct i2c_client *client = to_i2c_client(dev);
-
-   return i2c_smbus_write_word_swapped(client, reg, val);
-}
-
-static const struct ad7879_bus_ops ad7879_i2c_bus_ops = {
-   .bustype= BUS_I2C,
-   .read   = ad7879_i2c_read,
-   .multi_read = ad7879_i2c_multi_read,
-   .write  = ad7879_i2c_write,
+static const struct regmap_config ad7879_i2c_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 16,
+   .max_register = 15,
 };
 
 static int ad7879_i2c_probe(struct i2c_client *client,
  const struct i2c_device_id *id)
 {
struct ad7879 *ts;
+   struct regmap *regmap;
 
if (!i2c_check_functionality(client->adapter,
 I2C_FUNC_SMBUS_WORD_DATA)) {
@@ -66,8 +36,12 @@ static int ad7879_i2c_probe(struct i2c_client *client,
return -EIO;
}
 
-   ts = ad7879_probe(>dev, AD7879_DEVID, client->irq,
- _i2c_bus_ops);
+   regmap = devm_regmap_init_i2c(client, _i2c_regmap_config);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   ts = ad7879_probe(>dev, regmap, client->irq,
+ BUS_I2C, AD7879_DEVID);
if (IS_ERR(ts))
return PTR_ERR(ts);
 
diff --git a/drivers/input/touchscreen/ad7879-spi.c 
b/drivers/input/touchscreen/ad7879-spi.c
index d42b6b9af191..e9535aacaabf 100644
--- a/drivers/input/touchscreen/ad7879-spi.c
+++ b/drivers/input/touchscreen/ad7879-spi.c
@@ -11,109 +11,29 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ad7879.h"
 
 #define AD7879_DEVID   0x7A/* AD7879/AD7889 */
 
 #define MAX_SPI_FREQ_HZ  500
-#define AD7879_CMD_MAGIC 0xE000
-#define AD7879_CMD_READ  (1 << 10)
-#define AD7879_CMD(reg)  (AD7879_CMD_MAGIC | ((reg) & 0xF))
-#define AD7879_WRITECMD(reg) (AD7879_CMD(reg))
-#define AD7879_READCMD(reg)  (AD7879_CMD(reg) | AD7879_CMD_READ)
-
-/*
- * ad7879_read/write are only used for initial setup and for sysfs controls.
- * The main traffic is done in ad7879_collect().
- */
-
-static int ad7879_spi_xfer(struct spi_device *spi,
-  u16 cmd, u8 count, u16 *tx_buf, u16 *rx_buf)
-{
-   struct spi_message msg;
-   struct spi_transfer *xfers;
-   void *spi_data;
-   u16 *command;
-   u16 *_rx_buf = _rx_buf; /* shut gcc up */
-   u8 idx;
-   int ret;
-
-   

mmotm 2017-02-17-15-31 uploaded

[akpm]

The mm-of-the-moment snapshot 2017-02-17-15-31 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.10-rc8:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
* printk-use-rcuidle-console-tracepoint.patch
* scatterlist-dont-overflow-length-field.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* cris-use-generic-currenth.patch
* tracing-add-__print_flags_u64.patch
* dax-add-tracepoint-infrastructure-pmd-tracing.patch
* dax-update-maintainers-entries-for-fs-dax.patch
* dax-add-tracepoints-to-dax_pmd_load_hole.patch
* dax-add-tracepoints-to-dax_pmd_insert_mapping.patch
* mm-dax-make-pmd_fault-and-friends-to-be-the-same-as-fault.patch
* mm-dax-make-pmd_fault-and-friends-to-be-the-same-as-fault-v7.patch
* mm-dax-move-pmd_fault-to-take-only-vmf-parameter.patch
* dma-debug-add-comment-for-failed-to-check-map-error.patch
* tools-vm-add-missing-makefile-rules.patch
* scripts-spellingtxt-add-several-more-common-spelling-mistakes.patch
* scripts-spellingtxt-fix-incorrect-typo-words.patch
* scripts-spellingtxt-fix-incorrect-typo-words-fix.patch
* scripts-lindent-clean-up-and-optimize.patch
* scripts-checkstackpl-add-support-for-nios2.patch
* scripts-checkincludes-add-exit-message-for-no-duplicates-found.patch
* scripts-tagssh-include-arch-kconfig-for-tags-generation.patch
* m32r-use-generic-currenth.patch
* m32r-fix-build-warning.patch
* score-remove-asm-currenth.patch
* ocfs2-dlmglue-prepare-tracking-logic-to-avoid-recursive-cluster-lock.patch
* ocfs2-fix-deadlock-issue-when-taking-inode-lock-at-vfs-entry-points.patch
* 
ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called.patch
* 
ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called-fix.patch
* ocfs2-dlm-optimization-of-code-while-free-dead-node-locks.patch
* 
ocfs2-dlm-optimization-of-code-while-free-dead-node-locks-checkpatch-fixes.patch
* parisc-use-generic-currenth.patch
* block-use-for_each_thread-in-sys_ioprio_set-sys_ioprio_get.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
* 9p-fix-a-potential-acl-leak.patch
* kernel-watchdogc-do-not-hardcode-cpu-0-as-the-initial-thread.patch
  mm.patch
* slub-do-not-merge-cache-if-slub_debug-contains-a-never-merge-flag.patch
* mm-slub-add-a-dump_stack-to-the-unexpected-gfp-check.patch
* mm-slab-rename-kmalloc-node-cache-to-kmalloc-size.patch
* mm-slab-rename-kmalloc-node-cache-to-kmalloc-size-fix-fix.patch
* revert-slub-move-synchronize_sched-out-of-slab_mutex-on-shrink.patch
* slub-separate-out-sysfs_slab_release-from-sysfs_slab_remove.patch
* slab-remove-synchronous-rcu_barrier-call-in-memcg-cache-release-path.patch
* 

[RFC/RFT PATCH 1/3] Input: ad7879 - convert to use regmap

[Dmitry Torokhov]

Instead of rolling our own infrastructure to provide uniform access to I2C
and SPI buses, let's switch to using regmap.

Signed-off-by: Dmitry Torokhov 
---

Michael,

I am a bit (actually a lot) confused how this driver was working with SPI
and Blackfin, which is, as far as I understand, little-endian, because from
my reading of the spec the data on wire is big-endian. If this is not
correct we need to change spi regmap config to be:

static const struct regmap_config ad7879_spi_regmap_config = {
.reg_bits = 16,
.val_bits = 16,
.max_register = 15,
.read_flag_mask = AD7879_CMD_MAGIC | AD7879_CMD_READ,
.write_flag_mask = AD7879_CMD_MAGIC,
.reg_format_endian_default = REGMAP_ENDIAN_LITTLE,
.val_format_endian_default = REGMAP_ENDIAN_LITTLE,
};

Also, the original ad7879_spi_xfer was funky to tell the least. We
allocated n+2 spi_transfer structures, then smashed the beginning of the
first one with u16 command, then basically "restored" it???

Anyway, if you could try it out (and fix ;) ), that would be great.

Thanks.

 drivers/input/touchscreen/ad7879-i2c.c |  50 ---
 drivers/input/touchscreen/ad7879-spi.c | 112 ++---
 drivers/input/touchscreen/ad7879.c |  46 +-
 drivers/input/touchscreen/ad7879.h |  12 +---
 4 files changed, 63 insertions(+), 157 deletions(-)

diff --git a/drivers/input/touchscreen/ad7879-i2c.c 
b/drivers/input/touchscreen/ad7879-i2c.c
index 58f72e0246ab..25aa9b89a6aa 100644
--- a/drivers/input/touchscreen/ad7879-i2c.c
+++ b/drivers/input/touchscreen/ad7879-i2c.c
@@ -12,53 +12,23 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ad7879.h"
 
 #define AD7879_DEVID   0x79/* AD7879-1/AD7889-1 */
 
-/* All registers are word-sized.
- * AD7879 uses a high-byte first convention.
- */
-static int ad7879_i2c_read(struct device *dev, u8 reg)
-{
-   struct i2c_client *client = to_i2c_client(dev);
-
-   return i2c_smbus_read_word_swapped(client, reg);
-}
-
-static int ad7879_i2c_multi_read(struct device *dev,
-u8 first_reg, u8 count, u16 *buf)
-{
-   struct i2c_client *client = to_i2c_client(dev);
-   u8 idx;
-
-   i2c_smbus_read_i2c_block_data(client, first_reg, count * 2, (u8 *)buf);
-
-   for (idx = 0; idx < count; ++idx)
-   buf[idx] = swab16(buf[idx]);
-
-   return 0;
-}
-
-static int ad7879_i2c_write(struct device *dev, u8 reg, u16 val)
-{
-   struct i2c_client *client = to_i2c_client(dev);
-
-   return i2c_smbus_write_word_swapped(client, reg, val);
-}
-
-static const struct ad7879_bus_ops ad7879_i2c_bus_ops = {
-   .bustype= BUS_I2C,
-   .read   = ad7879_i2c_read,
-   .multi_read = ad7879_i2c_multi_read,
-   .write  = ad7879_i2c_write,
+static const struct regmap_config ad7879_i2c_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 16,
+   .max_register = 15,
 };
 
 static int ad7879_i2c_probe(struct i2c_client *client,
  const struct i2c_device_id *id)
 {
struct ad7879 *ts;
+   struct regmap *regmap;
 
if (!i2c_check_functionality(client->adapter,
 I2C_FUNC_SMBUS_WORD_DATA)) {
@@ -66,8 +36,12 @@ static int ad7879_i2c_probe(struct i2c_client *client,
return -EIO;
}
 
-   ts = ad7879_probe(>dev, AD7879_DEVID, client->irq,
- _i2c_bus_ops);
+   regmap = devm_regmap_init_i2c(client, _i2c_regmap_config);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   ts = ad7879_probe(>dev, regmap, client->irq,
+ BUS_I2C, AD7879_DEVID);
if (IS_ERR(ts))
return PTR_ERR(ts);
 
diff --git a/drivers/input/touchscreen/ad7879-spi.c 
b/drivers/input/touchscreen/ad7879-spi.c
index d42b6b9af191..e9535aacaabf 100644
--- a/drivers/input/touchscreen/ad7879-spi.c
+++ b/drivers/input/touchscreen/ad7879-spi.c
@@ -11,109 +11,29 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ad7879.h"
 
 #define AD7879_DEVID   0x7A/* AD7879/AD7889 */
 
 #define MAX_SPI_FREQ_HZ  500
-#define AD7879_CMD_MAGIC 0xE000
-#define AD7879_CMD_READ  (1 << 10)
-#define AD7879_CMD(reg)  (AD7879_CMD_MAGIC | ((reg) & 0xF))
-#define AD7879_WRITECMD(reg) (AD7879_CMD(reg))
-#define AD7879_READCMD(reg)  (AD7879_CMD(reg) | AD7879_CMD_READ)
-
-/*
- * ad7879_read/write are only used for initial setup and for sysfs controls.
- * The main traffic is done in ad7879_collect().
- */
-
-static int ad7879_spi_xfer(struct spi_device *spi,
-  u16 cmd, u8 count, u16 *tx_buf, u16 *rx_buf)
-{
-   struct spi_message msg;
-   struct spi_transfer *xfers;
-   void *spi_data;
-   u16 *command;
-   u16 *_rx_buf = _rx_buf; /* shut gcc up */
-   u8 idx;
-   int ret;
-
-   xfers = spi_data = 

mmotm 2017-02-17-15-31 uploaded

[akpm]

The mm-of-the-moment snapshot 2017-02-17-15-31 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.10-rc8:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
* printk-use-rcuidle-console-tracepoint.patch
* scatterlist-dont-overflow-length-field.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* cris-use-generic-currenth.patch
* tracing-add-__print_flags_u64.patch
* dax-add-tracepoint-infrastructure-pmd-tracing.patch
* dax-update-maintainers-entries-for-fs-dax.patch
* dax-add-tracepoints-to-dax_pmd_load_hole.patch
* dax-add-tracepoints-to-dax_pmd_insert_mapping.patch
* mm-dax-make-pmd_fault-and-friends-to-be-the-same-as-fault.patch
* mm-dax-make-pmd_fault-and-friends-to-be-the-same-as-fault-v7.patch
* mm-dax-move-pmd_fault-to-take-only-vmf-parameter.patch
* dma-debug-add-comment-for-failed-to-check-map-error.patch
* tools-vm-add-missing-makefile-rules.patch
* scripts-spellingtxt-add-several-more-common-spelling-mistakes.patch
* scripts-spellingtxt-fix-incorrect-typo-words.patch
* scripts-spellingtxt-fix-incorrect-typo-words-fix.patch
* scripts-lindent-clean-up-and-optimize.patch
* scripts-checkstackpl-add-support-for-nios2.patch
* scripts-checkincludes-add-exit-message-for-no-duplicates-found.patch
* scripts-tagssh-include-arch-kconfig-for-tags-generation.patch
* m32r-use-generic-currenth.patch
* m32r-fix-build-warning.patch
* score-remove-asm-currenth.patch
* ocfs2-dlmglue-prepare-tracking-logic-to-avoid-recursive-cluster-lock.patch
* ocfs2-fix-deadlock-issue-when-taking-inode-lock-at-vfs-entry-points.patch
* 
ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called.patch
* 
ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called-fix.patch
* ocfs2-dlm-optimization-of-code-while-free-dead-node-locks.patch
* 
ocfs2-dlm-optimization-of-code-while-free-dead-node-locks-checkpatch-fixes.patch
* parisc-use-generic-currenth.patch
* block-use-for_each_thread-in-sys_ioprio_set-sys_ioprio_get.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
* 9p-fix-a-potential-acl-leak.patch
* kernel-watchdogc-do-not-hardcode-cpu-0-as-the-initial-thread.patch
  mm.patch
* slub-do-not-merge-cache-if-slub_debug-contains-a-never-merge-flag.patch
* mm-slub-add-a-dump_stack-to-the-unexpected-gfp-check.patch
* mm-slab-rename-kmalloc-node-cache-to-kmalloc-size.patch
* mm-slab-rename-kmalloc-node-cache-to-kmalloc-size-fix-fix.patch
* revert-slub-move-synchronize_sched-out-of-slab_mutex-on-shrink.patch
* slub-separate-out-sysfs_slab_release-from-sysfs_slab_remove.patch
* slab-remove-synchronous-rcu_barrier-call-in-memcg-cache-release-path.patch
* 

[RFC/RFT PATCH 2/3] Input: ad7879 - use more devm interfaces

[Dmitry Torokhov]

gpiochip_add now has a managed version, and we can remove sysfs attribute
group via devm_add_action_or_reset (at least until we have devm version of
sysfs_crreate_group). This allows us to get rid of ad7879_remove().

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/ad7879-i2c.c | 12 ---
 drivers/input/touchscreen/ad7879-spi.c | 10 --
 drivers/input/touchscreen/ad7879.c | 60 --
 drivers/input/touchscreen/ad7879.h |  1 -
 4 files changed, 21 insertions(+), 62 deletions(-)

diff --git a/drivers/input/touchscreen/ad7879-i2c.c 
b/drivers/input/touchscreen/ad7879-i2c.c
index 25aa9b89a6aa..23e04e9f2dad 100644
--- a/drivers/input/touchscreen/ad7879-i2c.c
+++ b/drivers/input/touchscreen/ad7879-i2c.c
@@ -45,17 +45,6 @@ static int ad7879_i2c_probe(struct i2c_client *client,
if (IS_ERR(ts))
return PTR_ERR(ts);
 
-   i2c_set_clientdata(client, ts);
-
-   return 0;
-}
-
-static int ad7879_i2c_remove(struct i2c_client *client)
-{
-   struct ad7879 *ts = i2c_get_clientdata(client);
-
-   ad7879_remove(ts);
-
return 0;
 }
 
@@ -81,7 +70,6 @@ static struct i2c_driver ad7879_i2c_driver = {
.of_match_table = of_match_ptr(ad7879_i2c_dt_ids),
},
.probe  = ad7879_i2c_probe,
-   .remove = ad7879_i2c_remove,
.id_table   = ad7879_id,
 };
 
diff --git a/drivers/input/touchscreen/ad7879-spi.c 
b/drivers/input/touchscreen/ad7879-spi.c
index e9535aacaabf..f2c06b5a75d0 100644
--- a/drivers/input/touchscreen/ad7879-spi.c
+++ b/drivers/input/touchscreen/ad7879-spi.c
@@ -62,15 +62,6 @@ static int ad7879_spi_probe(struct spi_device *spi)
return 0;
 }
 
-static int ad7879_spi_remove(struct spi_device *spi)
-{
-   struct ad7879 *ts = spi_get_drvdata(spi);
-
-   ad7879_remove(ts);
-
-   return 0;
-}
-
 #ifdef CONFIG_OF
 static const struct of_device_id ad7879_spi_dt_ids[] = {
{ .compatible = "adi,ad7879", },
@@ -86,7 +77,6 @@ static struct spi_driver ad7879_spi_driver = {
.of_match_table = of_match_ptr(ad7879_spi_dt_ids),
},
.probe  = ad7879_spi_probe,
-   .remove = ad7879_spi_remove,
 };
 
 module_spi_driver(ad7879_spi_driver);
diff --git a/drivers/input/touchscreen/ad7879.c 
b/drivers/input/touchscreen/ad7879.c
index 6465db7a1b20..b7ab7f9767ca 100644
--- a/drivers/input/touchscreen/ad7879.c
+++ b/drivers/input/touchscreen/ad7879.c
@@ -458,7 +458,7 @@ static int ad7879_gpio_add(struct ad7879 *ts,
 
mutex_init(>mutex);
 
-   if (pdata->gpio_export) {
+   if (pdata && pdata->gpio_export) {
ts->gc.direction_input = ad7879_gpio_direction_input;
ts->gc.direction_output = ad7879_gpio_direction_output;
ts->gc.get = ad7879_gpio_get_value;
@@ -470,7 +470,7 @@ static int ad7879_gpio_add(struct ad7879 *ts,
ts->gc.owner = THIS_MODULE;
ts->gc.parent = ts->dev;
 
-   ret = gpiochip_add_data(>gc, ts);
+   ret = devm_gpiochip_add_data(ts->dev, >gc, ts);
if (ret)
dev_err(ts->dev, "failed to register gpio %d\n",
ts->gc.base);
@@ -478,25 +478,12 @@ static int ad7879_gpio_add(struct ad7879 *ts,
 
return ret;
 }
-
-static void ad7879_gpio_remove(struct ad7879 *ts)
-{
-   const struct ad7879_platform_data *pdata = dev_get_platdata(ts->dev);
-
-   if (pdata && pdata->gpio_export)
-   gpiochip_remove(>gc);
-
-}
 #else
-static inline int ad7879_gpio_add(struct ad7879 *ts,
- const struct ad7879_platform_data *pdata)
+static int ad7879_gpio_add(struct ad7879 *ts,
+  const struct ad7879_platform_data *pdata)
 {
return 0;
 }
-
-static inline void ad7879_gpio_remove(struct ad7879 *ts)
-{
-}
 #endif
 
 static int ad7879_parse_dt(struct device *dev, struct ad7879 *ts)
@@ -525,6 +512,13 @@ static int ad7879_parse_dt(struct device *dev, struct 
ad7879 *ts)
return 0;
 }
 
+static void ad7879_cleanup_sysfs(void *_ts)
+{
+   struct ad7879 *ts = _ts;
+
+   sysfs_remove_group(>dev->kobj, _attr_group);
+}
+
 struct ad7879 *ad7879_probe(struct device *dev, struct regmap *regmap,
int irq, u16 bustype, u8 devid)
 {
@@ -660,36 +654,24 @@ struct ad7879 *ad7879_probe(struct device *dev, struct 
regmap *regmap,
 
err = sysfs_create_group(>kobj, _attr_group);
if (err)
-   goto err_out;
+   return ERR_PTR(err);
 
-   if (pdata) {
-   err = ad7879_gpio_add(ts, pdata);
-   if (err)
-   goto err_remove_attr;
-   }
+   err = devm_add_action_or_reset(dev, ad7879_cleanup_sysfs, ts);
+   if (err)
+   return ERR_PTR(err);
 
-   err = input_register_device(input_dev);
+   err = 

[RFC/RFT PATCH 2/3] Input: ad7879 - use more devm interfaces

[Dmitry Torokhov]

gpiochip_add now has a managed version, and we can remove sysfs attribute
group via devm_add_action_or_reset (at least until we have devm version of
sysfs_crreate_group). This allows us to get rid of ad7879_remove().

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/ad7879-i2c.c | 12 ---
 drivers/input/touchscreen/ad7879-spi.c | 10 --
 drivers/input/touchscreen/ad7879.c | 60 --
 drivers/input/touchscreen/ad7879.h |  1 -
 4 files changed, 21 insertions(+), 62 deletions(-)

diff --git a/drivers/input/touchscreen/ad7879-i2c.c 
b/drivers/input/touchscreen/ad7879-i2c.c
index 25aa9b89a6aa..23e04e9f2dad 100644
--- a/drivers/input/touchscreen/ad7879-i2c.c
+++ b/drivers/input/touchscreen/ad7879-i2c.c
@@ -45,17 +45,6 @@ static int ad7879_i2c_probe(struct i2c_client *client,
if (IS_ERR(ts))
return PTR_ERR(ts);
 
-   i2c_set_clientdata(client, ts);
-
-   return 0;
-}
-
-static int ad7879_i2c_remove(struct i2c_client *client)
-{
-   struct ad7879 *ts = i2c_get_clientdata(client);
-
-   ad7879_remove(ts);
-
return 0;
 }
 
@@ -81,7 +70,6 @@ static struct i2c_driver ad7879_i2c_driver = {
.of_match_table = of_match_ptr(ad7879_i2c_dt_ids),
},
.probe  = ad7879_i2c_probe,
-   .remove = ad7879_i2c_remove,
.id_table   = ad7879_id,
 };
 
diff --git a/drivers/input/touchscreen/ad7879-spi.c 
b/drivers/input/touchscreen/ad7879-spi.c
index e9535aacaabf..f2c06b5a75d0 100644
--- a/drivers/input/touchscreen/ad7879-spi.c
+++ b/drivers/input/touchscreen/ad7879-spi.c
@@ -62,15 +62,6 @@ static int ad7879_spi_probe(struct spi_device *spi)
return 0;
 }
 
-static int ad7879_spi_remove(struct spi_device *spi)
-{
-   struct ad7879 *ts = spi_get_drvdata(spi);
-
-   ad7879_remove(ts);
-
-   return 0;
-}
-
 #ifdef CONFIG_OF
 static const struct of_device_id ad7879_spi_dt_ids[] = {
{ .compatible = "adi,ad7879", },
@@ -86,7 +77,6 @@ static struct spi_driver ad7879_spi_driver = {
.of_match_table = of_match_ptr(ad7879_spi_dt_ids),
},
.probe  = ad7879_spi_probe,
-   .remove = ad7879_spi_remove,
 };
 
 module_spi_driver(ad7879_spi_driver);
diff --git a/drivers/input/touchscreen/ad7879.c 
b/drivers/input/touchscreen/ad7879.c
index 6465db7a1b20..b7ab7f9767ca 100644
--- a/drivers/input/touchscreen/ad7879.c
+++ b/drivers/input/touchscreen/ad7879.c
@@ -458,7 +458,7 @@ static int ad7879_gpio_add(struct ad7879 *ts,
 
mutex_init(>mutex);
 
-   if (pdata->gpio_export) {
+   if (pdata && pdata->gpio_export) {
ts->gc.direction_input = ad7879_gpio_direction_input;
ts->gc.direction_output = ad7879_gpio_direction_output;
ts->gc.get = ad7879_gpio_get_value;
@@ -470,7 +470,7 @@ static int ad7879_gpio_add(struct ad7879 *ts,
ts->gc.owner = THIS_MODULE;
ts->gc.parent = ts->dev;
 
-   ret = gpiochip_add_data(>gc, ts);
+   ret = devm_gpiochip_add_data(ts->dev, >gc, ts);
if (ret)
dev_err(ts->dev, "failed to register gpio %d\n",
ts->gc.base);
@@ -478,25 +478,12 @@ static int ad7879_gpio_add(struct ad7879 *ts,
 
return ret;
 }
-
-static void ad7879_gpio_remove(struct ad7879 *ts)
-{
-   const struct ad7879_platform_data *pdata = dev_get_platdata(ts->dev);
-
-   if (pdata && pdata->gpio_export)
-   gpiochip_remove(>gc);
-
-}
 #else
-static inline int ad7879_gpio_add(struct ad7879 *ts,
- const struct ad7879_platform_data *pdata)
+static int ad7879_gpio_add(struct ad7879 *ts,
+  const struct ad7879_platform_data *pdata)
 {
return 0;
 }
-
-static inline void ad7879_gpio_remove(struct ad7879 *ts)
-{
-}
 #endif
 
 static int ad7879_parse_dt(struct device *dev, struct ad7879 *ts)
@@ -525,6 +512,13 @@ static int ad7879_parse_dt(struct device *dev, struct 
ad7879 *ts)
return 0;
 }
 
+static void ad7879_cleanup_sysfs(void *_ts)
+{
+   struct ad7879 *ts = _ts;
+
+   sysfs_remove_group(>dev->kobj, _attr_group);
+}
+
 struct ad7879 *ad7879_probe(struct device *dev, struct regmap *regmap,
int irq, u16 bustype, u8 devid)
 {
@@ -660,36 +654,24 @@ struct ad7879 *ad7879_probe(struct device *dev, struct 
regmap *regmap,
 
err = sysfs_create_group(>kobj, _attr_group);
if (err)
-   goto err_out;
+   return ERR_PTR(err);
 
-   if (pdata) {
-   err = ad7879_gpio_add(ts, pdata);
-   if (err)
-   goto err_remove_attr;
-   }
+   err = devm_add_action_or_reset(dev, ad7879_cleanup_sysfs, ts);
+   if (err)
+   return ERR_PTR(err);
 
-   err = input_register_device(input_dev);
+   err = ad7879_gpio_add(ts, pdata);

Re: [PATCH net-next] virito-net: set queues after reset during xdp_set

[John Fastabend]

On 17-02-16 09:10 PM, Jason Wang wrote:
> 
> 
> On 2017年02月17日 12:53, John Fastabend wrote:
>> On 17-02-15 01:08 AM, Jason Wang wrote:
>>> We set queues before reset which will cause a crash[1]. This is
>>> because is_xdp_raw_buffer_queue() depends on the old xdp queue pairs
>>> number to do the correct detection. So fix this by:
>>>
>>> - set queues after reset, to keep the old vi->curr_queue_pairs. (in
>>>fact setting queues before reset does not works since after feature
>>>set, all queue pairs were enabled by default during reset).
>>> - change xdp_queue_pairs only after virtnet_reset() is succeed.
>>>
>>> [1]
>> I'm guessing this occurs when enabling XDP while receiving lots of traffic?
> 
> I hit this then disabling XDP while receiving lots of traffic.
> 

[...]

>>> +vi->xdp_queue_pairs = xdp_qp;
>> But xdp_queue_pairs is being used to detect if we should allocate the XDP
>> headroom. If we move it here do we have a set of buffers in the ring without
>> the proper headroom when we assign the xdp program below?
> 
> Right, so how about passing xdp_queue_pairs as a parameter to virtnet_reset().
> Then virtnet_reset() can set it after _remove_vq_common() but before
> virtnet_restore_up()?
> 
> Thanks
> 

Sounds like a reasonable fix to me.

>>
>>> +}
>>> +
>>> +err = _virtnet_set_queues(vi, curr_qp + xdp_qp);
>>> +if (err) {
>>> +dev_warn(>dev, "XDP Device queue allocation failure.\n");
>>> +goto virtio_queue_err;
>>>   }
>>> netif_set_real_num_rx_queues(dev, curr_qp + xdp_qp);
>>> @@ -1844,17 +1844,18 @@ static int virtnet_xdp_set(struct net_device *dev,
>>> struct bpf_prog *prog)
>>> return 0;
>> Thanks,
>> John
>>
> 

Re: [PATCH net-next] virito-net: set queues after reset during xdp_set

[John Fastabend]

On 17-02-16 09:10 PM, Jason Wang wrote:
> 
> 
> On 2017年02月17日 12:53, John Fastabend wrote:
>> On 17-02-15 01:08 AM, Jason Wang wrote:
>>> We set queues before reset which will cause a crash[1]. This is
>>> because is_xdp_raw_buffer_queue() depends on the old xdp queue pairs
>>> number to do the correct detection. So fix this by:
>>>
>>> - set queues after reset, to keep the old vi->curr_queue_pairs. (in
>>>fact setting queues before reset does not works since after feature
>>>set, all queue pairs were enabled by default during reset).
>>> - change xdp_queue_pairs only after virtnet_reset() is succeed.
>>>
>>> [1]
>> I'm guessing this occurs when enabling XDP while receiving lots of traffic?
> 
> I hit this then disabling XDP while receiving lots of traffic.
> 

[...]

>>> +vi->xdp_queue_pairs = xdp_qp;
>> But xdp_queue_pairs is being used to detect if we should allocate the XDP
>> headroom. If we move it here do we have a set of buffers in the ring without
>> the proper headroom when we assign the xdp program below?
> 
> Right, so how about passing xdp_queue_pairs as a parameter to virtnet_reset().
> Then virtnet_reset() can set it after _remove_vq_common() but before
> virtnet_restore_up()?
> 
> Thanks
> 

Sounds like a reasonable fix to me.

>>
>>> +}
>>> +
>>> +err = _virtnet_set_queues(vi, curr_qp + xdp_qp);
>>> +if (err) {
>>> +dev_warn(>dev, "XDP Device queue allocation failure.\n");
>>> +goto virtio_queue_err;
>>>   }
>>> netif_set_real_num_rx_queues(dev, curr_qp + xdp_qp);
>>> @@ -1844,17 +1844,18 @@ static int virtnet_xdp_set(struct net_device *dev,
>>> struct bpf_prog *prog)
>>> return 0;
>> Thanks,
>> John
>>
> 

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Cong Wang]

On Fri, Feb 17, 2017 at 3:16 PM, Gabriel C  wrote:
>
>
> On 17.02.2017 23:38, Cong Wang wrote:
>>
>> On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C  wrote:
>>>
>>> Hi all,
>>>
>>> while poking at a different issue I found the following on my logs :
>>>
>>> [85362.132770] BUG: sleeping function called from invalid context at
>>> kernel/irq/manage.c:110
>>> [85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153, name:
>>> systemd-journal
>>> [85362.132772] no locks held by systemd-journal/1153.
>>> [85362.132772] irq event stamp: 60088359
>>> [85362.132777] hardirqs last  enabled at (60088359): []
>>> vprintk_emit+0x432/0x470
>>> [85362.132779] hardirqs last disabled at (60088358): []
>>> vprintk_emit+0x5c/0x470
>>> [85362.132782] softirqs last  enabled at (60088258): []
>>> __do_softirq+0x22d/0x290
>>> [85362.132784] softirqs last disabled at (60088233): []
>>> irq_exit+0x6a/0xd0
>>> [85362.132784] Preemption disabled at:
>>> [85362.132787] [] write_msg+0x4e/0xf0
>>> [85362.132790] CPU: 0 PID: 1153 Comm: systemd-journal Tainted: G
>>> I
>>> 4.10.0-rc8-debug-1-ga1015e374d94-dirty #5
>>> [85362.132791] Hardware name: FUJITSU  PRIMERGY
>>> TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709
>>> 02/04/2013
>>> [85362.132792] Call Trace:
>>> [85362.132796]  dump_stack+0x86/0xc1
>>> [85362.132799]  ___might_sleep+0x213/0x230
>>> [85362.132801]  __might_sleep+0x6b/0x80
>>> [85362.132803]  synchronize_irq+0x33/0x90
>>> [85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
>>> [85362.132807]  ? __disable_irq_nosync+0x4e/0x60
>>> [85362.132808]  disable_irq+0x17/0x20
>>
>>
>>
>> Hmm, your kernel base version is 4.10.0-rc8 but the symbols here
>> look like prior to my commit, because with my commit here should
>> be disable_hardirq() calling synchronize_hardirq().
>>
>> Did you revert it or make any local changes?
>
>
> The kernel is -rc8 with reverted d966564fcdc19e13eb6ba1fbe6b8101070339c3d
> +
> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=202461e2f3c15dbfb05825d29ace0d20cdf55fa4
> + an debug patch from Thomas to find these goldfish issues.
> (
> http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/goldfish-debug.patch
> )
>
> No other changes..

That is weird, the stack trace doesn't match the source code for some reason.
Can you objdump your e1000.ko module to see if that is true?

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Cong Wang]

On Fri, Feb 17, 2017 at 3:16 PM, Gabriel C  wrote:
>
>
> On 17.02.2017 23:38, Cong Wang wrote:
>>
>> On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C  wrote:
>>>
>>> Hi all,
>>>
>>> while poking at a different issue I found the following on my logs :
>>>
>>> [85362.132770] BUG: sleeping function called from invalid context at
>>> kernel/irq/manage.c:110
>>> [85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153, name:
>>> systemd-journal
>>> [85362.132772] no locks held by systemd-journal/1153.
>>> [85362.132772] irq event stamp: 60088359
>>> [85362.132777] hardirqs last  enabled at (60088359): []
>>> vprintk_emit+0x432/0x470
>>> [85362.132779] hardirqs last disabled at (60088358): []
>>> vprintk_emit+0x5c/0x470
>>> [85362.132782] softirqs last  enabled at (60088258): []
>>> __do_softirq+0x22d/0x290
>>> [85362.132784] softirqs last disabled at (60088233): []
>>> irq_exit+0x6a/0xd0
>>> [85362.132784] Preemption disabled at:
>>> [85362.132787] [] write_msg+0x4e/0xf0
>>> [85362.132790] CPU: 0 PID: 1153 Comm: systemd-journal Tainted: G
>>> I
>>> 4.10.0-rc8-debug-1-ga1015e374d94-dirty #5
>>> [85362.132791] Hardware name: FUJITSU  PRIMERGY
>>> TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709
>>> 02/04/2013
>>> [85362.132792] Call Trace:
>>> [85362.132796]  dump_stack+0x86/0xc1
>>> [85362.132799]  ___might_sleep+0x213/0x230
>>> [85362.132801]  __might_sleep+0x6b/0x80
>>> [85362.132803]  synchronize_irq+0x33/0x90
>>> [85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
>>> [85362.132807]  ? __disable_irq_nosync+0x4e/0x60
>>> [85362.132808]  disable_irq+0x17/0x20
>>
>>
>>
>> Hmm, your kernel base version is 4.10.0-rc8 but the symbols here
>> look like prior to my commit, because with my commit here should
>> be disable_hardirq() calling synchronize_hardirq().
>>
>> Did you revert it or make any local changes?
>
>
> The kernel is -rc8 with reverted d966564fcdc19e13eb6ba1fbe6b8101070339c3d
> +
> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=202461e2f3c15dbfb05825d29ace0d20cdf55fa4
> + an debug patch from Thomas to find these goldfish issues.
> (
> http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/goldfish-debug.patch
> )
>
> No other changes..

That is weird, the stack trace doesn't match the source code for some reason.
Can you objdump your e1000.ko module to see if that is true?

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Gabriel C]

On 18.02.2017 00:16, Gabriel C wrote:



On 17.02.2017 23:38, Cong Wang wrote:

On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C  wrote:

Hi all,

while poking at a different issue I found the following on my logs :

[85362.132770] BUG: sleeping function called from invalid context at
kernel/irq/manage.c:110
[85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153, name:
systemd-journal
[85362.132772] no locks held by systemd-journal/1153.
[85362.132772] irq event stamp: 60088359
[85362.132777] hardirqs last  enabled at (60088359): []
vprintk_emit+0x432/0x470
[85362.132779] hardirqs last disabled at (60088358): []
vprintk_emit+0x5c/0x470
[85362.132782] softirqs last  enabled at (60088258): []
__do_softirq+0x22d/0x290
[85362.132784] softirqs last disabled at (60088233): []
irq_exit+0x6a/0xd0
[85362.132784] Preemption disabled at:
[85362.132787] [] write_msg+0x4e/0xf0
[85362.132790] CPU: 0 PID: 1153 Comm: systemd-journal Tainted: G  I
4.10.0-rc8-debug-1-ga1015e374d94-dirty #5
[85362.132791] Hardware name: FUJITSU  PRIMERGY
TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709
02/04/2013
[85362.132792] Call Trace:
[85362.132796]  dump_stack+0x86/0xc1
[85362.132799]  ___might_sleep+0x213/0x230
[85362.132801]  __might_sleep+0x6b/0x80
[85362.132803]  synchronize_irq+0x33/0x90
[85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
[85362.132807]  ? __disable_irq_nosync+0x4e/0x60
[85362.132808]  disable_irq+0x17/0x20



Hmm, your kernel base version is 4.10.0-rc8 but the symbols here
look like prior to my commit, because with my commit here should
be disable_hardirq() calling synchronize_hardirq().

Did you revert it or make any local changes?


The kernel is -rc8 with reverted d966564fcdc19e13eb6ba1fbe6b8101070339c3d
+ 
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=202461e2f3c15dbfb05825d29ace0d20cdf55fa4
+ an debug patch from Thomas to find these goldfish issues.
( 
http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/goldfish-debug.patch )

No other changes..



Forgot to tell ,  netconsole is running on that box ..







[85362.132810]  e1000_netpoll+0x3d/0x110
[85362.132813]  netpoll_poll_dev+0xa0/0x170
[85362.132814]  netpoll_send_skb_on_dev+0x1ab/0x2b0
[85362.132816]  netpoll_send_udp+0x417/0x450
[85362.132817]  write_msg+0xdb/0xf0
[85362.132819]  console_unlock+0x2e5/0x430
[85362.132821]  ? __down_trylock_console_sem+0x41/0x60
[85362.132822]  vprintk_emit+0x456/0x470
[85362.132825]  printk_emit+0x2e/0x36
[85362.132827]  ? simple_strtoull+0x2c/0x50
[85362.132829]  devkmsg_write+0x115/0x160
[85362.132831]  do_iter_readv_writev+0xd8/0x100
[85362.132833]  do_readv_writev+0xdf/0x220
[85362.132835]  ? __might_fault+0x37/0x90
[85362.132838]  ? entry_SYSCALL_64_fastpath+0x5/0xc2
[85362.132839]  vfs_writev+0x3a/0x50
[85362.132841]  do_writev+0x4c/0xd0
[85362.132842]  SyS_writev+0xb/0x10
[85362.132843]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[85362.132845] RIP: 0033:0x7fc6d305c46d
[85362.132846] RSP: 002b:7ffca94161e0 EFLAGS: 0293 ORIG_RAX:
0014
[85362.132847] RAX: ffda RBX: 813afad3 RCX:
7fc6d305c46d
[85362.132848] RDX: 0005 RSI: 7ffca94162f0 RDI:
0006
[85362.132849] RBP: c9000d4c3f88 R08:  R09:
0008
[85362.132850] R10: 0069 R11: 0293 R12:
7ffca94162f0
[85362.132851] R13: 55768b19c920 R14: 7ffca9416330 R15:
7ffca94163c0
[85362.132853]  ? __this_cpu_preempt_check+0x13/0x20


Seems to be introduced by :

commit 311191297125156319be8f86d546ea1c569f7e95
Author: WANG Cong 
Date:   Sat Dec 10 14:22:42 2016 -0800

e1000: use disable_hardirq() for e1000_netpoll()

...

The used config can be found there:

http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/config-rcx


Regards,

Gabriel C

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Gabriel C]

On 18.02.2017 00:16, Gabriel C wrote:



On 17.02.2017 23:38, Cong Wang wrote:

On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C  wrote:

Hi all,

while poking at a different issue I found the following on my logs :

[85362.132770] BUG: sleeping function called from invalid context at
kernel/irq/manage.c:110
[85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153, name:
systemd-journal
[85362.132772] no locks held by systemd-journal/1153.
[85362.132772] irq event stamp: 60088359
[85362.132777] hardirqs last  enabled at (60088359): []
vprintk_emit+0x432/0x470
[85362.132779] hardirqs last disabled at (60088358): []
vprintk_emit+0x5c/0x470
[85362.132782] softirqs last  enabled at (60088258): []
__do_softirq+0x22d/0x290
[85362.132784] softirqs last disabled at (60088233): []
irq_exit+0x6a/0xd0
[85362.132784] Preemption disabled at:
[85362.132787] [] write_msg+0x4e/0xf0
[85362.132790] CPU: 0 PID: 1153 Comm: systemd-journal Tainted: G  I
4.10.0-rc8-debug-1-ga1015e374d94-dirty #5
[85362.132791] Hardware name: FUJITSU  PRIMERGY
TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709
02/04/2013
[85362.132792] Call Trace:
[85362.132796]  dump_stack+0x86/0xc1
[85362.132799]  ___might_sleep+0x213/0x230
[85362.132801]  __might_sleep+0x6b/0x80
[85362.132803]  synchronize_irq+0x33/0x90
[85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
[85362.132807]  ? __disable_irq_nosync+0x4e/0x60
[85362.132808]  disable_irq+0x17/0x20



Hmm, your kernel base version is 4.10.0-rc8 but the symbols here
look like prior to my commit, because with my commit here should
be disable_hardirq() calling synchronize_hardirq().

Did you revert it or make any local changes?


The kernel is -rc8 with reverted d966564fcdc19e13eb6ba1fbe6b8101070339c3d
+ 
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=202461e2f3c15dbfb05825d29ace0d20cdf55fa4
+ an debug patch from Thomas to find these goldfish issues.
( 
http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/goldfish-debug.patch )

No other changes..



Forgot to tell ,  netconsole is running on that box ..







[85362.132810]  e1000_netpoll+0x3d/0x110
[85362.132813]  netpoll_poll_dev+0xa0/0x170
[85362.132814]  netpoll_send_skb_on_dev+0x1ab/0x2b0
[85362.132816]  netpoll_send_udp+0x417/0x450
[85362.132817]  write_msg+0xdb/0xf0
[85362.132819]  console_unlock+0x2e5/0x430
[85362.132821]  ? __down_trylock_console_sem+0x41/0x60
[85362.132822]  vprintk_emit+0x456/0x470
[85362.132825]  printk_emit+0x2e/0x36
[85362.132827]  ? simple_strtoull+0x2c/0x50
[85362.132829]  devkmsg_write+0x115/0x160
[85362.132831]  do_iter_readv_writev+0xd8/0x100
[85362.132833]  do_readv_writev+0xdf/0x220
[85362.132835]  ? __might_fault+0x37/0x90
[85362.132838]  ? entry_SYSCALL_64_fastpath+0x5/0xc2
[85362.132839]  vfs_writev+0x3a/0x50
[85362.132841]  do_writev+0x4c/0xd0
[85362.132842]  SyS_writev+0xb/0x10
[85362.132843]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[85362.132845] RIP: 0033:0x7fc6d305c46d
[85362.132846] RSP: 002b:7ffca94161e0 EFLAGS: 0293 ORIG_RAX:
0014
[85362.132847] RAX: ffda RBX: 813afad3 RCX:
7fc6d305c46d
[85362.132848] RDX: 0005 RSI: 7ffca94162f0 RDI:
0006
[85362.132849] RBP: c9000d4c3f88 R08:  R09:
0008
[85362.132850] R10: 0069 R11: 0293 R12:
7ffca94162f0
[85362.132851] R13: 55768b19c920 R14: 7ffca9416330 R15:
7ffca94163c0
[85362.132853]  ? __this_cpu_preempt_check+0x13/0x20


Seems to be introduced by :

commit 311191297125156319be8f86d546ea1c569f7e95
Author: WANG Cong 
Date:   Sat Dec 10 14:22:42 2016 -0800

e1000: use disable_hardirq() for e1000_netpoll()

...

The used config can be found there:

http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/config-rcx


Regards,

Gabriel C

Re: [PATCH V2 0/6] PM / Domains: Implement domain performance states

[Kevin Hilman]

Viresh Kumar  writes:

> An earlier series[1] tried to implement bindings for PM domain
> performance states. Rob Herring suggested that we can actually merge the
> supporting code first instead of bindings, as that will make things
> easier to understand for all. The bindings can be decided and merged
> later.
>
> The bindings [1] aren't discarded yet and this series is based on a
> version of those only. The bindings are only used by the last patch,
> which should not be applied and is only sent for completeness.
>
> IOW, this series doesn't have any dependencies and can be merged
> straight away without waiting for the DT bindings.
>
> A brief summary of the problem this series is trying to solve:
>
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.

And what about domains where the performance levels are represented by
someting other than positive integer values? 

IMO, this implementation should start with a more generic approach
(e.g. OPPs) that would be useful on more SoCs that just qcom.  For SoCs
like QCOM, you could use dummy/simplfied OPPs that represent the integer
values passed to the qcom firmware.

> We decided earlier that we should extend Power Domain framework to
> support active state power management as well. The power-domains until
> now were only concentrating on the idle state management of the device
> and this needs to change in order to reuse the infrastructure of power
> domains for active state management.

Yes.  Thanks for working on it!

Kevin

Re: [PATCH V2 0/6] PM / Domains: Implement domain performance states

[Kevin Hilman]

Viresh Kumar  writes:

> An earlier series[1] tried to implement bindings for PM domain
> performance states. Rob Herring suggested that we can actually merge the
> supporting code first instead of bindings, as that will make things
> easier to understand for all. The bindings can be decided and merged
> later.
>
> The bindings [1] aren't discarded yet and this series is based on a
> version of those only. The bindings are only used by the last patch,
> which should not be applied and is only sent for completeness.
>
> IOW, this series doesn't have any dependencies and can be merged
> straight away without waiting for the DT bindings.
>
> A brief summary of the problem this series is trying to solve:
>
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.

And what about domains where the performance levels are represented by
someting other than positive integer values? 

IMO, this implementation should start with a more generic approach
(e.g. OPPs) that would be useful on more SoCs that just qcom.  For SoCs
like QCOM, you could use dummy/simplfied OPPs that represent the integer
values passed to the qcom firmware.

> We decided earlier that we should extend Power Domain framework to
> support active state power management as well. The power-domains until
> now were only concentrating on the idle state management of the device
> and this needs to change in order to reuse the infrastructure of power
> domains for active state management.

Yes.  Thanks for working on it!

Kevin

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Gabriel C]

On 17.02.2017 23:38, Cong Wang wrote:

On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C  wrote:

Hi all,

while poking at a different issue I found the following on my logs :

[85362.132770] BUG: sleeping function called from invalid context at
kernel/irq/manage.c:110
[85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153, name:
systemd-journal
[85362.132772] no locks held by systemd-journal/1153.
[85362.132772] irq event stamp: 60088359
[85362.132777] hardirqs last  enabled at (60088359): []
vprintk_emit+0x432/0x470
[85362.132779] hardirqs last disabled at (60088358): []
vprintk_emit+0x5c/0x470
[85362.132782] softirqs last  enabled at (60088258): []
__do_softirq+0x22d/0x290
[85362.132784] softirqs last disabled at (60088233): []
irq_exit+0x6a/0xd0
[85362.132784] Preemption disabled at:
[85362.132787] [] write_msg+0x4e/0xf0
[85362.132790] CPU: 0 PID: 1153 Comm: systemd-journal Tainted: G  I
4.10.0-rc8-debug-1-ga1015e374d94-dirty #5
[85362.132791] Hardware name: FUJITSU  PRIMERGY
TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709
02/04/2013
[85362.132792] Call Trace:
[85362.132796]  dump_stack+0x86/0xc1
[85362.132799]  ___might_sleep+0x213/0x230
[85362.132801]  __might_sleep+0x6b/0x80
[85362.132803]  synchronize_irq+0x33/0x90
[85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
[85362.132807]  ? __disable_irq_nosync+0x4e/0x60
[85362.132808]  disable_irq+0x17/0x20



Hmm, your kernel base version is 4.10.0-rc8 but the symbols here
look like prior to my commit, because with my commit here should
be disable_hardirq() calling synchronize_hardirq().

Did you revert it or make any local changes?


The kernel is -rc8 with reverted d966564fcdc19e13eb6ba1fbe6b8101070339c3d
+ 
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=202461e2f3c15dbfb05825d29ace0d20cdf55fa4
+ an debug patch from Thomas to find these goldfish issues.
( 
http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/goldfish-debug.patch )

No other changes..






[85362.132810]  e1000_netpoll+0x3d/0x110
[85362.132813]  netpoll_poll_dev+0xa0/0x170
[85362.132814]  netpoll_send_skb_on_dev+0x1ab/0x2b0
[85362.132816]  netpoll_send_udp+0x417/0x450
[85362.132817]  write_msg+0xdb/0xf0
[85362.132819]  console_unlock+0x2e5/0x430
[85362.132821]  ? __down_trylock_console_sem+0x41/0x60
[85362.132822]  vprintk_emit+0x456/0x470
[85362.132825]  printk_emit+0x2e/0x36
[85362.132827]  ? simple_strtoull+0x2c/0x50
[85362.132829]  devkmsg_write+0x115/0x160
[85362.132831]  do_iter_readv_writev+0xd8/0x100
[85362.132833]  do_readv_writev+0xdf/0x220
[85362.132835]  ? __might_fault+0x37/0x90
[85362.132838]  ? entry_SYSCALL_64_fastpath+0x5/0xc2
[85362.132839]  vfs_writev+0x3a/0x50
[85362.132841]  do_writev+0x4c/0xd0
[85362.132842]  SyS_writev+0xb/0x10
[85362.132843]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[85362.132845] RIP: 0033:0x7fc6d305c46d
[85362.132846] RSP: 002b:7ffca94161e0 EFLAGS: 0293 ORIG_RAX:
0014
[85362.132847] RAX: ffda RBX: 813afad3 RCX:
7fc6d305c46d
[85362.132848] RDX: 0005 RSI: 7ffca94162f0 RDI:
0006
[85362.132849] RBP: c9000d4c3f88 R08:  R09:
0008
[85362.132850] R10: 0069 R11: 0293 R12:
7ffca94162f0
[85362.132851] R13: 55768b19c920 R14: 7ffca9416330 R15:
7ffca94163c0
[85362.132853]  ? __this_cpu_preempt_check+0x13/0x20


Seems to be introduced by :

commit 311191297125156319be8f86d546ea1c569f7e95
Author: WANG Cong 
Date:   Sat Dec 10 14:22:42 2016 -0800

e1000: use disable_hardirq() for e1000_netpoll()

...

The used config can be found there:

http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/config-rcx


Regards,

Gabriel C

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Gabriel C]

On 17.02.2017 23:38, Cong Wang wrote:

On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C  wrote:

Hi all,

while poking at a different issue I found the following on my logs :

[85362.132770] BUG: sleeping function called from invalid context at
kernel/irq/manage.c:110
[85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153, name:
systemd-journal
[85362.132772] no locks held by systemd-journal/1153.
[85362.132772] irq event stamp: 60088359
[85362.132777] hardirqs last  enabled at (60088359): []
vprintk_emit+0x432/0x470
[85362.132779] hardirqs last disabled at (60088358): []
vprintk_emit+0x5c/0x470
[85362.132782] softirqs last  enabled at (60088258): []
__do_softirq+0x22d/0x290
[85362.132784] softirqs last disabled at (60088233): []
irq_exit+0x6a/0xd0
[85362.132784] Preemption disabled at:
[85362.132787] [] write_msg+0x4e/0xf0
[85362.132790] CPU: 0 PID: 1153 Comm: systemd-journal Tainted: G  I
4.10.0-rc8-debug-1-ga1015e374d94-dirty #5
[85362.132791] Hardware name: FUJITSU  PRIMERGY
TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709
02/04/2013
[85362.132792] Call Trace:
[85362.132796]  dump_stack+0x86/0xc1
[85362.132799]  ___might_sleep+0x213/0x230
[85362.132801]  __might_sleep+0x6b/0x80
[85362.132803]  synchronize_irq+0x33/0x90
[85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
[85362.132807]  ? __disable_irq_nosync+0x4e/0x60
[85362.132808]  disable_irq+0x17/0x20



Hmm, your kernel base version is 4.10.0-rc8 but the symbols here
look like prior to my commit, because with my commit here should
be disable_hardirq() calling synchronize_hardirq().

Did you revert it or make any local changes?


The kernel is -rc8 with reverted d966564fcdc19e13eb6ba1fbe6b8101070339c3d
+ 
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=202461e2f3c15dbfb05825d29ace0d20cdf55fa4
+ an debug patch from Thomas to find these goldfish issues.
( 
http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/goldfish-debug.patch )

No other changes..






[85362.132810]  e1000_netpoll+0x3d/0x110
[85362.132813]  netpoll_poll_dev+0xa0/0x170
[85362.132814]  netpoll_send_skb_on_dev+0x1ab/0x2b0
[85362.132816]  netpoll_send_udp+0x417/0x450
[85362.132817]  write_msg+0xdb/0xf0
[85362.132819]  console_unlock+0x2e5/0x430
[85362.132821]  ? __down_trylock_console_sem+0x41/0x60
[85362.132822]  vprintk_emit+0x456/0x470
[85362.132825]  printk_emit+0x2e/0x36
[85362.132827]  ? simple_strtoull+0x2c/0x50
[85362.132829]  devkmsg_write+0x115/0x160
[85362.132831]  do_iter_readv_writev+0xd8/0x100
[85362.132833]  do_readv_writev+0xdf/0x220
[85362.132835]  ? __might_fault+0x37/0x90
[85362.132838]  ? entry_SYSCALL_64_fastpath+0x5/0xc2
[85362.132839]  vfs_writev+0x3a/0x50
[85362.132841]  do_writev+0x4c/0xd0
[85362.132842]  SyS_writev+0xb/0x10
[85362.132843]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[85362.132845] RIP: 0033:0x7fc6d305c46d
[85362.132846] RSP: 002b:7ffca94161e0 EFLAGS: 0293 ORIG_RAX:
0014
[85362.132847] RAX: ffda RBX: 813afad3 RCX:
7fc6d305c46d
[85362.132848] RDX: 0005 RSI: 7ffca94162f0 RDI:
0006
[85362.132849] RBP: c9000d4c3f88 R08:  R09:
0008
[85362.132850] R10: 0069 R11: 0293 R12:
7ffca94162f0
[85362.132851] R13: 55768b19c920 R14: 7ffca9416330 R15:
7ffca94163c0
[85362.132853]  ? __this_cpu_preempt_check+0x13/0x20


Seems to be introduced by :

commit 311191297125156319be8f86d546ea1c569f7e95
Author: WANG Cong 
Date:   Sat Dec 10 14:22:42 2016 -0800

e1000: use disable_hardirq() for e1000_netpoll()

...

The used config can be found there:

http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/config-rcx


Regards,

Gabriel C

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

[hpa]

On February 17, 2017 3:02:33 PM PST, Andy Lutomirski  
wrote:
>On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds
> wrote:
>> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski
> wrote:
>>>
>>> At the very least, I'd want to see
>>> MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING.  I *hate* the current
>>> interface.
>>
>> That's unrelated, but I guess w could add a MAP_NOUNMAP flag, and
>then
>> you can use MAP_FIXED | MAP_NOUNMAP or something.
>>
>> But that has nothing to do with the 47-vs-56 bit issue.
>>
>>> How about MAP_LIMIT where the address passed in is interpreted as an
>>> upper bound instead of a fixed address?
>>
>> Again, that's a unrelated semantic issue. Right now - if you don't
>> pass in MAP_FIXED at all, the "addr" argument is used as a starting
>> value for deciding where to find an unmapped area. But there is no
>way
>> to specify the end. That would basically be what the process control
>> thing would be (not per-system-call, but per-thread ).
>>
>
>What I'm trying to say is: if we're going to do the route of 48-bit
>limit unless a specific mmap call requests otherwise, can we at least
>have an interface that doesn't suck?

Let's not, please.

But we really want this interface anyway.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[ANNOUNCE] Git v2.12.0-rc2

[Junio C Hamano]

A release candidate Git v2.12.0-rc2 is now available for testing
at the usual places.  It is comprised of 487 non-merge commits
since v2.11.0, contributed by 67 people, 21 of which are new faces.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/testing/

The following public repositories all have a copy of the
'v2.12.0-rc2' tag and the 'master' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

New contributors whose contributions weren't in v2.11.0 are as follows.
Welcome to the Git development community!

  Alan Davies, Andreas Krey, Cornelius Weig, David Pursehouse,
  Denton Liu, George Vanburgh, Igor Kushnir, Jack Bates,
  Kristoffer Haugsbakk, Kyle Meyer, Luis Ressel, Lukas Puehringer,
  Markus Hitter, Peter Law, Rasmus Villemoes, Rogier Goossens,
  Stefan Dotterweich, Steven Penny, Vinicius Kursancew, Vladimir
  Panteleev, and Wolfram Sang.

Returning contributors who helped this release are as follows.
Thanks for your continued support.

  마누엘, Alex Henrie, Beat Bolli, Brandon Williams, brian
  m. carlson, Chris Packham, Christian Couder, David Aguilar, David
  Turner, Dennis Kaarsemaker, Dimitriy Ryazantcev, Elia Pinto,
  Eric Wong, Heiko Voigt, Jacob Keller, Jeff Hostetler, Jeff King,
  Johannes Schindelin, Johannes Sixt, Jonathan Tan, Junio C Hamano,
  Kyle J. McKay, Lars Schneider, Linus Torvalds, Luke Diamand, Matt
  McCutchen, Max Kirillov, Mike Hommey, Nguyễn Thái Ngọc Duy,
  Patrick Steinhardt, Paul Mackerras, Philip Oakley, Pranit Bauva,
  Ramsay Jones, René Scharfe, Richard Hansen, Santiago Torres,
  Satoshi Yasushima, Stefan Beller, Stephan Beyer, SZEDER Gábor,
  Thomas Gummerer, Torsten Bögershausen, Vasco Almeida, Vegard
  Nossum, and Vitaly "_Vi" Shukela.



Git 2.12 Release Notes (draft)
==

Backward compatibility notes.

 * Use of an empty string that is used for 'everything matches' is
   still warned and Git asks users to use a more explicit '.' for that
   instead.  The hope is that existing users will not mind this
   change, and eventually the warning can be turned into a hard error,
   upgrading the deprecation into removal of this (mis)feature.  That
   is not scheduled to happen in the upcoming release (yet).

 * The historical argument order "git merge  HEAD ..."
   has been deprecated for quite some time, and will be removed in a
   future release.

 * An ancient script "git relink" has been removed.


Updates since v2.11
---

UI, Workflows & Features

 * Various updates to "git p4".

 * "git p4" didn't interact with the internal of .git directory
   correctly in the modern "git-worktree"-enabled world.

 * "git branch --list" and friends learned "--ignore-case" option to
   optionally sort branches and tags case insensitively.

 * In addition to %(subject), %(body), "log --pretty=format:..."
   learned a new placeholder %(trailers).

 * "git rebase" learned "--quit" option, which allows a user to
   remove the metadata left by an earlier "git rebase" that was
   manually aborted without using "git rebase --abort".

 * "git clone --reference $there --recurse-submodules $super" has been
   taught to guess repositories usable as references for submodules of
   $super that are embedded in $there while making a clone of the
   superproject borrow objects from $there; extend the mechanism to
   also allow submodules of these submodules to borrow repositories
   embedded in these clones of the submodules embedded in the clone of
   the superproject.

 * Porcelain scripts written in Perl are getting internationalized.

 * "git merge --continue" has been added as a synonym to "git commit"
   to conclude a merge that has stopped due to conflicts.

 * Finer-grained control of what protocols are allowed for transports
   during clone/fetch/push have been enabled via a new configuration
   mechanism.

 * "git shortlog" learned "--committer" option to group commits by
   committer, instead of author.

 * GitLFS integration with "git p4" has been updated.

 * The isatty() emulation for Windows has been updated to eradicate
   the previous hack that depended on internals of (older) MSVC
   runtime.

 * Some platforms no longer understand "latin-1" that is still seen in
   the wild in e-mail headers; replace them with "iso-8859-1" that is
   more widely known when conversion fails from/to it.

 * "git grep" has been taught to optionally recurse into submodules.

 * "git rm" used to refuse to remove a submodule when it has its own
   git repository embedded in its working tree.  It learned to move
   the repository away to $GIT_DIR/modules/ of the superproject
   instead, and allow the submodule to be deleted (as long 

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

[hpa]

On February 17, 2017 3:02:33 PM PST, Andy Lutomirski  
wrote:
>On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds
> wrote:
>> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski
> wrote:
>>>
>>> At the very least, I'd want to see
>>> MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING.  I *hate* the current
>>> interface.
>>
>> That's unrelated, but I guess w could add a MAP_NOUNMAP flag, and
>then
>> you can use MAP_FIXED | MAP_NOUNMAP or something.
>>
>> But that has nothing to do with the 47-vs-56 bit issue.
>>
>>> How about MAP_LIMIT where the address passed in is interpreted as an
>>> upper bound instead of a fixed address?
>>
>> Again, that's a unrelated semantic issue. Right now - if you don't
>> pass in MAP_FIXED at all, the "addr" argument is used as a starting
>> value for deciding where to find an unmapped area. But there is no
>way
>> to specify the end. That would basically be what the process control
>> thing would be (not per-system-call, but per-thread ).
>>
>
>What I'm trying to say is: if we're going to do the route of 48-bit
>limit unless a specific mmap call requests otherwise, can we at least
>have an interface that doesn't suck?

Let's not, please.

But we really want this interface anyway.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[ANNOUNCE] Git v2.12.0-rc2

[Junio C Hamano]

A release candidate Git v2.12.0-rc2 is now available for testing
at the usual places.  It is comprised of 487 non-merge commits
since v2.11.0, contributed by 67 people, 21 of which are new faces.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/testing/

The following public repositories all have a copy of the
'v2.12.0-rc2' tag and the 'master' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

New contributors whose contributions weren't in v2.11.0 are as follows.
Welcome to the Git development community!

  Alan Davies, Andreas Krey, Cornelius Weig, David Pursehouse,
  Denton Liu, George Vanburgh, Igor Kushnir, Jack Bates,
  Kristoffer Haugsbakk, Kyle Meyer, Luis Ressel, Lukas Puehringer,
  Markus Hitter, Peter Law, Rasmus Villemoes, Rogier Goossens,
  Stefan Dotterweich, Steven Penny, Vinicius Kursancew, Vladimir
  Panteleev, and Wolfram Sang.

Returning contributors who helped this release are as follows.
Thanks for your continued support.

  마누엘, Alex Henrie, Beat Bolli, Brandon Williams, brian
  m. carlson, Chris Packham, Christian Couder, David Aguilar, David
  Turner, Dennis Kaarsemaker, Dimitriy Ryazantcev, Elia Pinto,
  Eric Wong, Heiko Voigt, Jacob Keller, Jeff Hostetler, Jeff King,
  Johannes Schindelin, Johannes Sixt, Jonathan Tan, Junio C Hamano,
  Kyle J. McKay, Lars Schneider, Linus Torvalds, Luke Diamand, Matt
  McCutchen, Max Kirillov, Mike Hommey, Nguyễn Thái Ngọc Duy,
  Patrick Steinhardt, Paul Mackerras, Philip Oakley, Pranit Bauva,
  Ramsay Jones, René Scharfe, Richard Hansen, Santiago Torres,
  Satoshi Yasushima, Stefan Beller, Stephan Beyer, SZEDER Gábor,
  Thomas Gummerer, Torsten Bögershausen, Vasco Almeida, Vegard
  Nossum, and Vitaly "_Vi" Shukela.



Git 2.12 Release Notes (draft)
==

Backward compatibility notes.

 * Use of an empty string that is used for 'everything matches' is
   still warned and Git asks users to use a more explicit '.' for that
   instead.  The hope is that existing users will not mind this
   change, and eventually the warning can be turned into a hard error,
   upgrading the deprecation into removal of this (mis)feature.  That
   is not scheduled to happen in the upcoming release (yet).

 * The historical argument order "git merge  HEAD ..."
   has been deprecated for quite some time, and will be removed in a
   future release.

 * An ancient script "git relink" has been removed.


Updates since v2.11
---

UI, Workflows & Features

 * Various updates to "git p4".

 * "git p4" didn't interact with the internal of .git directory
   correctly in the modern "git-worktree"-enabled world.

 * "git branch --list" and friends learned "--ignore-case" option to
   optionally sort branches and tags case insensitively.

 * In addition to %(subject), %(body), "log --pretty=format:..."
   learned a new placeholder %(trailers).

 * "git rebase" learned "--quit" option, which allows a user to
   remove the metadata left by an earlier "git rebase" that was
   manually aborted without using "git rebase --abort".

 * "git clone --reference $there --recurse-submodules $super" has been
   taught to guess repositories usable as references for submodules of
   $super that are embedded in $there while making a clone of the
   superproject borrow objects from $there; extend the mechanism to
   also allow submodules of these submodules to borrow repositories
   embedded in these clones of the submodules embedded in the clone of
   the superproject.

 * Porcelain scripts written in Perl are getting internationalized.

 * "git merge --continue" has been added as a synonym to "git commit"
   to conclude a merge that has stopped due to conflicts.

 * Finer-grained control of what protocols are allowed for transports
   during clone/fetch/push have been enabled via a new configuration
   mechanism.

 * "git shortlog" learned "--committer" option to group commits by
   committer, instead of author.

 * GitLFS integration with "git p4" has been updated.

 * The isatty() emulation for Windows has been updated to eradicate
   the previous hack that depended on internals of (older) MSVC
   runtime.

 * Some platforms no longer understand "latin-1" that is still seen in
   the wild in e-mail headers; replace them with "iso-8859-1" that is
   more widely known when conversion fails from/to it.

 * "git grep" has been taught to optionally recurse into submodules.

 * "git rm" used to refuse to remove a submodule when it has its own
   git repository embedded in its working tree.  It learned to move
   the repository away to $GIT_DIR/modules/ of the superproject
   instead, and allow the submodule to be deleted (as long 

Re: [PATCH 4/5] staging: bcm2835-audio: bcm2835.h: fix volatile coding style issue

[Joe Perches]

On Fri, 2017-02-17 at 15:16 -0500, Nathan Howard wrote:
> Fix checkpatch.pl warning of the form "WARNING: Use of volatile is
> usually wrong: see Documentation/process/volatile-considered-harmful.rst."

Why are you sure the volatile use is not necessary?

> Signed-off-by: Nathan Howard 
> ---
>  drivers/staging/bcm2835-audio/bcm2835.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/bcm2835-audio/bcm2835.h 
> b/drivers/staging/bcm2835-audio/bcm2835.h
> index 2f9d1c9..08f7ad6 100644
> --- a/drivers/staging/bcm2835-audio/bcm2835.h
> +++ b/drivers/staging/bcm2835-audio/bcm2835.h
> @@ -125,8 +125,8 @@ struct bcm2835_alsa_stream {
>   struct semaphore buffers_update_sem;
>   struct semaphore control_sem;
>   spinlock_t lock;
> - volatile unsigned int control;
> - volatile unsigned int status;
> + unsigned int control;
> + unsigned int status;
>  
>   int open;
>   int running;

Re: [PATCH 4/5] staging: bcm2835-audio: bcm2835.h: fix volatile coding style issue

[Joe Perches]

On Fri, 2017-02-17 at 15:16 -0500, Nathan Howard wrote:
> Fix checkpatch.pl warning of the form "WARNING: Use of volatile is
> usually wrong: see Documentation/process/volatile-considered-harmful.rst."

Why are you sure the volatile use is not necessary?

> Signed-off-by: Nathan Howard 
> ---
>  drivers/staging/bcm2835-audio/bcm2835.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/bcm2835-audio/bcm2835.h 
> b/drivers/staging/bcm2835-audio/bcm2835.h
> index 2f9d1c9..08f7ad6 100644
> --- a/drivers/staging/bcm2835-audio/bcm2835.h
> +++ b/drivers/staging/bcm2835-audio/bcm2835.h
> @@ -125,8 +125,8 @@ struct bcm2835_alsa_stream {
>   struct semaphore buffers_update_sem;
>   struct semaphore control_sem;
>   spinlock_t lock;
> - volatile unsigned int control;
> - volatile unsigned int status;
> + unsigned int control;
> + unsigned int status;
>  
>   int open;
>   int running;

Re: [PATCH 2/2] mmc: meson-gx: remove mmc host on device removal

[Kevin Hilman]

Michał Zegan  writes:

> W dniu 17.02.2017 o 20:47, Kevin Hilman pisze:
>> Michał Zegan  writes:
>>
>>> The mmc host was added in meson_mmc_probe, but never removed in 
>>> meson_mmc_remove.
>>> Fix that by removing the host before deallocating other resources.
>>>
>>> Signed-off-by: Michał Zegan 
>> Reviewed-by: Kevin Hilman 
>
> I do not know how the mmc driver looks like after Heiner's cleanup. Does
> this patch get obsoleted by the prior cleanup, or conflict with it in
> some way?

It's not obsoleted, as I don't think Heiner's series fixes this problem,
but it may have minor conflicts.

I suggest you rebase this patch on top of Heiner's v2 to double check,
and resend if necessary, noting in the patch (after the '---') what it
applies on top of so that the MMC maintainers don't have to figure it
out.

Thanks,

Kevin

>>
>>> ---
>>>  drivers/mmc/host/meson-gx-mmc.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/meson-gx-mmc.c 
>>> b/drivers/mmc/host/meson-gx-mmc.c
>>> index d444b6bfa02b..bb83446118a3 100644
>>> --- a/drivers/mmc/host/meson-gx-mmc.c
>>> +++ b/drivers/mmc/host/meson-gx-mmc.c
>>> @@ -818,6 +818,8 @@ static int meson_mmc_remove(struct platform_device 
>>> *pdev)
>>> if (WARN_ON(!host))
>>> return 0;
>>>  
>>> +   mmc_remove_host(host->mmc);
>>> +
>>> if (host->bounce_buf)
>>> dma_free_coherent(host->dev, host->bounce_buf_size,
>>>   host->bounce_buf, host->bounce_dma_addr);

Re: [PATCH 2/2] mmc: meson-gx: remove mmc host on device removal

[Kevin Hilman]

Michał Zegan  writes:

> W dniu 17.02.2017 o 20:47, Kevin Hilman pisze:
>> Michał Zegan  writes:
>>
>>> The mmc host was added in meson_mmc_probe, but never removed in 
>>> meson_mmc_remove.
>>> Fix that by removing the host before deallocating other resources.
>>>
>>> Signed-off-by: Michał Zegan 
>> Reviewed-by: Kevin Hilman 
>
> I do not know how the mmc driver looks like after Heiner's cleanup. Does
> this patch get obsoleted by the prior cleanup, or conflict with it in
> some way?

It's not obsoleted, as I don't think Heiner's series fixes this problem,
but it may have minor conflicts.

I suggest you rebase this patch on top of Heiner's v2 to double check,
and resend if necessary, noting in the patch (after the '---') what it
applies on top of so that the MMC maintainers don't have to figure it
out.

Thanks,

Kevin

>>
>>> ---
>>>  drivers/mmc/host/meson-gx-mmc.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/meson-gx-mmc.c 
>>> b/drivers/mmc/host/meson-gx-mmc.c
>>> index d444b6bfa02b..bb83446118a3 100644
>>> --- a/drivers/mmc/host/meson-gx-mmc.c
>>> +++ b/drivers/mmc/host/meson-gx-mmc.c
>>> @@ -818,6 +818,8 @@ static int meson_mmc_remove(struct platform_device 
>>> *pdev)
>>> if (WARN_ON(!host))
>>> return 0;
>>>  
>>> +   mmc_remove_host(host->mmc);
>>> +
>>> if (host->bounce_buf)
>>> dma_free_coherent(host->dev, host->bounce_buf_size,
>>>   host->bounce_buf, host->bounce_dma_addr);

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

[Andy Lutomirski]

On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds
 wrote:
> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski  wrote:
>>
>> At the very least, I'd want to see
>> MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING.  I *hate* the current
>> interface.
>
> That's unrelated, but I guess w could add a MAP_NOUNMAP flag, and then
> you can use MAP_FIXED | MAP_NOUNMAP or something.
>
> But that has nothing to do with the 47-vs-56 bit issue.
>
>> How about MAP_LIMIT where the address passed in is interpreted as an
>> upper bound instead of a fixed address?
>
> Again, that's a unrelated semantic issue. Right now - if you don't
> pass in MAP_FIXED at all, the "addr" argument is used as a starting
> value for deciding where to find an unmapped area. But there is no way
> to specify the end. That would basically be what the process control
> thing would be (not per-system-call, but per-thread ).
>

What I'm trying to say is: if we're going to do the route of 48-bit
limit unless a specific mmap call requests otherwise, can we at least
have an interface that doesn't suck?

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

[Andy Lutomirski]

On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds
 wrote:
> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski  wrote:
>>
>> At the very least, I'd want to see
>> MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING.  I *hate* the current
>> interface.
>
> That's unrelated, but I guess w could add a MAP_NOUNMAP flag, and then
> you can use MAP_FIXED | MAP_NOUNMAP or something.
>
> But that has nothing to do with the 47-vs-56 bit issue.
>
>> How about MAP_LIMIT where the address passed in is interpreted as an
>> upper bound instead of a fixed address?
>
> Again, that's a unrelated semantic issue. Right now - if you don't
> pass in MAP_FIXED at all, the "addr" argument is used as a starting
> value for deciding where to find an unmapped area. But there is no way
> to specify the end. That would basically be what the process control
> thing would be (not per-system-call, but per-thread ).
>

What I'm trying to say is: if we're going to do the route of 48-bit
limit unless a specific mmap call requests otherwise, can we at least
have an interface that doesn't suck?

[PATCH] Input: tsc2007 - switch to using input_set_capability()

[Dmitry Torokhov]

Do not manipulate evbit/keybit directly, use helper for that.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/tsc2007_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2007_core.c 
b/drivers/input/touchscreen/tsc2007_core.c
index fdf81a2b989a..98dbefc3357d 100644
--- a/drivers/input/touchscreen/tsc2007_core.c
+++ b/drivers/input/touchscreen/tsc2007_core.c
@@ -364,8 +364,7 @@ static int tsc2007_probe(struct i2c_client *client,
 
input_set_drvdata(input_dev, ts);
 
-   input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
-   input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+   input_set_capability(input_dev, EV_KEY, BTN_TOUCH);
 
input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, ts->fuzzx, 0);
input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, ts->fuzzy, 0);
-- 
2.11.0.483.g087da7b7c-goog


-- 
Dmitry

[PATCH] Input: tsc2007 - switch to using input_set_capability()

[Dmitry Torokhov]

Do not manipulate evbit/keybit directly, use helper for that.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/touchscreen/tsc2007_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2007_core.c 
b/drivers/input/touchscreen/tsc2007_core.c
index fdf81a2b989a..98dbefc3357d 100644
--- a/drivers/input/touchscreen/tsc2007_core.c
+++ b/drivers/input/touchscreen/tsc2007_core.c
@@ -364,8 +364,7 @@ static int tsc2007_probe(struct i2c_client *client,
 
input_set_drvdata(input_dev, ts);
 
-   input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
-   input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+   input_set_capability(input_dev, EV_KEY, BTN_TOUCH);
 
input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, ts->fuzzx, 0);
input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, ts->fuzzy, 0);
-- 
2.11.0.483.g087da7b7c-goog


-- 
Dmitry

Re: [PATCH v9] soc: qcom: Add SoC info driver

[Stephen Boyd]

On 02/16, Imran Khan wrote:
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 18ec52f..4f0ccf8 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -85,6 +85,9 @@
>  /* Max number of processors/hosts in a system */
>  #define SMEM_HOST_COUNT  9
>  
> +
> +extern void qcom_socinfo_init(struct device *device);
> +

Sparse still complains... o well.

> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
> new file mode 100644
> index 000..495f937
> --- /dev/null
> +++ b/drivers/soc/qcom/socinfo.c
> @@ -0,0 +1,557 @@
> +/*
> + * Copyright (c) 2009-2017, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * SOC version type with major number in the upper 16 bits and minor
> + * number in the lower 16 bits.  For example:
> + *   1.0 -> 0x0001
> + *   2.3 -> 0x00020003
> + */
> +#define SOC_VER_MAJ(ver) (((ver) & 0x) >> 16)
> +#define SOC_VER_MIN(ver) ((ver) & 0x)
> +#define SOCINFO_VERSION_MAJORSOC_VER_MAJ
> +#define SOCINFO_VERSION_MINORSOC_VER_MIN

Do we really need two defines for the same thing?

> +
> +#define SMEM_SOCINFO_BUILD_ID_LENGTH 32
> +#define SMEM_IMAGE_VERSION_BLOCKS_COUNT  32
> +#define SMEM_IMAGE_VERSION_SIZE  4096
> +#define SMEM_IMAGE_VERSION_NAME_SIZE 75
> +#define SMEM_IMAGE_VERSION_VARIANT_SIZE  20
> +#define SMEM_IMAGE_VERSION_OEM_SIZE  32
> +
> +/*
> + * SMEM item ids, used to acquire handles to respective
> + * SMEM region.
> + */
> +#define SMEM_IMAGE_VERSION_TABLE 469
> +#define SMEM_HW_SW_BUILD_ID  137
> +
> +/*
> + * SMEM Image table indices
> + */
> +#define SMEM_IMAGE_TABLE_BOOT_INDEX  0
> +#define SMEM_IMAGE_TABLE_TZ_INDEX1
> +#define SMEM_IMAGE_TABLE_RPM_INDEX   3
> +#define SMEM_IMAGE_TABLE_APPS_INDEX  10
> +#define SMEM_IMAGE_TABLE_MPSS_INDEX  11
> +#define SMEM_IMAGE_TABLE_ADSP_INDEX  12
> +#define SMEM_IMAGE_TABLE_CNSS_INDEX  13
> +#define SMEM_IMAGE_TABLE_VIDEO_INDEX 14
> +
> +struct qcom_socinfo_attr {
> + struct device_attribute attr;
> + int min_ver;
> +};
> +
> +#define QCOM_SOCINFO_ATTR(_name, _show, _min_ver) \
> + { __ATTR(_name, 0444, _show, NULL), _min_ver }
> +
> +
> +struct smem_image_attribute {
> + struct device_attribute version;
> + struct device_attribute variant;
> + struct device_attribute crm;
> + int index;
> +};
> +
> +#define QCOM_SMEM_IMG_ITEM(_name, _mode, _index) \
> + static struct smem_image_attribute _name##_image_attrs = { \
> + __ATTR(_name##_image_version, _mode, \
> + qcom_show_image_version, qcom_store_image_version), \
> + __ATTR(_name##_image_variant, _mode, \
> + qcom_show_image_variant, qcom_store_image_variant), \
> + __ATTR(_name##_image_crm, _mode, \
> + qcom_show_image_crm, qcom_store_image_crm), \
> + _index \
> + }; \
> + static struct attribute_group _name##_image_attr_group = { \

can be const.

> + .attrs = (struct attribute*[]) { \
> + &_name##_image_attrs.version.attr, \
> + &_name##_image_attrs.variant.attr, \
> + &_name##_image_attrs.crm.attr, \
> + NULL \
> + } \
> + }
> +
> +static const char *const pmic_model[] = {
> + [0]  = "Unknown PMIC model",

Missing pm8916, but it doesn't seem to matter for me. My db410c
says 0 here.

> + [13] = "PM8058",
> + [14] = "PM8028",
> + [15] = "PM8901",
> + [16] = "PM8027",
> + [17] = "ISL9519",
> + [18] = "PM8921",
> + [19] = "PM8018",
> + [20] = "PM8015",
> + [21] = "PM8014",
> + [22] = "PM8821",
> + [23] = "PM8038",
> + [24] = "PM8922",
> + [25] = "PM8917",
> +};
> +
> +struct smem_image_version {
> + char name[SMEM_IMAGE_VERSION_NAME_SIZE];
> + char variant[SMEM_IMAGE_VERSION_VARIANT_SIZE];
> + char pad;
> + char oem[SMEM_IMAGE_VERSION_OEM_SIZE];
> +};
> +
> +struct qcom_soc_info {
> + int id;
> + const char *name;
> +};
> +
> +/* Used to parse shared memory. Must match the modem. */
> +struct socinfo_v0_1 {
> + __le32 fmt;
> + __le32 id;
> + __le32 ver;
> + char 

Re: [PATCH v9] soc: qcom: Add SoC info driver

[Stephen Boyd]

On 02/16, Imran Khan wrote:
> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> index 18ec52f..4f0ccf8 100644
> --- a/drivers/soc/qcom/smem.c
> +++ b/drivers/soc/qcom/smem.c
> @@ -85,6 +85,9 @@
>  /* Max number of processors/hosts in a system */
>  #define SMEM_HOST_COUNT  9
>  
> +
> +extern void qcom_socinfo_init(struct device *device);
> +

Sparse still complains... o well.

> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
> new file mode 100644
> index 000..495f937
> --- /dev/null
> +++ b/drivers/soc/qcom/socinfo.c
> @@ -0,0 +1,557 @@
> +/*
> + * Copyright (c) 2009-2017, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * SOC version type with major number in the upper 16 bits and minor
> + * number in the lower 16 bits.  For example:
> + *   1.0 -> 0x0001
> + *   2.3 -> 0x00020003
> + */
> +#define SOC_VER_MAJ(ver) (((ver) & 0x) >> 16)
> +#define SOC_VER_MIN(ver) ((ver) & 0x)
> +#define SOCINFO_VERSION_MAJORSOC_VER_MAJ
> +#define SOCINFO_VERSION_MINORSOC_VER_MIN

Do we really need two defines for the same thing?

> +
> +#define SMEM_SOCINFO_BUILD_ID_LENGTH 32
> +#define SMEM_IMAGE_VERSION_BLOCKS_COUNT  32
> +#define SMEM_IMAGE_VERSION_SIZE  4096
> +#define SMEM_IMAGE_VERSION_NAME_SIZE 75
> +#define SMEM_IMAGE_VERSION_VARIANT_SIZE  20
> +#define SMEM_IMAGE_VERSION_OEM_SIZE  32
> +
> +/*
> + * SMEM item ids, used to acquire handles to respective
> + * SMEM region.
> + */
> +#define SMEM_IMAGE_VERSION_TABLE 469
> +#define SMEM_HW_SW_BUILD_ID  137
> +
> +/*
> + * SMEM Image table indices
> + */
> +#define SMEM_IMAGE_TABLE_BOOT_INDEX  0
> +#define SMEM_IMAGE_TABLE_TZ_INDEX1
> +#define SMEM_IMAGE_TABLE_RPM_INDEX   3
> +#define SMEM_IMAGE_TABLE_APPS_INDEX  10
> +#define SMEM_IMAGE_TABLE_MPSS_INDEX  11
> +#define SMEM_IMAGE_TABLE_ADSP_INDEX  12
> +#define SMEM_IMAGE_TABLE_CNSS_INDEX  13
> +#define SMEM_IMAGE_TABLE_VIDEO_INDEX 14
> +
> +struct qcom_socinfo_attr {
> + struct device_attribute attr;
> + int min_ver;
> +};
> +
> +#define QCOM_SOCINFO_ATTR(_name, _show, _min_ver) \
> + { __ATTR(_name, 0444, _show, NULL), _min_ver }
> +
> +
> +struct smem_image_attribute {
> + struct device_attribute version;
> + struct device_attribute variant;
> + struct device_attribute crm;
> + int index;
> +};
> +
> +#define QCOM_SMEM_IMG_ITEM(_name, _mode, _index) \
> + static struct smem_image_attribute _name##_image_attrs = { \
> + __ATTR(_name##_image_version, _mode, \
> + qcom_show_image_version, qcom_store_image_version), \
> + __ATTR(_name##_image_variant, _mode, \
> + qcom_show_image_variant, qcom_store_image_variant), \
> + __ATTR(_name##_image_crm, _mode, \
> + qcom_show_image_crm, qcom_store_image_crm), \
> + _index \
> + }; \
> + static struct attribute_group _name##_image_attr_group = { \

can be const.

> + .attrs = (struct attribute*[]) { \
> + &_name##_image_attrs.version.attr, \
> + &_name##_image_attrs.variant.attr, \
> + &_name##_image_attrs.crm.attr, \
> + NULL \
> + } \
> + }
> +
> +static const char *const pmic_model[] = {
> + [0]  = "Unknown PMIC model",

Missing pm8916, but it doesn't seem to matter for me. My db410c
says 0 here.

> + [13] = "PM8058",
> + [14] = "PM8028",
> + [15] = "PM8901",
> + [16] = "PM8027",
> + [17] = "ISL9519",
> + [18] = "PM8921",
> + [19] = "PM8018",
> + [20] = "PM8015",
> + [21] = "PM8014",
> + [22] = "PM8821",
> + [23] = "PM8038",
> + [24] = "PM8922",
> + [25] = "PM8917",
> +};
> +
> +struct smem_image_version {
> + char name[SMEM_IMAGE_VERSION_NAME_SIZE];
> + char variant[SMEM_IMAGE_VERSION_VARIANT_SIZE];
> + char pad;
> + char oem[SMEM_IMAGE_VERSION_OEM_SIZE];
> +};
> +
> +struct qcom_soc_info {
> + int id;
> + const char *name;
> +};
> +
> +/* Used to parse shared memory. Must match the modem. */
> +struct socinfo_v0_1 {
> + __le32 fmt;
> + __le32 id;
> + __le32 ver;
> + char 

Re: [PATCH] Staging: ks7010: ks_*: Braces should be used on all arms of these statements

[Joe Perches]

On Fri, 2017-02-17 at 22:41 +0100, Shiva Kerdel wrote:
> Braces should be used on all arms of these statements (CHECK)..
[]
> diff --git a/drivers/staging/ks7010/ks_hostif.c 
> b/drivers/staging/ks7010/ks_hostif.c
[]
> @@ -2148,8 +2148,9 @@ void hostif_sme_mode_setup(struct ks_wlan_private *priv)
>   else
>   rate_octet[i] =
>   priv->reg.rate_set.body[i];
> - } else
> + } else {
>   break;
> + }

Generally, any time you see a form like this,
the test should be reversed

for/while/do {
if (foo) {
[bar...]
} else {
break;
}

should be:

for/while/do {
if (!foo)
break;
[bar...]
}

Re: [PATCH] Staging: ks7010: ks_*: Braces should be used on all arms of these statements

[Joe Perches]

On Fri, 2017-02-17 at 22:41 +0100, Shiva Kerdel wrote:
> Braces should be used on all arms of these statements (CHECK)..
[]
> diff --git a/drivers/staging/ks7010/ks_hostif.c 
> b/drivers/staging/ks7010/ks_hostif.c
[]
> @@ -2148,8 +2148,9 @@ void hostif_sme_mode_setup(struct ks_wlan_private *priv)
>   else
>   rate_octet[i] =
>   priv->reg.rate_set.body[i];
> - } else
> + } else {
>   break;
> + }

Generally, any time you see a form like this,
the test should be reversed

for/while/do {
if (foo) {
[bar...]
} else {
break;
}

should be:

for/while/do {
if (!foo)
break;
[bar...]
}

Re: [PATCH v2] gpio: dwapb: Add support for next generation of X-Gene SoC

[Hoan Tran]

Hi Andy,

On Fri, Feb 17, 2017 at 2:23 AM, Andy Shevchenko
 wrote:
> On Fri, Feb 17, 2017 at 3:01 AM, Hoan Tran  wrote:
>> Next generation of X-Gene SoC's GPIO hardware register map is very
>> similar to DW GPIO. It only differs by a few register addresses.
>> This patch modifies DW GPIO driver to accommodate the difference
>> in a few register addresses.
>
>> --- a/drivers/gpio/gpio-dwapb.c
>> +++ b/drivers/gpio/gpio-dwapb.c
>> @@ -55,6 +56,13 @@
>>  #define GPIO_SWPORT_DR_SIZE(GPIO_SWPORTB_DR - GPIO_SWPORTA_DR)
>>  #define GPIO_SWPORT_DDR_SIZE   (GPIO_SWPORTB_DDR - GPIO_SWPORTA_DDR)
>>
>> +#define GPIO_REG_OFFSET_V2 1
>
> + empty line
>
>> +#define GPIO_INTMASK_V20x44
>> +#define GPIO_INTTYPE_LEVEL_V2  0x34
>> +#define GPIO_INT_POLARITY_V2   0x38
>> +#define GPIO_INTSTATUS_V2  0x3c
>> +#define GPIO_PORTA_EOI_V2  0x40
>
>> +   unsigned intflags;
>
>> +static inline u32 gpio_reg_convert(struct dwapb_gpio *gpio, unsigned int 
>> offset)
>> +{
>
>> +   if (!(gpio->flags & GPIO_REG_OFFSET_V2))
>> +   return offset;
>
> I would split this to to functions:
>
> ... u32 gpio_reg_convert(...) {
>  if (gpio->flags & ...)
>   return gpio_reg_v2_convert();
>  return offset;
> }
>
>> +   switch (offset) {
>> +   case GPIO_INTMASK:
>> +   return GPIO_INTMASK_V2;
>> +   case GPIO_INTTYPE_LEVEL:
>> +   return GPIO_INTTYPE_LEVEL_V2;
>> +   case GPIO_INT_POLARITY:
>> +   return GPIO_INT_POLARITY_V2;
>> +   case GPIO_INTSTATUS:
>> +   return GPIO_INTSTATUS_V2;
>> +   case GPIO_PORTA_EOI:
>> +   return GPIO_PORTA_EOI_V2;
>> +   }
>> +
>> +   return offset;
>> +}
>
>> -   return gc->read_reg(reg_base + offset);
>> +   return gc->read_reg(reg_base + gpio_reg_convert(gpio, offset));
>
> I'm still not convinced why we can't use
>
> gc->read_reg = ..._read_reg_v2;
>
> It will be called only in case of v2.
>
> Sorry if I missed the point.

This gc->read_reg is from gpio_chip and it is assigned by the upper layer.

>
>>  static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
>> @@ -336,8 +366,8 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
>> ct->chip.irq_disable = dwapb_irq_disable;
>> ct->chip.irq_request_resources = dwapb_irq_reqres;
>> ct->chip.irq_release_resources = dwapb_irq_relres;
>> -   ct->regs.ack = GPIO_PORTA_EOI;
>> -   ct->regs.mask = GPIO_INTMASK;
>> +   ct->regs.ack = gpio_reg_convert(gpio, GPIO_PORTA_EOI);
>> +   ct->regs.mask = gpio_reg_convert(gpio, GPIO_INTMASK);
>> ct->type = IRQ_TYPE_LEVEL_MASK;
>> }
>>
>> @@ -520,6 +550,21 @@ static void dwapb_gpio_unregister(struct dwapb_gpio 
>> *gpio)
>> return pdata;
>>  }
>
>
>> +static const struct of_device_id dwapb_of_match[] = {
>> +   { .compatible = "snps,dw-apb-gpio", .data = (void *)0},
>> +   { .compatible = "apm,xgene-gpio-v2", .data = (void 
>> *)GPIO_REG_OFFSET_V2},
>> +   { /* Sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, dwapb_of_match);
>> +
>> +static const struct acpi_device_id dwapb_acpi_match[] = {
>> +   {"HISI0181", 0},
>> +   {"APMC0D07", 0},
>> +   {"APMC0D81", GPIO_REG_OFFSET_V2},
>> +   { }
>> +};
>> +MODULE_DEVICE_TABLE(acpi, dwapb_acpi_match);
>> +
>
> Since you are adding stuff here, I would consider at least two patches:
> 1. Move tables up here
> 2. Add and enable V2

Do we really need to have a separate patch for move the table up?

>
> or even 3:
> 1. Move tables
> 2. Extend functionality
> 3. Add ACPI ID
>
>> +   of_devid = of_match_device(dwapb_of_match, dev);
>> +   if (of_devid) {
>
> Why not to follow the below pattern, i.e.
>
> if (dev.of_node) {
>   const struct of_device_id *of_id;
> ...
> } else if (has_acpi_companion(...)) {
> ...
> }
>
> ?
>
>> +   if (of_devid->data)
>> +   gpio->flags = (uintptr_t)of_devid->data;
>
> Type inconsistency.
> (unsigned int) would work.

I tried and got this warning.
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

Thanks
Hoan

>
>> +   } else {
>> +   const struct acpi_device_id *acpi_id;
>> +
>> +   acpi_id = acpi_match_device(dwapb_acpi_match, >dev);
>> +   if (acpi_id) {
>> +   if (acpi_id->driver_data)
>> +   gpio->flags = acpi_id->driver_data;
>> +   }
>> +   }
>
>> @@ -581,19 +642,6 @@ static int dwapb_gpio_remove(struct platform_device 
>> *pdev)
>
>> -static const struct of_device_id dwapb_of_match[] = {
>> -   { .compatible = "snps,dw-apb-gpio" },
>> -   { /* Sentinel */ }
>> -};
>> -MODULE_DEVICE_TABLE(of, dwapb_of_match);
>> -
>> -static const struct acpi_device_id dwapb_acpi_match[] = {
>> -   {"HISI0181", 

Re: [PATCH v2] gpio: dwapb: Add support for next generation of X-Gene SoC

[Hoan Tran]

Hi Andy,

On Fri, Feb 17, 2017 at 2:23 AM, Andy Shevchenko
 wrote:
> On Fri, Feb 17, 2017 at 3:01 AM, Hoan Tran  wrote:
>> Next generation of X-Gene SoC's GPIO hardware register map is very
>> similar to DW GPIO. It only differs by a few register addresses.
>> This patch modifies DW GPIO driver to accommodate the difference
>> in a few register addresses.
>
>> --- a/drivers/gpio/gpio-dwapb.c
>> +++ b/drivers/gpio/gpio-dwapb.c
>> @@ -55,6 +56,13 @@
>>  #define GPIO_SWPORT_DR_SIZE(GPIO_SWPORTB_DR - GPIO_SWPORTA_DR)
>>  #define GPIO_SWPORT_DDR_SIZE   (GPIO_SWPORTB_DDR - GPIO_SWPORTA_DDR)
>>
>> +#define GPIO_REG_OFFSET_V2 1
>
> + empty line
>
>> +#define GPIO_INTMASK_V20x44
>> +#define GPIO_INTTYPE_LEVEL_V2  0x34
>> +#define GPIO_INT_POLARITY_V2   0x38
>> +#define GPIO_INTSTATUS_V2  0x3c
>> +#define GPIO_PORTA_EOI_V2  0x40
>
>> +   unsigned intflags;
>
>> +static inline u32 gpio_reg_convert(struct dwapb_gpio *gpio, unsigned int 
>> offset)
>> +{
>
>> +   if (!(gpio->flags & GPIO_REG_OFFSET_V2))
>> +   return offset;
>
> I would split this to to functions:
>
> ... u32 gpio_reg_convert(...) {
>  if (gpio->flags & ...)
>   return gpio_reg_v2_convert();
>  return offset;
> }
>
>> +   switch (offset) {
>> +   case GPIO_INTMASK:
>> +   return GPIO_INTMASK_V2;
>> +   case GPIO_INTTYPE_LEVEL:
>> +   return GPIO_INTTYPE_LEVEL_V2;
>> +   case GPIO_INT_POLARITY:
>> +   return GPIO_INT_POLARITY_V2;
>> +   case GPIO_INTSTATUS:
>> +   return GPIO_INTSTATUS_V2;
>> +   case GPIO_PORTA_EOI:
>> +   return GPIO_PORTA_EOI_V2;
>> +   }
>> +
>> +   return offset;
>> +}
>
>> -   return gc->read_reg(reg_base + offset);
>> +   return gc->read_reg(reg_base + gpio_reg_convert(gpio, offset));
>
> I'm still not convinced why we can't use
>
> gc->read_reg = ..._read_reg_v2;
>
> It will be called only in case of v2.
>
> Sorry if I missed the point.

This gc->read_reg is from gpio_chip and it is assigned by the upper layer.

>
>>  static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
>> @@ -336,8 +366,8 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
>> ct->chip.irq_disable = dwapb_irq_disable;
>> ct->chip.irq_request_resources = dwapb_irq_reqres;
>> ct->chip.irq_release_resources = dwapb_irq_relres;
>> -   ct->regs.ack = GPIO_PORTA_EOI;
>> -   ct->regs.mask = GPIO_INTMASK;
>> +   ct->regs.ack = gpio_reg_convert(gpio, GPIO_PORTA_EOI);
>> +   ct->regs.mask = gpio_reg_convert(gpio, GPIO_INTMASK);
>> ct->type = IRQ_TYPE_LEVEL_MASK;
>> }
>>
>> @@ -520,6 +550,21 @@ static void dwapb_gpio_unregister(struct dwapb_gpio 
>> *gpio)
>> return pdata;
>>  }
>
>
>> +static const struct of_device_id dwapb_of_match[] = {
>> +   { .compatible = "snps,dw-apb-gpio", .data = (void *)0},
>> +   { .compatible = "apm,xgene-gpio-v2", .data = (void 
>> *)GPIO_REG_OFFSET_V2},
>> +   { /* Sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, dwapb_of_match);
>> +
>> +static const struct acpi_device_id dwapb_acpi_match[] = {
>> +   {"HISI0181", 0},
>> +   {"APMC0D07", 0},
>> +   {"APMC0D81", GPIO_REG_OFFSET_V2},
>> +   { }
>> +};
>> +MODULE_DEVICE_TABLE(acpi, dwapb_acpi_match);
>> +
>
> Since you are adding stuff here, I would consider at least two patches:
> 1. Move tables up here
> 2. Add and enable V2

Do we really need to have a separate patch for move the table up?

>
> or even 3:
> 1. Move tables
> 2. Extend functionality
> 3. Add ACPI ID
>
>> +   of_devid = of_match_device(dwapb_of_match, dev);
>> +   if (of_devid) {
>
> Why not to follow the below pattern, i.e.
>
> if (dev.of_node) {
>   const struct of_device_id *of_id;
> ...
> } else if (has_acpi_companion(...)) {
> ...
> }
>
> ?
>
>> +   if (of_devid->data)
>> +   gpio->flags = (uintptr_t)of_devid->data;
>
> Type inconsistency.
> (unsigned int) would work.

I tried and got this warning.
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

Thanks
Hoan

>
>> +   } else {
>> +   const struct acpi_device_id *acpi_id;
>> +
>> +   acpi_id = acpi_match_device(dwapb_acpi_match, >dev);
>> +   if (acpi_id) {
>> +   if (acpi_id->driver_data)
>> +   gpio->flags = acpi_id->driver_data;
>> +   }
>> +   }
>
>> @@ -581,19 +642,6 @@ static int dwapb_gpio_remove(struct platform_device 
>> *pdev)
>
>> -static const struct of_device_id dwapb_of_match[] = {
>> -   { .compatible = "snps,dw-apb-gpio" },
>> -   { /* Sentinel */ }
>> -};
>> -MODULE_DEVICE_TABLE(of, dwapb_of_match);
>> -
>> -static const struct acpi_device_id dwapb_acpi_match[] = {
>> -   {"HISI0181", 0},
>> -   {"APMC0D07", 0},
>> -   { 

Re: [PATCH net-next v2 6/6] net: dsa: mv88e6xxx: add support for 6390 VTU

[Andrew Lunn]

On Fri, Feb 17, 2017 at 10:05:31AM -0500, Vivien Didelot wrote:
> The 6390 family of chips use only 2 of the 3 VTU Data registers to pack
> the MemberTag and PortState VLAN data. This means that they must be
> written or read before or after each VTU/STU operations.
> 
> Implement this variant to add support for VTU with such chips.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH net-next v2 6/6] net: dsa: mv88e6xxx: add support for 6390 VTU

[Andrew Lunn]

On Fri, Feb 17, 2017 at 10:05:31AM -0500, Vivien Didelot wrote:
> The 6390 family of chips use only 2 of the 3 VTU Data registers to pack
> the MemberTag and PortState VLAN data. This means that they must be
> written or read before or after each VTU/STU operations.
> 
> Implement this variant to add support for VTU with such chips.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH] PCI,pciehp: Don't handle PDC for cards with attention button

[Bjorn Helgaas]

On Thu, Feb 16, 2017 at 10:12:47PM -0800, Yinghai Lu wrote:
> On one system during power off slot, find card get power on right away.
>  # echo 0 > /sys/bus/pci/slots/1/power
>  pci_hotplug: power_write_file: power = 0
>  pciehp :16:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 
> 11f1
>  pciehp :16:00.0:pcie004: pciehp_unconfigure_device: domain:bus:dev = 
> :17:00
>  pci :17:00.0: PME# disabled
>  pci :17:00.0: freeing pci_dev info
>  pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
>  pciehp :16:00.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 write cmd 400
>  pciehp :16:00.0:pcie004: pending interrupts 0x0108 from Slot Status
>  pciehp :16:00.0:pcie004: Slot(1): Link Down
>  pciehp :16:00.0:pcie004: Slot(1): Link Down event ignored; already 
> powering off
>  pciehp :16:00.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 write cmd 300
>  pciehp :16:00.0:pcie004: pending interrupts 0x0018 from Slot Status  
> <==
>  pciehp :16:00.0:pcie004: Slot(1): Card present
>  pciehp :16:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 
> 17f1
>  pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
>  pciehp :16:00.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 write cmd 0
>  pciehp :16:00.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 write cmd 
> 200
>  pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
>  pciehp :16:00.0:pcie004: pciehp_check_link_active: lnk_status = f103
>  pciehp :16:00.0:pcie004: pending interrupts 0x0108 from Slot Status
>  pciehp :16:00.0:pcie004: Slot(1): Link Up
> ...
> 
> Somehow PDC bit get set, and during handling interrupt that is caused by
> CC, that PDC also get handled, and the card get powered on again.
> 
> In pcie_enable_notification(), we already only enable notification
> for PDC when attention button is not there.
> So we can safely add checking in pciehp_isr() to skip that PDC handling.
> 
> Signed-off-by: Yinghai Lu 
> 
> ---
>  drivers/pci/hotplug/pciehp_hpc.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6/drivers/pci/hotplug/pciehp_hpc.c
> ===
> --- linux-2.6.orig/drivers/pci/hotplug/pciehp_hpc.c
> +++ linux-2.6/drivers/pci/hotplug/pciehp_hpc.c
> @@ -618,8 +618,9 @@ static irqreturn_t pciehp_isr(int irq, v
>   present = !!(status & PCI_EXP_SLTSTA_PDS);
>   ctrl_info(ctrl, "Slot(%s): Card %spresent\n", slot_name(slot),
> present ? "" : "not ");
> - pciehp_queue_interrupt_event(slot, present ? INT_PRESENCE_ON :
> -  INT_PRESENCE_OFF);
> + if (!ATTN_BUTTN(ctrl))
> + pciehp_queue_interrupt_event(slot, present ?
> + INT_PRESENCE_ON : INT_PRESENCE_OFF);

I don't think it really makes sense to tie PDC handling with the
attention button.  It might happen to avoid the problem on your
system, but I don't see the logical connection between them.

Can you reproduce this by disabling pciehp and driving this sequence
manually with setpci?  I suspect that we are tripping over our own
feet because we read PCI_EXP_SLTSTA once, clear it (probably too
early), then queue multiple events, then process those events possibly
simultaneously.

>   }
>  
>   /* Check Power Fault Detected */

Re: [PATCH] PCI,pciehp: Don't handle PDC for cards with attention button

[Bjorn Helgaas]

On Thu, Feb 16, 2017 at 10:12:47PM -0800, Yinghai Lu wrote:
> On one system during power off slot, find card get power on right away.
>  # echo 0 > /sys/bus/pci/slots/1/power
>  pci_hotplug: power_write_file: power = 0
>  pciehp :16:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 
> 11f1
>  pciehp :16:00.0:pcie004: pciehp_unconfigure_device: domain:bus:dev = 
> :17:00
>  pci :17:00.0: PME# disabled
>  pci :17:00.0: freeing pci_dev info
>  pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
>  pciehp :16:00.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 write cmd 400
>  pciehp :16:00.0:pcie004: pending interrupts 0x0108 from Slot Status
>  pciehp :16:00.0:pcie004: Slot(1): Link Down
>  pciehp :16:00.0:pcie004: Slot(1): Link Down event ignored; already 
> powering off
>  pciehp :16:00.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 write cmd 300
>  pciehp :16:00.0:pcie004: pending interrupts 0x0018 from Slot Status  
> <==
>  pciehp :16:00.0:pcie004: Slot(1): Card present
>  pciehp :16:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 
> 17f1
>  pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
>  pciehp :16:00.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 write cmd 0
>  pciehp :16:00.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 write cmd 
> 200
>  pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
>  pciehp :16:00.0:pcie004: pciehp_check_link_active: lnk_status = f103
>  pciehp :16:00.0:pcie004: pending interrupts 0x0108 from Slot Status
>  pciehp :16:00.0:pcie004: Slot(1): Link Up
> ...
> 
> Somehow PDC bit get set, and during handling interrupt that is caused by
> CC, that PDC also get handled, and the card get powered on again.
> 
> In pcie_enable_notification(), we already only enable notification
> for PDC when attention button is not there.
> So we can safely add checking in pciehp_isr() to skip that PDC handling.
> 
> Signed-off-by: Yinghai Lu 
> 
> ---
>  drivers/pci/hotplug/pciehp_hpc.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6/drivers/pci/hotplug/pciehp_hpc.c
> ===
> --- linux-2.6.orig/drivers/pci/hotplug/pciehp_hpc.c
> +++ linux-2.6/drivers/pci/hotplug/pciehp_hpc.c
> @@ -618,8 +618,9 @@ static irqreturn_t pciehp_isr(int irq, v
>   present = !!(status & PCI_EXP_SLTSTA_PDS);
>   ctrl_info(ctrl, "Slot(%s): Card %spresent\n", slot_name(slot),
> present ? "" : "not ");
> - pciehp_queue_interrupt_event(slot, present ? INT_PRESENCE_ON :
> -  INT_PRESENCE_OFF);
> + if (!ATTN_BUTTN(ctrl))
> + pciehp_queue_interrupt_event(slot, present ?
> + INT_PRESENCE_ON : INT_PRESENCE_OFF);

I don't think it really makes sense to tie PDC handling with the
attention button.  It might happen to avoid the problem on your
system, but I don't see the logical connection between them.

Can you reproduce this by disabling pciehp and driving this sequence
manually with setpci?  I suspect that we are tripping over our own
feet because we read PCI_EXP_SLTSTA once, clear it (probably too
early), then queue multiple events, then process those events possibly
simultaneously.

>   }
>  
>   /* Check Power Fault Detected */

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Cong Wang]

On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C  wrote:
> Hi all,
>
> while poking at a different issue I found the following on my logs :
>
> [85362.132770] BUG: sleeping function called from invalid context at
> kernel/irq/manage.c:110
> [85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153, name:
> systemd-journal
> [85362.132772] no locks held by systemd-journal/1153.
> [85362.132772] irq event stamp: 60088359
> [85362.132777] hardirqs last  enabled at (60088359): []
> vprintk_emit+0x432/0x470
> [85362.132779] hardirqs last disabled at (60088358): []
> vprintk_emit+0x5c/0x470
> [85362.132782] softirqs last  enabled at (60088258): []
> __do_softirq+0x22d/0x290
> [85362.132784] softirqs last disabled at (60088233): []
> irq_exit+0x6a/0xd0
> [85362.132784] Preemption disabled at:
> [85362.132787] [] write_msg+0x4e/0xf0
> [85362.132790] CPU: 0 PID: 1153 Comm: systemd-journal Tainted: G  I
> 4.10.0-rc8-debug-1-ga1015e374d94-dirty #5
> [85362.132791] Hardware name: FUJITSU  PRIMERGY
> TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709
> 02/04/2013
> [85362.132792] Call Trace:
> [85362.132796]  dump_stack+0x86/0xc1
> [85362.132799]  ___might_sleep+0x213/0x230
> [85362.132801]  __might_sleep+0x6b/0x80
> [85362.132803]  synchronize_irq+0x33/0x90
> [85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
> [85362.132807]  ? __disable_irq_nosync+0x4e/0x60
> [85362.132808]  disable_irq+0x17/0x20


Hmm, your kernel base version is 4.10.0-rc8 but the symbols here
look like prior to my commit, because with my commit here should
be disable_hardirq() calling synchronize_hardirq().

Did you revert it or make any local changes?


> [85362.132810]  e1000_netpoll+0x3d/0x110
> [85362.132813]  netpoll_poll_dev+0xa0/0x170
> [85362.132814]  netpoll_send_skb_on_dev+0x1ab/0x2b0
> [85362.132816]  netpoll_send_udp+0x417/0x450
> [85362.132817]  write_msg+0xdb/0xf0
> [85362.132819]  console_unlock+0x2e5/0x430
> [85362.132821]  ? __down_trylock_console_sem+0x41/0x60
> [85362.132822]  vprintk_emit+0x456/0x470
> [85362.132825]  printk_emit+0x2e/0x36
> [85362.132827]  ? simple_strtoull+0x2c/0x50
> [85362.132829]  devkmsg_write+0x115/0x160
> [85362.132831]  do_iter_readv_writev+0xd8/0x100
> [85362.132833]  do_readv_writev+0xdf/0x220
> [85362.132835]  ? __might_fault+0x37/0x90
> [85362.132838]  ? entry_SYSCALL_64_fastpath+0x5/0xc2
> [85362.132839]  vfs_writev+0x3a/0x50
> [85362.132841]  do_writev+0x4c/0xd0
> [85362.132842]  SyS_writev+0xb/0x10
> [85362.132843]  entry_SYSCALL_64_fastpath+0x1f/0xc2
> [85362.132845] RIP: 0033:0x7fc6d305c46d
> [85362.132846] RSP: 002b:7ffca94161e0 EFLAGS: 0293 ORIG_RAX:
> 0014
> [85362.132847] RAX: ffda RBX: 813afad3 RCX:
> 7fc6d305c46d
> [85362.132848] RDX: 0005 RSI: 7ffca94162f0 RDI:
> 0006
> [85362.132849] RBP: c9000d4c3f88 R08:  R09:
> 0008
> [85362.132850] R10: 0069 R11: 0293 R12:
> 7ffca94162f0
> [85362.132851] R13: 55768b19c920 R14: 7ffca9416330 R15:
> 7ffca94163c0
> [85362.132853]  ? __this_cpu_preempt_check+0x13/0x20
>
>
> Seems to be introduced by :
>
> commit 311191297125156319be8f86d546ea1c569f7e95
> Author: WANG Cong 
> Date:   Sat Dec 10 14:22:42 2016 -0800
>
> e1000: use disable_hardirq() for e1000_netpoll()
>
> ...
>
> The used config can be found there:
>
> http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/config-rcx
>
>
> Regards,
>
> Gabriel C

Re: e1000_netpoll() , BUG: sleeping function called from invalid context

[Cong Wang]

On Fri, Feb 17, 2017 at 1:20 PM, Gabriel C  wrote:
> Hi all,
>
> while poking at a different issue I found the following on my logs :
>
> [85362.132770] BUG: sleeping function called from invalid context at
> kernel/irq/manage.c:110
> [85362.132771] in_atomic(): 1, irqs_disabled(): 1, pid: 1153, name:
> systemd-journal
> [85362.132772] no locks held by systemd-journal/1153.
> [85362.132772] irq event stamp: 60088359
> [85362.132777] hardirqs last  enabled at (60088359): []
> vprintk_emit+0x432/0x470
> [85362.132779] hardirqs last disabled at (60088358): []
> vprintk_emit+0x5c/0x470
> [85362.132782] softirqs last  enabled at (60088258): []
> __do_softirq+0x22d/0x290
> [85362.132784] softirqs last disabled at (60088233): []
> irq_exit+0x6a/0xd0
> [85362.132784] Preemption disabled at:
> [85362.132787] [] write_msg+0x4e/0xf0
> [85362.132790] CPU: 0 PID: 1153 Comm: systemd-journal Tainted: G  I
> 4.10.0-rc8-debug-1-ga1015e374d94-dirty #5
> [85362.132791] Hardware name: FUJITSU  PRIMERGY
> TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709
> 02/04/2013
> [85362.132792] Call Trace:
> [85362.132796]  dump_stack+0x86/0xc1
> [85362.132799]  ___might_sleep+0x213/0x230
> [85362.132801]  __might_sleep+0x6b/0x80
> [85362.132803]  synchronize_irq+0x33/0x90
> [85362.132805]  ? __irq_put_desc_unlock+0x19/0x40
> [85362.132807]  ? __disable_irq_nosync+0x4e/0x60
> [85362.132808]  disable_irq+0x17/0x20


Hmm, your kernel base version is 4.10.0-rc8 but the symbols here
look like prior to my commit, because with my commit here should
be disable_hardirq() calling synchronize_hardirq().

Did you revert it or make any local changes?


> [85362.132810]  e1000_netpoll+0x3d/0x110
> [85362.132813]  netpoll_poll_dev+0xa0/0x170
> [85362.132814]  netpoll_send_skb_on_dev+0x1ab/0x2b0
> [85362.132816]  netpoll_send_udp+0x417/0x450
> [85362.132817]  write_msg+0xdb/0xf0
> [85362.132819]  console_unlock+0x2e5/0x430
> [85362.132821]  ? __down_trylock_console_sem+0x41/0x60
> [85362.132822]  vprintk_emit+0x456/0x470
> [85362.132825]  printk_emit+0x2e/0x36
> [85362.132827]  ? simple_strtoull+0x2c/0x50
> [85362.132829]  devkmsg_write+0x115/0x160
> [85362.132831]  do_iter_readv_writev+0xd8/0x100
> [85362.132833]  do_readv_writev+0xdf/0x220
> [85362.132835]  ? __might_fault+0x37/0x90
> [85362.132838]  ? entry_SYSCALL_64_fastpath+0x5/0xc2
> [85362.132839]  vfs_writev+0x3a/0x50
> [85362.132841]  do_writev+0x4c/0xd0
> [85362.132842]  SyS_writev+0xb/0x10
> [85362.132843]  entry_SYSCALL_64_fastpath+0x1f/0xc2
> [85362.132845] RIP: 0033:0x7fc6d305c46d
> [85362.132846] RSP: 002b:7ffca94161e0 EFLAGS: 0293 ORIG_RAX:
> 0014
> [85362.132847] RAX: ffda RBX: 813afad3 RCX:
> 7fc6d305c46d
> [85362.132848] RDX: 0005 RSI: 7ffca94162f0 RDI:
> 0006
> [85362.132849] RBP: c9000d4c3f88 R08:  R09:
> 0008
> [85362.132850] R10: 0069 R11: 0293 R12:
> 7ffca94162f0
> [85362.132851] R13: 55768b19c920 R14: 7ffca9416330 R15:
> 7ffca94163c0
> [85362.132853]  ? __this_cpu_preempt_check+0x13/0x20
>
>
> Seems to be introduced by :
>
> commit 311191297125156319be8f86d546ea1c569f7e95
> Author: WANG Cong 
> Date:   Sat Dec 10 14:22:42 2016 -0800
>
> e1000: use disable_hardirq() for e1000_netpoll()
>
> ...
>
> The used config can be found there:
>
> http://ftp.frugalware.org/pub/other/people/crazy/kernel/t/config-rcx
>
>
> Regards,
>
> Gabriel C

Re: [PATCH net-next v2 2/6] net: dsa: mv88e6xxx: move ATU code in its own file

[Andrew Lunn]

> Note that we are very close from 4.10, so unless there is a major issue
> in the patchset, I'd prefer not to respin new versions. I'd gladly send
> cosmetics fixup later though. I'm waiting for this patchset to land in
> net-next to send the second one ready for cross-chip bridging in DSA.

I know we are very close to v4.10. But i don't think these changes
alone make the 6390 work properly. It appears that we still have:

   if (mv88e6xxx_6352_family(chip) || mv88e6xxx_6351_family(chip) ||
mv88e6xxx_6165_family(chip) || mv88e6xxx_6097_family(chip) ||
mv88e6xxx_6320_family(chip) || mv88e6xxx_6341_family(chip)) {
/* Port ATU control: disable limiting the number of
 * address database entries that this port is allowed
 * to use.
 */
err = mv88e6xxx_port_write(chip, port, PORT_ATU_CONTROL,
   0x);
/* Priority Override: disable DA, SA and VTU priority
 * override.
 */
err = mv88e6xxx_port_write(chip, port, PORT_PRI_OVERRIDE,
   0x);
if (err)
return err;
}

to deal with. I have been working on 6390 for a long time, and would
like to see it working properly, but i'm not happy with the
non-obvious changes here, and the structure of these patches.

Please take your time to do this right. Lots of small patches, which
are obviously correct.

   Andrew

Re: [PATCH net-next v2 2/6] net: dsa: mv88e6xxx: move ATU code in its own file

[Andrew Lunn]

> Note that we are very close from 4.10, so unless there is a major issue
> in the patchset, I'd prefer not to respin new versions. I'd gladly send
> cosmetics fixup later though. I'm waiting for this patchset to land in
> net-next to send the second one ready for cross-chip bridging in DSA.

I know we are very close to v4.10. But i don't think these changes
alone make the 6390 work properly. It appears that we still have:

   if (mv88e6xxx_6352_family(chip) || mv88e6xxx_6351_family(chip) ||
mv88e6xxx_6165_family(chip) || mv88e6xxx_6097_family(chip) ||
mv88e6xxx_6320_family(chip) || mv88e6xxx_6341_family(chip)) {
/* Port ATU control: disable limiting the number of
 * address database entries that this port is allowed
 * to use.
 */
err = mv88e6xxx_port_write(chip, port, PORT_ATU_CONTROL,
   0x);
/* Priority Override: disable DA, SA and VTU priority
 * override.
 */
err = mv88e6xxx_port_write(chip, port, PORT_PRI_OVERRIDE,
   0x);
if (err)
return err;
}

to deal with. I have been working on 6390 for a long time, and would
like to see it working properly, but i'm not happy with the
non-obvious changes here, and the structure of these patches.

Please take your time to do this right. Lots of small patches, which
are obviously correct.

   Andrew

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

[Dr. Greg Wettstein]

On Fri, Feb 17, 2017 at 02:37:12PM +0200, Jarkko Sakkinen wrote:

Hi, I hope the week is ending well for everyone.

> On Fri, Feb 17, 2017 at 03:56:26AM -0600, Dr. Greg Wettstein wrote:
> > On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote:
> > 
> > Good morning to everyone.
> > 
> > > On Thu, Feb 16, 2017 at 02:06:42PM -0600, Dr. Greg Wettstein wrote:
> > > > Just as an aside, has anyone given any thought about TPM2 resource
> > > > management in things like TXT/tboot environments?  The current tboot
> > > > code makes a rather naive assumption that it can take a handle slot to
> > > > protect its platform verification secret.  Doing resource management
> > > > correctly will require addressing extra-OS environments such as this
> > > > which may have TPM2 state requirement issues.
> > 
> > > The current implementation handles stuff created from regular
> > > /dev/tpm0 so I do not think this would be an issue. You can only
> > > access objects from a TPM space that are created within that space.
> > 
> > Unless I misunderstand the number of transient objects which can be
> > managed is a characteristic of the hardware and is a limited resource,
> > hence our discussion on the notion of a resource manager to shuttle
> > context in and out of these limited slots.
> > 
> > On a Kabylake system, running the following command:
> > 
> > getcapability -cap 6 | grep trans
> > 
> > After booting into a TXT mediated measured launch environment (MLE) yields
> > the following:
> > 
> > TPM_PT 010e value 0003 TPM_PT_HR_TRANSIENT_MIN - the minimum number 
> > of transient objects that can be held in TPM RAM
> > 
> > TPM_PT 0207 value 0002 TPM_PT_HR_TRANSIENT_AVAIL - estimate of the 
> > number of additional transient objects that could be loaded into TPM RAM
> > 
> > Booting without TXT results in the getcapability call indicating that
> > three slots are available.  Based on that and reading the tboot code,
> > we are assuming the occupied slot is the ephemeral primary key
> > generated by tboot which seals the verification secret.
> > 
> > In an MLE it is possible to create and then flush a new ephemeral
> > primary key which results in the following getcapability output:
> > 
> > TPM_PT 0207 value 0003 TPM_PT_HR_TRANSIENT_AVAIL - estimate of
> > the number of additional transient objects that could be loaded into TPM RAM
> > 
> > Which is probably going to be pretty surprising to tboot in the event
> > that it tries to re-verify the system state after a suspend event.
> > 
> > So based on that it would seem there would need to be some semblance
> > of cooperation between the resource manager and an extra-OS
> > utilization of TPM2 resources such as tboot.
> > 
> > Thoughts?

> The driver swaps in and out all the objects for one send-receive
> cycle.  So unless the driver is sending a command to a TPM the
> resource manager occupies zero slots. I do not see reason for
> forseeable future to change this pattern.
>
> I discussed about some "lazier" schemes for swapping with James an
> Ken in the early Fall but came into conclusion that it would make
> the RM really complicated. There would have to be something show
> stopper work load to even to start consider it.
>
> With the capacity of current TPMs and amount of traffic and
> workloads it is really not a worth of the trouble.
>
> I guess the way we do swapping kind of indirectly sorts out the
> issue you described, doesn't it?

I'm not sure, we've pulled down your resource manager branch so we can
figure out the exact mechanics of how it works.  Based on a cursory
read of the code it appears as if it loops through all three transient
handle slots and attempts to context save each transient object it
finds.  So if it does that for each send/receive cycle it should
theoretically inter-operate with TXT/tboot.

As noted previously, with the current kernel driver, we can see that
tboot has allocated a slot for the ephemeral key which is used to seal
the memory verification secrets.  This key gets allocated to handle
8000 as one would anticipate.  However when we attempt to issue a
context save against that handle we get an error.

Interestingly, when we attempt to flush that handle manually we
receive an error as well, but the number of available transient
handles increases by one which suggests the context flush cleared the
slot.

It seems that we should be able to manually replicate what the
resource manager is doing with the standard kernel driver or is this
an incorrect assumption?

We will have to spin up a kernel with your patches and see how it
reacts to the presence of the extra-OS handle allocation.

> /Jarkko

Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.   Specializing in information infra-structure
Fargo, ND  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

[Dr. Greg Wettstein]

On Fri, Feb 17, 2017 at 02:37:12PM +0200, Jarkko Sakkinen wrote:

Hi, I hope the week is ending well for everyone.

> On Fri, Feb 17, 2017 at 03:56:26AM -0600, Dr. Greg Wettstein wrote:
> > On Thu, Feb 16, 2017 at 10:33:04PM +0200, Jarkko Sakkinen wrote:
> > 
> > Good morning to everyone.
> > 
> > > On Thu, Feb 16, 2017 at 02:06:42PM -0600, Dr. Greg Wettstein wrote:
> > > > Just as an aside, has anyone given any thought about TPM2 resource
> > > > management in things like TXT/tboot environments?  The current tboot
> > > > code makes a rather naive assumption that it can take a handle slot to
> > > > protect its platform verification secret.  Doing resource management
> > > > correctly will require addressing extra-OS environments such as this
> > > > which may have TPM2 state requirement issues.
> > 
> > > The current implementation handles stuff created from regular
> > > /dev/tpm0 so I do not think this would be an issue. You can only
> > > access objects from a TPM space that are created within that space.
> > 
> > Unless I misunderstand the number of transient objects which can be
> > managed is a characteristic of the hardware and is a limited resource,
> > hence our discussion on the notion of a resource manager to shuttle
> > context in and out of these limited slots.
> > 
> > On a Kabylake system, running the following command:
> > 
> > getcapability -cap 6 | grep trans
> > 
> > After booting into a TXT mediated measured launch environment (MLE) yields
> > the following:
> > 
> > TPM_PT 010e value 0003 TPM_PT_HR_TRANSIENT_MIN - the minimum number 
> > of transient objects that can be held in TPM RAM
> > 
> > TPM_PT 0207 value 0002 TPM_PT_HR_TRANSIENT_AVAIL - estimate of the 
> > number of additional transient objects that could be loaded into TPM RAM
> > 
> > Booting without TXT results in the getcapability call indicating that
> > three slots are available.  Based on that and reading the tboot code,
> > we are assuming the occupied slot is the ephemeral primary key
> > generated by tboot which seals the verification secret.
> > 
> > In an MLE it is possible to create and then flush a new ephemeral
> > primary key which results in the following getcapability output:
> > 
> > TPM_PT 0207 value 0003 TPM_PT_HR_TRANSIENT_AVAIL - estimate of
> > the number of additional transient objects that could be loaded into TPM RAM
> > 
> > Which is probably going to be pretty surprising to tboot in the event
> > that it tries to re-verify the system state after a suspend event.
> > 
> > So based on that it would seem there would need to be some semblance
> > of cooperation between the resource manager and an extra-OS
> > utilization of TPM2 resources such as tboot.
> > 
> > Thoughts?

> The driver swaps in and out all the objects for one send-receive
> cycle.  So unless the driver is sending a command to a TPM the
> resource manager occupies zero slots. I do not see reason for
> forseeable future to change this pattern.
>
> I discussed about some "lazier" schemes for swapping with James an
> Ken in the early Fall but came into conclusion that it would make
> the RM really complicated. There would have to be something show
> stopper work load to even to start consider it.
>
> With the capacity of current TPMs and amount of traffic and
> workloads it is really not a worth of the trouble.
>
> I guess the way we do swapping kind of indirectly sorts out the
> issue you described, doesn't it?

I'm not sure, we've pulled down your resource manager branch so we can
figure out the exact mechanics of how it works.  Based on a cursory
read of the code it appears as if it loops through all three transient
handle slots and attempts to context save each transient object it
finds.  So if it does that for each send/receive cycle it should
theoretically inter-operate with TXT/tboot.

As noted previously, with the current kernel driver, we can see that
tboot has allocated a slot for the ephemeral key which is used to seal
the memory verification secrets.  This key gets allocated to handle
8000 as one would anticipate.  However when we attempt to issue a
context save against that handle we get an error.

Interestingly, when we attempt to flush that handle manually we
receive an error as well, but the number of available transient
handles increases by one which suggests the context flush cleared the
slot.

It seems that we should be able to manually replicate what the
resource manager is doing with the standard kernel driver or is this
an incorrect assumption?

We will have to spin up a kernel with your patches and see how it
reacts to the presence of the extra-OS handle allocation.

> /Jarkko

Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.   Specializing in information infra-structure
Fargo, ND  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com

Re: [PATCH v8 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver

[Stephen Boyd]

On 01/10, Imran Khan wrote:
> The socinfo ABI document describes the information provided
> by socinfo driver and the corresponding attributes to access
> that information.
> 
> Signed-off-by: Imran Khan 
> ---
>  Documentation/ABI/stable/sysfs-driver-qcom_socinfo | 147 
> +

Perhaps move it to testing instead of stable too?

>  1 file changed, 147 insertions(+)
>  create mode 100644 Documentation/ABI/stable/sysfs-driver-qcom_socinfo
> 
> diff --git a/Documentation/ABI/stable/sysfs-driver-qcom_socinfo 
> b/Documentation/ABI/stable/sysfs-driver-qcom_socinfo
> new file mode 100644
> index 000..f90c142
> --- /dev/null
> +++ b/Documentation/ABI/stable/sysfs-driver-qcom_socinfo
> @@ -0,0 +1,147 @@
> +What:/sys/devices/soc0/accessory_chip
> +Date:January 2017
> +Description:
> + This file shows the id of the accessory chip.

Please add a contact, linux-arm-...@vger.kernel.org perhaps?

> +
> +What:/sys/devices/soc0/adsp_image_crm
> +What:/sys/devices/soc0/adsp_image_variant
> +What:/sys/devices/soc0/adsp_image_version
> +Date:January 2017
> +Description:
> + These files respectively show the crm version, variant and
> + version of the ADSP image.
> +
> +What:/sys/devices/soc0/apps_image_crm
> +What:/sys/devices/soc0/apps_image_variant
> +What:/sys/devices/soc0/apps_image_version
> +Date:January 2017
> +Description:
> + These files respectively show the crm version, variant and
> + version of the APPS(Linux kernel, rootfs) image.
> +
> +What:/sys/devices/soc0/boot_image_crm
> +What:/sys/devices/soc0/boot_image_variant
> +What:/sys/devices/soc0/boot_image_version
> +Date:January 2017
> +Description:
> + These files respectively show the crm version, variant and
> + version of the Boot(bootloader) image.
> +
> +What:/sys/devices/soc0/build_id
> +Date:January 2017
> +Description:
> + This file shows the unique id of current build being used on
> + the system.
> +
> +What:/sys/devices/soc0/cnss_image_crm
> +What:/sys/devices/soc0/cnss_image_variant
> +What:/sys/devices/soc0/cnss_image_version
> +Date:January 2017
> +Description:
> + These files respectively show the crm version, variant and
> + version of the CNSS image.
> +
> +What:/sys/devices/soc0/family
> +Date:January 2017
> +Description:
> + This file shows the family(e.g Snapdragon) of the SoC.
> +
> +What:/sys/devices/soc0/foundry_id
> +Date:January 2017
> +Description:
> + This file shows the id of the foundry, where soc was
> + manufactured.
> +
> +What:/sys/devices/soc0/hw_platform
> +Date:January 2017
> +Description:
> + This file shows the type of hardware platform
> + (e.g MTP, QRD etc) where SoC is being used.
> +
> +What:/sys/devices/soc0/machine
> +Date:January 2017
> +Description:
> + This file shows the machine name as given in the DT.
> +
> +What:/sys/devices/soc0/mpss_image_crm
> +What:/sys/devices/soc0/mpss_image_variant
> +What:/sys/devices/soc0/mpss_image_version
> +Date:January 2017
> +Description:
> + These files respectively show the crm version, variant and
> + version of the MPSS image.
> +
> +What:/sys/devices/soc0/platform_subtype
> +Date:January 2017
> +Description:
> + This file shows the sub-type of hardware platform
> + (SKUAA, SKUF etc.) where SoC is being used.
> +
> +What:/sys/devices/soc0/platform_version
> +Date:January 2017
> +Description:
> + This file show the version of the hardware platform.
> +
> +What:/sys/devices/soc0/pmic_die_revision
> +Date:January 2017
> +Description:
> + This file shows revision of PMIC die.
> +
> +What:/sys/devices/soc0/pmic_model
> +Date:January 2017
> +Description:
> + This file shows name of PMIC model.

This doesn't seem very future proof when there's more than on
pmic, and really pmic isn't part of the SoC so it's sort of odd
to have that here in the first place. Any chance we can drop this
for now?

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

Re: g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

[Finn Thain]

On Thu, 16 Feb 2017, Ondrej Zary wrote:

> On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
> [...]
> > Are you trying to figure out which commands are going to disconnect 
> > during a transfer? This is really a function of the firmware in the 
> > target; there are no good heuristics AFAICT, so the PDMA algorithm has 
> > to be robust. mac_scsi has to cope with this too.
> >
> > Does the problem go away when you assign no IRQ? When instance->irq == 
> > NO_IRQ, the core driver will inhibit disconnect privileges.
> 
> Yes, it seems to run fine with IRQ/disconnect disabled. With IRQ 
> enabled, "dd if=/dev/sr0 of=anything" stops after a while.

When you say "stops", do you mean an infinite loop in 
generic_NCR5380_pread or does the loop complete (which would presumably 
leave the target stuck in DATA IN phase, and a scsi command timeout would 
probably follow after 30 seconds...)

> I get gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.
> 

You can use NCR5380_print() to get a decoded register dump.

When I decode the above values I get,

BASR   = 0x10 = BASR_IRQ
MODE   = 0x0e = MR_ENABLE_EOP_INTR | MR_MONITOR_BSY | MR_DMA_MODE
STATUS = 0x7c = SR_BSY | SR_REQ | SR_MSG | SR_CD | SR_IO

Since BASR_PHASE_MATCH is not set, the interrupt is almost certainly a 
phase mismatch. The new phase is SR_MSG | SR_CD | SR_IO = PHASE_MSGIN, 
which shows that the target has given up on the DATA IN phase and is 
presumably trying to send a DISCONNECT message.

> When I enable interrupts during PDMA (like the removed UNSAFE macro 
> did), the problems go away. I see an IRQ after each pread call.

You shouldn't need an interrupt, because NCR5380_dma_complete() gets 
called regardless. AFAICT, the only difference is the timing, which 
becomes less predictable. Calling spinlock_irq_restore() before the 
transfer seems to create a race condition between hostdata->dma_len store 
and load.

I think that the pread call has not yet returned when the interrupt fires 
and NCR5380_dma_complete() is called. Hence hostdata->dma_len has not yet 
been initialized. So when NCR5380_dma_complete() is called by the 
interrupt handler, SCp.this_residual will not change at all because 
hostdata->dma_len is still zero.

> (had to disable "no 53C80 gated irq after transfer" and "no end dma 
> signal" messages to reduce log spam)
> 

That may provide a quick way to detect the failed PDMA transfer, at least 
for testing purposes. There may be a more conclusive test for a partial 
transfer.

We could to implement something like macscsi_dma_residual() to take care 
of a failed PDMA transfer. That way, the failure can be taken into account 
when NCR5380_dma_complete() is called at the end of the transfer.

See patch below for example. It should confirm the theory above though it 
really needs some timeouts added (NCR5380_poll_politely()). And perhaps we 
could do something more clever than retry indefinitely, though we can 
still rely on the command timeout.

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 6f9665d..75cfaf3 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -497,15 +497,17 @@ static inline int generic_NCR5380_pread(struct 
NCR5380_hostdata *hostdata,
blocks--;
}
 
+   hostdata->pdma_residual = 0;
+
if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
-   printk("53C400r: no 53C80 gated irq after transfer");
+   hostdata->pdma_residual = hostdata->dma_len;
 
/* wait for 53C80 registers to be available */
while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG))
;
 
if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
-   printk(KERN_ERR "53C400r: no end dma signal\n");
+   hostdata->pdma_residual = hostdata->dma_len;

return 0;
 }
@@ -576,12 +578,14 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
/* FIXME - no timeout */
}
 
-   if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER)) {
-   printk(KERN_ERR "53C400w: no end dma signal\n");
-   }
+   hostdata->pdma_residual = 0;
+
+   if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
+   hostdata->pdma_residual = hostdata->dma_len;
 
while (!(NCR5380_read(TARGET_COMMAND_REG) & TCR_LAST_BYTE_SENT))
;   // TIMEOUT
+
return 0;
 }
 
@@ -607,6 +611,11 @@ static int generic_NCR5380_dma_xfer_len(struct 
NCR5380_hostdata *hostdata,
return transfersize;
 }
 
+static int generic_NCR5380_dma_residual(struct NCR5380_hostdata *hostdata)
+{
+   return hostdata->pdma_residual;
+}
+
 /*
  * Include the NCR5380 core code that we build our driver around   
  */
diff --git a/drivers/scsi/g_NCR5380.h b/drivers/scsi/g_NCR5380.h
index 81b22d9..08c91b7 100644
--- a/drivers/scsi/g_NCR5380.h
+++ 

Re: [PATCH v8 2/2] Documentation/ABI: Add ABI information for QCOM socinfo driver

[Stephen Boyd]

On 01/10, Imran Khan wrote:
> The socinfo ABI document describes the information provided
> by socinfo driver and the corresponding attributes to access
> that information.
> 
> Signed-off-by: Imran Khan 
> ---
>  Documentation/ABI/stable/sysfs-driver-qcom_socinfo | 147 
> +

Perhaps move it to testing instead of stable too?

>  1 file changed, 147 insertions(+)
>  create mode 100644 Documentation/ABI/stable/sysfs-driver-qcom_socinfo
> 
> diff --git a/Documentation/ABI/stable/sysfs-driver-qcom_socinfo 
> b/Documentation/ABI/stable/sysfs-driver-qcom_socinfo
> new file mode 100644
> index 000..f90c142
> --- /dev/null
> +++ b/Documentation/ABI/stable/sysfs-driver-qcom_socinfo
> @@ -0,0 +1,147 @@
> +What:/sys/devices/soc0/accessory_chip
> +Date:January 2017
> +Description:
> + This file shows the id of the accessory chip.

Please add a contact, linux-arm-...@vger.kernel.org perhaps?

> +
> +What:/sys/devices/soc0/adsp_image_crm
> +What:/sys/devices/soc0/adsp_image_variant
> +What:/sys/devices/soc0/adsp_image_version
> +Date:January 2017
> +Description:
> + These files respectively show the crm version, variant and
> + version of the ADSP image.
> +
> +What:/sys/devices/soc0/apps_image_crm
> +What:/sys/devices/soc0/apps_image_variant
> +What:/sys/devices/soc0/apps_image_version
> +Date:January 2017
> +Description:
> + These files respectively show the crm version, variant and
> + version of the APPS(Linux kernel, rootfs) image.
> +
> +What:/sys/devices/soc0/boot_image_crm
> +What:/sys/devices/soc0/boot_image_variant
> +What:/sys/devices/soc0/boot_image_version
> +Date:January 2017
> +Description:
> + These files respectively show the crm version, variant and
> + version of the Boot(bootloader) image.
> +
> +What:/sys/devices/soc0/build_id
> +Date:January 2017
> +Description:
> + This file shows the unique id of current build being used on
> + the system.
> +
> +What:/sys/devices/soc0/cnss_image_crm
> +What:/sys/devices/soc0/cnss_image_variant
> +What:/sys/devices/soc0/cnss_image_version
> +Date:January 2017
> +Description:
> + These files respectively show the crm version, variant and
> + version of the CNSS image.
> +
> +What:/sys/devices/soc0/family
> +Date:January 2017
> +Description:
> + This file shows the family(e.g Snapdragon) of the SoC.
> +
> +What:/sys/devices/soc0/foundry_id
> +Date:January 2017
> +Description:
> + This file shows the id of the foundry, where soc was
> + manufactured.
> +
> +What:/sys/devices/soc0/hw_platform
> +Date:January 2017
> +Description:
> + This file shows the type of hardware platform
> + (e.g MTP, QRD etc) where SoC is being used.
> +
> +What:/sys/devices/soc0/machine
> +Date:January 2017
> +Description:
> + This file shows the machine name as given in the DT.
> +
> +What:/sys/devices/soc0/mpss_image_crm
> +What:/sys/devices/soc0/mpss_image_variant
> +What:/sys/devices/soc0/mpss_image_version
> +Date:January 2017
> +Description:
> + These files respectively show the crm version, variant and
> + version of the MPSS image.
> +
> +What:/sys/devices/soc0/platform_subtype
> +Date:January 2017
> +Description:
> + This file shows the sub-type of hardware platform
> + (SKUAA, SKUF etc.) where SoC is being used.
> +
> +What:/sys/devices/soc0/platform_version
> +Date:January 2017
> +Description:
> + This file show the version of the hardware platform.
> +
> +What:/sys/devices/soc0/pmic_die_revision
> +Date:January 2017
> +Description:
> + This file shows revision of PMIC die.
> +
> +What:/sys/devices/soc0/pmic_model
> +Date:January 2017
> +Description:
> + This file shows name of PMIC model.

This doesn't seem very future proof when there's more than on
pmic, and really pmic isn't part of the SoC so it's sort of odd
to have that here in the first place. Any chance we can drop this
for now?

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

Re: g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

[Finn Thain]

On Thu, 16 Feb 2017, Ondrej Zary wrote:

> On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
> [...]
> > Are you trying to figure out which commands are going to disconnect 
> > during a transfer? This is really a function of the firmware in the 
> > target; there are no good heuristics AFAICT, so the PDMA algorithm has 
> > to be robust. mac_scsi has to cope with this too.
> >
> > Does the problem go away when you assign no IRQ? When instance->irq == 
> > NO_IRQ, the core driver will inhibit disconnect privileges.
> 
> Yes, it seems to run fine with IRQ/disconnect disabled. With IRQ 
> enabled, "dd if=/dev/sr0 of=anything" stops after a while.

When you say "stops", do you mean an infinite loop in 
generic_NCR5380_pread or does the loop complete (which would presumably 
leave the target stuck in DATA IN phase, and a scsi command timeout would 
probably follow after 30 seconds...)

> I get gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.
> 

You can use NCR5380_print() to get a decoded register dump.

When I decode the above values I get,

BASR   = 0x10 = BASR_IRQ
MODE   = 0x0e = MR_ENABLE_EOP_INTR | MR_MONITOR_BSY | MR_DMA_MODE
STATUS = 0x7c = SR_BSY | SR_REQ | SR_MSG | SR_CD | SR_IO

Since BASR_PHASE_MATCH is not set, the interrupt is almost certainly a 
phase mismatch. The new phase is SR_MSG | SR_CD | SR_IO = PHASE_MSGIN, 
which shows that the target has given up on the DATA IN phase and is 
presumably trying to send a DISCONNECT message.

> When I enable interrupts during PDMA (like the removed UNSAFE macro 
> did), the problems go away. I see an IRQ after each pread call.

You shouldn't need an interrupt, because NCR5380_dma_complete() gets 
called regardless. AFAICT, the only difference is the timing, which 
becomes less predictable. Calling spinlock_irq_restore() before the 
transfer seems to create a race condition between hostdata->dma_len store 
and load.

I think that the pread call has not yet returned when the interrupt fires 
and NCR5380_dma_complete() is called. Hence hostdata->dma_len has not yet 
been initialized. So when NCR5380_dma_complete() is called by the 
interrupt handler, SCp.this_residual will not change at all because 
hostdata->dma_len is still zero.

> (had to disable "no 53C80 gated irq after transfer" and "no end dma 
> signal" messages to reduce log spam)
> 

That may provide a quick way to detect the failed PDMA transfer, at least 
for testing purposes. There may be a more conclusive test for a partial 
transfer.

We could to implement something like macscsi_dma_residual() to take care 
of a failed PDMA transfer. That way, the failure can be taken into account 
when NCR5380_dma_complete() is called at the end of the transfer.

See patch below for example. It should confirm the theory above though it 
really needs some timeouts added (NCR5380_poll_politely()). And perhaps we 
could do something more clever than retry indefinitely, though we can 
still rely on the command timeout.

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 6f9665d..75cfaf3 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -497,15 +497,17 @@ static inline int generic_NCR5380_pread(struct 
NCR5380_hostdata *hostdata,
blocks--;
}
 
+   hostdata->pdma_residual = 0;
+
if (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_GATED_53C80_IRQ))
-   printk("53C400r: no 53C80 gated irq after transfer");
+   hostdata->pdma_residual = hostdata->dma_len;
 
/* wait for 53C80 registers to be available */
while (!(NCR5380_read(hostdata->c400_ctl_status) & CSR_53C80_REG))
;
 
if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
-   printk(KERN_ERR "53C400r: no end dma signal\n");
+   hostdata->pdma_residual = hostdata->dma_len;

return 0;
 }
@@ -576,12 +578,14 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
/* FIXME - no timeout */
}
 
-   if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER)) {
-   printk(KERN_ERR "53C400w: no end dma signal\n");
-   }
+   hostdata->pdma_residual = 0;
+
+   if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_END_DMA_TRANSFER))
+   hostdata->pdma_residual = hostdata->dma_len;
 
while (!(NCR5380_read(TARGET_COMMAND_REG) & TCR_LAST_BYTE_SENT))
;   // TIMEOUT
+
return 0;
 }
 
@@ -607,6 +611,11 @@ static int generic_NCR5380_dma_xfer_len(struct 
NCR5380_hostdata *hostdata,
return transfersize;
 }
 
+static int generic_NCR5380_dma_residual(struct NCR5380_hostdata *hostdata)
+{
+   return hostdata->pdma_residual;
+}
+
 /*
  * Include the NCR5380 core code that we build our driver around   
  */
diff --git a/drivers/scsi/g_NCR5380.h b/drivers/scsi/g_NCR5380.h
index 81b22d9..08c91b7 100644
--- a/drivers/scsi/g_NCR5380.h
+++ 

Re: net: use-after-free in tw_timer_handler

[Cong Wang]

On Fri, Feb 17, 2017 at 12:36 PM, Dmitry Vyukov  wrote:
> On Fri, Feb 17, 2017 at 7:51 PM, Cong Wang  wrote:
>>
>> This code was changed a long time ago :
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ed2e923945892a8372ab70d2f61d364b0b6d9054
>>
>> So I suspect a recent patch broke the logic.
>>
>> You might start a bisection :
>>
>> I would check if 4.7 and 4.8 trigger the issue you noticed.
>
>
> It happens with too low rate for bisecting (few times per day). I
> could add some additional checks into code, but I don't know what
> checks could be useful.

 If you can not tell if 4.7 and/or 4.8 have the problem, I am not sure
 we are able to help.
>>>
>>>
>>> There are also chances that the problem is older.
>>>
>>> Looking at the code, this part of inet_twsk_purge looks fishy:
>>>
>>> 285 if (unlikely((tw->tw_family != family) ||
>>> 286  
>>> atomic_read(_net(tw)->count))) {
>>>
>>> It uses net->count == 0 check to find the right sockets. But what if
>>> there are several nets with count == 0 in flight, can't there be
>>> several inet_twsk_purge calls running concurrently freeing each other
>>> sockets? If so it looks like inet_twsk_purge can call
>>> inet_twsk_deschedule_put twice for a socket. Namely, two calls for
>>> different nets discover the socket, check that net->count==0 and both
>>> call inet_twsk_deschedule_put. Shouldn't we just give inet_twsk_purge
>>> net that it needs to purge?
>>
>> I don't think this could happen, because cleanup_net() is called in a
>> work struct, and this work can't be scheduled twice, so there should
>> not be any parallel cleanup_net().
>>
>> Also, inet_twsk_deschedule_put() already waits for the flying timer,
>> net->count==0 at this point and all sockets in this netns are already
>> gone, so I don't know how a timer could be still fired after this.
>
>
> One thing that I noticed is that use-after-free always happens in
> tw_timer_handler, but never in timer code. This suggests that:
> 1. Whoever frees the struct waits for the timer mutex unlock.
> 2. Free happens almost at the same time as timer fires (otherwise the
> timer would probably be cancelled).
>
> That could happen if there is a race in timer code during cancellation
> or rearming. I understand that it's heavily stressed code, but who
> knows...

Good point! I think this could happen since timer is deactivated before
unlinking the tw sock, so another CPU could find it and rearm the timer
during such window?

>
> I still wonder if twsk_net(tw)->count==0 is the right condition. This
> net may not yet have been scheduled for destruction, but another task
> could pick it up and start destroying...

Good question. net_exit_list is just a snapshot of the cleanup_list, so
it is true that inet_twsk_purge() could purge more netns'es than in
net_exit_list, but I don't see any problem with this, the work later can't
find the same twsck again since it is unlinked from hashtable.
Do you see otherwise?

>
> Cong, do you have any ideas as to what debugging checks I could add to
> help track this down?

I don't have any theory for the cause of this bug. Your point above actually
makes sense for me. Maybe you can add some code in between the following
code:

if (del_timer_sync(>tw_timer))
inet_twsk_kill(tw);

to verify is the timer is rearmed or not.

Re: net: use-after-free in tw_timer_handler

[Cong Wang]

On Fri, Feb 17, 2017 at 12:36 PM, Dmitry Vyukov  wrote:
> On Fri, Feb 17, 2017 at 7:51 PM, Cong Wang  wrote:
>>
>> This code was changed a long time ago :
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ed2e923945892a8372ab70d2f61d364b0b6d9054
>>
>> So I suspect a recent patch broke the logic.
>>
>> You might start a bisection :
>>
>> I would check if 4.7 and 4.8 trigger the issue you noticed.
>
>
> It happens with too low rate for bisecting (few times per day). I
> could add some additional checks into code, but I don't know what
> checks could be useful.

 If you can not tell if 4.7 and/or 4.8 have the problem, I am not sure
 we are able to help.
>>>
>>>
>>> There are also chances that the problem is older.
>>>
>>> Looking at the code, this part of inet_twsk_purge looks fishy:
>>>
>>> 285 if (unlikely((tw->tw_family != family) ||
>>> 286  
>>> atomic_read(_net(tw)->count))) {
>>>
>>> It uses net->count == 0 check to find the right sockets. But what if
>>> there are several nets with count == 0 in flight, can't there be
>>> several inet_twsk_purge calls running concurrently freeing each other
>>> sockets? If so it looks like inet_twsk_purge can call
>>> inet_twsk_deschedule_put twice for a socket. Namely, two calls for
>>> different nets discover the socket, check that net->count==0 and both
>>> call inet_twsk_deschedule_put. Shouldn't we just give inet_twsk_purge
>>> net that it needs to purge?
>>
>> I don't think this could happen, because cleanup_net() is called in a
>> work struct, and this work can't be scheduled twice, so there should
>> not be any parallel cleanup_net().
>>
>> Also, inet_twsk_deschedule_put() already waits for the flying timer,
>> net->count==0 at this point and all sockets in this netns are already
>> gone, so I don't know how a timer could be still fired after this.
>
>
> One thing that I noticed is that use-after-free always happens in
> tw_timer_handler, but never in timer code. This suggests that:
> 1. Whoever frees the struct waits for the timer mutex unlock.
> 2. Free happens almost at the same time as timer fires (otherwise the
> timer would probably be cancelled).
>
> That could happen if there is a race in timer code during cancellation
> or rearming. I understand that it's heavily stressed code, but who
> knows...

Good point! I think this could happen since timer is deactivated before
unlinking the tw sock, so another CPU could find it and rearm the timer
during such window?

>
> I still wonder if twsk_net(tw)->count==0 is the right condition. This
> net may not yet have been scheduled for destruction, but another task
> could pick it up and start destroying...

Good question. net_exit_list is just a snapshot of the cleanup_list, so
it is true that inet_twsk_purge() could purge more netns'es than in
net_exit_list, but I don't see any problem with this, the work later can't
find the same twsck again since it is unlinked from hashtable.
Do you see otherwise?

>
> Cong, do you have any ideas as to what debugging checks I could add to
> help track this down?

I don't have any theory for the cause of this bug. Your point above actually
makes sense for me. Maybe you can add some code in between the following
code:

if (del_timer_sync(>tw_timer))
inet_twsk_kill(tw);

to verify is the timer is rearmed or not.

Re: [RFC 7/8] fpga-region: add sysfs interface

[Yves Vandervennet]

Moritz,

  whatever solution we decide to go with has to work with other OS'es. The 
last thing we want to do is to have wrappers that are Linux specific.

Yves

On Wed, 15 Feb 2017, Moritz Fischer wrote:

>>Hi Jason,
>>
>>On Wed, Feb 15, 2017 at 12:37 PM, Jason Gunthorpe
>> wrote:
>>> On Wed, Feb 15, 2017 at 12:07:15PM -0800, matthew.gerl...@linux.intel.com 
>>> wrote:
>>>
 The format of the meta data associated with a fpga bitstream is certainly a
 subject on its own.  HTTP style plain text is definately easy to understand
 and more importantly it is extendable.  On the other hand, it seems
 dangerous to be doing a lot of string parsing in the kernel.
>>>
>>> It is fairly close to binary parsing.. The process is
>>>
>>> - Find the first occurance of \n\n, must be less than XX bytes
>>> - Memcpy that from the sg list into a linear buffer
>>> - Replace all \n with \0
>>>
>>> To access a key:
>>> - Case insensitive search for START + "Key: " or \0 + "Key: "
>>> - Return as a string the part after the match
>>>
>>> This isn't the sort of string parsing that typically gets you into
>>> trouble. If we can't code the above correctly then we will screw up
>>> safe binary parsing of strings too :)
>>
>>Well I don't know ;-) With something fdt based we already have parsers there,
>>compilers are already in tree. I'll take another look at the u-boot
>>code, I think their
>>FIT (Flattened Image Tree) would be a fairly good match for what we're
>>trying to do.
>>
>>Cheers,
>>Moritz
>>--
>>To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
>>the body of a message to majord...@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: [RFC 7/8] fpga-region: add sysfs interface

[Yves Vandervennet]

Moritz,

  whatever solution we decide to go with has to work with other OS'es. The 
last thing we want to do is to have wrappers that are Linux specific.

Yves

On Wed, 15 Feb 2017, Moritz Fischer wrote:

>>Hi Jason,
>>
>>On Wed, Feb 15, 2017 at 12:37 PM, Jason Gunthorpe
>> wrote:
>>> On Wed, Feb 15, 2017 at 12:07:15PM -0800, matthew.gerl...@linux.intel.com 
>>> wrote:
>>>
 The format of the meta data associated with a fpga bitstream is certainly a
 subject on its own.  HTTP style plain text is definately easy to understand
 and more importantly it is extendable.  On the other hand, it seems
 dangerous to be doing a lot of string parsing in the kernel.
>>>
>>> It is fairly close to binary parsing.. The process is
>>>
>>> - Find the first occurance of \n\n, must be less than XX bytes
>>> - Memcpy that from the sg list into a linear buffer
>>> - Replace all \n with \0
>>>
>>> To access a key:
>>> - Case insensitive search for START + "Key: " or \0 + "Key: "
>>> - Return as a string the part after the match
>>>
>>> This isn't the sort of string parsing that typically gets you into
>>> trouble. If we can't code the above correctly then we will screw up
>>> safe binary parsing of strings too :)
>>
>>Well I don't know ;-) With something fdt based we already have parsers there,
>>compilers are already in tree. I'll take another look at the u-boot
>>code, I think their
>>FIT (Flattened Image Tree) would be a fairly good match for what we're
>>trying to do.
>>
>>Cheers,
>>Moritz
>>--
>>To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
>>the body of a message to majord...@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Userspace mmap to PCI is failing

[lex000luthor]

Hello,

I am trying to mmap a PCI device, but it fails with EINVAL.


...
fd = open("/dev/mem", O_RDWR | O_SYNC);
...
rv = mmap64(0, size, PROT_READ, MAP_SHARED, fd, pci_addr);
...


The pci_addr is the address obtained from lspci output which is a 64 bit
address.
The pci_addr has a value of 0x121ffb00, is that weird?

Kernel is 3.4.10 64 bit and User space is 32 bit.


regards,
Lex

Userspace mmap to PCI is failing

[lex000luthor]

Hello,

I am trying to mmap a PCI device, but it fails with EINVAL.


...
fd = open("/dev/mem", O_RDWR | O_SYNC);
...
rv = mmap64(0, size, PROT_READ, MAP_SHARED, fd, pci_addr);
...


The pci_addr is the address obtained from lspci output which is a 64 bit
address.
The pci_addr has a value of 0x121ffb00, is that weird?

Kernel is 3.4.10 64 bit and User space is 32 bit.


regards,
Lex

[PATCH] mtd: spi-nor: hisi: do not ignore clk_prepare_enable() failure

[Alexey Khoroshilov]

hisi_spi_nor_probe() ignores clk_prepare_enable() error code.
The patch fixes that.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/mtd/spi-nor/hisi-sfc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/spi-nor/hisi-sfc.c
index 20378b0d55e9..a286350627a6 100644
--- a/drivers/mtd/spi-nor/hisi-sfc.c
+++ b/drivers/mtd/spi-nor/hisi-sfc.c
@@ -448,8 +448,11 @@ static int hisi_spi_nor_probe(struct platform_device *pdev)
if (!host->buffer)
return -ENOMEM;
 
+   ret = clk_prepare_enable(host->clk);
+   if (ret)
+   return ret;
+
mutex_init(>lock);
-   clk_prepare_enable(host->clk);
hisi_spi_nor_init(host);
ret = hisi_spi_nor_register_all(host);
if (ret)
-- 
2.7.4

[PATCH] mtd: spi-nor: hisi: do not ignore clk_prepare_enable() failure

[Alexey Khoroshilov]

hisi_spi_nor_probe() ignores clk_prepare_enable() error code.
The patch fixes that.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/mtd/spi-nor/hisi-sfc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/spi-nor/hisi-sfc.c
index 20378b0d55e9..a286350627a6 100644
--- a/drivers/mtd/spi-nor/hisi-sfc.c
+++ b/drivers/mtd/spi-nor/hisi-sfc.c
@@ -448,8 +448,11 @@ static int hisi_spi_nor_probe(struct platform_device *pdev)
if (!host->buffer)
return -ENOMEM;
 
+   ret = clk_prepare_enable(host->clk);
+   if (ret)
+   return ret;
+
mutex_init(>lock);
-   clk_prepare_enable(host->clk);
hisi_spi_nor_init(host);
ret = hisi_spi_nor_register_all(host);
if (ret)
-- 
2.7.4

Re: [PATCH v3 0/7] Move dell-led to drivers/platform/x86

[Jacek Anaszewski]

Hi Michał,

Thanks for collecting relevant credits.
I've applied the patchset to the for-4.12 branch of linux-leds.git.

Best regards,
Jacek Anaszewski

On 02/17/2017 08:57 AM, Michał Kępień wrote:
> This patch series moves the dell-led driver from the LED subsystem to
> the x86 platform driver subsystem.
> 
> The original motivation behind this effort was to move all code using
> the dell-smbios module to the x86 platform driver subsystem.  While I
> was investigating the possibilities to do that, it quickly emerged that
> dell-led can and in fact should be moved to the x86 platform driver
> subsystem in its entirety.
> 
> dell-led consists of two major parts:
> 
>   - the part exposing a microphone mute LED interface, introduced in
> db6d8cc00773 ("dell-led: add mic mute led interface"); this
> interface is used by sound/pci/hda/dell_wmi_helper.c; while the
> original implementation used a WMI interface, it was changed to use
> dell-smbios in cf0d7ea33596 ("dell-led: use dell_smbios_find_token()
> for finding mic DMI tokens") and 0c41a08e131d ("dell-led: use
> dell_smbios_send_request() for performing SMBIOS calls"),
> 
>   - the part handling an activity LED present in Dell Latitude 2100
> netbooks, introduced in 72dcd8d08aca ("leds: Add Dell Business Class
> Netbook LED driver"); it binds to a specific WMI GUID and then
> registers a LED device which is controlled using WMI (i.e. it is
> essentially a WMI driver).
> 
> Patches 1 and 2 clean up the microphone mute LED interface to minimize
> the amount of code moved around.
> 
> Patch 3 updates a variable name in sound/pci/hda/dell_wmi_helper.c so
> that it better matches that variable's role.
> 
> Patch 4 moves the microphone mute LED interface to
> drivers/platform/x86/dell-laptop.c, effectively causing
> sound/pci/hda/dell_wmi_helper.c to depend on CONFIG_DELL_LAPTOP instead
> of CONFIG_LEDS_DELL_NETBOOKS.
> 
> Patch 5 reverts dell-led to the state it was in after its initial commit
> 72dcd8d08aca ("leds: Add Dell Business Class Netbook LED driver") by
> removing all remnants of the microphone mute LED handling code.
> 
> Patch 6 moves all that is left of dell-led (i.e. the activity LED part,
> as originally implemented), to a new module which is placed in
> drivers/platform/x86/dell-wmi-led.c.
> 
> Patch 7 fixes coding style issues in drivers/platform/x86/dell-wmi-led.c
> to make sure it gets a clean start in the x86 platform driver subsystem.
> 
> As all patches except patch 3 in this series affect the LED subsystem,
> the series is based on linux-leds/for-next.
> 
> Changes from v2:
> 
>   - Add patch 7 fixing coding style issues (feedback from Joe and Andy
> taken into account).
> 
>   - Add leading zero to constants in patch 4.
> 
>   - Move dell-led.h include one line higher in patch 4.
> 
> Changes from v1:
> 
>   - Squash patches 2-4 from v1 into a single patch (#2 in v2).
> 
>   - Add patch 3.
> 
>   - Fix subject pattern in patch 4.
> 
>   - Slight commit message adjustments, including fixing a typo
> ("COFIG_LEDS_DELL_NETBOOKS") in patch 6.
> 
>   - Remove the name of the module's source file from the header comment
> in drivers/platform/x86/dell-wmi-led.c to avoid the need to update
> it in the future.
> 
>  drivers/leds/Kconfig   |   9 --
>  drivers/leds/Makefile  |   1 -
>  drivers/platform/x86/Kconfig   |   8 ++
>  drivers/platform/x86/Makefile  |   1 +
>  drivers/platform/x86/dell-laptop.c |  28 
>  .../dell-led.c => platform/x86/dell-wmi-led.c} | 141 
> +
>  include/linux/dell-led.h   |   6 +-
>  sound/pci/hda/dell_wmi_helper.c|  30 ++---
>  8 files changed, 86 insertions(+), 138 deletions(-)
>  rename drivers/{leds/dell-led.c => platform/x86/dell-wmi-led.c} (56%)
> 

Re: [PATCH v3 0/7] Move dell-led to drivers/platform/x86

[Jacek Anaszewski]

Hi Michał,

Thanks for collecting relevant credits.
I've applied the patchset to the for-4.12 branch of linux-leds.git.

Best regards,
Jacek Anaszewski

On 02/17/2017 08:57 AM, Michał Kępień wrote:
> This patch series moves the dell-led driver from the LED subsystem to
> the x86 platform driver subsystem.
> 
> The original motivation behind this effort was to move all code using
> the dell-smbios module to the x86 platform driver subsystem.  While I
> was investigating the possibilities to do that, it quickly emerged that
> dell-led can and in fact should be moved to the x86 platform driver
> subsystem in its entirety.
> 
> dell-led consists of two major parts:
> 
>   - the part exposing a microphone mute LED interface, introduced in
> db6d8cc00773 ("dell-led: add mic mute led interface"); this
> interface is used by sound/pci/hda/dell_wmi_helper.c; while the
> original implementation used a WMI interface, it was changed to use
> dell-smbios in cf0d7ea33596 ("dell-led: use dell_smbios_find_token()
> for finding mic DMI tokens") and 0c41a08e131d ("dell-led: use
> dell_smbios_send_request() for performing SMBIOS calls"),
> 
>   - the part handling an activity LED present in Dell Latitude 2100
> netbooks, introduced in 72dcd8d08aca ("leds: Add Dell Business Class
> Netbook LED driver"); it binds to a specific WMI GUID and then
> registers a LED device which is controlled using WMI (i.e. it is
> essentially a WMI driver).
> 
> Patches 1 and 2 clean up the microphone mute LED interface to minimize
> the amount of code moved around.
> 
> Patch 3 updates a variable name in sound/pci/hda/dell_wmi_helper.c so
> that it better matches that variable's role.
> 
> Patch 4 moves the microphone mute LED interface to
> drivers/platform/x86/dell-laptop.c, effectively causing
> sound/pci/hda/dell_wmi_helper.c to depend on CONFIG_DELL_LAPTOP instead
> of CONFIG_LEDS_DELL_NETBOOKS.
> 
> Patch 5 reverts dell-led to the state it was in after its initial commit
> 72dcd8d08aca ("leds: Add Dell Business Class Netbook LED driver") by
> removing all remnants of the microphone mute LED handling code.
> 
> Patch 6 moves all that is left of dell-led (i.e. the activity LED part,
> as originally implemented), to a new module which is placed in
> drivers/platform/x86/dell-wmi-led.c.
> 
> Patch 7 fixes coding style issues in drivers/platform/x86/dell-wmi-led.c
> to make sure it gets a clean start in the x86 platform driver subsystem.
> 
> As all patches except patch 3 in this series affect the LED subsystem,
> the series is based on linux-leds/for-next.
> 
> Changes from v2:
> 
>   - Add patch 7 fixing coding style issues (feedback from Joe and Andy
> taken into account).
> 
>   - Add leading zero to constants in patch 4.
> 
>   - Move dell-led.h include one line higher in patch 4.
> 
> Changes from v1:
> 
>   - Squash patches 2-4 from v1 into a single patch (#2 in v2).
> 
>   - Add patch 3.
> 
>   - Fix subject pattern in patch 4.
> 
>   - Slight commit message adjustments, including fixing a typo
> ("COFIG_LEDS_DELL_NETBOOKS") in patch 6.
> 
>   - Remove the name of the module's source file from the header comment
> in drivers/platform/x86/dell-wmi-led.c to avoid the need to update
> it in the future.
> 
>  drivers/leds/Kconfig   |   9 --
>  drivers/leds/Makefile  |   1 -
>  drivers/platform/x86/Kconfig   |   8 ++
>  drivers/platform/x86/Makefile  |   1 +
>  drivers/platform/x86/dell-laptop.c |  28 
>  .../dell-led.c => platform/x86/dell-wmi-led.c} | 141 
> +
>  include/linux/dell-led.h   |   6 +-
>  sound/pci/hda/dell_wmi_helper.c|  30 ++---
>  8 files changed, 86 insertions(+), 138 deletions(-)
>  rename drivers/{leds/dell-led.c => platform/x86/dell-wmi-led.c} (56%)
> 

Re: [PATCH] [media] Staging: media/lirc: don't call put_ir_rx on rx twice

[Dan Carpenter]

This one is a false positive.  The original code is correct.

I was looking through my mail boxes to see the history of this and why
it hadn't been fixed earlier.  Someone tried to fix it in 2011:
https://www.spinics.net/lists/linux-driver-devel/msg17403.html
Then I complained about it again in 2014 when I was looking at a
different bug in that same function.  Now you're the third person to
think this code is suspicious.

I think part of the problem is that get_ir_rx(ir) is hidden as a
function parameter instead of on its own line.  But really even that
wouldn't totally fix the issue.

regards,
dan carpenter

Re: [PATCH] [media] Staging: media/lirc: don't call put_ir_rx on rx twice

[Dan Carpenter]

This one is a false positive.  The original code is correct.

I was looking through my mail boxes to see the history of this and why
it hadn't been fixed earlier.  Someone tried to fix it in 2011:
https://www.spinics.net/lists/linux-driver-devel/msg17403.html
Then I complained about it again in 2014 when I was looking at a
different bug in that same function.  Now you're the third person to
think this code is suspicious.

I think part of the problem is that get_ir_rx(ir) is hidden as a
function parameter instead of on its own line.  But really even that
wouldn't totally fix the issue.

regards,
dan carpenter

[PATCHv2 0/6] x86/platform/uv/BAU: UV4 message completion and initialization updates

[Andrew Banman]

The following patch series adds the necessary functionality to make the BAU
on UV4 operational. The purpose of these patches is to implement the correct
message completion logic on UV4. Also included is a bug fix to add a field
to the INTD payload. This is needed to verify the source of each message.

As of this patch set, the BAU operates without errors and performance tests
show TLB shootdowns take up to 42% less time with the BAU enabled.

The patches are summarized as follows:

(1) Populate a message payload field to verify messages at the destination.
Without this verification, the destination agent triggers a HUB error,
resulting in an NMI.

[PATCH 1/6] x86/platform/uv/BAU: Add uv_bau_version enumerated
[PATCH v2 2/6] x86/platform/uv/BAU: Add payload descriptor qualifier

This bug fix is included at the start of the series to avoid conflicts
in a code path shared by the rest of the series.

(2) Make the wait_completion routine part of the bau_operations interface,
and add a uv4_wait_completion routine to employ new completion logic.

The message completion logic for previous generations relies on software-
defined timeouts that are not implemented on UV4. Without these patches,
the BAU driver on UV4 erroneously identifies a UV2-WAR timeout during
normal operation.

[PATCH 3/6] x86/platform/uv/BAU: Cleanup bau_operations declaration
[PATCH 4/6] x86/platform/uv/BAU: Add status mmr location fields to
[PATCH v2 5/6] x86/platform/uv/BAU: Add wait_completion to
[PATCH v2 6/6] x86/platform/uv/BAU: Implement uv4_wait_completion with


Please see the commit messages for details on the motivation and content of
each patch.

Thank you,

Andrew Banman
HPE, Linux Kernel Engineer

[PATCHv2 0/6] x86/platform/uv/BAU: UV4 message completion and initialization updates

[Andrew Banman]

The following patch series adds the necessary functionality to make the BAU
on UV4 operational. The purpose of these patches is to implement the correct
message completion logic on UV4. Also included is a bug fix to add a field
to the INTD payload. This is needed to verify the source of each message.

As of this patch set, the BAU operates without errors and performance tests
show TLB shootdowns take up to 42% less time with the BAU enabled.

The patches are summarized as follows:

(1) Populate a message payload field to verify messages at the destination.
Without this verification, the destination agent triggers a HUB error,
resulting in an NMI.

[PATCH 1/6] x86/platform/uv/BAU: Add uv_bau_version enumerated
[PATCH v2 2/6] x86/platform/uv/BAU: Add payload descriptor qualifier

This bug fix is included at the start of the series to avoid conflicts
in a code path shared by the rest of the series.

(2) Make the wait_completion routine part of the bau_operations interface,
and add a uv4_wait_completion routine to employ new completion logic.

The message completion logic for previous generations relies on software-
defined timeouts that are not implemented on UV4. Without these patches,
the BAU driver on UV4 erroneously identifies a UV2-WAR timeout during
normal operation.

[PATCH 3/6] x86/platform/uv/BAU: Cleanup bau_operations declaration
[PATCH 4/6] x86/platform/uv/BAU: Add status mmr location fields to
[PATCH v2 5/6] x86/platform/uv/BAU: Add wait_completion to
[PATCH v2 6/6] x86/platform/uv/BAU: Implement uv4_wait_completion with


Please see the commit messages for details on the motivation and content of
each patch.

Thank you,

Andrew Banman
HPE, Linux Kernel Engineer

[PATCH v2 2/6] x86/platform/uv/BAU: Add payload descriptor qualifier

[Andrew Banman]

On UV4, the destination agent verifies each message by checking the
descriptor qualifier field of the message payload. Messages without this
field set to 0x534749 will cause a hub error to assert.

Split bau_message_payload into uv1_2_3 and uv4 versions to account for the
different payload formats. Enforce the size of each field by using the
appropriate integer type. Replace extraneous comments with a kernel-doc
comment for each struct.

Populate the descriptor qualifier field before the INTD broadcast is
initiated by the sender. This ensures each message sent by with the BAU
driver is verified.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 
---
 arch/x86/include/asm/uv/uv_bau.h | 40 
 arch/x86/platform/uv/tlb_uv.c| 27 +++
 2 files changed, 47 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index 768093f..1ed0574 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -185,6 +185,8 @@
 #define MSG_REGULAR1
 #define MSG_RETRY  2
 
+#define BAU_DESC_QUALIFIER 0x534749
+
 enum uv_bau_version {
UV_BAU_V1 = 1,
UV_BAU_V2,
@@ -229,20 +231,31 @@ struct bau_local_cpumask {
  *   the s/w ack bit vector  ]
  */
 
-/*
- * The payload is software-defined for INTD transactions
+/**
+ * struct uv1_2_3_bau_msg_payload - defines payload for INTD transactions
+ * @address: signifies a page or all TLB's of the cpu
+ * @acknowledge_count: CPUs on the destination Hub that received the interrupt
  */
-struct bau_msg_payload {
-   unsigned long   address;/* signifies a page or all
-  TLB's of the cpu */
-   /* 64 bits */
-   unsigned short  sending_cpu;/* filled in by sender */
-   /* 16 bits */
-   unsigned short  acknowledge_count;  /* filled in by destination */
-   /* 16 bits */
-   unsigned intreserved1:32;   /* not usable */
+struct uv1_2_3_bau_msg_payload {
+   u64 address;
+   u16 sending_cpu;
+   u16 acknowledge_count;
+   u32 reserved1;
 };
 
+/**
+ * struct uv4_bau_msg_payload - defines payload for INTD transactions
+ * @address: signifies a page or all TLB's of the cpu
+ * @acknowledge_count: CPUs on the destination Hub that received the interrupt
+ * @qualifier: set by source to verify origin of INTD broadcast
+ */
+struct uv4_bau_msg_payload {
+   u64 address;
+   u16 sending_cpu;
+   u16 acknowledge_count;
+   u32 reserved1:8;
+   u32 qualifier:24;
+};
 
 /*
  * UV1 Message header:  16 bytes (128 bits) (bytes 0x30-0x3f of descriptor)
@@ -418,7 +431,10 @@ struct bau_desc {
struct uv2_3_bau_msg_header uv2_3_hdr;
} header;
 
-   struct bau_msg_payload  payload;
+   union bau_payload_header {
+   struct uv1_2_3_bau_msg_payload  uv1_2_3;
+   struct uv4_bau_msg_payload  uv4;
+   } payload;
 };
 /* UV1:
  *   -payload---header--
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index f4f5aa6..70721c4 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -1114,15 +1114,12 @@ const struct cpumask *uv_flush_tlb_others(const struct 
cpumask *cpumask,
unsigned long end,
unsigned int cpu)
 {
-   int locals = 0;
-   int remotes = 0;
-   int hubs = 0;
+   int locals = 0, remotes = 0, hubs = 0;
struct bau_desc *bau_desc;
struct cpumask *flush_mask;
struct ptc_stats *stat;
struct bau_control *bcp;
-   unsigned long descriptor_status;
-   unsigned long status;
+   unsigned long descriptor_status, status, address;
 
bcp = _cpu(bau_control, cpu);
 
@@ -1171,10 +1168,24 @@ const struct cpumask *uv_flush_tlb_others(const struct 
cpumask *cpumask,
record_send_statistics(stat, locals, hubs, remotes, bau_desc);
 
if (!end || (end - start) <= PAGE_SIZE)
-   bau_desc->payload.address = start;
+   address = start;
else
-   bau_desc->payload.address = TLB_FLUSH_ALL;
-   bau_desc->payload.sending_cpu = cpu;
+   address = TLB_FLUSH_ALL;
+
+   switch (bcp->uvhub_version) {
+   case UV_BAU_V1:
+   case UV_BAU_V2:
+   case UV_BAU_V3:
+   bau_desc->payload.uv1_2_3.address = address;
+   bau_desc->payload.uv1_2_3.sending_cpu = cpu;
+   break;
+   case UV_BAU_V4:
+   bau_desc->payload.uv4.address = address;
+   bau_desc->payload.uv4.sending_cpu = cpu;
+   bau_desc->payload.uv4.qualifier = BAU_DESC_QUALIFIER;
+   break;
+   }
+
  

[PATCH 4/6] x86/platform/uv/BAU: Add status mmr location fields to bau_control

[Andrew Banman]

The location of the ERROR and BUSY status bits depends on the descriptor
index, i.e. the CPU, of the message. Since this index does not change,
there is no need to calculate the MMR and index location during message
processing. The less work we do in the hot path the better.

Add status_mmr and status_index fields to bau_control and compute their
values during initialization. Update uv*_wait_completion to use these
fields rather than receiving the information as parameters.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 

---
 arch/x86/include/asm/uv/uv_bau.h | 10 +++--
 arch/x86/platform/uv/tlb_uv.c| 48 +++-
 2 files changed, 31 insertions(+), 27 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index 59ae8a7..a02019a 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -600,8 +600,12 @@ struct uvhub_desc {
struct socket_desc  socket[2];
 };
 
-/*
- * one per-cpu; to locate the software tables
+/**
+ * struct bau_control
+ * @status_mmr: location of status mrr, determined by uvhub_cpu
+ * @status_index: index of ERR|BUSY bits in status mrr, determined by uvhub_cpu
+ *
+ * Per-cpu control struct containing CPU topology information and BAU 
tuneables.
  */
 struct bau_control {
struct bau_desc *descriptor_base;
@@ -619,6 +623,8 @@ struct bau_control {
int timeout_tries;
int ipi_attempts;
int conseccompletes;
+   u64 status_mmr;
+   int status_index;
boolnobau;
short   baudisabled;
short   cpu;
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index e6994fd..b8d3830 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -527,11 +527,12 @@ static unsigned long uv1_read_status(unsigned long 
mmr_offset, int right_shift)
  * return COMPLETE, RETRY(PLUGGED or TIMEOUT) or GIVEUP
  */
 static int uv1_wait_completion(struct bau_desc *bau_desc,
-   unsigned long mmr_offset, int right_shift,
struct bau_control *bcp, long try)
 {
unsigned long descriptor_status;
cycles_t ttm;
+   u64 mmr_offset = bcp->status_mmr;
+   int right_shift = bcp->status_index;
struct ptc_stats *stat = bcp->statp;
 
descriptor_status = uv1_read_status(mmr_offset, right_shift);
@@ -619,11 +620,12 @@ int handle_uv2_busy(struct bau_control *bcp)
 }
 
 static int uv2_3_wait_completion(struct bau_desc *bau_desc,
-   unsigned long mmr_offset, int right_shift,
struct bau_control *bcp, long try)
 {
unsigned long descriptor_stat;
cycles_t ttm;
+   u64 mmr_offset = bcp->status_mmr;
+   int right_shift = bcp->status_index;
int desc = bcp->uvhub_cpu;
long busy_reps = 0;
struct ptc_stats *stat = bcp->statp;
@@ -684,29 +686,12 @@ static int uv2_3_wait_completion(struct bau_desc 
*bau_desc,
return FLUSH_COMPLETE;
 }
 
-/*
- * There are 2 status registers; each and array[32] of 2 bits. Set up for
- * which register to read and position in that register based on cpu in
- * current hub.
- */
 static int wait_completion(struct bau_desc *bau_desc, struct bau_control *bcp, 
long try)
 {
-   int right_shift;
-   unsigned long mmr_offset;
-   int desc = bcp->uvhub_cpu;
-
-   if (desc < UV_CPUS_PER_AS) {
-   mmr_offset = UVH_LB_BAU_SB_ACTIVATION_STATUS_0;
-   right_shift = desc * UV_ACT_STATUS_SIZE;
-   } else {
-   mmr_offset = UVH_LB_BAU_SB_ACTIVATION_STATUS_1;
-   right_shift = ((desc - UV_CPUS_PER_AS) * UV_ACT_STATUS_SIZE);
-   }
-
-   if (bcp->uvhub_version == UV_BAU_V1)
-   return uv1_wait_completion(bau_desc, mmr_offset, right_shift, 
bcp, try);
+   if (bcp->uvhub_version == 1)
+   return uv1_wait_completion(bau_desc, bcp, try);
else
-   return uv2_3_wait_completion(bau_desc, mmr_offset, right_shift, 
bcp, try);
+   return uv2_3_wait_completion(bau_desc, bcp, try);
 }
 
 /*
@@ -2024,8 +2009,7 @@ static int scan_sock(struct socket_desc *sdp, struct 
uvhub_desc *bdp,
struct bau_control **smasterp,
struct bau_control **hmasterp)
 {
-   int i;
-   int cpu;
+   int i, cpu, uvhub_cpu;
struct bau_control *bcp;
 
for (i = 0; i < sdp->num_cpus; i++) {
@@ -2054,7 +2038,21 @@ static int scan_sock(struct socket_desc *sdp, struct 
uvhub_desc *bdp,
return 1;
}
bcp->uvhub_master = *hmasterp;
-   bcp->uvhub_cpu = 

[PATCH v2 2/6] x86/platform/uv/BAU: Add payload descriptor qualifier

[Andrew Banman]

On UV4, the destination agent verifies each message by checking the
descriptor qualifier field of the message payload. Messages without this
field set to 0x534749 will cause a hub error to assert.

Split bau_message_payload into uv1_2_3 and uv4 versions to account for the
different payload formats. Enforce the size of each field by using the
appropriate integer type. Replace extraneous comments with a kernel-doc
comment for each struct.

Populate the descriptor qualifier field before the INTD broadcast is
initiated by the sender. This ensures each message sent by with the BAU
driver is verified.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 
---
 arch/x86/include/asm/uv/uv_bau.h | 40 
 arch/x86/platform/uv/tlb_uv.c| 27 +++
 2 files changed, 47 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index 768093f..1ed0574 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -185,6 +185,8 @@
 #define MSG_REGULAR1
 #define MSG_RETRY  2
 
+#define BAU_DESC_QUALIFIER 0x534749
+
 enum uv_bau_version {
UV_BAU_V1 = 1,
UV_BAU_V2,
@@ -229,20 +231,31 @@ struct bau_local_cpumask {
  *   the s/w ack bit vector  ]
  */
 
-/*
- * The payload is software-defined for INTD transactions
+/**
+ * struct uv1_2_3_bau_msg_payload - defines payload for INTD transactions
+ * @address: signifies a page or all TLB's of the cpu
+ * @acknowledge_count: CPUs on the destination Hub that received the interrupt
  */
-struct bau_msg_payload {
-   unsigned long   address;/* signifies a page or all
-  TLB's of the cpu */
-   /* 64 bits */
-   unsigned short  sending_cpu;/* filled in by sender */
-   /* 16 bits */
-   unsigned short  acknowledge_count;  /* filled in by destination */
-   /* 16 bits */
-   unsigned intreserved1:32;   /* not usable */
+struct uv1_2_3_bau_msg_payload {
+   u64 address;
+   u16 sending_cpu;
+   u16 acknowledge_count;
+   u32 reserved1;
 };
 
+/**
+ * struct uv4_bau_msg_payload - defines payload for INTD transactions
+ * @address: signifies a page or all TLB's of the cpu
+ * @acknowledge_count: CPUs on the destination Hub that received the interrupt
+ * @qualifier: set by source to verify origin of INTD broadcast
+ */
+struct uv4_bau_msg_payload {
+   u64 address;
+   u16 sending_cpu;
+   u16 acknowledge_count;
+   u32 reserved1:8;
+   u32 qualifier:24;
+};
 
 /*
  * UV1 Message header:  16 bytes (128 bits) (bytes 0x30-0x3f of descriptor)
@@ -418,7 +431,10 @@ struct bau_desc {
struct uv2_3_bau_msg_header uv2_3_hdr;
} header;
 
-   struct bau_msg_payload  payload;
+   union bau_payload_header {
+   struct uv1_2_3_bau_msg_payload  uv1_2_3;
+   struct uv4_bau_msg_payload  uv4;
+   } payload;
 };
 /* UV1:
  *   -payload---header--
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index f4f5aa6..70721c4 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -1114,15 +1114,12 @@ const struct cpumask *uv_flush_tlb_others(const struct 
cpumask *cpumask,
unsigned long end,
unsigned int cpu)
 {
-   int locals = 0;
-   int remotes = 0;
-   int hubs = 0;
+   int locals = 0, remotes = 0, hubs = 0;
struct bau_desc *bau_desc;
struct cpumask *flush_mask;
struct ptc_stats *stat;
struct bau_control *bcp;
-   unsigned long descriptor_status;
-   unsigned long status;
+   unsigned long descriptor_status, status, address;
 
bcp = _cpu(bau_control, cpu);
 
@@ -1171,10 +1168,24 @@ const struct cpumask *uv_flush_tlb_others(const struct 
cpumask *cpumask,
record_send_statistics(stat, locals, hubs, remotes, bau_desc);
 
if (!end || (end - start) <= PAGE_SIZE)
-   bau_desc->payload.address = start;
+   address = start;
else
-   bau_desc->payload.address = TLB_FLUSH_ALL;
-   bau_desc->payload.sending_cpu = cpu;
+   address = TLB_FLUSH_ALL;
+
+   switch (bcp->uvhub_version) {
+   case UV_BAU_V1:
+   case UV_BAU_V2:
+   case UV_BAU_V3:
+   bau_desc->payload.uv1_2_3.address = address;
+   bau_desc->payload.uv1_2_3.sending_cpu = cpu;
+   break;
+   case UV_BAU_V4:
+   bau_desc->payload.uv4.address = address;
+   bau_desc->payload.uv4.sending_cpu = cpu;
+   bau_desc->payload.uv4.qualifier = BAU_DESC_QUALIFIER;
+   break;
+   }
+
/*
 * 

[PATCH 4/6] x86/platform/uv/BAU: Add status mmr location fields to bau_control

[Andrew Banman]

The location of the ERROR and BUSY status bits depends on the descriptor
index, i.e. the CPU, of the message. Since this index does not change,
there is no need to calculate the MMR and index location during message
processing. The less work we do in the hot path the better.

Add status_mmr and status_index fields to bau_control and compute their
values during initialization. Update uv*_wait_completion to use these
fields rather than receiving the information as parameters.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 

---
 arch/x86/include/asm/uv/uv_bau.h | 10 +++--
 arch/x86/platform/uv/tlb_uv.c| 48 +++-
 2 files changed, 31 insertions(+), 27 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index 59ae8a7..a02019a 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -600,8 +600,12 @@ struct uvhub_desc {
struct socket_desc  socket[2];
 };
 
-/*
- * one per-cpu; to locate the software tables
+/**
+ * struct bau_control
+ * @status_mmr: location of status mrr, determined by uvhub_cpu
+ * @status_index: index of ERR|BUSY bits in status mrr, determined by uvhub_cpu
+ *
+ * Per-cpu control struct containing CPU topology information and BAU 
tuneables.
  */
 struct bau_control {
struct bau_desc *descriptor_base;
@@ -619,6 +623,8 @@ struct bau_control {
int timeout_tries;
int ipi_attempts;
int conseccompletes;
+   u64 status_mmr;
+   int status_index;
boolnobau;
short   baudisabled;
short   cpu;
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index e6994fd..b8d3830 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -527,11 +527,12 @@ static unsigned long uv1_read_status(unsigned long 
mmr_offset, int right_shift)
  * return COMPLETE, RETRY(PLUGGED or TIMEOUT) or GIVEUP
  */
 static int uv1_wait_completion(struct bau_desc *bau_desc,
-   unsigned long mmr_offset, int right_shift,
struct bau_control *bcp, long try)
 {
unsigned long descriptor_status;
cycles_t ttm;
+   u64 mmr_offset = bcp->status_mmr;
+   int right_shift = bcp->status_index;
struct ptc_stats *stat = bcp->statp;
 
descriptor_status = uv1_read_status(mmr_offset, right_shift);
@@ -619,11 +620,12 @@ int handle_uv2_busy(struct bau_control *bcp)
 }
 
 static int uv2_3_wait_completion(struct bau_desc *bau_desc,
-   unsigned long mmr_offset, int right_shift,
struct bau_control *bcp, long try)
 {
unsigned long descriptor_stat;
cycles_t ttm;
+   u64 mmr_offset = bcp->status_mmr;
+   int right_shift = bcp->status_index;
int desc = bcp->uvhub_cpu;
long busy_reps = 0;
struct ptc_stats *stat = bcp->statp;
@@ -684,29 +686,12 @@ static int uv2_3_wait_completion(struct bau_desc 
*bau_desc,
return FLUSH_COMPLETE;
 }
 
-/*
- * There are 2 status registers; each and array[32] of 2 bits. Set up for
- * which register to read and position in that register based on cpu in
- * current hub.
- */
 static int wait_completion(struct bau_desc *bau_desc, struct bau_control *bcp, 
long try)
 {
-   int right_shift;
-   unsigned long mmr_offset;
-   int desc = bcp->uvhub_cpu;
-
-   if (desc < UV_CPUS_PER_AS) {
-   mmr_offset = UVH_LB_BAU_SB_ACTIVATION_STATUS_0;
-   right_shift = desc * UV_ACT_STATUS_SIZE;
-   } else {
-   mmr_offset = UVH_LB_BAU_SB_ACTIVATION_STATUS_1;
-   right_shift = ((desc - UV_CPUS_PER_AS) * UV_ACT_STATUS_SIZE);
-   }
-
-   if (bcp->uvhub_version == UV_BAU_V1)
-   return uv1_wait_completion(bau_desc, mmr_offset, right_shift, 
bcp, try);
+   if (bcp->uvhub_version == 1)
+   return uv1_wait_completion(bau_desc, bcp, try);
else
-   return uv2_3_wait_completion(bau_desc, mmr_offset, right_shift, 
bcp, try);
+   return uv2_3_wait_completion(bau_desc, bcp, try);
 }
 
 /*
@@ -2024,8 +2009,7 @@ static int scan_sock(struct socket_desc *sdp, struct 
uvhub_desc *bdp,
struct bau_control **smasterp,
struct bau_control **hmasterp)
 {
-   int i;
-   int cpu;
+   int i, cpu, uvhub_cpu;
struct bau_control *bcp;
 
for (i = 0; i < sdp->num_cpus; i++) {
@@ -2054,7 +2038,21 @@ static int scan_sock(struct socket_desc *sdp, struct 
uvhub_desc *bdp,
return 1;
}
bcp->uvhub_master = *hmasterp;
-   bcp->uvhub_cpu = uv_cpu_blade_processor_id(cpu);
+   uvhub_cpu = 

[PATCH v2 6/6] x86/platform/uv/BAU: Implement uv4_wait_completion with read_status

[Andrew Banman]

UV4 does not employ a software-timeout as in previous generations so a new
wait_completion routine without this logic is required. Certain completion
statuses require the AUX status bit in addition to ERROR and BUSY.

Add the read_status routine to construct the full completion status. Use
read_status in the uv4_wait_completion routine to handle all possible
completion statuses.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 
---
 arch/x86/platform/uv/tlb_uv.c | 58 ++-
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 2a826dd..42e65fe 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -687,6 +687,62 @@ static int uv2_3_wait_completion(struct bau_desc *bau_desc,
 }
 
 /*
+ * Returns the status of current BAU message for cpu desc as a bit field
+ * [Error][Busy][Aux]
+ */
+static u64 read_status(u64 status_mmr, int index, int desc)
+{
+   u64 stat;
+
+   stat = ((read_lmmr(status_mmr) >> index) & UV_ACT_STATUS_MASK) << 1;
+   stat |= (read_lmmr(UVH_LB_BAU_SB_ACTIVATION_STATUS_2) >> desc) & 0x1;
+
+   return stat;
+}
+
+static int uv4_wait_completion(struct bau_desc *bau_desc,
+   struct bau_control *bcp, long try)
+{
+   struct ptc_stats *stat = bcp->statp;
+   u64 descriptor_stat;
+   u64 mmr = bcp->status_mmr;
+   int index = bcp->status_index;
+   int desc = bcp->uvhub_cpu;
+
+   descriptor_stat = read_status(mmr, index, desc);
+
+   /* spin on the status MMR, waiting for it to go idle */
+   while (descriptor_stat != UV2H_DESC_IDLE) {
+   switch (descriptor_stat) {
+   case UV2H_DESC_SOURCE_TIMEOUT:
+   stat->s_stimeout++;
+   return FLUSH_GIVEUP;
+
+   case UV2H_DESC_DEST_TIMEOUT:
+   stat->s_dtimeout++;
+   bcp->conseccompletes = 0;
+   return FLUSH_RETRY_TIMEOUT;
+
+   case UV2H_DESC_DEST_STRONG_NACK:
+   stat->s_plugged++;
+   bcp->conseccompletes = 0;
+   return FLUSH_RETRY_PLUGGED;
+
+   case UV2H_DESC_DEST_PUT_ERR:
+   bcp->conseccompletes = 0;
+   return FLUSH_GIVEUP;
+
+   default:
+   /* descriptor_stat is still BUSY */
+   cpu_relax();
+   }
+   descriptor_stat = read_status(mmr, index, desc);
+   }
+   bcp->conseccompletes++;
+   return FLUSH_COMPLETE;
+}
+
+/*
  * Our retries are blocked by all destination sw ack resources being
  * in use, and a timeout is pending. In that case hardware immediately
  * returns the ERROR that looks like a destination timeout.
@@ -2157,7 +2213,7 @@ static int __init init_per_cpu(int nuvhubs, int 
base_part_pnode)
.write_g_sw_ack  = write_gmmr_proc_sw_ack,
.write_payload_first = write_mmr_proc_payload_first,
.write_payload_last  = write_mmr_proc_payload_last,
-   .wait_completion = uv2_3_wait_completion,
+   .wait_completion = uv4_wait_completion,
 };
 
 /*
-- 
1.8.2.1

[PATCH v2 6/6] x86/platform/uv/BAU: Implement uv4_wait_completion with read_status

[Andrew Banman]

UV4 does not employ a software-timeout as in previous generations so a new
wait_completion routine without this logic is required. Certain completion
statuses require the AUX status bit in addition to ERROR and BUSY.

Add the read_status routine to construct the full completion status. Use
read_status in the uv4_wait_completion routine to handle all possible
completion statuses.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 
---
 arch/x86/platform/uv/tlb_uv.c | 58 ++-
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 2a826dd..42e65fe 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -687,6 +687,62 @@ static int uv2_3_wait_completion(struct bau_desc *bau_desc,
 }
 
 /*
+ * Returns the status of current BAU message for cpu desc as a bit field
+ * [Error][Busy][Aux]
+ */
+static u64 read_status(u64 status_mmr, int index, int desc)
+{
+   u64 stat;
+
+   stat = ((read_lmmr(status_mmr) >> index) & UV_ACT_STATUS_MASK) << 1;
+   stat |= (read_lmmr(UVH_LB_BAU_SB_ACTIVATION_STATUS_2) >> desc) & 0x1;
+
+   return stat;
+}
+
+static int uv4_wait_completion(struct bau_desc *bau_desc,
+   struct bau_control *bcp, long try)
+{
+   struct ptc_stats *stat = bcp->statp;
+   u64 descriptor_stat;
+   u64 mmr = bcp->status_mmr;
+   int index = bcp->status_index;
+   int desc = bcp->uvhub_cpu;
+
+   descriptor_stat = read_status(mmr, index, desc);
+
+   /* spin on the status MMR, waiting for it to go idle */
+   while (descriptor_stat != UV2H_DESC_IDLE) {
+   switch (descriptor_stat) {
+   case UV2H_DESC_SOURCE_TIMEOUT:
+   stat->s_stimeout++;
+   return FLUSH_GIVEUP;
+
+   case UV2H_DESC_DEST_TIMEOUT:
+   stat->s_dtimeout++;
+   bcp->conseccompletes = 0;
+   return FLUSH_RETRY_TIMEOUT;
+
+   case UV2H_DESC_DEST_STRONG_NACK:
+   stat->s_plugged++;
+   bcp->conseccompletes = 0;
+   return FLUSH_RETRY_PLUGGED;
+
+   case UV2H_DESC_DEST_PUT_ERR:
+   bcp->conseccompletes = 0;
+   return FLUSH_GIVEUP;
+
+   default:
+   /* descriptor_stat is still BUSY */
+   cpu_relax();
+   }
+   descriptor_stat = read_status(mmr, index, desc);
+   }
+   bcp->conseccompletes++;
+   return FLUSH_COMPLETE;
+}
+
+/*
  * Our retries are blocked by all destination sw ack resources being
  * in use, and a timeout is pending. In that case hardware immediately
  * returns the ERROR that looks like a destination timeout.
@@ -2157,7 +2213,7 @@ static int __init init_per_cpu(int nuvhubs, int 
base_part_pnode)
.write_g_sw_ack  = write_gmmr_proc_sw_ack,
.write_payload_first = write_mmr_proc_payload_first,
.write_payload_last  = write_mmr_proc_payload_last,
-   .wait_completion = uv2_3_wait_completion,
+   .wait_completion = uv4_wait_completion,
 };
 
 /*
-- 
1.8.2.1

[PATCH 3/6] x86/platform/uv/BAU: Cleanup bau_operations declaration and instances

[Andrew Banman]

Move the bau_operations declaration after bau struct declarations so the
bau structs can be referenced when adding new functions to
bau_operations. That way we avoid forward declarations of the bau
structs.

Likewise, move uv*_bau_ops structs down to avoid forward declarations of
new functions defined in the same file. Declare these structs __initconst
since they are only used during initialization. Similarly, declare the
bau_operations ops instance __ro_after_init as it is read-only after
initialization.

This is a preparatory patch for adding wait_completion to bau_operations.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 
---
 arch/x86/include/asm/uv/uv_bau.h | 22 ++--
 arch/x86/platform/uv/tlb_uv.c| 43 
 2 files changed, 32 insertions(+), 33 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index 1ed0574..59ae8a7 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -405,17 +405,6 @@ struct uv2_3_bau_msg_header {
/* bits 127:120 */
 };
 
-/* Abstracted BAU functions */
-struct bau_operations {
-   unsigned long (*read_l_sw_ack)(void);
-   unsigned long (*read_g_sw_ack)(int pnode);
-   unsigned long (*bau_gpa_to_offset)(unsigned long vaddr);
-   void (*write_l_sw_ack)(unsigned long mmr);
-   void (*write_g_sw_ack)(int pnode, unsigned long mmr);
-   void (*write_payload_first)(int pnode, unsigned long mmr);
-   void (*write_payload_last)(int pnode, unsigned long mmr);
-};
-
 /*
  * The activation descriptor:
  * The format of the message to send, plus all accompanying control
@@ -667,6 +656,17 @@ struct bau_control {
struct hub_and_pnode*thp;
 };
 
+/* Abstracted BAU functions */
+struct bau_operations {
+   unsigned long   (*read_l_sw_ack)(void);
+   unsigned long   (*read_g_sw_ack)(int pnode);
+   unsigned long   (*bau_gpa_to_offset)(unsigned long vaddr);
+   void(*write_l_sw_ack)(unsigned long mmr);
+   void(*write_g_sw_ack)(int pnode, unsigned long mmr);
+   void(*write_payload_first)(int pnode, unsigned long mmr);
+   void(*write_payload_last)(int pnode, unsigned long mmr);
+};
+
 static inline void write_mmr_data_broadcast(int pnode, unsigned long mmr_image)
 {
write_gmmr(pnode, UVH_BAU_DATA_BROADCAST, mmr_image);
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 70721c4..e6994fd 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -23,28 +23,7 @@
 #include 
 #include 
 
-static struct bau_operations ops;
-
-static struct bau_operations uv123_bau_ops = {
-   .bau_gpa_to_offset   = uv_gpa_to_offset,
-   .read_l_sw_ack   = read_mmr_sw_ack,
-   .read_g_sw_ack   = read_gmmr_sw_ack,
-   .write_l_sw_ack  = write_mmr_sw_ack,
-   .write_g_sw_ack  = write_gmmr_sw_ack,
-   .write_payload_first = write_mmr_payload_first,
-   .write_payload_last  = write_mmr_payload_last,
-};
-
-static struct bau_operations uv4_bau_ops = {
-   .bau_gpa_to_offset   = uv_gpa_to_soc_phys_ram,
-   .read_l_sw_ack   = read_mmr_proc_sw_ack,
-   .read_g_sw_ack   = read_gmmr_proc_sw_ack,
-   .write_l_sw_ack  = write_mmr_proc_sw_ack,
-   .write_g_sw_ack  = write_gmmr_proc_sw_ack,
-   .write_payload_first = write_mmr_proc_payload_first,
-   .write_payload_last  = write_mmr_proc_payload_last,
-};
-
+static struct bau_operations ops __ro_after_init;
 
 /* timeouts in nanoseconds (indexed by UVH_AGING_PRESCALE_SEL urgency7 30:28) 
*/
 static int timeout_base_ns[] = {
@@ -2158,6 +2137,26 @@ static int __init init_per_cpu(int nuvhubs, int 
base_part_pnode)
return 1;
 }
 
+static const struct bau_operations uv123_bau_ops __initconst = {
+   .bau_gpa_to_offset   = uv_gpa_to_offset,
+   .read_l_sw_ack   = read_mmr_sw_ack,
+   .read_g_sw_ack   = read_gmmr_sw_ack,
+   .write_l_sw_ack  = write_mmr_sw_ack,
+   .write_g_sw_ack  = write_gmmr_sw_ack,
+   .write_payload_first = write_mmr_payload_first,
+   .write_payload_last  = write_mmr_payload_last,
+};
+
+static const struct bau_operations uv4_bau_ops __initconst = {
+   .bau_gpa_to_offset   = uv_gpa_to_soc_phys_ram,
+   .read_l_sw_ack   = read_mmr_proc_sw_ack,
+   .read_g_sw_ack   = read_gmmr_proc_sw_ack,
+   .write_l_sw_ack  = write_mmr_proc_sw_ack,
+   .write_g_sw_ack  = write_gmmr_proc_sw_ack,
+   .write_payload_first = write_mmr_proc_payload_first,
+   .write_payload_last  = write_mmr_proc_payload_last,
+};
+
 /*
  * Initialization of BAU-related structures
  */
-- 
1.8.2.1

[PATCH v2 5/6] x86/platform/uv/BAU: Add wait_completion to bau_operations

[Andrew Banman]

Remove the present wait_completion routine and add a function pointer by
the same name to the bau_operations struct. Rather than switching on the
UV hub version during message processing, set the architecture-specific
uv*_wait_completion during initialization.

The uv123_bau_ops struct must be split into uv1 and uv2_3 versions to
accomodate the corresponding wait_completion routines.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 
---
 arch/x86/include/asm/uv/uv_bau.h |  2 ++
 arch/x86/platform/uv/tlb_uv.c| 31 ++-
 2 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index a02019a..b52b356 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -671,6 +671,8 @@ struct bau_operations {
void(*write_g_sw_ack)(int pnode, unsigned long mmr);
void(*write_payload_first)(int pnode, unsigned long mmr);
void(*write_payload_last)(int pnode, unsigned long mmr);
+   int (*wait_completion)(struct bau_desc*,
+   struct bau_control*, long try);
 };
 
 static inline void write_mmr_data_broadcast(int pnode, unsigned long mmr_image)
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index b8d3830..2a826dd 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -686,14 +686,6 @@ static int uv2_3_wait_completion(struct bau_desc *bau_desc,
return FLUSH_COMPLETE;
 }
 
-static int wait_completion(struct bau_desc *bau_desc, struct bau_control *bcp, 
long try)
-{
-   if (bcp->uvhub_version == 1)
-   return uv1_wait_completion(bau_desc, bcp, try);
-   else
-   return uv2_3_wait_completion(bau_desc, bcp, try);
-}
-
 /*
  * Our retries are blocked by all destination sw ack resources being
  * in use, and a timeout is pending. In that case hardware immediately
@@ -922,7 +914,7 @@ int uv_flush_send_and_wait(struct cpumask *flush_mask, 
struct bau_control *bcp,
write_mmr_activation(index);
 
try++;
-   completion_stat = wait_completion(bau_desc, bcp, try);
+   completion_stat = ops.wait_completion(bau_desc, bcp, try);
 
handle_cmplt(completion_stat, bau_desc, bcp, hmaster, stat);
 
@@ -2135,7 +2127,18 @@ static int __init init_per_cpu(int nuvhubs, int 
base_part_pnode)
return 1;
 }
 
-static const struct bau_operations uv123_bau_ops __initconst = {
+static const struct bau_operations uv1_bau_ops __initconst = {
+   .bau_gpa_to_offset   = uv_gpa_to_offset,
+   .read_l_sw_ack   = read_mmr_sw_ack,
+   .read_g_sw_ack   = read_gmmr_sw_ack,
+   .write_l_sw_ack  = write_mmr_sw_ack,
+   .write_g_sw_ack  = write_gmmr_sw_ack,
+   .write_payload_first = write_mmr_payload_first,
+   .write_payload_last  = write_mmr_payload_last,
+   .wait_completion = uv1_wait_completion,
+};
+
+static const struct bau_operations uv2_3_bau_ops __initconst = {
.bau_gpa_to_offset   = uv_gpa_to_offset,
.read_l_sw_ack   = read_mmr_sw_ack,
.read_g_sw_ack   = read_gmmr_sw_ack,
@@ -2143,6 +2146,7 @@ static int __init init_per_cpu(int nuvhubs, int 
base_part_pnode)
.write_g_sw_ack  = write_gmmr_sw_ack,
.write_payload_first = write_mmr_payload_first,
.write_payload_last  = write_mmr_payload_last,
+   .wait_completion = uv2_3_wait_completion,
 };
 
 static const struct bau_operations uv4_bau_ops __initconst = {
@@ -2153,6 +2157,7 @@ static int __init init_per_cpu(int nuvhubs, int 
base_part_pnode)
.write_g_sw_ack  = write_gmmr_proc_sw_ack,
.write_payload_first = write_mmr_proc_payload_first,
.write_payload_last  = write_mmr_proc_payload_last,
+   .wait_completion = uv2_3_wait_completion,
 };
 
 /*
@@ -2174,11 +2179,11 @@ static int __init uv_bau_init(void)
if (is_uv4_hub())
ops = uv4_bau_ops;
else if (is_uv3_hub())
-   ops = uv123_bau_ops;
+   ops = uv2_3_bau_ops;
else if (is_uv2_hub())
-   ops = uv123_bau_ops;
+   ops = uv2_3_bau_ops;
else if (is_uv1_hub())
-   ops = uv123_bau_ops;
+   ops = uv1_bau_ops;
 
for_each_possible_cpu(cur_cpu) {
mask = _cpu(uv_flush_tlb_mask, cur_cpu);
-- 
1.8.2.1

[PATCH 3/6] x86/platform/uv/BAU: Cleanup bau_operations declaration and instances

[Andrew Banman]

Move the bau_operations declaration after bau struct declarations so the
bau structs can be referenced when adding new functions to
bau_operations. That way we avoid forward declarations of the bau
structs.

Likewise, move uv*_bau_ops structs down to avoid forward declarations of
new functions defined in the same file. Declare these structs __initconst
since they are only used during initialization. Similarly, declare the
bau_operations ops instance __ro_after_init as it is read-only after
initialization.

This is a preparatory patch for adding wait_completion to bau_operations.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 
---
 arch/x86/include/asm/uv/uv_bau.h | 22 ++--
 arch/x86/platform/uv/tlb_uv.c| 43 
 2 files changed, 32 insertions(+), 33 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index 1ed0574..59ae8a7 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -405,17 +405,6 @@ struct uv2_3_bau_msg_header {
/* bits 127:120 */
 };
 
-/* Abstracted BAU functions */
-struct bau_operations {
-   unsigned long (*read_l_sw_ack)(void);
-   unsigned long (*read_g_sw_ack)(int pnode);
-   unsigned long (*bau_gpa_to_offset)(unsigned long vaddr);
-   void (*write_l_sw_ack)(unsigned long mmr);
-   void (*write_g_sw_ack)(int pnode, unsigned long mmr);
-   void (*write_payload_first)(int pnode, unsigned long mmr);
-   void (*write_payload_last)(int pnode, unsigned long mmr);
-};
-
 /*
  * The activation descriptor:
  * The format of the message to send, plus all accompanying control
@@ -667,6 +656,17 @@ struct bau_control {
struct hub_and_pnode*thp;
 };
 
+/* Abstracted BAU functions */
+struct bau_operations {
+   unsigned long   (*read_l_sw_ack)(void);
+   unsigned long   (*read_g_sw_ack)(int pnode);
+   unsigned long   (*bau_gpa_to_offset)(unsigned long vaddr);
+   void(*write_l_sw_ack)(unsigned long mmr);
+   void(*write_g_sw_ack)(int pnode, unsigned long mmr);
+   void(*write_payload_first)(int pnode, unsigned long mmr);
+   void(*write_payload_last)(int pnode, unsigned long mmr);
+};
+
 static inline void write_mmr_data_broadcast(int pnode, unsigned long mmr_image)
 {
write_gmmr(pnode, UVH_BAU_DATA_BROADCAST, mmr_image);
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 70721c4..e6994fd 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -23,28 +23,7 @@
 #include 
 #include 
 
-static struct bau_operations ops;
-
-static struct bau_operations uv123_bau_ops = {
-   .bau_gpa_to_offset   = uv_gpa_to_offset,
-   .read_l_sw_ack   = read_mmr_sw_ack,
-   .read_g_sw_ack   = read_gmmr_sw_ack,
-   .write_l_sw_ack  = write_mmr_sw_ack,
-   .write_g_sw_ack  = write_gmmr_sw_ack,
-   .write_payload_first = write_mmr_payload_first,
-   .write_payload_last  = write_mmr_payload_last,
-};
-
-static struct bau_operations uv4_bau_ops = {
-   .bau_gpa_to_offset   = uv_gpa_to_soc_phys_ram,
-   .read_l_sw_ack   = read_mmr_proc_sw_ack,
-   .read_g_sw_ack   = read_gmmr_proc_sw_ack,
-   .write_l_sw_ack  = write_mmr_proc_sw_ack,
-   .write_g_sw_ack  = write_gmmr_proc_sw_ack,
-   .write_payload_first = write_mmr_proc_payload_first,
-   .write_payload_last  = write_mmr_proc_payload_last,
-};
-
+static struct bau_operations ops __ro_after_init;
 
 /* timeouts in nanoseconds (indexed by UVH_AGING_PRESCALE_SEL urgency7 30:28) 
*/
 static int timeout_base_ns[] = {
@@ -2158,6 +2137,26 @@ static int __init init_per_cpu(int nuvhubs, int 
base_part_pnode)
return 1;
 }
 
+static const struct bau_operations uv123_bau_ops __initconst = {
+   .bau_gpa_to_offset   = uv_gpa_to_offset,
+   .read_l_sw_ack   = read_mmr_sw_ack,
+   .read_g_sw_ack   = read_gmmr_sw_ack,
+   .write_l_sw_ack  = write_mmr_sw_ack,
+   .write_g_sw_ack  = write_gmmr_sw_ack,
+   .write_payload_first = write_mmr_payload_first,
+   .write_payload_last  = write_mmr_payload_last,
+};
+
+static const struct bau_operations uv4_bau_ops __initconst = {
+   .bau_gpa_to_offset   = uv_gpa_to_soc_phys_ram,
+   .read_l_sw_ack   = read_mmr_proc_sw_ack,
+   .read_g_sw_ack   = read_gmmr_proc_sw_ack,
+   .write_l_sw_ack  = write_mmr_proc_sw_ack,
+   .write_g_sw_ack  = write_gmmr_proc_sw_ack,
+   .write_payload_first = write_mmr_proc_payload_first,
+   .write_payload_last  = write_mmr_proc_payload_last,
+};
+
 /*
  * Initialization of BAU-related structures
  */
-- 
1.8.2.1

[PATCH v2 5/6] x86/platform/uv/BAU: Add wait_completion to bau_operations

[Andrew Banman]

Remove the present wait_completion routine and add a function pointer by
the same name to the bau_operations struct. Rather than switching on the
UV hub version during message processing, set the architecture-specific
uv*_wait_completion during initialization.

The uv123_bau_ops struct must be split into uv1 and uv2_3 versions to
accomodate the corresponding wait_completion routines.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 
---
 arch/x86/include/asm/uv/uv_bau.h |  2 ++
 arch/x86/platform/uv/tlb_uv.c| 31 ++-
 2 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index a02019a..b52b356 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -671,6 +671,8 @@ struct bau_operations {
void(*write_g_sw_ack)(int pnode, unsigned long mmr);
void(*write_payload_first)(int pnode, unsigned long mmr);
void(*write_payload_last)(int pnode, unsigned long mmr);
+   int (*wait_completion)(struct bau_desc*,
+   struct bau_control*, long try);
 };
 
 static inline void write_mmr_data_broadcast(int pnode, unsigned long mmr_image)
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index b8d3830..2a826dd 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -686,14 +686,6 @@ static int uv2_3_wait_completion(struct bau_desc *bau_desc,
return FLUSH_COMPLETE;
 }
 
-static int wait_completion(struct bau_desc *bau_desc, struct bau_control *bcp, 
long try)
-{
-   if (bcp->uvhub_version == 1)
-   return uv1_wait_completion(bau_desc, bcp, try);
-   else
-   return uv2_3_wait_completion(bau_desc, bcp, try);
-}
-
 /*
  * Our retries are blocked by all destination sw ack resources being
  * in use, and a timeout is pending. In that case hardware immediately
@@ -922,7 +914,7 @@ int uv_flush_send_and_wait(struct cpumask *flush_mask, 
struct bau_control *bcp,
write_mmr_activation(index);
 
try++;
-   completion_stat = wait_completion(bau_desc, bcp, try);
+   completion_stat = ops.wait_completion(bau_desc, bcp, try);
 
handle_cmplt(completion_stat, bau_desc, bcp, hmaster, stat);
 
@@ -2135,7 +2127,18 @@ static int __init init_per_cpu(int nuvhubs, int 
base_part_pnode)
return 1;
 }
 
-static const struct bau_operations uv123_bau_ops __initconst = {
+static const struct bau_operations uv1_bau_ops __initconst = {
+   .bau_gpa_to_offset   = uv_gpa_to_offset,
+   .read_l_sw_ack   = read_mmr_sw_ack,
+   .read_g_sw_ack   = read_gmmr_sw_ack,
+   .write_l_sw_ack  = write_mmr_sw_ack,
+   .write_g_sw_ack  = write_gmmr_sw_ack,
+   .write_payload_first = write_mmr_payload_first,
+   .write_payload_last  = write_mmr_payload_last,
+   .wait_completion = uv1_wait_completion,
+};
+
+static const struct bau_operations uv2_3_bau_ops __initconst = {
.bau_gpa_to_offset   = uv_gpa_to_offset,
.read_l_sw_ack   = read_mmr_sw_ack,
.read_g_sw_ack   = read_gmmr_sw_ack,
@@ -2143,6 +2146,7 @@ static int __init init_per_cpu(int nuvhubs, int 
base_part_pnode)
.write_g_sw_ack  = write_gmmr_sw_ack,
.write_payload_first = write_mmr_payload_first,
.write_payload_last  = write_mmr_payload_last,
+   .wait_completion = uv2_3_wait_completion,
 };
 
 static const struct bau_operations uv4_bau_ops __initconst = {
@@ -2153,6 +2157,7 @@ static int __init init_per_cpu(int nuvhubs, int 
base_part_pnode)
.write_g_sw_ack  = write_gmmr_proc_sw_ack,
.write_payload_first = write_mmr_proc_payload_first,
.write_payload_last  = write_mmr_proc_payload_last,
+   .wait_completion = uv2_3_wait_completion,
 };
 
 /*
@@ -2174,11 +2179,11 @@ static int __init uv_bau_init(void)
if (is_uv4_hub())
ops = uv4_bau_ops;
else if (is_uv3_hub())
-   ops = uv123_bau_ops;
+   ops = uv2_3_bau_ops;
else if (is_uv2_hub())
-   ops = uv123_bau_ops;
+   ops = uv2_3_bau_ops;
else if (is_uv1_hub())
-   ops = uv123_bau_ops;
+   ops = uv1_bau_ops;
 
for_each_possible_cpu(cur_cpu) {
mask = _cpu(uv_flush_tlb_mask, cur_cpu);
-- 
1.8.2.1

[PATCH 1/6] x86/platform/uv/BAU: Add uv_bau_version enumerated constants

[Andrew Banman]

Define enumerated constants for each UV hub version and replace magic
numbers with the appropriate constant. This makes our checks against
uvhub_version more robust, and any use of unsupported archs will be
caught during compilation.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 
---
 arch/x86/include/asm/uv/uv_bau.h |  7 +++
 arch/x86/platform/uv/tlb_uv.c| 16 
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index 57ab86d..768093f 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -185,6 +185,13 @@
 #define MSG_REGULAR1
 #define MSG_RETRY  2
 
+enum uv_bau_version {
+   UV_BAU_V1 = 1,
+   UV_BAU_V2,
+   UV_BAU_V3,
+   UV_BAU_V4,
+};
+
 /*
  * Distribution: 32 bytes (256 bits) (bytes 0-0x1f of descriptor)
  * If the 'multilevel' flag in the header portion of the descriptor
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index f25982c..f4f5aa6 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -724,7 +724,7 @@ static int wait_completion(struct bau_desc *bau_desc, 
struct bau_control *bcp, l
right_shift = ((desc - UV_CPUS_PER_AS) * UV_ACT_STATUS_SIZE);
}
 
-   if (bcp->uvhub_version == 1)
+   if (bcp->uvhub_version == UV_BAU_V1)
return uv1_wait_completion(bau_desc, mmr_offset, right_shift, 
bcp, try);
else
return uv2_3_wait_completion(bau_desc, mmr_offset, right_shift, 
bcp, try);
@@ -918,7 +918,7 @@ int uv_flush_send_and_wait(struct cpumask *flush_mask, 
struct bau_control *bcp,
struct uv1_bau_msg_header *uv1_hdr = NULL;
struct uv2_3_bau_msg_header *uv2_3_hdr = NULL;
 
-   if (bcp->uvhub_version == 1) {
+   if (bcp->uvhub_version == UV_BAU_V1) {
uv1 = 1;
uv1_throttle(hmaster, stat);
}
@@ -1296,7 +1296,7 @@ void uv_bau_message_interrupt(struct pt_regs *regs)
 
msgdesc.msg_slot = msg - msgdesc.queue_first;
msgdesc.msg = msg;
-   if (bcp->uvhub_version == 2)
+   if (bcp->uvhub_version == UV_BAU_V2)
process_uv2_message(, bcp);
else
/* no error workaround for uv1 or uv3 */
@@ -1838,7 +1838,7 @@ static void pq_init(int node, int pnode)
 * and the payload queue tail must be maintained by the kernel.
 */
bcp = _cpu(bau_control, smp_processor_id());
-   if (bcp->uvhub_version <= 3) {
+   if (bcp->uvhub_version <= UV_BAU_V3) {
tail = first;
gnode = uv_gpa_to_gnode(uv_gpa(pqp));
first = (gnode << UV_PAYLOADQ_GNODE_SHIFT) | tail;
@@ -2052,13 +2052,13 @@ static int scan_sock(struct socket_desc *sdp, struct 
uvhub_desc *bdp,
bcp->socket_master = *smasterp;
bcp->uvhub = bdp->uvhub;
if (is_uv1_hub())
-   bcp->uvhub_version = 1;
+   bcp->uvhub_version = UV_BAU_V1;
else if (is_uv2_hub())
-   bcp->uvhub_version = 2;
+   bcp->uvhub_version = UV_BAU_V2;
else if (is_uv3_hub())
-   bcp->uvhub_version = 3;
+   bcp->uvhub_version = UV_BAU_V3;
else if (is_uv4_hub())
-   bcp->uvhub_version = 4;
+   bcp->uvhub_version = UV_BAU_V4;
else {
pr_emerg("uvhub version not 1, 2, 3, or 4\n");
return 1;
-- 
1.8.2.1

[PATCH 1/6] x86/platform/uv/BAU: Add uv_bau_version enumerated constants

[Andrew Banman]

Define enumerated constants for each UV hub version and replace magic
numbers with the appropriate constant. This makes our checks against
uvhub_version more robust, and any use of unsupported archs will be
caught during compilation.

Signed-off-by: Andrew Banman 
Acked-by: Mike Travis 
---
 arch/x86/include/asm/uv/uv_bau.h |  7 +++
 arch/x86/platform/uv/tlb_uv.c| 16 
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_bau.h b/arch/x86/include/asm/uv/uv_bau.h
index 57ab86d..768093f 100644
--- a/arch/x86/include/asm/uv/uv_bau.h
+++ b/arch/x86/include/asm/uv/uv_bau.h
@@ -185,6 +185,13 @@
 #define MSG_REGULAR1
 #define MSG_RETRY  2
 
+enum uv_bau_version {
+   UV_BAU_V1 = 1,
+   UV_BAU_V2,
+   UV_BAU_V3,
+   UV_BAU_V4,
+};
+
 /*
  * Distribution: 32 bytes (256 bits) (bytes 0-0x1f of descriptor)
  * If the 'multilevel' flag in the header portion of the descriptor
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index f25982c..f4f5aa6 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -724,7 +724,7 @@ static int wait_completion(struct bau_desc *bau_desc, 
struct bau_control *bcp, l
right_shift = ((desc - UV_CPUS_PER_AS) * UV_ACT_STATUS_SIZE);
}
 
-   if (bcp->uvhub_version == 1)
+   if (bcp->uvhub_version == UV_BAU_V1)
return uv1_wait_completion(bau_desc, mmr_offset, right_shift, 
bcp, try);
else
return uv2_3_wait_completion(bau_desc, mmr_offset, right_shift, 
bcp, try);
@@ -918,7 +918,7 @@ int uv_flush_send_and_wait(struct cpumask *flush_mask, 
struct bau_control *bcp,
struct uv1_bau_msg_header *uv1_hdr = NULL;
struct uv2_3_bau_msg_header *uv2_3_hdr = NULL;
 
-   if (bcp->uvhub_version == 1) {
+   if (bcp->uvhub_version == UV_BAU_V1) {
uv1 = 1;
uv1_throttle(hmaster, stat);
}
@@ -1296,7 +1296,7 @@ void uv_bau_message_interrupt(struct pt_regs *regs)
 
msgdesc.msg_slot = msg - msgdesc.queue_first;
msgdesc.msg = msg;
-   if (bcp->uvhub_version == 2)
+   if (bcp->uvhub_version == UV_BAU_V2)
process_uv2_message(, bcp);
else
/* no error workaround for uv1 or uv3 */
@@ -1838,7 +1838,7 @@ static void pq_init(int node, int pnode)
 * and the payload queue tail must be maintained by the kernel.
 */
bcp = _cpu(bau_control, smp_processor_id());
-   if (bcp->uvhub_version <= 3) {
+   if (bcp->uvhub_version <= UV_BAU_V3) {
tail = first;
gnode = uv_gpa_to_gnode(uv_gpa(pqp));
first = (gnode << UV_PAYLOADQ_GNODE_SHIFT) | tail;
@@ -2052,13 +2052,13 @@ static int scan_sock(struct socket_desc *sdp, struct 
uvhub_desc *bdp,
bcp->socket_master = *smasterp;
bcp->uvhub = bdp->uvhub;
if (is_uv1_hub())
-   bcp->uvhub_version = 1;
+   bcp->uvhub_version = UV_BAU_V1;
else if (is_uv2_hub())
-   bcp->uvhub_version = 2;
+   bcp->uvhub_version = UV_BAU_V2;
else if (is_uv3_hub())
-   bcp->uvhub_version = 3;
+   bcp->uvhub_version = UV_BAU_V3;
else if (is_uv4_hub())
-   bcp->uvhub_version = 4;
+   bcp->uvhub_version = UV_BAU_V4;
else {
pr_emerg("uvhub version not 1, 2, 3, or 4\n");
return 1;
-- 
1.8.2.1

[PATCH v1 1/1] scsi: ufs-qcom: remove redundant condition check

[Subhash Jadavani]

Dan Carpenter  reported this:
---
The patch 9c46b8676271: "scsi: ufs-qcom: dump additional testbus
registers" from Feb 3, 2017, leads to the following static checker
warning:

drivers/scsi/ufs/ufs-qcom.c:1531 ufs_qcom_testbus_cfg_is_ok()
warn: impossible condition
'(host->testbus.select_minor > 255) => (0-255 > 255)'

drivers/scsi/ufs/ufs-qcom.c
  1517  static bool ufs_qcom_testbus_cfg_is_ok(struct ufs_qcom_host *host)
  1518  {
  1519  if (host->testbus.select_major >= TSTBUS_MAX) {
  1520   dev_err(host->hba->dev,
  1521 "%s: UFS_CFG1[TEST_BUS_SEL} may not equal 0x%05X\n",
  1522  __func__, host->testbus.select_major);
  1523  return false;
  1524  }
  1525
  1526  /*
  1527   * Not performing check for each individual select_major
  1528   * mappings of select_minor, since there is no harm in
  1529   * configuring a non-existent select_minor
  1530   */
  1531  if (host->testbus.select_minor > 0xFF) {
^

It might make sense to keep this check.  I don't know.  But it's
confusing that 0xFF is a magic number.  Better to make it a define.

  1532  dev_err(host->hba->dev,
  1533   "%s: 0x%05X is not a legal testbus option\n",
  1534__func__, host->testbus.select_minor);
  1535  return false;
  1536  }
  1537
  1538  return true;
  1539  }
---

As data type of "select_minor" is u8, above check is redundant. This change
removes it.

Reported-by: Dan Carpenter 
Signed-off-by: Subhash Jadavani 
---
 drivers/scsi/ufs/ufs-qcom.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index ce5d023..c87d770 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1523,18 +1523,6 @@ static bool ufs_qcom_testbus_cfg_is_ok(struct 
ufs_qcom_host *host)
return false;
}
 
-   /*
-* Not performing check for each individual select_major
-* mappings of select_minor, since there is no harm in
-* configuring a non-existent select_minor
-*/
-   if (host->testbus.select_minor > 0xFF) {
-   dev_err(host->hba->dev,
-   "%s: 0x%05X is not a legal testbus option\n",
-   __func__, host->testbus.select_minor);
-   return false;
-   }
-
return true;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v1 1/1] scsi: ufs-qcom: remove redundant condition check

[Subhash Jadavani]

Dan Carpenter  reported this:
---
The patch 9c46b8676271: "scsi: ufs-qcom: dump additional testbus
registers" from Feb 3, 2017, leads to the following static checker
warning:

drivers/scsi/ufs/ufs-qcom.c:1531 ufs_qcom_testbus_cfg_is_ok()
warn: impossible condition
'(host->testbus.select_minor > 255) => (0-255 > 255)'

drivers/scsi/ufs/ufs-qcom.c
  1517  static bool ufs_qcom_testbus_cfg_is_ok(struct ufs_qcom_host *host)
  1518  {
  1519  if (host->testbus.select_major >= TSTBUS_MAX) {
  1520   dev_err(host->hba->dev,
  1521 "%s: UFS_CFG1[TEST_BUS_SEL} may not equal 0x%05X\n",
  1522  __func__, host->testbus.select_major);
  1523  return false;
  1524  }
  1525
  1526  /*
  1527   * Not performing check for each individual select_major
  1528   * mappings of select_minor, since there is no harm in
  1529   * configuring a non-existent select_minor
  1530   */
  1531  if (host->testbus.select_minor > 0xFF) {
^

It might make sense to keep this check.  I don't know.  But it's
confusing that 0xFF is a magic number.  Better to make it a define.

  1532  dev_err(host->hba->dev,
  1533   "%s: 0x%05X is not a legal testbus option\n",
  1534__func__, host->testbus.select_minor);
  1535  return false;
  1536  }
  1537
  1538  return true;
  1539  }
---

As data type of "select_minor" is u8, above check is redundant. This change
removes it.

Reported-by: Dan Carpenter 
Signed-off-by: Subhash Jadavani 
---
 drivers/scsi/ufs/ufs-qcom.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index ce5d023..c87d770 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1523,18 +1523,6 @@ static bool ufs_qcom_testbus_cfg_is_ok(struct 
ufs_qcom_host *host)
return false;
}
 
-   /*
-* Not performing check for each individual select_major
-* mappings of select_minor, since there is no harm in
-* configuring a non-existent select_minor
-*/
-   if (host->testbus.select_minor > 0xFF) {
-   dev_err(host->hba->dev,
-   "%s: 0x%05X is not a legal testbus option\n",
-   __func__, host->testbus.select_minor);
-   return false;
-   }
-
return true;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC 4/8] doc: fpga-mgr: separate getting/locking FPGA manager

[Alan Tull]

On Fri, Feb 17, 2017 at 11:52 AM, Moritz Fischer  wrote:
> Alan,
>
> small nits inline

Hi Moritz,

Thanks for the review!

Alan

>
> On Wed, Feb 15, 2017 at 8:14 AM, Alan Tull  wrote:
>> Document that getting a reference to a FPGA Manager has been
>> separated from locking the FPGA Mangager for use.
>>
>> fpga_mgr_lock/unlock functions get/release mutex.
>>
>> of_fpga_mgr_get, fpga_mgr_get, and fpga_mgr_put no longer lock
>> the FPGA manager mutex.
>>
>> This makes it more straigtforward to save a reference to
>> a FPGA manager and only attempting to lock it when programming
>> the FPGA.
>>
>> Signed-off-by: Alan Tull 
> Acked-by: Moritz Fischer 
>
>> ---
>>  Documentation/fpga/fpga-mgr.txt | 19 ++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/fpga/fpga-mgr.txt 
>> b/Documentation/fpga/fpga-mgr.txt
>> index 78f197f..06d5d5b 100644
>> --- a/Documentation/fpga/fpga-mgr.txt
>> +++ b/Documentation/fpga/fpga-mgr.txt
>> @@ -53,13 +53,26 @@ To get/put a reference to a FPGA manager:
>> struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
>> struct fpga_manager *fpga_mgr_get(struct device *dev);
>>
>> -Given a DT node or device, get an exclusive reference to a FPGA manager.
>> +Given a DT node or device, get an reference to a FPGA manager.  Pointer
>
> Nits: get *a* reference, 'A' pointer or 'The' pointer.
>
>> +can be saved until you are ready to program the FPGA.
>>
>> void fpga_mgr_put(struct fpga_manager *mgr);
>>
>>  Release the reference.
>>
>>
>> +To get exclusive control of a FPGA manager:
>> +---
>> +
>> +   int fpga_mgr_lock(struct fpga_magager *mgr);
>> +
>> +Call fpga_mgr_lock and verify that it returns 0 before attempting to
>> +program the FPGA.
>> +
>> +   void fpga_mgr_unlock(struct fpga_magager *mgr);
>> +
>> +Call fpga_mgr_unlock when done programming the FPGA.
>> +
>>  To register or unregister the low level FPGA-specific driver:
>>  -
>>
>> @@ -95,11 +108,13 @@ int ret;
>>
>>  /* Get exclusive control of FPGA manager */
>>  struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
>> +ret = fpga_mgr_lock(mgr);
>>
>>  /* Load the buffer to the FPGA */
>>  ret = fpga_mgr_buf_load(mgr, , buf, count);
>>
>>  /* Release the FPGA manager */
>> +fpga_mgr_unlock(mgr);
>>  fpga_mgr_put(mgr);
>>
>>
>> @@ -124,11 +139,13 @@ int ret;
>>
>>  /* Get exclusive control of FPGA manager */
>>  struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
>> +ret = fpga_mgr_lock(mgr);
>>
>>  /* Get the firmware image (path) and load it to the FPGA */
>>  ret = fpga_mgr_firmware_load(mgr, , path);
>>
>>  /* Release the FPGA manager */
>> +fpga_mgr_unlock(mgr);
>>  fpga_mgr_put(mgr);
>>
>>
>> --
>> 2.7.4
>>
>
> Cheers,
>
> Moritz

Re: [RFC 4/8] doc: fpga-mgr: separate getting/locking FPGA manager

[Alan Tull]

On Fri, Feb 17, 2017 at 11:52 AM, Moritz Fischer  wrote:
> Alan,
>
> small nits inline

Hi Moritz,

Thanks for the review!

Alan

>
> On Wed, Feb 15, 2017 at 8:14 AM, Alan Tull  wrote:
>> Document that getting a reference to a FPGA Manager has been
>> separated from locking the FPGA Mangager for use.
>>
>> fpga_mgr_lock/unlock functions get/release mutex.
>>
>> of_fpga_mgr_get, fpga_mgr_get, and fpga_mgr_put no longer lock
>> the FPGA manager mutex.
>>
>> This makes it more straigtforward to save a reference to
>> a FPGA manager and only attempting to lock it when programming
>> the FPGA.
>>
>> Signed-off-by: Alan Tull 
> Acked-by: Moritz Fischer 
>
>> ---
>>  Documentation/fpga/fpga-mgr.txt | 19 ++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/fpga/fpga-mgr.txt 
>> b/Documentation/fpga/fpga-mgr.txt
>> index 78f197f..06d5d5b 100644
>> --- a/Documentation/fpga/fpga-mgr.txt
>> +++ b/Documentation/fpga/fpga-mgr.txt
>> @@ -53,13 +53,26 @@ To get/put a reference to a FPGA manager:
>> struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
>> struct fpga_manager *fpga_mgr_get(struct device *dev);
>>
>> -Given a DT node or device, get an exclusive reference to a FPGA manager.
>> +Given a DT node or device, get an reference to a FPGA manager.  Pointer
>
> Nits: get *a* reference, 'A' pointer or 'The' pointer.
>
>> +can be saved until you are ready to program the FPGA.
>>
>> void fpga_mgr_put(struct fpga_manager *mgr);
>>
>>  Release the reference.
>>
>>
>> +To get exclusive control of a FPGA manager:
>> +---
>> +
>> +   int fpga_mgr_lock(struct fpga_magager *mgr);
>> +
>> +Call fpga_mgr_lock and verify that it returns 0 before attempting to
>> +program the FPGA.
>> +
>> +   void fpga_mgr_unlock(struct fpga_magager *mgr);
>> +
>> +Call fpga_mgr_unlock when done programming the FPGA.
>> +
>>  To register or unregister the low level FPGA-specific driver:
>>  -
>>
>> @@ -95,11 +108,13 @@ int ret;
>>
>>  /* Get exclusive control of FPGA manager */
>>  struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
>> +ret = fpga_mgr_lock(mgr);
>>
>>  /* Load the buffer to the FPGA */
>>  ret = fpga_mgr_buf_load(mgr, , buf, count);
>>
>>  /* Release the FPGA manager */
>> +fpga_mgr_unlock(mgr);
>>  fpga_mgr_put(mgr);
>>
>>
>> @@ -124,11 +139,13 @@ int ret;
>>
>>  /* Get exclusive control of FPGA manager */
>>  struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
>> +ret = fpga_mgr_lock(mgr);
>>
>>  /* Get the firmware image (path) and load it to the FPGA */
>>  ret = fpga_mgr_firmware_load(mgr, , path);
>>
>>  /* Release the FPGA manager */
>> +fpga_mgr_unlock(mgr);
>>  fpga_mgr_put(mgr);
>>
>>
>> --
>> 2.7.4
>>
>
> Cheers,
>
> Moritz

Re: [PATCH v3 1/4] Documentation: devicetree: Add document bindings for leds-mt6323

[Jacek Anaszewski]

Hi Sean,

I've noticed some issues here, please refer below.

On 02/17/2017 07:05 AM, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> This patch adds documentation for devicetree bindings
> for LED support on MT6323 PMIC
> 
> Signed-off-by: Sean Wang 
> ---
>  .../devicetree/bindings/leds/leds-mt6323.txt   | 60 
> ++
>  1 file changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-mt6323.txt
> 
> diff --git a/Documentation/devicetree/bindings/leds/leds-mt6323.txt 
> b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
> new file mode 100644
> index 000..a968258
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
> @@ -0,0 +1,60 @@
> +Device Tree Bindings for LED support on MT6323 PMIC
> +
> +MT6323 LED controller is subfunction provided by
> +MT6323 PMIC, so the LED controller are defined as

s/controller/controllers/

> +the subnode of the function node provided by MT6323
> +PMIC controller that is being defined as one kind of
> +Muti-Function Device (MFD) using shared bus called
> +PMIC wrapper for each subfunction to access remote
> +MT6323 PMIC hardware.
> +
> +For MT6323 MFD bindings see:
> +Documentation/devicetree/bindings/mfd/mt6397.txt
> +For MediaTek PMIC wrapper bindings see:
> +Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> +
> +There's sub-node for the LED controller that describes
> +the initial behavior for each LED physically and currently
> +only four LED sub-nodes could be supported.

s/could/can/

> +
> +Required properties:
> +- compatible : must be "mediatek,mt6323-led"

s/must/Must/

and please put dot at the end of sentence.

> +
> +Optional properties:
> +- label : (optional)
> +  see Documentation/devicetree/bindings/leds/common.txt
> +- linux,default-trigger : (optional)
> +  see Documentation/devicetree/bindings/leds/common.txt
> +- default-state: (optional) The initial state of the LED
> +  see Documentation/devicetree/bindings/leds/common.txt
> +
> +Example:
> +
> + {
> + pmic: mt6323 {
> + compatible = "mediatek,mt6323";
> + interrupt-parent = <>;
> + interrupts = <150 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + mt6323led: mt6323led{
> + compatible = "mediatek,mt6323-led";
> +
> + led0: isink0 {
> + label = "LED0"

Currently these nodes refer to particular LED iout only by name,
but AFAIK DT node parsing order is not guaranteed. Therefore
it is customary to use reg property for defining the iout for
which the child node is predestined.

Please compare DT bindings of the other LED class devices.

> + linux,default-trigger = "timer";
> + default-state = "on";
> + };
> + led1: isink1 {
> + label = "LED1";
> + default-state = "on";
> + };
> + led2: isink2 {
> + label = "LED2";
> + linux,default-trigger = "timer";
> + default-state = "off";
> + };
> + };
> + };
> +};
> 

-- 
Best regards,
Jacek Anaszewski

Re: [PATCH v3 3/4] leds: Add LED support for MT6323 PMIC

[Jacek Anaszewski]

Hi Sean,

Thanks for the updated patch. I have one more comment below.

On 02/17/2017 07:05 AM, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> MT6323 PMIC is a multi-function device that includes
> LED function. It allows attaching up to 4 LEDs which
> can either be on, off or dimmed and/or blinked with
> the controller.
> 
> Signed-off-by: Sean Wang 
> ---
>  drivers/leds/Kconfig   |   8 +
>  drivers/leds/Makefile  |   1 +
>  drivers/leds/leds-mt6323.c | 470 
> +
>  3 files changed, 479 insertions(+)
>  create mode 100644 drivers/leds/leds-mt6323.c
> 
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index c621cbb..30095fc 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -117,6 +117,14 @@ config LEDS_MIKROTIK_RB532
> This option enables support for the so called "User LED" of
> Mikrotik's Routerboard 532.
>  
> +config LEDS_MT6323
> + tristate "LED Support for Mediatek MT6323 PMIC"
> + depends on LEDS_CLASS
> + depends on MFD_MT6397
> + help
> +   This option enables support for on-chip LED drivers found on
> +   Mediatek MT6323 PMIC.
> +
>  config LEDS_S3C24XX
>   tristate "LED Support for Samsung S3C24XX GPIO LEDs"
>   depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 6b82737..4feb332 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_LEDS_IS31FL32XX)   += 
> leds-is31fl32xx.o
>  obj-$(CONFIG_LEDS_PM8058)+= leds-pm8058.o
>  obj-$(CONFIG_LEDS_MLXCPLD)   += leds-mlxcpld.o
>  obj-$(CONFIG_LEDS_NIC78BX)   += leds-nic78bx.o
> +obj-$(CONFIG_LEDS_MT6323)+= leds-mt6323.o
>  
>  # LED SPI Drivers
>  obj-$(CONFIG_LEDS_DAC124S085)+= leds-dac124s085.o
> diff --git a/drivers/leds/leds-mt6323.c b/drivers/leds/leds-mt6323.c
> new file mode 100644
> index 000..f431b1d
> --- /dev/null
> +++ b/drivers/leds/leds-mt6323.c
> @@ -0,0 +1,470 @@
> +/*
> + * LED driver for Mediatek MT6323 PMIC
> + *
> + * Copyright (C) 2017 Sean Wang 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Register field for MT6323_TOP_CKPDN0 to enable
> + * 32K clock common for LED device.
> + */
> +#define MT6323_RG_DRV_32K_CK_PDN BIT(11)
> +#define MT6323_RG_DRV_32K_CK_PDN_MASKBIT(11)
> +
> +/*
> + * Register field for MT6323_TOP_CKPDN2 to enable
> + * individual clock for LED device.
> + */
> +#define MT6323_RG_ISINK_CK_PDN(i)BIT(i)
> +#define MT6323_RG_ISINK_CK_PDN_MASK(i)   BIT(i)
> +
> +/*
> + * Register field for MT6323_TOP_CKCON1 to select
> + * clock source.
> + */
> +#define MT6323_RG_ISINK_CK_SEL_MASK(i)   (BIT(10) << (i))
> +
> +/*
> + * Register for MT6323_ISINK_CON0 to setup the
> + * duty cycle of the blink.
> + */
> +#define MT6323_ISINK_CON0(i) (MT6323_ISINK0_CON0 + 0x8 * (i))
> +#define MT6323_ISINK_DIM_DUTY_MASK   (0x1f << 8)
> +#define MT6323_ISINK_DIM_DUTY(i) (((i) << 8) & \
> + MT6323_ISINK_DIM_DUTY_MASK)
> +
> +/* Register to setup the period of the blink. */
> +#define MT6323_ISINK_CON1(i) (MT6323_ISINK0_CON1 + 0x8 * (i))
> +#define MT6323_ISINK_DIM_FSEL_MASK   (0x)
> +#define MT6323_ISINK_DIM_FSEL(i) ((i) & MT6323_ISINK_DIM_FSEL_MASK)
> +
> +/* Register to control the brightness. */
> +#define MT6323_ISINK_CON2(i) (MT6323_ISINK0_CON2 + 0x8 * (i))
> +#define MT6323_ISINK_CH_STEP_SHIFT   12
> +#define MT6323_ISINK_CH_STEP_MASK(0x7 << 12)
> +#define MT6323_ISINK_CH_STEP(i)  (((i) << 12) & \
> + MT6323_ISINK_CH_STEP_MASK)
> +#define MT6323_ISINK_SFSTR0_TC_MASK  (0x3 << 1)
> +#define MT6323_ISINK_SFSTR0_TC(i)(((i) << 1) & \
> + MT6323_ISINK_SFSTR0_TC_MASK)
> +#define MT6323_ISINK_SFSTR0_EN_MASK  BIT(0)
> +#define MT6323_ISINK_SFSTR0_EN   BIT(0)
> +
> +/* Register to LED channel enablement. */
> +#define MT6323_ISINK_CH_EN_MASK(i)   BIT(i)
> +#define MT6323_ISINK_CH_EN(i)BIT(i)
> +
> +#define MT6323_MAX_PERIOD  1
> +#define MT6323_MAX_LEDS4
> +#define MT6323_MAX_BRIGHTNESS  6
> +#define 

Re: [PATCH v3 1/4] Documentation: devicetree: Add document bindings for leds-mt6323

[Jacek Anaszewski]

Hi Sean,

I've noticed some issues here, please refer below.

On 02/17/2017 07:05 AM, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> This patch adds documentation for devicetree bindings
> for LED support on MT6323 PMIC
> 
> Signed-off-by: Sean Wang 
> ---
>  .../devicetree/bindings/leds/leds-mt6323.txt   | 60 
> ++
>  1 file changed, 60 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-mt6323.txt
> 
> diff --git a/Documentation/devicetree/bindings/leds/leds-mt6323.txt 
> b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
> new file mode 100644
> index 000..a968258
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-mt6323.txt
> @@ -0,0 +1,60 @@
> +Device Tree Bindings for LED support on MT6323 PMIC
> +
> +MT6323 LED controller is subfunction provided by
> +MT6323 PMIC, so the LED controller are defined as

s/controller/controllers/

> +the subnode of the function node provided by MT6323
> +PMIC controller that is being defined as one kind of
> +Muti-Function Device (MFD) using shared bus called
> +PMIC wrapper for each subfunction to access remote
> +MT6323 PMIC hardware.
> +
> +For MT6323 MFD bindings see:
> +Documentation/devicetree/bindings/mfd/mt6397.txt
> +For MediaTek PMIC wrapper bindings see:
> +Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> +
> +There's sub-node for the LED controller that describes
> +the initial behavior for each LED physically and currently
> +only four LED sub-nodes could be supported.

s/could/can/

> +
> +Required properties:
> +- compatible : must be "mediatek,mt6323-led"

s/must/Must/

and please put dot at the end of sentence.

> +
> +Optional properties:
> +- label : (optional)
> +  see Documentation/devicetree/bindings/leds/common.txt
> +- linux,default-trigger : (optional)
> +  see Documentation/devicetree/bindings/leds/common.txt
> +- default-state: (optional) The initial state of the LED
> +  see Documentation/devicetree/bindings/leds/common.txt
> +
> +Example:
> +
> + {
> + pmic: mt6323 {
> + compatible = "mediatek,mt6323";
> + interrupt-parent = <>;
> + interrupts = <150 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + mt6323led: mt6323led{
> + compatible = "mediatek,mt6323-led";
> +
> + led0: isink0 {
> + label = "LED0"

Currently these nodes refer to particular LED iout only by name,
but AFAIK DT node parsing order is not guaranteed. Therefore
it is customary to use reg property for defining the iout for
which the child node is predestined.

Please compare DT bindings of the other LED class devices.

> + linux,default-trigger = "timer";
> + default-state = "on";
> + };
> + led1: isink1 {
> + label = "LED1";
> + default-state = "on";
> + };
> + led2: isink2 {
> + label = "LED2";
> + linux,default-trigger = "timer";
> + default-state = "off";
> + };
> + };
> + };
> +};
> 

-- 
Best regards,
Jacek Anaszewski

Re: [PATCH v3 3/4] leds: Add LED support for MT6323 PMIC

[Jacek Anaszewski]

Hi Sean,

Thanks for the updated patch. I have one more comment below.

On 02/17/2017 07:05 AM, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> MT6323 PMIC is a multi-function device that includes
> LED function. It allows attaching up to 4 LEDs which
> can either be on, off or dimmed and/or blinked with
> the controller.
> 
> Signed-off-by: Sean Wang 
> ---
>  drivers/leds/Kconfig   |   8 +
>  drivers/leds/Makefile  |   1 +
>  drivers/leds/leds-mt6323.c | 470 
> +
>  3 files changed, 479 insertions(+)
>  create mode 100644 drivers/leds/leds-mt6323.c
> 
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index c621cbb..30095fc 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -117,6 +117,14 @@ config LEDS_MIKROTIK_RB532
> This option enables support for the so called "User LED" of
> Mikrotik's Routerboard 532.
>  
> +config LEDS_MT6323
> + tristate "LED Support for Mediatek MT6323 PMIC"
> + depends on LEDS_CLASS
> + depends on MFD_MT6397
> + help
> +   This option enables support for on-chip LED drivers found on
> +   Mediatek MT6323 PMIC.
> +
>  config LEDS_S3C24XX
>   tristate "LED Support for Samsung S3C24XX GPIO LEDs"
>   depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 6b82737..4feb332 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_LEDS_IS31FL32XX)   += 
> leds-is31fl32xx.o
>  obj-$(CONFIG_LEDS_PM8058)+= leds-pm8058.o
>  obj-$(CONFIG_LEDS_MLXCPLD)   += leds-mlxcpld.o
>  obj-$(CONFIG_LEDS_NIC78BX)   += leds-nic78bx.o
> +obj-$(CONFIG_LEDS_MT6323)+= leds-mt6323.o
>  
>  # LED SPI Drivers
>  obj-$(CONFIG_LEDS_DAC124S085)+= leds-dac124s085.o
> diff --git a/drivers/leds/leds-mt6323.c b/drivers/leds/leds-mt6323.c
> new file mode 100644
> index 000..f431b1d
> --- /dev/null
> +++ b/drivers/leds/leds-mt6323.c
> @@ -0,0 +1,470 @@
> +/*
> + * LED driver for Mediatek MT6323 PMIC
> + *
> + * Copyright (C) 2017 Sean Wang 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Register field for MT6323_TOP_CKPDN0 to enable
> + * 32K clock common for LED device.
> + */
> +#define MT6323_RG_DRV_32K_CK_PDN BIT(11)
> +#define MT6323_RG_DRV_32K_CK_PDN_MASKBIT(11)
> +
> +/*
> + * Register field for MT6323_TOP_CKPDN2 to enable
> + * individual clock for LED device.
> + */
> +#define MT6323_RG_ISINK_CK_PDN(i)BIT(i)
> +#define MT6323_RG_ISINK_CK_PDN_MASK(i)   BIT(i)
> +
> +/*
> + * Register field for MT6323_TOP_CKCON1 to select
> + * clock source.
> + */
> +#define MT6323_RG_ISINK_CK_SEL_MASK(i)   (BIT(10) << (i))
> +
> +/*
> + * Register for MT6323_ISINK_CON0 to setup the
> + * duty cycle of the blink.
> + */
> +#define MT6323_ISINK_CON0(i) (MT6323_ISINK0_CON0 + 0x8 * (i))
> +#define MT6323_ISINK_DIM_DUTY_MASK   (0x1f << 8)
> +#define MT6323_ISINK_DIM_DUTY(i) (((i) << 8) & \
> + MT6323_ISINK_DIM_DUTY_MASK)
> +
> +/* Register to setup the period of the blink. */
> +#define MT6323_ISINK_CON1(i) (MT6323_ISINK0_CON1 + 0x8 * (i))
> +#define MT6323_ISINK_DIM_FSEL_MASK   (0x)
> +#define MT6323_ISINK_DIM_FSEL(i) ((i) & MT6323_ISINK_DIM_FSEL_MASK)
> +
> +/* Register to control the brightness. */
> +#define MT6323_ISINK_CON2(i) (MT6323_ISINK0_CON2 + 0x8 * (i))
> +#define MT6323_ISINK_CH_STEP_SHIFT   12
> +#define MT6323_ISINK_CH_STEP_MASK(0x7 << 12)
> +#define MT6323_ISINK_CH_STEP(i)  (((i) << 12) & \
> + MT6323_ISINK_CH_STEP_MASK)
> +#define MT6323_ISINK_SFSTR0_TC_MASK  (0x3 << 1)
> +#define MT6323_ISINK_SFSTR0_TC(i)(((i) << 1) & \
> + MT6323_ISINK_SFSTR0_TC_MASK)
> +#define MT6323_ISINK_SFSTR0_EN_MASK  BIT(0)
> +#define MT6323_ISINK_SFSTR0_EN   BIT(0)
> +
> +/* Register to LED channel enablement. */
> +#define MT6323_ISINK_CH_EN_MASK(i)   BIT(i)
> +#define MT6323_ISINK_CH_EN(i)BIT(i)
> +
> +#define MT6323_MAX_PERIOD  1
> +#define MT6323_MAX_LEDS4
> +#define MT6323_MAX_BRIGHTNESS  6
> +#define MT6323_UNIT_DUTY3125
> +
> +struct mt6323_leds;
> +
> +/**
> 

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Rask Ingemann Lambertsen]

On Fri, Feb 17, 2017 at 04:44:19PM +0100, Maxime Ripard wrote:
[...]
> We already have DT bindings for out of tree drivers, there's really
> nothing new here.

We have DT bindings for *hardware*, not for drivers. As stated in
Documentation/devicetree/usage-model.txt:

"The "Open Firmware Device Tree", or simply Device Tree (DT), is a data
structure and language for describing hardware.  More specifically, it
is a description of hardware that is readable by an operating system
so that the operating system doesn't need to hard code details of the
machine."

"2.1 High Level View
---
The most important thing to understand is that the DT is simply a data
structure that describes the hardware."

-- 
Rask Ingemann Lambertsen

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Rask Ingemann Lambertsen]

On Fri, Feb 17, 2017 at 04:44:19PM +0100, Maxime Ripard wrote:
[...]
> We already have DT bindings for out of tree drivers, there's really
> nothing new here.

We have DT bindings for *hardware*, not for drivers. As stated in
Documentation/devicetree/usage-model.txt:

"The "Open Firmware Device Tree", or simply Device Tree (DT), is a data
structure and language for describing hardware.  More specifically, it
is a description of hardware that is readable by an operating system
so that the operating system doesn't need to hard code details of the
machine."

"2.1 High Level View
---
The most important thing to understand is that the DT is simply a data
structure that describes the hardware."

-- 
Rask Ingemann Lambertsen