* [PATCH 0/2] Fix fallouts from asm/opcodes.h removal
From: Marc Zyngier @ 2016-12-03 14:05 UTC (permalink / raw)
To: linux-arm-kernel
Since the asm/opcodes.h file was removed, two bugs have cropped up:
- probes.h contains a reference to asm/opcodes.h that was missed
- An ugly (and alas familiar) bug has reappeared, leading to obscure
compilation errors when a .inst is part of an alternative and that
the "auto nop" feature is used to pad the alternative sequence (and
the whole thing is assembled with an old version of gas). This is
triggered again now that we generate SET_PSTATE_PAN/UAO using .inst.
The first bug is easy to fix, while the second requires some really
ugly (if limited) surgery using the .fill directive to replace the
"nops" macro.
Marc Zyngier (2):
arm64: Remove reference to asm/opcodes.h
arm64: alternatives: Work around NOP generation with broken assembler
arch/arm64/include/asm/alternative.h | 12 +++++++++++-
arch/arm64/include/asm/probes.h | 2 --
2 files changed, 11 insertions(+), 3 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH 1/2] arm64: Remove reference to asm/opcodes.h
From: Marc Zyngier @ 2016-12-03 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161203140538.23525-1-marc.zyngier@arm.com>
The asm/opcodes.h file is now gone, but probes.h still references it
for not obvious reason. Removing the #include directive fixes
the compilation.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/probes.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
index e175a82..6a5b289 100644
--- a/arch/arm64/include/asm/probes.h
+++ b/arch/arm64/include/asm/probes.h
@@ -15,8 +15,6 @@
#ifndef _ARM_PROBES_H
#define _ARM_PROBES_H
-#include <asm/opcodes.h>
-
typedef u32 probe_opcode_t;
typedef void (probes_handler_t) (u32 opcode, long addr, struct pt_regs *);
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] arm64: alternatives: Work around NOP generation with broken assembler
From: Marc Zyngier @ 2016-12-03 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161203140538.23525-1-marc.zyngier@arm.com>
When compiling a .inst directive in an alternative clause with
a rather old version of gas (circa 2.24), and when used with
the alternative_else_nop_endif feature, the compilation fails
with a rather cryptic message such as:
arch/arm64/lib/clear_user.S:33: Error: bad or irreducible absolute expression
which is caused by the bug described in eb7c11ee3c5c ("arm64:
alternative: Work around .inst assembler bugs").
This effectively prevents the use of the "nops" macro, which
requires the number of instruction as a parameter (the assembler
is confused and unable to compute the difference between two labels).
As an alternative(!), use the .fill directive to output the number
of required NOPs (.fill has the good idea to output the fill pattern
in the endianness of the instruction stream).
Fixes: 792d47379f4d ("arm64: alternative: add auto-nop infrastructure")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/alternative.h | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index 39feb85..39f8c98 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -159,9 +159,19 @@ void apply_alternatives(void *start, size_t length);
* of NOPs. The number of NOPs is chosen automatically to match the
* previous case.
*/
+
+#define NOP_INST 0xd503201f
+
.macro alternative_else_nop_endif
alternative_else
- nops (662b-661b) / AARCH64_INSN_SIZE
+ /*
+ * The same assembler bug strikes again here if the first half
+ * of the alternative sequence contains a .inst, leading to a
+ * bizarre error message. Fortulately, .fill replaces the
+ * "nops" macro by inserting padding with the target machine
+ * endianness.
+ */
+ .fill (662b-661b) / AARCH64_INSN_SIZE, AARCH64_INSN_SIZE, NOP_INST
alternative_endif
.endm
--
2.10.2
^ permalink raw reply related
* [arm64:for-next/core 52/52] arch/arm64/include/asm/probes.h:18:25: fatal error: asm/opcodes.h: No such file or directory
From: Marc Zyngier @ 2016-12-03 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86h96lmh5p.fsf@arm.com>
On Sat, 03 Dec 2016 10:38:26 +0000
Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Fri, Dec 02 2016 at 10:05:27 PM, kbuild test robot <fengguang.wu@intel.com> wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
> > head: bca8f17f57bd76ddf2bbd2527eb890d6f588853e
> > commit: bca8f17f57bd76ddf2bbd2527eb890d6f588853e [52/52] arm64: Get rid of asm/opcodes.h
> > config: arm64-allmodconfig (attached as .config)
> > compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> > reproduce:
> > wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout bca8f17f57bd76ddf2bbd2527eb890d6f588853e
> > # save the attached .config to linux build tree
> > make.cross ARCH=arm64
> >
> > All errors (new ones prefixed by >>):
> >
> > In file included from arch/arm64/include/asm/uprobes.h:14:0,
> > from include/linux/uprobes.h:61,
> > from include/linux/mm_types.h:13,
> > from include/linux/sched.h:27,
> > from arch/arm64/kernel/asm-offsets.c:21:
> >>> arch/arm64/include/asm/probes.h:18:25: fatal error: asm/opcodes.h: No such file or directory
> > #include <asm/opcodes.h>
> > ^
> > compilation terminated.
> > make[2]: *** [arch/arm64/kernel/asm-offsets.s] Error 1
> > make[2]: Target '__build' not remade because of errors.
> > make[1]: *** [prepare0] Error 2
> > make[1]: Target 'prepare' not remade because of errors.
> > make: *** [sub-make] Error 2
>
> Blah. Bloody uprobes. Just deleting this line should be enough, as I
> can't see anything that actually depends on what is in the 32bit
> asm/opcodes.h.
>
> I can submit a patch if needed.
Well, another (slightly more serious) bug has cropped up, so I just sent
a small patch series that addresses both.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH 1/2] soc: zte: pm_domains: Prepare for supporting ARMv8 2967 family
From: Baoyou Xie @ 2016-12-03 14:11 UTC (permalink / raw)
To: linux-arm-kernel
The ARMv8 2967 family (296718, 296716 etc) uses different value
for controlling the power domain on/off registers, Choose the
value depending on the compatible.
Multiple domains are prepared for the family, it's privated by
the drivers of boards.
This patch prepares the common functions.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 1 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/zte/Kconfig | 13 ++++
drivers/soc/zte/Makefile | 4 ++
drivers/soc/zte/pm_domains.c | 138 +++++++++++++++++++++++++++++++++++++++++++
drivers/soc/zte/pm_domains.h | 29 +++++++++
7 files changed, 187 insertions(+)
create mode 100644 drivers/soc/zte/Kconfig
create mode 100644 drivers/soc/zte/Makefile
create mode 100644 drivers/soc/zte/pm_domains.c
create mode 100644 drivers/soc/zte/pm_domains.h
diff --git a/MAINTAINERS b/MAINTAINERS
index ad199da..8198389 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1979,6 +1979,7 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
+F: drivers/soc/zte/
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f31bceb..f09023f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/ux500/Kconfig"
source "drivers/soc/versatile/Kconfig"
+source "drivers/soc/zte/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 50c23d0..05eae52 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
+obj-$(CONFIG_ARCH_ZX) += zte/
diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
new file mode 100644
index 0000000..4953c3fa
--- /dev/null
+++ b/drivers/soc/zte/Kconfig
@@ -0,0 +1,13 @@
+#
+# zx SoC drivers
+#
+menuconfig SOC_ZX
+ bool "zx SoC driver support"
+
+if SOC_ZX
+
+config ZX_PM_DOMAINS
+ bool "zx PM domains"
+ depends on PM_GENERIC_DOMAINS
+
+endif
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
new file mode 100644
index 0000000..97ac8ea
--- /dev/null
+++ b/drivers/soc/zte/Makefile
@@ -0,0 +1,4 @@
+#
+# zx SOC drivers
+#
+obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o
diff --git a/drivers/soc/zte/pm_domains.c b/drivers/soc/zte/pm_domains.c
new file mode 100644
index 0000000..5792f21
--- /dev/null
+++ b/drivers/soc/zte/pm_domains.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2015 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include "pm_domains.h"
+
+#define PCU_DM_CLKEN 0x18
+#define PCU_DM_RSTEN 0x20
+#define PCU_DM_ISOEN 0x1c
+#define PCU_DM_PWREN 0x24
+#define PCU_DM_ACK_SYNC 0x28
+
+static void __iomem *pcubase;
+
+int zx_normal_power_on(struct generic_pm_domain *domain)
+{
+ struct zx_pm_domain *zpd = (struct zx_pm_domain *)domain;
+ unsigned long loop = 20000;
+ u32 val;
+
+ loop = 1000;
+ do {
+ val = readl_relaxed(pcubase + PCU_DM_PWREN);
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN);
+
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC) & BIT(zpd->bit);
+ } while (--loop && !val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val | BIT(zpd->bit), pcubase + PCU_DM_RSTEN);
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN);
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val | BIT(zpd->bit), pcubase + PCU_DM_CLKEN);
+ udelay(5);
+
+ pr_info("normal poweron %s\n", domain->name);
+
+ return 0;
+}
+
+int zx_normal_power_off(struct generic_pm_domain *domain)
+{
+ struct zx_pm_domain *zpd = (struct zx_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN);
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val | BIT(zpd->bit), pcubase + PCU_DM_ISOEN);
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN);
+ udelay(5);
+
+ loop = 1000;
+ do {
+ val = readl_relaxed(pcubase + PCU_DM_PWREN);
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN);
+
+ udelay(1);
+
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC) & BIT(zpd->bit);
+ } while (--loop && val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ pr_info("normal poweroff %s\n", domain->name);
+
+ return 0;
+}
+
+int
+zx_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num)
+{
+ struct genpd_onecell_data *genpd_data;
+ struct resource *res;
+ int i;
+
+ genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data), GFP_KERNEL);
+ if (!genpd_data)
+ return -ENOMEM;
+
+ genpd_data->domains = zx_pm_domains;
+ genpd_data->num_domains = domain_num;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "no memory resource defined\n");
+ return -ENODEV;
+ }
+
+ pcubase = devm_ioremap_resource(&pdev->dev, res);
+ if (!pcubase) {
+ dev_err(&pdev->dev, "ioremap fail.\n");
+ return -EIO;
+ }
+
+ for (i = 0; i < domain_num; ++i)
+ pm_genpd_init(zx_pm_domains[i], NULL, false);
+
+ of_genpd_add_provider_onecell(pdev->dev.of_node, genpd_data);
+ dev_info(&pdev->dev, "powerdomain init ok\n");
+ return 0;
+}
diff --git a/drivers/soc/zte/pm_domains.h b/drivers/soc/zte/pm_domains.h
new file mode 100644
index 0000000..613e0be
--- /dev/null
+++ b/drivers/soc/zte/pm_domains.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2015 ZTE Co., Ltd.
+ * http://www.zte.com.cn
+ *
+ * Header for ZTE's Power Domain Driver support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ZTE_PM_DOMAIN_H
+#define __ZTE_PM_DOMAIN_H
+
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+
+struct zx_pm_domain {
+ struct generic_pm_domain dm;
+ unsigned int bit;
+};
+
+extern int zx_normal_power_on(struct generic_pm_domain *domain);
+extern int zx_normal_power_off(struct generic_pm_domain *domain);
+extern int
+zx_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num);
+#endif /* __ZTE_PM_DOMAIN_H */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] soc: zte: pm_domains: Add support for zx296718 driver
From: Baoyou Xie @ 2016-12-03 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480774291-6211-1-git-send-email-baoyou.xie@linaro.org>
This patch introduces the power domain driver of zx296718
which belongs to zte's 2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/soc/zte/Makefile | 3 +
drivers/soc/zte/zx296718_pm_domains.c | 162 ++++++++++++++++++++++++++++++++++
2 files changed, 165 insertions(+)
create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
index 97ac8ea..a6e7bfe 100644
--- a/drivers/soc/zte/Makefile
+++ b/drivers/soc/zte/Makefile
@@ -2,3 +2,6 @@
# zx SOC drivers
#
obj-$(CONFIG_ZX_PM_DOMAINS) += pm_domains.o
+ifeq ($(CONFIG_ZX_PM_DOMAINS), y)
+ obj-y += zx296718_pm_domains.o
+endif
diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
new file mode 100644
index 0000000..fc16dfd
--- /dev/null
+++ b/drivers/soc/zte/zx296718_pm_domains.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright (C) 2015 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include "pm_domains.h"
+
+enum {
+ PCU_DM_VOU = 0,
+ PCU_DM_SAPPU,
+ PCU_DM_VDE,
+ PCU_DM_VCE,
+ PCU_DM_HDE,
+ PCU_DM_VIU,
+ PCU_DM_USB20,
+ PCU_DM_USB21,
+ PCU_DM_USB30,
+ PCU_DM_HSIC,
+ PCU_DM_GMAC,
+ PCU_DM_TS,
+};
+
+static struct zx_pm_domain vou_domain = {
+ .dm = {
+ .name = "vou_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VOU,
+};
+static struct zx_pm_domain sappu_domain = {
+ .dm = {
+ .name = "sappu_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_SAPPU,
+};
+static struct zx_pm_domain vde_domain = {
+ .dm = {
+ .name = "vde_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VDE,
+};
+static struct zx_pm_domain vce_domain = {
+ .dm = {
+ .name = "vce_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VCE,
+};
+static struct zx_pm_domain hde_domain = {
+ .dm = {
+ .name = "hde_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_HDE,
+};
+
+static struct zx_pm_domain viu_domain = {
+ .dm = {
+ .name = "viu_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_VIU,
+};
+static struct zx_pm_domain usb20_domain = {
+ .dm = {
+ .name = "usb20_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_USB20,
+};
+static struct zx_pm_domain usb21_domain = {
+ .dm = {
+ .name = "usb21_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_USB21,
+};
+static struct zx_pm_domain usb30_domain = {
+ .dm = {
+ .name = "usb30_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_USB30,
+};
+static struct zx_pm_domain hsic_domain = {
+ .dm = {
+ .name = "hsic_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_HSIC,
+};
+static struct zx_pm_domain gmac_domain = {
+ .dm = {
+ .name = "gmac_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_GMAC,
+};
+static struct zx_pm_domain ts_domain = {
+ .dm = {
+ .name = "ts_domain",
+ .power_off = zx_normal_power_off,
+ .power_on = zx_normal_power_on,
+ },
+ .bit = PCU_DM_TS,
+};
+struct generic_pm_domain *zx296718_pm_domains[] = {
+ //&vou_domain.dm,
+ &sappu_domain.dm,
+ &vde_domain.dm,
+ &vce_domain.dm,
+ &hde_domain.dm,
+ &viu_domain.dm,
+ &usb20_domain.dm,
+ &usb21_domain.dm,
+ &usb30_domain.dm,
+ &hsic_domain.dm,
+ &gmac_domain.dm,
+ &ts_domain.dm,
+ &vou_domain.dm,
+};
+
+static int zx296718_pd_probe(struct platform_device *pdev)
+{
+ return zx_pd_probe(pdev,
+ zx296718_pm_domains,
+ ARRAY_SIZE(zx296718_pm_domains));
+}
+
+static const struct of_device_id zx296718_pm_domain_matches[] = {
+ { .compatible = "zte,zx296718-pcu", },
+ { },
+};
+
+static struct platform_driver zx296718_pd_driver = {
+ .driver = {
+ .name = "zx-powerdomain",
+ .owner = THIS_MODULE,
+ .of_match_table = zx296718_pm_domain_matches,
+ },
+ .probe = zx296718_pd_probe,
+};
+
+static int __init zx296718_pd_init(void)
+{
+ return platform_driver_register(&zx296718_pd_driver);
+}
+subsys_initcall(zx296718_pd_init);
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Antonio Ospite @ 2016-12-03 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <df32cbf6-e897-56d9-89d8-c65af06323a8@datenfreihafen.org>
On Sat, 26 Nov 2016 00:30:52 +0100
Stefan Schmidt <stefan@datenfreihafen.org> wrote:
> Hello.
>
Hi everyone,
> On 25.11.2016 20:53, Robert Jarzmik wrote:
> > Stefan Schmidt <stefan@datenfreihafen.org> writes:
> >
> >> Hello.
> >>
> >> On 24.11.2016 17:29, Arnd Bergmann wrote:
> >>> The camera_supply_dummy_device definition is shared between a780 and a910,
> >>> but only provided when the first is enabled and fails to build for a
> >>> configuration with only a910:
> >>>
> >>> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
> >>>
> >>> This moves the definition into its own section.
> >>>
> >>> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
> >>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >>> ---
> >>> arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
> >>
> >> I wonder what we should do with ezx.c.
> >>
> >> As far as I know neither Daniel nor Harald or myself are doing anything
> >> with this devices anymore. Besides a basic compile test having an ack or
> >> reviewed by from our side is a bit worthless. :/
> >>
> >> I should still have some of these phones around in a box somewhere. If
> >> there is someone with a good motivation and time to take over on this
> >> platform we will find a way to get the person this devices.
> >>
> >> Any takers? Robert? I guess you are already overloaded but you might
> >> also have an interest. Worth asking :)
> > Oh yes, I'm very interested in your box. Besides I really like old platforms
> > :)
>
>
> Great! I should have at least 3 or 4 different devices from the EZX
> platform around. I will go and search for the box over the weekend :)
>
> >> In the case nobody wants to pick up here what would you consider the
> >> bets way forward? I could send a patch removing ezx platform support
> >> from the kernel (basically ezx.c plus build support) or I can send a
> >> patch marking it at least orphan in MAINTAINERS. Let me know what you think.
> >>
> >> Daniel, Harald, if one of you is still interested in these and what to
> >> pick up the work again, please speak up now. :)
> > Unless another maintainer steps in, you can submit a patch to transfer the
> > maintainance onto me, and we'll see off mailing lists how we could arange the
> > boards transfer.
>
> I cc'ed another developer who did a lot of work regarding EZX.
>
> Antonio, as you can see from the mail above we are pondering what who
> will maintain the ezx platform in the kernel going forward. Neither
> Daniel, Harald or me is going to do so. If you have time, interest and
> motivation to do so please speak up. I know life moved on and you ahve
> other projects and interests so do not feel pressured here. Just say no
> if you have no interest. Robert already agreed to act as a fallback so
> we would still be safe. :)
>
I still use a Motorola A1200 with the original EZX stack as my main
phone (and that tells something about how much I use a phone...)
however I haven't touched any OpenEZX stuff in a while.
I don't think I am going to play with these devices anytime soon, but I
can provide Robert any info he may need about OpenEZX, the development
tools and the out-of-tree patches required to make the phones somewhat
usable.
I have an off-line backup of the OpenEZX wiki as well if that should be
needed.
Robert, feel free to contact me off-list any time.
I also still hang out in the #openezx IRC channel on Freenode.
Ciao ciao,
Antonio
--
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
^ permalink raw reply
* [PATCH 0/2] ARM: mmp: Fine-tuning for sram_probe()
From: SF Markus Elfring @ 2016-12-03 16:57 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 3 Dec 2016 17:50:23 +0100
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Check return values from ioremap() and kstrdup()
Delete an unnecessary variable initialisation
arch/arm/mach-mmp/sram.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/2] ARM: mmp: Check return values from ioremap() and kstrdup() in sram_probe()
From: SF Markus Elfring @ 2016-12-03 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b687577b-e664-6aa1-a85c-438e96216171@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 3 Dec 2016 17:26:32 +0100
Two return values were not checked before their further use so far.
This issue was detected by using the Coccinelle software.
* Add a bit of exception handling.
* Adjust tump targets.
Fixes: 3c7241bd36e2a618fe20c91f6c69cc20f2d981f2 ("ARM: mmp: add sram allocator")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/arm/mach-mmp/sram.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
index bf5e64906e65..0fbfc2a42ab3 100644
--- a/arch/arm/mach-mmp/sram.c
+++ b/arch/arm/mach-mmp/sram.c
@@ -88,14 +88,24 @@ static int sram_probe(struct platform_device *pdev)
info->sram_phys = (phys_addr_t)res->start;
info->sram_size = resource_size(res);
info->sram_virt = ioremap(info->sram_phys, info->sram_size);
+ if (!info->sram_virt) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
info->pool_name = kstrdup(pdata->pool_name, GFP_KERNEL);
+ if (!info->pool_name) {
+ ret = -ENOMEM;
+ goto unmap_io;
+ }
+
info->granularity = pdata->granularity;
info->gpool = gen_pool_create(ilog2(info->granularity), -1);
if (!info->gpool) {
dev_err(&pdev->dev, "create pool failed\n");
ret = -ENOMEM;
- goto create_pool_err;
+ goto free_name;
}
ret = gen_pool_add_virt(info->gpool, (unsigned long)info->sram_virt,
@@ -117,9 +127,10 @@ static int sram_probe(struct platform_device *pdev)
add_chunk_err:
gen_pool_destroy(info->gpool);
-create_pool_err:
- iounmap(info->sram_virt);
+free_name:
kfree(info->pool_name);
+unmap_io:
+ iounmap(info->sram_virt);
out:
kfree(info);
return ret;
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] ARM: mmp: Delete an unnecessary variable initialisation in sram_probe()
From: SF Markus Elfring @ 2016-12-03 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b687577b-e664-6aa1-a85c-438e96216171@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 3 Dec 2016 17:38:21 +0100
The local variable "ret" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/arm/mach-mmp/sram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mmp/sram.c b/arch/arm/mach-mmp/sram.c
index 0fbfc2a42ab3..260e8309dfd3 100644
--- a/arch/arm/mach-mmp/sram.c
+++ b/arch/arm/mach-mmp/sram.c
@@ -66,7 +66,7 @@ static int sram_probe(struct platform_device *pdev)
struct sram_platdata *pdata = pdev->dev.platform_data;
struct sram_bank_info *info;
struct resource *res;
- int ret = 0;
+ int ret;
if (!pdata || !pdata->pool_name)
return -ENODEV;
--
2.11.0
^ permalink raw reply related
* [GIT PULL 1/3] ARM: exynos: Soc/mach for v4.10
From: Krzysztof Kozlowski @ 2016-12-03 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57568492.9hbg5JCdec@wuerfel>
On Fri, Dec 02, 2016 at 10:52:57PM +0100, Arnd Bergmann wrote:
> On Thursday, December 1, 2016 8:34:04 PM CET Krzysztof Kozlowski wrote:
> > On Thu, Nov 24, 2016 at 08:08:27AM +0200, Krzysztof Kozlowski wrote:
> > > Hi,
> > >
> > > This contains previous dts branch because SCU node in dts is needed
> > > prior to removing it from mach code.
> > >
> > > Below you will find full pull request and one stripped from dependency.
> > >
> >
> > Hi Arnd, Kevin and Olof,
> >
> > What about this pull from the set?
> >
>
> Sorry, I initially deferred it and then didn't get back to it.
>
> The dependency on the .dts changes made me a bit nervous about
> taking it, mostly because the changelog fails to explain the
> exact dependencies.
>
> This breaks compatibility with existing .dtb files, right?
No, strictly speaking not. There was no dt-bindings change here, no DT
properties for SCU before. We are converting our drivers to DTB so this
is the same as before when switching for pinctrl, clocks or all other
drivers to DT.
We are not braking DTB ABI because there was no ABI around it before.
Otherwise, one would say that lack of SCU DT node was an ABI. That is
wrong, because DT should describe the hardware and SCU is in hardware.
> What I'd like to see here is an explanation about:
>
> - what the upside of breaking compatibility is
DTBs which do not have SCU are not proper because they skip that part of
hardware. However we are breaking them in the way the SMP won't work
there. It is not an ABI break, as I mentioned above.
> - what exactly stops working with an old dtb
> - why we don't keep a fallback for handling old dtb files
What is the point for it? This is not an ABI break. Even if it was,
Samsung guys don't care for ABI breaks at all (and in fact we wanted to
mark the platform experimental...).
> It would also be helpful to have a separate pull request for
> the commits require the new dtb, and the stuff that is unrelated.
I can do that but the pull will be small.
Best regards,
Krzysztof
^ permalink raw reply
* [SPCR] mmio32 iotype access requirements for X-Gene 8250(_dw) UART
From: Mark Salter @ 2016-12-03 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7fa523de-3fbb-1566-f521-927143f73d1e@redhat.com>
On Sat, 2016-12-03 at 05:06 -0500, Jon Masters wrote:
> Hi Duc, all,
>
> (and changing the subject and trimming/adjusting the CC)
>
> On 12/02/2016 02:39 PM, Duc Dang wrote:
> >
> > On Fri, Dec 2, 2016 at 12:11 AM, Jon Masters <jcm@redhat.com> wrote:
> > >
> > > You're welcome.
> > >
> > > (Unrelated) Note that I added a console= and earlycon in my test (and
> > > got the baud rate wrong for the console but nevermind...was ssh'd in
> > > after the earlycon output I cared about anyway) because of some other
> > > cleanup work for the SPCR parsing that apparently is still not quite
> > > fixed for upstream, or rather, there is a need to match on the 32-bit
> > > access required for the UART and that isn't happening so it's not
> > > getting setup. Folks are tracking that one and fixing it though.
> >
> > I don't see this console issue on X-Gene1 (Mustang board). I tried
> > with X-Gene 2 as well. I used both console=ttyS0,115200 and
> > earlycon=uart8250,mmio32,0x1c020000. Are you setting baudrate to
> > 115200 or something else?
> Let me clarify. What I meant above is that when I generated the boot
> log, I had specified earlycon and console parameters, but had fat
> fingered the baud rate (m400 uses 9600, mustang uses 115200 baud).
> That's what I was referring to in the original text above.
>
> HOWEVER...
>
> There is a broader problem with X-Gene SPCR support. The problem is
> that the 16550 UART in X-Gene requires the 32-bit access quirk (the
> iotype is set to UPIO_MEM32 for the APMC0D08 device). This means
> that when univ8250_console_match runs later, it will compare the
> iotype (MEM32) with the type previously registered with the
> kernel when the earlycon setup the preferred console.
Linaro has a kernel patch which looks at the bit_width field of the
port address:
Author: Aleksey Makarov <aleksey.makarov@linaro.org>
Date:???Thu Apr 28 19:52:38 2016 +0300
????serial: SPCR: check bit width for the 16550 UART
The SPCR in 3.06.25 firmware has a bit_width field set to 32 and with the
above patch, I don't need to use console=. But HP firmware on m400 sets
bit width to 8 so that needs a firmware fix to work with above.
>
> The earlycon preferred console will parse the SPCR and find:
>
> ????????iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ?
> ????????????????????????"mmio" : "io";
>
> Which sets it to "mmio" (not "mmio32"). There is a DBG2 (the table
> referenced by the SPCR that provides the actual port types for all
> modern revisions of the SPCR with revision2+, as required by Linux)
> port subtype for non-compliant SBSA ARM Generic UARTs that require
> 32-bit accesses, and this is ACPI_DBG2_ARM_SBSA_32BIT (type 0xd).
>
> However that only applies for "pl011" devices, and doesn't provide
> for 16550 UARTs that require 32-bit accessors.
>
> So you'll end up with Linux thinking it's registering a non-32-bit
> mmio preferred console during earlycon setup and then never match
> against that later in the 8250_core/8250_dw match function by
> virtue of the fact that these differ.
>
> There are a couple of possibilities:
>
> 1). Perhaps (for some reason) the IP actually does support sub-32-bit
> ????access and the iotype simply needs to be changed to reflect this.
> ????That would be the easiest option. But it's been this way for a
> ????long time in various codebases, so I would be pleasantly
> ????surprised if this were the case. Let me/us know :)
>
> 2). We find some way during SPCR setup to quirk for X-Gene as a non
> ????standard 16550 and set it up as an mmio32 iotype.
>
> 3). We get the DBG2 table updated to add a subtype of the 16650
> ????called something like "(deprecated) 16550 subset supporting
> ????only 32-bit accesses". Then we add this to Linux and get
> ????the firmware updated on systems to switch to this type. We
> ????would probably still want to quirk for existing machines.
>
> Perhaps I'm missing something. I would love for that to be true,
> but I don't think it is. I think we need a subtype of the 16550
> defined that encapsulates this mmio32 requirement properly. To
> that end, I've preemptively asked some friends at MS for a
> favor to look into adding a new subtype for this.
>
> Let me know what you think is the best path... :)
>
> Thanks,
>
> Jon.
>
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Stefan Schmidt @ 2016-12-03 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161203175513.499a3affbb3e4a0640997f82@ao2.it>
Hello.
On 03.12.2016 17:55, Antonio Ospite wrote:
> On Sat, 26 Nov 2016 00:30:52 +0100
> Stefan Schmidt <stefan@datenfreihafen.org> wrote:
>
>> Hello.
>>
>
> Hi everyone,
>
>> On 25.11.2016 20:53, Robert Jarzmik wrote:
>>> Stefan Schmidt <stefan@datenfreihafen.org> writes:
>>>
>>>> Hello.
>>>>
>>>> On 24.11.2016 17:29, Arnd Bergmann wrote:
>>>>> The camera_supply_dummy_device definition is shared between a780 and a910,
>>>>> but only provided when the first is enabled and fails to build for a
>>>>> configuration with only a910:
>>>>>
>>>>> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
>>>>>
>>>>> This moves the definition into its own section.
>>>>>
>>>>> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
>>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>>>> ---
>>>>> arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
>>>>
>>>> I wonder what we should do with ezx.c.
>>>>
>>>> As far as I know neither Daniel nor Harald or myself are doing anything
>>>> with this devices anymore. Besides a basic compile test having an ack or
>>>> reviewed by from our side is a bit worthless. :/
>>>>
>>>> I should still have some of these phones around in a box somewhere. If
>>>> there is someone with a good motivation and time to take over on this
>>>> platform we will find a way to get the person this devices.
>>>>
>>>> Any takers? Robert? I guess you are already overloaded but you might
>>>> also have an interest. Worth asking :)
>>> Oh yes, I'm very interested in your box. Besides I really like old platforms
>>> :)
>>
>>
>> Great! I should have at least 3 or 4 different devices from the EZX
>> platform around. I will go and search for the box over the weekend :)
>>
>>>> In the case nobody wants to pick up here what would you consider the
>>>> bets way forward? I could send a patch removing ezx platform support
>>>> from the kernel (basically ezx.c plus build support) or I can send a
>>>> patch marking it at least orphan in MAINTAINERS. Let me know what you think.
>>>>
>>>> Daniel, Harald, if one of you is still interested in these and what to
>>>> pick up the work again, please speak up now. :)
>>> Unless another maintainer steps in, you can submit a patch to transfer the
>>> maintainance onto me, and we'll see off mailing lists how we could arange the
>>> boards transfer.
>>
>> I cc'ed another developer who did a lot of work regarding EZX.
>>
>> Antonio, as you can see from the mail above we are pondering what who
>> will maintain the ezx platform in the kernel going forward. Neither
>> Daniel, Harald or me is going to do so. If you have time, interest and
>> motivation to do so please speak up. I know life moved on and you ahve
>> other projects and interests so do not feel pressured here. Just say no
>> if you have no interest. Robert already agreed to act as a fallback so
>> we would still be safe. :)
>>
>
> I still use a Motorola A1200 with the original EZX stack as my main
> phone (and that tells something about how much I use a phone...)
hehe :)
> however I haven't touched any OpenEZX stuff in a while.
>
> I don't think I am going to play with these devices anytime soon, but I
> can provide Robert any info he may need about OpenEZX, the development
> tools and the out-of-tree patches required to make the phones somewhat
> usable.
Great. I think this will be a great help for Robert when he tries to get
things going. Thanks a lot!
Robert, please send me your address details off list so we can arrange
for the device shipping. I will send a patch transferring the
maintainership for the EZX platform over to you in the next days.
regards
Stefan Schmidt
^ permalink raw reply
* [PATCH v5] PM/devfreq: add suspend frequency support
From: Pavel Machek @ 2016-12-03 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478599598-26015-1-git-send-email-hl@rock-chips.com>
Hi!
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 98c6993..8567153 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -172,6 +172,7 @@ struct devfreq {
> struct delayed_work work;
>
> unsigned long previous_freq;
> + unsigned long suspend_freq;
> struct devfreq_dev_status last_status;
>
> void *data; /* private data for governors */
> @@ -179,6 +180,7 @@ struct devfreq {
> unsigned long min_freq;
> unsigned long max_freq;
> bool stop_polling;
> + bool suspend_flag;
>
> /* information for device frequency transition */
> unsigned int total_trans;
It would be nice to comment what "suspend_flag" is... plus... Would it
be possible to rename suspend_freq or suspend_flag? They are really
really similar visually...
Thanks.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161203/6d21481d/attachment.sig>
^ permalink raw reply
* [SPCR] mmio32 iotype access requirements for X-Gene 8250(_dw) UART
From: Jon Masters @ 2016-12-03 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480785308.4751.41.camel@redhat.com>
Hi Mark,
On 12/03/2016 12:15 PM, Mark Salter wrote:
> On Sat, 2016-12-03 at 05:06 -0500, Jon Masters wrote:
>> There is a broader problem with X-Gene SPCR support. The problem is
>> that the 16550 UART in X-Gene requires the 32-bit access quirk (the
>> iotype is set to UPIO_MEM32 for the APMC0D08 device). This means
>> that when univ8250_console_match runs later, it will compare the
>> iotype (MEM32) with the type previously registered with the
>> kernel when the earlycon setup the preferred console.
>
> Linaro has a kernel patch which looks at the bit_width field of the
> port address:
>
> Author: Aleksey Makarov <aleksey.makarov@linaro.org>
> Date: Thu Apr 28 19:52:38 2016 +0300
>
> serial: SPCR: check bit width for the 16550 UART
>
> The SPCR in 3.06.25 firmware has a bit_width field set to 32 and with the
> above patch, I don't need to use console=. But HP firmware on m400 sets
> bit width to 8 so that needs a firmware fix to work with above.
Indeed, thanks. Graeme also mentioned that last night. I think this
a good solution for the moment, but still that it makes sense to
have a new 16650 UART type defined in the DBG2 spec for those
requiring 32-bit access (to mirror the type D for pl011). I
heard back from Microsoft this morning that they're looking.
Jon.
--
Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
* [PATCH net-next 0/8] drivers: net: xgene: Add Jumbo and Pause frame support
From: David Miller @ 2016-12-03 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480639304-18757-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Thu, 1 Dec 2016 16:41:36 -0800
> This patch set adds,
>
> 1. Jumbo frame support
> 2. Pause frame based flow control
>
> and fixes RSS for non-TCP/UDP packets.
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Series applied, thanks.
^ permalink raw reply
* [PATCH] ARM: OMAP2+: PRM: Delete an error message for a failed memory allocation
From: SF Markus Elfring @ 2016-12-03 20:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 3 Dec 2016 21:46:02 +0100
Omit an extra message for a memory allocation failure in this function.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/arm/mach-omap2/prm_common.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 5b2f5138d938..2b138b65129a 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -295,10 +295,8 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
GFP_KERNEL);
if (!prcm_irq_chips || !prcm_irq_setup->saved_mask ||
- !prcm_irq_setup->priority_mask) {
- pr_err("PRCM: kzalloc failed\n");
+ !prcm_irq_setup->priority_mask)
goto err;
- }
memset(mask, 0, sizeof(mask));
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3][v2] dt-bindings: Add compatible for LS2088A QDS and RDB boards
From: Rob Herring @ 2016-12-03 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480325824-14649-2-git-send-email-abhimanyu.saini@nxp.com>
On Mon, Nov 28, 2016 at 03:07:02PM +0530, Abhimanyu Saini wrote:
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 11 +++++++++++
> 1 file changed, 11 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] arm: MAINTAINERS: transfer maintainership for the EZX platform
From: Stefan Schmidt @ 2016-12-03 21:59 UTC (permalink / raw)
To: linux-arm-kernel
Neither Daniel, Harald or myself are looking into this anymore.
Robert thankfully agreed to handle the maintenance from now on.
Also remove the outdated entries for website, git tree and
mailing list.
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
---
MAINTAINERS | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2dd40c5..661af76 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1203,13 +1203,9 @@ S: Maintained
N: efm32
ARM/EZX SMARTPHONES (A780, A910, A1200, E680, ROKR E2 and ROKR E6)
-M: Daniel Ribeiro <drwyrm@gmail.com>
-M: Stefan Schmidt <stefan@openezx.org>
-M: Harald Welte <laforge@openezx.org>
-L: openezx-devel at lists.openezx.org (moderated for non-subscribers)
-W: http://www.openezx.org/
+M: Robert Jarzmik <robert.jarzmik@free.fr>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
-T: topgit git://git.openezx.org/openezx.git
F: arch/arm/mach-pxa/ezx.c
ARM/FARADAY FA526 PORT
--
2.5.5
^ permalink raw reply related
* [PATCH v2 1/3] ARM: dts: vf610-zii-dev-rev-b: Remove leftover PWM pingroup
From: Andrey Smirnov @ 2016-12-03 22:30 UTC (permalink / raw)
To: linux-arm-kernel
Remove pwm0grp since it is:
a) Not referenced anywhere in the DTS file (unlike Tower board it
is based on, this board does not use/expose FTM0)
b) Configures PTB2 and PTB3 in a way that contradicts
pinctrl-mdio-mux
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
No changes since v1
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index fa19cfd..2210811 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -677,15 +677,6 @@
>;
};
- pinctrl_pwm0: pwm0grp {
- fsl,pins = <
- VF610_PAD_PTB0__FTM0_CH0 0x1582
- VF610_PAD_PTB1__FTM0_CH1 0x1582
- VF610_PAD_PTB2__FTM0_CH2 0x1582
- VF610_PAD_PTB3__FTM0_CH3 0x1582
- >;
- };
-
pinctrl_qspi0: qspi0grp {
fsl,pins = <
VF610_PAD_PTD7__QSPI0_B_QSCK 0x31c3
--
2.5.5
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: vf610-zii-dev: Add .dts file for rev. C
From: Andrey Smirnov @ 2016-12-03 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480804219-12596-1-git-send-email-andrew.smirnov@gmail.com>
Add .dts file for rev. C of the board by factoring out commonalities
into a shared include file (vf610-zii-dev.dtsi) and deriving revision
specific file from it (vf610-zii-dev-rev-b.dts and
vf610-zii-dev-reb-c.dts).
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
Changes since v1:
- Removed fixed-link nodes from switch{0,1}port10
- Changed compatiblity for switch0 to "marvell,mv88e6190"
- Removde port at 9 from swith0 as well as mdio node
- Renamed shared .dtsi to "vf610-zii-dev.dtsi", since same
basic deign is shared by more than Rev. B and Rev
C. development boards
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 300 +----------------------
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 394 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/vf610-zii-dev.dtsi | 383 +++++++++++++++++++++++++++++
4 files changed, 780 insertions(+), 300 deletions(-)
create mode 100644 arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
create mode 100644 arch/arm/boot/dts/vf610-zii-dev.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..9f0d2a1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -442,7 +442,8 @@ dtb-$(CONFIG_SOC_VF610) += \
vf610-cosmic.dtb \
vf610m4-cosmic.dtb \
vf610-twr.dtb \
- vf610-zii-dev-rev-b.dtb
+ vf610-zii-dev-rev-b.dtb \
+ vf610-zii-dev-rev-c.dtb
dtb-$(CONFIG_ARCH_MXS) += \
imx23-evk.dtb \
imx23-olinuxino.dtb \
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 2210811..c0fc3f2 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -43,32 +43,12 @@
*/
/dts-v1/;
-#include "vf610.dtsi"
+#include "vf610-zii-dev.dtsi"
/ {
model = "ZII VF610 Development Board, Rev B";
compatible = "zii,vf610dev-b", "zii,vf610dev", "fsl,vf610";
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory {
- reg = <0x80000000 0x20000000>;
- };
-
- gpio-leds {
- compatible = "gpio-leds";
- pinctrl-0 = <&pinctrl_leds_debug>;
- pinctrl-names = "default";
-
- debug {
- label = "zii:green:debug1";
- gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- };
- };
-
mdio-mux {
compatible = "mdio-mux-gpio";
pinctrl-0 = <&pinctrl_mdio_mux>;
@@ -281,25 +261,6 @@
};
};
- reg_vcc_3v3_mcu: regulator-vcc-3v3-mcu {
- compatible = "regulator-fixed";
- regulator-name = "vcc_3v3_mcu";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- usb0_vbus: regulator-usb0-vbus {
- compatible = "regulator-fixed";
- pinctrl-0 = <&pinctrl_usb_vbus>;
- regulator-name = "usb_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- enable-active-high;
- regulator-always-on;
- regulator-boot-on;
- gpio = <&gpio0 6 0>;
- };
-
spi0 {
compatible = "spi-gpio";
pinctrl-0 = <&pinctrl_gpio_spi0>;
@@ -336,49 +297,6 @@
};
};
-&adc0 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_adc0_ad5>;
- vref-supply = <®_vcc_3v3_mcu>;
- status = "okay";
-};
-
-&edma0 {
- status = "okay";
-};
-
-&esdhc1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_esdhc1>;
- bus-width = <4>;
- status = "okay";
-};
-
-&fec0 {
- phy-mode = "rmii";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec0>;
- status = "okay";
-};
-
-&fec1 {
- phy-mode = "rmii";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec1>;
- status = "okay";
-
- fixed-link {
- speed = <100>;
- full-duplex;
- };
-
- mdio1: mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- status = "okay";
- };
-};
-
&i2c0 {
clock-frequency = <100000>;
pinctrl-names = "default";
@@ -403,33 +321,6 @@
interrupt-parent = <&gpio2>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
};
-
- lm75 at 48 {
- compatible = "national,lm75";
- reg = <0x48>;
- };
-
- at24c04 at 50 {
- compatible = "atmel,24c04";
- reg = <0x50>;
- };
-
- at24c04 at 52 {
- compatible = "atmel,24c04";
- reg = <0x52>;
- };
-
- ds1682 at 6b {
- compatible = "dallas,ds1682";
- reg = <0x6b>;
- };
-};
-
-&i2c1 {
- clock-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c1>;
- status = "okay";
};
&i2c2 {
@@ -499,120 +390,8 @@
};
};
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart0>;
- status = "okay";
-};
-
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart1>;
- status = "okay";
-};
-
-&uart2 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart2>;
- status = "okay";
-};
-
-&usbdev0 {
- disable-over-current;
- vbus-supply = <&usb0_vbus>;
- dr_mode = "host";
- status = "okay";
-};
-
-&usbh1 {
- disable-over-current;
- status = "okay";
-};
-
-&usbmisc0 {
- status = "okay";
-};
-
-&usbmisc1 {
- status = "okay";
-};
-
-&usbphy0 {
- status = "okay";
-};
-
-&usbphy1 {
- status = "okay";
-};
&iomuxc {
- pinctrl_adc0_ad5: adc0ad5grp {
- fsl,pins = <
- VF610_PAD_PTC30__ADC0_SE5 0x00a1
- >;
- };
-
- pinctrl_dspi0: dspi0grp {
- fsl,pins = <
- VF610_PAD_PTB18__DSPI0_CS1 0x1182
- VF610_PAD_PTB19__DSPI0_CS0 0x1182
- VF610_PAD_PTB20__DSPI0_SIN 0x1181
- VF610_PAD_PTB21__DSPI0_SOUT 0x1182
- VF610_PAD_PTB22__DSPI0_SCK 0x1182
- >;
- };
-
- pinctrl_dspi2: dspi2grp {
- fsl,pins = <
- VF610_PAD_PTD31__DSPI2_CS1 0x1182
- VF610_PAD_PTD30__DSPI2_CS0 0x1182
- VF610_PAD_PTD29__DSPI2_SIN 0x1181
- VF610_PAD_PTD28__DSPI2_SOUT 0x1182
- VF610_PAD_PTD27__DSPI2_SCK 0x1182
- >;
- };
-
- pinctrl_esdhc1: esdhc1grp {
- fsl,pins = <
- VF610_PAD_PTA24__ESDHC1_CLK 0x31ef
- VF610_PAD_PTA25__ESDHC1_CMD 0x31ef
- VF610_PAD_PTA26__ESDHC1_DAT0 0x31ef
- VF610_PAD_PTA27__ESDHC1_DAT1 0x31ef
- VF610_PAD_PTA28__ESDHC1_DATA2 0x31ef
- VF610_PAD_PTA29__ESDHC1_DAT3 0x31ef
- VF610_PAD_PTA7__GPIO_134 0x219d
- >;
- };
-
- pinctrl_fec0: fec0grp {
- fsl,pins = <
- VF610_PAD_PTC0__ENET_RMII0_MDC 0x30d2
- VF610_PAD_PTC1__ENET_RMII0_MDIO 0x30d3
- VF610_PAD_PTC2__ENET_RMII0_CRS 0x30d1
- VF610_PAD_PTC3__ENET_RMII0_RXD1 0x30d1
- VF610_PAD_PTC4__ENET_RMII0_RXD0 0x30d1
- VF610_PAD_PTC5__ENET_RMII0_RXER 0x30d1
- VF610_PAD_PTC6__ENET_RMII0_TXD1 0x30d2
- VF610_PAD_PTC7__ENET_RMII0_TXD0 0x30d2
- VF610_PAD_PTC8__ENET_RMII0_TXEN 0x30d2
- >;
- };
-
- pinctrl_fec1: fec1grp {
- fsl,pins = <
- VF610_PAD_PTA6__RMII_CLKIN 0x30d1
- VF610_PAD_PTC9__ENET_RMII1_MDC 0x30d2
- VF610_PAD_PTC10__ENET_RMII1_MDIO 0x30d3
- VF610_PAD_PTC11__ENET_RMII1_CRS 0x30d1
- VF610_PAD_PTC12__ENET_RMII1_RXD1 0x30d1
- VF610_PAD_PTC13__ENET_RMII1_RXD0 0x30d1
- VF610_PAD_PTC14__ENET_RMII1_RXER 0x30d1
- VF610_PAD_PTC15__ENET_RMII1_TXD1 0x30d2
- VF610_PAD_PTC16__ENET_RMII1_TXD0 0x30d2
- VF610_PAD_PTC17__ENET_RMII1_TXEN 0x30d2
- >;
- };
-
pinctrl_gpio_e6185_eeprom_sel: pinctrl-gpio-e6185-eeprom-spi0 {
fsl,pins = <
VF610_PAD_PTE27__GPIO_132 0x33e2
@@ -629,39 +408,6 @@
>;
};
- pinctrl_i2c_mux_reset: pinctrl-i2c-mux-reset {
- fsl,pins = <
- VF610_PAD_PTE14__GPIO_119 0x31c2
- >;
- };
-
- pinctrl_i2c0: i2c0grp {
- fsl,pins = <
- VF610_PAD_PTB14__I2C0_SCL 0x37ff
- VF610_PAD_PTB15__I2C0_SDA 0x37ff
- >;
- };
-
- pinctrl_i2c1: i2c1grp {
- fsl,pins = <
- VF610_PAD_PTB16__I2C1_SCL 0x37ff
- VF610_PAD_PTB17__I2C1_SDA 0x37ff
- >;
- };
-
- pinctrl_i2c2: i2c2grp {
- fsl,pins = <
- VF610_PAD_PTA22__I2C2_SCL 0x37ff
- VF610_PAD_PTA23__I2C2_SDA 0x37ff
- >;
- };
-
- pinctrl_leds_debug: pinctrl-leds-debug {
- fsl,pins = <
- VF610_PAD_PTD20__GPIO_74 0x31c2
- >;
- };
-
pinctrl_mdio_mux: pinctrl-mdio-mux {
fsl,pins = <
VF610_PAD_PTA18__GPIO_8 0x31c2
@@ -676,48 +422,4 @@
VF610_PAD_PTB28__GPIO_98 0x219d
>;
};
-
- pinctrl_qspi0: qspi0grp {
- fsl,pins = <
- VF610_PAD_PTD7__QSPI0_B_QSCK 0x31c3
- VF610_PAD_PTD8__QSPI0_B_CS0 0x31ff
- VF610_PAD_PTD9__QSPI0_B_DATA3 0x31c3
- VF610_PAD_PTD10__QSPI0_B_DATA2 0x31c3
- VF610_PAD_PTD11__QSPI0_B_DATA1 0x31c3
- VF610_PAD_PTD12__QSPI0_B_DATA0 0x31c3
- >;
- };
-
- pinctrl_uart0: uart0grp {
- fsl,pins = <
- VF610_PAD_PTB10__UART0_TX 0x21a2
- VF610_PAD_PTB11__UART0_RX 0x21a1
- >;
- };
-
- pinctrl_uart1: uart1grp {
- fsl,pins = <
- VF610_PAD_PTB23__UART1_TX 0x21a2
- VF610_PAD_PTB24__UART1_RX 0x21a1
- >;
- };
-
- pinctrl_uart2: uart2grp {
- fsl,pins = <
- VF610_PAD_PTD0__UART2_TX 0x21a2
- VF610_PAD_PTD1__UART2_RX 0x21a1
- >;
- };
-
- pinctrl_usb_vbus: pinctrl-usb-vbus {
- fsl,pins = <
- VF610_PAD_PTA16__GPIO_6 0x31c2
- >;
- };
-
- pinctrl_usb0_host: usb0-host-grp {
- fsl,pins = <
- VF610_PAD_PTD6__GPIO_85 0x0062
- >;
- };
};
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
new file mode 100644
index 0000000..ff17001
--- /dev/null
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -0,0 +1,394 @@
+/*
+ * Copyright (C) 2015, 2016 Zodiac Inflight Innovations
+ *
+ * Based on an original 'vf610-twr.dts' which is Copyright 2015,
+ * Freescale Semiconductor, Inc.
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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 "vf610-zii-dev.dtsi"
+
+/ {
+ model = "ZII VF610 Development Board, Rev C";
+ compatible = "zii,vf610dev-c", "zii,vf610dev", "fsl,vf610";
+
+ mdio-mux {
+ compatible = "mdio-mux-gpio";
+ pinctrl-0 = <&pinctrl_mdio_mux>;
+ pinctrl-names = "default";
+ gpios = <&gpio0 8 GPIO_ACTIVE_HIGH
+ &gpio0 9 GPIO_ACTIVE_HIGH
+ &gpio0 25 GPIO_ACTIVE_HIGH>;
+ mdio-parent-bus = <&mdio1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio_mux_1: mdio at 1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch0: switch0 at 0 {
+ compatible = "marvell,mv88e6190";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ dsa,member = <0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&fec1>;
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port at 2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port at 3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+ port at 4 {
+ reg = <4>;
+ label = "lan4";
+ };
+
+ switch0port10: port at 10 {
+ reg = <10>;
+ label = "dsa";
+ phy-mode = "xgmii";
+ link = <&switch1port10>;
+ };
+ };
+ };
+ };
+
+ mdio_mux_2: mdio at 2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch1: switch1 at 0 {
+ compatible = "marvell,mv88e6190";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ dsa,member = <0 1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 1 {
+ reg = <1>;
+ label = "lan5";
+ };
+
+ port at 2 {
+ reg = <2>;
+ label = "lan6";
+ };
+
+ port at 3 {
+ reg = <3>;
+ label = "lan7";
+ };
+
+ port at 4 {
+ reg = <4>;
+ label = "lan8";
+ };
+
+
+ switch1port10: port at 10 {
+ reg = <10>;
+ label = "dsa";
+ phy-mode = "xgmii";
+ link = <&switch0port10>;
+ };
+ };
+ };
+ };
+
+ mdio_mux_4: mdio at 4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&dspi0 {
+ bus-num = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dspi0>;
+ status = "okay";
+ spi-num-chipselects = <2>;
+
+ m25p128 at 0 {
+ compatible = "m25p128", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+};
+
+&i2c0 {
+ /*
+ * U712
+ *
+ * Exposed signals:
+ * P1 - WE2_CMD
+ * P2 - WE2_CLK
+ */
+ gpio5: pca9557 at 18 {
+ compatible = "nxp,pca9557";
+ reg = <0x18>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ /*
+ * U121
+ *
+ * Exposed signals:
+ * I/O0 - ENET_SWR_EN
+ * I/O1 - ESW1_RESETn
+ * I/O2 - ARINC_RESET
+ * I/O3 - DD1_IO_RESET
+ * I/O4 - ESW2_RESETn
+ * I/O5 - ESW3_RESETn
+ * I/O6 - ESW4_RESETn
+ * I/O8 - TP909
+ * I/O9 - FEM_SEL
+ * I/O10 - WIFI_RESETn
+ * I/O11 - PHY_RSTn
+ * I/O12 - OPT1_SD
+ * I/O13 - OPT2_SD
+ * I/O14 - OPT1_TX_DIS
+ * I/O15 - OPT2_TX_DIS
+ */
+ gpio6: sx1503 at 20 {
+ compatible = "semtech,sx1503q";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sx1503_20>;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ gpio-controller;
+ interrupt-controller;
+
+ enet_swr_en {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "enet-swr-en";
+ };
+ };
+
+ /*
+ * U715
+ *
+ * Exposed signals:
+ * IO0 - WE1_CLK
+ * IO1 - WE1_CMD
+ */
+ gpio7: pca9554 at 22 {
+ compatible = "nxp,pca9554";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ };
+};
+
+&i2c1 {
+ at24mac602 at 00 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ read-only;
+ };
+};
+
+&i2c2 {
+ tca9548 at 70 {
+ compatible = "nxp,pca9548";
+ pinctrl-0 = <&pinctrl_i2c_mux_reset>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
+
+ i2c at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ i2c at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ sfp2: at24c04 at 50 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ };
+ };
+
+ i2c at 2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ sfp3: at24c04 at 50 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ };
+ };
+
+ i2c at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&gpio0 {
+ eth0_intrp {
+ gpio-hog;
+ gpios = <23 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "sx1503-irq";
+ };
+};
+
+&gpio3 {
+ eth0_intrp {
+ gpio-hog;
+ gpios = <2 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "eth0-intrp";
+ };
+};
+
+&fec0 {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 0 {
+ compatible = "ethernet-phy-id0022.1550", "ethernet-phy-ieee802.3-c22";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec0_phy_int>;
+
+ interrupt-parent = <&gpio3>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ reg = <0>;
+ };
+ };
+};
+
+&iomuxc {
+ pinctr_atzb_rf_233: pinctrl-atzb-rf-233 {
+ fsl,pins = <
+ VF610_PAD_PTB2__GPIO_24 0x31c2
+ VF610_PAD_PTE27__GPIO_132 0x33e2
+ >;
+ };
+
+
+ pinctrl_sx1503_20: pinctrl-sx1503-20 {
+ fsl,pins = <
+ VF610_PAD_PTB1__GPIO_23 0x219d
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ VF610_PAD_PTA20__UART3_TX 0x21a2
+ VF610_PAD_PTA21__UART3_RX 0x21a1
+ >;
+ };
+
+ pinctrl_mdio_mux: pinctrl-mdio-mux {
+ fsl,pins = <
+ VF610_PAD_PTA18__GPIO_8 0x31c2
+ VF610_PAD_PTA19__GPIO_9 0x31c2
+ VF610_PAD_PTB3__GPIO_25 0x31c2
+ >;
+ };
+
+ pinctrl_fec0_phy_int: pinctrl-fec0-phy-int {
+ fsl,pins = <
+ VF610_PAD_PTB28__GPIO_98 0x2181
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi b/arch/arm/boot/dts/vf610-zii-dev.dtsi
new file mode 100644
index 0000000..9f5e2e7
--- /dev/null
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -0,0 +1,383 @@
+/*
+ * Copyright (C) 2015, 2016 Zodiac Inflight Innovations
+ *
+ * Based on an original 'vf610-twr.dts' which is Copyright 2015,
+ * Freescale Semiconductor, Inc.
+ *
+ * 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
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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
+n * 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.
+ */
+
+#include "vf610.dtsi"
+
+/ {
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x80000000 0x20000000>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&pinctrl_leds_debug>;
+ pinctrl-names = "default";
+
+ debug {
+ label = "zii:green:debug1";
+ gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ reg_vcc_3v3_mcu: regulator-vcc-3v3-mcu {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_3v3_mcu";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ usb0_vbus: regulator-usb0-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-0 = <&pinctrl_usb_vbus>;
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = <&gpio0 6 0>;
+ };
+};
+
+&adc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc0_ad5>;
+ vref-supply = <®_vcc_3v3_mcu>;
+ status = "okay";
+};
+
+&edma0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_esdhc1>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&fec0 {
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec0>;
+ status = "okay";
+};
+
+&fec1 {
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ status = "okay";
+
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+
+ mdio1: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+ };
+};
+
+&i2c0 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c0>;
+ pinctrl-1 = <&pinctrl_i2c0_gpio>;
+ scl-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ sda-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+
+ lm75 at 48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+
+ at24c04 at 50 {
+ compatible = "atmel,24c04";
+ reg = <0x50>;
+ };
+
+ at24c04 at 52 {
+ compatible = "atmel,24c04";
+ reg = <0x52>;
+ };
+
+ ds1682 at 6b {
+ compatible = "dallas,ds1682";
+ reg = <0x6b>;
+ };
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&usbdev0 {
+ disable-over-current;
+ vbus-supply = <&usb0_vbus>;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbh1 {
+ disable-over-current;
+ status = "okay";
+};
+
+&usbmisc0 {
+ status = "okay";
+};
+
+&usbmisc1 {
+ status = "okay";
+};
+
+&usbphy0 {
+ status = "okay";
+};
+
+&usbphy1 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_adc0_ad5: adc0ad5grp {
+ fsl,pins = <
+ VF610_PAD_PTC30__ADC0_SE5 0x00a1
+ >;
+ };
+
+ pinctrl_dspi0: dspi0grp {
+ fsl,pins = <
+ VF610_PAD_PTB18__DSPI0_CS1 0x1182
+ VF610_PAD_PTB19__DSPI0_CS0 0x1182
+ VF610_PAD_PTB20__DSPI0_SIN 0x1181
+ VF610_PAD_PTB21__DSPI0_SOUT 0x1182
+ VF610_PAD_PTB22__DSPI0_SCK 0x1182
+ >;
+ };
+
+ pinctrl_dspi2: dspi2grp {
+ fsl,pins = <
+ VF610_PAD_PTD31__DSPI2_CS1 0x1182
+ VF610_PAD_PTD30__DSPI2_CS0 0x1182
+ VF610_PAD_PTD29__DSPI2_SIN 0x1181
+ VF610_PAD_PTD28__DSPI2_SOUT 0x1182
+ VF610_PAD_PTD27__DSPI2_SCK 0x1182
+ >;
+ };
+
+ pinctrl_esdhc1: esdhc1grp {
+ fsl,pins = <
+ VF610_PAD_PTA24__ESDHC1_CLK 0x31ef
+ VF610_PAD_PTA25__ESDHC1_CMD 0x31ef
+ VF610_PAD_PTA26__ESDHC1_DAT0 0x31ef
+ VF610_PAD_PTA27__ESDHC1_DAT1 0x31ef
+ VF610_PAD_PTA28__ESDHC1_DATA2 0x31ef
+ VF610_PAD_PTA29__ESDHC1_DAT3 0x31ef
+ VF610_PAD_PTA7__GPIO_134 0x219d
+ >;
+ };
+
+ pinctrl_fec0: fec0grp {
+ fsl,pins = <
+ VF610_PAD_PTC0__ENET_RMII0_MDC 0x30d2
+ VF610_PAD_PTC1__ENET_RMII0_MDIO 0x30d3
+ VF610_PAD_PTC2__ENET_RMII0_CRS 0x30d1
+ VF610_PAD_PTC3__ENET_RMII0_RXD1 0x30d1
+ VF610_PAD_PTC4__ENET_RMII0_RXD0 0x30d1
+ VF610_PAD_PTC5__ENET_RMII0_RXER 0x30d1
+ VF610_PAD_PTC6__ENET_RMII0_TXD1 0x30d2
+ VF610_PAD_PTC7__ENET_RMII0_TXD0 0x30d2
+ VF610_PAD_PTC8__ENET_RMII0_TXEN 0x30d2
+ >;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ VF610_PAD_PTA6__RMII_CLKIN 0x30d1
+ VF610_PAD_PTC9__ENET_RMII1_MDC 0x30d2
+ VF610_PAD_PTC10__ENET_RMII1_MDIO 0x30d3
+ VF610_PAD_PTC11__ENET_RMII1_CRS 0x30d1
+ VF610_PAD_PTC12__ENET_RMII1_RXD1 0x30d1
+ VF610_PAD_PTC13__ENET_RMII1_RXD0 0x30d1
+ VF610_PAD_PTC14__ENET_RMII1_RXER 0x30d1
+ VF610_PAD_PTC15__ENET_RMII1_TXD1 0x30d2
+ VF610_PAD_PTC16__ENET_RMII1_TXD0 0x30d2
+ VF610_PAD_PTC17__ENET_RMII1_TXEN 0x30d2
+ >;
+ };
+
+ pinctrl_gpio_spi0: pinctrl-gpio-spi0 {
+ fsl,pins = <
+ VF610_PAD_PTB22__GPIO_44 0x33e2
+ VF610_PAD_PTB21__GPIO_43 0x33e2
+ VF610_PAD_PTB20__GPIO_42 0x33e1
+ VF610_PAD_PTB19__GPIO_41 0x33e2
+ VF610_PAD_PTB18__GPIO_40 0x33e2
+ >;
+ };
+
+ pinctrl_i2c_mux_reset: pinctrl-i2c-mux-reset {
+ fsl,pins = <
+ VF610_PAD_PTE14__GPIO_119 0x31c2
+ >;
+ };
+
+ pinctrl_i2c0: i2c0grp {
+ fsl,pins = <
+ VF610_PAD_PTB14__I2C0_SCL 0x37ff
+ VF610_PAD_PTB15__I2C0_SDA 0x37ff
+ >;
+ };
+
+ pinctrl_i2c0_gpio: i2c0grp-gpio {
+ fsl,pins = <
+ VF610_PAD_PTB14__GPIO_36 0x31c2
+ VF610_PAD_PTB15__GPIO_37 0x31c2
+ >;
+ };
+
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ VF610_PAD_PTB16__I2C1_SCL 0x37ff
+ VF610_PAD_PTB17__I2C1_SDA 0x37ff
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ VF610_PAD_PTA22__I2C2_SCL 0x37ff
+ VF610_PAD_PTA23__I2C2_SDA 0x37ff
+ >;
+ };
+
+ pinctrl_leds_debug: pinctrl-leds-debug {
+ fsl,pins = <
+ VF610_PAD_PTD20__GPIO_74 0x31c2
+ >;
+ };
+
+ pinctrl_qspi0: qspi0grp {
+ fsl,pins = <
+ VF610_PAD_PTD7__QSPI0_B_QSCK 0x31c3
+ VF610_PAD_PTD8__QSPI0_B_CS0 0x31ff
+ VF610_PAD_PTD9__QSPI0_B_DATA3 0x31c3
+ VF610_PAD_PTD10__QSPI0_B_DATA2 0x31c3
+ VF610_PAD_PTD11__QSPI0_B_DATA1 0x31c3
+ VF610_PAD_PTD12__QSPI0_B_DATA0 0x31c3
+ >;
+ };
+
+ pinctrl_uart0: uart0grp {
+ fsl,pins = <
+ VF610_PAD_PTB10__UART0_TX 0x21a2
+ VF610_PAD_PTB11__UART0_RX 0x21a1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ VF610_PAD_PTB23__UART1_TX 0x21a2
+ VF610_PAD_PTB24__UART1_RX 0x21a1
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ VF610_PAD_PTD0__UART2_TX 0x21a2
+ VF610_PAD_PTD1__UART2_RX 0x21a1
+ >;
+ };
+
+ pinctrl_usb_vbus: pinctrl-usb-vbus {
+ fsl,pins = <
+ VF610_PAD_PTA16__GPIO_6 0x31c2
+ >;
+ };
+
+ pinctrl_usb0_host: usb0-host-grp {
+ fsl,pins = <
+ VF610_PAD_PTD6__GPIO_85 0x0062
+ >;
+ };
+};
--
2.5.5
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: vf610-zii-dev-rev-b: Remove 'fixed-link' from DSA ports
From: Andrey Smirnov @ 2016-12-03 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480804219-12596-1-git-send-email-andrew.smirnov@gmail.com>
Remove 'fixed-link' nodes from DSA ports since they are not needed (they
are not limiting link's speed and the ports will be configured to their
maximux speed as a default)
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
Changes since v1:
- Patch was not present in v1
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index c0fc3f2..646c90c 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -97,10 +97,6 @@
phy-mode = "rgmii-txid";
link = <&switch1port6
&switch2port9>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
};
port at 6 {
@@ -165,10 +161,6 @@
label = "dsa";
phy-mode = "rgmii-txid";
link = <&switch0port5>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
};
};
mdio {
--
2.5.5
^ permalink raw reply related
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: kbuild test robot @ 2016-12-03 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122170616.29557-1-manu@bidouilliste.com>
Hi Emmanuel,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc7 next-20161202]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Emmanuel-Vadot/ARM-dts-sunxi-Add-num-cs-for-A20-spi-nodes/20161123-034323
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-vexpress_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/sun7i-a20.dtsi:874.13-14 syntax error
>> FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 18504 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161204/e19a77b4/attachment-0001.gz>
^ permalink raw reply
* [GIT PULL 2/10] firmware: Add Tegra IVC and BPMP support
From: Olof Johansson @ 2016-12-04 5:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121082959.GE25171@ulmo.ba.sec>
On Mon, Nov 21, 2016 at 09:29:59AM +0100, Thierry Reding wrote:
> On Fri, Nov 18, 2016 at 06:31:38PM -0800, Olof Johansson wrote:
> > On Fri, Nov 18, 2016 at 05:17:11PM +0100, Thierry Reding wrote:
> > > Hi ARM SoC maintainers,
> > >
> > > The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
> > >
> > > Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
> > >
> > > are available in the git repository at:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-firmware
> > >
> > > for you to fetch changes up to b704ed8095ee91af5f3f7343bb3be23aae1cb26d:
> > >
> > > dt-bindings: firmware: Allow child nodes inside the Tegra BPMP (2016-11-18 14:33:44 +0100)
> > >
> > > Thanks,
> > > Thierry
> > >
> > > ----------------------------------------------------------------
> > > firmware: Add Tegra IVC and BPMP support
> > >
> > > IVC is an inter-processor communication protocol that uses shared memory
> > > to exchange data between processors. The BPMP driver makes use of this
> > > to communicate with the Boot and Power Management Processor (BPMP) and
> > > uses an additional hardware synchronization primitive from the HSP block
> > > to signal availability of new data (doorbell).
> > >
> > > Firmware running on the BPMP implements a number of services such as the
> > > control of clocks and resets within the system, or the ability to ungate
> > > or gate power partitions.
> > >
> > > ----------------------------------------------------------------
> > > Dan Carpenter (1):
> > > mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
> > >
> > > Joseph Lo (3):
> > > soc/tegra: Add Tegra186 support
> > > dt-bindings: mailbox: Add Tegra HSP binding
> > > dt-bindings: firmware: Add bindings for Tegra BPMP
> > >
> > > Stephen Warren (2):
> > > dt-bindings: Add power domains to Tegra BPMP firmware
> > > dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
> > >
> > > Thierry Reding (5):
> > > Merge branch 'for-4.10/soc' into for-4.10/mailbox
> > > mailbox: Add Tegra HSP driver
> > > Merge branch 'for-4.10/mailbox' into for-4.10/firmware
> > > firmware: tegra: Add IVC library
> > > firmware: tegra: Add BPMP support
> >
> > Hi,
> >
> > Again the format of the pull request here is a little confusing, since it's
> > a cumulative shotlog and diffstat, while you already sent the bulk of this
> > as part of the driver branch (1/10). It'd have been better to use that branch
> > as the base when you generate the pull request since that's the delta we see
> > when we merge it in.
>
> In the past there had been occasions where it hadn't been clear what a
> given branch was going to pull in as additional dependencies, so adding
> the complete shortlog seemed like a good way to document this in a more
> explicit way.
>
> If you prefer working things out yourself I can tweak the scripts to
> generate the pull requests on top of their respective dependencies.
It's really about the order we'll merge the patches and the diffstat that
git merge will generate and display (which is the one I usually verify
against).
So being clear is definitely useful, but doing the diffstat on the incremental
changes is still preferred.
> > Also, I can't seem to find the key you use to sign these tags with, it isn't
> > uploaded on pgp.mit.edu. Can you remedy that please, and get it signed as
> > needed?
>
> Works for me:
>
> http://pgp.mit.edu/pks/lookup?op=get&search=0xDD23ACD77F3EB3A1
Odd, I searched for it and didn't find it. But yeah, it's there.
-Olof
^ permalink raw reply
* [GIT PULL 9/10] arm64: tegra: Device tree changes for v4.10-rc1
From: Olof Johansson @ 2016-12-04 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121082210.GD25171@ulmo.ba.sec>
On Mon, Nov 21, 2016 at 09:22:10AM +0100, Thierry Reding wrote:
> On Fri, Nov 18, 2016 at 06:40:21PM -0800, Olof Johansson wrote:
> > On Fri, Nov 18, 2016 at 05:17:18PM +0100, Thierry Reding wrote:
> > > Hi ARM SoC maintainers,
> > >
> > > The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
> > >
> > > Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
> > >
> > > are available in the git repository at:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.10-arm64-dt
> > >
> > > for you to fetch changes up to cc13b4fa4ac780cec6c21b64a39ab2950e95e8f6:
> > >
> > > arm64: tegra: Add NVIDIA P2771 board support (2016-11-18 14:35:53 +0100)
> > >
> > > Thanks,
> > > Thierry
> > >
> > > ----------------------------------------------------------------
> > > arm64: tegra: Device tree changes for v4.10-rc1
> > >
> > > This adds initial support for Tegra186, the P3310 processor module as
> > > well as the P2771 development board. Not much is functional, but there
> > > is enough to boot to an initial ramdisk with debug serial output.
> > >
> > > ----------------------------------------------------------------
> > > Dan Carpenter (1):
> > > mailbox: tegra-hsp: Use after free in tegra_hsp_remove_doorbells()
> > >
> > > Joseph Lo (6):
> > > soc/tegra: Add Tegra186 support
> > > dt-bindings: mailbox: Add Tegra HSP binding
> > > dt-bindings: firmware: Add bindings for Tegra BPMP
> > > arm64: tegra: Add Tegra186 support
> > > arm64: tegra: Add NVIDIA P3310 processor module support
> > > arm64: tegra: Add NVIDIA P2771 board support
> > >
> > > Stephen Warren (2):
> > > dt-bindings: Add power domains to Tegra BPMP firmware
> > > dt-bindings: firmware: Allow child nodes inside the Tegra BPMP
> > >
> > > Thierry Reding (12):
> > > Merge branch 'for-4.10/soc' into for-4.10/mailbox
> > > mailbox: Add Tegra HSP driver
> > > Merge branch 'for-4.10/mailbox' into for-4.10/firmware
> > > firmware: tegra: Add IVC library
> > > firmware: tegra: Add BPMP support
> > > Merge branch 'for-4.10/firmware' into for-4.10/arm64/dt
> > > arm64: tegra: Add CPU nodes for Tegra186
> > > arm64: tegra: Add serial ports on Tegra186
> > > arm64: tegra: Add I2C controllers on Tegra186
> > > arm64: tegra: Add SDHCI controllers on Tegra186
> > > arm64: tegra: Add GPIO controllers on Tegra186
> > > arm64: tegra: Enable PSCI on P3310
> >
> > The drivers->dt dependency here is annoying. Any chance you can respin without
> > it?
> >
> > We've been encouraging people to consider using numerical clock/gpio/reset
> > numbers on initial submission to avoid these dependencies on dt-bindings
> > includes, and then follow up with a move to the symbolic names between -rc1 and
> > -rc2. Mind doing the same here?
>
> Yes, I can do that. Would it be acceptable to have a dt-bindings->dt
> dependency? Stephen's already done a good job of avoiding this kind of
> dependency by getting the bindings, and hence dt-bindings headers,
> merged ahead of Linux kernel support because he had already gotten the
> bindings reviewed and finalized during his work on U-Boot.
>
> I've been told in the past that it's not necessary to strictly split DT
> bindings patches from driver patches, but I suppose if a dt-bindings->dt
> is acceptable, then splitting things up more strictly would actually be
> the preferable solution here because it also avoids the slight churn of
> converting to symbolic values later on.
Sorry, haven't been looking at this older for a while so this reply is
high-latency.
If you want to do a separate dt-bindings branch that includes the headers and
is present in both the dt and drivers branch, that'd work. If the changes are
trivial though, and just contains a few clocks, I think we should just have
them opencoded on the original merge, and then move over once the include files
have gone in. I'd be willing to merge such conversions between -rc1 and -rc2.
That's in particular the case when there's an external driver tree/maintainer,
since it avoids the three-way handshake, etc.
-Olof
^ 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