* [PATCH 4/9] clocksource/drivers/rockchip_timer: move TIMER_INT_UNMASK out of rk_timer_enable()
From: Alexander Kochetkov @ 2016-11-23 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479922177-20136-1-git-send-email-al.kochet@gmail.com>
This allow to enable timer without enabling interrupts from it.
As that mode will be used in clocksource implementation.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
drivers/clocksource/rockchip_timer.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/clocksource/rockchip_timer.c b/drivers/clocksource/rockchip_timer.c
index 2f18166..3b530f9 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -60,8 +60,7 @@ static inline void rk_timer_disable(struct rk_timer *timer)
static inline void rk_timer_enable(struct rk_timer *timer, u32 flags)
{
- writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
- timer->ctrl);
+ writel_relaxed(TIMER_ENABLE | flags, timer->ctrl);
}
static void rk_timer_update_counter(unsigned long cycles,
@@ -82,7 +81,7 @@ static inline int rk_timer_set_next_event(unsigned long cycles,
struct rk_timer *timer = rk_timer(ce);
rk_timer_disable(timer);
rk_timer_update_counter(cycles, timer);
- rk_timer_enable(timer, TIMER_MODE_USER_DEFINED_COUNT);
+ rk_timer_enable(timer, TIMER_MODE_USER_DEFINED_COUNT | TIMER_INT_UNMASK);
return 0;
}
@@ -98,7 +97,7 @@ static int rk_timer_set_periodic(struct clock_event_device *ce)
struct rk_timer *timer = rk_timer(ce);
rk_timer_disable(timer);
rk_timer_update_counter(timer->freq / HZ - 1, timer);
- rk_timer_enable(timer, TIMER_MODE_FREE_RUNNING);
+ rk_timer_enable(timer, TIMER_MODE_FREE_RUNNING | TIMER_INT_UNMASK);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/9] clocksource/drivers/rockchip_timer: implement loading 64bit value into timer
From: Alexander Kochetkov @ 2016-11-23 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479922177-20136-1-git-send-email-al.kochet@gmail.com>
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
drivers/clocksource/rockchip_timer.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/clocksource/rockchip_timer.c b/drivers/clocksource/rockchip_timer.c
index 3b530f9..f4c26be 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -63,11 +63,13 @@ static inline void rk_timer_enable(struct rk_timer *timer, u32 flags)
writel_relaxed(TIMER_ENABLE | flags, timer->ctrl);
}
-static void rk_timer_update_counter(unsigned long cycles,
- struct rk_timer *timer)
+static void rk_timer_update_counter(u64 cycles, struct rk_timer *timer)
{
- writel_relaxed(cycles, timer->base + TIMER_LOAD_COUNT0);
- writel_relaxed(0, timer->base + TIMER_LOAD_COUNT1);
+ u32 lower = cycles & 0xFFFFFFFF;
+ u32 upper = (cycles >> 32) & 0xFFFFFFFF;
+
+ writel_relaxed(lower, timer->base + TIMER_LOAD_COUNT0);
+ writel_relaxed(upper, timer->base + TIMER_LOAD_COUNT1);
}
static void rk_timer_interrupt_clear(struct rk_timer *timer)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 6/9] clocksource/drivers/rockchip_timer: implement reading 64bit value from timer
From: Alexander Kochetkov @ 2016-11-23 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479922177-20136-1-git-send-email-al.kochet@gmail.com>
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
drivers/clocksource/rockchip_timer.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/clocksource/rockchip_timer.c b/drivers/clocksource/rockchip_timer.c
index f4c26be..61787c5 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -19,6 +19,8 @@
#define TIMER_LOAD_COUNT0 0x00
#define TIMER_LOAD_COUNT1 0x04
+#define TIMER_CURRENT_VALUE0 0x08
+#define TIMER_CURRENT_VALUE1 0x0C
#define TIMER_CONTROL_REG3288 0x10
#define TIMER_CONTROL_REG3399 0x1c
#define TIMER_INT_STATUS 0x18
@@ -72,6 +74,25 @@ static void rk_timer_update_counter(u64 cycles, struct rk_timer *timer)
writel_relaxed(upper, timer->base + TIMER_LOAD_COUNT1);
}
+static u64 rk_timer_counter_read(struct rk_timer *timer)
+{
+ u64 counter;
+ u32 lower;
+ u32 upper, old_upper;
+
+ upper = readl_relaxed(timer->base + TIMER_CURRENT_VALUE1);
+ do {
+ old_upper = upper;
+ lower = readl_relaxed(timer->base + TIMER_CURRENT_VALUE0);
+ upper = readl_relaxed(timer->base + TIMER_CURRENT_VALUE1);
+ } while (upper != old_upper);
+
+ counter = upper;
+ counter <<= 32;
+ counter |= lower;
+ return counter;
+}
+
static void rk_timer_interrupt_clear(struct rk_timer *timer)
{
writel_relaxed(1, timer->base + TIMER_INT_STATUS);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 7/9] clocksource/drivers/rockchip_timer: implement clocksource timer
From: Alexander Kochetkov @ 2016-11-23 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479922177-20136-1-git-send-email-al.kochet@gmail.com>
The patch implement stable clocksource for rk3188. It register
one of the timers as clocksource and sched_clock. Also it override
arm_global_timer clocksource using rating property (350).
arm_global_timer enabled on rk3188 provide unstable clocksource.
It's rate depend on ARM CPU rate. As result the command 'sleep 60'
could run either ~60s (with CPU freq 312 MHZ) or ~45s (with CPU
freq 1.6GHz).
In order to use the patch you have to setup the timer using
'rockchip,clocksource' device tree property. timer6 was used as
clocksource in kernel 3.0 from rockchip SDK.
cpufreq-set -f 1.6GHZ
date; sleep 60; date
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
drivers/clocksource/rockchip_timer.c | 79 +++++++++++++++++++++++++++-------
1 file changed, 63 insertions(+), 16 deletions(-)
diff --git a/drivers/clocksource/rockchip_timer.c b/drivers/clocksource/rockchip_timer.c
index 61787c5..77bea97 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -11,6 +11,7 @@
#include <linux/clockchips.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/sched_clock.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
@@ -42,7 +43,13 @@ struct rk_clock_event_device {
struct rk_timer timer;
};
+struct rk_clocksource {
+ struct clocksource cs;
+ struct rk_timer timer;
+};
+
static struct rk_clock_event_device bc_timer;
+static struct rk_clocksource cs_timer;
static inline struct rk_clock_event_device*
rk_clock_event_device(struct clock_event_device *ce)
@@ -139,14 +146,35 @@ static irqreturn_t rk_timer_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static cycle_t rk_timer_clocksource_read(struct clocksource *cs)
+{
+ struct rk_clocksource *_cs = container_of(cs, struct rk_clocksource, cs);
+ return ~rk_timer_counter_read(&_cs->timer);
+}
+
+static u64 notrace rk_timer_sched_clock_read(void)
+{
+ struct rk_clocksource *_cs = &cs_timer;
+ return ~rk_timer_counter_read(&_cs->timer);
+}
+
static int __init rk_timer_init(struct device_node *np, u32 ctrl_reg)
{
- struct clock_event_device *ce = &bc_timer.ce;
- struct rk_timer *timer = &bc_timer.timer;
+ struct clock_event_device *ce = NULL;
+ struct clocksource *cs = NULL;
+ struct rk_timer *timer = NULL;
struct clk *timer_clk;
struct clk *pclk;
int ret = -EINVAL, irq;
+ if (of_property_read_bool(np, "rockchip,clocksource")) {
+ cs = &cs_timer.cs;
+ timer = &cs_timer.timer;
+ } else {
+ ce = &bc_timer.ce;
+ timer = &bc_timer.timer;
+ }
+
timer->base = of_iomap(np, 0);
if (!timer->base) {
pr_err("Failed to get base address for '%s'\n", TIMER_NAME);
@@ -189,26 +217,45 @@ static int __init rk_timer_init(struct device_node *np, u32 ctrl_reg)
goto out_irq;
}
- ce->name = TIMER_NAME;
- ce->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
- CLOCK_EVT_FEAT_DYNIRQ;
- ce->set_next_event = rk_timer_set_next_event;
- ce->set_state_shutdown = rk_timer_shutdown;
- ce->set_state_periodic = rk_timer_set_periodic;
- ce->irq = irq;
- ce->cpumask = cpu_possible_mask;
- ce->rating = 250;
+ if (ce) {
+ ce->name = TIMER_NAME;
+ ce->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
+ CLOCK_EVT_FEAT_DYNIRQ;
+ ce->set_next_event = rk_timer_set_next_event;
+ ce->set_state_shutdown = rk_timer_shutdown;
+ ce->set_state_periodic = rk_timer_set_periodic;
+ ce->irq = irq;
+ ce->cpumask = cpu_possible_mask;
+ ce->rating = 250;
+ }
+
+ if (cs) {
+ cs->name = TIMER_NAME;
+ cs->flags = CLOCK_SOURCE_IS_CONTINUOUS;
+ cs->mask = CLOCKSOURCE_MASK(64);
+ cs->read = rk_timer_clocksource_read;
+ cs->rating = 350;
+ }
rk_timer_interrupt_clear(timer);
rk_timer_disable(timer);
- ret = request_irq(irq, rk_timer_interrupt, IRQF_TIMER, TIMER_NAME, ce);
- if (ret) {
- pr_err("Failed to initialize '%s': %d\n", TIMER_NAME, ret);
- goto out_irq;
+ if (ce) {
+ ret = request_irq(irq, rk_timer_interrupt, IRQF_TIMER, TIMER_NAME, ce);
+ if (ret) {
+ pr_err("Failed to initialize '%s': %d\n", TIMER_NAME, ret);
+ goto out_irq;
+ }
+
+ clockevents_config_and_register(ce, timer->freq, 1, UINT_MAX);
}
- clockevents_config_and_register(ce, timer->freq, 1, UINT_MAX);
+ if (cs) {
+ rk_timer_update_counter(U64_MAX, timer);
+ rk_timer_enable(timer, 0);
+ clocksource_register_hz(cs, timer->freq);
+ sched_clock_register(rk_timer_sched_clock_read, 64, timer->freq);
+ }
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 8/9] dt-bindings: add rockchip, clocksource property to rk-timer
From: Alexander Kochetkov @ 2016-11-23 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479922177-20136-1-git-send-email-al.kochet@gmail.com>
---
.../bindings/timer/rockchip,rk-timer.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
index a41b184..ed5392a 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
@@ -9,6 +9,7 @@ Required properties:
- clocks : must contain an entry for each entry in clock-names
- clock-names : must include the following entries:
"timer", "pclk"
+- rockchip,clocksource: setup the timer as clocksource
Example:
timer: timer at ff810000 {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 9/9] ARM: dts: rockchip: add timer entries to rk3188.dtsi
From: Alexander Kochetkov @ 2016-11-23 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479922177-20136-1-git-send-email-al.kochet@gmail.com>
This is correct configuration borrowed from 3.0 kernel[1].
timer 6 used as clocksource, timers 0, 1, 4 and 5 used
as clockevents.
Timers can do interrupts and work as expected with correct
driver support.
[1] https://github.com/radxa/linux-rockchip/blob/radxa-stable-3.0/arch/arm/mach-rk3188/rk_timer.c
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
arch/arm/boot/dts/rk3188.dtsi | 45 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index 31f81b2..e2f88c8 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -106,6 +106,51 @@
};
};
+ timer0: timer at 20038000 {
+ compatible = "rockchip,rk3288-timer";
+ reg = <0x20038000 0x20>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER0>, <&cru PCLK_TIMER0>;
+ clock-names = "timer", "pclk";
+ status = "disabled";
+ };
+
+ timer1: timer at 20038020 {
+ compatible = "rockchip,rk3288-timer";
+ reg = <0x20038020 0x20>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER1>, <&cru PCLK_TIMER0>;
+ clock-names = "timer", "pclk";
+ status = "disabled";
+ };
+
+ timer4: timer at 20038060 {
+ compatible = "rockchip,rk3288-timer";
+ reg = <0x20038060 0x20>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER4>, <&cru PCLK_TIMER0>;
+ clock-names = "timer", "pclk";
+ status = "disabled";
+ };
+
+ timer5: timer at 20038080 {
+ compatible = "rockchip,rk3288-timer";
+ reg = <0x20038080 0x20>;
+ interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER5>, <&cru PCLK_TIMER0>;
+ clock-names = "timer", "pclk";
+ status = "disabled";
+ };
+
+ timer6: timer at 200380A0 {
+ compatible = "rockchip,rk3288-timer";
+ reg = <0x200380A0 0x20>;
+ interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_TIMER6>, <&cru PCLK_TIMER0>;
+ clock-names = "timer", "pclk";
+ status = "disabled";
+ };
+
i2s0: i2s at 1011a000 {
compatible = "rockchip,rk3188-i2s", "rockchip,rk3066-i2s";
reg = <0x1011a000 0x2000>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
From: Krzysztof Kozlowski @ 2016-11-23 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479467712-5218-1-git-send-email-krzk@kernel.org>
On Fri, Nov 18, 2016 at 01:15:12PM +0200, Krzysztof Kozlowski wrote:
> All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
> 200 Hz. Unfortunately in case of multiplatform image this affects also
> other platforms when Exynos is enabled.
>
> This looks like an very old legacy code, dating back to initial
> upstreaming of S3C24xx. Probably it was required for s3c24xx timer
> driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
> unused plat-samsung/time.c").
>
> Since then, this fixed 200 Hz spread everywhere, including out-of-tree
> Samsung kernels (SoC vendor's and Tizen's). I believe this choice
> was rather an effect of coincidence instead of conscious choice.
>
> On S3C24xx, the PWM counter is only 16 bit wide, and with the
> typical 12MHz input clock that overflows every 5.5ms. This works
> with HZ=200 or higher but not with HZ=100 which needs a 10ms
> interval between ticks. On Later chips (S3C64xx, S5P and EXYNOS),
> the counter is 32 bits and does not have this problem.
>
> The new samsung_pwm_timer driver solves the problem by scaling the input
> clock by a factor of 50 on S3C24xx, which makes it less accurate but
> allows HZ=100 as well as CONFIG_NO_HZ with fewer wakeups.
>
> Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
> A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
> other values.
>
> Reported-by: Lee Jones <lee.jones@linaro.org>
> [Dropping of 200_HZ from S3C/S5P was suggested by Arnd]
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> [Tested on Exynos5800]
> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Acked-by: Kukjin Kim <kgene@kernel.org>
> [Tested on S3C2440]
> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
> ---
>
> Changes since v2:
> 1. Extend message.
> 2. Add Kukjin's ack.
> 3. Add Sylwester's tested-by.
>
> Changes since v1:
> 1. Add Javier's tested-by.
> 2. Drop HZ_FIXED also from ARCH_S5PV210 and ARCH_S3C24XX after Arnd
> suggestions and analysis.
> ---
> arch/arm/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
Applied,
Krzysztof
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Frank Rowand @ 2016-11-23 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b668871c-2b54-0a2f-0d68-afaa50e17e63@ti.com>
On 11/22/16 21:55, Sekhar Nori wrote:
> On Tuesday 22 November 2016 11:51 PM, Frank Rowand wrote:
>> Please note that the compatible property might contain several strings, not just
>> a single string.
>
> So I guess the best thing to do is to use
> of_property_read_string_index() and print the sting at index 0.
>
> Thanks,
> Sekhar
If you want to print just one compatible value, you could use that method.
To give all of the information needed to understand the problem, the error
message would need to include all of the strings contained in the compatible
property and all of the .board values in the da8xx_ddrctl_board_confs[] array
(currently only one entry, but coded to allow additional entries in the
future).
It is hard to justify an error message that complex.
I would just print an error that no match was found.
-Frank
^ permalink raw reply
* [PATCH V9 11/11] ARM64/PCI: Support for ACPI based PCI host controller
From: Bjorn Helgaas @ 2016-11-23 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <edf72769-e9c8-4617-8dc4-8f3d05a678e7@semihalf.com>
On Wed, Nov 23, 2016 at 12:21:03PM +0100, Tomasz Nowicki wrote:
> Hi Bjorn,
>
> On 23.11.2016 00:13, Bjorn Helgaas wrote:
> >Hi Tomasz,
> >
> >On Fri, Jun 10, 2016 at 09:55:19PM +0200, Tomasz Nowicki wrote:
> >>Implement pci_acpi_scan_root and other arch-specific call so that ARM64
> >>can start using ACPI to setup and enumerate PCI buses.
> >>
> >>Prior to buses enumeration the pci_acpi_scan_root() implementation looks
> >>for configuration space start address (obtained through ACPI _CBA method or
> >>MCFG interface). If succeed, it uses ECAM library to create new mapping.
> >>Then it attaches generic ECAM ops (pci_generic_ecam_ops) which are used
> >>for accessing configuration space later on.
> >>...
> >
> >>+static struct acpi_pci_root_ops acpi_pci_root_ops = {
> >>+ .release_info = pci_acpi_generic_release_info,
> >>+};
> >>+
> >>+/* Interface called from ACPI code to setup PCI host controller */
> >> struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> >> {
> >>- /* TODO: Should be revisited when implementing PCI on ACPI */
> >>- return NULL;
> >>+ int node = acpi_get_node(root->device->handle);
> >>+ struct acpi_pci_generic_root_info *ri;
> >>+ struct pci_bus *bus, *child;
> >>+
> >>+ ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
> >>+ if (!ri)
> >>+ return NULL;
> >>+
> >>+ ri->cfg = pci_acpi_setup_ecam_mapping(root);
> >>+ if (!ri->cfg) {
> >>+ kfree(ri);
> >>+ return NULL;
> >>+ }
> >>+
> >>+ acpi_pci_root_ops.pci_ops = &ri->cfg->ops->pci_ops;
> >
> >This has already been merged, but this isn't right, is it? We're
> >writing a host controller-specific pointer into the single system-wide
> >acpi_pci_root_ops, then passing it on to acpi_pci_root_create().
> >
> >Today, I think ri->cfg->ops->pci_ops is always &pci_generic_ecam_ops,
> >from this path:
> >
> > ri->cfg = pci_acpi_setup_ecam_mapping
> > cfg = pci_ecam_create(..., &pci_generic_ecam_ops)
> > cfg = kzalloc(...)
> > cfg->ops = ops # &pci_generic_ecam_ops
> >
> >But we're about to merge the ECAM quirks series, which will mean it
> >may not be &pci_generic_ecam_ops. Even apart from the ECAM quirks, we
> >should avoid this pattern of putting device-specific info in a single
> >shared structure because it's too difficult to verify that it's
> >correct.
> >
>
> Well spotted. I agree, we need to fix this. How about this:
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index fb439c7..31c0e1c 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -152,33 +152,35 @@ static void
> pci_acpi_generic_release_info(struct acpi_pci_root_info *ci)
>
> ri = container_of(ci, struct acpi_pci_generic_root_info, common);
> pci_ecam_free(ri->cfg);
> + kfree(ci->ops);
> kfree(ri);
> }
>
> -static struct acpi_pci_root_ops acpi_pci_root_ops = {
> - .release_info = pci_acpi_generic_release_info,
> -};
> -
> /* Interface called from ACPI code to setup PCI host controller */
> struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> {
> int node = acpi_get_node(root->device->handle);
> struct acpi_pci_generic_root_info *ri;
> struct pci_bus *bus, *child;
> + struct acpi_pci_root_ops *root_ops;
>
> ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
> if (!ri)
> return NULL;
>
> + root_ops = kzalloc_node(sizeof(*root_ops), GFP_KERNEL, node);
> + if (!root_ops)
> + return NULL;
> +
> ri->cfg = pci_acpi_setup_ecam_mapping(root);
> if (!ri->cfg) {
> kfree(ri);
> + kfree(root_ops);
> return NULL;
> }
>
> - acpi_pci_root_ops.pci_ops = &ri->cfg->ops->pci_ops;
> - bus = acpi_pci_root_create(root, &acpi_pci_root_ops, &ri->common,
> - ri->cfg);
> + root_ops->release_info = pci_acpi_generic_release_info;
> + root_ops->pci_ops = &ri->cfg->ops->pci_ops;
> + bus = acpi_pci_root_create(root, root_ops, &ri->common, ri->cfg);
> if (!bus)
> return NULL;
>
> Of course, this should be the part of ECAM quirks core patches.
>
> The other option we have is to remove "struct pci_ops *pci_ops;"
> from acpi_pci_root_ops structure and pass struct pci_ops as an extra
> argument to acpi_pci_root_create(). What do you think?
I think your patch above is fine and avoids the need to change the x86 and
ia64 code. Would you mind packaging this up with a changelog and
signed-off-by? I can take care of putting it in the ECAM series.
Thanks,
Bjorn
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Frank Rowand @ 2016-11-23 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5835DC2D.5080606@gmail.com>
On 11/23/16 10:13, Frank Rowand wrote:
> On 11/22/16 21:55, Sekhar Nori wrote:
>> On Tuesday 22 November 2016 11:51 PM, Frank Rowand wrote:
>>> Please note that the compatible property might contain several strings, not just
>>> a single string.
>>
>> So I guess the best thing to do is to use
>> of_property_read_string_index() and print the sting at index 0.
>>
>> Thanks,
>> Sekhar
>
> If you want to print just one compatible value, you could use that method.
>
> To give all of the information needed to understand the problem, the error
> message would need to include all of the strings contained in the compatible
> property and all of the .board values in the da8xx_ddrctl_board_confs[] array
> (currently only one entry, but coded to allow additional entries in the
> future).
>
> It is hard to justify an error message that complex.
>
> I would just print an error that no match was found.
>
> -Frank
I just needed to read some more emails. I see this approach was taken
in the "[PATCH v4 0/2] da8xx: fix section mismatch in new drivers"
series.
-Frank
^ permalink raw reply
* [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode
From: Matthias Brugger @ 2016-11-23 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1463021701.25171.5.camel@mussux00>
Hi Hongzhou,
On 12/05/16 04:55, Hongzhou Yang wrote:
> On Wed, 2016-05-11 at 19:09 -0700, Hongzhou Yang wrote:
>> On Thu, 2016-05-12 at 09:41 +0800, chunfeng yun wrote:
>>> Hi,
>>>
>>> On Wed, 2016-05-11 at 11:32 -0700, Hongzhou Yang wrote:
>>>> On Wed, 2016-05-11 at 13:56 +0200, Linus Walleij wrote:
>>>>> On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun
>>>>> <chunfeng.yun@mediatek.com> wrote:
>>>>>
>>>>>> the default mode of GPIO16 pin is gpio, when set EINT16 to
>>>>>> IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be
>>>>>> fixed when set its default mode as usb iddig.
>>>>>>
>>>>>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>>>>>
>>>>
>>>> Chunfeng, GPIO16 can be used as EINT16 mode, but the pinmux should be 0.
>>>> If you want to set its default mode to iddig, you should set it in dts.
>>>>
>>> I set it in DTS, but it didn't work, because when usb driver requested
>>> IRQ, pinmux was switched back to default mode set by
>>> MTK_EINT_FUNCTION().
>>>
>>
>> After confirmed, there are something wrong with data sheet and pinmux
>> table, and GPIO16 can only receive interrupt by mode 1. So
>>
>> Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
>>
>
> Linus,
>
> We find there are some other pins still have the same problem, so please
> hold on it. Sorry for so much noise.
>
Did you made any progress on this? I didn't see any patch on the mailing
list.
Regards,
Matthias
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-23 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123145916.GL14947@lunn.ch>
Hello Andrew,
On 11/23/2016 03:59 PM, Andrew Lunn wrote:
>>> CZ11NIC12 is indicated on my board.
>>
>> :-( Well, this board version has wrongly matched length of some
>> differential pairs, IRQ from 88E1514 is connected differently, there
>> are slight differences in power supplies and (if I am not mistaken)
>> something changed in RTC support circuitry. It looks like a huge
>> mistake on our side.
>
> Hi Tomas
>
> Would these problems also explain why the Ethernet links to the switch
> don't work? Maybe the differential pairs?
no this is not the problem. When booting the OpenWRT based system I can
communicate with the device via the switch. (Didn't test deeply, but my
Laptop got a dhcp lease from the Turris Omnia and I can ping it.) But
this convinces me, that the hardware is good enough.
If you have any ideas what I can try to make the switch work or help to
diagnose the problem, just let me know.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161123/3b35fee8/attachment.sig>
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: Florian Fainelli @ 2016-11-23 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123100106.15969-2-s.hauer@pengutronix.de>
On 11/23/2016 02:01 AM, Sascha Hauer wrote:
> With this patch the serial core provides LED triggers for RX and TX.
>
> As the serial core layer does not know when the hardware actually sends
> or receives characters, this needs help from the UART drivers.
Looking at 8250, we call serial8250_tx_chars from __start_tx which is
called form the uart_ops::start_tx, for RX I sort of agree, since this
happens in interrupt handler. I suppose some drivers could actually
queue work but not do it right away though?
> The LED triggers are registered in uart_add_led_triggers() called from
> the UART drivers which want to support LED triggers. All the driver
> has to do then is to call uart_led_trigger_[tx|rx] to indicate
> activity.
Could we somehow remedy the lack of knowledge from the core as whether
the HW sends/receives characters first before adding support for LED
triggers? It would be more generic and future proof to require UART
drivers to report to the core when they actually TX/RX, and then at the
core level, utilize that knowledge to perform the LED trigger.
Side note: are you positive using drv->dev_name is robust enough on
systems with many different UART drivers, yet all of them being ttyS*?
Thanks!
--
Florian
^ permalink raw reply
* [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()
From: Stephen Boyd @ 2016-11-23 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737isvwc6.wl%kuninori.morimoto.gx@renesas.com>
On 11/16, Kuninori Morimoto wrote:
>
> Hi Rob, Michael, Russell
>
>
> What is the conclusion of this patch ?
> We shouldn't add devm_of_clk_get() ? or can I continue ?
>
> The problem of current [devm_]clk_get() handles *dev only,
> but I need to get clocks from DT node, not dev
>
> sound_soc {
> ...
> cpu {
> ...
> => clocks = <&xxx>;
> };
> codec {
> ...
> => clocks = <&xxx>;
> };
> };
>
I've seen bindings that have the 'clocks' property at the top
level and the appropriate 'clock-names' property to relate the
clocks to a subnode.
sound_soc {
clocks = <&xxx>, <&xxx>;
clock-names = "cpu", "codec";
...
cpu {
...
};
codec {
...
};
};
Then the subnodes call clk_get() with the top level device and
the name of their node and things match up. I suppose this
binding is finalized though, so we can't really do that?
I see that the gpio framework has a similar design called
devm_get_gpiod_from_child(), so how about we add a
devm_get_clk_from_child() API? That would more closely match the
intent here, which is to restrict the clk_get() operation to
child nodes of the device passed as the first argument.
struct clk *devm_get_clk_from_child(struct device *dev,
const char *con_id,
struct device_node *child);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 19:15 UTC (permalink / raw)
To: linux-arm-kernel
All,
I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
board (Marvell Armada 370 SoC). Every day or so I get a consistent
crash that brings down the whole board. I've attached three oops I
captured on the serial port.
I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
at me as "this would fix it". And since it takes a day or so to trigger
the oops, bisecting would be a bit brutal. Does anyone have any insight
into this?
thx,
Jason.
------- oops from v4.2.8 ------------------------------------------
[ 3572.897994] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[ 3572.906134] pgd = c0004000
[ 3572.908891] [00000020] *pgd=00000000
[ 3572.912504] Internal error: Oops: 5 [#1] SMP ARM
[ 3572.917142] Modules linked in: tun ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge ipv6 ath9k ath9k_common ath9k_hw led_class ath
[ 3572.930749] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.2.8 #57
[ 3572.937915] Hardware name: Marvell Armada 370/XP (Device Tree)
[ 3572.943774] task: c06fdd30 ti: c06f8000 task.ti: c06f8000
[ 3572.949208] PC is at ath_cmn_process_fft+0xac/0x4a0 [ath9k_common]
[ 3572.955421] LR is at ath_cmn_process_fft+0xc8/0x4a0 [ath9k_common]
[ 3572.961631] pc : [<bf081f44>] lr : [<bf081f60>] psr: 80000153
[ 3572.961631] sp : c06f9ca0 ip : 00000000 fp : 00000000
[ 3572.973160] r10: dc9a8010 r9 : 00000000 r8 : c06fa4d0
[ 3572.978409] r7 : 0000006c r6 : dd3abfc0 r5 : c06fad88 r4 : 00000000
[ 3572.984965] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[ 3572.991522] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 3572.998951] Control: 10c5387d Table: 1c894019 DAC: 00000015
[ 3573.004723] Process swapper/0 (pid: 0, stack limit = 0xc06f8220)
[ 3573.010756] Stack: (0xc06f9ca0 to 0xc06fa000)
[ 3573.015137] 9ca0: c0734e31 dfbe3f40 c06f6f40 c06f6f40 c06fae34 c0734184 00989680 00000003
[ 3573.023356] 9cc0: dff6cde0 00000008 c06f9df4 00000069 dca0ab8c c0098b44 00000985 00000fc0
[ 3573.031573] 9ce0: c0733700 dffa0560 00000002 c001b6ac 000000c0 00000000 00000000 00000000
[ 3573.039790] 9d00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.048006] 9d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.056222] 9d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.064438] 9d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dc9a8010
[ 3573.072654] 9d80: 00000000 dc983d18 dc983d00 dc983d00 00000002 dd045c90 dca08d40 bf090e64
[ 3573.080872] 9da0: d364463c 00000000 edf3c980 0000033f 0000033f 000001fa dc9a8010 00000000
[ 3573.089090] 9dc0: d3644890 00000000 dc9a8038 dca083e0 dd3abfc0 00000000 dd3abfc0 dca097ac
[ 3573.097306] 9de0: dc9a8038 00000002 00000001 dca083e0 00000100 d364463c 2602006c 018eff80
[ 3573.105522] 9e00: 80808000 00808080 20000001 00000000 00000000 00000000 00000000 00000000
[ 3573.113739] 9e20: 00000000 00000000 c06f9e68 dca08d40 00000001 dc9a8010 dca09708 c06f9e68
[ 3573.121955] 9e40: c06f4294 c06f8000 00000006 bf08e698 bf08e5dc dca096d0 dca096d4 00000000
[ 3573.130172] 9e60: c0735bc0 c0027e4c 00000000 c06fa098 00000100 c06f8000 c06f9e88 40000006
[ 3573.138389] 9e80: c06fa080 c0028030 ed5b3300 0000033f c06fa080 c06f4308 0000000a c0735bc0
[ 3573.146606] 9ea0: c06fa100 0004fe8e c051e380 00200000 c06f8000 c06f5444 00000000 00000000
[ 3573.154823] 9ec0: 00000001 df405000 c06fa484 c0759f80 c06f8000 c00283d8 c06f5444 c005b838
[ 3573.163041] 9ee0: c0341814 00000001 c0759f80 c06f9f20 000003ff c0009410 c034180c c0341814
[ 3573.171257] 9f00: 80000153 ffffffff c06f9f54 ed5b20c4 0000033f ed5b20c4 c06f8000 c0013340
[ 3573.179474] 9f20: 00000000 fffffffa 1f4ed000 dfbe3f40 ecf52c5b 0000033f dfbe34d0 00000001
[ 3573.187691] 9f40: ed5b20c4 0000033f ed5b20c4 c06f8000 0000001a c06f9f68 c034180c c0341814
[ 3573.195908] 9f60: 80000153 ffffffff 00000000 00000000 ed5b20c4 0000033f dfbe34d0 c051e374
[ 3573.204125] 9f80: dfbe34d0 c072a608 c06f64c8 c06fa51c c06f4364 c06fa524 c06f8000 c00535ec
[ 3573.212343] 9fa0: c06f9fa0 c0734dd1 dfffce00 ffffffff dfffce00 c06b5c6c ffffffff ffffffff
[ 3573.220559] 9fc0: 00000000 c06b5670 00000000 c06ea990 00000000 c0735294 c06fa4c0 c06ea98c
[ 3573.228777] 9fe0: c06fee2c 00004059 561f5811 00000000 00000000 0000807c 00000000 00000000
[ 3573.237025] [<bf081f44>] (ath_cmn_process_fft [ath9k_common]) from [<bf090e64>] (ath_rx_tasklet+0xa14/0xafc [ath9k])
[ 3573.247613] [<bf090e64>] (ath_rx_tasklet [ath9k]) from [<bf08e698>] (ath9k_tasklet+0xbc/0x20c [ath9k])
[ 3573.256981] [<bf08e698>] (ath9k_tasklet [ath9k]) from [<c0027e4c>] (tasklet_action+0x7c/0x110)
[ 3573.265641] [<c0027e4c>] (tasklet_action) from [<c0028030>] (__do_softirq+0xf8/0x23c)
[ 3573.273513] [<c0028030>] (__do_softirq) from [<c00283d8>] (irq_exit+0x78/0xb0)
[ 3573.280778] [<c00283d8>] (irq_exit) from [<c005b838>] (__handle_domain_irq+0x60/0xb0)
[ 3573.288651] [<c005b838>] (__handle_domain_irq) from [<c0009410>] (armada_370_xp_handle_irq+0x50/0xbc)
[ 3573.297917] [<c0009410>] (armada_370_xp_handle_irq) from [<c0013340>] (__irq_svc+0x40/0x54)
[ 3573.306306] Exception stack(0xc06f9f20 to 0xc06f9f68)
[ 3573.311385] 9f20: 00000000 fffffffa 1f4ed000 dfbe3f40 ecf52c5b 0000033f dfbe34d0 00000001
[ 3573.319602] 9f40: ed5b20c4 0000033f ed5b20c4 c06f8000 0000001a c06f9f68 c034180c c0341814
[ 3573.327816] 9f60: 80000153 ffffffff
[ 3573.331331] [<c0013340>] (__irq_svc) from [<c0341814>] (cpuidle_enter_state+0xdc/0x248)
[ 3573.339385] [<c0341814>] (cpuidle_enter_state) from [<c00535ec>] (cpu_startup_entry+0x170/0x234)
[ 3573.348218] [<c00535ec>] (cpu_startup_entry) from [<c06b5c6c>] (start_kernel+0x3b0/0x3bc)
[ 3573.356436] Code: e59c9004 e3e0b000 e5938000 ea000002 (e7990102)
[ 3573.362634] ---[ end trace 47b32564cd3160db ]---
[ 3573.367281] Kernel panic - not syncing: Fatal exception in interrupt
[ 3573.373667] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
------- oops from v4.8.6 ---------------------------------------------
[231233.388543] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[231233.396804] pgd = c0004000
[231233.399614] [00000020] *pgd=00000000
[231233.403311] Internal error: Oops: 17 [#1] SMP ARM
[231233.408124] Modules linked in: ath9k ath9k_common ath9k_hw ath
[231233.414132] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
[231233.420165] Hardware name: Marvell Armada 370/XP (Device Tree)
[231233.426111] task: c0b091c0 task.stack: c0b00000
[231233.430760] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
[231233.437060] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
[231233.443357] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
[231233.443357] sp : c0b01cd0 ip : 00000000 fp : 00000000
[231233.455059] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
[231233.460394] r7 : 00000000 r6 : dbef9440 r5 : c0b03da0 r4 : 00000000
[231233.467037] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[231233.473682] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
[231233.481023] Control: 10c5387d Table: 1e614019 DAC: 00000051
[231233.486882] Process swapper/0 (pid: 0, stack limit = 0xc0b00220)
[231233.493001] Stack: (0xc0b01cd0 to 0xc0b02000)
[231233.497466] 1cc0: fffffffa 3b9ac9ff 003c8995 c0b44d30
[231233.505770] 1ce0: dda18010 00000000 c0b01e14 c017ad48 ffffffff dee1ac84 c0b44d30 c0b44b00
[231233.514073] 1d00: 0000099e 00000440 0001bef9 c01176f4 00000002 00000786 00000000 00000000
[231233.522377] 1d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.530680] 1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.538984] 1d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.547287] 1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.555591] 1da0: dda18010 dda18010 00000000 defaa3d8 defaa3c0 defaa3c0 dee18e40 de5b4a18
[231233.563895] 1dc0: dda18010 bf08a9d0 071a3710 00000056 00989680 00000000 071a393a 00000056
[231233.572199] 1de0: 000001fb dee18440 00000000 dbef9440 dee198b0 00000014 dda18038 dee1a97c
[231233.580504] 1e00: dbef9440 00000002 00000001 dee18440 0036f478 071a3710 2422006c 018fff07
[231233.588807] 1e20: 80252900 01168e85 40000000 00000000 00000000 00000000 00000000 00000000
[231233.597110] 1e40: 00000000 00000000 c0a4a2c0 dee18e40 dda18010 dee19808 00000001 c0b00000
[231233.605414] 1e60: c0a4a2c0 c0b02080 40000006 bf088810 dee197d0 dee197d4 00000000 c0b01e88
[231233.613717] 1e80: c0b00000 c0126b88 00000000 00000006 c0b00000 c0b02098 c0b02080 00000100
[231233.622021] 1ea0: c0b02080 c0126d74 df405000 c0b01f30 c0b01ea8 c0b3bf80 0000000a 0160605b
[231233.630324] 1ec0: c0b02100 00200100 df488a20 c0a4d500 00000000 00000000 00000001 df405000
[231233.638629] 1ee0: c0b01f30 00000000 c0b03524 c0127120 c0a4d500 c01635e4 c04b7318 20000153
[231233.646933] 1f00: c0b61040 00000001 c0b61040 c010145c c04b7318 20000153 ffffffff c0b01f64
[231233.655236] 1f20: 0028571c c0b00000 00000000 c010bd8c 00000000 0000d24e 1f194000 dfbe31c0
[231233.663540] 1f40: 37d25f82 0000d24e dfbe2590 00000001 0028571c 0000d24e 00000000 c0b03524
[231233.671843] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff 00000051 00000000
[231233.680148] 1f80: dfbe2590 c0b00000 c0b034d4 00000001 dfbe2590 c0b2e070 c0a4e588 c0b0352c
[231233.688452] 1fa0: c0b03524 c015a240 c0b01fa8 c0b3b0f4 00000000 ffffffff 00000000 c0a00c54
[231233.696756] 1fc0: ffffffff ffffffff 00000000 c0a0068c 00000000 c0a3ba28 c0b3b614 c0b034c0
[231233.705059] 1fe0: c0a3ba24 c0b0a3a8 00004059 561f5811 00000000 0000807c 00000000 00000000
[231233.713401] [<bf07bec4>] (ath_cmn_process_fft [ath9k_common]) from [<bf08a9d0>] (ath_rx_tasklet+0x47c/0xb20 [ath9k])
[231233.724079] [<bf08a9d0>] (ath_rx_tasklet [ath9k]) from [<bf088810>] (ath9k_tasklet+0x1dc/0x218 [ath9k])
[231233.733623] [<bf088810>] (ath9k_tasklet [ath9k]) from [<c0126b88>] (tasklet_action+0x74/0x110)
[231233.742367] [<c0126b88>] (tasklet_action) from [<c0126d74>] (__do_softirq+0xfc/0x218)
[231233.750324] [<c0126d74>] (__do_softirq) from [<c0127120>] (irq_exit+0x7c/0xb4)
[231233.757678] [<c0127120>] (irq_exit) from [<c01635e4>] (__handle_domain_irq+0x60/0xb4)
[231233.765637] [<c01635e4>] (__handle_domain_irq) from [<c010145c>] (armada_370_xp_handle_irq+0x48/0xa8)
[231233.774989] [<c010145c>] (armada_370_xp_handle_irq) from [<c010bd8c>] (__irq_svc+0x6c/0x90)
[231233.783463] Exception stack(0xc0b01f30 to 0xc0b01f78)
[231233.788625] 1f20: 00000000 0000d24e 1f194000 dfbe31c0
[231233.796930] 1f40: 37d25f82 0000d24e dfbe2590 00000001 0028571c 0000d24e 00000000 c0b03524
[231233.805232] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff
[231233.811974] [<c010bd8c>] (__irq_svc) from [<c04b7318>] (cpuidle_enter_state+0x18c/0x2b4)
[231233.820202] [<c04b7318>] (cpuidle_enter_state) from [<c015a240>] (cpu_startup_entry+0x17c/0x220)
[231233.829124] [<c015a240>] (cpu_startup_entry) from [<c0a00c54>] (start_kernel+0x368/0x374)
[231233.837430] Code: e5933000 e1d330b4 e58d3030 ea000002 (e7970102)
[231233.843714] ---[ end trace 0a5139f91be0a117 ]---
[231233.848460] Kernel panic - not syncing: Fatal exception in interrupt
[231233.854937] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
------- oops from v4.8.6 #2 ------------------------------------------
[42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[42059.311799] pgd = c0004000
[42059.314522] [00000020] *pgd=00000000
[42059.318162] Internal error: Oops: 17 [#1] SMP ARM
[42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
[42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
[42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
[42059.340613] task: c0b091c0 task.stack: c0b00000
[42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
[42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
[42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
[42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
[42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
[42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
[42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[42059.387487] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
[42059.394741] Control: 10c5387d Table: 1ef48019 DAC: 00000051
[42059.400513] Process swapper/0 (pid: 0, stack limit = 0xc0b00220)
[42059.406545] Stack: (0xc0b01cd0 to 0xc0b02000)
[42059.410924] 1cc0: fffffffa 3b9ac9ff 0047c6ce c0b44d30
[42059.419141] 1ce0: de6a0010 00000000 c0b01e14 c017ad48 ffffffff dee0ac84 c0b44d30 c0b44b00
[42059.427357] 1d00: 0000099e 00000340 0001cfbd c01176f4 00000002 00000786 00000080 00000000
[42059.435573] 1d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.443789] 1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.452005] 1d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.460220] 1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.468437] 1da0: de6a0010 de6a0010 00000000 deec5b58 deec5b40 deec5b40 dee08e40 de631ff0
[42059.476653] 1dc0: de6a0010 bf08a9d0 8918a8c8 00000002 00000000 00000000 8918aaa1 00000002
[42059.484869] 1de0: 00000200 dee08440 00000000 dcfbd340 dee098b0 00000014 de6a0038 dee0a97c
[42059.493085] 1e00: dcfbd340 00000002 00000001 dee08440 00fc2540 8918a8c8 0502006c 018e026c
[42059.501301] 1e20: 80202600 016d5ab7 40000100 00000000 00000000 00000000 00000000 00000000
[42059.509518] 1e40: 00000000 00000000 c0a4a2c0 dee08e40 de6a0010 dee09808 00000001 c0b00000
[42059.517734] 1e60: c0a4a2c0 c0b02080 40000006 bf088810 dee097d0 dee097d4 00000000 c0b01e88
[42059.525950] 1e80: c0b00000 c0126b88 00000000 00000006 c0b00000 c0b02098 c0b02080 00000100
[42059.534166] 1ea0: c0b02080 c0126d74 df405000 c0b01f30 c0b01ea8 c0b3bf80 0000000a 003fb83a
[42059.542382] 1ec0: c0b02100 00200100 df486a20 c0a4d500 00000000 00000000 00000001 df405000
[42059.550599] 1ee0: c0b01f30 00000000 c0b03524 c0127120 c0a4d500 c01635e4 c04b7318 20000153
[42059.558816] 1f00: c0b61040 00000001 c0b61040 c010145c c04b7318 20000153 ffffffff c0b01f64
[42059.567031] 1f20: 006895c7 c0b00000 00000000 c010bd8c 00000000 00002640 1f194000 dfbe31c0
[42059.575248] 1f40: b1708859 00002640 dfbe2590 00000001 006895c7 00002640 00000000 c0b03524
[42059.583464] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff 00000051 00000000
[42059.591681] 1f80: dfbe2590 c0b00000 c0b034d4 00000001 dfbe2590 c0b2e070 c0a4e588 c0b0352c
[42059.599897] 1fa0: c0b03524 c015a240 c0b01fa8 c0b3b0f4 00000000 ffffffff 00000000 c0a00c54
[42059.608114] 1fc0: ffffffff ffffffff 00000000 c0a0068c 00000000 c0a3ba28 c0b3b614 c0b034c0
[42059.616330] 1fe0: c0a3ba24 c0b0a3a8 00004059 561f5811 00000000 0000807c 00000000 00000000
[42059.624586] [<bf07bec4>] (ath_cmn_process_fft [ath9k_common]) from [<bf08a9d0>] (ath_rx_tasklet+0x47c/0xb20 [ath9k])
[42059.635176] [<bf08a9d0>] (ath_rx_tasklet [ath9k]) from [<bf088810>] (ath9k_tasklet+0x1dc/0x218 [ath9k])
[42059.644631] [<bf088810>] (ath9k_tasklet [ath9k]) from [<c0126b88>] (tasklet_action+0x74/0x110)
[42059.653288] [<c0126b88>] (tasklet_action) from [<c0126d74>] (__do_softirq+0xfc/0x218)
[42059.661157] [<c0126d74>] (__do_softirq) from [<c0127120>] (irq_exit+0x7c/0xb4)
[42059.668423] [<c0127120>] (irq_exit) from [<c01635e4>] (__handle_domain_irq+0x60/0xb4)
[42059.676295] [<c01635e4>] (__handle_domain_irq) from [<c010145c>] (armada_370_xp_handle_irq+0x48/0xa8)
[42059.685559] [<c010145c>] (armada_370_xp_handle_irq) from [<c010bd8c>] (__irq_svc+0x6c/0x90)
[42059.693946] Exception stack(0xc0b01f30 to 0xc0b01f78)
[42059.699021] 1f20: 00000000 00002640 1f194000 dfbe31c0
[42059.707237] 1f40: b1708859 00002640 dfbe2590 00000001 006895c7 00002640 00000000 c0b03524
[42059.715453] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff
[42059.722107] [<c010bd8c>] (__irq_svc) from [<c04b7318>] (cpuidle_enter_state+0x18c/0x2b4)
[42059.730247] [<c04b7318>] (cpuidle_enter_state) from [<c015a240>] (cpu_startup_entry+0x17c/0x220)
[42059.739081] [<c015a240>] (cpu_startup_entry) from [<c0a00c54>] (start_kernel+0x368/0x374)
[42059.747299] Code: e5933000 e1d330b4 e58d3030 ea000002 (e7970102)
[42059.753488] ---[ end trace d9b5665c4c165fb1 ]---
[42059.758151] Kernel panic - not syncing: Fatal exception in interrupt
[42059.764541] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Russell King - ARM Linux @ 2016-11-23 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123154829.GA2489@afzalpc>
On Wed, Nov 23, 2016 at 09:18:29PM +0530, Afzal Mohammed wrote:
> multi_v7_defconfig & MMU disabled, stderr was more verbose and was
> unhappy with Kconfig dependencies,
Well, !MMU and multiplatform _are_ exclusive in reality. One of the
things we work around in multiplatform is the different physical
address space layouts of the platforms, particularly with where RAM
is located. That's not possible in !MMU configurations. A kernel
built to support every platform in multiplatform will not boot on
most of them.
So efforts to make !MMU work with multiplatform are IMHO rather
misguided.
!MMU makes sense with classifications of systems (like the Cortex-M*
based systems) but not everything.
--
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
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Kalle Valo @ 2016-11-23 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123191539.GF2799@io.lakedaemon.net>
Jason Cooper <jason@lakedaemon.net> writes:
> All,
>
> I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
> board (Marvell Armada 370 SoC). Every day or so I get a consistent
> crash that brings down the whole board. I've attached three oops I
> captured on the serial port.
>
> I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
> at me as "this would fix it". And since it takes a day or so to trigger
> the oops, bisecting would be a bit brutal. Does anyone have any insight
> into this?
Is this a regression, meaning that it didn't crash on older kernels but
crashes on newer ones? Or has it always crashed?
--
Kalle Valo
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a8cqgfpp.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
On Wed, Nov 23, 2016 at 09:26:42PM +0200, Kalle Valo wrote:
> Jason Cooper <jason@lakedaemon.net> writes:
> > I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
> > board (Marvell Armada 370 SoC). Every day or so I get a consistent
> > crash that brings down the whole board. I've attached three oops I
> > captured on the serial port.
> >
> > I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
> > at me as "this would fix it". And since it takes a day or so to trigger
> > the oops, bisecting would be a bit brutal. Does anyone have any insight
> > into this?
>
> Is this a regression, meaning that it didn't crash on older kernels but
> crashes on newer ones? Or has it always crashed?
iirc, it's always done this. It's one of my spare wifi backhauls that
spends most of it's time in a cardboard box waiting for a task,
collecting dust. Kinda like the toys in Toy Story.
I pulled it out a month or so ago and the behavior started. It had
4.2.8 on it at the time. I upgraded to latest stable a few weeks ago
(v4.8.6) and I'm getting the same issue.
When I originally set it up, it didn't run long enough for me to recall
if the issue occurred. Best I recall, that was with v4.2.8.
thx,
Jason.
^ permalink raw reply
* [PATCH 2/4] serial: 8250: Add LED trigger support
From: kbuild test robot @ 2016-11-23 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123100106.15969-3-s.hauer@pengutronix.de>
Hi Sascha,
[auto build test ERROR on tty/tty-testing]
[also build test ERROR on v4.9-rc6 next-20161123]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sascha-Hauer/serial-core-Add-LED-trigger-support/20161124-010846
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
config: m32r-m32104ut_defconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r
All errors (new ones prefixed by >>):
>> ERROR: "uart_led_trigger_rx" [drivers/tty/serial/8250/8250_base.ko] undefined!
>> ERROR: "uart_led_trigger_tx" [drivers/tty/serial/8250/8250_base.ko] undefined!
>> ERROR: "uart_remove_led_triggers" [drivers/tty/serial/8250/8250.ko] undefined!
>> ERROR: "uart_add_led_triggers" [drivers/tty/serial/8250/8250.ko] undefined!
--
>> ERROR: "uart_led_trigger_rx" [drivers/tty/serial/8250/8250_base.ko] undefined!
>> ERROR: "uart_led_trigger_tx" [drivers/tty/serial/8250/8250_base.ko] undefined!
>> ERROR: "uart_remove_led_triggers" [drivers/tty/serial/8250/8250.ko] undefined!
>> ERROR: "uart_add_led_triggers" [drivers/tty/serial/8250/8250.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 10628 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/2ef736c6/attachment.gz>
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Russell King - ARM Linux @ 2016-11-23 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123191539.GF2799@io.lakedaemon.net>
On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> ------- oops from v4.8.6 #2 ------------------------------------------
> [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> [42059.311799] pgd = c0004000
> [42059.314522] [00000020] *pgd=00000000
> [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> [42059.340613] task: c0b091c0 task.stack: c0b00000
> [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
Well, the good news is that it's reproducable.
It looks like it could be this:
static int
ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
{
for_each_online_cpu(i)
ret += relay_buf_full(rc->buf[i]);
where i = 8 (r2) and rc->buf is r7. That's just a guess though, as
there's precious little to go on with the Code: line - modern GCCs
don't give us much with the Code: line anymore to figure out what's
going on without the exact object files.
e5933000 ldr r3, [r3]
e1d330b4 ldrh r3, [r3, #4]
e58d3030 str r3, [sp, #48] ; 0x30
ea000002 b 1c <foo+0x1c>
e7970102 ldr r0, [r7, r2, lsl #2]
What makes me wonder though is that if i=8, that means you must have a
system with 9 online CPUs, which is probably unlikely - or maybe that's
the problem, for_each_online_cpu() is going wrong...
If it's not that line of code, I don't see what else it would be based
on the output of my compiler - there's only one case in my disassembly
that corresponds with the single code line that we have to go on, and
it's this:
a44: e5983020 ldr r3, [r8, #32]
a48: e793010a ldr r0, [r3, sl, lsl #2] <===
a4c: ebfffffe bl 0 <relay_buf_full>
a50: e0844000 add r4, r4, r0
a54: e59f9434 ldr r9, [pc, #1076]
a58: e28a2001 add r2, sl, #1
a5c: e3a01004 mov r1, #4
a60: e1a00009 mov r0, r9
a64: ebfffffe bl 0 <_find_next_bit_le>
a68: e5953000 ldr r3, [r5]
a6c: e1500003 cmp r0, r3
a70: e1a0a000 mov sl, r0
a74: bafffff2 blt a44 <ath_cmn_process_fft+0xa8>
I'm debating now about whether we need to dump more of the code in the
oops - both before and after the faulting instruction...
--
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 V3 0/8] IOMMU probe deferral support
From: Robin Murphy @ 2016-11-23 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002b01d24340$5d56e730$1804b590$@codeaurora.org>
On 20/11/16 15:11, Sricharan wrote:
> Hi Robin,
>
>> Hi Robin,
>>
>>> Hi Robin,
>>>
>>>> On 04/11/16 15:16, Sricharan wrote:
>>>>> Hi Robin,
>>>>>
>>>>>>>> Yikes, on second look, that definitely shouldn't be happening.
>>>>>>>> Everything below is probably the resulting fallout.
>>>>>>>
>>>>>>> [ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>>>>>>>
>>>>>>> I think the above print which says "failed to setup iommu_ops"
>>>>>>> because the call ops->add_device failed in of_pci_iommu_configure
>>>>>>> is the reason for the failure, in my case i simply do not get this even with
>>>>>>> your scripts. ops->add_device succeeds in the rebind as well. So still
>>>>>>> checking what could be happening in your case.
>>>>>>
>>>>>> I was looking at your code base from [1].The ops->add_device
>>>>>> callback from of_pci_iommu_configure on the rebind is the
>>>>>> one which is causing the failure. But not able to spot out
>>>>> >from code which point is causing the failure. It would be very helpful
>>>>>> if i can know which is the return value from the add_device callback
>>>>>> or point inside add_device callback which fails in your setup.
>>>>>>
>>>>>>
>>>>>> [1] git://linux-arm.org/linux-rm iommu/misc
>>>>>
>>>>> With little more try, i saw an issue where i had an failure
>>>>> similar to what you reported. The issue happens when multiple
>>>>> devices fall in to same group due to matching sids. I ended up
>>>>> doing a fix like below and it would be nice to verify if it is the same
>>>>> that we are seeing in your setup and if the fix makes a difference ?
>>>>>
>>>>> From: Sricharan R <sricharan@codeaurora.org>
>>>>> Date: Fri, 4 Nov 2016 20:28:49 +0530
>>>>> Subject: [PATCH] iommu/arm-smmu: Fix group's reference counting
>>>>>
>>>>> iommu_group_get_for_dev which gets called in the add_device
>>>>> callback, increases the reference count of the iommu_group,
>>>>> so we do an iommu_group_put after that. iommu_group_get_for_dev
>>>>> inturn calls device_group callback and in the case of arm-smmu
>>>>> we call generic_device_group/pci_device_group which takes
>>>>> care of increasing the group's reference. But when we return
>>>>> an already existing group(when multiple devices have same group)
>>>>> the reference is not incremented, resulting in issues when the
>>>>> remove_device callback for the devices is invoked.
>>>>> Fixing the same here.
>>>>
>>>> Bah, yes, this does look like my fault - after flip-flopping between
>>>> about 3 different ways to keep refcounts for the S2CR entries, none of
>>>> which would quite work, I ripped it all out but apparently still got
>>>> things wrong, oh well. Thanks for figuring it out.
>>>>
>>>> On the probe-deferral angle, whilst it's useful to have uncovered this
>>>> bug, I don't think we should actually be calling remove_device() from
>>>> DMA teardown. I think it's preferable from a user perspective if group
>>>> numbering remains stable, rather than changing depending on the order in
>>>> which they unbind/rebind VFIO drivers. I'm really keen to try and get
>>>> this in shape for 4.10, so I've taken the liberty of hacking up my own
>>>> branch (iommu/defer) based on v3 - would you mind taking a look at the
>>>> two "iommu/of:" commits to see what you think? (Ignore the PCI changes
>>>> to your later patches - that was an experiment which didn't really work out)
>>>
>>> Ok, will take a look at this now and respond more on this.
>>>
>> Sorry for the delayed response on this. I was OOO for the last few days.
>> So i tested this branch and it worked fine. I tested it with a pci device
>> for both normal and deferred probe cases. The of/iommu patches
>> are the cleanup/preparation patches and it looks fine. One thing is without
>> calling the remove_device callback, the resources like (smes for exmaple)
>> and the group association of the device all remain allocated. That does not
>> feel correct, given that the associated device does not exist. So to
>> understand that, what happens with VFIO in this case which makes the
>> group renumbering/rebinding a problem ?
>>
>
> Would it be ok if i post a V4 based on your branch above ?
Sure, as long as none of the hacks slip through :) - I've just pushed
out a mild rework based on Lorenzo's v9, which I hope shouldn't break
anything for you.
Having thought a bit more about the add/remove thing, I'm inclined to
agree that the group numbering itself may not be that big an issue in
practice - sure, it could break my little script, but it looks like QEMU
and such work with the device ID rather than the group number directly,
so might not even notice. However, the fact remains that the callbacks
are intended to handle a device being added to/removed from its bus, and
will continue to do so on other platforms, so I don't like the idea of
introducing needlessly different behaviour. If you unbind a driver, the
stream IDs and everything don't stop existing at the hardware level; the
struct device to which the in-kernel data belongs still exists and
doesn't stop being associated with its bus. There's no good reason for
freeing SMEs that we'll only reallocate again (inadequately-specced
hardware with not enough SMRs/contexts is not a *good* reason), and
there are also some strong arguments against letting any stream IDs the
kernel knows about go back to bypass after a driver has been bound - by
keeping groups around as expected that's something we can implement
quite easily without having to completely lock down bypass for stream
IDs the kernel *doesn't* know about.
Robin.
>
> Regards,
> Sricharan
>
^ permalink raw reply
* [PATCH] clk: bcm2835: Fix ->fixed_divider of pllh_aux
From: Stephen Boyd @ 2016-11-23 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122204528.18435-1-eric@anholt.net>
On 11/22, Eric Anholt wrote:
> From: Boris Brezillon <boris.brezillon@free-electrons.com>
>
> There is no fixed divider on pllh_aux.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> Reviewed-by: Eric Anholt <eric@anholt.net>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: kbuild test robot @ 2016-11-23 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123100106.15969-2-s.hauer@pengutronix.de>
Hi Sascha,
[auto build test WARNING on tty/tty-testing]
[also build test WARNING on v4.9-rc6 next-20161123]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sascha-Hauer/serial-core-Add-LED-trigger-support/20161124-010846
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule.
include/linux/init.h:1: warning: no structured comments found
include/linux/workqueue.h:392: warning: No description found for parameter '...'
include/linux/workqueue.h:392: warning: Excess function parameter 'args' description in 'alloc_workqueue'
include/linux/workqueue.h:413: warning: No description found for parameter '...'
include/linux/workqueue.h:413: warning: Excess function parameter 'args' description in 'alloc_ordered_workqueue'
include/linux/kthread.h:26: warning: No description found for parameter '...'
kernel/sys.c:1: warning: no structured comments found
drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
include/linux/fence-array.h:61: warning: No description found for parameter 'fence'
>> drivers/tty/serial/serial_core.c:2773: warning: Excess function parameter 'drv' description in 'uart_remove_led_triggers'
include/sound/core.h:324: warning: No description found for parameter '...'
include/sound/core.h:335: warning: No description found for parameter '...'
include/sound/core.h:388: warning: No description found for parameter '...'
include/media/media-entity.h:1054: warning: No description found for parameter '...'
include/net/mac80211.h:2148: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:2153: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:3202: ERROR: Unexpected indentation.
include/net/mac80211.h:3205: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:3207: ERROR: Unexpected indentation.
include/net/mac80211.h:3208: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:1435: WARNING: Inline emphasis start-string without end-string.
include/net/mac80211.h:1172: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:1173: WARNING: Inline literal start-string without end-string.
include/net/mac80211.h:814: ERROR: Unexpected indentation.
include/net/mac80211.h:815: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:820: ERROR: Unexpected indentation.
include/net/mac80211.h:821: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:2489: ERROR: Unexpected indentation.
include/net/mac80211.h:1768: ERROR: Unexpected indentation.
include/net/mac80211.h:1772: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:1746: WARNING: Inline emphasis start-string without end-string.
kernel/sched/fair.c:7259: WARNING: Inline emphasis start-string without end-string.
kernel/time/timer.c:1240: ERROR: Unexpected indentation.
kernel/time/timer.c:1242: ERROR: Unexpected indentation.
kernel/time/timer.c:1243: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:121: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:124: ERROR: Unexpected indentation.
include/linux/wait.h:126: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/time/hrtimer.c:1021: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/signal.c:317: WARNING: Inline literal start-string without end-string.
drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent.
drivers/message/fusion/mptbase.c:5054: WARNING: Definition list ends without a blank line; unexpected unindent.
drivers/tty/serial/serial_core.c:1897: WARNING: Definition list ends without a blank line; unexpected unindent.
include/linux/spi/spi.h:369: ERROR: Unexpected indentation.
WARNING: dvipng command 'dvipng' cannot be run (needed for math display), check the imgmath_dvipng setting
vim +2773 drivers/tty/serial/serial_core.c
2757 err_alloc:
2758 kfree(uport->led_trigger_tx_name);
2759 kfree(uport->led_trigger_rx_name);
2760
2761 return ret;
2762 }
2763
2764 /**
2765 * uart_remove_led_triggers - remove LED triggers
2766 * @drv: pointer to the uart low level driver structure for this port
2767 * @uport: uart port structure to use for this port.
2768 *
2769 * Remove LED triggers previously registered with uart_add_led_triggers
2770 */
2771 void uart_remove_led_triggers(struct uart_port *uport)
2772 {
> 2773 if (uport->led_trigger_rx)
2774 led_trigger_unregister_simple(uport->led_trigger_rx);
2775 kfree(uport->led_trigger_rx_name);
2776
2777 if (uport->led_trigger_tx)
2778 led_trigger_unregister_simple(uport->led_trigger_tx);
2779 kfree(uport->led_trigger_tx_name);
2780 }
2781
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6425 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/298326e0/attachment.gz>
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Don Dutile @ 2016-11-23 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83d7bf8e-1aa9-b61b-4e83-ba9da1926d19@jonmasters.org>
On 11/21/2016 12:13 AM, Jon Masters wrote:
> On 11/07/2016 07:45 PM, Will Deacon wrote:
>
>> I figured this was a reasonable post to piggy-back on for the LPC minutes
>> relating to guest MSIs on arm64.
>
> Thanks for this Will. I'm still digging out post-LPC and SC16, but the
> summary was much appreciated, and I'm glad the conversation is helping.
>
>> 1. The physical memory map is not standardised (Jon pointed out that
>> this is something that was realised late on)
>
> Just to note, we discussed this one about 3-4 years ago. I recall making
> a vigorous slideshow at a committee meeting in defense of having a
> single memory map for ARMv8 servers and requiring everyone to follow it.
> I was weak. I listened to the comments that this was "unreasonable".
> Instead, I consider it was unreasonable of me to not get with the other
> OS vendors and force things to be done one way. The lack of a "map at
> zero" RAM location on ARMv8 has been annoying enough for 32-bit DMA only
> devices on 64-bit (behind an SMMU but in passthrough mode it doesn't
> help) and other issues beyond fixing the MSI doorbell regions. If I ever
> have a time machine, I tried harder.
>
>> Jon pointed out that most people are pretty conservative about hardware
>> choices when migrating between them -- that is, they may only migrate
>> between different revisions of the same SoC, or they know ahead of time
>> all of the memory maps they want to support and this could be communicated
>> by way of configuration to libvirt.
>
> I think it's certainly reasonable to assume this in an initial
> implementation and fix it later. Currently, we're very conservative
> about host CPU passthrough anyway and can't migrate from one microarch
> to another revision of the same microarch even. And on x86, nobody
> really supports e.g. Intel to AMD and back again. I've always been of
Thats primarily due to diff virt implentations ... vme vs svm.
1) thats not the case here; can argue cross arch variations .. gicv2 vs gicv3 vs gicv4 ...
but cross vendor should work if arch and common feature map (like x86 libvirt can resolve)
is provided
2) second chance to do it better; look n learn!
and common thread i am trying to drive home here ... learn from past mistakes *and* good choices.
> the mind that we should ensure the architecture can handle this, but
> then cautiously approach this with a default to not doing it.
>
>> Alex asked if there was a security
>> issue with DMA bypassing the SMMU, but there aren't currently any systems
>> where that is known to happen. Such a system would surely not be safe for
>> passthrough.
>
> There are other potential security issues that came up but don't need to
> be noted here (yet). I have wanted to clarify the SBSA for a long time
> when it comes to how IOMMUs should be implemented. It's past time that
> we went back and had a few conversations about that. I've poked.
>
>> Ben mused that a way to handle conflicts dynamically might be to hotplug
>> on the entire host bridge in the guest, passing firmware tables describing
>> the new reserved regions as a property of the host bridge. Whilst this
>> may well solve the issue, it was largely considered future work due to
>> its invasive nature and dependency on firmware tables (and guest support)
>> that do not currently exist.
>
> Indeed. It's an elegant solution (thanks Ben) that I gather POWER
> already does (good for them). We've obviously got a few things to clean
> up after we get the basics in place. Again, I think we can consider it
> reasonable that the MSI doorbell regions are predetermined on system A
> well ahead of any potential migration (that may or may not then work)
> for the moment. Vendors will want to loosen this later, and they can
> drive the work to do that, for example by hotplugging a host bridge.
>
> Jon.
>
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC r8a7745 SYSC Driver Updates for v4.10
From: Simon Horman @ 2016-11-23 20:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
Please consider these Renesas ARM based SoC r8a7745 SYSC Driver updates for
v4.10.
This pull request is based on v4.9-rc1.
This pull request is broken out of an earlier pull request,
"Second Round of Renesas ARM Based SoC Drivers Updates for v4.10".
The motivation for breaking up the pull request is to provide
branches with minimal dependencies.
This pull request is targeted at the next/drivers branch of the arm-soc tree.
It introduces some minor merge conflicts in:
Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt
drivers/soc/renesas/Makefile
drivers/soc/renesas/rcar-sysc.c
drivers/soc/renesas/rcar-sysc.h
The resolution is to take both sides. A sample merge resolution is
provided in the renesas-next-20161123v2-v4.9-rc1 tag of the renesas tree.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-r8a7745-sysc-for-v4.10
for you to fetch changes up to 141723e0cbdc1139410f77d8a572f17ce2de6bf5:
soc: renesas: rcar-sysc: add R8A7745 support (2016-11-23 14:28:41 +0100)
----------------------------------------------------------------
Renesas ARM Based SoC r8a7745 SYSC Driver Updates for v4.10
* Add support for the r8a7745 SoC to rcar-sysc
----------------------------------------------------------------
Sergei Shtylyov (2):
ARM: shmobile: r8a7745: add power domain index macros
soc: renesas: rcar-sysc: add R8A7745 support
.../bindings/power/renesas,rcar-sysc.txt | 1 +
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r8a7745-sysc.c | 32 ++++++++++++++++++++++
drivers/soc/renesas/rcar-sysc.c | 3 ++
drivers/soc/renesas/rcar-sysc.h | 1 +
include/dt-bindings/power/r8a7745-sysc.h | 25 +++++++++++++++++
6 files changed, 63 insertions(+)
create mode 100644 drivers/soc/renesas/r8a7745-sysc.c
create mode 100644 include/dt-bindings/power/r8a7745-sysc.h
^ 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