* [PATCH] ARM: dts: s5pv210: add interrupt-parent for ohci
From: Arnd Bergmann @ 2018-01-10 16:10 UTC (permalink / raw)
To: linux-arm-kernel
The ohci-hcd node has an interrupt number but no interrupt-parent,
leading to a warning with current dtc versions:
arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci at ec300000
As seen from the related exynos dts files, the ohci and ehci controllers
always share one interrupt number, and the number is the same here as
well, so setting the same interrupt-parent is the reasonable solution
here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/s5pv210.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
index 247c0029659c..67358562a6ea 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -460,6 +460,7 @@
compatible = "samsung,exynos4210-ohci";
reg = <0xec300000 0x100>;
interrupts = <23>;
+ interrupt-parent = <&vic1>;
clocks = <&clocks CLK_USB_HOST>;
clock-names = "usbhost";
#address-cells = <1>;
--
2.9.0
^ permalink raw reply related
* [PATCH 1/2] soc: imx: gpcv2: Do not pass static memory as platform data
From: Andrey Smirnov @ 2018-01-10 16:16 UTC (permalink / raw)
To: linux-arm-kernel
Platform device core assumes the ownership of dev.platform_data as
well as that it is dynamically allocated and it will try to kfree it
as a part of platform_device_release(). Change the code to pass
kzalloc'ed chunk of memory instead of a pointer to a static memory to
avoid causing a BUG() when calling platform_device_put().
The problem can be reproduced by artificially enabling the error path
of platform_device_add() call (around line 357).
Note that this change also allows us to constify imx7_pgc_domains,
since we no longer need to be able to modify it.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
This patch is a follow up to fix one of the bugs discussed in
lkml.kernel.org/r/3f836677c6e98aaf01bc1ac8c3410083 at agner.ch
drivers/soc/imx/gpcv2.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
index afc7ecc3c187..001b64afa5c1 100644
--- a/drivers/soc/imx/gpcv2.c
+++ b/drivers/soc/imx/gpcv2.c
@@ -18,6 +18,7 @@
#include <linux/pm_domain.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
#include <dt-bindings/power/imx7-power.h>
#define GPC_LPCR_A7_BSC 0x000
@@ -155,7 +156,7 @@ static int imx7_gpc_pu_pgc_sw_pdn_req(struct generic_pm_domain *genpd)
return imx7_gpc_pu_pgc_sw_pxx_req(genpd, false);
}
-static struct imx7_pgc_domain imx7_pgc_domains[] = {
+static const struct imx7_pgc_domain imx7_pgc_domains[] = {
[IMX7_POWER_DOMAIN_MIPI_PHY] = {
.genpd = {
.name = "mipi-phy",
@@ -321,7 +322,14 @@ static int imx_gpcv2_probe(struct platform_device *pdev)
continue;
}
- domain = &imx7_pgc_domains[domain_index];
+ domain = kzalloc(sizeof(*domain), GFP_KERNEL);
+ if (!domain) {
+ of_node_put(np);
+ return -ENOMEM;
+ }
+ memcpy(domain, &imx7_pgc_domains[domain_index],
+ sizeof(*domain));
+
domain->regmap = regmap;
domain->genpd.power_on = imx7_gpc_pu_pgc_sw_pup_req;
domain->genpd.power_off = imx7_gpc_pu_pgc_sw_pdn_req;
@@ -330,6 +338,7 @@ static int imx_gpcv2_probe(struct platform_device *pdev)
domain_index);
if (!pd_pdev) {
dev_err(dev, "Failed to allocate platform device\n");
+ kfree(domain);
of_node_put(np);
return -ENOMEM;
}
--
2.14.3
^ permalink raw reply related
* [PATCH 2/2] soc: imx: gpc: Do not pass static memory as platform data
From: Andrey Smirnov @ 2018-01-10 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110161608.13015-1-andrew.smirnov@gmail.com>
Platform device core assumes the ownership of dev.platform_data as
well as that it is dynamically allocated and it will try to kfree it
as a part of platform_device_release(). Change the code to pass
kzalloc'ed chunk of memory instead of a pointer to a static memory to
avoid causing a BUG() when calling platform_device_put().
The problem can be reproduced by artificially enabling the error path
of platform_device_add() call (around line 452).
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
This patch is a follow up to fix one of the bugs discussed in
lkml.kernel.org/r/3f836677c6e98aaf01bc1ac8c3410083 at agner.ch
drivers/soc/imx/gpc.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 47e7aa963dbb..ec8b79abebac 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -18,6 +18,7 @@
#include <linux/pm_domain.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
#define GPC_CNTR 0x000
@@ -428,13 +429,19 @@ static int imx_gpc_probe(struct platform_device *pdev)
if (domain_index >= of_id_data->num_domains)
continue;
- domain = &imx_gpc_domains[domain_index];
+ domain = kzalloc(sizeof(*domain), GFP_KERNEL);
+ if (!domain) {
+ of_node_put(np);
+ return -ENOMEM;
+ }
+ memcpy(domain, &imx_gpc_domains[domain_index], sizeof(*domain));
domain->regmap = regmap;
domain->ipg_rate_mhz = ipg_rate_mhz;
pd_pdev = platform_device_alloc("imx-pgc-power-domain",
domain_index);
if (!pd_pdev) {
+ kfree(domain);
of_node_put(np);
return -ENOMEM;
}
--
2.14.3
^ permalink raw reply related
* [RFC PATCH] arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum #843419
From: Ard Biesheuvel @ 2018-01-10 16:19 UTC (permalink / raw)
To: linux-arm-kernel
Working around Cortex-A53 erratum #843419 involves special handling of
ADRP instructions that end up in the last two instruction slots of a
4k page, or whose output register gets overwritten without having been
read.
Normally, this gets taken care of by the linker, which can spot such
sequences at final link time, and insert a veneer if the ADRP ends up
at a vulnerable offset. However, linux kernel modules are partially
linked binaries, and so there is no 'final link time' other than the
runtime loading of the module, at which time all the static relocations
are resolved.
For this reason, we have implemented the #843419 workaround for modules
by avoiding ADRP instructions altogether, by using the large C model,
and by passing -mpc-relative-literal-loads to recent versions of GCC
that may emit adrp/ldr pairs to perform literal loads. However, this
workaround forces us to keep literal data mixed with the instructions
in the executable .text segment, and literal data may inadvertently
turn into an exploitable speculative gadget depending on the relative
offsets of arbitrary symbols.
So let's reimplement this workaround in a way that allows us to switch
back to the small C model, and to drop the -mpc-relative-literal-loads
GCC switch, by patching affected ADRP instructions at runtime:
- ADRP instructions that do not appear at 4k relative offset 0xff8 or
0xffc are ignored
- ADRP instructions that are within 1 MB of their target symbol are
converted into ADR instructions
- remaining ADRP instructions are redirected via a veneer that performs
the load using an unaffected movn/movk sequence.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/Kconfig | 4 +-
arch/arm64/Makefile | 1 -
arch/arm64/include/asm/module.h | 2 +
arch/arm64/kernel/module-plts.c | 62 ++++++++++++++++++++
arch/arm64/kernel/module.c | 32 +++++++++-
arch/arm64/kernel/reloc_test_core.c | 4 +-
arch/arm64/kernel/reloc_test_syms.S | 12 +++-
7 files changed, 107 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c9a7e9e1414f..fa25de22b4fa 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -452,7 +452,7 @@ config ARM64_ERRATUM_845719
config ARM64_ERRATUM_843419
bool "Cortex-A53: 843419: A load or store might access an incorrect address"
default y
- select ARM64_MODULE_CMODEL_LARGE if MODULES
+ select ARM64_MODULE_PLTS if MODULES
help
This option links the kernel with '--fix-cortex-a53-843419' and
builds modules using the large memory model in order to avoid the use
@@ -1039,7 +1039,6 @@ config ARM64_MODULE_CMODEL_LARGE
config ARM64_MODULE_PLTS
bool
- select ARM64_MODULE_CMODEL_LARGE
select HAVE_MOD_ARCH_SPECIFIC
config RELOCATABLE
@@ -1056,6 +1055,7 @@ config RELOCATABLE
config RANDOMIZE_BASE
bool "Randomize the address of the kernel image"
select ARM64_MODULE_PLTS if MODULES
+ select ARM64_MODULE_CMODEL_LARGE
select RELOCATABLE
help
Randomizes the virtual address at which the kernel image is
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index bd7cb205e28a..f49aa51fce05 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -27,7 +27,6 @@ ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
$(warning ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum)
else
LDFLAGS_vmlinux += --fix-cortex-a53-843419
-KBUILD_CFLAGS_MODULE += $(call cc-option, -mpc-relative-literal-loads)
endif
endif
diff --git a/arch/arm64/include/asm/module.h b/arch/arm64/include/asm/module.h
index 4f766178fa6f..b6dbbe3123a9 100644
--- a/arch/arm64/include/asm/module.h
+++ b/arch/arm64/include/asm/module.h
@@ -39,6 +39,8 @@ struct mod_arch_specific {
u64 module_emit_plt_entry(struct module *mod, void *loc, const Elf64_Rela *rela,
Elf64_Sym *sym);
+u64 module_emit_adrp_veneer(struct module *mod, void *loc, u64 val);
+
#ifdef CONFIG_RANDOMIZE_BASE
extern u64 module_alloc_base;
#else
diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
index ea640f92fe5a..b4e7fe45d337 100644
--- a/arch/arm64/kernel/module-plts.c
+++ b/arch/arm64/kernel/module-plts.c
@@ -41,6 +41,47 @@ u64 module_emit_plt_entry(struct module *mod, void *loc, const Elf64_Rela *rela,
return (u64)&plt[i];
}
+#ifdef CONFIG_ARM64_ERRATUM_843419
+u64 module_emit_adrp_veneer(struct module *mod, void *loc, u64 val)
+{
+ struct mod_plt_sec *pltsec = !in_init(mod, loc) ? &mod->arch.core :
+ &mod->arch.init;
+ struct plt_entry *plt = (struct plt_entry *)pltsec->plt->sh_addr;
+ int i = pltsec->plt_num_entries;
+ u32 mov0, mov1, mov2, br;
+ int rd;
+
+ /* get the destination register of the ADRP instruction */
+ rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD,
+ le32_to_cpup((__le32 *)loc));
+
+ /* generate the veneer instructions */
+ mov0 = aarch64_insn_gen_movewide(rd, (u16)~val, 0,
+ AARCH64_INSN_VARIANT_64BIT,
+ AARCH64_INSN_MOVEWIDE_INVERSE);
+ mov1 = aarch64_insn_gen_movewide(rd, (u16)(val >> 16), 16,
+ AARCH64_INSN_VARIANT_64BIT,
+ AARCH64_INSN_MOVEWIDE_KEEP);
+ mov2 = aarch64_insn_gen_movewide(rd, (u16)(val >> 32), 32,
+ AARCH64_INSN_VARIANT_64BIT,
+ AARCH64_INSN_MOVEWIDE_KEEP);
+ br = aarch64_insn_gen_branch_imm((u64)&plt[i].br, (u64)loc + 4,
+ AARCH64_INSN_BRANCH_NOLINK);
+
+ plt[i] = (struct plt_entry){
+ cpu_to_le32(mov0),
+ cpu_to_le32(mov1),
+ cpu_to_le32(mov2),
+ cpu_to_le32(br)
+ };
+
+ pltsec->plt_num_entries++;
+ BUG_ON(pltsec->plt_num_entries > pltsec->plt_max_entries);
+
+ return (u64)&plt[i];
+}
+#endif
+
#define cmp_3way(a,b) ((a) < (b) ? -1 : (a) > (b))
static int cmp_rela(const void *a, const void *b)
@@ -109,6 +150,18 @@ static unsigned int count_plts(Elf64_Sym *syms, Elf64_Rela *rela, int num,
if (rela[i].r_addend != 0 || !duplicate_rel(rela, i))
ret++;
break;
+ case R_AARCH64_ADR_PREL_PG_HI21_NC:
+ case R_AARCH64_ADR_PREL_PG_HI21:
+ /*
+ * Allocate veneer space for each ADRP that appears at
+ * a vulnerable offset. At relocation time, some of
+ * these will remain unused since some ADRP instructions
+ * can be patched to ADR instructions instead.
+ */
+ if (IS_ENABLED(CONFIG_ARM64_ERRATUM_843419) &&
+ (rela[i].r_offset & 0xfff) >= 0xff8)
+ ret++;
+ break;
}
}
return ret;
@@ -161,6 +214,15 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
if (!(dstsec->sh_flags & SHF_EXECINSTR))
continue;
+ if (IS_ENABLED(CONFIG_ARM64_ERRATUM_843419) &&
+ sechdrs[i].sh_addralign < SZ_4K)
+ /*
+ * Increase the alignment of all executable sections to
+ * 4k so that can we use r_offset to check whether the
+ * ADRP instruction will end up at a vulnerable offset.
+ */
+ sechdrs[i].sh_addralign = SZ_4K;
+
/* sort by type, symbol index and addend */
sort(rels, numrels, sizeof(Elf64_Rela), cmp_rela, NULL);
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index f469e0435903..f5fdb2eea032 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -197,6 +197,32 @@ static int reloc_insn_imm(enum aarch64_reloc_op op, __le32 *place, u64 val,
return 0;
}
+static bool reloc_adrp_erratum_843419(struct module *mod, __le32 *place,
+ u64 val)
+{
+ if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_843419))
+ return false;
+
+ /* only ADRP instructions@the end of a 4k page are affected */
+ if (((u64)place & 0xfff) < 0xff8)
+ return false;
+
+ /* patch ADRP to ADR if it is in range */
+ if (!reloc_insn_imm(RELOC_OP_PREL, place, val & ~0xfff, 0, 21,
+ AARCH64_INSN_IMM_ADR)) {
+ ((u8 *)place)[3] &= 0x7f; /* clear opcode bit 31 */
+ } else {
+ u32 insn;
+
+ /* out of range for ADR -> emit a veneer */
+ val = module_emit_adrp_veneer(mod, place, val & ~0xfff);
+ insn = aarch64_insn_gen_branch_imm((u64)place, val,
+ AARCH64_INSN_BRANCH_NOLINK);
+ *place = cpu_to_le32(insn);
+ }
+ return true;
+}
+
int apply_relocate_add(Elf64_Shdr *sechdrs,
const char *strtab,
unsigned int symindex,
@@ -336,14 +362,16 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
ovf = reloc_insn_imm(RELOC_OP_PREL, loc, val, 0, 21,
AARCH64_INSN_IMM_ADR);
break;
-#ifndef CONFIG_ARM64_ERRATUM_843419
case R_AARCH64_ADR_PREL_PG_HI21_NC:
overflow_check = false;
case R_AARCH64_ADR_PREL_PG_HI21:
+ if (reloc_adrp_erratum_843419(me, loc, val)) {
+ ovf = false;
+ break;
+ }
ovf = reloc_insn_imm(RELOC_OP_PAGE, loc, val, 12, 21,
AARCH64_INSN_IMM_ADR);
break;
-#endif
case R_AARCH64_ADD_ABS_LO12_NC:
case R_AARCH64_LDST8_ABS_LO12_NC:
overflow_check = false;
diff --git a/arch/arm64/kernel/reloc_test_core.c b/arch/arm64/kernel/reloc_test_core.c
index c124752a8bd3..a70489c584c7 100644
--- a/arch/arm64/kernel/reloc_test_core.c
+++ b/arch/arm64/kernel/reloc_test_core.c
@@ -28,6 +28,7 @@ asmlinkage u64 absolute_data16(void);
asmlinkage u64 signed_movw(void);
asmlinkage u64 unsigned_movw(void);
asmlinkage u64 relative_adrp(void);
+asmlinkage u64 relative_adrp_far(void);
asmlinkage u64 relative_adr(void);
asmlinkage u64 relative_data64(void);
asmlinkage u64 relative_data32(void);
@@ -43,9 +44,8 @@ static struct {
{ "R_AARCH64_ABS16", absolute_data16, UL(SYM16_ABS_VAL) },
{ "R_AARCH64_MOVW_SABS_Gn", signed_movw, UL(SYM64_ABS_VAL) },
{ "R_AARCH64_MOVW_UABS_Gn", unsigned_movw, UL(SYM64_ABS_VAL) },
-#ifndef CONFIG_ARM64_ERRATUM_843419
{ "R_AARCH64_ADR_PREL_PG_HI21", relative_adrp, (u64)&sym64_rel },
-#endif
+ { "R_AARCH64_ADR_PREL_PG_HI21", relative_adrp_far, (u64)&printk },
{ "R_AARCH64_ADR_PREL_LO21", relative_adr, (u64)&sym64_rel },
{ "R_AARCH64_PREL64", relative_data64, (u64)&sym64_rel },
{ "R_AARCH64_PREL32", relative_data32, (u64)&sym64_rel },
diff --git a/arch/arm64/kernel/reloc_test_syms.S b/arch/arm64/kernel/reloc_test_syms.S
index e1edcefeb02d..f333b4b7880d 100644
--- a/arch/arm64/kernel/reloc_test_syms.S
+++ b/arch/arm64/kernel/reloc_test_syms.S
@@ -43,15 +43,21 @@ ENTRY(unsigned_movw)
ret
ENDPROC(unsigned_movw)
-#ifndef CONFIG_ARM64_ERRATUM_843419
-
+ .align 12
+ .space 0xff8
ENTRY(relative_adrp)
adrp x0, sym64_rel
add x0, x0, #:lo12:sym64_rel
ret
ENDPROC(relative_adrp)
-#endif
+ .align 12
+ .space 0xffc
+ENTRY(relative_adrp_far)
+ adrp x0, printk
+ add x0, x0, #:lo12:printk
+ ret
+ENDPROC(relative_adrp_far)
ENTRY(relative_adr)
adr x0, sym64_rel
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: lpc3250: fix uda1380 gpio numbers
From: Arnd Bergmann @ 2018-01-10 16:22 UTC (permalink / raw)
To: linux-arm-kernel
dtc warns about obviously incorrect GPIO numbers for the audio codec
on both lpc32xx boards:
arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): reset-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): power-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): reset-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): power-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c at 400A0000/uda1380 at 18
It looks like the nodes are written for a different binding that combines
the GPIO number into a single number rather than a bank/number pair.
I found the right numbers on stackexchange.com, so this patch fixes
the warning and has a reasonable chance of getting things to actually
work.
Link: https://unix.stackexchange.com/questions/59497/alsa-asoc-how-to-correctly-load-devices-drivers/62217#62217
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/lpc3250-ea3250.dts | 4 ++--
arch/arm/boot/dts/lpc3250-phy3250.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/lpc3250-ea3250.dts b/arch/arm/boot/dts/lpc3250-ea3250.dts
index c43adb7b4d7c..58ea0a4e7afa 100644
--- a/arch/arm/boot/dts/lpc3250-ea3250.dts
+++ b/arch/arm/boot/dts/lpc3250-ea3250.dts
@@ -156,8 +156,8 @@
uda1380: uda1380 at 18 {
compatible = "nxp,uda1380";
reg = <0x18>;
- power-gpio = <&gpio 0x59 0>;
- reset-gpio = <&gpio 0x51 0>;
+ power-gpio = <&gpio 3 10 0>;
+ reset-gpio = <&gpio 3 2 0>;
dac-clk = "wspll";
};
diff --git a/arch/arm/boot/dts/lpc3250-phy3250.dts b/arch/arm/boot/dts/lpc3250-phy3250.dts
index c72eb9845603..1e1c2f517a82 100644
--- a/arch/arm/boot/dts/lpc3250-phy3250.dts
+++ b/arch/arm/boot/dts/lpc3250-phy3250.dts
@@ -81,8 +81,8 @@
uda1380: uda1380 at 18 {
compatible = "nxp,uda1380";
reg = <0x18>;
- power-gpio = <&gpio 0x59 0>;
- reset-gpio = <&gpio 0x51 0>;
+ power-gpio = <&gpio 3 10 0>;
+ reset-gpio = <&gpio 3 2 0>;
dac-clk = "wspll";
};
--
2.9.0
^ permalink raw reply related
* [PATCH] crypto: marvell/cesa - Fix DMA API misuse
From: Boris Brezillon @ 2018-01-10 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110154817.GA18707@lst.de>
Hi Christoph,
On Wed, 10 Jan 2018 16:48:17 +0100
Christoph Hellwig <hch@lst.de> wrote:
> On Wed, Jan 10, 2018 at 04:25:22PM +0100, Boris Brezillon wrote:
> > On Wed, 10 Jan 2018 15:15:43 +0000
> > Robin Murphy <robin.murphy@arm.com> wrote:
> >
> > > phys_to_dma() is an internal helper for certain DMA API implementations,
> > > and is not appropriate for drivers to use. It appears that what the CESA
> > > driver really wants to be using is dma_map_resource() - admittedly that
> > > didn't exist when the offending code was first merged, but it does now.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >
> > Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>
> Thanks. Robin, Boris: do you want me to pick this up in the
> dma-mapping tree and move it before the dma-direct.h introduction?
You should probably sync with Herbert, I'm just the maintainer of this
driver, not the crypto subsystem.
Regards,
Boris
^ permalink raw reply
* [PATCH] ARM: pxa/tosa-bt: add MODULE_LICENSE tag
From: Arnd Bergmann @ 2018-01-10 16:28 UTC (permalink / raw)
To: linux-arm-kernel
Without this tag, we get a build warning:
WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o
For completeness, I'm also adding author and description fields.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-pxa/tosa-bt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-pxa/tosa-bt.c b/arch/arm/mach-pxa/tosa-bt.c
index 107f37210fb9..83606087edc7 100644
--- a/arch/arm/mach-pxa/tosa-bt.c
+++ b/arch/arm/mach-pxa/tosa-bt.c
@@ -132,3 +132,7 @@ static struct platform_driver tosa_bt_driver = {
},
};
module_platform_driver(tosa_bt_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Dmitry Baryshkov");
+MODULE_DESCRIPTION("Bluetooth built-in chip control");
--
2.9.0
^ permalink raw reply related
* [PATCH] ARM: bL_switcher: add MODULE_LICENSE tag
From: Arnd Bergmann @ 2018-01-10 16:29 UTC (permalink / raw)
To: linux-arm-kernel
Without this tag, we get a build warning:
WARNING: modpost: missing MODULE_LICENSE() in arch/arm/common/bL_switcher_dummy_if.o
For completeness, I'm also adding author and description fields.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/common/bL_switcher_dummy_if.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/common/bL_switcher_dummy_if.c b/arch/arm/common/bL_switcher_dummy_if.c
index 4c10c6452678..f4dc1714a79e 100644
--- a/arch/arm/common/bL_switcher_dummy_if.c
+++ b/arch/arm/common/bL_switcher_dummy_if.c
@@ -57,3 +57,7 @@ static struct miscdevice bL_switcher_device = {
&bL_switcher_fops
};
module_misc_device(bL_switcher_device);
+
+MODULE_AUTHOR("Nicolas Pitre <nico@linaro.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("big.LITTLE switcher dummy user interface");
--
2.9.0
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
From: Stephen Boyd @ 2018-01-10 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaN6vmV4L4U76DvD5BN+j1RYCQakTysA+GGPdT8Chc-iw@mail.gmail.com>
On 01/10, Linus Walleij wrote:
> On Wed, Jan 10, 2018 at 2:58 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> > +- ngpios-ranges:
> > + Usage: optional
> > + Value type: <prop-encoded-array>
> > + Definition: Tuples of GPIO ranges (base, size) indicating
> > + GPIOs available for use.
> > +
> > Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
> > a general description of GPIO and interrupt bindings.
>
> I like the tuples syntax. That's fine. It's like gpio-ranges we have
> already to map between pin controllers and GPIO.
>
> I don't think we can reuse gpio-ranges because that is
> exclusively for pin control ATM, it would be fine if the ranges
> were for a specific device, like pin control does, like:
>
> gpio-ranges = <&secure_world_thing 0 20 10>;
>
> But you definately would need a node to tie it to, so that the
> driver for that node can specify that it's gonna take the
> GPIOs.
>
> But I think the semantics should be the inverse. That you
> point out "holes" with the lines we *can't* use.
Ok. I can invert the logic and push it into the core part of the
code. I'll leave the ACPI part in the msm driver.
>
> We already support a generic property "ngpios" that says how
> many of the GPIOs (counted from zero) that can be used,
> so if those should be able to use this as a generic property it
> is better with the inverse semantics and say that the
> "reserved-gpio-ranges", "secureworld-gpio-ranges"
> (or whatever we decide to call it) takes precedence over
> ngpios so we don't end up in ambigous places.
>
> Then, will it be possible to put the parsing, handling and
> disablement of these ranges into drivers/gpio/gpiolib-of.c
> where we handle the ranges today, or do we need to
> do it in the individual drivers?
>
I'll cook that up right now to do the inverse thing in the
gpiolib core code with a 'reserved-gpio-ranges' property. I
haven't looked in much detail, but I would hope that it would
work pretty easily. Should it be decoupled from the
GPIOLIB_IRQCHIP config? If the idea is generic, then it may not
be related to irq lines, but for the qcom driver it was all fine
because all three concepts: irq, gpios, and pins have a one to
one relationship. The only place it breaks down is if we have
more pins than gpios, in which case I punted and just considered
non-gpio pins as always valid.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] ARM: bL_switcher: add MODULE_LICENSE tag
From: Nicolas Pitre @ 2018-01-10 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110162911.461577-1-arnd@arndb.de>
On Wed, 10 Jan 2018, Arnd Bergmann wrote:
> Without this tag, we get a build warning:
>
> WARNING: modpost: missing MODULE_LICENSE() in arch/arm/common/bL_switcher_dummy_if.o
>
> For completeness, I'm also adding author and description fields.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/common/bL_switcher_dummy_if.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/common/bL_switcher_dummy_if.c b/arch/arm/common/bL_switcher_dummy_if.c
> index 4c10c6452678..f4dc1714a79e 100644
> --- a/arch/arm/common/bL_switcher_dummy_if.c
> +++ b/arch/arm/common/bL_switcher_dummy_if.c
> @@ -57,3 +57,7 @@ static struct miscdevice bL_switcher_device = {
> &bL_switcher_fops
> };
> module_misc_device(bL_switcher_device);
> +
> +MODULE_AUTHOR("Nicolas Pitre <nico@linaro.org>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("big.LITTLE switcher dummy user interface");
> --
> 2.9.0
>
>
^ permalink raw reply
* [PATCH v2 0/2] drivers: remove incorrect usage/dependency on topology_physical_package_id
From: Sudeep Holla @ 2018-01-10 16:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
There has been ongoing attempt to add ACPI topology support on ARM/ARM64
platform using PPTT. However it was discovered that the physical package
id is mapped to the so called clusters on ARM platforms and they don't
map to the physical socket as in other architectures.
In order to add the correct support for the well defined physical sockets,
we need to find remove the incorrect usage or any dependency on
topology_physical_package_id which currently maps to the clusters.
There's still one pending user of topology_physical_package_id, which is
arm_big_little driver which is used by bL switcher and by TC2 platform.
For now, we can leave that as is until we change the definition even for
ARM32 platforms as it's just used by only 32-bit platforms.
v1->v2:
- Update change log in patch 1/2 as suggested by Lorenzo
- Added acks from Viresh and Lorenzo
Sudeep Holla (2):
drivers: psci: remove cluster terminology and dependency on
physical_package_id
cpufreq: scpi: remove arm_big_little dependency
drivers/cpufreq/scpi-cpufreq.c | 193 ++++++++++++++++++++++++++++++++++++----
drivers/firmware/psci_checker.c | 46 +++++-----
2 files changed, 200 insertions(+), 39 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/2] drivers: psci: remove cluster terminology and dependency on physical_package_id
From: Sudeep Holla @ 2018-01-10 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515602655-12740-1-git-send-email-sudeep.holla@arm.com>
Since the definition of the term "cluster" is not well defined in the
architecture, we should avoid using it. Also the physical package id
is currently mapped to so called "clusters" in ARM/ARM64 platforms which
is already argumentative.
Currently PSCI checker uses the physical package id assuming that CPU
power domains map to "clusters" and the physical package id in the code
as it stands also maps to cluster boundaries. It does that trying to
test "cluster" idle states to its best. However the CPU power domain
often but not always maps directly to the processor topology.
This patch removes the dependency on physical_package_id from the topology
in this PSCI checker. Also it replaces all the occurences of clusters to
cpu_groups which is derived from core_sibling_mask and may not directly
map to physical "cluster".
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/firmware/psci_checker.c | 46 ++++++++++++++++++++---------------------
1 file changed, 22 insertions(+), 24 deletions(-)
diff --git a/drivers/firmware/psci_checker.c b/drivers/firmware/psci_checker.c
index f3f4f810e5df..bb1c068bff19 100644
--- a/drivers/firmware/psci_checker.c
+++ b/drivers/firmware/psci_checker.c
@@ -77,8 +77,8 @@ static int psci_ops_check(void)
return 0;
}
-static int find_clusters(const struct cpumask *cpus,
- const struct cpumask **clusters)
+static int find_cpu_groups(const struct cpumask *cpus,
+ const struct cpumask **cpu_groups)
{
unsigned int nb = 0;
cpumask_var_t tmp;
@@ -88,11 +88,11 @@ static int find_clusters(const struct cpumask *cpus,
cpumask_copy(tmp, cpus);
while (!cpumask_empty(tmp)) {
- const struct cpumask *cluster =
+ const struct cpumask *cpu_group =
topology_core_cpumask(cpumask_any(tmp));
- clusters[nb++] = cluster;
- cpumask_andnot(tmp, tmp, cluster);
+ cpu_groups[nb++] = cpu_group;
+ cpumask_andnot(tmp, tmp, cpu_group);
}
free_cpumask_var(tmp);
@@ -170,24 +170,24 @@ static int hotplug_tests(void)
{
int err;
cpumask_var_t offlined_cpus;
- int i, nb_cluster;
- const struct cpumask **clusters;
+ int i, nb_cpu_group;
+ const struct cpumask **cpu_groups;
char *page_buf;
err = -ENOMEM;
if (!alloc_cpumask_var(&offlined_cpus, GFP_KERNEL))
return err;
- /* We may have up to nb_available_cpus clusters. */
- clusters = kmalloc_array(nb_available_cpus, sizeof(*clusters),
- GFP_KERNEL);
- if (!clusters)
+ /* We may have up to nb_available_cpus cpu_groups. */
+ cpu_groups = kmalloc_array(nb_available_cpus, sizeof(*cpu_groups),
+ GFP_KERNEL);
+ if (!cpu_groups)
goto out_free_cpus;
page_buf = (char *)__get_free_page(GFP_KERNEL);
if (!page_buf)
- goto out_free_clusters;
+ goto out_free_cpu_groups;
err = 0;
- nb_cluster = find_clusters(cpu_online_mask, clusters);
+ nb_cpu_group = find_cpu_groups(cpu_online_mask, cpu_groups);
/*
* Of course the last CPU cannot be powered down and cpu_down() should
@@ -197,24 +197,22 @@ static int hotplug_tests(void)
err += down_and_up_cpus(cpu_online_mask, offlined_cpus);
/*
- * Take down CPUs by cluster this time. When the last CPU is turned
- * off, the cluster itself should shut down.
+ * Take down CPUs by cpu group this time. When the last CPU is turned
+ * off, the cpu group itself should shut down.
*/
- for (i = 0; i < nb_cluster; ++i) {
- int cluster_id =
- topology_physical_package_id(cpumask_any(clusters[i]));
+ for (i = 0; i < nb_cpu_group; ++i) {
ssize_t len = cpumap_print_to_pagebuf(true, page_buf,
- clusters[i]);
+ cpu_groups[i]);
/* Remove trailing newline. */
page_buf[len - 1] = '\0';
- pr_info("Trying to turn off and on again cluster %d "
- "(CPUs %s)\n", cluster_id, page_buf);
- err += down_and_up_cpus(clusters[i], offlined_cpus);
+ pr_info("Trying to turn off and on again group %d (CPUs %s)\n",
+ i, page_buf);
+ err += down_and_up_cpus(cpu_groups[i], offlined_cpus);
}
free_page((unsigned long)page_buf);
-out_free_clusters:
- kfree(clusters);
+out_free_cpu_groups:
+ kfree(cpu_groups);
out_free_cpus:
free_cpumask_var(offlined_cpus);
return err;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] cpufreq: scpi: remove arm_big_little dependency
From: Sudeep Holla @ 2018-01-10 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515602655-12740-1-git-send-email-sudeep.holla@arm.com>
The dependency on physical_package_id from the topology to get the
cluster identifier is wrong. The concept of cluster used in ARM topology
is unfortunately not well defined in the architecture, we should avoid
using it. Further the frequency domain need not be mapped to so called
"clusters" one to one.
SCPI already provides means to obtain the frequency domain id from the
device tree. In order to support some new topologies(e.g. DSU which
contains 2 frequency domains within the physical cluster), pseudo
clusters are created to make this driver work which is wrong again.
In order to solve those issues and also remove dependency of topological
physical id for frequency domain, this patch removes the arm_big_little
dependency from scpi driver.
Cc: linux-amlogic at lists.infradead.org
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/cpufreq/scpi-cpufreq.c | 193 +++++++++++++++++++++++++++++++++++++----
1 file changed, 178 insertions(+), 15 deletions(-)
Hi AmLogic team,
I would like to get tested-by tag so that there's no last minute surprise
from this patch on Amlogic platforms.
Regards,
Sudeep
diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c
index 05d299052c5c..247fcbfa4cb5 100644
--- a/drivers/cpufreq/scpi-cpufreq.c
+++ b/drivers/cpufreq/scpi-cpufreq.c
@@ -18,27 +18,89 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include <linux/clk.h>
#include <linux/cpu.h>
#include <linux/cpufreq.h>
+#include <linux/cpumask.h>
+#include <linux/cpu_cooling.h>
+#include <linux/export.h>
#include <linux/module.h>
-#include <linux/platform_device.h>
+#include <linux/of_platform.h>
#include <linux/pm_opp.h>
#include <linux/scpi_protocol.h>
+#include <linux/slab.h>
#include <linux/types.h>
-#include "arm_big_little.h"
+struct scpi_data {
+ struct clk *clk;
+ struct device *cpu_dev;
+ struct thermal_cooling_device *cdev;
+};
static struct scpi_ops *scpi_ops;
-static int scpi_get_transition_latency(struct device *cpu_dev)
+static unsigned int scpi_cpufreq_get_rate(unsigned int cpu)
+{
+ struct cpufreq_policy *policy = cpufreq_cpu_get_raw(cpu);
+ struct scpi_data *priv = policy->driver_data;
+ unsigned long rate = clk_get_rate(priv->clk);
+
+ return rate / 1000;
+}
+
+static int
+scpi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index)
+{
+ struct scpi_data *priv = policy->driver_data;
+ u64 rate = policy->freq_table[index].frequency * 1000;
+ int ret;
+
+ ret = clk_set_rate(priv->clk, rate);
+ if (!ret && (clk_get_rate(priv->clk) != rate))
+ ret = -EIO;
+
+ return ret;
+}
+
+static int
+scpi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
{
- return scpi_ops->get_transition_latency(cpu_dev);
+ int cpu, domain, tdomain;
+ struct device *tcpu_dev;
+
+ domain = scpi_ops->device_domain_id(cpu_dev);
+ if (domain < 0)
+ return domain;
+
+ for_each_possible_cpu(cpu) {
+ if (cpu == cpu_dev->id)
+ continue;
+
+ tcpu_dev = get_cpu_device(cpu);
+ if (!tcpu_dev)
+ continue;
+
+ tdomain = scpi_ops->device_domain_id(tcpu_dev);
+ if (tdomain == domain)
+ cpumask_set_cpu(cpu, cpumask);
+ }
+
+ return 0;
}
-static int scpi_init_opp_table(const struct cpumask *cpumask)
+static int scpi_cpufreq_init(struct cpufreq_policy *policy)
{
int ret;
- struct device *cpu_dev = get_cpu_device(cpumask_first(cpumask));
+ unsigned int latency;
+ struct device *cpu_dev;
+ struct scpi_data *priv;
+ struct cpufreq_frequency_table *freq_table;
+
+ cpu_dev = get_cpu_device(policy->cpu);
+ if (!cpu_dev) {
+ pr_err("failed to get cpu%d device\n", policy->cpu);
+ return -ENODEV;
+ }
ret = scpi_ops->add_opps_to_device(cpu_dev);
if (ret) {
@@ -46,32 +108,133 @@ static int scpi_init_opp_table(const struct cpumask *cpumask)
return ret;
}
- ret = dev_pm_opp_set_sharing_cpus(cpu_dev, cpumask);
- if (ret)
+ ret = scpi_get_sharing_cpus(cpu_dev, policy->cpus);
+ if (ret) {
+ dev_warn(cpu_dev, "failed to get sharing cpumask\n");
+ return ret;
+ }
+
+ ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
+ if (ret) {
dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n",
__func__, ret);
+ return ret;
+ }
+
+ ret = dev_pm_opp_get_opp_count(cpu_dev);
+ if (ret <= 0) {
+ dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
+ ret = -EPROBE_DEFER;
+ goto out_free_opp;
+ }
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ ret = -ENOMEM;
+ goto out_free_opp;
+ }
+
+ ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table);
+ if (ret) {
+ dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);
+ goto out_free_priv;
+ }
+
+ priv->cpu_dev = cpu_dev;
+ priv->clk = clk_get(cpu_dev, NULL);
+ if (IS_ERR(priv->clk)) {
+ dev_err(cpu_dev, "%s: Failed to get clk for cpu: %d\n",
+ __func__, cpu_dev->id);
+ goto out_free_cpufreq_table;
+ }
+
+ policy->driver_data = priv;
+
+ ret = cpufreq_table_validate_and_show(policy, freq_table);
+ if (ret) {
+ dev_err(cpu_dev, "%s: invalid frequency table: %d\n", __func__,
+ ret);
+ goto out_put_clk;
+ }
+
+ /* scpi allows DVFS request for any domain from any CPU */
+ policy->dvfs_possible_from_any_cpu = true;
+
+ latency = scpi_ops->get_transition_latency(cpu_dev);
+ if (!latency)
+ latency = CPUFREQ_ETERNAL;
+
+ policy->cpuinfo.transition_latency = latency;
+
+ policy->fast_switch_possible = false;
+ return 0;
+
+out_put_clk:
+ clk_put(priv->clk);
+out_free_cpufreq_table:
+ dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
+out_free_priv:
+ kfree(priv);
+out_free_opp:
+ dev_pm_opp_cpumask_remove_table(policy->cpus);
+
return ret;
}
-static const struct cpufreq_arm_bL_ops scpi_cpufreq_ops = {
- .name = "scpi",
- .get_transition_latency = scpi_get_transition_latency,
- .init_opp_table = scpi_init_opp_table,
- .free_opp_table = dev_pm_opp_cpumask_remove_table,
+static int scpi_cpufreq_exit(struct cpufreq_policy *policy)
+{
+ struct scpi_data *priv = policy->driver_data;
+
+ cpufreq_cooling_unregister(priv->cdev);
+ clk_put(priv->clk);
+ dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table);
+ kfree(priv);
+ dev_pm_opp_cpumask_remove_table(policy->related_cpus);
+
+ return 0;
+}
+
+static void scpi_cpufreq_ready(struct cpufreq_policy *policy)
+{
+ struct scpi_data *priv = policy->driver_data;
+ struct thermal_cooling_device *cdev;
+
+ cdev = of_cpufreq_cooling_register(policy);
+ if (!IS_ERR(cdev))
+ priv->cdev = cdev;
+}
+
+static struct cpufreq_driver scpi_cpufreq_driver = {
+ .name = "scpi-cpufreq",
+ .flags = CPUFREQ_STICKY | CPUFREQ_HAVE_GOVERNOR_PER_POLICY |
+ CPUFREQ_NEED_INITIAL_FREQ_CHECK,
+ .verify = cpufreq_generic_frequency_table_verify,
+ .attr = cpufreq_generic_attr,
+ .get = scpi_cpufreq_get_rate,
+ .init = scpi_cpufreq_init,
+ .exit = scpi_cpufreq_exit,
+ .ready = scpi_cpufreq_ready,
+ .target_index = scpi_cpufreq_set_target,
};
static int scpi_cpufreq_probe(struct platform_device *pdev)
{
+ int ret;
+
scpi_ops = get_scpi_ops();
if (!scpi_ops)
return -EIO;
- return bL_cpufreq_register(&scpi_cpufreq_ops);
+ ret = cpufreq_register_driver(&scpi_cpufreq_driver);
+ if (ret)
+ dev_err(&pdev->dev, "%s: registering cpufreq failed, err: %d\n",
+ __func__, ret);
+ return ret;
}
static int scpi_cpufreq_remove(struct platform_device *pdev)
{
- bL_cpufreq_unregister(&scpi_cpufreq_ops);
+ cpufreq_unregister_driver(&scpi_cpufreq_driver);
scpi_ops = NULL;
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/6] arm: Invalidate BTB on prefetch abort outside of user mapping on Cortex A8, A9, A12 and A17
From: Russell King - ARM Linux @ 2018-01-10 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108185533.9698-3-marc.zyngier@arm.com>
On Mon, Jan 08, 2018 at 06:55:29PM +0000, Marc Zyngier wrote:
> In order to prevent aliasing attacks on the branch predictor,
> invalidate the BTB on CPUs that are known to be affected when taking
> a prefetch abort on a address that is outside of a user task limit.
Can you please describe to me what sort of exploit this is supposed
to be protecting against - if you do not wish to make the details
public, please reply in private.
As far as I can see, this has no effect on the exploits that have been
made public to date as none of them involve the prefetch abort handler,
and from what I can see in the "Cache Speculation Side-Channels"
document, no mention is made of the prefetch abort.
Indeed, I've received feedback from Florian that my set of "exploits"
based on the published information to date are unaffected by your
patch series, so I'm really interested to know exactly what this
series is trying to fix.
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] usb: mtu3: fix ssusb_wakeup_set dummy
From: Arnd Bergmann @ 2018-01-10 16:45 UTC (permalink / raw)
To: linux-arm-kernel
Changing from ssusb_wakeup_enable/disable to ssusb_wakeup_set was done
in only one of two places in the kernel, the other one now causes a
build failure:
drivers/usb/mtu3/mtu3_plat.c: In function 'mtu3_suspend':
drivers/usb/mtu3/mtu3_plat.c:462:2: error: implicit declaration of function 'ssusb_wakeup_set'; did you mean 'ssusb_wakeup_disable'? [-Werror=implicit-function-declaration]
This adapts the dummy helpers the same way that the extern declarations
were.
Fixes: f0ede2c6282b ("usb: mtu3: supports remote wakeup for mt2712 with two SSUSB IPs")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/usb/mtu3/mtu3_dr.h | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_dr.h b/drivers/usb/mtu3/mtu3_dr.h
index ae1598d76e02..50702fdcde28 100644
--- a/drivers/usb/mtu3/mtu3_dr.h
+++ b/drivers/usb/mtu3/mtu3_dr.h
@@ -48,12 +48,7 @@ static inline int ssusb_host_disable(struct ssusb_mtk *ssusb, bool suspend)
return 0;
}
-static inline int ssusb_wakeup_enable(struct ssusb_mtk *ssusb)
-{
- return 0;
-}
-
-static inline void ssusb_wakeup_disable(struct ssusb_mtk *ssusb)
+static inline void ssusb_wakeup_set(struct ssusb_mtk *ssusb, bool enable)
{}
#endif
--
2.9.0
^ permalink raw reply related
* [PATCH 2/2] cpufreq: scpi: remove arm_big_little dependency
From: Sudeep Holla @ 2018-01-10 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110144631.GE3626@vireshk-i7>
On 10/01/18 14:46, Viresh Kumar wrote:
> On 09-01-18, 16:49, Sudeep Holla wrote:
>> The dependency on physical_package_id from the topology to get the
>> cluster identifier is wrong. The concept of cluster used in ARM topology
>> is unfortunately not well defined in the architecture, we should avoid
>> using it. Further the frequency domain need not be mapped to so called
>> "clusters" one to one.
>>
>> SCPI already provides means to obtain the frequency domain id from the
>> device tree. In order to support some new topologies(e.g. DSU which
>> contains 2 frequency domains within the physical cluster), pseudo
>> clusters are created to make this driver work which is wrong again.
>>
>> In order to solve those issues and also remove dependency of topological
>> physical id for frequency domain, this patch removes the arm_big_little
>> dependency from scpi driver.
>>
>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>> Cc: Viresh Kumar <viresh.kumar@linaro.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> drivers/cpufreq/scpi-cpufreq.c | 193 +++++++++++++++++++++++++++++++++++++----
>> 1 file changed, 178 insertions(+), 15 deletions(-)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
Thanks :)
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 27/33] dma-direct: use node local allocations for coherent memory
From: Robin Murphy @ 2018-01-10 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110153017.GD17790@lst.de>
On 10/01/18 15:30, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 12:06:22PM +0000, Robin Murphy wrote:
>> On 10/01/18 08:00, Christoph Hellwig wrote:
>>> To preserve the x86 behavior.
>>
>> And combined with patch 10/22 of the SWIOTLB refactoring, this means
>> SWIOTLB allocations will also end up NUMA-aware, right? Great, that's what
>> we want on arm64 too :)
>
> Well, only for swiotlb allocations that can be satisfied by
> dma_direct_alloc. If we actually have to fall back to the swiotlb
> buffers there is not node affinity yet.
Yeah, when I looked into it I reached the conclusion that per-node
bounce buffers probably weren't worth it - if you have to bounce you've
already pretty much lost the performance game, and if the CPU doing the
bouncing happens to be on a different node from the device you've
certainly lost either way. Per-node CMA zones we definitely *would*
like, but that's a future problem (it looks technically feasible without
huge infrastructure changes, but fiddly).
Robin.
^ permalink raw reply
* [PATCH v2 0/6] ARM branch predictor hardening
From: Nishanth Menon @ 2018-01-10 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108185533.9698-1-marc.zyngier@arm.com>
On 01/08/2018 12:55 PM, Marc Zyngier wrote:
> This small series implements some basic BP hardening by invalidating
> the BTB on CPUs that are known to be susceptible to aliasing attacks.
>
> These patches are closely modelled against what we do on arm64,
> although simpler as we can rely on an architected instruction to
> perform the invalidation. The notable exception is Cortex-A15, where
> BTB invalidation behaves like a NOP, and the only way to shoot the
> predictor down is to invalidate the icache *and* to have ACTLR[0] set
> to 1 (which is a secure-only operation).
>
btw, just wanted to understand if we had any reasons as to why
we'arent tagging these for stable? Yes, I am aware of Greg's comments
in [1], but the v7 series impacts a heck of a lot of existing products
and is not that extensive to cause too much of a pain is it?
OR, am I missing some thing else?
[1] http://www.kroah.com/log/blog/2018/01/06/meltdown-status/
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 0/2] 2c: mv64xxx: Fix clock resource for Armada 7K/8K
From: Gregory CLEMENT @ 2018-01-10 16:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This short series fixes the way the clocks are used for the mv64xxx
controller embedded in the Marvell Armada 7K/8K SoCs. On these SoCs a
second one is needed in order to clock the registers. It was not
noticed until now because we relied on the bootloader and also because
the clock driver was wrong.
Thanks to this fix, it would be possible to fix the clock driver
without introducing a regression.
The first patch is just a small cleanup found when I wrote the main
patch.
Thanks,
Gregory
Gregory CLEMENT (2):
i2c: mv64xxx: Remove useless test before clk_disable_unprepare
i2c: mv64xxx: Fix clock resource by adding an optional bus clock
drivers/i2c/busses/i2c-mv64xxx.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH 1/2] i2c: mv64xxx: Remove useless test before clk_disable_unprepare
From: Gregory CLEMENT @ 2018-01-10 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110165147.26605-1-gregory.clement@free-electrons.com>
The 2 functions called from clk_disable_unprepare() already check that
the clock pointer is valid: no need to test it before calling it.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/i2c/busses/i2c-mv64xxx.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index a832c45276a4..f69066266faa 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -950,9 +950,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
exit_reset:
reset_control_assert(drv_data->rstc);
exit_clk:
- /* Not all platforms have a clk */
- if (!IS_ERR(drv_data->clk))
- clk_disable_unprepare(drv_data->clk);
+ clk_disable_unprepare(drv_data->clk);
return rc;
}
@@ -965,9 +963,7 @@ mv64xxx_i2c_remove(struct platform_device *dev)
i2c_del_adapter(&drv_data->adapter);
free_irq(drv_data->irq, drv_data);
reset_control_assert(drv_data->rstc);
- /* Not all platforms have a clk */
- if (!IS_ERR(drv_data->clk))
- clk_disable_unprepare(drv_data->clk);
+ clk_disable_unprepare(drv_data->clk);
return 0;
}
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Gregory CLEMENT @ 2018-01-10 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110165147.26605-1-gregory.clement@free-electrons.com>
On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
is optional because not all the SoCs need them but at least for Armada
7K/8K it is actually mandatory.
The binding documentation is updating accordingly.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/i2c/busses/i2c-mv64xxx.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index f69066266faa..cce37d8ecf41 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -135,6 +135,7 @@ struct mv64xxx_i2c_data {
u32 freq_m;
u32 freq_n;
struct clk *clk;
+ struct clk *axi_clk;
wait_queue_head_t waitq;
spinlock_t lock;
struct i2c_msg *msg;
@@ -894,13 +895,20 @@ mv64xxx_i2c_probe(struct platform_device *pd)
init_waitqueue_head(&drv_data->waitq);
spin_lock_init(&drv_data->lock);
- /* Not all platforms have a clk */
+ /* Not all platforms have clocks */
drv_data->clk = devm_clk_get(&pd->dev, NULL);
if (IS_ERR(drv_data->clk) && PTR_ERR(drv_data->clk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
if (!IS_ERR(drv_data->clk))
clk_prepare_enable(drv_data->clk);
+ drv_data->axi_clk = devm_clk_get(&pd->dev, "axi");
+ if (IS_ERR(drv_data->axi_clk) &&
+ PTR_ERR(drv_data->axi_clk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ if (!IS_ERR(drv_data->axi_clk))
+ clk_prepare_enable(drv_data->axi_clk);
+
drv_data->irq = platform_get_irq(pd, 0);
if (pdata) {
@@ -950,6 +958,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
exit_reset:
reset_control_assert(drv_data->rstc);
exit_clk:
+ clk_disable_unprepare(drv_data->axi_clk);
clk_disable_unprepare(drv_data->clk);
return rc;
@@ -963,6 +972,7 @@ mv64xxx_i2c_remove(struct platform_device *dev)
i2c_del_adapter(&drv_data->adapter);
free_irq(drv_data->irq, drv_data);
reset_control_assert(drv_data->rstc);
+ clk_disable_unprepare(drv_data->axi_clk);
clk_disable_unprepare(drv_data->clk);
return 0;
--
2.15.1
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: imx6ul-evk: Add support for mag3110 sensor
From: Fabio Estevam @ 2018-01-10 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515498385-23198-1-git-send-email-marco.franchi@nxp.com>
On Tue, Jan 9, 2018 at 9:46 AM, Marco Franchi <marco.franchi@nxp.com> wrote:
> The i.MX 6UL EVK has a MAG3110 Magnetometer sensor in its base board.
> Add support for this sensor, which is included in the trivial i2c devices
> and according to the bindings documentation, just need a compatible field
> and an address.
>
> Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 2/3] ARM: imx: Update imx_v6_v7_defconfig for mag3110 support
From: Fabio Estevam @ 2018-01-10 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515498385-23198-2-git-send-email-marco.franchi@nxp.com>
On Tue, Jan 9, 2018 at 9:46 AM, Marco Franchi <marco.franchi@nxp.com> wrote:
> The i.MX 6UL EVK has support for the MAG3110 Magnetometer sensor, included
> in its base board by default.
>
> So add support for this Magnetometer in the imx_v6_v7_defconfig.
>
> Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 3/3] ARM: dts: imx7d-sdb: Add support for mpl3115 sensor
From: Fabio Estevam @ 2018-01-10 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515498385-23198-3-git-send-email-marco.franchi@nxp.com>
On Tue, Jan 9, 2018 at 9:46 AM, Marco Franchi <marco.franchi@nxp.com> wrote:
> The i.MX 7D SDB has a MPL3115 Pressure sensor.
> Add support for this sensor, which is included in the trivial i2c devices
> and according to the bindings documentation, just need a compatible field
> and an address.
>
> Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Thomas Petazzoni @ 2018-01-10 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110165147.26605-3-gregory.clement@free-electrons.com>
Hello,
On Wed, 10 Jan 2018 17:51:47 +0100, Gregory CLEMENT wrote:
> On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
> is optional because not all the SoCs need them but at least for Armada
> 7K/8K it is actually mandatory.
>
> The binding documentation is updating accordingly.
Seems like the binding documentation update is not part of this patch :)
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ 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