* [PATCH 2/4] dt-bindings: mfd: Remove TPS65217 interrupts
From: Lee Jones @ 2017-01-04 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209062833.5768-3-woogyom.kim@gmail.com>
On Fri, 09 Dec 2016, Milo Kim wrote:
> Interrupt numbers are from the datasheet, so no need to keep them in
> the ABI. Use the number in the DT file.
>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> ---
> arch/arm/boot/dts/am335x-bone-common.dtsi | 8 +++-----
> include/dt-bindings/mfd/tps65217.h | 26 --------------------------
> 2 files changed, 3 insertions(+), 31 deletions(-)
> delete mode 100644 include/dt-bindings/mfd/tps65217.h
Acked-by: Lee Jones <lee.jones@linaro.org>
I'm happy for this to go in via your respective ARM tree.
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 14b6269..3e32dd1 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -6,8 +6,6 @@
> * published by the Free Software Foundation.
> */
>
> -#include <dt-bindings/mfd/tps65217.h>
> -
> / {
> cpus {
> cpu at 0 {
> @@ -319,13 +317,13 @@
> ti,pmic-shutdown-controller;
>
> charger {
> - interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
> - interrupt-names = "AC", "USB";
> + interrupts = <0>, <1>;
> + interrupt-names = "USB", "AC";
> status = "okay";
> };
>
> pwrbutton {
> - interrupts = <TPS65217_IRQ_PB>;
> + interrupts = <2>;
> status = "okay";
> };
>
> diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
> deleted file mode 100644
> index cafb9e6..0000000
> --- a/include/dt-bindings/mfd/tps65217.h
> +++ /dev/null
> @@ -1,26 +0,0 @@
> -/*
> - * This header provides macros for TI TPS65217 DT bindings.
> - *
> - * Copyright (C) 2016 Texas Instruments
> - *
> - * 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.
> - *
> - * This program 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.
> - *
> - * You should have received a copy of the GNU General Public License along with
> - * this program. If not, see <http://www.gnu.org/licenses/>.
> - */
> -
> -#ifndef __DT_BINDINGS_TPS65217_H__
> -#define __DT_BINDINGS_TPS65217_H__
> -
> -#define TPS65217_IRQ_USB 0
> -#define TPS65217_IRQ_AC 1
> -#define TPS65217_IRQ_PB 2
> -
> -#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [RFC PATCH 01/10] arm64: cpufeature: allow for version discrepancy in PMU implementations
From: Mark Rutland @ 2017-01-04 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483467027-14547-2-git-send-email-will.deacon@arm.com>
On Tue, Jan 03, 2017 at 06:10:18PM +0000, Will Deacon wrote:
> Perf already supports multiple PMU instances for heterogeneous systems,
> so there's no need to be strict in the cpufeature checking, particularly
> as the PMU extension is optional in the architecture.
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
There are remaining issues with PMU support exposed to KVM guests in
hetereogeneous systems, but I think that's a larger issue with KVM and
heterogeneous CPUs (and we're already aware of it), so FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/kernel/cpufeature.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index fdf8f045929f..47d0226620e8 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -184,7 +184,11 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
> ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_CTX_CMPS_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_WRPS_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_BRPS_SHIFT, 4, 0),
> - S_ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
> + /*
> + * We can instantiate multiple PMU instances with different levels
> + * of support.
> + * */
> + S_ARM64_FTR_BITS(FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
> ARM64_FTR_END,
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
From: Christoffer Dall @ 2017-01-04 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229224335.13531-2-cov@codeaurora.org>
On Thu, Dec 29, 2016 at 05:43:32PM -0500, Christopher Covington wrote:
> From: Shanker Donthineni <shankerd@codeaurora.org>
>
> On the Qualcomm Datacenter Technologies Falkor v1 CPU, memory accesses may
> allocate TLB entries using an incorrect ASID when TTBRx_EL1 is being
> updated. Changing the TTBRx_EL1[ASID] and TTBRx_EL1[BADDR] fields
> separately using a reserved ASID will ensure that there are no TLB entries
> with incorrect ASID after changing the the ASID.
When we restore guest state in KVM, we completely save and restore
TTBRx_EL1 from EL2. Would that be affected by this erratum?
Thanks,
-Christoffer
^ permalink raw reply
* [RFC v2 PATCH 1/3] ARM: NOMMU: introduce dma operations for noMMU
From: Vladimir Murzin @ 2017-01-04 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks7Kzskb-VBQQdC2cNC52kro+6g2M6n5Rw4_vz-T4xn_eg@mail.gmail.com>
Hello Benjamin,
On 02/01/17 15:26, Benjamin Gaignard wrote:
> Hello Vladimir,
>
> I have tested your patch on my setup (stm32f4: no MMU, no MPU) where
> I'm writing display driver.
> This driver use dma_alloc_wc() and dma_mmap_wc() for frame buffer
> allocation and mmapping.
>
> In dma-mapping-nommu.c you haven't implement dma_map_ops.mmap so
> obviously my driver
> doesn't work with your code.
> In current implementation it is buggy too but I submit a patch to fix
> that problem:
> http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
>
> Could it be possible for you to include mmap support in dma-mapping-nommu.c ?
>
IIRC, stm32f4 is Cortex-M4, so no cache support and it means that it uses
dma_noop_ops. I offloaded mmap to common implementation, but completely forgot
it has the same restriction as arm counterpart. Regardless, thanks for
noticing that!
It seems that I need to check that mapping is done from DMA coherent area (I'm
moving to dma-coherent and here we have dma_mmap_from_coherent for that) and
something like bellow for dma_noop_ops:
diff --git a/lib/dma-noop.c b/lib/dma-noop.c
index 3d766e7..d838b88 100644
--- a/lib/dma-noop.c
+++ b/lib/dma-noop.c
@@ -64,6 +64,25 @@ static int dma_noop_supported(struct device *dev, u64 mask)
return 1;
}
+static int dma_noop_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size)
+{
+ unsigned long user_count = vma_pages(vma);
+ unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+ unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
+ unsigned long off = vma->vm_pgoff;
+ int ret = -ENXIO;
+
+ if (off < count && user_count <= (count - off)) {
+ ret = remap_pfn_range(vma, vma->vm_start,
+ pfn + off,
+ user_count << PAGE_SHIFT,
+ vma->vm_page_prot);
+ }
+
+ return ret;
+}
+
struct dma_map_ops dma_noop_ops = {
.alloc = dma_noop_alloc,
.free = dma_noop_free,
@@ -71,6 +90,7 @@ struct dma_map_ops dma_noop_ops = {
.map_sg = dma_noop_map_sg,
.mapping_error = dma_noop_mapping_error,
.dma_supported = dma_noop_supported,
+ .mmap = dma_noop_mmap,
};
EXPORT_SYMBOL(dma_noop_ops);
I'd be glad to hear if it works for you.
Cheers
Vladimir
> Regards,
> Benjamin
^ permalink raw reply related
* [PATCH 0/2] ARM: davinci: improve the nand clock lookup
From: Bartosz Golaszewski @ 2017-01-04 10:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sekhar,
this is a follow-up to the series fixing the da850 clocks.
Instead of having a half-measure of leaving out the dev_id from the
clock lookup table, make the aemif driver capable of accessing it
over platform data.
Tested with da850-lcdk.
Bartosz Golaszewski (2):
memory: aemif: allow passing device lookup table as platform data
ARM: da850: add the nand dev_id to the clock lookup table
arch/arm/mach-davinci/da850.c | 10 +---------
arch/arm/mach-davinci/da8xx-dt.c | 12 +++++++++++-
drivers/memory/ti-aemif.c | 8 +++++++-
include/linux/platform_data/ti-aemif.h | 23 +++++++++++++++++++++++
4 files changed, 42 insertions(+), 11 deletions(-)
create mode 100644 include/linux/platform_data/ti-aemif.h
--
2.9.3
^ permalink raw reply
* [PATCH 1/2] memory: aemif: allow passing device lookup table as platform data
From: Bartosz Golaszewski @ 2017-01-04 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483526167-24209-1-git-send-email-bgolaszewski@baylibre.com>
TI aemif driver creates its own subnodes of the device tree in order
to guarantee that all child devices are probed after the AEMIF timing
parameters are configured.
Some devices (e.g. da850) use struct of_dev_auxdata for clock lookup
but nodes created from within the aemif driver can't access the lookup
table.
Create a platform data structure that holds a pointer to
of_dev_auxdata so that we can use it with of_platform_populate().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/memory/ti-aemif.c | 8 +++++++-
include/linux/platform_data/ti-aemif.h | 23 +++++++++++++++++++++++
2 files changed, 30 insertions(+), 1 deletion(-)
create mode 100644 include/linux/platform_data/ti-aemif.h
diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
index a579a0f..22c1aee 100644
--- a/drivers/memory/ti-aemif.c
+++ b/drivers/memory/ti-aemif.c
@@ -20,6 +20,7 @@
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
+#include <linux/platform_data/ti-aemif.h>
#define TA_SHIFT 2
#define RHOLD_SHIFT 4
@@ -335,6 +336,8 @@ static int aemif_probe(struct platform_device *pdev)
struct device_node *np = dev->of_node;
struct device_node *child_np;
struct aemif_device *aemif;
+ struct aemif_platform_data *pdata;
+ struct of_dev_auxdata *dev_lookup;
if (np == NULL)
return 0;
@@ -343,6 +346,9 @@ static int aemif_probe(struct platform_device *pdev)
if (!aemif)
return -ENOMEM;
+ pdata = dev_get_platdata(&pdev->dev);
+ dev_lookup = pdata ? pdata->dev_lookup : NULL;
+
platform_set_drvdata(pdev, aemif);
aemif->clk = devm_clk_get(dev, NULL);
@@ -390,7 +396,7 @@ static int aemif_probe(struct platform_device *pdev)
* parameters are set.
*/
for_each_available_child_of_node(np, child_np) {
- ret = of_platform_populate(child_np, NULL, NULL, dev);
+ ret = of_platform_populate(child_np, NULL, dev_lookup, dev);
if (ret < 0)
goto error;
}
diff --git a/include/linux/platform_data/ti-aemif.h b/include/linux/platform_data/ti-aemif.h
new file mode 100644
index 0000000..ac72e11
--- /dev/null
+++ b/include/linux/platform_data/ti-aemif.h
@@ -0,0 +1,23 @@
+/*
+ * TI DaVinci AEMIF platform glue.
+ *
+ * Copyright (C) 2017 BayLibre SAS
+ *
+ * Author:
+ * Bartosz Golaszewski <bgolaszewski@baylibre.com>
+ *
+ * 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 __TI_DAVINCI_AEMIF_DATA_H__
+#define __TI_DAVINCI_AEMIF_DATA_H__
+
+#include <linux/of_platform.h>
+
+struct aemif_platform_data {
+ struct of_dev_auxdata *dev_lookup;
+};
+
+#endif /* __TI_DAVINCI_AEMIF_DATA_H__ */
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] ARM: da850: add the nand dev_id to the clock lookup table
From: Bartosz Golaszewski @ 2017-01-04 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483526167-24209-1-git-send-email-bgolaszewski@baylibre.com>
The aemif driver can now access struct of_dev_auxdata (using platform
data).
Add the device id to the clock lookup table for the nand clock and
create a separate lookup table for aemif subnodes.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 10 +---------
arch/arm/mach-davinci/da8xx-dt.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 55f6e11..7475f02 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -557,15 +557,7 @@ static struct clk_lookup da850_clks[] = {
CLK("da830-mmc.0", NULL, &mmcsd0_clk),
CLK("da830-mmc.1", NULL, &mmcsd1_clk),
CLK("ti-aemif", NULL, &aemif_clk),
- /*
- * The only user of this clock is davinci_nand and it get's it through
- * con_id. The nand node itself is created from within the aemif
- * driver to guarantee that it's probed after the aemif timing
- * parameters are configured. of_dev_auxdata is not accessible from
- * the aemif driver and can't be passed to of_platform_populate(). For
- * that reason we're leaving the dev_id here as NULL.
- */
- CLK(NULL, "aemif", &aemif_nand_clk),
+ CLK("davinci-nand.0", "aemif", &aemif_nand_clk),
CLK("ohci-da8xx", "usb11", &usb11_clk),
CLK("musb-da8xx", "usb20", &usb20_clk),
CLK("spi_davinci.0", NULL, &spi0_clk),
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9ee44da..06205fe 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -11,6 +11,7 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/irqdomain.h>
+#include <linux/platform_data/ti-aemif.h>
#include <asm/mach/arch.h>
@@ -18,6 +19,15 @@
#include "cp_intc.h"
#include <mach/da8xx.h>
+static struct of_dev_auxdata da850_aemif_auxdata_lookup[] = {
+ OF_DEV_AUXDATA("ti,davinci-nand", 0x62000000, "davinci-nand.0", NULL),
+ {}
+};
+
+static struct aemif_platform_data aemif_data = {
+ .dev_lookup = da850_aemif_auxdata_lookup,
+};
+
static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01e28000, "i2c_davinci.2", NULL),
@@ -37,7 +47,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e20000, "davinci_emac.1",
NULL),
OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
- OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
+ OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", &aemif_data),
OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: dts: armada388-clearfog: fix SPI flash #size-cells
From: Gregory CLEMENT @ 2017-01-04 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO41M-0007xc-Id@rmk-PC.armlinux.org.uk>
Hi Russell,
On lun., janv. 02 2017, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> The SPI flash #size-cells is specified in the binding documentation to
> have value 1, but we were setting it to zero. This wasn't causing any
> problem as we do not list any partitions, but it's worth specifying
> correctly if we're going to specify it at all.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied on mvebu/dt
Thanks,
Gregory
> ---
> arch/arm/boot/dts/armada-388-clearfog.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
> index 71ce201c903e..3e7c3a6237c3 100644
> --- a/arch/arm/boot/dts/armada-388-clearfog.dts
> +++ b/arch/arm/boot/dts/armada-388-clearfog.dts
> @@ -437,7 +437,7 @@
>
> spi-flash at 0 {
> #address-cells = <1>;
> - #size-cells = <0>;
> + #size-cells = <1>;
> compatible = "w25q32", "jedec,spi-nor";
> reg = <0>; /* Chip select 0 */
> spi-max-frequency = <3000000>;
> --
> 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
* [RFC PATCH 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Peter Zijlstra @ 2017-01-04 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483467027-14547-10-git-send-email-will.deacon@arm.com>
On Tue, Jan 03, 2017 at 06:10:26PM +0000, Will Deacon wrote:
> The ARMv8.2 architecture introduces the Statistical Profiling Extension
> (SPE). SPE provides a way to configure and collect profiling samples
> from the CPU in the form of a trace buffer, which can be mapped directly
> into userspace using the perf AUX buffer infrastructure.
>
> This patch adds support for SPE in the form of a new perf driver.
>
Can you give a little high level overview of what exactly SPE is?
^ permalink raw reply
* [PATCH v3] ARM: dts: turris-omnia: add support for ethernet switch
From: Andreas Färber @ 2017-01-04 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103193501.4827-1-uwe@kleine-koenig.org>
Hi Uwe,
Am 03.01.2017 um 20:35 schrieb Uwe Kleine-K?nig:
> The Turris Omnia features a Marvell MV88E6176 ethernet switch. Add it to
> the dts.
>
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
It's still not working for me on next-20170104 with this v3.
Are there any other patches needed?
Should all ports LAN0-LAN4 work with the commented-out second cpu node?
I've been using the WAN port (eth2) just fine. (=eth1 in OpenWrt)
With this patch, eth0 and eth1 are shown as UP by default. If however I
enslave eth0 and eth1 in a br-lan bridge, as seen under OpenWrt for
eth0+eth2, then eth1 is DOWN while eth0 remains UP, and br-lan remains
DOWN. Same issue if I drop eth0 from the bridge - after a reboot eth1 is
UP but br-lan is still DOWN.
I had to manually enable CONFIG_BRIDGE, so maybe I'm missing more kernel
options? Or did you simply not try using a bridge?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [RFC PATCH 02/10] arm64: cpufeature: Don't enforce system-wide SPE capability
From: Mark Rutland @ 2017-01-04 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483467027-14547-3-git-send-email-will.deacon@arm.com>
On Tue, Jan 03, 2017 at 06:10:19PM +0000, Will Deacon wrote:
> The statistical profiling extension (SPE) is an optional feature of
> ARMv8.1 and is unlikely to be supported by all of the CPUs in a
> heterogeneous system.
>
> This patch updates the cpufeature checks so that such systems are not
> tainted as unsupported.
>
> Reviewed-by: Suzuki Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
I couldn't find this in the ARMV8.1 supplement, but it is in the SPE
spec. FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/kernel/cpufeature.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 98ae03f8eedd..e156e7793a65 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -190,6 +190,7 @@
> #define ID_AA64MMFR2_CNP_SHIFT 0
>
> /* id_aa64dfr0 */
> +#define ID_AA64DFR0_PMSVER_SHIFT 32
> #define ID_AA64DFR0_CTX_CMPS_SHIFT 28
> #define ID_AA64DFR0_WRPS_SHIFT 20
> #define ID_AA64DFR0_BRPS_SHIFT 12
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 47d0226620e8..c18eb78d3a00 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -180,7 +180,8 @@ static const struct arm64_ftr_bits ftr_id_mmfr0[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
> - ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 32, 32, 0),
> + ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 36, 28, 0),
As a heads-up, this line will disappear with Suzuki's cpufeature updates
series, so you may spot a clash later on.
Thanks,
Mark.
> + ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64DFR0_PMSVER_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_CTX_CMPS_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_WRPS_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_BRPS_SHIFT, 4, 0),
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH] rtc: armada38x: add __ro_after_init to armada38x_rtc_ops
From: Julia Lawall @ 2017-01-04 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103215421.GN14217@n2100.armlinux.org.uk>
On Tue, 3 Jan 2017, Russell King - ARM Linux wrote:
> On Tue, Jan 03, 2017 at 09:31:18PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 03, 2017 at 01:18:29PM -0800, Kees Cook wrote:
> > > On Mon, Jan 2, 2017 at 6:06 AM, Russell King - ARM Linux
> > > <linux@armlinux.org.uk> wrote:
> > > > On Mon, Dec 26, 2016 at 05:01:02PM +0530, Bhumika Goyal wrote:
> > > >> The object armada38x_rtc_ops of type rtc_class_ops structure is not
> > > >> modified after getting initialized by armada38x_rtc_probe. Apart from
> > > >> getting referenced in init it is also passed as an argument to the function
> > > >> devm_rtc_device_register but this argument is of type const struct
> > > >> rtc_class_ops *. Therefore add __ro_after_init to its declaration.
> > > >
> > > > What I'd prefer here is for the structure to be duplicated, with one
> > > > copy having the alarm methods and one which does not. Both can then
> > > > be made "const" (so placed into the read-only section at link time)
> > > > and the probe function select between the two.
> > > >
> > > > I think that's a cleaner and better solution, even though it's
> > > > slightly larger.
> > > >
> > > > I'm not a fan of __ro_after_init being used where other solutions are
> > > > possible.
> > >
> > > Can the pointer that points to the struct rtc_class_ops be made ro_after_init?
> >
> > It's passed into the RTC core code, and probably stored in some dynamically
> > allocated object, so probably no. It's the same class of problem as every
> > file_operations pointer in the kernel, or the thousand other operations
> > structure pointers that a running kernel has.
I'm not sure to understand the question and the response. A quick check
with grep suggests that most rtc_class_ops pointers are already const.
There seem to be just some instances in specific drivers that are not.
julia
>
> For the elimination of doubt, this is what I meant in my original email.
> As you can see, there's nothing to be marked as __ro_after_init anymore.
>
> drivers/rtc/rtc-armada38x.c | 24 +++++++++++++++++-------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c
> index 9a3f2a6f512e..a4166ccfce36 100644
> --- a/drivers/rtc/rtc-armada38x.c
> +++ b/drivers/rtc/rtc-armada38x.c
> @@ -202,7 +202,7 @@ static irqreturn_t armada38x_rtc_alarm_irq(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> -static struct rtc_class_ops armada38x_rtc_ops = {
> +static const struct rtc_class_ops armada38x_rtc_ops = {
> .read_time = armada38x_rtc_read_time,
> .set_time = armada38x_rtc_set_time,
> .read_alarm = armada38x_rtc_read_alarm,
> @@ -210,8 +210,15 @@ static struct rtc_class_ops armada38x_rtc_ops = {
> .alarm_irq_enable = armada38x_rtc_alarm_irq_enable,
> };
>
> +static const struct rtc_class_ops armada38x_rtc_ops_noirq = {
> + .read_time = armada38x_rtc_read_time,
> + .set_time = armada38x_rtc_set_time,
> + .read_alarm = armada38x_rtc_read_alarm,
> +};
> +
> static __init int armada38x_rtc_probe(struct platform_device *pdev)
> {
> + const struct rtc_class_ops *ops;
> struct resource *res;
> struct armada38x_rtc *rtc;
> int ret;
> @@ -242,19 +249,22 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev)
> 0, pdev->name, rtc) < 0) {
> dev_warn(&pdev->dev, "Interrupt not available.\n");
> rtc->irq = -1;
> + }
> + platform_set_drvdata(pdev, rtc);
> +
> + if (rtc->irq != -1) {
> + device_init_wakeup(&pdev->dev, 1);
> + ops = &armada38x_rtc_ops;
> + } else {
> /*
> * If there is no interrupt available then we can't
> * use the alarm
> */
> - armada38x_rtc_ops.set_alarm = NULL;
> - armada38x_rtc_ops.alarm_irq_enable = NULL;
> + ops = &armada38x_rtc_ops_noirq;
> }
> - platform_set_drvdata(pdev, rtc);
> - if (rtc->irq != -1)
> - device_init_wakeup(&pdev->dev, 1);
>
> rtc->rtc_dev = devm_rtc_device_register(&pdev->dev, pdev->name,
> - &armada38x_rtc_ops, THIS_MODULE);
> + ops, THIS_MODULE);
> if (IS_ERR(rtc->rtc_dev)) {
> ret = PTR_ERR(rtc->rtc_dev);
> dev_err(&pdev->dev, "Failed to register RTC device: %d\n", ret);
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
>
^ permalink raw reply
* [PATCH v9 2/3] mfd: Kconfig: MFD_SUN4I_GPADC depends on !TOUCHSCREN_SUN4I_GPADC
From: Lee Jones @ 2017-01-04 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213143332.24988-3-quentin.schulz@free-electrons.com>
On Tue, 13 Dec 2016, Quentin Schulz wrote:
> MFD_SUN4I_GPADC and TOUCHSCREEN_SUN4I are incompatible (both are drivers
> for Allwinner SoCs' ADC). This makes sure TOUCHSCREEN_SUN4I isn't
> enabled while MFD_SUN4I_GPADC is enabled.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
>
> added in v8. I wrongly put the XOR dependance for SUN4I_GPADC and
> TOUCHSCREEN_SUN4I instead of for MFD_SUN4I_GPADC and TOUCHSCREEN_SUN4I.
>
> drivers/mfd/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Applied, thanks.
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 443ee50..e803884 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -45,6 +45,7 @@ config MFD_SUN4I_GPADC
> select MFD_CORE
> select REGMAP_MMIO
> depends on ARCH_SUNXI || COMPILE_TEST
> + depends on !TOUCHSCREEN_SUN4I
> help
> Select this to get support for Allwinner SoCs (A10, A13 and A31) ADC.
> This driver will only map the hardware interrupt and registers, you
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] rtc: armada38x: add __ro_after_init to armada38x_rtc_ops
From: Alexandre Belloni @ 2017-01-04 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1701041155380.3073@hadrien>
On 04/01/2017 at 11:57:00 +0100, Julia Lawall wrote :
>
>
> On Tue, 3 Jan 2017, Russell King - ARM Linux wrote:
>
> > On Tue, Jan 03, 2017 at 09:31:18PM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Jan 03, 2017 at 01:18:29PM -0800, Kees Cook wrote:
> > > > On Mon, Jan 2, 2017 at 6:06 AM, Russell King - ARM Linux
> > > > <linux@armlinux.org.uk> wrote:
> > > > > On Mon, Dec 26, 2016 at 05:01:02PM +0530, Bhumika Goyal wrote:
> > > > >> The object armada38x_rtc_ops of type rtc_class_ops structure is not
> > > > >> modified after getting initialized by armada38x_rtc_probe. Apart from
> > > > >> getting referenced in init it is also passed as an argument to the function
> > > > >> devm_rtc_device_register but this argument is of type const struct
> > > > >> rtc_class_ops *. Therefore add __ro_after_init to its declaration.
> > > > >
> > > > > What I'd prefer here is for the structure to be duplicated, with one
> > > > > copy having the alarm methods and one which does not. Both can then
> > > > > be made "const" (so placed into the read-only section at link time)
> > > > > and the probe function select between the two.
> > > > >
> > > > > I think that's a cleaner and better solution, even though it's
> > > > > slightly larger.
> > > > >
> > > > > I'm not a fan of __ro_after_init being used where other solutions are
> > > > > possible.
> > > >
> > > > Can the pointer that points to the struct rtc_class_ops be made ro_after_init?
> > >
> > > It's passed into the RTC core code, and probably stored in some dynamically
> > > allocated object, so probably no. It's the same class of problem as every
> > > file_operations pointer in the kernel, or the thousand other operations
> > > structure pointers that a running kernel has.
>
> I'm not sure to understand the question and the response. A quick check
> with grep suggests that most rtc_class_ops pointers are already const.
> There seem to be just some instances in specific drivers that are not.
>
The question was whether the point to the rtc_class_ops could be made
__ro_after_init. And Russell is right, it is pointed to by the ops
pointer in a struct rtc_device and that struct is dynamically allocated
in rtc_device_register().
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] mfd: mc13xxx: Set the irq type.
From: Lee Jones @ 2017-01-04 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483112613-18092-1-git-send-email-lilja.magnus@gmail.com>
On Fri, 30 Dec 2016, Magnus Lilja wrote:
> Commit 10f9edaeaa30 ("mfd: mc13xxx: Use regmap irq framework for
> interrupts") removed the passing of the IRQF_TRIGGER_HIGH flag when
> registering the interrupt.
> This commit fixes that problem by setting the IRQF_TRIGGER_HIGH flag in
> case no irq type is set via irqd framework (e.g. device tree). In the
> latter case the irq flag from irqd is used.
This looks like a hack.
Why can't you set the trigger type in Device Tree instead?
> Tested on i.MX31 PDK hardware.
>
> Fixes: 10f9edaeaa30 ("mfd: mc13xxx: Use regmap irq framework for interrupts")
> Cc: <stable@vger.kernel.org> # 3.18.x
> Cc: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
> ---
> Changes from v1 (which was part of a patch series):
> - Now uses irqd_-functions to check if irq type is defined
> - Added Fixes: and Cc: to stable kernel.
>
> drivers/mfd/mc13xxx-core.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
> index d7f54e4..e1757ea 100644
> --- a/drivers/mfd/mc13xxx-core.c
> +++ b/drivers/mfd/mc13xxx-core.c
> @@ -15,6 +15,7 @@
> #include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/mfd/core.h>
> +#include <linux/irq.h>
>
> #include "mc13xxx.h"
>
> @@ -410,6 +411,7 @@ int mc13xxx_common_init(struct device *dev)
> struct mc13xxx *mc13xxx = dev_get_drvdata(dev);
> u32 revision;
> int i, ret;
> + unsigned int flags;
>
> mc13xxx->dev = dev;
>
> @@ -440,7 +442,11 @@ int mc13xxx_common_init(struct device *dev)
> mc13xxx->irq_chip.irqs = mc13xxx->irqs;
> mc13xxx->irq_chip.num_irqs = ARRAY_SIZE(mc13xxx->irqs);
>
> - ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT,
> + flags = irqd_get_trigger_type(irq_get_irq_data(mc13xxx->irq));
> + flags = (flags == IRQ_TYPE_NONE) ? IRQF_TRIGGER_HIGH : flags;
> +
> + ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq,
> + IRQF_ONESHOT | flags,
> 0, &mc13xxx->irq_chip, &mc13xxx->irq_data);
> if (ret)
> return ret;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* arm64: virt_to_page() does not return right page for a kernel image address
From: Mark Rutland @ 2017-01-04 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHB_GuqqXqVu4i4eCZ3V_d8JbdSO6rjWpA_B0NMJsNc_Zw0Niw@mail.gmail.com>
On Wed, Jan 04, 2017 at 11:19:38AM +0530, Pratyush Anand wrote:
> Hi,
Hi,
> I noticed that on arm64 kmap_atomic() does not return correct address
> corresponding to a page located in data section. It causes crash in
> kdump kernel with v29 kdump patches. crash happens in a newly
> implemented crypto test [1], and the same test fails(even though it
> does not crash) in 1st kernel as well.
>
> Further debugging showed that the physical address returned by
> virt_to_phys(kaddr) and virt_to_phys(kmap_atomic(virt_to_page(kaddr))
> + offset_in_page(kaddr)) are not same.
As I mentioned over IRC, virt_to_phys() on a kmap*() result is wrong
anyway. A kmap() results is not guaranteed to be a linear map address,
even if that's the trivial implementation used today.
> Mark Rutland thinks(IRC :#armlinux) that _virt_to_pgoff *only* handles
> linear addresses, and not kernel image addresses. However, we have to
> ask if it should?
>From Ard's commit, the intention is clearly that it should not,
especially given the update to virt_addr_valid(). With Larua's
DEBUG_VIRTUAL updates, we can use lm_alias() to get a linear map address
before using virt_to_page().
Other than the (new) crypto test and the (not yet upstream) kdump
patches, does any code rely on virt_to_page() working for a kernel image
address? If so, and if we cannot fix those in the short term, we may
want to temporarily revert commit 9f2875912dac35d9 until those are fixed
up.
Regardless, I think that the kdump code should not rely on
virt_to_page() for a kernel image (or kmap) result.
Thanks,
Mark.
> Meanwhile, I reverted commit [2] and then everything worked fine
> *atleast* in my case. But, I am not sure if that could be the right
> and best solution.
>
> Opinion?
>
> ~Pratyush
>
> [1]
> commit d7db7a882debaffc78f91aabedee973aa1f73390
> Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> Date: Fri Oct 21 13:19:54 2016 +0100
>
> crypto: acomp - update testmgr with support for acomp
>
> [2]commit 9f2875912dac35d9272a82ea9eec9e5884b42cd2
> Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Date: Wed Mar 30 16:46:01 2016 +0200
>
> arm64: mm: restrict virt_to_page() to the linear mapping
^ permalink raw reply
* [PATCH 1/2] mfd: micon: Add Buffalo Kurobox Pro, Terastation II Pro/Live driver
From: Lee Jones @ 2017-01-04 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229000137.5553-2-f.fainelli@gmail.com>
On Wed, 28 Dec 2016, Florian Fainelli wrote:
> This driver is currently only used to reboot the devices, but the
> microcontroller hanging off UART1 on the Buffalo Kurobox Pro and
> Terastation II Pro/Live is capable of a lot more than that, which we
> will support in subsequent patches. For now, just add the reboot
> functionality to make the kernel reboot correctly.
This is not an MFD driver. You have written a UART driver.
Please relocate it to drivers/char/tty/serial.
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/mfd/Kconfig | 8 ++
> drivers/mfd/Makefile | 2 +
> drivers/mfd/micon.c | 204 ++++++++++++++++++++++++++++++++++++
> include/linux/platform_data/micon.h | 10 ++
> 4 files changed, 224 insertions(+)
> create mode 100644 drivers/mfd/micon.c
> create mode 100644 include/linux/platform_data/micon.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 4ce3b6f11830..e7df3d29351c 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -352,6 +352,14 @@ config MFD_MX25_TSADC
> i.MX25 processors. They consist of a conversion queue for general
> purpose ADC and a queue for Touchscreens.
>
> +config MFD_MICON
> + bool "Buffalo Kurobox Pro/Terastation II Pro/Live MCU interface"
> + depends on PLAT_ORION
> + help
> + Enables support for the UART1 attached micro controller on Buffalo
> + Kurobox Pro and Terastation II Pro/Live NAS devices. Used for
> + machine restart.
> +
> config MFD_HI6421_PMIC
> tristate "HiSilicon Hi6421 PMU/Codec IC"
> depends on OF
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index dda4d4f73ad7..61a226878129 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -94,6 +94,8 @@ obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
> obj-$(CONFIG_MFD_MC13XXX_SPI) += mc13xxx-spi.o
> obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
>
> +obj-$(CONFIG_MFD_MICON) += micon.o
> +
> obj-$(CONFIG_MFD_CORE) += mfd-core.o
>
> obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
> diff --git a/drivers/mfd/micon.c b/drivers/mfd/micon.c
> new file mode 100644
> index 000000000000..fe56abdc0160
> --- /dev/null
> +++ b/drivers/mfd/micon.c
> @@ -0,0 +1,204 @@
> +/*
> + * Buffalo Kurobox/Terastation Pro II specific power off method via
> + * UART1-attached microcontroller
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/io.h>
> +#include <linux/delay.h>
> +#include <linux/platform_device.h>
> +#include <linux/platform_data/micon.h>
> +#include <linux/serial_reg.h>
> +#include <linux/notifier.h>
> +#include <linux/reboot.h>
> +
> +struct micon_priv {
> + struct device *dev;
> + void __iomem *base;
> + int tclk;
> + struct notifier_block nb;
> +};
> +
> +#define UART1_REG(x) ((UART_##x) << 2)
> +
> +static int miconread(struct micon_priv *priv, unsigned char *buf, int count)
> +{
> + int i;
> + int timeout;
> +
> + for (i = 0; i < count; i++) {
> + timeout = 10;
> +
> + while (!(readl(priv->base + UART1_REG(LSR)) & UART_LSR_DR)) {
> + if (--timeout == 0)
> + break;
> + udelay(1000);
> + }
> +
> + if (timeout == 0)
> + break;
> + buf[i] = readl(priv->base + UART1_REG(RX));
> + }
> +
> + /* return read bytes */
> + return i;
> +}
> +
> +static int miconwrite(struct micon_priv *priv, const unsigned char *buf,
> + int count)
> +{
> + int i = 0;
> +
> + while (count--) {
> + while (!(readl(priv->base + UART1_REG(LSR)) & UART_LSR_THRE))
> + barrier();
> + writel(buf[i++], priv->base + UART1_REG(TX));
> + }
> +
> + return 0;
> +}
> +
> +static int miconsend(struct micon_priv *priv, const unsigned char *data,
> + int count)
> +{
> + int i;
> + unsigned char checksum = 0;
> + unsigned char recv_buf[40];
> + unsigned char send_buf[40];
> + unsigned char correct_ack[3];
> + int retry = 2;
> +
> + /* Generate checksum */
> + for (i = 0; i < count; i++)
> + checksum -= data[i];
> +
> + do {
> + /* Send data */
> + miconwrite(priv, data, count);
> +
> + /* send checksum */
> + miconwrite(priv, &checksum, 1);
> +
> + if (miconread(priv, recv_buf, sizeof(recv_buf)) <= 3) {
> + dev_err(priv->dev, ">%s: receive failed.\n", __func__);
> +
> + /* send preamble to clear the receive buffer */
> + memset(&send_buf, 0xff, sizeof(send_buf));
> + miconwrite(priv, send_buf, sizeof(send_buf));
> +
> + /* make dummy reads */
> + mdelay(100);
> + miconread(priv, recv_buf, sizeof(recv_buf));
> + } else {
> + /* Generate expected ack */
> + correct_ack[0] = 0x01;
> + correct_ack[1] = data[1];
> + correct_ack[2] = 0x00;
> +
> + /* checksum Check */
> + if ((recv_buf[0] + recv_buf[1] + recv_buf[2] +
> + recv_buf[3]) & 0xFF) {
> + dev_err(priv->dev, ">%s: Checksum Error : "
> + "Received data[%02x, %02x, %02x, %02x]"
> + "\n", __func__, recv_buf[0],
> + recv_buf[1], recv_buf[2], recv_buf[3]);
> + } else {
> + /* Check Received Data */
> + if (correct_ack[0] == recv_buf[0] &&
> + correct_ack[1] == recv_buf[1] &&
> + correct_ack[2] == recv_buf[2]) {
> + /* Interval for next command */
> + mdelay(10);
> +
> + /* Receive ACK */
> + return 0;
> + }
> + }
> + /* Received NAK or illegal Data */
> + dev_err(priv->dev, ">%s: Error : NAK or Illegal Data "
> + "Received\n", __func__);
> + }
> + } while (retry--);
> +
> + /* Interval for next command */
> + mdelay(10);
> +
> + return -1;
> +}
> +
> +static int restart_handler(struct notifier_block *this,
> + unsigned long code, void *cmd)
> +{
> + struct micon_priv *priv = container_of(this, struct micon_priv, nb);
> +
> + const unsigned char watchdogkill[] = {0x01, 0x35, 0x00};
> + const unsigned char shutdownwait[] = {0x00, 0x0c};
> + const unsigned char poweroff[] = {0x00, 0x06};
> + /* 38400 baud divisor */
> + unsigned int divisor = ((priv->tclk + (8 * 38400)) / (16 * 38400));
> +
> + if (code != SYS_DOWN && code != SYS_HALT)
> + return NOTIFY_DONE;
> +
> + dev_info(priv->dev, "%s: triggering power-off...\n", __func__);
> +
> + /* hijack uart1 and reset into sane state (38400,8n1,even parity) */
> + writel(0x83, priv->base + UART1_REG(LCR));
> + writel(divisor & 0xff, priv->base + UART1_REG(DLL));
> + writel((divisor >> 8) & 0xff, priv->base + UART1_REG(DLM));
> + writel(0x1b, priv->base + UART1_REG(LCR));
> + writel(0x00, priv->base + UART1_REG(IER));
> + writel(0x07, priv->base + UART1_REG(FCR));
> + writel(0x00, priv->base + UART1_REG(MCR));
> +
> + /* Send the commands to shutdown the Terastation Pro II */
> + miconsend(priv, watchdogkill, sizeof(watchdogkill));
> + miconsend(priv, shutdownwait, sizeof(shutdownwait));
> + miconsend(priv, poweroff, sizeof(poweroff));
> +
> + return NOTIFY_DONE;
> +}
> +
> +static int micon_probe(struct platform_device *pdev)
> +{
> + struct micon_platform_data *pdata = pdev->dev.platform_data;
> + struct micon_priv *priv;
> + struct resource *r;
> + int ret;
> +
> + if (!pdata)
> + return -ENODEV;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = &pdev->dev;
> + r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> + /* Don't request exclusive access since 8250 may also utilize this
> + * resource
> + */
> + priv->base = devm_ioremap(&pdev->dev, r->start, resource_size(r));
> + if (IS_ERR(priv->base))
> + return -ENOMEM;
> +
> + priv->tclk = pdata->tclk;
> +
> + priv->nb.notifier_call = restart_handler;
> +
> + return register_reboot_notifier(&priv->nb);
> +}
> +
> +static struct platform_driver micon_driver = {
> + .probe = micon_probe,
> + .driver = {
> + .name = MICON_NAME,
> + },
> +};
> +builtin_platform_driver(micon_driver);
> diff --git a/include/linux/platform_data/micon.h b/include/linux/platform_data/micon.h
> new file mode 100644
> index 000000000000..67dbaad5dfaa
> --- /dev/null
> +++ b/include/linux/platform_data/micon.h
> @@ -0,0 +1,10 @@
> +#ifndef __MICON_PDATA_H
> +#define __MICON_PDATA_H
> +
> +#define MICON_NAME "micon"
> +
> +struct micon_platform_data {
> + int tclk;
> +};
> +
> +#endif /* __MICON_PDATA_H */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v4 1/5] mfd: dt: Fix "indicates" typo in mfd bindings document
From: Lee Jones @ 2017-01-04 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-2-andrew@aj.id.au>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/mfd/mfd.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> index af9d6931a1a2..f1fceeda12f1 100644
> --- a/Documentation/devicetree/bindings/mfd/mfd.txt
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -19,7 +19,7 @@ Optional properties:
>
> - compatible : "simple-mfd" - this signifies that the operating system should
> consider all subnodes of the MFD device as separate devices akin to how
> - "simple-bus" inidicates when to see subnodes as children for a simple
> + "simple-bus" indicates when to see subnodes as children for a simple
> memory-mapped bus. For more complex devices, when the nexus driver has to
> probe registers to figure out what child devices exist etc, this should not
> be used. In the latter case the child devices will be determined by the
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 15/20] ARM/hw_breakpoint: Convert to hotplug state machine
From: Sebastian Andrzej Siewior @ 2017-01-04 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103093335.GA5605@leverpostej>
On 2017-01-03 09:33:36 [+0000], Mark Rutland wrote:
> Hi,
Hi,
> It looked like DBGPRSR.SPD is set unexpectedly over the default idle
> path (i.e. WFI), causing the (otherwise valid) register accesses above
> to be handled as undefined.
>
> I haven't looked at the patch in detail, but I guess that it allows idle
> to occur between reset_ctrl_regs() and arch_hw_breakpoint_init().
This could be possible. The callback is installed and the per-CPU thread
is woken up to handle it. It starts with the lowest CPU and loops for
all present CPUs. While waiting the thread to complete the callback, it
could go idle. See the for_each_present_cpu() loop in
__cpuhp_setup_state() and cpuhp_invoke_ap_callback() kicks the thread
(cpuhp_thread_fun()) and waits for its completion.
So the difference to on_each_cpu() is that the latter performs a busy
loop while waiting for function to complete on other CPUs.
> Reading DBGPRSR should clear SPD; but I'm not sure if other debug state
> is affected.
>
> Thanks,
> Mark.
Sebastian
^ permalink raw reply
* [PATCH v2 2/2] arm: perf: Mark as non-removable
From: Mark Rutland @ 2017-01-04 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2559413.O5mI12kdOo@ws-stein>
On Wed, Jan 04, 2017 at 10:19:46AM +0100, Alexander Stein wrote:
> On Thursday 22 December 2016 22:48:32, Mark Rutland wrote:
> > On Wed, Dec 21, 2016 at 04:03:40PM +0100, Alexander Stein wrote:
> > More generally, updating each and every driver in this manner seems like a
> > scattergun approach that is tiresome and error prone.
> >
> > IMO, it would be vastly better for a higher layer to enforce that we don't
> > attempt to unbind drivers where the driver does not have a remove callback,
> > as is the case here (and I suspect most over cases where
> > DEBUG_TEST_DRIVER_REMOVE is blowing up).
>
> You mean something like this?
> > diff --git a/drivers/base/driver.c b/drivers/base/driver.c
> > index 4eabfe2..3b6c1a2d 100644
> > --- a/drivers/base/driver.c
> > +++ b/drivers/base/driver.c
> > @@ -158,6 +158,9 @@ int driver_register(struct device_driver *drv)
> >
> > printk(KERN_WARNING "Driver '%s' needs updating - please use
> > "
> >
> > "bus_type methods\n", drv->name);
> >
> > + if (!drv->remove)
> > + drv->suppress_bind_attrs = true;
> > +
> >
> > other = driver_find(drv->name, drv->bus);
> > if (other) {
> >
> > printk(KERN_ERR "Error: Driver '%s' is already registered, "
Something of that sort, yes. Or have a bus-level callback so that the
bus can reject it dynamically (without having to alter the drv attrs).
> > Is there any reason that can't be enforced at the bus layer, say?
>
> I'm not sure if the change above works with remove functions set in struct
> bus_type too.
> But on the other hand this would hide errors in drivers which are actually
> removable but do not cleanup properly which DEBUG_TEST_DRIVER_REMOVE tries to
> detect.
> By setting .suppress_bind_attrs = true explicitely you state "This
> driver cannot be removed!", so the remove callback is not missing by accident.
I'm not sure I follow. If the remove callback is accidentally missing,
the driver is not "actually removable" today -- there's either no remove
code, or it's not been wired up (the latter of which will likely result
in a compiler warning about an unused function).
Aborting the remove early in those cases is much safer than forcefully
removing a driver without a remove callback.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v6 0/5] davinci: VPIF: add DT support
From: Sekhar Nori @ 2017-01-04 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57057847.C5XnZnHN9E@avalon>
+ Mauro
On Tuesday 03 January 2017 02:42 PM, Laurent Pinchart wrote:
> Hi Sekhar,
>
> On Tuesday 03 Jan 2017 14:33:00 Sekhar Nori wrote:
>> On Friday 16 December 2016 03:17 PM, Hans Verkuil wrote:
>>> On 07/12/16 19:30, Kevin Hilman wrote:
>>>> Prepare the groundwork for adding DT support for davinci VPIF drivers.
>>>> This series does some fixups/cleanups and then adds the DT binding and
>>>> DT compatible string matching for DT probing.
>>>>
>>>> The controversial part from previous versions around async subdev
>>>> parsing, and specifically hard-coding the input/output routing of
>>>> subdevs, has been left out of this series. That part can be done as a
>>>> follow-on step after agreement has been reached on the path forward.
>>>> With this version, platforms can still use the VPIF capture/display
>>>> drivers, but must provide platform_data for the subdevs and subdev
>>>> routing.
>>>>
>>>> Tested video capture to memory on da850-lcdk board using composite
>>>> input.
>>>
>>> Other than the comment for the first patch this series looks good.
>>>
>>> So once that's addressed I'll queue it up for 4.11.
>>
>> Can you provide an immutable commit (as it will reach v4.11) with with
>> this series applied? I have some platform changes to queue for v4.11
>> that depend on the driver updates.
>
> I don't think that's possible, given that Mauro rewrites all patches when
> handling pull requests to prepend [media] to the subject line and to add his
> SoB. Only Mauro can thus provide a stable branch, Hans can't.
Hi Mauro, once Hans sends you these patches, can you host these patches
on a stable branch, which I can merge into my pull request to ARM-SoC. I
have some platform updates that depend on these driver changes.
Ideally the branch has only these patches over an early v4.10-rc so I
include as little of media stuff as possible in my pull request.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v4 2/5] mfd: dt: ranges, #address-cells and #size-cells as optional properties
From: Lee Jones @ 2017-01-04 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-3-andrew@aj.id.au>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> Whilst describing a device and not a bus, simple-mfd is modelled on
> simple-bus where child nodes are iterated and registered as platform
> devices. Some complex devices, e.g. the Aspeed LPC controller, can
> benefit from address space mapping such that child nodes can use the
> regs property to describe their resource offsets within the
> multi-function device.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/mfd/mfd.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt
> index f1fceeda12f1..bcb6abb9d413 100644
> --- a/Documentation/devicetree/bindings/mfd/mfd.txt
> +++ b/Documentation/devicetree/bindings/mfd/mfd.txt
> @@ -25,6 +25,16 @@ Optional properties:
> be used. In the latter case the child devices will be determined by the
> operating system.
>
> +- ranges: Describes the address mapping relationship to the parent. Should set
> + the child's base address to 0, the physical address within parent's address
> + space, and the length of the address map.
> +
> +- #address-cells: Specifies the number of cells used to represent physical base
> + addresses. Must be present if ranges is used.
> +
> +- #size-cells: Specifies the number of cells used to represent the size of an
> + address. Must be present if ranges is used.
> +
> Example:
>
> foo at 1000 {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v4 3/5] mfd: dt: Add Aspeed Low Pin Count Controller bindings
From: Lee Jones @ 2017-01-04 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-4-andrew@aj.id.au>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Reviewed-by: Joel Stanley <joel@jms.id.au>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/mfd/aspeed-lpc.txt | 111 +++++++++++++++++++++
> 1 file changed, 111 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> new file mode 100644
> index 000000000000..a97131aba446
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -0,0 +1,111 @@
> +======================================================================
> +Device tree bindings for the Aspeed Low Pin Count (LPC) Bus Controller
> +======================================================================
> +
> +The LPC bus is a means to bridge a host CPU to a number of low-bandwidth
> +peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The
> +primary use case of the Aspeed LPC controller is as a slave on the bus
> +(typically in a Baseboard Management Controller SoC), but under certain
> +conditions it can also take the role of bus master.
> +
> +The LPC controller is represented as a multi-function device to account for the
> +mix of functionality it provides. The principle split is between the register
> +layout at the start of the I/O space which is, to quote the Aspeed datasheet,
> +"basically compatible with the [LPC registers from the] popular BMC controller
> +H8S/2168[1]", and everything else, where everything else is an eclectic
> +collection of functions with a esoteric register layout. "Everything else",
> +here labeled the "host" portion of the controller, includes, but is not limited
> +to:
> +
> +* An IPMI Block Transfer[2] Controller
> +
> +* An LPC Host Controller: Manages LPC functions such as host vs slave mode, the
> + physical properties of some LPC pins, configuration of serial IRQs, and
> + APB-to-LPC bridging amonst other functions.
> +
> +* An LPC Host Interface Controller: Manages functions exposed to the host such
> + as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART
> + management and bus snoop configuration.
> +
> +* A set of SuperIO[3] scratch registers: Enables implementation of e.g. custom
> + hardware management protocols for handover between the host and baseboard
> + management controller.
> +
> +Additionally the state of the LPC controller influences the pinmux
> +configuration, therefore the host portion of the controller is exposed as a
> +syscon as a means to arbitrate access.
> +
> +[0] http://www.intel.com/design/chipsets/industry/25128901.pdf
> +[1] https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4
> +[2] http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf
> +[3] https://en.wikipedia.org/wiki/Super_I/O
> +
> +Required properties
> +===================
> +
> +- compatible: One of:
> + "aspeed,ast2400-lpc", "simple-mfd"
> + "aspeed,ast2500-lpc", "simple-mfd"
> +
> +- reg: contains the physical address and length values of the Aspeed
> + LPC memory region.
> +
> +- #address-cells: <1>
> +- #size-cells: <1>
> +- ranges: Maps 0 to the physical address and length of the LPC memory
> + region
> +
> +Required LPC Child nodes
> +========================
> +
> +BMC Node
> +--------
> +
> +- compatible: One of:
> + "aspeed,ast2400-lpc-bmc"
> + "aspeed,ast2500-lpc-bmc"
> +
> +- reg: contains the physical address and length values of the
> + H8S/2168-compatible LPC controller memory region
> +
> +Host Node
> +---------
> +
> +- compatible: One of:
> + "aspeed,ast2400-lpc-host", "simple-mfd", "syscon"
> + "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"
> +
> +- reg: contains the address and length values of the host-related
> + register space for the Aspeed LPC controller
> +
> +- #address-cells: <1>
> +- #size-cells: <1>
> +- ranges: Maps 0 to the address and length of the host-related LPC memory
> + region
> +
> +Example:
> +
> +lpc: lpc at 1e789000 {
> + compatible = "aspeed,ast2500-lpc", "simple-mfd";
> + reg = <0x1e789000 0x1000>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x1e789000 0x1000>;
> +
> + lpc_bmc: lpc-bmc at 0 {
> + compatible = "aspeed,ast2500-lpc-bmc";
> + reg = <0x0 0x80>;
> + };
> +
> + lpc_host: lpc-host at 80 {
> + compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";
> + reg = <0x80 0x1e0>;
> + reg-io-width = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x80 0x1e0>;
> + };
> +};
> +
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v4 4/5] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
From: Lee Jones @ 2017-01-04 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-5-andrew@aj.id.au>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> on bits in both the System Control Unit and the LPC Host Controller.
>
> The Aspeed LPC Host Controller is described as a child node of the
> LPC host-range syscon device for arbitration of access by the host
> controller and pinmux drivers.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> ---
>
> Linus: I've retained your r-b tag I don't think the addition of the ast2400
> compatible string will fuss you. Please let me know if you feel this is
> inappropriate.
>
> .../devicetree/bindings/mfd/aspeed-lpc.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> index a97131aba446..514d82ced95b 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -109,3 +109,29 @@ lpc: lpc at 1e789000 {
> };
> };
>
> +Host Node Children
> +==================
> +
> +LPC Host Controller
> +-------------------
> +
> +The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
> +between the host and the baseboard management controller. The registers exist
> +in the "host" portion of the Aspeed LPC controller, which must be the parent of
> +the LPC host controller node.
> +
> +Required properties:
> +
> +- compatible: One of:
> + "aspeed,ast2400-lhc";
> + "aspeed,ast2500-lhc";
> +
> +- reg: contains offset/length values of the LHC memory regions. In the
> + AST2400 and AST2500 there are two regions.
> +
> +Example:
> +
> +lhc: lhc at 20 {
> + compatible = "aspeed,ast2500-lhc";
> + reg = <0x20 0x24 0x48 0x8>;
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v4 5/5] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
From: Lee Jones @ 2017-01-04 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-6-andrew@aj.id.au>
On Tue, 20 Dec 2016, Andrew Jeffery wrote:
> The Aspeed SoC Display Controller is presented as a syscon device to
> arbitrate access by display and pinmux drivers. Video pinmux
> configuration on fifth generation SoCs depends on bits in both the
> System Control Unit and the Display Controller.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> new file mode 100644
> index 000000000000..aea5370efd97
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> @@ -0,0 +1,17 @@
> +* Device tree bindings for Aspeed SoC Display Controller (GFX)
> +
> +The Aspeed SoC Display Controller primarily does as its name suggests, but also
> +participates in pinmux requests on the g5 SoCs. It is therefore considered a
> +syscon device.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-gfx", "syscon"
> +- reg: contains offset/length value of the GFX memory
> + region.
> +
> +Example:
> +
> +gfx: display at 1e6e6000 {
> + compatible = "aspeed,ast2500-gfx", "syscon";
> + reg = <0x1e6e6000 0x1000>;
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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