* Re: [PATCH v3 07/11] kselftest: arm64: fake_sigreturn_bad_size_for_magic0
From: Cristian Marussi @ 2019-08-30 14:49 UTC (permalink / raw)
To: Dave Martin; +Cc: andreyknvl, shuah, linux-arm-kernel, linux-kselftest
In-Reply-To: <20190813162550.GE10425@arm.com>
On 13/08/2019 17:25, Dave Martin wrote:
> On Fri, Aug 02, 2019 at 06:02:56PM +0100, Cristian Marussi wrote:
>> Added a simple fake_sigreturn testcase which builds a ucontext_t
>
> Add
Ok
>
>> with a badly sized magic0 header and place it onto the stack.
>
> I usually call a record with magic number 0 a "terminator record".
>
Ok
>> Expects a SIGSEGV on test PASS.
>>
>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>> ---
>> .../arm64/signal/testcases/.gitignore | 1 +
>> .../fake_sigreturn_bad_size_for_magic0.c | 57 +++++++++++++++++++
>> 2 files changed, 58 insertions(+)
>> create mode 100644 tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_bad_size_for_magic0.c
>>
>> diff --git a/tools/testing/selftests/arm64/signal/testcases/.gitignore b/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> index 0ea6fdc3765c..cf2a73599818 100644
>> --- a/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> +++ b/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> @@ -5,3 +5,4 @@ mangle_pstate_invalid_mode_el2
>> mangle_pstate_invalid_mode_el3
>> mangle_pstate_ssbs_regs
>> fake_sigreturn_bad_magic
>> +fake_sigreturn_bad_size_for_magic0
>> diff --git a/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_bad_size_for_magic0.c b/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_bad_size_for_magic0.c
>> new file mode 100644
>> index 000000000000..2f53c4740c85
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_bad_size_for_magic0.c
>> @@ -0,0 +1,57 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright (C) 2019 ARM Limited */
>> +
>
> #include <signal.h> ?
>
Ok
>> +#include <stdio.h>
>> +#include <ucontext.h>
>> +
>> +#include "test_signals_utils.h"
>> +#include "testcases.h"
>> +
>> +struct fake_sigframe sf;
>> +
>> +#define MIN_SZ_ALIGN 16
>> +
>> +static int fake_sigreturn_bad_size_for_magic0_run(struct tdescr *td,
>> + siginfo_t *si, ucontext_t *uc)
>> +{
>> + size_t resv_sz, offset;
>> + struct _aarch64_ctx *shead = GET_SF_RESV_HEAD(sf), *head;
>> +
>> + /* just to fill the ucontext_t with something real */
>> + if (!get_current_context(td, &sf.uc))
>> + return 1;
>> +
>> + resv_sz = GET_SF_RESV_SIZE(sf);
>> + /*
>> + * find the terminator, preserving existing headers
>> + * and verify amount of spare room in __reserved area.
>> + */
>> + head = get_terminator(shead, resv_sz, &offset);
>> + /*
>> + * try stripping extra_context header when low on space:
>> + * we need at least HDR_SZ + 16 space for the bad sized terminator.
>> + */
>> + if (head && resv_sz - offset < HDR_SZ + MIN_SZ_ALIGN) {
>> + fprintf(stderr, "Low on space:%zd. Discarding extra_context.\n",
>> + resv_sz - offset);
>> + head = get_header(shead, EXTRA_MAGIC, resv_sz, &offset);
>> + }
>> + /* just give up and timeout if still not enough space */
>> + if (head && resv_sz - offset >= HDR_SZ + MIN_SZ_ALIGN) {
>> + head->magic = 0;
>> + head->size = MIN_SZ_ALIGN;
>
> This is different from the amount of space we tested for
> (HDR_SZ + MIN_SZ_ALIGN) earlier.
>
> I'm not sure it matters which we use, but we should be consistent.
>
> I suggest sticking with HDR_SZ, unless there's something I've missed.
>
I'll stick to HDR_SZ in this case and use the new helper from 06/11
(get_starting_head)
> [...]
>
> Cheers
> ---Dave
>
Cheers
Cristian
_______________________________________________
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 01/10] KVM: arm64: Document PV-time interface
From: Andrew Jones @ 2019-08-30 14:47 UTC (permalink / raw)
To: Steven Price
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <20190830084255.55113-2-steven.price@arm.com>
On Fri, Aug 30, 2019 at 09:42:46AM +0100, Steven Price wrote:
> Introduce a paravirtualization interface for KVM/arm64 based on the
> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>
> This only adds the details about "Stolen Time" as the details of "Live
> Physical Time" have not been fully agreed.
>
> User space can specify a reserved area of memory for the guest and
> inform KVM to populate the memory with information on time that the host
> kernel has stolen from the guest.
>
> A hypercall interface is provided for the guest to interrogate the
> hypervisor's support for this interface and the location of the shared
> memory structures.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> Documentation/virt/kvm/arm/pvtime.txt | 64 +++++++++++++++++++++++++
> Documentation/virt/kvm/devices/vcpu.txt | 14 ++++++
> 2 files changed, 78 insertions(+)
> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
>
> diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
> new file mode 100644
> index 000000000000..dda3f0f855b9
> --- /dev/null
> +++ b/Documentation/virt/kvm/arm/pvtime.txt
> @@ -0,0 +1,64 @@
> +Paravirtualized time support for arm64
> +======================================
> +
> +Arm specification DEN0057/A defined a standard for paravirtualised time
> +support for AArch64 guests:
> +
> +https://developer.arm.com/docs/den0057/a
> +
> +KVM/arm64 implements the stolen time part of this specification by providing
> +some hypervisor service calls to support a paravirtualized guest obtaining a
> +view of the amount of time stolen from its execution.
> +
> +Two new SMCCC compatible hypercalls are defined:
> +
> +PV_FEATURES 0xC5000020
> +PV_TIME_ST 0xC5000022
> +
> +These are only available in the SMC64/HVC64 calling convention as
> +paravirtualized time is not available to 32 bit Arm guests. The existence of
> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
> +mechanism before calling it.
> +
> +PV_FEATURES
> + Function ID: (uint32) : 0xC5000020
> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
PV_TIME_LPT doesn't exist
> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
> + PV-time feature is supported by the hypervisor.
> +
> +PV_TIME_ST
> + Function ID: (uint32) : 0xC5000022
> + Return value: (int64) : IPA of the stolen time data structure for this
> + VCPU. On failure:
> + NOT_SUPPORTED (-1)
> +
> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
> +with inner and outer write back caching attributes, in the inner shareable
> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
> +meaningfully filled by the hypervisor (see structure below).
> +
> +PV_TIME_ST returns the structure for the calling VCPU.
> +
> +Stolen Time
> +-----------
> +
> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
> +
> + Field | Byte Length | Byte Offset | Description
> + ----------- | ----------- | ----------- | --------------------------
> + Revision | 4 | 0 | Must be 0 for version 0.1
> + Attributes | 4 | 4 | Must be 0
The above fields don't appear to be exposed to userspace in anyway. How
will we handle migration from one KVM with one version of the structure
to another?
> + Stolen time | 8 | 8 | Stolen time in unsigned
> + | | | nanoseconds indicating how
> + | | | much time this VCPU thread
> + | | | was involuntarily not
> + | | | running on a physical CPU.
> +
> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
> +will be present within a reserved region of the normal memory given to the
> +guest. The guest should not attempt to write into this memory. There is a
> +structure per VCPU of the guest.
Should we provide a recommendation as to how that reserved memory is
provided? One memslot divided into NR_VCPUS subregions? Should the
reserved region be described to the guest kernel with DT/ACPI? Or
should userspace ensure the region is not within any DT/ACPI described
regions?
> +
> +For the user space interface see Documentation/virt/kvm/devices/vcpu.txt
> +section "3. GROUP: KVM_ARM_VCPU_PVTIME_CTRL".
> +
> diff --git a/Documentation/virt/kvm/devices/vcpu.txt b/Documentation/virt/kvm/devices/vcpu.txt
> index 2b5dab16c4f2..896777f76f36 100644
> --- a/Documentation/virt/kvm/devices/vcpu.txt
> +++ b/Documentation/virt/kvm/devices/vcpu.txt
> @@ -60,3 +60,17 @@ time to use the number provided for a given timer, overwriting any previously
> configured values on other VCPUs. Userspace should configure the interrupt
> numbers on at least one VCPU after creating all VCPUs and before running any
> VCPUs.
> +
> +3. GROUP: KVM_ARM_VCPU_PVTIME_CTRL
> +Architectures: ARM64
> +
> +3.1 ATTRIBUTE: KVM_ARM_VCPU_PVTIME_SET_IPA
> +Parameters: 64-bit base address
> +Returns: -ENXIO: Stolen time not implemented
> + -EEXIST: Base address already set for this VCPU
> + -EINVAL: Base address not 64 byte aligned
> +
> +Specifies the base address of the stolen time structure for this VCPU. The
> +base address must be 64 byte aligned and exist within a valid guest memory
> +region. See Documentation/virt/kvm/arm/pvtime.txt for more information
> +including the layout of the stolen time structure.
> --
> 2.20.1
>
Thanks,
drew
_______________________________________________
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 01/11] asm-generic: add dma_zone_size
From: Catalin Marinas @ 2019-08-30 14:45 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: linux-mm, linux-riscv, will, Christoph Hellwig, m.szyprowski,
linux-arch, f.fainelli, frowand.list, devicetree, Arnd Bergmann,
marc.zyngier, robh+dt, linux-rpi-kernel, linux-arm-kernel, phill,
mbrugger, eric, linux-kernel, iommu, wahrenst, akpm, Robin Murphy
In-Reply-To: <027272c27398b950f207101a2c5dbc07a30a36bc.camel@suse.de>
On Mon, Aug 26, 2019 at 03:46:52PM +0200, Nicolas Saenz Julienne wrote:
> On Mon, 2019-08-26 at 09:09 +0200, Christoph Hellwig wrote:
> > On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne wrote:
> > > Some architectures have platform specific DMA addressing limitations.
> > > This will allow for hardware description code to provide the constraints
> > > in a generic manner, so as for arch code to properly setup it's memory
> > > zones and DMA mask.
> >
> > I know this just spreads the arm code, but I still kinda hate it.
>
> Rob's main concern was finding a way to pass the constraint from HW definition
> to arch without widening fdt's architecture specific function surface. I'd say
> it's fair to argue that having a generic mechanism makes sense as it'll now
> traverse multiple archs and subsystems.
>
> I get adding globals like this is not very appealing, yet I went with it as it
> was the easier to integrate with arm's code. Any alternative suggestions?
In some discussion with Robin, since it's just RPi4 that we are aware of
having such requirement on arm64, he suggested that we have a permanent
ZONE_DMA on arm64 with a default size of 1GB. It should cover all arm64
SoCs we know of without breaking the single Image binary. The arch/arm
can use its current mach-* support.
I may like this more than the proposed early_init_dt_get_dma_zone_size()
here which checks for specific SoCs (my preferred way was to build the
mask from all buses described in DT but I hadn't realised the
complications).
--
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 v3 06/11] kselftest: arm64: fake_sigreturn_bad_magic
From: Cristian Marussi @ 2019-08-30 14:29 UTC (permalink / raw)
To: Dave Martin; +Cc: andreyknvl, shuah, linux-arm-kernel, linux-kselftest
In-Reply-To: <20190813162523.GD10425@arm.com>
Hi
On 13/08/2019 17:25, Dave Martin wrote:
> On Fri, Aug 02, 2019 at 06:02:55PM +0100, Cristian Marussi wrote:
>> Added a simple fake_sigreturn testcase which builds a ucontext_t
>
> Add
Ok
>
>> with a bad magic header and place it onto the stack.
>> Expects a SIGSEGV on test PASS.
>> This commit also introduces a common utility assembly function to
>> invoke a sigreturn using a fake provided sigframe.
>>
>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>> ---
>> tools/testing/selftests/arm64/signal/Makefile | 2 +-
>> .../testing/selftests/arm64/signal/signals.S | 64 +++++++++++++++++++
>> .../arm64/signal/test_signals_utils.h | 1 +
>> .../arm64/signal/testcases/.gitignore | 1 +
>> .../testcases/fake_sigreturn_bad_magic.c | 63 ++++++++++++++++++
>> 5 files changed, 130 insertions(+), 1 deletion(-)
>> create mode 100644 tools/testing/selftests/arm64/signal/signals.S
>> create mode 100644 tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_bad_magic.c
>>
>> diff --git a/tools/testing/selftests/arm64/signal/Makefile b/tools/testing/selftests/arm64/signal/Makefile
>> index 8c8d08be4b0d..b3dcf315b5a4 100644
>> --- a/tools/testing/selftests/arm64/signal/Makefile
>> +++ b/tools/testing/selftests/arm64/signal/Makefile
>> @@ -80,7 +80,7 @@ endif
>> # Common test-unit targets to build common-layout test-cases executables
>> # Needs secondary expansion to properly include the testcase c-file in pre-reqs
>> .SECONDEXPANSION:
>> -$(PROGS): test_signals.c test_signals_utils.c testcases/testcases.c $$@.c test_signals.h test_signals_utils.h testcases/testcases.h
>> +$(PROGS): test_signals.c test_signals_utils.c testcases/testcases.c signals.S $$@.c test_signals.h test_signals_utils.h testcases/testcases.h
>> @if [ ! -d $(khdr_dir) ]; then \
>> echo -n "\n!!! WARNING: $(khdr_dir) NOT FOUND."; \
>> echo "===> Are you sure Kernel Headers have been installed properly ?\n"; \
>> diff --git a/tools/testing/selftests/arm64/signal/signals.S b/tools/testing/selftests/arm64/signal/signals.S
>> new file mode 100644
>> index 000000000000..6262b877400b
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/signal/signals.S
>> @@ -0,0 +1,64 @@
>> +/*
>> + * SPDX-License-Identifier: GPL-2.0
>> + * Copyright (C) 2019 ARM Limited
>> + */
>> +
>> +#include <asm/unistd.h>
>> +
>> +.section ".rodata", "a"
>
> The section name is not usually quoted in .section (though I guess it
> works).
>
Ok
>> +call_fmt:
>> + .asciz "Calling sigreturn with fake sigframe sized:%zd at calculated SP @%08lX\n"
>> +
>> +.text
>> +
>> +.globl fake_sigreturn
>> +
>> +/* fake_sigreturn x0:&sigframe, x1:sigframe_size, x2:alignment_SP */
>> +fake_sigreturn:
>> + mov x20, x0
>> + mov x21, x1
>> + mov x22, x2
>> + mov x23, sp
>> +
>> + /* create space on the stack for fake sigframe..."x22"-aligned */
>> + mov x0, #0
>
> Why to we move 0 into x0? We clobber x0 again in the next instruction:
Yes unneeded.
>> + add x0, x21, x22
>> + sub x22, x22, #1
>> + bic x0, x0, x22
>> + sub x23, x23, x0
>
> Can you explain the logic here? I'm not sure I understand what this is
> trying to do exactly.
The attempt is to make space on the stack for a x22-bytes-aligned sigframe
of at least x21-bytes-size (assuming x22 is power-of-two):
- calculate the needed aligned space (sigframe_size + x22) & ~(x22 - 1)
- calculate new SP in x23: x3 = sp - needed_aligned_space
- later down... move SP to the calculated sp in x23
- copy the provided sigframe on such new SP
> I notice you further modify this in patch 11 -- see my comments there,
> where I also suggest an alternative way of specifying a misaligned frame
> that might be simpler.
I've seen your comments on patch 11. I think I'll simplify that as you suggested:
patch 11 was meant to add the capability to misalign the sigframe on the SP
(which is needed in testcase contained in 11) but in fact is better if I move all
of the simplified logic here.
>> +
>> + ldr x0, =call_fmt
>> + mov x1, x21
>> + mov x2, x23
>> + bl printf
>> +
>> + mov sp, x23
>> +
>> + /* now fill it with the provided content... */
>> + mov x0, sp
>> + mov x1, x20
>> + mov x2, x21
>> + bl memcpy
>> +
>> + /*
>> + * Here saving a last minute SP to current->token acts as a marker:
>> + * if we got here, we are successfully faking a sigreturn; in other
>> + * words we are sure no bad fatal signal has been raised till now
>> + * for unrelated reasons, so we should consider the possibl observed
>
> typo: possible (or possibly?)
>
possibly
>> + * fatal signal like SEGV coming from Kernel restore_sigframe() and
>> + * triggered as expected from our test-case.
>> + * For simplicity this assumes that current field 'token' is laid out
>> + * as first in struct tdescr
>> + */
>> + ldr x0, current
>> + str x23, [x0]
>> + /* SP is already pointing back to the just built fake sigframe here */
>> + mov x8, #__NR_rt_sigreturn
>> + svc #0
>> +
>> + /*
>> + * Above sigreturn should not return...looping here leads to a timeout
>> + * and ensure proper and clean test failure, instead of jumping around
>> + * on a potentially corrupted stack.
>> + */
>> + b .
>> diff --git a/tools/testing/selftests/arm64/signal/test_signals_utils.h b/tools/testing/selftests/arm64/signal/test_signals_utils.h
>> index ce35be8ebc8e..2a71da7e6695 100644
>> --- a/tools/testing/selftests/arm64/signal/test_signals_utils.h
>> +++ b/tools/testing/selftests/arm64/signal/test_signals_utils.h
>> @@ -12,4 +12,5 @@ int test_run(struct tdescr *td);
>> void test_result(struct tdescr *td);
>>
>> bool get_current_context(struct tdescr *td, ucontext_t *dest_uc);
>> +int fake_sigreturn(void *sigframe, size_t sz, int alignment);
>> #endif
>> diff --git a/tools/testing/selftests/arm64/signal/testcases/.gitignore b/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> index a48a118b1a1a..0ea6fdc3765c 100644
>> --- a/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> +++ b/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> @@ -4,3 +4,4 @@ mangle_pstate_invalid_mode_el1
>> mangle_pstate_invalid_mode_el2
>> mangle_pstate_invalid_mode_el3
>> mangle_pstate_ssbs_regs
>> +fake_sigreturn_bad_magic
>> diff --git a/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_bad_magic.c b/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_bad_magic.c
>> new file mode 100644
>> index 000000000000..b4c063e02a7a
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_bad_magic.c
>> @@ -0,0 +1,63 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright (C) 2019 ARM Limited */
>> +
>
> We should probably also include <signal.h> here, since we're using
> siginfo_t etc.
Yes indeed. It was included via some other headers only.
>
>> +#include <stdio.h>
>> +#include <ucontext.h>
>> +
>> +#include "test_signals_utils.h"
>> +#include "testcases.h"
>> +
>> +struct fake_sigframe sf;
>> +
>> +static int fake_sigreturn_bad_magic_run(struct tdescr *td,
>> + siginfo_t *si, ucontext_t *uc)
>> +{
>> + size_t resv_sz, offset;
>> + struct _aarch64_ctx *shead = GET_SF_RESV_HEAD(sf), *head;
>> +
>> + /* just to fill the ucontext_t with something real */
>> + if (!get_current_context(td, &sf.uc))
>> + return 1;
>> +
>> + resv_sz = GET_SF_RESV_SIZE(sf);
>> + /*
>> + * find the terminator, preserving existing headers
>> + * and verify amount of spare room in __reserved area.
>> + */
>> + head = get_terminator(shead, resv_sz, &offset);
>> + /*
>> + * try stripping extra_context header when low on space:
>> + * we need at least 2*HDR_SZ space ... one for the KSFT_BAD_MAGIC
>> + * and the other for the usual terminator.
>> + */
>> + if (head && resv_sz - offset < HDR_SZ * 2) {
>
> Can we factor out this logic for finding space in the signal frame?
>
> We do pretty much the same thing in all the fake_sigreturn tests...
Ok
>
>> + fprintf(stderr, "Low on space:%zd. Discarding extra_context.\n",
>> + resv_sz - offset);
>> + head = get_header(shead, EXTRA_MAGIC, resv_sz, &offset);
>> + }
>> + /* just give up and timeout if still not enough space */
>
> Do we actually time out? I don't see where we actually wait, so doesn't
> test_run() just fail immediately?
>
> The same applies to all the other fake_sigreturn tests too.
>
Right. It is probably a leftover.
SIGALRM is used as an extreme measure to kill tests gone bad, but this
can happen only once the fake sigframe has been effectively placed on the stack
and sigreturned.
>> + if (head && resv_sz - offset >= HDR_SZ) {
>
> Should this be HDR_SZ * 2 again? We need space for the face header and
> space to write a terminator after it.
I'll fix in the new factored out code.
>
>> + fprintf(stderr, "Mangling template header. Spare space:%zd\n",
>> + resv_sz - offset);
>> + /*
>> + * use a well known NON existent bad magic...something
>> + * we should pretty sure won't be ever defined in Kernel
>> + */
>> + head->magic = KSFT_BAD_MAGIC;
>> + head->size = HDR_SZ;
>> + write_terminator_record(GET_RESV_NEXT_HEAD(head));
>> +
>> + ASSERT_BAD_CONTEXT(&sf.uc);
>> + fake_sigreturn(&sf, sizeof(sf), 16);
>> + }
>> +
>> + return 1;
>> +}
>
> [...]
>
> Cheers
> ---Dave
>
Cheers
Cristian
_______________________________________________
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 00/20] Initial support for Marvell MMP3 SoC
From: Marc Zyngier @ 2019-08-30 14:26 UTC (permalink / raw)
To: Lubomir Rintel, Olof Johansson
Cc: Mark Rutland, devicetree, Jason Cooper, Stephen Boyd,
linux-kernel, Michael Turquette, Russell King,
Kishon Vijay Abraham I, Rob Herring, Thomas Gleixner, linux-clk,
linux-arm-kernel
In-Reply-To: <481e832401c148baf222639f10f494b90dcd23c9.camel@v3.sk>
On 26/08/2019 12:59, Lubomir Rintel wrote:
> On Fri, 2019-08-23 at 10:42 +0100, Marc Zyngier wrote:
>> On 23/08/2019 08:21, Lubomir Rintel wrote:
>>> On Thu, 2019-08-22 at 11:31 +0100, Marc Zyngier wrote:
>>>> On 22/08/2019 10:26, Lubomir Rintel wrote:
>>>>> Hi,
>>>>>
>>>>> this is a second spin of a patch set that adds support for the Marvell
>>>>> MMP3 processor. MMP3 is used in OLPC XO-4 laptops, Panasonic Toughpad
>>>>> FZ-A1 tablet and Dell Wyse 3020 Tx0D thin clients.
>>>>>
>>>>> Compared to v1, there's a handful of fixes in response to reviews. Patch
>>>>> 02/20 is new. Details in individual patches.
>>>>>
>>>>> Apart from the adjustments in mach-mmp/, the patch makes necessary
>>>>> changes to the irqchip driver and adds an USB2 PHY driver. The latter
>>>>> has a dependency on the mach-mmp/ changes, so it can't be submitted
>>>>> separately.
>>>>>
>>>>> The patch set has been tested to work on Wyse Tx0D and not ruin MMP2
>>>>> support on XO-1.75.
>>>>
>>>> How do you want this series to be merged? I'm happy to take the irqchip
>>>> related patches as well as the corresponding DT change (once reviewed)
>>>> through my tree.
>>>
>>> I was hoping for the Arm SoC tree, because there are some dependencies
>>> (MMP3 USB PHY depends on MMP3 SoC).
>>>
>>> That said, the irqchip patches are rather independent and the only
>>> downside of them going in via a different tree will be that the other
>>> tree that will lack them won't boot on MMP3 (things will compile
>>> though). I don't know if that's okay. What's typically done in cases
>>> like these?
>>
>> I usually take the irqchip patches that can be built standalone (without
>> dependency on header files, for example). If you want them to go via
>> another tree, stick my
>>
>> Acked-by: Marc Zyngier <maz@kernel.org>
>>
>> on patches #6 through #9.
>
> Actually, please go ahead and pick the irqchip patches into your tree.
>
> The rest of the patch set may need a couple more spins, and it will be
> nice if it gets shorter.
Applied to irqchip-next.
M.
--
Jazz is not dead, it just smells funny...
_______________________________________________
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 v11 00/23] MT8183 IOMMU SUPPORT
From: Joerg Roedel @ 2019-08-30 14:21 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, chao.hao, Robin Murphy, linux-kernel, Evan Green,
Tomasz Figa, iommu, Rob Herring, linux-mediatek, Matthias Brugger,
ming-fan.chen, anan.sun, Will Deacon, Matthias Kaehlcke,
linux-arm-kernel
In-Reply-To: <1566615728-26388-1-git-send-email-yong.wu@mediatek.com>
On Sat, Aug 24, 2019 at 11:01:45AM +0800, Yong Wu wrote:
> Change notes:
> v11:
> 1) Adjust a bit code for mtk quirk in v7s.
> 2) Collect ack from will and Matthias of the last patch.
Applied to arm/mediatek, 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 5/8] lib: vdso: Remove checks on return value for 32 bit vDSO
From: Vincenzo Frascino @ 2019-08-30 14:16 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linux-kernel, linux-mips,
linux-kselftest
Cc: catalin.marinas, 0x7f454c46, salyzyn, paul.burton, luto, tglx,
will
In-Reply-To: <20190830135902.20861-6-vincenzo.frascino@arm.com>
On 30/08/2019 14:58, Vincenzo Frascino wrote:
> Since all the architectures that support the generic vDSO library have
> been converted to support the 32 bit fallbacks it is not required
> anymore to check the return value of __cvdso_clock_get*time32_common()
> before updating the old_timespec fields.
>
> Remove the related checks from the generic vdso library.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> CC: Andy Lutomirski <luto@kernel.org>
Forgot to add to this patch:
Suggested-by: Andy Lutomirski <luto@kernel.org>
> References: c60a32ea4f45 ("lib/vdso/32: Provide legacy syscall fallbacks")
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> ---
> lib/vdso/gettimeofday.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
> index 2c4b311c226d..d5bc16748f81 100644
> --- a/lib/vdso/gettimeofday.c
> +++ b/lib/vdso/gettimeofday.c
> @@ -129,10 +129,10 @@ __cvdso_clock_gettime32(clockid_t clock, struct old_timespec32 *res)
> if (unlikely(ret))
> return clock_gettime32_fallback(clock, res);
>
> - if (likely(!ret)) {
> - res->tv_sec = ts.tv_sec;
> - res->tv_nsec = ts.tv_nsec;
> - }
> + /* For ret == 0 */
> + res->tv_sec = ts.tv_sec;
> + res->tv_nsec = ts.tv_nsec;
> +
> return ret;
> }
> #endif /* BUILD_VDSO32 */
> @@ -238,10 +238,10 @@ __cvdso_clock_getres_time32(clockid_t clock, struct old_timespec32 *res)
> if (unlikely(ret))
> return clock_getres32_fallback(clock, res);
>
> - if (likely(!ret)) {
> - res->tv_sec = ts.tv_sec;
> - res->tv_nsec = ts.tv_nsec;
> - }
> + /* For ret == 0 */
> + res->tv_sec = ts.tv_sec;
> + res->tv_nsec = ts.tv_nsec;
> +
> return ret;
> }
> #endif /* BUILD_VDSO32 */
>
--
Regards,
Vincenzo
_______________________________________________
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 8/8] x86: vdso: Remove unused VDSO_HAS_32BIT_FALLBACK
From: Vincenzo Frascino @ 2019-08-30 13:59 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linux-kernel, linux-mips,
linux-kselftest
Cc: catalin.marinas, 0x7f454c46, salyzyn, paul.burton, luto, tglx,
will
In-Reply-To: <20190830135902.20861-1-vincenzo.frascino@arm.com>
VDSO_HAS_32BIT_FALLBACK has been removed from the core since
the architectures that support the generic vDSO library have
been converted to support the 32 bit fallbacks.
Remove unused VDSO_HAS_32BIT_FALLBACK from x86 vdso.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
arch/x86/include/asm/vdso/gettimeofday.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/vdso/gettimeofday.h b/arch/x86/include/asm/vdso/gettimeofday.h
index ba71a63cdac4..6aa8e3eda31d 100644
--- a/arch/x86/include/asm/vdso/gettimeofday.h
+++ b/arch/x86/include/asm/vdso/gettimeofday.h
@@ -96,8 +96,6 @@ long clock_getres_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
#else
-#define VDSO_HAS_32BIT_FALLBACK 1
-
static __always_inline
long clock_gettime_fallback(clockid_t _clkid, struct __kernel_timespec *_ts)
{
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 7/8] mips: vdso: Remove unused VDSO_HAS_32BIT_FALLBACK
From: Vincenzo Frascino @ 2019-08-30 13:59 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linux-kernel, linux-mips,
linux-kselftest
Cc: catalin.marinas, 0x7f454c46, salyzyn, paul.burton, luto, tglx,
will
In-Reply-To: <20190830135902.20861-1-vincenzo.frascino@arm.com>
VDSO_HAS_32BIT_FALLBACK has been removed from the core since
the architectures that support the generic vDSO library have
been converted to support the 32 bit fallbacks.
Remove unused VDSO_HAS_32BIT_FALLBACK from mips vdso.
Cc: Paul Burton <paul.burton@mips.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
arch/mips/include/asm/vdso/gettimeofday.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/mips/include/asm/vdso/gettimeofday.h b/arch/mips/include/asm/vdso/gettimeofday.h
index e78462e8ca2e..5ad2b086626d 100644
--- a/arch/mips/include/asm/vdso/gettimeofday.h
+++ b/arch/mips/include/asm/vdso/gettimeofday.h
@@ -107,8 +107,6 @@ static __always_inline int clock_getres_fallback(
#if _MIPS_SIM != _MIPS_SIM_ABI64
-#define VDSO_HAS_32BIT_FALLBACK 1
-
static __always_inline long clock_gettime32_fallback(
clockid_t _clkid,
struct old_timespec32 *_ts)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 6/8] arm64: compat: vdso: Remove unused VDSO_HAS_32BIT_FALLBACK
From: Vincenzo Frascino @ 2019-08-30 13:59 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linux-kernel, linux-mips,
linux-kselftest
Cc: catalin.marinas, 0x7f454c46, salyzyn, paul.burton, luto, tglx,
will
In-Reply-To: <20190830135902.20861-1-vincenzo.frascino@arm.com>
VDSO_HAS_32BIT_FALLBACK has been removed from the core since
the architectures that support the generic vDSO library have
been converted to support the 32 bit fallbacks.
Remove unused VDSO_HAS_32BIT_FALLBACK from arm64 compat vdso.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/vdso/compat_gettimeofday.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/include/asm/vdso/compat_gettimeofday.h b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
index fe7afe0f1a3d..537b1e695365 100644
--- a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
@@ -16,7 +16,6 @@
#define VDSO_HAS_CLOCK_GETRES 1
-#define VDSO_HAS_32BIT_FALLBACK 1
#define BUILD_VDSO32 1
static __always_inline
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/8] lib: vdso: Remove checks on return value for 32 bit vDSO
From: Vincenzo Frascino @ 2019-08-30 13:58 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linux-kernel, linux-mips,
linux-kselftest
Cc: catalin.marinas, 0x7f454c46, salyzyn, paul.burton, luto, tglx,
will
In-Reply-To: <20190830135902.20861-1-vincenzo.frascino@arm.com>
Since all the architectures that support the generic vDSO library have
been converted to support the 32 bit fallbacks it is not required
anymore to check the return value of __cvdso_clock_get*time32_common()
before updating the old_timespec fields.
Remove the related checks from the generic vdso library.
Cc: Thomas Gleixner <tglx@linutronix.de>
CC: Andy Lutomirski <luto@kernel.org>
References: c60a32ea4f45 ("lib/vdso/32: Provide legacy syscall fallbacks")
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
lib/vdso/gettimeofday.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
index 2c4b311c226d..d5bc16748f81 100644
--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -129,10 +129,10 @@ __cvdso_clock_gettime32(clockid_t clock, struct old_timespec32 *res)
if (unlikely(ret))
return clock_gettime32_fallback(clock, res);
- if (likely(!ret)) {
- res->tv_sec = ts.tv_sec;
- res->tv_nsec = ts.tv_nsec;
- }
+ /* For ret == 0 */
+ res->tv_sec = ts.tv_sec;
+ res->tv_nsec = ts.tv_nsec;
+
return ret;
}
#endif /* BUILD_VDSO32 */
@@ -238,10 +238,10 @@ __cvdso_clock_getres_time32(clockid_t clock, struct old_timespec32 *res)
if (unlikely(ret))
return clock_getres32_fallback(clock, res);
- if (likely(!ret)) {
- res->tv_sec = ts.tv_sec;
- res->tv_nsec = ts.tv_nsec;
- }
+ /* For ret == 0 */
+ res->tv_sec = ts.tv_sec;
+ res->tv_nsec = ts.tv_nsec;
+
return ret;
}
#endif /* BUILD_VDSO32 */
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/8] lib: vdso: Remove VDSO_HAS_32BIT_FALLBACK
From: Vincenzo Frascino @ 2019-08-30 13:58 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linux-kernel, linux-mips,
linux-kselftest
Cc: catalin.marinas, 0x7f454c46, salyzyn, paul.burton, luto, tglx,
will
In-Reply-To: <20190830135902.20861-1-vincenzo.frascino@arm.com>
VDSO_HAS_32BIT_FALLBACK was introduced to address a regression which
caused seccomp to deny access to the applications to clock_gettime64()
and clock_getres64() because they are not enabled in the existing
filters.
The purpose of VDSO_HAS_32BIT_FALLBACK was to simplify the conditional
implementation of __cvdso_clock_get*time32() variants.
Now that all the architectures that support the generic vDSO library
have been converted to support the 32 bit fallbacks the conditional
can be removed.
Cc: Thomas Gleixner <tglx@linutronix.de>
CC: Andy Lutomirski <luto@kernel.org>
References: c60a32ea4f45 ("lib/vdso/32: Provide legacy syscall fallbacks")
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
lib/vdso/gettimeofday.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
index a86e89e6dedc..2c4b311c226d 100644
--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -126,13 +126,8 @@ __cvdso_clock_gettime32(clockid_t clock, struct old_timespec32 *res)
ret = __cvdso_clock_gettime_common(clock, &ts);
-#ifdef VDSO_HAS_32BIT_FALLBACK
if (unlikely(ret))
return clock_gettime32_fallback(clock, res);
-#else
- if (unlikely(ret))
- ret = clock_gettime_fallback(clock, &ts);
-#endif
if (likely(!ret)) {
res->tv_sec = ts.tv_sec;
@@ -240,13 +235,8 @@ __cvdso_clock_getres_time32(clockid_t clock, struct old_timespec32 *res)
ret = __cvdso_clock_getres_common(clock, &ts);
-#ifdef VDSO_HAS_32BIT_FALLBACK
if (unlikely(ret))
return clock_getres32_fallback(clock, res);
-#else
- if (unlikely(ret))
- ret = clock_getres_fallback(clock, &ts);
-#endif
if (likely(!ret)) {
res->tv_sec = ts.tv_sec;
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/8] vdso: Complete the conversion to 32bit syscalls
From: Vincenzo Frascino @ 2019-08-30 13:58 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linux-kernel, linux-mips,
linux-kselftest
Cc: catalin.marinas, 0x7f454c46, salyzyn, paul.burton, luto, tglx,
will
This patch series is a follow up to "lib/vdso, x86/vdso: Fix fallout
from generic VDSO conversion" [1].
The main purpose is to complete the 32bit vDSOs conversion to use the
legacy 32bit syscalls as a fallback. With the conversion of all the
architectures present in -next complete, this patch series removes as
well the conditional choice in between 32 and 64 bit for 32bit vDSOs.
This series has been rebased on linux-next/master.
[1] https://lkml.org/lkml/2019/7/28/86
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Vincenzo Frascino (8):
arm64: compat: vdso: Expose BUILD_VDSO32
lib: vdso: Build 32 bit specific functions in the right context
mips: compat: vdso: Use legacy syscalls as fallback
lib: vdso: Remove VDSO_HAS_32BIT_FALLBACK
lib: vdso: Remove checks on return value for 32 bit vDSO
arm64: compat: vdso: Remove unused VDSO_HAS_32BIT_FALLBACK
mips: vdso: Remove unused VDSO_HAS_32BIT_FALLBACK
x86: vdso: Remove unused VDSO_HAS_32BIT_FALLBACK
.../include/asm/vdso/compat_gettimeofday.h | 2 +-
arch/mips/include/asm/vdso/gettimeofday.h | 43 +++++++++++++++++++
arch/mips/vdso/config-n32-o32-env.c | 1 +
arch/x86/include/asm/vdso/gettimeofday.h | 2 -
lib/vdso/gettimeofday.c | 30 ++++++-------
5 files changed, 57 insertions(+), 21 deletions(-)
--
2.23.0
_______________________________________________
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 3/8] mips: compat: vdso: Use legacy syscalls as fallback
From: Vincenzo Frascino @ 2019-08-30 13:58 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linux-kernel, linux-mips,
linux-kselftest
Cc: catalin.marinas, 0x7f454c46, salyzyn, paul.burton, luto, tglx,
will
In-Reply-To: <20190830135902.20861-1-vincenzo.frascino@arm.com>
The generic VDSO implementation uses the Y2038 safe clock_gettime64() and
clock_getres_time64() syscalls as fallback for 32bit VDSO. This breaks
seccomp setups because these syscalls might be not (yet) allowed.
Implement the 32bit variants which use the legacy syscalls and select the
variant in the core library.
The 64bit time variants are not removed because they are required for the
time64 based vdso accessors.
Cc: Paul Burton <paul.burton@mips.com>
Fixes: 00b26474c2f1 ("lib/vdso: Provide generic VDSO implementation")
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
arch/mips/include/asm/vdso/gettimeofday.h | 45 +++++++++++++++++++++++
arch/mips/vdso/config-n32-o32-env.c | 1 +
2 files changed, 46 insertions(+)
diff --git a/arch/mips/include/asm/vdso/gettimeofday.h b/arch/mips/include/asm/vdso/gettimeofday.h
index c59fe08b0347..e78462e8ca2e 100644
--- a/arch/mips/include/asm/vdso/gettimeofday.h
+++ b/arch/mips/include/asm/vdso/gettimeofday.h
@@ -105,6 +105,51 @@ static __always_inline int clock_getres_fallback(
return error ? -ret : ret;
}
+#if _MIPS_SIM != _MIPS_SIM_ABI64
+
+#define VDSO_HAS_32BIT_FALLBACK 1
+
+static __always_inline long clock_gettime32_fallback(
+ clockid_t _clkid,
+ struct old_timespec32 *_ts)
+{
+ register struct old_timespec32 *ts asm("a1") = _ts;
+ register clockid_t clkid asm("a0") = _clkid;
+ register long ret asm("v0");
+ register long nr asm("v0") = __NR_clock_gettime;
+ register long error asm("a3");
+
+ asm volatile(
+ " syscall\n"
+ : "=r" (ret), "=r" (error)
+ : "r" (clkid), "r" (ts), "r" (nr)
+ : "$1", "$3", "$8", "$9", "$10", "$11", "$12", "$13",
+ "$14", "$15", "$24", "$25", "hi", "lo", "memory");
+
+ return error ? -ret : ret;
+}
+
+static __always_inline int clock_getres32_fallback(
+ clockid_t _clkid,
+ struct old_timespec32 *_ts)
+{
+ register struct old_timespec32 *ts asm("a1") = _ts;
+ register clockid_t clkid asm("a0") = _clkid;
+ register long ret asm("v0");
+ register long nr asm("v0") = __NR_clock_getres;
+ register long error asm("a3");
+
+ asm volatile(
+ " syscall\n"
+ : "=r" (ret), "=r" (error)
+ : "r" (clkid), "r" (ts), "r" (nr)
+ : "$1", "$3", "$8", "$9", "$10", "$11", "$12", "$13",
+ "$14", "$15", "$24", "$25", "hi", "lo", "memory");
+
+ return error ? -ret : ret;
+}
+#endif
+
#ifdef CONFIG_CSRC_R4K
static __always_inline u64 read_r4k_count(void)
diff --git a/arch/mips/vdso/config-n32-o32-env.c b/arch/mips/vdso/config-n32-o32-env.c
index 7f8d957abd4a..0011a632aef2 100644
--- a/arch/mips/vdso/config-n32-o32-env.c
+++ b/arch/mips/vdso/config-n32-o32-env.c
@@ -10,6 +10,7 @@
*/
#undef CONFIG_64BIT
+#define BUILD_VDSO32
#define CONFIG_32BIT 1
#define CONFIG_GENERIC_ATOMIC64 1
#define BUILD_VDSO32_64
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/8] lib: vdso: Build 32 bit specific functions in the right context
From: Vincenzo Frascino @ 2019-08-30 13:58 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linux-kernel, linux-mips,
linux-kselftest
Cc: catalin.marinas, 0x7f454c46, salyzyn, paul.burton, luto, tglx,
will
In-Reply-To: <20190830135902.20861-1-vincenzo.frascino@arm.com>
clock_gettime32 and clock_getres_time32 should be compiled only with a
32 bit vdso library.
Exclude these symbols when BUILD_VDSO32 is not defined.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
---
lib/vdso/gettimeofday.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
index e630e7ff57f1..a86e89e6dedc 100644
--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -117,6 +117,7 @@ __cvdso_clock_gettime(clockid_t clock, struct __kernel_timespec *ts)
return 0;
}
+#ifdef BUILD_VDSO32
static __maybe_unused int
__cvdso_clock_gettime32(clockid_t clock, struct old_timespec32 *res)
{
@@ -139,6 +140,7 @@ __cvdso_clock_gettime32(clockid_t clock, struct old_timespec32 *res)
}
return ret;
}
+#endif /* BUILD_VDSO32 */
static __maybe_unused int
__cvdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
@@ -229,6 +231,7 @@ int __cvdso_clock_getres(clockid_t clock, struct __kernel_timespec *res)
return 0;
}
+#ifdef BUILD_VDSO32
static __maybe_unused int
__cvdso_clock_getres_time32(clockid_t clock, struct old_timespec32 *res)
{
@@ -251,4 +254,5 @@ __cvdso_clock_getres_time32(clockid_t clock, struct old_timespec32 *res)
}
return ret;
}
+#endif /* BUILD_VDSO32 */
#endif /* VDSO_HAS_CLOCK_GETRES */
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/8] arm64: compat: vdso: Expose BUILD_VDSO32
From: Vincenzo Frascino @ 2019-08-30 13:58 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linux-kernel, linux-mips,
linux-kselftest
Cc: catalin.marinas, 0x7f454c46, salyzyn, paul.burton, luto, tglx,
will
In-Reply-To: <20190830135902.20861-1-vincenzo.frascino@arm.com>
clock_gettime32 and clock_getres_time32 should be compiled only with the
32 bit vdso library.
Expose BUILD_VDSO32 when arm64 compat is compiled, to provide an
indication to the generic library to include these symbols.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/vdso/compat_gettimeofday.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/vdso/compat_gettimeofday.h b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
index c50ee1b7d5cd..fe7afe0f1a3d 100644
--- a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
@@ -17,6 +17,7 @@
#define VDSO_HAS_CLOCK_GETRES 1
#define VDSO_HAS_32BIT_FALLBACK 1
+#define BUILD_VDSO32 1
static __always_inline
int gettimeofday_fallback(struct __kernel_old_timeval *_tv,
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [GIT PULL] Texas Instruments K3 SoC changes for 5.4
From: Tero Kristo @ 2019-08-30 13:50 UTC (permalink / raw)
To: arm, soc
Cc: Nishanth Menon, Lokesh Vutla, Santosh Shilimkar,
Devshatwar, Nikhil, linux-arm-kernel@lists.infradead.org
Hello arm-soc maintainers,
Here are the changes for TI K3 SoC family for 5.4. This pull request is
based on top of drivers_soc_for_5.4 [1] from Santosh, basically because
there is hard dependency on this pull towards that. Otherwise any of the
DTS patches applying exclusive access flags will fail to compile.
I am hoping this is fine, please holler if you have anything against
this sequencing approach.
[1] https://lkml.org/lkml/2019/8/26/1124
-Tero
-----------
The following changes since commit 23013399a2252e9f592c2c52a62b213d3ef09217:
soc: ti: ti_sci_pm_domains: Add support for exclusive and shared
access (2019-08-26 20:00:41 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux
tags/ti-k3-soc-for-v5.4
for you to fetch changes up to d6dabd6f59c426e5d3eeb8a853dbda4818185ce1:
arm64: dts: ti: k3-j721e-main: Fix gic-its node unit-address
(2019-08-29 16:05:00 +0300)
----------------------------------------------------------------
Texas Instruments K3 SoC family changes for 5.4
- Typo fixes for gic-its unit addresses for both am654 and j721e
- HW spinlock nodes added for both am654 and j721e
- GPIO support for j721e
- power-domain cells update for both am654 / j721e for exclusive only
access
----------------------------------------------------------------
Lokesh Vutla (6):
arm64: dts: ti: k3-am654: Update the power domain cells
arm64: dts: ti: k3-j721e: Update the power domain cells
arm64: dts: ti: k3-j721e: Add gpio nodes in main domain
arm64: dts: ti: k3-j721e: Add gpio nodes in wakeup domain
arm64: dts: ti: k3-j721e-common-proc-board: Disable unused gpio
modules
dt-bindings: pinctrl: k3: Introduce pinmux definitions for J721E
Nikhil Devshatwar (1):
arm64: dts: k3-j721e: Add gpio-keys on common processor board
Suman Anna (4):
arm64: dts: ti: k3-am65-main: Add hwspinlock node
arm64: dts: ti: k3-j721e-main: Add hwspinlock node
arm64: dts: ti: k3-am65-main: Fix gic-its node unit-address
arm64: dts: ti: k3-j721e-main: Fix gic-its node unit-address
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 52 ++++---
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 10 +-
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 6 +-
arch/arm64/boot/dts/ti/k3-am65.dtsi | 1 +
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 1 +
.../boot/dts/ti/k3-j721e-common-proc-board.dts | 69 +++++++++
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 160
+++++++++++++++++++--
arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 40 +++++-
arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 +
include/dt-bindings/pinctrl/k3.h | 3 +
10 files changed, 298 insertions(+), 45 deletions(-)
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm: fix page faults in do_alignment
From: Russell King - ARM Linux admin @ 2019-08-30 13:48 UTC (permalink / raw)
To: Jing Xiangfeng
Cc: kstewart, gustavo, gregkh, linux-kernel, linux-mm, ebiederm,
sakari.ailus, bhelgaas, tglx, linux-arm-kernel
In-Reply-To: <20190830133522.GZ13294@shell.armlinux.org.uk>
Please fix your email.
jingxiangfeng@huawei.com
host mx7.huawei.com [168.195.93.46]
SMTP error from remote mail server after pipelined DATA:
554 5.7.1 spf check result is none
SPF is *not* required for email.
If you wish to impose such restrictions on email, then I reserve the
right to ignore your patches until this issue is resolved! ;)
On Fri, Aug 30, 2019 at 02:35:22PM +0100, Russell King - ARM Linux admin wrote:
> On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
> > The function do_alignment can handle misaligned address for user and
> > kernel space. If it is a userspace access, do_alignment may fail on
> > a low-memory situation, because page faults are disabled in
> > probe_kernel_address.
> >
> > Fix this by using __copy_from_user stead of probe_kernel_address.
> >
> > Fixes: b255188 ("ARM: fix scheduling while atomic warning in alignment handling code")
> > Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
>
> NAK.
>
> The "scheduling while atomic warning in alignment handling code" is
> caused by fixing up the page fault while trying to handle the
> mis-alignment fault generated from an instruction in atomic context.
>
> Your patch re-introduces that bug.
>
> > ---
> > arch/arm/mm/alignment.c | 16 +++++++++++++---
> > 1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
> > index 04b3643..2ccabd3 100644
> > --- a/arch/arm/mm/alignment.c
> > +++ b/arch/arm/mm/alignment.c
> > @@ -774,6 +774,7 @@ static ssize_t alignment_proc_write(struct file *file, const char __user *buffer
> > unsigned long instr = 0, instrptr;
> > int (*handler)(unsigned long addr, unsigned long instr, struct pt_regs *regs);
> > unsigned int type;
> > + mm_segment_t fs;
> > unsigned int fault;
> > u16 tinstr = 0;
> > int isize = 4;
> > @@ -784,16 +785,22 @@ static ssize_t alignment_proc_write(struct file *file, const char __user *buffer
> >
> > instrptr = instruction_pointer(regs);
> >
> > + fs = get_fs();
> > + set_fs(KERNEL_DS);
> > if (thumb_mode(regs)) {
> > u16 *ptr = (u16 *)(instrptr & ~1);
> > - fault = probe_kernel_address(ptr, tinstr);
> > + fault = __copy_from_user(tinstr,
> > + (__force const void __user *)ptr,
> > + sizeof(tinstr));
> > tinstr = __mem_to_opcode_thumb16(tinstr);
> > if (!fault) {
> > if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
> > IS_T32(tinstr)) {
> > /* Thumb-2 32-bit */
> > u16 tinst2 = 0;
> > - fault = probe_kernel_address(ptr + 1, tinst2);
> > + fault = __copy_from_user(tinst2,
> > + (__force const void __user *)(ptr+1),
> > + sizeof(tinst2));
> > tinst2 = __mem_to_opcode_thumb16(tinst2);
> > instr = __opcode_thumb32_compose(tinstr, tinst2);
> > thumb2_32b = 1;
> > @@ -803,10 +810,13 @@ static ssize_t alignment_proc_write(struct file *file, const char __user *buffer
> > }
> > }
> > } else {
> > - fault = probe_kernel_address((void *)instrptr, instr);
> > + fault = __copy_from_user(instr,
> > + (__force const void __user *)instrptr,
> > + sizeof(instr));
> > instr = __mem_to_opcode_arm(instr);
> > }
> >
> > + set_fs(fs);
> > if (fault) {
> > type = TYPE_FAULT;
> > goto bad_or_fault;
> > --
> > 1.8.3.1
> >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm: fix page faults in do_alignment
From: Russell King - ARM Linux admin @ 2019-08-30 13:35 UTC (permalink / raw)
To: Jing Xiangfeng
Cc: kstewart, gustavo, gregkh, linux-kernel, linux-mm, ebiederm,
sakari.ailus, bhelgaas, tglx, linux-arm-kernel
In-Reply-To: <1567171877-101949-1-git-send-email-jingxiangfeng@huawei.com>
On Fri, Aug 30, 2019 at 09:31:17PM +0800, Jing Xiangfeng wrote:
> The function do_alignment can handle misaligned address for user and
> kernel space. If it is a userspace access, do_alignment may fail on
> a low-memory situation, because page faults are disabled in
> probe_kernel_address.
>
> Fix this by using __copy_from_user stead of probe_kernel_address.
>
> Fixes: b255188 ("ARM: fix scheduling while atomic warning in alignment handling code")
> Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
NAK.
The "scheduling while atomic warning in alignment handling code" is
caused by fixing up the page fault while trying to handle the
mis-alignment fault generated from an instruction in atomic context.
Your patch re-introduces that bug.
> ---
> arch/arm/mm/alignment.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
> index 04b3643..2ccabd3 100644
> --- a/arch/arm/mm/alignment.c
> +++ b/arch/arm/mm/alignment.c
> @@ -774,6 +774,7 @@ static ssize_t alignment_proc_write(struct file *file, const char __user *buffer
> unsigned long instr = 0, instrptr;
> int (*handler)(unsigned long addr, unsigned long instr, struct pt_regs *regs);
> unsigned int type;
> + mm_segment_t fs;
> unsigned int fault;
> u16 tinstr = 0;
> int isize = 4;
> @@ -784,16 +785,22 @@ static ssize_t alignment_proc_write(struct file *file, const char __user *buffer
>
> instrptr = instruction_pointer(regs);
>
> + fs = get_fs();
> + set_fs(KERNEL_DS);
> if (thumb_mode(regs)) {
> u16 *ptr = (u16 *)(instrptr & ~1);
> - fault = probe_kernel_address(ptr, tinstr);
> + fault = __copy_from_user(tinstr,
> + (__force const void __user *)ptr,
> + sizeof(tinstr));
> tinstr = __mem_to_opcode_thumb16(tinstr);
> if (!fault) {
> if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
> IS_T32(tinstr)) {
> /* Thumb-2 32-bit */
> u16 tinst2 = 0;
> - fault = probe_kernel_address(ptr + 1, tinst2);
> + fault = __copy_from_user(tinst2,
> + (__force const void __user *)(ptr+1),
> + sizeof(tinst2));
> tinst2 = __mem_to_opcode_thumb16(tinst2);
> instr = __opcode_thumb32_compose(tinstr, tinst2);
> thumb2_32b = 1;
> @@ -803,10 +810,13 @@ static ssize_t alignment_proc_write(struct file *file, const char __user *buffer
> }
> }
> } else {
> - fault = probe_kernel_address((void *)instrptr, instr);
> + fault = __copy_from_user(instr,
> + (__force const void __user *)instrptr,
> + sizeof(instr));
> instr = __mem_to_opcode_arm(instr);
> }
>
> + set_fs(fs);
> if (fault) {
> type = TYPE_FAULT;
> goto bad_or_fault;
> --
> 1.8.3.1
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps 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] arm: fix page faults in do_alignment
From: Jing Xiangfeng @ 2019-08-30 13:31 UTC (permalink / raw)
To: linux, ebiederm, kstewart, gregkh, gustavo, bhelgaas,
jingxiangfeng, tglx, sakari.ailus
Cc: linux-mm, linux-kernel, linux-arm-kernel
The function do_alignment can handle misaligned address for user and
kernel space. If it is a userspace access, do_alignment may fail on
a low-memory situation, because page faults are disabled in
probe_kernel_address.
Fix this by using __copy_from_user stead of probe_kernel_address.
Fixes: b255188 ("ARM: fix scheduling while atomic warning in alignment handling code")
Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com>
---
arch/arm/mm/alignment.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 04b3643..2ccabd3 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -774,6 +774,7 @@ static ssize_t alignment_proc_write(struct file *file, const char __user *buffer
unsigned long instr = 0, instrptr;
int (*handler)(unsigned long addr, unsigned long instr, struct pt_regs *regs);
unsigned int type;
+ mm_segment_t fs;
unsigned int fault;
u16 tinstr = 0;
int isize = 4;
@@ -784,16 +785,22 @@ static ssize_t alignment_proc_write(struct file *file, const char __user *buffer
instrptr = instruction_pointer(regs);
+ fs = get_fs();
+ set_fs(KERNEL_DS);
if (thumb_mode(regs)) {
u16 *ptr = (u16 *)(instrptr & ~1);
- fault = probe_kernel_address(ptr, tinstr);
+ fault = __copy_from_user(tinstr,
+ (__force const void __user *)ptr,
+ sizeof(tinstr));
tinstr = __mem_to_opcode_thumb16(tinstr);
if (!fault) {
if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
IS_T32(tinstr)) {
/* Thumb-2 32-bit */
u16 tinst2 = 0;
- fault = probe_kernel_address(ptr + 1, tinst2);
+ fault = __copy_from_user(tinst2,
+ (__force const void __user *)(ptr+1),
+ sizeof(tinst2));
tinst2 = __mem_to_opcode_thumb16(tinst2);
instr = __opcode_thumb32_compose(tinstr, tinst2);
thumb2_32b = 1;
@@ -803,10 +810,13 @@ static ssize_t alignment_proc_write(struct file *file, const char __user *buffer
}
}
} else {
- fault = probe_kernel_address((void *)instrptr, instr);
+ fault = __copy_from_user(instr,
+ (__force const void __user *)instrptr,
+ sizeof(instr));
instr = __mem_to_opcode_arm(instr);
}
+ set_fs(fs);
if (fault) {
type = TYPE_FAULT;
goto bad_or_fault;
--
1.8.3.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RESEND PATCH 0/5] Add bluetooth support for Orange Pi 3
From: Maxime Ripard @ 2019-08-30 13:20 UTC (permalink / raw)
To: Marcel Holtmann
Cc: megous, Mark Rutland, Johan Hedberg, devicetree, netdev,
linux-kernel, linux-bluetooth, Chen-Yu Tsai, Rob Herring,
David S. Miller, linux-arm-kernel
In-Reply-To: <D02B89FB-F8C0-40AD-A99A-6C1B4FEB72A0@holtmann.org>
On Fri, Aug 30, 2019 at 02:43:48PM +0200, Marcel Holtmann wrote:
> >>> (Resend to add missing lists, sorry for the noise.)
> >>>
> >>> This series implements bluetooth support for Xunlong Orange Pi 3 board.
> >>>
> >>> The board uses AP6256 WiFi/BT 5.0 chip.
> >>>
> >>> Summary of changes:
> >>>
> >>> - add more delay to let initialize the chip
> >>> - let the kernel detect firmware file path
> >>> - add new compatible and update dt-bindings
> >>> - update Orange Pi 3 / H6 DTS
> >>>
> >>> Please take a look.
> >>>
> >>> thank you and regards,
> >>> Ondrej Jirman
> >>>
> >>> Ondrej Jirman (5):
> >>> dt-bindings: net: Add compatible for BCM4345C5 bluetooth device
> >>> bluetooth: bcm: Add support for loading firmware for BCM4345C5
> >>> bluetooth: hci_bcm: Give more time to come out of reset
> >>> arm64: dts: allwinner: h6: Add pin configs for uart1
> >>> arm64: dts: allwinner: orange-pi-3: Enable UART1 / Bluetooth
> >>>
> >>> .../bindings/net/broadcom-bluetooth.txt | 1 +
> >>> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 19 +++++++++++++++++++
> >>> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++++++++++
> >>> drivers/bluetooth/btbcm.c | 3 +++
> >>> drivers/bluetooth/hci_bcm.c | 3 ++-
> >>> 5 files changed, 35 insertions(+), 1 deletion(-)
> >>
> >> all 5 patches have been applied to bluetooth-next tree.
> >
> > The DTS patches (last 2) should go through the arm-soc tree, can you
> > drop them?
>
> why is that? We have included DTS changes for Bluetooth devices
> directly all the time. What is different with this hardware?
I guess some maintainers are more relaxed with it than we are then,
but for the why, well, it's the usual reasons, the most immediate one
being that it reduces to a minimum the conflicts between trees.
The other being that it's not really usual to merge patches supposed
to be handled by another maintainer without (at least) his
consent. I'm pretty sure you would have asked the same request if I
would have merged the bluetooth patches through my tree without
notice.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
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] i2c: mediatek: disable zero-length transfers for mt8183
From: Wolfram Sang @ 2019-08-30 13:08 UTC (permalink / raw)
To: Hsin-Yi Wang
Cc: linux-arm-kernel, Nicolas Boichat, Alexandru M Stan, Jun Gao,
linux-kernel, linux-mediatek, linux-i2c, Matthias Brugger,
Yingjoe Chen, Thomas Gleixner, Qii Wang
In-Reply-To: <20190822094516.55130-1-hsinyi@chromium.org>
[-- Attachment #1.1: Type: text/plain, Size: 1629 bytes --]
On Thu, Aug 22, 2019 at 05:45:17PM +0800, Hsin-Yi Wang wrote:
> When doing i2cdetect quick write mode, we would get transfer
> error ENOMEM, and i2cdetect shows there's no device at the address.
> Quoting from mt8183 datasheet, the number of transfers to be
> transferred in one transaction should be set to bigger than 1,
> so we should forbid zero-length transfer and update functionality.
>
> Incorrect return:
> localhost ~ # i2cdetect -q -y 0
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> After this patch:
> localhost ~ # i2cdetect -q -y 0
> Error: Can't use SMBus Quick Write command on this bus
>
> localhost ~ # i2cdetect -y 0
> Warning: Can't use SMBus Quick Write command, will skip some addresses
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00:
> 10:
> 20:
> 30: -- -- -- -- -- -- -- --
> 40:
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60:
> 70:
Thanks for providing these test results. Much appreciated. To shorten
the commit log a little, I removed them before applying, though.
>
> Reported-by: Alexandru M Stan <amstan@chromium.org>
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Applied to for-next, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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] drm/mcde: Fix DSI transfers
From: Linus Walleij @ 2019-08-30 13:06 UTC (permalink / raw)
To: dri-devel, Maarten Lankhorst, Maxime Ripard, Sean Paul
Cc: Linus Walleij, Stephan Gerhold, linux-arm-kernel
There were bugs in the DSI transfer (read and write) function
as it was only tested with displays ever needing a single byte
to be written. Fixed it up and tested so we can now write
messages of up to 16 bytes and read up to 4 bytes from the
display.
Tested with a Sony ACX424AKP display: this display now self-
identifies and can control backlight in command mode.
Cc: Stephan Gerhold <stephan@gerhold.net>
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpu/drm/mcde/mcde_dsi.c | 70 ++++++++++++++++++++++-----------
1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 07f7090d08b3..ad76a36e7bc1 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -178,22 +178,26 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
const u32 loop_delay_us = 10; /* us */
const u8 *tx = msg->tx_buf;
u32 loop_counter;
- size_t txlen;
+ size_t txlen = msg->tx_len;
+ size_t rxlen = msg->rx_len;
u32 val;
int ret;
int i;
- txlen = msg->tx_len;
- if (txlen > 12) {
+ if (txlen > 16) {
dev_err(d->dev,
- "dunno how to write more than 12 bytes yet\n");
+ "dunno how to write more than 16 bytes yet\n");
+ return -EIO;
+ }
+ if (rxlen > 4) {
+ dev_err(d->dev,
+ "dunno how to read more than 4 bytes yet\n");
return -EIO;
}
dev_dbg(d->dev,
- "message to channel %d, %zd bytes",
- msg->channel,
- txlen);
+ "message to channel %d, write %zd bytes read %zd bytes\n",
+ msg->channel, txlen, rxlen);
/* Command "nature" */
if (MCDE_DSI_HOST_IS_READ(msg->type))
@@ -210,9 +214,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
if (mipi_dsi_packet_format_is_long(msg->type))
val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LONGNOTSHORT;
val |= 0 << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_ID_SHIFT;
- /* Add one to the length for the MIPI DCS command */
- val |= txlen
- << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
+ val |= txlen << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LP_EN;
val |= msg->type << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHIFT;
writel(val, d->regs + DSI_DIRECT_CMD_MAIN_SETTINGS);
@@ -249,17 +251,36 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
writel(1, d->regs + DSI_DIRECT_CMD_SEND);
loop_counter = 1000 * 1000 / loop_delay_us;
- while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
- DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
- && --loop_counter)
- usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
-
- if (!loop_counter) {
- dev_err(d->dev, "DSI write timeout!\n");
- return -ETIME;
+ if (MCDE_DSI_HOST_IS_READ(msg->type)) {
+ /* Read command */
+ while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
+ (DSI_DIRECT_CMD_STS_READ_COMPLETED |
+ DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR))
+ && --loop_counter)
+ usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
+ if (!loop_counter) {
+ dev_err(d->dev, "DSI write timeout!\n");
+ return -ETIME;
+ }
+ } else {
+ /* Writing only */
+ while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
+ DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
+ && --loop_counter)
+ usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
+
+ if (!loop_counter) {
+ dev_err(d->dev, "DSI write timeout!\n");
+ return -ETIME;
+ }
}
val = readl(d->regs + DSI_DIRECT_CMD_STS);
+ if (val & DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR) {
+ dev_err(d->dev, "read completed with error\n");
+ writel(1, d->regs + DSI_DIRECT_CMD_RD_INIT);
+ return -EIO;
+ }
if (val & DSI_DIRECT_CMD_STS_ACKNOWLEDGE_WITH_ERR_RECEIVED) {
val >>= DSI_DIRECT_CMD_STS_ACK_VAL_SHIFT;
dev_err(d->dev, "error during transmission: %04x\n",
@@ -269,10 +290,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
if (!MCDE_DSI_HOST_IS_READ(msg->type)) {
/* Return number of bytes written */
- if (mipi_dsi_packet_format_is_long(msg->type))
- ret = 4 + txlen;
- else
- ret = 4;
+ ret = txlen;
} else {
/* OK this is a read command, get the response */
u32 rdsz;
@@ -282,7 +300,13 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
rdsz = readl(d->regs + DSI_DIRECT_CMD_RD_PROPERTY);
rdsz &= DSI_DIRECT_CMD_RD_PROPERTY_RD_SIZE_MASK;
rddat = readl(d->regs + DSI_DIRECT_CMD_RDDAT);
- for (i = 0; i < 4 && i < rdsz; i++)
+ if (rdsz < rxlen) {
+ dev_err(d->dev, "read error, requested %d got %d\n",
+ msg->rx_len, rdsz);
+ return -EIO;
+ }
+ /* FIXME: read more than 4 bytes */
+ for (i = 0; i < 4 && i < rxlen; i++)
rx[i] = (rddat >> (i * 8)) & 0xff;
ret = rdsz;
}
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] ARM: multi_v7_defconfig: Make MAX77802 regulator driver built-in
From: Marek Szyprowski @ 2019-08-30 13:04 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel
Cc: Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Marek Szyprowski
In-Reply-To: <CGME20190830130425eucas1p1b6806fad77366797271e70ce8ef4d296@eucas1p1.samsung.com>
Maxim 77802 PMIC is a main PMIC for the following Exynos5 based boards:
Odroid XU, Chromebook Pit and Chromebook Pi. Driver for its voltage
regulator is needed very early during boot to properly instantiate SD/MMC
devices and mount rootfs, so change that driver to be compiled-in.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/configs/multi_v7_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 64aa1136d43c..3dc636c3c5c7 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -562,7 +562,7 @@ CONFIG_REGULATOR_MAX8997=m
CONFIG_REGULATOR_MAX8998=m
CONFIG_REGULATOR_MAX77686=y
CONFIG_REGULATOR_MAX77693=m
-CONFIG_REGULATOR_MAX77802=m
+CONFIG_REGULATOR_MAX77802=y
CONFIG_REGULATOR_PALMAS=y
CONFIG_REGULATOR_PBIAS=y
CONFIG_REGULATOR_PWM=y
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v1 2/2] i2c: iproc: Add full name of devicetree node to adapter name
From: Wolfram Sang @ 2019-08-30 12:59 UTC (permalink / raw)
To: Rayagonda Kokatanur
Cc: Mark Rutland, devicetree, Lori Hikichi, Florian Fainelli,
linux-kernel, Rob Herring, bcm-kernel-feedback-list, linux-i2c,
Ray Jui, linux-arm-kernel
In-Reply-To: <1565235473-28461-3-git-send-email-rayagonda.kokatanur@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 885 bytes --]
On Thu, Aug 08, 2019 at 09:07:53AM +0530, Rayagonda Kokatanur wrote:
> From: Lori Hikichi <lori.hikichi@broadcom.com>
>
> Add the full name of the devicetree node to the adapter name.
> Without this change, all adapters have the same name making it difficult
> to distinguish between multiple instances.
> The most obvious way to see this is to use the utility i2c_detect.
> e.g. "i2c-detect -l"
>
> Before
> i2c-1 i2c Broadcom iProc I2C adapter I2C adapter
> i2c-0 i2c Broadcom iProc I2C adapter I2C adapter
>
> After
> i2c-1 i2c Broadcom iProc (i2c@e0000) I2C adapter
> i2c-0 i2c Broadcom iProc (i2c@b0000) I2C adapter
>
> Now it is easy to figure out which adapter maps to a which DT node.
>
> Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Applied to for-next, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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