* [PATCH v6 07/14] arm: Use STACK_TOP when computing mmap base address
From: Alexandre Ghiti @ 2019-08-08 6:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Albert Ou, Kees Cook, Alexandre Ghiti, linux-mm, Catalin Marinas,
Palmer Dabbelt, Will Deacon, Russell King, Ralf Baechle,
linux-kernel, linux-fsdevel, Luis Chamberlain, Paul Burton,
Paul Walmsley, James Hogan, linux-riscv, linux-mips,
Christoph Hellwig, linux-arm-kernel, Alexander Viro
In-Reply-To: <20190808061756.19712-1-alex@ghiti.fr>
mmap base address must be computed wrt stack top address, using TASK_SIZE
is wrong since STACK_TOP and TASK_SIZE are not equivalent.
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
---
arch/arm/mm/mmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index bff3d00bda5b..0b94b674aa91 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -19,7 +19,7 @@
/* gap between mmap and stack */
#define MIN_GAP (128*1024*1024UL)
-#define MAX_GAP ((TASK_SIZE)/6*5)
+#define MAX_GAP ((STACK_TOP)/6*5)
#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
static int mmap_is_legacy(struct rlimit *rlim_stack)
@@ -51,7 +51,7 @@ static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
else if (gap > MAX_GAP)
gap = MAX_GAP;
- return PAGE_ALIGN(TASK_SIZE - gap - rnd);
+ return PAGE_ALIGN(STACK_TOP - gap - rnd);
}
/*
--
2.20.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 v6 08/14] arm: Use generic mmap top-down layout and brk randomization
From: Alexandre Ghiti @ 2019-08-08 6:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Albert Ou, Kees Cook, Alexandre Ghiti, linux-mm, Catalin Marinas,
Palmer Dabbelt, Will Deacon, Russell King, Ralf Baechle,
linux-kernel, linux-fsdevel, Luis Chamberlain, Paul Burton,
Paul Walmsley, James Hogan, linux-riscv, linux-mips,
Christoph Hellwig, linux-arm-kernel, Alexander Viro
In-Reply-To: <20190808061756.19712-1-alex@ghiti.fr>
arm uses a top-down mmap layout by default that exactly fits the generic
functions, so get rid of arch specific code and use the generic version
by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
As ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT selects ARCH_HAS_ELF_RANDOMIZE,
use the generic version of arch_randomize_brk since it also fits.
Note that this commit also removes the possibility for arm to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.
Note that it is safe to remove STACK_RND_MASK since it matches the default
value.
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
---
arch/arm/Kconfig | 2 +-
arch/arm/include/asm/processor.h | 2 --
arch/arm/kernel/process.c | 5 ---
arch/arm/mm/mmap.c | 62 --------------------------------
4 files changed, 1 insertion(+), 70 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..81b08b027e4e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,7 +7,6 @@ config ARM
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
- select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
select ARCH_HAS_KCOV
@@ -30,6 +29,7 @@ config ARM
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
select BUILDTIME_EXTABLE_SORT if MMU
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 20c2f42454b8..614bf829e454 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -140,8 +140,6 @@ static inline void prefetchw(const void *ptr)
#endif
#endif
-#define HAVE_ARCH_PICK_MMAP_LAYOUT
-
#endif
#endif /* __ASM_ARM_PROCESSOR_H */
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index f934a6739fc0..9485acc520a4 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -319,11 +319,6 @@ unsigned long get_wchan(struct task_struct *p)
return 0;
}
-unsigned long arch_randomize_brk(struct mm_struct *mm)
-{
- return randomize_page(mm->brk, 0x02000000);
-}
-
#ifdef CONFIG_MMU
#ifdef CONFIG_KUSER_HELPERS
/*
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 0b94b674aa91..b8d912ac9e61 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -17,43 +17,6 @@
((((addr)+SHMLBA-1)&~(SHMLBA-1)) + \
(((pgoff)<<PAGE_SHIFT) & (SHMLBA-1)))
-/* gap between mmap and stack */
-#define MIN_GAP (128*1024*1024UL)
-#define MAX_GAP ((STACK_TOP)/6*5)
-#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
- if (current->personality & ADDR_COMPAT_LAYOUT)
- return 1;
-
- if (rlim_stack->rlim_cur == RLIM_INFINITY)
- return 1;
-
- return sysctl_legacy_va_layout;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
- unsigned long gap = rlim_stack->rlim_cur;
- unsigned long pad = stack_guard_gap;
-
- /* Account for stack randomization if necessary */
- if (current->flags & PF_RANDOMIZE)
- pad += (STACK_RND_MASK << PAGE_SHIFT);
-
- /* Values close to RLIM_INFINITY can overflow. */
- if (gap + pad > gap)
- gap += pad;
-
- if (gap < MIN_GAP)
- gap = MIN_GAP;
- else if (gap > MAX_GAP)
- gap = MAX_GAP;
-
- return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
/*
* We need to ensure that shared mappings are correctly aligned to
* avoid aliasing issues with VIPT caches. We need to ensure that
@@ -181,31 +144,6 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
return addr;
}
-unsigned long arch_mmap_rnd(void)
-{
- unsigned long rnd;
-
- rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-
- return rnd << PAGE_SHIFT;
-}
-
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
- unsigned long random_factor = 0UL;
-
- if (current->flags & PF_RANDOMIZE)
- random_factor = arch_mmap_rnd();
-
- if (mmap_is_legacy(rlim_stack)) {
- mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
- mm->get_unmapped_area = arch_get_unmapped_area;
- } else {
- mm->mmap_base = mmap_base(random_factor, rlim_stack);
- mm->get_unmapped_area = arch_get_unmapped_area_topdown;
- }
-}
-
/*
* You really shouldn't be using read() or write() on /dev/mem. This
* might go away in the future.
--
2.20.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
* Re: [Sound-open-firmware] [PATCH v2 3/5] ASoC: SOF: Add DT DSP device support
From: Daniel Baluta @ 2019-08-08 6:27 UTC (permalink / raw)
To: Pierre-Louis Bossart
Cc: Mark Rutland, Aisheng Dong, Peng Fan, Fabio Estevam, Anson Huang,
Devicetree List, Daniel Baluta, S.j. Wang, Marco Felsch,
Linux Kernel Mailing List, Paul Olaru, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, Leonard Crestez, Shawn Guo,
linux-arm-kernel, sound-open-firmware
In-Reply-To: <CAEnQRZCE3mxorYpL_nPXiU4MezGDaqUfuFDx8ci0WdXzDa68JA@mail.gmail.com>
On Wed, Aug 7, 2019 at 6:28 PM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>
> On Wed, Aug 7, 2019 at 6:22 PM Pierre-Louis Bossart
> <pierre-louis.bossart@linux.intel.com> wrote:
> >
> >
> > >>>> +static int sof_dt_probe(struct platform_device *pdev)
> > >>>> +{
> > >>>> + struct device *dev = &pdev->dev;
> > >>>> + const struct sof_dev_desc *desc;
> > >>>> + /*TODO: create a generic snd_soc_xxx_mach */
> > >>>> + struct snd_soc_acpi_mach *mach;
> > >>>
> > >>> I wonder if you really need to use the same structures. For Intel we get
> > >>> absolutely zero info from the firmware so rely on an ACPI codec ID as a
> > >>> key to find information on which firmware and topology to use, and which
> > >>> machine driver to load. You could have all this information in a DT blob?
> > >>
> > >> Yes. I see your point. I will still need to make a generic structure for
> > >> snd_soc_acpi_mach so that everyone can use sof_nocodec_setup function.
> > >>
> > >> Maybe something like this:
> > >>
> > >> struct snd_soc_mach {
> > >> union {
> > >> struct snd_soc_acpi_mach acpi_mach;
> > >> struct snd_soc_of_mach of_mach;
> > >> }
> > >> };
> > >>
> > >> and then change the prototype of sof_nocodec_setup.
> > >
> > > Hi Pierre,
> > >
> > > I fixed all the comments except the one above. Replacing snd_soc_acpi_mach
> > > with a generic snd_soc_mach is not trivial task.
> > >
> > > I wonder if it is acceptable to get the initial patches as they are
> > > now and later switch to
> > > generic ACPI/OF abstraction.
> > >
> > > Asking this because for the moment on the i.MX side I have only
> > > implemented no codec
> > > version and we don't probe any of the machine drivers we have.
> > >
> > > So, there is this only one member of snd_soc_acpi_mach that imx
> > > version is making use of:
> > >
> > > mach->drv_name = "sof-nocodec";
> > >
> > > That's all.
> > >
> > > I think the change as it is now is very clean and non-intrusive. Later
> > > we will get options to
> > > read firmware name and stuff from DT.
> > >
> > > Anyhow, I don't think we can get rid of snd_dev_desc structure on
> > > i.MX. This will be used
> > > to store the information read from DT:
> > >
> > > static struct sof_dev_desc sof_of_imx8qxp_desc = {
> > > » .default_fw_path = "imx/sof",
> > > » .default_tplg_path = "imx/sof-tplg",
> > > » .nocodec_fw_filename = "sof-imx8.ri",
> > > » .nocodec_tplg_filename = "sof-imx8-nocodec.tplg",
> > > » .ops = &sof_imx8_ops,
> > > };
> > >
> > > For the moment we will only use the default values.
> >
> > Yes, that's fine for now. If you don't have a real machine driver then
> > there's nothing urgent to change.
> >
> > Is the new version on GitHub?
>
> Not yet, will push it today and ping you.
PR updated: https://github.com/thesofproject/linux/pull/1048
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 09/14] mips: Properly account for stack randomization and stack guard gap
From: Alexandre Ghiti @ 2019-08-08 6:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Albert Ou, Kees Cook, Alexandre Ghiti, linux-mm, Catalin Marinas,
Palmer Dabbelt, Will Deacon, Russell King, Ralf Baechle,
linux-kernel, linux-fsdevel, Luis Chamberlain, Paul Burton,
Paul Walmsley, James Hogan, linux-riscv, linux-mips,
Christoph Hellwig, linux-arm-kernel, Alexander Viro
In-Reply-To: <20190808061756.19712-1-alex@ghiti.fr>
This commit takes care of stack randomization and stack guard gap when
computing mmap base address and checks if the task asked for randomization.
This fixes the problem uncovered and not fixed for arm here:
https://lkml.kernel.org/r/20170622200033.25714-1-riel@redhat.com
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Paul Burton <paul.burton@mips.com>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
---
arch/mips/mm/mmap.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index d79f2b432318..f5c778113384 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -21,8 +21,9 @@ unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */
EXPORT_SYMBOL(shm_align_mask);
/* gap between mmap and stack */
-#define MIN_GAP (128*1024*1024UL)
-#define MAX_GAP ((TASK_SIZE)/6*5)
+#define MIN_GAP (128*1024*1024UL)
+#define MAX_GAP ((TASK_SIZE)/6*5)
+#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
static int mmap_is_legacy(struct rlimit *rlim_stack)
{
@@ -38,6 +39,15 @@ static int mmap_is_legacy(struct rlimit *rlim_stack)
static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
{
unsigned long gap = rlim_stack->rlim_cur;
+ unsigned long pad = stack_guard_gap;
+
+ /* Account for stack randomization if necessary */
+ if (current->flags & PF_RANDOMIZE)
+ pad += (STACK_RND_MASK << PAGE_SHIFT);
+
+ /* Values close to RLIM_INFINITY can overflow. */
+ if (gap + pad > gap)
+ gap += pad;
if (gap < MIN_GAP)
gap = MIN_GAP;
--
2.20.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 v6 10/14] mips: Use STACK_TOP when computing mmap base address
From: Alexandre Ghiti @ 2019-08-08 6:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Albert Ou, Kees Cook, Alexandre Ghiti, linux-mm, Catalin Marinas,
Palmer Dabbelt, Will Deacon, Russell King, Ralf Baechle,
linux-kernel, linux-fsdevel, Luis Chamberlain, Paul Burton,
Paul Walmsley, James Hogan, linux-riscv, linux-mips,
Christoph Hellwig, linux-arm-kernel, Alexander Viro
In-Reply-To: <20190808061756.19712-1-alex@ghiti.fr>
mmap base address must be computed wrt stack top address, using TASK_SIZE
is wrong since STACK_TOP and TASK_SIZE are not equivalent.
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Paul Burton <paul.burton@mips.com>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
---
arch/mips/mm/mmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index f5c778113384..a7e84b2e71d7 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -22,7 +22,7 @@ EXPORT_SYMBOL(shm_align_mask);
/* gap between mmap and stack */
#define MIN_GAP (128*1024*1024UL)
-#define MAX_GAP ((TASK_SIZE)/6*5)
+#define MAX_GAP ((STACK_TOP)/6*5)
#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
static int mmap_is_legacy(struct rlimit *rlim_stack)
@@ -54,7 +54,7 @@ static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
else if (gap > MAX_GAP)
gap = MAX_GAP;
- return PAGE_ALIGN(TASK_SIZE - gap - rnd);
+ return PAGE_ALIGN(STACK_TOP - gap - rnd);
}
#define COLOUR_ALIGN(addr, pgoff) \
--
2.20.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 v3] arm64: mm: print hexadecimal EC value in mem_abort_decode()
From: Miles Chen @ 2019-08-08 6:29 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, wsd_upstream, Anshuman Khandual, linux-kernel,
Miles Chen, linux-mediatek, James Morse, linux-arm-kernel
This change prints the hexadecimal EC value in mem_abort_decode(),
which makes it easier to lookup the corresponding EC in
the ARM Architecture Reference Manual.
The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
faults") prints useful information when memory abort occurs. It would
be easier to lookup "0x25" instead of "DABT" in the document. Then we
can check the corresponding ISS.
For example:
Current info Document
EC Exception class
"CP15 MCR/MRC" 0x3 "MCR or MRC access to CP15a..."
"ASIMD" 0x7 "Access to SIMD or floating-point..."
"DABT (current EL)" 0x25 "Data Abort taken without..."
...
Before:
Unable to handle kernel paging request at virtual address 000000000000c000
Mem abort info:
ESR = 0x96000046
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000046
CM = 0, WnR = 1
After:
Unable to handle kernel paging request at virtual address 000000000000c000
Mem abort info:
ESR = 0x96000046
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000046
CM = 0, WnR = 1
Change since v1:
print "EC" instead of "Exception class"
print EC in fixwidth
Change since v2:
add acked-by tag from Mark since v2 implemented the suggestion in v1
add reviewed-by tag from Anshuman in v2
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Mark Rutland <Mark.rutland@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: James Morse <james.morse@arm.com>
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
---
arch/arm64/mm/fault.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index cfd65b63f36f..ad4980a27edb 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -86,8 +86,8 @@ static void mem_abort_decode(unsigned int esr)
pr_alert("Mem abort info:\n");
pr_alert(" ESR = 0x%08x\n", esr);
- pr_alert(" Exception class = %s, IL = %u bits\n",
- esr_get_class_string(esr),
+ pr_alert(" EC = 0x%02lx: %s, IL = %u bits\n",
+ ESR_ELx_EC(esr), esr_get_class_string(esr),
(esr & ESR_ELx_IL) ? 32 : 16);
pr_alert(" SET = %lu, FnV = %lu\n",
(esr & ESR_ELx_SET_MASK) >> ESR_ELx_SET_SHIFT,
--
2.18.0
_______________________________________________
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 v6 11/14] mips: Adjust brk randomization offset to fit generic version
From: Alexandre Ghiti @ 2019-08-08 6:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Albert Ou, Kees Cook, Alexandre Ghiti, linux-mm, Catalin Marinas,
Palmer Dabbelt, Will Deacon, Russell King, Ralf Baechle,
linux-kernel, linux-fsdevel, Luis Chamberlain, Paul Burton,
Paul Walmsley, James Hogan, linux-riscv, linux-mips,
Christoph Hellwig, linux-arm-kernel, Alexander Viro
In-Reply-To: <20190808061756.19712-1-alex@ghiti.fr>
This commit simply bumps up to 32MB and 1GB the random offset
of brk, compared to 8MB and 256MB, for 32bit and 64bit respectively.
Suggested-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Paul Burton <paul.burton@mips.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
---
arch/mips/mm/mmap.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index a7e84b2e71d7..ff6ab87e9c56 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -16,6 +16,7 @@
#include <linux/random.h>
#include <linux/sched/signal.h>
#include <linux/sched/mm.h>
+#include <linux/sizes.h>
unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */
EXPORT_SYMBOL(shm_align_mask);
@@ -189,11 +190,11 @@ static inline unsigned long brk_rnd(void)
unsigned long rnd = get_random_long();
rnd = rnd << PAGE_SHIFT;
- /* 8MB for 32bit, 256MB for 64bit */
+ /* 32MB for 32bit, 1GB for 64bit */
if (TASK_IS_32BIT_ADDR)
- rnd = rnd & 0x7ffffful;
+ rnd = rnd & (SZ_32M - 1);
else
- rnd = rnd & 0xffffffful;
+ rnd = rnd & (SZ_1G - 1);
return rnd;
}
--
2.20.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 v6 12/14] mips: Replace arch specific way to determine 32bit task with generic version
From: Alexandre Ghiti @ 2019-08-08 6:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Albert Ou, Kees Cook, Alexandre Ghiti, linux-mm, Catalin Marinas,
Palmer Dabbelt, Will Deacon, Russell King, Ralf Baechle,
linux-kernel, linux-fsdevel, Luis Chamberlain, Paul Burton,
Paul Walmsley, James Hogan, linux-riscv, linux-mips,
Christoph Hellwig, linux-arm-kernel, Alexander Viro
In-Reply-To: <20190808061756.19712-1-alex@ghiti.fr>
Mips uses TASK_IS_32BIT_ADDR to determine if a task is 32bit, but
this define is mips specific and other arches do not have it: instead,
use !IS_ENABLED(CONFIG_64BIT) || is_compat_task() condition.
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Paul Burton <paul.burton@mips.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
---
arch/mips/mm/mmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index ff6ab87e9c56..d5106c26ac6a 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -17,6 +17,7 @@
#include <linux/sched/signal.h>
#include <linux/sched/mm.h>
#include <linux/sizes.h>
+#include <linux/compat.h>
unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */
EXPORT_SYMBOL(shm_align_mask);
@@ -191,7 +192,7 @@ static inline unsigned long brk_rnd(void)
rnd = rnd << PAGE_SHIFT;
/* 32MB for 32bit, 1GB for 64bit */
- if (TASK_IS_32BIT_ADDR)
+ if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task())
rnd = rnd & (SZ_32M - 1);
else
rnd = rnd & (SZ_1G - 1);
--
2.20.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 v6 13/14] mips: Use generic mmap top-down layout and brk randomization
From: Alexandre Ghiti @ 2019-08-08 6:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Albert Ou, Kees Cook, Alexandre Ghiti, linux-mm, Catalin Marinas,
Palmer Dabbelt, Will Deacon, Russell King, Ralf Baechle,
linux-kernel, linux-fsdevel, Luis Chamberlain, Paul Burton,
Paul Walmsley, James Hogan, linux-riscv, linux-mips,
Christoph Hellwig, linux-arm-kernel, Alexander Viro
In-Reply-To: <20190808061756.19712-1-alex@ghiti.fr>
mips uses a top-down layout by default that exactly fits the generic
functions, so get rid of arch specific code and use the generic version
by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
As ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT selects ARCH_HAS_ELF_RANDOMIZE,
use the generic version of arch_randomize_brk since it also fits.
Note that this commit also removes the possibility for mips to have elf
randomization and no MMU: without MMU, the security added by randomization
is worth nothing.
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Paul Burton <paul.burton@mips.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
---
arch/mips/Kconfig | 2 +-
arch/mips/include/asm/processor.h | 5 --
arch/mips/mm/mmap.c | 96 -------------------------------
3 files changed, 1 insertion(+), 102 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d50fafd7bf3a..4e85d7d2cf1a 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -5,7 +5,6 @@ config MIPS
select ARCH_32BIT_OFF_T if !64BIT
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
select ARCH_CLOCKSOURCE_DATA
- select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_SUPPORTS_UPROBES
@@ -13,6 +12,7 @@ config MIPS
select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
+ select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT
select CLONE_BACKWARDS
diff --git a/arch/mips/include/asm/processor.h b/arch/mips/include/asm/processor.h
index aca909bd7841..fba18d4a9190 100644
--- a/arch/mips/include/asm/processor.h
+++ b/arch/mips/include/asm/processor.h
@@ -29,11 +29,6 @@
extern unsigned int vced_count, vcei_count;
-/*
- * MIPS does have an arch_pick_mmap_layout()
- */
-#define HAVE_ARCH_PICK_MMAP_LAYOUT 1
-
#ifdef CONFIG_32BIT
#ifdef CONFIG_KVM_GUEST
/* User space process size is limited to 1GB in KVM Guest Mode */
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index d5106c26ac6a..00fe90c6db3e 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -16,49 +16,10 @@
#include <linux/random.h>
#include <linux/sched/signal.h>
#include <linux/sched/mm.h>
-#include <linux/sizes.h>
-#include <linux/compat.h>
unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */
EXPORT_SYMBOL(shm_align_mask);
-/* gap between mmap and stack */
-#define MIN_GAP (128*1024*1024UL)
-#define MAX_GAP ((STACK_TOP)/6*5)
-#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
- if (current->personality & ADDR_COMPAT_LAYOUT)
- return 1;
-
- if (rlim_stack->rlim_cur == RLIM_INFINITY)
- return 1;
-
- return sysctl_legacy_va_layout;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
- unsigned long gap = rlim_stack->rlim_cur;
- unsigned long pad = stack_guard_gap;
-
- /* Account for stack randomization if necessary */
- if (current->flags & PF_RANDOMIZE)
- pad += (STACK_RND_MASK << PAGE_SHIFT);
-
- /* Values close to RLIM_INFINITY can overflow. */
- if (gap + pad > gap)
- gap += pad;
-
- if (gap < MIN_GAP)
- gap = MIN_GAP;
- else if (gap > MAX_GAP)
- gap = MAX_GAP;
-
- return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
#define COLOUR_ALIGN(addr, pgoff) \
((((addr) + shm_align_mask) & ~shm_align_mask) + \
(((pgoff) << PAGE_SHIFT) & shm_align_mask))
@@ -156,63 +117,6 @@ unsigned long arch_get_unmapped_area_topdown(struct file *filp,
addr0, len, pgoff, flags, DOWN);
}
-unsigned long arch_mmap_rnd(void)
-{
- unsigned long rnd;
-
-#ifdef CONFIG_COMPAT
- if (TASK_IS_32BIT_ADDR)
- rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
- else
-#endif /* CONFIG_COMPAT */
- rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-
- return rnd << PAGE_SHIFT;
-}
-
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
- unsigned long random_factor = 0UL;
-
- if (current->flags & PF_RANDOMIZE)
- random_factor = arch_mmap_rnd();
-
- if (mmap_is_legacy(rlim_stack)) {
- mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
- mm->get_unmapped_area = arch_get_unmapped_area;
- } else {
- mm->mmap_base = mmap_base(random_factor, rlim_stack);
- mm->get_unmapped_area = arch_get_unmapped_area_topdown;
- }
-}
-
-static inline unsigned long brk_rnd(void)
-{
- unsigned long rnd = get_random_long();
-
- rnd = rnd << PAGE_SHIFT;
- /* 32MB for 32bit, 1GB for 64bit */
- if (!IS_ENABLED(CONFIG_64BIT) || is_compat_task())
- rnd = rnd & (SZ_32M - 1);
- else
- rnd = rnd & (SZ_1G - 1);
-
- return rnd;
-}
-
-unsigned long arch_randomize_brk(struct mm_struct *mm)
-{
- unsigned long base = mm->brk;
- unsigned long ret;
-
- ret = PAGE_ALIGN(base + brk_rnd());
-
- if (ret < mm->brk)
- return mm->brk;
-
- return ret;
-}
-
bool __virt_addr_valid(const volatile void *kaddr)
{
unsigned long vaddr = (unsigned long)kaddr;
--
2.20.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 v6 14/14] riscv: Make mmap allocation top-down by default
From: Alexandre Ghiti @ 2019-08-08 6:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Albert Ou, Kees Cook, Alexandre Ghiti, linux-mm, Catalin Marinas,
Palmer Dabbelt, Will Deacon, Russell King, Ralf Baechle,
linux-kernel, linux-fsdevel, Luis Chamberlain, Paul Burton,
Paul Walmsley, James Hogan, linux-riscv, linux-mips,
Christoph Hellwig, linux-arm-kernel, Alexander Viro
In-Reply-To: <20190808061756.19712-1-alex@ghiti.fr>
In order to avoid wasting user address space by using bottom-up mmap
allocation scheme, prefer top-down scheme when possible.
Before:
root@qemuriscv64:~# cat /proc/self/maps
00010000-00016000 r-xp 00000000 fe:00 6389 /bin/cat.coreutils
00016000-00017000 r--p 00005000 fe:00 6389 /bin/cat.coreutils
00017000-00018000 rw-p 00006000 fe:00 6389 /bin/cat.coreutils
00018000-00039000 rw-p 00000000 00:00 0 [heap]
1555556000-155556d000 r-xp 00000000 fe:00 7193 /lib/ld-2.28.so
155556d000-155556e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so
155556e000-155556f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so
155556f000-1555570000 rw-p 00000000 00:00 0
1555570000-1555572000 r-xp 00000000 00:00 0 [vdso]
1555574000-1555576000 rw-p 00000000 00:00 0
1555576000-1555674000 r-xp 00000000 fe:00 7187 /lib/libc-2.28.so
1555674000-1555678000 r--p 000fd000 fe:00 7187 /lib/libc-2.28.so
1555678000-155567a000 rw-p 00101000 fe:00 7187 /lib/libc-2.28.so
155567a000-15556a0000 rw-p 00000000 00:00 0
3fffb90000-3fffbb1000 rw-p 00000000 00:00 0 [stack]
After:
root@qemuriscv64:~# cat /proc/self/maps
00010000-00016000 r-xp 00000000 fe:00 6389 /bin/cat.coreutils
00016000-00017000 r--p 00005000 fe:00 6389 /bin/cat.coreutils
00017000-00018000 rw-p 00006000 fe:00 6389 /bin/cat.coreutils
2de81000-2dea2000 rw-p 00000000 00:00 0 [heap]
3ff7eb6000-3ff7ed8000 rw-p 00000000 00:00 0
3ff7ed8000-3ff7fd6000 r-xp 00000000 fe:00 7187 /lib/libc-2.28.so
3ff7fd6000-3ff7fda000 r--p 000fd000 fe:00 7187 /lib/libc-2.28.so
3ff7fda000-3ff7fdc000 rw-p 00101000 fe:00 7187 /lib/libc-2.28.so
3ff7fdc000-3ff7fe2000 rw-p 00000000 00:00 0
3ff7fe4000-3ff7fe6000 r-xp 00000000 00:00 0 [vdso]
3ff7fe6000-3ff7ffd000 r-xp 00000000 fe:00 7193 /lib/ld-2.28.so
3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so
3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so
3ff7fff000-3ff8000000 rw-p 00000000 00:00 0
3fff888000-3fff8a9000 rw-p 00000000 00:00 0 [stack]
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Paul Walmsley <paul.walmsley@sifive.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
---
arch/riscv/Kconfig | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 59a4727ecd6c..87dc5370becb 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -54,6 +54,18 @@ config RISCV
select EDAC_SUPPORT
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
+ select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
+ select HAVE_ARCH_MMAP_RND_BITS
+
+config ARCH_MMAP_RND_BITS_MIN
+ default 18 if 64BIT
+ default 8
+
+# max bits determined by the following formula:
+# VA_BITS - PAGE_SHIFT - 3
+config ARCH_MMAP_RND_BITS_MAX
+ default 24 if 64BIT # SV39 based
+ default 17
config MMU
def_bool y
--
2.20.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
* Re: [PATCH] kernfs: fix memleak in kernel_ops_readdir()
From: Greg Kroah-Hartman @ 2019-08-08 6:42 UTC (permalink / raw)
To: Tejun Heo
Cc: Andrea Arcangeli, Tony Lindgren, linux-kernel, Russell King,
linux-omap, linux-arm-kernel
In-Reply-To: <20190807184518.GP136335@devbig004.ftw2.facebook.com>
On Wed, Aug 07, 2019 at 11:45:18AM -0700, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 07, 2019 at 06:29:28AM -0700, Tony Lindgren wrote:
> > Hi,
> >
> > * Tejun Heo <tj@kernel.org> [691231 23:00]:
> > > From: Andrea Arcangeli <aarcange@redhat.com>
> > >
> > > If getdents64 is killed or hits on segfault, it'll leave cgroups
> > > directories in sysfs pinned leaking memory because the kernfs node
> > > won't be freed on rmdir and the parent neither.
> >
> > Somehow this causes a regression in Linux next for me where I'm seeing
> > lots of sysfs entries now missing under /sys/bus/platform/devices.
> >
> > For example, I now only see one .serial entry show up in sysfs.
> > Things work again if I revert commit cc798c83898e ("kernfs: fix memleak
> > inkernel_ops_readdir()"). Any ideas why that would be?
> >
> > Below is a diff -u of ls /sys/bus/platform/devices for reference
> > showing the missing entries with cc798c83898e.
>
> Ugh, you're right. It can get double-put cuz ctx->pos is put by
> release too. Greg, sorry about the noise but can you please revert
> the patch? I'll look into why this looked like memory leak from
> slabinfo side.
Now reverted, thanks.
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V5 0/3] perf: imx8_ddr_perf: add AXI ID filter
From: Joakim Zhang @ 2019-08-08 6:45 UTC (permalink / raw)
To: robin.murphy@arm.com, will@kernel.org, mark.rutland@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
Add AXI ID filter for imx8m ddr perf.
Joakim Zhang (3):
perf: imx8_ddr_perf: add AXI ID filter support
Documentation: admin-guide: perf: add i.MX8 ddr pmu user doc
MAINTAINERS: add imx8 ddr perf admin-guide maintainer information
Documentation/admin-guide/perf/imx-ddr.rst | 30 +++++++++++
MAINTAINERS | 1 +
drivers/perf/fsl_imx8_ddr_perf.c | 63 +++++++++++++++++++++-
3 files changed, 92 insertions(+), 2 deletions(-)
create mode 100644 Documentation/admin-guide/perf/imx-ddr.rst
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-08 6:45 UTC (permalink / raw)
To: robin.murphy@arm.com, will@kernel.org, mark.rutland@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190808064216.6950-1-qiangqing.zhang@nxp.com>
AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
writes with an ARID or AXID matching filter setting. Granularity is at
subsystem level. Implementation does not allow filtring between masters
within a subsystem. Filter is defined with 2 configuration registers.
--AXI_ID defines AxID matching value
--AXI_MASKING defines which bits of AxID are meaningful for the matching
When non-masked bits are matching corresponding AXI_ID bits then counter
is incremented. This filter allows counting read or write access from a
subsystem or multiple subsystems.
Perf counter is incremented if AxID && AXI_MASKING == AXI_ID && AXI_MASKING
AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
Read and write AXI ID filter should write same value to DPCR1 if want to
specify at the same time as this filter is shared between counters.
e.g.
perf stat -a -e imx8_ddr0/axi-id-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axi-id-write,axi_id=0xMMMMDDDD/ cmd
MMMM: AXI_MASKING
DDDD: AXI_ID
ChangeLog:
V1 -> V2:
* add error log if user specifies read/write AXI ID filter at
the same time.
* of_device_get_match_data() instead of of_match_device(), and
remove the check of return value.
V2 -> V3:
* move the AXI ID check to event_add().
* add support for same value of axi_id.
V3 -> V4:
* move the AXI ID check to event_init().
V4 -> V5:
* reject event group if AXI ID not consistent in event_init().
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
drivers/perf/fsl_imx8_ddr_perf.c | 63 +++++++++++++++++++++++++++++++-
1 file changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
index 63fe21600072..f25cf5cbe156 100644
--- a/drivers/perf/fsl_imx8_ddr_perf.c
+++ b/drivers/perf/fsl_imx8_ddr_perf.c
@@ -42,9 +42,22 @@
static DEFINE_IDA(ddr_ida);
+/* DDR Perf hardware feature */
+#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter */
+
+struct fsl_ddr_devtype_data {
+ unsigned int quirks; /* quirks needed for different DDR Perf core */
+};
+
+static const struct fsl_ddr_devtype_data imx8_devtype_data;
+
+static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
+ .quirks = DDR_CAP_AXI_ID_FILTER,
+};
+
static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
- { .compatible = "fsl,imx8-ddr-pmu",},
- { .compatible = "fsl,imx8m-ddr-pmu",},
+ { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
+ { .compatible = "fsl,imx8m-ddr-pmu", .data = &imx8m_devtype_data},
{ /* sentinel */ }
};
@@ -57,6 +70,7 @@ struct ddr_pmu {
struct perf_event *events[NUM_COUNTERS];
int active_events;
enum cpuhp_state cpuhp_state;
+ const struct fsl_ddr_devtype_data *devtype_data;
int irq;
int id;
};
@@ -128,6 +142,8 @@ static struct attribute *ddr_perf_events_attrs[] = {
IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
+ IMX8_DDR_PMU_EVENT_ATTR(axi-id-read, 0x41),
+ IMX8_DDR_PMU_EVENT_ATTR(axi-id-write, 0x42),
NULL,
};
@@ -137,9 +153,11 @@ static struct attribute_group ddr_perf_events_attr_group = {
};
PMU_FORMAT_ATTR(event, "config:0-7");
+PMU_FORMAT_ATTR(axi_id, "config1:0-31");
static struct attribute *ddr_perf_format_attrs[] = {
&format_attr_event.attr,
+ &format_attr_axi_id.attr,
NULL,
};
@@ -189,6 +207,16 @@ static u32 ddr_perf_read_counter(struct ddr_pmu *pmu, int counter)
return readl_relaxed(pmu->base + COUNTER_READ + counter * 4);
}
+static bool ddr_perf_is_filtered(struct perf_event *event)
+{
+ return event->attr.config == 0x41 || event->attr.config == 0x42;
+}
+
+static u32 ddr_perf_filter_val(struct perf_event *event)
+{
+ return event->attr.config1;
+}
+
static int ddr_perf_event_init(struct perf_event *event)
{
struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
@@ -215,6 +243,18 @@ static int ddr_perf_event_init(struct perf_event *event)
!is_software_event(event->group_leader))
return -EINVAL;
+ if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
+ bool is_filtered = ddr_perf_is_filtered(event);
+ u32 filter_val = ddr_perf_filter_val(event);
+
+ for_each_sibling_event(sibling, event->group_leader) {
+ if (is_filtered && ddr_perf_is_filtered(sibling) &&
+ ddr_perf_filter_val(sibling) != filter_val) {
+ return -EINVAL;
+ }
+ }
+ }
+
for_each_sibling_event(sibling, event->group_leader) {
if (sibling->pmu != event->pmu &&
!is_software_event(sibling))
@@ -288,6 +328,23 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
int counter;
int cfg = event->attr.config;
+ if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
+ int i;
+ bool is_filtered = ddr_perf_is_filtered(event);
+ u32 filter_val = ddr_perf_filter_val(event);
+
+ for (i = 1; i < NUM_COUNTERS; i++) {
+ if (is_filtered && pmu->events[i] &&
+ ddr_perf_is_filtered(pmu->events[i]) &&
+ ddr_perf_filter_val(pmu->events[i]) != filter_val) {
+ dev_dbg(pmu->dev, "Contradictory axi id filter value\n");
+ return -EINVAL;
+ }
+ }
+
+ writel(filter_val, pmu->base + COUNTER_DPCR1);
+ }
+
counter = ddr_perf_alloc_counter(pmu, cfg);
if (counter < 0) {
dev_dbg(pmu->dev, "There are not enough counters\n");
@@ -472,6 +529,8 @@ static int ddr_perf_probe(struct platform_device *pdev)
if (!name)
return -ENOMEM;
+ pmu->devtype_data = of_device_get_match_data(&pdev->dev);
+
pmu->cpu = raw_smp_processor_id();
ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
DDR_CPUHP_CB_NAME,
--
2.17.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 V5 2/3] Documentation: admin-guide: perf: add i.MX8 ddr pmu user doc
From: Joakim Zhang @ 2019-08-08 6:45 UTC (permalink / raw)
To: robin.murphy@arm.com, will@kernel.org, mark.rutland@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190808064216.6950-1-qiangqing.zhang@nxp.com>
Add i.MX8 ddr pmu user doc.
ChangeLog:
V1 -> V4:
* new add in V4.
V4 -> V5:
* no change.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
Documentation/admin-guide/perf/imx-ddr.rst | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/admin-guide/perf/imx-ddr.rst
diff --git a/Documentation/admin-guide/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst
new file mode 100644
index 000000000000..8ab50e2da27e
--- /dev/null
+++ b/Documentation/admin-guide/perf/imx-ddr.rst
@@ -0,0 +1,30 @@
+====================================================
+Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
+====================================================
+
+There are no performance counters inside the DRAM controller, so performance
+signals are brought out to the edge of the controller where a set of 4 x 32 bit
+counters is implemented. This is controlled by the Performance log on parameter
+which causes a large number of PERF signals to be generated.
+
+Selection of the value for each counter is done via the config registiers. There
+is one register for each counter. Counter 0 is special in that it always counts
+“time” and when expired causes a lock on itself and the other counters and an
+interrupt ie enable of counter 0 is a global function.
+
+The "format" directory describes format of the config (event ID) and config1
+(AXI ID filter) fields of the perf_event_attr structure, see /sys/bus/event_source/
+devices/imx8_ddr0/format/. The "events" directory describes the events types
+hardware supported that can be used with perf tool, see /sys/bus/event_source/
+devices/imx8_ddr0/events/.
+
+AXI ID filter is only used by CSV modes 0x41 (axi-id-read) and 0x42 (axi-id-write)
+to count reading or writing matches filter setting. User should specify this two
+events with the same AXI ID filter value if want to count at the same time, as
+this filter register is shared between counters.
+
+Example for perf tool use::
+
+ perf stat -e imx8_ddr0/cycles/ sleep 1
+ perf stat -e imx8_ddr0/read/,imx8_ddr0/write/ sleep 1
+ perf stat -e imx8_ddr0/axi-id-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axi-id-write,axi_id=0xMMMMDDDD/ sleep 1
--
2.17.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 V5 3/3] MAINTAINERS: add imx8 ddr perf admin-guide maintainer information
From: Joakim Zhang @ 2019-08-08 6:45 UTC (permalink / raw)
To: robin.murphy@arm.com, will@kernel.org, mark.rutland@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190808064216.6950-1-qiangqing.zhang@nxp.com>
Add imx8 ddr perf admin-guide maintainer information.
ChangeLog:
V1 -> V5:
* new add in V5.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c6fa7e88a6f0..bc4eae7eba64 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6383,6 +6383,7 @@ M: Frank Li <Frank.li@nxp.com>
L: linux-arm-kernel@lists.infradead.org
S: Maintained
F: drivers/perf/fsl_imx8_ddr_perf.c
+F: Documentation/admin-guide/perf/imx-ddr.rst
F: Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt
FREESCALE IMX LPI2C DRIVER
--
2.17.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
* Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on A64-OLinuXino
From: Chen-Yu Tsai @ 2019-08-08 6:57 UTC (permalink / raw)
To: Sunil Mohan Adapa; +Cc: Maxime Ripard, Martin Ayotte, linux-arm-kernel
In-Reply-To: <70322b1b-2ee2-89c7-96f9-0d2dba4e0d64@medhas.org>
On Thu, Aug 8, 2019 at 2:25 PM Sunil Mohan Adapa <sunil@medhas.org> wrote:
>
>
>
> On 07/08/19 10:12 pm, Chen-Yu Tsai wrote:
> > On Wed, Aug 7, 2019 at 10:45 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Aug 07, 2019 at 08:09:19PM +0800, Chen-Yu Tsai wrote:
> >>> On Wed, Aug 7, 2019 at 8:01 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >>>>
> >>>> On Tue, Aug 06, 2019 at 02:25:17PM +0800, Chen-Yu Tsai wrote:
> >>>>> On Mon, Aug 5, 2019 at 8:58 PM Martin Ayotte <martinayotte@gmail.com> wrote:
> >>>>>>
> >>>>>> Fine for me too.
> >>>>>>
> >>>>>> Thanks .
> >>>>>>
> >>>>>> -----Message d'origine-----
> >>>>>> De : Sunil Mohan Adapa [mailto:sunil@medhas.org]
> >>>>>> Envoyé : Monday, August 05, 2019 1:25 AM
> >>>>>> Ą : Chen-Yu Tsai
> >>>>>> Cc : Maxime Ripard; Martin Ayotte; linux-arm-kernel
> >>>>>> Objet : Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on
> >>>>>> A64-OLinuXino
> >>>>>>
> >>>>>> On 04/08/19 8:33 pm, Chen-Yu Tsai wrote:
> >>>>>>> On Fri, Aug 2, 2019 at 2:47 AM Sunil Mohan Adapa <sunil@medhas.org> wrote:
> >>>>>>>>
> >>>>>>>> On 01/08/19 6:49 am, Martin Ayotte wrote:
> >>>>>>>>> If my SOB could help here, I don't mind since I've done the commit
> >>>>>>>>> more than a year ago for Armbian ...
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Martin Ayotte <martinayotte@gmai.com>
> >>>>>>>>> Tested-by: Martin Ayotte <martinayotte@gmai.com>
> >>>>>>>> gmai.com is likely a typo.
> >>>>>>>>
> >>>>>>>>> On Wed, Jul 31, 2019 at 10:42 PM Chen-Yu Tsai <wens@csie.org
> >>>>>>>>>
> >>>>>>>>>> Thanks. The patch looks good overall. The authorship is a little
> >>>>>>>>>> confusing though. If it was initially done by Martin (CC-ed), then
> >>>>>>>>>> he should be the author, and we should get his Signed-off-by if
> >>>>>>>>>> possible.
> >>>>>>>>
> >>>>>>>> Martin is indeed the original author of the patch. Thank you for
> >>>>>> reviewing.
> >>>>>>>
> >>>>>>> I'd like to apply this patch with Martin as the author, if that's OK with
> >>>>>> you
> >>>>>>> both?
> >>>>>>
> >>>>>> That is completely okay with me.
> >>>>>
> >>>>> Applied for 5.4.
> >>>>>
> >>>>> I reordered the tags so they make more sense:
> >>>>>
> >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4&id=0834887732df5af41b59b2e4d530fc1f5478965f
> >>>>
> >>>> Sorry for being late on this, but it looks like the eMMC, NAND and SPI
> >>>> pins are conflicting on the A64-Olinuxino design.
> >>>>
> >>>> There's no configuration with a NAND, so we don't really need to worry
> >>>> about that, but if we merge this in the main DT, we'll prevent anyone
> >>>> from using that DT on an olinuxino with a SPI flash.
> >>>>
> >>>> I think we should just create emmc and SPI-flash variants of that DT.
> >>>
> >>> Actually they aren't. Olimex specifically uses eMMC modules that don't
> >>> use the data strobe line, so SPI can be used together.
> >>
> >> Ah, right.
> >>
> >> Still, this creates a precedent that I'm not really comfortable
> >> with. Three actually.
> >>
> >> Merging this in the main DT means three things:
> >> - We're not consistent anymore, including within the olinuxino
> >> boards only. A20 Olinuxino is pretty much in the same situation,
> >> yet we dealt with it differently.
> >> - This means that this will create a spurious device and report
> >> errors in the kernel message and whenever someone will try to
> >> access the device on boards that don't have it wired. This
> >> shouldn't happen and we really shouldn't expose devices that just
> >> aren't there, just like you don't have all the devices that are
> >> not connected on your USB connector.
> >> - Finally, this means that in order to keep it somewhat consistent,
> >> we would have to merge the SPI flash in the main DT too. This will
> >> prevent people without a SPI flash to use the SPI signals on the
> >> UEXT connector for something else, which again goes against the
> >> policy we've had for basically any other board.
> >
> > OK. Shall we back it out and figure out something else?
>
> I can try to help with alternate implementation with some guidance. I
> can also test any patches on an A64-OLinuXino model with eMMC. So, do we
> create a new -emmc.dts like in case of A20 OLinuXino?
>
> BTW, a basic question: how does u-boot know which variant of dtb (with
> -emmc or without) it has load before booting Linux? Does this need to be
> hardcoded now into the boot script? Currently, in Debian the DTB name is
> chosen by u-boot and not present in the boot script.
The default name is set using Kconfig. It is present in the per-board
defconfig files.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] arm64: mm: print hexadecimal EC value in mem_abort_decode()
From: Miles Chen @ 2019-08-08 6:58 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, wsd_upstream, Catalin Marinas, Will Deacon,
linux-kernel, linux-mediatek, James Morse, linux-arm-kernel
In-Reply-To: <256df022-6ad2-bae8-cc94-908adf409a07@arm.com>
On Thu, 2019-08-08 at 11:51 +0530, Anshuman Khandual wrote:
>
> On 08/08/2019 11:31 AM, Miles Chen wrote:
> > On Thu, 2019-08-08 at 11:19 +0530, Anshuman Khandual wrote:
> >>
> >> On 08/07/2019 06:03 AM, Miles Chen wrote:
> >>> This change prints the hexadecimal EC value in mem_abort_decode(),
> >>> which makes it easier to lookup the corresponding EC in
> >>> the ARM Architecture Reference Manual.
> >>>
> >>> The commit 1f9b8936f36f ("arm64: Decode information from ESR upon mem
> >>> faults") prints useful information when memory abort occurs. It would
> >>> be easier to lookup "0x25" instead of "DABT" in the document. Then we
> >>> can check the corresponding ISS.
> >>>
> >>> For example:
> >>> Current info Document
> >>> EC Exception class
> >>> "CP15 MCR/MRC" 0x3 "MCR or MRC access to CP15a..."
> >>> "ASIMD" 0x7 "Access to SIMD or floating-point..."
> >>> "DABT (current EL)" 0x25 "Data Abort taken without..."
> >>> ...
> >>>
> >>> Before:
> >>> Unable to handle kernel paging request at virtual address 000000000000c000
> >>> Mem abort info:
> >>> ESR = 0x96000046
> >>> Exception class = DABT (current EL), IL = 32 bits
> >>> SET = 0, FnV = 0
> >>> EA = 0, S1PTW = 0
> >>> Data abort info:
> >>> ISV = 0, ISS = 0x00000046
> >>> CM = 0, WnR = 1
> >>>
> >>> After:
> >>> Unable to handle kernel paging request at virtual address 000000000000c000
> >>> Mem abort info:
> >>> ESR = 0x96000046
> >>> EC = 0x25: DABT (current EL), IL = 32 bits
> >>> SET = 0, FnV = 0
> >>> EA = 0, S1PTW = 0
> >>> Data abort info:
> >>> ISV = 0, ISS = 0x00000046
> >>> CM = 0, WnR = 1
> >>>
> >>> Change since v1:
> >>> print "EC" instead of "Exception class"
> >>> print EC in fixwidth
> >>>
> >>> Cc: Mark Rutland <Mark.rutland@arm.com>
> >>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
> >>> Cc: James Morse <james.morse@arm.com>
> >>> Signed-off-by: Miles Chen <miles.chen@mediatek.com>
> >>
> >> This version implements the suggestion, hence it should have
> >> also contained acked-by tag from Mark from earlier version.
> >>
> >
> > No problem. Sorry for not including the tag.
> > I was not sure if I should add the acked-by tag from Mark in patch v2.
>
> Yeah because V2 has now implemented the suggestion as required for
> getting the tag per Mark in V1.
>
Understood. thanks for the explanation
> >
> >> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> >
> > If I send patch v3, I should include acked-by tag from Mark and
> > Reviewed-by tag from you, right?
>
> Right.
_______________________________________________
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] arm64: mm: add missing PTE_SPECIAL in pte_mkdevmap on arm64
From: Anshuman Khandual @ 2019-08-08 6:58 UTC (permalink / raw)
To: Justin He (Arm Technology China), Catalin Marinas, Will Deacon,
Mark Rutland, James Morse
Cc: Logan Gunthorpe, Christoph Hellwig, Dan Williams,
Christoffer Dall, linux-kernel@vger.kernel.org, Jun Yao,
linux-mm@kvack.org, Jérôme Glisse, Qian Cai,
Punit Agrawal, Thomas Gleixner, Robin Murphy, Alex Van Brunt,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB7PR08MB30823791749E5B083AF167B5F7D70@DB7PR08MB3082.eurprd08.prod.outlook.com>
On 08/08/2019 11:50 AM, Justin He (Arm Technology China) wrote:
> Hi Anshuman
> Thanks for the comments, please see my comments below
>
>> -----Original Message-----
>> From: Anshuman Khandual <anshuman.khandual@arm.com>
>> Sent: 2019年8月8日 13:19
>> To: Justin He (Arm Technology China) <Justin.He@arm.com>; Catalin
>> Marinas <Catalin.Marinas@arm.com>; Will Deacon <will@kernel.org>;
>> Mark Rutland <Mark.Rutland@arm.com>; James Morse
>> <James.Morse@arm.com>
>> Cc: Christoffer Dall <Christoffer.Dall@arm.com>; Punit Agrawal
>> <punitagrawal@gmail.com>; Qian Cai <cai@lca.pw>; Jun Yao
>> <yaojun8558363@gmail.com>; Alex Van Brunt <avanbrunt@nvidia.com>;
>> Robin Murphy <Robin.Murphy@arm.com>; Thomas Gleixner
>> <tglx@linutronix.de>; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org
>> Subject: Re: [PATCH] arm64: mm: add missing PTE_SPECIAL in
>> pte_mkdevmap on arm64
>>
> [...]
>>> diff --git a/arch/arm64/include/asm/pgtable.h
>> b/arch/arm64/include/asm/pgtable.h
>>> index 5fdcfe237338..e09760ece844 100644
>>> --- a/arch/arm64/include/asm/pgtable.h
>>> +++ b/arch/arm64/include/asm/pgtable.h
>>> @@ -209,7 +209,7 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
>>>
>>> static inline pte_t pte_mkdevmap(pte_t pte)
>>> {
>>> - return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
>>> + return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL));
>>> }
>>>
>>> static inline void set_pte(pte_t *ptep, pte_t pte)
>>> @@ -396,7 +396,10 @@ static inline int pmd_protnone(pmd_t pmd)
>>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>> #define pmd_devmap(pmd) pte_devmap(pmd_pte(pmd))
>>> #endif
>>> -#define pmd_mkdevmap(pmd)
>> pte_pmd(pte_mkdevmap(pmd_pte(pmd)))
>>> +static inline pmd_t pmd_mkdevmap(pmd_t pmd)
>>> +{
>>> + return pte_pmd(set_pte_bit(pmd_pte(pmd),
>> __pgprot(PTE_DEVMAP)));
>>> +}
>>
>> Though I could see other platforms like powerpc and x86 following same
>> approach (DEVMAP + SPECIAL) for pte so that it checks positive for
>> pte_special() but then just DEVMAP for pmd which could never have a
>> pmd_special(). But a more fundamental question is - why should a devmap
>> be a special pte as well ?
>
> IIUC, special pte bit make things handling easier compare with those arches which
> have no special bit. The memory codes will regard devmap page as a special one
> compared with normal page.
For that we have PTE_DEVMAP on arm64 which differentiates device memory
entries from others and it should not again need PTE_SPECIAL as well for
that. We set both bits while creating the entries with pte_mkdevmap()
and check just one bit PTE_DEVMAP with pte_devmap(). Problem is it will
also test positive for pte_special() and risks being identified as one.
> Devmap page structure can be stored in ram/pmem/none.
That is altogether a different aspect which is handled with vmem_altmap
during hotplug and nothing to do with how device memory is mapped in the
page table. I am not sure about "none" though. IIUC unlike traditional
device pfn all ZONE_DEVICE memory will have struct page backing either
on system RAM or in the device memory itself.
>
>>
>> Also in vm_normal_page() why cannot it tests for pte_devmap() before it
>> starts looking for CONFIG_ARCH_HAS_PTE_SPECIAL. Is this the only path
>> for
>
> AFAICT, yes, but it changes to much besides arm codes. 😊
If this is the only path for which all platforms have to set PTE_SPECIAL
in their device mapping, then it should just be fixed in vm_normal_page().
>
>> which we need to set SPECIAL bit on a devmap pte or there are other paths
>> where this semantics is assumed ?
>
> No idea
Probably something to be asked in the mm community.
1. Why pte_mkdevmap() should set SPECIAL bit for a positive pte_special()
check. Why the same mapping be identified as pte_devmap() as well as
pte_special().
2. Can pte_devmap() and pte_special() re-ordering at vm_normal_page() will
remove this dependency or there are other commons MM paths which assume
this behavior ?
+ linux-mm@kvack.org <linux-mm@kvack.org>
+ Dan Williams <dan.j.williams@intel.com>
+ Jérôme Glisse <jglisse@redhat.com>
+ Logan Gunthorpe <logang@deltatee.com>
+ Christoph Hellwig <hch@lst.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 3/4] drm/mediatek: add mt8183 dpi clock factor
From: CK Hu @ 2019-08-08 7:14 UTC (permalink / raw)
To: Jitao Shi
Cc: Mark Rutland, devicetree, David Airlie, stonea168, dri-devel,
yingjoe.chen, Ajay Kumar, Vincent Palatin, cawa.cheng,
bibby.hsieh, Russell King, Thierry Reding, linux-pwm,
Sascha Hauer, Pawel Moll, Ian Campbell, Inki Dae, Rob Herring,
linux-mediatek, Andy Yan, Matthias Brugger, eddie.huang,
linux-arm-kernel, Rahul Sharma, srv_heupstream, linux-kernel,
Philipp Zabel, Sean Paul
In-Reply-To: <20190807060257.57007-4-jitao.shi@mediatek.com>
Hi, Jitao:
On Wed, 2019-08-07 at 14:02 +0800, Jitao Shi wrote:
> The factor depends on the divider of DPI in MT8183, therefore,
> we should fix this factor to the right and new one.
>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 743230864ba0..4f2700cbfdb7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -672,6 +672,16 @@ static unsigned int mt2701_calculate_factor(int clock)
> return 1;
> }
>
> +static unsigned int mt8183_calculate_factor(int clock)
> +{
> + if (clock <= 27000)
> + return 8;
> + else if (clock <= 167000)
> + return 4;
> + else
> + return 2;
> +}
> +
> static const struct mtk_dpi_conf mt8173_conf = {
> .cal_factor = mt8173_calculate_factor,
> .reg_h_fre_con = 0xe0,
> @@ -683,6 +693,11 @@ static const struct mtk_dpi_conf mt2701_conf = {
> .edge_sel_en = true,
> };
>
> +static const struct mtk_dpi_conf mt8183_conf = {
> + .cal_factor = mt8183_calculate_factor,
> + .reg_h_fre_con = 0xe0,
> +};
> +
> static int mtk_dpi_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -779,6 +794,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
> { .compatible = "mediatek,mt8173-dpi",
> .data = &mt8173_conf,
> },
> + { .compatible = "mediatek,mt8183-dpi",
> + .data = &mt8183_conf,
> + },
> { },
> };
>
_______________________________________________
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] mfd: ab3100: no need to check return value of debugfs_create functions
From: Lee Jones @ 2019-08-08 7:32 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Linus Walleij, linux-kernel, linux-arm-kernel
In-Reply-To: <20190706164722.18766-1-gregkh@linuxfoundation.org>
On Sat, 06 Jul 2019, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/mfd/ab3100-core.c | 45 ++++++---------------------------------
> drivers/mfd/ab3100-otp.c | 21 ++++++------------
> 2 files changed, 13 insertions(+), 53 deletions(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] mfd: ab8500: no need to check return value of debugfs_create functions
From: Lee Jones @ 2019-08-08 7:32 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Linus Walleij, linux-kernel, linux-arm-kernel
In-Reply-To: <20190706164722.18766-2-gregkh@linuxfoundation.org>
On Sat, 06 Jul 2019, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/mfd/ab8500-debugfs.c | 324 +++++++++++------------------------
> 1 file changed, 98 insertions(+), 226 deletions(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] mfd: aat2870: no need to check return value of debugfs_create functions
From: Lee Jones @ 2019-08-08 7:32 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20190706164722.18766-3-gregkh@linuxfoundation.org>
On Sat, 06 Jul 2019, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/mfd/aat2870-core.c | 13 ++-----------
> include/linux/mfd/aat2870.h | 1 -
> 2 files changed, 2 insertions(+), 12 deletions(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Detecting AArch32 support from a AArch64 process in user space
From: Stefan Agner @ 2019-08-08 7:36 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Marc Zyngier, ynorov, will.deacon, suzuki.poulose
[resend this time with the correct mailing list address]
Hello,
I am trying to detect whether an ARMv8 system running in AArch64 state
supports AArch32 state from a user space process. The arm64_features[]
in
arch/arm64/kernel/cpufeature.c lists a CPU feature "32-bit EL0 Support".
However, afaik this CPU feature is not directly exposed to user-space.
The features do get printed in the kernel log, but that requires
privileges and only works directly after boot. There is
system_supports_32bit_el0() which is used in various places in the arm64
architecture code. One of the instances where I can make sense of from
user space is through the personality system call. One idea is to call
personality(PER_LINUX32). It would then return error code 22 in case
32-bit is not supported in user space. However, if successful this
changes the personality of the current process which might have side
effects which I do not want...?
I started to ask myself what PER_LINUX32 actually changes. From what I
can tell it only changes the behavior of /proc/cpuinfo? The personality
seems not to be applied automatically to 32-bit processes, so this is a
opt-in backward compatibility feature?
To be on the safe side, I was thinking about executing the system call
in a separate process. However, at that point I could also just execute
a statically linked AArch32 binary and see whether I get a "exec format
error". I guess this could then be either due to missing AArch32 CPU
support or the kernel not being compiled with 32-bit compatibility.
At last I was considering reading directly from the CPU. But from what I
understand the register used in the kernel to determine 32-bit
compatibility (ID_AA64PFR0_EL1) is not accessible by user space (due to
the suffix _EL1).
Any advice/thoughts on this topic?
--
Stefan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH 00/10] ARM: davinci: use the new clocksource driver
From: Bartosz Golaszewski @ 2019-08-08 7:41 UTC (permalink / raw)
To: Sekhar Nori
Cc: Bartosz Golaszewski, Linux Kernel Mailing List, Linux ARM,
Kevin Hilman
In-Reply-To: <9e5704a3-8169-1575-4027-61d36c5e39b4@ti.com>
śr., 7 sie 2019 o 21:28 Sekhar Nori <nsekhar@ti.com> napisał(a):
>
> On 05/08/19 1:59 PM, Bartosz Golaszewski wrote:
> > pon., 22 lip 2019 o 15:17 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
> >>
> >> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >>
> >> Sekhar,
> >>
> >> the following patches switch DaVinci to using the new clocksource driver which
> >> is now upstream. They are rebased on top of v5.3-rc1. Additionally the
> >> following two patches were reverted locally due to a regression in v5.3-rc1
> >> about which the relevant maintainers have been already notified:
> >>
> >> 2eef1399a866 modules: fix BUG when load module with rodata=n
> >> 93651f80dcb6 modules: fix compile error if don't have strict module rwx
> >>
> >> Bartosz Golaszewski (10):
> >> ARM: davinci: enable the clocksource driver for DT mode
> >> ARM: davinci: WARN_ON() if clk_get() fails
> >> ARM: davinci: da850: switch to using the clocksource driver
> >> ARM: davinci: da830: switch to using the clocksource driver
> >> ARM: davinci: move timer definitions to davinci.h
> >> ARM: davinci: dm355: switch to using the clocksource driver
> >> ARM: davinci: dm365: switch to using the clocksource driver
> >> ARM: davinci: dm644x: switch to using the clocksource driver
> >> ARM: davinci: dm646x: switch to using the clocksource driver
> >> ARM: davinci: remove legacy timer support
> >>
> >> arch/arm/Kconfig | 1 +
> >> arch/arm/mach-davinci/Makefile | 3 +-
> >> arch/arm/mach-davinci/da830.c | 45 +--
> >> arch/arm/mach-davinci/da850.c | 50 +--
> >> arch/arm/mach-davinci/davinci.h | 3 +
> >> arch/arm/mach-davinci/devices-da8xx.c | 1 -
> >> arch/arm/mach-davinci/devices.c | 19 -
> >> arch/arm/mach-davinci/dm355.c | 28 +-
> >> arch/arm/mach-davinci/dm365.c | 26 +-
> >> arch/arm/mach-davinci/dm644x.c | 28 +-
> >> arch/arm/mach-davinci/dm646x.c | 28 +-
> >> arch/arm/mach-davinci/include/mach/common.h | 17 -
> >> arch/arm/mach-davinci/include/mach/time.h | 35 --
> >> arch/arm/mach-davinci/time.c | 414 --------------------
> >> 14 files changed, 110 insertions(+), 588 deletions(-)
> >> delete mode 100644 arch/arm/mach-davinci/include/mach/time.h
> >> delete mode 100644 arch/arm/mach-davinci/time.c
> >>
> >> --
> >> 2.21.0
> >>
> >
> > Hi Sekhar,
> >
> > a gentle ping. Is this series good to go in for v5.4?
>
> Hi Bartosz, a quick test shows that DM365 fails to boot after this. Can
> you please see if there is anything obviously wrong for that SoC. Rest
> seems to be okay.
>
> Thanks,
> Sekhar
Hi Sekhar,
just verified on Kevin's dm365-evm rebased on top of v5.3-rc3 and it
boots fine. I know that davinci failed to boot at v5.3-rc1.
Let me know if I can help with debugging.
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] pinctrl: freescale: imx: Add of_node_put() before return
From: Nishka Dasgupta @ 2019-08-08 7:47 UTC (permalink / raw)
To: aisheng.dong, festevam, shawnguo, stefan, kernel, linus.walleij,
s.hauer, linux-imx, linux-gpio, linux-arm-kernel
Cc: Nishka Dasgupta
Each iteration of for_each_child_of_node() puts the previous node;
however, in the case of a return from the middle of the loop, there is no
put, thus causing a memory leak. Hence put of_node_put() statements as
required before two mid-loop return statements.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
---
drivers/pinctrl/freescale/pinctrl-imx.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c b/drivers/pinctrl/freescale/pinctrl-imx.c
index 83ff9532bae6..9f42036c5fbb 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -672,8 +672,10 @@ static int imx_pinctrl_parse_functions(struct device_node *np,
grp = devm_kzalloc(ipctl->dev, sizeof(struct group_desc),
GFP_KERNEL);
- if (!grp)
+ if (!grp) {
+ of_node_put(child);
return -ENOMEM;
+ }
mutex_lock(&ipctl->mutex);
radix_tree_insert(&pctl->pin_group_tree,
@@ -697,12 +699,17 @@ static bool imx_pinctrl_dt_is_flat_functions(struct device_node *np)
struct device_node *pinctrl_np;
for_each_child_of_node(np, function_np) {
- if (of_property_read_bool(function_np, "fsl,pins"))
+ if (of_property_read_bool(function_np, "fsl,pins")) {
+ of_node_put(function_np);
return true;
+ }
for_each_child_of_node(function_np, pinctrl_np) {
- if (of_property_read_bool(pinctrl_np, "fsl,pins"))
+ if (of_property_read_bool(pinctrl_np, "fsl,pins")) {
+ of_node_put(pinctrl_np);
+ of_node_put(function_np);
return false;
+ }
}
}
--
2.19.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
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