date:20180413

On Tue, Mar 27, 2018 at 10:02:03AM +, Vadim Pasternak wrote:
> It adds missed logic for signal acknowledge, by adding an extra run for
> work queue in case a signal is received, but no specific signal assertion
> is detected. Such case theoretically can happen for example in case
> several units are removed or inserted at the same time. In this situation
> acknowledge for some signal can be missed at signal top aggreagation
> status level.

Why can they be missed? What does "signal top aggregation status level"
mean? I'm asking to confirm that we are fixing this at the right place,
and not just applying a suboptimal bandaid by running the workqueue
more.

...

> 
> Fixes: 1f976f6978bf ("platform/x86: Move Mellanox platform hotplug driver to 
> platform/mellanox")

You didn't mention above how this commit caused this - how did moving
the driver create this problem? Does this need to go to stable? I'm
assuming not as you've called it theoretical - not something you've
observed in practice?

...

>  static int mlxreg_hotplug_device_create(struct mlxreg_hotplug_priv_data 
> *priv,
> @@ -410,6 +413,18 @@ static void mlxreg_hotplug_work_handler(struct 
> work_struct *work)
>   aggr_asserted = priv->aggr_cache ^ regval;
>   priv->aggr_cache = regval;
>  
> + /*
> +  * Handler is invoked, but no assertion is detected at top aggregation
> +  * status level. Set aggr_asserted to mask value to allow handler extra
> +  * run over all relevant signals to recover any missed signal.
> +  */
> + if (priv->not_asserted == MLXREG_HOTPLUG_NOT_ASSERT) {
> + priv->not_asserted = 0;
> + aggr_asserted = pdata->mask;
> + }
> + if (!aggr_asserted)

We seem to check aggr_asserted in several places in this routine now.
Looks like something we could simplify. If you check it here, can you
drop the check lower in the routine? Can you remove it from the for loop
if conditional entirely? Please consider how to simplify.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 1/6] fs: use << for MS_* flags

2018-04-13 Thread Randy Dunlap

On 04/13/2018 09:11 AM, Christian Brauner wrote:
> Consistenly use << to define MS_* constants.
> 
> Signed-off-by: Christian Brauner 
> ---
>  include/uapi/linux/fs.h | 33 +
>  1 file changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index d2a8313fabd7..9662790a657c 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -105,22 +105,23 @@ struct inodes_stat_t {
>  /*
>   * These are the fs-independent mount-flags: up to 32 flags are supported
>   */
> -#define MS_RDONLY 1  /* Mount read-only */
> -#define MS_NOSUID 2  /* Ignore suid and sgid bits */
> -#define MS_NODEV  4  /* Disallow access to device special files */
> -#define MS_NOEXEC 8  /* Disallow program execution */
> -#define MS_SYNCHRONOUS   16  /* Writes are synced at once */
> -#define MS_REMOUNT   32  /* Alter flags of a mounted FS */
> -#define MS_MANDLOCK  64  /* Allow mandatory locks on an FS */
> -#define MS_DIRSYNC   128 /* Directory modifications are synchronous */
> -#define MS_NOATIME   1024/* Do not update access times. */
> -#define MS_NODIRATIME2048/* Do not update directory access times 
> */
> -#define MS_BIND  4096
> -#define MS_MOVE  8192
> -#define MS_REC   16384
> -#define MS_VERBOSE   32768   /* War is peace. Verbosity is silence.
> -MS_VERBOSE is deprecated. */
> -#define MS_SILENT32768
> +#define MS_RDONLY(1<<0)  /* Mount read-only */

Why not just use BIT(n) instead?

#include 

#define MS_RDONLY   BIT(0)  /* Mount read-only */

etc.

> +#define MS_NOSUID(1<<1)  /* Ignore suid and sgid bits */
> +#define MS_NODEV (1<<2)  /* Disallow access to device special files */
> +#define MS_NOEXEC(1<<3)  /* Disallow program execution */
> +#define MS_SYNCHRONOUS   (1<<4)  /* Writes are synced at once */
> +#define MS_REMOUNT   (1<<5)  /* Alter flags of a mounted FS */
> +#define MS_MANDLOCK  (1<<6)  /* Allow mandatory locks on an FS */
> +#define MS_DIRSYNC   (1<<7)  /* Directory modifications are synchronous */
> +#define MS_NOATIME   (1<<10) /* Do not update access times. */
> +#define MS_NODIRATIME(1<<11) /* Do not update directory access times 
> */
> +#define MS_BIND  (1<<12)
> +#define MS_MOVE  (1<<13)
> +#define MS_REC   (1<<14)
> +#define MS_VERBOSE   (1<<15) /* War is peace. Verbosity is silence.
> +  * MS_VERBOSE is deprecated.
> +  */
> +#define MS_SILENT(1<<15)
>  #define MS_POSIXACL  (1<<16) /* VFS does not apply the umask */
>  #define MS_UNBINDABLE(1<<17) /* change to unbindable */
>  #define MS_PRIVATE   (1<<18) /* change to private */
> 


-- 
~Randy

[PATCH v2 3/3] Documentation/i2c: adopt kernel commenting style in examples

The example I2C code is rewritten to adopt the preferred kernel block
commenting style.

Signed-off-by: Sam Hansen 
---
 Documentation/i2c/dev-interface | 57 +
 1 file changed, 43 insertions(+), 14 deletions(-)

diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index f92ee1f59914..e17f5814c199 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -30,24 +30,34 @@ assume much about them. They can even change from one boot 
to the next.
 
 Next thing, open the device file, as follows:
 
+  /*
+   * The adapter is probably dynamically determined.
+   */
   int file;
-  int adapter_nr = 2; /* probably dynamically determined */
+  int adapter_nr = 2;
   char filename[20];
 
   snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
   file = open(filename, O_RDWR);
   if (file < 0) {
-/* ERROR HANDLING; you can check errno to see what went wrong */
+/*
+ * ERROR HANDLING; you can check errno to see what went wrong.
+ */
 exit(1);
   }
 
 When you have opened the device, you must specify with what device
 address you want to communicate:
 
-  int addr = 0x40; /* The I2C address */
+  /*
+   * The I2C address.
+   */
+  int addr = 0x40;
 
   if (ioctl(file, I2C_SLAVE, addr) < 0) {
-/* ERROR HANDLING; you can check errno to see what went wrong */
+/*
+ * ERROR HANDLING; you can check errno to see what went wrong.
+ */
 exit(1);
   }
 
@@ -55,32 +65,51 @@ Well, you are all set up now. You can now use SMBus 
commands or plain
 I2C to communicate with your device. SMBus commands are preferred if
 the device supports them. Both are illustrated below.
 
-  __u8 reg = 0x10; /* Device register to access */
+  /*
+   * The device register to access.
+   */
+  __u8 reg = 0x10;
   __s32 res;
   char buf[10];
 
-  /* Using SMBus commands */
+  /*
+   * Using SMBus commands.
+   */
   res = i2c_smbus_read_word_data(file, reg);
   if (res < 0) {
-/* ERROR HANDLING: i2c transaction failed */
+/*
+ * ERROR HANDLING: i2c transaction failed.
+ */
   } else {
-/* res contains the read word */
+/*
+ * res contains the read word.
+ */
   }
 
-  /* Using I2C Write, equivalent of
- i2c_smbus_write_word_data(file, reg, 0x6543) */
+  /*
+   * Using I2C Write, equivalent of
+   * i2c_smbus_write_word_data(file, reg, 0x6543).
+   */
   buf[0] = reg;
   buf[1] = 0x43;
   buf[2] = 0x65;
   if (write(file, buf, 3) != 3) {
-/* ERROR HANDLING: i2c transaction failed */
+/*
+ * ERROR HANDLING: i2c transaction failed.
+ */
   }
 
-  /* Using I2C Read, equivalent of i2c_smbus_read_byte(file) */
+  /*
+   * Using I2C Read, equivalent of i2c_smbus_read_byte(file).
+   */
   if (read(file, buf, 1) != 1) {
-/* ERROR HANDLING: i2c transaction failed */
+/*
+ * ERROR HANDLING: i2c transaction failed.
+ */
   } else {
-/* buf[0] contains the read byte */
+/*
+ * buf[0] contains the read byte.
+ */
   }
 
 Note that only a subset of the I2C and SMBus protocols can be achieved by
-- 
2.17.0.484.g0c8726318c-goog

[PATCH v2 2/3] Documentation/i2c: sync docs with current state of i2c-tools

Currently, Documentation/i2c/dev-interface describes the use of
i2c_smbus_* helper routines as static inlined functions provided by
linux/i2c-dev.h.  Work has been done to refactor the linux/i2c-dev.h file
in the i2c-tools project out into its own library.  As a result, these
docs have become stale.

This patch corrects the discrepancy and directs the reader to the
i2c-tools project for more information.

Signed-off-by: Sam Hansen 
---
 Documentation/i2c/dev-interface | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index c8737d502791..f92ee1f59914 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -23,11 +23,6 @@ First, you need to include these two headers:
   #include 
   #include 
 
-(Please note that there are two files named "i2c-dev.h" out there. One is
-distributed with the Linux kernel and the other one is included in the
-source tree of i2c-tools. They used to be different in content but since 2012
-they're identical. You should use "linux/i2c-dev.h").
-
 Now, you have to decide which adapter you want to access. You should
 inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
 Adapter numbers are assigned somewhat dynamically, so you can not
@@ -140,8 +135,8 @@ ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)
   set in each message, overriding the values set with the above ioctl's.
 
 ioctl(file, I2C_SMBUS, struct i2c_smbus_ioctl_data *args)
-  Not meant to be called  directly; instead, use the access functions
-  below.
+  If possible, use the provided i2c_smbus_* methods described below instead
+  of issuing direct ioctls.
 
 You can do plain i2c transactions by using read(2) and write(2) calls.
 You do not need to pass the address byte; instead, set it through
@@ -166,10 +161,9 @@ what happened. The 'write' transactions return 0 on 
success; the
 returns the number of values read. The block buffers need not be longer
 than 32 bytes.
 
-The above functions are all inline functions, that resolve to calls to
-the i2c_smbus_access function, that on its turn calls a specific ioctl
-with the data in a specific format. Read the source code if you
-want to know what happens behind the screens.
+The above functions are made available by linking against the libi2c library,
+which is provided by the i2c-tools project.  See:
+https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/.
 
 
 Implementation details
-- 
2.17.0.484.g0c8726318c-goog

[PATCH v2 1/3] Documentation/i2c: whitespace cleanup

This strips trailing whitespace in Documentation/i2c/dev-interface.

Signed-off-by: Sam Hansen 
---
 Documentation/i2c/dev-interface | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index d04e6e4964ee..c8737d502791 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -9,8 +9,8 @@ i2c adapters present on your system at a given time. i2cdetect 
is part of
 the i2c-tools package.
 
 I2C device files are character device files with major device number 89
-and a minor device number corresponding to the number assigned as 
-explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ..., 
+and a minor device number corresponding to the number assigned as
+explained above. They should be called "i2c-%d" (i2c-0, i2c-1, ...,
 i2c-10, ...). All 256 minor device numbers are reserved for i2c.
 
 
@@ -38,7 +38,7 @@ Next thing, open the device file, as follows:
   int file;
   int adapter_nr = 2; /* probably dynamically determined */
   char filename[20];
-  
+
   snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
   file = open(filename, O_RDWR);
   if (file < 0) {
@@ -72,7 +72,7 @@ the device supports them. Both are illustrated below.
 /* res contains the read word */
   }
 
-  /* Using I2C Write, equivalent of 
+  /* Using I2C Write, equivalent of
  i2c_smbus_write_word_data(file, reg, 0x6543) */
   buf[0] = reg;
   buf[1] = 0x43;
@@ -147,7 +147,7 @@ You can do plain i2c transactions by using read(2) and 
write(2) calls.
 You do not need to pass the address byte; instead, set it through
 ioctl I2C_SLAVE before you try to access the device.
 
-You can do SMBus level transactions (see documentation file smbus-protocol 
+You can do SMBus level transactions (see documentation file smbus-protocol
 for details) through the following functions:
   __s32 i2c_smbus_write_quick(int file, __u8 value);
   __s32 i2c_smbus_read_byte(int file);
@@ -158,7 +158,7 @@ for details) through the following functions:
   __s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value);
   __s32 i2c_smbus_process_call(int file, __u8 command, __u16 value);
   __s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
-  __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length, 
+  __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
__u8 *values);
 All these transactions return -1 on failure; you can read errno to see
 what happened. The 'write' transactions return 0 on success; the
-- 
2.17.0.484.g0c8726318c-goog

Re: [PATCH] base: dma-mapping: Postpone cpu addr translation on mmap()

2018-04-13 Thread Christoph Hellwig

Please send a v2.

Re: [RFC PATCH 3/4] acpi: apei: Do not panic() in NMI because of GHES messages

2018-04-13 Thread James Morse

Hi Alex,

On 09/04/18 19:11, Alex G. wrote:
> On 04/06/2018 01:24 PM, James Morse wrote:
> Do you have any ETA on when your SEA patches are going to make it
> upstream? There's not much point in updating my patchset if it's going
> to conflict with your work.

The SEA stuff went in with 7edda0886bc3 ("acpi: apei: handle SEA notification
type for ARMv8"). My series is moving it to use the estatus-queue in the same
way as x86's NOTIFY_NMI does. This lets us safely add the other two NMI-like
notifications. I have no idea on the ETA, it depends on review feedback!

>>> But if on arm64, you can return to firmware,
>>> then we have wildly different constraints.
>>
>> We can't return to firmware, but we can take the error again, causing another
>> trap to firmware.
>>
>> e.g.: If a program accesses a value in the cache and the cache location is
>> discovered to be corrupt/marked-as-poisoned. This causes an 'external abort'
>> exception, which firmware has configured to trap to firmware. Once there, it
>> generates CPER records and sets-up an external-abort-exception for Linux.
>> If linux returns from this external-abort, we return to whatever program
>> accessed the bad-cache-value in the first case, re-run the instruction that
>> generates the external abort, and the same thing happens again, but to 
>> firmware
>> it looks like a second fault at the same address.

> This is a very good example of why we should _not_ panic in NMI.
> Invalidate the cache-line, next load causes a memory round-trip, and
> everyone's happy. Of course, FFS can't do that because it doesn't know
> if it's valid to invalidate (pun intended). But the OS does. So you
> _want_ to reach the error handler downstream of NMI context, and you do
> _not_ want to crash.

This assumes a cache-invalidate will clear the error, which I don't think we're
guaranteed on arm.
It also destroys any adjacent data, "everyone's happy" includes the thread that
got a chunk of someone-else's stack frame, I don't think it will be happy for
very long!

(this is a side issue for AER though)

>>> On x86, you can't return to SMM. You can have a new SMI triggered while
>>> servicing the NMI, but you can't re-enter an SMI that you've returned
>>> from. SMM holds all the cores, and they all leave SMM at roughly the
>>> same time, so you don't deal with coexistence issues. This probably also
>>> avoids the multiple notifications that you are trying to implement on arm.
>>
>> its the new SMI case.
>>
>> (We don't necessarily have all cores pulled into firmware, (although firmware
>> could do that in software), so different CPUs taking NMI-like notifications 
>> is
>> one of the things we have to handle.)

> How does FFS handle race conditions that can occur when accessing HW
> concurrently with the OS? I'm told it's the main reasons why BIOS
> doesn't release unused cores from SMM early.

This is firmware's problem, it depends on whether there is any hardware that is
shared with the OS. Some hardware can be marked 'secure' in which case only
firmware can access it, alternatively firmware can trap or just disable the OS's
access to the shared hardware.

For example, with the v8.2 RAS Extensions, there are some per-cpu error
registers. Firmware can disable these for the OS, so that it always reads 0 from
them. Instead firmware takes the error via FF, reads the registers from
firmware, and dumps CPER records into the OS's memory.

If there is a shared hardware resource that both the OS and firmware may be
accessing, yes firmware needs to pull the other CPUs in, but this depends on the
SoC design, it doesn't necessarily happen.

>>> On quick thought, I think the best way to go for both series is to leave
>>> the entry points arch-specific, and prevent hax86 and harm64 from
>>> stepping on each other's toes. Thoughts?
>>
>> The behaviour should be driven from the standard. I agree there is some 
>> leeway,
>> which linux should handle on all architectures that support GHES.
> 
> "The standard" deals mostly with firmware behavior. While I'm all for
> following specifications in order to ensure smooth interaction and
> integration, Linux is an OS and it deals with a plethora of "standards".
> Its job is to serve user requests. When a "standard" deviates from this,
> such as mandating a crash when one is not required, it's the OS's job to
> _not_ follow this requirement.

Sure, we're quirking our behaviour based on a high level of mistrust for the
firmware. My point here was we shouldn't duplicate the implementation because we
want x86:{AER,CPU,MEM} to behave differently to arm64:{AER,CPU,MEM}. I'd rather
the quirked-behaviour was along the *:{AER} versus *:{CPU,MEM} line. If we have
extra code to spot deferrable errors, we should use it on both architectures.

>> Once in ghes.c all the NMI-like notifications get merged together as the only
>> relevant thing about them is we have to use the estatus-queue, and can't call
>> any of the sleepy recovery helpers.
>>
>> I don't th

Re: [PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode

2018-04-13 Thread Kees Cook

On Thu, Apr 12, 2018 at 10:06 PM, Masahiro Yamada
 wrote:
> +stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
> +stackp-flags-$(CONFIG_CC_STACKPROTECTOR)  := -fstack-protector
> +stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG)   := -fstack-protector-strong
> +
> +KBUILD_CFLAGS += $(stackp-flags-y)

So, technically, this works just fine. I wonder if it has an overly
confusing result, in that the compiler under normal situations will
see:

gcc ... -fno-stack-protector -fstack-protector -fstack-protector-strong ...

How about something like this instead:

ifdef CONFIG_CC_STACKPROTECTOR_STRONG
KBUILD_CFLAGS += -fstack-protector-strong
else
ifdef CONFIG_CC_STACKPROTECTOR
KBUILD_CFLAGS += -fstack-protector
else
KBUILD_CFLAGS += -fno-stack-protector
endif
endif

-Kees

-- 
Kees Cook
Pixel Security

[PATCH v2 2/2] tracing/events: block: dev_t via driver core for plug and unplug events

Complements v2.6.31 commit 55782138e47d ("tracing/events: convert block
trace points to TRACE_EVENT()") to be equivalent to traditional blktrace
output. Also this allows event filtering to not always get all (un)plug
events.

NB: The NULL pointer check for q->kobj.parent is certainly racy and
I don't have enough experience if it's good enough for a trace event.
The change did work for my cases (block device read/write I/O on
zfcp-attached SCSI disks and dm-mpath on top).

While I haven't seen any prior art using driver core (parent) relations
for trace events, there are other cases using this when no direct pointer
exists between objects, such as:
 #define to_scsi_target(d)  container_of(d, struct scsi_target, dev)
 static inline struct scsi_target *scsi_target(struct scsi_device *sdev)
 {
return to_scsi_target(sdev->sdev_gendev.parent);
 }

This is the object model we make use of here:

struct gendisk {
struct hd_struct {
struct device {  /*container_of*/
struct kobject kobj; <--+
dev_t  devt; /*deref*/  |
} __dev;|
} part0;|
struct request_queue *queue; ..+|
}  :|
   :|
struct request_queue {  <..+|
/* queue kobject */ |
struct kobject {|
struct kobject *parent; +
} kobj;
}

The parent pointer comes from:
 #define disk_to_dev(disk)  (&(disk)->part0.__dev)
int blk_register_queue(struct gendisk *disk)
struct device *dev = disk_to_dev(disk);
struct request_queue *q = disk->queue;
ret = kobject_add(&q->kobj, kobject_get(&dev->kobj), "%s", "queue");
^^^parent

$ ls -d /sys/block/sdf/queue
/sys/block/sda/queue
$ cat /sys/block/sdf/dev
80:0

A partition does not have its own request queue:

$ cat /sys/block/sdf/sdf1/dev
8:81
$ ls -d /sys/block/sdf/sdf1/queue
ls: cannot access '/sys/block/sdf/sdf1/queue': No such file or directory

The difference to blktrace parsed output is that block events don't use the
partition's minor number but the containing block device's minor number:

$ dd if=/dev/sdf1 count=1

$ cat /sys/kernel/debug/tracing/trace
block_bio_remap: 8,80 R 2048 + 32 <- (8,81) 0
block_bio_queue: 8,80 R 2048 + 32 [dd]
block_getrq: 8,80 R 2048 + 32 [dd]
block_plug: 8,80 [dd]

block_rq_insert: 8,80 R 16384 () 2048 + 32 [dd]
block_unplug: 8,80 [dd] 1 explicit
  
block_rq_issue: 8,80 R 16384 () 2048 + 32 [dd]
block_rq_complete: 8,80 R () 2048 + 32 [0]

$ btrace /dev/sdf1
  8,80   11 0.0 240240  A   R 2048 + 32 <- (8,81) 0
  8,81   12 0.000220890 240240  Q   R 2048 + 32 [dd]
  8,81   13 0.000229639 240240  G   R 2048 + 32 [dd]
  8,81   14 0.000231805 240240  P   N [dd]
^^
  8,81   15 0.000234671 240240  I   R 2048 + 32 [dd]
  8,81   16 0.000236365 240240  U   N [dd] 1
^^
  8,81   17 0.000238527 240240  D   R 2048 + 32 [dd]
  8,81   22 0.000613741 0  C   R 2048 + 32 [0]

Signed-off-by: Steffen Maier 
---
 include/trace/events/block.h | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/block.h b/include/trace/events/block.h
index e90bb6eb8097..6ea5a3899c2e 100644
--- a/include/trace/events/block.h
+++ b/include/trace/events/block.h
@@ -460,14 +460,18 @@ TRACE_EVENT(block_plug,
TP_ARGS(q),
 
TP_STRUCT__entry(
+   __field( dev_t, dev )
__array( char,  comm,   TASK_COMM_LEN   )
),
 
TP_fast_assign(
+   __entry->dev = q->kobj.parent ?
+   container_of(q->kobj.parent, struct device, kobj)->devt : 0;
memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
),
 
-   TP_printk("[%s]", __entry->comm)
+   TP_printk("%d,%d [%s]",
+ MAJOR(__entry->dev), MINOR(__entry->dev), __entry->comm)
 );
 
 #define show_block_unplug_explicit(val)\
@@ -482,18 +486,23 @@ DECLARE_EVENT_CLASS(block_unplug,
TP_ARGS(q, depth, explicit),
 
TP_STRUCT__entry(
+   __field( dev_t, dev )
__field( int,   nr_rq   )
__field( bool,  explicit)
__array( char,  comm,   TASK_COMM_LEN   )
),
 
TP_fast_assign(
+   __entry->dev   = q->kobj.parent ?
+   container_of(q->kobj.parent, struct device, kobj)->devt : 0;
__entry->nr_rq = depth;
__entry->explicit = explicit;
memcpy(__entry->comm, current->comm,

Re: [PATCH v3 2/2] MIPS: io: add a barrier after register read in readX()

2018-04-13 Thread Sinan Kaya

On 4/13/2018 11:41 AM, David Laight wrote:
> From: James Hogan
>> Sent: 12 April 2018 22:52
>> On Tue, Apr 03, 2018 at 08:55:04AM -0400, Sinan Kaya wrote:
>>> While a barrier is present in writeX() function before the register write,
>>> a similar barrier is missing in the readX() function after the register
>>> read. This could allow memory accesses following readX() to observe
>>> stale data.
>>>
>>> Signed-off-by: Sinan Kaya 
>>> Reported-by: Arnd Bergmann 
>>
>> Both patches look like obvious improvements to me, so I'm happy to apply
>> to my fixes branch.
> 
> Don't you also need at least barrier() between the register write in writeX()
> and the register read in readX()?
> On ppc you probably need eieio.
> Or are drivers expected to insert that one?
> If they need to insert that one then why not all the others??
> 

Good question. The volatile in here should prevent compiler from reordering the
register read or write instructions. 

static inline type pfx##read##bwlq(const volatile void __iomem *mem)

This is the solution all other architectures rely on especially via
__raw_readX() and __raw_writeX() API.

Now, things can get reordered when it leaves the CPU. This is guaranteed by
embedding wmb() and rmb() into the writeX() and readX() functions in other
architectures.

This ordering guarantee has been agreed to be the responsibility of the
architecture not drivers.

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

Re: INFO: rcu detected stall in shrink_dcache_parent

2018-04-13 Thread syzbot


syzbot has found reproducer for the following crash on upstream commit
16e205cf42da1f497b10a4a24f563e6c0d574eec (Fri Apr 13 03:56:10 2018 +)
Merge tag 'drm-fixes-for-v4.17-rc1' of  
git://people.freedesktop.org/~airlied/linux
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=8e4a81166025b5b7fa66


So far this crash happened 13 times on upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5369092034789376
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=4909037686620160
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=6422767771582464
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=-5947642240294114534

compiler: gcc (GCC) 8.0.1 20180301 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8e4a81166025b5b7f...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

INFO: rcu_sched self-detected stall on CPU
	1-...!: (124998 ticks this GP) idle=c6e/1/4611686018427387906  
softirq=11062/11062 fqs=0

 (t=125000 jiffies g=5220 c=5219 q=10)
rcu_sched kthread starved for 125000 jiffies! g5220 c5219 f0x0  
RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0

RCU grace-period kthread stack dump:
rcu_sched   R  running task23896 9  2 0x8000
Call Trace:
 context_switch kernel/sched/core.c:2848 [inline]
 __schedule+0x801/0x1e30 kernel/sched/core.c:3490
 schedule+0xef/0x430 kernel/sched/core.c:3549
 schedule_timeout+0x138/0x240 kernel/time/timer.c:1801
 rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231
 kthread+0x345/0x410 kernel/kthread.c:238
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:411
NMI backtrace for cpu 1
CPU: 1 PID: 4547 Comm: syzkaller613030 Not tainted 4.16.0+ #2
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
 nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
 arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
 trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
 rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
 print_cpu_stall kernel/rcu/tree.c:1525 [inline]
 check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
 __rcu_pending kernel/rcu/tree.c:3356 [inline]
 rcu_pending kernel/rcu/tree.c:3401 [inline]
 rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
 update_process_times+0x2d/0x70 kernel/time/timer.c:1636
 tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:173
 tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1283
 __run_hrtimer kernel/time/hrtimer.c:1386 [inline]
 __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1448
 hrtimer_interrupt+0x286/0x650 kernel/time/hrtimer.c:1506
 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
 smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862
 
RIP: 0010:__preempt_count_add arch/x86/include/asm/preempt.h:76 [inline]
RIP: 0010:__rcu_read_lock include/linux/rcupdate.h:83 [inline]
RIP: 0010:rcu_read_lock include/linux/rcupdate.h:630 [inline]
RIP: 0010:d_walk+0x476/0xc80 fs/dcache.c:1303
RSP: 0018:8801a93d79d8 EFLAGS: 0203 ORIG_RAX: ff13
RAX: 8801acbe6300 RBX: 8801a762b520 RCX: 815cbe3e
RDX:  RSI: 81c2a68f RDI: 8801a7644d20
RBP: 8801a93d7b58 R08: ed0034ec89a5 R09: ed0034ec89a4
R10: ed0034ec89a4 R11: 8801a7644d23 R12: 8801a7644ca0
R13: dc00 R14: 8801a7644d20 R15: 8801a93d7b30
 shrink_dcache_parent+0x179/0x230 fs/dcache.c:1486
 vfs_rmdir+0x202/0x470 fs/namei.c:3850
 do_rmdir+0x523/0x610 fs/namei.c:3911
 SYSC_rmdir fs/namei.c:3929 [inline]
 SyS_rmdir+0x1a/0x20 fs/namei.c:3927
 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x4464a7
RSP: 002b:7ffdd93b0718 EFLAGS: 0207 ORIG_RAX: 0054
RAX: ffda RBX: 0065 RCX: 004464a7
RDX:  RSI: 006d85f8 RDI: 7ffdd93b1f80
RBP: 7ffdd93b1f80 R08:  R09: 0001
R10: 0005 R11: 0207 R12: 025778a0
R13:  R14: 0008d71f R15: 7ffdd93b1978

[PATCH v2 14/14] staging: iio: Remove ad7746 from staging

Signed-off-by: Hernán Gonzalez 
---
 .../devicetree/bindings/staging/iio/cdc/ad7746.txt |  34 -
 drivers/staging/iio/cdc/Kconfig|  10 -
 drivers/staging/iio/cdc/Makefile   |   1 -
 drivers/staging/iio/cdc/ad7746.c   | 856 -
 drivers/staging/iio/cdc/ad7746.h   |  24 -
 5 files changed, 925 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
 delete mode 100644 drivers/staging/iio/cdc/ad7746.c
 delete mode 100644 drivers/staging/iio/cdc/ad7746.h

diff --git a/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt 
b/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
deleted file mode 100644
index 7740f05..000
--- a/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Analog Devices AD7746/5/7 capacitive sensor driver
-
-Required properties:
-   - compatible: Should be one of
-   * "adi,ad7745"
-   * "adi,ad7746"
- * "adi,ad7747"
-   - reg: The 7-bits long I2c address of the device
-
-Optional properties:
-   - adi,exclvl: This property defines the excitation voltage level for the
-capacitance to be measured. Possible values are:
-  * 0 = +-VDD/8
-  * 1 = +-VDD/4
-  * 2 = +-VDD * 3/8
-  * 3 = +-VDD/2 (Default)
-   - adi,nexca_en: Invert excitation output A.
-   - adi,nexcb_en: Invert excitation output B.
-
-Example:
-Here exclvl would be 1 (VDD/4), Excitation pin A would be inverted and
-Excitation pin B would NOT be inverted.
-
-i2c2 {
-
-  < . . . >
-
-  ad7746: ad7746@60 {
-  compatible = "ad7746";
-  reg = <0x60>;
-  adi,exclvl = <1>;
-  adi,nexca_en;
-  };
-};
diff --git a/drivers/staging/iio/cdc/Kconfig b/drivers/staging/iio/cdc/Kconfig
index 80211df..a170ab3 100644
--- a/drivers/staging/iio/cdc/Kconfig
+++ b/drivers/staging/iio/cdc/Kconfig
@@ -23,14 +23,4 @@ config AD7152
  To compile this driver as a module, choose M here: the
  module will be called ad7152.
 
-config AD7746
-   tristate "Analog Devices AD7745, AD7746 AD7747 capacitive sensor driver"
-   depends on I2C
-   help
- Say yes here to build support for Analog Devices capacitive sensors.
- (AD7745, AD7746, AD7747) Provides direct access via sysfs.
-
- To compile this driver as a module, choose M here: the
- module will be called ad7746.
-
 endmenu
diff --git a/drivers/staging/iio/cdc/Makefile b/drivers/staging/iio/cdc/Makefile
index a5fbabf..5db1acd 100644
--- a/drivers/staging/iio/cdc/Makefile
+++ b/drivers/staging/iio/cdc/Makefile
@@ -4,4 +4,3 @@
 
 obj-$(CONFIG_AD7150) += ad7150.o
 obj-$(CONFIG_AD7152) += ad7152.o
-obj-$(CONFIG_AD7746) += ad7746.o
diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
deleted file mode 100644
index ef0ebb5..000
--- a/drivers/staging/iio/cdc/ad7746.c
+++ /dev/null
@@ -1,856 +0,0 @@
-/*
- * AD7746 capacitive sensor driver supporting AD7745, AD7746 and AD7747
- *
- * Copyright 2011 Analog Devices Inc.
- *
- * Licensed under the GPL-2.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include "ad7746.h"
-
-/*
- * AD7746 Register Definition
- */
-
-#define AD7746_REG_CAP_DATA_HIGH   1
-#define AD7746_REG_VT_DATA_HIGH4
-#define AD7746_REG_CAP_SETUP   7
-#define AD7746_REG_VT_SETUP8
-#define AD7746_REG_EXC_SETUP   9
-#define AD7746_REG_CFG 10
-#define AD7746_REG_CAPDACA 11
-#define AD7746_REG_CAPDACB 12
-#define AD7746_REG_CAP_OFFH13
-#define AD7746_REG_CAP_GAINH   15
-#define AD7746_REG_VOLT_GAINH  17
-
-/* Capacitive Channel Setup Register Bit Designations (AD7746_REG_CAP_SETUP) */
-#define AD7746_CAPSETUP_CAPEN  BIT(7)
-#define AD7746_CAPSETUP_CIN2   BIT(6) /* AD7746 only */
-#define AD7746_CAPSETUP_CAPDIFFBIT(5)
-#define AD7746_CAPSETUP_CACHOP BIT(0)
-
-/* Voltage/Temperature Setup Register Bit Designations (AD7746_REG_VT_SETUP) */
-#define AD7746_VTSETUP_VTEN(1 << 7)
-#define AD7746_VTSETUP_VTMD_INT_TEMP   (0 << 5)
-#define AD7746_VTSETUP_VTMD_EXT_TEMP   (1 << 5)
-#define AD7746_VTSETUP_VTMD_VDD_MON(2 << 5)
-#define AD7746_VTSETUP_VTMD_EXT_VIN(3 << 5)
-#define AD7746_VTSETUP_EXTREF  BIT(4)
-#define AD7746_VTSETUP_VTSHORT BIT(1)
-#define AD7746_VTSETUP_VTCHOP  BIT(0)
-
-/* Excitation Setup Register Bit Designations (AD7746_REG_EXC_SETUP) */
-#define AD7746_EXCSETUP_CLKCTRLBIT(7)
-#define AD7746_EXCSETUP_EXCON  BIT(6)
-#define AD7746_EXCSETUP_EXCB   BIT(5)
-#define AD7746_EXCSETUP_NEXCB  BIT(4)
-#define AD7746_EXCSETUP_EXCA   BIT(3)
-#define AD7746_EXCSETUP_NEXCA  BIT(2)

[PATCH v2 13/14] Move ad7746 out of staging

Signed-off-by: Hernán Gonzalez 
---
 .../devicetree/bindings/iio/cdc/ad7746.txt |  34 +
 drivers/iio/Kconfig|   1 +
 drivers/iio/Makefile   |   1 +
 drivers/iio/cdc/Kconfig|  16 +
 drivers/iio/cdc/Makefile   |   5 +
 drivers/iio/cdc/ad7746.c   | 855 +
 include/linux/iio/cdc/ad7746.h |  20 +
 7 files changed, 932 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/cdc/ad7746.txt
 create mode 100644 drivers/iio/cdc/Kconfig
 create mode 100644 drivers/iio/cdc/Makefile
 create mode 100644 drivers/iio/cdc/ad7746.c
 create mode 100644 include/linux/iio/cdc/ad7746.h

diff --git a/Documentation/devicetree/bindings/iio/cdc/ad7746.txt 
b/Documentation/devicetree/bindings/iio/cdc/ad7746.txt
new file mode 100644
index 000..7740f05
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/cdc/ad7746.txt
@@ -0,0 +1,34 @@
+Analog Devices AD7746/5/7 capacitive sensor driver
+
+Required properties:
+   - compatible: Should be one of
+   * "adi,ad7745"
+   * "adi,ad7746"
+ * "adi,ad7747"
+   - reg: The 7-bits long I2c address of the device
+
+Optional properties:
+   - adi,exclvl: This property defines the excitation voltage level for the
+capacitance to be measured. Possible values are:
+  * 0 = +-VDD/8
+  * 1 = +-VDD/4
+  * 2 = +-VDD * 3/8
+  * 3 = +-VDD/2 (Default)
+   - adi,nexca_en: Invert excitation output A.
+   - adi,nexcb_en: Invert excitation output B.
+
+Example:
+Here exclvl would be 1 (VDD/4), Excitation pin A would be inverted and
+Excitation pin B would NOT be inverted.
+
+i2c2 {
+
+  < . . . >
+
+  ad7746: ad7746@60 {
+  compatible = "ad7746";
+  reg = <0x60>;
+  adi,exclvl = <1>;
+  adi,nexca_en;
+  };
+};
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index b3c8c6e..d1c309b 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -71,6 +71,7 @@ config IIO_TRIGGERED_EVENT
 source "drivers/iio/accel/Kconfig"
 source "drivers/iio/adc/Kconfig"
 source "drivers/iio/amplifiers/Kconfig"
+source "drivers/iio/cdc/Kconfig"
 source "drivers/iio/chemical/Kconfig"
 source "drivers/iio/common/Kconfig"
 source "drivers/iio/counter/Kconfig"
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index b16b2e9..18bea8d 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -17,6 +17,7 @@ obj-y += accel/
 obj-y += adc/
 obj-y += amplifiers/
 obj-y += buffer/
+obj-y += cdc/
 obj-y += chemical/
 obj-y += common/
 obj-y += counter/
diff --git a/drivers/iio/cdc/Kconfig b/drivers/iio/cdc/Kconfig
new file mode 100644
index 000..d3a8600
--- /dev/null
+++ b/drivers/iio/cdc/Kconfig
@@ -0,0 +1,16 @@
+#
+# CDC drivers
+#
+menu "Capacitance to digital converters"
+
+config AD7746
+   tristate "Analog Devices AD7745, AD7746 AD7747 capacitive sensor driver"
+   depends on I2C
+   help
+ Say yes here to build support for Analog Devices capacitive sensors.
+ (AD7745, AD7746, AD7747) Provides direct access via sysfs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7746.
+
+endmenu
diff --git a/drivers/iio/cdc/Makefile b/drivers/iio/cdc/Makefile
new file mode 100644
index 000..1f71283
--- /dev/null
+++ b/drivers/iio/cdc/Makefile
@@ -0,0 +1,5 @@
+#
+#Makeefile for industrial I/O CDC drivers
+#
+
+obj-$(CONFIG_AD7746) += ad7746.o
diff --git a/drivers/iio/cdc/ad7746.c b/drivers/iio/cdc/ad7746.c
new file mode 100644
index 000..f283819
--- /dev/null
+++ b/drivers/iio/cdc/ad7746.c
@@ -0,0 +1,855 @@
+/*
+ * AD7746 capacitive sensor driver supporting AD7745, AD7746 and AD7747
+ *
+ * Copyright 2011 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ * AD7746 Register Definition
+ */
+
+#define AD7746_REG_CAP_DATA_HIGH   1
+#define AD7746_REG_VT_DATA_HIGH4
+#define AD7746_REG_CAP_SETUP   7
+#define AD7746_REG_VT_SETUP8
+#define AD7746_REG_EXC_SETUP   9
+#define AD7746_REG_CFG 10
+#define AD7746_REG_CAPDACA 11
+#define AD7746_REG_CAPDACB 12
+#define AD7746_REG_CAP_OFFH13
+#define AD7746_REG_CAP_GAINH   15
+#define AD7746_REG_VOLT_GAINH  17
+
+/* Capacitive Channel Setup Register Bit Designations (AD7746_REG_CAP_SETUP) */
+#define AD7746_CAPSETUP_CAPEN  BIT(7)
+#define AD7746_CAPSETUP_CIN2   BIT(6) /* AD7746 only */
+#define AD7746_CAPSETUP_CAPDIFFBIT(5)
+#define AD7746_CAPSETUP_CACHOP BIT(0)
+
+/* Voltage/Temperature Setup Register Bit Designations (AD7746_REG_VT_SETUP) */
+#define AD7746_VTSETUP_VTEN

[PATCH v2 12/14] staging: iio: ad7746: Add ABI documentation

The use cases for this driver don't comply with the current ABI. The
ad7746 and ad7152 need an external capacitance or voltage reference to
automatically calibrate themselves which is not the normal use case of
the calibscale and calibbias ABIs, a new ABI was needed.

Signed-off-by: Hernán Gonzalez 
---
 Documentation/ABI/testing/sysfs-bus-iio-ad7746 | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-ad7746

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-ad7746 
b/Documentation/ABI/testing/sysfs-bus-iio-ad7746
new file mode 100644
index 000..96a41b7
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-ad7746
@@ -0,0 +1,17 @@
+What:  
/sys/bus/iio/devices/iio:deviceX/in_capacitanceX_calibscale_calibration
+What:  
/sys/bus/iio/devices/iio:deviceX/in_voltage0_calibscale_calibration
+KernelVersion: 4.17.0
+Contact:   linux-...@vger.kernel.org
+Description:
+   Enter gain calibration mode, in which a full-scale
+   {capacitance, voltage reference} must be connected to the
+   {capacitance, voltage} input beforehand to automatically
+   calibrate the device.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/in_capacitanceX_calibbias_calibration
+KernelVersion: 4.17.0
+Contact:   linux-...@vger.kernel.org
+Description:
+   Enter offset calibration mode, in which a zero-scale
+   capacitance must be connected to the capacitance input
+   beforehand to automatically calibrate the device.
-- 
2.7.4

[PATCH v2 11/14] staging: iio: ad7746: Add devicetree bindings documentation

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Signed-off-by: Hernán Gonzalez 
---
 .../devicetree/bindings/staging/iio/cdc/ad7746.txt | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt

diff --git a/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt 
b/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
new file mode 100644
index 000..7740f05
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
@@ -0,0 +1,34 @@
+Analog Devices AD7746/5/7 capacitive sensor driver
+
+Required properties:
+   - compatible: Should be one of
+   * "adi,ad7745"
+   * "adi,ad7746"
+ * "adi,ad7747"
+   - reg: The 7-bits long I2c address of the device
+
+Optional properties:
+   - adi,exclvl: This property defines the excitation voltage level for the
+capacitance to be measured. Possible values are:
+  * 0 = +-VDD/8
+  * 1 = +-VDD/4
+  * 2 = +-VDD * 3/8
+  * 3 = +-VDD/2 (Default)
+   - adi,nexca_en: Invert excitation output A.
+   - adi,nexcb_en: Invert excitation output B.
+
+Example:
+Here exclvl would be 1 (VDD/4), Excitation pin A would be inverted and
+Excitation pin B would NOT be inverted.
+
+i2c2 {
+
+  < . . . >
+
+  ad7746: ad7746@60 {
+  compatible = "ad7746";
+  reg = <0x60>;
+  adi,exclvl = <1>;
+  adi,nexca_en;
+  };
+};
-- 
2.7.4

[PATCH v2 09/14] staging: iio: ad7746: Add remove()

This allows the driver to be probed and removed as a module powering it
down on remove().

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index c29a221..05506bf9 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -775,6 +775,31 @@ static int ad7746_probe(struct i2c_client *client,
return 0;
 }
 
+static int ad7746_remove(struct i2c_client *client)
+{
+   struct iio_dev *indio_dev = i2c_get_clientdata(client);
+   struct ad7746_chip_info *chip = iio_priv(indio_dev);
+   unsigned char regval;
+   int ret;
+
+   mutex_lock(&chip->lock);
+
+   regval = chip->config | AD7746_CONF_MODE_PWRDN;
+   ret = i2c_smbus_write_byte_data(chip->client, AD7746_REG_CFG, regval);
+
+   mutex_unlock(&chip->lock);
+
+   if (ret < 0) {
+   dev_warn(&client->dev, "Could NOT Power Down!\n");
+   goto out;
+   }
+
+   iio_device_unregister(indio_dev);
+
+out:
+   return ret;
+}
+
 static const struct i2c_device_id ad7746_id[] = {
{ "ad7745", 7745 },
{ "ad7746", 7746 },
@@ -799,6 +824,7 @@ static struct i2c_driver ad7746_driver = {
.of_match_table = of_match_ptr(ad7746_of_match),
},
.probe = ad7746_probe,
+   .remove = ad7746_remove,
.id_table = ad7746_id,
 };
 module_i2c_driver(ad7746_driver);
-- 
2.7.4

[PATCH v2 06/14] staging: iio: ad7746: Reorder variable declarations

Reorder some variable declarations in an inverse-pyramid scheme.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 9ef476a..f53612a 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -220,8 +220,8 @@ static int ad7746_select_channel(struct iio_dev *indio_dev,
 struct iio_chan_spec const *chan)
 {
struct ad7746_chip_info *chip = iio_priv(indio_dev);
-   int ret, delay, idx;
u8 vt_setup, cap_setup;
+   int ret, delay, idx;
 
switch (chan->type) {
case IIO_CAPACITANCE:
@@ -289,8 +289,8 @@ static inline ssize_t ad7746_start_calib(struct device *dev,
 {
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct ad7746_chip_info *chip = iio_priv(indio_dev);
-   bool doit;
int ret, timeout = 10;
+   bool doit;
 
ret = strtobool(buf, &doit);
if (ret < 0)
@@ -680,8 +680,8 @@ static int ad7746_probe(struct i2c_client *client,
struct ad7746_platform_data *pdata = client->dev.platform_data;
struct ad7746_chip_info *chip;
struct iio_dev *indio_dev;
-   int ret = 0;
unsigned char regval = 0;
+   int ret = 0;
 
indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*chip));
if (!indio_dev)
-- 
2.7.4

[PATCH v2 07/14] staging: iio: ad7746: Remove unused defines

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 7 ---
 drivers/staging/iio/cdc/ad7746.h | 5 -
 2 files changed, 12 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index f53612a..d39ab34 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -25,7 +25,6 @@
  * AD7746 Register Definition
  */
 
-#define AD7746_REG_STATUS  0
 #define AD7746_REG_CAP_DATA_HIGH   1
 #define AD7746_REG_VT_DATA_HIGH4
 #define AD7746_REG_CAP_SETUP   7
@@ -38,12 +37,6 @@
 #define AD7746_REG_CAP_GAINH   15
 #define AD7746_REG_VOLT_GAINH  17
 
-/* Status Register Bit Designations (AD7746_REG_STATUS) */
-#define AD7746_STATUS_EXCERR   BIT(3)
-#define AD7746_STATUS_RDY  BIT(2)
-#define AD7746_STATUS_RDYVTBIT(1)
-#define AD7746_STATUS_RDYCAP   BIT(0)
-
 /* Capacitive Channel Setup Register Bit Designations (AD7746_REG_CAP_SETUP) */
 #define AD7746_CAPSETUP_CAPEN  BIT(7)
 #define AD7746_CAPSETUP_CIN2   BIT(6) /* AD7746 only */
diff --git a/drivers/staging/iio/cdc/ad7746.h b/drivers/staging/iio/cdc/ad7746.h
index ea8572d..2fbcee8 100644
--- a/drivers/staging/iio/cdc/ad7746.h
+++ b/drivers/staging/iio/cdc/ad7746.h
@@ -13,11 +13,6 @@
  * TODO: struct ad7746_platform_data needs to go into include/linux/iio
  */
 
-#define AD7466_EXCLVL_00 /* +-VDD/8 */
-#define AD7466_EXCLVL_11 /* +-VDD/4 */
-#define AD7466_EXCLVL_22 /* +-VDD * 3/8 */
-#define AD7466_EXCLVL_33 /* +-VDD/2 */
-
 struct ad7746_platform_data {
unsigned char exclvl;   /*Excitation Voltage Level */
bool exca_en;   /* enables EXCA pin as the excitation output */
-- 
2.7.4

[PATCH v2 08/14] staging: iio: ad7746: Add dt-bindings

This patch adds dt bindings by populating a pdata struct in order to
modify as little as possible the existing code. It supports both
platform_data and dt-bindings but uses only one depending on
CONFIG_OF's value.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 54 +++-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index d39ab34..c29a221 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -666,6 +666,43 @@ static const struct iio_info ad7746_info = {
 /*
  * device probe and remove
  */
+#ifdef CONFIG_OF
+static struct ad7746_platform_data *ad7746_parse_dt(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct ad7746_platform_data *pdata;
+   unsigned int tmp;
+   int ret;
+
+   /* The default excitation outputs are not inverted, it should be stated
+* in the dt if needed.
+*/
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   ret = of_property_read_u32(np, "adi,exclvl", &tmp);
+   if (ret || tmp > 3) {
+   dev_warn(dev, "Wrong exclvl value, using default\n");
+   pdata->exclvl = 3; /* default value */
+   } else {
+   pdata->exclvl = tmp;
+   }
+
+   pdata->exca_en = true;
+   pdata->excb_en = true;
+   pdata->exca_inv_en = of_property_read_bool(np, "adi,nexca_en");
+   pdata->excb_inv_en = of_property_read_bool(np, "adi,nexcb_en");
+
+   return pdata;
+}
+#else
+static struct ad7746_platform_data *ad7746_parse_dt(struct device *dev)
+{
+   return NULL;
+}
+#endif
 
 static int ad7746_probe(struct i2c_client *client,
const struct i2c_device_id *id)
@@ -676,6 +713,11 @@ static int ad7746_probe(struct i2c_client *client,
unsigned char regval = 0;
int ret = 0;
 
+   if (client->dev.of_node)
+   pdata = ad7746_parse_dt(&client->dev);
+   else
+   pdata = client->dev.platform_data;
+
indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*chip));
if (!indio_dev)
return -ENOMEM;
@@ -739,12 +781,22 @@ static const struct i2c_device_id ad7746_id[] = {
{ "ad7747", 7747 },
{}
 };
-
 MODULE_DEVICE_TABLE(i2c, ad7746_id);
 
+#ifdef CONFIG_OF
+static const struct of_device_id ad7746_of_match[] = {
+   { .compatible = "adi,ad7745" },
+   { .compatible = "adi,ad7746" },
+   { .compatible = "adi,ad7747" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, ad7746_of_match);
+#endif
+
 static struct i2c_driver ad7746_driver = {
.driver = {
.name = KBUILD_MODNAME,
+   .of_match_table = of_match_ptr(ad7746_of_match),
},
.probe = ad7746_probe,
.id_table = ad7746_id,
-- 
2.7.4

[PATCH v2 10/14] staging: iio: ad7746: Add comments

Add comments to clarify some of the calculations made, specially when
reading or writing values.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 05506bf9..ef0ebb5 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -429,6 +429,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
goto out;
}
 
+   /* 2^16 in micro */
val = (val2 * 1024) / 15625;
 
switch (chan->type) {
@@ -554,6 +555,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
if (ret < 0)
goto out;
 
+   /*
+* Either for Capacitance, Voltage or Temperature,
+* the 0x00 code represents negative full scale,
+* the 0x80 code represents zero scale, and
+* the 0xFF code represents positive full scale.
+*/
+
*val = (be32_to_cpu(chip->data.d32) & 0xFF) - 0x80;
 
switch (chan->type) {
@@ -565,7 +573,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
*val = (*val * 125) / 256;
break;
case IIO_VOLTAGE:
-   if (chan->channel == 1) /* supply_raw*/
+
+   /*
+* The voltage from the VDD pin is internally
+* attenuated by 6.
+*/
+
+   if (chan->channel == 1) /* supply_raw */
*val = *val * 6;
break;
default:
@@ -606,6 +620,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
ret = IIO_VAL_INT;
break;
case IIO_CHAN_INFO_OFFSET:
+
+   /*
+* CAPDAC Scale = 21pF_typ / 127
+* CIN Scale = 8.192pF / 2^24
+* Offset Scale = CAPDAC Scale / CIN Scale = 338646
+*/
+
*val = AD7746_CAPDAC_DACP(chip->capdac[chan->channel]
  [chan->differential]) * 338646;
 
@@ -614,13 +635,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
case IIO_CHAN_INFO_SCALE:
switch (chan->type) {
case IIO_CAPACITANCE:
-   /* 8.192pf / 2^24 */
+   /* CIN Scale: 8.192pf / 2^24 */
*val =  0;
*val2 = 488;
ret = IIO_VAL_INT_PLUS_NANO;
break;
case IIO_VOLTAGE:
-   /* 1170mV / 2^23 */
+   /* VIN Scale: 1170mV / 2^23 */
*val = 1170;
*val2 = 23;
ret = IIO_VAL_FRACTIONAL_LOG2;
@@ -674,7 +695,8 @@ static struct ad7746_platform_data *ad7746_parse_dt(struct 
device *dev)
unsigned int tmp;
int ret;
 
-   /* The default excitation outputs are not inverted, it should be stated
+   /*
+* The default excitation outputs are not inverted, it should be stated
 * in the dt if needed.
 */
 
@@ -685,7 +707,7 @@ static struct ad7746_platform_data *ad7746_parse_dt(struct 
device *dev)
ret = of_property_read_u32(np, "adi,exclvl", &tmp);
if (ret || tmp > 3) {
dev_warn(dev, "Wrong exclvl value, using default\n");
-   pdata->exclvl = 3; /* default value */
+   pdata->exclvl = 3;
} else {
pdata->exclvl = tmp;
}
-- 
2.7.4

[PATCH v2 04/14] staging: iio: ad7746: Fix multiple line dereference

Clear checkpatch.pl WARNING about multiple line derefence but creates a
new one of line over 80 characters. In my opinion, it improves
readability.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index d793785..82fac76 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -410,8 +410,7 @@ static struct attribute *ad7746_attributes[] = {
&iio_dev_attr_in_capacitance1_calibbias_calibration.dev_attr.attr,
&iio_dev_attr_in_voltage0_calibscale_calibration.dev_attr.attr,
&iio_const_attr_in_voltage_sampling_frequency_available.dev_attr.attr,
-   &iio_const_attr_in_capacitance_sampling_frequency_available.
-   dev_attr.attr,
+   
&iio_const_attr_in_capacitance_sampling_frequency_available.dev_attr.attr,
NULL,
 };
 
-- 
2.7.4

[PATCH v2 01/14] staging: iio: ad7746: Automatically swap values in readings/writings

Data to read or write was being handled with the swab16() macro instead
of using i2c_smbus_{read,write}_swapped.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 4882dbc..53e28ae 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -451,7 +451,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
goto out;
}
 
-   ret = i2c_smbus_write_word_data(chip->client, reg, swab16(val));
+   ret = i2c_smbus_write_word_swapped(chip->client, reg, val);
if (ret < 0)
goto out;
 
@@ -462,8 +462,8 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
ret = -EINVAL;
goto out;
}
-   ret = i2c_smbus_write_word_data(chip->client,
-   AD7746_REG_CAP_OFFH, swab16(val));
+   ret = i2c_smbus_write_word_swapped(chip->client,
+  AD7746_REG_CAP_OFFH, val);
if (ret < 0)
goto out;
 
@@ -594,21 +594,21 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
goto out;
}
 
-   ret = i2c_smbus_read_word_data(chip->client, reg);
+   ret = i2c_smbus_read_word_swapped(chip->client, reg);
if (ret < 0)
goto out;
/* 1 + gain_val / 2^16 */
*val = 1;
-   *val2 = (15625 * swab16(ret)) / 1024;
+   *val2 = (15625 * ret) / 1024;
 
ret = IIO_VAL_INT_PLUS_MICRO;
break;
case IIO_CHAN_INFO_CALIBBIAS:
-   ret = i2c_smbus_read_word_data(chip->client,
-  AD7746_REG_CAP_OFFH);
+   ret = i2c_smbus_read_word_swapped(chip->client,
+ AD7746_REG_CAP_OFFH);
if (ret < 0)
goto out;
-   *val = swab16(ret);
+   *val = ret;
 
ret = IIO_VAL_INT;
break;
-- 
2.7.4

[PATCH v2 02/14] staging: iio: ad7746: Adjust arguments to match open parenthesis

Clear a couple more checkpatch.pl CHECKS.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 53e28ae..516aa93 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -556,7 +556,8 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
/* Now read the actual register */
 
ret = i2c_smbus_read_i2c_block_data(chip->client,
-   chan->address >> 8, 3, &chip->data.d8[1]);
+   chan->address >> 8, 3,
+   &chip->data.d8[1]);
 
if (ret < 0)
goto out;
@@ -614,7 +615,7 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
break;
case IIO_CHAN_INFO_OFFSET:
*val = AD7746_CAPDAC_DACP(chip->capdac[chan->channel]
-   [chan->differential]) * 338646;
+ [chan->differential]) * 338646;
 
ret = IIO_VAL_INT;
break;
-- 
2.7.4

[PATCH v2 00/14] Move ad7746 driver out of staging

Version 2 of the series trying to move ad7746 our of staging.

Changes in v2: (v1-> https://lkml.org/lkml/2018/3/21/406)
* Fix some issues pointed out by Jonathan
* Power down device on remove
* Add new ABI for the use case

Hernán Gonzalez (14):
  staging: iio: ad7746: Automatically swap values in readings/writings
  staging: iio: ad7746: Adjust arguments to match open parenthesis
  staging: iio: ad7746: Fix bound checkings
  staging: iio: ad7746: Fix multiple line dereference
  staging: iio: ad7746: Reorder includes alphabetically
  staging: iio: ad7746: Reorder variable declarations
  staging: iio: ad7746: Remove unused defines
  staging: iio: ad7746: Add dt-bindings
  staging: iio: ad7746: Add remove()
  staging: iio: ad7746: Add comments
  staging: iio: ad7746: Add devicetree bindings documentation
  staging: iio: ad7746: Add ABI documentation
  Move ad7746 out of staging
  staging: iio: Remove ad7746 from staging

 Documentation/ABI/testing/sysfs-bus-iio-ad7746 |  17 +++
 .../devicetree/bindings/iio/cdc/ad7746.txt |  34 +
 drivers/iio/Kconfig|   1 +
 drivers/iio/Makefile   |   1 +
 drivers/iio/cdc/Kconfig|  16 ++
 drivers/iio/cdc/Makefile   |   5 +
 drivers/{staging => }/iio/cdc/ad7746.c | 162 -
 drivers/staging/iio/cdc/Kconfig|  10 --
 drivers/staging/iio/cdc/Makefile   |   1 -
 .../staging => include/linux}/iio/cdc/ad7746.h |   9 --
 10 files changed, 201 insertions(+), 55 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-ad7746
 create mode 100644 Documentation/devicetree/bindings/iio/cdc/ad7746.txt
 create mode 100644 drivers/iio/cdc/Kconfig
 create mode 100644 drivers/iio/cdc/Makefile
 rename drivers/{staging => }/iio/cdc/ad7746.c (85%)
 rename {drivers/staging => include/linux}/iio/cdc/ad7746.h (70%)

-- 
2.7.4

[PATCH v2 05/14] staging: iio: ad7746: Reorder includes alphabetically

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 82fac76..9ef476a 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -6,15 +6,15 @@
  * Licensed under the GPL-2.
  */
 
-#include 
+#include 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
+#include 
+#include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
-- 
2.7.4

[PATCH v2 03/14] staging: iio: ad7746: Fix bound checkings

Also remove unnecessary parenthesis

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 516aa93..d793785 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -458,7 +458,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
ret = 0;
break;
case IIO_CHAN_INFO_CALIBBIAS:
-   if ((val < 0) | (val > 0x)) {
+   if (val < 0 || val > 0x) {
ret = -EINVAL;
goto out;
}
@@ -470,7 +470,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
ret = 0;
break;
case IIO_CHAN_INFO_OFFSET:
-   if ((val < 0) | (val > 43008000)) { /* 21pF */
+   if (val < 0 || val > 43008000) { /* 21pF */
ret = -EINVAL;
goto out;
}
-- 
2.7.4

Re: [RFC PATCH for 4.18 12/23] cpu_opv: Provide cpu_opv system call (v7)

2018-04-13 Thread Linus Torvalds

On Fri, Apr 13, 2018 at 5:16 AM, Mathieu Desnoyers
 wrote:
> The vmalloc space needed by cpu_opv is bound by the number of pages
> a cpu_opv call can touch.

No it's not.

You can have a thousand different processes doing cpu_opv at the same time.

A *single* cpu_opv may me limited toi "only" a megabyte, but I'm not
seeing any global limit anywhere.

In short, this looks like a guaranteed DoS approach to me.

   Linus

[RFC v2] tracing/events: block: also try to get dev_t via driver core for some events

Complements v2.6.31 commit 55782138e47d ("tracing/events: convert block
trace points to TRACE_EVENT()") for cases where rq->rq_disk == NULL:
  block_rq_requeue, block_rq_insert, block_rq_issue;
and for cases where bio == NULL:
  block_getrq, block_sleeprq.

NB: The NULL pointer check for q->kobj.parent is certainly racy and
I don't have enough experience if it's good enough for a trace event.

Since I don't know when above cases would occur,
I'm not sure this is worth it.

Signed-off-by: Steffen Maier 
---
 include/trace/events/block.h | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/include/trace/events/block.h b/include/trace/events/block.h
index 6ea5a3899c2e..001e4f369df9 100644
--- a/include/trace/events/block.h
+++ b/include/trace/events/block.h
@@ -86,7 +86,9 @@ TRACE_EVENT(block_rq_requeue,
),
 
TP_fast_assign(
-   __entry->dev   = rq->rq_disk ? disk_devt(rq->rq_disk) : 0;
+   __entry->dev   = rq->rq_disk ? disk_devt(rq->rq_disk) :
+   (q->kobj.parent ?
+container_of(q->kobj.parent, struct device, kobj)->devt : 0);
__entry->sector= blk_rq_trace_sector(rq);
__entry->nr_sector = blk_rq_trace_nr_sectors(rq);
 
@@ -162,7 +164,9 @@ DECLARE_EVENT_CLASS(block_rq,
),
 
TP_fast_assign(
-   __entry->dev   = rq->rq_disk ? disk_devt(rq->rq_disk) : 0;
+   __entry->dev   = rq->rq_disk ? disk_devt(rq->rq_disk) :
+   (q->kobj.parent ?
+container_of(q->kobj.parent, struct device, kobj)->devt : 0);
__entry->sector= blk_rq_trace_sector(rq);
__entry->nr_sector = blk_rq_trace_nr_sectors(rq);
__entry->bytes = blk_rq_bytes(rq);
@@ -397,7 +401,9 @@ DECLARE_EVENT_CLASS(block_get_rq,
 ),
 
TP_fast_assign(
-   __entry->dev= bio ? bio_dev(bio) : 0;
+   __entry->dev= bio ? bio_dev(bio) :
+   (q->kobj.parent ?
+container_of(q->kobj.parent, struct device, kobj)->devt : 0);
__entry->sector = bio ? bio->bi_iter.bi_sector : 0;
__entry->nr_sector  = bio ? bio_sectors(bio) : 0;
blk_fill_rwbs(__entry->rwbs,
-- 
2.13.5

[PATCH v2 1/2] tracing/events: block: track and print if unplug was explicit or schedule

Just like blktrace distinguishes explicit and schedule by means of
BLK_TA_UNPLUG_IO and BLK_TA_UNPLUG_TIMER, actually make use of the
existing argument "explicit" to distinguish the two cases in the one
common tracepoint block_unplug.

Complements v2.6.39 commit 49cac01e1fa7 ("block: make unplug timer trace
event correspond to the schedule() unplug") and commit d9c978331790
("block: remove block_unplug_timer() trace point").

Signed-off-by: Steffen Maier 
---

Changes since v1:
Use 0 and 1 instead of false and true for __print_symbolic table.
Now "trace-cmd report" can decode it. [Steven Rostedt]

 include/trace/events/block.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/trace/events/block.h b/include/trace/events/block.h
index 81b43f5bdf23..e90bb6eb8097 100644
--- a/include/trace/events/block.h
+++ b/include/trace/events/block.h
@@ -470,6 +470,11 @@ TRACE_EVENT(block_plug,
TP_printk("[%s]", __entry->comm)
 );
 
+#define show_block_unplug_explicit(val)\
+   __print_symbolic(val,   \
+{0, "schedule"},   \
+{1, "explicit"})
+
 DECLARE_EVENT_CLASS(block_unplug,
 
TP_PROTO(struct request_queue *q, unsigned int depth, bool explicit),
@@ -478,15 +483,18 @@ DECLARE_EVENT_CLASS(block_unplug,
 
TP_STRUCT__entry(
__field( int,   nr_rq   )
+   __field( bool,  explicit)
__array( char,  comm,   TASK_COMM_LEN   )
),
 
TP_fast_assign(
__entry->nr_rq = depth;
+   __entry->explicit = explicit;
memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
),
 
-   TP_printk("[%s] %d", __entry->comm, __entry->nr_rq)
+   TP_printk("[%s] %d %s", __entry->comm, __entry->nr_rq,
+ show_block_unplug_explicit(__entry->explicit))
 );
 
 /**
-- 
2.13.5

Re: [[PATCH v2] 1/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

On Sun, Apr 08, 2018 at 04:02:12PM +0530, Taniya Das wrote:
> From: Amit Nischal 
> 
> Add the RPMh clock driver to control the RPMh managed clock resources on
> some of the Qualcomm Technologies, Inc. SoCs.
> 
> Signed-off-by: David Collins 
> Signed-off-by: Amit Nischal 
> Signed-off-by: Taniya Das 
> ---
>  drivers/clk/qcom/Kconfig  |   9 +
>  drivers/clk/qcom/Makefile |   1 +
>  drivers/clk/qcom/clk-rpmh.c   | 394 
> ++

>  include/dt-bindings/clock/qcom,rpmh.h |  25 +++

This goes with the binding patch which should come first in the series.

>  4 files changed, 429 insertions(+)
>  create mode 100644 drivers/clk/qcom/clk-rpmh.c
>  create mode 100644 include/dt-bindings/clock/qcom,rpmh.h

[PATCH v2 0/2] tracing/events: block: bring more on a par with blktrace

I had the need to understand I/O request processing in detail.
But I also had the need to enrich block traces with other trace events
including my own dynamic kprobe events. So I preferred block trace events
over blktrace to get everything nicely sorted into one ftrace output.
However, I missed device filtering for (un)plug events and also
the difference between the two flavors of unplug.

The first two patches bring block trace events closer to their
counterpart in blktrace tooling.

The last patch is just an RFC. I still kept it in this patch set because
it is inspired by PATCH 2/2.

Changes since v1:
[PATCH v2 1/2]
Use 0 and 1 instead of false and true for __print_symbolic table.
Now "trace-cmd report" can decode it. [Steven Rostedt]

Steffen Maier (3):
  tracing/events: block: track and print if unplug was explicit or
schedule
  tracing/events: block: dev_t via driver core for plug and unplug
events
  tracing/events: block: also try to get dev_t via driver core for some
events

 include/trace/events/block.h | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

-- 
2.13.5

Re: [PATCH v3] gpio: dwapb: Add support for 1 interrupt per port A GPIO

2018-04-13 Thread Hoan Tran

Hi Phil,

On Fri, Apr 13, 2018 at 1:51 AM, Phil Edworthy
 wrote:
> The DesignWare GPIO IP can be configured for either 1 interrupt or 1
> per GPIO in port A, but the driver currently only supports 1 interrupt.
> See the DesignWare DW_apb_gpio Databook description of the
> 'GPIO_INTR_IO' parameter.
>
> This change allows the driver to work with up to 32 interrupts, it will
> get as many interrupts as specified in the DT 'interrupts' property.
> It doesn't do anything clever with the different interrupts, it just calls
> the same handler used for single interrupt hardware.
>
> Signed-off-by: Phil Edworthy 
> ---
> One point to mention is that I have made it possible for users to have
> unconncted interrupts by specifying holes in the list of interrupts. This is
> done by supporting the interrupts-extended DT prop.
> However, I have no use for this and had to hack some test case for this.
> Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
>
> v3:
>  - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect 
> problems
> v2:
>  - Replaced interrupt-mask DT prop with support for the interrupts-extended
>prop. This means replacing the call to irq_of_parse_and_map() with calls
>to of_irq_parse_one() and irq_create_of_mapping().
>
> Note: There are a few *code* lines over 80 chars, but this is just guidance,
>right? Especially as there are already some lines over 80 chars.
> ---
>  .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |  9 -
>  drivers/gpio/gpio-dwapb.c  | 43 
> +-
>  drivers/mfd/intel_quark_i2c_gpio.c |  3 +-
>  include/linux/platform_data/gpio-dwapb.h   |  3 +-
>  4 files changed, 45 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
> b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> index 4a75da7..3c1118b 100644
> --- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> @@ -26,8 +26,13 @@ controller.
>the second encodes the triger flags encoded as described in
>Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>  - interrupt-parent : The parent interrupt controller.
> -- interrupts : The interrupt to the parent controller raised when GPIOs
> -  generate the interrupts.
> +- interrupts : The interrupts to the parent controller raised when GPIOs
> +  generate the interrupts. If the controller provides one combined interrupt
> +  for all GPIOs, specify a single interrupt. If the controller provides one
> +  interrupt for each GPIO, provide a list of interrupts that correspond to 
> each
> +  of the GPIO pins. When specifying multiple interrupts, if any are 
> unconnected,
> +  use the interrupts-extended property to specify the interrupts and set the
> +  interrupt controller handle for unused interrupts to 0.
>  - snps,nr-gpios : The number of pins in the port, a single cell.
>  - resets : Reset line for the controller.
>
> diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
> index 226977f..3273504 100644
> --- a/drivers/gpio/gpio-dwapb.c
> +++ b/drivers/gpio/gpio-dwapb.c
> @@ -441,14 +441,19 @@ static void dwapb_configure_irqs(struct dwapb_gpio 
> *gpio,
> irq_gc->chip_types[1].handler = handle_edge_irq;
>
> if (!pp->irq_shared) {
> -   irq_set_chained_handler_and_data(pp->irq, dwapb_irq_handler,
> -gpio);
> +   int i;
> +
> +   for (i = 0; i < pp->ngpio; i++) {
> +   if (pp->irq[i])
> +   irq_set_chained_handler_and_data(pp->irq[i],
> +   dwapb_irq_handler, gpio);
> +   }
> } else {
> /*
>  * Request a shared IRQ since where MFD would have devices
>  * using the same irq pin
>  */
> -   err = devm_request_irq(gpio->dev, pp->irq,
> +   err = devm_request_irq(gpio->dev, pp->irq[0],
>dwapb_irq_handler_mfd,
>IRQF_SHARED, "gpio-dwapb-mfd", gpio);
> if (err) {
> @@ -524,7 +529,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
> if (pp->idx == 0)
> port->gc.set_config = dwapb_gpio_set_config;
>
> -   if (pp->irq)
> +   if (pp->has_irq)
> dwapb_configure_irqs(gpio, port, pp);
>
> err = gpiochip_add_data(&port->gc, port);
> @@ -535,7 +540,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
> port->is_registered = true;
>
> /* Add GPIO-signaled ACPI event support */
> -   if (pp->irq)
> +   if (pp->has_irq)
> acpi_gpiochip_request_interrupts(&port->gc);
>
> return err;
> @@ -601,13

Re: [PATCH v4 2/3] dt-bindings: power: supply: qcom_bms: Add bindings

On Sat, Apr 07, 2018 at 06:57:45PM +0100, Craig Tatlor wrote:
> Add bindings for the Qualcomm Battery Monitoring system.
> 
> Signed-off-by: Craig Tatlor 
> ---
>  .../bindings/power/supply/qcom_bms.txt| 93 +++
>  1 file changed, 93 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/supply/qcom_bms.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/supply/qcom_bms.txt 
> b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt
> new file mode 100644
> index ..6296399edc09
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/qcom_bms.txt
> @@ -0,0 +1,93 @@
> +Qualcomm Battery Measurement System
> +
> +The Qualcomm Battery Measurement System is found inside of Qualcomm PM8941

Is it Monitoring or Measurment?

> +PMICs. It provides OCV and coulomb counter registers that allow the kernel
> +to infer a capacity level.

s/kernel/OS/

OCV?

> +
> +Required properties:
> +- compatible:   Should contain "qcom,pm8941-bms".
> +- reg:  Specifies the SPMI address and length of the
> + controller's registers.
> +- interrupts:   OCV threshold interrupt.
> +- io-channels:  Should contain IIO channel specifier for the
> + ADC channel that reports battery temperature.
> +- io-channel-names: Should contain "temp".
> +- qcom,fcc-temp-legend: An array containing the temperature, in degC,
> + for each column of the FCC lookup table.

What's FCC?

> +- qcom,fcc-lut: An array of FCC values in mah, one entry for each
> + temperature defined in in qcom,fcc-temp-legend.
> +- qcom,ocv-temp-legend: An array containing the temperature, in degC,
> + for each column of the OCV lookup table.
> +- qcom,ocv-capacity-legend: An array containing the capacity for each
> + row of the OCV lookup table.
> +- qcom,ocv-lut: An array of OCV values in mV, one entry for each
> + capacity defined in qcom,ocv-capacity-legend.

Need to specify the sizes of these if not 32-bit.

All these seem to have units, so add unit suffixes as defined in 
property-units.txt.

> +
> +Example:
> +
> + pm8941_vadc: vadc@3100 {

adc@...

> + compatible = "qcom,spmi-vadc";
> + reg = <0x3100>;
> + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #io-channel-cells = <1>;
> +
> + bat_temp {
> + reg = ;
> + };
> + };
> +
> + bms@4000 {
> + compatible = "qcom,pm8941-bms";
> + reg = <0x4000>;
> + interrupts = <0x0 0x40 0x4 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "ocv_thr";
> +
> + io-channels = <&pm8941_vadc VADC_LR_MUX1_BAT_THERM>;
> + io-channel-names = "temp";
> +
> + qcom,fcc-temp-legend = /bits/ 8 <(-10) 0 25 50 65>;
> + qcom,fcc-lut = /bits/ 16 <6010 6070 6680 6780 6670>;
> +
> + qcom,ocv-capacity-legend = /bits/ 8 <100 95 90 85
> +  80 75 70 65
> +  60 55 50 45
> +  40 35 30 25
> +  20 15 10 9
> +  8 7 6 5 4
> +  3 2 1 0>;
> +
> + qcom,ocv-temp-legend = /bits/ 8 <(-10) 0 25 50 65>;
> + qcom,ocv-lut = /bits/ 16 <4288 4288 4306 4315 4315
> +   4261 4241 4259 4266 4246
> +   4201 4181 4201 4207 4187
> +   4153 4133 4150 4155 4135
> +   4105 4085 4100 4104 4084
> +   4058 4038 4052 4058 4038
> +   4012 3992 4004 4014 3994
> +   3970 3950 3959 3971 3951
> +   3931 3911 3915 3927 3907
> +   3899 3879 3880 3884 3864
> +   3873 3853 3851 3853 3833
> +   3848 3828 3827 3829 3809
> +   3829 3809 3808 3809 3789
> +   3815 3795 3791 3791 3771
>

Compliment of the day

2018-04-13 Thread Tracy William




--

Hi dear.
It is wonderful to contact you, I want us to have correspondence. I
wish you will have the desire so that we can get acquainted to each
other. Life itself is a mystery, you never know where it might lead
you.
I'm Tracy.William, a French American . I will be pleased if you reply
through.(tracy.medce...@outlook.com)
With Love
Tracy
--

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

2018-04-13 Thread Linus Torvalds

On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux
 wrote:
>
> Yes, it does solve the problem at hand with strace - the exact patch I
> tested against 4.16 is below.

Ok, good.

> However, FPE_FLTUNK is not defined in older kernels, so while we can
> fix it this way for the current merge window, that doesn't help 4.16.

I wonder if we should even bother with FPE_FLTUNK.

I suspect we might as well use FPE_FLTINV, I suspect, and not have
this complexity at all. That case is not worth worrying about, since
it's a "this shouldn't happen anyway" and the *real* reason will be in
the kernel logs due to vfs_panic().

So it's not like this is something that the user should ever care
about the si_code about.

> Given that the path we're talking about is unlikely to happen (as
> mentioned in my second paragraph) I still think reverting Eric's patch
> is the right way forward for older kernels.

I'd much rather get rid of that FPE_FIXME, and leave that whole mess behind.

So the attached patch seems simple and should work with 4.16 too.

Let's not leave this as some kind of nasty maintenance issue, and just
go for simple and stupid.

Hmm?

Linus
 arch/arm/include/uapi/asm/siginfo.h | 13 -
 arch/arm/vfp/vfpmodule.c|  2 +-
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/arch/arm/include/uapi/asm/siginfo.h b/arch/arm/include/uapi/asm/siginfo.h
deleted file mode 100644
index d0513880be21..
--- a/arch/arm/include/uapi/asm/siginfo.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef __ASM_SIGINFO_H
-#define __ASM_SIGINFO_H
-
-#include 
-
-/*
- * SIGFPE si_codes
- */
-#ifdef __KERNEL__
-#define FPE_FIXME	0	/* Broken dup of SI_USER */
-#endif /* __KERNEL__ */
-
-#endif
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 4c375e11ae95..af4ee2cef2f9 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -257,7 +257,7 @@ static void vfp_raise_exceptions(u32 exceptions, u32 inst, u32 fpscr, struct pt_
 
 	if (exceptions == VFP_EXCEPTION_ERROR) {
 		vfp_panic("unhandled bounce", inst);
-		vfp_raise_sigfpe(FPE_FIXME, regs);
+		vfp_raise_sigfpe(FPE_FLTINV, regs);
 		return;
 	}

Re: [PATCH RFC 7/8] mm: allow to control onlining/offlining of memory by a driver

2018-04-13 Thread David Hildenbrand

On 13.04.2018 17:59, Michal Hocko wrote:
> On Fri 13-04-18 15:33:28, David Hildenbrand wrote:
>> Some devices (esp. paravirtualized) might want to control
>> - when to online/offline a memory block
>> - how to online memory (MOVABLE/NORMAL)
>> - in which granularity to online/offline memory
>>
>> So let's add a new flag "driver_managed" and disallow to change the
>> state by user space. Device onlining/offlining will still work, however
>> the memory will not be actually onlined/offlined. That has to be handled
>> by the device driver that owns the memory.
> 
> Is there any reason to create the memblock sysfs interface to this
> memory at all? ZONE_DEVICE mem hotplug users currently do not do that
> and manage the memory themselves. It seems you want to achieve the same
> thing, no?
> 

Yes, I think so, namely kdump. We have to retrigger kexec() whenever a
memory block is added/removed. udev events are sent for that reason when
a memory block is created/deleted. And I think this is not done for
ZONE_DEVICE devices, or am I wrong?

-- 

Thanks,

David / dhildenb

Re: [PATCH] base: dma-mapping: Postpone cpu addr translation on mmap()

2018-04-13 Thread jacopo mondi

Hello again,

On Tue, Apr 10, 2018 at 09:57:52AM +0200, jacopo mondi wrote:
> Hi Christoph,
>
> On Mon, Apr 09, 2018 at 10:52:51AM -0700, Christoph Hellwig wrote:
> > On Mon, Apr 09, 2018 at 06:59:08PM +0200, Jacopo Mondi wrote:
> > > I'm still a bit puzzled on what happens if dma_mmap_from_dev_coherent() 
> > > fails.
> > > Does a dma_mmap_from_dev_coherent() failure guarantee anyhow that the
> > > successive virt_to_page() isn't problematic as it is today?
> > > Or is it the
> > >   if (off < count && user_count <= (count - off))
> > > check that makes the translation safe?
> >
> > It doesn't.  I think one major issue is that we should not simply fall
> > to dma_common_mmap if no method is required, but need every instance of
> > dma_map_ops to explicitly opt into an mmap method that is known to work.
>
> I see.. this patch thus just postpones the problem...
>
> >
> > >  #ifndef CONFIG_ARCH_NO_COHERENT_DMA_MMAP
> > >   unsigned long user_count = vma_pages(vma);
> > >   unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> > > - unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
> > >   unsigned long off = vma->vm_pgoff;
> > > + unsigned long pfn;
> > >
> > >   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > >
> > > @@ -235,6 +235,7 @@ int dma_common_mmap(struct device *dev, struct 
> > > vm_area_struct *vma,
> > >   return ret;
> > >
> > >   if (off < count && user_count <= (count - off)) {
> > > + pfn = page_to_pfn(virt_to_page(cpu_addr));
> > >   ret = remap_pfn_range(vma, vma->vm_start,
> > > pfn + off,
> > > user_count << PAGE_SHIFT,
> >
> > Why not:
> >
> > ret = remap_pfn_range(vma, vma->vm_start,
> > page_to_pfn(virt_to_page(cpu_addr)) + off,
> >
> > and save the temp variable?
>
> Sure, it's better... Should I send a v2 or considering your above
> comment this patch is just a mitigation and should be ditched in
> favour of a proper solution (which requires a much more considerable amount
> of work though)?

Don't want to be insistent, but I didn't get from your reply if a v2
is welcome or not :)

Thanks
  j


signature.asc
Description: PGP signature

Re: [PATCH v8 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver

2018-04-13 Thread jacopo mondi

Hello,
   small self review, as I've just noticed a trivial error.

On Tue, Apr 10, 2018 at 12:53:10PM +0200, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output converter.
>
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 
> ---
>  drivers/gpu/drm/bridge/Kconfig|   6 +
>  drivers/gpu/drm/bridge/Makefile   |   1 +
>  drivers/gpu/drm/bridge/thc63lvd1024.c | 206 
> ++
>  3 files changed, 213 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3aa65bd..42c9c2d 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -93,6 +93,12 @@ config DRM_SII9234
> It is an I2C driver, that detects connection of MHL bridge
> and starts encapsulation of HDMI signal.
>
> +config DRM_THINE_THC63LVD1024
> + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> + depends on OF
> + ---help---
> +   Thine THC63LVD1024 LVDS/parallel converter driver.
> +
>  config DRM_TOSHIBA_TC358767
>   tristate "Toshiba TC358767 eDP bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 373eb28..fd90b16 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>  obj-$(CONFIG_DRM_SII9234) += sii9234.o
> +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> new file mode 100644
> index 000..aa1d650
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -0,0 +1,206 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> + *
> + * Copyright (C) 2018 Jacopo Mondi 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +enum thc63_ports {
> + THC63_LVDS_IN0,
> + THC63_LVDS_IN1,
> + THC63_RGB_OUT0,
> + THC63_RGB_OUT1,
> +};
> +
> +struct thc63_dev {
> + struct device *dev;
> +
> + struct regulator *vcc;
> +
> + struct gpio_desc *pdwn;
> + struct gpio_desc *oe;
> +
> + struct drm_bridge bridge;
> + struct drm_bridge *next;
> +};
> +
> +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct thc63_dev, bridge);
> +}
> +
> +static int thc63_attach(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> +
> + return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> +}
> +
> +static void thc63_enable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + int ret;
> +
> + ret = regulator_enable(thc63->vcc);
> + if (ret) {
> + dev_err(thc63->dev,
> + "Failed to enable regulator \"vcc\": %d\n", ret);
> + return;
> + }
> +
> + gpiod_set_value(thc63->pdwn, 0);
> + gpiod_set_value(thc63->oe, 1);
> +}
> +
> +static void thc63_disable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + int ret;
> +
> + gpiod_set_value(thc63->oe, 0);
> + gpiod_set_value(thc63->pdwn, 1);
> +
> + ret = regulator_disable(thc63->vcc);
> + if (ret)
> + dev_err(thc63->dev,
> + "Failed to disable regulator \"vcc\": %d\n", ret);
> +}
> +
> +static const struct drm_bridge_funcs thc63_bridge_func = {
> + .attach = thc63_attach,
> + .enable = thc63_enable,
> + .disable = thc63_disable,
> +};
> +
> +static int thc63_parse_dt(struct thc63_dev *thc63)
> +{
> + struct device_node *thc63_out;
> + struct device_node *remote;
> +
> + thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
> +   THC63_RGB_OUT0, -1);
> + if (!thc63_out) {
> + dev_err(thc63->dev, "Missing endpoint in port@%u\n",
> + THC63_RGB_OUT0);
> + return -ENODEV;
> + }
> +
> + remote = of_graph_get_remote_port_parent(thc63_out);
> + of_node_put(thc63_out);
> + if (!remote) {
> + dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
> + THC63_RGB_OUT0);
> + return -ENODEV;
> + }
> +
> + if (!of_device_is_available(remote)) {
> + dev_err(thc63->dev, "port@%u remote endpoint is disabled\n",
> + THC63_RGB_OUT0);
> + of_node_put(remote);
> + return -ENO

Re: [PATCH v1 2/7] platform/mellanox: mlxreg-hotplug: Document fixes for hotplug private data

On Tue, Mar 27, 2018 at 10:02:02AM +, Vadim Pasternak wrote:
> Add missing description of dev, regmap, dwork_irq, after_probe in struct
> mlxreg_hotplug_priv_data.
> 
> Remove dwork field from the structure mlxreg_hotplug_priv_data itself and
> for the descriptions, since it is not used.
> 

A bit of a nit, but "Document..." implies no functional changes, but you are
changing the physical structure. This can have negative consequences in some
cases, even if the removed field is unused.

Someone reading through the git history might skip over patches starting with
"Document..." when looking for change which impacted behavior.

Again, for future submissions.

> Signed-off-by: Vadim Pasternak 
> ---
>  drivers/platform/mellanox/mlxreg-hotplug.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c 
> b/drivers/platform/mellanox/mlxreg-hotplug.c
> index ea9e7f4..b56953a 100644
> --- a/drivers/platform/mellanox/mlxreg-hotplug.c
> +++ b/drivers/platform/mellanox/mlxreg-hotplug.c
> @@ -59,9 +59,11 @@
>  /**
>   * struct mlxreg_hotplug_priv_data - platform private data:
>   * @irq: platform device interrupt number;
> + * @dev: basic device;
>   * @pdev: platform device;
>   * @plat: platform data;
> - * @dwork: delayed work template;
> + * @regmap: register map handle;
> + * @dwork_irq: delayed work template;
>   * @lock: spin lock;
>   * @hwmon: hwmon device;
>   * @mlxreg_hotplug_attr: sysfs attributes array;
> @@ -71,6 +73,7 @@
>   * @cell: location of top aggregation interrupt register;
>   * @mask: top aggregation interrupt common mask;
>   * @aggr_cache: last value of aggregation register status;
> + * @after_probe: flag indication probing completion;
>   */
>  struct mlxreg_hotplug_priv_data {
>   int irq;
> @@ -79,7 +82,6 @@ struct mlxreg_hotplug_priv_data {
>   struct mlxreg_hotplug_platform_data *plat;
>   struct regmap *regmap;
>   struct delayed_work dwork_irq;
> - struct delayed_work dwork;
>   spinlock_t lock; /* sync with interrupt */
>   struct device *hwmon;
>   struct attribute *mlxreg_hotplug_attr[MLXREG_HOTPLUG_ATTRS_MAX + 1];
> -- 
> 2.1.4
> 
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH v2 14/17] kvm: arm64: Switch to per VM IPA limit

2018-04-13 Thread Punit Agrawal

Hi Suzuki,

I haven't had a chance to look at the code but noticed one issue below.

Suzuki K Poulose  writes:

> Now that we can manage the stage2 page table per VM, switch the
> configuration details to per VM instance. We keep track of the
> IPA bits, number of page table levels and the VTCR bits (which
> depends on the IPA and the number of levels). While at it, remove
> unused pgd_lock field from kvm_arch for arm64.
>
> Cc: Marc Zyngier 
> Cc: Christoffer Dall 
> Signed-off-by: Suzuki K Poulose 
> ---
>  arch/arm64/include/asm/kvm_host.h   | 14 --
>  arch/arm64/include/asm/kvm_mmu.h| 11 +--
>  arch/arm64/include/asm/stage2_pgtable.h |  1 -
>  arch/arm64/kvm/hyp/switch.c |  3 +--
>  virt/kvm/arm/mmu.c  |  4 
>  5 files changed, 26 insertions(+), 7 deletions(-)
>

[...]

> diff --git a/arch/arm64/include/asm/kvm_mmu.h 
> b/arch/arm64/include/asm/kvm_mmu.h
> index bb458bf..e86d7f4 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -136,9 +136,10 @@ static inline unsigned long __kern_hyp_va(unsigned long 
> v)
>   */
>  #define KVM_PHYS_SHIFT   (40)
>  
> -#define kvm_phys_shift(kvm)  KVM_PHYS_SHIFT
> +#define kvm_phys_shift(kvm)  (kvm->arch.phys_shift)
>  #define kvm_phys_size(kvm)   (_AC(1, ULL) << kvm_phys_shift(kvm))
>  #define kvm_phys_mask(kvm)   (kvm_phys_size(kvm) - _AC(1, ULL))
> +#define kvm_stage2_levels(kvm)   (kvm->arch.s2_levels)
>  
>  static inline bool kvm_page_empty(void *ptr)
>  {

[...]

> diff --git a/arch/arm64/include/asm/stage2_pgtable.h 
> b/arch/arm64/include/asm/stage2_pgtable.h
> index 33e8ebb..9b75b83 100644
> --- a/arch/arm64/include/asm/stage2_pgtable.h
> +++ b/arch/arm64/include/asm/stage2_pgtable.h
> @@ -44,7 +44,6 @@
>   */
>  #define __s2_pgd_ptrs(pa, lvls)  (1 << ((pa) - 
> pt_levels_pgdir_shift((lvls
>  
> -#define kvm_stage2_levels(kvm)   
> stage2_pt_levels(kvm_phys_shift(kvm))
>  #define stage2_pgdir_shift(kvm)  \
>   pt_levels_pgdir_shift(kvm_stage2_levels(kvm))
>  #define stage2_pgdir_size(kvm)   (_AC(1, UL) << 
> stage2_pgdir_shift((kvm)))

[...]

> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 7a264c6..746f38e 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -753,6 +753,10 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm)
>   return -EINVAL;
>   }
>  
> + /* Make sure we have the stage2 configured for this VM */
> + if (WARN_ON(!kvm_stage2_levels(kvm)))
> + return -EINVAL;
> +

This hunk breaks the 32-bit build as kvm_stag2_levels() isn't defined on
arm.

Thanks,
Punit

>   /* Allocate the HW PGD, making sure that each page gets its own 
> refcount */
>   pgd = alloc_pages_exact(stage2_pgd_size(kvm), GFP_KERNEL | __GFP_ZERO);
>   if (!pgd)

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

2018-04-13 Thread Daniel Thompson

On Fri, Apr 13, 2018 at 06:08:24PM +0200, Daniel Vetter wrote:
> On Wed, Apr 11, 2018 at 09:32:16AM +0200, Simon Horman wrote:
> > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> > > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> > > ("gpio: correct docs about return value of gpiod_get_direction"). Now,
> > > fix this user (until a better, system-wide solution is in place).
> > > 
> > > Signed-off-by: Wolfram Sang 
> > > Acked-by: Daniel Thompson 
> > 
> > Reviewed-by: Simon Horman 
> > 
> > > ---
> > > 
> > > Changes since V1:
> > >   * rebased to top-of-linus-tree
> > >   * added tag from Daniel, thanks!
> > > 
> > > Through which tree does this need to go?
> 
> I think Daniel Thompson has one ...

Sorry, I didn't spot the question at the bottom of the change block. 
For backlight patches generally go though Lee Jones' tree.


Daniel.

Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support

2018-04-13 Thread Mimi Zohar

[Cc'ing John Johansen]

On Tue, 2018-03-27 at 18:01 -0500, Eric W. Biederman wrote:
[...]
> As such I expect the best way to create the ima namespace is by simply
> writing to securityfs/imafs.  Possibly before the user namespace is
> even unshared.  That would allow IMA to keep track of things from
> before a container is created.

My initial thought was to stage IMA namespacing with just IMA-audit
first, followed by either IMA-measurement or IMA-appraisal.  This
would allow us to get the basic IMA namespacing framework working and
defer dealing with the securityfs related namespacing of the IMA
policy and measurement list issues to later.

By tying IMA namespacing to a securityfs ima/unshare file, we would
need to address the securityfs issues first.

Mimi

Re: [PATCH ipmi/kcs_bmc v1] ipmi: add an NPCM7xx KCS BMC driver

2018-04-13 Thread Wang, Haiyue


Thanks, Corey.

BR,

Haiyue


On 2018-04-13 23:56, Corey Minyard wrote:

On 03/22/2018 07:50 AM, Haiyue Wang wrote:

This driver exposes the Keyboard Controller Style (KCS) interface on
Novoton NPCM7xx SoCs as a character device. Such SOCs are commonly used
as a BaseBoard Management Controller (BMC) on a server board, and KCS
interface is commonly used to perform the in-band IPMI communication
between the server and its BMC.


Sorry, I missed this.  It is queued for the next kernel release.

Thanks,

-corey

Re: [PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode

2018-04-13 Thread Alexandre Belloni

On 13/04/2018 19:11:16+0300, Radu Pirea wrote:
> These are bindings for at91-usart IP in spi spi mode. There is no support for
> internal chip select. Only kind of chip selects available are gpio chip
> selects.
> 
> Signed-off-by: Radu Pirea 
> ---
>  .../bindings/spi/microchip,at91-usart-spi.txt | 24 +++
>  1 file changed, 24 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt 
> b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
> new file mode 100644
> index ..92d33ccdffae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
> @@ -0,0 +1,24 @@
> +* Universal Synchronous Asynchronous Receiver/Transmitter (USART) in SPI mode
> +
> +Required properties:
> +- #size-cells  : Must be <0>
> +- #address-cells   : Must be <1>
> +- compatible: Should be "microchip,at91sam9g45-usart-spi" or 
> "microchip,sama5d2-usart-spi" 
> +- reg: Should contain registers location and length
> +- interrupts: Should contain interrupt
> +- clocks: phandles to input clocks.
> +- clock-names: tuple listing input clock names.
> + Required elements: "usart"
> +- cs-gpios: chipselects (internal cs not supported)
> +
> +Example:
> + spi0: spi@f001c000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "microchip,sama5d2-usart-spi", 
> "microchip,at91sam9g45-usart-spi";

I'm pretty sure this will be considered configuration rather than
hardware description. Why don't you do something like the flexcom mode
selection?

> + reg = <0xf001c000 0x100>;
> + interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&usart0_clk>;
> + clock-names = "usart";
> + cs-gpios = <&pioB 3 0>;
> + };
> -- 
> 2.17.0
> 

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v1 1/7] platform_data/mlxreg: Document fixes for hotplug device

On Tue, Mar 27, 2018 at 10:02:01AM +, Vadim Pasternak wrote:
> Remove redunadant description of label in struct mlxreg_hotplug_device.

 ^ redundant

Please configure a spell checker in your text editor. I take care of
these for first time contributors, but as you become a regular
contributor, I shouldn't need to rewrite your commit messages.

I'll handle this one, but please adapt your tooling for future patches.

> 
> Change location of access_mode in struct mlxreg_hotplug_device.
> 
> Signed-off-by: Vadim Pasternak 
> ---
>  include/linux/platform_data/mlxreg.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/include/linux/platform_data/mlxreg.h 
> b/include/linux/platform_data/mlxreg.h
> index 2744cff..19f5cb61 100644
> --- a/include/linux/platform_data/mlxreg.h
> +++ b/include/linux/platform_data/mlxreg.h
> @@ -58,11 +58,10 @@ struct mlxreg_hotplug_device {
>   * struct mlxreg_core_data - attributes control data:
>   *
>   * @label: attribute label;
> - * @label: attribute register offset;
>   * @reg: attribute register;
>   * @mask: attribute access mask;
> - * @mode: access mode;
>   * @bit: attribute effective bit;
> + * @mode: access mode;
>   * @np - pointer to node platform associated with attribute;
>   * @hpdev - hotplug device data;
>   * @health_cntr: dynamic device health indication counter;
> -- 
> 2.1.4
> 
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 17/17] perf annotate: Handle variables in 'sub', 'or' and many other instructions

2018-04-13 Thread Andi Kleen

On Fri, Apr 13, 2018 at 11:01:11AM -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo 
> 
> Just like is done for 'mov' and others that can have as source or
> targets variables resolved by objdump, to make them more compact:
> 
> -   orb$0x4,0x224d71(%rip)# 226ca4 
> <_rtld_global+0xca4>
> +   orb$0x4,_rtld_global+0xca4

That's not equivalent.  It could be non rip relative too. You would need
to keep at least the (%rip).

-Andi

Re: [PATCH v1 0/7] platform/x86: Mellanox add fixes and new features

On Tue, Mar 27, 2018 at 10:02:00AM +, Vadim Pasternak wrote:
> This patcheset includes:
> 
> Document fixes for mlxreg-hotplug driver and mlxreg header file.
> 
> Fix for the race condition in mlxreg-hotplug driver.
> 
> Adding support for ODM system types.
> 
> Activation of Mellanox LED driver from mlx-platform.
> 
> Introduction of new mlxreg-io driver.
> 
> Activation of mlxreg-io driver from mlx-platform.

Hi Vadim,

As you can see, all the patch names you listed above ^ are automatically
populated by the tooling below. Please use the message in patch 0/7 to
provide the reviewer with contextual information about these changes. A
summary of the series and why its needed is a good start. You want to
keep specific information to each patch with the patch. Think of this as
an Introduction to help the reviewer be prepared to review each
individual patch.

This message provides no context, and no introduction, so a reviewer
will have to figure that out as they go - which is another barrier to
getting the code reviewed.

Something for next time. OK, on to the review...

> 
> Vadim Pasternak (7):
>   platform_data/mlxreg: Document fixes for hotplug device
>   platform/mellanox: mlxreg-hotplug: Document fixes for hotplug private
> data
>   platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work
> queue
>   platform: mellanox: add new ODM system types to mlx-platform
>   platform/x86: mlx-platform: Add LED platform driver activation
>   platform/mellanox: Introduce support for Mellanox register access
> driver
>   platform/x86: mlx-platform: Add mlxreg-io platform driver activation
> 
>  drivers/platform/mellanox/Kconfig  |  11 +
>  drivers/platform/mellanox/Makefile |   1 +
>  drivers/platform/mellanox/mlxreg-hotplug.c |  23 +-
>  drivers/platform/mellanox/mlxreg-io.c  | 221 ++
>  drivers/platform/x86/mlx-platform.c| 447 
> +
>  include/linux/platform_data/mlxreg.h   |  66 -
>  6 files changed, 765 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/platform/mellanox/mlxreg-io.c
> 
> -- 
> 2.1.4
> 
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

2018-04-13 Thread Jann Horn

On Fri, Apr 13, 2018 at 6:05 PM, Jann Horn  wrote:
> On Fri, Apr 13, 2018 at 6:04 PM, Michal Hocko  wrote:
>> On Fri 13-04-18 17:04:09, Jann Horn wrote:
>>> On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko  wrote:
>>> > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote:
>>> > [...]
>>> >> So, you mean remove this entire paragraph:
>>> >>
>>> >>   For cases in which the specified memory region has not been
>>> >>   reserved using an existing mapping,  newer  kernels  (Linux
>>> >>   4.17  and later) provide an option MAP_FIXED_NOREPLACE that
>>> >>   should be used instead; older kernels require the caller to
>>> >>   use addr as a hint (without MAP_FIXED) and take appropriate
>>> >>   action if the kernel places the new mapping at a  different
>>> >>   address.
>>> >>
>>> >> It seems like some version of the first half of the paragraph is worth
>>> >> keeping, though, so as to point the reader in the direction of a remedy.
>>> >> How about replacing that text with the following:
>>> >>
>>> >>   Since  Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used
>>> >>   in a multithreaded program to avoid  the  hazard  described
>>> >>   above.
>>> >
>>> > Yes, that sounds reasonable to me.
>>>
>>> But that kind of sounds as if you can't avoid it before Linux 4.17,
>>> when actually, you just have to call mmap() with the address as hint,
>>> and if mmap() returns a different address, munmap() it and go on your
>>> normal error path.
>>
>> This is still racy in multithreaded application which is the main point
>> of the whole section, no?
>
> No, it isn't.

mmap() with a hint (without MAP_FIXED) will always non-racily allocate
a memory region for you or return an error code. If it does allocate a
memory region, it belongs to you until you deallocate it. It might be
at a different address than you requested - in that case you can
emulate MAP_FIXED_NOREPLACE by calling munmap() and treating it as an
error; or you can do something else with it.

MAP_FIXED_NOREPLACE is just a performance optimization.

Re: [PATCH v5 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

2018-04-13 Thread Lina Iyer


On Tue, Apr 10 2018 at 17:40 -0600, Bjorn Andersson wrote:

On Thu 05 Apr 09:18 PDT 2018, Lina Iyer wrote:
[..]

diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h

[..]

+/**
+ * struct tcs_response: Response object for a request
+ *
+ * @drv:   the controller
+ * @msg:   the request for this response
+ * @m: the tcs identifier
+ * @err:   error reported in the response
+ * @list:  element in list of pending response objects
+ */
+struct tcs_response {
+   struct rsc_drv *drv;
+   const struct tcs_request *msg;
+   u32 m;


m is assigned in one place but never used.


Right. Remnant from the downstream driver that uses buffers of
responses.


+   int err;
+   struct list_head list;
+};

[..]

diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c

[..]

+static struct tcs_group *get_tcs_from_index(struct rsc_drv *drv, int m)
+{
+   struct tcs_group *tcs;
+   int i;
+
+   for (i = 0; i < drv->num_tcs; i++) {
+   tcs = &drv->tcs[i];
+   if (tcs->mask & BIT(m))
+   return tcs;
+   }
+
+   WARN(i == drv->num_tcs, "Incorrect TCS index %d", m);
+
+   return NULL;
+}
+
+static struct tcs_response *setup_response(struct rsc_drv *drv,
+  const struct tcs_request *msg, int m)
+{
+   struct tcs_response *resp;
+   struct tcs_group *tcs;
+
+   resp = kzalloc(sizeof(*resp), GFP_ATOMIC);


I still don't like the idea that you allocate a response struct for each
request, then upon getting an ack post this on a list and schedule a
tasklet in order to optionally deliver the return value to the waiting
caller.

Why don't you just just add the "err" and a completion to the
tcs_request struct and if it's a sync operation you complete that in
your irq handler?

That would remove the response struct, the list of them, the tasklet and
the dynamic memory handling - at the "cost" of making the code possible
to follow.


Hmm.. Ok. Will try to simplify.


+   if (!resp)
+   return ERR_PTR(-ENOMEM);
+
+   resp->drv = drv;
+   resp->msg = msg;
+   resp->err = 0;
+
+   tcs = get_tcs_from_index(drv, m);
+   if (!tcs)
+   return ERR_PTR(-EINVAL);
+
+   assert_spin_locked(&tcs->lock);


I tried to boot the kernel with the rpmh-clk and rpmh-regulator drivers
and I kept hitting this assert.

Turns out that find_free_tcs() finds an empty TCS with index 'm' within
the tcs, then passes it to setup_response() which tries to use the 'm'
to figure out which tcs contains the TCS we're operating on.

But as 'm' is in tcs-local space and get_tcs_from_index() tries to
lookup the TCS in the global drv space we get hold of the wrong TCS.


You are right. I will fix it. Thanks for point out. Wonder what is in
your DT, that caused this to be triggered. Clearly it's missing my
setup.


+   tcs->responses[m - tcs->offset] = resp;
+
+   return resp;
+}
+
+static void free_response(struct tcs_response *resp)
+{
+   kfree(resp);
+}
+
+static struct tcs_response *get_response(struct rsc_drv *drv, u32 m)
+{
+   struct tcs_group *tcs = get_tcs_from_index(drv, m);
+
+   return tcs->responses[m - tcs->offset];
+}
+
+static u32 read_tcs_reg(struct rsc_drv *drv, int reg, int m, int n)
+{
+   return readl_relaxed(drv->tcs_base + reg + RSC_DRV_TCS_OFFSET * m +
+RSC_DRV_CMD_OFFSET * n);
+}
+
+static void write_tcs_reg(struct rsc_drv *drv, int reg, int m, int n, u32 data)
+{
+   writel_relaxed(data, drv->tcs_base + reg + RSC_DRV_TCS_OFFSET * m +
+  RSC_DRV_CMD_OFFSET * n);


Do you really want this relaxed? Isn't the ordering of these
significant?


The ordering isnt. I can make it not relaxed. Only ordering requirement
is that we tigger after writing everything.


+}
+
+static void write_tcs_reg_sync(struct rsc_drv *drv, int reg, int m, int n,
+  u32 data)
+{
+   write_tcs_reg(drv, reg, m, n, data);
+   for (;;) {
+   if (data == read_tcs_reg(drv, reg, m, n))
+   break;
+   udelay(1);
+   }
+}
+
+static bool tcs_is_free(struct rsc_drv *drv, int m)
+{
+   return !test_bit(m, drv->tcs_in_use) &&
+  read_tcs_reg(drv, RSC_DRV_STATUS, m, 0);
+}
+
+static struct tcs_group *get_tcs_of_type(struct rsc_drv *drv, int type)


According to rpmh_rsc_probe() the tcs array is indexed by "type", so you
can replace the entire function with:

return &drv->tcs[type];


Hmm. Ok.


+{
+   int i;
+   struct tcs_group *tcs;
+
+   for (i = 0; i < TCS_TYPE_NR; i++) {
+   if (type == drv->tcs[i].type)
+   break;
+   }
+
+   if (i == TCS_TYPE_NR)
+   return ERR_PTR(-EINVAL);
+
+   tcs = &drv->tcs[i];
+   if (!tcs->num_tcs)
+   return ERR_PTR(-EINVAL);
+
+   return tcs;
+}
+
+static struct

[PATCH] drm/amdgpu/acp: Fix slab-out-of-bounds in mfd_add_device in acp_hw_init

2018-04-13 Thread Daniel Kurtz

Commit 51f7415039d4 ("drm/amd/amdgpu: creating two I2S instances for
stoney/cz") added support for the "BT_I2S" ACP i2s channel.  As part of
this change, one additional acp resource was added, but the "num_resource"
count was accidentally incremented by 2.

This incorrect count eventually causes mfd_add_device() to try to access
an invalid memory address (the location of non-existent resource 5.

This fault was detected by running a KASAN enabled kernel, which produced
the following splat at boot:

[6.612987] 
==
[6.613509] BUG: KASAN: slab-out-of-bounds in mfd_add_device+0x4bc/0x7a7
[6.613509] Read of size 8 at addr 880107d4dc58 by task swapper/0/1
[6.613509]
[6.613509] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.33 #349
[6.613509] Hardware name: Google Grunt/Grunt, BIOS 
Google_Grunt.10543.0.2018_04_03_1812 04/02/2018
[6.613509] Call Trace:
[6.613509]  dump_stack+0x4d/0x63
[6.613509]  print_address_description+0x80/0x2d6
[6.613509]  ? mfd_add_device+0x4bc/0x7a7
[6.613509]  kasan_report+0x255/0x295
[6.613509]  mfd_add_device+0x4bc/0x7a7
[6.613509]  ? kasan_kmalloc+0x99/0xa8
[6.613509]  ? mfd_add_devices+0x58/0xe4
[6.613509]  ? __kmalloc+0x154/0x178
[6.613509]  mfd_add_devices+0xa5/0xe4
[6.613509]  acp_hw_init+0x92e/0xc4a
[6.613509]  amdgpu_device_init+0x1dfb/0x22a2
[6.613509]  ? kmalloc_order+0x53/0x5d
[6.613509]  ? kmalloc_order_trace+0x23/0xb3
[6.613509]  amdgpu_driver_load_kms+0xce/0x267
[6.613509]  drm_dev_register+0x169/0x2fb
[6.613509]  amdgpu_pci_probe+0x217/0x242
[6.613509]  pci_device_probe+0x101/0x18e
[6.613509]  driver_probe_device+0x1dd/0x419
[6.613509]  ? ___might_sleep+0x80/0x1b6
[6.613509]  __driver_attach+0x9f/0xc9
[6.613509]  ? driver_probe_device+0x419/0x419
[6.613509]  bus_for_each_dev+0xbc/0xe1
[6.613509]  bus_add_driver+0x189/0x2c0
[6.613509]  driver_register+0x108/0x156
[6.613509]  ? ttm_init+0x67/0x67
[6.613509]  do_one_initcall+0xb2/0x161
[6.613509]  kernel_init_freeable+0x25a/0x308
[6.613509]  ? rest_init+0xcc/0xcc
[6.613509]  kernel_init+0x11/0x10d
[6.613509]  ? rest_init+0xcc/0xcc
[6.613509]  ret_from_fork+0x22/0x40
[6.613509]
[6.613509] Allocated by task 1:
[6.613509]  save_stack+0x46/0xce
[6.613509]  kasan_kmalloc+0x99/0xa8
[6.613509]  kmem_cache_alloc_trace+0x11a/0x13e
[6.613509]  acp_hw_init+0x210/0xc4a
[6.613509]  amdgpu_device_init+0x1dfb/0x22a2
[6.613509]  amdgpu_driver_load_kms+0xce/0x267
[6.613509]  drm_dev_register+0x169/0x2fb
[6.613509]  amdgpu_pci_probe+0x217/0x242
[6.613509]  pci_device_probe+0x101/0x18e
[6.613509]  driver_probe_device+0x1dd/0x419
[6.613509]  __driver_attach+0x9f/0xc9
[6.613509]  bus_for_each_dev+0xbc/0xe1
[6.613509]  bus_add_driver+0x189/0x2c0
[6.613509]  driver_register+0x108/0x156
[6.613509]  do_one_initcall+0xb2/0x161
[6.613509]  kernel_init_freeable+0x25a/0x308
[6.613509]  kernel_init+0x11/0x10d
[6.613509]  ret_from_fork+0x22/0x40
[6.613509]
[6.613509] Freed by task 0:
[6.613509] (stack is not available)
[6.613509]
[6.613509] The buggy address belongs to the object at 880107d4db08
[6.613509]  which belongs to the cache kmalloc-512 of size 512
[6.613509] The buggy address is located 336 bytes inside of
[6.613509]  512-byte region [880107d4db08, 880107d4dd08)
[6.613509] The buggy address belongs to the page:
[6.613509] page:ea00041f5300 count:1 mapcount:0 mapping:  
(null) index:0x0 compound_mapcount: 0
[6.613509] flags: 0x80008100(slab|head)
[6.613509] raw: 80008100   
000100120012
[6.613509] raw: ea0004208520 88010b001680 88010b002cc0 

[6.613509] page dumped because: kasan: bad access detected
[6.613509]
[6.613509] Memory state around the buggy address:
[6.613509]  880107d4db00: fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[6.613509]  880107d4db80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[6.613509] >880107d4dc00: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc 
fc
[6.613509] ^
[6.613509]  880107d4dc80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[6.613509]  880107d4dd00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[6.613509] 
==

Fixes: 51f7415039d4 ("drm/amd/amdgpu: creating two I2S instances for stoney/cz")
Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
index 20f20079935b..42f0d60cf3f4 100644
--- a/drivers/gpu/drm/amd/amdgpu

[PATCH 1/6] fs: use << for MS_* flags

Consistenly use << to define MS_* constants.

Signed-off-by: Christian Brauner 
---
 include/uapi/linux/fs.h | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index d2a8313fabd7..9662790a657c 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -105,22 +105,23 @@ struct inodes_stat_t {
 /*
  * These are the fs-independent mount-flags: up to 32 flags are supported
  */
-#define MS_RDONLY   1  /* Mount read-only */
-#define MS_NOSUID   2  /* Ignore suid and sgid bits */
-#define MS_NODEV4  /* Disallow access to device special files */
-#define MS_NOEXEC   8  /* Disallow program execution */
-#define MS_SYNCHRONOUS 16  /* Writes are synced at once */
-#define MS_REMOUNT 32  /* Alter flags of a mounted FS */
-#define MS_MANDLOCK64  /* Allow mandatory locks on an FS */
-#define MS_DIRSYNC 128 /* Directory modifications are synchronous */
-#define MS_NOATIME 1024/* Do not update access times. */
-#define MS_NODIRATIME  2048/* Do not update directory access times */
-#define MS_BIND4096
-#define MS_MOVE8192
-#define MS_REC 16384
-#define MS_VERBOSE 32768   /* War is peace. Verbosity is silence.
-  MS_VERBOSE is deprecated. */
-#define MS_SILENT  32768
+#define MS_RDONLY  (1<<0)  /* Mount read-only */
+#define MS_NOSUID  (1<<1)  /* Ignore suid and sgid bits */
+#define MS_NODEV   (1<<2)  /* Disallow access to device special files */
+#define MS_NOEXEC  (1<<3)  /* Disallow program execution */
+#define MS_SYNCHRONOUS (1<<4)  /* Writes are synced at once */
+#define MS_REMOUNT (1<<5)  /* Alter flags of a mounted FS */
+#define MS_MANDLOCK(1<<6)  /* Allow mandatory locks on an FS */
+#define MS_DIRSYNC (1<<7)  /* Directory modifications are synchronous */
+#define MS_NOATIME (1<<10) /* Do not update access times. */
+#define MS_NODIRATIME  (1<<11) /* Do not update directory access times */
+#define MS_BIND(1<<12)
+#define MS_MOVE(1<<13)
+#define MS_REC (1<<14)
+#define MS_VERBOSE (1<<15) /* War is peace. Verbosity is silence.
+* MS_VERBOSE is deprecated.
+*/
+#define MS_SILENT  (1<<15)
 #define MS_POSIXACL(1<<16) /* VFS does not apply the umask */
 #define MS_UNBINDABLE  (1<<17) /* change to unbindable */
 #define MS_PRIVATE (1<<18) /* change to private */
-- 
2.17.0

[PATCH 3/6] statfs: add ST_UNBINDABLE

This lets userspace query whether a mountpoint was made MS_UNBINDABLE.

Signed-off-by: Christian Brauner 
---
 fs/statfs.c| 2 ++
 include/linux/statfs.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/fs/statfs.c b/fs/statfs.c
index 5b2a24f0f263..61b3063d3921 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -29,6 +29,8 @@ static int flags_by_mnt(int mnt_flags)
flags |= ST_NODIRATIME;
if (mnt_flags & MNT_RELATIME)
flags |= ST_RELATIME;
+   if (mnt_flags & MNT_UNBINDABLE)
+   flags |= ST_UNBINDABLE;
return flags;
 }
 
diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index b336c04e793c..e1b84d0388c1 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -40,5 +40,6 @@ struct kstatfs {
 #define ST_NOATIME (1<<10) /* do not update access times */
 #define ST_NODIRATIME  (1<<11) /* do not update directory access times */
 #define ST_RELATIME(1<<12) /* update atime relative to mtime/ctime */
+#define ST_UNBINDABLE  (1<<17) /* change to unbindable */
 
 #endif
-- 
2.17.0

[PATCH 0/6] statfs: handle mount propagation

Hey,

This little series
- unifies the definition of constants in statfs.h and fs.h
- extends statfs to handle mount propagation. This will let userspace
  easily query a given mountpoint for MS_UNBINDABLE, MS_SHARED,
  MS_PRIVATE and MS_SLAVE without always having to do costly parsing of
  /proc//mountinfo.
  To this end the flags:
  - ST_UNBINDABLE
  - ST_SHARED
  - ST_PRIVATE
  - ST_SLAVE
  are added. They have the same value as their MS_* counterparts.

The patchset was made against Al's vfs/for-next tree but they also apply
cleanly against current linus/master. So if they are deemed suitable for
inclusion in the current release that should work too.

Thanks!
Christian

Christian Brauner (6):
  fs: use << for MS_* flags
  statfs: use << to align with fs header
  statfs: add ST_UNBINDABLE
  statfs: add ST_SHARED
  statfs: add ST_PRIVATE
  statfs: add ST_SLAVE

 fs/statfs.c | 16 +++-
 include/linux/statfs.h  | 30 +-
 include/uapi/linux/fs.h | 33 +
 3 files changed, 49 insertions(+), 30 deletions(-)

-- 
2.17.0

[PATCH 6/6] statfs: add ST_SLAVE

This lets userspace query whether a mountpoint was made MS_SLAVE.

Signed-off-by: Christian Brauner 
---
 fs/statfs.c| 10 +-
 include/linux/statfs.h |  1 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/statfs.c b/fs/statfs.c
index 26cda2586d7e..86e957d16a68 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include "internal.h"
+#include "pnode.h"
 
 static int flags_by_mnt(int mnt_flags)
 {
@@ -52,8 +53,15 @@ static int flags_by_sb(int s_flags)
 
 static int calculate_f_flags(struct vfsmount *mnt)
 {
-   return ST_VALID | flags_by_mnt(mnt->mnt_flags) |
+   int flags = 0;
+
+   flags = ST_VALID | flags_by_mnt(mnt->mnt_flags) |
flags_by_sb(mnt->mnt_sb->s_flags);
+
+   if (IS_MNT_SLAVE(real_mount(mnt)))
+   flags |= ST_SLAVE;
+
+   return flags;
 }
 
 static int statfs_by_dentry(struct dentry *dentry, struct kstatfs *buf)
diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index 1ea4a45aa6c3..663fa5498a7d 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -42,6 +42,7 @@ struct kstatfs {
 #define ST_RELATIME(1<<12) /* update atime relative to mtime/ctime */
 #define ST_UNBINDABLE  (1<<17) /* change to unbindable */
 #define ST_PRIVATE (1<<18) /* change to private */
+#define ST_SLAVE   (1<<19) /* change to slave */
 #define ST_SHARED  (1<<20) /* change to shared */
 
 #endif
-- 
2.17.0

[PATCH 2/6] statfs: use << to align with fs header

Consistenly use << to define ST_* constants. This also aligns them with
their MS_* counterparts in fs.h

Signed-off-by: Christian Brauner 
---
 include/linux/statfs.h | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index 3142e98546ac..b336c04e793c 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -27,18 +27,18 @@ struct kstatfs {
  * ABI.  The exception is ST_VALID which has the same value as MS_REMOUNT
  * which doesn't make any sense for statfs.
  */
-#define ST_RDONLY  0x0001  /* mount read-only */
-#define ST_NOSUID  0x0002  /* ignore suid and sgid bits */
-#define ST_NODEV   0x0004  /* disallow access to device special files */
-#define ST_NOEXEC  0x0008  /* disallow program execution */
-#define ST_SYNCHRONOUS 0x0010  /* writes are synced at once */
-#define ST_VALID   0x0020  /* f_flags support is implemented */
-#define ST_MANDLOCK0x0040  /* allow mandatory locks on an FS */
-/* 0x0080 used for ST_WRITE in glibc */
-/* 0x0100 used for ST_APPEND in glibc */
-/* 0x0200 used for ST_IMMUTABLE in glibc */
-#define ST_NOATIME 0x0400  /* do not update access times */
-#define ST_NODIRATIME  0x0800  /* do not update directory access times */
-#define ST_RELATIME0x1000  /* update atime relative to mtime/ctime */
+#define ST_RDONLY  (1<<0) /* mount read-only */
+#define ST_NOSUID  (1<<1) /* ignore suid and sgid bits */
+#define ST_NODEV   (1<<2) /* disallow access to device special files */
+#define ST_NOEXEC  (1<<3) /* disallow program execution */
+#define ST_SYNCHRONOUS (1<<4) /* writes are synced at once */
+#define ST_VALID   (1<<5) /* f_flags support is implemented */
+#define ST_MANDLOCK(1<<6) /* allow mandatory locks on an FS */
+/* (1<<7) used for ST_WRITE in glibc */
+/* (1<<8) used for ST_APPEND in glibc */
+/* (1<<9) used for ST_IMMUTABLE in glibc */
+#define ST_NOATIME (1<<10) /* do not update access times */
+#define ST_NODIRATIME  (1<<11) /* do not update directory access times */
+#define ST_RELATIME(1<<12) /* update atime relative to mtime/ctime */
 
 #endif
-- 
2.17.0

[PATCH 5/6] statfs: add ST_PRIVATE

This lets userspace query whether a mountpoint was made MS_PRIVATE.

Signed-off-by: Christian Brauner 
---
 fs/statfs.c| 2 ++
 include/linux/statfs.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/fs/statfs.c b/fs/statfs.c
index 2fc6f9c3793c..26cda2586d7e 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -33,6 +33,8 @@ static int flags_by_mnt(int mnt_flags)
flags |= ST_UNBINDABLE;
if (mnt_flags & MNT_SHARED)
flags |= ST_SHARED;
+   else
+   flags |= ST_PRIVATE;
return flags;
 }
 
diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index 5416b2936dd9..1ea4a45aa6c3 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -41,6 +41,7 @@ struct kstatfs {
 #define ST_NODIRATIME  (1<<11) /* do not update directory access times */
 #define ST_RELATIME(1<<12) /* update atime relative to mtime/ctime */
 #define ST_UNBINDABLE  (1<<17) /* change to unbindable */
+#define ST_PRIVATE (1<<18) /* change to private */
 #define ST_SHARED  (1<<20) /* change to shared */
 
 #endif
-- 
2.17.0

[PATCH 4/6] statfs: add ST_SHARED

This lets userspace query whether a mountpoint was made MS_SHARED.

Signed-off-by: Christian Brauner 
---
 fs/statfs.c| 2 ++
 include/linux/statfs.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/fs/statfs.c b/fs/statfs.c
index 61b3063d3921..2fc6f9c3793c 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -31,6 +31,8 @@ static int flags_by_mnt(int mnt_flags)
flags |= ST_RELATIME;
if (mnt_flags & MNT_UNBINDABLE)
flags |= ST_UNBINDABLE;
+   if (mnt_flags & MNT_SHARED)
+   flags |= ST_SHARED;
return flags;
 }
 
diff --git a/include/linux/statfs.h b/include/linux/statfs.h
index e1b84d0388c1..5416b2936dd9 100644
--- a/include/linux/statfs.h
+++ b/include/linux/statfs.h
@@ -41,5 +41,6 @@ struct kstatfs {
 #define ST_NODIRATIME  (1<<11) /* do not update directory access times */
 #define ST_RELATIME(1<<12) /* update atime relative to mtime/ctime */
 #define ST_UNBINDABLE  (1<<17) /* change to unbindable */
+#define ST_SHARED  (1<<20) /* change to shared */
 
 #endif
-- 
2.17.0

[PATCH 0/3] Driver for AT91 USART in SPI mode

Hello,

I wrote this driver for USART IP that is found in AT91 and SAMA5 SoCs. The
IP has an internal chip select, but is not used because is deasserted and
asserted after every byte sent over the wires. Gpio chip selects are used
instead of internal one. The driver works with actual USART nodes from
device tree of boards, but compatible must be changed, SCK pin muxed and
cs-gpio, size-cells and address-cells must be added. Of course, at the end
of the wires must be an SPI slave linked, not a serial console. :)

I tested the driver on sama5d4-xplained and sama5d3-xplained and works
without issues.

Radu Pirea (3):
  MAINTAINERS: add usart spi driver
  dt-bindings: add binding for at91-usart in spi mode
  spi: at91-usart: add driver for at91-usart as spi

 .../bindings/spi/microchip,at91-usart-spi.txt |  24 +
 MAINTAINERS   |   7 +
 drivers/spi/Kconfig   |   8 +
 drivers/spi/Makefile  |   1 +
 drivers/spi/spi-at91-usart.c  | 545 ++
 5 files changed, 585 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
 create mode 100644 drivers/spi/spi-at91-usart.c

-- 
2.17.0

[PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode

These are bindings for at91-usart IP in spi spi mode. There is no support for
internal chip select. Only kind of chip selects available are gpio chip
selects.

Signed-off-by: Radu Pirea 
---
 .../bindings/spi/microchip,at91-usart-spi.txt | 24 +++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt

diff --git a/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt 
b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
new file mode 100644
index ..92d33ccdffae
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
@@ -0,0 +1,24 @@
+* Universal Synchronous Asynchronous Receiver/Transmitter (USART) in SPI mode
+
+Required properties:
+- #size-cells  : Must be <0>
+- #address-cells   : Must be <1>
+- compatible: Should be "microchip,at91sam9g45-usart-spi" or 
"microchip,sama5d2-usart-spi" 
+- reg: Should contain registers location and length
+- interrupts: Should contain interrupt
+- clocks: phandles to input clocks.
+- clock-names: tuple listing input clock names.
+   Required elements: "usart"
+- cs-gpios: chipselects (internal cs not supported)
+
+Example:
+   spi0: spi@f001c000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "microchip,sama5d2-usart-spi", 
"microchip,at91sam9g45-usart-spi";
+   reg = <0xf001c000 0x100>;
+   interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&usart0_clk>;
+   clock-names = "usart";
+   cs-gpios = <&pioB 3 0>;
+   };
-- 
2.17.0

[PATCH 1/3] MAINTAINERS: add usart spi driver

Add entry for at91 usart spi driver.

Signed-off-by: Radu Pirea 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e2a2fddbd19..8f80d0e30573 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9192,6 +9192,13 @@ S:   Supported
 F: drivers/mtd/nand/raw/atmel/*
 F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
 
+MICROCHIP AT91 USART SPI DRIVER
+M: Radu Pirea 
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/spi/spi-at91-usart.c
+F: Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
+
 MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
 M: Woojung Huh 
 M: Microchip Linux Driver Support 
-- 
2.17.0

[PATCH 3/3] spi: at91-usart: add driver for at91-usart as spi

This is the driver for at91-usart in spi mode. The USART IP can be configured
to work in many modes and one of them is SPI.

The driver was tested on sama5d3-xplained and sama5d4-xplained boards with
enc28j60 ethernet controller as slave.

Signed-off-by: Radu Pirea 
---
 drivers/spi/Kconfig  |   8 +
 drivers/spi/Makefile |   1 +
 drivers/spi/spi-at91-usart.c | 545 +++
 3 files changed, 554 insertions(+)
 create mode 100644 drivers/spi/spi-at91-usart.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 6fb0347a24f2..b6b18d12abcb 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -77,6 +77,14 @@ config SPI_ATMEL
  This selects a driver for the Atmel SPI Controller, present on
  many AT91 (ARM) chips.
 
+config SPI_AT91_USART
+tristate "Atmel USART Controller as SPI"
+depends on HAS_DMA
+depends on (ARCH_AT91 || COMPILE_TEST)
+help
+ This selects a driver for the AT91 USART Controller as SPI Master,
+ present on AT91 and SAMA5 SoC series.
+
 config SPI_AU1550
tristate "Au1550/Au1200/Au1300 SPI Controller"
depends on MIPS_ALCHEMY
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 34c5f2832ddf..fb6cb42f4eaa 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_SPI_LOOPBACK_TEST)   += 
spi-loopback-test.o
 obj-$(CONFIG_SPI_ALTERA)   += spi-altera.o
 obj-$(CONFIG_SPI_ARMADA_3700)  += spi-armada-3700.o
 obj-$(CONFIG_SPI_ATMEL)+= spi-atmel.o
+obj-$(CONFIG_SPI_AT91_USART)   += spi-at91-usart.o
 obj-$(CONFIG_SPI_ATH79)+= spi-ath79.o
 obj-$(CONFIG_SPI_AU1550)   += spi-au1550.o
 obj-$(CONFIG_SPI_AXI_SPI_ENGINE)   += spi-axi-spi-engine.o
diff --git a/drivers/spi/spi-at91-usart.c b/drivers/spi/spi-at91-usart.c
new file mode 100644
index ..7d443fae1b79
--- /dev/null
+++ b/drivers/spi/spi-at91-usart.c
@@ -0,0 +1,545 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for AT91 USART Controllers as SPI
+ *
+ * Copyright (C) 2018 Microchip Technology Inc.
+ * Author: Radu Pirea 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#define US_CR  0x00
+#define US_MR  0x04
+#define US_IER 0x08
+#defineUS_IDR  0x0C
+#defineUS_CSR  0x14
+#define US_RHR 0x18
+#defineUS_THR  0x1C
+#define US_BRGR0x20
+#define US_VERSION 0xFC
+
+#define US_CR_RSTRXBIT(2)
+#define US_CR_RSTTXBIT(3)
+#define US_CR_RXEN BIT(4)
+#define US_CR_RXDISBIT(5)
+#define US_CR_TXEN BIT(6)
+#define US_CR_TXDISBIT(7)
+
+#define US_MR_SPI_MASTER   0x0E
+#define US_MR_CHRL GENMASK(7, 6)
+#define US_MR_CPHA BIT(8)
+#define US_MR_CPOL BIT(16)
+#define US_MR_CLKO BIT(18)
+#define US_MR_WRDBTBIT(20)
+#define US_MR_LOOP BIT(15)
+
+#define US_IR_RXRDYBIT(0)
+#define US_IR_TXRDYBIT(1)
+#define US_IR_OVRE BIT(5)
+
+#define US_BRGR_SIZE   BIT(16)
+
+#define US_MIN_CLK_DIV 0x06
+#define US_MAX_CLK_DIV BIT(16)
+
+#define US_DUMMY_TX0xFF
+
+/* Register access macros */
+#define spi_readl(port, reg) \
+   readl_relaxed((port)->regs + US_##reg)
+#define spi_writel(port, reg, value) \
+   writel_relaxed((value), (port)->regs + US_##reg)
+
+#define spi_readb(port, reg) \
+   readb_relaxed((port)->regs + US_##reg)
+#define spi_writeb(port, reg, value) \
+   writeb_relaxed((value), (port)->regs + US_##reg)
+
+struct at91_usart_spi {
+   struct spi_transfer *current_transfer;
+   void __iomem*regs;
+   struct device   *dev;
+   struct clk  *clk;
+
+   /*used in interrupt to protect data reading*/
+   spinlock_t  lock;
+
+   int irq;
+   unsigned intcurrent_tx_remaining_bytes;
+   unsigned intcurrent_rx_remaining_bytes;
+   int done_status;
+
+   u32 spi_clk;
+   u32 status;
+
+   boolxfer_failed;
+   boolkeep_cs;
+   boolcs_active;
+};
+
+struct at91_usart_spi_device {
+   struct gpio_desc*npcs_pin;
+   u32 mr;
+};
+
+static inline u32 at91_usart_spi_tx_ready(struct at91_usart_spi *aus)
+{
+   return aus->status & US_IR_TXRDY;
+}
+
+static inline u32 at91_usart_spi_rx_ready(struct at91_usart_spi *aus)
+{
+   return

Re: [PATCH v3 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics

On Thu, Apr 12, 2018 at 10:15:41PM +0800, Kai-Heng Feng wrote:
> at 6:59 PM, Pali Rohár  wrote:
> 
> > On Thursday 12 April 2018 12:50:02 Takashi Iwai wrote:
> > > > +#if IS_ENABLED(CONFIG_DELL_LAPTOP)
> > > > +static bool check_dell_switchable_gfx(struct pci_dev *pdev)
> > > > +{
> > > > +   bool (*dell_switchable_gfx_is_enabled_func)(void);
> > > > +   bool enabled;
> > > > +
> > > > +   /* Only need to check for Dell laptops and AIOs */
> > > > +   if (!dmi_find_device(DMI_DEV_TYPE_OEM_STRING, "Dell System", 
> > > > NULL) ||
> > > > +   !(dmi_match(DMI_CHASSIS_TYPE, "10") ||
> > > > + dmi_match(DMI_CHASSIS_TYPE, "13")) ||
> > > > +   !(pdev->vendor == PCI_VENDOR_ID_ATI ||
> > > > + pdev->vendor == PCI_VENDOR_ID_NVIDIA))
> > > > +   return false;
> > ...
> > > > @@ -1711,6 +1745,11 @@ static int azx_create(struct snd_card
> > > > *card, struct pci_dev *pci,
> > > > if (err < 0)
> > > > return err;
> > > > 
> > > > +   if (check_dell_switchable_gfx(pci)) {
> > > > +   pci_disable_device(pci);
> > 
> > Hi!
> > 
> > Now looking at it again... This code disables all ATI and NVIDIA sound
> > cards available in any Dell System (laptop or AIO) if system says that
> > SG is enabled, right?
> 
> Yes.
> 
> > 
> > It means that also any external ATI or NVIDIA PCI card with audio device
> > connected to Thunderbolt (e.g. via PCI <--> TB bridge) is always
> > unconditionally disabled too?
> 
> I never thought of this case, thanks for bringing this up.
> Do you have any suggestion to check if it connects to the system via
> Thunderbolt?

Is there any kind of indicator for a PCI device if it is a removable
device?  Only disabling those PCI devices which are wholly integrated
with the platform would be ideal.

Failing that, is there an indicator in the PCI configuration which will
distinguish such devices? Are the integrated devices using specific
lanes, are the external devices behind a switch? etc. And can we do this
in a generic way for all relevant platforms.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

2018-04-13 Thread Daniel Vetter

On Wed, Apr 11, 2018 at 09:32:16AM +0200, Simon Horman wrote:
> On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> > ("gpio: correct docs about return value of gpiod_get_direction"). Now,
> > fix this user (until a better, system-wide solution is in place).
> > 
> > Signed-off-by: Wolfram Sang 
> > Acked-by: Daniel Thompson 
> 
> Reviewed-by: Simon Horman 
> 
> > ---
> > 
> > Changes since V1:
> > * rebased to top-of-linus-tree
> > * added tag from Daniel, thanks!
> > 
> > Through which tree does this need to go?

I think Daniel Thompson has one ...
-Daniel

> > 
> >  drivers/video/backlight/pwm_bl.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/video/backlight/pwm_bl.c 
> > b/drivers/video/backlight/pwm_bl.c
> > index 1c2289ddd555..0fa7d2bd0e48 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -301,14 +301,14 @@ static int pwm_backlight_probe(struct platform_device 
> > *pdev)
> >  
> > /*
> >  * If the GPIO is not known to be already configured as output, that
> > -* is, if gpiod_get_direction returns either GPIOF_DIR_IN or -EINVAL,
> > -* change the direction to output and set the GPIO as active.
> > +* is, if gpiod_get_direction returns either 1 or -EINVAL, 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_OUT)
> > +   gpiod_get_direction(pb->enable_gpio) != 0)
> > gpiod_direction_output(pb->enable_gpio, 1);
> >  
> > pb->power_supply = devm_regulator_get(&pdev->dev, "power");
> > -- 
> > 2.11.0
> > 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

RE: [RFC 02/10] PCI: cadence: Update cdns_pcie_ep_raise_irq function signature

2018-04-13 Thread Alan Douglas

On Tue, Apr 10 at 18.15, Gustavo Pimentel wrote:
> From: Gustavo Pimentel [mailto:gustavo.pimen...@synopsys.com]
> Changes the cdns_pcie_ep_raise_irq function signature, namely the
> interrupt_num variable type from u8 to u16 to accommodate the MSI-X
> maximum interrupts of 2048.
> 
> Signed-off-by: Gustavo Pimentel 
> ---
>  drivers/pci/cadence/pcie-cadence-ep.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/cadence/pcie-cadence-ep.c
> b/drivers/pci/cadence/pcie-cadence-ep.c
> index 3d8283e..6d6322c 100644
> --- a/drivers/pci/cadence/pcie-cadence-ep.c
> +++ b/drivers/pci/cadence/pcie-cadence-ep.c
> @@ -363,7 +363,7 @@ static int cdns_pcie_ep_send_msi_irq(struct
> cdns_pcie_ep *ep, u8 fn,  }
> 
>  static int cdns_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn,
> -   enum pci_epc_irq_type type, u8
> interrupt_num)
> +   enum pci_epc_irq_type type, u16
> interrupt_num)
>  {
>   struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
> 
> --
> 2.7.4
> 
Acked-by: Alan Douglas

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

2018-04-13 Thread Jann Horn

On Fri, Apr 13, 2018 at 6:04 PM, Michal Hocko  wrote:
> On Fri 13-04-18 17:04:09, Jann Horn wrote:
>> On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko  wrote:
>> > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote:
>> > [...]
>> >> So, you mean remove this entire paragraph:
>> >>
>> >>   For cases in which the specified memory region has not been
>> >>   reserved using an existing mapping,  newer  kernels  (Linux
>> >>   4.17  and later) provide an option MAP_FIXED_NOREPLACE that
>> >>   should be used instead; older kernels require the caller to
>> >>   use addr as a hint (without MAP_FIXED) and take appropriate
>> >>   action if the kernel places the new mapping at a  different
>> >>   address.
>> >>
>> >> It seems like some version of the first half of the paragraph is worth
>> >> keeping, though, so as to point the reader in the direction of a remedy.
>> >> How about replacing that text with the following:
>> >>
>> >>   Since  Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used
>> >>   in a multithreaded program to avoid  the  hazard  described
>> >>   above.
>> >
>> > Yes, that sounds reasonable to me.
>>
>> But that kind of sounds as if you can't avoid it before Linux 4.17,
>> when actually, you just have to call mmap() with the address as hint,
>> and if mmap() returns a different address, munmap() it and go on your
>> normal error path.
>
> This is still racy in multithreaded application which is the main point
> of the whole section, no?

No, it isn't.

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

2018-04-13 Thread Paolo Bonzini

On 13/04/2018 18:02, Jim Mattson wrote:
> On Fri, Apr 13, 2018 at 4:23 AM, Paolo Bonzini  wrote:
>> From: KarimAllah Ahmed 
>>
>> Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always
>> captures the TSC_OFFSET of the running guest whether it is the L1 or L2
>> guest.
>>
>> Cc: Jim Mattson 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: k...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Suggested-by: Paolo Bonzini 
>> Signed-off-by: KarimAllah Ahmed 
>> [AMD changes, fix update_ia32_tsc_adjust_msr. - Paolo]
>> Signed-off-by: Paolo Bonzini 
> 
>> @@ -11489,6 +11497,9 @@ static int nested_vmx_run(struct kvm_vcpu *vcpu, 
>> bool launch)
>> if (enable_shadow_vmcs)
>> copy_shadow_to_vmcs12(vmx);
>>
>> +   if (vmcs12->cpu_based_vm_exec_control & CPU_BASED_USE_TSC_OFFSETING)
>> +   vcpu->arch.tsc_offset += vmcs12->tsc_offset;
>> +
> 
> This seems a little early, since we don't restore the L1 TSC offset on
> the nested_vmx_failValid path.
> 

Now this can be a nice one to introduce the VMX API tests. :)  I'll try
to do it on Monday as punishment for not noticing the bug.  In the
meanwhile, Karim, can you post a fixed fixed version?

Paolo

Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved

2018-04-13 Thread Michal Hocko

On Fri 13-04-18 17:04:09, Jann Horn wrote:
> On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko  wrote:
> > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote:
> > [...]
> >> So, you mean remove this entire paragraph:
> >>
> >>   For cases in which the specified memory region has not been
> >>   reserved using an existing mapping,  newer  kernels  (Linux
> >>   4.17  and later) provide an option MAP_FIXED_NOREPLACE that
> >>   should be used instead; older kernels require the caller to
> >>   use addr as a hint (without MAP_FIXED) and take appropriate
> >>   action if the kernel places the new mapping at a  different
> >>   address.
> >>
> >> It seems like some version of the first half of the paragraph is worth
> >> keeping, though, so as to point the reader in the direction of a remedy.
> >> How about replacing that text with the following:
> >>
> >>   Since  Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used
> >>   in a multithreaded program to avoid  the  hazard  described
> >>   above.
> >
> > Yes, that sounds reasonable to me.
> 
> But that kind of sounds as if you can't avoid it before Linux 4.17,
> when actually, you just have to call mmap() with the address as hint,
> and if mmap() returns a different address, munmap() it and go on your
> normal error path.

This is still racy in multithreaded application which is the main point
of the whole section, no?

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

2018-04-13 Thread Jim Mattson

On Fri, Apr 13, 2018 at 4:23 AM, Paolo Bonzini  wrote:
> From: KarimAllah Ahmed 
>
> Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always
> captures the TSC_OFFSET of the running guest whether it is the L1 or L2
> guest.
>
> Cc: Jim Mattson 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: k...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Suggested-by: Paolo Bonzini 
> Signed-off-by: KarimAllah Ahmed 
> [AMD changes, fix update_ia32_tsc_adjust_msr. - Paolo]
> Signed-off-by: Paolo Bonzini 

> @@ -11489,6 +11497,9 @@ static int nested_vmx_run(struct kvm_vcpu *vcpu, bool 
> launch)
> if (enable_shadow_vmcs)
> copy_shadow_to_vmcs12(vmx);
>
> +   if (vmcs12->cpu_based_vm_exec_control & CPU_BASED_USE_TSC_OFFSETING)
> +   vcpu->arch.tsc_offset += vmcs12->tsc_offset;
> +

This seems a little early, since we don't restore the L1 TSC offset on
the nested_vmx_failValid path.

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

2018-04-13 Thread Brian Starkey

Hi Daniel,

On Fri, Apr 13, 2018 at 05:44:09PM +0200, Daniel Vetter wrote:

On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote:

Hi Daniel,

On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
> On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
> > On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> > > On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder  wrote:

[snip]

As for why, my understanding is like so:

For ->suspend(), we use the DRM helper, which disables the CRTC.
Normally disabling the CRTC would be enough to also invoke our
pm_runtime callback to do the final clock disable etc., however when a
system suspend is in-progress, the core forcibly takes a runtime
reference on all devices - preventing any pm_runtime paths from
running.

I thought this was fixed. At least I remember we had to add some special
calls to i915 to opt out of the "do runtime pm as part of suspend/resume"
behaviour, since it doesn't match what we needed.

See

commit aae4518b3124b29f8dc81c829c704fd2df72e98b
Author: Rafael J. Wysocki 
Date:   Fri May 16 02:46:50 2014 +0200

   PM / sleep: Mechanism to avoid resuming runtime-suspended devices 
unnecessarily

So I thought this stuff was supposed to work now. Adding Rafael Wyzocki,
he's done plenty presentations recently about exactly this.

AFAIK direct-complete is a different thing - related, but not involved
here.

Ayan's patch is to deal with the case where the device is active
(runtime state = active), when a system suspend is triggered.

The core takes its reference (leaving direct-complete devices
'suspended' if possible, but our device is 'active' and so
direct-complete doesn't apply) and then we start the system suspend
and disable the CRTC.

Normally, after the CRTC is disabled, we rely on PM-core to notice we
can be runtime suspended, but it won't do this during system suspend
because of the reference PM-core took, and so we need to force the
suspend ourselves.

This means that after the CRTC is disabled in ->suspend(), our normal
pm_runtime path will not be invoked, and so the things done in
malidp_runtime_pm_suspend() will never happen.

We were just following the advice in the kernel-doc to deal with this.

The alternative would be to call malidp_runtime_pm_{suspend,resume}
from the "not late" hooks, but I'd ask why?

> Also, you still haven't explained what exactly the dependency is.

Because there isn't one :-)

Hm, if there really isn't one, then I guess it's ok. But it's way too easy
to screw this up, have an accidental depency on a different device. And
then you try to fix this up. Having a suspend_late hook still smells fishy
to me, but I might be out of the loop.
-Daniel

Hopefully Rafael can set us straight. The kerneldoc doesn't make
suspend_late sound exceptional, but kernel-doc isn't perfect :-)

Thanks for the review,
-Brian

Thanks,
-Brian

> -Daniel
>
> >
> > > >> > ---
> > > >> >  drivers/gpu/drm/arm/malidp_drv.c | 17 +
> > > >> >  1 file changed, 17 insertions(+)
> > > >> >
> > > >> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
b/drivers/gpu/drm/arm/malidp_drv.c
> > > >> > index bd44a6d..f6124d8 100644
> > > >> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > >> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > > >> > @@ -766,8 +766,25 @@ static int __maybe_unused 
malidp_pm_resume(struct device *dev)
> > > >> > return 0;
> > > >> >  }
> > > >> >
> > > >> > +static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
> > > >> > +{
> > > >> > +   if (!pm_runtime_status_suspended(dev)) {
> > > >> > +   malidp_runtime_pm_suspend(dev);
> > > >> > +   pm_runtime_set_suspended(dev);
> > > >> > +   }
> > > >> > +   return 0;
> > > >> > +}
> > > >> > +
> > > >> > +static int __maybe_unused malidp_pm_resume_early(struct device *dev)
> > > >> > +{
> > > >> > +   malidp_runtime_pm_resume(dev);
> > > >> > +   pm_runtime_set_active(dev);
> > > >> > +   return 0;
> > > >> > +}
> > > >> > +
> > > >> >  static const struct dev_pm_ops malidp_pm_ops = {
> > > >> > SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
> > > >> > +   SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
malidp_pm_resume_early) \
> > > >> > SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, 
malidp_runtime_pm_resume, NULL)
> > > >> >  };
> > > >> >
> > > >> > --
> > > >> > 2.7.4
> > > >> >
> > > >> > ___
> > > >> > dri-devel mailing list
> > > >> > dri-de...@lists.freedesktop.org
> > > >> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >>
> > > >> --
> > > >> Daniel Vetter
> > > >> Software Engineer, Intel Corporation
> > > >> http://blog.ffwll.ch
> > > >> ___
> > > >> dri-devel mailing list
> > > >> dri-de...@lists.freedesktop.org
> > > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > IMPORTANT NOTICE: The contents of this email and any attachments are 
c

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

On Fri, Apr 13, 2018 at 5:13 AM, Jean Delvare  wrote:
> Hi Wolfram, Sam,
>
> On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote:
>> On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote:
>> > Currently, Documentation/i2c/dev-interface describes the use of i2c_smbus_*
>> > helper routines as static inlined functions provided by linux/i2c-dev.h.  
>> > Work
>> > has been done to refactor the linux/i2c-dev.h file in the i2c-tools project
>> > out into its own library.  As a result, these docs have become stale.
>>
>> Thanks for fixing this!
>>
>> > This patch corrects the discrepancy and directs the reader to the i2c-tools
>> > project for more information.  Additionally, some trailing-whitespace 
>> > cleanups
>> > were made.
>>
>> Minor nit: Having the whitespace changes in a seperate patch is a tad
>> easier to review.
>>
>> > -  /* Using I2C Write, equivalent of
>> > +  /* Using I2C Write, equivalent of
>> >   i2c_smbus_write_word_data(file, reg, 0x6543) */
>>
>> Maybe change to Kernel coding style comments while here?
>>
>> > -  Not meant to be called  directly; instead, use the access functions
>> > -  below.
>> > +  If possible, use the provided i2c_smbus_* methods described below in 
>> > favor
>> > +  of issuing direct ioctls.
>>
>> Why this change?
>
> I'm also not sure if "in favor of" is right. "instead of" would sound
> better to me, but I'm no native English speaker, I could be wrong.

Sounds good, I'll adopt "instead of".  Regarding Wolfram's earlier
comment, as an engineer, requiring an out-of-tree library to build
drivers felt a little off.  I can revert this section if you want,
just let me know.

>
>> > -The above functions are all inline functions, that resolve to calls to
>> > -the i2c_smbus_access function, that on its turn calls a specific ioctl
>> > -with the data in a specific format. Read the source code if you
>> > -want to know what happens behind the screens.
>> > +The above functions are made available by linking against the libi2c 
>> > library,
>> > +which is provided by the i2c-tools project.  See:
>> > +https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/.
>>
>> This is fine with me. Maybe Jean has a comment on this?
>
> Fixing the documentation is always welcome, thanks Sam for stepping in.
> However we really want separate patches for whitespace fixes and actual
> contents change, as Wolfram already mentioned above.

Will do!  I'll send a v2 patch set, thanks.

>
> --
> Jean Delvare
> SUSE L3 Support

Re: [PATCH RFC 7/8] mm: allow to control onlining/offlining of memory by a driver

2018-04-13 Thread Michal Hocko

On Fri 13-04-18 15:33:28, David Hildenbrand wrote:
> Some devices (esp. paravirtualized) might want to control
> - when to online/offline a memory block
> - how to online memory (MOVABLE/NORMAL)
> - in which granularity to online/offline memory
> 
> So let's add a new flag "driver_managed" and disallow to change the
> state by user space. Device onlining/offlining will still work, however
> the memory will not be actually onlined/offlined. That has to be handled
> by the device driver that owns the memory.

Is there any reason to create the memblock sysfs interface to this
memory at all? ZONE_DEVICE mem hotplug users currently do not do that
and manage the memory themselves. It seems you want to achieve the same
thing, no?
-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH 24/35] Revert "ovl: fix relatime for directories"

2018-04-13 Thread Vivek Goyal

On Thu, Apr 12, 2018 at 05:08:15PM +0200, Miklos Szeredi wrote:
> This reverts commit cd91304e7190b4c4802f8e413ab2214b233e0260.
> 
> Overlayfs no longer relies on the vfs correct atime handling.
> 
> Signed-off-by: Miklos Szeredi 
> ---
>  fs/inode.c | 21 -
>  fs/overlayfs/super.c   |  3 ---
>  include/linux/dcache.h |  3 ---
>  3 files changed, 4 insertions(+), 23 deletions(-)
> 
> diff --git a/fs/inode.c b/fs/inode.c
> index ef362364d396..163715de8cb2 100644
> --- a/fs/inode.c
> +++ b/fs/inode.c
> @@ -1570,24 +1570,11 @@ EXPORT_SYMBOL(bmap);
>  static void update_ovl_inode_times(struct dentry *dentry, struct inode 
> *inode,
>  bool rcu)
>  {
> - struct dentry *upperdentry;
> + if (!rcu) {
> + struct inode *realinode = d_real_inode(dentry);
>  
> - /*
> -  * Nothing to do if in rcu or if non-overlayfs
> -  */
> - if (rcu || likely(!(dentry->d_flags & DCACHE_OP_REAL)))
> - return;
> -
> - upperdentry = d_real(dentry, NULL, 0, D_REAL_UPPER);
> -
> - /*
> -  * If file is on lower then we can't update atime, so no worries about
> -  * stale mtime/ctime.
> -  */
> - if (upperdentry) {
> - struct inode *realinode = d_inode(upperdentry);
> -
> - if ((!timespec_equal(&inode->i_mtime, &realinode->i_mtime) ||
> + if (unlikely(inode != realinode) &&
> + (!timespec_equal(&inode->i_mtime, &realinode->i_mtime) ||
>!timespec_equal(&inode->i_ctime, &realinode->i_ctime))) {
>   inode->i_mtime = realinode->i_mtime;
>   inode->i_ctime = realinode->i_ctime;
> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
> index c3d8c7ea180f..006dc70d7425 100644
> --- a/fs/overlayfs/super.c
> +++ b/fs/overlayfs/super.c
> @@ -107,9 +107,6 @@ static struct dentry *ovl_d_real(struct dentry *dentry,
>   if (inode && d_inode(dentry) == inode)
>   return dentry;
>  
> - if (flags & D_REAL_UPPER)
> - return ovl_dentry_upper(dentry);
> -
>   if (!d_is_reg(dentry)) {
>   if (!inode || inode == d_inode(dentry))
>   return dentry;
> diff --git a/include/linux/dcache.h b/include/linux/dcache.h
> index 82a99d366aec..4c7ab11c627a 100644
> --- a/include/linux/dcache.h
> +++ b/include/linux/dcache.h
> @@ -565,9 +565,6 @@ static inline struct dentry *d_backing_dentry(struct 
> dentry *upper)
>   return upper;
>  }
>  
> -/* d_real() flags */
> -#define D_REAL_UPPER 0x2 /* return upper dentry or NULL if non-upper */

Good to see this go away. It was a major headache for metacopy only
patches. 

Vivek
> -
>  /**
>   * d_real - Return the real dentry
>   * @dentry: the dentry to query
> -- 
> 2.14.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH ipmi/kcs_bmc v1] ipmi: add an NPCM7xx KCS BMC driver

2018-04-13 Thread Corey Minyard


On 03/22/2018 07:50 AM, Haiyue Wang wrote:

This driver exposes the Keyboard Controller Style (KCS) interface on
Novoton NPCM7xx SoCs as a character device. Such SOCs are commonly used
as a BaseBoard Management Controller (BMC) on a server board, and KCS
interface is commonly used to perform the in-band IPMI communication
between the server and its BMC.


Sorry, I missed this.  It is queued for the next kernel release.

Thanks,

-corey



Signed-off-by: Avi Fishman 
Signed-off-by: Haiyue Wang 
---
  .../devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt   |  39 
  drivers/char/ipmi/Kconfig  |  15 ++
  drivers/char/ipmi/Makefile |   1 +
  drivers/char/ipmi/kcs_bmc_npcm7xx.c| 204 +
  4 files changed, 259 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt
  create mode 100644 drivers/char/ipmi/kcs_bmc_npcm7xx.c

diff --git a/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt 
b/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt
new file mode 100644
index 000..3538a21
--- /dev/null
+++ b/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt
@@ -0,0 +1,39 @@
+* Nuvoton NPCM7xx KCS (Keyboard Controller Style) IPMI interface
+
+The Nuvoton SOCs (NPCM7xx) are commonly used as BMCs
+(Baseboard Management Controllers) and the KCS interface can be
+used to perform in-band IPMI communication with their host.
+
+Required properties:
+- compatible : should be one of
+"nuvoton,npcm750-kcs-bmc"
+- interrupts : interrupt generated by the controller
+- kcs_chan : The KCS channel number in the controller
+
+Example:
+
+lpc_kcs: lpc_kcs@f0007000 {
+compatible = "nuvoton,npcm750-lpc-kcs", "simple-mfd", "syscon";
+reg = <0xf0007000 0x40>;
+reg-io-width = <1>;
+
+#address-cells = <1>;
+#size-cells = <1>;
+ranges = <0x0 0xf0007000 0x40>;
+
+kcs1: kcs1@0 {
+compatible = "nuvoton,npcm750-kcs-bmc";
+reg = <0x0 0x40>;
+interrupts = <0 9 4>;
+kcs_chan = <1>;
+status = "disabled";
+};
+
+kcs2: kcs2@0 {
+compatible = "nuvoton,npcm750-kcs-bmc";
+reg = <0x0 0x40>;
+interrupts = <0 9 4>;
+kcs_chan = <2>;
+status = "disabled";
+};
+};
\ No newline at end of file
diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index 3bda116..470f976 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -111,6 +111,21 @@ config ASPEED_KCS_IPMI_BMC
  The driver implements the BMC side of the KCS contorller, it
  provides the access of KCS IO space for BMC side.
  
+config NPCM7XX_KCS_IPMI_BMC

+   depends on ARCH_NPCM7XX || COMPILE_TEST
+   select IPMI_KCS_BMC
+   select REGMAP_MMIO
+   tristate "NPCM7xx KCS IPMI BMC driver"
+   help
+ Provides a driver for the KCS (Keyboard Controller Style) IPMI
+ interface found on Nuvoton NPCM7xx SOCs.
+
+ The driver implements the BMC side of the KCS contorller, it
+ provides the access of KCS IO space for BMC side.
+
+ This support is also available as a module.  If so, the module
+ will be called kcs_bmc_npcm7xx.
+
  config ASPEED_BT_IPMI_BMC
depends on ARCH_ASPEED || COMPILE_TEST
 depends on REGMAP && REGMAP_MMIO && MFD_SYSCON
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index 21e9e87..7a3baf3 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -24,3 +24,4 @@ obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
  obj-$(CONFIG_IPMI_KCS_BMC) += kcs_bmc.o
  obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
  obj-$(CONFIG_ASPEED_KCS_IPMI_BMC) += kcs_bmc_aspeed.o
+obj-$(CONFIG_NPCM7XX_KCS_IPMI_BMC) += kcs_bmc_npcm7xx.o
diff --git a/drivers/char/ipmi/kcs_bmc_npcm7xx.c 
b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
new file mode 100644
index 000..7bc898c
--- /dev/null
+++ b/drivers/char/ipmi/kcs_bmc_npcm7xx.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, Nuvoton Corporation.
+ * Copyright (c) 2018, Intel Corporation.
+ */
+
+#define pr_fmt(fmt) "nuvoton-kcs-bmc: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "kcs_bmc.h"
+
+#define DEVICE_NAME"npcm-kcs-bmc"
+#define KCS_CHANNEL_MAX3
+
+#define KCS1ST 0x0C
+#define KCS2ST 0x1E
+#define KCS3ST 0x30
+
+#define KCS1DO 0x0E
+#define KCS2DO 0x20
+#define KCS3DO 0x32
+
+#define KCS1DI 0x10
+#define KCS2DI 0x22
+#define KCS3DI 0x34
+
+#define KCS1CTL0x18
+#define KCS2CTL0x2A
+#define KCS3CTL0x3C
+#defineKCS_CTL_IBFIE   BIT(0)
+
+/*
+ * 7.2.4 Core KCS Registers
+ * Registers in this module are 8 bits. An 8

Re: net: hang in unregister_netdevice: waiting for lo to become free

2018-04-13 Thread Dmitry Vyukov

On Fri, Apr 13, 2018 at 2:43 PM, Dan Streetman  wrote:
> On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov  wrote:
>> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
>>  wrote:
>>> On 20.02.2018 18:26, Neil Horman wrote:

 On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
>
> On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
>  wrote:
>>
>> On 19.02.2018 20:59, Dmitry Vyukov wrote:
>>>
>>> Is this meant to be fixed already? I am still seeing this on the
>>> latest upstream tree.
>>>
>>
>> These two commits are in v4.16-rc1:
>>
>> commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8
>> Author: Tommi Rantala 
>> Date:   Mon Feb 5 21:48:14 2018 +0200
>>
>>  sctp: fix dst refcnt leak in sctp_v4_get_dst
>> ...
>>  Fixes: 410f03831 ("sctp: add routing output fallback")
>>  Fixes: 0ca50d12f ("sctp: fix src address selection if using
>> secondary
>> addresses")
>>
>>
>> commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2
>> Author: Alexey Kodanev 
>> Date:   Mon Feb 5 15:10:35 2018 +0300
>>
>>  sctp: fix dst refcnt leak in sctp_v6_get_dst()
>> ...
>>  Fixes: dbc2b5e9a09e ("sctp: fix src address selection if using
>> secondary
>> addresses for ipv6")
>>
>>
>> I guess we missed something if it's still reproducible.
>>
>> I can check it later this week, unless someone else beat me to it.
>
>
> Hi Tommi,
>
> Hmmm, I can't claim that it's exactly the same bug. Perhaps it's
> another one then. But I am still seeing these:
>
> [   58.799130] unregister_netdevice: waiting for lo to become free.
> Usage count = 4
> [   60.847138] unregister_netdevice: waiting for lo to become free.
> Usage count = 4
> [   62.895093] unregister_netdevice: waiting for lo to become free.
> Usage count = 4
> [   64.943103] unregister_netdevice: waiting for lo to become free.
> Usage count = 4
>
> on upstream tree pulled ~12 hours ago.
>
 Can you write a systemtap script to probe dev_hold, and dev_put, printing
 out a
 backtrace if the device name matches "lo".  That should tell us
 definitively if
 the problem is in the same location or not
>>>
>>>
>>> Hi Dmitry, I tested with the reproducer and the kernel .config file that you
>>> sent in the first email in this thread:
>>>
>>> With 4.16-rc2 unable to reproduce.
>>>
>>> With 4.15-rc9 bug reproducible, and I get "unregister_netdevice: waiting for
>>> lo to become free. Usage count = 3"
>>>
>>> With 4.15-rc9 and Alexey's "sctp: fix dst refcnt leak in sctp_v6_get_dst()"
>>> cherry-picked on top, unable to reproduce.
>>>
>>>
>>> Is syzkaller doing something else now to trigger the bug...?
>>> Can you still trigger the bug with the same reproducer?
>>
>> Hi Neil, Tommi,
>>
>> Reviving this old thread about "unregister_netdevice: waiting for lo
>> to become free. Usage count = 3" hangs.
>> I still did not have time to deep dive into what happens there (too
>> many bugs coming from syzbot). But this still actively happens and I
>> suspect accounts to a significant portion of various hang reports,
>> which are quite unpleasant.
>>
>> One idea that could make it all simpler:
>>
>> Is this wait loop in netdev_wait_allrefs() supposed to wait for any
>> prolonged periods of time under any non-buggy conditions? E.g. more
>> than 1-2 minutes?
>> If it only supposed to wait briefly for things that already supposed
>> to be shutting down, and we add a WARNING there after some timeout,
>> then syzbot will report all info how/when it happens, hopefully
>> extracting reproducers, and all the nice things.
>> But this WARNING should not have any false positives under any
>> realistic conditions (e.g. waiting for arrival of remote packets with
>> large timeouts).
>>
>> Looking at some task hung reports, it seems that this code holds some
>> mutexes, takes workqueue thread and prevents any progress with
>> destruction of other devices (and net namespace creation/destruction),
>> so I guess it should not wait for any indefinite periods of time?
>
> I'm working on this currently:
> https://bugs.launchpad.net/ubuntu/zesty/+source/linux/+bug/1711407
>
> I added a summary of what I've found to be the cause (or at least, one
> possible cause) of this:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407/comments/72
>
> I'm working on a patch to work around the main side-effect of this,
> which is hanging while holding the global net mutex.  Hangs will still
> happen (e.g. if a dst leaks) but should not affect anything else,
> other than a leak of the dst and its net namespace.
>
> Fixing the dst leaks is important too, of course, but a dst leak (or
> other cause) shouldn't break the entire system.

Leaking some memory is definitely better than hanging the system.

So I've made syzkaller to recognize "unregister_netdevice: waiting for
(.*) to becom

[PATCH v7 5/5] crypto: add flag for unstable encoding

The data-format of zBeWalgo, and some other algorithms is unstable. To
identify such unstable algorithms this patch adds a new flag to the
crypto-api.

Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
---
 crypto/zbewalgo.c  | 2 +-
 include/linux/crypto.h | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/crypto/zbewalgo.c b/crypto/zbewalgo.c
index 9db0d43b..e57b5ced 100644
--- a/crypto/zbewalgo.c
+++ b/crypto/zbewalgo.c
@@ -134,7 +134,7 @@ static int zbewalgo_decompress_crypto_unsafe(struct 
crypto_tfm *tfm,
 
 static struct crypto_alg crypto_alg_zbewalgo = {
.cra_name = "zbewalgo",
-   .cra_flags = CRYPTO_ALG_TYPE_COMPRESS,
+   .cra_flags = CRYPTO_ALG_TYPE_COMPRESS | CRYPTO_ALG_UNSTABLE_ENCODING,
.cra_ctxsize = sizeof(struct zbewalgo_ctx),
.cra_module = THIS_MODULE,
.cra_init = zbewalgo_init,
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 6bfb1aea..2228dd08 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -112,6 +112,12 @@
  */
 #define CRYPTO_ALG_OPTIONAL_KEY0x4000
 
+/*
+ * Set if the algorithm is new and it is likely that the encoding may
+ * change in near future
+ */
+#define CRYPTO_ALG_UNSTABLE_ENCODING   0x8000
+
 /*
  * Transform masks and values (for crt_flags).
  */
-- 
2.14.1

[PATCH v7 2/5] crypto: add zBeWalgo to crypto-api

This patch adds zBeWalgo to the crypto api so that zBeWalgo can be used by
zram.

Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
---
 crypto/Kconfig |  12 
 crypto/Makefile|   1 +
 crypto/testmgr.c   |  10 +++
 crypto/testmgr.h   | 134 
 crypto/zbewalgo.c  | 164 +
 drivers/block/zram/zcomp.c |   3 +
 6 files changed, 324 insertions(+)
 create mode 100644 crypto/zbewalgo.c

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 76e8c88c..749457a6 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1686,6 +1686,18 @@ config CRYPTO_LZ4
help
  This is the LZ4 algorithm.
 
+config CRYPTO_ZBEWALGO
+   tristate "zBeWalgo compression algorithm"
+   select CRYPTO_ALGAPI
+   select CRYPTO_ACOMP2
+   select ZBEWALGO_COMPRESS
+   help
+ This is the zBeWalgo compression algorithm. This algorithm
+ accepts only input sizes of at most one page at once.
+ To achieve high compression ratios zbewalgo can call multiple
+ transformation and compression algorithms in a row to optimize
+ the compressed size.
+
 config CRYPTO_LZ4HC
tristate "LZ4HC compression algorithm"
select CRYPTO_ALGAPI
diff --git a/crypto/Makefile b/crypto/Makefile
index 4fc69fe9..493cbd65 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -124,6 +124,7 @@ obj-$(CONFIG_CRYPTO_CRCT10DIF) += crct10dif_common.o 
crct10dif_generic.o
 obj-$(CONFIG_CRYPTO_AUTHENC) += authenc.o authencesn.o
 obj-$(CONFIG_CRYPTO_LZO) += lzo.o
 obj-$(CONFIG_CRYPTO_LZ4) += lz4.o
+obj-$(CONFIG_CRYPTO_ZBEWALGO) += zbewalgo.o
 obj-$(CONFIG_CRYPTO_LZ4HC) += lz4hc.o
 obj-$(CONFIG_CRYPTO_842) += 842.o
 obj-$(CONFIG_CRYPTO_RNG2) += rng.o
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index af4a01c5..53fd43d1 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3611,6 +3611,16 @@ static const struct alg_test_desc alg_test_descs[] = {
.dec = __VECS(tf_xts_dec_tv_template)
}
}
+   }, {
+   .alg = "zbewalgo",
+   .test = alg_test_comp,
+   .fips_allowed = 1,
+   .suite = {
+   .comp = {
+   .comp = __VECS(zbewalgo_comp_tv_template),
+   .decomp = __VECS(zbewalgo_decomp_tv_template)
+   }
+   }
}, {
.alg = "zlib-deflate",
.test = alg_test_comp,
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 004c0a0f..960bfbcf 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -37009,6 +37009,140 @@ static const struct hash_testvec 
bfin_crc_tv_template[] = {
 
 };
 
+static const struct comp_testvec zbewalgo_comp_tv_template[] = {
+   {
+   .inlen  = 512,
+   .outlen = 402,
+   .input  =
+   
"\x8a\x3a\xf3\xbe\x33\xf9\xab\x3d\xa1\x51\x9f\x7f\xad\xf6\xab\x3d"
+   
"\xad\x29\x8f\x3c\x27\xf4\xab\x3d\x06\x19\xc3\xf5\xa0\xf1\xab\x3d"
+   
"\xfb\x75\x3b\xab\x1a\xef\xab\x3d\xe3\x96\xf8\x5c\x94\xec\xab\x3d"
+   
"\x13\xd2\xfa\x0a\x0e\xea\xab\x3d\xe0\x7d\x42\xb5\x87\xe7\xab\x3d"
+   
"\xa1\xf0\xcf\x5b\x01\xe5\xab\x3d\xad\x80\xa3\xfe\x7a\xe2\xab\x3d"
+   
"\x59\x84\xbd\x9d\xf4\xdf\xab\x3d\xff\x51\x1e\x39\x6e\xdd\xab\x3d"
+   
"\xf5\x3f\xc6\xd0\xe7\xda\xab\x3d\x96\xa4\xb5\x64\x61\xd8\xab\x3d"
+   
"\x3b\xd6\xec\xf4\xda\xd5\xab\x3d\x3b\x2b\x6c\x81\x54\xd3\xab\x3d"
+   
"\xf2\xf9\x33\x0a\xce\xd0\xab\x3d\xbb\x98\x44\x8f\x47\xce\xab\x3d"
+   
"\xed\x5d\x9e\x10\xc1\xcb\xab\x3d\xe7\x9f\x41\x8e\x3a\xc9\xab\x3d"
+   
"\x07\xb5\x2e\x08\xb4\xc6\xab\x3d\xa9\xf3\x65\x7e\x2d\xc4\xab\x3d"
+   
"\x28\xb2\xe7\xf0\xa6\xc1\xab\x3d\xe3\x46\xb4\x5f\x20\xbf\xab\x3d"
+   
"\x38\x08\xcc\xca\x99\xbc\xab\x3d\x85\x4c\x2f\x32\x13\xba\xab\x3d"
+   
"\x2a\x6a\xde\x95\x8c\xb7\xab\x3d\x85\xb7\xd9\xf5\x05\xb5\xab\x3d"
+   
"\xf7\x8a\x21\x52\x7f\xb2\xab\x3d\xe2\x3a\xb6\xaa\xf8\xaf\xab\x3d"
+   
"\xa5\x1d\x98\xff\x71\xad\xab\x3d\xa3\x89\xc7\x50\xeb\xaa\xab\x3d"
+   
"\x3d\xd5\x44\x9e\x64\xa8\xab\x3d\xd6\x56\x10\xe8\xdd\xa5\xab\x3d"
+   
"\xce\x64\x2a\x2e\x57\xa3\xab\x3d\x8d\x55\x93\x70\xd0\xa0\xab\x3d"
+   
"\x76\x7f\x4b\xaf\x49\x9e\xab\x3d\xeb\x38\x53\xea\xc2\x9b\xab\x3d"
+   
"\x53\xd8\xaa\x21\x3c\x99\xab\x3d\x13\xb4\x52\x55\xb5\x96\xab\x3d"
+   
"\x92\x22\x4b\x85\x2e\x94\xab\x3d\x35\x7a\x94\xb1\xa7\x91\xab\x3d"
+   
"\x65\x11\x2f\xda\x20\x8f\xab\x3d\x86\x3e

[PATCH v7 4/5] crypto: configurable compression level

Most compression algorithms published by the crypto api are supporting
multiple different compression levels. The crypto api currently just
calls these algorithms with their default compression level.

This patch enables the caller to specify the compression level.

Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
---
 crypto/api.c  | 76 +++
 crypto/deflate.c  | 16 +
 crypto/lz4.c  | 16 +
 crypto/lz4hc.c| 13 +---
 crypto/testmgr.c  |  2 +-
 drivers/block/zram/zcomp.c| 10 +++---
 drivers/block/zram/zcomp.h|  3 +-
 drivers/block/zram/zram_drv.c | 24 --
 drivers/block/zram/zram_drv.h |  1 +
 fs/pstore/platform.c  |  2 +-
 fs/ubifs/compress.c   |  2 +-
 include/linux/crypto.h|  9 +++--
 mm/zswap.c|  2 +-
 net/xfrm/xfrm_ipcomp.c|  3 +-
 14 files changed, 147 insertions(+), 32 deletions(-)

diff --git a/crypto/api.c b/crypto/api.c
index 1d5290c6..81c3d416 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -388,6 +388,47 @@ struct crypto_tfm *__crypto_alloc_tfm(struct crypto_alg 
*alg, u32 type,
 }
 EXPORT_SYMBOL_GPL(__crypto_alloc_tfm);
 
+struct crypto_tfm *__crypto_alloc_tfm_compress(struct crypto_alg *alg,
+  u32 type, u32 mask, int level)
+{
+   struct crypto_tfm *tfm = NULL;
+   unsigned int tfm_size;
+   int err = -ENOMEM;
+
+   tfm_size = sizeof(*tfm) + crypto_ctxsize(alg, type, mask);
+   tfm = kzalloc(tfm_size, GFP_KERNEL);
+   if (!tfm)
+   goto out_err;
+
+   tfm->__crt_alg = alg;
+   if (alg->cra_flags & CRYPTO_ALG_TYPE_COMPRESS)
+   tfm->crt_compress.cot_level = level;
+
+   err = crypto_init_ops(tfm, type, mask);
+   if (err)
+   goto out_free_tfm;
+
+   if (!tfm->exit && alg->cra_init) {
+   err = alg->cra_init(tfm);
+   if (err)
+   goto cra_init_failed;
+   }
+
+   goto out;
+
+cra_init_failed:
+   crypto_exit_ops(tfm);
+out_free_tfm:
+   if (err == -EAGAIN)
+   crypto_shoot_alg(alg);
+   kfree(tfm);
+out_err:
+   tfm = ERR_PTR(err);
+out:
+   return tfm;
+}
+EXPORT_SYMBOL_GPL(__crypto_alloc_tfm_compress);
+
 /*
  * crypto_alloc_base - Locate algorithm and allocate transform
  * @alg_name: Name of algorithm
@@ -444,6 +485,41 @@ struct crypto_tfm *crypto_alloc_base(const char *alg_name, 
u32 type, u32 mask)
 }
 EXPORT_SYMBOL_GPL(crypto_alloc_base);
 
+struct crypto_tfm *crypto_alloc_base_compress(const char *alg_name, u32 type,
+ u32 mask, int level)
+{
+   struct crypto_tfm *tfm;
+   int err;
+
+   for (;;) {
+   struct crypto_alg *alg;
+
+   alg = crypto_alg_mod_lookup(alg_name, type, mask);
+   if (IS_ERR(alg)) {
+   err = PTR_ERR(alg);
+   goto err;
+   }
+
+   tfm = __crypto_alloc_tfm_compress(alg, type, mask, level);
+   if (!IS_ERR(tfm))
+   return tfm;
+
+   crypto_mod_put(alg);
+   err = PTR_ERR(tfm);
+
+err:
+   if (err != -EAGAIN)
+   break;
+   if (fatal_signal_pending(current)) {
+   err = -EINTR;
+   break;
+   }
+   }
+
+   return ERR_PTR(err);
+}
+EXPORT_SYMBOL_GPL(crypto_alloc_base_compress);
+
 void *crypto_create_tfm(struct crypto_alg *alg,
const struct crypto_type *frontend)
 {
diff --git a/crypto/deflate.c b/crypto/deflate.c
index 4b681a37..54a2ff21 100644
--- a/crypto/deflate.c
+++ b/crypto/deflate.c
@@ -24,6 +24,7 @@
  * it is not needed for IPCOMP and keeps the code simpler.  It can be
  * implemented if someone wants it.
  */
+
 #include 
 #include 
 #include 
@@ -43,7 +44,7 @@ struct deflate_ctx {
struct z_stream_s decomp_stream;
 };
 
-static int deflate_comp_init(struct deflate_ctx *ctx, int format)
+static int deflate_comp_init(struct deflate_ctx *ctx, int format, int level)
 {
int ret = 0;
struct z_stream_s *stream = &ctx->comp_stream;
@@ -55,9 +56,9 @@ static int deflate_comp_init(struct deflate_ctx *ctx, int 
format)
goto out;
}
if (format)
-   ret = zlib_deflateInit(stream, 3);
+   ret = zlib_deflateInit(stream, level);
else
-   ret = zlib_deflateInit2(stream, DEFLATE_DEF_LEVEL, Z_DEFLATED,
+   ret = zlib_deflateInit2(stream, level, Z_DEFLATED,
-DEFLATE_DEF_WINBITS,
DEFLATE_DEF_MEMLEVEL,
Z_DEFAULT_STRATEGY);
@@ -109,11 +110,11 @@ static void deflate_decomp_exit(struct deflate

[PATCH v7 3/5] crypto: add unsafe decompression to api

Up to Version 3 of this patch the decompressor of zbewalgo did not verify
that there is no overflow in the output buffer. Now zbewalgo includes a
safe decompressor which does check for buffer overflows and heap-error.
ZBewalgo and other Algorithms like lz4 include an unsafe decompressor version,
which is a bit faster, but does no error checking. These unsafe decompressors
can be applied when the datasource and the whole datapath is trusted.

This patch publishes these existing functions in the crypto-api

Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
---
 crypto/842.c |  3 ++-
 crypto/compress.c| 10 ++
 crypto/crypto_null.c |  3 ++-
 crypto/deflate.c |  3 ++-
 crypto/lz4.c | 23 ++-
 crypto/lz4hc.c   | 23 ++-
 crypto/lzo.c |  3 ++-
 crypto/testmgr.c | 27 ++-
 crypto/zbewalgo.c| 29 -
 drivers/block/zram/zram_drv.c| 34 +-
 drivers/block/zram/zram_drv.h|  1 +
 drivers/crypto/cavium/zip/zip_main.c |  6 --
 drivers/crypto/nx/nx-842-powernv.c   |  3 ++-
 drivers/crypto/nx/nx-842-pseries.c   |  3 ++-
 include/linux/crypto.h   | 16 
 15 files changed, 174 insertions(+), 13 deletions(-)

diff --git a/crypto/842.c b/crypto/842.c
index bc26dc94..7e74ea26 100644
--- a/crypto/842.c
+++ b/crypto/842.c
@@ -112,7 +112,8 @@ static struct crypto_alg alg = {
.cra_exit   = crypto842_exit,
.cra_u  = { .compress = {
.coa_compress   = crypto842_compress,
-   .coa_decompress = crypto842_decompress } }
+   .coa_decompress = crypto842_decompress,
+   .coa_decompress_unsafe  = crypto842_decompress } }
 };
 
 static struct scomp_alg scomp = {
diff --git a/crypto/compress.c b/crypto/compress.c
index f2d52292..bec79624 100644
--- a/crypto/compress.c
+++ b/crypto/compress.c
@@ -33,12 +33,22 @@ static int crypto_decompress(struct crypto_tfm *tfm,
   dlen);
 }
 
+static int crypto_decompress_unsafe(struct crypto_tfm *tfm,
+   const u8 *src, unsigned int slen,
+u8 *dst, unsigned int *dlen)
+{
+   return tfm->__crt_alg->cra_compress.coa_decompress_unsafe(tfm, src,
+ slen, dst,
+ dlen);
+}
+
 int crypto_init_compress_ops(struct crypto_tfm *tfm)
 {
struct compress_tfm *ops = &tfm->crt_compress;
 
ops->cot_compress = crypto_compress;
ops->cot_decompress = crypto_decompress;
+   ops->cot_decompress_unsafe = crypto_decompress_unsafe;
 
return 0;
 }
diff --git a/crypto/crypto_null.c b/crypto/crypto_null.c
index 20ff2c74..6e15e8c0 100644
--- a/crypto/crypto_null.c
+++ b/crypto/crypto_null.c
@@ -146,7 +146,8 @@ static struct crypto_alg null_algs[3] = { {
.cra_module =   THIS_MODULE,
.cra_u  =   { .compress = {
.coa_compress   =   null_compress,
-   .coa_decompress =   null_compress } }
+   .coa_decompress =   null_compress,
+   .coa_decompress_unsafe  =   null_compress } }
 } };
 
 MODULE_ALIAS_CRYPTO("compress_null");
diff --git a/crypto/deflate.c b/crypto/deflate.c
index 94ec3b36..4b681a37 100644
--- a/crypto/deflate.c
+++ b/crypto/deflate.c
@@ -286,7 +286,8 @@ static struct crypto_alg alg = {
.cra_exit   = deflate_exit,
.cra_u  = { .compress = {
.coa_compress   = deflate_compress,
-   .coa_decompress = deflate_decompress } }
+   .coa_decompress = deflate_decompress,
+   .coa_decompress_unsafe  = deflate_decompress } }
 };
 
 static struct scomp_alg scomp[] = { {
diff --git a/crypto/lz4.c b/crypto/lz4.c
index 2ce2660d..60a1914b 100644
--- a/crypto/lz4.c
+++ b/crypto/lz4.c
@@ -103,6 +103,19 @@ static int __lz4_decompress_crypto(const u8 *src, unsigned 
int slen,
return 0;
 }
 
+static int __lz4_decompress_crypto_unsafe(const u8 *src, unsigned int slen,
+ u8 *dst, unsigned int *dlen,
+  void *ctx)
+{
+   int out_len = LZ4_decompress_fast(src, dst, *dlen);
+
+   if (out_len < 0)
+   return -EINVAL;
+
+   *dlen = out_len;
+   return 0;
+}
+
 static int lz4_sdecompress(struct crypto_scomp *tfm, const u8 *src,
   unsigned int slen, u8 *dst, unsigned int *dlen,
   void *ctx)
@@ -117,6 +130,13 @@ static int lz4_decompress_crypto(struct crypto_

[PATCH v7 1/5] add compression algorithm zBeWalgo

zBeWalgo is a completely new algorithm - Currently it is not published
somewhere else right now, googleing it would not show up any results. The
following section describes how the algorithm works.

zBeWalgo itself is a container compression algorithm, which can execute
multiple different compression and transformation algorithms after each other.
The execution of different compression algorithms after each other will be
called 'combination' in this description and in the code. Additionally to be
able to execute combinations of algorithms, zBeWalgo can try different
combinations on the same input. This allows high compression ratios on
completely different datasets, which would otherwise require its own
algorithm each. Executing all known combinations on each input page would be
very slow. Therefore the data is compressed at first with that combination,
which was already successful on the last input page. If the compressed data
size of the current page is similar to that of the last page, the compressed
data is returned immediately without even trying the other combinations. Even
if there is no guarantee that consecutive calls to the algorithm belong to
each other, the speed improvement is obvious.

ZRAM uses zsmalloc for the management of the compressed pages. The largest
size-class in zsmalloc is 3264 Bytes. If the compressed data is larger than
that threshold, ZRAM ignores the compression and writes the uncompressed page
instead. As a consequence it is useless to continue compression, if the
algorithm detects, that the data can not be compressed using the current
combination. The threshold for aborting compression can be changed via sysfs at
any time, even if the algorithm is currently in use. If a combination fails to
compress the data, zBeWalgo tries the next combination. If no combination is
able to reduce the data in size, zBeWalgo returns a negative value.

Each combination consists of up to 7 compression and transformation steps.
Combinations can be added and removed at any time via sysfs. Already compressed
Data can always be decompressed, even if the combination used to produce it
does not exist anymore. Technically the user could add up to 256 combinations
concurrently, but that would be very time consuming if the data can not be
compressed.

To be able to build combinations and call different algorithms, all those
algorithms are implementing the same interface. This enables the user to
specify additional combinations while ZRAM is running.

Within the combinations many different algorithms can be used. Some of those
algorithms are published. This patch adds the following algorithms to be used
within the combinations:
- bwt: The Burrows-Wheeler-Transformation was published by 'M. Burrows' and
'D. J. Wheeler' in 1994. This implementation uses counting sort for
sorting the data. Their original paper is online available at:
http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-124.pdf
- mtf: The Move-To-Front algorithm as described by 'M. Burrows' and
'D. J. Wheeler' in the same paper as bwt.
- jbe: j-bit-encoding as proposed by 'I Made Agus Dwi Suarjaya' in 2012.
https://arxiv.org/pdf/1209.1045.pdf
- jbe2: A minor modification of jbe. Swapping groups of 4 Bit in consecutive
Bytes can increase the compression ratio, if for example the first
4 Bits of each Byte are zero. If jbe2 is called after mtf, this
happens ofthen.
- rle: Run Length Encoding
- huffman: Huffman encoding
- bewalgo: I invented this algorithm for my bachelors thesis
'Page-Based compression in the Linux Kernel'. This algorithm is
mainly inspired by lz4, focusing on increasing the speed even more,
with the help of page aligned read an write access. To achieve the
page alignment, the input and output data is accessed only in
blocks of 8 Bytes, therefore the encoding of the compressed data is
changed.

https://wr.informatik.uni-hamburg.de/_media/research:theses:benjamin_warnke_page_based_compression_in_the_linux_kernel.pdf
- bewalgo2: At the beginning of my work to improve ZRAM this was the whole
algorithm. The input is read in blocks of 8 Bytes. These Blocks
are added to an avl-tree. The avl-tree is mapped directly to an
array. The encoding is a variation of Run Length Encoding using the
indices in the avl-tree as data. The reason for using the tree
with indices is, that the indices can be encoded in less then
8 Bytes each.

[PATCH v7 0/5] add compression algorithm zBeWalgo

This patch series adds a new compression algorithm to the kernel and to
the crypto api.

Changes since v6:
- Fixed git apply error due to other recently applied patches

Changes since v5:
- Fixed compile-error due to variable definitions inside #ifdef 
CONFIG_ZRAM_WRITEBACK

Changes since v4:
- Fix mismatching function-prototypes
- Fix mismatching License errors
- Add static to global vars
- Add ULL to long constants

Changes since v3:
- Split patch into patchset
- Add Zstd = Zstandard to the list of benchmarked algorithms
- Added configurable compression levels to crypto-api
- Added multiple compression levels to the benchmarks below
- Added unsafe decompressor functions to crypto-api
- Added flag to mark unstable algorithms to crypto-api
- Test the code using afl-fuzz -> and fix the code
- Added 2 new Benchmark datasets
- checkpatch.pl fixes

Changes since v2:
- added linux-kernel Mailinglist

Changes since v1:
- improved documentation
- improved code style
- replaced numerous casts with get_unaligned*
- added tests in crypto/testmgr.h/c
- added zBeWalgo to the list of algorithms shown by 
/sys/block/zram0/comp_algorithm


Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM
compresses each page individually. As a result the compression algorithm is
forced to use a very small sliding window. None of the available compression
algorithms is designed to achieve high compression ratios with small inputs.

This patch-set adds a new compression algorithm 'zBeWalgo' to the crypto api.
This algorithm focusses on increasing the capacity of the compressed
block-device created by ZRAM. The choice of compression algorithms is always
a tradeoff between speed and compression ratio.

If faster algorithms like 'lz4' are chosen the compression ratio is often
lower than the ratio of zBeWalgo as shown in the following benchmarks. Due to
the lower compression ratio, ZRAM needs to fall back to backing_devices
mode often. If backing_devices are required, the effective speed of ZRAM is a
weighted average of de/compression time and writing/reading from the
backing_device. This should be considered when comparing the speeds in the
benchmarks.

There are different kinds of backing_devices, each with its own drawbacks.
1. HDDs: This kind of backing device is very slow. If the compression ratio
of an algorithm is much lower than the ratio of zBeWalgo, it might be faster
to use zBewalgo instead.
2. SSDs: I tested a swap partition on my NVME-SSD. The speed is even higher
than zram with lz4, but after about 5 Minutes the SSD is blocking all
read/write requests due to overheating. This is definitly not an option.


Benchmarks:


To obtain reproducable benchmarks, the datasets were first loaded into a
userspace-program. Than the data is written directly to a clean
zram-partition without any filesystem. Between writing and reading 'sync'
and 'echo 3 > /proc/sys/vm/drop_caches' is called. All time measurements are
wall clock times, and the benchmarks are using only one cpu-core at a time.
The new algorithm is compared to all available compression algorithms from
the crypto-api.

Before loading the datasets to user-space deduplication is applied, since
none Algorithm has deduplication. Duplicated pages are removed to
prevent an algorithm to obtain high/low ratios, just because a single page can
be compressed very well - or not.

All Algorithms marked with '*' are using unsafe decompression.

All Read and Write Speed Measurements are given in MBit/s

zbewalgo' uses per dataset specialized different combinations. These can be
specified at runtime via /sys/kernel/zbewalgo/combinations.


- '/dev/zero' This dataset is used to measure the speed limitations
for ZRAM. ZRAM filters zero-data internally and does not even call the
specified compression algorithm.

Algorithm   writeread
--zram--  2724.08 2828.87


- 'ecoham' This dataset is one of the input files for the scientific
application ECOHAM which runs an ocean simulation. This dataset contains a
lot of zeros - even after deduplication. Where the data is not zero there are
arrays of floating point values, adjacent float values are likely to be
similar to each other, allowing for high compression ratios.

zbewalgo reaches very high compression ratios and is a lot faster than other
algorithms with similar compression ratios.

Algorithmratiowrite read
--hdd--   1.00   134.70   156.62
lz4*_10   6.73  1303.12  1547.17
lz4_106.73  1303.12  1574.51
lzo   6.88  1205.98  1468.09
lz4*_05   7.00  1291.81  1642.41
lz4_057.00  1291.81  1682.81
lz4_077.13  1250.29  1593.89
lz4*_07   7.13  1250.29  1677.08
lz4_067.16  1307.62  1666.66
lz4*_06   7.16  1307.62  1669.42
lz4_037.21  1250.87  1449.48
lz4*_03   7.21  1250.87  1621.97
lz4*_04   7.23  1281.62  1645.56
lz4_047.23  1281.62  1666.81
lz4_027.33  1267.54  1523.11
lz4*_02   7.33  1267.54  1576.54
lz4_097.36  114

Re: [PATCH 8/8] drm/arm/malidp: Added the late system pm functions

2018-04-13 Thread Daniel Vetter

On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote:
> Hi Daniel,
> 
> On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
> > On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
> > > On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> > > > On Tue, Mar 27, 2018 at 11:59 AM, Ayan Halder  
> > > > wrote:
> > > > > On Tue, Mar 27, 2018 at 10:29:03AM +0200, Daniel Vetter wrote:
> > > > >> On Mon, Mar 26, 2018 at 06:03:20PM +0100, Ayan Kumar Halder wrote:
> > > > >> > malidp_pm_suspend_late checks if the runtime status is not 
> > > > >> > suspended
> > > > >> > and if so, invokes malidp_runtime_pm_suspend which disables the
> > > > >> > display engine/core interrupts and the clocks. It sets the runtime 
> > > > >> > status
> > > > >> > as suspended. Subsequently, malidp_pm_resume_early will invoke
> > > > >> > malidp_runtime_pm_resume which enables the clocks and the 
> > > > >> > interrupts
> > > > >> > (previously disabled) and sets the runtime status as active.
> > > > >> >
> > > > >> > Signed-off-by: Ayan Kumar Halder 
> > > > >> > Change-Id: I5f8c3d28f076314a1c9da2a46760a9c37039ccda
> > > > >>
> > > > >> Why exactly do you need late/early hooks? If you have dependencies 
> > > > >> with
> > > > >> other devices, pls consider adding device_links instead. This here
> > > > >> shouldn't be necessary.
> > > > >> -Daniel
> > > > > We need to late/early hooks to disable malidp interrupts and the
> > > > > clocks.
> > > >
> > > > Yes, but why this ordering constraint? Why can't you just disable the
> > > > interrupts/clocks in the normal suspend code. I see that the patch
> > > > does this, I want to understand why it does it.
> > > > -Daniel
> > > Apologies for my delayed response on this.
> > > 
> > > With reference to https://lwn.net/Articles/505683/ :-
> > > 1. "suspend() should leave the device in a quiescent state." We invoke
> > > drm_mode_config_helper_suspend() which deactivates the crtc. I
> > > understand that this is the quiescent state.
> > > 
> > > 2. "suspend_late() can often be the same as runtime_suspend()."  We
> > > invoke runtime suspend/resume calls in late/early hooks.
> > 
> > This article is from 2012. That's not really recommended best practices
> > anymore. device_links have only been added a few years ago, so ofc an
> > article from 2012 can't tell you that you should use those instead :-)
> > 
> > That's why I brought this up, we have much better ways to handle device
> > dependencies now.
> > 
> 
> We aren't trying to manage any device dependencies here, I don't know
> where that idea came from?
> 
> The kernel-doc on drm-next this afternoon says effectively the same
> thing:
> 
>   * @suspend: Executed before putting the system into a sleep state in which 
> the
>   *  contents of main memory are preserved.  The exact action to perform
>   *  depends on the device's subsystem (PM domain, device type, class or 
> bus
>   *  type), but generally the device must be quiescent after 
> subsystem-level
>   *  @suspend() has returned, so that it doesn't do any I/O or DMA.
>   *  Subsystem-level @suspend() is executed for all devices after invoking
>   *  subsystem-level @prepare() for all of them.
> 
> (i.e. suspend() makes the device quiescent).
> 
>   * @suspend_late: Continue operations started by @suspend().  For a number of
>   *  devices @suspend_late() may point to the same callback routine as the
>   *  runtime suspend callback.
> 
> (suggests suspend_late() be assigned to the same function as runtime
> suspend).
> 
> As for why, my understanding is like so:
> 
> For ->suspend(), we use the DRM helper, which disables the CRTC.
> Normally disabling the CRTC would be enough to also invoke our
> pm_runtime callback to do the final clock disable etc., however when a
> system suspend is in-progress, the core forcibly takes a runtime
> reference on all devices - preventing any pm_runtime paths from
> running.

I thought this was fixed. At least I remember we had to add some special
calls to i915 to opt out of the "do runtime pm as part of suspend/resume"
behaviour, since it doesn't match what we needed.

See

commit aae4518b3124b29f8dc81c829c704fd2df72e98b
Author: Rafael J. Wysocki 
Date:   Fri May 16 02:46:50 2014 +0200

PM / sleep: Mechanism to avoid resuming runtime-suspended devices 
unnecessarily

So I thought this stuff was supposed to work now. Adding Rafael Wyzocki,
he's done plenty presentations recently about exactly this.

> This means that after the CRTC is disabled in ->suspend(), our normal
> pm_runtime path will not be invoked, and so the things done in
> malidp_runtime_pm_suspend() will never happen.
> 
> We were just following the advice in the kernel-doc to deal with this.
> 
> The alternative would be to call malidp_runtime_pm_{suspend,resume}
> from the "not late" hooks, but I'd ask why?
> 
> > Also, you still haven't explained what exactly the dependency is.
> 
> Because there isn't one

RE: [PATCH v3 2/2] MIPS: io: add a barrier after register read in readX()

2018-04-13 Thread David Laight

From: James Hogan
> Sent: 12 April 2018 22:52
> On Tue, Apr 03, 2018 at 08:55:04AM -0400, Sinan Kaya wrote:
> > While a barrier is present in writeX() function before the register write,
> > a similar barrier is missing in the readX() function after the register
> > read. This could allow memory accesses following readX() to observe
> > stale data.
> >
> > Signed-off-by: Sinan Kaya 
> > Reported-by: Arnd Bergmann 
> 
> Both patches look like obvious improvements to me, so I'm happy to apply
> to my fixes branch.

Don't you also need at least barrier() between the register write in writeX()
and the register read in readX()?
On ppc you probably need eieio.
Or are drivers expected to insert that one?
If they need to insert that one then why not all the others??

David

[GIT PULL] arch/sh updates for 4.17

2018-04-13 Thread Rich Felker

Hi Linus,

Please pull these changes for arch/sh. Some of them have been pending
(and in linux-next) for a long time and address longstanding issues.

Rich




The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda:

  Linux 4.16 (2018-04-01 14:20:27 -0700)

are available in the git repository at:

  git://git.libc.org/linux-sh tags/sh-for-4.17

for you to fetch changes up to bf9c7e3d7924f72225f8f9c28438b4a711192ad3:

  arch/sh: pcie-sh7786: handle non-zero DMA offset (2018-04-12 19:47:58 -0400)


Fixes for bugs in futex, device tree, and userspace breakpoint traps,
and for PCI issues on SH7786.


Aurelien Jarno (1):
  sh: fix futex FUTEX_OP_SET op on userspace addresses

Rich Felker (2):
  sh: fix memory corruption of unflattened device tree
  sh: fix debug trap failure to process signals before return to user

Thomas Petazzoni (8):
  arch/sh: add sh7786_mm_sel() function
  arch/sh: make the DMA mapping operations observe dev->dma_pfn_offset
  arch/sh: pci: don't use disabled resources
  arch/sh: pcie-sh7786: mark unavailable PCI resource as disabled
  arch/sh: pcie-sh7786: exclude unusable PCI MEM areas
  arch/sh: pcie-sh7786: adjust PCI MEM and IO regions
  arch/sh: pcie-sh7786: adjust the memory mapping
  arch/sh: pcie-sh7786: handle non-zero DMA offset

 arch/sh/boards/of-generic.c  |  6 ---
 arch/sh/drivers/pci/pci.c|  5 +++
 arch/sh/drivers/pci/pcie-sh7786.c| 78 +---
 arch/sh/include/asm/futex.h  |  5 +--
 arch/sh/include/cpu-sh4/cpu/sh7786.h |  7 
 arch/sh/kernel/dma-nommu.c   |  7 +++-
 arch/sh/kernel/entry-common.S|  2 +-
 arch/sh/kernel/setup.c   |  8 
 arch/sh/mm/consistent.c  |  4 +-
 9 files changed, 84 insertions(+), 38 deletions(-)

Re: [PATCH v5 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

2018-04-13 Thread Lina Iyer


On Tue, Apr 10 2018 at 22:39 -0600, Stephen Boyd wrote:

Quoting Lina Iyer (2018-04-05 09:18:25)

Add controller driver for QCOM SoCs that have hardware based shared
resource management. The hardware IP known as RSC (Resource State
Coordinator) houses multiple Direct Resource Voter (DRV) for different
execution levels. A DRV is a unique voter on the state of a shared
resource. A Trigger Control Set (TCS) is a bunch of slots that can house
multiple resource state requests, that when triggered will issue those
requests through an internal bus to the Resource Power Manager Hardened
(RPMH) blocks. These hardware blocks are capable of adjusting clocks,
voltages, etc. The resource state request from a DRV are aggregated along
with state requests from other processors in the SoC and the aggregate
value is applied on the resource.

Some important aspects of the RPMH communication -
- Requests are  with some header information
- Multiple requests (upto 16) may be sent through a TCS, at a time
- Requests in a TCS are sent in sequence
- Requests may be fire-n-forget or completion (response expected)
- Multiple TCS from the same DRV may be triggered simultaneously
- Cannot send a request if another requesit for the same addr is in


s/requesit/request/


Ok.

  progress from the same DRV
- When all the requests from a TCS are complete, an IRQ is raised
- The IRQ handler needs to clear the TCS before it is available for
  reuse
- TCS configuration is specific to a DRV
- Platform drivers may use DRV from different RSCs to make requests


This last point is sort of not true anymore? At least my understanding
is that platform drivers are children of the rsc and that they can only
use that rsc to do anything with rpmh.


Platform drivers may talk to multiple RSC+DRV instances and make
requests from those DRVs.



Resource state requests made when CPUs are active are called 'active'
state requests. Requests made when all the CPUs are powered down (idle
state) are called 'sleep' state requests. They are matched by a
corresponding 'wake' state requests which puts the resources back in to
previously requested active state before resuming any CPU. TCSes are
dedicated for each type of requests. Control TCS are used to provide
specific information to the controller.


Can you mention AMC here too? I see the acronym but no definition of
what it is besides "Active or AMC" which may indicate A == Active.


Ok.



diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h
new file mode 100644
index ..aa73ec4b3e42
--- /dev/null
+++ b/drivers/soc/qcom/rpmh-internal.h
@@ -0,0 +1,89 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
+ */
+
+
+#ifndef __RPM_INTERNAL_H__
+#define __RPM_INTERNAL_H__
+
+#include 
+#include 
+
+#define TCS_TYPE_NR4
+#define MAX_CMDS_PER_TCS   16
+#define MAX_TCS_PER_TYPE   3
+#define MAX_TCS_NR (MAX_TCS_PER_TYPE * TCS_TYPE_NR)
+
+struct rsc_drv;
+
+/**
+ * struct tcs_response: Response object for a request
+ *
+ * @drv:   the controller
+ * @msg:   the request for this response
+ * @m: the tcs identifier
+ * @err:   error reported in the response
+ * @list:  element in list of pending response objects
+ */
+struct tcs_response {
+   struct rsc_drv *drv;
+   const struct tcs_request *msg;
+   u32 m;
+   int err;
+   struct list_head list;
+};
+
+/**
+ * struct tcs_group: group of Trigger Command Sets for a request state


Put (ACRONYM) for the acronyms that are spelled out the first time
please. Also, make sure we know what 'request state' is.


Its already in the commit text, but sure.


+ *
+ * @drv:   the controller
+ * @type:  type of the TCS in this group - active, sleep, wake


Now 'group' means 'request state'?


Group of TCSes. TCSes are grouped based on their use - sending requests
for active, sleep and wake.


+ * @mask:  mask of the TCSes relative to all the TCSes in the RSC
+ * @offset:start of the TCS group relative to the TCSes in the RSC
+ * @num_tcs:   number of TCSes in this type
+ * @ncpt:  number of commands in each TCS
+ * @lock:  lock for synchronizing this TCS writes
+ * @responses: response objects for requests sent from each TCS
+ */
+struct tcs_group {
+   struct rsc_drv *drv;
+   int type;


Is type supposed to be an enum?


Uses the #defines from include/dt-bindings/qcom,rpmh-rsc.txt.


+   u32 mask;
+   u32 offset;
+   int num_tcs;
+   int ncpt;
+   spinlock_t lock;
+   struct tcs_response *responses[MAX_TCS_PER_TYPE];
+};
+
+/**
+ * struct rsc_drv: the Resource State Coordinator controller
+ *
+ * @name:   controller identifier
+ * @tcs_base:   start address of the TCS registers in this controller
+ * @id: instance id in the controller (Direct Resource Voter)
+ * @num_tcs:number of TCSes in this DRV


It changed from an RSC

Re: [RfC PATCH] Add udmabuf misc device

2018-04-13 Thread Daniel Vetter

On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote:
> On 04/10/2018 08:26 PM, Dongwon Kim wrote:
> > On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/06/2018 09:57 PM, Dongwon Kim wrote:
> > > > On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote:
> > > > > On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:
> > > > > >Hi,
> > > > > > 
> > > > > > > > I fail to see any common ground for xen-zcopy and udmabuf ...
> > > > > > > Does the above mean you can assume that xen-zcopy and udmabuf
> > > > > > > can co-exist as two different solutions?
> > > > > > Well, udmabuf route isn't fully clear yet, but yes.
> > > > > > 
> > > > > > See also gvt (intel vgpu), where the hypervisor interface is 
> > > > > > abstracted
> > > > > > away into a separate kernel modules even though most of the actual 
> > > > > > vgpu
> > > > > > emulation code is common.
> > > > > Thank you for your input, I'm just trying to figure out
> > > > > which of the three z-copy solutions intersect and how much
> > > > > > > And what about hyper-dmabuf?
> > > > xen z-copy solution is pretty similar fundamentally to hyper_dmabuf
> > > > in terms of these core sharing feature:
> > > > 
> > > > 1. the sharing process - import prime/dmabuf from the producer -> 
> > > > extract
> > > > underlying pages and get those shared -> return references for shared 
> > > > pages
> > Another thing is danvet was kind of against to the idea of importing 
> > existing
> > dmabuf/prime buffer and forward it to the other domain due to 
> > synchronization
> > issues. He proposed to make hyper_dmabuf only work as an exporter so that it
> > can have a full control over the buffer. I think we need to talk about this
> > further as well.
> Yes, I saw this. But this limits the use-cases so much.
> For instance, running Android as a Guest (which uses ION to allocate
> buffers) means that finally HW composer will import dma-buf into
> the DRM driver. Then, in case of xen-front for example, it needs to be
> shared with the backend (Host side). Of course, we can change user-space
> to make xen-front allocate the buffers (make it exporter), but what we try
> to avoid is to change user-space which in normal world would have remain
> unchanged otherwise.
> So, I do think we have to support this use-case and just have to understand
> the complexity.

Erm, why do you need importer capability for this use-case?

guest1 -> ION -> xen-front -> hypervisor -> guest 2 -> xen-zcopy exposes
that dma-buf -> import to the real display hw

No where in this chain do you need xen-zcopy to be able to import a
dma-buf (within linux, it needs to import a bunch of pages from the
hypervisor).

Now if your plan is to use xen-zcopy in the guest1 instead of xen-front,
then you indeed need to import. But that imo doesn't make sense:
- xen-front gives you clearly defined flip events you can forward to the
  hypervisor. xen-zcopy would need to add that again. Same for
  hyperdmabuf (and really we're not going to shuffle struct dma_fence over
  the wire in a generic fashion between hypervisor guests).

- xen-front already has the idea of pixel format for the buffer (and any
  other metadata). Again, xen-zcopy and hyperdmabuf lack that, would need
  to add it shoehorned in somehow.

Ofc you won't be able to shovel sound or media stream data over to another
guest like this, but that's what you have xen-v4l and xen-sound or
whatever else for. Trying to make a new uapi, which means userspace must
be changed for all the different use-case, instead of reusing standard
linux driver uapi (which just happens to send the data to another
hypervisor guest instead of real hw) imo just doesn't make much sense.

Also, at least for the gpu subsystem: Any new uapi must have full
userspace available for it, see:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

Adding more uapi is definitely the most painful way to fix a use-case.
Personally I'd go as far and also change the xen-zcopy side on the
receiving guest to use some standard linux uapi. E.g. you could write an
output v4l driver to receive the frames from guest1.

> > danvet, can you comment on this topic?
> > 
> > > > 2. the page sharing mechanism - it uses Xen-grant-table.
> > > > 
> > > > And to give you a quick summary of differences as far as I understand
> > > > between two implementations (please correct me if I am wrong, 
> > > > Oleksandr.)
> > > > 
> > > > 1. xen-zcopy is DRM specific - can import only DRM prime buffer
> > > > while hyper_dmabuf can export any dmabuf regardless of originator
> > > Well, this is true. And at the same time this is just a matter
> > > of extending the API: xen-zcopy is a helper driver designed for
> > > xen-front/back use-case, so this is why it only has DRM PRIME API
> > > > 2. xen-zcopy doesn't seem to have dma-buf synchronization between two 
> > > > VMs
> > > > while (as danvet called it as remote dmabu

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

2018-04-13 Thread Paolo Bonzini

On 13/04/2018 14:40, Raslan, KarimAllah wrote:
>>  
>>  static void update_ia32_tsc_adjust_msr(struct kvm_vcpu *vcpu, s64 offset)
>>  {
>> -u64 curr_offset = vcpu->arch.tsc_offset;
>> +u64 curr_offset = kvm_x86_ops->read_l1_tsc_offset(vcpu);
> I might be missing something but is this really strictly needed or is
> it really a bug?
> 
> I can see update_ia32_tsc_adjust_msr called from kvm_write_tsc only 
> which is called from a) vmx_set_msr or b) kvm_arch_vcpu_postcreate.
> The adjust_msr would only be called if !host_initiated. So only 
> vmx_set_msr which is coming from an L1 write (or a restore but that
> would not be !host_initiated). So the only that tsc_adjust is called is
> !is_guest_mode.

It can also be called from guest mode if the MSR bitmap says there's no
L1 vmexit for that MSR; that's what the testcases do.

Paolo

>>  vcpu->arch.ia32_tsc_adjust_msr += offset - curr_offset;

RE: [PATCH v5 05/14] PCI: Add pcie_print_link_status() to log link speed and whether it's limited

2018-04-13 Thread Keller, Jacob E



> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Friday, April 13, 2018 7:07 AM
> To: Jakub Kicinski 
> Cc: Tal Gilboa ; Tariq Toukan ;
> Keller, Jacob E ; Ariel Elior 
> ;
> Ganesh Goudar ; Kirsher, Jeffrey T
> ; everest-linux...@cavium.com; intel-wired-
> l...@lists.osuosl.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-...@vger.kernel.org
> Subject: Re: [PATCH v5 05/14] PCI: Add pcie_print_link_status() to log link 
> speed
> and whether it's limited
> 
> On Thu, Apr 12, 2018 at 09:32:49PM -0700, Jakub Kicinski wrote:
> > On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote:
> > > + if (bw_avail >= bw_cap)
> > > + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n",
> > > +  bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);
> > > + else
> > > + pci_info(dev, "%d Mb/s available bandwidth, limited by %s x%d
> link at %s (capable of %d Mb/s with %s x%d link)\n",
> > > +  bw_avail, PCIE_SPEED2STR(speed), width,
> > > +  limiting_dev ? pci_name(limiting_dev) : "",
> > > +  bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);
> >
> > I was just looking at using this new function to print PCIe BW for a
> > NIC, but I'm slightly worried that there is nothing in the message that
> > says PCIe...  For a NIC some people may interpret the bandwidth as NIC
> > bandwidth:
> >
> > [   39.839989] nfp :04:00.0: Netronome Flow Processor NFP4000/NFP6000
> PCIe Card Probe
> > [   39.848943] nfp :04:00.0: 63.008 Gb/s available bandwidth (8 GT/s x8 
> > link)
> > [   39.857146] nfp :04:00.0: RESERVED BARs: 0.0: General/MSI-X SRAM, 
> > 0.1:
> PCIe XPB/MSI-X PBA, 0.4: Explicit0, 0.5: Explicit1, fre4
> >
> > It's not a 63Gbps NIC...  I'm sorry if this was discussed before and I
> > didn't find it.  Would it make sense to add the "PCIe: " prefix to the
> > message like bnx2x used to do?  Like:
> >
> > nfp :04:00.0: PCIe: 63.008 Gb/s available bandwidth (8 GT/s x8 link)
> 
> I agree, that does look potentially confusing.  How about this:
> 
>   nfp :04:00.0: 63.008 Gb/s available PCIe bandwidth (8 GT/s x8 link)
> 
> I did have to look twice at this before I remembered that we're
> printing Gb/s (not GB/s).  Most of the references I found on the web
> use GB/s when talking about total PCIe bandwidth.
> 
> But either way I think it's definitely worth mentioning PCIe
> explicitly.

I also agree printing PCIe explicitly is good.

Thanks,
Jake

Re: [PATCHv2 1/3] dt-bindings: misc: achc: Make ezport distinguishable

On Mon, Apr 9, 2018 at 4:13 PM, Sebastian Reichel
 wrote:
> Hi,
>
> On Mon, Apr 09, 2018 at 01:57:27PM -0500, Rob Herring wrote:
>> On Tue, Mar 27, 2018 at 03:52:57PM +0200, Sebastian Reichel wrote:
>> > This updates the GE ACHC binding, so that different compatible
>> > strings are used for the programming interface, which is the
>> > ezport interface from NXP MK20FN1M0VMD12 and the microcontroller's
>> > normal SPI interface.
>> >
>> > Signed-off-by: Sebastian Reichel 
>> > ---
>> >  Documentation/devicetree/bindings/misc/ge-achc.txt | 19 
>> > ---
>> >  1 file changed, 16 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/misc/ge-achc.txt 
>> > b/Documentation/devicetree/bindings/misc/ge-achc.txt
>> > index 77df94d7a32f..6c6bd6568504 100644
>> > --- a/Documentation/devicetree/bindings/misc/ge-achc.txt
>> > +++ b/Documentation/devicetree/bindings/misc/ge-achc.txt
>> > @@ -7,7 +7,13 @@ Note: This device does not expose the peripherals as USB 
>> > devices.
>> >
>> >  Required properties:
>> >
>> > -- compatible : Should be "ge,achc"
>> > +- compatible : Should be
>> > +  "ge,achc" (normal interface)
>> > +  "ge,achc-ezport" (flashing interface)
>> > +
>> > +Required properties (flashing interface only):
>> > +
>> > +- reset-gpios: GPIO Specifier for the reset GPIO
>>
>> Does the reset only affect the flashing interface and are the data pins
>> shared? If not for both, then I think the correct thing to do here is
>> just extend reg to support multiple values to represent multiple chip
>> selects.
>
> reset affects the whole chip and the same spi data/clock pins are
> being used, so extending reg should work. The flashing cannot happen
> with the same speed, though. I'm currently encoding this by using
> different "spi-max-frequency" properties. I suppose I could limit
> it in the driver instead. I tried to come up with an example for
> your suggestion. Is this what you had in mind?

If the max frequency is the device max, then that should be in the
driver. spi-max-frequency should really only be needed if the
frequency is less than the max of either the host or device.

>
> &spi_controller {
> achc@multiple {

@0

unit addresses are the 1st address.

> /* 0 = flashing interface, 1 = normal interface */
> reg = <0>, <1>;

You may want to put the normal interface first as that is the primary
interface and would still work assuming the OS ignored extra entries.

> compatible = "ge,achc";
> reset-gpios = <&gpio42 23 ACTIVE_LOW>;
> spi-max-frequency = <42>; /* max speed for normal operation */

42 Hz?

Rob

Re: [PATCH] kasan: add no_sanitize attribute for clang builds

2018-04-13 Thread Andrey Ryabinin



On 04/12/2018 08:29 PM, Andrey Konovalov wrote:
> KASAN uses the __no_sanitize_address macro to disable instrumentation
> of particular functions. Right now it's defined only for GCC build,
> which causes false positives when clang is used.
> 
> This patch adds a definition for clang.
> 
> Note, that clang's revision 329612 or higher is required.
> 
> Signed-off-by: Andrey Konovalov 
> ---
>  include/linux/compiler-clang.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index ceb96ecab96e..5a1d8580febe 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -25,6 +25,11 @@
>  #define __SANITIZE_ADDRESS__
>  #endif
>  
> +#ifdef CONFIG_KASAN

If, for whatever reason, developer decides to add __no_sanitize_address to some
generic function, guess what will happen next when he/she will try to build 
CONFIG_KASAN=n kernel?

> +#undef __no_sanitize_address
> +#define __no_sanitize_address __attribute__((no_sanitize("address")))
> +#endif
> +
>  /* Clang doesn't have a way to turn it off per-function, yet. */
>  #ifdef __noretpoline
>  #undef __noretpoline
>

[PATCH v2] drm/arm/malidp: Ensure that the crtcs are shutdown before removing any encoder/connector

2018-04-13 Thread Ayan Kumar Halder

One needs to ensure that the crtcs are shutdown so that the
drm_crtc_state->connector_mask reflects that no connectors
are currently active. Further, it reduces the reference
count for each connector. This ensures that the connectors
and encoders can be cleanly removed either when _unbind
is called for the corresponding drivers or by
drm_mode_config_cleanup().

Signed-off-by: Ayan Kumar Halder 
---

Changes in v2:
 - Reset the connectors' mask and the reference counts in drm_device
before unbinding any of its components (ie connectors and 
encoders).

---
 drivers/gpu/drm/arm/malidp_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 8d20faa..0a788d7 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -278,7 +278,6 @@ static int malidp_init(struct drm_device *drm)
 
 static void malidp_fini(struct drm_device *drm)
 {
-   drm_atomic_helper_shutdown(drm);
drm_mode_config_cleanup(drm);
 }
 
@@ -646,6 +645,7 @@ static int malidp_bind(struct device *dev)
malidp_de_irq_fini(drm);
drm->irq_enabled = false;
 irq_init_fail:
+   drm_atomic_helper_shutdown(drm);
component_unbind_all(dev, drm);
 bind_fail:
of_node_put(malidp->crtc.port);
@@ -681,6 +681,7 @@ static void malidp_unbind(struct device *dev)
malidp_se_irq_fini(drm);
malidp_de_irq_fini(drm);
drm->irq_enabled = false;
+   drm_atomic_helper_shutdown(drm);
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
-- 
2.7.4

Re: KASAN: slab-out-of-bounds Write in perf_callchain_user

2018-04-13 Thread Jiri Olsa

On Thu, Apr 12, 2018 at 03:02:01AM -0700, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on bpf-next commit
> 17dec0a949153d9ac00760ba2f5b78cb583e995f (Wed Apr 4 02:15:32 2018 +)
> Merge branch 'userns-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=7c449856228b63ac951e
> 
> So far this crash happened 2 times on bpf-next.
> syzkaller reproducer:
> https://syzkaller.appspot.com/x/repro.syz?id=4514433808203776
> Raw console output:
> https://syzkaller.appspot.com/x/log.txt?id=5570436679073792
> Kernel config:
> https://syzkaller.appspot.com/x/.config?id=-2735707888269579554
> compiler: gcc (GCC) 8.0.1 20180301 (experimental)
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+7c449856228b63ac9...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> IPVS: ftp: loaded support on port[0] = 21
> ==
> BUG: KASAN: slab-out-of-bounds in perf_callchain_store
> include/linux/perf_event.h:1147 [inline]
> BUG: KASAN: slab-out-of-bounds in perf_callchain_user+0xe31/0xfe0
> arch/x86/events/core.c:2485
> Write of size 8 at addr 8801d87f2d40 by task udevd/2377
> 
> CPU: 0 PID: 2377 Comm: udevd Not tainted 4.16.0+ #3
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x1b9/0x29f lib/dump_stack.c:53
>  print_address_description+0x6c/0x20b mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
>  __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:438
>  perf_callchain_store include/linux/perf_event.h:1147 [inline]
>  perf_callchain_user+0xe31/0xfe0 arch/x86/events/core.c:2485
>  get_perf_callchain+0x798/0xb20 kernel/events/callchain.c:227
>  perf_callchain kernel/events/core.c:6354 [inline]
>  perf_prepare_sample+0x123d/0x1900 kernel/events/core.c:6380
>  __perf_event_output kernel/events/core.c:6494 [inline]
>  perf_event_output_forward+0x10a/0x2b0 kernel/events/core.c:6512
>  __perf_event_overflow+0x231/0x4b0 kernel/events/core.c:7748
>  perf_swevent_overflow+0xad/0x150 kernel/events/core.c:7824
>  perf_swevent_event+0x1f0/0x2e0 kernel/events/core.c:7857
>  perf_tp_event+0x4da/0xc30 kernel/events/core.c:8280
>  perf_trace_run_bpf_submit+0x23f/0x370 kernel/events/core.c:8254
>  perf_trace_lock_acquire+0x4f1/0x980 include/trace/events/lock.h:13
>  trace_lock_acquire include/trace/events/lock.h:13 [inline]
>  lock_acquire+0x38e/0x520 kernel/locking/lockdep.c:3919
>  finish_lock_switch kernel/sched/core.c:2602 [inline]
>  finish_task_switch+0x1c2/0x820 kernel/sched/core.c:2701
>  context_switch kernel/sched/core.c:2851 [inline]
>  __schedule+0x80f/0x1e40 kernel/sched/core.c:3490
>  schedule+0xef/0x430 kernel/sched/core.c:3549
>  schedule_hrtimeout_range_clock+0x3c0/0x470 kernel/time/hrtimer.c:1883
>  schedule_hrtimeout_range+0x2a/0x40 kernel/time/hrtimer.c:1940
>  ep_poll+0xf2e/0x11d0 fs/eventpoll.c:1812
>  do_epoll_wait+0x1b0/0x200 fs/eventpoll.c:2191
>  SYSC_epoll_wait fs/eventpoll.c:2201 [inline]
>  SyS_epoll_wait+0x2c/0x40 fs/eventpoll.c:2198
>  do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x7fe39adf3943
> RSP: 002b:7ffc13750708 EFLAGS: 0246 ORIG_RAX: 00e8
> RAX: ffda RBX:  RCX: 7fe39adf3943
> RDX: 0008 RSI: 7ffc13750800 RDI: 000a
> RBP: 01b676c0 R08:  R09: 7fe39ae3ca60
> R10:  R11: 0246 R12: 0a56
> R13:  R14: 01b674a0 R15: 01b4e250
> 
> Allocated by task 4544:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:552
>  __do_kmalloc_node mm/slab.c:3670 [inline]
>  __kmalloc_node+0x47/0x70 mm/slab.c:3677
>  kmalloc_node include/linux/slab.h:554 [inline]
>  alloc_callchain_buffers kernel/events/callchain.c:91 [inline]
>  get_callchain_buffers+0x31a/0x4b0 kernel/events/callchain.c:138
>  perf_event_alloc.part.91+0x2274/0x30a0 kernel/events/core.c:10047
>  perf_event_alloc kernel/events/core.c:10376 [inline]
>  SYSC_perf_event_open+0xa8a/0x2fa0 kernel/events/core.c:10477
>  SyS_perf_event_open+0x35/0x40 kernel/events/core.c:10366
>  do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x42/0xb7

I think we miss the max-stack check for the initial event
that creates the buffers.. that allows us to create event
with max-stack value bigger than the global max:


[root@ibm-x3650m4-01 perf]# sysctl -a | grep perf_event_max_stack
ke

[PATCH] lockdown: fix coordination of kernel module signature verification

2018-04-13 Thread Mimi Zohar

If both IMA-appraisal and sig_enforce are enabled, then both signatures
are currently required.  If the IMA-appraisal signature verification
fails, it could rely on the appended signature verification; but with the
lockdown patch set, the appended signature verification assumes that if
IMA-appraisal is enabled, it has verified the signature.  Basically each
signature verification method would be relying on the other to verify the
kernel module signature.

This patch addresses the problem of requiring both kernel module signature
verification methods, when both are enabled, by verifying just the
appended signature.

Signed-off-by: Mimi Zohar 
---
 kernel/module.c   | 4 +---
 security/integrity/ima/ima_main.c | 7 ++-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 9c1709a05037..60861eb7bc4d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2803,9 +2803,7 @@ static int module_sig_check(struct load_info *info, int 
flags,
if (sig_enforce) {
pr_notice("%s is rejected\n", reason);
return -EKEYREJECTED;
-   }
-
-   if (can_do_ima_check && is_ima_appraise_enabled())
+   } else if (can_do_ima_check && is_ima_appraise_enabled())
return 0;
if (kernel_is_locked_down(reason))
return -EPERM;
diff --git a/security/integrity/ima/ima_main.c 
b/security/integrity/ima/ima_main.c
index 754ece08e1c6..2155b1f316a4 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -480,6 +480,7 @@ static int read_idmap[READING_MAX_ID] = {
 int ima_post_read_file(struct file *file, void *buf, loff_t size,
   enum kernel_read_file_id read_id)
 {
+   bool sig_enforce = is_module_sig_enforced();
enum ima_hooks func;
u32 secid;
 
@@ -490,7 +491,11 @@ int ima_post_read_file(struct file *file, void *buf, 
loff_t size,
return 0;
}
 
-   if (!file && read_id == READING_MODULE) /* MODULE_SIG_FORCE enabled */
+   /*
+* If both IMA-appraisal and appended signature verification are
+* enabled, rely on the appended signature verification.
+*/
+   if (sig_enforce && read_id == READING_MODULE)
return 0;
 
/* permit signed certs */
-- 
2.7.5

Re: [PATCH net] virtio-net: add missing virtqueue kick when flushing packets

2018-04-13 Thread David Miller

From: Jason Wang 
Date: Fri, 13 Apr 2018 14:58:25 +0800

> We tends to batch submitting packets during XDP_TX. This requires to
> kick virtqueue after a batch, we tried to do it through
> xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So
> explicitly kick the virtqueue in this case.
> 
> Reported-by: Kimitoshi Takahashi 
> Tested-by: Kimitoshi Takahashi 
> Cc: Daniel Borkmann 
> Fixes: 186b3c998c50 ("virtio-net: support XDP_REDIRECT")
> Signed-off-by: Jason Wang 

Applied and queued up for -stable, thanks Jason.

Re: [RFC v2] virtio: support packed ring

2018-04-13 Thread Michael S. Tsirkin

On Sun, Apr 01, 2018 at 10:12:16PM +0800, Tiwei Bie wrote:
> +static inline bool more_used(const struct vring_virtqueue *vq)
> +{
> + return vq->packed ? more_used_packed(vq) : more_used_split(vq);
> +}
> +
> +void *virtqueue_get_buf_ctx_split(struct virtqueue *_vq, unsigned int *len,
> +   void **ctx)
> +{
> + struct vring_virtqueue *vq = to_vvq(_vq);
> + void *ret;
> + unsigned int i;
> + u16 last_used;
> +
> + START_USE(vq);
> +
> + if (unlikely(vq->broken)) {
> + END_USE(vq);
> + return NULL;
> + }
> +
> + if (!more_used(vq)) {
> + pr_debug("No more buffers in queue\n");
> + END_USE(vq);
> + return NULL;
> + }

So virtqueue_get_buf_ctx_split should only call more_used_split.

to avoid such issues I think we should lay out the code like this:

XXX_split

XXX_packed

XXX wrappers

> +/* The standard layout

I'd drop standard here.

> for the packed ring is a continuous chunk of memory
> + * which looks like this.
> + *
> + * struct vring_packed
> + * {

Can the opening bracket go on the prev line pls?

> + *   // The actual descriptors (16 bytes each)
> + *   struct vring_packed_desc desc[num];
> + *
> + *   // Padding to the next align boundary.
> + *   char pad[];
> + *
> + *   // Driver Event Suppression
> + *   struct vring_packed_desc_event driver;
> + *
> + *   // Device Event Suppression
> + *   struct vring_packed_desc_event device;

Maybe that's how our driver does it but it's not based on spec
so I don't think this belongs in the header.

> + * };
> + */
> +
> +static inline unsigned vring_packed_size(unsigned int num, unsigned long 
> align)
> +{
> + return ((sizeof(struct vring_packed_desc) * num + align - 1)
> + & ~(align - 1)) + sizeof(struct vring_packed_desc_event) * 2;
> +}
> +

Cant say this API makes sense for me.


>  #endif /* _UAPI_LINUX_VIRTIO_RING_H */
> -- 
> 2.11.0

Re: [PATCH v3 4/4] DTS: Bindings: pca953x: add example how to use interrupt-controller and gpio-controller