* [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection
From: Neil Armstrong @ 2016-10-21 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021155408.GR16974@lunn.ch>
On 10/21/2016 05:54 PM, Andrew Lunn wrote:
> On Fri, Oct 21, 2016 at 04:40:33PM +0200, Neil Armstrong wrote:
>> The Meson GXL dwmac Glue Layer also provides switching between an external PHY
>> and an internal RMII 10/100 PHY.
>> Add a way to setup the correct PHY switching from a device tree attribute.
>
> Humm, actually. Maybe PHY_IS_INTERNAL in the phydrv->flags is the
> better solution. The MAC can then use phy_is_internal(ndev->phydev) to
> decide if this register needs programming.
>
> Andrew
>
Hi Andrew,
Yes this would be a good idea if we were able to scan the internal and external PHYs at the same time,
but with our limited knowledge the values we write in the register seems to switch a mux for the whole RMII
and MDIO signals to either interface.
Do you have knowledge if this case is already handled upstream ?
Thanks for your help,
Neil
^ permalink raw reply
* [PATCH 10/10] arm64: split thread_info from task stack
From: Mark Rutland @ 2016-10-21 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580A2B3A.7000300@arm.com>
Hi James,
On Fri, Oct 21, 2016 at 03:50:34PM +0100, James Morse wrote:
> > arch/arm64/kernel/entry.S | 4 ++--
>
> 4? That was too easy...
Indeed... ;)
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index 2d4c83b..e781391 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -123,6 +123,7 @@
> > * Set sp_el0 to current thread_info.
> > */
> > .if \el == 0
> > + ldr_this_cpu tsk, __entry_task, x21
> > msr sp_el0, tsk
> > .endif
> >
> > @@ -674,8 +675,7 @@ ENTRY(cpu_switch_to)
> > ldp x29, x9, [x8], #16
> > ldr lr, [x8]
> > mov sp, x9
> > - and x9, x9, #~(THREAD_SIZE - 1)
> > - msr sp_el0, x9
> > + msr sp_el0, x1
> > ret
> > ENDPROC(cpu_switch_to)
> >
>
> So now tsk is current instead of current_thread_info(), but we still access it
> with TI_* offsets:
Yes; luckily thread_info is the first member of task_struct, so this
works (as offsetof(struct task_struct, thread_info) == 0). The core code
also relies on this, e.g. in <linux/thread_info.h>:
#ifdef CONFIG_THREAD_INFO_IN_TASK
#define current_thread_info() ((struct thread_info *)current)
#endif
... regardless, I should have commented that, mentioned it in the commit
message, and perhaps put a BUILD_BUG_ON()-style assert somewhere. I'll
need to double-check, but IIRC I can't update asm-offsets to base the
TI_* offsets on task_struct without introducing a potential circular
include dependency.
I could at least s/TI_/TSK_/, with a comment.
> The 're-entered irq stack' check is going to need re-thinking:
> entry.S:195
> > /*
> > * Compare sp with the current thread_info, if the top
> > * ~(THREAD_SIZE - 1) bits match, we are on a task stack, and
> > * should switch to the irq stack.
> > */
> > and x25, x19, #~(THREAD_SIZE - 1)
> > cmp x25, tsk
> > b.ne 9998f
>
> It was done like this as the irq stack isn't naturally aligned, so this check
> implicitly assumes tsk is on the stack. I will try and come up with an alternative.
Ouch; I clearly didn't vet this thoroughly enough.
If we can corrupt another register here, we can load task_struct::stack
to compare against instead.
> And there are a few other things like this:
> entry.S:431
> > ldr w24, [tsk, #TI_PREEMPT] // get preempt count
> > cbnz w24, 1f // preempt count != 0
> > ldr x0, [tsk, #TI_FLAGS] // get flags
> > tbz x0, #TIF_NEED_RESCHED, 1f // needs rescheduling?
> > bl el1_preempt
>
> (It may be worth renaming the register alias 'tsk' as it isn't really a
> struct_task. This would catch any missed users at build time, including
> any patches in flight...)
Entertainingly, with these patches 'tsk' *is* task_struct, whereas
before it wasn't.
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index 2679722..cde25f4 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -149,6 +149,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> > * We need to tell the secondary core where to find its stack and the
> > * page tables.
> > */
> > + secondary_data.task = idle;
> > secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
> > update_cpu_boot_status(CPU_MMU_OFF);
> > __flush_dcache_area(&secondary_data, sizeof(secondary_data));
> > @@ -173,6 +174,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> > pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
> > }
> >
> > + secondary_data.task = NULL;
> > secondary_data.stack = NULL;
> > status = READ_ONCE(secondary_data.status);
> > if (ret && status) {
> >
>
> Nit-territory: Something we should remember is that __entry_task isn't written
> on secondary startup, so its stale (CPU0s idle task) until the first
> __switch_to(). This isn't a problem as its only read on entry from EL0.
Good point. I think I can initialise this in the hotplug path, if
nothing else but to save us any surprises when debugging.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 5/5] irqchip: st: Remove obsolete platforms from dt binding doc
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-1-git-send-email-patrice.chotard@st.com>
From: Patrice Chotard <patrice.chotard@st.com>
STiH415/6 SoC support is being removed from the kernel.
This patch updates the sti irchip and removes
references to these obsolete platforms.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: <tglx@linutronix.de>
Cc: <jason@lakedaemon.net>
Cc: <marc.zyngier@arm.com>
---
.../devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
index ced6014..23d1e1c 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/st,sti-irq-syscfg.txt
@@ -7,8 +7,6 @@ This driver is used to unmask them prior to use.
Required properties:
- compatible : Should be set to one of:
- "st,stih415-irq-syscfg"
- "st,stih416-irq-syscfg"
"st,stih407-irq-syscfg"
"st,stid127-irq-syscfg"
- st,syscfg : Phandle to Cortex-A9 IRQ system config registers
@@ -25,8 +23,8 @@ Optional properties:
Example:
irq-syscfg {
- compatible = "st,stih416-irq-syscfg";
- st,syscfg = <&syscfg_cpu>;
+ compatible = "st,stih407-irq-syscfg";
+ st,syscfg = <&syscfg_core>;
st,irq-device = <ST_IRQ_SYSCFG_PMU_0>,
<ST_IRQ_SYSCFG_PMU_1>;
st,fiq-device = <ST_IRQ_SYSCFG_DISABLED>,
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] irqchip: st: remove STiH415/416 irqchip support
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-1-git-send-email-patrice.chotard@st.com>
From: Patrice Chotard <patrice.chotard@st.com>
Support for STiH415/6 SoCs is being removed from the
kernel because the platforms are obsolete. This patch removes
the irqchip for these SoC's.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: <tglx@linutronix.de>
Cc: <jason@lakedaemon.net>
Cc: <marc.zyngier@arm.com>
---
drivers/irqchip/irq-st.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/irqchip/irq-st.c b/drivers/irqchip/irq-st.c
index 9af48a8..3ac9226 100644
--- a/drivers/irqchip/irq-st.c
+++ b/drivers/irqchip/irq-st.c
@@ -18,8 +18,6 @@
#include <linux/regmap.h>
#include <linux/slab.h>
-#define STIH415_SYSCFG_642 0x0a8
-#define STIH416_SYSCFG_7543 0x87c
#define STIH407_SYSCFG_5102 0x198
#define STID127_SYSCFG_734 0x088
@@ -48,14 +46,6 @@ struct st_irq_syscfg {
static const struct of_device_id st_irq_syscfg_match[] = {
{
- .compatible = "st,stih415-irq-syscfg",
- .data = (void *)STIH415_SYSCFG_642,
- },
- {
- .compatible = "st,stih416-irq-syscfg",
- .data = (void *)STIH416_SYSCFG_7543,
- },
- {
.compatible = "st,stih407-irq-syscfg",
.data = (void *)STIH407_SYSCFG_5102,
},
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] ARM: multi_v7_defconfig: Remove CONFIG_ST_THERMAL_MEMMAP Kconfig symbol
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-1-git-send-email-patrice.chotard@st.com>
From: Patrice Chotard <patrice.chotard@st.com>
Driver code has been already removed, see
http://www.spinics.net/lists/devicetree/msg143322.html
Remove the multi_v7_defconfig part
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: <rui.zhang@intel.com>
Cc: <edubezval@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 15b2f99..45e252b 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -450,7 +450,6 @@ CONFIG_RCAR_THERMAL=y
CONFIG_ARMADA_THERMAL=y
CONFIG_DAVINCI_WATCHDOG=m
CONFIG_EXYNOS_THERMAL=m
-CONFIG_ST_THERMAL_MEMMAP=y
CONFIG_WATCHDOG=y
CONFIG_DA9063_WATCHDOG=m
CONFIG_XILINX_WATCHDOG=y
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-1-git-send-email-patrice.chotard@st.com>
From: Patrice Chotard <patrice.chotard@st.com>
STiH415/6 SoC support is being removed from the kernel and
was the only platform using this Kconfig symbol
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: <rui.zhang@intel.com>
Cc: <edubezval@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 437d074..15b2f99 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -450,7 +450,6 @@ CONFIG_RCAR_THERMAL=y
CONFIG_ARMADA_THERMAL=y
CONFIG_DAVINCI_WATCHDOG=m
CONFIG_EXYNOS_THERMAL=m
-CONFIG_ST_THERMAL_SYSCFG=y
CONFIG_ST_THERMAL_MEMMAP=y
CONFIG_WATCHDOG=y
CONFIG_DA9063_WATCHDOG=m
--
1.9.1
^ permalink raw reply related
* [PATCH 1/5] thermal: st_thermal_syscfg: Remove obsolete STiH415/416 platform support.
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477065443-10668-1-git-send-email-patrice.chotard@st.com>
From: Patrice Chotard <patrice.chotard@st.com>
STiH415/6 SoC support is being removed from the kernel.
This patch removes support from the syscfg thermal driver.
This driver also supports STiD127 SoC which has never been
upstreamed.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Cc: <rui.zhang@intel.com>
Cc: <edubezval@gmail.com>
---
drivers/thermal/st/Kconfig | 4 -
drivers/thermal/st/Makefile | 1 -
drivers/thermal/st/st_thermal_syscfg.c | 178 ---------------------------------
3 files changed, 183 deletions(-)
delete mode 100644 drivers/thermal/st/st_thermal_syscfg.c
diff --git a/drivers/thermal/st/Kconfig b/drivers/thermal/st/Kconfig
index 490fdbe..ce84267 100644
--- a/drivers/thermal/st/Kconfig
+++ b/drivers/thermal/st/Kconfig
@@ -3,10 +3,6 @@ config ST_THERMAL
help
Support for thermal sensors on STMicroelectronics STi series of SoCs.
-config ST_THERMAL_SYSCFG
- select ST_THERMAL
- tristate "STi series syscfg register access based thermal sensors"
-
config ST_THERMAL_MEMMAP
select ST_THERMAL
tristate "STi series memory mapped access based thermal sensors"
diff --git a/drivers/thermal/st/Makefile b/drivers/thermal/st/Makefile
index b388789..27197e1 100644
--- a/drivers/thermal/st/Makefile
+++ b/drivers/thermal/st/Makefile
@@ -1,3 +1,2 @@
obj-$(CONFIG_ST_THERMAL) := st_thermal.o
-obj-$(CONFIG_ST_THERMAL_SYSCFG) += st_thermal_syscfg.o
obj-$(CONFIG_ST_THERMAL_MEMMAP) += st_thermal_memmap.o
diff --git a/drivers/thermal/st/st_thermal_syscfg.c b/drivers/thermal/st/st_thermal_syscfg.c
deleted file mode 100644
index 3df5b789..0000000
--- a/drivers/thermal/st/st_thermal_syscfg.c
+++ /dev/null
@@ -1,178 +0,0 @@
-/*
- * ST Thermal Sensor Driver for syscfg based sensors.
- * Author: Ajit Pal Singh <ajitpal.singh@st.com>
- *
- * Copyright (C) 2003-2014 STMicroelectronics (R&D) Limited
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include <linux/of.h>
-#include <linux/module.h>
-#include <linux/mfd/syscon.h>
-
-#include "st_thermal.h"
-
-/* STiH415 */
-#define STIH415_SYSCFG_FRONT(num) ((num - 100) * 4)
-#define STIH415_SAS_THSENS_CONF STIH415_SYSCFG_FRONT(178)
-#define STIH415_SAS_THSENS_STATUS STIH415_SYSCFG_FRONT(198)
-#define STIH415_SYSCFG_MPE(num) ((num - 600) * 4)
-#define STIH415_MPE_THSENS_CONF STIH415_SYSCFG_MPE(607)
-#define STIH415_MPE_THSENS_STATUS STIH415_SYSCFG_MPE(667)
-
-/* STiH416 */
-#define STIH416_SYSCFG_FRONT(num) ((num - 1000) * 4)
-#define STIH416_SAS_THSENS_CONF STIH416_SYSCFG_FRONT(1552)
-#define STIH416_SAS_THSENS_STATUS1 STIH416_SYSCFG_FRONT(1554)
-#define STIH416_SAS_THSENS_STATUS2 STIH416_SYSCFG_FRONT(1594)
-
-/* STiD127 */
-#define STID127_SYSCFG_CPU(num) ((num - 700) * 4)
-#define STID127_THSENS_CONF STID127_SYSCFG_CPU(743)
-#define STID127_THSENS_STATUS STID127_SYSCFG_CPU(767)
-
-static const struct reg_field st_415sas_regfields[MAX_REGFIELDS] = {
- [TEMP_PWR] = REG_FIELD(STIH415_SAS_THSENS_CONF, 9, 9),
- [DCORRECT] = REG_FIELD(STIH415_SAS_THSENS_CONF, 4, 8),
- [OVERFLOW] = REG_FIELD(STIH415_SAS_THSENS_STATUS, 8, 8),
- [DATA] = REG_FIELD(STIH415_SAS_THSENS_STATUS, 10, 16),
-};
-
-static const struct reg_field st_415mpe_regfields[MAX_REGFIELDS] = {
- [TEMP_PWR] = REG_FIELD(STIH415_MPE_THSENS_CONF, 8, 8),
- [DCORRECT] = REG_FIELD(STIH415_MPE_THSENS_CONF, 3, 7),
- [OVERFLOW] = REG_FIELD(STIH415_MPE_THSENS_STATUS, 9, 9),
- [DATA] = REG_FIELD(STIH415_MPE_THSENS_STATUS, 11, 18),
-};
-
-static const struct reg_field st_416sas_regfields[MAX_REGFIELDS] = {
- [TEMP_PWR] = REG_FIELD(STIH416_SAS_THSENS_CONF, 9, 9),
- [DCORRECT] = REG_FIELD(STIH416_SAS_THSENS_CONF, 4, 8),
- [OVERFLOW] = REG_FIELD(STIH416_SAS_THSENS_STATUS1, 8, 8),
- [DATA] = REG_FIELD(STIH416_SAS_THSENS_STATUS2, 10, 16),
-};
-
-static const struct reg_field st_127_regfields[MAX_REGFIELDS] = {
- [TEMP_PWR] = REG_FIELD(STID127_THSENS_CONF, 7, 7),
- [DCORRECT] = REG_FIELD(STID127_THSENS_CONF, 2, 6),
- [OVERFLOW] = REG_FIELD(STID127_THSENS_STATUS, 9, 9),
- [DATA] = REG_FIELD(STID127_THSENS_STATUS, 11, 18),
-};
-
-/* Private OPs for System Configuration Register based thermal sensors */
-static int st_syscfg_power_ctrl(struct st_thermal_sensor *sensor,
- enum st_thermal_power_state power_state)
-{
- return regmap_field_write(sensor->pwr, power_state);
-}
-
-static int st_syscfg_alloc_regfields(struct st_thermal_sensor *sensor)
-{
- struct device *dev = sensor->dev;
-
- sensor->pwr = devm_regmap_field_alloc(dev, sensor->regmap,
- sensor->cdata->reg_fields[TEMP_PWR]);
-
- if (IS_ERR(sensor->pwr)) {
- dev_err(dev, "failed to alloc syscfg regfields\n");
- return PTR_ERR(sensor->pwr);
- }
-
- return 0;
-}
-
-static int st_syscfg_regmap_init(struct st_thermal_sensor *sensor)
-{
- sensor->regmap =
- syscon_regmap_lookup_by_compatible(sensor->cdata->sys_compat);
- if (IS_ERR(sensor->regmap)) {
- dev_err(sensor->dev, "failed to find syscfg regmap\n");
- return PTR_ERR(sensor->regmap);
- }
-
- return 0;
-}
-
-static const struct st_thermal_sensor_ops st_syscfg_sensor_ops = {
- .power_ctrl = st_syscfg_power_ctrl,
- .alloc_regfields = st_syscfg_alloc_regfields,
- .regmap_init = st_syscfg_regmap_init,
-};
-
-/* Compatible device data for stih415 sas thermal sensor */
-static const struct st_thermal_compat_data st_415sas_cdata = {
- .sys_compat = "st,stih415-front-syscfg",
- .reg_fields = st_415sas_regfields,
- .ops = &st_syscfg_sensor_ops,
- .calibration_val = 16,
- .temp_adjust_val = 20,
- .crit_temp = 120,
-};
-
-/* Compatible device data for stih415 mpe thermal sensor */
-static const struct st_thermal_compat_data st_415mpe_cdata = {
- .sys_compat = "st,stih415-system-syscfg",
- .reg_fields = st_415mpe_regfields,
- .ops = &st_syscfg_sensor_ops,
- .calibration_val = 16,
- .temp_adjust_val = -103,
- .crit_temp = 120,
-};
-
-/* Compatible device data for stih416 sas thermal sensor */
-static const struct st_thermal_compat_data st_416sas_cdata = {
- .sys_compat = "st,stih416-front-syscfg",
- .reg_fields = st_416sas_regfields,
- .ops = &st_syscfg_sensor_ops,
- .calibration_val = 16,
- .temp_adjust_val = 20,
- .crit_temp = 120,
-};
-
-/* Compatible device data for stid127 thermal sensor */
-static const struct st_thermal_compat_data st_127_cdata = {
- .sys_compat = "st,stid127-cpu-syscfg",
- .reg_fields = st_127_regfields,
- .ops = &st_syscfg_sensor_ops,
- .calibration_val = 8,
- .temp_adjust_val = -103,
- .crit_temp = 120,
-};
-
-static const struct of_device_id st_syscfg_thermal_of_match[] = {
- { .compatible = "st,stih415-sas-thermal", .data = &st_415sas_cdata },
- { .compatible = "st,stih415-mpe-thermal", .data = &st_415mpe_cdata },
- { .compatible = "st,stih416-sas-thermal", .data = &st_416sas_cdata },
- { .compatible = "st,stid127-thermal", .data = &st_127_cdata },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, st_syscfg_thermal_of_match);
-
-static int st_syscfg_probe(struct platform_device *pdev)
-{
- return st_thermal_register(pdev, st_syscfg_thermal_of_match);
-}
-
-static int st_syscfg_remove(struct platform_device *pdev)
-{
- return st_thermal_unregister(pdev);
-}
-
-static struct platform_driver st_syscfg_thermal_driver = {
- .driver = {
- .name = "st_syscfg_thermal",
- .pm = &st_thermal_pm_ops,
- .of_match_table = st_syscfg_thermal_of_match,
- },
- .probe = st_syscfg_probe,
- .remove = st_syscfg_remove,
-};
-module_platform_driver(st_syscfg_thermal_driver);
-
-MODULE_AUTHOR("STMicroelectronics (R&D) Limited <ajitpal.singh@st.com>");
-MODULE_DESCRIPTION("STMicroelectronics STi SoC Thermal Sensor Driver");
-MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH 0/5] Remove STiH415/416 SoC platform support remaining parts
From: patrice.chotard at st.com @ 2016-10-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
From: Patrice Chotard <patrice.chotard@st.com>
ST have sent patches which remove clock support for these SoCs [1]
which once applied mean the platform will no longer boot.
This series cleans up remaining STi drivers which have
support for these SoC's, by removing code, and updating the DT
documentation accordingly. Some drivers such as st_thermal_syscfg
can be removed completely because the IP is only found on these
legacy SoC's.
Patrice Chotard (5):
thermal: st_thermal_syscfg: Remove obsolete STiH415/416 platform
support.
ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol
ARM: multi_v7_defconfig: Remove CONFIG_ST_THERMAL_MEMMAP Kconfig
symbol
irqchip: st: remove STiH415/416 irqchip support
irqchip: st: Remove obsolete platforms from dt binding doc
.../interrupt-controller/st,sti-irq-syscfg.txt | 6 +-
arch/arm/configs/multi_v7_defconfig | 2 -
drivers/irqchip/irq-st.c | 10 --
drivers/thermal/st/Kconfig | 4 -
drivers/thermal/st/Makefile | 1 -
drivers/thermal/st/st_thermal_syscfg.c | 178 ---------------------
6 files changed, 2 insertions(+), 199 deletions(-)
delete mode 100644 drivers/thermal/st/st_thermal_syscfg.c
--
1.9.1
^ permalink raw reply
* [PATCH V6 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Sinan Kaya @ 2016-10-21 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021065723.GA2467@localhost>
On 10/20/2016 11:57 PM, Vinod Koul wrote:
>> It looks like patches were applied out of order.
> When applying, if I get a conflict I try to skip them. Typically subsequent
> patches fail, sometimes they apply. I think couple of them did in this case
>
> It built for me, 0day also gave me success report, so unless we have bisect
> regression, I would like rest of the patches on top of this please..
>
OK. Let me work on it.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection
From: Andrew Lunn @ 2016-10-21 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477060838-14164-9-git-send-email-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 04:40:33PM +0200, Neil Armstrong wrote:
> The Meson GXL dwmac Glue Layer also provides switching between an external PHY
> and an internal RMII 10/100 PHY.
> Add a way to setup the correct PHY switching from a device tree attribute.
Humm, actually. Maybe PHY_IS_INTERNAL in the phydrv->flags is the
better solution. The MAC can then use phy_is_internal(ndev->phydev) to
decide if this register needs programming.
Andrew
^ permalink raw reply
* [PATCH 0/6] ARM: sun5i: chip: Misc improvements
From: Maxime Ripard @ 2016-10-21 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65L=Cf1EWgZ1YPyFA_g7aiqAGwNkC-e0vs3OM8BJ2OEbA@mail.gmail.com>
On Fri, Oct 21, 2016 at 11:02:23AM +0800, Chen-Yu Tsai wrote:
> On Mon, Oct 17, 2016 at 7:48 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > This is a bunch of patches I gathered for the CHIP, that enables a few
> > things, like the WiFi regulators (and its associated power sequence), a few
> > optional buses, etc.
Applied all with your Acked-by
> FYI this series makes more sense if you mention the Pocket CHIP DT overlays.
Not really, most of these patches are for the CHIP itself. The Pocket
CHIP, just like all the other DIPs so far, uses the LCD pins, but
that's pretty much the only DIP-specific patch there.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161021/81295753/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] ARM: convert to generated system call tables
From: Russell King - ARM Linux @ 2016-10-21 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4337157.Eff9E2riVH@wuerfel>
On Fri, Oct 21, 2016 at 05:18:30PM +0200, Arnd Bergmann wrote:
> On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
>
> > > If we hit this case, why not just use the wrapper on both EABI
> > > and OABI for simplicity? It's not like we care a lot about
> > > micro-optimizing OABI any more.
> >
> > I'd still like to retain the ability to only add to EABI in the future.
>
> Do you mean to add an EABI specific workaround for a specific syscall
> if necessary, or to stop adding OABI syscalls altogether?
To stop adding OABI syscalls altogether. I'm sure that there will
come a point (if it hasn't already) that glibc no longer supports
OABI, and at that point it probably becomes rather silly to keep
adding OABI syscalls.
> > > That brings up an interesting issue: it would be nice to use the
> > > same input file for arch/arm/ and the compat mode of arch/arm64,
> > > like x86 does. If we handle both oabi and arm64-compat in the same
> > > file, we end up with a superset of what x86 does, and we could
> > > use a single script again, and generate all four tables for
> > > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
> >
> > OABI-compat != ARM64-EABI-compat though. They're two completely
> > different things.
>
> For the purpose of generating the tables, I don't see much
> difference: we either use the fourth column only in native
> mode, or we use the fifth column to override values from
> the fourth one when emulating the ABI on the "other" kernel.
The table generation method can be shared, but I've no idea about the
feasibility of sharing the table between ARM64 and ARM - I don't know
enough about ARM64 to know whether things like an "long" argument to
a syscall (which would be 64-bit on ARM64) would be or would not be a
problem if called from a 32-bit user application.
I've zero knowledge of the whole 32-bit application on 64-bit CPUs
thing, so it's pointless trying to discuss this aspect with me. Even
for x86, all I care there is that it works, I've no knowledge of how
it works.
> That's similar to x86, 32-bit syscalls use the traditional numbers
> with an optionally different entry point for compat mode, while
> 64-bit syscalls use a somewhat reduced table that now has support
> for both native 64-bit and "x32" mode. x86-64 and x32 share a
> syscall table but not the unistd.h list, all three generated
> from syscall_64.tbl.
What's the point of the x32 mode?
> ARM64 has a separate list of syscalls for compat mode in
> arch/arm64/include/asm/unistd32.h, this list has the same format
> as include/asm-generic/uapi/unistd.h and must be updated manually
> to match the arch/arm/ table today.
Looking through it, sort-of. It could have re-used the numbering
from the arch/arm include file, but because ARM64 wanted to be an
entirely separate architecture, it duplicates a lot from 32-bit ARM.
I pointed that out at the time, and was shouted down (which is why
today I have absolutely nothing to do with ARM64, and as a result
have very little knowledge about ARM64 - I lost interest in it as
a result of the responses I got to my comments.)
So... if you don't mind, this isn't an issue I care one iota about.
In order for something to work like what you're alluding to, ARM64
would have to ferret around in arch/arm to pull out the bits it
wants, and I see zero reason for that to be acceptable on either
side of the ARM64 vs ARM divide - it will make my job harder because
I'm then into the position where I need acks from ARM64 people to
change ARM code, and that doesn't interest me at all. I'm not going
to put myself into a position where I'm at the mercy of ARM64 folk.
--
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 01/23] reset: Add renesas,rst DT bindings
From: Philipp Zabel @ 2016-10-21 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477055857-17936-2-git-send-email-geert+renesas@glider.be>
Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Add DT bindings for the Renesas R-Car Reset Controller (R-Car Gen1
> RESET/WDT and R-Car Gen2/Gen3 and RZ/G RST).
>
> As the features provided by the hardware module differ a lot across the
> various SoC families and members, only SoC-specific compatible values
> are defined.
>
> For now we use the RST only for providing access to the state of the
> mode pins, which is needed by the clock driver.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Magnus Damm <damm+renesas@opensource.se>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v4:
> - Add Acked-by,
> - Fix comma and period in list,
> - Add RZ/G1M and RZ/G1E,
>
> v3:
> - Clarify current usage,
> - Use "renesas,<soctype>-rst" instead of "renesas,rst-<soctype>",
> - Drop "syscon" compatible value,
> - Add R-Car M3-W,
> - Add R-Car Gen1,
>
> v2:
> - Add Acked-by.
> ---
> .../devicetree/bindings/reset/renesas,rst.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/renesas,rst.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.txt b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> new file mode 100644
> index 0000000000000000..fe5e0f37b3c93579
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
> @@ -0,0 +1,37 @@
> +DT bindings for the Renesas R-Car and RZ/G Reset Controllers
> +
> +The R-Car and RZ/G Reset Controllers provide reset control, and implement the
> +following functions:
> + - Latching of the levels on mode pins when PRESET# is negated,
> + - Mode monitoring register,
> + - Reset control of peripheral devices (on R-Car Gen1),
> + - Watchdog timer (on R-Car Gen1),
> + - Register-based reset control and boot address registers for the various CPU
> + cores (on R-Car Gen2 and Gen3, and on RZ/G).
> +
> +
> +Required properties:
> + - compatible: Should be
> + - "renesas,<soctype>-reset-wdt" for R-Car Gen1,
> + - "renesas,<soctype>-rst" for R-Car Gen2 and Gen3, and RZ/G
> + Examples with soctypes are:
> + - "renesas,r8a7743-rst" (RZ/G1M)
> + - "renesas,r8a7745-rst" (RZ/G1E)
> + - "renesas,r8a7778-reset-wdt" (R-Car M1A)
> + - "renesas,r8a7779-reset-wdt" (R-Car H1)
> + - "renesas,r8a7790-rst" (R-Car H2)
> + - "renesas,r8a7791-rst" (R-Car M2-W)
> + - "renesas,r8a7792-rst" (R-Car V2H
> + - "renesas,r8a7793-rst" (R-Car M2-N)
> + - "renesas,r8a7794-rst" (R-Car E2)
> + - "renesas,r8a7795-rst" (R-Car H3)
> + - "renesas,r8a7796-rst" (R-Car M3-W)
> + - reg: Address start and address range for the device.
> +
> +
> +Example:
> +
> + rst: reset-controller at e6160000 {
> + compatible = "renesas,r8a7795-rst";
> + reg = <0 0xe6160000 0 0x0200>;
> + };
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Philipp Zabel @ 2016-10-21 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477064730.2508.24.camel@pengutronix.de>
Am Freitag, den 21.10.2016, 17:45 +0200 schrieb Philipp Zabel:
> A. Hi Geert,
>
> Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> > Hi Philipp, Mike, Stephen, Simon, Magnus,
> > (see questions *** below!)
> >
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> >
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> >
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module. Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
>
> I think you should add a binding doc even though the DT bindings are
> still trivial.
Disregard that, I literally sent this mail and a second later noticed
patch 1 for the first time.
regards
Philipp
^ permalink raw reply
* [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection
From: Andrew Lunn @ 2016-10-21 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477060838-14164-9-git-send-email-narmstrong@baylibre.com>
On Fri, Oct 21, 2016 at 04:40:33PM +0200, Neil Armstrong wrote:
> The Meson GXL dwmac Glue Layer also provides switching between an external PHY
> and an internal RMII 10/100 PHY.
> Add a way to setup the correct PHY switching from a device tree attribute.
Hi Neil
Can this be made automatic?
The internal PHY appears to be on address 8. Can there also be an
external PHY on address 8? Could you follow the phy-handle link to the
phy node, check the address, and if it is 8, configure for an internal
PHY?
Andrew
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Philipp Zabel @ 2016-10-21 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477055857-17936-1-git-send-email-geert+renesas@glider.be>
A. Hi Geert,
Am Freitag, den 21.10.2016, 15:17 +0200 schrieb Geert Uytterhoeven:
> Hi Philipp, Mike, Stephen, Simon, Magnus,
> (see questions *** below!)
>
> Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> state of the mode pins either by a call from the platform code, or
> directly by using a hardcoded register access. This is a bit messy, and
> creates a dependency between driver and platform code.
>
> This patch series converts the various Renesas R-Car clock drivers
> and support code from reading the mode pin states using a hardcoded
> register access to using a new minimalistic R-Car RST driver.
>
> All R-Car clock drivers will rely on the presence in DT of a device node
> for the RST module. Backwards compatibility with old DTBs is retained
> only for R-Car Gen2, which has fallback code using its own private copy
> of rcar_gen2_read_mode_pins().
I think you should add a binding doc even though the DT bindings are
still trivial.
> After this, there is still one remaining user of
> rcar_gen2_read_mode_pins() left in platform code. A patch series to
> remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
>
> This series consists of 5 parts:
> A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> driver,
> B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> files,
> C. Patches 12-17 convert the clock drivers to call into the new R-Car
> RST driver,
> D. Patches 18-20 remove passing mode pin state to the clock drivers
> from the platform code,
> E. Patches 21-23 remove dead code from the clock drivers.
>
> As is usually the case with moving functionality from platform code to
> DT, there are lots of hard dependencies:
> - The DT updates in Part B can be merged as soon as the DT bindings in
> Part A have been approved,
> - The clock driver updates in Part C depend functionally on the driver
> code in Part A, and on the DT updates in Part B,
> - The board code cleanups in Part D depend on the clock driver updates
> in Part C,
> - The block driver cleanups in part E depend on the board code
> cleanups in part D.
>
> Hence to maintain the required lockstep between SoC driver, clock
> drivers, shmobile platform code, and shmobile DT, I propose to queue up
> all patches in a single branch against v4.9-rc1, and send pull requests
> to both Mike/Stephen (clock) and Simon (rest).
>
> ***
>
> - Philip: While this is a driver for a reset-controller, currently it
> doesn't provide any reset-controller functionality. Hence I added it
> to drivers/soc/renesas/. Is that OK for you?
Absolutely, as long as the driver isn't even a reset controller
provider, this is the right place.
regards
Philipp
^ permalink raw reply
* [PATCH] PCI: layerscape: Fix kernel panic on accessing NULL pointer
From: Bjorn Helgaas @ 2016-10-21 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476740647-11155-1-git-send-email-leoyang.li@nxp.com>
On Mon, Oct 17, 2016 at 04:44:06PM -0500, Li Yang wrote:
> Commit fefe6733e added reference to the pcie->drvdata before it is
> initialized which causes a kernel panic. Fix the problem by
> initializing the pcie->drvdata earlier before it is used.
>
> Reported-by: Stuart Yoder <stuart.yoder@nxp.com>
> Signed-off-by: Li Yang <leoyang.li@nxp.com>
I applied Marc Zyngier's identical patch to for-linus for v4.9. I don't
know which was posted first, but I saw Marc's first. Sorry I didn't at
least credit you when I applied it.
> ---
> drivers/pci/host/pci-layerscape.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
> index 2cb7315..958187f 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -245,6 +245,7 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
> if (!pcie)
> return -ENOMEM;
>
> + pcie->drvdata = match->data;
> pp = &pcie->pp;
> pp->dev = dev;
> pp->ops = pcie->drvdata->ops;
> @@ -256,7 +257,6 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
> return PTR_ERR(pcie->pp.dbi_base);
> }
>
> - pcie->drvdata = match->data;
> pcie->lut = pcie->pp.dbi_base + pcie->drvdata->lut_offset;
>
> if (!ls_pcie_is_bridge(pcie))
> --
> 1.9.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/4] ARM: boot: mxs: Add On-Chip RAM
From: Stefan Wahren @ 2016-10-21 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e472fb62-00d2-359d-2126-ce2727fe3bed@i2se.com>
Am 21.10.2016 um 17:24 schrieb Stefan Wahren:
> Am 21.10.2016 um 17:03 schrieb Shawn Guo:
>> On Fri, Oct 21, 2016 at 04:05:59PM +0200, Stefan Wahren wrote:
>>> Am 21.10.2016 um 15:53 schrieb Shawn Guo:
>>>> On Tue, Sep 13, 2016 at 05:51:02PM +0000, Stefan Wahren wrote:
>>>>> The i.MX23 / i.MX28 have a small amount of On-Chip RAM which is also necessary
>>>>> for suspend to RAM and standby mode. But before we need to remove the fake reg
>>>>> properties of all internal bus nodes as discussed in this thread [1].
>>>>>
>>>>> This patch series requires Fabio Estevam's recent series "ARM: dts: imx23:
>>>>> Remove skeleton.dtsi inclusion" [2].
>>>>>
>>>>> [1] - https://marc.info/?l=devicetree&m=146139948426520&w=2
>>>> The page cannot be reached. I would like to understand the
>>>> background for this change.
>>> Strange, because i don't have any problems while clicking on the URL.
>>>
>>> It's an older discussion on the devicetree / kernel newbie mailing list
>>> with subject "strange dtc errors after adding sram node". Arnd suggested
>>> in the discussion to remove the reg property from the ahb node.
>>>
>>> Please try this one: http://www.spinics.net/lists/newbies/msg57652.html
>> If you go through 'Table 4-1. Address Map for i.MX28' of MCIMX28RM, you
>> should be able to find there are 3 AHB buses: ahb at 0, ahb at 80080000 and
>> ahb at c0000000. The ocram goes to ahb at 0. The following change should be
>> the right one for ocram addition.
> Correct me if i'm wrong, but there is only one AHB bus and only the
> connected peripheral devices like ocram or USB controller have a memory
> mapped start address not the bus itself.
Please forget about that. According to the reference manual there are 3
AHB bus layers.
>
>> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
>> index 0ad893bf5f43..8e5718df06b2 100644
>> --- a/arch/arm/boot/dts/imx28.dtsi
>> +++ b/arch/arm/boot/dts/imx28.dtsi
>> @@ -47,6 +47,19 @@
>> };
>> };
>>
>> + ahb at 0 {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + reg = <0x0 0x80000000>;
>> + ranges;
>> +
>> + ocram: sram at 0 {
>> + compatible = "mmio-sram";
>> + reg = <0x0 0x20000>;
>> + };
>> + };
>> +
>> apb at 80000000 {
>> compatible = "simple-bus";
>> #address-cells = <1>;
>>
>
--
Software-Entwickler / software developer
I2SE GmbH Tel: +49 (0) 341 355667-00
Friedrich-Ebert-Str. 61 Fax: +49 (0) 341 355667-02
04109 Leipzig
Germany
Web: http://www.i2se.com/ Mail: info at i2se.com
VAT No.: DE 811528334
Amtsgericht Leipzig HRB 23784
Gesch?ftsf?hrer/CEO: Carsten Ziermann
*** Diese E-Mail ist allein f?r den bezeichneten Adressaten bestimmt. Sie kann rechtlich vertrauliche Informationen enthalten. Wenn Sie diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte unverz?glich den Absender per E-Mail und l?schen Sie diese E-Mail von Ihrem Computer, ohne Kopien anzufertigen.
Vielen Dank. ***
*** This email is for the exclusive use of the addressee. It may contain legally privileged information. If you have received this message in error, please notify the sender by email immediately and delete the message from your computer without making any copies.
Thank you. ***
^ permalink raw reply
* [PATCH] dt-bindings: video: exynos7-decon: Remove obsolete samsung,power-domain property
From: Javier Martinez Canillas @ 2016-10-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e80b5ee-41a9-8c35-ff0d-e1b8b7a4e429@samsung.com>
On 10/21/2016 11:36 AM, Sylwester Nawrocki wrote:
> On 10/21/2016 04:05 PM, Krzysztof Kozlowski wrote:
>> The samsung,power-domain property is obsolete since commit 0da658704136
>> ("ARM: dts: convert to generic power domain bindings for exynos DT").
>> Replace it with generic one.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [RFC] ARM: dts: exynos: Remove exynos4415.dtsi
From: Javier Martinez Canillas @ 2016-10-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c8576159-347c-42df-6a8d-8620ba4be8a1@samsung.com>
On 10/21/2016 11:33 AM, Sylwester Nawrocki wrote:
> On 10/21/2016 04:15 PM, Krzysztof Kozlowski wrote:
>> There are no boards in mainline using exynos4415.dtsi. This is DTS
>> was not tested for long. I am also not aware of any popular out-of-tree
>> boards using this (except consumer devices released by Samsung but those
>> cannot use mainline).
>>
>> Keeping Exynos4415 costs some useless effort so remove it.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> It seems a sane thing to do, I don't know of any active platform that
> uses Exynos4415.
>
> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 0/4] ARM: boot: mxs: Add On-Chip RAM
From: Stefan Wahren @ 2016-10-21 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021150336.GJ30578@tiger>
Am 21.10.2016 um 17:03 schrieb Shawn Guo:
> On Fri, Oct 21, 2016 at 04:05:59PM +0200, Stefan Wahren wrote:
>> Am 21.10.2016 um 15:53 schrieb Shawn Guo:
>>> On Tue, Sep 13, 2016 at 05:51:02PM +0000, Stefan Wahren wrote:
>>>> The i.MX23 / i.MX28 have a small amount of On-Chip RAM which is also necessary
>>>> for suspend to RAM and standby mode. But before we need to remove the fake reg
>>>> properties of all internal bus nodes as discussed in this thread [1].
>>>>
>>>> This patch series requires Fabio Estevam's recent series "ARM: dts: imx23:
>>>> Remove skeleton.dtsi inclusion" [2].
>>>>
>>>> [1] - https://marc.info/?l=devicetree&m=146139948426520&w=2
>>> The page cannot be reached. I would like to understand the
>>> background for this change.
>> Strange, because i don't have any problems while clicking on the URL.
>>
>> It's an older discussion on the devicetree / kernel newbie mailing list
>> with subject "strange dtc errors after adding sram node". Arnd suggested
>> in the discussion to remove the reg property from the ahb node.
>>
>> Please try this one: http://www.spinics.net/lists/newbies/msg57652.html
> If you go through 'Table 4-1. Address Map for i.MX28' of MCIMX28RM, you
> should be able to find there are 3 AHB buses: ahb at 0, ahb at 80080000 and
> ahb at c0000000. The ocram goes to ahb at 0. The following change should be
> the right one for ocram addition.
Correct me if i'm wrong, but there is only one AHB bus and only the
connected peripheral devices like ocram or USB controller have a memory
mapped start address not the bus itself.
>
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 0ad893bf5f43..8e5718df06b2 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -47,6 +47,19 @@
> };
> };
>
> + ahb at 0 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x0 0x80000000>;
> + ranges;
> +
> + ocram: sram at 0 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x20000>;
> + };
> + };
> +
> apb at 80000000 {
> compatible = "simple-bus";
> #address-cells = <1>;
>
^ permalink raw reply
* [PATCH v3 8/8] PM / doc: Update device documentation for devices in IRQ safe PM domains
From: Lina Iyer @ 2016-10-21 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0hP9QNSqU053keCgY-LEGAyOiOT_vuUK71Oa6i3f7pycg@mail.gmail.com>
On Fri, Oct 21 2016 at 07:07 -0600, Rafael J. Wysocki wrote:
>On Fri, Oct 14, 2016 at 7:47 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Update documentation to reflect the changes made to support IRQ safe PM
>> domains.
>>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
>> ---
>> Documentation/power/devices.txt | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
>> index 8ba6625..0401b53 100644
>> --- a/Documentation/power/devices.txt
>> +++ b/Documentation/power/devices.txt
>> @@ -607,7 +607,14 @@ individually. Instead, a set of devices sharing a power resource can be put
>> into a low-power state together at the same time by turning off the shared
>> power resource. Of course, they also need to be put into the full-power state
>> together, by turning the shared power resource on. A set of devices with this
>> -property is often referred to as a power domain.
>> +property is often referred to as a power domain. A power domain may also be
>> +nested inside another power domain.
>> +
>> +Devices and PM domains may be defined as IRQ-safe, if they can be powered
>> +on/off even when the IRQs are disabled. An IRQ-safe device in a domain will
>> +disallow power management on the domain, unless the domain is also defined as
>> +IRQ-safe. The restriction this framework imposes on the parent domain of an
>> +IRQ-safe domain is that it must also be defined as IRQ-safe.
>
>I would put this paragraph below, before the last paragraph in the section.
>
OK.
>Also I suppose that a domain should only be defined as "IRQ-safe" if
>all of the devices in it are "IRQ-safe" (or there will be problems at
>least in principle). If that is the case, it should be stated clearly
>in the paragraph you are adding as well.
>
Will add.
Thanks,
Lina
^ permalink raw reply
* [PATCH] drm: convert DT component matching to component_match_add_release()
From: Russell King - ARM Linux @ 2016-10-21 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbJ64JOugR2b3R87pFRDGDVs9HM3uZJM2z1-jHyhPf6WOA@mail.gmail.com>
On Thu, Oct 20, 2016 at 07:15:56PM -0400, Sean Paul wrote:
> On Thu, Oct 20, 2016 at 5:50 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote:
> >> On Wed, Oct 19, 2016 at 6:28 AM, Russell King
> >> <rmk+kernel@armlinux.org.uk> wrote:
> >> > Convert DT component matching to use component_match_add_release().
> >> >
> >> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> >> > ---
> >> > Can we please get this patch from May merged into the drm-misc or
> >> > whatever trees so that we don't end up with conflicts? I've no idea
> >> > who looks after drm-misc, as they have _still_ failed to add
> >> > themselves to MAINTAINERS.
> >>
> >> I think Daniel explained pretty clearly why this wasn't happening in
> >> the previous thread.
> >>
> >> Next time you send a v2, can you please mark it as such and include a
> >> "Changes in v2" section?
> >
> > Why - nothing's changed other than a rebase onto 4.9-rc1. This isn't
> > a "I've changed it in XYZ way, so here's a new copy".
>
>
> Changes in v2: None
>
> Is still useful since:
> a) the diffstat is different from v1, which necessitates me going
> through both versions to see what's changed from the previous reviews
> (only to find out myself that it's been rebased and a function has
> changed names)
Sorry, but I don't track in any fine detail what the changes are
between patches when I bring them forward: I have far too many patches
to do that (I have 300 right now) and I never know whether they're
going to result in a pull request or not. It means finding some way
to manually attach a change log to each patch I send out, which will
be very time consuming. I'd rather not send patches out than jump
through hoops like that, especially when the reason is that the
previous version was ignored.
> b) in June, you said you were going to roll a new version with the
> common OF bits extracted. it's nice to know at the outset that this
> has/hasn't happened
Now if you were following the rest of it, rather than just random parts
that suited you, you'd have noticed that I posted the new version, but
that caused more issues, so I publically said I was reverting back to
the original version.
> Also, prefacing the subject with [PATCH v2] or [PATCH RESEND] lets me
> know there is prior history with the change. Reading the previous
> version is helpful to see what reviewer's concerns were, and whether
> they've been addressed.
Yea, I'm very bad at changing the subject line in that way, and I'm
getting worse at it. Sorry, I try my best, but I can't do better than
that.
>
>
> > It's being
> > posted in the hope that someone will finally either comment on it or
> > merge the damn thing, rather than ignoring it was done when it was
> > last posted.
> >
> >> > drivers/gpu/drm/arm/hdlcd_drv.c | 3 ++-
> >> > drivers/gpu/drm/arm/malidp_drv.c | 4 +++-
> >> > drivers/gpu/drm/armada/armada_drv.c | 2 +-
> >> > drivers/gpu/drm/drm_of.c | 28 +++++++++++++++++++++++--
> >> > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 5 +++--
> >> > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 7 ++++---
> >> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +++-
> >> > drivers/gpu/drm/msm/msm_drv.c | 12 ++++++-----
> >> > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++++--
> >> > drivers/gpu/drm/sti/sti_drv.c | 5 +++--
> >> > drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
> >> > drivers/gpu/drm/tilcdc/tilcdc_external.c | 4 +++-
> >> > include/drm/drm_of.h | 12 +++++++++++
> >> > 13 files changed, 73 insertions(+), 22 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> >> > index fb6a418ce6be..6477d1a65266 100644
> >> > --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> >> > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> >> > @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
> >> > return -EAGAIN;
> >> > }
> >> >
> >> > - component_match_add(&pdev->dev, &match, compare_dev, port);
> >> > + drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
> >> > + of_node_put(port);
> >>
> >> There's no mention in your commit message about fixing these node leaks.
> >
> > Isn't that kind-of the whole point of this patch?
> >
>
> Not according to the commit msg, it isn't.
>
> You could have just done the of_node_put adds/relocations without
> wrapping component_match_add_release.
No, adding the of_node_put() there without the other changes means that
the OF layer can drop the "port" device node, kfree() it, and reallocate
it as a different device node - which means that we can end up matching
some random other device rather than the intended one. Hence, it is
_fundamentally_ a part of this patch and isn't an independent change.
--
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 2/3] ARM: convert to generated system call tables
From: Arnd Bergmann @ 2016-10-21 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021133708.GA1041@n2100.armlinux.org.uk>
On Friday, October 21, 2016 2:37:08 PM CEST Russell King - ARM Linux wrote:
> On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > If we hit this case, why not just use the wrapper on both EABI
> > and OABI for simplicity? It's not like we care a lot about
> > micro-optimizing OABI any more.
>
> I'd still like to retain the ability to only add to EABI in the future.
Do you mean to add an EABI specific workaround for a specific syscall
if necessary, or to stop adding OABI syscalls altogether?
For the first one, the way that the asm-generic unistd.h handles this is
to have a range of syscall numbers reserved for architecture specific
additions. I was planning to do the same here and have a number of
reserved numbers after the last architecture specific call before
the start of the newly added generic numbers.
> > (or alternatively, add "#define sync_file_range2 arm_sync_file_range"
> > to uapi/asm/unistd.h).
>
> Well, I think you have a mis-merge somewhere, beacuse uapi/asm/unistd.h
> does have:
>
> #define __NR_sync_file_range2 __NR_arm_sync_file_range
>
> in it, which triggers this in scripts/checksyscalls.sh:
That was it, I had merged in my y2038 syscall series for testing and
accidentally dropped that line while rebasing the newly added
syscalls.
> > That brings up an interesting issue: it would be nice to use the
> > same input file for arch/arm/ and the compat mode of arch/arm64,
> > like x86 does. If we handle both oabi and arm64-compat in the same
> > file, we end up with a superset of what x86 does, and we could
> > use a single script again, and generate all four tables for
> > ARM (native OABI, OABI-on-EABI, native EABI, EABI-on-arm64).
>
> OABI-compat != ARM64-EABI-compat though. They're two completely
> different things.
For the purpose of generating the tables, I don't see much
difference: we either use the fourth column only in native
mode, or we use the fifth column to override values from
the fourth one when emulating the ABI on the "other" kernel.
> Moreover, the syscall numbers ARM64 uses natively are completely
> different from the syscall numbers 32-bit ARM uses, either for EABI
> or OABI. So I really don't see this working.
That's similar to x86, 32-bit syscalls use the traditional numbers
with an optionally different entry point for compat mode, while
64-bit syscalls use a somewhat reduced table that now has support
for both native 64-bit and "x32" mode. x86-64 and x32 share a
syscall table but not the unistd.h list, all three generated
from syscall_64.tbl.
> I've no idea how ARM64 deals with 32-bit binaries, so I can't comment
> on how it deals with those syscalls, sorry.
ARM64 has a separate list of syscalls for compat mode in
arch/arm64/include/asm/unistd32.h, this list has the same format
as include/asm-generic/uapi/unistd.h and must be updated manually
to match the arch/arm/ table today.
ARM64 will also likely gain native (A64 instruction set) ILP32
support soon, which will use the same numbers as the 64-bit
mode but point to the compat syscalls. This is similar to
how ARM OABI emulation works.
> > Another related case in asm-generic, which defines three tables:
> > native 32-bit, native 64-bit and compat 32-bit. This one not only
> > needs to have three different function pointers (e.g. sys_fcntl64,
> > sys_fcntl and compat_sys_fcntl64) but also different macros (e.g.
> > __NR_fcntl64 and __NR_fcntl).
> >
> > Anything wrong with this approach:?
> >
> > /* ARM */
> > 221 oabi fcntl64 sys_fcntl64 sys_oabi_fcntl64
> > 221 eabi fcntl64 sys_fcntl64 compat_sys_fcntl64
> >
> > /* asm-generic */
> > 25 32 fcntl64 sys_fcntl64 compat_sys_fcntl64
> > 25 64 fcntl sys_fcntl
>
> Don't know, sorry. I know virtually nothing about the differences
> between the 64-bit and 32-bit ABIs, so I can't comment on anything
> to do with the compat_* interfaces.
The only important factor here is that the first three columns are used
to generate unistd.h, which is the same for both native and emulated
mode, while the last two columns are used to generate two sets of
syscall tables using the same numbers. This is a common requirement
for OABI mode (native or emulated), EABI (on 32-bit or 64-bit kernels)
and the generic ABI (native 32-bit or emulated 32-bit).
The 64-bit unistd.h is differs only in those syscalls that got replaced
with when loff_t support was added:
#define __NR_fcntl __NR3264_fcntl
#define __NR_statfs __NR3264_statfs
#define __NR_fstatfs __NR3264_fstatfs
#define __NR_truncate __NR3264_truncate
#define __NR_ftruncate __NR3264_ftruncate
#define __NR_lseek __NR3264_lseek
#define __NR_sendfile __NR3264_sendfile
#define __NR_newfstatat __NR3264_fstatat
#define __NR_fstat __NR3264_fstat
#define __NR_mmap __NR3264_mmap
#define __NR_fadvise64 __NR3264_fadvise64
#define __NR_stat __NR3264_stat
#define __NR_lstat __NR3264_lstat
64-bit architectures still use __NR_fcntl, while 32-bit architectures
use __NR_fcntl64 etc.
> > > The syscallnr.sh script kind-of looks like a candidate, but it has
> > > ARM arch specifics to it (knowing that the number of system calls
> > > needs to fit within the 8-bit value plus 4-bit shift constant
> > > representation of ARM ALU instructions.) Maybe a generic version
> > > without that knowledge would work, provided architectures can
> > > override it.
> >
> > syscallnr.sh isn't used on x86, and probably won't be needed on
> > most (or all) others, right?
>
> Why not - the point of syscallnr.sh is to remove the need to manually
> update the __NR_syscalls definition, which is a generic kernel thing.
> Unless other architectures just define a fixed-size table with plenty
> of extra space, they'd need to adjust __NR_syscalls when adding new
> calls.
Ah, makes sense. I see that x86 does this in
arch/x86/kernel/asm-offsets_64.c in a way that would also work on
other architectures, but being able to share a single script across
all architectures would also help avoid duplicating that code.
Arnd
^ permalink raw reply
* [PATCH v2 1/4] cpufreq: pxa: use generic platdev driver for device-tree
From: Robert Jarzmik @ 2016-10-21 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020033435.GD11766@vireshk-i7>
Viresh Kumar <viresh.kumar@linaro.org> writes:
> On 19-10-16, 22:06, Robert Jarzmik wrote:
>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>>
>> >> >> + { .compatible = "marvell,pxa250", },
>> >> >> + { .compatible = "marvell,pxa270", },
>> >> >>
>> >> >> { .compatible = "samsung,exynos3250", },
>> >> >> { .compatible = "samsung,exynos4210", },
>> >> >
>> >> > Isn't there a race between cpufreq-dt and the platform driver to
>> >> > register first ?
>> >> Ah, could you be more specific about the race you're talking of ?
>> >>
>> >> My understanding was that cpufreq-dt-platdev does create the device, and
>> >> cpufreq-dt is a driver for it, so there is no race but a direct relationship
>> >> AFAIU.
>> >
>> > I mean that both the driver may try to register to the cpufreq core if
>> > they are both compiled in a single image.
>> Euh I still don't follow you. The only driver that can register to the cpufreq
>> core is cpufreq-dt.
>
> I was wondering on what will happen if both cpufreq-dt and your pxa2xx-cpufreq
> driver are present in the same kernel image. In that case the init routines of
> both of them will try to call cpufreq_register_driver().
Right.
In my case, cpufreq-dt comes first, and wins.
pxa_cpu_init() calls cpufreq_register_driver() and returns -EEXIST.
Cheers.
--
Robert
^ 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