* Re: [PATCH] firmware: imx: Add DSP IPC protocol interface
From: Daniel Baluta @ 2019-08-01 10:00 UTC (permalink / raw)
To: Shawn Guo
Cc: Aisheng Dong, Ulf Hansson, Anson Huang, Daniel Baluta, S.j. Wang,
Linux Kernel Mailing List, Oleksij Rempel, dl-linux-imx,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190723074633.GJ15632@dragon>
On Tue, Jul 23, 2019 at 10:47 AM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Tue, Jul 23, 2019 at 10:44:09AM +0300, Daniel Baluta wrote:
> > Just realized that for this patch I forgot to add [PATCH v3]. Shawn,
> > should I resend?
>
> No need.
Just sent v4 out there adding support for remove. Hope you can have some time
to have a look.
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: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 10:00 UTC (permalink / raw)
To: Janne Karhunen
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, Jonathan Corbet,
jejb, Ard Biesheuvel, Linux Doc Mailing List, James Morris,
Jarkko Sakkinen, Linux Kernel Mailing List, dhowells,
linux-security-module, keyrings, Mimi Zohar, Casey Schaufler,
linux-integrity, Jens Wiklander, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAE=Ncrae6pM+WBDu9eJ7Fw2Fkvf3_YqH5tj9Tt938D4RtWcdSQ@mail.gmail.com>
On Thu, 1 Aug 2019 at 13:30, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> > > I chose the userspace plugin due to this, you can use userspace aids
> > > to provide any type of service. Use the crypto library you desire to
> > > do the magic you want.
> >
> > Here TEE isn't similar to a user-space crypto library. In our case TEE
> > is based on ARM TrustZone which only allows TEE communications to be
> > initiated from privileged mode. So why would you like to route
> > communications via user-mode (which is less secure) when we have
> > standardised TEE interface available in kernel?
>
> The physical access guards for reading/writing the involved critical
> memory are identical as far as I know? Layered security is generally a
> good thing, and the userspace pass actually adds a layer, so not sure
> which is really safer?
>
AFAIK, layered security is better in case we move from lower privilege
level to higher privilege level rather than in reverse order.
-Sumit
> In my case the rerouting was to done generalize it. Any type of trust
> source, anywhere.
>
>
> > > > Isn't actual purpose to have trusted keys is to protect user-space
> > > > from access to kernel keys in plain format? Doesn't user mode helper
> > > > defeat that purpose in one way or another?
> > >
> > > Not really. CPU is in the user mode while running the code, but the
> > > code or the secure keydata being is not available to the 'normal'
> > > userspace. It's like microkernel service/driver this way. The usermode
> > > driver is part of the kernel image and it runs on top of a invisible
> > > rootfs.
> >
> > Can you elaborate here with an example regarding how this user-mode
> > helper will securely communicate with a hardware based trust source
> > with other user-space processes denied access to that trust source?
>
> The other user mode processes will never see the device node to open.
> There is none in existence for them; it only exists in the ramfs based
> root for the user mode helper.
>
>
> --
> Janne
_______________________________________________
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 1/2] perf: imx8_ddr_perf: add AXI ID filter support
From: Robin Murphy @ 2019-08-01 9:59 UTC (permalink / raw)
To: Joakim Zhang, will@kernel.org, mark.rutland@arm.com, Frank Li
Cc: kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org,
dl-linux-imx
In-Reply-To: <DB7PR04MB46183D09C6AB61E6AA90386FE6DE0@DB7PR04MB4618.eurprd04.prod.outlook.com>
On 2019-08-01 6:25 am, Joakim Zhang wrote:
[...]
>>> @@ -195,6 +214,18 @@ static int ddr_perf_event_init(struct perf_event
>> *event)
>>> struct hw_perf_event *hwc = &event->hw;
>>> struct perf_event *sibling;
>>>
>>> + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
>>> + if (event->attr.config == 0x41)
>>> + pmu->axi_id_read = event->attr.config1;
>>> +
>>> + if (event->attr.config == 0x42)
>>> + pmu->axi_id_write = event->attr.config1;
>>> +
>>> + if (pmu->axi_id_read && pmu->axi_id_write &&
>>> + (pmu->axi_id_read != pmu->axi_id_write))
>>> + return -EINVAL;
>>> + }
>>
>> This isn't the correct approach that Mark outlined :(
>>
>> In event_init, you should validate that any filtering for the given event is
>> compatible with any other sibling events in the same group, but you should not
>> consider (and should definitely not change) the current state of the PMU at
>> that point. This step is about rejecting event configurations which could
>> *never* be successfully scheduled (since a group represents a set of events
>> which must be scheduled all at the same time).
>>
>> In event_add, you know the given event/group is sufficiently valid to
>> *potentially* be scheduled, given that it has passed the event_init checks, but
>> you then need to check that the filtering is compatible with all other events
>> *currently* counting on the PMU. If this fails, perf core will try to reschedule
>> the current events until the new one is able to run. That's why you need the
>> additional step of validating groups beforehand, because otherwise you could
>> end up with contradictory scheduling constraints at this point and never make
>> progress.
>
> Hi Mark and Robin,
>
> Thanks for all your kindly detailed explanation firstly.
>
> My understanding from your comments, I need to validate the filtering (i.e. config1/axi_id) for *all* events in same group during event_init, right?
> But it's so strange for that axi_id is only for axi-id-read and axi-id-write event. We don't need to specify axi_id for any other events when mixed with these two events.
Sorry, I implicitly meant all *relevant* events - obviously there's
nothing to check for events which don't have filtering anyway. All that
matters is the case where we're asked to create a read/write event in a
group which already has at least one other read/write event as a
sibling. I've sketched out a quick (completely untested) example of one
way to do that part below. The logic for event_add would be very
similar, except instead of comparing the sibling against the event,
there you'd compare the event against the current PMU state.
> If I can just check the axi-id-read and axi-id-write event during event_add and then pass the axi_id value to the filter register. Don't check the case that user
> specify both of them at the same time with different filtering value. Instead of checking it in the driver, I add the doc in Documentation/admin-guide/perf/ directory
> to note that axi-id-read and axi-id-write event should be specified separately, or specified at the same time with same axi_id value.
Sure, we could just rely on the user to get it right, but that means
there's a fair chance that the user can inadvertently get it wrong, get
nonsensical results, and waste a week trying to debug a perceived
problem which doesn't actually exist. It's not difficult for the driver
to perform the correct validation, so it's better for everyone if it does.
It also seems reasonable that a user might want to intentionally measure
events on different IDs over the same run (but not in the same group),
e.g. to compare the relative average bandwidth of two devices, perhaps
to tune QoS parameters. That requires perf core to know it needs to
rotate the events during the run, which will only happen if event_add
does the right thing.
Robin.
----->8-----
diff --git a/drivers/perf/fsl_imx8_ddr_perf.c
b/drivers/perf/fsl_imx8_ddr_perf.c
index 63fe21600072..f0f643831fda 100644
--- a/drivers/perf/fsl_imx8_ddr_perf.c
+++ b/drivers/perf/fsl_imx8_ddr_perf.c
@@ -189,11 +189,23 @@ static u32 ddr_perf_read_counter(struct ddr_pmu
*pmu, int counter)
return readl_relaxed(pmu->base + COUNTER_READ + counter * 4);
}
+static bool ddr_perf_is_filtered(struct perf_event *event)
+{
+ return event->attr.config == 0x41 || event->attr.config == 0x42;
+}
+
+static u32 ddr_perf_filter_val(struct perf_event *event)
+{
+ return event->attr.config1;
+}
+
static int ddr_perf_event_init(struct perf_event *event)
{
struct ddr_pmu *pmu = to_ddr_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
struct perf_event *sibling;
+ bool is_filtered;
+ u32 filter_val;
if (event->attr.type != event->pmu->type)
return -ENOENT;
@@ -215,10 +227,17 @@ static int ddr_perf_event_init(struct perf_event
*event)
!is_software_event(event->group_leader))
return -EINVAL;
+ is_filtered = ddr_perf_is_filtered(event);
+ filter_val = ddr_perf_filter_val(event);
+
for_each_sibling_event(sibling, event->group_leader) {
if (sibling->pmu != event->pmu &&
!is_software_event(sibling))
return -EINVAL;
+
+ if (is_filtered && ddr_perf_is_filtered(sibling) &&
+ ddr_perf_filter_val(sibling) != filter_val)
+ return -EINVAL;
}
event->cpu = pmu->cpu;
_______________________________________________
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 v4] firmware: imx: Add DSP IPC protocol interface
From: Daniel Baluta @ 2019-08-01 9:56 UTC (permalink / raw)
To: shawnguo
Cc: aisheng.dong, anson.huang, gregkh, s.hauer, linux-kernel,
Daniel Baluta, o.rempel, linux-imx, kernel, tglx, festevam,
linux-arm-kernel
Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain
the Tensilica HiFi4 DSP for advanced pre- and post-audio
processing.
The communication between Host CPU and DSP firmware is
taking place using a shared memory area for message passing
and a dedicated Messaging Unit for notifications.
DSP IPC protocol offers a doorbell interface using
imx-mailbox API.
We use 4 MU channels (2 x TXDB, 2 x RXDB) to implement a
request-reply protocol.
Connection 0 (txdb0, rxdb0):
- Host writes messasge to shared memory [SHMEM]
- Host sends a request [MU]
- DSP handles request [SHMEM]
- DSP sends reply [MU]
Connection 1 (txdb1, rxdb1):
- DSP writes a message to shared memory [SHMEM]
- DSP sends a request [MU]
- Host handles request [SHMEM]
- Host sends reply [MU]
The protocol interface will be used by a Host client to
communicate with the DSP. First client will be the i.MX8
part from Sound Open Firmware infrastructure.
The protocol offers the following interface:
On Tx:
- imx_dsp_ring_doorbell, will be called to notify the DSP
that it needs to handle a request.
On Rx:
- clients need to provide two callbacks:
.handle_reply
.handle_request
- the callbacks will be used by the protocol on
notification arrival from DSP.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
---
Changes since v3:
- Added remove function
drivers/firmware/imx/Kconfig | 11 +++
drivers/firmware/imx/Makefile | 1 +
drivers/firmware/imx/imx-dsp.c | 155 +++++++++++++++++++++++++++++++
include/linux/firmware/imx/dsp.h | 67 +++++++++++++
4 files changed, 234 insertions(+)
create mode 100644 drivers/firmware/imx/imx-dsp.c
create mode 100644 include/linux/firmware/imx/dsp.h
diff --git a/drivers/firmware/imx/Kconfig b/drivers/firmware/imx/Kconfig
index 42b566f8903f..0dbee32da4c6 100644
--- a/drivers/firmware/imx/Kconfig
+++ b/drivers/firmware/imx/Kconfig
@@ -1,4 +1,15 @@
# SPDX-License-Identifier: GPL-2.0-only
+config IMX_DSP
+ bool "IMX DSP Protocol driver"
+ depends on IMX_MBOX
+ help
+ This enables DSP IPC protocol between host AP (Linux)
+ and the firmware running on DSP.
+ DSP exists on some i.MX8 processors (e.g i.MX8QM, i.MX8QXP).
+
+ It acts like a doorbell. Client might use shared memory to
+ exchange information with DSP side.
+
config IMX_SCU
bool "IMX SCU Protocol driver"
depends on IMX_MBOX
diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 802c4ad8e8f9..08bc9ddfbdfb 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_IMX_DSP) += imx-dsp.o
obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
diff --git a/drivers/firmware/imx/imx-dsp.c b/drivers/firmware/imx/imx-dsp.c
new file mode 100644
index 000000000000..a43d2db5cbdb
--- /dev/null
+++ b/drivers/firmware/imx/imx-dsp.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ * Author: Daniel Baluta <daniel.baluta@nxp.com>
+ *
+ * Implementation of the DSP IPC interface (host side)
+ */
+
+#include <linux/firmware/imx/dsp.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_client.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+/*
+ * imx_dsp_ring_doorbell - triggers an interrupt on the other side (DSP)
+ *
+ * @dsp: DSP IPC handle
+ * @chan_idx: index of the channel where to trigger the interrupt
+ *
+ * Returns non-negative value for success, negative value for error
+ */
+int imx_dsp_ring_doorbell(struct imx_dsp_ipc *ipc, unsigned int idx)
+{
+ int ret;
+ struct imx_dsp_chan *dsp_chan;
+
+ if (idx >= DSP_MU_CHAN_NUM)
+ return -EINVAL;
+
+ dsp_chan = &ipc->chans[idx];
+ ret = mbox_send_message(dsp_chan->ch, NULL);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL(imx_dsp_ring_doorbell);
+
+/*
+ * imx_dsp_handle_rx - rx callback used by imx mailbox
+ *
+ * @c: mbox client
+ * @msg: message received
+ *
+ * Users of DSP IPC will need to privde handle_reply and handle_request
+ * callbacks.
+ */
+static void imx_dsp_handle_rx(struct mbox_client *c, void *msg)
+{
+ struct imx_dsp_chan *chan = container_of(c, struct imx_dsp_chan, cl);
+
+ if (chan->idx == 0) {
+ chan->ipc->ops->handle_reply(chan->ipc);
+ } else {
+ chan->ipc->ops->handle_request(chan->ipc);
+ imx_dsp_ring_doorbell(chan->ipc, 1);
+ }
+}
+
+static int imx_dsp_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct imx_dsp_ipc *dsp_ipc;
+ struct imx_dsp_chan *dsp_chan;
+ struct mbox_client *cl;
+ char *chan_name;
+ int ret;
+ int i, j;
+
+ device_set_of_node_from_dev(&pdev->dev, pdev->dev.parent);
+
+ dsp_ipc = devm_kzalloc(dev, sizeof(*dsp_ipc), GFP_KERNEL);
+ if (!dsp_ipc)
+ return -ENOMEM;
+
+ for (i = 0; i < DSP_MU_CHAN_NUM; i++) {
+ if (i < 2)
+ chan_name = kasprintf(GFP_KERNEL, "txdb%d", i);
+ else
+ chan_name = kasprintf(GFP_KERNEL, "rxdb%d", i - 2);
+
+ if (!chan_name)
+ return -ENOMEM;
+
+ dsp_chan = &dsp_ipc->chans[i];
+ cl = &dsp_chan->cl;
+ cl->dev = dev;
+ cl->tx_block = false;
+ cl->knows_txdone = true;
+ cl->rx_callback = imx_dsp_handle_rx;
+
+ dsp_chan->ipc = dsp_ipc;
+ dsp_chan->idx = i % 2;
+ dsp_chan->ch = mbox_request_channel_byname(cl, chan_name);
+ if (IS_ERR(dsp_chan->ch)) {
+ ret = PTR_ERR(dsp_chan->ch);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to request mbox chan %s ret %d\n",
+ chan_name, ret);
+ goto out;
+ }
+
+ dev_dbg(dev, "request mbox chan %s\n", chan_name);
+ /* chan_name is not used anymore by framework */
+ kfree(chan_name);
+ }
+
+ dsp_ipc->dev = dev;
+
+ dev_set_drvdata(dev, dsp_ipc);
+
+ dev_info(dev, "NXP i.MX DSP IPC initialized\n");
+
+ return devm_of_platform_populate(dev);
+out:
+ kfree(chan_name);
+ for (j = 0; j < i; j++) {
+ dsp_chan = &dsp_ipc->chans[j];
+ mbox_free_channel(dsp_chan->ch);
+ }
+
+ return ret;
+}
+
+static int imx_dsp_remove(struct platform_device *pdev)
+{
+ struct imx_dsp_chan *dsp_chan;
+ struct imx_dsp_ipc *dsp_ipc;
+ int i;
+
+ dsp_ipc = dev_get_drvdata(&pdev->dev);
+
+ for (i = 0; i < DSP_MU_CHAN_NUM; i++) {
+ dsp_chan = &dsp_ipc->chans[i];
+ mbox_free_channel(dsp_chan->ch);
+ }
+
+ return 0;
+}
+
+static struct platform_driver imx_dsp_driver = {
+ .driver = {
+ .name = "imx-dsp",
+ },
+ .probe = imx_dsp_probe,
+ .remove = imx_dsp_remove,
+};
+builtin_platform_driver(imx_dsp_driver);
+
+MODULE_AUTHOR("Daniel Baluta <daniel.baluta@nxp.com>");
+MODULE_DESCRIPTION("IMX DSP IPC protocol driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/firmware/imx/dsp.h b/include/linux/firmware/imx/dsp.h
new file mode 100644
index 000000000000..7562099c9e46
--- /dev/null
+++ b/include/linux/firmware/imx/dsp.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2019 NXP
+ *
+ * Header file for the DSP IPC implementation
+ */
+
+#ifndef _IMX_DSP_IPC_H
+#define _IMX_DSP_IPC_H
+
+#include <linux/device.h>
+#include <linux/types.h>
+#include <linux/mailbox_client.h>
+
+#define DSP_MU_CHAN_NUM 4
+
+struct imx_dsp_chan {
+ struct imx_dsp_ipc *ipc;
+ struct mbox_client cl;
+ struct mbox_chan *ch;
+ char *name;
+ int idx;
+};
+
+struct imx_dsp_ops {
+ void (*handle_reply)(struct imx_dsp_ipc *ipc);
+ void (*handle_request)(struct imx_dsp_ipc *ipc);
+};
+
+struct imx_dsp_ipc {
+ /* Host <-> DSP communication uses 2 txdb and 2 rxdb channels */
+ struct imx_dsp_chan chans[DSP_MU_CHAN_NUM];
+ struct device *dev;
+ struct imx_dsp_ops *ops;
+ void *private_data;
+};
+
+static inline void imx_dsp_set_data(struct imx_dsp_ipc *ipc, void *data)
+{
+ if (!ipc)
+ return;
+
+ ipc->private_data = data;
+}
+
+static inline void *imx_dsp_get_data(struct imx_dsp_ipc *ipc)
+{
+ if (!ipc)
+ return NULL;
+
+ return ipc->private_data;
+}
+
+#if IS_ENABLED(CONFIG_IMX_DSP)
+
+int imx_dsp_ring_doorbell(struct imx_dsp_ipc *dsp, unsigned int chan_idx);
+
+#else
+
+static inline int imx_dsp_ring_doorbell(struct imx_dsp_ipc *ipc,
+ unsigned int chan_idx)
+{
+ return -ENOTSUPP;
+}
+
+#endif
+#endif /* _IMX_DSP_IPC_H */
--
2.17.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: [PATCH] serial: imx: Avoid probe failure in case of missing gpiolib
From: Uwe Kleine-König @ 2019-08-01 9:55 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, Greg Kroah-Hartman, Sascha Hauer,
linux-kernel@vger.kernel.org, NXP Linux Team,
Pengutronix Kernel Team, Jiri Slaby, Shawn Guo, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <0674d68b-99fa-3408-1dd1-22dc84144b43@kontron.de>
On Thu, Aug 01, 2019 at 09:28:33AM +0000, Schrempf Frieder wrote:
> Hi Uwe,
>
> On 01.08.19 10:48, Uwe Kleine-König wrote:
> > On Thu, Aug 01, 2019 at 08:18:05AM +0000, Schrempf Frieder wrote:
> >> From: Frieder Schrempf <frieder.schrempf@kontron.de>
> >>
> >> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() will return
> >> -ENOSYS and cause the probing of the imx UART to fail. As the
> >> GPIOs are optional, we should continue probing in this case.
> >
> > Is this really still the case? On which version did you hit this
> > problem?
>
> Yes, I think it is. I used v5.2.5, that already has d99482673f95.
>
> >
> > I would expect that is gone with
> > d99482673f950817b30caf3fcdfb31179b050ce1 if not earlier.
>
> I think this is a different problem. If CONFIG_GPIOLIB is disabled,
> mctrl_gpio_init() returns -ENOSYS unconditionally here: [1]. The
> existing patch (d99482673f95) seems to handle the case when
> CONFIG_GPIOLIB is enabled, but no or not all GPIOs are given in the dtb.
Ah, I see.
I don't think we should handle this on a per-driver basis. So my
suggestion is to drop the dummy implementation for mctrl_gpio if GPIOLIB
is disabled. Then the behaviour should be consistant with the gpio stuff
returning NULL in this case. (Or alternatively adapt the dummy
implementation to shortcut and behave identically.)
(Having said that I don't like gpiolib's behaviour of returning NULL for
the optional calls if it's disabled, but having mctrl_gpio behave
differently is worse.)
> The sh-sci.c driver has a similar check to skip this case: [2].
This should than be dropped, too.
Best regards
Uwe
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/serial_mctrl_gpio.h#n121
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/sh-sci.c#n3290
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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/6] irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts
From: Marc Zyngier @ 2019-08-01 9:42 UTC (permalink / raw)
To: Suman Anna, Thomas Gleixner, Jason Cooper
Cc: devicetree, Grygorii Strashko, David Lechner, Tony Lindgren,
Sekhar Nori, linux-kernel, Andrew F. Davis, Lokesh Vutla,
Rob Herring, Murali Karicheri, linux-omap, linux-arm-kernel,
Roger Quadros
In-Reply-To: <20190731224149.11153-3-s-anna@ti.com>
On 31/07/2019 23:41, Suman Anna wrote:
> From: "Andrew F. Davis" <afd@ti.com>
>
> The Programmable Real-Time Unit Subsystem (PRUSS) contains a local
> interrupt controller (INTC) that can handle various system input events
> and post interrupts back to the device-level initiators. The INTC can
> support upto 64 input events with individual control configuration and
> hardware prioritization. These events are mapped onto 10 output interrupt
> lines through two levels of many-to-one mapping support. Different
> interrupt lines are routed to the individual PRU cores or to the host
> CPU, or to other devices on the SoC. Some of these events are sourced
> from peripherals or other sub-modules within that PRUSS, while a few
> others are sourced from SoC-level peripherals/devices.
>
> The PRUSS INTC platform driver manages this PRUSS interrupt controller
> and implements an irqchip driver to provide a Linux standard way for
> the PRU client users to enable/disable/ack/re-trigger a PRUSS system
> event. The system events to interrupt channels and output interrupts
> relies on the mapping configuration provided either through the PRU
> firmware blob or via the PRU application's device tree node. The
> mappings will be programmed during the boot/shutdown of a PRU core.
>
> The PRUSS INTC module is reference counted during the interrupt
> setup phase through the irqchip's irq_request_resources() and
> irq_release_resources() ops. This restricts the module from being
> removed as long as there are active interrupt users.
>
> The driver currently supports and can be built for OMAP architecture
> based AM335x, AM437x and AM57xx SoCs; Keystone2 architecture based
> 66AK2G SoCs and Davinci architecture based OMAP-L13x/AM18x/DA850 SoCs.
> All of these SoCs support 64 system events, 10 interrupt channels and
> 10 output interrupt lines per PRUSS INTC with a few SoC integration
> differences.
>
> NOTE:
> Each PRU-ICSS's INTC on AM57xx SoCs is preceded by a Crossbar that
> enables multiple external events to be routed to a specific number
> of input interrupt events. Any non-default external interrupt event
> directed towards PRUSS needs this crossbar to be setup properly.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> v2:
> - Addressed all of David Lechner's comments
> - Dropped irq_retrigger callback
> - Updated interrupt names from "hostX" to "host_intrX"
> - Moved host_mask variable to patch 4
> v1: https://patchwork.kernel.org/patch/11034545/
> v0: https://patchwork.kernel.org/patch/10795761/
>
> drivers/irqchip/Kconfig | 10 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-pruss-intc.c | 338 +++++++++++++++++++++++++++++++
> 3 files changed, 349 insertions(+)
> create mode 100644 drivers/irqchip/irq-pruss-intc.c
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 80e10f4e213a..dc6b5aa77a5d 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -471,6 +471,16 @@ config TI_SCI_INTA_IRQCHIP
> If you wish to use interrupt aggregator irq resources managed by the
> TI System Controller, say Y here. Otherwise, say N.
>
> +config TI_PRUSS_INTC
> + tristate "TI PRU-ICSS Interrupt Controller"
> + depends on ARCH_DAVINCI || SOC_AM33XX || SOC_AM437X || SOC_DRA7XX || ARCH_KEYSTONE
> + select IRQ_DOMAIN
> + help
> + This enables support for the PRU-ICSS Local Interrupt Controller
> + present within a PRU-ICSS subsystem present on various TI SoCs.
> + The PRUSS INTC enables various interrupts to be routed to multiple
> + different processors within the SoC.
> +
> endmenu
>
> config SIFIVE_PLIC
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 8d0fcec6ab23..a02e652ca805 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -102,3 +102,4 @@ obj-$(CONFIG_MADERA_IRQ) += irq-madera.o
> obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o
> obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o
> obj-$(CONFIG_TI_SCI_INTA_IRQCHIP) += irq-ti-sci-inta.o
> +obj-$(CONFIG_TI_PRUSS_INTC) += irq-pruss-intc.o
> diff --git a/drivers/irqchip/irq-pruss-intc.c b/drivers/irqchip/irq-pruss-intc.c
> new file mode 100644
> index 000000000000..4a9456544fd0
> --- /dev/null
> +++ b/drivers/irqchip/irq-pruss-intc.c
> @@ -0,0 +1,338 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PRU-ICSS INTC IRQChip driver for various TI SoCs
> + *
> + * Copyright (C) 2016-2019 Texas Instruments Incorporated - http://www.ti.com/
> + * Andrew F. Davis <afd@ti.com>
> + * Suman Anna <s-anna@ti.com>
> + */
> +
> +#include <linux/irq.h>
> +#include <linux/irqchip/chained_irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +
> +/*
> + * Number of host interrupts reaching the main MPU sub-system. Note that this
> + * is not the same as the total number of host interrupts supported by the PRUSS
> + * INTC instance
> + */
> +#define MAX_NUM_HOST_IRQS 8
> +
> +/* minimum starting host interrupt number for MPU */
> +#define MIN_PRU_HOST_INT 2
> +
> +/* maximum number of system events */
> +#define MAX_PRU_SYS_EVENTS 64
> +
> +/* PRU_ICSS_INTC registers */
> +#define PRU_INTC_REVID 0x0000
> +#define PRU_INTC_CR 0x0004
> +#define PRU_INTC_GER 0x0010
> +#define PRU_INTC_GNLR 0x001c
> +#define PRU_INTC_SISR 0x0020
> +#define PRU_INTC_SICR 0x0024
> +#define PRU_INTC_EISR 0x0028
> +#define PRU_INTC_EICR 0x002c
> +#define PRU_INTC_HIEISR 0x0034
> +#define PRU_INTC_HIDISR 0x0038
> +#define PRU_INTC_GPIR 0x0080
> +#define PRU_INTC_SRSR0 0x0200
> +#define PRU_INTC_SRSR1 0x0204
> +#define PRU_INTC_SECR0 0x0280
> +#define PRU_INTC_SECR1 0x0284
> +#define PRU_INTC_ESR0 0x0300
> +#define PRU_INTC_ESR1 0x0304
> +#define PRU_INTC_ECR0 0x0380
> +#define PRU_INTC_ECR1 0x0384
> +#define PRU_INTC_CMR(x) (0x0400 + (x) * 4)
> +#define PRU_INTC_HMR(x) (0x0800 + (x) * 4)
> +#define PRU_INTC_HIPIR(x) (0x0900 + (x) * 4)
> +#define PRU_INTC_SIPR0 0x0d00
> +#define PRU_INTC_SIPR1 0x0d04
> +#define PRU_INTC_SITR0 0x0d80
> +#define PRU_INTC_SITR1 0x0d84
> +#define PRU_INTC_HINLR(x) (0x1100 + (x) * 4)
> +#define PRU_INTC_HIER 0x1500
> +
> +/* HIPIR register bit-fields */
> +#define INTC_HIPIR_NONE_HINT 0x80000000
> +
> +/**
> + * struct pruss_intc - PRUSS interrupt controller structure
> + * @irqs: kernel irq numbers corresponding to PRUSS host interrupts
> + * @base: base virtual address of INTC register space
> + * @irqchip: irq chip for this interrupt controller
> + * @domain: irq domain for this interrupt controller
> + * @lock: mutex to serialize access to INTC
> + */
> +struct pruss_intc {
> + unsigned int irqs[MAX_NUM_HOST_IRQS];
> + void __iomem *base;
> + struct irq_chip *irqchip;
> + struct irq_domain *domain;
> + struct mutex lock; /* PRUSS INTC lock */
Nothing seem to use that lock in this patch (other than to initialize it).
> +};
> +
> +static inline u32 pruss_intc_read_reg(struct pruss_intc *intc, unsigned int reg)
> +{
> + return readl_relaxed(intc->base + reg);
> +}
> +
> +static inline void pruss_intc_write_reg(struct pruss_intc *intc,
> + unsigned int reg, u32 val)
> +{
> + writel_relaxed(val, intc->base + reg);
> +}
> +
> +static int pruss_intc_check_write(struct pruss_intc *intc, unsigned int reg,
> + unsigned int sysevent)
> +{
> + if (!intc)
> + return -EINVAL;
> +
> + if (sysevent >= MAX_PRU_SYS_EVENTS)
> + return -EINVAL;
How can any of these happen? That'd be a bug in the driver surely.
Also, nothing ever checks the return value.
> +
> + pruss_intc_write_reg(intc, reg, sysevent);
> +
> + return 0;
> +}
> +
> +static void pruss_intc_init(struct pruss_intc *intc)
> +{
> + int i;
> +
> + /* configure polarity to active high for all system interrupts */
> + pruss_intc_write_reg(intc, PRU_INTC_SIPR0, 0xffffffff);
> + pruss_intc_write_reg(intc, PRU_INTC_SIPR1, 0xffffffff);
> +
> + /* configure type to pulse interrupt for all system interrupts */
> + pruss_intc_write_reg(intc, PRU_INTC_SITR0, 0);
> + pruss_intc_write_reg(intc, PRU_INTC_SITR1, 0);
> +
> + /* clear all 16 interrupt channel map registers */
> + for (i = 0; i < 16; i++)
> + pruss_intc_write_reg(intc, PRU_INTC_CMR(i), 0);
> +
> + /* clear all 3 host interrupt map registers */
> + for (i = 0; i < 3; i++)
> + pruss_intc_write_reg(intc, PRU_INTC_HMR(i), 0);
> +}
> +
> +static void pruss_intc_irq_ack(struct irq_data *data)
> +{
> + struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
> + unsigned int hwirq = data->hwirq;
> +
> + pruss_intc_check_write(intc, PRU_INTC_SICR, hwirq);
> +}
> +
> +static void pruss_intc_irq_mask(struct irq_data *data)
> +{
> + struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
> + unsigned int hwirq = data->hwirq;
> +
> + pruss_intc_check_write(intc, PRU_INTC_EICR, hwirq);
> +}
> +
> +static void pruss_intc_irq_unmask(struct irq_data *data)
> +{
> + struct pruss_intc *intc = irq_data_get_irq_chip_data(data);
> + unsigned int hwirq = data->hwirq;
> +
> + pruss_intc_check_write(intc, PRU_INTC_EISR, hwirq);
> +}
> +
> +static int pruss_intc_irq_reqres(struct irq_data *data)
> +{
> + if (!try_module_get(THIS_MODULE))
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> +static void pruss_intc_irq_relres(struct irq_data *data)
> +{
> + module_put(THIS_MODULE);
> +}
> +
> +static int pruss_intc_irq_domain_map(struct irq_domain *d, unsigned int virq,
> + irq_hw_number_t hw)
> +{
> + struct pruss_intc *intc = d->host_data;
> +
> + irq_set_chip_data(virq, intc);
> + irq_set_chip_and_handler(virq, intc->irqchip, handle_level_irq);
> +
> + return 0;
> +}
> +
> +static void pruss_intc_irq_domain_unmap(struct irq_domain *d, unsigned int virq)
> +{
> + irq_set_chip_and_handler(virq, NULL, NULL);
> + irq_set_chip_data(virq, NULL);
> +}
> +
> +static const struct irq_domain_ops pruss_intc_irq_domain_ops = {
> + .xlate = irq_domain_xlate_onecell,
> + .map = pruss_intc_irq_domain_map,
> + .unmap = pruss_intc_irq_domain_unmap,
> +};
> +
> +static void pruss_intc_irq_handler(struct irq_desc *desc)
> +{
> + unsigned int irq = irq_desc_get_irq(desc);
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct pruss_intc *intc = irq_get_handler_data(irq);
> + u32 hipir;
> + unsigned int virq;
> + int i, hwirq;
> +
> + chained_irq_enter(chip, desc);
> +
> + /* find our host irq number */
> + for (i = 0; i < MAX_NUM_HOST_IRQS; i++)
> + if (intc->irqs[i] == irq)
> + break;
> + if (i == MAX_NUM_HOST_IRQS)
> + goto err;
> +
> + i += MIN_PRU_HOST_INT;
> +
> + /* get highest priority pending PRUSS system event */
> + hipir = pruss_intc_read_reg(intc, PRU_INTC_HIPIR(i));
> + while (!(hipir & INTC_HIPIR_NONE_HINT)) {
> + hwirq = hipir & GENMASK(9, 0);
> + virq = irq_linear_revmap(intc->domain, hwirq);
> +
> + /*
> + * NOTE: manually ACK any system events that do not have a
> + * handler mapped yet
> + */
> + if (unlikely(!virq))
> + pruss_intc_check_write(intc, PRU_INTC_SICR, hwirq);
How were they configured the first place?
> + else
> + generic_handle_irq(virq);
> +
> + /* get next system event */
> + hipir = pruss_intc_read_reg(intc, PRU_INTC_HIPIR(i));
> + }
> +err:
> + chained_irq_exit(chip, desc);
> +}
> +
> +static int pruss_intc_probe(struct platform_device *pdev)
> +{
> + static const char * const irq_names[] = {
Should this be sized with MAX_NUM_HOST_IRQS, given that this is how you
parse it?
> + "host_intr0", "host_intr1", "host_intr2", "host_intr3",
> + "host_intr4", "host_intr5", "host_intr6", "host_intr7", };
> + struct device *dev = &pdev->dev;
> + struct pruss_intc *intc;
> + struct resource *res;
> + struct irq_chip *irqchip;
> + int i, irq;
> +
> + intc = devm_kzalloc(dev, sizeof(*intc), GFP_KERNEL);
> + if (!intc)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, intc);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + intc->base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(intc->base)) {
> + dev_err(dev, "failed to parse and map intc memory resource\n");
> + return PTR_ERR(intc->base);
> + }
> +
> + dev_dbg(dev, "intc memory: pa %pa size 0x%zx va %pK\n", &res->start,
> + (size_t)resource_size(res), intc->base);
> +
> + mutex_init(&intc->lock);
> +
> + pruss_intc_init(intc);
> +
> + irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
> + if (!irqchip)
> + return -ENOMEM;
> +
> + irqchip->irq_ack = pruss_intc_irq_ack;
> + irqchip->irq_mask = pruss_intc_irq_mask;
> + irqchip->irq_unmask = pruss_intc_irq_unmask;
> + irqchip->irq_request_resources = pruss_intc_irq_reqres;
> + irqchip->irq_release_resources = pruss_intc_irq_relres;
> + irqchip->name = dev_name(dev);
> + intc->irqchip = irqchip;
Given that each and every pruss_intc ends up with a pointer to its own
irqchip, why is it a separate allocation instead of directly embedding
the structure?
Alternatively, have a single 'static const struct irq_chip' and lose the
slightly pointless dev_name as the irqchip name.
> +
> + /* always 64 events */
> + intc->domain = irq_domain_add_linear(dev->of_node, MAX_PRU_SYS_EVENTS,
> + &pruss_intc_irq_domain_ops, intc);
> + if (!intc->domain)
> + return -ENOMEM;
> +
> + for (i = 0; i < MAX_NUM_HOST_IRQS; i++) {
> + irq = platform_get_irq_byname(pdev, irq_names[i]);
> + if (irq < 0) {
irq == 0 is also an error.
> + dev_err(dev, "platform_get_irq_byname failed for %s : %d\n",
> + irq_names[i], irq);
> + goto fail_irq;
> + }
> +
> + intc->irqs[i] = irq;
> + irq_set_handler_data(irq, intc);
> + irq_set_chained_handler(irq, pruss_intc_irq_handler);
> + }
> +
> + return 0;
> +
> +fail_irq:
> + while (--i >= 0) {
> + if (intc->irqs[i])
This 'if' seems supperfluous.
> + irq_set_chained_handler_and_data(intc->irqs[i], NULL,
> + NULL);
> + }
> + irq_domain_remove(intc->domain);
> + return irq;
> +}
> +
> +static int pruss_intc_remove(struct platform_device *pdev)
> +{
> + struct pruss_intc *intc = platform_get_drvdata(pdev);
> + unsigned int hwirq;
> + int i;
> +
> + for (i = 0; i < MAX_NUM_HOST_IRQS; i++) {
> + if (intc->irqs[i])
Same here.
> + irq_set_chained_handler_and_data(intc->irqs[i], NULL,
> + NULL);
> + }
> +
> + for (hwirq = 0; hwirq < MAX_PRU_SYS_EVENTS; hwirq++)
> + irq_dispose_mapping(irq_find_mapping(intc->domain, hwirq));
> + irq_domain_remove(intc->domain);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id pruss_intc_of_match[] = {
> + { .compatible = "ti,pruss-intc", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, pruss_intc_of_match);
> +
> +static struct platform_driver pruss_intc_driver = {
> + .driver = {
> + .name = "pruss-intc",
> + .of_match_table = pruss_intc_of_match,
> + },
> + .probe = pruss_intc_probe,
> + .remove = pruss_intc_remove,
> +};
> +module_platform_driver(pruss_intc_driver);
> +
> +MODULE_AUTHOR("Andrew F. Davis <afd@ti.com>");
> +MODULE_AUTHOR("Suman Anna <s-anna@ti.com>");
> +MODULE_DESCRIPTION("TI PRU-ICSS INTC Driver");
> +MODULE_LICENSE("GPL v2");
>
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] tracing: Function stack size and its name mismatch in arm64
From: Will Deacon @ 2019-08-01 9:41 UTC (permalink / raw)
To: Jiping Ma
Cc: catalin.marinas, will.deacon, linux-kernel, rostedt, mingo, joel,
linux-arm-kernel
In-Reply-To: <20190801083340.57075-1-jiping.ma2@windriver.com>
On Thu, Aug 01, 2019 at 04:33:40PM +0800, Jiping Ma wrote:
> In arm64, the PC of the frame is matched to the last frame function,
> rather than the function of his frame. For the following example, the
> stack size of occupy_stack_init function should be 3376, rather than 176.
>
> Wrong info:
> Depth Size Location (16 entries)
> ----- ---- --------
> 0) 5400 16 __update_load_avg_se.isra.2+0x28/0x220
> 1) 5384 96 put_prev_entity+0x250/0x338
> 2) 5288 80 pick_next_task_fair+0x4c4/0x508
> 3) 5208 72 __schedule+0x100/0x600
> 4) 5136 184 preempt_schedule_common+0x28/0x48
> 5) 4952 32 preempt_schedule+0x28/0x30
> 6) 4920 16 vprintk_emit+0x170/0x1f8
> 7) 4904 128 vprintk_default+0x48/0x58
> 8) 4776 64 vprintk_func+0xf8/0x1c8
> 9) 4712 112 printk+0x70/0x90
> 10) 4600 176 occupy_stack_init+0x64/0xc0 [kernel_stack]
> 11) 4424 3376 do_one_initcall+0x68/0x248
> 12) 1048 144 do_init_module+0x60/0x1f0
> 13) 904 48 load_module+0x1d50/0x2340
> 14) 856 352 sys_finit_module+0xd0/0xe8
> 15) 504 504 el0_svc_naked+0x30/0x34
>
> Correct info:
> Depth Size Location (18 entries)
> ----- ---- --------
> 0) 5464 48 cgroup_rstat_updated+0x20/0x100
> 1) 5416 32 cgroup_base_stat_cputime_account_end.isra.0+0x30/0x60
> 2) 5384 32 __cgroup_account_cputime+0x3c/0x48
> 3) 5352 64 update_curr+0xc4/0x1d0
> 4) 5288 72 pick_next_task_fair+0x444/0x508
> 5) 5216 184 __schedule+0x100/0x600
> 6) 5032 32 preempt_schedule_common+0x28/0x48
> 7) 5000 16 preempt_schedule+0x28/0x30
> 8) 4984 128 vprintk_emit+0x170/0x1f8
> 9) 4856 64 vprintk_default+0x48/0x58
> 10) 4792 112 vprintk_func+0xf8/0x1c8
> 11) 4680 176 printk+0x70/0x90
> 12) 4504 80 func_test+0x7c/0xb8 [kernel_stack]
> 13) 4424 3376 occupy_stack_init+0x7c/0xc0 [kernel_stack]
> 14) 1048 144 do_one_initcall+0x68/0x248
> 15) 904 48 do_init_module+0x60/0x1f0
> 16) 856 352 load_module+0x1d50/0x2340
> 17) 504 504 sys_finit_module+0xd0/0xe8
>
> Signed-off-by: Jiping Ma <jiping.ma2@windriver.com>
> ---
> kernel/trace/trace_stack.c | 28 ++++++++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
> index 5d16f73898db..ed80b95abf06 100644
> --- a/kernel/trace/trace_stack.c
> +++ b/kernel/trace/trace_stack.c
> @@ -40,16 +40,28 @@ static void print_max_stack(void)
>
> pr_emerg(" Depth Size Location (%d entries)\n"
> " ----- ---- --------\n",
> +#ifdef CONFIG_ARM64
> + stack_trace_nr_entries - 1);
> +#else
> stack_trace_nr_entries);
Sorry, but I have no idea what the problem is here. All I know is that the
solution looks highly dubious and I find it very hard to believe that the
arm64 backtracing code is uniquely special as to deserve being called out
like this. I suspect there's a bug lurking somewhere, but you really need
to do a better job of explaining the issue rather than simply providing a
couple of backtraces with no context.
*Why* does the frame appear to be off-by-one?
Will
_______________________________________________
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 1/2] arm: dts: exynos: Add GPU/Mali T604 node to exynos5250
From: Marek Szyprowski @ 2019-08-01 9:35 UTC (permalink / raw)
To: Guillaume Gardet, Krzysztof Kozlowski
Cc: linux-samsung-soc@vger.kernel.org, Kukjin Kim,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DBBPR08MB4678D2A9A042269A8934E84183DF0@DBBPR08MB4678.eurprd08.prod.outlook.com>
Hi Guillaume,
On 2019-07-31 16:37, Guillaume Gardet wrote:
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: 26 July 2019 12:40
>> To: Guillaume Gardet <Guillaume.Gardet@arm.com>
>> Cc: linux-samsung-soc@vger.kernel.org; Kukjin Kim <kgene@kernel.org>;
>> linux-arm-kernel@lists.infradead.org
>> Subject: Re: [PATCH V2 1/2] arm: dts: exynos: Add GPU/Mali T604 node to
>> exynos5250
>>
>> On Thu, 25 Jul 2019 at 14:37, Guillaume Gardet <Guillaume.Gardet@arm.com>
>> wrote:
>>>> No, regulator is not provided. On all Exynos boards Mali uses its
>>>> own dedicated regulator (and sometimes additional one). It worked in
>>>> your case because the regulator was set as always-on but this is a
>> workaround for lack of consumers.
>>>> Once there is a consumer, the regulator should not be always-on to
>>>> save the energy when not used.
>>> I do not have the required info here. Do you have it, or could I skip the
>> mali-supply for now?
>>
>> You can guess from regulator name :)
>> For the Arndale, the schematics are saying it is buck4.
> Thanks. This is buck4 as well for snow.
>
> On Arndale board, buck4 has a fixed voltage of 1V contrary to snow, which leads to the following error:
> [ 21.131930] panfrost 11800000.gpu: Cannot set voltage 925000 uV
>
> The following change fixes the previous error:
> - regulator-min-microvolt = <1000000>;
> - regulator-max-microvolt = <1000000>;
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <1300000>;
>
> Should I remove arndale enablement for now until this is fixed separately, or could I add this fixup in this patch serie, as it is related?
It is okay to add this fixup to the patch, which sets mali regulator on
arndale board.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
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] serial: imx: Avoid probe failure in case of missing gpiolib
From: Schrempf Frieder @ 2019-08-01 9:28 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-serial@vger.kernel.org, Greg Kroah-Hartman, Sascha Hauer,
linux-kernel@vger.kernel.org, NXP Linux Team,
Pengutronix Kernel Team, Jiri Slaby, Shawn Guo, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190801084827.m42ci3amo37hmesi@pengutronix.de>
Hi Uwe,
On 01.08.19 10:48, Uwe Kleine-König wrote:
> On Thu, Aug 01, 2019 at 08:18:05AM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() will return
>> -ENOSYS and cause the probing of the imx UART to fail. As the
>> GPIOs are optional, we should continue probing in this case.
>
> Is this really still the case? On which version did you hit this
> problem?
Yes, I think it is. I used v5.2.5, that already has d99482673f95.
>
> I would expect that is gone with
> d99482673f950817b30caf3fcdfb31179b050ce1 if not earlier.
I think this is a different problem. If CONFIG_GPIOLIB is disabled,
mctrl_gpio_init() returns -ENOSYS unconditionally here: [1]. The
existing patch (d99482673f95) seems to handle the case when
CONFIG_GPIOLIB is enabled, but no or not all GPIOs are given in the dtb.
The sh-sci.c driver has a similar check to skip this case: [2].
Regards,
Frieder
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/serial_mctrl_gpio.h#n121
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/sh-sci.c#n3290
_______________________________________________
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 0/3] reset: meson: update with SPDX Licence identifier
From: Philipp Zabel @ 2019-08-01 9:03 UTC (permalink / raw)
To: Neil Armstrong; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <20190801075454.23547-1-narmstrong@baylibre.com>
On Thu, 2019-08-01 at 09:54 +0200, Neil Armstrong wrote:
> This serie updates the Amlogic Reset driver and bindings.
>
> Neil Armstrong (3):
> reset: reset-meson: update with SPDX Licence identifier
> dt-bindings: reset: amlogic,meson-gxbb-reset: update with SPDX Licence
> identifier
> dt-bindings: reset: amlogic,meson8b-reset: update with SPDX Licence
> identifier
Thank you, all three applied to reset/next.
regards
Philipp
_______________________________________________
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 1/1] dt-bindings: reset: Fix typo in imx8mq resets
From: Philipp Zabel @ 2019-08-01 9:01 UTC (permalink / raw)
To: Guido Günther, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Rob Herring, Mark Rutland, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <660b4fb6ab9acec05aa5fde323d878e04e3d1f64.1564647612.git.agx@sigxcpu.org>
On Thu, 2019-08-01 at 10:20 +0200, Guido Günther wrote:
> Some of the mipi dsi resets were called
>
> IMX8MQ_RESET_MIPI_DIS__
>
> instead of
>
> IMX8MQ_RESET_MIPI_DSI__
>
> Since they're DSI related this looks like a typo. This fixes the
> only in tree user as well to not break bisecting.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
Thank you, this was a typo in the Rev.0 reference manual.
It has been fixed in Rev. 1.
Applied to reset/next with Lucas' R-b.
regards
Philipp
_______________________________________________
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.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context
From: Julien Thierry @ 2019-08-01 8:49 UTC (permalink / raw)
To: Greg KH, Will Deacon
Cc: Mark Rutland, Marc Zyngier, Viresh Kumar, Will Deacon, stable,
mark.brown, linux-arm-kernel, Catalin Marinas, Russell King,
julien.thierry.kdev
In-Reply-To: <20190801084354.GA1085@kroah.com>
On 01/08/2019 09:43, Greg KH wrote:
> On Thu, Aug 01, 2019 at 08:34:45AM +0100, Will Deacon wrote:
>> On Thu, Aug 01, 2019 at 12:35:41PM +0530, Viresh Kumar wrote:
>>> On 01-08-19, 08:57, Greg KH wrote:
>>>> On Thu, Aug 01, 2019 at 12:05:44PM +0530, Viresh Kumar wrote:
>>>>> On 01-08-19, 07:30, Julien Thierry wrote:
>>>>>> I must admit I am not familiar with backport/stable process enough. But
>>>>>> personally I think the your suggestion seems more sensible than
>>>>>> backporting 4 patches.
>>>>>>
>>>>>> Or you can maybe ignore patch 25 and say in patch 24 that among the
>>>>>> changes made for the 4.4 codebase, the call arm64_apply_bp_hardening()
>>>>>> was moved from post_ttbr_update_workaround as it doesn't exist and
>>>>>> placed in check_and_switch_context() as it is its final destination.
>>>>>
>>>>> Done that and dropped the other two patches.
>>>>>
>>>>>> However, I really don't know what's the best way to proceed according to
>>>>>> existing practices. So input from someone else would be welcome.
>>>>>
>>>>> Lets see if someone comes up and ask me to do something else :)
>>>>
>>>> Keeping the same patches that upstream has is almost always the better
>>>> thing to do in the long-run.
>>>
>>> That would require two additional patches to be backported, 22 and 23
>>> from this series. From your suggestion it seems that keeping them is
>>> better here ?
>>
>> Yes. Backporting individual patches as they appear upstream is definitely
>> the preferred method for -stable. It makes the relationship to mainline
>> crystal clear, as well as any dependencies between patches that have been
>> backported. Everytime we tweak something unecessarily in a stable backport,
>> it just creates the potential for confusion and additional conflicts in
>> future backports, so it's best to follow the shape of upstream as closely as
>> possible, even if it results in additional patches.
>>
>> So I wouldn't worry about total number of patches. I'd worry more about
>> things like conflicts, deviation from mainline and overall testing coverage.
>
> That is exactly correct, thanks for saying it better than I could :)
>
Thanks, I'll try to keep those guidelines in mind for my future comments
on backports.
Cheers,
--
Julien Thierry
_______________________________________________
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] serial: imx: Avoid probe failure in case of missing gpiolib
From: Uwe Kleine-König @ 2019-08-01 8:48 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, Greg Kroah-Hartman, Sascha Hauer,
linux-kernel@vger.kernel.org, NXP Linux Team,
Pengutronix Kernel Team, Jiri Slaby, Shawn Guo, Fabio Estevam,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190801081524.22577-1-frieder.schrempf@kontron.de>
On Thu, Aug 01, 2019 at 08:18:05AM +0000, Schrempf Frieder wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() will return
> -ENOSYS and cause the probing of the imx UART to fail. As the
> GPIOs are optional, we should continue probing in this case.
Is this really still the case? On which version did you hit this
problem?
I would expect that is gone with
d99482673f950817b30caf3fcdfb31179b050ce1 if not earlier.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 4/6] irqchip/irq-pruss-intc: Add helper functions to configure internal mapping
From: Marc Zyngier @ 2019-08-01 8:45 UTC (permalink / raw)
To: Suman Anna, Thomas Gleixner, Jason Cooper
Cc: devicetree, Grygorii Strashko, David Lechner, Tony Lindgren,
Sekhar Nori, linux-kernel, Andrew F. Davis, Lokesh Vutla,
Rob Herring, Murali Karicheri, linux-omap, linux-arm-kernel,
Roger Quadros
In-Reply-To: <20190731224149.11153-5-s-anna@ti.com>
On 31/07/2019 23:41, Suman Anna wrote:
> The PRUSS INTC receives a number of system input interrupt source events
> and supports individual control configuration and hardware prioritization.
> These input events can be mapped to some output interrupt lines through 2
> levels of many-to-one mapping i.e. events to channel mapping and channels
> to output interrupts.
>
> This mapping information is provided through the PRU firmware that is
> loaded onto a PRU core/s or through the device tree node of the PRU
> application. The mapping is configured by the PRU remoteproc driver, and
> is setup before the PRU core is started and cleaned up after the PRU core
> is stopped. This event mapping configuration logic programs the Channel
> Map Registers (CMRx) and Host-Interrupt Map Registers (HMRx) only when a
> new program is being loaded/started and the same events and interrupt
> channels are reset to zero when stopping a PRU.
>
> Add two helper functions: pruss_intc_configure() & pruss_intc_unconfigure()
> that the PRU remoteproc driver can use to configure the PRUSS INTC.
So let me see if I correctly understand this: this adds yet another
firmware description parser, with a private interface to another
(undisclosed?) driver, bypassing the standard irqchip configuration
mechanism. It sounds great, doesn't it?
What I cannot really infer from this message (-ETOOMUCHJARGON) is what
interrupts this affects:
- Interrupts from random devices to the PRUSS?
- Interrupts from the PRUSS to the host?
- Something else?
When does this happen? Under control of what? It isn't even clear why
this is part of this irqchip driver.
Depending what this does, there may be ways to fit it into the standard
interrupt configuration framework. After all, we already have standard
interfaces to route interrupts to virtual CPUs, effectively passing full
control of an interrupt to another entity. If you squint hard enough,
your PRUSS can fit that description.
If that doesn't work, then we need to make the IRQ framework grok that
kind of requirement (hence my request for clarification). But I'm
strongly opposed to inventing a SoC-private way of configuring
interrupts behind the kernel's back.
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 v4.4 V2 25/43] arm64: Move BP hardening to check_and_switch_context
From: Greg KH @ 2019-08-01 8:43 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Viresh Kumar,
Will Deacon, stable, mark.brown, linux-arm-kernel,
Catalin Marinas, Russell King, julien.thierry.kdev
In-Reply-To: <20190801073444.4n45h6kcbmejvzte@willie-the-truck>
On Thu, Aug 01, 2019 at 08:34:45AM +0100, Will Deacon wrote:
> On Thu, Aug 01, 2019 at 12:35:41PM +0530, Viresh Kumar wrote:
> > On 01-08-19, 08:57, Greg KH wrote:
> > > On Thu, Aug 01, 2019 at 12:05:44PM +0530, Viresh Kumar wrote:
> > > > On 01-08-19, 07:30, Julien Thierry wrote:
> > > > > I must admit I am not familiar with backport/stable process enough. But
> > > > > personally I think the your suggestion seems more sensible than
> > > > > backporting 4 patches.
> > > > >
> > > > > Or you can maybe ignore patch 25 and say in patch 24 that among the
> > > > > changes made for the 4.4 codebase, the call arm64_apply_bp_hardening()
> > > > > was moved from post_ttbr_update_workaround as it doesn't exist and
> > > > > placed in check_and_switch_context() as it is its final destination.
> > > >
> > > > Done that and dropped the other two patches.
> > > >
> > > > > However, I really don't know what's the best way to proceed according to
> > > > > existing practices. So input from someone else would be welcome.
> > > >
> > > > Lets see if someone comes up and ask me to do something else :)
> > >
> > > Keeping the same patches that upstream has is almost always the better
> > > thing to do in the long-run.
> >
> > That would require two additional patches to be backported, 22 and 23
> > from this series. From your suggestion it seems that keeping them is
> > better here ?
>
> Yes. Backporting individual patches as they appear upstream is definitely
> the preferred method for -stable. It makes the relationship to mainline
> crystal clear, as well as any dependencies between patches that have been
> backported. Everytime we tweak something unecessarily in a stable backport,
> it just creates the potential for confusion and additional conflicts in
> future backports, so it's best to follow the shape of upstream as closely as
> possible, even if it results in additional patches.
>
> So I wouldn't worry about total number of patches. I'd worry more about
> things like conflicts, deviation from mainline and overall testing coverage.
That is exactly correct, thanks for saying it better than I could :)
greg k-h
_______________________________________________
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 1/1] dt-bindings: reset: Fix typo in imx8mq resets
From: Lucas Stach @ 2019-08-01 8:41 UTC (permalink / raw)
To: Guido Günther, Philipp Zabel, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Rob Herring, Mark Rutland, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <660b4fb6ab9acec05aa5fde323d878e04e3d1f64.1564647612.git.agx@sigxcpu.org>
Am Donnerstag, den 01.08.2019, 10:20 +0200 schrieb Guido Günther:
> Some of the mipi dsi resets were called
>
> IMX8MQ_RESET_MIPI_DIS__
>
> instead of
>
> IMX8MQ_RESET_MIPI_DSI__
>
> Since they're DSI related this looks like a typo. This fixes the
> only in tree user as well to not break bisecting.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/reset/reset-imx7.c | 12 ++++++------
> include/dt-bindings/reset/imx8mq-reset.h | 6 +++---
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
> index 3ecd770f910b..1443a55a0c29 100644
> --- a/drivers/reset/reset-imx7.c
> +++ b/drivers/reset/reset-imx7.c
> @@ -169,9 +169,9 @@ static const struct imx7_src_signal imx8mq_src_signals[IMX8MQ_RESET_NUM] = {
> > > [IMX8MQ_RESET_OTG2_PHY_RESET] = { SRC_USBOPHY2_RCR, BIT(0) },
> > > [IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N] = { SRC_MIPIPHY_RCR, BIT(1) },
> > > [IMX8MQ_RESET_MIPI_DSI_RESET_N] = { SRC_MIPIPHY_RCR, BIT(2) },
> > > - [IMX8MQ_RESET_MIPI_DIS_DPI_RESET_N] = { SRC_MIPIPHY_RCR, BIT(3) },
> > > - [IMX8MQ_RESET_MIPI_DIS_ESC_RESET_N] = { SRC_MIPIPHY_RCR, BIT(4) },
> > > - [IMX8MQ_RESET_MIPI_DIS_PCLK_RESET_N] = { SRC_MIPIPHY_RCR, BIT(5) },
> > > + [IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N] = { SRC_MIPIPHY_RCR, BIT(3) },
> > > + [IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N] = { SRC_MIPIPHY_RCR, BIT(4) },
> > > + [IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N] = { SRC_MIPIPHY_RCR, BIT(5) },
> > > [IMX8MQ_RESET_PCIEPHY] = { SRC_PCIEPHY_RCR,
> > BIT(2) | BIT(1) },
> > > [IMX8MQ_RESET_PCIEPHY_PERST] = { SRC_PCIEPHY_RCR, BIT(3) },
> @@ -220,9 +220,9 @@ static int imx8mq_reset_set(struct reset_controller_dev *rcdev,
>
> > case IMX8MQ_RESET_PCIE_CTRL_APPS_EN:
> > > case IMX8MQ_RESET_PCIE2_CTRL_APPS_EN: /* fallthrough */
> > > - case IMX8MQ_RESET_MIPI_DIS_PCLK_RESET_N: /* fallthrough */
> > > - case IMX8MQ_RESET_MIPI_DIS_ESC_RESET_N: /* fallthrough */
> > > - case IMX8MQ_RESET_MIPI_DIS_DPI_RESET_N: /* fallthrough */
> > > + case IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N: /* fallthrough */
> > > + case IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N: /* fallthrough */
> > > + case IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N: /* fallthrough */
> > > case IMX8MQ_RESET_MIPI_DSI_RESET_N: /* fallthrough */
> > > case IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N: /* fallthrough */
> > value = assert ? 0 : bit;
> diff --git a/include/dt-bindings/reset/imx8mq-reset.h b/include/dt-bindings/reset/imx8mq-reset.h
> index 57c592498aa0..bfa41b0e24f6 100644
> --- a/include/dt-bindings/reset/imx8mq-reset.h
> +++ b/include/dt-bindings/reset/imx8mq-reset.h
> @@ -31,9 +31,9 @@
> > #define IMX8MQ_RESET_OTG2_PHY_RESET 20
> > #define IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N 21
> > #define IMX8MQ_RESET_MIPI_DSI_RESET_N 22
> > -#define IMX8MQ_RESET_MIPI_DIS_DPI_RESET_N 23
> > -#define IMX8MQ_RESET_MIPI_DIS_ESC_RESET_N 24
> > -#define IMX8MQ_RESET_MIPI_DIS_PCLK_RESET_N 25
> > +#define IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N 23
> > +#define IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N 24
> > +#define IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N 25
> > #define IMX8MQ_RESET_PCIEPHY 26
> > #define IMX8MQ_RESET_PCIEPHY_PERST 27
> > #define IMX8MQ_RESET_PCIE_CTRL_APPS_EN 28
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] arm64: dts: ls1088a-qds: Add the spi-flash nodes under the DSPI controller
From: Chuanhua Han @ 2019-08-01 8:31 UTC (permalink / raw)
To: broonie, robh+dt, mark.rutland, shawnguo, leoyang.li
Cc: devicetree, Chuanhua Han, linux-kernel, linux-arm-kernel,
linux-spi
In-Reply-To: <20190801083105.30102-1-chuanhua.han@nxp.com>
This patch adds the spi-flash nodes under the DSPI controller for
ls1088a-qds boards.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts | 33 +++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts
index 6f48d21..120e62d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dts
@@ -17,6 +17,39 @@
compatible = "fsl,ls1088a-qds", "fsl,ls1088a";
};
+&dspi {
+ bus-num = <0>;
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+
+ flash@1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ spi-max-frequency = <3500000>;
+ reg = <1>;
+ };
+
+ flash@2 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ spi-max-frequency = <3500000>;
+ reg = <2>;
+ };
+};
+
&i2c0 {
status = "okay";
--
2.9.5
_______________________________________________
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 2/3] arm64: dts: ls1088a: Add the DSPI controller node
From: Chuanhua Han @ 2019-08-01 8:31 UTC (permalink / raw)
To: broonie, robh+dt, mark.rutland, shawnguo, leoyang.li
Cc: devicetree, Chuanhua Han, linux-kernel, linux-arm-kernel,
linux-spi
In-Reply-To: <20190801083105.30102-1-chuanhua.han@nxp.com>
This patch adds the DSPI controller node for ls1088a boards.
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index dacd8cf..fe8f1bd 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -252,6 +252,19 @@
#thermal-sensor-cells = <1>;
};
+ dspi: spi@2100000 {
+ compatible = "fsl,ls1088a-dspi",
+ "fsl,ls1021a-v1.0-dspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2100000 0x0 0x10000>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "dspi";
+ clocks = <&clockgen 4 1>;
+ spi-num-chipselects = <6>;
+ status = "disabled";
+ };
+
duart0: serial@21c0500 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0500 0x0 0x100>;
--
2.9.5
_______________________________________________
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 1/3] dt-bindings: fsl: dspi: Add fsl, ls1088a-dspi compatible string
From: Chuanhua Han @ 2019-08-01 8:31 UTC (permalink / raw)
To: broonie, robh+dt, mark.rutland, shawnguo, leoyang.li
Cc: devicetree, Chuanhua Han, linux-kernel, linux-arm-kernel,
linux-spi
new compatible string: "fsl,ls1088a-dspi".
Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
---
Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
index dcc7eaa..162e024 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
@@ -6,6 +6,7 @@ Required properties:
or
"fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
"fsl,ls1012a-dspi" followed by "fsl,ls1021a-v1.0-dspi"
+ "fsl,ls1088a-dspi" followed by "fsl,ls1021a-v1.0-dspi"
- reg : Offset and length of the register set for the device
- interrupts : Should contain SPI controller interrupt
- clocks: from common clock binding: handle to dspi clock.
--
2.9.5
_______________________________________________
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] ARM: at91/dt: pinctrl: add helper define for MULTI_DRIVE + PULL_UP
From: Ludovic Desroches @ 2019-08-01 8:29 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Alexandre Belloni, linux-arm-kernel
In-Reply-To: <20190731222439.15704-1-uwe@kleine-koenig.org>
On Thu, Aug 01, 2019 at 12:24:39AM +0200, Uwe Kleine-König wrote:
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> ---
>
> On Thu, Aug 01, 2019 at 12:14:48AM +0200, Uwe Kleine-König wrote:
> > The define I added in include/dt-bindings/pinctrl/at91.h would be nice
> > to have though to simplify overriding the SoC's default pinctrl. Would
> > it be OK to add this?
>
> something like this ...
>
Nice, easier for the user.
> The name is a bit inconsistent compared to
> AT91_PINCTRL_PULL_UP_DEGLITCH, but on the pro side it is shorter.
> Assuming you like this, what is your naming preference?
I advocate consistency in this case.
Regards
Ludovic
>
> Best regards
> Uwe
>
> include/dt-bindings/pinctrl/at91.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/dt-bindings/pinctrl/at91.h b/include/dt-bindings/pinctrl/at91.h
> index 3831f91fb3ba..b8bb55a935f6 100644
> --- a/include/dt-bindings/pinctrl/at91.h
> +++ b/include/dt-bindings/pinctrl/at91.h
> @@ -21,6 +21,7 @@
> #define AT91_PINCTRL_DEBOUNCE_VAL(x) (x << 17)
>
> #define AT91_PINCTRL_PULL_UP_DEGLITCH (AT91_PINCTRL_PULL_UP | AT91_PINCTRL_DEGLITCH)
> +#define AT91_PINCTRL_MULTI_DRIVE_PU (AT91_PINCTRL_MULTI_DRIVE | AT91_PINCTRL_PULL_UP)
>
> #define AT91_PINCTRL_DRIVE_STRENGTH_DEFAULT (0x0 << 5)
> #define AT91_PINCTRL_DRIVE_STRENGTH_LOW (0x1 << 5)
> --
> 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
* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 8:30 UTC (permalink / raw)
To: Sumit Garg
Cc: dhowells, Daniel Thompson, Rouven Czerwinski, Ard Biesheuvel,
jejb, Jonathan Corbet, Linux Doc Mailing List,
Linux Kernel Mailing List, Jarkko Sakkinen,
tee-dev @ lists . linaro . org, linux-security-module, keyrings,
Mimi Zohar, Casey Schaufler, linux-integrity, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <CAFA6WYPt4q+jaJbaoauXKr2qKgBHvtQ663s4t=W3nuPJPe2xpw@mail.gmail.com>
On Thu, Aug 1, 2019 at 10:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > Anyway, just my .02c. I guess having any new support in the kernel for
> > new trust sources is good and improvement from the current state. I
> > can certainly make my stuff work with your setup as well, what ever
> > people think is the best.
>
> Yes your implementation can very well fit under trusted keys
> abstraction framework without creating a new keytype: "ext-trusted".
The fundamental problem with the 'standardized kernel tee' still
exists - it will never be generic in real life. Getting all this in
the kernel will solve your problem and sell this particular product,
but it is quite unlikely to help that many users. If the security is
truly important to you, would you really trust any of this code to
someone else? In this day and age, I really doubt many do. Everyone
does their own thing, so this is why I really see all that as a
userspace problem.
--
Janne
_______________________________________________
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] at91/dt: ariettag25: style cleanup
From: Ludovic Desroches @ 2019-08-01 8:26 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mark Rutland, devicetree, Alexandre Belloni, Rob Herring,
linux-arm-kernel
In-Reply-To: <20190731220045.3992-1-uwe@kleine-koenig.org>
On Thu, Aug 01, 2019 at 12:00:45AM +0200, Uwe Kleine-König wrote:
> External E-Mail
>
>
> - newline between properties and sub-nodes
> - use tags from included dtsi instead of duplicating the hierarchy
> - status should be the last property
> - drop duplicated alias
>
> There are no differences in the generated .dtb
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> ---
> Hello,
>
> these are the style rules I was teached when modifying imx dts files.
> Do they apply to at91, too?
Hello Uwe,
It's okay for me, we had no guidelines at the beginning, that explain
some inconsistency among our dt files. We tend to follow these rules
excepted the use of labels.
I would like to be sure that Nicolas and Alexandre are on the same
wavelength than me.
Regards
Ludovic
>
> Best regards
> Uwe
>
> arch/arm/boot/dts/at91-ariettag25.dts | 87 +++++++++++++--------------
> 1 file changed, 43 insertions(+), 44 deletions(-)
>
> diff --git a/arch/arm/boot/dts/at91-ariettag25.dts b/arch/arm/boot/dts/at91-ariettag25.dts
> index 7a34c4dc05d2..8f9f5a22cbf6 100644
> --- a/arch/arm/boot/dts/at91-ariettag25.dts
> +++ b/arch/arm/boot/dts/at91-ariettag25.dts
> @@ -6,14 +6,11 @@
> */
> /dts-v1/;
> #include "at91sam9g25.dtsi"
> +
> / {
> model = "Acme Systems Arietta G25";
> compatible = "acme,ariettag25", "atmel,at91sam9x5", "atmel,at91sam9";
>
> - aliases {
> - serial0 = &dbgu;
> - };
> -
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -34,55 +31,16 @@
>
> ahb {
> apb {
> - mmc0: mmc@f0008000 {
> - pinctrl-0 = <
> - &pinctrl_mmc0_slot0_clk_cmd_dat0
> - &pinctrl_mmc0_slot0_dat1_3>;
> - status = "okay";
> -
> - slot@0 {
> - reg = <0>;
> - bus-width = <4>;
> - };
> - };
> -
> - tcb0: timer@f8008000 {
> - timer@0 {
> - compatible = "atmel,tcb-timer";
> - reg = <0>;
> - };
> -
> - timer@1 {
> - compatible = "atmel,tcb-timer";
> - reg = <1>;
> - };
> - };
> -
> - usb2: gadget@f803c000 {
> - status = "okay";
> - };
> -
> - dbgu: serial@fffff200 {
> - status = "okay";
> - };
> -
> rtc@fffffeb0 {
> status = "okay";
> };
> };
>
> - usb0: ohci@600000 {
> - status = "okay";
> - num-ports = <3>;
> - };
> -
> - usb1: ehci@700000 {
> - status = "okay";
> - };
> };
>
> leds {
> compatible = "gpio-leds";
> +
> arietta_led {
> label = "arietta_led";
> gpios = <&pioB 8 GPIO_ACTIVE_HIGH>; /* PB8 */
> @@ -90,3 +48,44 @@
> };
> };
> };
> +
> +&dbgu {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + pinctrl-0 = <
> + &pinctrl_mmc0_slot0_clk_cmd_dat0
> + &pinctrl_mmc0_slot0_dat1_3>;
> + status = "okay";
> +
> + slot@0 {
> + reg = <0>;
> + bus-width = <4>;
> + };
> +};
> +
> +&tcb0 {
> + timer@0 {
> + compatible = "atmel,tcb-timer";
> + reg = <0>;
> + };
> +
> + timer@1 {
> + compatible = "atmel,tcb-timer";
> + reg = <1>;
> + };
> +};
> +
> +&usb0 {
> + num-ports = <3>;
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> +};
> +
> +&usb2 {
> + 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
_______________________________________________
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 2/2] reset: imx7: Fix IMX8MQ_RESET_MIPI_DSI_ defines
From: Guido Günther @ 2019-08-01 8:22 UTC (permalink / raw)
To: Lucas Stach
Cc: Mark Rutland, devicetree, Philipp Zabel, Shawn Guo, Sascha Hauer,
linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <1564591585.7267.22.camel@pengutronix.de>
Hi Lucas,
On Wed, Jul 31, 2019 at 06:46:25PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 31.07.2019, 18:43 +0200 schrieb Guido Günther:
> > Some of the mipi dsi resets were called
> >
> > IMX8MQ_RESET_MIPI_DIS_
> >
> > instead of
> >
> > IMX8MQ_RESET_MIPI_DSI_
> >
> > Since they're DSI related this looks like a typo.
> >
> > I wasn't sure if this should be a single patch since it otherwise breaks
> > bisectability. I couldn't find any device trees using this yet.
>
> Yes, I think this should be squashed into a single commit. Other than
> that, the change looks correct.
Thanks for having a look. Sent out v2 as a single patch.
Cheers,
-- Guido
>
> Regards,
> Lucas
>
> > Signed-off-by: Guido Günther <agx@sigxcpu.org>
> > ---
> > drivers/reset/reset-imx7.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
> > index 3ecd770f910b..1443a55a0c29 100644
> > --- a/drivers/reset/reset-imx7.c
> > +++ b/drivers/reset/reset-imx7.c
> > @@ -169,9 +169,9 @@ static const struct imx7_src_signal imx8mq_src_signals[IMX8MQ_RESET_NUM] = {
> > > > [IMX8MQ_RESET_OTG2_PHY_RESET] = { SRC_USBOPHY2_RCR, BIT(0) },
> > > > [IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N] = { SRC_MIPIPHY_RCR, BIT(1) },
> > > > [IMX8MQ_RESET_MIPI_DSI_RESET_N] = { SRC_MIPIPHY_RCR, BIT(2) },
> > > > - [IMX8MQ_RESET_MIPI_DIS_DPI_RESET_N] = { SRC_MIPIPHY_RCR, BIT(3) },
> > > > - [IMX8MQ_RESET_MIPI_DIS_ESC_RESET_N] = { SRC_MIPIPHY_RCR, BIT(4) },
> > > > - [IMX8MQ_RESET_MIPI_DIS_PCLK_RESET_N] = { SRC_MIPIPHY_RCR, BIT(5) },
> > > > + [IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N] = { SRC_MIPIPHY_RCR, BIT(3) },
> > > > + [IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N] = { SRC_MIPIPHY_RCR, BIT(4) },
> > > > + [IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N] = { SRC_MIPIPHY_RCR, BIT(5) },
> > > > [IMX8MQ_RESET_PCIEPHY] = { SRC_PCIEPHY_RCR,
> > > BIT(2) | BIT(1) },
> > > > [IMX8MQ_RESET_PCIEPHY_PERST] = { SRC_PCIEPHY_RCR, BIT(3) },
> > @@ -220,9 +220,9 @@ static int imx8mq_reset_set(struct reset_controller_dev *rcdev,
> >
> > > case IMX8MQ_RESET_PCIE_CTRL_APPS_EN:
> > > > case IMX8MQ_RESET_PCIE2_CTRL_APPS_EN: /* fallthrough */
> > > > - case IMX8MQ_RESET_MIPI_DIS_PCLK_RESET_N: /* fallthrough */
> > > > - case IMX8MQ_RESET_MIPI_DIS_ESC_RESET_N: /* fallthrough */
> > > > - case IMX8MQ_RESET_MIPI_DIS_DPI_RESET_N: /* fallthrough */
> > > > + case IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N: /* fallthrough */
> > > > + case IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N: /* fallthrough */
> > > > + case IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N: /* fallthrough */
> > > > case IMX8MQ_RESET_MIPI_DSI_RESET_N: /* fallthrough */
> > > > case IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N: /* fallthrough */
> > > value = assert ? 0 : bit;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH ARM32 v4.4 V2 47/47] ARM: fix the cockup in the previous patch
From: Viresh Kumar @ 2019-08-01 8:16 UTC (permalink / raw)
To: stable
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Viresh Kumar,
guohanjun, Will Deacon, mark.brown, Catalin Marinas, Russell King,
linux-arm-kernel
In-Reply-To: <cover.1564646727.git.viresh.kumar@linaro.org>
From: Russell King <rmk+kernel@armlinux.org.uk>
Commit d6951f582cc50ba0ad22ef46b599740966599b14 upstream.
The intention in the previous patch was to only place the processor
tables in the .rodata section if big.Little was being built and we
wanted the branch target hardening, but instead (due to the way it
was tested) it ended up always placing the tables into the .rodata
section.
Although harmless, let's correct this anyway.
Fixes: 3a4d0c2172bc ("ARM: ensure that processor vtables is not lost after boot")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/mm/proc-macros.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index d36a283b4099..e6bfdcc381f8 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -263,7 +263,7 @@
* If we are building for big.Little with branch predictor hardening,
* we need the processor function tables to remain available after boot.
*/
-#if 1 // defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
+#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
.section ".rodata"
#endif
.type \name\()_processor_functions, #object
@@ -301,7 +301,7 @@ ENTRY(\name\()_processor_functions)
.endif
.size \name\()_processor_functions, . - \name\()_processor_functions
-#if 1 // defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
+#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
.previous
#endif
.endm
--
2.21.0.rc0.269.g1a574e7a288b
_______________________________________________
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 ARM32 v4.4 V2 45/47] ARM: spectre-v2: per-CPU vtables to work around big.Little systems
From: Viresh Kumar @ 2019-08-01 8:16 UTC (permalink / raw)
To: stable
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Viresh Kumar,
guohanjun, Will Deacon, mark.brown, Catalin Marinas, Russell King,
linux-arm-kernel
In-Reply-To: <cover.1564646727.git.viresh.kumar@linaro.org>
From: Russell King <rmk+kernel@armlinux.org.uk>
Commit 383fb3ee8024d596f488d2dbaf45e572897acbdb upstream.
In big.Little systems, some CPUs require the Spectre workarounds in
paths such as the context switch, but other CPUs do not. In order
to handle these differences, we need per-CPU vtables.
We are unable to use the kernel's per-CPU variables to support this
as per-CPU is not initialised at times when we need access to the
vtables, so we have to use an array indexed by logical CPU number.
We use an array-of-pointers to avoid having function pointers in
the kernel's read/write .data section.
Note: Added include of linux/slab.h in arch/arm/smp.c.
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/include/asm/proc-fns.h | 23 +++++++++++++++++++++++
arch/arm/kernel/setup.c | 5 +++++
arch/arm/kernel/smp.c | 32 ++++++++++++++++++++++++++++++++
arch/arm/mm/proc-v7-bugs.c | 17 ++---------------
4 files changed, 62 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
index a1a71b068edc..1bfcc3bcfc6d 100644
--- a/arch/arm/include/asm/proc-fns.h
+++ b/arch/arm/include/asm/proc-fns.h
@@ -104,12 +104,35 @@ extern void cpu_do_resume(void *);
#else
extern struct processor processor;
+#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
+#include <linux/smp.h>
+/*
+ * This can't be a per-cpu variable because we need to access it before
+ * per-cpu has been initialised. We have a couple of functions that are
+ * called in a pre-emptible context, and so can't use smp_processor_id()
+ * there, hence PROC_TABLE(). We insist in init_proc_vtable() that the
+ * function pointers for these are identical across all CPUs.
+ */
+extern struct processor *cpu_vtable[];
+#define PROC_VTABLE(f) cpu_vtable[smp_processor_id()]->f
+#define PROC_TABLE(f) cpu_vtable[0]->f
+static inline void init_proc_vtable(const struct processor *p)
+{
+ unsigned int cpu = smp_processor_id();
+ *cpu_vtable[cpu] = *p;
+ WARN_ON_ONCE(cpu_vtable[cpu]->dcache_clean_area !=
+ cpu_vtable[0]->dcache_clean_area);
+ WARN_ON_ONCE(cpu_vtable[cpu]->set_pte_ext !=
+ cpu_vtable[0]->set_pte_ext);
+}
+#else
#define PROC_VTABLE(f) processor.f
#define PROC_TABLE(f) processor.f
static inline void init_proc_vtable(const struct processor *p)
{
processor = *p;
}
+#endif
#define cpu_proc_init PROC_VTABLE(_proc_init)
#define cpu_check_bugs PROC_VTABLE(check_bugs)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 8081f88bf636..f2833d7c5378 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -113,6 +113,11 @@ EXPORT_SYMBOL(elf_hwcap2);
#ifdef MULTI_CPU
struct processor processor __ro_after_init;
+#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
+struct processor *cpu_vtable[NR_CPUS] = {
+ [0] = &processor,
+};
+#endif
#endif
#ifdef MULTI_TLB
struct cpu_tlb_fns cpu_tlb __ro_after_init;
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index c92abf791aed..03c11e021962 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -27,6 +27,7 @@
#include <linux/completion.h>
#include <linux/cpufreq.h>
#include <linux/irq_work.h>
+#include <linux/slab.h>
#include <linux/atomic.h>
#include <asm/bugs.h>
@@ -40,6 +41,7 @@
#include <asm/mmu_context.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
+#include <asm/procinfo.h>
#include <asm/processor.h>
#include <asm/sections.h>
#include <asm/tlbflush.h>
@@ -96,6 +98,30 @@ static unsigned long get_arch_pgd(pgd_t *pgd)
#endif
}
+#if defined(CONFIG_BIG_LITTLE) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
+static int secondary_biglittle_prepare(unsigned int cpu)
+{
+ if (!cpu_vtable[cpu])
+ cpu_vtable[cpu] = kzalloc(sizeof(*cpu_vtable[cpu]), GFP_KERNEL);
+
+ return cpu_vtable[cpu] ? 0 : -ENOMEM;
+}
+
+static void secondary_biglittle_init(void)
+{
+ init_proc_vtable(lookup_processor(read_cpuid_id())->proc);
+}
+#else
+static int secondary_biglittle_prepare(unsigned int cpu)
+{
+ return 0;
+}
+
+static void secondary_biglittle_init(void)
+{
+}
+#endif
+
int __cpu_up(unsigned int cpu, struct task_struct *idle)
{
int ret;
@@ -103,6 +129,10 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
if (!smp_ops.smp_boot_secondary)
return -ENOSYS;
+ ret = secondary_biglittle_prepare(cpu);
+ if (ret)
+ return ret;
+
/*
* We need to tell the secondary core where to find
* its stack and the page tables.
@@ -354,6 +384,8 @@ asmlinkage void secondary_start_kernel(void)
struct mm_struct *mm = &init_mm;
unsigned int cpu;
+ secondary_biglittle_init();
+
/*
* The identity mapping is uncached (strongly ordered), so
* switch away from it before attempting any exclusive accesses.
diff --git a/arch/arm/mm/proc-v7-bugs.c b/arch/arm/mm/proc-v7-bugs.c
index 5544b82a2e7a..9a07916af8dd 100644
--- a/arch/arm/mm/proc-v7-bugs.c
+++ b/arch/arm/mm/proc-v7-bugs.c
@@ -52,8 +52,6 @@ static void cpu_v7_spectre_init(void)
case ARM_CPU_PART_CORTEX_A17:
case ARM_CPU_PART_CORTEX_A73:
case ARM_CPU_PART_CORTEX_A75:
- if (processor.switch_mm != cpu_v7_bpiall_switch_mm)
- goto bl_error;
per_cpu(harden_branch_predictor_fn, cpu) =
harden_branch_predictor_bpiall;
spectre_v2_method = "BPIALL";
@@ -61,8 +59,6 @@ static void cpu_v7_spectre_init(void)
case ARM_CPU_PART_CORTEX_A15:
case ARM_CPU_PART_BRAHMA_B15:
- if (processor.switch_mm != cpu_v7_iciallu_switch_mm)
- goto bl_error;
per_cpu(harden_branch_predictor_fn, cpu) =
harden_branch_predictor_iciallu;
spectre_v2_method = "ICIALLU";
@@ -88,11 +84,9 @@ static void cpu_v7_spectre_init(void)
ARM_SMCCC_ARCH_WORKAROUND_1, &res);
if ((int)res.a0 != 0)
break;
- if (processor.switch_mm != cpu_v7_hvc_switch_mm && cpu)
- goto bl_error;
per_cpu(harden_branch_predictor_fn, cpu) =
call_hvc_arch_workaround_1;
- processor.switch_mm = cpu_v7_hvc_switch_mm;
+ cpu_do_switch_mm = cpu_v7_hvc_switch_mm;
spectre_v2_method = "hypervisor";
break;
@@ -101,11 +95,9 @@ static void cpu_v7_spectre_init(void)
ARM_SMCCC_ARCH_WORKAROUND_1, &res);
if ((int)res.a0 != 0)
break;
- if (processor.switch_mm != cpu_v7_smc_switch_mm && cpu)
- goto bl_error;
per_cpu(harden_branch_predictor_fn, cpu) =
call_smc_arch_workaround_1;
- processor.switch_mm = cpu_v7_smc_switch_mm;
+ cpu_do_switch_mm = cpu_v7_smc_switch_mm;
spectre_v2_method = "firmware";
break;
@@ -119,11 +111,6 @@ static void cpu_v7_spectre_init(void)
if (spectre_v2_method)
pr_info("CPU%u: Spectre v2: using %s workaround\n",
smp_processor_id(), spectre_v2_method);
- return;
-
-bl_error:
- pr_err("CPU%u: Spectre v2: incorrect context switching function, system vulnerable\n",
- cpu);
}
#else
static void cpu_v7_spectre_init(void)
--
2.21.0.rc0.269.g1a574e7a288b
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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