* [soc:arm/soc] BUILD SUCCESS d2353bad2c1eef7a1228645fbb21e7887c633d12
From: kbuild test robot @ 2020-06-03 5:21 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/soc
branch HEAD: d2353bad2c1eef7a1228645fbb21e7887c633d12 ARM: omap2: fix omap5_realtime_timer_init definition
elapsed time: 482m
configs tested: 99
configs skipped: 10
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm imx_v4_v5_defconfig
h8300 edosk2674_defconfig
parisc generic-64bit_defconfig
m68k amcore_defconfig
arm corgi_defconfig
sparc allyesconfig
mips bmips_stb_defconfig
arm realview_defconfig
alpha defconfig
arm moxart_defconfig
sh j2_defconfig
sparc64 allyesconfig
arm mps2_defconfig
powerpc alldefconfig
mips maltaup_defconfig
mips jmr3927_defconfig
s390 alldefconfig
c6x evmc6472_defconfig
sh rsk7203_defconfig
arm netwinder_defconfig
arm badge4_defconfig
mips decstation_64_defconfig
arc nsimosci_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allmodconfig
um allyesconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:arm/dt] BUILD SUCCESS 9ad249abe7b8f6f0d2d876bde860b1c511d71d7b
From: kbuild test robot @ 2020-06-03 5:21 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git arm/dt
branch HEAD: 9ad249abe7b8f6f0d2d876bde860b1c511d71d7b Merge tag 'zynqmp-dt-for-v5.8' of https://github.com/Xilinx/linux-xlnx into arm/dt
elapsed time: 482m
configs tested: 99
configs skipped: 10
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm imx_v4_v5_defconfig
h8300 edosk2674_defconfig
parisc generic-64bit_defconfig
m68k amcore_defconfig
arm corgi_defconfig
sparc allyesconfig
mips bmips_stb_defconfig
arm realview_defconfig
alpha defconfig
arm moxart_defconfig
sh j2_defconfig
sparc64 allyesconfig
arm mps2_defconfig
powerpc alldefconfig
mips maltaup_defconfig
mips jmr3927_defconfig
s390 alldefconfig
c6x evmc6472_defconfig
sh rsk7203_defconfig
arm netwinder_defconfig
arm badge4_defconfig
mips decstation_64_defconfig
arc nsimosci_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc rhel-kconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allmodconfig
um allyesconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] mailbox: imx: Add context save/restore for suspend/resume
From: Anson Huang @ 2020-06-03 5:15 UTC (permalink / raw)
To: jassisinghbrar, shawnguo, s.hauer, kernel, festevam, linux-kernel,
linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1591161344-12885-1-git-send-email-Anson.Huang@nxp.com>
From: Dong Aisheng <aisheng.dong@nxp.com>
For "mem" mode suspend on i.MX8 SoCs, MU settings could be
lost because its power is off, so save/restore is needed
for MU settings during suspend/resume. However, the restore
can ONLY be done when MU settings are actually lost, for the
scenario of settings NOT lost in "freeze" mode suspend, since
there could be still IPC going on multiple CPUs, restoring the
MU settings could overwrite the TIE by mistake and cause system
freeze, so need to make sure ONLY restore the MU settings when
it is powered off, Anson fixes this by checking whether restore
is actually needed when resume.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/mailbox/imx-mailbox.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index bd69ecf..da90a8e 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -67,6 +67,8 @@ struct imx_mu_priv {
struct clk *clk;
int irq;
+ u32 xcr;
+
bool side_b;
};
@@ -589,12 +591,45 @@ static const struct of_device_id imx_mu_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
+static int imx_mu_suspend_noirq(struct device *dev)
+{
+ struct imx_mu_priv *priv = dev_get_drvdata(dev);
+
+ priv->xcr = imx_mu_read(priv, priv->dcfg->xCR);
+
+ return 0;
+}
+
+static int imx_mu_resume_noirq(struct device *dev)
+{
+ struct imx_mu_priv *priv = dev_get_drvdata(dev);
+
+ /*
+ * ONLY restore MU when context lost, the TIE could
+ * be set during noirq resume as there is MU data
+ * communication going on, and restore the saved
+ * value will overwrite the TIE and cause MU data
+ * send failed, may lead to system freeze. This issue
+ * is observed by testing freeze mode suspend.
+ */
+ if (!imx_mu_read(priv, priv->dcfg->xCR))
+ imx_mu_write(priv, priv->xcr, priv->dcfg->xCR);
+
+ return 0;
+}
+
+static const struct dev_pm_ops imx_mu_pm_ops = {
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_mu_suspend_noirq,
+ imx_mu_resume_noirq)
+};
+
static struct platform_driver imx_mu_driver = {
.probe = imx_mu_probe,
.remove = imx_mu_remove,
.driver = {
.name = "imx_mu",
.of_match_table = imx_mu_dt_ids,
+ .pm = &imx_mu_pm_ops,
},
};
module_platform_driver(imx_mu_driver);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] Handle mailbox clock/power management related issues
From: Anson Huang @ 2020-06-03 5:15 UTC (permalink / raw)
To: jassisinghbrar, shawnguo, s.hauer, kernel, festevam, linux-kernel,
linux-arm-kernel
Cc: Linux-imx
Current i.MX mailbox driver mainly supports 2 series i.MX SoCs with
different architecture, one is for i.MX8X platforms with SCU inside,
the other is for i.MX6/7/8M series without SCU.
For i.MX8X, 2 types of MU are supported, one is for system IPC, such kind
of MU has no clock/power assignment, they are both controlled by SCU. The
other is for application, such kind of MU has no clock assignment, but have
power domain assignment, consumers need to call mailbox APIs to manage MU
power in runtime;
For i.MX6/7/8M, MU clock or power could be assigned based on different SoCs,
but all the MUs are for application, consumers need to call mailbox APIs to
manage MU clock/power in runtime.
For the power management related issue mentioned above, they are as below:
1. clock should be managed in runtime to make sure MU clock/power can be off
on i.MX6/7/8M platforms;
2. ONLY system IPC MU needs to have IRQF_NO_SUSPEND flag set, other application
MU no need to have this flag, since the MU clock/power is OFF in noirq
suspend phase and if MU interrupt arrives, with IRQF_NO_SUSPEND flag set,
the MU ISR will try to access MU register and lead to system hang because
of clock/power disabled;
To distinguish these different MU instances, use MU's clock/power assignment
status to decide whether to save/restore MU context during suspend/resume,
whether to have IRQF_NO_SUSPEND flag set, etc..
patch #1 is identical with https://patchwork.kernel.org/patch/11581215/, the
patch #2/#3 depend on #1, so I resend #1 in this series to make them as a whole
series.
Anson Huang (2):
mailbox: imx: Add runtime PM callback to handle MU clocks
mailbox: imx: ONLY IPC MU needs IRQF_NO_SUSPEND flag
Dong Aisheng (1):
mailbox: imx: Add context save/restore for suspend/resume
drivers/mailbox/imx-mailbox.c | 72 +++++++++++++++++++++++++++++++++++++++++--
1 file changed, 69 insertions(+), 3 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] mailbox: imx: ONLY IPC MU needs IRQF_NO_SUSPEND flag
From: Anson Huang @ 2020-06-03 5:15 UTC (permalink / raw)
To: jassisinghbrar, shawnguo, s.hauer, kernel, festevam, linux-kernel,
linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1591161344-12885-1-git-send-email-Anson.Huang@nxp.com>
IPC MU has no power domain assigned and there could be IPC during
noirq suspend phase, so IRQF_NO_SUSPEND flag is needed for IPC MU.
However, for other MUs, they have power domain assigned and their
power will be turned off during noirq suspend phase, but with
IRQF_NO_SUSPEND set, their interrupts are NOT disabled even after
their power turned off, it will cause system crash when mailbox
driver trys to handle pending interrupts but the MU power is already
turned off.
So, IRQF_NO_SUSPEND flag should ONLY be added to IPC MU which has
power domain managed by SCU, then all other MUs' pending interrupts
after noirq suspend phase will be handled after system resume.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/mailbox/imx-mailbox.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 080b608..7205b82 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -292,6 +292,7 @@ static int imx_mu_startup(struct mbox_chan *chan)
{
struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
struct imx_mu_con_priv *cp = chan->con_priv;
+ unsigned long irq_flag = IRQF_SHARED;
int ret;
pm_runtime_get_sync(priv->dev);
@@ -302,8 +303,12 @@ static int imx_mu_startup(struct mbox_chan *chan)
return 0;
}
- ret = request_irq(priv->irq, imx_mu_isr, IRQF_SHARED |
- IRQF_NO_SUSPEND, cp->irq_desc, chan);
+ /* IPC MU should be with IRQF_NO_SUSPEND set */
+ if (!priv->dev->pm_domain)
+ irq_flag |= IRQF_NO_SUSPEND;
+
+ ret = request_irq(priv->irq, imx_mu_isr, irq_flag,
+ cp->irq_desc, chan);
if (ret) {
dev_err(priv->dev,
"Unable to acquire IRQ %d\n", priv->irq);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] mailbox: imx: Add runtime PM callback to handle MU clocks
From: Anson Huang @ 2020-06-03 5:15 UTC (permalink / raw)
To: jassisinghbrar, shawnguo, s.hauer, kernel, festevam, linux-kernel,
linux-arm-kernel
Cc: Linux-imx
In-Reply-To: <1591161344-12885-1-git-send-email-Anson.Huang@nxp.com>
Some of i.MX8M SoCs have MU clock, they need to be managed in runtime
to make sure the MU clock can be off in runtime, add runtime PM callback
to handle MU clock.
And on i.MX8MP, the MU clock is combined with power domain and runtime
PM is enabled for the clock driver, during noirq suspend/resume phase,
runtime PM is disabled by device suspend, but the MU context save/restore
needs to enable MU clock for register access, calling clock prepare/enable
will trigger runtime resume failure and lead to system suspend failed.
Actually, the MU context save/restore is ONLY necessary for SCU IPC MU,
other MUs especially on i.MX8MP platforms which have MU clock assigned,
they need to runtime request/free mailbox channel in the consumer driver,
so no need to save/restore MU context for them, hence it can avoid this
issue, so the MU context save/restore is ONLY applied to i.MX platforms
MU instance without clock present.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/mailbox/imx-mailbox.c | 32 +++++++++++++++++++++++++++++---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index da90a8e..080b608 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -536,10 +536,13 @@ static int imx_mu_probe(struct platform_device *pdev)
if (ret < 0)
goto disable_runtime_pm;
+ clk_disable_unprepare(priv->clk);
+
return 0;
disable_runtime_pm:
pm_runtime_disable(dev);
+ clk_disable_unprepare(priv->clk);
return ret;
}
@@ -547,7 +550,6 @@ static int imx_mu_remove(struct platform_device *pdev)
{
struct imx_mu_priv *priv = platform_get_drvdata(pdev);
- clk_disable_unprepare(priv->clk);
pm_runtime_disable(priv->dev);
return 0;
@@ -595,7 +597,8 @@ static int imx_mu_suspend_noirq(struct device *dev)
{
struct imx_mu_priv *priv = dev_get_drvdata(dev);
- priv->xcr = imx_mu_read(priv, priv->dcfg->xCR);
+ if (!priv->clk)
+ priv->xcr = imx_mu_read(priv, priv->dcfg->xCR);
return 0;
}
@@ -612,15 +615,38 @@ static int imx_mu_resume_noirq(struct device *dev)
* send failed, may lead to system freeze. This issue
* is observed by testing freeze mode suspend.
*/
- if (!imx_mu_read(priv, priv->dcfg->xCR))
+ if (!imx_mu_read(priv, priv->dcfg->xCR) && !priv->clk)
imx_mu_write(priv, priv->xcr, priv->dcfg->xCR);
return 0;
}
+static int imx_mu_runtime_suspend(struct device *dev)
+{
+ struct imx_mu_priv *priv = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(priv->clk);
+
+ return 0;
+}
+
+static int imx_mu_runtime_resume(struct device *dev)
+{
+ struct imx_mu_priv *priv = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(priv->clk);
+ if (ret)
+ dev_err(dev, "failed to enable clock\n");
+
+ return ret;
+}
+
static const struct dev_pm_ops imx_mu_pm_ops = {
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_mu_suspend_noirq,
imx_mu_resume_noirq)
+ SET_RUNTIME_PM_OPS(imx_mu_runtime_suspend,
+ imx_mu_runtime_resume, NULL)
};
static struct platform_driver imx_mu_driver = {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] efi/libstub: refactor Makefile to not use lib-y syntax
From: Masahiro Yamada @ 2020-06-03 5:33 UTC (permalink / raw)
To: Ard Biesheuvel, linux-efi
Cc: Kees Cook, Catalin Marinas, Masahiro Yamada, linux-kernel,
Atish Patra, Arvind Sankar, Will Deacon, Ingo Molnar,
linux-arm-kernel
Documentation/kbuild/makefiles.rst says:
Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
I want to disallow lib-y outside of them.
Add a custom rule to build lib.a, which is linked to the decompressor
for ARCH=x86, ARCH=arm.
For ARCH=arm64, use obj-y to link objects to vmlinux in the ordinary
way.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
arch/arm64/Makefile | 1 -
drivers/firmware/efi/Makefile | 2 +-
drivers/firmware/efi/libstub/Makefile | 51 +++++++++++++++------------
3 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 650e1185c190..ab79b20efc8d 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -145,7 +145,6 @@ export TEXT_OFFSET
core-y += arch/arm64/
libs-y := arch/arm64/lib/ $(libs-y)
-core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
# Default target when executing plain make
boot := arch/arm64/boot
diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 7a216984552b..317a05cd388b 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
obj-$(CONFIG_UEFI_CPER) += cper.o
obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
-subdir-$(CONFIG_EFI_STUB) += libstub
+obj-$(CONFIG_EFI_STUB) += libstub/
obj-$(CONFIG_EFI_FAKE_MEMMAP) += fake_map.o
obj-$(CONFIG_EFI_BOOTLOADER_CONTROL) += efibc.o
obj-$(CONFIG_EFI_TEST) += test/
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index cce4a7436052..e4e9b17fa3b2 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -44,7 +44,7 @@ OBJECT_FILES_NON_STANDARD := y
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
KCOV_INSTRUMENT := n
-lib-y := efi-stub-helper.o gop.o secureboot.o tpm.o \
+stub-obj-y := efi-stub-helper.o gop.o secureboot.o tpm.o \
file.o mem.o random.o randomalloc.o pci.o \
skip_spaces.o lib-cmdline.o lib-ctype.o \
alignedmem.o relocate.o vsprintf.o
@@ -55,15 +55,19 @@ efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c
$(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
$(call if_changed_rule,cc_o_c)
-lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \
+stub-obj-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \
$(patsubst %.c,lib-%.o,$(efi-deps-y))
-lib-$(CONFIG_ARM) += arm32-stub.o
-lib-$(CONFIG_ARM64) += arm64-stub.o
-lib-$(CONFIG_X86) += x86-stub.o
+stub-obj-$(CONFIG_ARM) += arm32-stub.o
+stub-obj-$(CONFIG_ARM64) += arm64-stub.o
+stub-obj-$(CONFIG_X86) += x86-stub.o
CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
+targets += $(stub-obj-y)
+stub-obj-y := $(patsubst %.o,%.stub.o, $(stub-obj-y))
+targets += $(stub-obj-y)
+
#
# For x86, bootloaders like systemd-boot or grub-efi do not zero-initialize the
# .bss section, so the .bss section of the EFI stub needs to be included in the
@@ -83,23 +87,6 @@ STUBCOPY_FLAGS-$(CONFIG_ARM) += --rename-section .data=.data.efistub \
--rename-section .bss=.bss.efistub,load,alloc
STUBCOPY_RELOC-$(CONFIG_ARM) := R_ARM_ABS
-#
-# arm64 puts the stub in the kernel proper, which will unnecessarily retain all
-# code indefinitely unless it is annotated as __init/__initdata/__initconst etc.
-# So let's apply the __init annotations at the section level, by prefixing
-# the section names directly. This will ensure that even all the inline string
-# literals are covered.
-# The fact that the stub and the kernel proper are essentially the same binary
-# also means that we need to be extra careful to make sure that the stub does
-# not rely on any absolute symbol references, considering that the virtual
-# kernel mapping that the linker uses is not active yet when the stub is
-# executing. So build all C dependencies of the EFI stub into libstub, and do
-# a verification pass to see if any absolute relocations exist in any of the
-# object files.
-#
-extra-y := $(lib-y)
-lib-y := $(patsubst %.o,%.stub.o,$(lib-y))
-
STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
--prefix-symbols=__efistub_
STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
@@ -121,3 +108,23 @@ quiet_cmd_stubcopy = STUBCPY $@
/bin/false; \
fi; \
$(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@
+
+# arm64 puts the stub in the kernel proper, which will unnecessarily retain all
+# code indefinitely unless it is annotated as __init/__initdata/__initconst etc.
+# So let's apply the __init annotations at the section level, by prefixing
+# the section names directly. This will ensure that even all the inline string
+# literals are covered.
+# The fact that the stub and the kernel proper are essentially the same binary
+# also means that we need to be extra careful to make sure that the stub does
+# not rely on any absolute symbol references, considering that the virtual
+# kernel mapping that the linker uses is not active yet when the stub is
+# executing. So build all C dependencies of the EFI stub into libstub, and do
+# a verification pass to see if any absolute relocations exist in any of the
+# object files.
+#
+obj-$(CONFIG_ARM64) += $(stub-obj-y)
+extra-$(CONFIG_ARM) += lib.a
+extra-$(CONFIG_X86) += lib.a
+
+$(obj)/lib.a: $(addprefix $(obj)/, $(stub-obj-y)) FORCE
+ $(call if_changed,ar)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] Convert mxs/imx spi/cspi/lpspi binding to json-schema
From: Anson Huang @ 2020-06-03 6:13 UTC (permalink / raw)
To: broonie, robh+dt, shawnguo, s.hauer, kernel, festevam, marex,
linux-spi, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
This patch series converts mxs/imx spi/cspi/lpspi binding to json-schema.
In fsl-imx-cspi.yaml, also update compatible, remove obsolete properties
"fsl,spi-num-chipselects" and update the example based on latest DT file;
In spi-fsl-lpspi.yaml, the original maintainer's email address
pandy.gao@nxp.com is no longer valid, so I use mine.
Anson Huang (3):
dt-bindings: spi: Convert mxs spi to json-schema
dt-bindings: spi: Convert imx cspi to json-schema
dt-bindings: spi: Convert imx lpspi to json-schema
.../devicetree/bindings/spi/fsl-imx-cspi.txt | 56 -------------
.../devicetree/bindings/spi/fsl-imx-cspi.yaml | 97 ++++++++++++++++++++++
Documentation/devicetree/bindings/spi/mxs-spi.txt | 26 ------
Documentation/devicetree/bindings/spi/mxs-spi.yaml | 55 ++++++++++++
.../devicetree/bindings/spi/spi-fsl-lpspi.txt | 29 -------
.../devicetree/bindings/spi/spi-fsl-lpspi.yaml | 60 +++++++++++++
6 files changed, 212 insertions(+), 111 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/mxs-spi.txt
create mode 100644 Documentation/devicetree/bindings/spi/mxs-spi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] dt-bindings: spi: Convert mxs spi to json-schema
From: Anson Huang @ 2020-06-03 6:13 UTC (permalink / raw)
To: broonie, robh+dt, shawnguo, s.hauer, kernel, festevam, marex,
linux-spi, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591164809-13964-1-git-send-email-Anson.Huang@nxp.com>
Convert the MXS SPI binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Documentation/devicetree/bindings/spi/mxs-spi.txt | 26 ----------
Documentation/devicetree/bindings/spi/mxs-spi.yaml | 55 ++++++++++++++++++++++
2 files changed, 55 insertions(+), 26 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/mxs-spi.txt
create mode 100644 Documentation/devicetree/bindings/spi/mxs-spi.yaml
diff --git a/Documentation/devicetree/bindings/spi/mxs-spi.txt b/Documentation/devicetree/bindings/spi/mxs-spi.txt
deleted file mode 100644
index 3499b73..0000000
--- a/Documentation/devicetree/bindings/spi/mxs-spi.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-* Freescale MX233/MX28 SSP/SPI
-
-Required properties:
-- compatible: Should be "fsl,<soc>-spi", where soc is "imx23" or "imx28"
-- reg: Offset and length of the register set for the device
-- interrupts: Should contain SSP ERROR interrupt
-- dmas: DMA specifier, consisting of a phandle to DMA controller node
- and SSP DMA channel ID.
- Refer to dma.txt and fsl-mxs-dma.txt for details.
-- dma-names: Must be "rx-tx".
-
-Optional properties:
-- clock-frequency : Input clock frequency to the SPI block in Hz.
- Default is 160000000 Hz.
-
-Example:
-
-ssp0: ssp@80010000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,imx28-spi";
- reg = <0x80010000 0x2000>;
- interrupts = <96>;
- dmas = <&dma_apbh 0>;
- dma-names = "rx-tx";
-};
diff --git a/Documentation/devicetree/bindings/spi/mxs-spi.yaml b/Documentation/devicetree/bindings/spi/mxs-spi.yaml
new file mode 100644
index 0000000..ef99d12
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/mxs-spi.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/mxs-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MX233/MX28 SSP/SPI
+
+maintainers:
+ - Marek Vasut <marex@denx.de>
+
+allOf:
+ - $ref: "/schemas/spi/spi-controller.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx23-spi
+ - fsl,imx28-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+ clock-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: input clock frequency to the SPI block in Hz.
+ default: 160000000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ spi@80010000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx28-spi";
+ reg = <0x80010000 0x2000>;
+ interrupts = <96>;
+ dmas = <&dma_apbh 0>;
+ dma-names = "rx-tx";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: spi: Convert imx cspi to json-schema
From: Anson Huang @ 2020-06-03 6:13 UTC (permalink / raw)
To: broonie, robh+dt, shawnguo, s.hauer, kernel, festevam, marex,
linux-spi, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591164809-13964-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX CSPI binding to DT schema format using json-schema,
update compatible, remove obsolete properties "fsl,spi-num-chipselects"
and update the example based on latest DT file.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/spi/fsl-imx-cspi.txt | 56 -------------
.../devicetree/bindings/spi/fsl-imx-cspi.yaml | 97 ++++++++++++++++++++++
2 files changed, 97 insertions(+), 56 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
deleted file mode 100644
index 33bc58f..0000000
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-* Freescale (Enhanced) Configurable Serial Peripheral Interface
- (CSPI/eCSPI) for i.MX
-
-Required properties:
-- compatible :
- - "fsl,imx1-cspi" for SPI compatible with the one integrated on i.MX1
- - "fsl,imx21-cspi" for SPI compatible with the one integrated on i.MX21
- - "fsl,imx27-cspi" for SPI compatible with the one integrated on i.MX27
- - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31
- - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35
- - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51
- - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53 and later Soc
- - "fsl,imx8mq-ecspi" for SPI compatible with the one integrated on i.MX8MQ
- - "fsl,imx8mm-ecspi" for SPI compatible with the one integrated on i.MX8MM
- - "fsl,imx8mn-ecspi" for SPI compatible with the one integrated on i.MX8MN
- - "fsl,imx8mp-ecspi" for SPI compatible with the one integrated on i.MX8MP
-- reg : Offset and length of the register set for the device
-- interrupts : Should contain CSPI/eCSPI interrupt
-- clocks : Clock specifiers for both ipg and per clocks.
-- clock-names : Clock names should include both "ipg" and "per"
-See the clock consumer binding,
- Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Recommended properties:
-- cs-gpios : GPIOs to use as chip selects, see spi-bus.txt. While the native chip
-select lines can be used, they appear to always generate a pulse between each
-word of a transfer. Most use cases will require GPIO based chip selects to
-generate a valid transaction.
-
-Optional properties:
-- num-cs : Number of total chip selects, see spi-bus.txt.
-- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
-Documentation/devicetree/bindings/dma/dma.txt.
-- dma-names: DMA request names, if present, should include "tx" and "rx".
-- fsl,spi-rdy-drctl: Integer, representing the value of DRCTL, the register
-controlling the SPI_READY handling. Note that to enable the DRCTL consideration,
-the SPI_READY mode-flag needs to be set too.
-Valid values are: 0 (disabled), 1 (edge-triggered burst) and 2 (level-triggered burst).
-
-Obsolete properties:
-- fsl,spi-num-chipselects : Contains the number of the chipselect
-
-Example:
-
-ecspi@70010000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,imx51-ecspi";
- reg = <0x70010000 0x4000>;
- interrupts = <36>;
- cs-gpios = <&gpio3 24 0>, /* GPIO3_24 */
- <&gpio3 25 0>; /* GPIO3_25 */
- dmas = <&sdma 3 7 1>, <&sdma 4 7 2>;
- dma-names = "rx", "tx";
- fsl,spi-rdy-drctl = <1>;
-};
diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
new file mode 100644
index 0000000..cac023d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/fsl-imx-cspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale (Enhanced) Configurable Serial Peripheral Interface (CSPI/eCSPI) for i.MX
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+allOf:
+ - $ref: "/schemas/spi/spi-controller.yaml#"
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,imx1-cspi
+ - const: fsl,imx21-cspi
+ - const: fsl,imx27-cspi
+ - const: fsl,imx31-cspi
+ - const: fsl,imx35-cspi
+ - const: fsl,imx51-ecspi
+ - const: fsl,imx53-ecspi
+ - items:
+ - enum:
+ - fsl,imx50-ecspi
+ - fsl,imx6q-ecspi
+ - fsl,imx6sx-ecspi
+ - fsl,imx6sl-ecspi
+ - fsl,imx6sll-ecspi
+ - fsl,imx6ul-ecspi
+ - fsl,imx7d-ecspi
+ - fsl,imx8mq-ecspi
+ - fsl,imx8mm-ecspi
+ - fsl,imx8mn-ecspi
+ - fsl,imx8mp-ecspi
+ - const: fsl,imx51-ecspi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SoC SPI ipg clock
+ - description: SoC SPI per clock
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: ipg
+ - const: per
+ maxItems: 2
+
+ dmas:
+ items:
+ - description: DMA controller phandle and request line for RX
+ - description: DMA controller phandle and request line for TX
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ fsl,spi-rdy-drctl:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Integer, representing the value of DRCTL, the register controlling
+ the SPI_READY handling. Note that to enable the DRCTL consideration,
+ the SPI_READY mode-flag needs to be set too.
+ Valid values are: 0 (disabled), 1 (edge-triggered burst) and 2 (level-triggered burst).
+ enum: [0, 1, 2]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx5-clock.h>
+
+ spi@70010000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx51-ecspi";
+ reg = <0x70010000 0x4000>;
+ interrupts = <36>;
+ clocks = <&clks IMX5_CLK_ECSPI1_IPG_GATE>,
+ <&clks IMX5_CLK_ECSPI1_PER_GATE>;
+ clock-names = "ipg", "per";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: spi: Convert imx lpspi to json-schema
From: Anson Huang @ 2020-06-03 6:13 UTC (permalink / raw)
To: broonie, robh+dt, shawnguo, s.hauer, kernel, festevam, marex,
linux-spi, devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1591164809-13964-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX LPSPI binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/spi/spi-fsl-lpspi.txt | 29 -----------
.../devicetree/bindings/spi/spi-fsl-lpspi.yaml | 60 ++++++++++++++++++++++
2 files changed, 60 insertions(+), 29 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
deleted file mode 100644
index e71b81a..0000000
--- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Freescale Low Power SPI (LPSPI) for i.MX
-
-Required properties:
-- compatible :
- - "fsl,imx7ulp-spi" for LPSPI compatible with the one integrated on i.MX7ULP soc
- - "fsl,imx8qxp-spi" for LPSPI compatible with the one integrated on i.MX8QXP soc
-- reg : address and length of the lpspi master registers
-- interrupt-parent : core interrupt controller
-- interrupts : lpspi interrupt
-- clocks : lpspi clock specifier. Its number and order need to correspond to the
- value in clock-names.
-- clock-names : Corresponding to per clock and ipg clock in "clocks"
- respectively. In i.MX7ULP, it only has per clk, so use CLK_DUMMY
- to fill the "ipg" blank.
-- spi-slave : spi slave mode support. In slave mode, add this attribute without
- value. In master mode, remove it.
-
-Examples:
-
-lpspi2: lpspi@40290000 {
- compatible = "fsl,imx7ulp-spi";
- reg = <0x40290000 0x10000>;
- interrupt-parent = <&intc>;
- interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7ULP_CLK_LPSPI2>,
- <&clks IMX7ULP_CLK_DUMMY>;
- clock-names = "per", "ipg";
- spi-slave;
-};
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
new file mode 100644
index 0000000..d18e2b0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/spi-fsl-lpspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Low Power SPI (LPSPI) for i.MX
+
+maintainers:
+ - Anson Huang <Anson.Huang@nxp.com>
+
+allOf:
+ - $ref: "/schemas/spi/spi-controller.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx7ulp-spi
+ - fsl,imx8qxp-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: SoC SPI per clock
+ - description: SoC SPI ipg clock
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: per
+ - const: ipg
+ maxItems: 2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx7ulp-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ spi@40290000 {
+ compatible = "fsl,imx7ulp-spi";
+ reg = <0x40290000 0x10000>;
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7ULP_CLK_LPSPI2>,
+ <&clks IMX7ULP_CLK_DUMMY>;
+ clock-names = "per", "ipg";
+ spi-slave;
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] sound: usb: pcm: fix incorrect power state when playing sound after PM_AUTO suspend
From: Takashi Iwai @ 2020-06-03 6:28 UTC (permalink / raw)
To: Macpaul Lin
Cc: alsa-devel, Mediatek WSD Upstream, linux-kernel, linux-usb,
Johan Hovold, Takashi Iwai, Hui Wang, Alexander Tsoy,
linux-mediatek, Greg Kroah-Hartman, Matthias Brugger, Macpaul Lin,
Jaroslav Kysela, Szabolcs Szőke, linux-arm-kernel
In-Reply-To: <1591153515.23525.50.camel@mtkswgap22>
On Wed, 03 Jun 2020 05:05:15 +0200,
Macpaul Lin wrote:
>
> On Tue, 2020-06-02 at 14:46 +0200, Takashi Iwai wrote:
> > On Tue, 02 Jun 2020 13:53:41 +0200,
> > Macpaul Lin wrote:
> > >
> > > This patch fix incorrect power state changed by usb_audio_suspend()
> > > when CONFIG_PM is enabled.
> > >
> > > After receiving suspend PM message with auto flag, usb_audio_suspend()
> > > change card's power state to SNDRV_CTL_POWER_D3hot. Only when the other
> > > resume PM message with auto flag can change power state to
> > > SNDRV_CTL_POWER_D0 in __usb_audio_resume().
> > >
> > > However, when system is not under auto suspend, resume PM message with
> > > auto flag might not be able to receive on time which cause the power
> > > state was incorrect. At this time, if a player starts to play sound,
> > > will cause snd_usb_pcm_open() to access the card and setup_hw_info() will
> > > resume the card.
> > >
> > > But even the card is back to work and all function normal, the power
> > > state is still in SNDRV_CTL_POWER_D3hot.
> >
> > Hm, in exactly which situation does this happen? I still don't get
> > it. Could you elaborate how to trigger this?
>
> I'm not sure if this will happen on laptop or on PC.
> We've found this issue on Android phone (I'm not sure if each Android
> phone can reproduce this.).
>
> After booting the android phone, insert type-c headset without charging
> and play music at any duration, say, 1 second, then stop. Put phone away
> to idle about 17~18 minutes. Wait auto pm happened and the power state
> change to SNDRV_CTL_POWER_D3hot in sound/usb/card.c. Then wake up the
> phone, play music again. Then you'll probably found the music was not
> playing and the progress bar keep at the same position. It only happen
> when power state is SNDRV_CTL_POWER_D3hot. If not (the power state is
> SNDRV_CTL_POWER_D0), repeat the steps for several times, then it will be
> produced at some time.
>
> When it happened, sound_usb_pcm_open() will wake up the sound card by
> setup_hw_info()->__usb_audio_resume(). However, the card and the
> interface is function properly right now, the power state keeps remain
> SNDRV_CTL_POWER_D3hot.
And at this point it's already something wrong. We need to check why
SNDRV_CTL_POWER_D3hot is kept there, instead of working around the
rest behavior.
> The suggestive parameter settings from upper
> sound request will be pending since later snd_power_wait() call will
> still wait the card awaken. Ideally, auto PM should be recovered by
> sound card itself. But once the card is awaken at this circumstance, it
> looks like there are not more auto pm event. And the sound system of
> this interface will stuck here forever until user plug out the headset
> (reset the hardware).
>
> The root cause is that once the card has been resumed, it should inform
> auto pm change the state back into SNDRV_CTL_POWER_D0 and mark the
> device is using by some one.
>
> > > Which cause the infinite loop
> > > happened in snd_power_wait() to check the power state. Thus the
> > > successive setting ioctl cannot be passed to card.
> > >
> > > Hence we suggest to change power state to SNDRV_CTL_POWER_D0 when card
> > > has been resumed successfully.
> >
> > This doesn't look like a right solution for the problem, sorry.
> > The card PM status must be recovered to D0 when the autoresume
> > succeeds. If not, something is broken there, and it must be fixed
> > instead of fiddling the status flag externally.
>
> Yes, I agreed, but after checking the code in sound drivers,
> it looks like there is only chance that auto pm triggered by low-level
> code in sound/usb/card.c. In kernel 4.14, auto pm suspend is triggered
> by snd_pcm_suspend_all(). In later kernel, it is triggered by
> snd_usb_pcm_suspend(). However, it looks like there are no any resume
> trigger to recover auto pm state when the card has been waken by
> sound_usb_pcm_open().
If a running PCM stream has been suspended, the stream needs to be
resumed manually by user-space. There is no automatic resume. You
can forget about it and skip scratching that surface.
Again, the point to be checked is why D3hot is kept after
snd_usb_autoresume() is called.
It's Android, and I wonder whether the system does the system-suspend
(S3), or it's all runtime PM? Basically D3hot is set only for the
former, the system suspend, where the driver's PM callback is called
with PMSG_SUSPEND. Please check this at first. That is,
usb_audio_suspend() receives PMSG_SUSPEND or such, which makes
chip->autosuspended=1. The D3hot flag is set only in this condition.
Then, check the resume patterns. The usb-audio suspend/resume has
multiple refcounts. One is the Linux device PM refcount, and
chip->active refcount, and chip->num_suspended_intf refcount.
The first one (PM refount) is the primary refcount to manage the whole
system, and this is incremented / decremented by the standard PM
calls. The second one, chip->active, is a temporary flag to avoid the
re-entrance of the PM callbacks, and incremented at the probe enter
and __usb_audio_resume(), and decremented at the probe exit and
__usb_audio_resume() exist. The last one, chip->num_suspended_intf is
a refcount for the multiple interfaces assigned to a single card.
And, the most suspicious case is the last one,
chip->num_suspended-intf. It means that the device has multiple
USB interfaces and they went to suspend, while the resume isn't
performed for the all suspended interfaces in return.
If that's the case, you need to check where the suspend gets called to
which USB-interface (and which pm_message_t) and whether the resume
gets called for those.
thanks,
Takashi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] arm64/vdso: Add time namespace page
From: kbuild test robot @ 2020-06-03 6:42 UTC (permalink / raw)
To: Andrei Vagin, linux-arm-kernel, Catalin Marinas, Will Deacon
Cc: Mark Rutland, kbuild-all, Dmitry Safonov, linux-kernel,
Andrei Vagin, Thomas Gleixner, Vincenzo Frascino
In-Reply-To: <20200602180259.76361-4-avagin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
Hi Andrei,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on soc/for-next]
[also build test WARNING on arm/for-next xlnx/master kvmarm/next v5.7]
[cannot apply to arm64/for-next/core next-20200602]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Andrei-Vagin/arm64-add-the-time-namespace-support/20200603-020504
base: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
config: arm64-allnoconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> arch/arm64/kernel/vdso.c:93:19: warning: no previous prototype for 'arch_get_vdso_data' [-Wmissing-prototypes]
93 | struct vdso_data *arch_get_vdso_data(void *vvar_page)
| ^~~~~~~~~~~~~~~~~~
vim +/arch_get_vdso_data +93 arch/arm64/kernel/vdso.c
91
92
> 93 struct vdso_data *arch_get_vdso_data(void *vvar_page)
94 {
95 return (struct vdso_data *)(vvar_page);
96 }
97
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 8088 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] efi/libstub: refactor Makefile to not use lib-y syntax
From: Ard Biesheuvel @ 2020-06-03 6:44 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-efi, Kees Cook, Catalin Marinas, Linux Kernel Mailing List,
Atish Patra, Arvind Sankar, Will Deacon, Ingo Molnar, Linux ARM
In-Reply-To: <20200603053313.3863761-1-masahiroy@kernel.org>
On Wed, 3 Jun 2020 at 07:34, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> Documentation/kbuild/makefiles.rst says:
>
> Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.
>
> I want to disallow lib-y outside of them.
>
Why?
> Add a custom rule to build lib.a, which is linked to the decompressor
> for ARCH=x86, ARCH=arm.
>
> For ARCH=arm64, use obj-y to link objects to vmlinux in the ordinary
> way.
>
The code works perfectly fine as is, and I don't see what is
fundamentally wrong with using static libraries outside of lib/ and
arch/*/lib.
Also, I would like this code to still be incorporated as a static
library into arm64 as well, so that only pieces that are actually
needed are incorporated into the final image.
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
> arch/arm64/Makefile | 1 -
> drivers/firmware/efi/Makefile | 2 +-
> drivers/firmware/efi/libstub/Makefile | 51 +++++++++++++++------------
> 3 files changed, 30 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 650e1185c190..ab79b20efc8d 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -145,7 +145,6 @@ export TEXT_OFFSET
>
> core-y += arch/arm64/
> libs-y := arch/arm64/lib/ $(libs-y)
> -core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>
> # Default target when executing plain make
> boot := arch/arm64/boot
> diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
> index 7a216984552b..317a05cd388b 100644
> --- a/drivers/firmware/efi/Makefile
> +++ b/drivers/firmware/efi/Makefile
> @@ -20,7 +20,7 @@ obj-$(CONFIG_EFI_VARS_PSTORE) += efi-pstore.o
> obj-$(CONFIG_UEFI_CPER) += cper.o
> obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
> obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
> -subdir-$(CONFIG_EFI_STUB) += libstub
> +obj-$(CONFIG_EFI_STUB) += libstub/
> obj-$(CONFIG_EFI_FAKE_MEMMAP) += fake_map.o
> obj-$(CONFIG_EFI_BOOTLOADER_CONTROL) += efibc.o
> obj-$(CONFIG_EFI_TEST) += test/
> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
> index cce4a7436052..e4e9b17fa3b2 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -44,7 +44,7 @@ OBJECT_FILES_NON_STANDARD := y
> # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
> KCOV_INSTRUMENT := n
>
> -lib-y := efi-stub-helper.o gop.o secureboot.o tpm.o \
> +stub-obj-y := efi-stub-helper.o gop.o secureboot.o tpm.o \
> file.o mem.o random.o randomalloc.o pci.o \
> skip_spaces.o lib-cmdline.o lib-ctype.o \
> alignedmem.o relocate.o vsprintf.o
> @@ -55,15 +55,19 @@ efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c
> $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
> $(call if_changed_rule,cc_o_c)
>
> -lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \
> +stub-obj-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \
> $(patsubst %.c,lib-%.o,$(efi-deps-y))
>
> -lib-$(CONFIG_ARM) += arm32-stub.o
> -lib-$(CONFIG_ARM64) += arm64-stub.o
> -lib-$(CONFIG_X86) += x86-stub.o
> +stub-obj-$(CONFIG_ARM) += arm32-stub.o
> +stub-obj-$(CONFIG_ARM64) += arm64-stub.o
> +stub-obj-$(CONFIG_X86) += x86-stub.o
> CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
>
> +targets += $(stub-obj-y)
> +stub-obj-y := $(patsubst %.o,%.stub.o, $(stub-obj-y))
> +targets += $(stub-obj-y)
> +
> #
> # For x86, bootloaders like systemd-boot or grub-efi do not zero-initialize the
> # .bss section, so the .bss section of the EFI stub needs to be included in the
> @@ -83,23 +87,6 @@ STUBCOPY_FLAGS-$(CONFIG_ARM) += --rename-section .data=.data.efistub \
> --rename-section .bss=.bss.efistub,load,alloc
> STUBCOPY_RELOC-$(CONFIG_ARM) := R_ARM_ABS
>
> -#
> -# arm64 puts the stub in the kernel proper, which will unnecessarily retain all
> -# code indefinitely unless it is annotated as __init/__initdata/__initconst etc.
> -# So let's apply the __init annotations at the section level, by prefixing
> -# the section names directly. This will ensure that even all the inline string
> -# literals are covered.
> -# The fact that the stub and the kernel proper are essentially the same binary
> -# also means that we need to be extra careful to make sure that the stub does
> -# not rely on any absolute symbol references, considering that the virtual
> -# kernel mapping that the linker uses is not active yet when the stub is
> -# executing. So build all C dependencies of the EFI stub into libstub, and do
> -# a verification pass to see if any absolute relocations exist in any of the
> -# object files.
> -#
> -extra-y := $(lib-y)
> -lib-y := $(patsubst %.o,%.stub.o,$(lib-y))
> -
> STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
> --prefix-symbols=__efistub_
> STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
> @@ -121,3 +108,23 @@ quiet_cmd_stubcopy = STUBCPY $@
> /bin/false; \
> fi; \
> $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@
> +
> +# arm64 puts the stub in the kernel proper, which will unnecessarily retain all
> +# code indefinitely unless it is annotated as __init/__initdata/__initconst etc.
> +# So let's apply the __init annotations at the section level, by prefixing
> +# the section names directly. This will ensure that even all the inline string
> +# literals are covered.
> +# The fact that the stub and the kernel proper are essentially the same binary
> +# also means that we need to be extra careful to make sure that the stub does
> +# not rely on any absolute symbol references, considering that the virtual
> +# kernel mapping that the linker uses is not active yet when the stub is
> +# executing. So build all C dependencies of the EFI stub into libstub, and do
> +# a verification pass to see if any absolute relocations exist in any of the
> +# object files.
> +#
> +obj-$(CONFIG_ARM64) += $(stub-obj-y)
> +extra-$(CONFIG_ARM) += lib.a
> +extra-$(CONFIG_X86) += lib.a
> +
> +$(obj)/lib.a: $(addprefix $(obj)/, $(stub-obj-y)) FORCE
> + $(call if_changed,ar)
> --
> 2.25.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] sound: usb: pcm: fix incorrect power state when playing sound after PM_AUTO suspend
From: Takashi Iwai @ 2020-06-03 6:54 UTC (permalink / raw)
To: Macpaul Lin
Cc: alsa-devel, Mediatek WSD Upstream, linux-kernel, linux-usb,
Johan Hovold, Takashi Iwai, Hui Wang, Alexander Tsoy,
linux-mediatek, Greg Kroah-Hartman, Matthias Brugger, Macpaul Lin,
Jaroslav Kysela, Szabolcs Szőke, linux-arm-kernel
In-Reply-To: <s5heeqwfyti.wl-tiwai@suse.de>
On Wed, 03 Jun 2020 08:28:09 +0200,
Takashi Iwai wrote:
>
> And, the most suspicious case is the last one,
> chip->num_suspended-intf. It means that the device has multiple
> USB interfaces and they went to suspend, while the resume isn't
> performed for the all suspended interfaces in return.
If this is the cause, a patch like below might help.
It gets/puts the all assigned interfaced instead of only the primary
one.
Takashi
---
diff --git a/sound/usb/card.c b/sound/usb/card.c
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -634,7 +634,6 @@ static int usb_audio_probe(struct usb_interface *intf,
id, &chip);
if (err < 0)
goto __error;
- chip->pm_intf = intf;
break;
} else if (vid[i] != -1 || pid[i] != -1) {
dev_info(&dev->dev,
@@ -651,6 +650,13 @@ static int usb_audio_probe(struct usb_interface *intf,
goto __error;
}
}
+
+ if (chip->num_interfaces >= MAX_CARD_INTERFACES) {
+ dev_info(&dev->dev, "Too many interfaces assigned to the single USB-audio card\n");
+ err = -EINVAL;
+ goto __error;
+ }
+
dev_set_drvdata(&dev->dev, chip);
/*
@@ -703,6 +709,7 @@ static int usb_audio_probe(struct usb_interface *intf,
}
usb_chip[chip->index] = chip;
+ chip->intf[chip->num_interfaces] = intf;
chip->num_interfaces++;
usb_set_intfdata(intf, chip);
atomic_dec(&chip->active);
@@ -818,19 +825,36 @@ void snd_usb_unlock_shutdown(struct snd_usb_audio *chip)
int snd_usb_autoresume(struct snd_usb_audio *chip)
{
+ int i, err;
+
if (atomic_read(&chip->shutdown))
return -EIO;
- if (atomic_inc_return(&chip->active) == 1)
- return usb_autopm_get_interface(chip->pm_intf);
+ if (atomic_inc_return(&chip->active) != 1)
+ return 0;
+
+ for (i = 0; i < chip->num_interfaces; i++) {
+ err = usb_autopm_get_interface(chip->intf[i]);
+ if (err < 0) {
+ /* rollback */
+ while (--i >= 0)
+ usb_autopm_put_interface(chip->intf[i]);
+ return err;
+ }
+ }
return 0;
}
void snd_usb_autosuspend(struct snd_usb_audio *chip)
{
+ int i;
+
if (atomic_read(&chip->shutdown))
return;
- if (atomic_dec_and_test(&chip->active))
- usb_autopm_put_interface(chip->pm_intf);
+ if (!atomic_dec_and_test(&chip->active))
+ return;
+
+ for (i = 0; i < chip->num_interfaces; i++)
+ usb_autopm_put_interface(chip->intf[i]);
}
static int usb_audio_suspend(struct usb_interface *intf, pm_message_t message)
diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
--- a/sound/usb/usbaudio.h
+++ b/sound/usb/usbaudio.h
@@ -19,11 +19,13 @@
struct media_device;
struct media_intf_devnode;
+#define MAX_CARD_INTERFACES 16
+
struct snd_usb_audio {
int index;
struct usb_device *dev;
struct snd_card *card;
- struct usb_interface *pm_intf;
+ struct usb_interface *intf[MAX_CARD_INTERFACES];
u32 usb_id;
struct mutex mutex;
unsigned int autosuspended:1;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dma-direct: provide the ability to reserve per-numa CMA
From: kbuild test robot @ 2020-06-03 6:55 UTC (permalink / raw)
To: Barry Song, hch, m.szyprowski, robin.murphy, catalin.marinas
Cc: kbuild-all, john.garry, linux-kernel, linuxarm, iommu,
Jonathan.Cameron, linux-arm-kernel
In-Reply-To: <20200603024231.61748-2-song.bao.hua@hisilicon.com>
[-- Attachment #1: Type: text/plain, Size: 3177 bytes --]
Hi Barry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on linus/master v5.7]
[cannot apply to hch-configfs/for-next next-20200602]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Barry-Song/support-per-numa-CMA-for-ARM-server/20200603-104821
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: i386-randconfig-r033-20200602 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from include/linux/kernel.h:15,
from include/asm-generic/bug.h:19,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from include/linux/memblock.h:13,
from kernel/dma/contiguous.c:21:
kernel/dma/contiguous.c: In function 'dma_pernuma_cma_reserve':
>> include/linux/kern_levels.h:5:18: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'unsigned int' [-Wformat=]
5 | #define KERN_SOH "001" /* ASCII Start Of Header */
| ^~~~~~
include/linux/printk.h:137:10: note: in definition of macro 'no_printk'
137 | printk(fmt, ##__VA_ARGS__); | ^~~
include/linux/kern_levels.h:15:20: note: in expansion of macro 'KERN_SOH'
15 | #define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
| ^~~~~~~~
include/linux/printk.h:336:12: note: in expansion of macro 'KERN_DEBUG'
336 | no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~~~~
kernel/dma/contiguous.c:128:3: note: in expansion of macro 'pr_debug'
128 | pr_debug("%s: reserved %llu MiB on node %dn", __func__,
| ^~~~~~~~
kernel/dma/contiguous.c:128:29: note: format string is defined here
128 | pr_debug("%s: reserved %llu MiB on node %dn", __func__,
| ~~~^
| |
| long long unsigned int
| %u
vim +5 include/linux/kern_levels.h
314ba3520e513a Joe Perches 2012-07-30 4
04d2c8c83d0e3a Joe Perches 2012-07-30 @5 #define KERN_SOH "\001" /* ASCII Start Of Header */
04d2c8c83d0e3a Joe Perches 2012-07-30 6 #define KERN_SOH_ASCII '\001'
04d2c8c83d0e3a Joe Perches 2012-07-30 7
:::::: The code at line 5 was first introduced by commit
:::::: 04d2c8c83d0e3ac5f78aeede51babb3236200112 printk: convert the format for KERN_<LEVEL> to a 2 byte pattern
:::::: TO: Joe Perches <joe@perches.com>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33838 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dma-direct: provide the ability to reserve per-numa CMA
From: kbuild test robot @ 2020-06-03 7:18 UTC (permalink / raw)
To: Barry Song, hch, m.szyprowski, robin.murphy, catalin.marinas
Cc: kbuild-all, john.garry, linux-kernel, linuxarm, iommu,
Jonathan.Cameron, linux-arm-kernel
In-Reply-To: <20200603024231.61748-2-song.bao.hua@hisilicon.com>
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
Hi Barry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on linus/master v5.7]
[cannot apply to next-20200602]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Barry-Song/support-per-numa-CMA-for-ARM-server/20200603-104821
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: i386-randconfig-s002-20200602 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-244-g0ee050a8-dirty
# save the attached .config to linux build tree
make W=1 C=1 ARCH=i386 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> kernel/dma/contiguous.c:40:12: sparse: sparse: symbol 'dma_contiguous_pernuma_area' was not declared. Should it be static?
>> kernel/dma/contiguous.c:278:50: sparse: sparse: invalid access below 'dma_contiguous_pernuma_area' (-4 4)
Please review and possibly fold the followup patch.
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27963 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH] dma-direct: dma_contiguous_pernuma_area[] can be static
From: kbuild test robot @ 2020-06-03 7:18 UTC (permalink / raw)
To: Barry Song, hch, m.szyprowski, robin.murphy, catalin.marinas
Cc: kbuild-all, john.garry, linux-kernel, linuxarm, iommu,
Jonathan.Cameron, linux-arm-kernel
In-Reply-To: <20200603024231.61748-2-song.bao.hua@hisilicon.com>
Signed-off-by: kbuild test robot <lkp@intel.com>
---
contiguous.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 4b10d0ca0456d..2094c8e0590ac 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -37,7 +37,7 @@
#endif
struct cma *dma_contiguous_default_area;
-struct cma *dma_contiguous_pernuma_area[MAX_NUMNODES];
+static struct cma *dma_contiguous_pernuma_area[MAX_NUMNODES];
/*
* Default global CMA area size can be defined in kernel's .config.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 01/10] dmaengine: Actions: get rid of bit fields from dma descriptor
From: Manivannan Sadhasivam @ 2020-06-03 7:22 UTC (permalink / raw)
To: Amit Singh Tomar, andre.przywara, vkoul, afaerber
Cc: linux-actions, linux-kernel, cristian.ciocaltea, dmaengine,
dan.j.williams, linux-arm-kernel
In-Reply-To: <1591119192-18538-2-git-send-email-amittomer25@gmail.com>
On 2 June 2020 11:03:03 PM IST, Amit Singh Tomar <amittomer25@gmail.com> wrote:
>At the moment, Driver uses bit fields to describe registers of the DMA
>descriptor structure that makes it less portable and maintainable, and
>Andre suugested(and even sketched important bits for it) to make use of
>array to describe this DMA descriptors instead. It gives the
>flexibility
>while extending support for other platform such as Actions S700.
>
>This commit removes the "owl_dma_lli_hw" (that includes bit-fields) and
>uses array to describe DMA descriptor.
>
>Suggested-by: Andre Przywara <andre.przywara@arm.com>
>Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
>---
>Changes since v2:
> * No change.
>Changes since v1:
> * Defined macro for frame count value.
> * Introduced llc_hw_flen() from patch 2/9.
> * Removed the unnecessary line break.
>Changes since rfc:
> * No change.
>---
>drivers/dma/owl-dma.c | 84
>++++++++++++++++++++++++---------------------------
> 1 file changed, 40 insertions(+), 44 deletions(-)
>
>diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
>index c683051257fd..dd85c205454e 100644
>--- a/drivers/dma/owl-dma.c
>+++ b/drivers/dma/owl-dma.c
>@@ -120,30 +120,21 @@
> #define BIT_FIELD(val, width, shift, newshift) \
> ((((val) >> (shift)) & ((BIT(width)) - 1)) << (newshift))
>
>-/**
>- * struct owl_dma_lli_hw - Hardware link list for dma transfer
>- * @next_lli: physical address of the next link list
>- * @saddr: source physical address
>- * @daddr: destination physical address
>- * @flen: frame length
>- * @fcnt: frame count
>- * @src_stride: source stride
>- * @dst_stride: destination stride
>- * @ctrla: dma_mode and linklist ctrl config
>- * @ctrlb: interrupt config
>- * @const_num: data for constant fill
>- */
>-struct owl_dma_lli_hw {
>- u32 next_lli;
>- u32 saddr;
>- u32 daddr;
>- u32 flen:20;
>- u32 fcnt:12;
>- u32 src_stride;
>- u32 dst_stride;
>- u32 ctrla;
>- u32 ctrlb;
>- u32 const_num;
>+/* Frame count value is fixed as 1 */
>+#define FCNT_VAL 0x1
>+
>+/* Describe DMA descriptor, hardware link list for dma transfer */
Individual comments for these enums?
>+enum owl_dmadesc_offsets {
>+ OWL_DMADESC_NEXT_LLI = 0,
>+ OWL_DMADESC_SADDR,
>+ OWL_DMADESC_DADDR,
>+ OWL_DMADESC_FLEN,
>+ OWL_DMADESC_SRC_STRIDE,
>+ OWL_DMADESC_DST_STRIDE,
>+ OWL_DMADESC_CTRLA,
>+ OWL_DMADESC_CTRLB,
>+ OWL_DMADESC_CONST_NUM,
>+ OWL_DMADESC_SIZE
> };
>
> /**
>@@ -153,7 +144,7 @@ struct owl_dma_lli_hw {
> * @node: node for txd's lli_list
> */
> struct owl_dma_lli {
>- struct owl_dma_lli_hw hw;
>+ u32 hw[OWL_DMADESC_SIZE];
> dma_addr_t phys;
> struct list_head node;
> };
>@@ -320,6 +311,11 @@ static inline u32 llc_hw_ctrlb(u32 int_ctl)
> return ctl;
> }
>
>+static u32 llc_hw_flen(struct owl_dma_lli *lli)
>+{
>+ return lli->hw[OWL_DMADESC_FLEN] & GENMASK(19, 0);
>+}
>+
> static void owl_dma_free_lli(struct owl_dma *od,
> struct owl_dma_lli *lli)
> {
>@@ -351,8 +347,9 @@ static struct owl_dma_lli *owl_dma_add_lli(struct
>owl_dma_txd *txd,
> list_add_tail(&next->node, &txd->lli_list);
>
> if (prev) {
>- prev->hw.next_lli = next->phys;
>- prev->hw.ctrla |= llc_hw_ctrla(OWL_DMA_MODE_LME, 0);
>+ prev->hw[OWL_DMADESC_NEXT_LLI] = next->phys;
>+ prev->hw[OWL_DMADESC_CTRLA] |=
>+ llc_hw_ctrla(OWL_DMA_MODE_LME, 0);
> }
>
> return next;
>@@ -365,8 +362,7 @@ static inline int owl_dma_cfg_lli(struct
>owl_dma_vchan *vchan,
> struct dma_slave_config *sconfig,
> bool is_cyclic)
> {
>- struct owl_dma_lli_hw *hw = &lli->hw;
>- u32 mode;
>+ u32 mode, ctrlb;
>
> mode = OWL_DMA_MODE_PW(0);
>
>@@ -407,22 +403,22 @@ static inline int owl_dma_cfg_lli(struct
>owl_dma_vchan *vchan,
> return -EINVAL;
> }
>
>- hw->next_lli = 0; /* One link list by default */
>- hw->saddr = src;
>- hw->daddr = dst;
>-
>- hw->fcnt = 1; /* Frame count fixed as 1 */
>- hw->flen = len; /* Max frame length is 1MB */
>- hw->src_stride = 0;
>- hw->dst_stride = 0;
>- hw->ctrla = llc_hw_ctrla(mode,
>- OWL_DMA_LLC_SAV_LOAD_NEXT |
>- OWL_DMA_LLC_DAV_LOAD_NEXT);
>+ lli->hw[OWL_DMADESC_CTRLA] = llc_hw_ctrla(mode,
>+ OWL_DMA_LLC_SAV_LOAD_NEXT |
>+ OWL_DMA_LLC_DAV_LOAD_NEXT);
>
> if (is_cyclic)
>- hw->ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_BLOCK);
>+ ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_BLOCK);
> else
>- hw->ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_SUPER_BLOCK);
>+ ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_SUPER_BLOCK);
>+
>+ lli->hw[OWL_DMADESC_NEXT_LLI] = 0;
Again, please preserve the old comments.
>+ lli->hw[OWL_DMADESC_SADDR] = src;
>+ lli->hw[OWL_DMADESC_DADDR] = dst;
>+ lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
>+ lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
>+ lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
Please explain what you're doing here.
Thanks,
Mani
>+ lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
>
> return 0;
> }
>@@ -754,7 +750,7 @@ static u32 owl_dma_getbytes_chan(struct
>owl_dma_vchan *vchan)
> /* Start from the next active node */
> if (lli->phys == next_lli_phy) {
> list_for_each_entry(lli, &txd->lli_list, node)
>- bytes += lli->hw.flen;
>+ bytes += llc_hw_flen(lli);
> break;
> }
> }
>@@ -785,7 +781,7 @@ static enum dma_status owl_dma_tx_status(struct
>dma_chan *chan,
> if (vd) {
> txd = to_owl_txd(&vd->tx);
> list_for_each_entry(lli, &txd->lli_list, node)
>- bytes += lli->hw.flen;
>+ bytes += llc_hw_flen(lli);
> } else {
> bytes = owl_dma_getbytes_chan(vchan);
> }
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Security Random Number Generator support
From: Neal Liu @ 2020-06-03 7:29 UTC (permalink / raw)
To: Marc Zyngier, Julius Werner, Ard Biesheuvel
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman, Sean Wang,
linux-mediatek@lists.infradead.org, lkml, wsd_upstream,
Rob Herring, Neal Liu, Linux Crypto Mailing List, Matt Mackall,
Matthias Brugger, Crystal Guo (郭晶), Linux ARM
In-Reply-To: <85dfc0142d3879d50c0ba18bcc71e199@misterjones.org>
On Tue, 2020-06-02 at 21:02 +0800, Marc Zyngier wrote:
> On 2020-06-02 13:14, Ard Biesheuvel wrote:
> > On Tue, 2 Jun 2020 at 10:15, Neal Liu <neal.liu@mediatek.com> wrote:
> >>
> >> These patch series introduce a security random number generator
> >> which provides a generic interface to get hardware rnd from Secure
> >> state. The Secure state can be Arm Trusted Firmware(ATF), Trusted
> >> Execution Environment(TEE), or even EL2 hypervisor.
> >>
> >> Patch #1..2 adds sec-rng kernel driver for Trustzone based SoCs.
> >> For security awareness SoCs on ARMv8 with TrustZone enabled,
> >> peripherals like entropy sources is not accessible from normal world
> >> (linux) and rather accessible from secure world (HYP/ATF/TEE) only.
> >> This driver aims to provide a generic interface to Arm Trusted
> >> Firmware or Hypervisor rng service.
> >>
> >>
> >> changes since v1:
> >> - rename mt67xx-rng to mtk-sec-rng since all MediaTek ARMv8 SoCs can
> >> reuse
> >> this driver.
> >> - refine coding style and unnecessary check.
> >>
> >> changes since v2:
> >> - remove unused comments.
> >> - remove redundant variable.
> >>
> >> changes since v3:
> >> - add dt-bindings for MediaTek rng with TrustZone enabled.
> >> - revise HWRNG SMC call fid.
> >>
> >> changes since v4:
> >> - move bindings to the arm/firmware directory.
> >> - revise driver init flow to check more property.
> >>
> >> changes since v5:
> >> - refactor to more generic security rng driver which
> >> is not platform specific.
> >>
> >> *** BLURB HERE ***
> >>
> >> Neal Liu (2):
> >> dt-bindings: rng: add bindings for sec-rng
> >> hwrng: add sec-rng driver
> >>
> >
> > There is no reason to model a SMC call as a driver, and represent it
> > via a DT node like this.
>
> +1.
>
> > It would be much better if this SMC interface is made truly generic,
> > and wired into the arch_get_random() interface, which can be used much
> > earlier.
>
> Wasn't there a plan to standardize a SMC call to rule them all?
>
> M.
Could you give us a hint how to make this SMC interface more generic in
addition to my approach?
There is no (easy) way to get platform-independent SMC function ID,
which is why we encode it into device tree, and provide a generic
driver. In this way, different devices can be mapped and then get
different function ID internally.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] media: stm32-dcmi: Set minimum cpufreq requirement
From: Benjamin GAIGNARD @ 2020-06-03 7:34 UTC (permalink / raw)
To: Valentin Schneider
Cc: Alexandre TORGUE, rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
mcoquelin.stm32@gmail.com, Hugues FRUCHET, mchehab@kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <jhjo8q1io9o.mognet@arm.com>
On 6/2/20 3:35 PM, Valentin Schneider wrote:
> On 02/06/20 12:37, Benjamin GAIGNARD wrote:
>> On 6/2/20 11:31 AM, Valentin Schneider wrote:
>>>> @@ -99,6 +100,8 @@ enum state {
>>>>
>>>> #define OVERRUN_ERROR_THRESHOLD 3
>>>>
>>>> +#define DCMI_MIN_FREQ 650000 /* in KHz */
>>>> +
>>> This assumes the handling part is guaranteed to always run on the same CPU
>>> with the same performance profile (regardless of the platform). If that's
>>> not guaranteed, it feels like you'd want this to be configurable in some
>>> way.
>> Yes I could add a st,stm32-dcmi-min-frequency (in KHz) parameter the
>> device tree node.
>>
> Something like that - I'm not sure how well this fits with the DT
> landscape, as you could argue it isn't really a description of the
> hardware, more of a description of the performance expectations of the
> software. I won't really argue here.
>
>>>> struct dcmi_graph_entity {
>>>> struct v4l2_async_subdev asd;
>>>>
>>> [...]
>>>> @@ -2020,6 +2042,8 @@ static int dcmi_probe(struct platform_device *pdev)
>>>> goto err_cleanup;
>>>> }
>>>>
>>>> + dcmi->policy = cpufreq_cpu_get(0);
>>>> +
>>> Ideally you'd want to fetch the policy of the CPU your IRQ (and handling
>>> thread) is affined to; The only compatible DTS I found describes a single
>>> A7, which is somewhat limited in the affinity area...
>> If I move this code just before start streaming and use get_cpu(), would
>> it works ?
>>
> AFAIA streaming_start() is not necessarily executing on the same CPU as the
> one that will handle the interrupt. I was thinking you could use the IRQ's
> effective affinity as a hint of which CPU(s) to boost, i.e. something like:
>
> ---
> struct cpumask_var_t visited;
> struct irq_data *d = irq_get_irq_data(irq);
>
> err = alloc_cpumask_var(visited, GFP_KERNEL);
> /* ... */
> for_each_cpu(cpu, irq_data_get_effective_affinity_mask(d)) {
> /* check if not already spanned */
> if (cpumask_test_cpu(cpu, visited))
> continue;
>
> policy = cpufreq_cpu_get(cpu);
> cpumask_or(visited, visited, policy->cpus);
> /* do the boost for that policy here */
> /* ... */
> cpufreq_cpu_put(policy);
> }
> ---
>
> That of course falls apart when hotplug gets involved, and the effective
> affinity changes... There's irq_set_affinity_notifier() out there, but it
> seems it's only about the affinity, not the effective_affinity, I'm not
> sure how valid it would be to query the effective_affinity in that
> notifier.
If I wait to be in the irq it will be too late so I think I will do a
loop over all possible CPUs
before start the streaming to change the policies.
>
>> Benjamin
>>>> dev_info(&pdev->dev, "Probe done\n");
>>>>
>>>> platform_set_drvdata(pdev, dcmi);
>>>> @@ -2049,6 +2073,9 @@ static int dcmi_remove(struct platform_device *pdev)
>>>>
>>>> pm_runtime_disable(&pdev->dev);
>>>>
>>>> + if (dcmi->policy)
>>>> + cpufreq_cpu_put(dcmi->policy);
>>>> +
>>>> v4l2_async_notifier_unregister(&dcmi->notifier);
>>>> v4l2_async_notifier_cleanup(&dcmi->notifier);
>>>> media_entity_cleanup(&dcmi->vdev->entity);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 21/24] iommu/arm-smmu-v3: Add stall support for platform devices
From: Jean-Philippe Brucker @ 2020-06-03 7:38 UTC (permalink / raw)
To: Shameerali Kolothum Thodi
Cc: devicetree@vger.kernel.org, kevin.tian@intel.com, will@kernel.org,
fenghua.yu@intel.com, linux-pci@vger.kernel.org,
felix.kuehling@amd.com, hch@infradead.org, jgg@ziepe.ca,
iommu@lists.linux-foundation.org, linux-mm@kvack.org,
catalin.marinas@arm.com, zhangfei.gao@linaro.org,
robin.murphy@arm.com, christian.koenig@amd.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <c165fe41230f49baba991f1a416a4739@huawei.com>
On Tue, Jun 02, 2020 at 12:12:30PM +0000, Shameerali Kolothum Thodi wrote:
> > > > > > + if (ssid_valid)
> > > > > > + flt->prm.flags |=
> > > > IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
> > > > >
> > > > > Do we need to set this for STALL mode only support? I had an issue
> > > > > with this being set on a vSVA POC based on our D06 zip
> > > > > device(which is a "fake " pci dev that supports STALL mode but no
> > > > > PRI). The issue is, CMDQ_OP_RESUME doesn't have any ssid or SSV
> > > > > params and works on sid
> > > > and stag only.
> > > >
> > > > I don't understand the problem, arm_smmu_page_response() doesn't set
> > > > SSID or SSV when sending a CMDQ_OP_RESUME. Could you detail the flow
> > > > of a stall event and RESUME command in your prototype? Are you
> > > > getting issues with the host driver or the guest driver?
> > >
> > > The issue is on the host side iommu_page_response(). The flow is
> > > something like below.
> > >
> > > Stall: Host:-
> > >
> > > arm_smmu_handle_evt()
> > > iommu_report_device_fault()
> > > vfio_pci_iommu_dev_fault_handler()
> > >
> > > Stall: Qemu:-
> > >
> > > vfio_dma_fault_notifier_handler()
> > > inject_faults()
> > > smmuv3_inject_faults()
> > >
> > > Stall: Guest:-
> > >
> > > arm_smmu_handle_evt()
> > > iommu_report_device_fault()
> > > iommu_queue_iopf
> > > ...
> > > iopf_handle_group()
> > > iopf_handle_single()
> > > handle_mm_fault()
> > > iopf_complete()
> > > iommu_page_response()
> > > arm_smmu_page_response()
> > > arm_smmu_cmdq_issue_cmd(CMDQ_OP_RESUME)
> > >
> > > Resume: Qemu:-
> > >
> > > smmuv3_cmdq_consume(SMMU_CMD_RESUME)
> > > smmuv3_notify_page_resp()
> > > vfio:ioctl(page_response) --> struct iommu_page_response is filled
> > > with only version, grpid and code.
> > >
> > > Resume: Host:-
> > > ioctl(page_response)
> > > iommu_page_response() --> fails as the pending req has PASID_VALID
> > flag
> > > set and it checks for a match.
> >
> > I believe the fix needs to be here. It's also wrong for PRI since not all PCIe
> > endpoint require a PASID in the page response. Could you try the attached
> > patch?
>
> Going through the patch, yes, that will definitely fix the issue. But isn't it better if
> the request itself indicate whether it expects a response msg with a valid pasid or
> not? The response msg can come from userspace as well(vSVA) and if for some reason
> doesn't set it for a req that expects pasid then it should be an error, right? In the temp
> fix I had, I introduced another flag to indicate the endpoint has PRI support or not and
> used that to verify the pasid requirement. But for the PRI case you mentioned
> above, not sure it is easy to get that information or not. May be I am complicating things
> here :)
No you're right, we shouldn't send back malformed responses to the SMMU. I
suppose we can store a flag "PASID required" in the fault and check that
against the response. If we have to discard the guest's response, then we
can either fake a response (abort the stall) right away, or wait for the
response timeout to kick, which will do the same.
Thanks,
Jean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Security Random Number Generator support
From: Marc Zyngier @ 2020-06-03 7:40 UTC (permalink / raw)
To: Neal Liu
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Julius Werner, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman,
Sean Wang, lkml, wsd_upstream, Rob Herring, linux-mediatek,
Linux Crypto Mailing List, Matt Mackall, Matthias Brugger,
Crystal Guo (郭晶), Ard Biesheuvel, Linux ARM
In-Reply-To: <1591169342.4878.9.camel@mtkswgap22>
On 2020-06-03 08:29, Neal Liu wrote:
> On Tue, 2020-06-02 at 21:02 +0800, Marc Zyngier wrote:
>> On 2020-06-02 13:14, Ard Biesheuvel wrote:
>> > On Tue, 2 Jun 2020 at 10:15, Neal Liu <neal.liu@mediatek.com> wrote:
>> >>
>> >> These patch series introduce a security random number generator
>> >> which provides a generic interface to get hardware rnd from Secure
>> >> state. The Secure state can be Arm Trusted Firmware(ATF), Trusted
>> >> Execution Environment(TEE), or even EL2 hypervisor.
>> >>
>> >> Patch #1..2 adds sec-rng kernel driver for Trustzone based SoCs.
>> >> For security awareness SoCs on ARMv8 with TrustZone enabled,
>> >> peripherals like entropy sources is not accessible from normal world
>> >> (linux) and rather accessible from secure world (HYP/ATF/TEE) only.
>> >> This driver aims to provide a generic interface to Arm Trusted
>> >> Firmware or Hypervisor rng service.
>> >>
>> >>
>> >> changes since v1:
>> >> - rename mt67xx-rng to mtk-sec-rng since all MediaTek ARMv8 SoCs can
>> >> reuse
>> >> this driver.
>> >> - refine coding style and unnecessary check.
>> >>
>> >> changes since v2:
>> >> - remove unused comments.
>> >> - remove redundant variable.
>> >>
>> >> changes since v3:
>> >> - add dt-bindings for MediaTek rng with TrustZone enabled.
>> >> - revise HWRNG SMC call fid.
>> >>
>> >> changes since v4:
>> >> - move bindings to the arm/firmware directory.
>> >> - revise driver init flow to check more property.
>> >>
>> >> changes since v5:
>> >> - refactor to more generic security rng driver which
>> >> is not platform specific.
>> >>
>> >> *** BLURB HERE ***
>> >>
>> >> Neal Liu (2):
>> >> dt-bindings: rng: add bindings for sec-rng
>> >> hwrng: add sec-rng driver
>> >>
>> >
>> > There is no reason to model a SMC call as a driver, and represent it
>> > via a DT node like this.
>>
>> +1.
>>
>> > It would be much better if this SMC interface is made truly generic,
>> > and wired into the arch_get_random() interface, which can be used much
>> > earlier.
>>
>> Wasn't there a plan to standardize a SMC call to rule them all?
>>
>> M.
>
> Could you give us a hint how to make this SMC interface more generic in
> addition to my approach?
> There is no (easy) way to get platform-independent SMC function ID,
> which is why we encode it into device tree, and provide a generic
> driver. In this way, different devices can be mapped and then get
> different function ID internally.
The idea is simply to have *one* single ID that caters for all
implementations, just like we did for PSCI at the time. This
requires ARM to edict a standard, which is what I was referring
to above.
There is zero benefit in having a platform-dependent ID. It just
pointlessly increases complexity, and means we cannot use the RNG
before the firmware tables are available (yes, we need it that
early).
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 15/21] drm/rcar-du: Use GEM CMA object functions
From: Thomas Zimmermann @ 2020-06-03 7:48 UTC (permalink / raw)
To: kieran.bingham+renesas, Laurent Pinchart
Cc: alexandre.belloni, linux-aspeed, narmstrong, airlied, liviu.dudau,
dri-devel, paul, mihail.atanassov, sam, marex, khilman, abrodkin,
kong.kongxinwei, xinliang.liu, ludovic.desroches, tomi.valkeinen,
james.qian.wang, joel, linux-imx, alexandre.torgue, puck.chen,
s.hauer, alison.wang, jsarha, wens, vincent.abriou,
linux-arm-kernel, mcoquelin.stm32, bbrezillon, andrew,
philippe.cornu, yannick.fertre, kernel, zourongrong, shawnguo
In-Reply-To: <50d76988-f627-037d-a8bc-d18f6662c981@ideasonboard.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 4722 bytes --]
Hi
Am 25.05.20 um 17:38 schrieb Kieran Bingham:
> On 25/05/2020 13:49, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 22.05.20 um 22:12 schrieb Laurent Pinchart:
>>> Hi Thomas,
>>>
>>> Thank you for the patch.
>>>
>>> On Fri, May 22, 2020 at 03:52:40PM +0200, Thomas Zimmermann wrote:
>>>> The rcar-du driver uses the default implementation for CMA functions;
>>>> except for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro
>>>> now sets these defaults and .dumb_create in struct drm_driver. All
>>>> remaining operations are provided by CMA GEM object functions.
>>>>
>>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>>>> ---
>>>> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +----------
>>>> 1 file changed, 1 insertion(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>>>> index 3e67cf70f0402..3728038cec1d1 100644
>>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>>>> @@ -476,16 +476,7 @@ DEFINE_DRM_GEM_CMA_FOPS(rcar_du_fops);
>>>>
>>>> static struct drm_driver rcar_du_driver = {
>>>> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
>>>> - .gem_free_object_unlocked = drm_gem_cma_free_object,
>>>> - .gem_vm_ops = &drm_gem_cma_vm_ops,
>>>> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>>>> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>>>> - .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
>>>> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
>>>> - .gem_prime_vmap = drm_gem_cma_prime_vmap,
>>>> - .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
>>>> - .gem_prime_mmap = drm_gem_cma_prime_mmap,
>>>> - .dumb_create = rcar_du_dumb_create,
>>>> + __DRM_GEM_CMA_DRIVER_OPS(rcar_du_dumb_create),
>>>
>>> Your __DRM_GEM_CMA_DRIVER_OPS is defined as
>>>
>>> #define __DRM_GEM_CMA_DRIVER_OPS(__dumb_create) \
>>> .gem_create_object = drm_cma_gem_create_object_default_funcs, \
>>> .dumb_create = (__dumb_create), \
>>> .prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
>>> .prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
>>> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table_vmap, \
>>> .gem_prime_mmap = drm_gem_prime_mmap
>>>
>>> The patch thus introduces several changes:
>>>
>>> - drm_gem_cma_prime_import_sg_table_vmap() is used instead of
>>> drm_gem_cma_prime_import_sg_table() combined with .gem_prime_vmap()
>>> and .gem_prime_vunmap(). I believe that's fine, but splitting that
>>> change in a separate commit, or at the very least explaining it in
>>> details in the commit message, would make review easier.
>>>
>>> - .gem_create_object() is now set. That seems to be OK, but I'm not sure
>>> to grasp all the implications. This should also be explained in the
>>> commit message, and ideally split to a separate patch.
>>
>> That's relevant during object creation and sets the object functions.
>> See one of my other replies for how this can go away after all CMA
>> drivers have been updated to GEM object functions.
>>
>>
>>>
>>> - drm_gem_cma_prime_mmap() is replaced with drm_gem_prime_mmap(). Same
>>> comments :-)
>>
>> I relied on the aspeed driver to be correct. After Sam's comment on
>> that, I read the code once again several times. The original
>> implementation clears VM_PFNMAP. And I cannot find that code any longer.
>> Going back to the original function might be better.
>>
>>
>>>
>>> This patch hides way too many changes in what is documented as just
>>> innocent refactoring. It seems other drivers are affected too.
>>
>> Could you test the patchset? I don't have the HW.
>
> Digging out the branch you provided elsewhere in this thread:
>
>>>> Could you boot-test with the patchset applied?
>>>
>>> Yes, if you have a git branch I can just build and boot I can
>>> do it quickly!
>>
>> Fantastic! It's the cma-objfuncs branch of
>>
>> https://gitlab.freedesktop.org/tzimmermann/linux.git
>
> I have successfully run our display tests with your patches here on an
> R-Car H3 Salvator-XS(-es2).
>
> Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Thanks for testing.
>
>
>
>> Best regards
>> Thomas
>>
>>>
>>>> .fops = &rcar_du_fops,
>>>> .name = "rcar-du",
>>>> .desc = "Renesas R-Car Display Unit",
>>>
>>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] media: stm32-dcmi: Set minimum cpufreq requirement
From: Vincent Guittot @ 2020-06-03 7:50 UTC (permalink / raw)
To: Benjamin GAIGNARD
Cc: Alexandre TORGUE, rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
mcoquelin.stm32@gmail.com, Hugues FRUCHET, mchehab@kernel.org,
Valentin Schneider, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
In-Reply-To: <1b0ace18-e7f8-0b75-f6fe-968a269626b0@st.com>
On Wed, 3 Jun 2020 at 09:34, Benjamin GAIGNARD <benjamin.gaignard@st.com> wrote:
>
>
>
> On 6/2/20 3:35 PM, Valentin Schneider wrote:
> > On 02/06/20 12:37, Benjamin GAIGNARD wrote:
> >> On 6/2/20 11:31 AM, Valentin Schneider wrote:
> >>>> @@ -99,6 +100,8 @@ enum state {
> >>>>
> >>>> #define OVERRUN_ERROR_THRESHOLD 3
> >>>>
> >>>> +#define DCMI_MIN_FREQ 650000 /* in KHz */
> >>>> +
> >>> This assumes the handling part is guaranteed to always run on the same CPU
> >>> with the same performance profile (regardless of the platform). If that's
> >>> not guaranteed, it feels like you'd want this to be configurable in some
> >>> way.
> >> Yes I could add a st,stm32-dcmi-min-frequency (in KHz) parameter the
> >> device tree node.
> >>
> > Something like that - I'm not sure how well this fits with the DT
> > landscape, as you could argue it isn't really a description of the
> > hardware, more of a description of the performance expectations of the
> > software. I won't really argue here.
> >
> >>>> struct dcmi_graph_entity {
> >>>> struct v4l2_async_subdev asd;
> >>>>
> >>> [...]
> >>>> @@ -2020,6 +2042,8 @@ static int dcmi_probe(struct platform_device *pdev)
> >>>> goto err_cleanup;
> >>>> }
> >>>>
> >>>> + dcmi->policy = cpufreq_cpu_get(0);
> >>>> +
> >>> Ideally you'd want to fetch the policy of the CPU your IRQ (and handling
> >>> thread) is affined to; The only compatible DTS I found describes a single
> >>> A7, which is somewhat limited in the affinity area...
> >> If I move this code just before start streaming and use get_cpu(), would
> >> it works ?
> >>
> > AFAIA streaming_start() is not necessarily executing on the same CPU as the
> > one that will handle the interrupt. I was thinking you could use the IRQ's
> > effective affinity as a hint of which CPU(s) to boost, i.e. something like:
> >
> > ---
> > struct cpumask_var_t visited;
> > struct irq_data *d = irq_get_irq_data(irq);
> >
> > err = alloc_cpumask_var(visited, GFP_KERNEL);
> > /* ... */
> > for_each_cpu(cpu, irq_data_get_effective_affinity_mask(d)) {
> > /* check if not already spanned */
> > if (cpumask_test_cpu(cpu, visited))
> > continue;
> >
> > policy = cpufreq_cpu_get(cpu);
> > cpumask_or(visited, visited, policy->cpus);
> > /* do the boost for that policy here */
> > /* ... */
> > cpufreq_cpu_put(policy);
> > }
> > ---
> >
> > That of course falls apart when hotplug gets involved, and the effective
> > affinity changes... There's irq_set_affinity_notifier() out there, but it
> > seems it's only about the affinity, not the effective_affinity, I'm not
> > sure how valid it would be to query the effective_affinity in that
> > notifier.
> If I wait to be in the irq it will be too late so I think I will do a
> loop over all possible CPUs
> before start the streaming to change the policies.
Can't you use irq_get_affinity_mask and loop over it ?
Also You should better use freq_qos_add/remove_request during probe
and remove of the driver and use freq_qos_update_request in
dcmi_start/stop_streaming to set/unset your constraint.
>
> >
> >> Benjamin
> >>>> dev_info(&pdev->dev, "Probe done\n");
> >>>>
> >>>> platform_set_drvdata(pdev, dcmi);
> >>>> @@ -2049,6 +2073,9 @@ static int dcmi_remove(struct platform_device *pdev)
> >>>>
> >>>> pm_runtime_disable(&pdev->dev);
> >>>>
> >>>> + if (dcmi->policy)
> >>>> + cpufreq_cpu_put(dcmi->policy);
> >>>> +
> >>>> v4l2_async_notifier_unregister(&dcmi->notifier);
> >>>> v4l2_async_notifier_cleanup(&dcmi->notifier);
> >>>> media_entity_cleanup(&dcmi->vdev->entity);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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