* Re: [PATCH v4 4/4] thermal: cpuidle: Register cpuidle cooling device
From: Sudeep Holla @ 2020-05-15 9:58 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Lorenzo Pieralisi, open list:CPU IDLE TIME MANAGEMENT FRAMEWORK,
Rafael J. Wysocki, open list, open list:CPUIDLE DRIVER - ARM PSCI,
Sudeep Holla, rui.zhang, Lukasz Luba
In-Reply-To: <f3cee834-4946-10bd-a504-df6cf62d9e90@linaro.org>
On Mon, May 04, 2020 at 08:00:01PM +0200, Daniel Lezcano wrote:
>
> Hi,
>
> On 29/04/2020 23:01, Daniel Lezcano wrote:
> > On 29/04/2020 22:02, Lukasz Luba wrote:
> >>
> >>
> >> On 4/29/20 11:36 AM, Daniel Lezcano wrote:
> >>> The cpuidle driver can be used as a cooling device by injecting idle
> >>> cycles. The DT binding for the idle state added an optional
> >>>
> >>> When the property is set, register the cpuidle driver with the idle
> >>> state node pointer as a cooling device. The thermal framework will do
> >>> the association automatically with the thermal zone via the
> >>> cooling-device defined in the device tree cooling-maps section.
> >>>
> >>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >>> ---
> >>> - V4:
> >>> - Do not check the return value as the function does no longer
> >>> return one
> >>> ---
> >
> > [ ... ]
> >
> >> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
> >
> > Thanks Lukasz for the review.
> >
> > Rafael, as Lorenzo and Sudeep are not responsive, could you consider ack
> > this patch so I can merge the series through the thermal tree ?
>
> Gentle ping ... Sudeep, Lorenzo or Rafael ?
>
Sorry for the delay. I ignore this as it was generic and I was fine with
it. Didn't know you were waiting me, sorry for that.
FWIW:
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/5] PCI: uniphier: Add features for UniPhier PCIe host controller
From: Kunihiko Hayashi @ 2020-05-15 9:58 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
This series adds some features for UniPhier PCIe host controller.
- Add support for PME and AER invoked by MSI interrupt
- Add iATU register view support for PCIe version >= 4.80
- Add an error message when failing to get phy driver
This adds a new function called by MSI handler in DesignWare PCIe framework,
that invokes PME and AER funcions to detect the factor from SoC-dependent
registers.
Changes since v1:
- Add check if struct resource is NULL
- Fix warning in the type of dev_err() argument
Kunihiko Hayashi (5):
PCI: dwc: Add msi_host_isr() callback
PCI: uniphier: Add misc interrupt handler to invoke PME and AER
dt-bindings: PCI: uniphier: Add iATU register description
PCI: uniphier: Add iATU register support
PCI: uniphier: Add error message when failed to get phy
.../devicetree/bindings/pci/uniphier-pcie.txt | 1 +
drivers/pci/controller/dwc/pcie-designware-host.c | 8 +--
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/dwc/pcie-uniphier.c | 67 +++++++++++++++++-----
4 files changed, 60 insertions(+), 17 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/5] PCI: dwc: Add msi_host_isr() callback
From: Kunihiko Hayashi @ 2020-05-15 9:58 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589536743-6684-1-git-send-email-hayashi.kunihiko@socionext.com>
This adds msi_host_isr() callback function support to describe
SoC-dependent service triggered by MSI.
For example, when AER interrupt is triggered by MSI, the callback function
reads SoC-dependent registers and detects that the interrupt is from AER,
and invoke AER interrupts related to MSI.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++----
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 42fbfe2..7dd1021 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -112,13 +112,13 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
static void dw_chained_msi_isr(struct irq_desc *desc)
{
struct irq_chip *chip = irq_desc_get_chip(desc);
- struct pcie_port *pp;
+ struct pcie_port *pp = irq_desc_get_handler_data(desc);
- chained_irq_enter(chip, desc);
+ if (pp->ops->msi_host_isr)
+ pp->ops->msi_host_isr(pp);
- pp = irq_desc_get_handler_data(desc);
+ chained_irq_enter(chip, desc);
dw_handle_msi_irq(pp);
-
chained_irq_exit(chip, desc);
}
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 656e00f..e741967 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -170,6 +170,7 @@ struct dw_pcie_host_ops {
void (*scan_bus)(struct pcie_port *pp);
void (*set_num_vectors)(struct pcie_port *pp);
int (*msi_host_init)(struct pcie_port *pp);
+ void (*msi_host_isr)(struct pcie_port *pp);
};
struct pcie_port {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/5] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Kunihiko Hayashi @ 2020-05-15 9:59 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589536743-6684-1-git-send-email-hayashi.kunihiko@socionext.com>
The misc interrupts consisting of PME, AER, and Link event, is handled
by INTx handler, however, these interrupts should be also handled by
MSI handler.
This adds the function uniphier_pcie_misc_isr() that handles misc
intterupts, which is called from both INTx and MSI handlers.
This function detects PME and AER interrupts with the status register,
and invoke PME and AER drivers related to INTx or MSI.
And this sets the mask for misc interrupts from INTx if MSI is enabled
and sets the mask for misc interrupts from MSI if MSI is disabled.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 53 +++++++++++++++++++++++-------
1 file changed, 42 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index a5401a0..a8dda39 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -44,7 +44,9 @@
#define PCL_SYS_AUX_PWR_DET BIT(8)
#define PCL_RCV_INT 0x8108
+#define PCL_RCV_INT_ALL_INT_MASK GENMASK(28, 25)
#define PCL_RCV_INT_ALL_ENABLE GENMASK(20, 17)
+#define PCL_RCV_INT_ALL_MSI_MASK GENMASK(12, 9)
#define PCL_CFG_BW_MGT_STATUS BIT(4)
#define PCL_CFG_LINK_AUTO_BW_STATUS BIT(3)
#define PCL_CFG_AER_RC_ERR_MSI_STATUS BIT(2)
@@ -167,7 +169,15 @@ static void uniphier_pcie_stop_link(struct dw_pcie *pci)
static void uniphier_pcie_irq_enable(struct uniphier_pcie_priv *priv)
{
- writel(PCL_RCV_INT_ALL_ENABLE, priv->base + PCL_RCV_INT);
+ u32 val;
+
+ val = PCL_RCV_INT_ALL_ENABLE;
+ if (pci_msi_enabled())
+ val |= PCL_RCV_INT_ALL_INT_MASK;
+ else
+ val |= PCL_RCV_INT_ALL_MSI_MASK;
+
+ writel(val, priv->base + PCL_RCV_INT);
writel(PCL_RCV_INTX_ALL_ENABLE, priv->base + PCL_RCV_INTX);
}
@@ -231,28 +241,48 @@ static const struct irq_domain_ops uniphier_intx_domain_ops = {
.map = uniphier_pcie_intx_map,
};
-static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+static void uniphier_pcie_misc_isr(struct pcie_port *pp)
{
- struct pcie_port *pp = irq_desc_get_handler_data(desc);
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
- struct irq_chip *chip = irq_desc_get_chip(desc);
- unsigned long reg;
- u32 val, bit, virq;
+ u32 val, virq;
- /* INT for debug */
val = readl(priv->base + PCL_RCV_INT);
if (val & PCL_CFG_BW_MGT_STATUS)
dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
+
if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
- if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
- dev_dbg(pci->dev, "Root Error\n");
- if (val & PCL_CFG_PME_MSI_STATUS)
- dev_dbg(pci->dev, "PME Interrupt\n");
+
+ if (pci_msi_enabled()) {
+ if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS) {
+ dev_dbg(pci->dev, "Root Error Status\n");
+ virq = irq_linear_revmap(pp->irq_domain, 0);
+ generic_handle_irq(virq);
+ }
+
+ if (val & PCL_CFG_PME_MSI_STATUS) {
+ dev_dbg(pci->dev, "PME Interrupt\n");
+ virq = irq_linear_revmap(pp->irq_domain, 0);
+ generic_handle_irq(virq);
+ }
+ }
writel(val, priv->base + PCL_RCV_INT);
+}
+
+static void uniphier_pcie_irq_handler(struct irq_desc *desc)
+{
+ struct pcie_port *pp = irq_desc_get_handler_data(desc);
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned long reg;
+ u32 val, bit, virq;
+
+ /* misc interrupt */
+ uniphier_pcie_misc_isr(pp);
/* INTx */
chained_irq_enter(chip, desc);
@@ -330,6 +360,7 @@ static int uniphier_pcie_host_init(struct pcie_port *pp)
static const struct dw_pcie_host_ops uniphier_pcie_host_ops = {
.host_init = uniphier_pcie_host_init,
+ .msi_host_isr = uniphier_pcie_misc_isr,
};
static int uniphier_add_pcie_port(struct uniphier_pcie_priv *priv,
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/5] dt-bindings: PCI: uniphier: Add iATU register description
From: Kunihiko Hayashi @ 2020-05-15 9:59 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589536743-6684-1-git-send-email-hayashi.kunihiko@socionext.com>
In the dt-bindings, "atu" reg-names is required to get the register space
for iATU in Synopsis DWC version 4.80 or later.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
Documentation/devicetree/bindings/pci/uniphier-pcie.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
index 1fa2c59..c4b7381 100644
--- a/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/uniphier-pcie.txt
@@ -16,6 +16,7 @@ Required properties:
"dbi" - controller configuration registers
"link" - SoC-specific glue layer registers
"config" - PCIe configuration space
+ "atu" - iATU registers for DWC version 4.80 or later
- clocks: A phandle to the clock gate for PCIe glue layer including
the host controller.
- resets: A phandle to the reset line for PCIe glue layer including
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/5] PCI: uniphier: Add iATU register support
From: Kunihiko Hayashi @ 2020-05-15 9:59 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589536743-6684-1-git-send-email-hayashi.kunihiko@socionext.com>
This gets iATU register area from reg property. In Synopsis DWC version
4.80 or later, since iATU register area is separated from core register
area, this area is necessary to get from DT independently.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index a8dda39..493f105 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -447,6 +447,13 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
if (IS_ERR(priv->pci.dbi_base))
return PTR_ERR(priv->pci.dbi_base);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
+ if (res) {
+ priv->pci.atu_base = devm_pci_remap_cfg_resource(dev, res);
+ if (IS_ERR(priv->pci.atu_base))
+ priv->pci.atu_base = NULL;
+ }
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
priv->base = devm_ioremap_resource(dev, res);
if (IS_ERR(priv->base))
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/5] PCI: uniphier: Add error message when failed to get phy
From: Kunihiko Hayashi @ 2020-05-15 9:59 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Jingoo Han, Gustavo Pimentel,
Rob Herring, Masahiro Yamada
Cc: devicetree, Kunihiko Hayashi, Masami Hiramatsu, linux-pci,
linux-kernel, Jassi Brar, linux-arm-kernel
In-Reply-To: <1589536743-6684-1-git-send-email-hayashi.kunihiko@socionext.com>
Even if phy driver doesn't probe, the error message can't be distinguished
from other errors. This displays error message caused by the phy driver
explicitly.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index 493f105..7ae9688 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -468,8 +468,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
return PTR_ERR(priv->rst);
priv->phy = devm_phy_optional_get(dev, "pcie-phy");
- if (IS_ERR(priv->phy))
- return PTR_ERR(priv->phy);
+ if (IS_ERR(priv->phy)) {
+ ret = PTR_ERR(priv->phy);
+ dev_err(dev, "Failed to get phy (%d)\n", ret);
+ return ret;
+ }
platform_set_drvdata(pdev, priv);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [GIT PULL 1/5] Renesas ARM defconfig updates for v5.8 (take two)
From: Geert Uytterhoeven @ 2020-05-15 10:05 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20200515100547.14671-1-geert+renesas@glider.be>
The following changes since commit 4c427ab28fd1cd988fce9517527476cfebd27485:
ARM: shmobile: defconfig: Refresh for v5.7-rc1 (2020-04-20 10:02:46 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm-defconfig-for-v5.8-tag2
for you to fetch changes up to 44b6141ebe936808fc59b386e3e259bef6c9bba6:
ARM: multi_v7_defconfig: Enable r8a7742 SoC (2020-05-04 14:29:56 +0200)
----------------------------------------------------------------
Renesas ARM defconfig updates for v5.8 (take two)
- Enable support for the new RZ/G1H SoC in the shmobile and multi_v7
defconfigs.
----------------------------------------------------------------
Lad Prabhakar (2):
ARM: shmobile: defconfig: Enable r8a7742 SoC
ARM: multi_v7_defconfig: Enable r8a7742 SoC
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/shmobile_defconfig | 1 +
2 files changed, 2 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 0/5] Renesas SoC updates for v5.8 (take two)
From: Geert Uytterhoeven @ 2020-05-15 10:05 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
Hi arm-soc folks,
This is my second pull request for the inclusion of Renesas SoC updates
for v5.8.
It consists of 5 parts:
[GIT PULL 1/5] Renesas ARM defconfig updates for v5.8 (take two)
- Enable support for the new RZ/G1H SoC in the shmobile and multi_v7
defconfigs.
[GIT PULL 2/5] Renesas ARM DT updates for v5.8 (take two)
- Initial support for the Renesas RZ/G1H SoC on the iWave RainboW
Qseven SOM (G21M) and board (G21D),
- Support for the AISTARVISION MIPI Adapter V2.1 camera board on the
Silicon Linux EK874 RZ/G2E evaluation kit.
[GIT PULL 3/5] Renesas ARM SoC updates for v5.8 (take two)
- Add debug-ll support for RZ/G1H.
[GIT PULL 4/5] Renesas driver updates for v5.8 (take two)
- Add the main config option for the RZ/G1H SoC.
[GIT PULL 5/5] Renesas DT binding updates for v5.8 (take two)
- Document support for the RZ/G1H-based iWave RainboW Qseven SOM
(G21M) and board (G21D).
Note that the new Renesas RZ/G1H DT Binding Definitions are shared by
driver and DT source files, and thus included in multiple pull requests:
- "[GIT PULL 2/5] Renesas ARM DT updates for v5.8 (take two)",
- "[GIT PULL 4/5] Renesas driver updates for v5.8" (previous PR),
- "[GIT PULL] clk: renesas: Updates for v5.8" (for clk).
Thanks for pulling!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 5/5] Renesas DT binding updates for v5.8 (take two)
From: Geert Uytterhoeven @ 2020-05-15 10:05 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20200515100547.14671-1-geert+renesas@glider.be>
The following changes since commit 9e01d74ce0a154411c8991d6e34f4c470958eac3:
dt-bindings: reset: rcar-rst: Document r8a7742 reset module (2020-04-28 10:09:56 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dt-bindings-for-v5.8-tag2
for you to fetch changes up to 0b5832238d369a71f90a221d17b92761595c8067:
dt-bindings: arm: renesas: Document iW-RainboW-G21D-Qseven-RZG1H board (2020-05-15 10:49:27 +0200)
----------------------------------------------------------------
Renesas DT binding updates for v5.8 (take two)
- Document support for the RZ/G1H-based iWave RainboW Qseven SOM
(G21M) and board (G21D).
----------------------------------------------------------------
Lad Prabhakar (2):
dt-bindings: arm: renesas: Document iW-RainboW-G21M-Qseven-RZG1H SoM
dt-bindings: arm: renesas: Document iW-RainboW-G21D-Qseven-RZG1H board
Documentation/devicetree/bindings/arm/renesas.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 4/5] Renesas driver updates for v5.8 (take two)
From: Geert Uytterhoeven @ 2020-05-15 10:05 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20200515100547.14671-1-geert+renesas@glider.be>
The following changes since commit 2f71832755a9422f5a62a13ea3e805df7b173837:
soc: renesas: rcar-rst: Add support for RZ/G1H (2020-04-30 10:01:39 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-drivers-for-v5.8-tag2
for you to fetch changes up to cdc8abe763c99a6c2b854d7096eaf1ea21017a42:
soc: renesas: Add Renesas R8A7742 config option (2020-05-04 14:27:20 +0200)
----------------------------------------------------------------
Renesas driver updates for v5.8 (take two)
- Add the main config option for the RZ/G1H SoC.
----------------------------------------------------------------
Lad Prabhakar (1):
soc: renesas: Add Renesas R8A7742 config option
drivers/soc/renesas/Kconfig | 7 +++++++
1 file changed, 7 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/5] Renesas ARM DT updates for v5.8 (take two)
From: Geert Uytterhoeven @ 2020-05-15 10:05 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20200515100547.14671-1-geert+renesas@glider.be>
The following changes since commit cf8ae446bbcbf5c48214eb7ddaa6ac6e12f4633d:
arm64: dts: renesas: Fix IOMMU device node names (2020-04-27 12:02:56 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm-dt-for-v5.8-tag2
for you to fetch changes up to 0e36587c0832af5df894f5e5fcc45fb5a05cea5b:
arm64: dts: renesas: r8a774c0-cat874: Add support for AISTARVISION MIPI Adapter V2.1 (2020-05-12 10:05:36 +0200)
----------------------------------------------------------------
Renesas ARM DT updates for v5.8 (take two)
- Initial support for the Renesas RZ/G1H SoC on the iWave RainboW
Qseven SOM (G21M) and board (G21D),
- Support for the AISTARVISION MIPI Adapter V2.1 camera board on the
Silicon Linux EK874 RZ/G2E evaluation kit.
----------------------------------------------------------------
Geert Uytterhoeven (1):
Merge tag 'renesas-r8a7742-dt-binding-defs-tag' into renesas-arm-dt-for-v5.8
Lad Prabhakar (9):
dt-bindings: power: rcar-sysc: Add r8a7742 power domain index macros
clk: renesas: Add r8a7742 CPG Core Clock Definitions
ARM: dts: r8a7742: Initial SoC device tree
ARM: dts: r8a7742-iwg21m: Add iWave RZ/G1H Qseven SOM
ARM: dts: r8a7742-iwg21d-q7: Add iWave G21D-Q7 board based on RZ/G1H
ARM: dts: r8a7742: Add IRQC support
ARM: dts: r8a7742: Add [H]SCIF{A|B} support
ARM: dts: r8a7742: Add GPIO nodes
arm64: dts: renesas: r8a774c0-cat874: Add support for AISTARVISION MIPI Adapter V2.1
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 37 ++
arch/arm/boot/dts/r8a7742-iwg21m.dtsi | 53 ++
arch/arm/boot/dts/r8a7742.dtsi | 648 +++++++++++++++++++++
arch/arm64/boot/dts/renesas/Makefile | 3 +-
.../dts/renesas/aistarvision-mipi-adapter-2.1.dtsi | 94 +++
.../boot/dts/renesas/r8a774c0-ek874-mipi-2.1.dts | 72 +++
include/dt-bindings/clock/r8a7742-cpg-mssr.h | 42 ++
include/dt-bindings/power/r8a7742-sysc.h | 29 +
9 files changed, 978 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
create mode 100644 arch/arm/boot/dts/r8a7742-iwg21m.dtsi
create mode 100644 arch/arm/boot/dts/r8a7742.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/aistarvision-mipi-adapter-2.1.dtsi
create mode 100644 arch/arm64/boot/dts/renesas/r8a774c0-ek874-mipi-2.1.dts
create mode 100644 include/dt-bindings/clock/r8a7742-cpg-mssr.h
create mode 100644 include/dt-bindings/power/r8a7742-sysc.h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 3/5] Renesas ARM SoC updates for v5.8 (take two)
From: Geert Uytterhoeven @ 2020-05-15 10:05 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20200515100547.14671-1-geert+renesas@glider.be>
The following changes since commit 135e7a156ae2c1a7a1f0c1d44bf2b3daece04bbf:
ARM: shmobile: r8a7742: Basic SoC support (2020-04-28 10:13:58 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm-soc-for-v5.8-tag2
for you to fetch changes up to 96866b1a1d32318b6bbc321a762bf79db1f4686e:
ARM: debug-ll: Add support for r8a7742 (2020-05-04 14:28:21 +0200)
----------------------------------------------------------------
Renesas ARM SoC updates for v5.8 (take two)
- Add debug-ll support for RZ/G1H.
----------------------------------------------------------------
Lad Prabhakar (1):
ARM: debug-ll: Add support for r8a7742
arch/arm/Kconfig.debug | 10 ++++++++++
1 file changed, 10 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 30/38] dmabuf: fix common struct sg_table related issues
From: Gerd Hoffmann @ 2020-05-15 10:13 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Bartlomiej Zolnierkiewicz, David Airlie, linux-kernel, dri-devel,
Sumit Semwal, linaro-mm-sig, iommu, Daniel Vetter, Robin Murphy,
Christoph Hellwig, linux-arm-kernel, linux-media
In-Reply-To: <20200513133245.6408-30-m.szyprowski@samsung.com>
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index acb26c6..89e293b 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -63,10 +63,9 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf,
> GFP_KERNEL);
> if (ret < 0)
> goto err;
> - if (!dma_map_sg(dev, sg->sgl, sg->nents, direction)) {
> - ret = -EINVAL;
> + ret = dma_map_sgtable(dev, sg, direction, 0);
> + if (ret < 0)
> goto err;
> - }
> return sg;
>
> err:
> @@ -78,7 +77,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf,
> static void put_sg_table(struct device *dev, struct sg_table *sg,
> enum dma_data_direction direction)
> {
> - dma_unmap_sg(dev, sg->sgl, sg->nents, direction);
> + dma_unmap_sgtable(dev, sg, direction, 0);
> sg_free_table(sg);
> kfree(sg);
> }
Easy straightforward conversation.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
take care,
Gerd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: ti: k3-am654-main: Update otap-del-sel values
From: Tero Kristo @ 2020-05-15 10:14 UTC (permalink / raw)
To: Faiz Abbas, linux-kernel, devicetree, linux-arm-kernel; +Cc: nm, robh+dt
In-Reply-To: <20200507181526.12529-1-faiz_abbas@ti.com>
On 07/05/2020 21:15, Faiz Abbas wrote:
> According to the latest AM65x Data Manual[1], a different output tap
> delay value is optimum for a given speed mode. Update these values.
>
> [1] http://www.ti.com/lit/gpn/am6526
>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
> v2: Rebased to the latest mainline kernel
>
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> index 11887c72f23a..6cd9701e4ead 100644
> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
> @@ -244,7 +244,17 @@
> interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
> mmc-ddr-1_8v;
> mmc-hs200-1_8v;
> - ti,otap-del-sel = <0x2>;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-mmc-hs = <0x0>;
> + ti,otap-del-sel-sd-hs = <0x0>;
> + ti,otap-del-sel-sdr12 = <0x0>;
> + ti,otap-del-sel-sdr25 = <0x0>;
> + ti,otap-del-sel-sdr50 = <0x8>;
> + ti,otap-del-sel-sdr104 = <0x5>;
Isn't this wrong? Doc claims the value for sdr104 should be 0x7?
-Tero
> + ti,otap-del-sel-ddr50 = <0x5>;
> + ti,otap-del-sel-ddr52 = <0x5>;
> + ti,otap-del-sel-hs200 = <0x5>;
> + ti,otap-del-sel-hs400 = <0x0>;
> ti,trm-icp = <0x8>;
> dma-coherent;
> };
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/2] irqchip/gic-v3-its: Balance LPI affinity across CPUs
From: Marc Zyngier @ 2020-05-15 10:14 UTC (permalink / raw)
To: John Garry
Cc: Jason Cooper, chenxiang, Will Deacon, luojiaxing, linux-kernel,
Ming Lei, Zhou Wang, Thomas Gleixner, Robin Murphy,
linux-arm-kernel
In-Reply-To: <7c05b08b-2edc-7f97-0175-898e9772673e@huawei.com>
Hi John,
On 2020-05-14 13:05, John Garry wrote:
>>
>> + its_inc_lpi_count(d, cpu);
>> +
>> return IRQ_SET_MASK_OK_DONE;
>> }
>>
>> Results look ok:
>> nvme.use_threaded_interrupts=1 =0*
>> Before 950K IOPs 1000K IOPs
>> After 1100K IOPs 1150K IOPs
>>
>> * as mentioned before, this is quite unstable and causes lockups.
>> JFYI, there was an attempt to fix this:
>>
>> https://lore.kernel.org/linux-nvme/20191209175622.1964-1-kbusch@kernel.org/
>>
>
> Hi Marc,
>
> Just wondering if we can try to get this series over the line?
Absolutely. Life has got in the way, so let me page it back in...
> So I tested the patches on v5.7-rc5, and get similar performance
> improvement to above.
>
> I did apply a couple of patches, below, to remedy the issues I
> experienced for my D06CS.
Comments on that below.
>
> Thanks,
> John
>
>
> ---->8
>
>
> [PATCH 1/2] irqchip/gic-v3-its: Don't double account for target CPU
> assignment
>
> In its_set_affinity(), when a managed irq is already assigned to a CPU,
> we may needlessly reassign the irq to another CPU.
>
> This is because when selecting the target CPU, being the least loaded
> CPU in the mask, we account of that irq still being assigned to a CPU;
> thereby we may unfairly select another CPU.
>
> Modify this behaviour to pre-decrement the current target CPU LPI count
> when finding the least loaded CPU.
>
> Alternatively we may be able to just bail out early when the current
> target CPU already falls within the requested mask.
>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index 73f5c12..2b18feb 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1636,6 +1636,8 @@ static int its_set_affinity(struct irq_data *d,
> const struct cpumask *mask_val,
> if (irqd_is_forwarded_to_vcpu(d))
> return -EINVAL;
>
> + its_dec_lpi_count(d, its_dev->event_map.col_map[id]);
> +
> if (!force)
> cpu = its_select_cpu(d, mask_val);
> else
> @@ -1646,14 +1648,14 @@ static int its_set_affinity(struct irq_data
> *d, const struct cpumask *mask_val,
>
> /* don't set the affinity when the target cpu is same as current one
> */
> if (cpu != its_dev->event_map.col_map[id]) {
> - its_inc_lpi_count(d, cpu);
> - its_dec_lpi_count(d, its_dev->event_map.col_map[id]);
> target_col = &its_dev->its->collections[cpu];
> its_send_movi(its_dev, target_col, id);
> its_dev->event_map.col_map[id] = cpu;
> irq_data_update_effective_affinity(d, cpumask_of(cpu));
> }
>
> + its_inc_lpi_count(d, cpu);
> +
I'm OK with that change, as it removes unnecessary churn.
> return IRQ_SET_MASK_OK_DONE;
> }
>
> ---
>
>
> [PATCH 2/2] irqchip/gic-v3-its: Handle no overlap of non-managed irq
> affinity mask
>
> In selecting the target CPU for a non-managed interrupt, we may select
> a
> target CPU outside the requested affinity mask.
>
> This is because there may be no overlap of the ITS node mask and the
> requested CPU affinity mask. The requested affinity mask may be coming
> from userspace or some drivers which try to set irq affinity, see [0].
>
> In this case, just ignore the ITS node cpumask. This is a deviation
> from
> what Thomas described. Having said that, I am not sure if the
> interrupt is ever bound to a node for us.
>
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/perf/hisilicon/hisi_uncore_pmu.c#n417
>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index 2b18feb..12d5d4b4 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1584,10 +1584,6 @@ static int its_select_cpu(struct irq_data *d,
> cpumask_and(tmpmask, cpumask_of_node(node), aff_mask);
> cpumask_and(tmpmask, tmpmask, cpu_online_mask);
>
> - /* If that doesn't work, try the nodemask itself */
> - if (cpumask_empty(tmpmask))
> - cpumask_and(tmpmask, cpumask_of_node(node), cpu_online_mask);
> -
> cpu = cpumask_pick_least_loaded(d, tmpmask);
> if (cpu < nr_cpu_ids)
> goto out;
I'm really not sure. Shouldn't we then drop the wider search on
cpu_inline_mask, because userspace could have given us something
that we cannot deal with?
What you are advocating for is a strict adherence to the provided
mask, and it doesn't seem to be what other architectures are providing.
I consider the userspace-provided affinity as a hint more that anything
else, as in this case the kernel does know better (routing the interrupt
to a foreign node might be costly, or even impossible, see the TX1
erratum).
From what I remember of the earlier discussion, you saw an issue on
a system with two sockets and a single ITS, with the node mask limited
to the first socket. Is that correct?
I'll respin the series today and report it with you first patch
squased in.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 25/38] drm: virtio: fix common struct sg_table related issues
From: Gerd Hoffmann @ 2020-05-15 10:12 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Bartlomiej Zolnierkiewicz, David Airlie, linux-kernel, dri-devel,
virtualization, linaro-mm-sig, iommu, Daniel Vetter, Robin Murphy,
Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20200513133245.6408-25-m.szyprowski@samsung.com>
On Wed, May 13, 2020 at 03:32:32PM +0200, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called with the original number of the entries
> passed to the dma_map_sg().
>
> struct sg_table is a common structure used for describing a non-contiguous
> memory buffer, used commonly in the DRM and graphics subsystems. It
> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
> and DMA mapped pages (nents entry).
>
> It turned out that it was a common mistake to misuse nents and orig_nents
> entries, calling DMA-mapping functions with a wrong number of entries or
> ignoring the number of mapped entries returned by the dma_map_sg()
> function.
>
> To avoid such issues, lets use a common dma-mapping wrappers operating
> directly on the struct sg_table objects and use scatterlist page
> iterators where possible. This, almost always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.
Looks all sane.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
take care,
Gerd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] cpuidle: psci: Fixup execution order when entering a domain idle state
From: Sudeep Holla @ 2020-05-15 10:22 UTC (permalink / raw)
To: Ulf Hansson
Cc: Lorenzo Pieralisi, Benjamin Gaignard, Linux PM, Stephen Boyd,
Daniel Lezcano, Rafael J . Wysocki, Lina Iyer, Bjorn Andersson,
Sudeep Holla, Linux ARM
In-Reply-To: <CAPDyKFrdrOnxFHaAR=cmMi2VfSudyHdjZ7vRZKhTQtepdkiXug@mail.gmail.com>
On Thu, May 14, 2020 at 09:11:50PM +0200, Ulf Hansson wrote:
>
> No worries, thanks for reviewing.
>
You are welcome.
> That said, are you fine with Rafel queuing this then?
>
I am fine with that. However I told if you need fixes tags as there are
no users of the notification yet in the kernel. Though this is trivial,
but do we need this backported to stable kernel. I don't have strong
opinion and leave it to you and Rafael.
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 03/16] mfd: mfd-core: match device tree node against reg property
From: Lee Jones @ 2020-05-15 10:28 UTC (permalink / raw)
To: Michael Walle
Cc: linux-pwm, Linus Walleij, Thierry Reding, linux-watchdog,
Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, devicetree, Jean Delvare,
Jason Cooper, linux-gpio, Rob Herring, Thomas Gleixner,
Wim Van Sebroeck, linux-arm-kernel, linux-hwmon,
Greg Kroah-Hartman, linux-kernel, Li Yang, Mark Brown, Shawn Guo
In-Reply-To: <67e90dafd67c285158c2c6f67f92edb7@walle.cc>
On Thu, 30 Apr 2020, Michael Walle wrote:
> Hi Lee,
>
> Am 2020-04-23 19:45, schrieb Michael Walle:
> > There might be multiple children with the device tree compatible, for
> > example if a MFD has multiple instances of the same function. In this
> > case only the first is matched and the other children get a wrong
> > of_node reference.
> > Add a new option to match also against the unit address of the child
> > node. Additonally, a new helper OF_MFD_CELL_REG is added.
>
>
> Do you think this is feasible? I guess this is the biggest uncertainty
> for me at the moment in this patch series.
I think it sounds fine in principle. So long as it doesn't change the
existing behaviour when of_reg isn't set.
> > Signed-off-by: Michael Walle <michael@walle.cc>
> > ---
> > drivers/mfd/mfd-core.c | 29 ++++++++++++++++++++---------
> > include/linux/mfd/core.h | 26 ++++++++++++++++++++------
> > 2 files changed, 40 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> > index e735565969b3..4ecb376338f7 100644
> > --- a/drivers/mfd/mfd-core.c
> > +++ b/drivers/mfd/mfd-core.c
> > @@ -117,6 +117,7 @@ static int mfd_add_device(struct device *parent, int
> > id,
> > struct device_node *np = NULL;
> > int ret = -ENOMEM;
> > int platform_id;
> > + u32 of_reg;
> > int r;
> >
> > if (id == PLATFORM_DEVID_AUTO)
> > @@ -151,16 +152,26 @@ static int mfd_add_device(struct device *parent,
> > int id,
> >
> > if (parent->of_node && cell->of_compatible) {
> > for_each_child_of_node(parent->of_node, np) {
> > - if (of_device_is_compatible(np, cell->of_compatible)) {
> > - if (!of_device_is_available(np)) {
> > - /* Ignore disabled devices error free */
> > - ret = 0;
> > - goto fail_alias;
> > - }
> > - pdev->dev.of_node = np;
> > - pdev->dev.fwnode = &np->fwnode;
> > - break;
> > + if (!of_device_is_compatible(np, cell->of_compatible))
> > + continue;
> > +
> > + /* also match the unit address if set */
Please use correct grammar in comments (leaving off the full-stop).
> > + if (cell->of_reg & MFD_OF_REG_VALID) {
> > + if (of_property_read_u32(np, "reg", &of_reg))
> > + continue;
> > + if ((cell->of_reg & MFD_OF_REG_MASK) != of_reg)
> > + continue;
> > }
> > +
> > + if (!of_device_is_available(np)) {
> > + /* Ignore disabled devices error free */
> > + ret = 0;
> > + goto fail_alias;
> > + }
> > +
> > + pdev->dev.of_node = np;
> > + pdev->dev.fwnode = &np->fwnode;
> > + break;
> > }
> > }
> >
> > diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> > index d01d1299e49d..c2c0ad6b14f3 100644
> > --- a/include/linux/mfd/core.h
> > +++ b/include/linux/mfd/core.h
> > @@ -13,8 +13,11 @@
> > #include <linux/platform_device.h>
> >
> > #define MFD_RES_SIZE(arr) (sizeof(arr) / sizeof(struct resource))
> > +#define MFD_OF_REG_VALID BIT(31)
What about 64bit platforms?
> > +#define MFD_OF_REG_MASK GENMASK(30, 0)
> >
> > -#define MFD_CELL_ALL(_name, _res, _pdata, _pdsize, _id, _compat,
> > _match)\
> > +#define MFD_CELL_ALL(_name, _res, _pdata, _pdsize, _id, _compat, \
> > + _of_reg, _match) \
> > { \
> > .name = (_name), \
> > .resources = (_res), \
> > @@ -22,24 +25,32 @@
> > .platform_data = (_pdata), \
> > .pdata_size = (_pdsize), \
> > .of_compatible = (_compat), \
> > + .of_reg = (_of_reg), \
> > .acpi_match = (_match), \
> > .id = (_id), \
> > }
> >
> > +#define OF_MFD_CELL_REG(_name, _res, _pdata, _pdsize, _id, _compat, \
> > + _of_reg) \
> > + MFD_CELL_ALL(_name, _res, _pdata, _pdsize, _id, _compat, \
> > + ((_of_reg) | MFD_OF_REG_VALID), NULL) \
> > +
> > #define OF_MFD_CELL(_name, _res, _pdata, _pdsize,_id, _compat) \
> > - MFD_CELL_ALL(_name, _res, _pdata, _pdsize, _id, _compat, NULL) \
> > + MFD_CELL_ALL(_name, _res, _pdata, _pdsize, _id, _compat, \
> > + 0, NULL) \
> >
> > #define ACPI_MFD_CELL(_name, _res, _pdata, _pdsize, _id, _match) \
> > - MFD_CELL_ALL(_name, _res, _pdata, _pdsize, _id, NULL, _match) \
> > + MFD_CELL_ALL(_name, _res, _pdata, _pdsize, _id, NULL, 0, \
> > + _match) \
> >
> > #define MFD_CELL_BASIC(_name, _res, _pdata, _pdsize, _id) \
> > - MFD_CELL_ALL(_name, _res, _pdata, _pdsize, _id, NULL, NULL) \
> > + MFD_CELL_ALL(_name, _res, _pdata, _pdsize, _id, NULL, 0, NULL) \
> >
> > #define MFD_CELL_RES(_name, _res) \
> > - MFD_CELL_ALL(_name, _res, NULL, 0, 0, NULL, NULL) \
> > + MFD_CELL_ALL(_name, _res, NULL, 0, 0, NULL, 0, NULL) \
> >
> > #define MFD_CELL_NAME(_name) \
> > - MFD_CELL_ALL(_name, NULL, NULL, 0, 0, NULL, NULL) \
> > + MFD_CELL_ALL(_name, NULL, NULL, 0, 0, NULL, 0, NULL) \
> >
> > struct irq_domain;
> > struct property_entry;
> > @@ -78,6 +89,9 @@ struct mfd_cell {
> > */
> > const char *of_compatible;
> >
> > + /* matching the reg property if set */
Proper grammar please.
"OF unit address for device matching"
> > + unsigned int of_reg;
> > +
> > /* Matches ACPI */
> > const struct mfd_cell_acpi_match *acpi_match;
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 4/5] clk: stm32: Fix stm32f429 ltdc driver loading hang in clk set rate. keep ltdc clk running after kernel startup
From: dillon min @ 2020-05-15 10:31 UTC (permalink / raw)
To: Stephen Boyd
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Torgue, Dave Airlie, Michael Turquette, linux-kernel,
open list:DRM PANEL DRIVERS, linux-clk, Rob Herring,
thierry.reding, Maxime Coquelin, Daniel Vetter, Sam Ravnborg,
linux-stm32, Linux ARM
In-Reply-To: <158949014721.215346.12197373767247910756@swboyd.mtv.corp.google.com>
Hi Stephen,
thanks for reviewing.
On Fri, May 15, 2020 at 5:02 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting dillon.minfei@gmail.com (2020-05-12 00:03:36)
> > From: dillon min <dillon.minfei@gmail.com>
> >
> > as store stm32f4_rcc_register_pll return to the wrong offset of clks,
>
> Use () on functions, i.e. stm32f4_rcc_register_pll().
ok
>
> > so ltdc gate clk is null. need change clks[PLL_VCO_SAI] to clks[PLL_SAI]
>
> And quote variables like 'clks[PLL_VCO_SAI]'
ok
>
> >
> > add CLK_IGNORE_UNUSED for ltdc to make sure clk not be freed by
> > clk_disable_unused
>
> clk_disable_unused() doesn't free anything. Why does ltdc not need to be
> turned off if it isn't used? Is it critical to system operation? Should
> it be marked with the critical clk flag then? The CLK_IGNORE_UNUSED flag
> is almost always wrong to use.
Yes, you are right. thanks. CLK_IGNORE_UNUSED just hide the root
cause. after deeper debugging.
i need to drop the last changes , they are not the root cause.
post diff and analyse here first, i will resubmit clk's changes in
next patchset with gyro and ili9341.
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -129,8 +129,6 @@ static const struct stm32f4_gate_data
stm32f429_gates[] __initconst = {
{ STM32F4_RCC_APB2ENR, 20, "spi5", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div",
- CLK_IGNORE_UNUSED },
};
static const struct stm32f4_gate_data stm32f469_gates[] __initconst = {
@@ -558,13 +556,13 @@ static const struct clk_div_table post_divr_table[] = {
#define MAX_POST_DIV 3
static const struct stm32f4_pll_post_div_data post_div_data[MAX_POST_DIV] = {
- { CLK_I2SQ_PDIV, PLL_I2S, "plli2s-q-div", "plli2s-q",
+ { CLK_I2SQ_PDIV, PLL_VCO_I2S, "plli2s-q-div", "plli2s-q",
CLK_SET_RATE_PARENT, STM32F4_RCC_DCKCFGR, 0, 5, 0, NULL},
- { CLK_SAIQ_PDIV, PLL_SAI, "pllsai-q-div", "pllsai-q",
+ { CLK_SAIQ_PDIV, PLL_VCO_SAI, "pllsai-q-div", "pllsai-q",
CLK_SET_RATE_PARENT, STM32F4_RCC_DCKCFGR, 8, 5, 0, NULL },
- { NO_IDX, PLL_SAI, "pllsai-r-div", "pllsai-r", CLK_SET_RATE_PARENT,
+ { NO_IDX, PLL_VCO_SAI, "pllsai-r-div", "pllsai-r", CLK_SET_RATE_PARENT,
STM32F4_RCC_DCKCFGR, 16, 2, 0, post_divr_table },
};
@@ -1758,7 +1756,7 @@ static void __init stm32f4_rcc_init(struct
device_node *np)
clks[PLL_VCO_I2S] = stm32f4_rcc_register_pll("vco_in",
&data->pll_data[1], &stm32f4_clk_lock);
- clks[PLL_SAI] = stm32f4_rcc_register_pll("vco_in",
+ clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll("vco_in",
&data->pll_data[2], &stm32f4_clk_lock);
for (n = 0; n < MAX_POST_DIV; n++) {
issue 1: ili9341 hang in clk set rate, the root cause should be
PLL_VCO_SAI, PLL_SAI mismatch
for 'clks[]'
1, first at stm32f4_rcc_init() ,
clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll("vco_in",
&data->pll_data[2], &stm32f4_clk_lock);
the clk_hw from stm32f4_rcc_register_pll() is store to 'clks[7]', defined in
'include/dt-bindings/clock/stm32fx-clock.h'
2, next
hw = clk_register_pll_div(post_div->name,
post_div->parent,
post_div->flag,
base + post_div->offset,
post_div->shift,
post_div->width,
post_div->flag_div,
post_div->div_table,
clks[post_div->pll_num],
&stm32f4_clk_lock);
the 'clks[post_div->pll_num]', the pll_num is PLL_SAI, the value is 2,
defined at
enum {
PLL,
PLL_I2S,
PLL_SAI,
};
'post_div_data[]'
so 7 != 2 offset of 'clks[]', input the wrong 'clks[]' to
clk_register_pll_div. cause to_clk_gate result is null,
crashed in ltdc driver's loading.
issue 2: clk_disable_unused() turn off ltdc clock.
1, ltdc clk is defined in 'stm32f429_gates[]', register to clk core,
but there is no user to use it.
ltdc driver use dts binding name "lcd", connect to CLK_LCD, then
aux clk 'lcd-tft '
2, as no one use 'stm32f429_gates[]' s ltdc clock , so the
enable_count is zero, after kernel startup
it's been turn off by clk_disable_unused() is fine.
my chages for this is remove the ltdc from 'stm32f429_gates[]'
but this modification still need 'clk-stm32f4.c''s maintainer to check
if there is side effect.
>
> >
> > Signed-off-by: dillon min <dillon.minfei@gmail.com>
> > ---
> > drivers/clk/clk-stm32f4.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> > index 18117ce..0ba73de 100644
> > --- a/drivers/clk/clk-stm32f4.c
> > +++ b/drivers/clk/clk-stm32f4.c
> > @@ -129,7 +129,8 @@ static const struct stm32f4_gate_data stm32f429_gates[] __initconst = {
> > { STM32F4_RCC_APB2ENR, 20, "spi5", "apb2_div" },
> > { STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
> > { STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
> > - { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
> > + { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div",
> > + CLK_IGNORE_UNUSED },
> > };
> >
> > static const struct stm32f4_gate_data stm32f469_gates[] __initconst = {
> > @@ -1757,7 +1758,7 @@ static void __init stm32f4_rcc_init(struct device_node *np)
> > clks[PLL_VCO_I2S] = stm32f4_rcc_register_pll("vco_in",
> > &data->pll_data[1], &stm32f4_clk_lock);
> >
> > - clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll("vco_in",
> > + clks[PLL_SAI] = stm32f4_rcc_register_pll("vco_in",
> > &data->pll_data[2], &stm32f4_clk_lock);
> >
> > for (n = 0; n < MAX_POST_DIV; n++) {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Linux-stm32] [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
From: dillon min @ 2020-05-15 10:32 UTC (permalink / raw)
To: Benjamin GAIGNARD
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre TORGUE, Michael Turquette, Dave Airlie, Linus Walleij,
linux-kernel@vger.kernel.org, open list:DRM PANEL DRIVERS,
linux-stm32@st-md-mailman.stormreply.com, Stephen Boyd,
Rob Herring, thierry.reding@gmail.com, Linux ARM, Daniel Vetter,
Sam Ravnborg, linux-clk, Maxime Coquelin
In-Reply-To: <2afd2853-e3bc-0c69-a0e5-8d4aa631a634@st.com>
Hi Benjamin,
got it, thanks a lot.
best regards
Dillon
On Fri, May 15, 2020 at 5:34 PM Benjamin GAIGNARD
<benjamin.gaignard@st.com> wrote:
>
>
>
> On 5/15/20 11:24 AM, dillon min wrote:
> > Hi Benjamin,
> >
> > thanks for reply.
> >
> > On Fri, May 15, 2020 at 4:31 PM Benjamin GAIGNARD
> > <benjamin.gaignard@st.com> wrote:
> >>
> >>
> >> On 5/14/20 3:07 PM, dillon min wrote:
> >>> Hi Alexandre,
> >>>
> >>> On Thu, May 14, 2020 at 8:53 PM Alexandre Torgue
> >>> <alexandre.torgue@st.com> wrote:
> >>>>
> >>>> On 5/14/20 10:24 AM, Linus Walleij wrote:
> >>>>> On Tue, May 12, 2020 at 9:04 AM <dillon.minfei@gmail.com> wrote:
> >>>>>
> >>>>>> From: dillon min <dillon.minfei@gmail.com>
> >>>>>>
> >>>>>> Enable the ltdc & ili9341 on stm32429-disco board.
> >>>>>>
> >>>>>> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> >>>>> This mostly looks good but...
> >>>>>
> >>>>>> +&spi5 {
> >>>>>> + status = "okay";
> >>>>>> + pinctrl-0 = <&spi5_pins>;
> >>>>>> + pinctrl-names = "default";
> >>>>>> + #address-cells = <1>;
> >>>>>> + #size-cells = <0>;
> >>>>>> + cs-gpios = <&gpioc 2 GPIO_ACTIVE_LOW>;
> >>>>>> + dmas = <&dma2 3 2 0x400 0x0>,
> >>>>>> + <&dma2 4 2 0x400 0x0>;
> >>>>>> + dma-names = "rx", "tx";
> >>>>> These DMA assignments seem to be SoC things and should
> >>>>> rather be in the DTS(I) file where &spi5 is defined, right?
> >>>>> stm32f429.dtsi I suppose?
> >>>> I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
> >>>> doesn't want to use it, we use the "delete-property".
> >>> Yes, will move to Soc dtsi in next submits.
> >>>
> >>> i'm working on write a v4l2-m2m driver for dma2d of stm32 to support
> >>> pixel conversion
> >>> alpha blending between foreground and background graphics.
> >>>
> >>> as you know, some soc's engineer trying to add this function to drm system.
> >>>
> >>> do you know st's planning about soc's hardware accelerator driver on stm32mp?
> >>> such as chrom-art, will add to drm subsystem via ioctl to access, or to v4l2,
> >> On stm32mp we do not plan to use chrom-art in drm or v4l2 because it
> >> does fit
> >> with userland way of working. We use the GPU to do conversion, scaling,
> >> blending
> >> and composition in only one go.
> >> As explain here [1] DRM subsytem it isn't a solution and v4l2-m2m isn't
> >> used in any
> >> mainline compositors like Weston or android surfaceflinger.
> >>
> >> Benjamin
> >>
> > After check stm32mp's datasheets, they don't have chrom-art ip inside. sorry for
> > didn't check it yet.
> >
> > for stm32h7 series with chrom-art, jpeg hardware accelerator inside.
> > does st has plan to
> > setup a driver to support it ? i prefer v4l2-m2m should be easier to
> > implement it.
> > co work with dcmi, fbdev.
> ST doesn't plan to create a driver for chrom-art because nothing in
> mainline
> userland could use it.
>
> Benjamin
> >
> > thanks.
> >
> > best regards.
> >
> > Dillon
> >> [1]
> >> https://www.phoronix.com/scan.php?page=news_item&px=Linux-DRM-No-2D-Accel-API
> >>> thanks.
> >>>
> >>>>> It is likely the same no matter which device is using spi5.
> >>>>>
> >>>>> Yours,
> >>>>> Linus Walleij
> >>>>>
> >>> _______________________________________________
> >>> Linux-stm32 mailing list
> >>> Linux-stm32@st-md-mailman.stormreply.com
> >>> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 23/23] arm64: mte: Add Memory Tagging Extension documentation
From: Catalin Marinas @ 2020-05-15 10:38 UTC (permalink / raw)
To: Dave Martin
Cc: linux-arch, Richard Earnshaw, Will Deacon, Szabolcs Nagy,
Andrey Konovalov, Kevin Brodsky, linux-mm, Vincenzo Frascino,
Peter Collingbourne, linux-arm-kernel
In-Reply-To: <20200514113722.GA1907@gaia>
On Thu, May 14, 2020 at 12:37:22PM +0100, Catalin Marinas wrote:
> On Wed, May 13, 2020 at 04:48:46PM +0100, Dave P Martin wrote:
> > > > > On Wed, Apr 29, 2020 at 05:47:05PM +0100, Dave P Martin wrote:
> > > > > > On Tue, Apr 21, 2020 at 03:26:03PM +0100, Catalin Marinas wrote:
> > > > > > > +excludes all tags other than 0. A user thread can enable specific tags
> > > > > > > +in the randomly generated set using the ``prctl(PR_SET_TAGGED_ADDR_CTRL,
> > > > > > > +flags, 0, 0, 0)`` system call where ``flags`` contains the tags bitmap
> > > > > > > +in the ``PR_MTE_TAG_MASK`` bit-field.
> > > > > > > +
> > > > > > > +**Note**: The hardware uses an exclude mask but the ``prctl()``
> > > > > > > +interface provides an include mask. An include mask of ``0`` (exclusion
> > > > > > > +mask ``0xffff``) results in the CPU always generating tag ``0``.
> > > > > >
> > > > > > Is there no way to make this default to 1 rather than having a magic
> > > > > > meaning for 0?
> [...]
> > The only configuration that doesn't make sense is "no tags allowed", so
> > I'd argue for explicity blocking that, even if the architeture aliases
> > that encoding to something else.
> >
> > If we prefer 0 as a default value so that init inherits the correct
> > value from the kernel without any special acrobatics, then we make it an
> > exclude mask, with the semantics that the hardware is allowed to
> > generate any of these tags, but does not have to be capable of
> > generating all of them.
>
> That's more of a question to the libc people and their preference.
> We have two options with suboptions:
>
> 1. prctl() gets an exclude mask with 0xffff illegal even though the
> hardware accepts it:
> a) default exclude mask 0, allowing all tags to be generated by IRG
> b) default exclude mask of 0xfffe so that only tag 0 is generated
>
> 2. prctl() gets an include mask with 0 illegal:
> a) default include mask is 0xffff, allowing all tags to be generated
> b) default include mask 0f 0x0001 so that only tag 0 is generated
>
> We currently have (2) with mask 0 but could be changed to (2.b). If we
> are to follow the hardware description (which makes more sense to me but
> I don't write the C library), (1.a) is the most appropriate.
Thinking some more about this, as we are to expose the GCR_EL1.Excl via
a ptrace interface as a regset, it makes more sense to move back to an
exclude mask here with default 0. That would be option 1.a above.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement
From: Jean-Philippe Brucker @ 2020-05-15 10:43 UTC (permalink / raw)
To: linux-pci, linux-arm-kernel, iommu, joro, bhelgaas
Cc: Jean-Philippe Brucker, ashok.raj, will, alex.williamson,
robin.murphy, dwmw2, baolu.lu
I sent these in March as part of ATS enablement for device-tree [1], but
haven't found the time to address the largest comment on that series
about consolidating the root bridge ATS support between the different
ACPI tables.
I'm resending only the bits that consolidate the 'untrusted' check for
ATS, since there have been more discussions about this [2]. Patch 1
moves the 'untrusted' check to drivers/pci/ats.c and patches 2-4 modify
the ATS-capable IOMMU drivers.
The only functional change should be to the AMD IOMMU driver. With this
change all IOMMU drivers block 'Translated' PCIe transactions and
Translation Requests from untrusted devices.
[1] https://lore.kernel.org/linux-iommu/20200311124506.208376-1-jean-philippe@linaro.org/
[2] https://lore.kernel.org/linux-pci/20200513151929.GA38418@bjorn-Precision-5520/
Jean-Philippe Brucker (4):
PCI/ATS: Only enable ATS for trusted devices
iommu/amd: Use pci_ats_supported()
iommu/arm-smmu-v3: Use pci_ats_supported()
iommu/vt-d: Use pci_ats_supported()
include/linux/pci-ats.h | 3 +++
drivers/iommu/amd_iommu.c | 12 ++++--------
drivers/iommu/arm-smmu-v3.c | 20 +++++---------------
drivers/iommu/intel-iommu.c | 9 +++------
drivers/pci/ats.c | 18 +++++++++++++++++-
5 files changed, 32 insertions(+), 30 deletions(-)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] PCI/ATS: Only enable ATS for trusted devices
From: Jean-Philippe Brucker @ 2020-05-15 10:43 UTC (permalink / raw)
To: linux-pci, linux-arm-kernel, iommu, joro, bhelgaas
Cc: Jean-Philippe Brucker, ashok.raj, will, alex.williamson,
robin.murphy, dwmw2, baolu.lu
In-Reply-To: <20200515104359.1178606-1-jean-philippe@linaro.org>
Add pci_ats_supported(), which checks whether a device has an ATS
capability, and whether it is trusted. A device is untrusted if it is
plugged into an external-facing port such as Thunderbolt and could be
spoof an existing device to exploit weaknesses in the IOMMU
configuration. PCIe ATS is one such weaknesses since it allows
endpoints to cache IOMMU translations and emit transactions with
'Translated' Address Type (10b) that partially bypass the IOMMU
translation.
The SMMUv3 and VT-d IOMMU drivers already disallow ATS and transactions
with 'Translated' Address Type for untrusted devices. Add the check to
pci_enable_ats() to let other drivers (AMD IOMMU for now) benefit from
it.
By checking ats_cap, the pci_ats_supported() helper also returns whether
ATS was globally disabled with pci=noats, and could later include more
things, for example whether the whole PCIe hierarchy down to the
endpoint supports ATS.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
include/linux/pci-ats.h | 3 +++
drivers/pci/ats.c | 18 +++++++++++++++++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
index d08f0869f1213e..f75c307f346de9 100644
--- a/include/linux/pci-ats.h
+++ b/include/linux/pci-ats.h
@@ -6,11 +6,14 @@
#ifdef CONFIG_PCI_ATS
/* Address Translation Service */
+bool pci_ats_supported(struct pci_dev *dev);
int pci_enable_ats(struct pci_dev *dev, int ps);
void pci_disable_ats(struct pci_dev *dev);
int pci_ats_queue_depth(struct pci_dev *dev);
int pci_ats_page_aligned(struct pci_dev *dev);
#else /* CONFIG_PCI_ATS */
+static inline bool pci_ats_supported(struct pci_dev *d)
+{ return false; }
static inline int pci_enable_ats(struct pci_dev *d, int ps)
{ return -ENODEV; }
static inline void pci_disable_ats(struct pci_dev *d) { }
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index 390e92f2d8d1fc..15fa0c37fd8e44 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -30,6 +30,22 @@ void pci_ats_init(struct pci_dev *dev)
dev->ats_cap = pos;
}
+/**
+ * pci_ats_supported - check if the device can use ATS
+ * @dev: the PCI device
+ *
+ * Returns true if the device supports ATS and is allowed to use it, false
+ * otherwise.
+ */
+bool pci_ats_supported(struct pci_dev *dev)
+{
+ if (!dev->ats_cap)
+ return false;
+
+ return !dev->untrusted;
+}
+EXPORT_SYMBOL_GPL(pci_ats_supported);
+
/**
* pci_enable_ats - enable the ATS capability
* @dev: the PCI device
@@ -42,7 +58,7 @@ int pci_enable_ats(struct pci_dev *dev, int ps)
u16 ctrl;
struct pci_dev *pdev;
- if (!dev->ats_cap)
+ if (!pci_ats_supported(dev))
return -EINVAL;
if (WARN_ON(dev->ats_enabled))
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] iommu/amd: Use pci_ats_supported()
From: Jean-Philippe Brucker @ 2020-05-15 10:44 UTC (permalink / raw)
To: linux-pci, linux-arm-kernel, iommu, joro, bhelgaas
Cc: Jean-Philippe Brucker, ashok.raj, will, alex.williamson,
robin.murphy, dwmw2, baolu.lu
In-Reply-To: <20200515104359.1178606-1-jean-philippe@linaro.org>
The pci_ats_supported() function checks if a device supports ATS and is
allowed to use it. In addition to checking that the device has an ATS
capability and that the global pci=noats is not set
(pci_ats_disabled()), it also checks if a device is untrusted.
A device is untrusted if it is plugged into an external-facing port such
as Thunderbolt and could be spoofing an existing device to exploit
weaknesses in the IOMMU configuration. By calling pci_ats_supported() we
keep DTE[I]=0 for untrusted devices and abort transactions with
Pretranslated Addresses.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/iommu/amd_iommu.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 1dc3718560d0e8..8b7a9e811d33a6 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -313,16 +313,15 @@ static struct iommu_group *acpihid_device_group(struct device *dev)
static bool pci_iommuv2_capable(struct pci_dev *pdev)
{
static const int caps[] = {
- PCI_EXT_CAP_ID_ATS,
PCI_EXT_CAP_ID_PRI,
PCI_EXT_CAP_ID_PASID,
};
int i, pos;
- if (pci_ats_disabled())
+ if (!pci_ats_supported(pdev))
return false;
- for (i = 0; i < 3; ++i) {
+ for (i = 0; i < 2; ++i) {
pos = pci_find_ext_capability(pdev, caps[i]);
if (pos == 0)
return false;
@@ -3150,11 +3149,8 @@ int amd_iommu_device_info(struct pci_dev *pdev,
memset(info, 0, sizeof(*info));
- if (!pci_ats_disabled()) {
- pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS);
- if (pos)
- info->flags |= AMD_IOMMU_DEVICE_FLAG_ATS_SUP;
- }
+ if (pci_ats_supported(pdev))
+ info->flags |= AMD_IOMMU_DEVICE_FLAG_ATS_SUP;
pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PRI);
if (pos)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox