* [PATCH v6 01/13] arm64: add comments about EC exception levels
From: Kristina Martsenko @ 2018-12-07 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Andrew Jones, Jacob Bramley, Ard Biesheuvel,
Marc Zyngier, Catalin Marinas, Adam Wallis, Suzuki K Poulose,
Richard Henderson, Christoffer Dall, Will Deacon, kvmarm,
Cyrill Gorcunov, Ramana Radhakrishnan, Amit Kachhap,
Dave P Martin, linux-kernel, Kees Cook
In-Reply-To: <20181207183931.4285-1-kristina.martsenko@arm.com>
To make it clear which exceptions can't be taken to EL1 or EL2, add
comments next to the ESR_ELx_EC_* macro definitions.
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
---
arch/arm64/include/asm/esr.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 676de2ec1762..23602a0083ad 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -29,23 +29,23 @@
#define ESR_ELx_EC_CP14_MR (0x05)
#define ESR_ELx_EC_CP14_LS (0x06)
#define ESR_ELx_EC_FP_ASIMD (0x07)
-#define ESR_ELx_EC_CP10_ID (0x08)
+#define ESR_ELx_EC_CP10_ID (0x08) /* EL2 only */
/* Unallocated EC: 0x09 - 0x0B */
#define ESR_ELx_EC_CP14_64 (0x0C)
/* Unallocated EC: 0x0d */
#define ESR_ELx_EC_ILL (0x0E)
/* Unallocated EC: 0x0F - 0x10 */
#define ESR_ELx_EC_SVC32 (0x11)
-#define ESR_ELx_EC_HVC32 (0x12)
-#define ESR_ELx_EC_SMC32 (0x13)
+#define ESR_ELx_EC_HVC32 (0x12) /* EL2 only */
+#define ESR_ELx_EC_SMC32 (0x13) /* EL2 and above */
/* Unallocated EC: 0x14 */
#define ESR_ELx_EC_SVC64 (0x15)
-#define ESR_ELx_EC_HVC64 (0x16)
-#define ESR_ELx_EC_SMC64 (0x17)
+#define ESR_ELx_EC_HVC64 (0x16) /* EL2 and above */
+#define ESR_ELx_EC_SMC64 (0x17) /* EL2 and above */
#define ESR_ELx_EC_SYS64 (0x18)
#define ESR_ELx_EC_SVE (0x19)
/* Unallocated EC: 0x1A - 0x1E */
-#define ESR_ELx_EC_IMP_DEF (0x1f)
+#define ESR_ELx_EC_IMP_DEF (0x1f) /* EL3 only */
#define ESR_ELx_EC_IABT_LOW (0x20)
#define ESR_ELx_EC_IABT_CUR (0x21)
#define ESR_ELx_EC_PC_ALIGN (0x22)
@@ -68,7 +68,7 @@
/* Unallocated EC: 0x36 - 0x37 */
#define ESR_ELx_EC_BKPT32 (0x38)
/* Unallocated EC: 0x39 */
-#define ESR_ELx_EC_VECTOR32 (0x3A)
+#define ESR_ELx_EC_VECTOR32 (0x3A) /* EL2 only */
/* Unallocted EC: 0x3B */
#define ESR_ELx_EC_BRK64 (0x3C)
/* Unallocated EC: 0x3D - 0x3F */
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 2/4] drivers/irqchip: Add Actions external interrupts support
From: Marc Zyngier @ 2018-12-07 18:39 UTC (permalink / raw)
To: Parthiban Nallathambi, tglx, jason, robh+dt, mark.rutland,
afaerber, catalin.marinas, will.deacon, manivannan.sadhasivam
Cc: devicetree, linux, Saravanan Sekar, guilherme.simoes, laisa.costa,
mkzuffo, linux-kernel, thomas.liau, mp-cs, edgar.righi,
linux-arm-kernel
In-Reply-To: <20181126100356.2840578-3-pn@denx.de>
On 26/11/2018 10:03, Parthiban Nallathambi wrote:
> Actions Semi Owl family SoC's S500, S700 and S900 provides support
> for 3 external interrupt controllers through SIRQ pins.
>
> Each line can be independently configured as interrupt and triggers
> on either of the edges (raising or falling) or either of the levels
> (high or low) . Each line can also be masked independently.
>
> Signed-off-by: Parthiban Nallathambi <pn@denx.de>
> Signed-off-by: Saravanan Sekar <sravanhome@gmail.com>
> ---
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-owl-sirq.c | 301 +++++++++++++++++++++++++++++++++
> 2 files changed, 302 insertions(+)
> create mode 100644 drivers/irqchip/irq-owl-sirq.c
>
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 794c13d3ac3d..d8015fc5c1a2 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_ATH79) += irq-ath79-misc.o
> obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
> obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2836.o
> obj-$(CONFIG_ARCH_EXYNOS) += exynos-combiner.o
> +obj-$(CONFIG_ARCH_ACTIONS) += irq-owl-sirq.o
> obj-$(CONFIG_FARADAY_FTINTC010) += irq-ftintc010.o
> obj-$(CONFIG_ARCH_HIP04) += irq-hip04.o
> obj-$(CONFIG_ARCH_LPC32XX) += irq-lpc32xx.o
> diff --git a/drivers/irqchip/irq-owl-sirq.c b/drivers/irqchip/irq-owl-sirq.c
> new file mode 100644
> index 000000000000..cc59e5743cda
> --- /dev/null
> +++ b/drivers/irqchip/irq-owl-sirq.c
> @@ -0,0 +1,301 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Actions Semi Owl SoCs SIRQ interrupt controller driver
> + *
> + * Copyright (C) 2014 Actions Semi Inc.
> + * David Liu <liuwei@actions-semi.com>
> + *
> + * Author: Parthiban Nallathambi <pn@denx.de>
> + * Author: Saravanan Sekar <sravanhome@gmail.com>
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/irqchip.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
> +
> +#define INTC_EXTCTL_PENDING BIT(0)
> +#define INTC_EXTCTL_CLK_SEL BIT(4)
> +#define INTC_EXTCTL_EN BIT(5)
> +#define INTC_EXTCTL_TYPE_MASK GENMASK(6, 7)
#define GENMASK(h, l) [...]
I sense a problem here.
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] arm: dts: qcom: msm8998: Fixup clock to use xo_board
From: Bjorn Andersson @ 2018-12-07 18:34 UTC (permalink / raw)
To: Andy Gross; +Cc: Stephen Boyd, linux-arm-msm, linux-arm-kernel
In-Reply-To: <1544207605-23901-1-git-send-email-andy.gross@linaro.org>
On Fri 07 Dec 10:33 PST 2018, Andy Gross wrote:
> This patch sets the msm8998 xo clock name back to xo_board. Recent
> clock tree changes fixed the clock tree and the change to the xo name
> is causing issues. Let's change it back and leave the xo label on it.
>
> Fixes: 634da3307b08 (arm64: dts: qcom: msm8998: correct xo clock name)
> Signed-off-by: Andy Gross <andy.gross@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> index 49f0fee..c2423c9 100644
> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> @@ -54,7 +54,7 @@
> };
>
> clocks {
> - xo: xo {
> + xo: xo_board {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <19200000>;
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] meson: Fix IRQ trigger type
From: Emiliano Ingrassia @ 2018-12-07 18:33 UTC (permalink / raw)
To: Carlo Caione, Martin Blumenstingl
Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <463139583299c0099c812ad12017fe6d32662db4.camel@baylibre.com>
On Fri, Dec 07, 2018 at 11:03:20AM +0000, Carlo Caione wrote:
> On Fri, 2018-12-07 at 11:49 +0100, Jerome Brunet wrote:
> > On Thu, 2018-12-06 at 19:51 +0100, Emiliano Ingrassia wrote:
> > > Hi Carlo,
> > >
> > > I keep running tests with packet generator,
> > > using nload to show bandwidth usage.
> > >
> > > Here is my test results with packet generators
> > > both running on laptop and board with rate 1 Gbps.
> >
> > Testing in UDP is unlikely to give us clear picture of anything for
> > this sort
> > of fixes.
> >
> > All your test seems in show it the fact the Amlogic SoC usually
> > prioritize the
> > TX traffic over RX, which is something we've known about for a while.
> >
> > It would be helpful if you could provide TCP figures with a traffic
> > generator
> > we can all share an inspect, such as iperf3
>
> For reference you can use something like:
>
> iperf3 -c ${IP} -i ${IPERF_LOGPERIOD} -w 400k -p ${PORT} -t ${DURATION}
>
Thanks Carlo. Just to be consistent, what value did you use for DURATION?
> Cheers,
>
> --
> Carlo Caione
>
Regards,
Emiliano
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] ASoC: xlnx: Add i2s driver
From: Maruthi Srinivas Bayyavarapu @ 2018-12-07 18:32 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Rob Herring, Mark Rutland, Vishal Sagar, Michal Simek,
Maruthi Srinivas Bayyavarapu, devicetree, linux-kernel,
alsa-devel, linux-arm-kernel
In-Reply-To: <1544207558-72508-1-git-send-email-maruthi.srinivas.bayyavarapu@xilinx.com>
I2S IP instance can work in transmitter/playback or receiver/capture mode
exclusively. The patch registers corresponding instance as ASoC component
with audio framework.
Signed-off-by: Maruthi Srinivas Bayyavarapu <maruthi.srinivas.bayyavarapu@xilinx.com>
---
sound/soc/xilinx/xlnx_i2s.c | 185 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 185 insertions(+)
create mode 100644 sound/soc/xilinx/xlnx_i2s.c
diff --git a/sound/soc/xilinx/xlnx_i2s.c b/sound/soc/xilinx/xlnx_i2s.c
new file mode 100644
index 0000000..d4ae9ef
--- /dev/null
+++ b/sound/soc/xilinx/xlnx_i2s.c
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx ASoC I2S audio support
+ *
+ * Copyright (C) 2018 Xilinx, Inc.
+ *
+ * Author: Praveen Vuppala <praveenv@xilinx.com>
+ * Author: Maruthi Srinivas Bayyavarapu <maruthis@xilinx.com>
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#define DRV_NAME "xlnx_i2s"
+
+#define I2S_CORE_CTRL_OFFSET 0x08
+#define I2S_I2STIM_OFFSET 0x20
+#define I2S_CH0_OFFSET 0x30
+#define I2S_I2STIM_VALID_MASK GENMASK(7, 0)
+
+static int xlnx_i2s_set_sclkout_div(struct snd_soc_dai *cpu_dai,
+ int div_id, int div)
+{
+ void __iomem *base = snd_soc_dai_get_drvdata(cpu_dai);
+
+ if (!div || (div & ~I2S_I2STIM_VALID_MASK))
+ return -EINVAL;
+
+ writel(div, base + I2S_I2STIM_OFFSET);
+
+ return 0;
+}
+
+static int xlnx_i2s_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *i2s_dai)
+{
+ u32 reg_off, chan_id;
+ void __iomem *base = snd_soc_dai_get_drvdata(i2s_dai);
+
+ chan_id = params_channels(params) / 2;
+
+ while (chan_id > 0) {
+ reg_off = I2S_CH0_OFFSET + ((chan_id - 1) * 4);
+ writel(chan_id, base + reg_off);
+ chan_id--;
+ }
+
+ return 0;
+}
+
+static int xlnx_i2s_trigger(struct snd_pcm_substream *substream, int cmd,
+ struct snd_soc_dai *i2s_dai)
+{
+ void __iomem *base = snd_soc_dai_get_drvdata(i2s_dai);
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ writel(1, base + I2S_CORE_CTRL_OFFSET);
+ break;
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ writel(0, base + I2S_CORE_CTRL_OFFSET);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static const struct snd_soc_dai_ops xlnx_i2s_dai_ops = {
+ .trigger = xlnx_i2s_trigger,
+ .set_clkdiv = xlnx_i2s_set_sclkout_div,
+ .hw_params = xlnx_i2s_hw_params
+};
+
+static const struct snd_soc_component_driver xlnx_i2s_component = {
+ .name = DRV_NAME,
+};
+
+static const struct of_device_id xlnx_i2s_of_match[] = {
+ { .compatible = "xlnx,i2s-transmitter-1.0", },
+ { .compatible = "xlnx,i2s-receiver-1.0", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, xlnx_i2s_of_match);
+
+static int xlnx_i2s_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ void __iomem *base;
+ struct snd_soc_dai_driver *dai_drv;
+ int ret;
+ u32 ch, format, data_width;
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+
+ dai_drv = devm_kzalloc(&pdev->dev, sizeof(*dai_drv), GFP_KERNEL);
+ if (!dai_drv)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ ret = of_property_read_u32(node, "xlnx,num-channels", &ch);
+ if (ret < 0) {
+ dev_err(dev, "cannot get supported channels\n");
+ return ret;
+ }
+ ch = ch * 2;
+
+ ret = of_property_read_u32(node, "xlnx,dwidth", &data_width);
+ if (ret < 0) {
+ dev_err(dev, "cannot get data width\n");
+ return ret;
+ }
+ switch (data_width) {
+ case 16:
+ format = SNDRV_PCM_FMTBIT_S16_LE;
+ break;
+ case 24:
+ format = SNDRV_PCM_FMTBIT_S24_LE;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (of_device_is_compatible(node, "xlnx,i2s-transmitter-1.0")) {
+ dai_drv->name = "xlnx_i2s_playback";
+ dai_drv->playback.stream_name = "Playback";
+ dai_drv->playback.formats = format;
+ dai_drv->playback.channels_min = ch;
+ dai_drv->playback.channels_max = ch;
+ dai_drv->playback.rates = SNDRV_PCM_RATE_8000_192000;
+ dai_drv->ops = &xlnx_i2s_dai_ops;
+ } else if (of_device_is_compatible(node, "xlnx,i2s-receiver-1.0")) {
+ dai_drv->name = "xlnx_i2s_capture";
+ dai_drv->capture.stream_name = "Capture";
+ dai_drv->capture.formats = format;
+ dai_drv->capture.channels_min = ch;
+ dai_drv->capture.channels_max = ch;
+ dai_drv->capture.rates = SNDRV_PCM_RATE_8000_192000;
+ dai_drv->ops = &xlnx_i2s_dai_ops;
+ } else {
+ return -ENODEV;
+ }
+
+ dev_set_drvdata(&pdev->dev, base);
+
+ ret = devm_snd_soc_register_component(&pdev->dev, &xlnx_i2s_component,
+ dai_drv, 1);
+ if (ret) {
+ dev_err(&pdev->dev, "i2s component registration failed\n");
+ return ret;
+ }
+
+ dev_info(&pdev->dev, "%s DAI registered\n", dai_drv->name);
+
+ return ret;
+}
+
+static struct platform_driver xlnx_i2s_aud_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ .of_match_table = xlnx_i2s_of_match,
+ },
+ .probe = xlnx_i2s_probe,
+};
+
+module_platform_driver(xlnx_i2s_aud_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Praveen Vuppala <praveenv@xilinx.com>");
+MODULE_AUTHOR("Maruthi Srinivas Bayyavarapu <maruthis@xilinx.com>");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] ASoC: xlnx: enable i2s driver build
From: Maruthi Srinivas Bayyavarapu @ 2018-12-07 18:32 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Rob Herring, Mark Rutland, Vishal Sagar, Michal Simek,
Maruthi Srinivas Bayyavarapu, devicetree, linux-kernel,
alsa-devel, linux-arm-kernel
In-Reply-To: <1544207558-72508-1-git-send-email-maruthi.srinivas.bayyavarapu@xilinx.com>
Enabled i2s driver build option.
Signed-off-by: Maruthi Srinivas Bayyavarapu <maruthi.srinivas.bayyavarapu@xilinx.com>
---
sound/soc/Kconfig | 1 +
sound/soc/Makefile | 1 +
sound/soc/xilinx/Kconfig | 8 ++++++++
sound/soc/xilinx/Makefile | 2 ++
4 files changed, 12 insertions(+)
create mode 100644 sound/soc/xilinx/Kconfig
create mode 100644 sound/soc/xilinx/Makefile
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 1cf11cf..d21659f 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -73,6 +73,7 @@ source "sound/soc/tegra/Kconfig"
source "sound/soc/txx9/Kconfig"
source "sound/soc/uniphier/Kconfig"
source "sound/soc/ux500/Kconfig"
+source "sound/soc/xilinx/Kconfig"
source "sound/soc/xtensa/Kconfig"
source "sound/soc/zte/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index 62a5f87..aff7b19 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -57,5 +57,6 @@ obj-$(CONFIG_SND_SOC) += tegra/
obj-$(CONFIG_SND_SOC) += txx9/
obj-$(CONFIG_SND_SOC) += uniphier/
obj-$(CONFIG_SND_SOC) += ux500/
+obj-$(CONFIG_SND_SOC) += xilinx/
obj-$(CONFIG_SND_SOC) += xtensa/
obj-$(CONFIG_SND_SOC) += zte/
diff --git a/sound/soc/xilinx/Kconfig b/sound/soc/xilinx/Kconfig
new file mode 100644
index 0000000..25e287f
--- /dev/null
+++ b/sound/soc/xilinx/Kconfig
@@ -0,0 +1,8 @@
+config SND_SOC_XILINX_I2S
+ tristate "Audio support for the the Xilinx I2S"
+ help
+ Select this option to enable Xilinx I2S Audio. This enables
+ I2S playback and capture using xilinx soft IP. In transmitter
+ mode, IP receives audio in AES format, extracts PCM and sends
+ PCM data. In receiver mode, IP receives PCM audio and
+ encapsulates PCM in AES format and sends AES data.
diff --git a/sound/soc/xilinx/Makefile b/sound/soc/xilinx/Makefile
new file mode 100644
index 0000000..6c1209b
--- /dev/null
+++ b/sound/soc/xilinx/Makefile
@@ -0,0 +1,2 @@
+snd-soc-xlnx-i2s-objs := xlnx_i2s.o
+obj-$(CONFIG_SND_SOC_XILINX_I2S) += snd-soc-xlnx-i2s.o
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: ASoC: xlnx,i2s: Document i2s bindings
From: Maruthi Srinivas Bayyavarapu @ 2018-12-07 18:32 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Rob Herring, Mark Rutland, Vishal Sagar, Michal Simek,
Maruthi Srinivas Bayyavarapu, devicetree, linux-kernel,
alsa-devel, linux-arm-kernel
In-Reply-To: <1544207558-72508-1-git-send-email-maruthi.srinivas.bayyavarapu@xilinx.com>
Added documentation for I2S IP core DT bindings.
Signed-off-by: Maruthi Srinivas Bayyavarapu <maruthi.srinivas.bayyavarapu@xilinx.com>
---
.../devicetree/bindings/sound/xlnx,i2s.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/xlnx,i2s.txt
diff --git a/Documentation/devicetree/bindings/sound/xlnx,i2s.txt b/Documentation/devicetree/bindings/sound/xlnx,i2s.txt
new file mode 100644
index 0000000..5e7c7d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/xlnx,i2s.txt
@@ -0,0 +1,28 @@
+Device-Tree bindings for Xilinx I2S PL block
+
+The IP supports I2S based playback/capture audio
+
+Required property:
+ - compatible: "xlnx,i2s-transmitter-1.0" for playback and
+ "xlnx,i2s-receiver-1.0" for capture
+
+Required property common to both I2S playback and capture:
+ - reg: Base address and size of the IP core instance.
+ - xlnx,dwidth: sample data width. Can be any of 16, 24.
+ - xlnx,num-channels: Number of I2S streams. Can be any of 1, 2, 3, 4.
+ supported channels = 2 * xlnx,num-channels
+
+Example:
+
+ i2s_receiver@a0080000 {
+ compatible = "xlnx,i2s-receiver-1.0";
+ reg = <0x0 0xa0080000 0x0 0x10000>;
+ xlnx,dwidth = <0x18>;
+ xlnx,num-channels = <1>;
+ };
+ i2s_transmitter@a0090000 {
+ compatible = "xlnx,i2s-transmitter-1.0";
+ reg = <0x0 0xa0090000 0x0 0x10000>;
+ xlnx,dwidth = <0x18>;
+ xlnx,num-channels = <1>;
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] Add Xilinx I2S driver
From: Maruthi Srinivas Bayyavarapu @ 2018-12-07 18:32 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Rob Herring, Mark Rutland, Vishal Sagar, Michal Simek,
Maruthi Srinivas Bayyavarapu, devicetree, linux-kernel,
alsa-devel, linux-arm-kernel
Xilinx I2S IP enables I2S audio. Each IP can either work in playback
or capture mode exclusively. The driver supports both by reading the
configuration in device tree.
Patchset includes devicetree bindings documentation, driver and build
enablement.
Maruthi Srinivas Bayyavarapu (3):
dt-bindings: ASoC: xlnx,i2s: Document i2s bindings
ASoC: xlnx: Add i2s driver
ASoC: xlnx: enable i2s driver build
.../devicetree/bindings/sound/xlnx,i2s.txt | 28 ++++
sound/soc/Kconfig | 1 +
sound/soc/Makefile | 1 +
sound/soc/xilinx/Kconfig | 8 +
sound/soc/xilinx/Makefile | 2 +
sound/soc/xilinx/xlnx_i2s.c | 185 +++++++++++++++++++++
6 files changed, 225 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/xlnx,i2s.txt
create mode 100644 sound/soc/xilinx/Kconfig
create mode 100644 sound/soc/xilinx/Makefile
create mode 100644 sound/soc/xilinx/xlnx_i2s.c
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm: dts: qcom: msm8998: Fixup clock to use xo_board
From: Andy Gross @ 2018-12-07 18:33 UTC (permalink / raw)
To: linux-arm-msm; +Cc: Stephen Boyd, Andy Gross, linux-arm-kernel, Bjorn Andersson
This patch sets the msm8998 xo clock name back to xo_board. Recent
clock tree changes fixed the clock tree and the change to the xo name
is causing issues. Let's change it back and leave the xo label on it.
Fixes: 634da3307b08 (arm64: dts: qcom: msm8998: correct xo clock name)
Signed-off-by: Andy Gross <andy.gross@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 49f0fee..c2423c9 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -54,7 +54,7 @@
};
clocks {
- xo: xo {
+ xo: xo_board {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <19200000>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V3] arm64: Don't flush tlb while clearing the accessed bit
From: Will Deacon @ 2018-12-07 17:53 UTC (permalink / raw)
To: Alexander Van Brunt
Cc: mark.rutland@arm.com, linux-kernel@vger.kernel.org, Sachin Nikam,
linux-tegra@vger.kernel.org, Ashish Mhetre,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <BYAPR12MB27120C304F7B085A0CA36124CFA90@BYAPR12MB2712.namprd12.prod.outlook.com>
On Thu, Dec 06, 2018 at 08:42:03PM +0000, Alexander Van Brunt wrote:
> > > > If we roll a TLB invalidation routine without the trailing DSB, what sort of
> > > > performance does that get you?
> > >
> > > It is not as good. In some cases, it is really bad. Skipping the invalidate was
> > > the most consistent and fast implementation.
>
> > My problem with that is it's not really much different to just skipping the
> > page table update entirely. Skipping the DSB is closer to what is done on
> > x86, where we bound the stale entry time to the next context-switch.
>
> Which of the three implementations is the "that" and "it" in the first sentence?
that = it = skipping the whole invalidation + the DSB
> > Given that I already queued the version without the DSB, we have the choice
> > to either continue with that or to revert it and go back to the previous
> > behaviour. Which would you prefer?
>
> To me, skipping the DSB is a win over doing the invalidate and the DSB because
> it is faster on average.
>
> DSBs have a big impact on the performance of other CPUs in the inner shareable
> domain because of the ordering requirements. For example, we have observed
> Cortex A57s stalling all CPUs in the cluster until Device accesses complete.
>
> Would you be open to a patch on top of the DSB skipping patch that skips the
> whole invalidate?
I don't think so; we don't have an upper bound on how long we'll have a
stale TLB if remove the invalidation completely.
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 06/28] kernel: Define gettimeofday vdso common code
From: Will Deacon @ 2018-12-07 17:53 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-arch, Arnd Bergmann, Catalin Marinas, Daniel Lezcano,
Russell King, Ralf Baechle, Mark Salyzyn, Paul Burton,
Vincenzo Frascino, Peter Collingbourne, linux-arm-kernel
In-Reply-To: <alpine.DEB.2.21.1811292230430.1657@nanos.tec.linutronix.de>
Hi Thomas,
You got me at this bit:
On Thu, Nov 29, 2018 at 11:11:52PM +0100, Thomas Gleixner wrote:
> On Thu, 29 Nov 2018, Vincenzo Frascino wrote:
> > +static __always_inline notrace int __do_realtime_or_tai(
> > + const struct vdso_data *vd,
> > + struct __vdso_timespec *ts,
> > + bool is_tai)
> > +{
> > + u32 seq, cs_mono_mult, cs_shift;
> > + u64 ns, sec;
> > + u64 cycle_last, cs_mono_mask;
> > +
> > + if (vd->use_syscall)
> > + return -1;
> > +repeat:
> > + seq = vdso_read_begin(vd);
> > + cycle_last = vd->cs_cycle_last;
> > + cs_mono_mult = vd->cs_mono_mult;
> > + cs_shift = vd->cs_shift;
> > + cs_mono_mask = vd->cs_mono_mask;
> > +
> > + if (is_tai)
> > + sec = vd->tai_sec;
> > + else
> > + sec = vd->xtime_clock_sec;
> > + ns = vd->xtime_clock_nsec;
> > +
> > + if (unlikely(vdso_read_retry(vd, seq)))
> > + goto repeat;
> > +
> > + ns += get_clock_shifted_nsec(cycle_last, cs_mono_mult, cs_mono_mask);
>
> This is broken. You cannot read the counter outside the seq count protected
> region. Please tell the ARM64 folks that their VDSO asm maze is broken.
We'll fix the maze, but could you explain a bit about the brokenness,
please? The write side in update_vsyscall() is only touching the data page,
so I think we've got those fields covered correctly with the seqlock. We'd
only have to worry about protecting the counter if it could be written
somehow.
Is your concern to do with migrating between systems, where the new system
has a counter with a different offset? If so, what does the program flow
look like when migrating in? I guess somehow we ensure that update_vsyscall()
is invoked before userspace can resume.
Anyway, moving the counter read into the protected region is a little fiddly
because the memory barriers we have in there won't give us the ordering we
need. We'll instead need to do something nasty, like create a dependency
from the counter read to the read of the seqlock:
Maybe the untested crufty hack below, although this will be a nightmare to
implement in C.
Will
--->8
diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
index c39872a7b03c..2d1dfecae76b 100644
--- a/arch/arm64/kernel/vdso/gettimeofday.S
+++ b/arch/arm64/kernel/vdso/gettimeofday.S
@@ -73,6 +73,8 @@ x_tmp .req x8
movn x_tmp, #0xff00, lsl #48
and \res, x_tmp, \res
mul \res, \res, \mult
+ and x_tmp, x_tmp, xzr
+ add vdso_data, vdso_data, x_tmp
.endm
/*
@@ -147,12 +149,12 @@ ENTRY(__kernel_gettimeofday)
/* w11 = cs_mono_mult, w12 = cs_shift */
ldp w11, w12, [vdso_data, #VDSO_CS_MONO_MULT]
ldp x13, x14, [vdso_data, #VDSO_XTIME_CLK_SEC]
- seqcnt_check fail=1b
get_nsec_per_sec res=x9
lsl x9, x9, x12
get_clock_shifted_nsec res=x15, cycle_last=x10, mult=x11
+ seqcnt_check fail=1b
get_ts_realtime res_sec=x10, res_nsec=x11, \
clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
@@ -211,13 +213,13 @@ realtime:
/* w11 = cs_mono_mult, w12 = cs_shift */
ldp w11, w12, [vdso_data, #VDSO_CS_MONO_MULT]
ldp x13, x14, [vdso_data, #VDSO_XTIME_CLK_SEC]
- seqcnt_check fail=realtime
/* All computations are done with left-shifted nsecs. */
get_nsec_per_sec res=x9
lsl x9, x9, x12
get_clock_shifted_nsec res=x15, cycle_last=x10, mult=x11
+ seqcnt_check fail=realtime
get_ts_realtime res_sec=x10, res_nsec=x11, \
clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
clock_gettime_return, shift=1
@@ -231,7 +233,6 @@ monotonic:
ldp w11, w12, [vdso_data, #VDSO_CS_MONO_MULT]
ldp x13, x14, [vdso_data, #VDSO_XTIME_CLK_SEC]
ldp x3, x4, [vdso_data, #VDSO_WTM_CLK_SEC]
- seqcnt_check fail=monotonic
/* All computations are done with left-shifted nsecs. */
lsl x4, x4, x12
@@ -239,6 +240,7 @@ monotonic:
lsl x9, x9, x12
get_clock_shifted_nsec res=x15, cycle_last=x10, mult=x11
+ seqcnt_check fail=monotonic
get_ts_realtime res_sec=x10, res_nsec=x11, \
clock_nsec=x15, xtime_sec=x13, xtime_nsec=x14, nsec_to_sec=x9
@@ -253,13 +255,13 @@ monotonic_raw:
/* w11 = cs_raw_mult, w12 = cs_shift */
ldp w12, w11, [vdso_data, #VDSO_CS_SHIFT]
ldp x13, x14, [vdso_data, #VDSO_RAW_TIME_SEC]
- seqcnt_check fail=monotonic_raw
/* All computations are done with left-shifted nsecs. */
get_nsec_per_sec res=x9
lsl x9, x9, x12
get_clock_shifted_nsec res=x15, cycle_last=x10, mult=x11
+ seqcnt_check fail=monotonic_raw
get_ts_clock_raw res_sec=x10, res_nsec=x11, \
clock_nsec=x15, nsec_to_sec=x9
_______________________________________________
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 0/2] meson: Fix IRQ trigger type
From: Emiliano Ingrassia @ 2018-12-07 18:28 UTC (permalink / raw)
To: Jerome Brunet, Carlo Caione, Martin Blumenstingl
Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <44c9eedf4dc2616645c2a49b080f42a493fe03fd.camel@baylibre.com>
On Fri, Dec 07, 2018 at 11:49:15AM +0100, Jerome Brunet wrote:
> On Thu, 2018-12-06 at 19:51 +0100, Emiliano Ingrassia wrote:
> > Hi Carlo,
> >
> > I keep running tests with packet generator,
> > using nload to show bandwidth usage.
> >
> > Here is my test results with packet generators
> > both running on laptop and board with rate 1 Gbps.
>
> Testing in UDP is unlikely to give us clear picture of anything for this sort
> of fixes.
>
Why? Would you mind to explain your reasoning?
> All your test seems in show it the fact the Amlogic SoC usually prioritize the
> TX traffic over RX, which is something we've known about for a while.
>
Is that normal and/or acceptable?
> It would be helpful if you could provide TCP figures with a traffic generator
> we can all share an inspect, such as iperf3
>
> Finally, Your test do not show the original issue regarding EEE. So the work
> around we put (yes, it was never considered a solution) for it should not be
> kept IHMO. Your numbers for EEE may be due to the way the traffic is generated
> and the PHY entering LPI and taking a bit of time to exit it. Again UDP is not
> very helpful to characterize this.
>
Did you read my email entirely or just kidding me?
TEST 3 clearly shows that the issue regarding EEE is still there
with both patches applied.
My comment about TEST 3 (same results as TEST 2):
"Simple ping test from laptop to board shows a packet loss
of 90% and more while no packet loss achieved pinging
the laptop from the board."
I definitively advice against the second patch (the part regarding
32 bit Meson SoC).
About the first one, still no evidence that is needed on Meson8b SoC.
And I'm saying it because I tested both patches on real hardware,
not just guessing!
Furthermore, as Martin reported in one of the previous mail,
even Amlogic's buildroot kernel uses an edge rising IRQ type
for the Meson8b MAC. Other evidence that is not so clear
the need for the first patch on 32 bit Meson SoC.
> >
> > TEST 0: no patch applied.
> >
> > 1) Start packet generator on laptop:
> >
> > | incoming traffic | outgoing traffic
> > =====================================================
> > nload (board) | ~940 Mbps | 0 Mbps
> > -----------------------------------------------------
> > nload (laptop)| 0 Mbps | ~940 Mbps
> > =====================================================
> >
> > 2) Start packet generator on board:
> >
> > | incoming traffic | outgoing traffic
> > ==============+===================+==================
> > nload (board) | ~460 Mbps | ~256 Mbps
> > --------------+-------------------+------------------
> > nload (laptop)| ~256 Mbps | ~940 Mbps
> > =====================================================
> >
> > 3) Stop packet generator on laptop:
> >
> > | incoming traffic | outgoing traffic
> > =====================================================
> > nload (board) | 0 Mbps | ~940 Mbps
> > -----------------------------------------------------
> > nload (laptop)| ~940 Mbps | 0 Mbps
> > =====================================================
> >
> > 4) Restart packet generator on laptop:
> >
> > | incoming traffic | outgoing traffic
> > =====================================================
> > nload (board) | ~0 Mbps | ~940 Mbps
> > -----------------------------------------------------
> > nload (laptop)| ~940 Mbps | ~940 Mbps
> > =====================================================
> >
> > In the last case the "ifconfig" statistics about RX packets
> > remain fixed which probably indicates that the incoming traffic
> > to the board is effectively being dropped.
> >
> > The eth0 interrupt counter keeps incrementing.
> > Simple ping test works correctly.
> >
> >
> > TEST 1: IRQ type patch applied
> >
> > Same results as TEST 0.
> >
> >
> > TEST 2: eee-broken-1000t flag removed
> >
> > 1) Start packet generator on laptop:
> >
> > | incoming traffic | outgoing traffic
> > =====================================================
> > nload (board) | ~3Mbps | 0 Mbps
> > -----------------------------------------------------
> > nload (laptop)| 0 Mbps | ~940 Mbps
> > =====================================================
> >
> > 2) Start packet generator on board:
> >
> > | incoming traffic | outgoing traffic
> > ==============+===================+==================
> > nload (board) | ~0 Mbps | ~940 Mbps
> > --------------+-------------------+------------------
> > nload (laptop)| ~940 Mbps | ~940 Mbps
> > =====================================================
> >
> > 3) Stop packet generator on laptop:
> >
> > | incoming traffic | outgoing traffic
> > =====================================================
> > nload (board) | 0 Mbps | ~940 Mbps
> > -----------------------------------------------------
> > nload (laptop)| ~940 Mbps | 0 Mbps
> > =====================================================
> >
> > 4) Restart packet generator on laptop:
> >
> > | incoming traffic | outgoing traffic
> > =====================================================
> > nload (board) | ~0 Mbps | ~940 Mbps
> > -----------------------------------------------------
> > nload (laptop)| ~940 Mbps | ~940 Mbps
> > =====================================================
> >
> > In the first case the "ifconfig" statistics about RX packets
> > are incremented consistently with the incoming traffic value
> > showed by the nload (board side).
> >
> > In the last case the "ifconfig" statistics about RX packets
> > remain fixed which probably indicates that the incoming traffic
> > to the board is effectively being dropped.
> >
> > The eth0 interrupt counter keeps incrementing.
> > Simple ping test from laptop to board shows a packet loss
> > of 90% and more while no packet loss achieved pinging
> > the laptop from the board.
> >
> >
> > TEST 3: both patches applied.
> >
> > Same results as TEST 2.
> >
> >
> > From the results obtained from these tests,
> > which are more accurate than the previous one,
> > I can say that the second patch (remove eee-broken-1000t flag)
> > should NOT be applied.
> >
> > About the first one (change MAC IRQ type), I would like
> > to do other tests with other tools like iperf3.
> > With these results only, I would say to not apply it
> > because nothing changed but if your stress test failed on
> > long running and this patch fix it I would like to test it more deeply.
> >
> > As final thought, the conducted tests clearly show that if the board
> > transmits at full rate, all the incoming traffic is dropped.
> > I think that this behaviour should be fixed but don't know if
> > it depends on the driver or device tree description.
> > I'll keep investigating.
> >
> > Regards,
> >
> > Emiliano
> >
> > On Thu, Dec 06, 2018 at 04:52:28PM +0100, Emiliano Ingrassia wrote:
> > > Hi Carlo,
> > >
> > > thanks for the answer.
> > >
> > > On Thu, Dec 06, 2018 at 01:17:58PM +0000, Carlo Caione wrote:
> > > > On Thu, 2018-12-06 at 13:43 +0100, Emiliano Ingrassia wrote:
> > > > > Hi all,
> > > >
> > > > Hi Emiliano,
> > > >
> > > > > thank you for involving me.
> > > > >
> > > > > I applied Carlo's patches[0] on a kernel vanilla 4.19.6
> > > > > and tested it with kernel packet generator, monitoring
> > > > > bandwidth usage with "nload".
> > > > >
> > > > > All tests were conducted on an Odroid-C1+ Rev. 0.4-20150930 board
> > > > > with a short ethernet cable directly attached to a laptop with
> > > > > 1G ethernet interface, with "nload" running on the board.
> > > > >
> > > > > The tests I performed are composed by the following steps:
> > > > >
> > > > > 1) Start packet generator with "rate 1000M" on laptop;
> > > > >
> > > > > 2) Keep packet generator active on the laptop and
> > > > > start the packet generator on the board with "rate 1000M";
> > > > >
> > > > > 3) Stop both packet generators;
> > > > >
> > > > > 4) Start packet generator on the board;
> > > > >
> > > > > 5) Keep packet generator active on the board and
> > > > > start the packet generator on the laptop.
> > > >
> > > > out of curiosity: why do you expect to see something different from
> > > > point (2)?
> > > >
> > >
> > > I did not expect it indeed, I tried and got different results.
> > >
> > > > > Test results without Carlo's patches applied:
> > > > >
> > > > > 1) "nload" shows an incoming traffic of ~950Mbps;
> > > > >
> > > > > 2) "nload" shows an incoming traffic of ~400Mbps
> > > > > and an outgoing traffic of ~250Mbps;
> > > > >
> > > > > 3) "nload" shows 0Mbps both for incoming and outgoing traffic;
> > > > >
> > > > > 4) "nload" shows an outgoing traffic of ~950Mbps from the board;
> > > > >
> > > > > 5) "nload" shows incoming traffic of 0Mbps
> > > > > and an outgoing traffic of ~950Mbps.
> > > > >
> > > > > Applying only the first patch (change mac IRQ type) I got the same
> > > > > results.
> > > >
> > > > This is expected. The change in the IRQ type is solving an issue that
> > > > you can see if the run a stress test involving multiple components for
> > > > several hours.
> > > >
> > >
> > > OK, did you use "stress-ng" tool for tests?
> > >
> > > > > Applying only the second patch (drop eee-broken-1000t) I got the same
> > > > > results!
> > > >
> > > > I am a bit confused here. Wasn't the eee-broken-1000t added to fix a
> > > > problem with the ethernet? Are you suggesting that for some reason you
> > > > cannot reproduce anymore the problem for which the quirk was
> > > > introduced?
> > > >
> > >
> > > Problems without the "eee-broken-1000t" flags were experimented
> > > one and a half years ago on a Amlogic development kernel from [0],
> > > probably a 4.14 version.
> > > Many patches about Meson8b SoC, dwmac-meson8b and dwmac driver
> > > were introduced so yes, the "eee-broken-1000t" was added
> > > to fix a problem with the ethernet (one and a half years ago),
> > > but new tests are needed to say if it still necessary.
> > >
> > > > > With both patches applied I got the same results but with an incoming
> > > > > traffic
> > > > > of ~3Mbps on the board.
> > > >
> > > > On all the tests and immediately from the start of the tests?
> > > >
> > >
> > > Yes, in all the 5 steps immediately from the start.
> > >
> > > I also tried to execute "nload" on both sides to see the bandwidth
> > > usage.
> > >
> > > With bot patches applied, after starting kernel packet generator
> > > on my laptop with 1Gbps rate, "nload" on the laptop side shows me
> > > an outgoing traffic of ~940Mbps while "nload" on the board side shows
> > > me an incoming traffic of ~3Mbps.
> > >
> > > Also consider that a pinging test from my laptop to the board shows
> > > a packet loss of about 90%.
> > >
> > > > When you hit the problem con you check in /proc/interrupts if you see
> > > > the IRQ counter for the eth0 incrementing or not?
> > > >
> > >
> > > The eth0 IRQ counter is incremented during the test.
> > >
> > > > Cheers,
> > > >
> > > > --
> > > > Carlo Caione
> > > >
> > > >
> > >
> > > I would like to conduct other tests with iperf3 to be sure about
> > > the obtained results. What do you think?
> > > Should I apply your patches on the latest Amlogic development kernel?
> > >
> > > Regards,
> > >
> > > Emiliano
> > >
> > > [0]
> > > https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/
> >
> > Cheers,
> >
> > Emiliano
> >
> > _______________________________________________
> > linux-amlogic mailing list
> > linux-amlogic@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
>
_______________________________________________
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] Fix OMAP4430 SDP Ethernet startup
From: santosh.shilimkar @ 2018-12-07 18:25 UTC (permalink / raw)
To: Tony Lindgren, Russell King - ARM Linux
Cc: Peter Ujfalusi, linux-omap, linux-arm-kernel, Santosh Shilimkar
In-Reply-To: <20181207171642.GR6707@atomide.com>
On 12/7/18 9:16 AM, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [181207 13:58]:
[...]
>>> The 20ms you are seeing confirms this setup.
>>
>> Thanks for the confirmation and information. The Blaze schematics
>> are also unavailable afaics.
>
> Thanks applying into omap-for-v4.20/fixes with updated notes
> from Peter for the wiring.
>
Thanks Tony !!
_______________________________________________
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/3] arm64: dts: qcom: msm8998: correct xo clock name
From: Andy Gross @ 2018-12-07 18:23 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: Marc Gonzalez, Stephen Boyd, MSM, Bjorn Andersson, Georgi Djakov,
Linux ARM
In-Reply-To: <8a1ec3da-0c07-7c05-cf5b-f1fef001c972@codeaurora.org>
On Fri, Dec 07, 2018 at 07:58:52AM -0700, Jeffrey Hugo wrote:
> On 12/7/2018 2:03 AM, Marc Gonzalez wrote:
> >On 06/12/2018 19:34, Stephen Boyd wrote:
> >>Quoting Jeffrey Hugo (2018-12-05 15:04:01)
> >>>On 12/5/2018 2:42 PM, Stephen Boyd wrote:
> >>>>Quoting Jeffrey Hugo (2018-12-05 13:20:07)
> >>>>>On 12/5/2018 2:04 PM, Stephen Boyd wrote:
> >>>>>>Quoting Jeffrey Hugo (2018-12-05 09:03:54)
> >>>>>>
> >>>>>>I don't quite understand the patch in general. The xo_board clk should
> >>>>>>always exist in DT and the fixed factor clk in GCC is there until the
> >>>>>>rpm clk driver can control the XO clk state vote for the kernel.
> >>>>>
> >>>>>Sorry, this wasn't apparent. It doesn't seem like this "requirement" is
> >>>>>captured anywhere.
> >>>>
> >>>>Agreed!
> >>>>
> >>>>>
> >>>>>As far as the SD clocks are concerned, they are defined in GCC, and
> >>>>>eventually have a root parent called "xo". "xo" isn't defined anywhere,
> >>>>>so the SD clocks can't really be used, and the hardware doesn't come up.
> >>>>> This patch "fixed" that, but I missed the link to the rpm driver that
> >>>>>Marc pointed out.
> >>>>
> >>>>Hmm ok. The SD DT node should just point to the xo_board clk for now and
> >>>>later on it can be changed to use the rpm clk when the rpm node is
> >>>>created.
> >>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>If anything, change the DT node to be named xo-board instead of xo_board
> >>>>>>because that matches DT naming schemes and then add a clock-output-names
> >>>>>>= "xo_board" property to it so that we keep the underscore.
> >>>>>
> >>>>>I see this now, and I agree with it, but then SD goes back to a broken
> >>>>>state because there is "xo" clock for GCC. Its not quite clear to me
> >>>>>how to make GCC (and thus SD) happy again with this change reverted/fixed.
> >>>>>
> >>>>>Bjorn mentioned offline he is going to take a look, but he has a few
> >>>>>other things on his plate first.
> >>>>>
> >>>>
> >>>>There is an XO clk created in drivers/clk/qcom/gcc-msm8996.c, we should
> >>>>do the same here until rpm can handle this. I'll pack this patch up and
> >>>>merge it to clk-next soon.
> >>>
> >>>Thanks. I pulled in the below change into my tree, and fixed up the DT
> >>>based on the discussion we had. SD works, and things look sane to me
> >>>per clk_summary in debugfs.
> >>>
> >>>Feel free to throw my tested-by on if you want.
> >>
> >>Thanks. I did so and merged it up to clk-next.
> >
> >@Andy, don't you still need to revert 634da3307b083ee83eb9b377081fdfd6416a148a
> >("arm64: dts: qcom: msm8998: correct xo clock name") in for-next?
I'll send a fix for this. I think we want to keep the xo label, and just change
it to xo: xo_board. So instead of a revert, it'll be that + a Fixes line.
That ok?
Andy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] firmware: raspberrypi: notify VC4 firmware of a reboot
From: Stefan Wahren @ 2018-12-07 18:21 UTC (permalink / raw)
To: Florian Fainelli, Ray Jui, Scott Branden, Eric Anholt,
Arnd Bergmann
Cc: Stefan Wahren, bcm-kernel-feedback-list, linux-rpi-kernel,
linux-arm-kernel
In-Reply-To: <1544206871-15725-1-git-send-email-stefan.wahren@i2se.com>
The firmware-owned GPIO expander on RPi 3 B+ must be in same state
after a reboot as initial power on. Otherwise this would cause a
network boot failure of the BOOTROM. So inform the VC4 firmware to restore
the expander before doing a reboot.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Phil Elwell <phil@raspberrypi.org>
---
drivers/firmware/raspberrypi.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index a135581..61be15d 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -238,6 +238,16 @@ static int rpi_firmware_probe(struct platform_device *pdev)
return 0;
}
+static void rpi_firmware_shutdown(struct platform_device *pdev)
+{
+ struct rpi_firmware *fw = platform_get_drvdata(pdev);
+
+ if (!fw)
+ return;
+
+ rpi_firmware_property(fw, RPI_FIRMWARE_NOTIFY_REBOOT, NULL, 0);
+}
+
static int rpi_firmware_remove(struct platform_device *pdev)
{
struct rpi_firmware *fw = platform_get_drvdata(pdev);
@@ -278,6 +288,7 @@ static struct platform_driver rpi_firmware_driver = {
.of_match_table = rpi_firmware_of_match,
},
.probe = rpi_firmware_probe,
+ .shutdown = rpi_firmware_shutdown,
.remove = rpi_firmware_remove,
};
module_platform_driver(rpi_firmware_driver);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] soc: bcm2835: sync firmware properties with downstream
From: Stefan Wahren @ 2018-12-07 18:21 UTC (permalink / raw)
To: Florian Fainelli, Ray Jui, Scott Branden, Eric Anholt,
Arnd Bergmann
Cc: Stefan Wahren, bcm-kernel-feedback-list, linux-rpi-kernel,
linux-arm-kernel
Add latest firmware property tags from the latest Raspberry Pi downstream
kernel. This is needed to use the reboot notify in the following
commit.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
include/soc/bcm2835/raspberrypi-firmware.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index 4be1aa4..7800e12 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -73,6 +73,8 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_GET_CUSTOMER_OTP = 0x00030021,
RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
RPI_FIRMWARE_GET_THROTTLED = 0x00030046,
+ RPI_FIRMWARE_GET_CLOCK_MEASURED = 0x00030047,
+ RPI_FIRMWARE_NOTIFY_REBOOT = 0x00030048,
RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
RPI_FIRMWARE_SET_VOLTAGE = 0x00038003,
@@ -86,6 +88,8 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_SET_GPIO_CONFIG = 0x00038043,
RPI_FIRMWARE_GET_PERIPH_REG = 0x00030045,
RPI_FIRMWARE_SET_PERIPH_REG = 0x00038045,
+ RPI_FIRMWARE_GET_POE_HAT_VAL = 0x00030049,
+ RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
/* Dispmanx TAGS */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 00/17] initial support for "suniv" Allwinner new ARM9 SoC
From: Marc Zyngier @ 2018-12-07 18:16 UTC (permalink / raw)
To: Mesih Kilinc, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, linux-gpio, linux-sunxi
Cc: Julian Calaby, Linus Walleij, Daniel Lezcano, Russell King,
Chen-Yu Tsai, Rob Herring, Maxime Ripard, Icenowy Zheng
In-Reply-To: <cover.1543781680.git.mesihkilinc@gmail.com>
On 02/12/2018 20:23, Mesih Kilinc wrote:
> This is the sixth version of patchset for Allwinner ARMv5 F1C100s
> SoC. Addressed comments from Stephen Boyd, added signatures.
I've queued the 4 irqchip patches for 4.21.
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 2/3] irqchip: stm32: protect configuration registers with hwspinlock
From: Marc Zyngier @ 2018-12-07 18:14 UTC (permalink / raw)
To: Benjamin Gaignard, tglx, jason, robh+dt, mark.rutland,
alexandre.torgue
Cc: Benjamin Gaignard, devicetree, linux-kernel, linux-arm-kernel,
linux-stm32
In-Reply-To: <20181113144805.1054-3-benjamin.gaignard@st.com>
On 13/11/2018 14:48, Benjamin Gaignard wrote:
> If a hwspinlock is defined in device tree use it to protect
> configuration registers.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/irqchip/irq-stm32-exti.c | 36 ++++++++++++++++++++++++++++++------
> 1 file changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/irqchip/irq-stm32-exti.c b/drivers/irqchip/irq-stm32-exti.c
> index 0a2088e12d96..a010a2eed078 100644
> --- a/drivers/irqchip/irq-stm32-exti.c
> +++ b/drivers/irqchip/irq-stm32-exti.c
> @@ -6,6 +6,7 @@
> */
>
> #include <linux/bitops.h>
> +#include <linux/hwspinlock.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/irq.h>
> @@ -20,6 +21,8 @@
>
> #define IRQS_PER_BANK 32
>
> +#define HWSPINLOCK_TIMEOUT 5 /* msec */
> +
> struct stm32_exti_bank {
> u32 imr_ofst;
> u32 emr_ofst;
> @@ -47,6 +50,7 @@ struct stm32_exti_drv_data {
> struct stm32_exti_chip_data {
> struct stm32_exti_host_data *host_data;
> const struct stm32_exti_bank *reg_bank;
> + struct hwspinlock *hwlock;
> struct raw_spinlock rlock;
> u32 wake_active;
> u32 mask_cache;
> @@ -275,25 +279,34 @@ static int stm32_irq_set_type(struct irq_data *d, unsigned int type)
> struct stm32_exti_chip_data *chip_data = gc->private;
> const struct stm32_exti_bank *stm32_bank = chip_data->reg_bank;
> u32 rtsr, ftsr;
> - int err;
> + int err = 0;
>
> irq_gc_lock(gc);
>
> + if (chip_data->hwlock)
> + err = hwspin_lock_timeout(chip_data->hwlock,
> + HWSPINLOCK_TIMEOUT);
> +
> + if (err)
> + goto unlock;
> +
> rtsr = irq_reg_readl(gc, stm32_bank->rtsr_ofst);
> ftsr = irq_reg_readl(gc, stm32_bank->ftsr_ofst);
>
> err = stm32_exti_set_type(d, type, &rtsr, &ftsr);
> - if (err) {
> - irq_gc_unlock(gc);
> - return err;
> - }
> + if (err)
> + goto unspinlock;
>
> irq_reg_writel(gc, rtsr, stm32_bank->rtsr_ofst);
> irq_reg_writel(gc, ftsr, stm32_bank->ftsr_ofst);
>
> +unspinlock:
> + if (chip_data->hwlock)
> + hwspin_unlock(chip_data->hwlock);
> +unlock:
> irq_gc_unlock(gc);
>
> - return 0;
> + return err;
> }
>
> static void stm32_chip_suspend(struct stm32_exti_chip_data *chip_data,
> @@ -670,6 +683,7 @@ static int __init stm32_exti_init(const struct stm32_exti_drv_data *drv_data,
> int nr_irqs, ret, i;
> struct irq_chip_generic *gc;
> struct irq_domain *domain;
> + struct hwspinlock *hwlock = NULL;
>
> host_data = stm32_exti_host_init(drv_data, node);
> if (!host_data)
> @@ -692,12 +706,22 @@ static int __init stm32_exti_init(const struct stm32_exti_drv_data *drv_data,
> goto out_free_domain;
> }
>
> + /* hwspinlock is optional */
> + ret = of_hwspin_lock_get_id(node, 0);
> + if (ret < 0) {
> + if (ret == -EPROBE_DEFER)
> + goto out_free_domain;
Wouldn't it make sense to probe for this before allocating the domain?
> + } else {
> + hwlock = hwspin_lock_request_specific(ret);
> + }
> +
> for (i = 0; i < drv_data->bank_nr; i++) {
> const struct stm32_exti_bank *stm32_bank;
> struct stm32_exti_chip_data *chip_data;
>
> stm32_bank = drv_data->exti_banks[i];
> chip_data = stm32_exti_chip_init(host_data, i, node);
> + chip_data->hwlock = hwlock;
>
> gc = irq_get_domain_generic_chip(domain, i * IRQS_PER_BANK);
>
>
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: OMAP4430 SDP with KS8851: very slow networking
From: Tony Lindgren @ 2018-12-07 18:14 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: netdev, Grygorii Strashko, linux-omap, linux-arm-kernel
In-Reply-To: <20181207180020.GA9507@n2100.armlinux.org.uk>
Hi,
* Russell King - ARM Linux <linux@armlinux.org.uk> [181207 18:01]:
> Hi Tony,
>
> You know most of what's been going on from IRC, but here's the patch
> which gets me:
>
> 1) working interrupts for networking
> 2) solves the stuck-wakeup problem
>
> It also contains some of the debug bits I added.
This is excellent news :) Will test today.
> I think what this means is that we should strip out ec0daae685b2
> ("gpio: omap: Add level wakeup handling for omap4 based SoCs").
Yes the only reason for the wakeup quirk was the stuck wakeup
state seen on omap4, it can be just dropped if this works.
Adding Grygorii to Cc too.
Regards,
Tony
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 3d021f648c5d..528ffd1b9832 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -11,7 +11,7 @@
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> */
> -
> +#define DEBUG
> #include <linux/init.h>
> #include <linux/module.h>
> #include <linux/interrupt.h>
> @@ -366,10 +366,14 @@ static inline void omap_set_gpio_trigger(struct gpio_bank *bank, int gpio,
> trigger & IRQ_TYPE_LEVEL_LOW);
> omap_gpio_rmw(base, bank->regs->leveldetect1, gpio_bit,
> trigger & IRQ_TYPE_LEVEL_HIGH);
> + /*
> + * We need the edge detect enabled for the idle mode detection
> + * to function on OMAP4430.
> + */
> omap_gpio_rmw(base, bank->regs->risingdetect, gpio_bit,
> - trigger & IRQ_TYPE_EDGE_RISING);
> + trigger & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH));
> omap_gpio_rmw(base, bank->regs->fallingdetect, gpio_bit,
> - trigger & IRQ_TYPE_EDGE_FALLING);
> + trigger & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_LEVEL_LOW));
>
> bank->context.leveldetect0 =
> readl_relaxed(bank->base + bank->regs->leveldetect0);
> @@ -910,14 +914,16 @@ static void omap_gpio_unmask_irq(struct irq_data *d)
> if (trigger)
> omap_set_gpio_triggering(bank, offset, trigger);
>
> + omap_set_gpio_irqenable(bank, offset, 1);
> +
> /* For level-triggered GPIOs, the clearing must be done after
> - * the HW source is cleared, thus after the handler has run */
> - if (bank->level_mask & BIT(offset)) {
> - omap_set_gpio_irqenable(bank, offset, 0);
> + * the HW source is cleared, thus after the handler has run.
> + * OMAP4 needs this done _after_ enabing the interrupt to clear
> + * the wakeup status.
> + */
> + if (bank->level_mask & BIT(offset))
> omap_clear_gpio_irqstatus(bank, offset);
> - }
>
> - omap_set_gpio_irqenable(bank, offset, 1);
> raw_spin_unlock_irqrestore(&bank->lock, flags);
> }
>
> @@ -1520,6 +1526,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)
> struct device *dev = bank->chip.parent;
> u32 l1 = 0, l2 = 0;
>
> + dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
> + bank->context.leveldetect0, bank->context.leveldetect1,
> + bank->context.wake_en);
> +
> if (bank->funcs.idle_enable_level_quirk)
> bank->funcs.idle_enable_level_quirk(bank);
>
> @@ -1553,6 +1563,10 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context)
> bank->get_context_loss_count(dev);
>
> omap_gpio_dbck_disable(bank);
> +
> + dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
> + bank->context.leveldetect0, bank->context.leveldetect1,
> + bank->context.wake_en);
> }
>
> static void omap_gpio_init_context(struct gpio_bank *p);
> @@ -1563,6 +1577,10 @@ static void omap_gpio_unidle(struct gpio_bank *bank)
> u32 l = 0, gen, gen0, gen1;
> int c;
>
> + dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
> + bank->context.leveldetect0, bank->context.leveldetect1,
> + bank->context.wake_en);
> +
> /*
> * On the first resume during the probe, the context has not
> * been initialised and so initialise it now. Also initialise
> @@ -1648,6 +1666,10 @@ static void omap_gpio_unidle(struct gpio_bank *bank)
> }
>
> bank->workaround_enabled = false;
> +
> + dev_dbg(dev, "%s(): ld 0x%08x 0x%08x we 0x%08x\n", __func__,
> + bank->context.leveldetect0, bank->context.leveldetect1,
> + bank->context.wake_en);
> }
>
> static void omap_gpio_init_context(struct gpio_bank *p)
> @@ -1720,6 +1742,7 @@ static int __maybe_unused omap_gpio_runtime_suspend(struct device *dev)
> error = -EBUSY;
> goto unlock;
> }
> + dev_dbg(dev, "%s()\n", __func__);
> omap_gpio_idle(bank, true);
> bank->is_suspended = true;
> unlock:
> @@ -1741,6 +1764,7 @@ static int __maybe_unused omap_gpio_runtime_resume(struct device *dev)
> error = -EBUSY;
> goto unlock;
> }
> + dev_dbg(dev, "%s()\n", __func__);
> omap_gpio_unidle(bank);
> bank->is_suspended = false;
> unlock:
> @@ -1827,8 +1851,8 @@ static const struct omap_gpio_platform_data omap4_pdata = {
> .regs = &omap4_gpio_regs,
> .bank_width = 32,
> .dbck_flag = true,
> - .quirks = OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER |
> - OMAP_GPIO_QUIRK_DEFERRED_WKUP_EN,
> + .quirks = OMAP_GPIO_QUIRK_IDLE_REMOVE_TRIGGER /* |
> + OMAP_GPIO_QUIRK_DEFERRED_WKUP_EN */,
> };
>
> static const struct of_device_id omap_gpio_match[] = {
>
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
>
> _______________________________________________
> 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
* [PATCHv2 00/10] arm64: assembly export cleanup
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
When exporting a C function, we place the EXPORT_SYMBOL() immediately after the
function definition. Historically we couldn't do this with assembly functions,
and hence we collected all of these exports in arm64ksyms.c. Over time, this
has retained redundant includes and exports for items defined in C code.
For a while now it has been possible to export functions directly from assembly
files, which is beneficial for ongoing maintenance.
These patches move the exports from arm64ksyms.c into their relevant assembly
files, and remove the newly redundant arm64ksyms.c. I've pushed the series to
my arm64/export-cleanup branch [1] on kernel.org.
Thanks,
Mark.
Since v1 [2]:
* fold arm64 <asm/export.h> into <asm/assembler.h>
* rebase to for-next/core
[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/export-cleanup
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/610372.html
Mark Rutland (10):
arm64: remove bitop exports
arm64: move memstart_addr export inline
arm64: add EXPORT_SYMBOL_NOKASAN()
arm64: tishift: use asm EXPORT_SYMBOL()
arm64: smccc: use asm EXPORT_SYMBOL()
arm64: page: use asm EXPORT_SYMBOL()
arm64: uaccess: use asm EXPORT_SYMBOL()
arm64: string: use asm EXPORT_SYMBOL()
arm64: frace: use asm EXPORT_SYMBOL()
arm64: remove arm64ksyms.c
arch/arm64/include/asm/assembler.h | 9 ++++
arch/arm64/kernel/Makefile | 2 +-
arch/arm64/kernel/arm64ksyms.c | 88 --------------------------------------
arch/arm64/kernel/entry-ftrace.S | 4 ++
arch/arm64/kernel/smccc-call.S | 4 ++
arch/arm64/lib/clear_page.S | 1 +
arch/arm64/lib/clear_user.S | 2 +
arch/arm64/lib/copy_from_user.S | 4 +-
arch/arm64/lib/copy_in_user.S | 4 +-
arch/arm64/lib/copy_page.S | 1 +
arch/arm64/lib/copy_to_user.S | 4 +-
arch/arm64/lib/memchr.S | 1 +
arch/arm64/lib/memcmp.S | 1 +
arch/arm64/lib/memcpy.S | 2 +
arch/arm64/lib/memmove.S | 2 +
arch/arm64/lib/memset.S | 2 +
arch/arm64/lib/strchr.S | 1 +
arch/arm64/lib/strcmp.S | 1 +
arch/arm64/lib/strlen.S | 1 +
arch/arm64/lib/strncmp.S | 1 +
arch/arm64/lib/strnlen.S | 1 +
arch/arm64/lib/strrchr.S | 1 +
arch/arm64/lib/tishift.S | 5 +++
arch/arm64/mm/init.c | 2 +
24 files changed, 52 insertions(+), 92 deletions(-)
delete mode 100644 arch/arm64/kernel/arm64ksyms.c
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv2 05/10] arm64: smccc: use asm EXPORT_SYMBOL()
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
For a while now it's been possible to use EXPORT_SYMBOL() in assembly
files, which allows us to place exports immediately after assembly
functions, as we do for C functions.
As a step towards removing arm64ksyms.c, let's move the SMCCC exports to
the assembly file the functions are defined in.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/arm64ksyms.c | 5 -----
arch/arm64/kernel/smccc-call.S | 4 ++++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index d80e9cfc3062..74e29e69190b 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -26,7 +26,6 @@
#include <linux/syscalls.h>
#include <linux/uaccess.h>
#include <linux/io.h>
-#include <linux/arm-smccc.h>
#include <linux/kprobes.h>
#include <asm/checksum.h>
@@ -64,7 +63,3 @@ EXPORT_SYMBOL(_mcount);
NOKPROBE_SYMBOL(_mcount);
#endif
- /* arm-smccc */
-EXPORT_SYMBOL(__arm_smccc_smc);
-EXPORT_SYMBOL(__arm_smccc_hvc);
-
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index 62522342e1e4..184332286a81 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -13,7 +13,9 @@
*/
#include <linux/linkage.h>
#include <linux/arm-smccc.h>
+
#include <asm/asm-offsets.h>
+#include <asm/assembler.h>
.macro SMCCC instr
.cfi_startproc
@@ -40,6 +42,7 @@
ENTRY(__arm_smccc_smc)
SMCCC smc
ENDPROC(__arm_smccc_smc)
+EXPORT_SYMBOL(__arm_smccc_smc)
/*
* void arm_smccc_hvc(unsigned long a0, unsigned long a1, unsigned long a2,
@@ -50,3 +53,4 @@ ENDPROC(__arm_smccc_smc)
ENTRY(__arm_smccc_hvc)
SMCCC hvc
ENDPROC(__arm_smccc_hvc)
+EXPORT_SYMBOL(__arm_smccc_hvc)
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 08/10] arm64: string: use asm EXPORT_SYMBOL()
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
For a while now it's been possible to use EXPORT_SYMBOL() in assembly
files, which allows us to place exports immediately after assembly
functions, as we do for C functions.
As a step towards removing arm64ksyms.c, let's move the string routine
exports to the assembly files the functions are defined in. Routines
which should only be exported for !KASAN builds are exported using the
EXPORT_SYMBOL_NOKASAN() helper.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/arm64ksyms.c | 20 --------------------
arch/arm64/lib/memchr.S | 1 +
arch/arm64/lib/memcmp.S | 1 +
arch/arm64/lib/memcpy.S | 2 ++
arch/arm64/lib/memmove.S | 2 ++
arch/arm64/lib/memset.S | 2 ++
arch/arm64/lib/strchr.S | 1 +
arch/arm64/lib/strcmp.S | 1 +
arch/arm64/lib/strlen.S | 1 +
arch/arm64/lib/strncmp.S | 1 +
arch/arm64/lib/strnlen.S | 1 +
arch/arm64/lib/strrchr.S | 1 +
12 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 02019667e319..c142103bc0fe 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -19,7 +19,6 @@
#include <linux/export.h>
#include <linux/sched.h>
-#include <linux/string.h>
#include <linux/cryptohash.h>
#include <linux/delay.h>
#include <linux/in6.h>
@@ -29,25 +28,6 @@
#include <asm/checksum.h>
- /* string / mem functions */
-#ifndef CONFIG_KASAN
-EXPORT_SYMBOL(strchr);
-EXPORT_SYMBOL(strrchr);
-EXPORT_SYMBOL(strcmp);
-EXPORT_SYMBOL(strncmp);
-EXPORT_SYMBOL(strlen);
-EXPORT_SYMBOL(strnlen);
-EXPORT_SYMBOL(memcmp);
-EXPORT_SYMBOL(memchr);
-#endif
-
-EXPORT_SYMBOL(memset);
-EXPORT_SYMBOL(memcpy);
-EXPORT_SYMBOL(memmove);
-EXPORT_SYMBOL(__memset);
-EXPORT_SYMBOL(__memcpy);
-EXPORT_SYMBOL(__memmove);
-
#ifdef CONFIG_FUNCTION_TRACER
EXPORT_SYMBOL(_mcount);
NOKPROBE_SYMBOL(_mcount);
diff --git a/arch/arm64/lib/memchr.S b/arch/arm64/lib/memchr.S
index 0f164a4baf52..f146b7ecd28f 100644
--- a/arch/arm64/lib/memchr.S
+++ b/arch/arm64/lib/memchr.S
@@ -42,3 +42,4 @@ WEAK(memchr)
2: mov x0, #0
ret
ENDPIPROC(memchr)
+EXPORT_SYMBOL_NOKASAN(memchr)
diff --git a/arch/arm64/lib/memcmp.S b/arch/arm64/lib/memcmp.S
index fb295f52e9f8..e2e629b09049 100644
--- a/arch/arm64/lib/memcmp.S
+++ b/arch/arm64/lib/memcmp.S
@@ -256,3 +256,4 @@ CPU_LE( rev data2, data2 )
mov result, #0
ret
ENDPIPROC(memcmp)
+EXPORT_SYMBOL_NOKASAN(memcmp)
diff --git a/arch/arm64/lib/memcpy.S b/arch/arm64/lib/memcpy.S
index 67613937711f..b4f82888ed60 100644
--- a/arch/arm64/lib/memcpy.S
+++ b/arch/arm64/lib/memcpy.S
@@ -74,4 +74,6 @@ ENTRY(memcpy)
#include "copy_template.S"
ret
ENDPIPROC(memcpy)
+EXPORT_SYMBOL(memcpy)
ENDPROC(__memcpy)
+EXPORT_SYMBOL(__memcpy)
diff --git a/arch/arm64/lib/memmove.S b/arch/arm64/lib/memmove.S
index a5a4459013b1..ef12f719d99d 100644
--- a/arch/arm64/lib/memmove.S
+++ b/arch/arm64/lib/memmove.S
@@ -197,4 +197,6 @@ ENTRY(memmove)
b.ne .Ltail63
ret
ENDPIPROC(memmove)
+EXPORT_SYMBOL(memmove)
ENDPROC(__memmove)
+EXPORT_SYMBOL(__memmove)
diff --git a/arch/arm64/lib/memset.S b/arch/arm64/lib/memset.S
index f2670a9f218c..a79cf118d6d0 100644
--- a/arch/arm64/lib/memset.S
+++ b/arch/arm64/lib/memset.S
@@ -216,4 +216,6 @@ ENTRY(memset)
b.ne .Ltail_maybe_long
ret
ENDPIPROC(memset)
+EXPORT_SYMBOL(memset)
ENDPROC(__memset)
+EXPORT_SYMBOL(__memset)
diff --git a/arch/arm64/lib/strchr.S b/arch/arm64/lib/strchr.S
index 7c83091d1bcd..b179421f46c7 100644
--- a/arch/arm64/lib/strchr.S
+++ b/arch/arm64/lib/strchr.S
@@ -40,3 +40,4 @@ WEAK(strchr)
csel x0, x0, xzr, eq
ret
ENDPROC(strchr)
+EXPORT_SYMBOL_NOKASAN(strchr)
diff --git a/arch/arm64/lib/strcmp.S b/arch/arm64/lib/strcmp.S
index 7d5d15398bfb..c306c7b88574 100644
--- a/arch/arm64/lib/strcmp.S
+++ b/arch/arm64/lib/strcmp.S
@@ -232,3 +232,4 @@ CPU_BE( orr syndrome, diff, has_nul )
sub result, data1, data2, lsr #56
ret
ENDPIPROC(strcmp)
+EXPORT_SYMBOL_NOKASAN(strcmp)
diff --git a/arch/arm64/lib/strlen.S b/arch/arm64/lib/strlen.S
index 8e0b14205dcb..2a0240937416 100644
--- a/arch/arm64/lib/strlen.S
+++ b/arch/arm64/lib/strlen.S
@@ -124,3 +124,4 @@ CPU_LE( lsr tmp2, tmp2, tmp1 ) /* Shift (tmp1 & 63). */
csel data2, data2, data2a, le
b .Lrealigned
ENDPIPROC(strlen)
+EXPORT_SYMBOL_NOKASAN(strlen)
diff --git a/arch/arm64/lib/strncmp.S b/arch/arm64/lib/strncmp.S
index 66bd145935d9..c5d567afb039 100644
--- a/arch/arm64/lib/strncmp.S
+++ b/arch/arm64/lib/strncmp.S
@@ -308,3 +308,4 @@ CPU_BE( orr syndrome, diff, has_nul )
mov result, #0
ret
ENDPIPROC(strncmp)
+EXPORT_SYMBOL_NOKASAN(strncmp)
diff --git a/arch/arm64/lib/strnlen.S b/arch/arm64/lib/strnlen.S
index 355be04441fe..e21e536d420e 100644
--- a/arch/arm64/lib/strnlen.S
+++ b/arch/arm64/lib/strnlen.S
@@ -169,3 +169,4 @@ CPU_LE( lsr tmp2, tmp2, tmp4 ) /* Shift (tmp1 & 63). */
mov len, limit
ret
ENDPIPROC(strnlen)
+EXPORT_SYMBOL_NOKASAN(strnlen)
diff --git a/arch/arm64/lib/strrchr.S b/arch/arm64/lib/strrchr.S
index ea84924d5990..47e1593016dc 100644
--- a/arch/arm64/lib/strrchr.S
+++ b/arch/arm64/lib/strrchr.S
@@ -41,3 +41,4 @@ WEAK(strrchr)
2: mov x0, x3
ret
ENDPIPROC(strrchr)
+EXPORT_SYMBOL_NOKASAN(strrchr)
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 07/10] arm64: uaccess: use asm EXPORT_SYMBOL()
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
For a while now it's been possible to use EXPORT_SYMBOL() in assembly
files, which allows us to place exports immediately after assembly
functions, as we do for C functions.
As a step towards removing arm64ksyms.c, let's move the uaccess exports
to the assembly files the functions are defined in. As we have to
include <asm/assembler.h>, the existing includes are fixed to follow the
usual ordering conventions.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/arm64ksyms.c | 7 -------
arch/arm64/lib/clear_user.S | 2 ++
arch/arm64/lib/copy_from_user.S | 4 +++-
arch/arm64/lib/copy_in_user.S | 4 +++-
arch/arm64/lib/copy_to_user.S | 4 +++-
5 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 784b257d9643..02019667e319 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -24,18 +24,11 @@
#include <linux/delay.h>
#include <linux/in6.h>
#include <linux/syscalls.h>
-#include <linux/uaccess.h>
#include <linux/io.h>
#include <linux/kprobes.h>
#include <asm/checksum.h>
- /* user mem (segment) */
-EXPORT_SYMBOL(__arch_copy_from_user);
-EXPORT_SYMBOL(__arch_copy_to_user);
-EXPORT_SYMBOL(__arch_clear_user);
-EXPORT_SYMBOL(__arch_copy_in_user);
-
/* string / mem functions */
#ifndef CONFIG_KASAN
EXPORT_SYMBOL(strchr);
diff --git a/arch/arm64/lib/clear_user.S b/arch/arm64/lib/clear_user.S
index 21ba0b29621b..feb225bd4b80 100644
--- a/arch/arm64/lib/clear_user.S
+++ b/arch/arm64/lib/clear_user.S
@@ -18,6 +18,7 @@
#include <linux/linkage.h>
#include <asm/asm-uaccess.h>
+#include <asm/assembler.h>
.text
@@ -53,6 +54,7 @@ uao_user_alternative 9f, strb, sttrb, wzr, x0, 0
uaccess_disable_not_uao x2, x3
ret
ENDPROC(__arch_clear_user)
+EXPORT_SYMBOL(__arch_clear_user)
.section .fixup,"ax"
.align 2
diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index 20305d485046..dea6c762d52f 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -16,8 +16,9 @@
#include <linux/linkage.h>
-#include <asm/cache.h>
#include <asm/asm-uaccess.h>
+#include <asm/assembler.h>
+#include <asm/cache.h>
/*
* Copy from user space to a kernel buffer (alignment handled by the hardware)
@@ -71,6 +72,7 @@ ENTRY(__arch_copy_from_user)
mov x0, #0 // Nothing to copy
ret
ENDPROC(__arch_copy_from_user)
+EXPORT_SYMBOL(__arch_copy_from_user)
.section .fixup,"ax"
.align 2
diff --git a/arch/arm64/lib/copy_in_user.S b/arch/arm64/lib/copy_in_user.S
index 54b75deb1d16..a84227fbf716 100644
--- a/arch/arm64/lib/copy_in_user.S
+++ b/arch/arm64/lib/copy_in_user.S
@@ -18,8 +18,9 @@
#include <linux/linkage.h>
-#include <asm/cache.h>
#include <asm/asm-uaccess.h>
+#include <asm/assembler.h>
+#include <asm/cache.h>
/*
* Copy from user space to user space (alignment handled by the hardware)
@@ -73,6 +74,7 @@ ENTRY(__arch_copy_in_user)
mov x0, #0
ret
ENDPROC(__arch_copy_in_user)
+EXPORT_SYMBOL(__arch_copy_in_user)
.section .fixup,"ax"
.align 2
diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
index fda6172d6b88..ef44c7ca3ffb 100644
--- a/arch/arm64/lib/copy_to_user.S
+++ b/arch/arm64/lib/copy_to_user.S
@@ -16,8 +16,9 @@
#include <linux/linkage.h>
-#include <asm/cache.h>
#include <asm/asm-uaccess.h>
+#include <asm/assembler.h>
+#include <asm/cache.h>
/*
* Copy to user space from a kernel buffer (alignment handled by the hardware)
@@ -70,6 +71,7 @@ ENTRY(__arch_copy_to_user)
mov x0, #0
ret
ENDPROC(__arch_copy_to_user)
+EXPORT_SYMBOL(__arch_copy_to_user)
.section .fixup,"ax"
.align 2
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 10/10] arm64: remove arm64ksyms.c
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
Now that arm64ksyms.c has been reduced to a stub, let's remove it
entirely. New exports should be associated with their function
definition.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/Makefile | 2 +-
arch/arm64/kernel/arm64ksyms.c | 30 ------------------------------
2 files changed, 1 insertion(+), 31 deletions(-)
delete mode 100644 arch/arm64/kernel/arm64ksyms.c
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 4c8b13bede80..e069f957ec28 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -30,7 +30,7 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE
arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
sys_compat.o
arm64-obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o entry-ftrace.o
-arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
+arm64-obj-$(CONFIG_MODULES) += module.o
arm64-obj-$(CONFIG_ARM64_MODULE_PLTS) += module-plts.o
arm64-obj-$(CONFIG_PERF_EVENTS) += perf_regs.o perf_callchain.o
arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
deleted file mode 100644
index 4ca8d2b245d2..000000000000
--- a/arch/arm64/kernel/arm64ksyms.c
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * Based on arch/arm/kernel/armksyms.c
- *
- * Copyright (C) 2000 Russell King
- * Copyright (C) 2012 ARM Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/export.h>
-#include <linux/sched.h>
-#include <linux/cryptohash.h>
-#include <linux/delay.h>
-#include <linux/in6.h>
-#include <linux/syscalls.h>
-#include <linux/io.h>
-#include <linux/kprobes.h>
-
-#include <asm/checksum.h>
-
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv2 09/10] arm64: frace: use asm EXPORT_SYMBOL()
From: Mark Rutland @ 2018-12-07 18:08 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: mark.rutland, catalin.marinas, will.deacon
In-Reply-To: <20181207180823.36612-1-mark.rutland@arm.com>
For a while now it's been possible to use EXPORT_SYMBOL() in assembly
files, which allows us to place exports immediately after assembly
functions, as we do for C functions.
As a step towards removing arm64ksyms.c, let's move the ftrace exports
to the assembly files the functions are defined in.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/arm64ksyms.c | 5 -----
arch/arm64/kernel/entry-ftrace.S | 4 ++++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index c142103bc0fe..4ca8d2b245d2 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -28,8 +28,3 @@
#include <asm/checksum.h>
-#ifdef CONFIG_FUNCTION_TRACER
-EXPORT_SYMBOL(_mcount);
-NOKPROBE_SYMBOL(_mcount);
-#endif
-
diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
index 032e24d2d554..81b8eb5c4633 100644
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -120,6 +120,8 @@ skip_ftrace_call: // }
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
mcount_exit
ENDPROC(_mcount)
+EXPORT_SYMBOL(_mcount)
+NOKPROBE(_mcount)
#else /* CONFIG_DYNAMIC_FTRACE */
/*
@@ -131,6 +133,8 @@ ENDPROC(_mcount)
ENTRY(_mcount)
ret
ENDPROC(_mcount)
+EXPORT_SYMBOL(_mcount)
+NOKPROBE(_mcount)
/*
* void ftrace_caller(unsigned long return_address)
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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