* [PATCH v3] drivers: psci: PSCI checker module
From: Paul E. McKenney @ 2016-10-27 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a3fd021e-1fae-08e3-994b-87efcf11b164@arm.com>
On Thu, Oct 27, 2016 at 01:51:57PM +0100, Kevin Brodsky wrote:
> On 27/10/16 10:13, Lorenzo Pieralisi wrote:
> >On Wed, Oct 26, 2016 at 11:11:48AM -0700, Paul E. McKenney wrote:
> >>On Wed, Oct 26, 2016 at 06:35:34PM +0100, Lorenzo Pieralisi wrote:
> >>>On Wed, Oct 26, 2016 at 10:22:52AM -0700, Paul E. McKenney wrote:
> >>>>On Wed, Oct 26, 2016 at 06:10:06PM +0100, Lorenzo Pieralisi wrote:
> >>[ . . . ]
> >>
> >>>>>Thanks a lot for your feedback, thoughts appreciated.
> >>>>Let me ask the question more directly.
> >>>>
> >>>>Why on earth are we trying to run these tests concurrently?
> >>>We must prevent that, no question about that, that's why I started
> >>>this discussion. It is not fine to enable this checker and the
> >>>RCU/LOCK torture hotplug tests at the same time.
> >>>
> >>>>After all, if we just run one at a time in isolation, there is no
> >>>>problem.
> >>>Fine by me, it was to understand if the current assumptions we made
> >>>are correct and they are definitely not. If we enable the PSCI checker
> >>>we must disable the torture rcu/lock hotplug tests either statically or
> >>>dynamically.
> >>What rcutorture, locktorture, and rcuperf do is to invoke
> >>torture_init_begin(), which returns false if one of these tests
> >>is already running.
> >>
> >>Perhaps we should extract this torture-test-exclusion and require
> >>than conflicting torture tests invoke it?
> >Yes if it can be extracted as a check (but it should also prevent the
> >torture tests from running and vice versa), either that or Kconfig
> >dependency (which we could do as a first step, waiting to add the
> >required interface to the torture test code ?).
> >
> >Thanks !
> >Lorenzo
>
> That sounds like a reasonable idea, but then that would mean that the PSCI checker
> would have to wait until the torture test is finished if it is already running (and
> the other way around).
>
> I wasn't aware that torture tests were hotplugging CPUs. I think that the most
> sensible thing to do right now is to make CONFIG_PSCI_CHECKER depend on
> !CONFIG_TORTURE_TEST (or maybe specifically !CONFIG_RCU_TORTURE_TEST &&
> !CONFIG_LOCK_TORTURE_TEST). We can try to make them work together afterwards, but for
> the sake of getting this patch merged in a reasonable amount of time, I think we
> should just exclude the conflicting tests at the build level in this patch. I'll also
> update the comment accordingly.
I suggest !CONFIG_TORTURE_TEST, given that there are a couple of other
tests in the offing.
Thanx, Paul
> Thanks,
> Kevin
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
^ permalink raw reply
* [kernel-hardening] Re: [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Catalin Marinas @ 2016-10-27 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jKEpZgc9zqmX=QKs_NH70fX_4CRNEtFKXEETK6UwykNMw@mail.gmail.com>
On Fri, Sep 30, 2016 at 11:42:02AM -0700, Kees Cook wrote:
> On Thu, Sep 29, 2016 at 3:44 PM, Sami Tolvanen <samitolvanen@google.com> wrote:
> > On Thu, Sep 15, 2016 at 05:20:45PM +0100, Mark Rutland wrote:
> >> Likewise, how do we handle __flush_cache_user_range and
> >> flush_icache_range? Some callers (e.g. __do_compat_cache_op) pass in
> >> __user addresses.
> >
> > Also EXEC_USERSPACE in lkdtm passes a user space address to flush_icache_range
> > and causes the process to hang when I tested these patches on HiKey.
> >
> > Adding uaccess_{enable,disable}_not_uao to __flush_cache_user_range appears to
> > fix the problem.
>
> I had a thought just now on this: is lkdtm maybe doing the wrong thing
> here? i.e. should lkdtm be the one do to the uaccess_en/disable
> instead of flush_icache_range() itself, since it's the one abusing the
> API?
(preparing the v4 series)
I think lkdtm is using the API incorrectly here. The documentation for
flush_icache_range() (Documentation/cachetlb.txt) states that it is to
be used on kernel addresses. Even with uaccess_enable/disable in lkdtm,
faults on user space can still happen and the flush_icache_range()
function must be able to handle them. It happens to work on arm64
because of the fall through __flush_cache_user_range() but that's not
guaranteed on other architectures.
A potential solution is to use access_process_vm() and let the arch code
handle the cache maintenance automatically:
---------------------8<--------------------------------
>From fcbb7c9c30daf9bfc2a215ec10dba79c109ab835 Mon Sep 17 00:00:00 2001
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Thu, 27 Oct 2016 15:47:20 +0100
Subject: [PATCH] lkdtm: Do not use flush_icache_range() on user addresses
The flush_icache_range() API is meant to be used on kernel addresses
only as it may not have the infrastructure (exception entries) to handle
user memory faults.
The lkdtm execute_user_location() function tests the kernel execution of
user space addresses by mmap'ing an anonymous page, copying some code
together with cache maintenance and attempting to run it. However, the
cache maintenance step may fail because of the incorrect API usage
described above. The patch changes lkdtm to use access_process_vm() for
copying the code into user space which would take care of the necessary
cache maintenance.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
drivers/misc/lkdtm_perms.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/lkdtm_perms.c b/drivers/misc/lkdtm_perms.c
index 45f1c0f96612..c7635a79341f 100644
--- a/drivers/misc/lkdtm_perms.c
+++ b/drivers/misc/lkdtm_perms.c
@@ -60,15 +60,18 @@ static noinline void execute_location(void *dst, bool write)
static void execute_user_location(void *dst)
{
+ int copied;
+
/* Intentionally crossing kernel/user memory boundary. */
void (*func)(void) = dst;
pr_info("attempting ok execution at %p\n", do_nothing);
do_nothing();
- if (copy_to_user((void __user *)dst, do_nothing, EXEC_SIZE))
+ copied = access_process_vm(current, (unsigned long)dst, do_nothing,
+ EXEC_SIZE, FOLL_WRITE);
+ if (copied < EXEC_SIZE)
return;
- flush_icache_range((unsigned long)dst, (unsigned long)dst + EXEC_SIZE);
pr_info("attempting bad execution@%p\n", func);
func();
}
^ permalink raw reply related
* [RFC PATCH 1/5] of: introduce the overlay manager
From: Pantelis Antoniou @ 2016-10-27 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026145756.21689-2-antoine.tenart@free-electrons.com>
Hi Antoine,
> On Oct 26, 2016, at 17:57 , Antoine Tenart <antoine.tenart@free-electrons.com> wrote:
>
> The overlay manager is an in-kernel library helping to handle dt overlay
> loading when using capes.
>
All in all a nice idea. Comments inline.
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
> drivers/of/Kconfig | 2 +
> drivers/of/Makefile | 1 +
> drivers/of/overlay-manager/Kconfig | 6 +
> drivers/of/overlay-manager/Makefile | 1 +
> drivers/of/overlay-manager/overlay-manager.c | 199 +++++++++++++++++++++++++++
> include/linux/overlay-manager.h | 38 +++++
> 6 files changed, 247 insertions(+)
> create mode 100644 drivers/of/overlay-manager/Kconfig
> create mode 100644 drivers/of/overlay-manager/Makefile
> create mode 100644 drivers/of/overlay-manager/overlay-manager.c
> create mode 100644 include/linux/overlay-manager.h
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index bc07ad30c9bf..e57aeaf0bf4f 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -116,4 +116,6 @@ config OF_OVERLAY
> config OF_NUMA
> bool
>
> +source "drivers/of/overlay-manager/Kconfig"
> +
> endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index d7efd9d458aa..d738fd41271f 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.o
> obj-$(CONFIG_OF_NUMA) += of_numa.o
>
> obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> +obj-y += overlay-manager/
> diff --git a/drivers/of/overlay-manager/Kconfig b/drivers/of/overlay-manager/Kconfig
> new file mode 100644
> index 000000000000..eeb76054dcb8
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -0,0 +1,6 @@
> +config OF_OVERLAY_MGR
> + bool "Device Tree Overlay Manager"
> + depends on OF_OVERLAY
> + help
> + Enable the overlay manager to handle automatic overlay loading when
> + devices are detected.
> diff --git a/drivers/of/overlay-manager/Makefile b/drivers/of/overlay-manager/Makefile
> new file mode 100644
> index 000000000000..86d2b53950e7
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_OF_OVERLAY_MGR) += overlay-manager.o
> diff --git a/drivers/of/overlay-manager/overlay-manager.c b/drivers/of/overlay-manager/overlay-manager.c
> new file mode 100644
> index 000000000000..a725d7e24d38
> --- /dev/null
> +++ b/drivers/of/overlay-manager/overlay-manager.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart <antoine.tenart@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/firmware.h>
> +#include <linux/list.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/overlay-manager.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +struct overlay_mgr_overlay {
> + struct list_head list;
> + char *name;
> +};
> +
> +LIST_HEAD(overlay_mgr_overlays);
> +LIST_HEAD(overlay_mgr_formats);
> +DEFINE_SPINLOCK(overlay_mgr_lock);
> +DEFINE_SPINLOCK(overlay_mgr_format_lock);
> +
> +/*
> + * overlay_mgr_register_format()
> + *
> + * Adds a new format candidate to the list of supported formats. The registered
> + * formats are used to parse the headers stored on the dips.
> + */
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate)
> +{
> + struct overlay_mgr_format *format;
> + int err = 0;
> +
> + spin_lock(&overlay_mgr_format_lock);
> +
> + /* Check if the format is already registered */
> + list_for_each_entry(format, &overlay_mgr_formats, list) {
> + if (!strcpy(format->name, candidate->name)) {
> + err = -EEXIST;
> + goto err;
> + }
> + }
> +
> + list_add_tail(&candidate->list, &overlay_mgr_formats);
> +
> +err:
> + spin_unlock(&overlay_mgr_format_lock);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_register_format);
> +
> +/*
> + * overlay_mgr_parse()
> + *
> + * Parse raw data with registered format parsers. Fills the candidate string if
> + * one parser understood the raw data format.
> + */
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
> + unsigned *n)
> +{
> + struct list_head *pos, *tmp;
> + struct overlay_mgr_format *format;
> +
> + list_for_each_safe(pos, tmp, &overlay_mgr_formats) {
> + format = list_entry(pos, struct overlay_mgr_format, list);
> +
> + format->parse(dev, data, candidates, n);
> + if (n > 0)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_parse);
> +
> +static int overlay_mgr_check_overlay(struct device_node *node)
> +{
> + struct property *p;
> + const char *str = NULL;
> +
> + p = of_find_property(node, "compatible", NULL);
> + if (!p)
> + return -EINVAL;
> +
> + do {
> + str = of_prop_next_string(p, str);
> + if (of_machine_is_compatible(str))
> + return 0;
> + } while (str);
> +
> + return -EINVAL;
> +}
> +
> +/*
> + * _overlay_mgr_insert()
> + *
> + * Try to request and apply an overlay given a candidate name.
> + */
> +static int _overlay_mgr_apply(struct device *dev, char *candidate)
> +{
> + struct overlay_mgr_overlay *overlay;
> + struct device_node *node;
> + const struct firmware *firmware;
> + char *firmware_name;
> + int err = 0;
> +
> + spin_lock(&overlay_mgr_lock);
> +
> + list_for_each_entry(overlay, &overlay_mgr_overlays, list) {
> + if (!strcmp(overlay->name, candidate)) {
> + dev_err(dev, "overlay already loaded\n");
> + err = -EEXIST;
> + goto err_lock;
> + }
> + }
> +
> + overlay = devm_kzalloc(dev, sizeof(*overlay), GFP_KERNEL);
> + if (!overlay) {
> + err = -ENOMEM;
> + goto err_lock;
> + }
> +
> + overlay->name = candidate;
> +
> + firmware_name = kasprintf(GFP_KERNEL, "overlay-%s.dtbo", candidate);
> + if (!firmware_name) {
> + err = -ENOMEM;
> + goto err_free;
> + }
> +
> + dev_info(dev, "requesting firmware '%s'\n", firmware_name);
> +
> + err = request_firmware_direct(&firmware, firmware_name, dev);
> + if (err) {
> + dev_info(dev, "failed to request firmware '%s'\n",
> + firmware_name);
> + goto err_free;
> + }
> +
> + of_fdt_unflatten_tree((unsigned long *)firmware->data, NULL, &node);
> + if (!node) {
> + dev_err(dev, "failed to unflatted tree\n");
> + err = -EINVAL;
> + goto err_fw;
> + }
> +
> + of_node_set_flag(node, OF_DETACHED);
> +
> + err = of_resolve_phandles(node);
> + if (err) {
> + dev_err(dev, "failed to resolve phandles: %d\n", err);
> + goto err_fw;
> + }
> +
> + err = overlay_mgr_check_overlay(node);
> + if (err) {
> + dev_err(dev, "overlay checks failed: %d\n", err);
> + goto err_fw;
> + }
> +
> + err = of_overlay_create(node);
> + if (err < 0) {
> + dev_err(dev, "failed to create overlay: %d\n", err);
> + goto err_fw;
> + }
> +
> + list_add_tail(&overlay->list, &overlay_mgr_overlays);
> +
> + dev_info(dev, "loaded firmware '%s'\n", firmware_name);
> +
> + spin_unlock(&overlay_mgr_lock);
> + return 0;
> +
> +err_fw:
> + release_firmware(firmware);
> +err_free:
> + devm_kfree(dev, overlay);
> +err_lock:
> + spin_unlock(&overlay_mgr_lock);
> + return err;
> +}
> +
> +int overlay_mgr_apply(struct device *dev, char **candidates, unsigned n)
> +{
> + int i, ret;
> +
> + for (i=0; i < n; i++) {
> + ret = _overlay_mgr_apply(dev, candidates[i]);
> + if (!ret)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_apply);
> diff --git a/include/linux/overlay-manager.h b/include/linux/overlay-manager.h
> new file mode 100644
> index 000000000000..8adcc4f5ddf6
> --- /dev/null
> +++ b/include/linux/overlay-manager.h
> @@ -0,0 +1,38 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart <antoine.tenart@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __OVERLAY_MGR_H__
> +#define __OVERLAY_MGR_H__
> +
> +#include <linux/device.h>
> +#include <linux/list.h>
> +#include <linux/sizes.h>
> +
> +#define OVERLAY_MGR_DIP_MAX_SZ SZ_128
> +
This should not be here; if it?s general kernel plumbing no mention to
specific boards/archs are relevant.
> +struct overlay_mgr_format {
> + struct list_head list;
> + char *name;
> + int (*parse)(struct device *dev, void *data, char ***candidates,
> + unsigned *n);
> +};
> +
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate);
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
> + unsigned *n);
> +int overlay_mgr_apply(struct device *dev, char **candidates, unsigned n);
> +
> +#define dip_convert(field) \
> + ( \
> + (sizeof(field) == 1) ? field : \
> + (sizeof(field) == 2) ? be16_to_cpu(field) : \
> + (sizeof(field) == 4) ? be32_to_cpu(field) : \
> + -1 \
> + )
> +
Same as above.
> +#endif /* __OVERLAY_MGR_H__ */
> --
> 2.10.1
Regards
? Pantelis
^ permalink raw reply
* [SPAM][PATCH 2/3] irqchip: mtk-cirq: Add mediatek mtk-cirq implement
From: Yingjoe Chen @ 2016-10-27 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476335194-26604-3-git-send-email-youlin.pei@mediatek.com>
On Thu, 2016-10-13 at 13:06 +0800, Youlin Pei wrote:
> This commit add the mtk-cirq implement for mt2701.
>
> Signed-off-by: Youlin Pei <youlin.pei@mediatek.com>
> ---
> drivers/irqchip/Makefile | 2 +-
> drivers/irqchip/irq-mtk-cirq.c | 257 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 258 insertions(+), 1 deletion(-)
> create mode 100644 drivers/irqchip/irq-mtk-cirq.c
>
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 4c203b6..eee95c6 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -59,7 +59,7 @@ obj-$(CONFIG_BCM7120_L2_IRQ) += irq-bcm7120-l2.o
> obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
> obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
> obj-$(CONFIG_MIPS_GIC) += irq-mips-gic.o
> -obj-$(CONFIG_ARCH_MEDIATEK) += irq-mtk-sysirq.o
> +obj-$(CONFIG_ARCH_MEDIATEK) += irq-mtk-sysirq.o irq-mtk-cirq.o
> obj-$(CONFIG_ARCH_DIGICOLOR) += irq-digicolor.o
> obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
> obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
> diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c
> new file mode 100644
> index 0000000..544767d
> --- /dev/null
> +++ b/drivers/irqchip/irq-mtk-cirq.c
> @@ -0,0 +1,257 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: Youlin.Pei <youlin.pei@mediatek.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/irq.h>
> +#include <linux/irqchip.h>
> +#include <linux/irqdomain.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/syscore_ops.h>
> +
> +#define CIRQ_MASK_SET 0xC0
> +#define CIRQ_MASK_CLR 0x100
> +#define CIRQ_SENS_SET 0x180
> +#define CIRQ_SENS_CLR 0x1C0
nit: please use lower case for hex value
> +#define CIRQ_POL_SET 0x240
> +#define CIRQ_POL_CLR 0x280
> +#define CIRQ_CONTROL 0x300
> +
> +#define CIRQ_EN 0x1
nit: please align
> +#define CIRQ_EDGE 0x2
> +#define CIRQ_FLUSH 0x4
> +
> +#define CIRQ_IRQ_NUM 0x200
> +
> +struct mtk_cirq_chip_data {
> + void __iomem *base;
> + unsigned int ext_irq_start;
> +};
> +
<deleted..>
> +
> +static int __init mtk_cirq_of_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + struct irq_domain *domain, *domain_parent;
> + int ret;
> +
> + domain_parent = irq_find_host(parent);
> + if (!domain_parent) {
> + pr_err("mtk_cirq: interrupt-parent not found\n");
> + return -EINVAL;
> + }
> +
> + cirq_data = kzalloc(sizeof(*cirq_data), GFP_KERNEL);
> + if (!cirq_data)
> + return -ENOMEM;
> +
> + cirq_data->base = of_iomap(node, 0);
> + if (!cirq_data->base) {
> + pr_err("mtk_cirq: unable to map cirq register\n");
> + ret = -ENXIO;
> + goto out_free;
> + }
> +
> + if (of_property_read_u32(node, "mediatek,ext-irq-start",
> + &cirq_data->ext_irq_start)) {
> + ret = -EINVAL;
> + goto out_free;
Please propagate error returned from of_property_read_u32
Should goto out_unmap when fail here.
Joe.C
> + }
> +
> + domain = irq_domain_add_hierarchy(domain_parent, 0, CIRQ_IRQ_NUM, node,
> + &cirq_domain_ops, cirq_data);
> + if (!domain) {
> + ret = -ENOMEM;
> + goto out_unmap;
> + }
> +
> + mtk_cirq_syscore_init();
> +
> + return 0;
> +
> +out_unmap:
> + iounmap(cirq_data->base);
> +out_free:
> + kfree(cirq_data);
> + return ret;
> +}
> +
> +IRQCHIP_DECLARE(mtk_cirq, "mediatek,mt2701-cirq", mtk_cirq_of_init);
^ permalink raw reply
* [PATCH v7, 0/8] Add MediaTek USB3 DRD Driver
From: Greg Kroah-Hartman @ 2016-10-27 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476844107-31087-1-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Oct 19, 2016 at 10:28:19AM +0800, Chunfeng Yun wrote:
> These patches introduce the MediaTek USB3 dual-role controller
> driver.
>
> The driver can be configured as Dual-Role Device (DRD),
> Peripheral Only and Host Only (xHCI) modes. It works well
> with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
> tested on MT8173 platform which only contains USB2.0 device IP,
> and on MT6290 platform which contains USB3.0 device IP.
>
> Change in v7:
> 1. split dual-role driver into four patchs
> 2. remove QMU done tasklet
> 3. add a bool in xhci_hcd_mtk to signal absence of IPPC
Given a lack of objection from anyone, I've now merged these to my tree
to get them a spin in the 0-day build-bot.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2] ARM: dts: imx53-qsb: Fix regulator constraints
From: Fabio Estevam @ 2016-10-27 15:06 UTC (permalink / raw)
To: linux-arm-kernel
Since commit fa93fd4ecc9c ("regulator: core: Ensure we are at least in
bounds for our constraints") the imx53-qsb board populated with a Dialog
DA9053 PMIC fails to boot:
LDO3: Bringing 3300000uV into 1800000-1800000uV
The LDO3 voltage constraints passed in the device tree do not match
the valid range according to the datasheet, so fix this accordingly to
allow the board booting again.
While at it, fix the other voltage constraints as well.
Cc: <stable@vger.kernel.org> # 4.7.x
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v1:
- Mention the commit that causes the issue
arch/arm/boot/dts/imx53-qsb.dts | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-qsb.dts b/arch/arm/boot/dts/imx53-qsb.dts
index dec4b07..3799396 100644
--- a/arch/arm/boot/dts/imx53-qsb.dts
+++ b/arch/arm/boot/dts/imx53-qsb.dts
@@ -64,8 +64,8 @@
};
ldo3_reg: ldo3 {
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1725000>;
+ regulator-max-microvolt = <3300000>;
regulator-always-on;
};
@@ -76,8 +76,8 @@
};
ldo5_reg: ldo5 {
- regulator-min-microvolt = <1725000>;
- regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3600000>;
regulator-always-on;
};
@@ -100,14 +100,14 @@
};
ldo9_reg: ldo9 {
- regulator-min-microvolt = <1200000>;
+ regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <3600000>;
regulator-always-on;
};
ldo10_reg: ldo10 {
- regulator-min-microvolt = <1250000>;
- regulator-max-microvolt = <3650000>;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <3600000>;
regulator-always-on;
};
};
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 1/5] of: introduce the overlay manager
From: Pantelis Antoniou @ 2016-10-27 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026145756.21689-2-antoine.tenart@free-electrons.com>
Hi Antoine,
> On Oct 26, 2016, at 17:57 , Antoine Tenart <antoine.tenart@free-electrons.com> wrote:
>
> The overlay manager is an in-kernel library helping to handle dt overlay
> loading when using capes.
>
Code related comments
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
> drivers/of/Kconfig | 2 +
> drivers/of/Makefile | 1 +
> drivers/of/overlay-manager/Kconfig | 6 +
> drivers/of/overlay-manager/Makefile | 1 +
> drivers/of/overlay-manager/overlay-manager.c | 199 +++++++++++++++++++++++++++
> include/linux/overlay-manager.h | 38 +++++
> 6 files changed, 247 insertions(+)
> create mode 100644 drivers/of/overlay-manager/Kconfig
> create mode 100644 drivers/of/overlay-manager/Makefile
> create mode 100644 drivers/of/overlay-manager/overlay-manager.c
> create mode 100644 include/linux/overlay-manager.h
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index bc07ad30c9bf..e57aeaf0bf4f 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -116,4 +116,6 @@ config OF_OVERLAY
> config OF_NUMA
> bool
>
> +source "drivers/of/overlay-manager/Kconfig"
> +
> endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index d7efd9d458aa..d738fd41271f 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.o
> obj-$(CONFIG_OF_NUMA) += of_numa.o
>
> obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> +obj-y += overlay-manager/
> diff --git a/drivers/of/overlay-manager/Kconfig b/drivers/of/overlay-manager/Kconfig
> new file mode 100644
> index 000000000000..eeb76054dcb8
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Kconfig
> @@ -0,0 +1,6 @@
> +config OF_OVERLAY_MGR
> + bool "Device Tree Overlay Manager"
> + depends on OF_OVERLAY
> + help
> + Enable the overlay manager to handle automatic overlay loading when
> + devices are detected.
> diff --git a/drivers/of/overlay-manager/Makefile b/drivers/of/overlay-manager/Makefile
> new file mode 100644
> index 000000000000..86d2b53950e7
> --- /dev/null
> +++ b/drivers/of/overlay-manager/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_OF_OVERLAY_MGR) += overlay-manager.o
> diff --git a/drivers/of/overlay-manager/overlay-manager.c b/drivers/of/overlay-manager/overlay-manager.c
> new file mode 100644
> index 000000000000..a725d7e24d38
> --- /dev/null
> +++ b/drivers/of/overlay-manager/overlay-manager.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart <antoine.tenart@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/firmware.h>
> +#include <linux/list.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/overlay-manager.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +struct overlay_mgr_overlay {
> + struct list_head list;
> + char *name;
> +};
> +
> +LIST_HEAD(overlay_mgr_overlays);
> +LIST_HEAD(overlay_mgr_formats);
> +DEFINE_SPINLOCK(overlay_mgr_lock);
> +DEFINE_SPINLOCK(overlay_mgr_format_lock);
> +
Is there a reason for using spinlocks here? OF uses a mutex for
locking since we don?t expect OF manipulation occurring in a
non schedulable context.
> +/*
> + * overlay_mgr_register_format()
> + *
> + * Adds a new format candidate to the list of supported formats. The registered
> + * formats are used to parse the headers stored on the dips.
> + */
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate)
> +{
> + struct overlay_mgr_format *format;
> + int err = 0;
> +
> + spin_lock(&overlay_mgr_format_lock);
> +
> + /* Check if the format is already registered */
> + list_for_each_entry(format, &overlay_mgr_formats, list) {
> + if (!strcpy(format->name, candidate->name)) {
> + err = -EEXIST;
> + goto err;
> + }
> + }
> +
> + list_add_tail(&candidate->list, &overlay_mgr_formats);
> +
> +err:
> + spin_unlock(&overlay_mgr_format_lock);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_register_format);
> +
> +/*
> + * overlay_mgr_parse()
> + *
> + * Parse raw data with registered format parsers. Fills the candidate string if
> + * one parser understood the raw data format.
> + */
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
> + unsigned *n)
> +{
The two argument format is not very readable. Perhaps use a structure instead?
> + struct list_head *pos, *tmp;
> + struct overlay_mgr_format *format;
> +
> + list_for_each_safe(pos, tmp, &overlay_mgr_formats) {
> + format = list_entry(pos, struct overlay_mgr_format, list);
> +
> + format->parse(dev, data, candidates, n);
> + if (n > 0)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_parse);
> +
> +static int overlay_mgr_check_overlay(struct device_node *node)
> +{
> + struct property *p;
> + const char *str = NULL;
> +
> + p = of_find_property(node, "compatible", NULL);
> + if (!p)
> + return -EINVAL;
> +
> + do {
> + str = of_prop_next_string(p, str);
> + if (of_machine_is_compatible(str))
> + return 0;
I think this is very similar to the way of_match_node works.
Find a way to use that instead?
> + } while (str);
> +
> + return -EINVAL;
> +}
> +
> +/*
> + * _overlay_mgr_insert()
> + *
> + * Try to request and apply an overlay given a candidate name.
> + */
> +static int _overlay_mgr_apply(struct device *dev, char *candidate)
> +{
> + struct overlay_mgr_overlay *overlay;
> + struct device_node *node;
> + const struct firmware *firmware;
> + char *firmware_name;
> + int err = 0;
> +
> + spin_lock(&overlay_mgr_lock);
> +
> + list_for_each_entry(overlay, &overlay_mgr_overlays, list) {
> + if (!strcmp(overlay->name, candidate)) {
> + dev_err(dev, "overlay already loaded\n");
> + err = -EEXIST;
> + goto err_lock;
> + }
> + }
> +
> + overlay = devm_kzalloc(dev, sizeof(*overlay), GFP_KERNEL);
> + if (!overlay) {
> + err = -ENOMEM;
> + goto err_lock;
> + }
> +
spinlock and possibly sleeping?
> + overlay->name = candidate;
> +
> + firmware_name = kasprintf(GFP_KERNEL, "overlay-%s.dtbo", candidate);
> + if (!firmware_name) {
> + err = -ENOMEM;
> + goto err_free;
> + }
> +
> + dev_info(dev, "requesting firmware '%s'\n", firmware_name);
> +
> + err = request_firmware_direct(&firmware, firmware_name, dev);
> + if (err) {
> + dev_info(dev, "failed to request firmware '%s'\n",
> + firmware_name);
> + goto err_free;
> + }
> +
Same here.
> + of_fdt_unflatten_tree((unsigned long *)firmware->data, NULL, &node);
> + if (!node) {
> + dev_err(dev, "failed to unflatted tree\n");
> + err = -EINVAL;
> + goto err_fw;
> + }
> +
> + of_node_set_flag(node, OF_DETACHED);
> +
> + err = of_resolve_phandles(node);
> + if (err) {
> + dev_err(dev, "failed to resolve phandles: %d\n", err);
> + goto err_fw;
> + }
> +
> + err = overlay_mgr_check_overlay(node);
> + if (err) {
> + dev_err(dev, "overlay checks failed: %d\n", err);
> + goto err_fw;
> + }
> +
> + err = of_overlay_create(node);
> + if (err < 0) {
> + dev_err(dev, "failed to create overlay: %d\n", err);
> + goto err_fw;
> + }
> +
> + list_add_tail(&overlay->list, &overlay_mgr_overlays);
> +
> + dev_info(dev, "loaded firmware '%s'\n", firmware_name);
> +
> + spin_unlock(&overlay_mgr_lock);
> + return 0;
> +
> +err_fw:
> + release_firmware(firmware);
> +err_free:
> + devm_kfree(dev, overlay);
> +err_lock:
> + spin_unlock(&overlay_mgr_lock);
> + return err;
> +}
> +
> +int overlay_mgr_apply(struct device *dev, char **candidates, unsigned n)
> +{
> + int i, ret;
> +
> + for (i=0; i < n; i++) {
> + ret = _overlay_mgr_apply(dev, candidates[i]);
> + if (!ret)
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(overlay_mgr_apply);
> diff --git a/include/linux/overlay-manager.h b/include/linux/overlay-manager.h
> new file mode 100644
> index 000000000000..8adcc4f5ddf6
> --- /dev/null
> +++ b/include/linux/overlay-manager.h
> @@ -0,0 +1,38 @@
> +/*
> + * Copyright (C) 2016 - Antoine Tenart <antoine.tenart@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __OVERLAY_MGR_H__
> +#define __OVERLAY_MGR_H__
> +
> +#include <linux/device.h>
> +#include <linux/list.h>
> +#include <linux/sizes.h>
> +
> +#define OVERLAY_MGR_DIP_MAX_SZ SZ_128
> +
> +struct overlay_mgr_format {
> + struct list_head list;
> + char *name;
> + int (*parse)(struct device *dev, void *data, char ***candidates,
> + unsigned *n);
> +};
> +
> +int overlay_mgr_register_format(struct overlay_mgr_format *candidate);
> +int overlay_mgr_parse(struct device *dev, void *data, char ***candidates,
> + unsigned *n);
> +int overlay_mgr_apply(struct device *dev, char **candidates, unsigned n);
> +
> +#define dip_convert(field) \
> + ( \
> + (sizeof(field) == 1) ? field : \
> + (sizeof(field) == 2) ? be16_to_cpu(field) : \
> + (sizeof(field) == 4) ? be32_to_cpu(field) : \
> + -1 \
> + )
> +
> +#endif /* __OVERLAY_MGR_H__ */
> --
> 2.10.1
>
^ permalink raw reply
* [PATCH] KVM: arm/arm64: Kick VCPUs when queueing already pending IRQs
From: Shih-Wei Li @ 2016-10-27 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In cases like IPI, we could be queueing an interrupt for a VCPU
that is already running and is not about to exit, because the
VCPU has entered the VM with the interrupt pending and would
not trap on EOI'ing that interrupt. This could result to delays
in interrupt deliveries or even loss of interrupts.
To guarantee prompt interrupt injection, here we have to try to
kick the VCPU.
Signed-off-by: Shih-Wei Li <shihwei@cs.columbia.edu>
---
I've tested the code with an IPI test built on kvm-unit-test, which
measures the cycles spent between one VCPU sending IPI to a target
VCPU that busy loops in the VM, until the target VCPU ACKs and EOIs
the IPI. The patch here can improve the performance in such case by
more than 5000 cycles.
virt/kvm/arm/vgic/vgic.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
index b419a11..07cf239 100644
--- a/virt/kvm/arm/vgic/vgic.c
+++ b/virt/kvm/arm/vgic/vgic.c
@@ -273,6 +273,17 @@ retry:
* no more work for us to do.
*/
spin_unlock(&irq->irq_lock);
+
+ /*
+ * If the VCPU is not NULL, we could be queueing an
+ * edge-triggered interrupt for a VCPU which is already
+ * running and is not about to exit, because the VCPU has
+ * entered the VM with the interrupt pending and it wouldn't
+ * trap on EOI. To ensure prompt delivery of that interrupt,
+ * we have to try to kick the VCPU.
+ */
+ if (vcpu)
+ kvm_vcpu_kick(vcpu);
return false;
}
--
1.9.1
^ permalink raw reply related
* [alsa-devel] [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Jean-Francois Moine @ 2016-10-27 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024123449.npo4grdlbrj4tcsj@lukather>
On Mon, 24 Oct 2016 14:34:49 +0200
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Sun, Oct 23, 2016 at 09:45:03AM +0200, Jean-Francois Moine wrote:
> > On Sun, 23 Oct 2016 09:33:16 +0800
> > Chen-Yu Tsai <wens@csie.org> wrote:
> >
> > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > - it handles the H3
> > >
> > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > the newer SoCs.
> > >
> > > > - it creates the sound card (with sun4i-i2s, the sound card is created
> > > > by the CODECs)
> > >
> > > I think this is wrong. I2S is only the DAI. You typically have a separate
> > > platform driver for the whole card, or just use simple-card.
> >
> > An other device is not needed. The layout is simple:
> > I2S_controller (CPU DAI) <-> HDMI_CODEC (CODEC DAI)
> > The HDMI CODEC is supported by the HDMI video driver (only one device),
> > so, it cannot be the card device.
> > ASoC does not use the CPU DAI device (I2S_controller), so, it is
> > natural to use it to handle the card.
>
> Still, duplicating the driver is not the solution. I agree with
> Chen-Yu that we want to leverage the driver that is already there.
Hi Maxime and Chen-Yu,
After looking at the sun4i-i2s, I found 2 solutions for re-using its
code in the DE2 HDMI context:
1) either to split the sun4i-i2s driver into common I/O functions and
slave CPU DAI,
2) or to move the sun4i-i2s into a master CPU DAI.
(
some explanation about 'master' and 'slave': the master is the
component the device of which is also the sound card.
As the sound card uses the 'drvdata' of the device, this drvdata pointer
cannot be used by the master.
In the actual implementations:
- sun4i-i2s
master: card dev = codec dev, drvdata -> card
slave: i2s dev (CPU DAI), drvdata -> i2s data
- sun8i-i2s
master: card dev = i2s dev (CPU DAI), drvdata -> card
slave: codec dev (hdmi), drvdata -> codec data (audio/video)
)
In the case 1, there is no functional change, just a source split.
The sun8i-i2s will then use the common I/O functions.
In the case 2, the CODECs using the sun4i-i2s would have to move to
slave CODEC DAI, i.e. the card is created by the sun4i-i2s code.
In the 4.9, there is only one codec (sun4i-codec), so, the change
is just to move the card creation and the use of drvdata in both
codes.
In either cases, I could not check if this changes raise some
regression on the sun4i SoCs side. Then, I'd be glad to know:
- which solution suits you?
- are you ready to do and test the needed changes at the sun4i side?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [RFC PATCH 0/5] Add an overlay manager to handle board capes
From: Hans de Goede @ 2016-10-27 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqL9yWBj0yYE54XGi87YPGugGAACzr=CuW6dk5kk3EuyCA@mail.gmail.com>
Hi,
On 27-10-16 15:41, Rob Herring wrote:
> Please Cc the maintainers of drivers/of/.
>
> + Frank R, Hans, Dmitry S
>
> On Wed, Oct 26, 2016 at 9:57 AM, Antoine Tenart
> <antoine.tenart@free-electrons.com> wrote:
>> Hi all,
>>
>> Many boards now come with dips and compatible capes; among others the
>> C.H.I.P, or Beaglebones. All these boards have a kernel implementing an
>> out-of-tree "cape manager" which is used to detected capes, retrieve
>> their description and apply a corresponding overlay. This series is an
>> attempt to start a discussion, with an implementation of such a manager
>> which is somehow generic (i.e. formats or cape detectors can be added).
>> Other use cases could make use of this manager to dynamically load dt
>> overlays based on some input / hw presence.
>
> I'd like to see an input source be the kernel command line and/or a DT
> chosen property. Another overlay manager was proposed not to long
> ago[1] as well. There's also the Allwinner tablet use case from Hans
> where i2c devices are probed and detected. That's not using overlays
> currently, but maybe could.
Actually I'm currently thinking in a different direction, which I
think will be good for the boards where some ICs are frequently
replaced by 2nd (and 3th and 4th) sources, rather then that we're
dealing with an extension connector with capes / daughter boards.
Although there is some overlap I'm starting to think that we need to
treat these 2 cases differently. Let me quickly copy and paste
the basic idea I've for the 2nd source touchscreen / accelerometer
chip case:
"""
The kernel actually already has a detect() method in struct i2c_driver,
we could use that (we would need to implement it in drivers which do not
have it yet). Note on second thought it seems it may be better to use
probe() for this, see below.
Then we could have something like this in dt:
&i2c0 {
touchscreen1: gsl1680 at 40 {
reg = <0x40>;
compatible = "silead,gsl1680";
enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
status = "disabled";
};
touchscreen2: ektf2127 at 15 {
reg = <0x15>;
compatible = "elan,ektf2127";
enable-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
status = "disabled";
};
i2c-probe-stop-at-first-match-0 = <&touchscreen1>, <&touchscreen2>;
i2c-probe-stop-at-first-match-1 = <&accelerometer1>, <&accelerometer2>;
}
Which would make the i2c subsys call detect (*) on each device, until
a device is found. Likewise we could have a "i2c-probe-all" property
which also walks a list of phandles but does not stop on the first
match.
...
*) Yes this sounds Linux specific, but it really is just "execute to-be-probed
device compatible specific detection method"
"""
This does not 100% solve all q8 issues (see the "Add Allwinner Q8 tablets
hardware manager" thread), but does solve quite a bit of the use-case
and this matches what many vendor os-images (typically android) are
actually doing for these kind of boards.
As for the bits this does not solve, those are mostly board specific details
which cannot be probed at all, and on x86 are typically solved in the device
driver by doing a dmi check to identify the board and then apply a board
specific workaround in the driver.
I've come to believe that we should similarly delegate dealing this to device
drivers in the devicetree case. Note that dt should still of course fully
describe the hardware for normal hardware, the driver would just need to care
about weird board quirks in certain exceptions.
A more interesting problem here is that dt does not have something like
DMI, there is the machine compatible, but that typically does not contain
board revision info (where as DMI often does). I believe that this is
actually something which should be fixed at the bootloader level
have it prepend a new machine compatible which contains revision info.
Hmm, if we make the bootloader prepend a new machine compatible which contains
revision info, we could then trigger quirks on this and in some cases avoid
the need for dealing with board quirks in the driver ...
Note this is all very specific to dealing with board (revision) variants,
for add-ons having the bootloader add info to the machine compatible does
not seem the right solution.
Regards,
Hans
>
> Another thing to consider is different sources of overlays. Besides in
> the filesystem, overlays could be built into the kernel (already
> supported), embedded in the dtb (as the other overlay mgr did) or we
> could extend FDT format to append them.
>
>> The proposed design is a library which can be used by detector drivers
>> to parse headers and load the corresponding overlay. Helpers are
>> provided for this purpose. The whole thing is divided into 3 entities:
>>
>> - The parser which is project-specific (to allow supporting headers
>> already into the wild). It registers a function parsing an header's
>> data and filling one or more strings which will be used to find
>> matching dtbo on the fs.
>>
>> - The overlay manager helpers allowing to parse a header to retrieve
>> the previously mentioned strings and to load a compatible overlay.
>>
>> - The detectors which are used to detect capes and get their description
>> (to be parsed).
>
> What about things like power has to be turned on first to detect
> boards and read their ID? I think this needs to be tied into the
> driver model. Though, don't go sticking cape mgr nodes into DT. Maybe
> a driver gets bound to a connector node, but we've got to sort out
> connector bindings first.
>
>> An example of parser and detector is given, compatible with what's done
>> for the C.H.I.P. As the w1 framework is really bad (and we should
>> probably do something about that) the detector code is far from being
>> perfect; but that's not related to what we try to achieve here.
>>
>> The actual implementation has a limitation: the detectors cannot be
>> built-in the kernel image as they would likely detect capes at boot time
>> but will fail to get their corresponding dt overlays as the fs isn't
>> mounted yet. The only case this can work is when dt overlays are
>> built-in firmwares. This isn't an issue for the C.H.I.P. use case right
>> now. There was a discussion about making an helper to wait for the
>> rootfs to be mount but the answer was "this is the driver's problem".
>
> I thought there are firmware loading calls that will wait. I think
> this all needs to work asynchronously both for firmware loading and
> because w1 is really slow.
>
>> I'd like to get comments, specifically from people using custom cape
>> managers, to see if this could fill their needs (with I guess some
>> modifications).
>
> Having 2 would certainly give a better sense this is generic.
>
> Rob
>
> [1] https://patchwork.ozlabs.org/patch/667805/
>
^ permalink raw reply
* [PATCH 5/5] tty: amba-pl011: Add earlycon support for SBSA UART
From: Greg Kroah-Hartman @ 2016-10-27 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7edb183d-2376-0f09-a3ea-3bf78971609d@huawei.com>
On Mon, Oct 24, 2016 at 11:59:20AM +0800, Kefeng Wang wrote:
> Hi Greg, any more comments, thanks.
Never wait, just resend if you have comments and you know you have to
fix them up...
^ permalink raw reply
* [RFC PATCH 0/8] arm64: Add a compat vDSO
From: Dmitry Safonov @ 2016-10-27 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908140103.7468-1-kevin.brodsky@arm.com>
2016-09-08 17:00 GMT+03:00 Kevin Brodsky <kevin.brodsky@arm.com>:
> Hi,
>
> This series adds support for a compat (AArch32) vDSO, providing two
> userspace functionalities to compat processes:
>
> * "Virtual" time syscalls (gettimeofday and clock_gettime). The
> implementation is an adaptation of the arm vDSO (vgettimeofday.c),
> sharing the data page with the 64-bit vDSO.
>
> * sigreturn trampolines, following the example of the 64-bit vDSO
> (sigreturn.S), but slightly more complicated because we provide A32
> and T32 variants for both sigreturn and rt_sigreturn.
>
> The first point brings the performance improvement expected of a vDSO,
> by implementing time syscalls directly in userspace. The second point
> allows us to get rid of the compat vector page, at the expense of the
> kuser helpers (this is one reason for not enabling the compat vDSO by
> default).
>
> Unfortunately, this time we cannot escape using a 32-bit toolchain. To
> build the compat VDSO, CONFIG_COMPAT_VDSO must be set *and*
> CROSS_COMPILE_ARM32 must be defined to the prefix of a 32-bit compiler.
> Failure to do so will not prevent building the kernel, but a warning
> will be printed and the compat vDSO will not be built.
>
> I have only tested the series with a 64-bit userspace (+ 32-bit glibc).
> Testing it with a 32-bit userspace would be very welcome.
Hi, what's up with these patches, are you gonna resend them or prepare
a new version?
> Thanks,
> Kevin
>
> Kevin Brodsky (8):
> arm64: Refactor vDSO setup
> arm64: compat: Add time-related syscall numbers
> arm64: compat: Expose offset to registers in sigframes
> arm64: compat: Add a 32-bit vDSO
> arm64: compat: 32-bit vDSO setup
> arm64: elf: Set AT_SYSINFO_EHDR in compat processes
> arm64: compat: Use vDSO sigreturn trampolines if available
> arm64: Wire up and expose the new compat vDSO
>
> arch/arm64/Kconfig | 20 +++
> arch/arm64/Makefile | 20 ++-
> arch/arm64/include/asm/elf.h | 15 +-
> arch/arm64/include/asm/signal32.h | 46 +++++
> arch/arm64/include/asm/unistd.h | 2 +
> arch/arm64/include/asm/vdso.h | 3 +
> arch/arm64/kernel/Makefile | 8 +-
> arch/arm64/kernel/asm-offsets.c | 13 ++
> arch/arm64/kernel/signal32.c | 61 ++-----
> arch/arm64/kernel/vdso.c | 198 ++++++++++++---------
> arch/arm64/kernel/vdso32/Makefile | 121 +++++++++++++
> arch/arm64/kernel/vdso32/sigreturn.S | 86 +++++++++
> arch/arm64/kernel/vdso32/vdso.S | 32 ++++
> arch/arm64/kernel/vdso32/vdso.lds.S | 98 +++++++++++
> arch/arm64/kernel/vdso32/vgettimeofday.c | 294 +++++++++++++++++++++++++++++++
> 15 files changed, 883 insertions(+), 134 deletions(-)
> create mode 100644 arch/arm64/kernel/vdso32/Makefile
> create mode 100644 arch/arm64/kernel/vdso32/sigreturn.S
> create mode 100644 arch/arm64/kernel/vdso32/vdso.S
> create mode 100644 arch/arm64/kernel/vdso32/vdso.lds.S
> create mode 100644 arch/arm64/kernel/vdso32/vgettimeofday.c
--
Dmitry
^ permalink raw reply
* [PATCH v4] Remove duplicated defines (was [PATCH v3] Fix some potential warnings)
From: Alexandre Bailon @ 2016-10-27 15:32 UTC (permalink / raw)
To: linux-arm-kernel
Remove duplicated defines before they cause warning.
Change in V2:
Update the d830 evm board file to use the da8xx-cfgchip.h
These changes are required as I'm sending this patch apart from
the series "[PATCH/RFT v2 00/17] Add DT support for ohci-da8xx"
Changes in v3:
* Change the patch description to better respect what the patch fix.
* Sorted new header sorted in alphabetical order.
Alexandre Bailon (1):
ARM: davinci: da8xx: Remove duplicated defines
arch/arm/mach-davinci/board-da830-evm.c | 5 +++--
arch/arm/mach-davinci/board-omapl138-hawk.c | 3 ++-
include/linux/platform_data/usb-davinci.h | 23 -----------------------
3 files changed, 5 insertions(+), 26 deletions(-)
--
2.7.3
^ permalink raw reply
* [PATCH v4] ARM: davinci: da8xx: Remove duplicated defines
From: Alexandre Bailon @ 2016-10-27 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477582356-28156-1-git-send-email-abailon@baylibre.com>
Some macro for DA8xx CFGCHIP are defined in usb-davinci.h,
but da8xx-cfgchip.h intend to replace them.
Remove duplicated defines between da8xx-cfgchip.h and usb-davinci.h
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 5 +++--
arch/arm/mach-davinci/board-omapl138-hawk.c | 3 ++-
include/linux/platform_data/usb-davinci.h | 23 -----------------------
3 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 3d8cf8c..df1f409 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -18,6 +18,7 @@
#include <linux/i2c.h>
#include <linux/i2c/pcf857x.h>
#include <linux/platform_data/at24.h>
+#include <linux/mfd/da8xx-cfgchip.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
#include <linux/spi/spi.h>
@@ -116,7 +117,7 @@ static __init void da830_evm_usb_init(void)
cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
/* USB2.0 PHY reference clock is 24 MHz */
- cfgchip2 &= ~CFGCHIP2_REFFREQ;
+ cfgchip2 &= ~CFGCHIP2_REFFREQ_MASK;
cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
/*
@@ -133,7 +134,7 @@ static __init void da830_evm_usb_init(void)
* controller won't be able to drive VBUS thinking that it's a B-device.
* Otherwise, we want to use the OTG mode and enable VBUS comparators.
*/
- cfgchip2 &= ~CFGCHIP2_OTGMODE;
+ cfgchip2 &= ~CFGCHIP2_OTGMODE_MASK;
#ifdef CONFIG_USB_MUSB_HOST
cfgchip2 |= CFGCHIP2_FORCE_HOST;
#else
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index ee62486..e1efa10 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -13,6 +13,7 @@
#include <linux/init.h>
#include <linux/console.h>
#include <linux/gpio.h>
+#include <linux/mfd/da8xx-cfgchip.h>
#include <linux/platform_data/gpio-davinci.h>
#include <asm/mach-types.h>
@@ -254,7 +255,7 @@ static __init void omapl138_hawk_usb_init(void)
/* Setup the Ref. clock frequency for the HAWK at 24 MHz. */
cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
- cfgchip2 &= ~CFGCHIP2_REFFREQ;
+ cfgchip2 &= ~CFGCHIP2_REFFREQ_MASK;
cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
__raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
diff --git a/include/linux/platform_data/usb-davinci.h b/include/linux/platform_data/usb-davinci.h
index e0bc4ab..0926e99 100644
--- a/include/linux/platform_data/usb-davinci.h
+++ b/include/linux/platform_data/usb-davinci.h
@@ -11,29 +11,6 @@
#ifndef __ASM_ARCH_USB_H
#define __ASM_ARCH_USB_H
-/* DA8xx CFGCHIP2 (USB 2.0 PHY Control) register bits */
-#define CFGCHIP2_PHYCLKGD (1 << 17)
-#define CFGCHIP2_VBUSSENSE (1 << 16)
-#define CFGCHIP2_RESET (1 << 15)
-#define CFGCHIP2_OTGMODE (3 << 13)
-#define CFGCHIP2_NO_OVERRIDE (0 << 13)
-#define CFGCHIP2_FORCE_HOST (1 << 13)
-#define CFGCHIP2_FORCE_DEVICE (2 << 13)
-#define CFGCHIP2_FORCE_HOST_VBUS_LOW (3 << 13)
-#define CFGCHIP2_USB1PHYCLKMUX (1 << 12)
-#define CFGCHIP2_USB2PHYCLKMUX (1 << 11)
-#define CFGCHIP2_PHYPWRDN (1 << 10)
-#define CFGCHIP2_OTGPWRDN (1 << 9)
-#define CFGCHIP2_DATPOL (1 << 8)
-#define CFGCHIP2_USB1SUSPENDM (1 << 7)
-#define CFGCHIP2_PHY_PLLON (1 << 6) /* override PLL suspend */
-#define CFGCHIP2_SESENDEN (1 << 5) /* Vsess_end comparator */
-#define CFGCHIP2_VBDTCTEN (1 << 4) /* Vbus comparator */
-#define CFGCHIP2_REFFREQ (0xf << 0)
-#define CFGCHIP2_REFFREQ_12MHZ (1 << 0)
-#define CFGCHIP2_REFFREQ_24MHZ (2 << 0)
-#define CFGCHIP2_REFFREQ_48MHZ (3 << 0)
-
struct da8xx_ohci_root_hub;
typedef void (*da8xx_ocic_handler_t)(struct da8xx_ohci_root_hub *hub,
--
2.7.3
^ permalink raw reply related
* [PATCH v3 2/3] drm: zte: add initial vou drm driver
From: Shawn Guo @ 2016-10-27 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020122958.GC10198@joana>
Hi Gustavo,
Thanks for looking at the patch.
> 2016-10-20 Shawn Guo <shawn.guo@linaro.org>:
>
> > It adds the initial ZTE VOU display controller DRM driver. There are
> > still some features to be added, like overlay plane, scaling, and more
> > output devices support. But it's already useful with dual CRTCs and
> > HDMI monitor working.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
<snip>
> > +static void zx_hdmi_connector_destroy(struct drm_connector *connector)
> > +{
> > + drm_connector_unregister(connector);
>
> drm_connector_unregister() is not needed anymore. DRM core will call it
> for you.
>
> > + drm_connector_cleanup(connector);
> > +}
> > +
> > +static const struct drm_connector_funcs zx_hdmi_connector_funcs = {
> > + .dpms = drm_atomic_helper_connector_dpms,
> > + .fill_modes = drm_helper_probe_single_connector_modes,
> > + .detect = zx_hdmi_connector_detect,
> > + .destroy = zx_hdmi_connector_destroy,
>
> Then here you can use drm_connector_cleanup() directly.
Okay, will do.
> > + .reset = drm_atomic_helper_connector_reset,
> > + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> > + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> > +};
<snip>
> > +static void zx_crtc_atomic_begin(struct drm_crtc *crtc,
> > + struct drm_crtc_state *state)
> > +{
> > + struct drm_pending_vblank_event *event = crtc->state->event;
> > +
> > + if (!event)
> > + return;
> > +
> > + crtc->state->event = NULL;
> > +
> > + spin_lock_irq(&crtc->dev->event_lock);
> > + if (drm_crtc_vblank_get(crtc) == 0)
> > + drm_crtc_arm_vblank_event(crtc, event);
> > + else
> > + drm_crtc_send_vblank_event(crtc, event);
> > + spin_unlock_irq(&crtc->dev->event_lock);
>
> I think you may want to send the vblank event to userspace after you
> commit your planes, and not before.
I guess you are suggesting that the code should be implemented in
.atomic_flush hook instead, right?
> > +}
> > +
> > +static const struct drm_crtc_helper_funcs zx_crtc_helper_funcs = {
> > + .enable = zx_crtc_enable,
> > + .disable = zx_crtc_disable,
> > + .atomic_begin = zx_crtc_atomic_begin,
> > +};
> > +
> > +static const struct drm_crtc_funcs zx_crtc_funcs = {
> > + .destroy = drm_crtc_cleanup,
> > + .set_config = drm_atomic_helper_set_config,
> > + .page_flip = drm_atomic_helper_page_flip,
> > + .reset = drm_atomic_helper_crtc_reset,
> > + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> > + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> > +};
> > +
> > +static int zx_crtc_init(struct drm_device *drm, struct zx_vou_hw *vou,
> > + enum vou_chn_type chn_type)
> > +{
> > + struct device *dev = vou->dev;
> > + struct zx_layer_data data;
> > + struct zx_crtc *zcrtc;
> > + int ret;
> > +
> > + zcrtc = devm_kzalloc(dev, sizeof(*zcrtc), GFP_KERNEL);
> > + if (!zcrtc)
> > + return -ENOMEM;
> > +
> > + zcrtc->vou = vou;
> > + zcrtc->chn_type = chn_type;
> > +
> > + if (chn_type == VOU_CHN_MAIN) {
> > + data.layer = vou->osd + MAIN_GL_OFFSET;
> > + data.csc = vou->osd + MAIN_CSC_OFFSET;
> > + data.hbsc = vou->osd + MAIN_HBSC_OFFSET;
> > + data.rsz = vou->otfppu + MAIN_RSZ_OFFSET;
> > + zcrtc->chnreg = vou->osd + OSD_MAIN_CHN;
> > + zcrtc->regs = &main_crtc_regs;
> > + zcrtc->bits = &main_crtc_bits;
> > + } else {
> > + data.layer = vou->osd + AUX_GL_OFFSET;
> > + data.csc = vou->osd + AUX_CSC_OFFSET;
> > + data.hbsc = vou->osd + AUX_HBSC_OFFSET;
> > + data.rsz = vou->otfppu + AUX_RSZ_OFFSET;
> > + zcrtc->chnreg = vou->osd + OSD_AUX_CHN;
> > + zcrtc->regs = &aux_crtc_regs;
> > + zcrtc->bits = &aux_crtc_bits;
> > + }
> > +
> > + zcrtc->pixclk = devm_clk_get(dev, (chn_type == VOU_CHN_MAIN) ?
> > + "main_wclk" : "aux_wclk");
> > + if (IS_ERR(zcrtc->pixclk)) {
> > + ret = PTR_ERR(zcrtc->pixclk);
> > + dev_err(dev, "failed to get pix clk: %d\n", ret);
>
> DRM_ERROR() - here and in other places in your patch
I will follow Sean's suggestion to use DRM_DEV_* for these messages.
Shawn
^ permalink raw reply
* [PATCH 4/5] ARM: davinci: enable LEDs default-on trigger in default config
From: David Lechner @ 2016-10-27 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <669b14c2-7f62-35bc-c8a3-6dde05a99fb1@ti.com>
On 10/27/2016 06:29 AM, Sekhar Nori wrote:
> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>> The LEDs default-on trigger is nice to have. For example, it can be used
>> to configure a LED as a power indicator.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> ---
>> arch/arm/configs/davinci_all_defconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
>> index 9d7f0bc..e380743 100644
>> --- a/arch/arm/configs/davinci_all_defconfig
>> +++ b/arch/arm/configs/davinci_all_defconfig
>> @@ -181,6 +181,7 @@ CONFIG_LEDS_GPIO=m
>> CONFIG_LEDS_TRIGGERS=y
>> CONFIG_LEDS_TRIGGER_TIMER=m
>> CONFIG_LEDS_TRIGGER_HEARTBEAT=m
>> +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
>
> Can this be module like rest of the triggers? It will come on later, but
> not sure if you care about the difference that much. Having it a module
> will be better for those boards that don't need it.
>
> Thanks,
> Sekhar
>
Yes, module is OK here.
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Pantelis Antoniou @ 2016-10-27 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4cfbedb2-0249-e881-3577-dda0b0d4cabe@redhat.com>
Hi Hans,
> On Oct 26, 2016, at 14:46 , Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 24-10-16 19:39, Mark Rutland wrote:
>> On Fri, Oct 14, 2016 at 09:53:31AM +0200, Hans de Goede wrote:
>>> Hi Rob, Mark, et al.,
>>
>> Hi Hans,
>>
>> Apologies for the delay in replying to this.
>
> No worries, I believe that 1 week is actually a pretty good
> turn around time, esp. directly after a conference.
>
Conferences are a deadline killer. Just got around taking a look.
>> I'd like to be clear that I do understand that there is a problem that
>> needs to be addressed here. However, I do not believe that the *current*
>> in-kernel approach is correct. More on that below.
>
> Ok.
>
>>> Mark, I know that we discussed this at ELCE and you clearly indicated
>>> that according to you this does not belong in the kernel. I was a bit
>>> surprised by this part of the discussion.
>>>
>>> I had posted a RFC earlier and Rob had indicated that given that the q8
>>> tablets are a special case, as my code uses actual probing rather then some
>>> pre-arranged id mechanism with say an eeprom, that doing this in a
>>> non-generic manner would be ok for my special case.
>>
>> To some extent, Rob and I may have differing views here; I'm not
>> entirely sure what Rob's view is, and I cannot talk on his behalf. I
>> certainly must apologise for having not commented on said RFC, however.
>>
>>> So on to why I believe that the kernel is the best place to do this, at least
>>> for my special use-case:
>>>
>>> 1. Configurability
>>>
>>> Since the q8 tablets do not have any id mechanism I'm probing i2c busses to
>>> generate i2c client dt nodes with the right address and compatible.
>>> Some info in these nodes (e.g. touchscreen firmware-name) is not probable at
>>> all and gets set by heuristics. This heuristics may get things wrong.
>>> So my current implementation offers kernel cmdline options to override this.
>>
>> As I mentioned at ELCE, one major concern I have with this approach is
>> this probing, which in part relies on a collection of heuristics.
>
> This is quite use-case specific, anyways, the probing is a 2 step process:
>
> 1) Identify which hardware there is in the tablet, this is pretty
> reliable, we only detect a fix set of known possible touchscreens
> and accelerometers, at known addresses and almost all have an id
> register to check.
>
> 2) Determine *defaults* for various none probable settings, like guessing
> which firmware to load into the touchscreen controllers, as there are
> at least 2 ways the gsl1680 is wired up on these tablets and this
> requires 2 different firmware files. This uses heuristics, to, as said,
> determine the defaults all of the non-probable bits are overidable
> through config options (currently kernel module options). Getting these
> wrong is not dangerous to the hardware, but will work in a non-functional
> or misbehaving (wrong coordinates) touchscreen.
>
> Note with the models I've access to so far the heuristics score 100%
> but I'm not sure how representative the 16 models I've access to are
> (they are all different and have been bought over a span of multiple
> years).
>
>> I'm worried that this is very fragile, and sets us up for having to
>> maintain a much larger collection of heuristics and/or a database of
>> particular boards in future. This is fragile, defeats much of the gain
>> from DT.
>
> I understand your worries, as said I'm confident the actual probing
> is safe and getting the heuristics wrong will result in misbehavior,
> but not in any hardware damage or such.
>
>> Worse, this could be completely incompatible with some arbitrary board
>> that comes by in future,
>
> I assume you mean an arbitrary q8 tablet here, as the probe code does
> bind by board/machine compatible, so for a really arbitrary board
> this code will never activate.
>
>> because the kernel assumed something that was
>> not true, which it would not have done if things were explicitly
>> described to the kernel.
>
> I understand your worry, but moving the probing code to say u-boot
> will not change any of this, the kernel will get the explicit
> description created by the u-boot probe code, but it would be
> just as wrong.
>
> So maybe we need to answer 2 questions in a row:
>
> 1) Do we want such probe code at all ?
>
> My answer to this is yes, these (cheap) tablets are interesting to
> e.g. the maker community and I would like them to run mainline
> (and run mainline well), but given the way there are put together
> this require some code to dynamically adapt to the batch of the
> month somewhere
>
> 2) Where do we put this code ?
>
> If we agree on 1 (I assume we do) then this becomes the real
> question, at which point your worries about the kernel assuming
> something which is not true because the probe code got it wrong
> may become true regardless where the code lives.
>
> So wrt this worries is all I can do is ask you to trust me to
> not mess things up, just like we all trust driver authors, etc.
> all the time to not mess things up.
>
>> As I mentioned at ELCE, I'm not opposed to the concept of the kernel
>> applying overlays or fixups based on a well-defined set of criteria;
>> having some of that embedded in the DT itself would be remarkably
>> helpful. However, I am very much not keen on loosely defined criteria as
>> with here, as it couples the DT and kernel, and creates problems longer
>> term, as described above.
>
> Right, so again I think we need to split the discussion in 2 steps:
>
> 1) How do we apply the fixups, currently I'm using free-form changes
> done from C-code. I can envision moving to something like the quirk
> mechanism suggested by Pantelis in the past. Note this is not a perfect
> fit for my rather corner-case use-case, but I can understand that in
> general you want the variants to be described in dt, and activated
> in some way, rather then have c-code make free-form changes to the dt
>
We?ve had this discussion before, so I guess here it goes again.
I think the biggest objection is the programmatic way of applying
every quirk by ?hand?.
If there was a way to keep the probing mechanism but just spit out
a ?model? number we could reasonably map it to an overlay to apply
with a generic overlay manager.
>From an internal s/w standpoint having an expansion board or soldered
parts makes no difference.
> 2) How do we select which fixups to apply. Again I can understand
> you wanting some well defined mechanism for this, but again my
> use-case is special and simply does not allow for this as there
> is no id-eeprom to read or some such.
>
Yes there is no EEPROM but you might be able to map probing results to
a fake ?model? number.
Let me expand a bit:
Assume that you have a number of probing steps, for example A, B, C each
returning true or false, and C being executed only when B is ?true? you
could do this to generate a bit field that identifies it.
For example let?s assume that model FOO?s probing steps are
A false, B true, C false -> 010
Model?s BAR
A true, B false, C don?t care -> 10x
Mapping these to models could be
Model FOO, (010 & 111) == 010 (all three probing steps must match)
Model BAR, (10x & 110) = 100 (the first two probing steps must match)
>>> Although having to specify kernel cmdline options is not the plug and play
>>> experience I want to give end-users most distros do have documentation on
>>> how to do this and doing this is relatively easy for end-users. Moving this
>>> to the bootloader means moving to some bootloader specific config mechanism
>>> which is going to be quite hard (and possibly dangerous) for users to use.
>>
>> I have to ask, why is it more dangerous?
>
> Because for normal end users meddling with the bootloader / with u-boot's
> environment is like flashing a PC BIOS. Most (non technical) end users will
> want to install u-boot once (or not at all) and then just have it work.
>
Users do *not* want to deal with the bootloader. They don?t even want to
know that it?s there. As far they're concerned if you need to drop in
the bootloader to do something -> broken.
>> Perhaps more difficult, but that can be solved,
>
> More difficult means not doable for many users.
>
+1
>> if the manual
>> corrections are simply a set of options to be passed to the kernel, I
>> don't see why the bootloader cannot pick this up.
>>
>>> 2. Upgradability
>>>
>>> Most users treat the bootloader like they treat an x86 machine BIOS/EFI,
>>> they will never upgrade it unless they really have to. This means that it
>>> will be very difficult to get users to actual benefit from bug-fixes /
>>> improvements done to the probing code. Where as the kernel on boards running
>>> e.g. Debian or Fedora gets regular updates together with the rest of the
>>> system.
>>
>> Given that DTBs are supposed to remain supported, users should find
>> themselves with a system that continues to work, but may not have all
>> the bells and whistles it could, much like elsewhere.
>>
>> While it's true that we have issues in this area, I don't think that's
>> an argument for putting things into the kernel for this specific set of
>> boards.
>
> It is an argument to put much of the dynamic (dt) hardware support in
> the kernel in general.
>
>>> 3. Infrastructure
>>>
>>> The kernel simply has better infrastructure for doing these kind of things.
>>
>> At least on the DT front, a lot of work has gone into improving the
>> infrastructure, e.g. the work that Free Electrons have done [1]. I
>> appreciate that the infrastructure for things like poking SPI may not be
>> as advanced.
>>
>> Which bits of infrastructure do you find lacking today?
>
> Nothing really specific (I've not yet tried porting the probe code
> to u-boot), but I just find working within the kernel easier in general,
> since there really just is a lot more infrastructure. Note I'm the
> upstream u-boot maintainer for the allwinner SoC support, so this
> is not due to me being unfamiliar with u-boot.
>
>>> Yes we could improve the bootloader, but the kernel is also improving
>>> and likely at a faster rate. Besides that the purpose of the
>>> bootloader is mostly to be simple and small, load the kernel and get
>>> out of the way, not to be a general purpose os kernel. So it will
>>> simply always have less infrastructure and that is a good thing,
>>> otherwise we will be writing another general purpose os which is a
>>> waste of effort.
>>
>> I think this conflates a number of details. Yes, we'd like firmware and
>> bootloaders to be small, and yes, their infrastructure and feature
>> support will be smaller than a general purpose OS.
>>
>> That doesn't imply that they cannot have features necessary to boostrap
>> an OS.
>>
>> It's also not strictly necessary that the firmware or bootloader have
>> the capability to do all this probing, as that could be contained in
>> another part (e.g. a U-Boot application which is run once to detect the
>> board details, logging this into a file).
>>
>> It's also possible to ship an intermediary stage (e.g. like the
>> impedance matcher) which can be upgradeable independently of the kernel.
>
> Yes there are other solutions, but they all involve a lot more
> moving pieces (and thus will break) then a single isolated .c file
> in the kernel, which is all this series adds.
>
> Esp the intermediate solution just adds a ton of complexity with 0
> gain.
Simple is the way to go. Putting things in the kernel is the simplest
solution for the users, for the distro maintainers and the board support
people.
>
>>> 4. This is not a new board file
>>>
>>> Mark, at ELCE I got the feeling that your biggest worry / objection is
>>> that this will bring back board files, but that is not the case, if you
>>> look at the actual code it is nothing like a board-file at all. Where a
>>> board file was instantiating device after device after device from c-code,
>>> with maybe a few if-s in there to deal with board revisions. This code is
>>> all about figuring out which accelerometer and touchscreen there are,
>>> to then add nodes to the dt for this 2 devices, almost all the code is
>>> probing, the actual dt modifying code is tiny and no direct device
>>> instantiation is done at all.
>>
>> Sorry, but I must disagree. This code:
>>
>> (a) identifies a set of boards based on a top-level compatible string.
>> i.e. it's sole purpose is to handle those boards.
>>
>> (b) assumes non-general properties of those boards (e.g. that poking
>> certain SPI endpoints is safe).
>>
>> (c) applies arbitrary properties to the DT, applying in-built knowledge
>> of those boards (in addition to deep structural knowledge of the
>> DTB in question).
>>
>> To me, given the implicit knowledge, that qualifies as a "board file".
>>
>> As I mentioned at ELCE, if this had no knowledge of the boards in
>> question, I would be less concerned. e.g. if there was a well-defined
>> identification mechanism, describe in the DT, with fixups also defined
>> in the DT.
>
> And as I tried to explain before, for this specific use-case describing
> all this board specific knowledge in a generic manner in dt is simply
> impossible, unless we add a turing complete language to dt aka aml.
>
> I've a feeling that you're mixing this, rather special, use-case with
> the more generic use-case of daughter-boards for various small-board-computers
> I agree that for the SBC use-case it makes sense to try and come up with
> a shared core / dt bindings for much of this. Note that even this boards
> will still need a board (or board-family) specific method for getting
> the actual id from a daughter-board, but this board specific code could
> then pass the id to some more general hw-manager core which starts applying
> dt changes based on the id. But this assumes there is a single id to
> uniquely identify the extensions, which in my case there simply is not.
>
^ read above.
>>> 5. This is an exception, not the rule
>>>
>>> Yes this is introducing board (family of boards) specific c-code into the
>>> kernel, so in a way it is reminiscent of board files. But sometimes this is
>>> necessary, just look at all the vendor / platform specific code in the kernel
>>> in drivers/platform/x86, or all the places where DMI strings are used to
>>> uniquely identify a x86 board and adjust behavior.
>>>
>>> But this really is the exception, not the rule. I've written/upstreamed a
>>> number of drivers for q8 tablets hardware and if you look at e.g. the
>>> silead touchscreen driver then in linux-next this is already used for 5
>>> ARM dts files where no board specific C-code is involved at all.
>>>
>>> So this again is very different from the board file era, where C-code
>>> had to be used to fill device specific platform-data structs, here all
>>> necessary info is contained in the dt-binding and there are many users
>>> who do not need any board specific C-code in the kernel at all.
>>>
>>> So dt is working as it should and is avoiding board specific C-code for
>>> the majority of the cases. But sometimes hardware is not as we ideally
>>> would like it to be; and for those *exceptions* we are sometimes going
>>> to need C-code in the kernel, just like there is "board" specific C-code
>>> in the x86 code.
>>
>> Your talk convinced me that we're both going to see more variation
>> within this family of boards, and that we'll see more families of boards
>> following a similar patter. Given that, I think that we need a more
>> general solution, as I commented on the RFC.
>>
>> That doesn't necessarily mean that this can't happen in the kernel, but
>> it certainly needs to be more strictly defined, e.g. with match criteria
>> and fixups explicit in the DTB.
>
> The only answer I've to: "with match criteria and fixups explicit in the DTB"
> is: ok, give my a turing complete language inside DTB then, anything else
> will not suffice. So either we are doomed to reinvent ACPI; or we must
> accept some board(family) specific C-code in the kernel.
>
Please don?t let DT stagnate. We don?t have to repeat mistakes and we don?t
have to remain true to the spirit of what DT was supposed to be more than
a decade ago.
The problems we deal now are different, the industry is different and the
users are different.
We have to evolve along with them.
> Regards,
>
> Hans
Regards
? Pantelis
^ permalink raw reply
* [PATCH v6 5/5] ARM: DTS: da850: Add usb phy node
From: David Lechner @ 2016-10-27 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d55f19f2-beb3-a681-a6e9-c1d2c303173c@ti.com>
On 10/26/2016 05:26 AM, Sekhar Nori wrote:
> On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
>> Add a node for the new usb phy driver.
>
> changed this to:
>
> Add a node for usb phy device. This device
> controls both the USB 1.1 and USB 2.0 PHYs.
>
> mainly because the node is for the device, not the driver.
>
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
> Applied to v4.10/dt
>
> Thanks,
> Sekhar
>
I found a better way to represent this device as a child of the syscon
node. How should we handle the change? Should I submit a new patch that
applies on top of this one or will you drop this patch and I should send
a new one to take it's place?
Assuming that you agree that this is better:
cfgchip: cfgchip at 1417c {
compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
reg = <0x1417c 0x14>;
usb_phy: usb-phy {
compatible = "ti,da830-usb-phy";
#phy-cells = <1>;
status = "disabled";
};
};
Since the phy consists entirely as registers in the syscon device, we
should make it a child of the syscon device instead of a child of the
soc node.
^ permalink raw reply
* [PATCHv2] ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
From: Dinh Nguyen @ 2016-10-27 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027070626.s3wwiadf2iumxe4u@pengutronix.de>
On 10/27/2016 02:06 AM, Steffen Trumtrar wrote:
> On Wed, Oct 26, 2016 at 01:05:12PM -0500, dinguyen at opensource.altera.com wrote:
>> From: Dinh Nguyen <dinguyen@opensource.altera.com>
>>
>> Enable the QSPI node and add the flash chip.
>>
>> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
>> ---
>> v2: Remove partition entries for the SoCKIT
>> ---
>> arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>> index 02e22f5..2ce6736 100644
>> --- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>> +++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
>> @@ -175,6 +175,27 @@
>> status = "okay";
>> };
>>
>> +&qspi {
>> + status = "okay";
>> +
>> + flash: flash at 0 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "n25q256a";
>
> Did you test if this works correctly? According to my datasheet (Rev. C)
> the HPS qspi is a n25q00. The n25q256a is the other one.
>
No, I did not test this and thanks for catching it. On my SoCKIT, I see
a marking "25Q00AA" on the QSPI chip. So do you know if the compatible
string should be "n25q00a" or "n25q00". I guess I can test it.
Dinh
^ permalink raw reply
* [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver
From: Kevin Hilman @ 2016-10-27 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2694e4b5-20d5-f590-c6a6-55ff4cb8c16b@ti.com>
Tero Kristo <t-kristo@ti.com> writes:
> On 19/10/16 02:08, Nishanth Menon wrote:
>> Version 4 of the series is basically a rebase to v4.9-rc1, no functional
>> changes.
>
> Any final comments on this series, or shall I send a pull-req forward?
> Very minimal changes compared to v3 so should be good to go imo.
Not a comment on the series, but a question on TI-SCI.
Will the uC firmware be open like it was on AM335x?
Kevin
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Will Deacon @ 2016-10-27 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017185801.GT25086@rric.localdomain>
Hi Robert,
On Mon, Oct 17, 2016 at 08:58:01PM +0200, Robert Richter wrote:
> Mark, Will, any opinion here?
Having looking at this, I'm inclined to agree with you; pfn_valid() is
all about whether the underlying mem_map (struct page *) entry exists,
not about whether the page is mappable or not.
That said, setting the zone for pages representing NOMAP memory feels
like a slippery slope to losing information about them being NOMAP in
the first place and the whole problem getting out-of-hand. Whilst I'm
happy for pfn_valid() to return true (in the sense that we're within
bounds of mem_map etc), I'm less happy that we're also saying that the
struct page contains useful information, such as the zone and the node
information, which is then subsequently used by the NUMA code.
On top of that, pfn_valid is used in other places as a coarse "is this
memory?" check, and will cause things like ioremap to fail whereas it
wouldn't at the moment. It feels to me like NOMAP memory is a new type
of memory where there *is* a struct page, but it shouldn't be used for
anything. I don't think pfn_valid can describe that, given the way it's
currently used, and flipping the logic is just likely to move the problem
elsewhere.
What options do we have for fixing this in the NUMA code?
Will
^ permalink raw reply
* [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Richard Genoud @ 2016-10-27 16:04 UTC (permalink / raw)
To: linux-arm-kernel
After commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management
when hardware handshake is enabled"), the hardware handshake wasn't
functional anymore on Atmel platforms (beside SAMA5D2).
To understand why, one has to understand the flag ATMEL_US_USMODE_HWHS
first:
Before commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management
when hardware handshake is enabled"), this flag was never set.
Thus, the CTS/RTS where only handled by serial_core (and everything
worked just fine).
This commit introduced the use of the ATMEL_US_USMODE_HWHS flag,
enabling it for all boards when the user space enables flow control.
When the ATMEL_US_USMODE_HWHS is set, the Atmel USART controller
handles a part of the flow control job:
- disable the transmitter when the CTS pin gets high.
- drive the RTS pin high when the DMA buffer transfer is completed or
PDC RX buffer full or RX FIFO is beyond threshold. (depending on the
controller version).
NB: This feature is *not* mandatory for the flow control to work.
(Nevertheless, it's very useful if low latencies are needed.)
Now, the specifics of the ATMEL_US_USMODE_HWHS flag:
- For platforms with DMAC and no FIFOs (sam9x25, sam9x35, sama5D3,
sama5D4, sam9g15, sam9g25, sam9g35)* this feature simply doesn't work.
( source: https://lkml.org/lkml/2016/9/7/598 )
Tested it on sam9g35, the RTS pins always stays up, even when RXEN=1
or a new DMA transfer descriptor is set.
=> ATMEL_US_USMODE_HWHS must not be used for those platforms
- For platforms with a PDC (sam926{0,1,3}, sam9g10, sam9g20, sam9g45,
sam9g46)*, there's another kind of problem. Once the flag
ATMEL_US_USMODE_HWHS is set, the RTS pin can't be driven anymore via
RTSEN/RTSDIS in USART Control Register. The RTS pin can only be driven
by enabling/disabling the receiver or setting RCR=RNCR=0 in the PDC
(Receive (Next) Counter Register).
=> Doing this is beyond the scope of this patch and could add other
bugs, so the original (and working) behaviour should be set for those
platforms (meaning ATMEL_US_USMODE_HWHS flag should be unset).
- For platforms with a FIFO (sama5d2)*, the RTS pin is driven according
to the RX FIFO thresholds, and can be also driven by RTSEN/RTSDIS in
USART Control Register. No problem here.
(This was the use case of commit 1cf6e8fc8341 ("tty/serial: at91: fix
RTS line management when hardware handshake is enabled"))
NB: If the CTS pin declared as a GPIO in the DTS, (for instance
cts-gpios = <&pioA PIN_PB31 GPIO_ACTIVE_LOW>), the transmitter will be
disabled.
=> ATMEL_US_USMODE_HWHS flag can be set for this platform ONLY IF the
CTS pin is not a GPIO.
So, the only case when ATMEL_US_USMODE_HWHS can be enabled is when
(atmel_use_fifo(port) &&
!mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS))
Tested on all Atmel USART controller flavours:
AT91SAM9G35-CM (DMAC flavour), AT91SAM9G20-EK (PDC flavour),
SAMA5D2xplained (FIFO flavour).
* the list may not be exhaustive
Cc: <stable@vger.kernel.org> #4.4+ (beware, missing atmel_port variable)
Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
drivers/tty/serial/atmel_serial.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
Note for -stable:
This patch will apply on 4.4.x/4.8.x but compilation will fail due to
a missing variable atmel_port (introduced in 4.9-rc1):
static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
struct ktermios *old)
{
+ struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
unsigned long flags;
unsigned int old_mode, mode, imr, quot, baud;
Changes since v5:
- fix typos
- increase commentary
Changes since v4:
- the mctrl_gpio_use_rtscts() is gone since it was atmel_serial
specific. (so patch 1 is gone)
- patches 2 and 3 have been merged together since it didn't make
a lot of sense to correct the GPIO case in one separate patch.
- ATMEL_US_USMODE_HWHS is now unset for platform with PDC
Changes since v3:
- remove superfluous #include <linux/err.h> (thanks to Uwe)
- rebase on next-20160930
Changes since v2:
- remove IS_ERR_OR_NULL() test in patch 1/3 as Uwe suggested.
- fix typos in patch 2/3
- rebase on next-20160927
- simplify the logic in patch 3/3.
Changes since v1:
- Correct patch 1 with the error found by kbuild.
- Add Alexandre's Acked-by on patch 2
- Rewrite patch 3 logic in the light of the on-going discussion
with Cyrille and Alexandre.
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index fd8aa1f4ba78..168b10cad47b 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
mode |= ATMEL_US_USMODE_RS485;
} else if (termios->c_cflag & CRTSCTS) {
/* RS232 with hardware handshake (RTS/CTS) */
- if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
- dev_info(port->dev, "not enabling hardware flow control because DMA is used");
- termios->c_cflag &= ~CRTSCTS;
- } else {
+ if (atmel_use_fifo(port) &&
+ !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
+ /*
+ * with ATMEL_US_USMODE_HWHS set, the controller will
+ * be able to drive the RTS pin high/low when the RX
+ * FIFO is above RXFTHRES/below RXFTHRES2.
+ * It will also disable the transmitter when the CTS
+ * pin is high.
+ * This mode is not activated if CTS pin is a GPIO
+ * because in this case, the transmitter is always
+ * disabled (there must be an internal pull-up
+ * responsible for this behaviour).
+ * If the RTS pin is a GPIO, the controller won't be
+ * able to drive it according to the FIFO thresholds,
+ * but it will be handled by the driver.
+ */
mode |= ATMEL_US_USMODE_HWHS;
+ } else {
+ /*
+ * For platforms without FIFO, the flow control is
+ * handled by the driver.
+ */
+ mode |= ATMEL_US_USMODE_NORMAL;
}
} else {
/* RS232 without hadware handshake */
^ permalink raw reply related
* [PATCH v3] drivers: psci: PSCI checker module
From: Kevin Brodsky @ 2016-10-27 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027145446.GJ3716@linux.vnet.ibm.com>
On 27/10/16 15:54, Paul E. McKenney wrote:
> On Thu, Oct 27, 2016 at 01:51:57PM +0100, Kevin Brodsky wrote:
> > On 27/10/16 10:13, Lorenzo Pieralisi wrote:
> >> On Wed, Oct 26, 2016 at 11:11:48AM -0700, Paul E. McKenney wrote:
> >>> On Wed, Oct 26, 2016 at 06:35:34PM +0100, Lorenzo Pieralisi wrote:
> >>>> On Wed, Oct 26, 2016 at 10:22:52AM -0700, Paul E. McKenney wrote:
> >>>>> On Wed, Oct 26, 2016 at 06:10:06PM +0100, Lorenzo Pieralisi wrote:
> >>> [ . . . ]
> >>>
> >>>>>> Thanks a lot for your feedback, thoughts appreciated.
> >>>>> Let me ask the question more directly.
> >>>>>
> >>>>> Why on earth are we trying to run these tests concurrently?
> >>>> We must prevent that, no question about that, that's why I started
> >>>> this discussion. It is not fine to enable this checker and the
> >>>> RCU/LOCK torture hotplug tests at the same time.
> >>>>
> >>>>> After all, if we just run one at a time in isolation, there is no
> >>>>> problem.
> >>>> Fine by me, it was to understand if the current assumptions we made
> >>>> are correct and they are definitely not. If we enable the PSCI checker
> >>>> we must disable the torture rcu/lock hotplug tests either statically or
> >>>> dynamically.
> >>> What rcutorture, locktorture, and rcuperf do is to invoke
> >>> torture_init_begin(), which returns false if one of these tests
> >>> is already running.
> >>>
> >>> Perhaps we should extract this torture-test-exclusion and require
> >>> than conflicting torture tests invoke it?
> >> Yes if it can be extracted as a check (but it should also prevent the
> >> torture tests from running and vice versa), either that or Kconfig
> >> dependency (which we could do as a first step, waiting to add the
> >> required interface to the torture test code ?).
> >>
> >> Thanks !
> >> Lorenzo
> >
> > That sounds like a reasonable idea, but then that would mean that the PSCI checker
> > would have to wait until the torture test is finished if it is already running (and
> > the other way around).
> >
> > I wasn't aware that torture tests were hotplugging CPUs. I think that the most
> > sensible thing to do right now is to make CONFIG_PSCI_CHECKER depend on
> > !CONFIG_TORTURE_TEST (or maybe specifically !CONFIG_RCU_TORTURE_TEST &&
> > !CONFIG_LOCK_TORTURE_TEST). We can try to make them work together afterwards, but for
> > the sake of getting this patch merged in a reasonable amount of time, I think we
> > should just exclude the conflicting tests at the build level in this patch. I'll also
> > update the comment accordingly.
>
> I suggest !CONFIG_TORTURE_TEST, given that there are a couple of other
> tests in the offing.
>
> Thanx, Paul
Fair enough. If that's fine with Lorenzo, I'll add the dependency and post v4.
Thanks,
Kevin
^ permalink raw reply
* [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms
From: Nicolas Ferre @ 2016-10-27 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027160406.25738-1-richard.genoud@gmail.com>
Le 27/10/2016 ? 18:04, Richard Genoud a ?crit :
> After commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management
> when hardware handshake is enabled"), the hardware handshake wasn't
> functional anymore on Atmel platforms (beside SAMA5D2).
>
> To understand why, one has to understand the flag ATMEL_US_USMODE_HWHS
> first:
> Before commit 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management
> when hardware handshake is enabled"), this flag was never set.
> Thus, the CTS/RTS where only handled by serial_core (and everything
> worked just fine).
>
> This commit introduced the use of the ATMEL_US_USMODE_HWHS flag,
> enabling it for all boards when the user space enables flow control.
>
> When the ATMEL_US_USMODE_HWHS is set, the Atmel USART controller
> handles a part of the flow control job:
> - disable the transmitter when the CTS pin gets high.
> - drive the RTS pin high when the DMA buffer transfer is completed or
> PDC RX buffer full or RX FIFO is beyond threshold. (depending on the
> controller version).
>
> NB: This feature is *not* mandatory for the flow control to work.
> (Nevertheless, it's very useful if low latencies are needed.)
>
> Now, the specifics of the ATMEL_US_USMODE_HWHS flag:
>
> - For platforms with DMAC and no FIFOs (sam9x25, sam9x35, sama5D3,
> sama5D4, sam9g15, sam9g25, sam9g35)* this feature simply doesn't work.
> ( source: https://lkml.org/lkml/2016/9/7/598 )
> Tested it on sam9g35, the RTS pins always stays up, even when RXEN=1
> or a new DMA transfer descriptor is set.
> => ATMEL_US_USMODE_HWHS must not be used for those platforms
>
> - For platforms with a PDC (sam926{0,1,3}, sam9g10, sam9g20, sam9g45,
> sam9g46)*, there's another kind of problem. Once the flag
> ATMEL_US_USMODE_HWHS is set, the RTS pin can't be driven anymore via
> RTSEN/RTSDIS in USART Control Register. The RTS pin can only be driven
> by enabling/disabling the receiver or setting RCR=RNCR=0 in the PDC
> (Receive (Next) Counter Register).
> => Doing this is beyond the scope of this patch and could add other
> bugs, so the original (and working) behaviour should be set for those
> platforms (meaning ATMEL_US_USMODE_HWHS flag should be unset).
>
> - For platforms with a FIFO (sama5d2)*, the RTS pin is driven according
> to the RX FIFO thresholds, and can be also driven by RTSEN/RTSDIS in
> USART Control Register. No problem here.
> (This was the use case of commit 1cf6e8fc8341 ("tty/serial: at91: fix
> RTS line management when hardware handshake is enabled"))
> NB: If the CTS pin declared as a GPIO in the DTS, (for instance
> cts-gpios = <&pioA PIN_PB31 GPIO_ACTIVE_LOW>), the transmitter will be
> disabled.
> => ATMEL_US_USMODE_HWHS flag can be set for this platform ONLY IF the
> CTS pin is not a GPIO.
>
> So, the only case when ATMEL_US_USMODE_HWHS can be enabled is when
> (atmel_use_fifo(port) &&
> !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS))
>
> Tested on all Atmel USART controller flavours:
> AT91SAM9G35-CM (DMAC flavour), AT91SAM9G20-EK (PDC flavour),
> SAMA5D2xplained (FIFO flavour).
>
> * the list may not be exhaustive
>
> Cc: <stable@vger.kernel.org> #4.4+ (beware, missing atmel_port variable)
> Fixes: 1cf6e8fc8341 ("tty/serial: at91: fix RTS line management when hardware handshake is enabled")
> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks
> ---
> drivers/tty/serial/atmel_serial.c | 26 ++++++++++++++++++++++----
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> Note for -stable:
> This patch will apply on 4.4.x/4.8.x but compilation will fail due to
> a missing variable atmel_port (introduced in 4.9-rc1):
>
> static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> struct ktermios *old)
> {
> + struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> unsigned long flags;
> unsigned int old_mode, mode, imr, quot, baud;
>
> Changes since v5:
> - fix typos
> - increase commentary
>
> Changes since v4:
> - the mctrl_gpio_use_rtscts() is gone since it was atmel_serial
> specific. (so patch 1 is gone)
> - patches 2 and 3 have been merged together since it didn't make
> a lot of sense to correct the GPIO case in one separate patch.
> - ATMEL_US_USMODE_HWHS is now unset for platform with PDC
>
> Changes since v3:
> - remove superfluous #include <linux/err.h> (thanks to Uwe)
> - rebase on next-20160930
>
> Changes since v2:
> - remove IS_ERR_OR_NULL() test in patch 1/3 as Uwe suggested.
> - fix typos in patch 2/3
> - rebase on next-20160927
> - simplify the logic in patch 3/3.
>
> Changes since v1:
> - Correct patch 1 with the error found by kbuild.
> - Add Alexandre's Acked-by on patch 2
> - Rewrite patch 3 logic in the light of the on-going discussion
> with Cyrille and Alexandre.
>
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index fd8aa1f4ba78..168b10cad47b 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> mode |= ATMEL_US_USMODE_RS485;
> } else if (termios->c_cflag & CRTSCTS) {
> /* RS232 with hardware handshake (RTS/CTS) */
> - if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
> - dev_info(port->dev, "not enabling hardware flow control because DMA is used");
> - termios->c_cflag &= ~CRTSCTS;
> - } else {
> + if (atmel_use_fifo(port) &&
> + !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
> + /*
> + * with ATMEL_US_USMODE_HWHS set, the controller will
> + * be able to drive the RTS pin high/low when the RX
> + * FIFO is above RXFTHRES/below RXFTHRES2.
> + * It will also disable the transmitter when the CTS
> + * pin is high.
> + * This mode is not activated if CTS pin is a GPIO
> + * because in this case, the transmitter is always
> + * disabled (there must be an internal pull-up
> + * responsible for this behaviour).
> + * If the RTS pin is a GPIO, the controller won't be
> + * able to drive it according to the FIFO thresholds,
> + * but it will be handled by the driver.
> + */
> mode |= ATMEL_US_USMODE_HWHS;
> + } else {
> + /*
> + * For platforms without FIFO, the flow control is
> + * handled by the driver.
> + */
> + mode |= ATMEL_US_USMODE_NORMAL;
> }
> } else {
> /* RS232 without hadware handshake */
>
--
Nicolas Ferre
^ permalink raw reply
* [RFC PATCH 0/8] arm64: Add a compat vDSO
From: Kevin Brodsky @ 2016-10-27 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJwJo6aexCNNVoy9L+wqMJY1i1DVJix7UP1Z7exW1hGibHzJGQ@mail.gmail.com>
On 27/10/16 16:23, Dmitry Safonov wrote:
> 2016-09-08 17:00 GMT+03:00 Kevin Brodsky <kevin.brodsky@arm.com>:
>> Hi,
>>
>> This series adds support for a compat (AArch32) vDSO, providing two
>> userspace functionalities to compat processes:
>>
>> * "Virtual" time syscalls (gettimeofday and clock_gettime). The
>> implementation is an adaptation of the arm vDSO (vgettimeofday.c),
>> sharing the data page with the 64-bit vDSO.
>>
>> * sigreturn trampolines, following the example of the 64-bit vDSO
>> (sigreturn.S), but slightly more complicated because we provide A32
>> and T32 variants for both sigreturn and rt_sigreturn.
>>
>> The first point brings the performance improvement expected of a vDSO,
>> by implementing time syscalls directly in userspace. The second point
>> allows us to get rid of the compat vector page, at the expense of the
>> kuser helpers (this is one reason for not enabling the compat vDSO by
>> default).
>>
>> Unfortunately, this time we cannot escape using a 32-bit toolchain. To
>> build the compat VDSO, CONFIG_COMPAT_VDSO must be set *and*
>> CROSS_COMPILE_ARM32 must be defined to the prefix of a 32-bit compiler.
>> Failure to do so will not prevent building the kernel, but a warning
>> will be printed and the compat vDSO will not be built.
>>
>> I have only tested the series with a 64-bit userspace (+ 32-bit glibc).
>> Testing it with a 32-bit userspace would be very welcome.
>
> Hi, what's up with these patches, are you gonna resend them or prepare
> a new version?
Absolutely, actually I was working on it just now, sending v2 very soon :-)
Kevin
>> Thanks,
>> Kevin
>>
>> Kevin Brodsky (8):
>> arm64: Refactor vDSO setup
>> arm64: compat: Add time-related syscall numbers
>> arm64: compat: Expose offset to registers in sigframes
>> arm64: compat: Add a 32-bit vDSO
>> arm64: compat: 32-bit vDSO setup
>> arm64: elf: Set AT_SYSINFO_EHDR in compat processes
>> arm64: compat: Use vDSO sigreturn trampolines if available
>> arm64: Wire up and expose the new compat vDSO
>>
>> arch/arm64/Kconfig | 20 +++
>> arch/arm64/Makefile | 20 ++-
>> arch/arm64/include/asm/elf.h | 15 +-
>> arch/arm64/include/asm/signal32.h | 46 +++++
>> arch/arm64/include/asm/unistd.h | 2 +
>> arch/arm64/include/asm/vdso.h | 3 +
>> arch/arm64/kernel/Makefile | 8 +-
>> arch/arm64/kernel/asm-offsets.c | 13 ++
>> arch/arm64/kernel/signal32.c | 61 ++-----
>> arch/arm64/kernel/vdso.c | 198 ++++++++++++---------
>> arch/arm64/kernel/vdso32/Makefile | 121 +++++++++++++
>> arch/arm64/kernel/vdso32/sigreturn.S | 86 +++++++++
>> arch/arm64/kernel/vdso32/vdso.S | 32 ++++
>> arch/arm64/kernel/vdso32/vdso.lds.S | 98 +++++++++++
>> arch/arm64/kernel/vdso32/vgettimeofday.c | 294 +++++++++++++++++++++++++++++++
>> 15 files changed, 883 insertions(+), 134 deletions(-)
>> create mode 100644 arch/arm64/kernel/vdso32/Makefile
>> create mode 100644 arch/arm64/kernel/vdso32/sigreturn.S
>> create mode 100644 arch/arm64/kernel/vdso32/vdso.S
>> create mode 100644 arch/arm64/kernel/vdso32/vdso.lds.S
>> create mode 100644 arch/arm64/kernel/vdso32/vgettimeofday.c
>
^ 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