* [PATCH V7 10/10] arm/arm64: KVM: add guest SEA support
From: Tyler Baicar @ 2017-01-12 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484244924-24786-1-git-send-email-tbaicar@codeaurora.org>
Currently external aborts are unsupported by the guest abort
handling. Add handling for SEAs so that the host kernel reports
SEAs which occur in the guest kernel.
Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
---
arch/arm/include/asm/kvm_arm.h | 1 +
arch/arm/include/asm/system_misc.h | 5 +++++
arch/arm/kvm/mmu.c | 18 ++++++++++++++++--
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/include/asm/system_misc.h | 2 ++
arch/arm64/mm/fault.c | 13 +++++++++++++
6 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index e22089f..33a77509 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -187,6 +187,7 @@
#define FSC_FAULT (0x04)
#define FSC_ACCESS (0x08)
#define FSC_PERM (0x0c)
+#define FSC_EXTABT (0x10)
/* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
#define HPFAR_MASK (~0xf)
diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
index a3d61ad..ea45d94 100644
--- a/arch/arm/include/asm/system_misc.h
+++ b/arch/arm/include/asm/system_misc.h
@@ -24,4 +24,9 @@ extern unsigned int user_debug;
#endif /* !__ASSEMBLY__ */
+static inline int handle_guest_sea(unsigned long addr, unsigned int esr)
+{
+ return -1;
+}
+
#endif /* __ASM_ARM_SYSTEM_MISC_H */
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index e9a5c0e..1152966 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -29,6 +29,7 @@
#include <asm/kvm_asm.h>
#include <asm/kvm_emulate.h>
#include <asm/virt.h>
+#include <asm/system_misc.h>
#include "trace.h"
@@ -1441,8 +1442,21 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
/* Check the stage-2 fault is trans. fault or write fault */
fault_status = kvm_vcpu_trap_get_fault_type(vcpu);
- if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
- fault_status != FSC_ACCESS) {
+
+ /* The host kernel will handle the synchronous external abort. There
+ * is no need to pass the error into the guest.
+ */
+ if (fault_status == FSC_EXTABT) {
+ if(handle_guest_sea((unsigned long)fault_ipa,
+ kvm_vcpu_get_hsr(vcpu))) {
+ kvm_err("Failed to handle guest SEA, FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
+ kvm_vcpu_trap_get_class(vcpu),
+ (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
+ (unsigned long)kvm_vcpu_get_hsr(vcpu));
+ return -EFAULT;
+ }
+ } else if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
+ fault_status != FSC_ACCESS) {
kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
kvm_vcpu_trap_get_class(vcpu),
(unsigned long)kvm_vcpu_trap_get_fault(vcpu),
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 4b5c977..be0efb6 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -201,6 +201,7 @@
#define FSC_FAULT ESR_ELx_FSC_FAULT
#define FSC_ACCESS ESR_ELx_FSC_ACCESS
#define FSC_PERM ESR_ELx_FSC_PERM
+#define FSC_EXTABT ESR_ELx_FSC_EXTABT
/* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
#define HPFAR_MASK (~UL(0xf))
diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
index e7f3440..27816cb 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -77,4 +77,6 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
int register_sea_notifier(struct notifier_block *nb);
void unregister_sea_notifier(struct notifier_block *nb);
+int handle_guest_sea(unsigned long addr, unsigned int esr);
+
#endif /* __ASM_SYSTEM_MISC_H */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 81039c7..fa8d4d7 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -597,6 +597,19 @@ static const char *fault_name(unsigned int esr)
}
/*
+ * Handle Synchronous External Aborts that occur in a guest kernel.
+ */
+int handle_guest_sea(unsigned long addr, unsigned int esr)
+{
+ atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
+
+ pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
+ fault_name(esr), esr, addr);
+
+ return 0;
+}
+
+/*
* Dispatch a data abort to the relevant handler.
*/
asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* Nokia N900: mixers changed between 4.6 and 4.10, no longer can use in-call speaker
From: Pavel Machek @ 2017-01-12 18:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
In v4.10 (and probably v4.9, too) I can no longer use the in-call
speaker. I can no longer use the wired headset, either.
v4.4 (and probably v4.6) works ok.
Any ideas? Does wired headset / in-call speaker work for you?
"Mono" and "Mono DAC" options are still there.. but something else
changed, as alsamixer now shows way many more options (meaning they
are shorter?) and I get complains from alsactl:
alsactl: set_control:1328: failed to obtain info for control #49 (No
such file or directory)
...
alsactl: set_control:1328: failed to obtain info for control #229 (No
such file or directory)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170112/686d3a2c/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 1/2] of: base: add support to find the level of the last cache
From: Sudeep Holla @ 2017-01-12 18:29 UTC (permalink / raw)
To: linux-arm-kernel
It is useful to have helper function just to get the number of cache
levels for a given logical cpu. We can obtain the same by just checking
the level at which the last cache is present. This patch adds support
to find the level of the last cache for a given cpu.
It will be used on ARM64 platform where the device tree provides the
information for the additional non-architected/transparent/external
last level caches that are not integrated with the processors.
Suggested-by: Rob Herring <robh+dt@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/of/base.c | 27 +++++++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 28 insertions(+)
v1->v2:
- Moved to using "cache-level" in the last level cache instead
of counting through all the nodes as suggested by Rob
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..c1128a077aea 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -25,6 +25,7 @@
#include <linux/cpu.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/of_graph.h>
#include <linux/spinlock.h>
#include <linux/slab.h>
@@ -2268,6 +2269,32 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
}
/**
+ * of_find_last_cache_level - Find the level at which the last cache is
+ * present for the given logical cpu
+ *
+ * @cpu: cpu number(logical index) for which the last cache level is needed
+ *
+ * Returns the the level at which the last cache is present. It is exactly
+ * same as the total number of cache levels for the given logical cpu.
+ */
+int of_find_last_cache_level(unsigned int cpu)
+{
+ int cache_level = 0;
+ struct device_node *prev = NULL, *np = of_cpu_device_node_get(cpu);
+
+ while (np) {
+ prev = np;
+ of_node_put(np);
+ np = of_find_next_cache_node(np);
+ }
+
+ if (prev)
+ of_property_read_u32(prev, "cache-level", &cache_level);
+
+ return cache_level;
+}
+
+/**
* of_graph_parse_endpoint() - parse common endpoint node properties
* @node: pointer to endpoint device_node
* @endpoint: pointer to the OF endpoint data structure
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..21e6323de0f3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -280,6 +280,7 @@ extern struct device_node *of_get_child_by_name(const struct device_node *node,
/* cache lookup */
extern struct device_node *of_find_next_cache_node(const struct device_node *);
+extern int of_find_last_cache_level(unsigned int cpu);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] arm64: cacheinfo: add support to override cache levels via device tree
From: Sudeep Holla @ 2017-01-12 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484245772-31511-1-git-send-email-sudeep.holla@arm.com>
The cache hierarchy can be identified through Cache Level ID(CLIDR)
architected system register. However in some cases it will provide
only the number of cache levels that are integrated into the processor
itself. In other words, it can't provide any information about the
caches that are external and/or transparent.
Some platforms require to export the information about all such external
caches to the userspace applications via the sysfs interface.
This patch adds support to override the cache levels using device tree
to take such external non-architected caches into account.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/kernel/cacheinfo.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
index 9617301f76b5..3f2250fc391b 100644
--- a/arch/arm64/kernel/cacheinfo.c
+++ b/arch/arm64/kernel/cacheinfo.c
@@ -84,7 +84,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
static int __init_cache_level(unsigned int cpu)
{
- unsigned int ctype, level, leaves;
+ unsigned int ctype, level, leaves, of_level;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
@@ -97,6 +97,17 @@ static int __init_cache_level(unsigned int cpu)
leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
}
+ of_level = of_find_last_cache_level(cpu);
+ if (level < of_level) {
+ /*
+ * some external caches not specified in CLIDR_EL1
+ * the information may be available in the device tree
+ * only unified external caches are considered here
+ */
+ leaves += (of_level - level);
+ level = of_level;
+ }
+
this_cpu_ci->num_levels = level;
this_cpu_ci->num_leaves = leaves;
return 0;
--
2.7.4
^ permalink raw reply related
* [QUESTION] Arm64: Query L3 cache info via DT
From: Sudeep Holla @ 2017-01-12 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5874A03A.9000901@huawei.com>
On 10/01/17 08:50, Tan Xiaojun wrote:
[...]
> diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> index 4b472a3..aac18c2 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
> @@ -215,18 +215,30 @@
>
> cluster0_l2: l2-cache0 {
> compatible = "cache";
> + next-level-cache = <&die0_l3c>;
> };
>
> cluster1_l2: l2-cache1 {
> compatible = "cache";
> + next-level-cache = <&die0_l3c>;
> };
>
> cluster2_l2: l2-cache2 {
> compatible = "cache";
> + next-level-cache = <&die0_l3c>;
> };
>
> cluster3_l2: l2-cache3 {
> compatible = "cache";
> + next-level-cache = <&die0_l3c>;
> + };
> +
> + die0_l3c: l3-cache {
> + compatible = "cache";
> + cache-size = <16777216>;
> + cache-line-size = <64>;
> + cache-block-size = <16>;
You need to add cache-level = <3> with v2 patch set to work.
--
Regards,
Sudeep
^ permalink raw reply
* Nokia N900: mixers changed between 4.6 and 4.10, no longer can use in-call speaker
From: Pali Rohár @ 2017-01-12 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112181826.GA28290@amd>
On Thursday 12 January 2017 19:18:26 Pavel Machek wrote:
> Hi!
>
> In v4.10 (and probably v4.9, too) I can no longer use the in-call
> speaker. I can no longer use the wired headset, either.
>
> v4.4 (and probably v4.6) works ok.
>
> Any ideas? Does wired headset / in-call speaker work for you?
>
> "Mono" and "Mono DAC" options are still there.. but something else
> changed, as alsamixer now shows way many more options (meaning they
> are shorter?) and I get complains from alsactl:
>
> alsactl: set_control:1328: failed to obtain info for control #49 (No
> such file or directory)
> ...
> alsactl: set_control:1328: failed to obtain info for control #229 (No
> such file or directory)
>
>
>
> Pavel
Looks like there are not so much commits related to
sound/soc/omap/rx51.c Maybe it can be one of these twos?
cb7e62256e99d285e415cf75db67558f0f8bb107
6d2de5ab4328718302c54b20222c6b1a574c3fce
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170112/2c86eae0/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: errata: Provide macro for major and minor cpu revisions
From: Robert Richter @ 2017-01-12 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112153315.GC13843@arm.com>
On 12.01.17 15:33:15, Will Deacon wrote:
> On Wed, Jan 11, 2017 at 01:11:42PM +0100, Robert Richter wrote:
> > Definition of cpu ranges are hard to read if the cpu variant is not
> > zero. Provide MIDR_CPU_FULL_REV() macro to describe the full hardware
> > revision of a cpu including variant and (minor) revision.
> >
> > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > ---
> > arch/arm64/include/asm/cputype.h | 3 +++
> > arch/arm64/kernel/cpu_errata.c | 15 +++++++++------
> > arch/arm64/kernel/cpufeature.c | 8 +++-----
> > 3 files changed, 15 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> > index 26a68ddb11c1..983e59cbdd54 100644
> > --- a/arch/arm64/include/asm/cputype.h
> > +++ b/arch/arm64/include/asm/cputype.h
> > @@ -56,6 +56,9 @@
> > (0xf << MIDR_ARCHITECTURE_SHIFT) | \
> > ((partnum) << MIDR_PARTNUM_SHIFT))
> >
> > +#define MIDR_CPU_FULL_REV(var, rev) \
> > + (((var) << MIDR_VARIANT_SHIFT) | (rev))
>
> Minor nit, but could you rename this to MIDR_CPU_VAR_REV instead please?
> The revision field *is* the bottom 4 bits, so "full" rev doesn't really
> make a lot of sense.
Yeah, this is that I had in my first version. I wasn't sure on the
naming, so I am fine with your proposal.
Will resubmit.
Thanks,
-Robert
^ permalink raw reply
* [PATCH v3 resend] i2c: designware: add reset interface
From: Wolfram Sang @ 2017-01-12 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482848560-3752-1-git-send-email-zhangfei.gao@linaro.org>
On Tue, Dec 27, 2016 at 10:22:40PM +0800, Zhangfei Gao wrote:
> Some platforms like hi3660 need do reset first to allow accessing registers
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Tested-by: Ramiro Oliveira <ramiro.oliveira@synopsys.com>
Applied to for-next, thanks!
^ permalink raw reply
* [PATCH v3] arm64: mm: Fix NOMAP page initialization
From: Robert Richter @ 2017-01-12 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112160535.GF13843@arm.com>
On 12.01.17 16:05:36, Will Deacon wrote:
> On Mon, Jan 09, 2017 at 12:53:20PM +0100, Robert Richter wrote:
> > Kernel compile times (3 runs each):
> >
> > pfn_valid_within():
> >
> > real 6m4.088s
> > user 372m57.607s
> > sys 16m55.158s
> >
> > real 6m1.532s
> > user 372m48.453s
> > sys 16m50.370s
> >
> > real 6m4.061s
> > user 373m18.753s
> > sys 16m57.027s
>
> Did you reboot the machine between each build here, or only when changing
> kernel? If the latter, do you see variations in kernel build time by simply
> rebooting the same Image?
I built it in a loop on the shell, so no reboots between builds. Note
that I was building the kernel in /dev/shm to not access harddisks. I
think build times should be comparable then since there is no fs
caching.
-Robert
^ permalink raw reply
* [PATCH v2 03/26] treewide: Consolidate set_dma_ops() implementations
From: Bart Van Assche @ 2017-01-12 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112190718.6728-1-bart.vanassche@sandisk.com>
Now that all set_dma_ops() implementations are identical (ignoring
BUG_ON() statements), remove the architecture specific definitions
and add a definition in <linux/dma-mapping.h>.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linux-arch at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: Paul Mackerras <paulus@samba.org>
Cc: Russell King <linux@armlinux.org.uk>
---
arch/arm/include/asm/dma-mapping.h | 6 ------
arch/powerpc/include/asm/dma-mapping.h | 5 -----
arch/tile/include/asm/dma-mapping.h | 5 -----
include/linux/dma-mapping.h | 5 +++++
4 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 312f4d0564d6..c7432d647e53 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -31,12 +31,6 @@ static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
return __generic_dma_ops(dev);
}
-static inline void set_dma_ops(struct device *dev, const struct dma_map_ops *ops)
-{
- BUG_ON(!dev);
- dev->dma_ops = ops;
-}
-
#define HAVE_ARCH_DMA_SUPPORTED 1
extern int dma_supported(struct device *dev, u64 mask);
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 59fbd4abcbf8..8275603ba4d5 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -91,11 +91,6 @@ static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
return dev->dma_ops;
}
-static inline void set_dma_ops(struct device *dev, const struct dma_map_ops *ops)
-{
- dev->dma_ops = ops;
-}
-
/*
* get_dma_offset()
*
diff --git a/arch/tile/include/asm/dma-mapping.h b/arch/tile/include/asm/dma-mapping.h
index c0620697eaad..2562995a6ac9 100644
--- a/arch/tile/include/asm/dma-mapping.h
+++ b/arch/tile/include/asm/dma-mapping.h
@@ -59,11 +59,6 @@ static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
static inline void dma_mark_clean(void *addr, size_t size) {}
-static inline void set_dma_ops(struct device *dev, const struct dma_map_ops *ops)
-{
- dev->dma_ops = ops;
-}
-
static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
{
if (!dev->dma_mask)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f1da68b82c63..e97f23e8b2d9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -164,6 +164,11 @@ int dma_mmap_from_coherent(struct device *dev, struct vm_area_struct *vma,
#ifdef CONFIG_HAS_DMA
#include <asm/dma-mapping.h>
+static inline void set_dma_ops(struct device *dev,
+ const struct dma_map_ops *dma_ops)
+{
+ dev->dma_ops = dma_ops;
+}
#else
/*
* Define the dma api to allow compilation but not linking of
--
2.11.0
^ permalink raw reply related
* [PATCH] KVM: arm/arm64: vgic: Fix deadlock on error handling
From: Christoffer Dall @ 2017-01-12 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484237774-19047-1-git-send-email-marc.zyngier@arm.com>
On Thu, Jan 12, 2017 at 04:16:14PM +0000, Marc Zyngier wrote:
> Dmitry Vyukov reported that the syzkaller fuzzer triggered a
> deadlock in the vgic setup code when an error was detected, as
> the cleanup code tries to take a lock that is already held by
> the setup code.
>
> The fix is to avoid retaking the lock when cleaning up, by
> telling the cleanup function that we already hold it.
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/arm/vgic/vgic-init.c | 18 +++++++++++++-----
> virt/kvm/arm/vgic/vgic-v2.c | 2 --
> virt/kvm/arm/vgic/vgic-v3.c | 2 --
> 3 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
> index 5114391..c737ea0 100644
> --- a/virt/kvm/arm/vgic/vgic-init.c
> +++ b/virt/kvm/arm/vgic/vgic-init.c
> @@ -268,15 +268,11 @@ static void kvm_vgic_dist_destroy(struct kvm *kvm)
> {
> struct vgic_dist *dist = &kvm->arch.vgic;
>
> - mutex_lock(&kvm->lock);
> -
> dist->ready = false;
> dist->initialized = false;
>
> kfree(dist->spis);
> dist->nr_spis = 0;
> -
> - mutex_unlock(&kvm->lock);
> }
>
> void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
> @@ -286,7 +282,8 @@ void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
> INIT_LIST_HEAD(&vgic_cpu->ap_list_head);
> }
>
> -void kvm_vgic_destroy(struct kvm *kvm)
> +/* To be called with kvm->lock held */
> +static void __kvm_vgic_destroy(struct kvm *kvm)
> {
> struct kvm_vcpu *vcpu;
> int i;
> @@ -297,6 +294,13 @@ void kvm_vgic_destroy(struct kvm *kvm)
> kvm_vgic_vcpu_destroy(vcpu);
> }
>
> +void kvm_vgic_destroy(struct kvm *kvm)
> +{
> + mutex_lock(&kvm->lock);
> + __kvm_vgic_destroy(kvm);
> + mutex_unlock(&kvm->lock);
> +}
> +
> /**
> * vgic_lazy_init: Lazy init is only allowed if the GIC exposed to the guest
> * is a GICv2. A GICv3 must be explicitly initialized by the guest using the
> @@ -348,6 +352,10 @@ int kvm_vgic_map_resources(struct kvm *kvm)
> ret = vgic_v2_map_resources(kvm);
> else
> ret = vgic_v3_map_resources(kvm);
> +
> + if (ret)
> + __kvm_vgic_destroy(kvm);
> +
> out:
> mutex_unlock(&kvm->lock);
> return ret;
> diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
> index 9bab867..834137e 100644
> --- a/virt/kvm/arm/vgic/vgic-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-v2.c
> @@ -293,8 +293,6 @@ int vgic_v2_map_resources(struct kvm *kvm)
> dist->ready = true;
>
> out:
> - if (ret)
> - kvm_vgic_destroy(kvm);
> return ret;
> }
>
> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
> index 7df1b90..a4c7fff 100644
> --- a/virt/kvm/arm/vgic/vgic-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-v3.c
> @@ -308,8 +308,6 @@ int vgic_v3_map_resources(struct kvm *kvm)
> dist->ready = true;
>
> out:
> - if (ret)
> - kvm_vgic_destroy(kvm);
> return ret;
> }
>
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH] i2c: i2c-cadence: Don't register the adapter until it's ready
From: Wolfram Sang @ 2017-01-12 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <428e8fc8-8b23-8e2c-763e-d977aaa98691@mleia.com>
> Because the adapter registration i2c_add_adapter() can fail, information
> about the adapter initialization would be expected only in case of
> successful registration.
Exactly.
>
> The information sent to the kernel log buffer here is quite trivial,
> probably dev_info() can be just removed, but in any case it should be
> a separate change.
I am not sure I get you here, but to not have false positive success
messages, I'd think that should be all in one patch.
Regards,
Wolfram
^ permalink raw reply
* [PATCH v3 10/24] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
From: Tim Harvey @ 2017-01-12 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483755102-24785-11-git-send-email-steve_longerbeam@mentor.com>
On Fri, Jan 6, 2017 at 6:11 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> Add pinctrl groups for both GPT input capture channels.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index 967c3b8..495709f 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -457,6 +457,18 @@
> >;
> };
>
> + pinctrl_gpt_input_capture0: gptinputcapture0grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpt_input_capture1: gptinputcapture1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2 0x1b0b0
> + >;
> + };
> +
> pinctrl_spdif: spdifgrp {
> fsl,pins = <
> MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
> --
Steve,
These are not used anywhere.
Tim
^ permalink raw reply
* [PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-12 20:32 UTC (permalink / raw)
To: linux-arm-kernel
This adds a device tree definition file for LEGO MINDSTORMS EV3.
What is working:
* Pin muxing
* Pinconf
* GPIOs
* MicroSD card reader
* UART on input port 1
* Buttons
* LEDs
* Poweroff/reset
* Flash memory
* EEPROM
* USB host port
* USB peripheral port
What is not working/to be added later:
* Speaker - have patch submitted to get pwm-beeper working - maybe someday
it will have a real sound driver that uses PRU
* A/DC chip - have driver submitted and accepted - waiting for ack on
device tree bindings
* Display - waiting for "simple DRM" to be mainlined
* Bluetooth - needs new driver for sequencing power/enable/clock
* Input and output ports - need some sort of new phy or extcon driver as
well as PRU UART and PRU I2C drivers
* Battery indication - needs new power supply driver
Note on flash partitions:
These partitions are based on the official EV3 firmware from LEGO. It is
expected that most users of the mainline kernel on EV3 will be booting from
an SD card while retaining the official firmware in the flash memory.
Furthermore, the official firmware uses an ancient U-Boot (2009) that has
no device tree support. So, it makes sense to have this partition table in
the EV3 device tree file. In the unlikely case that anyone does create their
own firmware image with different partitioning, they can use a modern
U-Boot in their own firmware image that modifies the device tree with the
custom partitions.
Signed-off-by: David Lechner <david@lechnology.com>
---
v3 changes:
* required defconfig patches have been picked up in linux-davinci tree, so this
is the only patch left in the series
* Added aliases node for consistent naming of serial ports
* Added memory node
* Removed nodes that are not finalized yet
* Renamed button labels to match EV3 users manual
v2 changes:
* Dropped defconfig patches that have already been pick up
* Added some new defconfig patches
* Updated device tree file based on feedback and new available bindings
* Renamed file to include da850- prefix
* Changed button labels
* Fixed LED names
* Added beeper device for sound
* Added regulators for USB and A/DC
* Removed unused pinmux nodes
* Added pinconf for buttons
* Enabled pwms
* Used preferred bindings for flash partitions
* Added A/DC spi device
* Enabled USB
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/da850-lego-ev3.dts | 313 +++++++++++++++++++++++++++++++++++
2 files changed, 315 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/da850-lego-ev3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 78a94b7..1a19e7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -130,7 +130,8 @@ dtb-$(CONFIG_ARCH_CLPS711X) += \
dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-lcdk.dtb \
da850-enbw-cmc.dtb \
- da850-evm.dtb
+ da850-evm.dtb \
+ da850-lego-ev3.dtb
dtb-$(CONFIG_ARCH_DIGICOLOR) += \
cx92755_equinox.dtb
dtb-$(CONFIG_ARCH_EFM32) += \
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
new file mode 100644
index 0000000..7aaf902
--- /dev/null
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -0,0 +1,313 @@
+/*
+ * Device tree for LEGO MINDSTORMS EV3
+ *
+ * Copyright (C) 2017 David Lechner <david@lechnology.com>
+ *
+ * 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, version 2.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+
+#include "da850.dtsi"
+
+/ {
+ compatible = "lego,ev3", "ti,da850";
+ model = "LEGO MINDSTORMS EV3";
+
+ aliases {
+ serial1 = &serial1;
+ };
+
+ memory at c0000000 {
+ device_type = "memory";
+ reg = <0xc0000000 0x04000000>;
+ };
+
+ /*
+ * The buttons on the EV3 are mapped to keyboard keys.
+ */
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ label = "EV3 Brick Buttons";
+ pinctrl-names = "default";
+ pinctrl-0 = <&button_pins>, <&button_bias>;
+
+ center {
+ label = "Center";
+ linux,code = <KEY_ENTER>;
+ gpios = <&gpio 29 GPIO_ACTIVE_HIGH>;
+ };
+
+ left {
+ label = "Left";
+ linux,code = <KEY_LEFT>;
+ gpios = <&gpio 102 GPIO_ACTIVE_HIGH>;
+ };
+
+ back {
+ label = "Back";
+ linux,code = <KEY_BACKSPACE>;
+ gpios = <&gpio 106 GPIO_ACTIVE_HIGH>;
+ };
+
+ right {
+ label = "Right";
+ linux,code = <KEY_RIGHT>;
+ gpios = <&gpio 124 GPIO_ACTIVE_HIGH>;
+ };
+
+ down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio 126 GPIO_ACTIVE_HIGH>;
+ };
+
+ up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio 127 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ /*
+ * The EV3 has two built-in bi-color LEDs behind the buttons.
+ */
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ left_green {
+ label = "led0:green:brick-status";
+ /* GP6[13] */
+ gpios = <&gpio 103 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ right_red {
+ label = "led1:red:brick-status";
+ /* GP6[7] */
+ gpios = <&gpio 108 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ left_red {
+ label = "led0:red:brick-status";
+ /* GP6[12] */
+ gpios = <&gpio 109 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ right_green {
+ label = "led1:green:brick-status";
+ /* GP6[14] */
+ gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ /*
+ * The EV3 is powered down by turning off the main 5V supply.
+ */
+ gpio-poweroff {
+ compatible = "gpio-poweroff";
+ gpios = <&gpio 107 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&system_power_pin>;
+ };
+
+ /*
+ * This is a 5V current limiting regulator that is shared by USB,
+ * the sensor (input) ports, the motor (output) ports and the A/DC.
+ */
+ vcc5v: regulator1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v_pins>;
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio 101 0>;
+ over-current-gpios = <&gpio 99 GPIO_ACTIVE_LOW>;
+ enable-active-high;
+ regulator-boot-on;
+ };
+};
+
+&pmx_core {
+ status = "okay";
+
+ spi0_cs3_pin: pinmux_spi0_cs3_pin {
+ pinctrl-single,bits = <
+ /* CS3 */
+ 0xc 0x01000000 0x0f000000
+ >;
+ };
+
+ mmc0_cd_pin: pinmux_mmc0_cd {
+ pinctrl-single,bits = <
+ /* GP5[14] */
+ 0x2C 0x00000080 0x000000f0
+ >;
+ };
+
+ button_pins: pinmux_button_pins {
+ pinctrl-single,bits = <
+ /* GP1[13] */
+ 0x8 0x00000800 0x00000f00
+ /* GP6[10] */
+ 0x34 0x00800000 0x00f00000
+ /* GP6[6] */
+ 0x38 0x00000080 0x000000f0
+ /* GP7[12], GP7[14], GP7[15] */
+ 0x40 0x00808800 0x00f0ff00
+ >;
+ };
+
+ led_pins: pinmux_led_pins {
+ pinctrl-single,bits = <
+ /* GP6[12], GP6[13], GP6[14] */
+ 0x34 0x00008880 0x0000fff0
+ /* GP6[7] */
+ 0x38 0x00000008 0x0000000f
+ >;
+ };
+
+ system_power_pin: pinmux_system_power {
+ pinctrl-single,bits = <
+ /* GP6[11] */
+ 0x34 0x00080000 0x000f0000
+ >;
+ };
+
+ vcc5v_pins: pinmux_vcc5v {
+ pinctrl-single,bits = <
+ /* GP6[5] */
+ 0x40 0x00000080 0x000000f0
+ /* GP6[3] */
+ 0x4c 0x00008000 0x0000f000
+ >;
+ };
+};
+
+&pinconf {
+ status = "okay";
+
+ /* Buttons have external pulldown resistors */
+ button_bias: button-bias-groups {
+ disable {
+ groups = "cp5", "cp24", "cp25", "cp28";
+ bias-disable;
+ };
+ };
+};
+
+/* Input port 1 */
+&serial1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial1_rxtx_pins>;
+};
+
+&rtc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+
+ /*
+ * EEPROM contains the first stage bootloader, HW ID and Bluetooth MAC.
+ */
+ eeprom at 50 {
+ compatible = "at24,24c128";
+ pagesize = <64>;
+ read-only;
+ reg = <0x50>;
+ };
+};
+
+&wdt {
+ status = "okay";
+};
+
+&mmc0 {
+ status = "okay";
+ max-frequency = <50000000>;
+ bus-width = <4>;
+ cd-gpios = <&gpio 94 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin>;
+};
+
+&spi0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
+
+ flash at 0 {
+ compatible = "n25q128a13", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ ti,spi-wdelay = <8>;
+
+ /* Partitions are based on the official firmware from LEGO */
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition at 0 {
+ label = "U-Boot";
+ reg = <0 0x40000>;
+ };
+
+ partition at 40000 {
+ label = "U-Boot Env";
+ reg = <0x40000 0x10000>;
+ };
+
+ partition at 50000 {
+ label = "Kernel";
+ reg = <0x50000 0x200000>;
+ };
+
+ partition at 250000 {
+ label = "Filesystem";
+ reg = <0x250000 0xa50000>;
+ };
+
+ partition at cb0000 {
+ label = "Storage";
+ reg = <0xcb0000 0x2f0000>;
+ };
+ };
+ };
+};
+
+&gpio {
+ status = "okay";
+};
+
+&usb_phy {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+ vbus-supply = <&vcc5v>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] misc: sram: Introduce protect-exec region type
From: Dave Gerlach @ 2017-01-12 20:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
There are several instances when one would want to execute out of on-chip
SRAM, such as PM code on ARM platforms, so once again revisiting this
series to allow that in a generic manner. Seems that having a solution for
allowing SRAM to be mapped as executable will help clean up PM code on several
ARM platforms that are using ARM internal __arm_ioremap_exec API
and also open the door for PM support on new platforms like TI AM335x and
AM437x.
Previously a generic solution was attempted by introducing a memremap
executable API and then calling this from the generic sram driver here [1].
Russell King brought up the point that we should not just be mapping
memory as both writable and executable for security reasons which led to
the solution proposed in this series.
The generic SRAM driver already has a concept of "partitions" which can be
defined and flagged in the device tree, so this series introduces a new flag,
protect-exec, which indicates the region of SRAM that has been blocked out in
the DT is protected and executable. It will share the same capabilities of the
already present sram "pool" which will allow allocation through the use of the
genalloc framework but also be protected through the use of an "sram_exec_copy"
helper function to handle the copying of data to the space and also the page
attributes. In this context protected means the memory is managed such that
it is *either* writeable and non-executable or read-only and executable through
manipulation of the page attributes.
Unforunately, unlike the previously proposed solution, this is not a drop in
replacement for __arm_ioremap_exec, A large side effect of allocating
executable SRAM as this series does is that it will require rework for some
SRAM code as a lot of the assembly code I have seen makes use of PC relative
memory locations at the end of the code for local variables. This will no
longer be possible if we must maintain the read-only executable status of
the memory. If that's required then SRAM code will need to use pointers to
a separately allocated region of sram that is just a normal writable pool.
As mentioned in previous series I still see several platforms (at-91,
imx6, socfpga, omap3) that could make use of this although some rework may
be required unlike with the last solution, and it will be needed for the
forthcoming TI am335x and am437x PM code as portions of PM code are
moving in to drivers. An example of this in use can be seen at [2] in the
drivers/memory/ti-emif-sram.c and drivers/soc/ti/pm33xx.c files.
Regards,
Dave
[1] http://www.spinics.net/lists/linux-omap/msg132728.html
[2] https://github.com/dgerlach/linux-pm/tree/upstream/v4.10/sram-exec-copy-pm
Dave Gerlach (3):
misc: sram: Split sram data structures into local header
misc: sram: Introduce support code for protect-exec sram type
misc: sram: Integrate protect-exec reserved sram area type
Documentation/devicetree/bindings/sram/sram.txt | 6 ++
drivers/misc/Kconfig | 4 +
drivers/misc/Makefile | 1 +
drivers/misc/sram-exec.c | 105 ++++++++++++++++++++++++
drivers/misc/sram.c | 51 +++++-------
drivers/misc/sram.h | 58 +++++++++++++
include/linux/sram.h | 27 ++++++
7 files changed, 222 insertions(+), 30 deletions(-)
create mode 100644 drivers/misc/sram-exec.c
create mode 100644 drivers/misc/sram.h
create mode 100644 include/linux/sram.h
--
2.11.0
^ permalink raw reply
* [PATCH 1/3] misc: sram: Split sram data structures into local header
From: Dave Gerlach @ 2017-01-12 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112205220.26325-1-d-gerlach@ti.com>
In preparation of a coming file split of the sram driver, move the
common data structures into a local header file that can be shared
between files related to the sram driver.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
drivers/misc/sram.c | 30 ++----------------------------
drivers/misc/sram.h | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+), 28 deletions(-)
create mode 100644 drivers/misc/sram.h
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index b33ab8ce47ab..4ef5affd03d7 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -31,35 +31,9 @@
#include <linux/mfd/syscon.h>
#include <soc/at91/atmel-secumod.h>
-#define SRAM_GRANULARITY 32
-
-struct sram_partition {
- void __iomem *base;
-
- struct gen_pool *pool;
- struct bin_attribute battr;
- struct mutex lock;
-};
-
-struct sram_dev {
- struct device *dev;
- void __iomem *virt_base;
-
- struct gen_pool *pool;
- struct clk *clk;
+#include "sram.h"
- struct sram_partition *partition;
- u32 partitions;
-};
-
-struct sram_reserve {
- struct list_head list;
- u32 start;
- u32 size;
- bool export;
- bool pool;
- const char *label;
-};
+#define SRAM_GRANULARITY 32
static ssize_t sram_read(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr,
diff --git a/drivers/misc/sram.h b/drivers/misc/sram.h
new file mode 100644
index 000000000000..52501a84468c
--- /dev/null
+++ b/drivers/misc/sram.h
@@ -0,0 +1,39 @@
+/*
+ * Defines for the SRAM driver
+ *
+ * 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 __SRAM_H
+#define __SRAM_H
+
+struct sram_partition {
+ void __iomem *base;
+
+ struct gen_pool *pool;
+ struct bin_attribute battr;
+ struct mutex lock;
+ struct list_head list;
+};
+
+struct sram_dev {
+ struct device *dev;
+ void __iomem *virt_base;
+
+ struct gen_pool *pool;
+ struct clk *clk;
+
+ struct sram_partition *partition;
+ u32 partitions;
+};
+
+struct sram_reserve {
+ struct list_head list;
+ u32 start;
+ u32 size;
+ bool export;
+ bool pool;
+ const char *label;
+};
+#endif /* __SRAM_H */
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] misc: sram: Introduce support code for protect-exec sram type
From: Dave Gerlach @ 2017-01-12 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112205220.26325-1-d-gerlach@ti.com>
Some platforms, like many ARM SoCs, require the ability to run code from
on-chip memory like SRAM for tasks like reconfiguring the SDRAM
controller or entering low-power sleep modes. In order to do this we
must be able to allocate memory that the code can be copied to but then
change the mapping to be read-only and executable so that no memory is
both writable and executable at the same time to avoid opening any
unneccesary security holes.
By using the existing "pool" partition type that the SRAM driver allows
we can create a memory space that will already be exposed by the
genalloc framework to allow for allocating memory but we must extend
this to meet the executable requirements. By making use of various
set_memory_* APIs we can change the attributes of pages to make them
writable for code upload but then read-only and executable when we want
to actually run code. Because SRAM is a shared resource we need a
centralized manager of these set memory calls. Because the SRAM driver
itself is responsible for allocating the memory we can introduce a
sram_copy_exec API for the driver that works like memcpy but also
manages the page attributes and locking to allow multiple users of the
same SRAM space to all copy their code over independent of other each
before starting execution.
It is maintained in a separate file from the core SRAM driver to allow
it to be selectively built depending on whether or not a platform has
the appropriate set_memory_* APIs. A future patch will integrate it with
the core SRAM driver.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
drivers/misc/sram-exec.c | 105 +++++++++++++++++++++++++++++++++++++++++++++++
drivers/misc/sram.h | 18 ++++++++
include/linux/sram.h | 27 ++++++++++++
3 files changed, 150 insertions(+)
create mode 100644 drivers/misc/sram-exec.c
create mode 100644 include/linux/sram.h
diff --git a/drivers/misc/sram-exec.c b/drivers/misc/sram-exec.c
new file mode 100644
index 000000000000..ac522417c462
--- /dev/null
+++ b/drivers/misc/sram-exec.c
@@ -0,0 +1,105 @@
+/*
+ * SRAM protect-exec region helper functions
+ *
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ * Dave Gerlach
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/genalloc.h>
+#include <linux/sram.h>
+
+#include <asm/cacheflush.h>
+
+#include "sram.h"
+
+static DEFINE_MUTEX(exec_pool_list_mutex);
+static LIST_HEAD(exec_pool_list);
+
+int sram_check_protect_exec(struct sram_dev *sram, struct sram_reserve *block,
+ struct sram_partition *part)
+{
+ unsigned long base = (unsigned long)part->base;
+ unsigned long end = base + block->size;
+
+ if (!PAGE_ALIGNED(base) || !PAGE_ALIGNED(end)) {
+ dev_err(sram->dev,
+ "SRAM pool marked with 'protect-exec' is not page aligned and will not be created.\n");
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+int sram_add_protect_exec(struct sram_partition *part)
+{
+ mutex_lock(&exec_pool_list_mutex);
+ list_add_tail(&part->list, &exec_pool_list);
+ mutex_unlock(&exec_pool_list_mutex);
+
+ return 0;
+}
+
+/**
+ * sram_exec_copy - copy data to a protected executable region of sram
+ *
+ * @pool: struct gen_pool retrieved that is part of this sram
+ * @dst: Destination address for the copy, that must be inside pool
+ * @src: Source address for the data to copy
+ * @size: Size of copy to perform, which starting from dst, must reside in pool
+ *
+ * This helper function allows sram driver to act as central control location
+ * of 'protect-exec' pools which are normal sram pools but are always set
+ * read-only and executable except when copying data to them, at which point
+ * they are set to read-write non-executable, to make sure no memory is
+ * writeable and executable at the same time. This region must be page-aligned
+ * and is checked during probe, otherwise page attribute manipulation would
+ * not be possible.
+ */
+int sram_exec_copy(struct gen_pool *pool, void *dst, void *src,
+ size_t size)
+{
+ struct sram_partition *part = NULL, *p;
+ unsigned long base;
+ int pages;
+
+ mutex_lock(&exec_pool_list_mutex);
+ list_for_each_entry(p, &exec_pool_list, list) {
+ if (p->pool == pool)
+ part = p;
+ }
+ mutex_unlock(&exec_pool_list_mutex);
+
+ if (!part)
+ return -EINVAL;
+
+ if (!addr_in_gen_pool(pool, (unsigned long)dst, size))
+ return -EINVAL;
+
+ base = (unsigned long)part->base;
+ pages = PAGE_ALIGN(size) / PAGE_SIZE;
+
+ mutex_lock(&part->lock);
+
+ set_memory_nx((unsigned long)base, pages);
+ set_memory_rw((unsigned long)base, pages);
+
+ memcpy(dst, src, size);
+
+ set_memory_ro((unsigned long)base, pages);
+ set_memory_x((unsigned long)base, pages);
+
+ mutex_unlock(&part->lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(sram_exec_copy);
diff --git a/drivers/misc/sram.h b/drivers/misc/sram.h
index 52501a84468c..b268cd3f55bb 100644
--- a/drivers/misc/sram.h
+++ b/drivers/misc/sram.h
@@ -36,4 +36,22 @@ struct sram_reserve {
bool pool;
const char *label;
};
+
+#ifdef CONFIG_SRAM_EXEC
+int sram_check_protect_exec(struct sram_dev *sram, struct sram_reserve *block,
+ struct sram_partition *part);
+int sram_add_protect_exec(struct sram_partition *part);
+#else
+static inline int sram_check_protect_exec(struct sram_dev *sram,
+ struct sram_reserve *block,
+ struct sram_partition *part)
+{
+ return -ENODEV;
+}
+
+static inline int sram_add_protect_exec(struct sram_partition *part)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_SRAM_EXEC */
#endif /* __SRAM_H */
diff --git a/include/linux/sram.h b/include/linux/sram.h
new file mode 100644
index 000000000000..c97dcbe8ce25
--- /dev/null
+++ b/include/linux/sram.h
@@ -0,0 +1,27 @@
+/*
+ * Generic SRAM Driver Interface
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef __LINUX_SRAM_H__
+#define __LINUX_SRAM_H__
+
+struct gen_pool;
+
+#ifdef CONFIG_SRAM_EXEC
+int sram_exec_copy(struct gen_pool *pool, void *dst, void *src, size_t size);
+#else
+static inline int sram_exec_copy(struct gen_pool *pool, void *dst, void *src,
+ size_t size)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_SRAM_EXEC */
+#endif /* __LINUX_SRAM_H__ */
--
2.11.0
^ permalink raw reply related
* [PATCH 3/3] misc: sram: Integrate protect-exec reserved sram area type
From: Dave Gerlach @ 2017-01-12 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112205220.26325-1-d-gerlach@ti.com>
Introduce a new "protect-exec" reserved sram area type which is
makes use of the the existing functionality provided for the "pool"
sram region type for use with the genalloc framework and with the
added requirement that it be maintained as read-only and executable
while allowing for an arbitrary number of drivers to share the space.
This introduces a common way to maintain a region of sram as read-only
and executable and also introduces a helper function, sram_exec_copy,
which allows for copying data to this protected region while maintaining
locking to avoid conflicts between multiple users of the same space. A
region of memory that is marked with the "protect-exec" flag in the
device tree also has the requirement of providing a page aligned block
of memory so that the page attribute manipulation does not affect
surrounding regions.
Also, selectively enable this only for builds that support set_memory_*
calls, for now just ARM, through the use of Kconfig.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
Documentation/devicetree/bindings/sram/sram.txt | 6 ++++++
drivers/misc/Kconfig | 4 ++++
drivers/misc/Makefile | 1 +
drivers/misc/sram.c | 21 +++++++++++++++++++--
drivers/misc/sram.h | 1 +
5 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sram/sram.txt b/Documentation/devicetree/bindings/sram/sram.txt
index 068c2c03c38f..267da4410aef 100644
--- a/Documentation/devicetree/bindings/sram/sram.txt
+++ b/Documentation/devicetree/bindings/sram/sram.txt
@@ -42,6 +42,12 @@ Optional properties in the area nodes:
and in use by another device or devices
- export : indicates that the reserved SRAM area may be accessed outside
of the kernel, e.g. by bootloader or userspace
+- protect-exec : Same as 'pool' above but with the additional
+ constraint that code wil be run from the region and
+ that the memory is maintained as read-only, executable
+ during code execution. NOTE: This region must be page
+ aligned on start and end in order to properly allow
+ manipulation of the page attributes.
- label : the name for the reserved partition, if omitted, the label
is taken from the node name excluding the unit address.
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 64971baf11fa..0444a8f9b094 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -474,11 +474,15 @@ config SRAM
bool "Generic on-chip SRAM driver"
depends on HAS_IOMEM
select GENERIC_ALLOCATOR
+ select SRAM_EXEC if ARM
help
This driver allows you to declare a memory region to be managed by
the genalloc API. It is supposed to be used for small on-chip SRAM
areas found on many SoCs.
+config SRAM_EXEC
+ bool
+
config VEXPRESS_SYSCFG
bool "Versatile Express System Configuration driver"
depends on VEXPRESS_CONFIG
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 31983366090a..7a3ea89339b4 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_INTEL_MEI) += mei/
obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
obj-$(CONFIG_SRAM) += sram.o
+obj-$(CONFIG_SRAM_EXEC) += sram-exec.o
obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 4ef5affd03d7..15792970edf6 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -122,6 +122,18 @@ static int sram_add_partition(struct sram_dev *sram, struct sram_reserve *block,
if (ret)
return ret;
}
+ if (block->protect_exec) {
+ ret = sram_check_protect_exec(sram, block, part);
+ if (ret)
+ return ret;
+
+ ret = sram_add_pool(sram, block, start, part);
+ if (ret)
+ return ret;
+
+ sram_add_protect_exec(part);
+ }
+
sram->partitions++;
return 0;
@@ -207,7 +219,11 @@ static int sram_reserve_regions(struct sram_dev *sram, struct resource *res)
if (of_find_property(child, "pool", NULL))
block->pool = true;
- if ((block->export || block->pool) && block->size) {
+ if (of_find_property(child, "protect-exec", NULL))
+ block->protect_exec = true;
+
+ if ((block->export || block->pool || block->protect_exec) &&
+ block->size) {
exports++;
label = NULL;
@@ -267,7 +283,8 @@ static int sram_reserve_regions(struct sram_dev *sram, struct resource *res)
goto err_chunks;
}
- if ((block->export || block->pool) && block->size) {
+ if ((block->export || block->pool || block->protect_exec) &&
+ block->size) {
ret = sram_add_partition(sram, block,
res->start + block->start);
if (ret) {
diff --git a/drivers/misc/sram.h b/drivers/misc/sram.h
index b268cd3f55bb..c181ce4c8fca 100644
--- a/drivers/misc/sram.h
+++ b/drivers/misc/sram.h
@@ -34,6 +34,7 @@ struct sram_reserve {
u32 size;
bool export;
bool pool;
+ bool protect_exec;
const char *label;
};
--
2.11.0
^ permalink raw reply related
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-12 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112174902.j52foglkdouyz36n@pengutronix.de>
2017-01-12 18:49 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> On Thu, Jan 12, 2017 at 02:47:42PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-12 13:03 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> > Hello Cedric,
>> >
>> > On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
>> >> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> >> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
>> >> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> >> >> > This is surprising. I didn't recheck the manual, but that looks very
>> >> >> > uncomfortable.
>> >> >>
>> >> >> I agree but this exactly the hardware way of working described in the
>> >> >> reference manual.
>> >> >
>> >> > IMHO that's a hw bug. This makes it for example impossible to implement
>> >> > SMBus block transfers (I think).
>> >>
>> >> This is not correct.
>> >> Setting STOP/START bit does not mean the the pulse will be sent right now.
>> >> Here we have just to prepare the hardware for the 2 next pulse but the
>> >> STOP/START/ACK pulse will be generated at the right time as required
>> >> by I2C specification.
>> >> So SMBus block transfer will be possible.
>> >
>> > A block transfer consists of a byte that specifies the count of bytes
>> > yet to come. So the device sends for example:
>> >
>> > 0x01 0xab
>> >
>> > So when you read the 1 in the first byte it's already too late to set
>> > STOP to get it after the 2nd byte.
>> >
>> > Not sure I got all the required details right, though.
>>
>> Ok I understand your use case but I always think that the harware manages it.
>> If I take the above example, the I2C SMBus block read transaction will
>> be as below:
>> S Addr Wr [A] Comm [A]
>> S Addr Rd [A] [Count] A [Data1] A [Data2] NA P
>>
>> The first message is a single byte-transmission so there is no problem.
>>
>> The second message is a N-byte reception with N = 3
>>
>> When the I2C controller has finished to send the device address (S
>> Addr Rd), the ADDR flag is set and an interrupt is raised.
>> In the routine that handles ADDR event, we set ACK bit in order to
>> generate ACK pulse as soon as a data byte is received in the shift
>> register and then we clear the ADDR flag.
>> Please note that the SCL line is stretched low until ADDR flag is cleared.
>> So, as far I understand, the device could not sent any data as long as
>> the SCL line is stretched low. Right ?
>>
>> Then, as soon as the SCL line is high, the device could send the first
>> data byte (Count).
>> When this byte is received in the shift register, an ACK is
>> automatically generated as defined during adress match phase and the
>> data byte is pushed in DR (data register).
>> Then, an interrupt is raised as RXNE (RX not empty) flag is set.
>> In the routine that handles RXNE event, as N=3, we just clear all
>> buffer interrupts in order to avoid another system preemption due to
>> RXNE event but we does not read the data in DR.
>
> In my example I want to receive a block of length 1, so only two bytes
> are read, a 1 (the length) and the data byte (0xab in my example). I
> think that as soon as you read the 1 it's already to late to schedule
> the NA after the next byte?
Not really. This 2-byte reception is also correctly managed.
Indeed, in this case, when the controller has sent the device address,
the ADDR flag is set and an interrupt is raised.
So, as long as the ADDR flag is not cleared, the SCL line is stretched
low and the device could not send any data.
During this address match phase, for a 2-byte reception, we enable
NACK and set POS bit (ACK/NACK position).
As POS=1, the NACK will be sent for the next byte which will be
received in the shift register instead of the current one.
So in this example, the next byte will be the last one.
After that, we clear the ADDR flag and the device is allowed to send data.
When the first data is received in the shift register, the RXNE flag
is set and an interrupt is raised.
As it is a 2-byte reception, we just clear all interrupts buffer to
avoid another preemption due to RXNE but we does not read DR.
Then, the second and last byte is received in the shift register.
The NACK is automatically sent by I2C controller as it was configured
to do that in the address match phase described above.
Moereover, as the first byte has not been read in DR, the BTF event
flag is set and an interrupt is raised.
Again, the SCL line is stretching low as long as data register has not
been read.
In the meantime, we set STOP bit to generate the pulse and we launch 2
consecutive read of DR to retrieve the 2 data bytes and release SCL
stretching.
In that way, NA and STOP are generated as expected even for a 2-byte reception.
Best regards,
Cedric
^ permalink raw reply
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: Uwe Kleine-König @ 2017-01-12 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn3tPi0fjy+t-UhMTvAq7LfdKJJdbcLw2su1-YAGDZMxew@mail.gmail.com>
On Thu, Jan 12, 2017 at 09:58:23PM +0100, M'boumba Cedric Madianga wrote:
> 2017-01-12 18:49 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > On Thu, Jan 12, 2017 at 02:47:42PM +0100, M'boumba Cedric Madianga wrote:
> >> 2017-01-12 13:03 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> >> > Hello Cedric,
> >> >
> >> > On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
> >> >> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> >> >> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
> >> >> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> >> >> >> > This is surprising. I didn't recheck the manual, but that looks very
> >> >> >> > uncomfortable.
> >> >> >>
> >> >> >> I agree but this exactly the hardware way of working described in the
> >> >> >> reference manual.
> >> >> >
> >> >> > IMHO that's a hw bug. This makes it for example impossible to implement
> >> >> > SMBus block transfers (I think).
> >> >>
> >> >> This is not correct.
> >> >> Setting STOP/START bit does not mean the the pulse will be sent right now.
> >> >> Here we have just to prepare the hardware for the 2 next pulse but the
> >> >> STOP/START/ACK pulse will be generated at the right time as required
> >> >> by I2C specification.
> >> >> So SMBus block transfer will be possible.
> >> >
> >> > A block transfer consists of a byte that specifies the count of bytes
> >> > yet to come. So the device sends for example:
> >> >
> >> > 0x01 0xab
> >> >
> >> > So when you read the 1 in the first byte it's already too late to set
> >> > STOP to get it after the 2nd byte.
> >> >
> >> > Not sure I got all the required details right, though.
> >>
> >> Ok I understand your use case but I always think that the harware manages it.
> >> If I take the above example, the I2C SMBus block read transaction will
> >> be as below:
> >> S Addr Wr [A] Comm [A]
> >> S Addr Rd [A] [Count] A [Data1] A [Data2] NA P
> >>
> >> The first message is a single byte-transmission so there is no problem.
> >>
> >> The second message is a N-byte reception with N = 3
> >>
> >> When the I2C controller has finished to send the device address (S
> >> Addr Rd), the ADDR flag is set and an interrupt is raised.
> >> In the routine that handles ADDR event, we set ACK bit in order to
> >> generate ACK pulse as soon as a data byte is received in the shift
> >> register and then we clear the ADDR flag.
> >> Please note that the SCL line is stretched low until ADDR flag is cleared.
> >> So, as far I understand, the device could not sent any data as long as
> >> the SCL line is stretched low. Right ?
> >>
> >> Then, as soon as the SCL line is high, the device could send the first
> >> data byte (Count).
> >> When this byte is received in the shift register, an ACK is
> >> automatically generated as defined during adress match phase and the
> >> data byte is pushed in DR (data register).
> >> Then, an interrupt is raised as RXNE (RX not empty) flag is set.
> >> In the routine that handles RXNE event, as N=3, we just clear all
> >> buffer interrupts in order to avoid another system preemption due to
> >> RXNE event but we does not read the data in DR.
> >
> > In my example I want to receive a block of length 1, so only two bytes
> > are read, a 1 (the length) and the data byte (0xab in my example). I
> > think that as soon as you read the 1 it's already to late to schedule
> > the NA after the next byte?
>
> Not really. This 2-byte reception is also correctly managed.
> Indeed, in this case, when the controller has sent the device address,
> the ADDR flag is set and an interrupt is raised.
> So, as long as the ADDR flag is not cleared, the SCL line is stretched
> low and the device could not send any data.
> During this address match phase, for a 2-byte reception, we enable
> NACK and set POS bit (ACK/NACK position).
> As POS=1, the NACK will be sent for the next byte which will be
> received in the shift register instead of the current one.
> So in this example, the next byte will be the last one.
> After that, we clear the ADDR flag and the device is allowed to send data.
I didn't follow, but if you are convinced it works that's good. I wonder
if it simplifies the driver if POS=1 is used and so ACK/NACK can be
setup later?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH net-next v2 05/10] drivers: base: Add device_find_class()
From: David Miller @ 2017-01-12 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112034121.27697-6-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 11 Jan 2017 19:41:16 -0800
> Add a helper function to lookup a device reference given a class name.
> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
> make it more generic.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/base/core.c | 19 +++++++++++++++++++
> include/linux/device.h | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 020ea7f05520..3dd6047c10d8 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2065,6 +2065,25 @@ struct device *device_find_child(struct device *parent, void *data,
> }
> EXPORT_SYMBOL_GPL(device_find_child);
>
> +static int dev_is_class(struct device *dev, void *class)
I know you are just moving code, but this class argumnet is a string
and thus should be "char *" or even "const char *".
^ permalink raw reply
* [PATCH 0/4] video: ARM CLCD: add support of an optional GPIO to enable panel
From: Vladimir Zapolskiy @ 2017-01-12 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZdzGq8Atk2YMa23ZLRjnVGYBYQjEzu_q__s-yYkWg5hA@mail.gmail.com>
On 01/12/2017 10:27 AM, Linus Walleij wrote:
> On Thu, Jan 12, 2017 at 1:05 AM, Vladimir Zapolskiy <vz@mleia.com> wrote:
>> On 01/11/2017 05:16 PM, Linus Walleij wrote:
>>> On Tue, Jan 10, 2017 at 2:47 PM, Vladimir Murzin
>>> <vladimir.murzin@arm.com> wrote:
>>>
>>>> In another thread Benjamin pointed at patch [1] in drm/kms part for noMMU.
>>>>
>>>> [1] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=62a0d98a188cc4ebd8ea54b37d274ec20465e464
>>>
>>> Problem solved?
>>>
>>> Vladimir: I do not require in any way that you create a CLCD driver for DRM,
>>> I just think it would be very very nice...
>>>
>>
>> I have no other option, this series is unreviewed and thus unlikely it will
>> be applied, still a panel PCB on my board needs power management support.
>
> Hm I can ACK it I guess, but mergeing it into an unmaintained subsystem
> is another issue, just not very optimal.
+ Bartlomiej
Linus, your ack is always more than appreciated.
To all appearance Bartlomiej is a new honoured framebuffer layer maintainer.
Bartlomiej, do you have the changes under discussion in your mailbox or
should I resend them to you directly for review?
> If you get it working on your system I can look into migrating all the old
> users to DRM as well.
>
Sure, I started development of a simple CLCD DRM driver as an own attractive
exercise, I'll keep you informed of the progress.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-12 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112211004.z3wylc7vrubulc3x@pengutronix.de>
2017-01-12 22:10 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> On Thu, Jan 12, 2017 at 09:58:23PM +0100, M'boumba Cedric Madianga wrote:
>> 2017-01-12 18:49 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> > On Thu, Jan 12, 2017 at 02:47:42PM +0100, M'boumba Cedric Madianga wrote:
>> >> 2017-01-12 13:03 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> >> > Hello Cedric,
>> >> >
>> >> > On Thu, Jan 12, 2017 at 12:23:12PM +0100, M'boumba Cedric Madianga wrote:
>> >> >> 2017-01-11 16:39 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> >> >> > On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote:
>> >> >> >> 2017-01-11 9:22 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> >> >> >> > This is surprising. I didn't recheck the manual, but that looks very
>> >> >> >> > uncomfortable.
>> >> >> >>
>> >> >> >> I agree but this exactly the hardware way of working described in the
>> >> >> >> reference manual.
>> >> >> >
>> >> >> > IMHO that's a hw bug. This makes it for example impossible to implement
>> >> >> > SMBus block transfers (I think).
>> >> >>
>> >> >> This is not correct.
>> >> >> Setting STOP/START bit does not mean the the pulse will be sent right now.
>> >> >> Here we have just to prepare the hardware for the 2 next pulse but the
>> >> >> STOP/START/ACK pulse will be generated at the right time as required
>> >> >> by I2C specification.
>> >> >> So SMBus block transfer will be possible.
>> >> >
>> >> > A block transfer consists of a byte that specifies the count of bytes
>> >> > yet to come. So the device sends for example:
>> >> >
>> >> > 0x01 0xab
>> >> >
>> >> > So when you read the 1 in the first byte it's already too late to set
>> >> > STOP to get it after the 2nd byte.
>> >> >
>> >> > Not sure I got all the required details right, though.
>> >>
>> >> Ok I understand your use case but I always think that the harware manages it.
>> >> If I take the above example, the I2C SMBus block read transaction will
>> >> be as below:
>> >> S Addr Wr [A] Comm [A]
>> >> S Addr Rd [A] [Count] A [Data1] A [Data2] NA P
>> >>
>> >> The first message is a single byte-transmission so there is no problem.
>> >>
>> >> The second message is a N-byte reception with N = 3
>> >>
>> >> When the I2C controller has finished to send the device address (S
>> >> Addr Rd), the ADDR flag is set and an interrupt is raised.
>> >> In the routine that handles ADDR event, we set ACK bit in order to
>> >> generate ACK pulse as soon as a data byte is received in the shift
>> >> register and then we clear the ADDR flag.
>> >> Please note that the SCL line is stretched low until ADDR flag is cleared.
>> >> So, as far I understand, the device could not sent any data as long as
>> >> the SCL line is stretched low. Right ?
>> >>
>> >> Then, as soon as the SCL line is high, the device could send the first
>> >> data byte (Count).
>> >> When this byte is received in the shift register, an ACK is
>> >> automatically generated as defined during adress match phase and the
>> >> data byte is pushed in DR (data register).
>> >> Then, an interrupt is raised as RXNE (RX not empty) flag is set.
>> >> In the routine that handles RXNE event, as N=3, we just clear all
>> >> buffer interrupts in order to avoid another system preemption due to
>> >> RXNE event but we does not read the data in DR.
>> >
>> > In my example I want to receive a block of length 1, so only two bytes
>> > are read, a 1 (the length) and the data byte (0xab in my example). I
>> > think that as soon as you read the 1 it's already to late to schedule
>> > the NA after the next byte?
>>
>> Not really. This 2-byte reception is also correctly managed.
>> Indeed, in this case, when the controller has sent the device address,
>> the ADDR flag is set and an interrupt is raised.
>> So, as long as the ADDR flag is not cleared, the SCL line is stretched
>> low and the device could not send any data.
>> During this address match phase, for a 2-byte reception, we enable
>> NACK and set POS bit (ACK/NACK position).
>> As POS=1, the NACK will be sent for the next byte which will be
>> received in the shift register instead of the current one.
>> So in this example, the next byte will be the last one.
>> After that, we clear the ADDR flag and the device is allowed to send data.
>
> I didn't follow, but if you are convinced it works that's good. I wonder
> if it simplifies the driver if POS=1 is used and so ACK/NACK can be
> setup later?
Please see below a quote from datasheet that clearly described how to handle
For 2-byte reception:
? Wait until ADDR = 1 (SCL stretched low until the ADDR flag is cleared)
? Set ACK low, set POS high
? Clear ADDR flag
? Wait until BTF = 1 (Data 1 in DR, Data2 in shift register, SCL
stretched low until a data1 is read)
? Set STOP high
? Read data 1 and 2
So we cannot set POS=1 and setup ACK/NACK later as you suggest.
Best regards,
Cedric
^ permalink raw reply
* [RESEND] spi: davinci: Allow device tree devices to use DMA
From: Kevin Hilman @ 2017-01-12 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483673177-31516-1-git-send-email-david@lechnology.com>
David Lechner <david@lechnology.com> writes:
> This allows SPI devices specified in a device tree to use DMA when the
> master controller.
Enabling DMA for spi-davinci isn't quite ready yet since this driver is
blindly using dma_map_single() on addresses passed in. MTD seems to use
vmalloc'd buffers, which cannot be passed direclty to dma_map_single().
I thinks this driver needs an update to use spi_map_buf() to be able to
handle vmalloc'd buffers before always enabling DMA.
Kevin
^ permalink raw reply
* [PATCH -next] soc: ti: wkup_m3_ipc: Fix error return code in wkup_m3_ipc_probe()
From: Tony Lindgren @ 2017-01-12 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112145341.783-1-weiyj.lk@gmail.com>
* Wei Yongjun <weiyj.lk@gmail.com> [170112 06:55]:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix to return a negative error code from the kthread_run() error
> handling case instead of 0, as done elsewhere in this function.
>
> Fixes: cdd5de500b2c ("soc: ti: Add wkup_m3_ipc driver")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/soc/ti/wkup_m3_ipc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
> index 8bfa44b..369aef5 100644
> --- a/drivers/soc/ti/wkup_m3_ipc.c
> +++ b/drivers/soc/ti/wkup_m3_ipc.c
> @@ -457,6 +457,7 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
>
> if (IS_ERR(task)) {
> dev_err(dev, "can't create rproc_boot thread\n");
> + ret = PTR_ERR(task);
> goto err_put_rproc;
> }
>
>
Applying into omap-for-v4.10/fixes thanks.
Tony
^ 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