* [PATCH] pinctrl: sunxi: fix theoretical uninitialized variable access
From: Arnd Bergmann @ 2016-11-17 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYk25q9P5sErnfHcH49BT43vCCDihsZNEsf-6Gvpq+Pww@mail.gmail.com>
On Thursday, November 17, 2016 10:08:28 AM CET Linus Walleij wrote:
> On Wed, Nov 16, 2016 at 9:33 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>
> > On Wed, Nov 16, 2016 at 03:18:18PM +0100, Arnd Bergmann wrote:
> >> gcc warns about a way that it could use an uninitialized variable:
> >>
> >> drivers/pinctrl/sunxi/pinctrl-sunxi.c: In function 'sunxi_pinctrl_init':
> >> drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: error: 'best_div' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >>
> >> This cannot really happen except if 'freq' is UINT_MAX and 'clock' is
> >> zero, and both of these are forbidden. To shut up the warning anyway,
> >> this changes the logic to initialize the return code to the first
> >> divider value before looking at the others.
> >>
> >> Fixes: 7c926492d38a ("pinctrl: sunxi: Add support for interrupt debouncing")
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Thanks for that patch.
> >
> > Just out of curiosity, which gcc gives those warnings? I have 6.2 and
> > it didn't output anything..
>
> Context: Arnd re-enabled -Werror=maybe-uninitialized
> in the kernel build and this kind of stuff started to appear so
> it needs to be fixed up.
Right, it was disabled from linux-4.8-rc1 to linux-4.9-rc4 and is now back
in the default builds when using gcc-4.9 or higher. You should get the
warning if you test with linux-next or -rc4.
Arnd
^ permalink raw reply
* [PATCH v16 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Xiongfeng Wang @ 2016-11-17 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <944d11ac-3c0d-72c0-6888-df8e474e21bb@huawei.com>
Sorry for not describing specifically in the last mail.
I have applied all the patches of this patchset on Linux 4.9, and tested
the per-cpu timer and sbsa watchdog part, which function well on D05 board.
On 2016/11/17 11:34, Xiongfeng Wang wrote:
> Tested-by: wangxiongfeng2 at huawei.com on D05 board.
>
>
> On 2016/11/16 21:48, fu.wei at linaro.org wrote:
>> From: Fu Wei <fu.wei@linaro.org>
>>
>> This patchset:
>> (1)Preparation for adding GTDT support in arm_arch_timer:
>> 1. Move some enums and marcos to header file;
>> 2. Add a new enum for spi type;
>> 3. Improve printk relevant code.
>> 4. rename some enums and defines, and some cleanups.
>> 5. separate out arch_timer_uses_ppi init code and fix a potential bug
>> 6. Refactor arch_timer_detect_rate to keep dt code only in *_of_init
>> 7. Refactor arch_timer_needs_probing, and call it only if acpi disabled.
>> 8. Introduce some new structs and refactor the timer init code
>>
>> (2)Introduce ACPI GTDT parser: drivers/acpi/arm64/acpi_gtdt.c
>> Parse all kinds of timer in GTDT table of ACPI:arch timer,
>> memory-mapped timer and SBSA Generic Watchdog timer.
>> This driver can help to simplify all the relevant timer drivers,
>> and separate all the ACPI GTDT knowledge from them.
>>
>> (3)Simplify ACPI code for arm_arch_timer
>>
>> (4)Add GTDT support for ARM memory-mapped timer, also refactor
>> original memory-mapped timer dt support for reusing some common
>> code.
>>
>> This patchset has been tested on the following platforms with ACPI enabled:
>> (1)ARM Foundation v8 model
>>
>> Changelog:
>> v16: https://lkml.org/lkml/2016/
>> Fix patchset problem about static enum ppi_nr of 01/13 in v15.
>> Refactor arch_timer_detect_rate.
>> Refactor arch_timer_needs_probing.
>>
>> v15: https://lkml.org/lkml/2016/11/15/366
>> Re-order patches
>> Add arm_arch_timer refactoring patches to prepare for GTDT:
>> 1. rename some enums and defines, and some cleanups
>> 2. separate out arch_timer_uses_ppi init code and fix a potential bug
>> 3. Improve some new structs, refactor the timer init code.
>> Since the some structs have been changed, GTDT parser for memory-mapped
>> timer and SBSA Generic Watchdog timer have been update.
>>
>> v14: https://lkml.org/lkml/2016/9/28/573
>> Separate memory-mapped timer GTDT support into two patches
>> 1. Refactor the timer init code to prepare for GTDT
>> 2. Add GTDT support for memory-mapped timer
>>
>> v13: http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1231717.html
>> Improve arm_arch_timer code for memory-mapped
>> timer GTDT support, refactor original memory-mapped timer
>> dt support for reusing some common code.
>>
>> v12: https://lkml.org/lkml/2016/9/13/250
>> Rebase to latest Linux 4.8-rc6
>> Delete the confusing "skipping" in the error message.
>>
>> V11: https://lkml.org/lkml/2016/9/6/354
>> Rebase to latest Linux 4.8-rc5
>> Delete typedef (suggested by checkpatch.pl)
>>
>> V10: https://lkml.org/lkml/2016/7/26/215
>> Drop the "readq" patch.
>> Rebase to latest Linux 4.7.
>>
>> V9: https://lkml.org/lkml/2016/7/25/345
>> Improve pr_err message in acpi gtdt driver.
>> Update Commit message for 7/9
>> shorten the irq mapping function name
>> Improve GTDT driver for memory-mapped timer
>>
>> v8: https://lkml.org/lkml/2016/7/19/660
>> Improve "pr_fmt(fmt)" definition: add "ACPI" in front of "GTDT",
>> and also improve printk message.
>> Simplify is_timer_block and is_watchdog.
>> Merge acpi_gtdt_desc_init and gtdt_arch_timer_init into acpi_gtdt_init();
>> Delete __init in include/linux/acpi.h for GTDT API
>> Make ARM64 select GTDT.
>> Delete "#include <linux/module.h>" from acpi_gtdt.c
>> Simplify GT block parse code.
>>
>> v7: https://lkml.org/lkml/2016/7/13/769
>> Move the GTDT driver to drivers/acpi/arm64
>> Add add the ARM64-specific ACPI Support maintainers in MAINTAINERS
>> Merge 3 patches of GTDT parser driver.
>> Fix the for_each_platform_timer bug.
>>
>> v6: https://lkml.org/lkml/2016/6/29/580
>> split the GTDT driver to 4 parts: basic, arch_timer, memory-mapped timer,
>> and SBSA Generic Watchdog timer
>> Improve driver by suggestions and example code from Daniel Lezcano
>>
>> v5: https://lkml.org/lkml/2016/5/24/356
>> Sorting out all patches, simplify the API of GTDT driver:
>> GTDT driver just fills the data struct for arm_arch_timer driver.
>>
>> v4: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006667.html
>> Delete the kvm relevant patches
>> Separate two patches for sorting out the code for arm_arch_timer.
>> Improve irq info export code to allow missing irq info in GTDT table.
>>
>> v3: https://lkml.org/lkml/2016/2/1/658
>> Improve GTDT driver code:
>> (1)improve pr_* by defining pr_fmt(fmt)
>> (2)simplify gtdt_sbsa_gwdt_init
>> (3)improve gtdt_arch_timer_data_init, if table is NULL, it will try
>> to get GTDT table.
>> Move enum ppi_nr to arm_arch_timer.h, and add enum spi_nr.
>> Add arm_arch_timer get ppi from DT and GTDT support for kvm.
>>
>> v2: https://lkml.org/lkml/2015/12/2/10
>> Rebase to latest kernel version(4.4-rc3).
>> Fix the bug about the config problem,
>> use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c
>>
>> v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553
>>
>> Fu Wei (15):
>> clocksource/drivers/arm_arch_timer: Move enums and defines to header
>> file
>> clocksource/drivers/arm_arch_timer: Add a new enum for spi type
>> clocksource/drivers/arm_arch_timer: Improve printk relevant code
>> clocksource/drivers/arm_arch_timer: rename some enums and defines, and
>> some cleanups.
>> clocksource/drivers/arm_arch_timer: fix a bug in arch_timer_register
>> about arch_timer_uses_ppi
>> clocksource/drivers/arm_arch_timer: separate out arch_timer_uses_ppi
>> init code to prepare for GTDT.
>> clocksource/drivers/arm_arch_timer: Refactor arch_timer_detect_rate to
>> keep dt code in *_of_init
>> clocksource/drivers/arm_arch_timer: Refactor arch_timer_needs_probing,
>> and call it only if acpi disabled.
>> clocksource/drivers/arm_arch_timer: Introduce some new structs to
>> prepare for GTDT
>> clocksource/drivers/arm_arch_timer: Refactor the timer init code to
>> prepare for GTDT
>> acpi/arm64: Add GTDT table parse driver
>> clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
>> acpi/arm64: Add memory-mapped timer support in GTDT driver
>> clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped
>> timer
>> acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver
>>
>> arch/arm64/Kconfig | 1 +
>> drivers/acpi/arm64/Kconfig | 3 +
>> drivers/acpi/arm64/Makefile | 1 +
>> drivers/acpi/arm64/gtdt.c | 411 +++++++++++++++++++++++++++++
>> drivers/clocksource/arm_arch_timer.c | 484 ++++++++++++++++++++---------------
>> drivers/watchdog/Kconfig | 1 +
>> include/clocksource/arm_arch_timer.h | 61 ++++-
>> include/linux/acpi.h | 8 +
>> virt/kvm/arm/hyp/timer-sr.c | 6 +-
>> 9 files changed, 759 insertions(+), 217 deletions(-)
>> create mode 100644 drivers/acpi/arm64/gtdt.c
>>
>
>
> .
>
^ permalink raw reply
* [PATCH] pinctrl: sunxi: fix theoretical uninitialized variable access
From: Maxime Ripard @ 2016-11-17 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYk25q9P5sErnfHcH49BT43vCCDihsZNEsf-6Gvpq+Pww@mail.gmail.com>
On Thu, Nov 17, 2016 at 10:08:28AM +0100, Linus Walleij wrote:
> On Wed, Nov 16, 2016 at 9:33 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>
> > On Wed, Nov 16, 2016 at 03:18:18PM +0100, Arnd Bergmann wrote:
> >> gcc warns about a way that it could use an uninitialized variable:
> >>
> >> drivers/pinctrl/sunxi/pinctrl-sunxi.c: In function 'sunxi_pinctrl_init':
> >> drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: error: 'best_div' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >>
> >> This cannot really happen except if 'freq' is UINT_MAX and 'clock' is
> >> zero, and both of these are forbidden. To shut up the warning anyway,
> >> this changes the logic to initialize the return code to the first
> >> divider value before looking at the others.
> >>
> >> Fixes: 7c926492d38a ("pinctrl: sunxi: Add support for interrupt debouncing")
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Thanks for that patch.
> >
> > Just out of curiosity, which gcc gives those warnings? I have 6.2 and
> > it didn't output anything..
>
> Context: Arnd re-enabled -Werror=maybe-uninitialized
> in the kernel build and this kind of stuff started to appear so
> it needs to be fixed up.
Ah, that makes sense. 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/20161117/0d8e7790/attachment.sig>
^ permalink raw reply
* [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Linus Walleij @ 2016-11-17 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117060633.3837-1-andrew@aj.id.au>
On Thu, Nov 17, 2016 at 7:06 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> +* Device tree bindings for the Aspeed LPC Controller
We are going overboard with the lingo sometimes, to the point that we do not
understand how terse things become.
LPC = Low Pin Count, right?
Explain that right here: it is a slow external bus, right?
> +The Aspeed LPC controller contains registers for a variety of functions. Not
> +all registers for a function are contiguous, and some registers are referenced
> +by functions outside the LPC controller.
> +
> +Note that this is separate from the H8S/2168 compatible register set occupying
> +the start of the LPC controller address space.
> +
> +Some significant functions in the LPC controller:
> +
> +* LPC Host Controller
> +* Host Interface Controller
Host interface to what?
> +* iBT Controller
What is iBT?
> +* SuperIO Scratch registers
Again more context please.
With standards documents, either explain everything or provide
pointers for the information.
Yours,
Linus Walleij
^ permalink raw reply
* wdt, gpio: move arch_initcall into subsys_initcall ?
From: Vladimir Zapolskiy @ 2016-11-17 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582D5750.4000408@denx.de>
Hello Heiko,
On 11/17/2016 09:08 AM, Heiko Schocher wrote:
> Hello Guenter, Vladimir,
>
> Sorry for the late response, but I was "on the road" ...
>
> Am 15.11.2016 um 14:46 schrieb Guenter Roeck:
>> On 11/15/2016 03:32 AM, Vladimir Zapolskiy wrote:
>>> On 11/15/2016 01:10 PM, Vladimir Zapolskiy wrote:
>>>> Hello Heiko,
>>>>
>>>> On 11/15/2016 12:20 PM, Heiko Schocher wrote:
>>>>> Hello,
>>>>>
>>>>> commit e188cbf7564f: "gpio: mxc: shift gpio_mxc_init() to
>>>>> subsys_initcall level"
>>>>> moves the gpio initialization of the mxc gpio driver
>>>>> from the arch_initcall level into subsys_initcall level.
>>>>>
>>>>> This leads now on mxc boards, which use a gpio wdt driver
>>>>> and the CONFIG_GPIO_WATCHDOG_ARCH_INITCALL option enabled,
>>>>> to unwanted driver probe deferrals during kernel boot.
>>>>>
>>>>> I see this currently on an imx6 based board (which has unfortunately
>>>>> 3 WDT: imx6 internal (disabled), gpio wdt and da9063 WDT ...).
>>>>>
>>>>> Also a side effect from above commit is, that the da9063 WDT driver
>>>>> is now probed before the gpio WDT driver ... so /dev/watchdog now
>>>>> does not point to the gpio_wdt, instead it points to the da9063 WDT.
>>>>>
>>>>> So there are 2 solutions possible:
>>>>>
>>>>> - add a CONFIG_GPIO_MCX_ARCH_INITCALL option
>>>>> in drivers/gpio/gpio-mxc.c like for the gpio_wdt.c driver?
>>>>
>>>> in my opinion this is overly heavy solution and it might be
>>>> better to avoid it if possible.
>>>>
>>>> I would rather prefer to reconsider GPIO_WATCHDOG_ARCH_INITCALL
>>>> usage in the watchdog driver.
>>>>
>>>> Moreover adding this proposed GPIO_MCX_ARCH_INITCALL to call
>>>> the driver on arch level will result in deferring the GPIO driver.
>>>>
>>>>> But how can we guarantee, that first the gpio driver and then
>>>>> the gpio_wdt driver gets probed?
>>>>>
>>>>> - move the arch_initcall in gpio_wdt.c into a subsys_initcall
>>>>> (Tested this, and the probe dereferral messages are gone ...)
>>>>>
>>>>> But this may results in problems on boards, which needs an early
>>>>> trigger on an gpio wdt ...
>>>>
>>>> The level of "earliness" can not be defined in absolute time value
>>>> in any case, why decreasing the init level of the watchdog driver
>>>> to subsys level can cause problems? For that there should exist
>>>> some kind of a dependency on IC or PCB hardware level, can you
>>>> name it please?
>
> On the current problem, there is no dependency on PCB, but I know
> of watchdogs triggered through a gpio pin, which must triggered < 1 second
> and subsys_initcall is too late for this. I think, this was the reason
This is not a valid reason, nobody guarantees that arch_initcall()
code is run in < 1 second time interval.
> for introducing the CONFIG_GPIO_WATCHDOG_ARCH_INITCALL option ...
>
Putting GPIO driver on arch_initcall() level results in deferring
of the GPIO driver. Because you desire to avoid probe deferring, you
should not consider putting GPIO driver on arch_initcall() level.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins
From: Chen-Yu Tsai @ 2016-11-17 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In the past, all the MMC pins had
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
which was actually a no-op. We were relying on U-boot to set the bias
pull up for us. These properties were removed as part of the fix up to
actually support no bias on the pins. During the transition some boards
experienced regular MMC time-outs during normal operation, while others
completely failed to initialize the SD card.
Given that MMC starts in open-drain mode and the pull-ups are required,
it's best to enable it for all the pin settings.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 1 +
arch/arm/boot/dts/sun5i.dtsi | 1 +
arch/arm/boot/dts/sun6i-a31.dtsi | 4 ++++
arch/arm/boot/dts/sun7i-a20.dtsi | 2 ++
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 3 +++
arch/arm/boot/dts/sun8i-a83t.dtsi | 1 +
arch/arm/boot/dts/sun8i-h3.dtsi | 3 +++
arch/arm/boot/dts/sun9i-a80.dtsi | 3 +++
8 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index dae838e4dd9e..ba20b48c0702 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -1023,6 +1023,7 @@
"PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc0_cd_pin_reference_design: mmc0_cd_pin at 0 {
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 7ab6b336533e..54170147040f 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -582,6 +582,7 @@
"PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc2_pins_a: mmc2 at 0 {
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 7ea1116c7c88..20a0331ddfb5 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -547,6 +547,7 @@
"PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc1_pins_a: mmc1 at 0 {
@@ -554,6 +555,7 @@
"PG4", "PG5";
function = "mmc1";
drive-strength = <30>;
+ bias-pull-up;
};
mmc2_pins_a: mmc2 at 0 {
@@ -571,6 +573,7 @@
"PC24";
function = "mmc2";
drive-strength = <30>;
+ bias-pull-up;
};
mmc3_8bit_emmc_pins: mmc3 at 1 {
@@ -580,6 +583,7 @@
"PC24";
function = "mmc3";
drive-strength = <40>;
+ bias-pull-up;
};
uart0_pins_a: uart0 at 0 {
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 34d613b0dd73..a1ee4197129a 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -1179,6 +1179,7 @@
"PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc0_cd_pin_reference_design: mmc0_cd_pin at 0 {
@@ -1200,6 +1201,7 @@
"PI7", "PI8", "PI9";
function = "mmc3";
drive-strength = <30>;
+ bias-pull-up;
};
ps20_pins_a: ps20 at 0 {
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index ecb49a5a7615..bc3e936edfcf 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -293,6 +293,7 @@
"PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc1_pins_a: mmc1 at 0 {
@@ -300,6 +301,7 @@
"PG3", "PG4", "PG5";
function = "mmc1";
drive-strength = <30>;
+ bias-pull-up;
};
mmc2_8bit_pins: mmc2_8bit {
@@ -309,6 +311,7 @@
"PC15", "PC16";
function = "mmc2";
drive-strength = <30>;
+ bias-pull-up;
};
pwm0_pins: pwm0 {
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 656cdb5f7a88..79eaa7139f43 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -171,6 +171,7 @@
"PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
uart0_pins_a: uart0 at 0 {
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 416b825ddb9f..fca66bf2dec5 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -348,6 +348,7 @@
"PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc0_cd_pin: mmc0_cd_pin at 0 {
@@ -361,6 +362,7 @@
"PG4", "PG5";
function = "mmc1";
drive-strength = <30>;
+ bias-pull-up;
};
mmc2_8bit_pins: mmc2_8bit {
@@ -370,6 +372,7 @@
"PC15", "PC16";
function = "mmc2";
drive-strength = <30>;
+ bias-pull-up;
};
spi0_pins: spi0 {
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index b97db1df0803..7231d2c90dde 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -696,6 +696,7 @@
"PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+ bias-pull-up;
};
mmc1_pins: mmc1 {
@@ -703,6 +704,7 @@
"PG4", "PG5";
function = "mmc1";
drive-strength = <30>;
+ bias-pull-up;
};
mmc2_8bit_pins: mmc2_8bit {
@@ -712,6 +714,7 @@
"PC16";
function = "mmc2";
drive-strength = <30>;
+ bias-pull-up;
};
uart0_pins_a: uart0 at 0 {
--
2.10.2
^ permalink raw reply related
* [PATCH v16 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Daniel Lezcano @ 2016-11-17 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479304148-2965-1-git-send-email-fu.wei@linaro.org>
On Wed, Nov 16, 2016 at 09:48:53PM +0800, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> This patchset:
> (1)Preparation for adding GTDT support in arm_arch_timer:
> 1. Move some enums and marcos to header file;
> 2. Add a new enum for spi type;
> 3. Improve printk relevant code.
> 4. rename some enums and defines, and some cleanups.
> 5. separate out arch_timer_uses_ppi init code and fix a potential bug
> 6. Refactor arch_timer_detect_rate to keep dt code only in *_of_init
> 7. Refactor arch_timer_needs_probing, and call it only if acpi disabled.
> 8. Introduce some new structs and refactor the timer init code
>
> (2)Introduce ACPI GTDT parser: drivers/acpi/arm64/acpi_gtdt.c
> Parse all kinds of timer in GTDT table of ACPI:arch timer,
> memory-mapped timer and SBSA Generic Watchdog timer.
> This driver can help to simplify all the relevant timer drivers,
> and separate all the ACPI GTDT knowledge from them.
>
> (3)Simplify ACPI code for arm_arch_timer
>
> (4)Add GTDT support for ARM memory-mapped timer, also refactor
> original memory-mapped timer dt support for reusing some common
> code.
>
> This patchset has been tested on the following platforms with ACPI enabled:
> (1)ARM Foundation v8 model
>
> Changelog:
> v16: https://lkml.org/lkml/2016/
> Fix patchset problem about static enum ppi_nr of 01/13 in v15.
> Refactor arch_timer_detect_rate.
> Refactor arch_timer_needs_probing.
Most of the patches are touching drivers/clocksource and others acpi.
Through which tree this patchset should go ?
^ permalink raw reply
* [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Martin Sperl @ 2016-11-17 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117021107.GA2647@localhost.localdomain>
On 17.11.2016 03:11, Eduardo Valentin wrote:
> Hey Martin,
>
> Very sorry for the late feedback. Not so sure if this one got queued
> already or not. Anyways, just minor questions as follows:
>
> On Wed, Nov 02, 2016 at 10:18:22AM +0000, kernel at martin.sperl.org wrote:
>> From: Martin Sperl <kernel@martin.sperl.org>
>>
>> Add basic thermal driver for bcm2835 SOC.
>>
>> This driver currently relies on the firmware setting up the
>> tsense HW block and does not set it up itself.
>>
>> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
>> Acked-by: Eric Anholt <eric@anholt.net>
>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>>
...
>> +static int bcm2835_thermal_adc2temp(
>> + const struct bcm2835_thermal_info *info, u32 adc)
>> +{
>> + return info->offset + (adc * info->slope);
>
> Any specific reason we cannot use thermal_zone_params->slope and
> thermal_zone_params->offset?
You could - the patch was just rebased to 4.9 and those slope and
offset just got merged during this cycle.
Do we really need to modify it - the patch has been around since 4.6.
>> +
>> +static int bcm2835_thermal_get_trip_temp(
>> + struct thermal_zone_device *tz, int trip, int *temp)
>> +{
>> + struct bcm2835_thermal_data *data = tz->devdata;
>> + u32 val = readl(data->regs + BCM2835_TS_TSENSCTL);
>> +
>> + /* get the THOLD bits */
>> + val &= BCM2835_TS_TSENSCTL_THOLD_MASK;
>> + val >>= BCM2835_TS_TSENSCTL_THOLD_SHIFT;
>> +
>> + /* if it is zero then use the info value */
>> + if (val)
>
> Is this a read only register or is this driver supposed to program it?
> In which scenario it would be 0? Can this be added as comments?
It is RW, but the Firmware typically sets up the thermal device with the
correct values already - this is just a fallback.
>> +static int bcm2835_thermal_get_temp(struct thermal_zone_device *tz,
>> + int *temp)
>> +{
>> + struct bcm2835_thermal_data *data = tz->devdata;
>> + u32 val = readl(data->regs + BCM2835_TS_TSENSSTAT);
>> +
>> + if (!(val & BCM2835_TS_TSENSSTAT_VALID))
>
> What cases you would get the valid bit not set? Do you need to wait for
> the conversion to finish?
I guess: if you have just enabled the HW-block (which the FW does much
in advance) and start to read the value immediately (before the first
sample period has finished), then this will not be valid.
So do you need another version of the patchset that uses that new API?
Thanks,
Martin
^ permalink raw reply
* [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Vinod Koul @ 2016-11-17 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117063646.GE28340@tuxbot>
On Wed, Nov 16, 2016 at 10:36:46PM -0800, Bjorn Andersson wrote:
> On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:
>
> > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > >
> > > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > > without providing Linus with a messy merge conflict.
> > > >
> > > > So the remoteproc parts now has to go through my tree.
> > >
> > > OK, I think the best approach is for Vinod to create an immutable
> > > branch with the entire fdma series on, and then both of you merge that branch into
> > > your respective trees.
> >
> > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> > tag, please do let me know
> >
>
> Hi Vinod,
>
> It looks like you reverted the wrong Kconfig fix, the one I objected to
> was the change in drivers/remoteproc, not the one in drivers/dma.
>
> The ST_FMDA depends on functions exposed by REMOTEPROC and
> ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
> guys made user selectable - and as such should not be selected - but I
> think we should move forward and get everything merged and then we can
> go back and figure out how this should be addressed (or left alone?).
>
> I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
> now broken drivers/remoteproc/Kconfig.
>
> We do however both need to revert the revert or there will be link
> errors if you build the dma driver with remoteproc=n. If you do this I
> can merge the topic once more and we'll keep the set of changes in sync.
Oops my bad, thanks for letting me know. I have reverted this now and
pushing out. Please do let me know if this was fine
Thanks
--
~Vinod
^ permalink raw reply
* [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Joel Stanley @ 2016-11-17 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4751029.AudB7s5avo@wuerfel>
On Thu, Nov 17, 2016 at 7:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 17, 2016 4:36:33 PM CET Andrew Jeffery wrote:
>> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>> ---
>>
>> I'd like to start a discussion about how to handle the LPC register space in
>> the Aspeed SoC. There are a number of issues, largely concerned with the layout
>> of the registers but also with the fact that LPC register state is used by the
>> pinmux to determine some pin functionality.
> ...
>>
>> What is the recommended approach to managing such hardware?
>
> Can you clarify which side of the LPC bus this is? We are currently having
> a discussion for how to integrate the LPC master on an ARM64 server that
> uses LPC to access an Aspeed LPC slave. For this one we want to use the
> traditional ISA DT binding.
This is from the perspective of the BMC.
On the machines we are talking to, most (all?) access is performed
through the system firmware (skiboot).
> I'm guessing that you are interesting in the other side here, for mapping
> the registers of the LPC slave on the Aspeed BMC, but that's not clear from
> your email, as I'm assuming that the same chip has both master and slave
> interfaces.
Yep, we come from the "other side".
The BMC itself can operate the bus in Master or Slave mode. We are
interested in the slave case, for when the host is requesting access
to its system firmware at boot time. This happens by mapping a region
of the BMC's AHB memory space into the LPC address space. After we
deal with pinmux, Andrew or I will be hacking on a driver to configure
that space, as the BMC needs to configure the window before the host
can boot. It's a pile of bits spread out over different parts of the
chip, and doesn't map nicely into any existing driver model we have in
the kernel.
Other functions include IPMI communication between the BMC and the
host via the LPC bus via the iBT interface. We have a driver for that
staged for 4.10. Then there's a mailbox, some "scratch" registers that
can be used by the firmware for whatever they see fit, and all kinds
of crazy legacy x86 stuff like POST code registers.
Cheers,
Joel
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-17 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgTjG8G0U+A1p7hOKND9rjY4BzZfPgyWWHAEryYkHj_UOw@mail.gmail.com>
On Wed, 2016-11-16 at 22:36 +0530, Anand Moon wrote:
> ?Hi Jerome.
>
> On 15 November 2016 at 19:59, Jerome Brunet <jbrunet@baylibre.com>
> wrote:
> >
> > On some platforms, energy efficient ethernet with rtl8211 devices
> > is
> > causing issue, like throughput drop or broken link.
> >
> > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the
> > issue root
> > cause is not fully understood yet, disabling EEE advertisement
> > prevent auto
> > negotiation from enabling EEE.
> >
> > This patch provides options to disable 1000T and 100TX EEE
> > advertisement
> > individually for the realtek phys supporting this feature.
> >
> > Reported-by: Martin Blumenstingl <martin.blumenstingl@googlemail.co
> > m>
> > Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> > Cc: Alexandre TORGUE <alexandre.torgue@st.com>
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > Tested-by: Andre Roth <neolynx@gmail.com>
> > ---
> > ?drivers/net/phy/realtek.c | 65
> > ++++++++++++++++++++++++++++++++++++++++++++++-
> > ?1 file changed, 64 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> > index aadd6e9f54ad..77235fd5faaf 100644
> > --- a/drivers/net/phy/realtek.c
> > +++ b/drivers/net/phy/realtek.c
> > @@ -15,6 +15,12 @@
> > ? */
> > ?#include <linux/phy.h>
> > ?#include <linux/module.h>
> > +#include <linux/of.h>
> > +
> > +struct rtl8211x_phy_priv {
> > +???????bool eee_1000t_disable;
> > +???????bool eee_100tx_disable;
> > +};
> >
> > ?#define RTL821x_PHYSR??????????0x11
> > ?#define RTL821x_PHYSR_DUPLEX???0x2000
> > @@ -93,12 +99,44 @@ static int rtl8211f_config_intr(struct
> > phy_device *phydev)
> > ????????return err;
> > ?}
> >
> > +static void rtl8211x_clear_eee_adv(struct phy_device *phydev)
> > +{
> > +???????struct rtl8211x_phy_priv *priv = phydev->priv;
> > +???????u16 val;
> > +
> > +???????if (priv->eee_1000t_disable || priv->eee_100tx_disable) {
> > +???????????????val = phy_read_mmd_indirect(phydev,
> > MDIO_AN_EEE_ADV,
> > +???????????????????????????????????????????MDIO_MMD_AN);
> > +
> > +???????????????if (priv->eee_1000t_disable)
> > +???????????????????????val &= ~MDIO_AN_EEE_ADV_1000T;
> > +???????????????if (priv->eee_100tx_disable)
> > +???????????????????????val &= ~MDIO_AN_EEE_ADV_100TX;
> > +
> > +???????????????phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV,
> > +??????????????????????????????????????MDIO_MMD_AN, val);
> > +???????}
> > +}
> > +
> > +static int rtl8211x_config_init(struct phy_device *phydev)
> > +{
> > +???????int ret;
> > +
> > +???????ret = genphy_config_init(phydev);
> > +???????if (ret < 0)
> > +???????????????return ret;
> > +
> > +???????rtl8211x_clear_eee_adv(phydev);
> > +
> > +???????return 0;
> > +}
> > +
> > ?static int rtl8211f_config_init(struct phy_device *phydev)
> > ?{
> > ????????int ret;
> > ????????u16 reg;
> >
> > -???????ret = genphy_config_init(phydev);
> > +???????ret = rtl8211x_config_init(phydev);
> > ????????if (ret < 0)
> > ????????????????return ret;
> >
> > @@ -115,6 +153,26 @@ static int rtl8211f_config_init(struct
> > phy_device *phydev)
> > ????????return 0;
> > ?}
> >
> > +static int rtl8211x_phy_probe(struct phy_device *phydev)
> > +{
> > +???????struct device *dev = &phydev->mdio.dev;
> > +???????struct device_node *of_node = dev->of_node;
> > +???????struct rtl8211x_phy_priv *priv;
> > +
> > +???????priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > +???????if (!priv)
> > +???????????????return -ENOMEM;
> > +
> > +???????priv->eee_1000t_disable =
> > +???????????????of_property_read_bool(of_node, "realtek,disable-
> > eee-1000t");
> > +???????priv->eee_100tx_disable =
> > +???????????????of_property_read_bool(of_node, "realtek,disable-
> > eee-100tx");
> > +
> > +???????phydev->priv = priv;
> > +
> > +???????return 0;
> > +}
> > +
> > ?static struct phy_driver realtek_drvs[] = {
> > ????????{
> > ????????????????.phy_id?????????= 0x00008201,
> > @@ -140,7 +198,9 @@ static struct phy_driver realtek_drvs[] = {
> > ????????????????.phy_id_mask????= 0x001fffff,
> > ????????????????.features???????= PHY_GBIT_FEATURES,
> > ????????????????.flags??????????= PHY_HAS_INTERRUPT,
> > +???????????????.probe??????????= &rtl8211x_phy_probe,
> > ????????????????.config_aneg????= genphy_config_aneg,
> > +???????????????.config_init????= &rtl8211x_config_init,
> > ????????????????.read_status????= genphy_read_status,
> > ????????????????.ack_interrupt??= rtl821x_ack_interrupt,
> > ????????????????.config_intr????= rtl8211e_config_intr,
> > @@ -152,7 +212,9 @@ static struct phy_driver realtek_drvs[] = {
> > ????????????????.phy_id_mask????= 0x001fffff,
> > ????????????????.features???????= PHY_GBIT_FEATURES,
> > ????????????????.flags??????????= PHY_HAS_INTERRUPT,
> > +???????????????.probe??????????= &rtl8211x_phy_probe,
> > ????????????????.config_aneg????= &genphy_config_aneg,
> > +???????????????.config_init????= &rtl8211x_config_init,
> > ????????????????.read_status????= &genphy_read_status,
> > ????????????????.ack_interrupt??= &rtl821x_ack_interrupt,
> > ????????????????.config_intr????= &rtl8211e_config_intr,
> > @@ -164,6 +226,7 @@ static struct phy_driver realtek_drvs[] = {
> > ????????????????.phy_id_mask????= 0x001fffff,
> > ????????????????.features???????= PHY_GBIT_FEATURES,
> > ????????????????.flags??????????= PHY_HAS_INTERRUPT,
> > +???????????????.probe??????????= &rtl8211x_phy_probe,
> > ????????????????.config_aneg????= &genphy_config_aneg,
> > ????????????????.config_init????= &rtl8211f_config_init,
> > ????????????????.read_status????= &genphy_read_status,
> > --
> > 2.7.4
> >
>
> How about adding callback functionality for .soft_reset to handle
> BMCR
> where we update the Auto-Negotiation for the phy,
> as per the datasheet of the rtl8211f.
I'm not sure I understand how this would help with our issue (and EEE).
Am I missing something or is it something unrelated that you would like
to see happening on this driver ??
>
> -Best Regard
> Anand Moon
>
> >
> >
> > _______________________________________________
> > linux-amlogic mailing list
> > linux-amlogic at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Vinod Koul @ 2016-11-17 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b33d23d-b7c5-6e6d-454f-755c86ddd5eb@samsung.com>
On Wed, Nov 16, 2016 at 06:31:13PM +0100, Sylwester Nawrocki wrote:
> On 11/16/2016 06:03 PM, Krzysztof Kozlowski wrote:
> > As I understood, everything won't be applied because ASoC tree already
> > contains some work around this?
>
> Yes, sorry, I didn't coordinate this work very well, there are some patches
> for the pcm and the i2s driver already in the ASoC tree which would conflict
> with this series. I'd suggest to ignore patches 5/8...8/8 for now.
Okay, applied 1 thru 4 now after fixing subsystem name on 1st.
Anyone wants to pull can fetch topic/s3c64xx
Thanks
--
~Vinod
^ permalink raw reply
* [RFC PATCH] mfd: dt: Add Aspeed LPC binding
From: Joel Stanley @ 2016-11-17 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdazPEbU2gmDyke=GTYtjVp8aeauS+PVkp-zuiVoVz7kbw@mail.gmail.com>
Hey Linus,
On Thu, Nov 17, 2016 at 8:00 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Nov 17, 2016 at 7:06 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
>
>> +* Device tree bindings for the Aspeed LPC Controller
>
> We are going overboard with the lingo sometimes, to the point that we do not
> understand how terse things become.
>
> LPC = Low Pin Count, right?
> Explain that right here: it is a slow external bus, right?
Yep. 33MHz bus that generally connects a host CPU to other devices on
the same motherboard, such as management controllers.
https://en.wikipedia.org/wiki/Low_Pin_Count
Systems with Aspeed BMCs use the LPC to load the firmware from the BMC
into the host at boot, and send IPMI messages between the host and the
BMC.
BMC stands for Baseboard Management Controller. Back in the day it was
simple keyboard controller microcontroller, these days we use a 800MHz
ARM11 with half a gigabyte of RAM. It provides access to the boot
firmware for the host CPU, monitors the health of the system (fans,
temperature, error logging), and provides remote access for power
cycling and installation.
https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller
Andrew and I work on an open source project that is creating a new BMC
software stack called OpenBMC. You've been merging the wonderful
Aspeed pinmux patches that Andrew wrote recently, which was a major
bit of kernel work required for that project.
>> +The Aspeed LPC controller contains registers for a variety of functions. Not
>> +all registers for a function are contiguous, and some registers are referenced
>> +by functions outside the LPC controller.
>> +
>> +Note that this is separate from the H8S/2168 compatible register set occupying
>> +the start of the LPC controller address space.
>> +
>> +Some significant functions in the LPC controller:
>> +
>> +* LPC Host Controller
>> +* Host Interface Controller
>
> Host interface to what?
Host in this case is the CPU on the motherboard to do the heavy
lifting. x86, ARM64, PowerPC. So this is the BMC's interface to the
host.
>
>> +* iBT Controller
>
> What is iBT?
IPMI Byte Transfer? Something like that. It's the transport that the
host uses to send IPMI messages to the BMC and back.
The host side has been upstream for a while. The BMC side has a driver
staged for v4.10:
https://patchwork.ozlabs.org/patch/674973/
If you're really bored you can read up on IPMI from the specificaiton:
http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html
tl;dr is it's a protocol for communication to the BMC. There is
in-band IPMI, which is between the host and the BMC over the eg. the
BT interface. Or out of band IPMI, which is where you use ipmitool
from your laptop to talk to the BMC over the network.
>
>> +* SuperIO Scratch registers
>
> Again more context please.
The SuperIO name is legacy x86 terminology. These are a few bytes
worth of data that can be set from one side and read by the other in
order to convey firmware-specific information. In OpenPower systems,
we use them to tell the host where to send it's console output when it
is booting.
> With standards documents, either explain everything or provide
> pointers for the information.
If only we could give you the pleasure of reading the Aspeed reference
manual. It's only available from Aspeed under NDA at this point in
time though. If you want further details on anything else then Andrew,
Ben or myself can explain.
Cheers,
Joel
^ permalink raw reply
* [PATCH 4.8 65/92] Revert "clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init"
From: Greg Kroah-Hartman @ 2016-11-17 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117103224.218007793@linuxfoundation.org>
4.8-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen-Yu Tsai <wens@csie.org>
commit 593876838826914a7e4e05fbbcb728be6fbc4d89 upstream.
struct clocksource is also used by the clk notifier callback, to
unregister and re-register the clocksource with a different clock rate.
clocksource_mmio_init does not pass back a pointer to the struct used,
and the clk notifier callback assumes that the struct clocksource in
struct sun5i_timer_clksrc is valid. This results in a kernel NULL
pointer dereference when the hstimer clock is changed:
Unable to handle kernel NULL pointer dereference at virtual address 00000004
[<c03a4678>] (clocksource_unbind) from [<c03a46d4>] (clocksource_unregister+0x2c/0x44)
[<c03a46d4>] (clocksource_unregister) from [<c0a6f350>] (sun5i_rate_cb_clksrc+0x34/0x3c)
[<c0a6f350>] (sun5i_rate_cb_clksrc) from [<c035ea50>] (notifier_call_chain+0x44/0x84)
[<c035ea50>] (notifier_call_chain) from [<c035edc0>] (__srcu_notifier_call_chain+0x44/0x60)
[<c035edc0>] (__srcu_notifier_call_chain) from [<c035edf4>] (srcu_notifier_call_chain+0x18/0x20)
[<c035edf4>] (srcu_notifier_call_chain) from [<c0670174>] (__clk_notify+0x70/0x7c)
[<c0670174>] (__clk_notify) from [<c06702c0>] (clk_propagate_rate_change+0xa4/0xc4)
[<c06702c0>] (clk_propagate_rate_change) from [<c0670288>] (clk_propagate_rate_change+0x6c/0xc4)
Revert the commit for now. clocksource_mmio_init can be made to pass back
a pointer, but the code churn and usage of an inner struct might not be
worth it.
Fixes: 157dfadef832 ("clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init")
Reported-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Cc: linux-sunxi at googlegroups.com
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/20161018054918.26855-1-wens at csie.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clocksource/timer-sun5i.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -152,6 +152,13 @@ static irqreturn_t sun5i_timer_interrupt
return IRQ_HANDLED;
}
+static cycle_t sun5i_clksrc_read(struct clocksource *clksrc)
+{
+ struct sun5i_timer_clksrc *cs = to_sun5i_timer_clksrc(clksrc);
+
+ return ~readl(cs->timer.base + TIMER_CNTVAL_LO_REG(1));
+}
+
static int sun5i_rate_cb_clksrc(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -210,8 +217,13 @@ static int __init sun5i_setup_clocksourc
writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
base + TIMER_CTL_REG(1));
- ret = clocksource_mmio_init(base + TIMER_CNTVAL_LO_REG(1), node->name,
- rate, 340, 32, clocksource_mmio_readl_down);
+ cs->clksrc.name = node->name;
+ cs->clksrc.rating = 340;
+ cs->clksrc.read = sun5i_clksrc_read;
+ cs->clksrc.mask = CLOCKSOURCE_MASK(32);
+ cs->clksrc.flags = CLOCK_SOURCE_IS_CONTINUOUS;
+
+ ret = clocksource_register_hz(&cs->clksrc, rate);
if (ret) {
pr_err("Couldn't register clock source.\n");
goto err_remove_notifier;
^ permalink raw reply
* [PATCH] Replacement for Arm initrd memblock reserve and free inconsistency.
From: william.helsby at stfc.ac.uk @ 2016-11-17 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116234741.GE1041@n2100.armlinux.org.uk>
My understanding of your proposed patch is that it rounds the area to be reserved for the initrd image to page
boundaries. It then checks that this rounding does not grow the initrd to overlap other areas.
If it does not overlap, all is well. The kernel will not kmalloc anything within the partial pages
at the beginning and end of the initrd image. When the initrd image is freed, complete pages are
released and there is no wasted memory.
However, if it does overlap other regions, it disables the initrd image and the kernel panics with no root file system.
My patch rounds the area to be reserved for the initrd image to page boundaries.
It then checks that this rounding does not grow the initrd to overlap other areas.
If it does not overlap the system initialised the ramdisk from the initrd image and then frees the initrd area
with no wasted memory. All is good.
If it does overlap, my code tried to determine the cause of the overlap and fell back to, in the worst case,
just reserving the space actually occupied by the initrd image. In this case the kernel would start,
initialise the ramdisk and try to free the initrd image. At worst 2 partial pages at the beginning and end of
the initrd image would not be freed, wasting up to 8kBytes.
To me this is a more acceptable fallback than deleting the root file system.
Also not that in the current code free_initrd_mem checks:
if (end == initrd_end)
end = round_up(end, PAGE_SIZE);
So only rounds up the end if the whole initrd image is being freed.
If free_initrd_mem is called with end != initrd_end (because the crash kernel area overlaps),
then the end is not rounded up.
However:
poison_init_mem((void *)start, PAGE_ALIGN(end) - start);
will still page align the end address and could potentially overwrite the crash kernel area.
I don't know anything about if and when the crash kernel area is used, but in principle this may be a bad thing.
William.
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at armlinux.org.uk]
Sent: 16 November 2016 23:48
To: Helsby, William (STFC,DL,TECH)
Cc: linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH] Replacement for Arm initrd memblock reserve and free inconsistency.
On Tue, Nov 15, 2016 at 03:45:55PM +0000, william.helsby at stfc.ac.uk wrote:
> The option of moving the initrd code later (after
> early_init_fdt_reserve_self();
> early_init_fdt_scan_reserved_mem() ) was tested.
Moving stuff around tends to break...
I'd prefer to do it this way, as it's much more readable (and we prize readability... see Documentation/CodingStyle.)
arch/arm/mm/init.c | 71 +++++++++++++++++++++++++++++++++---------------------
1 file changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 370581aeb871..ffae20b25929 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -227,6 +227,48 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t align)
return phys;
}
+static void __init arm_initrd_init(void) { #ifdef CONFIG_BLK_DEV_INITRD
+ unsigned long size;
+ phys_addr_t start;
+
+ /* FDT scan will populate initrd_start */
+ if (initrd_start && !phys_initrd_size) {
+ phys_initrd_start = __virt_to_phys(initrd_start);
+ phys_initrd_size = initrd_end - initrd_start;
+ }
+
+ initrd_start = initrd_end = 0;
+
+ if (!phys_initrd_size)
+ return;
+
+ start = phys_initrd_start & PAGE_MASK;
+ size = PAGE_ALIGN(phys_initrd_size + phys_initrd_start - start);
+
+ if (!memblock_is_region_memory(start, size)) {
+ pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling initrd\n",
+ (u64)start, size);
+ phys_initrd_start = phys_initrd_size = 0;
+ return;
+ }
+
+ if (memblock_is_region_reserved(start, size)) {
+ pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory region - disabling initrd\n",
+ (u64)start, size);
+ phys_initrd_start = phys_initrd_size = 0;
+ return;
+ }
+
+ memblock_reserve(start, size);
+
+ /* Now convert initrd to virtual addresses */
+ initrd_start = __phys_to_virt(phys_initrd_start);
+ initrd_end = initrd_start + phys_initrd_size; #endif }
+
void __init arm_memblock_init(const struct machine_desc *mdesc) {
/* Register the kernel text, kernel data and initrd with memblock. */ @@ -235,34 +277,7 @@ void __init arm_memblock_init(const struct machine_desc *mdesc) #else
memblock_reserve(__pa(_stext), _end - _stext); #endif -#ifdef CONFIG_BLK_DEV_INITRD
- /* FDT scan will populate initrd_start */
- if (initrd_start && !phys_initrd_size) {
- phys_initrd_start = __virt_to_phys(initrd_start);
- phys_initrd_size = initrd_end - initrd_start;
- }
- initrd_start = initrd_end = 0;
- if (phys_initrd_size &&
- !memblock_is_region_memory(phys_initrd_start, phys_initrd_size)) {
- pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region - disabling initrd\n",
- (u64)phys_initrd_start, phys_initrd_size);
- phys_initrd_start = phys_initrd_size = 0;
- }
- if (phys_initrd_size &&
- memblock_is_region_reserved(phys_initrd_start, phys_initrd_size)) {
- pr_err("INITRD: 0x%08llx+0x%08lx overlaps in-use memory region - disabling initrd\n",
- (u64)phys_initrd_start, phys_initrd_size);
- phys_initrd_start = phys_initrd_size = 0;
- }
- if (phys_initrd_size) {
- memblock_reserve(phys_initrd_start, phys_initrd_size);
-
- /* Now convert initrd to virtual addresses */
- initrd_start = __phys_to_virt(phys_initrd_start);
- initrd_end = initrd_start + phys_initrd_size;
- }
-#endif
-
+ arm_initrd_init();
arm_mm_memblock_reserve();
/* reserve any platform specific memblock areas */
--
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
* Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'
From: Mark Rutland @ 2016-11-17 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116224024.GA11821@roeck-us.net>
On Wed, Nov 16, 2016 at 02:40:24PM -0800, Guenter Roeck wrote:
> On Wed, Nov 16, 2016 at 08:27:09PM -0200, Fabio Estevam wrote:
> > Hi Guenter,
> >
> > On Wed, Nov 16, 2016 at 8:10 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > Anyway, I guess the problem is that the "official" dtb files no longer provide
> > > the skeleton /chosen and /memory nodes (and maybe others), and qemu seems to
> > > expect that they are provided. Is that correct ?
> >
> > imx6qdl-sabrelite.dtsi provides chosen and memory nodes.
>
> Yes, but not the 'device_type' property, which the kernel seems to expect.
Memory nodes require this property per ePAPR and the devicetree.org
spec, so the bug is that we didn't add those when removing the
skeleton.dtsi include.
> The qemu patch below fixes the problem for sabrelite, I just don't know
> if that is really the way to go. You tell me; I'll be happy to submit
> the necessary patch(es) into qemu.
As above, I don't think the below patch is necessary. The dt should have
this property to begin with.
> The same is true for 'chosen'. Right now qemu expects this node to exist.
> It does exist for sabrelite, but apparently not for imx25-pdk.
Having QEMU create a /chosen node if one does not exist already sounds
sensible to me.
Thanks,
Mark.
> Guenter
>
> ---
> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
> index 1b913a4..080d1e5 100644
> --- a/hw/arm/boot.c
> +++ b/hw/arm/boot.c
> @@ -486,6 +486,12 @@ static int load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
> g_free(nodename);
> }
> } else {
> + Error *err = NULL;
> +
> + if (!qemu_fdt_getprop(fdt, "/memory", "device_type", NULL, &err)) {
> + qemu_fdt_setprop_string(fdt, "/memory", "device_type", "memory");
> + }
> +
> rc = qemu_fdt_setprop_sized_cells(fdt, "/memory", "reg",
> acells, binfo->loader_start,
> scells, binfo->ram_size);
^ permalink raw reply
* [PATCH v16 00/15] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
From: Fu Wei @ 2016-11-17 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d8b5ca3f-d756-ae2e-012c-3cabc38dd39a@huawei.com>
Hi Xiongfeng
On 17 November 2016 at 17:25, Xiongfeng Wang <wangxiongfeng2@huawei.com> wrote:
>
> Sorry for not describing specifically in the last mail.
> I have applied all the patches of this patchset on Linux 4.9, and tested
> the per-cpu timer and sbsa watchdog part, which function well on D05 board.
Thanks for your testing,
So I will apply your Tested-by in 1~8, 11, 12, 15 in my next patchset.
>
> On 2016/11/17 11:34, Xiongfeng Wang wrote:
>> Tested-by: wangxiongfeng2 at huawei.com on D05 board.
>>
>>
>> On 2016/11/16 21:48, fu.wei at linaro.org wrote:
>>> From: Fu Wei <fu.wei@linaro.org>
>>>
>>> This patchset:
>>> (1)Preparation for adding GTDT support in arm_arch_timer:
>>> 1. Move some enums and marcos to header file;
>>> 2. Add a new enum for spi type;
>>> 3. Improve printk relevant code.
>>> 4. rename some enums and defines, and some cleanups.
>>> 5. separate out arch_timer_uses_ppi init code and fix a potential bug
>>> 6. Refactor arch_timer_detect_rate to keep dt code only in *_of_init
>>> 7. Refactor arch_timer_needs_probing, and call it only if acpi disabled.
>>> 8. Introduce some new structs and refactor the timer init code
>>>
>>> (2)Introduce ACPI GTDT parser: drivers/acpi/arm64/acpi_gtdt.c
>>> Parse all kinds of timer in GTDT table of ACPI:arch timer,
>>> memory-mapped timer and SBSA Generic Watchdog timer.
>>> This driver can help to simplify all the relevant timer drivers,
>>> and separate all the ACPI GTDT knowledge from them.
>>>
>>> (3)Simplify ACPI code for arm_arch_timer
>>>
>>> (4)Add GTDT support for ARM memory-mapped timer, also refactor
>>> original memory-mapped timer dt support for reusing some common
>>> code.
>>>
>>> This patchset has been tested on the following platforms with ACPI enabled:
>>> (1)ARM Foundation v8 model
>>>
>>> Changelog:
>>> v16: https://lkml.org/lkml/2016/
>>> Fix patchset problem about static enum ppi_nr of 01/13 in v15.
>>> Refactor arch_timer_detect_rate.
>>> Refactor arch_timer_needs_probing.
>>>
>>> v15: https://lkml.org/lkml/2016/11/15/366
>>> Re-order patches
>>> Add arm_arch_timer refactoring patches to prepare for GTDT:
>>> 1. rename some enums and defines, and some cleanups
>>> 2. separate out arch_timer_uses_ppi init code and fix a potential bug
>>> 3. Improve some new structs, refactor the timer init code.
>>> Since the some structs have been changed, GTDT parser for memory-mapped
>>> timer and SBSA Generic Watchdog timer have been update.
>>>
>>> v14: https://lkml.org/lkml/2016/9/28/573
>>> Separate memory-mapped timer GTDT support into two patches
>>> 1. Refactor the timer init code to prepare for GTDT
>>> 2. Add GTDT support for memory-mapped timer
>>>
>>> v13: http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1231717.html
>>> Improve arm_arch_timer code for memory-mapped
>>> timer GTDT support, refactor original memory-mapped timer
>>> dt support for reusing some common code.
>>>
>>> v12: https://lkml.org/lkml/2016/9/13/250
>>> Rebase to latest Linux 4.8-rc6
>>> Delete the confusing "skipping" in the error message.
>>>
>>> V11: https://lkml.org/lkml/2016/9/6/354
>>> Rebase to latest Linux 4.8-rc5
>>> Delete typedef (suggested by checkpatch.pl)
>>>
>>> V10: https://lkml.org/lkml/2016/7/26/215
>>> Drop the "readq" patch.
>>> Rebase to latest Linux 4.7.
>>>
>>> V9: https://lkml.org/lkml/2016/7/25/345
>>> Improve pr_err message in acpi gtdt driver.
>>> Update Commit message for 7/9
>>> shorten the irq mapping function name
>>> Improve GTDT driver for memory-mapped timer
>>>
>>> v8: https://lkml.org/lkml/2016/7/19/660
>>> Improve "pr_fmt(fmt)" definition: add "ACPI" in front of "GTDT",
>>> and also improve printk message.
>>> Simplify is_timer_block and is_watchdog.
>>> Merge acpi_gtdt_desc_init and gtdt_arch_timer_init into acpi_gtdt_init();
>>> Delete __init in include/linux/acpi.h for GTDT API
>>> Make ARM64 select GTDT.
>>> Delete "#include <linux/module.h>" from acpi_gtdt.c
>>> Simplify GT block parse code.
>>>
>>> v7: https://lkml.org/lkml/2016/7/13/769
>>> Move the GTDT driver to drivers/acpi/arm64
>>> Add add the ARM64-specific ACPI Support maintainers in MAINTAINERS
>>> Merge 3 patches of GTDT parser driver.
>>> Fix the for_each_platform_timer bug.
>>>
>>> v6: https://lkml.org/lkml/2016/6/29/580
>>> split the GTDT driver to 4 parts: basic, arch_timer, memory-mapped timer,
>>> and SBSA Generic Watchdog timer
>>> Improve driver by suggestions and example code from Daniel Lezcano
>>>
>>> v5: https://lkml.org/lkml/2016/5/24/356
>>> Sorting out all patches, simplify the API of GTDT driver:
>>> GTDT driver just fills the data struct for arm_arch_timer driver.
>>>
>>> v4: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006667.html
>>> Delete the kvm relevant patches
>>> Separate two patches for sorting out the code for arm_arch_timer.
>>> Improve irq info export code to allow missing irq info in GTDT table.
>>>
>>> v3: https://lkml.org/lkml/2016/2/1/658
>>> Improve GTDT driver code:
>>> (1)improve pr_* by defining pr_fmt(fmt)
>>> (2)simplify gtdt_sbsa_gwdt_init
>>> (3)improve gtdt_arch_timer_data_init, if table is NULL, it will try
>>> to get GTDT table.
>>> Move enum ppi_nr to arm_arch_timer.h, and add enum spi_nr.
>>> Add arm_arch_timer get ppi from DT and GTDT support for kvm.
>>>
>>> v2: https://lkml.org/lkml/2015/12/2/10
>>> Rebase to latest kernel version(4.4-rc3).
>>> Fix the bug about the config problem,
>>> use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c
>>>
>>> v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553
>>>
>>> Fu Wei (15):
>>> clocksource/drivers/arm_arch_timer: Move enums and defines to header
>>> file
>>> clocksource/drivers/arm_arch_timer: Add a new enum for spi type
>>> clocksource/drivers/arm_arch_timer: Improve printk relevant code
>>> clocksource/drivers/arm_arch_timer: rename some enums and defines, and
>>> some cleanups.
>>> clocksource/drivers/arm_arch_timer: fix a bug in arch_timer_register
>>> about arch_timer_uses_ppi
>>> clocksource/drivers/arm_arch_timer: separate out arch_timer_uses_ppi
>>> init code to prepare for GTDT.
>>> clocksource/drivers/arm_arch_timer: Refactor arch_timer_detect_rate to
>>> keep dt code in *_of_init
>>> clocksource/drivers/arm_arch_timer: Refactor arch_timer_needs_probing,
>>> and call it only if acpi disabled.
>>> clocksource/drivers/arm_arch_timer: Introduce some new structs to
>>> prepare for GTDT
>>> clocksource/drivers/arm_arch_timer: Refactor the timer init code to
>>> prepare for GTDT
>>> acpi/arm64: Add GTDT table parse driver
>>> clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
>>> acpi/arm64: Add memory-mapped timer support in GTDT driver
>>> clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped
>>> timer
>>> acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver
>>>
>>> arch/arm64/Kconfig | 1 +
>>> drivers/acpi/arm64/Kconfig | 3 +
>>> drivers/acpi/arm64/Makefile | 1 +
>>> drivers/acpi/arm64/gtdt.c | 411 +++++++++++++++++++++++++++++
>>> drivers/clocksource/arm_arch_timer.c | 484 ++++++++++++++++++++---------------
>>> drivers/watchdog/Kconfig | 1 +
>>> include/clocksource/arm_arch_timer.h | 61 ++++-
>>> include/linux/acpi.h | 8 +
>>> virt/kvm/arm/hyp/timer-sr.c | 6 +-
>>> 9 files changed, 759 insertions(+), 217 deletions(-)
>>> create mode 100644 drivers/acpi/arm64/gtdt.c
>>>
>>
>>
>> .
>>
>
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
From: Will Deacon @ 2016-11-17 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117022023.GA5704@linaro.org>
Hi Akashi,
On Thu, Nov 17, 2016 at 02:34:24PM +0900, AKASHI Takahiro wrote:
> On Wed, Nov 16, 2016 at 04:30:15PM +0000, Will Deacon wrote:
> > I thought limit was just a physical address, and then
>
> No, it's not.
Quite right, it's a size. Sorry about that.
> > memblock_mem_limit_remove_map operated on the end of the nearest memblock?
>
> No, but "max_addr" returned by __find_max_addr() is a physical address
> and the end address of memory of "limit" size in total.
>
> > You could leave the __find_max_addr call in memblock_mem_limit_remove_map,
> > given that I don't think you need/want it for memblock_cap_memory_range.
> >
> > > So I added an extra argument, exact, to a common function to specify
> > > distinct behaviors. Confusing? Please see the patch below.
> >
> > Oh yikes, this certainly wasn't what I had in mind! My observation was
> > just that memblock_mem_limit_remove_map(limit) does:
> >
> >
> > 1. memblock_isolate_range(limit - limit+ULLONG_MAX)
> > 2. memblock_remove_region(all non-nomap regions in the isolated region)
> > 3. truncate reserved regions to limit
> >
> > and your memblock_cap_memory_range(base, size) does:
> >
> > 1. memblock_isolate_range(base - base+size)
> > 2, memblock_remove_region(all non-nomap regions above and below the
> > isolated region)
> > 3. truncate reserved regions around the isolated region
> >
> > so, assuming we can invert the isolation in one of the cases, then they
> > could share the same underlying implementation.
>
> Please see my simplified patch below which would explain what I meant.
> (Note that the size is calculated by 'max_addr - 0'.)
>
> > I'm probably just missing something here, because the patch you've ended
> > up with is far more involved than I anticipated...
>
> I hope that it will meet almost your anticipation.
It looks much better, thanks! Just one question below.
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 7608bc3..fea1688 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> (phys_addr_t)ULLONG_MAX);
> }
>
> +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> +{
> + int start_rgn, end_rgn;
> + int i, ret;
> +
> + if (!size)
> + return;
> +
> + ret = memblock_isolate_range(&memblock.memory, base, size,
> + &start_rgn, &end_rgn);
> + if (ret)
> + return;
> +
> + /* remove all the MAP regions */
> + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> + memblock_remove_region(&memblock.memory, i);
In the case that we have only one, giant memblock that covers base all
of base + size, can't we end up with start_rgn = end_rgn = 0? In which
case, we'd end up accidentally removing the map regions here.
The existing code:
> - /* remove all the MAP regions above the limit */
> - for (i = end_rgn - 1; i >= start_rgn; i--) {
> - if (!memblock_is_nomap(&type->regions[i]))
> - memblock_remove_region(type, i);
> - }
seems to handle this.
Will
^ permalink raw reply
* [PATCH] arm: dma-mapping: Reset the device's dma_ops
From: Sricharan R @ 2016-11-17 11:20 UTC (permalink / raw)
To: linux-arm-kernel
arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
,dma_ops should be cleared in the teardown path. Otherwise
this causes problem when the probe of device is retried after
being deferred. The device's iommu structures are cleared
after EPROBEDEFER error, but on the next try dma_ops will still
be set to old value, which is not right.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm/mm/dma-mapping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab4f745..a40f03e 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2358,6 +2358,7 @@ static void arm_teardown_iommu_dma_ops(struct device *dev)
__arm_iommu_detach_device(dev);
arm_iommu_release_mapping(mapping);
+ set_dma_ops(dev, NULL);
}
#else
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v8 1/7] arm/arm64: vgic: Implement support for userspace access
From: Vijay Kilari @ 2016-11-17 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116185215.GC3811@cbox>
On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Fri, Nov 04, 2016 at 04:43:27PM +0530, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>
>> Read and write of some registers like ISPENDR and ICPENDR
>> from userspace requires special handling when compared to
>> guest access for these registers.
>>
>> Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> for handling of ISPENDR, ICPENDR registers handling.
>>
>> Add infrastructure to support guest and userspace read
>> and write for the required registers
>> Also moved vgic_uaccess from vgic-mmio-v2.c to vgic-mmio.c
>>
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> ---
>> virt/kvm/arm/vgic/vgic-mmio-v2.c | 25 ----------
>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 98 ++++++++++++++++++++++++++++++++--------
>> virt/kvm/arm/vgic/vgic-mmio.c | 78 ++++++++++++++++++++++++++++----
>> virt/kvm/arm/vgic/vgic-mmio.h | 19 ++++++++
>> 4 files changed, 169 insertions(+), 51 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> index b44b359..0b32f40 100644
>> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
>> @@ -406,31 +406,6 @@ int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
>> return -ENXIO;
>> }
>>
>> -/*
>> - * When userland tries to access the VGIC register handlers, we need to
>> - * create a usable struct vgic_io_device to be passed to the handlers and we
>> - * have to set up a buffer similar to what would have happened if a guest MMIO
>> - * access occurred, including doing endian conversions on BE systems.
>> - */
>> -static int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
>> - bool is_write, int offset, u32 *val)
>> -{
>> - unsigned int len = 4;
>> - u8 buf[4];
>> - int ret;
>> -
>> - if (is_write) {
>> - vgic_data_host_to_mmio_bus(buf, len, *val);
>> - ret = kvm_io_gic_ops.write(vcpu, &dev->dev, offset, len, buf);
>> - } else {
>> - ret = kvm_io_gic_ops.read(vcpu, &dev->dev, offset, len, buf);
>> - if (!ret)
>> - *val = vgic_data_mmio_bus_to_host(buf, len);
>> - }
>> -
>> - return ret;
>> -}
>> -
>> int vgic_v2_cpuif_uaccess(struct kvm_vcpu *vcpu, bool is_write,
>> int offset, u32 *val)
>> {
>> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> index 0d3c76a..ce2708d 100644
>> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> @@ -209,6 +209,62 @@ static unsigned long vgic_mmio_read_v3_idregs(struct kvm_vcpu *vcpu,
>> return 0;
>> }
>>
>> +static unsigned long vgic_v3_uaccess_read_pending(struct kvm_vcpu *vcpu,
>> + gpa_t addr, unsigned int len)
>> +{
>> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
>> + u32 value = 0;
>> + int i;
>> +
>> + /*
>> + * A level triggerred interrupt pending state is latched in both
>> + * "soft_pending" and "line_level" variables. Userspace will save
>> + * and restore soft_pending and line_level separately.
>> + * Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>> + * handling of ISPENDR and ICPENDR.
>> + */
>> + for (i = 0; i < len * 8; i++) {
>> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
>> +
>> + if (irq->config == VGIC_CONFIG_LEVEL && irq->soft_pending)
>> + value |= (1U << i);
>> + if (irq->config == VGIC_CONFIG_EDGE && irq->pending)
>> + value |= (1U << i);
>> +
>> + vgic_put_irq(vcpu->kvm, irq);
>> + }
>> +
>> + return value;
>> +}
>> +
>> +static void vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
>> + gpa_t addr, unsigned int len,
>> + unsigned long val)
>> +{
>> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
>> + int i;
>> +
>> + for (i = 0; i < len * 8; i++) {
>> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
>> +
>> + spin_lock(&irq->irq_lock);
>> + if (test_bit(i, &val)) {
>> + irq->pending = true;
>> + irq->soft_pending = true;
>
> In the vgic_mmio_write_spending function we only set the soft_pending
> state to true if the interrupt is a level-triggered interrupt.
>
> Should we check if that's the case here as well before setting the
> soft_pending state?
Yes, can be done. But it puts hard requirement that irq config should
be restored
before updating pending state.
In any case, the soft_pending is used only if interrupt is level-triggered.
>
> Otherwise, this patch looks good.
>
> Thanks,
> -Christoffer
>
^ permalink raw reply
* [PATCH fpga 1/9] fpga zynq: Add missing \n to messages
From: Matthias Brugger @ 2016-11-17 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115180813.GB1852@obsidianresearch.com>
On 15/11/16 19:08, Jason Gunthorpe wrote:
>
> On Tue, Nov 15, 2016 at 12:05:15PM +0100, Matthias Brugger wrote:
>> On 09/11/16 23:58, Jason Gunthorpe wrote:
>>> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>>
>> Please add a commit message, although it is cristal clear what this patch
>> does :)
>
> As you say, it is crystal clear already, and this is an acceptable commit
> message.. Please suggest a text if you want to see something
> different.
>
"Function dev_err doesn't add a newline at the end of the string. This
will lead to a hard to read kernel log. This patch fixes this."
With this (or something similar added):
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Regards,
Matthias
^ permalink raw reply
* [PATCH] ARM64: dma-mapping: preallocate DMA-debug hash tables in core_initcall
From: Marek Szyprowski @ 2016-11-17 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116123918.qzaqczaqri2hab43@localhost>
Hi Catalin,
On 2016-11-16 13:39, Catalin Marinas wrote:
> On Wed, Nov 16, 2016 at 10:20:13AM +0100, Marek Szyprowski wrote:
>> fs_initcall is definitely too late to initialize DMA-debug hash tables,
>> because some drivers might get probed and use DMA mapping framework
>> already in core_initcall. Late initialization of DMA-debug results in
>> false warning about accessing memory, that was not allocated. This issue
>> has been observed on ARM 32bit, but the same driver can be used also on
>> ARM64.
>>
>> This patch moves initialization of DMA-debug to core_initcall. This is
>> safe from the initialization perspective. dma_debug_do_init() internally
>> calls debugfs functions and debugfs also gets initialised at
>> core_initcall(), and that is earlier than arch code in the link order,
>> so it will get initialized just before the DMA-debug.
> Do we really want to rely on the link order within an initcall level?
> What guarantees this?
There are many places in the kernel which rely on link order and I'm
convinced
that calling initcalls in link order is guaranteed.
> I hope someone sorts out the deferred probe or some other dependency
> detection mechanism to address this issue. But in the meantime I
> wouldn't merge a patch which relies on just the link order.
This has nothing to deferred probe. This patch is related to initialization
of dma-debug framework. In my initial submission for ARM arch I proposed
pure_initcall to have this infrastructure available as early as possible,
but Russell pointed that dma-debug depends on debugfs initialization, so
it should be initialized after it. He also pointed that core_initcall will
be fine for this.
Please also note that dt devices are also populated from core_initcall and
drivers can then bind to them and try to use dma-mapping api, what results
in false warnings about using uninitialized memory as dma-debug framework
is unable to track allocations done before its initialization.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v8 1/7] arm/arm64: vgic: Implement support for userspace access
From: Christoffer Dall @ 2016-11-17 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6vbFj3aoSiqc4n_92rZgONeQVhp-GtTkEhW3=pt9P1hGQ@mail.gmail.com>
On Thu, Nov 17, 2016 at 04:56:53PM +0530, Vijay Kilari wrote:
> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Fri, Nov 04, 2016 at 04:43:27PM +0530, vijay.kilari at gmail.com wrote:
> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >>
> >> Read and write of some registers like ISPENDR and ICPENDR
> >> from userspace requires special handling when compared to
> >> guest access for these registers.
> >>
> >> Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> >> for handling of ISPENDR, ICPENDR registers handling.
> >>
> >> Add infrastructure to support guest and userspace read
> >> and write for the required registers
> >> Also moved vgic_uaccess from vgic-mmio-v2.c to vgic-mmio.c
> >>
> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >> ---
> >> virt/kvm/arm/vgic/vgic-mmio-v2.c | 25 ----------
> >> virt/kvm/arm/vgic/vgic-mmio-v3.c | 98 ++++++++++++++++++++++++++++++++--------
> >> virt/kvm/arm/vgic/vgic-mmio.c | 78 ++++++++++++++++++++++++++++----
> >> virt/kvm/arm/vgic/vgic-mmio.h | 19 ++++++++
> >> 4 files changed, 169 insertions(+), 51 deletions(-)
> >>
> >> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >> index b44b359..0b32f40 100644
> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> >> @@ -406,31 +406,6 @@ int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
> >> return -ENXIO;
> >> }
> >>
> >> -/*
> >> - * When userland tries to access the VGIC register handlers, we need to
> >> - * create a usable struct vgic_io_device to be passed to the handlers and we
> >> - * have to set up a buffer similar to what would have happened if a guest MMIO
> >> - * access occurred, including doing endian conversions on BE systems.
> >> - */
> >> -static int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> >> - bool is_write, int offset, u32 *val)
> >> -{
> >> - unsigned int len = 4;
> >> - u8 buf[4];
> >> - int ret;
> >> -
> >> - if (is_write) {
> >> - vgic_data_host_to_mmio_bus(buf, len, *val);
> >> - ret = kvm_io_gic_ops.write(vcpu, &dev->dev, offset, len, buf);
> >> - } else {
> >> - ret = kvm_io_gic_ops.read(vcpu, &dev->dev, offset, len, buf);
> >> - if (!ret)
> >> - *val = vgic_data_mmio_bus_to_host(buf, len);
> >> - }
> >> -
> >> - return ret;
> >> -}
> >> -
> >> int vgic_v2_cpuif_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> >> int offset, u32 *val)
> >> {
> >> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> index 0d3c76a..ce2708d 100644
> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> @@ -209,6 +209,62 @@ static unsigned long vgic_mmio_read_v3_idregs(struct kvm_vcpu *vcpu,
> >> return 0;
> >> }
> >>
> >> +static unsigned long vgic_v3_uaccess_read_pending(struct kvm_vcpu *vcpu,
> >> + gpa_t addr, unsigned int len)
> >> +{
> >> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> >> + u32 value = 0;
> >> + int i;
> >> +
> >> + /*
> >> + * A level triggerred interrupt pending state is latched in both
> >> + * "soft_pending" and "line_level" variables. Userspace will save
> >> + * and restore soft_pending and line_level separately.
> >> + * Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> >> + * handling of ISPENDR and ICPENDR.
> >> + */
> >> + for (i = 0; i < len * 8; i++) {
> >> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> >> +
> >> + if (irq->config == VGIC_CONFIG_LEVEL && irq->soft_pending)
> >> + value |= (1U << i);
> >> + if (irq->config == VGIC_CONFIG_EDGE && irq->pending)
> >> + value |= (1U << i);
> >> +
> >> + vgic_put_irq(vcpu->kvm, irq);
> >> + }
> >> +
> >> + return value;
> >> +}
> >> +
> >> +static void vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
> >> + gpa_t addr, unsigned int len,
> >> + unsigned long val)
> >> +{
> >> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> >> + int i;
> >> +
> >> + for (i = 0; i < len * 8; i++) {
> >> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> >> +
> >> + spin_lock(&irq->irq_lock);
> >> + if (test_bit(i, &val)) {
> >> + irq->pending = true;
> >> + irq->soft_pending = true;
> >
> > In the vgic_mmio_write_spending function we only set the soft_pending
> > state to true if the interrupt is a level-triggered interrupt.
> >
> > Should we check if that's the case here as well before setting the
> > soft_pending state?
>
> Yes, can be done. But it puts hard requirement that irq config should
> be restored
> before updating pending state.
Ah, I see.
ok, I think you should keep it the way it is then, but please add a
comment to that effect.
> In any case, the soft_pending is used only if interrupt is level-triggered.
>
Yes, indeed.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v8 0/7] arm/arm64: vgic: Implement API for vGICv3 live migration
From: Christoffer Dall @ 2016-11-17 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258013-6669-1-git-send-email-vijay.kilari@gmail.com>
Hi Vijaya,
On Fri, Nov 04, 2016 at 04:43:26PM +0530, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> This patchset adds API for saving and restoring
> of VGICv3 registers to support live migration with new vgic feature.
> This API definition is as per version of VGICv3 specification
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>
> The patch 3 & 4 are picked from the Pavel's previous implementation.
> http://www.spinics.net/lists/kvm/msg122040.html
>
> v7 => v8:
> - Rebased to 4.9-rc3
I noticed when looking at this series that there are quite a few
conflicts when applying to kvmarm/queue, so if you could rebase the next
verson on kvmarm/queue, then you'll make Marc's life a bit easier.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH 0/3] thermal: Fix module autoload for drivers
From: Javier Martinez Canillas @ 2016-11-17 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476455702-21748-1-git-send-email-javier@osg.samsung.com>
Hello Eduardo,
On Fri, Oct 14, 2016 at 11:34 AM, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> Hello,
>
> This small series contains trivial fixes to allow modules to be autoloaded
> when its correspoinding thermal device is registered.
>
> Best regards,
> Javier
>
>
> Javier Martinez Canillas (3):
> thermal: max77620: Fix module autoload
> thermal: tango: Fix module autoload
> thermal: db8500: Fix module autoload
>
Any comments about these patches?
Best regards,
Javier
^ 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