* [PATCH v3 2/3] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver
From: Igal Liberman @ 2017-04-24 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424075407.19730-3-antoine.tenart@free-electrons.com>
[...]
> + priv->clk = of_clk_get(dev->of_node, 0);
> + if (!IS_ERR(priv->clk)) {
> + ret = clk_prepare_enable(priv->clk);
> + if (ret) {
> + dev_err(dev, "unable to enable clk (%d)\n", ret);
> + return ret;
> + }
> + } else {
> + /* The clock isn't mandatory */
> + if (PTR_ERR(priv->clk) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + }
> +
> + ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
The correct address width of the engine in Marvell SoCs is 40bit.
> + if (ret)
> + goto err_clk;
> +
> + priv->context_pool = dmam_pool_create("safexcel-context", dev,
> + sizeof(struct
> safexcel_context_record),
> + 1, 0);
> + if (!priv->context_pool) {
> + ret = -ENOMEM;
> + goto err_clk;
> + }
> +
Thanks,
Igal
^ permalink raw reply
* [PATCH v5 02/11] clk: sunxi-ng: add support for DE2 CCU
From: Maxime Ripard @ 2017-04-24 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170423103754.50012-3-icenowy@aosc.io>
Hi,
On Sun, Apr 23, 2017 at 06:37:45PM +0800, Icenowy Zheng wrote:
> +static const struct of_device_id sunxi_de2_clk_ids[] = {
> + {
> + .compatible = "allwinner,sun8i-a83t-de2-clk",
> + .data = &sun8i_a83t_de2_clk_desc,
> + },
> + {
> + .compatible = "allwinner,sun50i-h5-de2-clk",
> + .data = &sun50i_a64_de2_clk_desc,
> + },
> + /*
> + * The Allwinner A64 SoC needs some bit to be poke in syscon to make
> + * DE2 really working.
> + * So there's currently no A64 compatible here.
> + * H5 shares the same reset line with A64, so here H5 is using the
> + * clock description of A64.
> + */
> + { }
> +};
So that A64 driver would require more than just what you defined in
the binding in order to operate?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170424/f955f91c/attachment-0001.sig>
^ permalink raw reply
* [PATCH] arm64: dts: r8a7795: update PFC node name to pin-controller
From: Simon Horman @ 2017-04-24 8:51 UTC (permalink / raw)
To: linux-arm-kernel
The device trees for Renesas SoCs use either pfc or pin-controller
as the node name for the PFC device. This patch is intended to take a step
towards unifying the node name used as pin-controller which appears to
be more the more generic of the two and thus more in keeping with the DT
specs.
My analysis is that this is a user-visible change to the extent that kernel
logs, and sysfs entries change from e6060000.pfc and pfc at e6060000 to
e6060000.pin-controller and pin-controller at e6060000.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Before:
/sys/kernel/debug/pinctrl/e6060000.pfc
/sys/devices/platform/soc/e6060000.pfc
/sys/firmware/devicetree/base/soc/pfc at e6060000
/sys/bus/platform/devices/e6060000.pfc
/sys/bus/platform/drivers/sh-pfc
/sys/bus/platform/drivers/sh-pfc/e6060000.pfc
After:
/sys/kernel/debug/pinctrl/e6060000.pin-controller
/sys/devices/platform/soc/e6060000.pin-controller
/sys/firmware/devicetree/base/soc/pin-controller at e6060000
/sys/bus/platform/devices/e6060000.pin-controller
/sys/bus/platform/drivers/sh-pfc
/sys/bus/platform/drivers/sh-pfc/e6060000.pin-controller
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index e99d6443b3e4..7d87dff70ac8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -398,7 +398,7 @@
#power-domain-cells = <1>;
};
- pfc: pfc at e6060000 {
+ pfc: pin-controller at e6060000 {
compatible = "renesas,pfc-r8a7795";
reg = <0 0xe6060000 0 0x50c>;
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v3 2/3] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver
From: Antoine Tenart @ 2017-04-24 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ff65d6a5e5e4d388d3c5a384e4f5fd6@IL-EXCH01.marvell.com>
Hi Igal,
On Mon, Apr 24, 2017 at 08:50:32AM +0000, Igal Liberman wrote:
> [...]
>
> > + priv->clk = of_clk_get(dev->of_node, 0);
> > + if (!IS_ERR(priv->clk)) {
> > + ret = clk_prepare_enable(priv->clk);
> > + if (ret) {
> > + dev_err(dev, "unable to enable clk (%d)\n", ret);
> > + return ret;
> > + }
> > + } else {
> > + /* The clock isn't mandatory */
> > + if (PTR_ERR(priv->clk) == -EPROBE_DEFER)
> > + return -EPROBE_DEFER;
> > + }
> > +
> > + ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
>
> The correct address width of the engine in Marvell SoCs is 40bit.
Oops. I'll update.
Thanks!
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170424/4f99b7e5/attachment.sig>
^ permalink raw reply
* [PATCH V3 2/2] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd
From: Lee Jones @ 2017-04-24 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <370c36f9-e6fc-416c-776b-edc1e42d7ddc@linaro.org>
On Sat, 22 Apr 2017, Daniel Lezcano wrote:
> On 22/04/2017 04:02, Stephen Boyd wrote:
> > On 04/17, Daniel Lezcano wrote:
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >> ---
> >> Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++++++
> >> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
> >> 2 files changed, 7 insertions(+)
> >>
> >
> > I take it this goes through arm-soc? Not sure why I'm on To:
> > line.
>
> Probably it should go through Lee's tree.
Unlikely.
The document and the DTS change should really have gone separately,
but to save you from having to mess around so close to the merge window:
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] arm64: dts: r8a7795: update PFC node name to pin-controller
From: Geert Uytterhoeven @ 2017-04-24 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493023915-21658-1-git-send-email-horms+renesas@verge.net.au>
On Mon, Apr 24, 2017 at 10:51 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> The device trees for Renesas SoCs use either pfc or pin-controller
> as the node name for the PFC device. This patch is intended to take a step
> towards unifying the node name used as pin-controller which appears to
> be more the more generic of the two and thus more in keeping with the DT
s/be more/be/
> specs.
>
> My analysis is that this is a user-visible change to the extent that kernel
> logs, and sysfs entries change from e6060000.pfc and pfc at e6060000 to
> e6060000.pin-controller and pin-controller at e6060000.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/3] ARM: dts: at91: sama5d2_xplained: enable ADTRG pin
From: Ludovic Desroches @ 2017-04-24 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492590045-17329-2-git-send-email-eugen.hristev@microchip.com>
On Wed, Apr 19, 2017 at 11:20:43AM +0300, Eugen Hristev wrote:
> Enable pinctrl for ADTRG pin (PD31) for ADC hardware trigger support.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> ---
> arch/arm/boot/dts/at91-sama5d2_xplained.dts | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> index 0bef9e0..04754b1 100644
> --- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> @@ -303,7 +303,7 @@
> vddana-supply = <&vdd_3v3_lp_reg>;
> vref-supply = <&vdd_3v3_lp_reg>;
> pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_adc_default>;
> + pinctrl-0 = <&pinctrl_adc_default &pinctrl_adtrg_default>;
> status = "okay";
> };
>
> @@ -322,6 +322,20 @@
> bias-disable;
> };
>
> + /*
> + * The ADTRG pin can work on any edge type.
> + * In here it's being pulled up, so need to
> + * connect it to ground to get an edge e.g.
> + * Trigger can be configured on falling, rise
> + * or any edge, and the pull-up can be changed
> + * to pull-down or left floating according to
> + * needs.
> + */
> + pinctrl_adtrg_default: adtrg_default {
> + pinmux = <PIN_PD31__ADTRG>;
> + bias-pull-up;
> + };
> +
> pinctrl_charger_chglev: charger_chglev {
> pinmux = <PIN_PA12__GPIO>;
> bias-disable;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v5 05/11] drm/sun4i: abstract a engine type
From: Maxime Ripard @ 2017-04-24 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170423103754.50012-6-icenowy@aosc.io>
Hi,
Thanks a lot for that work.
On Sun, Apr 23, 2017 at 06:37:48PM +0800, Icenowy Zheng wrote:
> As we are going to add support for the Allwinner DE2 engine in sun4i-drm
> driver, we will finally have two types of display engines -- the DE1
> backend and the DE2 mixer. They both do some display blending and feed
> graphics data to TCON, so I choose to call them both "engine" here.
>
> Abstract the engine type to a new struct with an ops struct, which contains
> functions that should be called outside the engine-specified code (in
> TCON, CRTC or TV Encoder code).
>
> A dedicated Kconfig option is also added to control whether
> sun4i-backend-specified code (sun4i_backend.c and sun4i_layer.c) should
> be built. As we removed the codes in CRTC code that directly call the
> layer code, we can now extract the layer part and combine it with the
> backend part into a new module, sun4i-backend.ko.
While the code itself is good now, the patch mixes a few things that
would be better to be split in separate patches. I think it would be
better if you had patches organized like this:
- Abstract the engine type by create the sunxi_engine structure and
fixing all the callers.
- Move the layers and backend files in the same module, and remove
the now useless EXPORT_SYMBOLS.
- Create a Kconfig option.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170424/d1d15dd2/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/3] iio: adc: at91-sama5d2_adc: add hw trigger and buffer support
From: Ludovic Desroches @ 2017-04-24 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492590045-17329-3-git-send-email-eugen.hristev@microchip.com>
On Wed, Apr 19, 2017 at 11:20:44AM +0300, Eugen Hristev wrote:
> Added support for the external hardware trigger on pin ADTRG,
> integrated the three possible edge triggers into the subsystem
> and created buffer management for data retrieval
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> ---
> drivers/iio/adc/at91-sama5d2_adc.c | 207 ++++++++++++++++++++++++++++++++++++-
> 1 file changed, 204 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c
> index e10dca3..09a8c3d 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -23,8 +23,15 @@
> #include <linux/platform_device.h>
> #include <linux/sched.h>
> #include <linux/wait.h>
> +#include <linux/slab.h>
> +
> #include <linux/iio/iio.h>
> #include <linux/iio/sysfs.h>
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/trigger.h>
> +#include <linux/iio/trigger_consumer.h>
> +#include <linux/iio/triggered_buffer.h>
> +
> #include <linux/regulator/consumer.h>
>
> /* Control Register */
> @@ -132,6 +139,17 @@
> #define AT91_SAMA5D2_PRESSR 0xbc
> /* Trigger Register */
> #define AT91_SAMA5D2_TRGR 0xc0
> +/* Mask for TRGMOD field of TRGR register */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_MASK GENMASK(2, 0)
> +/* No trigger, only software trigger can start conversions */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_NO_TRIGGER 0
> +/* Trigger Mode external trigger rising edge */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_RISE 1
> +/* Trigger Mode external trigger falling edge */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL 2
> +/* Trigger Mode external trigger any edge */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY 3
> +
> /* Correction Select Register */
> #define AT91_SAMA5D2_COSR 0xd0
> /* Correction Value Register */
> @@ -145,14 +163,20 @@
> /* Version Register */
> #define AT91_SAMA5D2_VERSION 0xfc
>
> +#define AT91_SAMA5D2_HW_TRIG_CNT 3
> +#define AT91_SAMA5D2_SINGLE_CHAN_CNT 12
> +#define AT91_SAMA5D2_DIFF_CHAN_CNT 6
> +
> #define AT91_SAMA5D2_CHAN_SINGLE(num, addr) \
> { \
> .type = IIO_VOLTAGE, \
> .channel = num, \
> .address = addr, \
> + .scan_index = num, \
> .scan_type = { \
> .sign = 'u', \
> .realbits = 12, \
> + .storagebits = 16, \
> }, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> @@ -168,9 +192,11 @@
> .channel = num, \
> .channel2 = num2, \
> .address = addr, \
> + .scan_index = num + AT91_SAMA5D2_SINGLE_CHAN_CNT, \
> .scan_type = { \
> .sign = 's', \
> .realbits = 12, \
> + .storagebits = 16, \
> }, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> @@ -188,18 +214,26 @@ struct at91_adc_soc_info {
> unsigned max_sample_rate;
> };
>
> +struct at91_adc_trigger {
> + char *name;
> + unsigned int trgmod_value;
> +};
> +
> struct at91_adc_state {
> void __iomem *base;
> int irq;
> struct clk *per_clk;
> struct regulator *reg;
> struct regulator *vref;
> + u16 *buffer;
> int vref_uv;
> const struct iio_chan_spec *chan;
> bool conversion_done;
> u32 conversion_value;
> struct at91_adc_soc_info soc_info;
> wait_queue_head_t wq_data_available;
> + struct iio_trigger **trig;
> + const struct at91_adc_trigger *trigger_list;
> /*
> * lock to prevent concurrent 'single conversion' requests through
> * sysfs.
> @@ -207,6 +241,21 @@ struct at91_adc_state {
> struct mutex lock;
> };
>
> +static const struct at91_adc_trigger at91_adc_trigger_list[] = {
> + {
> + .name = "external-rising",
> + .trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_RISE,
> + },
> + {
> + .name = "external-falling",
> + .trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL,
> + },
> + {
> + .name = "external-any",
> + .trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY,
> + },
> +};
> +
> static const struct iio_chan_spec at91_adc_channels[] = {
> AT91_SAMA5D2_CHAN_SINGLE(0, 0x50),
> AT91_SAMA5D2_CHAN_SINGLE(1, 0x54),
> @@ -226,8 +275,141 @@ static const struct iio_chan_spec at91_adc_channels[] = {
> AT91_SAMA5D2_CHAN_DIFF(6, 7, 0x68),
> AT91_SAMA5D2_CHAN_DIFF(8, 9, 0x70),
> AT91_SAMA5D2_CHAN_DIFF(10, 11, 0x78),
> + IIO_CHAN_SOFT_TIMESTAMP(AT91_SAMA5D2_SINGLE_CHAN_CNT
> + + AT91_SAMA5D2_DIFF_CHAN_CNT + 1),
> };
>
> +static int at91_adc_configure_trigger(struct iio_trigger *trig, bool state)
> +{
> + struct iio_dev *indio = iio_trigger_get_drvdata(trig);
> + struct at91_adc_state *st = iio_priv(indio);
> + u32 status = at91_adc_readl(st, AT91_SAMA5D2_TRGR);
> + u8 bit;
> + int i;
> +
> + /* clear TRGMOD */
> + status &= ~AT91_SAMA5D2_TRGR_TRGMOD_MASK;
> +
> + /* if we are disabling the trigger, it's enough to clear TRGMOD */
> + if (!state) {
> + at91_adc_writel(st, AT91_SAMA5D2_TRGR, status);
> + kfree(st->buffer);
> + return 0;
> + }
> +
> + st->buffer = kmalloc(indio->scan_bytes, GFP_KERNEL);
> + if (!st->buffer)
> + return -ENOMEM;
> +
> + for (i = 0; i < AT91_SAMA5D2_HW_TRIG_CNT; i++) {
> + if (!strstr(trig->name, st->trigger_list[i].name)) {
> + status |= st->trigger_list[i].trgmod_value;
> + break;
> + }
> + }
> +
> + /* setup hw trigger */
> + at91_adc_writel(st, AT91_SAMA5D2_TRGR, status);
> +
> + for_each_set_bit(bit, indio->active_scan_mask, indio->num_channels) {
> + struct iio_chan_spec const *chan = indio->channels + bit;
> +
> + at91_adc_writel(st, AT91_SAMA5D2_CHER, BIT(chan->channel));
> + at91_adc_writel(st, AT91_SAMA5D2_IER, BIT(chan->channel));
> + }
> +
> + return 0;
> +}
> +
> +static const struct iio_trigger_ops at91_adc_trigger_ops = {
> + .owner = THIS_MODULE,
> + .set_trigger_state = &at91_adc_configure_trigger,
> +};
> +
> +static struct iio_trigger *at91_adc_allocate_trigger(struct iio_dev *indio,
> + char *trigger_name)
> +{
> + struct iio_trigger *trig;
> + int ret;
> +
> + trig = devm_iio_trigger_alloc(&indio->dev, "%s-dev%d-%s", indio->name,
> + indio->id, trigger_name);
> + if (!trig)
> + return NULL;
> +
> + trig->dev.parent = indio->dev.parent;
> + iio_trigger_set_drvdata(trig, indio);
> + trig->ops = &at91_adc_trigger_ops;
> +
> + ret = devm_iio_trigger_register(&indio->dev, trig);
> +
> + if (ret)
> + return NULL;
> +
> + return trig;
> +}
> +
> +static int at91_adc_trigger_init(struct iio_dev *indio)
> +{
> + struct at91_adc_state *st = iio_priv(indio);
> + int i;
> +
> + st->trig = devm_kzalloc(&indio->dev,
> + AT91_SAMA5D2_HW_TRIG_CNT * sizeof(*st->trig),
> + GFP_KERNEL);
> +
> + if (!st->trig) {
> + dev_err(&indio->dev, "could not allocate trig list memory\n");
> + return -ENOMEM;
> + }
> +
> + for (i = 0; i < AT91_SAMA5D2_HW_TRIG_CNT; i++) {
> + st->trig[i] = at91_adc_allocate_trigger(indio,
> + st->trigger_list[i].name);
> + if (!st->trig[i]) {
> + dev_err(&indio->dev,
> + "could not allocate trigger %d\n", i);
> + return -ENOMEM;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio = pf->indio_dev;
> + struct at91_adc_state *st = iio_priv(indio);
> + int i = 0;
> + u8 bit;
> +
> + for_each_set_bit(bit, indio->active_scan_mask, indio->num_channels) {
> + struct iio_chan_spec const *chan = indio->channels + bit;
> +
> + st->buffer[i] = at91_adc_readl(st, chan->address);
> + i++;
> + }
> +
> + iio_push_to_buffers_with_timestamp(indio, st->buffer, pf->timestamp);
> +
> + iio_trigger_notify_done(indio->trig);
> +
> + /* Needed to ACK the DRDY interruption */
> + at91_adc_readl(st, AT91_SAMA5D2_LCDR);
> +
> + enable_irq(st->irq);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int at91_adc_buffer_init(struct iio_dev *indio)
> +{
> + return devm_iio_triggered_buffer_setup(&indio->dev, indio,
> + &iio_pollfunc_store_time,
> + &at91_adc_trigger_handler, NULL);
> +}
> +
> static unsigned at91_adc_startup_time(unsigned startup_time_min,
> unsigned adc_clk_khz)
> {
> @@ -293,14 +475,19 @@ static irqreturn_t at91_adc_interrupt(int irq, void *private)
> u32 status = at91_adc_readl(st, AT91_SAMA5D2_ISR);
> u32 imr = at91_adc_readl(st, AT91_SAMA5D2_IMR);
>
> - if (status & imr) {
> + if (!(status & imr))
> + return IRQ_NONE;
> +
> + if (iio_buffer_enabled(indio)) {
> + disable_irq_nosync(irq);
> + iio_trigger_poll(indio->trig);
> + } else {
> st->conversion_value = at91_adc_readl(st, st->chan->address);
> st->conversion_done = true;
> wake_up_interruptible(&st->wq_data_available);
> - return IRQ_HANDLED;
> }
>
> - return IRQ_NONE;
> + return IRQ_HANDLED;
> }
>
> static int at91_adc_read_raw(struct iio_dev *indio_dev,
> @@ -406,6 +593,8 @@ static int at91_adc_probe(struct platform_device *pdev)
>
> st = iio_priv(indio_dev);
>
> + st->trigger_list = at91_adc_trigger_list;
> +
> ret = of_property_read_u32(pdev->dev.of_node,
> "atmel,min-sample-rate-hz",
> &st->soc_info.min_sample_rate);
> @@ -499,6 +688,18 @@ static int at91_adc_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, indio_dev);
>
> + ret = at91_adc_buffer_init(indio_dev);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "couldn't initialize the buffer.\n");
> + goto per_clk_disable_unprepare;
> + }
> +
> + ret = at91_adc_trigger_init(indio_dev);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "couldn't setup the triggers.\n");
> + goto per_clk_disable_unprepare;
> + }
> +
> ret = iio_device_register(indio_dev);
> if (ret < 0)
> goto per_clk_disable_unprepare;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v5 09/11] ARM: dts: sun8i: add DE2 nodes for V3s SoC
From: Maxime Ripard @ 2017-04-24 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170423103754.50012-10-icenowy@aosc.io>
On Sun, Apr 23, 2017 at 06:37:52PM +0800, Icenowy Zheng wrote:
> + tcon0_out: port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + };
> + };
> + };
> +
> +
There's one too many newline here.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170424/64cab28a/attachment.sig>
^ permalink raw reply
* [PATCH v3 15/18] arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled
From: Hanjun Guo @ 2017-04-24 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <493e2b26-96a2-4b92-fd4b-f6f7d5c89fb5@arm.com>
On 2017/4/24 16:40, Marc Zyngier wrote:
> On 24/04/17 09:25, Lixiaoping (Timmy) wrote:
>> Hi Marc,
>>
>> Sorry about previous email's confidential info. Please forget it.
>>
>> +#define ESR_ELx_SYS64_ISS_SYS_CNTFRQ (ESR_ELx_SYS64_ISS_SYS_VAL(3, 3, 14, 0, 0) | \
>> + ESR_ELx_SYS64_ISS_DIR_READ)
>>
>> I think (3, 3, 14, 0, 0) should be (3, 3, 0, 14, 0)?
> Thanks for spotting this. I assumed that the sys_reg() and
> SR_ELx_SYS64_ISS_SYS_VAL() macros took their arguments in the same
> order. That would have been too easy... ;-)
>
> Amended patch below, please let me know if it works for you.
>
> Thanks,
>
> M.
>
> >From 4444c86a97c1a487e12c319fdc197c88631d72b5 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <marc.zyngier@arm.com>
> Date: Mon, 24 Apr 2017 09:04:03 +0100
> Subject: [PATCH] arm64: Add CNTFRQ_EL0 trap handler
>
> We now trap accesses to CNTVCT_EL0 when the counter is broken
> enough to require the kernel to mediate the access. But it
> turns out that some existing userspace (such as OpenMPI) do
> probe for the counter frequency, leading to an UNDEF exception
> as CNTVCT_EL0 and CNTFRQ_EL0 share the same control bit.
>
> The fix is to handle the exception the same way we do for CNTVCT_EL0.
>
> Fixes: a86bd139f2ae ("arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled")
> Reported-by: Hanjun Guo <guohanjun@huawei.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
I tested this patch and the undefined instruction error is gone, I can
get the FREQ in the user space now, thank you very much for the quick
response.
Tested-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Thanks
Hanjun
^ permalink raw reply
* [PATCH v5 1/4] gpio: mvebu: Add limited PWM support
From: Linus Walleij @ 2017-04-24 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421111952.54978e80@free-electrons.com>
On Fri, Apr 21, 2017 at 11:19 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> I clearly don't want to block this, but I believe this is a very good
> illustration of why stable DT bindings simply don't work. We are
> realizing here that having each GPIO bank represented as a separate DT
> node doesn't work, because this blinking functionality is not per GPIO
> bank, but global to all GPIO banks.
>
> I am totally fine with compromise, and having things simple first, and
> extend them later if needed. But this stable DT binding rule makes this
> quite impossible: what is a compromise today might put you in big
> troubles tomorrow.
Really "stable bindings" I never believed in. It's just a pipe dream.
Well they might become stable when the system is "finished"
whenever that happens.
I think a better rationale is that of the IETF:
"rough consensus and running code", make deployed DTs work,
if they are not deployed, or only getting deployed together with the
kernel, changing the bindings are not a problem.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: update cpu opp table for rk3399 op1
From: Heiko Stübner @ 2017-04-24 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f4c389af-5b1f-9197-0df4-f8407ed8622a@rock-chips.com>
Am Montag, 24. April 2017, 16:49:08 CEST schrieb Caesar Wang:
> ? 2017?04?24? 16:26, Heiko St?bner ??:
> > Hi Caesar,
> >
> > Am Montag, 24. April 2017, 14:18:50 CEST schrieb Caesar Wang:
> >> Update the cpu opp table for rk3399 op1.
> >
> > Ideally this should contain something about the "why".
> > Are these new voltage settings safer to operate under?
>
> The before opp table is for earlier batch of rk3399 SoCs, that's no
> enough for the current and
> newer batch of rk3399 op1. In order to suit for the rk3399 op1, we need
> to little voltages changed.
just to make sure, this is also safe for all the non-chromebook rk3399 socs
(like the firefly and tv-boxes, etc), right?
Thanks
Heiko
^ permalink raw reply
* [PATCH V3 2/2] ARM64: dts: hi6220-hikey: Add clock binding for the pmic mfd
From: Daniel Lezcano @ 2017-04-24 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424085944.aa5dsc4g6bwm5rgi@dell>
On Mon, Apr 24, 2017 at 09:59:44AM +0100, Lee Jones wrote:
> On Sat, 22 Apr 2017, Daniel Lezcano wrote:
>
> > On 22/04/2017 04:02, Stephen Boyd wrote:
> > > On 04/17, Daniel Lezcano wrote:
> > >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > >> ---
> > >> Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 ++++++
> > >> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
> > >> 2 files changed, 7 insertions(+)
> > >>
> > >
> > > I take it this goes through arm-soc? Not sure why I'm on To:
> > > line.
> >
> > Probably it should go through Lee's tree.
>
> Unlikely.
>
> The document and the DTS change should really have gone separately,
> but to save you from having to mess around so close to the merge window:
>
> Acked-by: Lee Jones <lee.jones@linaro.org>
Thanks Lee.
Usually, I take the DT changes (including doc) with the timers changes with the
maintainer and Rob's blessing. So the DT and the driver changes are aligned in
my tree and make the submission changes easier.
I agree mixing the patches for different destinations into a single patchset is
fuzzy, I will take care next time to separate the patches.
-- Daniel
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH v3 15/18] arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled
From: Daniel Lezcano @ 2017-04-24 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58FDC1F5.3000401@huawei.com>
On Mon, Apr 24, 2017 at 05:14:29PM +0800, Hanjun Guo wrote:
> On 2017/4/24 16:40, Marc Zyngier wrote:
> > On 24/04/17 09:25, Lixiaoping (Timmy) wrote:
> >> Hi Marc,
> >>
> >> Sorry about previous email's confidential info. Please forget it.
> >>
> >> +#define ESR_ELx_SYS64_ISS_SYS_CNTFRQ (ESR_ELx_SYS64_ISS_SYS_VAL(3, 3, 14, 0, 0) | \
> >> + ESR_ELx_SYS64_ISS_DIR_READ)
> >>
> >> I think (3, 3, 14, 0, 0) should be (3, 3, 0, 14, 0)?
> > Thanks for spotting this. I assumed that the sys_reg() and
> > SR_ELx_SYS64_ISS_SYS_VAL() macros took their arguments in the same
> > order. That would have been too easy... ;-)
> >
> > Amended patch below, please let me know if it works for you.
> >
> > Thanks,
> >
> > M.
> >
> > >From 4444c86a97c1a487e12c319fdc197c88631d72b5 Mon Sep 17 00:00:00 2001
> > From: Marc Zyngier <marc.zyngier@arm.com>
> > Date: Mon, 24 Apr 2017 09:04:03 +0100
> > Subject: [PATCH] arm64: Add CNTFRQ_EL0 trap handler
> >
> > We now trap accesses to CNTVCT_EL0 when the counter is broken
> > enough to require the kernel to mediate the access. But it
> > turns out that some existing userspace (such as OpenMPI) do
> > probe for the counter frequency, leading to an UNDEF exception
> > as CNTVCT_EL0 and CNTFRQ_EL0 share the same control bit.
> >
> > The fix is to handle the exception the same way we do for CNTVCT_EL0.
> >
> > Fixes: a86bd139f2ae ("arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled")
> > Reported-by: Hanjun Guo <guohanjun@huawei.com>
> > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> > ---
>
> I tested this patch and the undefined instruction error is gone, I can
> get the FREQ in the user space now, thank you very much for the quick
> response.
>
> Tested-by: Hanjun Guo <guohanjun@huawei.com>
> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Thanks for providing so quickly a fix and test it.
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH v6 1/4] gpio: mvebu: Add limited PWM support
From: Linus Walleij @ 2017-04-24 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414154056.32055-2-ralph.sennhauser@gmail.com>
On Fri, Apr 14, 2017 at 5:40 PM, Ralph Sennhauser
<ralph.sennhauser@gmail.com> wrote:
> From: Andrew Lunn <andrew@lunn.ch>
>
> Armada 370/XP devices can 'blink' GPIO lines with a configurable on
> and off period. This can be modelled as a PWM.
>
> However, there are only two sets of PWM configuration registers for
> all the GPIO lines. This driver simply allows a single GPIO line per
> GPIO chip of 32 lines to be used as a PWM. Attempts to use more return
> EBUSY.
>
> Due to the interleaving of registers it is not simple to separate the
> PWM driver from the GPIO driver. Thus the GPIO driver has been
> extended with a PWM driver.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> URL: https://patchwork.ozlabs.org/patch/427287/
> URL: https://patchwork.ozlabs.org/patch/427295/
> [Ralph Sennhauser:
> * Port forward
> * Merge PWM portion into gpio-mvebu.c
> * Switch to atomic PWM API
> * Add new compatible string marvell,armada-370-xp-gpio
> * Update and merge documentation patch
> * Update MAINTAINERS]
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
> Acked-by: Thierry Reding <thierry.reding@gmail.com>
> Acked-by: Rob Herring <robh@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v6 2/4] ARM: dts: mvebu: Add PWM properties to .dtsi files
From: Linus Walleij @ 2017-04-24 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414154056.32055-3-ralph.sennhauser@gmail.com>
On Fri, Apr 14, 2017 at 5:40 PM, Ralph Sennhauser
<ralph.sennhauser@gmail.com> wrote:
> From: Andrew Lunn <andrew@lunn.ch>
>
> Add properties to the GPIO nodes to allow them to be also used as PWM
> lines.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> URL: https://patchwork.ozlabs.org/patch/427294/
> [Ralph Sennhauser: Add new compatible string marvell,armada-370-xp-gpio]
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Please funnel this through ARM SoC.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v6 3/4] ARM: mvebu: Enable SENSORS_PWM_FAN in defconfig
From: Linus Walleij @ 2017-04-24 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414154056.32055-4-ralph.sennhauser@gmail.com>
On Fri, Apr 14, 2017 at 5:40 PM, Ralph Sennhauser
<ralph.sennhauser@gmail.com> wrote:
> From: Andrew Lunn <andrew@lunn.ch>
>
> Now that the GPIO driver also supports PWM operation, enable the PWM
> framework and fan driver in mvebu_v7_defconfig.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> URL: https://patchwork.ozlabs.org/patch/427297/
> [Ralph Sennhauser: add fan driver to defconfig]
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Please funnel this through ARM SoC.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v6 4/4] ARM: dts: armada-xp: Use pwm-fan rather than gpio-fan
From: Linus Walleij @ 2017-04-24 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414154056.32055-5-ralph.sennhauser@gmail.com>
On Fri, Apr 14, 2017 at 5:40 PM, Ralph Sennhauser
<ralph.sennhauser@gmail.com> wrote:
> From: Andrew Lunn <andrew@lunn.ch>
>
> The mvebu GPIO driver can also perform PWM on some pins. Use the pwm-fan
> driver to control the fan of the WRT1900AC, giving us finer grained control
> over its speed and hence noise.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> URL: https://patchwork.ozlabs.org/patch/427291/
> [Ralph Sennhauser: drop flags paramter from pwms, no longer used]
> Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Please funnel this through ARM SoC.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm64: fix the overlap between the kernel image and vmalloc address
From: zhongjiang @ 2017-04-24 9:22 UTC (permalink / raw)
To: linux-arm-kernel
From: zhong jiang <zhongjiang@huawei.com>
Recently, xiaojun report the following issue.
[ 4544.984139] Unable to handle kernel paging request at virtual address ffff804392800000
[ 4544.991995] pgd = ffff80096745f000
[ 4544.995369] [ffff804392800000] *pgd=0000000000000000
[ 4545.000297] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 4545.005815] Modules linked in:
[ 4545.008843] CPU: 1 PID: 8976 Comm: cat Not tainted 4.11.0-rc6 #1
[ 4545.014790] Hardware name: ARM Juno development board (r1) (DT)
[ 4545.020653] task: ffff8009753fdb00 task.stack: ffff80097533c000
[ 4545.026520] PC is at __memcpy+0x100/0x180
[ 4545.030491] LR is at vread+0x144/0x280
[ 4545.034202] pc : [<ffff0000083a1000>] lr : [<ffff0000081c126c>] pstate: 20000145
[ 4545.041530] sp : ffff80097533fcb0
[ 4545.044811] x29: ffff80097533fcb0 x28: ffff800962d24000
[ 4545.050074] x27: 0000000000001000 x26: ffff8009753fdb00
[ 4545.055337] x25: ffff000008200000 x24: ffff800977801380
[ 4545.060600] x23: ffff8009753fdb00 x22: ffff800962d24000
[ 4545.065863] x21: 0000000000001000 x20: ffff000008200000
[ 4545.071125] x19: 0000000000001000 x18: 0000ffffefa323c0
[ 4545.076387] x17: 0000ffffa9c87440 x16: ffff0000081fdfd0
[ 4545.081649] x15: 0000ffffa9d01588 x14: 72a77346b2407be7
[ 4545.086911] x13: 5299400690000000 x12: b0000001f9001a79
[ 4545.092173] x11: 97fc098d91042260 x10: 0000000000000000
[ 4545.097435] x9 : 0000000000000000 x8 : 9110626091260021
[ 4545.102698] x7 : 0000000000001000 x6 : ffff800962d24000
[ 4545.107960] x5 : ffff8009778013b0 x4 : 0000000000000000
[ 4545.113222] x3 : 0400000000000001 x2 : 0000000000000f80
[ 4545.118484] x1 : ffff804392800000 x0 : ffff800962d24000
[ 4545.123745]
[ 4545.125220] Process cat (pid: 8976, stack limit = 0xffff80097533c000)
[ 4545.131598] Stack: (0xffff80097533fcb0 to 0xffff800975340000)
[ 4545.137289] fca0: ffff80097533fd30 ffff000008270f64
[ 4545.145049] fcc0: 000000000000e000 000000003956f000 ffff000008f950d0 ffff80097533feb8
[ 4545.152809] fce0: 0000000000002000 ffff8009753fdb00 ffff800962d24000 ffff000008e8d3d8
[ 4545.160568] fd00: 0000000000001000 ffff000008200000 0000000000001000 ffff800962d24000
[ 4545.168327] fd20: 0000000000001000 ffff000008e884a0 ffff80097533fdb0 ffff00000826340c
[ 4545.176086] fd40: ffff800976bf2800 fffffffffffffffb 000000003956d000 ffff80097533feb8
[ 4545.183846] fd60: 0000000060000000 0000000000000015 0000000000000124 000000000000003f
[ 4545.191605] fd80: ffff000008962000 ffff8009753fdb00 ffff8009753fdb00 ffff8009753fdb00
[ 4545.199364] fda0: 0000000300000124 0000000000002000 ffff80097533fdd0 ffff0000081fb83c
[ 4545.207123] fdc0: 0000000000010000 ffff80097514f900 ffff80097533fe50 ffff0000081fcb28
[ 4545.214883] fde0: 0000000000010000 ffff80097514f900 0000000000000000 0000000000000000
[ 4545.222642] fe00: ffff80097533fe30 ffff0000081fca1c ffff80097514f900 0000000000000000
[ 4545.230401] fe20: 000000003956d000 ffff80097533feb8 ffff80097533fe50 ffff0000081fcb04
[ 4545.238160] fe40: 0000000000010000 ffff80097514f900 ffff80097533fe80 ffff0000081fe014
[ 4545.245919] fe60: ffff80097514f900 ffff80097514f900 000000003956d000 0000000000010000
[ 4545.253678] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800977146000
[ 4545.261438] fea0: ffffffffffffffff 0000ffffa9c8745c 0000000000000124 0000000008202000
[ 4545.269197] fec0: 0000000000000003 000000003956d000 0000000000010000 0000000000000000
[ 4545.276956] fee0: 0000000000011011 0000000000000001 0000000000000011 0000000000000002
[ 4545.284715] ff00: 000000000000003f 1f3c201f7372686b 00000000ffffffff 0000000000000030
[ 4545.292474] ff20: 0000000000000038 0000000000000000 0000ffffa9bcca94 0000ffffa9d01588
[ 4545.300233] ff40: 0000000000000000 0000ffffa9c87440 0000ffffefa323c0 0000000000010000
[ 4545.307993] ff60: 000000000041a310 000000003956d000 0000000000000003 000000007fffe000
[ 4545.315751] ff80: 00000000004088d0 0000000000010000 0000000000000000 0000000000000000
[ 4545.323511] ffa0: 0000000000010000 0000ffffefa32690 0000000000404dcc 0000ffffefa32690
[ 4545.331270] ffc0: 0000ffffa9c8745c 0000000060000000 0000000000000003 000000000000003f
[ 4545.339029] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4545.346786] Call trace:
[ 4545.349207] Exception stack(0xffff80097533fae0 to 0xffff80097533fc10)
[ 4545.355586] fae0: 0000000000001000 0001000000000000 ffff80097533fcb0 ffff0000083a1000
[ 4545.363345] fb00: 000000003957c000 ffff80097533fc00 0000000020000145 0000000000000025
[ 4545.371105] fb20: ffff800962d24000 ffff000008e8d3d8 0000000000001000 ffff8009753fdb00
[ 4545.378864] fb40: 0000000000000000 0000000000000002 ffff80097533fd30 ffff000008082604
[ 4545.386623] fb60: 0000000000001000 0001000000000000 ffff80097533fd30 ffff0000083a0a90
[ 4545.394382] fb80: ffff800962d24000 ffff804392800000 0000000000000f80 0400000000000001
[ 4545.402140] fba0: 0000000000000000 ffff8009778013b0 ffff800962d24000 0000000000001000
[ 4545.409899] fbc0: 9110626091260021 0000000000000000 0000000000000000 97fc098d91042260
[ 4545.417658] fbe0: b0000001f9001a79 5299400690000000 72a77346b2407be7 0000ffffa9d01588
[ 4545.425416] fc00: ffff0000081fdfd0 0000ffffa9c87440
[ 4545.430248] [<ffff0000083a1000>] __memcpy+0x100/0x180
[ 4545.435253] [<ffff000008270f64>] read_kcore+0x21c/0x3b0
[ 4545.440429] [<ffff00000826340c>] proc_reg_read+0x64/0x90
[ 4545.445691] [<ffff0000081fb83c>] __vfs_read+0x1c/0x108
[ 4545.450779] [<ffff0000081fcb28>] vfs_read+0x80/0x130
[ 4545.455696] [<ffff0000081fe014>] SyS_read+0x44/0xa0
[ 4545.460528] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[ 4545.465790] Code: d503201f d503201f d503201f d503201f (a8c12027)
[ 4545.471852] ---[ end trace 4d1897f94759f461 ]---
[ 4545.476435] note: cat[8976] exited with preempt_count 2
I find the issue is introduced when applying commit f9040773b7bb
("arm64: move kernel image to base of vmalloc area"). This patch
make the kernel image overlap with vmalloc area. It will result in
vmalloc area have the huge page table. but the vmalloc_to_page is
not realize the change. and the function is public to any arch.
I fix it by change the init mapping to make it keep the accordance
with vmalloc area mapping.
Fixes: f9040773b7bb ("arm64: move kernel image to base of vmalloc area")
Reported-by: tan xiaojun <tanxiaojun@huawei.com>
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
arch/arm64/mm/mmu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 17243e4..2d8b34d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -185,7 +185,7 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
/* try section mapping first */
if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
- !page_mappings_only) {
+ !page_mappings_only && !is_vmalloc_addr((void *)addr)) {
/*
* Set the contiguous bit for the subsequent group of
* PMDs if its size and alignment are appropriate.
@@ -256,7 +256,8 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
/*
* For 4K granule only, attempt to put down a 1GB block
*/
- if (use_1G_block(addr, next, phys) && !page_mappings_only) {
+ if (use_1G_block(addr, next, phys) && !page_mappings_only &&
+ !is_vmalloc_addr((void *)addr)) {
pud_set_huge(pud, phys, prot);
/*
--
1.7.12.4
^ permalink raw reply related
* [PATCH v4 1/7] pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers
From: Linus Walleij @ 2017-04-24 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <941d03c9a3bdfd5e789aada29b35184ec9fed9fe.1491405475.git-series.gregory.clement@free-electrons.com>
On Wed, Apr 5, 2017 at 5:18 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Document the device tree binding for the pin controllers found on the
> Armada 37xx SoCs.
>
> Update the binding documention of the xtal clk which is a subnode of this
> syscon node.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied, fixed up Rob's comment and added his ACK in the process.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Lee Jones @ 2017-04-24 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491683412-12237-1-git-send-email-daniel.lezcano@linaro.org>
On Sat, 08 Apr 2017, Daniel Lezcano wrote:
> The hi655x multi function device is a PMIC providing regulators.
>
> The PMIC also provides a clock for the WiFi and the Bluetooth, let's implement
> this clock in order to add it in the hi655x MFD and allow proper wireless
> initialization.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
>
> Changelog:
>
> V2:
> - Added COMPILE_TEST option, compiled on x86
> - Removed useless parenthesis
> - Used of_clk_hw_simple_get() instead of deref dance
> - Do bailout if the clock-names is not specified
> - Rollback on error
> - Folded mfd line change and binding
> - Added #clock-cells binding documentation
> - Added #clock-cells in the DT
>
> V1: initial post
> ---
??
> ---
I'm unsure if this as been mentioned before, but bundling;
driver & architecture changes and documentation into a single patch is
very seldom a good idea. In this case, you should split this into at
least 3, perhaps 4 patches.
> .../devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 +
Patch 1
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
Patch 2
> drivers/clk/Kconfig | 8 ++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-hi655x.c | 140 +++++++++++++++++++++
Patch 3
> drivers/mfd/hi655x-pmic.c | 3 +-
Patch 4
[...]
> 6 files changed, 158 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/clk-hi655x.c
>
> diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
> index 0548569..194e2a9fd 100644
> --- a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
> +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
> @@ -16,6 +16,11 @@ Required properties:
> - reg: Base address of PMIC on Hi6220 SoC.
> - interrupt-controller: Hi655x has internal IRQs (has own IRQ domain).
> - pmic-gpios: The GPIO used by PMIC IRQ.
> +- #clock-cells: From common clock binding; shall be set to 0
> +
> +Optional properties:
> +- clock-output-names: From common clock binding to override the
> + default output clock name
>
> Example:
> pmic: pmic at f8000000 {
> @@ -24,4 +29,5 @@ Example:
> interrupt-controller;
> #interrupt-cells = <2>;
> pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> + clock-cells = <0>;
> }
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> index dba3c13..bb9afb1 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> @@ -328,6 +328,7 @@
> interrupt-controller;
> #interrupt-cells = <2>;
> pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> + #clock-cells = <0>;
>
> regulators {
> ldo2: LDO2 {
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 9356ab4..36cfea3 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -47,6 +47,14 @@ config COMMON_CLK_RK808
> clocked at 32KHz each. Clkout1 is always on, Clkout2 can off
> by control register.
>
> +config COMMON_CLK_HI655X
> + tristate "Clock driver for Hi655x"
> + depends on MFD_HI655X_PMIC || COMPILE_TEST
> + ---help---
> + This driver supports the hi655x PMIC clock. This
> + multi-function device has one fixed-rate oscillator, clocked
> + at 32KHz.
> +
> config COMMON_CLK_SCPI
> tristate "Clock driver controlled via SCPI interface"
> depends on ARM_SCPI_PROTOCOL || COMPILE_TEST
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 92c12b8..c19983a 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_COMMON_CLK_PALMAS) += clk-palmas.o
> obj-$(CONFIG_COMMON_CLK_PWM) += clk-pwm.o
> obj-$(CONFIG_CLK_QORIQ) += clk-qoriq.o
> obj-$(CONFIG_COMMON_CLK_RK808) += clk-rk808.o
> +obj-$(CONFIG_COMMON_CLK_HI655X) += clk-hi655x.o
> obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
> obj-$(CONFIG_COMMON_CLK_SCPI) += clk-scpi.o
> obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
> diff --git a/drivers/clk/clk-hi655x.c b/drivers/clk/clk-hi655x.c
> new file mode 100644
> index 0000000..b2bea32
> --- /dev/null
> +++ b/drivers/clk/clk-hi655x.c
> @@ -0,0 +1,140 @@
> +/*
> + * Clock driver for Hi655x
> + *
> + * Copyright (c) 2016, Linaro Ltd.
> + *
> + * Author: Daniel Lezcano <daniel.lezcano@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/hi655x-pmic.h>
> +
> +#define HI655X_CLK_BASE HI655X_BUS_ADDR(0x1c)
> +#define HI655X_CLK_SET BIT(6)
> +
> +struct hi655x_clk {
> + struct hi655x_pmic *hi655x;
> + struct clk_hw clk_hw;
> +};
> +
> +static unsigned long hi655x_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + return 32768;
> +}
> +
> +static int hi655x_clk_enable(struct clk_hw *hw, bool enable)
> +{
> + struct hi655x_clk *hi655x_clk =
> + container_of(hw, struct hi655x_clk, clk_hw);
> +
> + struct hi655x_pmic *hi655x = hi655x_clk->hi655x;
> +
> + return regmap_update_bits(hi655x->regmap, HI655X_CLK_BASE,
> + HI655X_CLK_SET, enable ? HI655X_CLK_SET : 0);
> +}
> +
> +static int hi655x_clk_prepare(struct clk_hw *hw)
> +{
> + return hi655x_clk_enable(hw, true);
> +}
> +
> +static void hi655x_clk_unprepare(struct clk_hw *hw)
> +{
> + hi655x_clk_enable(hw, false);
> +}
> +
> +static int hi655x_clk_is_prepared(struct clk_hw *hw)
> +{
> + struct hi655x_clk *hi655x_clk =
> + container_of(hw, struct hi655x_clk, clk_hw);
> + struct hi655x_pmic *hi655x = hi655x_clk->hi655x;
> + int ret;
> + uint32_t val;
> +
> + ret = regmap_read(hi655x->regmap, HI655X_CLK_BASE, &val);
> + if (ret < 0)
> + return ret;
> +
> + return val & HI655X_CLK_BASE;
> +}
> +
> +static const struct clk_ops hi655x_clk_ops = {
> + .prepare = hi655x_clk_prepare,
> + .unprepare = hi655x_clk_unprepare,
> + .is_prepared = hi655x_clk_is_prepared,
> + .recalc_rate = hi655x_clk_recalc_rate,
> +};
> +
> +static int hi655x_clk_probe(struct platform_device *pdev)
> +{
> + struct device *parent = pdev->dev.parent;
> + struct hi655x_pmic *hi655x = dev_get_drvdata(parent);
> + struct clk_init_data *hi655x_clk_init;
> + struct hi655x_clk *hi655x_clk;
> + const char *clk_name = "hi655x-clk";
> + int ret;
> +
> + hi655x_clk = devm_kzalloc(&pdev->dev, sizeof(*hi655x_clk), GFP_KERNEL);
> + if (!hi655x_clk)
> + return -ENOMEM;
> +
> + hi655x_clk_init = devm_kzalloc(&pdev->dev, sizeof(*hi655x_clk_init),
> + GFP_KERNEL);
> + if (!hi655x_clk_init)
> + return -ENOMEM;
> +
> + of_property_read_string_index(parent->of_node, "clock-output-names",
> + 0, &clk_name);
> +
> + hi655x_clk_init->name = clk_name;
> + hi655x_clk_init->ops = &hi655x_clk_ops;
> +
> + hi655x_clk->clk_hw.init = hi655x_clk_init;
> + hi655x_clk->hi655x = hi655x;
> +
> + platform_set_drvdata(pdev, hi655x_clk);
> +
> + ret = devm_clk_hw_register(&pdev->dev, &hi655x_clk->clk_hw);
> + if (ret)
> + return ret;
> +
> + ret = of_clk_add_hw_provider(parent->of_node, of_clk_hw_simple_get,
> + &hi655x_clk->clk_hw);
> + if (ret)
> + return ret;
> +
> + ret = clk_hw_register_clkdev(&hi655x_clk->clk_hw, clk_name, NULL);
> + if (ret)
> + of_clk_del_provider(parent->of_node);
> +
> + return ret;
> +}
> +
> +static struct platform_driver hi655x_clk_driver = {
> + .probe = hi655x_clk_probe,
> + .driver = {
> + .name = "hi655x-clk",
> + },
> +};
> +
> +module_platform_driver(hi655x_clk_driver);
> +
> +MODULE_DESCRIPTION("Clk driver for the hi655x series PMICs");
> +MODULE_AUTHOR("Daniel Lezcano <daniel.lezcano@linaro.org>");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hi655x-clk");
> diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
> index ba706ad..c37ccbf 100644
> --- a/drivers/mfd/hi655x-pmic.c
> +++ b/drivers/mfd/hi655x-pmic.c
> @@ -77,7 +77,8 @@
> .num_resources = ARRAY_SIZE(pwrkey_resources),
> .resources = &pwrkey_resources[0],
> },
> - { .name = "hi655x-regulator", },
> + { .name = "hi655x-regulator", },
> + { .name = "hi655x-clk", },
> };
>
> static void hi655x_local_irq_clear(struct regmap *map)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 15/18] arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled
From: Marc Zyngier @ 2017-04-24 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58FDC1F5.3000401@huawei.com>
On 24/04/17 10:14, Hanjun Guo wrote:
> On 2017/4/24 16:40, Marc Zyngier wrote:
>> On 24/04/17 09:25, Lixiaoping (Timmy) wrote:
>>> Hi Marc,
>>>
>>> Sorry about previous email's confidential info. Please forget it.
>>>
>>> +#define ESR_ELx_SYS64_ISS_SYS_CNTFRQ (ESR_ELx_SYS64_ISS_SYS_VAL(3, 3, 14, 0, 0) | \
>>> + ESR_ELx_SYS64_ISS_DIR_READ)
>>>
>>> I think (3, 3, 14, 0, 0) should be (3, 3, 0, 14, 0)?
>> Thanks for spotting this. I assumed that the sys_reg() and
>> SR_ELx_SYS64_ISS_SYS_VAL() macros took their arguments in the same
>> order. That would have been too easy... ;-)
>>
>> Amended patch below, please let me know if it works for you.
>>
>> Thanks,
>>
>> M.
>>
>> >From 4444c86a97c1a487e12c319fdc197c88631d72b5 Mon Sep 17 00:00:00 2001
>> From: Marc Zyngier <marc.zyngier@arm.com>
>> Date: Mon, 24 Apr 2017 09:04:03 +0100
>> Subject: [PATCH] arm64: Add CNTFRQ_EL0 trap handler
>>
>> We now trap accesses to CNTVCT_EL0 when the counter is broken
>> enough to require the kernel to mediate the access. But it
>> turns out that some existing userspace (such as OpenMPI) do
>> probe for the counter frequency, leading to an UNDEF exception
>> as CNTVCT_EL0 and CNTFRQ_EL0 share the same control bit.
>>
>> The fix is to handle the exception the same way we do for CNTVCT_EL0.
>>
>> Fixes: a86bd139f2ae ("arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled")
>> Reported-by: Hanjun Guo <guohanjun@huawei.com>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>
> I tested this patch and the undefined instruction error is gone, I can
> get the FREQ in the user space now, thank you very much for the quick
> response.
>
> Tested-by: Hanjun Guo <guohanjun@huawei.com>
> Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Thanks for giving it a go. Catalin, can you queue this via the arm64 tree?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/1] PCI: Add MCFG quirk for 2nd node of Cavium ThunderX pass2.x host controller
From: Robert Richter @ 2017-04-24 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421165614.GA17916@bhelgaas-glaptop.roam.corp.google.com>
On 21.04.17 11:56:14, Bjorn Helgaas wrote:
> On Wed, Mar 29, 2017 at 02:16:13PM +0200, Tomasz Nowicki wrote:
> > Currently SoCs pass2.x do not emulate EA headers for ACPI boot method at all.
> > However, for pass2.x some devices (like EDAC) advertise incorrect base addresses
> > in their BARs which results in driver probe failure during resource request.
> > Since all problematic blocks are on 2nd NUMA node under domain 10 add necessary
> > quirk entry to obtain BAR addresses correction using EA header emulation.
> >
> > Fixes: 44f22bd91e88 ("PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controller")
> > Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> > CC: stable at vger.kernel.org # v4.10+
>
> Sorry Tomasz, I must have mistakenly marked this "accepted" in
> patchwork, so it fell off my to-do list. It's too late to get this in
> v4.11, but I can still apply it for v4.12.
>
> I put it on my pci/host-thunder branch with Robert's ack. I added a preceding
> patch to tidy up whitespace, which makes this patch look like just:
>
> /* SoC pass2.x */
> THUNDER_PEM_QUIRK(1, 0),
> THUNDER_PEM_QUIRK(1, 1),
> + THUNDER_ECAM_QUIRK(1, 10),
>
> Please double-check it to make sure this is what you need.
Bjorn,
since the second is marked stable there will be conflicts when
applying it to stable (or built errors). The best would be to change
order of both (128cd6e8249f^, 128cd6e8249f) for smooth backporting
which makes it then more close to Tomasz's version again.
Thanks,
-Robert
>
> > ---
> > drivers/acpi/pci_mcfg.c | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> > index a6a4cea..a0a391e 100644
> > --- a/drivers/acpi/pci_mcfg.c
> > +++ b/drivers/acpi/pci_mcfg.c
> > @@ -90,13 +90,14 @@ static struct mcfg_fixup mcfg_quirks[] = {
> > &thunder_pem_ecam_ops, THUNDER_PEM_RES(0x894057000000UL, node) }, \
> > { "CAVIUM", "THUNDERX", rev, 9 + (10 * (node)), MCFG_BUS_ANY, \
> > &thunder_pem_ecam_ops, THUNDER_PEM_RES(0x89808f000000UL, node) }
> > +#define THUNDER_ECAM_QUIRK(rev, seg) \
> > + { "CAVIUM", "THUNDERX", rev, seg, MCFG_BUS_ANY, \
> > + &pci_thunder_ecam_ops }
> > /* SoC pass2.x */
> > THUNDER_PEM_QUIRK(1, 0),
> > THUNDER_PEM_QUIRK(1, 1),
> > + THUNDER_ECAM_QUIRK(1, 10),
> >
> > -#define THUNDER_ECAM_QUIRK(rev, seg) \
> > - { "CAVIUM", "THUNDERX", rev, seg, MCFG_BUS_ANY, \
> > - &pci_thunder_ecam_ops }
> > /* SoC pass1.x */
> > THUNDER_PEM_QUIRK(2, 0), /* off-chip devices */
> > THUNDER_PEM_QUIRK(2, 1), /* off-chip devices */
> > --
> > 2.7.4
> >
^ permalink raw reply
* [PATCH v3] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd
From: Suzuki K Poulose @ 2017-04-24 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <febea966-3767-21ff-3c40-1a76d1399138@suse.de>
On Sat, Apr 22, 2017 at 02:28:44AM +0200, Alexander Graf wrote:
>
>
> On 04.04.17 12:35, Suzuki K Poulose wrote:
> > Hi Christoffer,
> >
> > On 04/04/17 11:13, Christoffer Dall wrote:
> > > Hi Suzuki,
> > >
> > > On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote:
> > > > In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
> > > > unmap_stage2_range() on the entire memory range for the guest. This
> > > > could
> > > > cause problems with other callers (e.g, munmap on a memslot) trying to
> > > > unmap a range. And since we have to unmap the entire Guest memory range
> > > > holding a spinlock, make sure we yield the lock if necessary, after we
> > > > unmap each PUD range.
> > > >
> > > > Fixes: commit d5d8184d35c9 ("KVM: ARM: Memory virtualization setup")
> > > > Cc: stable at vger.kernel.org # v3.10+
> > > > Cc: Paolo Bonzini <pbonzin@redhat.com>
> > > > Cc: Marc Zyngier <marc.zyngier@arm.com>
> > > > Cc: Christoffer Dall <christoffer.dall@linaro.org>
> > > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > > [ Avoid vCPU starvation and lockup detector warnings ]
> > > > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> > > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > >
> > >
> > > This unfortunately fails to build on 32-bit ARM, and I also think we
> > > intended to check against S2_PGDIR_SIZE, not S2_PUD_SIZE.
> >
> > Sorry about that, I didn't test the patch with arm32. I am fine the
> > patch below. And I agree that the name change does make things more
> > readable. See below for a hunk that I posted to the kbuild report.
> >
> > >
> > > How about adding this to your patch (which includes a rename of
> > > S2_PGD_SIZE which is horribly confusing as it indicates the size of the
> > > first level stage-2 table itself, where S2_PGDIR_SIZE indicates the size
> > > of address space mapped by a single entry in the same table):
> > >
> > > diff --git a/arch/arm/include/asm/stage2_pgtable.h
> > > b/arch/arm/include/asm/stage2_pgtable.h
> > > index 460d616..c997f2d 100644
> > > --- a/arch/arm/include/asm/stage2_pgtable.h
> > > +++ b/arch/arm/include/asm/stage2_pgtable.h
> > > @@ -35,10 +35,13 @@
> > >
> > > #define stage2_pud_huge(pud) pud_huge(pud)
> > >
> > > +#define S2_PGDIR_SIZE PGDIR_SIZE
> > > +#define S2_PGDIR_MASK PGDIR_MASK
> > > +
> > > /* Open coded p*d_addr_end that can deal with 64bit addresses */
> > > static inline phys_addr_t stage2_pgd_addr_end(phys_addr_t addr,
> > > phys_addr_t end)
> > > {
> > > - phys_addr_t boundary = (addr + PGDIR_SIZE) & PGDIR_MASK;
> > > + phys_addr_t boundary = (addr + S2_PGDIR_SIZE) & S2_PGDIR_MASK;
> > >
> > > return (boundary - 1 < end - 1) ? boundary : end;
> > > }
> > > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> > > index db94f3a..6e79a4c 100644
> > > --- a/arch/arm/kvm/mmu.c
> > > +++ b/arch/arm/kvm/mmu.c
> > > @@ -41,7 +41,7 @@ static unsigned long hyp_idmap_start;
> > > static unsigned long hyp_idmap_end;
> > > static phys_addr_t hyp_idmap_vector;
> > >
> > > -#define S2_PGD_SIZE (PTRS_PER_S2_PGD * sizeof(pgd_t))
> > > +#define S2_PGD_TABLE_SIZE (PTRS_PER_S2_PGD * sizeof(pgd_t))
> > > #define hyp_pgd_order get_order(PTRS_PER_PGD * sizeof(pgd_t))
> > >
> > > #define KVM_S2PTE_FLAG_IS_IOMAP (1UL << 0)
> > > @@ -299,7 +299,7 @@ static void unmap_stage2_range(struct kvm *kvm,
> > > phys_addr_t start, u64 size)
> > > * If the range is too large, release the kvm->mmu_lock
> > > * to prevent starvation and lockup detector warnings.
> > > */
> > > - if (size > S2_PUD_SIZE)
> > > + if (size > S2_PGDIR_SIZE)
> > > cond_resched_lock(&kvm->mmu_lock);
> > > next = stage2_pgd_addr_end(addr, end);
> > > if (!stage2_pgd_none(*pgd))
> > > @@ -747,7 +747,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
> > > }
> > >
> > > /* Allocate the HW PGD, making sure that each page gets its own
> > > refcount */
> > > - pgd = alloc_pages_exact(S2_PGD_SIZE, GFP_KERNEL | __GFP_ZERO);
> > > + pgd = alloc_pages_exact(S2_PGD_TABLE_SIZE, GFP_KERNEL | __GFP_ZERO);
> > > if (!pgd)
> > > return -ENOMEM;
> > >
> > > @@ -843,7 +843,7 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
> > > spin_unlock(&kvm->mmu_lock);
> > >
> > > /* Free the HW pgd, one page at a time */
> > > - free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
> > > + free_pages_exact(kvm->arch.pgd, S2_PGD_TABLE_SIZE);
> > > kvm->arch.pgd = NULL;
> > > }
> > >
> >
> > Btw, I have a different hunk to solve the problem, posted to the kbuild
> > report. I will post it here for the sake of capturing the discussion in
> > one place. The following hunk on top of the patch, changes the lock
> > release after we process one PGDIR entry. As for the first time
> > we enter the loop we haven't done much with the lock held, hence it may
> > make
> > sense to do it after the first round and we have more work to do.
> >
> > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> > index db94f3a..582a972 100644
> > --- a/arch/arm/kvm/mmu.c
> > +++ b/arch/arm/kvm/mmu.c
> > @@ -295,15 +295,15 @@ static void unmap_stage2_range(struct kvm *kvm,
> > phys_addr_t start, u64 size)
> > assert_spin_locked(&kvm->mmu_lock);
> > pgd = kvm->arch.pgd + stage2_pgd_index(addr);
> > do {
> > + next = stage2_pgd_addr_end(addr, end);
> > + if (!stage2_pgd_none(*pgd))
>
> Just as heads up, I had this version applied to my tree by accident (commit
> 8b3405e345b5a098101b0c31b264c812bba045d9 from Christoffer's queue) and ran
> into a NULL pointer dereference:
>
> [223090.242280] Unable to handle kernel NULL pointer dereference at virtual
> address 00000040
> [223090.262330] PC is at unmap_stage2_range+0x8c/0x428
> [223090.262332] LR is at kvm_unmap_hva_handler+0x2c/0x3c
> [223090.262531] Call trace:
> [223090.262533] [<ffff0000080adb78>] unmap_stage2_range+0x8c/0x428
> [223090.262535] [<ffff0000080adf40>] kvm_unmap_hva_handler+0x2c/0x3c
> [223090.262537] [<ffff0000080ace2c>] handle_hva_to_gpa+0xb0/0x104
> [223090.262539] [<ffff0000080af988>] kvm_unmap_hva+0x5c/0xbc
> [223090.262543] [<ffff0000080a2478>]
> kvm_mmu_notifier_invalidate_page+0x50/0x8c
> [223090.262547] [<ffff0000082274f8>]
> __mmu_notifier_invalidate_page+0x5c/0x84
> [223090.262551] [<ffff00000820b700>] try_to_unmap_one+0x1d0/0x4a0
> [223090.262553] [<ffff00000820c5c8>] rmap_walk+0x1cc/0x2e0
> [223090.262555] [<ffff00000820c90c>] try_to_unmap+0x74/0xa4
> [223090.262557] [<ffff000008230ce4>] migrate_pages+0x31c/0x5ac
> [223090.262561] [<ffff0000081f869c>] compact_zone+0x3fc/0x7ac
> [223090.262563] [<ffff0000081f8ae0>] compact_zone_order+0x94/0xb0
> [223090.262564] [<ffff0000081f91c0>] try_to_compact_pages+0x108/0x290
> [223090.262569] [<ffff0000081d5108>] __alloc_pages_direct_compact+0x70/0x1ac
> [223090.262571] [<ffff0000081d64a0>] __alloc_pages_nodemask+0x434/0x9f4
> [223090.262572] [<ffff0000082256f0>] alloc_pages_vma+0x230/0x254
> [223090.262574] [<ffff000008235e5c>] do_huge_pmd_anonymous_page+0x114/0x538
> [223090.262576] [<ffff000008201bec>] handle_mm_fault+0xd40/0x17a4
> [223090.262577] [<ffff0000081fb324>] __get_user_pages+0x12c/0x36c
> [223090.262578] [<ffff0000081fb804>] get_user_pages_unlocked+0xa4/0x1b8
> [223090.262579] [<ffff0000080a3ce8>] __gfn_to_pfn_memslot+0x280/0x31c
> [223090.262580] [<ffff0000080a3dd0>] gfn_to_pfn_prot+0x4c/0x5c
> [223090.262582] [<ffff0000080af3f8>] kvm_handle_guest_abort+0x240/0x774
> [223090.262584] [<ffff0000080b2bac>] handle_exit+0x11c/0x1ac
> [223090.262586] [<ffff0000080ab99c>] kvm_arch_vcpu_ioctl_run+0x31c/0x648
> [223090.262587] [<ffff0000080a1d78>] kvm_vcpu_ioctl+0x378/0x768
> [223090.262590] [<ffff00000825df5c>] do_vfs_ioctl+0x324/0x5a4
> [223090.262591] [<ffff00000825e26c>] SyS_ioctl+0x90/0xa4
> [223090.262595] [<ffff000008085d84>] el0_svc_naked+0x38/0x3c
>
> 0xffff0000080adb78 is in unmap_stage2_range (../arch/arm/kvm/mmu.c:260).
> 255 pud_t *pud, *start_pud;
> 256
> 257 start_pud = pud = stage2_pud_offset(pgd, addr);
> 258 do {
> 259 next = stage2_pud_addr_end(addr, end);
> 260 if (!stage2_pud_none(*pud)) {
> 261 if (stage2_pud_huge(*pud)) {
> 262 pud_t old_pud = *pud;
> 263
> 264 stage2_pud_clear(pud);
>
>
> So please beware that for some reason pud may become invalid after
> rescheduling.
Alex,
Thanks for the report. The patch below should fix this one.
---8>---
kvm: arm/arm64: Fix race in resetting stage2 PGD
In kvm_free_stage2_pgd() we check the stage2 PGD before holding
the lock and proceed to take the lock if it is valid. And we unmap
the page tables, followed by releasing the lock. We reset the PGD
only after dropping this lock, which could cause a race condition
where another thread waiting on the lock could potentially see that
the PGD is still valid and proceed to perform a stage2 operation.
This patch moves the stage2 PGD manipulation under the lock.
Reported-by: Alexander Graf <agraf@suse.de>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm/kvm/mmu.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 582a972..9c4026d 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -835,16 +835,18 @@ void stage2_unmap_vm(struct kvm *kvm)
*/
void kvm_free_stage2_pgd(struct kvm *kvm)
{
- if (kvm->arch.pgd == NULL)
- return;
+ void *pgd = NULL;
spin_lock(&kvm->mmu_lock);
- unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+ if (kvm->arch.pgd) {
+ unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+ pgd = kvm->arch.pgd;
+ kvm->arch.pgd = NULL;
+ }
spin_unlock(&kvm->mmu_lock);
-
/* Free the HW pgd, one page at a time */
- free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
- kvm->arch.pgd = NULL;
+ if (pgd)
+ free_pages_exact(pgd, S2_PGD_SIZE);
}
static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache *cache,
--
2.7.4
^ 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