* [PATCH] convert orion5x ls-chl to device tree
From: Gregory CLEMENT @ 2016-11-07 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <636b2eb5-a23d-1e87-2bf6-5c1cc1f8332b@gmail.com>
Hi Ash,
On dim., nov. 06 2016, Ash Hughes <sehguh.hsa@gmail.com> wrote:
> Sorry about that, formatting error with tabs being converted to spaces
> in email. This should now apply.
I applied it to mvebu/dt.
Next time could you send it in a separate email?
Also, for device tree the topic should start by "ARM: dts: orion5x:".
And last point in your second version you forgot the commit log, I took
care of it too by using the one from your first version.
Thanks,
Gregory
>
> Ash
> ---
> From 398d2c6e5c834e6887a5e6b5e898455977d0c00b Mon Sep 17 00:00:00 2001
> From: Ashley Hughes <ashley.hughes@blueyonder.co.uk>
> Date: Sun, 9 Oct 2016 17:04:12 +0100
> Subject: [PATCH] convert ls-chl to FDT
>
> Signed-off-by: Ashley Hughes <ashley.hughes@blueyonder.co.uk>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/orion5x-lschl.dts | 171 ++++++++++++++++++
> arch/arm/mach-orion5x/Kconfig | 4 +-
> arch/arm/mach-orion5x/Makefile | 1 -
> arch/arm/mach-orion5x/ls-chl-setup.c | 331 -----------------------------------
> 5 files changed, 174 insertions(+), 334 deletions(-)
> create mode 100644 arch/arm/boot/dts/orion5x-lschl.dts
> delete mode 100644 arch/arm/mach-orion5x/ls-chl-setup.c
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..4853049 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -597,6 +597,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
> orion5x-lacie-ethernet-disk-mini-v2.dtb \
> orion5x-linkstation-lsgl.dtb \
> orion5x-linkstation-lswtgl.dtb \
> + orion5x-lschl.dtb \
> orion5x-lswsgl.dtb \
> orion5x-maxtor-shared-storage-2.dtb \
> orion5x-netgear-wnr854t.dtb \
> diff --git a/arch/arm/boot/dts/orion5x-lschl.dts b/arch/arm/boot/dts/orion5x-lschl.dts
> new file mode 100644
> index 0000000..9474092
> --- /dev/null
> +++ b/arch/arm/boot/dts/orion5x-lschl.dts
> @@ -0,0 +1,171 @@
> +/*
> + * Device Tree file for Buffalo Linkstation LS-CHLv3
> + *
> + * Copyright (C) 2016 Ash Hughes <ashley.hughes@blueyonder.co.uk>
> + * Copyright (C) 2015, 2016
> + * Roger Shimizu <rogershimizu@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "orion5x-linkstation.dtsi"
> +#include "mvebu-linkstation-gpio-simple.dtsi"
> +#include "mvebu-linkstation-fan.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> + model = "Buffalo Linkstation Live v3 (LS-CHL)";
> + compatible = "buffalo,lschl", "marvell,orion5x-88f5182", "marvell,orion5x";
> +
> + memory { /* 128 MB */
> + device_type = "memory";
> + reg = <0x00000000 0x8000000>;
> + };
> +
> + gpio_keys {
> + func {
> + label = "Function Button";
> + linux,code = <KEY_OPTION>;
> + gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
> + };
> +
> + power-on-switch {
> + gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
> + };
> +
> + power-auto-switch {
> + gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + gpio_leds {
> + pinctrl-0 = <&pmx_led_power &pmx_led_alarm &pmx_led_info &pmx_led_func>;
> + blue-power-led {
> + gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + red-alarm-led {
> + gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
> + };
> +
> + amber-info-led {
> + gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + func {
> + label = "lschl:func:blue:top";
> + gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + gpio_fan {
> + gpios = <&gpio0 14 GPIO_ACTIVE_LOW
> + &gpio0 16 GPIO_ACTIVE_LOW>;
> +
> + alarm-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> + };
> +};
> +
> +&pinctrl {
> + pmx_led_power: pmx-leds {
> + marvell,pins = "mpp0";
> + marvell,function = "gpio";
> + };
> +
> + pmx_power_hdd: pmx-power-hdd {
> + marvell,pins = "mpp1";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_alarm: pmx-leds {
> + marvell,pins = "mpp2";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_info: pmx-leds {
> + marvell,pins = "mpp3";
> + marvell,function = "gpio";
> + };
> +
> + pmx_fan_lock: pmx-fan-lock {
> + marvell,pins = "mpp6";
> + marvell,function = "gpio";
> + };
> +
> + pmx_power_switch: pmx-power-switch {
> + marvell,pins = "mpp8", "mpp10", "mpp15";
> + marvell,function = "gpio";
> + };
> +
> + pmx_power_usb: pmx-power-usb {
> + marvell,pins = "mpp9";
> + marvell,function = "gpio";
> + };
> +
> + pmx_fan_high: pmx-fan-high {
> + marvell,pins = "mpp14";
> + marvell,function = "gpio";
> + };
> +
> + pmx_fan_low: pmx-fan-low {
> + marvell,pins = "mpp16";
> + marvell,function = "gpio";
> + };
> +
> + pmx_led_func: pmx-leds {
> + marvell,pins = "mpp17";
> + marvell,function = "gpio";
> + };
> +
> + pmx_sw_init: pmx-sw-init {
> + marvell,pins = "mpp7";
> + marvell,function = "gpio";
> + };
> +};
> +
> +&hdd_power {
> + gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&usb_power {
> + gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
> +};
> +
> diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
> index 89bb0fc..793efa9 100644
> --- a/arch/arm/mach-orion5x/Kconfig
> +++ b/arch/arm/mach-orion5x/Kconfig
> @@ -85,8 +85,8 @@ config MACH_LINKSTATION_PRO
> v2 devices are supported.
>
> config MACH_LINKSTATION_LSCHL
> - bool "Buffalo Linkstation Live v3 (LS-CHL)"
> - select I2C_BOARDINFO if I2C
> + bool "Buffalo Linkstation Live v3 (LS-CHL) (Flattened Device Tree)"
> + select ARCH_ORION5X_DT
> help
> Say 'Y' here if you want your kernel to support the
> Buffalo Linkstation Live v3 (LS-CHL) platform.
> diff --git a/arch/arm/mach-orion5x/Makefile b/arch/arm/mach-orion5x/Makefile
> index 4b2502b..ae91872 100644
> --- a/arch/arm/mach-orion5x/Makefile
> +++ b/arch/arm/mach-orion5x/Makefile
> @@ -18,7 +18,6 @@ obj-$(CONFIG_MACH_WNR854T) += wnr854t-setup.o
> obj-$(CONFIG_MACH_RD88F5181L_GE) += rd88f5181l-ge-setup.o
> obj-$(CONFIG_MACH_RD88F5181L_FXO) += rd88f5181l-fxo-setup.o
> obj-$(CONFIG_MACH_RD88F6183AP_GE) += rd88f6183ap-ge-setup.o
> -obj-$(CONFIG_MACH_LINKSTATION_LSCHL) += ls-chl-setup.o
>
> obj-$(CONFIG_ARCH_ORION5X_DT) += board-dt.o
> obj-$(CONFIG_MACH_D2NET_DT) += board-d2net.o
> diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
> deleted file mode 100644
> index dfdaa8a..0000000
> --- a/arch/arm/mach-orion5x/ls-chl-setup.c
> +++ /dev/null
> @@ -1,331 +0,0 @@
> -/*
> - * arch/arm/mach-orion5x/ls-chl-setup.c
> - *
> - * Maintainer: Ash Hughes <ashley.hughes@blueyonder.co.uk>
> - *
> - * This file is licensed under the terms of the GNU General Public
> - * License version 2. This program is licensed "as is" without any
> - * warranty of any kind, whether express or implied.
> - */
> -
> -#include <linux/kernel.h>
> -#include <linux/init.h>
> -#include <linux/platform_device.h>
> -#include <linux/mtd/physmap.h>
> -#include <linux/mv643xx_eth.h>
> -#include <linux/leds.h>
> -#include <linux/gpio_keys.h>
> -#include <linux/gpio-fan.h>
> -#include <linux/input.h>
> -#include <linux/i2c.h>
> -#include <linux/ata_platform.h>
> -#include <linux/gpio.h>
> -#include <asm/mach-types.h>
> -#include <asm/mach/arch.h>
> -#include "common.h"
> -#include "mpp.h"
> -#include "orion5x.h"
> -
> -/*****************************************************************************
> - * Linkstation LS-CHL Info
> - ****************************************************************************/
> -
> -/*
> - * 256K NOR flash Device bus boot chip select
> - */
> -
> -#define LSCHL_NOR_BOOT_BASE 0xf4000000
> -#define LSCHL_NOR_BOOT_SIZE SZ_256K
> -
> -/*****************************************************************************
> - * 256KB NOR Flash on BOOT Device
> - ****************************************************************************/
> -
> -static struct physmap_flash_data lschl_nor_flash_data = {
> - .width = 1,
> -};
> -
> -static struct resource lschl_nor_flash_resource = {
> - .flags = IORESOURCE_MEM,
> - .start = LSCHL_NOR_BOOT_BASE,
> - .end = LSCHL_NOR_BOOT_BASE + LSCHL_NOR_BOOT_SIZE - 1,
> -};
> -
> -static struct platform_device lschl_nor_flash = {
> - .name = "physmap-flash",
> - .id = 0,
> - .dev = {
> - .platform_data = &lschl_nor_flash_data,
> - },
> - .num_resources = 1,
> - .resource = &lschl_nor_flash_resource,
> -};
> -
> -/*****************************************************************************
> - * Ethernet
> - ****************************************************************************/
> -
> -static struct mv643xx_eth_platform_data lschl_eth_data = {
> - .phy_addr = MV643XX_ETH_PHY_ADDR(8),
> -};
> -
> -/*****************************************************************************
> - * RTC 5C372a on I2C bus
> - ****************************************************************************/
> -
> -static struct i2c_board_info __initdata lschl_i2c_rtc = {
> - I2C_BOARD_INFO("rs5c372a", 0x32),
> -};
> -
> -/*****************************************************************************
> - * LEDs attached to GPIO
> - ****************************************************************************/
> -
> -#define LSCHL_GPIO_LED_ALARM 2
> -#define LSCHL_GPIO_LED_INFO 3
> -#define LSCHL_GPIO_LED_FUNC 17
> -#define LSCHL_GPIO_LED_PWR 0
> -
> -static struct gpio_led lschl_led_pins[] = {
> - {
> - .name = "alarm:red",
> - .gpio = LSCHL_GPIO_LED_ALARM,
> - .active_low = 1,
> - }, {
> - .name = "info:amber",
> - .gpio = LSCHL_GPIO_LED_INFO,
> - .active_low = 1,
> - }, {
> - .name = "func:blue:top",
> - .gpio = LSCHL_GPIO_LED_FUNC,
> - .active_low = 1,
> - }, {
> - .name = "power:blue:bottom",
> - .gpio = LSCHL_GPIO_LED_PWR,
> - },
> -};
> -
> -static struct gpio_led_platform_data lschl_led_data = {
> - .leds = lschl_led_pins,
> - .num_leds = ARRAY_SIZE(lschl_led_pins),
> -};
> -
> -static struct platform_device lschl_leds = {
> - .name = "leds-gpio",
> - .id = -1,
> - .dev = {
> - .platform_data = &lschl_led_data,
> - },
> -};
> -
> -/*****************************************************************************
> - * SATA
> - ****************************************************************************/
> -static struct mv_sata_platform_data lschl_sata_data = {
> - .n_ports = 2,
> -};
> -
> -/*****************************************************************************
> - * LS-CHL specific power off method: reboot
> - ****************************************************************************/
> -/*
> - * On the LS-CHL, the shutdown process is following:
> - * - Userland monitors key events until the power switch goes to off position
> - * - The board reboots
> - * - U-boot starts and goes into an idle mode waiting for the user
> - * to move the switch to ON position
> - *
> - */
> -
> -static void lschl_power_off(void)
> -{
> - orion5x_restart(REBOOT_HARD, NULL);
> -}
> -
> -/*****************************************************************************
> - * General Setup
> - ****************************************************************************/
> -#define LSCHL_GPIO_USB_POWER 9
> -#define LSCHL_GPIO_AUTO_POWER 17
> -#define LSCHL_GPIO_POWER 18
> -
> -/****************************************************************************
> - * GPIO Attached Keys
> - ****************************************************************************/
> -#define LSCHL_GPIO_KEY_FUNC 15
> -#define LSCHL_GPIO_KEY_POWER 8
> -#define LSCHL_GPIO_KEY_AUTOPOWER 10
> -#define LSCHL_SW_POWER 0x00
> -#define LSCHL_SW_AUTOPOWER 0x01
> -#define LSCHL_SW_FUNC 0x02
> -
> -static struct gpio_keys_button lschl_buttons[] = {
> - {
> - .type = EV_SW,
> - .code = LSCHL_SW_POWER,
> - .gpio = LSCHL_GPIO_KEY_POWER,
> - .desc = "Power-on Switch",
> - .active_low = 1,
> - }, {
> - .type = EV_SW,
> - .code = LSCHL_SW_AUTOPOWER,
> - .gpio = LSCHL_GPIO_KEY_AUTOPOWER,
> - .desc = "Power-auto Switch",
> - .active_low = 1,
> - }, {
> - .type = EV_SW,
> - .code = LSCHL_SW_FUNC,
> - .gpio = LSCHL_GPIO_KEY_FUNC,
> - .desc = "Function Switch",
> - .active_low = 1,
> - },
> -};
> -
> -static struct gpio_keys_platform_data lschl_button_data = {
> - .buttons = lschl_buttons,
> - .nbuttons = ARRAY_SIZE(lschl_buttons),
> -};
> -
> -static struct platform_device lschl_button_device = {
> - .name = "gpio-keys",
> - .id = -1,
> - .num_resources = 0,
> - .dev = {
> - .platform_data = &lschl_button_data,
> - },
> -};
> -
> -#define LSCHL_GPIO_HDD_POWER 1
> -
> -/****************************************************************************
> - * GPIO Fan
> - ****************************************************************************/
> -
> -#define LSCHL_GPIO_FAN_LOW 16
> -#define LSCHL_GPIO_FAN_HIGH 14
> -#define LSCHL_GPIO_FAN_LOCK 6
> -
> -static struct gpio_fan_alarm lschl_alarm = {
> - .gpio = LSCHL_GPIO_FAN_LOCK,
> -};
> -
> -static struct gpio_fan_speed lschl_speeds[] = {
> - {
> - .rpm = 0,
> - .ctrl_val = 3,
> - }, {
> - .rpm = 1500,
> - .ctrl_val = 2,
> - }, {
> - .rpm = 3250,
> - .ctrl_val = 1,
> - }, {
> - .rpm = 5000,
> - .ctrl_val = 0,
> - },
> -};
> -
> -static int lschl_gpio_list[] = {
> - LSCHL_GPIO_FAN_HIGH, LSCHL_GPIO_FAN_LOW,
> -};
> -
> -static struct gpio_fan_platform_data lschl_fan_data = {
> - .num_ctrl = ARRAY_SIZE(lschl_gpio_list),
> - .ctrl = lschl_gpio_list,
> - .alarm = &lschl_alarm,
> - .num_speed = ARRAY_SIZE(lschl_speeds),
> - .speed = lschl_speeds,
> -};
> -
> -static struct platform_device lschl_fan_device = {
> - .name = "gpio-fan",
> - .id = -1,
> - .num_resources = 0,
> - .dev = {
> - .platform_data = &lschl_fan_data,
> - },
> -};
> -
> -/****************************************************************************
> - * GPIO Data
> - ****************************************************************************/
> -
> -static unsigned int lschl_mpp_modes[] __initdata = {
> - MPP0_GPIO, /* LED POWER */
> - MPP1_GPIO, /* HDD POWER */
> - MPP2_GPIO, /* LED ALARM */
> - MPP3_GPIO, /* LED INFO */
> - MPP4_UNUSED,
> - MPP5_UNUSED,
> - MPP6_GPIO, /* FAN LOCK */
> - MPP7_GPIO, /* SW INIT */
> - MPP8_GPIO, /* SW POWER */
> - MPP9_GPIO, /* USB POWER */
> - MPP10_GPIO, /* SW AUTO POWER */
> - MPP11_UNUSED,
> - MPP12_UNUSED,
> - MPP13_UNUSED,
> - MPP14_GPIO, /* FAN HIGH */
> - MPP15_GPIO, /* SW FUNC */
> - MPP16_GPIO, /* FAN LOW */
> - MPP17_GPIO, /* LED FUNC */
> - MPP18_UNUSED,
> - MPP19_UNUSED,
> - 0,
> -};
> -
> -static void __init lschl_init(void)
> -{
> - /*
> - * Setup basic Orion functions. Needs to be called early.
> - */
> - orion5x_init();
> -
> - orion5x_mpp_conf(lschl_mpp_modes);
> -
> - /*
> - * Configure peripherals.
> - */
> - orion5x_ehci0_init();
> - orion5x_ehci1_init();
> - orion5x_eth_init(&lschl_eth_data);
> - orion5x_i2c_init();
> - orion5x_sata_init(&lschl_sata_data);
> - orion5x_uart0_init();
> - orion5x_xor_init();
> -
> - mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
> - ORION_MBUS_DEVBUS_BOOT_ATTR,
> - LSCHL_NOR_BOOT_BASE,
> - LSCHL_NOR_BOOT_SIZE);
> - platform_device_register(&lschl_nor_flash);
> -
> - platform_device_register(&lschl_leds);
> -
> - platform_device_register(&lschl_button_device);
> -
> - platform_device_register(&lschl_fan_device);
> -
> - i2c_register_board_info(0, &lschl_i2c_rtc, 1);
> -
> - /* usb power on */
> - gpio_set_value(LSCHL_GPIO_USB_POWER, 1);
> -
> - /* register power-off method */
> - pm_power_off = lschl_power_off;
> -
> - pr_info("%s: finished\n", __func__);
> -}
> -
> -MACHINE_START(LINKSTATION_LSCHL, "Buffalo Linkstation LiveV3 (LS-CHL)")
> - /* Maintainer: Ash Hughes <ashley.hughes@blueyonder.co.uk> */
> - .atag_offset = 0x100,
> - .nr_irqs = ORION5X_NR_IRQS,
> - .init_machine = lschl_init,
> - .map_io = orion5x_map_io,
> - .init_early = orion5x_init_early,
> - .init_irq = orion5x_init_irq,
> - .init_time = orion5x_timer_init,
> - .fixup = tag_fixup_mem32,
> - .restart = orion5x_restart,
> -MACHINE_END
> --
> 2.7.4
>
>
> On 04/11/16 12:44, Gregory CLEMENT wrote:
>> Hi Ash,
>>
>> On mar., oct. 25 2016, Ash Hughes <sehguh.hsa@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> This patch converts my orion5x ls-chl Linkstation device to device
>>> tree.
>> I was about to apply your patch but it does not apply on mvebu/dt or
>> even on v4.9-rc1.
>>
>> Could you rebase it?
>>
>> Thanks,
>>
>> Gregory
>>
>>> Signed-off-by: Ashley Hughes <ashley.hughes@blueyonder.co.uk>
>>> ---
>>> arch/arm/boot/dts/Makefile | 1 +
>>> arch/arm/boot/dts/orion5x-lschl.dts | 171 ++++++++++++++++++
>>> arch/arm/mach-orion5x/Kconfig | 4 +-
>>> arch/arm/mach-orion5x/Makefile | 1 -
>>> arch/arm/mach-orion5x/ls-chl-setup.c | 331 -----------------------------------
>>> 5 files changed, 174 insertions(+), 334 deletions(-)
>>> create mode 100644 arch/arm/boot/dts/orion5x-lschl.dts
>>> delete mode 100644 arch/arm/mach-orion5x/ls-chl-setup.c
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index befcd26..4853049 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -597,6 +597,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
>>> orion5x-lacie-ethernet-disk-mini-v2.dtb \
>>> orion5x-linkstation-lsgl.dtb \
>>> orion5x-linkstation-lswtgl.dtb \
>>> + orion5x-lschl.dtb \
>>> orion5x-lswsgl.dtb \
>>> orion5x-maxtor-shared-storage-2.dtb \
>>> orion5x-netgear-wnr854t.dtb \
>>> diff --git a/arch/arm/boot/dts/orion5x-lschl.dts b/arch/arm/boot/dts/orion5x-lschl.dts
>>> new file mode 100644
>>> index 0000000..9474092
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/orion5x-lschl.dts
>>> @@ -0,0 +1,171 @@
>>> +/*
>>> + * Device Tree file for Buffalo Linkstation LS-CHLv3
>>> + *
>>> + * Copyright (C) 2016 Ash Hughes <ashley.hughes@blueyonder.co.uk>
>>> + * Copyright (C) 2015, 2016
>>> + * Roger Shimizu <rogershimizu@gmail.com>
>>> + *
>>> + * This file is dual-licensed: you can use it either under the terms
>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>> + * licensing only applies to this file, and not this project as a
>>> + * whole.
>>> + *
>>> + * a) This file is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License as
>>> + * published by the Free Software Foundation; either version 2 of the
>>> + * License, or (at your option) any later version.
>>> + *
>>> + * This file is distributed in the hope that it will be useful
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * Or, alternatively
>>> + *
>>> + * b) Permission is hereby granted, free of charge, to any person
>>> + * obtaining a copy of this software and associated documentation
>>> + * files (the "Software"), to deal in the Software without
>>> + * restriction, including without limitation the rights to use
>>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>>> + * sell copies of the Software, and to permit persons to whom the
>>> + * Software is furnished to do so, subject to the following
>>> + * conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be
>>> + * included in all copies or substantial portions of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
>>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
>>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> + * OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "orion5x-linkstation.dtsi"
>>> +#include "mvebu-linkstation-gpio-simple.dtsi"
>>> +#include "mvebu-linkstation-fan.dtsi"
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +
>>> +/ {
>>> + model = "Buffalo Linkstation Live v3 (LS-CHL)";
>>> + compatible = "buffalo,lschl", "marvell,orion5x-88f5182", "marvell,orion5x";
>>> +
>>> + memory { /* 128 MB */
>>> + device_type = "memory";
>>> + reg = <0x00000000 0x8000000>;
>>> + };
>>> +
>>> + gpio_keys {
>>> + func {
>>> + label = "Function Button";
>>> + linux,code = <KEY_OPTION>;
>>> + gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
>>> + power-on-switch {
>>> + gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
>>> + power-auto-switch {
>>> + gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
>>> + };
>>> + };
>>> +
>>> + gpio_leds {
>>> + pinctrl-0 = <&pmx_led_power &pmx_led_alarm &pmx_led_info &pmx_led_func>;
>>> + blue-power-led {
>>> + gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
>>> + red-alarm-led {
>>> + gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
>>> + amber-info-led {
>>> + gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
>>> + };
>>> +
>>> + func {
>>> + label = "lschl:func:blue:top";
>>> + gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
>>> + };
>>> + };
>>> +
>>> + gpio_fan {
>>> + gpios = <&gpio0 14 GPIO_ACTIVE_LOW
>>> + &gpio0 16 GPIO_ACTIVE_LOW>;
>>> +
>>> + alarm-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +};
>>> +
>>> +&pinctrl {
>>> + pmx_led_power: pmx-leds {
>>> + marvell,pins = "mpp0";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_power_hdd: pmx-power-hdd {
>>> + marvell,pins = "mpp1";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_led_alarm: pmx-leds {
>>> + marvell,pins = "mpp2";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_led_info: pmx-leds {
>>> + marvell,pins = "mpp3";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_fan_lock: pmx-fan-lock {
>>> + marvell,pins = "mpp6";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_power_switch: pmx-power-switch {
>>> + marvell,pins = "mpp8", "mpp10", "mpp15";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_power_usb: pmx-power-usb {
>>> + marvell,pins = "mpp9";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_fan_high: pmx-fan-high {
>>> + marvell,pins = "mpp14";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_fan_low: pmx-fan-low {
>>> + marvell,pins = "mpp16";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_led_func: pmx-leds {
>>> + marvell,pins = "mpp17";
>>> + marvell,function = "gpio";
>>> + };
>>> +
>>> + pmx_sw_init: pmx-sw-init {
>>> + marvell,pins = "mpp7";
>>> + marvell,function = "gpio";
>>> + };
>>> +};
>>> +
>>> +&hdd_power {
>>> + gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
>>> +};
>>> +
>>> +&usb_power {
>>> + gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
>>> +};
>>> +
>>> diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
>>> index 89bb0fc..793efa9 100644
>>> --- a/arch/arm/mach-orion5x/Kconfig
>>> +++ b/arch/arm/mach-orion5x/Kconfig
>>> @@ -85,8 +85,8 @@ config MACH_LINKSTATION_PRO
>>> v2 devices are supported.
>>>
>>> config MACH_LINKSTATION_LSCHL
>>> - bool "Buffalo Linkstation Live v3 (LS-CHL)"
>>> - select I2C_BOARDINFO if I2C
>>> + bool "Buffalo Linkstation Live v3 (LS-CHL) (Flattened Device Tree)"
>>> + select ARCH_ORION5X_DT
>>> help
>>> Say 'Y' here if you want your kernel to support the
>>> Buffalo Linkstation Live v3 (LS-CHL) platform.
>>> diff --git a/arch/arm/mach-orion5x/Makefile b/arch/arm/mach-orion5x/Makefile
>>> index 4b2502b..ae91872 100644
>>> --- a/arch/arm/mach-orion5x/Makefile
>>> +++ b/arch/arm/mach-orion5x/Makefile
>>> @@ -18,7 +18,6 @@ obj-$(CONFIG_MACH_WNR854T) += wnr854t-setup.o
>>> obj-$(CONFIG_MACH_RD88F5181L_GE) += rd88f5181l-ge-setup.o
>>> obj-$(CONFIG_MACH_RD88F5181L_FXO) += rd88f5181l-fxo-setup.o
>>> obj-$(CONFIG_MACH_RD88F6183AP_GE) += rd88f6183ap-ge-setup.o
>>> -obj-$(CONFIG_MACH_LINKSTATION_LSCHL) += ls-chl-setup.o
>>>
>>> obj-$(CONFIG_ARCH_ORION5X_DT) += board-dt.o
>>> obj-$(CONFIG_MACH_D2NET_DT) += board-d2net.o
>>> diff --git a/arch/arm/mach-orion5x/ls-chl-setup.c b/arch/arm/mach-orion5x/ls-chl-setup.c
>>> deleted file mode 100644
>>> index dfdaa8a..0000000
>>> --- a/arch/arm/mach-orion5x/ls-chl-setup.c
>>> +++ /dev/null
>>> @@ -1,331 +0,0 @@
>>> -/*
>>> - * arch/arm/mach-orion5x/ls-chl-setup.c
>>> - *
>>> - * Maintainer: Ash Hughes <ashley.hughes@blueyonder.co.uk>
>>> - *
>>> - * This file is licensed under the terms of the GNU General Public
>>> - * License version 2. This program is licensed "as is" without any
>>> - * warranty of any kind, whether express or implied.
>>> - */
>>> -
>>> -#include <linux/kernel.h>
>>> -#include <linux/init.h>
>>> -#include <linux/platform_device.h>
>>> -#include <linux/mtd/physmap.h>
>>> -#include <linux/mv643xx_eth.h>
>>> -#include <linux/leds.h>
>>> -#include <linux/gpio_keys.h>
>>> -#include <linux/gpio-fan.h>
>>> -#include <linux/input.h>
>>> -#include <linux/i2c.h>
>>> -#include <linux/ata_platform.h>
>>> -#include <linux/gpio.h>
>>> -#include <asm/mach-types.h>
>>> -#include <asm/mach/arch.h>
>>> -#include "common.h"
>>> -#include "mpp.h"
>>> -#include "orion5x.h"
>>> -
>>> -/*****************************************************************************
>>> - * Linkstation LS-CHL Info
>>> - ****************************************************************************/
>>> -
>>> -/*
>>> - * 256K NOR flash Device bus boot chip select
>>> - */
>>> -
>>> -#define LSCHL_NOR_BOOT_BASE 0xf4000000
>>> -#define LSCHL_NOR_BOOT_SIZE SZ_256K
>>> -
>>> -/*****************************************************************************
>>> - * 256KB NOR Flash on BOOT Device
>>> - ****************************************************************************/
>>> -
>>> -static struct physmap_flash_data lschl_nor_flash_data = {
>>> - .width = 1,
>>> -};
>>> -
>>> -static struct resource lschl_nor_flash_resource = {
>>> - .flags = IORESOURCE_MEM,
>>> - .start = LSCHL_NOR_BOOT_BASE,
>>> - .end = LSCHL_NOR_BOOT_BASE + LSCHL_NOR_BOOT_SIZE - 1,
>>> -};
>>> -
>>> -static struct platform_device lschl_nor_flash = {
>>> - .name = "physmap-flash",
>>> - .id = 0,
>>> - .dev = {
>>> - .platform_data = &lschl_nor_flash_data,
>>> - },
>>> - .num_resources = 1,
>>> - .resource = &lschl_nor_flash_resource,
>>> -};
>>> -
>>> -/*****************************************************************************
>>> - * Ethernet
>>> - ****************************************************************************/
>>> -
>>> -static struct mv643xx_eth_platform_data lschl_eth_data = {
>>> - .phy_addr = MV643XX_ETH_PHY_ADDR(8),
>>> -};
>>> -
>>> -/*****************************************************************************
>>> - * RTC 5C372a on I2C bus
>>> - ****************************************************************************/
>>> -
>>> -static struct i2c_board_info __initdata lschl_i2c_rtc = {
>>> - I2C_BOARD_INFO("rs5c372a", 0x32),
>>> -};
>>> -
>>> -/*****************************************************************************
>>> - * LEDs attached to GPIO
>>> - ****************************************************************************/
>>> -
>>> -#define LSCHL_GPIO_LED_ALARM 2
>>> -#define LSCHL_GPIO_LED_INFO 3
>>> -#define LSCHL_GPIO_LED_FUNC 17
>>> -#define LSCHL_GPIO_LED_PWR 0
>>> -
>>> -static struct gpio_led lschl_led_pins[] = {
>>> - {
>>> - .name = "alarm:red",
>>> - .gpio = LSCHL_GPIO_LED_ALARM,
>>> - .active_low = 1,
>>> - }, {
>>> - .name = "info:amber",
>>> - .gpio = LSCHL_GPIO_LED_INFO,
>>> - .active_low = 1,
>>> - }, {
>>> - .name = "func:blue:top",
>>> - .gpio = LSCHL_GPIO_LED_FUNC,
>>> - .active_low = 1,
>>> - }, {
>>> - .name = "power:blue:bottom",
>>> - .gpio = LSCHL_GPIO_LED_PWR,
>>> - },
>>> -};
>>> -
>>> -static struct gpio_led_platform_data lschl_led_data = {
>>> - .leds = lschl_led_pins,
>>> - .num_leds = ARRAY_SIZE(lschl_led_pins),
>>> -};
>>> -
>>> -static struct platform_device lschl_leds = {
>>> - .name = "leds-gpio",
>>> - .id = -1,
>>> - .dev = {
>>> - .platform_data = &lschl_led_data,
>>> - },
>>> -};
>>> -
>>> -/*****************************************************************************
>>> - * SATA
>>> - ****************************************************************************/
>>> -static struct mv_sata_platform_data lschl_sata_data = {
>>> - .n_ports = 2,
>>> -};
>>> -
>>> -/*****************************************************************************
>>> - * LS-CHL specific power off method: reboot
>>> - ****************************************************************************/
>>> -/*
>>> - * On the LS-CHL, the shutdown process is following:
>>> - * - Userland monitors key events until the power switch goes to off position
>>> - * - The board reboots
>>> - * - U-boot starts and goes into an idle mode waiting for the user
>>> - * to move the switch to ON position
>>> - *
>>> - */
>>> -
>>> -static void lschl_power_off(void)
>>> -{
>>> - orion5x_restart(REBOOT_HARD, NULL);
>>> -}
>>> -
>>> -/*****************************************************************************
>>> - * General Setup
>>> - ****************************************************************************/
>>> -#define LSCHL_GPIO_USB_POWER 9
>>> -#define LSCHL_GPIO_AUTO_POWER 17
>>> -#define LSCHL_GPIO_POWER 18
>>> -
>>> -/****************************************************************************
>>> - * GPIO Attached Keys
>>> - ****************************************************************************/
>>> -#define LSCHL_GPIO_KEY_FUNC 15
>>> -#define LSCHL_GPIO_KEY_POWER 8
>>> -#define LSCHL_GPIO_KEY_AUTOPOWER 10
>>> -#define LSCHL_SW_POWER 0x00
>>> -#define LSCHL_SW_AUTOPOWER 0x01
>>> -#define LSCHL_SW_FUNC 0x02
>>> -
>>> -static struct gpio_keys_button lschl_buttons[] = {
>>> - {
>>> - .type = EV_SW,
>>> - .code = LSCHL_SW_POWER,
>>> - .gpio = LSCHL_GPIO_KEY_POWER,
>>> - .desc = "Power-on Switch",
>>> - .active_low = 1,
>>> - }, {
>>> - .type = EV_SW,
>>> - .code = LSCHL_SW_AUTOPOWER,
>>> - .gpio = LSCHL_GPIO_KEY_AUTOPOWER,
>>> - .desc = "Power-auto Switch",
>>> - .active_low = 1,
>>> - }, {
>>> - .type = EV_SW,
>>> - .code = LSCHL_SW_FUNC,
>>> - .gpio = LSCHL_GPIO_KEY_FUNC,
>>> - .desc = "Function Switch",
>>> - .active_low = 1,
>>> - },
>>> -};
>>> -
>>> -static struct gpio_keys_platform_data lschl_button_data = {
>>> - .buttons = lschl_buttons,
>>> - .nbuttons = ARRAY_SIZE(lschl_buttons),
>>> -};
>>> -
>>> -static struct platform_device lschl_button_device = {
>>> - .name = "gpio-keys",
>>> - .id = -1,
>>> - .num_resources = 0,
>>> - .dev = {
>>> - .platform_data = &lschl_button_data,
>>> - },
>>> -};
>>> -
>>> -#define LSCHL_GPIO_HDD_POWER 1
>>> -
>>> -/****************************************************************************
>>> - * GPIO Fan
>>> - ****************************************************************************/
>>> -
>>> -#define LSCHL_GPIO_FAN_LOW 16
>>> -#define LSCHL_GPIO_FAN_HIGH 14
>>> -#define LSCHL_GPIO_FAN_LOCK 6
>>> -
>>> -static struct gpio_fan_alarm lschl_alarm = {
>>> - .gpio = LSCHL_GPIO_FAN_LOCK,
>>> -};
>>> -
>>> -static struct gpio_fan_speed lschl_speeds[] = {
>>> - {
>>> - .rpm = 0,
>>> - .ctrl_val = 3,
>>> - }, {
>>> - .rpm = 1500,
>>> - .ctrl_val = 2,
>>> - }, {
>>> - .rpm = 3250,
>>> - .ctrl_val = 1,
>>> - }, {
>>> - .rpm = 5000,
>>> - .ctrl_val = 0,
>>> - },
>>> -};
>>> -
>>> -static int lschl_gpio_list[] = {
>>> - LSCHL_GPIO_FAN_HIGH, LSCHL_GPIO_FAN_LOW,
>>> -};
>>> -
>>> -static struct gpio_fan_platform_data lschl_fan_data = {
>>> - .num_ctrl = ARRAY_SIZE(lschl_gpio_list),
>>> - .ctrl = lschl_gpio_list,
>>> - .alarm = &lschl_alarm,
>>> - .num_speed = ARRAY_SIZE(lschl_speeds),
>>> - .speed = lschl_speeds,
>>> -};
>>> -
>>> -static struct platform_device lschl_fan_device = {
>>> - .name = "gpio-fan",
>>> - .id = -1,
>>> - .num_resources = 0,
>>> - .dev = {
>>> - .platform_data = &lschl_fan_data,
>>> - },
>>> -};
>>> -
>>> -/****************************************************************************
>>> - * GPIO Data
>>> - ****************************************************************************/
>>> -
>>> -static unsigned int lschl_mpp_modes[] __initdata = {
>>> - MPP0_GPIO, /* LED POWER */
>>> - MPP1_GPIO, /* HDD POWER */
>>> - MPP2_GPIO, /* LED ALARM */
>>> - MPP3_GPIO, /* LED INFO */
>>> - MPP4_UNUSED,
>>> - MPP5_UNUSED,
>>> - MPP6_GPIO, /* FAN LOCK */
>>> - MPP7_GPIO, /* SW INIT */
>>> - MPP8_GPIO, /* SW POWER */
>>> - MPP9_GPIO, /* USB POWER */
>>> - MPP10_GPIO, /* SW AUTO POWER */
>>> - MPP11_UNUSED,
>>> - MPP12_UNUSED,
>>> - MPP13_UNUSED,
>>> - MPP14_GPIO, /* FAN HIGH */
>>> - MPP15_GPIO, /* SW FUNC */
>>> - MPP16_GPIO, /* FAN LOW */
>>> - MPP17_GPIO, /* LED FUNC */
>>> - MPP18_UNUSED,
>>> - MPP19_UNUSED,
>>> - 0,
>>> -};
>>> -
>>> -static void __init lschl_init(void)
>>> -{
>>> - /*
>>> - * Setup basic Orion functions. Needs to be called early.
>>> - */
>>> - orion5x_init();
>>> -
>>> - orion5x_mpp_conf(lschl_mpp_modes);
>>> -
>>> - /*
>>> - * Configure peripherals.
>>> - */
>>> - orion5x_ehci0_init();
>>> - orion5x_ehci1_init();
>>> - orion5x_eth_init(&lschl_eth_data);
>>> - orion5x_i2c_init();
>>> - orion5x_sata_init(&lschl_sata_data);
>>> - orion5x_uart0_init();
>>> - orion5x_xor_init();
>>> -
>>> - mvebu_mbus_add_window_by_id(ORION_MBUS_DEVBUS_BOOT_TARGET,
>>> - ORION_MBUS_DEVBUS_BOOT_ATTR,
>>> - LSCHL_NOR_BOOT_BASE,
>>> - LSCHL_NOR_BOOT_SIZE);
>>> - platform_device_register(&lschl_nor_flash);
>>> -
>>> - platform_device_register(&lschl_leds);
>>> -
>>> - platform_device_register(&lschl_button_device);
>>> -
>>> - platform_device_register(&lschl_fan_device);
>>> -
>>> - i2c_register_board_info(0, &lschl_i2c_rtc, 1);
>>> -
>>> - /* usb power on */
>>> - gpio_set_value(LSCHL_GPIO_USB_POWER, 1);
>>> -
>>> - /* register power-off method */
>>> - pm_power_off = lschl_power_off;
>>> -
>>> - pr_info("%s: finished\n", __func__);
>>> -}
>>> -
>>> -MACHINE_START(LINKSTATION_LSCHL, "Buffalo Linkstation LiveV3 (LS-CHL)")
>>> - /* Maintainer: Ash Hughes <ashley.hughes@blueyonder.co.uk> */
>>> - .atag_offset = 0x100,
>>> - .nr_irqs = ORION5X_NR_IRQS,
>>> - .init_machine = lschl_init,
>>> - .map_io = orion5x_map_io,
>>> - .init_early = orion5x_init_early,
>>> - .init_irq = orion5x_init_irq,
>>> - .init_time = orion5x_timer_init,
>>> - .fixup = tag_fixup_mem32,
>>> - .restart = orion5x_restart,
>>> -MACHINE_END
>>> -- 2.7.4
>>>
>>>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] staging: vc04_services: add vchiq_pagelist_info structure
From: Eric Anholt @ 2016-11-07 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107140603.14125-1-mzoran@crowfest.net>
Michael Zoran <mzoran@crowfest.net> writes:
> The current dma_map_sg based implementation for bulk messages
> computes many offsets into a single allocation multiple times in
> both the create and free code paths. This is inefficient,
> error prone and in fact still has a few lingering issues
> with arm64.
>
> This change replaces a small portion of that inplementation with
> new code that uses a new struct vchiq_pagelist_info to store the
> needed information rather then complex offset calculations.
>
> This improved implementation should be more efficient and easier
> to understand and maintain.
>
> Tests Run(Both Pass):
> vchiq_test -p 1
> vchiq_test -f 10
Looks good, and it's a nice cleanup. Thanks!
Reviewed-by: Eric Anholt <eric@anholt.net>
I had one style note, which was that you're using an int and 0/1 for a
boolean value, but we like to use proper bools and true/false instead.
However, you're modifying code that was already using an int for related
booleans, so that can be a separate cleanup.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/cd4b1063/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] arm64/setup: Use ID_AA64ISAR0_EL1_.* macros
From: Suzuki K Poulose @ 2016-11-07 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1441303972-9480-1-git-send-email-kuleshovmail@gmail.com>
On 03/09/15 19:12, Alexander Kuleshov wrote:
> The 26d75e67c commit (arm64/cpufeature.h: Add macros for a cpu features
> testing) provides set of macros for the testing processor's crypto features.
> Let's use these macros instead of direct calculation.
>
> Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
> ---
> arch/arm64/kernel/setup.c | 29 +++++++++--------------------
> 1 file changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 926ae8d..a3faf4f 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
This patch doesn't apply on the current mainline tree. Where does this patch apply ?
The elf_hwcap calculation has been moved to a separate function setup_elf_hwcaps()
in arch/arm64/kernel/cpufeature.c, which makes uses of a table of arm64_cpu_capabilities.
Suzuki
> @@ -250,33 +250,22 @@ static void __init setup_processor(void)
>
> /*
> * ID_AA64ISAR0_EL1 contains 4-bit wide signed feature blocks.
> - * The blocks we test below represent incremental functionality
> - * for non-negative values. Negative values are reserved.
> */
> features = read_cpuid(ID_AA64ISAR0_EL1);
> - block = (features >> 4) & 0xf;
> - if (!(block & 0x8)) {
> - switch (block) {
> - default:
> - case 2:
> - elf_hwcap |= HWCAP_PMULL;
> - case 1:
> - elf_hwcap |= HWCAP_AES;
> - case 0:
> - break;
> - }
> - }
>
> - block = (features >> 8) & 0xf;
> - if (block && !(block & 0x8))
> + if (ID_AA64ISAR0_EL1_AES(features))
> + elf_hwcap |= HWCAP_AES;
> +
> + if (ID_AA64ISAR0_EL1_PMULL(features))
> + elf_hwcap |= HWCAP_PMULL;
> +
> + if (ID_AA64ISAR0_EL1_SHA1(features))
> elf_hwcap |= HWCAP_SHA1;
>
> - block = (features >> 12) & 0xf;
> - if (block && !(block & 0x8))
> + if (ID_AA64ISAR0_EL1_SHA2(features))
> elf_hwcap |= HWCAP_SHA2;
>
> - block = (features >> 16) & 0xf;
> - if (block && !(block & 0x8))
> + if (ID_AA64ISAR0_EL1_CRC32(features))
> elf_hwcap |= HWCAP_CRC32;
^ permalink raw reply
* [PATCH 3/3] arm64/fpsimd: Use ID_AA64PFR0_EL1_.* macros
From: Suzuki K Poulose @ 2016-11-07 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1441303979-9535-1-git-send-email-kuleshovmail@gmail.com>
On 03/09/15 19:12, Alexander Kuleshov wrote:
> The 26d75e67c commit (arm64/cpufeature.h: Add macros for a cpu features
> testing) provides set of macros for the testing processor's FP and advanced
> SIMD features.
>
> Let's use these macros instead of direct calculation.
>
> Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
> ---
> arch/arm64/kernel/fpsimd.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 44d6f75..12943a5 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -27,6 +27,7 @@
>
> #include <asm/fpsimd.h>
> #include <asm/cputype.h>
> +#include <asm/cpufeature.h>
>
> #define FPEXC_IOF (1 << 0)
> #define FPEXC_DZF (1 << 1)
> @@ -333,13 +334,13 @@ static int __init fpsimd_init(void)
> {
> u64 pfr = read_cpuid(ID_AA64PFR0_EL1);
>
> - if (pfr & (0xf << 16)) {
> + if (ID_AA64PFR0_EL1_FP(pfr)) {
> pr_notice("Floating-point is not implemented\n");
> return 0;
> }
> elf_hwcap |= HWCAP_FP;
>
> - if (pfr & (0xf << 20))
> + if (ID_AA64PFR0_EL1_ADV_SIMD(pfr))
> pr_notice("Advanced SIMD is not implemented\n");
> else
> elf_hwcap |= HWCAP_ASIMD;
>
Similar to the previous one, this won't apply anymore.
Suzuki
^ permalink raw reply
* [PATCHv4 0/4] WX checking for arm64
From: Catalin Marinas @ 2016-11-07 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07589590-7b7d-4ba1-67af-b39c40b16939@redhat.com>
On Mon, Nov 07, 2016 at 08:26:34AM -0800, Laura Abbott wrote:
> On 11/07/2016 07:38 AM, Mark Rutland wrote:
> >From 06fef1ad1138d0808eec770e64458a350941bd2d Mon Sep 17 00:00:00 2001
> >From: Mark Rutland <mark.rutland@arm.com>
> >Date: Mon, 7 Nov 2016 15:24:40 +0000
> >Subject: [PATCH] Fix KASAN splats with DEBUG_WX
[...]
> Acked-by: Laura Abbott <labbott@redhat.com>
Thanks. I'll queue the patch on top of the others.
--
Catalin
^ permalink raw reply
* [PATCH v2] staging: vc04_services: setup DMA and coherent mask
From: Eric Anholt @ 2016-11-07 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031210203.2089-1-mzoran@crowfest.net>
Michael Zoran <mzoran@crowfest.net> writes:
> VCHI messages between the CPU and firmware use 32-bit
> bus addresses. Explicitly set the DMA mask and coherent
> on all platforms.
Reviewed-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/14619b5d/attachment.sig>
^ permalink raw reply
* [PATCH 0/3] arm64: dts: hisi: hip06 SAS device tree fixes
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: linux-arm-kernel
This patchset resolves some hip06 SAS device tree issues.
John Garry (3):
arm64: dts: hisi: fix hip06 sas am-max-trans quirk
arm64: dts: hisi: disable sas0 and sas2 for d03
arm64: dts: hisi: add refclk node to hip06 dts files for SAS
arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8 --------
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 11 ++++++++++-
2 files changed, 10 insertions(+), 9 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] arm64: dts: hisi: fix hip06 sas am-max-trans quirk
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry@huawei.com>
The string for the am max transmissions quirk property
is not correct -> fix it.
Signed-off-by: John Garry <john.garry@huawei.com>
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index b548763..5330abb 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -590,7 +590,7 @@
reg = <0 0xa2000000 0 0x10000>;
sas-addr = [50 01 88 20 16 00 00 00];
hisilicon,sas-syscon = <&pcie_subctl>;
- am-max-trans;
+ hip06-sas-v2-quirk-amt;
ctrl-reset-reg = <0xa18>;
ctrl-reset-sts-reg = <0x5a0c>;
ctrl-clock-ena-reg = <0x318>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: hisi: disable sas0 and sas2 for d03
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry@huawei.com>
The SAS nodes sas0 and sas2 are not available on d03, so
disable them.
Signed-off-by: John Garry <john.garry@huawei.com>
Acked-by: Xu Wei <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
index f54b283..7c4114a 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
@@ -41,18 +41,10 @@
status = "ok";
};
-&sas0 {
- status = "ok";
-};
-
&sas1 {
status = "ok";
};
-&sas2 {
- status = "ok";
-};
-
&usb_ohci {
status = "ok";
};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: hisi: add refclk node to hip06 dts files for SAS
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry@huawei.com>
We will only maintain 1 dts for D03 and there are 50MHz
and 66MHz versions of D03: so we expect UEFI to update
refclk rate in the fdt at boot time.
Signed-off-by: John Garry <john.garry@huawei.com>
Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index 5330abb..7b40dce 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -318,6 +318,12 @@
#size-cells = <2>;
ranges;
+ refclk: refclk {
+ compatible = "fixed-clock";
+ clock-frequency = <50000000>;
+ #clock-cells = <0>;
+ };
+
usb_ohci: ohci at a7030000 {
compatible = "generic-ohci";
reg = <0x0 0xa7030000 0x0 0x10000>;
@@ -552,6 +558,7 @@
ctrl-reset-reg = <0xa60>;
ctrl-reset-sts-reg = <0x5a30>;
ctrl-clock-ena-reg = <0x338>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <8>;
dma-coherent;
@@ -594,6 +601,7 @@
ctrl-reset-reg = <0xa18>;
ctrl-reset-sts-reg = <0x5a0c>;
ctrl-clock-ena-reg = <0x318>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <8>;
dma-coherent;
@@ -635,6 +643,7 @@
ctrl-reset-reg = <0xae0>;
ctrl-reset-sts-reg = <0x5a70>;
ctrl-clock-ena-reg = <0x3a8>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <9>;
dma-coherent;
--
1.9.1
^ permalink raw reply related
* [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
From: Matthias Brugger @ 2016-11-07 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGS+omDmFdqzuFqcCe9gFGemZc88Yt0_3_o2KwOgW=GN_kCakQ@mail.gmail.com>
On 05/11/16 00:21, Daniel Kurtz wrote:
> On Tue, Oct 25, 2016 at 6:23 AM, Matthias Brugger
> <matthias.bgg@gmail.com> wrote:
>>
>> On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote:
>> [...]
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> [...]
>>>>
>>>> +
>>>> +/* Firmware */
>>>> +#define PS_FW_NAME "ps864x_fw.bin"
>>>> +
>>>
>>> From where I can download this firmware image?
>>
>> I suppose this FW bits have to be added to linux-firmware repository first, before this patch can be accepted.
>
> All PS8640 devices should already ship with working firmware.
> The firmware update procedure is only used in the unlikely event where
> one wants to update the bridge to a different firmware provided by
> Parade.
>
> Why must the lack of firmware really block landing this driver?
>
> If this is really so, can we just land the functional part of the
> driver first, and add the firmware update in a follow-up patch.
>
After checking other users of request_firmware and check them against
linux-firmware I think we don't need the FW in linux-firmware to get the
driver merged. Especially as there already is a working FW stored on the
device.
Regards,
Matthias
^ permalink raw reply
* [3/4] ARM: EXYNOS: Remove static mapping of SCU SFR
From: Pankaj Dubey @ 2016-11-07 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582007F1.5050803@samsung.com>
Hi Alim,
On 7 November 2016 at 10:19, Alim Akhtar <alim.akhtar@samsung.com> wrote:
>
> Hi Pankaj,
>
>
> On 11/07/2016 08:05 AM, pankaj.dubey wrote:
>>
>> Hi Alim,
>>
>> On Friday 04 November 2016 06:56 PM, Alim Akhtar wrote:
>>>
>>> Hi Pankaj,
>>>
>>> On 11/04/2016 09:09 AM, Pankaj Dubey wrote:
>>>>
>>>> Lets remove static mapping of SCU SFR mainly used in CORTEX-A9 SoC
>>>> based boards.
>>>> Instead use mapping from device tree node of SCU.
>>>>
>>>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>>>> ---
>>>> arch/arm/mach-exynos/exynos.c | 22
>>>> ----------------------
>>>> arch/arm/mach-exynos/include/mach/map.h | 2 --
>>>> arch/arm/mach-exynos/platsmp.c | 18 +++++++++++-------
>>>> arch/arm/mach-exynos/pm.c | 14 +++++++++++---
>>>> arch/arm/mach-exynos/suspend.c | 15 +++++++++++----
>>>> arch/arm/plat-samsung/include/plat/map-s5p.h | 4 ----
>>>> 6 files changed, 33 insertions(+), 42 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-exynos/exynos.c
>>>> b/arch/arm/mach-exynos/exynos.c
>>>> index 757fc11..fa08ef9 100644
>>>> --- a/arch/arm/mach-exynos/exynos.c
>>>> +++ b/arch/arm/mach-exynos/exynos.c
>>>> @@ -28,15 +28,6 @@
>>>>
>>>> #include "common.h"
>>>>
>>>> -static struct map_desc exynos4_iodesc[] __initdata = {
>>>> - {
>>>> - .virtual = (unsigned long)S5P_VA_COREPERI_BASE,
>>>> - .pfn = __phys_to_pfn(EXYNOS4_PA_COREPERI),
>>>> - .length = SZ_8K,
>>>> - .type = MT_DEVICE,
>>>> - },
>>>> -};
>>>> -
>>>> static struct platform_device exynos_cpuidle = {
>>>> .name = "exynos_cpuidle",
>>>> #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
>>>> @@ -99,17 +90,6 @@ static int __init exynos_fdt_map_chipid(unsigned
>>>> long node, const char *uname,
>>>> return 1;
>>>> }
>>>>
>>>> -/*
>>>> - * exynos_map_io
>>>> - *
>>>> - * register the standard cpu IO areas
>>>> - */
>>>> -static void __init exynos_map_io(void)
>>>> -{
>>>> - if (soc_is_exynos4())
>>>> - iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
>>>> -}
>>>> -
>>>> static void __init exynos_init_io(void)
>>>> {
>>>> debug_ll_io_init();
>>>> @@ -118,8 +98,6 @@ static void __init exynos_init_io(void)
>>>>
>>>> /* detect cpu id and rev. */
>>>> s5p_init_cpu(S5P_VA_CHIPID);
>>>> -
>>>> - exynos_map_io();
>>>> }
>>>>
>>>> /*
>>>> diff --git a/arch/arm/mach-exynos/include/mach/map.h
>>>> b/arch/arm/mach-exynos/include/mach/map.h
>>>> index 5fb0040..0eef407 100644
>>>> --- a/arch/arm/mach-exynos/include/mach/map.h
>>>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>>>> @@ -18,6 +18,4 @@
>>>>
>>>> #define EXYNOS_PA_CHIPID 0x10000000
>>>>
>>>> -#define EXYNOS4_PA_COREPERI 0x10500000
>>>> -
>>>> #endif /* __ASM_ARCH_MAP_H */
>>>> diff --git a/arch/arm/mach-exynos/platsmp.c
>>>> b/arch/arm/mach-exynos/platsmp.c
>>>> index a5d6841..553d0d9 100644
>>>> --- a/arch/arm/mach-exynos/platsmp.c
>>>> +++ b/arch/arm/mach-exynos/platsmp.c
>>>> @@ -224,11 +224,6 @@ static void write_pen_release(int val)
>>>> sync_cache_w(&pen_release);
>>>> }
>>>>
>>>> -static void __iomem *scu_base_addr(void)
>>>> -{
>>>> - return (void __iomem *)(S5P_VA_SCU);
>>>> -}
>>>> -
>>>> static DEFINE_SPINLOCK(boot_lock);
>>>>
>>>> static void exynos_secondary_init(unsigned int cpu)
>>>> @@ -387,14 +382,23 @@ fail:
>>>>
>>>> static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
>>>> {
>>>> + struct device_node *np;
>>>> + void __iomem *scu_base;
>>>> int i;
>>>>
>>>> exynos_sysram_init();
>>>>
>>>> exynos_set_delayed_reset_assertion(true);
>>>>
>>>> - if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
>>>> - scu_enable(scu_base_addr());
>>>> + if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
>>>> + np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
>>>
>>>
>>> what if of_find_compatible_node() fails? May be add a error check for
>>> the same?
>>
>>
>> Thanks for review.
>>
>> You are right of_find_compatible_node() is bound to fail, but only in
>> case supplied compatible is missing in DT. In our case this piece of
>> code will execute only for Cortex-A9 based SoC (which in case of Exynos
>> SoC is applicable only for Exynos4 series) and we will for sure
>> providing "arm,cortex-a9-scu" in DT, so there is no chance of failure.
>> So I feel extra check on "np" for NULL will add no benefit here.
>>
> Well I am not entirely convenience here, I still feel it better to have those check, lets not assume anything about future, but when I see of_find_compatible_node() uses elsewhere in kernel, both kind of uses are there (with/without error check).
> So, I leave it to you and maintainer to take a call on this, otherwise this patch looks good.
>
> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
>
Well, I further checked details of of_find_compatible_node() and
of_iomap and below is function call chain
of_find_compatible_node //Returns vaild pointer for match, and NULL
for no match
--> __of_device_is_compatible () //Returns 0 for no match, and a
positive integer on match
So in our case lets say for any reason "arm,cortex-a9-scu" compatible
is not present, "np" will be set as NULL.
Next we have following line without check on "np" for NULL,
scu_base = of_iomap(np, 0);
If we see function call sequence of of_iomap we have,
of_iomap(..) //Returns NULL is of_address_to_resource returns non-zero
--> of_address_to_resource(...) // Returns -EINVAL if "addrp" is NULL
--> of_get_address(...) //Returns NULL if "parent" is NULL
--> of_get_parent(...) //Returns np with refcount
incremented if np is NOT NULL else returns NULL
So in our case we will get scu_base as NULL if we pass "np" as NULL,
and on very next line we have check on scu_base, which will prevent us
from de-referencing a NULL pointer. So there won't be any CRASH or
abnormal behavior, due to not checking "np" for NULL.
I think this is the reason in many places in kernel there is no check
for NULL for of_find_compatible_node, surely some places there are
checks, but as per current code flow if someone is calling of_iomap
with np as NULL there won't be any crash and of_iomap will gracefully
returns NULL in that case. Also of_node_put and of_node_get has check
for NULL received device_node and handles it gracefully.
But one thing I missed is that in case scu_base is NULL we are not
suppose to move ahead in function exynos_smp_prepare_cpus(..), This
part I will update and post next version with appropriate change.
Thanks,
Pankaj Dubey
>>
>>
>> Thanks,
>> Pankaj Dubey
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] arm/vdso: introduce vdso_mremap hook
From: Christopher Covington @ 2016-11-07 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161101172214.2938-1-dsafonov@virtuozzo.com>
Hi Dmitry,
On 11/01/2016 01:22 PM, Dmitry Safonov wrote:
> Add vdso_mremap hook which will fix context.vdso pointer after mremap()
> on vDSO vma. This is needed for correct landing after syscall execution.
> Primary goal of this is for CRIU on arm - we need to restore vDSO image
> at the exactly same place where the vma was in dumped application. With
> the help of this hook we'll move vDSO at the new position.
> The CRIU code handles situations like when vDSO of dumped application
> was different from vDSO on restoring system. This usally happens when
> some new symbols are being added to vDSO. In these situations CRIU
> inserts jump trampolines from old vDSO blob to new vDSO on restore.
> By that reason even if on restore vDSO blob lies on the same address as
> blob in dumped application - we still need to move it if it differs.
>
> There was previously attempt to add this functionality for arm64 by
> arch_mremap hook [1], while this patch introduces this with minimal
> effort - the same way I've added it to x86:
> commit b059a453b1cf ("x86/vdso: Add mremap hook to vm_special_mapping")
>
> At this moment, vdso restoring code is disabled for arm/arm64 arch
> in CRIU [2], so C/R is only working for !CONFIG_VDSO kernels. This patch
> is aimed to fix that.
> The same hook may be introduced for arm64 kernel, but at this moment
> arm64 vdso code is actively reworked by Kevin, so we can do it on top.
> Separately, I've refactored arch_remap hook out from ppc64 [3].
>
> [1]: https://marc.info/?i=1448455781-26660-1-git-send-email-cov at codeaurora.org
> [2]: https://github.com/xemul/criu/blob/master/Makefile#L39
> [3]: https://marc.info/?i=20161027170948.8279-1-dsafonov at virtuozzo.com
>
> Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> Cc: Christopher Covington <cov@codeaurora.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-mm at kvack.org
> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
> Cc: Pavel Emelyanov <xemul@virtuozzo.com>
> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
> ---
> arch/arm/kernel/vdso.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
> index 53cf86cf2d1a..d1001f87c2f6 100644
> --- a/arch/arm/kernel/vdso.c
> +++ b/arch/arm/kernel/vdso.c
> @@ -54,8 +54,11 @@ static const struct vm_special_mapping vdso_data_mapping = {
> .pages = &vdso_data_page,
> };
>
> +static int vdso_mremap(const struct vm_special_mapping *sm,
> + struct vm_area_struct *new_vma);
> static struct vm_special_mapping vdso_text_mapping __ro_after_init = {
> .name = "[vdso]",
> + .mremap = vdso_mremap,
> };
>
> struct elfinfo {
> @@ -254,6 +257,24 @@ void arm_install_vdso(struct mm_struct *mm, unsigned long addr)
> mm->context.vdso = addr;
> }
>
> +static int vdso_mremap(const struct vm_special_mapping *sm,
> + struct vm_area_struct *new_vma)
> +{
> + unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
> + unsigned long vdso_size = (vdso_total_pages - 1) << PAGE_SHIFT;
> +
> + /* Disallow partial vDSO blob remap */
> + if (vdso_size != new_size)
> + return -EINVAL;
> +
> + if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
> + return -EFAULT;
> +
> + current->mm->context.vdso = new_vma->vm_start;
> +
> + return 0;
> +}
> +
> static void vdso_write_begin(struct vdso_data *vdata)
> {
> ++vdso_data->seq_count;
>
What do you think about putting this code somewhere generic (not under
arch/*), so that powerpc and arm64 can reuse it once the cosmetic changes
to make them compatible are made? My thought was that it could be defined
underneath CONFIG_GENERIC_VDSO, which architectures could select as they
became compatible.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: Add Broadcom Northstar2 device tree entries for PDC driver.
From: Florian Fainelli @ 2016-11-07 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1467316764-19686-4-git-send-email-rob.rice@broadcom.com>
On 06/30/2016 12:59 PM, Rob Rice wrote:
> From: Rob Rice <rrice@broadcom.com>
>
> Add Broadcom Northstar2 SoC device tree entries for PDC driver.
>
> Signed-off-by: Rob Rice <rob.rice@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Applied, thanks Rob!
--
Florian
^ permalink raw reply
* [PATCH 1/4] ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
From: Pankaj Dubey @ 2016-11-07 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPfuN7sdj+C=ccb18TspS_QmvJF-OS1keBsXt8a4w51TUg@mail.gmail.com>
Hi Krzysztof,
On 7 November 2016 at 12:29, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Nov 7, 2016 at 5:37 AM, pankaj.dubey <pankaj.dubey@samsung.com> wrote:
>> Hi Krzysztof,
>>
>> On Saturday 05 November 2016 09:11 PM, Krzysztof Kozlowski wrote:
>>> On Fri, Nov 04, 2016 at 09:09:21AM +0530, Pankaj Dubey wrote:
>>>> We can safely remove exynos_smp_init_cpus() hook from mach-exynos/platsmp.c,
>>>> as all SMP platforms in mach-exynos can rely on DT for CPU core description
>>>> instead of determining number of cores from the SCU.
>>>>
>>>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>>>> ---
>>>> arch/arm/mach-exynos/platsmp.c | 31 -------------------------------
>>>> 1 file changed, 31 deletions(-)
>>>>
>>>
>>>
>>> Thanks, applied. Somehow your patchset did not reach linux-samsung-soc's
>>> Parchwork. I don't have a clue why... It is on linux-arm-kernel's
>>> Patchwork.
>>>
>>
>> Thanks for looking into this series.
>>
>> I am also not sure why its not reflecting for you on linux-samsung-soc's
>> Patchwork, but I can see this series in linux-samsung-soc Patchwork at
>> below links:
>
> Hmmm... it is weird. Why I didn't see them before? It seems that I
> even updated their status. Confusing...
>
>
>> Will you please review other two patches (3/4 and 4/4) in this series?
>
> 4/4 is okay but it depends on 3/4 which already has a valid comment -
> what will happen when DT node is not present (which first of all will
> happen because DTS is applied on separate branch... and anyway the
> code must be prepared for different DTSes). Initially I thought there
> will be NULL pointer exception on of_iomap() but after looking at the
> code it might work, I mean fail in a reasonable way.
>
Yes, you are right, even we do not add check for NULL on "np" it won't
cause NULL pointer exception on of_iomap(), and it handles it
gracefully, I have given explanation about this on patch [4/4] as
reply to Alim.
So we can safely avoid check for NULL on "np" without assuming
anything, but at the same time I noticed that in case of_iomap returns
NULL, we can't move ahead and configure secondary startup address in
exynos_smp_prepare_cpus, so I will resubmit [3/4] and [4/4] with
appropriate changes to take care of this case. If you see any other
concern please let me know.
Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/6] mfd: max8997: Initialize max8997 register map
From: Pankaj Dubey @ 2016-11-07 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b150578-b766-3470-475c-fe494bcc8c54@osg.samsung.com>
Hi Javier,
On 7 November 2016 at 19:52, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> Hello Pankaj,
>
> On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
>> This patch add regmap initialization to use register map
>> in max8997-clk device driver
>>
>> CC: Lee Jones <lee.jones@linaro.org>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>
> Patch looks good to me. Now that the driver uses regmap, I think you should
> be able to get rid of drivers/mfd/max8997-irq.c and use the regmap IRQ chip
> like is done in most Maxim PMIC MFD drivers.
>
> That can be done as a follow-up of this series though.
>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
Thanks for review.
You are right, that we can get rid of max8997-irq.c by using regmap
IRQ chip, but I would like to take that as a separate follow-up
series.
Thanks,
Pankaj Dubey
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] arm/vdso: introduce vdso_mremap hook
From: Dmitry Safonov @ 2016-11-07 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0b41c28b-20ef-332f-d8d6-e381e05b8252@codeaurora.org>
On 11/07/2016 08:00 PM, Christopher Covington wrote:
> Hi Dmitry,
>
> On 11/01/2016 01:22 PM, Dmitry Safonov wrote:
>> Add vdso_mremap hook which will fix context.vdso pointer after mremap()
>> on vDSO vma. This is needed for correct landing after syscall execution.
>> Primary goal of this is for CRIU on arm - we need to restore vDSO image
>> at the exactly same place where the vma was in dumped application. With
>> the help of this hook we'll move vDSO at the new position.
>> The CRIU code handles situations like when vDSO of dumped application
>> was different from vDSO on restoring system. This usally happens when
>> some new symbols are being added to vDSO. In these situations CRIU
>> inserts jump trampolines from old vDSO blob to new vDSO on restore.
>> By that reason even if on restore vDSO blob lies on the same address as
>> blob in dumped application - we still need to move it if it differs.
>>
>> There was previously attempt to add this functionality for arm64 by
>> arch_mremap hook [1], while this patch introduces this with minimal
>> effort - the same way I've added it to x86:
>> commit b059a453b1cf ("x86/vdso: Add mremap hook to vm_special_mapping")
>>
>> At this moment, vdso restoring code is disabled for arm/arm64 arch
>> in CRIU [2], so C/R is only working for !CONFIG_VDSO kernels. This patch
>> is aimed to fix that.
>> The same hook may be introduced for arm64 kernel, but at this moment
>> arm64 vdso code is actively reworked by Kevin, so we can do it on top.
>> Separately, I've refactored arch_remap hook out from ppc64 [3].
>>
>> [1]: https://marc.info/?i=1448455781-26660-1-git-send-email-cov at codeaurora.org
>> [2]: https://github.com/xemul/criu/blob/master/Makefile#L39
>> [3]: https://marc.info/?i=20161027170948.8279-1-dsafonov at virtuozzo.com
>>
>> Cc: Kevin Brodsky <kevin.brodsky@arm.com>
>> Cc: Christopher Covington <cov@codeaurora.org>
>> Cc: Andy Lutomirski <luto@amacapital.net>
>> Cc: Oleg Nesterov <oleg@redhat.com>
>> Cc: Russell King <linux@armlinux.org.uk>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-mm at kvack.org
>> Cc: Cyrill Gorcunov <gorcunov@openvz.org>
>> Cc: Pavel Emelyanov <xemul@virtuozzo.com>
>> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
>> ---
>> arch/arm/kernel/vdso.c | 21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
>> index 53cf86cf2d1a..d1001f87c2f6 100644
>> --- a/arch/arm/kernel/vdso.c
>> +++ b/arch/arm/kernel/vdso.c
>> @@ -54,8 +54,11 @@ static const struct vm_special_mapping vdso_data_mapping = {
>> .pages = &vdso_data_page,
>> };
>>
>> +static int vdso_mremap(const struct vm_special_mapping *sm,
>> + struct vm_area_struct *new_vma);
>> static struct vm_special_mapping vdso_text_mapping __ro_after_init = {
>> .name = "[vdso]",
>> + .mremap = vdso_mremap,
>> };
>>
>> struct elfinfo {
>> @@ -254,6 +257,24 @@ void arm_install_vdso(struct mm_struct *mm, unsigned long addr)
>> mm->context.vdso = addr;
>> }
>>
>> +static int vdso_mremap(const struct vm_special_mapping *sm,
>> + struct vm_area_struct *new_vma)
>> +{
>> + unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
>> + unsigned long vdso_size = (vdso_total_pages - 1) << PAGE_SHIFT;
>> +
>> + /* Disallow partial vDSO blob remap */
>> + if (vdso_size != new_size)
>> + return -EINVAL;
>> +
>> + if (WARN_ON_ONCE(current->mm != new_vma->vm_mm))
>> + return -EFAULT;
>> +
>> + current->mm->context.vdso = new_vma->vm_start;
>> +
>> + return 0;
>> +}
>> +
>> static void vdso_write_begin(struct vdso_data *vdata)
>> {
>> ++vdso_data->seq_count;
>>
>
> What do you think about putting this code somewhere generic (not under
> arch/*), so that powerpc and arm64 can reuse it once the cosmetic changes
> to make them compatible are made? My thought was that it could be defined
> underneath CONFIG_GENERIC_VDSO, which architectures could select as they
> became compatible.
Hi Chistopher,
Well, I don't think we won something out of generalization of simple
assignment for context.vdso pointer accross arches. And a need to rename
vdso over arches for saving one single line?
Also I don't like a bit this arch_mremap hook and need to nullify
vdso pointer.
But, anyway, I don't mind if your patches got applied instead - this
unability to move vdso prevent's to support vdso vma C/R, as you know ;)
--
Dmitry
^ permalink raw reply
* [PATCH] serial: sirf: Simplify a test
From: Julia Lawall @ 2016-11-07 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2916662.De1FDumaQl@wuerfel>
On Mon, 7 Nov 2016, Arnd Bergmann wrote:
> On Tuesday, November 1, 2016 8:03:33 AM CET Christophe JAILLET wrote:
> > 'dmaengine_prep_dma_cyclic()' does not return an error pointer, so the test
> > can be simplified to be more consistent.
> >
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>
> The change looks correct in principle. It would be good to automate looking
> for other instances of this bug. How did you find it? Do you have e.g. a
> coccinelle script or did you just stumble over the issue by accident?
I'm working on collecting this information in a more general way. It is
complicated by the fact that there are some functions that have the same
names but different behaviors, and I want to be clear about when that is
an issue. There are nevertheless limits to the accuracy that can be
obtained with Coccinelle, because Coccinelle doesn't take values into
account. Sometimes a variable is initialized to NULL, just to have a
starting value, but in practice the only way to reach an error return is
via conditionals that have the effect of ensuring that the value is
ERR_PTR. So at least the cases that are reported as being able to return
both NULL and ERR_PTR will need some careful checking.
julia
>
> There is one problem with your patch:
>
> > drivers/tty/serial/sirfsoc_uart.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/tty/serial/sirfsoc_uart.c b/drivers/tty/serial/sirfsoc_uart.c
> > index b186c9c4f850..666ca3156961 100644
> > --- a/drivers/tty/serial/sirfsoc_uart.c
> > +++ b/drivers/tty/serial/sirfsoc_uart.c
> > @@ -609,7 +609,7 @@ static void sirfsoc_uart_start_next_rx_dma(struct uart_port *port)
> > sirfport->rx_dma_items.dma_addr, SIRFSOC_RX_DMA_BUF_SIZE,
> > SIRFSOC_RX_DMA_BUF_SIZE / 2,
> > DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
> > - if (IS_ERR_OR_NULL(sirfport->rx_dma_items.desc)) {
> > + if (!sirfport->rx_dma_items.desc) {
> > dev_err(port->dev, "DMA slave single fail\n");
> > return;
> > }
>
> The serial driver is for the sirf platform, which uses the sirf-dma
> dmaengine driver, and that particular driver has an incorrect
> dma_prep_cyclic implementation, so I think we also need this fix:
>
> diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
> index 8f62edad51be..220c611c89ae 100644
> --- a/drivers/dma/sirf-dma.c
> +++ b/drivers/dma/sirf-dma.c
> @@ -775,7 +775,7 @@ sirfsoc_dma_prep_cyclic(struct dma_chan *chan, dma_addr_t addr,
> * BUFB
> */
> if (buf_len != 2 * period_len)
> - return ERR_PTR(-EINVAL);
> + return NULL;
>
> /* Get free descriptor */
> spin_lock_irqsave(&schan->lock, iflags);
>
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 3/6] clk: Add driver for Maxim-8997 PMIC clocks
From: Pankaj Dubey @ 2016-11-07 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <63750c2f-35cb-91ab-276b-c788f51081cb@osg.samsung.com>
Hi Javier,
On 7 November 2016 at 20:31, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> Hello Pankaj,
>
> On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
>> The MAX8997 PMIC has 32.786kHz crystal oscillator which provides an
>> accurate low frequency clock for MAX8997 internal circuit as well as
>> external circuit. This patch adds support for these two clocks.
>>
>> CC: Michael Turquette <mturquette@baylibre.com>
>> CC: Rob Herring <robh+dt@kernel.org>
>> CC: devicetree at vger.kernel.org
>> CC: linux-clk at vger.kernel.org
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>
> What kernel version are you basing this on? The Maxim common clock code
This patch series, I have prepared on Krzysztof's for-next which is 4.9-rc1,
> is going away for v4.9 and instead the clk-max77686 driver supports both
> 77686 and 77802 clocks. See commit 8ad313fe4e00 ("clk: max77686: Combine
> Maxim max77686 and max77802 driver").
>
> Since the 8997 clock IP looks very similar to 77802 AFAICT, you should
> also extend the clk-max77686 driver to have 8997 support.
>
I was not aware of this change. I will check this and if I can
reuse/extend max77686 for 8997 I will do it.
Thanks,
Pankaj Dubey
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/6] Add support for MAX8997 Clock Driver
From: Krzysztof Kozlowski @ 2016-11-07 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-1-git-send-email-pankaj.dubey@samsung.com>
On Mon, Nov 07, 2016 at 03:39:30PM +0530, Pankaj Dubey wrote:
> During recent test on Exynos4210 based Origen board, I observed
> RTC1 probe is failing giving following error message:
>
> [ 2.195817] s3c-rtc 10070000.rtc: failed to find rtc source clock
> [ 2.200475] s3c-rtc: probe of 10070000.rtc failed with error -2
> [ 2.206597] i2c /dev entries driver
>
> This is mainly because S3C-RTC expects two clocks "rtc" and "rtc_src".
> In case of Origen board this second clock is supplied by MAX8997 clock
> oscillator.
> This patch series modified MAX8997 MFD driver for supporting regmap, and
> adds max8997-clk driver. Also it documentation where-ever required and
> extends RTC node in exynos4210-origen.dts for supporting both clocks.
>
> After this patch series, RTC is getting probed properly on Origen board.
>
> This patch series is tested for SMP boot on Origen board.
No need to re-invent the wheel:
https://lkml.org/lkml/2016/6/17/57
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/437113.html
I won't be sending updates for these patches. Feel free to continue the
work.
BR,
Krzysztof
>
> Pankaj Dubey (6):
> mfd: max8997: Initialize max8997 register map
> dt-bindings: clk: max8997: Add DT binding documentation
> clk: Add driver for Maxim-8997 PMIC clocks
> ARM: dts: Add clock provider specific properties to max8997 node
> mfd: max8997: Add max8997-clk name in mfd_cell
> ARM: dts: Extend the S3C RTC node with rtc_src clock
>
> .../devicetree/bindings/clock/maxim,max8997.txt | 44 +++++++++++++
> .../bindings/regulator/max8997-regulator.txt | 3 +
> arch/arm/boot/dts/exynos4210-origen.dts | 6 +-
> arch/arm/boot/dts/exynos4210-trats.dts | 3 +-
> drivers/clk/Kconfig | 10 +++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-max8997.c | 76 ++++++++++++++++++++++
> drivers/mfd/max8997.c | 15 +++++
> include/dt-bindings/clock/maxim,max8997.h | 23 +++++++
> include/linux/mfd/max8997-private.h | 3 +
> 10 files changed, 182 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/maxim,max8997.txt
> create mode 100644 drivers/clk/clk-max8997.c
> create mode 100644 include/dt-bindings/clock/maxim,max8997.h
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH V3 1/2] ARM: imx: mmdc perf function support i.MX6QP
From: Frank Li @ 2016-11-07 17:30 UTC (permalink / raw)
To: linux-arm-kernel
i.MX6QP added new register bit PROFILE_SEL in MADPCR0.
need set it at perf start.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Change from V2 - V3
- Use MMDC_FLAG_PROFILE_SEL
- Use flags instead of driver_data
- fix commit message typo
- add const
- use u32 val.
Change from V1 - V2
- remove fsl_mmdc_devtype
arch/arm/mach-imx/mmdc.c | 38 ++++++++++++++++++++++++++++++++------
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
index d82d14c..ba96bf9 100644
--- a/arch/arm/mach-imx/mmdc.c
+++ b/arch/arm/mach-imx/mmdc.c
@@ -44,6 +44,7 @@
#define DBG_RST 0x2
#define PRF_FRZ 0x4
#define CYC_OVF 0x8
+#define PROFILE_SEL 0x10
#define MMDC_MADPCR0 0x410
#define MMDC_MADPSR0 0x418
@@ -55,10 +56,29 @@
#define MMDC_NUM_COUNTERS 6
+#define MMDC_FLAG_PROFILE_SEL 0x1
+
#define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
static int ddr_type;
+struct fsl_mmdc_devtype_data {
+ unsigned int flags;
+};
+
+static const struct fsl_mmdc_devtype_data imx6q_data = {
+};
+
+static const struct fsl_mmdc_devtype_data imx6qp_data = {
+ .flags = MMDC_FLAG_PROFILE_SEL,
+};
+
+static const struct of_device_id imx_mmdc_dt_ids[] = {
+ { .compatible = "fsl,imx6q-mmdc", .data = (void *)&imx6q_data},
+ { .compatible = "fsl,imx6qp-mmdc", .data = (void *)&imx6qp_data},
+ { /* sentinel */ }
+};
+
#ifdef CONFIG_PERF_EVENTS
static DEFINE_IDA(mmdc_ida);
@@ -83,6 +103,7 @@ struct mmdc_pmu {
struct device *dev;
struct perf_event *mmdc_events[MMDC_NUM_COUNTERS];
struct hlist_node node;
+ struct fsl_mmdc_devtype_data *devtype_data;
};
/*
@@ -307,6 +328,7 @@ static void mmdc_pmu_event_start(struct perf_event *event, int flags)
struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
void __iomem *mmdc_base, *reg;
+ u32 val;
mmdc_base = pmu_mmdc->mmdc_base;
reg = mmdc_base + MMDC_MADPCR0;
@@ -321,7 +343,12 @@ static void mmdc_pmu_event_start(struct perf_event *event, int flags)
local64_set(&hwc->prev_count, 0);
writel(DBG_RST, reg);
- writel(DBG_EN, reg);
+
+ val = DBG_EN;
+ if (pmu_mmdc->devtype_data->flags & MMDC_FLAG_PROFILE_SEL)
+ val |= PROFILE_SEL;
+
+ writel(val, reg);
}
static int mmdc_pmu_event_add(struct perf_event *event, int flags)
@@ -436,6 +463,8 @@ static int imx_mmdc_perf_init(struct platform_device *pdev, void __iomem *mmdc_b
char *name;
int mmdc_num;
int ret;
+ const struct of_device_id *of_id =
+ of_match_device(imx_mmdc_dt_ids, &pdev->dev);
pmu_mmdc = kzalloc(sizeof(*pmu_mmdc), GFP_KERNEL);
if (!pmu_mmdc) {
@@ -450,6 +479,8 @@ static int imx_mmdc_perf_init(struct platform_device *pdev, void __iomem *mmdc_b
name = devm_kasprintf(&pdev->dev,
GFP_KERNEL, "mmdc%d", mmdc_num);
+ pmu_mmdc->devtype_data = (struct fsl_mmdc_devtype_data *)of_id->data;
+
hrtimer_init(&pmu_mmdc->hrtimer, CLOCK_MONOTONIC,
HRTIMER_MODE_REL);
pmu_mmdc->hrtimer.function = mmdc_pmu_timer_handler;
@@ -524,11 +555,6 @@ int imx_mmdc_get_ddr_type(void)
return ddr_type;
}
-static const struct of_device_id imx_mmdc_dt_ids[] = {
- { .compatible = "fsl,imx6q-mmdc", },
- { /* sentinel */ }
-};
-
static struct platform_driver imx_mmdc_driver = {
.driver = {
.name = "imx-mmdc",
--
2.5.2
^ permalink raw reply related
* [PATCH V3 2/2] ARM: dts: add new compatible stream for i.MX6QP mmdc
From: Frank Li @ 2016-11-07 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478539849-10834-1-git-send-email-Frank.Li@nxp.com>
MMDC has a slightly different programming model between imx6q and imx6qp
in terms of perf support, it's exactly same for suspend support, so we
have fsl,imx6q-mmdc here to save patching suspend driver with the new
compatible.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Change from V3 to V2
- change commit message to show suspend need fsl,imx6q-mmdc
arch/arm/boot/dts/imx6qp.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qp.dtsi b/arch/arm/boot/dts/imx6qp.dtsi
index 886dbf2..e0fdd0f 100644
--- a/arch/arm/boot/dts/imx6qp.dtsi
+++ b/arch/arm/boot/dts/imx6qp.dtsi
@@ -85,5 +85,12 @@
pcie: pcie at 0x01000000 {
compatible = "fsl,imx6qp-pcie", "snps,dw-pcie";
};
+
+ aips-bus at 02100000 {
+ mmdc0: mmdc at 021b0000 { /* MMDC0 */
+ compatible = "fsl,imx6qp-mmdc", "fsl,imx6q-mmdc";
+ reg = <0x021b0000 0x4000>;
+ };
+ };
};
};
--
2.5.2
^ permalink raw reply related
* [PATCH V3 0/6] ARM64: Uprobe support added
From: Pratyush Anand @ 2016-11-07 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107113944.GB28876@MBP.local>
On Monday 07 November 2016 05:09 PM, Catalin Marinas wrote:
>> diff --git a/arch/arm64/kernel/probes/decode-insn.c
>> > b/arch/arm64/kernel/probes/decode-insn.c
>> > index 8a29d29..6bf6657 100644
>> > --- a/arch/arm64/kernel/probes/decode-insn.c
>> > +++ b/arch/arm64/kernel/probes/decode-insn.c
>> > @@ -17,7 +17,6 @@
>> > #include <linux/kprobes.h>
>> > #include <linux/module.h>
>> > #include <linux/kallsyms.h>
>> > -#include <asm/kprobes.h>
>> > #include <asm/insn.h>
>> > #include <asm/sections.h>
>> >
>> > So, do you want me to send V4 or a separate topup fixup patch. Please let me
>> > know, will do accordingly.
> Just a separate patch on top of your series would do. Also please test
> your series with CONFIG_KPROBE disabled and I assume this wasn't done
> (just in case there is an interaction we were not aware of).
OK, I tested by disabling CONFIG_KPROBE, and uprobe tests worked fine.
~Pratyush
^ permalink raw reply
* [PATCH] arm64: fix error: conflicting types for 'kprobe_fault_handler'
From: Pratyush Anand @ 2016-11-07 17:37 UTC (permalink / raw)
To: linux-arm-kernel
When CONFIG_KPROBE is disabled but CONFIG_UPROBE_EVENT is enabled, we get
following compilation error:
In file included from
.../arch/arm64/kernel/probes/decode-insn.c:20:0:
.../arch/arm64/include/asm/kprobes.h:52:5: error:
conflicting types for 'kprobe_fault_handler'
int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
^~~~~~~~~~~~~~~~~~~~
In file included from
.../arch/arm64/kernel/probes/decode-insn.c:17:0:
.../include/linux/kprobes.h:398:90: note:
previous definition of 'kprobe_fault_handler' was here
static inline int kprobe_fault_handler(struct pt_regs *regs, int trapnr)
^
.../scripts/Makefile.build:290: recipe for target
'arch/arm64/kernel/probes/decode-insn.o' failed
<asm/kprobes.h> is already included from <linux/kprobes.h> under #ifdef
CONFIG_KPROBE. So, this patch fixes the error by removing it from
decode-insn.c.
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
arch/arm64/kernel/probes/decode-insn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/kernel/probes/decode-insn.c b/arch/arm64/kernel/probes/decode-insn.c
index 8a29d2982eec..6bf6657a5a52 100644
--- a/arch/arm64/kernel/probes/decode-insn.c
+++ b/arch/arm64/kernel/probes/decode-insn.c
@@ -17,7 +17,6 @@
#include <linux/kprobes.h>
#include <linux/module.h>
#include <linux/kallsyms.h>
-#include <asm/kprobes.h>
#include <asm/insn.h>
#include <asm/sections.h>
--
2.7.4
^ permalink raw reply related
* [PATCH 3/6] clk: Add driver for Maxim-8997 PMIC clocks
From: Krzysztof Kozlowski @ 2016-11-07 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-4-git-send-email-pankaj.dubey@samsung.com>
On Mon, Nov 07, 2016 at 03:39:33PM +0530, Pankaj Dubey wrote:
> The MAX8997 PMIC has 32.786kHz crystal oscillator which provides an
> accurate low frequency clock for MAX8997 internal circuit as well as
> external circuit. This patch adds support for these two clocks.
>
> CC: Michael Turquette <mturquette@baylibre.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree at vger.kernel.org
> CC: linux-clk at vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> drivers/clk/Kconfig | 10 ++++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-max8997.c | 76 +++++++++++++++++++++++++++++++
> include/dt-bindings/clock/maxim,max8997.h | 23 ++++++++++
You need to split the dt-bindings header into separate one so others
could pull it. Please also mention the dependencies between patches in
cover letter, because it does not look like it could be applied as is.
Best regards,
Krzysztof
^ 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