* [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
From: Auger Eric @ 2016-09-13 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1473695704.git.robin.murphy@arm.com>
Hi Robin
On 12/09/2016 18:13, Robin Murphy wrote:
> Hi all,
>
> To any more confusing fixups and crazily numbered extra patches, here's
> a quick v7 with everything rebased into the right order. The significant
> change this time is to implement iommu_fwspec properly from the start,
> which ends up being far simpler and more robust than faffing about
> introducing it somewhere 'less intrusive' to move toward core code later.
>
> New branch in the logical place:
>
> git://linux-arm.org/linux-rm iommu/generic-v7
I just tested your branch on AMD overdrive *without* updating the device
tree description according to the new syntax and I get a kernel oops.
See logs attached. Continuing my investigations ...
Best Regards
Eric
>
> Robin.
>
> Mark Rutland (1):
> Docs: dt: add PCI IOMMU map bindings
>
> Robin Murphy (21):
> of/irq: Break out msi-map lookup (again)
> iommu/of: Handle iommu-map property for PCI
> iommu: Introduce iommu_fwspec
> Docs: dt: document ARM SMMUv3 generic binding usage
> iommu/arm-smmu: Fall back to global bypass
> iommu/arm-smmu: Implement of_xlate() for SMMUv3
> iommu/arm-smmu: Support non-PCI devices with SMMUv3
> iommu/arm-smmu: Set PRIVCFG in stage 1 STEs
> iommu/arm-smmu: Handle stream IDs more dynamically
> iommu/arm-smmu: Consolidate stream map entry state
> iommu/arm-smmu: Keep track of S2CR state
> iommu/arm-smmu: Refactor mmu-masters handling
> iommu/arm-smmu: Streamline SMMU data lookups
> iommu/arm-smmu: Add a stream map entry iterator
> iommu/arm-smmu: Intelligent SMR allocation
> iommu/arm-smmu: Convert to iommu_fwspec
> Docs: dt: document ARM SMMU generic binding usage
> iommu/arm-smmu: Wire up generic configuration support
> iommu/arm-smmu: Set domain geometry
> iommu/dma: Add support for mapping MSIs
> iommu/dma: Avoid PCI host bridge windows
>
> .../devicetree/bindings/iommu/arm,smmu-v3.txt | 8 +-
> .../devicetree/bindings/iommu/arm,smmu.txt | 63 +-
> .../devicetree/bindings/pci/pci-iommu.txt | 171 ++++
> arch/arm64/mm/dma-mapping.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +-
> drivers/iommu/Kconfig | 2 +-
> drivers/iommu/arm-smmu-v3.c | 386 +++++----
> drivers/iommu/arm-smmu.c | 962 ++++++++++-----------
> drivers/iommu/dma-iommu.c | 161 +++-
> drivers/iommu/iommu.c | 56 ++
> drivers/iommu/of_iommu.c | 52 +-
> drivers/irqchip/irq-gic-v2m.c | 3 +
> drivers/irqchip/irq-gic-v3-its.c | 3 +
> drivers/of/irq.c | 78 +-
> drivers/of/of_pci.c | 102 +++
> include/linux/device.h | 3 +
> include/linux/dma-iommu.h | 12 +-
> include/linux/iommu.h | 38 +
> include/linux/of_pci.h | 10 +
> 19 files changed, 1323 insertions(+), 791 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
>
-------------- next part --------------
[ 3.185447] CPU features: detected feature: 32-bit EL0 Support
[ 3.185455] CPU: All CPU(s) started at EL2
[ 3.185475] alternatives: patching kernel code
[ 3.188549] devtmpfs: initialized
[ 3.189484] SMBIOS 3.0.0 present.
[ 3.189570] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 3.189750] pinctrl core: initialized pinctrl subsystem
[ 3.190113] NET: Registered protocol family 16
[ 3.205134] cpuidle: using governor menu
[ 3.205292] arm-smmu: deprecated "mmu-masters" DT property in use; DMA API support unavailable
[ 3.205319] arm-smmu e0600000.smmu: probing hardware configuration...
[ 3.205326] arm-smmu e0600000.smmu: SMMUv1 with:
[ 3.205334] arm-smmu e0600000.smmu: stage 2 translation
[ 3.205341] arm-smmu e0600000.smmu: non-coherent table walk
[ 3.205348] arm-smmu e0600000.smmu: (IDR0.CTTW overridden by dma-coherent property)
[ 3.205358] arm-smmu e0600000.smmu: stream matching with 32 register groups, mask 0x7fff
[ 3.205369] arm-smmu e0600000.smmu: 8 context banks (8 stage-2 only)
[ 3.205377] arm-smmu e0600000.smmu: Supported page sizes: 0x60211000
[ 3.205384] arm-smmu e0600000.smmu: Stage-2: 40-bit IPA -> 40-bit PA
[ 3.205489] arm-smmu: deprecated "mmu-masters" DT property in use; DMA API support unavailable
[ 3.205512] arm-smmu e0800000.smmu: probing hardware configuration...
[ 3.205519] arm-smmu e0800000.smmu: SMMUv1 with:
[ 3.205525] arm-smmu e0800000.smmu: stage 2 translation
[ 3.205533] arm-smmu e0800000.smmu: non-coherent table walk
[ 3.205539] arm-smmu e0800000.smmu: (IDR0.CTTW overridden by dma-coherent property)
[ 3.205550] arm-smmu e0800000.smmu: stream matching with 32 register groups, mask 0x7fff
[ 3.205560] arm-smmu e0800000.smmu: 8 context banks (8 stage-2 only)
[ 3.205567] arm-smmu e0800000.smmu: Supported page sizes: 0x60211000
[ 3.205574] arm-smmu e0800000.smmu: Stage-2: 40-bit IPA -> 40-bit PA
[ 3.205670] arm-smmu: deprecated "mmu-masters" DT property in use; DMA API support unavailable
[ 3.205692] arm-smmu e0a00000.smmu: probing hardware configuration...
[ 3.205699] arm-smmu e0a00000.smmu: SMMUv1 with:
[ 3.205705] arm-smmu e0a00000.smmu: stage 2 translation
[ 3.205712] arm-smmu e0a00000.smmu: non-coherent table walk
[ 3.205719] arm-smmu e0a00000.smmu: (IDR0.CTTW overridden by dma-coherent property)
[ 3.205729] arm-smmu e0a00000.smmu: stream matching with 32 register groups, mask 0x7fff
[ 3.205738] arm-smmu e0a00000.smmu: 8 context banks (8 stage-2 only)
[ 3.205745] arm-smmu e0a00000.smmu: Supported page sizes: 0x60211000
[ 3.205752] arm-smmu e0a00000.smmu: Stage-2: 40-bit IPA -> 40-bit PA
[ 3.205801] vdso: 2 pages (1 code @ ffff0000088c6000, 1 data @ ffff000008dd4000)
[ 3.205814] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[ 3.206098] DMA: preallocated 256 KiB pool for atomic allocations
[ 3.206186] Serial: AMBA PL011 UART driver
[ 3.207040] e1010000.serial: ttyAMA0 at MMIO 0xe1010000 (irq = 20, base_baud = 0) is a PL011 rev3
[ 3.995110] console [ttyAMA0] enabled
[ 3.999198] OF: amba_device_add() failed (-19) for /smb/gpio at e0020000
[ 4.006287] iommu: Adding device e0700000.xgmac to group 0
[ 4.027943] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 4.034596] ACPI: Interpreter disabled.
[ 4.038537] Unable to handle kernel paging request at virtual address ffffff8030010000
[ 4.046452] pgd = ffff000008f61000
[ 4.049845] [ffffff8030010000] *pgd=0000000000000000
[ 4.054807] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 4.060371] Modules linked in:
[ 4.063419] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc4-26782-g83cf8c5 #14
[ 4.070982] Hardware name: Default string Default string/Default string, BIOS WOD5527X 05/25/2015
[ 4.079846] task: ffff8003ec108000 task.stack: ffff8003ec110000
[ 4.085761] PC is at __arm_v7s_map+0x1cc/0x378
[ 4.090196] LR is at __arm_v7s_map+0xb4/0x378
[ 4.094543] pc : [<ffff000008522604>] lr : [<ffff0000085224ec>] pstate: 20000045
[ 4.101931] sp : ffff8003ec113bf0
[ 4.105236] x29: ffff8003ec113bf0 x28: 0000000000001000
[ 4.110543] x27: ffffff8030010000 x26: ffff8003eb47e518
[ 4.115850] x25: 0000000000000001 x24: ffffff8030010004
[ 4.121155] x23: 000000000000000c x22: ffff8003eb47e500
[ 4.126461] x21: 0000000000001000 x20: 0000000000000000
[ 4.131767] x19: ffffff8030010000 x18: 000000000000000e
[ 4.137072] x17: 00000000000040ff x16: 0000000000000000
[ 4.142379] x15: 000000000000008c x14: 0000000000000006
[ 4.147684] x13: 0000000000000007 x12: 0000000000000020
[ 4.152990] x11: 0000000000000003 x10: ffff000008dd6000
[ 4.158295] x9 : 0000000000000004 x8 : 0000000000000e71
[ 4.163601] x7 : ffffff8030010000 x6 : ffffff8030010000
[ 4.168907] x5 : 0000000000000002 x4 : 0000000000000000
[ 4.174212] x3 : 0000000000000001 x2 : 0000000000000001
[ 4.179518] x1 : 0000000000000e7d x0 : 0000000000000004
[ 4.184824]
[ 4.186306] Process swapper/0 (pid: 1, stack limit = 0xffff8003ec110020)
[ 4.192998] Stack: (0xffff8003ec113bf0 to 0xffff8003ec114000)
[ 4.198735] 3be0: ffff8003ec113c70 ffff0000085224ec
[ 4.206558] 3c00: 0000000000001000 0000000000000000 0000000000000000 ffff8003eb47e500
[ 4.214381] 3c20: 0000000000000014 0000000000001000 0000000000000000 ffff8003eb47e518
[ 4.222203] 3c40: ffff800030008000 0000000000001000 0000000000000000 ffff8003eb47e518
[ 4.230026] 3c60: ffff8003ec113c70 ffffff8030010000 ffff8003ec113cf0 ffff0000085227f8
[ 4.237848] 3c80: ffff8003eb47e568 0000000000001000 0000000000000000 000000000000002a
[ 4.245671] 3ca0: 0000000000000001 0000000000001000 0000000000000001 ffff8003ec113d88
[ 4.253493] 3cc0: ffff8003ec113d80 0000000000001000 0000000000000002 000000000000000f
[ 4.261315] 3ce0: ffff800030010000 ffff000008bc2520 ffff8003ec113d20 ffff000008d0036c
[ 4.269137] 3d00: ffff8003eb47e568 000000000000000c 0000000000000000 000000000000002a
[ 4.276960] 3d20: ffff8003ec113dd0 ffff00000808335c ffff000008d0019c ffff8003ec110000
[ 4.284782] 3d40: 0000000000000000 ffff000008f1c000 ffff000008cc0498 ffff000008cad0a0
[ 4.292605] 3d60: ffff000008d2ab20 ffff000008f1c000 0000000000000109 0000000000000000
[ 4.300427] 3d80: 0000000000000001 0000000001111000 0000002000000020 ffff000008e750b0
[ 4.308249] 3da0: 0000000000000000 000000003000806a 4000400000000020 00000000800b8204
[ 4.316072] 3dc0: 0000000000000000 0000000000000000 ffff8003ec113e40 ffff000008cc0d54
[ 4.323894] 3de0: ffff000008d95df0 ffff000008d2aa70 0000000000000004 ffff000008f1c000
[ 4.331717] 3e00: ffff8003ec113e00 ffff000008ef8f38 0000000000000000 0000000400000004
[ 4.339539] 3e20: ffff000008ef8ec0 0000000000000000 ffff000008cc0498 ffff000008cad0a0
[ 4.347361] 3e40: ffff8003ec113ea0 ffff0000088a7f88 ffff0000088a7f78 0000000000000000
[ 4.355183] 3e60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.363006] 3e80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.370828] 3ea0: 0000000000000000 ffff000008082e90 ffff0000088a7f78 0000000000000000
[ 4.378650] 3ec0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.386473] 3ee0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.394295] 3f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.402117] 3f20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.409940] 3f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.417762] 3f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.425584] 3f80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.433406] 3fa0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.441229] 3fc0: 0000000000000000 0000000000000005 0000000000000000 0000000000000000
[ 4.449051] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4.456873] Call trace:
[ 4.459310] Exception stack(0xffff8003ec113a20 to 0xffff8003ec113b50)
[ 4.465742] 3a20: ffffff8030010000 0001000000000000 ffff8003ec113bf0 ffff000008522604
[ 4.473565] 3a40: 0000000002088021 ffff8003eb47e518 ffff8003fff4db00 ffff8003ffe81400
[ 4.481388] 3a60: ffff000008dd5000 0208802100008001 0000000000000000 0000000000000000
[ 4.489210] 3a80: ffff8003ec113b80 ffff00000820247c 0000000000000040 0000000000000000
[ 4.497032] 3aa0: ffff8003ec110000 0000000000000003 0000000002088021 ffff000008521cbc
[ 4.504854] 3ac0: 0000000000000004 0000000000000e7d 0000000000000001 0000000000000001
[ 4.512677] 3ae0: 0000000000000000 0000000000000002 ffffff8030010000 ffffff8030010000
[ 4.520499] 3b00: 0000000000000e71 0000000000000004 ffff000008dd6000 0000000000000003
[ 4.528321] 3b20: 0000000000000020 0000000000000007 0000000000000006 000000000000008c
[ 4.536143] 3b40: 0000000000000000 00000000000040ff
[ 4.541012] [<ffff000008522604>] __arm_v7s_map+0x1cc/0x378
[ 4.546489] [<ffff0000085224ec>] __arm_v7s_map+0xb4/0x378
[ 4.551879] [<ffff0000085227f8>] arm_v7s_map+0x48/0xc4
[ 4.557010] [<ffff000008d0036c>] arm_v7s_do_selftests+0x1d0/0x4b4
[ 4.563096] [<ffff00000808335c>] do_one_initcall+0x38/0x12c
[ 4.568662] [<ffff000008cc0d54>] kernel_init_freeable+0x1a8/0x24c
[ 4.574748] [<ffff0000088a7f88>] kernel_init+0x10/0xfc
[ 4.579878] [<ffff000008082e90>] ret_from_fork+0x10/0x40
[ 4.585181] Code: aa1b03f3 8b180378 f9003fa7 710004bf (b9400266)
[ 4.591280] ---[ end trace d091d1618c2826ea ]---
[ 4.595897] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 4.595897]
[ 4.605024] SMP: stopping secondary CPUs
[ 4.608942] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 4.608942]
^ permalink raw reply
* [PATCH] coresight: tmc: fix for trace collection bug in sysFS mode
From: Venkatesh Vivekanandan @ 2016-09-13 12:20 UTC (permalink / raw)
To: linux-arm-kernel
tmc_etb_dump_hw is never called in sysFS mode to collect trace from
hardware, because drvdata->mode is set to CS_MODE_DISABLED at
tmc_disable_etf/etr_sink
static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
{
.
.
if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
tmc_etb_dump_hw(drvdata);
.
.
}
static void tmc_disable_etf_sink(struct coresight_device *csdev)
{
.
.
val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
/* Disable the TMC only if it needs to */
if (val != CS_MODE_DISABLED)
tmc_etb_disable_hw(drvdata);
.
.
}
Signed-off-by: Venkatesh Vivekanandan <venkatesh.vivekanandan@broadcom.com>
---
drivers/hwtracing/coresight/coresight-tmc-etf.c | 9 +++++----
drivers/hwtracing/coresight/coresight-tmc-etr.c | 9 +++++----
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 466af86..c7fb7f7 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -61,6 +61,8 @@ static void tmc_etb_dump_hw(struct tmc_drvdata *drvdata)
static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
{
+ long val;
+
CS_UNLOCK(drvdata->base);
tmc_flush_and_stop(drvdata);
@@ -68,7 +70,8 @@ static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
* When operating in sysFS mode the content of the buffer needs to be
* read before the TMC is disabled.
*/
- if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
+ val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
+ if (val == CS_MODE_SYSFS)
tmc_etb_dump_hw(drvdata);
tmc_disable_hw(drvdata);
@@ -225,7 +228,6 @@ static int tmc_enable_etf_sink(struct coresight_device *csdev, u32 mode)
static void tmc_disable_etf_sink(struct coresight_device *csdev)
{
- long val;
unsigned long flags;
struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -235,9 +237,8 @@ static void tmc_disable_etf_sink(struct coresight_device *csdev)
return;
}
- val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
/* Disable the TMC only if it needs to */
- if (val != CS_MODE_DISABLED)
+ if (local_read(&drvdata->mode) != CS_MODE_DISABLED)
tmc_etb_disable_hw(drvdata);
spin_unlock_irqrestore(&drvdata->spinlock, flags);
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 688be9e..480794b 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -73,6 +73,8 @@ static void tmc_etr_dump_hw(struct tmc_drvdata *drvdata)
static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
{
+ long val;
+
CS_UNLOCK(drvdata->base);
tmc_flush_and_stop(drvdata);
@@ -80,7 +82,8 @@ static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
* When operating in sysFS mode the content of the buffer needs to be
* read before the TMC is disabled.
*/
- if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
+ val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
+ if (val == CS_MODE_SYSFS)
tmc_etr_dump_hw(drvdata);
tmc_disable_hw(drvdata);
@@ -215,7 +218,6 @@ static int tmc_enable_etr_sink(struct coresight_device *csdev, u32 mode)
static void tmc_disable_etr_sink(struct coresight_device *csdev)
{
- long val;
unsigned long flags;
struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -225,9 +227,8 @@ static void tmc_disable_etr_sink(struct coresight_device *csdev)
return;
}
- val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
/* Disable the TMC only if it needs to */
- if (val != CS_MODE_DISABLED)
+ if (local_read(&drvdata->mode) != CS_MODE_DISABLED)
tmc_etr_disable_hw(drvdata);
spin_unlock_irqrestore(&drvdata->spinlock, flags);
--
2.1.0
^ permalink raw reply related
* [PATCH v1 2/2] arm64: dts: rockchip: Add PX5 Evaluation board
From: Andreas Färber @ 2016-09-13 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473529623-6268-1-git-send-email-andy.yan@rock-chips.com>
Hi,
Am 10.09.2016 um 19:47 schrieb Andy Yan:
> PX5 EVB is designed by Rockchip for automotive field,
> which intergrated with CVBS(TP2825)/MIPI DSI/CSI/LVDS
> HDMI video input/output interface, audio codec ES8396,
> WIFI/BT(on RTL8723BS), Gsensor BMA250E and light&proximity
> sensor STK3410.
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Most comments from PX3 1/2 apply here, too.
> ---
>
> Changes in v1:
> - board rename
> - add vendor prefix for i2c interfaced devices
>
> Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts | 304 +++++++++++++++++++++
> 3 files changed, 309 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
> index 6da3881..b6f92d6 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -107,6 +107,10 @@ Rockchip platforms device tree bindings
> Required root node properties:
> - compatible = "rockchip,r88", "rockchip,rk3368";
>
> +- Rockchip PX5 Evaluation board:
> + Required root node properties:
> + - compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
> +
> - Rockchip RK3228 Evaluation board:
> Required root node properties:
> - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 7037a16..86c74b2 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -1,6 +1,7 @@
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
There is no PX5 listed on your English website (yet), but given that you
have your own rockchip/ folder for arm64 I would encourage you to rename
to px5-evb.dtb independent of any internal heritage or compatibility the
SoC has. Compare apq/ipq/msm in qcom.
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
>
> always := $(dtb-y)
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> new file mode 100644
> index 0000000..be0e915
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3368-px5-evb.dts
> @@ -0,0 +1,304 @@
> +/*
> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", 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 "rk3368.dtsi"
Similarly suggest a px5.dtsi here.
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> + model = "Rockchip PX5 EVB";
> + compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
> +
> + chosen {
> + stdout-path = "serial4:115200n8";
> + };
> +
> + memory at 0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x80000000>;
> + };
> +
> + keys: gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwr_key>;
> +
> + power {
> + gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
> + label = "GPIO Power";
> + linux,code = <KEY_POWER>;
> + wakeup-source;
> + };
> + };
> +
> + vcc_sys: vcc-sys-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_sys";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +};
> +
> +&emmc {
> + status = "okay";
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + clock-frequency = <150000000>;
> + disable-wp;
> + keep-power-in-suspend;
> + non-removable;
> + num-slots = <1>;
> + vmmc-supply = <&vcc_io>;
> + vqmmc-supply = <&vcc18_flash>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_bus8>;
> +};
> +
> +&i2c0 {
> + status = "okay";
> +
> + rk808: pmic at 1b {
> + compatible = "rockchip,rk808";
> + reg = <0x1b>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int>, <&pmic_sleep>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> + rockchip,system-power-controller;
> + vcc1-supply = <&vcc_sys>;
> + vcc2-supply = <&vcc_sys>;
> + vcc3-supply = <&vcc_sys>;
> + vcc4-supply = <&vcc_sys>;
> + vcc6-supply = <&vcc_sys>;
> + vcc7-supply = <&vcc_sys>;
> + vcc8-supply = <&vcc_io>;
> + vcc9-supply = <&vcc_sys>;
> + vcc10-supply = <&vcc_sys>;
> + vcc11-supply = <&vcc_sys>;
> + vcc12-supply = <&vcc_io>;
> + clock-output-names = "xin32k", "rk808-clkout2";
> + #clock-cells = <1>;
> +
> + regulators {
> + vdd_cpu: DCDC_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-name = "vdd_cpu";
> + };
> +
> + vdd_log: DCDC_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-name = "vdd_log";
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "vcc_ddr";
> + };
> +
> + vcc_io: DCDC_REG4 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcc_io";
> + };
> +
> + vcc18_flash: LDO_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vcc18_flash";
> + };
> +
> + vcca_33: LDO_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vcca_33";
> + };
> +
> + vdd_10: LDO_REG3 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-name = "vdd_10";
> + };
> +
> + avdd_33: LDO_REG4 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "avdd_33";
> + };
> +
> + vccio_sd: LDO_REG5 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vccio_sd";
> + };
> +
> + vdd10_lcd: LDO_REG6 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-name = "vdd10_lcd";
> + };
> +
> + vcc_18: LDO_REG7 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vcc_18";
> + };
> +
> + vcc18_lcd: LDO_REG8 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-name = "vcc18_lcd";
> + };
> +
> + vcc_sd: SWITCH_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "vcc_sd";
> + };
> +
> + vcc33_lcd: SWITCH_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "vcc33_lcd";
> + };
> + };
> + };
> +};
> +
> +&i2c1 {
> + status = "okay";
> +
> + /* Accelerometer */
> + bma250 at 18 {
> + compatible = "bosch,bma250";
> + reg = <0x18>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
> + };
> +
> + stk3410 at 48 {
> + compatible = "sensortek,STK3310";
> + reg = <0x48>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <19 IRQ_TYPE_LEVEL_LOW>;
> + };
> +};
> +
> +&i2c2 {
> + status = "okay";
> +
> + gsl1680: touchscreen at 40 {
> + compatible = "silead,gsl1680";
> + reg = <0x40>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
> + power-gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <1280>;
> + silead,max-fingers = <5>;
> + };
> +};
> +
> +&pinctrl {
> +
Drop white line?
> + keys {
> + pwr_key: pwr-key {
> + rockchip,pins = <0 2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_sleep: pmic-sleep {
> + rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>;
> + };
> +
> + pmic_int: pmic-int {
> + rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +};
> +
> +&tsadc {
> + status = "okay";
> + rockchip,hw-tshut-mode = <0>; /* CRU */
> + rockchip,hw-tshut-polarity = <1>; /* high */
> +};
> +
> +&uart4 {
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + status = "okay";
> +};
> +
> +&usb_otg {
> + status = "okay";
> +};
> +
> +&wdt {
> + status = "okay";
> +};
Otherwise formally looks fine.
Cheers,
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
* [PATCH v5 5/9] Documentation: dt-bindings: Add IRQ related properties of STM32 pinctrl
From: Alexandre Torgue @ 2016-09-13 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbZtNscuJ0bQMYt09ZKACQ0PBG8XMmGo7XnDy5fMGk9_g@mail.gmail.com>
Hi Linus,
On 09/13/2016 10:18 AM, Linus Walleij wrote:
> On Fri, Sep 9, 2016 at 4:42 PM, Alexandre TORGUE
> <alexandre.torgue@st.com> wrote:
>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
>> index 587bffb..a0eed99 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
>> @@ -14,6 +14,9 @@ Required properies:
>> - #size-cells : The value of this property must be 1
>> - ranges : defines mapping between pin controller node (parent) to
>> gpio-bank node (children).
>> + - interrupt-parent: phandle of the interrupt parent to which the external
>> + GPIO interrupts are forwarded to.
>> + - st,syscfg: phandle of the syscfg node used for IRQ mux selection.
>
> Actually this doc is incomplete.
>
> This is a phandle + offset, not just a phandle.
>
> It is a small detail so I don't care much, either send a patch to
> fix up this doc (I have already merged it) or patch the driver
> to not retrieve the offset and instead use
> #define SYSCFG_OFFSET 0x08
> or something...
I'll send a patch for Documentation.
Do I need to wait this series is officially released (4.9-rc1) or can I
send it now ?
Regards
Alex
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* [PATCH 6/8 v2] arm: orion5x: Add DT-based support for Netgear WNR854T
From: Andrew Lunn @ 2016-09-13 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88e40f0c6cafec244dc16af5a03cfb44@jamie.lentin.co.uk>
On Tue, Sep 13, 2016 at 10:10:41AM +0100, Jamie Lentin wrote:
> On 2016-09-12 23:03, Andrew Lunn wrote:
> >>Maybe we can instead leave out the PCI support from the new
> >>file for now and not delete the legacy board file?
>
> This seems a reasonable compromise. The PCI card the router comes
> with isn't supported by mwl8k mainline anyway (There's STA-only
> firmware that can be extracted from a windows driver and PCI IDs
> added, but stats reporting uses a different format), so it's not a
> huge loss, although many did replace the card with something
> Atheros-based.
O.K. So dropping the PCI code gets us going forward.
Have we missed the merge window?
> Unfortunately the power regulator on my spare router has stopped
> regulating, which will make more development tricky.
The Green Light of death?
> >Jamie, which interrupt do you see the WiFi card using? If it is
> >IRQ_ORION5X_PCIE0_INT, (1 + 11), that is probably easier to deal with
> >than if it uses GPIO 4.
>
> Definitely uses GPIO 4.
O.K, that makes it more interesting. As far as i can see, no other
PCIe system uses a GPIO for its interrupt. There is no core support
for this, or any bus driver doing it. So there is no binding to
follow.
Andrew
^ permalink raw reply
* [PATCHv3 00/11] crypto: omap HW crypto fixes
From: Herbert Xu @ 2016-09-13 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
On Thu, Aug 04, 2016 at 01:28:35PM +0300, Tero Kristo wrote:
> Hi,
>
> This revision took quite a bit time to craft due to the rework needed
> for sham buffer handling and export/import. I ended up implementing
> a flush functionality for draining out the sham buffer when doing
> export/import; just shrinking the buffer to sufficiently small size
> impacted the performance with small data chunks too much so I dropped
> this approach.
>
> The series also fixes a couple of existing issues with omap2/omap3
> hardware acceleration, I ran a full boot test / crypto manager
> test suite on all boards accessible to me now.
>
> Based on top of latest mainline, which is somewhere before 4.8-rc1
> as of writing this, I am unable to rebase the series during the next
> three weeks so wanted to get this out now. Targeted for 4.9 merge
> window, some fixes could be picked up earlier though if needed.
I have applied patches 1,4-5,7-11. Some of them didn't apply
cleanly so please check the result in my tree.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
From: Robin Murphy @ 2016-09-13 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92f27a6b-9752-516d-3924-c552fc6a5ace@redhat.com>
Hi Eric,
On 13/09/16 13:14, Auger Eric wrote:
> Hi Robin
>
> On 12/09/2016 18:13, Robin Murphy wrote:
>> Hi all,
>>
>> To any more confusing fixups and crazily numbered extra patches, here's
>> a quick v7 with everything rebased into the right order. The significant
>> change this time is to implement iommu_fwspec properly from the start,
>> which ends up being far simpler and more robust than faffing about
>> introducing it somewhere 'less intrusive' to move toward core code later.
>>
>> New branch in the logical place:
>>
>> git://linux-arm.org/linux-rm iommu/generic-v7
> I just tested your branch on AMD overdrive *without* updating the device
> tree description according to the new syntax and I get a kernel oops.
> See logs attached. Continuing my investigations ...
Looking at that backtrace, it seems the offending commit is actually in
Will's devel branch _underneath_ this series; what's blowing up there is
the short-descriptor io-pgtable selftests, which you should be able to
reproduce on anything back to 4.6-rc1 with
CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST=y.
The short-descriptor code is never going to work on Seattle due to the
lack of 32-bit addressable memory - in normal use it would fail
gracefully because it couldn't allocate anything, but since the
selftests bypass the DMA API and corresponding checks, you end up with
nastiness happening via truncated addresses. A while back I did start
looking into generalising the selftests to remove all the "if
(!selftest_running)" special-casing; might be time to pick that up again.
Robin.
>
> Best Regards
>
> Eric
>>
>> Robin.
>>
>> Mark Rutland (1):
>> Docs: dt: add PCI IOMMU map bindings
>>
>> Robin Murphy (21):
>> of/irq: Break out msi-map lookup (again)
>> iommu/of: Handle iommu-map property for PCI
>> iommu: Introduce iommu_fwspec
>> Docs: dt: document ARM SMMUv3 generic binding usage
>> iommu/arm-smmu: Fall back to global bypass
>> iommu/arm-smmu: Implement of_xlate() for SMMUv3
>> iommu/arm-smmu: Support non-PCI devices with SMMUv3
>> iommu/arm-smmu: Set PRIVCFG in stage 1 STEs
>> iommu/arm-smmu: Handle stream IDs more dynamically
>> iommu/arm-smmu: Consolidate stream map entry state
>> iommu/arm-smmu: Keep track of S2CR state
>> iommu/arm-smmu: Refactor mmu-masters handling
>> iommu/arm-smmu: Streamline SMMU data lookups
>> iommu/arm-smmu: Add a stream map entry iterator
>> iommu/arm-smmu: Intelligent SMR allocation
>> iommu/arm-smmu: Convert to iommu_fwspec
>> Docs: dt: document ARM SMMU generic binding usage
>> iommu/arm-smmu: Wire up generic configuration support
>> iommu/arm-smmu: Set domain geometry
>> iommu/dma: Add support for mapping MSIs
>> iommu/dma: Avoid PCI host bridge windows
>>
>> .../devicetree/bindings/iommu/arm,smmu-v3.txt | 8 +-
>> .../devicetree/bindings/iommu/arm,smmu.txt | 63 +-
>> .../devicetree/bindings/pci/pci-iommu.txt | 171 ++++
>> arch/arm64/mm/dma-mapping.c | 2 +-
>> drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +-
>> drivers/iommu/Kconfig | 2 +-
>> drivers/iommu/arm-smmu-v3.c | 386 +++++----
>> drivers/iommu/arm-smmu.c | 962 ++++++++++-----------
>> drivers/iommu/dma-iommu.c | 161 +++-
>> drivers/iommu/iommu.c | 56 ++
>> drivers/iommu/of_iommu.c | 52 +-
>> drivers/irqchip/irq-gic-v2m.c | 3 +
>> drivers/irqchip/irq-gic-v3-its.c | 3 +
>> drivers/of/irq.c | 78 +-
>> drivers/of/of_pci.c | 102 +++
>> include/linux/device.h | 3 +
>> include/linux/dma-iommu.h | 12 +-
>> include/linux/iommu.h | 38 +
>> include/linux/of_pci.h | 10 +
>> 19 files changed, 1323 insertions(+), 791 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
>>
>
>
>
^ permalink raw reply
* [PATCH -next] hwrng: st - Fix missing clk_disable_unprepare() on error in st_rng_probe()
From: Herbert Xu @ 2016-09-13 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473509022-3478-1-git-send-email-weiyj.lk@gmail.com>
On Sat, Sep 10, 2016 at 12:03:42PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix the missing clk_disable_unprepare() before return
> from st_rng_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v3 4/7] palmetto: Request relevant mux functions in devicetree
From: Joel Stanley @ 2016-09-13 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160830075600.11559-5-andrew@aj.id.au>
On Tue, Aug 30, 2016 at 5:25 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> +&pinctrl {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flbusy_default &pinctrl_flwp_default
> + &pinctrl_vgahs_default &pinctrl_vgavs_default
> + &pinctrl_ddcclk_default &pinctrl_ddcdat_default
> +
> + &pinctrl_pwm1_default &pinctrl_pwm2_default
> + &pinctrl_pwm3_default &pinctrl_pwm4_default
> + &pinctrl_pwm5_default &pinctrl_pwm6_default
> + &pinctrl_pwm7_default
> +
> + &pinctrl_bmcint_default &pinctrl_flack_default>;
> +};
It's not clear that all systems use these pins in that way. I will not
include this one for now.
Cheers,
Joel
^ permalink raw reply
* [PATCH v3 2/7] mach-aspeed: Select GPIO driver
From: Joel Stanley @ 2016-09-13 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160830075600.11559-3-andrew@aj.id.au>
On Tue, Aug 30, 2016 at 5:25 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig
> index f3f8c5c658db..5aba9598f821 100644
> --- a/arch/arm/mach-aspeed/Kconfig
> +++ b/arch/arm/mach-aspeed/Kconfig
> @@ -7,6 +7,8 @@ menuconfig ARCH_ASPEED
> select MOXART_TIMER
> select MFD_SYSCON
> select PINCTRL
> + select GPIOLIB
> + select GPIO_ASPEED
GPIO_ASPEED is a tristate, so if we select it in ARCH_ASPEED all users
of the driver will have it selected.
I think I will drop this patch so we still have the option of building
the gpio driver as a module. Otherwise, we should change the GPIO
driver to be built in.
Cheers,
Joel
^ permalink raw reply
* [PATCH 1/2] crypto: arm/aes-ctr: fix NULL dereference in tail processing
From: Herbert Xu @ 2016-09-13 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473756533-21078-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Sep 13, 2016 at 09:48:52AM +0100, Ard Biesheuvel wrote:
> The AES-CTR glue code avoids calling into the blkcipher API for the
> tail portion of the walk, by comparing the remainder of walk.nbytes
> modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
> into the tail processing block if they are equal. This tail processing
> block checks whether nbytes != 0, and does nothing otherwise.
>
> However, in case of an allocation failure in the blkcipher layer, we
> may enter this code with walk.nbytes == 0, while nbytes > 0. In this
> case, we should not dereference the source and destination pointers,
> since they may be NULL. So instead of checking for nbytes != 0, check
> for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
> non-error conditions.
>
> Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
> Reported-by: xiakaixu <xiakaixu@huawei.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
Both patches applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v3 0/7] aspeed: Integrate pinctrl and gpio drivers
From: Joel Stanley @ 2016-09-13 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160830075600.11559-1-andrew@aj.id.au>
On Tue, Aug 30, 2016 at 5:25 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> Here's v3 of the Aspeed pinctrl and gpio driver integration patches. v2 of the
> integration series can be found at:
>
> https://lkml.org/lkml/2016/8/19/403
Looks good to me. I commented on the two patches that I don't think we
want to include. If you're happy with that I will send a tree to Arnd.
Arnd, the pinctrl driver is staged for 4.9. We're adding the symbol to
arch/arm/mach-aspeed, so the tree I send will have a dependency on the
pinctrl tree. How do I proceed in this case?
Cheers,
Joel
^ permalink raw reply
* [PATCH v5 5/9] Documentation: dt-bindings: Add IRQ related properties of STM32 pinctrl
From: Linus Walleij @ 2016-09-13 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0359b2c7-cda5-b744-7051-4b19af0fcfcd@st.com>
On Tue, Sep 13, 2016 at 2:34 PM, Alexandre Torgue
<alexandre.torgue@st.com> wrote:
> I'll send a patch for Documentation.
> Do I need to wait this series is officially released (4.9-rc1) or can I
> send it now ?
No just send it now, I'll apply it directly on top.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
From: Auger Eric @ 2016-09-13 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e24821be-5cc4-52b3-f961-1eb32cf58293@arm.com>
Hi Robin,
On 13/09/2016 14:40, Robin Murphy wrote:
> Hi Eric,
>
> On 13/09/16 13:14, Auger Eric wrote:
>> Hi Robin
>>
>> On 12/09/2016 18:13, Robin Murphy wrote:
>>> Hi all,
>>>
>>> To any more confusing fixups and crazily numbered extra patches, here's
>>> a quick v7 with everything rebased into the right order. The significant
>>> change this time is to implement iommu_fwspec properly from the start,
>>> which ends up being far simpler and more robust than faffing about
>>> introducing it somewhere 'less intrusive' to move toward core code later.
>>>
>>> New branch in the logical place:
>>>
>>> git://linux-arm.org/linux-rm iommu/generic-v7
>> I just tested your branch on AMD overdrive *without* updating the device
>> tree description according to the new syntax and I get a kernel oops.
>> See logs attached. Continuing my investigations ...
>
> Looking at that backtrace, it seems the offending commit is actually in
> Will's devel branch _underneath_ this series; what's blowing up there is
> the short-descriptor io-pgtable selftests, which you should be able to
> reproduce on anything back to 4.6-rc1 with
> CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST=y.
I confirm that when disabling the option, I don't get the oops anymore.
Thanks!
Eric
>
> The short-descriptor code is never going to work on Seattle due to the
> lack of 32-bit addressable memory - in normal use it would fail
> gracefully because it couldn't allocate anything, but since the
> selftests bypass the DMA API and corresponding checks, you end up with
> nastiness happening via truncated addresses. A while back I did start
> looking into generalising the selftests to remove all the "if
> (!selftest_running)" special-casing; might be time to pick that up again.
>
> Robin.
>
>>
>> Best Regards
>>
>> Eric
>>>
>>> Robin.
>>>
>>> Mark Rutland (1):
>>> Docs: dt: add PCI IOMMU map bindings
>>>
>>> Robin Murphy (21):
>>> of/irq: Break out msi-map lookup (again)
>>> iommu/of: Handle iommu-map property for PCI
>>> iommu: Introduce iommu_fwspec
>>> Docs: dt: document ARM SMMUv3 generic binding usage
>>> iommu/arm-smmu: Fall back to global bypass
>>> iommu/arm-smmu: Implement of_xlate() for SMMUv3
>>> iommu/arm-smmu: Support non-PCI devices with SMMUv3
>>> iommu/arm-smmu: Set PRIVCFG in stage 1 STEs
>>> iommu/arm-smmu: Handle stream IDs more dynamically
>>> iommu/arm-smmu: Consolidate stream map entry state
>>> iommu/arm-smmu: Keep track of S2CR state
>>> iommu/arm-smmu: Refactor mmu-masters handling
>>> iommu/arm-smmu: Streamline SMMU data lookups
>>> iommu/arm-smmu: Add a stream map entry iterator
>>> iommu/arm-smmu: Intelligent SMR allocation
>>> iommu/arm-smmu: Convert to iommu_fwspec
>>> Docs: dt: document ARM SMMU generic binding usage
>>> iommu/arm-smmu: Wire up generic configuration support
>>> iommu/arm-smmu: Set domain geometry
>>> iommu/dma: Add support for mapping MSIs
>>> iommu/dma: Avoid PCI host bridge windows
>>>
>>> .../devicetree/bindings/iommu/arm,smmu-v3.txt | 8 +-
>>> .../devicetree/bindings/iommu/arm,smmu.txt | 63 +-
>>> .../devicetree/bindings/pci/pci-iommu.txt | 171 ++++
>>> arch/arm64/mm/dma-mapping.c | 2 +-
>>> drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +-
>>> drivers/iommu/Kconfig | 2 +-
>>> drivers/iommu/arm-smmu-v3.c | 386 +++++----
>>> drivers/iommu/arm-smmu.c | 962 ++++++++++-----------
>>> drivers/iommu/dma-iommu.c | 161 +++-
>>> drivers/iommu/iommu.c | 56 ++
>>> drivers/iommu/of_iommu.c | 52 +-
>>> drivers/irqchip/irq-gic-v2m.c | 3 +
>>> drivers/irqchip/irq-gic-v3-its.c | 3 +
>>> drivers/of/irq.c | 78 +-
>>> drivers/of/of_pci.c | 102 +++
>>> include/linux/device.h | 3 +
>>> include/linux/dma-iommu.h | 12 +-
>>> include/linux/iommu.h | 38 +
>>> include/linux/of_pci.h | 10 +
>>> 19 files changed, 1323 insertions(+), 791 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
>>>
>>
>>
>>
>
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD and Regulator due for the v4.9 merge window
From: Lee Jones @ 2016-09-13 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913120244.GA28894@dell>
Hold off on pulling this please Mark.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Mark Rutland @ 2016-09-13 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D7CF17.2050905@laposte.net>
On Tue, Sep 13, 2016 at 12:04:07PM +0200, Sebastian Frias wrote:
> Hi Mark,
>
> On 09/12/2016 06:56 PM, Mark Rutland wrote:
> > The latter is extremely difficult to judge when you just
> > get a binding document with little or no additional context.
>
> Exactly, that is why I was thinking it would take less "review" time.
> Indeed, if there is no driver, why would it matter what those bindings
> are?
If you believe that the bindings don't matter, then there is absolutely
no reason for them to exist in the first place.
If those binding matter to *anyone*, then those collating the bindings
have some responsibility of stewardship, and that includes
review/maintenance/etc.
Hence, the Linux community cares as stewards of those bindings, and
don't accept bindings they don't understand, for which there is no
obvious user, nor for which the authors claim stability does not matter.
Those go against the aims of DT, and against out responsiblities as
stewards.
I cannot put that any clearer.
> >> Could you be more precise on those two issues? Namely:
> >> "the effort" and the "lack of benefit for the community"?
> >
> > As above, reviewing is tricky. One has to spend the time gaining an
> > understanding of a particular piece of hardware, the class of hardware
> > it falls in, and also the bigger picture that it fits in. Once you have
> > that, you have to review the binding in that context, and that takes
> > time and effort.
>
> Yes, but this is based on a binding for which there's a driver.
> If there's no driver it should not take that much time, right?
>
> > As things evolve, perhaps mistakes or inconsistencies are found, or new
> > ways to generalise things. As that occurs, there is a maintenance burden
> > for existing bindings.
> >
> > All of that takes time and effort.
>
> Only for bindings for which there is a driver.
This is not true for all but the most trivial of hardware, as I stated
previously.
Go and take a look at all the effort that went into sorting out generic
IOMMU bindings, when driver support was written after a large amount of
review to sort out fundamental concepts. We had to sort out fundamentals
before prototype driver code could be written, and while we knew drivers
were coming, an awful lot of review effort came first.
> Think about this:
> - a binding with no driver is submitted and ends up in the tree
> (it could be on a staging area if necessary)
>
> - if at a later point somebody attempts to upstream a driver using those
> 'staging' bindings, the reviewers could say "you are using 'staging' bindings,
> please add compatibility with 'staging' and 'standard' bindings", even if that
> includes the discussion and review of newly created 'standard' bindings
> corresponding to the 'staging' bindings.
>
> - the submitter may even say "there's no need for compatibility for 'staging'
> bindings, because they were never used (or other valid reasons)".
>
> What would you think of something like that?
As above, if they were never used, and potentially wrong, why did they
exist?
Trying to upstream a binding with no user comees with no immediate
benefit, and potentially creates longer-term pain, whereas you can defer
upstreaming a binding until the driver is ready.
Note that I've repeatedly pointed out that the user of the binding
doesn't necessarily have to be linux. However, there does need to be
some demonstration, and commitment to maintaining the principles DT aims
towards (e.g. stability).
> Let's make an abstraction of the word 'binding', 'create a binding', etc. and
> just focus on this:
> - Somebody submits a DT file that contains properties and nodes that are
> *not used* by any Linux driver.
> - Said properties and nodes serve as HW description for HW blocks for which
> *there is no* Linux driver.
>
> The goal of the above is to use the DT as the authoritative (and single)
> source of HW definition.
I understand that goal, and I've asked for a specific example, as this
is not clear-cut. e.g. there has been work on describing secure devices
for QEMU, but this isn't necessarily something we want to expose Linux
to in general.
> > As with all things, it depends on context. If someone's using a DT to
> > describe details of the secure world of a platform with trustzone to a
> > secure OS, then not all of that information is relevant to Linux.
> > Likewise if configuration details specific to FW are embedded.
>
> Ok, so if the information is not relevant to Linux do you agree that it
> should not affect it, and then we could imagine such details being present on
> the DT anyway?
Perhaps, or perhaps not. It depends on a number of details, and as I've
said previously I cannot give you a general answer, because there is
none. You must provide a specific case.
> You mention the case of another OS.
> What is the definition of OS in this case?
Generally, I am considering a general purpose OS (e.g. Linux, FreeBSD),
and not a secure-world trusted OS nor firmware (as typically these are
very strongly tied to the platform, and have very different strtuctures
and requirements when compared to a general purpose OS).
That's the conext in which bindings are developed.
> Because one could say that "FW" or "secure world" could fit that definition,
> right?
There's been work on describing things about the secure world in DT for
QEMU. Firmware is typically so device-specific that an upstream/common
DT doesn't really make sense.
Perhaps you have an example of the specific use-case you care about?
> Indeed, to me it is clear that what we conceive "differently", is that
> "the effort", "lack of benefit for the community", "Old bindings should
> remain supported regardless" and "backward compatibility" are considered
> with respect to DT *plus* driver, yet the idea is to have DT describe
> HW for which there's no upstream driver yet.
> Hence most of those considerations should not apply, right?
No.
Bindings themselves should remain stable over time in that they must be
evolved so as to allow software to handle them in a stable fashion,
supporting old and new DTBs.
While a lot of that effort is taken by code, care must also be taken wit
the bindings themselves, and those considerations apply.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/5] clk: add support for runtime pm
From: Marek Szyprowski @ 2016-09-13 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFo7R1f1H1R5Q78L4e_nHfngRYfo8jP_Dfi3uf_OGWvZCg@mail.gmail.com>
Hi Ulf,
Thanks for looking into this patch!
On 2016-09-13 10:49, Ulf Hansson wrote:
> On 1 September 2016 at 15:45, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>> Registers for some clocks might be located in the SOC area, which are under the
>> power domain. To enable access to those registers respective domain has to be
>> turned on. Additionally, registers for such clocks will usually loose its
>> contents when power domain is turned off, so additional saving and restoring of
>> them might be needed in the clock controller driver.
> This is indeed correct, I can confirm that the UX500 SoC's PRCC clock
> controllers also needs to be managed like this.
>
>> This patch adds basic infrastructure in the clocks core to allow implementing
>> driver for such clocks under power domains. Clock provider can supply a
>> struct device pointer, which is the used by clock core for tracking and managing
>> clock's controller runtime pm state. Each clk_prepare() operation
>> will first call pm_runtime_get_sync() on the supplied device, while
>> clk_unprepare() will do pm_runtime_put() at the end.
> This make sense!
>
>> Additional calls to pm_runtime_get/put functions are required to ensure that any
>> register access (like calculating/chaning clock rates) will be done with clock
> /s/chaning/changing
>
>> controller in active runtime state.
> /s/active runtime/runtime resumed
>
>> Special handling of the case when runtime pm is disabled for clock controller's
>> device is needed to let this feature work properly also during system sleep
>> suspend/resume operations (runtime pm is first disabled before entering sleep
>> state's, but controller is usually still operational until its suspend pm
>> callback is called).
> This needs to be clarified. I agree we need to cover system PM as
> well, but let's try be a bit more precise about it.
Right, I wasn't precise here. I've developed this code on older (v4.1
and v4.6)
kernels, which had a code which disables runtime pm during system sleep
transition
time. Maybe I need to revisit it and consider your change merged to
v4.8-rc1, which
keeps runtime pm enabled during system sleep transitions.
>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> I would also like to extend the change log to describe a little bit of
> how a clk provider should interact with this new and nice feature.
> Something like:
>
> *) It needs to provide a struct device to the core when registering
> the provider.
> **) It needs to enable runtime PM.
> ***) It needs to make sure the runtime PM status of the controller
> device reflects the HW state.
Right, this definitely has to be added. Thank you for reminding about
such obvious
things.
>> ---
>> drivers/clk/clk.c | 84 +++++++++++++++++++++++++++++++++++++++++++++++++------
>> 1 file changed, 76 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 820a939fb6bb..a1934e9b4e95 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -21,6 +21,7 @@
>> #include <linux/of.h>
>> #include <linux/device.h>
>> #include <linux/init.h>
>> +#include <linux/pm_runtime.h>
>> #include <linux/sched.h>
>> #include <linux/clkdev.h>
>>
>> @@ -46,6 +47,7 @@ struct clk_core {
>> const struct clk_ops *ops;
>> struct clk_hw *hw;
>> struct module *owner;
>> + struct device *dev;
>> struct clk_core *parent;
>> const char **parent_names;
>> struct clk_core **parents;
>> @@ -87,6 +89,42 @@ struct clk {
>> struct hlist_node clks_node;
>> };
>>
>> +/*** runtime pm ***/
>> +static int clk_pm_runtime_get(struct clk_core *core)
>> +{
>> + int ret = 0;
>> +
>> + if (!core->dev)
>> + return 0;
>> +
>> + if (pm_runtime_enabled(core->dev)) {
> Why do you need to check for this?
This was a workaround, which let it work during the system sleep transition
state.
>
>> + ret = pm_runtime_get_sync(core->dev);
>> + } else {
>> + if (!pm_runtime_status_suspended(core->dev))
>> + pm_runtime_get_noresume(core->dev);
> This looks weird. I guess it's related to the system PM case somehow?
>
>> + }
>> + return ret < 0 ? ret : 0;
>> +}
>> +
>> +static void clk_pm_runtime_put(struct clk_core *core)
>> +{
> Similar comments as for clk_pm_runtime_get().
>
>> + if (!core->dev)
>> + return;
>> +
>> + if (pm_runtime_enabled(core->dev))
>> + pm_runtime_put(core->dev);
>> + else
>> + pm_runtime_put_noidle(core->dev);
>> +}
>> +
>> +static bool clk_pm_runtime_suspended(struct clk_core *core)
>> +{
>> + if (!core->dev)
>> + return 0;
>> +
>> + return pm_runtime_suspended(core->dev);
>> +}
>> +
>> /*** locking ***/
>> static void clk_prepare_lock(void)
>> {
>> @@ -150,6 +188,9 @@ static void clk_enable_unlock(unsigned long flags)
>>
>> static bool clk_core_is_prepared(struct clk_core *core)
>> {
>> + if (clk_pm_runtime_suspended(core))
>> + return false;
>> +
> This isn't safe, as even if the clock controller is runtime resumed at
> this point, that's *not* a guarantee that is stays runtime resumed
> while invoking the ->ops->is_prepared().
>
> Instead you must call a pm_runtime_get_noresume() before you check the
> runtime PM status, as that should avoid the device from being runtime
> suspended. Then when the ->ops->is_prepared() has been invoked, we
> should call pm_runtime_put().
>
> Although, I am not sure the above change becomes entirely correct as I
> think we are mixing the runtime PM status with the clock prepare
> status here. In other words, the next time the clock controller
> becomes runtime resumed, it may very well restore some register
> context which may prepare the clock, unless someone explicitly has
> unprepared it.
>
> Of course, it all depends on how clk_core_is_prepared() is used by the
> clock framework.
clk_core_is_prepared() is mainly used by disable_unused_tree_*. You are
right that it mixes a bit clock prepared state with runtime pm active
state of clock controller's, but I assumed here that clock cannot be
prepared if runtime pm state of controller is suspended. Other approach
here would be to call pm_runtime_get(), check status and then
pm_runtime_put(). If you prefer such approach, I will change it.
>
>> /*
>> * .is_prepared is optional for clocks that can prepare
>> * fall back to software usage counter if it is missing
>> @@ -162,6 +203,9 @@ static bool clk_core_is_prepared(struct clk_core *core)
>>
>> static bool clk_core_is_enabled(struct clk_core *core)
>> {
>> + if (clk_pm_runtime_suspended(core))
>> + return false;
>> +
> Similar comment as for clk_core_is_prepared().
>
>> /*
>> * .is_enabled is only mandatory for clocks that gate
>> * fall back to software usage counter if .is_enabled is missing
>> @@ -489,6 +533,8 @@ static void clk_core_unprepare(struct clk_core *core)
>> if (core->ops->unprepare)
>> core->ops->unprepare(core->hw);
>>
>> + clk_pm_runtime_put(core);
>> +
>> trace_clk_unprepare_complete(core);
>> clk_core_unprepare(core->parent);
>> }
>> @@ -530,10 +576,14 @@ static int clk_core_prepare(struct clk_core *core)
>> return 0;
>>
>> if (core->prepare_count == 0) {
>> - ret = clk_core_prepare(core->parent);
>> + ret = clk_pm_runtime_get(core);
>> if (ret)
>> return ret;
>>
>> + ret = clk_core_prepare(core->parent);
>> + if (ret)
>> + goto runtime_put;
>> +
>> trace_clk_prepare(core);
>>
>> if (core->ops->prepare)
>> @@ -541,15 +591,18 @@ static int clk_core_prepare(struct clk_core *core)
>>
>> trace_clk_prepare_complete(core);
>>
>> - if (ret) {
>> - clk_core_unprepare(core->parent);
>> - return ret;
>> - }
>> + if (ret)
>> + goto unprepare;
>> }
>>
>> core->prepare_count++;
>>
>> return 0;
>> +unprepare:
>> + clk_core_unprepare(core->parent);
>> +runtime_put:
>> + clk_pm_runtime_put(core);
>> + return ret;
>> }
>>
>> static int clk_core_prepare_lock(struct clk_core *core)
>> @@ -1563,6 +1616,7 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
>> {
>> struct clk_core *top, *fail_clk;
>> unsigned long rate = req_rate;
>> + int ret = 0;
>>
>> if (!core)
>> return 0;
>> @@ -1579,21 +1633,28 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
>> if (!top)
>> return -EINVAL;
>>
>> + ret = clk_pm_runtime_get(core);
>> + if (ret)
>> + return ret;
>> +
>> /* notify that we are about to change rates */
>> fail_clk = clk_propagate_rate_change(top, PRE_RATE_CHANGE);
>> if (fail_clk) {
>> pr_debug("%s: failed to set %s rate\n", __func__,
>> fail_clk->name);
>> clk_propagate_rate_change(top, ABORT_RATE_CHANGE);
>> - return -EBUSY;
>> + ret = -EBUSY;
>> + goto err;
>> }
>>
>> /* change the rates */
>> clk_change_rate(top);
>>
>> core->req_rate = req_rate;
>> +err:
>> + clk_pm_runtime_put(core);
>>
>> - return 0;
>> + return ret;
>> }
>>
>> /**
>> @@ -1824,12 +1885,16 @@ static int clk_core_set_parent(struct clk_core *core, struct clk_core *parent)
>> p_rate = parent->rate;
>> }
>>
>> + ret = clk_pm_runtime_get(core);
>> + if (ret)
>> + goto out;
>> +
>> /* propagate PRE_RATE_CHANGE notifications */
>> ret = __clk_speculate_rates(core, p_rate);
>>
>> /* abort if a driver objects */
>> if (ret & NOTIFY_STOP_MASK)
>> - goto out;
>> + goto runtime_put;
>>
>> /* do the re-parent */
>> ret = __clk_set_parent(core, parent, p_index);
>> @@ -1842,6 +1907,8 @@ static int clk_core_set_parent(struct clk_core *core, struct clk_core *parent)
>> __clk_recalc_accuracies(core);
>> }
>>
>> +runtime_put:
>> + clk_pm_runtime_put(core);
>> out:
>> clk_prepare_unlock();
>>
>> @@ -2546,6 +2613,7 @@ struct clk *clk_register(struct device *dev, struct clk_hw *hw)
>> goto fail_name;
>> }
>> core->ops = hw->init->ops;
>> + core->dev = dev;
>> if (dev && dev->driver)
>> core->owner = dev->driver->owner;
>> core->hw = hw;
>> --
>> 1.9.1
>>
> I believe we are also accessing the clock controller HW from the
> late_initcall_sync(clk_disable_unused) function.
This was indirectly handled by the runtime pm state check in is_prepared
and is_enabled().
> More precisely, in clk_disable_unused_subtree(), we probably need a
> pm_runtime_get_sync() before calling clk_core_is_enabled(). And then
> restore that with a pm_runtime_put() after the clock has been
> disabled.
> The similar is needed in clk_unprepare_unused_subtree().
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Mark Rutland @ 2016-09-13 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D7E4EC.6050509@tabi.org>
Hi Timur,
On Tue, Sep 13, 2016 at 06:37:16AM -0500, Timur Tabi wrote:
> Sebastian Frias wrote:
> >Let's make an abstraction of the word 'binding', 'create a binding', etc. and
> >just focus on this:
> >- Somebody submits a DT file that contains properties and nodes that are
> >*not used* by any Linux driver.
> >- Said properties and nodes serve as HW description for HW blocks for which
> >*there is no* Linux driver.
> >
> >The goal of the above is to use the DT as the authoritative (and single)
> >source of HW definition.
>
> No.
>
> I've grown weary of this discussion. We have explained multiple
> times why this is impractical. Using the DT to document hardware
> makes no sense. No one is going to do that, and anyone who attempts
> to submit a DT binding without an actual driver will get rejected.
Please don't make the same mistake of trivialising this in either
direction.
While we appear to be going in circles, in general there are potentially
valid cases to consider -- there may be system properties/devices that
don't happen to matter to Linux, but are generic, well-defined, and
matter to others. Bindings for those should be considered.
In the absence of any example, as with this thread, there is nothing to
consider, however.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] iommu/io-pgtable-arm: Check for v7s-incapable systems
From: Robin Murphy @ 2016-09-13 13:26 UTC (permalink / raw)
To: linux-arm-kernel
On machines with no 32-bit addressable RAM whatsoever, we shouldn't
even touch the v7s format as it's never going to work.
Fixes: e5fc9753b1a8 ("iommu/io-pgtable: Add ARMv7 short descriptor support")
Reported-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm-v7s.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index def8ca1c982d..b7759a48f4ed 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -633,6 +633,9 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
{
struct arm_v7s_io_pgtable *data;
+ if (upper_32_bits(PHYS_OFFSET))
+ return NULL;
+
if (cfg->ias > ARM_V7S_ADDR_BITS || cfg->oas > ARM_V7S_ADDR_BITS)
return NULL;
--
2.8.1.dirty
^ permalink raw reply related
* [PATCH] Documentation: dt-bindings: Fix "st, syscfg" definition for STM32 pinctrl
From: Alexandre TORGUE @ 2016-09-13 13:28 UTC (permalink / raw)
To: linux-arm-kernel
"st,syscfg" entry was bad described.
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
index a0eed99..f9753c4 100644
--- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
@@ -16,7 +16,9 @@ Required properies:
gpio-bank node (children).
- interrupt-parent: phandle of the interrupt parent to which the external
GPIO interrupts are forwarded to.
- - st,syscfg: phandle of the syscfg node used for IRQ mux selection.
+ - st,syscfg: Should be phandle/offset pair. The phandle to the syscon node
+ which includes IRQ mux selection register, and the offset of the IRQ mux
+ selection register.
- pins-are-numbered: Specify the subnodes are using numbered pinmux to
specify pins.
--
1.9.1
^ permalink raw reply related
* [GIT PULL] Immutable branch between MFD and Regulator due for the v4.9 merge window
From: Lee Jones @ 2016-09-13 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913120244.GA28894@dell>
Mark,
Try this instead.
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-regulator-v4.9
for you to fetch changes up to 8824ee8573483e1c91691b5be3d3730e75551dce:
mfd: axp20x: Add support for AXP806 PMIC (2016-09-13 14:10:04 +0100)
----------------------------------------------------------------
Immutable branch between MFD and Regualtor due for the v4.9 merge window
----------------------------------------------------------------
Chen-Yu Tsai (3):
regulator: axp20x: Support AXP806 variant
mfd: axp20x: Add bindings for AXP806 PMIC
mfd: axp20x: Add support for AXP806 PMIC
Documentation/devicetree/bindings/mfd/axp20x.txt | 28 +++++-
drivers/mfd/axp20x-rsb.c | 1 +
drivers/mfd/axp20x.c | 72 ++++++++++++++
drivers/regulator/axp20x-regulator.c | 118 +++++++++++++++++++++--
include/linux/mfd/axp20x.h | 60 ++++++++++++
5 files changed, 270 insertions(+), 9 deletions(-)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 1/9] ethernet: add sun8i-emac driver
From: LABBE Corentin @ 2016-09-13 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909141527.GE30871@lunn.ch>
On Fri, Sep 09, 2016 at 04:15:27PM +0200, Andrew Lunn wrote:
> Hi Corentin
>
> > +static int sun8i_emac_mdio_register(struct net_device *ndev)
> > +{
> > + struct sun8i_emac_priv *priv = netdev_priv(ndev);
> > + struct mii_bus *bus;
> > + int ret;
> > +
> > + bus = mdiobus_alloc();
>
> You can use devm_mdiobus_alloc() which will simplify your error
> handling and unregister code.
>
> Andrew
Hello
Since the mdio bus is allocated on ndev/open, it need to be removed when ndev/stop is called.
So devm_mdiobus_alloc cannot be used.
Regards
Corentin Labbe
^ permalink raw reply
* [PATCH v3 3/9] ARM: sun8i: dt: Add DT bindings documentation for Allwinner sun8i-emac
From: LABBE Corentin @ 2016-09-13 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909141710.GF30871@lunn.ch>
On Fri, Sep 09, 2016 at 04:17:10PM +0200, Andrew Lunn wrote:
> > +Optional properties:
> > +- allwinner,tx-delay: TX clock delay chain value. Range value is 0-0x07. Default is 0)
> > +- allwinner,rx-delay: RX clock delay chain value. Range value is 0-0x1F. Default is 0)
>
> What are the units? pS? nS?
>
> Andrew
No units, only raw number.
I will add a comment for this.
Regards
Corentin Labbe
^ permalink raw reply
* Qustion:: hungtask will come up when ksm enable.
From: zhong jiang @ 2016-09-13 13:37 UTC (permalink / raw)
To: linux-arm-kernel
I hit a following problem when run a oom case in ltp. The kernel version is 4.1 stable.
[ 601.937145] Call trace:
[ 601.939600] [<ffffffc000086a88>] __switch_to+0x74/0x8c
[ 601.944760] [<ffffffc000a1bae0>] __schedule+0x23c/0x7bc
[ 601.950007] [<ffffffc000a1c09c>] schedule+0x3c/0x94
[ 601.954907] [<ffffffc000a1eb84>] rwsem_down_write_failed+0x214/0x350
[ 601.961289] [<ffffffc000a1e32c>] down_write+0x64/0x80
[ 601.966363] [<ffffffc00021f794>] __ksm_exit+0x90/0x19c
[ 601.971523] [<ffffffc0000be650>] mmput+0x118/0x11c
[ 601.976335] [<ffffffc0000c3ec4>] do_exit+0x2dc/0xa74
[ 601.981321] [<ffffffc0000c46f8>] do_group_exit+0x4c/0xe4
[ 601.986656] [<ffffffc0000d0f34>] get_signal+0x444/0x5e0
[ 601.991904] [<ffffffc000089fcc>] do_signal+0x1d8/0x450
[ 601.997065] [<ffffffc00008a35c>] do_notify_resume+0x70/0x78
ksm_exit should take the write lock and wait all read lock is released. in fact, but I find
ksmd still hold a read lock in scan_get_next_rmap_item. thefefore, it will lead to hungtask.
Any suggestion will be appreciated.
Thanks
zhongjiang
^ permalink raw reply
* [PATCH v3 4/9] ARM: dts: sun8i-h3: Add dt node for the syscon control module
From: LABBE Corentin @ 2016-09-13 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912072812.GB9449@lukather>
On Mon, Sep 12, 2016 at 09:28:12AM +0200, Maxime Ripard wrote:
> On Fri, Sep 09, 2016 at 02:45:12PM +0200, Corentin Labbe wrote:
> > This patch add the dt node for the syscon register present on the
> > Allwinner H3.
> >
> > Only two register are present in this syscon and the only one useful is
> > the one dedicated to EMAC clock.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index fdf9fdb..a39da6f 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -140,6 +140,11 @@
> > #size-cells = <1>;
> > ranges;
> >
> > + syscon: syscon at 01c00000 {
> > + compatible = "syscon";
>
> Having our compatible would be nice here. syscon doesn't mean anything
> by itself.
>
Since no driver handle it, I follow what I saw in other DT.
At your choice, I can add a sun8i-syscon, but it will be unused.
> > + reg = <0x01c00000 0x34>;
>
> And the size of our system controller is 0x1000
>
I put the real size used, but I can put what datasheet said.
Regards
Corentin Labbe
^ 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