* Re: [PATCH v2 2/4] dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
From: Rob Herring @ 2020-05-29 22:22 UTC (permalink / raw)
To: Florian Fainelli
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Scott Branden, Geert Uytterhoeven, Ray Jui, Linus Walleij,
Matti Vaittinen, linux-kernel, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200529191522.27938-3-f.fainelli@gmail.com>
On Fri, 29 May 2020 12:15:20 -0700, Florian Fainelli wrote:
> BCM7211 supports wake-up interrupts in the form of optional interrupt
> lines, one per bank, plus the "all banks" interrupt line.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> .../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 01/20] dt-bindings: mtd: Document nand-ecc-placement
From: Rob Herring @ 2020-05-29 22:21 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Boris Brezillon, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200529002517.3546-2-miquel.raynal@bootlin.com>
On Fri, May 29, 2020 at 02:24:58AM +0200, Miquel Raynal wrote:
> This optional property defines where the ECC bytes are expected to be
> stored. No value defaults to an unknown location, while these
> locations can be explicitly set to OOB or interleaved depending if
> the ECC bytes are entirely stored in the OOB area or mixed with
> regular data in the main area (also sometimes referred as
> "syndrome").
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> .../devicetree/bindings/mtd/nand-controller.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> index d261b7096c69..4a0798247d2d 100644
> --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> @@ -56,6 +56,16 @@ patternProperties:
> (Linux will handle the calculations). soft_bch is deprecated
> and should be replaced by soft and nand-ecc-algo.
>
> + nand-ecc-placement:
> + allOf:
You can drop using allOf now, but it still works as is.
Acked-by: Rob Herring <robh@kernel.org>
> + - $ref: /schemas/types.yaml#/definitions/string
> + - enum: [ oob, interleaved ]
> + description:
> + Location of the ECC bytes. This location is unknown by default
> + but can be explicitly set to "oob", if all ECC bytes are
> + known to be stored in the OOB area, or "interleaved" if ECC
> + bytes will be interleaved with regular data in the main area.
> +
> nand-ecc-algo:
> allOf:
> - $ref: /schemas/types.yaml#/definitions/string
> --
> 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
* Re: [PATCH] [v2] ARM: omap2: fix omap5_realtime_timer_init definition
From: Tony Lindgren @ 2020-05-29 22:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Santosh Shilimkar, linux-kernel, Tero Kristo, Olof Johansson,
linux-omap, linux-arm-kernel
In-Reply-To: <20200529220029.589078-1-arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [200529 22:01]:
> There is one more regression introduced by the last build fix:
>
> arch/arm/mach-omap2/timer.c:170:6: error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
> void __init omap5_realtime_timer_init(void)
> ^
> arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
> static inline void omap5_realtime_timer_init(void)
> ^
> arch/arm/mach-omap2/timer.c:170:13: error: redefinition of 'omap5_realtime_timer_init'
> void __init omap5_realtime_timer_init(void)
> ^
> arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
> static inline void omap5_realtime_timer_init(void)
>
> As it turns out, the CONFIG_SOC_HAS_REALTIME_COUNTER option
> should never be disabled for OMAP5 as we realy on this to initialize
> the clocks and the timer. Just remove it here and make it the default.
>
> Removing the guard around the set_cntfreq() definition, I noticed that
> this is not properly namespaced, so fix that as well.
Looks good to me, thanks for fixing it:
Acked-by: Tony Lindgren <tony@atomide.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] [v2] ARM: omap2: fix omap5_realtime_timer_init definition
From: Arnd Bergmann @ 2020-05-29 21:59 UTC (permalink / raw)
To: Tony Lindgren, Arnd Bergmann
Cc: Santosh Shilimkar, linux-kernel, Tero Kristo, Olof Johansson,
linux-omap, linux-arm-kernel
There is one more regression introduced by the last build fix:
arch/arm/mach-omap2/timer.c:170:6: error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
void __init omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
static inline void omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/timer.c:170:13: error: redefinition of 'omap5_realtime_timer_init'
void __init omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
static inline void omap5_realtime_timer_init(void)
As it turns out, the CONFIG_SOC_HAS_REALTIME_COUNTER option
should never be disabled for OMAP5 as we realy on this to initialize
the clocks and the timer. Just remove it here and make it the default.
Removing the guard around the set_cntfreq() definition, I noticed that
this is not properly namespaced, so fix that as well.
Fixes: d86ad463d670 ("ARM: OMAP2+: Fix regression for using local timer on non-SMP SoCs")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I'll let this run randconfig builds overnight to be sure it doesn't
cause another regression.
---
arch/arm/mach-omap2/Kconfig | 5 -----
arch/arm/mach-omap2/common.h | 6 ------
arch/arm/mach-omap2/omap-secure.h | 9 +--------
arch/arm/mach-omap2/omap-smp.c | 2 +-
arch/arm/mach-omap2/timer.c | 14 ++------------
5 files changed, 4 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ca74473f01df..87fb4df4cf72 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -145,11 +145,6 @@ config ARCH_OMAP2PLUS_TYPICAL
config SOC_HAS_OMAP2_SDRC
bool "OMAP2 SDRAM Controller support"
-config SOC_HAS_REALTIME_COUNTER
- bool "Real time free running counter"
- depends on SOC_OMAP5 || SOC_DRA7XX
- default y
-
config POWER_AVS_OMAP
bool "AVS(Adaptive Voltage Scaling) support for OMAP IP versions 1&2"
depends on POWER_AVS && (ARCH_OMAP3 || ARCH_OMAP4) && PM
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 49926eced5f1..70e3d6df4cb6 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -112,13 +112,7 @@ static inline int omap_l2_cache_init(void)
#define omap4_l2c310_write_sec NULL
#endif
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
extern void omap5_realtime_timer_init(void);
-#else
-static inline void omap5_realtime_timer_init(void)
-{
-}
-#endif
void omap2420_init_early(void);
void omap2430_init_early(void);
diff --git a/arch/arm/mach-omap2/omap-secure.h b/arch/arm/mach-omap2/omap-secure.h
index 4aaa95706d39..fbc02bb639c4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -81,14 +81,7 @@ extern u32 rx51_secure_rng_call(u32 ptr, u32 count, u32 flag);
extern bool optee_available;
void omap_secure_init(void);
-
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
-void set_cntfreq(void);
-#else
-static inline void set_cntfreq(void)
-{
-}
-#endif
+void omap5_set_cntfreq(void);
#endif /* __ASSEMBLER__ */
#endif /* OMAP_ARCH_OMAP_SECURE_H */
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 570a987e6d1a..f35d5642122a 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -162,7 +162,7 @@ static void omap4_secondary_init(unsigned int cpu)
* Configure the CNTFRQ register for the secondary cpu's which
* indicates the frequency of the cpu local timers.
*/
- set_cntfreq();
+ omap5_set_cntfreq();
/* Configure ACR to disable streaming WA for 801819 */
omap5_erratum_workaround_801819();
/* Enable ACR to allow for ICUALLU workaround */
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c1737e737a94..9b7b1240de81 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -39,11 +39,9 @@
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
#define NUMERATOR_DENUMERATOR_MASK 0xfffff000
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
-
static unsigned long arch_timer_freq;
-void set_cntfreq(void)
+void omap5_set_cntfreq(void)
{
omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
}
@@ -154,19 +152,11 @@ static void __init realtime_counter_init(void)
writel_relaxed(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
arch_timer_freq = DIV_ROUND_UP_ULL(rate * num, den);
- set_cntfreq();
+ omap5_set_cntfreq();
iounmap(base);
}
-#else
-
-static inline void realtime_counter_init(void)
-{
-}
-
-#endif /* CONFIG_SOC_HAS_REALTIME_COUNTER */
-
void __init omap5_realtime_timer_init(void)
{
omap_clk_init();
--
2.26.2
_______________________________________________
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] ARM: omap2: fix omap5_realtime_timer_init definition
From: Tony Lindgren @ 2020-05-29 21:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: santosh.shilimkar, linux-kernel@vger.kernel.org, Stefan Agner,
SoC Team, Olof Johansson, linux-omap, Linux ARM
In-Reply-To: <CAK8P3a0oK-SqWHR9v0-2p3Fd_mCe2ibP_SQKf_W2A6cbEzVgWw@mail.gmail.com>
* Arnd Bergmann <arnd@arndb.de> [200529 21:41]:
> On Fri, May 29, 2020 at 11:14 PM Tony Lindgren <tony@atomide.com> wrote:
> > * Arnd Bergmann <arnd@arndb.de> [200529 21:09]:
> > >
> > > #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
> > > extern void omap5_realtime_timer_init(void);
> > > #else
> > > static inline void omap5_realtime_timer_init(void)
> > > {
> > > }
> > > #endif
> > >
> > > In fact, the inline stub is what that caused the regression,
> > > so I think it's ok with my patch.
> >
> > To me it seems not having SOC_HAS_REALTIME_COUNTER will
> > cause omap5_realtime_timer_init() not get called?
>
> Correct, this looked to me like it was the intention of that
> symbol. Unfortunately there is no help text but it is user
> selectable:
>
> config SOC_HAS_REALTIME_COUNTER
> bool "Real time free running counter"
> depends on SOC_OMAP5 || SOC_DRA7XX
> default y
Maybe this is a legacy Kconfig option since Santosh got
the cpuidle coupled to switch things to using the always on
timers for idle modes years ago already.
> > That initializes clocks and calls timer_probe(). So this
> > will result in non-booting system AFAIK, the header
> > file stub should no rely CONFIG_SOC_HAS_REALTIME_COUNTER
> > also, but rather ! CONFIG_SOC_OMAP5 || CONFIG_SOC_DRA7XX.
> >
> > Also the Makefile change at least seems wrong, that
> > can't rely on CONFIG_SOC_HAS_REALTIME_COUNTER.
>
> How about just removing the prompt on
> CONFIG_SOC_HAS_REALTIME_COUNTER but keeping the
> rest of my patch? That way it's just always enabled when
> there is a chip that needs it enabled in the kernel config.
>
> The only other usage of the symbol is
>
> #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
> void set_cntfreq(void);
> #else
> static inline void set_cntfreq(void)
> {
> }
> #endif
Yeah it's already default y, so I'd say let's just get
rid of the option.
> Alternatively, we could just remove the Kconfig symbol
> altogether and rely on (SOC_OMAP5 || SOC_DRA7XX)
> everywhere, but that seems a little more fragile in case
> there is going to be another chip that needs it.
Sounds like we can just remove CONFIG_SOC_HAS_REALTIME_COUNTER
and rely on (SOC_OMAP5 || SOC_DRA7XX).
Regards,
Tony
_______________________________________________
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 1/4] dt-bindings: pinctrl: Document 7211 compatible for brcm, bcm2835-gpio.txt
From: Rob Herring @ 2020-05-29 21:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Scott Branden,
open list:PIN CONTROL SUBSYSTEM, Ray Jui, Linus Walleij,
Matti Vaittinen, linux-kernel, Nicolas Saenz Julienne,
Rob Herring,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200529191522.27938-2-f.fainelli@gmail.com>
On Fri, 29 May 2020 12:15:19 -0700, Florian Fainelli wrote:
> Document the brcm,bcm7211-gpio compatible string in the
> brcm,bcm2835-gpio.txt document.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
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] ARM: omap2: fix omap5_realtime_timer_init definition
From: Arnd Bergmann @ 2020-05-29 21:39 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-kernel@vger.kernel.org, Stefan Agner, SoC Team,
Olof Johansson, linux-omap, Linux ARM
In-Reply-To: <20200529211440.GX37466@atomide.com>
On Fri, May 29, 2020 at 11:14 PM Tony Lindgren <tony@atomide.com> wrote:
> * Arnd Bergmann <arnd@arndb.de> [200529 21:09]:
> >
> > #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
> > extern void omap5_realtime_timer_init(void);
> > #else
> > static inline void omap5_realtime_timer_init(void)
> > {
> > }
> > #endif
> >
> > In fact, the inline stub is what that caused the regression,
> > so I think it's ok with my patch.
>
> To me it seems not having SOC_HAS_REALTIME_COUNTER will
> cause omap5_realtime_timer_init() not get called?
Correct, this looked to me like it was the intention of that
symbol. Unfortunately there is no help text but it is user
selectable:
config SOC_HAS_REALTIME_COUNTER
bool "Real time free running counter"
depends on SOC_OMAP5 || SOC_DRA7XX
default y
> That initializes clocks and calls timer_probe(). So this
> will result in non-booting system AFAIK, the header
> file stub should no rely CONFIG_SOC_HAS_REALTIME_COUNTER
> also, but rather ! CONFIG_SOC_OMAP5 || CONFIG_SOC_DRA7XX.
>
> Also the Makefile change at least seems wrong, that
> can't rely on CONFIG_SOC_HAS_REALTIME_COUNTER.
How about just removing the prompt on
CONFIG_SOC_HAS_REALTIME_COUNTER but keeping the
rest of my patch? That way it's just always enabled when
there is a chip that needs it enabled in the kernel config.
The only other usage of the symbol is
#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
void set_cntfreq(void);
#else
static inline void set_cntfreq(void)
{
}
#endif
Alternatively, we could just remove the Kconfig symbol
altogether and rely on (SOC_OMAP5 || SOC_DRA7XX)
everywhere, but that seems a little more fragile in case
there is going to be another chip that needs it.
Arnd
_______________________________________________
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 v4 18/26] arm64: mte: Add PTRACE_{PEEK,POKE}MTETAGS support
From: Luis Machado @ 2020-05-29 21:25 UTC (permalink / raw)
To: Catalin Marinas, linux-arm-kernel
Cc: linux-arch, Omair Javaid, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Peter Collingbourne, linux-mm, Alan Hayward,
Vincenzo Frascino, Will Deacon, Dave P Martin
In-Reply-To: <20200515171612.1020-19-catalin.marinas@arm.com>
Hi Catalin,
I have a question about siginfo MTE information. I suppose SEGV_MTESERR
will be the most useful setting for debugging, right? Does si_addr
contain the tagged pointer with the logical tag, a zero-tagged memory
address or a tagged pointer with the allocation tag?
From the debugger user's perspective, one would want to see both the
logical tag and the allocation tag. And it would be handy to have both
available in siginfo. Does that make sense?
Also, when would we see SEGV_MTEAERR, for example? That would provide no
additional information about a particular memory address, which is not
that useful for the debugger.
Thanks,
Luis
On 5/15/20 2:16 PM, Catalin Marinas wrote:
> Add support for bulk setting/getting of the MTE tags in a tracee's
> address space at 'addr' in the ptrace() syscall prototype. 'data' points
> to a struct iovec in the tracer's address space with iov_base
> representing the address of a tracer's buffer of length iov_len. The
> tags to be copied to/from the tracer's buffer are stored as one tag per
> byte.
>
> On successfully copying at least one tag, ptrace() returns 0 and updates
> the tracer's iov_len with the number of tags copied. In case of error,
> either -EIO or -EFAULT is returned, trying to follow the ptrace() man
> page.
>
> Note that the tag copying functions are not performance critical,
> therefore they lack optimisations found in typical memory copy routines.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Alan Hayward <Alan.Hayward@arm.com>
> Cc: Luis Machado <luis.machado@linaro.org>
> Cc: Omair Javaid <omair.javaid@linaro.org>
> ---
>
> Notes:
> v4:
> - Following the change to only clear the tags in a page if it is mapped
> to user with PROT_MTE, ptrace() now will refuse to access tags in
> pages not previously mapped with PROT_MTE (PG_mte_tagged set). This is
> primarily to avoid leaking uninitialised tags to user via ptrace().
> - Fix SYM_FUNC_END argument typo.
> - Rename MTE_ALLOC_* to MTE_GRANULE_*.
> - Use uao_user_alternative for the user access in case we ever want to
> call mte_copy_tags_* with a kernel buffer. It also matches the other
> uaccess routines in the kernel.
> - Simplify arch_ptrace() slightly.
> - Reorder down_write_killable() with access_ok() in
> __access_remote_tags().
> - Handle copy length 0 in mte_copy_tags_{to,from}_user().
> - Use put_user() instead of __put_user().
>
> New in v3.
>
> arch/arm64/include/asm/mte.h | 17 ++++
> arch/arm64/include/uapi/asm/ptrace.h | 3 +
> arch/arm64/kernel/mte.c | 139 +++++++++++++++++++++++++++
> arch/arm64/kernel/ptrace.c | 7 ++
> arch/arm64/lib/mte.S | 53 ++++++++++
> 5 files changed, 219 insertions(+)
>
> diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
> index 7435f6619bf1..9d4b1390d07d 100644
> --- a/arch/arm64/include/asm/mte.h
> +++ b/arch/arm64/include/asm/mte.h
> @@ -5,6 +5,11 @@
> #ifndef __ASM_MTE_H
> #define __ASM_MTE_H
>
> +#define MTE_GRANULE_SIZE UL(16)
> +#define MTE_GRANULE_MASK (~(MTE_GRANULE_SIZE - 1))
> +#define MTE_TAG_SHIFT 56
> +#define MTE_TAG_SIZE 4
> +
> #ifndef __ASSEMBLY__
>
> #include <linux/page-flags.h>
> @@ -12,6 +17,10 @@
> #include <asm/pgtable-types.h>
>
> void mte_clear_page_tags(void *addr, size_t size);
> +unsigned long mte_copy_tags_from_user(void *to, const void __user *from,
> + unsigned long n);
> +unsigned long mte_copy_tags_to_user(void __user *to, void *from,
> + unsigned long n);
>
> #ifdef CONFIG_ARM64_MTE
>
> @@ -25,6 +34,8 @@ void mte_thread_switch(struct task_struct *next);
> void mte_suspend_exit(void);
> long set_mte_ctrl(unsigned long arg);
> long get_mte_ctrl(void);
> +int mte_ptrace_copy_tags(struct task_struct *child, long request,
> + unsigned long addr, unsigned long data);
>
> #else
>
> @@ -54,6 +65,12 @@ static inline long get_mte_ctrl(void)
> {
> return 0;
> }
> +static inline int mte_ptrace_copy_tags(struct task_struct *child,
> + long request, unsigned long addr,
> + unsigned long data)
> +{
> + return -EIO;
> +}
>
> #endif
>
> diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
> index 1daf6dda8af0..cd2a4a164de3 100644
> --- a/arch/arm64/include/uapi/asm/ptrace.h
> +++ b/arch/arm64/include/uapi/asm/ptrace.h
> @@ -67,6 +67,9 @@
> /* syscall emulation path in ptrace */
> #define PTRACE_SYSEMU 31
> #define PTRACE_SYSEMU_SINGLESTEP 32
> +/* MTE allocation tag access */
> +#define PTRACE_PEEKMTETAGS 33
> +#define PTRACE_POKEMTETAGS 34
>
> #ifndef __ASSEMBLY__
>
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index cda09bc8caf4..6abd6a16a145 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -4,14 +4,18 @@
> */
>
> #include <linux/bitops.h>
> +#include <linux/kernel.h>
> #include <linux/mm.h>
> #include <linux/prctl.h>
> #include <linux/sched.h>
> +#include <linux/sched/mm.h>
> #include <linux/string.h>
> #include <linux/thread_info.h>
> +#include <linux/uio.h>
>
> #include <asm/cpufeature.h>
> #include <asm/mte.h>
> +#include <asm/ptrace.h>
> #include <asm/sysreg.h>
>
> void mte_sync_tags(pte_t *ptep, pte_t pte)
> @@ -173,3 +177,138 @@ long get_mte_ctrl(void)
>
> return ret;
> }
> +
> +/*
> + * Access MTE tags in another process' address space as given in mm. Update
> + * the number of tags copied. Return 0 if any tags copied, error otherwise.
> + * Inspired by __access_remote_vm().
> + */
> +static int __access_remote_tags(struct task_struct *tsk, struct mm_struct *mm,
> + unsigned long addr, struct iovec *kiov,
> + unsigned int gup_flags)
> +{
> + struct vm_area_struct *vma;
> + void __user *buf = kiov->iov_base;
> + size_t len = kiov->iov_len;
> + int ret;
> + int write = gup_flags & FOLL_WRITE;
> +
> + if (!access_ok(buf, len))
> + return -EFAULT;
> +
> + if (down_read_killable(&mm->mmap_sem))
> + return -EIO;
> +
> + while (len) {
> + unsigned long tags, offset;
> + void *maddr;
> + struct page *page = NULL;
> +
> + ret = get_user_pages_remote(tsk, mm, addr, 1, gup_flags,
> + &page, &vma, NULL);
> + if (ret <= 0)
> + break;
> +
> + /*
> + * Only copy tags if the page has been mapped as PROT_MTE
> + * (PG_mte_tagged set). Otherwise the tags are not valid and
> + * not accessible to user. Moreover, an mprotect(PROT_MTE)
> + * would cause the existing tags to be cleared if the page
> + * was never mapped with PROT_MTE.
> + */
> + if (!test_bit(PG_mte_tagged, &page->flags)) {
> + ret = -EOPNOTSUPP;
> + put_page(page);
> + break;
> + }
> +
> + /* limit access to the end of the page */
> + offset = offset_in_page(addr);
> + tags = min(len, (PAGE_SIZE - offset) / MTE_GRANULE_SIZE);
> +
> + maddr = page_address(page);
> + if (write) {
> + tags = mte_copy_tags_from_user(maddr + offset, buf, tags);
> + set_page_dirty_lock(page);
> + } else {
> + tags = mte_copy_tags_to_user(buf, maddr + offset, tags);
> + }
> + put_page(page);
> +
> + /* error accessing the tracer's buffer */
> + if (!tags)
> + break;
> +
> + len -= tags;
> + buf += tags;
> + addr += tags * MTE_GRANULE_SIZE;
> + }
> + up_read(&mm->mmap_sem);
> +
> + /* return an error if no tags copied */
> + kiov->iov_len = buf - kiov->iov_base;
> + if (!kiov->iov_len) {
> + /* check for error accessing the tracee's address space */
> + if (ret <= 0)
> + return -EIO;
> + else
> + return -EFAULT;
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Copy MTE tags in another process' address space at 'addr' to/from tracer's
> + * iovec buffer. Return 0 on success. Inspired by ptrace_access_vm().
> + */
> +static int access_remote_tags(struct task_struct *tsk, unsigned long addr,
> + struct iovec *kiov, unsigned int gup_flags)
> +{
> + struct mm_struct *mm;
> + int ret;
> +
> + mm = get_task_mm(tsk);
> + if (!mm)
> + return -EPERM;
> +
> + if (!tsk->ptrace || (current != tsk->parent) ||
> + ((get_dumpable(mm) != SUID_DUMP_USER) &&
> + !ptracer_capable(tsk, mm->user_ns))) {
> + mmput(mm);
> + return -EPERM;
> + }
> +
> + ret = __access_remote_tags(tsk, mm, addr, kiov, gup_flags);
> + mmput(mm);
> +
> + return ret;
> +}
> +
> +int mte_ptrace_copy_tags(struct task_struct *child, long request,
> + unsigned long addr, unsigned long data)
> +{
> + int ret;
> + struct iovec kiov;
> + struct iovec __user *uiov = (void __user *)data;
> + unsigned int gup_flags = FOLL_FORCE;
> +
> + if (!system_supports_mte())
> + return -EIO;
> +
> + if (get_user(kiov.iov_base, &uiov->iov_base) ||
> + get_user(kiov.iov_len, &uiov->iov_len))
> + return -EFAULT;
> +
> + if (request == PTRACE_POKEMTETAGS)
> + gup_flags |= FOLL_WRITE;
> +
> + /* align addr to the MTE tag granule */
> + addr &= MTE_GRANULE_MASK;
> +
> + ret = access_remote_tags(child, addr, &kiov, gup_flags);
> + if (!ret)
> + ret = put_user(kiov.iov_len, &uiov->iov_len);
> +
> + return ret;
> +}
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 077e352495eb..c8bda5f5b321 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -34,6 +34,7 @@
> #include <asm/cpufeature.h>
> #include <asm/debug-monitors.h>
> #include <asm/fpsimd.h>
> +#include <asm/mte.h>
> #include <asm/pgtable.h>
> #include <asm/pointer_auth.h>
> #include <asm/stacktrace.h>
> @@ -1797,6 +1798,12 @@ const struct user_regset_view *task_user_regset_view(struct task_struct *task)
> long arch_ptrace(struct task_struct *child, long request,
> unsigned long addr, unsigned long data)
> {
> + switch (request) {
> + case PTRACE_PEEKMTETAGS:
> + case PTRACE_POKEMTETAGS:
> + return mte_ptrace_copy_tags(child, request, addr, data);
> + }
> +
> return ptrace_request(child, request, addr, data);
> }
>
> diff --git a/arch/arm64/lib/mte.S b/arch/arm64/lib/mte.S
> index a531b52fa5ba..862655a36013 100644
> --- a/arch/arm64/lib/mte.S
> +++ b/arch/arm64/lib/mte.S
> @@ -4,7 +4,9 @@
> */
> #include <linux/linkage.h>
>
> +#include <asm/alternative.h>
> #include <asm/assembler.h>
> +#include <asm/mte.h>
> #include <asm/page.h>
>
> .arch armv8.5-a+memtag
> @@ -40,3 +42,54 @@ SYM_FUNC_START(mte_copy_page_tags)
> b.ne 1b
> 2:
> SYM_FUNC_END(mte_copy_page_tags)
> +
> +/*
> + * Read tags from a user buffer (one tag per byte) and set the corresponding
> + * tags at the given kernel address. Used by PTRACE_POKEMTETAGS.
> + * x0 - kernel address (to)
> + * x1 - user buffer (from)
> + * x2 - number of tags/bytes (n)
> + * Returns:
> + * x0 - number of tags read/set
> + */
> +SYM_FUNC_START(mte_copy_tags_from_user)
> + mov x3, x1
> + cbz x2, 2f
> +1:
> + uao_user_alternative 2f, ldrb, ldtrb, w4, x1, 0
> + lsl x4, x4, #MTE_TAG_SHIFT
> + stg x4, [x0], #MTE_GRANULE_SIZE
> + add x1, x1, #1
> + subs x2, x2, #1
> + b.ne 1b
> +
> + // exception handling and function return
> +2: sub x0, x1, x3 // update the number of tags set
> + ret
> +SYM_FUNC_END(mte_copy_tags_from_user)
> +
> +/*
> + * Get the tags from a kernel address range and write the tag values to the
> + * given user buffer (one tag per byte). Used by PTRACE_PEEKMTETAGS.
> + * x0 - user buffer (to)
> + * x1 - kernel address (from)
> + * x2 - number of tags/bytes (n)
> + * Returns:
> + * x0 - number of tags read/set
> + */
> +SYM_FUNC_START(mte_copy_tags_to_user)
> + mov x3, x0
> + cbz x2, 2f
> +1:
> + ldg x4, [x1]
> + ubfx x4, x4, #MTE_TAG_SHIFT, #MTE_TAG_SIZE
> + uao_user_alternative 2f, strb, sttrb, w4, x0, 0
> + add x0, x0, #1
> + add x1, x1, #MTE_GRANULE_SIZE
> + subs x2, x2, #1
> + b.ne 1b
> +
> + // exception handling and function return
> +2: sub x0, x0, x3 // update the number of tags copied
> + ret
> +SYM_FUNC_END(mte_copy_tags_to_user)
>
_______________________________________________
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 0/8] Convert the intel iommu driver to the dma-iommu api
From: Logan Gunthorpe @ 2020-05-29 21:21 UTC (permalink / raw)
To: Marek Szyprowski, Christoph Hellwig
Cc: kvm, David Airlie, Joonas Lahtinen, dri-devel, Bjorn Andersson,
linux-tegra, Julien Grall, Thierry Reding, Will Deacon,
Jean-Philippe Brucker, linux-samsung-soc, Marc Zyngier,
Krzysztof Kozlowski, Jonathan Hunter, linux-rockchip, Andy Gross,
linux-arm-kernel, linux-s390, linux-arm-msm, intel-gfx,
Jani Nikula, Alex Williamson, linux-mediatek, Rodrigo Vivi,
Matthias Brugger, Thomas Gleixner, virtualization,
Gerald Schaefer, David Woodhouse, Cornelia Huck, linux-kernel,
Tom Murphy, iommu, Kukjin Kim, Robin Murphy
In-Reply-To: <ef2150d5-7b6a-df25-c10d-e43316fe7812@samsung.com>
On 2020-05-29 3:11 p.m., Marek Szyprowski wrote:
> Patches are pending:
> https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprowski@samsung.com/T/
Cool, nice! Though, I still don't think that fixes the issue in
i915_scatterlist.h given it still ignores sg_dma_len() and strictly
relies on sg_next()/sg_is_last() to stop iterating -- and I suspect this
is the bug that got in Tom's way.
>> However, as Robin pointed out, there are other ugly tricks like stopping
>> iterating through the SGL when sg_dma_len() is zero. For example, the
>> AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does
>> this trick and thus likely isn't buggy (otherwise, I'd expect someone to
>> have complained by now seeing AMD has already switched to IOMMU-DMA.
>
> I'm not sure that this is a trick. Stopping at zero sg_dma_len() was
> somewhere documented.
Well whatever you want to call it, it is ugly to have some drivers doing
one thing with the returned value and others assuming there's an extra
zero at the end. It just causes confusion for people reading/copying the
code. It would be better if they are all consistent. However, I concede
stopping at zero should not be broken, presently.
Logan
_______________________________________________
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 2/2] drivers: clk: zynqmp: Update fraction clock check from custom type flags
From: Jolly Shah @ 2020-05-29 21:20 UTC (permalink / raw)
To: Stephen Boyd, Jolly Shah, arm, linux-clk, michal.simek,
mturquette, olof
Cc: Tejas Patel, Rajan Vaja, rajanv, linux-kernel, linux-arm-kernel
In-Reply-To: <159070755756.69627.18401650656284023600@swboyd.mtv.corp.google.com>
Hi Stephan,
> ------Original Message------
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Thursday, May 28, 2020 4:12PM
> To: Jolly Shah <jolly.shah@xilinx.com>, Arm <arm@kernel.org>,
Linux-clk <linux-clk@vger.kernel.org>, Michal Simek
<michal.simek@xilinx.com>, Mturquette <mturquette@baylibre.com>, Olof
<olof@lixom.net>
> Cc: Rajan Vaja <rajanv@xilinx.com>,
Linux-arm-kernel@lists.infradead.org
<linux-arm-kernel@lists.infradead.org>, Linux-kernel@vger.kernel.org
<linux-kernel@vger.kernel.org>, Tejas Patel <tejas.patel@xilinx.com>,
Rajan Vaja <rajan.vaja@xilinx.com>
> Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction
clock check from custom type flags
>
> Quoting Jolly Shah (2020-05-28 10:44:01)
>> Hi Stephan,
>>
>> Thanks for the review.
>>
>> > ------Original Message------
>> > From: Stephen Boyd <sboyd@kernel.org>
>> > Sent: Tuesday, May 26, 2020 6:08PM
>> > To: Jolly Shah <jolly.shah@xilinx.com>, Arm <arm@kernel.org>,
>> Linux-clk <linux-clk@vger.kernel.org>, Michal Simek
>> <michal.simek@xilinx.com>, Mturquette <mturquette@baylibre.com>, Olof
>> <olof@lixom.net>
>> > Cc: Rajan Vaja <rajanv@xilinx.com>,
>> Linux-arm-kernel@lists.infradead.org
>> <linux-arm-kernel@lists.infradead.org>, Linux-kernel@vger.kernel.org
>> <linux-kernel@vger.kernel.org>, Tejas Patel <tejas.patel@xilinx.com>,
>> Rajan Vaja <rajan.vaja@xilinx.com>, Jolly Shah <jolly.shah@xilinx.com>
>> > Subject: Re: [PATCH v2 2/2] drivers: clk: zynqmp: Update fraction
>> clock check from custom type flags
>> >
>>> Quoting Jolly Shah (2020-03-12 14:31:39)
>>>> From: Tejas Patel <tejas.patel@xilinx.com>
>>>>
>>>> Older firmware version sets BIT(13) in clkflag to mark a
>>>> divider as fractional divider. Updated firmware version sets BIT(4)
>>>> in type flags to mark a divider as fractional divider since
>>>> BIT(13) is defined as CLK_DUTY_CYCLE_PARENT in the common clk
>>>> framework flags.
>>>>
>>>> To support both old and new firmware version, consider BIT(13) from
>>>> clkflag and BIT(4) from type_flag to check if divider is fractional
>>>> or not.
>>>>
>>>> To maintain compatibility BIT(13) of clkflag in firmware will not be
>>>> used in future for any purpose and will be marked as unused.
>>>
>>> Why are we mixing the firmware flags with the ccf flags? They shouldn't
>>> be the same. The firmware should have its own 'flag numberspace' that is
>>> distinct from the common clk framework's 'flag numberspace'. Please fix
>>> the code.
>>>
>>
>> Yes firmware flags are using separate numberspace now. Firmware
>> maintains CCF and firmware specific flags separately but earlier
>> CLK_FRAC was mistakenly defined in ccf flagspace and hence handled here
>> for backward compatibility. Driver takes care of not registering same
>> with CCF. Let me know if I misunderstood.
>
> Why is the firmware maintaining CCF specific flags? The firmware
> shouldn't know about the CCF flag numbering at all. We can change the
> numbers that the CCF flags are assigned to randomly and that shouldn't
> mean that the firmware needs to change. Maybe I should apply this patch?
Got it. Will fix it.
Thanks,
Jolly Shah
>
> ---8<----
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index bd1ee9039558..c1f36bca85b0 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -16,22 +16,22 @@
> *
> * Please update clk_flags[] in drivers/clk/clk.c when making changes here!
> */
> -#define CLK_SET_RATE_GATE BIT(0) /* must be gated across rate change */
> -#define CLK_SET_PARENT_GATE BIT(1) /* must be gated across re-parent */
> -#define CLK_SET_RATE_PARENT BIT(2) /* propagate rate change up one level */
> -#define CLK_IGNORE_UNUSED BIT(3) /* do not gate even if unused */
> +#define CLK_SET_RATE_GATE BIT(13) /* must be gated across rate change */
> +#define CLK_SET_PARENT_GATE BIT(2) /* must be gated across re-parent */
> +#define CLK_SET_RATE_PARENT BIT(3) /* propagate rate change up one level */
> +#define CLK_IGNORE_UNUSED BIT(4) /* do not gate even if unused */
> /* unused */
> /* unused */
> -#define CLK_GET_RATE_NOCACHE BIT(6) /* do not use the cached clk rate */
> -#define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
> -#define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy */
> -#define CLK_RECALC_NEW_RATES BIT(9) /* recalc rates after notifications */
> -#define CLK_SET_RATE_UNGATE BIT(10) /* clock needs to run to set rate */
> -#define CLK_IS_CRITICAL BIT(11) /* do not gate, ever */
> +#define CLK_GET_RATE_NOCACHE BIT(5) /* do not use the cached clk rate */
> +#define CLK_SET_RATE_NO_REPARENT BIT(6) /* don't re-parent on rate change */
> +#define CLK_GET_ACCURACY_NOCACHE BIT(7) /* do not use the cached clk accuracy */
> +#define CLK_RECALC_NEW_RATES BIT(8) /* recalc rates after notifications */
> +#define CLK_SET_RATE_UNGATE BIT(9) /* clock needs to run to set rate */
> +#define CLK_IS_CRITICAL BIT(10) /* do not gate, ever */
> /* parents need enable during gate/ungate, set rate and re-parent */
> -#define CLK_OPS_PARENT_ENABLE BIT(12)
> +#define CLK_OPS_PARENT_ENABLE BIT(11)
> /* duty cycle call may be forwarded to the parent clock */
> -#define CLK_DUTY_CYCLE_PARENT BIT(13)
> +#define CLK_DUTY_CYCLE_PARENT BIT(12)
>
> struct clk;
> struct clk_hw;
>
_______________________________________________
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 v3 04/25] clk: bcm: rpi: Allow the driver to be probed by DT
From: Stephen Boyd @ 2020-05-29 21:17 UTC (permalink / raw)
To: Maxime Ripard, Nicolas Saenz Julienne
Cc: Tim Gover, Dave Stevenson, Michael Turquette, linux-kernel,
linux-clk, bcm-kernel-feedback-list, linux-rpi-kernel,
Phil Elwell, linux-arm-kernel, Maxime Ripard
In-Reply-To: <fa709f71b27aadf987685f7cae2a65cc3cef8e3d.1590594293.git-series.maxime@cerno.tech>
Quoting Maxime Ripard (2020-05-27 08:45:00)
> The current firmware clock driver for the RaspberryPi can only be probed by
> manually registering an associated platform_device.
>
> While this works fine for cpufreq where the device gets attached a clkdev
> lookup, it would be tedious to maintain a table of all the devices using
> one of the clocks exposed by the firmware.
>
> Since the DT on the other hand is the perfect place to store those
> associations, make the firmware clocks driver probe-able through the device
> tree so that we can represent it as a node.
>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
_______________________________________________
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 v3 02/25] dt-bindings: clock: Add a binding for the RPi Firmware clocks
From: Stephen Boyd @ 2020-05-29 21:17 UTC (permalink / raw)
To: Maxime Ripard, Nicolas Saenz Julienne
Cc: devicetree, Tim Gover, Dave Stevenson, Michael Turquette,
linux-kernel, linux-clk, Rob Herring, bcm-kernel-feedback-list,
linux-rpi-kernel, Phil Elwell, linux-arm-kernel, Maxime Ripard
In-Reply-To: <919e2f2f13583d4d53d0e95b81fc3fb8a7606107.1590594293.git-series.maxime@cerno.tech>
Quoting Maxime Ripard (2020-05-27 08:44:58)
> The firmware running on the RPi VideoCore can be used to discover and
> change the various clocks running in the BCM2711. Since devices will
> need to use them through the DT, let's add a pretty simple binding.
>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index cec540c052b6..b48ed875eb8e 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -22,6 +22,25 @@ properties:
> Phandle to the firmware device's Mailbox.
> (See: ../mailbox/mailbox.txt for more information)
>
> + clocks:
> + type: object
> +
> + properties:
> + compatible:
> + const: raspberrypi,firmware-clocks
> +
> + "#clock-cells":
> + const: 1
> + description: >
Just curious if this is the same as the | syntax? I haven't seen this
used before.
> + The argument is the ID of the clocks contained by the
> + firmware messages.
> +
_______________________________________________
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] ARM: omap2: fix omap5_realtime_timer_init definition
From: Tony Lindgren @ 2020-05-29 21:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel@vger.kernel.org, Stefan Agner, SoC Team,
Olof Johansson, linux-omap, Linux ARM
In-Reply-To: <CAK8P3a1fEq6n1pBqkY4CqxpSZnMLOQsNHFyhB_L4uo-oZVu4sw@mail.gmail.com>
* Arnd Bergmann <arnd@arndb.de> [200529 21:09]:
> On Fri, May 29, 2020 at 10:44 PM Tony Lindgren <tony@atomide.com> wrote:
> >
> > * Arnd Bergmann <arnd@arndb.de> [200529 20:18]:
> > > There is one more regression introduced by the last build fix:
> >
> > Argh.. I did run make randconfig for like 10 builds
> > after the last fix.
> >
> > > Address this by removing the now obsolete #ifdefs in that file and
> > > just building the entire file based on the flag that controls the
> > > omap5_realtime_timer_init function declaration.
> >
> > I think this will introduce other randconfig build failures
> > as SOC_HAS_REALTIME_COUNTER is bool in Kconfig.
>
> I did a few hundred randconfig builds with the patch and have
> not yet seen any further problems.
Ah right, it works for randconfig builds now but won't boot :)
> > We still need to call omap5_realtime_timer_init() even if
> > SOC_HAS_REALTIME_COUNTER is not set.
>
> This is what's in the header file:
>
> #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
> extern void omap5_realtime_timer_init(void);
> #else
> static inline void omap5_realtime_timer_init(void)
> {
> }
> #endif
>
> In fact, the inline stub is what that caused the regression,
> so I think it's ok with my patch.
To me it seems not having SOC_HAS_REALTIME_COUNTER will
cause omap5_realtime_timer_init() not get called?
That initializes clocks and calls timer_probe(). So this
will result in non-booting system AFAIK, the header
file stub should no rely CONFIG_SOC_HAS_REALTIME_COUNTER
also, but rather ! CONFIG_SOC_OMAP5 || CONFIG_SOC_DRA7XX.
Also the Makefile change at least seems wrong, that
can't rely on CONFIG_SOC_HAS_REALTIME_COUNTER.
Regards,
Tony
_______________________________________________
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] cpufreq: brcmstb-avs-cpufreq: send S2_ENTER / S2_EXIT commands to AVS
From: Florian Fainelli @ 2020-05-29 21:13 UTC (permalink / raw)
To: Markus Mayer, Rafael J. Wysocki, Viresh Kumar, Florian Fainelli
Cc: Broadcom Kernel List, Linux Kernel Mailing List, ARM Kernel List,
Linux Power Management List
In-Reply-To: <20200528182014.20021-3-mmayer@broadcom.com>
On 5/28/20 11:20 AM, Markus Mayer wrote:
> On suspend we send AVS_CMD_S2_ENTER and on resume AVS_CMD_S2_EXIT.
> These are best effort calls, so we don't check the return code or take
> any action if either of the calls fails.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
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] cpufreq: brcmstb-avs-cpufreq: more flexible interface for __issue_avs_command()
From: Florian Fainelli @ 2020-05-29 21:13 UTC (permalink / raw)
To: Markus Mayer, Rafael J. Wysocki, Viresh Kumar, Florian Fainelli
Cc: Broadcom Kernel List, Linux Kernel Mailing List, ARM Kernel List,
Linux Power Management List
In-Reply-To: <20200528182014.20021-1-mmayer@broadcom.com>
On 5/28/20 11:20 AM, Markus Mayer wrote:
> We are changing how parameters are passed to __issue_avs_command(), so we
> can pass input *and* output arguments with the same command, rather than
> just one or the other.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
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 0/8] Convert the intel iommu driver to the dma-iommu api
From: Marek Szyprowski @ 2020-05-29 21:11 UTC (permalink / raw)
To: Logan Gunthorpe, Christoph Hellwig
Cc: kvm, David Airlie, Joonas Lahtinen, dri-devel, Bjorn Andersson,
linux-tegra, Julien Grall, Thierry Reding, Will Deacon,
Jean-Philippe Brucker, linux-samsung-soc, Marc Zyngier,
Krzysztof Kozlowski, Jonathan Hunter, linux-rockchip, Andy Gross,
linux-arm-kernel, linux-s390, linux-arm-msm, intel-gfx,
Jani Nikula, Alex Williamson, linux-mediatek, Rodrigo Vivi,
Matthias Brugger, Thomas Gleixner, virtualization,
Gerald Schaefer, David Woodhouse, Cornelia Huck, linux-kernel,
Tom Murphy, iommu, Kukjin Kim, Robin Murphy
In-Reply-To: <33137cfb-603c-86e8-1091-f36117ecfaf3@deltatee.com>
Hi Logan,
On 29.05.2020 21:05, Logan Gunthorpe wrote:
> On 2020-05-29 6:45 a.m., Christoph Hellwig wrote:
>> On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote:
>>>> This issue is most likely in the i915 driver and is most likely caused by the driver not respecting the return value of the dma_map_ops::map_sg function. You can see the driver ignoring the return value here:
>>>> https://protect2.fireeye.com/url?k=ca25a34b-97f7b813-ca242804-0cc47a31c8b4-0ecdffc9f56851e1&q=1&u=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fblob%2F7e0165b2f1a912a06e381e91f0f4e495f4ac3736%2Fdrivers%2Fgpu%2Fdrm%2Fi915%2Fgem%2Fi915_gem_dmabuf.c%23L51
>>>>
>>>> Previously this didn’t cause issues because the intel map_sg always returned the same number of elements as the input scatter gather list but with the change to this dma-iommu api this is no longer the case. I wasn’t able to track the bug down to a specific line of code unfortunately.
>> Mark did a big audit into the map_sg API abuse and initially had
>> some i915 patches, but then gave up on them with this comment:
>>
>> "The biggest TODO is DRM/i915 driver and I don't feel brave enough to fix
>> it fully. The driver creatively uses sg_table->orig_nents to store the
>> size of the allocate scatterlist and ignores the number of the entries
>> returned by dma_map_sg function. In this patchset I only fixed the
>> sg_table objects exported by dmabuf related functions. I hope that I
>> didn't break anything there."
>>
>> it would be really nice if the i915 maintainers could help with sorting
>> that API abuse out.
>>
> I agree completely that the API abuse should be sorted out, but I think
> that's much larger than just the i915 driver. Pretty much every dma-buf
> map_dma_buf implementation I looked at ignores the returned nents of
> sg_attrs. This sucks, but I don't think it's the bug Tom ran into. See:
>
> amdgpu_dma_buf_map
> armada_gem_prime_map_dma_buf
> drm_gem_map_dma_buf
> i915_gem_map_dma_buf
> tegra_gem_prime_map_dma_buf
>
> So this should probably be addressed by the whole GPU community.
Patches are pending:
https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprowski@samsung.com/T/
> However, as Robin pointed out, there are other ugly tricks like stopping
> iterating through the SGL when sg_dma_len() is zero. For example, the
> AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does
> this trick and thus likely isn't buggy (otherwise, I'd expect someone to
> have complained by now seeing AMD has already switched to IOMMU-DMA.
I'm not sure that this is a trick. Stopping at zero sg_dma_len() was
somewhere documented.
> As I tried to point out in my previous email, i915 does not do this
> trick. In fact, it completely ignores sg_dma_len() and is thus
> completely broken. See i915_scatterlist.h and the __sgt_iter() function.
> So it doesn't sound to me like Mark's fix would address the issue at
> all. Per my previous email, I'd guess that it can be fixed simply by
> adjusting the __sgt_iter() function to do something more sensible.
> (Better yet, if possible, ditch __sgt_iter() and use the common DRM
> function that AMD uses).
>
> This would at least allow us to make progress with Tom's IOMMU-DMA patch
> set and once that gets in, it will be harder for other drivers to make
> the same mistake.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
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] dt-bindings: clock: Convert i.MX8QXP LPCG to json-schema
From: Rob Herring @ 2020-05-29 21:11 UTC (permalink / raw)
To: Anson Huang
Cc: aisheng.dong, devicetree, sboyd, shawnguo, s.hauer, linux-kernel,
linux-clk, robh+dt, Linux-imx, kernel, festevam, mturquette,
linux-arm-kernel
In-Reply-To: <1590733299-12051-1-git-send-email-Anson.Huang@nxp.com>
On Fri, 29 May 2020 14:21:39 +0800, Anson Huang wrote:
> Convert the i.MX8QXP LPCG binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/clock/imx8qxp-lpcg.txt | 51 ---------------
> .../devicetree/bindings/clock/imx8qxp-lpcg.yaml | 72 ++++++++++++++++++++++
> 2 files changed, 72 insertions(+), 51 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm64 fix for 5.7-rc8/final
From: pr-tracker-bot @ 2020-05-29 21:10 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Linus Torvalds, linux-kernel, linux-arm-kernel
In-Reply-To: <20200529172055.28307-1-catalin.marinas@arm.com>
The pull request you sent on Fri, 29 May 2020 18:20:55 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4f23460cfa867aa560119e18a73616e784d3cd66
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
_______________________________________________
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] ARM: omap2: fix omap5_realtime_timer_init definition
From: Arnd Bergmann @ 2020-05-29 21:07 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-kernel@vger.kernel.org, Stefan Agner, SoC Team,
Olof Johansson, linux-omap, Linux ARM
In-Reply-To: <20200529204404.GW37466@atomide.com>
On Fri, May 29, 2020 at 10:44 PM Tony Lindgren <tony@atomide.com> wrote:
>
> * Arnd Bergmann <arnd@arndb.de> [200529 20:18]:
> > There is one more regression introduced by the last build fix:
>
> Argh.. I did run make randconfig for like 10 builds
> after the last fix.
>
> > Address this by removing the now obsolete #ifdefs in that file and
> > just building the entire file based on the flag that controls the
> > omap5_realtime_timer_init function declaration.
>
> I think this will introduce other randconfig build failures
> as SOC_HAS_REALTIME_COUNTER is bool in Kconfig.
I did a few hundred randconfig builds with the patch and have
not yet seen any further problems.
> We still need to call omap5_realtime_timer_init() even if
> SOC_HAS_REALTIME_COUNTER is not set.
This is what's in the header file:
#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
extern void omap5_realtime_timer_init(void);
#else
static inline void omap5_realtime_timer_init(void)
{
}
#endif
In fact, the inline stub is what that caused the regression,
so I think it's ok with my patch.
Arnd
_______________________________________________
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] ARM: omap2: fix omap5_realtime_timer_init definition
From: Tony Lindgren @ 2020-05-29 20:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Stefan Agner, soc, Olof Johansson, linux-omap,
linux-arm-kernel
In-Reply-To: <20200529201701.521933-1-arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [200529 20:18]:
> There is one more regression introduced by the last build fix:
Argh.. I did run make randconfig for like 10 builds
after the last fix.
> arch/arm/mach-omap2/timer.c:170:6: error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
> void __init omap5_realtime_timer_init(void)
> ^
> arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
> static inline void omap5_realtime_timer_init(void)
> ^
> arch/arm/mach-omap2/timer.c:170:13: error: redefinition of 'omap5_realtime_timer_init'
> void __init omap5_realtime_timer_init(void)
> ^
> arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
> static inline void omap5_realtime_timer_init(void)
>
> Address this by removing the now obsolete #ifdefs in that file and
> just building the entire file based on the flag that controls the
> omap5_realtime_timer_init function declaration.
I think this will introduce other randconfig build failures
as SOC_HAS_REALTIME_COUNTER is bool in Kconfig.
We still need to call omap5_realtime_timer_init() even if
SOC_HAS_REALTIME_COUNTER is not set.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: omap2: fix omap5_realtime_timer_init definition
From: Arnd Bergmann @ 2020-05-29 20:16 UTC (permalink / raw)
To: soc, Tony Lindgren, Arnd Bergmann
Cc: Olof Johansson, linux-omap, linux-arm-kernel, Stefan Agner,
linux-kernel
There is one more regression introduced by the last build fix:
arch/arm/mach-omap2/timer.c:170:6: error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
void __init omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
static inline void omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/timer.c:170:13: error: redefinition of 'omap5_realtime_timer_init'
void __init omap5_realtime_timer_init(void)
^
arch/arm/mach-omap2/common.h:118:20: note: previous definition is here
static inline void omap5_realtime_timer_init(void)
Address this by removing the now obsolete #ifdefs in that file and
just building the entire file based on the flag that controls the
omap5_realtime_timer_init function declaration.
Fixes: d86ad463d670 ("ARM: OMAP2+: Fix regression for using local timer on non-SMP SoCs")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
If this looks ok, I'd apply it directly on top again for the merge window.
---
arch/arm/mach-omap2/Makefile | 6 +++---
arch/arm/mach-omap2/timer.c | 10 ----------
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 40898b1fd7da..732e614c56b2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -46,9 +46,9 @@ obj-$(CONFIG_SOC_OMAP5) += $(omap-4-5-common) $(smp-y) sleep44xx.o
obj-$(CONFIG_SOC_AM43XX) += $(omap-4-5-common)
obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-common) $(smp-y) sleep44xx.o
-omap5-dra7-common = timer.o
-obj-$(CONFIG_SOC_OMAP5) += $(omap5-dra7-common)
-obj-$(CONFIG_SOC_DRA7XX) += $(omap5-dra7-common)
+omap5-dra7-common-$(CONFIG_SOC_HAS_REALTIME_COUNTER) = timer.o
+obj-$(CONFIG_SOC_OMAP5) += $(omap5-dra7-common-y)
+obj-$(CONFIG_SOC_DRA7XX) += $(omap5-dra7-common-y)
# Functions loaded to SRAM
obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c1737e737a94..620ba69c8f11 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -39,8 +39,6 @@
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
#define NUMERATOR_DENUMERATOR_MASK 0xfffff000
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
-
static unsigned long arch_timer_freq;
void set_cntfreq(void)
@@ -159,14 +157,6 @@ static void __init realtime_counter_init(void)
iounmap(base);
}
-#else
-
-static inline void realtime_counter_init(void)
-{
-}
-
-#endif /* CONFIG_SOC_HAS_REALTIME_COUNTER */
-
void __init omap5_realtime_timer_init(void)
{
omap_clk_init();
--
2.26.2
_______________________________________________
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] net: ethernet: mtk-star-emac: remove unused variable
From: David Miller @ 2020-05-29 19:42 UTC (permalink / raw)
To: brgl
Cc: lkp, stephane.leprovost, bgolaszewski, netdev, sean.wang,
linux-kernel, fparent, pedro.tsai, linux-mediatek,
andrew.perepech, john, matthias.bgg, kuba, Mark-MC.Lee,
linux-arm-kernel
In-Reply-To: <20200529082648.19677-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Fri, 29 May 2020 10:26:48 +0200
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The desc pointer is set but not used. Remove it.
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver")
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied, thanks.
_______________________________________________
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 v4 0/2] soc: ti: add k3 platforms chipid module driver
From: Grygorii Strashko @ 2020-05-29 19:39 UTC (permalink / raw)
To: santosh.shilimkar, Arnd Bergmann
Cc: Nishanth Menon, DTML, Dave Gerlach, Lokesh Vutla, Sekhar Nori,
linux-kernel@vger.kernel.org, Tero Kristo, Rob Herring,
Santosh Shilimkar, Linux ARM
In-Reply-To: <cb980673-d3ad-53b8-9351-196ff3f47c45@oracle.com>
On 29/05/2020 22:19, santosh.shilimkar@oracle.com wrote:
> On 5/29/20 11:34 AM, Arnd Bergmann wrote:
>> On Fri, May 29, 2020 at 8:22 PM Grygorii Strashko
>> <grygorii.strashko@ti.com> wrote:
>>> On 12/05/2020 15:34, Grygorii Strashko wrote:
>>
>>>> .../bindings/soc/ti/k3-socinfo.yaml | 40 +++++
>>>> drivers/soc/ti/Kconfig | 10 ++
>>>> drivers/soc/ti/Makefile | 1 +
>>>> drivers/soc/ti/k3-socinfo.c | 152 ++++++++++++++++++
>>>> 4 files changed, 203 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
>>>> create mode 100644 drivers/soc/ti/k3-socinfo.c
>>>>
>>>
>>> Any chances you can pick this up?
>>
>> I merged a version of this driver from Santosh's pull request into the
>> arm/drviers tree yesterday.
>>
>> Is there something missing?
>>
> Nope. I was going to reply on the thread but missed it.
Oh. Thanks. I've missed that it was already picked up.
Thanks again.
--
Best regards,
grygorii
_______________________________________________
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 V3] dt-bindings: timer: Convert i.MX GPT to json-schema
From: Rob Herring @ 2020-05-29 19:36 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, festevam, s.hauer, daniel.lezcano, linux-kernel,
robh+dt, Linux-imx, kernel, tglx, shawnguo, linux-arm-kernel
In-Reply-To: <1590717882-20922-1-git-send-email-Anson.Huang@nxp.com>
On Fri, 29 May 2020 10:04:42 +0800, Anson Huang wrote:
> Convert the i.MX GPT binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V2:
> - in compatible properties, group all the ones with the same
> fallback to a single 'items' list using enum for the first entry.
> ---
> .../devicetree/bindings/timer/fsl,imxgpt.txt | 45 --------------
> .../devicetree/bindings/timer/fsl,imxgpt.yaml | 72 ++++++++++++++++++++++
> 2 files changed, 72 insertions(+), 45 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
>
Applied, thanks!
_______________________________________________
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/4] dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
From: Florian Fainelli @ 2020-05-29 19:36 UTC (permalink / raw)
To: Rob Herring, Florian Fainelli
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Scott Branden, Ray Jui, Linus Walleij,
Matti Vaittinen, linux-kernel, open list:PIN CONTROL SUBSYSTEM,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200529193315.GA2807797@bogus>
On 5/29/20 12:33 PM, Rob Herring wrote:
> On Thu, May 28, 2020 at 12:21:10PM -0700, Florian Fainelli wrote:
>> BCM7211 supports wake-up interrupts in the form of optional interrupt
>> lines, one per bank, plus the "all banks" interrupt line.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> .../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
>> index dfc67b90591c..5682b2010e50 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
>> @@ -16,7 +16,9 @@ Required properties:
>> second cell is used to specify optional parameters:
>> - bit 0 specifies polarity (0 for normal, 1 for inverted)
>> - interrupts : The interrupt outputs from the controller. One interrupt per
>> - individual bank followed by the "all banks" interrupt.
>> + individual bank followed by the "all banks" interrupt. For BCM7211, an
>> + additional set of per-bank interrupt line and an "all banks" wake-up
>> + interrupt may be specified.
>
> Is 'all banks' the name? Generally 'wakeup' is used for a wake up irq.
The firmware provided DTB on 7211 names the interrupts "gpio_%d" for the
standard interrupts, including the "all banks" which is then "gpio_3"
and the wake-up interrupts are named "gpio_%d_wake", and the all banks
wake-up is "gpio_3_wake".
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox