* [PATCH v2 0/7] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11
From: Herbert Xu @ 2017-01-12 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484152915-26517-1-git-send-email-ard.biesheuvel@linaro.org>
On Wed, Jan 11, 2017 at 04:41:48PM +0000, Ard Biesheuvel wrote:
> This adds ARM and arm64 implementations of ChaCha20, scalar AES and SIMD
> AES (using bit slicing). The SIMD algorithms in this series take advantage
> of the new skcipher walksize attribute to iterate over the input in the most
> efficient manner possible.
>
> Patch #1 adds a NEON implementation of ChaCha20 for ARM.
>
> Patch #2 adds a NEON implementation of ChaCha20 for arm64.
>
> Patch #3 modifies the existing NEON and ARMv8 Crypto Extensions implementations
> of AES-CTR to be available as a synchronous skcipher as well. This is intended
> for the mac80211 code, which uses synchronous encapsulations of ctr(aes)
> [ccm, gcm] in softirq context, during which arm64 supports use of SIMD code.
>
> Patch #4 adds a scalar implementation of AES for arm64, using the key schedule
> generation routines and lookup tables of the generic code in crypto/aes_generic.
>
> Patch #5 does the same for ARM, replacing existing scalar code that originated
> in the OpenSSL project, and contains redundant key schedule generation routines
> and lookup tables (and is slightly slower on modern cores)
>
> Patch #6 replaces the ARM bit sliced NEON code with a new implementation that
> has a number of advantages over the original code (which also originated in the
> OpenSSL project.) The performance should be identical.
>
> Patch #7 adds a port of the ARM bit-sliced AES code to arm64, in ECB, CBC, CTR
> and XTS modes.
>
> Due to the size of patch #7, it may be difficult to apply these patches from
> patchwork, so I pushed them here as well:
It seems to have made it.
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 2/2] crypto: mediatek - fix format string for 64-bit builds
From: Herbert Xu @ 2017-01-12 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111135601.4047225-1-arnd@arndb.de>
On Wed, Jan 11, 2017 at 02:55:20PM +0100, Arnd Bergmann wrote:
> After I enabled COMPILE_TEST for non-ARM targets, I ran into these
> warnings:
>
> crypto/mediatek/mtk-aes.c: In function 'mtk_aes_info_map':
> crypto/mediatek/mtk-aes.c:224:28: error: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Werror=format=]
> dev_err(cryp->dev, "dma %d bytes error\n", sizeof(*info));
> crypto/mediatek/mtk-sha.c:344:28: error: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Werror=format=]
> crypto/mediatek/mtk-sha.c:550:21: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'size_t {aka long unsigned int}' [-Werror=format=]
>
> The correct format for size_t is %zu, so use that in all three
> cases.
>
> Fixes: 785e5c616c84 ("crypto: mediatek - Add crypto driver support for some MediaTek chips")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 1/2] crypto: mediatek - remove ARM dependencies
From: Herbert Xu @ 2017-01-12 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111135104.3961730-1-arnd@arndb.de>
On Wed, Jan 11, 2017 at 02:50:19PM +0100, Arnd Bergmann wrote:
> Building the mediatek driver on an older ARM architecture results in a
> harmless warning:
>
> warning: (ARCH_OMAP2PLUS_TYPICAL && CRYPTO_DEV_MEDIATEK) selects NEON which has unmet direct dependencies (VFPv3 && CPU_V7)
>
> We could add an explicit dependency on CPU_V7, but it seems nicer to
> open up the build to additional configurations. This replaces the ARM
> optimized algorithm selection with the normal one that all other drivers
> use, and that in turn lets us relax the dependency on ARM and drop
> a number of the unrelated 'select' statements.
>
> Obviously a real user would still select those other optimized drivers
> as a fallback, but as there is no strict dependency, we can leave that
> up to the user.
>
> Fixes: 785e5c616c84 ("crypto: mediatek - Add crypto driver support for some MediaTek chips")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: mediatek: don't return garbage err on successful return
From: Herbert Xu @ 2017-01-12 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103132122.26900-1-colin.king@canonical.com>
On Tue, Jan 03, 2017 at 01:21:22PM +0000, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> In the case where keylen <= bs mtk_sha_setkey returns an uninitialized
> return value in err. Fix this by returning 0 instead of err.
>
> Issue detected by static analysis with cppcheck.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 0/3] crypto: picoxcell - Cleanups removing non-DT code
From: Herbert Xu @ 2017-01-12 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483376819-26726-1-git-send-email-javier@osg.samsung.com>
On Mon, Jan 02, 2017 at 02:06:56PM -0300, Javier Martinez Canillas wrote:
> Hello,
>
> This small series contains a couple of cleanups that removes some driver's code
> that isn't needed due the driver being for a DT-only platform.
>
> The changes were suggested by Arnd Bergmann as a response to a previous patch:
> https://lkml.org/lkml/2017/1/2/342
>
> Patch #1 allows the driver to be built when the COMPILE_TEST option is enabled.
> Patch #2 removes the platform ID table since isn't needed for DT-only drivers.
> Patch #3 removes a wrapper function that's also not needed if driver is DT-only.
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] arm64: Advertise support for Rounding double multiply instructions
From: Suzuki K Poulose @ 2017-01-12 16:37 UTC (permalink / raw)
To: linux-arm-kernel
ARM v8.1 extensions include support for rounding double multiply
add/subtract instructions to the A64 SIMD instructions set. Let
the userspace know about it via a HWCAP bit.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Applies on top of the MRS CPUID feature emulation series [1]
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/478007.html
---
arch/arm64/include/uapi/asm/hwcap.h | 1 +
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/cpuinfo.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index 773c90b..61c263c 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -31,5 +31,6 @@
#define HWCAP_FPHP (1 << 9)
#define HWCAP_ASIMDHP (1 << 10)
#define HWCAP_CPUID (1 << 11)
+#define HWCAP_ASIMDRDM (1 << 12)
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index fa707e3..936a129 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -872,6 +872,7 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA2_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SHA2),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_CRC32_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_CRC32),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_ATOMICS_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_ATOMICS),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_RDM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDRDM),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_FP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_FPHP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_ASIMD),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 4d44edd..5b22c68 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -64,6 +64,7 @@ static const char *const hwcap_str[] = {
"fphp",
"asimdhp",
"cpuid",
+ "asimdrdm",
NULL
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 7/7] uapi: export all headers under uapi directories
From: Nicolas Dichtel @ 2017-01-12 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LSU.2.20.1701121727180.19188@erq.vanv.qr>
Le 12/01/2017 ? 17:28, Jan Engelhardt a ?crit :
> On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:
>
>> Le 09/01/2017 ? 13:56, Christoph Hellwig a ?crit :
>>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>>>> Regularly, when a new header is created in include/uapi/, the developer
>>>> forgets to add it in the corresponding Kbuild file. This error is usually
>>>> detected after the release is out.
>>>>
>>>> In fact, all headers under uapi directories should be exported, thus it's
>>>> useless to have an exhaustive list.
>>>>
>>>> After this patch, the following files, which were not exported, are now
>>>> exported (with make headers_install_all):
>>>
>>> ... snip ...
>>>
>>>> linux/genwqe/.install
>>>> linux/genwqe/..install.cmd
>>>> linux/cifs/.install
>>>> linux/cifs/..install.cmd
>>>
>>> I'm pretty sure these should not be exported!
>>>
>> Those files are created in every directory:
>> $ find usr/include/ -name '\.\.install.cmd' | wc -l
>> 71
>
> That still does not mean they should be exported.
>
> Anything but headers (and directories as a skeleton structure) is maximally suspicious.
>
What I was trying to say is that I export those directories like other are.
Removing those files is not related to that series.
Regards,
Nicolas
^ permalink raw reply
* [PATCH v2 7/7] uapi: export all headers under uapi directories
From: Jan Engelhardt @ 2017-01-12 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <464a1323-4450-e563-ff59-9e6d57b75959@6wind.com>
On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:
>Le 09/01/2017 ? 13:56, Christoph Hellwig a ?crit :
>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>>> Regularly, when a new header is created in include/uapi/, the developer
>>> forgets to add it in the corresponding Kbuild file. This error is usually
>>> detected after the release is out.
>>>
>>> In fact, all headers under uapi directories should be exported, thus it's
>>> useless to have an exhaustive list.
>>>
>>> After this patch, the following files, which were not exported, are now
>>> exported (with make headers_install_all):
>>
>> ... snip ...
>>
>>> linux/genwqe/.install
>>> linux/genwqe/..install.cmd
>>> linux/cifs/.install
>>> linux/cifs/..install.cmd
>>
>> I'm pretty sure these should not be exported!
>>
>Those files are created in every directory:
>$ find usr/include/ -name '\.\.install.cmd' | wc -l
>71
That still does not mean they should be exported.
Anything but headers (and directories as a skeleton structure) is maximally suspicious.
^ permalink raw reply
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-12 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn2pW20VPP_yGtvJ_ufvj6Xj1poBiiA2WqkALiaLyyONug@mail.gmail.com>
>>> > I don't understand scl_period = 1 ?s for Fast Mode. For a bus freqency
>>> > of 400 kHz we need low + high = 2.5 ?s. Is there a factor 10 missing
>>> > somewhere?
>>>
>>> As CCR = SCL_period * I2C parent clk frequency with minimal freq =
>>> 2Mhz and SCL_period = 1 we have:
>>> CCR = 1 * 2Mhz = 2.
>>> But to compute, scl_low and scl_high in Fast mode, we have to do the
>>> following thing as Duty=1:
>>> scl_high = 9 * CCR * I2C parent clk period
>>> scl_low = 16 * CCR * I2C parent clk period
>>> In our example:
>>> scl_high = 9 * 2 * 0,0000005 = 0,000009 sec = 9 ?s
>>> scl_low = 16 * 2 * 0.0000005 = 0,000016 sec = 16 ?s
>>> So low + high = 27 ?s > 2,5 ?s
>>
>> For me 9 ?s + 16 ?s is 25 ?s, resulting in 40 kHz. That's why I wondered
>> if there is a factor 10 missing somewhere.
>
> Hum ok. I am going to double-check what is wrong because when I check
> with the scope I always reach 400Khz for SCL.
> I will let you know.
There is one point I miss here that is described in the reference manual:
To reach the 400 kHz maximum I?C fast mode clock, the I2C parent rate
must be a multiple of 10 MHz.
So, contrary to what we said in a previous thread, 400 kHz could not
be reached with low frequencies.
In that way, we could compute CCR with duty = 0 by default.
So, I find another formula very close to the first one I pushed in the
first version:
In fast mode, we compute CCR with duty = 0:
t_scl_high = CCR * I2C parent clk period
t_scl_low = 2 *CCR * I2C parent clk period
So, CCR = I2C parent rate / 400 kHz / 3
For example with parent rate = 40 MHz:
CCR = 40000000 / 400000 / 3 = 33.333333333 = 33
t_scl_high = 33 * (1 / 2000000) = 825 ns > 600 ns
t_scl_low = 2 * 16 * (1 / 2000000) = 1650 ns > 1300 ns
It seems ok now.
Best regards,
Cedric
^ permalink raw reply
* [PATCH] KVM: arm/arm64: vgic: Fix deadlock on error handling
From: Marc Zyngier @ 2017-01-12 16:16 UTC (permalink / raw)
To: linux-arm-kernel
Dmitry Vyukov reported that the syzkaller fuzzer triggered a
deadlock in the vgic setup code when an error was detected, as
the cleanup code tries to take a lock that is already held by
the setup code.
The fix is to avoid retaking the lock when cleaning up, by
telling the cleanup function that we already hold it.
Cc: stable at vger.kernel.org
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-init.c | 18 +++++++++++++-----
virt/kvm/arm/vgic/vgic-v2.c | 2 --
virt/kvm/arm/vgic/vgic-v3.c | 2 --
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 5114391..c737ea0 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -268,15 +268,11 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm)
{
struct vgic_dist *dist = &kvm->arch.vgic;
- mutex_lock(&kvm->lock);
-
dist->ready = false;
dist->initialized = false;
kfree(dist->spis);
dist->nr_spis = 0;
-
- mutex_unlock(&kvm->lock);
}
void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
@@ -286,7 +282,8 @@ void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
INIT_LIST_HEAD(&vgic_cpu->ap_list_head);
}
-void kvm_vgic_destroy(struct kvm *kvm)
+/* To be called with kvm->lock held */
+static void __kvm_vgic_destroy(struct kvm *kvm)
{
struct kvm_vcpu *vcpu;
int i;
@@ -297,6 +294,13 @@ void kvm_vgic_destroy(struct kvm *kvm)
kvm_vgic_vcpu_destroy(vcpu);
}
+void kvm_vgic_destroy(struct kvm *kvm)
+{
+ mutex_lock(&kvm->lock);
+ __kvm_vgic_destroy(kvm);
+ mutex_unlock(&kvm->lock);
+}
+
/**
* vgic_lazy_init: Lazy init is only allowed if the GIC exposed to the guest
* is a GICv2. A GICv3 must be explicitly initialized by the guest using the
@@ -348,6 +352,10 @@ int kvm_vgic_map_resources(struct kvm *kvm)
ret = vgic_v2_map_resources(kvm);
else
ret = vgic_v3_map_resources(kvm);
+
+ if (ret)
+ __kvm_vgic_destroy(kvm);
+
out:
mutex_unlock(&kvm->lock);
return ret;
diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
index 9bab867..834137e 100644
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -293,8 +293,6 @@ int vgic_v2_map_resources(struct kvm *kvm)
dist->ready = true;
out:
- if (ret)
- kvm_vgic_destroy(kvm);
return ret;
}
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index 7df1b90..a4c7fff 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -308,8 +308,6 @@ int vgic_v3_map_resources(struct kvm *kvm)
dist->ready = true;
out:
- if (ret)
- kvm_vgic_destroy(kvm);
return ret;
}
--
2.1.4
^ permalink raw reply related
* [Question] New mmap64 syscall?
From: Florian Weimer @ 2017-01-12 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103205437.GA22548@amd>
On 01/03/2017 09:54 PM, Pavel Machek wrote:
> ...actually, with strace and batched interface, it will be impossible
> to see what is going on because of races. So I'm not sure if I like
> the batched interface at all...
I'm not sure if I understand this problem.
ioctl, fcntl, most socket system calls, even open all have this problem
as well, right?
Thanks,
Florian
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-12 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112154548.twj2ktbfzbsarzbc@localhost>
On Thu, Jan 12, 2017 at 03:45:48PM +0000, Catalin Marinas wrote:
> On Wed, Jan 11, 2017 at 06:40:52PM +0000, Mark Rutland wrote:
> > Likewise, I beleive we may need to modify cpu_set_reserved_ttbr0().
>
> This may be fine if my assumptions about this erratum are correct. In
> the cpu_set_reserved_ttbr0() case we set TTBR0_EL1 to a table without
> any entries, so no new entries could be tagged with the old ASID.
For some reason, I was under the impression that the issue was old table
entries being allocated to the new ASID. Looking over the series again,
it's not clear to me precisely which cases can occur.
It would be good to see that clarified.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Will Deacon @ 2017-01-12 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112155558.ud4ln3lk5lpwxrq3@localhost>
On Thu, Jan 12, 2017 at 03:55:58PM +0000, Catalin Marinas wrote:
> On Wed, Jan 11, 2017 at 06:22:08PM +0000, Marc Zyngier wrote:
> > On 11/01/17 18:06, Catalin Marinas wrote:
> > > On Wed, Jan 11, 2017 at 09:41:15AM -0500, Christopher Covington wrote:
> > >> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> > >> index 32682be..9ee46df 100644
> > >> --- a/arch/arm64/mm/proc.S
> > >> +++ b/arch/arm64/mm/proc.S
> > >> @@ -23,6 +23,7 @@
> > >> #include <asm/assembler.h>
> > >> #include <asm/asm-offsets.h>
> > >> #include <asm/hwcap.h>
> > >> +#include <asm/mmu_context.h>
> > >> #include <asm/pgtable.h>
> > >> #include <asm/pgtable-hwdef.h>
> > >> #include <asm/cpufeature.h>
> > >> @@ -140,6 +141,18 @@ ENDPROC(cpu_do_resume)
> > >> ENTRY(cpu_do_switch_mm)
> > >> mmid x1, x1 // get mm->context.id
> > >> bfi x0, x1, #48, #16 // set the ASID
> > >> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
> > >> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
> > >> + mrs x2, ttbr0_el1
> > >> + mov x3, #FALKOR_RESERVED_ASID
> > >> + bfi x2, x3, #48, #16 // reserved ASID + old BADDR
> > >> + msr ttbr0_el1, x2
> > >> + isb
> > >> + bfi x2, x0, #0, #48 // reserved ASID + new BADDR
> > >> + msr ttbr0_el1, x2
> > >> + isb
> > >> +alternative_else_nop_endif
> > >> +#endif
> > >> msr ttbr0_el1, x0 // set TTBR0
> > >> isb
> > >> post_ttbr0_update_workaround
> > >
> > > Please move the above hunk to a pre_ttbr0_update_workaround macro for
> > > consistency with post_ttbr0_update_workaround.
> >
> > In which case (and also for consistency), should we add that pre_ttbr0
> > macro to entry.S, just before __uaccess_ttbr0_enable? It may not be
> > needed in the SW pan case, but it is probably worth entertaining the
> > idea that there may be something to do there...
>
> It may actually be needed in entry.S as well. With SW PAN, we move the
> context switching from cpu_do_switch_mm to the kernel_exit macro when
> returning to user. In this case we are switching from the reserved ASID
> 0 and reserved TTBR0_EL1 (pointing to a zeroed page) to the user's
> TTBR0_EL1 and ASID. If the ASID switch isn't taken into account, we may
> end up with new TLB entries being tagged with the reserved ASID. Apart
> from a potential loss of protection with TTBR0 PAN, is there anything
> else that could go wrong? Maybe a TLB conflict if we mix TLBs from
> multiple address spaces tagged with the same reserved ASID.
>
> If the above is an issue, we would need to patch
> __uaccess_ttbr0_enable() as well, though I'm more inclined to make this
> erratum not selectable when TTBR0 PAN is enabled.
I don't think that's a reasonable approach. By all means change the
default, but we need to support kernel images with both of these kconfig
options enabled.
Will
^ permalink raw reply
* [PATCH v3] arm64: mm: Fix NOMAP page initialization
From: Will Deacon @ 2017-01-12 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109115320.GI4930@rric.localdomain>
Hi Robert,
On Mon, Jan 09, 2017 at 12:53:20PM +0100, Robert Richter wrote:
> On 06.01.17 08:37:25, Ard Biesheuvel wrote:
> > Any comments on the performance impact (including boot time) ?
>
> I did a kernel compile test and kernel mode time increases by about
> 2.2%. Though this is already significant, we need a more suitable mem
> benchmark here for further testing.
Thanks for doing this.
> For boot time I dont see significant changes.
>
> -Robert
>
>
> Boot times:
>
> pfn_valid_within():
> [ 25.929134]
> [ 25.548830]
> [ 25.503225]
>
> early_pfn_valid() v3:
> [ 25.773814]
> [ 25.548428]
> [ 25.765290]
>
>
> Kernel compile times (3 runs each):
>
> pfn_valid_within():
>
> real 6m4.088s
> user 372m57.607s
> sys 16m55.158s
>
> real 6m1.532s
> user 372m48.453s
> sys 16m50.370s
>
> real 6m4.061s
> user 373m18.753s
> sys 16m57.027s
Did you reboot the machine between each build here, or only when changing
kernel? If the latter, do you see variations in kernel build time by simply
rebooting the same Image?
Will
^ permalink raw reply
* [PATCH] arm64: assembler: make adr_l work in modules under KASLR
From: Catalin Marinas @ 2017-01-12 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112154420.GE13843@arm.com>
On Thu, Jan 12, 2017 at 03:44:20PM +0000, Will Deacon wrote:
> On Wed, Jan 11, 2017 at 02:54:53PM +0000, Ard Biesheuvel wrote:
> > When CONFIG_RANDOMIZE_MODULE_REGION_FULL=y, the offset between loaded
> > modules and the core kernel may exceed 4 GB, putting symbols exported
> > by the core kernel out of the reach of the ordinary adrp/add instruction
> > pairs used to generate relative symbol references. So make the adr_l
> > macro emit a movz/movk sequence instead when executing in module context.
> >
> > While at it, remove the pointless special case for the stack pointer.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> > arch/arm64/include/asm/assembler.h | 36 +++++++++++++++-----
> > 1 file changed, 27 insertions(+), 9 deletions(-)
>
> Given that you need this for 4.11, I suggest Catalin takes it as a fix
> for 4.10 to avoid the crypto dependency.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
That's fine by me. Thanks for the ack.
--
Catalin
^ permalink raw reply
* [RFC 00/13] vITS save/restore
From: Eric Auger @ 2017-01-12 15:56 UTC (permalink / raw)
To: linux-arm-kernel
This series specifies and implements an API aimed at saving and restoring
the state of the in-kernel emulated ITS device.
The ITS is programmed through registers and tables. Those later tables
are allocated by the guest. Their base address is programmed in
registers or table entries before the ITS is enabled.
The ITS is free to use some of them to flush its internal caches. This
is likely to be used when entering low power state.
Therefore, for save/restore use case, it looks natural to use this
guest RAM allocated space to save the table related data. However,
currently,The ITS in-kernel emulated device does not use all of those
tables and for those it uses, it does not always sync them with its
cached data. Additional sync must happen for:
- the collection table
- the device table
- the per-device translation tables
- the LPI pending tables.
The LPI configration table and the command queues do not need extra
syncs.
So the bulk of the work in this series consists in the table
save/restore rather than register save/restore.
An alternative to flushing the tables into guest RAM could have been
to flush them into a separate user-space buffer. However the drawback
of this alternative is that the virtualizer would allocate dedicated
buffers to store the data that should normally be laid out in guest
RAM. It would also be obliged to re-compute their size from
register/table content.
So saving the tables in guest RAM better fit the ITS programming
model and optimizes the memory usage. The drawback of this solution
is it brings additional challenges at user-space level to make sure
the guest RAM is frozen after table sync.
The code is functional while saving/restoring a guest using
virtio-net-pci. However many points deserve additional tests.
I share the series at that stage to get the documentation reviewed
and main principles discussed.
The series applies on top of Vijaya's series:
- [PATCH v10 0/8] arm/arm64: vgic: Implement API for vGICv3 live
migration
http://www.spinics.net/lists/arm-kernel/msg546383.html
Best Regards
Eric
Git: complete series available at
https://github.com/eauger/linux/tree/v4.10-rc3-its-mig-rfc-v1
* Testing:
- on Cavium using a virtio-net-pci guest and virsh save/restore
commands
Eric Auger (13):
KVM: arm/arm64: Add vITS save/restore API documentation
arm/arm64: vgic: turn vgic_find_mmio_region into public
KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_REGS group
KVM: arm64: ITS: Implement vgic_its_has_attr_regs and attr_regs_access
KVM: arm64: ITS: Implement vgic_mmio_uaccess_write_its_creadr
KVM: arm64: ITS: Expose ITT_Entry_Size in GITS_TYPER
KVM: arm64: ITS: Change entry_size and indirect bit in BASER
KVM: arm64: ITS: On MAPD interpret and store itt_addr and size
KVM: arm64: ITS: KVM_DEV_ARM_VGIC_GRP_ITS_TABLES group
KVM: arm64: ITS: vgic_its_alloc_itte/device
KVM: arm64: ITS: Collection table save/restore
KVM: arm64: ITS: Device and translation table flush
KVM: arm64: ITS: Pending table save/restore
Documentation/virtual/kvm/devices/arm-vgic-its.txt | 70 +++
arch/arm/include/uapi/asm/kvm.h | 2 +
arch/arm64/include/uapi/asm/kvm.h | 2 +
include/kvm/arm_vgic.h | 3 +
include/linux/irqchip/arm-gic-v3.h | 1 +
virt/kvm/arm/vgic/vgic-its.c | 655 +++++++++++++++++++--
virt/kvm/arm/vgic/vgic-mmio.c | 3 +-
virt/kvm/arm/vgic/vgic-mmio.h | 14 +-
8 files changed, 705 insertions(+), 45 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Catalin Marinas @ 2017-01-12 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <278a45c0-bd49-b8a2-63ae-80ad851bab9b@arm.com>
On Wed, Jan 11, 2017 at 06:22:08PM +0000, Marc Zyngier wrote:
> On 11/01/17 18:06, Catalin Marinas wrote:
> > On Wed, Jan 11, 2017 at 09:41:15AM -0500, Christopher Covington wrote:
> >> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> >> index 32682be..9ee46df 100644
> >> --- a/arch/arm64/mm/proc.S
> >> +++ b/arch/arm64/mm/proc.S
> >> @@ -23,6 +23,7 @@
> >> #include <asm/assembler.h>
> >> #include <asm/asm-offsets.h>
> >> #include <asm/hwcap.h>
> >> +#include <asm/mmu_context.h>
> >> #include <asm/pgtable.h>
> >> #include <asm/pgtable-hwdef.h>
> >> #include <asm/cpufeature.h>
> >> @@ -140,6 +141,18 @@ ENDPROC(cpu_do_resume)
> >> ENTRY(cpu_do_switch_mm)
> >> mmid x1, x1 // get mm->context.id
> >> bfi x0, x1, #48, #16 // set the ASID
> >> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
> >> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
> >> + mrs x2, ttbr0_el1
> >> + mov x3, #FALKOR_RESERVED_ASID
> >> + bfi x2, x3, #48, #16 // reserved ASID + old BADDR
> >> + msr ttbr0_el1, x2
> >> + isb
> >> + bfi x2, x0, #0, #48 // reserved ASID + new BADDR
> >> + msr ttbr0_el1, x2
> >> + isb
> >> +alternative_else_nop_endif
> >> +#endif
> >> msr ttbr0_el1, x0 // set TTBR0
> >> isb
> >> post_ttbr0_update_workaround
> >
> > Please move the above hunk to a pre_ttbr0_update_workaround macro for
> > consistency with post_ttbr0_update_workaround.
>
> In which case (and also for consistency), should we add that pre_ttbr0
> macro to entry.S, just before __uaccess_ttbr0_enable? It may not be
> needed in the SW pan case, but it is probably worth entertaining the
> idea that there may be something to do there...
It may actually be needed in entry.S as well. With SW PAN, we move the
context switching from cpu_do_switch_mm to the kernel_exit macro when
returning to user. In this case we are switching from the reserved ASID
0 and reserved TTBR0_EL1 (pointing to a zeroed page) to the user's
TTBR0_EL1 and ASID. If the ASID switch isn't taken into account, we may
end up with new TLB entries being tagged with the reserved ASID. Apart
from a potential loss of protection with TTBR0 PAN, is there anything
else that could go wrong? Maybe a TLB conflict if we mix TLBs from
multiple address spaces tagged with the same reserved ASID.
If the above is an issue, we would need to patch
__uaccess_ttbr0_enable() as well, though I'm more inclined to make this
erratum not selectable when TTBR0 PAN is enabled.
--
Catalin
^ permalink raw reply
* [PATCH v2 7/7] uapi: export all headers under uapi directories
From: Nicolas Dichtel @ 2017-01-12 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109125638.GA15506@infradead.org>
Le 09/01/2017 ? 13:56, Christoph Hellwig a ?crit :
> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>> Regularly, when a new header is created in include/uapi/, the developer
>> forgets to add it in the corresponding Kbuild file. This error is usually
>> detected after the release is out.
>>
>> In fact, all headers under uapi directories should be exported, thus it's
>> useless to have an exhaustive list.
>>
>> After this patch, the following files, which were not exported, are now
>> exported (with make headers_install_all):
>
> ... snip ...
>
>> linux/genwqe/.install
>> linux/genwqe/..install.cmd
>> linux/cifs/.install
>> linux/cifs/..install.cmd
>
> I'm pretty sure these should not be exported!
>
Those files are created in every directory:
$ find usr/include/ -name '\.\.install.cmd' | wc -l
71
$ find usr/include/ -name '\.install' | wc -l
71
See also
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.headersinst#n32
Thank you,
Nicolas
^ permalink raw reply
* [PATCH] ARM: dts: NSP: Fix DT ranges error
From: Jon Mason @ 2017-01-12 15:50 UTC (permalink / raw)
To: linux-arm-kernel
The range size for axi is 0x2 bytes too small, as the QSPI needs
0x11c408 + 0x004 (which is 0x0011c40c, not 0x0011c40a). No errors have
been observed with this shortcoming, but fixing it for correctness.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 6c58c78..832795b 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -160,7 +160,7 @@
axi {
compatible = "simple-bus";
- ranges = <0x00000000 0x18000000 0x0011c40a>;
+ ranges = <0x00000000 0x18000000 0x0011c40c>;
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Catalin Marinas @ 2017-01-12 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111184052.GE29247@leverpostej>
On Wed, Jan 11, 2017 at 06:40:52PM +0000, Mark Rutland wrote:
> On Wed, Jan 11, 2017 at 06:22:08PM +0000, Marc Zyngier wrote:
> > On 11/01/17 18:06, Catalin Marinas wrote:
> > > On Wed, Jan 11, 2017 at 09:41:15AM -0500, Christopher Covington wrote:
> > >> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> > >> index 32682be..9ee46df 100644
> > >> --- a/arch/arm64/mm/proc.S
> > >> +++ b/arch/arm64/mm/proc.S
> > >> @@ -23,6 +23,7 @@
> > >> #include <asm/assembler.h>
> > >> #include <asm/asm-offsets.h>
> > >> #include <asm/hwcap.h>
> > >> +#include <asm/mmu_context.h>
> > >> #include <asm/pgtable.h>
> > >> #include <asm/pgtable-hwdef.h>
> > >> #include <asm/cpufeature.h>
> > >> @@ -140,6 +141,18 @@ ENDPROC(cpu_do_resume)
> > >> ENTRY(cpu_do_switch_mm)
> > >> mmid x1, x1 // get mm->context.id
> > >> bfi x0, x1, #48, #16 // set the ASID
> > >> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
> > >> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
> > >> + mrs x2, ttbr0_el1
> > >> + mov x3, #FALKOR_RESERVED_ASID
> > >> + bfi x2, x3, #48, #16 // reserved ASID + old BADDR
> > >> + msr ttbr0_el1, x2
> > >> + isb
> > >> + bfi x2, x0, #0, #48 // reserved ASID + new BADDR
> > >> + msr ttbr0_el1, x2
> > >> + isb
> > >> +alternative_else_nop_endif
> > >> +#endif
> > >> msr ttbr0_el1, x0 // set TTBR0
> > >> isb
> > >> post_ttbr0_update_workaround
> > >
> > > Please move the above hunk to a pre_ttbr0_update_workaround macro for
> > > consistency with post_ttbr0_update_workaround.
> >
> > In which case (and also for consistency), should we add that pre_ttbr0
> > macro to entry.S, just before __uaccess_ttbr0_enable? It may not be
> > needed in the SW pan case, but it is probably worth entertaining the
> > idea that there may be something to do there...
>
> Likewise, I beleive we may need to modify cpu_set_reserved_ttbr0().
This may be fine if my assumptions about this erratum are correct. In
the cpu_set_reserved_ttbr0() case we set TTBR0_EL1 to a table without
any entries, so no new entries could be tagged with the old ASID.
--
Catalin
^ permalink raw reply
* [PATCH] bus: qcom_ebi2: default y if ARCH_QCOM
From: Andy Gross @ 2017-01-12 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112070855.22214-1-linus.walleij@linaro.org>
On Thu, Jan 12, 2017 at 08:08:55AM +0100, Linus Walleij wrote:
> Since we want this external bus to be available on multi_v7 builds,
> set to default ARCH_QCOM so we get it selected whenever QCOM is
> enabled.
>
> Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Andy: I guess you could queue this to ARM SoC, they seem so manage
> drivers/bus from there.
No worries. I'll add this to my list.
Thanks,
Andy
^ permalink raw reply
* [PATCH] arm64: assembler: make adr_l work in modules under KASLR
From: Will Deacon @ 2017-01-12 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484146493-18460-1-git-send-email-ard.biesheuvel@linaro.org>
On Wed, Jan 11, 2017 at 02:54:53PM +0000, Ard Biesheuvel wrote:
> When CONFIG_RANDOMIZE_MODULE_REGION_FULL=y, the offset between loaded
> modules and the core kernel may exceed 4 GB, putting symbols exported
> by the core kernel out of the reach of the ordinary adrp/add instruction
> pairs used to generate relative symbol references. So make the adr_l
> macro emit a movz/movk sequence instead when executing in module context.
>
> While at it, remove the pointless special case for the stack pointer.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/include/asm/assembler.h | 36 +++++++++++++++-----
> 1 file changed, 27 insertions(+), 9 deletions(-)
Given that you need this for 4.11, I suggest Catalin takes it as a fix
for 4.10 to avoid the crypto dependency.
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH v29 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Mark Rutland @ 2017-01-12 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228043734.27535-1-takahiro.akashi@linaro.org>
Hi,
On Wed, Dec 28, 2016 at 01:37:34PM +0900, AKASHI Takahiro wrote:
> From: James Morse <james.morse@arm.com>
>
> Add documentation for
> linux,crashkernel-base and crashkernel-size,
> linux,usable-memory-range
> linux,elfcorehdr
> used by arm64 kdump to decribe the kdump reserved area, and
> the elfcorehdr's location within it.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> [takahiro.akashi at linaro.org: added "linux,crashkernel-base" and "-size" ]
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> ---
> Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> index 6ae9d82d4c37..7b115165e9ec 100644
> --- a/Documentation/devicetree/bindings/chosen.txt
> +++ b/Documentation/devicetree/bindings/chosen.txt
> @@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on
> book3e) by some versions of kexec-tools to tell the new kernel that it
> is being booted by kexec, as the booting environment may differ (e.g.
> a different secondary CPU release mechanism)
> +
> +linux,crashkernel-base
> +linux,crashkernel-size
> +----------------------
> +
> +These properties (currently used on PowerPC and arm64) indicates
> +the base address and the size, respectively, of the reserved memory
> +range for crash dump kernel.
>From this description, it's not clear to me what the (expected)
consumers of this property are, nor what is expected to provide it.
In previous rounds of review, I had assumed that this was used to
describe a preference to the first kernel as to what region of memory
should be used for a subsequent kdump kernel. Looking around, I'm not
sure if I was correct in that assessment.
I see that arch/powerpc seems to consume this property to configure
crashk_res, but it also rewrites it based on crashk_res, presumably for
the benefit of userspace. It's not clear to me how on powerpc the kdump
kernel knows its memory range -- is more DT modification done in the
kernel and/or userspace?
I disagree with modifying this property to expose it to userspace. For
arm64 we should either ensure that /proc/iomem is consistently usable
(and have userspace consistently use it), or we should expose a new file
specifically to expose this information.
Further, I do not think we need this property. It makes more sense to me
for the preference of a a region to be described to the *first* kernel
using the command line consistently.
So I think we should drop this property, and not use it on arm64. Please
document this as powerpc only.
> +e.g.
> +
> +/ {
> + chosen {
> + linux,crashkernel-base = <0x9 0xf0000000>;
> + linux,crashkernel-size = <0x0 0x10000000>;
> + };
> +};
> +
> +linux,usable-memory-range
> +-------------------------
> +
> +This property (currently used only on arm64) holds the memory range,
> +the base address and the size, which can be used as system ram on
> +the *current* kernel. Note that, if this property is present, any memory
> +regions under "memory" nodes in DT blob or ones marked as "conventional
> +memory" in EFI memory map should be ignored.
Could you please replace this with:
This property (arm64 only) holds a base address and size, describing a
limited region in which memory may be considered available for use by
the kernel. Memory outside of this range is not available for use.
This property describes a limitation: memory within this range is only
valid when also described through another mechanism that the kernel
would otherwise use to determine available memory (e.g. memory nodes
or the EFI memory map). Valid memory may be sparse within the range.
To clarify why we need this, given by above comments w.r.r. the
linux,crashkernel-* properties:
* It preserves all the original memory map information (e.g. memory
nodes and/or EFI memory map)
* It works consistently, regardless of how the kdump kernel would
otherwise determine which memory to use (memory nodes, EFI, etc).
* It will be simply and reliable for an in-kernel purgatory to insert,
if we need a kexec_file_load()-based kdump (e.g. without requiring
memory map rewrites, and avoiding clashes with command line
parameters). For a first kernel, this is not as big a concern.
> +linux,elfcorehdr
> +----------------
> +
> +This property (currently used only on arm64) holds the memory range,
> +the address and the size, of the elf core header which mainly describes
> +the panicked kernel's memory layout as PT_LOAD segments of elf format.
> +e.g.
> +
> +/ {
> + chosen {
> + linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>;
> + };
> +};
This property looks fine to me.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm64: Add support for DMA_ATTR_SKIP_CPU_SYNC attribute to swiotlb
From: Will Deacon @ 2017-01-12 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484129477-24121-1-git-send-email-geert+renesas@glider.be>
On Wed, Jan 11, 2017 at 11:11:17AM +0100, Geert Uytterhoeven wrote:
> From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>
> This patch adds support for DMA_ATTR_SKIP_CPU_SYNC attribute for
> dma_{un}map_{page,sg} functions family to swiotlb.
>
> DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
> the CPU cache for the given buffer assuming that it has been already
> transferred to 'device' domain.
>
> Ported from IOMMU .{un}map_{sg,page} ops.
>
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v2:
> - Add Acked-by.
>
> Support for DMA_ATTR_SKIP_CPU_SYNC was included when porting the IOMMU
> ops from arm to arm64 in commit 13b8629f651164d7 ("arm64: Add IOMMU
> dma_ops").
>
> Presumably it was an oversight that the existing swiotlb based
> implementation didn't have support for DMA_ATTR_SKIP_CPU_SYNC yet?
> ---
> arch/arm64/mm/dma-mapping.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
Thanks. Applied for 4.11, with Robin's Reviewed-by.
Will
^ permalink raw reply
* [PATCH] arm64: errata: Provide macro for major and minor cpu revisions
From: Will Deacon @ 2017-01-12 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111121143.9586-1-rrichter@cavium.com>
On Wed, Jan 11, 2017 at 01:11:42PM +0100, Robert Richter wrote:
> Definition of cpu ranges are hard to read if the cpu variant is not
> zero. Provide MIDR_CPU_FULL_REV() macro to describe the full hardware
> revision of a cpu including variant and (minor) revision.
>
> Signed-off-by: Robert Richter <rrichter@cavium.com>
> ---
> arch/arm64/include/asm/cputype.h | 3 +++
> arch/arm64/kernel/cpu_errata.c | 15 +++++++++------
> arch/arm64/kernel/cpufeature.c | 8 +++-----
> 3 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> index 26a68ddb11c1..983e59cbdd54 100644
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -56,6 +56,9 @@
> (0xf << MIDR_ARCHITECTURE_SHIFT) | \
> ((partnum) << MIDR_PARTNUM_SHIFT))
>
> +#define MIDR_CPU_FULL_REV(var, rev) \
> + (((var) << MIDR_VARIANT_SHIFT) | (rev))
Minor nit, but could you rename this to MIDR_CPU_VAR_REV instead please?
The revision field *is* the bottom 4 bits, so "full" rev doesn't really
make a lot of sense.
If you repost with that change, I'll pick it up for 4.11.
Thanks,
Will
^ 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