Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 5/5] perf s390: add regs_query_register_offset()
From: Hendrik Brueckner @ 2017-12-01 14:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1512137948-31729-1-git-send-email-brueckner@linux.vnet.ibm.com>

The regs_query_register_offset() helper function converts
register name like "%r0" to an offset of a register in user_pt_regs
It is required by the BPF prologue generator.

The user_pt_regs structure was recently added to "asm/ptrace.h".
Hence, update tools/perf/check-headers.sh to keep the header file
in sync with kernel changes.

Suggested-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Reviewed-and-tested-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
---
 tools/perf/arch/s390/Makefile          |  1 +
 tools/perf/arch/s390/util/dwarf-regs.c | 32 +++++++++++++++++++++++++++++---
 tools/perf/check-headers.sh            |  1 +
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/tools/perf/arch/s390/Makefile b/tools/perf/arch/s390/Makefile
index 21322e0..09ba923 100644
--- a/tools/perf/arch/s390/Makefile
+++ b/tools/perf/arch/s390/Makefile
@@ -2,3 +2,4 @@ ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
 endif
 HAVE_KVM_STAT_SUPPORT := 1
+PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
diff --git a/tools/perf/arch/s390/util/dwarf-regs.c b/tools/perf/arch/s390/util/dwarf-regs.c
index f47576c..a8ace5c 100644
--- a/tools/perf/arch/s390/util/dwarf-regs.c
+++ b/tools/perf/arch/s390/util/dwarf-regs.c
@@ -2,17 +2,43 @@
 /*
  * Mapping of DWARF debug register numbers into register names.
  *
- *    Copyright IBM Corp. 2010
- *    Author(s): Heiko Carstens <heiko.carstens@de.ibm.com>,
+ * Copyright IBM Corp. 2010, 2017
+ * Author(s): Heiko Carstens <heiko.carstens@de.ibm.com>,
+ *	      Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
  *
  */
 
+#include <errno.h>
 #include <stddef.h>
-#include <dwarf-regs.h>
+#include <stdlib.h>
 #include <linux/kernel.h>
+#include <asm/ptrace.h>
+#include <string.h>
+#include <dwarf-regs.h>
 #include "dwarf-regs-table.h"
 
 const char *get_arch_regstr(unsigned int n)
 {
 	return (n >= ARRAY_SIZE(s390_dwarf_regs)) ? NULL : s390_dwarf_regs[n];
 }
+
+/*
+ * Convert the register name into an offset to struct pt_regs (kernel).
+ * This is required by the BPF prologue generator.  The BPF
+ * program is called in the BPF overflow handler in the perf
+ * core.
+ */
+int regs_query_register_offset(const char *name)
+{
+	unsigned long gpr;
+
+	if (!name || strncmp(name, "%r", 2))
+		return -EINVAL;
+
+	errno = 0;
+	gpr = strtoul(name + 2, NULL, 10);
+	if (errno || gpr >= 16)
+		return -EINVAL;
+
+	return offsetof(user_pt_regs, gprs) + 8 * gpr;
+}
diff --git a/tools/perf/check-headers.sh b/tools/perf/check-headers.sh
index 77406d2..6db9d80 100755
--- a/tools/perf/check-headers.sh
+++ b/tools/perf/check-headers.sh
@@ -30,6 +30,7 @@ arch/x86/include/uapi/asm/vmx.h
 arch/powerpc/include/uapi/asm/kvm.h
 arch/s390/include/uapi/asm/kvm.h
 arch/s390/include/uapi/asm/kvm_perf.h
+arch/s390/include/uapi/asm/ptrace.h
 arch/s390/include/uapi/asm/sie.h
 arch/arm/include/uapi/asm/kvm.h
 arch/arm64/include/uapi/asm/kvm.h
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH RT] arm*: disable NEON in kernel mode
From: Sebastian Andrzej Siewior @ 2017-12-01 14:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171201141827.yip6pl3tt7kxzek7@lakrids.cambridge.arm.com>

On 2017-12-01 14:18:28 [+0000], Mark Rutland wrote:
> [Adding Ard, who wrote the NEON crypto code]
> 
> On Fri, Dec 01, 2017 at 02:45:06PM +0100, Sebastian Andrzej Siewior wrote:
> > +arm folks, to let you know
> > 
> > On 2017-12-01 11:43:32 [+0100], To linux-rt-users at vger.kernel.org wrote:
> > > NEON in kernel mode is used by the crypto algorithms and raid6 code.
> > > While the raid6 code looks okay, the crypto algorithms do not: NEON
> > > is enabled on first invocation and may allocate/free/map memory before
> > > the NEON mode is disabled again.
> 
> Could you elaborate on why this is a problem?
> 
> I guess this is because kernel_neon_{begin,end}() disable preemption?
> 
> ... is this specific to RT?

It is RT specific, yes. One thing are the unbounded latencies since
everything in this preempt_disable section can take time depending on
the size of the request.
The other thing is code like in
  arch/arm64/crypto/aes-ce-ccm-glue.c:ccm_encrypt()

where within this preempt_disable() section skcipher_walk_done() is
invoked. That function can allocate/free/map memory which is okay for
!RT but is not for RT. I tried to break those loops for x86 [0] and I
simply didn't had the time to do the same for ARM. I am aware that
store/restore of the NEON registers (as SSE and AVX) is expensive and
doing a lot of operations in one go is desired. So for x86 I would want
to do some benchmarks and come up with some numbers based on which I
can argue with people one way or another depending on how much it hurts
and how long preemption can be disabled.

[0] https://www.spinics.net/lists/kernel/msg2663115.html

> Thanks,
> Mark.

Sebastian

^ permalink raw reply

* [alsa-devel] [PATCH v5 04/13] IIO: inkern: API for manipulating channel attributes
From: kbuild test robot @ 2017-12-01 14:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1511881557-28596-5-git-send-email-arnaud.pouliquen@st.com>

Hi Arnaud,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on iio/togreg]
[also build test WARNING on v4.15-rc1 next-20171201]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Arnaud-Pouliquen/Add-STM32-DFSDM-support/20171201-215409
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   In file included from drivers/iio//adc/envelope-detector.c:38:0:
>> include/linux/iio/consumer.h:228:20: warning: 'enum iio_chan_info_enum' declared inside parameter list
        int val2, enum iio_chan_info_enum attribute);
                       ^
>> include/linux/iio/consumer.h:228:20: warning: its scope is only this definition or declaration, which is probably not what you want
   include/linux/iio/consumer.h:242:27: warning: 'enum iio_chan_info_enum' declared inside parameter list
              int *val2, enum iio_chan_info_enum attribute);
                              ^

vim +228 include/linux/iio/consumer.h

   217	
   218	/**
   219	 * iio_write_channel_attribute() - Write values to the device attribute.
   220	 * @chan:	The channel being queried.
   221	 * @val:	Value being written.
   222	 * @val2:	Value being written.val2 use depends on attribute type.
   223	 * @attribute:	info attribute to be read.
   224	 *
   225	 * Returns an error code or 0.
   226	 */
   227	int iio_write_channel_attribute(struct iio_channel *chan, int val,
 > 228					int val2, enum iio_chan_info_enum attribute);
   229	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 51640 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171201/fc1aaf8e/attachment-0001.gz>

^ permalink raw reply

* [alsa-devel] [PATCH v5 13/13] ASoC: stm32: add DFSDM DAI support
From: kbuild test robot @ 2017-12-01 14:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1511881557-28596-14-git-send-email-arnaud.pouliquen@st.com>

Hi Arnaud,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on iio/togreg]
[also build test WARNING on v4.15-rc1 next-20171201]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Arnaud-Pouliquen/Add-STM32-DFSDM-support/20171201-215409
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=blackfin 

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:329:0,
                    from include/linux/kernel.h:13,
                    from include/linux/clk.h:16,
                    from sound/soc//stm/stm32_adfsdm.c:23:
   sound/soc//stm/stm32_adfsdm.c: In function 'stm32_afsdm_pcm_cb':
>> sound/soc//stm/stm32_adfsdm.c:173:20: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t {aka long unsigned int}' [-Wformat=]
     dev_dbg(rtd->dev, "%s: buff_add :%p, pos = %d, size = %d\n",
                       ^
   include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
      __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                          ^~~
>> sound/soc//stm/stm32_adfsdm.c:173:2: note: in expansion of macro 'dev_dbg'
     dev_dbg(rtd->dev, "%s: buff_add :%p, pos = %d, size = %d\n",
     ^~~~~~~

vim +/dev_dbg +173 sound/soc//stm/stm32_adfsdm.c

  > 23	#include <linux/clk.h>
    24	#include <linux/module.h>
    25	#include <linux/platform_device.h>
    26	#include <linux/slab.h>
    27	
    28	#include <linux/iio/iio.h>
    29	#include <linux/iio/consumer.h>
    30	#include <linux/iio/adc/stm32-dfsdm-adc.h>
    31	
    32	#include <sound/pcm.h>
    33	#include <sound/soc.h>
    34	
    35	#define STM32_ADFSDM_DRV_NAME "stm32-adfsdm"
    36	
    37	#define DFSDM_MAX_PERIOD_SIZE	(PAGE_SIZE / 2)
    38	#define DFSDM_MAX_PERIODS	6
    39	
    40	struct stm32_adfsdm_priv {
    41		struct snd_soc_dai_driver dai_drv;
    42		struct snd_pcm_substream *substream;
    43		struct device *dev;
    44	
    45		/* IIO */
    46		struct iio_channel *iio_ch;
    47		struct iio_cb_buffer *iio_cb;
    48		bool iio_active;
    49	
    50		/* PCM buffer */
    51		unsigned char *pcm_buff;
    52		unsigned int pos;
    53		bool allocated;
    54	};
    55	
    56	struct stm32_adfsdm_data {
    57		unsigned int rate;	/* SNDRV_PCM_RATE value */
    58		unsigned int freq;	/* frequency in Hz */
    59	};
    60	
    61	static const struct snd_pcm_hardware stm32_adfsdm_pcm_hw = {
    62		.info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER |
    63		    SNDRV_PCM_INFO_PAUSE,
    64		.formats = SNDRV_PCM_FMTBIT_S32_LE,
    65	
    66		.rate_min = 8000,
    67		.rate_max = 32000,
    68	
    69		.channels_min = 1,
    70		.channels_max = 1,
    71	
    72		.periods_min = 2,
    73		.periods_max = DFSDM_MAX_PERIODS,
    74	
    75		.period_bytes_max = DFSDM_MAX_PERIOD_SIZE,
    76		.buffer_bytes_max = DFSDM_MAX_PERIODS * DFSDM_MAX_PERIOD_SIZE
    77	};
    78	
    79	static void stm32_adfsdm_shutdown(struct snd_pcm_substream *substream,
    80					  struct snd_soc_dai *dai)
    81	{
    82		struct stm32_adfsdm_priv *priv = snd_soc_dai_get_drvdata(dai);
    83	
    84		if (priv->iio_active) {
    85			iio_channel_stop_all_cb(priv->iio_cb);
    86			priv->iio_active = false;
    87		}
    88	}
    89	
    90	static int stm32_adfsdm_dai_prepare(struct snd_pcm_substream *substream,
    91					    struct snd_soc_dai *dai)
    92	{
    93		struct stm32_adfsdm_priv *priv = snd_soc_dai_get_drvdata(dai);
    94		int ret;
    95	
    96		ret = iio_write_channel_attribute(priv->iio_ch,
    97						  substream->runtime->rate, 0,
    98						  IIO_CHAN_INFO_SAMP_FREQ);
    99		if (ret < 0) {
   100			dev_err(dai->dev, "%s: Failed to set %d sampling rate\n",
   101				__func__, substream->runtime->rate);
   102			return ret;
   103		}
   104	
   105		if (!priv->iio_active) {
   106			ret = iio_channel_start_all_cb(priv->iio_cb);
   107			if (!ret)
   108				priv->iio_active = true;
   109			else
   110				dev_err(dai->dev, "%s: IIO channel start failed (%d)\n",
   111					__func__, ret);
   112		}
   113	
   114		return ret;
   115	}
   116	
   117	static int stm32_adfsdm_set_sysclk(struct snd_soc_dai *dai, int clk_id,
   118					   unsigned int freq, int dir)
   119	{
   120		struct stm32_adfsdm_priv *priv = snd_soc_dai_get_drvdata(dai);
   121		ssize_t size;
   122	
   123		dev_dbg(dai->dev, "%s: Enter for freq %d\n", __func__, freq);
   124	
   125		/* Set IIO frequency if CODEC is master as clock comes from SPI_IN*/
   126		if (dir == SND_SOC_CLOCK_IN) {
   127			char str_freq[10];
   128	
   129			snprintf(str_freq, sizeof(str_freq), "%d\n", freq);
   130			size = iio_write_channel_ext_info(priv->iio_ch, "spi_clk_freq",
   131							  str_freq, sizeof(str_freq));
   132			if (size != sizeof(str_freq)) {
   133				dev_err(dai->dev, "%s: Failed to set SPI clock\n",
   134					__func__);
   135				return -EINVAL;
   136			}
   137		}
   138		return 0;
   139	}
   140	
   141	static const struct snd_soc_dai_ops stm32_adfsdm_dai_ops = {
   142		.shutdown = stm32_adfsdm_shutdown,
   143		.prepare = stm32_adfsdm_dai_prepare,
   144		.set_sysclk = stm32_adfsdm_set_sysclk,
   145	};
   146	
   147	static const struct snd_soc_dai_driver stm32_adfsdm_dai = {
   148		.capture = {
   149			    .channels_min = 1,
   150			    .channels_max = 1,
   151			    .formats = SNDRV_PCM_FMTBIT_S32_LE,
   152			    .rates = (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000 |
   153				      SNDRV_PCM_RATE_32000),
   154			    },
   155		.ops = &stm32_adfsdm_dai_ops,
   156	};
   157	
   158	static const struct snd_soc_component_driver stm32_adfsdm_dai_component = {
   159		.name = "stm32_dfsdm_audio",
   160	};
   161	
   162	static int stm32_afsdm_pcm_cb(const void *data, size_t size, void *private)
   163	{
   164		struct stm32_adfsdm_priv *priv = private;
   165		struct snd_soc_pcm_runtime *rtd = priv->substream->private_data;
   166		u8 *pcm_buff = priv->pcm_buff;
   167		u8 *src_buff = (u8 *)data;
   168		unsigned int buff_size = snd_pcm_lib_buffer_bytes(priv->substream);
   169		unsigned int period_size = snd_pcm_lib_period_bytes(priv->substream);
   170		unsigned int old_pos = priv->pos;
   171		unsigned int cur_size = size;
   172	
 > 173		dev_dbg(rtd->dev, "%s: buff_add :%p, pos = %d, size = %d\n",
   174			__func__, &pcm_buff[priv->pos], priv->pos, size);
   175	
   176		if ((priv->pos + size) > buff_size) {
   177			memcpy(&pcm_buff[priv->pos], src_buff, buff_size - priv->pos);
   178			cur_size -= buff_size - priv->pos;
   179			priv->pos = 0;
   180		}
   181	
   182		memcpy(&pcm_buff[priv->pos], &src_buff[size - cur_size], cur_size);
   183		priv->pos = (priv->pos + cur_size) % buff_size;
   184	
   185		if (cur_size != size || (old_pos && (old_pos % period_size < size)))
   186			snd_pcm_period_elapsed(priv->substream);
   187	
   188		return 0;
   189	}
   190	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 46104 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171201/04fdb848/attachment-0001.gz>

^ permalink raw reply

* [PATCH v5 1/5] dt-bindings: define vendor prefix for Wi2Wi, Inc.
From: Andreas Färber @ 2017-12-01 14:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <876647948fceb763a0b584b70c3805dec562072e.1512114576.git.hns@goldelico.com>

Hi,

Am 01.12.2017 um 08:49 schrieb H. Nikolaus Schaller:
> Introduce vendor prefix for Wi2Wi, Inc. for W2SG00x4 GPS modules
> and W2CBW003 Bluetooth/WiFi combo (CSR/Marvell).

If there's more iterations, maybe you could clarify what the company
does overall (just these 2?) vs. what specifically you add it for here?

> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Other than that,

Reviewed-by: Andreas F?rber <afaerber@suse.de>

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

^ permalink raw reply

* [PATCH RT] arm*: disable NEON in kernel mode
From: Ard Biesheuvel @ 2017-12-01 15:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171201143648.GK1612@linutronix.de>


l
> On 1 Dec 2017, at 14:36, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
>> On 2017-12-01 14:18:28 [+0000], Mark Rutland wrote:
>> [Adding Ard, who wrote the NEON crypto code]
>> 
>>> On Fri, Dec 01, 2017 at 02:45:06PM +0100, Sebastian Andrzej Siewior wrote:
>>> +arm folks, to let you know
>>> 
>>>> On 2017-12-01 11:43:32 [+0100], To linux-rt-users at vger.kernel.org wrote:
>>>> NEON in kernel mode is used by the crypto algorithms and raid6 code.
>>>> While the raid6 code looks okay, the crypto algorithms do not: NEON
>>>> is enabled on first invocation and may allocate/free/map memory before
>>>> the NEON mode is disabled again.
>> 
>> Could you elaborate on why this is a problem?
>> 
>> I guess this is because kernel_neon_{begin,end}() disable preemption?
>> 
>> ... is this specific to RT?
> 
> It is RT specific, yes. One thing are the unbounded latencies since
> everything in this preempt_disable section can take time depending on
> the size of the request.
> The other thing is code like in
>  arch/arm64/crypto/aes-ce-ccm-glue.c:ccm_encrypt()
> 
> where within this preempt_disable() section skcipher_walk_done() is
> invoked. That function can allocate/free/map memory which is okay for
> !RT but is not for RT. I tried to break those loops for x86 [0] and I
> simply didn't had the time to do the same for ARM. I am aware that
> store/restore of the NEON registers (as SSE and AVX) is expensive and
> doing a lot of operations in one go is desired.

I wouldn?t mind fixing the code instead. We never disable the neon, but only stack the contents of the registers the first time, and unstack them only before returning to userland (with the exception of nested neon use in softirq context). When this code was introduced, we always stacked/unstacked the whole register file eagerly every time.


> So for x86 I would want
> to do some benchmarks and come up with some numbers based on which I
> can argue with people one way or another depending on how much it hurts
> and how long preemption can be disabled.
> 
> [0] https://www.spinics.net/lists/kernel/msg2663115.html
> 
>> Thanks,
>> Mark.
> 
> Sebastian

^ permalink raw reply

* [alsa-devel] [PATCH v5 04/13] IIO: inkern: API for manipulating channel attributes
From: kbuild test robot @ 2017-12-01 15:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1511881557-28596-5-git-send-email-arnaud.pouliquen@st.com>

Hi Arnaud,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on iio/togreg]
[also build test WARNING on v4.15-rc1 next-20171201]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Arnaud-Pouliquen/Add-STM32-DFSDM-support/20171201-215409
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: x86_64-randconfig-x012-201748 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from drivers/iio/adc/envelope-detector.c:38:0:
>> include/linux/iio/consumer.h:228:20: warning: 'enum iio_chan_info_enum' declared inside parameter list will not be visible outside of this definition or declaration
        int val2, enum iio_chan_info_enum attribute);
                       ^~~~~~~~~~~~~~~~~~
   include/linux/iio/consumer.h:242:27: warning: 'enum iio_chan_info_enum' declared inside parameter list will not be visible outside of this definition or declaration
              int *val2, enum iio_chan_info_enum attribute);
                              ^~~~~~~~~~~~~~~~~~
   Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
   Cyclomatic Complexity 1 include/linux/kernel.h:kstrtoul
   Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
   Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
   Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
   Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock_irq
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irq
   Cyclomatic Complexity 1 include/linux/completion.h:__init_completion
   Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies
   Cyclomatic Complexity 3 include/linux/jiffies.h:msecs_to_jiffies
   Cyclomatic Complexity 1 include/linux/workqueue.h:queue_delayed_work
   Cyclomatic Complexity 1 include/linux/workqueue.h:schedule_delayed_work
   Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name
   Cyclomatic Complexity 2 include/linux/device.h:dev_name
   Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
   Cyclomatic Complexity 1 include/linux/iio/iio.h:iio_priv
   Cyclomatic Complexity 1 include/linux/irq.h:irqd_get_trigger_type
   Cyclomatic Complexity 2 include/linux/irq.h:irq_get_trigger_type
   Cyclomatic Complexity 1 include/linux/interrupt.h:devm_request_irq
   Cyclomatic Complexity 1 include/linux/platform_device.h:platform_set_drvdata
   Cyclomatic Complexity 1 drivers/iio/adc/envelope-detector.c:envelope_detector_driver_init
   Cyclomatic Complexity 15 drivers/iio/adc/envelope-detector.c:envelope_detector_probe
   Cyclomatic Complexity 1 drivers/iio/adc/envelope-detector.c:envelope_detector_comp_isr
   Cyclomatic Complexity 3 drivers/iio/adc/envelope-detector.c:envelope_store_comp_interval
   Cyclomatic Complexity 1 drivers/iio/adc/envelope-detector.c:envelope_show_comp_interval
   Cyclomatic Complexity 1 drivers/iio/adc/envelope-detector.c:envelope_show_invert
   Cyclomatic Complexity 6 drivers/iio/adc/envelope-detector.c:envelope_store_invert
   Cyclomatic Complexity 3 drivers/iio/adc/envelope-detector.c:envelope_detector_comp_latch
   Cyclomatic Complexity 5 drivers/iio/adc/envelope-detector.c:envelope_detector_setup_compare
   Cyclomatic Complexity 5 drivers/iio/adc/envelope-detector.c:envelope_detector_read_raw
   Cyclomatic Complexity 3 drivers/iio/adc/envelope-detector.c:envelope_detector_timeout
   Cyclomatic Complexity 1 drivers/iio/adc/envelope-detector.c:envelope_detector_driver_exit
--
   In file included from drivers/iio/multiplexer/iio-mux.c:14:0:
>> include/linux/iio/consumer.h:228:20: warning: 'enum iio_chan_info_enum' declared inside parameter list will not be visible outside of this definition or declaration
        int val2, enum iio_chan_info_enum attribute);
                       ^~~~~~~~~~~~~~~~~~
   include/linux/iio/consumer.h:242:27: warning: 'enum iio_chan_info_enum' declared inside parameter list will not be visible outside of this definition or declaration
              int *val2, enum iio_chan_info_enum attribute);
                              ^~~~~~~~~~~~~~~~~~
   Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
   Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
   Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name
   Cyclomatic Complexity 1 include/linux/device.h:devm_kzalloc
   Cyclomatic Complexity 2 include/linux/device.h:dev_name
   Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
   Cyclomatic Complexity 1 include/linux/iio/iio.h:iio_channel_has_info
   Cyclomatic Complexity 1 include/linux/iio/iio.h:iio_channel_has_available
   Cyclomatic Complexity 1 include/linux/iio/iio.h:iio_priv
   Cyclomatic Complexity 1 include/linux/platform_device.h:platform_set_drvdata
   Cyclomatic Complexity 1 drivers/iio/multiplexer/iio-mux.c:mux_driver_init
   Cyclomatic Complexity 7 drivers/iio/multiplexer/iio-mux.c:iio_mux_select
   Cyclomatic Complexity 1 drivers/iio/multiplexer/iio-mux.c:iio_mux_deselect
   Cyclomatic Complexity 5 drivers/iio/multiplexer/iio-mux.c:mux_write_ext_info
   Cyclomatic Complexity 2 drivers/iio/multiplexer/iio-mux.c:mux_read_ext_info
   Cyclomatic Complexity 3 drivers/iio/multiplexer/iio-mux.c:mux_write_raw
   Cyclomatic Complexity 3 drivers/iio/multiplexer/iio-mux.c:mux_read_avail
   Cyclomatic Complexity 4 drivers/iio/multiplexer/iio-mux.c:mux_read_raw
   Cyclomatic Complexity 16 drivers/iio/multiplexer/iio-mux.c:mux_configure_channel
   Cyclomatic Complexity 20 drivers/iio/multiplexer/iio-mux.c:mux_probe
   Cyclomatic Complexity 1 drivers/iio/multiplexer/iio-mux.c:mux_driver_exit
--
   In file included from drivers/iio//adc/envelope-detector.c:38:0:
>> include/linux/iio/consumer.h:228:20: warning: 'enum iio_chan_info_enum' declared inside parameter list will not be visible outside of this definition or declaration
        int val2, enum iio_chan_info_enum attribute);
                       ^~~~~~~~~~~~~~~~~~
   include/linux/iio/consumer.h:242:27: warning: 'enum iio_chan_info_enum' declared inside parameter list will not be visible outside of this definition or declaration
              int *val2, enum iio_chan_info_enum attribute);
                              ^~~~~~~~~~~~~~~~~~
   Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
   Cyclomatic Complexity 1 include/linux/kernel.h:kstrtoul
   Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
   Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
   Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
   Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_lock_irq
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock
   Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irq
   Cyclomatic Complexity 1 include/linux/completion.h:__init_completion
   Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies
   Cyclomatic Complexity 3 include/linux/jiffies.h:msecs_to_jiffies
   Cyclomatic Complexity 1 include/linux/workqueue.h:queue_delayed_work
   Cyclomatic Complexity 1 include/linux/workqueue.h:schedule_delayed_work
   Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name
   Cyclomatic Complexity 2 include/linux/device.h:dev_name
   Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
   Cyclomatic Complexity 1 include/linux/iio/iio.h:iio_priv
   Cyclomatic Complexity 1 include/linux/irq.h:irqd_get_trigger_type
   Cyclomatic Complexity 2 include/linux/irq.h:irq_get_trigger_type
   Cyclomatic Complexity 1 include/linux/interrupt.h:devm_request_irq
   Cyclomatic Complexity 1 include/linux/platform_device.h:platform_set_drvdata
   Cyclomatic Complexity 1 drivers/iio//adc/envelope-detector.c:envelope_detector_driver_init
   Cyclomatic Complexity 15 drivers/iio//adc/envelope-detector.c:envelope_detector_probe
   Cyclomatic Complexity 1 drivers/iio//adc/envelope-detector.c:envelope_detector_comp_isr
   Cyclomatic Complexity 3 drivers/iio//adc/envelope-detector.c:envelope_store_comp_interval
   Cyclomatic Complexity 1 drivers/iio//adc/envelope-detector.c:envelope_show_comp_interval
   Cyclomatic Complexity 1 drivers/iio//adc/envelope-detector.c:envelope_show_invert
   Cyclomatic Complexity 6 drivers/iio//adc/envelope-detector.c:envelope_store_invert
   Cyclomatic Complexity 3 drivers/iio//adc/envelope-detector.c:envelope_detector_comp_latch
   Cyclomatic Complexity 5 drivers/iio//adc/envelope-detector.c:envelope_detector_setup_compare
   Cyclomatic Complexity 5 drivers/iio//adc/envelope-detector.c:envelope_detector_read_raw
   Cyclomatic Complexity 3 drivers/iio//adc/envelope-detector.c:envelope_detector_timeout
   Cyclomatic Complexity 1 drivers/iio//adc/envelope-detector.c:envelope_detector_driver_exit
--
   In file included from drivers/iio//multiplexer/iio-mux.c:14:0:
>> include/linux/iio/consumer.h:228:20: warning: 'enum iio_chan_info_enum' declared inside parameter list will not be visible outside of this definition or declaration
        int val2, enum iio_chan_info_enum attribute);
                       ^~~~~~~~~~~~~~~~~~
   include/linux/iio/consumer.h:242:27: warning: 'enum iio_chan_info_enum' declared inside parameter list will not be visible outside of this definition or declaration
              int *val2, enum iio_chan_info_enum attribute);
                              ^~~~~~~~~~~~~~~~~~
   Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR
   Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
   Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name
   Cyclomatic Complexity 1 include/linux/device.h:devm_kzalloc
   Cyclomatic Complexity 2 include/linux/device.h:dev_name
   Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
   Cyclomatic Complexity 1 include/linux/iio/iio.h:iio_channel_has_info
   Cyclomatic Complexity 1 include/linux/iio/iio.h:iio_channel_has_available
   Cyclomatic Complexity 1 include/linux/iio/iio.h:iio_priv
   Cyclomatic Complexity 1 include/linux/platform_device.h:platform_set_drvdata
   Cyclomatic Complexity 1 drivers/iio//multiplexer/iio-mux.c:mux_driver_init
   Cyclomatic Complexity 7 drivers/iio//multiplexer/iio-mux.c:iio_mux_select
   Cyclomatic Complexity 1 drivers/iio//multiplexer/iio-mux.c:iio_mux_deselect
   Cyclomatic Complexity 5 drivers/iio//multiplexer/iio-mux.c:mux_write_ext_info
   Cyclomatic Complexity 2 drivers/iio//multiplexer/iio-mux.c:mux_read_ext_info
   Cyclomatic Complexity 3 drivers/iio//multiplexer/iio-mux.c:mux_write_raw
   Cyclomatic Complexity 3 drivers/iio//multiplexer/iio-mux.c:mux_read_avail
   Cyclomatic Complexity 4 drivers/iio//multiplexer/iio-mux.c:mux_read_raw
   Cyclomatic Complexity 16 drivers/iio//multiplexer/iio-mux.c:mux_configure_channel
   Cyclomatic Complexity 20 drivers/iio//multiplexer/iio-mux.c:mux_probe
   Cyclomatic Complexity 1 drivers/iio//multiplexer/iio-mux.c:mux_driver_exit

vim +228 include/linux/iio/consumer.h

   217	
   218	/**
   219	 * iio_write_channel_attribute() - Write values to the device attribute.
   220	 * @chan:	The channel being queried.
   221	 * @val:	Value being written.
   222	 * @val2:	Value being written.val2 use depends on attribute type.
   223	 * @attribute:	info attribute to be read.
   224	 *
   225	 * Returns an error code or 0.
   226	 */
   227	int iio_write_channel_attribute(struct iio_channel *chan, int val,
 > 228					int val2, enum iio_chan_info_enum attribute);
   229	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 28248 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171201/552f1dc2/attachment-0001.gz>

^ permalink raw reply

* [PATCH 10/37] KVM: arm64: Slightly improve debug save/restore functions
From: Christoffer Dall @ 2017-12-01 15:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <e9b8d6b8-6dfa-3e6d-6e8f-c16a1882651f@arm.com>

Hi Julien,

On Tue, Nov 14, 2017 at 04:42:13PM +0000, Julien Thierry wrote:
> On 12/10/17 11:41, Christoffer Dall wrote:
> >The debug save/restore functions can be improved by using the has_vhe()
> >static key instead of the instruction alternative.  Using the static key
> >uses the same paradigm as we're going to use elsewhere, it makes the
> >code more readable, and it generates slightly better code (no
> >stack setups and function calls unless necessary).
> >
> >We also use a static key on the restore path, because it will be
> >marginally faster than loading a value from memory.
> >
> >Finally, we don't have to conditionally clear the debug dirty flag if
> >it's set, we can just clear it.
> >
> >Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> >---
> >  arch/arm64/kvm/hyp/debug-sr.c | 22 +++++++++-------------
> >  1 file changed, 9 insertions(+), 13 deletions(-)
> >
> >diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
> >index 0fc0758..a2291b6 100644
> >--- a/arch/arm64/kvm/hyp/debug-sr.c
> >+++ b/arch/arm64/kvm/hyp/debug-sr.c
> >@@ -75,11 +75,6 @@
> >  #define psb_csync()		asm volatile("hint #17")
> >-static void __hyp_text __debug_save_spe_vhe(u64 *pmscr_el1)
> >-{
> >-	/* The vcpu can run. but it can't hide. */
> >-}
> >-
> >  static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1)
> >  {
> >  	u64 reg;
> >@@ -109,10 +104,6 @@ static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1)
> >  	dsb(nsh);
> >  }
> >-static hyp_alternate_select(__debug_save_spe,
> >-			    __debug_save_spe_nvhe, __debug_save_spe_vhe,
> >-			    ARM64_HAS_VIRT_HOST_EXTN);
> >-
> >  static void __hyp_text __debug_restore_spe(u64 pmscr_el1)
> >  {
> >  	if (!pmscr_el1)
> >@@ -174,17 +165,22 @@ void __hyp_text __debug_cond_save_host_state(struct kvm_vcpu *vcpu)
> >  {
> >  	__debug_save_state(vcpu, &vcpu->arch.host_debug_state.regs,
> >  			   kern_hyp_va(vcpu->arch.host_cpu_context));
> >-	__debug_save_spe()(&vcpu->arch.host_debug_state.pmscr_el1);
> >+
> >+	/* Non-VHE: Disable and flush SPE data generation
> >+	 * VHE: The vcpu can run. but it can't hide. */
> >+	if (!has_vhe())
> >+		__debug_save_spe_nvhe(&vcpu->arch.host_debug_state.pmscr_el1);
> >  }
> >  void __hyp_text __debug_cond_restore_host_state(struct kvm_vcpu *vcpu)
> >  {
> >-	__debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
> >+	if (!has_vhe())
> >+		__debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
> 
> For consistency, would it be worth naming that function
> '__debug_restore_spe_nvhe' ?

Yes.

> 
> Also, looking at __debug_save_spe_nvhe, I'm not sure how we guarantee that
> we might not end up using stale data during the restore_spe (though, if this
> is an issue, it existed before this change).
> The save function might exit without setting a value to saved pmscr_el1.
> 
> Basically I'm wondering if the following scenario (in non VHE) is possible
> and/or whether it is problematic:
> 
> - save spe
> - restore spe
> - host starts using spi -> !(PMBLIMITR_EL1 & PMBLIMITR_EL1_E)

spi ?

> - save spe -> returns early without setting pmscr_el1
> - restore spe with old save instead of doing nothing
> 

I think I see what you mean.  Basically you're asking if we need this:

diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
index 4112160..8ab3510 100644
--- a/arch/arm64/kvm/hyp/debug-sr.c
+++ b/arch/arm64/kvm/hyp/debug-sr.c
@@ -106,7 +106,7 @@ static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1)
 
 static void __hyp_text __debug_restore_spe_nvhe(u64 &pmscr_el1)
 {
-	if (!pmscr_el1)
+	if (*pmscr_el1 != 0)
 		return;
 
 	/* The host page table is installed, but not yet synchronised */
@@ -114,6 +114,7 @@ static void __hyp_text __debug_restore_spe_nvhe(u64 &pmscr_el1)
 
 	/* Re-enable data generation */
 	write_sysreg_s(pmscr_el1, PMSCR_EL1);
+	*pmscr_el1 = 0;
 }
 
 void __hyp_text __debug_save_state(struct kvm_vcpu *vcpu,

I think we do, and I think this is a separate fix.  Would you like to
write a patch and cc Will and Marc (original author and committer) to
fix this?  Probably worth a cc stable as well.

Thanks,
-Christoffer

^ permalink raw reply related

* [PATCH 0/3] arm64: SVE fixes for v4.15-rc1
From: Dave Martin @ 2017-12-01 15:19 UTC (permalink / raw)
  To: linux-arm-kernel

This mini-series contains a few fixes for known issues in the arm64 SVE
patches that missed the merge window.

They should be considered fixes for v4.15.

Dave Martin (3):
  arm64: KVM: Move CPU ID reg trap setup off the world switch path
  arm64: fpsimd: Abstract out binding of task's fpsimd context to the
    cpu.
  arm64/sve: KVM: Avoid dereference of dead task during guest entry

 arch/arm64/include/asm/kvm_emulate.h |  8 ++++++
 arch/arm64/kernel/fpsimd.c           | 51 +++++++++++++++++++++---------------
 arch/arm64/kvm/hyp/switch.c          |  4 ---
 3 files changed, 38 insertions(+), 25 deletions(-)

-- 
2.1.4

^ permalink raw reply

* [PATCH 1/3] arm64: KVM: Move CPU ID reg trap setup off the world switch path
From: Dave Martin @ 2017-12-01 15:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1512141582-17474-1-git-send-email-Dave.Martin@arm.com>

The HCR_EL2.TID3 flag needs to be set when trapping guest access to
the CPU ID registers is required.  However, the decision about
whether to set this bit does not need to be repeated at every
switch to the guest.

Instead, it's sufficient to make this decision once and record the
outcome.

This patch moves the decision to vcpu_reset_hcr() and records the
choice made in vcpu->arch.hcr_el2.  The world switch code can then
load this directly when switching to the guest without the need for
conditional logic on the critical path.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Suggested-by: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>

---

Note to maintainers: this was discussed on-list [1] prior to the merge
window, but this patch implementing the agreed decision hasn't been
posted previously.

This should be considered a fix for v4.15.

[1] [PATCH v3 02/28] arm64: KVM: Hide unsupported AArch64 CPU features from guests
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/537420.html
---
 arch/arm64/include/asm/kvm_emulate.h | 8 ++++++++
 arch/arm64/kvm/hyp/switch.c          | 4 ----
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 5f28dfa..8ff5aef 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -52,6 +52,14 @@ static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
 		vcpu->arch.hcr_el2 |= HCR_E2H;
 	if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
 		vcpu->arch.hcr_el2 &= ~HCR_RW;
+
+	/*
+	 * TID3: trap feature register accesses that we virtualise.
+	 * For now this is conditional, since no AArch32 feature regs
+	 * are currently virtualised.
+	 */
+	if (vcpu->arch.hcr_el2 & HCR_RW)
+		vcpu->arch.hcr_el2 |= HCR_TID3;
 }
 
 static inline unsigned long vcpu_get_hcr(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 525c01f..87fd590 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -86,10 +86,6 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 		write_sysreg(1 << 30, fpexc32_el2);
 		isb();
 	}
-
-	if (val & HCR_RW) /* for AArch64 only: */
-		val |= HCR_TID3; /* TID3: trap feature register accesses */
-
 	write_sysreg(val, hcr_el2);
 
 	/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
-- 
2.1.4

^ permalink raw reply related

* [PATCH 2/3] arm64: fpsimd: Abstract out binding of task's fpsimd context to the cpu.
From: Dave Martin @ 2017-12-01 15:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1512141582-17474-1-git-send-email-Dave.Martin@arm.com>

There is currently some duplicate logic to associate current's
FPSIMD context with the cpu when loading FPSIMD state into the cpu
regs.

Subsequent patches will update that logic, so in order to ensure it
only needs to be done in one place, this patch factors the relevant
code out into a new function fpsimd_bind_to_cpu().

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm64/kernel/fpsimd.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 143b3e7..007140b 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -992,6 +992,18 @@ void fpsimd_signal_preserve_current_state(void)
 }
 
 /*
+ * Associate current's FPSIMD context with this cpu
+ * Preemption must be disabled when calling this function.
+ */
+static void fpsimd_bind_to_cpu(void)
+{
+	struct fpsimd_state *st = &current->thread.fpsimd_state;
+
+	__this_cpu_write(fpsimd_last_state, st);
+	st->cpu = smp_processor_id();
+}
+
+/*
  * Load the userland FPSIMD state of 'current' from memory, but only if the
  * FPSIMD state already held in the registers is /not/ the most recent FPSIMD
  * state of 'current'
@@ -1004,11 +1016,8 @@ void fpsimd_restore_current_state(void)
 	local_bh_disable();
 
 	if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
-		struct fpsimd_state *st = &current->thread.fpsimd_state;
-
 		task_fpsimd_load();
-		__this_cpu_write(fpsimd_last_state, st);
-		st->cpu = smp_processor_id();
+		fpsimd_bind_to_cpu();
 	}
 
 	local_bh_enable();
@@ -1032,12 +1041,8 @@ void fpsimd_update_current_state(struct fpsimd_state *state)
 	}
 	task_fpsimd_load();
 
-	if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
-		struct fpsimd_state *st = &current->thread.fpsimd_state;
-
-		__this_cpu_write(fpsimd_last_state, st);
-		st->cpu = smp_processor_id();
-	}
+	if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE))
+		fpsimd_bind_to_cpu();
 
 	local_bh_enable();
 }
-- 
2.1.4

^ permalink raw reply related

* [PATCH 3/3] arm64/sve: KVM: Avoid dereference of dead task during guest entry
From: Dave Martin @ 2017-12-01 15:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1512141582-17474-1-git-send-email-Dave.Martin@arm.com>

When deciding whether to invalidate FPSIMD state cached in the cpu,
the backend function sve_flush_cpu_state() attempts to dereference
__this_cpu_read(fpsimd_last_state).  However, this is not safe:
there is no guarantee that the pointer is still valid, because the
task could have exited in the meantime.  For this reason, this
percpu pointer should only be assigned or compared, never
dereferenced.

This means that we need another means to get the appropriate value
of TIF_SVE for the associated task.

This patch solves this issue by adding a cached copy of the TIF_SVE
flag in fpsimd_last_state, which we can check without dereferencing
the task pointer.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
 arch/arm64/kernel/fpsimd.c | 28 ++++++++++++++++------------
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 007140b..3dc8058 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -114,7 +114,12 @@
  *   returned from the 2nd syscall yet, TIF_FOREIGN_FPSTATE is still set so
  *   whatever is in the FPSIMD registers is not saved to memory, but discarded.
  */
-static DEFINE_PER_CPU(struct fpsimd_state *, fpsimd_last_state);
+struct fpsimd_last_state_struct {
+	struct fpsimd_state *st;
+	bool sve_in_use;
+};
+
+static DEFINE_PER_CPU(struct fpsimd_last_state_struct, fpsimd_last_state);
 
 /* Default VL for tasks that don't set it explicitly: */
 static int sve_default_vl = -1;
@@ -905,7 +910,7 @@ void fpsimd_thread_switch(struct task_struct *next)
 		 */
 		struct fpsimd_state *st = &next->thread.fpsimd_state;
 
-		if (__this_cpu_read(fpsimd_last_state) == st
+		if (__this_cpu_read(fpsimd_last_state.st) == st
 		    && st->cpu == smp_processor_id())
 			clear_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
 		else
@@ -997,9 +1002,12 @@ void fpsimd_signal_preserve_current_state(void)
  */
 static void fpsimd_bind_to_cpu(void)
 {
+	struct fpsimd_last_state_struct *last =
+		this_cpu_ptr(&fpsimd_last_state);
 	struct fpsimd_state *st = &current->thread.fpsimd_state;
 
-	__this_cpu_write(fpsimd_last_state, st);
+	last->st = st;
+	last->sve_in_use = test_thread_flag(TIF_SVE);
 	st->cpu = smp_processor_id();
 }
 
@@ -1057,7 +1065,7 @@ void fpsimd_flush_task_state(struct task_struct *t)
 
 static inline void fpsimd_flush_cpu_state(void)
 {
-	__this_cpu_write(fpsimd_last_state, NULL);
+	__this_cpu_write(fpsimd_last_state.st, NULL);
 }
 
 /*
@@ -1070,14 +1078,10 @@ static inline void fpsimd_flush_cpu_state(void)
 #ifdef CONFIG_ARM64_SVE
 void sve_flush_cpu_state(void)
 {
-	struct fpsimd_state *const fpstate = __this_cpu_read(fpsimd_last_state);
-	struct task_struct *tsk;
-
-	if (!fpstate)
-		return;
+	struct fpsimd_last_state_struct const *last =
+		this_cpu_ptr(&fpsimd_last_state);
 
-	tsk = container_of(fpstate, struct task_struct, thread.fpsimd_state);
-	if (test_tsk_thread_flag(tsk, TIF_SVE))
+	if (last->st && last->sve_in_use)
 		fpsimd_flush_cpu_state();
 }
 #endif /* CONFIG_ARM64_SVE */
@@ -1272,7 +1276,7 @@ static inline void fpsimd_pm_init(void) { }
 #ifdef CONFIG_HOTPLUG_CPU
 static int fpsimd_cpu_dead(unsigned int cpu)
 {
-	per_cpu(fpsimd_last_state, cpu) = NULL;
+	per_cpu(fpsimd_last_state.st, cpu) = NULL;
 	return 0;
 }
 
-- 
2.1.4

^ permalink raw reply related

* [PATCH v3] usb: xhci: allow imod-interval to be configurable
From: Adam Wallis @ 2017-12-01 15:44 UTC (permalink / raw)
  To: linux-arm-kernel

The xHCI driver currently has the IMOD set to 160, which
translates to an IMOD interval of 40,000ns (160 * 250)ns

Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
introduced a QUIRK for the MTK platform to adjust this interval to 20,
which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
due to the fact that the MTK controller IMOD interval is 8 times
as much as defined in xHCI spec.

Instead of adding more quirk bits for additional platforms, this patch
introduces the ability for vendors to set the IMOD_INTERVAL as is
optimal for their platform. By using device_property_read_u32() on
"imod-interval", the IMOD INTERVAL can be specified in nano seconds. If
no interval is specified, the default of 40,000ns (IMOD=160) will be
used.

No bounds checking has been implemented due to the fact that a vendor
may have violated the spec and would need to specify a value outside of
the max 8,000 IRQs/second limit specified in the xHCI spec.

Signed-off-by: Adam Wallis <awallis@codeaurora.org>
---
changes from v2:
  * Added PCI default value [Mathias]
  * Removed xhci-mtk.h from xhci-plat.c [Chunfeng Yun]
  * Removed MTK quirk from xhci-plat and moved logic to xhci-mtk [Chunfeng]
  * Updated bindings Documentation to use proper units [Rob Herring]
  * Added imod-interval description and example to MTK binding documentation
changes from v1:
  * Removed device_property_read_u32() per suggestion from greg k-h
  * Used ER_IRQ_INTERVAL_MASK in place of (u16) cast

 Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 2 ++
 Documentation/devicetree/bindings/usb/usb-xhci.txt          | 1 +
 drivers/usb/host/xhci-mtk.c                                 | 9 +++++++++
 drivers/usb/host/xhci-pci.c                                 | 3 +++
 drivers/usb/host/xhci-plat.c                                | 4 ++++
 drivers/usb/host/xhci.c                                     | 7 ++-----
 drivers/usb/host/xhci.h                                     | 2 ++
 7 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
index 3059596..45bbf18 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
@@ -46,6 +46,7 @@ Optional properties:
  - pinctrl-names : a pinctrl state named "default" must be defined
  - pinctrl-0 : pin control group
 	See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+ - imod-interval: Default interval is 5000ns
 
 Example:
 usb30: usb at 11270000 {
@@ -66,6 +67,7 @@ usb30: usb at 11270000 {
 	usb3-lpm-capable;
 	mediatek,syscon-wakeup = <&pericfg>;
 	mediatek,wakeup-src = <1>;
+	imod-interval = <10000>;
 };
 
 2nd: dual-role mode with xHCI driver
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index ae6e484..89b68f1 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -29,6 +29,7 @@ Optional properties:
   - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
   - usb3-lpm-capable: determines if platform is USB3 LPM capable
   - quirk-broken-port-ped: set if the controller has broken port disable mechanism
+  - imod-interval: Default interval is 40000ns
 
 Example:
 	usb at f0931000 {
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index b62a1d2..278ea3b 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -674,6 +674,15 @@ static int xhci_mtk_probe(struct platform_device *pdev)
 
 	xhci = hcd_to_xhci(hcd);
 	xhci->main_hcd = hcd;
+
+	/*
+	 * imod_interval is the interrupt modulation value in nanoseconds.
+	 * The increment interval is 8 times as much as that defined in
+	 * the xHCI spec on MTK's controller.
+	 */
+	xhci->imod_interval = 5000;
+	device_property_read_u32(dev, "imod-interval", &xhci->imod_interval);
+
 	xhci->shared_hcd = usb_create_shared_hcd(driver, dev,
 			dev_name(dev), hcd);
 	if (!xhci->shared_hcd) {
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 7ef1274..efbe57b 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -234,6 +234,9 @@ static int xhci_pci_setup(struct usb_hcd *hcd)
 	if (!xhci->sbrn)
 		pci_read_config_byte(pdev, XHCI_SBRN_OFFSET, &xhci->sbrn);
 
+	/* imod_interval is the interrupt modulation value in nanoseconds. */
+	xhci->imod_interval = 40000;
+
 	retval = xhci_gen_setup(hcd, xhci_pci_quirks);
 	if (retval)
 		return retval;
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 09f164f..b78be87 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -269,6 +269,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
 	if (device_property_read_bool(&pdev->dev, "quirk-broken-port-ped"))
 		xhci->quirks |= XHCI_BROKEN_PORT_PED;
 
+	/* imod_interval is the interrupt modulation value in nanoseconds. */
+	xhci->imod_interval = 40000;
+	device_property_read_u32(sysdev, "imod-interval", &xhci->imod_interval);
+
 	hcd->usb_phy = devm_usb_get_phy_by_phandle(sysdev, "usb-phy", 0);
 	if (IS_ERR(hcd->usb_phy)) {
 		ret = PTR_ERR(hcd->usb_phy);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2424d30..0b7755b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -586,11 +586,8 @@ int xhci_run(struct usb_hcd *hcd)
 			"// Set the interrupt modulation register");
 	temp = readl(&xhci->ir_set->irq_control);
 	temp &= ~ER_IRQ_INTERVAL_MASK;
-	/*
-	 * the increment interval is 8 times as much as that defined
-	 * in xHCI spec on MTK's controller
-	 */
-	temp |= (u32) ((xhci->quirks & XHCI_MTK_HOST) ? 20 : 160);
+	temp |= (xhci->imod_interval / 250) & ER_IRQ_INTERVAL_MASK;
+
 	writel(temp, &xhci->ir_set->irq_control);
 
 	/* Set the HCD state before we enable the irqs */
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 99a014a..2a4177b 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1717,6 +1717,8 @@ struct xhci_hcd {
 	u8		max_interrupters;
 	u8		max_ports;
 	u8		isoc_threshold;
+	/* imod_interval in ns (I * 250ns) */
+	u32		imod_interval;
 	int		event_ring_max;
 	/* 4KB min, 128MB max */
 	int		page_size;
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply related

* [PATCH v2] usb: xhci: allow imod-interval to be configurable
From: Adam Wallis @ 2017-12-01 15:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1512099124.17567.156.camel@mhfsdcap03>

Hi Chunfeng,

On 11/30/2017 10:32 PM, Chunfeng Yun wrote:
> Hi,
> On Wed, 2017-11-29 at 10:52 -0500, Adam Wallis wrote:
>> The xHCI driver currently has the IMOD set to 160, which
>> translates to an IMOD interval of 40,000ns (160 * 250)ns
>>
>> Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
>> introduced a QUIRK for the MTK platform to adjust this interval to 20,
[..]
>>  #include "xhci-mvebu.h"
>>  #include "xhci-rcar.h"
>> +#include "xhci-mtk.h"
> Needn't it, MTK makes use of xhci-mtk.c but not xhci-plat.c
> 

Thanks - I made this change in V3.

[..]
>>  
>>  static struct hc_driver __read_mostly xhci_plat_hc_driver;
>>  
>> @@ -269,6 +270,18 @@ static int xhci_plat_probe(struct platform_device *pdev)
>>  	if (device_property_read_bool(&pdev->dev, "quirk-broken-port-ped"))
>>  		xhci->quirks |= XHCI_BROKEN_PORT_PED;
>>  
>> +	/*
>> +	 * imod_interval is the interrupt modulation value in nanoseconds.
>> +	 * The increment interval is 8 times as much as that defined in
>> +	 * the xHCI spec on MTK's controller. This quirk check exists to provide
>> +	 * backwards compatibility, however, this should be pushed into
>> +	 * the device tree files at some point in the future and
>> +	 * checking the quirk should be removed from xhci_plat_probe.
>> +	 */
>> +	xhci->imod_interval = xhci->quirks & XHCI_MTK_HOST ? 5000 : 40000;
> Can be moved into xhci-mtk.c for MTK quirk, like as following:
> 

I moved this into V3 as suggested - could you test on an MTK platform (I don't
have one available) to see if it performs as expected?




-- 
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply

* [PATCH V4 3/5] device property: Introduce a common API to fetch device match data
From: Sinan Kaya @ 2017-12-01 15:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20171201091325.weepl5rtxg4zqqyd@paasikivi.fi.intel.com>

On 12/1/2017 4:13 AM, Sakari Ailus wrote:
> Most of the dev->of_node checks have been removed from property.c and
> replaced by calls to the firmware specific fwnode operations. What remains
> should probably be moved there, too (apart from dev_fwnode).
> 
> How about adding a new op for this one to struct fwnode_operations in
> include/linux/fwnode.h?

Sure, let me look. I was following the get_dma function. Bad example I guess.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

^ permalink raw reply

* [PATCH 1/1] timecounter: Make cyclecounter struct part of timecounter struct
From: Richard Cochran @ 2017-12-01 15:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1512114454-26958-1-git-send-email-sagar.a.kamble@intel.com>

On Fri, Dec 01, 2017 at 01:17:34PM +0530, Sagar Arun Kamble wrote:
> There is no real need for the users of timecounters to define cyclecounter
> and timecounter variables separately. Since timecounter will always be
> based on cyclecounter, have cyclecounter struct as member of timecounter
> struct.

Could you please put the PTP maintainer onto CC?

Thanks,
Richard

^ permalink raw reply

* [PATCH v4 02/10] pinctrl: axp209: add pinctrl features
From: Maxime Ripard @ 2017-12-01 15:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <71c9da94df2a5938cb8c092e40f8e36eec0b01c3.1512135804.git-series.quentin.schulz@free-electrons.com>

On Fri, Dec 01, 2017 at 02:44:43PM +0100, Quentin Schulz wrote:
> +static void axp20x_gpio_set(struct gpio_chip *chip, unsigned offset,
> +			    int value)
> +{

checkpatch output:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'

> +static int axp20x_pmx_set_mux(struct pinctrl_dev *pctldev,
> +			      unsigned int function, unsigned int group)
> +{
> +	struct axp20x_gpio *gpio = pinctrl_dev_get_drvdata(pctldev);
> +	unsigned int mask;
> +
> +	/* Every pin supports GPIO_OUT and GPIO_IN functions */
> +	if (function <= AXP20X_FUNC_GPIO_IN)
> +		return axp20x_pmx_set(pctldev, group,
> +				      gpio->funcs[function].muxval);
> +
> +	if (function == AXP20X_FUNC_LDO)
> +		mask = gpio->desc->ldo_mask;
> +	else
> +		mask = gpio->desc->adc_mask;

What is the point of this test...

> +	if (!(BIT(group) & mask))
> +		return -EINVAL;
> +
> +	/*
> +	 * We let the regulator framework handle the LDO muxing as muxing bits
> +	 * are basically also regulators on/off bits. It's better not to enforce
> +	 * any state of the regulator when selecting LDO mux so that we don't
> +	 * interfere with the regulator driver.
> +	 */
> +	if (function == AXP20X_FUNC_LDO)
> +		return 0;

... if you know that you're not going to do anything with one of the
outcomes. It would be better to just move that part above, instead of
doing the same test twice.

It looks good otherwise, 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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171201/13676615/attachment-0001.sig>

^ permalink raw reply

* [PATCH v4 06/10] pinctrl: axp209: add programmable ADC muxing value
From: Maxime Ripard @ 2017-12-01 15:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <a4f348914450705f1f784a2148559e19caf9e9fd.1512135804.git-series.quentin.schulz@free-electrons.com>

On Fri, Dec 01, 2017 at 02:44:47PM +0100, Quentin Schulz wrote:
> To prepare for patches that will add support for a new PMIC that has a
> different GPIO adc muxing value, add an adc_mux within axp20x_pctl
> structure and use it.
> 
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171201/32cd1e33/attachment.sig>

^ permalink raw reply

* Essential get_user fix missing from 3.10 aarch64
From: Jason A. Donenfeld @ 2017-12-01 15:57 UTC (permalink / raw)
  To: linux-arm-kernel

Hi stable/arm/Willy,

1f65c13efef69b6dc908e588f91a133641d8475c is an important commit,
because it involves evaluation of pointers from userspace. I'm running
into issues with RNDADDTOENTCNT reading bogus values, because p is
incremented twice as much as it should in this random.c block:

        case RNDADDENTROPY:
               if (!capable(CAP_SYS_ADMIN))
                       return -EPERM;
               if (get_user(ent_count, p++))
                       return -EFAULT;
               if (ent_count < 0)
                       return -EINVAL;
               if (get_user(size, p++))
                       return -EFAULT;
               retval = write_pool(&input_pool, (const char __user *)p,
                                   size);

That seems reasonable, but on aarch64, get_user is defined as:

#define get_user(x, ptr)                                                \
({                                                                      \
       might_sleep();                                                  \
       access_ok(VERIFY_READ, (ptr), sizeof(*(ptr))) ?                 \
               __get_user((x), (ptr)) :                                \
               ((x) = 0, -EFAULT);                                     \
})

Notice the multiple use of ptr.

I thought I had found something breathtakingly bad, until I realized
that it was already fixed in 2013 by Takahiro. It just wasn't marked
for stable.

Not sure if there's ever going to be another stable 3.10 release, but
if so, this would be an important one to backport.

Regards,
Jason

^ permalink raw reply

* [PATCH v4 10/10] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs
From: Maxime Ripard @ 2017-12-01 15:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <afc22693e34c11231fc85a0dc6af3ffb340ba9b2.1512135804.git-series.quentin.schulz@free-electrons.com>

On Fri, Dec 01, 2017 at 02:44:51PM +0100, Quentin Schulz wrote:
> On AXP813/818, GPIO0 and GPIO1 can be used as LDO as (respectively)
> ldo_io0 and ldo_io1.
> 
> Let's add the pinctrl properties to the said regulators.
> 
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>

Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171201/44cb2b61/attachment.sig>

^ permalink raw reply

* SCPI regressions in v4.15-rc1 on Amlogic SoCs.
From: Kevin Hilman @ 2017-12-01 15:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <9754d389-1dd4-e189-6c8f-c725d049dea8@gmail.com>

On Thu, Nov 30, 2017 at 11:08 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> Am 01.12.2017 um 01:21 schrieb Kevin Hilman:
>> Hi Sudeep,
>>
>> There's been a pretty major regression in v4.15-rc1 compared to v4.15
>> in SCPI causing warning splats on amlogic SoCs when cpufreq starts up
>> and tries to set the OPP for the first time[1].
>>
> Thanks for the report. Strange enough, it works perfectly fine on my
> Odroid-C2, see below log part from latest next kernel.

There are alot more amlogic SoCs out there that should've been tested
with this change, and you didn't Cc linux-amlogic or ask for more help
testing.  Now we're in a position to have major regressions on most
amlogic boards for v4.15.

> Your log seems to indicate that due to deferred probing something is
> not done in the right order.
> Can you bisect the issue? I'd assume that it's commit 931cf0c53e69
> ("firmware: arm_scpi: pre-populate dvfs info in scpi_probe").

I do not currnetly have the time to bisect this, and we're in the
"fixes" phase of the merge window so there is urgency.

I would much rather see these patches reverted, and actually tested on
affected platforms before they make it into mainline.

Sudeep, any chance of reverting these while we're still in the -rc phase?

Thanks,

Kevin

> Rgds, Heiner
>
> [    0.034293] soc soc0: Amlogic Meson GXBB (S905) Revision 1f:0 (c:1) Detected
> [    0.036666] c81004c0.serial: ttyAML0 at MMIO 0xc81004c0 (irq = 13, base_baud = 1500000) is a meson_uart
> [    0.606914] console [ttyAML0] enabled
> [    0.615031] loop: module loaded
> [    0.616117] meson-gx-mmc d0074000.mmc: allocated mmc-pwrseq
> [    0.643406] ledtrig-cpu: registered to indicate activity on CPUs
> [    0.644047] meson-sm: secure-monitor enabled
> [    0.648156] hidraw: raw HID events driver (C) Jiri Kosina
> [    0.653572] platform-mhu c883c404.mailbox: Platform MHU Mailbox registered
> [    0.660439] NET: Registered protocol family 17
> [    0.665031] registered taskstats version 1
> [    0.668689] Loading compiled-in X.509 certificates
> [    0.678049] meson-gx-mmc d0072000.mmc: Got CD GPIO
> [    0.712946] scpi_protocol scpi: SCP Protocol 0.0 Firmware 0.0.0 version
> [    0.715600] cpu cpu0: bL_cpufreq_init: CPU 0 initialized
> [    0.719245] arm_big_little: bL_cpufreq_register: Registered platform driver: scpi
> [    0.727344] mmc0: new HS400 MMC card at address 0001
> [    0.729179] hctosys: unable to open rtc device (rtc0)
> [    0.729355] USB_OTG_PWR: disabling
> [    0.729358] TFLASH_VDD: disabling
> [    0.729361] TF_IO: disabling
> [    0.747230] mmcblk0: mmc0:0001 DJNB4R 116 GiB
> [    0.752588] mmcblk0boot0: mmc0:0001 DJNB4R partition 1 4.00 MiB
> [    0.757220] mmcblk0boot1: mmc0:0001 DJNB4R partition 2 4.00 MiB
> [    0.762274] mmcblk0rpmb: mmc0:0001 DJNB4R partition 3 4.00 MiB, chardev (249:0)
> [    0.770243]  mmcblk0: p1
> [    0.781732] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
>
>
>> I ran out of time to narrow it down further since there have been
>> quite a few changes since v4.14, but simply reverting
>> drivers/firmware/arm_scpi.c to its v4.14 state gets things working
>> again.
>>
>> This has been happening for awhile, and we should've caught it sooner
>> in kernelCI.org, however this warning splat still allows the kernel to
>> finish booting, so it still resulted in a PASS for the boot test.
>> That combined with the fact that we've been tracking some other
>> regressions, we didn't notice it until now.
>>
>> Also, is this the expected result for the pre-1.0 firmware:
>>
>>     scpi_protocol scpi: SCP Protocol 0.0 Firmware 0.0.0 version
>>
>> Kevin
>>
>> [1] Here are a few boot logs from v4.15-rc1 with the splat:
>>
>> https://storage.kernelci.org/mainline/master/v4.15-rc1/arm64/defconfig/lab-baylibre-seattle/boot-meson-gxl-s905x-khadas-vim.html
>>
>> https://storage.kernelci.org/mainline/master/v4.15-rc1/arm64/defconfig/lab-baylibre-seattle/boot-meson-gxbb-p200.html
>>
>> https://storage.kernelci.org/mainline/master/v4.15-rc1/arm64/defconfig/lab-baylibre-seattle/boot-meson-gxl-s905d-p230.html
>>
>

^ permalink raw reply

* [PATCH 1/2] arm64: dts: a64-olinuxino: Enable RTL8723BS WiFi
From: Maxime Ripard @ 2017-12-01 16:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1512119165-15290-1-git-send-email-jagan@amarulasolutions.com>

On Fri, Dec 01, 2017 at 02:36:04PM +0530, Jagan Teki wrote:
> Enable RTL8723BS WiFi chip on a64-olinuxino board:
> - WiFi SDIO interface is connected to MMC1
> - WiFi REG_ON pin connected to gpio PL2: attach to mmc-pwrseq
> - WiFi HOST_WAKE pin connected to gpio PL3
> 
> To make rtl8723bs chip to work build it as module to and run
> CONFIG_RTL8723BS=m

You can definitely use that driver without building it as a module.

Once that part of the commit log has been removed,
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171201/5fa06d0d/attachment.sig>

^ permalink raw reply

* [PATCH 2/2] arm64: allwinner: a64-sopine: Use dcdc1 regulator instead of vcc3v3
From: Maxime Ripard @ 2017-12-01 16:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1512119165-15290-2-git-send-email-jagan@amarulasolutions.com>

Hi

On Fri, Dec 01, 2017 at 02:36:05PM +0530, Jagan Teki wrote:
> Since current tree support AXP803 regulators,
> replace fixed regulator vcc3v3 with AXP803 dcdc1 regulator.
> 
> Tested mmc0 on sopine baseboard.
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>

Is it supposed to be a fix?

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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171201/a035a340/attachment.sig>

^ permalink raw reply

* SCPI regressions in v4.15-rc1 on Amlogic SoCs.
From: Jerome Brunet @ 2017-12-01 16:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAOi56cXCBAJO6iOONTENqGdm9kE+t4fGYgTENupzkRgHjJfykw@mail.gmail.com>

On Thu, 2017-11-30 at 16:21 -0800, Kevin Hilman wrote:
> Hi Sudeep,
> 
> There's been a pretty major regression in v4.15-rc1 compared to v4.15
> in SCPI causing warning splats on amlogic SoCs when cpufreq starts up
> and tries to set the OPP for the first time[1].
> 
> I ran out of time to narrow it down further since there have been
> quite a few changes since v4.14, but simply reverting
> drivers/firmware/arm_scpi.c to its v4.14 state gets things working
> again.

Same thing for me. One of my early libretech-cc gets completely stuck during
boot with v4.15-rc1

reverting drivers/firmware/arm_scpi.c to v4.14 fixes the problem.

On the u-art, we see traces that appear to be coming from the FW:
> domain-0 init dvfs: 4 

My platform gets stuck on one of these traces with v4.15-rc1

> 
> This has been happening for awhile, and we should've caught it sooner
> in kernelCI.org, however this warning splat still allows the kernel to
> finish booting, so it still resulted in a PASS for the boot test.
> That combined with the fact that we've been tracking some other
> regressions, we didn't notice it until now.
> 
> Also, is this the expected result for the pre-1.0 firmware:
> 
>     scpi_protocol scpi: SCP Protocol 0.0 Firmware 0.0.0 version
> 
> Kevin
> 
> [1] Here are a few boot logs from v4.15-rc1 with the splat:
> 
> https://storage.kernelci.org/mainline/master/v4.15-rc1/arm64/defconfig/lab-bay
> libre-seattle/boot-meson-gxl-s905x-khadas-vim.html
> 
> https://storage.kernelci.org/mainline/master/v4.15-rc1/arm64/defconfig/lab-bay
> libre-seattle/boot-meson-gxbb-p200.html
> 
> https://storage.kernelci.org/mainline/master/v4.15-rc1/arm64/defconfig/lab-bay
> libre-seattle/boot-meson-gxl-s905d-p230.html
> 
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

^ permalink raw reply

* Essential get_user fix missing from 3.10 aarch64
From: Willy Tarreau @ 2017-12-01 16:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAHmME9qtH1ywCS+4ebg8myxWsAUbcqG6Rcus+Nt0DBLLaMu4wQ@mail.gmail.com>

Hi Jason,

On Fri, Dec 01, 2017 at 04:57:26PM +0100, Jason A. Donenfeld wrote:
> Not sure if there's ever going to be another stable 3.10 release, but
> if so, this would be an important one to backport.

Thanks for the heads up but unfortunately there's not going to be any
more 3.10, it's been announced as EOL soon since last January or so,
and definitely so with 3.10.108.

Your finding may interest distros still maintaining their own 3.10 though.

Thanks,
Willy

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox