* [PATCH 07/29] asm-generic: improve the flush_dcache_page stub
From: Christoph Hellwig @ 2020-05-15 14:36 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200515143646.3857579-1-hch@lst.de>
There is a magic ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE cpp symbol that
guards non-stub availability of flush_dcache_pagge. Use that to
check if flush_dcache_pagg is implemented.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/asm-generic/cacheflush.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index bf9bb83e9fc8d..bbbb4d4ef6516 100644
--- a/include/asm-generic/cacheflush.h
+++ b/include/asm-generic/cacheflush.h
@@ -2,8 +2,6 @@
#ifndef _ASM_GENERIC_CACHEFLUSH_H
#define _ASM_GENERIC_CACHEFLUSH_H
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-
/*
* The cache doesn't need to be flushed when TLB entries change when
* the cache is mapped to physical memory, not virtual memory
@@ -42,12 +40,14 @@ static inline void flush_cache_page(struct vm_area_struct *vma,
}
#endif
-#ifndef flush_dcache_page
+#ifndef ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
static inline void flush_dcache_page(struct page *page)
{
}
+#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
#endif
+
#ifndef flush_dcache_mmap_lock
static inline void flush_dcache_mmap_lock(struct address_space *mapping)
{
--
2.26.2
^ permalink raw reply related
* [PATCH 06/29] asm-generic: don't include <linux/mm.h> in cacheflush.h
From: Christoph Hellwig @ 2020-05-15 14:36 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200515143646.3857579-1-hch@lst.de>
This seems to lead to some crazy include loops when using
asm-generic/cacheflush.h on more architectures, so leave it
to the arch header for now.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/um/include/asm/tlb.h | 2 ++
arch/x86/include/asm/cacheflush.h | 2 ++
drivers/nvdimm/pmem.c | 3 ++-
include/asm-generic/cacheflush.h | 3 ---
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/um/include/asm/tlb.h b/arch/um/include/asm/tlb.h
index 70ee603839006..ff9c62828962c 100644
--- a/arch/um/include/asm/tlb.h
+++ b/arch/um/include/asm/tlb.h
@@ -2,6 +2,8 @@
#ifndef __UM_TLB_H
#define __UM_TLB_H
+#include <linux/mm.h>
+
#include <asm/tlbflush.h>
#include <asm-generic/cacheflush.h>
#include <asm-generic/tlb.h>
diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
index 63feaf2a5f93d..b192d917a6d0b 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -2,6 +2,8 @@
#ifndef _ASM_X86_CACHEFLUSH_H
#define _ASM_X86_CACHEFLUSH_H
+#include <linux/mm.h>
+
/* Caches aren't brain-dead on the intel. */
#include <asm-generic/cacheflush.h>
#include <asm/special_insns.h>
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 2df6994acf836..55282a6217407 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -7,7 +7,6 @@
* Copyright (c) 2015, Boaz Harrosh <boaz@plexistor.com>.
*/
-#include <asm/cacheflush.h>
#include <linux/blkdev.h>
#include <linux/hdreg.h>
#include <linux/init.h>
@@ -25,6 +24,8 @@
#include <linux/dax.h>
#include <linux/nd.h>
#include <linux/backing-dev.h>
+#include <linux/mm.h>
+#include <asm/cacheflush.h>
#include "pmem.h"
#include "pfn.h"
#include "nd.h"
diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index 906277492ec59..bf9bb83e9fc8d 100644
--- a/include/asm-generic/cacheflush.h
+++ b/include/asm-generic/cacheflush.h
@@ -2,9 +2,6 @@
#ifndef _ASM_GENERIC_CACHEFLUSH_H
#define _ASM_GENERIC_CACHEFLUSH_H
-/* Keep includes the same across arches. */
-#include <linux/mm.h>
-
#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
/*
--
2.26.2
^ permalink raw reply related
* [PATCH 05/29] asm-generic: fix the inclusion guards for cacheflush.h
From: Christoph Hellwig @ 2020-05-15 14:36 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200515143646.3857579-1-hch@lst.de>
cacheflush.h uses a somewhat to generic include guard name that clashes
with various arch files. Use a more specific one.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/asm-generic/cacheflush.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index cac7404b2bdd2..906277492ec59 100644
--- a/include/asm-generic/cacheflush.h
+++ b/include/asm-generic/cacheflush.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __ASM_CACHEFLUSH_H
-#define __ASM_CACHEFLUSH_H
+#ifndef _ASM_GENERIC_CACHEFLUSH_H
+#define _ASM_GENERIC_CACHEFLUSH_H
/* Keep includes the same across arches. */
#include <linux/mm.h>
@@ -109,4 +109,4 @@ static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
memcpy(dst, src, len)
#endif
-#endif /* __ASM_CACHEFLUSH_H */
+#endif /* _ASM_GENERIC_CACHEFLUSH_H */
--
2.26.2
^ permalink raw reply related
* [PATCH 04/29] unicore32: remove flush_cache_user_range
From: Christoph Hellwig @ 2020-05-15 14:36 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200515143646.3857579-1-hch@lst.de>
flush_cache_user_range is an ARMism not used by any generic or unicore32
specific code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/unicore32/include/asm/cacheflush.h | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/unicore32/include/asm/cacheflush.h b/arch/unicore32/include/asm/cacheflush.h
index dc8c0b41538f8..9393ca4047e93 100644
--- a/arch/unicore32/include/asm/cacheflush.h
+++ b/arch/unicore32/include/asm/cacheflush.h
@@ -132,14 +132,6 @@ extern void flush_cache_page(struct vm_area_struct *vma,
#define flush_cache_dup_mm(mm) flush_cache_mm(mm)
-/*
- * flush_cache_user_range is used when we want to ensure that the
- * Harvard caches are synchronised for the user space address range.
- * This is used for the UniCore private sys_cacheflush system call.
- */
-#define flush_cache_user_range(vma, start, end) \
- __cpuc_coherent_user_range((start) & PAGE_MASK, PAGE_ALIGN(end))
-
/*
* Perform necessary cache operations to ensure that data previously
* stored within this range of addresses can be executed by the CPU.
--
2.26.2
^ permalink raw reply related
* [PATCH 03/29] powerpc: unexport flush_icache_user_range
From: Christoph Hellwig @ 2020-05-15 14:36 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200515143646.3857579-1-hch@lst.de>
flush_icache_user_range is only used by copy_to_user_page, which is
only used by core VM code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/powerpc/mm/mem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 041ed7cfd341a..f0d1bf0a8e14f 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -587,7 +587,6 @@ void flush_icache_user_range(struct vm_area_struct *vma, struct page *page,
flush_icache_range(maddr, maddr + len);
kunmap(page);
}
-EXPORT_SYMBOL(flush_icache_user_range);
/*
* System memory should not be in /proc/iomem but various tools expect it
--
2.26.2
^ permalink raw reply related
* [PATCH 02/29] nds32: unexport flush_icache_page
From: Christoph Hellwig @ 2020-05-15 14:36 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200515143646.3857579-1-hch@lst.de>
flush_icache_page is only used by mm/memory.c.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/nds32/mm/cacheflush.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/nds32/mm/cacheflush.c b/arch/nds32/mm/cacheflush.c
index 254703653b6f5..8f168b33065fa 100644
--- a/arch/nds32/mm/cacheflush.c
+++ b/arch/nds32/mm/cacheflush.c
@@ -35,7 +35,6 @@ void flush_icache_page(struct vm_area_struct *vma, struct page *page)
kunmap_atomic((void *)kaddr);
local_irq_restore(flags);
}
-EXPORT_SYMBOL(flush_icache_page);
void flush_icache_user_range(struct vm_area_struct *vma, struct page *page,
unsigned long addr, int len)
--
2.26.2
^ permalink raw reply related
* sort out the flush_icache_range mess v2
From: Christoph Hellwig @ 2020-05-15 14:36 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
Hi all,
flush_icache_range is mostly used for kernel address, except for the following
cases:
- the nommu brk and mmap implementations,
- the read_code helper that is only used for binfmt_flat, binfmt_elf_fdpic,
and binfmt_aout including the broken ia32 compat version
- binfmt_flat itself,
none of which really are used by a typical MMU enabled kernel, as a.out can
only be build for alpha and m68k to start with.
But strangely enough commit ae92ef8a4424 ("PATCH] flush icache in correct
context") added a "set_fs(KERNEL_DS)" around the flush_icache_range call
in the module loader, because apparently m68k assumed user pointers.
This series first cleans up the cacheflush implementations, largely by
switching as much as possible to the asm-generic version after a few
preparations, then moves the misnamed current flush_icache_user_range to
a new name, to finally introduce a real flush_icache_user_range to be used
for the above use cases to flush the instruction cache for a userspace
address range. The last patch then drops the set_fs in the module code
and moves it into the m68k implementation.
A git tree is available here:
git://git.infradead.org/users/hch/misc.git flush_icache_range.2
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/flush_icache_range.2
Changes since v1:
- fix pmem.c compilation on some s390 configs
- drop two patches picked up by the arch maintainers
^ permalink raw reply
* [PATCH 01/29] arm: fix the flush_icache_range arguments in set_fiq_handler
From: Christoph Hellwig @ 2020-05-15 14:36 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200515143646.3857579-1-hch@lst.de>
The arguments passed look bogus, try to fix them to something that seems
to make sense.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/kernel/fiq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index cd1234c103fcd..98ca3e3fa8471 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -98,8 +98,8 @@ void set_fiq_handler(void *start, unsigned int length)
memcpy(base + offset, start, length);
if (!cache_is_vipt_nonaliasing())
- flush_icache_range((unsigned long)base + offset, offset +
- length);
+ flush_icache_range((unsigned long)base + offset,
+ (unsigned long)base + offset + length);
flush_icache_range(0xffff0000 + offset, 0xffff0000 + offset + length);
}
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v2 0/2] ASoC: fsl_esai: Add support for imx8qm
From: Mark Brown @ 2020-05-15 11:10 UTC (permalink / raw)
To: nicoleotsuka, robh+dt, lgirdwood, tiwai, alsa-devel, timur,
Xiubo.Lee, Shengjiu Wang, perex, festevam, devicetree
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1589537601.git.shengjiu.wang@nxp.com>
On Fri, 15 May 2020 18:10:49 +0800, Shengjiu Wang wrote:
> Add support for imx8qm.
>
> Shengjiu Wang (2):
> ASoC: fsl_esai: introduce SoC specific data
> ASoC: fsl_esai: Add new compatible string for imx8qm
>
> Changes in v2
> - drop the 0002 patch in v1, the dma relate limitation should
> be done in dma driver, or define a new DMA API for it.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.8
Thanks!
[1/2] ASoC: fsl_esai: introduce SoC specific data
commit: 6878e75204e1d0420fd8130bad33f88053ba44de
[2/2] ASoC: fsl_esai: Add new compatible string for imx8qm
commit: d59628b310a77e616ce2e5857e6ede5bf96c6784
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [PATCH v2 2/2] ASoC: fsl_esai: Add new compatible string for imx8qm
From: Shengjiu Wang @ 2020-05-15 10:10 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel, lgirdwood, robh+dt, devicetree
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1589537601.git.shengjiu.wang@nxp.com>
Add new compatible string "fsl,imx8qm-esai" in the binding document.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/sound/fsl,esai.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt
index 0e6e2166f76c..0a2480aeecf0 100644
--- a/Documentation/devicetree/bindings/sound/fsl,esai.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
@@ -12,6 +12,7 @@ Required properties:
"fsl,imx35-esai",
"fsl,vf610-esai",
"fsl,imx6ull-esai",
+ "fsl,imx8qm-esai",
- reg : Offset and length of the register set for the device.
--
2.21.0
^ permalink raw reply related
* [PATCH v2 0/2] ASoC: fsl_esai: Add support for imx8qm
From: Shengjiu Wang @ 2020-05-15 10:10 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel, lgirdwood, robh+dt, devicetree
Cc: linuxppc-dev, linux-kernel
Add support for imx8qm.
Shengjiu Wang (2):
ASoC: fsl_esai: introduce SoC specific data
ASoC: fsl_esai: Add new compatible string for imx8qm
Changes in v2
- drop the 0002 patch in v1, the dma relate limitation should
be done in dma driver, or define a new DMA API for it.
.../devicetree/bindings/sound/fsl,esai.txt | 1 +
sound/soc/fsl/fsl_esai.c | 46 +++++++++++++++----
2 files changed, 38 insertions(+), 9 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH v2 1/2] ASoC: fsl_esai: introduce SoC specific data
From: Shengjiu Wang @ 2020-05-15 10:10 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel, lgirdwood, robh+dt, devicetree
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1589537601.git.shengjiu.wang@nxp.com>
Introduce a SoC specific data structure which contains the
differences between the different SoCs.
This makes it easier to support more differences without having
to introduce a new if/else each time.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
sound/soc/fsl/fsl_esai.c | 46 ++++++++++++++++++++++++++++++++--------
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 84290be778f0..bac65ba7fbad 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -21,6 +21,17 @@
SNDRV_PCM_FMTBIT_S20_3LE | \
SNDRV_PCM_FMTBIT_S24_LE)
+/**
+ * fsl_esai_soc_data: soc specific data
+ *
+ * @imx: for imx platform
+ * @reset_at_xrun: flags for enable reset operaton
+ */
+struct fsl_esai_soc_data {
+ bool imx;
+ bool reset_at_xrun;
+};
+
/**
* fsl_esai: ESAI private data
*
@@ -33,6 +44,7 @@
* @fsysclk: system clock source to derive HCK, SCK and FS
* @spbaclk: SPBA clock (optional, depending on SoC design)
* @task: tasklet to handle the reset operation
+ * @soc: soc specific data
* @lock: spin lock between hw_reset() and trigger()
* @fifo_depth: depth of tx/rx FIFO
* @slot_width: width of each DAI slot
@@ -44,7 +56,6 @@
* @sck_div: if using PSR/PM dividers for SCKx clock
* @slave_mode: if fully using DAI slave mode
* @synchronous: if using tx/rx synchronous mode
- * @reset_at_xrun: flags for enable reset operaton
* @name: driver name
*/
struct fsl_esai {
@@ -57,6 +68,7 @@ struct fsl_esai {
struct clk *fsysclk;
struct clk *spbaclk;
struct tasklet_struct task;
+ const struct fsl_esai_soc_data *soc;
spinlock_t lock; /* Protect hw_reset and trigger */
u32 fifo_depth;
u32 slot_width;
@@ -70,10 +82,24 @@ struct fsl_esai {
bool sck_div[2];
bool slave_mode;
bool synchronous;
- bool reset_at_xrun;
char name[32];
};
+static struct fsl_esai_soc_data fsl_esai_vf610 = {
+ .imx = false,
+ .reset_at_xrun = true,
+};
+
+static struct fsl_esai_soc_data fsl_esai_imx35 = {
+ .imx = true,
+ .reset_at_xrun = true,
+};
+
+static struct fsl_esai_soc_data fsl_esai_imx6ull = {
+ .imx = true,
+ .reset_at_xrun = false,
+};
+
static irqreturn_t esai_isr(int irq, void *devid)
{
struct fsl_esai *esai_priv = (struct fsl_esai *)devid;
@@ -85,7 +111,7 @@ static irqreturn_t esai_isr(int irq, void *devid)
regmap_read(esai_priv->regmap, REG_ESAI_SAISR, &saisr);
if ((saisr & (ESAI_SAISR_TUE | ESAI_SAISR_ROE)) &&
- esai_priv->reset_at_xrun) {
+ esai_priv->soc->reset_at_xrun) {
dev_dbg(&pdev->dev, "reset module for xrun\n");
regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
ESAI_xCR_xEIE_MASK, 0);
@@ -936,9 +962,11 @@ static int fsl_esai_probe(struct platform_device *pdev)
esai_priv->pdev = pdev;
snprintf(esai_priv->name, sizeof(esai_priv->name), "%pOFn", np);
- if (of_device_is_compatible(np, "fsl,vf610-esai") ||
- of_device_is_compatible(np, "fsl,imx35-esai"))
- esai_priv->reset_at_xrun = true;
+ esai_priv->soc = of_device_get_match_data(&pdev->dev);
+ if (!esai_priv->soc) {
+ dev_err(&pdev->dev, "failed to get soc data\n");
+ return -ENODEV;
+ }
/* Get the addresses and IRQ */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1063,9 +1091,9 @@ static int fsl_esai_remove(struct platform_device *pdev)
}
static const struct of_device_id fsl_esai_dt_ids[] = {
- { .compatible = "fsl,imx35-esai", },
- { .compatible = "fsl,vf610-esai", },
- { .compatible = "fsl,imx6ull-esai", },
+ { .compatible = "fsl,imx35-esai", .data = &fsl_esai_imx35 },
+ { .compatible = "fsl,vf610-esai", .data = &fsl_esai_vf610 },
+ { .compatible = "fsl,imx6ull-esai", .data = &fsl_esai_imx6ull },
{}
};
MODULE_DEVICE_TABLE(of, fsl_esai_dt_ids);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 2/3] ASoC: fsl_esai: Add support for imx8qm
From: Shengjiu Wang @ 2020-05-15 10:01 UTC (permalink / raw)
To: Mark Brown
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux-ALSA, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Liam Girdwood, Takashi Iwai, Nicolin Chen, Rob Herring,
linuxppc-dev, linux-kernel
In-Reply-To: <20200512123801.GG5110@sirena.org.uk>
On Tue, May 12, 2020 at 8:38 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, May 12, 2020 at 10:48:41AM +0800, Shengjiu Wang wrote:
> > On Wed, May 6, 2020 at 10:33 AM Shengjiu Wang <shengjiu.wang@gmail.com> wrote:
> > > On Fri, May 1, 2020 at 6:23 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > > > EDMA requires the period size to be multiple of maxburst. Otherwise
> > > > > the remaining bytes are not transferred and thus noise is produced.
>
> > > > If this constraint comes from the DMA controller then normally you'd
> > > > expect the DMA controller integration to be enforcing this - is there no
> > > > information in the DMA API that lets us know that this constraint is
> > > > there?
>
> > > No, I can't find one API for this.
> > > Do you have a recommendation?
>
> > could you please recommend which DMA API can I use?
>
> Not off-hand, you'd probably need to extend the API to export the
> information.
Thanks. I will think about if I can find a better solution.
And I will drop this change and send v2 of this patch-set.
^ permalink raw reply
* Re: [PATCH v8 30/30] powerpc sstep: Add support for prefixed fixed-point arithmetic
From: Jordan Niethe @ 2020-05-15 8:02 UTC (permalink / raw)
To: linuxppc-dev
Cc: Christophe Leroy, Alistair Popple, Nicholas Piggin, Balamuruhan S,
naveen.n.rao, Daniel Axtens
In-Reply-To: <20200506034050.24806-31-jniethe5@gmail.com>
mpe, and this thanks.
---
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1343,7 +1343,7 @@ int analyse_instr(struct instruction_op *op,
const struct pt_regs *regs,
rd = (suffix >> 21) & 0x1f;
op->reg = rd;
op->val = regs->gpr[rd];
- suffixopcode = suffix >> 26;
+ suffixopcode = get_op(suffix);
prefixtype = (word >> 24) & 0x3;
switch (prefixtype) {
case 2:
--
2.17.1
^ permalink raw reply
* Re: [PATCH v8 29/30] powerpc sstep: Add support for prefixed load/stores
From: Jordan Niethe @ 2020-05-15 7:59 UTC (permalink / raw)
To: linuxppc-dev
Cc: Christophe Leroy, Alistair Popple, Nicholas Piggin, Balamuruhan S,
naveen.n.rao, Daniel Axtens
In-Reply-To: <20200506034050.24806-30-jniethe5@gmail.com>
mpe, and this thanks.
----
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1204,7 +1204,7 @@ int analyse_instr(struct instruction_op *op,
const struct pt_regs *regs,
struct ppc_inst instr)
{
unsigned int opcode, ra, rb, rc, rd, spr, u;
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64
unsigned int suffixopcode, prefixtype, prefix_r;
#endif
unsigned long int imm;
@@ -2701,7 +2701,7 @@ int analyse_instr(struct instruction_op *op,
const struct pt_regs *regs,
op->reg = rd;
op->val = regs->gpr[rd];
- suffixopcode = suffix >> 26;
+ suffixopcode = get_op(suffix);
prefixtype = (word >> 24) & 0x3;
switch (prefixtype) {
case 0: /* Type 00 Eight-Byte Load/Store */
--
2.17.1
^ permalink raw reply
* Re: [PATCH v8 25/30] powerpc: Test prefixed instructions in feature fixups
From: Jordan Niethe @ 2020-05-15 7:57 UTC (permalink / raw)
To: linuxppc-dev
Cc: Christophe Leroy, Alistair Popple, Nicholas Piggin, Balamuruhan S,
naveen.n.rao, Daniel Axtens
In-Reply-To: <20200506034050.24806-26-jniethe5@gmail.com>
Hey mpe, could you add this thanks.
diff --git a/arch/powerpc/lib/feature-fixups.c
b/arch/powerpc/lib/feature-fixups.c
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -689,7 +689,7 @@ static void test_lwsync_macros(void)
}
}
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64
static void __init test_prefix_patching(void)
{
extern unsigned int ftr_fixup_prefix1[];
@@ -755,7 +755,7 @@ static void __init test_prefix_word_alt_patching(void)
patch_feature_section(0, &fixup);
check(memcmp(ftr_fixup_prefix3, ftr_fixup_prefix3_orig, size) != 0);
}
-#endif /* __powerpc64__ */
+#endif /* CONFIG_PPC64 */
static int __init test_feature_fixups(void)
{
@@ -771,7 +771,7 @@ static int __init test_feature_fixups(void)
test_cpu_macros();
test_fw_macros();
test_lwsync_macros();
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64
test_prefix_patching();
test_prefix_alt_patching();
test_prefix_word_alt_patching();
--
^ permalink raw reply
* Re: [PATCH v8 24/30] powerpc: Test prefixed code patching
From: Jordan Niethe @ 2020-05-15 7:54 UTC (permalink / raw)
To: linuxppc-dev
Cc: Christophe Leroy, Alistair Popple, Nicholas Piggin, Balamuruhan S,
naveen.n.rao, Daniel Axtens
In-Reply-To: <20200506034050.24806-25-jniethe5@gmail.com>
Hey mpe could you add this please.
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -707,7 +707,7 @@ static void __init test_translate_branch(void)
vfree(buf);
}
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64
static void __init test_prefixed_patching(void)
{
extern unsigned int code_patching_test1[];
@@ -733,7 +733,7 @@ static int __init test_code_patching(void)
test_branch_bform();
test_create_function_call();
test_translate_branch();
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64
test_prefixed_patching();
#endif
--
2.17.1
^ permalink raw reply
* Re: [PATCH v8 23/30] powerpc: Add prefixed instructions to instruction data type
From: Jordan Niethe @ 2020-05-15 7:52 UTC (permalink / raw)
To: Michael Ellerman
Cc: Christophe Leroy, Alistair Popple, Nicholas Piggin, Balamuruhan S,
naveen.n.rao, linuxppc-dev, Daniel Axtens
In-Reply-To: <871rnmasnn.fsf@mpe.ellerman.id.au>
Hey mpe, fixes for the issues highlighted by Christophe, except KUAP
as discussed. Will make the optprobe change as a preceding patch.
diff --git a/arch/powerpc/include/asm/inst.h b/arch/powerpc/include/asm/inst.h
--- a/arch/powerpc/include/asm/inst.h
+++ b/arch/powerpc/include/asm/inst.h
@@ -11,9 +11,9 @@
struct ppc_inst {
u32 val;
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64
u32 suffix;
-#endif /* __powerpc64__ */
+#endif /* CONFIG_PPC64 */
} __packed;
static inline u32 ppc_inst_val(struct ppc_inst x)
@@ -26,7 +26,7 @@ static inline int ppc_inst_primary_opcode(struct ppc_inst x)
return get_op(ppc_inst_val(x));
}
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64
#define ppc_inst(x) ((struct ppc_inst){ .val = (x), .suffix = 0xff })
#define ppc_inst_prefix(x, y) ((struct ppc_inst){ .val = (x), .suffix = (y) })
@@ -52,7 +52,7 @@ static inline struct ppc_inst ppc_inst_read(const
struct ppc_inst *ptr)
u32 val, suffix;
val = *(u32 *)ptr;
- if ((val >> 26) == 1) {
+ if ((get_op(val)) == OP_PREFIX) {
suffix = *((u32 *)ptr + 1);
return ppc_inst_prefix(val, suffix);
} else {
@@ -94,7 +94,7 @@ static inline bool ppc_inst_equal(struct ppc_inst x,
struct ppc_inst y)
return ppc_inst_val(x) == ppc_inst_val(y);
}
-#endif /* __powerpc64__ */
+#endif /* CONFIG_PPC64 */
static inline int ppc_inst_len(struct ppc_inst x)
{
diff --git a/arch/powerpc/include/asm/uaccess.h
b/arch/powerpc/include/asm/uaccess.h
index e9027b3c641a..ac36a82321d4 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -105,7 +105,7 @@ static inline int __access_ok(unsigned long addr,
unsigned long size,
#define __put_user_inatomic(x, ptr) \
__put_user_nosleep((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64
#define __get_user_instr(x, ptr) \
({ \
long __gui_ret = 0; \
@@ -113,7 +113,7 @@ static inline int __access_ok(unsigned long addr,
unsigned long size,
struct ppc_inst __gui_inst; \
unsigned int prefix, suffix; \
__gui_ret = __get_user(prefix, (unsigned int __user *)__gui_ptr); \
- if (!__gui_ret && (prefix >> 26) == OP_PREFIX) { \
+ if (!__gui_ret && (get_op(prefix)) == OP_PREFIX) { \
__gui_ret = __get_user(suffix, \
(unsigned int __user *)__gui_ptr + 1); \
__gui_inst = ppc_inst_prefix(prefix, suffix); \
@@ -131,7 +131,7 @@ static inline int __access_ok(unsigned long addr,
unsigned long size,
struct ppc_inst __gui_inst; \
unsigned int prefix, suffix; \
__gui_ret = __get_user_inatomic(prefix, (unsigned int __user
*)__gui_ptr); \
- if (!__gui_ret && (prefix >> 26) == OP_PREFIX) { \
+ if (!__gui_ret && (get_op(prefix)) == OP_PREFIX) { \
__gui_ret = __get_user_inatomic(suffix, \
(unsigned int __user *)__gui_ptr + 1); \
__gui_inst = ppc_inst_prefix(prefix, suffix); \
diff --git a/arch/powerpc/kernel/optprobes.c b/arch/powerpc/kernel/optprobes.c
index a8e66603d12b..3ac105e7faae 100644
--- a/arch/powerpc/kernel/optprobes.c
+++ b/arch/powerpc/kernel/optprobes.c
@@ -283,10 +283,8 @@ int arch_prepare_optimized_kprobe(struct
optimized_kprobe *op, struct kprobe *p)
* 3. load instruction to be emulated into relevant register, and
*/
temp = ppc_inst_read((struct ppc_inst *)p->ainsn.insn);
- patch_imm64_load_insns(ppc_inst_val(temp) |
- ((u64)ppc_inst_suffix(temp) << 32),
- 4,
- buff + TMPL_INSN_IDX);
+ patch_imm64_load_insns(ppc_inst_val(temp) |
((u64)ppc_inst_suffix(temp) << 32),
+ 4, buff + TMPL_INSN_IDX);
/*
* 4. branch back from trampoline
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 58b67b62d5d3..bfd4e1dae0fb 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -26,8 +26,6 @@ static int __patch_instruction(struct ppc_inst
*exec_addr, struct ppc_inst instr
if (!ppc_inst_prefixed(instr)) {
__put_user_asm(ppc_inst_val(instr), patch_addr, err, "stw");
- if (err)
- return err;
} else {
#ifdef CONFIG_CPU_LITTLE_ENDIAN
__put_user_asm((u64)ppc_inst_suffix(instr) << 32 |
@@ -36,12 +34,13 @@ static int __patch_instruction(struct ppc_inst
*exec_addr, struct ppc_inst instr
__put_user_asm((u64)ppc_inst_val(instr) << 32 |
ppc_inst_suffix(instr), patch_addr, err, "std");
#endif /* CONFIG_CPU_LITTLE_ENDIAN */
- if (err)
- return err;
}
+ if (err)
+ return err;
asm ("dcbst 0, %0; sync; icbi 0,%1; sync; isync" :: "r" (patch_addr),
"r" (exec_addr));
+
return 0;
}
diff --git a/arch/powerpc/lib/inst.c b/arch/powerpc/lib/inst.c
index e5e589994097..3c3851ffdb36 100644
--- a/arch/powerpc/lib/inst.c
+++ b/arch/powerpc/lib/inst.c
@@ -7,7 +7,7 @@
#include <linux/uaccess.h>
#include <asm/inst.h>
-#ifdef __powerpc64__
+#ifdef CONFIG_PPC64
int probe_user_read_inst(struct ppc_inst *inst,
struct ppc_inst *nip)
{
@@ -17,9 +17,8 @@ int probe_user_read_inst(struct ppc_inst *inst,
err = probe_user_read(&val, nip, sizeof(val));
if (err)
return err;
- if ((val >> 26) == OP_PREFIX) {
- err = probe_user_read(&suffix, (void *)nip + 4,
- sizeof(unsigned int));
+ if (get_op(val) == OP_PREFIX) {
+ err = probe_user_read(&suffix, (void *)nip + 4, 4);
*inst = ppc_inst_prefix(val, suffix);
} else {
*inst = ppc_inst(val);
@@ -36,9 +35,8 @@ int probe_kernel_read_inst(struct ppc_inst *inst,
err = probe_kernel_read(&val, src, sizeof(val));
if (err)
return err;
- if ((val >> 26) == OP_PREFIX) {
- err = probe_kernel_read(&suffix, (void *)src + 4,
- sizeof(unsigned int));
+ if (get_op(val) == OP_PREFIX) {
+ err = probe_kernel_read(&suffix, (void *)src + 4, 4);
*inst = ppc_inst_prefix(val, suffix);
} else {
*inst = ppc_inst(val);
@@ -67,4 +65,4 @@ int probe_kernel_read_inst(struct ppc_inst *inst,
*inst = ppc_inst(val);
return err;
}
-#endif /* __powerpc64__ */
+#endif /* CONFIG_PPC64 */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v8 08/30] powerpc: Use a function for getting the instruction op code
From: Jordan Niethe @ 2020-05-15 7:48 UTC (permalink / raw)
To: linuxppc-dev
Cc: Christophe Leroy, Alistair Popple, Nicholas Piggin, Balamuruhan S,
naveen.n.rao, Daniel Axtens
In-Reply-To: <20200506034050.24806-9-jniethe5@gmail.com>
mpe, as suggested by Christophe could you please add this.
diff --git a/arch/powerpc/include/asm/inst.h b/arch/powerpc/include/asm/inst.h
--- a/arch/powerpc/include/asm/inst.h
+++ b/arch/powerpc/include/asm/inst.h
@@ -2,6 +2,8 @@
#ifndef _ASM_INST_H
#define _ASM_INST_H
+#include <asm/disassemble.h>
+
/*
* Instruction data type for POWER
*/
@@ -15,7 +17,7 @@ static inline u32 ppc_inst_val(u32 x)
static inline int ppc_inst_primary_opcode(u32 x)
{
- return ppc_inst_val(x) >> 26;
+ return get_op(ppc_inst_val(x));
}
#endif /* _ASM_INST_H */
--
2.17.1
^ permalink raw reply
* Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
From: Greg KH @ 2020-05-15 7:30 UTC (permalink / raw)
To: rananta; +Cc: linuxppc-dev, andrew, Jiri Slaby, linux-kernel
In-Reply-To: <0ab0b49f19b824ac1c4db4c4937ed388@codeaurora.org>
On Thu, May 14, 2020 at 04:22:10PM -0700, rananta@codeaurora.org wrote:
> On 2020-05-13 00:04, Greg KH wrote:
> > On Tue, May 12, 2020 at 02:39:50PM -0700, rananta@codeaurora.org wrote:
> > > On 2020-05-12 01:25, Greg KH wrote:
> > > > On Tue, May 12, 2020 at 09:22:15AM +0200, Jiri Slaby wrote:
> > > > > On 11. 05. 20, 9:39, Greg KH wrote:
> > > > > > On Mon, May 11, 2020 at 12:23:58AM -0700, rananta@codeaurora.org wrote:
> > > > > >> On 2020-05-09 23:48, Greg KH wrote:
> > > > > >>> On Sat, May 09, 2020 at 06:30:56PM -0700, rananta@codeaurora.org wrote:
> > > > > >>>> On 2020-05-06 02:48, Greg KH wrote:
> > > > > >>>>> On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta wrote:
> > > > > >>>>>> Potentially, hvc_open() can be called in parallel when two tasks calls
> > > > > >>>>>> open() on /dev/hvcX. In such a scenario, if the
> > > > > >>>>>> hp->ops->notifier_add()
> > > > > >>>>>> callback in the function fails, where it sets the tty->driver_data to
> > > > > >>>>>> NULL, the parallel hvc_open() can see this NULL and cause a memory
> > > > > >>>>>> abort.
> > > > > >>>>>> Hence, serialize hvc_open and check if tty->private_data is NULL
> > > > > >>>>>> before
> > > > > >>>>>> proceeding ahead.
> > > > > >>>>>>
> > > > > >>>>>> The issue can be easily reproduced by launching two tasks
> > > > > >>>>>> simultaneously
> > > > > >>>>>> that does nothing but open() and close() on /dev/hvcX.
> > > > > >>>>>> For example:
> > > > > >>>>>> $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
> > > > > >>>>>>
> > > > > >>>>>> Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
> > > > > >>>>>> ---
> > > > > >>>>>> drivers/tty/hvc/hvc_console.c | 16 ++++++++++++++--
> > > > > >>>>>> 1 file changed, 14 insertions(+), 2 deletions(-)
> > > > > >>>>>>
> > > > > >>>>>> diff --git a/drivers/tty/hvc/hvc_console.c
> > > > > >>>>>> b/drivers/tty/hvc/hvc_console.c
> > > > > >>>>>> index 436cc51c92c3..ebe26fe5ac09 100644
> > > > > >>>>>> --- a/drivers/tty/hvc/hvc_console.c
> > > > > >>>>>> +++ b/drivers/tty/hvc/hvc_console.c
> > > > > >>>>>> @@ -75,6 +75,8 @@ static LIST_HEAD(hvc_structs);
> > > > > >>>>>> */
> > > > > >>>>>> static DEFINE_MUTEX(hvc_structs_mutex);
> > > > > >>>>>>
> > > > > >>>>>> +/* Mutex to serialize hvc_open */
> > > > > >>>>>> +static DEFINE_MUTEX(hvc_open_mutex);
> > > > > >>>>>> /*
> > > > > >>>>>> * This value is used to assign a tty->index value to a hvc_struct
> > > > > >>>>>> based
> > > > > >>>>>> * upon order of exposure via hvc_probe(), when we can not match it
> > > > > >>>>>> to
> > > > > >>>>>> @@ -346,16 +348,24 @@ static int hvc_install(struct tty_driver
> > > > > >>>>>> *driver, struct tty_struct *tty)
> > > > > >>>>>> */
> > > > > >>>>>> static int hvc_open(struct tty_struct *tty, struct file * filp)
> > > > > >>>>>> {
> > > > > >>>>>> - struct hvc_struct *hp = tty->driver_data;
> > > > > >>>>>> + struct hvc_struct *hp;
> > > > > >>>>>> unsigned long flags;
> > > > > >>>>>> int rc = 0;
> > > > > >>>>>>
> > > > > >>>>>> + mutex_lock(&hvc_open_mutex);
> > > > > >>>>>> +
> > > > > >>>>>> + hp = tty->driver_data;
> > > > > >>>>>> + if (!hp) {
> > > > > >>>>>> + rc = -EIO;
> > > > > >>>>>> + goto out;
> > > > > >>>>>> + }
> > > > > >>>>>> +
> > > > > >>>>>> spin_lock_irqsave(&hp->port.lock, flags);
> > > > > >>>>>> /* Check and then increment for fast path open. */
> > > > > >>>>>> if (hp->port.count++ > 0) {
> > > > > >>>>>> spin_unlock_irqrestore(&hp->port.lock, flags);
> > > > > >>>>>> hvc_kick();
> > > > > >>>>>> - return 0;
> > > > > >>>>>> + goto out;
> > > > > >>>>>> } /* else count == 0 */
> > > > > >>>>>> spin_unlock_irqrestore(&hp->port.lock, flags);
> > > > > >>>>>
> > > > > >>>>> Wait, why isn't this driver just calling tty_port_open() instead of
> > > > > >>>>> trying to open-code all of this?
> > > > > >>>>>
> > > > > >>>>> Keeping a single mutext for open will not protect it from close, it will
> > > > > >>>>> just slow things down a bit. There should already be a tty lock held by
> > > > > >>>>> the tty core for open() to keep it from racing things, right?
> > > > > >>>> The tty lock should have been held, but not likely across
> > > > > >>>> ->install() and
> > > > > >>>> ->open() callbacks, thus resulting in a race between hvc_install() and
> > > > > >>>> hvc_open(),
> > > > > >>>
> > > > > >>> How? The tty lock is held in install, and should not conflict with
> > > > > >>> open(), otherwise, we would be seeing this happen in all tty drivers,
> > > > > >>> right?
> > > > > >>>
> > > > > >> Well, I was expecting the same, but IIRC, I see that the open() was being
> > > > > >> called in parallel for the same device node.
> > > > > >
> > > > > > So open and install are happening at the same time? And the tty_lock()
> > > > > > does not protect the needed fields from being protected properly? If
> > > > > > not, what fields are being touched without the lock?
> > > > > >
> > > > > >> Is it expected that the tty core would allow only one thread to
> > > > > >> access the dev-node, while blocking the other, or is it the client
> > > > > >> driver's responsibility to handle the exclusiveness?
> > > > > >
> > > > > > The tty core should handle this correctly, for things that can mess
> > > > > > stuff up (like install and open at the same time). A driver should not
> > > > > > have to worry about that.
> > > > > >
> > > > > >>>> where hvc_install() sets a data and the hvc_open() clears it.
> > > > > >>>> hvc_open()
> > > > > >>>> doesn't
> > > > > >>>> check if the data was set to NULL and proceeds.
> > > > > >>>
> > > > > >>> What data is being set that hvc_open is checking?
> > > > > >> hvc_install sets tty->private_data to hp, while hvc_open sets it to NULL (in
> > > > > >> one of the paths).
> > > > > >
> > > > > > I see no use of private_data in drivers/tty/hvc/ so what exactly are you
> > > > > > referring to?
> > > > >
> > > > > He likely means tty->driver_data. And there exactly lays the issue.
> > > > >
> > > > > commit bdb498c20040616e94b05c31a0ceb3e134b7e829
> > > > > Author: Jiri Slaby <jslaby@suse.cz>
> > > > > Date: Tue Aug 7 21:48:04 2012 +0200
> > > > >
> > > > > TTY: hvc_console, add tty install
> > > > >
> > > > > added hvc_install but did not move 'tty->driver_data = NULL;' from
> > > > > hvc_open's fail path to hvc_cleanup.
> > > > >
> > > > > IOW hvc_open now NULLs tty->driver_data even for another task which
> > > > > opened the tty earlier. The same holds for
> > > > > "tty_port_tty_set(&hp->port,
> > > > > NULL);" there. And actually "tty_port_put(&hp->port);" is also
> > > > > incorrect
> > > > > for the 2nd task opening the tty.
> > > > >
> > > > > So, a mutex with tty->driver_data check in open is not definitely the
> > > > > way to go. This mess needs to be sorted out properly. Sure, a good
> > > > > start
> > > > > would be a conversion to tty_port_open. Right after dropping "tty:
> > > > > hvc:
> > > > > Fix data abort due to race in hvc_open" from tty/tty-next :).
> > > >
> > > > I've now reverted this commit so we can start from a "clean" place.
> > > >
> > > > > What I *don't* understand is why hp->ops->notifier_add fails, given
> > > > > the
> > > > > open does not allow multiple opens anyway?
> > > >
> > > > I don't understand that either. Raghavendra, can you show a real trace
> > > > for this issue that shows this?
> > > >
> > > Let me know if this helps:
> > >
> > > [ 265.332900] Unable to handle kernel NULL pointer dereference at
> > > virtual
> > > address 00000000000000a8
> > > [ 265.332920] Mem abort info:
> > > [ 265.332934] ESR = 0x96000006
> > > [ 265.332950] EC = 0x25: DABT (current EL), IL = 32 bits
> > > [ 265.332963] SET = 0, FnV = 0
> > > [ 265.332975] EA = 0, S1PTW = 0
> > > [ 265.332985] Data abort info:
> > > [ 265.332997] ISV = 0, ISS = 0x00000006
> > > [ 265.333008] CM = 0, WnR = 0
> > > [ 265.333025] user pgtable: 4k pages, 39-bit VAs,
> > > pgdp=00000001620f3000
> > > [ 265.333038] [00000000000000a8] pgd=00000001620f2003,
> > > pud=00000001620f2003, pmd=0000000000000000
> > > [ 265.333071] Internal error: Oops: 96000006 [#1] PREEMPT SMP
> > > [ 265.333424] CPU: 1 PID: 5653 Comm: stress-ng-dev Tainted: G S
> > > W O
> > > 5.4.12-g04866e0 #1
> > > [ 265.333458] pstate: 80400085 (Nzcv daIf +PAN -UAO)
> > > [ 265.333499] pc : _raw_spin_lock_irqsave+0x40/0x7c
> > > [ 265.333517] lr : _raw_spin_lock_irqsave+0x38/0x7c
> > > [ 265.333530] sp : ffffffc02436ba40
> > > [ 265.333542] x29: ffffffc02436ba40 x28: 0000000000020800
> > > [ 265.333562] x27: ffffffdfb4046490 x26: ffffff8101b83400
> > > [ 265.333580] x25: ffffff80e163ad00 x24: ffffffdfb45c7798
> > > [ 265.333598] x23: ffffff8101b83668 x22: ffffffdfb4974000
> > > [ 265.333617] x21: 0000000000000001 x20: 00000000000000a8
> > > [ 265.333634] x19: 0000000000000000 x18: ffffff80e0b0d460
> > > [ 265.333652] x17: 0000000000000000 x16: 0000000001000000
> > > [ 265.333670] x15: 0000000001000000 x14: 00000000f8000000
> > > [ 265.333688] x13: 0000000000000000 x12: 0000000000000001
> > > [ 265.333706] x11: 17f5f16765f64600 x10: 17f5f16765f64600
> > > [ 265.333724] x9 : ffffffdfb3444244 x8 : 0000000000000000
> > > [ 265.333741] x7 : 0000000000000000 x6 : 0000000000000000
> > > [ 265.333759] x5 : 0000000000000000 x4 : 0000000000000002
> > > [ 265.333776] x3 : ffffffc02436b9c0 x2 : ffffffdfb40456e0
> > > [ 265.333794] x1 : ffffffc02436b9c0 x0 : ffffffdfb3444244
> > > [ 265.333812] Call trace:
> > > [ 265.333831] _raw_spin_lock_irqsave+0x40/0x7c
> > > [ 265.333859] 28$61deaf328f140fd7df47c115ec866fa5+0x28/0x174
> > > [ 265.333882] tty_open$86bd494905ebe22944bf63b711173de3+0x3d0/0x584
> > > [ 265.333921]
> > > chrdev_open$4083aaa799bca8e0e1e0c8dc1947aa96+0x1c4/0x248
> > > [ 265.333940] do_dentry_open+0x258/0x3b0
> > > [ 265.333956] vfs_open+0x2c/0x38
> > > [ 265.333975] path_openat+0x898/0xedc
> > > [ 265.333991] do_filp_open+0x78/0x124
> > > [ 265.334006] do_sys_open+0x13c/0x298
> > > [ 265.334022] __arm64_sys_openat+0x28/0x34
> > > [ 265.334044] el0_svc_common+0xb8/0x1b4
> > > [ 265.334059] el0_svc_handler+0x6c/0x88
> > > [ 265.334079] el0_svc+0x8/0xc
> > > [ 265.334110] Code: 52800035 97b9fec7 aa1f03e8 f9800291 (885ffe81)
> > > [ 265.334130] ---[ end trace ac90e3099a98e99f ]---
> > > [ 265.334146] Kernel panic - not syncing: Fatal exception
> >
> > Hm, do you have a strace showing the close happening at the same time?
> > What about install()?
>
> Yes, I do see the close happening, at which point the issue is not seen.
> It's only seen if the second task came in before this close was called. For
> this task, as the file was already opened, it doesn't go through
> hvc_install.
>
> (I figured adding some logs in the drivers would be helpful than straces to
> also include hvc_install)
>
> These are the traces you get when the issue happens:
> [ 154.212291] hvc_install called for pid: 666
> [ 154.216705] hvc_open called for pid: 666
> [ 154.233657] hvc_open: request_irq failed with rc -22.
> [ 154.238934] hvc_open called for pid: 678
> [ 154.243012] Unable to handle kernel NULL pointer dereference at virtual
> address 00000000000000c4
> # hvc_install isn't called for pid: 678 as the file wasn't closed yet.
>
> And these are the traces we get when things are normal:
> [ 76.318861] hvc_install called for pid: 537
> [ 76.323240] hvc_open called for pid: 537
> [ 76.340177] hvc_open: request_irq failed with rc -22.
> [ 76.345384] hvc_close called for pid: 537
> [ 76.349555] hvc_install called for pid: 538
> [ 76.353921] hvc_open called for pid: 538
> # hvc_open for the second task (pid: 538) seems to be fine here as the file
> was closed prior to the second task tried to open the file.
>
> >
> > And what line in hvc_open() does that offset correspond to?
> It's the point where it tries to acquire the spinlock for the first time:
> spin_lock_irqsave(&hp->port.lock, flags);
Ah, is this a console? Maybe this is the same issue that other console
drivers have been having recently, look at:
https://lore.kernel.org/r/20200428184050.6501-1-john.stultz@linaro.org
and
https://lore.kernel.org/r/1589019852-21505-2-git-send-email-sagar.kadam@sifive.com
Is that what you need here too?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 2/2] powerpc/rtas: Implement reentrant rtas call
From: Nicholas Piggin @ 2020-05-15 7:30 UTC (permalink / raw)
To: Allison Randal, Benjamin Herrenschmidt, Gautham R. Shenoy,
Greg Kroah-Hartman, Leonardo Bras, Michael Ellerman, Nadav Amit,
Nathan Lynch, Paul Mackerras, Thomas Gleixner
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200514235138.150722-3-leobras.c@gmail.com>
Excerpts from Leonardo Bras's message of May 15, 2020 9:51 am:
> Implement rtas_call_reentrant() for reentrant rtas-calls:
> "ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive".
>
> On LoPAPR Version 1.1 (March 24, 2016), from 7.3.10.1 to 7.3.10.4,
> items 2 and 3 say:
>
> 2 - For the PowerPC External Interrupt option: The * call must be
> reentrant to the number of processors on the platform.
> 3 - For the PowerPC External Interrupt option: The * argument call
> buffer for each simultaneous call must be physically unique.
>
> So, these rtas-calls can be called in a lockless way, if using
> a different buffer for each cpu doing such rtas call.
What about rtas_call_unlocked? Do the callers need to take the rtas
lock?
Machine checks must call ibm,nmi-interlock too, which we really don't
want to take a lock for either. Hopefully that's in a class of its own
and we can essentially ignore with respect to other rtas calls.
The spec is pretty vague too :(
"The ibm,get-xive call must be reentrant to the number of processors on
the platform."
This suggests ibm,get-xive can be called concurrently by multiple
processors. It doesn't say anything about being re-entrant against any
of the other re-entrant calls. Maybe that could be reasonably assumed,
but I don't know if it's reasonable to assume it can be called
concurrently with a *non-reentrant* call, is it?
> For this, it was suggested to add the buffer (struct rtas_args)
> in the PACA struct, so each cpu can have it's own buffer.
You can't do this, paca is not limited to RTAS_INSTANTIATE_MAX.
Which is good, because I didn't want you to add another 88 bytes to the
paca :) Can you make it a pointer and allocate it separately? Check
the slb_shadow allocation, you could use a similar pattern.
The other option would be to have just one more rtas args, and have the
crashing CPU always that. That would skirt the re-entrancy issue -- the
concurrency is only ever a last resort. Would be a bit tricker though.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v8 13/30] powerpc: Add a probe_user_read_inst() function
From: Jordan Niethe @ 2020-05-15 3:46 UTC (permalink / raw)
To: Christophe Leroy
Cc: Christophe Leroy, Alistair Popple, Nicholas Piggin, Balamuruhan S,
naveen.n.rao, linuxppc-dev, Daniel Axtens
In-Reply-To: <e4bd592e-2e35-9c73-854e-1380222f34ef@csgroup.eu>
On Thu, May 14, 2020 at 3:46 PM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
> > Introduce a probe_user_read_inst() function to use in cases where
> > probe_user_read() is used for getting an instruction. This will be more
> > useful for prefixed instructions.
> >
> > Reviewed-by: Alistair Popple <alistair@popple.id.au>
> > Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
> > ---
> > v6: - New to series
> > ---
> > arch/powerpc/include/asm/inst.h | 3 +++
> > arch/powerpc/lib/Makefile | 2 +-
> > arch/powerpc/lib/inst.c | 18 ++++++++++++++++++
> > arch/powerpc/mm/fault.c | 2 +-
> > 4 files changed, 23 insertions(+), 2 deletions(-)
> > create mode 100644 arch/powerpc/lib/inst.c
> >
> > diff --git a/arch/powerpc/include/asm/inst.h b/arch/powerpc/include/asm/inst.h
> > index 552e953bf04f..3e9a58420151 100644
> > --- a/arch/powerpc/include/asm/inst.h
> > +++ b/arch/powerpc/include/asm/inst.h
> > @@ -37,4 +37,7 @@ static inline bool ppc_inst_equal(struct ppc_inst x, struct ppc_inst y)
> > return ppc_inst_val(x) == ppc_inst_val(y);
> > }
> >
> > +int probe_user_read_inst(struct ppc_inst *inst,
> > + struct ppc_inst *nip);
> > +
> > #endif /* _ASM_INST_H */
> > diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
> > index b8de3be10eb4..546591848219 100644
> > --- a/arch/powerpc/lib/Makefile
> > +++ b/arch/powerpc/lib/Makefile
> > @@ -16,7 +16,7 @@ CFLAGS_code-patching.o += -DDISABLE_BRANCH_PROFILING
> > CFLAGS_feature-fixups.o += -DDISABLE_BRANCH_PROFILING
> > endif
> >
> > -obj-y += alloc.o code-patching.o feature-fixups.o pmem.o
> > +obj-y += alloc.o code-patching.o feature-fixups.o pmem.o inst.o
> >
> > ifndef CONFIG_KASAN
> > obj-y += string.o memcmp_$(BITS).o
> > diff --git a/arch/powerpc/lib/inst.c b/arch/powerpc/lib/inst.c
> > new file mode 100644
> > index 000000000000..eaf786afad2b
> > --- /dev/null
> > +++ b/arch/powerpc/lib/inst.c
> > @@ -0,0 +1,18 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright 2020, IBM Corporation.
> > + */
> > +
> > +#include <linux/uaccess.h>
> > +#include <asm/inst.h>
> > +
> > +int probe_user_read_inst(struct ppc_inst *inst,
> > + struct ppc_inst *nip)
> > +{
> > + unsigned int val;
> > + int err;
> > +
> > + err = probe_user_read(&val, nip, sizeof(val));
> > + *inst = ppc_inst(val);
> > + return err;
> > +}
> > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> > index 4a50f125ec18..f3a943eae305 100644
> > --- a/arch/powerpc/mm/fault.c
> > +++ b/arch/powerpc/mm/fault.c
> > @@ -281,7 +281,7 @@ static bool bad_stack_expansion(struct pt_regs *regs, unsigned long address,
> > access_ok(nip, sizeof(*nip))) {
> > struct ppc_inst inst;
> >
> > - if (!probe_user_read(&inst, nip, sizeof(inst)))
> > + if (!probe_user_read_inst(&inst, (struct ppc_inst __user *)nip))
>
> Shouldn't 'nip' become de 'struct ppc_inst __user *' instead of casting ?
>
> > return !store_updates_sp(inst);
> > *must_retry = true;
> > }
> >
Yeah it would make more sense to do it like this.
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -256,7 +256,7 @@ static bool bad_stack_expansion(struct pt_regs
*regs, unsigned long address,
* expand to 1MB without further checks.
*/
if (address + 0x100000 < vma->vm_end) {
- unsigned int __user *nip = (unsigned int __user *)regs->nip;
+ struct ppc_inst __user *nip = (struct ppc_inst __user *)regs->nip;
/* get user regs even if this fault is in kernel mode */
struct pt_regs *uregs = current->thread.regs;
if (uregs == NULL)
@@ -281,7 +281,7 @@ static bool bad_stack_expansion(struct pt_regs
*regs, unsigned long address,
access_ok(nip, sizeof(*nip))) {
struct ppc_inst inst;
- if (!probe_user_read_inst(&inst, (struct ppc_inst __user *)nip))
+ if (!probe_user_read_inst(&inst, nip))
return !store_updates_sp(inst);
*must_retry = true;
}
--
2.17.1
>
> Christophe
^ permalink raw reply
* Re: [PATCH v2 7/9] powerpc/ps3: Add check for otheros image size
From: Michael Ellerman @ 2020-05-15 2:02 UTC (permalink / raw)
To: Geoff Levand
Cc: linuxppc-dev, Geert Uytterhoeven, Markus Elfring,
Emmanuel Nicolet
In-Reply-To: <4e8defeb49d62dd9d435e5ea3ddc5668e56fa496.1589049250.git.geoff@infradead.org>
Hi Geoff,
Geoff Levand <geoff@infradead.org> writes:
> The ps3's otheros flash loader has a size limit of 16 MiB for the
> uncompressed image. If that limit will be reached output the
> flash image file as 'otheros-too-big.bld'.
>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> ---
> arch/powerpc/boot/wrapper | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> index 35ace40d9fc2..ab1e3ddc79f3 100755
> --- a/arch/powerpc/boot/wrapper
> +++ b/arch/powerpc/boot/wrapper
> @@ -571,7 +571,20 @@ ps3)
> count=$overlay_size bs=1
>
> odir="$(dirname "$ofile.bin")"
> - rm -f "$odir/otheros.bld"
> - gzip -n --force -9 --stdout "$ofile.bin" > "$odir/otheros.bld"
> +
> + # The ps3's flash loader has a size limit of 16 MiB for the uncompressed
> + # image. If a compressed image that exceeded this limit is written to
> + # flash the loader will decompress that image until the 16 MiB limit is
> + # reached, then enter the system reset vector of the partially decompressed
> + # image. No warning is issued.
> + rm -f "$odir"/{otheros,otheros-too-big}.bld
> + size=$(${CROSS}nm --no-sort --radix=d "$ofile" | egrep ' _end$' | cut -d' ' -f1)
> + bld="otheros.bld"
> + if [ $size -gt $((0x1000000)) ]; then
> + bld="otheros-too-big.bld"
> + echo " INFO: Uncompressed kernel is too large to program into PS3 flash memory;" \
This now appears on all my ppc64_defconfig builds, which I don't really
like.
That does highlight the fact that ppc64_defconfig including
CONFIG_PPC_PS3 is not really helpful for people actually wanting to run
the kernel on a PS3.
So I wonder if we should drop CONFIG_PPC_PS3 from ppc64_defconfig, in
which case I'd be happy to keep the INFO message because it should only
appear on ps3 specific builds.
The other option would be to drop the message, or only print it when
we're doing a verbose build.
Thoughts?
cheers
^ permalink raw reply
* Re: [PATCH v8 23/30] powerpc: Add prefixed instructions to instruction data type
From: Michael Ellerman @ 2020-05-15 1:33 UTC (permalink / raw)
To: Christophe Leroy, Jordan Niethe, linuxppc-dev
Cc: christophe.leroy, alistair, npiggin, bala24, naveen.n.rao, dja
In-Reply-To: <56ca6bcb-c719-a049-63b0-aae73023bde5@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 06/05/2020 à 05:40, Jordan Niethe a écrit :
>> For powerpc64, redefine the ppc_inst type so both word and prefixed
>> instructions can be represented. On powerpc32 the type will remain the
>> same. Update places which had assumed instructions to be 4 bytes long.
...
>> diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
>> index c0a35e4586a5..217897927926 100644
>> --- a/arch/powerpc/include/asm/uaccess.h
>> +++ b/arch/powerpc/include/asm/uaccess.h
>> @@ -105,11 +105,49 @@ static inline int __access_ok(unsigned long addr, unsigned long size,
>> #define __put_user_inatomic(x, ptr) \
>> __put_user_nosleep((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
>>
>> +#ifdef __powerpc64__
>
> Replace by CONFIG_PPC64
>
>> +#define __get_user_instr(x, ptr) \
>> +({ \
>> + long __gui_ret = 0; \
>> + unsigned long __gui_ptr = (unsigned long)ptr; \
>> + struct ppc_inst __gui_inst; \
>> + unsigned int prefix, suffix; \
>> + __gui_ret = __get_user(prefix, (unsigned int __user *)__gui_ptr); \
>
> __get_user() can be costly especially with KUAP. I think you should
> perform a 64 bits read and fallback on a 32 bits read only if the 64
> bits read failed.
I worry that might break something.
It _should_ be safe, but I'm paranoid.
If we think the KUAP overhead is a problem then I think we'd be better
off pulling the KUAP disable/enable into this macro.
>> diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
>> index 2bd2b752de4f..a8238eff3a31 100644
>> --- a/arch/powerpc/lib/feature-fixups.c
>> +++ b/arch/powerpc/lib/feature-fixups.c
>> @@ -84,12 +84,13 @@ static int patch_feature_section(unsigned long value, struct fixup_entry *fcur)
>> src = alt_start;
>> dest = start;
>>
>> - for (; src < alt_end; src++, dest++) {
>> + for (; src < alt_end; src = (void *)src + ppc_inst_len(ppc_inst_read(src)),
>> + (dest = (void *)dest + ppc_inst_len(ppc_inst_read(dest)))) {
>
> Can we do this outside the for() for readability ?
I have an idea for cleaning these up, will post it as a follow-up to the series.
>> diff --git a/arch/powerpc/lib/inst.c b/arch/powerpc/lib/inst.c
>> index 08dedd927268..eb6f9ee28ac6 100644
>> --- a/arch/powerpc/lib/inst.c
>> +++ b/arch/powerpc/lib/inst.c
>> @@ -3,9 +3,49 @@
>> * Copyright 2020, IBM Corporation.
>> */
>>
>> +#include <asm/ppc-opcode.h>
>> #include <linux/uaccess.h>
>> #include <asm/inst.h>
>>
>> +#ifdef __powerpc64__
>> +int probe_user_read_inst(struct ppc_inst *inst,
>> + struct ppc_inst *nip)
>> +{
>> + unsigned int val, suffix;
>> + int err;
>> +
>> + err = probe_user_read(&val, nip, sizeof(val));
>
> A user read is costly with KUAP. Can we do a 64 bits read and perform a
> 32 bits read only when 64 bits read fails ?
Same comment as above.
cheers
^ permalink raw reply
* Re: [PATCH v3 2/2] powerpc/rtas: Implement reentrant rtas call
From: Leonardo Bras @ 2020-05-15 0:00 UTC (permalink / raw)
To: Nathan Lynch
Cc: Gautham R. Shenoy, Greg Kroah-Hartman, linux-kernel,
Nicholas Piggin, Paul Mackerras, Nadav Amit, Thomas Gleixner,
linuxppc-dev, Allison Randal
In-Reply-To: <fc13b26ff3d2ea2e84049eabda0c60a60d851b40.camel@gmail.com>
On Thu, 2020-05-14 at 20:28 -0300, Leonardo Bras wrote:
> Yes, you are right.
> I will also add preempt_{dis,en}able, which in most kernels will
> compile out, but it will be kind of 'ready' if we ever decide to
> support PREEMPT.
>
> Thanks for the feedback!
v4:
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200514235138.150722-3-leobras.c@gmail.com/
^ 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