* [PATCH 1/2] KVM: Enforce error in ioctl for compat tasks when !KVM_COMPAT
From: Christian Borntraeger @ 2018-06-19 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e4d21bf-d30f-ac66-3017-2badf6a29ec5@arm.com>
On 06/19/2018 12:10 PM, Marc Zyngier wrote:
> On 19/06/18 11:01, Mark Rutland wrote:
>> On Tue, Jun 19, 2018 at 10:42:50AM +0100, Marc Zyngier wrote:
>>> The current behaviour of the compat ioctls is a bit odd.
>>> We provide a compat_ioctl method when KVM_COMPAT is set, and NULL
>>> otherwise. But NULL means that the normal, non-compat ioctl should
>>> be used directly for compat tasks, and there is no way to actually
>>> prevent a compat task from issueing KVM ioctls.
>>>
>>> This patch changes this behaviour, by always registering a compat_ioctl
>>> method, even if KVM_COMPAT is not selected. In that case, the callback
>>> will always return -EINVAL.
>>>
>>> Reported-by: Mark Rutland <mark.rutland@arm.com>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>
>> I virt/kvm/Kconfig we have:
>>
>> config KVM_COMPAT
>> def_bool y
>> depends on KVM && COMPAT && !S390
>>
>> ... and in arch/s390 we have COMPAT support, so does this potentially break
>> anything there?
>
> It doesn't seem to (COMPAT seems to support the 31 bit stuff, which I
> don't think ever had KVM support), but my s390-foo is quite basic.
>
> Christian, could you help here?
We do not support KVM for 31 bit. So the original goal of the KVM_COMPAT stuff
was to actually disable the compat thing for the KVM device driver.
See
commit de8e5d744051568c8aad ("KVM: Disable compat ioctl for s390").
Now looking back, this patch actually only disabled the compat wrappers and
still allows an 31bit process to run the 64bit ioctls. In theory this should
cause no issues as the 64bit ioctl must fence off all invalid input anyway
but actually forbidding KVM for compat processes is even better.
So I think this patch actually is a good thing.
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
if you want you could even add a
Fixes: tag.
^ permalink raw reply
* [PATCHv3 01/19] arm64: consistently use unsigned long for thread flags
From: Mark Rutland @ 2018-06-19 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619104939.likbams3ly5c5ugu@armageddon.cambridge.arm.com>
On Tue, Jun 19, 2018 at 11:49:40AM +0100, Catalin Marinas wrote:
> On Mon, Jun 18, 2018 at 01:02:52PM +0100, Mark Rutland wrote:
> > In do_notify_resume, we manipulate thread_flags as a 32-bit unsigned
> > int, whereas thread_info::flags is a 64-bit unsigned long, and elsewhere
> > (e.g. in the entry assembly) we manipulate the flags as a 64-bit
> > quantity.
> >
> > For consistency, and to avoid problems if we end up with more than 32
> > flags, let's make do_notify_resume take the flags as a 64-bit unsigned
> > long.
>
> When we get to more than 32 flags, you may want to modify the _TIF_*
> definitions as well to (UL(1) << TIF_*).
Agreed. I can spin a patch or two for a that as a subsequent cleanup.
> In the meantime:
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cheers!
Mark.
^ permalink raw reply
* [Dev] [PATCH 4/5] RFC: bus: 96boards Low-Speed Connector
From: Daniel Thompson @ 2018-06-19 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-5-linus.walleij@linaro.org>
On Mon, Jun 18, 2018 at 09:45:55AM +0200, Linus Walleij wrote:
> This illustrates my idea for using a small connector driver to
> plug in "mezzanine boards" on the 96boards low-speed connector.
>
> These "mezzanine boards" are no different than "capes", "logic
> modules", etc. This thing, a non-discoverable connector where
> a user can plug in a few peripherals has been reinvented a few
> times.
>
> As a proof-of-concept we add the Secure96, a quite minimal
> mezzanine board.
>
> Users can register their boards in a simple way. Either just
> add their compatible-string in the device tree:
>
> board {
> compatible = "96boards,secure96";
> };
>
> And if they can't even change three lines in their device tree,
> or if they at runtime decide to plug in some board and test it,
> they can use sysfs, as exemplified by plugging in the secure96
> security board at runtime:
>
> > cd /sys/devices/platform/connector
> > echo 1 > secure96
> [ 61.014629] lscon connector: called mezzanine_store on secure96
> [ 61.020530] lscon connector: populate secure96
> [ 61.027081] at24 1-0050: 2048 byte 24c128 EEPROM, writable, 128 bytes/write
> [ 61.053569] atmel-ecc 1-0060: configuration zone is unlocked
> [ 61.502535] tpm_tis_spi spi0.0: 2.0 TPM (device-id 0x1B, rev-id 16)
> (...)
>
> The plug-in board can be removed from sysfs and added back
> again multiple times like this with the devices being runtime
> added and removed by two writes to sysfs.
>
> > echo 0 > secure96
> > echo 1 > secure96
> > echo 0 > secure96
> (...)
Having a sysfs interface is useful (I certainly love being able to use
sysfs to manage ad-hoc I2C chains).
However it feels like the current blurring between connector device and
mezzanine device is shining through in this interface if only because
the look and feel is very different to instantiating an I2C device from
user-space.
Daniel.
^ permalink raw reply
* [PATCH] dt-bindings: Fix unbalanced quotation marks
From: Srinivas Kandagatla @ 2018-06-19 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617143127.11421-1-j.neuschaefer@gmx.net>
On 17/06/18 15:31, Jonathan Neusch?fer wrote:
> example:
> diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
> index 6a4aadc4ce06..84b28dbe9f15 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
> +++ b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt
> @@ -30,7 +30,7 @@ Required properties:
>
> Board connectors:
> * Headset Mic
> - * Secondary Mic",
> + * Secondary Mic
> * DMIC
> * Ext Spk
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
> index aa54e49fc8a2..c7600a93ab39 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
> +++ b/Documentation/devicetree/bindings/sound/qcom,apq8096.txt
> @@ -35,7 +35,7 @@ This binding describes the APQ8096 sound card, which uses qdsp for audio.
> "Digital Mic3"
>
> Audio pins and MicBias on WCD9335 Codec:
> - "MIC_BIAS1
> + "MIC_BIAS1"
> "MIC_BIAS2"
> "MIC_BIAS3"
> "MIC_BIAS4"
for apq8016 and apq8096 parts:
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
^ permalink raw reply
* [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
From: A.s. Dong @ 2018-06-19 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502100401.qmik5goglbuiqcaa@pengutronix.de>
Hi Sascha,
> -----Original Message-----
> From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> Sent: Wednesday, May 2, 2018 6:04 PM
> To: A.s. Dong <aisheng.dong@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; dl-linux-imx
> <linux-imx@nxp.com>; kernel at pengutronix.de; Fabio Estevam
> <fabio.estevam@nxp.com>; shawnguo at kernel.org
> Subject: Re: [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
>
> On Sat, Apr 28, 2018 at 02:46:16AM +0800, Dong Aisheng wrote:
> > +/* Initialization of the MU code. */
> > +int __init imx8_scu_init(void)
> > +{
> > + struct device_node *np, *mu_np;
> > + struct resource mu_res;
> > + sc_err_t sci_err;
> > + int ret;
> > +
> > + if (!of_machine_is_compatible("fsl,imx8qxp"))
> > + return 0;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "nxp,imx8qxp-scu");
> > + if (!np)
> > + return -ENODEV;
> > +
> > + mu_np = of_parse_phandle(np, "fsl,mu", 0);
> > + if (WARN_ON(!mu_np))
> > + return -EINVAL;
> > +
> > + ret = of_address_to_resource(mu_np, 0, &mu_res);
> > + if (WARN_ON(ret))
> > + return -EINVAL;
> > +
> > + /* we use mu physical address as IPC communication channel ID */
> > + sci_err = sc_ipc_open(&scu_ipc_handle, (sc_ipc_id_t)(mu_res.start));
> > + if (sci_err != SC_ERR_NONE) {
> > + pr_err("Cannot open MU channel to SCU\n");
> > + return sci_err;
> > + };
>
> Introducing private error codes always has the risk of just forwarding them as
> errno codes as done here.
>
> > +
> > + of_node_put(mu_np);
> > +
> > + pr_info("NXP i.MX SCU Initialized (scu_ipc %u)\n", scu_ipc_handle);
> > +
> > + return 0;
> > +}
> > +early_initcall(imx8_scu_init);
>
> This code shows that the separate 'scu' device node shouldn't exist. It is only
> used as a stepping stone to find the 'mu' node. Instead of providing a proper
> driver for the 'mu' node the scu code registers it with its physical address.
> I don't think it makes sense to separate mu and scu code in this way.
>
> > +#define RPC_VER(MSG) ((MSG)->version)
> > +#define RPC_SIZE(MSG) ((MSG)->size)
> > +#define RPC_SVC(MSG) ((MSG)->svc)
> > +#define RPC_FUNC(MSG) ((MSG)->func)
> > +#define RPC_R8(MSG) ((MSG)->func)
> > +#define RPC_I32(MSG, IDX) ((MSG)->DATA.i32[(IDX) / 4])
> > +#define RPC_I16(MSG, IDX) ((MSG)->DATA.i16[(IDX) / 2])
> > +#define RPC_I8(MSG, IDX) ((MSG)->DATA.i8[(IDX)])
> > +#define RPC_U32(MSG, IDX) ((MSG)->DATA.u32[(IDX) / 4])
> > +#define RPC_U16(MSG, IDX) ((MSG)->DATA.u16[(IDX) / 2])
> > +#define RPC_U8(MSG, IDX) ((MSG)->DATA.u8[(IDX)])
>
> These macros only make the code less readable, please drop them. Plain
> m->version is easier to read and forces the reader through less
> indirections. IMO m->DATA.u32[0] = foo; m->DATA.u8[4] = bar is still better
> readable than doing the division by size in macros.
>
> > +typedef enum sc_rpc_async_state_e {
> > + SC_RPC_ASYNC_STATE_RD_START = 0,
> > + SC_RPC_ASYNC_STATE_RD_ACTIVE = 1,
> > + SC_RPC_ASYNC_STATE_RD_DONE = 2,
> > + SC_RPC_ASYNC_STATE_WR_START = 3,
> > + SC_RPC_ASYNC_STATE_WR_ACTIVE = 4,
> > + SC_RPC_ASYNC_STATE_WR_DONE = 5,
> > +} sc_rpc_async_state_t;
> > +
> > +typedef struct sc_rpc_async_msg_s {
> > + sc_rpc_async_state_t state;
> > + uint8_t wordIdx;
> > + sc_rpc_msg_t msg;
> > + uint32_t timeStamp;
> > +} sc_rpc_async_msg_t;
>
> We normally do not typedef struct types. Any good reasons to do so here?
>
> > +
> > +/* Functions */
> > +
> > +/*
> > + * This is an internal function to send an RPC message over an IPC
> > + * channel. It is called by client-side SCFW API function shims.
> > + *
> > + * @param[in] ipc IPC handle
> > + * @param[in,out] msg handle to a message
> > + * @param[in] no_resp response flag
> > + *
> > + * If no_resp is false then this function waits for a response
> > + * and returns the result in msg.
> > + */
> > +void sc_call_rpc(sc_ipc_t ipc, sc_rpc_msg_t *msg, bool no_resp);
> > +
> > +/*
> > + * This is an internal function to dispath an RPC call that has
> > + * arrived via IPC over an MU. It is called by server-side SCFW.
> > + *
> > + * @param[in] mu MU message arrived on
> > + * @param[in,out] msg handle to a message
> > + *
> > + * The function result is returned in msg.
> > + */
> > +void sc_rpc_dispatch(sc_rsrc_t mu, sc_rpc_msg_t *msg);
>
> Declared but never defined.
>
> > +
> > +/*
> > + * This function translates an RPC message and forwards on to the
> > + * normal RPC API. It is used only by hypervisors.
> > + *
> > + * @param[in] ipc IPC handle
> > + * @param[in,out] msg handle to a message
> > + *
> > + * This function decodes a message, calls macros to translate the
> > + * resources, pins, addresses, partitions, memory regions, etc. and
> > + * then forwards on to the hypervisors SCFW API.Return results are
> > + * translated back abd placed back into the message to be returned
> > + * to the original API.
> > + */
> > +void sc_rpc_xlate(sc_ipc_t ipc, sc_rpc_msg_t *msg);
>
> ditto.
>
> > +
> > +#endif /* _SC_RPC_H */
> > diff --git a/drivers/soc/imx/sc/svc/irq/rpc.h
> > b/drivers/soc/imx/sc/svc/irq/rpc.h
> > new file mode 100644
> > index 0000000..0de8718
> > --- /dev/null
> > +++ b/drivers/soc/imx/sc/svc/irq/rpc.h
> > @@ -0,0 +1,41 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Copyright 2017~2018 NXP
> > + *
> > + * Header file for the IRQ RPC implementation.
> > + */
> > +
> > +#ifndef _SC_IRQ_RPC_H
> > +#define _SC_IRQ_RPC_H
> > +
> > +/* Types */
> > +
> > +/*!
> > + * This type is used to indicate RPC IRQ function calls.
> > + */
> > +typedef enum irq_func_e {
> > + IRQ_FUNC_UNKNOWN = 0, /* Unknown function */
> > + IRQ_FUNC_ENABLE = 1, /* Index for irq_enable() RPC call */
> > + IRQ_FUNC_STATUS = 2, /* Index for irq_status() RPC call */
> > +} irq_func_t;
> > +
> > +/* Functions */
> > +
> > +/*!
> > + * This function dispatches an incoming IRQ RPC request.
> > + *
> > + * @param[in] caller_pt caller partition
> > + * @param[in] msg pointer to RPC message
> > + */
> > +void irq_dispatch(sc_rm_pt_t caller_pt, sc_rpc_msg_t *msg);
>
> ditto.
>
> > +
> > +/*!
> > + * This function translates and dispatches an IRQ RPC request.
> > + *
> > + * @param[in] ipc IPC handle
> > + * @param[in] msg pointer to RPC message
> > + */
> > +void irq_xlate(sc_ipc_t ipc, sc_rpc_msg_t *msg);
>
> ditto.
>
> > +++ b/include/soc/imx/sc/svc/timer/api.h
> > @@ -0,0 +1,265 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Copyright 2017~2018 NXP
> > + *
> > + * Header file containing the public API for the System Controller
> > +(SC)
> > + * Timer function.
> > + *
> > + * TIMER_SVC (SVC) Timer Service
> > + *
> > + * Module for the Timer service. This includes support for the
> > +watchdog, RTC,
> > + * and system counter. Note every resource partition has a watchdog
> > +it can
> > + * use.
> > + */
> > +
> > +#ifndef _SC_TIMER_API_H
> > +#define _SC_TIMER_API_H
> > +
> > +/* Includes */
> > +
> > +#include <soc/imx/sc/types.h>
> > +#include <soc/imx/sc/svc/rm/api.h>
> > +
> > +/* Defines */
> > +
> > +/*
> > + * @name Defines for type widths
> > + */
> > +#define SC_TIMER_ACTION_W 3 /* Width of sc_timer_wdog_action_t
> */
> > +
> > +/*
> > + * @name Defines for sc_timer_wdog_action_t */
> > +#define SC_TIMER_WDOG_ACTION_PARTITION 0 /* Reset
> partition */
> > +#define SC_TIMER_WDOG_ACTION_WARM 1 /* Warm reset
> system */
> > +#define SC_TIMER_WDOG_ACTION_COLD 2 /* Cold reset system
> */
> > +#define SC_TIMER_WDOG_ACTION_BOARD 3 /* Reset board */
> > +#define SC_TIMER_WDOG_ACTION_IRQ 4 /* Only generate
> IRQs */
> > +
> > +/* Types */
> > +
> > +/*
> > + * This type is used to configure the watchdog action.
> > + */
> > +typedef uint8_t sc_timer_wdog_action_t;
>
> Mixing an unnecessary typedef and defines doesn't look good. This should
> be
>
> typedef enum {
> SC_TIMER_WDOG_ACTION_PARTITION,
> } sc_timer_wdog_action_t;
>
> The same pattern is used elsewhere in this patch.
>
After checking with SCU firmware owner, we know that the SCU firmware actually
did that way before, but changed to mixed typedef and defines due to below reasons:
1) emum size is undefined. Usually is int. But wdog_action_t, others are similar,
is defined as u8 in SCU communication protocol which means we can't use it without
an explicitly casting.
2) Follow MISRA C requirement
For enum, Math is not allowed on them. Cannot iterate over them. Can't hardly use at
all without cast.
That's why we decided to eliminate some using of enum in SC firmware to pass the
MISRA C scan.
And for the RPC_X macros, I still did not remove them due to it's used in all C files
which is rather than a simple head file change.
I already sent out an updated version for review.
Please check it. If you still think it's quite necessary to change, please feel free to
let me know.
Regards
Dong Aisheng
> > +
> > +/*
> > + * This type is used to declare a watchdog time value in milliseconds.
> > + */
> > +typedef uint32_t sc_timer_wdog_time_t;
>
> Why an extra type for this?
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions |
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> w.pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7C2d0
> 5ba17b0d24957022a08d5b0140906%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C0%7C636608522458461041&sdata=WMYanmj1AZkESu0fbXrspidjPbVc
> t3sKQYNhGt5J9ME%3D&reserved=0 |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [Dev] [PATCH 0/5] RFC: Mezzanine handling for 96boards
From: Daniel Thompson @ 2018-06-19 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-1-linus.walleij@linaro.org>
On Mon, Jun 18, 2018 at 09:45:51AM +0200, Linus Walleij wrote:
> This is a proposal for how to handle the non-discoverable
> 96boards plug-in expansion boards called "mezzanines" in the
> Linux kernel. It is a working RFC series meant for discussion
> at the moment.
>
> The RFC was done on the brand new Ultra96 board from Xilinx
> with a Secure96 mezzanine expansion board. The main part
> is in patch 4, the rest is enabling and examples.
>
> The code can be obtained from here:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=ultra96
>
> You can for example probably augment the DTS file for any
> upstream-supported 96board and get the Secure96 going with
> it with minor efforts.
Like other commenters I'm rather like using C to solve this, and your
comments Big Upfront Design are good backup in term of convincing me.
> TODO:
>
> - Proper device tree bindings for the connector, for now
> look at the example.
>
> - Discuss whether to actually do this or just take it all and
> flush it down the drain because the community doesn't like
> it. I'm not one of those especially infatuated with my own code,
> I always stay by the old programming project management mantra
> to calculate to make one version and throw it away as stepping
> stone to a good final design.
>
> - Placement: putting this in drivers/bus is just an example.
> drivers/platform/96boards-mezzanines is fine too, maybe better?
>
> - I am especially curious about input from Andy and Mika from
> the Intel/ACPI camp on what they have seen for non-discoverable
> plug-in boards. Does this problem even exist in the Intel
> world, or not...
I'm also interested in the "what about ACPI" question?
Using C makes describing a board in ACPI fairly easy. AFAICT allocating
IDs to a board rather than its included components is fairly natural for
ACPI.
However I'm too ignorant to be able to figure out if the expansion
connector itself could/should be described in the tables (e.g. if
connector is a bus and the board is[1] a device, could the bus driver
be instantiated in a reasonable way).
Daniel.
[1] ... or becomes a device, based on feedback in this thread ;-)
^ permalink raw reply
* [PATCH] drm/bridge: tc358764: fix noderef.cocci warnings
From: kbuild test robot @ 2018-06-19 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529396370-18761-8-git-send-email-m.purski@samsung.com>
From: kbuild test robot <fengguang.wu@intel.com>
drivers/gpu/drm/bridge/tc358764.c:179:60-66: ERROR: application of sizeof to pointer
sizeof when applied to a pointer typed expression gives the size of
the pointer
Generated by: scripts/coccinelle/misc/noderef.cocci
Fixes: 147fe90c9d51 ("drm/bridge: tc358764: Add DSI to LVDS bridge driver")
CC: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
tc358764.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/bridge/tc358764.c
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -176,7 +176,8 @@ static int tc358764_read(struct tc358764
ssize_t ret;
cpu_to_le16s(&addr);
- ret = mipi_dsi_generic_read(dsi, &addr, sizeof(addr), val, sizeof(val));
+ ret = mipi_dsi_generic_read(dsi, &addr, sizeof(addr), val,
+ sizeof(*val));
if (ret >= 0)
le32_to_cpus(val);
^ permalink raw reply
* [PATCH v3 7/9] drm/bridge: tc358764: Add DSI to LVDS bridge driver
From: kbuild test robot @ 2018-06-19 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529396370-18761-8-git-send-email-m.purski@samsung.com>
Hi Andrzej,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v4.18-rc1]
[also build test WARNING on next-20180619]
[cannot apply to drm-exynos/exynos-drm/for-next robh/for-next drm/drm-next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Maciej-Purski/drm-exynos-rename-bridge_node-to-mic_bridge_node/20180619-175136
coccinelle warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/bridge/tc358764.c:179:60-66: ERROR: application of sizeof to pointer
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCHv3 02/19] arm64: move SCTLR_EL{1, 2} assertions to <asm/sysreg.h>
From: Catalin Marinas @ 2018-06-19 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-3-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:53PM +0100, Mark Rutland wrote:
> Currently we assert that the SCTLR_EL{1,2}_{SET,CLEAR} bits are
> self-consistent with an assertion in config_sctlr_el1(). This is a bit
> unusual, since config_sctlr_el1() doesn't make use of these definitions,
> and is far away from the definitions themselves.
>
> We can use the CPP #error directive to have equivalent assertions in
> <asm/sysreg.h>, next to the definitions of the set/clear bits, which is
> a bit clearer and simpler.
>
> At the same time, lets fill in the upper 32 bits for both registers in
> their repsective RES0 definitions. This could be a little nicer with
> GENMASK_ULL(63, 32), but this currently lives in <linux/bitops.h>, which
> cannot safely be included from assembly, as <asm/sysreg.h> can.
>
> Note the when the preprocessor evaluates an expression for an #if
> directive, all signed or unsigned values are treated as intmax_t or
> uintmax_t respectively. To avoid ambiguity, we define explicitly define
> the mask of all 64 bits.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dave Martin <dave.martin@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v2 5/5] ARM: tegra: Always boot CPU in ARM-mode
From: Dmitry Osipenko @ 2018-06-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619110027.16935-1-digetx@gmail.com>
CPU always jumps into the reset handler in ARM-mode from the Trusted
Foundations firmware, hence make CPU to always jump into kernel in
ARM-mode regardless of the firmware presence to support Thumb2 kernel + TF
case.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
arch/arm/mach-tegra/reset-handler.S | 1 +
arch/arm/mach-tegra/reset.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index e9f2a7775998..8eda5c786f50 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -113,6 +113,7 @@ ENTRY(__tegra_cpu_reset_handler_start)
* must be position-independent.
*/
+ .arm
.align L1_CACHE_SHIFT
ENTRY(__tegra_cpu_reset_handler)
diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index b02ae7699842..3f1ef4561298 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -97,7 +97,7 @@ void __init tegra_cpu_reset_handler_init(void)
__tegra_cpu_reset_handler_data[TEGRA_RESET_MASK_PRESENT] =
*((u32 *)cpu_possible_mask);
__tegra_cpu_reset_handler_data[TEGRA_RESET_STARTUP_SECONDARY] =
- __pa_symbol((void *)secondary_startup);
+ __pa_symbol((void *)secondary_startup_arm);
#endif
#ifdef CONFIG_PM_SLEEP
--
2.17.1
^ permalink raw reply related
* [PATCH v2 4/5] ARM: tegra: Don't apply CPU erratas in insecure mode
From: Dmitry Osipenko @ 2018-06-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619110027.16935-1-digetx@gmail.com>
CPU isn't allowed to touch secure registers while running under secure
monitor. Hence skip applying CPU erratas in the reset handler if Trusted
Foundations firmware presents.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
arch/arm/mach-tegra/reset-handler.S | 24 ++++++++++++------------
arch/arm/mach-tegra/reset.c | 3 +++
arch/arm/mach-tegra/reset.h | 9 +++++++--
arch/arm/mach-tegra/sleep-tegra20.S | 4 ++++
4 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-tegra/reset-handler.S b/arch/arm/mach-tegra/reset-handler.S
index 805f306fa6f7..e9f2a7775998 100644
--- a/arch/arm/mach-tegra/reset-handler.S
+++ b/arch/arm/mach-tegra/reset-handler.S
@@ -29,8 +29,6 @@
#define PMC_SCRATCH41 0x140
-#define RESET_DATA(x) ((TEGRA_RESET_##x)*4)
-
#ifdef CONFIG_PM_SLEEP
/*
* tegra_resume
@@ -121,6 +119,12 @@ ENTRY(__tegra_cpu_reset_handler)
cpsid aif, 0x13 @ SVC mode, interrupts disabled
tegra_get_soc_id TEGRA_APB_MISC_BASE, r6
+
+ adr r12, __tegra_cpu_reset_handler_data
+ ldr r0, [r12, #RESET_DATA(TF_PRESENT)]
+ cmp r0, #0
+ bne after_errata
+
#ifdef CONFIG_ARCH_TEGRA_2x_SOC
t20_check:
cmp r6, #TEGRA20
@@ -155,7 +159,6 @@ after_errata:
and r10, r10, #0x3 @ R10 = CPU number
mov r11, #1
mov r11, r11, lsl r10 @ R11 = CPU mask
- adr r12, __tegra_cpu_reset_handler_data
#ifdef CONFIG_SMP
/* Does the OS know about this CPU? */
@@ -169,10 +172,9 @@ after_errata:
cmp r6, #TEGRA20
bne 1f
/* If not CPU0, don't let CPU0 reset CPU1 now that CPU1 is coming up. */
- mov32 r5, TEGRA_IRAM_BASE + TEGRA_IRAM_RESET_HANDLER_OFFSET
mov r0, #CPU_NOT_RESETTABLE
cmp r10, #0
- strneb r0, [r5, #__tegra20_cpu1_resettable_status_offset]
+ strneb r0, [r12, #RESET_DATA(RESETTABLE_STATUS)]
1:
#endif
@@ -277,14 +279,12 @@ ENDPROC(__tegra_cpu_reset_handler)
.align L1_CACHE_SHIFT
.type __tegra_cpu_reset_handler_data, %object
.globl __tegra_cpu_reset_handler_data
+ .globl __tegra_cpu_reset_handler_data_offset
+ .equ __tegra_cpu_reset_handler_data_offset, \
+ . - __tegra_cpu_reset_handler_start
__tegra_cpu_reset_handler_data:
- .rept TEGRA_RESET_DATA_SIZE
- .long 0
+ .rept TEGRA_RESET_DATA_SIZE
+ .long 0
.endr
- .globl __tegra20_cpu1_resettable_status_offset
- .equ __tegra20_cpu1_resettable_status_offset, \
- . - __tegra_cpu_reset_handler_start
- .byte 0
.align L1_CACHE_SHIFT
-
ENTRY(__tegra_cpu_reset_handler_end)
diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index dc558892753c..b02ae7699842 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -24,6 +24,7 @@
#include <asm/cacheflush.h>
#include <asm/firmware.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/trusted_foundations.h>
#include "iomap.h"
#include "irammap.h"
@@ -89,6 +90,8 @@ static void __init tegra_cpu_reset_handler_enable(void)
void __init tegra_cpu_reset_handler_init(void)
{
+ __tegra_cpu_reset_handler_data[TEGRA_RESET_TF_PRESENT] =
+ trusted_foundations_registered();
#ifdef CONFIG_SMP
__tegra_cpu_reset_handler_data[TEGRA_RESET_MASK_PRESENT] =
diff --git a/arch/arm/mach-tegra/reset.h b/arch/arm/mach-tegra/reset.h
index 9c479c7925b8..db0e6b3097ab 100644
--- a/arch/arm/mach-tegra/reset.h
+++ b/arch/arm/mach-tegra/reset.h
@@ -25,7 +25,11 @@
#define TEGRA_RESET_STARTUP_SECONDARY 3
#define TEGRA_RESET_STARTUP_LP2 4
#define TEGRA_RESET_STARTUP_LP1 5
-#define TEGRA_RESET_DATA_SIZE 6
+#define TEGRA_RESET_RESETTABLE_STATUS 6
+#define TEGRA_RESET_TF_PRESENT 7
+#define TEGRA_RESET_DATA_SIZE 8
+
+#define RESET_DATA(x) ((TEGRA_RESET_##x)*4)
#ifndef __ASSEMBLY__
@@ -49,7 +53,8 @@ void __tegra_cpu_reset_handler_end(void);
(u32)__tegra_cpu_reset_handler_start)))
#define tegra20_cpu1_resettable_status \
(IO_ADDRESS(TEGRA_IRAM_BASE + TEGRA_IRAM_RESET_HANDLER_OFFSET + \
- (u32)__tegra20_cpu1_resettable_status_offset))
+ ((u32)&__tegra_cpu_reset_handler_data[TEGRA_RESET_RESETTABLE_STATUS] - \
+ (u32)__tegra_cpu_reset_handler_start)))
#endif
#define tegra_cpu_reset_handler_offset \
diff --git a/arch/arm/mach-tegra/sleep-tegra20.S b/arch/arm/mach-tegra/sleep-tegra20.S
index 5c8e638ee51a..11f423e4a263 100644
--- a/arch/arm/mach-tegra/sleep-tegra20.S
+++ b/arch/arm/mach-tegra/sleep-tegra20.S
@@ -28,6 +28,7 @@
#include <asm/cache.h>
#include "irammap.h"
+#include "reset.h"
#include "sleep.h"
#define EMC_CFG 0xc
@@ -54,6 +55,9 @@
#define APB_MISC_XM2CFGCPADCTRL2 0x8e4
#define APB_MISC_XM2CFGDPADCTRL2 0x8e8
+#define __tegra20_cpu1_resettable_status_offset \
+ (__tegra_cpu_reset_handler_data_offset + RESET_DATA(RESETTABLE_STATUS))
+
.macro pll_enable, rd, r_car_base, pll_base
ldr \rd, [\r_car_base, #\pll_base]
tst \rd, #(1 << 30)
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/5] ARM: tegra: Setup L2 cache using Trusted Foundations firmware
From: Dmitry Osipenko @ 2018-06-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619110027.16935-1-digetx@gmail.com>
On Tegra20/30 L2 cache must be initialized using firmware call if CPU
is running in insecure mode. Initialize L2 cache and setup the outer-cache
callbacks in early boot using the firmware API.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
arch/arm/mach-tegra/tegra.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index f9587be48235..590b1cf1a8c4 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -38,6 +38,7 @@
#include <soc/tegra/fuse.h>
#include <soc/tegra/pmc.h>
+#include <asm/firmware.h>
#include <asm/hardware/cache-l2x0.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
@@ -70,9 +71,23 @@ u32 tegra_uart_config[3] = {
0,
};
+static void __init tegra_trusted_foundations_l2x0_cache_init(void)
+{
+ if (IS_ENABLED(CONFIG_CACHE_L2X0) &&
+ IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) &&
+ of_machine_is_compatible("nvidia,tegra20"))
+ call_firmware_op(l2x0_init);
+
+ if (IS_ENABLED(CONFIG_CACHE_L2X0) &&
+ IS_ENABLED(CONFIG_ARCH_TEGRA_3x_SOC) &&
+ of_machine_is_compatible("nvidia,tegra30"))
+ call_firmware_op(l2x0_init);
+}
+
static void __init tegra_init_early(void)
{
of_register_trusted_foundations();
+ tegra_trusted_foundations_l2x0_cache_init();
tegra_cpu_reset_handler_init();
}
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/5] ARM: trusted_foundations: Provide information about whether firmware is registered
From: Dmitry Osipenko @ 2018-06-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619110027.16935-1-digetx@gmail.com>
Add a helper that provides information about whether Trusted Foundations
firmware operations have been registered.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
arch/arm/firmware/trusted_foundations.c | 5 +++++
arch/arm/include/asm/trusted_foundations.h | 7 +++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/firmware/trusted_foundations.c b/arch/arm/firmware/trusted_foundations.c
index 30df6547020f..f6eeb67de217 100644
--- a/arch/arm/firmware/trusted_foundations.c
+++ b/arch/arm/firmware/trusted_foundations.c
@@ -124,3 +124,8 @@ void of_register_trusted_foundations(void)
panic("Trusted Foundation: missing version-minor property\n");
register_trusted_foundations(&pdata);
}
+
+bool trusted_foundations_registered(void)
+{
+ return firmware_ops == &trusted_foundations_ops;
+}
diff --git a/arch/arm/include/asm/trusted_foundations.h b/arch/arm/include/asm/trusted_foundations.h
index 00748350cf72..bfd0d780824b 100644
--- a/arch/arm/include/asm/trusted_foundations.h
+++ b/arch/arm/include/asm/trusted_foundations.h
@@ -31,6 +31,7 @@
#include <linux/of.h>
#include <linux/cpu.h>
#include <linux/smp.h>
+#include <linux/types.h>
struct trusted_foundations_platform_data {
unsigned int version_major;
@@ -41,6 +42,7 @@ struct trusted_foundations_platform_data {
void register_trusted_foundations(struct trusted_foundations_platform_data *pd);
void of_register_trusted_foundations(void);
+bool trusted_foundations_registered(void);
#else /* CONFIG_TRUSTED_FOUNDATIONS */
@@ -68,6 +70,11 @@ static inline void of_register_trusted_foundations(void)
if (of_find_compatible_node(NULL, NULL, "tlm,trusted-foundations"))
register_trusted_foundations(NULL);
}
+
+static inline bool trusted_foundations_registered(void)
+{
+ return false;
+}
#endif /* CONFIG_TRUSTED_FOUNDATIONS */
#endif
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/5] ARM: trusted_foundations: Implement L2 cache initialization callback
From: Dmitry Osipenko @ 2018-06-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619110027.16935-1-digetx@gmail.com>
Implement L2 cache initialization firmware callback that should be invoked
early in boot to enable cache HW.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
arch/arm/firmware/trusted_foundations.c | 27 +++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/firmware/trusted_foundations.c b/arch/arm/firmware/trusted_foundations.c
index 3fb1b5a1dce9..30df6547020f 100644
--- a/arch/arm/firmware/trusted_foundations.c
+++ b/arch/arm/firmware/trusted_foundations.c
@@ -18,8 +18,13 @@
#include <linux/init.h>
#include <linux/of.h>
#include <asm/firmware.h>
+#include <asm/outercache.h>
#include <asm/trusted_foundations.h>
+#define TF_CACHE_MAINT 0xfffff100
+
+#define TF_CACHE_INIT 1
+
#define TF_SET_CPU_BOOT_ADDR_SMC 0xfffff200
#define TF_CPU_PM 0xfffffffc
@@ -63,9 +68,31 @@ static int tf_prepare_idle(void)
return 0;
}
+#ifdef CONFIG_CACHE_L2X0
+static void tf_cache_write_sec(unsigned long val, unsigned int reg)
+{
+ /*
+ * The L2X0 cache driver shouldn't invoke a write to a secure registers,
+ * though it's better to reinsure by printing a warning message.
+ */
+ pr_warn("%s: Ignoring write [0x%x]: 0x%08lx\n", __func__, reg, val);
+}
+
+static int tf_init_cache(void)
+{
+ outer_cache.write_sec = tf_cache_write_sec;
+ tf_generic_smc(TF_CACHE_MAINT, TF_CACHE_INIT, 0);
+
+ return 0;
+}
+#endif /* CONFIG_CACHE_L2X0 */
+
static const struct firmware_ops trusted_foundations_ops = {
.set_cpu_boot_addr = tf_set_cpu_boot_addr,
.prepare_idle = tf_prepare_idle,
+#ifdef CONFIG_CACHE_L2X0
+ .l2x0_init = tf_init_cache,
+#endif
};
void register_trusted_foundations(struct trusted_foundations_platform_data *pd)
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/5] Initial support of Trusted Foundations on Tegra30
From: Dmitry Osipenko @ 2018-06-19 11:00 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This series of patches brings initial support of Trusted Foundations to
Tegra30, that is to the consumer-grade Tegra30 devices which do not allow
to easily replace the proprietary bootloader. Support is initial because
this series implements only a proper CPU boot-up (main + secondary cores)
and a basic L2 cache maintenance that is done using the TF firmware.
Suspend-resume support is missing yet as I couldn't get it to work
(CPU hangs on resume from suspend after awhile and seems that is related
to inappropriately done cache maintenance during of suspend-resume using
the firmware), it is work-in-progress for now.
This patchset is partially based on the work done by Micha? Miros?aw [0].
[0] https://www.spinics.net/lists/linux-tegra/msg30368.html
Changelog:
v2:
- The "Don't apply CPU erratas in insecure mode" patch got some
cleanup, in particular resolved the messiness in
__tegra_cpu_reset_handler_data.
- Added a comment to tf_cache_write_sec(), justifying the warning
message.
Dmitry Osipenko (5):
ARM: trusted_foundations: Implement L2 cache initialization callback
ARM: trusted_foundations: Provide information about whether firmware
is registered
ARM: tegra: Setup L2 cache using Trusted Foundations firmware
ARM: tegra: Don't apply CPU erratas in insecure mode
ARM: tegra: Always boot CPU in ARM-mode
arch/arm/firmware/trusted_foundations.c | 32 ++++++++++++++++++++++
arch/arm/include/asm/trusted_foundations.h | 7 +++++
arch/arm/mach-tegra/reset-handler.S | 25 +++++++++--------
arch/arm/mach-tegra/reset.c | 5 +++-
arch/arm/mach-tegra/reset.h | 9 ++++--
arch/arm/mach-tegra/sleep-tegra20.S | 4 +++
arch/arm/mach-tegra/tegra.c | 15 ++++++++++
7 files changed, 82 insertions(+), 15 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH v3 3/7] arm_pmu: Add support for 64bit event counters
From: Mark Rutland @ 2018-06-19 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529403342-17899-4-git-send-email-suzuki.poulose@arm.com>
On Tue, Jun 19, 2018 at 11:15:38AM +0100, Suzuki K Poulose wrote:
> Each PMU has a set of 32bit event counters. But in some
> special cases, the events could be counted using counters
> which are effectively 64bit wide.
>
> e.g, Arm V8 PMUv3 has a 64 bit cycle counter which can count
> only the CPU cycles. Also, the PMU can chain the event counters
> to effectively count as a 64bit counter.
>
> Add support for tracking the events that uses 64bit counters.
> This only affects the periods set for each counter in the core
> driver.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> Changes since v2:
> - None
> ---
> drivers/perf/arm_pmu.c | 15 +++++++++------
> include/linux/perf/arm_pmu.h | 6 ++++++
> 2 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 6ddc00d..e3766a8 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -28,9 +28,11 @@
> static DEFINE_PER_CPU(struct arm_pmu *, cpu_armpmu);
> static DEFINE_PER_CPU(int, cpu_irq);
>
> -static inline u64 arm_pmu_max_period(void)
> +static inline u64 arm_pmu_event_max_period(struct perf_event *event)
> {
> - return (1ULL << 32) - 1;
> + return (event->hw.flags & ARMPMU_EVT_64BIT) ?
> + GENMASK_ULL(63, 0) :
> + GENMASK_ULL(31, 0);
Please make this:
if (event->hw.flags & ARMPMU_EVT_64BIT)
return GENMASK_ULL(63, 0);
else
return GENMASK_ULL(31, 0);
... which I think is more legible than a ternary spread across multiple
lines.
The rest looks fine, so with that:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> }
>
> static int
> @@ -122,7 +124,7 @@ int armpmu_event_set_period(struct perf_event *event)
> u64 max_period;
> int ret = 0;
>
> - max_period = arm_pmu_max_period();
> + max_period = arm_pmu_event_max_period(event);
> if (unlikely(left <= -period)) {
> left = period;
> local64_set(&hwc->period_left, left);
> @@ -148,7 +150,7 @@ int armpmu_event_set_period(struct perf_event *event)
>
> local64_set(&hwc->prev_count, (u64)-left);
>
> - armpmu->write_counter(event, (u64)(-left) & 0xffffffff);
> + armpmu->write_counter(event, (u64)(-left) & max_period);
>
> perf_event_update_userpage(event);
>
> @@ -160,7 +162,7 @@ u64 armpmu_event_update(struct perf_event *event)
> struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> struct hw_perf_event *hwc = &event->hw;
> u64 delta, prev_raw_count, new_raw_count;
> - u64 max_period = arm_pmu_max_period();
> + u64 max_period = arm_pmu_event_max_period(event);
>
> again:
> prev_raw_count = local64_read(&hwc->prev_count);
> @@ -368,6 +370,7 @@ __hw_perf_event_init(struct perf_event *event)
> struct hw_perf_event *hwc = &event->hw;
> int mapping;
>
> + hwc->flags = 0;
> mapping = armpmu->map_event(event);
>
> if (mapping < 0) {
> @@ -410,7 +413,7 @@ __hw_perf_event_init(struct perf_event *event)
> * is far less likely to overtake the previous one unless
> * you have some serious IRQ latency issues.
> */
> - hwc->sample_period = arm_pmu_max_period() >> 1;
> + hwc->sample_period = arm_pmu_event_max_period(event) >> 1;
> hwc->last_period = hwc->sample_period;
> local64_set(&hwc->period_left, hwc->sample_period);
> }
> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> index f7126a2..10f92e1 100644
> --- a/include/linux/perf/arm_pmu.h
> +++ b/include/linux/perf/arm_pmu.h
> @@ -25,6 +25,12 @@
> */
> #define ARMPMU_MAX_HWEVENTS 32
>
> +/*
> + * ARM PMU hw_event flags
> + */
> +/* Event uses a 64bit counter */
> +#define ARMPMU_EVT_64BIT 1
> +
> #define HW_OP_UNSUPPORTED 0xFFFF
> #define C(_x) PERF_COUNT_HW_CACHE_##_x
> #define CACHE_OP_UNSUPPORTED 0xFFFF
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] ARM: dts: imx53-qsb: Let the codec control MCLK pinctrl
From: Fabio Estevam @ 2018-06-19 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619011645.GU16091@dragon>
Hi Shawn,
On Mon, Jun 18, 2018 at 10:16 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> Are you saying that pins in hog group hasn't been set up yet when codec
> driver probes?
After further investigation I found the root cause as to why
pinctrl_hog pins were failling and sent a fix for it:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=fixes&id=bc3322bc166a2905bc91f774d7b22773dc7c063a
We can drop this dts patch.
Moving from hog to codec group is still a good idea though. I can
respin this patch later, but it will be a cleanup, not a bug fix.
Thanks
^ permalink raw reply
* [PATCH v3 2/7] arm_pmu: Change API to support 64bit counter values
From: Mark Rutland @ 2018-06-19 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529403342-17899-3-git-send-email-suzuki.poulose@arm.com>
On Tue, Jun 19, 2018 at 11:15:37AM +0100, Suzuki K Poulose wrote:
> Convert the {read/write}_counter APIs to handle 64bit values
> to enable supporting chained event counters.
It might be worth a note that the underlying helpers will still only
write 32-bit values, and we'll only pass those 32-bit values, so this
shouldn't cause any functional change.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> - No changes since v2
> ---
> arch/arm/kernel/perf_event_v6.c | 4 ++--
> arch/arm/kernel/perf_event_v7.c | 4 ++--
> arch/arm/kernel/perf_event_xscale.c | 8 ++++----
> arch/arm64/kernel/perf_event.c | 9 ++++-----
> include/linux/perf/arm_pmu.h | 4 ++--
> 5 files changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
> index f64a6bf..0729f98 100644
> --- a/arch/arm/kernel/perf_event_v6.c
> +++ b/arch/arm/kernel/perf_event_v6.c
> @@ -233,7 +233,7 @@ armv6_pmcr_counter_has_overflowed(unsigned long pmcr,
> return ret;
> }
>
> -static inline u32 armv6pmu_read_counter(struct perf_event *event)
> +static inline u64 armv6pmu_read_counter(struct perf_event *event)
> {
> struct hw_perf_event *hwc = &event->hw;
> int counter = hwc->idx;
> @@ -251,7 +251,7 @@ static inline u32 armv6pmu_read_counter(struct perf_event *event)
> return value;
> }
>
> -static inline void armv6pmu_write_counter(struct perf_event *event, u32 value)
> +static inline void armv6pmu_write_counter(struct perf_event *event, u64 value)
> {
> struct hw_perf_event *hwc = &event->hw;
> int counter = hwc->idx;
> diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
> index ecca4cd..fd7ce01 100644
> --- a/arch/arm/kernel/perf_event_v7.c
> +++ b/arch/arm/kernel/perf_event_v7.c
> @@ -743,7 +743,7 @@ static inline void armv7_pmnc_select_counter(int idx)
> isb();
> }
>
> -static inline u32 armv7pmu_read_counter(struct perf_event *event)
> +static inline u64 armv7pmu_read_counter(struct perf_event *event)
> {
> struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> struct hw_perf_event *hwc = &event->hw;
> @@ -763,7 +763,7 @@ static inline u32 armv7pmu_read_counter(struct perf_event *event)
> return value;
> }
>
> -static inline void armv7pmu_write_counter(struct perf_event *event, u32 value)
> +static inline void armv7pmu_write_counter(struct perf_event *event, u64 value)
> {
> struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> struct hw_perf_event *hwc = &event->hw;
> diff --git a/arch/arm/kernel/perf_event_xscale.c b/arch/arm/kernel/perf_event_xscale.c
> index c4f0294..942230f 100644
> --- a/arch/arm/kernel/perf_event_xscale.c
> +++ b/arch/arm/kernel/perf_event_xscale.c
> @@ -316,7 +316,7 @@ static void xscale1pmu_stop(struct arm_pmu *cpu_pmu)
> raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> }
>
> -static inline u32 xscale1pmu_read_counter(struct perf_event *event)
> +static inline u64 xscale1pmu_read_counter(struct perf_event *event)
> {
> struct hw_perf_event *hwc = &event->hw;
> int counter = hwc->idx;
> @@ -337,7 +337,7 @@ static inline u32 xscale1pmu_read_counter(struct perf_event *event)
> return val;
> }
>
> -static inline void xscale1pmu_write_counter(struct perf_event *event, u32 val)
> +static inline void xscale1pmu_write_counter(struct perf_event *event, u64 val)
> {
> struct hw_perf_event *hwc = &event->hw;
> int counter = hwc->idx;
> @@ -678,7 +678,7 @@ static void xscale2pmu_stop(struct arm_pmu *cpu_pmu)
> raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> }
>
> -static inline u32 xscale2pmu_read_counter(struct perf_event *event)
> +static inline u64 xscale2pmu_read_counter(struct perf_event *event)
> {
> struct hw_perf_event *hwc = &event->hw;
> int counter = hwc->idx;
> @@ -705,7 +705,7 @@ static inline u32 xscale2pmu_read_counter(struct perf_event *event)
> return val;
> }
>
> -static inline void xscale2pmu_write_counter(struct perf_event *event, u32 val)
> +static inline void xscale2pmu_write_counter(struct perf_event *event, u64 val)
> {
> struct hw_perf_event *hwc = &event->hw;
> int counter = hwc->idx;
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 678ecff..66a2ffd 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -512,7 +512,7 @@ static inline int armv8pmu_select_counter(int idx)
> return idx;
> }
>
> -static inline u32 armv8pmu_read_counter(struct perf_event *event)
> +static inline u64 armv8pmu_read_counter(struct perf_event *event)
> {
> struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> struct hw_perf_event *hwc = &event->hw;
> @@ -530,7 +530,7 @@ static inline u32 armv8pmu_read_counter(struct perf_event *event)
> return value;
> }
>
> -static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
> +static inline void armv8pmu_write_counter(struct perf_event *event, u64 value)
> {
> struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> struct hw_perf_event *hwc = &event->hw;
> @@ -545,9 +545,8 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
> * count using the lower 32bits and we want an interrupt when
> * it overflows.
> */
> - u64 value64 = 0xffffffff00000000ULL | value;
> -
> - write_sysreg(value64, pmccntr_el0);
> + value |= 0xffffffff00000000ULL;
> + write_sysreg(value, pmccntr_el0);
> } else if (armv8pmu_select_counter(idx) == idx)
> write_sysreg(value, pmxevcntr_el0);
> }
> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> index 12c30a2..f7126a2 100644
> --- a/include/linux/perf/arm_pmu.h
> +++ b/include/linux/perf/arm_pmu.h
> @@ -87,8 +87,8 @@ struct arm_pmu {
> struct perf_event *event);
> int (*set_event_filter)(struct hw_perf_event *evt,
> struct perf_event_attr *attr);
> - u32 (*read_counter)(struct perf_event *event);
> - void (*write_counter)(struct perf_event *event, u32 val);
> + u64 (*read_counter)(struct perf_event *event);
> + void (*write_counter)(struct perf_event *event, u64 val);
> void (*start)(struct arm_pmu *);
> void (*stop)(struct arm_pmu *);
> void (*reset)(void *);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCHv3 01/19] arm64: consistently use unsigned long for thread flags
From: Catalin Marinas @ 2018-06-19 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618120310.39527-2-mark.rutland@arm.com>
On Mon, Jun 18, 2018 at 01:02:52PM +0100, Mark Rutland wrote:
> In do_notify_resume, we manipulate thread_flags as a 32-bit unsigned
> int, whereas thread_info::flags is a 64-bit unsigned long, and elsewhere
> (e.g. in the entry assembly) we manipulate the flags as a 64-bit
> quantity.
>
> For consistency, and to avoid problems if we end up with more than 32
> flags, let's make do_notify_resume take the flags as a 64-bit unsigned
> long.
When we get to more than 32 flags, you may want to modify the _TIF_*
definitions as well to (UL(1) << TIF_*). In the meantime:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v3 1/7] arm_pmu: Clean up maximum period handling
From: Mark Rutland @ 2018-06-19 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529403342-17899-2-git-send-email-suzuki.poulose@arm.com>
On Tue, Jun 19, 2018 at 11:15:36AM +0100, Suzuki K Poulose wrote:
> Each PMU defines their max_period of the counter as the maximum
> value that can be counted. Since all the PMU backends support
> 32bit counters by default, let us remove the redundant field.
>
> No functional changes.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> No changes since v2
> ---
> arch/arm/kernel/perf_event_v6.c | 2 --
> arch/arm/kernel/perf_event_v7.c | 1 -
> arch/arm/kernel/perf_event_xscale.c | 2 --
> arch/arm64/kernel/perf_event.c | 1 -
> drivers/perf/arm_pmu.c | 16 ++++++++++++----
> include/linux/perf/arm_pmu.h | 1 -
> 6 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
> index be42c4f..f64a6bf 100644
> --- a/arch/arm/kernel/perf_event_v6.c
> +++ b/arch/arm/kernel/perf_event_v6.c
> @@ -495,7 +495,6 @@ static void armv6pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->stop = armv6pmu_stop;
> cpu_pmu->map_event = armv6_map_event;
> cpu_pmu->num_events = 3;
> - cpu_pmu->max_period = (1LLU << 32) - 1;
> }
>
> static int armv6_1136_pmu_init(struct arm_pmu *cpu_pmu)
> @@ -546,7 +545,6 @@ static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->stop = armv6pmu_stop;
> cpu_pmu->map_event = armv6mpcore_map_event;
> cpu_pmu->num_events = 3;
> - cpu_pmu->max_period = (1LLU << 32) - 1;
>
> return 0;
> }
> diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
> index 57f01e0..ecca4cd 100644
> --- a/arch/arm/kernel/perf_event_v7.c
> +++ b/arch/arm/kernel/perf_event_v7.c
> @@ -1170,7 +1170,6 @@ static void armv7pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->start = armv7pmu_start;
> cpu_pmu->stop = armv7pmu_stop;
> cpu_pmu->reset = armv7pmu_reset;
> - cpu_pmu->max_period = (1LLU << 32) - 1;
> };
>
> static void armv7_read_num_pmnc_events(void *info)
> diff --git a/arch/arm/kernel/perf_event_xscale.c b/arch/arm/kernel/perf_event_xscale.c
> index 88d1a76..c4f0294 100644
> --- a/arch/arm/kernel/perf_event_xscale.c
> +++ b/arch/arm/kernel/perf_event_xscale.c
> @@ -374,7 +374,6 @@ static int xscale1pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->stop = xscale1pmu_stop;
> cpu_pmu->map_event = xscale_map_event;
> cpu_pmu->num_events = 3;
> - cpu_pmu->max_period = (1LLU << 32) - 1;
>
> return 0;
> }
> @@ -743,7 +742,6 @@ static int xscale2pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->stop = xscale2pmu_stop;
> cpu_pmu->map_event = xscale_map_event;
> cpu_pmu->num_events = 5;
> - cpu_pmu->max_period = (1LLU << 32) - 1;
>
> return 0;
> }
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 33147aa..678ecff 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -960,7 +960,6 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->start = armv8pmu_start,
> cpu_pmu->stop = armv8pmu_stop,
> cpu_pmu->reset = armv8pmu_reset,
> - cpu_pmu->max_period = (1LLU << 32) - 1,
> cpu_pmu->set_event_filter = armv8pmu_set_event_filter;
>
> return 0;
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index a6347d4..6ddc00d 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -28,6 +28,11 @@
> static DEFINE_PER_CPU(struct arm_pmu *, cpu_armpmu);
> static DEFINE_PER_CPU(int, cpu_irq);
>
> +static inline u64 arm_pmu_max_period(void)
> +{
> + return (1ULL << 32) - 1;
> +}
> +
> static int
> armpmu_map_cache_event(const unsigned (*cache_map)
> [PERF_COUNT_HW_CACHE_MAX]
> @@ -114,8 +119,10 @@ int armpmu_event_set_period(struct perf_event *event)
> struct hw_perf_event *hwc = &event->hw;
> s64 left = local64_read(&hwc->period_left);
> s64 period = hwc->sample_period;
> + u64 max_period;
> int ret = 0;
>
> + max_period = arm_pmu_max_period();
> if (unlikely(left <= -period)) {
> left = period;
> local64_set(&hwc->period_left, left);
> @@ -136,8 +143,8 @@ int armpmu_event_set_period(struct perf_event *event)
> * effect we are reducing max_period to account for
> * interrupt latency (and we are being very conservative).
> */
> - if (left > (armpmu->max_period >> 1))
> - left = armpmu->max_period >> 1;
> + if (left > (max_period >> 1))
> + left = (max_period >> 1);
>
> local64_set(&hwc->prev_count, (u64)-left);
>
> @@ -153,6 +160,7 @@ u64 armpmu_event_update(struct perf_event *event)
> struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> struct hw_perf_event *hwc = &event->hw;
> u64 delta, prev_raw_count, new_raw_count;
> + u64 max_period = arm_pmu_max_period();
>
> again:
> prev_raw_count = local64_read(&hwc->prev_count);
> @@ -162,7 +170,7 @@ u64 armpmu_event_update(struct perf_event *event)
> new_raw_count) != prev_raw_count)
> goto again;
>
> - delta = (new_raw_count - prev_raw_count) & armpmu->max_period;
> + delta = (new_raw_count - prev_raw_count) & max_period;
>
> local64_add(delta, &event->count);
> local64_sub(delta, &hwc->period_left);
> @@ -402,7 +410,7 @@ __hw_perf_event_init(struct perf_event *event)
> * is far less likely to overtake the previous one unless
> * you have some serious IRQ latency issues.
> */
> - hwc->sample_period = armpmu->max_period >> 1;
> + hwc->sample_period = arm_pmu_max_period() >> 1;
> hwc->last_period = hwc->sample_period;
> local64_set(&hwc->period_left, hwc->sample_period);
> }
> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> index ad54444..12c30a2 100644
> --- a/include/linux/perf/arm_pmu.h
> +++ b/include/linux/perf/arm_pmu.h
> @@ -94,7 +94,6 @@ struct arm_pmu {
> void (*reset)(void *);
> int (*map_event)(struct perf_event *event);
> int num_events;
> - u64 max_period;
> bool secure_access; /* 32-bit ARM only */
> #define ARMV8_PMUV3_MAX_COMMON_EVENTS 0x40
> DECLARE_BITMAP(pmceid_bitmap, ARMV8_PMUV3_MAX_COMMON_EVENTS);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v3 6/7] arm64: perf: Disable PMU while processing counter overflows
From: Mark Rutland @ 2018-06-19 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529403342-17899-7-git-send-email-suzuki.poulose@arm.com>
On Tue, Jun 19, 2018 at 11:15:41AM +0100, Suzuki K Poulose wrote:
> The arm64 PMU updates the event counters and reprograms the
> counters in the overflow IRQ handler without disabling the
> PMU. This could potentially cause skews in for group counters,
> where the overflowed counters may potentially loose some event
> counts, while they are reprogrammed. To prevent this, disable
> the PMU while we process the counter overflows and enable it
> right back when we are done.
>
> This patch also moves the PMU stop/start routines to avoid a
> forward declaration.
>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
This makes me realise that we could remove the pmu_lock, but that's not
a new problem, and we can address that separately.
Thanks,
Mark.
> ---
> arch/arm64/kernel/perf_event.c | 50 +++++++++++++++++++++++-------------------
> 1 file changed, 28 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 9ce3729..eebc635 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -678,6 +678,28 @@ static void armv8pmu_disable_event(struct perf_event *event)
> raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> }
>
> +static void armv8pmu_start(struct arm_pmu *cpu_pmu)
> +{
> + unsigned long flags;
> + struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> +
> + raw_spin_lock_irqsave(&events->pmu_lock, flags);
> + /* Enable all counters */
> + armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_E);
> + raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> +}
> +
> +static void armv8pmu_stop(struct arm_pmu *cpu_pmu)
> +{
> + unsigned long flags;
> + struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> +
> + raw_spin_lock_irqsave(&events->pmu_lock, flags);
> + /* Disable all counters */
> + armv8pmu_pmcr_write(armv8pmu_pmcr_read() & ~ARMV8_PMU_PMCR_E);
> + raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> +}
> +
> static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
> {
> u32 pmovsr;
> @@ -702,6 +724,11 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
> */
> regs = get_irq_regs();
>
> + /*
> + * Stop the PMU while processing the counter overflows
> + * to prevent skews in group events.
> + */
> + armv8pmu_stop(cpu_pmu);
> for (idx = 0; idx < cpu_pmu->num_events; ++idx) {
> struct perf_event *event = cpuc->events[idx];
> struct hw_perf_event *hwc;
> @@ -726,6 +753,7 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
> if (perf_event_overflow(event, &data, regs))
> cpu_pmu->disable(event);
> }
> + armv8pmu_start(cpu_pmu);
>
> /*
> * Handle the pending perf events.
> @@ -739,28 +767,6 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
> return IRQ_HANDLED;
> }
>
> -static void armv8pmu_start(struct arm_pmu *cpu_pmu)
> -{
> - unsigned long flags;
> - struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> -
> - raw_spin_lock_irqsave(&events->pmu_lock, flags);
> - /* Enable all counters */
> - armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_E);
> - raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> -}
> -
> -static void armv8pmu_stop(struct arm_pmu *cpu_pmu)
> -{
> - unsigned long flags;
> - struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
> -
> - raw_spin_lock_irqsave(&events->pmu_lock, flags);
> - /* Disable all counters */
> - armv8pmu_pmcr_write(armv8pmu_pmcr_read() & ~ARMV8_PMU_PMCR_E);
> - raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> -}
> -
> static int armv8pmu_get_event_idx(struct pmu_hw_events *cpuc,
> struct perf_event *event)
> {
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-19 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <09260c7e-8b9d-bc3c-5bca-0fd75417f552@arm.com>
Hi James,
On Tue, Jun 19, 2018 at 3:46 PM, James Morse <james.morse@arm.com> wrote:
> Hi Yanjiang, Will,
>
> On 19/06/18 10:57, Jin, Yanjiang wrote:
>>> -----Original Message-----
>>> From: Will Deacon [mailto:will.deacon at arm.com]
>>> Sent: 2018?6?19? 17:41
>>> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
>>> Cc: James Morse <james.morse@arm.com>; Bhupesh Sharma
>>> <bhsharma@redhat.com>; Mark Rutland <mark.rutland@arm.com>; Ard
>>> Biesheuvel <ard.biesheuvel@linaro.org>; Catalin Marinas
>>> <catalin.marinas@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>;
>>> AKASHI Takahiro <takahiro.akashi@linaro.org>; Bhupesh SHARMA
>>> <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
>>> kernel at lists.infradead.org>
>>> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of
>>> linear region
>>>
>>> On Tue, Jun 19, 2018 at 09:34:56AM +0000, Jin, Yanjiang wrote:
>>>>> On Tue, Jun 19, 2018 at 03:02:15AM +0000, Jin, Yanjiang wrote:
>>>>>>> You seem to be using this for user-space phys_to_virt() based on
>>>>>>> values found in /proc/iomem. This should give you what you want,
>>>>>>> and isolate your user-space from the kernel's unexpected naming of
>>> variables.
>>>>>>
>>>>>> I don't know could I simplify this problem?
>>>>>> Let's ignore what memstart_addr represents here, we just want to
>>>>>> implement
>>>>>> phys_to_virt() in an userspace applications(kexec-tools or others).
>>>>>>
>>>>>> ARM64 Kernel has a below definition:
>>>>>>
>>>>>> #define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) |
>>>>> PAGE_OFFSET)
>>>>>>
>>>>>> So userspace app must know PHYS_OFFSET(equal to memstart_addr now).
>>>>>> Seems this is very simple, but memstart_addr has gone through
>>>>>> several operations in arm64_memblock_init() depends on different
>>>>>> Kernel configurations, so userspace app needs to know many
>>>>>> additional definitions as
>>>>> following:
>>>>>>
>>>>>> memblock_start_of_DRAM(), (ifdef CONFIG_SPARSEMEM_VMEMMAP),
>>>>>> ARM64_MEMSTART_SHIFT, SECTION_SIZE_BITS, PAGE_OFFSET,
>>>>>> memblock_end_of_DRAM(), IS_ENABLED(CONFIG_RANDOMIZE_BASE),
>>>>>> memstart_offset_seed.
>>>>>>
>>>>>> It is hard to know all above in kexec-tools now. Originally I
>>>>>> planned to read memstart_addr's value from "/dev/mem", but someone
>>>>>> thought not all Kernels enable "/dev/mem", we'd better find a more
>>>>>> generic approach. So we want to get some suggestions from ARM kernel
>>> community.
>>>>>> Can we export this variable in Kernel side through sysconf() or
>>>>>> other similar methods? Or someone can provide an effect way to get
>>>>>> memstart_addr's value?
>>>>>
>>>>> I thought the suggestion from James was to expose this via an ELF
>>>>> NOTE in kcore and vmcore (or in the header directly if that's possible, but I'm
>>> not sure about it)?
>>>>
>>>> Thanks for your reply firstly. But same as DEVMEM, kcore is not a
>>>> must-have, so we can't depend on it.
>>>
>>> Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps.
>>>
>>>> On the other hand, phys_to_virt() is called during generating vmcore
>>>> in Kexec-tools, vmcore also can't help this issue.
>>>
>>> I don't understand this part. If you have the vmcore in your hand, why can't you
>>> grok the pv offset from the note and use that in phys_to_virt()?
>>
>> It is a chicken-and-egg issue.
>> phys_to virt() is for crashdump setup. To generate vmcore, we must call
>> phys_to_virt(). At this point, no vmcore exists.
>
> Its needed for the parts of the ELF header that kexec-tools generates at kdump
> load time?
>
> So adding this pv_offset to the key=value data crash_save_vmcoreinfo_init()
> saves isn't available early enough?
Yes, one case where it is not actually available early enough for
makedumpfile usage is if we are determining the PT_NOTE contents from
the '/proc/kcore' on a 'live' system
See <https://github.com/bhupesh-sharma/makedumpfile/blob/devel/elf_info.c#L375>
for example:
int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len)
{
<snip..>
kvaddr = (ulong)vmcoreinfo_addr + PAGE_OFFSET;
}
Now the problem at hand is to determine the offset at which the
pv_offset (key=value data pair) lies in the '/proc/kcore' (I assume
that when you mentioned above and earlier about adding this pair to
the elfnotes you meant both the vmcoreinfo and 'proc/kcore'), as we
can have 'n' number of PT_LOAD segments.
So, we have a chicken and egg situation in such case(s). Do you have
any pointers on how we can fix such use-cases.
Thanks,
Bhupesh
> If we select PROC_KCORE for KEXEC so you know you will have /proc/kcore if the
> system supports kdump. We should probably provide the same information in the
> PT_NOTE section of the /proc/kcore file.
>
>
> (I thought the kdump kernel exported that crash_save_vmcoreinfo_init() data as
> an elf-note itself, but digging deeper I see the kernel exposes the physical
> address in /sys/kernel/vmcoreinfo. Presumably its passed back via the kdump
> elfcorehdr.)
>
>
>>>> Unfortunately, not all platforms support analyzing Kernel config in
>>>> userspace application, so Kexec-tools can't know some key kernel options.
>>>> If not so, we can simulate the whole arm64_memblock_init() progress
>>>> in kexec-tools.
>>>
>>> I don't understand what the kernel config has to do with kexec tools.
>>
>> I mean that if we can know kernel .config in all circumstances, we can calculate memstart_addr as below in Kexec-tools:
>>
>>
>> memstart_addr = round_down(memblock_start_of_DRAM(),
>> ARM64_MEMSTART_ALIGN);
>
> This wouldn't work for KASLR. Having the kernel provide you with the offset
> means you are insulated from the details of phys_to_virt() and what affects
> these values. It should be possible to do this in the same way for all
> architectures.
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH 15/20] dts: arm: imx7{d,s}: Update coresight binding for hardware ports
From: Stefan Agner @ 2018-06-19 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619021218.GV16091@dragon>
On 19.06.2018 04:12, Shawn Guo wrote:
> Hi Stefan,
>
> Can you take a look at the patch? Thanks.
>
> Shawn
>
> On Tue, Jun 05, 2018 at 10:43:26PM +0100, Suzuki K Poulose wrote:
>> Switch to the updated coresight bindings.
Looks good to me.
Reviewed-by: Stefan Agner <stefan@agner.ch>
--
Stefan
>>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> arch/arm/boot/dts/imx7d.dtsi | 5 ++++-
>> arch/arm/boot/dts/imx7s.dtsi | 41 ++++++++++++++++++++++++++++++-----------
>> 2 files changed, 34 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
>> index 200714e..5faff17 100644
>> --- a/arch/arm/boot/dts/imx7d.dtsi
>> +++ b/arch/arm/boot/dts/imx7d.dtsi
>> @@ -87,7 +87,9 @@
>>
>> port {
>> etm1_out_port: endpoint {
>> + direction = <1>;
>> remote-endpoint = <&ca_funnel_in_port1>;
>> + coresight,hwid = <0>;
>> };
>> };
>> };
>> @@ -174,8 +176,9 @@
>> port at 1 {
>> reg = <1>;
>> ca_funnel_in_port1: endpoint {
>> - slave-mode;
>> + direction = <0>;
>> remote-endpoint = <&etm1_out_port>;
>> + coresight,hwid = <1>;
>> };
>> };
>> };
>> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
>> index 4d42335..8e90915 100644
>> --- a/arch/arm/boot/dts/imx7s.dtsi
>> +++ b/arch/arm/boot/dts/imx7s.dtsi
>> @@ -151,23 +151,28 @@
>> port at 0 {
>> reg = <0>;
>> replicator_out_port0: endpoint {
>> + direction = <1>;
>> remote-endpoint = <&tpiu_in_port>;
>> + coresight,hwid = <0>;
>> };
>> };
>>
>> port at 1 {
>> reg = <1>;
>> replicator_out_port1: endpoint {
>> + direction = <1>;
>> remote-endpoint = <&etr_in_port>;
>> + coresight,hwid = <1>;
>> };
>> };
>>
>> /* replicator input port */
>> port at 2 {
>> - reg = <0>;
>> + reg = <2>;
>> replicator_in_port0: endpoint {
>> - slave-mode;
>> + direction = <0>;
>> remote-endpoint = <&etf_out_port>;
>> + coresight,hwid = <0>;
>> };
>> };
>> };
>> @@ -203,16 +208,19 @@
>> port at 0 {
>> reg = <0>;
>> ca_funnel_in_port0: endpoint {
>> - slave-mode;
>> + direction = <0>;
>> remote-endpoint = <&etm0_out_port>;
>> + coresight,hwid = <0>;
>> };
>> };
>>
>> /* funnel output port */
>> port at 2 {
>> - reg = <0>;
>> + reg = <2>;
>> ca_funnel_out_port0: endpoint {
>> + direction = <1>;
>> remote-endpoint = <&hugo_funnel_in_port0>;
>> + coresight,hwid = <0>;
>> };
>> };
>>
>> @@ -229,7 +237,9 @@
>>
>> port {
>> etm0_out_port: endpoint {
>> + direction = <1>;
>> remote-endpoint = <&ca_funnel_in_port0>;
>> + coresight,hwid = <0>;
>> };
>> };
>> };
>> @@ -248,22 +258,26 @@
>> port at 0 {
>> reg = <0>;
>> hugo_funnel_in_port0: endpoint {
>> - slave-mode;
>> + direction = <0>;
>> remote-endpoint = <&ca_funnel_out_port0>;
>> + coresight,hwid = <0>;
>> };
>> };
>>
>> port at 1 {
>> reg = <1>;
>> hugo_funnel_in_port1: endpoint {
>> - slave-mode; /* M4 input */
>> + direction = <0>; /* M4 input */
>> + coresight,hwid = <1>;
>> };
>> };
>>
>> port at 2 {
>> - reg = <0>;
>> + reg = <2>;
>> hugo_funnel_out_port0: endpoint {
>> + direction = <1>;
>> remote-endpoint = <&etf_in_port>;
>> + coresight,hwid = <0>;
>> };
>> };
>>
>> @@ -284,15 +298,18 @@
>> port at 0 {
>> reg = <0>;
>> etf_in_port: endpoint {
>> - slave-mode;
>> + direction = <0>;
>> remote-endpoint = <&hugo_funnel_out_port0>;
>> + coresight,hwid = <0>;
>> };
>> };
>>
>> port at 1 {
>> - reg = <0>;
>> + reg = <1>;
>> etf_out_port: endpoint {
>> + direction = <1>;
>> remote-endpoint = <&replicator_in_port0>;
>> + coresight,hwid = <0>;
>> };
>> };
>> };
>> @@ -306,8 +323,9 @@
>>
>> port {
>> etr_in_port: endpoint {
>> - slave-mode;
>> + direction = <0>;
>> remote-endpoint = <&replicator_out_port1>;
>> + coresight,hwid = <0>;
>> };
>> };
>> };
>> @@ -320,8 +338,9 @@
>>
>> port {
>> tpiu_in_port: endpoint {
>> - slave-mode;
>> + direction = <0>;
>> remote-endpoint = <&replicator_out_port1>;
>> + coresight,hwid = <0>;
>> };
>> };
>> };
>> --
>> 2.7.4
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: James Morse @ 2018-06-19 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cb5aa4ee12422ecc5f6530f3a74bcfa553b42c80.camel@redhat.com>
Hi Mark,
On 18/06/18 23:18, Mark Salter wrote:
> On Mon, 2018-06-18 at 11:04 -0700, Geoff Levand wrote:
>> Thanks for all the comments, but my lack of access to an m400 platform, and
>> my lack of knowledge about the m400 limits what I can comment on and what I
>> can do.
>
> I can take another look at this on an m400 here.
Thanks!
> I don't believe it is a
> memory access to physical space with nothing attached to it.
That is what the CPER records are describing though.
> I seem to recall
> an errata with xgene-1 where such accesses cause the cpu to halt. But I could
> be misremembering that. I have no trouble believing the firmware ras code was
> untested. It is probably some boilerplate code built in before ras was supported
> in kernel.
It would be interesting to know which GHES this error is being found in, and
whether the Error Status Block points anywhere (or at an empty block) when Linux
is started from UEFI.
If there is something in the Error Status Block out of UEFI, then this must be
something triggered by UEFI, or a bug that can be fixed by UEFI clearing out the
CPER records.
https://bugzilla.redhat.com/show_bug.cgi?id=1285107
suggests redhat can rebuild the UEFI firmware for this box.
If there is nothing in the Error Status Block when Linux is started, surely
Linux is doing something to cause this to happen. I'd like to find out what, as
its probably a software bug.
(The case where disabling HEST would be the right thing to do is if there is a
bogus GHES->GAS entry in GHES.0, the access to which causes GHES.1 to be
populated with 'Access to an address not mapped to any component', which we find
next. If this is the case it would be better to check GHES entries against the
UEFI memory map to check this is memory, and it was reserved.)
> But the problem occurs early enough in boot where there can't be
> that many things that would cause a problem on m400 and not mustang so I'll
> look again.
Playing spot the difference in the dmesg, I'd check for smoke coming out of:
| acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
| xgene-gpio APMC0D14:00: X-Gene GPIO driver registered.
| pcie_pme: probe of 0000:00:00.0:pcie001 failed with error -22
If the firmware description of the GIC is wrong in someway, disabling KVM may be
worth testing too.
Thanks,
James
^ permalink raw reply
* [PATCH v5 3/3] arm64: Introduce command line parameter to disable CNP
From: Vladimir Murzin @ 2018-06-19 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529403502-2843-1-git-send-email-vladimir.murzin@arm.com>
There are cases when activating of Common Not Private (CNP) feature
might not be desirable; this patch allows to forcefully disable CNP
even it is supported by hardware.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++++
arch/arm64/kernel/cpufeature.c | 11 ++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index efc7aa7..4abc485 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2648,6 +2648,10 @@
noclflush [BUGS=X86] Don't use the CLFLUSH instruction
+ nocnp [ARM64]
+ Disable CNP (Common not Private translations)
+ even if it is supported by processor.
+
nodelayacct [KNL] Disable per-task delay accounting
nodsp [SH] Disable hardware DSP at boot time.
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e0129f2..270fb3b 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -860,6 +860,15 @@ static bool has_cache_dic(const struct arm64_cpu_capabilities *entry,
return read_sanitised_ftr_reg(SYS_CTR_EL0) & BIT(CTR_DIC_SHIFT);
}
+static bool nocnp;
+
+static int __init early_nocnp(char *p)
+{
+ nocnp = true;
+ return 0;
+}
+early_param("nocnp", early_nocnp);
+
static bool __maybe_unused
has_useable_cnp(const struct arm64_cpu_capabilities *entry, int scope)
{
@@ -872,7 +881,7 @@ has_useable_cnp(const struct arm64_cpu_capabilities *entry, int scope)
if (elfcorehdr_size)
return false;
#endif
- return has_cpuid_feature(entry, scope);
+ return has_cpuid_feature(entry, scope) && !nocnp;
}
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
--
2.0.0
^ permalink raw reply related
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