* Re: [PATCH v3 19/20] dt-bindings: mali-midgard: Allow dma-coherent
From: Rob Herring @ 2020-05-15 3:16 UTC (permalink / raw)
To: Andre Przywara
Cc: Mark Rutland, devicetree, Lorenzo Pieralisi, David Airlie,
Liviu Dudau, dri-devel, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20200513103016.130417-20-andre.przywara@arm.com>
On Wed, 13 May 2020 11:30:15 +0100, Andre Przywara wrote:
> Add the boolean dma-coherent property to the list of allowed properties,
> since some boards (Arm Juno) integrate the GPU this way.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
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 v3 01/20] dt-bindings: arm: gic: Allow combining arm, gic-400 compatible strings
From: Rob Herring @ 2020-05-15 3:16 UTC (permalink / raw)
To: Andre Przywara
Cc: Mark Rutland, devicetree, Lorenzo Pieralisi, Marc Zyngier,
Liviu Dudau, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20200513103016.130417-2-andre.przywara@arm.com>
On Wed, 13 May 2020 11:29:57 +0100, Andre Przywara wrote:
> The arm,gic-400 compatible is probably the best matching string for the
> GIC in most modern SoCs, but was only introduced later into the kernel.
> For historic reasons and to keep compatibility, some SoC DTs were thus
> using a combination of this name and one of the older strings, which
> currently the binding denies.
>
> Add a stanza to the DT binding to allow "arm,gic-400", followed by
> either "arm,cortex-a15-gic" or "arm,cortex-a7-gic". This fixes binding
> compliance for quite some SoC .dtsi files in the kernel tree.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../devicetree/bindings/interrupt-controller/arm,gic.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
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 v2 0/4] scsi: ufs: allow customizable WriteBooster flush policy
From: Stanley Chu @ 2020-05-15 1:15 UTC (permalink / raw)
To: Martin K. Petersen
Cc: bvanassche, linux-scsi, andy.teng, jejb, chun-hung.wu,
kuohong.wang, linux-kernel, avri.altman, cang, linux-mediatek,
peter.wang, alim.akhtar, matthias.bgg, beanhuo, linux-arm-kernel,
asutoshd
In-Reply-To: <158950485295.8169.36549719949053326.b4-ty@oracle.com>
Hi Martin,
On Thu, 2020-05-14 at 21:10 -0400, Martin K. Petersen wrote:
> On Sat, 9 May 2020 17:37:12 +0800, Stanley Chu wrote:
>
> > This patch set tries to allow vendors to modify the WriteBooster flush policy.
> >
> > In the same time, collect all customizable parameters to an unified structure to make UFS driver more clean.
> >
> > v1 -> v2:
> > - Squash patch [3] and [4]
> > - Remove a dummy "new line" in patch [3]
> > - Fix commit message in patch [3]
> >
> > [...]
>
> Applied to 5.8/scsi-queue, thanks!
>
> I had to combine patches 1 and 2. Otherwise you'd get compile
> failures due to the fields moving inside the struct.
>
> [1/4] scsi: ufs: Introduce ufs_hba_variant_params to group customizable parameters
> https://git.kernel.org/mkp/scsi/c/90b8491c0033
> [3/4] scsi: ufs: Customize flush threshold for WriteBooster
> https://git.kernel.org/mkp/scsi/c/d14734ae3ae7
> [4/4] scsi: ufs-mediatek: Customize WriteBooster flush policy
> https://git.kernel.org/mkp/scsi/c/f48b285ae658
>
Thanks so much for helping the patch squash.
Thanks,
Stanley Chu
_______________________________________________
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 0/4] scsi: ufs: allow customizable WriteBooster flush policy
From: Martin K. Petersen @ 2020-05-15 1:10 UTC (permalink / raw)
To: jejb, linux-scsi, alim.akhtar, Stanley Chu, asutoshd, avri.altman
Cc: bvanassche, Martin K . Petersen, andy.teng, chun-hung.wu,
kuohong.wang, linux-kernel, cang, linux-mediatek, peter.wang,
matthias.bgg, linux-arm-kernel, beanhuo
In-Reply-To: <20200509093716.21010-1-stanley.chu@mediatek.com>
On Sat, 9 May 2020 17:37:12 +0800, Stanley Chu wrote:
> This patch set tries to allow vendors to modify the WriteBooster flush policy.
>
> In the same time, collect all customizable parameters to an unified structure to make UFS driver more clean.
>
> v1 -> v2:
> - Squash patch [3] and [4]
> - Remove a dummy "new line" in patch [3]
> - Fix commit message in patch [3]
>
> [...]
Applied to 5.8/scsi-queue, thanks!
I had to combine patches 1 and 2. Otherwise you'd get compile
failures due to the fields moving inside the struct.
[1/4] scsi: ufs: Introduce ufs_hba_variant_params to group customizable parameters
https://git.kernel.org/mkp/scsi/c/90b8491c0033
[3/4] scsi: ufs: Customize flush threshold for WriteBooster
https://git.kernel.org/mkp/scsi/c/d14734ae3ae7
[4/4] scsi: ufs-mediatek: Customize WriteBooster flush policy
https://git.kernel.org/mkp/scsi/c/f48b285ae658
--
Martin K. Petersen Oracle Linux Engineering
_______________________________________________
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 -next] scsi: ufs-mediatek: Make ufs_mtk_fixup_dev_quirks static
From: Martin K. Petersen @ 2020-05-15 1:10 UTC (permalink / raw)
To: jejb, matthias.bgg, ChenTao, stanley.chu
Cc: Martin K . Petersen, linux-scsi, linux-kernel, avri.altman,
linux-mediatek, alim.akhtar, linux-arm-kernel
In-Reply-To: <20200514012655.127202-1-chentao107@huawei.com>
On Thu, 14 May 2020 09:26:55 +0800, ChenTao wrote:
> Fix the following warning:
>
> drivers/scsi/ufs/ufs-mediatek.c:585:6: warning:
> symbol 'ufs_mtk_fixup_dev_quirks' was not declared. Should it be static?
Applied to 5.8/scsi-queue, thanks!
[1/1] scsi: ufs-mediatek: Make ufs_mtk_fixup_dev_quirks static
https://git.kernel.org/mkp/scsi/c/21d2b76831fd
--
Martin K. Petersen Oracle Linux Engineering
_______________________________________________
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 v6] arm64: Expose FAR_EL1 tag bits in sigcontext
From: Peter Collingbourne @ 2020-05-15 0:58 UTC (permalink / raw)
To: Dave Martin
Cc: Andrey Konovalov, Kevin Brodsky, Kostya Serebryany, Linux ARM,
Catalin Marinas, Vincenzo Frascino, Will Deacon, Evgenii Stepanov,
Richard Henderson
In-Reply-To: <20200513202808.GY21779@arm.com>
On Wed, May 13, 2020 at 1:28 PM Dave Martin <Dave.Martin@arm.com> wrote:
>
> On Wed, May 13, 2020 at 11:09:14AM -0700, Peter Collingbourne wrote:
> > The kernel currently clears the tag bits (i.e. bits 56-63) in the fault
> > address exposed via siginfo.si_addr and sigcontext.fault_address. However,
> > the tag bits may be needed by tools in order to accurately diagnose
> > memory errors, such as HWASan [1] or future tools based on the Memory
> > Tagging Extension (MTE).
> >
> > We should not stop clearing these bits in the existing fault address fields,
> > because there may be existing userspace applications that are expecting the tag
> > bits to be cleared. Instead, create a fault_addr_top_byte_context in sigcontext
> > (similar to the existing esr_context), and store the tag bits of FAR_EL1 there.
> >
> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> >
> > Signed-off-by: Peter Collingbourne <pcc@google.com>
> > ---
> > v6:
> > - bring back comment about __reserved[]
> >
> > v5:
> > - add padding to fault_addr_top_byte_context in order to ensure the correct
> > size and preserve sp alignment
> >
> > v4:
> > - expose only the tag bits in the context instead of the entire FAR_EL1
> > - remove mention of the new context from the sigcontext.__reserved[] note
> >
> > v3:
> > - add documentation to tagged-pointers.rst
> > - update comments in sigcontext.h
> >
> > v2:
> > - revert changes to hw_breakpoint.c
> > - rename set_thread_esr to set_thread_far_esr
> >
> > Documentation/arm64/tagged-pointers.rst | 17 +++++----
> > arch/arm64/include/asm/exception.h | 2 +-
> > arch/arm64/include/asm/processor.h | 2 +-
> > arch/arm64/include/uapi/asm/sigcontext.h | 22 ++++++++----
> > arch/arm64/kernel/entry-common.c | 2 --
> > arch/arm64/kernel/signal.c | 22 +++++++++++-
> > arch/arm64/mm/fault.c | 45 ++++++++++++++----------
> > 7 files changed, 77 insertions(+), 35 deletions(-)
> >
> > diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
> > index eab4323609b9..c6e9592a9dea 100644
> > --- a/Documentation/arm64/tagged-pointers.rst
> > +++ b/Documentation/arm64/tagged-pointers.rst
> > @@ -53,12 +53,17 @@ visibility.
> > Preserving tags
> > ---------------
> >
> > -Non-zero tags are not preserved when delivering signals. This means that
> > -signal handlers in applications making use of tags cannot rely on the
> > -tag information for user virtual addresses being maintained for fields
> > -inside siginfo_t. One exception to this rule is for signals raised in
> > -response to watchpoint debug exceptions, where the tag information will
> > -be preserved.
> > +Non-zero tags are not preserved in the fault address fields
> > +siginfo.si_addr or sigcontext.fault_address when delivering
> > +signals. This means that signal handlers in applications making use
> > +of tags cannot rely on the tag information for user virtual addresses
> > +being maintained in these fields. One exception to this rule is for
> > +signals raised in response to watchpoint debug exceptions, where the
> > +tag information will be preserved.
> > +
> > +The fault address tag is preserved in the fault_addr_top_byte field of
> > +the signal frame record fault_addr_top_byte_context, which is present
> > +for signals raised in response to data aborts and instruction aborts.
> >
> > The architecture prevents the use of a tagged PC, so the upper byte will
> > be set to a sign-extension of bit 55 on exception return.
> > diff --git a/arch/arm64/include/asm/exception.h b/arch/arm64/include/asm/exception.h
> > index 7a6e81ca23a8..90e772d9b2cd 100644
> > --- a/arch/arm64/include/asm/exception.h
> > +++ b/arch/arm64/include/asm/exception.h
> > @@ -32,7 +32,7 @@ static inline u32 disr_to_esr(u64 disr)
> > }
> >
> > asmlinkage void enter_from_user_mode(void);
> > -void do_mem_abort(unsigned long addr, unsigned int esr, struct pt_regs *regs);
> > +void do_mem_abort(unsigned long far, unsigned int esr, struct pt_regs *regs);
> > void do_undefinstr(struct pt_regs *regs);
> > asmlinkage void bad_mode(struct pt_regs *regs, int reason, unsigned int esr);
> > void do_debug_exception(unsigned long addr_if_watchpoint, unsigned int esr,
> > diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> > index 240fe5e5b720..63185be29ff9 100644
> > --- a/arch/arm64/include/asm/processor.h
> > +++ b/arch/arm64/include/asm/processor.h
> > @@ -144,7 +144,7 @@ struct thread_struct {
> > void *sve_state; /* SVE registers, if any */
> > unsigned int sve_vl; /* SVE vector length */
> > unsigned int sve_vl_onexec; /* SVE vl after next exec */
> > - unsigned long fault_address; /* fault info */
> > + unsigned long fault_address; /* FAR_EL1 value */
> > unsigned long fault_code; /* ESR_EL1 value */
> > struct debug_info debug; /* debugging */
> > #ifdef CONFIG_ARM64_PTR_AUTH
> > diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
> > index 8b0ebce92427..2a3fe3de899d 100644
> > --- a/arch/arm64/include/uapi/asm/sigcontext.h
> > +++ b/arch/arm64/include/uapi/asm/sigcontext.h
> > @@ -44,11 +44,12 @@ struct sigcontext {
> > *
> > * 0x210 fpsimd_context
> > * 0x10 esr_context
> > + * 0x10 fault_addr_top_byte_context
> > * 0x8a0 sve_context (vl <= 64) (optional)
> > * 0x20 extra_context (optional)
> > * 0x10 terminator (null _aarch64_ctx)
> > *
> > - * 0x510 (reserved for future allocation)
> > + * 0x500 (reserved for future allocation)
> > *
> > * New records that can exceed this space need to be opt-in for userspace, so
> > * that an expanded signal frame is not generated unexpectedly. The mechanism
> > @@ -94,17 +95,26 @@ struct esr_context {
> > __u64 esr;
> > };
> >
> > +/* Top byte of fault address (normally not exposed via si_addr) */
> > +#define FAULT_ADDR_TOP_BYTE_MAGIC 0x46544201
> > +
> > +struct fault_addr_top_byte_context {
> > + struct _aarch64_ctx head;
> > + __u8 fault_addr_top_byte;
> > + __u8 __reserved[7];
> > +};
> > +
>
> Nit: the name here is a bit cumbersome (obviously bikeshedding...)
>
>
> For the rest, some of my comments may be bogus -- I haven't dug into
> this stuff for a little while!
>
>
> Anyway:
>
> Do we really get the whole top byte of the address in the FAR? If so,
> fine, but I'm having trouble finding a clear statement in the
> architecture one way or the other. (I didn't attempt to dive into the
> pseudocode.)
I rely on this statement in the ARM:
https://developer.arm.com/docs/ddi0595/b/aarch64-system-registers/far_el1
"For a Data Abort or Watchpoint exception, if address tagging is
enabled for the address accessed by the data access that caused the
exception, then this field includes the tag."
And note that address tagging here essentially means TBI (which is
always enabled on Linux), and not memory tagging.
> Also, since we're burning 16 bytes here, I'd prefer if we make this
> extensible. At present the __reserved[7] is unusable because
> userspace has no way to know whether it's valid or not.
>
> Options include an additional flag byte (0 for now), or just making
> the whole thing a __u64. In that case we can leave the top byte bits
> in their original positions if we want, but it would be a good idea to
> include a flag to say that field is valid at all. (See comments below
> on Synchronous external abort.)
>
> So, say, foo_context->fault_info = (esr & (~0ULL << 56)) | TOP_BYTE_VALID.
> (with #defines for the bits/fields as appropriate).
The flag bits seem like a good idea. Thinking ahead to the MTE sync
tag fault (which might not provide us with bits 60-63), we may
consider having separate bits to indicate "bits 56-59 valid" and "bits
60-63 valid", set both bits for regular data aborts and only the
former for sync tag faults, which would avoid the need to define a
separate context for these faults. And if a future architecture
revision provides us with bits 60-63 for tag faults, we could start
setting both flag bits even for tag faults.
> > /*
> > * extra_context: describes extra space in the signal frame for
> > * additional structures that don't fit in sigcontext.__reserved[].
> > *
> > * Note:
> > *
> > - * 1) fpsimd_context, esr_context and extra_context must be placed in
> > - * sigcontext.__reserved[] if present. They cannot be placed in the
> > - * extra space. Any other record can be placed either in the extra
> > - * space or in sigcontext.__reserved[], unless otherwise specified in
> > - * this file.
> > + * 1) fpsimd_context, esr_context, fault_addr_top_byte_context and
> > + * extra_context must be placed in sigcontext.__reserved[] if present.
> > + * They cannot be placed in the extra space. Any other record can be
> > + * placed either in the extra space or in sigcontext.__reserved[],
> > + * unless otherwise specified in this file.
> > *
> > * 2) There must not be more than one extra_context.
> > *
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index c839b5bf1904..045b4f518836 100644
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -22,7 +22,6 @@ static void notrace el1_abort(struct pt_regs *regs, unsigned long esr)
> > unsigned long far = read_sysreg(far_el1);
> >
> > local_daif_inherit(regs);
> > - far = untagged_addr(far);
> > do_mem_abort(far, esr, regs);
> > }
> > NOKPROBE_SYMBOL(el1_abort);
> > @@ -104,7 +103,6 @@ static void notrace el0_da(struct pt_regs *regs, unsigned long esr)
> >
> > user_exit_irqoff();
> > local_daif_restore(DAIF_PROCCTX);
> > - far = untagged_addr(far);
> > do_mem_abort(far, esr, regs);
> > }
> > NOKPROBE_SYMBOL(el0_da);
> > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> > index 339882db5a91..baa88dc02e5c 100644
> > --- a/arch/arm64/kernel/signal.c
> > +++ b/arch/arm64/kernel/signal.c
> > @@ -55,6 +55,7 @@ struct rt_sigframe_user_layout {
> >
> > unsigned long fpsimd_offset;
> > unsigned long esr_offset;
> > + unsigned long ftb_offset;
> > unsigned long sve_offset;
> > unsigned long extra_offset;
> > unsigned long end_offset;
> > @@ -383,6 +384,7 @@ static int parse_user_sigframe(struct user_ctxs *user,
> > break;
> >
> > case ESR_MAGIC:
> > + case FAULT_ADDR_TOP_BYTE_MAGIC:
> > /* ignore */
> > break;
> >
> > @@ -581,6 +583,12 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
> > sizeof(struct esr_context));
> > if (err)
> > return err;
> > +
> > + err = sigframe_alloc(
> > + user, &user->ftb_offset,
> > + sizeof(struct fault_addr_top_byte_context));
>
> Nit: inconsistent indentation?
>
> (Mostly just because it makes the change look odd against the hunk
> context, but not a big deal.)
With consistent indentation we violate 80 cols due to the extra long
struct name. The indentation is what clang-format is giving me.
> > + if (err)
> > + return err;
> > }
> >
> > if (system_supports_sve()) {
> > @@ -621,7 +629,8 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
> > __put_user_error(regs->pc, &sf->uc.uc_mcontext.pc, err);
> > __put_user_error(regs->pstate, &sf->uc.uc_mcontext.pstate, err);
> >
> > - __put_user_error(current->thread.fault_address, &sf->uc.uc_mcontext.fault_address, err);
> > + __put_user_error(untagged_addr(current->thread.fault_address),
> > + &sf->uc.uc_mcontext.fault_address, err);
> >
> > err |= __copy_to_user(&sf->uc.uc_sigmask, set, sizeof(*set));
> >
> > @@ -641,6 +650,17 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
> > __put_user_error(current->thread.fault_code, &esr_ctx->esr, err);
> > }
> >
> > + if (err == 0 && user->ftb_offset) {
> > + struct fault_addr_top_byte_context __user *ftb_ctx =
> > + apply_user_offset(user, user->ftb_offset);
> > +
> > + __put_user_error(FAULT_ADDR_TOP_BYTE_MAGIC,
> > + &ftb_ctx->head.magic, err);
> > + __put_user_error(sizeof(*ftb_ctx), &ftb_ctx->head.size, err);
> > + __put_user_error(current->thread.fault_address >> 56,
> > + &ftb_ctx->fault_addr_top_byte, err);
> > + }
> > +
>
> How do we handle the fact that the top byte of FAR is sometimes UNKNOWN?
>
> For Synchronous external aborts in particular, those bits are documented
> as UNKNOWN, but I don't see any special handling, There may be other
> cases I haven't spotted.
>
> For preference we can omit this record entirely if we don't have any
> information we can report, but certainly we shouldn't expose UNKNOWN
> bits.
In this case we mask out the top byte in do_sea before passing the
address to arm64_notify_die (which clears fault_address and passes the
address argument on to arm64_force_sig_fault to be exposed via
si_addr). So the record would always contain a 0 byte. It seems
reasonable to omit the record in this case instead.
> [ Aside:
>
> Also, what if we're not reporting a memory abort at all? Does
> thread.fault_address just contain junk from the last fault? I see
> nothing anywhere that cleans this up. (This is historical and not
> your fault, but it would be good to close this down while we're about
> it.)
>
>
> Hmmm, looking at the code I think we probably leak fault_address etc.
> across execve() too, so it may even be stale junk from an old process
> :/
>
> Maybe I just confused myself.
>
> End aside. ]
Yes, it's unclear whether we always manage to not expose a fault
address if we're not reporting a data or instruction abort. The code
would need to arrange for fault_code to be set to 0 in order to avoid
exposing previous fault_address values via future signals. I don't see
anywhere where we're resetting these fields after delivering a signal,
so it seems possible by calling arm64_force_sig_fault without first
setting fault_code (most callers do this, but the calls in
arch/arm64/kernel/debug-monitors.c and arch/arm64/kernel/ptrace.c seem
not to), or simply by calling force_sig_fault (which happens in many
places throughout the kernel).
Maybe something like this would do the trick? (Untested, and forgive
spaces instead of tabs, grumble grumble gmail):
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index baa88dc02e5c..5867f2fdbe64 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -648,6 +648,7 @@ static int setup_sigframe(struct
rt_sigframe_user_layout *user,
__put_user_error(ESR_MAGIC, &esr_ctx->head.magic, err);
__put_user_error(sizeof(*esr_ctx), &esr_ctx->head.size, err);
__put_user_error(current->thread.fault_code,
&esr_ctx->esr, err);
+ current->thread.fault_code = 0;
}
if (err == 0 && user->ftb_offset) {
> Apart from these issues, the actual code looks reasonable.
Thanks for the review.
Peter
_______________________________________________
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 v4 1/4] KEYS: trusted: Add generic trusted keys framework
From: Jarkko Sakkinen @ 2020-05-15 0:00 UTC (permalink / raw)
To: Sumit Garg
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, op-tee,
Jonathan Corbet, James Bottomley, Janne Karhunen,
Linux Doc Mailing List, James Morris, Mimi Zohar,
Linux Kernel Mailing List, dhowells, linux-security-module,
open list:ASYMMETRIC KEYS, Markus Wamser, Casey Schaufler,
linux-integrity, Jens Wiklander, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAFA6WYMciZ=qkG3N_9YWzt_DJr2dGwdAy9diMXCJSNjr2o5ONA@mail.gmail.com>
On Thu, 2020-05-14 at 16:53 +0530, Sumit Garg wrote:
> On Thu, 14 May 2020 at 05:55, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> > On Wed, 2020-05-06 at 15:10 +0530, Sumit Garg wrote:
> > > Current trusted keys framework is tightly coupled to use TPM device as
> > > an underlying implementation which makes it difficult for implementations
> > > like Trusted Execution Environment (TEE) etc. to provide trusked keys
> > > support in case platform doesn't posses a TPM device.
> > >
> > > So this patch tries to add generic trusted keys framework where underlying
> > > implemtations like TPM, TEE etc. could be easily plugged-in.
> > >
> > > Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >
> > I tend to agree how this is implemented and could merge it as such.
> >
> > I'm just thinking if we could refine this patch in a way that instead of
> > copying TRUSTED_DEBUG macro we could just replace pr_info() statements
> > with pr_debug()?
>
> AFAIU, TRUSTED_DEBUG being a security sensitive operation is only
> meant to be used in development environments and should be strictly
> disabled in production environments. But it may not always be true
> with pr_debug() with CONFIG_DYNAMIC_DEBUG=y which allows the debug
> paths to be compiled into the kernel which can be enabled/disabled at
> runtime.
>
> IMO we should keep this TRUSTED_DEBUG macro, so that users are aware
> of its security sensitive nature and need to explicitly enable it to
> debug.
You are absolutely correct.
/Jarkko
_______________________________________________
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 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
From: Jarkko Sakkinen @ 2020-05-14 23:43 UTC (permalink / raw)
To: Sumit Garg
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, op-tee,
Jonathan Corbet, James Bottomley, Janne Karhunen,
Linux Doc Mailing List, James Morris, Mimi Zohar,
Linux Kernel Mailing List, dhowells, linux-security-module,
open list:ASYMMETRIC KEYS, Markus Wamser, Casey Schaufler,
linux-integrity, Jens Wiklander, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAFA6WYPr1iL-uJgSRu_61uv=2DhuEdDVdQLDuyPEOOK2jEgvyg@mail.gmail.com>
On Thu, 2020-05-14 at 12:57 +0530, Sumit Garg wrote:
> On Thu, 14 May 2020 at 05:58, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> > On Wed, 2020-05-06 at 15:10 +0530, Sumit Garg wrote:
> > > Add support for TEE based trusted keys where TEE provides the functionality
> > > to seal and unseal trusted keys using hardware unique key.
> > >
> > > Refer to Documentation/tee.txt for detailed information about TEE.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >
> > The implementation looks solid but how or who could possibly test this?
> >
> > I do posses (personally, not from employer) bunch of ARM boards but my
> > TZ knowledge is somewhat limited (e.g. how can I get something running
> > in TZ).
> >
>
> Although, it should be fairly easy to test this implementation on an
> ARM board which supports OP-TEE. But since you are new to ARM
> TrustZone world, I would suggest you get used to OP-TEE on Qemu based
> setup. You could find pretty good documentation for this here [1] but
> for simplicity let me document steps here to test this trusted keys
> feature from scratch:
>
> # Install prerequisites as mentioned here [2]
>
> # Get the source code
> $ mkdir -p <optee-project>
> $ cd <optee-project>
> $ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
> $ repo sync -j4 --no-clone-bundle
>
> # Get the toolchain
> $ cd <optee-project>/build
> $ make -j2 toolchains
>
> # As trusted keys work is based on latest tpmdd/master, so we can
> change Linux base as follows:
> $ cd <optee-project>/linux
> $ git remote add tpmdd git://git.infradead.org/users/jjs/linux-tpmdd.git
> $ git pull tpmdd
> $ git checkout -b tpmdd-master remotes/tpmdd/master
> # Cherry-pick and apply TEE features patch-set from this PR[3]
> # Apply this Linux trusted keys patch-set.
>
> # Now move on to build the source code
> $ cd <optee-project>/build
> # Apply attached "keyctl_change" patch
> $ patch -p1 < keyctl_change
> $ make -j`nproc`
> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
>
> # Run QEMU setup
> $ make run-only
> # Type "c" on QEMU console to continue boot
>
> # Now there should be two virtual consoles up, one for OP-TEE and
> other for Linux
> # On Linux console, you can play with "keyctl" utility to have trusted
> and encrypted keys based on TEE.
>
> Do let me know in case you are stuck while following the above steps.
>
> [1] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> [2] https://optee.readthedocs.io/en/latest/building/prerequisites.html#prerequisites
> [3] https://lkml.org/lkml/2020/5/4/1062
>
> -Sumit
Thanks I'll try this out as soon as the v5.8 release hassle is over!
/Jarkko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: ARM: static kernel in vmalloc space
From: Russell King - ARM Linux admin @ 2020-05-14 23:40 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: afzal mohammed, linux-kernel@vger.kernel.org, Linux ARM
In-Reply-To: <CAK8P3a2KR+O5Ua5hsNgzLQV5-V1pat6JH_WM10Es-oUhXO2OgA@mail.gmail.com>
On Thu, May 14, 2020 at 11:12:01PM +0200, Arnd Bergmann wrote:
> On Thu, May 14, 2020 at 6:25 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 14, 2020 at 1:18 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
>
> > > It's clearly possible to do something very similar for older chips
> > > (v6 or v7 without LPAE, possibly even v5), it just gets harder
> > > while providing less benefit.
> >
> > Forget about doing this for anything without a PIPT cache - or you're
> > going to end up having to flush the data cache each time you enter or
> > exit the kernel.
>
> Right, let's forget I said anything about v5 or earlier ;-)
>
> I expected the non-aliasing VIPT caches to work the same as PIPT, can
> you clarify if there is something to be aware of for those? I see that some
> ARMv8 chips and most ARMv6 chips (not OMAP2 and Realview) are
> of that kind, and at we clearly don't want to break running on ARMv8 at
> least.
There are some aliasing VIPT implementations on ARMv6, but I don't
remember how common.
> Anyway my point was that it's best to only do it for LPAE anyway, everything
> else being a distraction, as the only non-LPAE SoCs I could find with
> support for over 2GB are some of the higher-end i.MX6 versions and the
> original highbank.
Yep.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 4/4] gpio: xilinx: Utilize for_each_set_clump macro
From: Syed Nayyar Waris @ 2020-05-14 23:21 UTC (permalink / raw)
To: akpm
Cc: linux-gpio, linux-kernel, linus.walleij, vilhelm.gray,
michal.simek, bgolaszewski, andriy.shevchenko, linux-arm-kernel
In-Reply-To: <cover.1589497311.git.syednwaris@gmail.com>
This patch reimplements the xgpio_set_multiple function in
drivers/gpio/gpio-xilinx.c to use the new for_each_set_clump macro.
Instead of looping for each bit in xgpio_set_multiple
function, now we can check each channel at a time and save cycles.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Syed Nayyar Waris <syednwaris@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
Changes in v6:
- No change.
Changes in v5:
- Minor change: Inline values '32' and '64' in code for better
code readability.
Changes in v4:
- Minor change: Inline values '32' and '64' in code for better
code readability.
Changes in v3:
- No change.
Changes in v2:
- No change.
drivers/gpio/gpio-xilinx.c | 62 ++++++++++++++++++++------------------
1 file changed, 32 insertions(+), 30 deletions(-)
diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index 67f9f82e0db0..e81092dea27e 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -136,39 +136,41 @@ static void xgpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
static void xgpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
unsigned long *bits)
{
- unsigned long flags;
+ unsigned long flags[2];
struct xgpio_instance *chip = gpiochip_get_data(gc);
- int index = xgpio_index(chip, 0);
- int offset, i;
-
- spin_lock_irqsave(&chip->gpio_lock[index], flags);
-
- /* Write to GPIO signals */
- for (i = 0; i < gc->ngpio; i++) {
- if (*mask == 0)
- break;
- /* Once finished with an index write it out to the register */
- if (index != xgpio_index(chip, i)) {
- xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
- index * XGPIO_CHANNEL_OFFSET,
- chip->gpio_state[index]);
- spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
- index = xgpio_index(chip, i);
- spin_lock_irqsave(&chip->gpio_lock[index], flags);
- }
- if (__test_and_clear_bit(i, mask)) {
- offset = xgpio_offset(chip, i);
- if (test_bit(i, bits))
- chip->gpio_state[index] |= BIT(offset);
- else
- chip->gpio_state[index] &= ~BIT(offset);
- }
+ u32 *const state = chip->gpio_state;
+ unsigned int *const width = chip->gpio_width;
+ unsigned long offset, clump;
+ size_t index;
+
+ DECLARE_BITMAP(old, 64);
+ DECLARE_BITMAP(new, 64);
+ DECLARE_BITMAP(changed, 64);
+
+ spin_lock_irqsave(&chip->gpio_lock[0], flags[0]);
+ spin_lock_irqsave(&chip->gpio_lock[1], flags[1]);
+
+ bitmap_set_value(old, state[0], 0, width[0]);
+ bitmap_set_value(old, state[1], width[0], width[1]);
+ bitmap_replace(new, old, bits, mask, gc->ngpio);
+
+ bitmap_set_value(old, state[0], 0, 32);
+ bitmap_set_value(old, state[1], 32, 32);
+ state[0] = bitmap_get_value(new, 0, width[0]);
+ state[1] = bitmap_get_value(new, width[0], width[1]);
+ bitmap_set_value(new, state[0], 0, 32);
+ bitmap_set_value(new, state[1], 32, 32);
+ bitmap_xor(changed, old, new, 64);
+
+ for_each_set_clump(offset, clump, changed, 64, 32) {
+ index = offset / 32;
+ xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
+ index * XGPIO_CHANNEL_OFFSET,
+ state[index]);
}
- xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET +
- index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]);
-
- spin_unlock_irqrestore(&chip->gpio_lock[index], flags);
+ spin_unlock_irqrestore(&chip->gpio_lock[1], flags[1]);
+ spin_unlock_irqrestore(&chip->gpio_lock[0], flags[0]);
}
/**
--
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
* [PATCH v6 0/4] Introduce the for_each_set_clump macro
From: Syed Nayyar Waris @ 2020-05-14 23:16 UTC (permalink / raw)
To: akpm
Cc: linux-arch, amit.kucheria, arnd, yamada.masahiro, linux-kernel,
linus.walleij, daniel.lezcano, vilhelm.gray, michal.simek,
bgolaszewski, rrichter, linux-gpio, linux-pm, rui.zhang,
andriy.shevchenko, linux-arm-kernel
This patchset introduces a new generic version of for_each_set_clump.
The previous version of for_each_set_clump8 used a fixed size 8-bit
clump, but the new generic version can work with clump of any size but
less than or equal to BITS_PER_LONG. The patchset utilizes the new macro
in several GPIO drivers.
The earlier 8-bit for_each_set_clump8 facilitated a
for-loop syntax that iterates over a memory region entire groups of set
bits at a time.
For example, suppose you would like to iterate over a 32-bit integer 8
bits at a time, skipping over 8-bit groups with no set bit, where
XXXXXXXX represents the current 8-bit group:
Example: 10111110 00000000 11111111 00110011
First loop: 10111110 00000000 11111111 XXXXXXXX
Second loop: 10111110 00000000 XXXXXXXX 00110011
Third loop: XXXXXXXX 00000000 11111111 00110011
Each iteration of the loop returns the next 8-bit group that has at
least one set bit.
But with the new for_each_set_clump the clump size can be different from 8 bits.
Moreover, the clump can be split at word boundary in situations where word
size is not multiple of clump size. Following are examples showing the working
of new macro for clump sizes of 24 bits and 6 bits.
Example 1:
clump size: 24 bits, Number of clumps (or ports): 10
bitmap stores the bit information from where successive clumps are retrieved.
/* bitmap memory region */
0x00aa0000ff000000; /* Most significant bits */
0xaaaaaa0000ff0000;
0x000000aa000000aa;
0xbbbbabcdeffedcba; /* Least significant bits */
Different iterations of for_each_set_clump:-
'offset' is the bit position and 'clump' is the 24 bit clump from the
above bitmap.
Iteration first: offset: 0 clump: 0xfedcba
Iteration second: offset: 24 clump: 0xabcdef
Iteration third: offset: 48 clump: 0xaabbbb
Iteration fourth: offset: 96 clump: 0xaa
Iteration fifth: offset: 144 clump: 0xff
Iteration sixth: offset: 168 clump: 0xaaaaaa
Iteration seventh: offset: 216 clump: 0xff
Loop breaks because in the end the remaining bits (0x00aa) size was less
than clump size of 24 bits.
In above example it can be seen that in iteration third, the 24 bit clump
that was retrieved was split between bitmap[0] and bitmap[1]. This example
also shows that 24 bit zeroes if present in between, were skipped (preserving
the previous for_each_set_macro8 behaviour).
Example 2:
clump size = 6 bits, Number of clumps (or ports) = 3.
/* bitmap memory region */
0x00aa0000ff000000; /* Most significant bits */
0xaaaaaa0000ff0000;
0x0f00000000000000;
0x0000000000000ac0; /* Least significant bits */
Different iterations of for_each_set_clump:
'offset' is the bit position and 'clump' is the 6 bit clump from the
above bitmap.
Iteration first: offset: 6 clump: 0x2b
Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
Here 6 * 3 is clump size * no. of clumps.
Changes in v6:
- [Patch 2/4]: Make 'for loop' inside test_for_each_set_clump more
succinct.
Changes in v5:
- [Patch 4/4]: Minor change: Hardcode value for better code readability.
Changes in v4:
- [Patch 2/4]: Use 'for' loop in test function of for_each_set_clump.
- [Patch 3/4]: Minor change: Inline value for better code readability.
- [Patch 4/4]: Minor change: Inline value for better code readability.
Changes in v3:
- [Patch 3/4]: Change datatype of some variables from u64 to unsigned long
in function thunderx_gpio_set_multiple.
CHanges in v2:
- [Patch 2/4]: Unify different tests for 'for_each_set_clump'. Pass test data as
function parameters.
- [Patch 2/4]: Remove unnecessary bitmap_zero calls.
Syed Nayyar Waris (4):
bitops: Introduce the the for_each_set_clump macro
lib/test_bitmap.c: Add for_each_set_clump test cases
gpio: thunderx: Utilize for_each_set_clump macro
gpio: xilinx: Utilize for_each_set_clump macro
drivers/gpio/gpio-thunderx.c | 11 ++-
drivers/gpio/gpio-xilinx.c | 62 ++++++-------
include/asm-generic/bitops/find.h | 19 ++++
include/linux/bitmap.h | 61 +++++++++++++
include/linux/bitops.h | 13 +++
lib/find_bit.c | 14 +++
lib/test_bitmap.c | 142 ++++++++++++++++++++++++++++++
7 files changed, 288 insertions(+), 34 deletions(-)
base-commit: 5f458e572071a54841b93f41e25fbe8ded82df79
--
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
* Re: [PATCH 1/2] hwrng: iproc-rng200 - Set the quality value
From: Lukasz Stelmach @ 2020-05-14 22:18 UTC (permalink / raw)
To: Stephan Mueller
Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger,
Greg Kroah-Hartman, Matt Mackall, linux-kernel,
Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz,
Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui,
bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel,
linux-crypto
In-Reply-To: <4493123.C11H8YMYNy@tauon.chronox.de>
[-- Attachment #1.1: Type: text/plain, Size: 2351 bytes --]
It was <2020-05-14 czw 22:20>, when Stephan Mueller wrote:
> Am Donnerstag, 14. Mai 2020, 21:07:33 CEST schrieb Łukasz Stelmach:
>
> Hi Łukasz,
>
>> The value has been estimaded by obtainig 1024 chunks of data 128 bytes
>> (1024 bits) each from the generator and finding chunk with minimal
>> entropy using the ent(1) tool. The value was 6.327820 bits of entropy
>> in each 8 bits of data.
>
> I am not sure we should use the ent tool to define the entropy
> level. Ent seems to use a very coarse entropy estimation.
>
> I would feel more comfortable when using other measures like SP800-90B
> which even provides a tool for the analysis.
>
> I understand that entropy estimates, well, are estimates. But the ent
> data is commonly not very conservative.
>
> [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment
Thank you for pointing this out.
I am running tests using SP800-90B tools and the first issue I can see
is the warning that samples contain less than 1e6 bytes of data. I know
little about maths behind random number generators, but I have noticed
that the bigger chunk of data from an RNG I feed into either ent or ea_iid
the higher entropy they report. That is why I divided the data into 1024
bit chunks in the first place. To get worse results. With ea_iid they
get even worse (128 bytes of random data)
Calculating baseline statistics...
H_original: 4.107376
H_bitstring: 0.795122
min(H_original, 8 X H_bitstring): 4.107376
but I don't know how much I can trust it, when I get such warning
*** Warning: data contains less than 1000000 samples ***
ea_non_iid refuses to run tests with less than 4096 bytes of input.
I may suspect that lack of any warnings from ent doesn't make its
results any more reliable.
Anyway. I collected 1024 files 1024 bits each once again and ran the
following tests
for f in exynos-trng/random*; do ./ea_iid "$f" | grep ^min; done | sort | head -1
for f in rng200/random*; do ./ea_iid "$f" | grep ^min; done | sort | head -1
For both RNGs I got the same
min(H_original, 8 X H_bitstring): 3.393082
which, if I understand correctly, means I should set quality to no more
than 434. Do you think 400 is OK?
Kind regards,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: defconfig: enable CONFIG_PCIE_RCAR_HOST
From: Lad Prabhakar @ 2020-05-14 22:10 UTC (permalink / raw)
To: Geert Uytterhoeven, Catalin Marinas, Will Deacon
Cc: linux-renesas-soc, Prabhakar Lad, linux-kernel, linux-arm-kernel,
Lad Prabhakar
config option PCIE_RCAR internally selects PCIE_RCAR_HOST which builds the
same driver. So this patch renames CONFIG_PCIE_RCAR to
CONFIG_PCIE_RCAR_HOST so that PCIE_RCAR can be safely dropped from Kconfig
file.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
arch/arm64/configs/defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 5b674a0..ccc0836 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -193,7 +193,7 @@ CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_PCI_AARDVARK=y
CONFIG_PCI_TEGRA=y
-CONFIG_PCIE_RCAR=y
+CONFIG_PCIE_RCAR_HOST=y
CONFIG_PCI_HOST_GENERIC=y
CONFIG_PCI_XGENE=y
CONFIG_PCIE_ALTERA=y
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: ARM: static kernel in vmalloc space
From: Arnd Bergmann @ 2020-05-14 21:12 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: afzal mohammed, linux-kernel@vger.kernel.org, Linux ARM
In-Reply-To: <20200514162535.GP1551@shell.armlinux.org.uk>
On Thu, May 14, 2020 at 6:25 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote:
> > On Thu, May 14, 2020 at 1:18 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> > It's clearly possible to do something very similar for older chips
> > (v6 or v7 without LPAE, possibly even v5), it just gets harder
> > while providing less benefit.
>
> Forget about doing this for anything without a PIPT cache - or you're
> going to end up having to flush the data cache each time you enter or
> exit the kernel.
Right, let's forget I said anything about v5 or earlier ;-)
I expected the non-aliasing VIPT caches to work the same as PIPT, can
you clarify if there is something to be aware of for those? I see that some
ARMv8 chips and most ARMv6 chips (not OMAP2 and Realview) are
of that kind, and at we clearly don't want to break running on ARMv8 at
least.
Anyway my point was that it's best to only do it for LPAE anyway, everything
else being a distraction, as the only non-LPAE SoCs I could find with
support for over 2GB are some of the higher-end i.MX6 versions and the
original highbank.
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 v3 4/5] clk: stm32: Fix stm32f429 ltdc driver loading hang in clk set rate. keep ltdc clk running after kernel startup
From: Stephen Boyd @ 2020-05-14 21:02 UTC (permalink / raw)
To: airlied, alexandre.torgue, daniel, dillon.minfei, mcoquelin.stm32,
mturquette, robh+dt, sam, thierry.reding
Cc: devicetree, linux-kernel, dri-devel, linux-stm32, dillon.minfei,
linux-clk, linux-arm-kernel
In-Reply-To: <1589267017-17294-5-git-send-email-dillon.minfei@gmail.com>
Quoting dillon.minfei@gmail.com (2020-05-12 00:03:36)
> From: dillon min <dillon.minfei@gmail.com>
>
> as store stm32f4_rcc_register_pll return to the wrong offset of clks,
Use () on functions, i.e. stm32f4_rcc_register_pll().
> so ltdc gate clk is null. need change clks[PLL_VCO_SAI] to clks[PLL_SAI]
And quote variables like 'clks[PLL_VCO_SAI]'
>
> add CLK_IGNORE_UNUSED for ltdc to make sure clk not be freed by
> clk_disable_unused
clk_disable_unused() doesn't free anything. Why does ltdc not need to be
turned off if it isn't used? Is it critical to system operation? Should
it be marked with the critical clk flag then? The CLK_IGNORE_UNUSED flag
is almost always wrong to use.
>
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
> drivers/clk/clk-stm32f4.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> index 18117ce..0ba73de 100644
> --- a/drivers/clk/clk-stm32f4.c
> +++ b/drivers/clk/clk-stm32f4.c
> @@ -129,7 +129,8 @@ static const struct stm32f4_gate_data stm32f429_gates[] __initconst = {
> { STM32F4_RCC_APB2ENR, 20, "spi5", "apb2_div" },
> { STM32F4_RCC_APB2ENR, 21, "spi6", "apb2_div" },
> { STM32F4_RCC_APB2ENR, 22, "sai1", "apb2_div" },
> - { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
> + { STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div",
> + CLK_IGNORE_UNUSED },
> };
>
> static const struct stm32f4_gate_data stm32f469_gates[] __initconst = {
> @@ -1757,7 +1758,7 @@ static void __init stm32f4_rcc_init(struct device_node *np)
> clks[PLL_VCO_I2S] = stm32f4_rcc_register_pll("vco_in",
> &data->pll_data[1], &stm32f4_clk_lock);
>
> - clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll("vco_in",
> + clks[PLL_SAI] = stm32f4_rcc_register_pll("vco_in",
> &data->pll_data[2], &stm32f4_clk_lock);
>
> for (n = 0; n < MAX_POST_DIV; n++) {
_______________________________________________
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 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
From: Laurent Pinchart @ 2020-05-14 20:55 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Chun-Kuang Hu, Nicolas Boichat, Daniel Vetter,
Enric Balletbo Serra, linux-kernel, dri-devel, David Airlie,
moderated list:ARM/Mediatek SoC support, Philipp Zabel,
Hsin-Yi Wang, Matthias Brugger, Collabora Kernel ML, Sam Ravnborg,
Linux ARM
In-Reply-To: <e1ac7d75-c46a-445a-5fcf-5253548f2707@collabora.com>
Hi Enric,
On Thu, May 14, 2020 at 07:35:33PM +0200, Enric Balletbo i Serra wrote:
> On 14/5/20 19:12, Enric Balletbo i Serra wrote:
> > On 14/5/20 18:44, Chun-Kuang Hu wrote:
> >> Enric Balletbo i Serra <enric.balletbo@collabora.com> 於 2020年5月14日 週四 下午11:42寫道：
> >>> On 14/5/20 16:28, Chun-Kuang Hu wrote:
> >>>> Enric Balletbo Serra <eballetbo@gmail.com> 於 2020年5月14日 週四 上午12:41寫道：
> >>>>> Missatge de Enric Balletbo i Serra <enric.balletbo@collabora.com> del
> >>>>> dia dv., 1 de maig 2020 a les 17:25:
> >>>>>>
> >>>>>> Use the drm_bridge_connector helper to create a connector for pipelines
> >>>>>> that use drm_bridge. This allows splitting connector operations across
> >>>>>> multiple bridges when necessary, instead of having the last bridge in
> >>>>>> the chain creating the connector and handling all connector operations
> >>>>>> internally.
> >>>>>>
> >>>>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>>>>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> >>>>>
> >>>>> A gentle ping on this, I think that this one is the only one that
> >>>>> still needs a review in the series.
> >>>>
> >>>> This is what I reply in patch v3:
> >>>
> >>> Sorry for missing this.
> >>>
> >>>> I think the panel is wrapped into next_bridge here,
> >>>
> >>> Yes, you can have for example:
> >>>
> >>> 1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) -> drm_panel_bridge
> >>> (edp panel)
> >>>
> >>> or a
> >>>
> >>> 2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel)
> >>>
> >>> The _first_ one is my use case
> >>>
> >>>> if (panel) {
> >>>
> >>> This handles the second case, where you attach a dsi panel.
> >>>
> >>>> dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
> >>>>
> >>>> so the next_bridge is a panel_bridge, in its attach function
> >>>> panel_bridge_attach(),
> >>>> according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
> >>>> it would create connector and attach connector to panel.
> >>>>
> >>>> I'm not sure this flag would exist or not, but for both case, it's strange.
> >>>> If exist, you create connector in this patch but no where to attach
> >>>> connector to panel.
> >>>
> >>> Yes, in fact, this is transitional patch needed, as once I converted mtk_dpi,
> >>> mtk_dsi and mtk_hdmi to the new drm_bridge API the drm_bridge_connector_init()
> >>> will be done in mtk_drm_drv. We will need to call drm_bridge_connector_init for
> >>> dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi drivers. The
> >>> graphic controller driver should create connectors and CRTCs, as example you can
> >>> take a look at drivers/gpu/drm/omapdrm/omap_drv.c
> >>
> >> I have such question because I've reviewed omap's driver. In omap's
> >> driver, after it call drm_bridge_connector_init(), it does this:
> >>
> >> if (pipe->output->panel) {
> >> ret = drm_panel_attach(pipe->output->panel,
> >> pipe->connector);
> >> if (ret < 0)
> >> return ret;
> >> }
> >>
> >> In this patch, you does not do this.
> >>
> >
> > I see, so yes, I am probably missing call drm_panel_attach in case there is a
> > direct panel attached. Thanks for pointing it.
> >
> > I'll send a new version adding the drm_panel_attach call.
> >
>
> Wait, shouldn't panel be attached on the call of mtk_dsi_bridge_attach as
> next_bridge points to a bridge or a panel?
>
> static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags)
> {
> struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> /* Attach the panel or bridge to the dsi bridge */
> return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
> &dsi->bridge, flags);
> }
>
> Or I am continuing misunderstanding all this?
Panels should always be wrapped in a drm_bridge, so I think you're doing
right. I believe the call to drm_panel_attach() in omapdrm is a leftover
that can be removed. I'll have a look at it.
> >>>> If not exist, the next_brige would create one connector and this brige
> >>>> would create another connector.
> >>>>
> >>>> I think in your case, mtk_dsi does not directly connect to a panel, so
> >>>
> >>> Exactly
> >>>
> >>>> I need a exact explain. Or someone could test this on a
> >>>> directly-connect-panel platform.
> >>>
> >>> I don't think I am breaking this use case but AFAICS there is no users in
> >>> mainline that directly connect a panel using the mediatek driver. As I said my
> >>> use case is the other so I can't really test. Do you know anyone that can test this?
> >>
> >> I'm not sure who can test this, but [1], which is sent by YT Shen in a
> >> series, is a patch to support dsi command mode so dsi could directly
> >> connect to panel.
> >>
> >> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/mediatek?h=v5.7-rc5&id=21898816831fc60c92dd634ab4316a24da7eb4af
> >>
> >> It's better that someone could test this case, but if no one would
> >> test this, I could also accept a good-look patch.
> >>
> >>>>>> Changes in v4: None
> >>>>>> Changes in v3:
> >>>>>> - Move the bridge.type line to the patch that adds drm_bridge support. (Laurent Pinchart)
> >>>>>>
> >>>>>> Changes in v2: None
> >>>>>>
> >>>>>> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 ++++++++++++-
> >>>>>> 1 file changed, 12 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> >>>>>> index 4f3bd095c1ee..471fcafdf348 100644
> >>>>>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> >>>>>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> >>>>>> @@ -17,6 +17,7 @@
> >>>>>>
> >>>>>> #include <drm/drm_atomic_helper.h>
> >>>>>> #include <drm/drm_bridge.h>
> >>>>>> +#include <drm/drm_bridge_connector.h>
> >>>>>> #include <drm/drm_mipi_dsi.h>
> >>>>>> #include <drm/drm_of.h>
> >>>>>> #include <drm/drm_panel.h>
> >>>>>> @@ -183,6 +184,7 @@ struct mtk_dsi {
> >>>>>> struct drm_encoder encoder;
> >>>>>> struct drm_bridge bridge;
> >>>>>> struct drm_bridge *next_bridge;
> >>>>>> + struct drm_connector *connector;
> >>>>>> struct phy *phy;
> >>>>>>
> >>>>>> void __iomem *regs;
> >>>>>> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
> >>>>>> */
> >>>>>> dsi->encoder.possible_crtcs = 1;
> >>>>>>
> >>>>>> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
> >>>>>> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
> >>>>>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >>>>>> if (ret)
> >>>>>> goto err_cleanup_encoder;
> >>>>>>
> >>>>>> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
> >>>>>> + if (IS_ERR(dsi->connector)) {
> >>>>>> + DRM_ERROR("Unable to create bridge connector\n");
> >>>>>> + ret = PTR_ERR(dsi->connector);
> >>>>>> + goto err_cleanup_encoder;
> >>>>>> + }
> >>>>>> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
> >>>>>> +
> >>>>>> return 0;
> >>>>>>
> >>>>>> err_cleanup_encoder:
--
Regards,
Laurent Pinchart
_______________________________________________
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/16] mfd: mfd-core: Don't overwrite the dma_mask of the child device
From: Michael Walle @ 2020-05-14 20:45 UTC (permalink / raw)
To: Mark Brown
Cc: linux-pwm, Linus Walleij, Thierry Reding, Lee Jones, Jason Cooper,
Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, devicetree, Jean Delvare,
linux-watchdog, linux-gpio, Rob Herring, Thomas Gleixner,
Wim Van Sebroeck, linux-arm-kernel, linux-hwmon, Shawn Guo,
linux-kernel, Li Yang, Greg Kroah-Hartman, Robin Murphy
In-Reply-To: <20200428152543.GI5677@sirena.org.uk>
Am 2020-04-28 17:25, schrieb Mark Brown:
> On Tue, Apr 28, 2020 at 03:49:49PM +0100, Robin Murphy wrote:
>
>> For better or worse, the platform bus is the dumping ground for random
>> crap,
>> so we just have to deal with all the abstraction breakage that leaks
>> out of
>> that.
>
> The reason we're using the platform bus for this is that historically
> people were creating buses which were essentially carbon copies of the
> platform bus with the name changed and it was felt that rather than
> duplicate code it was better to just use platform devices with no MMIO
> ranges defined. If there's some assumptions about DMA for platform
> devices floating about somewhere it might be reasonable to revisit this
> and create a non-DMA variant of platform devices since there is a
> meaningful difference.
Was there any conclusion? Should I keep or drop this patch in the next
version
of this series?
--
-michael
_______________________________________________
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/2] hwrng: exynos - Set the quality value
From: Stephan Mueller @ 2020-05-14 20:20 UTC (permalink / raw)
To: Łukasz Stelmach
Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger,
Greg Kroah-Hartman, Matt Mackall, linux-kernel,
Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz,
Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui,
bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel,
linux-crypto
In-Reply-To: <20200514190734.32746-3-l.stelmach@samsung.com>
Am Donnerstag, 14. Mai 2020, 21:07:34 CEST schrieb Łukasz Stelmach:
Hi Łukasz,
> The value has been estimaded by obtainig 1024 chunks of data 128 bytes
> (1024 bits) each from the generator and finding chunk with minimal
> entropy using the ent(1) tool. The value was 6.332937 bits of entropy
> in each 8 bits of data.
Dto - see the other comment.
Ciao
Stephan
_______________________________________________
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/2] hwrng: iproc-rng200 - Set the quality value
From: Stephan Mueller @ 2020-05-14 20:20 UTC (permalink / raw)
To: Łukasz Stelmach
Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger,
Greg Kroah-Hartman, Matt Mackall, linux-kernel,
Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz,
Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui,
bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel,
linux-crypto
In-Reply-To: <20200514190734.32746-2-l.stelmach@samsung.com>
Am Donnerstag, 14. Mai 2020, 21:07:33 CEST schrieb Łukasz Stelmach:
Hi Łukasz,
> The value has been estimaded by obtainig 1024 chunks of data 128 bytes
> (1024 bits) each from the generator and finding chunk with minimal
> entropy using the ent(1) tool. The value was 6.327820 bits of entropy
> in each 8 bits of data.
I am not sure we should use the ent tool to define the entropy level. Ent
seems to use a very coarse entropy estimation.
I would feel more comfortable when using other measures like SP800-90B which
even provides a tool for the analysis.
I understand that entropy estimates, well, are estimates. But the ent data is
commonly not very conservative.
[1] https://github.com/usnistgov/SP800-90B_EntropyAssessment
Ciao
Stephan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 33/38] staging: tegra-vde: fix common struct sg_table related issues
From: Dmitry Osipenko @ 2020-05-14 20:07 UTC (permalink / raw)
To: Marek Szyprowski, dri-devel, iommu, linaro-mm-sig, linux-kernel
Cc: devel, Bartlomiej Zolnierkiewicz, David Airlie,
Greg Kroah-Hartman, Jonathan Hunter, Thierry Reding,
Daniel Vetter, linux-tegra, Mauro Carvalho Chehab, Robin Murphy,
Christoph Hellwig, linux-arm-kernel, linux-media
In-Reply-To: <20200513133245.6408-33-m.szyprowski@samsung.com>
13.05.2020 16:32, Marek Szyprowski пишет:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called with the original number of the entries
> passed to the dma_map_sg().
>
> struct sg_table is a common structure used for describing a non-contiguous
> memory buffer, used commonly in the DRM and graphics subsystems. It
> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
> and DMA mapped pages (nents entry).
>
> It turned out that it was a common mistake to misuse nents and orig_nents
> entries, calling DMA-mapping functions with a wrong number of entries or
> ignoring the number of mapped entries returned by the dma_map_sg()
> function.
>
> To avoid such issues, lets use a common dma-mapping wrappers operating
> directly on the struct sg_table objects and use scatterlist page
> iterators where possible. This, almost always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
> vs. orig_nents misuse' thread:
> https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprowski@samsung.com/T/
> ---
> drivers/staging/media/tegra-vde/iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/tegra-vde/iommu.c b/drivers/staging/media/tegra-vde/iommu.c
> index 6af863d..adf8dc7 100644
> --- a/drivers/staging/media/tegra-vde/iommu.c
> +++ b/drivers/staging/media/tegra-vde/iommu.c
> @@ -36,8 +36,8 @@ int tegra_vde_iommu_map(struct tegra_vde *vde,
>
> addr = iova_dma_addr(&vde->iova, iova);
>
> - size = iommu_map_sg(vde->domain, addr, sgt->sgl, sgt->nents,
> - IOMMU_READ | IOMMU_WRITE);
> + size = iommu_map_sgtable(vde->domain, addr, sgt,
> + IOMMU_READ | IOMMU_WRITE);
> if (!size) {
> __free_iova(&vde->iova, iova);
> return -ENXIO;
>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv2 1/2] coresight: etm4x: Add support to skip trace unit power up
From: Sai Prakash Ranjan @ 2020-05-14 19:57 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: Sai Prakash Ranjan, linux-arm-msm, coresight, linux-kernel,
Stephen Boyd, Tingwei Zhang, Leo Yan, linux-arm-kernel
In-Reply-To: <cover.1589485594.git.saiprakash.ranjan@codeaurora.org>
From: Tingwei Zhang <tingwei@codeaurora.org>
On some Qualcomm Technologies Inc. SoCs like SC7180, there
exists a hardware errata where the APSS (Application Processor
SubSystem)/CPU watchdog counter is stopped when the trace unit
power up ETM register is set (TRCPDCR.PU = 1). Since the ETMs
share the same power domain as that of respective CPU cores,
they are powered on when the CPU core is powered on. So we can
skip powering up of trace unit after checking for this errata
via new property called "qcom,skip-power-up".
Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
drivers/hwtracing/coresight/coresight-etm4x.c | 27 ++++++++++++-------
drivers/hwtracing/coresight/coresight-etm4x.h | 3 +++
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index fb0f5f4f3a91..b38214326fa4 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -196,12 +196,14 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata)
writel_relaxed(config->vmid_mask0, drvdata->base + TRCVMIDCCTLR0);
writel_relaxed(config->vmid_mask1, drvdata->base + TRCVMIDCCTLR1);
- /*
- * Request to keep the trace unit powered and also
- * emulation of powerdown
- */
- writel_relaxed(readl_relaxed(drvdata->base + TRCPDCR) | TRCPDCR_PU,
- drvdata->base + TRCPDCR);
+ if (!drvdata->skip_power_up) {
+ /*
+ * Request to keep the trace unit powered and also
+ * emulation of powerdown
+ */
+ writel_relaxed(readl_relaxed(drvdata->base + TRCPDCR) | TRCPDCR_PU,
+ drvdata->base + TRCPDCR);
+ }
/* Enable the trace unit */
writel_relaxed(1, drvdata->base + TRCPRGCTLR);
@@ -476,10 +478,12 @@ static void etm4_disable_hw(void *info)
CS_UNLOCK(drvdata->base);
- /* power can be removed from the trace unit now */
- control = readl_relaxed(drvdata->base + TRCPDCR);
- control &= ~TRCPDCR_PU;
- writel_relaxed(control, drvdata->base + TRCPDCR);
+ if (!drvdata->skip_power_up) {
+ /* power can be removed from the trace unit now */
+ control = readl_relaxed(drvdata->base + TRCPDCR);
+ control &= ~TRCPDCR_PU;
+ writel_relaxed(control, drvdata->base + TRCPDCR);
+ }
control = readl_relaxed(drvdata->base + TRCPRGCTLR);
@@ -1429,6 +1433,9 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
return -ENOMEM;
}
+ if (fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up"))
+ drvdata->skip_power_up = true;
+
/* Validity for the resource is already checked by the AMBA core */
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base))
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index 4a695bf90582..72c9a55e67df 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -407,6 +407,8 @@ struct etmv4_save_state {
* @config: structure holding configuration parameters.
* @save_state: State to be preserved across power loss
* @state_needs_restore: True when there is context to restore after PM exit
+ * @skip_power_up: Indicates if an implementation can skip powering up
+ * the trace unit.
*/
struct etmv4_drvdata {
void __iomem *base;
@@ -454,6 +456,7 @@ struct etmv4_drvdata {
struct etmv4_config config;
struct etmv4_save_state *save_state;
bool state_needs_restore;
+ bool skip_power_up;
};
/* Address comparator access types */
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 2/2] dt-bindings: arm: coresight: Add support to skip trace unit power up
From: Sai Prakash Ranjan @ 2020-05-14 19:57 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: Sai Prakash Ranjan, linux-arm-msm, coresight, linux-kernel,
Stephen Boyd, Tingwei Zhang, Leo Yan, linux-arm-kernel
In-Reply-To: <cover.1589485594.git.saiprakash.ranjan@codeaurora.org>
From: Tingwei Zhang <tingwei@codeaurora.org>
Add "qcom,skip-power-up" property to identify systems which can
skip powering up of trace unit since they share the same power
domain as their CPU core. This is required to identify such
systems with hardware errata which stops the CPU watchdog counter
when the power up bit is set (TRCPDCR.PU).
Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
Documentation/devicetree/bindings/arm/coresight.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
index 846f6daae71b..e4b2eda0b53b 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -108,6 +108,13 @@ its hardware characteristcs.
* arm,cp14: must be present if the system accesses ETM/PTM management
registers via co-processor 14.
+ * qcom,skip-power-up: boolean. Indicates that an implementation can
+ skip powering up the trace unit. TRCPDCR.PU does not have to be set
+ on Qualcomm Technologies Inc. systems since ETMs are in the same power
+ domain as their CPU cores. This property is required to identify such
+ systems with hardware errata where the CPU watchdog counter is stopped
+ when TRCPDCR.PU is set.
+
* Optional property for TMC:
* arm,buffer-size: size of contiguous buffer space for TMC ETR
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 0/2] coresight: etm4x: Add support to skip trace unit power up
From: Sai Prakash Ranjan @ 2020-05-14 19:57 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, Mike Leach, devicetree,
Rob Herring
Cc: Sai Prakash Ranjan, linux-arm-msm, coresight, linux-kernel,
Stephen Boyd, Tingwei Zhang, Leo Yan, linux-arm-kernel
This series adds support to skip powering up of trace unit on systems
with an errata which stops CPU watchdog counter when power up bit is
set (TRCPDCR.PU = 1). Setting this bit is not required on Qualcomm
Technologies Inc. chipsets where this errata exists since the ETMs
are in the same power domain as their respective CPU cores.
Tingwei Zhang (2):
coresight: etm4x: Add support to skip trace unit power up
dt-bindings: arm: coresight: Add support to skip trace unit power up
.../devicetree/bindings/arm/coresight.txt | 7 +++++
drivers/hwtracing/coresight/coresight-etm4x.c | 27 ++++++++++++-------
drivers/hwtracing/coresight/coresight-etm4x.h | 3 +++
3 files changed, 27 insertions(+), 10 deletions(-)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
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 08/10] ARM: mmp: Remove legacy clk code
From: Stephen Boyd @ 2020-05-14 19:57 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Arnd Bergmann, Russell King, linux-kernel, Lubomir Rintel,
linux-clk, linux-arm-kernel
In-Reply-To: <20200409064416.83340-9-sboyd@kernel.org>
Quoting Stephen Boyd (2020-04-08 23:44:14)
> Remove all the legacy clk code that supports a non-common clk framework
> implementation of 'struct clk' in mach-mmp. This code doesn't look to be
> compiled anymore given that the MMP is fully supported in the
> multi-platform config via ARCH_MULTIPLATFORM as of commit 377524dc4d77
> ("ARM: mmp: move into ARCH_MULTIPLATFORM"). The ARCH_MULTIPLATFORM
> config selects COMMON_CLK and therefore the Makefile rule can never
> actually compile the code in these files.
>
> Cc: Lubomir Rintel <lkundrak@v3.sk>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: <linux-arm-kernel@lists.infradead.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
Applied to clk-next + a fix for problem reported in -next
_______________________________________________
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 07/10] clk: Allow the common clk framework to be selectable
From: Stephen Boyd @ 2020-05-14 19:57 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Rich Felker, Yoshinori Sato, Arnd Bergmann, linux-sh, linux-mips,
linux-kernel, Jiaxun Yang, Aurelien Jacquiot, linux-m68k,
Mark Brown, Geert Uytterhoeven, Mark Salter, Russell King,
Thomas Bogendoerfer, Guan Xuetao, linux-clk, linux-arm-kernel,
linux-c6x-dev
In-Reply-To: <20200409064416.83340-8-sboyd@kernel.org>
Quoting Stephen Boyd (2020-04-08 23:44:13)
> Enable build testing and configuration control of the common clk
> framework so that more code coverage and testing can be done on the
> common clk framework across various architectures. This also nicely
> removes the requirement that architectures must select the framework
> when they don't use it in architecture code.
>
> There's one snag with doing this, and that's making sure that randconfig
> builds don't select this option when some architecture or platform
> implements 'struct clk' outside of the common clk framework. Introduce a
> new config option 'HAVE_LEGACY_CLK' to indicate those platforms that
> haven't migrated to the common clk framework and therefore shouldn't be
> allowed to select this new config option. Also add a note that we hope
> one day to remove this config entirely.
>
> Based on a patch by Mark Brown <broonie@kernel.org>.
>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Aurelien Jacquiot <jacquiot.aurelien@gmail.com>
> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
> Cc: Guan Xuetao <gxt@pku.edu.cn>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: <linux-mips@vger.kernel.org>
> Cc: <linux-c6x-dev@linux-c6x.org>
> Cc: <linux-m68k@lists.linux-m68k.org>
> Cc: <linux-arm-kernel@lists.infradead.org>
> Cc: <linux-sh@vger.kernel.org>
> Link: https://lore.kernel.org/r/1470915049-15249-1-git-send-email-broonie@kernel.org
> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
> ---
Applied to clk-next
_______________________________________________
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