Re: [PATCH v1 1/1] gpio: of: provide option generic property for initial line states

[Oleksij Rempel]

Hi Vladimir,

On Sun, Jun 11, 2017 at 10:57:18PM +0300, Vladimir Zapolskiy wrote:
> Hi Oleksij,
> 
> On 06/11/2017 09:19 AM, Oleksij Rempel wrote:
> > Hi Rob,
> > 
> > On Fri, Jun 09, 2017 at 10:41:30AM -0500, Rob Herring wrote:
> >> On Fri, Jun 9, 2017 at 9:16 AM, Oleksij Rempel  
> >> wrote:
> >>> This property is needed for barebox or may be other bootloaders
> >>> to set proper gpio configuration as early as possible.
> >>>
> >>> This example is mainly based on "lines-initial-states" property
> >>> from this binding documentation:
> >>> Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> >>
> >> Don't we have a binding for this already based on gpio-hogs.
> > 
> > Markus Pargmann was working on this topic before and suddenly was not
> > able to finish it.
> 
> that's fine, but the proposed extension is supposedly not wanted.

:(

> > I found only some not finished discussions and no code or documentation
> > in linux kernel upstream.
> > 
> > So far, I was able to find fallowing patches and discussions:
> > patch 23.08.2015, last comment 11.05.2017:
> > https://patchwork.kernel.org/patch/7096721/
> > 
> > patch 23.02.2016, last comment 09.03.2016:
> > https://patchwork.ozlabs.org/patch/586743/
> > 
> > Since there was objections about node-like design for gpio-initval, I
> > provided an array property, which is similar to initval properties already 
> > used
> > for different other device nodes. For example:
> > 
> > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> > qcom,ath10k-calibration-data
> > 
> > Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> > lines-initial-states
> 
> It'd rather be better to fix the drivers and remove the properties
> from these found device tree binding descriptions.

no sure if it is possible. WiFi calibration data is kind of initval too.

> > 
> > Please fixme if I miss something.
> 
> Why is GPIO hogging mechanism not good enough for your purpose?

Becouse it should not permanently hog a gpio. The "Hogging" should be
released as soon as some driver will request it.

Right now, if I define gpio-hog, boot loader will configure it and start
linux. But linux will never let it free.

If you have other suggestions which fit to this use case, please tell
me. I assume, right now I'm just blind.

Other way, I can imagine is to create real device nodes which use this
gpios. Compatible for this devices will be like this:
some_gpio_holder: gpio@0 {
compatible = "gpio-for-userspace";
gpio = < 5 GPIO_ACTIVE_HIGH>;
};

Boot loader will configure it as needed, an linux will do nothing with
it so it can be used over /dev/gpio interface.

> --
> With best wishes,
> Vladimir

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v1 1/1] gpio: of: provide option generic property for initial line states

[Oleksij Rempel]

Hi Vladimir,

On Sun, Jun 11, 2017 at 10:57:18PM +0300, Vladimir Zapolskiy wrote:
> Hi Oleksij,
> 
> On 06/11/2017 09:19 AM, Oleksij Rempel wrote:
> > Hi Rob,
> > 
> > On Fri, Jun 09, 2017 at 10:41:30AM -0500, Rob Herring wrote:
> >> On Fri, Jun 9, 2017 at 9:16 AM, Oleksij Rempel  
> >> wrote:
> >>> This property is needed for barebox or may be other bootloaders
> >>> to set proper gpio configuration as early as possible.
> >>>
> >>> This example is mainly based on "lines-initial-states" property
> >>> from this binding documentation:
> >>> Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> >>
> >> Don't we have a binding for this already based on gpio-hogs.
> > 
> > Markus Pargmann was working on this topic before and suddenly was not
> > able to finish it.
> 
> that's fine, but the proposed extension is supposedly not wanted.

:(

> > I found only some not finished discussions and no code or documentation
> > in linux kernel upstream.
> > 
> > So far, I was able to find fallowing patches and discussions:
> > patch 23.08.2015, last comment 11.05.2017:
> > https://patchwork.kernel.org/patch/7096721/
> > 
> > patch 23.02.2016, last comment 09.03.2016:
> > https://patchwork.ozlabs.org/patch/586743/
> > 
> > Since there was objections about node-like design for gpio-initval, I
> > provided an array property, which is similar to initval properties already 
> > used
> > for different other device nodes. For example:
> > 
> > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> > qcom,ath10k-calibration-data
> > 
> > Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> > lines-initial-states
> 
> It'd rather be better to fix the drivers and remove the properties
> from these found device tree binding descriptions.

no sure if it is possible. WiFi calibration data is kind of initval too.

> > 
> > Please fixme if I miss something.
> 
> Why is GPIO hogging mechanism not good enough for your purpose?

Becouse it should not permanently hog a gpio. The "Hogging" should be
released as soon as some driver will request it.

Right now, if I define gpio-hog, boot loader will configure it and start
linux. But linux will never let it free.

If you have other suggestions which fit to this use case, please tell
me. I assume, right now I'm just blind.

Other way, I can imagine is to create real device nodes which use this
gpios. Compatible for this devices will be like this:
some_gpio_holder: gpio@0 {
compatible = "gpio-for-userspace";
gpio = < 5 GPIO_ACTIVE_HIGH>;
};

Boot loader will configure it as needed, an linux will do nothing with
it so it can be used over /dev/gpio interface.

> --
> With best wishes,
> Vladimir

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: linux-next: build failure after merge of the akpm-current tree

[Michael Ellerman]

Daniel Micay  writes:
> ...
>
> The arch mailing list was pinged about this which is how the powerpc
> folks got involved and fixed the issues there, including at least one
> runtime one. Not sure where (if anywhere) those are queued up, but Kees
> could pick those up too.

I was expecting Kees to pick them up.

cheers

Re: linux-next: build failure after merge of the akpm-current tree

[Michael Ellerman]

Daniel Micay  writes:
> ...
>
> The arch mailing list was pinged about this which is how the powerpc
> folks got involved and fixed the issues there, including at least one
> runtime one. Not sure where (if anywhere) those are queued up, but Kees
> could pick those up too.

I was expecting Kees to pick them up.

cheers

[PATCH] ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe'

[Christophe JAILLET]

If this memory allocation fail, we must disable what has been enabled.
Do not return immediately but go thrue the error handling path instead.

Also use 'devm_kmemdup' instead of 'devm_kzalloc+memcpy' to simplify code.

Signed-off-by: Christophe JAILLET 
---
 sound/soc/rockchip/rockchip_i2s.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index af5e0da144f7..f3aa3dfe914b 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -643,12 +643,13 @@ static int rockchip_i2s_probe(struct platform_device 
*pdev)
goto err_pm_disable;
}
 
-   soc_dai = devm_kzalloc(>dev,
+   soc_dai = devm_kmemdup(>dev, _i2s_dai
   sizeof(*soc_dai), GFP_KERNEL);
-   if (!soc_dai)
-   return -ENOMEM;
+   if (!soc_dai) {
+   err = -ENOMEM;
+   goto err_pm_disable;
+   }
 
-   memcpy(soc_dai, _i2s_dai, sizeof(*soc_dai));
if (!of_property_read_u32(node, "rockchip,playback-channels", )) {
if (val >= 2 && val <= 8)
soc_dai->playback.channels_max = val;
-- 
2.11.0

[PATCH] ASoC: rockchip: Fix an error handling in 'rockchip_i2s_probe'

[Christophe JAILLET]

If this memory allocation fail, we must disable what has been enabled.
Do not return immediately but go thrue the error handling path instead.

Also use 'devm_kmemdup' instead of 'devm_kzalloc+memcpy' to simplify code.

Signed-off-by: Christophe JAILLET 
---
 sound/soc/rockchip/rockchip_i2s.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index af5e0da144f7..f3aa3dfe914b 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -643,12 +643,13 @@ static int rockchip_i2s_probe(struct platform_device 
*pdev)
goto err_pm_disable;
}
 
-   soc_dai = devm_kzalloc(>dev,
+   soc_dai = devm_kmemdup(>dev, _i2s_dai
   sizeof(*soc_dai), GFP_KERNEL);
-   if (!soc_dai)
-   return -ENOMEM;
+   if (!soc_dai) {
+   err = -ENOMEM;
+   goto err_pm_disable;
+   }
 
-   memcpy(soc_dai, _i2s_dai, sizeof(*soc_dai));
if (!of_property_read_u32(node, "rockchip,playback-channels", )) {
if (val >= 2 && val <= 8)
soc_dai->playback.channels_max = val;
-- 
2.11.0

Re: [PATCH 10/18] spi: qup: Fix DMA mode interrupt handling

[Sricharan R]

Hi Andy,

On 6/15/2017 1:36 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:51:11PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> This is needed for v1, where the i/o completion is not
>>> handled in the dma driver.
>>>
>>> Signed-off-by: Andy Gross 
>>> Signed-off-by: Varadarajan Narayanan 
>>> ---
>>>  drivers/spi/spi-qup.c | 15 +--
>>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
>>> index 872de28..bd53e82 100644
>>> --- a/drivers/spi/spi-qup.c
>>> +++ b/drivers/spi/spi-qup.c
>>> @@ -510,9 +510,9 @@ static irqreturn_t spi_qup_qup_irq(int irq, void 
>>> *dev_id)
>>>  
>>> writel_relaxed(qup_err, controller->base + QUP_ERROR_FLAGS);
>>> writel_relaxed(spi_err, controller->base + SPI_ERROR_FLAGS);
>>> -   writel_relaxed(opflags, controller->base + QUP_OPERATIONAL);
>>>  
>>> if (!xfer) {
>>> +   writel_relaxed(opflags, controller->base + QUP_OPERATIONAL);
>>
>>  This does look correct to remove acknowledging the QUP in normal case and
>>   do it conditionally only when xfer = NULL.
> 
> This is to probably mask the issue of getting erroneous/spurious IRQs.
> 

 hmm, now the QUP_OPERATIONAL is not written to acknowledge the interrupts in
 normal case seems to be wrong.

>>
>>> dev_err_ratelimited(controller->dev, "unexpected irq %08x %08x 
>>> %08x\n",
>>> qup_err, spi_err, opflags);
>>> return IRQ_HANDLED;
>>> @@ -540,7 +540,15 @@ static irqreturn_t spi_qup_qup_irq(int irq, void 
>>> *dev_id)
>>> error = -EIO;
>>> }
>>>  
>>> -   if (!spi_qup_is_dma_xfer(controller->mode)) {
>>> +   if (spi_qup_is_dma_xfer(controller->mode)) {
>>> +   writel_relaxed(opflags, controller->base + QUP_OPERATIONAL);
>>> +   if (opflags & QUP_OP_IN_SERVICE_FLAG &&
>>> +   opflags & QUP_OP_MAX_INPUT_DONE_FLAG)
>>> +   complete(>rxc);
>>> +   if (opflags & QUP_OP_OUT_SERVICE_FLAG &&
>>> +   opflags & QUP_OP_MAX_OUTPUT_DONE_FLAG)
>>> +   complete(>txc);
>>> +   } else {
>>
>>  Is this because in patch #8 that we do not populate the dma callback
>>  for v1. If that is done, this should not be required at all, as the
>>  complete would be signalled from the dma callback.
> 
> I believe that is true.  There shouldn't be any IRQs for DMA enabled
> transactions (at least BAM-dma).

 yeah, the above hunk looks like is ADM specific, not sure why ADM cannot
 work with dma callbacks.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 10/18] spi: qup: Fix DMA mode interrupt handling

[Sricharan R]

Hi Andy,

On 6/15/2017 1:36 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:51:11PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> This is needed for v1, where the i/o completion is not
>>> handled in the dma driver.
>>>
>>> Signed-off-by: Andy Gross 
>>> Signed-off-by: Varadarajan Narayanan 
>>> ---
>>>  drivers/spi/spi-qup.c | 15 +--
>>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
>>> index 872de28..bd53e82 100644
>>> --- a/drivers/spi/spi-qup.c
>>> +++ b/drivers/spi/spi-qup.c
>>> @@ -510,9 +510,9 @@ static irqreturn_t spi_qup_qup_irq(int irq, void 
>>> *dev_id)
>>>  
>>> writel_relaxed(qup_err, controller->base + QUP_ERROR_FLAGS);
>>> writel_relaxed(spi_err, controller->base + SPI_ERROR_FLAGS);
>>> -   writel_relaxed(opflags, controller->base + QUP_OPERATIONAL);
>>>  
>>> if (!xfer) {
>>> +   writel_relaxed(opflags, controller->base + QUP_OPERATIONAL);
>>
>>  This does look correct to remove acknowledging the QUP in normal case and
>>   do it conditionally only when xfer = NULL.
> 
> This is to probably mask the issue of getting erroneous/spurious IRQs.
> 

 hmm, now the QUP_OPERATIONAL is not written to acknowledge the interrupts in
 normal case seems to be wrong.

>>
>>> dev_err_ratelimited(controller->dev, "unexpected irq %08x %08x 
>>> %08x\n",
>>> qup_err, spi_err, opflags);
>>> return IRQ_HANDLED;
>>> @@ -540,7 +540,15 @@ static irqreturn_t spi_qup_qup_irq(int irq, void 
>>> *dev_id)
>>> error = -EIO;
>>> }
>>>  
>>> -   if (!spi_qup_is_dma_xfer(controller->mode)) {
>>> +   if (spi_qup_is_dma_xfer(controller->mode)) {
>>> +   writel_relaxed(opflags, controller->base + QUP_OPERATIONAL);
>>> +   if (opflags & QUP_OP_IN_SERVICE_FLAG &&
>>> +   opflags & QUP_OP_MAX_INPUT_DONE_FLAG)
>>> +   complete(>rxc);
>>> +   if (opflags & QUP_OP_OUT_SERVICE_FLAG &&
>>> +   opflags & QUP_OP_MAX_OUTPUT_DONE_FLAG)
>>> +   complete(>txc);
>>> +   } else {
>>
>>  Is this because in patch #8 that we do not populate the dma callback
>>  for v1. If that is done, this should not be required at all, as the
>>  complete would be signalled from the dma callback.
> 
> I believe that is true.  There shouldn't be any IRQs for DMA enabled
> transactions (at least BAM-dma).

 yeah, the above hunk looks like is ADM specific, not sure why ADM cannot
 work with dma callbacks.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH kernel 1/3] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

[Alexey Kardashevskiy]

From: Yongji Xie 

We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates interrupts of all devices on the bus are
managed by the hardware enabling IRQ remapping(intel naming).
When the capability is enabled, a given PCI device can only
shoot the MSIs assigned for it. In other words, the hardware
can protect system from invalid MSIs of the device by checking
the target address and data when there is something wrong
with MSI part in device or device driver.

There is a existing flag for this capability in the IOMMU space:

enum iommu_cap {
IOMMU_CAP_CACHE_COHERENCY,
--->IOMMU_CAP_INTR_REMAP,
IOMMU_CAP_NOEXEC,
};

and Eric also posted a patchset [1] to abstract it on MSI
controller side for ARM. But it would make sense to have a
more common flag like PCI_BUS_FLAGS_MSI_REMAP so that we can
use a universal flag to test this capability on PCI side for
different archs.

With this flag enabled, we can easily know whether it's safe
to expose MSI-X tables of PCI BARs to userspace. Some usespace
drivers such as VFIO may benefit from this.

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html

Signed-off-by: Yongji Xie 
Signed-off-by: Alexey Kardashevskiy 
---
 include/linux/pci.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 8039f9f0ca05..2c6dbb3dd0da 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -200,6 +200,7 @@ enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI= (__force pci_bus_flags_t) 1,
PCI_BUS_FLAGS_NO_MMRBC  = (__force pci_bus_flags_t) 2,
PCI_BUS_FLAGS_NO_AERSID = (__force pci_bus_flags_t) 4,
+   PCI_BUS_FLAGS_MSI_REMAP = (__force pci_bus_flags_t) 8,
 };
 
 /* These values come from the PCI Express Spec */
-- 
2.11.0

[PATCH kernel 2/3] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

[Alexey Kardashevskiy]

From: Yongji Xie 

Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.

Signed-off-by: Yongji Xie 
Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 283caf1070c9..b6bda1918273 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3177,6 +3177,12 @@ static void pnv_pci_ioda_fixup(void)
 #endif
 }
 
+int pnv_pci_ioda_root_bridge_prepare(struct pci_host_bridge *bridge)
+{
+   bridge->bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+   return 0;
+}
+
 /*
  * Returns the alignment for I/O or memory windows for P2P
  * bridges. That actually depends on how PEs are segmented.
@@ -3861,6 +3867,8 @@ static void __init pnv_pci_init_ioda_phb(struct 
device_node *np,
 */
ppc_md.pcibios_fixup = pnv_pci_ioda_fixup;
 
+   ppc_md.pcibios_root_bridge_prepare = pnv_pci_ioda_root_bridge_prepare;
+
if (phb->type == PNV_PHB_NPU) {
hose->controller_ops = pnv_npu_ioda_controller_ops;
} else {
-- 
2.11.0

[PATCH kernel 2/3] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

[Alexey Kardashevskiy]

From: Yongji Xie 

Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.

Signed-off-by: Yongji Xie 
Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 283caf1070c9..b6bda1918273 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3177,6 +3177,12 @@ static void pnv_pci_ioda_fixup(void)
 #endif
 }
 
+int pnv_pci_ioda_root_bridge_prepare(struct pci_host_bridge *bridge)
+{
+   bridge->bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+   return 0;
+}
+
 /*
  * Returns the alignment for I/O or memory windows for P2P
  * bridges. That actually depends on how PEs are segmented.
@@ -3861,6 +3867,8 @@ static void __init pnv_pci_init_ioda_phb(struct 
device_node *np,
 */
ppc_md.pcibios_fixup = pnv_pci_ioda_fixup;
 
+   ppc_md.pcibios_root_bridge_prepare = pnv_pci_ioda_root_bridge_prepare;
+
if (phb->type == PNV_PHB_NPU) {
hose->controller_ops = pnv_npu_ioda_controller_ops;
} else {
-- 
2.11.0

[PATCH kernel 1/3] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

[Alexey Kardashevskiy]

From: Yongji Xie 

We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates interrupts of all devices on the bus are
managed by the hardware enabling IRQ remapping(intel naming).
When the capability is enabled, a given PCI device can only
shoot the MSIs assigned for it. In other words, the hardware
can protect system from invalid MSIs of the device by checking
the target address and data when there is something wrong
with MSI part in device or device driver.

There is a existing flag for this capability in the IOMMU space:

enum iommu_cap {
IOMMU_CAP_CACHE_COHERENCY,
--->IOMMU_CAP_INTR_REMAP,
IOMMU_CAP_NOEXEC,
};

and Eric also posted a patchset [1] to abstract it on MSI
controller side for ARM. But it would make sense to have a
more common flag like PCI_BUS_FLAGS_MSI_REMAP so that we can
use a universal flag to test this capability on PCI side for
different archs.

With this flag enabled, we can easily know whether it's safe
to expose MSI-X tables of PCI BARs to userspace. Some usespace
drivers such as VFIO may benefit from this.

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html

Signed-off-by: Yongji Xie 
Signed-off-by: Alexey Kardashevskiy 
---
 include/linux/pci.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 8039f9f0ca05..2c6dbb3dd0da 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -200,6 +200,7 @@ enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI= (__force pci_bus_flags_t) 1,
PCI_BUS_FLAGS_NO_MMRBC  = (__force pci_bus_flags_t) 2,
PCI_BUS_FLAGS_NO_AERSID = (__force pci_bus_flags_t) 4,
+   PCI_BUS_FLAGS_MSI_REMAP = (__force pci_bus_flags_t) 8,
 };
 
 /* These values come from the PCI Express Spec */
-- 
2.11.0

[PATCH kernel 0/3 REPOST] vfio-pci: Add support for mmapping MSI-X table

[Alexey Kardashevskiy]

Here is a patchset which Yongji was working on before
leaving IBM LTC. Since we still want to have this functionality
in the kernel (DPDK is the first user), here is a rebase
on the current upstream.


Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that users can write directly
to MSI-X table and generate an incorrect MSIs.

However, this will cause some performance issue when there
are some critical device registers in the same page as the
MSI-X table. We have to handle the mmio access to these
registers in QEMU emulation rather than in guest.

To solve this issue, this series allows to expose MSI-X table
to userspace when hardware enables the capability of interrupt
remapping which can ensure that a given PCI device can only
shoot the MSIs assigned for it. And we introduce a new bus_flags
PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
for different archs.

The patch 3 are based on the proposed patchset[1].

Changelog
v3:
- rebased on the current upstream

v2:
- Make the commit log more clear
- Replace pci_bus_check_msi_remapping() with pci_bus_msi_isolated()
  so that we could clearly know what the function does
- Set PCI_BUS_FLAGS_MSI_REMAP in pci_create_root_bus() instead
  of iommu_bus_notifier()
- Reserve VFIO_REGION_INFO_FLAG_CAPS when we allow to mmap MSI-X
  table so that we can know whether we allow to mmap MSI-X table
  in QEMU

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html


This is based on sha1
63f700aab4c1 Linus Torvalds "Merge tag 'xtensa-20170612' of 
git://github.com/jcmvbkbc/linux-xtensa".

Please comment. Thanks.



Yongji Xie (3):
  PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
  pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge
  vfio-pci: Allow to expose MSI-X table to userspace if interrupt
remapping is enabled

 include/linux/pci.h   |  1 +
 arch/powerpc/platforms/powernv/pci-ioda.c |  8 
 drivers/vfio/pci/vfio_pci.c   | 18 +++---
 drivers/vfio/pci/vfio_pci_rdwr.c  |  3 ++-
 4 files changed, 26 insertions(+), 4 deletions(-)

-- 
2.11.0

[PATCH kernel 3/3] vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is enabled

[Alexey Kardashevskiy]

From: Yongji Xie 

This patch tries to expose MSI-X tables to userspace if hardware
enables interrupt remapping which can ensure that a given PCI
device can only shoot the MSIs assigned for it. So we could
never worry that userspace driver can hurt other devices by
writing to the exposed MSI-X table directly.

Signed-off-by: Yongji Xie 
Signed-off-by: Alexey Kardashevskiy 
---
 drivers/vfio/pci/vfio_pci.c  | 18 +++---
 drivers/vfio/pci/vfio_pci_rdwr.c |  3 ++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 324c52e3a1a4..700e9d04dab5 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -564,8 +564,12 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
 
end = pci_resource_len(vdev->pdev, vdev->msix_bar);
 
-   /* If MSI-X table is aligned to the start or end, only one area */
-   if (((vdev->msix_offset & PAGE_MASK) == 0) ||
+   /*
+* If MSI-X table is allowed to mmap because of the capability
+* of IRQ remapping or aligned to the start or end, only one area
+*/
+   if ((vdev->pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP) ||
+   ((vdev->msix_offset & PAGE_MASK) == 0) ||
(PAGE_ALIGN(vdev->msix_offset + vdev->msix_size) >= end))
nr_areas = 1;
 
@@ -577,6 +581,12 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
 
sparse->nr_areas = nr_areas;
 
+   if (vdev->pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP) {
+   sparse->areas[i].offset = 0;
+   sparse->areas[i].size = end;
+   goto out;
+   }
+
if (vdev->msix_offset & PAGE_MASK) {
sparse->areas[i].offset = 0;
sparse->areas[i].size = vdev->msix_offset & PAGE_MASK;
@@ -590,6 +600,7 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
i++;
}
 
+out:
ret = vfio_info_add_capability(caps, VFIO_REGION_INFO_CAP_SPARSE_MMAP,
   sparse);
kfree(sparse);
@@ -1115,7 +1126,8 @@ static int vfio_pci_mmap(void *device_data, struct 
vm_area_struct *vma)
if (req_start + req_len > phys_len)
return -EINVAL;
 
-   if (index == vdev->msix_bar) {
+   if (index == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
/*
 * Disallow mmaps overlapping the MSI-X table; users don't
 * get to touch this directly.  We could find somewhere
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 357243d76f10..5378f2c3ac8e 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -164,7 +164,8 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, char 
__user *buf,
} else
io = vdev->barmap[bar];
 
-   if (bar == vdev->msix_bar) {
+   if (bar == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
x_start = vdev->msix_offset;
x_end = vdev->msix_offset + vdev->msix_size;
}
-- 
2.11.0

[PATCH kernel 0/3 REPOST] vfio-pci: Add support for mmapping MSI-X table

[Alexey Kardashevskiy]

Here is a patchset which Yongji was working on before
leaving IBM LTC. Since we still want to have this functionality
in the kernel (DPDK is the first user), here is a rebase
on the current upstream.


Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that users can write directly
to MSI-X table and generate an incorrect MSIs.

However, this will cause some performance issue when there
are some critical device registers in the same page as the
MSI-X table. We have to handle the mmio access to these
registers in QEMU emulation rather than in guest.

To solve this issue, this series allows to expose MSI-X table
to userspace when hardware enables the capability of interrupt
remapping which can ensure that a given PCI device can only
shoot the MSIs assigned for it. And we introduce a new bus_flags
PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
for different archs.

The patch 3 are based on the proposed patchset[1].

Changelog
v3:
- rebased on the current upstream

v2:
- Make the commit log more clear
- Replace pci_bus_check_msi_remapping() with pci_bus_msi_isolated()
  so that we could clearly know what the function does
- Set PCI_BUS_FLAGS_MSI_REMAP in pci_create_root_bus() instead
  of iommu_bus_notifier()
- Reserve VFIO_REGION_INFO_FLAG_CAPS when we allow to mmap MSI-X
  table so that we can know whether we allow to mmap MSI-X table
  in QEMU

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html


This is based on sha1
63f700aab4c1 Linus Torvalds "Merge tag 'xtensa-20170612' of 
git://github.com/jcmvbkbc/linux-xtensa".

Please comment. Thanks.



Yongji Xie (3):
  PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
  pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge
  vfio-pci: Allow to expose MSI-X table to userspace if interrupt
remapping is enabled

 include/linux/pci.h   |  1 +
 arch/powerpc/platforms/powernv/pci-ioda.c |  8 
 drivers/vfio/pci/vfio_pci.c   | 18 +++---
 drivers/vfio/pci/vfio_pci_rdwr.c  |  3 ++-
 4 files changed, 26 insertions(+), 4 deletions(-)

-- 
2.11.0

[PATCH kernel 3/3] vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is enabled

[Alexey Kardashevskiy]

From: Yongji Xie 

This patch tries to expose MSI-X tables to userspace if hardware
enables interrupt remapping which can ensure that a given PCI
device can only shoot the MSIs assigned for it. So we could
never worry that userspace driver can hurt other devices by
writing to the exposed MSI-X table directly.

Signed-off-by: Yongji Xie 
Signed-off-by: Alexey Kardashevskiy 
---
 drivers/vfio/pci/vfio_pci.c  | 18 +++---
 drivers/vfio/pci/vfio_pci_rdwr.c |  3 ++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 324c52e3a1a4..700e9d04dab5 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -564,8 +564,12 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
 
end = pci_resource_len(vdev->pdev, vdev->msix_bar);
 
-   /* If MSI-X table is aligned to the start or end, only one area */
-   if (((vdev->msix_offset & PAGE_MASK) == 0) ||
+   /*
+* If MSI-X table is allowed to mmap because of the capability
+* of IRQ remapping or aligned to the start or end, only one area
+*/
+   if ((vdev->pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP) ||
+   ((vdev->msix_offset & PAGE_MASK) == 0) ||
(PAGE_ALIGN(vdev->msix_offset + vdev->msix_size) >= end))
nr_areas = 1;
 
@@ -577,6 +581,12 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
 
sparse->nr_areas = nr_areas;
 
+   if (vdev->pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP) {
+   sparse->areas[i].offset = 0;
+   sparse->areas[i].size = end;
+   goto out;
+   }
+
if (vdev->msix_offset & PAGE_MASK) {
sparse->areas[i].offset = 0;
sparse->areas[i].size = vdev->msix_offset & PAGE_MASK;
@@ -590,6 +600,7 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
i++;
}
 
+out:
ret = vfio_info_add_capability(caps, VFIO_REGION_INFO_CAP_SPARSE_MMAP,
   sparse);
kfree(sparse);
@@ -1115,7 +1126,8 @@ static int vfio_pci_mmap(void *device_data, struct 
vm_area_struct *vma)
if (req_start + req_len > phys_len)
return -EINVAL;
 
-   if (index == vdev->msix_bar) {
+   if (index == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
/*
 * Disallow mmaps overlapping the MSI-X table; users don't
 * get to touch this directly.  We could find somewhere
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 357243d76f10..5378f2c3ac8e 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -164,7 +164,8 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, char 
__user *buf,
} else
io = vdev->barmap[bar];
 
-   if (bar == vdev->msix_bar) {
+   if (bar == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
x_start = vdev->msix_offset;
x_end = vdev->msix_offset + vdev->msix_size;
}
-- 
2.11.0

Re: [PATCH kernel 0/3] vfio-pci: Add support for mmapping MSI-X table

[Alexey Kardashevskiy]

Ouch, this is a wrong one, please ignore. I'll repost in a sec.


On 15/06/17 15:06, Alexey Kardashevskiy wrote:
> Here is a patchset which Yongji was working on before
> leaving IBM LTC. Since we still want to have this functionality
> in the kernel (DPDK is the first user), here is a rebase
> on the current upstream.
> 
> 
> Current vfio-pci implementation disallows to mmap the page
> containing MSI-X table in case that users can write directly
> to MSI-X table and generate an incorrect MSIs.
> 
> However, this will cause some performance issue when there
> are some critical device registers in the same page as the
> MSI-X table. We have to handle the mmio access to these
> registers in QEMU emulation rather than in guest.
> 
> To solve this issue, this series allows to expose MSI-X table
> to userspace when hardware enables the capability of interrupt
> remapping which can ensure that a given PCI device can only
> shoot the MSIs assigned for it. And we introduce a new bus_flags
> PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
> for different archs.
> 
> The patch 3 are based on the proposed patchset[1].
> 
> Changelog
> v3:
> - rebased on the current upstream
> 
> v2:
> - Make the commit log more clear
> - Replace pci_bus_check_msi_remapping() with pci_bus_msi_isolated()
>   so that we could clearly know what the function does
> - Set PCI_BUS_FLAGS_MSI_REMAP in pci_create_root_bus() instead
>   of iommu_bus_notifier()
> - Reserve VFIO_REGION_INFO_FLAG_CAPS when we allow to mmap MSI-X
>   table so that we can know whether we allow to mmap MSI-X table
>   in QEMU
> 
> [1] 
> https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html
> 
> 
> This is based on sha1
> 63f700aab4c1 Linus Torvalds "Merge tag 'xtensa-20170612' of 
> git://github.com/jcmvbkbc/linux-xtensa".
> 
> Please comment. Thanks.
> 
> 
> 
> Yongji Xie (3):
>   PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
>   pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge
>   vfio-pci: Allow to expose MSI-X table to userspace if interrupt
> remapping is enabled
> 
>  include/linux/pci.h   |  1 +
>  arch/powerpc/platforms/powernv/pci-ioda.c |  8 
>  drivers/vfio/pci/vfio_pci.c   | 18 +++---
>  drivers/vfio/pci/vfio_pci_rdwr.c  |  3 ++-
>  4 files changed, 26 insertions(+), 4 deletions(-)
> 


-- 
Alexey

Re: [PATCH kernel 0/3] vfio-pci: Add support for mmapping MSI-X table

[Alexey Kardashevskiy]

Ouch, this is a wrong one, please ignore. I'll repost in a sec.


On 15/06/17 15:06, Alexey Kardashevskiy wrote:
> Here is a patchset which Yongji was working on before
> leaving IBM LTC. Since we still want to have this functionality
> in the kernel (DPDK is the first user), here is a rebase
> on the current upstream.
> 
> 
> Current vfio-pci implementation disallows to mmap the page
> containing MSI-X table in case that users can write directly
> to MSI-X table and generate an incorrect MSIs.
> 
> However, this will cause some performance issue when there
> are some critical device registers in the same page as the
> MSI-X table. We have to handle the mmio access to these
> registers in QEMU emulation rather than in guest.
> 
> To solve this issue, this series allows to expose MSI-X table
> to userspace when hardware enables the capability of interrupt
> remapping which can ensure that a given PCI device can only
> shoot the MSIs assigned for it. And we introduce a new bus_flags
> PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
> for different archs.
> 
> The patch 3 are based on the proposed patchset[1].
> 
> Changelog
> v3:
> - rebased on the current upstream
> 
> v2:
> - Make the commit log more clear
> - Replace pci_bus_check_msi_remapping() with pci_bus_msi_isolated()
>   so that we could clearly know what the function does
> - Set PCI_BUS_FLAGS_MSI_REMAP in pci_create_root_bus() instead
>   of iommu_bus_notifier()
> - Reserve VFIO_REGION_INFO_FLAG_CAPS when we allow to mmap MSI-X
>   table so that we can know whether we allow to mmap MSI-X table
>   in QEMU
> 
> [1] 
> https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html
> 
> 
> This is based on sha1
> 63f700aab4c1 Linus Torvalds "Merge tag 'xtensa-20170612' of 
> git://github.com/jcmvbkbc/linux-xtensa".
> 
> Please comment. Thanks.
> 
> 
> 
> Yongji Xie (3):
>   PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
>   pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge
>   vfio-pci: Allow to expose MSI-X table to userspace if interrupt
> remapping is enabled
> 
>  include/linux/pci.h   |  1 +
>  arch/powerpc/platforms/powernv/pci-ioda.c |  8 
>  drivers/vfio/pci/vfio_pci.c   | 18 +++---
>  drivers/vfio/pci/vfio_pci_rdwr.c  |  3 ++-
>  4 files changed, 26 insertions(+), 4 deletions(-)
> 


-- 
Alexey

Re: [PATCH 2/3] arm: dts: mt2701: Add display bls related nodes for MT2701

[Weiqing Kong]

On Fri, 2017-06-09 at 10:12 +0200, Matthias Brugger wrote:
> 
> On 01/06/17 08:08, Erin Lo wrote:
> > From: YT Shen 
> 
> I miss the Singed-off-by from YT Shen.
> 
> > 
> > This patch adds the device node of display backlight for MT2701
> > 
> > Signed-off-by: Weiqing Kong 
> > Signed-off-by: Erin Lo 
> > ---
> >   arch/arm/boot/dts/mt2701-evb.dts | 29 +
> >   arch/arm/boot/dts/mt2701.dtsi|  9 +
> >   2 files changed, 38 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/mt2701-evb.dts 
> > b/arch/arm/boot/dts/mt2701-evb.dts
> > index a483798..e49c2b7 100644
> > --- a/arch/arm/boot/dts/mt2701-evb.dts
> > +++ b/arch/arm/boot/dts/mt2701-evb.dts
> > @@ -22,6 +22,35 @@
> > memory {
> > reg = <0 0x8000 0 0x4000>;
> > };
> > +
> > +   backlight_lcd: backlight_lcd {
> > +   compatible = "pwm-backlight";
> > +   pwms = < 0 10>;
> > +   brightness-levels = <
> > + 0  16  32  48  64  80  96 112
> > +   128 144 160 176 192 208 224 240
> > +   255
> > +   >;
> > +   default-brightness-level = <9>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_bls_gpio>;
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   pwm_bls_gpio: pwm_bls_gpio {
> > +   pins_cmd_dat {
> > +   pinmux = ;
> > +   };
> > +   };
> >   };
> >   
> >{
> > diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> > index de88bd7..4f110d5 100644
> > --- a/arch/arm/boot/dts/mt2701.dtsi
> > +++ b/arch/arm/boot/dts/mt2701.dtsi
> > @@ -366,6 +366,15 @@
> > #clock-cells = <1>;
> > };
> >   
> > +   bls: bls@1400a000 {
> > +   compatible = "mediatek,mt2701-disp-pwm";
> > +   reg = <0 0x1400a000 0 0x1000>;
> > +   #pwm-cells = <2>;
> > +   clocks = < CLK_MM_MDP_BLS_26M>, < CLK_MM_DISP_BLS>;
> > +   clock-names = "main", "mm";
> > +   status = "disabled";
> > +   };
> > +
> 
> Can you make this a new patch please. It's preferred to have one patch 
> for the dtsi and another one for the actual board.
> 
> Thanks,
> Matthias

OK, I will split it into two patches.

Thanks,
Weiqing Kong

> 
> > larb0: larb@1401 {
> > compatible = "mediatek,mt2701-smi-larb";
> > reg = <0 0x1401 0 0x1000>;
> > 

Re: [PATCH 2/3] arm: dts: mt2701: Add display bls related nodes for MT2701

[Weiqing Kong]

On Fri, 2017-06-09 at 10:12 +0200, Matthias Brugger wrote:
> 
> On 01/06/17 08:08, Erin Lo wrote:
> > From: YT Shen 
> 
> I miss the Singed-off-by from YT Shen.
> 
> > 
> > This patch adds the device node of display backlight for MT2701
> > 
> > Signed-off-by: Weiqing Kong 
> > Signed-off-by: Erin Lo 
> > ---
> >   arch/arm/boot/dts/mt2701-evb.dts | 29 +
> >   arch/arm/boot/dts/mt2701.dtsi|  9 +
> >   2 files changed, 38 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/mt2701-evb.dts 
> > b/arch/arm/boot/dts/mt2701-evb.dts
> > index a483798..e49c2b7 100644
> > --- a/arch/arm/boot/dts/mt2701-evb.dts
> > +++ b/arch/arm/boot/dts/mt2701-evb.dts
> > @@ -22,6 +22,35 @@
> > memory {
> > reg = <0 0x8000 0 0x4000>;
> > };
> > +
> > +   backlight_lcd: backlight_lcd {
> > +   compatible = "pwm-backlight";
> > +   pwms = < 0 10>;
> > +   brightness-levels = <
> > + 0  16  32  48  64  80  96 112
> > +   128 144 160 176 192 208 224 240
> > +   255
> > +   >;
> > +   default-brightness-level = <9>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_bls_gpio>;
> > +   };
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   status = "okay";
> > +};
> > +
> > + {
> > +   pwm_bls_gpio: pwm_bls_gpio {
> > +   pins_cmd_dat {
> > +   pinmux = ;
> > +   };
> > +   };
> >   };
> >   
> >{
> > diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> > index de88bd7..4f110d5 100644
> > --- a/arch/arm/boot/dts/mt2701.dtsi
> > +++ b/arch/arm/boot/dts/mt2701.dtsi
> > @@ -366,6 +366,15 @@
> > #clock-cells = <1>;
> > };
> >   
> > +   bls: bls@1400a000 {
> > +   compatible = "mediatek,mt2701-disp-pwm";
> > +   reg = <0 0x1400a000 0 0x1000>;
> > +   #pwm-cells = <2>;
> > +   clocks = < CLK_MM_MDP_BLS_26M>, < CLK_MM_DISP_BLS>;
> > +   clock-names = "main", "mm";
> > +   status = "disabled";
> > +   };
> > +
> 
> Can you make this a new patch please. It's preferred to have one patch 
> for the dtsi and another one for the actual board.
> 
> Thanks,
> Matthias

OK, I will split it into two patches.

Thanks,
Weiqing Kong

> 
> > larb0: larb@1401 {
> > compatible = "mediatek,mt2701-smi-larb";
> > reg = <0 0x1401 0 0x1000>;
> > 

Re: [PATCH 11/18] spi: qup: properly detect extra interrupts

[Sricharan R]

Hi Andy,

On 6/15/2017 1:29 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:57:25PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> It's possible for a SPI transaction to complete and get another
>>> interrupt and have it processed on the same spi_transfer before the
>>> transfer_one can set it to NULL.
>>>
>>> This masks unexpected interrupts, so let's set the spi_transfer to
>>> NULL in the interrupt once the transaction is done. So we can
>>> properly detect these bad interrupts and print warning messages.
>>>
>>> Signed-off-by: Matthew McClintock 
>>> Signed-off-by: Varadarajan Narayanan 
>>> ---
>>>  drivers/spi/spi-qup.c | 20 +++-
>>>  1 file changed, 11 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
>>> index bd53e82..1a2a9d9 100644
>>> --- a/drivers/spi/spi-qup.c
>>> +++ b/drivers/spi/spi-qup.c
>>> @@ -496,13 +496,13 @@ static irqreturn_t spi_qup_qup_irq(int irq, void 
>>> *dev_id)
>>> struct spi_qup *controller = dev_id;
>>> struct spi_transfer *xfer;
>>> u32 opflags, qup_err, spi_err;
>>> -   unsigned long flags;
>>> int error = 0;
>>> +   bool done = 0;
>>>  
>>> -   spin_lock_irqsave(>lock, flags);
>>> +   spin_lock(>lock);
>>> xfer = controller->xfer;
>>> controller->xfer = NULL;
>>> -   spin_unlock_irqrestore(>lock, flags);
>>> +   spin_unlock(>lock);
>>
>>  Why change the locking here ?
>>
>>>  
>>> qup_err = readl_relaxed(controller->base + QUP_ERROR_FLAGS);
>>> spi_err = readl_relaxed(controller->base + SPI_ERROR_FLAGS);
>>> @@ -556,16 +556,19 @@ static irqreturn_t spi_qup_qup_irq(int irq, void 
>>> *dev_id)
>>> spi_qup_write(controller, xfer);
>>> }
>>>  
>>> -   spin_lock_irqsave(>lock, flags);
>>> -   controller->error = error;
>>> -   controller->xfer = xfer;
>>> -   spin_unlock_irqrestore(>lock, flags);
>>> -
>>> /* re-read opflags as flags may have changed due to actions above */
>>> opflags = readl_relaxed(controller->base + QUP_OPERATIONAL);
>>>  
>>> if ((controller->rx_bytes == xfer->len &&
>>> (opflags & QUP_OP_MAX_INPUT_DONE_FLAG)) ||  error)
>>> +   done = true;
>>> +
>>> +   spin_lock(>lock);
>>> +   controller->error = error;
>>> +   controller->xfer = done ? NULL : xfer;
>>> +   spin_unlock(>lock);
>>> +
>>> +   if (done)
>>> complete(>done);
>>>  
>>   Its not clear, why the driver is setting the controller->xfer = NULL
>>   and restoring it inside the irq. This patch seems to fix things on
>>   top of that.
> 
> I think the original intent was to make sure that the irqhandler knew that 
> there
> was no outstanding transaction.  This begs the question of why that would ever
> be necessary.  I think it would suffice to rework all of that to remove that
> behavior and perhaps enable/disable the irq as we need to during transactions.
> 
> I've never been a fan of the controller->xfer being set to NULL.

 Agree, that part needs fixing in the original code. Also patch #10 changing the
 behavior to acknowledge the interrupts only when its spurious does not look
 correct. Trying to fix the original should simplify or avoid the spurious case
 itself.

Regards,
 Sricharan 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 11/18] spi: qup: properly detect extra interrupts

[Sricharan R]

Hi Andy,

On 6/15/2017 1:29 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:57:25PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> It's possible for a SPI transaction to complete and get another
>>> interrupt and have it processed on the same spi_transfer before the
>>> transfer_one can set it to NULL.
>>>
>>> This masks unexpected interrupts, so let's set the spi_transfer to
>>> NULL in the interrupt once the transaction is done. So we can
>>> properly detect these bad interrupts and print warning messages.
>>>
>>> Signed-off-by: Matthew McClintock 
>>> Signed-off-by: Varadarajan Narayanan 
>>> ---
>>>  drivers/spi/spi-qup.c | 20 +++-
>>>  1 file changed, 11 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
>>> index bd53e82..1a2a9d9 100644
>>> --- a/drivers/spi/spi-qup.c
>>> +++ b/drivers/spi/spi-qup.c
>>> @@ -496,13 +496,13 @@ static irqreturn_t spi_qup_qup_irq(int irq, void 
>>> *dev_id)
>>> struct spi_qup *controller = dev_id;
>>> struct spi_transfer *xfer;
>>> u32 opflags, qup_err, spi_err;
>>> -   unsigned long flags;
>>> int error = 0;
>>> +   bool done = 0;
>>>  
>>> -   spin_lock_irqsave(>lock, flags);
>>> +   spin_lock(>lock);
>>> xfer = controller->xfer;
>>> controller->xfer = NULL;
>>> -   spin_unlock_irqrestore(>lock, flags);
>>> +   spin_unlock(>lock);
>>
>>  Why change the locking here ?
>>
>>>  
>>> qup_err = readl_relaxed(controller->base + QUP_ERROR_FLAGS);
>>> spi_err = readl_relaxed(controller->base + SPI_ERROR_FLAGS);
>>> @@ -556,16 +556,19 @@ static irqreturn_t spi_qup_qup_irq(int irq, void 
>>> *dev_id)
>>> spi_qup_write(controller, xfer);
>>> }
>>>  
>>> -   spin_lock_irqsave(>lock, flags);
>>> -   controller->error = error;
>>> -   controller->xfer = xfer;
>>> -   spin_unlock_irqrestore(>lock, flags);
>>> -
>>> /* re-read opflags as flags may have changed due to actions above */
>>> opflags = readl_relaxed(controller->base + QUP_OPERATIONAL);
>>>  
>>> if ((controller->rx_bytes == xfer->len &&
>>> (opflags & QUP_OP_MAX_INPUT_DONE_FLAG)) ||  error)
>>> +   done = true;
>>> +
>>> +   spin_lock(>lock);
>>> +   controller->error = error;
>>> +   controller->xfer = done ? NULL : xfer;
>>> +   spin_unlock(>lock);
>>> +
>>> +   if (done)
>>> complete(>done);
>>>  
>>   Its not clear, why the driver is setting the controller->xfer = NULL
>>   and restoring it inside the irq. This patch seems to fix things on
>>   top of that.
> 
> I think the original intent was to make sure that the irqhandler knew that 
> there
> was no outstanding transaction.  This begs the question of why that would ever
> be necessary.  I think it would suffice to rework all of that to remove that
> behavior and perhaps enable/disable the irq as we need to during transactions.
> 
> I've never been a fan of the controller->xfer being set to NULL.

 Agree, that part needs fixing in the original code. Also patch #10 changing the
 behavior to acknowledge the interrupts only when its spurious does not look
 correct. Trying to fix the original should simplify or avoid the spurious case
 itself.

Regards,
 Sricharan 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

[Greg KH]

On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +struct sbefifo {
> + struct timer_list poll_timer;
> + struct fsi_device *fsi_dev;
> + struct miscdevice mdev;
> + wait_queue_head_t wait;
> + struct list_head link;
> + struct list_head xfrs;
> + struct kref kref;
> + spinlock_t lock;
> + char name[32];
> + int idx;
> + int rc;
> +};

You have a misc device, a pointer to a fsi_device, and a kref in this
structure.  Which one actually does the reference counting?  It seems
there are 3 different ways it could happen.  That's not right at all,
and ripe for lots and lots of confusion.  Only use one please.

thanks,

greg k-h

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

[Greg KH]

On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +struct sbefifo {
> + struct timer_list poll_timer;
> + struct fsi_device *fsi_dev;
> + struct miscdevice mdev;
> + wait_queue_head_t wait;
> + struct list_head link;
> + struct list_head xfrs;
> + struct kref kref;
> + spinlock_t lock;
> + char name[32];
> + int idx;
> + int rc;
> +};

You have a misc device, a pointer to a fsi_device, and a kref in this
structure.  Which one actually does the reference counting?  It seems
there are 3 different ways it could happen.  That's not right at all,
and ripe for lots and lots of confusion.  Only use one please.

thanks,

greg k-h

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

[Greg KH]

On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +static ssize_t sbefifo_read(struct file *file, char __user *buf,
> + size_t len, loff_t *offset)
> +{
> + struct sbefifo_client *client = file->private_data;
> +
> + WARN_ON(*offset);

Huh?  Why?

> + if (!access_ok(VERIFY_WRITE, buf, len))
> + return -EFAULT;

What does this check?  You should never need to call access_ok in any
driver, copy_from/to_user handles that all for you just fine.

thanks,

greg k-h

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

[Greg KH]

On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +static ssize_t sbefifo_read(struct file *file, char __user *buf,
> + size_t len, loff_t *offset)
> +{
> + struct sbefifo_client *client = file->private_data;
> +
> + WARN_ON(*offset);

Huh?  Why?

> + if (!access_ok(VERIFY_WRITE, buf, len))
> + return -EFAULT;

What does this check?  You should never need to call access_ok in any
driver, copy_from/to_user handles that all for you just fine.

thanks,

greg k-h

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

[Greg KH]

On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> + dev_info(dev, "Found sbefifo device\n");

Don't be chatty, this isn't needed at all, right?

thanks,

greg k-h

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

[Greg KH]

On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> + dev_info(dev, "Found sbefifo device\n");

Don't be chatty, this isn't needed at all, right?

thanks,

greg k-h

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

[Greg KH]

On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> --- /dev/null
> +++ b/include/linux/fsi-sbefifo.h
> @@ -0,0 +1,30 @@
> +/*
> + * SBEFIFO FSI Client device driver
> + *
> + * Copyright (C) IBM Corporation 2017
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERGCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef LINUX_FSI_SBEFIFO_H
> +#define LINUX_FSI_SBEFIFO_H
> +
> +struct device;
> +struct sbefifo_client;
> +
> +extern struct sbefifo_client *sbefifo_drv_open(struct device *dev,
> +unsigned long flags);
> +extern int sbefifo_drv_read(struct sbefifo_client *client, char *buf,
> + size_t len);
> +extern int sbefifo_drv_write(struct sbefifo_client *client, const char *buf,
> +  size_t len);
> +extern void sbefifo_drv_release(struct sbefifo_client *client);
> +
> +#endif /* LINUX_FSI_SBEFIFO_H */

Why do you need this .h file at all?  Nothing is calling it, right?

thanks,

greg k-h

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

[Greg KH]

On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> --- /dev/null
> +++ b/include/linux/fsi-sbefifo.h
> @@ -0,0 +1,30 @@
> +/*
> + * SBEFIFO FSI Client device driver
> + *
> + * Copyright (C) IBM Corporation 2017
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERGCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef LINUX_FSI_SBEFIFO_H
> +#define LINUX_FSI_SBEFIFO_H
> +
> +struct device;
> +struct sbefifo_client;
> +
> +extern struct sbefifo_client *sbefifo_drv_open(struct device *dev,
> +unsigned long flags);
> +extern int sbefifo_drv_read(struct sbefifo_client *client, char *buf,
> + size_t len);
> +extern int sbefifo_drv_write(struct sbefifo_client *client, const char *buf,
> +  size_t len);
> +extern void sbefifo_drv_release(struct sbefifo_client *client);
> +
> +#endif /* LINUX_FSI_SBEFIFO_H */

Why do you need this .h file at all?  Nothing is calling it, right?

thanks,

greg k-h

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

[Greg KH]

On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +static DEFINE_IDA(sbefifo_ida);

WHen your module exits, you don't clean up this structure.  Common
mistake :)

thanks,

greg k-h

xgetbv nondeterminism

[Andy Lutomirski]

I saw your post about XGETBV
(http://robert.ocallahan.org/2017/06/another-case-of-obscure-cpu.html),
and it sounds like it could plausibly be a kernel bug.  What kernel
are you on?

I wonder if CPUs have an optimization in which, if a given register
set is in the init state but XINUSE=1, then they'll notice when
XRSTORS runs and clear XINUSE.  If so, that would be rather
unfortunate IMO.

Dave, why is XINUSE exposed at all to userspace?  IIRC it's visible
via XGETBV, XSAVEC, and maybe even XSAVE, and ISTM that making it
visible to userspace serves basically no performance purpose and just
encourages annoying corner cases.  I can see an argument that making
XSAVEC fast is nice for user threading libraries, but user threading
libraries that use XSAVEC are probably doing it wrong and should
instead rely on ABI guarantees to avoid saving and restoring extended
state at all.

To be fair, glibc uses this new XGETBV feature, but I suspect its
usage is rather dubious.  Shouldn't it just do XSAVEC directly rather
than rolling its own code?

Re: [PATCH linux] drivers/fsi: Add SBEFIFO FSI client device driver

[Greg KH]

On Wed, Jun 14, 2017 at 02:47:27PM -0500, Edward A. James wrote:
> +static DEFINE_IDA(sbefifo_ida);

WHen your module exits, you don't clean up this structure.  Common
mistake :)

thanks,

greg k-h

xgetbv nondeterminism

[Andy Lutomirski]

I saw your post about XGETBV
(http://robert.ocallahan.org/2017/06/another-case-of-obscure-cpu.html),
and it sounds like it could plausibly be a kernel bug.  What kernel
are you on?

I wonder if CPUs have an optimization in which, if a given register
set is in the init state but XINUSE=1, then they'll notice when
XRSTORS runs and clear XINUSE.  If so, that would be rather
unfortunate IMO.

Dave, why is XINUSE exposed at all to userspace?  IIRC it's visible
via XGETBV, XSAVEC, and maybe even XSAVE, and ISTM that making it
visible to userspace serves basically no performance purpose and just
encourages annoying corner cases.  I can see an argument that making
XSAVEC fast is nice for user threading libraries, but user threading
libraries that use XSAVEC are probably doing it wrong and should
instead rely on ABI guarantees to avoid saving and restoring extended
state at all.

To be fair, glibc uses this new XGETBV feature, but I suspect its
usage is rather dubious.  Shouldn't it just do XSAVEC directly rather
than rolling its own code?

Re: [PATCH 07/18] spi: qup: Fix transaction done signaling

[Sricharan R]

Hi Andy,

On 6/15/2017 1:21 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:43:43PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> Wait to signal done until we get all of the interrupts we are expecting
>>> to get for a transaction.  If we don't wait for the input done flag, we
>>> can be inbetween transactions when the done flag comes in and this can
>>> mess up the next transaction.
>>>
>>> Signed-off-by: Andy Gross 
>>> Signed-off-by: Varadarajan Narayanan 
>>> ---
>>>  drivers/spi/spi-qup.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
>>> index 2124815..7c22ee4 100644
>>> --- a/drivers/spi/spi-qup.c
>>> +++ b/drivers/spi/spi-qup.c
>>> @@ -465,7 +465,8 @@ static irqreturn_t spi_qup_qup_irq(int irq, void 
>>> *dev_id)
>>> controller->xfer = xfer;
>>> spin_unlock_irqrestore(>lock, flags);
>>>  
>>> -   if (controller->rx_bytes == xfer->len || error)
>>> +   if ((controller->rx_bytes == xfer->len &&
>>> +   (opflags & QUP_OP_MAX_INPUT_DONE_FLAG)) ||  error)
>>
>>  Not sure why we need this additional check, because having read all the
>>  bytes implies transfer complete (or) why not just check only for
>>  QUP_OP_MAX_INPUT_DONE_FLAG ?
> 
> So you can receive an interrupt for the last data without it having also
> signalled the INPUT_DONE.  That means you'd have one more IRQ come in and if 
> you
> don't wait for that, you could start up the next transaction and have an irq
> come in that screws up that transaction.
> 
> It might be sufficient to just wait for the INPUT_DONE_FLAG.  That cannot be
> signalled unless the rx_bytes == xfer->len.
> 

 Right, that should simply it little bit.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 07/18] spi: qup: Fix transaction done signaling

[Sricharan R]

Hi Andy,

On 6/15/2017 1:21 AM, Andy Gross wrote:
> On Wed, Jun 14, 2017 at 12:43:43PM +0530, Sricharan R wrote:
>> Hi Varada,
>>
>> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote:
>>> Wait to signal done until we get all of the interrupts we are expecting
>>> to get for a transaction.  If we don't wait for the input done flag, we
>>> can be inbetween transactions when the done flag comes in and this can
>>> mess up the next transaction.
>>>
>>> Signed-off-by: Andy Gross 
>>> Signed-off-by: Varadarajan Narayanan 
>>> ---
>>>  drivers/spi/spi-qup.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c
>>> index 2124815..7c22ee4 100644
>>> --- a/drivers/spi/spi-qup.c
>>> +++ b/drivers/spi/spi-qup.c
>>> @@ -465,7 +465,8 @@ static irqreturn_t spi_qup_qup_irq(int irq, void 
>>> *dev_id)
>>> controller->xfer = xfer;
>>> spin_unlock_irqrestore(>lock, flags);
>>>  
>>> -   if (controller->rx_bytes == xfer->len || error)
>>> +   if ((controller->rx_bytes == xfer->len &&
>>> +   (opflags & QUP_OP_MAX_INPUT_DONE_FLAG)) ||  error)
>>
>>  Not sure why we need this additional check, because having read all the
>>  bytes implies transfer complete (or) why not just check only for
>>  QUP_OP_MAX_INPUT_DONE_FLAG ?
> 
> So you can receive an interrupt for the last data without it having also
> signalled the INPUT_DONE.  That means you'd have one more IRQ come in and if 
> you
> don't wait for that, you could start up the next transaction and have an irq
> come in that screws up that transaction.
> 
> It might be sufficient to just wait for the INPUT_DONE_FLAG.  That cannot be
> signalled unless the rx_bytes == xfer->len.
> 

 Right, that should simply it little bit.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

[Stephen Rothwell]

Hi Daniel,

On Thu, 15 Jun 2017 00:49:21 -0400 Daniel Micay  wrote:
>
> > So after that the errors (x86_64 allmodconfig build) are only:
> > 
> > In file included from include/linux/bitmap.h:8:0,
> >  from include/linux/cpumask.h:11,
> >  from arch/x86/include/asm/cpumask.h:4,
> >  from arch/x86/include/asm/msr.h:10,
> >  from arch/x86/include/asm/processor.h:20,
> >  from arch/x86/include/asm/cpufeature.h:4,
> >  from arch/x86/include/asm/thread_info.h:52,
> >  from include/linux/thread_info.h:37,
> >  from arch/x86/include/asm/preempt.h:6,
> >  from include/linux/preempt.h:80,
> >  from include/linux/spinlock.h:50,
> >  from include/linux/mmzone.h:7,
> >  from include/linux/gfp.h:5,
> >  from arch/x86/power/hibernate_64.c:11:
> > In function 'memcpy',
> > inlined from 'relocate_restore_code' at
> > arch/x86/power/hibernate_64.c:150:2,
> > inlined from 'swsusp_arch_resume' at
> > arch/x86/power/hibernate_64.c:186:8:
> > include/linux/string.h:309:4: error: call to '__read_overflow2'
> > declared with attribute error: detected read beyond size of object
> > passed as 2nd parameter
> > __read_overflow2();
> > ^
> > In file included from include/linux/bitmap.h:8:0,
> >  from include/linux/cpumask.h:11,
> >  from arch/x86/include/asm/cpumask.h:4,
> >  from arch/x86/include/asm/msr.h:10,
> >  from arch/x86/include/asm/processor.h:20,
> >  from arch/x86/include/asm/cpufeature.h:4,
> >  from arch/x86/include/asm/thread_info.h:52,
> >  from include/linux/thread_info.h:37,
> >  from arch/x86/include/asm/preempt.h:6,
> >  from include/linux/preempt.h:80,
> >  from include/linux/spinlock.h:50,
> >  from include/linux/mmzone.h:7,
> >  from include/linux/gfp.h:5,
> >  from include/linux/mm.h:9,
> >  from kernel/kexec_file.c:15:
> > In function 'memcmp',
> > inlined from 'kexec_load_purgatory' at kernel/kexec_file.c:900:6:
> > include/linux/string.h:348:4: error: call to '__read_overflow'
> > declared with attribute error: detected read beyond size of object
> > passed as 1st parameter
> > __read_overflow();
> > ^
> >   
> 
> Kees has the remaining ones here now:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=for-next/kspp

Excellent, so hopefully tomorrow I won't need to revert (at which point
the overnight builds (http://kisskb.ellerman.id.au/linux-next) will
point out any more problems).

> Not entirely sure what happened to the powerpc bits though.

Maybe in the powerpc tree
(git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git#next).

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

[Stephen Rothwell]

Hi Daniel,

On Thu, 15 Jun 2017 00:49:21 -0400 Daniel Micay  wrote:
>
> > So after that the errors (x86_64 allmodconfig build) are only:
> > 
> > In file included from include/linux/bitmap.h:8:0,
> >  from include/linux/cpumask.h:11,
> >  from arch/x86/include/asm/cpumask.h:4,
> >  from arch/x86/include/asm/msr.h:10,
> >  from arch/x86/include/asm/processor.h:20,
> >  from arch/x86/include/asm/cpufeature.h:4,
> >  from arch/x86/include/asm/thread_info.h:52,
> >  from include/linux/thread_info.h:37,
> >  from arch/x86/include/asm/preempt.h:6,
> >  from include/linux/preempt.h:80,
> >  from include/linux/spinlock.h:50,
> >  from include/linux/mmzone.h:7,
> >  from include/linux/gfp.h:5,
> >  from arch/x86/power/hibernate_64.c:11:
> > In function 'memcpy',
> > inlined from 'relocate_restore_code' at
> > arch/x86/power/hibernate_64.c:150:2,
> > inlined from 'swsusp_arch_resume' at
> > arch/x86/power/hibernate_64.c:186:8:
> > include/linux/string.h:309:4: error: call to '__read_overflow2'
> > declared with attribute error: detected read beyond size of object
> > passed as 2nd parameter
> > __read_overflow2();
> > ^
> > In file included from include/linux/bitmap.h:8:0,
> >  from include/linux/cpumask.h:11,
> >  from arch/x86/include/asm/cpumask.h:4,
> >  from arch/x86/include/asm/msr.h:10,
> >  from arch/x86/include/asm/processor.h:20,
> >  from arch/x86/include/asm/cpufeature.h:4,
> >  from arch/x86/include/asm/thread_info.h:52,
> >  from include/linux/thread_info.h:37,
> >  from arch/x86/include/asm/preempt.h:6,
> >  from include/linux/preempt.h:80,
> >  from include/linux/spinlock.h:50,
> >  from include/linux/mmzone.h:7,
> >  from include/linux/gfp.h:5,
> >  from include/linux/mm.h:9,
> >  from kernel/kexec_file.c:15:
> > In function 'memcmp',
> > inlined from 'kexec_load_purgatory' at kernel/kexec_file.c:900:6:
> > include/linux/string.h:348:4: error: call to '__read_overflow'
> > declared with attribute error: detected read beyond size of object
> > passed as 1st parameter
> > __read_overflow();
> > ^
> >   
> 
> Kees has the remaining ones here now:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=for-next/kspp

Excellent, so hopefully tomorrow I won't need to revert (at which point
the overnight builds (http://kisskb.ellerman.id.au/linux-next) will
point out any more problems).

> Not entirely sure what happened to the powerpc bits though.

Maybe in the powerpc tree
(git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git#next).

-- 
Cheers,
Stephen Rothwell

[PATCH kernel 2/3] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

[Alexey Kardashevskiy]

From: Yongji Xie 

Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.

Signed-off-by: Yongji Xie 
Reviewed-by: Alexey Kardashevskiy 
Signed-off-by: Paul Mackerras 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 283caf1070c9..b6bda1918273 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3177,6 +3177,12 @@ static void pnv_pci_ioda_fixup(void)
 #endif
 }
 
+int pnv_pci_ioda_root_bridge_prepare(struct pci_host_bridge *bridge)
+{
+   bridge->bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+   return 0;
+}
+
 /*
  * Returns the alignment for I/O or memory windows for P2P
  * bridges. That actually depends on how PEs are segmented.
@@ -3861,6 +3867,8 @@ static void __init pnv_pci_init_ioda_phb(struct 
device_node *np,
 */
ppc_md.pcibios_fixup = pnv_pci_ioda_fixup;
 
+   ppc_md.pcibios_root_bridge_prepare = pnv_pci_ioda_root_bridge_prepare;
+
if (phb->type == PNV_PHB_NPU) {
hose->controller_ops = pnv_npu_ioda_controller_ops;
} else {
-- 
2.11.0

[PATCH kernel 3/3] vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is enabled

[Alexey Kardashevskiy]

From: Yongji Xie 

This patch tries to expose MSI-X tables to userspace if hardware
enables interrupt remapping which can ensure that a given PCI
device can only shoot the MSIs assigned for it. So we could
never worry that userspace driver can hurt other devices by
writing to the exposed MSI-X table directly.

Signed-off-by: Yongji Xie 
Signed-off-by: Michael Roth 
Signed-off-by: Paul Mackerras 
---
 drivers/vfio/pci/vfio_pci.c  | 18 +++---
 drivers/vfio/pci/vfio_pci_rdwr.c |  3 ++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 324c52e3a1a4..700e9d04dab5 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -564,8 +564,12 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
 
end = pci_resource_len(vdev->pdev, vdev->msix_bar);
 
-   /* If MSI-X table is aligned to the start or end, only one area */
-   if (((vdev->msix_offset & PAGE_MASK) == 0) ||
+   /*
+* If MSI-X table is allowed to mmap because of the capability
+* of IRQ remapping or aligned to the start or end, only one area
+*/
+   if ((vdev->pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP) ||
+   ((vdev->msix_offset & PAGE_MASK) == 0) ||
(PAGE_ALIGN(vdev->msix_offset + vdev->msix_size) >= end))
nr_areas = 1;
 
@@ -577,6 +581,12 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
 
sparse->nr_areas = nr_areas;
 
+   if (vdev->pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP) {
+   sparse->areas[i].offset = 0;
+   sparse->areas[i].size = end;
+   goto out;
+   }
+
if (vdev->msix_offset & PAGE_MASK) {
sparse->areas[i].offset = 0;
sparse->areas[i].size = vdev->msix_offset & PAGE_MASK;
@@ -590,6 +600,7 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
i++;
}
 
+out:
ret = vfio_info_add_capability(caps, VFIO_REGION_INFO_CAP_SPARSE_MMAP,
   sparse);
kfree(sparse);
@@ -1115,7 +1126,8 @@ static int vfio_pci_mmap(void *device_data, struct 
vm_area_struct *vma)
if (req_start + req_len > phys_len)
return -EINVAL;
 
-   if (index == vdev->msix_bar) {
+   if (index == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
/*
 * Disallow mmaps overlapping the MSI-X table; users don't
 * get to touch this directly.  We could find somewhere
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 357243d76f10..5378f2c3ac8e 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -164,7 +164,8 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, char 
__user *buf,
} else
io = vdev->barmap[bar];
 
-   if (bar == vdev->msix_bar) {
+   if (bar == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
x_start = vdev->msix_offset;
x_end = vdev->msix_offset + vdev->msix_size;
}
-- 
2.11.0

[PATCH kernel 1/3] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

[Alexey Kardashevskiy]

From: Yongji Xie 

We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates interrupts of all devices on the bus are
managed by the hardware enabling IRQ remapping(intel naming).
When the capability is enabled, a given PCI device can only
shoot the MSIs assigned for it. In other words, the hardware
can protect system from invalid MSIs of the device by checking
the target address and data when there is something wrong
with MSI part in device or device driver.

There is a existing flag for this capability in the IOMMU space:

enum iommu_cap {
IOMMU_CAP_CACHE_COHERENCY,
--->IOMMU_CAP_INTR_REMAP,
IOMMU_CAP_NOEXEC,
};

and Eric also posted a patchset [1] to abstract it on MSI
controller side for ARM. But it would make sense to have a
more common flag like PCI_BUS_FLAGS_MSI_REMAP so that we can
use a universal flag to test this capability on PCI side for
different archs.

With this flag enabled, we can easily know whether it's safe
to expose MSI-X tables of PCI BARs to userspace. Some usespace
drivers such as VFIO may benefit from this.

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html

Signed-off-by: Yongji Xie 
Signed-off-by: Paul Mackerras 
---
 include/linux/pci.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 8039f9f0ca05..2c6dbb3dd0da 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -200,6 +200,7 @@ enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI= (__force pci_bus_flags_t) 1,
PCI_BUS_FLAGS_NO_MMRBC  = (__force pci_bus_flags_t) 2,
PCI_BUS_FLAGS_NO_AERSID = (__force pci_bus_flags_t) 4,
+   PCI_BUS_FLAGS_MSI_REMAP = (__force pci_bus_flags_t) 8,
 };
 
 /* These values come from the PCI Express Spec */
-- 
2.11.0

[PATCH kernel 0/3] vfio-pci: Add support for mmapping MSI-X table

[Alexey Kardashevskiy]

Here is a patchset which Yongji was working on before
leaving IBM LTC. Since we still want to have this functionality
in the kernel (DPDK is the first user), here is a rebase
on the current upstream.


Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that users can write directly
to MSI-X table and generate an incorrect MSIs.

However, this will cause some performance issue when there
are some critical device registers in the same page as the
MSI-X table. We have to handle the mmio access to these
registers in QEMU emulation rather than in guest.

To solve this issue, this series allows to expose MSI-X table
to userspace when hardware enables the capability of interrupt
remapping which can ensure that a given PCI device can only
shoot the MSIs assigned for it. And we introduce a new bus_flags
PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
for different archs.

The patch 3 are based on the proposed patchset[1].

Changelog
v3:
- rebased on the current upstream

v2:
- Make the commit log more clear
- Replace pci_bus_check_msi_remapping() with pci_bus_msi_isolated()
  so that we could clearly know what the function does
- Set PCI_BUS_FLAGS_MSI_REMAP in pci_create_root_bus() instead
  of iommu_bus_notifier()
- Reserve VFIO_REGION_INFO_FLAG_CAPS when we allow to mmap MSI-X
  table so that we can know whether we allow to mmap MSI-X table
  in QEMU

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html


This is based on sha1
63f700aab4c1 Linus Torvalds "Merge tag 'xtensa-20170612' of 
git://github.com/jcmvbkbc/linux-xtensa".

Please comment. Thanks.



Yongji Xie (3):
  PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
  pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge
  vfio-pci: Allow to expose MSI-X table to userspace if interrupt
remapping is enabled

 include/linux/pci.h   |  1 +
 arch/powerpc/platforms/powernv/pci-ioda.c |  8 
 drivers/vfio/pci/vfio_pci.c   | 18 +++---
 drivers/vfio/pci/vfio_pci_rdwr.c  |  3 ++-
 4 files changed, 26 insertions(+), 4 deletions(-)

-- 
2.11.0

[PATCH kernel 2/3] pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge

[Alexey Kardashevskiy]

From: Yongji Xie 

Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.

Signed-off-by: Yongji Xie 
Reviewed-by: Alexey Kardashevskiy 
Signed-off-by: Paul Mackerras 
---
 arch/powerpc/platforms/powernv/pci-ioda.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 283caf1070c9..b6bda1918273 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3177,6 +3177,12 @@ static void pnv_pci_ioda_fixup(void)
 #endif
 }
 
+int pnv_pci_ioda_root_bridge_prepare(struct pci_host_bridge *bridge)
+{
+   bridge->bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+   return 0;
+}
+
 /*
  * Returns the alignment for I/O or memory windows for P2P
  * bridges. That actually depends on how PEs are segmented.
@@ -3861,6 +3867,8 @@ static void __init pnv_pci_init_ioda_phb(struct 
device_node *np,
 */
ppc_md.pcibios_fixup = pnv_pci_ioda_fixup;
 
+   ppc_md.pcibios_root_bridge_prepare = pnv_pci_ioda_root_bridge_prepare;
+
if (phb->type == PNV_PHB_NPU) {
hose->controller_ops = pnv_npu_ioda_controller_ops;
} else {
-- 
2.11.0

[PATCH kernel 3/3] vfio-pci: Allow to expose MSI-X table to userspace if interrupt remapping is enabled

[Alexey Kardashevskiy]

From: Yongji Xie 

This patch tries to expose MSI-X tables to userspace if hardware
enables interrupt remapping which can ensure that a given PCI
device can only shoot the MSIs assigned for it. So we could
never worry that userspace driver can hurt other devices by
writing to the exposed MSI-X table directly.

Signed-off-by: Yongji Xie 
Signed-off-by: Michael Roth 
Signed-off-by: Paul Mackerras 
---
 drivers/vfio/pci/vfio_pci.c  | 18 +++---
 drivers/vfio/pci/vfio_pci_rdwr.c |  3 ++-
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 324c52e3a1a4..700e9d04dab5 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -564,8 +564,12 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
 
end = pci_resource_len(vdev->pdev, vdev->msix_bar);
 
-   /* If MSI-X table is aligned to the start or end, only one area */
-   if (((vdev->msix_offset & PAGE_MASK) == 0) ||
+   /*
+* If MSI-X table is allowed to mmap because of the capability
+* of IRQ remapping or aligned to the start or end, only one area
+*/
+   if ((vdev->pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP) ||
+   ((vdev->msix_offset & PAGE_MASK) == 0) ||
(PAGE_ALIGN(vdev->msix_offset + vdev->msix_size) >= end))
nr_areas = 1;
 
@@ -577,6 +581,12 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
 
sparse->nr_areas = nr_areas;
 
+   if (vdev->pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP) {
+   sparse->areas[i].offset = 0;
+   sparse->areas[i].size = end;
+   goto out;
+   }
+
if (vdev->msix_offset & PAGE_MASK) {
sparse->areas[i].offset = 0;
sparse->areas[i].size = vdev->msix_offset & PAGE_MASK;
@@ -590,6 +600,7 @@ static int msix_sparse_mmap_cap(struct vfio_pci_device 
*vdev,
i++;
}
 
+out:
ret = vfio_info_add_capability(caps, VFIO_REGION_INFO_CAP_SPARSE_MMAP,
   sparse);
kfree(sparse);
@@ -1115,7 +1126,8 @@ static int vfio_pci_mmap(void *device_data, struct 
vm_area_struct *vma)
if (req_start + req_len > phys_len)
return -EINVAL;
 
-   if (index == vdev->msix_bar) {
+   if (index == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
/*
 * Disallow mmaps overlapping the MSI-X table; users don't
 * get to touch this directly.  We could find somewhere
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 357243d76f10..5378f2c3ac8e 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -164,7 +164,8 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, char 
__user *buf,
} else
io = vdev->barmap[bar];
 
-   if (bar == vdev->msix_bar) {
+   if (bar == vdev->msix_bar &&
+   !(pdev->bus->bus_flags & PCI_BUS_FLAGS_MSI_REMAP)) {
x_start = vdev->msix_offset;
x_end = vdev->msix_offset + vdev->msix_size;
}
-- 
2.11.0

[PATCH kernel 1/3] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

[Alexey Kardashevskiy]

From: Yongji Xie 

We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates interrupts of all devices on the bus are
managed by the hardware enabling IRQ remapping(intel naming).
When the capability is enabled, a given PCI device can only
shoot the MSIs assigned for it. In other words, the hardware
can protect system from invalid MSIs of the device by checking
the target address and data when there is something wrong
with MSI part in device or device driver.

There is a existing flag for this capability in the IOMMU space:

enum iommu_cap {
IOMMU_CAP_CACHE_COHERENCY,
--->IOMMU_CAP_INTR_REMAP,
IOMMU_CAP_NOEXEC,
};

and Eric also posted a patchset [1] to abstract it on MSI
controller side for ARM. But it would make sense to have a
more common flag like PCI_BUS_FLAGS_MSI_REMAP so that we can
use a universal flag to test this capability on PCI side for
different archs.

With this flag enabled, we can easily know whether it's safe
to expose MSI-X tables of PCI BARs to userspace. Some usespace
drivers such as VFIO may benefit from this.

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html

Signed-off-by: Yongji Xie 
Signed-off-by: Paul Mackerras 
---
 include/linux/pci.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 8039f9f0ca05..2c6dbb3dd0da 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -200,6 +200,7 @@ enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI= (__force pci_bus_flags_t) 1,
PCI_BUS_FLAGS_NO_MMRBC  = (__force pci_bus_flags_t) 2,
PCI_BUS_FLAGS_NO_AERSID = (__force pci_bus_flags_t) 4,
+   PCI_BUS_FLAGS_MSI_REMAP = (__force pci_bus_flags_t) 8,
 };
 
 /* These values come from the PCI Express Spec */
-- 
2.11.0

[PATCH kernel 0/3] vfio-pci: Add support for mmapping MSI-X table

[Alexey Kardashevskiy]

Here is a patchset which Yongji was working on before
leaving IBM LTC. Since we still want to have this functionality
in the kernel (DPDK is the first user), here is a rebase
on the current upstream.


Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that users can write directly
to MSI-X table and generate an incorrect MSIs.

However, this will cause some performance issue when there
are some critical device registers in the same page as the
MSI-X table. We have to handle the mmio access to these
registers in QEMU emulation rather than in guest.

To solve this issue, this series allows to expose MSI-X table
to userspace when hardware enables the capability of interrupt
remapping which can ensure that a given PCI device can only
shoot the MSIs assigned for it. And we introduce a new bus_flags
PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
for different archs.

The patch 3 are based on the proposed patchset[1].

Changelog
v3:
- rebased on the current upstream

v2:
- Make the commit log more clear
- Replace pci_bus_check_msi_remapping() with pci_bus_msi_isolated()
  so that we could clearly know what the function does
- Set PCI_BUS_FLAGS_MSI_REMAP in pci_create_root_bus() instead
  of iommu_bus_notifier()
- Reserve VFIO_REGION_INFO_FLAG_CAPS when we allow to mmap MSI-X
  table so that we can know whether we allow to mmap MSI-X table
  in QEMU

[1] https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html


This is based on sha1
63f700aab4c1 Linus Torvalds "Merge tag 'xtensa-20170612' of 
git://github.com/jcmvbkbc/linux-xtensa".

Please comment. Thanks.



Yongji Xie (3):
  PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
  pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge
  vfio-pci: Allow to expose MSI-X table to userspace if interrupt
remapping is enabled

 include/linux/pci.h   |  1 +
 arch/powerpc/platforms/powernv/pci-ioda.c |  8 
 drivers/vfio/pci/vfio_pci.c   | 18 +++---
 drivers/vfio/pci/vfio_pci_rdwr.c  |  3 ++-
 4 files changed, 26 insertions(+), 4 deletions(-)

-- 
2.11.0

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

[Stephen Rothwell]

Hi Kees,

On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook  wrote:
>
> CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> so objtool needs to know about it too.
> 
> Suggested-by: Daniel Micay 
> Signed-off-by: Kees Cook 
> Cc: Josh Poimboeuf 

Tested-by: Stephen Rothwell 

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

[Stephen Rothwell]

Hi Kees,

On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook  wrote:
>
> CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> so objtool needs to know about it too.
> 
> Suggested-by: Daniel Micay 
> Signed-off-by: Kees Cook 
> Cc: Josh Poimboeuf 

Tested-by: Stephen Rothwell 

-- 
Cheers,
Stephen Rothwell

linux-next: Tree for Jun 15

[Stephen Rothwell]

Hi all,

Changes since 20170614:

The sound-asoc tree lost its build failure.

The driver-core tree lost its build failure.

The akpm (was akpm-current) tree still had its build failure for which
I reverted a commit.

Non-merge commits (relative to Linus' tree): 6467
 6462 files changed, 288178 insertions(+), 127782 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 265 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (63f700aab4c1 Merge tag 'xtensa-20170612' of 
git://github.com/jcmvbkbc/linux-xtensa)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (ff85a1a80e00 kconfig: Check for libncurses before 
menuconfig)
Merging arc-current/for-curr (45c7d002f207 ARC: defconfig: Cleanup from old 
Kconfig options)
Merging arm-current/fixes (d360a687d995 ARM: 8682/1: V7M: Set cacheid iff 
DminLine or IminLine is nonzero)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (c6ee9619e2ed powerpc/book3s64: Move 
PPC_DT_CPU_FTRs and enable it by default)
Merging sparc/master (5faab9e0f03c Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (849a44de9163 net: don't global ICMP rate limit packets 
originating from loopback)
Merging ipsec/master (138437f591dd xfrm: move xfrm_garbage_collect out of 
xfrm_policy_flush)
Merging netfilter/master (4b1f0d33db7d net: ipmr: Fix some mroute forwarding 
issues in vrf's)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (dc89481bb4c9 Merge tag 
'iwlwifi-for-kalle-2017-06-05' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (68dd02d19c81 dev_ioctl: copy only the smaller struct 
iwreq for wext)
Merging sound-current/for-linus (2deaeaf102d6 ALSA: pcm: Don't treat NULL chmap 
as a fatal error)
Merging pci-current/for-linus (98dbf5af4fdd PCI: endpoint: Select CRC32 to fix 
test build error)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (3c2993b8c614 Linux 4.12-rc4)
Merging usb.current/usb-linus (d2f48f05cd2a usb: xhci: ASMedia ASM1042A chipset 
need shorts TX quirk)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (ed6456afef0d Staging: rtl8723bs: fix an 
error code in isFileReadable())
Merging char-misc.current/char-misc-linus (32c1431eea48 Linux 4.12-rc5)
Merging input-current/for-linus (a0897d5f2c2d Input: synaptics-rmi4 - register 
F03 port as pass-through serio)
Merging crypto-current/master (d41519a69b35 crypto: Work around deallocated 
stack

linux-next: Tree for Jun 15

[Stephen Rothwell]

Hi all,

Changes since 20170614:

The sound-asoc tree lost its build failure.

The driver-core tree lost its build failure.

The akpm (was akpm-current) tree still had its build failure for which
I reverted a commit.

Non-merge commits (relative to Linus' tree): 6467
 6462 files changed, 288178 insertions(+), 127782 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 265 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (63f700aab4c1 Merge tag 'xtensa-20170612' of 
git://github.com/jcmvbkbc/linux-xtensa)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (ff85a1a80e00 kconfig: Check for libncurses before 
menuconfig)
Merging arc-current/for-curr (45c7d002f207 ARC: defconfig: Cleanup from old 
Kconfig options)
Merging arm-current/fixes (d360a687d995 ARM: 8682/1: V7M: Set cacheid iff 
DminLine or IminLine is nonzero)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (c6ee9619e2ed powerpc/book3s64: Move 
PPC_DT_CPU_FTRs and enable it by default)
Merging sparc/master (5faab9e0f03c Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (849a44de9163 net: don't global ICMP rate limit packets 
originating from loopback)
Merging ipsec/master (138437f591dd xfrm: move xfrm_garbage_collect out of 
xfrm_policy_flush)
Merging netfilter/master (4b1f0d33db7d net: ipmr: Fix some mroute forwarding 
issues in vrf's)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (dc89481bb4c9 Merge tag 
'iwlwifi-for-kalle-2017-06-05' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (68dd02d19c81 dev_ioctl: copy only the smaller struct 
iwreq for wext)
Merging sound-current/for-linus (2deaeaf102d6 ALSA: pcm: Don't treat NULL chmap 
as a fatal error)
Merging pci-current/for-linus (98dbf5af4fdd PCI: endpoint: Select CRC32 to fix 
test build error)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (3c2993b8c614 Linux 4.12-rc4)
Merging usb.current/usb-linus (d2f48f05cd2a usb: xhci: ASMedia ASM1042A chipset 
need shorts TX quirk)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (ed6456afef0d Staging: rtl8723bs: fix an 
error code in isFileReadable())
Merging char-misc.current/char-misc-linus (32c1431eea48 Linux 4.12-rc5)
Merging input-current/for-linus (a0897d5f2c2d Input: synaptics-rmi4 - register 
F03 port as pass-through serio)
Merging crypto-current/master (d41519a69b35 crypto: Work around deallocated 
stack

Re: [PATCH] USB: gtco: remove unnecessary variable assignments

[Joe Perches]

On Wed, 2017-06-14 at 20:50 -0500, Gustavo A. R. Silva wrote:
> Remove unnecessary variable assignments.
> Variable _val_ is overwritten before the value stored in it can be used.
> 
> Addresses-Coverity-ID: 1397695
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/input/tablet/gtco.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
> index b796e89..d9de13c 100644
> --- a/drivers/input/tablet/gtco.c
> +++ b/drivers/input/tablet/gtco.c
> @@ -652,8 +652,6 @@ static void gtco_urb_callback(struct urb *urbinfo)
>   switch (device->buffer[0]) {
>   case 5:
>   /* Pressure is 9 bits */
> - val = ((u16)(device->buffer[8]) << 1);
> - val |= (u16)(device->buffer[7] >> 7);
>   input_report_abs(inputdev, ABS_PRESSURE,
>device->buffer[8]);

Perhaps more likely to be

input_report_abs(inputdev, ABS_PRESSURE, val);

Re: [PATCH] USB: gtco: remove unnecessary variable assignments

[Joe Perches]

On Wed, 2017-06-14 at 20:50 -0500, Gustavo A. R. Silva wrote:
> Remove unnecessary variable assignments.
> Variable _val_ is overwritten before the value stored in it can be used.
> 
> Addresses-Coverity-ID: 1397695
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/input/tablet/gtco.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
> index b796e89..d9de13c 100644
> --- a/drivers/input/tablet/gtco.c
> +++ b/drivers/input/tablet/gtco.c
> @@ -652,8 +652,6 @@ static void gtco_urb_callback(struct urb *urbinfo)
>   switch (device->buffer[0]) {
>   case 5:
>   /* Pressure is 9 bits */
> - val = ((u16)(device->buffer[8]) << 1);
> - val |= (u16)(device->buffer[7] >> 7);
>   input_report_abs(inputdev, ABS_PRESSURE,
>device->buffer[8]);

Perhaps more likely to be

input_report_abs(inputdev, ABS_PRESSURE, val);

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

[Greg Kroah-Hartman]

On Thu, Jun 15, 2017 at 06:52:21AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> > As reported by kernelci, some functions in the VT code use significant
> > amounts of kernel stack when local variables get inlined into the caller
> > multiple times:
> > 
> > drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
> > drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is 
> > larger than 2048 bytes [-Werror=frame-larger-than=]
> > 
> > Annotating those functions as noinline_if_stackbloat prevents the inlining
> > and reduces the overall stack usage in this driver.
> > 
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/tty/vt/keyboard.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> > index f4166263bb3a..c0d111444a0e 100644
> > --- a/drivers/tty/vt/keyboard.c
> > +++ b/drivers/tty/vt/keyboard.c
> > @@ -301,13 +301,13 @@ int kbd_rate(struct kbd_repeat *rpt)
> >  /*
> >   * Helper Functions.
> >   */
> > -static void put_queue(struct vc_data *vc, int ch)
> > +static noinline_if_stackbloat void put_queue(struct vc_data *vc, int ch)
> >  {
> > tty_insert_flip_char(>port, ch, 0);
> > tty_schedule_flip(>port);
> >  }
> 
> Ugh, really?  We have to start telling gcc not to be stupid here?
> That's not going to be easy, and will just entail us doing this all over
> the place, right?
> 
> The code isn't asking to be inlined, so why is gcc allowing it to be
> done that way?  Doesn't that imply gcc is the problem here?

Wait, you are now, in this patch, _asking_ for it to be inlined.  How is
that solving anything?

greg k-h

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

[Greg Kroah-Hartman]

On Thu, Jun 15, 2017 at 06:52:21AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> > As reported by kernelci, some functions in the VT code use significant
> > amounts of kernel stack when local variables get inlined into the caller
> > multiple times:
> > 
> > drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
> > drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is 
> > larger than 2048 bytes [-Werror=frame-larger-than=]
> > 
> > Annotating those functions as noinline_if_stackbloat prevents the inlining
> > and reduces the overall stack usage in this driver.
> > 
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/tty/vt/keyboard.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> > index f4166263bb3a..c0d111444a0e 100644
> > --- a/drivers/tty/vt/keyboard.c
> > +++ b/drivers/tty/vt/keyboard.c
> > @@ -301,13 +301,13 @@ int kbd_rate(struct kbd_repeat *rpt)
> >  /*
> >   * Helper Functions.
> >   */
> > -static void put_queue(struct vc_data *vc, int ch)
> > +static noinline_if_stackbloat void put_queue(struct vc_data *vc, int ch)
> >  {
> > tty_insert_flip_char(>port, ch, 0);
> > tty_schedule_flip(>port);
> >  }
> 
> Ugh, really?  We have to start telling gcc not to be stupid here?
> That's not going to be easy, and will just entail us doing this all over
> the place, right?
> 
> The code isn't asking to be inlined, so why is gcc allowing it to be
> done that way?  Doesn't that imply gcc is the problem here?

Wait, you are now, in this patch, _asking_ for it to be inlined.  How is
that solving anything?

greg k-h

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

[Greg Kroah-Hartman]

On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> As reported by kernelci, some functions in the VT code use significant
> amounts of kernel stack when local variables get inlined into the caller
> multiple times:
> 
> drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
> drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is 
> larger than 2048 bytes [-Werror=frame-larger-than=]
> 
> Annotating those functions as noinline_if_stackbloat prevents the inlining
> and reduces the overall stack usage in this driver.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/tty/vt/keyboard.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index f4166263bb3a..c0d111444a0e 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -301,13 +301,13 @@ int kbd_rate(struct kbd_repeat *rpt)
>  /*
>   * Helper Functions.
>   */
> -static void put_queue(struct vc_data *vc, int ch)
> +static noinline_if_stackbloat void put_queue(struct vc_data *vc, int ch)
>  {
>   tty_insert_flip_char(>port, ch, 0);
>   tty_schedule_flip(>port);
>  }

Ugh, really?  We have to start telling gcc not to be stupid here?
That's not going to be easy, and will just entail us doing this all over
the place, right?

The code isn't asking to be inlined, so why is gcc allowing it to be
done that way?  Doesn't that imply gcc is the problem here?

thanks,

greg k-h

Re: [PATCH v2 03/11] tty: kbd: reduce stack size with KASAN

[Greg Kroah-Hartman]

On Wed, Jun 14, 2017 at 11:15:38PM +0200, Arnd Bergmann wrote:
> As reported by kernelci, some functions in the VT code use significant
> amounts of kernel stack when local variables get inlined into the caller
> multiple times:
> 
> drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
> drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is 
> larger than 2048 bytes [-Werror=frame-larger-than=]
> 
> Annotating those functions as noinline_if_stackbloat prevents the inlining
> and reduces the overall stack usage in this driver.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/tty/vt/keyboard.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index f4166263bb3a..c0d111444a0e 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -301,13 +301,13 @@ int kbd_rate(struct kbd_repeat *rpt)
>  /*
>   * Helper Functions.
>   */
> -static void put_queue(struct vc_data *vc, int ch)
> +static noinline_if_stackbloat void put_queue(struct vc_data *vc, int ch)
>  {
>   tty_insert_flip_char(>port, ch, 0);
>   tty_schedule_flip(>port);
>  }

Ugh, really?  We have to start telling gcc not to be stupid here?
That's not going to be easy, and will just entail us doing this all over
the place, right?

The code isn't asking to be inlined, so why is gcc allowing it to be
done that way?  Doesn't that imply gcc is the problem here?

thanks,

greg k-h

Re: [PATCH v3 1/9] ARM: dts: imx6ul-isiot: Add Sound card with codec node

[Jagan Teki]

On Thu, Jun 15, 2017 at 7:50 AM, Shawn Guo  wrote:
> On Wed, Jun 14, 2017 at 08:17:04PM +0530, Jagan Teki wrote:
>> On Fri, Apr 7, 2017 at 6:46 PM, Shawn Guo  wrote:
>> > On Thu, Apr 06, 2017 at 11:32:07PM +0530, Jagan Teki wrote:
>> >> From: Jagan Teki 
>> >>
>> >> Add support for Sound card and related codec(via i2c1) nodes
>> >> on Engicam Is.IoT MX6UL variant module boards.
>> >>
>> >> Cc: Shawn Guo 
>> >> Cc: Matteo Lisi 
>> >> Cc: Michael Trimarchi 
>> >> Signed-off-by: Jagan Teki 
>> >> ---
>> >> Changes for v3:
>> >> - Replace fsl,imx-audio-sgtl5000 and use simple-audio-card
>> >> Changes for v2:
>> >> - Use proper [label:] node-name[@unit-address] for codec
>> >> - Remove incorrect codec property 'wlf,shared-lrclk'
>> >> - Remove 'gpr' from sound card node
>> >>
>> >>  arch/arm/boot/dts/imx6ul-isiot-common.dtsi | 10 +++
>> >>  arch/arm/boot/dts/imx6ul-isiot.dtsi| 44 
>> >> ++
>> >
>> > Can you help me understand how these two files are related?  Why is
>> > sgtl5000 added into one and sound node added into the other?
>>
>> lcdif, ts and sound card which may differ based on the base-board
>> connected with SOM, So I moved these stuff which are related to
>> Starter kit supported once's and used with SOM dts files. if some
>> other board with same SOM can have different lcdif and etc so they can
>> define locally to dts.
>
> I do not follow how these stuff are organized.  So far we have the
> following isiot dts files.
>
>  - imx6ul-isiot-common.dtsi
>  - imx6ul-isiot.dtsi
>  - imx6ul-isiot-emmc.dts and imx6ul-isiot-nand.dts
>
> How are they mapping to SoM and base-board?

isiot is a modules class, with that emmc and nand are two separate
SOM's. the current support is for mounting these SOM's on Development
base board[1]. So, for isiot module class we have imx6ul-isiot.dtsi
and emmc and nand SOM's have imx6ul-isiot-emmc.dts and
imx6ul-isiot-nand.dts. There are some Carrier boards[1] which were
used with different lcdif and other changes, So
imx6ul-isiot-common.dtsi have changes common across emmc and nand,
instead of adding them into individual dts files I moved in
-common.dtsi.  So in future if isiot SOM mounted on carrier board
which should have a separate dts and which may or may not use
imx6ul-isiot-common.dtsi

[1] https://www.engicam.com/vis-prod/101142
[2] https://www.engicam.com/vis-prod/101128

thanks!
-- 
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

Re: [PATCH v3 1/9] ARM: dts: imx6ul-isiot: Add Sound card with codec node

[Jagan Teki]

On Thu, Jun 15, 2017 at 7:50 AM, Shawn Guo  wrote:
> On Wed, Jun 14, 2017 at 08:17:04PM +0530, Jagan Teki wrote:
>> On Fri, Apr 7, 2017 at 6:46 PM, Shawn Guo  wrote:
>> > On Thu, Apr 06, 2017 at 11:32:07PM +0530, Jagan Teki wrote:
>> >> From: Jagan Teki 
>> >>
>> >> Add support for Sound card and related codec(via i2c1) nodes
>> >> on Engicam Is.IoT MX6UL variant module boards.
>> >>
>> >> Cc: Shawn Guo 
>> >> Cc: Matteo Lisi 
>> >> Cc: Michael Trimarchi 
>> >> Signed-off-by: Jagan Teki 
>> >> ---
>> >> Changes for v3:
>> >> - Replace fsl,imx-audio-sgtl5000 and use simple-audio-card
>> >> Changes for v2:
>> >> - Use proper [label:] node-name[@unit-address] for codec
>> >> - Remove incorrect codec property 'wlf,shared-lrclk'
>> >> - Remove 'gpr' from sound card node
>> >>
>> >>  arch/arm/boot/dts/imx6ul-isiot-common.dtsi | 10 +++
>> >>  arch/arm/boot/dts/imx6ul-isiot.dtsi| 44 
>> >> ++
>> >
>> > Can you help me understand how these two files are related?  Why is
>> > sgtl5000 added into one and sound node added into the other?
>>
>> lcdif, ts and sound card which may differ based on the base-board
>> connected with SOM, So I moved these stuff which are related to
>> Starter kit supported once's and used with SOM dts files. if some
>> other board with same SOM can have different lcdif and etc so they can
>> define locally to dts.
>
> I do not follow how these stuff are organized.  So far we have the
> following isiot dts files.
>
>  - imx6ul-isiot-common.dtsi
>  - imx6ul-isiot.dtsi
>  - imx6ul-isiot-emmc.dts and imx6ul-isiot-nand.dts
>
> How are they mapping to SoM and base-board?

isiot is a modules class, with that emmc and nand are two separate
SOM's. the current support is for mounting these SOM's on Development
base board[1]. So, for isiot module class we have imx6ul-isiot.dtsi
and emmc and nand SOM's have imx6ul-isiot-emmc.dts and
imx6ul-isiot-nand.dts. There are some Carrier boards[1] which were
used with different lcdif and other changes, So
imx6ul-isiot-common.dtsi have changes common across emmc and nand,
instead of adding them into individual dts files I moved in
-common.dtsi.  So in future if isiot SOM mounted on carrier board
which should have a separate dts and which may or may not use
imx6ul-isiot-common.dtsi

[1] https://www.engicam.com/vis-prod/101142
[2] https://www.engicam.com/vis-prod/101128

thanks!
-- 
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[PATCH v2] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

[Arvind Yadav]

clk_prepare_enable() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 

Changes in v2:
  Remove useless initialization of retval.
---
 drivers/usb/host/ohci-pxa27x.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 79efde8f..21c010f 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -274,14 +274,16 @@ static inline void pxa27x_reset_hc(struct pxa27x_ohci 
*pxa_ohci)
 
 static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci, struct device *dev)
 {
-   int retval = 0;
+   int retval;
struct pxaohci_platform_data *inf;
uint32_t uhchr;
struct usb_hcd *hcd = dev_get_drvdata(dev);
 
inf = dev_get_platdata(dev);
 
-   clk_prepare_enable(pxa_ohci->clk);
+   retval = clk_prepare_enable(pxa_ohci->clk);
+   if (retval)
+   return retval;
 
pxa27x_reset_hc(pxa_ohci);
 
@@ -296,8 +298,10 @@ static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci, 
struct device *dev)
if (inf->init)
retval = inf->init(dev);
 
-   if (retval < 0)
+   if (retval < 0) {
+   clk_disable_unprepare(pxa_ohci->clk);
return retval;
+   }
 
if (cpu_is_pxa3xx())
pxa3xx_u2d_start_hc(>self);
-- 
1.9.1

[PATCH v2] usb: host: ohci-pxa27x: Handle return value of clk_prepare_enable

[Arvind Yadav]

clk_prepare_enable() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 

Changes in v2:
  Remove useless initialization of retval.
---
 drivers/usb/host/ohci-pxa27x.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 79efde8f..21c010f 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -274,14 +274,16 @@ static inline void pxa27x_reset_hc(struct pxa27x_ohci 
*pxa_ohci)
 
 static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci, struct device *dev)
 {
-   int retval = 0;
+   int retval;
struct pxaohci_platform_data *inf;
uint32_t uhchr;
struct usb_hcd *hcd = dev_get_drvdata(dev);
 
inf = dev_get_platdata(dev);
 
-   clk_prepare_enable(pxa_ohci->clk);
+   retval = clk_prepare_enable(pxa_ohci->clk);
+   if (retval)
+   return retval;
 
pxa27x_reset_hc(pxa_ohci);
 
@@ -296,8 +298,10 @@ static int pxa27x_start_hc(struct pxa27x_ohci *pxa_ohci, 
struct device *dev)
if (inf->init)
retval = inf->init(dev);
 
-   if (retval < 0)
+   if (retval < 0) {
+   clk_disable_unprepare(pxa_ohci->clk);
return retval;
+   }
 
if (cpu_is_pxa3xx())
pxa3xx_u2d_start_hc(>self);
-- 
1.9.1

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

[Daniel Micay]

> So after that the errors (x86_64 allmodconfig build) are only:
> 
> In file included from include/linux/bitmap.h:8:0,
>  from include/linux/cpumask.h:11,
>  from arch/x86/include/asm/cpumask.h:4,
>  from arch/x86/include/asm/msr.h:10,
>  from arch/x86/include/asm/processor.h:20,
>  from arch/x86/include/asm/cpufeature.h:4,
>  from arch/x86/include/asm/thread_info.h:52,
>  from include/linux/thread_info.h:37,
>  from arch/x86/include/asm/preempt.h:6,
>  from include/linux/preempt.h:80,
>  from include/linux/spinlock.h:50,
>  from include/linux/mmzone.h:7,
>  from include/linux/gfp.h:5,
>  from arch/x86/power/hibernate_64.c:11:
> In function 'memcpy',
> inlined from 'relocate_restore_code' at
> arch/x86/power/hibernate_64.c:150:2,
> inlined from 'swsusp_arch_resume' at
> arch/x86/power/hibernate_64.c:186:8:
> include/linux/string.h:309:4: error: call to '__read_overflow2'
> declared with attribute error: detected read beyond size of object
> passed as 2nd parameter
> __read_overflow2();
> ^
> In file included from include/linux/bitmap.h:8:0,
>  from include/linux/cpumask.h:11,
>  from arch/x86/include/asm/cpumask.h:4,
>  from arch/x86/include/asm/msr.h:10,
>  from arch/x86/include/asm/processor.h:20,
>  from arch/x86/include/asm/cpufeature.h:4,
>  from arch/x86/include/asm/thread_info.h:52,
>  from include/linux/thread_info.h:37,
>  from arch/x86/include/asm/preempt.h:6,
>  from include/linux/preempt.h:80,
>  from include/linux/spinlock.h:50,
>  from include/linux/mmzone.h:7,
>  from include/linux/gfp.h:5,
>  from include/linux/mm.h:9,
>  from kernel/kexec_file.c:15:
> In function 'memcmp',
> inlined from 'kexec_load_purgatory' at kernel/kexec_file.c:900:6:
> include/linux/string.h:348:4: error: call to '__read_overflow'
> declared with attribute error: detected read beyond size of object
> passed as 1st parameter
> __read_overflow();
> ^
> 

Kees has the remaining ones here now:

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=for-next/kspp

Not entirely sure what happened to the powerpc bits though.

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

[Daniel Micay]

> So after that the errors (x86_64 allmodconfig build) are only:
> 
> In file included from include/linux/bitmap.h:8:0,
>  from include/linux/cpumask.h:11,
>  from arch/x86/include/asm/cpumask.h:4,
>  from arch/x86/include/asm/msr.h:10,
>  from arch/x86/include/asm/processor.h:20,
>  from arch/x86/include/asm/cpufeature.h:4,
>  from arch/x86/include/asm/thread_info.h:52,
>  from include/linux/thread_info.h:37,
>  from arch/x86/include/asm/preempt.h:6,
>  from include/linux/preempt.h:80,
>  from include/linux/spinlock.h:50,
>  from include/linux/mmzone.h:7,
>  from include/linux/gfp.h:5,
>  from arch/x86/power/hibernate_64.c:11:
> In function 'memcpy',
> inlined from 'relocate_restore_code' at
> arch/x86/power/hibernate_64.c:150:2,
> inlined from 'swsusp_arch_resume' at
> arch/x86/power/hibernate_64.c:186:8:
> include/linux/string.h:309:4: error: call to '__read_overflow2'
> declared with attribute error: detected read beyond size of object
> passed as 2nd parameter
> __read_overflow2();
> ^
> In file included from include/linux/bitmap.h:8:0,
>  from include/linux/cpumask.h:11,
>  from arch/x86/include/asm/cpumask.h:4,
>  from arch/x86/include/asm/msr.h:10,
>  from arch/x86/include/asm/processor.h:20,
>  from arch/x86/include/asm/cpufeature.h:4,
>  from arch/x86/include/asm/thread_info.h:52,
>  from include/linux/thread_info.h:37,
>  from arch/x86/include/asm/preempt.h:6,
>  from include/linux/preempt.h:80,
>  from include/linux/spinlock.h:50,
>  from include/linux/mmzone.h:7,
>  from include/linux/gfp.h:5,
>  from include/linux/mm.h:9,
>  from kernel/kexec_file.c:15:
> In function 'memcmp',
> inlined from 'kexec_load_purgatory' at kernel/kexec_file.c:900:6:
> include/linux/string.h:348:4: error: call to '__read_overflow'
> declared with attribute error: detected read beyond size of object
> passed as 1st parameter
> __read_overflow();
> ^
> 

Kees has the remaining ones here now:

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=for-next/kspp

Not entirely sure what happened to the powerpc bits though.

Re: [PATCH 1/3] x86/mm: Provide pmdp_mknotpresent() helper

[kbuild test robot]

Hi Kirill,

[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.12-rc5 next-20170614]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kirill-A-Shutemov/Do-not-loose-dirty-bit-on-THP-pages/20170615-115540
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: i386-randconfig-x071-06130444 (attached as .config)
compiler: gcc-6 (Debian 6.3.0-18) 6.3.0 20170516
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

   In file included from include/linux/mm.h:70:0,
from include/linux/memcontrol.h:29,
from include/linux/swap.h:8,
from include/linux/suspend.h:4,
from arch/x86/kernel/asm-offsets.c:12:
>> arch/x86/include/asm/pgtable.h:1096:27: error: redefinition of 
>> 'pmdp_mknotpresent'
#define pmdp_mknotpresent pmdp_mknotpresent
  ^
>> arch/x86/include/asm/pgtable.h:1097:20: note: in expansion of macro 
>> 'pmdp_mknotpresent'
static inline void pmdp_mknotpresent(pmd_t *pmdp)
   ^
   In file included from arch/x86/include/asm/pgtable_32.h:43:0,
from arch/x86/include/asm/pgtable.h:604,
from include/linux/mm.h:70,
from include/linux/memcontrol.h:29,
from include/linux/swap.h:8,
from include/linux/suspend.h:4,
from arch/x86/kernel/asm-offsets.c:12:
   arch/x86/include/asm/pgtable-3level.h:194:20: note: previous definition of 
'pmdp_mknotpresent' was here
static inline void pmdp_mknotpresent(pmd_t *pmdp)
   ^
   make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +/pmdp_mknotpresent +1096 arch/x86/include/asm/pgtable.h

  1090unsigned long addr, pmd_t *pmdp)
  1091  {
  1092  clear_bit(_PAGE_BIT_RW, (unsigned long *)pmdp);
  1093  }
  1094  
  1095  #ifndef pmdp_mknotpresent
> 1096  #define pmdp_mknotpresent pmdp_mknotpresent
> 1097  static inline void pmdp_mknotpresent(pmd_t *pmdp)
  1098  {
  1099  pmd_t old, new;
  1100  

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


.config.gz
Description: application/gzip

Re: [PATCH 1/3] x86/mm: Provide pmdp_mknotpresent() helper

[kbuild test robot]

Hi Kirill,

[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.12-rc5 next-20170614]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Kirill-A-Shutemov/Do-not-loose-dirty-bit-on-THP-pages/20170615-115540
base:   git://git.cmpxchg.org/linux-mmotm.git master
config: i386-randconfig-x071-06130444 (attached as .config)
compiler: gcc-6 (Debian 6.3.0-18) 6.3.0 20170516
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

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

   In file included from include/linux/mm.h:70:0,
from include/linux/memcontrol.h:29,
from include/linux/swap.h:8,
from include/linux/suspend.h:4,
from arch/x86/kernel/asm-offsets.c:12:
>> arch/x86/include/asm/pgtable.h:1096:27: error: redefinition of 
>> 'pmdp_mknotpresent'
#define pmdp_mknotpresent pmdp_mknotpresent
  ^
>> arch/x86/include/asm/pgtable.h:1097:20: note: in expansion of macro 
>> 'pmdp_mknotpresent'
static inline void pmdp_mknotpresent(pmd_t *pmdp)
   ^
   In file included from arch/x86/include/asm/pgtable_32.h:43:0,
from arch/x86/include/asm/pgtable.h:604,
from include/linux/mm.h:70,
from include/linux/memcontrol.h:29,
from include/linux/swap.h:8,
from include/linux/suspend.h:4,
from arch/x86/kernel/asm-offsets.c:12:
   arch/x86/include/asm/pgtable-3level.h:194:20: note: previous definition of 
'pmdp_mknotpresent' was here
static inline void pmdp_mknotpresent(pmd_t *pmdp)
   ^
   make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +/pmdp_mknotpresent +1096 arch/x86/include/asm/pgtable.h

  1090unsigned long addr, pmd_t *pmdp)
  1091  {
  1092  clear_bit(_PAGE_BIT_RW, (unsigned long *)pmdp);
  1093  }
  1094  
  1095  #ifndef pmdp_mknotpresent
> 1096  #define pmdp_mknotpresent pmdp_mknotpresent
> 1097  static inline void pmdp_mknotpresent(pmd_t *pmdp)
  1098  {
  1099  pmd_t old, new;
  1100  

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


.config.gz
Description: application/gzip

Re: [HMM-CDM 2/5] mm/hmm: add new helper to hotplug CDM memory region

[Balbir Singh]

On Wed, 14 Jun 2017 16:11:41 -0400
Jérôme Glisse  wrote:

> Unlike unaddressable memory, coherent device memory has a real
> resource associated with it on the system (as CPU can address
> it). Add a new helper to hotplug such memory within the HMM
> framework.
> 
> Signed-off-by: Jérôme Glisse 
> ---

Looks good to me

Reviewed-by: Balbir Singh 

Re: [HMM-CDM 2/5] mm/hmm: add new helper to hotplug CDM memory region

[Balbir Singh]

On Wed, 14 Jun 2017 16:11:41 -0400
Jérôme Glisse  wrote:

> Unlike unaddressable memory, coherent device memory has a real
> resource associated with it on the system (as CPU can address
> it). Add a new helper to hotplug such memory within the HMM
> framework.
> 
> Signed-off-by: Jérôme Glisse 
> ---

Looks good to me

Reviewed-by: Balbir Singh 

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

[Stephen Rothwell]

Hi all,

On Thu, 15 Jun 2017 14:05:22 +1000 Stephen Rothwell  
wrote:
>
> On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook  wrote:
> >
> > CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> > so objtool needs to know about it too.
> > 
> > Suggested-by: Daniel Micay 
> > Signed-off-by: Kees Cook 
> > Cc: Josh Poimboeuf 
> > ---
> >  tools/objtool/builtin-check.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
> > index 282a60368b14..5f66697fe1e0 100644
> > --- a/tools/objtool/builtin-check.c
> > +++ b/tools/objtool/builtin-check.c
> > @@ -192,7 +192,8 @@ static int __dead_end_function(struct objtool_file 
> > *file, struct symbol *func,
> > "complete_and_exit",
> > "kvm_spurious_fault",
> > "__reiserfs_panic",
> > -   "lbug_with_loc"
> > +   "lbug_with_loc",
> > +   "fortify_panic",
> > };
> >  
> > if (func->bind == STB_WEAK)
> > -- 
> > 2.7.4  
> 
> OK, I have added this to the end of linux-next today (in the part of
> Andrew's tree afte the linux-next merge).  I also move the fortify
> string patch to after it (but I assume I will still need to revert it).

So after that the errors (x86_64 allmodconfig build) are only:

In file included from include/linux/bitmap.h:8:0,
 from include/linux/cpumask.h:11,
 from arch/x86/include/asm/cpumask.h:4,
 from arch/x86/include/asm/msr.h:10,
 from arch/x86/include/asm/processor.h:20,
 from arch/x86/include/asm/cpufeature.h:4,
 from arch/x86/include/asm/thread_info.h:52,
 from include/linux/thread_info.h:37,
 from arch/x86/include/asm/preempt.h:6,
 from include/linux/preempt.h:80,
 from include/linux/spinlock.h:50,
 from include/linux/mmzone.h:7,
 from include/linux/gfp.h:5,
 from arch/x86/power/hibernate_64.c:11:
In function 'memcpy',
inlined from 'relocate_restore_code' at arch/x86/power/hibernate_64.c:150:2,
inlined from 'swsusp_arch_resume' at arch/x86/power/hibernate_64.c:186:8:
include/linux/string.h:309:4: error: call to '__read_overflow2' declared with 
attribute error: detected read beyond size of object passed as 2nd parameter
__read_overflow2();
^
In file included from include/linux/bitmap.h:8:0,
 from include/linux/cpumask.h:11,
 from arch/x86/include/asm/cpumask.h:4,
 from arch/x86/include/asm/msr.h:10,
 from arch/x86/include/asm/processor.h:20,
 from arch/x86/include/asm/cpufeature.h:4,
 from arch/x86/include/asm/thread_info.h:52,
 from include/linux/thread_info.h:37,
 from arch/x86/include/asm/preempt.h:6,
 from include/linux/preempt.h:80,
 from include/linux/spinlock.h:50,
 from include/linux/mmzone.h:7,
 from include/linux/gfp.h:5,
 from include/linux/mm.h:9,
 from kernel/kexec_file.c:15:
In function 'memcmp',
inlined from 'kexec_load_purgatory' at kernel/kexec_file.c:900:6:
include/linux/string.h:348:4: error: call to '__read_overflow' declared with 
attribute error: detected read beyond size of object passed as 1st parameter
__read_overflow();
^

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

[Stephen Rothwell]

Hi all,

On Thu, 15 Jun 2017 14:05:22 +1000 Stephen Rothwell  
wrote:
>
> On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook  wrote:
> >
> > CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> > so objtool needs to know about it too.
> > 
> > Suggested-by: Daniel Micay 
> > Signed-off-by: Kees Cook 
> > Cc: Josh Poimboeuf 
> > ---
> >  tools/objtool/builtin-check.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
> > index 282a60368b14..5f66697fe1e0 100644
> > --- a/tools/objtool/builtin-check.c
> > +++ b/tools/objtool/builtin-check.c
> > @@ -192,7 +192,8 @@ static int __dead_end_function(struct objtool_file 
> > *file, struct symbol *func,
> > "complete_and_exit",
> > "kvm_spurious_fault",
> > "__reiserfs_panic",
> > -   "lbug_with_loc"
> > +   "lbug_with_loc",
> > +   "fortify_panic",
> > };
> >  
> > if (func->bind == STB_WEAK)
> > -- 
> > 2.7.4  
> 
> OK, I have added this to the end of linux-next today (in the part of
> Andrew's tree afte the linux-next merge).  I also move the fortify
> string patch to after it (but I assume I will still need to revert it).

So after that the errors (x86_64 allmodconfig build) are only:

In file included from include/linux/bitmap.h:8:0,
 from include/linux/cpumask.h:11,
 from arch/x86/include/asm/cpumask.h:4,
 from arch/x86/include/asm/msr.h:10,
 from arch/x86/include/asm/processor.h:20,
 from arch/x86/include/asm/cpufeature.h:4,
 from arch/x86/include/asm/thread_info.h:52,
 from include/linux/thread_info.h:37,
 from arch/x86/include/asm/preempt.h:6,
 from include/linux/preempt.h:80,
 from include/linux/spinlock.h:50,
 from include/linux/mmzone.h:7,
 from include/linux/gfp.h:5,
 from arch/x86/power/hibernate_64.c:11:
In function 'memcpy',
inlined from 'relocate_restore_code' at arch/x86/power/hibernate_64.c:150:2,
inlined from 'swsusp_arch_resume' at arch/x86/power/hibernate_64.c:186:8:
include/linux/string.h:309:4: error: call to '__read_overflow2' declared with 
attribute error: detected read beyond size of object passed as 2nd parameter
__read_overflow2();
^
In file included from include/linux/bitmap.h:8:0,
 from include/linux/cpumask.h:11,
 from arch/x86/include/asm/cpumask.h:4,
 from arch/x86/include/asm/msr.h:10,
 from arch/x86/include/asm/processor.h:20,
 from arch/x86/include/asm/cpufeature.h:4,
 from arch/x86/include/asm/thread_info.h:52,
 from include/linux/thread_info.h:37,
 from arch/x86/include/asm/preempt.h:6,
 from include/linux/preempt.h:80,
 from include/linux/spinlock.h:50,
 from include/linux/mmzone.h:7,
 from include/linux/gfp.h:5,
 from include/linux/mm.h:9,
 from kernel/kexec_file.c:15:
In function 'memcmp',
inlined from 'kexec_load_purgatory' at kernel/kexec_file.c:900:6:
include/linux/string.h:348:4: error: call to '__read_overflow' declared with 
attribute error: detected read beyond size of object passed as 1st parameter
__read_overflow();
^

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] sm501fb: Silence a coccinelle script warning.

[Christophe JAILLET]

Le 14/06/2017 à 12:54, Bartlomiej Zolnierkiewicz a écrit :

Hi,

On Monday, May 08, 2017 08:11:16 AM Christophe JAILLET wrote:

According to surrounding goto, it is likely that 'goto err_probed_panel' is
expected here.
This change is just done in order to silence some coccinelle scripts
which try to detect wrongly ordered goto.

If 'info->fb[HEAD_PANEL]' and' 'info->fb[HEAD_CRT]' are both NULL, this
means that no 'framebuffer_alloc' has been performed, so 'goto err_alloc'
looks fine.
Anyway, it is also harmless in this case to call 'framebuffer_release'.
The code looks more straight forward.

Signed-off-by: Christophe JAILLET 

It seems that the code for supporting only selected framebuffers
(only HEAD_PANEL fb or only HEAD_CRT fb) is broken anyway as at least
the suspend/resume support assumes that both framebuffers are always
present. Also all sm501fb driver users always try try to initialize
both framebuffers. Therefore I would prefer the removal of non-working
individual framebuffers support (the code that your patch modifies
would be removed as well). Could you please look into it?

Thx for the feedback, but no, I won't be able to go further.
I don't know the code enough in this area.
Sorry.

Best regards,
CJ

Re: [PATCH] sm501fb: Silence a coccinelle script warning.

[Christophe JAILLET]

Le 14/06/2017 à 12:54, Bartlomiej Zolnierkiewicz a écrit :

Hi,

On Monday, May 08, 2017 08:11:16 AM Christophe JAILLET wrote:

According to surrounding goto, it is likely that 'goto err_probed_panel' is
expected here.
This change is just done in order to silence some coccinelle scripts
which try to detect wrongly ordered goto.

If 'info->fb[HEAD_PANEL]' and' 'info->fb[HEAD_CRT]' are both NULL, this
means that no 'framebuffer_alloc' has been performed, so 'goto err_alloc'
looks fine.
Anyway, it is also harmless in this case to call 'framebuffer_release'.
The code looks more straight forward.

Signed-off-by: Christophe JAILLET 

It seems that the code for supporting only selected framebuffers
(only HEAD_PANEL fb or only HEAD_CRT fb) is broken anyway as at least
the suspend/resume support assumes that both framebuffers are always
present. Also all sm501fb driver users always try try to initialize
both framebuffers. Therefore I would prefer the removal of non-working
individual framebuffers support (the code that your patch modifies
would be removed as well). Could you please look into it?

Thx for the feedback, but no, I won't be able to go further.
I don't know the code enough in this area.
Sorry.

Best regards,
CJ

Re: [PATCH v2] mfd: Add driver for RAVE Supervisory Processor

[Chris Healy]

On Mon, Jun 12, 2017 at 6:23 PM, Andrey Smirnov
 wrote:
> Add a driver for RAVE Supervisory Processor, an MCU implementing
> varoius bits of housekeeping functionality (watchdoging, backlight
> control, LED control, etc) on RAVE family of products by Zodiac
> Inflight Innovations.
>
> This driver implementes core MFD/serdev device as well as
> communication subroutines necessary for commanding the device.
>
> Cc: cphe...@gmail.com
> Cc: Lucas Stach 
> Cc: Nikita Yushchenko 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
>
> Changes since [v1]:
>
>  - Fix MODULE_LICENSE to specify "GPL v2"
>
>  - Fix a bug in rave_sp_get_status()
>
>  - Use %zu to fix warning repored by kbuild test robot
>
>  - Remove "status" properties from examples zii,rave-sp.txt as well as
>clarify the fact that device node is expected to be a child of a
>serial device node
>
> NOTE:
>
>  * The driver for "zii,rave-sp-watchdog" exists, but I haven't
>submitted it yet, becuase I wanted to make sure that API exposed by
>this MFD is acceptable and doesn't need drastic changes
>
>  * This driver is dependent on crc_ccitt_false() introduced in
>2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next'
>
>
> [v1] lkml.kernel.org/r/20170606180643.14258-1-andrew.smir...@gmail.com
>
>
>  .../devicetree/bindings/mfd/zii,rave-sp.txt|   36 +
>  drivers/mfd/Kconfig|9 +
>  drivers/mfd/Makefile   |1 +
>  drivers/mfd/rave-sp.c  | 1009 
> 
>  include/linux/rave-sp.h|   54 ++
>  5 files changed, 1109 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
>  create mode 100644 drivers/mfd/rave-sp.c
>  create mode 100644 include/linux/rave-sp.h
>

This patch was tested on Zodiac RDU1 and RDU2 platforms.

Tested-by: Chris Healy 

Re: [PATCH v2] mfd: Add driver for RAVE Supervisory Processor

[Chris Healy]

On Mon, Jun 12, 2017 at 6:23 PM, Andrey Smirnov
 wrote:
> Add a driver for RAVE Supervisory Processor, an MCU implementing
> varoius bits of housekeeping functionality (watchdoging, backlight
> control, LED control, etc) on RAVE family of products by Zodiac
> Inflight Innovations.
>
> This driver implementes core MFD/serdev device as well as
> communication subroutines necessary for commanding the device.
>
> Cc: cphe...@gmail.com
> Cc: Lucas Stach 
> Cc: Nikita Yushchenko 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
>
> Changes since [v1]:
>
>  - Fix MODULE_LICENSE to specify "GPL v2"
>
>  - Fix a bug in rave_sp_get_status()
>
>  - Use %zu to fix warning repored by kbuild test robot
>
>  - Remove "status" properties from examples zii,rave-sp.txt as well as
>clarify the fact that device node is expected to be a child of a
>serial device node
>
> NOTE:
>
>  * The driver for "zii,rave-sp-watchdog" exists, but I haven't
>submitted it yet, becuase I wanted to make sure that API exposed by
>this MFD is acceptable and doesn't need drastic changes
>
>  * This driver is dependent on crc_ccitt_false() introduced in
>2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next'
>
>
> [v1] lkml.kernel.org/r/20170606180643.14258-1-andrew.smir...@gmail.com
>
>
>  .../devicetree/bindings/mfd/zii,rave-sp.txt|   36 +
>  drivers/mfd/Kconfig|9 +
>  drivers/mfd/Makefile   |1 +
>  drivers/mfd/rave-sp.c  | 1009 
> 
>  include/linux/rave-sp.h|   54 ++
>  5 files changed, 1109 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
>  create mode 100644 drivers/mfd/rave-sp.c
>  create mode 100644 include/linux/rave-sp.h
>

This patch was tested on Zodiac RDU1 and RDU2 platforms.

Tested-by: Chris Healy 

[GIT] Networking

[David Miller]

1) The netlink attribute passed in to dev_set_alias() is not
   necessarily NULL terminated, don't use strlcpy() on it.
   From Alexander Potapenko.

2) Fix implementation of atomics in arm64 bpf JIT, from Daniel
   Borkmann.

3) Correct the release of netdevs and driver private data in
   certain circumstances.

4) Sanitize netlink message length properly in decnet, from
   Mateusz Jurczyk.

5) Don't leak kernel data in rtnl_fill_vfinfo() netlink blobs.
   From Yuval Mintz.

6) Hash secret is never initialized in ipv6 ILA translation code, from
   Arnd Bergmann.  I guess those clang warnings about unused inline
   functions are useful for something!

7) Fix endian selection in bpf_endian.h, from Daniel Borkmann.

8) Sanitize sockaddr length before dereferncing any fields in
   AF_UNIX and CAIF.  From Mateusz Jurczyk.

9) Fix timestamping for GMAC3 chips in stmmac driver, from Mario
   Molitor.

10) Do not leak netdev on dev_alloc_name() errors in mac80211, from
Johannes Berg.

11) Fix locking in sctp_for_each_endpoint(), from Xin Long.

12) Fix wrong memset size on 32-bit in snmp6, from Christian Perle.

13) Fix use after free in ip_mc_clear_src(), from WANG Cong.

14) Fix regressions caused by ICMP rate limiting changes in 4.11,
from Jesper Dangaard Brouer.

Please pull, thanks a lot!

The following changes since commit b29794ec95c6856b316c2295904208bf11ffddd9:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-06-06 
14:30:17 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 640f93cc6ea7327588be3cc0849d1342aac0393a:

  i40e: Fix a sleep-in-atomic bug (2017-06-14 23:45:22 -0400)


Alexander Potapenko (1):
  net: don't call strlen on non-terminated string in dev_set_alias()

Andreas Pape (1):
  batman-adv: fix memory leak when dropping packet from other gateway

Antoine Tenart (1):
  net: mvpp2: do not bypass the mvpp22_port_mii_set function

Arnd Bergmann (1):
  ila_xlat: add missing hash secret initialization

Ashwanth Goli (1):
  net: rps: fix uninitialized symbol warning

Avraham Stern (1):
  mac80211: Fix incorrect condition when checking rx timestamp

Bjørn Mork (1):
  qmi_wwan: new Telewell and Sierra device IDs

Christian Lamparter (2):
  net: emac: fix reset timeout with AR8035 phy
  net: emac: fix and unify emac_mdio functions

Christian Perle (1):
  proc: snmp6: Use correct type in memset

Dan Carpenter (1):
  net/act_pedit: fix an error code

Daniel Borkmann (2):
  bpf, arm64: use separate register for state in stxr
  bpf, tests: fix endianness selection

David Ahern (2):
  net: ipv6: Release route when device is unregistering
  net: vrf: Make add_fib_rules per network namespace flag

David S. Miller (13):
  net: Fix inconsistent teardown and release of private netdev state.
  hsi: Fix build regression due to netdev destructor fix.
  Revert "decnet: dn_rtmsg: Improve input length sanitization in 
dnrmg_receive_user_skb"
  Merge branch 'netvsc-bug-fixes'
  net: Fix build regression in rtl8723bs staging driver.
  Merge tag 'linux-can-fixes-for-4.12-20170609' of 
git://git.kernel.org/.../mkl/linux-can
  Merge branch 'bnx2x-Fix-malicious-VFs-indication'
  Revert "net: fec: Add a fec_enet_clear_ethtool_stats() stub for 
CONFIG_M5272"
  Merge branch 'mvpp2-fixes'
  Merge branch 'ena-fixes'
  Merge tag 'mlx5-fixes-2017-06-11' of git://git.kernel.org/.../saeed/linux
  Merge tag 'mac80211-for-davem-2017-06-13' of 
git://git.kernel.org/.../jberg/mac80211
  Merge tag 'batadv-net-for-davem-20170613' of 
git://git.open-mesh.org/linux-merge

Dominik Heidler (1):
  l2tp: cast l2tp traffic counter to unsigned

Donald Sharp (1):
  net: ipmr: Fix some mroute forwarding issues in vrf's

Emmanuel Grumbach (2):
  mac80211: don't look at the PM bit of BAR frames
  mac80211: don't send SMPS action frame in AP mode when not needed

Fabio Estevam (1):
  net: fec: Add a fec_enet_clear_ethtool_stats() stub for CONFIG_M5272

Florian Fainelli (1):
  net: phy: Fix MDIO_THUNDER dependencies

Huy Nguyen (1):
  net/mlx5: Remove several module events out of ethtool stats

Jacob Keller (1):
  i40e: fix handling of HW ATR eviction

Jason A. Donenfeld (1):
  mac80211/wpa: use constant time memory comparison for MACs

Jesper Dangaard Brouer (1):
  net: don't global ICMP rate limit packets originating from loopback

Jia-Ju Bai (3):
  net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx
  net: tipc: Fix a sleep-in-atomic bug in tipc_msg_reverse
  i40e: Fix a sleep-in-atomic bug

Joe Perches (2):
  net: phy: add missing SPEED_14000
  netconsole: Remove duplicate "netconsole: " logging prefix

Johan Hovold (1):
  can: peak_usb: fix product-id endianness in error message

[GIT] Networking

[David Miller]

1) The netlink attribute passed in to dev_set_alias() is not
   necessarily NULL terminated, don't use strlcpy() on it.
   From Alexander Potapenko.

2) Fix implementation of atomics in arm64 bpf JIT, from Daniel
   Borkmann.

3) Correct the release of netdevs and driver private data in
   certain circumstances.

4) Sanitize netlink message length properly in decnet, from
   Mateusz Jurczyk.

5) Don't leak kernel data in rtnl_fill_vfinfo() netlink blobs.
   From Yuval Mintz.

6) Hash secret is never initialized in ipv6 ILA translation code, from
   Arnd Bergmann.  I guess those clang warnings about unused inline
   functions are useful for something!

7) Fix endian selection in bpf_endian.h, from Daniel Borkmann.

8) Sanitize sockaddr length before dereferncing any fields in
   AF_UNIX and CAIF.  From Mateusz Jurczyk.

9) Fix timestamping for GMAC3 chips in stmmac driver, from Mario
   Molitor.

10) Do not leak netdev on dev_alloc_name() errors in mac80211, from
Johannes Berg.

11) Fix locking in sctp_for_each_endpoint(), from Xin Long.

12) Fix wrong memset size on 32-bit in snmp6, from Christian Perle.

13) Fix use after free in ip_mc_clear_src(), from WANG Cong.

14) Fix regressions caused by ICMP rate limiting changes in 4.11,
from Jesper Dangaard Brouer.

Please pull, thanks a lot!

The following changes since commit b29794ec95c6856b316c2295904208bf11ffddd9:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-06-06 
14:30:17 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to 640f93cc6ea7327588be3cc0849d1342aac0393a:

  i40e: Fix a sleep-in-atomic bug (2017-06-14 23:45:22 -0400)


Alexander Potapenko (1):
  net: don't call strlen on non-terminated string in dev_set_alias()

Andreas Pape (1):
  batman-adv: fix memory leak when dropping packet from other gateway

Antoine Tenart (1):
  net: mvpp2: do not bypass the mvpp22_port_mii_set function

Arnd Bergmann (1):
  ila_xlat: add missing hash secret initialization

Ashwanth Goli (1):
  net: rps: fix uninitialized symbol warning

Avraham Stern (1):
  mac80211: Fix incorrect condition when checking rx timestamp

Bjørn Mork (1):
  qmi_wwan: new Telewell and Sierra device IDs

Christian Lamparter (2):
  net: emac: fix reset timeout with AR8035 phy
  net: emac: fix and unify emac_mdio functions

Christian Perle (1):
  proc: snmp6: Use correct type in memset

Dan Carpenter (1):
  net/act_pedit: fix an error code

Daniel Borkmann (2):
  bpf, arm64: use separate register for state in stxr
  bpf, tests: fix endianness selection

David Ahern (2):
  net: ipv6: Release route when device is unregistering
  net: vrf: Make add_fib_rules per network namespace flag

David S. Miller (13):
  net: Fix inconsistent teardown and release of private netdev state.
  hsi: Fix build regression due to netdev destructor fix.
  Revert "decnet: dn_rtmsg: Improve input length sanitization in 
dnrmg_receive_user_skb"
  Merge branch 'netvsc-bug-fixes'
  net: Fix build regression in rtl8723bs staging driver.
  Merge tag 'linux-can-fixes-for-4.12-20170609' of 
git://git.kernel.org/.../mkl/linux-can
  Merge branch 'bnx2x-Fix-malicious-VFs-indication'
  Revert "net: fec: Add a fec_enet_clear_ethtool_stats() stub for 
CONFIG_M5272"
  Merge branch 'mvpp2-fixes'
  Merge branch 'ena-fixes'
  Merge tag 'mlx5-fixes-2017-06-11' of git://git.kernel.org/.../saeed/linux
  Merge tag 'mac80211-for-davem-2017-06-13' of 
git://git.kernel.org/.../jberg/mac80211
  Merge tag 'batadv-net-for-davem-20170613' of 
git://git.open-mesh.org/linux-merge

Dominik Heidler (1):
  l2tp: cast l2tp traffic counter to unsigned

Donald Sharp (1):
  net: ipmr: Fix some mroute forwarding issues in vrf's

Emmanuel Grumbach (2):
  mac80211: don't look at the PM bit of BAR frames
  mac80211: don't send SMPS action frame in AP mode when not needed

Fabio Estevam (1):
  net: fec: Add a fec_enet_clear_ethtool_stats() stub for CONFIG_M5272

Florian Fainelli (1):
  net: phy: Fix MDIO_THUNDER dependencies

Huy Nguyen (1):
  net/mlx5: Remove several module events out of ethtool stats

Jacob Keller (1):
  i40e: fix handling of HW ATR eviction

Jason A. Donenfeld (1):
  mac80211/wpa: use constant time memory comparison for MACs

Jesper Dangaard Brouer (1):
  net: don't global ICMP rate limit packets originating from loopback

Jia-Ju Bai (3):
  net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx
  net: tipc: Fix a sleep-in-atomic bug in tipc_msg_reverse
  i40e: Fix a sleep-in-atomic bug

Joe Perches (2):
  net: phy: add missing SPEED_14000
  netconsole: Remove duplicate "netconsole: " logging prefix

Johan Hovold (1):
  can: peak_usb: fix product-id endianness in error message

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

[Boqun Feng]

On Wed, Jun 14, 2017 at 09:25:58AM -0700, Krister Johansen wrote:
> On Wed, Jun 14, 2017 at 11:02:40AM -0400, Steven Rostedt wrote:
> > On Wed, 14 Jun 2017 09:10:15 -0400
> > Steven Rostedt  wrote:
> > 
> > > Now let's make it simpler. I'll even add the READ_ONCE and WRITE_ONCE
> > > where applicable.
> > > 
> > > 
> > >   CPU0CPU1
> > >   
> > >   LOCK(A)
> > > 
> > >  LOCK(B)
> > >WRITE_ONCE(X, INIT)
> > > 
> > >(the cpu may postpone writing X)
> > > 
> > >(the cpu can fetch wq list here)
> > >   list_add(wq, q)
> > > 
> > >  UNLOCK(B)
> > > 
> > >  (the cpu may fetch old value of X)
> > > 
> > >(write of X happens here)
> > > 
> > >  if (READ_ONCE(X) != init)
> > >schedule();
> > > 
> > >   UNLOCK(A)
> > > 
> > >if (list_empty(wq))
> > >  return;
> > > 
> > > Tell me again how the READ_ONCE() and WRITE_ONCE() helps in this
> > > scenario?
> > > 
> > > Because we are using spinlocks, this wont be an issue for most
> > > architectures. The bug happens if the fetching of the list_empty()
> > > leaks into before the UNLOCK(A).
> > > 
> > > If the reading/writing of the list and the reading/writing of gp_flags
> > > gets reversed in either direction by the CPU, then we have a problem.
> > 
> > FYI..
> > 
> > Both sides need a memory barrier. Otherwise, even with a memory barrier
> > on CPU1 we can still have:
> > 
> > 
> > CPU0CPU1
> > 
> > 
> > LOCK(A)
> >  LOCK(B)
> > 
> >  list_add(wq, q)
> > 
> >  (cpu waits to write wq list)
> > 
> >  (cpu fetches X)
> > 
> >  WRITE_ONCE(X, INIT)
> > 
> > UNLOCK(A)
> > 
> > smp_mb();
> > 
> > if (list_empty(wq))
> >return;
> > 
> >  (cpu writes wq list)
> > 
> >  UNLOCK(B)
> > 
> >  if (READ_ONCE(X) != INIT)
> >schedule()
> > 
> > 
> > Luckily for us, there is a memory barrier on CPU0. In
> > prepare_to_swait() we have:
> > 
> > raw_spin_lock_irqsave(>lock, flags);
> > __prepare_to_swait(q, wait);
> > set_current_state(state);
> > raw_spin_unlock_irqrestore(>lock, flags);
> > 
> > And that set_current_state() call includes a memory barrier, which will
> > prevent the above from happening, as the addition to the wq list must
> > be flushed before fetching X.
> > 
> > I still strongly believe that the swait_active() requires a memory
> > barrier.
> 
> FWLIW, I agree.  There was a smb_mb() in RT-linux's equivalent of
> swait_activate().
> 
> https://www.spinics.net/lists/linux-rt-users/msg10340.html
> 
> If the barrier goes in swait_active() then we don't have to require all
> of the callers of swait_active and swake_up to issue the barrier
> instead.  Handling this in swait_active is likely to be less error
> prone.  Though, we could also do something like wq_has_sleeper() and use
> that preferentially in swake_up and its variants.
> 

I think it makes more sense that we delete the swait_active() in
swake_up()? Because we seems to encourage users to do the quick check on
wait queue on their own, so why do the check again in swake_up()?
Besides, wake_up() doesn't call waitqueue_activie() outside the lock
critical section either.

So how about the patch below(Testing is in progress)? Peter?

Regards,
Boqun

->8
Subject: [PATCH] swait: Remove the lockless swait_active() check in
 swake_up*()

Steven Rostedt reported a potential race in RCU core because of
swake_up():

CPU0CPU1

__call_rcu_core() {

 spin_lock(rnp_root)
 need_wake = __rcu_start_gp() {
  rcu_start_gp_advanced() {
   gp_flags = FLAG_INIT
  }
 }

 rcu_gp_kthread() {
   swait_event_interruptible(wq,
gp_flags & FLAG_INIT) {
   spin_lock(q->lock)

*fetch wq->task_list here! *

   list_add(wq->task_list, q->task_list)
   spin_unlock(q->lock);

   *fetch old value of gp_flags here *

 spin_unlock(rnp_root)

 rcu_gp_kthread_wake() {
  swake_up(wq) {
   swait_active(wq) {
list_empty(wq->task_list)

   } * return false *

  if (condition) * false *
schedule();

In this case, a wakeup is missed, which could 

Re: [PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.

[Boqun Feng]

On Wed, Jun 14, 2017 at 09:25:58AM -0700, Krister Johansen wrote:
> On Wed, Jun 14, 2017 at 11:02:40AM -0400, Steven Rostedt wrote:
> > On Wed, 14 Jun 2017 09:10:15 -0400
> > Steven Rostedt  wrote:
> > 
> > > Now let's make it simpler. I'll even add the READ_ONCE and WRITE_ONCE
> > > where applicable.
> > > 
> > > 
> > >   CPU0CPU1
> > >   
> > >   LOCK(A)
> > > 
> > >  LOCK(B)
> > >WRITE_ONCE(X, INIT)
> > > 
> > >(the cpu may postpone writing X)
> > > 
> > >(the cpu can fetch wq list here)
> > >   list_add(wq, q)
> > > 
> > >  UNLOCK(B)
> > > 
> > >  (the cpu may fetch old value of X)
> > > 
> > >(write of X happens here)
> > > 
> > >  if (READ_ONCE(X) != init)
> > >schedule();
> > > 
> > >   UNLOCK(A)
> > > 
> > >if (list_empty(wq))
> > >  return;
> > > 
> > > Tell me again how the READ_ONCE() and WRITE_ONCE() helps in this
> > > scenario?
> > > 
> > > Because we are using spinlocks, this wont be an issue for most
> > > architectures. The bug happens if the fetching of the list_empty()
> > > leaks into before the UNLOCK(A).
> > > 
> > > If the reading/writing of the list and the reading/writing of gp_flags
> > > gets reversed in either direction by the CPU, then we have a problem.
> > 
> > FYI..
> > 
> > Both sides need a memory barrier. Otherwise, even with a memory barrier
> > on CPU1 we can still have:
> > 
> > 
> > CPU0CPU1
> > 
> > 
> > LOCK(A)
> >  LOCK(B)
> > 
> >  list_add(wq, q)
> > 
> >  (cpu waits to write wq list)
> > 
> >  (cpu fetches X)
> > 
> >  WRITE_ONCE(X, INIT)
> > 
> > UNLOCK(A)
> > 
> > smp_mb();
> > 
> > if (list_empty(wq))
> >return;
> > 
> >  (cpu writes wq list)
> > 
> >  UNLOCK(B)
> > 
> >  if (READ_ONCE(X) != INIT)
> >schedule()
> > 
> > 
> > Luckily for us, there is a memory barrier on CPU0. In
> > prepare_to_swait() we have:
> > 
> > raw_spin_lock_irqsave(>lock, flags);
> > __prepare_to_swait(q, wait);
> > set_current_state(state);
> > raw_spin_unlock_irqrestore(>lock, flags);
> > 
> > And that set_current_state() call includes a memory barrier, which will
> > prevent the above from happening, as the addition to the wq list must
> > be flushed before fetching X.
> > 
> > I still strongly believe that the swait_active() requires a memory
> > barrier.
> 
> FWLIW, I agree.  There was a smb_mb() in RT-linux's equivalent of
> swait_activate().
> 
> https://www.spinics.net/lists/linux-rt-users/msg10340.html
> 
> If the barrier goes in swait_active() then we don't have to require all
> of the callers of swait_active and swake_up to issue the barrier
> instead.  Handling this in swait_active is likely to be less error
> prone.  Though, we could also do something like wq_has_sleeper() and use
> that preferentially in swake_up and its variants.
> 

I think it makes more sense that we delete the swait_active() in
swake_up()? Because we seems to encourage users to do the quick check on
wait queue on their own, so why do the check again in swake_up()?
Besides, wake_up() doesn't call waitqueue_activie() outside the lock
critical section either.

So how about the patch below(Testing is in progress)? Peter?

Regards,
Boqun

->8
Subject: [PATCH] swait: Remove the lockless swait_active() check in
 swake_up*()

Steven Rostedt reported a potential race in RCU core because of
swake_up():

CPU0CPU1

__call_rcu_core() {

 spin_lock(rnp_root)
 need_wake = __rcu_start_gp() {
  rcu_start_gp_advanced() {
   gp_flags = FLAG_INIT
  }
 }

 rcu_gp_kthread() {
   swait_event_interruptible(wq,
gp_flags & FLAG_INIT) {
   spin_lock(q->lock)

*fetch wq->task_list here! *

   list_add(wq->task_list, q->task_list)
   spin_unlock(q->lock);

   *fetch old value of gp_flags here *

 spin_unlock(rnp_root)

 rcu_gp_kthread_wake() {
  swake_up(wq) {
   swait_active(wq) {
list_empty(wq->task_list)

   } * return false *

  if (condition) * false *
schedule();

In this case, a wakeup is missed, which could cause the 

Re: Qemu crashes in -next due to 'of: remove *phandle properties from expanded device tree'

[Guenter Roeck]

On 06/14/2017 05:45 PM, Frank Rowand wrote:

On 06/14/17 15:35, Guenter Roeck wrote:

On Wed, Jun 14, 2017 at 02:31:58PM -0700, Frank Rowand wrote:

Hi Guenter,


< snip >


Can you also include the console messages before the "[ cut here ]" line?


http://kerneltests.org/builders

Check qemu test results in the 'next' column. ppc and ppc64 show related console
messages.


Thanks for the pointer.  Unfortunately I did not see any additional clues (yet)
in the full log.

I tried to compare the failed boot to a good boot, but did not find a console
log for a good boot.  I started at the qemu-ppc-next builder page:

   http://kerneltests.org/builders/qemu-ppc64-next

and looked at recent tests that were successful (like #645).  But the log file
link from that test does not show the contents of the console for tests that
pass.  Is there some way to see what the console for a successful test looks
like?

-Frank


Good (v4.12-rc4):

...
NR_IRQS:512 nr_irqs:512 16
OF: Checking node /
OF:   node '/' compatible '' type 'open-pic' name '' score 0
OF:   node '/' compatible 'open-pic' type '' name '' score 0
OF: Checking node /pci@e0008000
OF:   node '/pci@e0008000' compatible '' type 'open-pic' name '' score 0
OF:   node '/pci@e0008000' compatible 'open-pic' type '' name '' score 0
OF: Checking node /soc@e000
OF:   node '/soc@e000' compatible '' type 'open-pic' name '' score 0
OF:   node '/soc@e000' compatible 'open-pic' type '' name '' score 0
OF: Checking node /soc@e000/msi@41600
OF:   node '/soc@e000/msi@41600' compatible '' type 'open-pic' name '' 
score 0
OF:   node '/soc@e000/msi@41600' compatible 'open-pic' type '' name '' 
score 0
OF: Checking node /soc@e000/global-utilities@e
OF:   node '/soc@e000/global-utilities@e' compatible '' type 'open-pic' 
name '' score 0
OF:   node '/soc@e000/global-utilities@e' compatible 'open-pic' type '' 
name '' score 0
OF: Checking node /soc@e000/serial@4500
OF:   node '/soc@e000/serial@4500' compatible '' type 'open-pic' name '' 
score 0
OF:   node '/soc@e000/serial@4500' compatible 'open-pic' type '' name '' 
score 0
OF: Checking node /soc@e000/pic@4
OF: type match
OF:   node '/soc@e000/pic@4' compatible '' type 'open-pic' name '' 
score 2
OF:   node '/soc@e000/pic@4' compatible 'open-pic' type '' name '' 
score 0
mpic: Setting up MPIC " OpenPIC  " version 1.2 at e004, max 1 CPUs
mpic: ISU size: 512, shift: 9, mask: 1ff
mpic: Initializing for 512 sources

bad:

NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
OF: Checking node /
OF:   node '/' compatible '' type 'open-pic' name '' score 0
OF:   node '/' compatible 'open-pic' type '' name '' score 0
OF: Checking node /pci@e0008000
OF:   node '/pci@e0008000' compatible '' type 'open-pic' name '' score 0
OF:   node '/pci@e0008000' compatible 'open-pic' type '' name '' score 0
OF: Checking node /soc@e000
OF:   node '/soc@e000' compatible '' type 'open-pic' name '' score 0
OF:   node '/soc@e000' compatible 'open-pic' type '' name '' score 0
OF: Checking node /soc@e000/msi@41600
OF:   node '/soc@e000/msi@41600' compatible '' type 'open-pic' name '' 
score 0
OF:   node '/soc@e000/msi@41600' compatible 'open-pic' type '' name '' 
score 0
OF: Checking node /soc@e000/global-utilities@e
OF:   node '/soc@e000/global-utilities@e' compatible '' type 'open-pic' 
name '' score 0
OF:   node '/soc@e000/global-utilities@e' compatible 'open-pic' type '' 
name '' score 0
OF: Checking node /soc@e000/serial@4500
OF:   node '/soc@e000/serial@4500' compatible '' type 'open-pic' name '' 
score 0
OF:   node '/soc@e000/serial@4500' compatible 'open-pic' type '' name '' 
score 0
OF: Checking node /soc@e000/pic@4
OF:   node '/soc@e000/pic@4' compatible '' type 'open-pic' name '' 
score 0
OF:   node '/soc@e000/pic@4' compatible 'open-pic' type '' name '' 
score 0
OF: Checking node /aliases
OF:   node '/aliases' compatible '' type 'open-pic' name '' score 0
OF:   node '/aliases' compatible 'open-pic' type '' name '' score 0
OF: Checking node /cpus
OF:   node '/cpus' compatible '' type 'open-pic' name '' score 0
OF:   node '/cpus' compatible 'open-pic' type '' name '' score 0
OF: Checking node /cpus/PowerPC,8544@0
OF:   node '/cpus/PowerPC,8544@0' compatible '' type 'open-pic' name '' score 0
OF:   node '/cpus/PowerPC,8544@0' compatible 'open-pic' type '' name '' score 0
OF: Checking node /chosen
OF:   node '/chosen' compatible '' type 'open-pic' name '' score 0
OF:   node '/chosen' compatible 'open-pic' type '' name '' score 0
OF: Checking node /memory
OF:   node '/memory' compatible '' type 'open-pic' name '' score 0
OF:   node '/memory' compatible 'open-pic' type '' name '' score 0
No matching open-pic node
[ cut here ]
kernel BUG at arch/powerpc/platforms/85xx/corenet_generic.c:50!

So, in __of_device_is_compatible(), the difference is in

Re: Qemu crashes in -next due to 'of: remove *phandle properties from expanded device tree'

[Guenter Roeck]

On 06/14/2017 05:45 PM, Frank Rowand wrote:

On 06/14/17 15:35, Guenter Roeck wrote:

On Wed, Jun 14, 2017 at 02:31:58PM -0700, Frank Rowand wrote:

Hi Guenter,


< snip >


Can you also include the console messages before the "[ cut here ]" line?


http://kerneltests.org/builders

Check qemu test results in the 'next' column. ppc and ppc64 show related console
messages.


Thanks for the pointer.  Unfortunately I did not see any additional clues (yet)
in the full log.

I tried to compare the failed boot to a good boot, but did not find a console
log for a good boot.  I started at the qemu-ppc-next builder page:

   http://kerneltests.org/builders/qemu-ppc64-next

and looked at recent tests that were successful (like #645).  But the log file
link from that test does not show the contents of the console for tests that
pass.  Is there some way to see what the console for a successful test looks
like?

-Frank


Good (v4.12-rc4):

...
NR_IRQS:512 nr_irqs:512 16
OF: Checking node /
OF:   node '/' compatible '' type 'open-pic' name '' score 0
OF:   node '/' compatible 'open-pic' type '' name '' score 0
OF: Checking node /pci@e0008000
OF:   node '/pci@e0008000' compatible '' type 'open-pic' name '' score 0
OF:   node '/pci@e0008000' compatible 'open-pic' type '' name '' score 0
OF: Checking node /soc@e000
OF:   node '/soc@e000' compatible '' type 'open-pic' name '' score 0
OF:   node '/soc@e000' compatible 'open-pic' type '' name '' score 0
OF: Checking node /soc@e000/msi@41600
OF:   node '/soc@e000/msi@41600' compatible '' type 'open-pic' name '' 
score 0
OF:   node '/soc@e000/msi@41600' compatible 'open-pic' type '' name '' 
score 0
OF: Checking node /soc@e000/global-utilities@e
OF:   node '/soc@e000/global-utilities@e' compatible '' type 'open-pic' 
name '' score 0
OF:   node '/soc@e000/global-utilities@e' compatible 'open-pic' type '' 
name '' score 0
OF: Checking node /soc@e000/serial@4500
OF:   node '/soc@e000/serial@4500' compatible '' type 'open-pic' name '' 
score 0
OF:   node '/soc@e000/serial@4500' compatible 'open-pic' type '' name '' 
score 0
OF: Checking node /soc@e000/pic@4
OF: type match
OF:   node '/soc@e000/pic@4' compatible '' type 'open-pic' name '' 
score 2
OF:   node '/soc@e000/pic@4' compatible 'open-pic' type '' name '' 
score 0
mpic: Setting up MPIC " OpenPIC  " version 1.2 at e004, max 1 CPUs
mpic: ISU size: 512, shift: 9, mask: 1ff
mpic: Initializing for 512 sources

bad:

NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
OF: Checking node /
OF:   node '/' compatible '' type 'open-pic' name '' score 0
OF:   node '/' compatible 'open-pic' type '' name '' score 0
OF: Checking node /pci@e0008000
OF:   node '/pci@e0008000' compatible '' type 'open-pic' name '' score 0
OF:   node '/pci@e0008000' compatible 'open-pic' type '' name '' score 0
OF: Checking node /soc@e000
OF:   node '/soc@e000' compatible '' type 'open-pic' name '' score 0
OF:   node '/soc@e000' compatible 'open-pic' type '' name '' score 0
OF: Checking node /soc@e000/msi@41600
OF:   node '/soc@e000/msi@41600' compatible '' type 'open-pic' name '' 
score 0
OF:   node '/soc@e000/msi@41600' compatible 'open-pic' type '' name '' 
score 0
OF: Checking node /soc@e000/global-utilities@e
OF:   node '/soc@e000/global-utilities@e' compatible '' type 'open-pic' 
name '' score 0
OF:   node '/soc@e000/global-utilities@e' compatible 'open-pic' type '' 
name '' score 0
OF: Checking node /soc@e000/serial@4500
OF:   node '/soc@e000/serial@4500' compatible '' type 'open-pic' name '' 
score 0
OF:   node '/soc@e000/serial@4500' compatible 'open-pic' type '' name '' 
score 0
OF: Checking node /soc@e000/pic@4
OF:   node '/soc@e000/pic@4' compatible '' type 'open-pic' name '' 
score 0
OF:   node '/soc@e000/pic@4' compatible 'open-pic' type '' name '' 
score 0
OF: Checking node /aliases
OF:   node '/aliases' compatible '' type 'open-pic' name '' score 0
OF:   node '/aliases' compatible 'open-pic' type '' name '' score 0
OF: Checking node /cpus
OF:   node '/cpus' compatible '' type 'open-pic' name '' score 0
OF:   node '/cpus' compatible 'open-pic' type '' name '' score 0
OF: Checking node /cpus/PowerPC,8544@0
OF:   node '/cpus/PowerPC,8544@0' compatible '' type 'open-pic' name '' score 0
OF:   node '/cpus/PowerPC,8544@0' compatible 'open-pic' type '' name '' score 0
OF: Checking node /chosen
OF:   node '/chosen' compatible '' type 'open-pic' name '' score 0
OF:   node '/chosen' compatible 'open-pic' type '' name '' score 0
OF: Checking node /memory
OF:   node '/memory' compatible '' type 'open-pic' name '' score 0
OF:   node '/memory' compatible 'open-pic' type '' name '' score 0
No matching open-pic node
[ cut here ]
kernel BUG at arch/powerpc/platforms/85xx/corenet_generic.c:50!

So, in __of_device_is_compatible(), the difference is in

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

[Stephen Rothwell]

Hi Kees,

On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook  wrote:
>
> CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> so objtool needs to know about it too.
> 
> Suggested-by: Daniel Micay 
> Signed-off-by: Kees Cook 
> Cc: Josh Poimboeuf 
> ---
>  tools/objtool/builtin-check.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
> index 282a60368b14..5f66697fe1e0 100644
> --- a/tools/objtool/builtin-check.c
> +++ b/tools/objtool/builtin-check.c
> @@ -192,7 +192,8 @@ static int __dead_end_function(struct objtool_file *file, 
> struct symbol *func,
>   "complete_and_exit",
>   "kvm_spurious_fault",
>   "__reiserfs_panic",
> - "lbug_with_loc"
> + "lbug_with_loc",
> + "fortify_panic",
>   };
>  
>   if (func->bind == STB_WEAK)
> -- 
> 2.7.4

OK, I have added this to the end of linux-next today (in the part of
Andrew's tree afte the linux-next merge).  I also move the fortify
string patch to after it (but I assume I will still need to revert it).

I willl drop this patch when it appears elsewhere in linux-next.
-- 
Cheers,
Stephen Rothwell

Re: [PATCH] objtool: Add fortify_panic as __noreturn function

[Stephen Rothwell]

Hi Kees,

On Wed, 14 Jun 2017 19:18:51 -0700 Kees Cook  wrote:
>
> CONFIG_FORTIFY_SOURCE implements fortify_panic() as a __noreturn function,
> so objtool needs to know about it too.
> 
> Suggested-by: Daniel Micay 
> Signed-off-by: Kees Cook 
> Cc: Josh Poimboeuf 
> ---
>  tools/objtool/builtin-check.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
> index 282a60368b14..5f66697fe1e0 100644
> --- a/tools/objtool/builtin-check.c
> +++ b/tools/objtool/builtin-check.c
> @@ -192,7 +192,8 @@ static int __dead_end_function(struct objtool_file *file, 
> struct symbol *func,
>   "complete_and_exit",
>   "kvm_spurious_fault",
>   "__reiserfs_panic",
> - "lbug_with_loc"
> + "lbug_with_loc",
> + "fortify_panic",
>   };
>  
>   if (func->bind == STB_WEAK)
> -- 
> 2.7.4

OK, I have added this to the end of linux-next today (in the part of
Andrew's tree afte the linux-next merge).  I also move the fortify
string patch to after it (but I assume I will still need to revert it).

I willl drop this patch when it appears elsewhere in linux-next.
-- 
Cheers,
Stephen Rothwell

Re: [PATCH] dmaengine: qcom-bam: Process multiple pending descriptors

[Vinod Koul]

On Wed, Jun 07, 2017 at 05:59:07PM +0530, Sricharan R wrote:
> The bam dmaengine has a circular FIFO to which we
> add hw descriptors that describes the transaction.
> The FIFO has space for about 4096 hw descriptors.
> 
> Currently we add one descriptor and wait for it to
> complete with interrupt and start processing the
> next pending descriptor. In this way, FIFO is
> underutilised and also adds additional interrupt
> overhead for each of the descriptor. This results
> in loss of throughput for clients that submits
> multiple descriptors together, that can be processed
> by bam and the client peripheral together.
> So instead, when a client does an issue_pending,
> we can keep pulling in descriptors from the pending
> queue and add it to the FIFO, till either the FIFO
> is full (or) client has requested for an interrupt
> notification for that descriptor. After this,
> receiving a completion interrupt implies that all
> descriptors that were submitted have completed.
> so notify completion for all the descriptors.
> 
> CURRENT:
> 
> --  ---   ---
> |DES 0| |DESC 1|  |DESC 2 + INT |
> --  ---   ---
>|   ||
>|   ||
> INTERRUPT:   (INT)   (INT)  (INT)
> CALLBACK: (CB)(CB) (CB)
> 
>   MTD_SPEEDTEST READ PAGE: 3560 KiB/s
>   MTD_SPEEDTEST WRITE PAGE: 2664 KiB/s
>   IOZONE READ: 2456 KB/s
>   IOZONE WRITE: 1230 KB/s
> 
>   bam dma interrupts (after tests): 96508
> 
> CHANGE:
> 
> --  ----
> |DES 0| |DESC 1   |DESC 2 + INT |
> --  ---   --
>   |
>   |
> (INT)
> (CB for 0, 1, 2)

I am not sure why suppressing callback helps? I think you should still
continue filling up FIFO but also ensure interrupt so that callback can be
invoked, user thread maybe waiting on that

FWIW waiting for interrupt and submitting is extremely inefficient and
shouldn't be done, so that part of this is good.

> 
>   MTD_SPEEDTEST READ PAGE: 3860 KiB/s
>   MTD_SPEEDTEST WRITE PAGE: 2837 KiB/s
>   IOZONE READ: 2677 KB/s
>   IOZONE WRITE: 1308 KB/s
> 
>   bam dma interrupts (after tests): 58806
> 
> Signed-off-by: Sricharan R 
> ---
>  drivers/dma/qcom/bam_dma.c | 180 
> +
>  1 file changed, 115 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 03c4eb3..97892f7 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -76,7 +77,8 @@ struct bam_async_desc {
>   u16 flags;
>  
>   struct bam_desc_hw *curr_desc;
> -
> + /* list node for the desc in the bam_chan list of descriptors */
> + struct list_head desc_node;
>   enum dma_transfer_direction dir;
>   size_t length;
>   struct bam_desc_hw desc[0];
> @@ -371,6 +373,8 @@ struct bam_chan {
>   unsigned int initialized;   /* is the channel hw initialized? */
>   unsigned int paused;/* is the channel paused? */
>   unsigned int reconfigure;   /* new slave config? */
> + /* list of descriptors currently processed */
> + struct list_head desc_list;
>  
>   struct list_head node;
>  };
> @@ -486,6 +490,8 @@ static void bam_chan_init_hw(struct bam_chan *bchan,
>  
>   bchan->initialized = 1;
>  
> + INIT_LIST_HEAD(>desc_list);
> +
>   /* init FIFO pointers */
>   bchan->head = 0;
>   bchan->tail = 0;
> @@ -631,8 +637,6 @@ static struct dma_async_tx_descriptor 
> *bam_prep_slave_sg(struct dma_chan *chan,
>  
>   if (flags & DMA_PREP_INTERRUPT)
>   async_desc->flags |= DESC_FLAG_EOT;
> - else
> - async_desc->flags |= DESC_FLAG_INT;

shouldn't we do DESC_FLAG_INT for DMA_PREP_INTERRUPT and not EOT which i
suppose means end of transfers?

>  
>   async_desc->num_desc = num_alloc;
>   async_desc->curr_desc = async_desc->desc;
> @@ -680,13 +684,18 @@ static struct dma_async_tx_descriptor 
> *bam_prep_slave_sg(struct dma_chan *chan,
>  static int bam_dma_terminate_all(struct dma_chan *chan)
>  {
>   struct bam_chan *bchan = to_bam_chan(chan);
> + struct bam_async_desc *async_desc;
>   unsigned long flag;
>   LIST_HEAD(head);
>  
>   /* remove all transactions, including active transaction */
>   spin_lock_irqsave(>vc.lock, flag);
>   if (bchan->curr_txd) {
> - list_add(>curr_txd->vd.node, >vc.desc_issued);
> + list_for_each_entry(async_desc, >desc_list, desc_node) {
> +   

Re: [PATCH] dmaengine: qcom-bam: Process multiple pending descriptors

[Vinod Koul]

On Wed, Jun 07, 2017 at 05:59:07PM +0530, Sricharan R wrote:
> The bam dmaengine has a circular FIFO to which we
> add hw descriptors that describes the transaction.
> The FIFO has space for about 4096 hw descriptors.
> 
> Currently we add one descriptor and wait for it to
> complete with interrupt and start processing the
> next pending descriptor. In this way, FIFO is
> underutilised and also adds additional interrupt
> overhead for each of the descriptor. This results
> in loss of throughput for clients that submits
> multiple descriptors together, that can be processed
> by bam and the client peripheral together.
> So instead, when a client does an issue_pending,
> we can keep pulling in descriptors from the pending
> queue and add it to the FIFO, till either the FIFO
> is full (or) client has requested for an interrupt
> notification for that descriptor. After this,
> receiving a completion interrupt implies that all
> descriptors that were submitted have completed.
> so notify completion for all the descriptors.
> 
> CURRENT:
> 
> --  ---   ---
> |DES 0| |DESC 1|  |DESC 2 + INT |
> --  ---   ---
>|   ||
>|   ||
> INTERRUPT:   (INT)   (INT)  (INT)
> CALLBACK: (CB)(CB) (CB)
> 
>   MTD_SPEEDTEST READ PAGE: 3560 KiB/s
>   MTD_SPEEDTEST WRITE PAGE: 2664 KiB/s
>   IOZONE READ: 2456 KB/s
>   IOZONE WRITE: 1230 KB/s
> 
>   bam dma interrupts (after tests): 96508
> 
> CHANGE:
> 
> --  ----
> |DES 0| |DESC 1   |DESC 2 + INT |
> --  ---   --
>   |
>   |
> (INT)
> (CB for 0, 1, 2)

I am not sure why suppressing callback helps? I think you should still
continue filling up FIFO but also ensure interrupt so that callback can be
invoked, user thread maybe waiting on that

FWIW waiting for interrupt and submitting is extremely inefficient and
shouldn't be done, so that part of this is good.

> 
>   MTD_SPEEDTEST READ PAGE: 3860 KiB/s
>   MTD_SPEEDTEST WRITE PAGE: 2837 KiB/s
>   IOZONE READ: 2677 KB/s
>   IOZONE WRITE: 1308 KB/s
> 
>   bam dma interrupts (after tests): 58806
> 
> Signed-off-by: Sricharan R 
> ---
>  drivers/dma/qcom/bam_dma.c | 180 
> +
>  1 file changed, 115 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 03c4eb3..97892f7 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -76,7 +77,8 @@ struct bam_async_desc {
>   u16 flags;
>  
>   struct bam_desc_hw *curr_desc;
> -
> + /* list node for the desc in the bam_chan list of descriptors */
> + struct list_head desc_node;
>   enum dma_transfer_direction dir;
>   size_t length;
>   struct bam_desc_hw desc[0];
> @@ -371,6 +373,8 @@ struct bam_chan {
>   unsigned int initialized;   /* is the channel hw initialized? */
>   unsigned int paused;/* is the channel paused? */
>   unsigned int reconfigure;   /* new slave config? */
> + /* list of descriptors currently processed */
> + struct list_head desc_list;
>  
>   struct list_head node;
>  };
> @@ -486,6 +490,8 @@ static void bam_chan_init_hw(struct bam_chan *bchan,
>  
>   bchan->initialized = 1;
>  
> + INIT_LIST_HEAD(>desc_list);
> +
>   /* init FIFO pointers */
>   bchan->head = 0;
>   bchan->tail = 0;
> @@ -631,8 +637,6 @@ static struct dma_async_tx_descriptor 
> *bam_prep_slave_sg(struct dma_chan *chan,
>  
>   if (flags & DMA_PREP_INTERRUPT)
>   async_desc->flags |= DESC_FLAG_EOT;
> - else
> - async_desc->flags |= DESC_FLAG_INT;

shouldn't we do DESC_FLAG_INT for DMA_PREP_INTERRUPT and not EOT which i
suppose means end of transfers?

>  
>   async_desc->num_desc = num_alloc;
>   async_desc->curr_desc = async_desc->desc;
> @@ -680,13 +684,18 @@ static struct dma_async_tx_descriptor 
> *bam_prep_slave_sg(struct dma_chan *chan,
>  static int bam_dma_terminate_all(struct dma_chan *chan)
>  {
>   struct bam_chan *bchan = to_bam_chan(chan);
> + struct bam_async_desc *async_desc;
>   unsigned long flag;
>   LIST_HEAD(head);
>  
>   /* remove all transactions, including active transaction */
>   spin_lock_irqsave(>vc.lock, flag);
>   if (bchan->curr_txd) {
> - list_add(>curr_txd->vd.node, >vc.desc_issued);
> + list_for_each_entry(async_desc, >desc_list, desc_node) {
> + bchan->curr_txd = 

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

[Icenowy Zheng]

于 2017年6月15日 GMT+08:00 上午11:54:08, Vinod Koul  写到:
>On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
>> On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
>> > > SoC info is in compatible, so there's no reason to make it a
>property.
>> > 
>> > that's why it would need to be optional for the SoC's that needs
>these..
>> 
>> There's nothing optional about that behaviour, it's mandatory for the
>> SoC that need it, and useless on the SoC that don't.
>
>And why should kernel put strings for each hw behaviour. I am expecting
>DT
>to tell me if this SoC is a special case or not and kernel shall handle
>accordingly

I don't think this kind of behavior should be described in DT.

Rob, do you agree?

>
>> Plus, that would require changing the DT binding, which isn't
>> something we can do.
>
>Any reason why bindings can't change..? I though this was support for
>new
>SoC...

This is a behavior that exists on a SoC that is already
supported (A23/A33).

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

[Icenowy Zheng]

于 2017年6月15日 GMT+08:00 上午11:54:08, Vinod Koul  写到:
>On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
>> On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
>> > > SoC info is in compatible, so there's no reason to make it a
>property.
>> > 
>> > that's why it would need to be optional for the SoC's that needs
>these..
>> 
>> There's nothing optional about that behaviour, it's mandatory for the
>> SoC that need it, and useless on the SoC that don't.
>
>And why should kernel put strings for each hw behaviour. I am expecting
>DT
>to tell me if this SoC is a special case or not and kernel shall handle
>accordingly

I don't think this kind of behavior should be described in DT.

Rob, do you agree?

>
>> Plus, that would require changing the DT binding, which isn't
>> something we can do.
>
>Any reason why bindings can't change..? I though this was support for
>new
>SoC...

This is a behavior that exists on a SoC that is already
supported (A23/A33).

Re: [PATCH v2] ip6_tunnel: Correct tos value in collect_md mode

[Peter Dawson]

On Thu, 15 Jun 2017 10:30:29 +0800
Haishuang Yan  wrote:

> Same as ip_gre, geneve and vxlan, use key->tos as tos value.
> 
> CC: Peter Dawson 
> Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on
> encapsulated packets”)
> Suggested-by: Daniel Borkmann 
> Signed-off-by: Haishuang Yan 
> 
> ---
> Changes since v2:
>   * Add fixes information
>   * mask key->tos with RT_TOS() suggested by Daniel
> ---
>  net/ipv6/ip6_tunnel.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index ef99d59..6400726 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -1249,7 +1249,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device 
> *dev, __u8 dsfield,
>   fl6.flowi6_proto = IPPROTO_IPIP;
>   fl6.daddr = key->u.ipv6.dst;
>   fl6.flowlabel = key->label;
> - dsfield = ip6_tclass(key->label);
> + dsfield =  RT_TOS(key->tos);
>   } else {
>   if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
>   encap_limit = t->parms.encap_limit;
> @@ -1320,7 +1320,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device 
> *dev, __u8 dsfield,
>   fl6.flowi6_proto = IPPROTO_IPV6;
>   fl6.daddr = key->u.ipv6.dst;
>   fl6.flowlabel = key->label;
> - dsfield = ip6_tclass(key->label);
> + dsfield = RT_TOS(key->tos);
>   } else {
>   offset = ip6_tnl_parse_tlv_enc_lim(skb, 
> skb_network_header(skb));
>   /* ip6_tnl_parse_tlv_enc_lim() might have reallocated skb->head 
> */

I don't think it is correct to apply RT_TOS

Here is my understanding based on the RFCs.

IPv4/6 Header:0 |0 1 2 3 |0 1 2 3 |0 1 2 3 |0 1 2 3 |
RFC2460(IPv6)   |Version | Traffic Class   ||
RFC2474(IPv6)   |Version | DSCP|ECN||
RFC2474(IPv4)   |Version |  IHL   |DSCP |ECN|
RFC1349(IPv4)   |Version |  IHL   | PREC |  TOS   |X| 
RFC791 (IPv4)   |Version |  IHL   |  TOS|

u8 key->tos stores the full 8bits of Traffic class from an IPv6 header and;
u8 key->tos stores the full 8bits of TOS(RFC791) from an IPv4 header
u8 ip6_tclass will return the full 8bits of Traffic Class from an IPv6 flowlabel

RT_TOS will return the RFC1349 4bit TOS field.

Applying RT_TOS to a key->tos will result in lost information and the inclusion 
of 1 bit of ECN if the original field was a DSCP+ECN.

Based on this understanding of the RFCs (but not years of experience) and since 
RFC1349 has been obsoleted by RFC2474 I think the use of RT_TOS should be 
deprecated.

This being said, dsfield = ip6_tclass(key->label) = key->tos isn't fully 
correct either because the result will contain the ECN bits as well as the DSCP.

I agree that code should be consistent, but not where there is a potential 
issue.

Re: [PATCH v2] ip6_tunnel: Correct tos value in collect_md mode

[Peter Dawson]

On Thu, 15 Jun 2017 10:30:29 +0800
Haishuang Yan  wrote:

> Same as ip_gre, geneve and vxlan, use key->tos as tos value.
> 
> CC: Peter Dawson 
> Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on
> encapsulated packets”)
> Suggested-by: Daniel Borkmann 
> Signed-off-by: Haishuang Yan 
> 
> ---
> Changes since v2:
>   * Add fixes information
>   * mask key->tos with RT_TOS() suggested by Daniel
> ---
>  net/ipv6/ip6_tunnel.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index ef99d59..6400726 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -1249,7 +1249,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device 
> *dev, __u8 dsfield,
>   fl6.flowi6_proto = IPPROTO_IPIP;
>   fl6.daddr = key->u.ipv6.dst;
>   fl6.flowlabel = key->label;
> - dsfield = ip6_tclass(key->label);
> + dsfield =  RT_TOS(key->tos);
>   } else {
>   if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
>   encap_limit = t->parms.encap_limit;
> @@ -1320,7 +1320,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device 
> *dev, __u8 dsfield,
>   fl6.flowi6_proto = IPPROTO_IPV6;
>   fl6.daddr = key->u.ipv6.dst;
>   fl6.flowlabel = key->label;
> - dsfield = ip6_tclass(key->label);
> + dsfield = RT_TOS(key->tos);
>   } else {
>   offset = ip6_tnl_parse_tlv_enc_lim(skb, 
> skb_network_header(skb));
>   /* ip6_tnl_parse_tlv_enc_lim() might have reallocated skb->head 
> */

I don't think it is correct to apply RT_TOS

Here is my understanding based on the RFCs.

IPv4/6 Header:0 |0 1 2 3 |0 1 2 3 |0 1 2 3 |0 1 2 3 |
RFC2460(IPv6)   |Version | Traffic Class   ||
RFC2474(IPv6)   |Version | DSCP|ECN||
RFC2474(IPv4)   |Version |  IHL   |DSCP |ECN|
RFC1349(IPv4)   |Version |  IHL   | PREC |  TOS   |X| 
RFC791 (IPv4)   |Version |  IHL   |  TOS|

u8 key->tos stores the full 8bits of Traffic class from an IPv6 header and;
u8 key->tos stores the full 8bits of TOS(RFC791) from an IPv4 header
u8 ip6_tclass will return the full 8bits of Traffic Class from an IPv6 flowlabel

RT_TOS will return the RFC1349 4bit TOS field.

Applying RT_TOS to a key->tos will result in lost information and the inclusion 
of 1 bit of ECN if the original field was a DSCP+ECN.

Based on this understanding of the RFCs (but not years of experience) and since 
RFC1349 has been obsoleted by RFC2474 I think the use of RT_TOS should be 
deprecated.

This being said, dsfield = ip6_tclass(key->label) = key->tos isn't fully 
correct either because the result will contain the ECN bits as well as the DSCP.

I agree that code should be consistent, but not where there is a potential 
issue.

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

[Vinod Koul]

On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
> On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
> > > SoC info is in compatible, so there's no reason to make it a property.
> > 
> > that's why it would need to be optional for the SoC's that needs these..
> 
> There's nothing optional about that behaviour, it's mandatory for the
> SoC that need it, and useless on the SoC that don't.

And why should kernel put strings for each hw behaviour. I am expecting DT
to tell me if this SoC is a special case or not and kernel shall handle
accordingly

> Plus, that would require changing the DT binding, which isn't
> something we can do.

Any reason why bindings can't change..? I though this was support for new
SoC...

-- 
~Vinod

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

[Vinod Koul]

On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
> On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
> > > SoC info is in compatible, so there's no reason to make it a property.
> > 
> > that's why it would need to be optional for the SoC's that needs these..
> 
> There's nothing optional about that behaviour, it's mandatory for the
> SoC that need it, and useless on the SoC that don't.

And why should kernel put strings for each hw behaviour. I am expecting DT
to tell me if this SoC is a special case or not and kernel shall handle
accordingly

> Plus, that would require changing the DT binding, which isn't
> something we can do.

Any reason why bindings can't change..? I though this was support for new
SoC...

-- 
~Vinod

Re: [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v3

[zhong jiang]

On 2017/5/25 1:20, Jérôme Glisse wrote:
> HMM (heterogeneous memory management) need struct page to support migration
> from system main memory to device memory.  Reasons for HMM and migration to
> device memory is explained with HMM core patch.
>
> This patch deals with device memory that is un-addressable memory (ie CPU
> can not access it). Hence we do not want those struct page to be manage
> like regular memory. That is why we extend ZONE_DEVICE to support different
> types of memory.
>
> A persistent memory type is define for existing user of ZONE_DEVICE and a
> new device un-addressable type is added for the un-addressable memory type.
> There is a clear separation between what is expected from each memory type
> and existing user of ZONE_DEVICE are un-affected by new requirement and new
> use of the un-addressable type. All specific code path are protect with
> test against the memory type.
>
> Because memory is un-addressable we use a new special swap type for when
> a page is migrated to device memory (this reduces the number of maximum
> swap file).
>
> The main two additions beside memory type to ZONE_DEVICE is two callbacks.
> First one, page_free() is call whenever page refcount reach 1 (which means
> the page is free as ZONE_DEVICE page never reach a refcount of 0). This
> allow device driver to manage its memory and associated struct page.
>
> The second callback page_fault() happens when there is a CPU access to
> an address that is back by a device page (which are un-addressable by the
> CPU). This callback is responsible to migrate the page back to system
> main memory. Device driver can not block migration back to system memory,
> HMM make sure that such page can not be pin into device memory.
>
> If device is in some error condition and can not migrate memory back then
> a CPU page fault to device memory should end with SIGBUS.
>
> Changed since v2:
>   - s/DEVICE_UNADDRESSABLE/DEVICE_PRIVATE
> Changed since v1:
>   - rename to device private memory (from device unaddressable)
>
> Signed-off-by: Jérôme Glisse 
> Acked-by: Dan Williams 
> Cc: Ross Zwisler 
> ---
>  fs/proc/task_mmu.c   |  7 +
>  include/linux/ioport.h   |  1 +
>  include/linux/memremap.h | 72 
> 
>  include/linux/mm.h   | 12 
>  include/linux/swap.h | 24 ++--
>  include/linux/swapops.h  | 68 +
>  kernel/memremap.c| 34 +++
>  mm/Kconfig   | 13 +
>  mm/memory.c  | 61 
>  mm/memory_hotplug.c  | 10 +--
>  mm/mprotect.c| 14 ++
>  11 files changed, 311 insertions(+), 5 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index f0c8b33..90b2fa4 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -542,6 +542,8 @@ static void smaps_pte_entry(pte_t *pte, unsigned long 
> addr,
>   }
>   } else if (is_migration_entry(swpent))
>   page = migration_entry_to_page(swpent);
> + else if (is_device_private_entry(swpent))
> + page = device_private_entry_to_page(swpent);
>   } else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
>   && pte_none(*pte))) {
>   page = find_get_entry(vma->vm_file->f_mapping,
> @@ -704,6 +706,8 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long 
> hmask,
>  
>   if (is_migration_entry(swpent))
>   page = migration_entry_to_page(swpent);
> + else if (is_device_private_entry(swpent))
> + page = device_private_entry_to_page(swpent);
>   }
>   if (page) {
>   int mapcount = page_mapcount(page);
> @@ -1196,6 +1200,9 @@ static pagemap_entry_t pte_to_pagemap_entry(struct 
> pagemapread *pm,
>   flags |= PM_SWAP;
>   if (is_migration_entry(entry))
>   page = migration_entry_to_page(entry);
> +
> + if (is_device_private_entry(entry))
> + page = device_private_entry_to_page(entry);
>   }
>  
>   if (page && !PageAnon(page))
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 6230064..3a4f691 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -130,6 +130,7 @@ enum {
>   IORES_DESC_ACPI_NV_STORAGE  = 3,
>   IORES_DESC_PERSISTENT_MEMORY= 4,
>   IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
> + IORES_DESC_DEVICE_PRIVATE_MEMORY= 6,
>  };
>  
>  /* helpers to define resources */
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 9341619..0fcf840 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> 

Re: [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v3

[zhong jiang]

On 2017/5/25 1:20, Jérôme Glisse wrote:
> HMM (heterogeneous memory management) need struct page to support migration
> from system main memory to device memory.  Reasons for HMM and migration to
> device memory is explained with HMM core patch.
>
> This patch deals with device memory that is un-addressable memory (ie CPU
> can not access it). Hence we do not want those struct page to be manage
> like regular memory. That is why we extend ZONE_DEVICE to support different
> types of memory.
>
> A persistent memory type is define for existing user of ZONE_DEVICE and a
> new device un-addressable type is added for the un-addressable memory type.
> There is a clear separation between what is expected from each memory type
> and existing user of ZONE_DEVICE are un-affected by new requirement and new
> use of the un-addressable type. All specific code path are protect with
> test against the memory type.
>
> Because memory is un-addressable we use a new special swap type for when
> a page is migrated to device memory (this reduces the number of maximum
> swap file).
>
> The main two additions beside memory type to ZONE_DEVICE is two callbacks.
> First one, page_free() is call whenever page refcount reach 1 (which means
> the page is free as ZONE_DEVICE page never reach a refcount of 0). This
> allow device driver to manage its memory and associated struct page.
>
> The second callback page_fault() happens when there is a CPU access to
> an address that is back by a device page (which are un-addressable by the
> CPU). This callback is responsible to migrate the page back to system
> main memory. Device driver can not block migration back to system memory,
> HMM make sure that such page can not be pin into device memory.
>
> If device is in some error condition and can not migrate memory back then
> a CPU page fault to device memory should end with SIGBUS.
>
> Changed since v2:
>   - s/DEVICE_UNADDRESSABLE/DEVICE_PRIVATE
> Changed since v1:
>   - rename to device private memory (from device unaddressable)
>
> Signed-off-by: Jérôme Glisse 
> Acked-by: Dan Williams 
> Cc: Ross Zwisler 
> ---
>  fs/proc/task_mmu.c   |  7 +
>  include/linux/ioport.h   |  1 +
>  include/linux/memremap.h | 72 
> 
>  include/linux/mm.h   | 12 
>  include/linux/swap.h | 24 ++--
>  include/linux/swapops.h  | 68 +
>  kernel/memremap.c| 34 +++
>  mm/Kconfig   | 13 +
>  mm/memory.c  | 61 
>  mm/memory_hotplug.c  | 10 +--
>  mm/mprotect.c| 14 ++
>  11 files changed, 311 insertions(+), 5 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index f0c8b33..90b2fa4 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -542,6 +542,8 @@ static void smaps_pte_entry(pte_t *pte, unsigned long 
> addr,
>   }
>   } else if (is_migration_entry(swpent))
>   page = migration_entry_to_page(swpent);
> + else if (is_device_private_entry(swpent))
> + page = device_private_entry_to_page(swpent);
>   } else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
>   && pte_none(*pte))) {
>   page = find_get_entry(vma->vm_file->f_mapping,
> @@ -704,6 +706,8 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long 
> hmask,
>  
>   if (is_migration_entry(swpent))
>   page = migration_entry_to_page(swpent);
> + else if (is_device_private_entry(swpent))
> + page = device_private_entry_to_page(swpent);
>   }
>   if (page) {
>   int mapcount = page_mapcount(page);
> @@ -1196,6 +1200,9 @@ static pagemap_entry_t pte_to_pagemap_entry(struct 
> pagemapread *pm,
>   flags |= PM_SWAP;
>   if (is_migration_entry(entry))
>   page = migration_entry_to_page(entry);
> +
> + if (is_device_private_entry(entry))
> + page = device_private_entry_to_page(entry);
>   }
>  
>   if (page && !PageAnon(page))
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 6230064..3a4f691 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -130,6 +130,7 @@ enum {
>   IORES_DESC_ACPI_NV_STORAGE  = 3,
>   IORES_DESC_PERSISTENT_MEMORY= 4,
>   IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
> + IORES_DESC_DEVICE_PRIVATE_MEMORY= 6,
>  };
>  
>  /* helpers to define resources */
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 9341619..0fcf840 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -4,6 +4,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  struct 

Re: [HMM-CDM 3/5] mm/memcontrol: allow to uncharge page without using page->lru field

[Balbir Singh]

On Wed, 14 Jun 2017 16:11:42 -0400
Jérôme Glisse  wrote:

> HMM pages (private or public device pages) are ZONE_DEVICE page and
> thus you can not use page->lru fields of those pages. This patch
> re-arrange the uncharge to allow single page to be uncharge without
> modifying the lru field of the struct page.
> 
> There is no change to memcontrol logic, it is the same as it was
> before this patch.
> 
> Signed-off-by: Jérôme Glisse 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Vladimir Davydov 
> Cc: cgro...@vger.kernel.org
> ---
>  mm/memcontrol.c | 168 
> +++-
>  1 file changed, 92 insertions(+), 76 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index e3fe4d0..b93f5fe 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5509,48 +5509,102 @@ void mem_cgroup_cancel_charge(struct page *page, 
> struct mem_cgroup *memcg,
>   cancel_charge(memcg, nr_pages);
>  }
>  
> -static void uncharge_batch(struct mem_cgroup *memcg, unsigned long pgpgout,
> -unsigned long nr_anon, unsigned long nr_file,
> -unsigned long nr_kmem, unsigned long nr_huge,
> -unsigned long nr_shmem, struct page *dummy_page)
> +struct uncharge_gather {
> + struct mem_cgroup *memcg;
> + unsigned long pgpgout;
> + unsigned long nr_anon;
> + unsigned long nr_file;
> + unsigned long nr_kmem;
> + unsigned long nr_huge;
> + unsigned long nr_shmem;
> + struct page *dummy_page;
> +};
> +
> +static inline void uncharge_gather_clear(struct uncharge_gather *ug)
>  {
> - unsigned long nr_pages = nr_anon + nr_file + nr_kmem;
> + memset(ug, 0, sizeof(*ug));
> +}
> +
> +static void uncharge_batch(const struct uncharge_gather *ug)
> +{

Can we pass page as an argument so that we can do check events on the page?

> + unsigned long nr_pages = ug->nr_anon + ug->nr_file + ug->nr_kmem;
>   unsigned long flags;
>  
> - if (!mem_cgroup_is_root(memcg)) {
> - page_counter_uncharge(>memory, nr_pages);
> + if (!mem_cgroup_is_root(ug->memcg)) {
> + page_counter_uncharge(>memcg->memory, nr_pages);
>   if (do_memsw_account())
> - page_counter_uncharge(>memsw, nr_pages);
> - if (!cgroup_subsys_on_dfl(memory_cgrp_subsys) && nr_kmem)
> - page_counter_uncharge(>kmem, nr_kmem);
> - memcg_oom_recover(memcg);
> + page_counter_uncharge(>memcg->memsw, nr_pages);
> + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys) && ug->nr_kmem)
> + page_counter_uncharge(>memcg->kmem, ug->nr_kmem);
> + memcg_oom_recover(ug->memcg);
>   }
>  
>   local_irq_save(flags);
> - __this_cpu_sub(memcg->stat->count[MEMCG_RSS], nr_anon);
> - __this_cpu_sub(memcg->stat->count[MEMCG_CACHE], nr_file);
> - __this_cpu_sub(memcg->stat->count[MEMCG_RSS_HUGE], nr_huge);
> - __this_cpu_sub(memcg->stat->count[NR_SHMEM], nr_shmem);
> - __this_cpu_add(memcg->stat->events[PGPGOUT], pgpgout);
> - __this_cpu_add(memcg->stat->nr_page_events, nr_pages);
> - memcg_check_events(memcg, dummy_page);
> + __this_cpu_sub(ug->memcg->stat->count[MEMCG_RSS], ug->nr_anon);
> + __this_cpu_sub(ug->memcg->stat->count[MEMCG_CACHE], ug->nr_file);
> + __this_cpu_sub(ug->memcg->stat->count[MEMCG_RSS_HUGE], ug->nr_huge);
> + __this_cpu_sub(ug->memcg->stat->count[NR_SHMEM], ug->nr_shmem);
> + __this_cpu_add(ug->memcg->stat->events[PGPGOUT], ug->pgpgout);
> + __this_cpu_add(ug->memcg->stat->nr_page_events, nr_pages);
> + memcg_check_events(ug->memcg, ug->dummy_page);
>   local_irq_restore(flags);
>  
> - if (!mem_cgroup_is_root(memcg))
> - css_put_many(>css, nr_pages);
> + if (!mem_cgroup_is_root(ug->memcg))
> + css_put_many(>memcg->css, nr_pages);
> +}
> +
> +static void uncharge_page(struct page *page, struct uncharge_gather *ug)
> +{
> + VM_BUG_ON_PAGE(PageLRU(page), page);
> + VM_BUG_ON_PAGE(!PageHWPoison(page) && page_count(page), page);
> +
> + if (!page->mem_cgroup)
> + return;
> +
> + /*
> +  * Nobody should be changing or seriously looking at
> +  * page->mem_cgroup at this point, we have fully
> +  * exclusive access to the page.
> +  */
> +
> + if (ug->memcg != page->mem_cgroup) {
> + if (ug->memcg) {
> + uncharge_batch(ug);

What is ug->dummy_page set to at this point? ug->dummy_page is assigned below

> + uncharge_gather_clear(ug);
> + }
> + ug->memcg = page->mem_cgroup;
> + }
> +
> + if (!PageKmemcg(page)) {
> + unsigned int nr_pages = 1;
> +
> + if (PageTransHuge(page)) {
> + nr_pages <<= 

Re: [HMM-CDM 3/5] mm/memcontrol: allow to uncharge page without using page->lru field

[Balbir Singh]

On Wed, 14 Jun 2017 16:11:42 -0400
Jérôme Glisse  wrote:

> HMM pages (private or public device pages) are ZONE_DEVICE page and
> thus you can not use page->lru fields of those pages. This patch
> re-arrange the uncharge to allow single page to be uncharge without
> modifying the lru field of the struct page.
> 
> There is no change to memcontrol logic, it is the same as it was
> before this patch.
> 
> Signed-off-by: Jérôme Glisse 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Vladimir Davydov 
> Cc: cgro...@vger.kernel.org
> ---
>  mm/memcontrol.c | 168 
> +++-
>  1 file changed, 92 insertions(+), 76 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index e3fe4d0..b93f5fe 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5509,48 +5509,102 @@ void mem_cgroup_cancel_charge(struct page *page, 
> struct mem_cgroup *memcg,
>   cancel_charge(memcg, nr_pages);
>  }
>  
> -static void uncharge_batch(struct mem_cgroup *memcg, unsigned long pgpgout,
> -unsigned long nr_anon, unsigned long nr_file,
> -unsigned long nr_kmem, unsigned long nr_huge,
> -unsigned long nr_shmem, struct page *dummy_page)
> +struct uncharge_gather {
> + struct mem_cgroup *memcg;
> + unsigned long pgpgout;
> + unsigned long nr_anon;
> + unsigned long nr_file;
> + unsigned long nr_kmem;
> + unsigned long nr_huge;
> + unsigned long nr_shmem;
> + struct page *dummy_page;
> +};
> +
> +static inline void uncharge_gather_clear(struct uncharge_gather *ug)
>  {
> - unsigned long nr_pages = nr_anon + nr_file + nr_kmem;
> + memset(ug, 0, sizeof(*ug));
> +}
> +
> +static void uncharge_batch(const struct uncharge_gather *ug)
> +{

Can we pass page as an argument so that we can do check events on the page?

> + unsigned long nr_pages = ug->nr_anon + ug->nr_file + ug->nr_kmem;
>   unsigned long flags;
>  
> - if (!mem_cgroup_is_root(memcg)) {
> - page_counter_uncharge(>memory, nr_pages);
> + if (!mem_cgroup_is_root(ug->memcg)) {
> + page_counter_uncharge(>memcg->memory, nr_pages);
>   if (do_memsw_account())
> - page_counter_uncharge(>memsw, nr_pages);
> - if (!cgroup_subsys_on_dfl(memory_cgrp_subsys) && nr_kmem)
> - page_counter_uncharge(>kmem, nr_kmem);
> - memcg_oom_recover(memcg);
> + page_counter_uncharge(>memcg->memsw, nr_pages);
> + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys) && ug->nr_kmem)
> + page_counter_uncharge(>memcg->kmem, ug->nr_kmem);
> + memcg_oom_recover(ug->memcg);
>   }
>  
>   local_irq_save(flags);
> - __this_cpu_sub(memcg->stat->count[MEMCG_RSS], nr_anon);
> - __this_cpu_sub(memcg->stat->count[MEMCG_CACHE], nr_file);
> - __this_cpu_sub(memcg->stat->count[MEMCG_RSS_HUGE], nr_huge);
> - __this_cpu_sub(memcg->stat->count[NR_SHMEM], nr_shmem);
> - __this_cpu_add(memcg->stat->events[PGPGOUT], pgpgout);
> - __this_cpu_add(memcg->stat->nr_page_events, nr_pages);
> - memcg_check_events(memcg, dummy_page);
> + __this_cpu_sub(ug->memcg->stat->count[MEMCG_RSS], ug->nr_anon);
> + __this_cpu_sub(ug->memcg->stat->count[MEMCG_CACHE], ug->nr_file);
> + __this_cpu_sub(ug->memcg->stat->count[MEMCG_RSS_HUGE], ug->nr_huge);
> + __this_cpu_sub(ug->memcg->stat->count[NR_SHMEM], ug->nr_shmem);
> + __this_cpu_add(ug->memcg->stat->events[PGPGOUT], ug->pgpgout);
> + __this_cpu_add(ug->memcg->stat->nr_page_events, nr_pages);
> + memcg_check_events(ug->memcg, ug->dummy_page);
>   local_irq_restore(flags);
>  
> - if (!mem_cgroup_is_root(memcg))
> - css_put_many(>css, nr_pages);
> + if (!mem_cgroup_is_root(ug->memcg))
> + css_put_many(>memcg->css, nr_pages);
> +}
> +
> +static void uncharge_page(struct page *page, struct uncharge_gather *ug)
> +{
> + VM_BUG_ON_PAGE(PageLRU(page), page);
> + VM_BUG_ON_PAGE(!PageHWPoison(page) && page_count(page), page);
> +
> + if (!page->mem_cgroup)
> + return;
> +
> + /*
> +  * Nobody should be changing or seriously looking at
> +  * page->mem_cgroup at this point, we have fully
> +  * exclusive access to the page.
> +  */
> +
> + if (ug->memcg != page->mem_cgroup) {
> + if (ug->memcg) {
> + uncharge_batch(ug);

What is ug->dummy_page set to at this point? ug->dummy_page is assigned below

> + uncharge_gather_clear(ug);
> + }
> + ug->memcg = page->mem_cgroup;
> + }
> +
> + if (!PageKmemcg(page)) {
> + unsigned int nr_pages = 1;
> +
> + if (PageTransHuge(page)) {
> + nr_pages <<= compound_order(page);
> + ug->nr_huge += nr_pages;
> + }
> +   

Re: [PATCH] mm, memory_hotplug: support movable_node for hotplugable nodes

[Wei Yang]

On Thu, Jun 08, 2017 at 02:23:18PM +0200, Michal Hocko wrote:
>From: Michal Hocko 
>
>movable_node kernel parameter allows to make hotplugable NUMA
>nodes to put all the hotplugable memory into movable zone which
>allows more or less reliable memory hotremove.  At least this
>is the case for the NUMA nodes present during the boot (see
>find_zone_movable_pfns_for_nodes).
>
>This is not the case for the memory hotplug, though.
>
>   echo online > /sys/devices/system/memory/memoryXYZ/status
>
>will default to a kernel zone (usually ZONE_NORMAL) unless the
>particular memblock is already in the movable zone range which is not
>the case normally when onlining the memory from the udev rule context
>for a freshly hotadded NUMA node. The only option currently is to have a
>special udev rule to echo online_movable to all memblocks belonging to
>such a node which is rather clumsy. Not the mention this is inconsistent
>as well because what ended up in the movable zone during the boot will
>end up in a kernel zone after hotremove & hotadd without special care.
>
>It would be nice to reuse memblock_is_hotpluggable but the runtime
>hotplug doesn't have that information available because the boot and
>hotplug paths are not shared and it would be really non trivial to
>make them use the same code path because the runtime hotplug doesn't
>play with the memblock allocator at all.
>
>Teach move_pfn_range that MMOP_ONLINE_KEEP can use the movable zone if
>movable_node is enabled and the range doesn't overlap with the existing
>normal zone. This should provide a reasonable default onlining strategy.
>
>Strictly speaking the semantic is not identical with the boot time
>initialization because find_zone_movable_pfns_for_nodes covers only the
>hotplugable range as described by the BIOS/FW. From my experience this
>is usually a full node though (except for Node0 which is special and
>never goes away completely). If this turns out to be a problem in the
>real life we can tweak the code to store hotplug flag into memblocks
>but let's keep this simple now.
>
>Signed-off-by: Michal Hocko 
>---
>
>Hi Andrew,
>I've posted this as an RFC previously [1] and there haven't been any
>objections to the approach so I've dropped the RFC and sending it for
>inclusion. The only change since the last time is the update of the
>documentation to clarify the semantic as suggested by Reza Arbab.
>
>[1] http://lkml.kernel.org/r/20170601122004.32732-1-mho...@kernel.org
>
> Documentation/memory-hotplug.txt | 12 +---
> mm/memory_hotplug.c  | 19 ---
> 2 files changed, 25 insertions(+), 6 deletions(-)
>
>diff --git a/Documentation/memory-hotplug.txt 
>b/Documentation/memory-hotplug.txt
>index 670f3ded0802..5c628e19d6cd 100644
>--- a/Documentation/memory-hotplug.txt
>+++ b/Documentation/memory-hotplug.txt
>@@ -282,20 +282,26 @@ offlined it is possible to change the individual block's 
>state by writing to the
> % echo online > /sys/devices/system/memory/memoryXXX/state
> 
> This onlining will not change the ZONE type of the target memory block,
>-If the memory block is in ZONE_NORMAL, you can change it to ZONE_MOVABLE:
>+If the memory block doesn't belong to any zone an appropriate kernel zone
>+(usually ZONE_NORMAL) will be used unless movable_node kernel command line
>+option is specified when ZONE_MOVABLE will be used.
>+
>+You can explicitly request to associate it with ZONE_MOVABLE by
> 
> % echo online_movable > /sys/devices/system/memory/memoryXXX/state
> (NOTE: current limit: this memory block must be adjacent to ZONE_MOVABLE)
> 
>-And if the memory block is in ZONE_MOVABLE, you can change it to ZONE_NORMAL:
>+Or you can explicitly request a kernel zone (usually ZONE_NORMAL) by:
> 
> % echo online_kernel > /sys/devices/system/memory/memoryXXX/state
> (NOTE: current limit: this memory block must be adjacent to ZONE_NORMAL)
> 
>+An explicit zone onlining can fail (e.g. when the range is already within
>+and existing and incompatible zone already).
>+
> After this, memory block XXX's state will be 'online' and the amount of
> available memory will be increased.
> 
>-Currently, newly added memory is added as ZONE_NORMAL (for powerpc, ZONE_DMA).
> This may be changed in future.
> 
> 
>diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>index b98fb0b3ae11..74d75583736c 100644
>--- a/mm/memory_hotplug.c
>+++ b/mm/memory_hotplug.c
>@@ -943,6 +943,19 @@ struct zone *default_zone_for_pfn(int nid, unsigned long 
>start_pfn,
>   return >node_zones[ZONE_NORMAL];
> }
> 
>+static inline bool movable_pfn_range(int nid, struct zone *default_zone,
>+  unsigned long start_pfn, unsigned long nr_pages)
>+{
>+  if (!allow_online_pfn_range(nid, start_pfn, nr_pages,
>+  MMOP_ONLINE_KERNEL))
>+  return true;
>+
>+  if (!movable_node_is_enabled())
>+  return false;
>+
>+  return !zone_intersects(default_zone, start_pfn, 

Re: [PATCH] mm, memory_hotplug: support movable_node for hotplugable nodes

[Wei Yang]

On Thu, Jun 08, 2017 at 02:23:18PM +0200, Michal Hocko wrote:
>From: Michal Hocko 
>
>movable_node kernel parameter allows to make hotplugable NUMA
>nodes to put all the hotplugable memory into movable zone which
>allows more or less reliable memory hotremove.  At least this
>is the case for the NUMA nodes present during the boot (see
>find_zone_movable_pfns_for_nodes).
>
>This is not the case for the memory hotplug, though.
>
>   echo online > /sys/devices/system/memory/memoryXYZ/status
>
>will default to a kernel zone (usually ZONE_NORMAL) unless the
>particular memblock is already in the movable zone range which is not
>the case normally when onlining the memory from the udev rule context
>for a freshly hotadded NUMA node. The only option currently is to have a
>special udev rule to echo online_movable to all memblocks belonging to
>such a node which is rather clumsy. Not the mention this is inconsistent
>as well because what ended up in the movable zone during the boot will
>end up in a kernel zone after hotremove & hotadd without special care.
>
>It would be nice to reuse memblock_is_hotpluggable but the runtime
>hotplug doesn't have that information available because the boot and
>hotplug paths are not shared and it would be really non trivial to
>make them use the same code path because the runtime hotplug doesn't
>play with the memblock allocator at all.
>
>Teach move_pfn_range that MMOP_ONLINE_KEEP can use the movable zone if
>movable_node is enabled and the range doesn't overlap with the existing
>normal zone. This should provide a reasonable default onlining strategy.
>
>Strictly speaking the semantic is not identical with the boot time
>initialization because find_zone_movable_pfns_for_nodes covers only the
>hotplugable range as described by the BIOS/FW. From my experience this
>is usually a full node though (except for Node0 which is special and
>never goes away completely). If this turns out to be a problem in the
>real life we can tweak the code to store hotplug flag into memblocks
>but let's keep this simple now.
>
>Signed-off-by: Michal Hocko 
>---
>
>Hi Andrew,
>I've posted this as an RFC previously [1] and there haven't been any
>objections to the approach so I've dropped the RFC and sending it for
>inclusion. The only change since the last time is the update of the
>documentation to clarify the semantic as suggested by Reza Arbab.
>
>[1] http://lkml.kernel.org/r/20170601122004.32732-1-mho...@kernel.org
>
> Documentation/memory-hotplug.txt | 12 +---
> mm/memory_hotplug.c  | 19 ---
> 2 files changed, 25 insertions(+), 6 deletions(-)
>
>diff --git a/Documentation/memory-hotplug.txt 
>b/Documentation/memory-hotplug.txt
>index 670f3ded0802..5c628e19d6cd 100644
>--- a/Documentation/memory-hotplug.txt
>+++ b/Documentation/memory-hotplug.txt
>@@ -282,20 +282,26 @@ offlined it is possible to change the individual block's 
>state by writing to the
> % echo online > /sys/devices/system/memory/memoryXXX/state
> 
> This onlining will not change the ZONE type of the target memory block,
>-If the memory block is in ZONE_NORMAL, you can change it to ZONE_MOVABLE:
>+If the memory block doesn't belong to any zone an appropriate kernel zone
>+(usually ZONE_NORMAL) will be used unless movable_node kernel command line
>+option is specified when ZONE_MOVABLE will be used.
>+
>+You can explicitly request to associate it with ZONE_MOVABLE by
> 
> % echo online_movable > /sys/devices/system/memory/memoryXXX/state
> (NOTE: current limit: this memory block must be adjacent to ZONE_MOVABLE)
> 
>-And if the memory block is in ZONE_MOVABLE, you can change it to ZONE_NORMAL:
>+Or you can explicitly request a kernel zone (usually ZONE_NORMAL) by:
> 
> % echo online_kernel > /sys/devices/system/memory/memoryXXX/state
> (NOTE: current limit: this memory block must be adjacent to ZONE_NORMAL)
> 
>+An explicit zone onlining can fail (e.g. when the range is already within
>+and existing and incompatible zone already).
>+
> After this, memory block XXX's state will be 'online' and the amount of
> available memory will be increased.
> 
>-Currently, newly added memory is added as ZONE_NORMAL (for powerpc, ZONE_DMA).
> This may be changed in future.
> 
> 
>diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>index b98fb0b3ae11..74d75583736c 100644
>--- a/mm/memory_hotplug.c
>+++ b/mm/memory_hotplug.c
>@@ -943,6 +943,19 @@ struct zone *default_zone_for_pfn(int nid, unsigned long 
>start_pfn,
>   return >node_zones[ZONE_NORMAL];
> }
> 
>+static inline bool movable_pfn_range(int nid, struct zone *default_zone,
>+  unsigned long start_pfn, unsigned long nr_pages)
>+{
>+  if (!allow_online_pfn_range(nid, start_pfn, nr_pages,
>+  MMOP_ONLINE_KERNEL))
>+  return true;
>+
>+  if (!movable_node_is_enabled())
>+  return false;
>+
>+  return !zone_intersects(default_zone, start_pfn, nr_pages);
>+}
>+

To be honest, 

Re: [PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

[Tim Savannah]

Any comments? Can we get this merged, or some variation? It affects a
lot more than just all my machines. Google shows this traceback is
occurring for others as well.

On Mon, May 29, 2017 at 12:57 AM, Tim Savannah  wrote:
> Oops, sent last one without patch on accident. Attached this time.
>
>
> This has been happening for me since 4.10
>
> dquot_writeback_dquots expects a lock to be held on super_block->s_umount ,
>
> and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not
> obtain such a lock.
>
> Thus, the following warning is generated:
>
> [Sun May 28 04:58:06 2017] [ cut here ]
> [Sun May 28 04:58:06 2017] WARNING: CPU: 0 PID: 31 at
> fs/quota/dquot.c:620 dquot_writeback_dquots+0x248/0x250
> [Sun May 28 04:58:06 2017] Modules linked in: bbswitch(O)
> nls_iso8859_1 nls_cp437 iTCO_wdt iTCO_vendor_support acer_wmi
> sparse_keymap coretemp efi_pstore hwmon intel_rapl
> x86_pkg_temp_thermal intel_powerclamp pcspkr ath9k ath9k_common
> ath9k_hw ath efivars mac80211 joydev psmouse i2c_i801 cfg80211
> input_leds led_class nvidiafb vgastate fb_ddc atl1c i915
> drm_kms_helper drm intel_gtt syscopyarea sysfillrect sysimgblt mei_me
> fb_sys_fops i2c_algo_bit mei lpc_ich shpchp acpi_cpufreq thermal wmi
> video tpm_tis tpm_tis_core button tpm sch_fq_codel evdev mac_hid
> uvcvideo vboxnetflt(O) videobuf2_vmalloc videobuf2_memops
> vboxnetadp(O) videobuf2_v4l2 videobuf2_core pci_stub videodev
> vboxpci(O) media ath3k btusb btrtl btbcm btintel vboxdrv(O) bluetooth
> rfkill loop usbip_host usbip_core sg ip_tables x_tables hid_generic
> usbhid
> [Sun May 28 04:58:06 2017]  hid sr_mod cdrom sd_mod serio_raw atkbd
> libps2 ehci_pci xhci_pci ahci xhci_hcd ehci_hcd libahci libata
> scsi_mod usbcore usb_common i8042 serio raid1 raid0 dm_mod md_mod
> [Sun May 28 04:58:06 2017] CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: G
>   O4.11.3-1-ck2-ck #1
> [Sun May 28 04:58:06 2017] Hardware name: Acer Aspire V3-771/VA70_HC,
> BIOS V2.16 01/14/2013
> [Sun May 28 04:58:06 2017] Workqueue: events_long flush_old_commits
> [Sun May 28 04:58:06 2017] Call Trace:
> [Sun May 28 04:58:06 2017]  ? dump_stack+0x5c/0x7a
> [Sun May 28 04:58:06 2017]  ? __warn+0xb4/0xd0
> [Sun May 27 04:58:06 2017]  ? dquot_writeback_dquots+0x248/0x250
> [Sun May 27 04:58:06 2017]  ? reiserfs_sync_fs+0x12/0x70
> [Sun May 27 04:58:06 2017]  ? dbs_work_handler+0x3d/0x50
> [Sun May 27 04:58:06 2017]  ? flush_old_commits+0x30/0x50
> [Sun May 27 04:58:06 2017]  ? process_one_work+0x1b1/0x3a0
> [Sun May 27 04:58:06 2017]  ? worker_thread+0x42/0x4c0
> [Sun May 27 04:58:06 2017]  ? kthread+0xf2/0x130
> [Sun May 27 04:58:06 2017]  ? process_one_work+0x3a0/0x3a0
> [Sun May 27 04:58:06 2017]  ? kthread_create_on_node+0x40/0x40
> [Sun May 27 04:58:06 2017]  ? ret_from_fork+0x26/0x40
> [Sun May 27 04:58:06 2017] ---[ end trace 7e040d020ba99607 ]---
>
>
> This occurs during system boot on a fully-updated Archlinux system,
> and has so since 4.10 100% of the time. It may occur after as well,
> but it's a WARN_ONCE.
>
> The attached patch corrects this issue by first trying to obtain a
> readlock on said structure member, and if it got it, releases it
> before returning.
>
> After applying the patch, my system is completely stable and the
> warning no longer occurs. Mounting and unmounting works as expected
> without issue.
>
> Thanks,
> - Tim Savannah

Re: [PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

[Tim Savannah]

Any comments? Can we get this merged, or some variation? It affects a
lot more than just all my machines. Google shows this traceback is
occurring for others as well.

On Mon, May 29, 2017 at 12:57 AM, Tim Savannah  wrote:
> Oops, sent last one without patch on accident. Attached this time.
>
>
> This has been happening for me since 4.10
>
> dquot_writeback_dquots expects a lock to be held on super_block->s_umount ,
>
> and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not
> obtain such a lock.
>
> Thus, the following warning is generated:
>
> [Sun May 28 04:58:06 2017] [ cut here ]
> [Sun May 28 04:58:06 2017] WARNING: CPU: 0 PID: 31 at
> fs/quota/dquot.c:620 dquot_writeback_dquots+0x248/0x250
> [Sun May 28 04:58:06 2017] Modules linked in: bbswitch(O)
> nls_iso8859_1 nls_cp437 iTCO_wdt iTCO_vendor_support acer_wmi
> sparse_keymap coretemp efi_pstore hwmon intel_rapl
> x86_pkg_temp_thermal intel_powerclamp pcspkr ath9k ath9k_common
> ath9k_hw ath efivars mac80211 joydev psmouse i2c_i801 cfg80211
> input_leds led_class nvidiafb vgastate fb_ddc atl1c i915
> drm_kms_helper drm intel_gtt syscopyarea sysfillrect sysimgblt mei_me
> fb_sys_fops i2c_algo_bit mei lpc_ich shpchp acpi_cpufreq thermal wmi
> video tpm_tis tpm_tis_core button tpm sch_fq_codel evdev mac_hid
> uvcvideo vboxnetflt(O) videobuf2_vmalloc videobuf2_memops
> vboxnetadp(O) videobuf2_v4l2 videobuf2_core pci_stub videodev
> vboxpci(O) media ath3k btusb btrtl btbcm btintel vboxdrv(O) bluetooth
> rfkill loop usbip_host usbip_core sg ip_tables x_tables hid_generic
> usbhid
> [Sun May 28 04:58:06 2017]  hid sr_mod cdrom sd_mod serio_raw atkbd
> libps2 ehci_pci xhci_pci ahci xhci_hcd ehci_hcd libahci libata
> scsi_mod usbcore usb_common i8042 serio raid1 raid0 dm_mod md_mod
> [Sun May 28 04:58:06 2017] CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: G
>   O4.11.3-1-ck2-ck #1
> [Sun May 28 04:58:06 2017] Hardware name: Acer Aspire V3-771/VA70_HC,
> BIOS V2.16 01/14/2013
> [Sun May 28 04:58:06 2017] Workqueue: events_long flush_old_commits
> [Sun May 28 04:58:06 2017] Call Trace:
> [Sun May 28 04:58:06 2017]  ? dump_stack+0x5c/0x7a
> [Sun May 28 04:58:06 2017]  ? __warn+0xb4/0xd0
> [Sun May 27 04:58:06 2017]  ? dquot_writeback_dquots+0x248/0x250
> [Sun May 27 04:58:06 2017]  ? reiserfs_sync_fs+0x12/0x70
> [Sun May 27 04:58:06 2017]  ? dbs_work_handler+0x3d/0x50
> [Sun May 27 04:58:06 2017]  ? flush_old_commits+0x30/0x50
> [Sun May 27 04:58:06 2017]  ? process_one_work+0x1b1/0x3a0
> [Sun May 27 04:58:06 2017]  ? worker_thread+0x42/0x4c0
> [Sun May 27 04:58:06 2017]  ? kthread+0xf2/0x130
> [Sun May 27 04:58:06 2017]  ? process_one_work+0x3a0/0x3a0
> [Sun May 27 04:58:06 2017]  ? kthread_create_on_node+0x40/0x40
> [Sun May 27 04:58:06 2017]  ? ret_from_fork+0x26/0x40
> [Sun May 27 04:58:06 2017] ---[ end trace 7e040d020ba99607 ]---
>
>
> This occurs during system boot on a fully-updated Archlinux system,
> and has so since 4.10 100% of the time. It may occur after as well,
> but it's a WARN_ONCE.
>
> The attached patch corrects this issue by first trying to obtain a
> readlock on said structure member, and if it got it, releases it
> before returning.
>
> After applying the patch, my system is completely stable and the
> warning no longer occurs. Mounting and unmounting works as expected
> without issue.
>
> Thanks,
> - Tim Savannah

Re: [PATCH v4 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

[Shawn Guo]

+Leonard, in case he wants to have a look.

One small comment below ...

On Fri, Jun 09, 2017 at 04:07:35PM +0200, Oleksij Rempel wrote:
> One of the Freescale recommended sequences for power off with external
> PMIC is the following:
> ...
> 3.  SoC is programming PMIC for power off when standby is asserted.
> 4.  In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.
> 
> See:
> http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf
> page 5083
> 
> This patch implements step 4. of this sequence.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  arch/arm/mach-imx/pm-imx6.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
> index e61b1d1027e1..3a4f8f289f4d 100644
> --- a/arch/arm/mach-imx/pm-imx6.c
> +++ b/arch/arm/mach-imx/pm-imx6.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 

How are these headers used?

Shawn

>  
>  #include "common.h"
>  #include "hardware.h"
> @@ -602,6 +604,28 @@ static void __init imx6_pm_common_init(const struct 
> imx6_pm_socdata
>  IMX6Q_GPR1_GINT);
>  }
>  
> +static void imx6_pm_poweroff(void)
> +{
> + imx6_set_lpm(STOP_POWER_OFF);
> + cpu_suspend(0, imx6q_suspend_finish);
> +
> + mdelay(1000);
> +
> + pr_emerg("Unable to poweroff system\n");
> +}
> +
> +static int imx6_pm_poweroff_probe(void)
> +{
> + if (pm_power_off) {
> + pr_warn("%s: pm_power_off already claimed  %p %pf!\n",
> + __func__, pm_power_off, pm_power_off);
> + return -EBUSY;
> + }
> +
> + pm_power_off = imx6_pm_poweroff;
> + return 0;
> +}
> +
>  void __init imx6_pm_ccm_init(const char *ccm_compat)
>  {
>   struct device_node *np;
> @@ -618,6 +642,9 @@ void __init imx6_pm_ccm_init(const char *ccm_compat)
>   val = readl_relaxed(ccm_base + CLPCR);
>   val &= ~BM_CLPCR_LPM;
>   writel_relaxed(val, ccm_base + CLPCR);
> +
> + if (of_property_read_bool(np, "fsl,pmic-stby-poweroff"))
> + imx6_pm_poweroff_probe();
>  }
>  
>  void __init imx6q_pm_init(void)
> -- 
> 2.11.0
> 

Re: [PATCH v4 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

[Shawn Guo]

+Leonard, in case he wants to have a look.

One small comment below ...

On Fri, Jun 09, 2017 at 04:07:35PM +0200, Oleksij Rempel wrote:
> One of the Freescale recommended sequences for power off with external
> PMIC is the following:
> ...
> 3.  SoC is programming PMIC for power off when standby is asserted.
> 4.  In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.
> 
> See:
> http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf
> page 5083
> 
> This patch implements step 4. of this sequence.
> 
> Signed-off-by: Oleksij Rempel 
> ---
>  arch/arm/mach-imx/pm-imx6.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
> index e61b1d1027e1..3a4f8f289f4d 100644
> --- a/arch/arm/mach-imx/pm-imx6.c
> +++ b/arch/arm/mach-imx/pm-imx6.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 

How are these headers used?

Shawn

>  
>  #include "common.h"
>  #include "hardware.h"
> @@ -602,6 +604,28 @@ static void __init imx6_pm_common_init(const struct 
> imx6_pm_socdata
>  IMX6Q_GPR1_GINT);
>  }
>  
> +static void imx6_pm_poweroff(void)
> +{
> + imx6_set_lpm(STOP_POWER_OFF);
> + cpu_suspend(0, imx6q_suspend_finish);
> +
> + mdelay(1000);
> +
> + pr_emerg("Unable to poweroff system\n");
> +}
> +
> +static int imx6_pm_poweroff_probe(void)
> +{
> + if (pm_power_off) {
> + pr_warn("%s: pm_power_off already claimed  %p %pf!\n",
> + __func__, pm_power_off, pm_power_off);
> + return -EBUSY;
> + }
> +
> + pm_power_off = imx6_pm_poweroff;
> + return 0;
> +}
> +
>  void __init imx6_pm_ccm_init(const char *ccm_compat)
>  {
>   struct device_node *np;
> @@ -618,6 +642,9 @@ void __init imx6_pm_ccm_init(const char *ccm_compat)
>   val = readl_relaxed(ccm_base + CLPCR);
>   val &= ~BM_CLPCR_LPM;
>   writel_relaxed(val, ccm_base + CLPCR);
> +
> + if (of_property_read_bool(np, "fsl,pmic-stby-poweroff"))
> + imx6_pm_poweroff_probe();
>  }
>  
>  void __init imx6q_pm_init(void)
> -- 
> 2.11.0
> 

Investment portfolio

[Hassan Dako]

Hello,

How are you today?

we have the financial capability to finance any investment portfolio as far as 
is it genuine, all we need is a capable business partner that possesses 
investment strategies or profitable business information for good turn over 
within 10-20years.

We can provide proof of funds on demand Please write me back if you can work 
with me on this project.

Thank You,

Best Regards
Hassan Dako

Investment portfolio

[Hassan Dako]

Hello,

How are you today?

we have the financial capability to finance any investment portfolio as far as 
is it genuine, all we need is a capable business partner that possesses 
investment strategies or profitable business information for good turn over 
within 10-20years.

We can provide proof of funds on demand Please write me back if you can work 
with me on this project.

Thank You,

Best Regards
Hassan Dako