* [PATCH 8/8] PCI: rpadlpar: fix a leaked reference by adding missing of_node_put
From: Wen Yang @ 2019-02-27 4:40 UTC (permalink / raw)
To: benh
Cc: heiko, hayashi.kunihiko, linux-pci, shawn.lin, minghuan.Lian,
paulus, thomas.petazzoni, Wen Yang, ryder.lee, kishon,
linux-rockchip, bcm-kernel-feedback-list, linux-arm-kernel,
wang.yi59, rjui, lorenzo.pieralisi, linux-mediatek, tyreld,
matthias.bgg, linux-omap, mingkai.hu, roy.zang, sbranden,
yamada.masahiro, linuxppc-dev, linux-kernel, bhelgaas
In-Reply-To: <1551242443-27300-1-git-send-email-wen.yang99@zte.com.cn>
The call to of_find_node_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/pci/hotplug/rpadlpar_core.c:55:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 42, but without a corresponding object release within this function
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pci/hotplug/rpadlpar_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
index e2356a9..f3f42ff 100644
--- a/drivers/pci/hotplug/rpadlpar_core.c
+++ b/drivers/pci/hotplug/rpadlpar_core.c
@@ -52,6 +52,7 @@ static struct device_node *find_vio_slot_node(char *drc_name)
break;
}
+ of_node_put(parent);
return dn;
}
--
2.9.5
^ permalink raw reply related
* [PATCH 2/8] PCI: uniphier: fix a leaked reference by adding missing of_node_put
From: Wen Yang @ 2019-02-27 4:40 UTC (permalink / raw)
To: benh
Cc: heiko, hayashi.kunihiko, linux-pci, shawn.lin, minghuan.Lian,
paulus, thomas.petazzoni, Wen Yang, ryder.lee, kishon,
linux-rockchip, bcm-kernel-feedback-list, linux-arm-kernel,
wang.yi59, rjui, lorenzo.pieralisi, linux-mediatek, tyreld,
matthias.bgg, linux-omap, mingkai.hu, roy.zang, sbranden,
yamada.masahiro, linuxppc-dev, linux-kernel, bhelgaas
In-Reply-To: <1551242443-27300-1-git-send-email-wen.yang99@zte.com.cn>
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
irq_domain_add_linear also calls of_node_get to increase refcount,
so irq_domain will not be affected when it is released.
Detected by coccinelle with the following warnings:
./drivers/pci/controller/dwc/pcie-uniphier.c:283:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 274, but without a corresponding object release within this function.
./drivers/pci/controller/dwc/pcie-uniphier.c:290:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 274, but without a corresponding object release within this function.
./drivers/pci/controller/dwc/pcie-uniphier.c:296:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 274, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: linux-pci@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pci/controller/dwc/pcie-uniphier.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
index d5dc402..3f30ee4 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -270,6 +270,7 @@ static int uniphier_pcie_config_legacy_irq(struct pcie_port *pp)
struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
struct device_node *np = pci->dev->of_node;
struct device_node *np_intc;
+ int ret = 0;
np_intc = of_get_child_by_name(np, "legacy-interrupt-controller");
if (!np_intc) {
@@ -280,20 +281,24 @@ static int uniphier_pcie_config_legacy_irq(struct pcie_port *pp)
pp->irq = irq_of_parse_and_map(np_intc, 0);
if (!pp->irq) {
dev_err(pci->dev, "Failed to get an IRQ entry in legacy-interrupt-controller\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out_put_node;
}
priv->legacy_irq_domain = irq_domain_add_linear(np_intc, PCI_NUM_INTX,
&uniphier_intx_domain_ops, pp);
if (!priv->legacy_irq_domain) {
dev_err(pci->dev, "Failed to get INTx domain\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto out_put_node;
}
irq_set_chained_handler_and_data(pp->irq, uniphier_pcie_irq_handler,
pp);
- return 0;
+out_put_node:
+ of_node_put(np_intc);
+ return ret;
}
static int uniphier_pcie_host_init(struct pcie_port *pp)
--
2.9.5
^ permalink raw reply related
* [PATCH 4/8] PCI: rockchip: fix a leaked reference by adding missing of_node_put
From: Wen Yang @ 2019-02-27 4:40 UTC (permalink / raw)
To: benh
Cc: heiko, hayashi.kunihiko, linux-pci, shawn.lin, minghuan.Lian,
paulus, thomas.petazzoni, Wen Yang, ryder.lee, kishon,
linux-rockchip, bcm-kernel-feedback-list, linux-arm-kernel,
wang.yi59, rjui, lorenzo.pieralisi, linux-mediatek, tyreld,
matthias.bgg, linux-omap, mingkai.hu, roy.zang, sbranden,
yamada.masahiro, linuxppc-dev, linux-kernel, bhelgaas
In-Reply-To: <1551242443-27300-1-git-send-email-wen.yang99@zte.com.cn>
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
irq_domain_add_linear also calls of_node_get to increase refcount,
so irq_domain will not be affected when it is released.
Detected by coccinelle with the following warnings:
./drivers/pci/controller/pcie-rockchip-host.c:729:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 718, but without a corresponding object release within this function.
./drivers/pci/controller/pcie-rockchip-host.c:732:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 718, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: linux-pci@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pci/controller/pcie-rockchip-host.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index 1372d27..8d20f17 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -724,6 +724,7 @@ static int rockchip_pcie_init_irq_domain(struct rockchip_pcie *rockchip)
rockchip->irq_domain = irq_domain_add_linear(intc, PCI_NUM_INTX,
&intx_domain_ops, rockchip);
+ of_node_put(intc);
if (!rockchip->irq_domain) {
dev_err(dev, "failed to get a INTx IRQ domain\n");
return -EINVAL;
--
2.9.5
^ permalink raw reply related
* [PATCH 5/8] PCI: aardvark: fix a leaked reference by adding missing of_node_put
From: Wen Yang @ 2019-02-27 4:40 UTC (permalink / raw)
To: benh
Cc: heiko, hayashi.kunihiko, linux-pci, shawn.lin, minghuan.Lian,
paulus, thomas.petazzoni, Wen Yang, ryder.lee, kishon,
linux-rockchip, bcm-kernel-feedback-list, linux-arm-kernel,
wang.yi59, rjui, lorenzo.pieralisi, linux-mediatek, tyreld,
matthias.bgg, linux-omap, mingkai.hu, roy.zang, sbranden,
yamada.masahiro, linuxppc-dev, linux-kernel, bhelgaas
In-Reply-To: <1551242443-27300-1-git-send-email-wen.yang99@zte.com.cn>
The call to of_get_next_child returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
irq_domain_add_linear also calls of_node_get to increase refcount,
so irq_domain will not be affected when it is released.
Detected by coccinelle with the following warnings:
./drivers/pci/controller/pci-aardvark.c:826:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 798, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pci/controller/pci-aardvark.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index 750081c..56ecb16 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -794,6 +794,7 @@ static int advk_pcie_init_irq_domain(struct advk_pcie *pcie)
struct device_node *node = dev->of_node;
struct device_node *pcie_intc_node;
struct irq_chip *irq_chip;
+ int ret = 0;
pcie_intc_node = of_get_next_child(node, NULL);
if (!pcie_intc_node) {
@@ -806,8 +807,8 @@ static int advk_pcie_init_irq_domain(struct advk_pcie *pcie)
irq_chip->name = devm_kasprintf(dev, GFP_KERNEL, "%s-irq",
dev_name(dev));
if (!irq_chip->name) {
- of_node_put(pcie_intc_node);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out_put_node;
}
irq_chip->irq_mask = advk_pcie_irq_mask;
@@ -819,11 +820,13 @@ static int advk_pcie_init_irq_domain(struct advk_pcie *pcie)
&advk_pcie_irq_domain_ops, pcie);
if (!pcie->irq_domain) {
dev_err(dev, "Failed to get a INTx IRQ domain\n");
- of_node_put(pcie_intc_node);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out_put_node;
}
- return 0;
+out_put_node:
+ of_node_put(pcie_intc_node);
+ return ret;
}
static void advk_pcie_remove_irq_domain(struct advk_pcie *pcie)
--
2.9.5
^ permalink raw reply related
* [PATCH 3/8] PCI: dwc: layerscape: fix a leaked reference by adding missing of_node_put
From: Wen Yang @ 2019-02-27 4:40 UTC (permalink / raw)
To: benh
Cc: heiko, hayashi.kunihiko, linux-pci, shawn.lin, minghuan.Lian,
paulus, thomas.petazzoni, Wen Yang, ryder.lee, kishon,
linux-rockchip, bcm-kernel-feedback-list, linux-arm-kernel,
wang.yi59, rjui, lorenzo.pieralisi, linux-mediatek, tyreld,
matthias.bgg, linux-omap, mingkai.hu, roy.zang, sbranden,
yamada.masahiro, linuxppc-dev, linux-kernel, bhelgaas
In-Reply-To: <1551242443-27300-1-git-send-email-wen.yang99@zte.com.cn>
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/pci/controller/dwc/pci-layerscape.c:204:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 198, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Minghuan Lian <minghuan.Lian@nxp.com>
Cc: Mingkai Hu <mingkai.hu@nxp.com>
Cc: Roy Zang <roy.zang@nxp.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-pci@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pci/controller/dwc/pci-layerscape.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
index ce45bde2..3a5fa26 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -201,6 +201,7 @@ static int ls_pcie_msi_host_init(struct pcie_port *pp)
return -EINVAL;
}
+ of_node_put(msi_node);
return 0;
}
--
2.9.5
^ permalink raw reply related
* [PATCH 1/8] PCI: dwc: pci-dra7xx: fix a leaked reference by adding missing of_node_put
From: Wen Yang @ 2019-02-27 4:40 UTC (permalink / raw)
To: benh
Cc: heiko, hayashi.kunihiko, linux-pci, shawn.lin, minghuan.Lian,
paulus, thomas.petazzoni, Wen Yang, ryder.lee, kishon,
linux-rockchip, bcm-kernel-feedback-list, linux-arm-kernel,
wang.yi59, rjui, lorenzo.pieralisi, linux-mediatek, tyreld,
matthias.bgg, linux-omap, mingkai.hu, roy.zang, sbranden,
yamada.masahiro, linuxppc-dev, linux-kernel, bhelgaas
The call to of_get_next_child returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
irq_domain_add_linear also calls of_node_get to increase refcount,
so irq_domain will not be affected when it is released.
Detected by coccinelle with the following warnings:
./drivers/pci/controller/dwc/pci-dra7xx.c:252:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 241, but without a corresponding object release within this function.
./drivers/pci/controller/dwc/pci-dra7xx.c:255:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 241, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-omap@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/pci/controller/dwc/pci-dra7xx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c b/drivers/pci/controller/dwc/pci-dra7xx.c
index ae84a69..627c91d 100644
--- a/drivers/pci/controller/dwc/pci-dra7xx.c
+++ b/drivers/pci/controller/dwc/pci-dra7xx.c
@@ -247,6 +247,7 @@ static int dra7xx_pcie_init_irq_domain(struct pcie_port *pp)
dra7xx->irq_domain = irq_domain_add_linear(pcie_intc_node, PCI_NUM_INTX,
&intx_domain_ops, pp);
+ of_node_put(pcie_intc_node);
if (!dra7xx->irq_domain) {
dev_err(dev, "Failed to get a INTx IRQ domain\n");
return -ENODEV;
--
2.9.5
^ permalink raw reply related
* Re: [PATCH 00/18] Add FADump support on PowerNV platform
From: Nicholas Piggin @ 2019-02-27 4:18 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli, Hari Bathini, Vasant Hegde,
linuxppc-dev, Mahesh J Salgaonkar, Michael Ellerman,
Stewart Smith
In-Reply-To: <155077048463.21014.13936958730316555495.stgit@hbathini.in.ibm.com>
Hari Bathini's on February 22, 2019 3:35 am:
> Firmware-Assisted Dump (FADump) is currently supported only on pseries
> platform. This patch series adds support for powernv platform too.
>
> The first and third patches refactor the FADump code to make use of common
> code across multiple platforms. The fifth patch adds basic FADump support
> for powernv platform. Patches seven & eight honour reserved-ranges DT node
> while reserving/releasing memory used by FADump. The next patch processes
> CPU state data provided by firmware to create and append core notes to the
> ELF core file. The tenth patch adds support for preserving crash data for
> subsequent boots (useful in cases like petitboot). Patch twelve provides
> support to export opalcore. This is to make debugging of failures in OPAL
> code easier. The subsequent patch ensures vmcore processing is skipped
> when only OPAL core is exported by f/w. The next patch provides option to
> release the kernel memory used to export opalcore. Patch seventeen adds
> backup area (an area populated before crash and used in the capture kernel
> to setup vmcore file robustly) support on PowerNV platform. The remaining
> patches update Firmware-Assisted Dump documentation appropriately.
>
> Note that the quantam of increase in robustness due to patch seventeen may
> not be worth breaking backward compatibility for older kernel versions.
> Would like to hear thoughts from others on it.
>
> The patch series is tested with the latest firmware plus the below skiboot
> changes for MPIPL support:
>
> https://patchwork.ozlabs.org/project/skiboot/list/?series=78497
> ("MPIPL support")
>
> ---
>
> Hari Bathini (18):
> powerpc/fadump: move internal fadump code to a new file
> powerpc/fadump: Improve fadump documentation
> pseries/fadump: move out platform specific support from generic code
> powerpc/fadump: use FADump instead of fadump for how it is pronounced
> powerpc/fadump: enable fadump support on OPAL based POWER platform
> powerpc/fadump: Update documentation about OPAL platform support
> powerpc/fadump: consider reserved ranges while reserving memory
> powerpc/fadump: consider reserved ranges while releasing memory
> powernv/fadump: process architected register state data provided by firmware
> powernv/fadump: add support to preserve crash data on FADUMP disabled kernel
> powerpc/fadump: update documentation about CONFIG_PRESERVE_FA_DUMP
> powerpc/powernv: export /proc/opalcore for analysing opal crashes
> powernv/fadump: Skip processing /proc/vmcore when only OPAL core exists
> powernv/opalcore: provide an option to invalidate /proc/opalcore file
> powernv/fadump: consider f/w load area
> powernv/fadump: update documentation about option to release opalcore
> powernv/fadump: use backup area to map PIR to logical CPUs
The need to map firmware identifiers like PIR to Linux numbering comes
up in a few places, OPAL msglog, pdbg debugger, etc. I wonder if we
could have Linux register its logical CPU numbers with OPAL after it
boots. Would that help with your usage?
> powerpc/fadump: Update documentation about backup area support
>
>
> Documentation/powerpc/firmware-assisted-dump.txt | 208 ++--
> arch/powerpc/Kconfig | 23
> arch/powerpc/include/asm/fadump.h | 190 ---
> arch/powerpc/include/asm/opal-api.h | 58 +
> arch/powerpc/include/asm/opal.h | 1
> arch/powerpc/kernel/Makefile | 6
> arch/powerpc/kernel/fadump.c | 1199 ++++++++--------------
> arch/powerpc/kernel/fadump_internal.c | 297 +++++
> arch/powerpc/kernel/fadump_internal.h | 250 +++++
I don't have much knowledge of fadump code, so I'll nitpick instead :P
Why are you calling it fadump_internal, what's internal about it? You
have the framework for the ops table etc here, which makes the platform
code have to #include "../kernel/fadump_internal.h", and suggests it's
not so internal. Seems like it would be fine just to go in
include/asm/fadump.h and kernel fadump.c?
> arch/powerpc/kernel/prom.c | 4
> arch/powerpc/platforms/powernv/Makefile | 3
> arch/powerpc/platforms/powernv/opal-core.c | 602 +++++++++++
> arch/powerpc/platforms/powernv/opal-fadump.c | 670 ++++++++++++
> arch/powerpc/platforms/powernv/opal-fadump.h | 116 ++
> arch/powerpc/platforms/powernv/opal-wrappers.S | 1
> arch/powerpc/platforms/pseries/Makefile | 1
> arch/powerpc/platforms/pseries/pseries_fadump.c | 535 ++++++++++
> arch/powerpc/platforms/pseries/pseries_fadump.h | 96 ++
These hopefully could just be called pseries/fadump.[ch]? Or maybe
rtas-fadump if you want to be like powernv.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Make opal log only readable by root
From: Andrew Donnellan @ 2019-02-27 4:17 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev
In-Reply-To: <20190227030229.12814-1-jniethe5@gmail.com>
On 27/2/19 2:02 pm, Jordan Niethe wrote:
> Currently the opal log is globally readable. It is kernel policy to limit
> the visibility of physical addresses / kernel pointers to root.
> Given this and the fact the opal log may contain this information it would
> be better to limit the readability to root.
>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Guess I'll have to get used to typing sudo more often. :(
Makes sense also given that we do the same thing for exports afaict.
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Make opal log only readable by root
From: Stewart Smith @ 2019-02-27 3:59 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev; +Cc: Jordan Niethe
In-Reply-To: <20190227030229.12814-1-jniethe5@gmail.com>
Jordan Niethe <jniethe5@gmail.com> writes:
> Currently the opal log is globally readable. It is kernel policy to limit
> the visibility of physical addresses / kernel pointers to root.
> Given this and the fact the opal log may contain this information it would
> be better to limit the readability to root.
>
> Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
Yeah, this is a really good idea.
Reviewed-by: Stewart Smith <stewart@linux.ibm.com>
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply
* Re: [PATCH 00/18] Add FADump support on PowerNV platform
From: Daniel Axtens @ 2019-02-27 3:37 UTC (permalink / raw)
To: Hari Bathini, Ananth N Mavinakayanahalli, Michael Ellerman,
Mahesh J Salgaonkar, Vasant Hegde, linuxppc-dev, Stewart Smith
In-Reply-To: <155077048463.21014.13936958730316555495.stgit@hbathini.in.ibm.com>
Hi Hari,
> Firmware-Assisted Dump (FADump) is currently supported only on pseries
> platform. This patch series adds support for powernv platform too.
>
> The first and third patches refactor the FADump code to make use of common
> code across multiple platforms. The fifth patch adds basic FADump support
> for powernv platform. Patches seven & eight honour reserved-ranges DT node
> while reserving/releasing memory used by FADump. The next patch processes
> CPU state data provided by firmware to create and append core notes to the
> ELF core file. The tenth patch adds support for preserving crash data for
> subsequent boots (useful in cases like petitboot). Patch twelve provides
> support to export opalcore. This is to make debugging of failures in OPAL
> code easier. The subsequent patch ensures vmcore processing is skipped
> when only OPAL core is exported by f/w. The next patch provides option to
> release the kernel memory used to export opalcore. Patch seventeen adds
> backup area (an area populated before crash and used in the capture kernel
> to setup vmcore file robustly) support on PowerNV platform. The remaining
> patches update Firmware-Assisted Dump documentation appropriately.
>
> Note that the quantam of increase in robustness due to patch seventeen may
> not be worth breaking backward compatibility for older kernel versions.
> Would like to hear thoughts from others on it.
>
> The patch series is tested with the latest firmware plus the below skiboot
> changes for MPIPL support:
>
> https://patchwork.ozlabs.org/project/skiboot/list/?series=78497
> ("MPIPL support")
>
If I want to test this, is there some userspace tooling that will
extract a fadump from a rebooted system and allow me to examine it as I
would with a kdump (e.g. with crash)? I did look at
Documentation/powerpc/firmware-assisted-dump.txt but it seems to only
cover the kernel layer.
Regards,
Daniel
> ---
>
> Hari Bathini (18):
> powerpc/fadump: move internal fadump code to a new file
> powerpc/fadump: Improve fadump documentation
> pseries/fadump: move out platform specific support from generic code
> powerpc/fadump: use FADump instead of fadump for how it is pronounced
> powerpc/fadump: enable fadump support on OPAL based POWER platform
> powerpc/fadump: Update documentation about OPAL platform support
> powerpc/fadump: consider reserved ranges while reserving memory
> powerpc/fadump: consider reserved ranges while releasing memory
> powernv/fadump: process architected register state data provided by firmware
> powernv/fadump: add support to preserve crash data on FADUMP disabled kernel
> powerpc/fadump: update documentation about CONFIG_PRESERVE_FA_DUMP
> powerpc/powernv: export /proc/opalcore for analysing opal crashes
> powernv/fadump: Skip processing /proc/vmcore when only OPAL core exists
> powernv/opalcore: provide an option to invalidate /proc/opalcore file
> powernv/fadump: consider f/w load area
> powernv/fadump: update documentation about option to release opalcore
> powernv/fadump: use backup area to map PIR to logical CPUs
> powerpc/fadump: Update documentation about backup area support
>
>
> Documentation/powerpc/firmware-assisted-dump.txt | 208 ++--
> arch/powerpc/Kconfig | 23
> arch/powerpc/include/asm/fadump.h | 190 ---
> arch/powerpc/include/asm/opal-api.h | 58 +
> arch/powerpc/include/asm/opal.h | 1
> arch/powerpc/kernel/Makefile | 6
> arch/powerpc/kernel/fadump.c | 1199 ++++++++--------------
> arch/powerpc/kernel/fadump_internal.c | 297 +++++
> arch/powerpc/kernel/fadump_internal.h | 250 +++++
> arch/powerpc/kernel/prom.c | 4
> arch/powerpc/platforms/powernv/Makefile | 3
> arch/powerpc/platforms/powernv/opal-core.c | 602 +++++++++++
> arch/powerpc/platforms/powernv/opal-fadump.c | 670 ++++++++++++
> arch/powerpc/platforms/powernv/opal-fadump.h | 116 ++
> arch/powerpc/platforms/powernv/opal-wrappers.S | 1
> arch/powerpc/platforms/pseries/Makefile | 1
> arch/powerpc/platforms/pseries/pseries_fadump.c | 535 ++++++++++
> arch/powerpc/platforms/pseries/pseries_fadump.h | 96 ++
> 18 files changed, 3252 insertions(+), 1008 deletions(-)
> create mode 100644 arch/powerpc/kernel/fadump_internal.c
> create mode 100644 arch/powerpc/kernel/fadump_internal.h
> create mode 100644 arch/powerpc/platforms/powernv/opal-core.c
> create mode 100644 arch/powerpc/platforms/powernv/opal-fadump.c
> create mode 100644 arch/powerpc/platforms/powernv/opal-fadump.h
> create mode 100644 arch/powerpc/platforms/pseries/pseries_fadump.c
> create mode 100644 arch/powerpc/platforms/pseries/pseries_fadump.h
>
> --
> Signature
^ permalink raw reply
* Re: [PATCH] powerpc/fsl: Fix the flush of branch predictor.
From: Daniel Axtens @ 2019-02-27 3:37 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Diana Craciun
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <dccb392cd3e2b1825608576ecf2487cc5d84466d.1551205086.git.christophe.leroy@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> The commit identified below adds MC_BTB_FLUSH macro only when
> CONFIG_PPC_FSL_BOOK3E is defined. This results in the following error
> on some configs (seen several times with kisskb randconfig_defconfig)
>
> arch/powerpc/kernel/exceptions-64e.S:576: Error: Unrecognized opcode: `mc_btb_flush'
> make[3]: *** [scripts/Makefile.build:367: arch/powerpc/kernel/exceptions-64e.o] Error 1
> make[2]: *** [scripts/Makefile.build:492: arch/powerpc/kernel] Error 2
> make[1]: *** [Makefile:1043: arch/powerpc] Error 2
> make: *** [Makefile:152: sub-make] Error 2
>
> This patch adds a blank definition of MC_BTB_FLUSH for other cases.
>
> Fixes: 10c5e83afd4a ("powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)")
> Cc: Diana Craciun <diana.craciun@nxp.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/kernel/exceptions-64e.S | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
> index 4549ce8d4637..49381f32b374 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -338,6 +338,7 @@ ret_from_mc_except:
> #define GEN_BTB_FLUSH
> #define CRIT_BTB_FLUSH
> #define DBG_BTB_FLUSH
> +#define MC_BTB_FLUSH
> #define GDBELL_BTB_FLUSH
This seems correct to me:
- MC_BTB_FLUSH gets a definition in the CONFIG_PPC_FSL_BOOK3E case.
- other things that are defined in the FSL_BOOK3E case get empty
definitions in the #else branch, but MC_BTB_FLUSH doesn't.
- this patch just adds that empty definition.
- there are no other definitions of MC_BTB_FLUSH that should be used
instead.
Reviewed-by: Daniel Axtens <dja@axtens.net>
Regards,
Daniel
> #endif
>
> --
> 2.13.3
^ permalink raw reply
* [PATCH] powerpc/powernv: Make opal log only readable by root
From: Jordan Niethe @ 2019-02-27 3:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jordan Niethe
Currently the opal log is globally readable. It is kernel policy to limit
the visibility of physical addresses / kernel pointers to root.
Given this and the fact the opal log may contain this information it would
be better to limit the readability to root.
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
arch/powerpc/platforms/powernv/opal-msglog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal-msglog.c b/arch/powerpc/platforms/powernv/opal-msglog.c
index acd3206dfae3..06628c71cef6 100644
--- a/arch/powerpc/platforms/powernv/opal-msglog.c
+++ b/arch/powerpc/platforms/powernv/opal-msglog.c
@@ -98,7 +98,7 @@ static ssize_t opal_msglog_read(struct file *file, struct kobject *kobj,
}
static struct bin_attribute opal_msglog_attr = {
- .attr = {.name = "msglog", .mode = 0444},
+ .attr = {.name = "msglog", .mode = 0400},
.read = opal_msglog_read
};
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv: move OPAL call wrapper tracing and interrupt handling to C
From: Stewart Smith @ 2019-02-27 2:22 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20190226093035.7176-1-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> The OPAL call wrapper gets interrupt disabling wrong. It disables
> interrupts just by clearing MSR[EE], which has two problems:
>
> - It doesn't call into the IRQ tracing subsystem, which means tracing
> across OPAL calls does not always notice IRQs have been disabled.
>
> - It doesn't go through the IRQ soft-mask code, which causes a minor
> bug. MSR[EE] can not be restored by saving the MSR then clearing
> MSR[EE], because a racing interrupt while soft-masked could clear
> MSR[EE] between the two steps. This can cause MSR[EE] to be
> incorrectly enabled when the OPAL call returns. Fortunately that
> should only result in another masked interrupt being taken to
> disable MSR[EE] again, but it's a bit sloppy.
>
> The existing code also saves MSR to PACA, which is not re-entrant if
> there is a nested OPAL call from different MSR contexts, which can
> happen these days with SRESET interrupts on bare metal.
>
> To fix these issues, move the tracing and IRQ handling code to C, and
> call into asm just for the low level call when everything is ready to
> go. Save the MSR on stack rather than PACA.
>
> Performance cost is kept to a minimum with a few optimisations:
>
> - The endian switch upon return is combined with the MSR restore,
> which avoids an expensive context synchronizing operation for LE
> kernels. This makes up for the additional mtmsrd to enable
> interrupts with local_irq_enable().
>
> - blr is now used to return from the opal_* functions that are called
> as C functions, to avoid link stack corruption. This requires a
> skiboot fix as well to keep the call stack balanced.
>
> A NULL call is more costly after this, (410ns->430ns on POWER9), but
> OPAL calls are generally not performance critical at this scale.
At least with this patch we can start to better measure things, and
that's a big plus. Also, When I get to start worrying about <1ms OPAL
calls, I think we can revisit optimising this path :)
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply
* Re: [PATCH V7 0/4] mm/kvm/vfio/ppc64: Migrate compound pages out of CMA region
From: Andrew Morton @ 2019-02-26 23:53 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Andrea Arcangeli, Alexey Kardashevskiy, linux-kernel,
Michal Hocko, linux-mm, linuxppc-dev, David Gibson
In-Reply-To: <20190114095438.32470-1-aneesh.kumar@linux.ibm.com>
[patch 1/4]: OK. I guess. Was this worth consuming our last PF_ flag?
[patch 2/4]: unreviewed
[patch 3/4]: unreviewed, mpe still unhappy, I expect?
[patch 4/4]: unreviewed
^ permalink raw reply
* Re: [PATCH V5 0/5] NestMMU pte upgrade workaround for mprotect
From: Andrew Morton @ 2019-02-26 23:37 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: x86, npiggin, linux-mm, paulus, linuxppc-dev
In-Reply-To: <20190116085035.29729-1-aneesh.kumar@linux.ibm.com>
[patch 1/5]: unreviewed and has unaddressed comments from mpe.
[patch 2/5]: ditto
[patch 3/5]: ditto
[patch 4/5]: seems ready
[patch 5/5]: reviewed by mpe, but appears to need more work
^ permalink raw reply
* Re: [PATCH v2 11/16] KVM: introduce a 'mmap' method for KVM devices
From: David Gibson @ 2019-02-26 23:22 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, kvm-ppc, Paul Mackerras, Cédric Le Goater, linuxppc-dev
In-Reply-To: <e1a35077-8c0f-313c-15d0-0483956bfcd6@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]
On Tue, Feb 26, 2019 at 01:52:39PM +0100, Paolo Bonzini wrote:
> On 25/02/19 11:57, Cédric Le Goater wrote:
> > Hello Paolo,
> >
> > On 2/25/19 4:33 AM, David Gibson wrote:
> >> On Fri, Feb 22, 2019 at 12:28:35PM +0100, Cédric Le Goater wrote:
> >>> Some KVM devices will want to handle special mappings related to the
> >>> underlying HW. For instance, the XIVE interrupt controller of the
> >>> POWER9 processor has MMIO pages for thread interrupt management and
> >>> for interrupt source control that need to be exposed to the guest when
> >>> the OS has the required support.
> >>>
> >>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> >>
> >> Ah, when I suggested mmap() on the base device fd, I hadn't realized
> >> there wasn't a facility for that yet.
> >>
> >> Have you discussed this with Paolo?
> >
> > Not yet.
> >
> >> We'll need some core KVM buy in to merge this.
> >
> > Here is an extension of the KVM device to allow special mappings.
> > Something we would need for the support of the POWER9 XIVE interrupt
> > controller.
> >
> > There are two MMIOs we need to expose to the guest :
> >
> > 1. HW MMIO controlling of the interrupt presenter registers (TIMA)
> > 2. HW MMIO of the interrupt sources for interrupt management (ESB)
> >
> > The TIMA could have been exposed with a page offset in the vCPU mapping
> > but as it only makes sense when the XIVE interrupt mode is active, we
> > chose to use directly the KVM device fd for that. Is that ok ?
> >
> > An alternate solution is to use a device ioctl to allocate an anon fd
> > and do the mapping, but that seems like extra fuss for the same result.
>
> It's okay, it's a natural extension to dev_ops - but thanks for asking
> anyway. :)
Ok, cool.
Given that, do you want to merge directly - since this looks sound
enough, even though the rest of the series needs some polish? Or
would you prefer it to come in via Paulus' tree?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 04/16] KVM: PPC: Book3S HV: XIVE: add a control to initialize a source
From: David Gibson @ 2019-02-26 23:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: kvm, kvm-ppc, Cédric Le Goater, linuxppc-dev
In-Reply-To: <20190226042515.GB28015@blackberry>
[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]
On Tue, Feb 26, 2019 at 03:25:15PM +1100, Paul Mackerras wrote:
> On Mon, Feb 25, 2019 at 01:10:12PM +1100, David Gibson wrote:
> > On Fri, Feb 22, 2019 at 12:28:28PM +0100, Cédric Le Goater wrote:
> > > + /*
> > > + * If the source doesn't already have an IPI, allocate
> > > + * one and get the corresponding data
> > > + */
> > > + if (!state->ipi_number) {
> > > + state->ipi_number = xive_native_alloc_irq();
> > > + if (state->ipi_number == 0) {
> > > + pr_err("Failed to allocate IRQ !\n");
> > > + return -ENXIO;
> > > + }
> > > + xive_native_populate_irq_data(state->ipi_number,
> > > + &state->ipi_data);
> > > + pr_debug("%s allocated hw_irq=0x%x for irq=0x%lx\n", __func__,
> > > + state->ipi_number, irq);
> > > + }
> > > +
> > > + arch_spin_lock(&sb->lock);
> >
> > Why the direct call to arch_spin_lock() rather than just spin_lock()?
>
> He's sharing data structures with the xics-on-xive code, and that code
> has a real-mode variant, and in real mode we don't want to risk
> invoking lockdep code. Hence sb->lock is an arch_spinlock_t, and he
> has to use arch_spin_lock() on it.
Ah, right.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: build failure of current mmotm with skiroot_defconfig
From: Paul Mackerras @ 2019-02-26 22:24 UTC (permalink / raw)
To: Mike Rapoport; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20190226095908.GD11981@rapoport-lnx>
On Tue, Feb 26, 2019 at 11:59:08AM +0200, Mike Rapoport wrote:
> On Tue, Feb 26, 2019 at 10:39:54AM +0100, Christophe Leroy wrote:
> >
> >
> > Le 26/02/2019 à 09:12, Mike Rapoport a écrit :
> > >Hi,
> > >
> > >I've encountered the following error when building skyroot_defconfig with
> > >current mmotm tree:
> > >
> > >make CONFIG_OF_ALL_DTBS=y CONFIG_DTC=y CROSS_COMPILE=/opt/gcc-8.1.0-nolibc/powerpc64-linux/bin/powerpc64-linux- ARCH=powerpc vmlinux
> > > ...
> > > CC arch/powerpc/kernel/dbell.o
> > >In file included from arch/powerpc/kernel/dbell.c:20:
> > >arch/powerpc/include/asm/kvm_ppc.h: In function 'xics_on_xive':
> > >arch/powerpc/include/asm/kvm_ppc.h:625:9: error: implicit declaration of function 'xive_enabled'; did you mean 'eeh_enabled'? [-Werror=implicit-function-declaration]
> > > return xive_enabled() && cpu_has_feature(CPU_FTR_HVMODE);
> > > ^~~~~~~~~~~~
> > > eeh_enabled
> >
> > I can neither find the above in arch/powerpc/include/asm/kvm_ppc.h in the
> > powerpc tree, nor a patch removing it.
> >
> > Where does that comes from ?
>
> It's from current mmotm, probably some merge conflict...
It's not a merge conflict; see http://patchwork.ozlabs.org/patch/1048584/
for the fix.
Paul.
^ permalink raw reply
* [PATCH] KVM: PPC: Fix compilation when KVM is not enabled
From: Paul Mackerras @ 2019-02-26 22:21 UTC (permalink / raw)
To: kvm, kvm-ppc; +Cc: linuxppc-dev
Compiling with CONFIG_PPC_POWERNV=y and KVM disabled currently gives
an error like this:
CC arch/powerpc/kernel/dbell.o
In file included from arch/powerpc/kernel/dbell.c:20:0:
arch/powerpc/include/asm/kvm_ppc.h: In function ‘xics_on_xive’:
arch/powerpc/include/asm/kvm_ppc.h:625:9: error: implicit declaration of function ‘xive_enabled’ [-Werror=implicit-function-declaration]
return xive_enabled() && cpu_has_feature(CPU_FTR_HVMODE);
^
cc1: all warnings being treated as errors
scripts/Makefile.build:276: recipe for target 'arch/powerpc/kernel/dbell.o' failed
make[3]: *** [arch/powerpc/kernel/dbell.o] Error 1
Fix this by making the xics_on_xive() definition conditional on the
same symbol (CONFIG_KVM_BOOK3S_64_HANDLER) that determines whether we
include <asm/xive.h> or not, since that's the header that defines
xive_enabled().
Fixes: 03f953329bd8 ("KVM: PPC: Book3S: Allow XICS emulation to work in nested hosts using XIVE")
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
---
arch/powerpc/include/asm/kvm_ppc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index d283d31..ac22b28 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -619,7 +619,7 @@ static inline int kvmppc_xive_set_irq(struct kvm *kvm, int irq_source_id, u32 ir
static inline void kvmppc_xive_push_vcpu(struct kvm_vcpu *vcpu) { }
#endif /* CONFIG_KVM_XIVE */
-#ifdef CONFIG_PPC_POWERNV
+#if defined(CONFIG_PPC_POWERNV) && defined(CONFIG_KVM_BOOK3S_64_HANDLER)
static inline bool xics_on_xive(void)
{
return xive_enabled() && cpu_has_feature(CPU_FTR_HVMODE);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v1 4/4] clk: qoriq: Add clockgen support for lx2160a
From: Scott Wood @ 2019-02-26 21:30 UTC (permalink / raw)
To: Vabhav Sharma, sudeep.holla@arm.com, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, mturquette@baylibre.com,
sboyd@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org,
linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel-owner@vger.kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, gregkh@linuxfoundation.org, arnd@arndb.de,
kstewart@linuxfoundation.org, yamada.masahiro@socionext.com,
Leo Li, shawnguo@kernel.org
Cc: ulf.hansson@linaro.org, Yogesh Narayan Gaur, Andy Tang,
linux@armlinux.org.uk, adrian.hunter@intel.com
In-Reply-To: <1551132245-6089-5-git-send-email-vabhav.sharma@nxp.com>
On Tue, 2019-02-26 at 10:11 +0000, Vabhav Sharma wrote:
> From: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
>
> Add clockgen support for lx2160a.
> Added entry for compat 'fsl,lx2160a-clockgen'.
>
> Signed-off-by: Tang Yuantian <andy.tang@nxp.com>
> Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/clk/clk-qoriq.c | 12 ++++++++++++
> drivers/cpufreq/qoriq-cpufreq.c | 1 +
> 2 files changed, 13 insertions(+)
Acked-by: Scott Wood <oss@buserror.net>
-Scott
^ permalink raw reply
* Re: [PATCH v1 3/4] clk: qoriq: increase array size of cmux_to_group
From: Scott Wood @ 2019-02-26 21:30 UTC (permalink / raw)
To: Vabhav Sharma, sudeep.holla@arm.com, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, mturquette@baylibre.com,
sboyd@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org,
linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel-owner@vger.kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, gregkh@linuxfoundation.org, arnd@arndb.de,
kstewart@linuxfoundation.org, yamada.masahiro@socionext.com,
Leo Li, shawnguo@kernel.org
Cc: ulf.hansson@linaro.org, Yogesh Narayan Gaur,
linux@armlinux.org.uk, adrian.hunter@intel.com
In-Reply-To: <1551132245-6089-4-git-send-email-vabhav.sharma@nxp.com>
On Tue, 2019-02-26 at 10:11 +0000, Vabhav Sharma wrote:
> From: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
>
> Increase size of cmux_to_group array, to accomdate entry of
> -1 termination.
>
> Added -1, terminated, entry for 4080_cmux_grpX.
>
> Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
> Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
> Acked-by: Stephen Boyd <sboyd@kernel.org>
> ---
> drivers/clk/clk-qoriq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Scott Wood <oss@buserror.net>
-Scott
^ permalink raw reply
* PROBLEM: monotonic clock going backwards on ppc64
From: Jakub Drnec @ 2019-02-26 16:13 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I think I observed a potential problem, is this the correct place to report it? (CC me, not on list)
[1.] One line summary: monotonic clock can be made to decrease on ppc64
[2.] Full description:
Setting the realtime clock can sometimes make the monotonic clock go back by over a hundred years.
Decreasing the realtime clock across the y2k38 threshold is one reliable way to reproduce.
Allegedly this can also happen just by running ntpd, I have not managed to reproduce that other
than booting with rtc at >2038 and then running ntp.
When this happens, anything with timers (e.g. openjdk) breaks rather badly.
[3.] Keywords: gettimeofday, ppc64, vdso
[4.] Kernel information
[4.1.] Kernel version: any (tested on 4.19)
[4.2.] Kernel .config file: any
[5.] Most recent kernel version which did not have the bug: not a regression
[6.] Output of Oops..: not applicable
[7.] Example program which triggers the problem
--- testcase.c
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <unistd.h>
long get_time() {
struct timespec tp;
if (clock_gettime(CLOCK_MONOTONIC, &tp) != 0) {
perror("clock_gettime failed");
exit(1);
}
long result = tp.tv_sec + tp.tv_nsec / 1000000000;
return result;
}
int main() {
printf("monitoring monotonic clock...\n");
long last = get_time();
while(1) {
long now = get_time();
if (now < last) {
printf("clock went backwards by %ld seconds!\n",
last - now);
}
last = now;
sleep(1);
}
return 0;
}
---
when running
# date -s 2040-1-1
# date -s 2037-1-1
program outputs: clock went backwards by 4294967295 seconds!
[8.] Environment: any ppc64, currently reproducing on qemu-system-ppc64le running debian unstable
[X.] Other notes, patches, fixes, workarounds:
The problem seems to be in vDSO code in arch/powerpc/kernel/vdso64/gettimeofday.S.
(possibly because some values used in the calculation are only 32 bit?)
Slightly silly workaround:
nuke the "cmpwi cr1,r3,CLOCK_MONOTONIC" in __kernel_clock_gettime
Now it always goes through the syscall fallback which does not have the same problem.
Regards,
Jakub Drnec
^ permalink raw reply
* Re: [PATCH V3] ASoC: fsl_esai: fix channel swap issue when stream starts
From: Nicolin Chen @ 2019-02-26 19:10 UTC (permalink / raw)
To: S.j. Wang
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6a5f6ddf5c1683106b0cadd5691cd2d9cfe2c997.1551150582.git.shengjiu.wang@nxp.com>
Hi Shengjiu,
Two more trivial comments inline.
On Tue, Feb 26, 2019 at 03:12:25AM +0000, S.j. Wang wrote:
> There is very low possibility ( < 0.1% ) that channel swap happened
> in beginning when multi output/input pin is enabled. The issue is
> that hardware can't send data to correct pin in the beginning with
> the normal enable flow.
>
> This is hardware issue, but there is no errata, the workaround flow
> is that: Each time playback/recording, firstly clear the xSMA/xSMB,
> then enable TE/RE, then enable xSMB and xSMA (xSMB must be enabled
> before xSMA). Which is to use the xSMA as the trigger start register,
> previously the xCR_TE or xCR_RE is the bit for starting.
>
> Fixes commit 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
> Cc: <stable@vger.kernel.org>
> Re> @@ -361,21 +363,13 @@ static int fsl_esai_set_dai_tdm_slot(struct snd_soc_dai *dai, u32 tx_mask,
> esai_priv->slot_width = slot_width;
> esai_priv->slots = slots;
> + esai_priv->tx_mask = tx_mask;
> + esai_priv->rx_mask = rx_mask;
Not necessary to have tabs before "="s.
> @@ -611,12 +606,23 @@ static int fsl_esai_trigger(struct snd_pcm_substream *substream, int cmd,
> regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
> tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK,
> tx ? ESAI_xCR_TE(pins) : ESAI_xCR_RE(pins));
> + mask = tx ? esai_priv->tx_mask : esai_priv->rx_mask;
> +
Please add a line of brief comments for the reason why we are doing
this here, something similar to the commit log, but should have:
1) Clear xSMA/B 2) Set TE/RE before xSMA/B 3)Set xSMB before xSMA.
Apparently having this mask settings in the trigger() does not look
very common, so I believe a line of comments would help a lot.
You may add my Acked-by in your next version:
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Thanks
> + regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
> + ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(mask));
> + regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
> + ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(mask));
> +
> break;
> case SNDRV_PCM_TRIGGER_SUSPEND:
> case SNDRV_PCM_TRIGGER_STOP:
> case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
> tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK, 0);
> + regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
> + ESAI_xSMA_xS_MASK, 0);
> + regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
> + ESAI_xSMB_xS_MASK, 0);
>
^ permalink raw reply
* [PATCH] powerpc/fsl: Fix the flush of branch predictor.
From: Christophe Leroy @ 2019-02-26 18:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Diana Craciun
Cc: linuxppc-dev, linux-kernel
The commit identified below adds MC_BTB_FLUSH macro only when
CONFIG_PPC_FSL_BOOK3E is defined. This results in the following error
on some configs (seen several times with kisskb randconfig_defconfig)
arch/powerpc/kernel/exceptions-64e.S:576: Error: Unrecognized opcode: `mc_btb_flush'
make[3]: *** [scripts/Makefile.build:367: arch/powerpc/kernel/exceptions-64e.o] Error 1
make[2]: *** [scripts/Makefile.build:492: arch/powerpc/kernel] Error 2
make[1]: *** [Makefile:1043: arch/powerpc] Error 2
make: *** [Makefile:152: sub-make] Error 2
This patch adds a blank definition of MC_BTB_FLUSH for other cases.
Fixes: 10c5e83afd4a ("powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)")
Cc: Diana Craciun <diana.craciun@nxp.com>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/kernel/exceptions-64e.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 4549ce8d4637..49381f32b374 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -338,6 +338,7 @@ ret_from_mc_except:
#define GEN_BTB_FLUSH
#define CRIT_BTB_FLUSH
#define DBG_BTB_FLUSH
+#define MC_BTB_FLUSH
#define GDBELL_BTB_FLUSH
#endif
--
2.13.3
^ permalink raw reply related
* Re: [PATCH] soc: fsl: guts: make fsl_guts_get_svr() static
From: Li Yang @ 2019-02-26 17:43 UTC (permalink / raw)
To: Y.b. Lu
Cc: linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Horia Geanta
In-Reply-To: <VI1PR0401MB2237C56CD38D546E83218C8FF87F0@VI1PR0401MB2237.eurprd04.prod.outlook.com>
On Fri, Feb 22, 2019 at 2:09 AM Y.b. Lu <yangbo.lu@nxp.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Horia Geantă <horia.geanta@nxp.com>
> > Sent: Thursday, February 21, 2019 6:38 PM
> > To: Leo Li <leoyang.li@nxp.com>
> > Cc: Y.b. Lu <yangbo.lu@nxp.com>; linuxppc-dev@lists.ozlabs.org;
> > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> > Subject: [PATCH] soc: fsl: guts: make fsl_guts_get_svr() static
> >
> > The export of fsl_guts_get_svr() is a left-over, it's currently used only internally
> > and users needing SoC information should use the generic soc_device
> > infrastructure.
> >
>
> [Y.b. Lu] Acked-by: Yangbo Lu <yangbo.lu@nxp.com>
Applied for next. Thanks.
>
> > Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
> > ---
> > drivers/soc/fsl/guts.c | 3 +--
> > include/linux/fsl/guts.h | 2 --
> > 2 files changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c index
> > 4f9655087bd7..63f6df86f9e5 100644
> > --- a/drivers/soc/fsl/guts.c
> > +++ b/drivers/soc/fsl/guts.c
> > @@ -115,7 +115,7 @@ static const struct fsl_soc_die_attr
> > *fsl_soc_die_match(
> > return NULL;
> > }
> >
> > -u32 fsl_guts_get_svr(void)
> > +static u32 fsl_guts_get_svr(void)
> > {
> > u32 svr = 0;
> >
> > @@ -129,7 +129,6 @@ u32 fsl_guts_get_svr(void)
> >
> > return svr;
> > }
> > -EXPORT_SYMBOL(fsl_guts_get_svr);
> >
> > static int fsl_guts_probe(struct platform_device *pdev) { diff --git
> > a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h index
> > 941b11811f85..1fc0edd71c52 100644
> > --- a/include/linux/fsl/guts.h
> > +++ b/include/linux/fsl/guts.h
> > @@ -135,8 +135,6 @@ struct ccsr_guts {
> > u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
> > } __attribute__ ((packed));
> >
> > -u32 fsl_guts_get_svr(void);
> > -
> > /* Alternate function signal multiplex control */ #define
> > MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
> >
> > --
> > 2.16.2
>
^ permalink raw reply
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