* [PATCH v4 3/3] arm64: Introduce command line parameter to disable CNP
From: Catalin Marinas @ 2018-05-23 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526638022-4137-4-git-send-email-vladimir.murzin@arm.com>
On Fri, May 18, 2018 at 11:07:02AM +0100, Vladimir Murzin wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 11fc28e..8f59d47 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2636,6 +2636,10 @@
>
> noclflush [BUGS=X86] Don't use the CLFLUSH instruction
>
> + nocnp [ARM64]
> + Disable CNP (Common not Private translations)
> + even if it is supported by processor.
> +
> nodelayacct [KNL] Disable per-task delay accounting
>
> nodsp [SH] Disable hardware DSP at boot time.
Do we actually have a use-case for this command line option? I'm not
considering hardware errata as these are handled separately in the
kernel.
--
Catalin
^ permalink raw reply
* [PATCH 07/11] dts: juno: Add scatter-gather support for all revisions
From: Mathieu Poirier @ 2018-05-23 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526661567-4578-8-git-send-email-suzuki.poulose@arm.com>
On 18 May 2018 at 10:39, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> Advertise that the scatter-gather is properly integrated on
> all revisions of Juno board.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index eb749c5..6ce9090 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> @@ -198,6 +198,7 @@
> clocks = <&soc_smc50mhz>;
> clock-names = "apb_pclk";
> power-domains = <&scpi_devpd 0>;
> + arm,scatter-gather;
> port {
> etr_in_port: endpoint {
> slave-mode;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v4 0/2] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-05-23 17:46 UTC (permalink / raw)
To: linux-arm-kernel
This series adds support for telling userspace the size of the signal
frame via a new AT_MINSIGSTKSZ entry in the aux vector.
This is an update to a previous v3 standalone patch [1], which is
presented here as patch 2 with some updates in response to review.
See the changelog in the patch for details.
Patch 1 is new, and thins out some WARN_ON() checks for timely
initialisation of sve_max_vl that now look excessive, to strengthen
the case for not adding more such checks in patch 2.
[1] [PATCH v3] arm64: signal: Report signal frame size to userspace via auxv
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/578585.html
Dave Martin (2):
arm64/sve: Thin out initialisation sanity-checks for sve_max_vl
arm64: signal: Report signal frame size to userspace via auxv
arch/arm64/include/asm/elf.h | 11 ++++++++
arch/arm64/include/asm/processor.h | 5 ++++
arch/arm64/include/uapi/asm/auxvec.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/fpsimd.c | 17 +++---------
arch/arm64/kernel/ptrace.c | 3 ---
arch/arm64/kernel/signal.c | 52 +++++++++++++++++++++++++++++++-----
7 files changed, 68 insertions(+), 24 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v4 1/2] arm64/sve: Thin out initialisation sanity-checks for sve_max_vl
From: Dave Martin @ 2018-05-23 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527097616-25214-1-git-send-email-Dave.Martin@arm.com>
Now that the kernel SVE support is reasonably mature, it is
excessive to default sve_max_vl to the invalid value -1 and then
sprinkle WARN_ON()s around the place to make sure it has been
initialised before use. The cpufeatures code already runs pretty
early, and will ensure sve_max_vl gets initialised.
This patch initialises sve_max_vl to something sane that will be
supported by every SVE implementation, and removes most of the
sanity checks.
The checks in find_supported_vector_length() are retained for now.
If anything goes horribly wrong, we are likely to trip a check here
sooner or later.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kernel/fpsimd.c | 17 ++++-------------
arch/arm64/kernel/ptrace.c | 3 ---
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 87a3536..f9ec640 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -129,7 +129,7 @@ static int sve_default_vl = -1;
#ifdef CONFIG_ARM64_SVE
/* Maximum supported vector length across all CPUs (initially poisoned) */
-int __ro_after_init sve_max_vl = -1;
+int __ro_after_init sve_max_vl = SVE_VL_MIN;
/* Set of available vector lengths, as vq_to_bit(vq): */
static __ro_after_init DECLARE_BITMAP(sve_vq_map, SVE_VQ_MAX);
static void __percpu *efi_sve_state;
@@ -360,22 +360,13 @@ static int sve_proc_do_default_vl(struct ctl_table *table, int write,
return ret;
/* Writing -1 has the special meaning "set to max": */
- if (vl == -1) {
- /* Fail safe if sve_max_vl wasn't initialised */
- if (WARN_ON(!sve_vl_valid(sve_max_vl)))
- vl = SVE_VL_MIN;
- else
- vl = sve_max_vl;
-
- goto chosen;
- }
+ if (vl == -1)
+ vl = sve_max_vl;
if (!sve_vl_valid(vl))
return -EINVAL;
- vl = find_supported_vector_length(vl);
-chosen:
- sve_default_vl = vl;
+ sve_default_vl = find_supported_vector_length(vl);
return 0;
}
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 7ff81fe..577deb0 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -766,9 +766,6 @@ static void sve_init_header_from_task(struct user_sve_header *header,
vq = sve_vq_from_vl(header->vl);
header->max_vl = sve_max_vl;
- if (WARN_ON(!sve_vl_valid(sve_max_vl)))
- header->max_vl = header->vl;
-
header->size = SVE_PT_SIZE(vq, header->flags);
header->max_size = SVE_PT_SIZE(sve_vq_from_vl(header->max_vl),
SVE_PT_REGS_SVE);
--
2.1.4
^ permalink raw reply related
* [PATCH v4 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-05-23 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527097616-25214-1-git-send-email-Dave.Martin@arm.com>
Stateful CPU architecture extensions may require the signal frame
to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
However, changing this #define is an ABI break.
To allow userspace the option of determining the signal frame size
in a more forwards-compatible way, this patch adds a new auxv entry
tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
size that the process can observe during its lifetime.
If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
assume that the MINSIGSTKSZ #define is sufficient. This allows for
a consistent interface with older kernels that do not provide
AT_MINSIGSTKSZ.
The idea is that libc could expose this via sysconf() or some
similar mechanism.
There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
about userspace's own stack overheads and should not pretend to
know.
For arm64:
The primary motivation for this interface is the Scalable Vector
Extension, which can require at least 4KB or so of extra space
in the signal frame for the largest hardware implementations.
To determine the correct value, a "Christmas tree" mode (via the
add_all argument) is added to setup_sigframe_layout(), to simulate
addition of all possible records to the signal frame at maximum
possible size.
If this procedure goes wrong somehow, resulting in a stupidly large
frame layout and hence failure of sigframe_alloc() to allocate a
record to the frame, then this is indicative of a kernel bug: the
kernel's internal SIGFRAME_MAXSZ is supposed to sanity-check
against generting frames that we consider _impossibly_ large. If
we hit this case, SIGFRAME_MAXSZ is used as our best guess, and we
WARN().
For arm64 SVE:
The SVE context block in the signal frame needs to be considered
too when computing the maximum possible signal frame size.
Because the size of this block depends on the vector length, this
patch computes the size based not on the thread's current vector
length but instead on the maximum possible vector length: this
determines the maximum size of SVE context block that can be
observed in any signal frame for the lifetime of the process.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Alex Benn?e <alex.bennee@linaro.org>
---
Changes since v3:
* Fall back to SIGFRAME_MAXSZ, not SIGSTKSZ in case of
setup_sigframe_layout() failure, since exceeding SIGFRAME_MAXSZ is
the only way this can fail: therefore SIGFRAME_MAXSZ is our best
guess at the required size.
* Commit message updated to reflect the above change.
Requested by Will Deacon:
* Remove superfluous WARN()s from ARCH_DL_INFO and
setup_sigframe_layout(). If something went wrong and we still have
no value for signal_minsigstksz by the time we exec some user
process, AT_MINSIGSTKSZ is omitted from the aux vector. Userspace
should fall back to the MINSIGSTKSZ #define anyway in this case
(i.e., do things the POSIX way).
* Change the type of signal_minsigstksz to unsigned long, to match the
auxv and sigframe_size() types. (sigframe_size uses size_t, but it's
somewhat moot exactly what the types are, providing that
SIGFRAME_MAXSZ fits in all of them).
Also requested by Mark Rutland:
* Merge #ifndef __ASSEMBLY__ block introduced in <asm/elf.h> into
the existing one. The only things above are #defines, which
shouldn't be affected by this.
---
arch/arm64/include/asm/elf.h | 11 ++++++++
arch/arm64/include/asm/processor.h | 5 ++++
arch/arm64/include/uapi/asm/auxvec.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/signal.c | 52 +++++++++++++++++++++++++++++++-----
5 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index fac1c4d..9c18f0e 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -121,6 +121,9 @@
#ifndef __ASSEMBLY__
+#include <linux/bug.h>
+#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
+
typedef unsigned long elf_greg_t;
#define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
@@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
do { \
NEW_AUX_ENT(AT_SYSINFO_EHDR, \
(elf_addr_t)current->mm->context.vdso); \
+ \
+ /* \
+ * Should always be nonzero unless there's a kernel bug. If \
+ * the we haven't determined a sensible value to give to \
+ * userspace, omit the entry: \
+ */ \
+ if (likely(signal_minsigstksz)) \
+ NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz); \
} while (0)
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 7675989..65ab83e 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -35,6 +35,8 @@
#ifdef __KERNEL__
#include <linux/build_bug.h>
+#include <linux/cache.h>
+#include <linux/init.h>
#include <linux/stddef.h>
#include <linux/string.h>
@@ -244,6 +246,9 @@ void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused);
void cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused);
void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused);
+extern unsigned long __ro_after_init signal_minsigstksz; /* sigframe size */
+extern void __init minsigstksz_setup(void);
+
/* Userspace interface for PR_SVE_{SET,GET}_VL prctl()s: */
#define SVE_SET_VL(arg) sve_set_current_vl(arg)
#define SVE_GET_VL() sve_get_current_vl()
diff --git a/arch/arm64/include/uapi/asm/auxvec.h b/arch/arm64/include/uapi/asm/auxvec.h
index ec0a86d..743c0b8 100644
--- a/arch/arm64/include/uapi/asm/auxvec.h
+++ b/arch/arm64/include/uapi/asm/auxvec.h
@@ -19,7 +19,8 @@
/* vDSO location */
#define AT_SYSINFO_EHDR 33
+#define AT_MINSIGSTKSZ 51 /* stack needed for signal delivery */
-#define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
+#define AT_VECTOR_SIZE_ARCH 2 /* entries in ARCH_DLINFO */
#endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9d1b06d..0e0b53d 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1619,6 +1619,7 @@ void __init setup_cpu_features(void)
pr_info("emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching\n");
sve_setup();
+ minsigstksz_setup();
/* Advertise that we have computed the system capabilities */
set_sys_caps_initialised();
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 154b7d3..00b9990 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -17,6 +17,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/cache.h>
#include <linux/compat.h>
#include <linux/errno.h>
#include <linux/kernel.h>
@@ -570,8 +571,15 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
return 0;
}
-/* Determine the layout of optional records in the signal frame */
-static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
+/*
+ * Determine the layout of optional records in the signal frame
+ *
+ * add_all: if true, lays out the biggest possible signal frame for
+ * this task; otherwise, generates a layout for the current state
+ * of the task.
+ */
+static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
+ bool add_all)
{
int err;
@@ -581,7 +589,7 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
return err;
/* fault information, if valid */
- if (current->thread.fault_code) {
+ if (add_all || current->thread.fault_code) {
err = sigframe_alloc(user, &user->esr_offset,
sizeof(struct esr_context));
if (err)
@@ -591,8 +599,14 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
if (system_supports_sve()) {
unsigned int vq = 0;
- if (test_thread_flag(TIF_SVE))
- vq = sve_vq_from_vl(current->thread.sve_vl);
+ if (add_all || test_thread_flag(TIF_SVE)) {
+ int vl = sve_max_vl;
+
+ if (!add_all)
+ vl = current->thread.sve_vl;
+
+ vq = sve_vq_from_vl(vl);
+ }
err = sigframe_alloc(user, &user->sve_offset,
SVE_SIG_CONTEXT_SIZE(vq));
@@ -603,7 +617,6 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
return sigframe_alloc_end(user);
}
-
static int setup_sigframe(struct rt_sigframe_user_layout *user,
struct pt_regs *regs, sigset_t *set)
{
@@ -701,7 +714,7 @@ static int get_sigframe(struct rt_sigframe_user_layout *user,
int err;
init_user_layout(user);
- err = setup_sigframe_layout(user);
+ err = setup_sigframe_layout(user, false);
if (err)
return err;
@@ -936,3 +949,28 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
thread_flags = READ_ONCE(current_thread_info()->flags);
} while (thread_flags & _TIF_WORK_MASK);
}
+
+unsigned long __ro_after_init signal_minsigstksz;
+
+/*
+ * Determine the stack space required for guaranteed signal devliery.
+ * This function is used to populate AT_MINSIGSTKSZ at process startup.
+ * cpufeatures setup is assumed to be complete.
+ */
+void __init minsigstksz_setup(void)
+{
+ struct rt_sigframe_user_layout user;
+
+ init_user_layout(&user);
+
+ /*
+ * If this fails, SIGFRAME_MAXSZ needs to be enlarged. It won't
+ * be big enough, but it's our best guess:
+ */
+ if (WARN_ON(setup_sigframe_layout(&user, true)))
+ signal_minsigstksz = SIGFRAME_MAXSZ;
+ else
+ signal_minsigstksz = sigframe_size(&user) +
+ round_up(sizeof(struct frame_record), 16) +
+ 16; /* max alignment padding */
+}
--
2.1.4
^ permalink raw reply related
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Nick Desaulniers @ 2018-05-23 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAeHK+wk0hSH6iQcsLzrpjvsGocev-UZ6=z95ysecdFnAcHVSQ@mail.gmail.com>
On Wed, May 23, 2018 at 4:54 AM Andrey Konovalov <andreyknvl@google.com>
wrote:
> On Tue, May 22, 2018 at 8:28 PM, Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> > On Fri, May 18, 2018 at 11:13 AM Marc Zyngier <marc.zyngier@arm.com>
wrote:
> >> > - you have checked that with a released version of the compiler, you
> >
> > On Tue, May 22, 2018 at 10:58 AM Andrey Konovalov <andreyknvl@google.com
> > wrote:
> >> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> >
> > Hi Andrey,
> > Thank you very much for this report. Can you confirm as well the
version
> > of Clang that you were using?
> I'm on 86852a40 ("[InstCombine] Calloc-ed strings optimizations").
> > If it's not a binary release (built from
> > source), would you be able to re-confirm with a released version?
> Sure. Which release should I try and how do I get it?
Maybe clang-6.0 as the latest release (though I suspect you may run into
the recently-fixed-in-clang-7.0 "S" constraint bug that you reported).
I've had luck on debian based distributions installing from:
http://apt.llvm.org/
(These can be added to your /etc/apt/sources.list, then a `sudo apt update`
and `sudo apt install clang-6.0`)
If you're not able to add remote repositories (some employers block this ;)
), then you can find releases for download for a few different platforms:
https://releases.llvm.org/
For example, a quick:
$ mkdir llvm-6.0
$ cd !$
$ wget
https://releases.llvm.org/6.0.0/clang+llvm-6.0.0-x86_64-linux-gnu-debian8.tar.xz
$ tar xvf clang+llvm-6.0.0-x86_64-linux-gnu-debian8.tar.xz
$ ./clang+llvm-6.0.0-x86_64-linux-gnu-debian8/bin/clang-6.0 -v
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: .../llvm-6.0/./clang+llvm-6.0.0-x86_64-linux-gnu-debian8/bin
Found candidate GCC installation: ...
Candidate multilib: .;@m64
Selected multilib: .;@m64
Seems to work.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* [PATCH v7 2/2] drivers: soc: Add LLCC driver
From: rishabhb at codeaurora.org @ 2018-05-23 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Vd8HZU+BT38-OfXHiihv1yZG6YBeMWyfweBA+kAwk6HUw@mail.gmail.com>
On 2018-05-22 12:38, Andy Shevchenko wrote:
> On Tue, May 22, 2018 at 9:33 PM, <rishabhb@codeaurora.org> wrote:
>> On 2018-05-18 14:01, Andy Shevchenko wrote:
>>> On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar
>>> <rishabhb@codeaurora.org> wrote:
>
>>>> +#define ACTIVATE 0x1
>>>> +#define DEACTIVATE 0x2
>>>> +#define ACT_CTRL_OPCODE_ACTIVATE 0x1
>>>> +#define ACT_CTRL_OPCODE_DEACTIVATE 0x2
>>>> +#define ACT_CTRL_ACT_TRIG 0x1
>>>
>>>
>>> Are these bits? Perhaps BIT() ?
>>>
>> isn't it just better to use fixed size as u suggest in the next
>> comment?
>
> If the are bits, use BIT() macro.
>
>>>> +struct llcc_slice_desc *llcc_slice_getd(u32 uid)
>>>> +{
>>>> + const struct llcc_slice_config *cfg;
>>>> + struct llcc_slice_desc *desc;
>>>> + u32 sz, count = 0;
>>>> +
>>>> + cfg = drv_data->cfg;
>>>> + sz = drv_data->cfg_size;
>>>> +
>>>
>>>
>>>> + while (cfg && count < sz) {
>>>> + if (cfg->usecase_id == uid)
>>>> + break;
>>>> + cfg++;
>>>> + count++;
>>>> + }
>>>> + if (cfg == NULL || count == sz)
>>>> + return ERR_PTR(-ENODEV);
>>>
>>>
>>> if (!cfg)
>>> return ERR_PTR(-ENODEV);
>>>
>>> while (cfg->... != uid) {
>>> cfg++;
>>> count++;
>>> }
>>>
>>> if (count == sz)
>>> return ...
>>>
>>> Though I would rather put it to for () loop.
>>>
>> In each while loop iteration the cfg pointer needs to be checked for
>> NULL. What if the usecase id never matches the uid passed by client
>> and we keep iterating. At some point it will crash.
>
> do {
> if (!cfg || count == sz)
> return ...(-ENODEV);
> ...
> } while (...);
>
> Though, as I said for-loop will look slightly better I think.
>
>>>> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
>>>> + DEACTIVATE);
>>>
>>>
>>> Perhaps one line (~83 characters here is OK) ?
>>
>> The checkpatch script complains about such lines.
>
> So what if it just 3 characters out?
>
Many upstream reviewers have objection to lines crossing over 80
characters
I have gotten reviews to reduce the line length even if its like 81~82
characters. Can we keep this as it is? I have addressed all other
comments and will send out the next patch by today.
>>>> + ret = llcc_update_act_ctrl(desc->slice_id, act_ctrl_val,
>>>> + ACTIVATE);
>
>>> Ditto.
>
>>>> + attr1_cfg = bcast_off +
>>>> +
>>>> LLCC_TRP_ATTR1_CFGn(llcc_table[i].slice_id);
>>>> + attr0_cfg = bcast_off +
>>>> +
>>>> LLCC_TRP_ATTR0_CFGn(llcc_table[i].slice_id);
>
>>> Ditto.
>
>>>> + attr1_val |= llcc_table[i].probe_target_ways <<
>>>> + ATTR1_PROBE_TARGET_WAYS_SHIFT;
>>>> + attr1_val |= llcc_table[i].fixed_size <<
>>>> + ATTR1_FIXED_SIZE_SHIFT;
>>>> + attr1_val |= llcc_table[i].priority <<
>>>> ATTR1_PRIORITY_SHIFT;
>
>>> foo |=
>>> bar << SHIFT;
>>>
>>> would look slightly better.
>
> Did you consider this option ?
^ permalink raw reply
* [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Guenter Roeck @ 2018-05-23 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <76d47e02-7a5f-3fc2-3905-cd4aa03ac69c@arm.com>
On Wed, May 23, 2018 at 12:48:10PM +0100, Robin Murphy wrote:
> On 23/05/18 08:52, Scott Branden wrote:
> >
> >
> >On 18-05-22 04:24 PM, Ray Jui wrote:
> >>Hi Guenter,
> >>
> >>On 5/22/2018 1:54 PM, Guenter Roeck wrote:
> >>>On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:
> >>>>If the watchdog hardware is already enabled during the boot process,
> >>>>when the Linux watchdog driver loads, it should reset the watchdog and
> >>>>tell the watchdog framework. As a result, ping can be generated from
> >>>>the watchdog framework, until the userspace watchdog daemon takes over
> >>>>control
> >>>>
> >>>>Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> >>>>Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
> >>>>Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> >>>>---
> >>>>? drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
> >>>>? 1 file changed, 22 insertions(+)
> >>>>
> >>>>diff --git a/drivers/watchdog/sp805_wdt.c
> >>>>b/drivers/watchdog/sp805_wdt.c
> >>>>index 1484609..408ffbe 100644
> >>>>--- a/drivers/watchdog/sp805_wdt.c
> >>>>+++ b/drivers/watchdog/sp805_wdt.c
> >>>>@@ -42,6 +42,7 @@
> >>>>????? /* control register masks */
> >>>>????? #define??? INT_ENABLE??? (1 << 0)
> >>>>????? #define??? RESET_ENABLE??? (1 << 1)
> >>>>+??? #define??? ENABLE_MASK??? (INT_ENABLE | RESET_ENABLE)
> >>>>? #define WDTINTCLR??????? 0x00C
> >>>>? #define WDTRIS??????????? 0x010
> >>>>? #define WDTMIS??????????? 0x014
> >>>>@@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
> >>>>? MODULE_PARM_DESC(nowayout,
> >>>>????????? "Set to 1 to keep watchdog running after device release");
> >>>>? +/* returns true if wdt is running; otherwise returns false */
> >>>>+static bool wdt_is_running(struct watchdog_device *wdd)
> >>>>+{
> >>>>+??? struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
> >>>>+
> >>>>+??? if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
> >>>>+??????? ENABLE_MASK)
> >>>>+??????? return true;
> >>>>+??? else
> >>>>+??????? return false;
> >>>
> >>>????return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
> >>>
> >>
> >>Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE);
> >>therefore, a simple !!(expression) would not work? That is, the masked
> >>result needs to be compared against the mask again to ensure both bits
> >>are set, right?
> >Ray - your original code looks correct to me.? Easier to read and less
> >prone to errors as shown in the attempted translation to a single
> >statement.
>
> if (<boolean condition>)
> return true;
> else
> return false;
>
> still looks really dumb, though, and IMO is actually harder to read than
> just "return <boolean condition>;" because it forces you to stop and
> double-check that the logic is, in fact, only doing the obvious thing.
>
Yes, and I won't accept it, sorry.
Guenter
> Robin.
>
>
>
> p.s. No thanks for making me remember the mind-boggling horror of briefly
> maintaining part of this legacy codebase... :P
>
> $ grep -r '? true : false' --include=*.cpp . | wc -l
> 951
^ permalink raw reply
* [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Guenter Roeck @ 2018-05-23 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ef3539fd-c95c-f364-93c7-680aabd1eea3@arm.com>
On Wed, May 23, 2018 at 06:15:14PM +0100, Robin Murphy wrote:
> On 23/05/18 17:29, Ray Jui wrote:
> >Hi Robin,
> >
> >On 5/23/2018 4:48 AM, Robin Murphy wrote:
> >>On 23/05/18 08:52, Scott Branden wrote:
> >>>
> >>>
> >>>On 18-05-22 04:24 PM, Ray Jui wrote:
> >>>>Hi Guenter,
> >>>>
> >>>>On 5/22/2018 1:54 PM, Guenter Roeck wrote:
> >>>>>On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:
> >>>>>>If the watchdog hardware is already enabled during the boot process,
> >>>>>>when the Linux watchdog driver loads, it should reset the
> >>>>>>watchdog and
> >>>>>>tell the watchdog framework. As a result, ping can be generated from
> >>>>>>the watchdog framework, until the userspace watchdog daemon
> >>>>>>takes over
> >>>>>>control
> >>>>>>
> >>>>>>Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> >>>>>>Reviewed-by: Vladimir Olovyannikov
> >>>>>><vladimir.olovyannikov@broadcom.com>
> >>>>>>Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> >>>>>>---
> >>>>>>? drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
> >>>>>>? 1 file changed, 22 insertions(+)
> >>>>>>
> >>>>>>diff --git a/drivers/watchdog/sp805_wdt.c
> >>>>>>b/drivers/watchdog/sp805_wdt.c
> >>>>>>index 1484609..408ffbe 100644
> >>>>>>--- a/drivers/watchdog/sp805_wdt.c
> >>>>>>+++ b/drivers/watchdog/sp805_wdt.c
> >>>>>>@@ -42,6 +42,7 @@
> >>>>>>????? /* control register masks */
> >>>>>>????? #define??? INT_ENABLE??? (1 << 0)
> >>>>>>????? #define??? RESET_ENABLE??? (1 << 1)
> >>>>>>+??? #define??? ENABLE_MASK??? (INT_ENABLE | RESET_ENABLE)
> >>>>>>? #define WDTINTCLR??????? 0x00C
> >>>>>>? #define WDTRIS??????????? 0x010
> >>>>>>? #define WDTMIS??????????? 0x014
> >>>>>>@@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
> >>>>>>? MODULE_PARM_DESC(nowayout,
> >>>>>>????????? "Set to 1 to keep watchdog running after device release");
> >>>>>>? +/* returns true if wdt is running; otherwise returns false */
> >>>>>>+static bool wdt_is_running(struct watchdog_device *wdd)
> >>>>>>+{
> >>>>>>+??? struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
> >>>>>>+
> >>>>>>+??? if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
> >>>>>>+??????? ENABLE_MASK)
> >>>>>>+??????? return true;
> >>>>>>+??? else
> >>>>>>+??????? return false;
> >>>>>
> >>>>>????return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
> >>>>>
> >>>>
> >>>>Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE);
> >>>>therefore, a simple !!(expression) would not work? That is, the
> >>>>masked result needs to be compared against the mask again to ensure
> >>>>both bits are set, right?
> >>>Ray - your original code looks correct to me.? Easier to read and less
> >>>prone to errors as shown in the attempted translation to a single
> >>>statement.
> >>
> >>?????if (<boolean condition>)
> >>???????? return true;
> >>?????else
> >>???????? return false;
> >>
> >>still looks really dumb, though, and IMO is actually harder to read than
> >>just "return <boolean condition>;" because it forces you to stop and
> >>double-check that the logic is, in fact, only doing the obvious thing.
> >
> >If you can propose a way to modify my original code above to make it more
> >readable, I'm fine to make the change.
>
> Well,
>
> return readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK == ENABLE_MASK;
>
> would probably be reasonable to anyone other than the 80-column zealots, but
> removing the silly boolean-to-boolean translation idiom really only
> emphasises the fact that it's fundamentally a big complex statement; for
> maximum clarity I'd be inclined to separate the two logical operations (read
> and comparison), e.g.:
>
> u32 wdtcontrol = readl_relaxed(wdt->base + WDTCONTROL);
>
> return wdtcontrol & ENABLE_MASK == ENABLE_MASK;
== has higher precendence than bitwise &, so this will need ( ),
but otherwise I agree.
>
> which is still -3 lines vs. the original.
>
> >As I mentioned, I don't think the following change proposed by Guenter
> >will work due to the reason I pointed out:
> >
> >return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
>
> FWIW, getting the desired result should only need one logical not swapping
> for a bitwise one there:
>
> return !(~readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK);
>
> but that's well into "too clever for its own good" territory ;)
Yes, that would be confusing.
>
> Robin.
^ permalink raw reply
* [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Guenter Roeck @ 2018-05-23 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af81ea74-fb80-11e2-7bdc-d3607bdbd46b@arm.com>
On Wed, May 23, 2018 at 11:57:25AM +0100, Robin Murphy wrote:
> On 22/05/18 19:47, Ray Jui wrote:
> >Update the SP805 binding document to add optional 'timeout-sec'
> >devicetree property
> >
> >Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> >Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> >---
> > Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> >diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> >index edc4f0e..f898a86 100644
> >--- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> >+++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> >@@ -19,6 +19,8 @@ Required properties:
> > Optional properties:
> > - interrupts : Should specify WDT interrupt number.
> >+- timeout-sec : Should specify default WDT timeout in seconds. If unset, the
> >+ default timeout is 30 seconds
>
> According to the SP805 TRM, the default interval is dependent on the rate of
> WDOGCLK, but would typically be a lot longer than that :/
>
Depends on the definition of "default". In the context of watchdog drivers,
it is (or should be) a driver default, not a chip default.
Guenter
> On a related note, anyone have any idea why we seem to have two subtly
> different SP805 bindings defined?
>
> Robin.
>
> > Examples:
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH RFC V2 2/6] hwmon: Add support for RPi voltage sensor
From: Guenter Roeck @ 2018-05-23 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cbbdab47-cde3-7a7c-c797-c00d546e00d5@arm.com>
On Wed, May 23, 2018 at 01:12:10PM +0100, Robin Murphy wrote:
> On 22/05/18 20:31, Stefan Wahren wrote:
> [...]
> >>>>>+static int rpi_hwmon_probe(struct platform_device *pdev)
> >>>>>+{
> >>>>>+ struct device *dev = &pdev->dev;
> >>>>>+ struct rpi_hwmon_data *data;
> >>>>>+ int ret;
> >>>>>+
> >>>>>+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> >>>>>+ if (!data)
> >>>>>+ return -ENOMEM;
> >>>>>+
> >>>>>+ data->fw = platform_get_drvdata(to_platform_device(dev->parent));
> >>>>>+ if (!data->fw)
> >>>>>+ return -EPROBE_DEFER;
> >>>>>+
> >>>>
> >>>>I am a bit at loss here (and sorry I didn't bring this up before).
> >>>>How would this ever be possible, given that the driver is registered
> >>>>from the firmware driver ?
> >>>
> >>>Do you refer to the (wrong) return code, the assumption that the parent must be a platform driver or a possible race?
> >>>
> >>
> >>The return code is one thing. My question was how the driver would ever be instantiated
> >>with platform_get_drvdata(to_platform_device(dev->parent)) == NULL (but dev->parent != NULL),
> >>so I referred to the race. But, sure, a second question would be how that would indicate
> >>that the parent is not instantiated yet (which by itself seems like an odd question).
> >
> >This shouldn't happen and worth a log error. In patch #3 the registration is called after the complete private data of the firmware driver is initialized. Did i missed something?
> >
> >But i must confess that i didn't test all builtin/module combinations.
>
> The point is that, by construction, a "raspberrypi-hwmon" device will only
> ever be created for this driver to bind to if the firmware device is both
> fully initialised and known to support the GET_THROTTLED call already. Thus
> trying to check those again from the hwmon driver is at best pointless, and
> at worst misleading. If somebody *does* manage to bind this driver to some
> random inappropriate device, you've still got no guarantee that dev->parent
> is valid or that dev_get_drvdata(dev->parent)) won't return something
> non-NULL that isn't a struct rpi_firmware pointer, at which point you're
> liable to pass the paranoid check yet still crash anyway.
>
> IOW, you can't reasonably defend against incorrect operation, and under
> correct operation there's nothing to defend against, so either way it's
> pretty futile to waste effort trying.
>
Well said.
Guenter
^ permalink raw reply
* [GIT PULL] Amlogic 32-bit DT updates for v4.18, round 2
From: Kevin Hilman @ 2018-05-23 18:17 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 35ee52bea66c74a7c33cebda8692d61b1ed7c6e9:
ARM: dts: meson8m2: add support for the Tronsmart MXIII Plus (2018-05-10 17:03:28 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt-2
for you to fetch changes up to ae0257da5701b6e44eba9dc4ebab867b56d6ea29:
ARM: meson: merge Kconfig symbol MACH_MESON8B into MACH_MESON8 (2018-05-23 10:08:13 -0700)
----------------------------------------------------------------
Amlogic 32-bit DT changes for v4.18, round 2
- remove MACH_MESON8B, only used for building DTs
----------------------------------------------------------------
Martin Blumenstingl (2):
ARM: dts: meson: build the Meson8b .dtbs with MACH_MESON8
ARM: meson: merge Kconfig symbol MACH_MESON8B into MACH_MESON8
arch/arm/boot/dts/Makefile | 5 ++---
arch/arm/mach-meson/Kconfig | 9 +--------
2 files changed, 3 insertions(+), 11 deletions(-)
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT updates for v4.18, round 2
From: Kevin Hilman @ 2018-05-23 18:17 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit c51fb2d458a6d62215c1ff6bbca8e5c876370e71:
dt-bindings: arm: amlogic: add support for the Tronsmart MXIII Plus (2018-05-09 15:25:20 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2
for you to fetch changes up to ffe2f2a415a5c36c0629c0ac8ea3dda80fbfd4b6:
ARM64: dts: meson-axg: enable i2c AO on the S400 board (2018-05-23 10:05:41 -0700)
----------------------------------------------------------------
Amlogic 64-bit DT updates for v4.18, round 2
- AXG I2C fixups/cleanups
----------------------------------------------------------------
Jerome Brunet (4):
ARM64: dts: meson-axg: clean-up i2c nodes
ARM64: dts: meson-axg: correct i2c AO clock
ARM64: dts: meson-axg: add i2c AO pins
ARM64: dts: meson-axg: enable i2c AO on the S400 board
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------
2 files changed, 62 insertions(+), 23 deletions(-)
^ permalink raw reply
* [PATCH 06/11] dts: bindings: Restrict coresight tmc-etr scatter-gather mode
From: Rob Herring @ 2018-05-23 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526661567-4578-7-git-send-email-suzuki.poulose@arm.com>
On Fri, May 18, 2018 at 05:39:22PM +0100, Suzuki K Poulose wrote:
> We are about to add the support for ETR builtin scatter-gather mode
> for dealing with large amount of trace buffers. However, on some of
> the platforms, using the ETR SG mode can lock up the system due to
> the way the ETR is connected to the memory subsystem.
>
> In SG mode, the ETR performs READ from the scatter-gather table to
> fetch the next page and regular WRITE of trace data. If the READ
> operation doesn't complete(due to the memory subsystem issues,
> which we have seen on a couple of platforms) the trace WRITE
> cannot proceed leading to issues. So, we by default do not
> use the SG mode, unless it is known to be safe on the platform.
> We define a DT property for the TMC node to specify whether we
> have a proper SG mode.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Mike Leach <mike.leach@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: John Horley <john.horley@arm.com>
> Cc: Robert Walker <robert.walker@arm.com>
> Cc: devicetree at vger.kernel.org
> Cc: frowand.list at gmail.com
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> Documentation/devicetree/bindings/arm/coresight.txt | 2 ++
> drivers/hwtracing/coresight/coresight-tmc.c | 9 ++++++++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 03/15] clk: sunxi-ng: r40: Export video PLLs
From: Rob Herring @ 2018-05-23 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519183127.2718-4-jernej.skrabec@siol.net>
On Sat, May 19, 2018 at 08:31:15PM +0200, Jernej Skrabec wrote:
> Video PLLs need to be referenced in R40 DT as possible HDMI PHY parent.
>
> Export them.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 8 ++++++--
> include/dt-bindings/clock/sun8i-r40-ccu.h | 4 ++++
> 2 files changed, 10 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 05/15] drm/sun4i: Add TCON TOP driver
From: Rob Herring @ 2018-05-23 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180519183127.2718-6-jernej.skrabec@siol.net>
On Sat, May 19, 2018 at 08:31:17PM +0200, Jernej Skrabec wrote:
> As already described in DT binding, TCON TOP is responsible for
> configuring display pipeline. In this initial driver focus is on HDMI
> pipeline, so TVE and LCD configuration is not implemented.
>
> Implemented features:
> - HDMI source selection
> - clock driver (TCON and DSI gating)
> - connecting mixers and TCONS
>
> Something similar also existed in previous SoCs, except that it was part
> of first TCON.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/Makefile | 3 +-
> drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 256 +++++++++++++++++++++
> drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 20 ++
> include/dt-bindings/clock/sun8i-tcon-top.h | 11 +
This belongs with the binding doc patch.
> 4 files changed, 289 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
> create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
^ permalink raw reply
* [RFC 12/13] ARM: dts: ti: add dra71-evm FIT description file
From: Tony Lindgren @ 2018-05-23 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <243730d3-e7f3-584d-b5dd-491c2700cf11@ti.com>
* Tero Kristo <t-kristo@ti.com> [180523 05:58]:
> On 22/05/18 23:01, Rob Herring wrote:
> > On Mon, May 21, 2018 at 09:57:54AM +0300, Tero Kristo wrote:
> > > Ok trying to resurrect this thread a bit. Is there any kind of consensus how
> > > things like this should be handled? Should we add the DT overlay files to
> > > kernel tree or not?
> >
> > IMO, yes.
I too agree the overlay files should be in the kernel rather than
people having to try to figure out where to find them.
No idea how we'll verify they'll build though :) Maybe we
just need randconfig support for DT overlay files too?
Regards,
Tony
^ permalink raw reply
* [PATCH v2] OMAP: CLK: CLKSRC: Add suspend resume hooks
From: Tony Lindgren @ 2018-05-23 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527013340-8036-1-git-send-email-j-keerthy@ti.com>
* Keerthy <j-keerthy@ti.com> [180522 11:24]:
> Add the save and restore for clksrc as part of suspend and resume
> so that it saves the counter value and restores. This is needed in
> modes like rtc+ddr in self-refresh not doing this stalls the time.
Can't we now do this all in drivers/clocksource/timer-ti-*.c?
> @@ -490,6 +513,15 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
> res = omap_dm_timer_init_one(&clksrc, fck_source, property,
> &clocksource_gpt.name,
> OMAP_TIMER_NONPOSTED);
> +
> + if (soc_is_am43xx()) {
> + clocksource_gpt.suspend = omap2_gptimer_clksrc_suspend;
> + clocksource_gpt.resume = omap2_gptimer_clksrc_resume;
> +
> + clocksource_gpt_hwmod =
> + omap_hwmod_lookup(clocksource_gpt.name);
> + }
> +
Then you can do this based on a quirk flag set by compatible.
Regards,
Tony
^ permalink raw reply
* [PATCHv2] arm64: Make sure permission updates happen for pmd/pud
From: Laura Abbott @ 2018-05-23 18:43 UTC (permalink / raw)
To: linux-arm-kernel
Commit 15122ee2c515 ("arm64: Enforce BBM for huge IO/VMAP mappings")
disallowed block mappings for ioremap since that code does not honor
break-before-make. The same APIs are also used for permission updating
though and the extra checks prevent the permission updates from happening,
even though this should be permitted. This results in read-only permissions
not being fully applied. Visibly, this can occasionaly be seen as a failure
on the built in rodata test when the test data ends up in a section or
as an odd RW gap on the page table dump. Fix this by using
pgattr_change_is_safe instead of p*d_present for determining if the
change is permitted.
Reported-by: Peter Robinson <pbrobinson@gmail.com>
Fixes: 15122ee2c515 ("arm64: Enforce BBM for huge IO/VMAP mappings")
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
v2: Switch to using pgattr_change_is_safe per suggestion of Will
---
arch/arm64/mm/mmu.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..493ff75670ff 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -933,13 +933,15 @@ int pud_set_huge(pud_t *pudp, phys_addr_t phys, pgprot_t prot)
{
pgprot_t sect_prot = __pgprot(PUD_TYPE_SECT |
pgprot_val(mk_sect_prot(prot)));
+ pud_t new_pud = pfn_pud(__phys_to_pfn(phys), sect_prot);
- /* ioremap_page_range doesn't honour BBM */
- if (pud_present(READ_ONCE(*pudp)))
+ /* Only allow permission changes for now */
+ if (!pgattr_change_is_safe(READ_ONCE(pud_val(*pudp)),
+ pud_val(new_pud)))
return 0;
BUG_ON(phys & ~PUD_MASK);
- set_pud(pudp, pfn_pud(__phys_to_pfn(phys), sect_prot));
+ set_pud(pudp, new_pud);
return 1;
}
@@ -947,13 +949,15 @@ int pmd_set_huge(pmd_t *pmdp, phys_addr_t phys, pgprot_t prot)
{
pgprot_t sect_prot = __pgprot(PMD_TYPE_SECT |
pgprot_val(mk_sect_prot(prot)));
+ pmd_t new_pmd = pfn_pmd(__phys_to_pfn(phys), sect_prot);
- /* ioremap_page_range doesn't honour BBM */
- if (pmd_present(READ_ONCE(*pmdp)))
+ /* Only allow permission changes for now */
+ if (!pgattr_change_is_safe(READ_ONCE(pmd_val(*pmdp)),
+ pmd_val(new_pmd)))
return 0;
BUG_ON(phys & ~PMD_MASK);
- set_pmd(pmdp, pfn_pmd(__phys_to_pfn(phys), sect_prot));
+ set_pmd(pmdp, new_pmd);
return 1;
}
--
2.17.0
^ permalink raw reply related
* [GIT PULL] Amlogic 64-bit DT updates for v4.18, round 3
From: Kevin Hilman @ 2018-05-23 18:50 UTC (permalink / raw)
To: linux-arm-kernel
Olof, ARnd,
Here's final round of 64-bit DT updates for v4.18 for Amlogic.
I separated this one from round 2 because I've merged a tag from the
clock tree where the headers were added that are used by the new clock
driver nodes.
That clock dependency branch is already queued by the clock maintainers,
but included here so the arm-soc DT branch will continue to build
standalone.
Kevin
The following changes since commit ffe2f2a415a5c36c0629c0ac8ea3dda80fbfd4b6:
ARM64: dts: meson-axg: enable i2c AO on the S400 board (2018-05-23 10:05:41 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-3
for you to fetch changes up to 9adda3534faad306c3d5351c5b87d26fea9767be:
ARM64: dts: meson: fix clock source of the pclk for UART_AO (2018-05-23 11:31:54 -0700)
----------------------------------------------------------------
Amlogic 64-bit DT updates, round3
- AXG: add new clock driver
----------------------------------------------------------------
Kevin Hilman (1):
Merge tag 'for-kevin-meson-clk-bindings-v4.18-1' of https://github.com/BayLibre/clk-meson into v4.18/dt64
Martin Blumenstingl (1):
dt-bindings: clock: meson8b: export the NAND clock
Maxime Jourdan (1):
clk: meson: gxbb: expose VDEC_1 and VDEC_HEVC clocks
Qiufang Dai (1):
ARM64: dts: meson-axg: add AO clock driver
Yixun Lan (3):
dt-bindings: clock: axg-aoclkc: New binding for Meson-AXG SoC
dt-bindings: clock: reset: Add AXG AO Clock and Reset Bindings
ARM64: dts: meson: fix clock source of the pclk for UART_AO
Documentation/devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt | 1 +
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 16 ++++++++++++++--
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++--
include/dt-bindings/clock/axg-aoclkc.h | 26 ++++++++++++++++++++++++++
include/dt-bindings/clock/gxbb-clkc.h | 2 ++
include/dt-bindings/clock/meson8b-clkc.h | 1 +
include/dt-bindings/reset/axg-aoclkc.h | 20 ++++++++++++++++++++
8 files changed, 68 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/clock/axg-aoclkc.h
create mode 100644 include/dt-bindings/reset/axg-aoclkc.h
^ permalink raw reply
* [PATCH 3/6] ASoC: ams_delta: use GPIO lookup table
From: Tony Lindgren @ 2018-05-23 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521100503.GA24638@sirena.org.uk>
* Mark Brown <broonie@kernel.org> [180521 10:07]:
> On Fri, May 18, 2018 at 11:09:51PM +0200, Janusz Krzysztofik wrote:
> > Now as the Amstrad Delta board provides GPIO lookup tables, switch from
> > GPIO numbers to GPIO descriptors and use the table to locate required
> > GPIO pins.
>
> Acked-by: Mark Brown <broonie@kernel.org>
Thanks applying patches 1 and 3 of this series into omap-for-v4.18/soc.
It's kind of getting late for v4.18, but let's see if we can still make
it.
Seems the others can be applied to the driver trees after no more
comments, then once all that is done we can apply the last patch
in this series.
Regards,
Tony
^ permalink raw reply
* [PATCH v2] ARM: AM43XX: Add functions to save/restore am43xx control registers
From: Tony Lindgren @ 2018-05-23 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527013299-7982-1-git-send-email-j-keerthy@ti.com>
* Keerthy <j-keerthy@ti.com> [180522 11:24]:
> From: Tero Kristo <t-kristo@ti.com>
>
> These registers are part of the wkup domain and are lost during RTC only
> suspend and also hibernation, so storing/restoring their state is
> necessary.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> ---
>
> Changes in v2:
>
> * Introduced cpu_pm notifier instead of direct calls from pm33xx code.
> * Tested on am437x-gp-evm
>
> Probably too late for 4.18!
Applying into omap-for-v4.18/soc thanks, let's see if we can still
make it. If not, then for v4.19.
Regards,
Tony
^ permalink raw reply
* [PATCH] arm64: kvm: use -fno-jump-tables with clang
From: Andrey Konovalov @ 2018-05-23 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKwvOd=fqk2bQSiPBsUmVSQLGUEGYSUev3iWvico6HOpYs5YJA@mail.gmail.com>
On Wed, May 23, 2018 at 7:47 PM, Nick Desaulniers
<ndesaulniers@google.com> wrote:
> On Wed, May 23, 2018 at 4:54 AM Andrey Konovalov <andreyknvl@google.com>
> wrote:
>> On Tue, May 22, 2018 at 8:28 PM, Nick Desaulniers
>> <ndesaulniers@google.com> wrote:
>> > On Fri, May 18, 2018 at 11:13 AM Marc Zyngier <marc.zyngier@arm.com>
> wrote:
>> >> > - you have checked that with a released version of the compiler, you
>> >
>> > On Tue, May 22, 2018 at 10:58 AM Andrey Konovalov <andreyknvl@google.com
>
>> > wrote:
>> >> Tested-by: Andrey Konovalov <andreyknvl@google.com>
>> >
>> > Hi Andrey,
>> > Thank you very much for this report. Can you confirm as well the
> version
>> > of Clang that you were using?
>
>> I'm on 86852a40 ("[InstCombine] Calloc-ed strings optimizations").
>
>> > If it's not a binary release (built from
>> > source), would you be able to re-confirm with a released version?
>
>> Sure. Which release should I try and how do I get it?
>
> Maybe clang-6.0 as the latest release (though I suspect you may run into
> the recently-fixed-in-clang-7.0 "S" constraint bug that you reported).
Yes, and also into the "support for "r" prefixed variables in ARM
inline assembly" issue.
Tested on upstream commit ded4c39e (before both issues were
introduced) with -fno-jump-tables patch applied using clang 6.0.
Same result, the patch helps.
>
> I've had luck on debian based distributions installing from:
> http://apt.llvm.org/
>
> (These can be added to your /etc/apt/sources.list, then a `sudo apt update`
> and `sudo apt install clang-6.0`)
>
> If you're not able to add remote repositories (some employers block this ;)
> ), then you can find releases for download for a few different platforms:
> https://releases.llvm.org/
>
> For example, a quick:
> $ mkdir llvm-6.0
> $ cd !$
> $ wget
> https://releases.llvm.org/6.0.0/clang+llvm-6.0.0-x86_64-linux-gnu-debian8.tar.xz
> $ tar xvf clang+llvm-6.0.0-x86_64-linux-gnu-debian8.tar.xz
> $ ./clang+llvm-6.0.0-x86_64-linux-gnu-debian8/bin/clang-6.0 -v
> clang version 6.0.0 (tags/RELEASE_600/final)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: .../llvm-6.0/./clang+llvm-6.0.0-x86_64-linux-gnu-debian8/bin
> Found candidate GCC installation: ...
> Candidate multilib: .;@m64
> Selected multilib: .;@m64
>
> Seems to work.
> --
> Thanks,
> ~Nick Desaulniers
^ permalink raw reply
* [PATCH 1/5] Documentation: DT: Add optional 'timeout-sec' property for sp805
From: Rob Herring @ 2018-05-23 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c542388f-e417-f624-ade1-95f9a2fc8a3b@broadcom.com>
On Wed, May 23, 2018 at 09:25:49AM -0700, Ray Jui wrote:
>
>
> On 5/23/2018 3:57 AM, Robin Murphy wrote:
> > On 22/05/18 19:47, Ray Jui wrote:
> > > Update the SP805 binding document to add optional 'timeout-sec'
> > > devicetree property
> > >
> > > Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> > > Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> > > ---
> > > ? Documentation/devicetree/bindings/watchdog/sp805-wdt.txt | 2 ++
> > > ? 1 file changed, 2 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> > > b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> > > index edc4f0e..f898a86 100644
> > > --- a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> > > +++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
> > > @@ -19,6 +19,8 @@ Required properties:
> > > ? Optional properties:
> > > ? - interrupts : Should specify WDT interrupt number.
> > > +- timeout-sec : Should specify default WDT timeout in seconds. If
> > > unset, the
> > > +??????????????? default timeout is 30 seconds
> >
> > According to the SP805 TRM, the default interval is dependent on the
> > rate of WDOGCLK, but would typically be a lot longer than that :/
> >
> > On a related note, anyone have any idea why we seem to have two subtly
> > different SP805 bindings defined?
Sigh.
> Interesting, I did not even know that until you pointed this out (and it's
> funny that I found that I actually reviewed arm,sp805.txt internally in
> Broadcom code review).
>
> It looks like one was done by Bhupesh Sharma (sp805-wdt.txt) and the other
> was done by Anup Patel (arm,sp805.txt). Both were merged at the same time
> around March 20, 2016: 915c56bc01d6. I'd assume both were sent out at around
> the same time.
>
> It sounds like we should definitely remove one of them. Given that
> sp805-wdt.txt appears to have more detailed descriptions on the use of the
> clocks, should we remove arm,sp805.txt?
Take whichever text you like, but I prefer filenames using the
compatible string and the correct string is 'arm,sp805' because '-wdt'
is redundant. You can probably safely just update all the dts files with
'arm,sp805' and just remove 'arm,sp805-wdt' because it is not actually
used (as the ID registers are).
Rob
^ permalink raw reply
* [PATCH] ARM: DTS: dra7: fix DCAN node addresses
From: Tony Lindgren @ 2018-05-23 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cf431fca-0372-bd50-88e7-d478e4aa52da@ti.com>
* Roger Quadros <rogerq@ti.com> [180521 20:25]:
> On 21/05/18 15:08, Kevin Hilman wrote:
> > Fix the DT node addresses to match the reg property addresses,
> > which were verified to match the TRM:
> > http://www.ti.com/lit/pdf/sprui30
> >
> > Cc: Roger Quadros <rogerq@ti.com>
> > Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>
> Thanks Kevin.
>
> Acked-by: Roger Quadros <rogerq@ti.com>
Applying into omap-for-v4.18/dt-fixes thanks.
Tony
^ 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