* [PATCH v6 08/18] iommu/vt-d: Implement reserved region get/put callbacks
From: Auger Eric @ 2017-01-06 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106110131.GM17255@8bytes.org>
Hi Joerg,
On 06/01/2017 12:01, Joerg Roedel wrote:
> On Thu, Jan 05, 2017 at 07:04:36PM +0000, Eric Auger wrote:
>> +static void intel_iommu_get_resv_regions(struct device *device,
>> + struct list_head *head)
>> +{
>> + struct iommu_resv_region *reg;
>> +
>> + reg = iommu_alloc_resv_region(IOAPIC_RANGE_START,
>> + IOAPIC_RANGE_END - IOAPIC_RANGE_START + 1,
>> + 0, IOMMU_RESV_NOMAP);
>> + if (!reg)
>> + return;
>> + list_add_tail(®->list, head);
>> +}
>
> That is different from what AMD does, can you also report the RMRR
> regions for the device here (as direct-map regions)?
if I return RMRR regions as direct mapped regions,
iommu_group_create_direct_mappings will perform the 1-1 mapping.
I am not familiar with the intel-iommu code but I guess this job
currently is done in the intel driver:
iommu_prepare_rmrr_dev -> iommu_prepare_identity_map
->domain_prepare_identity_map -> iommu_domain_identity_map?
What is your feeling?
Thanks
Eric
>
>
>
> Joerg
>
^ permalink raw reply
* [PATCH v6 07/18] iommu: Implement reserved_regions iommu-group sysfs file
From: Auger Eric @ 2017-01-06 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106110039.GL17255@8bytes.org>
Hi Joerg,
On 06/01/2017 12:00, Joerg Roedel wrote:
> On Thu, Jan 05, 2017 at 07:04:35PM +0000, Eric Auger wrote:
>> + list_for_each_entry_safe(region, next, &group_resv_regions, list) {
>> + str += sprintf(str, "0x%016llx 0x%016llx\n",
>> + (long long int)region->start,
>> + (long long int)(region->start +
>> + region->length - 1));
>> + kfree(region);
>> + }
>
> I think it also makes sense to report the type of the reserved region.
What is the best practice in that case? Shall we put the type enum
values as strings such as:
- direct
- nomap
- msi
and document that in Documentation/ABI/testing/sysfs-kernel-iommu_groups
Thanks
Eric
>
>
>
> Joerg
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v6 01/18] iommu/dma: Allow MSI-only cookies
From: Auger Eric @ 2017-01-06 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106105945.GK17255@8bytes.org>
On 06/01/2017 11:59, Joerg Roedel wrote:
> On Thu, Jan 05, 2017 at 07:04:29PM +0000, Eric Auger wrote:
>> struct iommu_dma_cookie {
>> - struct iova_domain iovad;
>> - struct list_head msi_page_list;
>> - spinlock_t msi_lock;
>> + union {
>> + struct iova_domain iovad;
>> + dma_addr_t msi_iova;
>> + };
>> + struct list_head msi_page_list;
>> + spinlock_t msi_lock;
>> + enum iommu_dma_cookie_type type;
>
> Please move the type to the beginning of the struct and add a comment
> how the type relates to the union.
Sure
Thank you for the review.
Best regards
Eric
>
>
>
> Joerg
>
^ permalink raw reply
* [RFT PATCH] crypto: arm/aes - replace scalar AES cipher
From: Ard Biesheuvel @ 2017-01-06 11:53 UTC (permalink / raw)
To: linux-arm-kernel
This replaces the scalar AES cipher that originates in the OpenSSL project
with a new implementation that is ~15% (*) faster (on modern cores), and
reuses the lookup tables and the key schedule generation routines from the
generic C implementation (which is usually compiled in anyway due to
networking and other subsystems depending on it).
Note that the bit sliced NEON code for AES still depends on the scalar cipher
that this patch replaces, so it is not removed entirely yet.
* On Cortex-A57, the performance increases from 17.0 to 14.9 cycles per byte
for 128-bit keys.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
It makes sense to test this on a variety of cores before deciding whether
to merge it or not. Test results welcome. (insmod tcrypt.ko mode=200 sec=1)
arch/arm/crypto/Kconfig | 20 +--
arch/arm/crypto/Makefile | 4 +-
arch/arm/crypto/aes-cipher-core.S | 169 ++++++++++++++++++++
arch/arm/crypto/aes-cipher-glue.c | 69 ++++++++
arch/arm/crypto/aes_glue.c | 98 ------------
5 files changed, 241 insertions(+), 119 deletions(-)
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 2f3339f015d3..f1de658c3c8f 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -62,33 +62,15 @@ config CRYPTO_SHA512_ARM
using optimized ARM assembler and NEON, when available.
config CRYPTO_AES_ARM
- tristate "AES cipher algorithms (ARM-asm)"
- depends on ARM
+ tristate "Scalar AES cipher for ARM"
select CRYPTO_ALGAPI
select CRYPTO_AES
help
Use optimized AES assembler routines for ARM platforms.
- AES cipher algorithms (FIPS-197). AES uses the Rijndael
- algorithm.
-
- Rijndael appears to be consistently a very good performer in
- both hardware and software across a wide range of computing
- environments regardless of its use in feedback or non-feedback
- modes. Its key setup time is excellent, and its key agility is
- good. Rijndael's very low memory requirements make it very well
- suited for restricted-space environments, in which it also
- demonstrates excellent performance. Rijndael's operations are
- among the easiest to defend against power and timing attacks.
-
- The AES specifies three key sizes: 128, 192 and 256 bits
-
- See <http://csrc.nist.gov/encryption/aes/> for more information.
-
config CRYPTO_AES_ARM_BS
tristate "Bit sliced AES using NEON instructions"
depends on KERNEL_MODE_NEON
- select CRYPTO_AES_ARM
select CRYPTO_BLKCIPHER
select CRYPTO_SIMD
help
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index 8d74e55eacd4..8f5de2db701c 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -27,8 +27,8 @@ $(warning $(ce-obj-y) $(ce-obj-m))
endif
endif
-aes-arm-y := aes-armv4.o aes_glue.o
-aes-arm-bs-y := aesbs-core.o aesbs-glue.o
+aes-arm-y := aes-cipher-core.o aes-cipher-glue.o
+aes-arm-bs-y := aes-armv4.o aesbs-core.o aesbs-glue.o
sha1-arm-y := sha1-armv4-large.o sha1_glue.o
sha1-arm-neon-y := sha1-armv7-neon.o sha1_neon_glue.o
sha256-arm-neon-$(CONFIG_KERNEL_MODE_NEON) := sha256_neon_glue.o
diff --git a/arch/arm/crypto/aes-cipher-core.S b/arch/arm/crypto/aes-cipher-core.S
new file mode 100644
index 000000000000..8d4a15364d43
--- /dev/null
+++ b/arch/arm/crypto/aes-cipher-core.S
@@ -0,0 +1,169 @@
+/*
+ * Scalar AES core transform
+ *
+ * Copyright (C) 2017 Linaro Ltd <ard.biesheuvel@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+
+ .text
+ .align 5
+
+ rk .req r0
+ rounds .req r1
+ in .req r2
+ out .req r3
+ tt .req ip
+
+ t0 .req lr
+ t1 .req r2
+ t2 .req r3
+
+ .macro __select, out, in, idx
+ .if __LINUX_ARM_ARCH__ < 7
+ and \out, \in, #0xff << (8 * \idx)
+ .else
+ ubfx \out, \in, #(8 * \idx), #8
+ .endif
+ .endm
+
+ .macro __load, out, in, idx
+ .if __LINUX_ARM_ARCH__ < 7 && \idx > 0
+ ldr \out, [tt, \in, lsr #(8 * \idx) - 2]
+ .else
+ ldr \out, [tt, \in, lsl #2]
+ .endif
+ .endm
+
+ .macro __hround, out0, out1, in0, in1, in2, in3, t3, t4, enc
+ __select \out0, \in0, 0
+ __select t0, \in1, 1
+ __load \out0, \out0, 0
+ __load t0, t0, 1
+
+ .if \enc
+ __select \out1, \in1, 0
+ __select t1, \in2, 1
+ .else
+ __select \out1, \in3, 0
+ __select t1, \in0, 1
+ .endif
+ __load \out1, \out1, 0
+ __select t2, \in2, 2
+ __load t1, t1, 1
+ __load t2, t2, 2
+
+ eor \out0, \out0, t0, ror #24
+
+ __select t0, \in3, 3
+ .if \enc
+ __select \t3, \in3, 2
+ __select \t4, \in0, 3
+ .else
+ __select \t3, \in1, 2
+ __select \t4, \in2, 3
+ .endif
+ __load \t3, \t3, 2
+ __load t0, t0, 3
+ __load \t4, \t4, 3
+
+ eor \out1, \out1, t1, ror #24
+ eor \out0, \out0, t2, ror #16
+ ldm rk!, {t1, t2}
+ eor \out1, \out1, \t3, ror #16
+ eor \out0, \out0, t0, ror #8
+ eor \out1, \out1, \t4, ror #8
+ eor \out0, \out0, t1
+ eor \out1, \out1, t2
+ .endm
+
+ .macro fround, out0, out1, out2, out3, in0, in1, in2, in3
+ __hround \out0, \out1, \in0, \in1, \in2, \in3, \out2, \out3, 1
+ __hround \out2, \out3, \in2, \in3, \in0, \in1, \in1, \in2, 1
+ .endm
+
+ .macro iround, out0, out1, out2, out3, in0, in1, in2, in3
+ __hround \out0, \out1, \in0, \in3, \in2, \in1, \out2, \out3, 0
+ __hround \out2, \out3, \in2, \in1, \in0, \in3, \in1, \in0, 0
+ .endm
+
+ .macro __rev, out, in
+ .if __LINUX_ARM_ARCH__ < 7
+ lsl t0, \in, #24
+ and t1, \in, #0xff00
+ and t2, \in, #0xff0000
+ orr \out, t0, \in, lsr #24
+ orr \out, \out, t1, lsl #8
+ orr \out, \out, t2, lsr #8
+ .else
+ rev \out, \in
+ .endif
+ .endm
+
+ .macro do_crypt, round, ttab, ltab
+ push {r3-r11, lr}
+
+ ldr r4, [in]
+ ldr r5, [in, #4]
+ ldr r6, [in, #8]
+ ldr r7, [in, #12]
+
+ ldm rk!, {r8, r9, r10, r11}
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ __rev r4, r4
+ __rev r5, r5
+ __rev r6, r6
+ __rev r7, r7
+#endif
+
+ eor r4, r4, r8
+ eor r5, r5, r9
+ eor r6, r6, r10
+ eor r7, r7, r11
+
+ ldr tt, =\ttab
+
+ tst rounds, #2
+ bne 1f
+
+0: \round r8, r9, r10, r11, r4, r5, r6, r7
+ \round r4, r5, r6, r7, r8, r9, r10, r11
+
+1: subs rounds, rounds, #4
+ \round r8, r9, r10, r11, r4, r5, r6, r7
+ ldrls tt, =\ltab
+ \round r4, r5, r6, r7, r8, r9, r10, r11
+ bhi 0b
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+ __rev r4, r4
+ __rev r5, r5
+ __rev r6, r6
+ __rev r7, r7
+#endif
+
+ ldr out, [sp]
+
+ str r4, [out]
+ str r5, [out, #4]
+ str r6, [out, #8]
+ str r7, [out, #12]
+
+ pop {r3-r11, pc}
+
+ .align 3
+ .ltorg
+ .endm
+
+ENTRY(__aes_arm_encrypt)
+ do_crypt fround, crypto_ft_tab, crypto_fl_tab
+ENDPROC(__aes_arm_encrypt)
+
+ENTRY(__aes_arm_decrypt)
+ do_crypt iround, crypto_it_tab, crypto_il_tab
+ENDPROC(__aes_arm_decrypt)
diff --git a/arch/arm/crypto/aes-cipher-glue.c b/arch/arm/crypto/aes-cipher-glue.c
new file mode 100644
index 000000000000..19545237112a
--- /dev/null
+++ b/arch/arm/crypto/aes-cipher-glue.c
@@ -0,0 +1,69 @@
+/*
+ * Scalar AES core transform
+ *
+ * Copyright (C) 2017 Linaro Ltd <ard.biesheuvel@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <crypto/aes.h>
+#include <linux/crypto.h>
+#include <linux/module.h>
+
+asmlinkage void __aes_arm_encrypt(u32 *rk, int rounds, const u8 *in, u8 *out);
+EXPORT_SYMBOL(__aes_arm_encrypt);
+
+asmlinkage void __aes_arm_decrypt(u32 *rk, int rounds, const u8 *in, u8 *out);
+EXPORT_SYMBOL(__aes_arm_decrypt);
+
+static void aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+ struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
+ int rounds = 6 + ctx->key_length / 4;
+
+ __aes_arm_encrypt(ctx->key_enc, rounds, in, out);
+}
+
+static void aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+ struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
+ int rounds = 6 + ctx->key_length / 4;
+
+ __aes_arm_decrypt(ctx->key_dec, rounds, in, out);
+}
+
+static struct crypto_alg aes_alg = {
+ .cra_name = "aes",
+ .cra_driver_name = "aes-arm",
+ .cra_priority = 200,
+ .cra_flags = CRYPTO_ALG_TYPE_CIPHER,
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct crypto_aes_ctx),
+ .cra_module = THIS_MODULE,
+
+ .cra_cipher.cia_min_keysize = AES_MIN_KEY_SIZE,
+ .cra_cipher.cia_max_keysize = AES_MAX_KEY_SIZE,
+ .cra_cipher.cia_setkey = crypto_aes_set_key,
+ .cra_cipher.cia_encrypt = aes_encrypt,
+ .cra_cipher.cia_decrypt = aes_decrypt
+};
+
+static int __init aes_init(void)
+{
+ return crypto_register_alg(&aes_alg);
+}
+
+static void __exit aes_fini(void)
+{
+ crypto_unregister_alg(&aes_alg);
+}
+
+module_init(aes_init);
+module_exit(aes_fini);
+
+MODULE_DESCRIPTION("Scalar AES cipher for ARM");
+MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS_CRYPTO("aes");
diff --git a/arch/arm/crypto/aes_glue.c b/arch/arm/crypto/aes_glue.c
deleted file mode 100644
index 0409b8f89782..000000000000
--- a/arch/arm/crypto/aes_glue.c
+++ /dev/null
@@ -1,98 +0,0 @@
-/*
- * Glue Code for the asm optimized version of the AES Cipher Algorithm
- */
-
-#include <linux/module.h>
-#include <linux/crypto.h>
-#include <crypto/aes.h>
-
-#include "aes_glue.h"
-
-EXPORT_SYMBOL(AES_encrypt);
-EXPORT_SYMBOL(AES_decrypt);
-EXPORT_SYMBOL(private_AES_set_encrypt_key);
-EXPORT_SYMBOL(private_AES_set_decrypt_key);
-
-static void aes_encrypt(struct crypto_tfm *tfm, u8 *dst, const u8 *src)
-{
- struct AES_CTX *ctx = crypto_tfm_ctx(tfm);
- AES_encrypt(src, dst, &ctx->enc_key);
-}
-
-static void aes_decrypt(struct crypto_tfm *tfm, u8 *dst, const u8 *src)
-{
- struct AES_CTX *ctx = crypto_tfm_ctx(tfm);
- AES_decrypt(src, dst, &ctx->dec_key);
-}
-
-static int aes_set_key(struct crypto_tfm *tfm, const u8 *in_key,
- unsigned int key_len)
-{
- struct AES_CTX *ctx = crypto_tfm_ctx(tfm);
-
- switch (key_len) {
- case AES_KEYSIZE_128:
- key_len = 128;
- break;
- case AES_KEYSIZE_192:
- key_len = 192;
- break;
- case AES_KEYSIZE_256:
- key_len = 256;
- break;
- default:
- tfm->crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
- return -EINVAL;
- }
-
- if (private_AES_set_encrypt_key(in_key, key_len, &ctx->enc_key) == -1) {
- tfm->crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
- return -EINVAL;
- }
- /* private_AES_set_decrypt_key expects an encryption key as input */
- ctx->dec_key = ctx->enc_key;
- if (private_AES_set_decrypt_key(in_key, key_len, &ctx->dec_key) == -1) {
- tfm->crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
- return -EINVAL;
- }
- return 0;
-}
-
-static struct crypto_alg aes_alg = {
- .cra_name = "aes",
- .cra_driver_name = "aes-asm",
- .cra_priority = 200,
- .cra_flags = CRYPTO_ALG_TYPE_CIPHER,
- .cra_blocksize = AES_BLOCK_SIZE,
- .cra_ctxsize = sizeof(struct AES_CTX),
- .cra_module = THIS_MODULE,
- .cra_list = LIST_HEAD_INIT(aes_alg.cra_list),
- .cra_u = {
- .cipher = {
- .cia_min_keysize = AES_MIN_KEY_SIZE,
- .cia_max_keysize = AES_MAX_KEY_SIZE,
- .cia_setkey = aes_set_key,
- .cia_encrypt = aes_encrypt,
- .cia_decrypt = aes_decrypt
- }
- }
-};
-
-static int __init aes_init(void)
-{
- return crypto_register_alg(&aes_alg);
-}
-
-static void __exit aes_fini(void)
-{
- crypto_unregister_alg(&aes_alg);
-}
-
-module_init(aes_init);
-module_exit(aes_fini);
-
-MODULE_DESCRIPTION("Rijndael (AES) Cipher Algorithm (ASM)");
-MODULE_LICENSE("GPL");
-MODULE_ALIAS_CRYPTO("aes");
-MODULE_ALIAS_CRYPTO("aes-asm");
-MODULE_AUTHOR("David McCullough <ucdevel@gmail.com>");
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
From: Sudeep Holla @ 2017-01-06 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9f508097-f605-ebd8-20af-c3e798c6fdcc@poczta.onet.pl>
Hi Micha?,
On 05/01/17 19:04, Micha? Zegan wrote:
> Hello.
>
> The patch causes cpufreq module (scpi-cpufreq) not to detect cpufreq, so
> it actually works, but...
> Loading the module causes few errors because of not found frequencies or
> something, then it is all okay. However after loading scpi-cpufreq you
> cannot actually power the cpu off and on. You will power it off
> successfully, but when trying to power it on, the cpufreq driver will
> error out,
Yes I had noticed this in past, this needs to be fixed. I had a patch
and seems like it slipped through the cracks. I will fins and post it.
> and then after it happens, the cpu that was trying to go
> online will be offline again, and that is a little... unfortunate. The
IIUC, you mean the cpufreq drive spits error on every hotplug event ?
If so yes, otherwise I think I didn't understand you concern above.
> question is, and I cannot really test that: will the module actually
> autoload after this change?
>
It should work, I had tested this in past.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Russell King - ARM Linux @ 2017-01-06 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGm1_kvZ4dQrJ89qYU5wLGU1NR=j9xyWUm2mgYtq3F1+bo1OCg@mail.gmail.com>
On Fri, Jan 06, 2017 at 06:42:24AM +0100, Yegor Yefremov wrote:
> On Fri, Jan 6, 2017 at 12:25 AM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > Another concern with this patch is that the existing phylib "set_eee"
> > code is horribly buggy - it just translates the modes from userspace
> > into the register value and writes them directly to the register with
> > no validation. So it's possible to set modes in the register that the
> > hardware doesn't support, and have them advertised to the link partner.
> >
> > I have a patch which fixes that, restricting (as we do elsewhere) the
> > advert according to the EEE supported capabilities retrieved from the
> > PCS - maybe the problem here is that the PCS doesn't support support
> > EEE in 1000baseT mode?
> >
> > Out of interest, which PHY is used on this platform?
> >
> > On the SolidRun boards, they're using AR8035, and have suffered this
> > occasional link drop problem. What has been found is that it seems to
> > be to do with the timing parameters, and it seemed to only be 1000bT
> > that was affected. I don't remember off hand exactly which or what
> > the change was they made to stabilise it though, but I can probabily
> > find out tomorrow.
>
> I have different boards with am335x and AR8035 and we had occasional
> link drop with both 100 and 1000 speeds.
AR8035 has "Smart EEE", which is a PHY specific thing... it's not
entirely 802.3 compliant as it doesn't involve the MAC.
The Smart EEE control registers are in the PCS MMD - some of this
is from people's memories:
- 0x805b is the TX wakeup timer. Lower 8 bits for 100base-Tx and
upper 8 bits for 1000base-T.
- 0x805c and 0x805d.
The LPI timer is 24 bit, with the lower 16 bits in 0x805c and the
upper 8 in 0x805d. 0x805d bit 8 appears to be the Smart EEE enable bit.
What was found was setting the 1000base-T wakeup timer to the same as
the 100base-Tx avoided the problems we were seeing, which was only
with 1000base-T. (Whether that's because 100base-Tx hasn't been as well
tested, I don't know.) SR ended up with 0x1717 in 0x805b.
I'd suggest playing around with that register to see if extending the
wakeup time has any beneficial effect.
Also, I suspect Smart EEE shouldn't be enabled if you have an EEE
capable MAC (in which case 0x805d bit 8 should be clear.) I think,
however, it defaults to enabled.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v4 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong values foe ldo23 and ldo25
From: Krzysztof Kozlowski @ 2017-01-06 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106114114.19321-2-andi.shyti@samsung.com>
On Fri, Jan 06, 2017 at 08:41:10PM +0900, Andi Shyti wrote:
> From: Chanwoo Choi <cw00.choi@samsung.com>
>
> This patch fixes wrong values assigned to ldo23 and ldo25 on both TM2 and TM2E.
>
> Fixes: 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 7 ++++---
> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 9 ---------
> 2 files changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 3b5215c40fcd..e8971f4a5977 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -504,9 +504,9 @@
> };
>
> ldo23_reg: LDO23 {
> - regulator-name = "CAM_SEN_CORE_1.2V_AP";
> + regulator-name = "CAM_SEN_CORE_1.05V_AP";
> regulator-min-microvolt = <1050000>;
> - regulator-max-microvolt = <1200000>;
> + regulator-max-microvolt = <1050000>;
> };
>
> ldo24_reg: LDO24 {
> @@ -516,9 +516,10 @@
> };
>
> ldo25_reg: LDO25 {
> - regulator-name = "CAM_SEN_A2.8V_AP";
> + regulator-name = "UNUSED_LDO25";
> regulator-min-microvolt = <2800000>;
> regulator-max-microvolt = <2800000>;
> + regulator-always-off;
No. I mentioned in last email that this property is wrong.
When resubmitting, please fix the subject prefix.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA
From: Will Deacon @ 2017-01-06 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105194944.GY4930@rric.localdomain>
On Thu, Jan 05, 2017 at 08:49:44PM +0100, Robert Richter wrote:
> On 05.01.17 13:22:00, Robert Richter wrote:
> > On 05.01.17 12:08:20, Will Deacon wrote:
> > > I really can't see how the fix causes a crash, and I couldn't reproduce
> > > it on any of my boards, nor could any of the Linaro folk afaik. Are you
> > > definitely running mainline with just these two patches from Ard?
> >
> > Yes, just both patches applied. Various other solutions were working.
>
> I have retested the same kernel (v4.9 based) as before and now it
> boots fine including rtc-efi device registration (it was crashing
> there):
>
> rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>
> There could be a difference in firmware and mem setup, though I also
> downgraded the firmware to test it, but can't reproduce it anymore. I
> could reliable trigger the crash the first time.
>
> FTR the oops.
Hmm, I just can't help but think you were accidentally running with
additional patches when you saw this oops previously. For example,
your log looks very similar to this one:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473666.html
but then again, these crashes probably often look alike.
Will
^ permalink raw reply
* [PATCH V8 1/9] iommu: add IOMMU_PRIV attribute
From: Sricharan @ 2017-01-06 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106110627.GO17255@8bytes.org>
Hi Joerg,
>-----Original Message-----
>From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Joerg Roedel
>Sent: Friday, January 06, 2017 4:36 PM
>To: Sricharan R <sricharan@codeaurora.org>
>Cc: mitchelh at codeaurora.org; pdaly at codeaurora.org; vinod.koul at intel.com; jgebben at codeaurora.org; will.deacon at arm.com;
>linux-kernel at vger.kernel.org; iommu at lists.linux-foundation.org; linux at armlinux.org.uk; jcrouse at codeaurora.org;
>dan.j.williams at intel.com; pratikp at codeaurora.org; tzeng at codeaurora.org; linux-arm-kernel at lists.infradead.org;
>robin.murphy at arm.com
>Subject: Re: [PATCH V8 1/9] iommu: add IOMMU_PRIV attribute
>
>On Mon, Jan 02, 2017 at 06:42:36PM +0530, Sricharan R wrote:
>> From: Mitchel Humpherys <mitchelh@codeaurora.org>
>>
>> Add the IOMMU_PRIV attribute, which is used to indicate privileged
>> mappings.
>>
>> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>> Tested-by: Robin Murphy <robin.murphy@arm.com>
>> Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
>> Acked-by: Will Deacon <will.deacon@arm.com>
>> ---
>> include/linux/iommu.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>> index 0ff5111..8c15ada 100644
>> --- a/include/linux/iommu.h
>> +++ b/include/linux/iommu.h
>> @@ -31,6 +31,7 @@
>> #define IOMMU_CACHE (1 << 2) /* DMA cache coherency */
>> #define IOMMU_NOEXEC (1 << 3)
>> #define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
>> +#define IOMMU_PRIV (1 << 5) /* privileged */
>
>Since this is a new generic global flag, can you please add a more
>verbose comment telling what a 'privileged' mapping is about in the
>iommu-case? We should have a clear defined semantic for this flag or we
>might end up with different meanings for it with different
>iommu-hardware.
This flag is to inform the iommu api to setup privileged mappings
for the caller which can be accessed only by the master running with
supervisor/privileged permissions and inaccessible to less privileged
execution levels.
i will repost this with comment added.
Regards,
Sricharan
^ permalink raw reply
* [PATCH v4 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong values foe ldo23 and ldo25
From: Javier Martinez Canillas @ 2017-01-06 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106114114.19321-2-andi.shyti@samsung.com>
Hello Andi,
On 01/06/2017 08:41 AM, Andi Shyti wrote:
> From: Chanwoo Choi <cw00.choi@samsung.com>
>
> This patch fixes wrong values assigned to ldo23 and ldo25 on both TM2 and TM2E.
>
> Fixes: 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
I don't have the schematics to check, but the patch looks good to me
besides the "regulator-always-off" property as Krzysztof mentioned.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v6 01/18] iommu/dma: Allow MSI-only cookies
From: Robin Murphy @ 2017-01-06 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b058a7f9-84bf-1d5c-1c24-24da251cc964@redhat.com>
On 06/01/17 11:46, Auger Eric wrote:
>
>
> On 06/01/2017 11:59, Joerg Roedel wrote:
>> On Thu, Jan 05, 2017 at 07:04:29PM +0000, Eric Auger wrote:
>>> struct iommu_dma_cookie {
>>> - struct iova_domain iovad;
>>> - struct list_head msi_page_list;
>>> - spinlock_t msi_lock;
>>> + union {
>>> + struct iova_domain iovad;
>>> + dma_addr_t msi_iova;
>>> + };
>>> + struct list_head msi_page_list;
>>> + spinlock_t msi_lock;
>>> + enum iommu_dma_cookie_type type;
>>
>> Please move the type to the beginning of the struct and add a comment
>> how the type relates to the union.
>
> Sure
>
> Thank you for the review.
FWIW I already had a cleaned up version of this patch, I just hadn't
mentioned it. I've pushed out an update with that change added too[1].
Robin.
[1]:http://linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/misc
>
> Best regards
>
> Eric
>>
>>
>>
>> Joerg
>>
^ permalink raw reply
* [PATCH v4 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Krzysztof Kozlowski @ 2017-01-06 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106114114.19321-3-andi.shyti@samsung.com>
On Fri, Jan 06, 2017 at 08:41:11PM +0900, Andi Shyti wrote:
> Currently tm2e dts includes tm2 but there are some differences
> between the two boards and tm2 has some properties that tm2e
> doesn't have.
>
> That's why it's important to keep the two dts files independent
> and put all the commonalities in a tm2-common.dtsi file.
>
> At the current status the only two differences between the two
> dts files (besides the board name) are ldo31 and ldo38.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> ...ynos5433-tm2.dts => exynos5433-tm2-common.dtsi} | 24 +-
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1153 +-------------------
> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 22 +-
> 3 files changed, 56 insertions(+), 1143 deletions(-)
> copy arch/arm64/boot/dts/exynos/{exynos5433-tm2.dts => exynos5433-tm2-common.dtsi} (98%)
> rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> similarity index 98%
> copy from arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> copy to arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index e8971f4a5977..c43f9a38adf6 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
Thanks. Now I can easily see the differences... and there are
differences! This is much, much easier to review then all previous
versions.
> @@ -3,8 +3,8 @@
> *
> * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> *
> - * Device tree source file for Samsung's TM2 board which is based on
> - * Samsung Exynos5433 SoC.
> + * Common device tree source file for Samsung's TM2 and TM2E boards
> + * which are based on Samsung Exynos5433 SoC.
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> @@ -322,7 +322,7 @@
> "s2mps13_bt";
> };
>
> - regulators {
> + regulators: regulators {
I understand that you added the label to create LDO31 and LDO38
regulators in specific DTS (I read your comments below). I do not have
strong opinion but I would prefer overriding in DTS instead of new addon, so:
1. without the label above,
2. with something like:
ldo31_reg: LDO31 {
/*
* LDO31 differs from target to target,
* its definition is in the .dts
*/
};
With such empty stub, one can still find all the regulator nodes in
common DTSI. I find it more readable. What do you think?
Best regards,
Krzysztof
> ldo1_reg: LDO1 {
> regulator-name = "VDD_ALIVE_0.9V_AP";
> regulator-min-microvolt = <900000>;
> @@ -552,11 +552,10 @@
> regulator-max-microvolt = <3300000>;
> };
>
> - ldo31_reg: LDO31 {
> - regulator-name = "TSP_VDD_1.85V_AP";
> - regulator-min-microvolt = <1850000>;
> - regulator-max-microvolt = <1850000>;
> - };
> + /*
> + * LDO31 differs from target to target,
> + * its definition is in the .dts
> + */
>
> ldo32_reg: LDO32 {
> regulator-name = "VTOUCH_1.8V_AP";
> @@ -595,11 +594,10 @@
> regulator-max-microvolt = <1800000>;
> };
>
> - ldo38_reg: LDO38 {
> - regulator-name = "VCC_3.0V_MOTOR_AP";
> - regulator-min-microvolt = <3000000>;
> - regulator-max-microvolt = <3000000>;
> - };
> + /*
> + * LDO38 differs from target to target,
> + * its definition is in the .dts
> + */
>
> ldo39_reg: LDO39 {
> regulator-name = "V_HRM_1.8V";
^ permalink raw reply
* [PATCH v2 4/7] x86: put msr-index.h in uapi
From: Borislav Petkov @ 2017-01-06 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483695839-18660-5-git-send-email-nicolas.dichtel@6wind.com>
On Fri, Jan 06, 2017 at 10:43:56AM +0100, Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.
It should rather not be exported - please remove it from
arch/x86/include/uapi/asm/Kbuild instead.
Thanks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH v4 3/5] input: Add support for the tm2 touchkey device driver
From: Krzysztof Kozlowski @ 2017-01-06 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106114114.19321-4-andi.shyti@samsung.com>
On Fri, Jan 06, 2017 at 08:41:12PM +0900, Andi Shyti wrote:
> From: Jaechul Lee <jcsing.lee@samsung.com>
>
> This patch adds the binding description of the tm2 touchkey
> device driver.
>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> .../bindings/input/samsung,tm2-touchkey.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 4/5] input: tm2-touchkey: Add touchkey driver support for TM2
From: Krzysztof Kozlowski @ 2017-01-06 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106114114.19321-5-andi.shyti@samsung.com>
On Fri, Jan 06, 2017 at 08:41:13PM +0900, Andi Shyti wrote:
> From: Jaechul Lee <jcsing.lee@samsung.com>
>
> This patch adds support for the TM2 touch key and led
> functionality.
>
> The driver interfaces with userspace through an input device and
> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
> controlled by "/sys/class/leds/tm2-touchkey/brightness".
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> drivers/input/keyboard/Kconfig | 11 ++
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/tm2-touchkey.c | 280 ++++++++++++++++++++++++++++++++++
> 3 files changed, 292 insertions(+)
> create mode 100644 drivers/input/keyboard/tm2-touchkey.c
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 9/9] arm64: Documentation - Expose CPU feature registers
From: Catalin Marinas @ 2017-01-06 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483552147-9605-10-git-send-email-suzuki.poulose@arm.com>
On Wed, Jan 04, 2017 at 05:49:07PM +0000, Suzuki K. Poulose wrote:
> +The following rules are applied to the value returned by the
> +infrastructure:
> +
> + a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0.
> + b) The value of a reserved field is populated with the reserved
> + value as defined by the architecture.
> + c) The value of a field marked as not 'visible', is set to indicate
> + the feature is missing (as defined by the architecture).
> + d) The value of a 'visible' field holds the system wide safe value
> + for the particular feature(except for MIDR_EL1, see section 4).
> + See Appendix I for more information on safe value.
> +
> +There are only a few registers visible to the userspace. See Section 4,
> +for the list of 'visible' registers.
> +
> +All others are emulated as having 'invisible' features.
BTW, we don't have any statement about whether a visible field may
become invisible but I guess this wouldn't be a problem as long as the
feature is reported as missing. I'm thinking about currently RES0 fields
that are listed as visible but they may report something in the future
that we don't want exposed to user. At that point, we'll change the
field to "invisible" while reporting RES0 to user. I don't see an issue
with this, just I thought worth flagging.
Anyway:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v3 2/3] DT: bingdings: power: reset: add linkstation-reset doc
From: Roger Shimizu @ 2017-01-06 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103170952.7svgaa247ewlht7f@rob-hp-laptop>
Dear Rob,
Thanks for your comments!
On Wed, Jan 4, 2017 at 2:09 AM, Rob Herring <robh@kernel.org> wrote:
>
> This needs to model the uC connected to the UART rather than some node
> that defines only some portion of the functionality. I'm working on
> bindings and proper bus support for this[1], but it's not done yet.
> Though, the binding side is pretty simple.
>
> Rob
>
> [1] https://git.kernel.org/cgit/linux/kernel/git/robh/linux.git/log/?h=serial-bus-v2
Actually I have limited knowledge on DT binding.
I think it should be OK to remove the 2/3 patch (this thread) in my
next series, and I'll do my homework when you finish it.
Thank you!
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
^ permalink raw reply
* [PATCH 2/2] arm64: mm: enable CONFIG_HOLES_IN_ZONE for NUMA
From: Ard Biesheuvel @ 2017-01-06 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106120339.GA20726@arm.com>
On 6 January 2017 at 12:03, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Jan 05, 2017 at 08:49:44PM +0100, Robert Richter wrote:
>> On 05.01.17 13:22:00, Robert Richter wrote:
>> > On 05.01.17 12:08:20, Will Deacon wrote:
>> > > I really can't see how the fix causes a crash, and I couldn't reproduce
>> > > it on any of my boards, nor could any of the Linaro folk afaik. Are you
>> > > definitely running mainline with just these two patches from Ard?
>> >
>> > Yes, just both patches applied. Various other solutions were working.
>>
>> I have retested the same kernel (v4.9 based) as before and now it
>> boots fine including rtc-efi device registration (it was crashing
>> there):
>>
>> rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>>
>> There could be a difference in firmware and mem setup, though I also
>> downgraded the firmware to test it, but can't reproduce it anymore. I
>> could reliable trigger the crash the first time.
>>
>> FTR the oops.
>
> Hmm, I just can't help but think you were accidentally running with
> additional patches when you saw this oops previously. For example,
> your log looks very similar to this one:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473666.html
>
> but then again, these crashes probably often look alike.
>
These are quite different, in fact. In James's case, the UEFI memory
map was missing some entries, so not all memory regions that the
firmware expected to be there were actually mapped, hence the all-zero
*pte. In Robert's case, it looks like the UEFI runtime services page
tables are corrupted, i.e., *pte has RES0 bits set.
^ permalink raw reply
* [PATCH] ARM: hw_breakpoint: blacklist Scorpion CPUs
From: Mark Rutland @ 2017-01-06 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106112125.GB15333@arm.com>
On Fri, Jan 06, 2017 at 11:21:25AM +0000, Will Deacon wrote:
> On Thu, Jan 05, 2017 at 05:32:36PM +0000, Mark Rutland wrote:
> > + if (read_cpuid_part() == ARM_CPU_PART_SCORPION) {
> > + pr_info("Scorpion CPU detected. Breakpoints and watchpoints disabled\n");
>
> nit: we're disabling *hardware* breakpoints and watchpoints, so it's worth
> mentioning that in the print.
True. I've fixed up the message.
> With that:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
> Please put this into Russell's patch system.
Cheers.
I've dropped this in the patch system as 8634/1.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v6 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Will Deacon @ 2017-01-06 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e518ab78-4093-0bc9-fe68-e7da25fd5644@huawei.com>
On Fri, Jan 06, 2017 at 11:41:28AM +0800, Ding Tianhong wrote:
> Please help reviewing the new version, I think it is nearly close to the
> final solution and it is very important to our chip or something else chip
> has similar erratum. If there is any dissatisfaction, please inform me
> and I will fix it. :)
It looks fine to me, but I don't maintain the arch timer driver!
Will
^ permalink raw reply
* [PATCH v3 4/9] arm64: cpufeature: Document the rules of safe value for features
From: Catalin Marinas @ 2017-01-06 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483552147-9605-5-git-send-email-suzuki.poulose@arm.com>
On Wed, Jan 04, 2017 at 05:49:02PM +0000, Suzuki K. Poulose wrote:
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -29,7 +29,21 @@
> #include <linux/jump_label.h>
> #include <linux/kernel.h>
>
> -/* CPU feature register tracking */
> +/*
> + * CPU feature register tracking
> + *
> + * The safe value of a CPUID feature field is dependent on the implications
> + * of the values assigned to it by the architecture. Based on the relationship
> + * between the values, the features are classified into 3 types.
> + *
> + * a) LOWER_SAFE - The value 'n+1' indicates, value 'n' and some
> + * additional features. (where n >= 0). The smaller value (n) is
> + * considered safer in this case.
> + * b) HIGHER_SAFE - The value 'n+1' is safer than 'n' (for n>= 0).
> + * c) EXACT - If the values of the feature don't have any relationship,
> + * a predefined safe value is used.
> + */
I don't think this text fully describes what is actually compared. You
could say something that the lowest value of all the CPUs is chosen for
LOWER_SAFE, highest for HIGHER_SAFE and it is expected that all CPUs
have the same value for a field when EXACT is specified.
--
Catalin
^ permalink raw reply
* [PATCH] clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled
From: Sudeep Holla @ 2017-01-06 12:34 UTC (permalink / raw)
To: linux-arm-kernel
Currently we add the virtual cpufreq device unconditionally even when
the SCPI DVFS clock provider node is disabled. This will cause cpufreq
driver to throw errors when it gets initailised on boot/modprobe and
also when the CPUs are hot-plugged back in.
This patch fixes the issue by adding the virtual cpufreq device only if
the SCPI DVFS clock provider is available and registered.
Fixes: 9490f01e2471 ("clk: scpi: add support for cpufreq virtual device")
Reported-by: Micha? Zegan <webczat_200@poczta.onet.pl>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/clk/clk-scpi.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-scpi.c b/drivers/clk/clk-scpi.c
index 2a3e9d8e88b0..96d37175d0ad 100644
--- a/drivers/clk/clk-scpi.c
+++ b/drivers/clk/clk-scpi.c
@@ -290,13 +290,15 @@ static int scpi_clocks_probe(struct platform_device *pdev)
of_node_put(child);
return ret;
}
- }
- /* Add the virtual cpufreq device */
- cpufreq_dev = platform_device_register_simple("scpi-cpufreq",
- -1, NULL, 0);
- if (IS_ERR(cpufreq_dev))
- pr_warn("unable to register cpufreq device");
+ if (match->data != &scpi_dvfs_ops)
+ continue;
+ /* Add the virtual cpufreq device if it's DVFS clock provider */
+ cpufreq_dev = platform_device_register_simple("scpi-cpufreq",
+ -1, NULL, 0);
+ if (IS_ERR(cpufreq_dev))
+ pr_warn("unable to register cpufreq device");
+ }
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Javier Martinez Canillas @ 2017-01-06 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106114114.19321-3-andi.shyti@samsung.com>
Hello Andi,
On 01/06/2017 08:41 AM, Andi Shyti wrote:
> Currently tm2e dts includes tm2 but there are some differences
> between the two boards and tm2 has some properties that tm2e
> doesn't have.
>
> That's why it's important to keep the two dts files independent
> and put all the commonalities in a tm2-common.dtsi file.
>
> At the current status the only two differences between the two
> dts files (besides the board name) are ldo31 and ldo38.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
I've some comments though:
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> dissimilarity index 98%
> index e8971f4a5977..d30b45a9c0d4 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -1,1120 +1,33 @@
[snip]
> -
> -/ {
> - model = "Samsung TM2 board";
> - compatible = "samsung,tm2", "samsung,exynos5433";
> -
[snip]
> +
> +/ {
> + model = "Samsung TM2E board";
> + compatible = "samsung,tm2e", "samsung,exynos5433";
> +};
> +
You ended with the wrong model and compatible for TM2.
Speaking about these, I noticed that the common .dtsi has the TM2 model and
compatible. I think those don't belong to .dtsi files and instead should be
defined on each .dts file.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v6 08/18] iommu/vt-d: Implement reserved region get/put callbacks
From: Joerg Roedel @ 2017-01-06 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <36bac0a9-89a6-ff7b-1870-a795a4f57700@redhat.com>
On Fri, Jan 06, 2017 at 12:45:54PM +0100, Auger Eric wrote:
> On 06/01/2017 12:01, Joerg Roedel wrote:
> > On Thu, Jan 05, 2017 at 07:04:36PM +0000, Eric Auger wrote:
> > That is different from what AMD does, can you also report the RMRR
> > regions for the device here (as direct-map regions)?
>
> if I return RMRR regions as direct mapped regions,
> iommu_group_create_direct_mappings will perform the 1-1 mapping.
No, this will not happen until the Intel IOMMU driver returns valid
IOMMU_DOMAIN_DMA type domains.
> I am not familiar with the intel-iommu code but I guess this job
> currently is done in the intel driver:
> iommu_prepare_rmrr_dev -> iommu_prepare_identity_map
> ->domain_prepare_identity_map -> iommu_domain_identity_map?
Right, this is done in the Intel driver atm.
Joerg
^ permalink raw reply
* [PATCH v6 07/18] iommu: Implement reserved_regions iommu-group sysfs file
From: Joerg Roedel @ 2017-01-06 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <888d3750-817c-77d1-8154-e77cf8c3ad4b@redhat.com>
On Fri, Jan 06, 2017 at 12:46:05PM +0100, Auger Eric wrote:
> On 06/01/2017 12:00, Joerg Roedel wrote:
> > I think it also makes sense to report the type of the reserved region.
>
> What is the best practice in that case? Shall we put the type enum
> values as strings such as:
> - direct
> - nomap
> - msi
>
> and document that in Documentation/ABI/testing/sysfs-kernel-iommu_groups
Yes, a string would be good. An probably 'reserved' is a better name
than nomap?
Joerg
^ 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