* [PATCH 1/5 v9] ARM: Disable KASan instrumentation for some code
From: Linus Walleij @ 2020-05-15 11:40 UTC (permalink / raw)
To: Florian Fainelli, Abbott Liu, Russell King, Ard Biesheuvel,
Andrey Ryabinin
Cc: Arnd Bergmann, Marc Zyngier, Linus Walleij, kasan-dev,
Alexander Potapenko, linux-arm-kernel, Dmitry Vyukov
In-Reply-To: <20200515114028.135674-1-linus.walleij@linaro.org>
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
Disable instrumentation for arch/arm/boot/compressed/*
since that code is executed before the kernel has even
set up its mappings and definately out of scope for
KASan.
Disable instrumentation of arch/arm/vdso/* because that code
is not linked with the kernel image, so the KASan management
code would fail to link.
Disable instrumentation of arch/arm/mm/physaddr.c. See commit
ec6d06efb0ba ("arm64: Add support for CONFIG_DEBUG_VIRTUAL")
for more details.
Disable kasan check in the function unwind_pop_register because
it does not matter that kasan checks failed when unwind_pop_register()
reads the stack memory of a task.
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v8->v9:
- Collect Ard's tags.
ChangeLog v7->v8:
- Do not sanitize arch/arm/mm/mmu.c.
Apart from being intuitively correct, it turns out that KASan
will insert a __asan_load4() into the set_pte_at() function
in mmu.c and this is something that KASan calls in the early
initialization, to set up the shadow memory. Naturally,
__asan_load4() cannot be called before the shadow memory is
set up so we need to exclude mmu.c from sanitization.
ChangeLog v6->v7:
- Removed the KVM instrumentaton disablement since KVM
on ARM32 is gone.
---
arch/arm/boot/compressed/Makefile | 1 +
arch/arm/kernel/unwind.c | 6 +++++-
arch/arm/mm/Makefile | 2 ++
arch/arm/vdso/Makefile | 2 ++
4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 9c11e7490292..abd6f3d5c2ba 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -24,6 +24,7 @@ OBJS += hyp-stub.o
endif
GCOV_PROFILE := n
+KASAN_SANITIZE := n
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
KCOV_INSTRUMENT := n
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 11a964fd66f4..739a77f39a8f 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -236,7 +236,11 @@ static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
if (*vsp >= (unsigned long *)ctrl->sp_high)
return -URC_FAILURE;
- ctrl->vrs[reg] = *(*vsp)++;
+ /* Use READ_ONCE_NOCHECK here to avoid this memory access
+ * from being tracked by KASAN.
+ */
+ ctrl->vrs[reg] = READ_ONCE_NOCHECK(*(*vsp));
+ (*vsp)++;
return URC_OK;
}
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 7cb1699fbfc4..99699c32d8a5 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -7,6 +7,7 @@ obj-y := extable.o fault.o init.o iomap.o
obj-y += dma-mapping$(MMUEXT).o
obj-$(CONFIG_MMU) += fault-armv.o flush.o idmap.o ioremap.o \
mmap.o pgd.o mmu.o pageattr.o
+KASAN_SANITIZE_mmu.o := n
ifneq ($(CONFIG_MMU),y)
obj-y += nommu.o
@@ -16,6 +17,7 @@ endif
obj-$(CONFIG_ARM_PTDUMP_CORE) += dump.o
obj-$(CONFIG_ARM_PTDUMP_DEBUGFS) += ptdump_debugfs.o
obj-$(CONFIG_MODULES) += proc-syms.o
+KASAN_SANITIZE_physaddr.o := n
obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o
diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile
index d3c9f03e7e79..71d18d59bd35 100644
--- a/arch/arm/vdso/Makefile
+++ b/arch/arm/vdso/Makefile
@@ -42,6 +42,8 @@ GCOV_PROFILE := n
# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
KCOV_INSTRUMENT := n
+KASAN_SANITIZE := n
+
# Force dependency
$(obj)/vdso.o : $(obj)/vdso.so
--
2.25.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: [PATCH v8 2/3] drivers: input: keyboard: Add mtk keypad driver
From: Andy Shevchenko @ 2020-05-15 11:40 UTC (permalink / raw)
To: Marco Felsch
Cc: Dmitry Torokhov, linux-kernel, linux-mediatek, Yingjoe Chen,
Fengping Yu, linux-arm-kernel
In-Reply-To: <20200515093016.rw5bmvoumgzvkqrc@pengutronix.de>
On Fri, May 15, 2020 at 11:30:16AM +0200, Marco Felsch wrote:
> On 20-05-15 14:20, Fengping Yu wrote:
...
> > + depends on OF && HAVE_CLK
>
> Please drop those deps and instead use:
+1
> depends on ARCH_MEDIATEK && ARM64
I would go even further
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
> There are still some missing deps:
>
> select CONFIG_REGMAP_MMIO
> select INPUT_MATRIXKMAP
...
> > +#define MTK_KPD_DEBOUNCE_MAX_US 256000 /*256ms */
>
> Thanks for aligning the defines but the 256ms comment is still useless
> as Andy already said.
Yes, it seems my comments partially (?) have been ignored.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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/7] firmware: smccc: Drop smccc_version enum and use ARM_SMCCC_VERSION_1_x instead
From: Mark Rutland @ 2020-05-15 11:39 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas, linux-kernel,
Steven Price, harb, Will Deacon, linux-arm-kernel
In-Reply-To: <20200506164411.3284-5-sudeep.holla@arm.com>
On Wed, May 06, 2020 at 05:44:08PM +0100, Sudeep Holla wrote:
> Instead of maintaining 2 sets of enums/macros for tracking SMCCC version,
> let us drop smccc_version enum and use ARM_SMCCC_VERSION_1_x directly
> instead.
>
> This is in preparation to drop smccc_version here and move it separately
> under drivers/firmware/smccc.
>
> Reviewed-by: Steven Price <steven.price@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/kernel/paravirt.c | 2 +-
> drivers/firmware/psci/psci.c | 8 ++++----
> include/linux/psci.h | 7 +------
> 3 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
> index 1ef702b0be2d..295d66490584 100644
> --- a/arch/arm64/kernel/paravirt.c
> +++ b/arch/arm64/kernel/paravirt.c
> @@ -120,7 +120,7 @@ static bool has_pv_steal_clock(void)
> struct arm_smccc_res res;
>
> /* To detect the presence of PV time support we require SMCCC 1.1+ */
> - if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
> + if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE)
> return false;
>
> arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 2937d44b5df4..6a56d7196697 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -54,12 +54,12 @@ bool psci_tos_resident_on(int cpu)
>
> struct psci_operations psci_ops = {
> .conduit = SMCCC_CONDUIT_NONE,
> - .smccc_version = SMCCC_VERSION_1_0,
> + .smccc_version = ARM_SMCCC_VERSION_1_0,
> };
>
> enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
> {
> - if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
> + if (psci_ops.smccc_version < ARM_SMCCC_VERSION_1_1)
> return SMCCC_CONDUIT_NONE;
>
> return psci_ops.conduit;
> @@ -411,8 +411,8 @@ static void __init psci_init_smccc(void)
> if (feature != PSCI_RET_NOT_SUPPORTED) {
> u32 ret;
> ret = invoke_psci_fn(ARM_SMCCC_VERSION_FUNC_ID, 0, 0, 0);
> - if (ret == ARM_SMCCC_VERSION_1_1) {
> - psci_ops.smccc_version = SMCCC_VERSION_1_1;
> + if (ret >= ARM_SMCCC_VERSION_1_1) {
> + psci_ops.smccc_version = ret;
> ver = ret;
> }
> }
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index a67712b73b6c..29bd0671e5bb 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -21,11 +21,6 @@ bool psci_power_state_is_valid(u32 state);
> int psci_set_osi_mode(void);
> bool psci_has_osi_support(void);
>
> -enum smccc_version {
> - SMCCC_VERSION_1_0,
> - SMCCC_VERSION_1_1,
> -};
> -
> struct psci_operations {
> u32 (*get_version)(void);
> int (*cpu_suspend)(u32 state, unsigned long entry_point);
> @@ -36,7 +31,7 @@ struct psci_operations {
> unsigned long lowest_affinity_level);
> int (*migrate_info_type)(void);
> enum arm_smccc_conduit conduit;
> - enum smccc_version smccc_version;
> + u32 smccc_version;
> };
>
> extern struct psci_operations psci_ops;
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8] Add matrix keypad driver support for Mediatek SoCs
From: Andy Shevchenko @ 2020-05-15 11:38 UTC (permalink / raw)
To: Fengping Yu
Cc: Dmitry Torokhov, Marco Felsch, linux-kernel, linux-mediatek,
Yingjoe Chen, linux-arm-kernel
In-Reply-To: <20200515062007.28346-1-fengping.yu@mediatek.com>
On Fri, May 15, 2020 at 02:20:04PM +0800, Fengping Yu wrote:
>
> Change since v7:
> - specify compatible property as const string
> - add maxItem in required property
> - squash keypad example nodes
> - sort header file with alphabetic order
> - align all define values and add MTK_ prefix to make more uniform
> - change debounce value to default 16ms if not specified in dts
> - remove extra braces
> - separate clk prepare as an internal driver function
> - add special compatible string
> - modify CONFIG_KEYBOARD_MTK_KPD=m to build keypad as ko module
You forgot to address at least some of my comments...
>
> fengping.yu (3):
> dt-bindings: Add keypad devicetree documentation
> drivers: input: keyboard: Add mtk keypad driver
> configs: defconfig: Add CONFIG_ng.yu (3):
> dt-bindings: Add keypad devicetree documentation
> drivers: input: keyboard: Add mtk keypad driver
> configs: defconfig: Add CONFIG_KEYBOARD_MTK_KPD=m
>
> .../devicetree/bindings/input/mtk-kpd.yaml | 94 +++++++
> arch/arm64/configs/defconfig | 1 +
> drivers/input/keyboard/Kconfig | 9 +
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/mtk-kpd.c | 231 ++++++++++++++++++
> 5 files changed, 336 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/mtk-kpd.yaml
> create mode 100644 drivers/input/keyboard/mtk-kpd.c
>
> --
> 2.18.0
>
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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 3/7] firmware: smccc: Add the definition for SMCCCv1.2 version/error codes
From: Mark Rutland @ 2020-05-15 11:38 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas, linux-kernel,
Steven Price, harb, Will Deacon, linux-arm-kernel
In-Reply-To: <20200506164411.3284-4-sudeep.holla@arm.com>
On Wed, May 06, 2020 at 05:44:07PM +0100, Sudeep Holla wrote:
> Add the definition for SMCCC v1.2 version and new error code added.
> While at it, also add a note that ARM DEN 0070A is deprecated and is
> now merged into the main SMCCC specification(ARM DEN 0028C).
>
> Reviewed-by: Steven Price <steven.price@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Hmm... the SMCCC v1.2 doc still seems to be EAC rather than a final
release.
I don't expect that this would change, but I am a little hesitant to add
other stuff based on an unfinalized spec. Do we know when the final
release will be?
Thanks,
Mark.
> ---
> include/linux/arm-smccc.h | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 6c1d1eda3be4..9d9a2e42e919 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -56,6 +56,7 @@
>
> #define ARM_SMCCC_VERSION_1_0 0x10000
> #define ARM_SMCCC_VERSION_1_1 0x10001
> +#define ARM_SMCCC_VERSION_1_2 0x10002
>
> #define ARM_SMCCC_VERSION_FUNC_ID \
> ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> @@ -314,10 +315,14 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
> */
> #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
>
> -/* Return codes defined in ARM DEN 0070A */
> +/*
> + * Return codes defined in ARM DEN 0070A
> + * ARM DEN 0070A is now merged/consolidated into ARM DEN 0028C
> + */
> #define SMCCC_RET_SUCCESS 0
> #define SMCCC_RET_NOT_SUPPORTED -1
> #define SMCCC_RET_NOT_REQUIRED -2
> +#define SMCCC_RET_INVALID_PARAMETER -3
>
> /*
> * Like arm_smccc_1_1* but always returns SMCCC_RET_NOT_SUPPORTED.
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/7] firmware: smccc: Update link to latest SMCCC specification
From: Mark Rutland @ 2020-05-15 11:37 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas, linux-kernel,
Steven Price, harb, Will Deacon, linux-arm-kernel
In-Reply-To: <20200506164411.3284-3-sudeep.holla@arm.com>
On Wed, May 06, 2020 at 05:44:06PM +0100, Sudeep Holla wrote:
> The current link gets redirected to the revision B published in November
> 2016 though it actually points to the original revision A published in
> June 2013.
>
> Let us update the link to point to the latest version, so that it
> doesn't get stale anytime soon. Currently it points to v1.2 published in
> March 2020.
>
> Reviewed-by: Steven Price <steven.price@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Changing the link is fine, but could we also add a line to make it clear
which version of spec was written against, e.g.
| This code is up-to-date with version DEN 0028 A
... as that was previously implicit in the documentation link, and it
makes clear what the code is aware of and what it is trying to handle.
Iknow we'll have to update it periodically, but I think that's
worthwthile.
With that:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> include/linux/arm-smccc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 59494df0f55b..6c1d1eda3be4 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -10,7 +10,7 @@
> /*
> * This file provides common defines for ARM SMC Calling Convention as
> * specified in
> - * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
> + * https://developer.arm.com/docs/den0028/latest
> */
>
> #define ARM_SMCCC_STD_CALL _AC(0,U)
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/7] firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and above
From: Mark Rutland @ 2020-05-15 11:37 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Arnd Bergmann, Catalin Marinas, linux-kernel,
Steven Price, harb, Will Deacon, linux-arm-kernel
In-Reply-To: <20200506164411.3284-2-sudeep.holla@arm.com>
On Wed, May 06, 2020 at 05:44:05PM +0100, Sudeep Holla wrote:
> SMCCC v1.0 lacked discoverability of version and features. To accelerate
> adoption of few mitigations and protect systems more rapidly from various
> vulnerability, PSCI v1.0 was updated to add SMCCC discovery mechanism
> though the PSCI firmware implementation of PSCI_FEATURES(SMCCC_VERSION)
> which returns success on firmware compliant to SMCCC v1.1 and above.
>
> This inturn makes SMCCC v1.1 and above dependent on ARM_PSCI_FW for
> backward compatibility. Let us introduce a new hidden config for the
> same to build more features on top of SMCCC v1.1 and above.
>
> While at it, also sort alphabetically the psci entry.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> drivers/firmware/Kconfig | 6 ++----
> drivers/firmware/smccc/Kconfig | 17 +++++++++++++++++
> 2 files changed, 19 insertions(+), 4 deletions(-)
> create mode 100644 drivers/firmware/smccc/Kconfig
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 8007d4aa76dc..4843e94713a4 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -295,15 +295,13 @@ config TURRIS_MOX_RWTM
> other manufacturing data and also utilize the Entropy Bit Generator
> for hardware random number generation.
>
> -config HAVE_ARM_SMCCC
> - bool
> -
> -source "drivers/firmware/psci/Kconfig"
> source "drivers/firmware/broadcom/Kconfig"
> source "drivers/firmware/google/Kconfig"
> source "drivers/firmware/efi/Kconfig"
> source "drivers/firmware/imx/Kconfig"
> source "drivers/firmware/meson/Kconfig"
> +source "drivers/firmware/psci/Kconfig"
> +source "drivers/firmware/smccc/Kconfig"
> source "drivers/firmware/tegra/Kconfig"
> source "drivers/firmware/xilinx/Kconfig"
>
> diff --git a/drivers/firmware/smccc/Kconfig b/drivers/firmware/smccc/Kconfig
> new file mode 100644
> index 000000000000..d93f1ab52cb2
> --- /dev/null
> +++ b/drivers/firmware/smccc/Kconfig
> @@ -0,0 +1,17 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config HAVE_ARM_SMCCC
> + bool
> + help
> + Include support for the Secure Monitor Call (SMC) and Hypervisor
> + Call (HVC) instructions on Armv7 and above architectures.
> +
> +config HAVE_ARM_SMCCC_DISCOVERY
> + bool
> + depends on ARM_PSCI_FW
> + default y
> + help
> + SMCCC v1.0 lacked discoverability and hence PSCI v1.0 was updated
> + to add SMCCC discovery mechanism though the PSCI firmware
> + implementation of PSCI_FEATURES(SMCCC_VERSION) which returns
> + success on firmware compliant to SMCCC v1.1 and above.
> +
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/4] Introduce the for_each_set_clump macro
From: Andy Shevchenko @ 2020-05-15 11:32 UTC (permalink / raw)
To: Syed Nayyar Waris
Cc: linux-arch, amit.kucheria, arnd, yamada.masahiro, linux-kernel,
linus.walleij, daniel.lezcano, vilhelm.gray, michal.simek,
bgolaszewski, rrichter, linux-gpio, linux-pm, akpm, rui.zhang,
linux-arm-kernel
In-Reply-To: <cover.1589497311.git.syednwaris@gmail.com>
On Fri, May 15, 2020 at 04:46:03AM +0530, Syed Nayyar Waris wrote:
> 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.
Thank you!
Overall looks good to me, though I gave tags per individual patches (I'm not
familiar with that GPIO drivers, so, I may not tag them).
>
> 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
>
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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] cpuidle: psci: Fixup execution order when entering a domain idle state
From: Ulf Hansson @ 2020-05-15 11:29 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Benjamin Gaignard, Linux PM, Stephen Boyd,
Daniel Lezcano, Rafael J . Wysocki, Lina Iyer, Bjorn Andersson,
Linux ARM
In-Reply-To: <20200515102255.GA25927@bogus>
On Fri, 15 May 2020 at 12:23, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Thu, May 14, 2020 at 09:11:50PM +0200, Ulf Hansson wrote:
> >
> > No worries, thanks for reviewing.
> >
>
> You are welcome.
>
> > That said, are you fine with Rafel queuing this then?
> >
>
> I am fine with that. However I told if you need fixes tags as there are
> no users of the notification yet in the kernel. Though this is trivial,
> but do we need this backported to stable kernel. I don't have strong
> opinion and leave it to you and Rafael.
I wanted to add the fixes tag, to make it obvious that there is an
error being fixed.
On the other hand, no need to tag this for stable, nor to need to send
it as fix for 5.7,
>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Thanks!
Kind regards
Uffe
_______________________________________________
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 23/23] arm64: mte: Add Memory Tagging Extension documentation
From: Catalin Marinas @ 2020-05-15 11:27 UTC (permalink / raw)
To: Szabolcs Nagy
Cc: linux-arch, Richard Earnshaw, nd, Will Deacon, Andrey Konovalov,
Kevin Brodsky, linux-mm, Vincenzo Frascino, Peter Collingbourne,
Dave Martin, linux-arm-kernel
In-Reply-To: <20200515111359.GC27289@arm.com>
On Fri, May 15, 2020 at 12:14:00PM +0100, Szabolcs Nagy wrote:
> The 05/15/2020 11:38, Catalin Marinas wrote:
> > On Thu, May 14, 2020 at 12:37:22PM +0100, Catalin Marinas wrote:
> > > We have two options with suboptions:
> > >
> > > 1. prctl() gets an exclude mask with 0xffff illegal even though the
> > > hardware accepts it:
> > > a) default exclude mask 0, allowing all tags to be generated by IRG
> > > b) default exclude mask of 0xfffe so that only tag 0 is generated
> > >
> > > 2. prctl() gets an include mask with 0 illegal:
> > > a) default include mask is 0xffff, allowing all tags to be generated
> > > b) default include mask 0f 0x0001 so that only tag 0 is generated
> > >
> > > We currently have (2) with mask 0 but could be changed to (2.b). If we
> > > are to follow the hardware description (which makes more sense to me but
> > > I don't write the C library), (1.a) is the most appropriate.
> >
> > Thinking some more about this, as we are to expose the GCR_EL1.Excl via
> > a ptrace interface as a regset, it makes more sense to move back to an
> > exclude mask here with default 0. That would be option 1.a above.
>
> i think the libc has to do a prctl call to set
> mte up and at that point it will use whatever
> arguments necessary, so 1.a should work (just
> like the other options).
>
> likely libc will disable 0 for irg and possibly
> one or two other fixed colors (which will have
> specific use).
>
> the difference i see between 1 vs 2 is forward
> compatibility if the architecture changes (e.g.
> adding more tag bits) but then likely new prctl
> flag will be needed for handling that so it's
> probably not an issue.
Thanks Szabolcs. While we are at this, no-one so far asked for the
GCR_EL1.RRND to be exposed to user (and this implies RGSR_EL1.SEED).
Since RRND=1 guarantees a distribution "no worse" than that of RRND=0, I
thought there isn't much point in exposing this configuration to the
user. The only advantage of RRND=0 I see is that the kernel can change
the seed randomly but, with only 4 bits per tag, it really doesn't
matter much.
Anyway, mentioning it here in case anyone is surprised later about the
lack of RRND configurability.
--
Catalin
_______________________________________________
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] clk / soc: mediatek: fix ptr_ret.cocci warnings
From: Matthias Brugger @ 2020-05-15 11:20 UTC (permalink / raw)
To: Enric Balletbo i Serra, kbuild test robot
Cc: kbuild-all, Stephen Boyd, linux-kernel, linux-mediatek, CK Hu,
linux-arm-kernel
In-Reply-To: <5ca9a334-31d7-8878-f586-13d5020c24fc@collabora.com>
On 10/05/2020 12:07, Enric Balletbo i Serra wrote:
>
>
> On 10/5/20 4:53, kbuild test robot wrote:
>> From: kbuild test robot <lkp@intel.com>
>>
>> drivers/soc/mediatek/mtk-mmsys.c:28:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>>
>>
>> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>>
>> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>>
>> Fixes: 13032709e232 ("clk / soc: mediatek: Move mt8173 MMSYS to platform driver")
>> CC: Matthias Brugger <mbrugger@suse.com>
>> Signed-off-by: kbuild test robot <lkp@intel.com>
>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>
Since we have
667c769246b0 ("soc / drm: mediatek: Fix mediatek-drm device probing")
I think this is not a valid patch anymore.
Regards,
Matthias
>> ---
>>
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> head: 30e2206e11ce27ae910cc0dab21472429e400a87
>> commit: 13032709e2328553970f0002df5edce6aac69425 [1266/7905] clk / soc: mediatek: Move mt8173 MMSYS to platform driver
>>
>> mtk-mmsys.c | 5 +----
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> --- a/drivers/soc/mediatek/mtk-mmsys.c
>> +++ b/drivers/soc/mediatek/mtk-mmsys.c
>> @@ -25,10 +25,7 @@ static int mtk_mmsys_probe(struct platfo
>>
>> clks = platform_device_register_data(&pdev->dev, data->clk_driver,
>> PLATFORM_DEVID_AUTO, NULL, 0);
>> - if (IS_ERR(clks))
>> - return PTR_ERR(clks);
>> -
>> - return 0;
>> + return PTR_ERR_OR_ZERO(clks);
>> }
>>
>> static const struct of_device_id of_match_mtk_mmsys[] = {
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 6/7] usb: gadget: udc: atmel: update endpoint allocation for sam9x60
From: cristian.birsan @ 2020-05-15 11:16 UTC (permalink / raw)
To: balbi, gregkh, nicolas.ferre, alexandre.belloni,
ludovic.desroches, robh+dt, mark.rutland, linux-arm-kernel,
linux-usb, devicetree, linux-kernel
Cc: Cristian Birsan
In-Reply-To: <20200515111631.31210-1-cristian.birsan@microchip.com>
From: Cristian Birsan <cristian.birsan@microchip.com>
The DPRAM memory from the USB High Speed Device Port (UDPHS) hardware
block was increased. This patch updates the endpoint allocation for sam9x60
to take advantage of this larger memory. At the same time the
constraint to allocate the endpoints in order was lifted. To handle old
and new hardware in the same driver the capabilities (caps) structure
was extended.
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 22 ++++++++++++++++++----
drivers/usb/gadget/udc/atmel_usba_udc.h | 1 +
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 2b1a0b6df0fe..ecd0fa9823bb 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1066,12 +1066,14 @@ static struct usb_ep *atmel_usba_match_ep(struct usb_gadget *gadget,
case USB_ENDPOINT_XFER_ISOC:
ep->fifo_size = 1024;
- ep->nr_banks = 2;
+ if (ep->udc->caps->ep_prealloc)
+ ep->nr_banks = 2;
break;
case USB_ENDPOINT_XFER_BULK:
ep->fifo_size = 512;
- ep->nr_banks = 1;
+ if (ep->udc->caps->ep_prealloc)
+ ep->nr_banks = 1;
break;
case USB_ENDPOINT_XFER_INT:
@@ -1081,7 +1083,8 @@ static struct usb_ep *atmel_usba_match_ep(struct usb_gadget *gadget,
else
ep->fifo_size =
roundup_pow_of_two(le16_to_cpu(desc->wMaxPacketSize));
- ep->nr_banks = 1;
+ if (ep->udc->caps->ep_prealloc)
+ ep->nr_banks = 1;
break;
}
@@ -2034,16 +2037,27 @@ static void at91sam9g45_pulse_bias(struct usba_udc *udc)
static const struct usba_udc_caps at91sam9rl_caps = {
.toggle_bias = at91sam9rl_toggle_bias,
+ .ep_prealloc = true,
};
static const struct usba_udc_caps at91sam9g45_caps = {
.pulse_bias = at91sam9g45_pulse_bias,
+ .ep_prealloc = true,
+};
+
+static const struct usba_udc_caps sama5d3_caps = {
+ .ep_prealloc = true,
+};
+
+static const struct usba_udc_caps at91sam9x60_caps = {
+ .ep_prealloc = false,
};
static const struct of_device_id atmel_udc_dt_ids[] = {
{ .compatible = "atmel,at91sam9rl-udc", .data = &at91sam9rl_caps },
{ .compatible = "atmel,at91sam9g45-udc", .data = &at91sam9g45_caps },
- { .compatible = "atmel,sama5d3-udc" },
+ { .compatible = "atmel,sama5d3-udc", .data = &sama5d3_caps },
+ { .compatible = "microchip,sam9x60-udc", .data = &at91sam9x60_caps },
{ /* sentinel */ }
};
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.h b/drivers/usb/gadget/udc/atmel_usba_udc.h
index 1a0f77bf8d4f..f9239e200e7a 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.h
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.h
@@ -305,6 +305,7 @@ struct usba_request {
struct usba_udc_caps {
void (*toggle_bias)(struct usba_udc *udc, int is_on);
void (*pulse_bias)(struct usba_udc *udc);
+ bool ep_prealloc;
};
struct usba_udc {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 7/7] ARM: dts: at91: sam9x60ek: enable usb device
From: cristian.birsan @ 2020-05-15 11:16 UTC (permalink / raw)
To: balbi, gregkh, nicolas.ferre, alexandre.belloni,
ludovic.desroches, robh+dt, mark.rutland, linux-arm-kernel,
linux-usb, devicetree, linux-kernel
Cc: Cristian Birsan
In-Reply-To: <20200515111631.31210-1-cristian.birsan@microchip.com>
From: Cristian Birsan <cristian.birsan@microchip.com>
Enable usb device for sam9x60ek board.
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
---
arch/arm/boot/dts/at91-sam9x60ek.dts | 13 +++++
arch/arm/boot/dts/sam9x60.dtsi | 74 ++++++++++++++++++++++++++++
2 files changed, 87 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sam9x60ek.dts b/arch/arm/boot/dts/at91-sam9x60ek.dts
index b484745bf2d4..325d0fc8674f 100644
--- a/arch/arm/boot/dts/at91-sam9x60ek.dts
+++ b/arch/arm/boot/dts/at91-sam9x60ek.dts
@@ -547,6 +547,12 @@
atmel,pins = <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
};
};
+
+ usb0 {
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins = <AT91_PIOB 16 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+ };
+ };
}; /* pinctrl */
&pmc {
@@ -634,6 +640,13 @@
};
};
+&usb0 {
+ atmel,vbus-gpio = <&pioB 16 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ status = "okay";
+};
+
&usb1 {
num-ports = <3>;
atmel,vbus-gpio = <0
diff --git a/arch/arm/boot/dts/sam9x60.dtsi b/arch/arm/boot/dts/sam9x60.dtsi
index 6763423d64b8..5cd2b9054762 100644
--- a/arch/arm/boot/dts/sam9x60.dtsi
+++ b/arch/arm/boot/dts/sam9x60.dtsi
@@ -69,6 +69,80 @@
#size-cells = <1>;
ranges;
+ usb0: gadget@500000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "microchip,sam9x60-udc";
+ reg = <0x00500000 0x100000
+ 0xf803c000 0x400>;
+ interrupts = <23 IRQ_TYPE_LEVEL_HIGH 2>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 23>, <&pmc PMC_TYPE_CORE PMC_UTMI>;
+ clock-names = "pclk", "hclk";
+ assigned-clocks = <&pmc PMC_TYPE_CORE PMC_UTMI>;
+ assigned-clock-rates = <480000000>;
+ status = "disabled";
+
+ ep@0 {
+ reg = <0>;
+ atmel,fifo-size = <64>;
+ atmel,nb-banks = <1>;
+ };
+
+ ep@1 {
+ reg = <1>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <2>;
+ atmel,can-dma;
+ };
+
+ ep@2 {
+ reg = <2>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <2>;
+ atmel,can-dma;
+ };
+
+ ep@3 {
+ reg = <3>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <3>;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep@4 {
+ reg = <4>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <3>;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep@5 {
+ reg = <5>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <3>;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep@6 {
+ reg = <6>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <3>;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+
+ ep@7 {
+ reg = <7>;
+ atmel,fifo-size = <1024>;
+ atmel,nb-banks = <3>;
+ atmel,can-dma;
+ atmel,can-isoc;
+ };
+ };
+
usb1: ohci@600000 {
compatible = "atmel,at91rm9200-ohci", "usb-ohci";
reg = <0x00600000 0x100000>;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/7] usb: gadget: udc: atmel: use 1 bank endpoints for control transfers
From: cristian.birsan @ 2020-05-15 11:16 UTC (permalink / raw)
To: balbi, gregkh, nicolas.ferre, alexandre.belloni,
ludovic.desroches, robh+dt, mark.rutland, linux-arm-kernel,
linux-usb, devicetree, linux-kernel
Cc: Cristian Birsan
In-Reply-To: <20200515111631.31210-1-cristian.birsan@microchip.com>
From: Cristian Birsan <cristian.birsan@microchip.com>
Use 1 bank endpoints for control transfers
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index beb7246935a8..a73b0e78a357 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1061,6 +1061,7 @@ static struct usb_ep *atmel_usba_match_ep(struct usb_gadget *gadget,
switch (usb_endpoint_type(desc)) {
case USB_ENDPOINT_XFER_CONTROL:
+ ep->nr_banks = 1;
break;
case USB_ENDPOINT_XFER_ISOC:
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/7] usb: gadget: udc: atmel: rename errata into caps
From: cristian.birsan @ 2020-05-15 11:16 UTC (permalink / raw)
To: balbi, gregkh, nicolas.ferre, alexandre.belloni,
ludovic.desroches, robh+dt, mark.rutland, linux-arm-kernel,
linux-usb, devicetree, linux-kernel
Cc: Cristian Birsan
In-Reply-To: <20200515111631.31210-1-cristian.birsan@microchip.com>
From: Cristian Birsan <cristian.birsan@microchip.com>
Rename errata structure into capabilities (caps). It will be used to add
capabilities for new SoCs. Get the pointer to PMC only for the SoCs that
need it to perform toggle_bias or pulse_bias.
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 20 ++++++++++----------
drivers/usb/gadget/udc/atmel_usba_udc.h | 4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index a73b0e78a357..2b1a0b6df0fe 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -389,8 +389,8 @@ static int vbus_is_present(struct usba_udc *udc)
static void toggle_bias(struct usba_udc *udc, int is_on)
{
- if (udc->errata && udc->errata->toggle_bias)
- udc->errata->toggle_bias(udc, is_on);
+ if (udc->caps && udc->caps->toggle_bias)
+ udc->caps->toggle_bias(udc, is_on);
}
static void generate_bias_pulse(struct usba_udc *udc)
@@ -398,8 +398,8 @@ static void generate_bias_pulse(struct usba_udc *udc)
if (!udc->bias_pulse_needed)
return;
- if (udc->errata && udc->errata->pulse_bias)
- udc->errata->pulse_bias(udc);
+ if (udc->caps && udc->caps->pulse_bias)
+ udc->caps->pulse_bias(udc);
udc->bias_pulse_needed = false;
}
@@ -2032,17 +2032,17 @@ static void at91sam9g45_pulse_bias(struct usba_udc *udc)
AT91_PMC_BIASEN);
}
-static const struct usba_udc_errata at91sam9rl_errata = {
+static const struct usba_udc_caps at91sam9rl_caps = {
.toggle_bias = at91sam9rl_toggle_bias,
};
-static const struct usba_udc_errata at91sam9g45_errata = {
+static const struct usba_udc_caps at91sam9g45_caps = {
.pulse_bias = at91sam9g45_pulse_bias,
};
static const struct of_device_id atmel_udc_dt_ids[] = {
- { .compatible = "atmel,at91sam9rl-udc", .data = &at91sam9rl_errata },
- { .compatible = "atmel,at91sam9g45-udc", .data = &at91sam9g45_errata },
+ { .compatible = "atmel,at91sam9rl-udc", .data = &at91sam9rl_caps },
+ { .compatible = "atmel,at91sam9g45-udc", .data = &at91sam9g45_caps },
{ .compatible = "atmel,sama5d3-udc" },
{ /* sentinel */ }
};
@@ -2070,8 +2070,8 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
if (!match)
return ERR_PTR(-EINVAL);
- udc->errata = match->data;
- if (udc->errata) {
+ udc->caps = match->data;
+ if (udc->caps && (udc->caps->pulse_bias || udc->caps->toggle_bias)) {
pp = of_find_matching_node_and_match(NULL, atmel_pmc_dt_ids,
NULL);
if (!pp)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.h b/drivers/usb/gadget/udc/atmel_usba_udc.h
index 8de79356d31d..1a0f77bf8d4f 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.h
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.h
@@ -302,7 +302,7 @@ struct usba_request {
unsigned int mapped:1;
};
-struct usba_udc_errata {
+struct usba_udc_caps {
void (*toggle_bias)(struct usba_udc *udc, int is_on);
void (*pulse_bias)(struct usba_udc *udc);
};
@@ -320,7 +320,7 @@ struct usba_udc {
struct usb_gadget gadget;
struct usb_gadget_driver *driver;
struct platform_device *pdev;
- const struct usba_udc_errata *errata;
+ const struct usba_udc_caps *caps;
int irq;
struct gpio_desc *vbus_pin;
int num_ep;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/7] dt-bindings: usb: atmel: Update DT bindings documentation for sam9x60
From: cristian.birsan @ 2020-05-15 11:16 UTC (permalink / raw)
To: balbi, gregkh, nicolas.ferre, alexandre.belloni,
ludovic.desroches, robh+dt, mark.rutland, linux-arm-kernel,
linux-usb, devicetree, linux-kernel
Cc: Cristian Birsan
In-Reply-To: <20200515111631.31210-1-cristian.birsan@microchip.com>
From: Cristian Birsan <cristian.birsan@microchip.com>
Add sam9x60 binding.
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
---
Documentation/devicetree/bindings/usb/atmel-usb.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 44e80153b148..bae2b928a014 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -82,6 +82,7 @@ Required properties:
"atmel,at91sam9rl-udc"
"atmel,at91sam9g45-udc"
"atmel,sama5d3-udc"
+ "microchip,sam9x60-udc"
- reg: Address and length of the register set for the device
- interrupts: Should contain usba interrupt
- clocks: Should reference the peripheral and host clocks
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/7] usb: gadget: udc: atmel: simplify endpoint allocation
From: cristian.birsan @ 2020-05-15 11:16 UTC (permalink / raw)
To: balbi, gregkh, nicolas.ferre, alexandre.belloni,
ludovic.desroches, robh+dt, mark.rutland, linux-arm-kernel,
linux-usb, devicetree, linux-kernel
Cc: Cristian Birsan
In-Reply-To: <20200515111631.31210-1-cristian.birsan@microchip.com>
From: Cristian Birsan <cristian.birsan@microchip.com>
Simplify the endpoint allocation and cleanup the code.
Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 21 ++++++++-------------
drivers/usb/gadget/udc/atmel_usba_udc.h | 1 -
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 2b154085dc6a..beb7246935a8 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1097,7 +1097,6 @@ static struct usb_ep *atmel_usba_match_ep(struct usb_gadget *gadget,
ep->ept_cfg |= USBA_BF(BK_NUMBER, ep->nr_banks);
- ep->udc->configured_ep++;
}
return _ep;
@@ -1790,7 +1789,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (status & USBA_END_OF_RESET) {
struct usba_ep *ep0, *ep;
- int i, n;
+ int i;
usba_writel(udc, INT_CLR,
USBA_END_OF_RESET|USBA_END_OF_RESUME
@@ -1838,13 +1837,14 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
"ODD: EP0 configuration is invalid!\n");
/* Preallocate other endpoints */
- n = fifo_mode ? udc->num_ep : udc->configured_ep;
- for (i = 1; i < n; i++) {
+ for (i = 1; i < udc->num_ep; i++) {
ep = &udc->usba_ep[i];
- usba_ep_writel(ep, CFG, ep->ept_cfg);
- if (!(usba_ep_readl(ep, CFG) & USBA_EPT_MAPPED))
- dev_err(&udc->pdev->dev,
- "ODD: EP%d configuration is invalid!\n", i);
+ if (ep->ep.claimed) {
+ usba_ep_writel(ep, CFG, ep->ept_cfg);
+ if (!(usba_ep_readl(ep, CFG) & USBA_EPT_MAPPED))
+ dev_err(&udc->pdev->dev,
+ "ODD: EP%d configuration is invalid!\n", i);
+ }
}
}
@@ -2011,10 +2011,6 @@ static int atmel_usba_stop(struct usb_gadget *gadget)
if (udc->vbus_pin)
disable_irq(gpiod_to_irq(udc->vbus_pin));
- if (fifo_mode == 0)
- udc->configured_ep = 1;
-
- udc->suspended = false;
usba_stop(udc);
udc->driver = NULL;
@@ -2095,7 +2091,6 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
pp = NULL;
while ((pp = of_get_next_child(np, pp)))
udc->num_ep++;
- udc->configured_ep = 1;
} else {
udc->num_ep = usba_config_fifo_table(udc);
}
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.h b/drivers/usb/gadget/udc/atmel_usba_udc.h
index a0225e4543d4..8de79356d31d 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.h
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.h
@@ -324,7 +324,6 @@ struct usba_udc {
int irq;
struct gpio_desc *vbus_pin;
int num_ep;
- int configured_ep;
struct usba_fifo_cfg *fifo_cfg;
struct clk *pclk;
struct clk *hclk;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/7] usb: gadget: udc: atmel: use of_find_matching_node_and_match
From: cristian.birsan @ 2020-05-15 11:16 UTC (permalink / raw)
To: balbi, gregkh, nicolas.ferre, alexandre.belloni,
ludovic.desroches, robh+dt, mark.rutland, linux-arm-kernel,
linux-usb, devicetree, linux-kernel
Cc: Claudiu Beznea
In-Reply-To: <20200515111631.31210-1-cristian.birsan@microchip.com>
From: Claudiu Beznea <claudiu.beznea@microchip.com>
Instead of trying to match every possible compatible use
of_find_matching_node_and_match() and pass the compatible array.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 22200341c8ec..2b154085dc6a 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -2052,6 +2052,13 @@ static const struct of_device_id atmel_udc_dt_ids[] = {
MODULE_DEVICE_TABLE(of, atmel_udc_dt_ids);
+static const struct of_device_id atmel_pmc_dt_ids[] = {
+ { .compatible = "atmel,at91sam9g45-pmc" },
+ { .compatible = "atmel,at91sam9rl-pmc" },
+ { .compatible = "atmel,at91sam9x5-pmc" },
+ { /* sentinel */ }
+};
+
static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
struct usba_udc *udc)
{
@@ -2067,13 +2074,17 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
return ERR_PTR(-EINVAL);
udc->errata = match->data;
- udc->pmc = syscon_regmap_lookup_by_compatible("atmel,at91sam9g45-pmc");
- if (IS_ERR(udc->pmc))
- udc->pmc = syscon_regmap_lookup_by_compatible("atmel,at91sam9rl-pmc");
- if (IS_ERR(udc->pmc))
- udc->pmc = syscon_regmap_lookup_by_compatible("atmel,at91sam9x5-pmc");
- if (udc->errata && IS_ERR(udc->pmc))
- return ERR_CAST(udc->pmc);
+ if (udc->errata) {
+ pp = of_find_matching_node_and_match(NULL, atmel_pmc_dt_ids,
+ NULL);
+ if (!pp)
+ return ERR_PTR(-ENODEV);
+
+ udc->pmc = syscon_node_to_regmap(pp);
+ of_node_put(pp);
+ if (IS_ERR(udc->pmc))
+ return ERR_CAST(udc->pmc);
+ }
udc->num_ep = 0;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/7] usb: gadget: udc: atmel: add usb device support for SAM9x60 SoC
From: cristian.birsan @ 2020-05-15 11:16 UTC (permalink / raw)
To: balbi, gregkh, nicolas.ferre, alexandre.belloni,
ludovic.desroches, robh+dt, mark.rutland, linux-arm-kernel,
linux-usb, devicetree, linux-kernel
Cc: Cristian Birsan
From: Cristian Birsan <cristian.birsan@microchip.com>
This patch set adds usb device support for SAM9x60 SoC.
The DPRAM memory for the USB High Speed Device Port (UDPHS) hardware
block was increased and the allocation method is changed. This patch
series simplifies the endpoint allocation scheme to acomodate this SoC
and the old ones.
Changes in v2:
- drop the patch that adds reference to pmc for sam9x60
- use dt-bindings: usb prefix
- enable usb device in device tree
Claudiu Beznea (1):
usb: gadget: udc: atmel: use of_find_matching_node_and_match
Cristian Birsan (6):
dt-bindings: usb: atmel: Update DT bindings documentation for sam9x60
usb: gadget: udc: atmel: simplify endpoint allocation
usb: gadget: udc: atmel: use 1 bank endpoints for control transfers
usb: gadget: udc: atmel: rename errata into caps
usb: gadget: udc: atmel: update endpoint allocation for sam9x60
ARM: dts: at91: sam9x60ek: enable usb device
.../devicetree/bindings/usb/atmel-usb.txt | 1 +
arch/arm/boot/dts/at91-sam9x60ek.dts | 13 +++
arch/arm/boot/dts/sam9x60.dtsi | 74 ++++++++++++++++
drivers/usb/gadget/udc/atmel_usba_udc.c | 87 ++++++++++++-------
drivers/usb/gadget/udc/atmel_usba_udc.h | 6 +-
5 files changed, 145 insertions(+), 36 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* PTRACE_SYSEMU behavior difference on arm64
From: Keno Fischer @ 2020-05-15 11:15 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Catalin Marinas, Will Deacon, Oleg Nesterov, linux-arm-kernel,
Sudeep Holla
The behavior of PTRACE_SYSEMU on arm64
appears to differ substantially from that of x86 and powerpc
(the other two architectures on which this feature is implemented).
In particular, after PTRACE_SYSEMU the syscall will always
be skipped on x86 and powerpc, but executed on arm64 unless
the syscall-entry stop was again continued using PTRACE_SYSEMU.
The skipping behavior is also documented in the manpage,
so I suspect this may just be a bug (the skipping behavior
makes sense to me and is what I would expect).
The reason this happens is that `syscall_trace_enter`
re-checks TIF_SYSCALL_EMU after the ptrace stop, but at that
point it may have already been superseded by a new ptrace
request. x86 and power save the original value of the flag,
rather than acting on the new value. I can submit a patch to
fix this, but wanted to check first whether this was intentional.
If it is, I can fix the man page instead.
Keno
_______________________________________________
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 23/23] arm64: mte: Add Memory Tagging Extension documentation
From: Szabolcs Nagy @ 2020-05-15 11:14 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, Richard Earnshaw, nd, Will Deacon, Andrey Konovalov,
Kevin Brodsky, linux-mm, Vincenzo Frascino, Peter Collingbourne,
Dave Martin, linux-arm-kernel
In-Reply-To: <20200515103839.GA22393@gaia>
The 05/15/2020 11:38, Catalin Marinas wrote:
> On Thu, May 14, 2020 at 12:37:22PM +0100, Catalin Marinas wrote:
> > On Wed, May 13, 2020 at 04:48:46PM +0100, Dave P Martin wrote:
> > > > > > On Wed, Apr 29, 2020 at 05:47:05PM +0100, Dave P Martin wrote:
> > > > > > > On Tue, Apr 21, 2020 at 03:26:03PM +0100, Catalin Marinas wrote:
> > > > > > > > +excludes all tags other than 0. A user thread can enable specific tags
> > > > > > > > +in the randomly generated set using the ``prctl(PR_SET_TAGGED_ADDR_CTRL,
> > > > > > > > +flags, 0, 0, 0)`` system call where ``flags`` contains the tags bitmap
> > > > > > > > +in the ``PR_MTE_TAG_MASK`` bit-field.
> > > > > > > > +
> > > > > > > > +**Note**: The hardware uses an exclude mask but the ``prctl()``
> > > > > > > > +interface provides an include mask. An include mask of ``0`` (exclusion
> > > > > > > > +mask ``0xffff``) results in the CPU always generating tag ``0``.
> > > > > > >
> > > > > > > Is there no way to make this default to 1 rather than having a magic
> > > > > > > meaning for 0?
> > [...]
> > > The only configuration that doesn't make sense is "no tags allowed", so
> > > I'd argue for explicity blocking that, even if the architeture aliases
> > > that encoding to something else.
> > >
> > > If we prefer 0 as a default value so that init inherits the correct
> > > value from the kernel without any special acrobatics, then we make it an
> > > exclude mask, with the semantics that the hardware is allowed to
> > > generate any of these tags, but does not have to be capable of
> > > generating all of them.
> >
> > That's more of a question to the libc people and their preference.
> > We have two options with suboptions:
> >
> > 1. prctl() gets an exclude mask with 0xffff illegal even though the
> > hardware accepts it:
> > a) default exclude mask 0, allowing all tags to be generated by IRG
> > b) default exclude mask of 0xfffe so that only tag 0 is generated
> >
> > 2. prctl() gets an include mask with 0 illegal:
> > a) default include mask is 0xffff, allowing all tags to be generated
> > b) default include mask 0f 0x0001 so that only tag 0 is generated
> >
> > We currently have (2) with mask 0 but could be changed to (2.b). If we
> > are to follow the hardware description (which makes more sense to me but
> > I don't write the C library), (1.a) is the most appropriate.
>
> Thinking some more about this, as we are to expose the GCR_EL1.Excl via
> a ptrace interface as a regset, it makes more sense to move back to an
> exclude mask here with default 0. That would be option 1.a above.
i think the libc has to do a prctl call to set
mte up and at that point it will use whatever
arguments necessary, so 1.a should work (just
like the other options).
likely libc will disable 0 for irg and possibly
one or two other fixed colors (which will have
specific use).
the difference i see between 1 vs 2 is forward
compatibility if the architecture changes (e.g.
adding more tag bits) but then likely new prctl
flag will be needed for handling that so it's
probably not an issue.
_______________________________________________
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 v1 1/9] dmaengine: Actions: get rid of bit fields from dma descriptor
From: Amit Tomer @ 2020-05-15 11:11 UTC (permalink / raw)
To: Vinod Koul
Cc: Andre Przywara, linux-actions, cristian.ciocaltea,
Manivannan Sadhasivam, dmaengine, dan.j.williams,
Andreas Färber, linux-arm-kernel
In-Reply-To: <CABHD4K92yySOJs9heBienGBieu6N+ALj7NKcAPvThQGXMWfOdA@mail.gmail.com>
Hi,
> I do have a cover letter for this series , But CCed only to Actions
> Semi SoC maintainers
> and mailing list.
and following is the link to cover letter for v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2020-May/732075.html
Thanks
-Amit
_______________________________________________
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 4/4] thermal: cpuidle: Register cpuidle cooling device
From: Daniel Lezcano @ 2020-05-15 11:03 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, open list:CPU IDLE TIME MANAGEMENT FRAMEWORK,
Rafael J. Wysocki, open list, open list:CPUIDLE DRIVER - ARM PSCI,
rui.zhang, Lukasz Luba
In-Reply-To: <20200515095751.GA25267@bogus>
On 15/05/2020 11:58, Sudeep Holla wrote:
> On Mon, May 04, 2020 at 08:00:01PM +0200, Daniel Lezcano wrote:
>>
>> Hi,
>>
>> On 29/04/2020 23:01, Daniel Lezcano wrote:
>>> On 29/04/2020 22:02, Lukasz Luba wrote:
>>>>
>>>>
>>>> On 4/29/20 11:36 AM, Daniel Lezcano wrote:
>>>>> The cpuidle driver can be used as a cooling device by injecting idle
>>>>> cycles. The DT binding for the idle state added an optional
>>>>>
>>>>> When the property is set, register the cpuidle driver with the idle
>>>>> state node pointer as a cooling device. The thermal framework will do
>>>>> the association automatically with the thermal zone via the
>>>>> cooling-device defined in the device tree cooling-maps section.
>>>>>
>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>>> ---
>>>>> - V4:
>>>>> - Do not check the return value as the function does no longer
>>>>> return one
>>>>> ---
>>>
>>> [ ... ]
>>>
>>>> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
>>>
>>> Thanks Lukasz for the review.
>>>
>>> Rafael, as Lorenzo and Sudeep are not responsive, could you consider ack
>>> this patch so I can merge the series through the thermal tree ?
>>
>> Gentle ping ... Sudeep, Lorenzo or Rafael ?
>>
>
> Sorry for the delay. I ignore this as it was generic and I was fine with
> it. Didn't know you were waiting me, sorry for that.
No problem, thanks for the ack.
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Rafael, if you are ok with that, I'll take this patch in the thermal
tree along with the others.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Use cpus_have_final_cap for has_vhe()
From: David Brazdil @ 2020-05-15 11:02 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, Suzuki K Poulose, James Morse, Julien Thierry, dbrazdil,
kvmarm, linux-arm-kernel
In-Reply-To: <20200513103828.74580-1-maz@kernel.org>
Hi Marc,
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: David Brazdil <dbrazdil@google.com>
Thanks, this is really helpful for the 'Split off nVHE code' series. Tested
them together and things seem to work just fine.
David
_______________________________________________
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-15 10:59 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: <CGME20200515110002eucas1p136759396d9b61f214d1f14856c009501@eucas1p1.samsung.com>
[-- Attachment #1.1: Type: text/plain, Size: 1410 bytes --]
It was <2020-05-15 pią 11:10>, when Stephan Mueller wrote:
> As I mentioned, all that is or seems to be analyzed here is the
> quality of the cryptographic post-processing. Thus none of the data
> can be used for getting an idea of the entropy content.
>
> That said, the ent value indeed looks too low which seems to be an
> issue in the tool itself.
>
> Note, for an entropy assessment commonly at least 1 million traces
> from the raw noise source are needed.
I've got 1MiB from each source. Of course I used raw data from /dev/hwrng
for tpm, exynos and rng200.
| Source | ea_iid -i | ea_iid -c (h') | ent |
|--------------+-----------+----------------+----------|
| /dev/random | 7.875064 | 0.998166 | 7.999801 |
| /dev/urandom | 7.879351 | 0.998373 | 7.999821 |
| tpm-rng | 7.880012 | 0.998118 | 7.999828 |
| exynos-trng | 7.435701 | 0.947574 | 7.991820 |
| rng200 | 7.883320 | 0.998592 | 7.999824 |
> See for examples on how such entropy assessments are conducted in the LRNG
> documentation [1] or the Linux /dev/random implementation in [2]
Thanks a lot, I am reading.
I will try to write somthing clever as soon as I parse and understand
these documents (and do other stuff too). Thank you very much for your help.
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
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