[PATCH] arm64: dts: ls1012a: enable PCIe on freeway board

[Mian Yousaf Kaukab]

ls1012a-freeway board contains a M.2 2230 slot. Update the status of
pcei1 node to okay so that the pcie controller can be probed.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
index 6290e2f9de6a..e3f371788f85 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts
@@ -38,3 +38,7 @@ w25q16dw0: flash@0 {
spi-tx-bus-width = <2>;
};
 };
+
+ {
+   status = "okay";
+};
-- 
2.26.2

[PATCH net] netsec: restore phy power state after controller reset

[Mian Yousaf Kaukab]

Since commit 8e850f25b581 ("net: socionext: Stop PHY before resetting
netsec") netsec_netdev_init() power downs phy before resetting the
controller. However, the state is not restored once the reset is
complete. As a result it is not possible to bring up network on a
platform with Broadcom BCM5482 phy.

Fix the issue by restoring phy power state after controller reset is
complete.

Fixes: 8e850f25b581 ("net: socionext: Stop PHY before resetting netsec")
Cc: sta...@vger.kernel.org
Signed-off-by: Mian Yousaf Kaukab 
---
 drivers/net/ethernet/socionext/netsec.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/socionext/netsec.c 
b/drivers/net/ethernet/socionext/netsec.c
index 3c53051bdacf..200785e703c8 100644
--- a/drivers/net/ethernet/socionext/netsec.c
+++ b/drivers/net/ethernet/socionext/netsec.c
@@ -1715,14 +1715,17 @@ static int netsec_netdev_init(struct net_device *ndev)
goto err1;
 
/* set phy power down */
-   data = netsec_phy_read(priv->mii_bus, priv->phy_addr, MII_BMCR) |
-   BMCR_PDOWN;
-   netsec_phy_write(priv->mii_bus, priv->phy_addr, MII_BMCR, data);
+   data = netsec_phy_read(priv->mii_bus, priv->phy_addr, MII_BMCR);
+   netsec_phy_write(priv->mii_bus, priv->phy_addr, MII_BMCR,
+data | BMCR_PDOWN);
 
ret = netsec_reset_hardware(priv, true);
if (ret)
goto err2;
 
+   /* Restore phy power state */
+   netsec_phy_write(priv->mii_bus, priv->phy_addr, MII_BMCR, data);
+
spin_lock_init(>desc_ring[NETSEC_RING_TX].lock);
spin_lock_init(>desc_ring[NETSEC_RING_RX].lock);
 
-- 
2.26.2

Re: dwc: tegra194: issue with card containing a bridge

[Mian Yousaf Kaukab]

On Thu, Dec 17, 2020 at 06:06:35PM +0100, Mian Yousaf Kaukab wrote:
> On Thu, Dec 17, 2020 at 08:58:57AM -0600, Rob Herring wrote:
> > On Tue, Dec 15, 2020 at 09:52:35PM +0100, Mian Yousaf Kaukab wrote:
> > > On Tue, Dec 15, 2020 at 09:41:47AM -0600, Rob Herring wrote:
> > > > On Tue, Dec 15, 2020 at 02:25:04PM +0100, Mian Yousaf Kaukab wrote:
> > > > > On Tue, Dec 15, 2020 at 05:45:59PM +0530, Vidya Sagar wrote:
> > > > > > Thanks Mian for bringing it to our notice.
> > > > > > Have you tried removing the dw_pcie_setup_rc(pp); call from 
> > > > > > pcie-tegra194.c
> > > > > > file on top of linux-next? and does that solve the issue?
> > > > > > 
> > > > > > diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > > b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > > index 5597b2a49598..1c9e9c054592 100644
> > > > > > --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > > +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > > @@ -907,7 +907,7 @@ static void tegra_pcie_prepare_host(struct 
> > > > > > pcie_port
> > > > > > *pp)
> > > > > > dw_pcie_writel_dbi(pci, 
> > > > > > CFG_TIMER_CTRL_MAX_FUNC_NUM_OFF,
> > > > > > val);
> > > > > > }
> > > > > > 
> > > > > > -   dw_pcie_setup_rc(pp);
> > > > > > +   //dw_pcie_setup_rc(pp);
> > > > > I still see the same issue with this change.
> > > > > Reverting b9ac0f9dc8ea works though.
> > > > > > 
> > > > > > clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ);
> > > > > > 
> > > > > > I took a quick look at the dw_pcie_setup_rc() implementation and 
> > > > > > I'm not
> > > > > > sure why calling it second time should create any issue for the 
> > > > > > enumeration
> > > > > > of devices behind a switch. Perhaps I need to spend more time to 
> > > > > > debug that
> > > > > > part.
> > > > > > In any case, since dw_pcie_setup_rc() is already part of
> > > > > > dw_pcie_host_init(), I think it can be removed from
> > > > > > tegra_pcie_prepare_host() implemention.
> > > > 
> > > > I think the 2nd time is making the link go down is my guess. Tegra was 
> > > > odd in that its start/stop link functions don't do link handling, so I 
> > > > didn't implement those functions and left the link handling in the 
> > > > Tegra 
> > > > driver.
> > > > 
> > > > Can you try the below patch. It needs some more work as it breaks 
> > > > endpoint mode.
> > 
> > [...]
> > 
> > > Boot is ok with this patch. Some improvement in lspci as well:
> > 
> > Some improvement? Meaning not completely working still?
> > 
> > > # lspci
> > > 0001:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad2 (rev a1)
> > > 0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 
> > > (rev 13)
> > > 0005:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad0 (rev a1)
> > > 0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
> > 
> > This patch was closer to the original flow, but would not have worked if 
> > DLFE disabled mode was needed.
> > 
> > Please give this patch a try:
> Thank you for the patch! Initial results with it looks very promising.
> I’ll get back to you tomorrow after running a few more tests.
Rob, thank you for your efforts! This patch fixed the issue I was seeing. FWIW:

Tested-by: Mian Yousaf Kaukab 

BR,
Yousaf

Re: dwc: tegra194: issue with card containing a bridge

[Mian Yousaf Kaukab]

On Thu, Dec 17, 2020 at 08:58:57AM -0600, Rob Herring wrote:
> On Tue, Dec 15, 2020 at 09:52:35PM +0100, Mian Yousaf Kaukab wrote:
> > On Tue, Dec 15, 2020 at 09:41:47AM -0600, Rob Herring wrote:
> > > On Tue, Dec 15, 2020 at 02:25:04PM +0100, Mian Yousaf Kaukab wrote:
> > > > On Tue, Dec 15, 2020 at 05:45:59PM +0530, Vidya Sagar wrote:
> > > > > Thanks Mian for bringing it to our notice.
> > > > > Have you tried removing the dw_pcie_setup_rc(pp); call from 
> > > > > pcie-tegra194.c
> > > > > file on top of linux-next? and does that solve the issue?
> > > > > 
> > > > > diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > index 5597b2a49598..1c9e9c054592 100644
> > > > > --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > > @@ -907,7 +907,7 @@ static void tegra_pcie_prepare_host(struct 
> > > > > pcie_port
> > > > > *pp)
> > > > > dw_pcie_writel_dbi(pci, 
> > > > > CFG_TIMER_CTRL_MAX_FUNC_NUM_OFF,
> > > > > val);
> > > > > }
> > > > > 
> > > > > -   dw_pcie_setup_rc(pp);
> > > > > +   //dw_pcie_setup_rc(pp);
> > > > I still see the same issue with this change.
> > > > Reverting b9ac0f9dc8ea works though.
> > > > > 
> > > > > clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ);
> > > > > 
> > > > > I took a quick look at the dw_pcie_setup_rc() implementation and I'm 
> > > > > not
> > > > > sure why calling it second time should create any issue for the 
> > > > > enumeration
> > > > > of devices behind a switch. Perhaps I need to spend more time to 
> > > > > debug that
> > > > > part.
> > > > > In any case, since dw_pcie_setup_rc() is already part of
> > > > > dw_pcie_host_init(), I think it can be removed from
> > > > > tegra_pcie_prepare_host() implemention.
> > > 
> > > I think the 2nd time is making the link go down is my guess. Tegra was 
> > > odd in that its start/stop link functions don't do link handling, so I 
> > > didn't implement those functions and left the link handling in the Tegra 
> > > driver.
> > > 
> > > Can you try the below patch. It needs some more work as it breaks 
> > > endpoint mode.
> 
> [...]
> 
> > Boot is ok with this patch. Some improvement in lspci as well:
> 
> Some improvement? Meaning not completely working still?
> 
> > # lspci
> > 0001:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad2 (rev a1)
> > 0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 
> > (rev 13)
> > 0005:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad0 (rev a1)
> > 0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
> 
> This patch was closer to the original flow, but would not have worked if 
> DLFE disabled mode was needed.
> 
> Please give this patch a try:
Thank you for the patch! Initial results with it looks very promising.
I’ll get back to you tomorrow after running a few more tests.

BR,
Yousaf

Re: dwc: tegra194: issue with card containing a bridge

[Mian Yousaf Kaukab]

On Tue, Dec 15, 2020 at 09:41:47AM -0600, Rob Herring wrote:
> On Tue, Dec 15, 2020 at 02:25:04PM +0100, Mian Yousaf Kaukab wrote:
> > On Tue, Dec 15, 2020 at 05:45:59PM +0530, Vidya Sagar wrote:
> > > Thanks Mian for bringing it to our notice.
> > > Have you tried removing the dw_pcie_setup_rc(pp); call from 
> > > pcie-tegra194.c
> > > file on top of linux-next? and does that solve the issue?
> > > 
> > > diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > index 5597b2a49598..1c9e9c054592 100644
> > > --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > @@ -907,7 +907,7 @@ static void tegra_pcie_prepare_host(struct pcie_port
> > > *pp)
> > > dw_pcie_writel_dbi(pci, CFG_TIMER_CTRL_MAX_FUNC_NUM_OFF,
> > > val);
> > > }
> > > 
> > > -   dw_pcie_setup_rc(pp);
> > > +   //dw_pcie_setup_rc(pp);
> > I still see the same issue with this change.
> > Reverting b9ac0f9dc8ea works though.
> > > 
> > > clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ);
> > > 
> > > I took a quick look at the dw_pcie_setup_rc() implementation and I'm not
> > > sure why calling it second time should create any issue for the 
> > > enumeration
> > > of devices behind a switch. Perhaps I need to spend more time to debug 
> > > that
> > > part.
> > > In any case, since dw_pcie_setup_rc() is already part of
> > > dw_pcie_host_init(), I think it can be removed from
> > > tegra_pcie_prepare_host() implemention.
> 
> I think the 2nd time is making the link go down is my guess. Tegra was 
> odd in that its start/stop link functions don't do link handling, so I 
> didn't implement those functions and left the link handling in the Tegra 
> driver.
> 
> Can you try the below patch. It needs some more work as it breaks 
> endpoint mode.
> 
> 8<
> 
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c 
> b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 648e731bccfa..49bb487b16ae 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -907,9 +907,32 @@ static void tegra_pcie_prepare_host(struct pcie_port *pp)
>   dw_pcie_writel_dbi(pci, CFG_TIMER_CTRL_MAX_FUNC_NUM_OFF, val);
>   }
>  
> - dw_pcie_setup_rc(pp);
> -
>   clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ);
> +}
> +
> +static int tegra_pcie_dw_host_init(struct pcie_port *pp)
> +{
> + pp->bridge->ops = _pci_ops;
> +
> + tegra_pcie_prepare_host(pp);
> + tegra_pcie_enable_interrupts(pp);
> +
> + return 0;
> +}
> +
> +static int tegra_pcie_dw_link_up(struct dw_pcie *pci)
> +{
> + struct tegra_pcie_dw *pcie = to_tegra_pcie(pci);
> + u32 val = dw_pcie_readw_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKSTA);
> +
> + return !!(val & PCI_EXP_LNKSTA_DLLLA);
> +}
> +
> +static int tegra_pcie_dw_start_link(struct dw_pcie *pci)
> +{
> + u32 val, offset, speed, tmp;
> + struct tegra_pcie_dw *pcie = to_tegra_pcie(pci);
> + struct pcie_port *pp = >pp;
>  
>   /* Assert RST */
>   val = appl_readl(pcie, APPL_PINMUX);
> @@ -929,17 +952,6 @@ static void tegra_pcie_prepare_host(struct pcie_port *pp)
>   appl_writel(pcie, val, APPL_PINMUX);
>  
>   msleep(100);
> -}
> -
> -static int tegra_pcie_dw_host_init(struct pcie_port *pp)
> -{
> - struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> - struct tegra_pcie_dw *pcie = to_tegra_pcie(pci);
> - u32 val, tmp, offset, speed;
> -
> - pp->bridge->ops = _pci_ops;
> -
> - tegra_pcie_prepare_host(pp);
>  
>   if (dw_pcie_wait_for_link(pci)) {
>   /*
> @@ -975,7 +987,8 @@ static int tegra_pcie_dw_host_init(struct pcie_port *pp)
>   val &= ~PCI_DLF_EXCHANGE_ENABLE;
>   dw_pcie_writel_dbi(pci, offset, val);
>  
> - tegra_pcie_prepare_host(pp);
> + tegra_pcie_dw_host_init(pp);
> + dw_pcie_setup_rc(pp);
>  
>   if (dw_pcie_wait_for_link(pci))
>   return 0;
> @@ -985,25 +998,6 @@ static int tegra_pcie_dw_host_init(struct pcie_port *pp)
>   PCI_EXP_LNKSTA_CLS;
>   clk_set_rate(pcie->core_clk, pcie_gen_freq[speed - 1]);
>  
> - tegra_pcie_enable_interrupts(pp);
> -
> - return 0;
> -}
>

Re: dwc: tegra194: issue with card containing a bridge

[Mian Yousaf Kaukab]

On Tue, Dec 15, 2020 at 01:44:21PM -0600, Rob Herring wrote:
> On Tue, Dec 15, 2020 at 09:41:47AM -0600, Rob Herring wrote:
> > On Tue, Dec 15, 2020 at 02:25:04PM +0100, Mian Yousaf Kaukab wrote:
> > > On Tue, Dec 15, 2020 at 05:45:59PM +0530, Vidya Sagar wrote:
> > > > Thanks Mian for bringing it to our notice.
> > > > Have you tried removing the dw_pcie_setup_rc(pp); call from 
> > > > pcie-tegra194.c
> > > > file on top of linux-next? and does that solve the issue?
> > > > 
> > > > diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > index 5597b2a49598..1c9e9c054592 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> > > > @@ -907,7 +907,7 @@ static void tegra_pcie_prepare_host(struct pcie_port
> > > > *pp)
> > > > dw_pcie_writel_dbi(pci, CFG_TIMER_CTRL_MAX_FUNC_NUM_OFF,
> > > > val);
> > > > }
> > > > 
> > > > -   dw_pcie_setup_rc(pp);
> > > > +   //dw_pcie_setup_rc(pp);
> > > I still see the same issue with this change.
> > > Reverting b9ac0f9dc8ea works though.
> > > > 
> > > > clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ);
> > > > 
> > > > I took a quick look at the dw_pcie_setup_rc() implementation and I'm not
> > > > sure why calling it second time should create any issue for the 
> > > > enumeration
> > > > of devices behind a switch. Perhaps I need to spend more time to debug 
> > > > that
> > > > part.
> > > > In any case, since dw_pcie_setup_rc() is already part of
> > > > dw_pcie_host_init(), I think it can be removed from
> > > > tegra_pcie_prepare_host() implemention.
> > 
> > I think the 2nd time is making the link go down is my guess. Tegra was 
> > odd in that its start/stop link functions don't do link handling, so I 
> > didn't implement those functions and left the link handling in the Tegra 
> > driver.
> > 
> > Can you try the below patch. It needs some more work as it breaks 
> > endpoint mode.
> 
> That one missed some re-init. Try this one instead
> 
> 8<
> 
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c 
> b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 5597b2a49598..d8fed3561e91 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -933,14 +933,24 @@ static void tegra_pcie_prepare_host(struct pcie_port 
> *pp)
>  
>  static int tegra_pcie_dw_host_init(struct pcie_port *pp)
>  {
> - struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> - struct tegra_pcie_dw *pcie = to_tegra_pcie(pci);
> - u32 val, tmp, offset, speed;
> -
>   pp->bridge->ops = _pci_ops;
>  
>   tegra_pcie_prepare_host(pp);
>  
> + return 0;
> +}
> +
> +static int tegra_pcie_dw_start_link(struct dw_pcie *pci)
> +{
> + u32 val, offset, speed, tmp;
> + struct tegra_pcie_dw *pcie = to_tegra_pcie(pci);
> + struct pcie_port *pp = >pp;
> +
> + if (pcie->mode == DW_PCIE_EP_TYPE) {
> + enable_irq(pcie->pex_rst_irq);
> + return 0;
> + }
> +
>   if (dw_pcie_wait_for_link(pci)) {
>   /*
>* There are some endpoints which can't get the link up if
> @@ -998,15 +1008,6 @@ static int tegra_pcie_dw_link_up(struct dw_pcie *pci)
>   return !!(val & PCI_EXP_LNKSTA_DLLLA);
>  }
>  
> -static int tegra_pcie_dw_start_link(struct dw_pcie *pci)
> -{
> - struct tegra_pcie_dw *pcie = to_tegra_pcie(pci);
> -
> - enable_irq(pcie->pex_rst_irq);
> -
> - return 0;
> -}
> -
>  static void tegra_pcie_dw_stop_link(struct dw_pcie *pci)
>  {
>   struct tegra_pcie_dw *pcie = to_tegra_pcie(pci);
With USB3380 card PTM enabled... is the last message I see. It doesn't
boot further:
[9.124500] tegra194-pcie 141a.pcie: iATU unroll: enabled
[9.130310] tegra194-pcie 141a.pcie: Detected iATU regions: 8 outbound, 
2 inbound
[9.138915] tegra194-pcie 141a.pcie: Link up
[9.144940] tegra194-pcie 141a.pcie: PCI host bridge to bus 0005:00
[9.151849] pci_bus 0005:00: root bus resource [bus 00-ff]
[9.157595] pci_bus 0005:00: root bus resource [mem 
0x1c-0x1f3fff pref]
[9.165509] pci_bus 0005:00: root bus resource [mem 
0x1f4000-0x1e] (bu

Re: dwc: tegra194: issue with card containing a bridge

[Mian Yousaf Kaukab]

On Tue, Dec 15, 2020 at 05:45:59PM +0530, Vidya Sagar wrote:
> Thanks Mian for bringing it to our notice.
> Have you tried removing the dw_pcie_setup_rc(pp); call from pcie-tegra194.c
> file on top of linux-next? and does that solve the issue?
> 
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
> b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 5597b2a49598..1c9e9c054592 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -907,7 +907,7 @@ static void tegra_pcie_prepare_host(struct pcie_port
> *pp)
> dw_pcie_writel_dbi(pci, CFG_TIMER_CTRL_MAX_FUNC_NUM_OFF,
> val);
> }
> 
> -   dw_pcie_setup_rc(pp);
> +   //dw_pcie_setup_rc(pp);
I still see the same issue with this change.
Reverting b9ac0f9dc8ea works though.
> 
> clk_set_rate(pcie->core_clk, GEN4_CORE_CLK_FREQ);
> 
> I took a quick look at the dw_pcie_setup_rc() implementation and I'm not
> sure why calling it second time should create any issue for the enumeration
> of devices behind a switch. Perhaps I need to spend more time to debug that
> part.
> In any case, since dw_pcie_setup_rc() is already part of
> dw_pcie_host_init(), I think it can be removed from
> tegra_pcie_prepare_host() implemention.
> 
> Thanks,
> Vidya Sagar
> 
BR,
Yousaf

dwc: tegra194: issue with card containing a bridge

[Mian Yousaf Kaukab]

Hi,
I am seeing an issue with next-20201211 with USB3380[1] based PCIe card
(vid:pid 10b5:3380) on Jetson AGX Xavier. Card doesn't show up in the
lspci output.

In non working case (next-20201211):
# lspci
0001:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad2 (rev a1)
0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13)
0005:00:00.0 PCI bridge: NVIDIA Corporation Device 1ad0 (rev a1)

In working case (v5.10-rc7):
# lspci
0001:00:00.0 PCI bridge: Molex Incorporated Device 1ad2 (rev a1)
0001:01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9171 (rev 13)
0005:00:00.0 PCI bridge: Molex Incorporated Device 1ad0 (rev a1)
0005:01:00.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
0005:02:02.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
0005:03:00.0 USB controller: PLX Technology, Inc. Device 3380 (rev ab)
# lspci -t
-+-[0005:00]---00.0-[01-ff]00.0-[02-03]02.0-[03]00.0
 +-[0001:00]---00.0-[01-ff]00.0
 \-[:00]-
#lspci -v
https://paste.opensuse.org/87573209

git-bisect points to commit b9ac0f9dc8ea ("PCI: dwc: Move dw_pcie_setup_rc() to 
DWC common code").
dw_pcie_setup_rc() is not removed from pcie-tegra194.c in this commit.

Could the failure be caused because dw_pcie_setup_rc() is called twice now in 
case of tegra194?

BR,
Yousaf

[1]: 
https://www.broadcom.com/products/pcie-switches-bridges/usb-pci/usb-controllers/usb3380

Re: [PATCH v2 0/4] cppc_cpufreq: fix, clarify and improve support

[Mian Yousaf Kaukab]

On Mon, Dec 14, 2020 at 12:38:19PM +, Ionela Voinescu wrote:
> Hi guys,
> 
> I'm sending v2 of some of the patches at [1] in light of the discussions
> at [2].
> 
> v2:
>  - Patches 1-3 are trivial rebase on linux next 20201211, with conflicts
>fixed after eliminating what previously was "[PATCH 4/8] cppc_cpufreq:
>replace per-cpu structures with lists." Therefore, I have kept
>Viresh's acks.
> 
>  - Patch 4 is a merge between:
>  - [PATCH 4/8] cppc_cpufreq: replace per-cpu structures with lists
>  - [PATCH] cppc_cpufreq: optimise memory allocation for HW and NONE
>coordination
>both found at [1].
> 
>This functionality was introducing the problem at [2] and it's fixed
>in this version by bailing out of driver registration if a _CPC entry
>is not found for a CPU.
> 
>Yousaf, it would be great if you can test this and make sure it
>matches your expectations.
> 
>Rafael, Viresh if you think this last patch introduces too many
>changes, you can skip it for 5.11 which is around the corner and
>have more time for review for 5.12. I've added more eyes in the review
>list.
> 
> 
> All patches are based on linux next 20201211 after patch at [3] is
> applied.
> 
> [1] 
> https://lore.kernel.org/linux-pm/20201105125524.4409-1-ionela.voine...@arm.com/#t
> [2] 
> https://lore.kernel.org/linux-pm/20201210142139.20490-1-yousaf.kau...@suse.com/
> [3] 
> https://lore.kernel.org/linux-pm/20201214120740.10948-1-ionela.voine...@arm.com/
> 
> Ionela Voinescu (4):
>   cppc_cpufreq: use policy->cpu as driver of frequency setting
>   cppc_cpufreq: clarify support for coordination types
>   cppc_cpufreq: expose information on frequency domains
>   cppc_cpufreq: replace per-cpu data array with a list
> 
>  .../ABI/testing/sysfs-devices-system-cpu  |   3 +-
>  drivers/acpi/cppc_acpi.c  | 141 ++--
>  drivers/cpufreq/cppc_cpufreq.c| 204 ++++++----
>  include/acpi/cppc_acpi.h  |   6 +-
>  4 files changed, 181 insertions(+), 173 deletions(-)

For the whole series:
Tested-by: Mian Yousaf Kaukab 

Re: [PATCH 1/2] acpi: cppc: add cpufreq device

[Mian Yousaf Kaukab]

On Thu, Dec 10, 2020 at 03:32:09PM +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 10, 2020 at 3:23 PM Mian Yousaf Kaukab
>  wrote:
> >
> > Convert cppc-cpufreq driver to a platform driver (done in a separate patch)
> > and add cppc-cpufreq device when acpi_cppc_processor_probe() succeeds.
> 
> Honestly, I prefer to drop 28f06f770454 (along with its follower)
> instead of making this change.
> 
Even if we revert 28f06f770454 there is still one more small issue that these
patches fix. Currently, ACPI_PROCESSOR_DEVICE_HID is used to load cppc-cpufreq
module. In case when CPPC is disabled, some cycles will be wasted in loading
cppc-cpufreq module. The module will return error from the init call though
so no memory is wasted.

After converting to platform-driver, cppc-cpufreq module will only be loaded
when the platform-device is available.

BR,
Yousaf

[PATCH 2/2] cpufreq: cppc: convert to a platform driver

[Mian Yousaf Kaukab]

From: Mian Yousaf Kaukab 

Instead of piggybacking on ACPI_PROCESSOR_DEVICE_HID, convert the driver
to a proper platform driver with its own ID. Driver will only be probed
when cppc-cpufreq device is available.

Fixes: 28f06f770454 ("cppc_cpufreq: replace per-cpu structures with lists")
Signed-off-by: Mian Yousaf Kaukab 
---
 drivers/cpufreq/cppc_cpufreq.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index bb4c068601db..defac1dd9a2a 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -11,13 +11,13 @@
 #define pr_fmt(fmt)"CPPC Cpufreq:" fmt
 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -512,7 +512,7 @@ static void cppc_check_hisi_workaround(void)
acpi_put_table(tbl);
 }
 
-static int __init cppc_cpufreq_init(void)
+static int cppc_cpufreq_probe(struct platform_device *pdev)
 {
if (acpi_disabled)
return -ENODEV;
@@ -533,26 +533,27 @@ static inline void free_cpu_data(void)
list_del(>node);
kfree(iter);
}
-
 }
 
-static void __exit cppc_cpufreq_exit(void)
+static int cppc_cpufreq_remove(struct platform_device *pdev)
 {
cpufreq_unregister_driver(_cpufreq_driver);
 
free_cpu_data();
+
+   return 0;
 }
 
-module_exit(cppc_cpufreq_exit);
+static struct platform_driver cppc_cpufreq_platform_driver = {
+   .driver = {
+   .name = "cppc-cpufreq",
+   },
+   .probe = cppc_cpufreq_probe,
+   .remove = cppc_cpufreq_remove,
+};
+module_platform_driver(cppc_cpufreq_platform_driver);
+
+MODULE_ALIAS("platform:cppc-cpufreq");
 MODULE_AUTHOR("Ashwin Chaugule");
 MODULE_DESCRIPTION("CPUFreq driver based on the ACPI CPPC v5.0+ spec");
 MODULE_LICENSE("GPL");
-
-late_initcall(cppc_cpufreq_init);
-
-static const struct acpi_device_id cppc_acpi_ids[] __used = {
-   {ACPI_PROCESSOR_DEVICE_HID, },
-   {}
-};
-
-MODULE_DEVICE_TABLE(acpi, cppc_acpi_ids);
-- 
2.26.2

[PATCH 1/2] acpi: cppc: add cpufreq device

[Mian Yousaf Kaukab]

From: Mian Yousaf Kaukab 

Since commit 28f06f770454 ("cppc_cpufreq: replace per-cpu structures with
lists"), cppc-cpufreq driver doesn't check availability of PSD data before
registering with cpufreq core. As a result on a ThunderX2 platform when
CPPC is disabled from BIOS, kernel log is spammed with following messages:

[  180.974166] CPPC Cpufreq: Error in acquiring _CPC/_PSD data for CPUxx

acpi_cppc_processor_probe() never succeed in this case because
acpi_evaluate_object_typed("_CPC") always returns AE_NOT_FOUND. When
cpufreq core calls cppc_cpufreq_cpu_init(), driver fails to obtain PSD data
and print error messages.

Convert cppc-cpufreq driver to a platform driver (done in a separate patch)
and add cppc-cpufreq device when acpi_cppc_processor_probe() succeeds.

Fixes: 28f06f770454 ("cppc_cpufreq: replace per-cpu structures with lists")
Reported-by: Petr Cervinka 
Signed-off-by: Mian Yousaf Kaukab 
---
 drivers/acpi/cppc_acpi.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 4e478f751ff7..adf9ca3be9fe 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -606,6 +607,23 @@ static bool is_cppc_supported(int revision, int num_ent)
return true;
 }
 
+static void add_cppc_cpufreq_dev(void)
+{
+   static bool already_added;
+
+   if (!already_added) {
+   struct platform_device *pdev;
+
+   pdev = platform_device_register_simple("cppc-cpufreq", -1,
+   NULL, 0);
+   if (IS_ERR(pdev))
+   pr_err("Couldn't register cppc-cpufreq err=%ld\n",
+   PTR_ERR(pdev));
+   else
+   already_added = true;
+   }
+}
+
 /*
  * An example CPC table looks like the following.
  *
@@ -815,6 +833,9 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
}
 
kfree(output.pointer);
+
+   add_cppc_cpufreq_dev();
+
return 0;
 
 out_free:
-- 
2.26.2

[PATCH] PCI: cadence: Fix cdns_pcie_host_setup() error path

[Mian Yousaf Kaukab]

commit 19abcd790b51 ("PCI: cadence: Fix cdns_pcie_{host|ep}_setup() error
path") removed pm_runtime_put_sync() call from the error path in
cdns_pcie_{host|ep}_setup(). However, the hunk in cdns_pcie_host_setup()
got lost.

Fix error path in cdns_pcie_host_setup() by removing pm_runtime_put_sync()
call.

Fixes: 24344226f66b ("PCI: cadence: Use struct pci_host_bridge.windows list 
directly")
Cc: sta...@vger.kernel.org
Signed-off-by: Mian Yousaf Kaukab 
---
 drivers/pci/controller/cadence/pcie-cadence-host.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c 
b/drivers/pci/controller/cadence/pcie-cadence-host.c
index 811c1cb2e8de..6e2557653943 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
@@ -471,14 +471,5 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
if (!bridge->ops)
bridge->ops = _pcie_host_ops;
 
-   ret = pci_host_probe(bridge);
-   if (ret < 0)
-   goto err_init;
-
-   return 0;
-
- err_init:
-   pm_runtime_put_sync(dev);
-
-   return ret;
+   return pci_host_probe(bridge);
 }
-- 
2.26.2

[PATCH] coresight: fix offset by one error in counting ports

[Mian Yousaf Kaukab]

Since port-numbers start from 0, add 1 to port-number to get the port
count.

Fix following crash when Coresight is enabled on ACPI based systems:

[   61.061736] Unable to handle kernel NULL pointer dereference at virtual 
address 0008
...
[   61.135494] pc : acpi_coresight_parse_graph+0x1c4/0x37c
[   61.140705] lr : acpi_coresight_parse_graph+0x160/0x37c
[   61.145915] sp : 800012f4ba40
[   61.145917] x29: 800012f4ba40 x28: 00becce62f98
[   61.159896] x27: 0005 x26: 00becd8a7c88
[   61.165195] x25: 00becd8a7d88 x24: 00becce62f80
[   61.170492] x23: 800011ef99c0 x22: 009efb8bc010
[   61.175790] x21: 0018 x20: 0005
[   61.181087] x19: 00becce62e80 x18: 0020
[   61.186385] x17: 0001 x16: 02a8
[   61.191682] x15: 000838648550 x14: 
[   61.196980] x13:  x12: 00becce62d87
[   61.202277] x11: ff76 x10: 002e
[   61.207575] x9 : 8000107e1a68 x8 : 00becce63000
[   61.212873] x7 : 0018 x6 : 003f
[   61.218170] x5 :  x4 : 
[   61.223467] x3 :  x2 : 
[   61.228764] x1 : 00becce62f80 x0 : 
[   61.234062] Call trace:
[   61.236497]  acpi_coresight_parse_graph+0x1c4/0x37c
[   61.241361]  coresight_get_platform_data+0xdc/0x130
[   61.246225]  tmc_probe+0x138/0x2dc
[   61.246227]  amba_probe+0xdc/0x220
[   61.255779]  really_probe+0xe8/0x49c
[   61.255781]  driver_probe_device+0xec/0x140
[   61.255782]  device_driver_attach+0xc8/0xd0
[   61.255785]  __driver_attach+0xac/0x180
[   61.265857]  bus_for_each_dev+0x78/0xcc
[   61.265859]  driver_attach+0x2c/0x40
[   61.265861]  bus_add_driver+0x150/0x244
[   61.265863]  driver_register+0x80/0x13c
[   61.273591]  amba_driver_register+0x60/0x70
[   61.273594]  tmc_driver_init+0x20/0x2c
[   61.281582]  do_one_initcall+0x50/0x230
[   61.281585]  do_initcalls+0x104/0x144
[   61.291831]  kernel_init_freeable+0x168/0x1dc
[   61.291834]  kernel_init+0x1c/0x120
[   61.299215]  ret_from_fork+0x10/0x18
[   61.299219] Code: b9400022 f9400660 9b277c42 8b02 (f9400404)
[   61.307381] ---[ end trace 63c6c3d7ec6a9b7c ]---
[   61.315225] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b

Fixes: d375b356e687 ("coresight: Fix support for sparsely populated ports")
Reported-by: Ruediger Oertel 
Signed-off-by: Mian Yousaf Kaukab 
---
 drivers/hwtracing/coresight/coresight-platform.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-platform.c 
b/drivers/hwtracing/coresight/coresight-platform.c
index bfd44231d7ad..227e234a2470 100644
--- a/drivers/hwtracing/coresight/coresight-platform.c
+++ b/drivers/hwtracing/coresight/coresight-platform.c
@@ -711,11 +711,11 @@ static int acpi_coresight_parse_graph(struct acpi_device 
*adev,
return dir;
 
if (dir == ACPI_CORESIGHT_LINK_MASTER) {
-   if (ptr->outport > pdata->nr_outport)
-   pdata->nr_outport = ptr->outport;
+   if (ptr->outport >= pdata->nr_outport)
+   pdata->nr_outport = ptr->outport + 1;
ptr++;
} else {
-   WARN_ON(pdata->nr_inport == ptr->child_port);
+   WARN_ON(pdata->nr_inport == ptr->child_port + 1);
/*
 * We do not track input port connections for a device.
 * However we need the highest port number described,
@@ -723,8 +723,8 @@ static int acpi_coresight_parse_graph(struct acpi_device 
*adev,
 * record for an output connection. Hence, do not move
 * the ptr for input connections
 */
-   if (ptr->child_port > pdata->nr_inport)
-   pdata->nr_inport = ptr->child_port;
+   if (ptr->child_port >= pdata->nr_inport)
+   pdata->nr_inport = ptr->child_port + 1;
}
}
 
-- 
2.26.2

[PATCH] coresight: fix offset by one error in counting ports

[Mian Yousaf Kaukab]

Since port-numbers start from 0, add 1 to port-number to get the port
count.

Fix following crash when Coresight is enabled on ACPI based systems:

[   61.061736] Unable to handle kernel NULL pointer dereference at virtual 
address 0008
...
[   61.135494] pc : acpi_coresight_parse_graph+0x1c4/0x37c
[   61.140705] lr : acpi_coresight_parse_graph+0x160/0x37c
[   61.145915] sp : 800012f4ba40
[   61.145917] x29: 800012f4ba40 x28: 00becce62f98
[   61.159896] x27: 0005 x26: 00becd8a7c88
[   61.165195] x25: 00becd8a7d88 x24: 00becce62f80
[   61.170492] x23: 800011ef99c0 x22: 009efb8bc010
[   61.175790] x21: 0018 x20: 0005
[   61.181087] x19: 00becce62e80 x18: 0020
[   61.186385] x17: 0001 x16: 02a8
[   61.191682] x15: 000838648550 x14: 
[   61.196980] x13:  x12: 00becce62d87
[   61.202277] x11: ff76 x10: 002e
[   61.207575] x9 : 8000107e1a68 x8 : 00becce63000
[   61.212873] x7 : 0018 x6 : 003f
[   61.218170] x5 :  x4 : 
[   61.223467] x3 :  x2 : 
[   61.228764] x1 : 00becce62f80 x0 : 
[   61.234062] Call trace:
[   61.236497]  acpi_coresight_parse_graph+0x1c4/0x37c
[   61.241361]  coresight_get_platform_data+0xdc/0x130
[   61.246225]  tmc_probe+0x138/0x2dc
[   61.246227]  amba_probe+0xdc/0x220
[   61.255779]  really_probe+0xe8/0x49c
[   61.255781]  driver_probe_device+0xec/0x140
[   61.255782]  device_driver_attach+0xc8/0xd0
[   61.255785]  __driver_attach+0xac/0x180
[   61.265857]  bus_for_each_dev+0x78/0xcc
[   61.265859]  driver_attach+0x2c/0x40
[   61.265861]  bus_add_driver+0x150/0x244
[   61.265863]  driver_register+0x80/0x13c
[   61.273591]  amba_driver_register+0x60/0x70
[   61.273594]  tmc_driver_init+0x20/0x2c
[   61.281582]  do_one_initcall+0x50/0x230
[   61.281585]  do_initcalls+0x104/0x144
[   61.291831]  kernel_init_freeable+0x168/0x1dc
[   61.291834]  kernel_init+0x1c/0x120
[   61.299215]  ret_from_fork+0x10/0x18
[   61.299219] Code: b9400022 f9400660 9b277c42 8b02 (f9400404)
[   61.307381] ---[ end trace 63c6c3d7ec6a9b7c ]---
[   61.315225] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b

Fixes: d375b356e687 ("coresight: Fix support for sparsely populated ports")
Reported-by: Ruediger Oertel 
Signed-off-by: Mian Yousaf Kaukab 
---
 drivers/hwtracing/coresight/coresight-platform.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-platform.c 
b/drivers/hwtracing/coresight/coresight-platform.c
index bfd44231d7ad..227e234a2470 100644
--- a/drivers/hwtracing/coresight/coresight-platform.c
+++ b/drivers/hwtracing/coresight/coresight-platform.c
@@ -711,11 +711,11 @@ static int acpi_coresight_parse_graph(struct acpi_device 
*adev,
return dir;
 
if (dir == ACPI_CORESIGHT_LINK_MASTER) {
-   if (ptr->outport > pdata->nr_outport)
-   pdata->nr_outport = ptr->outport;
+   if (ptr->outport >= pdata->nr_outport)
+   pdata->nr_outport = ptr->outport + 1;
ptr++;
} else {
-   WARN_ON(pdata->nr_inport == ptr->child_port);
+   WARN_ON(pdata->nr_inport == ptr->child_port + 1);
/*
 * We do not track input port connections for a device.
 * However we need the highest port number described,
@@ -723,8 +723,8 @@ static int acpi_coresight_parse_graph(struct acpi_device 
*adev,
 * record for an output connection. Hence, do not move
 * the ptr for input connections
 */
-   if (ptr->child_port > pdata->nr_inport)
-   pdata->nr_inport = ptr->child_port;
+   if (ptr->child_port >= pdata->nr_inport)
+   pdata->nr_inport = ptr->child_port + 1;
}
}
 
-- 
2.26.2

Re: [PATCH 2/4] dt-bindings: sram: add documentation for reserved-only flag

[Mian Yousaf Kaukab]

On Wed, May 20, 2020 at 10:55:58AM +0200, Thierry Reding wrote:
> On Tue, May 19, 2020 at 05:03:26PM -0600, Rob Herring wrote:
> > On Tue, May 19, 2020 at 10:16:43AM -0600, Stephen Warren wrote:
> > > On 5/13/20 4:41 AM, Mian Yousaf Kaukab wrote:
> > > > On Tue, May 12, 2020 at 01:45:28PM -0600, Stephen Warren wrote:
> > > >> On 5/12/20 8:48 AM, Mian Yousaf Kaukab wrote:
> > > >>> Add documentation for the new optional flag added for SRAM driver.
> > > >>
> > > >>> diff --git a/Documentation/devicetree/bindings/sram/sram.yaml 
> > > >>> b/Documentation/devicetree/bindings/sram/sram.yaml
> > > >>
> > > >>> +  reserved-only:
> > > >>> +description:
> > > >>> +  The flag indicating, that only SRAM reserved regions have to 
> > > >>> be remapped.
> > > >>> +  remapping type is selected depending upon no-memory-wc as 
> > > >>> usual.
> > > >>> +type: boolean
> > > >>
> > > >> This feels a bit like a SW flag rather than a HW description, so I'm 
> > > >> not
> > > >> sure it's appropriate to put it into DT.
> > > > 
> > > > Reserved regions themselves are software descriptions, no? Then we have 
> > > > 'pool'
> > > > flag which is again a software flag and so on. This flag falls into same
> > > > category and nothing out of ordinary.
> > > 
> > > I suppose that's true to some extent. This is indeed a description of
> > > the system environment presented to the SW that consumes the DT, which
> > > is a bit more than pure HW description but still a description of
> > > something imposed externally rather than describing something that's up
> > > to the discretion of the consuming SW. So, go ahead.
> > > 
> > > >> Are there any cases where the SW should map all of the SRAM, i.e. where
> > > >> we wouldn't expect to set reserved-only? [...]
> > > > 
> > > > Yes, here are a few examples:
> > > > arch/arm/boot/dts/aspeed-g*.dtsi
> > > > arch/arm/boot/dts/at91*.dtsi
> > > > arch/arm/boot/dts/bcm7445.dtsi
> > > > Then arch/arm/boot/dts/dra7.dtsi is an example where we should map 
> > > > everything
> > > > except the reserved region.
> > > > 
> > > >> [...] I'd expect reserved-only to be
> > > >> the default, and perhaps only, mode of operation for the SRAM driver.
> > > > 
> > > > It will break compatibility with existing dtbs.
> > > > 
> > > >> If we can't do that because some SW currently expects to be able to map
> > > >> arbitrary portions of the SRAM, shouldn't that SW be fixed to tell the
> > > >> SRAM driver which parts it's using, hence still allowing the driver to
> > > >> only map in-use portions?
> > > > 
> > > > User doesn’t need sram driver in that case. It can use genalloc api 
> > > > directly.
> > > 
> > > This sounds a bit odd. Without a driver for the reserved region, nothing
> > > should be touching it, since otherwise there's no code that owns an
> > > manages the region. If any code needs to consume the region, it should
> > > obtain info about the region from some form of provider code that can
> > > handle both the allocation and mapping. Anything else sounds like some
> > > consumer code directly making use of DT nodes it doesn't own. But since
> > > I'm not familiar enough with the SRAM driver and genalloc code that you
> > > mention to fully understand the allocation paths I guess I won't object
> > > for now, although it does still sound fishy.
> > 
> > I'm fine with the concept, but I don't think a single flag is adequate. 
> > If there are reserved regions within the SRAM, then define child nodes 
> > to mark those regions reserved. I don't think you need a new flag. Just 
> > a 'reg' property and nothing else.
> 
> It sounds to me like there are two different interpretations of SRAM and
> reserved regions. On one hand, as you suggest, we have one SRAM that's
> made available as genalloc pool and then individual regions can be
> marked as reserved so that they aren't added to that pool.
> 
> At the same time, each reserved region is also exposed as a separate
> pool and that's in fact used by many consumers as a way of getting a
> specific chunk of the SRAM for their own use (via phandle to the region

Re: [PATCH 2/4] dt-bindings: sram: add documentation for reserved-only flag

[Mian Yousaf Kaukab]

On Tue, May 12, 2020 at 01:45:28PM -0600, Stephen Warren wrote:
> On 5/12/20 8:48 AM, Mian Yousaf Kaukab wrote:
> > Add documentation for the new optional flag added for SRAM driver.
> 
> > diff --git a/Documentation/devicetree/bindings/sram/sram.yaml 
> > b/Documentation/devicetree/bindings/sram/sram.yaml
> 
> > +  reserved-only:
> > +description:
> > +  The flag indicating, that only SRAM reserved regions have to be 
> > remapped.
> > +  remapping type is selected depending upon no-memory-wc as usual.
> > +type: boolean
> 
> This feels a bit like a SW flag rather than a HW description, so I'm not
> sure it's appropriate to put it into DT.

Reserved regions themselves are software descriptions, no? Then we have 'pool'
flag which is again a software flag and so on. This flag falls into same
category and nothing out of ordinary.
> 
> Are there any cases where the SW should map all of the SRAM, i.e. where
> we wouldn't expect to set reserved-only? [...]

Yes, here are a few examples:
arch/arm/boot/dts/aspeed-g*.dtsi
arch/arm/boot/dts/at91*.dtsi
arch/arm/boot/dts/bcm7445.dtsi
Then arch/arm/boot/dts/dra7.dtsi is an example where we should map everything
except the reserved region.

> [...] I'd expect reserved-only to be
> the default, and perhaps only, mode of operation for the SRAM driver.

It will break compatibility with existing dtbs.

> If we can't do that because some SW currently expects to be able to map
> arbitrary portions of the SRAM, shouldn't that SW be fixed to tell the
> SRAM driver which parts it's using, hence still allowing the driver to
> only map in-use portions?

User doesn’t need sram driver in that case. It can use genalloc api directly.

BR,
Yousaf

[PATCH 3/4] arm64: tegra186: add reserved-only flag in sysram node

[Mian Yousaf Kaukab]

bpmp driver has reserved regions in sysram. Since sysram is only used
by the bpmp driver, add ‘reserved-only’ flag to the sysram node so
that only regions used by the bpmp driver are remapped. Other regions
of the sysram may not be accessible to the kernel and a speculative
access to them can cause SError.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 58100fb9cd8b..07ce7e7b270c 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1219,6 +1219,7 @@ sysram@3000 {
#address-cells = <2>;
#size-cells = <2>;
ranges = <0 0x0 0x0 0x3000 0x0 0x5>;
+   reserved-only;
 
cpu_bpmp_tx: shmem@4e000 {
compatible = "nvidia,tegra186-bpmp-shmem";
-- 
2.25.0

[PATCH 1/4] misc: sram: add support for remapping reserved regions only

[Mian Yousaf Kaukab]

Some SRAM kernel users may be interested in SRAM’s reserved regions
only, though a bigger SRAM is available on the platform. Add an
optional flag 'reserved-only' which allows to ioremap reserved regions
only. Rest of SRAM is not remapped. ioremap type is selected depending
upon no-memory-wc as usual.

Signed-off-by: Mian Yousaf Kaukab 
---
*Tested only on Jetson TX2. Jetson AGX Xavier is untested.*

 drivers/misc/sram.c | 73 ++---
 drivers/misc/sram.h |  3 ++
 2 files changed, 58 insertions(+), 18 deletions(-)

diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 6c1a23cb3e8c..44e459f39e22 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -97,7 +97,7 @@ static int sram_add_partition(struct sram_dev *sram, struct 
sram_reserve *block,
struct sram_partition *part = >partition[sram->partitions];
 
mutex_init(>lock);
-   part->base = sram->virt_base + block->start;
+   part->base = block->virt_start;
 
if (block->pool) {
ret = sram_add_pool(sram, block, start, part);
@@ -153,6 +153,25 @@ static int sram_reserve_cmp(void *priv, struct list_head 
*a,
return ra->start - rb->start;
 }
 
+static int sram_remap_resource(struct sram_dev *sram,
+   struct resource *res, void __iomem **virt)
+{
+   void __iomem *addr;
+
+   if (sram->no_memory_wc)
+   addr = devm_ioremap_resource(sram->dev, res);
+   else
+   addr = devm_ioremap_resource_wc(sram->dev, res);
+
+   if (IS_ERR(addr)) {
+   dev_err(sram->dev, "could not map SRAM region\n");
+   return PTR_ERR(addr);
+   }
+
+   *virt = addr;
+   return 0;
+}
+
 static int sram_reserve_regions(struct sram_dev *sram, struct resource *res)
 {
struct device_node *np = sram->dev->of_node, *child;
@@ -239,6 +258,16 @@ static int sram_reserve_regions(struct sram_dev *sram, 
struct resource *res)
block->start, block->start + block->size);
}
 
+   /* ioremap reserved block as whole sram is not remapped */
+   if (sram->reserved_only) {
+   ret = sram_remap_resource(sram, _res,
+   >virt_start);
+   if (ret)
+   goto err_chunks;
+   } else {
+   block->virt_start = sram->virt_base + block->start;
+   }
+
block++;
}
child = NULL;
@@ -282,8 +311,11 @@ static int sram_reserve_regions(struct sram_dev *sram, 
struct resource *res)
}
}
 
-   /* current start is in a reserved block, so continue after it */
-   if (block->start == cur_start) {
+   /*
+* Current start is in a reserved block, so continue after it.
+* Or if only using reserved blocks
+*/
+   if (block->start == cur_start || sram->reserved_only) {
cur_start = block->start + block->size;
continue;
}
@@ -342,6 +374,7 @@ static int sram_probe(struct platform_device *pdev)
struct sram_dev *sram;
int ret;
int (*init_func)(void);
+   struct resource *res;
 
sram = devm_kzalloc(>dev, sizeof(*sram), GFP_KERNEL);
if (!sram)
@@ -349,19 +382,22 @@ static int sram_probe(struct platform_device *pdev)
 
sram->dev = >dev;
 
-   if (of_property_read_bool(pdev->dev.of_node, "no-memory-wc"))
-   sram->virt_base = devm_platform_ioremap_resource(pdev, 0);
-   else
-   sram->virt_base = devm_platform_ioremap_resource_wc(pdev, 0);
-   if (IS_ERR(sram->virt_base)) {
-   dev_err(>dev, "could not map SRAM registers\n");
-   return PTR_ERR(sram->virt_base);
-   }
+   sram->no_memory_wc =
+   of_property_read_bool(pdev->dev.of_node, "no-memory-wc");
+   sram->reserved_only =
+   of_property_read_bool(pdev->dev.of_node, "reserved-only");
 
-   sram->pool = devm_gen_pool_create(sram->dev, ilog2(SRAM_GRANULARITY),
- NUMA_NO_NODE, NULL);
-   if (IS_ERR(sram->pool))
-   return PTR_ERR(sram->pool);
+   if (!sram->reserved_only) {
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   ret = sram_remap_resource(sram, res, >virt_base);
+   if (ret)
+   return ret;
+
+   sram->pool = devm_gen_pool_create(sram->dev,
+   ilog2(SRAM_GRANULARITY), NUMA_NO_NODE, NULL);
+   if (IS_ERR(sram

[PATCH 4/4] arm64: tegra194: add reserved-only flag in sysram node

[Mian Yousaf Kaukab]

bpmp driver has reserved regions in sysram. Since sysram is only used
by the bpmp driver, add ‘reserved-only’ flag to the sysram node so
that only regions used by the bpmp driver are remapped. Other regions
of the sysram may not be accessible to the kernel and a speculative
access to them can cause SError.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index e1ae01c2d039..9a5276d9c2a6 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1743,6 +1743,7 @@ sysram@4000 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x4000 0x5>;
+   reserved-only;
 
cpu_bpmp_tx: shmem@4e000 {
compatible = "nvidia,tegra194-bpmp-shmem";
-- 
2.25.0

[PATCH 2/4] dt-bindings: sram: add documentation for reserved-only flag

[Mian Yousaf Kaukab]

Add documentation for the new optional flag added for SRAM driver.

Signed-off-by: Mian Yousaf Kaukab 
---
 Documentation/devicetree/bindings/sram/sram.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/sram/sram.yaml 
b/Documentation/devicetree/bindings/sram/sram.yaml
index 19d116ff9ddc..4bcc309fa841 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -55,6 +55,12 @@ properties:
   as write combining. WC is used by default.
 type: boolean
 
+  reserved-only:
+description:
+  The flag indicating, that only SRAM reserved regions have to be remapped.
+  remapping type is selected depending upon no-memory-wc as usual.
+type: boolean
+
 patternProperties:
   "^([a-z]*-)?sram(-section)?@[a-f0-9]+$":
 type: object
-- 
2.25.0

Re: arm64: tegra186: bpmp: kernel crash while decompressing initrd

[Mian Yousaf Kaukab]

On Mon, May 11, 2020 at 12:25:00PM +0100, Robin Murphy wrote:
> On 2020-05-08 9:40 am, Mian Yousaf Kaukab wrote:
> > I am seeing following kernel crash on Jetson TX2. Board is flashed with
> > firmware bits from L4T R32.4.2 with upstream u-boot. Crash always
> > happens while decompressing initrd. Initrd is approximately 80 MiB in
> > size and compressed with xz (xz --check=crc32 --lzma2=dict=32MiB).
> > Crash is not observed if the same initrd is compressed with gzip.
> > [1] was a previous attempt to workaround the same issue.
> > 
> > [0.651168] Trying to unpack rootfs image as initramfs...
> > [2.890171] SError Interrupt on CPU0, code 0xbf40c000 -- SError
> > [2.890174] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G S
> > 5.7.0-rc4-next-20200505 #22
> > [2.890175] Hardware name: nvidia p2771-/p2771-, BIOS 
> > 2020.04-rc3 03/25/2020
> > [2.890176] pstate: 2005 (nzCv daif -PAN -UAO BTYPE=--)
> > [2.890177] pc : lzma_main+0x648/0x908
> > [2.890178] lr : lzma_main+0x330/0x908
> > [2.890179] sp : 80001003bb70
> > [2.890180] x29: 80001003bb70 x28: 04d794a4
> > [2.890183] x27: 04769941 x26: 0001eb064000
> > [2.890185] x25: 0001eb060028 x24: 0002
> > [2.890187] x23: 0003 x22: 0007
> > [2.890189] x21: 00611f4b x20: 0001eb06
> > [2.890192] x19: 80001003bcb8 x18: 0068
> > [2.890194] x17: 00c0 x16: fe00076b2108
> > [2.890196] x15: 0800 x14: 00ff
> > [2.890198] x13: 0001 x12: 0001eb06
> > [2.890200] x11: 0600 x10: 0001eb060028
> > [2.890202] x9 : ffbb2a08 x8 : 0ed0
> > [2.890204] x7 : 011553ec x6 : 
> > [2.890206] x5 :  x4 : 0006
> > [2.890208] x3 : 015a29e4 x2 : 0001eb062d0c
> > [2.890210] x1 : 000c x0 : 0263de44
> > 
> > With some debugging aid ported from Nvidia downstream kernel [2] the
> > actual cause was found:
> > 
> > [0.761525] Trying to unpack rootfs image as initramfs...
> > [2.955499] CPU0: SError: mpidr=0x8100, esr=0xbf40c000
> > [2.955502] CPU1: SError: mpidr=0x8000, esr=0xbe00
> > [2.955505] CPU2: SError: mpidr=0x8001, esr=0xbe00
> > [2.955506] CPU3: SError: mpidr=0x8101, esr=0xbf40c000
> > [2.955507] ROC:CCE Machine Check Error:
> > [2.955508] ROC:CCE Registers:
> > [2.955509]  STAT: 0xb4400415
> > [2.955510]  ADDR: 0x400c00e7a00c
> > [2.955511]  MSC1: 0x80ffc
> > [2.955512]  MSC2: 0x39800
> > [2.955513] --
> > [2.955514] Decoded ROC:CCE Machine Check:
> > [2.955515]  Uncorrected (this is fatal)
> > [2.955516]  Error reporting enabled when error arrived
> > [2.955517]  Error Code = 0x415
> > [2.955518]  Poison Error
> > [2.955518]  Command = NCRd (0xc)
> > [2.955519]  Address Type = Non-Secure DRAM
> > [2.955521]  Address = 0x30039e80 -- 3000.sysram + 0x39e80
> > [2.955521]  TLimit = 0x3ff
> > [2.955522]  Poison Error Mask = 0x80
> > [2.955523]  More Info = 0x800
> > [2.955524]  Timeout Info = 0x0
> > [2.955525]  Poison Info = 0x800
> > [2.955526]  Read Request failed GSC checks
> > [2.955527]  Source = L2_1 (A57) (0x1)
> > [2.955528]  TID = 0xe
> > 
> > IIUC, there was read request for 0x30039e80 from EL1/2 which failed.
> > This address falls in the sysram security aperture and hence a read
> > from normal mode failed.
> > 
> > sysram is mapped at 0x3000_ to 0x3004_ and is managed by the
> > sram driver (drivers/misc/sram.c). There are two reserved pools for
> > BPMP driver communication at 0x3004_e000 and 0x3004_f000 of 0x1000
> > bytes each.
> > 
> > sram driver maps complete 0x3000_ to 0x3004_ range as normal
> > memory.
> 
> That's your problem. It's not really worth attempting to reason about, the
> architecture says that anything mapped as Normal memory may be speculatively
> accessed at any time, so no amount of second-guessing is going to save you
> in general. Don't make stuff accessible to the kernel that it doesn't need
> to access, and especially don't make stuff accessible to the kernel if
> accessing it will kill the system.
> 
I agree and [1] was an attempt in that direction. What I wonder

arm64: tegra186: bpmp: kernel crash while decompressing initrd

[Mian Yousaf Kaukab]

I am seeing following kernel crash on Jetson TX2. Board is flashed with
firmware bits from L4T R32.4.2 with upstream u-boot. Crash always
happens while decompressing initrd. Initrd is approximately 80 MiB in
size and compressed with xz (xz --check=crc32 --lzma2=dict=32MiB).
Crash is not observed if the same initrd is compressed with gzip.
[1] was a previous attempt to workaround the same issue.

[0.651168] Trying to unpack rootfs image as initramfs...
[2.890171] SError Interrupt on CPU0, code 0xbf40c000 -- SError
[2.890174] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G S
5.7.0-rc4-next-20200505 #22
[2.890175] Hardware name: nvidia p2771-/p2771-, BIOS 2020.04-rc3 
03/25/2020
[2.890176] pstate: 2005 (nzCv daif -PAN -UAO BTYPE=--)
[2.890177] pc : lzma_main+0x648/0x908
[2.890178] lr : lzma_main+0x330/0x908
[2.890179] sp : 80001003bb70
[2.890180] x29: 80001003bb70 x28: 04d794a4
[2.890183] x27: 04769941 x26: 0001eb064000
[2.890185] x25: 0001eb060028 x24: 0002
[2.890187] x23: 0003 x22: 0007
[2.890189] x21: 00611f4b x20: 0001eb06
[2.890192] x19: 80001003bcb8 x18: 0068
[2.890194] x17: 00c0 x16: fe00076b2108
[2.890196] x15: 0800 x14: 00ff
[2.890198] x13: 0001 x12: 0001eb06
[2.890200] x11: 0600 x10: 0001eb060028
[2.890202] x9 : ffbb2a08 x8 : 0ed0
[2.890204] x7 : 011553ec x6 : 
[2.890206] x5 :  x4 : 0006
[2.890208] x3 : 015a29e4 x2 : 0001eb062d0c
[2.890210] x1 : 000c x0 : 0263de44

With some debugging aid ported from Nvidia downstream kernel [2] the
actual cause was found:

[0.761525] Trying to unpack rootfs image as initramfs...
[2.955499] CPU0: SError: mpidr=0x8100, esr=0xbf40c000
[2.955502] CPU1: SError: mpidr=0x8000, esr=0xbe00
[2.955505] CPU2: SError: mpidr=0x8001, esr=0xbe00
[2.955506] CPU3: SError: mpidr=0x8101, esr=0xbf40c000
[2.955507] ROC:CCE Machine Check Error:
[2.955508] ROC:CCE Registers:
[2.955509]  STAT: 0xb4400415
[2.955510]  ADDR: 0x400c00e7a00c
[2.955511]  MSC1: 0x80ffc
[2.955512]  MSC2: 0x39800
[2.955513] --
[2.955514] Decoded ROC:CCE Machine Check:
[2.955515]  Uncorrected (this is fatal)
[2.955516]  Error reporting enabled when error arrived
[2.955517]  Error Code = 0x415
[2.955518]  Poison Error
[2.955518]  Command = NCRd (0xc)
[2.955519]  Address Type = Non-Secure DRAM
[2.955521]  Address = 0x30039e80 -- 3000.sysram + 0x39e80
[2.955521]  TLimit = 0x3ff
[2.955522]  Poison Error Mask = 0x80
[2.955523]  More Info = 0x800
[2.955524]  Timeout Info = 0x0
[2.955525]  Poison Info = 0x800
[2.955526]  Read Request failed GSC checks
[2.955527]  Source = L2_1 (A57) (0x1)
[2.955528]  TID = 0xe

IIUC, there was read request for 0x30039e80 from EL1/2 which failed.
This address falls in the sysram security aperture and hence a read
from normal mode failed.

sysram is mapped at 0x3000_ to 0x3004_ and is managed by the
sram driver (drivers/misc/sram.c). There are two reserved pools for
BPMP driver communication at 0x3004_e000 and 0x3004_f000 of 0x1000
bytes each.

sram driver maps complete 0x3000_ to 0x3004_ range as normal
memory. However, only the BPMP reserved pools (0x3004_e000 - 0x3004_)
are accessible from the kernel. Address 0x3003_9e80 is inaccessible
from the kernel and a read to it (which I believe is speculative)
causes the SError. Only driver which uses sysram is not initialized at
this point (rootfs_initcall level). As since
commit d70f5e541ab3 ("firmware: tegra: Make BPMP a regular driver")
bpmp driver is initialized at device_initcall level.

If none of the drivers on the kernel side using 0x3003_9e80 address
range. Why a read to it occurs even speculatively? Could it be that
some EL3 software didn’t cleanup after itself properly? Any
suggestions on debugging this issue further?

Another solution suggested in [1] was to add no-memory-wc in sysram
node in device-tree so that sysram is mapped as device-memory. Thus
preventing any speculative access. However, it causes another set of
issues with the bpmp driver. That's may be a discussion for another
time.

BR,
Yousaf

[1]: https://lore.kernel.org/patchwork/patch/1132429/
[2]: git://nv-tegra.nvidia.com/linux-4.9.git

[PATCH] gpio: tegra186: export MODULE_DEVICE_TABLE

[Mian Yousaf Kaukab]

Export MODULE_DEVICE_TABLE since the driver can be built as a module.

Signed-off-by: Mian Yousaf Kaukab 
---
 drivers/gpio/gpio-tegra186.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-tegra186.c b/drivers/gpio/gpio-tegra186.c
index 79b553dc39a3..178e9128ded0 100644
--- a/drivers/gpio/gpio-tegra186.c
+++ b/drivers/gpio/gpio-tegra186.c
@@ -894,6 +894,7 @@ static const struct of_device_id tegra186_gpio_of_match[] = 
{
/* sentinel */
}
 };
+MODULE_DEVICE_TABLE(of, tegra186_gpio_of_match);
 
 static struct platform_driver tegra186_gpio_driver = {
.driver = {
-- 
2.25.0

Re: [PATCH] arm64: tegra: only map accessible sysram

[Mian Yousaf Kaukab]

On Sun, Sep 29, 2019 at 11:28:43PM -0600, Stephen Warren wrote:
> On 9/29/19 2:08 PM, Mian Yousaf Kaukab wrote:
> > Most of the SysRAM is secure and only accessible by TF-A.
> > Don't map this inaccessible memory in kernel. Only map pages
> > used by bpmp driver.
> 
> I don't believe this change is correct. The actual patch doesn't
> implement mapping a subset of the RAM (a software issue), but rather it
> changes the DT representation of the SYSRAM hardware. The SYSRAM
> hardware always does start at 0x3000, even if a subset of the
> address range is dedicated to a specific purpose. If the kernel must map
> only part of the RAM, then some additional property should indicate
> this.[...]
I agree the hardware description becomes inaccurate with this change.

In the current setup complete 0x3000_ to 0x3005_ range is being mapped
as normal memory (MT_NORMAL_NC). Though only 0x3004_E000 to 0x3005_ are
accessible by the kernel. I am seeing an issue where a read access (which I
believe is speculative) to inaccessible range causes an SError. Another 
solution for this problem could be to add "no-memory-wc" to SysRAM node so that
it is mapped as device memory (MT_DEVICE_nGnRE). Would that be acceptable?

> [...] Also, I believe it's incorrect to hard-code into the kernel's DT
> the range of addresses used by the secure monitor/OS, since this can
> vary depending on what the user actually chooses to install as the
> secure monitor/OS. Any indication of such regions should be filled in at
> runtime by some boot firmware or the secure monitor/OS itself, or
> retrieved using some runtime API rather than DT.
Secure-OS addresses are not of interest here. SysRAM is partitioned
between secure-OS and BPMP and kernel is only interested in the BPMP
part. The firmware can update these addresses in the device-tree if it
wants to. Would you prefer something similar implemented in u-boot so
that it updates SysRAM node to only expose kernel accessible part of it
to the kernel?

Can u-boot dynamically figure out the Secure-OS vs BPMP partition?

BR,
Yousaf

[PATCH] arm64: tegra: only map accessible sysram

[Mian Yousaf Kaukab]

Most of the SysRAM is secure and only accessible by TF-A.
Don't map this inaccessible memory in kernel. Only map pages
used by bpmp driver.

Signed-off-by: Mian Yousaf Kaukab 
---
Only tegra186 is tested. Tested on Jetson TX2.

 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 14 +++---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 14 +++---
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 47cd831fcf44..a861f46125fd 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1174,23 +1174,23 @@
power-domains = < TEGRA186_POWER_DOMAIN_GPU>;
};
 
-   sysram@3000 {
+   sysram@3004e000 {
compatible = "nvidia,tegra186-sysram", "mmio-sram";
-   reg = <0x0 0x3000 0x0 0x5>;
+   reg = <0x0 0x3004e000 0x0 0x2000>;
#address-cells = <2>;
#size-cells = <2>;
-   ranges = <0 0x0 0x0 0x3000 0x0 0x5>;
+   ranges = <0 0x0 0x0 0x3004e000 0x0 0x2000>;
 
-   cpu_bpmp_tx: shmem@4e000 {
+   cpu_bpmp_tx: shmem@e000 {
compatible = "nvidia,tegra186-bpmp-shmem";
-   reg = <0x0 0x4e000 0x0 0x1000>;
+   reg = <0x0 0x0 0x0 0x1000>;
label = "cpu-bpmp-tx";
pool;
};
 
-   cpu_bpmp_rx: shmem@4f000 {
+   cpu_bpmp_rx: shmem@f000 {
compatible = "nvidia,tegra186-bpmp-shmem";
-   reg = <0x0 0x4f000 0x0 0x1000>;
+   reg = <0x0 0x1000 0x0 0x1000>;
label = "cpu-bpmp-rx";
pool;
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 3c0cf54f0aab..98b9399d6b7f 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1430,23 +1430,23 @@
  0x8200 0x0  0x4000 0x1f 0x4000 0x0 
0xc000>; /* non-prefetchable memory (3GB) */
};
 
-   sysram@4000 {
+   sysram@4004e000 {
compatible = "nvidia,tegra194-sysram", "mmio-sram";
-   reg = <0x0 0x4000 0x0 0x5>;
+   reg = <0x0 0x4004e000 0x0 0x2000>;
#address-cells = <1>;
#size-cells = <1>;
-   ranges = <0x0 0x0 0x4000 0x5>;
+   ranges = <0x0 0x0 0x4004e000 0x2000>;
 
-   cpu_bpmp_tx: shmem@4e000 {
+   cpu_bpmp_tx: shmem@e000 {
compatible = "nvidia,tegra194-bpmp-shmem";
-   reg = <0x4e000 0x1000>;
+   reg = <0x0 0x1000>;
label = "cpu-bpmp-tx";
pool;
};
 
-   cpu_bpmp_rx: shmem@4f000 {
+   cpu_bpmp_rx: shmem@f000 {
compatible = "nvidia,tegra194-bpmp-shmem";
-   reg = <0x4f000 0x1000>;
+   reg = <0x1000 0x1000>;
label = "cpu-bpmp-rx";
pool;
};
-- 
2.16.4

Re: [v5 2/2] arm64: dts: lx2160a: add sata node support

[Mian Yousaf Kaukab]

On Fri, Jan 25, 2019 at 08:10:13AM +, Peng Ma wrote:
> Add SATA device nodes for fsl-lx2160a and enable support
> for QDS and RDB boards.
> 
> Signed-off-by: Peng Ma 
> ---
> changed for V5:
>   - no change
> 
>  arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts |   16 +++
>  arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts |   16 +++
>  arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi|   44 
> +
>  3 files changed, 76 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts 
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> index 99a22ab..1a5acf6 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> @@ -95,6 +95,22 @@
>   };
>  };
>  
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts 
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> index 6481e5f..5b6799e 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> @@ -102,6 +102,22 @@
>   };
>  };
>  
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index a79f5c1..592034b 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -671,6 +671,50 @@
>   status = "disabled";
>   };
>  
> + sata0: sata@320 {
> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x320 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
> + sata1: sata@321 {
> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x321 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
> + sata2: sata@322 {
> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x322 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
> + sata3: sata@323 {
> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x323 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
You are using same reg values for sata-ecc in all sata instances. Does this
actually work? No errors when the ahci_qoriq driver do ioremap on it while
probing second instance and onward?

fsl-ls208xa.dtsi is the only other file here with multiple sata instances and
it doesn’t care about sata-ecc.

> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + status = "disabled";
> + };
> +
>   smmu: iommu@500 {
>   compatible = "arm,mmu-500";
>   reg = <0 0x500 0 0x80>;

BR,
Yousaf

Re: [PATCH RESEND] ahci: qoriq: add lx2160 platforms support

[Mian Yousaf Kaukab]

On Thu, Jan 31, 2019 at 05:28:29PM +0800, Peng Ma wrote:
> Lx2160a is a new introduced soc which supports ATA3.0
> Clean up some code
Some more info here can be useful. For example why you are removing LS2088A
support. Otherwise patch looks good.

> 
> Signed-off-by: Peng Ma 
> ---
>  drivers/ata/ahci_qoriq.c |   44 
>  1 files changed, 12 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
> index ce59253..1994bf2 100644
> --- a/drivers/ata/ahci_qoriq.c
> +++ b/drivers/ata/ahci_qoriq.c
> @@ -57,7 +57,7 @@ enum ahci_qoriq_type {
>   AHCI_LS2080A,
>   AHCI_LS1046A,
>   AHCI_LS1088A,
> - AHCI_LS2088A,
> + AHCI_LX2160A,
>  };
>  
>  struct ahci_qoriq_priv {
> @@ -73,7 +73,7 @@ struct ahci_qoriq_priv {
>   { .compatible = "fsl,ls2080a-ahci", .data = (void *)AHCI_LS2080A},
>   { .compatible = "fsl,ls1046a-ahci", .data = (void *)AHCI_LS1046A},
>   { .compatible = "fsl,ls1088a-ahci", .data = (void *)AHCI_LS1088A},
> - { .compatible = "fsl,ls2088a-ahci", .data = (void *)AHCI_LS2088A},
> + { .compatible = "fsl,lx2160a-ahci", .data = (void *)AHCI_LX2160A},
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match);
> @@ -174,12 +174,10 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
> *hpriv)
>   writel(LS1021A_PORT_PHY4, reg_base + PORT_PHY4);
>   writel(LS1021A_PORT_PHY5, reg_base + PORT_PHY5);
>   writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
> - if (qpriv->is_dmacoherent)
> - writel(AHCI_PORT_AXICC_CFG,
> - reg_base + LS1021A_AXICC_ADDR);
>   break;
>  
>   case AHCI_LS1043A:
> + case AHCI_LS1046A:
>   if (!qpriv->ecc_addr)
>   return -EINVAL;
>   writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2,
> @@ -188,8 +186,6 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
> *hpriv)
>   writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
>   writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
>   writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
> - if (qpriv->is_dmacoherent)
> - writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
>   break;
>  
>   case AHCI_LS2080A:
> @@ -197,24 +193,10 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
> *hpriv)
>   writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
>   writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
>   writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
> - if (qpriv->is_dmacoherent)
> - writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
> - break;
> -
> - case AHCI_LS1046A:
> - if (!qpriv->ecc_addr)
> - return -EINVAL;
> - writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2,
> - qpriv->ecc_addr);
> - writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
> - writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
> - writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
> - writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
> - if (qpriv->is_dmacoherent)
> - writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
>   break;
>  
>   case AHCI_LS1088A:
> + case AHCI_LX2160A:
>   if (!qpriv->ecc_addr)
>   return -EINVAL;
>   writel(readl(qpriv->ecc_addr) | ECC_DIS_LS1088A,
> @@ -223,18 +205,16 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
> *hpriv)
>   writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
>   writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
>   writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
> - if (qpriv->is_dmacoherent)
> - writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
>   break;
> + }
>  
> - case AHCI_LS2088A:
> - writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
> - writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
> - writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
> - writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
> - if (qpriv->is_dmacoherent)
> - writel(AHCI_PORT_AXICC_CFG, reg_base + PORT_AXICC);
> - break;
> + if (qpriv->is_dmacoherent) {
> + if (qpriv->type == AHCI_LS1021A)
> + writel(AHCI_PORT_AXICC_CFG,
> +reg_base + LS1021A_AXICC_ADDR);
> + else
> + writel(AHCI_PORT_AXICC_CFG,
> +reg_base + PORT_AXICC);
>   }
>  
>   return 0;
> -- 
> 1.7.1

BR,
Yousaf

Re: [PATCH RESEND 0/6] arm64: add support for generic cpu vulnerabilities

[Mian Yousaf Kaukab]

On Mon, Sep 17, 2018 at 02:35:08PM +0100, Will Deacon wrote:
> On Wed, Sep 05, 2018 at 11:25:33AM +0200, Mian Yousaf Kaukab wrote:
> > On Mon, Aug 27, 2018 at 04:33:04PM +0200, Mian Yousaf Kaukab wrote:
> > > GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
> > > system is affected by vulnerabilities like meltdown and other variants
> > > of spectre. This small series adds support for it in arm64.
> > 
> > Marc, Will, Can you please review this series?
> 
> Sorry it took so long to get to this, it's just consistently failed to
> get to the top of my review queue. I had a quick look just now and there
> are a few things to address before we can take the series.
Thank you for the review. I will get back to you after fixing the comments as 
soon as possible.

> 
> Cheers,
> 
> Will

Thanks,
Yousaf

Re: [PATCH RESEND 0/6] arm64: add support for generic cpu vulnerabilities

[Mian Yousaf Kaukab]

On Mon, Sep 17, 2018 at 02:35:08PM +0100, Will Deacon wrote:
> On Wed, Sep 05, 2018 at 11:25:33AM +0200, Mian Yousaf Kaukab wrote:
> > On Mon, Aug 27, 2018 at 04:33:04PM +0200, Mian Yousaf Kaukab wrote:
> > > GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
> > > system is affected by vulnerabilities like meltdown and other variants
> > > of spectre. This small series adds support for it in arm64.
> > 
> > Marc, Will, Can you please review this series?
> 
> Sorry it took so long to get to this, it's just consistently failed to
> get to the top of my review queue. I had a quick look just now and there
> are a few things to address before we can take the series.
Thank you for the review. I will get back to you after fixing the comments as 
soon as possible.

> 
> Cheers,
> 
> Will

Thanks,
Yousaf

Re: [PATCH RESEND 0/6] arm64: add support for generic cpu vulnerabilities

[Mian Yousaf Kaukab]

On Mon, Aug 27, 2018 at 04:33:04PM +0200, Mian Yousaf Kaukab wrote:
> GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
> system is affected by vulnerabilities like meltdown and other variants
> of spectre. This small series adds support for it in arm64.

Marc, Will, Can you please review this series?
Please let me know if I should rebase it against arm64 tree.

Thanks,
Yousaf

Re: [PATCH RESEND 0/6] arm64: add support for generic cpu vulnerabilities

[Mian Yousaf Kaukab]

On Mon, Aug 27, 2018 at 04:33:04PM +0200, Mian Yousaf Kaukab wrote:
> GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
> system is affected by vulnerabilities like meltdown and other variants
> of spectre. This small series adds support for it in arm64.

Marc, Will, Can you please review this series?
Please let me know if I should rebase it against arm64 tree.

Thanks,
Yousaf

[PATCH RESEND 2/6] arm64: add sysfs vulnerability show for meltdown

[Mian Yousaf Kaukab]

Checking CSV3 support directly in case CONFIG_UNMAP_KERNEL_AT_EL0
is not enabled.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index dec10898d688..996edb4e18ad 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static bool __maybe_unused
 is_affected_midr_range(const struct arm64_cpu_capabilities *entry, int scope)
@@ -683,3 +684,26 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
{
}
 };
+
+#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
+
+ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   u64 pfr0;
+   u32 csv3;
+
+   if (arm64_kernel_unmapped_at_el0())
+   return sprintf(buf, "Mitigation: KPTI\n");
+
+   pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+   csv3 = cpuid_feature_extract_unsigned_field(pfr0,
+   ID_AA64PFR0_CSV3_SHIFT);
+
+   if (csv3 || is_cpu_meltdown_safe())
+   return sprintf(buf, "Not affected\n");
+
+   return sprintf(buf, "Vulnerable\n");
+}
+
+#endif
-- 
2.11.0

[PATCH RESEND 1/6] arm64: kpti: move check for non-vulnerable CPUs to a function

[Mian Yousaf Kaukab]

Prepare to call it in generic cpu vulnerabilities support.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/include/asm/cpufeature.h | 16 
 arch/arm64/kernel/cpufeature.c  |  9 +
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h 
b/arch/arm64/include/asm/cpufeature.h
index 1717ba1db35d..0b0b5b3e36ba 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -530,6 +530,22 @@ void arm64_set_ssbd_mitigation(bool state);
 static inline void arm64_set_ssbd_mitigation(bool state) {}
 #endif
 
+static inline bool is_cpu_meltdown_safe(void)
+{
+   /* List of CPUs that are not vulnerable and don't need KPTI */
+   static const struct midr_range kpti_safe_list[] = {
+   MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
+   MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
+   { /* sentinel */ }
+   };
+
+   /* Don't force KPTI for CPUs that are not vulnerable */
+   if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+   return true;
+
+   return false;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e238b7932096..6a94f8bce35a 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -865,12 +865,6 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, 
<0: forced off */
 static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
int scope)
 {
-   /* List of CPUs that are not vulnerable and don't need KPTI */
-   static const struct midr_range kpti_safe_list[] = {
-   MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
-   MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
-   { /* sentinel */ }
-   };
char const *str = "command line option";
 
/*
@@ -894,8 +888,7 @@ static bool unmap_kernel_at_el0(const struct 
arm64_cpu_capabilities *entry,
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
return true;
 
-   /* Don't force KPTI for CPUs that are not vulnerable */
-   if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+   if (is_cpu_meltdown_safe())
return false;
 
/* Defer to CPU feature registers */
-- 
2.11.0

[PATCH RESEND 3/6] arm64: add sysfs vulnerability show for spectre v1

[Mian Yousaf Kaukab]

Hard-coded since patches are merged and there are no configuration
options.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 996edb4e18ad..92616431ae4e 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -706,4 +706,10 @@ ssize_t cpu_show_meltdown(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Vulnerable\n");
 }
 
+ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   return sprintf(buf, "Mitigation: __user pointer sanitization\n");
+}
+
 #endif
-- 
2.11.0

[PATCH RESEND 0/6] arm64: add support for generic cpu vulnerabilities

[Mian Yousaf Kaukab]

GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
system is affected by vulnerabilities like meltdown and other variants
of spectre. This small series adds support for it in arm64.

Thank you,

Best regards,
Yousaf

Mian Yousaf Kaukab (6):
  arm64: kpti: move check for non-vulnerable CPUs to a function
  arm64: add sysfs vulnerability show for meltdown
  arm64: add sysfs vulnerability show for spectre v1
  arm64: add sysfs vulnerability show for spectre v2
  arm64: add sysfs vulnerability show for speculative store bypass
  arm64: enable generic CPU vulnerabilites support

 arch/arm64/Kconfig  |  1 +
 arch/arm64/include/asm/cpufeature.h | 16 +++
 arch/arm64/kernel/cpu_errata.c  | 84 -
 arch/arm64/kernel/cpufeature.c  |  9 +---
 4 files changed, 101 insertions(+), 9 deletions(-)

-- 
2.11.0

[PATCH RESEND 5/6] arm64: add sysfs vulnerability show for speculative store bypass

[Mian Yousaf Kaukab]

Return status based no ssbd_state. Return string "Unknown" in case
CONFIG_ARM64_SSBD is disabled or arch workaround2 is not available
in the firmware.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 8469d3be7b15..8b60aa30a3fa 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -744,4 +744,24 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Not affected\n");
 }
 
+ssize_t cpu_show_spec_store_bypass(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   switch (arm64_get_ssbd_state()) {
+   case ARM64_SSBD_MITIGATED:
+   return sprintf(buf, "Not affected\n");
+
+   case ARM64_SSBD_KERNEL:
+   case ARM64_SSBD_FORCE_ENABLE:
+   return sprintf(buf,
+   "Mitigation: Speculative Store Bypass disabled");
+
+   case ARM64_SSBD_FORCE_DISABLE:
+   return sprintf(buf, "Vulnerable\n");
+
+   default: /* ARM64_SSBD_UNKNOWN*/
+   return sprintf(buf, "Unknown\n");
+   }
+}
+
 #endif
-- 
2.11.0

[PATCH RESEND 0/6] arm64: add support for generic cpu vulnerabilities

[Mian Yousaf Kaukab]

GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
system is affected by vulnerabilities like meltdown and other variants
of spectre. This small series adds support for it in arm64.

Thank you,

Best regards,
Yousaf

Mian Yousaf Kaukab (6):
  arm64: kpti: move check for non-vulnerable CPUs to a function
  arm64: add sysfs vulnerability show for meltdown
  arm64: add sysfs vulnerability show for spectre v1
  arm64: add sysfs vulnerability show for spectre v2
  arm64: add sysfs vulnerability show for speculative store bypass
  arm64: enable generic CPU vulnerabilites support

 arch/arm64/Kconfig  |  1 +
 arch/arm64/include/asm/cpufeature.h | 16 +++
 arch/arm64/kernel/cpu_errata.c  | 84 -
 arch/arm64/kernel/cpufeature.c  |  9 +---
 4 files changed, 101 insertions(+), 9 deletions(-)

-- 
2.11.0

[PATCH RESEND 5/6] arm64: add sysfs vulnerability show for speculative store bypass

[Mian Yousaf Kaukab]

Return status based no ssbd_state. Return string "Unknown" in case
CONFIG_ARM64_SSBD is disabled or arch workaround2 is not available
in the firmware.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 8469d3be7b15..8b60aa30a3fa 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -744,4 +744,24 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Not affected\n");
 }
 
+ssize_t cpu_show_spec_store_bypass(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   switch (arm64_get_ssbd_state()) {
+   case ARM64_SSBD_MITIGATED:
+   return sprintf(buf, "Not affected\n");
+
+   case ARM64_SSBD_KERNEL:
+   case ARM64_SSBD_FORCE_ENABLE:
+   return sprintf(buf,
+   "Mitigation: Speculative Store Bypass disabled");
+
+   case ARM64_SSBD_FORCE_DISABLE:
+   return sprintf(buf, "Vulnerable\n");
+
+   default: /* ARM64_SSBD_UNKNOWN*/
+   return sprintf(buf, "Unknown\n");
+   }
+}
+
 #endif
-- 
2.11.0

[PATCH RESEND 2/6] arm64: add sysfs vulnerability show for meltdown

[Mian Yousaf Kaukab]

Checking CSV3 support directly in case CONFIG_UNMAP_KERNEL_AT_EL0
is not enabled.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index dec10898d688..996edb4e18ad 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static bool __maybe_unused
 is_affected_midr_range(const struct arm64_cpu_capabilities *entry, int scope)
@@ -683,3 +684,26 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
{
}
 };
+
+#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
+
+ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   u64 pfr0;
+   u32 csv3;
+
+   if (arm64_kernel_unmapped_at_el0())
+   return sprintf(buf, "Mitigation: KPTI\n");
+
+   pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+   csv3 = cpuid_feature_extract_unsigned_field(pfr0,
+   ID_AA64PFR0_CSV3_SHIFT);
+
+   if (csv3 || is_cpu_meltdown_safe())
+   return sprintf(buf, "Not affected\n");
+
+   return sprintf(buf, "Vulnerable\n");
+}
+
+#endif
-- 
2.11.0

[PATCH RESEND 1/6] arm64: kpti: move check for non-vulnerable CPUs to a function

[Mian Yousaf Kaukab]

Prepare to call it in generic cpu vulnerabilities support.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/include/asm/cpufeature.h | 16 
 arch/arm64/kernel/cpufeature.c  |  9 +
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h 
b/arch/arm64/include/asm/cpufeature.h
index 1717ba1db35d..0b0b5b3e36ba 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -530,6 +530,22 @@ void arm64_set_ssbd_mitigation(bool state);
 static inline void arm64_set_ssbd_mitigation(bool state) {}
 #endif
 
+static inline bool is_cpu_meltdown_safe(void)
+{
+   /* List of CPUs that are not vulnerable and don't need KPTI */
+   static const struct midr_range kpti_safe_list[] = {
+   MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
+   MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
+   { /* sentinel */ }
+   };
+
+   /* Don't force KPTI for CPUs that are not vulnerable */
+   if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+   return true;
+
+   return false;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e238b7932096..6a94f8bce35a 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -865,12 +865,6 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, 
<0: forced off */
 static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
int scope)
 {
-   /* List of CPUs that are not vulnerable and don't need KPTI */
-   static const struct midr_range kpti_safe_list[] = {
-   MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
-   MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
-   { /* sentinel */ }
-   };
char const *str = "command line option";
 
/*
@@ -894,8 +888,7 @@ static bool unmap_kernel_at_el0(const struct 
arm64_cpu_capabilities *entry,
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
return true;
 
-   /* Don't force KPTI for CPUs that are not vulnerable */
-   if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+   if (is_cpu_meltdown_safe())
return false;
 
/* Defer to CPU feature registers */
-- 
2.11.0

[PATCH RESEND 3/6] arm64: add sysfs vulnerability show for spectre v1

[Mian Yousaf Kaukab]

Hard-coded since patches are merged and there are no configuration
options.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 996edb4e18ad..92616431ae4e 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -706,4 +706,10 @@ ssize_t cpu_show_meltdown(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Vulnerable\n");
 }
 
+ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   return sprintf(buf, "Mitigation: __user pointer sanitization\n");
+}
+
 #endif
-- 
2.11.0

[PATCH RESEND 4/6] arm64: add sysfs vulnerability show for spectre v2

[Mian Yousaf Kaukab]

Only report mitigation present if hardening callback has been
successfully installed.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 92616431ae4e..8469d3be7b15 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -481,7 +481,8 @@ multi_entry_cap_cpu_enable(const struct 
arm64_cpu_capabilities *entry)
caps->cpu_enable(caps);
 }
 
-#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+#if defined(CONFIG_HARDEN_BRANCH_PREDICTOR) || \
+   defined(CONFIG_GENERIC_CPU_VULNERABILITIES)
 
 /*
  * List of CPUs where we need to issue a psci call to
@@ -712,4 +713,35 @@ ssize_t cpu_show_spectre_v1(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Mitigation: __user pointer sanitization\n");
 }
 
+ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   u64 pfr0;
+   struct bp_hardening_data *data;
+
+   pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+   if (cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_CSV2_SHIFT))
+   return sprintf(buf, "Not affected\n");
+
+   if (cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR)) {
+   /*
+* Hardware is vulnerable. Lets check if bp hardening callback
+* has been successfully installed
+*/
+   data = arm64_get_bp_hardening_data();
+   if (data && data->fn)
+   return sprintf(buf,
+   "Mitigation: Branch predictor hardening");
+   else
+   /* For example SMCCC_VERSION_1_0 */
+   return sprintf(buf, "Vulnerable\n");
+   }
+
+   /* In case CONFIG_HARDEN_BRANCH_PREDICTOR is not enabled */
+   if (is_midr_in_range_list(read_cpuid_id(), arm64_bp_harden_smccc_cpus))
+   return sprintf(buf, "Vulnerable\n");
+
+   return sprintf(buf, "Not affected\n");
+}
+
 #endif
-- 
2.11.0

[PATCH RESEND 4/6] arm64: add sysfs vulnerability show for spectre v2

[Mian Yousaf Kaukab]

Only report mitigation present if hardening callback has been
successfully installed.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 92616431ae4e..8469d3be7b15 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -481,7 +481,8 @@ multi_entry_cap_cpu_enable(const struct 
arm64_cpu_capabilities *entry)
caps->cpu_enable(caps);
 }
 
-#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+#if defined(CONFIG_HARDEN_BRANCH_PREDICTOR) || \
+   defined(CONFIG_GENERIC_CPU_VULNERABILITIES)
 
 /*
  * List of CPUs where we need to issue a psci call to
@@ -712,4 +713,35 @@ ssize_t cpu_show_spectre_v1(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Mitigation: __user pointer sanitization\n");
 }
 
+ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   u64 pfr0;
+   struct bp_hardening_data *data;
+
+   pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+   if (cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_CSV2_SHIFT))
+   return sprintf(buf, "Not affected\n");
+
+   if (cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR)) {
+   /*
+* Hardware is vulnerable. Lets check if bp hardening callback
+* has been successfully installed
+*/
+   data = arm64_get_bp_hardening_data();
+   if (data && data->fn)
+   return sprintf(buf,
+   "Mitigation: Branch predictor hardening");
+   else
+   /* For example SMCCC_VERSION_1_0 */
+   return sprintf(buf, "Vulnerable\n");
+   }
+
+   /* In case CONFIG_HARDEN_BRANCH_PREDICTOR is not enabled */
+   if (is_midr_in_range_list(read_cpuid_id(), arm64_bp_harden_smccc_cpus))
+   return sprintf(buf, "Vulnerable\n");
+
+   return sprintf(buf, "Not affected\n");
+}
+
 #endif
-- 
2.11.0

[PATCH RESEND 6/6] arm64: enable generic CPU vulnerabilites support

[Mian Yousaf Kaukab]

Enable CPU vulnerabilty show functions for spectre_v1, spectre_v2,
meltdown and store-bypass.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0dec01a0c81c..ffd97bc0f5d5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -84,6 +84,7 @@ config ARM64
select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST
select GENERIC_CPU_AUTOPROBE
+   select GENERIC_CPU_VULNERABILITIES
select GENERIC_EARLY_IOREMAP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_MULTI_HANDLER
-- 
2.11.0

[PATCH RESEND 6/6] arm64: enable generic CPU vulnerabilites support

[Mian Yousaf Kaukab]

Enable CPU vulnerabilty show functions for spectre_v1, spectre_v2,
meltdown and store-bypass.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0dec01a0c81c..ffd97bc0f5d5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -84,6 +84,7 @@ config ARM64
select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST
select GENERIC_CPU_AUTOPROBE
+   select GENERIC_CPU_VULNERABILITIES
select GENERIC_EARLY_IOREMAP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_MULTI_HANDLER
-- 
2.11.0

[PATCH 0/6] arm64: add support for generic cpu vulnerabilities

[Mian Yousaf Kaukab]

GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
system is affected by vulnerabilities like meltdown and other variants
of spectre. This small series adds support for it in arm64.

Thank you,

Best regards,
Yousaf

Mian Yousaf Kaukab (6):
  arm64: kpti: move check for non-vulnerable CPUs to a function
  arm64: add sysfs vulnerability show for meltdown
  arm64: add sysfs vulnerability show for spectre v1
  arm64: add sysfs vulnerability show for spectre v2
  arm64: add sysfs vulnerability show for speculative store bypass
  arm64: enable generic CPU vulnerabilites support

 arch/arm64/Kconfig  |  1 +
 arch/arm64/include/asm/cpufeature.h | 16 +++
 arch/arm64/kernel/cpu_errata.c  | 84 -
 arch/arm64/kernel/cpufeature.c  |  9 +---
 4 files changed, 101 insertions(+), 9 deletions(-)

-- 
2.11.0

[PATCH 0/6] arm64: add support for generic cpu vulnerabilities

[Mian Yousaf Kaukab]

GENERIC_CPU_VULNERABILITIES provide a common way to figure out if a
system is affected by vulnerabilities like meltdown and other variants
of spectre. This small series adds support for it in arm64.

Thank you,

Best regards,
Yousaf

Mian Yousaf Kaukab (6):
  arm64: kpti: move check for non-vulnerable CPUs to a function
  arm64: add sysfs vulnerability show for meltdown
  arm64: add sysfs vulnerability show for spectre v1
  arm64: add sysfs vulnerability show for spectre v2
  arm64: add sysfs vulnerability show for speculative store bypass
  arm64: enable generic CPU vulnerabilites support

 arch/arm64/Kconfig  |  1 +
 arch/arm64/include/asm/cpufeature.h | 16 +++
 arch/arm64/kernel/cpu_errata.c  | 84 -
 arch/arm64/kernel/cpufeature.c  |  9 +---
 4 files changed, 101 insertions(+), 9 deletions(-)

-- 
2.11.0

[PATCH 3/6] arm64: add sysfs vulnerability show for spectre v1

[Mian Yousaf Kaukab]

Hard-coded since patches are merged and there are no configuration
options.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 996edb4e18ad..92616431ae4e 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -706,4 +706,10 @@ ssize_t cpu_show_meltdown(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Vulnerable\n");
 }
 
+ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   return sprintf(buf, "Mitigation: __user pointer sanitization\n");
+}
+
 #endif
-- 
2.11.0

[PATCH 3/6] arm64: add sysfs vulnerability show for spectre v1

[Mian Yousaf Kaukab]

Hard-coded since patches are merged and there are no configuration
options.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 996edb4e18ad..92616431ae4e 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -706,4 +706,10 @@ ssize_t cpu_show_meltdown(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Vulnerable\n");
 }
 
+ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   return sprintf(buf, "Mitigation: __user pointer sanitization\n");
+}
+
 #endif
-- 
2.11.0

[PATCH 4/6] arm64: add sysfs vulnerability show for spectre v2

[Mian Yousaf Kaukab]

Only report mitigation present if hardening callback has been
successfully installed.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 92616431ae4e..8469d3be7b15 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -481,7 +481,8 @@ multi_entry_cap_cpu_enable(const struct 
arm64_cpu_capabilities *entry)
caps->cpu_enable(caps);
 }
 
-#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+#if defined(CONFIG_HARDEN_BRANCH_PREDICTOR) || \
+   defined(CONFIG_GENERIC_CPU_VULNERABILITIES)
 
 /*
  * List of CPUs where we need to issue a psci call to
@@ -712,4 +713,35 @@ ssize_t cpu_show_spectre_v1(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Mitigation: __user pointer sanitization\n");
 }
 
+ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   u64 pfr0;
+   struct bp_hardening_data *data;
+
+   pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+   if (cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_CSV2_SHIFT))
+   return sprintf(buf, "Not affected\n");
+
+   if (cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR)) {
+   /*
+* Hardware is vulnerable. Lets check if bp hardening callback
+* has been successfully installed
+*/
+   data = arm64_get_bp_hardening_data();
+   if (data && data->fn)
+   return sprintf(buf,
+   "Mitigation: Branch predictor hardening");
+   else
+   /* For example SMCCC_VERSION_1_0 */
+   return sprintf(buf, "Vulnerable\n");
+   }
+
+   /* In case CONFIG_HARDEN_BRANCH_PREDICTOR is not enabled */
+   if (is_midr_in_range_list(read_cpuid_id(), arm64_bp_harden_smccc_cpus))
+   return sprintf(buf, "Vulnerable\n");
+
+   return sprintf(buf, "Not affected\n");
+}
+
 #endif
-- 
2.11.0

[PATCH 2/6] arm64: add sysfs vulnerability show for meltdown

[Mian Yousaf Kaukab]

Checking CSV3 support directly in case CONFIG_UNMAP_KERNEL_AT_EL0
is not enabled.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index dec10898d688..996edb4e18ad 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static bool __maybe_unused
 is_affected_midr_range(const struct arm64_cpu_capabilities *entry, int scope)
@@ -683,3 +684,26 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
{
}
 };
+
+#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
+
+ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   u64 pfr0;
+   u32 csv3;
+
+   if (arm64_kernel_unmapped_at_el0())
+   return sprintf(buf, "Mitigation: KPTI\n");
+
+   pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+   csv3 = cpuid_feature_extract_unsigned_field(pfr0,
+   ID_AA64PFR0_CSV3_SHIFT);
+
+   if (csv3 || is_cpu_meltdown_safe())
+   return sprintf(buf, "Not affected\n");
+
+   return sprintf(buf, "Vulnerable\n");
+}
+
+#endif
-- 
2.11.0

[PATCH 4/6] arm64: add sysfs vulnerability show for spectre v2

[Mian Yousaf Kaukab]

Only report mitigation present if hardening callback has been
successfully installed.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 92616431ae4e..8469d3be7b15 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -481,7 +481,8 @@ multi_entry_cap_cpu_enable(const struct 
arm64_cpu_capabilities *entry)
caps->cpu_enable(caps);
 }
 
-#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+#if defined(CONFIG_HARDEN_BRANCH_PREDICTOR) || \
+   defined(CONFIG_GENERIC_CPU_VULNERABILITIES)
 
 /*
  * List of CPUs where we need to issue a psci call to
@@ -712,4 +713,35 @@ ssize_t cpu_show_spectre_v1(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Mitigation: __user pointer sanitization\n");
 }
 
+ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   u64 pfr0;
+   struct bp_hardening_data *data;
+
+   pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+   if (cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_CSV2_SHIFT))
+   return sprintf(buf, "Not affected\n");
+
+   if (cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR)) {
+   /*
+* Hardware is vulnerable. Lets check if bp hardening callback
+* has been successfully installed
+*/
+   data = arm64_get_bp_hardening_data();
+   if (data && data->fn)
+   return sprintf(buf,
+   "Mitigation: Branch predictor hardening");
+   else
+   /* For example SMCCC_VERSION_1_0 */
+   return sprintf(buf, "Vulnerable\n");
+   }
+
+   /* In case CONFIG_HARDEN_BRANCH_PREDICTOR is not enabled */
+   if (is_midr_in_range_list(read_cpuid_id(), arm64_bp_harden_smccc_cpus))
+   return sprintf(buf, "Vulnerable\n");
+
+   return sprintf(buf, "Not affected\n");
+}
+
 #endif
-- 
2.11.0

[PATCH 2/6] arm64: add sysfs vulnerability show for meltdown

[Mian Yousaf Kaukab]

Checking CSV3 support directly in case CONFIG_UNMAP_KERNEL_AT_EL0
is not enabled.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index dec10898d688..996edb4e18ad 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static bool __maybe_unused
 is_affected_midr_range(const struct arm64_cpu_capabilities *entry, int scope)
@@ -683,3 +684,26 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
{
}
 };
+
+#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
+
+ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   u64 pfr0;
+   u32 csv3;
+
+   if (arm64_kernel_unmapped_at_el0())
+   return sprintf(buf, "Mitigation: KPTI\n");
+
+   pfr0 = read_cpuid(ID_AA64PFR0_EL1);
+   csv3 = cpuid_feature_extract_unsigned_field(pfr0,
+   ID_AA64PFR0_CSV3_SHIFT);
+
+   if (csv3 || is_cpu_meltdown_safe())
+   return sprintf(buf, "Not affected\n");
+
+   return sprintf(buf, "Vulnerable\n");
+}
+
+#endif
-- 
2.11.0

[PATCH 5/6] arm64: add sysfs vulnerability show for speculative store bypass

[Mian Yousaf Kaukab]

Return status based no ssbd_state. Return string "Unknown" in case
CONFIG_ARM64_SSBD is disabled or arch workaround2 is not available
in the firmware.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 8469d3be7b15..8b60aa30a3fa 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -744,4 +744,24 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Not affected\n");
 }
 
+ssize_t cpu_show_spec_store_bypass(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   switch (arm64_get_ssbd_state()) {
+   case ARM64_SSBD_MITIGATED:
+   return sprintf(buf, "Not affected\n");
+
+   case ARM64_SSBD_KERNEL:
+   case ARM64_SSBD_FORCE_ENABLE:
+   return sprintf(buf,
+   "Mitigation: Speculative Store Bypass disabled");
+
+   case ARM64_SSBD_FORCE_DISABLE:
+   return sprintf(buf, "Vulnerable\n");
+
+   default: /* ARM64_SSBD_UNKNOWN*/
+   return sprintf(buf, "Unknown\n");
+   }
+}
+
 #endif
-- 
2.11.0

[PATCH 5/6] arm64: add sysfs vulnerability show for speculative store bypass

[Mian Yousaf Kaukab]

Return status based no ssbd_state. Return string "Unknown" in case
CONFIG_ARM64_SSBD is disabled or arch workaround2 is not available
in the firmware.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/kernel/cpu_errata.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 8469d3be7b15..8b60aa30a3fa 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -744,4 +744,24 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "Not affected\n");
 }
 
+ssize_t cpu_show_spec_store_bypass(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   switch (arm64_get_ssbd_state()) {
+   case ARM64_SSBD_MITIGATED:
+   return sprintf(buf, "Not affected\n");
+
+   case ARM64_SSBD_KERNEL:
+   case ARM64_SSBD_FORCE_ENABLE:
+   return sprintf(buf,
+   "Mitigation: Speculative Store Bypass disabled");
+
+   case ARM64_SSBD_FORCE_DISABLE:
+   return sprintf(buf, "Vulnerable\n");
+
+   default: /* ARM64_SSBD_UNKNOWN*/
+   return sprintf(buf, "Unknown\n");
+   }
+}
+
 #endif
-- 
2.11.0

[PATCH 6/6] arm64: enable generic CPU vulnerabilites support

[Mian Yousaf Kaukab]

Enable CPU vulnerabilty show functions for spectre_v1, spectre_v2,
meltdown and store-bypass.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0dec01a0c81c..ffd97bc0f5d5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -84,6 +84,7 @@ config ARM64
select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST
select GENERIC_CPU_AUTOPROBE
+   select GENERIC_CPU_VULNERABILITIES
select GENERIC_EARLY_IOREMAP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_MULTI_HANDLER
-- 
2.11.0

[PATCH 6/6] arm64: enable generic CPU vulnerabilites support

[Mian Yousaf Kaukab]

Enable CPU vulnerabilty show functions for spectre_v1, spectre_v2,
meltdown and store-bypass.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0dec01a0c81c..ffd97bc0f5d5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -84,6 +84,7 @@ config ARM64
select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST
select GENERIC_CPU_AUTOPROBE
+   select GENERIC_CPU_VULNERABILITIES
select GENERIC_EARLY_IOREMAP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_MULTI_HANDLER
-- 
2.11.0

[PATCH 1/6] arm64: kpti: move check for non-vulnerable CPUs to a function

[Mian Yousaf Kaukab]

Prepare to call it in generic cpu vulnerabilities support.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/include/asm/cpufeature.h | 16 
 arch/arm64/kernel/cpufeature.c  |  9 +
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h 
b/arch/arm64/include/asm/cpufeature.h
index 1717ba1db35d..0b0b5b3e36ba 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -530,6 +530,22 @@ void arm64_set_ssbd_mitigation(bool state);
 static inline void arm64_set_ssbd_mitigation(bool state) {}
 #endif
 
+static inline bool is_cpu_meltdown_safe(void)
+{
+   /* List of CPUs that are not vulnerable and don't need KPTI */
+   static const struct midr_range kpti_safe_list[] = {
+   MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
+   MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
+   { /* sentinel */ }
+   };
+
+   /* Don't force KPTI for CPUs that are not vulnerable */
+   if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+   return true;
+
+   return false;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e238b7932096..6a94f8bce35a 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -865,12 +865,6 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, 
<0: forced off */
 static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
int scope)
 {
-   /* List of CPUs that are not vulnerable and don't need KPTI */
-   static const struct midr_range kpti_safe_list[] = {
-   MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
-   MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
-   { /* sentinel */ }
-   };
char const *str = "command line option";
 
/*
@@ -894,8 +888,7 @@ static bool unmap_kernel_at_el0(const struct 
arm64_cpu_capabilities *entry,
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
return true;
 
-   /* Don't force KPTI for CPUs that are not vulnerable */
-   if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+   if (is_cpu_meltdown_safe())
return false;
 
/* Defer to CPU feature registers */
-- 
2.11.0

[PATCH 1/6] arm64: kpti: move check for non-vulnerable CPUs to a function

[Mian Yousaf Kaukab]

Prepare to call it in generic cpu vulnerabilities support.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/include/asm/cpufeature.h | 16 
 arch/arm64/kernel/cpufeature.c  |  9 +
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h 
b/arch/arm64/include/asm/cpufeature.h
index 1717ba1db35d..0b0b5b3e36ba 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -530,6 +530,22 @@ void arm64_set_ssbd_mitigation(bool state);
 static inline void arm64_set_ssbd_mitigation(bool state) {}
 #endif
 
+static inline bool is_cpu_meltdown_safe(void)
+{
+   /* List of CPUs that are not vulnerable and don't need KPTI */
+   static const struct midr_range kpti_safe_list[] = {
+   MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
+   MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
+   { /* sentinel */ }
+   };
+
+   /* Don't force KPTI for CPUs that are not vulnerable */
+   if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+   return true;
+
+   return false;
+}
+
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e238b7932096..6a94f8bce35a 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -865,12 +865,6 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, 
<0: forced off */
 static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
int scope)
 {
-   /* List of CPUs that are not vulnerable and don't need KPTI */
-   static const struct midr_range kpti_safe_list[] = {
-   MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
-   MIDR_ALL_VERSIONS(MIDR_BRCM_VULCAN),
-   { /* sentinel */ }
-   };
char const *str = "command line option";
 
/*
@@ -894,8 +888,7 @@ static bool unmap_kernel_at_el0(const struct 
arm64_cpu_capabilities *entry,
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
return true;
 
-   /* Don't force KPTI for CPUs that are not vulnerable */
-   if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
+   if (is_cpu_meltdown_safe())
return false;
 
/* Defer to CPU feature registers */
-- 
2.11.0

Re: [PATCH] ACPI: processor: fix LPI when built as module

[Mian Yousaf Kaukab]

On 5/23/17 3:08 PM, Sudeep Holla wrote:



On 19/05/17 10:28, Mian Yousaf Kaukab wrote:

Low Power Idle(LPI) support added acpi_processor_ffh_lpi_probe() and
acpi_processor_ffh_lpi_enter() as __weak functions and arch code is
supposed to provide the actual callbacks. This breaks if
ACPI_PROCESSOR is configured as a module.

Add CONFIG_ARCH_HAS_ACPI_LPI configuration option to fix this.



Rafael didn't like the extra Kconfig option when I first posted
LPI patches.


Signed-off-by: Mian Yousaf Kaukab <yousaf.kau...@suse.com>
---
  arch/arm64/Kconfig| 1 +
  arch/arm64/kernel/cpuidle.c   | 2 ++
  drivers/acpi/Kconfig  | 3 +++
  drivers/acpi/processor_idle.c | 9 +++--
  4 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 848a34116c67..de2f2779cdf5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -10,6 +10,7 @@ config ARM64
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
+   select ARCH_HAS_ACPI_LPI if ACPI
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
index fd691087dc9a..002d9cb890bd 100644
--- a/arch/arm64/kernel/cpuidle.c
+++ b/arch/arm64/kernel/cpuidle.c
@@ -51,9 +51,11 @@ int acpi_processor_ffh_lpi_probe(unsigned int cpu)
  {
return arm_cpuidle_init(cpu);
  }
+EXPORT_SYMBOL(acpi_processor_ffh_lpi_probe);
  
  int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)

  {
return CPU_PM_CPU_IDLE_ENTER(arm_cpuidle_suspend, lpi->index);
  }
+EXPORT_SYMBOL(acpi_processor_ffh_lpi_enter);


Won't these 2 export suffice ? [...]

No, they don't suffice.


[...] I am just curious why that won't work.

I am not really sure. System.map shows the exported symbols as following:
08095898 T acpi_processor_ffh_lpi_probe
080958f8 T acpi_processor_ffh_lpi_enter
08c19160 R __ksymtab_acpi_processor_ffh_lpi_enter
08c19170 R __ksymtab_acpi_processor_ffh_lpi_probe
08c357f0 r __kcrctab_acpi_processor_ffh_lpi_enter
08c357f8 r __kcrctab_acpi_processor_ffh_lpi_probe
08c4361b r __kstrtab_acpi_processor_ffh_lpi_enter
08c43638 r __kstrtab_acpi_processor_ffh_lpi_probe

and 'nm processor.ko' shows that they are defined as weak:

0d68 W acpi_processor_ffh_lpi_enter
0cc8 W acpi_processor_ffh_lpi_probe

But still weak symbols are happily used when the module is inserted.


Will weak function definitions be still picked when built as modules ?

Yes.

BR,
Yousaf

Re: [PATCH] ACPI: processor: fix LPI when built as module

[Mian Yousaf Kaukab]

On 5/23/17 3:08 PM, Sudeep Holla wrote:



On 19/05/17 10:28, Mian Yousaf Kaukab wrote:

Low Power Idle(LPI) support added acpi_processor_ffh_lpi_probe() and
acpi_processor_ffh_lpi_enter() as __weak functions and arch code is
supposed to provide the actual callbacks. This breaks if
ACPI_PROCESSOR is configured as a module.

Add CONFIG_ARCH_HAS_ACPI_LPI configuration option to fix this.



Rafael didn't like the extra Kconfig option when I first posted
LPI patches.


Signed-off-by: Mian Yousaf Kaukab 
---
  arch/arm64/Kconfig| 1 +
  arch/arm64/kernel/cpuidle.c   | 2 ++
  drivers/acpi/Kconfig  | 3 +++
  drivers/acpi/processor_idle.c | 9 +++--
  4 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 848a34116c67..de2f2779cdf5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -10,6 +10,7 @@ config ARM64
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
+   select ARCH_HAS_ACPI_LPI if ACPI
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
index fd691087dc9a..002d9cb890bd 100644
--- a/arch/arm64/kernel/cpuidle.c
+++ b/arch/arm64/kernel/cpuidle.c
@@ -51,9 +51,11 @@ int acpi_processor_ffh_lpi_probe(unsigned int cpu)
  {
return arm_cpuidle_init(cpu);
  }
+EXPORT_SYMBOL(acpi_processor_ffh_lpi_probe);
  
  int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)

  {
return CPU_PM_CPU_IDLE_ENTER(arm_cpuidle_suspend, lpi->index);
  }
+EXPORT_SYMBOL(acpi_processor_ffh_lpi_enter);


Won't these 2 export suffice ? [...]

No, they don't suffice.


[...] I am just curious why that won't work.

I am not really sure. System.map shows the exported symbols as following:
08095898 T acpi_processor_ffh_lpi_probe
080958f8 T acpi_processor_ffh_lpi_enter
08c19160 R __ksymtab_acpi_processor_ffh_lpi_enter
08c19170 R __ksymtab_acpi_processor_ffh_lpi_probe
08c357f0 r __kcrctab_acpi_processor_ffh_lpi_enter
08c357f8 r __kcrctab_acpi_processor_ffh_lpi_probe
08c4361b r __kstrtab_acpi_processor_ffh_lpi_enter
08c43638 r __kstrtab_acpi_processor_ffh_lpi_probe

and 'nm processor.ko' shows that they are defined as weak:

0d68 W acpi_processor_ffh_lpi_enter
0cc8 W acpi_processor_ffh_lpi_probe

But still weak symbols are happily used when the module is inserted.


Will weak function definitions be still picked when built as modules ?

Yes.

BR,
Yousaf

[PATCH] ACPI: processor: fix LPI when built as module

[Mian Yousaf Kaukab]

Low Power Idle(LPI) support added acpi_processor_ffh_lpi_probe() and
acpi_processor_ffh_lpi_enter() as __weak functions and arch code is
supposed to provide the actual callbacks. This breaks if
ACPI_PROCESSOR is configured as a module.

Add CONFIG_ARCH_HAS_ACPI_LPI configuration option to fix this.

Signed-off-by: Mian Yousaf Kaukab <yousaf.kau...@suse.com>
---
 arch/arm64/Kconfig| 1 +
 arch/arm64/kernel/cpuidle.c   | 2 ++
 drivers/acpi/Kconfig  | 3 +++
 drivers/acpi/processor_idle.c | 9 +++--
 4 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 848a34116c67..de2f2779cdf5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -10,6 +10,7 @@ config ARM64
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
+   select ARCH_HAS_ACPI_LPI if ACPI
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
index fd691087dc9a..002d9cb890bd 100644
--- a/arch/arm64/kernel/cpuidle.c
+++ b/arch/arm64/kernel/cpuidle.c
@@ -51,9 +51,11 @@ int acpi_processor_ffh_lpi_probe(unsigned int cpu)
 {
return arm_cpuidle_init(cpu);
 }
+EXPORT_SYMBOL(acpi_processor_ffh_lpi_probe);
 
 int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
 {
return CPU_PM_CPU_IDLE_ENTER(arm_cpuidle_suspend, lpi->index);
 }
+EXPORT_SYMBOL(acpi_processor_ffh_lpi_enter);
 #endif
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f84dc23..7e5a7bce9d72 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -224,6 +224,9 @@ config ACPI_PROCESSOR_IDLE
bool
select CPU_IDLE
 
+config ARCH_HAS_ACPI_LPI
+   def_bool n
+
 config ACPI_MCFG
bool
 
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 5c8aa9cf62d7..321fe9acd8e8 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1211,15 +1211,20 @@ static int acpi_processor_get_lpi_info(struct 
acpi_processor *pr)
return 0;
 }
 
-int __weak acpi_processor_ffh_lpi_probe(unsigned int cpu)
+#ifdef CONFIG_ARCH_HAS_ACPI_LPI
+int acpi_processor_ffh_lpi_probe(unsigned int cpu);
+int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi);
+#else
+static int acpi_processor_ffh_lpi_probe(unsigned int cpu)
 {
return -ENODEV;
 }
 
-int __weak acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
+static int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
 {
return -ENODEV;
 }
+#endif /* CONFIG_ARCH_HAS_ACPI_LPI */
 
 /**
  * acpi_idle_lpi_enter - enters an ACPI any LPI state
-- 
2.11.0

[PATCH] ACPI: processor: fix LPI when built as module

[Mian Yousaf Kaukab]

Low Power Idle(LPI) support added acpi_processor_ffh_lpi_probe() and
acpi_processor_ffh_lpi_enter() as __weak functions and arch code is
supposed to provide the actual callbacks. This breaks if
ACPI_PROCESSOR is configured as a module.

Add CONFIG_ARCH_HAS_ACPI_LPI configuration option to fix this.

Signed-off-by: Mian Yousaf Kaukab 
---
 arch/arm64/Kconfig| 1 +
 arch/arm64/kernel/cpuidle.c   | 2 ++
 drivers/acpi/Kconfig  | 3 +++
 drivers/acpi/processor_idle.c | 9 +++--
 4 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 848a34116c67..de2f2779cdf5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -10,6 +10,7 @@ config ARM64
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
+   select ARCH_HAS_ACPI_LPI if ACPI
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
index fd691087dc9a..002d9cb890bd 100644
--- a/arch/arm64/kernel/cpuidle.c
+++ b/arch/arm64/kernel/cpuidle.c
@@ -51,9 +51,11 @@ int acpi_processor_ffh_lpi_probe(unsigned int cpu)
 {
return arm_cpuidle_init(cpu);
 }
+EXPORT_SYMBOL(acpi_processor_ffh_lpi_probe);
 
 int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
 {
return CPU_PM_CPU_IDLE_ENTER(arm_cpuidle_suspend, lpi->index);
 }
+EXPORT_SYMBOL(acpi_processor_ffh_lpi_enter);
 #endif
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f84dc23..7e5a7bce9d72 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -224,6 +224,9 @@ config ACPI_PROCESSOR_IDLE
bool
select CPU_IDLE
 
+config ARCH_HAS_ACPI_LPI
+   def_bool n
+
 config ACPI_MCFG
bool
 
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 5c8aa9cf62d7..321fe9acd8e8 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1211,15 +1211,20 @@ static int acpi_processor_get_lpi_info(struct 
acpi_processor *pr)
return 0;
 }
 
-int __weak acpi_processor_ffh_lpi_probe(unsigned int cpu)
+#ifdef CONFIG_ARCH_HAS_ACPI_LPI
+int acpi_processor_ffh_lpi_probe(unsigned int cpu);
+int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi);
+#else
+static int acpi_processor_ffh_lpi_probe(unsigned int cpu)
 {
return -ENODEV;
 }
 
-int __weak acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
+static int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
 {
return -ENODEV;
 }
+#endif /* CONFIG_ARCH_HAS_ACPI_LPI */
 
 /**
  * acpi_idle_lpi_enter - enters an ACPI any LPI state
-- 
2.11.0

[PATCH v1] irqdomain: add empty irq_domain_check_msi_remap

[Mian Yousaf Kaukab]

Fix following build error for s390:
drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group':
drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of 
function 'irq_domain_check_msi_remap'

Signed-off-by: Mian Yousaf Kaukab <yousaf.kau...@suse.com>
---
History:
v1:
 -Return false instead of true as suggested by Marc and Eric.
 -Drop 2/2

 include/linux/irqdomain.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 188eced6813e..9f3616085423 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -524,6 +524,10 @@ static inline struct irq_domain *irq_find_matching_fwnode(
 {
return NULL;
 }
+static inline bool irq_domain_check_msi_remap(void)
+{
+   return false;
+}
 #endif /* !CONFIG_IRQ_DOMAIN */
 
 #endif /* _LINUX_IRQDOMAIN_H */
-- 
2.11.0

[PATCH v1] irqdomain: add empty irq_domain_check_msi_remap

[Mian Yousaf Kaukab]

Fix following build error for s390:
drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group':
drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of 
function 'irq_domain_check_msi_remap'

Signed-off-by: Mian Yousaf Kaukab 
---
History:
v1:
 -Return false instead of true as suggested by Marc and Eric.
 -Drop 2/2

 include/linux/irqdomain.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 188eced6813e..9f3616085423 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -524,6 +524,10 @@ static inline struct irq_domain *irq_find_matching_fwnode(
 {
return NULL;
 }
+static inline bool irq_domain_check_msi_remap(void)
+{
+   return false;
+}
 #endif /* !CONFIG_IRQ_DOMAIN */
 
 #endif /* _LINUX_IRQDOMAIN_H */
-- 
2.11.0

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

[Mian Yousaf Kaukab]

On 03/02/2017 02:46 PM, Auger Eric wrote:

Hi,

On 02/03/2017 13:38, Mian Yousaf Kaukab wrote:

On 03/02/2017 11:24 AM, Auger Eric wrote:

Hi,

On 02/03/2017 11:01, Mian Yousaf Kaukab wrote:

Check only if irq domains are available.

Signed-off-by: Mian Yousaf Kaukab <yousaf.kau...@suse.com>
---
   drivers/vfio/vfio_iommu_type1.c | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c
b/drivers/vfio/vfio_iommu_type1.c
index bd6f293c4ebd..e3ed50e40ead 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1287,8 +1287,9 @@ static int vfio_iommu_type1_attach_group(void
*iommu_data,
   INIT_LIST_HEAD(>group_list);
   list_add(>next, >group_list);
   -msi_remap = resv_msi ? irq_domain_check_msi_remap() :
-iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
+msi_remap = resv_msi && IS_ENABLED(CONFIG_IRQ_DOMAIN) ?
+irq_domain_check_msi_remap() :
+iommu_capable(bus, IOMMU_CAP_INTR_REMAP);

Is that patch actually needed after [PATCH 1/2] irqdomain: add empty
irq_domain_check_msi_remap. irq_domain_check_msi_remap() should be
defined and if you follow my suggestion, would return false. Anyway in
your case resv_msi should be false.

I agree its an overkill if resv_msi is guaranteed to be false. What I am
unsure about is that, if iommu have IOMMU_RESV_MSI regions that would
mean that irq domains are selected in the build. If this is not
guaranteed, then we need to add this check.


Currently only ARM SMMUs advertise IOMMU_RESV_MSI regions. If attempting
to do passthrough on an ARM platform not implementing IRQ_DOMAIN the
unsafe IRQ assignment mode would need to be chosen (if
irq_domain_check_msi_remap() returns false as discussed before). Anyway
checking the  interrupt remapping capability on IOMMU side would report
false as well since the capability is not exposed by ARM SMMU anymore.OK I will drop this patch. We get a warning anyway in case the 

capability is checked from the wrong place.

BR,
Yousaf

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

[Mian Yousaf Kaukab]

On 03/02/2017 02:46 PM, Auger Eric wrote:

Hi,

On 02/03/2017 13:38, Mian Yousaf Kaukab wrote:

On 03/02/2017 11:24 AM, Auger Eric wrote:

Hi,

On 02/03/2017 11:01, Mian Yousaf Kaukab wrote:

Check only if irq domains are available.

Signed-off-by: Mian Yousaf Kaukab 
---
   drivers/vfio/vfio_iommu_type1.c | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c
b/drivers/vfio/vfio_iommu_type1.c
index bd6f293c4ebd..e3ed50e40ead 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1287,8 +1287,9 @@ static int vfio_iommu_type1_attach_group(void
*iommu_data,
   INIT_LIST_HEAD(>group_list);
   list_add(>next, >group_list);
   -msi_remap = resv_msi ? irq_domain_check_msi_remap() :
-iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
+msi_remap = resv_msi && IS_ENABLED(CONFIG_IRQ_DOMAIN) ?
+irq_domain_check_msi_remap() :
+iommu_capable(bus, IOMMU_CAP_INTR_REMAP);

Is that patch actually needed after [PATCH 1/2] irqdomain: add empty
irq_domain_check_msi_remap. irq_domain_check_msi_remap() should be
defined and if you follow my suggestion, would return false. Anyway in
your case resv_msi should be false.

I agree its an overkill if resv_msi is guaranteed to be false. What I am
unsure about is that, if iommu have IOMMU_RESV_MSI regions that would
mean that irq domains are selected in the build. If this is not
guaranteed, then we need to add this check.


Currently only ARM SMMUs advertise IOMMU_RESV_MSI regions. If attempting
to do passthrough on an ARM platform not implementing IRQ_DOMAIN the
unsafe IRQ assignment mode would need to be chosen (if
irq_domain_check_msi_remap() returns false as discussed before). Anyway
checking the  interrupt remapping capability on IOMMU side would report
false as well since the capability is not exposed by ARM SMMU anymore.OK I will drop this patch. We get a warning anyway in case the 

capability is checked from the wrong place.

BR,
Yousaf

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

[Mian Yousaf Kaukab]

On 03/02/2017 02:12 PM, Auger Eric wrote:

Hi Yousaf,

On 02/03/2017 13:23, Mian Yousaf Kaukab wrote:

On 03/02/2017 11:24 AM, Auger Eric wrote:

Hi Mian Yousaf,

On 02/03/2017 11:01, Mian Yousaf Kaukab wrote:

Fix following build error for s390:
drivers/vfio/vfio_iommu_type1.c: In function
'vfio_iommu_type1_attach_group':
drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration
of function 'irq_domain_check_msi_remap'

Signed-off-by: Mian Yousaf Kaukab <yousaf.kau...@suse.com>
---
   include/linux/irqdomain.h | 4 
   1 file changed, 4 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 188eced6813e..137817b08cdc 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -524,6 +524,10 @@ static inline struct irq_domain
*irq_find_matching_fwnode(
   {
   return NULL;
   }
+static inline bool irq_domain_check_msi_remap(void)
+{
+return true;

By default you should rather return false, reporting there is no MSI
remapping capability on irq domain side. Besides thank you for the fix.

I choose to return true based on the function header comments of
irq_domain_check_msi_remap. It says

"Return: false if any MSI irq domain does not support IRQ remapping,
true otherwise (including if there is no MSI irq domain)"

So function should return true in case of no MSI irq domain. Have I miss
understood this?

This behavior is indeed mandated on ARM - where MSI are translated by
the smmu - to allow safe device assignment if there is no MSI domain,
ie. in this situation there is no risk an assigned device writes into an
MSI doorbell.

As the function is not implemented at all in your case, personally I
would rather be defensive though and return false. You were not able to
check the capability.

OK Agree. I will send an update as soon as a decision is made on 2/2.

BR,
Yousaf

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

[Mian Yousaf Kaukab]

On 03/02/2017 02:12 PM, Auger Eric wrote:

Hi Yousaf,

On 02/03/2017 13:23, Mian Yousaf Kaukab wrote:

On 03/02/2017 11:24 AM, Auger Eric wrote:

Hi Mian Yousaf,

On 02/03/2017 11:01, Mian Yousaf Kaukab wrote:

Fix following build error for s390:
drivers/vfio/vfio_iommu_type1.c: In function
'vfio_iommu_type1_attach_group':
drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration
of function 'irq_domain_check_msi_remap'

Signed-off-by: Mian Yousaf Kaukab 
---
   include/linux/irqdomain.h | 4 
   1 file changed, 4 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 188eced6813e..137817b08cdc 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -524,6 +524,10 @@ static inline struct irq_domain
*irq_find_matching_fwnode(
   {
   return NULL;
   }
+static inline bool irq_domain_check_msi_remap(void)
+{
+return true;

By default you should rather return false, reporting there is no MSI
remapping capability on irq domain side. Besides thank you for the fix.

I choose to return true based on the function header comments of
irq_domain_check_msi_remap. It says

"Return: false if any MSI irq domain does not support IRQ remapping,
true otherwise (including if there is no MSI irq domain)"

So function should return true in case of no MSI irq domain. Have I miss
understood this?

This behavior is indeed mandated on ARM - where MSI are translated by
the smmu - to allow safe device assignment if there is no MSI domain,
ie. in this situation there is no risk an assigned device writes into an
MSI doorbell.

As the function is not implemented at all in your case, personally I
would rather be defensive though and return false. You were not able to
check the capability.

OK Agree. I will send an update as soon as a decision is made on 2/2.

BR,
Yousaf

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

[Mian Yousaf Kaukab]

On 03/02/2017 11:24 AM, Auger Eric wrote:

Hi,

On 02/03/2017 11:01, Mian Yousaf Kaukab wrote:

Check only if irq domains are available.

Signed-off-by: Mian Yousaf Kaukab <yousaf.kau...@suse.com>
---
  drivers/vfio/vfio_iommu_type1.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index bd6f293c4ebd..e3ed50e40ead 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1287,8 +1287,9 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
INIT_LIST_HEAD(>group_list);
list_add(>next, >group_list);
  
-	msi_remap = resv_msi ? irq_domain_check_msi_remap() :

-   iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
+   msi_remap = resv_msi && IS_ENABLED(CONFIG_IRQ_DOMAIN) ?
+   irq_domain_check_msi_remap() :
+   iommu_capable(bus, IOMMU_CAP_INTR_REMAP);

Is that patch actually needed after [PATCH 1/2] irqdomain: add empty
irq_domain_check_msi_remap. irq_domain_check_msi_remap() should be
defined and if you follow my suggestion, would return false. Anyway in
your case resv_msi should be false.
I agree its an overkill if resv_msi is guaranteed to be false. What I am 
unsure about is that, if iommu have IOMMU_RESV_MSI regions that would 
mean that irq domains are selected in the build. If this is not 
guaranteed, then we need to add this check.




Thanks

Eric


BR,
Yousaf

Re: [PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

[Mian Yousaf Kaukab]

On 03/02/2017 11:24 AM, Auger Eric wrote:

Hi,

On 02/03/2017 11:01, Mian Yousaf Kaukab wrote:

Check only if irq domains are available.

Signed-off-by: Mian Yousaf Kaukab 
---
  drivers/vfio/vfio_iommu_type1.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index bd6f293c4ebd..e3ed50e40ead 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1287,8 +1287,9 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
INIT_LIST_HEAD(>group_list);
list_add(>next, >group_list);
  
-	msi_remap = resv_msi ? irq_domain_check_msi_remap() :

-   iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
+   msi_remap = resv_msi && IS_ENABLED(CONFIG_IRQ_DOMAIN) ?
+   irq_domain_check_msi_remap() :
+   iommu_capable(bus, IOMMU_CAP_INTR_REMAP);

Is that patch actually needed after [PATCH 1/2] irqdomain: add empty
irq_domain_check_msi_remap. irq_domain_check_msi_remap() should be
defined and if you follow my suggestion, would return false. Anyway in
your case resv_msi should be false.
I agree its an overkill if resv_msi is guaranteed to be false. What I am 
unsure about is that, if iommu have IOMMU_RESV_MSI regions that would 
mean that irq domains are selected in the build. If this is not 
guaranteed, then we need to add this check.




Thanks

Eric


BR,
Yousaf

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

[Mian Yousaf Kaukab]

On 03/02/2017 11:24 AM, Auger Eric wrote:

Hi Mian Yousaf,

On 02/03/2017 11:01, Mian Yousaf Kaukab wrote:

Fix following build error for s390:
drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group':
drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of 
function 'irq_domain_check_msi_remap'

Signed-off-by: Mian Yousaf Kaukab <yousaf.kau...@suse.com>
---
  include/linux/irqdomain.h | 4 
  1 file changed, 4 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 188eced6813e..137817b08cdc 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -524,6 +524,10 @@ static inline struct irq_domain *irq_find_matching_fwnode(
  {
return NULL;
  }
+static inline bool irq_domain_check_msi_remap(void)
+{
+   return true;

By default you should rather return false, reporting there is no MSI
remapping capability on irq domain side. Besides thank you for the fix.
I choose to return true based on the function header comments of 
irq_domain_check_msi_remap. It says


"Return: false if any MSI irq domain does not support IRQ remapping, 
true otherwise (including if there is no MSI irq domain)"


So function should return true in case of no MSI irq domain. Have I miss 
understood this?


BR,
Yousaf

Re: [PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

[Mian Yousaf Kaukab]

On 03/02/2017 11:24 AM, Auger Eric wrote:

Hi Mian Yousaf,

On 02/03/2017 11:01, Mian Yousaf Kaukab wrote:

Fix following build error for s390:
drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group':
drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of 
function 'irq_domain_check_msi_remap'

Signed-off-by: Mian Yousaf Kaukab 
---
  include/linux/irqdomain.h | 4 
  1 file changed, 4 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 188eced6813e..137817b08cdc 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -524,6 +524,10 @@ static inline struct irq_domain *irq_find_matching_fwnode(
  {
return NULL;
  }
+static inline bool irq_domain_check_msi_remap(void)
+{
+   return true;

By default you should rather return false, reporting there is no MSI
remapping capability on irq domain side. Besides thank you for the fix.
I choose to return true based on the function header comments of 
irq_domain_check_msi_remap. It says


"Return: false if any MSI irq domain does not support IRQ remapping, 
true otherwise (including if there is no MSI irq domain)"


So function should return true in case of no MSI irq domain. Have I miss 
understood this?


BR,
Yousaf

[PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

[Mian Yousaf Kaukab]

Check only if irq domains are available.

Signed-off-by: Mian Yousaf Kaukab <yousaf.kau...@suse.com>
---
 drivers/vfio/vfio_iommu_type1.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index bd6f293c4ebd..e3ed50e40ead 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1287,8 +1287,9 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
INIT_LIST_HEAD(>group_list);
list_add(>next, >group_list);
 
-   msi_remap = resv_msi ? irq_domain_check_msi_remap() :
-   iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
+   msi_remap = resv_msi && IS_ENABLED(CONFIG_IRQ_DOMAIN) ?
+   irq_domain_check_msi_remap() :
+   iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
 
if (!allow_unsafe_interrupts && !msi_remap) {
pr_warn("%s: No interrupt remapping support.  Use the module 
param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this 
platform\n",
-- 
2.11.0

[PATCH 2/2] vfio: type1: conditionally check MSI remapping at irq domain level

[Mian Yousaf Kaukab]

Check only if irq domains are available.

Signed-off-by: Mian Yousaf Kaukab 
---
 drivers/vfio/vfio_iommu_type1.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index bd6f293c4ebd..e3ed50e40ead 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -1287,8 +1287,9 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
INIT_LIST_HEAD(>group_list);
list_add(>next, >group_list);
 
-   msi_remap = resv_msi ? irq_domain_check_msi_remap() :
-   iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
+   msi_remap = resv_msi && IS_ENABLED(CONFIG_IRQ_DOMAIN) ?
+   irq_domain_check_msi_remap() :
+   iommu_capable(bus, IOMMU_CAP_INTR_REMAP);
 
if (!allow_unsafe_interrupts && !msi_remap) {
pr_warn("%s: No interrupt remapping support.  Use the module 
param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this 
platform\n",
-- 
2.11.0

[PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

[Mian Yousaf Kaukab]

Fix following build error for s390:
drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group':
drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of 
function 'irq_domain_check_msi_remap'

Signed-off-by: Mian Yousaf Kaukab <yousaf.kau...@suse.com>
---
 include/linux/irqdomain.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 188eced6813e..137817b08cdc 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -524,6 +524,10 @@ static inline struct irq_domain *irq_find_matching_fwnode(
 {
return NULL;
 }
+static inline bool irq_domain_check_msi_remap(void)
+{
+   return true;
+}
 #endif /* !CONFIG_IRQ_DOMAIN */
 
 #endif /* _LINUX_IRQDOMAIN_H */
-- 
2.11.0

[PATCH 1/2] irqdomain: add empty irq_domain_check_msi_remap

[Mian Yousaf Kaukab]

Fix following build error for s390:
drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group':
drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of 
function 'irq_domain_check_msi_remap'

Signed-off-by: Mian Yousaf Kaukab 
---
 include/linux/irqdomain.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 188eced6813e..137817b08cdc 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -524,6 +524,10 @@ static inline struct irq_domain *irq_find_matching_fwnode(
 {
return NULL;
 }
+static inline bool irq_domain_check_msi_remap(void)
+{
+   return true;
+}
 #endif /* !CONFIG_IRQ_DOMAIN */
 
 #endif /* _LINUX_IRQDOMAIN_H */
-- 
2.11.0

[PATCH v1 Resend] usb: dwc2: gadget: fix a memory use-after-free bug

[Mian Yousaf Kaukab]

From: Yunzhi Li 

When dwc2_hsotg_handle_unaligned_buf_complete() hs_req->req.buf
already destroyed, in dwc2_hsotg_unmap_dma(), it touches
hs_req->req.dma again, so dwc2_hsotg_unmap_dma() should be called
before dwc2_hsotg_handle_unaligned_buf_complete(). Otherwise, it
will cause a bad_page BUG, when allocate this memory page next
time.

This bug led to the following crash:

BUG: Bad page state in process swapper/0  pfn:2bdbc
[   26.820440] page:eed76780 count:0 mapcount:0 mapping:  (null) index:0x0
[   26.854710] page flags: 0x200(arch_1)
[   26.885836] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
[   26.919179] bad because of flags:
[   26.948917] page flags: 0x200(arch_1)
[   26.979100] Modules linked in:
[   27.008401] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W3.14.0 #17
[   27.041816] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   27.076108] [] (show_stack) from [] 
(dump_stack+0x70/0x8c)
[   27.110246] [] (dump_stack) from [] (bad_page+0xfc/0x12c)
[   27.143958] [] (bad_page) from [] 
(get_page_from_freelist+0x3e4/0x50c)
[   27.179298] [] (get_page_from_freelist) from [] 
(__alloc_pages_nodemask)
[   27.216296] [] (__alloc_pages_nodemask) from [] 
(__get_free_pages+0x20/)
[   27.252326] [] (__get_free_pages) from [] 
(kmalloc_order_trace+0x34/0xa)
[   27.288295] [] (kmalloc_order_trace) from [] 
(__kmalloc+0x40/0x1ac)
[   27.323751] [] (__kmalloc) from [] 
(dwc2_hsotg_ep_queue.isra.12+0x7c/0x1)
[   27.359937] [] (dwc2_hsotg_ep_queue.isra.12) from [] 
(dwc2_hsotg_ep_queue)
[   27.397478] [] (dwc2_hsotg_ep_queue_lock) from [] 
(rx_submit+0xfc/0x164)
[   27.433619] [] (rx_submit) from [] 
(rx_complete+0x22c/0x230)
[   27.468872] [] (rx_complete) from [] 
(dwc2_hsotg_complete_request+0xfc/0)
[   27.506240] [] (dwc2_hsotg_complete_request) from [] 
(dwc2_hsotg_handle_o)
[   27.545401] [] (dwc2_hsotg_handle_outdone) from [] 
(dwc2_hsotg_epint+0x2c)
[   27.583689] [] (dwc2_hsotg_epint) from [] 
(dwc2_hsotg_irq+0x1dc/0x4ac)
[   27.621041] [] (dwc2_hsotg_irq) from [] 
(handle_irq_event_percpu+0x70/0x)
[   27.659066] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x4c)
[   27.697322] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0xc8/0x11)
[   27.735451] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x30/0x)
[   27.773918] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x84/0)
[   27.812018] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x48/0x6c)
[   27.849695] [] (gic_handle_irq) from [] 
(__irq_svc+0x40/0x50)
[   27.886907] Exception stack(0xc0d01ee0 to 0xc0d01f28)

Acked-by: John Youn 
Tested-by: Heiko Stuebner 
Tested-by: Jeffy Chen 
Signed-off-by: Yunzhi Li 
---
Resending on Yunzhi's behalf since he is travelling.

 drivers/usb/dwc2/gadget.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 12ac879..5755e65 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1390,14 +1390,14 @@ static void dwc2_hsotg_complete_request(struct 
dwc2_hsotg *hsotg,
if (hs_req->req.status == -EINPROGRESS)
hs_req->req.status = result;
 
+   if (using_dma(hsotg))
+   dwc2_hsotg_unmap_dma(hsotg, hs_ep, hs_req);
+
dwc2_hsotg_handle_unaligned_buf_complete(hsotg, hs_ep, hs_req);
 
hs_ep->req = NULL;
list_del_init(_req->queue);
 
-   if (using_dma(hsotg))
-   dwc2_hsotg_unmap_dma(hsotg, hs_ep, hs_req);
-
/*
 * call the complete request with the locks off, just in case the
 * request tries to queue more work for this endpoint.
-- 
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 Resend] usb: dwc2: gadget: fix a memory use-after-free bug

[Mian Yousaf Kaukab]

From: Yunzhi Li 

When dwc2_hsotg_handle_unaligned_buf_complete() hs_req->req.buf
already destroyed, in dwc2_hsotg_unmap_dma(), it touches
hs_req->req.dma again, so dwc2_hsotg_unmap_dma() should be called
before dwc2_hsotg_handle_unaligned_buf_complete(). Otherwise, it
will cause a bad_page BUG, when allocate this memory page next
time.

This bug led to the following crash:

BUG: Bad page state in process swapper/0  pfn:2bdbc
[   26.820440] page:eed76780 count:0 mapcount:0 mapping:  (null) index:0x0
[   26.854710] page flags: 0x200(arch_1)
[   26.885836] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
[   26.919179] bad because of flags:
[   26.948917] page flags: 0x200(arch_1)
[   26.979100] Modules linked in:
[   27.008401] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W3.14.0 #17
[   27.041816] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   27.076108] [] (show_stack) from [] 
(dump_stack+0x70/0x8c)
[   27.110246] [] (dump_stack) from [] (bad_page+0xfc/0x12c)
[   27.143958] [] (bad_page) from [] 
(get_page_from_freelist+0x3e4/0x50c)
[   27.179298] [] (get_page_from_freelist) from [] 
(__alloc_pages_nodemask)
[   27.216296] [] (__alloc_pages_nodemask) from [] 
(__get_free_pages+0x20/)
[   27.252326] [] (__get_free_pages) from [] 
(kmalloc_order_trace+0x34/0xa)
[   27.288295] [] (kmalloc_order_trace) from [] 
(__kmalloc+0x40/0x1ac)
[   27.323751] [] (__kmalloc) from [] 
(dwc2_hsotg_ep_queue.isra.12+0x7c/0x1)
[   27.359937] [] (dwc2_hsotg_ep_queue.isra.12) from [] 
(dwc2_hsotg_ep_queue)
[   27.397478] [] (dwc2_hsotg_ep_queue_lock) from [] 
(rx_submit+0xfc/0x164)
[   27.433619] [] (rx_submit) from [] 
(rx_complete+0x22c/0x230)
[   27.468872] [] (rx_complete) from [] 
(dwc2_hsotg_complete_request+0xfc/0)
[   27.506240] [] (dwc2_hsotg_complete_request) from [] 
(dwc2_hsotg_handle_o)
[   27.545401] [] (dwc2_hsotg_handle_outdone) from [] 
(dwc2_hsotg_epint+0x2c)
[   27.583689] [] (dwc2_hsotg_epint) from [] 
(dwc2_hsotg_irq+0x1dc/0x4ac)
[   27.621041] [] (dwc2_hsotg_irq) from [] 
(handle_irq_event_percpu+0x70/0x)
[   27.659066] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x4c)
[   27.697322] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0xc8/0x11)
[   27.735451] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x30/0x)
[   27.773918] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x84/0)
[   27.812018] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x48/0x6c)
[   27.849695] [] (gic_handle_irq) from [] 
(__irq_svc+0x40/0x50)
[   27.886907] Exception stack(0xc0d01ee0 to 0xc0d01f28)

Acked-by: John Youn 
Tested-by: Heiko Stuebner 
Tested-by: Jeffy Chen 
Signed-off-by: Yunzhi Li 
---
Resending on Yunzhi's behalf since he is travelling.

 drivers/usb/dwc2/gadget.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 12ac879..5755e65 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1390,14 +1390,14 @@ static void dwc2_hsotg_complete_request(struct 
dwc2_hsotg *hsotg,
if (hs_req->req.status == -EINPROGRESS)
hs_req->req.status = result;
 
+   if (using_dma(hsotg))
+   dwc2_hsotg_unmap_dma(hsotg, hs_ep, hs_req);
+
dwc2_hsotg_handle_unaligned_buf_complete(hsotg, hs_ep, hs_req);
 
hs_ep->req = NULL;
list_del_init(_req->queue);
 
-   if (using_dma(hsotg))
-   dwc2_hsotg_unmap_dma(hsotg, hs_ep, hs_req);
-
/*
 * call the complete request with the locks off, just in case the
 * request tries to queue more work for this endpoint.
-- 
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/