Re: [PATCH 0/5] add support for relative references in special sections

[Sergey Senozhatsky]

On (08/14/17 11:52), Ard Biesheuvel wrote:
> This adds support for emitting special sections such as initcall arrays,
> PCI fixups and tracepoints as relative references rather than absolute
> references. This reduces the size by 50% on 64-bit architectures, but
> more importantly, it removes the need for carrying relocation metadata
> for these sections in relocatables kernels (e.g., for KASLR) that need
> to fix up these absolute references at boot time. On arm64, this reduces
> the vmlinux footprint of such a reference by 8x (8 byte absolute reference
> + 24 byte RELA entry vs 4 byte relative reference)
[..]

a side note,
checkpatch complaints quite a lot.

-ss

Re: [PATCH 0/5] add support for relative references in special sections

[Sergey Senozhatsky]

On (08/14/17 11:52), Ard Biesheuvel wrote:
> This adds support for emitting special sections such as initcall arrays,
> PCI fixups and tracepoints as relative references rather than absolute
> references. This reduces the size by 50% on 64-bit architectures, but
> more importantly, it removes the need for carrying relocation metadata
> for these sections in relocatables kernels (e.g., for KASLR) that need
> to fix up these absolute references at boot time. On arm64, this reduces
> the vmlinux footprint of such a reference by 8x (8 byte absolute reference
> + 24 byte RELA entry vs 4 byte relative reference)
[..]

a side note,
checkpatch complaints quite a lot.

-ss

Re: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

Hello,

On 08/18/2017 08:43 AM, Takashi Sakamoto wrote:

On Aug 17 2017 19:05, Oleksandr Grytsov wrote:
So, from the above we think that period elapsed event derived in the 
described
ways may not improve latency and will complicate the system. So, for 
that
reason we are thinking of the option 2) (Positions of actual data 
transmission

in any serial sound interfaces of actual hardwares.)


Please declare the way to enable stuffs on DomU to get the positions 
from actual hardware.


This is what we haven't investigated yet in detail as we were mostly 
focusing on

period elapsed approach, so we can report our findings to the community.

Taking into account the fact that the backend we have is a user-space 
application

running on top of ALSA/PulseAudio we cannot get HW pointers from actual
hardware by any means (PulseAudio use-case is the most tough thing in 
equation)


At the moment we are seeking for any advise from more experienced developers
in the field on possible ways to solve the problem of Dom0/DomU 
synchronization.
Hope, together we can identify such a way that would be accepted by the 
community.


If you have something on your mind could you please share your thoughts?


Regards

Takashi Sakamoto

Thank you,
Oleksandr Andrushchenko

Re: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

Hello,

On 08/18/2017 08:43 AM, Takashi Sakamoto wrote:

On Aug 17 2017 19:05, Oleksandr Grytsov wrote:
So, from the above we think that period elapsed event derived in the 
described
ways may not improve latency and will complicate the system. So, for 
that
reason we are thinking of the option 2) (Positions of actual data 
transmission

in any serial sound interfaces of actual hardwares.)


Please declare the way to enable stuffs on DomU to get the positions 
from actual hardware.


This is what we haven't investigated yet in detail as we were mostly 
focusing on

period elapsed approach, so we can report our findings to the community.

Taking into account the fact that the backend we have is a user-space 
application

running on top of ALSA/PulseAudio we cannot get HW pointers from actual
hardware by any means (PulseAudio use-case is the most tough thing in 
equation)


At the moment we are seeking for any advise from more experienced developers
in the field on possible ways to solve the problem of Dom0/DomU 
synchronization.
Hope, together we can identify such a way that would be accepted by the 
community.


If you have something on your mind could you please share your thoughts?


Regards

Takashi Sakamoto

Thank you,
Oleksandr Andrushchenko

Re: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

On 2017/8/18 13:04, Tantilov, Emil S wrote:
>> -Original Message-
>> From: Ding Tianhong [mailto:dingtianh...@huawei.com]
>> Sent: Thursday, August 17, 2017 5:39 PM
>> To: Tantilov, Emil S ; da...@davemloft.net;
>> Kirsher, Jeffrey T ; keesc...@chromium.org;
>> linux-kernel@vger.kernel.org; sparcli...@vger.kernel.org; intel-wired-
>> l...@lists.osuosl.org; alexander.du...@gmail.com; net...@vger.kernel.org;
>> linux...@huawei.com
>> Subject: Re: [PATCH net v2 2/2] net: ixgbe: Use new
>> PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
>>
>>
>>
>> On 2017/8/17 22:17, Tantilov, Emil S wrote:
>>
ret_val = ixgbe_start_hw_generic(hw);

 -#ifndef CONFIG_SPARC
 -  /* Disable relaxed ordering */
 -  for (i = 0; ((i < hw->mac.max_tx_queues) &&
 -   (i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
 -  regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(i));
 -  regval &= ~IXGBE_DCA_TXCTRL_DESC_WRO_EN;
 -  IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(i), regval);
 -  }
 +  if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
>>>
>>> As Alex mentioned there is no need for this check in any form.
>>>
>>> The HW defaults to Relaxed Ordering enabled unless it is disabled in
>>> the PCIe Device Control Register. So the above logic is already done by
>> HW.
>>>
>>> All you have to do is strip the code disabling relaxed ordering.
>>>
>>
>> Hi Tantilov:
>>
>> I misunderstood Alex's suggestion, But I still couldn't find the logic
>> where
>> the HW disable the Relaxed Ordering when the PCIe Device Control Register
>> disable it, can you point it out?
> 
> If you look at the datasheet (82599) - the description of CTRL_EXT.RO_DIS 
> (bit 17, 0b):
> 
> Relaxed Ordering Disable. When set to 1b, the device does not request any 
> relaxed
> ordering transactions. When this bit is cleared and the Enable Relaxed 
> Ordering bit in
> the Device Control register is set, the device requests relaxed ordering 
> transactions per queues as configured in the DCA_RXCTRL[n] and DCA_TXCTRL[n] 
> registers.
> 
> So if you remove the code that clears the bits in DCA_T/RXCTRL relaxed 
> ordering should
> be enabled by HW when the bus allows it.
> 

Great, Thanks for your explanation.

> Thanks,
> Emil
> 
> 
> .
> 

Re: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

On 2017/8/18 13:04, Tantilov, Emil S wrote:
>> -Original Message-
>> From: Ding Tianhong [mailto:dingtianh...@huawei.com]
>> Sent: Thursday, August 17, 2017 5:39 PM
>> To: Tantilov, Emil S ; da...@davemloft.net;
>> Kirsher, Jeffrey T ; keesc...@chromium.org;
>> linux-kernel@vger.kernel.org; sparcli...@vger.kernel.org; intel-wired-
>> l...@lists.osuosl.org; alexander.du...@gmail.com; net...@vger.kernel.org;
>> linux...@huawei.com
>> Subject: Re: [PATCH net v2 2/2] net: ixgbe: Use new
>> PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
>>
>>
>>
>> On 2017/8/17 22:17, Tantilov, Emil S wrote:
>>
ret_val = ixgbe_start_hw_generic(hw);

 -#ifndef CONFIG_SPARC
 -  /* Disable relaxed ordering */
 -  for (i = 0; ((i < hw->mac.max_tx_queues) &&
 -   (i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
 -  regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(i));
 -  regval &= ~IXGBE_DCA_TXCTRL_DESC_WRO_EN;
 -  IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(i), regval);
 -  }
 +  if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
>>>
>>> As Alex mentioned there is no need for this check in any form.
>>>
>>> The HW defaults to Relaxed Ordering enabled unless it is disabled in
>>> the PCIe Device Control Register. So the above logic is already done by
>> HW.
>>>
>>> All you have to do is strip the code disabling relaxed ordering.
>>>
>>
>> Hi Tantilov:
>>
>> I misunderstood Alex's suggestion, But I still couldn't find the logic
>> where
>> the HW disable the Relaxed Ordering when the PCIe Device Control Register
>> disable it, can you point it out?
> 
> If you look at the datasheet (82599) - the description of CTRL_EXT.RO_DIS 
> (bit 17, 0b):
> 
> Relaxed Ordering Disable. When set to 1b, the device does not request any 
> relaxed
> ordering transactions. When this bit is cleared and the Enable Relaxed 
> Ordering bit in
> the Device Control register is set, the device requests relaxed ordering 
> transactions per queues as configured in the DCA_RXCTRL[n] and DCA_TXCTRL[n] 
> registers.
> 
> So if you remove the code that clears the bits in DCA_T/RXCTRL relaxed 
> ordering should
> be enabled by HW when the bus allows it.
> 

Great, Thanks for your explanation.

> Thanks,
> Emil
> 
> 
> .
> 

[PATCH] drivers: spi: Allocate bus number from spi framework

[sunil . m]

From: Suniel Mahesh <suni...@techveda.org>

spi framework should allocate bus number dynamically either
via Linux IDR or spi alias for master drivers. This patch deletes
code pertaining to manual allocation of spi bus number in spi omap2
master driver.

Signed-off-by: Suniel Mahesh <suni...@techveda.org>
Signed-off-by: Karthik Tummala <kart...@techveda.org>
Tested-by: Karthik Tummala <kart...@techveda.org>
---
Note:
- Patch was compile tested and built(ARCH=arm) on next-20170817.
- Patch was hardware tested on AM335x (McSPI controller) with
  spi flash chips.
- Added spi aliases in aliases node, device tree and tested.
- No build/run-time issues reported.
- The commit:
"spi: Pick spi bus number from Linux idr or spi alias"
(SHA1:9b61e302210eba55768962f2f11e96bb508c2408)
has introduced bus numbering which happens dynamically either
via Linux IDR or spi alias for master drivers.
---
 drivers/spi/spi-omap2-mcspi.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index e048268..9bf64e6 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1338,7 +1338,6 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
struct resource *r;
int status = 0, i;
u32 regs_offset = 0;
-   static int  bus_num = 1;
struct device_node  *node = pdev->dev.of_node;
const struct of_device_id *match;
 
@@ -1374,14 +1373,11 @@ static int omap2_mcspi_probe(struct platform_device 
*pdev)
 
of_property_read_u32(node, "ti,spi-num-cs", _cs);
master->num_chipselect = num_cs;
-   master->bus_num = bus_num++;
if (of_get_property(node, "ti,pindir-d0-out-d1-in", NULL))
mcspi->pin_dir = MCSPI_PINDIR_D0_OUT_D1_IN;
} else {
pdata = dev_get_platdata(>dev);
master->num_chipselect = pdata->num_cs;
-   if (pdev->id != -1)
-   master->bus_num = pdev->id;
mcspi->pin_dir = pdata->pin_dir;
}
regs_offset = pdata->regs_offset;
-- 
1.9.1

[PATCH] drivers: spi: Allocate bus number from spi framework

[sunil . m]

From: Suniel Mahesh 

spi framework should allocate bus number dynamically either
via Linux IDR or spi alias for master drivers. This patch deletes
code pertaining to manual allocation of spi bus number in spi omap2
master driver.

Signed-off-by: Suniel Mahesh 
Signed-off-by: Karthik Tummala 
Tested-by: Karthik Tummala 
---
Note:
- Patch was compile tested and built(ARCH=arm) on next-20170817.
- Patch was hardware tested on AM335x (McSPI controller) with
  spi flash chips.
- Added spi aliases in aliases node, device tree and tested.
- No build/run-time issues reported.
- The commit:
"spi: Pick spi bus number from Linux idr or spi alias"
(SHA1:9b61e302210eba55768962f2f11e96bb508c2408)
has introduced bus numbering which happens dynamically either
via Linux IDR or spi alias for master drivers.
---
 drivers/spi/spi-omap2-mcspi.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index e048268..9bf64e6 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1338,7 +1338,6 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
struct resource *r;
int status = 0, i;
u32 regs_offset = 0;
-   static int  bus_num = 1;
struct device_node  *node = pdev->dev.of_node;
const struct of_device_id *match;
 
@@ -1374,14 +1373,11 @@ static int omap2_mcspi_probe(struct platform_device 
*pdev)
 
of_property_read_u32(node, "ti,spi-num-cs", _cs);
master->num_chipselect = num_cs;
-   master->bus_num = bus_num++;
if (of_get_property(node, "ti,pindir-d0-out-d1-in", NULL))
mcspi->pin_dir = MCSPI_PINDIR_D0_OUT_D1_IN;
} else {
pdata = dev_get_platdata(>dev);
master->num_chipselect = pdata->num_cs;
-   if (pdev->id != -1)
-   master->bus_num = pdev->id;
mcspi->pin_dir = pdata->pin_dir;
}
regs_offset = pdata->regs_offset;
-- 
1.9.1

Re: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Takashi Sakamoto]

On Aug 17 2017 19:05, Oleksandr Grytsov wrote:

So, from the above we think that period elapsed event derived in the described
ways may not improve latency and will complicate the system. So, for that
reason we are thinking of the option 2) (Positions of actual data transmission
in any serial sound interfaces of actual hardwares.)


Please declare the way to enable stuffs on DomU to get the positions 
from actual hardware.



Regards

Takashi Sakamoto

Re: [PATCH RESEND1 00/12] ALSA: vsnd: Add Xen para-virtualized frontend driver

[Takashi Sakamoto]

On Aug 17 2017 19:05, Oleksandr Grytsov wrote:

So, from the above we think that period elapsed event derived in the described
ways may not improve latency and will complicate the system. So, for that
reason we are thinking of the option 2) (Positions of actual data transmission
in any serial sound interfaces of actual hardwares.)


Please declare the way to enable stuffs on DomU to get the positions 
from actual hardware.



Regards

Takashi Sakamoto

32-bit powerpc, aty128fb: vmap allocation for size 135168 failed

[Meelis Roos]

I was trying 4.13.0-rc5-00075-gac9a40905a61 on my PowerMac G4 with 1G 
RAM and after some time of sddm respawning and X trying to restart, 
dmesg is full of messages about vmap allocation failures.

Maybe the aty128fb is leaking ROM allocations or something like that?

sddm has been crashing eearlier too but I have not investigated it yet, 
but right after reboot the messages are about ATI ROM contents:

Aug 17 23:53:57 pohl kernel: [ 2940.146546] aty128fb :00:10.0: Invalid PCI 
ROM header signature: expecting 0xaa55, got 0x
Aug 17 23:54:02 pohl kernel: [ 2944.804838] aty128fb :00:10.0: Invalid PCI 
ROM header signature: expecting 0xaa55, got 0x1110
Aug 17 23:54:06 pohl kernel: [ 2948.992457] sddm[14039]: unhandled signal 11 at 
0030 nip 0030 lr 0f55f858 code 30001

Then it changes to groups like this:
Aug 17 23:54:29 pohl kernel: [ 2971.514484] sddm[14093]: unhandled signal 11 at 
0090 nip 0090 lr 0f55f858 code 30001
Aug 17 23:54:30 pohl kernel: [ 2972.994486] aty128fb :00:10.0: Invalid PCI 
ROM header signature: expecting 0xaa55, got 0x
Aug 17 23:54:30 pohl kernel: [ 2973.040595] vmap allocation for size 3149824 
failed: use vmalloc= to increase size
Aug 17 23:54:33 pohl kernel: [ 2976.245220] aty128fb :00:10.0: Invalid PCI 
ROM header signature: expecting 0xaa55, got 0x
Aug 17 23:54:33 pohl kernel: [ 2976.295452] vmap allocation for size 3149824 
failed: use vmalloc= to increase size

And finally it becomes just vmalloc errors, no ATI ROM messages at all:

[32075.316981] sddm[14563]: unhandled signal 11 at 0050 nip 0050 lr 
0f55f858 code 30001
[32076.766965] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32076.788476] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32079.124735] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32079.146326] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32081.305352] sddm[14590]: unhandled signal 11 at 0050 nip 0050 lr 
0f55f858 code 30001
[32082.768060] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32082.789530] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32085.125847] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32085.147228] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32087.311193] sddm[14617]: unhandled signal 11 at 00430068 nip 00430068 lr 
0f55f858 code 30001
[32088.767983] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32088.789536] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32091.108732] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32091.130348] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32093.285222] sddm[14644]: unhandled signal 11 at 0050 nip 0050 lr 
0f55f858 code 30001
[32094.767678] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32094.789329] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32097.128241] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32097.149745] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32099.293082] sddm[14671]: unhandled signal 11 at 0030 nip 0030 lr 
0f55f858 code 30001
[32100.768030] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32100.789505] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32103.124223] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32103.145881] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size


# cat /proc/meminfo 
MemTotal:1031440 kB
MemFree:  135948 kB
MemAvailable: 889288 kB
Buffers:  215448 kB
Cached:   573780 kB
SwapCached:   44 kB
Active:   430480 kB
Inactive: 392416 kB
Active(anon):  14984 kB
Inactive(anon):92276 kB
Active(file): 415496 kB
Inactive(file):   300140 kB
Unevictable:   0 kB
Mlocked:   0 kB
HighTotal:262144 kB
HighFree:  22140 kB
LowTotal: 769296 kB
LowFree:  113808 kB
SwapTotal:848984 kB
SwapFree: 848464 kB
Dirty:   180 kB
Writeback: 0 kB
AnonPages: 33640 kB
Mapped:84392 kB
Shmem: 73592 kB
Slab:  66972 kB
SReclaimable:  54952 kB
SUnreclaim:12020 kB
KernelStack: 680 kB
PageTables: 1344 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 1364704 kB
Committed_AS: 351992 kB
VmallocTotal: 211808 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB



-- 
Meelis Roos (mr...@linux.ee)

32-bit powerpc, aty128fb: vmap allocation for size 135168 failed

[Meelis Roos]

I was trying 4.13.0-rc5-00075-gac9a40905a61 on my PowerMac G4 with 1G 
RAM and after some time of sddm respawning and X trying to restart, 
dmesg is full of messages about vmap allocation failures.

Maybe the aty128fb is leaking ROM allocations or something like that?

sddm has been crashing eearlier too but I have not investigated it yet, 
but right after reboot the messages are about ATI ROM contents:

Aug 17 23:53:57 pohl kernel: [ 2940.146546] aty128fb :00:10.0: Invalid PCI 
ROM header signature: expecting 0xaa55, got 0x
Aug 17 23:54:02 pohl kernel: [ 2944.804838] aty128fb :00:10.0: Invalid PCI 
ROM header signature: expecting 0xaa55, got 0x1110
Aug 17 23:54:06 pohl kernel: [ 2948.992457] sddm[14039]: unhandled signal 11 at 
0030 nip 0030 lr 0f55f858 code 30001

Then it changes to groups like this:
Aug 17 23:54:29 pohl kernel: [ 2971.514484] sddm[14093]: unhandled signal 11 at 
0090 nip 0090 lr 0f55f858 code 30001
Aug 17 23:54:30 pohl kernel: [ 2972.994486] aty128fb :00:10.0: Invalid PCI 
ROM header signature: expecting 0xaa55, got 0x
Aug 17 23:54:30 pohl kernel: [ 2973.040595] vmap allocation for size 3149824 
failed: use vmalloc= to increase size
Aug 17 23:54:33 pohl kernel: [ 2976.245220] aty128fb :00:10.0: Invalid PCI 
ROM header signature: expecting 0xaa55, got 0x
Aug 17 23:54:33 pohl kernel: [ 2976.295452] vmap allocation for size 3149824 
failed: use vmalloc= to increase size

And finally it becomes just vmalloc errors, no ATI ROM messages at all:

[32075.316981] sddm[14563]: unhandled signal 11 at 0050 nip 0050 lr 
0f55f858 code 30001
[32076.766965] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32076.788476] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32079.124735] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32079.146326] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32081.305352] sddm[14590]: unhandled signal 11 at 0050 nip 0050 lr 
0f55f858 code 30001
[32082.768060] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32082.789530] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32085.125847] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32085.147228] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32087.311193] sddm[14617]: unhandled signal 11 at 00430068 nip 00430068 lr 
0f55f858 code 30001
[32088.767983] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32088.789536] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32091.108732] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32091.130348] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32093.285222] sddm[14644]: unhandled signal 11 at 0050 nip 0050 lr 
0f55f858 code 30001
[32094.767678] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32094.789329] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32097.128241] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32097.149745] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32099.293082] sddm[14671]: unhandled signal 11 at 0030 nip 0030 lr 
0f55f858 code 30001
[32100.768030] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32100.789505] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size
[32103.124223] vmap allocation for size 135168 failed: use vmalloc= to 
increase size
[32103.145881] vmap allocation for size 3149824 failed: use vmalloc= to 
increase size


# cat /proc/meminfo 
MemTotal:1031440 kB
MemFree:  135948 kB
MemAvailable: 889288 kB
Buffers:  215448 kB
Cached:   573780 kB
SwapCached:   44 kB
Active:   430480 kB
Inactive: 392416 kB
Active(anon):  14984 kB
Inactive(anon):92276 kB
Active(file): 415496 kB
Inactive(file):   300140 kB
Unevictable:   0 kB
Mlocked:   0 kB
HighTotal:262144 kB
HighFree:  22140 kB
LowTotal: 769296 kB
LowFree:  113808 kB
SwapTotal:848984 kB
SwapFree: 848464 kB
Dirty:   180 kB
Writeback: 0 kB
AnonPages: 33640 kB
Mapped:84392 kB
Shmem: 73592 kB
Slab:  66972 kB
SReclaimable:  54952 kB
SUnreclaim:12020 kB
KernelStack: 680 kB
PageTables: 1344 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 1364704 kB
Committed_AS: 351992 kB
VmallocTotal: 211808 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB



-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH v6 0/2] Make find_later_rq() choose a closer cpu in topology

[Byungchul Park]

On Thu, Aug 17, 2017 at 09:51:34PM -0700, Joel Fernandes (Google) wrote:
> On Thu, Aug 17, 2017 at 6:25 PM, Byungchul Park  
> wrote:
> > On Mon, Aug 07, 2017 at 12:50:32PM +0900, Byungchul Park wrote:
> >> When cpudl_find() returns any among free_cpus, the cpu might not be
> >> closer than others, considering sched domain. For example:
> >>
> >>this_cpu: 15
> >>free_cpus: 0, 1,..., 14 (== later_mask)
> >>best_cpu: 0
> >>
> >>topology:
> >>
> >>0 --+
> >>+--+
> >>1 --+  |
> >>   +-- ... --+
> >>2 --+  | |
> >>+--+ |
> >>3 --+|
> >>
> >>... ...
> >>
> >>12 --+   |
> >> +--+|
> >>13 --+  ||
> >>+-- ... -+
> >>14 --+  |
> >> +--+
> >>15 --+
> >>
> >> In this case, it would be best to select 14 since it's a free cpu and
> >> closest to 15(this_cpu). However, currently the code select 0(best_cpu)
> >> even though that's just any among free_cpus. Fix it.
> >
> > Could you let me know your opinions about this?
> 
> Patch looks good to me, I would also add a comment ontop of
> fallback_cpu (I think Steve mentioned similar thing at [1])
> 
> /*
>  * fallback is the closest CPU in the closest SD incase
>  * all domains are PREFER_SIBLING
>  */
>  if (fallback_cpu == -1)
>  fallback_cpu = best_cpu;
> 
> And clarify this in the commit message.

Right. I will add it.

Thank you very much,
Byungchul

Re: [PATCH v6 0/2] Make find_later_rq() choose a closer cpu in topology

[Byungchul Park]

On Thu, Aug 17, 2017 at 09:51:34PM -0700, Joel Fernandes (Google) wrote:
> On Thu, Aug 17, 2017 at 6:25 PM, Byungchul Park  
> wrote:
> > On Mon, Aug 07, 2017 at 12:50:32PM +0900, Byungchul Park wrote:
> >> When cpudl_find() returns any among free_cpus, the cpu might not be
> >> closer than others, considering sched domain. For example:
> >>
> >>this_cpu: 15
> >>free_cpus: 0, 1,..., 14 (== later_mask)
> >>best_cpu: 0
> >>
> >>topology:
> >>
> >>0 --+
> >>+--+
> >>1 --+  |
> >>   +-- ... --+
> >>2 --+  | |
> >>+--+ |
> >>3 --+|
> >>
> >>... ...
> >>
> >>12 --+   |
> >> +--+|
> >>13 --+  ||
> >>+-- ... -+
> >>14 --+  |
> >> +--+
> >>15 --+
> >>
> >> In this case, it would be best to select 14 since it's a free cpu and
> >> closest to 15(this_cpu). However, currently the code select 0(best_cpu)
> >> even though that's just any among free_cpus. Fix it.
> >
> > Could you let me know your opinions about this?
> 
> Patch looks good to me, I would also add a comment ontop of
> fallback_cpu (I think Steve mentioned similar thing at [1])
> 
> /*
>  * fallback is the closest CPU in the closest SD incase
>  * all domains are PREFER_SIBLING
>  */
>  if (fallback_cpu == -1)
>  fallback_cpu = best_cpu;
> 
> And clarify this in the commit message.

Right. I will add it.

Thank you very much,
Byungchul

Re: [tip:locking/core] locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE part of CONFIG_PROVE_LOCKING

[Byungchul Park]

On Thu, Aug 17, 2017 at 12:45:44PM +0200, Ingo Molnar wrote:
> > @@ -1164,9 +1164,6 @@ config LOCKDEP_CROSSRELEASE
> >  
> >  config LOCKDEP_COMPLETE
> > bool "Lock debugging: allow completions to use deadlock detector"
> > -   depends on PROVE_LOCKING
> > -   select LOCKDEP_CROSSRELEASE
> > -   default n
> > help
> 
> Yeah, so I only noticed this after committing the patches, but this change 
> does 
> not make the option non-interactive. The way to do that is to remove the "" 
> help 
> text, i.e. make it a simple 'bool'.
> 
> I'll do that and re-push.

I am sorry for making it rather harder to be done.

Re: [tip:locking/core] locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE part of CONFIG_PROVE_LOCKING

[Byungchul Park]

On Thu, Aug 17, 2017 at 12:45:44PM +0200, Ingo Molnar wrote:
> > @@ -1164,9 +1164,6 @@ config LOCKDEP_CROSSRELEASE
> >  
> >  config LOCKDEP_COMPLETE
> > bool "Lock debugging: allow completions to use deadlock detector"
> > -   depends on PROVE_LOCKING
> > -   select LOCKDEP_CROSSRELEASE
> > -   default n
> > help
> 
> Yeah, so I only noticed this after committing the patches, but this change 
> does 
> not make the option non-interactive. The way to do that is to remove the "" 
> help 
> text, i.e. make it a simple 'bool'.
> 
> I'll do that and re-push.

I am sorry for making it rather harder to be done.

Re: [PATCH v4 0/4] Add Broadcom STB USB phy driver

[Florian Fainelli]

On 07/21/2017 07:10 AM, Al Cooper wrote:
> Add a new USB Phy driver for Broadcom STB SoCs. This driver
> supports Broadcom STB ARM SoCs. This driver in
> combination with the Broadcom STB ohci, ehci and xhci
> drivers will enable USB1.1, USB2.0 and USB3.0 support.
> This Phy driver also supports the Broadcom BDC gadget
> driver.

Kishon can we get some timely feedback on this please? Thanks

> 
> Changes since v3:
> - Removed MIPS support because there is such a small
>   amount of code that is common to both ARM and MIPS.
>   I'll create a separate MIPS driver in the future.
> - Have the Kconfig selection for this driver also select
>   "CONFIG_SOC_BRCMSTB" which contains needed functions.
> - Change device tree properties to use "brcm,has_xhci" and
>   "brcm,has_eohci" to determine if the phy contains
>   a xhci phy, and e/ohci phy or both.
> - Change the phy xlate routine to return an error instead
>   of NULL for a requested phy that doesn't exist.
> - Moved some probe functionality into it's own funtion to
>   simplify the many "if (has_xhci)" statements.
> 
> Changes since v2:
> - Fix kbuild errors by changing Kconfig so the driver
>   only builds for ARCH_BRCMSTB || BMIPS_GENERIC systems
> 
> Changes since v1:
> - Rebased to next
> - Add Kconfig entry to build the driver
> - Commented all delays
> - Split out sysfs functionality in separate patch
> - Removed parsing of old obselete device tree properties
> - Changed device property "device" to "dr_mode" using
>   standard values "host" and "peripheral" along with new
>   values "drd" and "typec-pd"
> - Add ability to handle the standard PHY_TYPE_USB2 and
>   PHY_TYPE_USB3 arguments passed in by phy consumers.
> - Moved phy_provider_register() to end of probe routine
> 
> Al Cooper (4):
>   soc: brcmstb: Add Product ID and Family ID helper functions
>   dt-bindings: Add Broadcom STB USB PHY binding document
>   phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver
>   phy: usb: phy-brcm-usb: Add ability to force DRD mode to host or
> device
> 
>  .../bindings/phy/brcm,brcmstb-usb-phy.txt  |   43 +
>  MAINTAINERS|7 +
>  drivers/phy/broadcom/Kconfig   |   13 +
>  drivers/phy/broadcom/Makefile  |3 +
>  drivers/phy/broadcom/phy-brcm-usb-init.c   | 1034 
> 
>  drivers/phy/broadcom/phy-brcm-usb-init.h   |   50 +
>  drivers/phy/broadcom/phy-brcm-usb.c|  460 +
>  drivers/soc/bcm/brcmstb/common.c   |   12 +
>  include/linux/soc/brcmstb/brcmstb.h|   10 +
>  9 files changed, 1632 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb-init.c
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb-init.h
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb.c
> 

-- 
Florian

Re: [PATCH v4 0/4] Add Broadcom STB USB phy driver

[Florian Fainelli]

On 07/21/2017 07:10 AM, Al Cooper wrote:
> Add a new USB Phy driver for Broadcom STB SoCs. This driver
> supports Broadcom STB ARM SoCs. This driver in
> combination with the Broadcom STB ohci, ehci and xhci
> drivers will enable USB1.1, USB2.0 and USB3.0 support.
> This Phy driver also supports the Broadcom BDC gadget
> driver.

Kishon can we get some timely feedback on this please? Thanks

> 
> Changes since v3:
> - Removed MIPS support because there is such a small
>   amount of code that is common to both ARM and MIPS.
>   I'll create a separate MIPS driver in the future.
> - Have the Kconfig selection for this driver also select
>   "CONFIG_SOC_BRCMSTB" which contains needed functions.
> - Change device tree properties to use "brcm,has_xhci" and
>   "brcm,has_eohci" to determine if the phy contains
>   a xhci phy, and e/ohci phy or both.
> - Change the phy xlate routine to return an error instead
>   of NULL for a requested phy that doesn't exist.
> - Moved some probe functionality into it's own funtion to
>   simplify the many "if (has_xhci)" statements.
> 
> Changes since v2:
> - Fix kbuild errors by changing Kconfig so the driver
>   only builds for ARCH_BRCMSTB || BMIPS_GENERIC systems
> 
> Changes since v1:
> - Rebased to next
> - Add Kconfig entry to build the driver
> - Commented all delays
> - Split out sysfs functionality in separate patch
> - Removed parsing of old obselete device tree properties
> - Changed device property "device" to "dr_mode" using
>   standard values "host" and "peripheral" along with new
>   values "drd" and "typec-pd"
> - Add ability to handle the standard PHY_TYPE_USB2 and
>   PHY_TYPE_USB3 arguments passed in by phy consumers.
> - Moved phy_provider_register() to end of probe routine
> 
> Al Cooper (4):
>   soc: brcmstb: Add Product ID and Family ID helper functions
>   dt-bindings: Add Broadcom STB USB PHY binding document
>   phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver
>   phy: usb: phy-brcm-usb: Add ability to force DRD mode to host or
> device
> 
>  .../bindings/phy/brcm,brcmstb-usb-phy.txt  |   43 +
>  MAINTAINERS|7 +
>  drivers/phy/broadcom/Kconfig   |   13 +
>  drivers/phy/broadcom/Makefile  |3 +
>  drivers/phy/broadcom/phy-brcm-usb-init.c   | 1034 
> 
>  drivers/phy/broadcom/phy-brcm-usb-init.h   |   50 +
>  drivers/phy/broadcom/phy-brcm-usb.c|  460 +
>  drivers/soc/bcm/brcmstb/common.c   |   12 +
>  include/linux/soc/brcmstb/brcmstb.h|   10 +
>  9 files changed, 1632 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb-init.c
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb-init.h
>  create mode 100644 drivers/phy/broadcom/phy-brcm-usb.c
> 

-- 
Florian

Re: [PATCH v2 15/16] dmaengine: bcm-sba-raid: Add debugfs support

[Anup Patel]

On Fri, Aug 18, 2017 at 10:56 AM, Vinod Koul  wrote:
> On Fri, Aug 18, 2017 at 10:33:54AM +0530, Anup Patel wrote:
>> On Thu, Aug 17, 2017 at 1:31 PM, Vinod Koul  wrote:
>> > On Tue, Aug 01, 2017 at 04:07:59PM +0530, Anup Patel wrote:
>> > why fail, debugfs should be an optional thingy, why would you want to fail 
>> > here?
>>
>> Yes, we are handling the case when debugfs is not available
>> and skipping debugfs gracefully.
>>
>> If debugfs is available then failure of debugfs_create_dir()
>> should be reported.
>
> reported yes, bailing out on that err no..

OK, I will put dev_err() instead of bailing out.

Regards,
Anup

Re: [PATCH v2 15/16] dmaengine: bcm-sba-raid: Add debugfs support

[Anup Patel]

On Fri, Aug 18, 2017 at 10:56 AM, Vinod Koul  wrote:
> On Fri, Aug 18, 2017 at 10:33:54AM +0530, Anup Patel wrote:
>> On Thu, Aug 17, 2017 at 1:31 PM, Vinod Koul  wrote:
>> > On Tue, Aug 01, 2017 at 04:07:59PM +0530, Anup Patel wrote:
>> > why fail, debugfs should be an optional thingy, why would you want to fail 
>> > here?
>>
>> Yes, we are handling the case when debugfs is not available
>> and skipping debugfs gracefully.
>>
>> If debugfs is available then failure of debugfs_create_dir()
>> should be reported.
>
> reported yes, bailing out on that err no..

OK, I will put dev_err() instead of bailing out.

Regards,
Anup

Re: Do we really need d_weak_revalidate???

[NeilBrown]

On Thu, Aug 17 2017, Ian Kent wrote:

> On 16/08/17 19:34, Jeff Layton wrote:
>> On Wed, 2017-08-16 at 12:43 +1000, NeilBrown wrote:
>>> On Mon, Aug 14 2017, Jeff Layton wrote:
>>>
 On Mon, 2017-08-14 at 09:36 +1000, NeilBrown wrote:
> On Fri, Aug 11 2017, Jeff Layton wrote:
>
>> On Fri, 2017-08-11 at 05:55 +, Trond Myklebust wrote:
>>> On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote:
 Funny story.  4.5 years ago we discarded the FS_REVAL_DOT superblock
 flag and introduced the d_weak_revalidate dentry operation instead.
 We duly removed the flag from NFS superblocks and NFSv4 superblocks,
 and added the new dentry operation to NFS dentries  but not to
 NFSv4
 dentries.

 And nobody noticed.

 Until today.

 A customer reports a situation where mount(,MS_REMOUNT,..) on an
 NFS
 filesystem hangs because the network has been deconfigured.  This
 makes
 perfect sense and I suggested a code change to fix the problem.
 However when a colleague was trying to reproduce the problem to
 validate
 the fix, he couldn't.  Then nor could I.

 The problem is trivially reproducible with NFSv3, and not at all with
 NFSv4.  The reason is the missing d_weak_revalidate.

 We could simply add d_weak_revalidate for NFSv4, but given that it
 has been missing for 4.5 years, and the only time anyone noticed was
 when the ommission resulted in a better user experience, I do wonder
 if
 we need to.  Can we just discard d_weak_revalidate?  What purpose
 does
 it serve?  I couldn't find one.

 Thanks,
 NeilBrown

 For reference, see
 Commit: ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a
 d_weak_revalidate dentry op")



 To reproduce the problem at home, on a system that uses systemd:
 1/ place (or find) a filesystem image in a file on an NFS filesystem.
 2/ mount the nfs filesystem with "noac" - choose v3 or v4
 3/ loop-mount the filesystem image read-only somewhere
 4/ reboot

 If you choose v4, the reboot will succeed, possibly after a 90second
 timeout.
 If you choose v3, the reboot will hang indefinitely in systemd-
 shutdown while
 remounting the nfs filesystem read-only.

 If you don't use "noac" it can still hang, but only if something
 slows
 down the reboot enough that attributes have timed out by the time
 that
 systemd-shutdown runs.  This happens for our customer.

 If the loop-mounted filesystem is not read-only, you get other
 problems.

 We really want systemd to figure out that the loop-mount needs to be
 unmounted first.  I have ideas concerning that, but it is messy.  But
 that isn't the only bug here.
>>>
>>> The main purpose of d_weak_revalidate() was to catch the issues that
>>> arise when someone changes the contents of the current working
>>> directory or its parent on the server. Since '.' and '..' are treated
>>> specially in the lookup code, they would not be revalidated without
>>> special treatment. That leads to issues when looking up files as
>>> ./ or ../, since the client won't detect that its
>>> dcache is stale until it tries to use the cached dentry+inode.
>>>
>>> The one thing that has changed since its introduction is, I believe,
>>> the ESTALE handling in the VFS layer. That might fix a lot of the
>>> dcache lookup bugs that were previously handled by d_weak_revalidate().
>>> I haven't done an audit to figure out if it actually can handle all of
>>> them.
>>>
>>
>> It may also be related to 8033426e6bdb2690d302872ac1e1fadaec1a5581:
>>
>> vfs: allow umount to handle mountpoints without revalidating them
>
> You say in the comment for that commit:
>
>  but there
> are cases where we do want to revalidate the root of the fs.
>
> Do you happen to remember what those cases are?
>

 Not exactly, but I _think_ I might have been assuming that we needed to
 ensure that the inode attrs on the root were up to date after the
 pathwalk.

 I think that was probably wrong. d_revalidate is really intended to
 ensure that the dentry in question still points to the same inode. In
 the case of the root of the mount though, we don't really care about the
 dentry on the server at all. We're attaching the root of the mount to an
 inode and don't care of the dentry name changes. If we do need to ensure
 the inode attrs are updated, we'll just revalidate them at that point.

>>
>> Possibly the fact that 

Re: Do we really need d_weak_revalidate???

[NeilBrown]

On Thu, Aug 17 2017, Ian Kent wrote:

> On 16/08/17 19:34, Jeff Layton wrote:
>> On Wed, 2017-08-16 at 12:43 +1000, NeilBrown wrote:
>>> On Mon, Aug 14 2017, Jeff Layton wrote:
>>>
 On Mon, 2017-08-14 at 09:36 +1000, NeilBrown wrote:
> On Fri, Aug 11 2017, Jeff Layton wrote:
>
>> On Fri, 2017-08-11 at 05:55 +, Trond Myklebust wrote:
>>> On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote:
 Funny story.  4.5 years ago we discarded the FS_REVAL_DOT superblock
 flag and introduced the d_weak_revalidate dentry operation instead.
 We duly removed the flag from NFS superblocks and NFSv4 superblocks,
 and added the new dentry operation to NFS dentries  but not to
 NFSv4
 dentries.

 And nobody noticed.

 Until today.

 A customer reports a situation where mount(,MS_REMOUNT,..) on an
 NFS
 filesystem hangs because the network has been deconfigured.  This
 makes
 perfect sense and I suggested a code change to fix the problem.
 However when a colleague was trying to reproduce the problem to
 validate
 the fix, he couldn't.  Then nor could I.

 The problem is trivially reproducible with NFSv3, and not at all with
 NFSv4.  The reason is the missing d_weak_revalidate.

 We could simply add d_weak_revalidate for NFSv4, but given that it
 has been missing for 4.5 years, and the only time anyone noticed was
 when the ommission resulted in a better user experience, I do wonder
 if
 we need to.  Can we just discard d_weak_revalidate?  What purpose
 does
 it serve?  I couldn't find one.

 Thanks,
 NeilBrown

 For reference, see
 Commit: ecf3d1f1aa74 ("vfs: kill FS_REVAL_DOT by adding a
 d_weak_revalidate dentry op")



 To reproduce the problem at home, on a system that uses systemd:
 1/ place (or find) a filesystem image in a file on an NFS filesystem.
 2/ mount the nfs filesystem with "noac" - choose v3 or v4
 3/ loop-mount the filesystem image read-only somewhere
 4/ reboot

 If you choose v4, the reboot will succeed, possibly after a 90second
 timeout.
 If you choose v3, the reboot will hang indefinitely in systemd-
 shutdown while
 remounting the nfs filesystem read-only.

 If you don't use "noac" it can still hang, but only if something
 slows
 down the reboot enough that attributes have timed out by the time
 that
 systemd-shutdown runs.  This happens for our customer.

 If the loop-mounted filesystem is not read-only, you get other
 problems.

 We really want systemd to figure out that the loop-mount needs to be
 unmounted first.  I have ideas concerning that, but it is messy.  But
 that isn't the only bug here.
>>>
>>> The main purpose of d_weak_revalidate() was to catch the issues that
>>> arise when someone changes the contents of the current working
>>> directory or its parent on the server. Since '.' and '..' are treated
>>> specially in the lookup code, they would not be revalidated without
>>> special treatment. That leads to issues when looking up files as
>>> ./ or ../, since the client won't detect that its
>>> dcache is stale until it tries to use the cached dentry+inode.
>>>
>>> The one thing that has changed since its introduction is, I believe,
>>> the ESTALE handling in the VFS layer. That might fix a lot of the
>>> dcache lookup bugs that were previously handled by d_weak_revalidate().
>>> I haven't done an audit to figure out if it actually can handle all of
>>> them.
>>>
>>
>> It may also be related to 8033426e6bdb2690d302872ac1e1fadaec1a5581:
>>
>> vfs: allow umount to handle mountpoints without revalidating them
>
> You say in the comment for that commit:
>
>  but there
> are cases where we do want to revalidate the root of the fs.
>
> Do you happen to remember what those cases are?
>

 Not exactly, but I _think_ I might have been assuming that we needed to
 ensure that the inode attrs on the root were up to date after the
 pathwalk.

 I think that was probably wrong. d_revalidate is really intended to
 ensure that the dentry in question still points to the same inode. In
 the case of the root of the mount though, we don't really care about the
 dentry on the server at all. We're attaching the root of the mount to an
 inode and don't care of the dentry name changes. If we do need to ensure
 the inode attrs are updated, we'll just revalidate them at that point.

>>
>> Possibly the fact that 

Re: [PATCH v2 15/16] dmaengine: bcm-sba-raid: Add debugfs support

[Vinod Koul]

On Fri, Aug 18, 2017 at 10:33:54AM +0530, Anup Patel wrote:
> On Thu, Aug 17, 2017 at 1:31 PM, Vinod Koul  wrote:
> > On Tue, Aug 01, 2017 at 04:07:59PM +0530, Anup Patel wrote:
> > why fail, debugfs should be an optional thingy, why would you want to fail 
> > here?
> 
> Yes, we are handling the case when debugfs is not available
> and skipping debugfs gracefully.
> 
> If debugfs is available then failure of debugfs_create_dir()
> should be reported.

reported yes, bailing out on that err no..

-- 
~Vinod

[PATCH v7 2/2] perf/core: add mux switch to skip to the current CPU's events list on mux interrupt

[Alexey Budankov]

This patch implements mux switch that triggers skipping to the 
current CPU's events list at mulitplexing hrtimer interrupt 
handler as well as adoption of the switch in the existing 
implementation.

perf_event_groups_iterate_cpu() API is introduced to implement 
iteration thru the certain CPU groups list skipping groups 
allocated for the other CPUs.

Signed-off-by: Alexey Budankov 
---
 kernel/events/core.c | 193 ---
 1 file changed, 137 insertions(+), 56 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 08ccfb2..aeb0f81 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -556,11 +556,11 @@ void perf_sample_event_took(u64 sample_len_ns)
 static atomic64_t perf_event_id;
 
 static void cpu_ctx_sched_out(struct perf_cpu_context *cpuctx,
- enum event_type_t event_type);
+ enum event_type_t event_type, int mux);
 
 static void cpu_ctx_sched_in(struct perf_cpu_context *cpuctx,
 enum event_type_t event_type,
-struct task_struct *task);
+struct task_struct *task, int mux);
 
 static void update_context_time(struct perf_event_context *ctx);
 static u64 perf_event_time(struct perf_event *event);
@@ -702,6 +702,7 @@ static void perf_cgroup_switch(struct task_struct *task, 
int mode)
struct perf_cpu_context *cpuctx;
struct list_head *list;
unsigned long flags;
+   int mux = 0;
 
/*
 * Disable interrupts and preemption to avoid this CPU's
@@ -717,7 +718,7 @@ static void perf_cgroup_switch(struct task_struct *task, 
int mode)
perf_pmu_disable(cpuctx->ctx.pmu);
 
if (mode & PERF_CGROUP_SWOUT) {
-   cpu_ctx_sched_out(cpuctx, EVENT_ALL);
+   cpu_ctx_sched_out(cpuctx, EVENT_ALL, mux);
/*
 * must not be done before ctxswout due
 * to event_filter_match() in event_sched_out()
@@ -736,7 +737,7 @@ static void perf_cgroup_switch(struct task_struct *task, 
int mode)
 */
cpuctx->cgrp = perf_cgroup_from_task(task,
 >ctx);
-   cpu_ctx_sched_in(cpuctx, EVENT_ALL, task);
+   cpu_ctx_sched_in(cpuctx, EVENT_ALL, task, mux);
}
perf_pmu_enable(cpuctx->ctx.pmu);
perf_ctx_unlock(cpuctx, cpuctx->task_ctx);
@@ -1613,8 +1614,16 @@ perf_event_groups_rotate(struct rb_root *groups, int cpu)
  */
 #define perf_event_groups_for_each(event, iter, tree, node, list, link) \
   for (iter = rb_first(tree); iter; iter = rb_next(iter))  \
-   list_for_each_entry(event, &(rb_entry(iter, \
-   typeof(*event), node)->list), link)
+   list_for_each_entry(event, &(rb_entry(iter, \
+   typeof(*event), node)->list), link)
+
+/*
+ * Iterate event groups related to specific cpu.
+ */
+#define perf_event_groups_for_each_cpu(event, cpu, tree, list, link)   \
+   list = perf_event_groups_get_list(tree, cpu);   \
+   if (list)   \
+   list_for_each_entry(event, list, link)
 
 /*
  * Add a event from the lists for its context.
@@ -2397,36 +2406,38 @@ static void add_event_to_ctx(struct perf_event *event,
 
 static void ctx_sched_out(struct perf_event_context *ctx,
  struct perf_cpu_context *cpuctx,
- enum event_type_t event_type);
+ enum event_type_t event_type, int mux);
 static void
 ctx_sched_in(struct perf_event_context *ctx,
 struct perf_cpu_context *cpuctx,
 enum event_type_t event_type,
-struct task_struct *task);
+struct task_struct *task, int mux);
 
 static void task_ctx_sched_out(struct perf_cpu_context *cpuctx,
   struct perf_event_context *ctx,
   enum event_type_t event_type)
 {
+   int mux = 0;
+
if (!cpuctx->task_ctx)
return;
 
if (WARN_ON_ONCE(ctx != cpuctx->task_ctx))
return;
 
-   ctx_sched_out(ctx, cpuctx, event_type);
+   ctx_sched_out(ctx, cpuctx, event_type, mux);
 }
 
 static void perf_event_sched_in(struct perf_cpu_context *cpuctx,
struct perf_event_context *ctx,
-   struct task_struct *task)
+   struct task_struct *task, int mux)
 {
-   cpu_ctx_sched_in(cpuctx, EVENT_PINNED, task);
+   cpu_ctx_sched_in(cpuctx, EVENT_PINNED, task, mux);
if (ctx)
-   

Re: [PATCH v2 15/16] dmaengine: bcm-sba-raid: Add debugfs support

[Vinod Koul]

On Fri, Aug 18, 2017 at 10:33:54AM +0530, Anup Patel wrote:
> On Thu, Aug 17, 2017 at 1:31 PM, Vinod Koul  wrote:
> > On Tue, Aug 01, 2017 at 04:07:59PM +0530, Anup Patel wrote:
> > why fail, debugfs should be an optional thingy, why would you want to fail 
> > here?
> 
> Yes, we are handling the case when debugfs is not available
> and skipping debugfs gracefully.
> 
> If debugfs is available then failure of debugfs_create_dir()
> should be reported.

reported yes, bailing out on that err no..

-- 
~Vinod

[PATCH v7 2/2] perf/core: add mux switch to skip to the current CPU's events list on mux interrupt

[Alexey Budankov]

This patch implements mux switch that triggers skipping to the 
current CPU's events list at mulitplexing hrtimer interrupt 
handler as well as adoption of the switch in the existing 
implementation.

perf_event_groups_iterate_cpu() API is introduced to implement 
iteration thru the certain CPU groups list skipping groups 
allocated for the other CPUs.

Signed-off-by: Alexey Budankov 
---
 kernel/events/core.c | 193 ---
 1 file changed, 137 insertions(+), 56 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 08ccfb2..aeb0f81 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -556,11 +556,11 @@ void perf_sample_event_took(u64 sample_len_ns)
 static atomic64_t perf_event_id;
 
 static void cpu_ctx_sched_out(struct perf_cpu_context *cpuctx,
- enum event_type_t event_type);
+ enum event_type_t event_type, int mux);
 
 static void cpu_ctx_sched_in(struct perf_cpu_context *cpuctx,
 enum event_type_t event_type,
-struct task_struct *task);
+struct task_struct *task, int mux);
 
 static void update_context_time(struct perf_event_context *ctx);
 static u64 perf_event_time(struct perf_event *event);
@@ -702,6 +702,7 @@ static void perf_cgroup_switch(struct task_struct *task, 
int mode)
struct perf_cpu_context *cpuctx;
struct list_head *list;
unsigned long flags;
+   int mux = 0;
 
/*
 * Disable interrupts and preemption to avoid this CPU's
@@ -717,7 +718,7 @@ static void perf_cgroup_switch(struct task_struct *task, 
int mode)
perf_pmu_disable(cpuctx->ctx.pmu);
 
if (mode & PERF_CGROUP_SWOUT) {
-   cpu_ctx_sched_out(cpuctx, EVENT_ALL);
+   cpu_ctx_sched_out(cpuctx, EVENT_ALL, mux);
/*
 * must not be done before ctxswout due
 * to event_filter_match() in event_sched_out()
@@ -736,7 +737,7 @@ static void perf_cgroup_switch(struct task_struct *task, 
int mode)
 */
cpuctx->cgrp = perf_cgroup_from_task(task,
 >ctx);
-   cpu_ctx_sched_in(cpuctx, EVENT_ALL, task);
+   cpu_ctx_sched_in(cpuctx, EVENT_ALL, task, mux);
}
perf_pmu_enable(cpuctx->ctx.pmu);
perf_ctx_unlock(cpuctx, cpuctx->task_ctx);
@@ -1613,8 +1614,16 @@ perf_event_groups_rotate(struct rb_root *groups, int cpu)
  */
 #define perf_event_groups_for_each(event, iter, tree, node, list, link) \
   for (iter = rb_first(tree); iter; iter = rb_next(iter))  \
-   list_for_each_entry(event, &(rb_entry(iter, \
-   typeof(*event), node)->list), link)
+   list_for_each_entry(event, &(rb_entry(iter, \
+   typeof(*event), node)->list), link)
+
+/*
+ * Iterate event groups related to specific cpu.
+ */
+#define perf_event_groups_for_each_cpu(event, cpu, tree, list, link)   \
+   list = perf_event_groups_get_list(tree, cpu);   \
+   if (list)   \
+   list_for_each_entry(event, list, link)
 
 /*
  * Add a event from the lists for its context.
@@ -2397,36 +2406,38 @@ static void add_event_to_ctx(struct perf_event *event,
 
 static void ctx_sched_out(struct perf_event_context *ctx,
  struct perf_cpu_context *cpuctx,
- enum event_type_t event_type);
+ enum event_type_t event_type, int mux);
 static void
 ctx_sched_in(struct perf_event_context *ctx,
 struct perf_cpu_context *cpuctx,
 enum event_type_t event_type,
-struct task_struct *task);
+struct task_struct *task, int mux);
 
 static void task_ctx_sched_out(struct perf_cpu_context *cpuctx,
   struct perf_event_context *ctx,
   enum event_type_t event_type)
 {
+   int mux = 0;
+
if (!cpuctx->task_ctx)
return;
 
if (WARN_ON_ONCE(ctx != cpuctx->task_ctx))
return;
 
-   ctx_sched_out(ctx, cpuctx, event_type);
+   ctx_sched_out(ctx, cpuctx, event_type, mux);
 }
 
 static void perf_event_sched_in(struct perf_cpu_context *cpuctx,
struct perf_event_context *ctx,
-   struct task_struct *task)
+   struct task_struct *task, int mux)
 {
-   cpu_ctx_sched_in(cpuctx, EVENT_PINNED, task);
+   cpu_ctx_sched_in(cpuctx, EVENT_PINNED, task, mux);
if (ctx)
-   ctx_sched_in(ctx, cpuctx, EVENT_PINNED, task);

Re: [PATCH v2 03/16] dmaengine: bcm-sba-raid: Common flags for sba_request state and fence

[Vinod Koul]

On Fri, Aug 18, 2017 at 10:26:54AM +0530, Anup Patel wrote:
> On Thu, Aug 17, 2017 at 9:15 AM, Vinod Koul  wrote:
> > On Tue, Aug 01, 2017 at 04:07:47PM +0530, Anup Patel wrote:
> >> This patch merges sba_request state and fence into common
> >> sba_request flags. Also, in-future we can extend sba_request
> >> flags as required.
> >
> > and it also changes the flag values to bits, which I have no idea why that
> > was done, care to explain that please...
> 
> I thought its better to have separate bit each sba_request state so
> that when a sba_request is accidentally in two states then we can
> debug better.

that is fine, but you need to comminucate the motivation behind such a
change!!

> 
> I will restore state values.

either ways am okay, but if we are not using bits smartly then why to change

-- 
~Vinod

Re: [PATCH v2 03/16] dmaengine: bcm-sba-raid: Common flags for sba_request state and fence

[Vinod Koul]

On Fri, Aug 18, 2017 at 10:26:54AM +0530, Anup Patel wrote:
> On Thu, Aug 17, 2017 at 9:15 AM, Vinod Koul  wrote:
> > On Tue, Aug 01, 2017 at 04:07:47PM +0530, Anup Patel wrote:
> >> This patch merges sba_request state and fence into common
> >> sba_request flags. Also, in-future we can extend sba_request
> >> flags as required.
> >
> > and it also changes the flag values to bits, which I have no idea why that
> > was done, care to explain that please...
> 
> I thought its better to have separate bit each sba_request state so
> that when a sba_request is accidentally in two states then we can
> debug better.

that is fine, but you need to comminucate the motivation behind such a
change!!

> 
> I will restore state values.

either ways am okay, but if we are not using bits smartly then why to change

-- 
~Vinod

[PATCH 3/5] mmc: sdhci-msm: Add support to wait for power irq

[Vijay Viswanath]

From: Sahitya Tummala 

Add support API which will check if power irq is expected to be
generated and wait for the power irq to come and complete if the irq is
expected.

Signed-off-by: Sahitya Tummala 
Signed-off-by: Vijay Viswanath 
---
 drivers/mmc/host/sdhci-msm.c | 125 ++-
 1 file changed, 123 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index f3e0489..6d3b1fd 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -123,6 +123,10 @@
 #define CMUX_SHIFT_PHASE_MASK  (7 << CMUX_SHIFT_PHASE_SHIFT)
 
 #define MSM_MMC_AUTOSUSPEND_DELAY_MS   50
+
+/* Timeout value to avoid infinite waiting for pwr_irq */
+#define MSM_PWR_IRQ_TIMEOUT_MS 5000
+
 struct sdhci_msm_host {
struct platform_device *pdev;
void __iomem *core_mem; /* MSM SDCC mapped address */
@@ -138,6 +142,11 @@ struct sdhci_msm_host {
bool calibration_done;
u8 saved_tuning_phase;
bool use_cdclp533;
+   u32 curr_pwr_state;
+   u32 curr_io_level;
+#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
+   struct completion pwr_irq_completion;
+#endif
 };
 
 static unsigned int msm_get_clock_rate_for_bus_mode(struct sdhci_host *host,
@@ -995,6 +1004,90 @@ static void sdhci_msm_set_uhs_signaling(struct sdhci_host 
*host,
sdhci_msm_hs400(host, >ios);
 }
 
+#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
+static inline void sdhci_msm_init_pwr_irq_completion(
+   struct sdhci_msm_host *msm_host)
+{
+   init_completion(_host->pwr_irq_completion);
+}
+
+static inline void sdhci_msm_complete_pwr_irq_completion(
+   struct sdhci_msm_host *msm_host)
+{
+   complete(_host->pwr_irq_completion);
+}
+
+/*
+ * sdhci_msm_check_power_status API should be called when registers writes
+ * which can toggle sdhci IO bus ON/OFF or change IO lines HIGH/LOW happens.
+ * To what state the register writes will change the IO lines should be passed
+ * as the argument req_type. This API will check whether the IO line's state
+ * is already the expected state and will wait for power irq only if
+ * power irq is expected to be trigerred based on the current IO line state
+ * and expected IO line state.
+ */
+static void sdhci_msm_check_power_status(struct sdhci_host *host, u32 req_type)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+   unsigned long flags;
+   bool done = false;
+
+   spin_lock_irqsave(>lock, flags);
+   pr_debug("%s: %s: request %d curr_pwr_state %x curr_io_level %x\n",
+   mmc_hostname(host->mmc), __func__, req_type,
+   msm_host->curr_pwr_state, msm_host->curr_io_level);
+
+   /*
+* The IRQ for request type IO High/LOW will be generated when -
+* there is a state change in 1.8V enable bit (bit 3) of
+* SDHCI_HOST_CONTROL2 register. The reset state of that bit is 0
+* which indicates 3.3V IO voltage. So, when MMC core layer tries
+* to set it to 3.3V before card detection happens, the
+* IRQ doesn't get triggered as there is no state change in this bit.
+* The driver already handles this case by changing the IO voltage
+* level to high as part of controller power up sequence. Hence, check
+* for host->pwr to handle a case where IO voltage high request is
+* issued even before controller power up.
+*/
+   if ((req_type & REQ_IO_HIGH) && !host->pwr) {
+   pr_debug("%s: do not wait for power IRQ that never comes\n",
+   mmc_hostname(host->mmc));
+   spin_unlock_irqrestore(>lock, flags);
+   return;
+   }
+   if ((req_type & msm_host->curr_pwr_state) ||
+   (req_type & msm_host->curr_io_level))
+   done = true;
+   spin_unlock_irqrestore(>lock, flags);
+   /*
+* This is needed here to hanlde a case where IRQ gets
+* triggered even before this function is called so that
+* x->done counter of completion gets reset. Otherwise,
+* next call to wait_for_completion returns immediately
+* without actually waiting for the IRQ to be handled.
+*/
+   if (done)
+   init_completion(_host->pwr_irq_completion);
+   else if (!wait_for_completion_timeout(_host->pwr_irq_completion,
+   msecs_to_jiffies(MSM_PWR_IRQ_TIMEOUT_MS)))
+   __WARN_printf("%s: request(%d) timed out waiting for pwr_irq\n",
+   mmc_hostname(host->mmc), req_type);
+   pr_debug("%s: %s: request %d done\n", mmc_hostname(host->mmc),
+   __func__, req_type);
+}
+#else
+static inline void sdhci_msm_init_pwr_irq_completion(
+   struct 

[PATCH v7 1/2] perf/core: use rb trees for pinned/flexible groups

[Alexey Budankov]

This patch moves event groups into rb tree sorted by CPU, so that 
multiplexing hrtimer interrupt handler would be able skipping to the current 
CPU's list and ignore groups allocated for the other CPUs.

New API for manipulating event groups in the trees is implemented as well 
as adoption on the API in the current implementation.

Signed-off-by: Alexey Budankov 
---
 include/linux/perf_event.h |  19 ++-
 kernel/events/core.c   | 314 +
 2 files changed, 249 insertions(+), 84 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index b14095b..cc07904 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -572,7 +572,20 @@ struct perf_event {
 */
struct list_headgroup_entry;
struct list_headsibling_list;
-
+   /*
+* Node on the pinned or flexible tree located at the event context;
+* the node may be empty in case its event is not directly attached
+* to the tree but to group_list list of the event directly
+* attached to the tree;
+*/
+   struct rb_node  group_node;
+   /*
+* List keeps groups allocated for the same cpu;
+* the list may be empty in case its event is not directly
+* attached to the tree but to group_list list of the event directly
+* attached to the tree;
+*/
+   struct list_headgroup_list;
/*
 * We need storage to track the entries in perf_pmu_migrate_context; we
 * cannot use the event_entry because of RCU and we want to keep the
@@ -741,8 +754,8 @@ struct perf_event_context {
struct mutexmutex;
 
struct list_headactive_ctx_list;
-   struct list_headpinned_groups;
-   struct list_headflexible_groups;
+   struct rb_root  pinned_groups;
+   struct rb_root  flexible_groups;
struct list_headevent_list;
int nr_events;
int nr_active;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index d704e23..08ccfb2 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1466,8 +1466,12 @@ static enum event_type_t get_event_type(struct 
perf_event *event)
return event_type;
 }
 
-static struct list_head *
-ctx_group_list(struct perf_event *event, struct perf_event_context *ctx)
+/*
+ * Extract pinned or flexible groups from the context
+ * based on event attrs bits;
+ */
+static struct rb_root *
+get_event_groups(struct perf_event *event, struct perf_event_context *ctx)
 {
if (event->attr.pinned)
return >pinned_groups;
@@ -1476,6 +1480,143 @@ ctx_group_list(struct perf_event *event, struct 
perf_event_context *ctx)
 }
 
 /*
+ * Insert a group into a tree using event->cpu as a key. If event->cpu node
+ * is already attached to the tree then the event is added to the attached
+ * group's group_list list.
+ */
+static void
+perf_event_groups_insert(struct rb_root *groups, struct perf_event *event)
+{
+   struct perf_event *node_event;
+   struct rb_node *parent;
+   struct rb_node **node;
+
+   node = >rb_node;
+   parent = *node;
+
+   while (*node) {
+   parent = *node;
+   node_event = container_of(*node,
+   struct perf_event, group_node);
+
+   if (event->cpu < node_event->cpu) {
+   node = >rb_left;
+   } else if (event->cpu > node_event->cpu) {
+   node = >rb_right;
+   } else {
+   list_add_tail(>group_entry,
+   _event->group_list);
+   return;
+   }
+   }
+
+   list_add_tail(>group_entry, >group_list);
+
+   rb_link_node(>group_node, parent, node);
+   rb_insert_color(>group_node, groups);
+}
+
+/*
+ * Helper function to insert event into the pinned or
+ * flexible groups;
+ */
+static void
+add_event_to_groups(struct perf_event *event, struct perf_event_context *ctx)
+{
+   struct rb_root *groups;
+
+   groups = get_event_groups(event, ctx);
+   perf_event_groups_insert(groups, event);
+}
+
+/*
+ * Delete a group from a tree. If the group is directly attached to the tree
+ * it is replaced by the next group on the group's group_list.
+ */
+static void
+perf_event_groups_delete(struct rb_root *groups, struct perf_event *event)
+{
+   list_del_init(>group_entry);
+
+   if (!RB_EMPTY_NODE(>group_node)) {
+   if (!RB_EMPTY_ROOT(groups)) {
+   if (list_empty(>group_list)) {
+   rb_erase(>group_node, groups);
+   } else {
+

[PATCH 3/5] mmc: sdhci-msm: Add support to wait for power irq

[Vijay Viswanath]

From: Sahitya Tummala 

Add support API which will check if power irq is expected to be
generated and wait for the power irq to come and complete if the irq is
expected.

Signed-off-by: Sahitya Tummala 
Signed-off-by: Vijay Viswanath 
---
 drivers/mmc/host/sdhci-msm.c | 125 ++-
 1 file changed, 123 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index f3e0489..6d3b1fd 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -123,6 +123,10 @@
 #define CMUX_SHIFT_PHASE_MASK  (7 << CMUX_SHIFT_PHASE_SHIFT)
 
 #define MSM_MMC_AUTOSUSPEND_DELAY_MS   50
+
+/* Timeout value to avoid infinite waiting for pwr_irq */
+#define MSM_PWR_IRQ_TIMEOUT_MS 5000
+
 struct sdhci_msm_host {
struct platform_device *pdev;
void __iomem *core_mem; /* MSM SDCC mapped address */
@@ -138,6 +142,11 @@ struct sdhci_msm_host {
bool calibration_done;
u8 saved_tuning_phase;
bool use_cdclp533;
+   u32 curr_pwr_state;
+   u32 curr_io_level;
+#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
+   struct completion pwr_irq_completion;
+#endif
 };
 
 static unsigned int msm_get_clock_rate_for_bus_mode(struct sdhci_host *host,
@@ -995,6 +1004,90 @@ static void sdhci_msm_set_uhs_signaling(struct sdhci_host 
*host,
sdhci_msm_hs400(host, >ios);
 }
 
+#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
+static inline void sdhci_msm_init_pwr_irq_completion(
+   struct sdhci_msm_host *msm_host)
+{
+   init_completion(_host->pwr_irq_completion);
+}
+
+static inline void sdhci_msm_complete_pwr_irq_completion(
+   struct sdhci_msm_host *msm_host)
+{
+   complete(_host->pwr_irq_completion);
+}
+
+/*
+ * sdhci_msm_check_power_status API should be called when registers writes
+ * which can toggle sdhci IO bus ON/OFF or change IO lines HIGH/LOW happens.
+ * To what state the register writes will change the IO lines should be passed
+ * as the argument req_type. This API will check whether the IO line's state
+ * is already the expected state and will wait for power irq only if
+ * power irq is expected to be trigerred based on the current IO line state
+ * and expected IO line state.
+ */
+static void sdhci_msm_check_power_status(struct sdhci_host *host, u32 req_type)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+   unsigned long flags;
+   bool done = false;
+
+   spin_lock_irqsave(>lock, flags);
+   pr_debug("%s: %s: request %d curr_pwr_state %x curr_io_level %x\n",
+   mmc_hostname(host->mmc), __func__, req_type,
+   msm_host->curr_pwr_state, msm_host->curr_io_level);
+
+   /*
+* The IRQ for request type IO High/LOW will be generated when -
+* there is a state change in 1.8V enable bit (bit 3) of
+* SDHCI_HOST_CONTROL2 register. The reset state of that bit is 0
+* which indicates 3.3V IO voltage. So, when MMC core layer tries
+* to set it to 3.3V before card detection happens, the
+* IRQ doesn't get triggered as there is no state change in this bit.
+* The driver already handles this case by changing the IO voltage
+* level to high as part of controller power up sequence. Hence, check
+* for host->pwr to handle a case where IO voltage high request is
+* issued even before controller power up.
+*/
+   if ((req_type & REQ_IO_HIGH) && !host->pwr) {
+   pr_debug("%s: do not wait for power IRQ that never comes\n",
+   mmc_hostname(host->mmc));
+   spin_unlock_irqrestore(>lock, flags);
+   return;
+   }
+   if ((req_type & msm_host->curr_pwr_state) ||
+   (req_type & msm_host->curr_io_level))
+   done = true;
+   spin_unlock_irqrestore(>lock, flags);
+   /*
+* This is needed here to hanlde a case where IRQ gets
+* triggered even before this function is called so that
+* x->done counter of completion gets reset. Otherwise,
+* next call to wait_for_completion returns immediately
+* without actually waiting for the IRQ to be handled.
+*/
+   if (done)
+   init_completion(_host->pwr_irq_completion);
+   else if (!wait_for_completion_timeout(_host->pwr_irq_completion,
+   msecs_to_jiffies(MSM_PWR_IRQ_TIMEOUT_MS)))
+   __WARN_printf("%s: request(%d) timed out waiting for pwr_irq\n",
+   mmc_hostname(host->mmc), req_type);
+   pr_debug("%s: %s: request %d done\n", mmc_hostname(host->mmc),
+   __func__, req_type);
+}
+#else
+static inline void sdhci_msm_init_pwr_irq_completion(
+   struct sdhci_msm_host *msm_host)
+{
+}
+
+static inline void 

[PATCH v7 1/2] perf/core: use rb trees for pinned/flexible groups

[Alexey Budankov]

This patch moves event groups into rb tree sorted by CPU, so that 
multiplexing hrtimer interrupt handler would be able skipping to the current 
CPU's list and ignore groups allocated for the other CPUs.

New API for manipulating event groups in the trees is implemented as well 
as adoption on the API in the current implementation.

Signed-off-by: Alexey Budankov 
---
 include/linux/perf_event.h |  19 ++-
 kernel/events/core.c   | 314 +
 2 files changed, 249 insertions(+), 84 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index b14095b..cc07904 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -572,7 +572,20 @@ struct perf_event {
 */
struct list_headgroup_entry;
struct list_headsibling_list;
-
+   /*
+* Node on the pinned or flexible tree located at the event context;
+* the node may be empty in case its event is not directly attached
+* to the tree but to group_list list of the event directly
+* attached to the tree;
+*/
+   struct rb_node  group_node;
+   /*
+* List keeps groups allocated for the same cpu;
+* the list may be empty in case its event is not directly
+* attached to the tree but to group_list list of the event directly
+* attached to the tree;
+*/
+   struct list_headgroup_list;
/*
 * We need storage to track the entries in perf_pmu_migrate_context; we
 * cannot use the event_entry because of RCU and we want to keep the
@@ -741,8 +754,8 @@ struct perf_event_context {
struct mutexmutex;
 
struct list_headactive_ctx_list;
-   struct list_headpinned_groups;
-   struct list_headflexible_groups;
+   struct rb_root  pinned_groups;
+   struct rb_root  flexible_groups;
struct list_headevent_list;
int nr_events;
int nr_active;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index d704e23..08ccfb2 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1466,8 +1466,12 @@ static enum event_type_t get_event_type(struct 
perf_event *event)
return event_type;
 }
 
-static struct list_head *
-ctx_group_list(struct perf_event *event, struct perf_event_context *ctx)
+/*
+ * Extract pinned or flexible groups from the context
+ * based on event attrs bits;
+ */
+static struct rb_root *
+get_event_groups(struct perf_event *event, struct perf_event_context *ctx)
 {
if (event->attr.pinned)
return >pinned_groups;
@@ -1476,6 +1480,143 @@ ctx_group_list(struct perf_event *event, struct 
perf_event_context *ctx)
 }
 
 /*
+ * Insert a group into a tree using event->cpu as a key. If event->cpu node
+ * is already attached to the tree then the event is added to the attached
+ * group's group_list list.
+ */
+static void
+perf_event_groups_insert(struct rb_root *groups, struct perf_event *event)
+{
+   struct perf_event *node_event;
+   struct rb_node *parent;
+   struct rb_node **node;
+
+   node = >rb_node;
+   parent = *node;
+
+   while (*node) {
+   parent = *node;
+   node_event = container_of(*node,
+   struct perf_event, group_node);
+
+   if (event->cpu < node_event->cpu) {
+   node = >rb_left;
+   } else if (event->cpu > node_event->cpu) {
+   node = >rb_right;
+   } else {
+   list_add_tail(>group_entry,
+   _event->group_list);
+   return;
+   }
+   }
+
+   list_add_tail(>group_entry, >group_list);
+
+   rb_link_node(>group_node, parent, node);
+   rb_insert_color(>group_node, groups);
+}
+
+/*
+ * Helper function to insert event into the pinned or
+ * flexible groups;
+ */
+static void
+add_event_to_groups(struct perf_event *event, struct perf_event_context *ctx)
+{
+   struct rb_root *groups;
+
+   groups = get_event_groups(event, ctx);
+   perf_event_groups_insert(groups, event);
+}
+
+/*
+ * Delete a group from a tree. If the group is directly attached to the tree
+ * it is replaced by the next group on the group's group_list.
+ */
+static void
+perf_event_groups_delete(struct rb_root *groups, struct perf_event *event)
+{
+   list_del_init(>group_entry);
+
+   if (!RB_EMPTY_NODE(>group_node)) {
+   if (!RB_EMPTY_ROOT(groups)) {
+   if (list_empty(>group_list)) {
+   rb_erase(>group_node, groups);
+   } else {
+   struct perf_event *next =
+   

[PATCH 4/5] mmc: sdhci-msm: Add ops to do sdhc register write

[Vijay Viswanath]

Register writes which change voltage of IO lines or turn the IO bus
on/off require controller to be ready before progressing further. When
the controller is ready, it will generate a power irq which needs to be
handled. The thread which initiated the register write should wait for
power irq to complete. This will be done through the new sdhc msm write
APIs which will check whether the particular write can trigger a power
irq and wait for it with a timeout if it is expected.
The SDHC core power control IRQ gets triggered when -
* There is a state change in power control bit (bit 0)
  of SDHCI_POWER_CONTROL register.
* There is a state change in 1.8V enable bit (bit 3) of
  SDHCI_HOST_CONTROL2 register.
* Bit 1 of SDHCI_SOFTWARE_RESET is set.

Signed-off-by: Vijay Viswanath 
---
 drivers/mmc/host/sdhci-msm.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 6d3b1fd..6571880 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1250,6 +1250,41 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
__sdhci_msm_set_clock(host, clock);
 }
 
+#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
+static void __sdhci_msm_check_write(struct sdhci_host *host, u16 val, int reg)
+{
+   u32 req_type = 0;
+
+   switch (reg) {
+   case SDHCI_HOST_CONTROL2:
+   req_type = (val & SDHCI_CTRL_VDD_180) ? REQ_IO_LOW :
+   REQ_IO_HIGH;
+   break;
+   case SDHCI_SOFTWARE_RESET:
+   if (host->pwr && (val & SDHCI_RESET_ALL))
+   req_type = REQ_BUS_OFF;
+   break;
+   case SDHCI_POWER_CONTROL:
+   req_type = !val ? REQ_BUS_OFF : REQ_BUS_ON;
+   break;
+   }
+
+   if (req_type)
+   sdhci_msm_check_power_status(host, req_type);
+}
+
+static void sdhci_msm_writew(struct sdhci_host *host, u16 val, int reg)
+{
+   writew_relaxed(val, host->ioaddr + reg);
+   __sdhci_msm_check_write(host, val, reg);
+}
+
+static void sdhci_msm_writeb(struct sdhci_host *host, u8 val, int reg)
+{
+   writeb_relaxed(val, host->ioaddr + reg);
+   __sdhci_msm_check_write(host, val, reg);
+}
+#endif
 static const struct of_device_id sdhci_msm_dt_match[] = {
{ .compatible = "qcom,sdhci-msm-v4" },
{},
@@ -1264,6 +1299,10 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
.get_max_clock = sdhci_msm_get_max_clock,
.set_bus_width = sdhci_set_bus_width,
.set_uhs_signaling = sdhci_msm_set_uhs_signaling,
+#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
+   .write_w = sdhci_msm_writew,
+   .write_b = sdhci_msm_writeb,
+#endif
 };
 
 static const struct sdhci_pltfm_data sdhci_msm_pdata = {
-- 
 Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 5/5] defconfig: msm: Enable CONFIG_MMC_SDHCI_IO_ACCESSORS

[Vijay Viswanath]

Enable CONFIG_MMC_SDHCI_IO_ACCESSORS so that SDHC controller specific
register read and write APIs, if registered, can be used.

Signed-off-by: Vijay Viswanath 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 65cdd87..a3c93ed 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -398,6 +398,7 @@ CONFIG_MMC_SDHCI_CADENCE=y
 CONFIG_MMC_SDHCI_TEGRA=y
 CONFIG_MMC_MESON_GX=y
 CONFIG_MMC_SDHCI_MSM=y
+CONFIG_MMC_SDHCI_IO_ACCESSORS=y
 CONFIG_MMC_SPI=y
 CONFIG_MMC_SDHI=y
 CONFIG_MMC_DW=y
-- 
 Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 4/5] mmc: sdhci-msm: Add ops to do sdhc register write

[Vijay Viswanath]

Register writes which change voltage of IO lines or turn the IO bus
on/off require controller to be ready before progressing further. When
the controller is ready, it will generate a power irq which needs to be
handled. The thread which initiated the register write should wait for
power irq to complete. This will be done through the new sdhc msm write
APIs which will check whether the particular write can trigger a power
irq and wait for it with a timeout if it is expected.
The SDHC core power control IRQ gets triggered when -
* There is a state change in power control bit (bit 0)
  of SDHCI_POWER_CONTROL register.
* There is a state change in 1.8V enable bit (bit 3) of
  SDHCI_HOST_CONTROL2 register.
* Bit 1 of SDHCI_SOFTWARE_RESET is set.

Signed-off-by: Vijay Viswanath 
---
 drivers/mmc/host/sdhci-msm.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 6d3b1fd..6571880 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1250,6 +1250,41 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
__sdhci_msm_set_clock(host, clock);
 }
 
+#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
+static void __sdhci_msm_check_write(struct sdhci_host *host, u16 val, int reg)
+{
+   u32 req_type = 0;
+
+   switch (reg) {
+   case SDHCI_HOST_CONTROL2:
+   req_type = (val & SDHCI_CTRL_VDD_180) ? REQ_IO_LOW :
+   REQ_IO_HIGH;
+   break;
+   case SDHCI_SOFTWARE_RESET:
+   if (host->pwr && (val & SDHCI_RESET_ALL))
+   req_type = REQ_BUS_OFF;
+   break;
+   case SDHCI_POWER_CONTROL:
+   req_type = !val ? REQ_BUS_OFF : REQ_BUS_ON;
+   break;
+   }
+
+   if (req_type)
+   sdhci_msm_check_power_status(host, req_type);
+}
+
+static void sdhci_msm_writew(struct sdhci_host *host, u16 val, int reg)
+{
+   writew_relaxed(val, host->ioaddr + reg);
+   __sdhci_msm_check_write(host, val, reg);
+}
+
+static void sdhci_msm_writeb(struct sdhci_host *host, u8 val, int reg)
+{
+   writeb_relaxed(val, host->ioaddr + reg);
+   __sdhci_msm_check_write(host, val, reg);
+}
+#endif
 static const struct of_device_id sdhci_msm_dt_match[] = {
{ .compatible = "qcom,sdhci-msm-v4" },
{},
@@ -1264,6 +1299,10 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
.get_max_clock = sdhci_msm_get_max_clock,
.set_bus_width = sdhci_set_bus_width,
.set_uhs_signaling = sdhci_msm_set_uhs_signaling,
+#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
+   .write_w = sdhci_msm_writew,
+   .write_b = sdhci_msm_writeb,
+#endif
 };
 
 static const struct sdhci_pltfm_data sdhci_msm_pdata = {
-- 
 Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 5/5] defconfig: msm: Enable CONFIG_MMC_SDHCI_IO_ACCESSORS

[Vijay Viswanath]

Enable CONFIG_MMC_SDHCI_IO_ACCESSORS so that SDHC controller specific
register read and write APIs, if registered, can be used.

Signed-off-by: Vijay Viswanath 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 65cdd87..a3c93ed 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -398,6 +398,7 @@ CONFIG_MMC_SDHCI_CADENCE=y
 CONFIG_MMC_SDHCI_TEGRA=y
 CONFIG_MMC_MESON_GX=y
 CONFIG_MMC_SDHCI_MSM=y
+CONFIG_MMC_SDHCI_IO_ACCESSORS=y
 CONFIG_MMC_SPI=y
 CONFIG_MMC_SDHI=y
 CONFIG_MMC_DW=y
-- 
 Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 2/5] mmc: sdhci-msm: Fix HW issue with power IRQ handling during reset

[Vijay Viswanath]

From: Sahitya Tummala 

There is a rare scenario in HW, where the first clear pulse could
be lost when the actual reset and clear/read of status register
are happening at the same time. Fix this by retrying upto 10 times
to ensure the status register gets cleared. Otherwise, this will
lead to a spurious power IRQ which results in system instability.

Signed-off-by: Sahitya Tummala 
Signed-off-by: Vijay Viswanath 
---
 drivers/mmc/host/sdhci-msm.c | 43 ---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 0957199..f3e0489 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -995,17 +995,51 @@ static void sdhci_msm_set_uhs_signaling(struct sdhci_host 
*host,
sdhci_msm_hs400(host, >ios);
 }
 
-static void sdhci_msm_voltage_switch(struct sdhci_host *host)
+static void sdhci_msm_dump_pwr_ctrl_regs(struct sdhci_host *host)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+
+   pr_err("%s: PWRCTL_STATUS: 0x%08x | PWRCTL_MASK: 0x%08x | PWRCTL_CTL: 
0x%08x\n",
+   mmc_hostname(host->mmc),
+   readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS),
+   readl_relaxed(msm_host->core_mem + CORE_PWRCTL_MASK),
+   readl_relaxed(msm_host->core_mem + CORE_PWRCTL_CTL));
+}
+
+static void sdhci_msm_handle_pwr_irq(struct sdhci_host *host, int irq)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
u32 irq_status, irq_ack = 0;
+   int retry = 10;
 
irq_status = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
irq_status &= INT_MASK;
 
writel_relaxed(irq_status, msm_host->core_mem + CORE_PWRCTL_CLEAR);
 
+   /*
+* There is a rare HW scenario where the first clear pulse could be
+* lost when actual reset and clear/read of status register is
+* happening at a time. Hence, retry for at least 10 times to make
+* sure status register is cleared. Otherwise, this will result in
+* a spurious power IRQ resulting in system instability.
+*/
+   while (irq_status & readl_relaxed(msm_host->core_mem +
+   CORE_PWRCTL_STATUS)) {
+   if (retry == 0) {
+   pr_err("%s: Timedout clearing (0x%x) pwrctl status 
register\n",
+   mmc_hostname(host->mmc), irq_status);
+   sdhci_msm_dump_pwr_ctrl_regs(host);
+   WARN_ON(1);
+   }
+   writel_relaxed(irq_status,
+   msm_host->core_mem + CORE_PWRCTL_CLEAR);
+   retry--;
+   udelay(10);
+   }
+
if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF))
irq_ack |= CORE_PWRCTL_BUS_SUCCESS;
if (irq_status & (CORE_PWRCTL_IO_LOW | CORE_PWRCTL_IO_HIGH))
@@ -1017,13 +1051,17 @@ static void sdhci_msm_voltage_switch(struct sdhci_host 
*host)
 * switches are handled by the sdhci core, so just report success.
 */
writel_relaxed(irq_ack, msm_host->core_mem + CORE_PWRCTL_CTL);
+
+   pr_debug("%s: %s: Handled IRQ(%d), irq_status=0x%x, ack=0x%x\n",
+   mmc_hostname(msm_host->mmc), __func__, irq, irq_status,
+   irq_ack);
 }
 
 static irqreturn_t sdhci_msm_pwr_irq(int irq, void *data)
 {
struct sdhci_host *host = (struct sdhci_host *)data;
 
-   sdhci_msm_voltage_switch(host);
+   sdhci_msm_handle_pwr_irq(host, irq);
 
return IRQ_HANDLED;
 }
@@ -1106,7 +1144,6 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
.get_max_clock = sdhci_msm_get_max_clock,
.set_bus_width = sdhci_set_bus_width,
.set_uhs_signaling = sdhci_msm_set_uhs_signaling,
-   .voltage_switch = sdhci_msm_voltage_switch,
 };
 
 static const struct sdhci_pltfm_data sdhci_msm_pdata = {
-- 
 Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 2/5] mmc: sdhci-msm: Fix HW issue with power IRQ handling during reset

[Vijay Viswanath]

From: Sahitya Tummala 

There is a rare scenario in HW, where the first clear pulse could
be lost when the actual reset and clear/read of status register
are happening at the same time. Fix this by retrying upto 10 times
to ensure the status register gets cleared. Otherwise, this will
lead to a spurious power IRQ which results in system instability.

Signed-off-by: Sahitya Tummala 
Signed-off-by: Vijay Viswanath 
---
 drivers/mmc/host/sdhci-msm.c | 43 ---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 0957199..f3e0489 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -995,17 +995,51 @@ static void sdhci_msm_set_uhs_signaling(struct sdhci_host 
*host,
sdhci_msm_hs400(host, >ios);
 }
 
-static void sdhci_msm_voltage_switch(struct sdhci_host *host)
+static void sdhci_msm_dump_pwr_ctrl_regs(struct sdhci_host *host)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
+
+   pr_err("%s: PWRCTL_STATUS: 0x%08x | PWRCTL_MASK: 0x%08x | PWRCTL_CTL: 
0x%08x\n",
+   mmc_hostname(host->mmc),
+   readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS),
+   readl_relaxed(msm_host->core_mem + CORE_PWRCTL_MASK),
+   readl_relaxed(msm_host->core_mem + CORE_PWRCTL_CTL));
+}
+
+static void sdhci_msm_handle_pwr_irq(struct sdhci_host *host, int irq)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
u32 irq_status, irq_ack = 0;
+   int retry = 10;
 
irq_status = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
irq_status &= INT_MASK;
 
writel_relaxed(irq_status, msm_host->core_mem + CORE_PWRCTL_CLEAR);
 
+   /*
+* There is a rare HW scenario where the first clear pulse could be
+* lost when actual reset and clear/read of status register is
+* happening at a time. Hence, retry for at least 10 times to make
+* sure status register is cleared. Otherwise, this will result in
+* a spurious power IRQ resulting in system instability.
+*/
+   while (irq_status & readl_relaxed(msm_host->core_mem +
+   CORE_PWRCTL_STATUS)) {
+   if (retry == 0) {
+   pr_err("%s: Timedout clearing (0x%x) pwrctl status 
register\n",
+   mmc_hostname(host->mmc), irq_status);
+   sdhci_msm_dump_pwr_ctrl_regs(host);
+   WARN_ON(1);
+   }
+   writel_relaxed(irq_status,
+   msm_host->core_mem + CORE_PWRCTL_CLEAR);
+   retry--;
+   udelay(10);
+   }
+
if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF))
irq_ack |= CORE_PWRCTL_BUS_SUCCESS;
if (irq_status & (CORE_PWRCTL_IO_LOW | CORE_PWRCTL_IO_HIGH))
@@ -1017,13 +1051,17 @@ static void sdhci_msm_voltage_switch(struct sdhci_host 
*host)
 * switches are handled by the sdhci core, so just report success.
 */
writel_relaxed(irq_ack, msm_host->core_mem + CORE_PWRCTL_CTL);
+
+   pr_debug("%s: %s: Handled IRQ(%d), irq_status=0x%x, ack=0x%x\n",
+   mmc_hostname(msm_host->mmc), __func__, irq, irq_status,
+   irq_ack);
 }
 
 static irqreturn_t sdhci_msm_pwr_irq(int irq, void *data)
 {
struct sdhci_host *host = (struct sdhci_host *)data;
 
-   sdhci_msm_voltage_switch(host);
+   sdhci_msm_handle_pwr_irq(host, irq);
 
return IRQ_HANDLED;
 }
@@ -1106,7 +1144,6 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, 
unsigned int clock)
.get_max_clock = sdhci_msm_get_max_clock,
.set_bus_width = sdhci_set_bus_width,
.set_uhs_signaling = sdhci_msm_set_uhs_signaling,
-   .voltage_switch = sdhci_msm_voltage_switch,
 };
 
 static const struct sdhci_pltfm_data sdhci_msm_pdata = {
-- 
 Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 0/5] mmc: sdhci-msm: Corrections to implementation of power irq

[Vijay Viswanath]

Register writes which change voltage of IO lines or turn the IO bus on/off
require sdhc controller to be ready before progressing further. Once a
register write which affects IO lines is done, the driver should wait for
power irq from controller. Once the irq comes, the driver should acknowledge
the irq by writing to power control register. If the acknowledgement is not
given to controller, the controller may not complete the corresponding
register write action and this can mess up the controller if drivers proceeds
without power irq completing. 

Sahitya Tummala (2):
  mmc: sdhci-msm: Fix HW issue with power IRQ handling during reset
  mmc: sdhci-msm: Add support to wait for power irq

Subhash Jadavani (1):
  mmc: sdhci-msm: fix issue with power irq

Vijay Viswanath (2):
  mmc: sdhci-msm: Add ops to do sdhc register write
  defconfig: msm: Enable CONFIG_MMC_SDHCI_IO_ACCESSORS

 arch/arm64/configs/defconfig |   1 +
 drivers/mmc/host/sdhci-msm.c | 233 ++-
 2 files changed, 229 insertions(+), 5 deletions(-)

-- 
 Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 1/5] mmc: sdhci-msm: fix issue with power irq

[Vijay Viswanath]

From: Subhash Jadavani 

SDCC controller reset (SW_RST) during probe may trigger power irq if
previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we
enable the power irq interrupt in GIC (by registering the interrupt
handler), we need to ensure that any pending power irq interrupt status
is acknowledged otherwise power irq interrupt handler would be fired
prematurely.

Signed-off-by: Subhash Jadavani 
Signed-off-by: Vijay Viswanath 
---
 drivers/mmc/host/sdhci-msm.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 9d601dc..0957199 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1128,6 +1128,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
u16 host_version, core_minor;
u32 core_version, config;
u8 core_major;
+   u32 irq_status, irq_ctl;
 
host = sdhci_pltfm_init(pdev, _msm_pdata, sizeof(*msm_host));
if (IS_ERR(host))
@@ -1250,6 +1251,28 @@ static int sdhci_msm_probe(struct platform_device *pdev)
   CORE_VENDOR_SPEC_CAPABILITIES0);
}
 
+   /*
+* Power on reset state may trigger power irq if previous status of
+* PWRCTL was either BUS_ON or IO_HIGH_V. So before enabling pwr irq
+* interrupt in GIC, any pending power irq interrupt should be
+* acknowledged. Otherwise power irq interrupt handler would be
+* fired prematurely.
+*/
+
+   irq_status = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
+   writel_relaxed(irq_status, msm_host->core_mem + CORE_PWRCTL_CLEAR);
+   irq_ctl = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_CTL);
+   if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF))
+   irq_ctl |= CORE_PWRCTL_BUS_SUCCESS;
+   if (irq_status & (CORE_PWRCTL_IO_HIGH | CORE_PWRCTL_IO_LOW))
+   irq_ctl |= CORE_PWRCTL_IO_SUCCESS;
+   writel_relaxed(irq_ctl, msm_host->core_mem + CORE_PWRCTL_CTL);
+   /*
+* Ensure that above writes are propogated before interrupt enablement
+* in GIC.
+*/
+   mb();
+
/* Setup IRQ for handling power/voltage tasks with PMIC */
msm_host->pwr_irq = platform_get_irq_byname(pdev, "pwr_irq");
if (msm_host->pwr_irq < 0) {
@@ -1259,6 +1282,9 @@ static int sdhci_msm_probe(struct platform_device *pdev)
goto clk_disable;
}
 
+   /* Enable pwr irq interrupts */
+   writel_relaxed(INT_MASK, msm_host->core_mem + CORE_PWRCTL_MASK);
+
ret = devm_request_threaded_irq(>dev, msm_host->pwr_irq, NULL,
sdhci_msm_pwr_irq, IRQF_ONESHOT,
dev_name(>dev), host);
-- 
 Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 0/5] mmc: sdhci-msm: Corrections to implementation of power irq

[Vijay Viswanath]

Register writes which change voltage of IO lines or turn the IO bus on/off
require sdhc controller to be ready before progressing further. Once a
register write which affects IO lines is done, the driver should wait for
power irq from controller. Once the irq comes, the driver should acknowledge
the irq by writing to power control register. If the acknowledgement is not
given to controller, the controller may not complete the corresponding
register write action and this can mess up the controller if drivers proceeds
without power irq completing. 

Sahitya Tummala (2):
  mmc: sdhci-msm: Fix HW issue with power IRQ handling during reset
  mmc: sdhci-msm: Add support to wait for power irq

Subhash Jadavani (1):
  mmc: sdhci-msm: fix issue with power irq

Vijay Viswanath (2):
  mmc: sdhci-msm: Add ops to do sdhc register write
  defconfig: msm: Enable CONFIG_MMC_SDHCI_IO_ACCESSORS

 arch/arm64/configs/defconfig |   1 +
 drivers/mmc/host/sdhci-msm.c | 233 ++-
 2 files changed, 229 insertions(+), 5 deletions(-)

-- 
 Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 1/5] mmc: sdhci-msm: fix issue with power irq

[Vijay Viswanath]

From: Subhash Jadavani 

SDCC controller reset (SW_RST) during probe may trigger power irq if
previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we
enable the power irq interrupt in GIC (by registering the interrupt
handler), we need to ensure that any pending power irq interrupt status
is acknowledged otherwise power irq interrupt handler would be fired
prematurely.

Signed-off-by: Subhash Jadavani 
Signed-off-by: Vijay Viswanath 
---
 drivers/mmc/host/sdhci-msm.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 9d601dc..0957199 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1128,6 +1128,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
u16 host_version, core_minor;
u32 core_version, config;
u8 core_major;
+   u32 irq_status, irq_ctl;
 
host = sdhci_pltfm_init(pdev, _msm_pdata, sizeof(*msm_host));
if (IS_ERR(host))
@@ -1250,6 +1251,28 @@ static int sdhci_msm_probe(struct platform_device *pdev)
   CORE_VENDOR_SPEC_CAPABILITIES0);
}
 
+   /*
+* Power on reset state may trigger power irq if previous status of
+* PWRCTL was either BUS_ON or IO_HIGH_V. So before enabling pwr irq
+* interrupt in GIC, any pending power irq interrupt should be
+* acknowledged. Otherwise power irq interrupt handler would be
+* fired prematurely.
+*/
+
+   irq_status = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
+   writel_relaxed(irq_status, msm_host->core_mem + CORE_PWRCTL_CLEAR);
+   irq_ctl = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_CTL);
+   if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF))
+   irq_ctl |= CORE_PWRCTL_BUS_SUCCESS;
+   if (irq_status & (CORE_PWRCTL_IO_HIGH | CORE_PWRCTL_IO_LOW))
+   irq_ctl |= CORE_PWRCTL_IO_SUCCESS;
+   writel_relaxed(irq_ctl, msm_host->core_mem + CORE_PWRCTL_CTL);
+   /*
+* Ensure that above writes are propogated before interrupt enablement
+* in GIC.
+*/
+   mb();
+
/* Setup IRQ for handling power/voltage tasks with PMIC */
msm_host->pwr_irq = platform_get_irq_byname(pdev, "pwr_irq");
if (msm_host->pwr_irq < 0) {
@@ -1259,6 +1282,9 @@ static int sdhci_msm_probe(struct platform_device *pdev)
goto clk_disable;
}
 
+   /* Enable pwr irq interrupts */
+   writel_relaxed(INT_MASK, msm_host->core_mem + CORE_PWRCTL_MASK);
+
ret = devm_request_threaded_irq(>dev, msm_host->pwr_irq, NULL,
sdhci_msm_pwr_irq, IRQF_ONESHOT,
dev_name(>dev), host);
-- 
 Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v7 0/2] perf/core: addressing 4x slowdown during per-process profiling of STREAM benchmark on Intel Xeon Phi

[Alexey Budankov]

Hi,

This patch set v7 moves event groups into rb trees and implements 
skipping to the current CPU's list on hrtimer interrupt.

Events allocated for the same CPU are still kept in a linked list
of the event directly attached to the tree because it is unclear 
how to implement fast iteration thru events allocated for 
the same CPU when they are all attached to a tree employing 
additional 64bit index as a secondary treee key.

The patch set addresses feeback captured previously. Specifically
API with a callback in signature is replaced by a macro what reduced
the size of adapting changes.

Patches in the set are expected to be applied one after another in 
the mentioned order and they are logically split into two parts 
to simplify the review process.

For more background details and feedback of the patch set please 
refer to v6 and older.

Thanks,
Alexey

---
 Alexey Budankov (2):
perf/core: use rb trees for pinned/flexible groups
perf/core: add mux switch to skip to the current CPU's events list on 
mux interrupt

 include/linux/perf_event.h |  19 +-
 kernel/events/core.c   | 463 ++---
 2 files changed, 364 insertions(+), 118 deletions(-)

[PATCH v7 0/2] perf/core: addressing 4x slowdown during per-process profiling of STREAM benchmark on Intel Xeon Phi

[Alexey Budankov]

Hi,

This patch set v7 moves event groups into rb trees and implements 
skipping to the current CPU's list on hrtimer interrupt.

Events allocated for the same CPU are still kept in a linked list
of the event directly attached to the tree because it is unclear 
how to implement fast iteration thru events allocated for 
the same CPU when they are all attached to a tree employing 
additional 64bit index as a secondary treee key.

The patch set addresses feeback captured previously. Specifically
API with a callback in signature is replaced by a macro what reduced
the size of adapting changes.

Patches in the set are expected to be applied one after another in 
the mentioned order and they are logically split into two parts 
to simplify the review process.

For more background details and feedback of the patch set please 
refer to v6 and older.

Thanks,
Alexey

---
 Alexey Budankov (2):
perf/core: use rb trees for pinned/flexible groups
perf/core: add mux switch to skip to the current CPU's events list on 
mux interrupt

 include/linux/perf_event.h |  19 +-
 kernel/events/core.c   | 463 ++---
 2 files changed, 364 insertions(+), 118 deletions(-)

Re: [PATCH v2 15/16] dmaengine: bcm-sba-raid: Add debugfs support

[Anup Patel]

On Thu, Aug 17, 2017 at 1:31 PM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:59PM +0530, Anup Patel wrote:
>> This patch adds debugfs support to report stats via debugfs
>> which in-turn will help debug hang or error situations.
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 82 
>> +-
>>  1 file changed, 81 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index f0a0e80..f9d110c 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -36,6 +36,7 @@
>>   */
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -162,6 +163,9 @@ struct sba_device {
>>   struct list_head reqs_completed_list;
>>   struct list_head reqs_aborted_list;
>>   struct list_head reqs_free_list;
>> + /* DebugFS directory entries */
>> + struct dentry *root;
>> + struct dentry *stats;
>>  };
>>
>>  /* == Command helper routines = */
>> @@ -486,6 +490,45 @@ static void sba_process_received_request(struct 
>> sba_device *sba,
>>   }
>>  }
>>
>> +static void sba_write_stats_in_seqfile(struct sba_device *sba,
>> +struct seq_file *file)
>> +{
>> + unsigned long flags;
>> + struct sba_request *req;
>> + u32 free_count = 0, alloced_count = 0, pending_count = 0;
>> + u32 active_count = 0, aborted_count = 0, completed_count = 0;
>> +
>> + spin_lock_irqsave(>reqs_lock, flags);
>> +
>> + list_for_each_entry(req, >reqs_free_list, node)
>> + free_count++;
>> +
>> + list_for_each_entry(req, >reqs_alloc_list, node)
>> + alloced_count++;
>> +
>> + list_for_each_entry(req, >reqs_pending_list, node)
>> + pending_count++;
>> +
>> + list_for_each_entry(req, >reqs_active_list, node)
>> + active_count++;
>> +
>> + list_for_each_entry(req, >reqs_aborted_list, node)
>> + aborted_count++;
>> +
>> + list_for_each_entry(req, >reqs_completed_list, node)
>> + completed_count++;
>> +
>> + spin_unlock_irqrestore(>reqs_lock, flags);
>> +
>> + seq_printf(file, "maximum requests   = %d\n", sba->max_req);
>> + seq_printf(file, "free requests  = %d\n", free_count);
>> + seq_printf(file, "alloced requests   = %d\n", alloced_count);
>> + seq_printf(file, "pending requests   = %d\n", pending_count);
>> + seq_printf(file, "active requests= %d\n", active_count);
>> + seq_printf(file, "aborted requests   = %d\n", aborted_count);
>> + seq_printf(file, "completed requests = %d\n", completed_count);
>> +}
>> +
>>  /* == DMAENGINE callbacks = */
>>
>>  static void sba_free_chan_resources(struct dma_chan *dchan)
>> @@ -1451,6 +1494,19 @@ static void sba_receive_message(struct mbox_client 
>> *cl, void *msg)
>>   sba_process_received_request(sba, req);
>>  }
>>
>> +/* == Debugfs callbacks == */
>> +
>> +static int sba_debugfs_stats_show(struct seq_file *file, void *offset)
>> +{
>> + struct platform_device *pdev = to_platform_device(file->private);
>> + struct sba_device *sba = platform_get_drvdata(pdev);
>> +
>> + /* Write stats in file */
>> + sba_write_stats_in_seqfile(sba, file);
>> +
>> + return 0;
>> +}
>> +
>>  /* == Platform driver routines = */
>>
>>  static int sba_prealloc_channel_resources(struct sba_device *sba)
>> @@ -1721,10 +1777,30 @@ static int sba_probe(struct platform_device *pdev)
>>   if (ret)
>>   goto fail_free_mchans;
>>
>> + /* Check availability of debugfs */
>> + if (!debugfs_initialized())
>> + goto skip_debugfs;
>> +
>> + /* Create debugfs root entry */
>> + sba->root = debugfs_create_dir(dev_name(sba->dev), NULL);
>> + if (IS_ERR_OR_NULL(sba->root)) {
>> + ret = PTR_ERR_OR_ZERO(sba->root);
>> + goto fail_free_resources;
>
> why fail, debugfs should be an optional thingy, why would you want to fail 
> here?

Yes, we are handling the case when debugfs is not available
and skipping debugfs gracefully.

If debugfs is available then failure of debugfs_create_dir()
should be reported.

Regards,
Anup

Re: [PATCH v2 15/16] dmaengine: bcm-sba-raid: Add debugfs support

[Anup Patel]

On Thu, Aug 17, 2017 at 1:31 PM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:59PM +0530, Anup Patel wrote:
>> This patch adds debugfs support to report stats via debugfs
>> which in-turn will help debug hang or error situations.
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Scott Branden 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 82 
>> +-
>>  1 file changed, 81 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index f0a0e80..f9d110c 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -36,6 +36,7 @@
>>   */
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -162,6 +163,9 @@ struct sba_device {
>>   struct list_head reqs_completed_list;
>>   struct list_head reqs_aborted_list;
>>   struct list_head reqs_free_list;
>> + /* DebugFS directory entries */
>> + struct dentry *root;
>> + struct dentry *stats;
>>  };
>>
>>  /* == Command helper routines = */
>> @@ -486,6 +490,45 @@ static void sba_process_received_request(struct 
>> sba_device *sba,
>>   }
>>  }
>>
>> +static void sba_write_stats_in_seqfile(struct sba_device *sba,
>> +struct seq_file *file)
>> +{
>> + unsigned long flags;
>> + struct sba_request *req;
>> + u32 free_count = 0, alloced_count = 0, pending_count = 0;
>> + u32 active_count = 0, aborted_count = 0, completed_count = 0;
>> +
>> + spin_lock_irqsave(>reqs_lock, flags);
>> +
>> + list_for_each_entry(req, >reqs_free_list, node)
>> + free_count++;
>> +
>> + list_for_each_entry(req, >reqs_alloc_list, node)
>> + alloced_count++;
>> +
>> + list_for_each_entry(req, >reqs_pending_list, node)
>> + pending_count++;
>> +
>> + list_for_each_entry(req, >reqs_active_list, node)
>> + active_count++;
>> +
>> + list_for_each_entry(req, >reqs_aborted_list, node)
>> + aborted_count++;
>> +
>> + list_for_each_entry(req, >reqs_completed_list, node)
>> + completed_count++;
>> +
>> + spin_unlock_irqrestore(>reqs_lock, flags);
>> +
>> + seq_printf(file, "maximum requests   = %d\n", sba->max_req);
>> + seq_printf(file, "free requests  = %d\n", free_count);
>> + seq_printf(file, "alloced requests   = %d\n", alloced_count);
>> + seq_printf(file, "pending requests   = %d\n", pending_count);
>> + seq_printf(file, "active requests= %d\n", active_count);
>> + seq_printf(file, "aborted requests   = %d\n", aborted_count);
>> + seq_printf(file, "completed requests = %d\n", completed_count);
>> +}
>> +
>>  /* == DMAENGINE callbacks = */
>>
>>  static void sba_free_chan_resources(struct dma_chan *dchan)
>> @@ -1451,6 +1494,19 @@ static void sba_receive_message(struct mbox_client 
>> *cl, void *msg)
>>   sba_process_received_request(sba, req);
>>  }
>>
>> +/* == Debugfs callbacks == */
>> +
>> +static int sba_debugfs_stats_show(struct seq_file *file, void *offset)
>> +{
>> + struct platform_device *pdev = to_platform_device(file->private);
>> + struct sba_device *sba = platform_get_drvdata(pdev);
>> +
>> + /* Write stats in file */
>> + sba_write_stats_in_seqfile(sba, file);
>> +
>> + return 0;
>> +}
>> +
>>  /* == Platform driver routines = */
>>
>>  static int sba_prealloc_channel_resources(struct sba_device *sba)
>> @@ -1721,10 +1777,30 @@ static int sba_probe(struct platform_device *pdev)
>>   if (ret)
>>   goto fail_free_mchans;
>>
>> + /* Check availability of debugfs */
>> + if (!debugfs_initialized())
>> + goto skip_debugfs;
>> +
>> + /* Create debugfs root entry */
>> + sba->root = debugfs_create_dir(dev_name(sba->dev), NULL);
>> + if (IS_ERR_OR_NULL(sba->root)) {
>> + ret = PTR_ERR_OR_ZERO(sba->root);
>> + goto fail_free_resources;
>
> why fail, debugfs should be an optional thingy, why would you want to fail 
> here?

Yes, we are handling the case when debugfs is not available
and skipping debugfs gracefully.

If debugfs is available then failure of debugfs_create_dir()
should be reported.

Regards,
Anup

Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface

[David Miller]

From: Stephen Hemminger 
Date: Thu, 17 Aug 2017 17:42:05 -0700

> Please drop these functions, they do nothing and are not used
> as stubs in any operations table.

It might have been helpful to scan the entire series to understand
why it looks this way.

He's building the driver up, one piece at a time, filling in the full
implementation as is possible as more and more infrastructure is added.

So some functions start empty when a method is needed to be filled in,
and then gradually obtains more and more content throughout the
series.

And this is a fine way to add a huge new driver (although not my
personal preference).

RE: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Tantilov, Emil S]

>-Original Message-
>From: Ding Tianhong [mailto:dingtianh...@huawei.com]
>Sent: Thursday, August 17, 2017 5:39 PM
>To: Tantilov, Emil S ; da...@davemloft.net;
>Kirsher, Jeffrey T ; keesc...@chromium.org;
>linux-kernel@vger.kernel.org; sparcli...@vger.kernel.org; intel-wired-
>l...@lists.osuosl.org; alexander.du...@gmail.com; net...@vger.kernel.org;
>linux...@huawei.com
>Subject: Re: [PATCH net v2 2/2] net: ixgbe: Use new
>PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
>
>
>
>On 2017/8/17 22:17, Tantilov, Emil S wrote:
>
>>> ret_val = ixgbe_start_hw_generic(hw);
>>>
>>> -#ifndef CONFIG_SPARC
>>> -   /* Disable relaxed ordering */
>>> -   for (i = 0; ((i < hw->mac.max_tx_queues) &&
>>> -(i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
>>> -   regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(i));
>>> -   regval &= ~IXGBE_DCA_TXCTRL_DESC_WRO_EN;
>>> -   IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(i), regval);
>>> -   }
>>> +   if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
>>
>> As Alex mentioned there is no need for this check in any form.
>>
>> The HW defaults to Relaxed Ordering enabled unless it is disabled in
>> the PCIe Device Control Register. So the above logic is already done by
>HW.
>>
>> All you have to do is strip the code disabling relaxed ordering.
>>
>
>Hi Tantilov:
>
>I misunderstood Alex's suggestion, But I still couldn't find the logic
>where
>the HW disable the Relaxed Ordering when the PCIe Device Control Register
>disable it, can you point it out?

If you look at the datasheet (82599) - the description of CTRL_EXT.RO_DIS (bit 
17, 0b):

Relaxed Ordering Disable. When set to 1b, the device does not request any 
relaxed
ordering transactions. When this bit is cleared and the Enable Relaxed Ordering 
bit in
the Device Control register is set, the device requests relaxed ordering 
transactions per queues as configured in the DCA_RXCTRL[n] and DCA_TXCTRL[n] 
registers.

So if you remove the code that clears the bits in DCA_T/RXCTRL relaxed ordering 
should
be enabled by HW when the bus allows it.

Thanks,
Emil

Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface

[David Miller]

From: Stephen Hemminger 
Date: Thu, 17 Aug 2017 17:42:05 -0700

> Please drop these functions, they do nothing and are not used
> as stubs in any operations table.

It might have been helpful to scan the entire series to understand
why it looks this way.

He's building the driver up, one piece at a time, filling in the full
implementation as is possible as more and more infrastructure is added.

So some functions start empty when a method is needed to be filled in,
and then gradually obtains more and more content throughout the
series.

And this is a fine way to add a huge new driver (although not my
personal preference).

RE: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Tantilov, Emil S]

>-Original Message-
>From: Ding Tianhong [mailto:dingtianh...@huawei.com]
>Sent: Thursday, August 17, 2017 5:39 PM
>To: Tantilov, Emil S ; da...@davemloft.net;
>Kirsher, Jeffrey T ; keesc...@chromium.org;
>linux-kernel@vger.kernel.org; sparcli...@vger.kernel.org; intel-wired-
>l...@lists.osuosl.org; alexander.du...@gmail.com; net...@vger.kernel.org;
>linux...@huawei.com
>Subject: Re: [PATCH net v2 2/2] net: ixgbe: Use new
>PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
>
>
>
>On 2017/8/17 22:17, Tantilov, Emil S wrote:
>
>>> ret_val = ixgbe_start_hw_generic(hw);
>>>
>>> -#ifndef CONFIG_SPARC
>>> -   /* Disable relaxed ordering */
>>> -   for (i = 0; ((i < hw->mac.max_tx_queues) &&
>>> -(i < IXGBE_DCA_MAX_QUEUES_82598)); i++) {
>>> -   regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL(i));
>>> -   regval &= ~IXGBE_DCA_TXCTRL_DESC_WRO_EN;
>>> -   IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL(i), regval);
>>> -   }
>>> +   if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
>>
>> As Alex mentioned there is no need for this check in any form.
>>
>> The HW defaults to Relaxed Ordering enabled unless it is disabled in
>> the PCIe Device Control Register. So the above logic is already done by
>HW.
>>
>> All you have to do is strip the code disabling relaxed ordering.
>>
>
>Hi Tantilov:
>
>I misunderstood Alex's suggestion, But I still couldn't find the logic
>where
>the HW disable the Relaxed Ordering when the PCIe Device Control Register
>disable it, can you point it out?

If you look at the datasheet (82599) - the description of CTRL_EXT.RO_DIS (bit 
17, 0b):

Relaxed Ordering Disable. When set to 1b, the device does not request any 
relaxed
ordering transactions. When this bit is cleared and the Enable Relaxed Ordering 
bit in
the Device Control register is set, the device requests relaxed ordering 
transactions per queues as configured in the DCA_RXCTRL[n] and DCA_TXCTRL[n] 
registers.

So if you remove the code that clears the bits in DCA_T/RXCTRL relaxed ordering 
should
be enabled by HW when the bus allows it.

Thanks,
Emil

Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface

[David Miller]

From: Stephen Hemminger 
Date: Thu, 17 Aug 2017 17:45:40 -0700

> On Thu, 17 Aug 2017 19:52:42 +0800
> Aviad Krawczyk  wrote:
> 
>> +nic_dev = (struct hinic_dev *)netdev_priv(netdev);
> 
> Since netdev_priv() returns void *, a cast is not necessary here.

Agreed.

Re: [PATCH V5 net-next 01/21] net-next/hinic: Initialize hw interface

[David Miller]

From: Stephen Hemminger 
Date: Thu, 17 Aug 2017 17:45:40 -0700

> On Thu, 17 Aug 2017 19:52:42 +0800
> Aviad Krawczyk  wrote:
> 
>> +nic_dev = (struct hinic_dev *)netdev_priv(netdev);
> 
> Since netdev_priv() returns void *, a cast is not necessary here.

Agreed.

Re: [PATCH v2 10/16] dmaengine: bcm-sba-raid: Alloc resources before registering DMA device

[Anup Patel]

On Thu, Aug 17, 2017 at 12:08 PM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:54PM +0530, Anup Patel wrote:
>> We should allocate DMA channel resources before registering the
>> DMA device in sba_probe() because we can get DMA request soon
>> after registering the DMA device. If DMA channel resources are
>> not allocated before first DMA request then SBA-RAID driver will
>> crash.
>>
>> Signed-off-by: Anup Patel 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 30 +++---
>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index f6616da..f14ed0a 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -1478,13 +1478,13 @@ static int sba_prealloc_channel_resources(struct 
>> sba_device *sba)
>>   int i, j, ret = 0;
>>   struct sba_request *req = NULL;
>>
>> - sba->resp_base = dma_alloc_coherent(sba->dma_dev.dev,
>> + sba->resp_base = dma_alloc_coherent(sba->mbox_dev,
>
> how does this qualify as move before registering, you seem to be using
> different device now

The sba->dma_dev.dev is assigned in sba_async_register().

Now, if we are calling sba_async_register() after
sba_prealloc_channel_resources() then we cannot
use sba->dma_dev.dev in sba_prealloc_channel_resources()

Regards,
Anup

Re: [PATCH v2 10/16] dmaengine: bcm-sba-raid: Alloc resources before registering DMA device

[Anup Patel]

On Thu, Aug 17, 2017 at 12:08 PM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:54PM +0530, Anup Patel wrote:
>> We should allocate DMA channel resources before registering the
>> DMA device in sba_probe() because we can get DMA request soon
>> after registering the DMA device. If DMA channel resources are
>> not allocated before first DMA request then SBA-RAID driver will
>> crash.
>>
>> Signed-off-by: Anup Patel 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 30 +++---
>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index f6616da..f14ed0a 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -1478,13 +1478,13 @@ static int sba_prealloc_channel_resources(struct 
>> sba_device *sba)
>>   int i, j, ret = 0;
>>   struct sba_request *req = NULL;
>>
>> - sba->resp_base = dma_alloc_coherent(sba->dma_dev.dev,
>> + sba->resp_base = dma_alloc_coherent(sba->mbox_dev,
>
> how does this qualify as move before registering, you seem to be using
> different device now

The sba->dma_dev.dev is assigned in sba_async_register().

Now, if we are calling sba_async_register() after
sba_prealloc_channel_resources() then we cannot
use sba->dma_dev.dev in sba_prealloc_channel_resources()

Regards,
Anup

Re: [PATCH v2 03/16] dmaengine: bcm-sba-raid: Common flags for sba_request state and fence

[Anup Patel]

On Thu, Aug 17, 2017 at 9:15 AM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:47PM +0530, Anup Patel wrote:
>> This patch merges sba_request state and fence into common
>> sba_request flags. Also, in-future we can extend sba_request
>> flags as required.
>
> and it also changes the flag values to bits, which I have no idea why that
> was done, care to explain that please...

I thought its better to have separate bit each sba_request state so
that when a sba_request is accidentally in two states then we can
debug better.

I will restore state values.

Regards,
Anup

Re: [PATCH v2 03/16] dmaengine: bcm-sba-raid: Common flags for sba_request state and fence

[Anup Patel]

On Thu, Aug 17, 2017 at 9:15 AM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:47PM +0530, Anup Patel wrote:
>> This patch merges sba_request state and fence into common
>> sba_request flags. Also, in-future we can extend sba_request
>> flags as required.
>
> and it also changes the flag values to bits, which I have no idea why that
> was done, care to explain that please...

I thought its better to have separate bit each sba_request state so
that when a sba_request is accidentally in two states then we can
debug better.

I will restore state values.

Regards,
Anup

Re: [PATCH v2 01/16] dmaengine: bcm-sba-raid: Minor improvments in comments

[Anup Patel]

On Thu, Aug 17, 2017 at 9:14 AM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:45PM +0530, Anup Patel wrote:
>> Make section comments consistent across the Broadcom SBA RAID driver
>> by avoiding " SBA " in some of the comments.
>
> and you add more comments..

OK, I will add this to commit description.

>
>>
>> Signed-off-by: Anup Patel 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index e41bbc7..76999b7 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -48,7 +48,8 @@
>>
>>  #include "dmaengine.h"
>>
>> -/* SBA command related defines */
>> +/* == Driver macros and defines = */
>> +
>>  #define SBA_TYPE_SHIFT   48
>>  #define SBA_TYPE_MASKGENMASK(1, 0)
>>  #define SBA_TYPE_A   0x0
>> @@ -88,6 +89,8 @@
>>  #define to_sba_device(dchan) \
>>   container_of(dchan, struct sba_device, dma_chan)
>>
>> +/* = Driver data structures = */
>
> like this!!
>
>> +
>>  enum sba_request_state {
>>   SBA_REQUEST_STATE_FREE = 1,
>>   SBA_REQUEST_STATE_ALLOCED = 2,
>> @@ -164,7 +167,7 @@ struct sba_device {
>>   int reqs_free_count;
>>  };
>>
>> -/* == SBA command helper routines = */
>> +/* == Command helper routines = */
>>
>>  static inline u64 __pure sba_cmd_enc(u64 cmd, u32 val, u32 shift, u32 mask)
>>  {
>> @@ -196,7 +199,7 @@ static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32 
>> b1, u32 b0)
>>  ((d & SBA_C_MDATA_DNUM_MASK) << SBA_C_MDATA_DNUM_SHIFT);
>>  }
>>
>> -/* == Channel resource management routines = */
>> +/* == General helper routines = */
>>

Regards,
Anup

Re: [PATCH v2 01/16] dmaengine: bcm-sba-raid: Minor improvments in comments

[Anup Patel]

On Thu, Aug 17, 2017 at 9:14 AM, Vinod Koul  wrote:
> On Tue, Aug 01, 2017 at 04:07:45PM +0530, Anup Patel wrote:
>> Make section comments consistent across the Broadcom SBA RAID driver
>> by avoiding " SBA " in some of the comments.
>
> and you add more comments..

OK, I will add this to commit description.

>
>>
>> Signed-off-by: Anup Patel 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 9 ++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index e41bbc7..76999b7 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -48,7 +48,8 @@
>>
>>  #include "dmaengine.h"
>>
>> -/* SBA command related defines */
>> +/* == Driver macros and defines = */
>> +
>>  #define SBA_TYPE_SHIFT   48
>>  #define SBA_TYPE_MASKGENMASK(1, 0)
>>  #define SBA_TYPE_A   0x0
>> @@ -88,6 +89,8 @@
>>  #define to_sba_device(dchan) \
>>   container_of(dchan, struct sba_device, dma_chan)
>>
>> +/* = Driver data structures = */
>
> like this!!
>
>> +
>>  enum sba_request_state {
>>   SBA_REQUEST_STATE_FREE = 1,
>>   SBA_REQUEST_STATE_ALLOCED = 2,
>> @@ -164,7 +167,7 @@ struct sba_device {
>>   int reqs_free_count;
>>  };
>>
>> -/* == SBA command helper routines = */
>> +/* == Command helper routines = */
>>
>>  static inline u64 __pure sba_cmd_enc(u64 cmd, u32 val, u32 shift, u32 mask)
>>  {
>> @@ -196,7 +199,7 @@ static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32 
>> b1, u32 b0)
>>  ((d & SBA_C_MDATA_DNUM_MASK) << SBA_C_MDATA_DNUM_SHIFT);
>>  }
>>
>> -/* == Channel resource management routines = */
>> +/* == General helper routines = */
>>

Regards,
Anup

Re: [PATCH v6 0/2] Make find_later_rq() choose a closer cpu in topology

[Joel Fernandes (Google)]

On Thu, Aug 17, 2017 at 6:25 PM, Byungchul Park  wrote:
> On Mon, Aug 07, 2017 at 12:50:32PM +0900, Byungchul Park wrote:
>> When cpudl_find() returns any among free_cpus, the cpu might not be
>> closer than others, considering sched domain. For example:
>>
>>this_cpu: 15
>>free_cpus: 0, 1,..., 14 (== later_mask)
>>best_cpu: 0
>>
>>topology:
>>
>>0 --+
>>+--+
>>1 --+  |
>>   +-- ... --+
>>2 --+  | |
>>+--+ |
>>3 --+|
>>
>>... ...
>>
>>12 --+   |
>> +--+|
>>13 --+  ||
>>+-- ... -+
>>14 --+  |
>> +--+
>>15 --+
>>
>> In this case, it would be best to select 14 since it's a free cpu and
>> closest to 15(this_cpu). However, currently the code select 0(best_cpu)
>> even though that's just any among free_cpus. Fix it.
>
> Could you let me know your opinions about this?

Patch looks good to me, I would also add a comment ontop of
fallback_cpu (I think Steve mentioned similar thing at [1])

/*
 * fallback is the closest CPU in the closest SD incase
 * all domains are PREFER_SIBLING
 */
 if (fallback_cpu == -1)
 fallback_cpu = best_cpu;

And clarify this in the commit message.


thanks,

-Joel

[1] https://patchwork.kernel.org/patch/9884383/


>
>> Change from v5
>>-. exclude two patches already picked up by peterz
>>   (sched/deadline: Make find_later_rq() choose a closer cpu in topology)
>>   (sched/deadline: Change return value of cpudl_find())
>>-. apply what peterz fixed for 'prefer sibling', into deadline and rt
>>
>> Change from v4
>>-. remove a patch that might cause huge lock contention
>>   (by spin lock() in a hot path of scheduler)
>>
>> Change from v3
>>-. rename closest_cpu to best_cpu so that it align with rt
>>-. protect referring cpudl.elements with cpudl.lock
>>-. change return value of cpudl_find() to bool
>>
>> Change from v2
>>-. add support for SD_PREFER_SIBLING
>>
>> Change from v1
>>-. clean up the patch
>>
>> Byungchul Park (2):
>>   sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
>>   sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()
>>
>>  kernel/sched/deadline.c | 46 +++---
>>  kernel/sched/rt.c   | 47 ---
>>  2 files changed, 87 insertions(+), 6 deletions(-)
>>
>> --
>> 1.9.1

Re: [PATCH v6 0/2] Make find_later_rq() choose a closer cpu in topology

[Joel Fernandes (Google)]

On Thu, Aug 17, 2017 at 6:25 PM, Byungchul Park  wrote:
> On Mon, Aug 07, 2017 at 12:50:32PM +0900, Byungchul Park wrote:
>> When cpudl_find() returns any among free_cpus, the cpu might not be
>> closer than others, considering sched domain. For example:
>>
>>this_cpu: 15
>>free_cpus: 0, 1,..., 14 (== later_mask)
>>best_cpu: 0
>>
>>topology:
>>
>>0 --+
>>+--+
>>1 --+  |
>>   +-- ... --+
>>2 --+  | |
>>+--+ |
>>3 --+|
>>
>>... ...
>>
>>12 --+   |
>> +--+|
>>13 --+  ||
>>+-- ... -+
>>14 --+  |
>> +--+
>>15 --+
>>
>> In this case, it would be best to select 14 since it's a free cpu and
>> closest to 15(this_cpu). However, currently the code select 0(best_cpu)
>> even though that's just any among free_cpus. Fix it.
>
> Could you let me know your opinions about this?

Patch looks good to me, I would also add a comment ontop of
fallback_cpu (I think Steve mentioned similar thing at [1])

/*
 * fallback is the closest CPU in the closest SD incase
 * all domains are PREFER_SIBLING
 */
 if (fallback_cpu == -1)
 fallback_cpu = best_cpu;

And clarify this in the commit message.


thanks,

-Joel

[1] https://patchwork.kernel.org/patch/9884383/


>
>> Change from v5
>>-. exclude two patches already picked up by peterz
>>   (sched/deadline: Make find_later_rq() choose a closer cpu in topology)
>>   (sched/deadline: Change return value of cpudl_find())
>>-. apply what peterz fixed for 'prefer sibling', into deadline and rt
>>
>> Change from v4
>>-. remove a patch that might cause huge lock contention
>>   (by spin lock() in a hot path of scheduler)
>>
>> Change from v3
>>-. rename closest_cpu to best_cpu so that it align with rt
>>-. protect referring cpudl.elements with cpudl.lock
>>-. change return value of cpudl_find() to bool
>>
>> Change from v2
>>-. add support for SD_PREFER_SIBLING
>>
>> Change from v1
>>-. clean up the patch
>>
>> Byungchul Park (2):
>>   sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()
>>   sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()
>>
>>  kernel/sched/deadline.c | 46 +++---
>>  kernel/sched/rt.c   | 47 ---
>>  2 files changed, 87 insertions(+), 6 deletions(-)
>>
>> --
>> 1.9.1

Re: WARNING: CPU: 15 PID: 0 at block/blk-mq.c:1111 __blk_mq_run_hw_queue+0x1d8/0x1f0

[Abdul Haleem]

On Thu, 2017-08-17 at 14:18 -0500, Brian King wrote:
> On 08/17/2017 10:32 AM, Bart Van Assche wrote:
> > On Wed, 2017-08-16 at 15:10 -0500, Brian King wrote:
> >> On 08/16/2017 01:15 PM, Bart Van Assche wrote:
> >>> On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote:
>  Linux-next booted with the below warnings on powerpc
> 
>  [ ... ]
> 
>  boot warnings:
>  --
>  kvm: exiting hardware virtualization
>  [ cut here ]
>  WARNING: CPU: 15 PID: 0 at block/blk-mq.c: __blk_mq_run_hw_queue
>  +0x1d8/0x1f0
>  Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
>  Call Trace:
>  [c0037990] [c088f7b0] __blk_mq_delay_run_hw_queue
>  +0x1f0/0x210
>  [c00379d0] [c088fcb8] blk_mq_start_hw_queue+0x58/0x80
>  [c00379f0] [c088fd40] blk_mq_start_hw_queues+0x60/0xb0
>  [c0037a30] [c0ae2b54] scsi_kick_queue+0x34/0xa0
>  [c0037a50] [c0ae2f70] scsi_run_queue+0x3b0/0x660
>  [c0037ac0] [c0ae7ed4] scsi_run_host_queues+0x64/0xc0
>  [c0037b00] [c0ae7f64] scsi_unblock_requests+0x34/0x60
>  [c0037b20] [c0b14998] ipr_ioa_bringdown_done+0xf8/0x3a0
>  [c0037bc0] [c0b12528] ipr_reset_ioa_job+0xd8/0x170
>  [c0037c00] [c0b18790] ipr_reset_timer_done+0x110/0x160
>  [c0037c50] [c024db50] call_timer_fn+0xa0/0x3a0
>  [c0037ce0] [c024e058] expire_timers+0x1b8/0x350
>  [c0037d50] [c024e2f0] run_timer_softirq+0x100/0x3e0
>  [c0037df0] [c0162edc] __do_softirq+0x20c/0x620
>  [c0037ee0] [c0163a80] irq_exit+0x230/0x290
>  [c0037f10] [c001d770] __do_irq+0x170/0x410
>  [c0037f90] [c003ea20] call_do_irq+0x14/0x24
>  [c007f84e3a70] [c001dae0] do_IRQ+0xd0/0x190
>  [c007f84e3ac0] [c0008c58] hardware_interrupt_common
>  +0x158/0x160
> >>>
> >>> Hello Brian,
> >>>
> >>> In the MAINTAINERS file I found the following:
> >>>
> >>> IBM Power Linux RAID adapter
> >>> M:  Brian King 
> >>> S:  Supported
> >>> F:  drivers/scsi/ipr.*
> >>>
> >>> Is that information up-to-date? Do you agree that the above message 
> >>> indicates
> >>> a bug in the ipr driver?
> >>
> >> Yes. Can you try with this patch that is in 4.13/scsi-fixes:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=4.13/scsi-fixes=b0e17a9b0df29590c45dfb296f541270a5941f41
> > 

Hi Brian,

The patch fixes the warning, Thanks for the fix.

Tested-by : Abdul Haleem 

-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre

Re: WARNING: CPU: 15 PID: 0 at block/blk-mq.c:1111 __blk_mq_run_hw_queue+0x1d8/0x1f0

[Abdul Haleem]

On Thu, 2017-08-17 at 14:18 -0500, Brian King wrote:
> On 08/17/2017 10:32 AM, Bart Van Assche wrote:
> > On Wed, 2017-08-16 at 15:10 -0500, Brian King wrote:
> >> On 08/16/2017 01:15 PM, Bart Van Assche wrote:
> >>> On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote:
>  Linux-next booted with the below warnings on powerpc
> 
>  [ ... ]
> 
>  boot warnings:
>  --
>  kvm: exiting hardware virtualization
>  [ cut here ]
>  WARNING: CPU: 15 PID: 0 at block/blk-mq.c: __blk_mq_run_hw_queue
>  +0x1d8/0x1f0
>  Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
>  Call Trace:
>  [c0037990] [c088f7b0] __blk_mq_delay_run_hw_queue
>  +0x1f0/0x210
>  [c00379d0] [c088fcb8] blk_mq_start_hw_queue+0x58/0x80
>  [c00379f0] [c088fd40] blk_mq_start_hw_queues+0x60/0xb0
>  [c0037a30] [c0ae2b54] scsi_kick_queue+0x34/0xa0
>  [c0037a50] [c0ae2f70] scsi_run_queue+0x3b0/0x660
>  [c0037ac0] [c0ae7ed4] scsi_run_host_queues+0x64/0xc0
>  [c0037b00] [c0ae7f64] scsi_unblock_requests+0x34/0x60
>  [c0037b20] [c0b14998] ipr_ioa_bringdown_done+0xf8/0x3a0
>  [c0037bc0] [c0b12528] ipr_reset_ioa_job+0xd8/0x170
>  [c0037c00] [c0b18790] ipr_reset_timer_done+0x110/0x160
>  [c0037c50] [c024db50] call_timer_fn+0xa0/0x3a0
>  [c0037ce0] [c024e058] expire_timers+0x1b8/0x350
>  [c0037d50] [c024e2f0] run_timer_softirq+0x100/0x3e0
>  [c0037df0] [c0162edc] __do_softirq+0x20c/0x620
>  [c0037ee0] [c0163a80] irq_exit+0x230/0x290
>  [c0037f10] [c001d770] __do_irq+0x170/0x410
>  [c0037f90] [c003ea20] call_do_irq+0x14/0x24
>  [c007f84e3a70] [c001dae0] do_IRQ+0xd0/0x190
>  [c007f84e3ac0] [c0008c58] hardware_interrupt_common
>  +0x158/0x160
> >>>
> >>> Hello Brian,
> >>>
> >>> In the MAINTAINERS file I found the following:
> >>>
> >>> IBM Power Linux RAID adapter
> >>> M:  Brian King 
> >>> S:  Supported
> >>> F:  drivers/scsi/ipr.*
> >>>
> >>> Is that information up-to-date? Do you agree that the above message 
> >>> indicates
> >>> a bug in the ipr driver?
> >>
> >> Yes. Can you try with this patch that is in 4.13/scsi-fixes:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?h=4.13/scsi-fixes=b0e17a9b0df29590c45dfb296f541270a5941f41
> > 

Hi Brian,

The patch fixes the warning, Thanks for the fix.

Tested-by : Abdul Haleem 

-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre

Re: [PATCH] PCI: Allow PCI express root ports to find themselves

[Michael Ellerman]

Thierry Reding <thierry.red...@gmail.com> writes:

> From: Thierry Reding <tred...@nvidia.com>
>
> If the pci_find_pcie_root_port() function is called on a root port
> itself, return the root port rather than NULL.
>
> This effectively reverts commit 0e405232871d6 ("PCI: fix oops when
> try to find Root Port for a PCI device") which added an extra check
> that would now be redundant.
>
> Fixes: a99b646afa8a ("PCI: Disable PCIe Relaxed Ordering if unsupported")
> Fixes: c56d4450eb68 ("PCI: Turn off Request Attributes to avoid Chelsio T5 
> Completion erratum")
> Signed-off-by: Thierry Reding <tred...@nvidia.com>
> ---
> This applies on top of and was tested on next-20170817.
>
> Michael, it'd be great if you could test this one again to clarify
> whether or not the fix that's already in Linus' tree is still needed, or
> whether it's indeed obsoleted by this patch.

This works fine for me, applied on top of Linus' tree (d33a2a914319).

cheers

Re: [PATCH] PCI: Allow PCI express root ports to find themselves

[Michael Ellerman]

Thierry Reding  writes:

> From: Thierry Reding 
>
> If the pci_find_pcie_root_port() function is called on a root port
> itself, return the root port rather than NULL.
>
> This effectively reverts commit 0e405232871d6 ("PCI: fix oops when
> try to find Root Port for a PCI device") which added an extra check
> that would now be redundant.
>
> Fixes: a99b646afa8a ("PCI: Disable PCIe Relaxed Ordering if unsupported")
> Fixes: c56d4450eb68 ("PCI: Turn off Request Attributes to avoid Chelsio T5 
> Completion erratum")
> Signed-off-by: Thierry Reding 
> ---
> This applies on top of and was tested on next-20170817.
>
> Michael, it'd be great if you could test this one again to clarify
> whether or not the fix that's already in Linus' tree is still needed, or
> whether it's indeed obsoleted by this patch.

This works fine for me, applied on top of Linus' tree (d33a2a914319).

cheers

[PATCH] usb: xhci: Renesas uPD720202 needs short TX quirk

[Kai-Heng Feng]

When plugging Logitech C920 webcam, warning messages filled up dmesg:
[77117.655018] xhci_hcd :0c:00.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[77117.659018] xhci_hcd :0c:00.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[77122.622952] handle_tx_event: 541 callbacks suppressed

No more warning messages with XHCI_TRUST_TX_LENGTH applied.

BugLink: https://bugs.launchpad.net/bugs/1710548
Signed-off-by: Kai-Heng Feng 
---
 drivers/usb/host/xhci-pci.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 8071c8fdd15e..8566b43e19ba 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -202,8 +202,10 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
xhci->quirks |= XHCI_BROKEN_STREAMS;
}
if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
-   pdev->device == 0x0015)
+   pdev->device == 0x0015) {
xhci->quirks |= XHCI_RESET_ON_RESUME;
+   xhci->quirks |= XHCI_TRUST_TX_LENGTH;
+   }
if (pdev->vendor == PCI_VENDOR_ID_VIA)
xhci->quirks |= XHCI_RESET_ON_RESUME;
 
-- 
2.14.1

[PATCH] usb: xhci: Renesas uPD720202 needs short TX quirk

[Kai-Heng Feng]

When plugging Logitech C920 webcam, warning messages filled up dmesg:
[77117.655018] xhci_hcd :0c:00.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[77117.659018] xhci_hcd :0c:00.0: WARN Successful completion on short TX: 
needs XHCI_TRUST_TX_LENGTH quirk?
[77122.622952] handle_tx_event: 541 callbacks suppressed

No more warning messages with XHCI_TRUST_TX_LENGTH applied.

BugLink: https://bugs.launchpad.net/bugs/1710548
Signed-off-by: Kai-Heng Feng 
---
 drivers/usb/host/xhci-pci.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 8071c8fdd15e..8566b43e19ba 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -202,8 +202,10 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
xhci->quirks |= XHCI_BROKEN_STREAMS;
}
if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
-   pdev->device == 0x0015)
+   pdev->device == 0x0015) {
xhci->quirks |= XHCI_RESET_ON_RESUME;
+   xhci->quirks |= XHCI_TRUST_TX_LENGTH;
+   }
if (pdev->vendor == PCI_VENDOR_ID_VIA)
xhci->quirks |= XHCI_RESET_ON_RESUME;
 
-- 
2.14.1

Re: [PATCH] cpufreq: Don't send callback pointer to cpufreq_add_update_util_hook()

[Viresh Kumar]

On 17-08-17, 17:31, Rafael J. Wysocki wrote:
> On Thursday, August 17, 2017 2:04:48 PM CEST Viresh Kumar wrote:
> > The callers already have the structure (struct update_util_data) where
> > the function pointer is saved by cpufreq_add_update_util_hook(). And its
> > better if the callers fill it themselves, as they can do it from the
> > governor->init() callback then, which is called only once per policy
> > lifetime rather than doing it from governor->start which can get called
> > multiple times.
> 
> So what problem exactly is this addressing?

Its not fixing any problem really, but is rather just a cleanup patch.
I had a look at include/linux/sched/cpufreq.h and got confused for a
moment:

struct update_util_data {
   void (*func)(struct update_util_data *data, u64 time, unsigned int 
flags);
};

void cpufreq_add_update_util_hook(int cpu, struct update_util_data *data,
   void (*func)(struct update_util_data *data, u64 time,
unsigned int flags));


It wasn't quite straight-forward to understand why we needed to pass
both "data" and "func", while "data" should already have "func" set
within it. And then I realized that cpufreq_add_update_util_hook() is
actually setting that field.

Filling the pointer from the callers is probably better because:
- It makes it more readable.
- We have to pass one less argument and the function prototype becomes
  quite short.
- The callers don't have to set the data->func pointer from the
  governor->start() callback now and can do it only once from
  governor->init(). ->start(), stop() callbacks can get called a lot,
  for example with CPU hotplug.

But yeah, its all trivial stuff. No big problem solved.

-- 
viresh

Re: [PATCH] cpufreq: Don't send callback pointer to cpufreq_add_update_util_hook()

[Viresh Kumar]

On 17-08-17, 17:31, Rafael J. Wysocki wrote:
> On Thursday, August 17, 2017 2:04:48 PM CEST Viresh Kumar wrote:
> > The callers already have the structure (struct update_util_data) where
> > the function pointer is saved by cpufreq_add_update_util_hook(). And its
> > better if the callers fill it themselves, as they can do it from the
> > governor->init() callback then, which is called only once per policy
> > lifetime rather than doing it from governor->start which can get called
> > multiple times.
> 
> So what problem exactly is this addressing?

Its not fixing any problem really, but is rather just a cleanup patch.
I had a look at include/linux/sched/cpufreq.h and got confused for a
moment:

struct update_util_data {
   void (*func)(struct update_util_data *data, u64 time, unsigned int 
flags);
};

void cpufreq_add_update_util_hook(int cpu, struct update_util_data *data,
   void (*func)(struct update_util_data *data, u64 time,
unsigned int flags));


It wasn't quite straight-forward to understand why we needed to pass
both "data" and "func", while "data" should already have "func" set
within it. And then I realized that cpufreq_add_update_util_hook() is
actually setting that field.

Filling the pointer from the callers is probably better because:
- It makes it more readable.
- We have to pass one less argument and the function prototype becomes
  quite short.
- The callers don't have to set the data->func pointer from the
  governor->start() callback now and can do it only once from
  governor->init(). ->start(), stop() callbacks can get called a lot,
  for example with CPU hotplug.

But yeah, its all trivial stuff. No big problem solved.

-- 
viresh

[PATCH] tpm/tpm_crb: Access locality for non-ACPI and non-SMC start method

[Jiandi An]

For ARM64, the locality is handled by Trust Zone in FW.
The layout does not have crb_regs_head.  It is hitting
the following line.
dev_warn(dev, FW_BUG "Bad ACPI memory layout");

Current code excludes CRB_FL_ACPI_START and when
CRB_FL_CRB_SMC_START is added around the same time
locality support is added, it should also be excluded.

For goIdle and cmdReady where code was excluding
CRB_FL_ACPI_START only (do nothing for ACPI start method),
CRB_FL_CRB_SMC_START was also excluded as ARM64 SMC start
method does not have TPM_CRB_CTRL_REQ.
Change if confition to white list instead of black list.

Signed-off-by: Jiandi An 
---
 drivers/char/tpm/tpm_crb.c | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 8f0a98d..cbfdbdde 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -128,18 +128,16 @@ struct tpm2_crb_smc {
  * Anyhow, we do not wait here as a consequent CMD_READY request
  * will be handled correctly even if idle was not completed.
  *
- * The function does nothing for devices with ACPI-start method.
+ * The function does nothing for devices with ACPI-start method
+ * or SMC-start method.
  *
  * Return: 0 always
  */
 static int __maybe_unused crb_go_idle(struct device *dev, struct crb_priv 
*priv)
 {
-   if ((priv->flags & CRB_FL_ACPI_START) ||
-   (priv->flags & CRB_FL_CRB_SMC_START))
-   return 0;
-
-   iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs_t->ctrl_req);
-   /* we don't really care when this settles */
+   if ((priv->flags & (CRB_FL_ACPI_START | CRB_FL_CRB_SMC_START)) == 0)
+   iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs_t->ctrl_req);
+   /* we don't really care when this settles */
 
return 0;
 }
@@ -174,23 +172,22 @@ static bool crb_wait_for_reg_32(u32 __iomem *reg, u32 
mask, u32 value,
  * The device should respond within TIMEOUT_C.
  *
  * The function does nothing for devices with ACPI-start method
+ * or SMC-start method.
  *
  * Return: 0 on success -ETIME on timeout;
  */
 static int __maybe_unused crb_cmd_ready(struct device *dev,
struct crb_priv *priv)
 {
-   if ((priv->flags & CRB_FL_ACPI_START) ||
-   (priv->flags & CRB_FL_CRB_SMC_START))
-   return 0;
-
-   iowrite32(CRB_CTRL_REQ_CMD_READY, >regs_t->ctrl_req);
-   if (!crb_wait_for_reg_32(>regs_t->ctrl_req,
-CRB_CTRL_REQ_CMD_READY /* mask */,
-0, /* value */
-TPM2_TIMEOUT_C)) {
-   dev_warn(dev, "cmdReady timed out\n");
-   return -ETIME;
+   if ((priv->flags & (CRB_FL_ACPI_START | CRB_FL_CRB_SMC_START)) == 0) {
+   iowrite32(CRB_CTRL_REQ_CMD_READY, >regs_t->ctrl_req);
+   if (!crb_wait_for_reg_32(>regs_t->ctrl_req,
+CRB_CTRL_REQ_CMD_READY /* mask */,
+0, /* value */
+TPM2_TIMEOUT_C)) {
+   dev_warn(dev, "cmdReady timed out\n");
+   return -ETIME;
+   }
}
 
return 0;
@@ -458,7 +455,7 @@ static int crb_map_io(struct acpi_device *device, struct 
crb_priv *priv,
 * the control area, as one nice sane region except for some older
 * stuff that puts the control area outside the ACPI IO region.
 */
-   if (!(priv->flags & CRB_FL_ACPI_START)) {
+   if ((priv->flags & (CRB_FL_ACPI_START | CRB_FL_CRB_SMC_START)) == 0) {
if (buf->control_address == io_res.start +
sizeof(*priv->regs_h))
priv->regs_h = priv->iobase;
-- 
Jiandi An
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH] tpm/tpm_crb: Access locality for non-ACPI and non-SMC start method

[Jiandi An]

For ARM64, the locality is handled by Trust Zone in FW.
The layout does not have crb_regs_head.  It is hitting
the following line.
dev_warn(dev, FW_BUG "Bad ACPI memory layout");

Current code excludes CRB_FL_ACPI_START and when
CRB_FL_CRB_SMC_START is added around the same time
locality support is added, it should also be excluded.

For goIdle and cmdReady where code was excluding
CRB_FL_ACPI_START only (do nothing for ACPI start method),
CRB_FL_CRB_SMC_START was also excluded as ARM64 SMC start
method does not have TPM_CRB_CTRL_REQ.
Change if confition to white list instead of black list.

Signed-off-by: Jiandi An 
---
 drivers/char/tpm/tpm_crb.c | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 8f0a98d..cbfdbdde 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -128,18 +128,16 @@ struct tpm2_crb_smc {
  * Anyhow, we do not wait here as a consequent CMD_READY request
  * will be handled correctly even if idle was not completed.
  *
- * The function does nothing for devices with ACPI-start method.
+ * The function does nothing for devices with ACPI-start method
+ * or SMC-start method.
  *
  * Return: 0 always
  */
 static int __maybe_unused crb_go_idle(struct device *dev, struct crb_priv 
*priv)
 {
-   if ((priv->flags & CRB_FL_ACPI_START) ||
-   (priv->flags & CRB_FL_CRB_SMC_START))
-   return 0;
-
-   iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs_t->ctrl_req);
-   /* we don't really care when this settles */
+   if ((priv->flags & (CRB_FL_ACPI_START | CRB_FL_CRB_SMC_START)) == 0)
+   iowrite32(CRB_CTRL_REQ_GO_IDLE, >regs_t->ctrl_req);
+   /* we don't really care when this settles */
 
return 0;
 }
@@ -174,23 +172,22 @@ static bool crb_wait_for_reg_32(u32 __iomem *reg, u32 
mask, u32 value,
  * The device should respond within TIMEOUT_C.
  *
  * The function does nothing for devices with ACPI-start method
+ * or SMC-start method.
  *
  * Return: 0 on success -ETIME on timeout;
  */
 static int __maybe_unused crb_cmd_ready(struct device *dev,
struct crb_priv *priv)
 {
-   if ((priv->flags & CRB_FL_ACPI_START) ||
-   (priv->flags & CRB_FL_CRB_SMC_START))
-   return 0;
-
-   iowrite32(CRB_CTRL_REQ_CMD_READY, >regs_t->ctrl_req);
-   if (!crb_wait_for_reg_32(>regs_t->ctrl_req,
-CRB_CTRL_REQ_CMD_READY /* mask */,
-0, /* value */
-TPM2_TIMEOUT_C)) {
-   dev_warn(dev, "cmdReady timed out\n");
-   return -ETIME;
+   if ((priv->flags & (CRB_FL_ACPI_START | CRB_FL_CRB_SMC_START)) == 0) {
+   iowrite32(CRB_CTRL_REQ_CMD_READY, >regs_t->ctrl_req);
+   if (!crb_wait_for_reg_32(>regs_t->ctrl_req,
+CRB_CTRL_REQ_CMD_READY /* mask */,
+0, /* value */
+TPM2_TIMEOUT_C)) {
+   dev_warn(dev, "cmdReady timed out\n");
+   return -ETIME;
+   }
}
 
return 0;
@@ -458,7 +455,7 @@ static int crb_map_io(struct acpi_device *device, struct 
crb_priv *priv,
 * the control area, as one nice sane region except for some older
 * stuff that puts the control area outside the ACPI IO region.
 */
-   if (!(priv->flags & CRB_FL_ACPI_START)) {
+   if ((priv->flags & (CRB_FL_ACPI_START | CRB_FL_CRB_SMC_START)) == 0) {
if (buf->control_address == io_res.start +
sizeof(*priv->regs_h))
priv->regs_h = priv->iobase;
-- 
Jiandi An
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH] vfio: Stall vfio_del_group_dev() for container group detach

[Alex Williamson]

When the user unbinds the last device of a group from a vfio bus
driver, the devices within that group should be available for other
purposes.  We currently have a race that makes this generally, but
not always true.  The device can be unbound from the vfio bus driver,
but remaining IOMMU context of the group attached to the container
can result in errors as the next driver configures DMA for the device.

Wait for the group to be detached from the IOMMU backend before
allowing the bus driver remove callback to complete.

Signed-off-by: Alex Williamson 
---
 drivers/vfio/vfio.c |   20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 330d50582f40..fb78e0becd1b 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -85,6 +85,7 @@ struct vfio_group {
struct list_headunbound_list;
struct mutexunbound_lock;
atomic_topened;
+   wait_queue_head_t   container_q;
boolnoiommu;
struct kvm  *kvm;
struct blocking_notifier_head   notifier;
@@ -337,6 +338,7 @@ static struct vfio_group *vfio_create_group(struct 
iommu_group *iommu_group)
mutex_init(>unbound_lock);
atomic_set(>container_users, 0);
atomic_set(>opened, 0);
+   init_waitqueue_head(>container_q);
group->iommu_group = iommu_group;
 #ifdef CONFIG_VFIO_NOIOMMU
group->noiommu = (iommu_group_get_iommudata(iommu_group) == );
@@ -993,6 +995,23 @@ void *vfio_del_group_dev(struct device *dev)
}
} while (ret <= 0);
 
+   /*
+* In order to support multiple devices per group, devices can be
+* plucked from the group while other devices in the group are still
+* in use.  The container persists with this group and those remaining
+* devices still attached.  If the user creates an isolation violation
+* by binding this device to another driver while the group is still in
+* use, that's their fault.  However, in the case of removing the last,
+* or potentially the only, device in the group there can be no other
+* in-use devices in the group.  The user has done their due diligence
+* and we should lay no claims to those devices.  In order to do that,
+* we need to make sure the group is detached from the container.
+* Without this stall, we're potentially racing with a user process
+* that may attempt to immediately bind this device to another driver.
+*/
+   if (list_empty(>device_list))
+   wait_event(group->container_q, !group->container);
+
vfio_group_put(group);
 
return device_data;
@@ -1298,6 +1317,7 @@ static void __vfio_group_unset_container(struct 
vfio_group *group)
  group->iommu_group);
 
group->container = NULL;
+   wake_up(>container_q);
list_del(>container_next);
 
/* Detaching the last group deprivileges a container, remove iommu */

[PATCH] vfio: Stall vfio_del_group_dev() for container group detach

[Alex Williamson]

When the user unbinds the last device of a group from a vfio bus
driver, the devices within that group should be available for other
purposes.  We currently have a race that makes this generally, but
not always true.  The device can be unbound from the vfio bus driver,
but remaining IOMMU context of the group attached to the container
can result in errors as the next driver configures DMA for the device.

Wait for the group to be detached from the IOMMU backend before
allowing the bus driver remove callback to complete.

Signed-off-by: Alex Williamson 
---
 drivers/vfio/vfio.c |   20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 330d50582f40..fb78e0becd1b 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -85,6 +85,7 @@ struct vfio_group {
struct list_headunbound_list;
struct mutexunbound_lock;
atomic_topened;
+   wait_queue_head_t   container_q;
boolnoiommu;
struct kvm  *kvm;
struct blocking_notifier_head   notifier;
@@ -337,6 +338,7 @@ static struct vfio_group *vfio_create_group(struct 
iommu_group *iommu_group)
mutex_init(>unbound_lock);
atomic_set(>container_users, 0);
atomic_set(>opened, 0);
+   init_waitqueue_head(>container_q);
group->iommu_group = iommu_group;
 #ifdef CONFIG_VFIO_NOIOMMU
group->noiommu = (iommu_group_get_iommudata(iommu_group) == );
@@ -993,6 +995,23 @@ void *vfio_del_group_dev(struct device *dev)
}
} while (ret <= 0);
 
+   /*
+* In order to support multiple devices per group, devices can be
+* plucked from the group while other devices in the group are still
+* in use.  The container persists with this group and those remaining
+* devices still attached.  If the user creates an isolation violation
+* by binding this device to another driver while the group is still in
+* use, that's their fault.  However, in the case of removing the last,
+* or potentially the only, device in the group there can be no other
+* in-use devices in the group.  The user has done their due diligence
+* and we should lay no claims to those devices.  In order to do that,
+* we need to make sure the group is detached from the container.
+* Without this stall, we're potentially racing with a user process
+* that may attempt to immediately bind this device to another driver.
+*/
+   if (list_empty(>device_list))
+   wait_event(group->container_q, !group->container);
+
vfio_group_put(group);
 
return device_data;
@@ -1298,6 +1317,7 @@ static void __vfio_group_unset_container(struct 
vfio_group *group)
  group->iommu_group);
 
group->container = NULL;
+   wake_up(>container_q);
list_del(>container_next);
 
/* Detaching the last group deprivileges a container, remove iommu */

[PATCH] pinctrl: mediatek: update PCIe mux data for MT7623

[Ryder Lee]

MT2701 shares the same driver with MT7623, but there is a slight difference
between their pin functions (e.g., PCIe), so we update the different parts
in pinmux table.

Doing so, SoC could choose the correct mux setting via their own pinfun.h.

Signed-off-by: Ryder Lee 
CC: Biao Huang 
---
 drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h 
b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h
index f906420..1035df4 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h
@@ -223,6 +223,8 @@
MTK_EINT_FUNCTION(0, 0),
MTK_FUNCTION(0, "GPIO22"),
MTK_FUNCTION(1, "UCTS0"),
+   /* MT7623 take function 2 as PCIE0_PERST_N */
+   MTK_FUNCTION(2, "PCIE0_PERST_N"),
MTK_FUNCTION(3, "KCOL3"),
MTK_FUNCTION(4, "CONN_DSP_JDO"),
MTK_FUNCTION(5, "EXT_FRAME_SYNC"),
@@ -235,6 +237,8 @@
MTK_EINT_FUNCTION(0, 1),
MTK_FUNCTION(0, "GPIO23"),
MTK_FUNCTION(1, "URTS0"),
+   /* MT7623 take function 2 as PCIE1_PERST_N */
+   MTK_FUNCTION(2, "PCIE1_PERST_N"),
MTK_FUNCTION(3, "KCOL2"),
MTK_FUNCTION(4, "CONN_MCU_TDO"),
MTK_FUNCTION(5, "EXT_FRAME_SYNC"),
@@ -247,6 +251,8 @@
MTK_EINT_FUNCTION(0, 2),
MTK_FUNCTION(0, "GPIO24"),
MTK_FUNCTION(1, "UCTS1"),
+   /* MT7623 take function 2 as PCIE2_PERST_N */
+   MTK_FUNCTION(2, "PCIE2_PERST_N"),
MTK_FUNCTION(3, "KCOL1"),
MTK_FUNCTION(4, "CONN_MCU_DBGACK_N"),
MTK_FUNCTION(7, "DBG_MON_A[28]"),
@@ -308,6 +314,8 @@
MTK_FUNCTION(3, "KROW0"),
MTK_FUNCTION(4, "CONN_MCU_TMS"),
MTK_FUNCTION(5, "CONN_MCU_AICE_JMSC"),
+   /* MT7623 take function 6 as PCIE2_PERST_N */
+   MTK_FUNCTION(6, "PCIE2_PERST_N"),
MTK_FUNCTION(7, "DBG_MON_A[23]"),
MTK_FUNCTION(14, "PCIE2_PERST_N")
),
@@ -1787,6 +1795,8 @@
MTK_FUNCTION(0, "GPIO208"),
MTK_FUNCTION(1, "AUD_EXT_CK1"),
MTK_FUNCTION(2, "PWM0"),
+   /* MT7623 take function 3 as PCIE0_PERST_N */
+   MTK_FUNCTION(3, "PCIE0_PERST_N"),
MTK_FUNCTION(4, "ANT_SEL5"),
MTK_FUNCTION(5, "DISP_PWM"),
MTK_FUNCTION(7, "DBG_MON_A[31]"),
@@ -1799,6 +1809,8 @@
MTK_FUNCTION(0, "GPIO209"),
MTK_FUNCTION(1, "AUD_EXT_CK2"),
MTK_FUNCTION(2, "MSDC1_WP"),
+   /* MT7623 take function 3 as PCIE1_PERST_N */
+   MTK_FUNCTION(3, "PCIE1_PERST_N"),
MTK_FUNCTION(5, "PWM1"),
MTK_FUNCTION(7, "DBG_MON_A[32]"),
MTK_FUNCTION(11, "PCIE1_PERST_N")
-- 
1.9.1

[PATCH] pinctrl: mediatek: update PCIe mux data for MT7623

[Ryder Lee]

MT2701 shares the same driver with MT7623, but there is a slight difference
between their pin functions (e.g., PCIe), so we update the different parts
in pinmux table.

Doing so, SoC could choose the correct mux setting via their own pinfun.h.

Signed-off-by: Ryder Lee 
CC: Biao Huang 
---
 drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h 
b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h
index f906420..1035df4 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h
@@ -223,6 +223,8 @@
MTK_EINT_FUNCTION(0, 0),
MTK_FUNCTION(0, "GPIO22"),
MTK_FUNCTION(1, "UCTS0"),
+   /* MT7623 take function 2 as PCIE0_PERST_N */
+   MTK_FUNCTION(2, "PCIE0_PERST_N"),
MTK_FUNCTION(3, "KCOL3"),
MTK_FUNCTION(4, "CONN_DSP_JDO"),
MTK_FUNCTION(5, "EXT_FRAME_SYNC"),
@@ -235,6 +237,8 @@
MTK_EINT_FUNCTION(0, 1),
MTK_FUNCTION(0, "GPIO23"),
MTK_FUNCTION(1, "URTS0"),
+   /* MT7623 take function 2 as PCIE1_PERST_N */
+   MTK_FUNCTION(2, "PCIE1_PERST_N"),
MTK_FUNCTION(3, "KCOL2"),
MTK_FUNCTION(4, "CONN_MCU_TDO"),
MTK_FUNCTION(5, "EXT_FRAME_SYNC"),
@@ -247,6 +251,8 @@
MTK_EINT_FUNCTION(0, 2),
MTK_FUNCTION(0, "GPIO24"),
MTK_FUNCTION(1, "UCTS1"),
+   /* MT7623 take function 2 as PCIE2_PERST_N */
+   MTK_FUNCTION(2, "PCIE2_PERST_N"),
MTK_FUNCTION(3, "KCOL1"),
MTK_FUNCTION(4, "CONN_MCU_DBGACK_N"),
MTK_FUNCTION(7, "DBG_MON_A[28]"),
@@ -308,6 +314,8 @@
MTK_FUNCTION(3, "KROW0"),
MTK_FUNCTION(4, "CONN_MCU_TMS"),
MTK_FUNCTION(5, "CONN_MCU_AICE_JMSC"),
+   /* MT7623 take function 6 as PCIE2_PERST_N */
+   MTK_FUNCTION(6, "PCIE2_PERST_N"),
MTK_FUNCTION(7, "DBG_MON_A[23]"),
MTK_FUNCTION(14, "PCIE2_PERST_N")
),
@@ -1787,6 +1795,8 @@
MTK_FUNCTION(0, "GPIO208"),
MTK_FUNCTION(1, "AUD_EXT_CK1"),
MTK_FUNCTION(2, "PWM0"),
+   /* MT7623 take function 3 as PCIE0_PERST_N */
+   MTK_FUNCTION(3, "PCIE0_PERST_N"),
MTK_FUNCTION(4, "ANT_SEL5"),
MTK_FUNCTION(5, "DISP_PWM"),
MTK_FUNCTION(7, "DBG_MON_A[31]"),
@@ -1799,6 +1809,8 @@
MTK_FUNCTION(0, "GPIO209"),
MTK_FUNCTION(1, "AUD_EXT_CK2"),
MTK_FUNCTION(2, "MSDC1_WP"),
+   /* MT7623 take function 3 as PCIE1_PERST_N */
+   MTK_FUNCTION(3, "PCIE1_PERST_N"),
MTK_FUNCTION(5, "PWM1"),
MTK_FUNCTION(7, "DBG_MON_A[32]"),
MTK_FUNCTION(11, "PCIE1_PERST_N")
-- 
1.9.1

[PATCH v1 0/2] clk: rockchip: rk3228: add SCLK_SDIO_SRC clk id

[Elaine Zhang]

This patch exports sdio src clock for dts reference.

Elaine Zhang (2):
  clk: rockchip: add rk3228 sclk_sdio_src ID
  clk: rockchip: rk3228: add SCLK_SDIO_SRC clk id

 drivers/clk/rockchip/clk-rk3228.c  | 2 +-
 include/dt-bindings/clock/rk3228-cru.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH v1 0/2] clk: rockchip: rk3228: add SCLK_SDIO_SRC clk id

[Elaine Zhang]

This patch exports sdio src clock for dts reference.

Elaine Zhang (2):
  clk: rockchip: add rk3228 sclk_sdio_src ID
  clk: rockchip: rk3228: add SCLK_SDIO_SRC clk id

 drivers/clk/rockchip/clk-rk3228.c  | 2 +-
 include/dt-bindings/clock/rk3228-cru.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH v1 1/2] clk: rockchip: add rk3228 sclk_sdio_src ID

[Elaine Zhang]

This patch exports sdio src clock for dts reference.

Signed-off-by: Elaine Zhang 
---
 include/dt-bindings/clock/rk3228-cru.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/rk3228-cru.h 
b/include/dt-bindings/clock/rk3228-cru.h
index 56f841c22801..55655ab0a4c4 100644
--- a/include/dt-bindings/clock/rk3228-cru.h
+++ b/include/dt-bindings/clock/rk3228-cru.h
@@ -49,6 +49,7 @@
 #define SCLK_EMMC_DRV  117
 #define SCLK_SDMMC_SAMPLE  118
 #define SCLK_SDIO_SAMPLE   119
+#define SCLK_SDIO_SRC  120
 #define SCLK_EMMC_SAMPLE   121
 #define SCLK_VOP   122
 #define SCLK_HDMI_HDCP 123
-- 
1.9.1

[PATCH v1 1/2] clk: rockchip: add rk3228 sclk_sdio_src ID

[Elaine Zhang]

This patch exports sdio src clock for dts reference.

Signed-off-by: Elaine Zhang 
---
 include/dt-bindings/clock/rk3228-cru.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/rk3228-cru.h 
b/include/dt-bindings/clock/rk3228-cru.h
index 56f841c22801..55655ab0a4c4 100644
--- a/include/dt-bindings/clock/rk3228-cru.h
+++ b/include/dt-bindings/clock/rk3228-cru.h
@@ -49,6 +49,7 @@
 #define SCLK_EMMC_DRV  117
 #define SCLK_SDMMC_SAMPLE  118
 #define SCLK_SDIO_SAMPLE   119
+#define SCLK_SDIO_SRC  120
 #define SCLK_EMMC_SAMPLE   121
 #define SCLK_VOP   122
 #define SCLK_HDMI_HDCP 123
-- 
1.9.1

[PATCH v1 2/2] clk: rockchip: rk3228: add SCLK_SDIO_SRC clk id

[Elaine Zhang]

In some special circumstances, may be need to reparent clk for sclk_sdio_src.

Signed-off-by: Elaine Zhang 
---
 drivers/clk/rockchip/clk-rk3228.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3228.c 
b/drivers/clk/rockchip/clk-rk3228.c
index bb405d9044a3..11e7f2d1c054 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -391,7 +391,7 @@ enum rk3228_plls {
RK2928_CLKSEL_CON(11), 8, 2, MFLAGS, 0, 8, DFLAGS,
RK2928_CLKGATE_CON(2), 11, GFLAGS),
 
-   COMPOSITE_NODIV(0, "sclk_sdio_src", mux_mmc_src_p, 0,
+   COMPOSITE_NODIV(SCLK_SDIO_SRC, "sclk_sdio_src", mux_mmc_src_p, 0,
RK2928_CLKSEL_CON(11), 10, 2, MFLAGS,
RK2928_CLKGATE_CON(2), 13, GFLAGS),
DIV(SCLK_SDIO, "sclk_sdio", "sclk_sdio_src", 0,
-- 
1.9.1

[PATCH v1 2/2] clk: rockchip: rk3228: add SCLK_SDIO_SRC clk id

[Elaine Zhang]

In some special circumstances, may be need to reparent clk for sclk_sdio_src.

Signed-off-by: Elaine Zhang 
---
 drivers/clk/rockchip/clk-rk3228.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3228.c 
b/drivers/clk/rockchip/clk-rk3228.c
index bb405d9044a3..11e7f2d1c054 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -391,7 +391,7 @@ enum rk3228_plls {
RK2928_CLKSEL_CON(11), 8, 2, MFLAGS, 0, 8, DFLAGS,
RK2928_CLKGATE_CON(2), 11, GFLAGS),
 
-   COMPOSITE_NODIV(0, "sclk_sdio_src", mux_mmc_src_p, 0,
+   COMPOSITE_NODIV(SCLK_SDIO_SRC, "sclk_sdio_src", mux_mmc_src_p, 0,
RK2928_CLKSEL_CON(11), 10, 2, MFLAGS,
RK2928_CLKGATE_CON(2), 13, GFLAGS),
DIV(SCLK_SDIO, "sclk_sdio", "sclk_sdio_src", 0,
-- 
1.9.1

[PATCH] mm/hmm: avoid bloating arch that do not make use of HMM

[jglisse]

From: Jérôme Glisse 

This move all new code including new page migration helper behind
kernel Kconfig option so that there is no codee bloat for arch or
user that do not want to use HMM or any of its associated features.

arm allyesconfig (without all the patchset, then with and this patch):
   textdata bss dec hex filename
837218964651113127582964157815991   96814b7 
../without/vmlinux
837223644651113127582964157816459   968168b vmlinux

Signed-off-by: Jérôme Glisse 
Cc: Dan Williams 
Cc: Andrew Morton 
---
 include/linux/memremap.h | 22 +++---
 include/linux/migrate.h  | 13 +
 include/linux/mm.h   | 26 +-
 mm/Kconfig   |  4 
 mm/Makefile  |  3 ++-
 mm/hmm.c |  6 +++---
 mm/migrate.c |  2 ++
 7 files changed, 48 insertions(+), 28 deletions(-)

diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index f8ee1c73ad2d..79f8ba7c3894 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -138,18 +138,6 @@ void *devm_memremap_pages(struct device *dev, struct 
resource *res,
 struct dev_pagemap *find_dev_pagemap(resource_size_t phys);
 
 static inline bool is_zone_device_page(const struct page *page);
-
-static inline bool is_device_private_page(const struct page *page)
-{
-   return is_zone_device_page(page) &&
-   page->pgmap->type == MEMORY_DEVICE_PRIVATE;
-}
-
-static inline bool is_device_public_page(const struct page *page)
-{
-   return is_zone_device_page(page) &&
-   page->pgmap->type == MEMORY_DEVICE_PUBLIC;
-}
 #else
 static inline void *devm_memremap_pages(struct device *dev,
struct resource *res, struct percpu_ref *ref,
@@ -168,17 +156,21 @@ static inline struct dev_pagemap 
*find_dev_pagemap(resource_size_t phys)
 {
return NULL;
 }
+#endif
 
+#if defined(CONFIG_DEVICE_PRIVATE) || defined(CONFIG_DEVICE_PUBLIC)
 static inline bool is_device_private_page(const struct page *page)
 {
-   return false;
+   return is_zone_device_page(page) &&
+   page->pgmap->type == MEMORY_DEVICE_PRIVATE;
 }
 
 static inline bool is_device_public_page(const struct page *page)
 {
-   return false;
+   return is_zone_device_page(page) &&
+   page->pgmap->type == MEMORY_DEVICE_PUBLIC;
 }
-#endif
+#endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
 
 /**
  * get_dev_pagemap() - take a new live reference on the dev_pagemap for @pfn
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index d4e6d12a0b40..643c7ae7d7b4 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -265,6 +265,7 @@ struct migrate_vma_ops {
 void *private);
 };
 
+#if defined(CONFIG_MIGRATE_VMA_HELPER)
 int migrate_vma(const struct migrate_vma_ops *ops,
struct vm_area_struct *vma,
unsigned long start,
@@ -272,6 +273,18 @@ int migrate_vma(const struct migrate_vma_ops *ops,
unsigned long *src,
unsigned long *dst,
void *private);
+#else
+static inline int migrate_vma(const struct migrate_vma_ops *ops,
+ struct vm_area_struct *vma,
+ unsigned long start,
+ unsigned long end,
+ unsigned long *src,
+ unsigned long *dst,
+ void *private)
+{
+   return -EINVAL;
+}
+#endif /* IS_ENABLED(CONFIG_MIGRATE_VMA_HELPER) */
 
 #endif /* CONFIG_MIGRATION */
 
diff --git a/include/linux/mm.h b/include/linux/mm.h
index d1d161efefa0..663a2916a3bf 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -796,18 +796,27 @@ static inline bool is_zone_device_page(const struct page 
*page)
 }
 #endif
 
-#if IS_ENABLED(CONFIG_DEVICE_PRIVATE) ||  IS_ENABLED(CONFIG_DEVICE_PUBLIC)
+#if defined(CONFIG_DEVICE_PRIVATE) || defined(CONFIG_DEVICE_PUBLIC)
 void put_zone_device_private_or_public_page(struct page *page);
-#else
+DECLARE_STATIC_KEY_FALSE(device_private_key);
+#define IS_HMM_ENABLED static_branch_unlikely(_private_key)
+static inline bool is_device_private_page(const struct page *page);
+static inline bool is_device_public_page(const struct page *page);
+#else /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
 static inline void put_zone_device_private_or_public_page(struct page *page)
 {
 }
+#define IS_HMM_ENABLED 0
+static inline bool is_device_private_page(const struct page *page)
+{
+   return false;
+}
+static inline bool is_device_public_page(const struct page *page)
+{
+   return false;
+}
 #endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
 
-static inline bool is_device_private_page(const struct page *page);
-static inline bool 

[PATCH] mm/hmm: avoid bloating arch that do not make use of HMM

[jglisse]

From: Jérôme Glisse 

This move all new code including new page migration helper behind
kernel Kconfig option so that there is no codee bloat for arch or
user that do not want to use HMM or any of its associated features.

arm allyesconfig (without all the patchset, then with and this patch):
   textdata bss dec hex filename
837218964651113127582964157815991   96814b7 
../without/vmlinux
837223644651113127582964157816459   968168b vmlinux

Signed-off-by: Jérôme Glisse 
Cc: Dan Williams 
Cc: Andrew Morton 
---
 include/linux/memremap.h | 22 +++---
 include/linux/migrate.h  | 13 +
 include/linux/mm.h   | 26 +-
 mm/Kconfig   |  4 
 mm/Makefile  |  3 ++-
 mm/hmm.c |  6 +++---
 mm/migrate.c |  2 ++
 7 files changed, 48 insertions(+), 28 deletions(-)

diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index f8ee1c73ad2d..79f8ba7c3894 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -138,18 +138,6 @@ void *devm_memremap_pages(struct device *dev, struct 
resource *res,
 struct dev_pagemap *find_dev_pagemap(resource_size_t phys);
 
 static inline bool is_zone_device_page(const struct page *page);
-
-static inline bool is_device_private_page(const struct page *page)
-{
-   return is_zone_device_page(page) &&
-   page->pgmap->type == MEMORY_DEVICE_PRIVATE;
-}
-
-static inline bool is_device_public_page(const struct page *page)
-{
-   return is_zone_device_page(page) &&
-   page->pgmap->type == MEMORY_DEVICE_PUBLIC;
-}
 #else
 static inline void *devm_memremap_pages(struct device *dev,
struct resource *res, struct percpu_ref *ref,
@@ -168,17 +156,21 @@ static inline struct dev_pagemap 
*find_dev_pagemap(resource_size_t phys)
 {
return NULL;
 }
+#endif
 
+#if defined(CONFIG_DEVICE_PRIVATE) || defined(CONFIG_DEVICE_PUBLIC)
 static inline bool is_device_private_page(const struct page *page)
 {
-   return false;
+   return is_zone_device_page(page) &&
+   page->pgmap->type == MEMORY_DEVICE_PRIVATE;
 }
 
 static inline bool is_device_public_page(const struct page *page)
 {
-   return false;
+   return is_zone_device_page(page) &&
+   page->pgmap->type == MEMORY_DEVICE_PUBLIC;
 }
-#endif
+#endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
 
 /**
  * get_dev_pagemap() - take a new live reference on the dev_pagemap for @pfn
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index d4e6d12a0b40..643c7ae7d7b4 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -265,6 +265,7 @@ struct migrate_vma_ops {
 void *private);
 };
 
+#if defined(CONFIG_MIGRATE_VMA_HELPER)
 int migrate_vma(const struct migrate_vma_ops *ops,
struct vm_area_struct *vma,
unsigned long start,
@@ -272,6 +273,18 @@ int migrate_vma(const struct migrate_vma_ops *ops,
unsigned long *src,
unsigned long *dst,
void *private);
+#else
+static inline int migrate_vma(const struct migrate_vma_ops *ops,
+ struct vm_area_struct *vma,
+ unsigned long start,
+ unsigned long end,
+ unsigned long *src,
+ unsigned long *dst,
+ void *private)
+{
+   return -EINVAL;
+}
+#endif /* IS_ENABLED(CONFIG_MIGRATE_VMA_HELPER) */
 
 #endif /* CONFIG_MIGRATION */
 
diff --git a/include/linux/mm.h b/include/linux/mm.h
index d1d161efefa0..663a2916a3bf 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -796,18 +796,27 @@ static inline bool is_zone_device_page(const struct page 
*page)
 }
 #endif
 
-#if IS_ENABLED(CONFIG_DEVICE_PRIVATE) ||  IS_ENABLED(CONFIG_DEVICE_PUBLIC)
+#if defined(CONFIG_DEVICE_PRIVATE) || defined(CONFIG_DEVICE_PUBLIC)
 void put_zone_device_private_or_public_page(struct page *page);
-#else
+DECLARE_STATIC_KEY_FALSE(device_private_key);
+#define IS_HMM_ENABLED static_branch_unlikely(_private_key)
+static inline bool is_device_private_page(const struct page *page);
+static inline bool is_device_public_page(const struct page *page);
+#else /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
 static inline void put_zone_device_private_or_public_page(struct page *page)
 {
 }
+#define IS_HMM_ENABLED 0
+static inline bool is_device_private_page(const struct page *page)
+{
+   return false;
+}
+static inline bool is_device_public_page(const struct page *page)
+{
+   return false;
+}
 #endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
 
-static inline bool is_device_private_page(const struct page *page);
-static inline bool is_device_public_page(const struct page *page);
-
-DECLARE_STATIC_KEY_FALSE(device_private_key);
 
 static 

Re: [PATCH] kvm: VMX: do not use vm-exit instruction length for fast MMIO

[Yang Zhang]

On 2017/8/17 16:51, Wanpeng Li wrote:

2017-08-17 16:48 GMT+08:00 Yang Zhang :

On 2017/8/17 16:31, Wanpeng Li wrote:


2017-08-17 16:28 GMT+08:00 Wanpeng Li :


2017-08-17 16:07 GMT+08:00 Yang Zhang :


On 2017/8/17 0:56, Radim Krčmář wrote:



2017-08-16 17:10+0300, Michael S. Tsirkin:



On Wed, Aug 16, 2017 at 03:34:54PM +0200, Paolo Bonzini wrote:



Microsoft pointed out privately to me that KVM's handling of
KVM_FAST_MMIO_BUS is invalid.  Using skip_emulation_instruction is
invalid
in EPT misconfiguration vmexit handlers, because neither EPT
violations
nor misconfigurations are listed in the manual among the VM exits
that
set the VM-exit instruction length field.

While physical processors seem to set the field, this is not
architectural
and is just a side effect of the implementation.  I couldn't convince
myself of any condition on the exit qualification where VM-exit
instruction length "has" to be defined; there are no trap-like
VM-exits
that can be repurposed; and fault-like VM-exits such as
descriptor-table
exits provide no decoding information.  So I don't really see any way
to keep the full speedup.

What we can do is use EMULTYPE_SKIP; it only saves 200 clock cycles
because computing the physical RIP and reading the instruction is
expensive, but at least the eventfd is signaled before entering the
emulator.  This saves on latency.  While at it, don't check
breakpoints
when skipping the instruction, as presumably any side effect has been
exposed already.

Adding a hypercall or MSR write that does a fast MMIO write to a
physical
address would do it, but it adds hypervisor knowledge in virtio,
including
CPUID handling.  So it would be pretty ugly in the guest-side
implementation,
but if somebody wants to do it and the virtio side is acceptable to
the
virtio maintainers, I am okay with it.

Cc: Michael S. Tsirkin 
Cc: sta...@vger.kernel.org
Fixes: 68c3b4d1676d870f0453c31d5a52e7e65c7448ae
Suggested-by: Radim Krčmář 
Signed-off-by: Paolo Bonzini 




Jason (cc) who worked on the original optimization said he can
work to test the performance impact.
I suggest we don't rush this (it's been like this for 2 years),
and the issue seems to be largely theoretical.




Paolo, did Microsoft point it out because they hit the bug when running
KVM on Hyper-V?




Does this mean the nested emulation of EPT violation and
misconfiguration in
KVM side doesn't strictly follow the manual since we didn't hit the bug
in
KVM?



The VM-exit instruction length of vmcs12 is provided by vmcs02
(prepare_vmcs12()), so unless the length from vmcs02 is wrong. In
addition, something like mov instruction which can trigger the EPT
violation/misconfig in guest has already been decoded before executing
I think, IIUC, then exit qualification can have the information about
the instruction length.



s/exit qualification/VM-exit instruction length



According to Paolo's comment "neither EPT violations nor misconfigurations
are listed in the manual among the VM exits that set the VM-exit instruction
length field", it seems to set the instruction length in vmcs12 is not right
though it is harmless.


But Paolo also mentioned this "It just happens that the actual
condition for VM-exit instruction length being set correctly is "the
fault was taken after the accessing instruction has been decoded"."


We are talking the different thing. As manual mentioned, "All VM exits 
other than those listed in the above items leave this field undefined." 
If we set the field which is not in the listed VM exits that means our 
emulation is not correct. But i have checked the code, KVM just read the 
instruction length from hardware which means we didn't set it artificially.




Regards,
Wanpeng Li




--
Yang
Alibaba Cloud Computing

Re: [PATCH v2] HID: google: add google hammer HID driver

[Wei-Ning Huang]

+ Jiri Kosina , linux-in...@vger.kernel.org

On Fri, Aug 18, 2017 at 2:35 AM, Dmitry Torokhov  wrote:
> On Thu, Aug 17, 2017 at 1:45 AM, Wei-Ning Huang  wrote:
>> Add Google hammer HID driver. This driver allow us to control hammer
>> keyboard backlights and support future features.
>>
>> Signed-off-by: Wei-Ning Huang 
>
> I was helping Wei-Ning internally with this, so
>
> Reviewed-by: Dmitry Torokhov 
>
> You might need to resend to directly to Jiri who is HID maintainer.
>
>> ---
>>  drivers/hid/Kconfig |   6 +++
>>  drivers/hid/Makefile|   1 +
>>  drivers/hid/hid-core.c  |   4 ++
>>  drivers/hid/hid-google-hammer.c | 108 
>> 
>>  drivers/hid/hid-ids.h   |   3 ++
>>  5 files changed, 122 insertions(+)
>>  create mode 100644 drivers/hid/hid-google-hammer.c
>>
>> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> index 3cd60f460b61..efc71acbcf5b 100644
>> --- a/drivers/hid/Kconfig
>> +++ b/drivers/hid/Kconfig
>> @@ -329,6 +329,12 @@ config HOLTEK_FF
>>   Say Y here if you have a Holtek On Line Grip based game controller
>>   and want to have force feedback support for it.
>>
>> +config HID_GOOGLE_HAMMER
>> +   tristate "Google Hammer Keyboard"
>> +   depends on USB_HID && LEDS_CLASS
>> +   ---help---
>> +   Say Y here if you have a Google Hammer device.
>> +
>>  config HID_GT683R
>> tristate "MSI GT68xR LED support"
>> depends on LEDS_CLASS && USB_HID
>> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
>> index 8659d7e633a5..b5d3039286e3 100644
>> --- a/drivers/hid/Makefile
>> +++ b/drivers/hid/Makefile
>> @@ -43,6 +43,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
>>  obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
>>  obj-$(CONFIG_HID_GEMBIRD)  += hid-gembird.o
>>  obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
>> +obj-$(CONFIG_HID_GOOGLE_HAMMER)+= hid-google-hammer.o
>>  obj-$(CONFIG_HID_GT683R)   += hid-gt683r.o
>>  obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
>>  obj-$(CONFIG_HID_HOLTEK)   += hid-holtek-kbd.o
>> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> index 9017dcc14502..813e3d86e2d0 100644
>> --- a/drivers/hid/hid-core.c
>> +++ b/drivers/hid/hid-core.c
>> @@ -2049,6 +2049,10 @@ static const struct hid_device_id 
>> hid_have_special_driver[] = {
>>  { HID_BLUETOOTH_DEVICE(0x58, 0x2000) },
>>  { HID_BLUETOOTH_DEVICE(0x471, 0x2210) },
>>  #endif
>> +#if IS_ENABLED(CONFIG_HID_GOOGLE_HAMMER)
>> +   { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER) 
>> },
>> +   { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
>> +#endif
>>  #if IS_ENABLED(CONFIG_HID_GREENASIA)
>> { HID_USB_DEVICE(USB_VENDOR_ID_GREENASIA, 0x0012) },
>>  #endif
>> diff --git a/drivers/hid/hid-google-hammer.c 
>> b/drivers/hid/hid-google-hammer.c
>> new file mode 100644
>> index ..b6955f01c656
>> --- /dev/null
>> +++ b/drivers/hid/hid-google-hammer.c
>> @@ -0,0 +1,108 @@
>> +/*
>> + *  HID driver for Google Hammer device.
>> + *
>> + *  Copyright (c) 2017 Google Inc.
>> + *  Author: Wei-Ning Huang 
>> + */
>> +
>> +/*
>> + * 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "hid-ids.h"
>> +
>> +#define MAX_BRIGHTNESS 100
>> +
>> +struct hammer_kbd_leds {
>> +   struct led_classdev cdev;
>> +   struct hid_device *hdev;
>> +   u8 buf[2] cacheline_aligned;
>> +};
>> +
>> +static int hammer_kbd_brightness_set_blocking(struct led_classdev *cdev,
>> +   enum led_brightness br)
>> +{
>> +   struct hammer_kbd_leds *led = container_of(cdev,
>> +  struct hammer_kbd_leds,
>> +  cdev);
>> +   int ret;
>> +
>> +   led->buf[0] = 0;
>> +   led->buf[1] = br;
>> +
>> +   ret = hid_hw_output_report(led->hdev, led->buf, sizeof(led->buf));
>> +   if (ret == -ENOSYS)
>> +   ret = hid_hw_raw_request(led->hdev, 0, led->buf,
>> +sizeof(led->buf),
>> +HID_OUTPUT_REPORT,
>> +HID_REQ_SET_REPORT);
>> +   if (ret < 0)
>> +   hid_err(led->hdev, "failed to set keyboard backlight: %d\n",
>> +   ret);
>> +   return ret;
>> +}
>> +
>> +static int hammer_register_leds(struct hid_device *hdev)
>> +{
>> +   struct hammer_kbd_leds *kbd_backlight;
>> +
>> +   kbd_backlight = 

Re: [PATCH] kvm: VMX: do not use vm-exit instruction length for fast MMIO

[Yang Zhang]

On 2017/8/17 16:51, Wanpeng Li wrote:

2017-08-17 16:48 GMT+08:00 Yang Zhang :

On 2017/8/17 16:31, Wanpeng Li wrote:


2017-08-17 16:28 GMT+08:00 Wanpeng Li :


2017-08-17 16:07 GMT+08:00 Yang Zhang :


On 2017/8/17 0:56, Radim Krčmář wrote:



2017-08-16 17:10+0300, Michael S. Tsirkin:



On Wed, Aug 16, 2017 at 03:34:54PM +0200, Paolo Bonzini wrote:



Microsoft pointed out privately to me that KVM's handling of
KVM_FAST_MMIO_BUS is invalid.  Using skip_emulation_instruction is
invalid
in EPT misconfiguration vmexit handlers, because neither EPT
violations
nor misconfigurations are listed in the manual among the VM exits
that
set the VM-exit instruction length field.

While physical processors seem to set the field, this is not
architectural
and is just a side effect of the implementation.  I couldn't convince
myself of any condition on the exit qualification where VM-exit
instruction length "has" to be defined; there are no trap-like
VM-exits
that can be repurposed; and fault-like VM-exits such as
descriptor-table
exits provide no decoding information.  So I don't really see any way
to keep the full speedup.

What we can do is use EMULTYPE_SKIP; it only saves 200 clock cycles
because computing the physical RIP and reading the instruction is
expensive, but at least the eventfd is signaled before entering the
emulator.  This saves on latency.  While at it, don't check
breakpoints
when skipping the instruction, as presumably any side effect has been
exposed already.

Adding a hypercall or MSR write that does a fast MMIO write to a
physical
address would do it, but it adds hypervisor knowledge in virtio,
including
CPUID handling.  So it would be pretty ugly in the guest-side
implementation,
but if somebody wants to do it and the virtio side is acceptable to
the
virtio maintainers, I am okay with it.

Cc: Michael S. Tsirkin 
Cc: sta...@vger.kernel.org
Fixes: 68c3b4d1676d870f0453c31d5a52e7e65c7448ae
Suggested-by: Radim Krčmář 
Signed-off-by: Paolo Bonzini 




Jason (cc) who worked on the original optimization said he can
work to test the performance impact.
I suggest we don't rush this (it's been like this for 2 years),
and the issue seems to be largely theoretical.




Paolo, did Microsoft point it out because they hit the bug when running
KVM on Hyper-V?




Does this mean the nested emulation of EPT violation and
misconfiguration in
KVM side doesn't strictly follow the manual since we didn't hit the bug
in
KVM?



The VM-exit instruction length of vmcs12 is provided by vmcs02
(prepare_vmcs12()), so unless the length from vmcs02 is wrong. In
addition, something like mov instruction which can trigger the EPT
violation/misconfig in guest has already been decoded before executing
I think, IIUC, then exit qualification can have the information about
the instruction length.



s/exit qualification/VM-exit instruction length



According to Paolo's comment "neither EPT violations nor misconfigurations
are listed in the manual among the VM exits that set the VM-exit instruction
length field", it seems to set the instruction length in vmcs12 is not right
though it is harmless.


But Paolo also mentioned this "It just happens that the actual
condition for VM-exit instruction length being set correctly is "the
fault was taken after the accessing instruction has been decoded"."


We are talking the different thing. As manual mentioned, "All VM exits 
other than those listed in the above items leave this field undefined." 
If we set the field which is not in the listed VM exits that means our 
emulation is not correct. But i have checked the code, KVM just read the 
instruction length from hardware which means we didn't set it artificially.




Regards,
Wanpeng Li




--
Yang
Alibaba Cloud Computing

Re: [PATCH v2] HID: google: add google hammer HID driver

[Wei-Ning Huang]

+ Jiri Kosina , linux-in...@vger.kernel.org

On Fri, Aug 18, 2017 at 2:35 AM, Dmitry Torokhov  wrote:
> On Thu, Aug 17, 2017 at 1:45 AM, Wei-Ning Huang  wrote:
>> Add Google hammer HID driver. This driver allow us to control hammer
>> keyboard backlights and support future features.
>>
>> Signed-off-by: Wei-Ning Huang 
>
> I was helping Wei-Ning internally with this, so
>
> Reviewed-by: Dmitry Torokhov 
>
> You might need to resend to directly to Jiri who is HID maintainer.
>
>> ---
>>  drivers/hid/Kconfig |   6 +++
>>  drivers/hid/Makefile|   1 +
>>  drivers/hid/hid-core.c  |   4 ++
>>  drivers/hid/hid-google-hammer.c | 108 
>> 
>>  drivers/hid/hid-ids.h   |   3 ++
>>  5 files changed, 122 insertions(+)
>>  create mode 100644 drivers/hid/hid-google-hammer.c
>>
>> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> index 3cd60f460b61..efc71acbcf5b 100644
>> --- a/drivers/hid/Kconfig
>> +++ b/drivers/hid/Kconfig
>> @@ -329,6 +329,12 @@ config HOLTEK_FF
>>   Say Y here if you have a Holtek On Line Grip based game controller
>>   and want to have force feedback support for it.
>>
>> +config HID_GOOGLE_HAMMER
>> +   tristate "Google Hammer Keyboard"
>> +   depends on USB_HID && LEDS_CLASS
>> +   ---help---
>> +   Say Y here if you have a Google Hammer device.
>> +
>>  config HID_GT683R
>> tristate "MSI GT68xR LED support"
>> depends on LEDS_CLASS && USB_HID
>> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
>> index 8659d7e633a5..b5d3039286e3 100644
>> --- a/drivers/hid/Makefile
>> +++ b/drivers/hid/Makefile
>> @@ -43,6 +43,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
>>  obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
>>  obj-$(CONFIG_HID_GEMBIRD)  += hid-gembird.o
>>  obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
>> +obj-$(CONFIG_HID_GOOGLE_HAMMER)+= hid-google-hammer.o
>>  obj-$(CONFIG_HID_GT683R)   += hid-gt683r.o
>>  obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
>>  obj-$(CONFIG_HID_HOLTEK)   += hid-holtek-kbd.o
>> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> index 9017dcc14502..813e3d86e2d0 100644
>> --- a/drivers/hid/hid-core.c
>> +++ b/drivers/hid/hid-core.c
>> @@ -2049,6 +2049,10 @@ static const struct hid_device_id 
>> hid_have_special_driver[] = {
>>  { HID_BLUETOOTH_DEVICE(0x58, 0x2000) },
>>  { HID_BLUETOOTH_DEVICE(0x471, 0x2210) },
>>  #endif
>> +#if IS_ENABLED(CONFIG_HID_GOOGLE_HAMMER)
>> +   { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_HAMMER) 
>> },
>> +   { HID_USB_DEVICE(USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
>> +#endif
>>  #if IS_ENABLED(CONFIG_HID_GREENASIA)
>> { HID_USB_DEVICE(USB_VENDOR_ID_GREENASIA, 0x0012) },
>>  #endif
>> diff --git a/drivers/hid/hid-google-hammer.c 
>> b/drivers/hid/hid-google-hammer.c
>> new file mode 100644
>> index ..b6955f01c656
>> --- /dev/null
>> +++ b/drivers/hid/hid-google-hammer.c
>> @@ -0,0 +1,108 @@
>> +/*
>> + *  HID driver for Google Hammer device.
>> + *
>> + *  Copyright (c) 2017 Google Inc.
>> + *  Author: Wei-Ning Huang 
>> + */
>> +
>> +/*
>> + * 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "hid-ids.h"
>> +
>> +#define MAX_BRIGHTNESS 100
>> +
>> +struct hammer_kbd_leds {
>> +   struct led_classdev cdev;
>> +   struct hid_device *hdev;
>> +   u8 buf[2] cacheline_aligned;
>> +};
>> +
>> +static int hammer_kbd_brightness_set_blocking(struct led_classdev *cdev,
>> +   enum led_brightness br)
>> +{
>> +   struct hammer_kbd_leds *led = container_of(cdev,
>> +  struct hammer_kbd_leds,
>> +  cdev);
>> +   int ret;
>> +
>> +   led->buf[0] = 0;
>> +   led->buf[1] = br;
>> +
>> +   ret = hid_hw_output_report(led->hdev, led->buf, sizeof(led->buf));
>> +   if (ret == -ENOSYS)
>> +   ret = hid_hw_raw_request(led->hdev, 0, led->buf,
>> +sizeof(led->buf),
>> +HID_OUTPUT_REPORT,
>> +HID_REQ_SET_REPORT);
>> +   if (ret < 0)
>> +   hid_err(led->hdev, "failed to set keyboard backlight: %d\n",
>> +   ret);
>> +   return ret;
>> +}
>> +
>> +static int hammer_register_leds(struct hid_device *hdev)
>> +{
>> +   struct hammer_kbd_leds *kbd_backlight;
>> +
>> +   kbd_backlight = devm_kzalloc(>dev,
>> +sizeof(*kbd_backlight),
>> +   

[PATCH] staging: pi433: fixed coding style issues

[Xiangyang Zhang]

space required before the open parenthesis, open brace should be
on previous line.

Signed-off-by: Xiangyang Zhang 
---
 drivers/staging/pi433/pi433_if.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 6b9b7df70f8e..87053e778451 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -1125,14 +1125,13 @@ static int pi433_probe(struct spi_device *spi)
if (retval < 0)
return retval;
 
-   switch(retval)
-   {
-   case 0x24:
-   dev_dbg(>dev, "found pi433 (ver. 0x%x)", retval);
-   break;
-   default:
-   dev_dbg(>dev, "unknown chip version: 0x%x", 
retval);
-   return -ENODEV;
+   switch (retval) {
+   case 0x24:
+   dev_dbg(>dev, "found pi433 (ver. 0x%x)", retval);
+   break;
+   default:
+   dev_dbg(>dev, "unknown chip version: 0x%x", retval);
+   return -ENODEV;
}
 
/* Allocate driver data */
-- 
2.14.1

[PATCH] staging: pi433: fixed coding style issues

[Xiangyang Zhang]

space required before the open parenthesis, open brace should be
on previous line.

Signed-off-by: Xiangyang Zhang 
---
 drivers/staging/pi433/pi433_if.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 6b9b7df70f8e..87053e778451 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -1125,14 +1125,13 @@ static int pi433_probe(struct spi_device *spi)
if (retval < 0)
return retval;
 
-   switch(retval)
-   {
-   case 0x24:
-   dev_dbg(>dev, "found pi433 (ver. 0x%x)", retval);
-   break;
-   default:
-   dev_dbg(>dev, "unknown chip version: 0x%x", 
retval);
-   return -ENODEV;
+   switch (retval) {
+   case 0x24:
+   dev_dbg(>dev, "found pi433 (ver. 0x%x)", retval);
+   break;
+   default:
+   dev_dbg(>dev, "unknown chip version: 0x%x", retval);
+   return -ENODEV;
}
 
/* Allocate driver data */
-- 
2.14.1

Re: [PATCH v2 20/22] fpga: intel: afu add FPGA_GET_API_VERSION/CHECK_EXTENSION ioctls support

[Wu Hao]

On Thu, Aug 17, 2017 at 12:12:00PM -0700, Moritz Fischer wrote:
> Hi,
> 
> On Sun, Jun 25, 2017 at 6:52 PM, Wu Hao  wrote:
> > FPGA_GET_API_VERSION and FPGA_CHECK_EXTENSION ioctls are common ones which
> > need to be supported by all feature devices drivers including FME and AFU.
> > This patch implements above 2 ioctls in Intel FPGA Accelerated Function
> > Unit (AFU) driver.
> >
> > Signed-off-by: Tim Whisonant 
> > Signed-off-by: Enno Luebbers 
> > Signed-off-by: Shiva Rao 
> > Signed-off-by: Christopher Rauer 
> > Signed-off-by: Xiao Guangrong 
> > Signed-off-by: Wu Hao 
> > ---
> > v2: rebased
> > ---
> >  drivers/fpga/intel-afu-main.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/fpga/intel-afu-main.c b/drivers/fpga/intel-afu-main.c
> > index 2a17cde..22f77f2 100644
> > --- a/drivers/fpga/intel-afu-main.c
> > +++ b/drivers/fpga/intel-afu-main.c
> > @@ -122,6 +122,13 @@ static int afu_release(struct inode *inode, struct 
> > file *filp)
> > return 0;
> >  }
> >
> > +static long afu_ioctl_check_extension(struct feature_platform_data *pdata,
> > +unsigned long arg)
> > +{
> > +   /* No extension support for now */
> 
> Do you maybe make that an -ENOTSUPP or -EINVAL then?

Hi Moritz

User will use this ioctl to check if extension X is supported. It always 
returns 0
means any extension indicated by the arg, is not supported.

I think we don't have to return an -ENOTSUPP or -EINVAL here, which may confuse
the enduser. : )

Thanks
Hao

> > +   return 0;
> > +}
> > +
> >  static long afu_ioctl(struct file *filp, unsigned int cmd, unsigned long 
> > arg)
> >  {
> > struct platform_device *pdev = filp->private_data;
> > @@ -132,6 +139,10 @@ static long afu_ioctl(struct file *filp, unsigned int 
> > cmd, unsigned long arg)
> > dev_dbg(>dev, "%s cmd 0x%x\n", __func__, cmd);
> >
> > switch (cmd) {
> > +   case FPGA_GET_API_VERSION:
> > +   return FPGA_API_VERSION;
> > +   case FPGA_CHECK_EXTENSION:
> > +   return afu_ioctl_check_extension(pdata, arg);
> > default:
> > /*
> >  * Let sub-feature's ioctl function to handle the cmd
> > --
> > 1.8.3.1
> >
> > --
> > 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
> 
> Thanks,
> 
> Moritz

Re: [PATCH v2 20/22] fpga: intel: afu add FPGA_GET_API_VERSION/CHECK_EXTENSION ioctls support

[Wu Hao]

On Thu, Aug 17, 2017 at 12:12:00PM -0700, Moritz Fischer wrote:
> Hi,
> 
> On Sun, Jun 25, 2017 at 6:52 PM, Wu Hao  wrote:
> > FPGA_GET_API_VERSION and FPGA_CHECK_EXTENSION ioctls are common ones which
> > need to be supported by all feature devices drivers including FME and AFU.
> > This patch implements above 2 ioctls in Intel FPGA Accelerated Function
> > Unit (AFU) driver.
> >
> > Signed-off-by: Tim Whisonant 
> > Signed-off-by: Enno Luebbers 
> > Signed-off-by: Shiva Rao 
> > Signed-off-by: Christopher Rauer 
> > Signed-off-by: Xiao Guangrong 
> > Signed-off-by: Wu Hao 
> > ---
> > v2: rebased
> > ---
> >  drivers/fpga/intel-afu-main.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/fpga/intel-afu-main.c b/drivers/fpga/intel-afu-main.c
> > index 2a17cde..22f77f2 100644
> > --- a/drivers/fpga/intel-afu-main.c
> > +++ b/drivers/fpga/intel-afu-main.c
> > @@ -122,6 +122,13 @@ static int afu_release(struct inode *inode, struct 
> > file *filp)
> > return 0;
> >  }
> >
> > +static long afu_ioctl_check_extension(struct feature_platform_data *pdata,
> > +unsigned long arg)
> > +{
> > +   /* No extension support for now */
> 
> Do you maybe make that an -ENOTSUPP or -EINVAL then?

Hi Moritz

User will use this ioctl to check if extension X is supported. It always 
returns 0
means any extension indicated by the arg, is not supported.

I think we don't have to return an -ENOTSUPP or -EINVAL here, which may confuse
the enduser. : )

Thanks
Hao

> > +   return 0;
> > +}
> > +
> >  static long afu_ioctl(struct file *filp, unsigned int cmd, unsigned long 
> > arg)
> >  {
> > struct platform_device *pdev = filp->private_data;
> > @@ -132,6 +139,10 @@ static long afu_ioctl(struct file *filp, unsigned int 
> > cmd, unsigned long arg)
> > dev_dbg(>dev, "%s cmd 0x%x\n", __func__, cmd);
> >
> > switch (cmd) {
> > +   case FPGA_GET_API_VERSION:
> > +   return FPGA_API_VERSION;
> > +   case FPGA_CHECK_EXTENSION:
> > +   return afu_ioctl_check_extension(pdata, arg);
> > default:
> > /*
> >  * Let sub-feature's ioctl function to handle the cmd
> > --
> > 1.8.3.1
> >
> > --
> > 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
> 
> Thanks,
> 
> Moritz

Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches

[Peter Hutterer]

sorry, was at a conference/travelling and I'm slowly catching up.

On Fri, Aug 11, 2017 at 10:29:07AM +0200, Henrik Rydberg wrote:
> Hi Dmitry,
> 
> > The meaning of confidence is literally "contact is too large to be a
> > finger", so it is not touch state, but really tool identity. We do
> > allow tool identity to change over time.
> What I am arguing is rather that since "palm" is a property, just like
> contact size, there should be no need to confuse that property with the
> touch state, which is, as you state, what happens in userland when the tool
> type is modified. Using a different event for the palm property ought to
> remove that confusion.

whether it's a property or a tool type is up for interpretation, imo neither
is right or wrong. It's common enough that the tool type changes after touch
down but it's equally common for the tool type to be set at start.

> > The additional state is simply because we have never updated the tool
> > type on release events and userspace is not expecting it and is likely
> > to ignore any data in the slot that is accompanied with
> > ABS_TRACKING_ID == -1. So we synthesize an extra event to have
> > distinct tool change and release.
> 
> We update all other properties of a contact freely at release, so
> logically there is no good reason to treat palm, the binary version of max
> contact size, differently.

note that palm does not indicate max contact size, it's merely a magic
property at which point the contact is not considered a normal finger
anymore. It may be size related, but it's certainly doesn't imply that it's
the maximum touch size and I expect this to be even less true of devices in
the future.
 
> > Mostly because with BTN_TOOL_PALM we are not able to decide which
> > contact is turning into palm. Also, other drivers (RMI) use
> > MT_TOOL_PALM and I would like to report palm state in unified way.
> Precedent certainly matters, but in this case, I think the modification
> promises problems down the road. I would rather suggest to add a new binary
> palm property, with the precise meaning "contact size = max contact size",
> and take it from there. I dont mind writing a patch for it if you agree.

the closest interpretation would be "contact size/shape/location indicates
that it is not a finger". I don't think you can easily narrow this down
further, mostly because it's often driven by the firmware and who knows what
that does.

I can live with an extra property as well as long as it's per-touch, but I
don't have any problems with MT_TOOL_PALM.

Cheers,
   Peter

Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches

[Peter Hutterer]

sorry, was at a conference/travelling and I'm slowly catching up.

On Fri, Aug 11, 2017 at 10:29:07AM +0200, Henrik Rydberg wrote:
> Hi Dmitry,
> 
> > The meaning of confidence is literally "contact is too large to be a
> > finger", so it is not touch state, but really tool identity. We do
> > allow tool identity to change over time.
> What I am arguing is rather that since "palm" is a property, just like
> contact size, there should be no need to confuse that property with the
> touch state, which is, as you state, what happens in userland when the tool
> type is modified. Using a different event for the palm property ought to
> remove that confusion.

whether it's a property or a tool type is up for interpretation, imo neither
is right or wrong. It's common enough that the tool type changes after touch
down but it's equally common for the tool type to be set at start.

> > The additional state is simply because we have never updated the tool
> > type on release events and userspace is not expecting it and is likely
> > to ignore any data in the slot that is accompanied with
> > ABS_TRACKING_ID == -1. So we synthesize an extra event to have
> > distinct tool change and release.
> 
> We update all other properties of a contact freely at release, so
> logically there is no good reason to treat palm, the binary version of max
> contact size, differently.

note that palm does not indicate max contact size, it's merely a magic
property at which point the contact is not considered a normal finger
anymore. It may be size related, but it's certainly doesn't imply that it's
the maximum touch size and I expect this to be even less true of devices in
the future.
 
> > Mostly because with BTN_TOOL_PALM we are not able to decide which
> > contact is turning into palm. Also, other drivers (RMI) use
> > MT_TOOL_PALM and I would like to report palm state in unified way.
> Precedent certainly matters, but in this case, I think the modification
> promises problems down the road. I would rather suggest to add a new binary
> palm property, with the precise meaning "contact size = max contact size",
> and take it from there. I dont mind writing a patch for it if you agree.

the closest interpretation would be "contact size/shape/location indicates
that it is not a finger". I don't think you can easily narrow this down
further, mostly because it's often driven by the firmware and who knows what
that does.

I can live with an extra property as well as long as it's per-touch, but I
don't have any problems with MT_TOOL_PALM.

Cheers,
   Peter

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

[Alexei Starovoitov]

On 8/15/17 12:34 PM, Edward Cree wrote:

State of a register doesn't matter if it wasn't read in reaching an exit;
 a write screens off all reads downstream of it from all explored_states
 upstream of it.
This allows us to prune many more branches; here are some processed insn
 counts for some Cilium programs:
Program  before  after
bpf_lb_opt_-DLB_L3.o   6515   3361
bpf_lb_opt_-DLB_L4.o   8976   5176
bpf_lb_opt_-DUNKNOWN.o 2960   1137
bpf_lxc_opt_-DDROP_ALL.o  95412  48537
bpf_lxc_opt_-DUNKNOWN.o  141706  78718
bpf_netdev.o  24251  17995
bpf_overlay.o 10999   9385

The runtime is also improved; here are 'time' results in ms:
Program  before  after
bpf_lb_opt_-DLB_L3.o 24  6
bpf_lb_opt_-DLB_L4.o 26 11
bpf_lb_opt_-DUNKNOWN.o   11  2
bpf_lxc_opt_-DDROP_ALL.o   1288139
bpf_lxc_opt_-DUNKNOWN.o1768234
bpf_netdev.o 62 31
bpf_overlay.o15 13

Signed-off-by: Edward Cree 


this is one ingenious hack. Love it!
I took me whole day to understand most of it, but I still have
few questions:


+
+static void propagate_liveness(const struct bpf_verifier_state *state,
+  struct bpf_verifier_state *parent)


here the name 'parent' is very confusing, since for the first
iteration of the loop below it transfers lives from 'neighbor'
state to the current state and only then traverses the link
of parents in the current.
Would be good to document it, since I was struggling the most
with this name until I realized that the way you build parent link list
in is_state_visited() is actual sequence of roughly basic blocks and
the name 'parent' applies there, but not for the first iteration
of this function.


@@ -3407,6 +3501,14 @@ static int is_state_visited(struct bpf_verifier_env 
*env, int insn_idx)
memcpy(_sl->state, >cur_state, sizeof(env->cur_state));
new_sl->next = env->explored_states[insn_idx];
env->explored_states[insn_idx] = new_sl;
+   /* connect new state to parentage chain */
+   env->cur_state.parent = _sl->state;
+   /* clear liveness marks in current state */
+   for (i = 0; i < BPF_REG_FP; i++)
+   env->cur_state.regs[i].live = REG_LIVE_NONE;
+   for (i = 0; i < MAX_BPF_STACK / BPF_REG_SIZE; i++)
+   if (env->cur_state.stack_slot_type[i * BPF_REG_SIZE] == 
STACK_SPILL)
+   env->cur_state.spilled_regs[i].live = REG_LIVE_NONE;


and this part I don't get at all.
It seems you're trying to sort-of do per-fake-basic block liveness
analysis, but our state_list_marks are not correct if we go with
canonical basic block definition, since we mark the jump insn and
not insn after the branch and not every basic block boundary is
properly detected.
So if algorithm should only work for basic blocks (for sequences of
instructions without control flow changes) then it's broken.
If it should work with control flow insns then it should also work
for the whole chain of insns from the first one till bpf_exit...
So I tried removing two above clearing loops and results are much
better:
before  after
bpf_lb-DLB_L3.o 26041120
bpf_lb-DLB_L4.o 11159   1371
bpf_lb-DUNKNOWN.o   1116485
bpf_lxc-DDROP_ALL.o 34566   12758
bpf_lxc-DUNKNOWN.o  53267   18337
bpf_netdev.o17843   10564
bpf_overlay.o   86725513

but it feels too good to be true and probably not correct.
So either way we need to fix something it seems.

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

[Alexei Starovoitov]

On 8/15/17 12:34 PM, Edward Cree wrote:

State of a register doesn't matter if it wasn't read in reaching an exit;
 a write screens off all reads downstream of it from all explored_states
 upstream of it.
This allows us to prune many more branches; here are some processed insn
 counts for some Cilium programs:
Program  before  after
bpf_lb_opt_-DLB_L3.o   6515   3361
bpf_lb_opt_-DLB_L4.o   8976   5176
bpf_lb_opt_-DUNKNOWN.o 2960   1137
bpf_lxc_opt_-DDROP_ALL.o  95412  48537
bpf_lxc_opt_-DUNKNOWN.o  141706  78718
bpf_netdev.o  24251  17995
bpf_overlay.o 10999   9385

The runtime is also improved; here are 'time' results in ms:
Program  before  after
bpf_lb_opt_-DLB_L3.o 24  6
bpf_lb_opt_-DLB_L4.o 26 11
bpf_lb_opt_-DUNKNOWN.o   11  2
bpf_lxc_opt_-DDROP_ALL.o   1288139
bpf_lxc_opt_-DUNKNOWN.o1768234
bpf_netdev.o 62 31
bpf_overlay.o15 13

Signed-off-by: Edward Cree 


this is one ingenious hack. Love it!
I took me whole day to understand most of it, but I still have
few questions:


+
+static void propagate_liveness(const struct bpf_verifier_state *state,
+  struct bpf_verifier_state *parent)


here the name 'parent' is very confusing, since for the first
iteration of the loop below it transfers lives from 'neighbor'
state to the current state and only then traverses the link
of parents in the current.
Would be good to document it, since I was struggling the most
with this name until I realized that the way you build parent link list
in is_state_visited() is actual sequence of roughly basic blocks and
the name 'parent' applies there, but not for the first iteration
of this function.


@@ -3407,6 +3501,14 @@ static int is_state_visited(struct bpf_verifier_env 
*env, int insn_idx)
memcpy(_sl->state, >cur_state, sizeof(env->cur_state));
new_sl->next = env->explored_states[insn_idx];
env->explored_states[insn_idx] = new_sl;
+   /* connect new state to parentage chain */
+   env->cur_state.parent = _sl->state;
+   /* clear liveness marks in current state */
+   for (i = 0; i < BPF_REG_FP; i++)
+   env->cur_state.regs[i].live = REG_LIVE_NONE;
+   for (i = 0; i < MAX_BPF_STACK / BPF_REG_SIZE; i++)
+   if (env->cur_state.stack_slot_type[i * BPF_REG_SIZE] == 
STACK_SPILL)
+   env->cur_state.spilled_regs[i].live = REG_LIVE_NONE;


and this part I don't get at all.
It seems you're trying to sort-of do per-fake-basic block liveness
analysis, but our state_list_marks are not correct if we go with
canonical basic block definition, since we mark the jump insn and
not insn after the branch and not every basic block boundary is
properly detected.
So if algorithm should only work for basic blocks (for sequences of
instructions without control flow changes) then it's broken.
If it should work with control flow insns then it should also work
for the whole chain of insns from the first one till bpf_exit...
So I tried removing two above clearing loops and results are much
better:
before  after
bpf_lb-DLB_L3.o 26041120
bpf_lb-DLB_L4.o 11159   1371
bpf_lb-DUNKNOWN.o   1116485
bpf_lxc-DDROP_ALL.o 34566   12758
bpf_lxc-DUNKNOWN.o  53267   18337
bpf_netdev.o17843   10564
bpf_overlay.o   86725513

but it feels too good to be true and probably not correct.
So either way we need to fix something it seems.

Re: [PATCH 0/5] arm-smmu: performance optimization

[Leizhen (ThunderTown)]

On 2017/8/17 22:36, Will Deacon wrote:
> Thunder, Nate, Robin,
> 
> On Mon, Jun 26, 2017 at 09:38:45PM +0800, Zhen Lei wrote:
>> I described the optimization more detail in patch 1 and 2, and patch 3-5 are
>> the implementation on arm-smmu/arm-smmu-v3 of patch 2.
>>
>> Patch 1 is v2. In v1, I directly replaced writel with writel_relaxed in
>> queue_inc_prod. But Robin figured that it may lead SMMU consume stale
>> memory contents. I thought more than 3 whole days and got this one.
>>
>> This patchset is based on Robin Murphy's [PATCH v2 0/8] io-pgtable lock 
>> removal.
> 
> For the time being, I think we should focus on the new TLB flushing
> interface posted by Joerg:
> 
> http://lkml.kernel.org/r/1502974596-23835-1-git-send-email-j...@8bytes.org
> 
> which looks like it can give us most of the benefits of this series. Once
> we've got that, we can see what's left in the way of performance and focus
> on the cmdq batching separately (because I'm still not convinced about it).
OK, this is a good news.

But I have a review comment(sorry, I have not subscribed it yet, so can not 
directly reply it):
I don't think we should add tlb sync for map operation
1. at init time, all tlbs will be invalidated
2. when we try to map a new range, there are no related ptes bufferd in tlb, 
because of above 1 and below 3
3. when we unmap the above range, make sure all related ptes bufferd in tlb to 
be invalidated before unmap finished

> 
> Thanks,
> 
> Will
> 
> .
> 

-- 
Thanks!
BestRegards

Re: [PATCH 0/5] arm-smmu: performance optimization

[Leizhen (ThunderTown)]

On 2017/8/17 22:36, Will Deacon wrote:
> Thunder, Nate, Robin,
> 
> On Mon, Jun 26, 2017 at 09:38:45PM +0800, Zhen Lei wrote:
>> I described the optimization more detail in patch 1 and 2, and patch 3-5 are
>> the implementation on arm-smmu/arm-smmu-v3 of patch 2.
>>
>> Patch 1 is v2. In v1, I directly replaced writel with writel_relaxed in
>> queue_inc_prod. But Robin figured that it may lead SMMU consume stale
>> memory contents. I thought more than 3 whole days and got this one.
>>
>> This patchset is based on Robin Murphy's [PATCH v2 0/8] io-pgtable lock 
>> removal.
> 
> For the time being, I think we should focus on the new TLB flushing
> interface posted by Joerg:
> 
> http://lkml.kernel.org/r/1502974596-23835-1-git-send-email-j...@8bytes.org
> 
> which looks like it can give us most of the benefits of this series. Once
> we've got that, we can see what's left in the way of performance and focus
> on the cmdq batching separately (because I'm still not convinced about it).
OK, this is a good news.

But I have a review comment(sorry, I have not subscribed it yet, so can not 
directly reply it):
I don't think we should add tlb sync for map operation
1. at init time, all tlbs will be invalidated
2. when we try to map a new range, there are no related ptes bufferd in tlb, 
because of above 1 and below 3
3. when we unmap the above range, make sure all related ptes bufferd in tlb to 
be invalidated before unmap finished

> 
> Thanks,
> 
> Will
> 
> .
> 

-- 
Thanks!
BestRegards

[PATCH v4 9/9] dt-bindings: ASoC: rockchip: Update description of rockchip,codec

[Jeffy Chen]

Update description for newly added optional audio codecs.

Signed-off-by: Jeffy Chen 
Acked-by: Rob Herring 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt 
b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
index f19b6c830a34..f54b4e91e97c 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
@@ -4,7 +4,7 @@ Required properties:
 - compatible: "rockchip,rk3399-gru-sound"
 - rockchip,cpu: The phandle of the Rockchip I2S controller that's
   connected to the codecs
-- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
+- rockchip,codec: The phandle of the audio codecs
 
 Example:
 
-- 
2.11.0

[PATCH v4 9/9] dt-bindings: ASoC: rockchip: Update description of rockchip,codec

[Jeffy Chen]

Update description for newly added optional audio codecs.

Signed-off-by: Jeffy Chen 
Acked-by: Rob Herring 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt 
b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
index f19b6c830a34..f54b4e91e97c 100644
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
@@ -4,7 +4,7 @@ Required properties:
 - compatible: "rockchip,rk3399-gru-sound"
 - rockchip,cpu: The phandle of the Rockchip I2S controller that's
   connected to the codecs
-- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
+- rockchip,codec: The phandle of the audio codecs
 
 Example:
 
-- 
2.11.0

[PATCH v4 8/9] ASoC: rockchip: Add support for DMIC codec

[Jeffy Chen]

Add support for optional dmic codec.

Signed-off-by: Jeffy Chen 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 sound/soc/rockchip/Kconfig|  1 +
 sound/soc/rockchip/rk3399_gru_sound.c | 33 +
 2 files changed, 34 insertions(+)

diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index 8f0d0d8d34e6..b0825370d262 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -69,6 +69,7 @@ config SND_SOC_RK3399_GRU_SOUND
select SND_SOC_DA7219
select SND_SOC_RT5514_SPI
select SND_SOC_HDMI_CODEC
+   select SND_SOC_DMIC
help
  Say Y or M here if you want to add support multiple codecs for SoC
  audio on Rockchip RK3399 GRU boards.
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 8ffae1934b94..0be3e5c1386f 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -262,6 +262,25 @@ static int rockchip_sound_cdndp_hw_params(struct 
snd_pcm_substream *substream,
return 0;
 }
 
+static int rockchip_sound_dmic_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   unsigned int mclk;
+   int ret;
+
+   mclk = params_rate(params) * SOUND_FS;
+
+   ret = snd_soc_dai_set_sysclk(rtd->cpu_dai, 0, mclk, 0);
+   if (ret) {
+   dev_err(rtd->card->dev, "%s() error setting sysclk to %u: %d\n",
+   __func__, mclk, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct snd_soc_ops rockchip_sound_max98357a_ops = {
.hw_params = rockchip_sound_max98357a_hw_params,
 };
@@ -278,6 +297,10 @@ static struct snd_soc_ops rockchip_sound_cdndp_ops = {
.hw_params = rockchip_sound_cdndp_hw_params,
 };
 
+static struct snd_soc_ops rockchip_sound_dmic_ops = {
+   .hw_params = rockchip_sound_dmic_hw_params,
+};
+
 static struct snd_soc_card rockchip_sound_card = {
.name = "rk3399-gru-sound",
.owner = THIS_MODULE,
@@ -292,6 +315,7 @@ static struct snd_soc_card rockchip_sound_card = {
 enum {
DAILINK_CDNDP,
DAILINK_DA7219,
+   DAILINK_DMIC,
DAILINK_MAX98357A,
DAILINK_RT5514,
DAILINK_RT5514_DSP,
@@ -300,6 +324,7 @@ enum {
 static const char * const dailink_compat[] = {
[DAILINK_CDNDP] = "rockchip,rk3399-cdn-dp",
[DAILINK_DA7219] = "dlg,da7219",
+   [DAILINK_DMIC] = "dmic-codec",
[DAILINK_MAX98357A] = "maxim,max98357a",
[DAILINK_RT5514] = "realtek,rt5514-i2c",
[DAILINK_RT5514_DSP] = "realtek,rt5514-spi",
@@ -324,6 +349,14 @@ static const struct snd_soc_dai_link rockchip_dais[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
},
+   [DAILINK_DMIC] = {
+   .name = "DMIC",
+   .stream_name = "DMIC PCM",
+   .codec_dai_name = "dmic-hifi",
+   .ops = _sound_dmic_ops,
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+   SND_SOC_DAIFMT_CBS_CFS,
+   },
[DAILINK_MAX98357A] = {
.name = "MAX98357A",
.stream_name = "MAX98357A PCM",
-- 
2.11.0

[PATCH v4 6/9] ASoC: rockchip: Parse dai links from dts

[Jeffy Chen]

Refactor rockchip_sound_probe, parse dai links from dts instead of
hard coding them.

Signed-off-by: Jeffy Chen 
---

Changes in v4: None
Changes in v3:
Use compatible to match audio codecs
-- Suggested-by Matthias Kaehlcke 

Changes in v2:
Let rockchip,codec-names be a required property, because we plan to
add more supported codecs to the fixed dai link list in the driver.

 sound/soc/rockchip/rk3399_gru_sound.c | 139 ++
 1 file changed, 91 insertions(+), 48 deletions(-)

diff --git a/sound/soc/rockchip/rk3399_gru_sound.c 
b/sound/soc/rockchip/rk3399_gru_sound.c
index 9b7e28703bfb..d532336871d7 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -235,14 +235,42 @@ static const struct snd_soc_ops rockchip_sound_da7219_ops 
= {
.hw_params = rockchip_sound_da7219_hw_params,
 };
 
+static struct snd_soc_card rockchip_sound_card = {
+   .name = "rk3399-gru-sound",
+   .owner = THIS_MODULE,
+   .dapm_widgets = rockchip_dapm_widgets,
+   .num_dapm_widgets = ARRAY_SIZE(rockchip_dapm_widgets),
+   .dapm_routes = rockchip_dapm_routes,
+   .num_dapm_routes = ARRAY_SIZE(rockchip_dapm_routes),
+   .controls = rockchip_controls,
+   .num_controls = ARRAY_SIZE(rockchip_controls),
+};
+
 enum {
+   DAILINK_DA7219,
DAILINK_MAX98357A,
DAILINK_RT5514,
-   DAILINK_DA7219,
DAILINK_RT5514_DSP,
 };
 
-static struct snd_soc_dai_link rockchip_dailinks[] = {
+static const char * const dailink_compat[] = {
+   [DAILINK_DA7219] = "dlg,da7219",
+   [DAILINK_MAX98357A] = "maxim,max98357a",
+   [DAILINK_RT5514] = "realtek,rt5514-i2c",
+   [DAILINK_RT5514_DSP] = "realtek,rt5514-spi",
+};
+
+static const struct snd_soc_dai_link rockchip_dais[] = {
+   [DAILINK_DA7219] = {
+   .name = "DA7219",
+   .stream_name = "DA7219 PCM",
+   .codec_dai_name = "da7219-hifi",
+   .init = rockchip_sound_da7219_init,
+   .ops = _sound_da7219_ops,
+   /* set da7219 as slave */
+   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+   SND_SOC_DAIFMT_CBS_CFS,
+   },
[DAILINK_MAX98357A] = {
.name = "MAX98357A",
.stream_name = "MAX98357A PCM",
@@ -261,16 +289,6 @@ static struct snd_soc_dai_link rockchip_dailinks[] = {
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
},
-   [DAILINK_DA7219] = {
-   .name = "DA7219",
-   .stream_name = "DA7219 PCM",
-   .codec_dai_name = "da7219-hifi",
-   .init = rockchip_sound_da7219_init,
-   .ops = _sound_da7219_ops,
-   /* set da7219 as slave */
-   .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
-   SND_SOC_DAIFMT_CBS_CFS,
-   },
/* RT5514 DSP for voice wakeup via spi bus */
[DAILINK_RT5514_DSP] = {
.name = "RT5514 DSP",
@@ -279,53 +297,78 @@ static struct snd_soc_dai_link rockchip_dailinks[] = {
},
 };
 
-static struct snd_soc_card rockchip_sound_card = {
-   .name = "rk3399-gru-sound",
-   .owner = THIS_MODULE,
-   .dai_link = rockchip_dailinks,
-   .num_links =  ARRAY_SIZE(rockchip_dailinks),
-   .dapm_widgets = rockchip_dapm_widgets,
-   .num_dapm_widgets = ARRAY_SIZE(rockchip_dapm_widgets),
-   .dapm_routes = rockchip_dapm_routes,
-   .num_dapm_routes = ARRAY_SIZE(rockchip_dapm_routes),
-   .controls = rockchip_controls,
-   .num_controls = ARRAY_SIZE(rockchip_controls),
-};
-
-static int rockchip_sound_probe(struct platform_device *pdev)
+static int rockchip_sound_codec_node_match(struct device_node *np_codec)
 {
-   struct snd_soc_card *card = _sound_card;
-   struct device_node *cpu_node;
-   int i, ret;
+   int i;
 
-   cpu_node = of_parse_phandle(pdev->dev.of_node, "rockchip,cpu", 0);
-   if (!cpu_node) {
-   dev_err(>dev, "Property 'rockchip,cpu' missing or 
invalid\n");
-   return -EINVAL;
+   for (i = 0; i < ARRAY_SIZE(dailink_compat); i++) {
+   if (of_device_is_compatible(np_codec, dailink_compat[i]))
+   return i;
}
+   return -1;
+}
 
-   for (i = 0; i < ARRAY_SIZE(rockchip_dailinks); i++) {
-   rockchip_dailinks[i].platform_of_node = cpu_node;
-   rockchip_dailinks[i].cpu_of_node = cpu_node;
-
-   rockchip_dailinks[i].codec_of_node =
-   of_parse_phandle(pdev->dev.of_node, "rockchip,codec", 
i);
-   if (!rockchip_dailinks[i].codec_of_node) {
-   dev_err(>dev,
-   "Property[%d] 'rockchip,codec' missing or 
invalid\n", i);
+static int