* Re: [PATCH V2 3/5] tools/perf: Add powerpc support for PERF_SAMPLE_WEIGHT_STRUCT
From: Jiri Olsa @ 2021-03-24 19:43 UTC (permalink / raw)
To: Athira Rajeev
Cc: ravi.bangoria, maddy, peterz, linux-kernel, acme,
linux-perf-users, jolsa, kjain, linuxppc-dev, kan.liang
In-Reply-To: <1616425047-1666-4-git-send-email-atrajeev@linux.vnet.ibm.com>
On Mon, Mar 22, 2021 at 10:57:25AM -0400, Athira Rajeev wrote:
> Add arch specific arch_evsel__set_sample_weight() to set the new
> sample type for powerpc.
>
> Add arch specific arch_perf_parse_sample_weight() to store the
> sample->weight values depending on the sample type applied.
> if the new sample type (PERF_SAMPLE_WEIGHT_STRUCT) is applied,
> store only the lower 32 bits to sample->weight. If sample type
> is 'PERF_SAMPLE_WEIGHT', store the full 64-bit to sample->weight.
>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---
> tools/perf/arch/powerpc/util/Build | 2 ++
> tools/perf/arch/powerpc/util/event.c | 32 ++++++++++++++++++++++++++++++++
> tools/perf/arch/powerpc/util/evsel.c | 8 ++++++++
> 3 files changed, 42 insertions(+)
> create mode 100644 tools/perf/arch/powerpc/util/event.c
> create mode 100644 tools/perf/arch/powerpc/util/evsel.c
>
> diff --git a/tools/perf/arch/powerpc/util/Build b/tools/perf/arch/powerpc/util/Build
> index b7945e5a543b..8a79c4126e5b 100644
> --- a/tools/perf/arch/powerpc/util/Build
> +++ b/tools/perf/arch/powerpc/util/Build
> @@ -4,6 +4,8 @@ perf-y += kvm-stat.o
> perf-y += perf_regs.o
> perf-y += mem-events.o
> perf-y += sym-handling.o
> +perf-y += evsel.o
> +perf-y += event.o
>
> perf-$(CONFIG_DWARF) += dwarf-regs.o
> perf-$(CONFIG_DWARF) += skip-callchain-idx.o
> diff --git a/tools/perf/arch/powerpc/util/event.c b/tools/perf/arch/powerpc/util/event.c
> new file mode 100644
> index 000000000000..f49d32c2c8ae
> --- /dev/null
> +++ b/tools/perf/arch/powerpc/util/event.c
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <linux/types.h>
> +#include <linux/string.h>
> +#include <linux/zalloc.h>
> +
> +#include "../../../util/event.h"
> +#include "../../../util/synthetic-events.h"
> +#include "../../../util/machine.h"
> +#include "../../../util/tool.h"
> +#include "../../../util/map.h"
> +#include "../../../util/debug.h"
nit, just #include "utils/...h" should work no?
other than that, the patchset looks ok to me
Acked-by: Jiri Olsa <jolsa@redhat.com>
thanks,
jirka
> +
> +void arch_perf_parse_sample_weight(struct perf_sample *data,
> + const __u64 *array, u64 type)
> +{
> + union perf_sample_weight weight;
> +
> + weight.full = *array;
> + if (type & PERF_SAMPLE_WEIGHT)
> + data->weight = weight.full;
> + else
> + data->weight = weight.var1_dw;
> +}
> +
> +void arch_perf_synthesize_sample_weight(const struct perf_sample *data,
> + __u64 *array, u64 type)
> +{
> + *array = data->weight;
> +
> + if (type & PERF_SAMPLE_WEIGHT_STRUCT)
> + *array &= 0xffffffff;
> +}
> diff --git a/tools/perf/arch/powerpc/util/evsel.c b/tools/perf/arch/powerpc/util/evsel.c
> new file mode 100644
> index 000000000000..2f733cdc8dbb
> --- /dev/null
> +++ b/tools/perf/arch/powerpc/util/evsel.c
> @@ -0,0 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <stdio.h>
> +#include "util/evsel.h"
> +
> +void arch_evsel__set_sample_weight(struct evsel *evsel)
> +{
> + evsel__set_sample_bit(evsel, WEIGHT_STRUCT);
> +}
> --
> 1.8.3.1
>
^ permalink raw reply
* [PATCH v7 3/7] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
From: Serge Semin @ 2021-03-24 20:48 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Felipe Balbi, Michael Ellerman,
Vladimir Zapolskiy, Alexey Brodkin, Vineet Gupta, Rob Herring,
Greg Kroah-Hartman, Krzysztof Kozlowski, Benjamin Herrenschmidt,
Paul Mackerras
Cc: Serge Semin, devicetree, linuxppc-dev, linux-kernel, Serge Semin
In-Reply-To: <20210324204836.29668-1-Sergey.Semin@baikalelectronics.ru>
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/powerpc/boot/dts/akebono.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/akebono.dts b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@30000010000 {
interrupts = <93 2>;
};
- EHCI0: ehci@30010000000 {
+ EHCI0: usb@30010000000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x10000000 0x0 0x10000>;
interrupt-parent = <&MPIC>;
@@ -140,14 +140,14 @@ SD0: sd@30000000000 {
interrupt-parent = <&MPIC>;
};
- OHCI0: ohci@30010010000 {
+ OHCI0: usb@30010010000 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x10010000 0x0 0x10000>;
interrupt-parent = <&MPIC>;
interrupts = <89 1>;
};
- OHCI1: ohci@30010020000 {
+ OHCI1: usb@30010020000 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x10020000 0x0 0x10000>;
interrupt-parent = <&MPIC>;
--
2.30.1
^ permalink raw reply related
* [PATCH v7 0/7] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name
From: Serge Semin @ 2021-03-24 20:48 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Felipe Balbi, Michael Ellerman,
Vladimir Zapolskiy, Alexey Brodkin, Vineet Gupta, Rob Herring,
Greg Kroah-Hartman, Krzysztof Kozlowski
Cc: devicetree, Khuong Dinh, Patrice Chotard, Serge Semin,
linux-kernel, Serge Semin, Paul Mackerras, linux-arm-msm,
linux-snps-arc, linuxppc-dev, linux-arm-kernel
As the subject states this series is an attempt to harmonize the xHCI,
EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
framework of the patchset [1].
Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
controllers with "synopsys,"-vendor prefix compatible string in favor of
the ones with valid "snps,"-prefix. It's done in all the DTS files,
which have been unfortunate to define such nodes.
Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
been erroneously declared as boolean while having uint32 type. Neil said
it was ok to init that property with 0x20 value.
Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
and DWC USB3 DT nodes name as in accordance with their DT schema the
corresponding node name is suppose to comply with the Generic USB HCD DT
schema, which requires the USB nodes to have the name acceptable by the
regexp: "^usb(@.*)?". Such requirement had been applicable even before we
introduced the new DT schema in [1], but as we can see it hasn't been
strictly implemented for a lot the DTS files. Since DT schema is now
available the automated DTS validation shall make sure that the rule isn't
violated.
Note most of these patches have been a part of the last three patches of
[1]. But since there is no way to have them merged in in a combined
manner, I had to move them to the dedicated series and split them up so to
be accepted by the corresponding subsystem maintainers one-by-one.
[1] Link: https://lore.kernel.org/linux-usb/20201014101402.18271-1-Sergey.Semin@baikalelectronics.ru/
Changelog v1:
- As Krzysztof suggested I've created a script which checked whether the
node names had been also updated in all the depended dts files. As a
result I found two more files which should have been also modified:
arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
- Correct the USB DWC3 nodes name found in
arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
Link: https://lore.kernel.org/linux-usb/20201020115959.2658-1-Sergey.Semin@baikalelectronics.ru
Changelog v2:
- Drop the patch:
[PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
and get back the one which marks the "synopsys,dwc3" compatible string
as deprecated into the DT schema related series.
- Drop the patches:
[PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
[PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
[PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
[PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
[PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
[PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
[PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
[PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
[PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
[PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
[PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
- Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
sub-node and falling back to the "dwc3@"-prefixed one on failure.
Link: https://lore.kernel.org/linux-usb/20201111091552.15593-1-Sergey.Semin@baikalelectronics.ru
Changelog v3:
- Drop the patches:
[PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
[PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
[PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes name
[PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
Link: https://lore.kernel.org/linux-usb/20201205155621.3045-1-Sergey.Semin@baikalelectronics.ru
Changelog v4:
- Just resend.
Link: https://lore.kernel.org/linux-usb/20201210091756.18057-1-Sergey.Semin@baikalelectronics.ru/
Changelog v5:
- Drop the patch:
[PATCH v4 02/10] arm64: dts: amlogic: meson-g12: Set FL-adj property value
since it has been applied to the corresponding maintainers repos.
- Get back the patch:
[PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
as it has been missing in the kernel 5.11-rc7
- Rebase onto the kernel 5.11-rc7.
Link: https://lore.kernel.org/lkml/20210208135154.6645-1-Sergey.Semin@baikalelectronics.ru/
Changelog v6:
- Just resend and add linux-usb.vger.kernel.org to the list of Ccecipients.
Link: https://lore.kernel.org/linux-usb/20210210172850.20849-1-Sergey.Semin@baikalelectronics.ru
Link: https://lore.kernel.org/linux-usb/20210212205521.14280-1-Sergey.Semin@baikalelectronics.ru
Changelog v7:
- Replace "of_get_child_by_name(np, "usb") ?: of_get_child_by_name(np, "dwc3");"
pattern with using of_get_compatible_child() method in the Qcom DWC3 driver.
- Drop the patches:
[PATCH v6 01/10] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
[PATCH v6 02/10] arm: dts: keystone: Correct DWC USB3 compatible string
[PATCH v6 06/10] arm: dts: keystone: Harmonize DWC USB3 DT nodes name
since they have been applied to the corresponding maintainers repos.
- Cleanup the list of recipients.
- Rebase onto kernel 5.12-rc4.
Cc: Khuong Dinh <khuong@os.amperecomputing.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-snps-arc@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (7):
arc: dts: Harmonize EHCI/OHCI DT nodes name
arm: dts: lpc18xx: Harmonize EHCI/OHCI DT nodes name
powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name
arm: dts: stih407-family: Harmonize DWC USB3 DT nodes name
arm64: dts: apm: Harmonize DWC USB3 DT nodes name
usb: dwc3: qcom: Detect DWC3 DT-nodes using compatible string
arm64: dts: qcom: Harmonize DWC USB3 DT nodes name
arch/arc/boot/dts/axc003.dtsi | 4 ++--
arch/arc/boot/dts/axc003_idu.dtsi | 4 ++--
arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++--
arch/arc/boot/dts/hsdk.dts | 4 ++--
arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +-
arch/arm/boot/dts/lpc18xx.dtsi | 4 ++--
arch/arm/boot/dts/stih407-family.dtsi | 2 +-
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 4 ++--
arch/arm64/boot/dts/apm/apm-storm.dtsi | 6 +++---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
arch/arm64/boot/dts/qcom/qcs404.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
arch/powerpc/boot/dts/akebono.dts | 6 +++---
drivers/usb/dwc3/dwc3-qcom.c | 2 +-
20 files changed, 35 insertions(+), 35 deletions(-)
--
2.30.1
^ permalink raw reply
* Re: [RFC PATCH 6/8] powerpc/mm/book3s64/hash: drop pre 2.06 tlbiel for clang
From: Segher Boessenkool @ 2021-03-24 21:07 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev, llvmlinux, Daniel Axtens
In-Reply-To: <20210324155105.GZ16691@gate.crashing.org>
On Wed, Mar 24, 2021 at 10:51:05AM -0500, Segher Boessenkool wrote:
> The variants with fewer operands have those coded as 0 in the
> instruction. All of this is backwards compatible.
I was reminded that this is broken in ISA 2.03. Ouch.
Segher
^ permalink raw reply
* Re: [PATCH 0/6] ASoC: fsl: Don't use devm_regmap_init_mmio_clk
From: Mark Brown @ 2021-03-24 23:39 UTC (permalink / raw)
To: Shengjiu Wang, festevam, Xiubo.Lee, timur, nicoleotsuka, tiwai,
perex, alsa-devel
Cc: Mark Brown, linuxppc-dev, linux-kernel
In-Reply-To: <1616579928-22428-1-git-send-email-shengjiu.wang@nxp.com>
On Wed, 24 Mar 2021 17:58:42 +0800, Shengjiu Wang wrote:
> When there is power domain bind with ipg clock,
>
> The call flow:
> devm_regmap_init_mmio_clk
> - clk_prepare()
> - clk_pm_runtime_get()
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/6] ASoC: fsl_esai: Don't use devm_regmap_init_mmio_clk
commit: 203773e39347922b3923df6094324d430664466e
[2/6] ASoC: fsl_spdif: Don't use devm_regmap_init_mmio_clk
commit: c2562572467a74fd637d2d22fb773b052512528c
[3/6] ASoC: fsl_asrc: Don't use devm_regmap_init_mmio_clk
commit: cab04ab5900fea6655f2a49d1f94c37200b63a59
[4/6] ASoC: fsl_easrc: Don't use devm_regmap_init_mmio_clk
commit: 069b24f22eb9dba2e0886b40ea3feaa98e3f4f9b
[5/6] ASoC: fsl_audmix: Don't use devm_regmap_init_mmio_clk
commit: 3feaba79d8f701a774815483aa0e7f4edb15c880
[6/6] ASoC: fsl_micfil: Don't use devm_regmap_init_mmio_clk
commit: b5cf28f7a890f3554ca15a43edbbb86dd1b9663c
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [RESEND 1/1] powerpc: asm: hvconsole: Move 'hvc_vio_init_early's prototype to shared location
From: Michael Ellerman @ 2021-03-25 1:10 UTC (permalink / raw)
To: Lee Jones, linux-kernel, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20210324103854.GK2916463@dell>
Lee Jones <lee.jones@linaro.org> writes:
> On Wed, 03 Mar 2021, Lee Jones wrote:
>
>> Fixes the following W=1 kernel build warning(s):
>>
>> drivers/tty/hvc/hvc_vio.c:385:13: warning: no previous prototype for ‘hvc_vio_init_early’ [-Wmissing-prototypes]
>> 385 | void __init hvc_vio_init_early(void)
>> | ^~~~~~~~~~~~~~~~~~
>>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>> ---
>> arch/powerpc/include/asm/hvconsole.h | 3 +++
>> arch/powerpc/platforms/pseries/pseries.h | 3 ---
>> arch/powerpc/platforms/pseries/setup.c | 1 +
>> 3 files changed, 4 insertions(+), 3 deletions(-)
>
> Any idea who might pick this up please?
I will. I have it in my next-test branch.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/asm-offsets: GPR14 is not needed either
From: Rashmica Gupta @ 2021-03-25 3:34 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <9881c68fbca004f9ea18fc9473f630e11ccd6417.1615806071.git.christophe.leroy@csgroup.eu>
On Mon, 2021-03-15 at 11:01 +0000, Christophe Leroy wrote:
> Commit aac6a91fea93 ("powerpc/asm: Remove unused symbols in
> asm-offsets.c") removed GPR15 to GPR31 but kept GPR14,
> probably because it pops up in a couple of comments when doing
> a grep.
>
> However, it was never used either, so remove it as well.
>
Looks good to me.
Reviewed-by: Rashmica Gupta <rashmica.g@gmail.com>
> Fixes: aac6a91fea93 ("powerpc/asm: Remove unused symbols in asm-
> offsets.c")
> Cc: Rashmica Gupta <rashmicy@gmail.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/kernel/asm-offsets.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/asm-offsets.c
> b/arch/powerpc/kernel/asm-offsets.c
> index f3a662201a9f..4d230c5c7099 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -323,9 +323,6 @@ int main(void)
> STACK_PT_REGS_OFFSET(GPR11, gpr[11]);
> STACK_PT_REGS_OFFSET(GPR12, gpr[12]);
> STACK_PT_REGS_OFFSET(GPR13, gpr[13]);
> -#ifndef CONFIG_PPC64
> - STACK_PT_REGS_OFFSET(GPR14, gpr[14]);
> -#endif /* CONFIG_PPC64 */
> /*
> * Note: these symbols include _ because they overlap with
> special
> * register names
^ permalink raw reply
* Re: [PATCH 0/2] Fix EH race and MQ support
From: Martin K. Petersen @ 2021-03-25 3:53 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: brking, linuxppc-dev, linux-scsi, Martin K . Petersen,
linux-kernel
In-Reply-To: <20210319205029.312969-1-tyreld@linux.ibm.com>
On Fri, 19 Mar 2021 14:50:27 -0600, Tyrel Datwyler wrote:
> Changes to the locking pattern protecting the event lists and handling of scsi
> command completion introduced a race where an ouststanding command that EH is
> waiting ifor to complete is no longer identifiable by being on the sent list, but
> instead as a command that is not on the free list. This is a result of moving
> commands to be completed off the sent list to a private list to be completed
> outside the list lock.
>
> [...]
Applied to 5.12/scsi-fixes, thanks!
[1/2] ibmvfc: fix potential race in ibmvfc_wait_for_ops
https://git.kernel.org/mkp/scsi/c/8b1c9b202549
[2/2] ibmvfc: make ibmvfc_wait_for_ops MQ aware
https://git.kernel.org/mkp/scsi/c/62fc2661482b
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH 00/36] [Set 4] Rid W=1 warnings in SCSI
From: Martin K. Petersen @ 2021-03-25 3:53 UTC (permalink / raw)
To: Lee Jones
Cc: Tyrel Datwyler, Hannes Reinecke, Anil Ravindranath, Brian Macy,
willy, Le Moal, David Chaw, Marvell, Jirka Hanika, Brian King,
Artur Paszkiewicz, target-devel, Drew Eckhardt, Linda Xie,
Ketan Mukadam, Paul Mackerras, linux-drivers, Dave Boutcher,
Brian King, linux-scsi, Subbu Seetharaman, Sathya Prakash,
Doug Ledford, Leonard N. Zubkoff, Christoph Hellwig,
Nicholas A. Bellinger, Colin DeVilbiss, Karan Tilak Kumar,
Badari Pulavarty, Alan Cox, Bryant G. Ly, Douglas Gilbert,
Jamie Lenehan, MPT-FusionLinux.pdl, Matthew R. Ochs,
MPT-FusionLinux.pdl, Eric Youngdale, Torben Mathiasen,
Michael Cyr, dc395x, Satish Kharat, Suganath Prabu Subramani,
James E.J. Bottomley, Luben Tuikov, Ali Akcaagac, Santiago Leon,
Jitendra Bhivare, Manoj N. Kumar, Hannes Reinecke, Erich Chen,
Dave Boutcher, Richard Gooch, Uma Krishnan, Sreekanth Reddy,
C.L. Huang, Martin K . Petersen, Oliver Neukum, linux-kernel,
Sesidhar Baddela, Bas Vermeulen, Alex Davis, Kurt Garloff,
Shaun Tancheff, FUJITA Tomonori, linuxppc-dev, Linux GmbH
In-Reply-To: <20210317091230.2912389-1-lee.jones@linaro.org>
On Wed, 17 Mar 2021 09:11:54 +0000, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> Lee Jones (36):
> scsi: myrb: Demote non-conformant kernel-doc headers and fix others
> scsi: ipr: Fix incorrect function names in their headers
> scsi: mvumi: Fix formatting and doc-rot issues
> scsi: sd_zbc: Place function name into header
> scsi: pmcraid: Fix a whole host of kernel-doc issues
> scsi: sd: Fix function name in header
> scsi: aic94xx: aic94xx_dump: Correct misspelling of function
> asd_dump_seq_state()
> scsi: be2iscsi: be_main: Ensure function follows directly after its
> header
> scsi: dc395x: Fix some function param descriptions
> scsi: initio: Fix a few kernel-doc misdemeanours
> scsi: a100u2w: Fix some misnaming and formatting issues
> scsi: myrs: Add missing ':' to make the kernel-doc checker happy
> scsi: pmcraid: Correct function name pmcraid_show_adapter_id() in
> header
> scsi: mpt3sas: mpt3sas_scs: Fix a few kernel-doc issues
> scsi: be2iscsi: be_main: Demote incomplete/non-conformant kernel-doc
> header
> scsi: isci: phy: Fix a few different kernel-doc related issues
> scsi: fnic: fnic_scsi: Demote non-conformant kernel-doc headers
> scsi: fnic: fnic_fcs: Kernel-doc headers must contain the function
> name
> scsi: isci: phy: Provide function name and demote non-conforming
> header
> scsi: isci: request: Fix a myriad of kernel-doc issues
> scsi: isci: host: Fix bunch of kernel-doc related issues
> scsi: isci: task: Demote non-conformant header and remove superfluous
> param
> scsi: isci: remote_node_table: Fix a bunch of kernel-doc misdemeanours
> scsi: isci: remote_node_context: Fix one function header and demote a
> couple more
> scsi: isci: port_config: Fix a bunch of doc-rot and demote abuses
> scsi: isci: remote_device: Fix a bunch of doc-rot issues
> scsi: isci: request: Fix doc-rot issue relating to 'ireq' param
> scsi: isci: port: Fix a bunch of kernel-doc issues
> scsi: isci: remote_node_context: Demote kernel-doc abuse
> scsi: isci: remote_node_table: Provide some missing params and remove
> others
> scsi: cxlflash: main: Fix a little do-rot
> scsi: cxlflash: superpipe: Fix a few misnaming issues
> scsi: ibmvscsi: Fix a bunch of kernel-doc related issues
> scsi: ibmvscsi: ibmvfc: Fix a bunch of misdocumentation
> scsi: ibmvscsi_tgt: ibmvscsi_tgt: Remove duplicate section 'NOTE'
> scsi: cxlflash: vlun: Fix some misnaming related doc-rot
>
> [...]
Applied to 5.13/scsi-queue, thanks!
[01/36] scsi: myrb: Demote non-conformant kernel-doc headers and fix others
https://git.kernel.org/mkp/scsi/c/12a1b740f225
[02/36] scsi: ipr: Fix incorrect function names in their headers
https://git.kernel.org/mkp/scsi/c/637b5c3ebc1c
[03/36] scsi: mvumi: Fix formatting and doc-rot issues
https://git.kernel.org/mkp/scsi/c/5ccd626516e1
[04/36] scsi: sd_zbc: Place function name into header
https://git.kernel.org/mkp/scsi/c/59863cb53d80
[05/36] scsi: pmcraid: Fix a whole host of kernel-doc issues
https://git.kernel.org/mkp/scsi/c/3673b7b0007b
[06/36] scsi: sd: Fix function name in header
https://git.kernel.org/mkp/scsi/c/ad907c54e36f
[07/36] scsi: aic94xx: aic94xx_dump: Correct misspelling of function asd_dump_seq_state()
https://git.kernel.org/mkp/scsi/c/3e2f4679ea03
[08/36] scsi: be2iscsi: be_main: Ensure function follows directly after its header
https://git.kernel.org/mkp/scsi/c/f1d50e8ee5c9
[09/36] scsi: dc395x: Fix some function param descriptions
https://git.kernel.org/mkp/scsi/c/33c8ef953ece
[10/36] scsi: initio: Fix a few kernel-doc misdemeanours
https://git.kernel.org/mkp/scsi/c/100ec495e01e
[11/36] scsi: a100u2w: Fix some misnaming and formatting issues
https://git.kernel.org/mkp/scsi/c/c548a6250627
[12/36] scsi: myrs: Add missing ':' to make the kernel-doc checker happy
https://git.kernel.org/mkp/scsi/c/9eb292eb2ef7
[13/36] scsi: pmcraid: Correct function name pmcraid_show_adapter_id() in header
https://git.kernel.org/mkp/scsi/c/a364a147b1dc
[14/36] scsi: mpt3sas: mpt3sas_scs: Fix a few kernel-doc issues
https://git.kernel.org/mkp/scsi/c/a8d548b0b3ee
[15/36] scsi: be2iscsi: be_main: Demote incomplete/non-conformant kernel-doc header
https://git.kernel.org/mkp/scsi/c/a90a8c607570
[16/36] scsi: isci: phy: Fix a few different kernel-doc related issues
https://git.kernel.org/mkp/scsi/c/6af1d9bd9051
[17/36] scsi: fnic: fnic_scsi: Demote non-conformant kernel-doc headers
https://git.kernel.org/mkp/scsi/c/c7eab0704c30
[18/36] scsi: fnic: fnic_fcs: Kernel-doc headers must contain the function name
https://git.kernel.org/mkp/scsi/c/2efd8631d6a5
[19/36] scsi: isci: phy: Provide function name and demote non-conforming header
https://git.kernel.org/mkp/scsi/c/6ab7ca5139b7
[20/36] scsi: isci: request: Fix a myriad of kernel-doc issues
https://git.kernel.org/mkp/scsi/c/db35a0835357
[21/36] scsi: isci: host: Fix bunch of kernel-doc related issues
https://git.kernel.org/mkp/scsi/c/44b7ca966128
[22/36] scsi: isci: task: Demote non-conformant header and remove superfluous param
https://git.kernel.org/mkp/scsi/c/0afdee03f2e7
[23/36] scsi: isci: remote_node_table: Fix a bunch of kernel-doc misdemeanours
https://git.kernel.org/mkp/scsi/c/103d61927ed3
[24/36] scsi: isci: remote_node_context: Fix one function header and demote a couple more
https://git.kernel.org/mkp/scsi/c/ad276048f1bc
[25/36] scsi: isci: port_config: Fix a bunch of doc-rot and demote abuses
https://git.kernel.org/mkp/scsi/c/29faa5ce26ae
[26/36] scsi: isci: remote_device: Fix a bunch of doc-rot issues
https://git.kernel.org/mkp/scsi/c/242e15d7a4f4
[27/36] scsi: isci: request: Fix doc-rot issue relating to 'ireq' param
https://git.kernel.org/mkp/scsi/c/a8604e44514d
[28/36] scsi: isci: port: Fix a bunch of kernel-doc issues
https://git.kernel.org/mkp/scsi/c/7292a8b039c5
[29/36] scsi: isci: remote_node_context: Demote kernel-doc abuse
https://git.kernel.org/mkp/scsi/c/d2d480f132e8
[30/36] scsi: isci: remote_node_table: Provide some missing params and remove others
https://git.kernel.org/mkp/scsi/c/188f513dd22c
[31/36] scsi: cxlflash: main: Fix a little do-rot
https://git.kernel.org/mkp/scsi/c/cf0ad7a15ac5
[32/36] scsi: cxlflash: superpipe: Fix a few misnaming issues
https://git.kernel.org/mkp/scsi/c/32b3edfd28f8
[33/36] scsi: ibmvscsi: Fix a bunch of kernel-doc related issues
https://git.kernel.org/mkp/scsi/c/841d7df0d416
[34/36] scsi: ibmvscsi: ibmvfc: Fix a bunch of misdocumentation
https://git.kernel.org/mkp/scsi/c/dd9c77297148
[35/36] scsi: ibmvscsi_tgt: ibmvscsi_tgt: Remove duplicate section 'NOTE'
https://git.kernel.org/mkp/scsi/c/cba3ebfc008e
[36/36] scsi: cxlflash: vlun: Fix some misnaming related doc-rot
https://git.kernel.org/mkp/scsi/c/a690baa47fd1
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* RE: [PATCH 15/17] iommu: remove DOMAIN_ATTR_NESTING
From: Tian, Kevin @ 2021-03-25 6:12 UTC (permalink / raw)
To: Auger Eric, Christoph Hellwig
Cc: freedreno@lists.freedesktop.org, Liu, Yi L, kvm@vger.kernel.org,
Will Deacon, linux-arm-msm@vger.kernel.org,
dri-devel@lists.freedesktop.org, Li Yang,
iommu@lists.linux-foundation.org, netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, David Woodhouse,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <3a1194de-a053-84dd-3d6a-bff8e01ebcd3@redhat.com>
> From: Auger Eric
> Sent: Monday, March 15, 2021 3:52 PM
> To: Christoph Hellwig <hch@lst.de>
> Cc: kvm@vger.kernel.org; Will Deacon <will@kernel.org>; linuxppc-
> dev@lists.ozlabs.org; dri-devel@lists.freedesktop.org; Li Yang
> <leoyang.li@nxp.com>; iommu@lists.linux-foundation.org;
>
> Hi Christoph,
>
> On 3/14/21 4:58 PM, Christoph Hellwig wrote:
> > On Sun, Mar 14, 2021 at 11:44:52AM +0100, Auger Eric wrote:
> >> As mentionned by Robin, there are series planning to use
> >> DOMAIN_ATTR_NESTING to get info about the nested caps of the iommu
> (ARM
> >> and Intel):
> >>
> >> [Patch v8 00/10] vfio: expose virtual Shared Virtual Addressing to VMs
> >> patches 1, 2, 3
> >>
> >> Is the plan to introduce a new domain_get_nesting_info ops then?
> >
> > The plan as usual would be to add it the series adding that support.
> > Not sure what the merge plans are - if the series is ready to be
> > merged I could rebase on top of it, otherwise that series will need
> > to add the method.
> OK I think your series may be upstreamed first.
>
Agree. The vSVA series is still undergoing a refactor according to Jason's
comment thus won't be ready in short term. It's better to let this one
go in first.
Thanks
Kevin
^ permalink raw reply
* Re: [PATCH 15/17] iommu: remove DOMAIN_ATTR_NESTING
From: Christoph Hellwig @ 2021-03-25 6:51 UTC (permalink / raw)
To: Tian, Kevin
Cc: freedreno@lists.freedesktop.org, Liu, Yi L, kvm@vger.kernel.org,
Will Deacon, linux-arm-msm@vger.kernel.org,
dri-devel@lists.freedesktop.org, Li Yang, Auger Eric,
iommu@lists.linux-foundation.org, David Woodhouse,
netdev@vger.kernel.org, virtualization@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, Christoph Hellwig,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <MWHPR11MB188688125518D050E384658F8C629@MWHPR11MB1886.namprd11.prod.outlook.com>
On Thu, Mar 25, 2021 at 06:12:37AM +0000, Tian, Kevin wrote:
> Agree. The vSVA series is still undergoing a refactor according to Jason's
> comment thus won't be ready in short term. It's better to let this one
> go in first.
Would be great to get a few more reviews while we're at it :)
^ permalink raw reply
* Re: [PATCH V3 -next] powerpc: kernel/time.c - cleanup warnings
From: Alexandre Belloni @ 2021-03-25 8:45 UTC (permalink / raw)
To: heying (H)
Cc: linux-rtc, a.zummo, geert+renesas, peterz, frederic, linux-kernel,
npiggin, kernelfans, paulus, geert, tglx, msuchanek, linuxppc-dev
In-Reply-To: <18a8d444-f1a5-61e0-b9f2-f85c03d71686@huawei.com>
On 24/03/2021 17:46:19+0800, heying (H) wrote:
> Many thanks for your suggestion. As you suggest, rtc_lock should be local to
> platforms.
>
> Does it mean not only powerpc but also all other platforms should adapt this
> change?
Not all the other ones, in the current state, x86 still needs it. I'll
work on that. Again, the patch is fine as is.
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] pseries: prevent free CPU ids to be reused on another node
From: Laurent Dufour @ 2021-03-25 9:35 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: nathanl, cheloha, linuxppc-dev, linux-kernel
When a CPU is hot added, the CPU ids are taken from the available mask from
the lower possible set. If that set of values was previously used for CPU
attached to a different node, this seems to application like if these CPUs
have migrated from a node to another one which is not expected in real
life.
To prevent this, it is needed to record the CPU ids used for each node and
to not reuse them on another node. However, to prevent CPU hot plug to
fail, in the case the CPU ids is starved on a node, the capability to reuse
other nodes’ free CPU ids is kept. A warning is displayed in such a case
to warn the user.
A new CPU bit mask (node_recorded_ids_map) is introduced for each possible
node. It is populated with the CPU onlined at boot time, and then when a
CPU is hot plug to a node. The bits in that mask remain when the CPU is hot
unplugged, to remind this CPU ids have been used for this node.
If no id set was found, a retry is made without removing the ids used on
the other nodes to try reusing them. This is the way ids have been
allocated prior to this patch.
The effect of this patch can be seen by removing and adding CPUs using the
Qemu monitor. In the following case, the first CPU from the node 2 is
removed, then the first one from the node 1 is removed too. Later, the
first CPU of the node 2 is added back. Without that patch, the kernel will
numbered these CPUs using the first CPU ids available which are the ones
freed when removing the second CPU of the node 0. This leads to the CPU ids
16-23 to move from the node 1 to the node 2. With the patch applied, the
CPU ids 32-39 are used since they are the lowest free ones which have not
been used on another node.
At boot time:
[root@vm40 ~]# numactl -H | grep cpus
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 2 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
Vanilla kernel, after the CPU hot unplug/plug operations:
[root@vm40 ~]# numactl -H | grep cpus
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 1 cpus: 24 25 26 27 28 29 30 31
node 2 cpus: 16 17 18 19 20 21 22 23 40 41 42 43 44 45 46 47
Patched kernel, after the CPU hot unplug/plug operations:
[root@vm40 ~]# numactl -H | grep cpus
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 1 cpus: 24 25 26 27 28 29 30 31
node 2 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
Changes since V1 (no functional changes):
- update the test's output in the commit's description
- node_recorded_ids_map should be static
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 83 ++++++++++++++++++--
1 file changed, 76 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 12cbffd3c2e3..48c7943b25b0 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -39,6 +39,8 @@
/* This version can't take the spinlock, because it never returns */
static int rtas_stop_self_token = RTAS_UNKNOWN_SERVICE;
+static cpumask_var_t node_recorded_ids_map[MAX_NUMNODES];
+
static void rtas_stop_self(void)
{
static struct rtas_args args;
@@ -151,29 +153,61 @@ static void pseries_cpu_die(unsigned int cpu)
*/
static int pseries_add_processor(struct device_node *np)
{
- unsigned int cpu;
+ unsigned int cpu, node;
cpumask_var_t candidate_mask, tmp;
- int err = -ENOSPC, len, nthreads, i;
+ int err = -ENOSPC, len, nthreads, i, nid;
const __be32 *intserv;
+ bool force_reusing = false;
intserv = of_get_property(np, "ibm,ppc-interrupt-server#s", &len);
if (!intserv)
return 0;
- zalloc_cpumask_var(&candidate_mask, GFP_KERNEL);
- zalloc_cpumask_var(&tmp, GFP_KERNEL);
+ alloc_cpumask_var(&candidate_mask, GFP_KERNEL);
+ alloc_cpumask_var(&tmp, GFP_KERNEL);
+
+ /*
+ * Fetch from the DT nodes read by dlpar_configure_connector() the NUMA
+ * node id the added CPU belongs to.
+ */
+ nid = of_node_to_nid(np);
+ if (nid < 0 || !node_possible(nid))
+ nid = first_online_node;
nthreads = len / sizeof(u32);
- for (i = 0; i < nthreads; i++)
- cpumask_set_cpu(i, tmp);
cpu_maps_update_begin();
BUG_ON(!cpumask_subset(cpu_present_mask, cpu_possible_mask));
+again:
+ cpumask_clear(candidate_mask);
+ cpumask_clear(tmp);
+ for (i = 0; i < nthreads; i++)
+ cpumask_set_cpu(i, tmp);
+
/* Get a bitmap of unoccupied slots. */
cpumask_xor(candidate_mask, cpu_possible_mask, cpu_present_mask);
+
+ /*
+ * Remove free ids previously assigned on the other nodes. We can walk
+ * only online nodes because once a node became online it is not turned
+ * offlined back.
+ */
+ if (!force_reusing)
+ for_each_online_node(node) {
+ if (node == nid) /* Keep our node's recorded ids */
+ continue;
+ cpumask_andnot(candidate_mask, candidate_mask,
+ node_recorded_ids_map[node]);
+ }
+
if (cpumask_empty(candidate_mask)) {
+ if (!force_reusing) {
+ force_reusing = true;
+ goto again;
+ }
+
/* If we get here, it most likely means that NR_CPUS is
* less than the partition's max processors setting.
*/
@@ -191,12 +225,36 @@ static int pseries_add_processor(struct device_node *np)
cpumask_shift_left(tmp, tmp, nthreads);
if (cpumask_empty(tmp)) {
+ if (!force_reusing) {
+ force_reusing = true;
+ goto again;
+ }
printk(KERN_ERR "Unable to find space in cpu_present_mask for"
" processor %pOFn with %d thread(s)\n", np,
nthreads);
goto out_unlock;
}
+ /* Record the newly used CPU ids for the associate node. */
+ cpumask_or(node_recorded_ids_map[nid], node_recorded_ids_map[nid], tmp);
+
+ /*
+ * If we force reusing the id, remove these ids from any node which was
+ * previously using it.
+ */
+ if (force_reusing) {
+ cpu = cpumask_first(tmp);
+ pr_warn("Reusing free CPU ids %d-%d from another node\n",
+ cpu, cpu + nthreads - 1);
+
+ for_each_online_node(node) {
+ if (node == nid)
+ continue;
+ cpumask_andnot(node_recorded_ids_map[node],
+ node_recorded_ids_map[node], tmp);
+ }
+ }
+
for_each_cpu(cpu, tmp) {
BUG_ON(cpu_present(cpu));
set_cpu_present(cpu, true);
@@ -889,6 +947,7 @@ static struct notifier_block pseries_smp_nb = {
static int __init pseries_cpu_hotplug_init(void)
{
int qcss_tok;
+ unsigned int node;
#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
ppc_md.cpu_probe = dlpar_cpu_probe;
@@ -910,8 +969,18 @@ static int __init pseries_cpu_hotplug_init(void)
smp_ops->cpu_die = pseries_cpu_die;
/* Processors can be added/removed only on LPAR */
- if (firmware_has_feature(FW_FEATURE_LPAR))
+ if (firmware_has_feature(FW_FEATURE_LPAR)) {
+ for_each_node(node) {
+ alloc_bootmem_cpumask_var(&node_recorded_ids_map[node]);
+
+ /* Record ids of CPU added at boot time */
+ cpumask_or(node_recorded_ids_map[node],
+ node_recorded_ids_map[node],
+ node_to_cpumask_map[node]);
+ }
+
of_reconfig_notifier_register(&pseries_smp_nb);
+ }
return 0;
}
--
2.31.0
^ permalink raw reply related
* Re: [PATCH v2 6/7] cmdline: Gives architectures opportunity to use generically defined boot cmdline manipulation
From: Christophe Leroy @ 2021-03-25 11:18 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, robh, daniel, devicetree, linux-kernel,
Paul Mackerras, linuxppc-dev, danielwa
In-Reply-To: <20210303175747.GD19713@willie-the-truck>
Le 03/03/2021 à 18:57, Will Deacon a écrit :
> On Tue, Mar 02, 2021 at 05:25:22PM +0000, Christophe Leroy wrote:
>> Most architectures have similar boot command line manipulation
>> options. This patchs adds the definition in init/Kconfig, gated by
>> CONFIG_HAVE_CMDLINE that the architectures can select to use them.
>>
>> In order to use this, a few architectures will have to change their
>> CONFIG options:
>> - riscv has to replace CMDLINE_FALLBACK by CMDLINE_FROM_BOOTLOADER
>> - architectures using CONFIG_CMDLINE_OVERRIDE or
>> CONFIG_CMDLINE_OVERWRITE have to replace them by CONFIG_CMDLINE_FORCE.
>>
>> Architectures also have to define CONFIG_DEFAULT_CMDLINE.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> ---
>> init/Kconfig | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 56 insertions(+)
>>
>> diff --git a/init/Kconfig b/init/Kconfig
>> index 22946fe5ded9..a0f2ad9467df 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -117,6 +117,62 @@ config INIT_ENV_ARG_LIMIT
>> Maximum of each of the number of arguments and environment
>> variables passed to init from the kernel command line.
>>
>> +config HAVE_CMDLINE
>> + bool
>> +
>> +config CMDLINE_BOOL
>> + bool "Default bootloader kernel arguments"
>> + depends on HAVE_CMDLINE
>> + help
>> + On some platforms, there is currently no way for the boot loader to
>> + pass arguments to the kernel. For these platforms, you can supply
>> + some command-line options at build time by entering them here. In
>> + most cases you will need to specify the root device here.
>
> Why is this needed as well as CMDLINE_FROM_BOOTLOADER? IIUC, the latter
> will use CONFIG_CMDLINE if it fails to get anything from the bootloader,
> which sounds like the same scenario.
>
>> +config CMDLINE
>> + string "Initial kernel command string"
>
> s/Initial/Default
>
> which is then consistent with the rest of the text here.
>
>> + depends on CMDLINE_BOOL
>
> Ah, so this is a bit different and I don't think lines-up with the
> CMDLINE_BOOL help text.
>
>> + default DEFAULT_CMDLINE
>> + help
>> + On some platforms, there is currently no way for the boot loader to
>> + pass arguments to the kernel. For these platforms, you can supply
>> + some command-line options at build time by entering them here. In
>> + most cases you will need to specify the root device here.
>
> (same stale text)
>
>> +choice
>> + prompt "Kernel command line type" if CMDLINE != ""
>> + default CMDLINE_FROM_BOOTLOADER
>> + help
>> + Selects the way you want to use the default kernel arguments.
>
> How about:
>
> "Determines how the default kernel arguments are combined with any
> arguments passed by the bootloader"
>
>> +config CMDLINE_FROM_BOOTLOADER
>> + bool "Use bootloader kernel arguments if available"
>> + help
>> + Uses the command-line options passed by the boot loader. If
>> + the boot loader doesn't provide any, the default kernel command
>> + string provided in CMDLINE will be used.
>> +
>> +config CMDLINE_EXTEND
>
> Can we rename this to CMDLINE_APPEND, please? There is code in the tree
> which disagrees about what CMDLINE_EXTEND means, so that will need be
> to be updated to be consistent (e.g. the EFI stub parsing order). Having
> the generic option with a different name means we won't accidentally end
> up with the same inconsistent behaviours.
Argh, yes. Seems like the problem is even larger than that IIUC:
- For ARM it means to append the bootloader arguments to the CONFIG_CMDLINE
- For Powerpc it means to append the CONFIG_CMDLINE to the bootloader arguments
- For SH it means to append the CONFIG_CMDLINE to the bootloader arguments
- For EFI it means to append the bootloader arguments to the CONFIG_CMDLINE
- For OF it means to append the CONFIG_CMDLINE to the bootloader arguments
So what happens on ARM for instance when it selects CONFIG_OF for instance ?
Or should we consider that EXTEND means APPEND or PREPEND, no matter which ?
Because EXTEND is for instance used for:
config INITRAMFS_FORCE
bool "Ignore the initramfs passed by the bootloader"
depends on CMDLINE_EXTEND || CMDLINE_FORCE
Christophe
^ permalink raw reply
* [PATCH AUTOSEL 5.11 22/44] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:24 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112459.1926846-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 7897d16e0990..727d4b321937 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -7,7 +7,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -46,7 +46,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.10 21/39] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:25 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112558.1927423-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 7897d16e0990..727d4b321937 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -7,7 +7,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -46,7 +46,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 15/24] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:26 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112651.1927828-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 7897d16e0990..727d4b321937 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -7,7 +7,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -46,7 +46,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 11/20] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:27 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112724.1928174-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 7897d16e0990..727d4b321937 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -7,7 +7,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -46,7 +46,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 09/16] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:27 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112751.1928421-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 7897d16e0990..727d4b321937 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -7,7 +7,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -46,7 +46,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 06/13] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:28 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112814.1928637-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 6e834caa3720..7b10b3ef7739 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -6,7 +6,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -45,7 +45,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH v3 2/2] powerpc/perf: Add platform specific check_attr_config
From: Madhavan Srinivasan @ 2021-03-25 11:53 UTC (permalink / raw)
To: mpe; +Cc: Madhavan Srinivasan, linuxppc-dev
In-Reply-To: <20210325115326.143151-1-maddy@linux.ibm.com>
Add platform specific attr.config value checks. Patch
includes checks for both power9 and power10.
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
---
Changelog v2:
- Changed function name as suggested.
- Added name of source document referred for reserved values
Changelog v1:
- No changes
arch/powerpc/perf/isa207-common.c | 42 +++++++++++++++++++++++++++++++
arch/powerpc/perf/isa207-common.h | 2 ++
arch/powerpc/perf/power10-pmu.c | 13 ++++++++++
arch/powerpc/perf/power9-pmu.c | 13 ++++++++++
4 files changed, 70 insertions(+)
diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index e4f577da33d8..358a0e95ba5f 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -694,3 +694,45 @@ int isa207_get_alternatives(u64 event, u64 alt[], int size, unsigned int flags,
return num_alt;
}
+
+int isa3XX_check_attr_config(struct perf_event *ev)
+{
+ u64 val, sample_mode;
+ u64 event = ev->attr.config;
+
+ val = (event >> EVENT_SAMPLE_SHIFT) & EVENT_SAMPLE_MASK;
+ sample_mode = val & 0x3;
+
+ /*
+ * MMCRA[61:62] is Random Sampling Mode (SM).
+ * value of 0b11 is reserved.
+ */
+ if (sample_mode == 0x3)
+ return -EINVAL;
+
+ /*
+ * Check for all reserved value
+ * Source: Performance Monitoring Unit User Guide
+ */
+ switch (val) {
+ case 0x5:
+ case 0x9:
+ case 0xD:
+ case 0x19:
+ case 0x1D:
+ case 0x1A:
+ case 0x1E:
+ return -EINVAL;
+ }
+
+ /*
+ * MMCRA[48:51]/[52:55]) Threshold Start/Stop
+ * Events Selection.
+ * 0b11110000/0b00001111 is reserved.
+ */
+ val = (event >> EVENT_THR_CTL_SHIFT) & EVENT_THR_CTL_MASK;
+ if (((val & 0xF0) == 0xF0) || ((val & 0xF) == 0xF))
+ return -EINVAL;
+
+ return 0;
+}
diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
index 1af0e8c97ac7..b4d2a2b2b346 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -280,4 +280,6 @@ void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
struct pt_regs *regs);
void isa207_get_mem_weight(u64 *weight);
+int isa3XX_check_attr_config(struct perf_event *ev);
+
#endif
diff --git a/arch/powerpc/perf/power10-pmu.c b/arch/powerpc/perf/power10-pmu.c
index a901c1348cad..f9d64c63bb4a 100644
--- a/arch/powerpc/perf/power10-pmu.c
+++ b/arch/powerpc/perf/power10-pmu.c
@@ -106,6 +106,18 @@ static int power10_get_alternatives(u64 event, unsigned int flags, u64 alt[])
return num_alt;
}
+static int power10_check_attr_config(struct perf_event *ev)
+{
+ u64 val;
+ u64 event = ev->attr.config;
+
+ val = (event >> EVENT_SAMPLE_SHIFT) & EVENT_SAMPLE_MASK;
+ if (val == 0x10 || isa3XX_check_attr_config(ev))
+ return -EINVAL;
+
+ return 0;
+}
+
GENERIC_EVENT_ATTR(cpu-cycles, PM_RUN_CYC);
GENERIC_EVENT_ATTR(instructions, PM_RUN_INST_CMPL);
GENERIC_EVENT_ATTR(branch-instructions, PM_BR_CMPL);
@@ -559,6 +571,7 @@ static struct power_pmu power10_pmu = {
.attr_groups = power10_pmu_attr_groups,
.bhrb_nr = 32,
.capabilities = PERF_PMU_CAP_EXTENDED_REGS,
+ .check_attr_config = power10_check_attr_config,
};
int init_power10_pmu(void)
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 2a57e93a79dc..ff3382140d7e 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -151,6 +151,18 @@ static int power9_get_alternatives(u64 event, unsigned int flags, u64 alt[])
return num_alt;
}
+static int power9_check_attr_config(struct perf_event *ev)
+{
+ u64 val;
+ u64 event = ev->attr.config;
+
+ val = (event >> EVENT_SAMPLE_SHIFT) & EVENT_SAMPLE_MASK;
+ if (val == 0xC || isa3XX_check_attr_config(ev))
+ return -EINVAL;
+
+ return 0;
+}
+
GENERIC_EVENT_ATTR(cpu-cycles, PM_CYC);
GENERIC_EVENT_ATTR(stalled-cycles-frontend, PM_ICT_NOSLOT_CYC);
GENERIC_EVENT_ATTR(stalled-cycles-backend, PM_CMPLU_STALL);
@@ -437,6 +449,7 @@ static struct power_pmu power9_pmu = {
.attr_groups = power9_pmu_attr_groups,
.bhrb_nr = 32,
.capabilities = PERF_PMU_CAP_EXTENDED_REGS,
+ .check_attr_config = power9_check_attr_config,
};
int init_power9_pmu(void)
--
2.26.2
^ permalink raw reply related
* [PATCH v3 1/2] powerpc/perf: Infrastructure to support checking of attr.config*
From: Madhavan Srinivasan @ 2021-03-25 11:53 UTC (permalink / raw)
To: mpe; +Cc: Madhavan Srinivasan, linuxppc-dev
Introduce code to support the checking of attr.config* for
values which are reserved for a given platform.
Performance Monitoring Unit (PMU) configuration registers
have fields that are reserved and some specific values for
bit fields are reserved. For ex., MMCRA[61:62] is
Random Sampling Mode (SM) and value of 0b11 for this field
is reserved.
Writing non-zero or invalid values in these fields will
have unknown behaviours.
Patch adds a generic call-back function "check_attr_config"
in "struct power_pmu", to be called in event_init to
check for attr.config* values for a given platform.
"check_attr_config" is valid only for raw event type.
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
---
Changelog v2:
-Fixed commit message
Changelog v1:
-Fixed commit message and in-code comments
arch/powerpc/include/asm/perf_event_server.h | 6 ++++++
arch/powerpc/perf/core-book3s.c | 14 ++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index 00e7e671bb4b..dde97d7d9253 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -67,6 +67,12 @@ struct power_pmu {
* the pmu supports extended perf regs capability
*/
int capabilities;
+ /*
+ * Function to check event code for values which are
+ * reserved. Function takes struct perf_event as input,
+ * since event code could be spread in attr.config*
+ */
+ int (*check_attr_config)(struct perf_event *ev);
};
/*
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 6817331e22ff..c6eeb4fdc5fd 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1958,6 +1958,20 @@ static int power_pmu_event_init(struct perf_event *event)
if (ppmu->blacklist_ev && is_event_blacklisted(ev))
return -EINVAL;
+ /*
+ * PMU config registers have fields that are
+ * reserved and specific value to bit field as reserved.
+ * For ex., MMCRA[61:62] is Randome Sampling Mode (SM)
+ * and value of 0b11 to this field is reserved.
+ *
+ * This check is needed only for raw event type,
+ * since tools like fuzzer use raw event type to
+ * provide randomized event code values for test.
+ *
+ */
+ if (ppmu->check_attr_config &&
+ ppmu->check_attr_config(event))
+ return -EINVAL;
break;
default:
return -ENOENT;
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
From: Christophe Leroy @ 2021-03-25 12:03 UTC (permalink / raw)
To: Rob Herring
Cc: Daniel Gimpelevich, linuxppc-dev, X86 ML, open list:MIPS,
linux-kernel@vger.kernel.org, Paul Mackerras, xe-linux-external,
Andrew Morton, Will Deacon, Daniel Walker
In-Reply-To: <CAL_JsqKm76jRQYDcu3rGyUWKPLspoO=EZW_WFy=zAK+m_JYCTg@mail.gmail.com>
Le 24/03/2021 à 18:32, Rob Herring a écrit :
> On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 09/03/2021 à 22:29, Daniel Walker a écrit :
>>> On Tue, Mar 09, 2021 at 08:47:09AM +0100, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 09/03/2021 à 01:02, Daniel Walker a écrit :
>>>>> This is a scripted mass convert of the config files to use
>>>>> the new generic cmdline. There is a bit of a trim effect here.
>>>>> It would seems that some of the config haven't been trimmed in
>>>>> a while.
>>>>
>>>> If you do that in a separate patch, you loose bisectability.
>>>>
>>>> I think it would have been better to do things in a different way, more or less like I did in my series:
>>>> 1/ Provide GENERIC cmdline at the same functionnality level as what is
>>>> spread in the different architectures
>>>> 2/ Convert architectures to the generic with least churn.
>>>> 3/ Add new features to the generic
>>>
>>> You have to have the churn eventually, no matter how you do it. The only way you
>>> don't have churn is if you never upgrade the feature set.
>>>
>>>
>>>>>
>>>>> The bash script used to convert is as follows,
>>>>>
>>>>> if [[ -z "$1" || -z "$2" ]]; then
>>>>> echo "Two arguments are needed."
>>>>> exit 1
>>>>> fi
>>>>> mkdir $1
>>>>> cp $2 $1/.config
>>>>> sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g' $1/.config
>>>>
>>>> This is not correct.
>>>>
>>>> By default, on powerpc the provided command line is used only if the bootloader doesn't provide one.
>>>>
>>>> Otherwise:
>>>> - the builtin command line is appended to the one provided by the bootloader
>>>> if CONFIG_CMDLINE_EXTEND is selected
>>>> - the builtin command line replaces to the one provided by the bootloader if
>>>> CONFIG_CMDLINE_FORCE is selected
>>>
>>> I think my changes maintain most of this due to the override of
>>> CONFIG_CMDLINE_PREPEND. This is an upgrade and the inflexibility in powerpc is
>>> an example of why these changes were created in the first place.
>>
>> "inflexibility in powerpc" : Can you elaborate ?
>>
>>>
>>> For example , say the default command line is "root=/dev/issblk0" from iss476
>>> platform. And the bootloader adds "root=/dev/sda1"
>>>
>>> The result is <prepend><bootloader><append>.
>>
>>
>> I'm still having hard time understanding the benefit of having both <prepend> and <append>.
>> Could you please provide a complete exemple from real life, ie what exactly the problem is and what
>> it solves ?
>
> It doesn't matter. We already have both cases and 'extend' has meant either one.
>
> What someone wants is policy and the kernel shouldn't be defining the policy.
>
Ok, so you agree we don't need to provide two CMDLINE, one to be appended and one to be prepended.
Let's only provide once CMDLINE as of today, and ask the user to select whether he wants it appended
or prepended or replacee. Then no need to change all existing config to rename CONFIG_CMDLINE into
either of the new ones.
That's the main difference between my series and Daniel's series. So I'll finish taking Will's
comment into account and we'll send out a v3 soon.
Thanks
Christophe
^ permalink raw reply
* Re: [PATCH v7] powerpc/irq: Inline call_do_irq() and call_do_softirq()
From: Segher Boessenkool @ 2021-03-25 12:44 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <87k0pwhh5y.fsf@mpe.ellerman.id.au>
On Wed, Mar 24, 2021 at 11:26:01PM +1100, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> > Hmm. It is the first time we use named parameters in powerpc assembly, isn't it ?
> Yeah I'd like us to use it more, I think it helps readability a lot.
..in some cases. Not in most cases :-(
> > Wondering, how would the below look like with named parameters (from __put_user_asm2_goto) ?
> >
> > stw%X1 %L0, %L1
>
> Not sure, possibly that's too complicated for it :)
asm("stw%X[name1] %L[name0],%L[name1]" :: [name0]"r"(x), [name1]"m"(p));
Yes, it is not more readable *at all*.
Segher
^ permalink raw reply
* Re: [PATCH V2 1/5] powerpc/perf: Expose processor pipeline stage cycles using PERF_SAMPLE_WEIGHT_STRUCT
From: Arnaldo Carvalho de Melo @ 2021-03-25 13:01 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: ravi.bangoria, Athira Rajeev, peterz, linux-kernel,
linux-perf-users, jolsa, kjain, linuxppc-dev, kan.liang
In-Reply-To: <d7dd633b-e28a-155a-a8e2-0e5a83b4eead@linux.ibm.com>
Em Wed, Mar 24, 2021 at 10:05:23AM +0530, Madhavan Srinivasan escreveu:
>
> On 3/22/21 8:27 PM, Athira Rajeev wrote:
> > Performance Monitoring Unit (PMU) registers in powerpc provides
> > information on cycles elapsed between different stages in the
> > pipeline. This can be used for application tuning. On ISA v3.1
> > platform, this information is exposed by sampling registers.
> > Patch adds kernel support to capture two of the cycle counters
> > as part of perf sample using the sample type:
> > PERF_SAMPLE_WEIGHT_STRUCT.
> >
> > The power PMU function 'get_mem_weight' currently uses 64 bit weight
> > field of perf_sample_data to capture memory latency. But following the
> > introduction of PERF_SAMPLE_WEIGHT_TYPE, weight field could contain
> > 64-bit or 32-bit value depending on the architexture support for
> > PERF_SAMPLE_WEIGHT_STRUCT. Patches uses WEIGHT_STRUCT to expose the
> > pipeline stage cycles info. Hence update the ppmu functions to work for
> > 64-bit and 32-bit weight values.
> >
> > If the sample type is PERF_SAMPLE_WEIGHT, use the 64-bit weight field.
> > if the sample type is PERF_SAMPLE_WEIGHT_STRUCT, memory subsystem
> > latency is stored in the low 32bits of perf_sample_weight structure.
> > Also for CPU_FTR_ARCH_31, capture the two cycle counter information in
> > two 16 bit fields of perf_sample_weight structure.
>
> Changes looks fine to me.
>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
So who will process the kernel bits? I'm merging the tooling parts,
Thanks,
- Arnaldo
>
> > Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/include/asm/perf_event_server.h | 2 +-
> > arch/powerpc/perf/core-book3s.c | 4 ++--
> > arch/powerpc/perf/isa207-common.c | 29 +++++++++++++++++++++++++---
> > arch/powerpc/perf/isa207-common.h | 6 +++++-
> > 4 files changed, 34 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
> > index 00e7e671bb4b..112cf092d7b3 100644
> > --- a/arch/powerpc/include/asm/perf_event_server.h
> > +++ b/arch/powerpc/include/asm/perf_event_server.h
> > @@ -43,7 +43,7 @@ struct power_pmu {
> > u64 alt[]);
> > void (*get_mem_data_src)(union perf_mem_data_src *dsrc,
> > u32 flags, struct pt_regs *regs);
> > - void (*get_mem_weight)(u64 *weight);
> > + void (*get_mem_weight)(u64 *weight, u64 type);
> > unsigned long group_constraint_mask;
> > unsigned long group_constraint_val;
> > u64 (*bhrb_filter_map)(u64 branch_sample_type);
> > diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> > index 766f064f00fb..6936763246bd 100644
> > --- a/arch/powerpc/perf/core-book3s.c
> > +++ b/arch/powerpc/perf/core-book3s.c
> > @@ -2206,9 +2206,9 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
> > ppmu->get_mem_data_src)
> > ppmu->get_mem_data_src(&data.data_src, ppmu->flags, regs);
> > - if (event->attr.sample_type & PERF_SAMPLE_WEIGHT &&
> > + if (event->attr.sample_type & PERF_SAMPLE_WEIGHT_TYPE &&
> > ppmu->get_mem_weight)
> > - ppmu->get_mem_weight(&data.weight.full);
> > + ppmu->get_mem_weight(&data.weight.full, event->attr.sample_type);
> > if (perf_event_overflow(event, &data, regs))
> > power_pmu_stop(event, 0);
> > diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
> > index e4f577da33d8..5dcbdbd54598 100644
> > --- a/arch/powerpc/perf/isa207-common.c
> > +++ b/arch/powerpc/perf/isa207-common.c
> > @@ -284,8 +284,10 @@ void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
> > }
> > }
> > -void isa207_get_mem_weight(u64 *weight)
> > +void isa207_get_mem_weight(u64 *weight, u64 type)
> > {
> > + union perf_sample_weight *weight_fields;
> > + u64 weight_lat;
> > u64 mmcra = mfspr(SPRN_MMCRA);
> > u64 exp = MMCRA_THR_CTR_EXP(mmcra);
> > u64 mantissa = MMCRA_THR_CTR_MANT(mmcra);
> > @@ -296,9 +298,30 @@ void isa207_get_mem_weight(u64 *weight)
> > mantissa = P10_MMCRA_THR_CTR_MANT(mmcra);
> > if (val == 0 || val == 7)
> > - *weight = 0;
> > + weight_lat = 0;
> > else
> > - *weight = mantissa << (2 * exp);
> > + weight_lat = mantissa << (2 * exp);
> > +
> > + /*
> > + * Use 64 bit weight field (full) if sample type is
> > + * WEIGHT.
> > + *
> > + * if sample type is WEIGHT_STRUCT:
> > + * - store memory latency in the lower 32 bits.
> > + * - For ISA v3.1, use remaining two 16 bit fields of
> > + * perf_sample_weight to store cycle counter values
> > + * from sier2.
> > + */
> > + weight_fields = (union perf_sample_weight *)weight;
> > + if (type & PERF_SAMPLE_WEIGHT)
> > + weight_fields->full = weight_lat;
> > + else {
> > + weight_fields->var1_dw = (u32)weight_lat;
> > + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> > + weight_fields->var2_w = P10_SIER2_FINISH_CYC(mfspr(SPRN_SIER2));
> > + weight_fields->var3_w = P10_SIER2_DISPATCH_CYC(mfspr(SPRN_SIER2));
> > + }
> > + }
> > }
> > int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp, u64 event_config1)
> > diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
> > index 1af0e8c97ac7..fc30d43c4d0c 100644
> > --- a/arch/powerpc/perf/isa207-common.h
> > +++ b/arch/powerpc/perf/isa207-common.h
> > @@ -265,6 +265,10 @@
> > #define ISA207_SIER_DATA_SRC_SHIFT 53
> > #define ISA207_SIER_DATA_SRC_MASK (0x7ull << ISA207_SIER_DATA_SRC_SHIFT)
> > +/* Bits in SIER2/SIER3 for Power10 */
> > +#define P10_SIER2_FINISH_CYC(sier2) (((sier2) >> (63 - 37)) & 0x7fful)
> > +#define P10_SIER2_DISPATCH_CYC(sier2) (((sier2) >> (63 - 13)) & 0x7fful)
> > +
> > #define P(a, b) PERF_MEM_S(a, b)
> > #define PH(a, b) (P(LVL, HIT) | P(a, b))
> > #define PM(a, b) (P(LVL, MISS) | P(a, b))
> > @@ -278,6 +282,6 @@ int isa207_get_alternatives(u64 event, u64 alt[], int size, unsigned int flags,
> > const unsigned int ev_alt[][MAX_ALT]);
> > void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
> > struct pt_regs *regs);
> > -void isa207_get_mem_weight(u64 *weight);
> > +void isa207_get_mem_weight(u64 *weight, u64 type);
> > #endif
--
- Arnaldo
^ 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