Re: [Outreachy kernel] [PATCH v6] staging: Use buf_lock instead of mlock and Refactor code

[SIMRAN SINGHAL]

On Tue, Mar 21, 2017 at 10:18 PM, Alison Schofield  wrote:
> On Mon, Mar 20, 2017 at 01:36:21AM +0530, simran singhal wrote:
>
> Hi Simran,
>
> I going to ask for a v7 without looking at the code ;)
> Subject line needs subsystem and driver.
> Subject and log message can be improved.

Hi Alison,
I have already sent v7 with changed subject.

>
>> The IIO subsystem is redefining iio_dev->mlock to be used by
>> the IIO core only for protecting device operating mode changes.
>> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.
>>
>> In this driver, mlock was being used to protect hardware state
>> changes. Replace it with buf_lock in the devices global data.
>^^^ this was not done
>>
>> As buf_lock protects both the adis16060_spi_write() and
>> adis16060_spi_read() functions and both are always called in
>> pair. First write, then read. Thus, refactor the code to have
>> one single function adis16060_spi_write_than_read() which is
>> protected by the existing buf_lock.
> This was done.  So, you were able to obsolete the need for mlock
> by creating the paired function.
>
>>
>> Removed nested locks as the function adis16060_read_raw call
>> a lock on >buf_lock and then calls the function
>> adis16060_spi_write which again tries to get hold
>> of the same lock.
>  this was not done.  Yes, you avoided nested locks through
> proper coding, but we don't want to give the impression in the
> log message that there was a pre-existing nested lock issue.
>
> I did checkpatch & compile it...but looked no further yet.
>
> alisons
>>
>> Signed-off-by: simran singhal 
>> ---
>>
>>  v6:
>>-Change commit message
>>-Remove nested lock
>>
>>  drivers/staging/iio/gyro/adis16060_core.c | 40 
>> ++-
>>  1 file changed, 13 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
>> b/drivers/staging/iio/gyro/adis16060_core.c
>> index c9d46e7..1c6de46 100644
>> --- a/drivers/staging/iio/gyro/adis16060_core.c
>> +++ b/drivers/staging/iio/gyro/adis16060_core.c
>> @@ -40,25 +40,17 @@ struct adis16060_state {
>>
>>  static struct iio_dev *adis16060_iio_dev;
>>
>> -static int adis16060_spi_write(struct iio_dev *indio_dev, u8 val)
>> +static int adis16060_spi_write_than_read(struct iio_dev *indio_dev,
>> +  u8 conf, u16 *val)
>>  {
>>   int ret;
>>   struct adis16060_state *st = iio_priv(indio_dev);
>>
>> - mutex_lock(>buf_lock);
>> - st->buf[2] = val; /* The last 8 bits clocked in are latched */
>> + st->buf[2] = conf; /* The last 8 bits clocked in are latched */
>>   ret = spi_write(st->us_w, st->buf, 3);
>> - mutex_unlock(>buf_lock);
>> -
>> - return ret;
>> -}
>> -
>> -static int adis16060_spi_read(struct iio_dev *indio_dev, u16 *val)
>> -{
>> - int ret;
>> - struct adis16060_state *st = iio_priv(indio_dev);
>>
>> - mutex_lock(>buf_lock);
>> + if (ret < 0)
>> + return ret;
>>
>>   ret = spi_read(st->us_r, st->buf, 3);
>>
>> @@ -69,8 +61,8 @@ static int adis16060_spi_read(struct iio_dev *indio_dev, 
>> u16 *val)
>>*/
>>   if (!ret)
>>   *val = ((st->buf[0] & 0x3) << 12) |
>> - (st->buf[1] << 4) |
>> - ((st->buf[2] >> 4) & 0xF);
>> +  (st->buf[1] << 4) |
>> +  ((st->buf[2] >> 4) & 0xF);
>>   mutex_unlock(>buf_lock);
>>
>>   return ret;
>> @@ -83,20 +75,18 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>>  {
>>   u16 tval = 0;
>>   int ret;
>> + struct adis16060_state *st = iio_priv(indio_dev);
>>
>>   switch (mask) {
>>   case IIO_CHAN_INFO_RAW:
>>   /* Take the iio_dev status lock */
>> - mutex_lock(_dev->mlock);
>> - ret = adis16060_spi_write(indio_dev, chan->address);
>> + mutex_lock(>buf_lock);
>> + ret = adis16060_spi_write_than_read(indio_dev,
>> + chan->address, );
>> + mutex_unlock(>buf_lock);
>>   if (ret < 0)
>> - goto out_unlock;
>> + return ret;
>>
>> - ret = adis16060_spi_read(indio_dev, );
>> - if (ret < 0)
>> - goto out_unlock;
>> -
>> - mutex_unlock(_dev->mlock);
>>   *val = tval;
>>   return IIO_VAL_INT;
>>   case IIO_CHAN_INFO_OFFSET:
>> @@ -110,10 +100,6 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>>   }
>>
>>   return -EINVAL;
>> -
>> -out_unlock:
>> - mutex_unlock(_dev->mlock);
>> - return ret;
>>  }
>>
>>  static const struct iio_info adis16060_info = {
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving 

Re: [RESEND PATCH 1/7] time: Delete do_sys_setimeofday()

[kbuild test robot]

Hi Deepa,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc3 next-20170321]
[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/Deepa-Dinamani/Change-k_clock-interfaces-to-use-timespec64/20170321-234145
config: alpha-defconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/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=alpha 

All errors (new ones prefixed by >>):

   arch/alpha/kernel/osf_sys.c: In function 'SYSC_osf_settimeofday':
>> arch/alpha/kernel/osf_sys.c:1032:9: error: implicit declaration of function 
>> 'do_sys_settimeofday' [-Werror=implicit-function-declaration]
 return do_sys_settimeofday(tv ?  : NULL, tz ?  : NULL);
^~~
   cc1: some warnings being treated as errors

vim +/do_sys_settimeofday +1032 arch/alpha/kernel/osf_sys.c

^1da177e Linus Torvalds 2005-04-16  1026}
^1da177e Linus Torvalds 2005-04-16  1027if (tz) {
^1da177e Linus Torvalds 2005-04-16  1028if 
(copy_from_user(, tz, sizeof(*tz)))
^1da177e Linus Torvalds 2005-04-16  1029return -EFAULT;
^1da177e Linus Torvalds 2005-04-16  1030}
^1da177e Linus Torvalds 2005-04-16  1031  
^1da177e Linus Torvalds 2005-04-16 @1032return do_sys_settimeofday(tv ? 
 : NULL, tz ?  : NULL);
^1da177e Linus Torvalds 2005-04-16  1033  }
^1da177e Linus Torvalds 2005-04-16  1034  
baa73d9e Nicolas Pitre  2016-11-11  1035  asmlinkage long 
sys_ni_posix_timers(void);

:: The code at line 1032 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds <torva...@ppc970.osdl.org>
:: CC: Linus Torvalds <torva...@ppc970.osdl.org>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs

[Rafael J. Wysocki]

On Tuesday, March 21, 2017 06:00:17 PM Peter Zijlstra wrote:
> On Tue, Mar 21, 2017 at 04:18:52PM +0100, Rafael J. Wysocki wrote:
> > +static bool sugov_cpu_is_busy(struct sugov_cpu *sg_cpu)
> > +{
> > +   unsigned long idle_calls = tick_nohz_get_idle_calls();
> > +   bool not_idle = idle_calls == sg_cpu->saved_idle_calls;
> > +
> > +   sg_cpu->saved_idle_calls = idle_calls;
> > +   return not_idle && this_rq()->rd->overload;
> > +}
> 
> So I really don't understand the rd->overload thing. What is it supposed
> to do here?

The idea was that if the CPU was running one task saturating the capacity which
then was migrated out of it, the frequency should still be reduced.

And since rd->overload covers all CPUs (in general) it kind of tells us whether
or not there are other tasks to replace the migrated one any time soon.

However, if there are no tasks to replace the migrated one, the CPU will go
idle quickly (as there are no taks to run on it), in which case keeping the
current frequency on it shouldn't matter.

In all of the other cases keeping the current frequency is the right thing to
do IMO.

So, it looks like checking this_rq()->rd->overload doesn't really help after 
all. :-)

Thanks,
Rafael

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

[Dmitry Safonov]

On 03/21/2017 08:45 PM, Andy Lutomirski wrote:

On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov  wrote:

On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote:
...

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index d6b784a5520d..d3d4d9abcaf8 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -519,8 +519,14 @@ void set_personality_ia32(bool x32)
  if (current->mm)
  current->mm->context.ia32_compat = TIF_X32;
  current->personality &= ~READ_IMPLIES_EXEC;
- /* in_compat_syscall() uses the presence of the x32
-syscall bit flag to determine compat status */
+ /*
+  * in_compat_syscall() uses the presence of the x32
+  * syscall bit flag to determine compat status.
+  * On the bitness of syscall relies x86 mmap() code,
+  * so set x32 syscall bit right here to make
+  * in_compat_syscall() work during exec().
+  */
+ task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
  current->thread.status &= ~TS_COMPAT;


Hi! I must admit I didn't follow close the overall series (so can't
comment much here :) but I have a slightly unrelated question -- is
there a way to figure out if task is running in x32 mode say with
some ptrace or procfs sign?


You should be able to figure out of a *syscall* is x32 by simply
looking at bit 30 in the syscall number.  (This is unlike i386, which
is currently not reflected in ptrace.)


The process could be stopped with PTRACE_SEIZE and I think, it'll not
have x32 syscall bit at that moment.

I guess the question comes from that we're releasing CRIU 3.0 with
32-bit C/R and some other cool stuff, but we don't support x32 yet.
As we don't want release a thing that we aren't properly testing.
So for a while we should error on dumping x32 applications.

I think, the best way for now is to check physicall address of vdso
from /proc/.../pagemap. If it's CONFIG_VDSO=n kernel, I guess we could
also add check for %ds from ptrace's register set. For x32 it's set to
__USER_DS, while for native it's 0 (looking at start_thread() and
compat_start_thread()). The application can simply change it without
any consequence - so it's not very reliable, we could only warn at
catching it, not rely on this.



Do we actually have an x32 per-task mode at all?  If so, maybe we can
just remove it on top of Dmitry's series.


--
 Dmitry

[PATCH v2 3/7] pinctrl: armada-37xx: Add pin controller support for Armada 37xx

[Gregory CLEMENT]

The Armada 37xx SoC come with 2 pin controllers: one on the south
bridge (managing 28 pins) and one on the north bridge (managing 36 pins).

At the hardware level the controller configure the pins by group and not
pin by pin. This constraint is reflected in the design of the driver:
only the group related functions are implemented.

Signed-off-by: Gregory CLEMENT 
---
 drivers/pinctrl/Makefile|   2 +-
 drivers/pinctrl/mvebu/Kconfig   |   7 +-
 drivers/pinctrl/mvebu/Makefile  |   3 +-
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 605 +-
 4 files changed, 615 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c

diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a251f439626f..95080811f36f 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -44,7 +44,7 @@ obj-y += bcm/
 obj-$(CONFIG_PINCTRL_BERLIN)   += berlin/
 obj-y  += freescale/
 obj-$(CONFIG_X86)  += intel/
-obj-$(CONFIG_PINCTRL_MVEBU)+= mvebu/
+obj-y  += mvebu/
 obj-y  += nomadik/
 obj-$(CONFIG_PINCTRL_PXA)  += pxa/
 obj-$(CONFIG_ARCH_QCOM)+= qcom/
diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig
index 170602407c0d..5bade32d3089 100644
--- a/drivers/pinctrl/mvebu/Kconfig
+++ b/drivers/pinctrl/mvebu/Kconfig
@@ -39,3 +39,10 @@ config PINCTRL_ORION
select PINCTRL_MVEBU
 
 endif
+
+config PINCTRL_ARMADA_37XX
+   bool
+   select GENERIC_PINCONF
+   select MFD_SYSCON
+   select PINCONF
+   select PINMUX
diff --git a/drivers/pinctrl/mvebu/Makefile b/drivers/pinctrl/mvebu/Makefile
index 18270cd5ea43..60c245a60f39 100644
--- a/drivers/pinctrl/mvebu/Makefile
+++ b/drivers/pinctrl/mvebu/Makefile
@@ -1,4 +1,4 @@
-obj-y  += pinctrl-mvebu.o
+obj-$(CONFIG_PINCTRL_MVEBU)+= pinctrl-mvebu.o
 obj-$(CONFIG_PINCTRL_DOVE) += pinctrl-dove.o
 obj-$(CONFIG_PINCTRL_KIRKWOOD) += pinctrl-kirkwood.o
 obj-$(CONFIG_PINCTRL_ARMADA_370) += pinctrl-armada-370.o
@@ -6,4 +6,5 @@ obj-$(CONFIG_PINCTRL_ARMADA_375) += pinctrl-armada-375.o
 obj-$(CONFIG_PINCTRL_ARMADA_38X) += pinctrl-armada-38x.o
 obj-$(CONFIG_PINCTRL_ARMADA_39X) += pinctrl-armada-39x.o
 obj-$(CONFIG_PINCTRL_ARMADA_XP)  += pinctrl-armada-xp.o
+obj-$(CONFIG_PINCTRL_ARMADA_37XX)  += pinctrl-armada-37xx.o
 obj-$(CONFIG_PINCTRL_ORION)  += pinctrl-orion.o
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
new file mode 100644
index ..98cde04e07e1
--- /dev/null
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -0,0 +1,605 @@
+/*
+ * Marvell 37xx SoC pinctrl driver
+ *
+ * Copyright (C) 2017 Marvell
+ *
+ * Gregory CLEMENT 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2 or later. This program is licensed "as is"
+ * without any warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../pinctrl-utils.h"
+
+#define OUTPUT_EN  0x0
+#define OUTPUT_CTL 0x20
+#define SELECTION  0x30
+
+static int global_pin;
+
+#define NB_FUNCS 2
+#define GPIO_PER_REG   32
+
+/**
+ * struct armada_37xx_pin_group: represents group of pins of a pinmux function.
+ * The pins of a pinmux groups are composed of one or two groups of contiguous
+ * pins.
+ * @name:  Name of the pin group, used to lookup the group.
+ * @start_pins:Index of the first pin of the main range of pins 
belonging to
+ * the group
+ * @npins: Number of pins included in the first range
+ * @reg_mask:  Bit mask matching the group in the selection register
+ * @extra_pins:Index of the first pin of the optional second range of 
pins
+ * belonging to the group
+ * @npins: Number of pins included in the second optional range
+ * @funcs: A list of pinmux functions that can be selected for this group.
+ * @pins:  Total number pins included in the group
+ */
+struct armada_37xx_pin_group {
+   const char  *name;
+   unsigned intstart_pin;
+   unsigned intnpins;
+   u32 reg_mask;
+   unsigned intextra_pin;
+   unsigned intextra_npins;
+   const char  *funcs[NB_FUNCS];
+   unsigned int*pins;
+};
+
+struct armada_37xx_pin_data {
+   u8  nr_pins;
+   char*name;
+   struct armada_37xx_pin_group*groups;
+   int ngroups;
+};
+
+struct armada_37xx_pmx_func {
+   const char  *name;
+   const char  **groups;
+   unsigned intngroups;
+};
+
+struct 

[PATCH v2 4/7] pinctrl: armada-37xx: Add gpio support

[Gregory CLEMENT]

GPIO management is pretty simple and is part of the same IP than the pin
controller for the Armada 37xx SoCs.  This patch adds the GPIO support to
the pinctrl-armada-37xx.c file, it also allows sharing common functions
between the gpiolib and the pinctrl drivers.

Signed-off-by: Gregory CLEMENT 
---
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 134 ++---
 1 file changed, 119 insertions(+), 15 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index 98cde04e07e1..e41e2d02aca7 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -10,6 +10,7 @@
  * without any warranty of any kind, whether express or implied.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +25,8 @@
 #include "../pinctrl-utils.h"
 
 #define OUTPUT_EN  0x0
+#define INPUT_VAL  0x10
+#define OUTPUT_VAL 0x18
 #define OUTPUT_CTL 0x20
 #define SELECTION  0x30
 
@@ -75,6 +78,7 @@ struct armada_37xx_pinctrl {
struct regmap   *regmap;
struct armada_37xx_pin_data *data;
struct device   *dev;
+   struct gpio_chipgpio_chip;
struct pinctrl_desc pctl;
struct pinctrl_dev  *pctl_dev;
struct armada_37xx_pin_group*groups;
@@ -312,51 +316,99 @@ static int armada_37xx_pmx_set(struct pinctrl_dev 
*pctldev,
return armada_37xx_pmx_set_by_name(pctldev, name, grp);
 }
 
-static int armada_37xx_pmx_direction_input(struct armada_37xx_pinctrl *info,
-  unsigned int offset)
+static inline void aramda_37xx_update_reg(unsigned int *reg,
+ unsigned int offset)
 {
-   unsigned int reg = OUTPUT_EN;
-   unsigned int mask;
-
+   /* We never have more than 2 registers */
if (offset >= GPIO_PER_REG) {
offset -= GPIO_PER_REG;
-   reg += sizeof(u32);
+   *reg += sizeof(u32);
}
+}
+
+static int armada_37xx_gpio_direction_input(struct gpio_chip *chip,
+   unsigned int offset)
+{
+   struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
+   unsigned int reg = OUTPUT_EN;
+   unsigned int mask;
+
+   aramda_37xx_update_reg(, offset);
mask = BIT(offset);
 
return regmap_update_bits(info->regmap, reg, mask, 0);
 }
 
+static int armada_37xx_gpio_get_direction(struct gpio_chip *chip,
+ unsigned int offset)
+{
+   struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
+   unsigned int reg = OUTPUT_EN;
+   unsigned int val, mask;
+
+   aramda_37xx_update_reg(, offset);
+   mask = BIT(offset);
+
+   regmap_read(info->regmap, reg, );
 
+   return !(val & mask);
+}
 
-static int armada_37xx_pmx_direction_output(struct armada_37xx_pinctrl *info,
-   unsigned int offset, int value)
+static int armada_37xx_gpio_direction_output(struct gpio_chip *chip,
+unsigned int offset, int value)
 {
+   struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
unsigned int reg = OUTPUT_EN;
unsigned int mask;
 
-   if (offset >= GPIO_PER_REG) {
-   offset -= GPIO_PER_REG;
-   reg += sizeof(u32);
-   }
+   aramda_37xx_update_reg(, offset);
mask = BIT(offset);
 
return regmap_update_bits(info->regmap, reg, mask, mask);
 }
 
+static int armada_37xx_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+   struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
+   unsigned int reg = INPUT_VAL;
+   unsigned int val, mask;
+
+   aramda_37xx_update_reg(, offset);
+   mask = BIT(offset);
+
+   regmap_read(info->regmap, reg, );
+
+   return (val & mask) != 0;
+}
+
+static void armada_37xx_gpio_set(struct gpio_chip *chip, unsigned int offset,
+int value)
+{
+   struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
+   unsigned int reg = OUTPUT_VAL;
+   unsigned int mask, val;
+
+   aramda_37xx_update_reg(, offset);
+   mask = BIT(offset);
+   val = value ? mask : 0;
+
+   regmap_update_bits(info->regmap, reg, mask, val);
+}
+
 static int armada_37xx_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
  struct pinctrl_gpio_range *range,
  unsigned int offset, bool input)
 {
struct armada_37xx_pinctrl *info = pinctrl_dev_get_drvdata(pctldev);
+   struct gpio_chip *chip = range->gc;
 
dev_dbg(info->dev, "gpio_direction for pin %u as %s-%d to %s\n",
offset, range->name, offset, input ? "input" : "output");
 
  

[PATCH v3 03/11] ARM: dts: sun8i: sina33: add cpu-supply

[Quentin Schulz]

This adds the cpu-supply DT property to the cpu0 DT node needed by
the board to adapt the regulator voltage depending on the currently used
OPP.

Signed-off-by: Quentin Schulz 
---
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts 
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index cde14b3..d84f1bd 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -83,6 +83,10 @@
status = "okay";
 };
 
+ {
+   cpu-supply = <_dcdc3>;
+};
+
  {
status = "okay";
 };
-- 
2.9.3

[PATCH v2 0/7] Hi,

[Gregory CLEMENT]

this series add support for the pin and gpio controllers present on
the Armada 37xx SoCs.

Each Armada 37xx SoC comes with 2 pin controllers: one on the south
bridge (managing 28 pins) and one on the north bridge (managing 36 pins).

At the hardware level the controller configure the pins by group and not
pin by pin.

The gpio controller is also capable to handle interrupt from gpio.

Gregory

Gregory CLEMENT (7):
  pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers
  arm64: marvell: enable the Armada 37xx pinctrl driver
  pinctrl: armada-37xx: Add pin controller support for Armada 37xx
  pinctrl: armada-37xx: Add gpio support
  pinctrl: aramda-37xx: Add irqchip support
  ARM64: dts: marvell: Add pinctrl nodes for Armada 3700
  ARM64: dts: marvell: armada37xx: add pinctrl definition

 Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt |   
7 +-
 Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt | 
143 +++-
 arch/arm64/Kconfig.platforms  |   
2 +-
 arch/arm64/boot/dts/marvell/armada-3720-db.dts|   
8 +-
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi  |  
71 +-
 drivers/pinctrl/Makefile  |   
2 +-
 drivers/pinctrl/mvebu/Kconfig |   
7 +-
 drivers/pinctrl/mvebu/Makefile|   
3 +-
 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c   | 
918 -
 9 files changed, 1153 insertions(+), 8 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
 create mode 100644 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c

base-commit: c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201
-- 
git-series 0.9.1

[PATCH v2 1/7] pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers

[Gregory CLEMENT]

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 
---
 Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt |   
7 ++--
 Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt | 
143 -
 2 files changed, 147 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt 
b/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
index a88f1f05fbd6..4c0807f28cfa 100644
--- a/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
+++ b/Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
@@ -5,6 +5,7 @@ reading the gpio latch register.
 
 This node must be a subnode of the node exposing the register address
 of the GPIO block where the gpio latch is located.
+See Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
 
 Required properties:
 - compatible : shall be one of the following:
@@ -16,9 +17,9 @@ Optional properties:
output names ("xtal")
 
 Example:
-gpio1: gpio@13800 {
-   compatible = "marvell,armada-3700-gpio", "syscon", "simple-mfd";
-   reg = <0x13800 0x1000>;
+pinctrl_nb: pinctrl-nb@13800 {
+   compatible = "armada3710-nb-pinctrl", "syscon", "simple-mfd";
+   reg = <0x13800 0x100>, <0x13C00 0x20>;
 
xtalclk: xtal-clk {
compatible = "marvell,armada-3700-xtal-clock";
diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
new file mode 100644
index ..9eabb42fbd53
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-37xx-pinctrl.txt
@@ -0,0 +1,143 @@
+* Marvell Armada 37xx SoC pin and gpio controller
+
+Each Armada 37xx SoC come with two pin and gpio controller one for the
+south bridge and the other for the north bridge.
+
+Inside this set of register the gpio latch allows exposing some
+configuration of the SoC and especially the clock frequency of the
+xtal. Hence, this node is a represent as syscon allowing sharing the
+register between multiple hardware block.
+
+GPIO and pin controller:
+
+
+Refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning
+of the phrase "pin configuration node".
+
+Required properties for pinctrl driver:
+
+- compatible:  "marvell,armada3710-sb-pinctrl", "syscon, "simple-mfd"
+   for the south bridge
+   "marvell,armada3710-nb-pinctrl", "syscon, "simple-mfd"
+   for the north bridge
+- reg: The first set of register are for pinctrl/gpio and the second
+  set for the interrupt controller
+- interrupts: list of the interrupt use by the gpio
+
+Available groups and functions for the North bridge:
+
+group: jtag
+ - pins 20-24
+ - functions jtag, gpio
+
+group sdio0
+ - pins 8-10
+ - functions sdio, gpio
+
+group emmc_nb
+ - pins 27-35
+ - functions emmc, gpio
+
+group pwm0
+ - pin 11 (GPIO1-11)
+ - functions pwm, gpio
+
+group pwm1
+ - pin 12
+ - functions pwm, gpio
+
+group pwm2
+ - pin 13
+ - functions pwm, gpio
+
+group pwm3
+ - pin 14
+ - functions pwm, gpio
+
+group pmic1
+ - pin 17
+ - functions pmic, gpio
+
+group pmic0
+ - pin 16
+ - functions pmic, gpio
+
+group i2c2
+ - pins 2-3
+ - functions i2c, gpio
+
+group i2c1
+ - pins 0-1
+ - functions i2c, gpio
+
+group spi_cs1
+ - pin 17
+ - functions spi, gpio
+
+group spi_cs2
+ - pin 18
+ - functions spi, gpio
+
+group spi_cs3
+ - pin 19
+ - functions spi, gpio
+
+group onewire
+ - pin 4
+ - functions onewire, gpio
+
+group uart1
+ - pins 25-26
+ - functions uart, gpio
+
+group spi_quad
+ - pins 15-16
+ - functions spi, gpio
+
+group uart_2
+ - pins 9-10
+ - functions uart, gpio
+
+Available groups and functions for the South bridge:
+
+group usb32_drvvbus0
+ - pin 36
+ - functions drvbus, gpio
+
+group usb2_drvvbus1
+ - pin 37
+ - functions drvbus, gpio
+
+group sdio_sb
+ - pins 60-64
+ - functions sdio, gpio
+
+group rgmii
+ - pins 42-55
+ - functions mii, gpio
+
+group pcie1
+ - pins 39-40
+ - functions pcie, gpio
+
+group ptp
+ - pins 56-58
+ - functions ptp, gpio
+
+group ptp_clk
+ - pin 57
+ - functions ptp, mii
+
+group ptp_trig
+ - pin 58
+ - functions ptp, mii
+
+group mii_col
+ - pin 59
+ - functions mii, mii_err
+
+Xtal Clock bindings for Marvell Armada 37xx SoCs
+
+
+see Documentation/devicetree/bindings/clock/armada3700-xtal-clock.txt
-- 
git-series 0.9.1

[PATCH v2 2/7] arm64: marvell: enable the Armada 37xx pinctrl driver

[Gregory CLEMENT]

This commit makes sure the driver for the Armada 37xx pin controller is
enabled.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm64/Kconfig.platforms | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 129cc5ae4091..f2bb1691264f 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -105,6 +105,8 @@ config ARCH_MVEBU
select ARMADA_37XX_CLK
select MVEBU_ODMI
select MVEBU_PIC
+   select PINCTRL
+   select PINCTRL_ARMADA_37XX
help
  This enables support for Marvell EBU familly, including:
   - Armada 3700 SoC Family
-- 
git-series 0.9.1

[PATCH v3 08/11] ARM: dtsi: sun8i: a33: add thermal sensor

[Quentin Schulz]

This adds the DT node for the thermal sensor present in the Allwinner
A33 GPADC.

Signed-off-by: Quentin Schulz 
---

v3:
  - switched compatible to allwinner,sun8i-a33-ths,
  - renamed DT node name and label to ths to better match datasheet's name,

 arch/arm/boot/dts/sun8i-a33.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index b1cdff66..f391f71 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -266,6 +266,13 @@
status = "disabled";
};
 
+   ths: ths@01c25000 {
+   compatible = "allwinner,sun8i-a33-ths";
+   reg = <0x01c25000 0x100>;
+   #thermal-sensor-cells = <0>;
+   #io-channel-cells = <0>;
+   };
+
fe0: display-frontend@01e0 {
compatible = "allwinner,sun8i-a33-display-frontend";
reg = <0x01e0 0x2>;
@@ -376,6 +383,11 @@
};
};
};
+
+   iio-hwmon {
+   compatible = "iio-hwmon";
+   io-channels = <>;
+   };
 };
 
  {
-- 
2.9.3

Re: [Outreachy kernel] [PATCH v3 0/2] Replace mlock with private lock and delete whitespaces

[Alison Schofield]

On Tue, Mar 21, 2017 at 11:33:54PM +0530, simran singhal wrote:
> The patch series replaces mlock with a private lock for driver ad9834 and
> Fix coding style issues related to white spaces.

Hi Simran,  

I'm getting lost.  Patchset Subject Line needs subsystem and driver.
The comment above says ad9834 but the patches below say ade7753.

Can we drive adis16060 through ACK and then come back to this one?
(ie. applyling lessons learned)

thanks,
alisons
> 
> v3:
>   -Using new private "lock" instead of using "buf_lock"
>as it can cause deadlock.
>   -Sending it as a series of two patches.
> 
> v2:
>   -Using the existing buf_lock instead of lock.
>
> 
> simran singhal (2):
>   staging: iio: ade7753: Remove trailing whitespaces
>   staging: iio: ade7753: Replace mlock with driver private lock
> 
>  drivers/staging/iio/meter/ade7753.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> -- 
> 2.7.4
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1490119436-20042-1-git-send-email-singhalsimran0%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 0/3] dtc updates for 4.12

[Olof Johansson]

On Tue, Mar 21, 2017 at 9:19 AM, Rob Herring  wrote:
> This series syncs dtc with current mainline. The primary motivation is
> to pull in the new checks I've worked on. This gives lots of new
> warnings which are turned off by default.
>
> Arm-soc folks, I've left the PCI checks enabled as they are pretty much
> all real errors and there aren't that many (about 1200, but that's lots
> of duplicates). I have a patch for some of them.

Yay for better warnings!

But as with all changes of this kind, when new warnings are introduced
please give people some time to remove them without turning them on by
default. We had a cycle like that already.

Main reason is that it becomes too hard to spot new warnings when they
come in if the logs are flooded with 1200 existing warnings.

How many of them do you have patches for, per chance? If we can see
them show up quickly the answer to the above might be a bit different.


-Olof

Re: [PATCH 07/13] perf, tools: Add a simple expression parser for JSON

[Arnaldo Carvalho de Melo]

Em Tue, Mar 21, 2017 at 04:14:23PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Mar 20, 2017 at 01:17:05PM -0700, Andi Kleen escreveu:
> > From: Andi Kleen 
> > 
> > Add a simple expression parser good enough to parse JSON relation
> > expressions. The parser is implemented using bison.
> 
> Renaming 'foo_expr' to 'foo_json_expr', as 'expr' is _way_ too
> generic...

I retract that, it is used with JSON, but isn't strictly tied to it,
keeping as is, nevermind.

- Arnaldo
 
> - Arnaldo
>  
> > This is just intended as an simple parser for internal usage
> > in the event lists, not the beginning of a "perf scripting language"
> > 
> > v2: Use expr__ prefix instead of expr_
> > Support multiple free variables for parser
> > Signed-off-by: Andi Kleen 
> > ---
> >  tools/perf/tests/Build  |   1 +
> >  tools/perf/tests/builtin-test.c |   4 +
> >  tools/perf/tests/expr.c |  55 +
> >  tools/perf/tests/tests.h|   1 +
> >  tools/perf/util/Build   |   5 ++
> >  tools/perf/util/expr.h  |  25 ++
> >  tools/perf/util/expr.y  | 173 
> > 
> >  7 files changed, 264 insertions(+)
> >  create mode 100644 tools/perf/tests/expr.c
> >  create mode 100644 tools/perf/util/expr.h
> >  create mode 100644 tools/perf/util/expr.y
> > 
> > diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
> > index 1cb3d9b540e9..af58ebc243ef 100644
> > --- a/tools/perf/tests/Build
> > +++ b/tools/perf/tests/Build
> > @@ -38,6 +38,7 @@ perf-y += cpumap.o
> >  perf-y += stat.o
> >  perf-y += event_update.o
> >  perf-y += event-times.o
> > +perf-y += expr.o
> >  perf-y += backward-ring-buffer.o
> >  perf-y += sdt.o
> >  perf-y += is_printable_array.o
> > diff --git a/tools/perf/tests/builtin-test.c 
> > b/tools/perf/tests/builtin-test.c
> > index 83c4669cbc5b..86822969e8a8 100644
> > --- a/tools/perf/tests/builtin-test.c
> > +++ b/tools/perf/tests/builtin-test.c
> > @@ -44,6 +44,10 @@ static struct test generic_tests[] = {
> > .func = test__parse_events,
> > },
> > {
> > +   .desc = "Simple expression parser",
> > +   .func = test__expr,
> > +   },
> > +   {
> > .desc = "PERF_RECORD_* events & perf_sample fields",
> > .func = test__PERF_RECORD,
> > },
> > diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
> > new file mode 100644
> > index ..554695c06c5b
> > --- /dev/null
> > +++ b/tools/perf/tests/expr.c
> > @@ -0,0 +1,55 @@
> > +#include "util/debug.h"
> > +#include "util/expr.h"
> > +#include "tests.h"
> > +
> > +static int test(struct parse_ctx *ctx, const char *e, double val2)
> > +{
> > +   double val;
> > +
> > +   if (expr__parse(, ctx, ))
> > +   TEST_ASSERT_VAL("parse test failed", 0);
> > +   TEST_ASSERT_VAL("unexpected value", val == val2);
> > +   return 0;
> > +}
> > +
> > +int test__expr(int subtest __maybe_unused)
> > +{
> > +   const char *p;
> > +   const char **other;
> > +   double val;
> > +   int ret;
> > +   struct parse_ctx ctx;
> > +   int num_other;
> > +
> > +   expr__ctx_init();
> > +   expr__add_id(, "FOO", 1);
> > +   expr__add_id(, "BAR", 2);
> > +
> > +   ret = test(, "1+1", 2);
> > +   ret |= test(, "FOO+BAR", 3);
> > +   ret |= test(, "(BAR/2)%2", 1);
> > +   ret |= test(, "1 - -4",  5);
> > +   ret |= test(, "(FOO-1)*2 + (BAR/2)%2 - -4",  5);
> > +
> > +   if (ret)
> > +   return ret;
> > +
> > +   p = "FOO/0";
> > +   ret = expr__parse(, , );
> > +   TEST_ASSERT_VAL("division by zero", ret == 1);
> > +
> > +   p = "BAR/";
> > +   ret = expr__parse(, , );
> > +   TEST_ASSERT_VAL("missing operand", ret == 1);
> > +
> > +   TEST_ASSERT_VAL("find other",
> > +   expr__find_other("FOO + BAR + BAZ + BOZO", "FOO", 
> > , _other) == 0);
> > +   TEST_ASSERT_VAL("find other", num_other == 3);
> > +   TEST_ASSERT_VAL("find other", !strcmp(other[0], "BAR"));
> > +   TEST_ASSERT_VAL("find other", !strcmp(other[1], "BAZ"));
> > +   TEST_ASSERT_VAL("find other", !strcmp(other[2], "BOZO"));
> > +   TEST_ASSERT_VAL("find other", other[3] == NULL);
> > +   free((void *)other);
> > +
> > +   return 0;
> > +}
> > diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
> > index 1fa9b9d83aa5..631859629403 100644
> > --- a/tools/perf/tests/tests.h
> > +++ b/tools/perf/tests/tests.h
> > @@ -62,6 +62,7 @@ int test__sample_parsing(int subtest);
> >  int test__keep_tracking(int subtest);
> >  int test__parse_no_sample_id_all(int subtest);
> >  int test__dwarf_unwind(int subtest);
> > +int test__expr(int subtest);
> >  int test__hists_filter(int subtest);
> >  int test__mmap_thread_lookup(int subtest);
> >  int test__thread_mg_share(int subtest);
> > diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> > index fb4f42f1bb38..0b98534a9ea1 100644
> > --- a/tools/perf/util/Build
> > +++ b/tools/perf/util/Build
> > @@ -90,6 +90,7 @@ libperf-y += 

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

[Cyrill Gorcunov]

On Tue, Mar 21, 2017 at 12:31:51PM -0700, Andy Lutomirski wrote:
...
> > I guess the question comes from that we're releasing CRIU 3.0 with
> > 32-bit C/R and some other cool stuff, but we don't support x32 yet.
> > As we don't want release a thing that we aren't properly testing.
> > So for a while we should error on dumping x32 applications.
> 
> I'm curious: shouldn't x32 CRIU just work?  What goes wrong?

Anything ;) We didn't tried as far as I know but i bet
somthing will be broken for sure.

Re: [PATCH 0/3] dtc updates for 4.12

[Rob Herring]

On Tue, Mar 21, 2017 at 11:49 AM, Florian Fainelli  wrote:
> On 03/21/2017 09:19 AM, Rob Herring wrote:
>> This series syncs dtc with current mainline. The primary motivation is
>> to pull in the new checks I've worked on. This gives lots of new
>> warnings which are turned off by default.
>>
>> Arm-soc folks, I've left the PCI checks enabled as they are pretty much
>> all real errors and there aren't that many (about 1200, but that's lots
>> of duplicates). I have a patch for some of them.
>
> Out of curiosity, should we think about making dtc a git submodule and
> have some magic in scripts/update-dtc-source.sh to sync it to a desired
> commit?

I'd be fine with that though all of dtc is not imported and I don't
really want to be the first to try to add a git submodule to the
kernel. Not everyone is a fan I think.

Rob

Re: [PATCH v2 0/2] Remove Typedefs.

[Jonathan Cameron]

On 21/03/17 15:06, Arushi Singhal wrote:
> Typedefs are removed in sm750fb driver.
> 
> Arushi Singhal (2):
>   staging: sm750fb: Remove typedef from "typedef struct _mode_parameter_t"
>   staging: sm750fb: Remove typedef from "typedef enum _spolarity_t"
> 
>  drivers/staging/sm750fb/ddk750_mode.c |  8 +---
>  drivers/staging/sm750fb/ddk750_mode.h | 19 ---
>  drivers/staging/sm750fb/sm750_hw.c|  2 +-
>  3 files changed, 14 insertions(+), 15 deletions(-)
> 
Please be careful to only cc linux-iio for patches with an IIO component...

[PATCH v9 3/3] backlight arcxcnn add support for ArcticSand devices

[Olimpiu Dejeu]

backlight: Add support for Arctic Sand LED backlight driver chips
This driver provides support for the Arctic Sand arc2c0608 chip, 
and provides a framework to support future devices.
Reviewed-by: Daniel Thompson 
Signed-off-by: Olimpiu Dejeu 
---
v8 => v9:
- Addressing kbuild test robot WARNING: PTR_ERR_OR_ZERO can be used
v7 => v8:
- Version updated to match other patch in set. No other changes.
v6 => v7:
- Addressing issues brought up by Daniel Thompson
v5 => v6:
- Addressing issues brought up by Daniel Thompson
v4 => v5:
- Code style changes per Joe Perches and Jingoo Han
v3 => v4:
- Code style changes per Joe Perches and Jingoo Han
v2 => v3:
- Renamed variables to comply with conventions on naming
- Corrected device name in arcxcnn.h
v1 => v2:
- Removed "magic numbers" to initialize registers
- Cleaned up device tree bindings
- Fixed code style to address comments and pass "checkpatch"
- Removed unneeded debug and testing code


 drivers/video/backlight/Kconfig  |   7 +
 drivers/video/backlight/Makefile |   1 +
 drivers/video/backlight/arcxcnn_bl.c | 419 +++
 3 files changed, 427 insertions(+)
 create mode 100644 drivers/video/backlight/arcxcnn_bl.c

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5ffa4b4..4e1d2ad 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -460,6 +460,13 @@ config BACKLIGHT_BD6107
help
  If you have a Rohm BD6107 say Y to enable the backlight driver.
 
+config BACKLIGHT_ARCXCNN
+   tristate "Backlight driver for the Arctic Sands ARCxC family"
+   depends on I2C
+   help
+ If you have an ARCxC family backlight say Y to enable
+ the backlight driver.
+
 endif # BACKLIGHT_CLASS_DEVICE
 
 endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 16ec534..8905129 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_BACKLIGHT_SKY81452)  += sky81452-backlight.o
 obj-$(CONFIG_BACKLIGHT_TOSA)   += tosa_bl.o
 obj-$(CONFIG_BACKLIGHT_TPS65217)   += tps65217_bl.o
 obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
+obj-$(CONFIG_BACKLIGHT_ARCXCNN)+= arcxcnn_bl.o
diff --git a/drivers/video/backlight/arcxcnn_bl.c 
b/drivers/video/backlight/arcxcnn_bl.c
new file mode 100644
index 000..e01b1b0
--- /dev/null
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -0,0 +1,419 @@
+/*
+ * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
+ *
+ * Copyright 2016 ArcticSand, Inc.
+ * Author : Brian Dodge 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum arcxcnn_chip_id {
+   ARC2C0608
+};
+
+/**
+ * struct arcxcnn_platform_data
+ * @name   : Backlight driver name (NULL will use default)
+ * @initial_brightness : initial value of backlight brightness
+ * @leden  : initial LED string enables, upper bit is global on/off
+ * @led_config_0   : fading speed (period between intensity steps)
+ * @led_config_1   : misc settings, see datasheet
+ * @dim_freq   : pwm dimming frequency if in pwm mode
+ * @comp_config: misc config, see datasheet
+ * @filter_config  : RC/PWM filter config, see datasheet
+ * @trim_config: full scale current trim, see datasheet
+ */
+struct arcxcnn_platform_data {
+   const char *name;
+   u16 initial_brightness;
+   u8  leden;
+   u8  led_config_0;
+   u8  led_config_1;
+   u8  dim_freq;
+   u8  comp_config;
+   u8  filter_config;
+   u8  trim_config;
+};
+
+#define ARCXCNN_CMD0x00/* Command Register */
+#define ARCXCNN_CMD_STDBY  0x80/*   I2C Standby */
+#define ARCXCNN_CMD_RESET  0x40/*   Reset */
+#define ARCXCNN_CMD_BOOST  0x10/*   Boost */
+#define ARCXCNN_CMD_OVP_MASK   0x0C/*   --- Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_XXV0x0C/*Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_20V0x08/*   20v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_24V0x04/*   24v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_31V0x00/*   31.4v Over Voltage 

[PATCH v9 2/3] backlight arcxcnn devicetree bindings for ArcticSand

[Olimpiu Dejeu]

backlight: Add devicetree bindings for the Arctic Sand backlight driver
This patch provides devicetree bindings for the Arctic Sand
driver submitted in the previous patch
Acked-by: Rob Herring 
Acked-by: Daniel Thompson 
Signed-off-by: Olimpiu Dejeu 
---
v8 => v9:
- Version updated to match other patch in set. No other changes.
v7 => v8:
- Version updated to match other patch in set. No other changes.
v6 => v7:
- Version updated to match other patch in set. No other changes.
v5 => v6:
- Version updated to match other patch in set. No other changes.
v4 => v5:
- Added spaces for increased readability per Lee Jones
v3 => v4:
- Added spaces for increased readability per Lee Jones
v2 => v3:
- Version updated to match other patch in set. No other changes.
v1 => v2:
- Version updated to match other patch in set. No other changes.

 .../bindings/leds/backlight/arcxcnn_bl.txt | 33 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt

diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt 
b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
new file mode 100644
index 000..ecb7731
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -0,0 +1,33 @@
+Binding for ArcticSand arc2c0608 LED driver
+
+Required properties:
+- compatible:  should be "arc,arc2c0608"
+- reg: slave address
+
+Optional properties:
+- default-brightness:  brightness value on boot, value from: 0-4095
+- label:   The name of the backlight device
+   See Documentation/devicetree/bindings/leds/common.txt
+- led-sources: List of enabled channels from 0 to 5.
+   See Documentation/devicetree/bindings/leds/common.txt
+
+- arc,led-config-0:setting for register ILED_CONFIG_0
+- arc,led-config-1:setting for register ILED_CONFIG_1
+- arc,dim-freq:PWM mode frequence setting (bits [3:0] used)
+- arc,comp-config: setting for register CONFIG_COMP
+- arc,filter-config:   setting for register FILTER_CONFIG
+- arc,trim-config: setting for register IMAXTUNE
+
+Note: Optional properties not specified will default to values in IC EPROM
+
+Example:
+
+arc2c0608@30 {
+   compatible = "arc,arc2c0608";
+   reg = <0x30>;
+   default-brightness = <500>;
+   label = "lcd-backlight";
+   linux,default-trigger = "backlight";
+   led-sources = <0 1 2 5>;
+};
+
-- 
2.7.4

Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs

[Vincent Guittot]

On 21 March 2017 at 15:58, Peter Zijlstra  wrote:
>
> On Tue, Mar 21, 2017 at 03:16:19PM +0100, Vincent Guittot wrote:
> > On 21 March 2017 at 15:03, Peter Zijlstra  wrote:
> >
> > > On Tue, Mar 21, 2017 at 02:37:08PM +0100, Vincent Guittot wrote:
> > > > On 21 March 2017 at 14:22, Peter Zijlstra  wrote:
> > >
> > > > For the not overloaded case, it makes sense to immediately update to
> > > > OPP to be aligned with the new utilization of the CPU even if it was
> > > > not idle in the past couple of ticks
> > >
> > > Yeah, but we cannot know. Also, who cares?
> > >
> >
> > embedded system that doesn't want to stay at higest OPP if significant part
> > of the utilzation has moved away as an example
> > AFAICT, schedutil tries to select the best OPP according to the current
> > utilization of the CPU so if the utilization decreases, the OPP should also
> > decrease
>
> Sure I get that; but given the lack of crystal ball instructions we
> cannot know if this is the case or not.

cfs_rq->avg.load_avg account the waiting time of CPU (in addition to
the weight of task) so i was wondering if we can't use it to detect if
we are in the overloaded  case or not even if utilization is not mac
capacity because we have just migrated a task (and its utilization)
out



>
> And if we really dropped below 100% utilization, we should hit idle
> fairly soon.

[PATCH v3 09/11] ARM: dtsi: sun8i: a33: add CPU thermal throttling

[Quentin Schulz]

This adds CPU thermal throttling for the Allwinner A33. It uses the
thermal sensor present in the SoC's GPADC.

Signed-off-by: Quentin Schulz 
---

v3:
  - switched to new phandle because of modified DT node name for the GPADC
  (named THS),
  - got rid of cooling-min-level and cooling-max-level as it's not used in any
  code in the kernel,

v2:
  - updated cooling-max-level to reflect newly added OPPs,

 arch/arm/boot/dts/sun8i-a33.dtsi | 45 
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index f391f71..73552bb 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -43,6 +43,7 @@
  */
 
 #include "sun8i-a23-a33.dtsi"
+#include 
 
 / {
cpu0_opp_table: opp_table0 {
@@ -127,6 +128,7 @@
clocks = < CLK_CPUX>;
clock-names = "cpu";
operating-points-v2 = <_opp_table>;
+   #cooling-cells = <2>;
};
 
cpu@1 {
@@ -170,6 +172,49 @@
};
};
 
+   thermal-zones {
+   cpu_thermal {
+   /* milliseconds */
+   polling-delay-passive = <250>;
+   polling-delay = <1000>;
+   thermal-sensors = <>;
+
+   cooling-maps {
+   map0 {
+   trip = <_alert0>;
+   cooling-device = < 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   map1 {
+   trip = <_alert1>;
+   cooling-device = < 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+   };
+   };
+
+   trips {
+   cpu_alert0: cpu_alert0 {
+   /* milliCelsius */
+   temperature = <75000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   cpu_alert1: cpu_alert1 {
+   /* milliCelsius */
+   temperature = <9>;
+   hysteresis = <2000>;
+   type = "hot";
+   };
+
+   cpu_crit: cpu_crit {
+   /* milliCelsius */
+   temperature = <11>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+   };
+
memory {
reg = <0x4000 0x8000>;
};
-- 
2.9.3

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

[J. Bruce Fields]

On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> > - NFS doesn't actually require that it increases, but I think it
> >   should.  I assume 64 bits means we don't need a discussion of
> >   wraparound.
> 
> I thought NFS spec required that you be able to recognize old change
> attributes so that they can be discarded. I could be wrong here though.
> I'd have to go back and look through the spec to be sure.

https://tools.ietf.org/html/rfc7862#section-10

--b.

Re: [PING PATCH v2] jump label: fix passing kbuild_cflags when checking for asm goto support

[Masahiro Yamada]

2017-03-21 2:15 GMT+09:00 Gleb Fotengauer-Malinovskiy :
> The latest change of asm goto support check added passing of KBUILD_CFLAGS
> to compiler.  When these flags reference gcc plugins that are not built yet,
> the check fails.
>
> When one runs "make bzImage" followed by "make modules", the kernel is always
> built with HAVE_JUMP_LABEL disabled, while the modules are built depending on
> CONFIG_JUMP_LABEL.  If HAVE_JUMP_LABEL macro happens to be different, modules
> are built with undefined references, e.g.:
>
> ERROR: "static_key_slow_inc" [net/netfilter/xt_TEE.ko] undefined!
> ERROR: "static_key_slow_dec" [net/netfilter/xt_TEE.ko] undefined!
> ERROR: "static_key_slow_dec" [net/netfilter/nft_meta.ko] undefined!
> ERROR: "static_key_slow_inc" [net/netfilter/nft_meta.ko] undefined!
> ERROR: "nf_hooks_needed" [net/netfilter/ipvs/ip_vs.ko] undefined!
> ERROR: "nf_hooks_needed" [net/ipv6/ipv6.ko] undefined!
> ERROR: "static_key_count" [net/ipv6/ipv6.ko] undefined!
> ERROR: "static_key_slow_inc" [net/ipv6/ipv6.ko] undefined!
>
> This change moves the check before all these references are added
> to KBUILD_CFLAGS.  This is correct because subsequent KBUILD_CFLAGS
> modifications are not relevant to this check.
>
> Reported-by: Anton V. Boyarshinov 
> Fixes: 35f860f9ba6a ("jump label: pass kbuild_cflags when checking for asm 
> goto support")
> Cc: sta...@vger.kernel.org  # v4.10
> Signed-off-by: Gleb Fotengauer-Malinovskiy 
> Signed-off-by: Dmitry V. Levin 
> Acked-by: Steven Rostedt (VMware) 
> Acked-by: David Lin 
> ---
> v2: update description of the problem fixed by this patch
>


I assume this PING is addressed to me.

First, Steven asked Andrew to pick up this,
but I have not seen it in linux-next yet. So,

Applied to linux-kbuild/fixes.  Thanks!




-- 
Best Regards
Masahiro Yamada

RE: [PATCH v2] scsi: storvsc: Add support for FC rport.

[KY Srinivasan]

> -Original Message-
> From: Cathy Avery [mailto:cav...@redhat.com]
> Sent: Friday, March 17, 2017 8:18 AM
> To: KY Srinivasan ; h...@infradead.org; Haiyang Zhang
> ; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com
> Cc: step...@networkplumber.org; dan.carpen...@oracle.com;
> de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; linux-
> s...@vger.kernel.org
> Subject: [PATCH v2] scsi: storvsc: Add support for FC rport.
> 
> Included in the current storvsc driver for Hyper-V is the ability
> to access luns on an FC fabric via a virtualized fiber channel
> adapter exposed by the Hyper-V host. The driver also attaches to
> the FC transport to allow host and port names to be published under
> /sys/class/fc_host/hostX. Current customer tools running on the VM
> require that these names be available in the well known standard
> location under fc_host/hostX.
> 
> A problem arose when attaching to the FC transport. The scsi_scan
> code attempts to call fc_user_scan which has basically become a no-op
> due to the fact that the virtualized FC device does not expose rports.
> At this point you cannot refresh the scsi bus after mapping or unmapping
> luns on the SAN without a reboot of the VM.
> 
> This patch stubs in an rport per fc_host in storvsc so that the
> requirement of a defined rport is now met within the fc_transport and
> echo "- - -" > /sys/class/scsi_host/hostX/scan now works.
> 
> Signed-off-by: Cathy Avery 

Acked-by: K. Y. Srinivasan 
> ---
> Changes since v1:
> - Fix fc_rport_identifiers init [Stephen Hemminger]
> - Better error checking
> ---
>  drivers/scsi/storvsc_drv.c | 23 ++-
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 638e5f4..37646d1 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -478,6 +478,9 @@ struct storvsc_device {
>*/
>   u64 node_name;
>   u64 port_name;
> +#if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
> + struct fc_rport *rport;
> +#endif
>  };
> 
>  struct hv_host_device {
> @@ -1816,19 +1819,27 @@ static int storvsc_probe(struct hv_device
> *device,
>   target = (device->dev_instance.b[5] << 8 |
>device->dev_instance.b[4]);
>   ret = scsi_add_device(host, 0, target, 0);
> - if (ret) {
> - scsi_remove_host(host);
> - goto err_out2;
> - }
> + if (ret)
> + goto err_out3;
>   }
>  #if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
>   if (host->transportt == fc_transport_template) {
> + struct fc_rport_identifiers ids = {
> + .roles = FC_PORT_ROLE_FCP_TARGET,
> + };
> +
>   fc_host_node_name(host) = stor_device->node_name;
>   fc_host_port_name(host) = stor_device->port_name;
> + stor_device->rport = fc_remote_port_add(host, 0, );
> + if (!stor_device->rport)
> + goto err_out3;
>   }
>  #endif
>   return 0;
> 
> +err_out3:
> + scsi_remove_host(host);
> +
>  err_out2:
>   /*
>* Once we have connected with the host, we would need to
> @@ -1854,8 +1865,10 @@ static int storvsc_remove(struct hv_device *dev)
>   struct Scsi_Host *host = stor_device->host;
> 
>  #if IS_ENABLED(CONFIG_SCSI_FC_ATTRS)
> - if (host->transportt == fc_transport_template)
> + if (host->transportt == fc_transport_template) {
> + fc_remote_port_delete(stor_device->rport);
>   fc_remove_host(host);
> + }
>  #endif
>   scsi_remove_host(host);
>   storvsc_dev_remove(dev);
> --
> 2.5.0

Re: [PATCH] doc: Update the comparisons rule in rcu_dereference.txt

[Paul E. McKenney]

On Mon, Mar 20, 2017 at 10:38:35PM +0100, Michalis Kokologiannakis wrote:
> When an RCU-protected pointer is fetched but never dereferenced
> rcu_access_pointer() should be used in place of rcu_dereference().
> This commit explicitly records this very fact in Documentation/
> RCU/rcu_dereference.txt, in order to prevent the usage of
> rcu_dereference() in comparisons.
> 
> Signed-off-by: Michalis Kokologiannakis 

Queued for review, thank you!

Thanx, Paul

> ---
>  Documentation/RCU/rcu_dereference.txt | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Documentation/RCU/rcu_dereference.txt 
> b/Documentation/RCU/rcu_dereference.txt
> index c0bf244..b2a613f 100644
> --- a/Documentation/RCU/rcu_dereference.txt
> +++ b/Documentation/RCU/rcu_dereference.txt
> @@ -138,6 +138,15 @@ oBe very careful about comparing pointers 
> obtained from
>   This sort of comparison occurs frequently when scanning
>   RCU-protected circular linked lists.
> 
> + Note that if checks for being within an RCU read-side
> + critical section are not required and the pointer is never
> + dereferenced, rcu_access_pointer() should be used in place
> + of rcu_dereference(). The rcu_access_pointer() primitive
> + does not require an enclosing read-side critical section,
> + and also omits the smp_read_barrier_depends() included in
> + rcu_dereference(), which in turn should provide a small
> + performance gain in some CPUs (e.g., the DEC Alpha).
> +
>   o   The comparison is against a pointer that references memory
>   that was initialized "a long time ago."  The reason
>   this is safe is that even if misordering occurs, the
> -- 
> 2.1.4
> 

Re: [PATCH] trace-cmd: Fix segmentation fault in trace-snapshot

[Steven Rostedt]

On Tue, 21 Mar 2017 17:11:53 +0100
John Kacur  wrote:

> To reproduce the problem:
> 
>   plugin 'wakeup'
> trace-cmd: Device or resource busy
>   Segmentation fault (core dumped)
> 
> When the user triggers a condition such as EBUSY the program should
> die gracefully. The problem here is simply caused by an extra
> conversion specifier in "die" in the write_file function

Thanks John!

I'm currently traveling but I'll apply this when I get a chance.

-- Steve

> 
> Signed-off-by: John Kacur 
> ---
>  trace-snapshot.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/trace-snapshot.c b/trace-snapshot.c
> index 9d3608c49563..771b065ccfa4 100644
> --- a/trace-snapshot.c
> +++ b/trace-snapshot.c
> @@ -42,7 +42,8 @@ static void write_file(const char *name, char *val)
>  
>   n = write(fd, val, strlen(val));
>   if (n < 0)
> - die("failed to write '%d' to %s\n", path);
> + die("failed to write to %s\n", path);
> +
>   tracecmd_put_tracing_file(path);
>   close(fd);
>  }

[RFC] x86/tboot: add an option to disable iommu force on

[Shaohua Li]

IOMMU harms performance signficantly when we run very fast networking
workloads. This is a limitation in hardware based on our observation, so
we'd like to disable the IOMMU force on, but we do want to use TBOOT and
we can sacrifice the DMA security bought by IOMMU. I must admit I know
nothing about TBOOT, but TBOOT guys (cc-ed) think not eabling IOMMU is
totally ok.

So introduce a new boot option to disable the force on. It's kind of
silly we need to run into intel_iommu_init even without force on, but we
need to disable TBOOT PMR registers. For system without the boot option,
nothing is changed.

Signed-off-by: Shaohua Li 
---
 arch/x86/kernel/tboot.c   |  3 +++
 drivers/iommu/intel-iommu.c   | 21 -
 include/linux/dma_remapping.h |  1 +
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c
index b868fa1..edbdfe6 100644
--- a/arch/x86/kernel/tboot.c
+++ b/arch/x86/kernel/tboot.c
@@ -510,6 +510,9 @@ int tboot_force_iommu(void)
if (!tboot_enabled())
return 0;
 
+   if (!intel_iommu_tboot_noforce)
+   return 1;
+
if (no_iommu || swiotlb || dmar_disabled)
pr_warning("Forcing Intel-IOMMU to enabled\n");
 
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 238ad34..737dfa7 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -183,6 +183,7 @@ static int rwbf_quirk;
  * (used when kernel is launched w/ TXT)
  */
 static int force_on = 0;
+int intel_iommu_tboot_noforce;
 
 /*
  * 0: Present
@@ -607,6 +608,10 @@ static int __init intel_iommu_setup(char *str)
"Intel-IOMMU: enable pre-production PASID 
support\n");
intel_iommu_pasid28 = 1;
iommu_identity_mapping |= IDENTMAP_GFX;
+   } else if (!strncmp(str, "tboot_noforce", 13)) {
+printk(KERN_INFO
+   "Intel-IOMMU: not forcing on after tboot\n");
+   intel_iommu_tboot_noforce = 1;
}
 
str += strcspn(str, ",");
@@ -4840,8 +4845,22 @@ int __init intel_iommu_init(void)
goto out_free_dmar;
}
 
-   if (no_iommu || dmar_disabled)
+   if (no_iommu || dmar_disabled) {
+   /*
+* We exit the function here to ensure IOMMU's remapping and
+* mempool aren't setup, which means that the IOMMU's PMRs
+* won't be disabled via the call to init_dmars(). So disable
+* it explicitly here. The PMRs were setup by tboot prior to
+* calling SENTER, but the kernel is expected to reset/tear
+* down the PMRs.
+*/
+   if (intel_iommu_tboot_noforce) {
+   for_each_iommu(iommu, drhd)
+   iommu_disable_protect_mem_regions(iommu);
+   }
+
goto out_free_dmar;
+   }
 
if (list_empty(_rmrr_units))
pr_info("No RMRR found\n");
diff --git a/include/linux/dma_remapping.h b/include/linux/dma_remapping.h
index 187c102..9088407 100644
--- a/include/linux/dma_remapping.h
+++ b/include/linux/dma_remapping.h
@@ -39,6 +39,7 @@ extern int iommu_calculate_agaw(struct intel_iommu *iommu);
 extern int iommu_calculate_max_sagaw(struct intel_iommu *iommu);
 extern int dmar_disabled;
 extern int intel_iommu_enabled;
+extern int intel_iommu_tboot_noforce;
 #else
 static inline int iommu_calculate_agaw(struct intel_iommu *iommu)
 {
-- 
2.9.3

Re: [PATCH v4 1/2] backlight: pwm_bl: Move the checks for initial power state to a separate function

[Geert Uytterhoeven]

Hi Peter,

On Tue, Nov 22, 2016 at 2:41 PM, Peter Ujfalusi  wrote:
> Move the checks to select the initial state for the backlight to a new
> function and document the checks we are doing.

This is far from a simple "move"...

> With the separate function it is going to be easier to fix or improve the
> initial power state configuration later and it is easier to read the code.
>
> Signed-off-by: Peter Ujfalusi 
> Reviewed-by: Philipp Zabel 
> Reviewed-by: Thierry Reding 

This patch (commit 7613c922315e308a in v4.11-rc1) broke the display on
r8a7740/armadillo.

> @@ -267,20 +292,16 @@ static int pwm_backlight_probe(struct platform_device 
> *pdev)
> pb->enable_gpio = gpio_to_desc(data->enable_gpio);
> }
>
> -   if (pb->enable_gpio) {
> -   /*
> -* If the driver is probed from the device tree and there is a
> -* phandle link pointing to the backlight node, it is safe to
> -* assume that another driver will enable the backlight at the
> -* appropriate time. Therefore, if it is disabled, keep it so.
> -*/
> -   if (node && node->phandle &&
> -   gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_OUT &&
> -   gpiod_get_value(pb->enable_gpio) == 0)
> -   initial_blank = FB_BLANK_POWERDOWN;
> -   else
> -   gpiod_direction_output(pb->enable_gpio, 1);

In my case, "node" points to the "/backlight" node, but phandle is NULL.
Hence before, gpiod_direction_output() was called to enable the GPIO...

> -   }
> +   /*
> +* If the GPIO is configured as input, change the direction to output
> +* and set the GPIO as active.
> +* Do not force the GPIO to active when it was already output as it
> +* could cause backlight flickering or we would enable the backlight 
> too
> +* early. Leave the decision of the initial backlight state for later.
> +*/
> +   if (pb->enable_gpio &&
> +   gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_IN)
> +   gpiod_direction_output(pb->enable_gpio, 1);

... while now it's no longer called, as gpiod_get_direction() returns
-EINVAL.

Indeed, r8a7740_pfc does not implement the .get_direction() callback,
so gpiod_get_direction() always returns -EINVAL, which is never equal
to GPIOF_DIR_IN.

Restoring the old behavior by changing the above test to

if (pb->enable_gpio &&
(!node || !node->phandle ||
 gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_IN))

fixes the display for me, but leads to a more complex expression.

However, changing the test to

if (pb->enable_gpio &&
gpiod_get_direction(pb->enable_gpio) != GPIOF_DIR_OUT)

also fixes the display, as an error is always different from GPIOF_DIR_OUT.

Anyone with comments or suggestions to fix this for real?

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Re: [RESEND PATCH 1/7] time: Delete do_sys_setimeofday()

[Deepa Dinamani]

>arch/alpha/kernel/osf_sys.c: In function 'SYSC_osf_settimeofday':
>>> arch/alpha/kernel/osf_sys.c:1032:9: error: implicit declaration of function 
>>> 'do_sys_settimeofday' [-Werror=implicit-function-declaration]
>  return do_sys_settimeofday(tv ?  : NULL, tz ?  : NULL);
> ^~~
>cc1: some warnings being treated as errors
>
> vim +/do_sys_settimeofday +1032 arch/alpha/kernel/osf_sys.c

I missed this do_sys_settimeofday() call.
I will fix this in v2.

Thanks,
Deepa

[PATCH v2] drivers: staging: vt6656: fixed coding style errors

[Prasant Jalan]

This patch replaces spaces with tabs for indentation as per kernel
coding standards.

Signed-off-by: Prasant Jalan 
---
 drivers/staging/vt6656/rf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..0e3a62a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,8 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2, length,
+   array);
 
length2 -= length;
value += length;
-- 
2.7.4

Re: [PATCH v6 3/4] leds: Add LED support for MT6323 PMIC

[Jacek Anaszewski]

Hi Sean,

Thanks for the updated patch set. I've just applied patches
1/4 and 3/4 to the for-next branch of linux-leds.git.

Thanks for your effort.

Best regards,
Jacek Anaszewski

On 03/20/2017 07:47 AM, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> MT6323 PMIC is a multi-function device that includes LED function.
> It allows attaching up to 4 LEDs which can either be on, off or dimmed
> and/or blinked with the controller.
> 
> Signed-off-by: Sean Wang 
> Reviewed-by: Jacek Anaszewski 
> ---
>  drivers/leds/Kconfig   |   8 +
>  drivers/leds/Makefile  |   1 +
>  drivers/leds/leds-mt6323.c | 502 
> +
>  3 files changed, 511 insertions(+)
>  create mode 100644 drivers/leds/leds-mt6323.c
> 
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 275f467..1cf4b6d 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -126,6 +126,14 @@ config LEDS_MIKROTIK_RB532
> This option enables support for the so called "User LED" of
> Mikrotik's Routerboard 532.
>  
> +config LEDS_MT6323
> + tristate "LED Support for Mediatek MT6323 PMIC"
> + depends on LEDS_CLASS
> + depends on MFD_MT6397
> + help
> +   This option enables support for on-chip LED drivers found on
> +   Mediatek MT6323 PMIC.
> +
>  config LEDS_S3C24XX
>   tristate "LED Support for Samsung S3C24XX GPIO LEDs"
>   depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 6b82737..4feb332 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_LEDS_IS31FL32XX)   += 
> leds-is31fl32xx.o
>  obj-$(CONFIG_LEDS_PM8058)+= leds-pm8058.o
>  obj-$(CONFIG_LEDS_MLXCPLD)   += leds-mlxcpld.o
>  obj-$(CONFIG_LEDS_NIC78BX)   += leds-nic78bx.o
> +obj-$(CONFIG_LEDS_MT6323)+= leds-mt6323.o
>  
>  # LED SPI Drivers
>  obj-$(CONFIG_LEDS_DAC124S085)+= leds-dac124s085.o
> diff --git a/drivers/leds/leds-mt6323.c b/drivers/leds/leds-mt6323.c
> new file mode 100644
> index 000..48081bc
> --- /dev/null
> +++ b/drivers/leds/leds-mt6323.c
> @@ -0,0 +1,502 @@
> +/*
> + * LED driver for Mediatek MT6323 PMIC
> + *
> + * Copyright (C) 2017 Sean Wang 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Register field for MT6323_TOP_CKPDN0 to enable
> + * 32K clock common for LED device.
> + */
> +#define MT6323_RG_DRV_32K_CK_PDN BIT(11)
> +#define MT6323_RG_DRV_32K_CK_PDN_MASKBIT(11)
> +
> +/*
> + * Register field for MT6323_TOP_CKPDN2 to enable
> + * individual clock for LED device.
> + */
> +#define MT6323_RG_ISINK_CK_PDN(i)BIT(i)
> +#define MT6323_RG_ISINK_CK_PDN_MASK(i)   BIT(i)
> +
> +/*
> + * Register field for MT6323_TOP_CKCON1 to select
> + * clock source.
> + */
> +#define MT6323_RG_ISINK_CK_SEL_MASK(i)   (BIT(10) << (i))
> +
> +/*
> + * Register for MT6323_ISINK_CON0 to setup the
> + * duty cycle of the blink.
> + */
> +#define MT6323_ISINK_CON0(i) (MT6323_ISINK0_CON0 + 0x8 * (i))
> +#define MT6323_ISINK_DIM_DUTY_MASK   (0x1f << 8)
> +#define MT6323_ISINK_DIM_DUTY(i) (((i) << 8) & \
> + MT6323_ISINK_DIM_DUTY_MASK)
> +
> +/* Register to setup the period of the blink. */
> +#define MT6323_ISINK_CON1(i) (MT6323_ISINK0_CON1 + 0x8 * (i))
> +#define MT6323_ISINK_DIM_FSEL_MASK   (0x)
> +#define MT6323_ISINK_DIM_FSEL(i) ((i) & MT6323_ISINK_DIM_FSEL_MASK)
> +
> +/* Register to control the brightness. */
> +#define MT6323_ISINK_CON2(i) (MT6323_ISINK0_CON2 + 0x8 * (i))
> +#define MT6323_ISINK_CH_STEP_SHIFT   12
> +#define MT6323_ISINK_CH_STEP_MASK(0x7 << 12)
> +#define MT6323_ISINK_CH_STEP(i)  (((i) << 12) & \
> + MT6323_ISINK_CH_STEP_MASK)
> +#define MT6323_ISINK_SFSTR0_TC_MASK  (0x3 << 1)
> +#define MT6323_ISINK_SFSTR0_TC(i)(((i) << 1) & \
> + MT6323_ISINK_SFSTR0_TC_MASK)
> +#define MT6323_ISINK_SFSTR0_EN_MASK  BIT(0)
> +#define MT6323_ISINK_SFSTR0_EN   BIT(0)
> +
> +/* Register to LED channel enablement. */
> +#define MT6323_ISINK_CH_EN_MASK(i)   BIT(i)
> +#define MT6323_ISINK_CH_EN(i)BIT(i)
> +
> 

Re: [lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

[Linus Torvalds]

On Tue, Mar 21, 2017 at 11:16 AM, Thomas Garnier  wrote:
> This error happens even with Andy TLS fix on 32-bit (GDT is on fixmap
> but not readonly). I am looking into it.
>
> KVM internal error. Suberror: 3
> extra data[0]: 8b0e
> extra data[1]: 31

If I read that right, it's extra data[1] 0x31, which EXIT_REASON_EPT_MISCONFIG.

I'm not seeing how the A bit in a GDT entry could have anything to do
with it. I'm assuming it happens even without Andy's patch?

  Linus

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

[hpa]

On March 21, 2017 12:07:13 PM PDT, Cyrill Gorcunov  wrote:
>On Tue, Mar 21, 2017 at 11:51:09AM -0700, h...@zytor.com wrote:
>> >
>> >indeed, thanks!
>> 
>> I proposed to the ptrace people a virtual register for this and a few
>other things, but it got bikeshed to death.
>
>Any mail reference left? Would like to read it.

Not sure...
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[PATCH v3 00/11] add thermal throttling to Allwinner A33 SoC

[Quentin Schulz]

The Allwinner SoCs all have an ADC that can also act as a touchscreen
controller and a thermal sensor. The first four channels can be used
either for the ADC or the touchscreen and the fifth channel is used for
the thermal sensor. We currently have a driver for the two latter
functions in drivers/input/touchscreen/sun4i-ts.c but we don't have
access to the ADC feature at all. It is meant to replace the current
driver by using MFD and subdrivers for existing bindings.

The Allwinner A33 only has a thermal sensor present in the GPADC. In
addition, there is not an existing DT binding for the GPADC. Thus, we do
not need the sun4i-gpadc MFD driver which was made to keep DT compatibility
and probe subdrivers without the need to add DT subnodes.

This series of patch adds the thermal sensor for the A33 and GPU/CPU
thermal throttling. It also adds the cpu-supply property to the CPU node
needed by the Sinlinx SinA33 and Olinuxino A33 to adapt their CPU regulator
voltage depending on the currently used OPP. The other A33 boards all have
their cpu-supply property set.

This series also fixes the missing operating-points-v2 property in cpu DT
nodes. Finally, it also adds all remaining OPPs which can be found in
Allwinner 3.4 linux and fex files of all A33 boards.

This series of patch is based on this[1] series of patch.

v3:
  - fixed compatible name in DT and in documentation,
  - fixed DT node name and label,
  - added explanations in commit logs,
  - moved frequencies that need overvolting to board DTS instead of A33 DTSI,
  - fixed a typo in if is_enabled condition,
  - removed all patches concerning Olimex Olinuxino (no HW to test on),

[1] https://lkml.org/lkml/2016/12/13/298 : "[PATCH v9] add support for Allwinner
SoCs ADC"

Thanks,
Quentin

Maxime Ripard (1):
  ARM: sun8i: a33: Add devfreq-based GPU cooling

Quentin Schulz (10):
  ARM: sun8i: a33: add operating-points-v2 property to all nodes
  ARM: sun8i: a33: add all operating points
  ARM: dts: sun8i: sina33: add cpu-supply
  Documentation: DT: bindings: mfd: add A33 GPADC binding
  Documentation: DT: bindings: input: touschcreen: remove sun4i
documentation
  iio: adc: sun4i-gpadc-iio: move code used in MFD probing to new
function
  iio: adc: sun4i-gpadc-iio: add support for A33 thermal sensor
  ARM: dtsi: sun8i: a33: add thermal sensor
  ARM: dtsi: sun8i: a33: add CPU thermal throttling
  ARM: sun8i: sina33: add highest OPP of CPUs

 .../touchscreen/sun4i.txt => mfd/sun4i-gpadc.txt}  |  21 +++
 arch/arm/boot/dts/sun8i-a23-a33.dtsi   |   1 +
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts |  18 +++
 arch/arm/boot/dts/sun8i-a33.dtsi   | 141 +
 drivers/iio/adc/Kconfig|   2 +-
 drivers/iio/adc/sun4i-gpadc-iio.c  | 170 +
 include/linux/mfd/sun4i-gpadc.h|   4 +
 7 files changed, 324 insertions(+), 33 deletions(-)
 rename Documentation/devicetree/bindings/{input/touchscreen/sun4i.txt => 
mfd/sun4i-gpadc.txt} (64%)

-- 
2.9.3

Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup

[Tim Murray]

On Sun, Mar 19, 2017 at 10:59 PM, Minchan Kim  wrote:
> However, I'm not sure your approach is good. It seems your approach just
> reclaims pages from groups (DEF_PRIORITY - memcg->priority) >= sc->priority.
> IOW, it is based on *temporal* memory pressure fluctuation sc->priority.
>
> Rather than it, I guess pages to be reclaimed should be distributed by
> memcg->priority. Namely, if global memory pressure happens and VM want to
> reclaim 100 pages, VM should reclaim 90 pages from memcg-A(priority-10)
> and 10 pages from memcg-B(prioirty-90).

This is what I debated most while writing this patch. If I'm
understanding your concern correctly, I think I'm doing more than
skipping high-priority cgroups:

- If the scan isn't high priority yet, then skip high-priority cgroups.
- When the scan is high priority, scan fewer pages from
higher-priority cgroups (using the priority to modify the shift in
get_scan_count).

This is tightly coupled with the question of what to do with
vmpressure. The right thing to do on an Android device under memory
pressure is probably something like this:

1. Reclaim aggressively from low-priority background processes. The
goal here is to reduce the pages used by background processes to the
size of their heaps (or smaller with ZRAM) but zero file pages.
They're already likely to be killed by userspace and we're keeping
them around opportunistically, so a performance hit if they run and
have to do IO to restore some of that working set is okay.
2. Reclaim a small amount from persistent processes. These often have
a performance-critical subset of pages that we absolutely don't want
paged out, but some reclaim of these processes is fine. They're large,
some of them only run sporadically and don't impact performance, it's
okay to touch these sometimes.
3. If there still aren't enough free pages, notify userspace to kill
any processes it can. If I put my "Android performance engineer
working on userspace" hat on, what I'd want to know from userspace is
that kswapd/direct reclaim probably has to scan foreground processes
in order to reclaim enough free pages to satisfy watermarks. That's a
signal I could directly act on from userspace.
4. If that still isn't enough, reclaim from foreground processes,
since those processes are performance-critical.

As a result, I like not being fair about which cgroups are scanned
initially. Some cgroups are strictly more important than others. (With
that said, I'm not tied to enforcing unfairness in scanning. Android
would probably use different priority levels for each app level for
fair scanning vs unfair scanning, but my guess is that the actual
reclaiming behavior would look similar in both schemes.)

Mem cgroup priority suggests a useful signal for vmpressure. If
scanning is starting to touch cgroups at a higher priority than
persistent processes, then the userspace lowmemorykiller could kill
one or more background processes (which would be in low-priority
cgroups that have already been scanned aggressively). The current lmk
hand-tuned watermarks would be gone, and tuning the /proc/sys/vm knobs
would be all that's required to make an Android device do the right
thing in terms of memory.

On Sun, Mar 19, 2017 at 10:59 PM, Minchan Kim  wrote:
> Hello,
>
> On Fri, Mar 17, 2017 at 04:16:35PM -0700, Tim Murray wrote:
>> Hi all,
>>
>> I've been working to improve Android's memory management and drop 
>> lowmemorykiller from the kernel, and I'd like to get some feedback on a 
>> small patch with a lot of side effects.
>>
>> Currently, when an Android device is under memory pressure, one of three 
>> things will happen from kswapd:
>>
>> 1. Compress an anonymous page to ZRAM.
>> 2. Evict a file page.
>> 3. Kill a process via lowmemorykiller.
>>
>> The first two are cheap and per-page, the third is relatively cheap in the 
>> short term, frees many pages, and may cause power and performance penalties 
>> later on when the process has to be started again. For lots of reasons, I'd 
>> like a better balance between reclamation and killing on Android.
>>
>> One of the nice things about Android from an optimization POV is that the 
>> execution model is more constrained than a generic Linux machine. There are 
>> only a limited number of processes that need to execute quickly for the 
>> device to appear to have good performance, and a userspace daemon (called 
>> ActivityManagerService) knows exactly what those processes are at any given 
>> time. We've made use of that in the past via cpusets and schedtune to limit 
>> the CPU resources available to background processes, and I think we can 
>> apply the same concept to memory.
>>
>
> AFAIK, many platforms as well as android have done it. IOW, they know what
> processes are important while others are not critical for user-response.
>
>> This patch adds a new tunable to mem cgroups, memory.priority. A mem cgroup 
>> with a non-zero priority will not be eligible for scanning 

[PATCH 0/2] xen,input: xen-kbdfront pointing device resolution support

[Juergen Gross]

As my patch tying the resolution of the xen pointing device to that of
the framebuffer wasn't accepted add support for different resolutions
via a module parameter.

Another possibility would be to set parameters via Xenstore, but this
is broken (patch 2 fixes that) and not yet supported by Xen tools.

Juergen Gross (2):
  xen,input: add xen-kbdfront module parameter for setting resolution
  xen,input: repair xen-kbdfront resolution setting via xenstore

 drivers/input/misc/xen-kbdfront.c | 42 ++-
 1 file changed, 28 insertions(+), 14 deletions(-)

-- 
2.10.2

[PATCH 1/2] xen,input: add xen-kbdfront module parameter for setting resolution

[Juergen Gross]

Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.

Signed-off-by: Juergen Gross 
---
 drivers/input/misc/xen-kbdfront.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 3900875..2df5678 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -41,6 +41,12 @@ struct xenkbd_info {
char phys[32];
 };
 
+enum { KPARAM_WIDTH, KPARAM_HEIGHT, KPARAM_CNT };
+static int size[KPARAM_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(size, int, NULL, 0444);
+MODULE_PARM_DESC(size,
+   "Pointing device width, height in pixels (default 800,600)");
+
 static int xenkbd_remove(struct xenbus_device *);
 static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info 
*);
 static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -174,8 +180,8 @@ static int xenkbd_probe(struct xenbus_device *dev,
 
if (abs) {
__set_bit(EV_ABS, ptr->evbit);
-   input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
-   input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+   input_set_abs_params(ptr, ABS_X, 0, size[KPARAM_WIDTH], 0, 0);
+   input_set_abs_params(ptr, ABS_Y, 0, size[KPARAM_HEIGHT], 0, 0);
} else {
input_set_capability(ptr, EV_REL, REL_X);
input_set_capability(ptr, EV_REL, REL_Y);
-- 
2.10.2

Re: [PATCH] fs/pstore: Perform erase from a worker

[Chris Wilson]

On Tue, Mar 21, 2017 at 02:58:48PM +0900, Namhyung Kim wrote:
> Hello,
> 
> On Mon, Mar 20, 2017 at 10:49:16AM -0700, Kees Cook wrote:
> > On Fri, Mar 17, 2017 at 2:52 AM, Chris Wilson  
> > wrote:
> > > In order to prevent a cyclic recursion between psi->read_mutex and the
> > > inode_lock, we need to move the pse->erase to a worker.
> > >
> > > [  605.374955] ==
> > > [  605.381281] [ INFO: possible circular locking dependency detected ]
> > > [  605.387679] 4.11.0-rc2-CI-CI_DRM_2352+ #1 Not tainted
> > > [  605.392826] ---
> > > [  605.399196] rm/7298 is trying to acquire lock:
> > > [  605.403720]  (>read_mutex){+.+.+.}, at: [] 
> > > pstore_unlink+0x3f/0xa0
> > > [  605.412300]
> > > [  605.412300] but task is already holding lock:
> > > [  605.418237]  (>s_type->i_mutex_key#14){++}, at: 
> > > [] vfs_unlink+0x4c/0x19
> > > 0
> > > [  605.427397]
> > > [  605.427397] which lock already depends on the new lock.
> > > [  605.427397]
> > > [  605.435770]
> > > [  605.435770] the existing dependency chain (in reverse order) is:
> > > [  605.443396]
> > > [  605.443396] -> #1 (>s_type->i_mutex_key#14){++}:
> > > [  605.450347]lock_acquire+0xc9/0x220
> > > [  605.454551]down_write+0x3f/0x70
> > > [  605.458484]pstore_mkfile+0x1f4/0x460
> > > [  605.462835]pstore_get_records+0x17a/0x320
> > > [  605.467664]pstore_fill_super+0xa4/0xc0
> > > [  605.472205]mount_single+0x89/0xb0
> > > [  605.476314]pstore_mount+0x13/0x20
> > > [  605.480411]mount_fs+0xf/0x90
> > > [  605.484122]vfs_kern_mount+0x66/0x170
> > > [  605.488464]do_mount+0x190/0xd50
> > > [  605.492397]SyS_mount+0x90/0xd0
> > > [  605.496212]entry_SYSCALL_64_fastpath+0x1c/0xb1
> > > [  605.501496]
> > > [  605.501496] -> #0 (>read_mutex){+.+.+.}:
> > > [  605.507747]__lock_acquire+0x1ac0/0x1bb0
> > > [  605.512401]lock_acquire+0xc9/0x220
> > > [  605.516594]__mutex_lock+0x6e/0x990
> > > [  605.520755]mutex_lock_nested+0x16/0x20
> > > [  605.525279]pstore_unlink+0x3f/0xa0
> > > [  605.529465]vfs_unlink+0xb5/0x190
> > > [  605.533477]do_unlinkat+0x24c/0x2a0
> > > [  605.537672]SyS_unlinkat+0x16/0x30
> > > [  605.541781]entry_SYSCALL_64_fastpath+0x1c/0xb1
> > 
> > If I'm reading this right it's a race between mount and unlink...
> > that's quite a corner case. :)
> > 
> > > [  605.547067]
> > > [  605.547067] other info that might help us debug this:
> > > [  605.547067]
> > > [  605.555221]  Possible unsafe locking scenario:
> > > [  605.555221]
> > > [  605.561280]CPU0CPU1
> > > [  605.565883]
> > > [  605.570502]   lock(>s_type->i_mutex_key#14);
> > > [  605.575217]lock(>read_mutex);
> > > [  605.581803]
> > > lock(>s_type->i_mutex_key#14);
> > > [  605.589159]   lock(>read_mutex);
> > 
> > I haven't had time to dig much yet, but I wonder if the locking order
> > on unlink could just be reversed, and the deadlock would go away?
> 
> IIUC, the unlink path locks a file in the root directory, while the
> mount path locks the root directory.  Maybe we can use a subclass?
> (not tested)

More puzzling, or just my confusion, reports from our CI farm say that
this patch breaks removing objects from pstote. :|

Will look forward to better suggestions on how to avoid lockdep.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH v6 10/11] drivers: perf: hisi: use poll method when no IRQ for MN counter overflow

[Mark Rutland]

On Fri, Mar 10, 2017 at 01:29:01AM -0500, Anurup M wrote:
> When no IRQ is supported in hardware, use hrtimer to poll and
> update event counter and avoid overflow condition for MN PMU.
> An interval of 8 seconds is used for the hrtimer.

Please fold this into the main MN patch.

The comments on the L3 hrtimer patch also apply here.

Thanks,
Mark.

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

[Nadav Amit]

> On Mar 21, 2017, at 9:58 AM, Radim Krčmář  wrote:

> In '-smp 2', the writing VCPU always does 1 wakeups by writing into
> monitored memory, but the mwaiting VCPU can be also woken up by host
> interrupts, which might add a few exits depending on timing.
> 
> I didn't spend much time in making the PASS/FAIL mean much, or ensuring
> that we only get 1 wakeups ... it is nothing to be worried about.
> 
> Hint 240 behaves as nop even on my system, so I still don't find
> anything insane on that machine (if OS X is exluded) ...

From my days in Intel (10 years ago), I can say that MWAIT wakes for many
microarchitecural events beside interrupts.

Out of curiosity, aren’t you worried that on OS X the wbinvd causes an exit
after the monitor and before the mwait?

Re: [PATCH v6 03/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU

[Mark Rutland]

On Tue, Mar 21, 2017 at 02:07:42PM +, Mark Rutland wrote:
> On Fri, Mar 10, 2017 at 01:27:27AM -0500, Anurup M wrote:
> > +HiSilicon SoC chip is encapsulated by multiple CPU and IO dies. The CPU die
> > +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every 
> > SCCL
> > +in HiP05/06/07 chips are further grouped as CPU clusters (CCL) which 
> > includes
> > +4 cpu-cores each.
> > +e.g. In the case of HiP05/06/07, each SCCL has 1 L3 cache and 1 MN PMU 
> > device.
> > +The L3 cache is further grouped as 4 L3 cache banks in a SCCL.
> > +
> > +The Hisilicon SoC PMU DT node bindings for uncore PMU devices are as below.
> > +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
> > +the parent node will be the djtag node of the corresponding CPU die (SCCL).
> > +
> > +L3 cache
> > +-
> > +The L3 cache is dedicated for each SCCL. Each SCCL in HiP05/06/07 chips 
> > have 4
> > +L3 cache banks. Each L3 cache bank have separate DT nodes.
> > +
> > +Required properties:
> > +
> > +   - compatible : This value should be as follows
> > +   (a) "hisilicon,hip05-pmu-l3c-v1" for v1 hw in HiP05 chipset
> > +   (b) "hisilicon,hip06-pmu-l3c-v1" for v1 hw in HiP06 chipset
> > +   (c) "hisilicon,hip07-pmu-l3c-v2" for v2 hw in HiP07 chipset
> > +
> > +   - hisilicon,module-id : This property is a combination of two values
> > +   in the below order.
> > +   a) Module ID: The module identifier for djtag.
> > +   b) Instance or Bank ID: This will identify the L3 cache bank
> > +or instance.
> 
> I take it this is intended two mean this property is two cells in
> length, with one cell for each of the below.
> 
> This is a somewhat confusing proeprty given that the name only applies
> to the first half of the value...

Please split this itno two properties, and have a hisilicon,instance-id
for the L3 nodes.

Thanks,
Mark.

Re: [PATCH v6 09/11] drivers: perf: hisi: Miscellanous node(MN) event counting in perf

[Mark Rutland]

On Fri, Mar 10, 2017 at 01:28:53AM -0500, Anurup M wrote:
> +static u32 hisi_mn_read_counter(struct hisi_mn_data *mn_data, int cntr_idx)
> +{
> + struct hisi_djtag_client *client = mn_data->client;
> + u32 module_id = GET_MODULE_ID(mn_data);
> + u32 reg_off, value;
> +
> + reg_off = get_counter_reg_off(cntr_idx);
> + hisi_djtag_readreg(module_id, MN1_BANK_SELECT, reg_off,
> +client, );

You need to handle this failing.

[...]

> + do {
> + /* Get count from the MN */
> + prev_raw_count = local64_read(>prev_count);
> + new_raw_count = hisi_mn_read_counter(mn_data, idx);
> + delta = (new_raw_count - prev_raw_count) & HISI_MAX_PERIOD;
> +
> + local64_add(delta, >count);
> + } while (local64_cmpxchg(>prev_count, prev_raw_count,
> +  new_raw_count) != prev_raw_count);

Same comment as for the l3 event update loop.

[...]

> + /*
> +  * Value to write to event select register
> +  * Each byte in the 32 bit select register is used to
> +  * configure the event code. Each byte correspond to a
> +  * counter register to use.
> +  */
> + val = event_value << (8 * idx);
> +
> + /*
> +  * Set the event in MN_EVENT_TYPE Register
> +  */
> + hisi_djtag_readreg(module_id, MN1_BANK_SELECT, MN1_EVTYPE_REG_OFF,
> +client, );
> + value &= ~(0xff << (8 * idx));
> + value |= val;
> + hisi_djtag_writereg(module_id, MN1_BANK_SELECT, MN1_EVTYPE_REG_OFF,
> + value, client);

Use a helper for this common pattern.

[...]

> +static int hisi_mn_pmu_init(struct hisi_pmu *mn_pmu,
> + struct hisi_djtag_client *client)
> +{
> + struct device *dev = >dev;
> +
> + mn_pmu->num_events = HISI_HWEVENT_MN_EVENT_MAX;
> + mn_pmu->num_counters = HISI_IDX_MN_COUNTER_MAX;
> + mn_pmu->scl_id = hisi_djtag_get_sclid(client);
> +
> + mn_pmu->name = kasprintf(GFP_KERNEL, "hisi_mn_%d", mn_pmu->scl_id);

This is leaked if we fail in hisi_pmu_mn_dev_probe()...

> +static int hisi_pmu_mn_dev_probe(struct hisi_djtag_client *client)
> +{
> + struct hisi_pmu *mn_pmu;
> + struct device *dev = >dev;
> + int ret;
> +
> + mn_pmu = hisi_pmu_alloc(dev);
> + if (!mn_pmu)
> + return -ENOMEM;
> +
> + ret = hisi_mn_pmu_init(mn_pmu, client);
> + if (ret)
> + return ret;
> +
> + ret = hisi_mn_init_data(mn_pmu, client);
> + if (ret)
> + return ret;

... e.g. here.

Thanks,
Mark.

[PATCH v3 0/2] Replace mlock with private lock and delete whitespaces

[simran singhal]

The patch series replaces mlock with a private lock for driver ad9834 and
Fix coding style issues related to white spaces.

v3:
  -Using new private "lock" instead of using "buf_lock"
   as it can cause deadlock.
  -Sending it as a series of two patches.

v2:
  -Using the existing buf_lock instead of lock.
   

simran singhal (2):
  staging: iio: ade7753: Remove trailing whitespaces
  staging: iio: ade7753: Replace mlock with driver private lock

 drivers/staging/iio/meter/ade7753.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

-- 
2.7.4

Re: [PING PATCH v2] jump label: fix passing kbuild_cflags when checking for asm goto support

[Steven Rostedt]

On Wed, 22 Mar 2017 02:48:44 +0900
Masahiro Yamada  wrote:

> 
> I assume this PING is addressed to me.
> 
> First, Steven asked Andrew to pick up this,
> but I have not seen it in linux-next yet. So,
> 
> Applied to linux-kbuild/fixes.  Thanks!

Thanks Masahiro!

-- Steve

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

[Jonathan Cameron]

On 21 March 2017 17:27:02 GMT+00:00, Julia Lawall  wrote:
>
>
>On Tue, 21 Mar 2017, Arushi Singhal wrote:
>
>>
>>
>> On Tue, Mar 21, 2017 at 10:32 PM, Alison Schofield
>
>> wrote:
>>   On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote:
>>   >
>>   >
>>   > On Tue, 21 Mar 2017, Arushi Singhal wrote:
>>   >
>>   > > On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield
>>   
>>   > > wrote:
>>   > >       On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi
>>   Singhal wrote:
>>   > >       > Patchseries of IIO coding tasks
>>   > >
>>   > >       This wouldn't be a patchset.  Although they touch the
>>   same
>>   > >       driver, the changes are unrelated.  See more below...
>>   > >
>>   > > This I have send as a Patchset because as you have
>mentioned
>>   below that the
>>   > > [PATCH 2/2] was already done before by someone but I think
>>   so it is not yet
>>   > > applied in the Greg's tree yet.So I have done both the
>>   changes and as they
>>   > > should be applied one after other so that's why I have send
>>   them as
>>   > > Patchset.
>>   >
>>   > For the IIO patches, it is better to work on the IIO tree,
>not
>>   Greg's.
>>   > Greg manages staging, not IIO.  The IIO patches should appear
>>   in Greg's
>>   > tree eventually.
>>   >
>>   > julia
>>
>>   We didn't direct applicants to create an iio tree.  At this
>>   point,
>>   it seems more than is necessary.  They can follow the
>directions
>>   in the
>>   task descriptions and avoid the collisions.
>>
>>   Of course, they are welcome to create a tree to iio/testing.
>>
>>   (IMHO it's more overhead/busy work and maybe not the best use
>>   of time in the home stretch of the application period.)
>>
>>   alisons
>>
>>
>> Hi Alison
>> As you have mentioned that my [PATCH 2/2] is already being done
>someone. So
>> how can I make the changes of [PATCH 1/2] on top of it as [PATCH 2/2]
>is not
>> yet applied on the staging tree.
>
>Make a patch that applies to the current state of the IIO tree.  Just
>clone that one like you cloned the staging one.
>
>julia
>
Slight amendment,. Normally would be the togreg branch which doesn't rebase.

With all the current churn might be best to use the testing branch and i will 
fix up any issues if i
 have to rebase as result of build tests.

Will.send Greg a pull later anyway, so should be less difference after he pulls 
that.

J
>> Please suggest me.
>> Thanks
>> Arushi
>>   >
>>   > >       >
>>   > >       > Arushi Singhal (2):
>>   > >       >   staging: ad7759: Replace mlock with driver
>private
>>   lock
>>   > >
>>   > >       This one is already been submitted.  If you have a v2
>>   for it,
>>   > >       then v2
>>   > >       the original patch.
>>   > >
>>   > > Is it submitted by me only before? And this is not the v2.
>>   > > I have just resed it.
>>   > >       >   staging: iio: ade7759: Move header content to
>>   implementation
>>   > >       file
>>   > >
>>   > >       This patch is done and applied already.  See the
>>   Coding Task #1
>>   > >       notes
>>   > >       in the IIO Tasks page.
>>   > >
>>   > > Not at applied I think so.
>>   > > Thanks
>>   > > Arushi
>>   > >
>>   > >       alisons
>>   > >
>>   > >       >
>>   > >       >  drivers/staging/iio/meter/ade7759.c   | 56
>>   > >       +--
>>   > >       >  drivers/staging/iio/meter/ade7759.h   | 53
>>   > >       -
>>   > >       >  2 files changed, 54 insertions(+), 57 deletions(-)
>>   > >       >
>>   > >       > --
>>   > >       > 2.11.0
>>   > >       >
>>   > > > --
>>   > > > You received this message because you are subscribed to
>>   the Google
>>   > > Groups "outreachy-kernel" group.
>>   > > > To unsubscribe from this group and stop receiving emails
>>   from it,
>>   > > send an email to
>>   outreachy-kernel+unsubscr...@googlegroups.com.
>>   > > > To post to this group, send email to
>>   > > outreachy-ker...@googlegroups.com.
>>   > > > To view this discussion on the
>webvisithttps://groups.google.com/d/msgid/outreachy-kernel/20170321133021.6737
>>   -1-ar
>>   > > ushisinghal19971997%40gmail.com.
>>   > > > For more options, visit
>>   https://groups.google.com/d/optout.
>>   > >
>>   > >
>>   > > --
>>   > > You received this message because you are subscribed to the
>>   Google Groups
>>   > > "outreachy-kernel" group.
>>   > > To unsubscribe from this group and stop receiving emails
>>   from it, send an
>>   > > email to 

[PATCH v3 1/2] staging: iio: ade7753: Remove trailing whitespaces

[simran singhal]

This patch removes trailing whitespaces in order to follow the Linux
coding style.

Signed-off-by: simran singhal 
---
 drivers/staging/iio/meter/ade7753.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/meter/ade7753.c 
b/drivers/staging/iio/meter/ade7753.c
index dfd8b71..b71fbd3 100644
--- a/drivers/staging/iio/meter/ade7753.c
+++ b/drivers/staging/iio/meter/ade7753.c
@@ -83,10 +83,10 @@
  * @buf_lock:   mutex to protect tx and rx
  **/
 struct ade7753_state {
-   struct spi_device   *us;
-   struct mutexbuf_lock;
-   u8  tx[ADE7753_MAX_TX] 
cacheline_aligned;
-   u8  rx[ADE7753_MAX_RX];
+   struct spi_device   *us;
+   struct mutexbuf_lock;
+   u8  tx[ADE7753_MAX_TX] cacheline_aligned;
+   u8  rx[ADE7753_MAX_RX];
 };
 
 static int ade7753_spi_write_reg_8(struct device *dev,
-- 
2.7.4

[PATCH v3 2/2] staging: iio: ade7753: Replace mlock with driver private lock

[simran singhal]

The IIO subsystem is redefining iio_dev->mlock to be used by
the IIO core only for protecting device operating mode changes.
ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.

In this driver, mlock was being used to protect hardware state
changes.  Replace it with a lock in the devices global data.

Signed-off-by: simran singhal 
---
 drivers/staging/iio/meter/ade7753.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/meter/ade7753.c 
b/drivers/staging/iio/meter/ade7753.c
index b71fbd3..9674e05 100644
--- a/drivers/staging/iio/meter/ade7753.c
+++ b/drivers/staging/iio/meter/ade7753.c
@@ -80,11 +80,13 @@
  * @us: actual spi_device
  * @tx: transmit buffer
  * @rx: receive buffer
+ * @lock:   protect sensor state
  * @buf_lock:   mutex to protect tx and rx
  **/
 struct ade7753_state {
struct spi_device   *us;
struct mutexbuf_lock;
+   struct mutexlock;  /* protect sensor state */
u8  tx[ADE7753_MAX_TX] cacheline_aligned;
u8  rx[ADE7753_MAX_RX];
 };
@@ -484,7 +486,7 @@ static ssize_t ade7753_write_frequency(struct device *dev,
if (!val)
return -EINVAL;
 
-   mutex_lock(_dev->mlock);
+   mutex_lock(>lock);
 
t = 27900 / val;
if (t > 0)
@@ -505,7 +507,7 @@ static ssize_t ade7753_write_frequency(struct device *dev,
ret = ade7753_spi_write_reg_16(dev, ADE7753_MODE, reg);
 
 out:
-   mutex_unlock(_dev->mlock);
+   mutex_unlock(>lock);
 
return ret ? ret : len;
 }
-- 
2.7.4

[Q] Figuring out task mode

[Cyrill Gorcunov]

/I renamed the mail's subject/

On Tue, Mar 21, 2017 at 10:45:57AM -0700, Andy Lutomirski wrote:
> >> + task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
> >>   current->thread.status &= ~TS_COMPAT;
> >
> > Hi! I must admit I didn't follow close the overall series (so can't
> > comment much here :) but I have a slightly unrelated question -- is
> > there a way to figure out if task is running in x32 mode say with
> > some ptrace or procfs sign?
> 
> You should be able to figure out of a *syscall* is x32 by simply
> looking at bit 30 in the syscall number.  (This is unlike i386, which
> is currently not reflected in ptrace.)

Yes, syscall number will help but from criu perpspective (until
Dima's patches are merged into mainlie) we need to figure out
if we can dump x32 tasks without running parasite code inside,
ie via plain ptrace call or some procfs output. But looks like
it's impossible for now.

> Do we actually have an x32 per-task mode at all?  If so, maybe we can
> just remove it on top of Dmitry's series.

Don't think so, x32 should be set upon exec and without Dima's series
it is immutable I think.

Re: [lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

[Thomas Garnier]

This error happens even with Andy TLS fix on 32-bit (GDT is on fixmap
but not readonly). I am looking into it.

KVM internal error. Suberror: 3
extra data[0]: 8b0e
extra data[1]: 31
EAX=0001 EBX=9f9121f3 ECX=4330b100 EDX=f000
ESI=547e EDI=ffa74000 EBP=42273ef8 ESP=42273ef8
EIP=4105a0a2 EFL=00210002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =007b   00c0f300 DPL=3 DS   [-WA]
CS =0060   00c09b00 DPL=0 CS32 [-RA]
SS =0068   00c09300 DPL=0 DS   [-WA]
DS =007b   00c0f300 DPL=3 DS   [-WA]
FS =00d8 1232d000  00809300 DPL=0 DS16 [-WA]
GS =00e0 5492d4c0 0018 00409100 DPL=0 DS   [--A]
LDT=   00c0
TR =0080 5492b340 206b 8b00 DPL=0 TSS32-busy
GDT= ffa94000 00ff
IDT= fffba000 07ff
CR0=80050033 CR2=ff874000 CR3=0261 CR4=0690
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EFER=
Code=f0 d7 00 b8 01 00 00 00 8b 15 ec 48 29 42 8a 8a 00 50 87 ff <88>
8a 00 50 87 ff 31 c0 5d c3 55 89 e5 57 56 53 e8 8d f0 d7 00 89 c6 a1
00 ff dd 42 05 00

On Mon, Mar 20, 2017 at 9:57 PM, kernel test robot
 wrote:
>
> FYI, we noticed the following commit:
>
> commit: 69218e47994da614e7af600bf06887750ab6657a ("x86: Remap GDT tables in 
> the fixmap section")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> in testcase: trinity
> with following parameters:
>
> runtime: 300s
>
> test-description: Trinity is a linux system call fuzz tester.
> test-url: http://codemonkey.org.uk/projects/trinity/
>
>
> on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 320M
>
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
>
>
> +--+++
> |  | f06bdd4001 | 
> 69218e4799 |
> +--+++
> | boot_successes   | 3  | 
> 0  |
> | boot_failures| 5  | 
> 8  |
> | BUG:kernel_reboot-without-warning_in_boot_stage  | 4  | 
>|
> | WARNING:at_arch/x86/include/asm/fpu/internal.h:#fpu__restore | 1  | 
>|
> | BUG:kernel_hang_in_boot_stage| 0  | 
> 8  |
> +--+++
>
> [0.00] sysrq: sysrq always enabled.
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> [0.00] Initializing CPU#0
> [0.00] allocated 331644 bytes of page_ext
> [0.00] Initializing HighMem for node 0 (:)
> [0.00] Memory: 267332K/327160K available (14061K kernel code, 1104K 
> rwdata, 4696K rodata, 2460K init, 13208K bss, 59828K reserved, 0K 
> cma-reserved, 0K highmem)
> [0.00] virtual kernel memory layout:
> [0.00] fixmap  : 0xffa74000 - 0xf000   (5676 kB)
> [0.00] pkmap   : 0xff40 - 0xff80   (4096 kB)
> [0.00] vmalloc : 0x547e - 0xff3fe000   (2732 MB)
> [0.00] lowmem  : 0x4000 - 0x53fe   ( 319 MB)
> [0.00]   .init : 0x4236a000 - 0x425d1000   (2460 kB)
> [0.00]   .data : 0x41dbb72c - 0x42368300   (5810 kB)
> [0.00]   .text : 0x4100 - 0x41dbb72c   (14061 kB)
>
>
> Elapsed time: 480
> BUG: kernel hang in boot stage
>
> initrds=(
> /osimage/yocto/yocto-tiny-i386-2016-04-22.cgz
> 
> /lkp/scheduled/vm-lkp-hsw01-yocto-i386-25/trinity-300s-yocto-tiny-i386-2016-04-22.cgz-69218e47994da614e7af600bf06887750ab6657a-20170319-117821-bls48g-0.cgz
> /lkp/lkp/lkp-i386.cgz
>
>
> To reproduce:
>
> git clone https://github.com/01org/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k  job-script  # job-script is attached in 
> this email
>
>
>
> Thanks,
> Xiaolong



-- 
Thomas

Re: [PATCH] Staging: ks7010 - fixed style block comments

[Greg KH]

On Wed, Mar 22, 2017 at 07:29:50AM +1300, Derek Robson wrote:
> On Tue, Mar 21, 2017 at 08:56:25AM +0100, Greg KH wrote:
> > On Sun, Mar 19, 2017 at 01:07:17PM +1300, Derek Robson wrote:
> > > Fixed style of all block comments across whole driver
> > > Found by checkpatch
> > > 
> > > Signed-off-by: Derek Robson 
> > > ---
> > >  drivers/staging/ks7010/ks7010_sdio.c |  3 ++-
> > >  drivers/staging/ks7010/ks_hostif.h   | 35 +-
> > >  drivers/staging/ks7010/ks_wlan.h |  3 ++-
> > >  drivers/staging/ks7010/ks_wlan_net.c | 41 
> > > +++-
> > >  4 files changed, 55 insertions(+), 27 deletions(-)
> > 
> > This patch doesn't apply to my tree at all :(
> >
> 
> Am I working from the right/best tree for driver/staging?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git

What branch did you use?  You should use staging-next, or worse case,
staging-testing.  Don't use 'master', as that tracks Linus's tree and is
usually quite old.

thanks,

greg k-h

Applied "spi: loopback-test: fix potential integer overflow on multiple" to the spi tree

[Mark Brown]

The patch

   spi: loopback-test: fix potential integer overflow on multiple

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From d2c14c64d678713fced6f2261ce7d398b4351de5 Mon Sep 17 00:00:00 2001
From: Colin Ian King 
Date: Mon, 20 Mar 2017 13:58:05 +
Subject: [PATCH] spi: loopback-test: fix potential integer overflow on
 multiple

A multiplication of 8U * xfer-len with the type of a 32 bit unsigned int
is evaluated using 32 bit arithmetic and then used in a context that
expects an expression of type unsigned long long (64 bits).  Avoid any
potential overflow by casting BITS_PER_BYTE to unsigned long long.

Detected by CoverityScan, CID#1419691 ("Unintentional integer overflow")

Fixes: ea9936f324356 ("spi: loopback-test: add elapsed time check")
Signed-off-by: Colin Ian King 
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-loopback-test.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-loopback-test.c b/drivers/spi/spi-loopback-test.c
index fcae3377ec26..6888d5c34ac4 100644
--- a/drivers/spi/spi-loopback-test.c
+++ b/drivers/spi/spi-loopback-test.c
@@ -508,7 +508,8 @@ static int spi_test_check_elapsed_time(struct spi_device 
*spi,
 
for (i = 0; i < test->transfer_count; i++) {
struct spi_transfer *xfer = test->transfers + i;
-   unsigned long long nbits = BITS_PER_BYTE * xfer->len;
+   unsigned long long nbits = (unsigned long long)BITS_PER_BYTE *
+  xfer->len;
 
delay_usecs += xfer->delay_usecs;
if (!xfer->speed_hz)
-- 
2.11.0

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

[Jeff Layton]

On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote:
> On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> > > - It's durable; the above comparison still works if there were reboots
> > >   between the two i_version checks.
> > >   - I don't know how realistic this is--we may need to figure out
> > > if there's a weaker guarantee that's still useful.  Do
> > > filesystems actually make ctime/mtime/i_version changes
> > > atomically with the changes that caused them?  What if a
> > > change attribute is exposed to an NFS client but doesn't make
> > > it to disk, and then that value is reused after reboot?
> > > 
> > 
> > Yeah, there could be atomicity there. If we bump i_version, we'll mark
> > the inode dirty and I think that will end up with the new i_version at
> > least being journalled before __mark_inode_dirty returns.
> 
> So you think the filesystem can provide the atomicity?  In more detail:
> 

Sorry, I hit send too quickly. That should have read:

"Yeah, there could be atomicity issues there."

I think providing that level of atomicity may be difficult, though
maybe there's some way to make the querying of i_version block until
the inode update has been journalled?

>   - if I write to a file, a simultaneous reader should see either
> (old data, old i_version) or (new data, new i_version), not a
> combination of the two.
>   - ditto for metadata modifications.
>   - the same should be true if there's a crash.
> 
> (If that's not possible, then I think we could live with a brief window
> of (new data, old i_version) as long as it doesn't persist beyond sync?)
> 
> > That said, I suppose it is possible for us to bump the counter, hand
> > that new counter value out to a NFS client and then the box crashes
> > before it makes it to the journal.
> > 
> > Not sure how big a problem that really is.
> 
> The other case I was wondering about may have been unclear.  Represent
> the state of a file by a (data, i_version) pair.  Say:
> 
>   - file is modified from (F, V) to (F', V+1).
>   - client reads and caches (F', V+1).
>   - server crashes before writeback, so disk still has (F, V).
>   - after restart, someone else modifies file to (F'', V+1).
>   - original client revalidates its cache, sees V+1, concludes
> file data is still F'.
> 
> This may not cause a real problem for clients depending only on
> traditional NFS close-to-open semantics.
> 
> 

No, I think that is a legitimate problem.

That said, after F'', the mtime would almost certainly be different
from the time after F', and that would likely be enough to prevent
confusion in NFS clients.

Applications that are just looking at i_version via statx() could get
confused though.

-- 
Jeff Layton 

Applied "spi: pl022: Document property values" to the spi tree

[Mark Brown]

The patch

   spi: pl022: Document property values

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 3c85871a8a7f079cd4a24877ac9e0bcc0b1c2e4a Mon Sep 17 00:00:00 2001
From: Antonio Borneo 
Date: Mon, 20 Mar 2017 10:59:59 +0100
Subject: [PATCH] spi: pl022: Document property values

The property "pl022,com-mode" can only assume one of the values of
the enum ssp_mode, defined in include/linux/amba/pl022.h
List the possible numeric values and report the associated meaning.

Signed-off-by: Antonio Borneo 
Signed-off-by: Mark Brown 
---
 Documentation/devicetree/bindings/spi/spi_pl022.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt 
b/Documentation/devicetree/bindings/spi/spi_pl022.txt
index 2692a5726c3f..7638b4968ddb 100644
--- a/Documentation/devicetree/bindings/spi/spi_pl022.txt
+++ b/Documentation/devicetree/bindings/spi/spi_pl022.txt
@@ -30,7 +30,10 @@ contain the following properties.
0: SPI
1: Texas Instruments Synchronous Serial Frame Format
2: Microwire (Half Duplex)
-- pl022,com-mode : polling, interrupt or dma
+- pl022,com-mode : specifies the transfer mode:
+   0: interrupt mode
+   1: polling mode (default mode if property not present)
+   2: DMA mode
 - pl022,rx-level-trig : Rx FIFO watermark level
 - pl022,tx-level-trig : Tx FIFO watermark level
 - pl022,ctrl-len : Microwire interface: Control length
-- 
2.11.0

[PATCH v3 07/11] iio: adc: sun4i-gpadc-iio: add support for A33 thermal sensor

[Quentin Schulz]

This adds support for the Allwinner A33 thermal sensor.

Unlike the A10, A13 and A31, the Allwinner A33 only has one channel
which is dedicated to the thermal sensor. Moreover, its thermal sensor
does not generate interruptions, thus we only need to directly read the
register storing the temperature value.

The MFD used by the A10, A13 and A31, was created to avoid breaking the
DT binding, but since the nodes for the ADC weren't there for the A33,
it is not needed.

Though the A33 does not have an internal ADC, it has a thermal sensor
which shares the same registers with GPADC of the already supported SoCs
and almost the same bits, for the same purpose (thermal sensor).

The thermal sensor behaves exactly the same (except the presence of
interrupts or not) on the different SoCs.

Signed-off-by: Quentin Schulz 
Acked-by: Lee Jones 
---

v3:
  - switched compatible from allwinner,sun8i-a33-gpadc-iio to
  allwinner,sun8i-a33-ths to better reflect the datasheet's name,
  - fixed the non-working if (!IS_ENABLED(THERMAL_OF)) by prefixing it with
  CONFIG,

v2:
  - removed added comments in Kconfig,
  - simplified Kconfig depends on condition,
  - removed THERMAL_OF requirement for sun8i,
  - renamed sun8i_gpadc_channels to sun8i_a33_gpadc_channels,
  - renamed use_dt boolean in no_irq as it reflects better why we need it,
  - removed spurious/unneeded modifications done in v1,

 drivers/iio/adc/Kconfig   |   2 +-
 drivers/iio/adc/sun4i-gpadc-iio.c | 100 --
 include/linux/mfd/sun4i-gpadc.h   |   4 ++
 3 files changed, 102 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 9f8b4b1..8c8ead6 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -562,7 +562,7 @@ config STX104
 config SUN4I_GPADC
tristate "Support for the Allwinner SoCs GPADC"
depends on IIO
-   depends on MFD_SUN4I_GPADC
+   depends on MFD_SUN4I_GPADC || MACH_SUN8I
help
  Say yes here to build support for Allwinner (A10, A13 and A31) SoCs
  GPADC. This ADC provides 4 channels which can be used as an ADC or as
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c 
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 7cb997a..74705aa 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -85,6 +85,12 @@ static const struct gpadc_data sun6i_gpadc_data = {
.adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
 };
 
+static const struct gpadc_data sun8i_a33_gpadc_data = {
+   .temp_offset = -1662,
+   .temp_scale = 162,
+   .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
+};
+
 struct sun4i_gpadc_iio {
struct iio_dev  *indio_dev;
struct completion   completion;
@@ -96,6 +102,7 @@ struct sun4i_gpadc_iio {
unsigned inttemp_data_irq;
atomic_tignore_temp_data_irq;
const struct gpadc_data *data;
+   boolno_irq;
/* prevents concurrent reads of temperature and ADC */
struct mutexmutex;
 };
@@ -138,6 +145,23 @@ static const struct iio_chan_spec 
sun4i_gpadc_channels_no_temp[] = {
SUN4I_GPADC_ADC_CHANNEL(3, "adc_chan3"),
 };
 
+static const struct iio_chan_spec sun8i_a33_gpadc_channels[] = {
+   {
+   .type = IIO_TEMP,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_OFFSET),
+   .datasheet_name = "temp_adc",
+   },
+};
+
+static const struct regmap_config sun4i_gpadc_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+   .fast_io = true,
+};
+
 static int sun4i_prepare_for_irq(struct iio_dev *indio_dev, int channel,
 unsigned int irq)
 {
@@ -247,6 +271,17 @@ static int sun4i_gpadc_temp_read(struct iio_dev 
*indio_dev, int *val)
 {
struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
 
+   if (info->no_irq) {
+   pm_runtime_get_sync(indio_dev->dev.parent);
+
+   regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
+
+   pm_runtime_mark_last_busy(indio_dev->dev.parent);
+   pm_runtime_put_autosuspend(indio_dev->dev.parent);
+
+   return 0;
+   }
+
return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
 }
 
@@ -454,6 +489,58 @@ static int sun4i_irq_init(struct platform_device *pdev, 
const char *name,
return 0;
 }
 
+static const struct of_device_id sun4i_gpadc_of_id[] = {
+   {
+   .compatible = "allwinner,sun8i-a33-ths",
+   .data = _a33_gpadc_data,
+   },
+   { /* sentinel */ }
+};
+
+static int sun4i_gpadc_probe_dt(struct platform_device *pdev,
+ 

Re: [PATCH 07/13] perf, tools: Add a simple expression parser for JSON

[Arnaldo Carvalho de Melo]

Em Mon, Mar 20, 2017 at 01:17:05PM -0700, Andi Kleen escreveu:
> From: Andi Kleen 
> 
> Add a simple expression parser good enough to parse JSON relation
> expressions. The parser is implemented using bison.

Renaming 'foo_expr' to 'foo_json_expr', as 'expr' is _way_ too
generic...

- Arnaldo
 
> This is just intended as an simple parser for internal usage
> in the event lists, not the beginning of a "perf scripting language"
> 
> v2: Use expr__ prefix instead of expr_
> Support multiple free variables for parser
> Signed-off-by: Andi Kleen 
> ---
>  tools/perf/tests/Build  |   1 +
>  tools/perf/tests/builtin-test.c |   4 +
>  tools/perf/tests/expr.c |  55 +
>  tools/perf/tests/tests.h|   1 +
>  tools/perf/util/Build   |   5 ++
>  tools/perf/util/expr.h  |  25 ++
>  tools/perf/util/expr.y  | 173 
> 
>  7 files changed, 264 insertions(+)
>  create mode 100644 tools/perf/tests/expr.c
>  create mode 100644 tools/perf/util/expr.h
>  create mode 100644 tools/perf/util/expr.y
> 
> diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
> index 1cb3d9b540e9..af58ebc243ef 100644
> --- a/tools/perf/tests/Build
> +++ b/tools/perf/tests/Build
> @@ -38,6 +38,7 @@ perf-y += cpumap.o
>  perf-y += stat.o
>  perf-y += event_update.o
>  perf-y += event-times.o
> +perf-y += expr.o
>  perf-y += backward-ring-buffer.o
>  perf-y += sdt.o
>  perf-y += is_printable_array.o
> diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
> index 83c4669cbc5b..86822969e8a8 100644
> --- a/tools/perf/tests/builtin-test.c
> +++ b/tools/perf/tests/builtin-test.c
> @@ -44,6 +44,10 @@ static struct test generic_tests[] = {
>   .func = test__parse_events,
>   },
>   {
> + .desc = "Simple expression parser",
> + .func = test__expr,
> + },
> + {
>   .desc = "PERF_RECORD_* events & perf_sample fields",
>   .func = test__PERF_RECORD,
>   },
> diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
> new file mode 100644
> index ..554695c06c5b
> --- /dev/null
> +++ b/tools/perf/tests/expr.c
> @@ -0,0 +1,55 @@
> +#include "util/debug.h"
> +#include "util/expr.h"
> +#include "tests.h"
> +
> +static int test(struct parse_ctx *ctx, const char *e, double val2)
> +{
> + double val;
> +
> + if (expr__parse(, ctx, ))
> + TEST_ASSERT_VAL("parse test failed", 0);
> + TEST_ASSERT_VAL("unexpected value", val == val2);
> + return 0;
> +}
> +
> +int test__expr(int subtest __maybe_unused)
> +{
> + const char *p;
> + const char **other;
> + double val;
> + int ret;
> + struct parse_ctx ctx;
> + int num_other;
> +
> + expr__ctx_init();
> + expr__add_id(, "FOO", 1);
> + expr__add_id(, "BAR", 2);
> +
> + ret = test(, "1+1", 2);
> + ret |= test(, "FOO+BAR", 3);
> + ret |= test(, "(BAR/2)%2", 1);
> + ret |= test(, "1 - -4",  5);
> + ret |= test(, "(FOO-1)*2 + (BAR/2)%2 - -4",  5);
> +
> + if (ret)
> + return ret;
> +
> + p = "FOO/0";
> + ret = expr__parse(, , );
> + TEST_ASSERT_VAL("division by zero", ret == 1);
> +
> + p = "BAR/";
> + ret = expr__parse(, , );
> + TEST_ASSERT_VAL("missing operand", ret == 1);
> +
> + TEST_ASSERT_VAL("find other",
> + expr__find_other("FOO + BAR + BAZ + BOZO", "FOO", 
> , _other) == 0);
> + TEST_ASSERT_VAL("find other", num_other == 3);
> + TEST_ASSERT_VAL("find other", !strcmp(other[0], "BAR"));
> + TEST_ASSERT_VAL("find other", !strcmp(other[1], "BAZ"));
> + TEST_ASSERT_VAL("find other", !strcmp(other[2], "BOZO"));
> + TEST_ASSERT_VAL("find other", other[3] == NULL);
> + free((void *)other);
> +
> + return 0;
> +}
> diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
> index 1fa9b9d83aa5..631859629403 100644
> --- a/tools/perf/tests/tests.h
> +++ b/tools/perf/tests/tests.h
> @@ -62,6 +62,7 @@ int test__sample_parsing(int subtest);
>  int test__keep_tracking(int subtest);
>  int test__parse_no_sample_id_all(int subtest);
>  int test__dwarf_unwind(int subtest);
> +int test__expr(int subtest);
>  int test__hists_filter(int subtest);
>  int test__mmap_thread_lookup(int subtest);
>  int test__thread_mg_share(int subtest);
> diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> index fb4f42f1bb38..0b98534a9ea1 100644
> --- a/tools/perf/util/Build
> +++ b/tools/perf/util/Build
> @@ -90,6 +90,7 @@ libperf-y += mem-events.o
>  libperf-y += vsprintf.o
>  libperf-y += drv_configs.o
>  libperf-y += time-utils.o
> +libperf-y += expr-bison.o
>  
>  libperf-$(CONFIG_LIBBPF) += bpf-loader.o
>  libperf-$(CONFIG_BPF_PROLOGUE) += bpf-prologue.o
> @@ -142,6 +143,10 @@ $(OUTPUT)util/parse-events-bison.c: util/parse-events.y
>   $(call rule_mkdir)
>   $(Q)$(call echo-cmd,bison)$(BISON) 

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

[J. Bruce Fields]

On Tue, Mar 21, 2017 at 02:46:53PM -0400, Jeff Layton wrote:
> On Tue, 2017-03-21 at 14:30 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> > > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> > > > - It's durable; the above comparison still works if there were reboots
> > > >   between the two i_version checks.
> > > > - I don't know how realistic this is--we may need to figure out
> > > >   if there's a weaker guarantee that's still useful.  Do
> > > >   filesystems actually make ctime/mtime/i_version changes
> > > >   atomically with the changes that caused them?  What if a
> > > >   change attribute is exposed to an NFS client but doesn't make
> > > >   it to disk, and then that value is reused after reboot?
> > > > 
> > > 
> > > Yeah, there could be atomicity there. If we bump i_version, we'll mark
> > > the inode dirty and I think that will end up with the new i_version at
> > > least being journalled before __mark_inode_dirty returns.
> > 
> > So you think the filesystem can provide the atomicity?  In more detail:
> > 
> 
> Sorry, I hit send too quickly. That should have read:
> 
> "Yeah, there could be atomicity issues there."
> 
> I think providing that level of atomicity may be difficult, though
> maybe there's some way to make the querying of i_version block until
> the inode update has been journalled?

No idea.  Anyway, I'd like to figure out some reasonable requirement
that we can document.

> 
> > - if I write to a file, a simultaneous reader should see either
> >   (old data, old i_version) or (new data, new i_version), not a
> >   combination of the two.
> > - ditto for metadata modifications.
> > - the same should be true if there's a crash.
> > 
> > (If that's not possible, then I think we could live with a brief window
> > of (new data, old i_version) as long as it doesn't persist beyond sync?)
> > 
> > > That said, I suppose it is possible for us to bump the counter, hand
> > > that new counter value out to a NFS client and then the box crashes
> > > before it makes it to the journal.
> > > 
> > > Not sure how big a problem that really is.
> > 
> > The other case I was wondering about may have been unclear.  Represent
> > the state of a file by a (data, i_version) pair.  Say:
> > 
> > - file is modified from (F, V) to (F', V+1).
> > - client reads and caches (F', V+1).
> > - server crashes before writeback, so disk still has (F, V).
> > - after restart, someone else modifies file to (F'', V+1).
> > - original client revalidates its cache, sees V+1, concludes
> >   file data is still F'.
> > 
> > This may not cause a real problem for clients depending only on
> > traditional NFS close-to-open semantics.
> > 
> > 
> 
> No, I think that is a legitimate problem.
> 
> That said, after F'', the mtime would almost certainly be different
> from the time after F', and that would likely be enough to prevent
> confusion in NFS clients.

Oh, good point.  So, may be worth saying that anyone wanting to make
sense of these across reboot should compare times as well (maybe that
should be in nfs rfc's too).  I think that should be ctime not mtime,
though?

--b.

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

[Cyrill Gorcunov]

On Tue, Mar 21, 2017 at 11:51:09AM -0700, h...@zytor.com wrote:
> >
> >indeed, thanks!
> 
> I proposed to the ptrace people a virtual register for this and a few other 
> things, but it got bikeshed to death.

Any mail reference left? Would like to read it.

[PATCH] drivers: staging: vt6656: fixed coding style errors

[Prasant Jalan]

This patch replaces spaces with tabs for indentation as per kernel
coding standards.

Signed-off-by: Prasant Jalan 
---
 drivers/staging/vt6656/rf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..0e3a62a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,8 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2, length,
+   array);
 
length2 -= length;
value += length;
-- 
2.7.4

Re: [PATCH] arm64: dts: hi6220: enable DMA in spi0

[Antonio Borneo]

On Tue, Mar 21, 2017 at 8:08 AM, Guodong Xu  wrote:
> From: Wang Xiaoyin 
>
> Enable DMA in spi0.

Hi Guodong, Xiaoyin,

added linux-spi in copy.

Actually the patch does not enable the DMA. The commit message is not correct.

> Cc: Antonio Borneo 
> Signed-off-by: Zhong Kaihua 
> Signed-off-by: Guodong Xu 
> Signed-off-by: Wang Xiaoyin 
> ---
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 470461d..e40625f 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -682,7 +682,8 @@
> reg = <0x0 0xf7106000 0x0 0x1000>;
> interrupts = <0 50 4>;
> bus-id = <0>;
> -   enable-dma = <0>;
> +   dmas =  < 0  1>;
> +   dma-names = "rx", "tx";

The controller spi0 is a standard ARM PL022.
This patch removes the nonexistent property "enable-dma" and specifies
which DMA controller and which DMA channels are connected to spi0.
The values are coherent with the documentation available for hi6220.

Apart from the commit message, I'm fine with this patch.

On PL022 the DMA is not enabled in the DT node of the controller but
in the DT node of each spi device, through the property
"pl022,com-mode".
A separate patch should eventually enable the DMA for those spi
devices that require it.

Best Regards,
Antonio

> clocks = <_ctrl HI6220_SPI_CLK>;
> clock-names = "apb_pclk";
> pinctrl-names = "default";
> --
> 2.10.2
>

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

[Julia Lawall]

On Tue, 21 Mar 2017, Alison Schofield wrote:

> On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote:
> >
> >
> > On Tue, 21 Mar 2017, Arushi Singhal wrote:
> >
> > > On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield 
> > > wrote:
> > >   On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi Singhal wrote:
> > >   > Patchseries of IIO coding tasks
> > >
> > >   This wouldn't be a patchset.  Although they touch the same
> > >   driver, the changes are unrelated.  See more below...
> > >
> > > This I have send as a Patchset because as you have mentioned below that 
> > > the
> > > [PATCH 2/2] was already done before by someone but I think so it is not 
> > > yet
> > > applied in the Greg's tree yet.So I have done both the changes and as they
> > > should be applied one after other so that's why I have send them as
> > > Patchset.
> >
> > For the IIO patches, it is better to work on the IIO tree, not Greg's.
> > Greg manages staging, not IIO.  The IIO patches should appear in Greg's
> > tree eventually.
> >
> > julia
>
> We didn't direct applicants to create an iio tree.  At this point,
> it seems more than is necessary.  They can follow the directions in the
> task descriptions and avoid the collisions.

I meant just pull from the IIO tree you mentioned, work on that, submit
patches, and then expect to see the patches show up there at some time in
the future.

If someone make IIO patches on Greg's tree, then they will have an out of
date view.

julia

>
> Of course, they are welcome to create a tree to iio/testing.
>
> (IMHO it's more overhead/busy work and maybe not the best use
> of time in the home stretch of the application period.)
>
> alisons
> >
> > >   >
> > >   > Arushi Singhal (2):
> > >   >   staging: ad7759: Replace mlock with driver private lock
> > >
> > >   This one is already been submitted.  If you have a v2 for it,
> > >   then v2
> > >   the original patch.
> > >
> > > Is it submitted by me only before? And this is not the v2.
> > > I have just resed it.
> > >   >   staging: iio: ade7759: Move header content to implementation
> > >   file
> > >
> > >   This patch is done and applied already.  See the Coding Task #1
> > >   notes
> > >   in the IIO Tasks page.
> > >
> > > Not at applied I think so.
> > > Thanks
> > > Arushi
> > >
> > >   alisons
> > >
> > >   >
> > >   >  drivers/staging/iio/meter/ade7759.c   | 56
> > >   +--
> > >   >  drivers/staging/iio/meter/ade7759.h   | 53
> > >   -
> > >   >  2 files changed, 54 insertions(+), 57 deletions(-)
> > >   >
> > >   > --
> > >   > 2.11.0
> > >   >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > Groups "outreachy-kernel" group.
> > > > To unsubscribe from this group and stop receiving emails from it,
> > > send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > > To post to this group, send email to
> > > outreachy-ker...@googlegroups.com.
> > > > To view this discussion on the web 
> > > > visithttps://groups.google.com/d/msgid/outreachy-kernel/20170321133021.6737-1-ar
> > > ushisinghal19971997%40gmail.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "outreachy-kernel" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > > To view this discussion on the web 
> > > visithttps://groups.google.com/d/msgid/outreachy-kernel/CA%2BXqjF9dVy33Dsv0H2z8x
> > > taNeMOW7SQgr4qa4wLwz6xFNVTsUA%40mail.gmail.com.
> > > For more options, visit https://groups.google.com/d/optout.
> > >
> > >
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170321170221.GB2793%40d830.WORKGROUP.
> For more options, visit https://groups.google.com/d/optout.
>

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

[Dmitry Safonov]

On 03/21/2017 08:27 PM, h...@zytor.com wrote:

On March 21, 2017 9:37:12 AM PDT, Dmitry Safonov  wrote:

After my changes to mmap(), its code now relies on the bitness of
performing syscall. According to that, it chooses the base of
allocation:
mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall.
It was done by:
 commit 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for
32-bit mmap()").

The code afterwards relies on in_compat_syscall() returning true for
32-bit syscalls. It's usually so while we're in context of application
that does 32-bit syscalls. But during exec() it is not valid for x32
ELF.
The reason is that the application hasn't yet done any syscall, so x32
bit has not being set.
That results in -ENOMEM for x32 ELF files as there fired BAD_ADDR()
in elf_map(), that is called from do_execve()->load_elf_binary().
For i386 ELFs it works as SET_PERSONALITY() sets TS_COMPAT flag.

I suggest to set x32 bit before first return to userspace, during
setting personality at exec(). This way we can rely on
in_compat_syscall() during exec().

Fixes: commit 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for
32-bit mmap()")
Cc: 0x7f454...@gmail.com
Cc: linux...@kvack.org
Cc: Andrei Vagin 
Cc: Cyrill Gorcunov 
Cc: Borislav Petkov 
Cc: "Kirill A. Shutemov" 
Cc: x...@kernel.org
Cc: H. Peter Anvin 
Cc: Andy Lutomirski 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Reported-by: Adam Borowski 
Signed-off-by: Dmitry Safonov 
---
v2:
- specifying mmap() allocation path which failed during exec()
- fix comment style

arch/x86/kernel/process_64.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/process_64.c
b/arch/x86/kernel/process_64.c
index d6b784a5520d..d3d4d9abcaf8 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -519,8 +519,14 @@ void set_personality_ia32(bool x32)
if (current->mm)
current->mm->context.ia32_compat = TIF_X32;
current->personality &= ~READ_IMPLIES_EXEC;
-   /* in_compat_syscall() uses the presence of the x32
-  syscall bit flag to determine compat status */
+   /*
+* in_compat_syscall() uses the presence of the x32
+* syscall bit flag to determine compat status.
+* On the bitness of syscall relies x86 mmap() code,
+* so set x32 syscall bit right here to make
+* in_compat_syscall() work during exec().
+*/
+   task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
current->thread.status &= ~TS_COMPAT;
} else {
set_thread_flag(TIF_IA32);


You also need to clear the bit for an x32 -> x86-64 exec.  Otherwise it seems 
okay to me.


Oh, indeed!
Thanks for catching, I'll send v3 with it.

--
 Dmitry

[PATCH v3 10/11] ARM: sun8i: a33: Add devfreq-based GPU cooling

[Quentin Schulz]

From: Maxime Ripard 

This adds GPU thermal throttling for the Allwinner A33.

Signed-off-by: Maxime Ripard 
Signed-off-by: Quentin Schulz 
---

v3:
  - got rid of cooling-min-level and cooling-max-level as it's not used in any
  code in the kernel,

added in v2

 arch/arm/boot/dts/sun8i-a23-a33.dtsi |  1 +
 arch/arm/boot/dts/sun8i-a33.dtsi | 24 
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 5e8725d..6d81a6d 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -495,6 +495,7 @@
 
assigned-clocks = < CLK_GPU>;
assigned-clock-rates = <38400>;
+   #cooling-cells = <2>;
};
 
gic: interrupt-controller@01c81000 {
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 73552bb..a2c6077 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -188,6 +188,16 @@
trip = <_alert1>;
cooling-device = < 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
};
+
+   map2 {
+   trip = <_alert0>;
+   cooling-device = < 1 
THERMAL_NO_LIMIT>;
+   };
+
+   map3 {
+   trip = <_alert1>;
+   cooling-device = < 2 
THERMAL_NO_LIMIT>;
+   };
};
 
trips {
@@ -198,6 +208,13 @@
type = "passive";
};
 
+   gpu_alert0: gpu_alert0 {
+   /* milliCelsius */
+   temperature = <85000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
cpu_alert1: cpu_alert1 {
/* milliCelsius */
temperature = <9>;
@@ -205,6 +222,13 @@
type = "hot";
};
 
+   gpu_alert1: gpu_alert1 {
+   /* milliCelsius */
+   temperature = <95000>;
+   hysteresis = <2000>;
+   type = "hot";
+   };
+
cpu_crit: cpu_crit {
/* milliCelsius */
temperature = <11>;
-- 
2.9.3

Re: [PATCH v2] Kbuild: make designated_init attribute fatal

[Masahiro Yamada]

2017-03-21 9:14 GMT+09:00 Kees Cook :
> If a structure is marked with __attribute__((designated_init)) from
> GCC or Sparse, it needs to have all static initializers using designated
> initialization. Fail the build for any missing cases. This attribute will
> be used by the randstruct plugin to make sure randomized structures are
> being correctly initialized.
>
> Signed-off-by: Kees Cook 
> ---
> v2: update subject to more clearly describe change, Masahiro Yamada
> ---


Applied to linux-kbuild/kbuild.   Thanks!



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 2/3] asm-generic, x86: wrap atomic operations

[Dmitry Vyukov]

On Tue, Mar 21, 2017 at 11:41 AM, Mark Rutland  wrote:
> On Tue, Mar 21, 2017 at 12:25:06PM +0300, Andrey Ryabinin wrote:
>> On 03/20/2017 08:17 PM, Mark Rutland wrote:
>> > Hi,
>> >
>> > On Tue, Mar 14, 2017 at 08:24:13PM +0100, Dmitry Vyukov wrote:
>> >>  /**
>> >> - * atomic_read - read atomic variable
>> >> + * arch_atomic_read - read atomic variable
>> >>   * @v: pointer of type atomic_t
>> >>   *
>> >>   * Atomically reads the value of @v.
>> >>   */
>> >> -static __always_inline int atomic_read(const atomic_t *v)
>> >> +static __always_inline int arch_atomic_read(const atomic_t *v)
>> >>  {
>> >> -  return READ_ONCE((v)->counter);
>> >> +  /*
>> >> +   * We use READ_ONCE_NOCHECK() because atomic_read() contains KASAN
>> >> +   * instrumentation. Double instrumentation is unnecessary.
>> >> +   */
>> >> +  return READ_ONCE_NOCHECK((v)->counter);
>> >>  }
>> >
>> > Just to check, we do this to avoid duplicate reports, right?
>> >
>> > If so, double instrumentation isn't solely "unnecessary"; it has a
>> > functional difference, and we should explicitly describe that in the
>> > comment.
>> >
>> > ... or are duplicate reports supressed somehow?
>>
>> They are not suppressed yet. But I think we should just switch kasan
>> to single shot mode, i.e. report only the first error. Single bug
>> quite often has multiple invalid memory accesses causing storm in
>> dmesg. Also write OOB might corrupt metadata so the next report will
>> print bogus alloc/free stacktraces.
>> In most cases we need to look only at the first report, so reporting
>> anything after the first is just counterproductive.
>
> FWIW, that sounds sane to me.
>
> Given that, I agree with your comment regarding READ_ONCE{,_NOCHECK}().
>
> If anyone really wants all the reports, we could have a boot-time option
> to do that.


I don't mind changing READ_ONCE_NOCHECK to READ_ONCE. But I don't have
strong preference either way.

We could do:
#define arch_atomic_read_is_already_instrumented 1
and then skip instrumentation in asm-generic if it's defined. But I
don't think it's worth it.

There is no functional difference, it's only an optimization (now
somewhat questionable). As Andrey said, one can get a splash of
reports anyway, and it's the first one that is important. We use KASAN
with panic_on_warn=1 so we don't even see the rest.

Re: [PATCH 4/4] perf annotate: More exactly grep -v of the objdump command

[Arnaldo Carvalho de Melo]

Em Wed, Mar 22, 2017 at 01:19:49AM +0900, Taeung Song escreveu:
> On 03/21/2017 11:37 PM, Arnaldo Carvalho de Melo wrote:
> > > +++ b/tools/perf/util/annotate.c
> > > @@ -1443,7 +1443,7 @@ int symbol__disassemble(struct symbol *sym, struct 
> > > map *map, const char *arch_na
> > >   snprintf(command, sizeof(command),
> > >"%s %s%s --start-address=0x%016" PRIx64
> > >" --stop-address=0x%016" PRIx64
> > > -  " -l -d %s %s -C %s 2>/dev/null|grep -v %s|expand",
> > > +  " -l -d %s %s -C %s 2>/dev/null|grep -v %s: |expand",

> > Are you sure this works as you expect? I.e. both lines will have '%s:'
 
> Yes, if we do, we can exactly the only below line without the side effect
> IMHO.

yeah, because the .c is not there, ok gotcha, will get your new commit
log message, massage it a bit and apply the patch.

- Arnaldo

Re: [tip:x86/process] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

[Kyle Huey]

On Tue, Mar 21, 2017 at 1:34 AM, Ingo Molnar  wrote:
>
> * tip-bot for Kyle Huey  wrote:
>
>> Commit-ID:  e9ea1e7f53b852147cbd568b0568c7ad97ec21a3
>> Gitweb: 
>> http://git.kernel.org/tip/e9ea1e7f53b852147cbd568b0568c7ad97ec21a3
>> Author: Kyle Huey 
>> AuthorDate: Mon, 20 Mar 2017 01:16:26 -0700
>> Committer:  Thomas Gleixner 
>> CommitDate: Mon, 20 Mar 2017 16:10:34 +0100
>>
>> x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
>
> Note that this series broke the UML build:
>
>   /home/mingo/tip/arch/x86/um/syscalls_64.c:15:6: error: conflicting types 
> for ‘arch_prctl’
>   ...
>
> etc.
>
> Thanks,
>
> Ingo

Yes, I sent another patch ("um: fix build error due to typo")
yesterday and tglx applied it to x86/process.

- Kyle

[PATCH] drivers: staging: vt6656: fixed coding style errors

[Prasant Jalan]

This patch replaces spaces with tabs for indentation as per kernel
coding standards.

Signed-off-by: Prasant Jalan 
---
 drivers/staging/vt6656/rf.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
index 068c1c8..0e3a62a 100644
--- a/drivers/staging/vt6656/rf.c
+++ b/drivers/staging/vt6656/rf.c
@@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr1, length1);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
-   MESSAGE_REQUEST_RF_INIT, length1, array);
+   MESSAGE_REQUEST_RF_INIT, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH0, length, array);
+   value, MESSAGE_REQUEST_RF_CH0, length, array);
 
length2 -= length;
value += length;
@@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr3, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH1, length, array);
+   value, MESSAGE_REQUEST_RF_CH1, length, array);
 
length3 -= length;
value += length;
@@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
 
/* Init Table 2 */
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
+   0, MESSAGE_REQUEST_RF_INIT2, length1, array);
 
/* Channel Table 0 */
value = 0;
@@ -937,7 +937,8 @@ void vnt_rf_table_download(struct vnt_private *priv)
memcpy(array, addr2, length);
 
vnt_control_out(priv, MESSAGE_TYPE_WRITE,
-   value, MESSAGE_REQUEST_RF_CH2, length, 
array);
+   value, MESSAGE_REQUEST_RF_CH2, length,
+   array);
 
length2 -= length;
value += length;
-- 
2.7.4

Applied "spi: pl022: remove nonexistent properties from DT binding example" to the spi tree

[Mark Brown]

The patch

   spi: pl022: remove nonexistent properties from DT binding example

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From e6a72e057fa3e0ad38ec59c4779647a7bd390a37 Mon Sep 17 00:00:00 2001
From: Antonio Borneo 
Date: Mon, 20 Mar 2017 10:57:18 +0100
Subject: [PATCH] spi: pl022: remove nonexistent properties from DT binding
 example

The properties "pl022,hierarchy" and "pl022,slave-tx-disable" were
initially proposed till patch V4 [1] but then discarded in V5 [2]
when the patch set was taken over by another developer, as
explained in patch history in [3].
The above properties never landed in mainline code but were then
listed in the binding example by a following commit dc715452e914
("spi: pl022: use generic DMA slave configuration if possible")
and later on they were copy-paste in some board's DT.

Remove the nonexistent properties from the example.
Also remove a spaces-only line at the end of the file.

[1] https://lkml.org/lkml/2012/7/9/421
[2] https://lkml.org/lkml/2012/8/21/427
[3] https://lkml.org/lkml/2012/8/21/436

Signed-off-by: Antonio Borneo 
Signed-off-by: Mark Brown 
---
 Documentation/devicetree/bindings/spi/spi_pl022.txt | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt 
b/Documentation/devicetree/bindings/spi/spi_pl022.txt
index 4d1673ca8cf8..2692a5726c3f 100644
--- a/Documentation/devicetree/bindings/spi/spi_pl022.txt
+++ b/Documentation/devicetree/bindings/spi/spi_pl022.txt
@@ -56,9 +56,7 @@ Example:
spi-max-frequency = <1200>;
spi-cpol;
spi-cpha;
-   pl022,hierarchy = <0>;
pl022,interface = <0>;
-   pl022,slave-tx-disable;
pl022,com-mode = <0x2>;
pl022,rx-level-trig = <0>;
pl022,tx-level-trig = <0>;
@@ -67,4 +65,3 @@ Example:
pl022,duplex = <0>;
};
};
-   
-- 
2.11.0

Re: [PATCH] drivers: staging: vt6656: fixed coding style errors

[Greg KH]

On Wed, Mar 22, 2017 at 12:10:50AM +0530, Prasant Jalan wrote:
> This patch replaces spaces with tabs for indentation as per kernel
> coding standards.
> 
> Signed-off-by: Prasant Jalan 
> ---
>  drivers/staging/vt6656/rf.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)

Didn't you just send this same patch?  If this is a 'v2' patch, please
read Documentation/SubmittingPatches for how to properly do that (hint,
you need more info here...)

thanks,

greg k-h

Re: [PATCH] checkpatch: Flag spam header (X-Spam-Report) to prevent spurious warnings

[Joe Perches]

On Tue, 2017-03-21 at 09:30 -0700, John 'Warthog9' Hawley (VMware) wrote:
> Spamassassin sticks a long (~79 character) long string after a
> line that has a single space in it. The line with space causes
> checkpatch to erroniously think that it's in the content body, as
> opposed to headers and thus flag a mail header as an unwrapped long
> comment line.

If the spammassassin header is like

email-header-n: foo
email-header-m: bar
 
X-Spam-Report: bar

Does that form follow rfc 5322?

If it does then any email header could have that
form and the header wrapping test should be
updated from

if ($in_header_lines && $realfile =~ /^$/ &&
!($rawline =~ /^\s+\S/ ||
  $rawline =~ /^(commit\b|from\b|[\w-]+:).*$/i)) {
$in_header_lines = 0;
$in_commit_log = 1;
$has_commit_log = 1;
}

to something like

if ($in_header_lines && $realfile =~ /^$/ &&
!($rawline =~ /^ (?:\s*\S|$)/ ||
  $rawline =~ /^(commit\b|from\b|[\w-]+:).*$/i)) {

Re: [PATCH v2] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

[Calvin Owens]

On 03/21/2017 04:39 AM, Brian Foster wrote:

On Sun, Mar 19, 2017 at 09:54:51PM -0700, Calvin Owens wrote:

When punching past EOF on XFS, fallocate(mode=PUNCH_HOLE|KEEP_SIZE) will
round the file size up to the nearest multiple of PAGE_SIZE:

  calvinow@vm-disks/generic-xfs-1 ~$ dd if=/dev/urandom of=test bs=2048 count=1
  calvinow@vm-disks/generic-xfs-1 ~$ stat test
Size: 2048Blocks: 8  IO Block: 4096   regular file
  calvinow@vm-disks/generic-xfs-1 ~$ fallocate -n -l 2048 -o 2048 -p test
  calvinow@vm-disks/generic-xfs-1 ~$ stat test
Size: 4096Blocks: 8  IO Block: 4096   regular file

Commit 3c2bdc912a1cc050 ("xfs: kill xfs_zero_remaining_bytes") replaced
xfs_zero_remaining_bytes() with calls to iomap helpers. The new helpers
don't enforce that [pos,offset) lies strictly on [0,i_size) when being
called from xfs_free_file_space(), so by "leaking" these ranges into
xfs_zero_range() we get this buggy behavior.

Fix this by reintroducing the checks xfs_zero_remaining_bytes() did
against i_size at the bottom of xfs_free_file_space().

Reported-by: Aaron Gao 
Fixes: 3c2bdc912a1cc050 ("xfs: kill xfs_zero_remaining_bytes")
Cc: Christoph Hellwig 
Cc:  # 4.8+
Signed-off-by: Calvin Owens 
---
 fs/xfs/xfs_bmap_util.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index 8b75dce..0796ebc 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -1309,6 +1309,17 @@ xfs_free_file_space(
}

/*
+* Avoid doing I/O beyond eof - it's not necessary
+* since nothing can read beyond eof.  The space will
+* be zeroed when the file is extended anyway.
+*/


I'd suggest to update the comment below with this information and move
the following bits down below it as well.


Will do.


+   if (offset >= XFS_ISIZE(ip))
+   return 0;
+
+   if ((offset + len) >= XFS_ISIZE(ip))
+   len = XFS_ISIZE(ip) - offset - 1;
+


This looks like an off-by-one. Do you mean the following?

if (offset + len > XFS_ISIZE(ip))
len = XFS_ISIZE(ip) - offset;


It's not an off-by-one (it's self-consistent), but your way makes more
sense, I'll fix it ;)

Thanks,
Calvin


Brian


+   /*
 * Now that we've unmap all full blocks we'll have to zero out any
 * partial block at the beginning and/or end.  xfs_zero_range is
 * smart enough to skip any holes, including those we just created.
--
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

[James Morse]

Hi Christoffer,

On 21/03/17 11:34, Christoffer Dall wrote:
> On Tue, Mar 21, 2017 at 02:32:29PM +0800, gengdongjiu wrote:
>> On 2017/3/20 23:08, James Morse wrote:
>> On 20/03/17 07:55, Dongjiu Geng wrote:
>>> In the RAS implementation, hardware pass the virtual SEI
>>> syndrome information through the VSESR_EL2, so set the virtual
>>> SEI syndrome using physical SEI syndrome el2_elr to pass to
>>> the guest OS
>>>
>>> How does this work with firmware first?
>>
>> I explained it in previous mail about the work flow.
> 
> When delivering and reporting SEIs to the VM, should this happen
> directly to the OS running in the VM, or to the guest firmware (e.g.
> UEFI) running in the VM as well?

'firmware first' is the ACPI specs name for x86's BIOS or management-mode
handling the error. On arm64 we have multiple things called firmware, so the
name might be more confusing than helpful.

As far as I understand it, firmware here refers to the secure-world and EL3.
Something like ATF can use SCR_EL3.EA to claim SErrors and external aborts,
routing them to EL3 where secure platform specific firmware generates CPER 
records.
For a guest, Qemu takes the role of this EL3-firmware.



Thanks,

James

[PATCH 2/2] xen,input: repair xen-kbdfront resolution setting via xenstore

[Juergen Gross]

Setting the pointing device resolution via Xenstore isn't working
reliably: in case XenbusStateInitWait has been missed the resolution
settings won't be read. Correct this.

Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross 
---
 drivers/input/misc/xen-kbdfront.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 2df5678..7585fa4 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -312,11 +312,27 @@ static void xenkbd_disconnect_backend(struct xenkbd_info 
*info)
info->gref = -1;
 }
 
+static void xenkbd_set_connected(struct xenbus_device *dev)
+{
+   struct xenkbd_info *info = dev_get_drvdata(>dev);
+   int ret;
+
+   if (xenbus_read_unsigned(info->xbdev->otherend,
+"feature-abs-pointer", 0)) {
+   ret = xenbus_write(XBT_NIL, info->xbdev->nodename,
+  "request-abs-pointer", "1");
+   if (ret)
+   pr_warn("xenkbd: can't request abs-pointer");
+   }
+
+   xenbus_switch_state(dev, XenbusStateConnected);
+}
+
 static void xenkbd_backend_changed(struct xenbus_device *dev,
   enum xenbus_state backend_state)
 {
struct xenkbd_info *info = dev_get_drvdata(>dev);
-   int ret, val;
+   int val;
 
switch (backend_state) {
case XenbusStateInitialising:
@@ -327,16 +343,7 @@ static void xenkbd_backend_changed(struct xenbus_device 
*dev,
break;
 
case XenbusStateInitWait:
-InitWait:
-   if (xenbus_read_unsigned(info->xbdev->otherend,
-"feature-abs-pointer", 0)) {
-   ret = xenbus_write(XBT_NIL, info->xbdev->nodename,
-  "request-abs-pointer", "1");
-   if (ret)
-   pr_warning("xenkbd: can't request abs-pointer");
-   }
-
-   xenbus_switch_state(dev, XenbusStateConnected);
+   xenkbd_set_connected(dev);
break;
 
case XenbusStateConnected:
@@ -346,7 +353,8 @@ static void xenkbd_backend_changed(struct xenbus_device 
*dev,
 * get Connected twice here.
 */
if (dev->state != XenbusStateConnected)
-   goto InitWait; /* no InitWait seen yet, fudge it */
+   /* No InitWait seen yet, fudge it. */
+   xenkbd_set_connected(dev);
 
/* Set input abs params to match backend screen res */
if (xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-- 
2.10.2

Re: [PATCH v6 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

[Mark Rutland]

On Fri, Mar 10, 2017 at 01:28:45AM -0500, Anurup M wrote:
> Add hrtimer support which use poll method to avoid counter overflow
> when overflow IRQ is not supported in hardware.
> The L3 cache PMU use N-N SPI interrupt which has no support in kernel
> mainline. So use hrtimer to poll and update event counter to avoid
> overflow condition for L3 cache PMU.
> An interval of 10 seconds is used for the hrtimer.

This should be folded with the previous patch, given that it is
necessary for counters to work correctly.

[...]

> +/*
> + * Default timer frequency to poll and avoid counter overflow.
> + * CPU speed = 2.4Ghz, Therefore Access time = 0.4ns
> + * L1 cache - 2 way set associative
> + * L2  - 16 way set associative
> + * L3  - 16 way set associative. L3 cache has 4 banks.
> + *
> + * Overflow time = 2^31 * (access time L1 + access time L2 + access time L3)
> + * = 2^31 * ((2 * 0.4ns) + (16 * 0.4ns) + (4 * 16 * 0.4ns)) = 70 seconds
> + *
> + * L3 cache is also used by devices like PCIe, SAS etc. at
> + * the same time. So the overflow time could be even smaller.
> + * So on a safe side we use a timer interval of 10sec
> + */
> +#define L3C_HRTIMER_INTERVAL (10LL * MSEC_PER_SEC)

This sounds fine.

[...]

> +/*
> + * sysfs hrtimer_interval attributes
> + */
> +ssize_t hisi_hrtimer_interval_sysfs_show(struct device *dev,
> +  struct device_attribute *attr,
> +  char *buf)
> +{
> + struct pmu *pmu = dev_get_drvdata(dev);
> + struct hisi_pmu *hisi_pmu = to_hisi_pmu(pmu);
> +
> + if (hisi_pmu->hrt_duration)
> + return sprintf(buf, "%llu\n", hisi_pmu->hrt_duration);
> + return 0;
> +}

I don't think that we need a sysfs property for this.

[...]

> +/* The counter overflow IRQ is not supported for some PMUs
> + * use hrtimer to periodically poll and avoid overflow
> + */
> +static enum hrtimer_restart hisi_hrtimer_callback(struct hrtimer *hrtimer)
> +{
> + struct hisi_pmu *hisi_pmu = container_of(hrtimer,
> +  struct hisi_pmu, hrtimer);
> + struct perf_event *event;
> + struct hw_perf_event *hwc;
> + unsigned long flags;
> +
> + /* Return if no active events */
> + if (!hisi_pmu->num_active)
> + return HRTIMER_NORESTART;
> +
> + local_irq_save(flags);
> +
> + /* Update event count for each active event */
> + list_for_each_entry(event, _pmu->active_list, active_entry) {
> + hwc = >hw;
> + /* Read hardware counter and update the Perf event counter */
> + hisi_pmu->ops->event_update(event, hwc, GET_CNTR_IDX(hwc));
> + }

How do we ensure that we don't take the interrupt in the middle of a
sequence of accesses to the HW?

Thanks,
Mark.

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

[Cyrill Gorcunov]

On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote:
...
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index d6b784a5520d..d3d4d9abcaf8 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -519,8 +519,14 @@ void set_personality_ia32(bool x32)
>   if (current->mm)
>   current->mm->context.ia32_compat = TIF_X32;
>   current->personality &= ~READ_IMPLIES_EXEC;
> - /* in_compat_syscall() uses the presence of the x32
> -syscall bit flag to determine compat status */
> + /*
> +  * in_compat_syscall() uses the presence of the x32
> +  * syscall bit flag to determine compat status.
> +  * On the bitness of syscall relies x86 mmap() code,
> +  * so set x32 syscall bit right here to make
> +  * in_compat_syscall() work during exec().
> +  */
> + task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
>   current->thread.status &= ~TS_COMPAT;

Hi! I must admit I didn't follow close the overall series (so can't
comment much here :) but I have a slightly unrelated question -- is
there a way to figure out if task is running in x32 mode say with
some ptrace or procfs sign?

Re: [Outreachy kernel] [PATCH 0/2] IIO coding tasks

[Alison Schofield]

On Tue, Mar 21, 2017 at 10:52:46PM +0530, Arushi Singhal wrote:
> On Tue, Mar 21, 2017 at 10:32 PM, Alison Schofield 
> wrote:
> 
> > On Tue, Mar 21, 2017 at 05:39:38PM +0100, Julia Lawall wrote:
> > >
> > >
> > > On Tue, 21 Mar 2017, Arushi Singhal wrote:
> > >
> > > > On Tue, Mar 21, 2017 at 9:33 PM, Alison Schofield <
> > amsfiel...@gmail.com>
> > > > wrote:
> > > >   On Tue, Mar 21, 2017 at 07:00:17PM +0530, Arushi Singhal wrote:
> > > >   > Patchseries of IIO coding tasks
> > > >
> > > >   This wouldn't be a patchset.  Although they touch the same
> > > >   driver, the changes are unrelated.  See more below...
> > > >
> > > > This I have send as a Patchset because as you have mentioned below
> > that the
> > > > [PATCH 2/2] was already done before by someone but I think so it is
> > not yet
> > > > applied in the Greg's tree yet.So I have done both the changes and as
> > they
> > > > should be applied one after other so that's why I have send them as
> > > > Patchset.
> > >
> > > For the IIO patches, it is better to work on the IIO tree, not Greg's.
> > > Greg manages staging, not IIO.  The IIO patches should appear in Greg's
> > > tree eventually.
> > >
> > > julia
> >
> > We didn't direct applicants to create an iio tree.  At this point,
> > it seems more than is necessary.  They can follow the directions in the
> > task descriptions and avoid the collisions.
> >
> > Of course, they are welcome to create a tree to iio/testing.
> >
> > (IMHO it's more overhead/busy work and maybe not the best use
> > of time in the home stretch of the application period.)
> >
> > alisons
> >
> 
> Hi Alison
> As you have mentioned that my [PATCH 2/2] is already being done someone. So
> how can I make the changes of [PATCH 1/2] on top of it as [PATCH 2/2] is
> not yet applied on the staging tree.
> Please suggest me.
> Thanks
> Arushi

Arushi - 
I don't see anything needing to be done by you!
Your ad7759 mlock patch is awaiting review.  It's not your issue
to keep up with all changes going into the file.  When it gets applied 
will most likely merge with no merge issue at all. 
alisons
> 
> > >
> > > >   >
> > > >   > Arushi Singhal (2):
> > > >   >   staging: ad7759: Replace mlock with driver private lock
> > > >
> > > >   This one is already been submitted.  If you have a v2 for it,
> > > >   then v2
> > > >   the original patch.
> > > >
> > > > Is it submitted by me only before? And this is not the v2.
> > > > I have just resed it.
> > > >   >   staging: iio: ade7759: Move header content to implementation
> > > >   file
> > > >
> > > >   This patch is done and applied already.  See the Coding Task #1
> > > >   notes
> > > >   in the IIO Tasks page.
> > > >
> > > > Not at applied I think so.
> > > > Thanks
> > > > Arushi
> > > >
> > > >   alisons
> > > >
> > > >   >
> > > >   >  drivers/staging/iio/meter/ade7759.c   | 56
> > > >   +--
> > > >   >  drivers/staging/iio/meter/ade7759.h   | 53
> > > >   -
> > > >   >  2 files changed, 54 insertions(+), 57 deletions(-)
> > > >   >
> > > >   > --
> > > >   > 2.11.0
> > > >   >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > Groups "outreachy-kernel" group.
> > > > > To unsubscribe from this group and stop receiving emails from it,
> > > > send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > > > To post to this group, send email to
> > > > outreachy-ker...@googlegroups.com.
> > > > > To view this discussion on the web visithttps://groups.google.
> > com/d/msgid/outreachy-kernel/20170321133021.6737-1-ar
> > > > ushisinghal19971997%40gmail.com.
> > > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "outreachy-kernel" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > an
> > > > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > > > To post to this group, send email to outreachy-ker...@googlegroups.com
> > .
> > > > To view this discussion on the web visithttps://groups.google.
> > com/d/msgid/outreachy-kernel/CA%2BXqjF9dVy33Dsv0H2z8x
> > > > taNeMOW7SQgr4qa4wLwz6xFNVTsUA%40mail.gmail.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > > >
> > > >
> >
> >

Re: 4.11rc3 unwinder spew.

[Josh Poimboeuf]

On Mon, Mar 20, 2017 at 06:13:25PM -0400, Dave Jones wrote:
> I just got this while running a backup..
> 
>   Dave
> 
> WARNING: kernel stack frame pointer at c9fe7ff0 in rsync:1157 has bad 
> value   (null)
> unwind stack type:0 next_sp:  (null) mask:2 graph_idx:0
> c9fe7f98: c9fe7ff0 (0xc9fe7ff0)
> c9fe7fa0: b7000f56 (trace_hardirqs_off_thunk+0x1a/0x1c)
> c9fe7fa8: 0246 (0x246)
> c9fe7fb0:  ...
> c9fe7fc0: 7ffe3af639bc (0x7ffe3af639bc)
> c9fe7fc8: 0006 (0x6)
> c9fe7fd0: 7f80af433fc5 (0x7f80af433fc5)
> c9fe7fd8: 7ffe3af638e0 (0x7ffe3af638e0)
> c9fe7fe0: 7ffe3af638e0 (0x7ffe3af638e0)
> c9fe7fe8: 7ffe3af63970 (0x7ffe3af63970)
> c9fe7ff0:  ...
> c9fe7ff8: b7b74b9a (entry_SYSCALL_64_after_swapgs+0x17/0x4f)

Thanks, this is a known issue with the unwinder getting confused about
interrupts hitting in early entry code.  I'm working on a patch to fix
it.

-- 
Josh

[PATCH v1] Revert "extcon: usb-gpio: add support for ACPI gpio interface"

[Andy Shevchenko]

The commit 942c7924a51e introduced a check for ACPI handle for the
device that never appears on any ACPI-enabled platform so far. It seems
a confusion with extcon-intel-int3496 which does support ACPI-enabled
platforms.

Revert commit 942c7924a51e to avoid any confusion in the future.

Cc: Lu Baolu 
Signed-off-by: Andy Shevchenko 
---
 drivers/extcon/extcon-usb-gpio.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index d47573a31e17..9c925b05b7aa 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define USB_GPIO_DEBOUNCE_MS   20  /* ms */
@@ -111,7 +110,7 @@ static int usb_extcon_probe(struct platform_device *pdev)
struct usb_extcon_info *info;
int ret;
 
-   if (!np && !ACPI_HANDLE(dev))
+   if (!np)
return -EINVAL;
 
info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
-- 
2.11.0

Re: Question: Linux changes required for off control board RTC

[Alexandre Belloni]

Hi,

On 21/03/2017 at 13:08:54 -0500, Tracy Smith wrote:
> Hi, not sure if this is the correct venue to post a question, so
> please forgive and direct me to the correct board or list if not.
> 

Lee is probably not the one to ask :)

> A custom board implementation using a ARM-8 Cortex A53 NXP LS1043ardb
> is considering moving the RTC from the control board to an FPGA.
> Reason is for accuracy of time/date and efficiency for their FPGA/DSP
> application.
> 
> 1) What kernel changes would be required to support such an
> implementation and these would need to be pushed to the community
> under the GPL?
> 

You'll have to write a proper driver. It will have to be licensed under
the GPLv2 but you don't necessarily have to push it anywhere (that is
not how the GPL is working).

> 2) Is it a trivial task to make such changes in the kernel to support
> an RTC not located on the control board/SoC itself?
> 

RTC drivers are not so complicated. I'd say that the difficulty mainly
depends on how the SoC can access the FPGA.


> 3) What is the expected behavior of the kernel with no changes added
> to accommodate such an architecture?
> 

The kernel will work, the RTC is not required.

> 4) Is there a configurable kernel option to allow for such a change,
> or have these or similar changes already been added to the kernel?
> 

More details are needed to answer that but basically if your FPGa
emulates an RTC that is already supported, you don't need to write
much.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH] drivers: staging: vt6656: fxed coding style errors

[Greg KH]

On Tue, Mar 21, 2017 at 10:25:40PM +0530, Prasant Jalan wrote:
> This patch replaces spaces with tabs for indentation as per kernel
> coding standards.
> 
> Signed-off-by: Prasant Jalan 
> ---
>  drivers/staging/vt6656/rf.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/vt6656/rf.c b/drivers/staging/vt6656/rf.c
> index 068c1c8..f69bced 100644
> --- a/drivers/staging/vt6656/rf.c
> +++ b/drivers/staging/vt6656/rf.c
> @@ -876,7 +876,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
>   memcpy(array, addr1, length1);
>  
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE, 0,
> - MESSAGE_REQUEST_RF_INIT, length1, array);
> + MESSAGE_REQUEST_RF_INIT, length1, array);
>  
>   /* Channel Table 0 */
>   value = 0;
> @@ -889,7 +889,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
>   memcpy(array, addr2, length);
>  
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE,
> - value, MESSAGE_REQUEST_RF_CH0, length, array);
> + value, MESSAGE_REQUEST_RF_CH0, length, array);
>  
>   length2 -= length;
>   value += length;
> @@ -907,7 +907,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
>   memcpy(array, addr3, length);
>  
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE,
> - value, MESSAGE_REQUEST_RF_CH1, length, array);
> + value, MESSAGE_REQUEST_RF_CH1, length, array);
>  
>   length3 -= length;
>   value += length;
> @@ -924,7 +924,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
>  
>   /* Init Table 2 */
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE,
> - 0, MESSAGE_REQUEST_RF_INIT2, length1, array);
> + 0, MESSAGE_REQUEST_RF_INIT2, length1, array);
>  
>   /* Channel Table 0 */
>   value = 0;
> @@ -937,7 +937,7 @@ void vnt_rf_table_download(struct vnt_private *priv)
>   memcpy(array, addr2, length);
>  
>   vnt_control_out(priv, MESSAGE_TYPE_WRITE,
> - value, MESSAGE_REQUEST_RF_CH2, length, 
> array);
> + value, MESSAGE_REQUEST_RF_CH2, length, array);

Why make this last change?  It's now not indented properly :(

thanks,

greg k-h

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

[Michael S. Tsirkin]

On Tue, Mar 21, 2017 at 05:16:32PM +0100, Joerg Roedel wrote:
> On Wed, Mar 15, 2017 at 11:22:18PM +0200, Michael S. Tsirkin wrote:
> > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> > index d1efe2c..18e53bc 100644
> > --- a/arch/x86/kvm/svm.c
> > +++ b/arch/x86/kvm/svm.c
> > @@ -1198,8 +1198,6 @@ static void init_vmcb(struct vcpu_svm *svm)
> > set_intercept(svm, INTERCEPT_CLGI);
> > set_intercept(svm, INTERCEPT_SKINIT);
> > set_intercept(svm, INTERCEPT_WBINVD);
> > -   set_intercept(svm, INTERCEPT_MONITOR);
> > -   set_intercept(svm, INTERCEPT_MWAIT);
> 
> Why do you remove the intercepts for AMD? The new kvm_mwait_in_guest()
> function will always return false on AMD anyway,

I think that's a bug and I should fix it to return true there.

> and on Intel you re-add
> the intercepts for !kvm_mwait_in_guest().
> 
> 
>   Joerg

Does AMD need some work-around similar to CPUID5_ECX_INTERRUPT_BREAK?
That's why we have kvm_mwait_in_guest ...

-- 
MST

Re: [PATCH RT] tty: serial: st-asc: Make the locking RT aware

[Thomas Gleixner]

On Tue, 21 Mar 2017, Steven Rostedt wrote:
> > /*
> >  * Disable interrupts so we don't get the IRQ line bouncing
> 
> I'm nervous about the above comment, which in full is:
> 
>   /*
>* Disable interrupts so we don't get the IRQ line bouncing
>* up and down while interrupts are disabled.
>*/
> 
> I'm not sure if disabling interrupts helps on an SMP system. This patch
> does change what happens when port->sysrq is set. But I'm not sure we
> care.

It disables interrupts at the device level which obviously helps whether on
SMP or not.

Thanks,

tglx

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

[hpa]

On March 21, 2017 10:45:57 AM PDT, Andy Lutomirski  wrote:
>On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov 
>wrote:
>> On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote:
>> ...
>>> diff --git a/arch/x86/kernel/process_64.c
>b/arch/x86/kernel/process_64.c
>>> index d6b784a5520d..d3d4d9abcaf8 100644
>>> --- a/arch/x86/kernel/process_64.c
>>> +++ b/arch/x86/kernel/process_64.c
>>> @@ -519,8 +519,14 @@ void set_personality_ia32(bool x32)
>>>   if (current->mm)
>>>   current->mm->context.ia32_compat = TIF_X32;
>>>   current->personality &= ~READ_IMPLIES_EXEC;
>>> - /* in_compat_syscall() uses the presence of the x32
>>> -syscall bit flag to determine compat status */
>>> + /*
>>> +  * in_compat_syscall() uses the presence of the x32
>>> +  * syscall bit flag to determine compat status.
>>> +  * On the bitness of syscall relies x86 mmap() code,
>>> +  * so set x32 syscall bit right here to make
>>> +  * in_compat_syscall() work during exec().
>>> +  */
>>> + task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT;
>>>   current->thread.status &= ~TS_COMPAT;
>>
>> Hi! I must admit I didn't follow close the overall series (so can't
>> comment much here :) but I have a slightly unrelated question -- is
>> there a way to figure out if task is running in x32 mode say with
>> some ptrace or procfs sign?
>
>You should be able to figure out of a *syscall* is x32 by simply
>looking at bit 30 in the syscall number.  (This is unlike i386, which
>is currently not reflected in ptrace.)
>
>Do we actually have an x32 per-task mode at all?  If so, maybe we can
>just remove it on top of Dmitry's series.

We do, for things like signal delivery mostly.  We have tried relying on it as 
little as possible, intentionally.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [lkp-robot] [x86] 69218e4799: BUG:kernel_hang_in_boot_stage

[Thomas Garnier]

On Tue, Mar 21, 2017 at 12:20 PM, Linus Torvalds
 wrote:
>
> On Tue, Mar 21, 2017 at 11:16 AM, Thomas Garnier  wrote:
> > This error happens even with Andy TLS fix on 32-bit (GDT is on fixmap
> > but not readonly). I am looking into it.
> >
> > KVM internal error. Suberror: 3
> > extra data[0]: 8b0e
> > extra data[1]: 31
>
> If I read that right, it's extra data[1] 0x31, which 
> EXIT_REASON_EPT_MISCONFIG.
>
> I'm not seeing how the A bit in a GDT entry could have anything to do
> with it. I'm assuming it happens even without Andy's patch?

Correct.

>
>   Linus




-- 
Thomas

Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs

[Patrick Bellasi]

On 21-Mar 16:18, Peter Zijlstra wrote:
> On Tue, Mar 21, 2017 at 03:08:20PM +, Patrick Bellasi wrote:
> 
> > And than we can move this bit into an inline function, something like e.g.:
> > 
> >static inline bool sugov_this_cpu_is_busy()
> >{
> >return this_rq()->rd->overloaded
> >}
> 
> No, that's just entirely and utterly wrong. It being in rd means its
> very much not about _this_ CPU in any way.

You right (of course), we cannot really use "this_" in the name of
a function with such a code.

The suggestion here was at least to factor out whatever code we want
to use to check if the current CPU has to be subject to a down-scaling
constraint.

However, using rd->overload is not the best option, for the many reasons
you explained in your previous comment. Thus, we should probably stay
with the idle time tracking solution initially proposed by Rafael.

Sorry for the noise :-(

-- 
#include 

Patrick Bellasi

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

[Radim Krčmář]

2017-03-21 05:22+0200, Michael S. Tsirkin:
> On Fri, Mar 17, 2017 at 09:23:56AM -0400, Gabriel L. Somlo wrote:
>> OK, now on to Radim's test, on the MacPro1,1:
>> 
>> [kvm-unit-tests]$ time TIMEOUT=20 ./x86-run x86/mwait.flat -append '240 1 1'
>> timeout -k 1s --foreground 20 qemu-kvm -nodefaults -enable-kvm -device 
>> pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial 
>> stdio -device pci-testdev -kernel x86/mwait.flat -append 240 1 1
>> enabling apic
>> PASS: resumed from mwait 1 times
>> SUMMARY: 1 tests
>> 
>> real0m0.746s
>> user0m0.542s
>> sys 0m0.215s
>> [kvm-unit-tests]$ time TIMEOUT=20 ./x86-run x86/mwait.flat -append '240 1 0'
>> timeout -k 1s --foreground 20 qemu-kvm -nodefaults -enable-kvm -device 
>> pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial 
>> stdio -device pci-testdev -kernel x86/mwait.flat -append 240 1 0
>> enabling apic
>> PASS: resumed from mwait 1 times
>> SUMMARY: 1 tests
>> 
>> real0m0.743s
>> user0m0.528s
>> sys 0m0.226s
>> [kvm-unit-tests]$ time TIMEOUT=20 ./x86-run x86/mwait.flat -append '240 1 1' 
>> -smp 2
>> timeout -k 1s --foreground 20 qemu-kvm -nodefaults -enable-kvm -device 
>> pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial 
>> stdio -device pci-testdev -kernel x86/mwait.flat -append 240 1 1 -smp 2
>> enabling apic
>> enabling apic
>> FAIL: resumed from mwait 10150 times
>> SUMMARY: 1 tests, 1 unexpected failures
>> 
>> real0m0.745s
>> user0m0.545s
>> sys 0m0.214s
>> [kvm-unit-tests]$ time TIMEOUT=20 ./x86-run x86/mwait.flat -append '240 1 0' 
>> -smp 2
>> timeout -k 1s --foreground 20 qemu-kvm -nodefaults -enable-kvm -device 
>> pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial 
>> stdio -device pci-testdev -kernel x86/mwait.flat -append 240 1 0 -smp 2
>> enabling apic
>> enabling apic
>> FAIL: resumed from mwait 10116 times
>> SUMMARY: 1 tests, 1 unexpected failures
>> 
>> real0m0.744s
>> user0m0.541s
>> sys 0m0.217s
>> 
>> HTH,
>> --Gabriel
> 
> Weird. How can it go above 1? Radim - any idea?

In '-smp 2', the writing VCPU always does 1 wakeups by writing into
monitored memory, but the mwaiting VCPU can be also woken up by host
interrupts, which might add a few exits depending on timing.

I didn't spend much time in making the PASS/FAIL mean much, or ensuring
that we only get 1 wakeups ... it is nothing to be worried about.

Hint 240 behaves as nop even on my system, so I still don't find
anything insane on that machine (if OS X is exluded) ...

[PATCH v3 11/11] ARM: sun8i: sina33: add highest OPP of CPUs

[Quentin Schulz]

The A33 supports 1.1GHz and 1.2GHz frequencies at 1.32V and the Sinlinx
SinA33 has its cpu-supply property set in the cpu DT node.

Therefore, CPUfreq knows how to handle the regulator in charge of the
CPU and can adjust its voltage to match the OPP.

Add these two CPU frequencies to the CPU OPP table of the Sinlinx
SinA33.

Signed-off-by: Quentin Schulz 
---

added in v3

 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts 
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index d84f1bd..a92dee1 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -87,6 +87,20 @@
cpu-supply = <_dcdc3>;
 };
 
+_opp_table {
+   opp@110400 {
+   opp-hz = /bits/ 64 <110400>;
+   opp-microvolt = <132>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp@12 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <132>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+};
+
  {
status = "okay";
 };
-- 
2.9.3

Question: Linux changes required for off control board RTC

[Tracy Smith]

Hi, not sure if this is the correct venue to post a question, so
please forgive and direct me to the correct board or list if not.

A custom board implementation using a ARM-8 Cortex A53 NXP LS1043ardb
is considering moving the RTC from the control board to an FPGA.
Reason is for accuracy of time/date and efficiency for their FPGA/DSP
application.

1) What kernel changes would be required to support such an
implementation and these would need to be pushed to the community
under the GPL?

2) Is it a trivial task to make such changes in the kernel to support
an RTC not located on the control board/SoC itself?

3) What is the expected behavior of the kernel with no changes added
to accommodate such an architecture?

4) Is there a configurable kernel option to allow for such a change,
or have these or similar changes already been added to the kernel?

thx,
Tracy

Re: [PATCH v2 6/6] selftests: enable O and KBUILD_OUTPUT

[Shuah Khan]

On 03/21/2017 10:09 AM, Bamvor Zhang Jian wrote:
> Hi, Shuah
> 
> On 21 March 2017 at 21:54, Shuah Khan  wrote:
>> On 03/21/2017 03:00 AM, Bamvor Zhang Jian wrote:
>>> Hi,
>>>
>>> On 21 March 2017 at 16:35, Michael Ellerman  wrote:
 Andy Lutomirski  writes:

> On Tue, Nov 29, 2016 at 3:55 AM,   wrote:
>> From: Bamvor Jian Zhang 
>>
>> Enable O and KBUILD_OUTPUT for kselftest. User could compile kselftest
>> to another directory by passing O or KBUILD_OUTPUT. And O is high
>> priority than KBUILD_OUTPUT.
>
> Sorry for noticing this late, but this patch
> (a8ba798bc8ec663cf02e80b0dd770324de9bafd9) is really annoying for
> people who *don't* use these fancy options:

 Yeah sorry, it wasn't quite ready to go in.
>>
>> Bamovar,
>>
>> Please give me heads up and ask me to not commit the patch,
>> if you think it isn't ready.
>>

> $ make -C tools/testing/selftests/x86 ldt_gdt_32
> make: Entering directory 
> '/home/luto/apps/linux/tools/testing/selftests/x86'
> Makefile:44: warning: overriding recipe for target 'clean'
> ../lib.mk:55: warning: ignoring old recipe for target 'clean'
> make: *** No rule to make target 'ldt_gdt_32'.  Stop.
> make: Leaving directory 
> '/home/luto/apps/linux/tools/testing/selftests/x86'
>
> Is there any way that you can make this work again?

 There obviously is *a* way, but I'm not sure there's a simple and
 obviously correct way that is an easy fix for 4.11.

 I see at least 18 Makefile's in tools/testing/selftests that use
 $(OUTPUT)/, which would all need to be updated at least to use $(OUTPUT)
 (no trailing slash), and then some other changes to not propagate OUTPUT
 when the user didn't specify it. But hopefully someone will prove me
 wrong.
>>> I also look at this issue. Originally, I use OUTPUT without slash in my
>>> patch. People argue that it is not very clear. So, I add slash in curent
>>> version.

 As a (poor) alternative you can do:

  $ cd tools/testing/selftests/x86; make $PWD/ldt_gdt_32

 or just:

  $ make -C tools/testing/selftests/x86

 cheers
>>> Do we really need "make -C tools/testing/selftests/x86 ldt_gdt_32"?
>>> It is useful but it will skip the top level Makefile of selftests.
>>
>> Being able to build individual tests is an important use-case. Please
>> see kselftest.txt under Documentation directory for all the use-cases
>> and new patches shouldn't break these use-cases.
> Understand. I am sorry I do not know this use case before. And I read
> kselftest.txt again, I do not find this use case is mentioned. So,
> I add a few lines in kselftest.txt to avoid break this use case in future.
> Is there any other use cases I should test?

Running an individual test as in the example below should be allowed.
make -C tools/testing/selftests hotplug

Also individual tests are often run from the test director. For example,

cd tools/testing/selftests/x86; make

thanks,
-- Shuah

>>
>> Breaking these use-cases is a regression and we have to fix it
> Here is a fix. I could build individual test case in x86 and build the whole
> x86 test cases successful respectively. And I do a quick test for all the
> subsets. Please review the patch if it is make sense to you and Michael.
> At the same time, I am buildind and testing all the testcases.
> 
> Michael: could you please do me a favor to test the powerpc part? Thanks.
> 
> From 21b17710d23783c5148303e5628b52d281e6f62b Mon Sep 17 00:00:00 2001
> From: Bamvor Jian Zhang 
> Date: Tue, 21 Mar 2017 22:38:01 +0800
> Subject: [PATCH] selftests: fix the broken individual test for x86
> 
> Andy Lutomirski report that build individual testcase in x86 is broken:
> 
> $ make -C tools/testing/selftests/x86 ldt_gdt_32
> make: Entering directory '/home/luto/apps/linux/tools/testing/selftests/x86'
> Makefile:44: warning: overriding recipe for target 'clean'
> ../lib.mk:55: warning: ignoring old recipe for target 'clean'
> make: *** No rule to make target 'ldt_gdt_32'.  Stop.
> make: Leaving directory '/home/luto/apps/linux/tools/testing/selftests/x86'
> 
> This patch fix this issue by removing the slash after OUTPUT.
> And also mention this use case in Documentation/kselftests.txt
> 
> Reported-by: Andy Lutomirski 
> Suggested-by: Michael Ellerman 
> Signed-off-by: Bamvor Jian Zhang 
> ---
>  Documentation/kselftest.txt|  5 +
>  tools/testing/selftests/Makefile   | 16 
>  tools/testing/selftests/exec/Makefile  | 10 +-
>  tools/testing/selftests/ftrace/Makefile|  2 +-
>  tools/testing/selftests/futex/Makefile | 12 

run_timer_softirq gpf. tracing?

[Dave Jones]

I just hit this while fuzzing..

general protection fault:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.11.0-rc2-think+ #1 
task: 88017f0ed440 task.stack: c9094000
RIP: 0010:run_timer_softirq+0x15f/0x700
RSP: 0018:880507c03ec8 EFLAGS: 00010086
RAX: dead0200 RBX: 880507dd0d00 RCX: 0002
RDX: 880507c03ed0 RSI:  RDI: 8204b3a0
RBP: 880507c03f48 R08: 880507dd12d0 R09: 880507c03ed8
R10: 880507dd0db0 R11:  R12: 8215cc38
R13: 880507c03ed0 R14: 82005188 R15: 8804b55491a8
FS:  () GS:880507c0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0004 CR3: 05011000 CR4: 001406e0
Call Trace:
 
 ? clockevents_program_event+0x47/0x120
 __do_softirq+0xbf/0x5b1
 irq_exit+0xb5/0xc0
 smp_apic_timer_interrupt+0x3d/0x50
 apic_timer_interrupt+0x97/0xa0
RIP: 0010:cpuidle_enter_state+0x12e/0x400
RSP: 0018:c9097e40 EFLAGS: 0202
[CONT START]  ORIG_RAX: ff10
RAX: 88017f0ed440 RBX: e8a03cc8 RCX: 0001
RDX: 20c49ba5e353f7cf RSI: 0001 RDI: 88017f0ed440
RBP: c9097e80 R08:  R09: 0008
R10:  R11:  R12: 0005
R13: 820b9338 R14: 0005 R15: 820b9320
 
 cpuidle_enter+0x17/0x20
 call_cpuidle+0x23/0x40
 do_idle+0xfb/0x200
 cpu_startup_entry+0x71/0x80
 start_secondary+0x16a/0x210
 start_cpu+0x14/0x14
Code: 8b 05 ce 1b ef 7e 83 f8 03 0f 87 4e 01 00 00 89 c0 49 0f a3 04 24 0f 82 
0a 01 00 00 49 8b 07 49 8b 57 08 48 85 c0 48 89 02 74 04 <48> 89 50 08 41 f6 47 
2a 20 49 c7 47 08 00 00 00 00 48 89 df 48 


RAX looks like list poison, and CR2 = 4, which is likely the ->next of a list,
with a NULL pointer.

Here's the disassembly of timer.o
https://codemonkey.org.uk/junk/timer.o.txt

Sure enough, run_timer_softirq+0x15f (1ccf) is..


entry->next = LIST_POISON2;
1cc8:   48 b8 00 02 00 00 00movabs $0xdead0200,%rax
1ccf:   00 ad de 


This looks to be something to do with the tracing definition of timer_cancel.
I don't fully grok how the tracing macros work, is there something obvious
here before I dig deeper ?

Right before that list op, we do this..

if (timer->flags & TIMER_IRQSAFE) {

Which looks like a line from expire_timers.   I'm not following how we get there
from that tracing definition.

No tracing was active when this happened.

Dave

Re: [PATCH] fs/pstore: Perform erase from a worker

[Kees Cook]

On Mon, Mar 20, 2017 at 10:58 PM, Namhyung Kim  wrote:
> Hello,
>
> On Mon, Mar 20, 2017 at 10:49:16AM -0700, Kees Cook wrote:
>> On Fri, Mar 17, 2017 at 2:52 AM, Chris Wilson  
>> wrote:
>> > In order to prevent a cyclic recursion between psi->read_mutex and the
>> > inode_lock, we need to move the pse->erase to a worker.
>> >
>> > [  605.374955] ==
>> > [  605.381281] [ INFO: possible circular locking dependency detected ]
>> > [  605.387679] 4.11.0-rc2-CI-CI_DRM_2352+ #1 Not tainted
>> > [  605.392826] ---
>> > [  605.399196] rm/7298 is trying to acquire lock:
>> > [  605.403720]  (>read_mutex){+.+.+.}, at: [] 
>> > pstore_unlink+0x3f/0xa0
>> > [  605.412300]
>> > [  605.412300] but task is already holding lock:
>> > [  605.418237]  (>s_type->i_mutex_key#14){++}, at: 
>> > [] vfs_unlink+0x4c/0x19
>> > 0
>> > [  605.427397]
>> > [  605.427397] which lock already depends on the new lock.
>> > [  605.427397]
>> > [  605.435770]
>> > [  605.435770] the existing dependency chain (in reverse order) is:
>> > [  605.443396]
>> > [  605.443396] -> #1 (>s_type->i_mutex_key#14){++}:
>> > [  605.450347]lock_acquire+0xc9/0x220
>> > [  605.454551]down_write+0x3f/0x70
>> > [  605.458484]pstore_mkfile+0x1f4/0x460
>> > [  605.462835]pstore_get_records+0x17a/0x320
>> > [  605.467664]pstore_fill_super+0xa4/0xc0
>> > [  605.472205]mount_single+0x89/0xb0
>> > [  605.476314]pstore_mount+0x13/0x20
>> > [  605.480411]mount_fs+0xf/0x90
>> > [  605.484122]vfs_kern_mount+0x66/0x170
>> > [  605.488464]do_mount+0x190/0xd50
>> > [  605.492397]SyS_mount+0x90/0xd0
>> > [  605.496212]entry_SYSCALL_64_fastpath+0x1c/0xb1
>> > [  605.501496]
>> > [  605.501496] -> #0 (>read_mutex){+.+.+.}:
>> > [  605.507747]__lock_acquire+0x1ac0/0x1bb0
>> > [  605.512401]lock_acquire+0xc9/0x220
>> > [  605.516594]__mutex_lock+0x6e/0x990
>> > [  605.520755]mutex_lock_nested+0x16/0x20
>> > [  605.525279]pstore_unlink+0x3f/0xa0
>> > [  605.529465]vfs_unlink+0xb5/0x190
>> > [  605.533477]do_unlinkat+0x24c/0x2a0
>> > [  605.537672]SyS_unlinkat+0x16/0x30
>> > [  605.541781]entry_SYSCALL_64_fastpath+0x1c/0xb1
>>
>> If I'm reading this right it's a race between mount and unlink...
>> that's quite a corner case. :)
>>
>> > [  605.547067]
>> > [  605.547067] other info that might help us debug this:
>> > [  605.547067]
>> > [  605.555221]  Possible unsafe locking scenario:
>> > [  605.555221]
>> > [  605.561280]CPU0CPU1
>> > [  605.565883]
>> > [  605.570502]   lock(>s_type->i_mutex_key#14);
>> > [  605.575217]lock(>read_mutex);
>> > [  605.581803]
>> > lock(>s_type->i_mutex_key#14);
>> > [  605.589159]   lock(>read_mutex);
>>
>> I haven't had time to dig much yet, but I wonder if the locking order
>> on unlink could just be reversed, and the deadlock would go away?
>
> IIUC, the unlink path locks a file in the root directory, while the
> mount path locks the root directory.  Maybe we can use a subclass?
> (not tested)
>
> Thanks,
> Namhyung
>
>
> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
> index 06504b69575b..6eea6bcf90c8 100644
> --- a/fs/pstore/inode.c
> +++ b/fs/pstore/inode.c
> @@ -394,7 +394,7 @@ int pstore_mkfile(struct pstore_record *record)
> break;
> }
>
> -   inode_lock(d_inode(root));
> +   inode_lock_nested(d_inode(root), I_MUTEX_PARENT);
>
> dentry = d_alloc_name(root, name);
> if (!dentry)

No luck, unfortunately...

In looking at other examples, I don't think the inode_lock is needed
at all? I see other uses of d_alloc_name() and d_add() without an
inode lock (proc, libfs, etc), and the locking documentation doesn't
seem to imply it either? This solves the lockdep, though it's unclear
to me if it is somehow unsafe (apologies for whitespace damage...):


diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 06504b69575b..3d83b13d2338 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -394,11 +394,9 @@ int pstore_mkfile(struct pstore_record *record)
break;
}

-   inode_lock(d_inode(root));
-
dentry = d_alloc_name(root, name);
if (!dentry)
-   goto fail_lockedalloc;
+   goto fail_private;

inode->i_size = private->total_size = size;

@@ -413,16 +411,12 @@ int pstore_mkfile(struct pstore_record *record)
list_add(>list, );
spin_unlock_irqrestore(_lock, flags);

-   inode_unlock(d_inode(root));
-
return 0;

-fail_lockedalloc:
-   inode_unlock(d_inode(root));
+fail_private:
free_pstore_private(private);
 fail_alloc:

Re: [Outreachy kernel] [PATCH v6] staging: Use buf_lock instead of mlock and Refactor code

[SIMRAN SINGHAL]

On Tue, Mar 21, 2017 at 10:18 PM, Alison Schofield  wrote:
> On Mon, Mar 20, 2017 at 01:36:21AM +0530, simran singhal wrote:
>
> Hi Simran,
>
> I going to ask for a v7 without looking at the code ;)
> Subject line needs subsystem and driver.
> Subject and log message can be improved.
>
>> The IIO subsystem is redefining iio_dev->mlock to be used by
>> the IIO core only for protecting device operating mode changes.
>> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.
>>
>> In this driver, mlock was being used to protect hardware state
>> changes. Replace it with buf_lock in the devices global data.
>^^^ this was not done
>>
>> As buf_lock protects both the adis16060_spi_write() and
>> adis16060_spi_read() functions and both are always called in
>> pair. First write, then read. Thus, refactor the code to have
>> one single function adis16060_spi_write_than_read() which is
>> protected by the existing buf_lock.
> This was done.  So, you were able to obsolete the need for mlock
> by creating the paired function.

I am still using mlock but now locking it and performing both write and
read and than unlocking.

So, now have a single safe function.

>
>>
>> Removed nested locks as the function adis16060_read_raw call
>> a lock on >buf_lock and then calls the function
>> adis16060_spi_write which again tries to get hold
>> of the same lock.
>  this was not done.  Yes, you avoided nested locks through
> proper coding, but we don't want to give the impression in the
> log message that there was a pre-existing nested lock issue.
>
> I did checkpatch & compile it...but looked no further yet.
>
> alisons
>>
>> Signed-off-by: simran singhal 
>> ---
>>
>>  v6:
>>-Change commit message
>>-Remove nested lock
>>
>>  drivers/staging/iio/gyro/adis16060_core.c | 40 
>> ++-
>>  1 file changed, 13 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
>> b/drivers/staging/iio/gyro/adis16060_core.c
>> index c9d46e7..1c6de46 100644
>> --- a/drivers/staging/iio/gyro/adis16060_core.c
>> +++ b/drivers/staging/iio/gyro/adis16060_core.c
>> @@ -40,25 +40,17 @@ struct adis16060_state {
>>
>>  static struct iio_dev *adis16060_iio_dev;
>>
>> -static int adis16060_spi_write(struct iio_dev *indio_dev, u8 val)
>> +static int adis16060_spi_write_than_read(struct iio_dev *indio_dev,
>> +  u8 conf, u16 *val)
>>  {
>>   int ret;
>>   struct adis16060_state *st = iio_priv(indio_dev);
>>
>> - mutex_lock(>buf_lock);
>> - st->buf[2] = val; /* The last 8 bits clocked in are latched */
>> + st->buf[2] = conf; /* The last 8 bits clocked in are latched */
>>   ret = spi_write(st->us_w, st->buf, 3);
>> - mutex_unlock(>buf_lock);
>> -
>> - return ret;
>> -}
>> -
>> -static int adis16060_spi_read(struct iio_dev *indio_dev, u16 *val)
>> -{
>> - int ret;
>> - struct adis16060_state *st = iio_priv(indio_dev);
>>
>> - mutex_lock(>buf_lock);
>> + if (ret < 0)
>> + return ret;
>>
>>   ret = spi_read(st->us_r, st->buf, 3);
>>
>> @@ -69,8 +61,8 @@ static int adis16060_spi_read(struct iio_dev *indio_dev, 
>> u16 *val)
>>*/
>>   if (!ret)
>>   *val = ((st->buf[0] & 0x3) << 12) |
>> - (st->buf[1] << 4) |
>> - ((st->buf[2] >> 4) & 0xF);
>> +  (st->buf[1] << 4) |
>> +  ((st->buf[2] >> 4) & 0xF);
>>   mutex_unlock(>buf_lock);
>>
>>   return ret;
>> @@ -83,20 +75,18 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>>  {
>>   u16 tval = 0;
>>   int ret;
>> + struct adis16060_state *st = iio_priv(indio_dev);
>>
>>   switch (mask) {
>>   case IIO_CHAN_INFO_RAW:
>>   /* Take the iio_dev status lock */
>> - mutex_lock(_dev->mlock);
>> - ret = adis16060_spi_write(indio_dev, chan->address);
>> + mutex_lock(>buf_lock);
>> + ret = adis16060_spi_write_than_read(indio_dev,
>> + chan->address, );
>> + mutex_unlock(>buf_lock);
>>   if (ret < 0)
>> - goto out_unlock;
>> + return ret;
>>
>> - ret = adis16060_spi_read(indio_dev, );
>> - if (ret < 0)
>> - goto out_unlock;
>> -
>> - mutex_unlock(_dev->mlock);
>>   *val = tval;
>>   return IIO_VAL_INT;
>>   case IIO_CHAN_INFO_OFFSET:
>> @@ -110,10 +100,6 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
>>   }
>>
>>   return -EINVAL;
>> -
>> -out_unlock:
>> - mutex_unlock(_dev->mlock);
>> - return ret;
>>  }
>>
>>  static const struct iio_info adis16060_info = {
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> 

Re: [PATCH] Staging: ks7010 - fixed style block comments

[Derek Robson]

On Tue, Mar 21, 2017 at 08:56:25AM +0100, Greg KH wrote:
> On Sun, Mar 19, 2017 at 01:07:17PM +1300, Derek Robson wrote:
> > Fixed style of all block comments across whole driver
> > Found by checkpatch
> > 
> > Signed-off-by: Derek Robson 
> > ---
> >  drivers/staging/ks7010/ks7010_sdio.c |  3 ++-
> >  drivers/staging/ks7010/ks_hostif.h   | 35 +-
> >  drivers/staging/ks7010/ks_wlan.h |  3 ++-
> >  drivers/staging/ks7010/ks_wlan_net.c | 41 
> > +++-
> >  4 files changed, 55 insertions(+), 27 deletions(-)
> 
> This patch doesn't apply to my tree at all :(
>

Am I working from the right/best tree for driver/staging?

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git

Thanks for helping the new guy :-)



 

Re: [PATCH 4/4] perf annotate: More exactly grep -v of the objdump command

[Arnaldo Carvalho de Melo]

Em Tue, Mar 21, 2017 at 03:29:50PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Mar 22, 2017 at 01:19:49AM +0900, Taeung Song escreveu:
> > On 03/21/2017 11:37 PM, Arnaldo Carvalho de Melo wrote:
> > > > +++ b/tools/perf/util/annotate.c
> > > > @@ -1443,7 +1443,7 @@ int symbol__disassemble(struct symbol *sym, 
> > > > struct map *map, const char *arch_na
> > > > snprintf(command, sizeof(command),
> > > >  "%s %s%s --start-address=0x%016" PRIx64
> > > >  " --stop-address=0x%016" PRIx64
> > > > -" -l -d %s %s -C %s 2>/dev/null|grep -v %s|expand",
> > > > +" -l -d %s %s -C %s 2>/dev/null|grep -v %s: |expand",
> 
> > > Are you sure this works as you expect? I.e. both lines will have '%s:'
>  
> > Yes, if we do, we can exactly the only below line without the side effect
> > IMHO.
> 
> yeah, because the .c is not there, ok gotcha, will get your new commit
> log message, massage it a bit and apply the patch.

Nah, with all this in mind, the original message is good enough, sorry
for the confusion with the .c and the space after ':' (that I removed,
needless and potentially confusing, as we saw here).

- Arnaldo

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

[hpa]

On March 21, 2017 11:40:58 AM PDT, Cyrill Gorcunov  wrote:
>On Tue, Mar 21, 2017 at 09:09:40PM +0300, Dmitry Safonov wrote:
>> 
>> I guess the question comes from that we're releasing CRIU 3.0 with
>> 32-bit C/R and some other cool stuff, but we don't support x32 yet.
>> As we don't want release a thing that we aren't properly testing.
>> So for a while we should error on dumping x32 applications.
>
>yes
>
>> I think, the best way for now is to check physicall address of vdso
>> from /proc/.../pagemap. If it's CONFIG_VDSO=n kernel, I guess we
>could
>> also add check for %ds from ptrace's register set. For x32 it's set
>to
>> __USER_DS, while for native it's 0 (looking at start_thread() and
>> compat_start_thread()). The application can simply change it without
>> any consequence - so it's not very reliable, we could only warn at
>> catching it, not rely on this.
>
>indeed, thanks!

I proposed to the ptrace people a virtual register for this and a few other 
things, but it got bikeshed to death.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH 7/7] Change k_clock nsleep() to use timespec64

[Deepa Dinamani]

>> index f608941..97a883a 100644
>> --- a/include/linux/posix-timers.h
>> +++ b/include/linux/posix-timers.h
>> @@ -94,7 +94,7 @@ struct k_clock {
>> int (*clock_adj) (const clockid_t which_clock, struct timex *tx);
>> int (*timer_create) (struct k_itimer *timer);
>> int (*nsleep) (const clockid_t which_clock, int flags,
>> -  struct timespec *, struct timespec __user *);
>> +  struct timespec64 *, struct timespec __user *);
>> long (*nsleep_restart) (struct restart_block *restart_block);
>
> You change one of the two arguments, but not the second one
> or the code in the restart handler that uses that __user pointer.
>
> Your patch is a good step in the right direction, and the second half
> of it is definitely complicated enough to be done in a separate
> patch, so I think it's good to keep them separate, just add
> explain why this is done one at a time.

Yes, this is intentional.
I was including the restart_block param in the syscall interfaces category.

I will make an explicit note in the commit text.

Thanks,
Deepa

Re: Eric Anholt offically announces support of VC4 without access to expander on the RPI 3

[Michael Zoran]

On Tue, 2017-03-21 at 10:34 -0700, Eric Anholt wrote:
> Michael Zoran  writes:
> 
> > On Mon, 2017-03-20 at 10:22 -0700, Eric Anholt wrote:
> > > Michael Zoran  writes:
> > > 
> > > > > > Since the API is completely documented, I see no reason we
> > > > > > or
> > > > > > anybody
> > > > > > couldn't essentially rewrite the driver while it's in
> > > > > > staging.  I
> > > > > > just
> > > > > > think it would be best for everyone if the new version was
> > > > > > a
> > > > > > drop
> > > > > > in
> > > > > > replacement for the original version.  Essential an
> > > > > > enhancement
> > > > > > rather
> > > > > > then a competitor.
> > > > > 
> > > > > I think my comments weren't fundamental changes, but you
> > > > > surely
> > > > > mean
> > > > > the devicetree ABI? I like to see this driver ASAP out of
> > > > > staging
> > > > > and
> > > > > i'm not interested to maintain 2 functional identical driver
> > > > > only
> > > > > to
> > > > > keep compability with the Foundation tree. Currently i'm
> > > > > afraid
> > > > > that
> > > > > we build up many drivers in staging, which need a complete
> > > > > rewrite
> > > > > later if they should come out of staging. It would be nice if
> > > > > we
> > > > > could avoid the situation we have with the thermal driver.
> > > > > 
> > > > > Stefan
> > > > 
> > > > The API I'm talking about here is the mailbox API that is used
> > > > to
> > > > talk
> > > > to the firmware.  The numbers and structures to pass are
> > > > documented. 
> > > > Nothing prevents anybody from rewriting this driver and
> > > > submitting
> > > > it
> > > > to the appropriate subsystems.  It's certainly small enough.
> > > > 
> > > > If you really want working thermal or cpu speed drivers today,
> > > > nothing
> > > > stops anybody from submitting the downstream drivers after
> > > > doing
> > > > some
> > > > minor touchups and submitting them to staging.  That would at
> > > > least
> > > > get
> > > > things working while people argue about what the correct DT
> > > > nodes
> > > > should be.
> > > > 
> > > > I would also like to point out that the RPI 3 has been out for
> > > > over
> > > > a
> > > > year and nobody has been able to get working video out of it
> > > > through
> > > > VC4 on a mainline tree.  At least until now.  So I'm not sure
> > > > the
> > > > best
> > > > way to go is for the expander driver to go under the GPIO
> > > > subtree.
> > > 
> > > Excuse me?  Display works fine on my Pi3.  VC4 uses DDC to probe
> > > for
> > > connection when the GPIO line isn't present in the DT.
> > 
> > Just a FYI, Eric Anholt has offically announced support for VC4 for
> > HDMI on mainline Linus build without any support from the expander
> > on
> > the RPI 3.  
> > 
> > Sounds like this particular driver isn't needed then, correct?
> 
> That's the HDMI audio that just landed.  HDMI has been working on the
> pi3 since 9d44a8d530e8cc97d71ffcbc0ff3b5553c62.
> 
> In the absence of a GPIO line for hotplug detect, we use DDC, which
> is
> slower and throws an error in dmesg when the probe happens but HDMI
> is
> disconnected.  As such, having a GPIO driver would improve things for
> people.


Would a non DT based solution be outside the realm of possibilities?  I
wrote a very simple library that emulates vcgencmd from the kernel. 
One of the commands for vcgencmd is to query the HDMI hotplug status. 
It's sort of semi documentated on the web.  The vcgencmd library works,
but I haven't tested if the virtualized hotplug info from the command
output is correct in all cases.

What I'm thinking is I could package this in a single file library that
would get put in upstream, but it would only support 1 command only. To
query the virtual hotplug status.

The only thing is you would need to take a dependency from VC4 to
vchiq/vc04_services.  It would get VC4 working better on upstream, but
it would mean taking a dependency from VC4 to vc04_services and the
stagging tree(with all that imples).

I think this may be a better solution then arguing with the DT folks on
this expander driver that isn't being directly controlled.

What do you think?

Re: [PATCH V12 05/10] acpi: apei: handle SEA notification type for ARMv8

[Baicar, Tyler]

Hello James,


On 3/17/2017 10:43 AM, James Morse wrote:

On 06/03/17 20:44, Tyler Baicar wrote:

ARM APEI extension proposal added SEA (Synchronous External Abort)
notification type for ARMv8.
Add a new GHES error source handling function for SEA. If an error
source's notification type is SEA, then this function can be registered
into the SEA exception handler. That way GHES will parse and report
SEA exceptions when they occur.
An SEA can interrupt code that had interrupts masked and is treated as
an NMI. To aid this the page of address space for mapping APEI buffers
while in_nmi() is always reserved, and ghes_ioremap_pfn_nmi() is
changed to use the helper methods to find the prot_t to map with in
the same way as ghes_ioremap_pfn_irq().
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index b25e7cf..b0596ba 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1023,6 +1075,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
pr_warning(GHES_PFX "Generic hardware error source: %d notified via 
local interrupt is not supported!\n",
   generic->header.source_id);
goto err;
+   case ACPI_HEST_NOTIFY_GPIO:
+   case ACPI_HEST_NOTIFY_SEI:
+   case ACPI_HEST_NOTIFY_GSIV:
+   pr_warn(GHES_PFX "Generic hardware error source: %d notified via 
notification type %u is not supported\n",
+   generic->header.source_id, generic->header.source_id);
+   rc = -ENOTSUPP;
+   goto err;
default:
pr_warning(FW_WARN GHES_PFX "Unknown notification type: %u for 
generic hardware error source: %d\n",
   generic->notify.type, generic->header.source_id);


This hunk will conflict with Shiju Jose's patch[0] that adds GPIO and GSIV
support. Can we remove it?
Yes, I was planning on removing this when I saw Shiju's patch. It will 
be removed in my v13.


Thanks,
Tyler


[0] https://www.spinics.net/lists/linux-acpi/msg72654.html


--
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.

Re: [PATCH v2 2/2] drm/panel: add innolux,p079zca panel driver

[Sean Paul]

On Wed, Mar 15, 2017 at 03:19:13PM +0800, Chris Zhong wrote:
> Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI
> panel.
> 
> Signed-off-by: Chris Zhong 
> ---
> 
> Changes in v2:
> - add some error check
> - always use Low power mode to send commend
> - add comments for all the sleep
> - use DRM_DEV_ERROR instead of dev_err
> 

Minor suggestion below. Once that's cleared up, you can add:
Reviewed-by: Sean Paul 

Also, please add Thierry directly to your patches so he sees them.


>  drivers/gpu/drm/panel/Kconfig |  11 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  drivers/gpu/drm/panel/panel-innolux-p079zca.c | 344 
> ++
>  3 files changed, 356 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-innolux-p079zca.c
> 


> +static int innolux_panel_prepare(struct drm_panel *panel)
> +{
> + struct innolux_panel *innolux = to_innolux_panel(panel);
> + int err, ret;
> +
> + if (innolux->prepared)
> + return 0;
> +
> + gpiod_set_value_cansleep(innolux->enable_gpio, 0);
> +
> + err = regulator_enable(innolux->supply);
> + if (err < 0)
> + return err;
> +
> + /* T2: 15ms - 1000ms */
> + usleep_range(15000, 16000);
> +
> + gpiod_set_value_cansleep(innolux->enable_gpio, 1);
> +
> + /* T4: 15ms - 1000ms */
> + usleep_range(15000, 16000);
> +
> + err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
> + if (err < 0) {
> + DRM_DEV_ERROR(panel->dev, "failed to exit sleep mode: %d\n",
> +   err);
> + goto poweroff;
> + }
> +
> + /* T6: 120ms - 1000ms*/
> + msleep(120);
> +
> + err = mipi_dsi_dcs_set_display_on(innolux->link);
> + if (err < 0) {
> + DRM_DEV_ERROR(panel->dev, "failed to set display on: %d\n",
> +   err);
> + goto poweroff;
> + }
> +
> + /* T7: 5ms */
> + usleep_range(5000, 6000);
> +
> + innolux->prepared = true;
> +
> + return 0;
> +
> +poweroff:
> + ret = regulator_disable(innolux->supply);
> + if (ret)
> + return ret;

I don't think we should be returning this error code. If we're here, it's
because something else triggered err, and we should return that. Change this to:

if (regulator_disable(innolux->supply))
DRM_DEV_ERROR(panel->dev, "failed to disable regulator after error\n");



Sean

> +
> + gpiod_set_value_cansleep(innolux->enable_gpio, 0);
> + return err;
> +}



> -- 
> 2.6.3
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/3] arm64: exynos: Enable drivers for Exynos5433

[Krzysztof Kozlowski]

On Tue, Mar 14, 2017 at 07:10:25PM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> 
> Patches are independent but I organized them into one patchset
> as they have common goal - enable more drivers for ARMv8 Exynos chips.
> 
> If there are no objections, I can take it through samsung-soc.
> 
> Changes since v1:
> 
> 1. Patch 1/3: Do not enable entire DRM stack but only drivers
>supporting Exynos5433 and Exynos7 (suggested by Bartlomiej).
> 2. Add Bartlomiej's and Alim's reviews.
> 
> 
> Best regards,
> Krzysztof
>

I appled all three to samsung-soc and I will push them through arm-soc.

Best regards,
Krzysztof