* RE: [PATCH] firmware: arm_scmi: Use {get,put}_unaligned_le32 accessors
From: David Laight @ 2019-08-07 15:18 UTC (permalink / raw)
To: 'Sudeep Holla', linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, Philipp Zabel
In-Reply-To: <20190807130038.26878-1-sudeep.holla@arm.com>
From: Sudeep Holla
> Sent: 07 August 2019 14:01
>
> Instead of type-casting the {tx,rx}.buf all over the place while
> accessing them to read/write __le32 from/to the firmware, let's use
> the nice existing {get,put}_unaligned_le32 accessors to hide all the
> type cast ugliness.
Why the 'unaligned' accessors?
> - *(__le32 *)t->tx.buf = cpu_to_le32(id);
> + put_unaligned_le32(id, t->tx.buf);
These will be expensive if the cpu doesn't support them.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFCv3 2/3] interconnect: Add imx core driver
From: Georgi Djakov @ 2019-08-07 15:16 UTC (permalink / raw)
To: Leonard Crestez, Rob Herring, Artur Świgoń,
Alexandre Bailon, Viresh Kumar
Cc: Mark Rutland, Dong Aisheng, Jacky Bai, Saravana Kannan,
Anson Huang, Stephen Boyd, Michael Turquette, linux-pm,
Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park, MyungJoo Ham,
linux-imx, kernel, Fabio Estevam, Shawn Guo, devicetree,
linux-arm-kernel
In-Reply-To: <2b8905754d9a3fa6f4dc7b73b45649c85aa3e80a.1565088423.git.leonard.crestez@nxp.com>
Hi Leonard,
On 8/6/19 13:55, Leonard Crestez wrote:
> This adds support for i.MX SoC family to interconnect framework.
>
> Platform drivers can describe their interconnect graph and
> several adjustment knobs where an icc node bandwith converted to a
s/bandwith/bandwidth/
> clk_min_rate request.
>
> All adjustable nodes are assumed to be independent.
>
> Based on an earlier work by Alexandre Bailon but greatly reduced to drop
> "platform opp" support.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Your Signed-off-by should be below Alexandre's.
> ---
> drivers/interconnect/Kconfig | 1 +
> drivers/interconnect/Makefile | 1 +
> drivers/interconnect/imx/Kconfig | 5 +
> drivers/interconnect/imx/Makefile | 1 +
> drivers/interconnect/imx/imx.c | 258 ++++++++++++++++++++++++++++++
> drivers/interconnect/imx/imx.h | 62 +++++++
> 6 files changed, 328 insertions(+)
> create mode 100644 drivers/interconnect/imx/Kconfig
> create mode 100644 drivers/interconnect/imx/Makefile
> create mode 100644 drivers/interconnect/imx/imx.c
> create mode 100644 drivers/interconnect/imx/imx.h
>
> diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
> index bfa4ca3ab7a9..e61802230f90 100644
> --- a/drivers/interconnect/Kconfig
> +++ b/drivers/interconnect/Kconfig
> @@ -10,7 +10,8 @@ menuconfig INTERCONNECT
> If unsure, say no.
>
> if INTERCONNECT
>
> source "drivers/interconnect/qcom/Kconfig"
> +source "drivers/interconnect/imx/Kconfig"
>
> endif
> diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
> index 28f2ab0824d5..20a13b7eb37f 100644
> --- a/drivers/interconnect/Makefile
> +++ b/drivers/interconnect/Makefile
> @@ -2,5 +2,6 @@
>
> icc-core-objs := core.o
>
> obj-$(CONFIG_INTERCONNECT) += icc-core.o
> obj-$(CONFIG_INTERCONNECT_QCOM) += qcom/
> +obj-$(CONFIG_INTERCONNECT_IMX) += imx/
> diff --git a/drivers/interconnect/imx/Kconfig b/drivers/interconnect/imx/Kconfig
> new file mode 100644
> index 000000000000..45fbae7007af
> --- /dev/null
> +++ b/drivers/interconnect/imx/Kconfig
> @@ -0,0 +1,5 @@
> +config INTERCONNECT_IMX
> + bool "i.MX interconnect drivers"
> + depends on ARCH_MXC || ARCH_MXC_ARM64 || COMPILE_TEST
> + help
> + Generic interconnect driver for i.MX SOCs
> diff --git a/drivers/interconnect/imx/Makefile b/drivers/interconnect/imx/Makefile
> new file mode 100644
> index 000000000000..bb92fd9fe4a5
> --- /dev/null
> +++ b/drivers/interconnect/imx/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_INTERCONNECT_IMX) += imx.o
> diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
> new file mode 100644
> index 000000000000..cc838e40419e
> --- /dev/null
> +++ b/drivers/interconnect/imx/imx.c
> @@ -0,0 +1,258 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Interconnect framework driver for i.MX SoC
> + *
> + * Copyright (c) 2019, BayLibre
> + * Copyright (c) 2019, NXP
> + * Author: Alexandre Bailon <abailon@baylibre.com>
> + * Author: Leonard Crestez <leonard.crestez@nxp.com>
> + */
> +
> +#include <linux/device.h>
> +#include <linux/interconnect-provider.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_qos.h>
> +#include <linux/devfreq.h>
Please sort alphabetically.
> +#include <linux/of.h>
> +
> +#include "imx.h"
> +
> +/* private icc_provider data */
> +struct imx_icc_provider {
> + struct device *dev;
> +};
> +
> +/* private icc_node data */
> +struct imx_icc_node {
> + const struct imx_icc_node_desc *desc;
> + struct devfreq *devfreq;
> + struct dev_pm_qos_request qos_req;
> +};
> +
> +static int imx_icc_aggregate(struct icc_node *node, u32 avg_bw,
> + u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
> +{
> + *agg_avg += avg_bw;
> + *agg_peak = max(*agg_peak, peak_bw);
> +
> + return 0;
> +}
> +
> +static struct icc_node* imx_icc_xlate(struct of_phandle_args *spec, void *data)
> +{
> + struct imx_icc_provider *desc = data;
> + struct icc_provider *provider = dev_get_drvdata(desc->dev);
> + unsigned int id = spec->args[0];
> + struct icc_node *node;
> +
> + list_for_each_entry (node, &provider->nodes, node_list)
> + if (node->id == id)
> + return node;
> +
> + return ERR_PTR(-EINVAL);
> +}
> +
> +static int imx_icc_node_set(struct icc_node *node)
> +{
> + struct device *dev = node->provider->dev;
> + struct imx_icc_node *node_data = node->data;
> + unsigned long freq;
> +
> + if (!node_data->devfreq)
> + return 0;
> +
> + freq = (node->avg_bw + node->peak_bw) * node_data->desc->adj->bw_mul;
> + do_div(freq, node_data->desc->adj->bw_div);
> + if (freq > INT_MAX) {
> + dev_err(dev, "%s can't request more INT_MAX freq\n",
> + node->name);
> + return -ERANGE;
> + }
> +
> + dev_dbg(dev, "%s avg_bw %u peak_bw %u min_freq %lu\n",
> + node->name, node->avg_bw, node->peak_bw, freq);
> +
> + dev_pm_qos_update_request(&node_data->qos_req, freq);
> +
> + return 0;
> +}
> +
> +static int imx_icc_set(struct icc_node *src, struct icc_node *dst)
> +{
> + return imx_icc_node_set(dst);
> +}
> +
> +static int imx_icc_node_init_devfreq(struct device *dev,
> + struct icc_node *node)
> +{
> + struct imx_icc_node *node_data = node->data;
> + const struct imx_icc_node_desc *node_desc = node_data->desc;
> + int index;
> + int ret;
> +
> + index = of_property_match_string(dev->of_node,
> + "devfreq-names", node_desc->adj->devfreq_name);
> + if (index < 0) {
> + dev_err(dev, "failed to match devfreq-names %s: %d\n",
> + node_desc->adj->devfreq_name, index);
> + return index;
> + }
> +
> + node_data->devfreq = devfreq_get_devfreq_by_phandle(dev, index);
> + if (IS_ERR(node_data->devfreq)) {
> + ret = PTR_ERR(node_data->devfreq);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "failed to fetch devfreq %d %s: %d\n",
> + index, node_desc->adj->devfreq_name, ret);
> + return ret;
> + }
> +
> + return dev_pm_qos_add_request(node_data->devfreq->dev.parent,
> + &node_data->qos_req,
> + DEV_PM_QOS_MIN_FREQUENCY, 0);
> +}
> +
> +static struct icc_node *imx_icc_node_add(struct icc_provider *provider,
> + const struct imx_icc_node_desc *node_desc)
> +{
> + struct imx_icc_provider *provider_data = provider->data;
> + struct device *dev = provider_data->dev;
> + struct imx_icc_node *node_data;
> + struct icc_node *node;
> + int ret;
> +
> + node = icc_node_create(node_desc->id);
> + if (IS_ERR(node)) {
> + dev_err(dev, "failed to create node %d\n", node_desc->id);
> + return node;
> + }
> +
> + if (node->data) {
> + dev_err(dev, "already created node %s id=%d\n",
> + node_desc->name, node_desc->id);
> + return ERR_PTR(-EEXIST);
> + }
> +
> + node_data = devm_kzalloc(dev, sizeof(*node_data), GFP_KERNEL);
> + if (!node_data) {
> + icc_node_destroy(node->id);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + node->name = node_desc->name;
> + node->data = node_data;
> + node_data->desc = node_desc;
> + if (node_desc->adj) {
> + ret = imx_icc_node_init_devfreq(dev, node);
> + if (ret < 0) {
> + icc_node_destroy(node->id);
> + return ERR_PTR(ret);
> + }
> + }
> +
> + icc_node_add(node, provider);
> +
> + return node;
> +}
> +
> +static void imx_icc_unregister_nodes(struct icc_provider *provider)
> +{
> + struct icc_node *node, *tmp;
> +
> + list_for_each_entry_safe(node, tmp, &provider->nodes, node_list) {
> + struct imx_icc_node *node_data = node->data;
> +
> + icc_node_del(node);
> + icc_node_destroy(node->id);
> + if (dev_pm_qos_request_active(&node_data->qos_req))
> + dev_pm_qos_remove_request(&node_data->qos_req);
> + }
> +}
> +
> +static int imx_icc_register_nodes(struct icc_provider *provider,
> + const struct imx_icc_node_desc *descs,
> + int count)
> +{
> + int ret;
> + int i;
> +
> + for (i = 0; i < count; i++) {
> + struct icc_node *node;
> + const struct imx_icc_node_desc *node_desc = &descs[i];
> + size_t j;
> +
> + node = imx_icc_node_add(provider, node_desc);
> + if (IS_ERR(node)) {
> + ret = PTR_ERR(node);
> + if (ret != -EPROBE_DEFER)
> + dev_err(provider->dev, "failed to add %s: %d\n",
> + node_desc->name, ret);
> + goto err;
> + }
> +
> + for (j = 0; j < node_desc->num_links; j++)
> + icc_link_create(node, node_desc->links[j]);
> + }
> +
> + return 0;
> +
> +err:
> + imx_icc_unregister_nodes(provider);
> +
> + return ret;
> +}
> +
> +int imx_icc_register(struct platform_device *pdev,
> + struct imx_icc_node_desc *nodes, int nodes_count)
> +{
> + struct device *dev = &pdev->dev;
> + struct imx_icc_provider *desc;
> + struct icc_provider *provider;
> + int ret;
> +
> + desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
> + if (!desc)
> + return -ENOMEM;
> + desc->dev = dev;
> +
> + provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL);
> + if (!provider)
> + return -ENOMEM;
> + provider->set = imx_icc_set;
> + provider->aggregate = imx_icc_aggregate;
> + provider->xlate = imx_icc_xlate;
> + provider->data = desc;
> + provider->dev = dev;
> + platform_set_drvdata(pdev, provider);
> +
> + ret = icc_provider_add(provider);
> + if (ret) {
> + dev_err(dev, "error adding interconnect provider\n");
> + return ret;
> + }
> +
> + ret = imx_icc_register_nodes(provider, nodes, nodes_count);
> + if (ret) {
> + dev_err(dev, "error adding interconnect nodes\n");
> + goto provider_del;
> + }
> +
> + return 0;
> +
> +provider_del:
> + icc_provider_del(provider);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(imx_icc_register);
> +
> +int imx_icc_unregister(struct platform_device *pdev)
> +{
> + struct icc_provider *provider = platform_get_drvdata(pdev);
> +
> + icc_provider_del(provider);
> + imx_icc_unregister_nodes(provider);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(imx_icc_unregister);
> diff --git a/drivers/interconnect/imx/imx.h b/drivers/interconnect/imx/imx.h
> new file mode 100644
> index 000000000000..ab191eb89616
> --- /dev/null
> +++ b/drivers/interconnect/imx/imx.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Interconnect framework driver for i.MX SoC
> + *
> + * Copyright (c) 2019, BayLibre
> + * Copyright (c) 2019, NXP
> + * Author: Alexandre Bailon <abailon@baylibre.com>
> + * Author: Leonard Crestez <leonard.crestez@nxp.com>
> + */
> +#ifndef __BUSFREQ_H
> +#define __BUSFREQ_H
Maybe __DRIVERS_INTERCONNECT_IMX_IMX_H to match with the path and filename.
> +
> +#include <linux/kernel.h>
> +
> +#define IMX_ICC_MAX_LINKS 32
2 seems enough?
> +#define IMX_ICC_UNDEFINED_BW 0xffffffff
Is this used?
> +
> +/*
> + * struct imx_icc_node_adj - Describe an dynamic adjustment knob
s/an/a/
> + */
> +struct imx_icc_node_adj_desc {
> + const char *devfreq_name;
> + unsigned int bw_mul, bw_div;
> +};
> +
> +/*
> + * struct imx_icc_node - Describe an interconnect node
> + * @name: name of the node
> + * @id: an unique id to identify the node
> + * @links: an array of slaves' node id
> + * @num_links: number of id defined in links
> + */
> +struct imx_icc_node_desc {
> + const char *name;
> + u16 id;
> + u16 links[IMX_ICC_MAX_LINKS];
> + u16 num_links;
> +
> + const struct imx_icc_node_adj_desc *adj;
> +};
> +
> +#define DEFINE_BUS_INTERCONNECT(_name, _id, _adj, _numlinks, ...) \
You can remove the _numlinks...
> + { \
> + .id = _id, \
> + .name = _name, \
> + .adj = _adj, \
> + .num_links = _numlinks, \
...and calculate the number of links automatically with:
.num_links = ARRAY_SIZE(((int[]){ __VA_ARGS__ })), \
> + .links = { __VA_ARGS__ }, \
> + }
> +
> +#define DEFINE_BUS_MASTER(_name, _id, _dest_id) \
> + DEFINE_BUS_INTERCONNECT(_name, _id, NULL, 1, _dest_id)
> +
> +#define DEFINE_BUS_SLAVE(_name, _id, _adj) \
> + DEFINE_BUS_INTERCONNECT(_name, _id, _adj, 0)
> +
> +int imx_icc_register(struct platform_device *pdev,
> + struct imx_icc_node_desc *nodes,
> + int nodes_count);
> +int imx_icc_unregister(struct platform_device *pdev);
> +
> +#endif /* __BUSFREQ_H */
Thanks,
Georgi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFCv3 1/3] dt-bindings: interconnect: Add bindings for imx
From: Georgi Djakov @ 2019-08-07 15:16 UTC (permalink / raw)
To: Leonard Crestez, Rob Herring, Artur Świgoń,
Alexandre Bailon, Viresh Kumar
Cc: Mark Rutland, Dong Aisheng, Jacky Bai, Saravana Kannan,
Anson Huang, Stephen Boyd, Michael Turquette, linux-pm,
Krzysztof Kozlowski, Chanwoo Choi, Kyungmin Park, MyungJoo Ham,
linux-imx, kernel, Fabio Estevam, Shawn Guo, devicetree,
linux-arm-kernel
In-Reply-To: <90561b14af66655ca859d387b3808a84641eea4e.1565088423.git.leonard.crestez@nxp.com>
Hi Leonard,
On 8/6/19 13:55, Leonard Crestez wrote:
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
Please put some commit text.
> .../devicetree/bindings/interconnect/imx.yaml | 38 +++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interconnect/imx.yaml
>
> diff --git a/Documentation/devicetree/bindings/interconnect/imx.yaml b/Documentation/devicetree/bindings/interconnect/imx.yaml
> new file mode 100644
> index 000000000000..c6f173b38f4f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interconnect/imx.yaml
> @@ -0,0 +1,38 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/interconnect/imx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic i.MX interconnect device
> +
> +maintainers:
> + - Leonard Crestez <leonard.crestez@nxp.com>
> +
> +properties:
> + compatible:
> + contains:
> + enum:
> + - fsl,imx8mm-interconnect
Maybe fsl,imx8mm-busfreq? I thought it's called busfreq in downstream, but it's
up to you.
> + "#interconnect-cells":
> + const: 1
> + devfreq-names:
> + description: Names of devfreq instances for adjustable nodes
> + devfreq:
> + description: List of phandle pointing to devfreq instances
> +
> +required:
> + - compatible
> + - "#interconnect-cells"
> + - "devfreq-names"
> + - "devfreq"
> +
> +examples:
> + - |
> + #include <dt-bindings/interconnect/imx8mm.h>
> + icc: interconnect {
> + compatible = "fsl,imx8mm-interconnect";
> + #interconnect-cells = <1>;
> + devfreq-names = "dram", "noc", "axi";
> + devfreq = <&ddrc>, <&noc>, <&pl301_main>;
> + };
>
Thanks,
Georgi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: KVM: hyp: debug-sr: Mark expected switch fall-throughs
From: Marc Zyngier @ 2019-08-07 15:11 UTC (permalink / raw)
To: Gustavo A. R. Silva, James Morse, Julien Thierry,
Suzuki K Poulose, Catalin Marinas, Will Deacon
Cc: kvmarm, linux-arm-kernel, linux-kernel
In-Reply-To: <20190807141857.GA4198@embeddedor>
On 07/08/2019 15:18, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings (Building: allmodconfig arm64):
>
> arch/arm64/kvm/hyp/debug-sr.c:20:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:21:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:22:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:23:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:24:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:25:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:26:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:27:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:28:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:29:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:30:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:31:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:32:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:33:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
> arch/arm64/kvm/hyp/debug-sr.c:34:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Already fixed (together with all the other KVM/arm warnings/bugs), and
pull request sent to Paolo.
Thanks,
M.
--
Jazz is not dead, it just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 2/4] perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
From: Lubashev, Igor @ 2019-08-07 14:56 UTC (permalink / raw)
To: Jiri Olsa, Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra,
linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190807114602.GB9605@krava>
On Wed, August 7 at 2019 7:46 AM Jiri Olsa wrote:
> On Tue, Aug 06, 2019 at 11:35:55PM -0400, Igor Lubashev wrote:
> > The kernel is using CAP_SYS_ADMIN instead of euid==0 to override
> > perf_event_paranoid check. Make perf do the same.
> >
> > Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
> > ---
> > tools/perf/arch/arm/util/cs-etm.c | 3 ++-
> > tools/perf/arch/arm64/util/arm-spe.c | 4 ++--
> > tools/perf/arch/x86/util/intel-bts.c | 3 ++-
> > tools/perf/arch/x86/util/intel-pt.c | 2 +-
> > tools/perf/util/evsel.c | 2 +-
> > 5 files changed, 8 insertions(+), 6 deletions(-)
> >
SNIP
> > --- a/tools/perf/arch/arm64/util/arm-spe.c
> > +++ b/tools/perf/arch/arm64/util/arm-spe.c
> > @@ -12,6 +12,7 @@
> > #include <time.h>
> >
> > #include "../../util/cpumap.h"
> > +#include "../../util/event.h"
> > #include "../../util/evsel.h"
> > #include "../../util/evlist.h"
> > #include "../../util/session.h"
> > @@ -65,8 +66,7 @@ static int arm_spe_recording_options(struct
> auxtrace_record *itr,
> > struct arm_spe_recording *sper =
> > container_of(itr, struct arm_spe_recording, itr);
> > struct perf_pmu *arm_spe_pmu = sper->arm_spe_pmu;
> > - struct evsel *evsel, *arm_spe_evsel = NULL;
>
> wouldn't this removal break the compilation on arm?
>
> jirka
>
> > - bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
> > + bool privileged = perf_event_paranoid_check(-1);
> > struct evsel *tracking_evsel;
> > int err;
>
> SNIP
Mea culpa! (An artifact of a bad rebase.) Just learned to cross-compile. Thanks, Alexey and Jirka!
The v3 with the fix has been posted (https://lkml.kernel.org/lkml/cover.1565188228.git.ilubashe@akamai.com).
- Igor
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4 11/11] docs: arm64: Add layout and 52-bit info to memory document
From: Will Deacon @ 2019-08-07 14:55 UTC (permalink / raw)
To: Steve Capper
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, Catalin Marinas,
bhsharma@redhat.com, maz@kernel.org, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190807132935.GB17012@capper-ampere.manchester.arm.com>
On Wed, Aug 07, 2019 at 01:29:38PM +0000, Steve Capper wrote:
> Many thanks for going through this series Catalin. Would you like me to post
> a V5 of the series?
/me does best Catalin impression...
"Yes, please."
Uncanny, eh?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/4] perf: Use capabilities instead of uid and euid
From: Igor Lubashev @ 2019-08-07 14:44 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
Series v1: https://lkml.kernel.org/lkml/1562112605-6235-1-git-send-email-ilubashe@akamai.com
Kernel is using capabilities instead of uid and euid to restrict access to
kernel pointers and tracing facilities. This patch series updates the perf to
better match the security model used by the kernel.
This series enables instructions in Documentation/admin-guide/perf-security.rst
to actually work, even when kernel.perf_event_paranoid=2 and
kernel.kptr_restrict=1.
The series consists of four patches:
01: perf: Add capability-related utilities
Add utility functions to check capabilities and perf_event_paranoid checks,
if libcap-dev[el] is available. (Otherwise, assume no capabilities.)
02: perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
Replace the use of euid==0 with a check for CAP_SYS_ADMIN whenever
perf_event_paranoid level is verified.
03: perf: Use CAP_SYSLOG with kptr_restrict checks
Replace the use of uid and euid with a check for CAP_SYSLOG when
kptr_restrict is verified (similar to kernel/kallsyms.c and lib/vsprintf.c).
Consult perf_event_paranoid when kptr_restrict==0 (see kernel/kallsyms.c).
04: perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace
Replace the use of euid==0 with a check for CAP_SYS_ADMIN before mounting
debugfs for ftrace.
I tested this by following Documentation/admin-guide/perf-security.rst
guidelines and setting sysctls:
kernel.perf_event_paranoid=2
kernel.kptr_restrict=1
As an unprivileged user who is in perf_users group (setup via instructions
above), I executed:
perf record -a -- sleep 1
Without the patch, perf record did not capture any kernel functions.
With the patch, perf included all kernel functions.
Changelog:
v3: * Fix arm64 compilation (thanks, Alexey and Jiri)
v2: * Added a build feature check for libcap-dev[el] as suggested by Arnaldo
Igor Lubashev (4):
perf: Add capability-related utilities
perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
perf: Use CAP_SYSLOG with kptr_restrict checks
perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace
tools/build/Makefile.feature | 2 ++
tools/build/feature/Makefile | 4 ++++
tools/build/feature/test-libcap.c | 20 ++++++++++++++++++++
tools/perf/Makefile.config | 11 +++++++++++
tools/perf/Makefile.perf | 2 ++
tools/perf/arch/arm/util/cs-etm.c | 3 ++-
tools/perf/arch/arm64/util/arm-spe.c | 3 ++-
tools/perf/arch/x86/util/intel-bts.c | 3 ++-
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/builtin-ftrace.c | 4 +++-
tools/perf/util/Build | 2 ++
tools/perf/util/cap.c | 29 +++++++++++++++++++++++++++++
tools/perf/util/cap.h | 24 ++++++++++++++++++++++++
tools/perf/util/event.h | 1 +
tools/perf/util/evsel.c | 2 +-
tools/perf/util/python-ext-sources | 1 +
tools/perf/util/symbol.c | 15 +++++++++++----
tools/perf/util/util.c | 9 +++++++++
18 files changed, 127 insertions(+), 10 deletions(-)
create mode 100644 tools/build/feature/test-libcap.c
create mode 100644 tools/perf/util/cap.c
create mode 100644 tools/perf/util/cap.h
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/4] perf: Add capability-related utilities
From: Igor Lubashev @ 2019-08-07 14:44 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565188228.git.ilubashe@akamai.com>
Add utilities to help checking capabilities of the running procss.
Make perf link with libcap, if it is available. If no libcap-dev[el],
assume no capabilities.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/build/Makefile.feature | 2 ++
tools/build/feature/Makefile | 4 ++++
tools/build/feature/test-libcap.c | 20 ++++++++++++++++++++
tools/perf/Makefile.config | 11 +++++++++++
tools/perf/Makefile.perf | 2 ++
tools/perf/util/Build | 2 ++
tools/perf/util/cap.c | 29 +++++++++++++++++++++++++++++
tools/perf/util/cap.h | 24 ++++++++++++++++++++++++
tools/perf/util/event.h | 1 +
tools/perf/util/python-ext-sources | 1 +
tools/perf/util/util.c | 9 +++++++++
11 files changed, 105 insertions(+)
create mode 100644 tools/build/feature/test-libcap.c
create mode 100644 tools/perf/util/cap.c
create mode 100644 tools/perf/util/cap.h
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 86b793dffbc4..8a19753cc26a 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -42,6 +42,7 @@ FEATURE_TESTS_BASIC := \
gtk2-infobar \
libaudit \
libbfd \
+ libcap \
libelf \
libelf-getphdrnum \
libelf-gelf_getnote \
@@ -110,6 +111,7 @@ FEATURE_DISPLAY ?= \
gtk2 \
libaudit \
libbfd \
+ libcap \
libelf \
libnuma \
numa_num_possible_cpus \
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 0658b8cd0e53..8499385365c0 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -20,6 +20,7 @@ FILES= \
test-libbfd-liberty.bin \
test-libbfd-liberty-z.bin \
test-cplus-demangle.bin \
+ test-libcap.bin \
test-libelf.bin \
test-libelf-getphdrnum.bin \
test-libelf-gelf_getnote.bin \
@@ -105,6 +106,9 @@ $(OUTPUT)test-fortify-source.bin:
$(OUTPUT)test-bionic.bin:
$(BUILD)
+$(OUTPUT)test-libcap.bin:
+ $(BUILD) -lcap
+
$(OUTPUT)test-libelf.bin:
$(BUILD) -lelf
diff --git a/tools/build/feature/test-libcap.c b/tools/build/feature/test-libcap.c
new file mode 100644
index 000000000000..d2a2e152195f
--- /dev/null
+++ b/tools/build/feature/test-libcap.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <sys/capability.h>
+#include <linux/capability.h>
+
+int main(void)
+{
+ cap_flag_value_t val;
+ cap_t caps = cap_get_proc();
+
+ if (!caps)
+ return 1;
+
+ if (cap_get_flag(caps, CAP_SYS_ADMIN, CAP_EFFECTIVE, &val) != 0)
+ return 1;
+
+ if (cap_free(caps) != 0)
+ return 1;
+
+ return 0;
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index e4988f49ea79..9a06787fedc6 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -824,6 +824,17 @@ ifndef NO_LIBZSTD
endif
endif
+ifndef NO_LIBCAP
+ ifeq ($(feature-libcap), 1)
+ CFLAGS += -DHAVE_LIBCAP_SUPPORT
+ EXTLIBS += -lcap
+ $(call detected,CONFIG_LIBCAP)
+ else
+ msg := $(warning No libcap found, disables capability support, please install libcap-devel/libcap-dev);
+ NO_LIBCAP := 1
+ endif
+endif
+
ifndef NO_BACKTRACE
ifeq ($(feature-backtrace), 1)
CFLAGS += -DHAVE_BACKTRACE_SUPPORT
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 67512a12276b..f9807d8c005b 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -88,6 +88,8 @@ include ../scripts/utilities.mak
#
# Define NO_LIBBPF if you do not want BPF support
#
+# Define NO_LIBCAP if you do not want process capabilities considered by perf
+#
# Define NO_SDT if you do not want to define SDT event in perf tools,
# note that it doesn't disable SDT scanning support.
#
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 7abf05131889..7cda749059a9 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -148,6 +148,8 @@ perf-$(CONFIG_ZLIB) += zlib.o
perf-$(CONFIG_LZMA) += lzma.o
perf-$(CONFIG_ZSTD) += zstd.o
+perf-$(CONFIG_LIBCAP) += cap.o
+
perf-y += demangle-java.o
perf-y += demangle-rust.o
diff --git a/tools/perf/util/cap.c b/tools/perf/util/cap.c
new file mode 100644
index 000000000000..c3ba841bbf37
--- /dev/null
+++ b/tools/perf/util/cap.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Capability utilities
+ */
+
+#ifdef HAVE_LIBCAP_SUPPORT
+
+#include "cap.h"
+#include <stdbool.h>
+#include <sys/capability.h>
+
+bool perf_cap__capable(cap_value_t cap)
+{
+ cap_flag_value_t val;
+ cap_t caps = cap_get_proc();
+
+ if (!caps)
+ return false;
+
+ if (cap_get_flag(caps, cap, CAP_EFFECTIVE, &val) != 0)
+ val = CAP_CLEAR;
+
+ if (cap_free(caps) != 0)
+ return false;
+
+ return val == CAP_SET;
+}
+
+#endif /* HAVE_LIBCAP_SUPPORT */
diff --git a/tools/perf/util/cap.h b/tools/perf/util/cap.h
new file mode 100644
index 000000000000..514b1f8992f6
--- /dev/null
+++ b/tools/perf/util/cap.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PERF_CAP_H
+#define __PERF_CAP_H
+
+#include <stdbool.h>
+#include <linux/capability.h>
+#include <linux/compiler.h>
+
+#ifdef HAVE_LIBCAP_SUPPORT
+
+#include <sys/capability.h>
+
+bool perf_cap__capable(cap_value_t cap);
+
+#else
+
+static inline bool perf_cap__capable(int cap __maybe_unused)
+{
+ return false;
+}
+
+#endif /* HAVE_LIBCAP_SUPPORT */
+
+#endif /* __PERF_CAP_H */
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 70841d115349..0e164e8ae28d 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -851,6 +851,7 @@ void cpu_map_data__synthesize(struct cpu_map_data *data, struct perf_cpu_map *m
void event_attr_init(struct perf_event_attr *attr);
int perf_event_paranoid(void);
+bool perf_event_paranoid_check(int max_level);
extern int sysctl_perf_event_max_stack;
extern int sysctl_perf_event_max_contexts_per_stack;
diff --git a/tools/perf/util/python-ext-sources b/tools/perf/util/python-ext-sources
index 235bd9803390..c6dd478956f1 100644
--- a/tools/perf/util/python-ext-sources
+++ b/tools/perf/util/python-ext-sources
@@ -7,6 +7,7 @@
util/python.c
../lib/ctype.c
+util/cap.c
util/evlist.c
util/evsel.c
util/cpumap.c
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 9c3c97697387..6fd130a5d8f2 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -16,10 +16,12 @@
#include <string.h>
#include <errno.h>
#include <limits.h>
+#include <linux/capability.h>
#include <linux/kernel.h>
#include <linux/log2.h>
#include <linux/time64.h>
#include <unistd.h>
+#include "cap.h"
#include "strlist.h"
#include "string2.h"
@@ -403,6 +405,13 @@ int perf_event_paranoid(void)
return value;
}
+
+bool perf_event_paranoid_check(int max_level)
+{
+ return perf_cap__capable(CAP_SYS_ADMIN) ||
+ perf_event_paranoid() <= max_level;
+}
+
static int
fetch_ubuntu_kernel_version(unsigned int *puint)
{
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on A64-OLinuXino
From: Maxime Ripard @ 2019-08-07 14:45 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: Sunil Mohan Adapa, Martin Ayotte, linux-arm-kernel
In-Reply-To: <CAGb2v66vcQxjoi-0hhCOesT59Loo7Bw5M9fX8eCBWv-wM1CnoA@mail.gmail.com>
Hi,
On Wed, Aug 07, 2019 at 08:09:19PM +0800, Chen-Yu Tsai wrote:
> On Wed, Aug 7, 2019 at 8:01 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Tue, Aug 06, 2019 at 02:25:17PM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Aug 5, 2019 at 8:58 PM Martin Ayotte <martinayotte@gmail.com> wrote:
> > > >
> > > > Fine for me too.
> > > >
> > > > Thanks .
> > > >
> > > > -----Message d'origine-----
> > > > De : Sunil Mohan Adapa [mailto:sunil@medhas.org]
> > > > Envoyé : Monday, August 05, 2019 1:25 AM
> > > > Ą : Chen-Yu Tsai
> > > > Cc : Maxime Ripard; Martin Ayotte; linux-arm-kernel
> > > > Objet : Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on
> > > > A64-OLinuXino
> > > >
> > > > On 04/08/19 8:33 pm, Chen-Yu Tsai wrote:
> > > > > On Fri, Aug 2, 2019 at 2:47 AM Sunil Mohan Adapa <sunil@medhas.org> wrote:
> > > > >>
> > > > >> On 01/08/19 6:49 am, Martin Ayotte wrote:
> > > > >>> If my SOB could help here, I don't mind since I've done the commit
> > > > >>> more than a year ago for Armbian ...
> > > > >>>
> > > > >>> Signed-off-by: Martin Ayotte <martinayotte@gmai.com>
> > > > >>> Tested-by: Martin Ayotte <martinayotte@gmai.com>
> > > > >> gmai.com is likely a typo.
> > > > >>
> > > > >>> On Wed, Jul 31, 2019 at 10:42 PM Chen-Yu Tsai <wens@csie.org
> > > > >>>
> > > > >>>> Thanks. The patch looks good overall. The authorship is a little
> > > > >>>> confusing though. If it was initially done by Martin (CC-ed), then
> > > > >>>> he should be the author, and we should get his Signed-off-by if
> > > > >>>> possible.
> > > > >>
> > > > >> Martin is indeed the original author of the patch. Thank you for
> > > > reviewing.
> > > > >
> > > > > I'd like to apply this patch with Martin as the author, if that's OK with
> > > > you
> > > > > both?
> > > >
> > > > That is completely okay with me.
> > >
> > > Applied for 5.4.
> > >
> > > I reordered the tags so they make more sense:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4&id=0834887732df5af41b59b2e4d530fc1f5478965f
> >
> > Sorry for being late on this, but it looks like the eMMC, NAND and SPI
> > pins are conflicting on the A64-Olinuxino design.
> >
> > There's no configuration with a NAND, so we don't really need to worry
> > about that, but if we merge this in the main DT, we'll prevent anyone
> > from using that DT on an olinuxino with a SPI flash.
> >
> > I think we should just create emmc and SPI-flash variants of that DT.
>
> Actually they aren't. Olimex specifically uses eMMC modules that don't
> use the data strobe line, so SPI can be used together.
Ah, right.
Still, this creates a precedent that I'm not really comfortable
with. Three actually.
Merging this in the main DT means three things:
- We're not consistent anymore, including within the olinuxino
boards only. A20 Olinuxino is pretty much in the same situation,
yet we dealt with it differently.
- This means that this will create a spurious device and report
errors in the kernel message and whenever someone will try to
access the device on boards that don't have it wired. This
shouldn't happen and we really shouldn't expose devices that just
aren't there, just like you don't have all the devices that are
not connected on your USB connector.
- Finally, this means that in order to keep it somewhat consistent,
we would have to merge the SPI flash in the main DT too. This will
prevent people without a SPI flash to use the SPI signals on the
UEXT connector for something else, which again goes against the
policy we've had for basically any other board.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Igor Lubashev @ 2019-08-07 14:44 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565188228.git.ilubashe@akamai.com>
Kernel is using CAP_SYSLOG capability instead of uid==0 and euid==0 when
checking kptr_restrict. Make perf do the same.
Also, the kernel is a more restrictive than "no restrictions" in case of
kptr_restrict==0, so add the same logic to perf.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/util/symbol.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 173f3378aaa0..046271103499 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -4,6 +4,7 @@
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
+#include <linux/capability.h>
#include <linux/kernel.h>
#include <linux/mman.h>
#include <linux/time64.h>
@@ -15,8 +16,10 @@
#include <inttypes.h>
#include "annotate.h"
#include "build-id.h"
+#include "cap.h"
#include "util.h"
#include "debug.h"
+#include "event.h"
#include "machine.h"
#include "map.h"
#include "symbol.h"
@@ -890,7 +893,11 @@ bool symbol__restricted_filename(const char *filename,
{
bool restricted = false;
- if (symbol_conf.kptr_restrict) {
+ /* Per kernel/kallsyms.c:
+ * we also restrict when perf_event_paranoid > 1 w/o CAP_SYSLOG
+ */
+ if (symbol_conf.kptr_restrict ||
+ (perf_event_paranoid() > 1 && !perf_cap__capable(CAP_SYSLOG))) {
char *r = realpath(filename, NULL);
if (r != NULL) {
@@ -2190,9 +2197,9 @@ static bool symbol__read_kptr_restrict(void)
char line[8];
if (fgets(line, sizeof(line), fp) != NULL)
- value = ((geteuid() != 0) || (getuid() != 0)) ?
- (atoi(line) != 0) :
- (atoi(line) == 2);
+ value = perf_cap__capable(CAP_SYSLOG) ?
+ (atoi(line) >= 2) :
+ (atoi(line) != 0);
fclose(fp);
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/4] perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
From: Igor Lubashev @ 2019-08-07 14:44 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565188228.git.ilubashe@akamai.com>
The kernel is using CAP_SYS_ADMIN instead of euid==0 to override
perf_event_paranoid check. Make perf do the same.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/arch/arm/util/cs-etm.c | 3 ++-
tools/perf/arch/arm64/util/arm-spe.c | 3 ++-
tools/perf/arch/x86/util/intel-bts.c | 3 ++-
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/util/evsel.c | 2 +-
5 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
index 5cb07e8cb296..b87a1ca2968f 100644
--- a/tools/perf/arch/arm/util/cs-etm.c
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -18,6 +18,7 @@
#include "../../perf.h"
#include "../../util/auxtrace.h"
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evlist.h"
#include "../../util/evsel.h"
#include "../../util/pmu.h"
@@ -254,7 +255,7 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
struct evsel *evsel, *cs_etm_evsel = NULL;
struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = (geteuid() == 0 || perf_event_paranoid() < 0);
+ bool privileged = perf_event_paranoid_check(-1);
int err = 0;
ptr->evlist = evlist;
diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
index 00915b8fd05b..29275a0544cd 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -12,6 +12,7 @@
#include <time.h>
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -66,7 +67,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
container_of(itr, struct arm_spe_recording, itr);
struct perf_pmu *arm_spe_pmu = sper->arm_spe_pmu;
struct evsel *evsel, *arm_spe_evsel = NULL;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
struct evsel *tracking_evsel;
int err;
diff --git a/tools/perf/arch/x86/util/intel-bts.c b/tools/perf/arch/x86/util/intel-bts.c
index 7b23318ebd7b..56a76142e9fd 100644
--- a/tools/perf/arch/x86/util/intel-bts.c
+++ b/tools/perf/arch/x86/util/intel-bts.c
@@ -12,6 +12,7 @@
#include <linux/zalloc.h>
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -107,7 +108,7 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
struct perf_pmu *intel_bts_pmu = btsr->intel_bts_pmu;
struct evsel *evsel, *intel_bts_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
btsr->evlist = evlist;
btsr->snapshot_mode = opts->auxtrace_snapshot_mode;
diff --git a/tools/perf/arch/x86/util/intel-pt.c b/tools/perf/arch/x86/util/intel-pt.c
index 218a4e694618..43d5088ee824 100644
--- a/tools/perf/arch/x86/util/intel-pt.c
+++ b/tools/perf/arch/x86/util/intel-pt.c
@@ -558,7 +558,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
bool have_timing_info, need_immediate = false;
struct evsel *evsel, *intel_pt_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
u64 tsc_bit;
int err;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 64bc32ed6dfa..eafc134bf17c 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -279,7 +279,7 @@ struct evsel *perf_evsel__new_idx(struct perf_event_attr *attr, int idx)
static bool perf_event_can_profile_kernel(void)
{
- return geteuid() == 0 || perf_event_paranoid() == -1;
+ return perf_event_paranoid_check(-1);
}
struct evsel *perf_evsel__new_cycles(bool precise)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 4/4] perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace
From: Igor Lubashev @ 2019-08-07 14:44 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565188228.git.ilubashe@akamai.com>
Kernel requires CAP_SYS_ADMIN instead of euid==0 to mount debugfs for ftrace.
Make perf do the same.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/builtin-ftrace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
index ae1466aa3b26..d09eac8a6d57 100644
--- a/tools/perf/builtin-ftrace.c
+++ b/tools/perf/builtin-ftrace.c
@@ -13,6 +13,7 @@
#include <signal.h>
#include <fcntl.h>
#include <poll.h>
+#include <linux/capability.h>
#include "debug.h"
#include <subcmd/parse-options.h>
@@ -21,6 +22,7 @@
#include "target.h"
#include "cpumap.h"
#include "thread_map.h"
+#include "util/cap.h"
#include "util/config.h"
@@ -281,7 +283,7 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, int argc, const char **argv)
.events = POLLIN,
};
- if (geteuid() != 0) {
+ if (!perf_cap__capable(CAP_SYS_ADMIN)) {
pr_err("ftrace only works for root!\n");
return -1;
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64: Disable big endian builds with clang
From: Robin Murphy @ 2019-08-07 14:41 UTC (permalink / raw)
To: Mark Brown, Nick Desaulniers
Cc: Tri Vo, Catalin Marinas, Nathan Huckleberry, clang-built-linux,
Nathan Chancellor, Will Deacon, Linux ARM
In-Reply-To: <20190807123809.GA4048@sirena.co.uk>
On 07/08/2019 13:38, Mark Brown wrote:
> On Tue, Aug 06, 2019 at 04:47:23PM -0700, Nick Desaulniers wrote:
>> On Tue, Aug 6, 2019 at 2:25 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
>>> On Tue, Aug 6, 2019 at 11:39 AM Mark Brown <broonie@kernel.org> wrote:
>
>> +Huck
>> Huck notes that the device eventually boots in qemu, it just takes on
>> the order of 165 seconds to boot. What's the timeout on KernelCI?
>
> It's not a timeout in kernelci, it's the kernel timing out being unable
> to find something in userspace being booted it can use as /init (there's
> a timeout in that process to cope with network filesystems). IIRC it's
> about 2 minutes. You can see this clearly in the logs I pointed you at:
>
> | You can see a bunch of reports here (all the big endian failures):
>
> | https://kernelci.org/boot/all/job/next/branch/master/kernel/next-20190730/
>
> For example:
>
> https://storage.kernelci.org/next/master/next-20190730/arm64/defconfig+CONFIG_CPU_BIG_ENDIAN=y/clang-8/lab-baylibre/boot-meson-gxbb-nanopi-k2.html
I thought it looked suspicious that there were EFI messages in that boot
log; from that job's config:
https://storage.kernelci.org/next/master/next-20190730/arm64/defconfig+CONFIG_CPU_BIG_ENDIAN=y/clang-8/kernel.config
...
# CONFIG_CPU_BIG_ENDIAN is not set
...
I think that's a kernelci problem...
Robin.
>
>> I think if we can determine why we see:
>> [ 144.626755] request_module: kmod_concurrent_max (0) close to 0
>> (max_modprobes: 50), for module binfmt-4c46, throttling...
>> [ 149.752826] request_module: modprobe binfmt-4c46 cannot be
>> processed, kmod busy with 50 threads for more than 5 seconds now
>
>> a lot, then we don't actually need to disable this outright when
>> building w/ Clang?
>
> Those error messages are happening because the kernel can't figure out
> how to execute a binary it's trying to run, like I say the module it's
> trying to load is binfmt_misc. If the kernel can't work out how to
> execute userspace it's not terribly useful.
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Sound-open-firmware] [PATCH v2 3/5] ASoC: SOF: Add DT DSP device support
From: Daniel Baluta @ 2019-08-07 14:39 UTC (permalink / raw)
To: Pierre-Louis Bossart
Cc: Mark Rutland, Aisheng Dong, Peng Fan, Fabio Estevam, Anson Huang,
Devicetree List, Daniel Baluta, S.j. Wang, Marco Felsch,
Linux Kernel Mailing List, Paul Olaru, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, Leonard Crestez, Shawn Guo,
linux-arm-kernel, sound-open-firmware
In-Reply-To: <CAEnQRZDr+gj_eiESLNbVUVy1rreRE1nnDgtb3g=CjaRF5Aq9Vw@mail.gmail.com>
On Wed, Jul 24, 2019 at 10:04 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>
> On Tue, Jul 23, 2019 at 6:19 PM Pierre-Louis Bossart
> <pierre-louis.bossart@linux.intel.com> wrote:
> >
> >
> > > diff --git a/sound/soc/sof/Kconfig b/sound/soc/sof/Kconfig
> > > index 61b97fc55bb2..2aa3a1cdf60c 100644
> > > --- a/sound/soc/sof/Kconfig
> > > +++ b/sound/soc/sof/Kconfig
> > > @@ -36,6 +36,15 @@ config SND_SOC_SOF_ACPI
> > > Say Y if you need this option
> > > If unsure select "N".
> > >
> > > +config SND_SOC_SOF_DT
> > > + tristate "SOF DT enumeration support"
> > > + select SND_SOC_SOF
> > > + select SND_SOC_SOF_OPTIONS
> > > + help
> > > + This adds support for Device Tree enumeration. This option is
> > > + required to enable i.MX8 devices.
> > > + Say Y if you need this option. If unsure select "N".
> > > +
> >
> > [snip]
> >
> > > diff --git a/sound/soc/sof/imx/Kconfig b/sound/soc/sof/imx/Kconfig
> > > index fff64a9970f0..fa35994a79c4 100644
> > > --- a/sound/soc/sof/imx/Kconfig
> > > +++ b/sound/soc/sof/imx/Kconfig
> > > @@ -12,6 +12,7 @@ if SND_SOC_SOF_IMX_TOPLEVEL
> > >
> > > config SND_SOC_SOF_IMX8
> > > tristate "SOF support for i.MX8"
> > > + select SND_SOC_SOF_DT
> >
> > This looks upside down. You should select SOF_DT first then include the
> > NXP stuff.
> >
> > > help
> > > This adds support for Sound Open Firmware for NXP i.MX8 platforms
> > > Say Y if you have such a device.
> > > diff --git a/sound/soc/sof/sof-dt-dev.c b/sound/soc/sof/sof-dt-dev.c
> > > new file mode 100644
> > > index 000000000000..31429bbb5c7e
> > > --- /dev/null
> > > +++ b/sound/soc/sof/sof-dt-dev.c
> > > @@ -0,0 +1,159 @@
> > > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> > > +//
> > > +// Copyright 2019 NXP
> > > +//
> > > +// Author: Daniel Baluta <daniel.baluta@nxp.com>
> > > +//
> > > +
> > > +#include <linux/firmware.h>
> > > +#include <linux/module.h>
> > > +#include <linux/pm_runtime.h>
> > > +#include <sound/sof.h>
> > > +
> > > +#include "ops.h"
> > > +
> > > +extern struct snd_sof_dsp_ops sof_imx8_ops;
> > > +
> > > +static char *fw_path;
> > > +module_param(fw_path, charp, 0444);
> > > +MODULE_PARM_DESC(fw_path, "alternate path for SOF firmware.");
> > > +
> > > +static char *tplg_path;
> > > +module_param(tplg_path, charp, 0444);
> > > +MODULE_PARM_DESC(tplg_path, "alternate path for SOF topology.");
> > > +
> > > +/* platform specific devices */
> > > +#if IS_ENABLED(CONFIG_SND_SOC_SOF_IMX8)
> > > +static struct sof_dev_desc sof_dt_imx8qxp_desc = {
> > > + .default_fw_path = "imx/sof",
> > > + .default_tplg_path = "imx/sof-tplg",
> > > + .nocodec_fw_filename = "sof-imx8.ri",
> > > + .nocodec_tplg_filename = "sof-imx8-nocodec.tplg",
> > > + .ops = &sof_imx8_ops,
> > > +};
> > > +#endif
> > > +
> > > +static const struct dev_pm_ops sof_dt_pm = {
> > > + SET_SYSTEM_SLEEP_PM_OPS(snd_sof_suspend, snd_sof_resume)
> > > + SET_RUNTIME_PM_OPS(snd_sof_runtime_suspend, snd_sof_runtime_resume,
> > > + NULL)
> > > +};
> > > +
> > > +static void sof_dt_probe_complete(struct device *dev)
> > > +{
> > > + /* allow runtime_pm */
> > > + pm_runtime_set_autosuspend_delay(dev, SND_SOF_SUSPEND_DELAY_MS);
> > > + pm_runtime_use_autosuspend(dev);
> > > + pm_runtime_enable(dev);
> > > +}
> > > +
> > > +static int sof_dt_probe(struct platform_device *pdev)
> > > +{
> > > + struct device *dev = &pdev->dev;
> > > + const struct sof_dev_desc *desc;
> > > + /*TODO: create a generic snd_soc_xxx_mach */
> > > + struct snd_soc_acpi_mach *mach;
> >
> > I wonder if you really need to use the same structures. For Intel we get
> > absolutely zero info from the firmware so rely on an ACPI codec ID as a
> > key to find information on which firmware and topology to use, and which
> > machine driver to load. You could have all this information in a DT blob?
>
> Yes. I see your point. I will still need to make a generic structure for
> snd_soc_acpi_mach so that everyone can use sof_nocodec_setup function.
>
> Maybe something like this:
>
> struct snd_soc_mach {
> union {
> struct snd_soc_acpi_mach acpi_mach;
> struct snd_soc_of_mach of_mach;
> }
> };
>
> and then change the prototype of sof_nocodec_setup.
Hi Pierre,
I fixed all the comments except the one above. Replacing snd_soc_acpi_mach
with a generic snd_soc_mach is not trivial task.
I wonder if it is acceptable to get the initial patches as they are
now and later switch to
generic ACPI/OF abstraction.
Asking this because for the moment on the i.MX side I have only
implemented no codec
version and we don't probe any of the machine drivers we have.
So, there is this only one member of snd_soc_acpi_mach that imx
version is making use of:
mach->drv_name = "sof-nocodec";
That's all.
I think the change as it is now is very clean and non-intrusive. Later
we will get options to
read firmware name and stuff from DT.
Anyhow, I don't think we can get rid of snd_dev_desc structure on
i.MX. This will be used
to store the information read from DT:
static struct sof_dev_desc sof_of_imx8qxp_desc = {
» .default_fw_path = "imx/sof",
» .default_tplg_path = "imx/sof-tplg",
» .nocodec_fw_filename = "sof-imx8.ri",
» .nocodec_tplg_filename = "sof-imx8-nocodec.tplg",
» .ops = &sof_imx8_ops,
};
For the moment we will only use the default values.
thanks,
Daniel.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Use {get,put}_unaligned_le32 accessors
From: Sudeep Holla @ 2019-08-07 14:37 UTC (permalink / raw)
To: Robin Murphy; +Cc: linux-arm-kernel, linux-kernel, Philipp Zabel
In-Reply-To: <4e6de98c-833b-a80b-acef-6e88391e80f2@arm.com>
On Wed, Aug 07, 2019 at 03:07:39PM +0100, Robin Murphy wrote:
> On 07/08/2019 14:57, Sudeep Holla wrote:
> > On Wed, Aug 07, 2019 at 03:36:11PM +0200, Philipp Zabel wrote:
> > > Hi Sudeep,
> > >
> > > On Wed, 2019-08-07 at 14:00 +0100, Sudeep Holla wrote:
> > > > Instead of type-casting the {tx,rx}.buf all over the place while
> > > > accessing them to read/write __le32 from/to the firmware, let's use
> > > > the nice existing {get,put}_unaligned_le32 accessors to hide all the
> > > > type cast ugliness.
> > > >
> > > > Suggested-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > > > ---
> > > > drivers/firmware/arm_scmi/base.c | 2 +-
> > > > drivers/firmware/arm_scmi/clock.c | 10 ++++------
> > > > drivers/firmware/arm_scmi/common.h | 2 ++
> > > > drivers/firmware/arm_scmi/perf.c | 8 ++++----
> > > > drivers/firmware/arm_scmi/power.c | 6 +++---
> > > > drivers/firmware/arm_scmi/reset.c | 2 +-
> > > > drivers/firmware/arm_scmi/sensors.c | 12 +++++-------
> > > > 7 files changed, 20 insertions(+), 22 deletions(-)
> > > >
> > > > diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
> > > > index 204390297f4b..f804e8af6521 100644
> > > > --- a/drivers/firmware/arm_scmi/base.c
> > > > +++ b/drivers/firmware/arm_scmi/base.c
> > > [...]
> > > > @@ -204,14 +204,12 @@ scmi_clock_rate_get(const struct scmi_handle *handle, u32 clk_id, u64 *value)
> > > > if (ret)
> > > > return ret;
> > > >
> > > > - *(__le32 *)t->tx.buf = cpu_to_le32(clk_id);
> > > > + put_unaligned_le32(clk_id, t->tx.buf);
> > > >
> > > > ret = scmi_do_xfer(handle, t);
> > > > if (!ret) {
> > > > - __le32 *pval = t->rx.buf;
> > > > -
> > > > - *value = le32_to_cpu(*pval);
> > > > - *value |= (u64)le32_to_cpu(*(pval + 1)) << 32;
> > > > + *value = get_unaligned_le32(t->rx.buf);
> > > > + *value |= (u64)get_unaligned_le32(t->rx.buf + 1) << 32;
> > >
> > > Isn't t->rx.buf a void pointer? If I am not mistaken, you'd either have
> > > to keep the pval local variables, or cast to (__le32 *) before doing
> > > pointer arithmetic.
> > >
> >
> > Ah right, that's the reason I added it at the first place. I will fix that.
>
> Couldn't you just use get_unaligned_le64() here anyway?
Indeed, that's what I found as I wanted to avoid pval, testing now.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFCv2 1/9] dt-bindings: mailbox: meson-mhu: convert to yaml
From: Maxime Ripard @ 2019-08-07 14:34 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-amlogic, robh+dt, jassisinghbrar, linux-arm-kernel,
devicetree
In-Reply-To: <20190805120320.32282-2-narmstrong@baylibre.com>
Hi,
On Mon, Aug 05, 2019 at 02:03:12PM +0200, Neil Armstrong wrote:
> Now that we have the DT validation in place, let's convert the device tree
> bindings for the Amlogic MHU controller over to a YAML schemas.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../mailbox/amlogic,meson-gxbb-mhu.yaml | 53 +++++++++++++++++++
> .../devicetree/bindings/mailbox/meson-mhu.txt | 34 ------------
> 2 files changed, 53 insertions(+), 34 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
> delete mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
> new file mode 100644
> index 000000000000..2536a0082cff
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 BayLibre, SAS
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/mailbox/amlogic,meson-gxbb-mhu.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Amlogic Meson Message-Handling-Unit Controller
> +
> +maintainers:
> + - Neil Armstrong <narmstrong@baylibre.com>
> +
> +description: |
> + The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller
> + that has 3 independent channels/links to communicate with remote processor(s).
> + MHU links are hardwired on a platform. A link raises interrupt for any
> + received data. However, there is no specified way of knowing if the sent
> + data has been read by the remote. This driver assumes the sender polls
> + STAT register and the remote clears it after having read the data.
> +
> +properties:
> + compatible:
> + enum:
> + - amlogic,meson-gxbb-mhu
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + minItems: 3
> + maxItems: 3
You don't need to specify both here. If one is missing, the tools will
fill it automatically with the other's value.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: fsl: add support for Hummingboard Pulse
From: Baruch Siach @ 2019-08-07 14:32 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
Cc: Baruch Siach, Jon Nettleton, linux-arm-kernel
From: Jon Nettleton <jon@solid-run.com>
The SolidRun Hummingboard Pulse carrier board carries the SolidRun
i.MX8MQ based SOM.
Notably missing is PCIe support that depends on analog PLLOUT clock.
Current imx clk driver does not support this clock.
Signed-off-by: Jon Nettleton <jon@solid-run.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../freescale/imx8mq-hummingboard-pulse.dts | 237 ++++++++++++++
.../boot/dts/freescale/imx8mq-sr-som.dtsi | 309 ++++++++++++++++++
3 files changed, 547 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index c043aca66572..6833b23e2dd2 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -22,6 +22,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts b/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
new file mode 100644
index 000000000000..653cad30deb7
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2018 Jon Nettleton <jon@solid-run.com>
+ */
+
+/dts-v1/;
+
+#include "imx8mq.dtsi"
+#include "imx8mq-sr-som.dtsi"
+
+/ {
+ model = "SolidRun i.MX8MQ HummingBoard Pulse";
+ compatible = "solidrun,hummingboard-pulse", "fsl,imx8mq";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_usdhc2_vmmc: usdhc2_vmmc {
+ compatible = "regulator-fixed";
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_5v0: regulator-v-5v0 {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "v_5v0";
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ imx8mq-sr-hb {
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* MikroBus Analog */
+ MX8MQ_IOMUXC_NAND_DATA05_GPIO3_IO11 0x41
+ /* MikroBus Reset */
+ MX8MQ_IOMUXC_SAI2_RXD0_GPIO4_IO23 0x41
+ /* The following 2 pins need to be commented out and
+ * reconfigured to enable RTS/CTS on UART3
+ */
+ /* MikroBus PWM */
+ MX8MQ_IOMUXC_ECSPI1_MISO_GPIO5_IO8 0x41
+ /* MikroBus INT */
+ MX8MQ_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x41
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C3_SCL_I2C3_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C3_SDA_I2C3_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_typec: typecgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_NAND_RE_B_GPIO3_IO15 0x16
+ MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x17059
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART2_TXD_UART2_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART2_RXD_UART2_DCE_RX 0x49
+ /* These pins are currently allocated to the
+ * uBLOX module on the SOM
+ */
+ /* MX8MQ_IOMUXC_UART4_RXD_UART2_DCE_CTS_B 0x49 */
+ /* MX8MQ_IOMUXC_UART4_TXD_UART2_DCE_RTS_B 0x49 */
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART3_TXD_UART3_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART3_RXD_UART3_DCE_RX 0x49
+ /* These pins are by default GPIO on the Mikro Bus
+ * Header. To use RTS/CTS on UART3 comment them out
+ * of the hoggrp and enable them here
+ */
+ /* MX8MQ_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x49 */
+ /* MX8MQ_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x49 */
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CD_B_GPIO2_IO12 0x41
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x83
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc3
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc3
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc3
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc3
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc3
+ MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x8d
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcd
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xcd
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xcd
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xcd
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xcd
+ MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x9f
+ MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xdf
+ MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xdf
+ MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xdf
+ MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xdf
+ MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xdf
+ MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1
+ >;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ typec_ptn5100: ptn5110@50 {
+ compatible = "usb,tcpci";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec>;
+ reg = <0x50>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <6 8>;
+ ss-sel-gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
+ src-pdos = <0x380190c8>;
+ snk-pdos = <0x380190c8 0x3802d0c8>;
+ max-snk-mv = <9000>;
+ max-snk-ma = <2000>;
+ op-snk-mw = <9000>;
+ max-snk-mw = <18000>;
+ port-type = "drp";
+ default-role = "sink";
+ };
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ rtc@69 {
+ compatible = "abracon,ab1805";
+ reg = <0x69>;
+ abracon,tc-diode = "schottky";
+ abracon,tc-resistor = <3>;
+ };
+};
+
+&uart2 { /* J35 header */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART2>;
+ assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
+ status = "okay";
+};
+
+&uart3 { /* Mikrobus */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART3>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>;
+ fsl,uart-has-rtscts;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ status = "okay";
+ extcon = <&typec_ptn5100>;
+ dr_mode = "otg";
+};
+
+&usb_dwc3_1 {
+ status = "okay";
+ dr_mode = "host";
+};
+
+&usb3_phy0 {
+ status = "okay";
+};
+
+&usb3_phy1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
new file mode 100644
index 000000000000..c19956ad4921
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
@@ -0,0 +1,309 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2018 Jon Nettleton <jon@solid-run.com>
+ */
+
+/ {
+ vdd_3v3: regulator-vdd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-always-on;
+ regulator-name = "vdd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&pgc_gpu{
+ power-supply = <&sw1a_reg>;
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ phy-reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <2>;
+ fsl,magic-packet;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <4>;
+ };
+ };
+};
+
+&iomuxc {
+ microsom {
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC 0x3
+ MX8MQ_IOMUXC_ENET_MDIO_ENET1_MDIO 0x23
+ MX8MQ_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
+ MX8MQ_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
+ MX8MQ_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
+ MX8MQ_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
+ MX8MQ_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
+ MX8MQ_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
+ MX8MQ_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
+ MX8MQ_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
+ MX8MQ_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
+ MX8MQ_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
+ MX8MQ_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
+ MX8MQ_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
+ MX8MQ_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x19
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C1_SCL_I2C1_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_pcie0: pcie0grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x74
+ MX8MQ_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 0x16
+ MX8MQ_IOMUXC_SAI2_RXFS_GPIO4_IO21 0x16
+ >;
+ };
+
+ pinctrl_qspi: qspigrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_NAND_ALE_QSPI_A_SCLK 0x82
+ MX8MQ_IOMUXC_NAND_CE0_B_QSPI_A_SS0_B 0x82
+ MX8MQ_IOMUXC_NAND_DATA00_QSPI_A_DATA0 0x82
+ MX8MQ_IOMUXC_NAND_DATA01_QSPI_A_DATA1 0x82
+ MX8MQ_IOMUXC_NAND_DATA02_QSPI_A_DATA2 0x82
+ MX8MQ_IOMUXC_NAND_DATA03_QSPI_A_DATA3 0x82
+
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART1_RXD_UART1_DCE_RX 0x49
+ MX8MQ_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49
+ MX8MQ_IOMUXC_NAND_CE1_B_GPIO3_IO2 0x19
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART4_TXD_UART4_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART4_RXD_UART4_DCE_RX 0x49
+ MX8MQ_IOMUXC_SAI3_TXD_GPIO5_IO1 0x19
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x83
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc3
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xc3
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xc3
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xc3
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xc3
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xc3
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xc3
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xc3
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xc3
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x83
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x8d
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xcd
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xcd
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xcd
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xcd
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xcd
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xcd
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xcd
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xcd
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xcd
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x8d
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x9f
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xdf
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xdf
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xdf
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xdf
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xdf
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xdf
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xdf
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xdf
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xdf
+ MX8MQ_IOMUXC_SD1_STROBE_USDHC1_STROBE 0x9f
+ MX8MQ_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0xc1
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0xc6
+ >;
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ pmic: pfuze100@8 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3ab {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ regulator-always-on;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+ };
+};
+
+&qspi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi>;
+ status = "okay";
+
+ /* SPI flash; not assembled by default */
+ n25q256a@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ compatible = "micron,n25q256a", "jedec,spi-nor";
+ spi-max-frequency = <29000000>;
+ status = "disabled";
+ };
+};
+
+&uart1 { /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART1>;
+ assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
+ assigned-clock-rates = <25000000>;
+ status = "okay";
+};
+
+&uart4 { /* ublox BT */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART4>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>;
+ assigned-clock-rates = <80000000>;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&pgc_vpu {
+ power-supply = <&sw1c_reg>;
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
From: Georgi Djakov @ 2019-08-07 14:21 UTC (permalink / raw)
To: Artur Świgoń, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel, linux-pm, dri-devel
Cc: Bartłomiej Żołnierkiewicz, sw0312.kim, krzk,
inki.dae, cw00.choi, myungjoo.ham, m.szyprowski
In-Reply-To: <62557522be4924a01d3822d4734c30f2965c608b.camel@partner.samsung.com>
Hi Artur,
On 8/1/19 10:59, Artur Świgoń wrote:
> Hi Georgi,
>
> On Fri, 2019-07-26 at 11:05 +0300, Georgi Djakov wrote:
>> Hi Artur,
>>
>> On 7/23/19 15:20, Artur Świgoń wrote:
>>> This patch adds interconnect functionality to the exynos-bus devfreq
>>> driver.
>>>
>>> The SoC topology is a graph (or, more specifically, a tree) and most of its
>>> edges are taken from the devfreq parent-child hierarchy (cf.
>>> Documentation/devicetree/bindings/devfreq/exynos-bus.txt). The previous
>>> patch adds missing edges to the DT (under the name 'parent'). Due to
>>> unspecified relative probing order, -EPROBE_DEFER may be propagated to
>>> guarantee that a child is probed before its parent.
>>>
>>> Each bus is now an interconnect provider and an interconnect node as well
>>> (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
>>> itself as a node. Node IDs are not hardcoded but rather assigned at
>>> runtime, in probing order (subject to the above-mentioned exception
>>> regarding relative order). This approach allows for using this driver with
>>> various Exynos SoCs.
>>
>> I am not familiar with the Exynos bus topology, but it seems to me that it's not
>> represented correctly. An interconnect provider with just a single node (port)
>> is odd. I would expect that each provider consists of multiple master and slave
>> nodes. This data would be used by a framework to understand what are the links
>> and how the traffic flows between the IP blocks and through which buses.
>
> To summarize the exynos-bus topology[1] used by the devfreq driver: There are
> many data buses for data transfer in Samsung Exynos SoC. Every bus has its own
> clock. Buses often share power lines, in which case one of the buses on the
> power line is referred to as 'parent' (or as 'devfreq' in the DT). In the
> particular case of Exynos4412[1][2], the topology can be expressed as follows:
>
> bus_dmc
> -- bus_acp
> -- bus_c2c
>
> bus_leftbus
> -- bus_rightbus
> -- bus_display
> -- bus_fsys
> -- bus_peri
> -- bus_mfc
>
> Where bus_dmc and bus_leftbus probably could be referred to as masters, and the
> following indented nodes as slaves. Patch 08/11 of this RFC additionally adds
> the following to the DT:
>
> bus_dmc
> -- bus_leftbus
>
> Which makes the topology a valid tree.
>
> The exynos-bus concept in devfreq[3] is designed in such a way that every bus is
> probed separately as a platform device, and is a largely independent entity.
>
> This RFC proposes an extension to the existing devfreq driver that basically
> provides a simple QoS to ensure minimum clock frequency for selected buses
> (possibly overriding devfreq governor calculations) using the interconnect
> framework.
>
> The hierarchy is modelled in such a way that every bus is an interconnect node.
> On the other hand, what is considered an interconnect provider here is quite
> arbitrary, but for the reasons mentioned in the above paragraph, this RFC
> assumes that every bus is a provider of itself as a node. Using an alternative
IIUC, in case we want to transfer data between the display and the memory
controller, the path would look like this:
display --> bus_display --> bus_leftbus --> bus_dmc --> memory
But the bus_display for example would have not one, but two nodes (ports),
right? One representing the link to the display controller and another one
representing the link to bus_leftbus? So i think that all the buses should
have at least two nodes, to represent each end of the wire.
> singleton provider approach was deemed more complicated since the 'dev' field in
> 'struct icc_provider' has to be set to something meaningful and we are tied to
> the 'samsung,exynos-bus' compatible string in the driver (and multiple instances
> of exynos-bus probed in indeterminate relative order).
>
Sure, the rest makes sense to me.
Thanks,
Georgi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: KVM: hyp: debug-sr: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-08-07 14:18 UTC (permalink / raw)
To: Marc Zyngier, James Morse, Julien Thierry, Suzuki K Poulose,
Catalin Marinas, Will Deacon
Cc: Gustavo A. R. Silva, kvmarm, linux-arm-kernel, linux-kernel
Mark switch cases where we are expecting to fall through.
This patch fixes the following warnings (Building: allmodconfig arm64):
arch/arm64/kvm/hyp/debug-sr.c:20:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:21:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:22:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:23:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:24:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:25:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:26:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:27:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:28:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:29:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:30:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:31:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:32:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:33:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arm64/kvm/hyp/debug-sr.c:34:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
arch/arm64/kvm/hyp/debug-sr.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
index 26781da3ad3e..0fc9872a1467 100644
--- a/arch/arm64/kvm/hyp/debug-sr.c
+++ b/arch/arm64/kvm/hyp/debug-sr.c
@@ -18,40 +18,70 @@
#define save_debug(ptr,reg,nr) \
switch (nr) { \
case 15: ptr[15] = read_debug(reg, 15); \
+ /* Fall through */ \
case 14: ptr[14] = read_debug(reg, 14); \
+ /* Fall through */ \
case 13: ptr[13] = read_debug(reg, 13); \
+ /* Fall through */ \
case 12: ptr[12] = read_debug(reg, 12); \
+ /* Fall through */ \
case 11: ptr[11] = read_debug(reg, 11); \
+ /* Fall through */ \
case 10: ptr[10] = read_debug(reg, 10); \
+ /* Fall through */ \
case 9: ptr[9] = read_debug(reg, 9); \
+ /* Fall through */ \
case 8: ptr[8] = read_debug(reg, 8); \
+ /* Fall through */ \
case 7: ptr[7] = read_debug(reg, 7); \
+ /* Fall through */ \
case 6: ptr[6] = read_debug(reg, 6); \
+ /* Fall through */ \
case 5: ptr[5] = read_debug(reg, 5); \
+ /* Fall through */ \
case 4: ptr[4] = read_debug(reg, 4); \
+ /* Fall through */ \
case 3: ptr[3] = read_debug(reg, 3); \
+ /* Fall through */ \
case 2: ptr[2] = read_debug(reg, 2); \
+ /* Fall through */ \
case 1: ptr[1] = read_debug(reg, 1); \
+ /* Fall through */ \
default: ptr[0] = read_debug(reg, 0); \
}
#define restore_debug(ptr,reg,nr) \
switch (nr) { \
case 15: write_debug(ptr[15], reg, 15); \
+ /* Fall through */ \
case 14: write_debug(ptr[14], reg, 14); \
+ /* Fall through */ \
case 13: write_debug(ptr[13], reg, 13); \
+ /* Fall through */ \
case 12: write_debug(ptr[12], reg, 12); \
+ /* Fall through */ \
case 11: write_debug(ptr[11], reg, 11); \
+ /* Fall through */ \
case 10: write_debug(ptr[10], reg, 10); \
+ /* Fall through */ \
case 9: write_debug(ptr[9], reg, 9); \
+ /* Fall through */ \
case 8: write_debug(ptr[8], reg, 8); \
+ /* Fall through */ \
case 7: write_debug(ptr[7], reg, 7); \
+ /* Fall through */ \
case 6: write_debug(ptr[6], reg, 6); \
+ /* Fall through */ \
case 5: write_debug(ptr[5], reg, 5); \
+ /* Fall through */ \
case 4: write_debug(ptr[4], reg, 4); \
+ /* Fall through */ \
case 3: write_debug(ptr[3], reg, 3); \
+ /* Fall through */ \
case 2: write_debug(ptr[2], reg, 2); \
+ /* Fall through */ \
case 1: write_debug(ptr[1], reg, 1); \
+ /* Fall through */ \
default: write_debug(ptr[0], reg, 0); \
}
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64: Disable big endian builds with clang
From: Mark Rutland @ 2019-08-07 14:14 UTC (permalink / raw)
To: Mark Brown
Cc: Tri Vo, Catalin Marinas, Nick Desaulniers, clang-built-linux,
Nathan Chancellor, Will Deacon, linux-arm-kernel
In-Reply-To: <20190807135618.GF54191@lakrids.cambridge.arm.com>
On Wed, Aug 07, 2019 at 02:56:19PM +0100, Mark Rutland wrote:
> On Wed, Aug 07, 2019 at 02:05:27PM +0100, Mark Brown wrote:
> > On Wed, Aug 07, 2019 at 02:01:11PM +0100, Mark Rutland wrote:
> > > On Tue, Aug 06, 2019 at 07:39:18PM +0100, Mark Brown wrote:
> >
> > > Judging by the kernel log linked in a reply, this is with:
> >
> > > * clang version 8.0.1-svn359952-1~exp1~20190504004501.65 (branches/release_80)
> >
> > > Is that the llvm.org binary release, or a custom build of clang?
> >
> > It's from a llvm.org .deb.
> >
> > > * Linux 5.3.0-rc2-next-20190730
> >
> > > Could we previously build a BE kernel with clang? If so, what's the
> > > last working kernel?
> >
> > As far as I know this has been broken for as long as we tried building
> > and booting big endian kernels in clang. The compile works fine, it's
> > just that the resulting binary doesn't seem to be working so well.
>
> I've just had a go, and it works for me. Log below from a BE busybox,
> but I also have a BE buildroot filesystem working.
>
> For reference, I'm using:
>
> * Linux v5.3-rc3 defconfig
> * LLVM 8.0.0 (x86_64) from llvm.org
> * GCC 8.1.0 (x86_64) from kernel.org crosstool
>
> ... so I don't think we should blacklist this just yet, but we certainly
> need to better understand the issue you're seeing. I'll have a go with
> LLVM 8.0.1 in case there's a regression from 8.0.0 to 8.0.1.
FWIW, using LLVM 8.0.1 also works for me, everything else being
unchanged.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: socfpga: Fix up button mapping on VINING FPGA
From: Dinh Nguyen @ 2019-08-07 14:10 UTC (permalink / raw)
To: Marek Vasut, linux-arm-kernel
In-Reply-To: <a7c317e9-22d2-965e-7143-b07014cb5dfe@denx.de>
Hi Marek,
On 8/7/19 6:13 AM, Marek Vasut wrote:
> On 6/28/19 2:19 AM, Marek Vasut wrote:
>> Add missing buttons and signals to the VINING FPGA device tree,
>> so they are presented to the userspace via gpio-keys evdev.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Dinh Nguyen <dinguyen@kernel.org>
>
> Bump ?
>
Sorry for being late on this. I've applied it and it was queued for
v5.3, but I missed the merged window. It's queued for v5.4.
Dinh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] drivers: firmware: psci: Decouple checker from generic ARM CPUidle
From: Daniel Lezcano @ 2019-08-07 14:09 UTC (permalink / raw)
To: Lorenzo Pieralisi, linux-pm
Cc: Mark Rutland, Ulf Hansson, Catalin Marinas, Rafael J. Wysocki,
LKML, Sudeep Holla, Will Deacon, LAKML
In-Reply-To: <20190722153745.32446-4-lorenzo.pieralisi@arm.com>
On 22/07/2019 17:37, Lorenzo Pieralisi wrote:
> The PSCI checker currently relies on the generic ARM CPUidle
> infrastructure to enter an idle state, which in turn creates
> a dependency that is not really needed.
>
> The PSCI checker code to test PSCI CPU suspend is built on
> top of the CPUidle framework and can easily reuse the
> struct cpuidle_state.enter() function (previously initialized
> by an idle driver, with a PSCI back-end) to trigger an entry
> into an idle state, decoupling the PSCI checker from the
> generic ARM CPUidle infrastructure and simplyfing the code
> in the process.
>
> Convert the PSCI checker suspend entry function to use
> the struct cpuidle_state.enter() function callback.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> drivers/firmware/psci/psci_checker.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/firmware/psci/psci_checker.c b/drivers/firmware/psci/psci_checker.c
> index f3659443f8c2..6a445397771c 100644
> --- a/drivers/firmware/psci/psci_checker.c
> +++ b/drivers/firmware/psci/psci_checker.c
> @@ -228,8 +228,11 @@ static int hotplug_tests(void)
>
> static void dummy_callback(struct timer_list *unused) {}
>
> -static int suspend_cpu(int index, bool broadcast)
> +static int suspend_cpu(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv, int index)
> {
> + struct cpuidle_state *state = &drv->states[index];
> + bool broadcast = state->flags & CPUIDLE_FLAG_TIMER_STOP;
> int ret;
>
> arch_cpu_idle_enter();
> @@ -254,11 +257,7 @@ static int suspend_cpu(int index, bool broadcast)
> }
> }
>
> - /*
> - * Replicate the common ARM cpuidle enter function
> - * (arm_enter_idle_state).
> - */
> - ret = CPU_PM_CPU_IDLE_ENTER(arm_cpuidle_suspend, index);
> + ret = state->enter(dev, drv, index);
>
> if (broadcast)
> tick_broadcast_exit();
> @@ -301,9 +300,8 @@ static int suspend_test_thread(void *arg)
> * doesn't use PSCI).
> */
> for (index = 1; index < drv->state_count; ++index) {
> - struct cpuidle_state *state = &drv->states[index];
> - bool broadcast = state->flags & CPUIDLE_FLAG_TIMER_STOP;
> int ret;
> + struct cpuidle_state *state = &drv->states[index];
>
> /*
> * Set the timer to wake this CPU up in some time (which
> @@ -318,7 +316,7 @@ static int suspend_test_thread(void *arg)
> /* IRQs must be disabled during suspend operations. */
> local_irq_disable();
>
> - ret = suspend_cpu(index, broadcast);
> + ret = suspend_cpu(dev, drv, index);
>
> /*
> * We have woken up. Re-enable IRQs to handle any
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Use {get,put}_unaligned_le32 accessors
From: Robin Murphy @ 2019-08-07 14:07 UTC (permalink / raw)
To: Sudeep Holla, Philipp Zabel; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20190807135757.GA27278@e107155-lin>
On 07/08/2019 14:57, Sudeep Holla wrote:
> On Wed, Aug 07, 2019 at 03:36:11PM +0200, Philipp Zabel wrote:
>> Hi Sudeep,
>>
>> On Wed, 2019-08-07 at 14:00 +0100, Sudeep Holla wrote:
>>> Instead of type-casting the {tx,rx}.buf all over the place while
>>> accessing them to read/write __le32 from/to the firmware, let's use
>>> the nice existing {get,put}_unaligned_le32 accessors to hide all the
>>> type cast ugliness.
>>>
>>> Suggested-by: Philipp Zabel <p.zabel@pengutronix.de>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>> drivers/firmware/arm_scmi/base.c | 2 +-
>>> drivers/firmware/arm_scmi/clock.c | 10 ++++------
>>> drivers/firmware/arm_scmi/common.h | 2 ++
>>> drivers/firmware/arm_scmi/perf.c | 8 ++++----
>>> drivers/firmware/arm_scmi/power.c | 6 +++---
>>> drivers/firmware/arm_scmi/reset.c | 2 +-
>>> drivers/firmware/arm_scmi/sensors.c | 12 +++++-------
>>> 7 files changed, 20 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
>>> index 204390297f4b..f804e8af6521 100644
>>> --- a/drivers/firmware/arm_scmi/base.c
>>> +++ b/drivers/firmware/arm_scmi/base.c
>> [...]
>>> @@ -204,14 +204,12 @@ scmi_clock_rate_get(const struct scmi_handle *handle, u32 clk_id, u64 *value)
>>> if (ret)
>>> return ret;
>>>
>>> - *(__le32 *)t->tx.buf = cpu_to_le32(clk_id);
>>> + put_unaligned_le32(clk_id, t->tx.buf);
>>>
>>> ret = scmi_do_xfer(handle, t);
>>> if (!ret) {
>>> - __le32 *pval = t->rx.buf;
>>> -
>>> - *value = le32_to_cpu(*pval);
>>> - *value |= (u64)le32_to_cpu(*(pval + 1)) << 32;
>>> + *value = get_unaligned_le32(t->rx.buf);
>>> + *value |= (u64)get_unaligned_le32(t->rx.buf + 1) << 32;
>>
>> Isn't t->rx.buf a void pointer? If I am not mistaken, you'd either have
>> to keep the pval local variables, or cast to (__le32 *) before doing
>> pointer arithmetic.
>>
>
> Ah right, that's the reason I added it at the first place. I will fix that.
Couldn't you just use get_unaligned_le64() here anyway?
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: defconfig: lpc32xx: enable lpc32xx GPIO driver
From: Sylvain Lemieux @ 2019-08-07 14:04 UTC (permalink / raw)
To: vz, arnd; +Cc: Sylvain Lemieux, linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
The change that allow the multiplatform build for the lpc32xx
platform add a new kernel config for the LPC32XX GPIO driver.
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Note:
* This patch depend on the following patchset:
ARM: move lpc32xx and dove to multiplatform
https://www.spinics.net/lists/linux-usb/msg183095.html
arch/arm/configs/lpc32xx_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/lpc32xx_defconfig b/arch/arm/configs/lpc32xx_defconfig
index 2d75bd8..09deb57 100644
--- a/arch/arm/configs/lpc32xx_defconfig
+++ b/arch/arm/configs/lpc32xx_defconfig
@@ -94,6 +94,7 @@ CONFIG_SERIAL_HS_LPC32XX_CONSOLE=y
# CONFIG_HW_RANDOM is not set
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_PNX=y
+CONFIG_GPIO_LPC32XX=y
CONFIG_SPI=y
CONFIG_SPI_PL022=y
CONFIG_GPIO_SYSFS=y
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] firmware: arm_scmi: Use {get,put}_unaligned_le32 accessors
From: Sudeep Holla @ 2019-08-07 13:57 UTC (permalink / raw)
To: Philipp Zabel; +Cc: linux-kernel, linux-arm-kernel, Sudeep Holla
In-Reply-To: <1565184971.5048.8.camel@pengutronix.de>
On Wed, Aug 07, 2019 at 03:36:11PM +0200, Philipp Zabel wrote:
> Hi Sudeep,
>
> On Wed, 2019-08-07 at 14:00 +0100, Sudeep Holla wrote:
> > Instead of type-casting the {tx,rx}.buf all over the place while
> > accessing them to read/write __le32 from/to the firmware, let's use
> > the nice existing {get,put}_unaligned_le32 accessors to hide all the
> > type cast ugliness.
> >
> > Suggested-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> > drivers/firmware/arm_scmi/base.c | 2 +-
> > drivers/firmware/arm_scmi/clock.c | 10 ++++------
> > drivers/firmware/arm_scmi/common.h | 2 ++
> > drivers/firmware/arm_scmi/perf.c | 8 ++++----
> > drivers/firmware/arm_scmi/power.c | 6 +++---
> > drivers/firmware/arm_scmi/reset.c | 2 +-
> > drivers/firmware/arm_scmi/sensors.c | 12 +++++-------
> > 7 files changed, 20 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
> > index 204390297f4b..f804e8af6521 100644
> > --- a/drivers/firmware/arm_scmi/base.c
> > +++ b/drivers/firmware/arm_scmi/base.c
> [...]
> > @@ -204,14 +204,12 @@ scmi_clock_rate_get(const struct scmi_handle *handle, u32 clk_id, u64 *value)
> > if (ret)
> > return ret;
> >
> > - *(__le32 *)t->tx.buf = cpu_to_le32(clk_id);
> > + put_unaligned_le32(clk_id, t->tx.buf);
> >
> > ret = scmi_do_xfer(handle, t);
> > if (!ret) {
> > - __le32 *pval = t->rx.buf;
> > -
> > - *value = le32_to_cpu(*pval);
> > - *value |= (u64)le32_to_cpu(*(pval + 1)) << 32;
> > + *value = get_unaligned_le32(t->rx.buf);
> > + *value |= (u64)get_unaligned_le32(t->rx.buf + 1) << 32;
>
> Isn't t->rx.buf a void pointer? If I am not mistaken, you'd either have
> to keep the pval local variables, or cast to (__le32 *) before doing
> pointer arithmetic.
>
Ah right, that's the reason I added it at the first place. I will fix that.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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