Re: [PATCH] backlight: report error on failure

[Daniel Thompson]

On Wed, Jan 18, 2017 at 09:23:50PM +, Sudip Mukherjee wrote:
> It is possible to update the backlight power and the brightness using
> the sysfs and on writing it either returns the count or if the callback
> function does not exist then returns the error code 'ENXIO'.
> 
> We have a situation where the userspace client is writing to the sysfs
> to update the power and since the callback function exists the client
> receives the return value as count and considers the operation to be
> successful. That is correct as the write to the sysfs was successful.
> But there is no way to know if the actual operation was done or not.

For brightness there is the actual_brightness file... but I don't think
there's anything for power.


> backlight_update_status() returns the error code if it fails. Pass that
> to the userspace client who is trying to update the power so that the
> client knows that the operation failed.

Strictly speaking this is an ABI change. Its probably a harmless one
making it ok to change but I'm interested what testing or code review 
you've done to be sure the userspace doesn't do odd things if the kernel
starts to pass through errors.


> Signed-off-by: Sudip Mukherjee 
> ---
>  drivers/video/backlight/backlight.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/backlight/backlight.c 
> b/drivers/video/backlight/backlight.c
> index 288318a..74b72b5 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -146,9 +146,9 @@ static ssize_t bl_power_store(struct device *dev, struct 
> device_attribute *attr,
>   pr_debug("set power to %lu\n", power);
>   if (bd->props.power != power) {
>   bd->props.power = power;
> - backlight_update_status(bd);
> + rc = backlight_update_status(bd);
>   }
> - rc = count;
> + rc = rc ? rc : count;

Shouldn't bd->props,power be rolled back on error?

Without it we end up in an odd situation with the lazy updates, 
specifically if the userspace observes original error and retries then we
will spuriously succeed due to the lazy update (leaving us not much 
better off than without this change).


>   mutex_unlock(&bd->ops_lock);
>  
> @@ -176,8 +176,7 @@ int backlight_device_set_brightness(struct 
> backlight_device *bd,
>   else {
>   pr_debug("set brightness to %lu\n", brightness);
>   bd->props.brightness = brightness;
> - backlight_update_status(bd);
> - rc = 0;
> + rc = backlight_update_status(bd);

Again, there is no roll back on error.


Daniel.

[PATCH] make.cross: Update openrisc toolchain to fix builds

[Stafford Horne]

The latest openrisc kernel patchs in linux-next are failing to build due
to old toolchains at the crosstool website.

Update to point the the toolchain binaries released the OpenRISC team.

Signed-off-by: Stafford Horne 
---
 sbin/make.cross | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/sbin/make.cross b/sbin/make.cross
index c450b4a..7f802b1 100755
--- a/sbin/make.cross
+++ b/sbin/make.cross
@@ -104,12 +104,31 @@ install_linaro()
sudo mv $dir  $GCC_INSTALL_PATH/gcc-$cross_gcc_version/$gcc_arch
 }
 
+install_openrisc()
+{
+   local 
URL='https://github.com/openrisc/or1k-gcc/releases/download/or1k-5.4.0-20170218'
+   local file='or1k-linux-5.4.0-20170218.tar.xz'
+
+   download_extract "$URL/$file"
+
+   local dir="$GCC_INSTALL_PATH/${gcc_arch}"
+   local cross_gcc_version=(${dir}/bin/${gcc_arch}-gcc-*.*.*)
+   local cross_gcc_version=${cross_gcc_version##*-}
+
+   echo mkdir -p $GCC_INSTALL_PATH/gcc-$cross_gcc_version
+   sudo mkdir -p $GCC_INSTALL_PATH/gcc-$cross_gcc_version
+   echo mv $dir  $GCC_INSTALL_PATH/gcc-$cross_gcc_version/$gcc_arch
+   sudo mv $dir  $GCC_INSTALL_PATH/gcc-$cross_gcc_version/$gcc_arch
+}
+
 install_cross_compiler()
 {
install_packages
 
if [[ $gcc_arch =~ 'aarch64' ]]; then
install_linaro
+   elif [[ $gcc_arch =~ 'or1k' ]]; then
+   install_openrisc
else
install_crosstool
fi
@@ -150,7 +169,7 @@ setup_crosstool()
fi
;;
openrisc)
-   gcc_arch=or32-linux
+   gcc_arch=or1k-linux
;;
s390)
gcc_arch=s390x-linux
-- 
2.9.3

Re: Crosstool/kbuild-all toolchain updates

[Stafford Horne]

Ping?

On Wed, Feb 01, 2017 at 07:44:38AM +0900, Stafford Horne wrote:
> Hi Fengguang/All,
> 
> I am working as the OpenRISC linux kernel maintainer.  Currently in
> linux-next our patches are causing kbuild test robot to fail.
> 
> This is because the patches are taking advantage of 2 'new' (2 year old)
> instrucions (l.swa/l.lwa) and the build robots, as far as I can tell,
> use the 'make.cross' [0] build script from lkp-tests.git.  These point
> to the crosstools [1] toolchains maintained by Tony.
> 
> I sent a mail to Tony who maintains the crosstools but I didn't get a
> reply and it seems he is not longer working on them [1].
> 
> I think our options are:
> 
>   1. Update 'make.cross' to point somewhere else for openrisc
>   2. Update and maintain crosstools
> 
> For 1. its trvial but, maybe not the best solution.
> 
> For 2. I created new crosstool builds for openrisc [3]. The way the
> crosstools are maintained is via a patches.tar file and it seem a custom
> buildall script.  I dont see the source for that custom script anywhere.
> 
> I am thinking I could help to update and 'opensource' the crosstool
> build scripts to make it easier for everyone to update toolchains by
> sending patches.
> 
> But, I would need access to crosstool on kernel.org and an OK from
> everyone.
> 
> Any opinions? Questions?
> 
> -Stafford
> 
> [0] 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/sbin/make.cross
> [1] https://www.kernel.org/pub/tools/crosstool/
> [2] https://marc.info/?l=linux-kernel&m=146406282809809&w=1
> [3] http://shorne.noip.me/crosstool/files/

Any thought on this?

I create a patch to do 1. Update make.cross to point to openrisc
binaries. I hope you found it on the list:

  https://lkml.org/lkml/2017/2/19/12

-Stafford

Re: [PATCH] backlight: report error on failure

[Daniel Thompson]

On Sat, Feb 18, 2017 at 04:31:43PM +, Sudip Mukherjee wrote:
> On Monday 30 January 2017 11:04 PM, Sudip Mukherjee wrote:
> > On Wednesday 18 January 2017 09:23 PM, Sudip Mukherjee wrote:
> > > It is possible to update the backlight power and the brightness using
> > > the sysfs and on writing it either returns the count or if the callback
> > > function does not exist then returns the error code 'ENXIO'.
> > > 
> > > We have a situation where the userspace client is writing to the sysfs
> > > to update the power and since the callback function exists the client
> > > receives the return value as count and considers the operation to be
> > > successful. That is correct as the write to the sysfs was successful.
> > > But there is no way to know if the actual operation was done or not.
> > > 
> > > backlight_update_status() returns the error code if it fails. Pass that
> > > to the userspace client who is trying to update the power so that the
> > > client knows that the operation failed.
> > > 
> > > Signed-off-by: Sudip Mukherjee 
> > > ---
> > 
> > A gentle ping.
> 
> Hi Andrew,
> 
> Its more than one month now that this patch was submitted. Can you please
> take it through your tree... else it will miss the merge window.

Sorry you've been waiting so long for a review. Your "gentle ping" did
result in a few minor tweaks to the maintainers but what it didn't
(until today) provoke was  review!

To be honest, the ABI changes in the patch meant I wanted to check a 
few things first. However prompted by this mail I've just replied with 
the review I *should* have sent out a week ago [asking you rather than 
me to fill in some details about the likely effect of the ABI change ;-) ].

BTW, I did do some archeology eariler in the week and I think the kernel
has been swallowing error codes here for >10 years, so I'm curious if this
is a theoretic bug fix or are you aware of some tangible problem in 
userspace that results from it?


Daniel.

Re: [PATCH] proc/sysctl: prune stale dentries during unregistering

[Al Viro]

On Sat, Feb 18, 2017 at 09:55:28PM +0300, Konstantin Khlebnikov wrote:
> This patch has locking problem. I've got lockdep splat under LTP.
> 
> d_lock nests inside i_lock
> sysctl_lock nests inside d_lock in d_compare
> 
> This patch adds i_lock nesting inside sysctl_lock.

Once ->unregistering is set, you can drop sysctl_lock just fine.  So I'd
try something like this - use rcu_read_lock() in proc_sys_prune_dcache(),
drop sysctl_lock() before it and regain after.  Make sure that no inodes
are added to the list ones ->unregistering has been set and use RCU list
primitives for modifying the inode list, with sysctl_lock still used to
serialize its modifications.

Freeing struct inode is RCU-delayed (see proc_destroy_inode()), so doing
igrab() is safe there.  Since we don't drop inode reference until after we'd
passed beyond it in the list, list_for_each_entry_rcu() should be fine,
AFAICS.  Below is a completely untested modification of your patch along
those lines:

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 842a5ff5b85c..7ad9ed7958af 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -43,10 +43,11 @@ static void proc_evict_inode(struct inode *inode)
de = PDE(inode);
if (de)
pde_put(de);
+
head = PROC_I(inode)->sysctl;
if (head) {
RCU_INIT_POINTER(PROC_I(inode)->sysctl, NULL);
-   sysctl_head_put(head);
+   proc_sys_evict_inode(inode, head);
}
 }
 
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 2de5194ba378..ed1d762160e6 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -65,6 +65,7 @@ struct proc_inode {
struct proc_dir_entry *pde;
struct ctl_table_header *sysctl;
struct ctl_table *sysctl_entry;
+   struct list_head sysctl_inodes;
const struct proc_ns_operations *ns_ops;
struct inode vfs_inode;
 };
@@ -249,10 +250,12 @@ extern void proc_thread_self_init(void);
  */
 #ifdef CONFIG_PROC_SYSCTL
 extern int proc_sys_init(void);
-extern void sysctl_head_put(struct ctl_table_header *);
+extern void proc_sys_evict_inode(struct inode *inode,
+struct ctl_table_header *head);
 #else
 static inline void proc_sys_init(void) { }
-static inline void sysctl_head_put(struct ctl_table_header *head) { }
+static inline void proc_sys_evict_inode(struct  inode *inode,
+   struct ctl_table_header *head) { }
 #endif
 
 /*
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index 55313d994895..6477c4a2dc6c 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -190,6 +190,7 @@ static void init_header(struct ctl_table_header *head,
head->set = set;
head->parent = NULL;
head->node = node;
+   INIT_LIST_HEAD(&head->inodes);
if (node) {
struct ctl_table *entry;
for (entry = table; entry->procname; entry++, node++)
@@ -259,6 +260,26 @@ static void unuse_table(struct ctl_table_header *p)
complete(p->unregistering);
 }
 
+static void proc_sys_prune_dcache(struct ctl_table_header *head)
+{
+   struct inode *inode, *prev = NULL;
+   struct proc_inode *ei;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(ei, &head->inodes, sysctl_inodes) {
+   inode = igrab(&ei->vfs_inode);
+   if (inode) {
+   rcu_read_unlock();
+   iput(prev);
+   prev = inode;
+   d_prune_aliases(inode);
+   rcu_read_lock();
+   }
+   }
+   rcu_read_unlock();
+   iput(prev);
+}
+
 /* called under sysctl_lock, will reacquire if has to wait */
 static void start_unregistering(struct ctl_table_header *p)
 {
@@ -272,31 +293,22 @@ static void start_unregistering(struct ctl_table_header 
*p)
p->unregistering = &wait;
spin_unlock(&sysctl_lock);
wait_for_completion(&wait);
-   spin_lock(&sysctl_lock);
} else {
/* anything non-NULL; we'll never dereference it */
p->unregistering = ERR_PTR(-EINVAL);
+   spin_unlock(&sysctl_lock);
}
/*
+* Prune dentries for unregistered sysctls: namespaced sysctls
+* can have duplicate names and contaminate dcache very badly.
+*/
+   proc_sys_prune_dcache(p);
+   /*
 * do not remove from the list until nobody holds it; walking the
 * list in do_sysctl() relies on that.
 */
-   erase_header(p);
-}
-
-static void sysctl_head_get(struct ctl_table_header *head)
-{
-   spin_lock(&sysctl_lock);
-   head->count++;
-   spin_unlock(&sysctl_lock);
-}
-
-void sysctl_head_put(struct ctl_table_header *head)
-{
spin_lock(&sysctl_lock);
-   if (!--head->count)
-   kfree_rcu(head, rcu);
-   spin_unlock(&sysctl_lock);
+   erase_h

Re: [PATCH] make.cross: Update openrisc toolchain to fix builds

[Fengguang Wu]

Applied, thank you!

On Sun, Feb 19, 2017 at 05:14:36PM +0900, Stafford Horne wrote:

The latest openrisc kernel patchs in linux-next are failing to build due
to old toolchains at the crosstool website.

Update to point the the toolchain binaries released the OpenRISC team.

Signed-off-by: Stafford Horne 
---
sbin/make.cross | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/sbin/make.cross b/sbin/make.cross
index c450b4a..7f802b1 100755
--- a/sbin/make.cross
+++ b/sbin/make.cross
@@ -104,12 +104,31 @@ install_linaro()
sudo mv $dir  $GCC_INSTALL_PATH/gcc-$cross_gcc_version/$gcc_arch
}

+install_openrisc()
+{
+   local 
URL='https://github.com/openrisc/or1k-gcc/releases/download/or1k-5.4.0-20170218'
+   local file='or1k-linux-5.4.0-20170218.tar.xz'
+
+   download_extract "$URL/$file"
+
+   local dir="$GCC_INSTALL_PATH/${gcc_arch}"
+   local cross_gcc_version=(${dir}/bin/${gcc_arch}-gcc-*.*.*)
+   local cross_gcc_version=${cross_gcc_version##*-}
+
+   echo mkdir -p $GCC_INSTALL_PATH/gcc-$cross_gcc_version
+   sudo mkdir -p $GCC_INSTALL_PATH/gcc-$cross_gcc_version
+   echo mv $dir  $GCC_INSTALL_PATH/gcc-$cross_gcc_version/$gcc_arch
+   sudo mv $dir  $GCC_INSTALL_PATH/gcc-$cross_gcc_version/$gcc_arch
+}
+
install_cross_compiler()
{
install_packages

if [[ $gcc_arch =~ 'aarch64' ]]; then
install_linaro
+   elif [[ $gcc_arch =~ 'or1k' ]]; then
+   install_openrisc
else
install_crosstool
fi
@@ -150,7 +169,7 @@ setup_crosstool()
fi
;;
openrisc)
-   gcc_arch=or32-linux
+   gcc_arch=or1k-linux
;;
s390)
gcc_arch=s390x-linux
--
2.9.3

Re: [PATCH 4/9] vfs: intercept reads to overlay files

[Al Viro]

On Fri, Feb 17, 2017 at 05:09:33PM +0100, Miklos Szeredi wrote:
> ...in order to handle the corner case when the file is copyied up after
> being opened read-only.

> --- /dev/null
> +++ b/fs/overlay_util.c
> @@ -0,0 +1,39 @@
> +/*
> + * Copyright (C) 2017 Red Hat, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +#if IS_ENABLED(CONFIG_OVERLAY_FS)

This is crap - it should be handled in fs/Makefile, not with IS_ENABLED.

> +#include 
> +#include 
> +#include 
> +#include "internal.h"
> +
> +static bool overlay_file_consistent(struct file *file)
> +{
> + return d_real_inode(file->f_path.dentry) == file_inode(file);
> +}
> +
> +ssize_t overlay_read_iter(struct file *file, struct kiocb *kio,
> +   struct iov_iter *iter)
> +{
> + ssize_t ret;
> +
> + if (likely(overlay_file_consistent(file)))
> + return file->f_op->read_iter(kio, iter);
> +
> + file = filp_clone_open(file);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> +
> + ret = vfs_iter_read(file, iter, &kio->ki_pos);
> + fput(file);

You do realize that a bunch of such calls will breed arseloads of struct file,
right?  Freeing is delayed...

> +static inline bool is_overlay_file(struct file *file)
> +{
> + return IS_ENABLED(CONFIG_OVERLAY_FS) && file->f_mode & FMODE_OVERLAY;
> +}
> +
>  static inline ssize_t call_read_iter(struct file *file, struct kiocb *kio,
>struct iov_iter *iter)
>  {
> + if (unlikely(is_overlay_file(file)))
> + return overlay_read_iter(file, kio, iter);
> +
>   return file->f_op->read_iter(kio, iter);
>  }

1) that IS_ENABLED is fairly pointless and it's not obvious that nobody
else will use that flag

2) what that check should include is overlay_file_consistent(), with
no method call in overlay_read_iter().

3) anything that does a plenty of calls of kernel_read() is going to be
very unpleasantly surprised by the effects of that thing.

Re: [PATCH 0/9] overlay: fix inconsistency of ro file after copy-up

[Al Viro]

On Fri, Feb 17, 2017 at 05:09:29PM +0100, Miklos Szeredi wrote:
> A file is opened for read-only, opened read-write (resulting in a copy up)
> and modified.  The data read back from the the read-only fd will be stale
> in this case (the read-only file descriptor still refers to the lower,
> unmodified file).
> 
> This patchset fixes issues related to this corner case.  This is a
> requirement from various parties for accepting overlayfs as a "POSIX"
> filesystem.
> 
> When an operation (read, mmap, fsync) is done on an overlay fd opened
> read-only that is referring to a lower file, check if it has been copied up
> in the mean time.  If so, open the upper file and use that for the operation.
> 
> To make the performance impact minimal for non-overlay case, use a flag in
> file->f_mode to indicate that this is an overlay file.

This is one hell of a DoS vector - it's really easy to eat tons of struct
file that way.  Preparatory parts of that series make sense on their own,
but your "let's allocate a struct file, call ->open() and schedule that
struct file for closing upon the exit to userland on each kernel_read()"
is not.

RE: [RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure

[Grumbach, Emmanuel]

Hi Luis,

> 
> The firmware async callback handles the device's opmode start call, but
> optionally also allows opmode registration to take care of its opmode start. 
> If
> the firmware callback handles it its error path in case of opmode start 
> failure
> has a few pieces of code missing from the opmode registration. The opmode
> registration hanlder has no cleanup at all. Sync both error paths.
> 
> This should in theory fix a detangled drv from the drv list should either of 
> the
> opmode modules loaded and handled registration for the drv.
> 
> The path of having the opmode registration deal with the drv opmode start is
> actually the more common path. The other path, from the async callback is
> rathe rare (1/8 or so times for me) -- it happens when the the opmode
> driver's init routine completed prior to the driver's async callback opmode
> start call.

I'd claim it should never happen unless you have several devices on the system 
using the same
opmode, or unless you do:
modprobe iwlwifi  #which will load iwl{d,m}vm
rmmod iwl{d,m}vm #and do _not_ remove iwlwifi
modprobe iwlwifi



> 
> Signed-off-by: Luis R. Rodriguez 
> ---

Luca is OOO,  but this looks fine to me.


>  drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index be466a074c1d..e198d6f5fcea 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1611,8 +1611,13 @@ int iwl_opmode_register(const char *name, const
> struct iwl_op_mode_ops *ops)
>   continue;
>   op->ops = ops;
>   /* TODO: need to handle exceptional case */
> - list_for_each_entry(drv, &op->drv, list)
> + list_for_each_entry(drv, &op->drv, list) {
>   drv->op_mode = _iwl_op_mode_start(drv, op);
> + if (!drv->op_mode) {
> + complete(&drv-
> >request_firmware_complete);
> + device_release_driver(drv->trans->dev);
> + }
> + }
> 
>   mutex_unlock(&iwlwifi_opmode_table_mtx);
>   return 0;
> --
> 2.11.0

Re: [PATCH 4/9] vfs: intercept reads to overlay files

[Miklos Szeredi]

On Sun, Feb 19, 2017 at 10:05 AM, Al Viro  wrote:
> On Fri, Feb 17, 2017 at 05:09:33PM +0100, Miklos Szeredi wrote:
>> ...in order to handle the corner case when the file is copyied up after
>> being opened read-only.
>
>> --- /dev/null
>> +++ b/fs/overlay_util.c
>> @@ -0,0 +1,39 @@
>> +/*
>> + * Copyright (C) 2017 Red Hat, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published 
>> by
>> + * the Free Software Foundation.
>> + */
>> +#if IS_ENABLED(CONFIG_OVERLAY_FS)
>
> This is crap - it should be handled in fs/Makefile, not with IS_ENABLED.

This is needed if overlay is built in or a module.  Couldn't figure
out how makefile could handle that.

>
>> +#include 
>> +#include 
>> +#include 
>> +#include "internal.h"
>> +
>> +static bool overlay_file_consistent(struct file *file)
>> +{
>> + return d_real_inode(file->f_path.dentry) == file_inode(file);
>> +}
>> +
>> +ssize_t overlay_read_iter(struct file *file, struct kiocb *kio,
>> +   struct iov_iter *iter)
>> +{
>> + ssize_t ret;
>> +
>> + if (likely(overlay_file_consistent(file)))
>> + return file->f_op->read_iter(kio, iter);
>> +
>> + file = filp_clone_open(file);
>> + if (IS_ERR(file))
>> + return PTR_ERR(file);
>> +
>> + ret = vfs_iter_read(file, iter, &kio->ki_pos);
>> + fput(file);
>
> You do realize that a bunch of such calls will breed arseloads of struct file,
> right?  Freeing is delayed...

No, I hadn't realized that.  Could we force freeing file here?

>
>> +static inline bool is_overlay_file(struct file *file)
>> +{
>> + return IS_ENABLED(CONFIG_OVERLAY_FS) && file->f_mode & FMODE_OVERLAY;
>> +}
>> +
>>  static inline ssize_t call_read_iter(struct file *file, struct kiocb *kio,
>>struct iov_iter *iter)
>>  {
>> + if (unlikely(is_overlay_file(file)))
>> + return overlay_read_iter(file, kio, iter);
>> +
>>   return file->f_op->read_iter(kio, iter);
>>  }
>
> 1) that IS_ENABLED is fairly pointless and it's not obvious that nobody
> else will use that flag

It's mean to be a micro-optimization for the CONFIG_OVERLAYFS=n case.

>
> 2) what that check should include is overlay_file_consistent(), with
> no method call in overlay_read_iter().

This is again a micro-optimization for the case when this is not an
overlay file.  Which is the very very likely case.

What's the problem with putting that test in the non-inline function?

>
> 3) anything that does a plenty of calls of kernel_read() is going to be
> very unpleasantly surprised by the effects of that thing.

Why is that?

Thanks,
Miklos

[PATCH] net: mvpp2: Fix a memory leak in error handling path

[Christophe JAILLET]

if 'devm_kzalloc()' fails, we should release resources allocated so far,
just as done a few lines below.

Signed-off-by: Christophe JAILLET 
---
 drivers/net/ethernet/marvell/mvpp2.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index c2fd7c36f927..c48632048f71 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5971,8 +5971,10 @@ static int mvpp2_port_init(struct mvpp2_port *port)
struct mvpp2_tx_queue *txq;
 
txq = devm_kzalloc(dev, sizeof(*txq), GFP_KERNEL);
-   if (!txq)
-   return -ENOMEM;
+   if (!txq) {
+   err = -ENOMEM;
+   goto err_free_percpu;
+   }
 
txq->pcpu = alloc_percpu(struct mvpp2_txq_pcpu);
if (!txq->pcpu) {
-- 
2.9.3

[PATCH] qlcnic: Fix a memory leak in error handling path

[Christophe JAILLET]

If 'dma_alloc_coherent()' fails, we should release resources allocated so
far, just as done in all other cases in this function.

Signed-off-by: Christophe JAILLET 
---
checkpatch.pl complains about '== NULL'. I have left it as-is because both
'== NULL' and '!' are already used in the file.
---
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c 
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index daf05155b732..d344e9d43832 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -573,8 +573,10 @@ int qlcnic_alloc_hw_resources(struct qlcnic_adapter 
*adapter)
ptr = (__le32 *)dma_alloc_coherent(&pdev->dev, sizeof(u32),
   &tx_ring->hw_cons_phys_addr,
   GFP_KERNEL);
-   if (ptr == NULL)
-   return -ENOMEM;
+   if (ptr == NULL) {
+   err = -ENOMEM;
+   goto err_out_free;
+   }
 
tx_ring->hw_consumer = ptr;
/* cmd desc ring */
-- 
2.9.3

[PATCH] fs/pstore: constify pstore_zbackend structures

[Bhumika Goyal]

The references of pstore_zbackend structures are stored into the
pointer zbackend of type struct pstore_zbackend. The pointer zbackend
can be made const as it is only dereferenced. After making this change
the pstore_zbackend structures whose references are stored into the
pointer zbackend can be made const too.

File size before:
   textdata bss dec hex filename
   4817 541 1725530159a fs/pstore/platform.o

File size after:
   textdata bss dec hex filename
   4865 477 1725514158a fs/pstore/platform.o

Signed-off-by: Bhumika Goyal 
---
 fs/pstore/platform.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 729677e..92e8728 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -267,7 +267,7 @@ static void free_zlib(void)
big_oops_buf_sz = 0;
 }
 
-static struct pstore_zbackend backend_zlib = {
+static const struct pstore_zbackend backend_zlib = {
.compress   = compress_zlib,
.decompress = decompress_zlib,
.allocate   = allocate_zlib,
@@ -328,7 +328,7 @@ static void free_lzo(void)
big_oops_buf_sz = 0;
 }
 
-static struct pstore_zbackend backend_lzo = {
+static const struct pstore_zbackend backend_lzo = {
.compress   = compress_lzo,
.decompress = decompress_lzo,
.allocate   = allocate_lzo,
@@ -389,7 +389,7 @@ static void free_lz4(void)
big_oops_buf_sz = 0;
 }
 
-static struct pstore_zbackend backend_lz4 = {
+static const struct pstore_zbackend backend_lz4 = {
.compress   = compress_lz4,
.decompress = decompress_lz4,
.allocate   = allocate_lz4,
@@ -398,7 +398,7 @@ static void free_lz4(void)
 };
 #endif
 
-static struct pstore_zbackend *zbackend =
+static const struct pstore_zbackend *zbackend =
 #if defined(CONFIG_PSTORE_ZLIB_COMPRESS)
&backend_zlib;
 #elif defined(CONFIG_PSTORE_LZO_COMPRESS)
-- 
1.9.1

RE: [RFC 2/5] iwlwifi: fix request_module() use

[Grumbach, Emmanuel]

> 
> The return value of request_module() being 0 does not mean that the driver
> which was requested has loaded. To properly check that the driver was
> loaded each driver can use internal mechanisms to vet the driver is now
> present. The helper try_then_request_module() was added to help with
> this, allowing drivers to specify their own validation as the first argument.
> 
> On iwlwifi the use case is a bit more complicated given that the value we
> need to check for is protected with a mutex later used on the
> module_init() of the module we are asking for. If we were to lock and
> request_module() we'd deadlock. iwlwifi needs its own wrapper then so it
> can handle its special locking requirements.
> 
> Signed-off-by: Luis R. Rodriguez 

I don't see the problem with the current code. We don't assume that everything 
has been
loaded immediately after request_module returns. We just free the intermediate 
firmware
structures that won't be using anymore. What happens here is that after 
request_module
returns, we patiently wait until it is loaded, and when that happens, 
iwl{d,m}vm's init function
will be called. That one is the one that continues the flow by calling:

ret = iwl_opmode_register("iwlmvm", &iwl_mvm_ops);

(for the iwlmvm case).

Where am I wrong here?


> ---
>  drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 34 ---
> -
>  1 file changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index e198d6f5fcea..6beb92d19ea7 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1231,6 +1231,29 @@ static void _iwl_op_mode_stop(struct iwl_drv
> *drv)
>   }
>  }
> 
> +static void iwlwifi_try_load_op(struct iwlwifi_opmode_table *op,
> + struct iwl_drv *drv)
> +{
> + int ret = 0;
> +
> + ret = request_module("%s", op->name);
> + if (ret)
> + goto out;
> +
> + mutex_lock(&iwlwifi_opmode_table_mtx);
> + if (!op->ops)
> + ret = -ENOENT;
> + mutex_unlock(&iwlwifi_opmode_table_mtx);
> +
> +out:
> +#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
> + if (ret)
> + IWL_ERR(drv,
> + "failed to load module %s (error %d), is dynamic
> loading enabled?\n",
> + op->name, ret);
> +#endif
> +}
> +
>  /**
>   * iwl_req_fw_callback - callback when firmware was loaded
>   *
> @@ -1471,15 +1494,8 @@ static void iwl_req_fw_callback(const struct
> firmware *ucode_raw, void *context)
>* else from proceeding if the module fails to load
>* or hangs loading.
>*/
> - if (load_module) {
> - err = request_module("%s", op->name);
> -#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
> - if (err)
> - IWL_ERR(drv,
> - "failed to load module %s (error %d), is
> dynamic loading enabled?\n",
> - op->name, err);
> -#endif
> - }
> + if (load_module)
> + iwlwifi_try_load_op(op, drv);
>   goto free;
> 
>   try_again:
> --
> 2.11.0

[PATCH] mm/gup: Check for protnone only if it is a PTE entry.

[Aneesh Kumar K.V]

Do the prot_none/FOLL_NUMA check after we are sure this is a THP pte. Archs
can implement prot_none such that it can return true for regular pmd entries.

Signed-off-by: Aneesh Kumar K.V 
---
 mm/gup.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 5531489d..bb5f3d69f87e 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -265,8 +265,6 @@ struct page *follow_page_mask(struct vm_area_struct *vma,
return page;
return no_page_table(vma, flags);
}
-   if ((flags & FOLL_NUMA) && pmd_protnone(*pmd))
-   return no_page_table(vma, flags);
if (pmd_devmap(*pmd)) {
ptl = pmd_lock(mm, pmd);
page = follow_devmap_pmd(vma, address, pmd, flags);
@@ -277,6 +275,9 @@ struct page *follow_page_mask(struct vm_area_struct *vma,
if (likely(!pmd_trans_huge(*pmd)))
return follow_page_pte(vma, address, pmd, flags);
 
+   if ((flags & FOLL_NUMA) && pmd_protnone(*pmd))
+   return no_page_table(vma, flags);
+
ptl = pmd_lock(mm, pmd);
if (unlikely(!pmd_trans_huge(*pmd))) {
spin_unlock(ptl);
-- 
2.7.4

[PATCH] NFC: st21nfca: Fix potential memory leak

[Christophe JAILLET]

If all bits of 'dev_mask' are already set, there is a memory leak because
'info' should be freed before returning.

While fixing it, 'return -ENOMEM' directly if the first kzalloc fails.
This makes the code more readable.

Signed-off-by: Christophe JAILLET 
---
 drivers/nfc/st21nfca/core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
index dacb9166081b..50be3b788f1c 100644
--- a/drivers/nfc/st21nfca/core.c
+++ b/drivers/nfc/st21nfca/core.c
@@ -959,10 +959,8 @@ int st21nfca_hci_probe(void *phy_id, struct nfc_phy_ops 
*phy_ops,
unsigned long quirks = 0;
 
info = kzalloc(sizeof(struct st21nfca_hci_info), GFP_KERNEL);
-   if (!info) {
-   r = -ENOMEM;
-   goto err_alloc_hdev;
-   }
+   if (!info)
+   return -ENOMEM;
 
info->phy_ops = phy_ops;
info->phy_id = phy_id;
@@ -978,8 +976,10 @@ int st21nfca_hci_probe(void *phy_id, struct nfc_phy_ops 
*phy_ops,
 * persistent info to discriminate 2 identical chips
 */
dev_num = find_first_zero_bit(dev_mask, ST21NFCA_NUM_DEVICES);
-   if (dev_num >= ST21NFCA_NUM_DEVICES)
-   return -ENODEV;
+   if (dev_num >= ST21NFCA_NUM_DEVICES) {
+   r = -ENODEV;
+   goto err_alloc_hdev;
+   }
 
set_bit(dev_num, dev_mask);
 
-- 
2.9.3

[PATCH] mm/thp/autonuma: Use TNF flag instead of vm fault.

[Aneesh Kumar K.V]

We are using wrong flag value in task_numa_falt function. This can result in
us doing wrong numa fault statistics update, because we update num_pages_migrate
and numa_fault_locality etc based on the flag argument passed.

Signed-off-by: Aneesh Kumar K.V 
---
 mm/huge_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 5f3ad65c85de..8f1d93257fb9 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1333,7 +1333,7 @@ int do_huge_pmd_numa_page(struct vm_fault *vmf, pmd_t pmd)
 
if (page_nid != -1)
task_numa_fault(last_cpupid, page_nid, HPAGE_PMD_NR,
-   vmf->flags);
+   flags);
 
return 0;
 }
-- 
2.7.4

Re: [PATCH 4/4] iio: accel: adxl345: Add ACPI support

[Lars-Peter Clausen]

On 02/16/2017 11:02 AM, Eva Rachel Retuya wrote:
[...]
> @@ -54,9 +55,17 @@ static const struct i2c_device_id adxl345_i2c_id[] = {
>  
>  MODULE_DEVICE_TABLE(i2c, adxl345_i2c_id);
>  
> +static const struct acpi_device_id adxl345_acpi_id[] = {
> + { "ADX0345", 0 },

Who allocated this ID? ADX does not seem to be a registered vendor ID
(http://www.uefi.org/PNP_ACPI_Registry).

> + { }
> +};

[PATCH 0/7] introduce __ro_mostly_after_init section marker

[Hoeun Ryu]

 After `__ro_after_init` marker is included in kernel, many kernel data
objects can be read-only-after-init. But there are many other places that
would be good to read-only-after-init but `__ro_after_init` can not be simply
applicable to them because they should be writable at some points, which are
during module_init/exit or dynamic de/registration for a specific subsystem.
 `__ro_mostly_after_init` is basically the same to `__ro_after_init`. The
section is mapped as read-only after kernel init. The different thing is
this section is temporarily mapped as read-write during module_init/exit and
de/registration of a subsystem using set_ro_mostly_after_init_rw/ro pair.

- Tested only on arm64.

Description:
  0001 patch is `__ro_mostly_after_init` itself.
  0002 patch is to add set_ro_mostly_after_init_rw/ro pair using
set_memory_rw/ro.
  0003 patch is to make the section read-write in module_init/exit.
  0004 patch is an example for dynamic init/deinit of a subsystem.
  0005 patch is an example for __ro_mostly_after_init section modified during
module_init/exit.
  0006/0007 patches are fixes for arm64 kernel mapping.

Hoeun Ryu (7):
  arch: add __ro_mostly_after_init section marker
  init: add set_ro_mostly_after_init_rw/ro function
  module: modify memory attrs for __ro_mostly_after_init during
module_init/exit
  selinux: mark __ro_mostly_after_init for selinux_hooks/selinux_nf_ops
  cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states
  arm64: add __map_kernel_segment to accept additional vm flags
  arm64: map seperately rodata sections for __ro_mostly_after_init
section

 arch/arm64/mm/mmu.c   | 44 ---
 include/asm-generic/sections.h|  1 +
 include/asm-generic/vmlinux.lds.h | 10 +
 include/linux/cache.h | 11 ++
 include/linux/init.h  |  6 ++
 init/main.c   | 24 +
 kernel/cpu.c  |  4 ++--
 kernel/module.c   | 10 +++--
 security/selinux/hooks.c  |  8 +--
 9 files changed, 105 insertions(+), 13 deletions(-)

-- 
2.7.4

[PATCH V3 3/3] powerpc/mm/autonuma: Switch ppc64 to its own implementeation of saved write

[Aneesh Kumar K.V]

With this our protnone becomes a present pte with READ/WRITE/EXEC bit cleared.
By default we also set _PAGE_PRIVILEGED on such pte. This is now used to help
us identify a protnone pte that as saved write bit. For such pte, we will clear
the _PAGE_PRIVILEGED bit. The pte still remain non-accessible from both user
and kernel.

Acked-By: Michael Neuling 
Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/book3s/64/pgtable.h | 52 
 1 file changed, 45 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 6a55bbe91556..d87bee85fc44 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -1,6 +1,9 @@
 #ifndef _ASM_POWERPC_BOOK3S_64_PGTABLE_H_
 #define _ASM_POWERPC_BOOK3S_64_PGTABLE_H_
 
+#ifndef __ASSEMBLY__
+#include 
+#endif
 /*
  * Common bits between hash and Radix page table
  */
@@ -428,15 +431,47 @@ static inline pte_t pte_clear_soft_dirty(pte_t pte)
 #endif /* CONFIG_HAVE_ARCH_SOFT_DIRTY */
 
 #ifdef CONFIG_NUMA_BALANCING
-/*
- * These work without NUMA balancing but the kernel does not care. See the
- * comment in include/asm-generic/pgtable.h . On powerpc, this will only
- * work for user pages and always return true for kernel pages.
- */
 static inline int pte_protnone(pte_t pte)
 {
-   return (pte_raw(pte) & cpu_to_be64(_PAGE_PRESENT | _PAGE_PRIVILEGED)) ==
-   cpu_to_be64(_PAGE_PRESENT | _PAGE_PRIVILEGED);
+   return (pte_raw(pte) & cpu_to_be64(_PAGE_PRESENT | _PAGE_PTE | 
_PAGE_RWX)) ==
+   cpu_to_be64(_PAGE_PRESENT | _PAGE_PTE);
+}
+
+#define pte_mk_savedwrite pte_mk_savedwrite
+static inline pte_t pte_mk_savedwrite(pte_t pte)
+{
+   /*
+* Used by Autonuma subsystem to preserve the write bit
+* while marking the pte PROT_NONE. Only allow this
+* on PROT_NONE pte
+*/
+   VM_BUG_ON((pte_raw(pte) & cpu_to_be64(_PAGE_PRESENT | _PAGE_RWX | 
_PAGE_PRIVILEGED)) !=
+ cpu_to_be64(_PAGE_PRESENT | _PAGE_PRIVILEGED));
+   return __pte(pte_val(pte) & ~_PAGE_PRIVILEGED);
+}
+
+#define pte_clear_savedwrite pte_clear_savedwrite
+static inline pte_t pte_clear_savedwrite(pte_t pte)
+{
+   /*
+* Used by KSM subsystem to make a protnone pte readonly.
+*/
+   VM_BUG_ON(!pte_protnone(pte));
+   return __pte(pte_val(pte) | _PAGE_PRIVILEGED);
+}
+
+#define pte_savedwrite pte_savedwrite
+static inline bool pte_savedwrite(pte_t pte)
+{
+   /*
+* Saved write ptes are prot none ptes that doesn't have
+* privileged bit sit. We mark prot none as one which has
+* present and pviliged bit set and RWX cleared. To mark
+* protnone which used to have _PAGE_WRITE set we clear
+* the privileged bit.
+*/
+   VM_BUG_ON(!pte_protnone(pte));
+   return !(pte_raw(pte) & cpu_to_be64(_PAGE_RWX | _PAGE_PRIVILEGED));
 }
 #endif /* CONFIG_NUMA_BALANCING */
 
@@ -867,6 +902,8 @@ static inline pte_t *pmdp_ptep(pmd_t *pmd)
 #define pmd_mkclean(pmd)   pte_pmd(pte_mkclean(pmd_pte(pmd)))
 #define pmd_mkyoung(pmd)   pte_pmd(pte_mkyoung(pmd_pte(pmd)))
 #define pmd_mkwrite(pmd)   pte_pmd(pte_mkwrite(pmd_pte(pmd)))
+#define pmd_mk_savedwrite(pmd) pte_pmd(pte_mk_savedwrite(pmd_pte(pmd)))
+#define pmd_clear_savedwrite(pmd)  
pte_pmd(pte_clear_savedwrite(pmd_pte(pmd)))
 
 #ifdef CONFIG_HAVE_ARCH_SOFT_DIRTY
 #define pmd_soft_dirty(pmd)pte_soft_dirty(pmd_pte(pmd))
@@ -883,6 +920,7 @@ static inline int pmd_protnone(pmd_t pmd)
 
 #define __HAVE_ARCH_PMD_WRITE
 #define pmd_write(pmd) pte_write(pmd_pte(pmd))
+#define pmd_savedwrite(pmd)pte_savedwrite(pmd_pte(pmd))
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 extern pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot);
-- 
2.7.4

[RFC 1/7] arch: add __ro_mostly_after_init section marker

[Hoeun Ryu]

 After `__ro_after_init` marker is included in kernel, many kernel data
objects can be read-only-after-init. But there are many other places that
would be good to read-only-after-init but `__ro_after_init` can not be simply
applicable to them because they should be writable at some points, which are
during module_init/exit or dynamic de/registration for a specific subsystem.
 `__ro_mostly_after_init` is basically the same to `__ro_after_init`. The
section is mapped as read-only after kernel init. The different thing is
this section is temporarily mapped as read-write during module_init/exit and
de/registration of a subsystem using set_ro_mostly_after_init_rw/ro pair.
 Use `__ro_mostly_after_init` as a way to mark such memory instead when
`__ro_after_init` is not applicable because the memory should be writable
at the described points of time. They are read-only right after kernel init
and writable temporarily only during module_init/exit and dynamic
de/registration for a subsystem.

Signed-off-by: Hoeun Ryu 
---
 include/asm-generic/sections.h|  1 +
 include/asm-generic/vmlinux.lds.h | 10 ++
 include/linux/cache.h | 11 +++
 3 files changed, 22 insertions(+)

diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 4df64a1..16a6f21 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -34,6 +34,7 @@ extern char __bss_start[], __bss_stop[];
 extern char __init_begin[], __init_end[];
 extern char _sinittext[], _einittext[];
 extern char __start_data_ro_after_init[], __end_data_ro_after_init[];
+extern char __start_data_ro_mostly_after_init[], 
__end_data_ro_mostly_after_init[];
 extern char _end[];
 extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[];
 extern char __kprobes_text_start[], __kprobes_text_end[];
diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 4e09b28..cc5f44e 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -265,6 +265,15 @@
__end_data_ro_after_init = .;
 #endif
 
+#ifndef RO_MOSTLY_AFTER_INIT_DATA
+#define RO_MOSTLY_AFTER_INIT_DATA(align)   \
+   . = ALIGN(align);   \
+   VMLINUX_SYMBOL(__start_data_ro_mostly_after_init) = .;  \
+   *(.data..ro_mostly_after_init)  \
+   . = ALIGN(align);   \
+   VMLINUX_SYMBOL(__end_data_ro_mostly_after_init) = .;
+#endif
+
 /*
  * Read only Data
  */
@@ -275,6 +284,7 @@
*(.rodata) *(.rodata.*) \
RO_AFTER_INIT_DATA  /* Read only after init */  \
KEEP(*(__vermagic)) /* Kernel version magic */  \
+   RO_MOSTLY_AFTER_INIT_DATA(align)\
. = ALIGN(8);   \
VMLINUX_SYMBOL(__start___tracepoints_ptrs) = .; \
KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer array */ \
diff --git a/include/linux/cache.h b/include/linux/cache.h
index 1be04f8..fd1cb9b 100644
--- a/include/linux/cache.h
+++ b/include/linux/cache.h
@@ -30,6 +30,17 @@
 #define __ro_after_init __attribute__((__section__(".data..ro_after_init")))
 #endif
 
+/*
+ * __ro_mostly_after_init is almost like __ro_after_init.
+ * but __ro_mostly_after_init section is temporarily writable only during
+ * module_init/exit or dynamic de/registeration of a subsystem using
+ * set_ro_mostly_after_init_rw/ro pair.
+ */
+#ifndef __ro_mostly_after_init
+#define __ro_mostly_after_init \
+   __attribute__((__section__(".data..ro_mostly_after_init")))
+#endif
+
 #ifndef cacheline_aligned
 #define cacheline_aligned __attribute__((__aligned__(SMP_CACHE_BYTES)))
 #endif
-- 
2.7.4

[PATCH V3 1/3] mm/autonuma: Let architecture override how the write bit should be stashed in a protnone pte.

[Aneesh Kumar K.V]

Autonuma preserves the write permission across numa fault to avoid taking
a writefault after a numa fault (Commit: b191f9b106ea " mm: numa: preserve PTE
write permissions across a NUMA hinting fault"). Architecture can implement
protnone in different ways and some may choose to implement that by clearing 
Read/
Write/Exec bit of pte. Setting the write bit on such pte can result in wrong
behaviour. Fix this up by allowing arch to override how to save the write bit
on a protnone pte.

Acked-By: Michael Neuling 
Signed-off-by: Aneesh Kumar K.V 
---
 include/asm-generic/pgtable.h | 16 
 mm/huge_memory.c  |  6 +++---
 mm/memory.c   |  2 +-
 mm/mprotect.c |  4 ++--
 4 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 18af2bcefe6a..b6f3a8a4b738 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -192,6 +192,22 @@ static inline void ptep_set_wrprotect(struct mm_struct 
*mm, unsigned long addres
 }
 #endif
 
+#ifndef pte_savedwrite
+#define pte_savedwrite pte_write
+#endif
+
+#ifndef pte_mk_savedwrite
+#define pte_mk_savedwrite pte_mkwrite
+#endif
+
+#ifndef pmd_savedwrite
+#define pmd_savedwrite pmd_write
+#endif
+
+#ifndef pmd_mk_savedwrite
+#define pmd_mk_savedwrite pmd_mkwrite
+#endif
+
 #ifndef __HAVE_ARCH_PMDP_SET_WRPROTECT
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static inline void pmdp_set_wrprotect(struct mm_struct *mm,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 8f1d93257fb9..e6de801fa477 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1253,7 +1253,7 @@ int do_huge_pmd_numa_page(struct vm_fault *vmf, pmd_t pmd)
}
 
/* See similar comment in do_numa_page for explanation */
-   if (!pmd_write(pmd))
+   if (!pmd_savedwrite(pmd))
flags |= TNF_NO_GROUP;
 
/*
@@ -1316,7 +1316,7 @@ int do_huge_pmd_numa_page(struct vm_fault *vmf, pmd_t pmd)
goto out;
 clear_pmdnuma:
BUG_ON(!PageLocked(page));
-   was_writable = pmd_write(pmd);
+   was_writable = pmd_savedwrite(pmd);
pmd = pmd_modify(pmd, vma->vm_page_prot);
pmd = pmd_mkyoung(pmd);
if (was_writable)
@@ -1571,7 +1571,7 @@ int change_huge_pmd(struct vm_area_struct *vma, pmd_t 
*pmd,
entry = pmdp_huge_get_and_clear_notify(mm, addr, pmd);
entry = pmd_modify(entry, newprot);
if (preserve_write)
-   entry = pmd_mkwrite(entry);
+   entry = pmd_mk_savedwrite(entry);
ret = HPAGE_PMD_NR;
set_pmd_at(mm, addr, pmd, entry);
BUG_ON(vma_is_anonymous(vma) && !preserve_write &&
diff --git a/mm/memory.c b/mm/memory.c
index 6bf2b471e30c..641b83dbff60 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3388,7 +3388,7 @@ static int do_numa_page(struct vm_fault *vmf)
int target_nid;
bool migrated = false;
pte_t pte = vmf->orig_pte;
-   bool was_writable = pte_write(pte);
+   bool was_writable = pte_savedwrite(pte);
int flags = 0;
 
/*
diff --git a/mm/mprotect.c b/mm/mprotect.c
index f9c07f54dd62..15f5c174a7c1 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -113,13 +113,13 @@ static unsigned long change_pte_range(struct 
vm_area_struct *vma, pmd_t *pmd,
ptent = ptep_modify_prot_start(mm, addr, pte);
ptent = pte_modify(ptent, newprot);
if (preserve_write)
-   ptent = pte_mkwrite(ptent);
+   ptent = pte_mk_savedwrite(ptent);
 
/* Avoid taking write faults for known dirty pages */
if (dirty_accountable && pte_dirty(ptent) &&
(pte_soft_dirty(ptent) ||
 !(vma->vm_flags & VM_SOFTDIRTY))) {
-   ptent = pte_mkwrite(ptent);
+   ptent = pte_mk_savedwrite(ptent);
}
ptep_modify_prot_commit(mm, addr, pte, ptent);
pages++;
-- 
2.7.4

[PATCH V3 0/3] Numabalancing preserve write fix

[Aneesh Kumar K.V]

This patch series address an issue w.r.t THP migration and autonuma
preserve write feature. migrate_misplaced_transhuge_page() cannot deal with
concurrent modification of the page. It does a page copy without
following the migration pte sequence. IIUC, this was done to keep the
migration simpler and at the time of implemenation we didn't had THP
page cache which would have required a more elaborate migration scheme.
That means thp autonuma migration expect the protnone with saved write
to be done such that both kernel and user cannot update
the page content. This patch series enables archs like ppc64 to do that.
We are good with the hash translation mode with the current code,
because we never create a hardware page table entry for a protnone pte. 

Changes form V2:
* Fix kvm crashes due to ksm not clearing savedwrite bit.

Changes from V1:
* Update the patch so that it apply cleanly to upstream.
* Add acked-by from Michael Neuling

Aneesh Kumar K.V (3):
  mm/autonuma: Let architecture override how the write bit should be
stashed in a protnone pte.
  mm/ksm: Handle protnone saved writes when making page write protect
  powerpc/mm/autonuma: Switch ppc64 to its own implementeation of saved
write

 arch/powerpc/include/asm/book3s/64/pgtable.h | 52 
 include/asm-generic/pgtable.h| 24 +
 mm/huge_memory.c |  6 ++--
 mm/ksm.c |  9 +++--
 mm/memory.c  |  2 +-
 mm/mprotect.c|  4 +--
 6 files changed, 82 insertions(+), 15 deletions(-)

-- 
2.7.4

[RFC 4/7] selinux: mark __ro_mostly_after_init for selinux_hooks/selinux_nf_ops

[Hoeun Ryu]

 It would be good that selinux hooks objects are marked as
`__ro_mostly_after_init`. They can not be simply marked as `__ro_after_init'
because they should be writable during selinux_disable procedure.
`__ro_mostly_after_init` section is temporarily read-write during
selinux_disable procedure via set_ro_mostly_after_init_rw/ro pair. Now that
they can be read-only except during the procedure.

Signed-off-by: Hoeun Ryu 
---
 security/selinux/hooks.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 9a8f12f..64fd799 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -6106,7 +6106,7 @@ static int selinux_key_getsecurity(struct key *key, char 
**_buffer)
 
 #endif
 
-static struct security_hook_list selinux_hooks[] = {
+static struct security_hook_list selinux_hooks[] __ro_mostly_after_init = {
LSM_HOOK_INIT(binder_set_context_mgr, selinux_binder_set_context_mgr),
LSM_HOOK_INIT(binder_transaction, selinux_binder_transaction),
LSM_HOOK_INIT(binder_transfer_binder, selinux_binder_transfer_binder),
@@ -6381,7 +6381,7 @@ security_initcall(selinux_init);
 
 #if defined(CONFIG_NETFILTER)
 
-static struct nf_hook_ops selinux_nf_ops[] = {
+static struct nf_hook_ops selinux_nf_ops[] __ro_mostly_after_init = {
{
.hook = selinux_ipv4_postroute,
.pf =   NFPROTO_IPV4,
@@ -6477,13 +6477,17 @@ int selinux_disable(void)
selinux_disabled = 1;
selinux_enabled = 0;
 
+   set_ro_mostly_after_init_rw();
security_delete_hooks(selinux_hooks, ARRAY_SIZE(selinux_hooks));
+   set_ro_mostly_after_init_ro();
 
/* Try to destroy the avc node cache */
avc_disable();
 
/* Unregister netfilter hooks. */
+   set_ro_mostly_after_init_ro();
selinux_nf_ip_exit();
+   set_ro_mostly_after_init_rw();
 
/* Unregister selinuxfs. */
exit_sel_fs();
-- 
2.7.4

[PATCH V3 2/3] mm/ksm: Handle protnone saved writes when making page write protect

[Aneesh Kumar K.V]

Without this KSM will consider the page write protected, but a numa fault can
later mark the page writable. This can result in memory corruption.

Signed-off-by: Aneesh Kumar K.V 
---
 include/asm-generic/pgtable.h | 8 
 mm/ksm.c  | 9 +++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index b6f3a8a4b738..8c8ba48bef0b 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -200,6 +200,10 @@ static inline void ptep_set_wrprotect(struct mm_struct 
*mm, unsigned long addres
 #define pte_mk_savedwrite pte_mkwrite
 #endif
 
+#ifndef pte_clear_savedwrite
+#define pte_clear_savedwrite pte_wrprotect
+#endif
+
 #ifndef pmd_savedwrite
 #define pmd_savedwrite pmd_write
 #endif
@@ -208,6 +212,10 @@ static inline void ptep_set_wrprotect(struct mm_struct 
*mm, unsigned long addres
 #define pmd_mk_savedwrite pmd_mkwrite
 #endif
 
+#ifndef pmd_clear_savedwrite
+#define pmd_clear_savedwrite pmd_wrprotect
+#endif
+
 #ifndef __HAVE_ARCH_PMDP_SET_WRPROTECT
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static inline void pmdp_set_wrprotect(struct mm_struct *mm,
diff --git a/mm/ksm.c b/mm/ksm.c
index 9ae6011a41f8..768202831578 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -872,7 +872,8 @@ static int write_protect_page(struct vm_area_struct *vma, 
struct page *page,
if (!ptep)
goto out_mn;
 
-   if (pte_write(*ptep) || pte_dirty(*ptep)) {
+   if (pte_write(*ptep) || pte_dirty(*ptep) ||
+   (pte_protnone(*ptep) && pte_savedwrite(*ptep))) {
pte_t entry;
 
swapped = PageSwapCache(page);
@@ -897,7 +898,11 @@ static int write_protect_page(struct vm_area_struct *vma, 
struct page *page,
}
if (pte_dirty(entry))
set_page_dirty(page);
-   entry = pte_mkclean(pte_wrprotect(entry));
+
+   if (pte_protnone(entry))
+   entry = pte_mkclean(pte_clear_savedwrite(entry));
+   else
+   entry = pte_mkclean(pte_wrprotect(entry));
set_pte_at_notify(mm, addr, ptep, entry);
}
*orig_pte = *ptep;
-- 
2.7.4

[RFC 3/7] module: modify memory attrs for __ro_mostly_after_init during module_init/exit

[Hoeun Ryu]

 `__ro_mostly_after_init` is almost like `__ro_after_init`. The section is
read-only as same as `__ro_after_init` after kernel init. This patch makes
`__ro_mostly_after_init` section read-write temporarily only during
module_init/module_exit.

Signed-off-by: Hoeun Ryu 
---
 kernel/module.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 7eba6de..3b25e0e 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -987,8 +987,11 @@ SYSCALL_DEFINE2(delete_module, const char __user *, 
name_user,
 
mutex_unlock(&module_mutex);
/* Final destruction now no one is using it. */
-   if (mod->exit != NULL)
+   if (mod->exit != NULL) {
+   set_ro_mostly_after_init_rw();
mod->exit();
+   set_ro_mostly_after_init_ro();
+   }
blocking_notifier_call_chain(&module_notify_list,
 MODULE_STATE_GOING, mod);
klp_module_going(mod);
@@ -3396,8 +3399,11 @@ static noinline int do_init_module(struct module *mod)
 
do_mod_ctors(mod);
/* Start the module */
-   if (mod->init != NULL)
+   if (mod->init != NULL) {
+   set_ro_mostly_after_init_rw();
ret = do_one_initcall(mod->init);
+   set_ro_mostly_after_init_ro();
+   }
if (ret < 0) {
goto fail_free_freeinit;
}
-- 
2.7.4

[RFC 5/7] cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states

[Hoeun Ryu]

It would be good that `__ro_mostly_after_init` is marked to cpuhp state
objects. They can not be simply marked as `__ro_after_init` because they
should be writable during module_init/exit. Now that they can be read-only
except during module_init/exit

Signed-off-by: Hoeun Ryu 
---
 kernel/cpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 0a5f630..12ad4c2 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1126,7 +1126,7 @@ core_initcall(cpu_hotplug_pm_sync_init);
 #endif /* CONFIG_SMP */
 
 /* Boot processor state steps */
-static struct cpuhp_step cpuhp_bp_states[] = {
+static struct cpuhp_step cpuhp_bp_states[] __ro_mostly_after_init = {
[CPUHP_OFFLINE] = {
.name   = "offline",
.startup.single = NULL,
@@ -1212,7 +1212,7 @@ static struct cpuhp_step cpuhp_bp_states[] = {
 };
 
 /* Application processor state steps */
-static struct cpuhp_step cpuhp_ap_states[] = {
+static struct cpuhp_step cpuhp_ap_states[] __ro_mostly_after_init = {
 #ifdef CONFIG_SMP
/* Final state before CPU kills itself */
[CPUHP_AP_IDLE_DEAD] = {
-- 
2.7.4

[RFC 2/7] init: add set_ro_mostly_after_init_rw/ro function

[Hoeun Ryu]

 Add set_ro_mostly_after_init_rw/ro pair to modify memory attributes for
memory marked as `ro_mostly_after_init`.

 I am doubtful that this is the right place where these functions reside and
these functions are suitable for all architectures for memory attributes
modification. Please comment.

Signed-off-by: Hoeun Ryu 
---
 include/linux/init.h |  6 ++
 init/main.c  | 24 
 2 files changed, 30 insertions(+)

diff --git a/include/linux/init.h b/include/linux/init.h
index 79af096..d68e4f7 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -131,6 +131,12 @@ extern bool rodata_enabled;
 #endif
 #ifdef CONFIG_STRICT_KERNEL_RWX
 void mark_rodata_ro(void);
+
+void set_ro_mostly_after_init_rw(void);
+void set_ro_mostly_after_init_ro(void);
+#else
+static inline void set_ro_mostly_after_init_rw(void) { }
+static inline void set_ro_mostly_after_init_ro(void) { }
 #endif
 
 extern void (*late_time_init)(void);
diff --git a/init/main.c b/init/main.c
index 4719abf..a5d4873 100644
--- a/init/main.c
+++ b/init/main.c
@@ -941,6 +941,30 @@ static void mark_readonly(void)
} else
pr_info("Kernel memory protection disabled.\n");
 }
+
+void set_ro_mostly_after_init_rw(void)
+{
+   unsigned long start = PFN_ALIGN(__start_data_ro_mostly_after_init);
+   unsigned long end = PFN_ALIGN(&__end_data_ro_mostly_after_init);
+   unsigned long nr_pages = (end - start) >> PAGE_SHIFT;
+
+   if (!rodata_enabled)
+   return;
+
+   set_memory_rw(start, nr_pages);
+}
+
+void set_ro_mostly_after_init_ro(void)
+{
+   unsigned long start = PFN_ALIGN(__start_data_ro_mostly_after_init);
+   unsigned long end = PFN_ALIGN(&__end_data_ro_mostly_after_init);
+   unsigned long nr_pages = (end - start) >> PAGE_SHIFT;
+
+   if (!rodata_enabled)
+   return;
+
+   set_memory_ro(start, nr_pages);
+}
 #else
 static inline void mark_readonly(void)
 {
-- 
2.7.4

[RFC 7/7] arm64: map seperately rodata sections for __ro_mostly_after_init section

[Hoeun Ryu]

Map rodata sections seperately for the new __ro_mostly_after_init section.
Attribute of memory for __ro_mostly_after_init section can be changed later
so we need a dedicated vmalloced region for set_memory_rw/ro api.

Signed-off-by: Hoeun Ryu 
---
 arch/arm64/mm/mmu.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 91271b1..4a89a2e 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -434,8 +434,22 @@ void mark_rodata_ro(void)
 * mark .rodata as read only. Use __init_begin rather than __end_rodata
 * to cover NOTES and EXCEPTION_TABLE.
 */
-   section_size = (unsigned long)__init_begin - (unsigned 
long)__start_rodata;
-   create_mapping_late(__pa_symbol(__start_rodata), (unsigned 
long)__start_rodata,
+   section_size = (unsigned long)__start_data_ro_mostly_after_init -
+   (unsigned long)__start_rodata;
+   create_mapping_late(__pa_symbol(__start_rodata),
+   (unsigned long)__start_rodata,
+   section_size, PAGE_KERNEL_RO);
+
+   section_size = (unsigned long)__end_data_ro_mostly_after_init -
+   (unsigned long)__start_data_ro_mostly_after_init;
+   create_mapping_late(__pa_symbol(__start_data_ro_mostly_after_init),
+   (unsigned long)__start_data_ro_mostly_after_init,
+   section_size, PAGE_KERNEL_RO);
+
+   section_size = (unsigned long)__init_begin -
+   (unsigned long)__end_data_ro_mostly_after_init;
+   create_mapping_late(__pa_symbol(__end_data_ro_mostly_after_init),
+   (unsigned long)__end_data_ro_mostly_after_init,
section_size, PAGE_KERNEL_RO);
 
/* flush the TLBs after updating live kernel mappings */
@@ -478,10 +492,18 @@ static void __init map_kernel_segment(pgd_t *pgd, void 
*va_start, void *va_end,
  */
 static void __init map_kernel(pgd_t *pgd)
 {
-   static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_init, 
vmlinux_data;
+   static struct vm_struct vmlinux_text, vmlinux_rodata1, vmlinux_rodata2, 
vmlinux_ro_mostly_after_init, vmlinux_init, vmlinux_data;
 
map_kernel_segment(pgd, _text, _etext, PAGE_KERNEL_EXEC, &vmlinux_text);
-   map_kernel_segment(pgd, __start_rodata, __init_begin, PAGE_KERNEL, 
&vmlinux_rodata);
+   map_kernel_segment(pgd, __start_rodata, 
__start_data_ro_mostly_after_init, PAGE_KERNEL, &vmlinux_rodata1);
+   __map_kernel_segment(pgd,
+__start_data_ro_mostly_after_init,
+__end_data_ro_mostly_after_init,
+PAGE_KERNEL,
+&vmlinux_ro_mostly_after_init,
+VM_MAP | VM_ALLOC);
+   map_kernel_segment(pgd, __end_data_ro_mostly_after_init, __init_begin, 
PAGE_KERNEL, &vmlinux_rodata2);
+
map_kernel_segment(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC,
   &vmlinux_init);
map_kernel_segment(pgd, _data, _end, PAGE_KERNEL, &vmlinux_data);
-- 
2.7.4

[RFC 6/7] arm64: add __map_kernel_segment to accept additional vm flags

[Hoeun Ryu]

 Memory attribute for `__ro_mostly_after_init` section should be changed
via set_memory_rw/ro that doesn't work against vm areas which don't have
VM_ALLOC. Add this function to map `__ro_mostly_after_init` section with
VM_ALLOC flag set in map_kernel.

Signed-off-by: Hoeun Ryu 
---
 arch/arm64/mm/mmu.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index b805c01..91271b1 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -444,8 +444,10 @@ void mark_rodata_ro(void)
debug_checkwx();
 }
 
-static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
- pgprot_t prot, struct vm_struct *vma)
+static void __init __map_kernel_segment(pgd_t *pgd,
+   void *va_start, void *va_end,
+   pgprot_t prot, struct vm_struct *vma,
+   unsigned long flags)
 {
phys_addr_t pa_start = __pa_symbol(va_start);
unsigned long size = va_end - va_start;
@@ -459,12 +461,18 @@ static void __init map_kernel_segment(pgd_t *pgd, void 
*va_start, void *va_end,
vma->addr   = va_start;
vma->phys_addr  = pa_start;
vma->size   = size;
-   vma->flags  = VM_MAP;
+   vma->flags  = flags;
vma->caller = __builtin_return_address(0);
 
vm_area_add_early(vma);
 }
 
+static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
+ pgprot_t prot, struct vm_struct *vma)
+{
+   return __map_kernel_segment(pgd, va_start, va_end, prot, vma, VM_MAP);
+}
+
 /*
  * Create fine-grained mappings for the kernel.
  */
-- 
2.7.4

[PATCH] ASLA: emu10k1: constify snd_emux_operators structure

[Bhumika Goyal]

Declare snd_emux_operators structure as const as it is only copied into
another structure. So, snd_emux_operators structures having this property
can be made const.

Signed-off-by: Bhumika Goyal 
---
 sound/pci/emu10k1/emu10k1_callback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/emu10k1/emu10k1_callback.c 
b/sound/pci/emu10k1/emu10k1_callback.c
index d2c7ea3..aa2cc27 100644
--- a/sound/pci/emu10k1/emu10k1_callback.c
+++ b/sound/pci/emu10k1/emu10k1_callback.c
@@ -61,7 +61,7 @@ static struct snd_emux_voice *get_voice(struct snd_emux *emux,
 /*
  * set up operators
  */
-static struct snd_emux_operators emu10k1_ops = {
+static const struct snd_emux_operators emu10k1_ops = {
.owner =THIS_MODULE,
.get_voice =get_voice,
.prepare =  start_voice,
-- 
1.9.1

Re: [PATCH v7 2/2] mtd: nand: Add support for Arasan NAND Flash Controller

[Boris Brezillon]

Hi Punnaiah,

Sorry for the late reply.

On Mon, 9 Jan 2017 08:28:54 +0530
Punnaiah Choudary Kalluri  wrote:

> Added the basic driver for Arasan NAND Flash Controller used in
> Zynq UltraScale+ MPSoC. It supports only Hw ECC and upto 24bit
> correction.
> 
> Signed-off-by: Punnaiah Choudary Kalluri 
> ---
> Changes in v7:
> - Implemented Marek suggestions and comments
> - Corrected the acronyms those should be in caps
> - Modified kconfig/Make file to keep arasan entry in sorted order
> - Added is_vmlloc_addr check
> - Used ioread/write32_rep variants to avoid compilation error for intel
>   platforms
> - separated PIO and DMA mode read/write functions
> - Minor cleanup
> Chnages in v6:
> - Addressed most of the Brian and Boris comments
> - Separated the nandchip from the nand controller
> - Removed the ecc lookup table from driver
> - Now use framework nand waitfunction and readoob
> - Fixed the compiler warning
> - Adapted the new frameowrk changes related to ecc and ooblayout
> - Disabled the clocks after the nand_reelase
> - Now using only one completion object
> - Boris suggessions like adapting cmd_ctrl and rework on read/write byte
>   are not implemented and i will patch them later
> - Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr will
>   implement later once the basic driver is mainlined.
> Changes in v5:
> - Renamed the driver filei as arasan_nand.c
> - Fixed all comments relaqted coding style
> - Fixed comments related to propagating the errors
> - Modified the anfc_write_page_hwecc as per the write_page
>   prototype
> Changes in v4:
> - Added support for onfi timing mode configuration
> - Added clock suort
> - Added support for multiple chipselects
> Changes in v3:
> - Removed unused variables
> - Avoided busy loop and used jifies based implementation
> - Fixed compiler warnings "right shift count >= width of type"
> - Removed unneeded codei and improved error reporting
> - Added onfi version check to ensure reading the valid address cycles
> Changes in v2:
> - Added missing of.h to avoid kbuild system report erro
> ---
>  drivers/mtd/nand/Kconfig   |   8 +
>  drivers/mtd/nand/Makefile  |   1 +
>  drivers/mtd/nand/arasan_nand.c | 932 
> +
>  3 files changed, 941 insertions(+)
>  create mode 100644 drivers/mtd/nand/arasan_nand.c

checkpatch.pl --strict reports a few coding style problems. Can you fix
them?

[...]

> +#define PROG_PGRDBIT(0)
> +#define PROG_ERASE   BIT(2)
> +#define PROG_STATUS  BIT(3)
> +#define PROG_PGPROG  BIT(4)
> +#define PROG_RDIDBIT(6)
> +#define PROG_RDPARAM BIT(7)
> +#define PROG_RST BIT(8)
> +#define PROG_GET_FEATURE BIT(9)
> +#define PROG_SET_FEATURE BIT(10)

I know I'm being insistent on this, but I don't understand what these
different prog modes are meant for. You still have to set the NAND
command and address cycles, so it probably has to do with timing
sequences, but that's not clearly described in the doc you pointed.

[...]

> +static void anfc_rw_buf_dma(struct mtd_info *mtd, uint8_t *buf, int len,
> + int operation, u32 prog)
> +{
> + dma_addr_t paddr;
> + struct nand_chip *chip = mtd_to_nand(mtd);
> + struct anfc *nfc = to_anfc(chip->controller);
> + struct anfc_nand_chip *achip = to_anfc_nand(chip);
> + u32 eccintr = 0, dir;
> + u32 pktsize = len, pktcount = 1;
> +
> + if ((nfc->curr_cmd == NAND_CMD_READ0) ||
> + ((nfc->curr_cmd == NAND_CMD_SEQIN) && !nfc->iswriteoob)) {
> + pktsize = achip->pktsize;
> + pktcount = DIV_ROUND_UP(mtd->writesize, pktsize);
> + }

I really don't like what's done here (the fact that you test
->curr_cmd in something that is supposed to be command agnostic). Maybe
you should just avoid using ->write_buf() when programming a page, and
have a custom function doing that.

Let's try to keep ->read/write_buf() as generic as possible.

> + anfc_setpktszcnt(nfc, pktsize, pktcount);
> +
> + if (!achip->bch && (nfc->curr_cmd == NAND_CMD_READ0))
> + eccintr = MBIT_ERROR;

Ditto.

> +
> + if (operation)
> + dir = DMA_FROM_DEVICE;
> + else
> + dir = DMA_TO_DEVICE;
> +
> + paddr = dma_map_single(nfc->dev, buf, len, dir);
> + if (dma_mapping_error(nfc->dev, paddr)) {
> + dev_err(nfc->dev, "Read buffer mapping error");
> + return;
> + }
> + lo_hi_writeq(paddr, nfc->base + DMA_ADDR0_OFST);
> + anfc_enable_intrs(nfc, (XFER_COMPLETE | eccintr));
> + writel(prog, nfc->base + PROG_OFST);
> + anfc_wait_for_event(nfc);
> + dma_unmap_single(nfc->dev, paddr, len, dir);
> +}
> +
> +static void anfc_rw_buf_pio(struct mtd_info *mtd, uint8_t *buf, int len,
> + int operation, int prog)
> +{
> + struct nand_chip *chi

[PATCH] staging: bcm2835: Fix a memory leak in error handling path

[Christophe JAILLET]

If 'kzalloc()' fails, we should release resources allocated so far, just as
done in all other cases in this function.

Signed-off-by: Christophe JAILLET 
---
Not sure that the error handling path is correct.
Is 'gdev[0]' freed? Should it be?
---
 drivers/staging/media/platform/bcm2835/bcm2835-camera.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c 
b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
index ca15a698e018..9651b9bc3439 100644
--- a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
+++ b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
@@ -1914,8 +1914,10 @@ static int __init bm2835_mmal_init(void)
 
for (camera = 0; camera < num_cameras; camera++) {
dev = kzalloc(sizeof(struct bm2835_mmal_dev), GFP_KERNEL);
-   if (!dev)
-   return -ENOMEM;
+   if (!dev) {
+   ret = -ENOMEM;
+   goto free_dev;
+   }
 
dev->camera_num = camera;
dev->max_width = resolutions[camera][0];
-- 
2.9.3

Re: [PATCH] Staging: iio: impedance-analyzer: ad5933.c - style fix

[Jonathan Cameron]

On 12/02/17 07:22, Derek Robson wrote:
> Change permissions to octal style.
> Found using checkpatch
> 
> Signed-off-by: Derek Robson 
Applied to the togreg branch of iio.git and pushed out as testing for the 
autobuilders
to play with it.

Jonathan
> ---
>  drivers/staging/iio/impedance-analyzer/ad5933.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c 
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index 5e96352fa4ac..297665d3fe11 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -345,12 +345,12 @@ static ssize_t ad5933_store_frequency(struct device 
> *dev,
>   return ret ? ret : len;
>  }
>  
> -static IIO_DEVICE_ATTR(out_voltage0_freq_start, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(out_voltage0_freq_start, 0644,
>   ad5933_show_frequency,
>   ad5933_store_frequency,
>   AD5933_REG_FREQ_START);
>  
> -static IIO_DEVICE_ATTR(out_voltage0_freq_increment, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(out_voltage0_freq_increment, 0644,
>   ad5933_show_frequency,
>   ad5933_store_frequency,
>   AD5933_REG_FREQ_INC);
> @@ -469,32 +469,32 @@ static ssize_t ad5933_store(struct device *dev,
>   return ret ? ret : len;
>  }
>  
> -static IIO_DEVICE_ATTR(out_voltage0_scale, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(out_voltage0_scale, 0644,
>   ad5933_show,
>   ad5933_store,
>   AD5933_OUT_RANGE);
>  
> -static IIO_DEVICE_ATTR(out_voltage0_scale_available, S_IRUGO,
> +static IIO_DEVICE_ATTR(out_voltage0_scale_available, 0444,
>   ad5933_show,
>   NULL,
>   AD5933_OUT_RANGE_AVAIL);
>  
> -static IIO_DEVICE_ATTR(in_voltage0_scale, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(in_voltage0_scale, 0644,
>   ad5933_show,
>   ad5933_store,
>   AD5933_IN_PGA_GAIN);
>  
> -static IIO_DEVICE_ATTR(in_voltage0_scale_available, S_IRUGO,
> +static IIO_DEVICE_ATTR(in_voltage0_scale_available, 0444,
>   ad5933_show,
>   NULL,
>   AD5933_IN_PGA_GAIN_AVAIL);
>  
> -static IIO_DEVICE_ATTR(out_voltage0_freq_points, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(out_voltage0_freq_points, 0644,
>   ad5933_show,
>   ad5933_store,
>   AD5933_FREQ_POINTS);
>  
> -static IIO_DEVICE_ATTR(out_voltage0_settling_cycles, S_IRUGO | S_IWUSR,
> +static IIO_DEVICE_ATTR(out_voltage0_settling_cycles, 0644,
>   ad5933_show,
>   ad5933_store,
>   AD5933_OUT_SETTLING_CYCLES);
> 

Re: [kernel-hardening] [PATCH 0/7] introduce __ro_mostly_after_init section marker

[Ard Biesheuvel]

Hi Hoeun,

On 19 February 2017 at 10:03, Hoeun Ryu  wrote:
>  After `__ro_after_init` marker is included in kernel, many kernel data
> objects can be read-only-after-init. But there are many other places that
> would be good to read-only-after-init but `__ro_after_init` can not be simply
> applicable to them because they should be writable at some points, which are
> during module_init/exit or dynamic de/registration for a specific subsystem.

The argument sounds reasonable, but it would really help if you could
describe some use cases in more detail.

>  `__ro_mostly_after_init` is basically the same to `__ro_after_init`. The
> section is mapped as read-only after kernel init. The different thing is
> this section is temporarily mapped as read-write during module_init/exit and
> de/registration of a subsystem using set_ro_mostly_after_init_rw/ro pair.
>
> - Tested only on arm64.
>
> Description:
>   0001 patch is `__ro_mostly_after_init` itself.
>   0002 patch is to add set_ro_mostly_after_init_rw/ro pair using
> set_memory_rw/ro.
>   0003 patch is to make the section read-write in module_init/exit.
>   0004 patch is an example for dynamic init/deinit of a subsystem.
>   0005 patch is an example for __ro_mostly_after_init section modified during
> module_init/exit.
>   0006/0007 patches are fixes for arm64 kernel mapping.
>
> Hoeun Ryu (7):
>   arch: add __ro_mostly_after_init section marker
>   init: add set_ro_mostly_after_init_rw/ro function
>   module: modify memory attrs for __ro_mostly_after_init during
> module_init/exit
>   selinux: mark __ro_mostly_after_init for selinux_hooks/selinux_nf_ops
>   cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states
>   arm64: add __map_kernel_segment to accept additional vm flags
>   arm64: map seperately rodata sections for __ro_mostly_after_init
> section
>
>  arch/arm64/mm/mmu.c   | 44 
> ---
>  include/asm-generic/sections.h|  1 +
>  include/asm-generic/vmlinux.lds.h | 10 +
>  include/linux/cache.h | 11 ++
>  include/linux/init.h  |  6 ++
>  init/main.c   | 24 +
>  kernel/cpu.c  |  4 ++--
>  kernel/module.c   | 10 +++--
>  security/selinux/hooks.c  |  8 +--
>  9 files changed, 105 insertions(+), 13 deletions(-)
>
> --
> 2.7.4
>

Re: [RFC 6/7] arm64: add __map_kernel_segment to accept additional vm flags

[Ard Biesheuvel]

On 19 February 2017 at 10:04, Hoeun Ryu  wrote:
>  Memory attribute for `__ro_mostly_after_init` section should be changed
> via set_memory_rw/ro that doesn't work against vm areas which don't have
> VM_ALLOC.

This is for a good reason: VMALLOC regions are guaranteed to be mapped
down to pages, which is the only thing set_memory_rX() supports. On
arm64, kernel segments may be mapped using contiguous page mappings or
block mappings, which cannot be modified like this.

> Add this function to map `__ro_mostly_after_init` section with
> VM_ALLOC flag set in map_kernel.
>

If we add this functionality, I'd rather we have a special handler for
the __ro_mostly_after_init section and not use set_memory_rX().

> Signed-off-by: Hoeun Ryu 
> ---
>  arch/arm64/mm/mmu.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index b805c01..91271b1 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -444,8 +444,10 @@ void mark_rodata_ro(void)
> debug_checkwx();
>  }
>
> -static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void 
> *va_end,
> - pgprot_t prot, struct vm_struct *vma)
> +static void __init __map_kernel_segment(pgd_t *pgd,
> +   void *va_start, void *va_end,
> +   pgprot_t prot, struct vm_struct *vma,
> +   unsigned long flags)
>  {
> phys_addr_t pa_start = __pa_symbol(va_start);
> unsigned long size = va_end - va_start;
> @@ -459,12 +461,18 @@ static void __init map_kernel_segment(pgd_t *pgd, void 
> *va_start, void *va_end,
> vma->addr   = va_start;
> vma->phys_addr  = pa_start;
> vma->size   = size;
> -   vma->flags  = VM_MAP;
> +   vma->flags  = flags;
> vma->caller = __builtin_return_address(0);
>
> vm_area_add_early(vma);
>  }
>
> +static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void 
> *va_end,
> + pgprot_t prot, struct vm_struct *vma)
> +{
> +   return __map_kernel_segment(pgd, va_start, va_end, prot, vma, VM_MAP);
> +}
> +
>  /*
>   * Create fine-grained mappings for the kernel.
>   */
> --
> 2.7.4
>

Re: [PATCH v2 1/2] staging: iio: isl29028: change sampling frequencies available to use decimals

[Jonathan Cameron]

On 12/02/17 10:55, Brian Masney wrote:
> The sysfs attribute in_proximity_sampling_frequency_available currently
> shows the values 1 3 5 10 13 20 83 100. These values are supposed to
> correspond to the sleep values 800 400 200 100 75 50 12 0 (all in ms).
> When passing in a sampling frequency of 3, it actually uses a sleep
> time of 200ms instead of the expected 400ms value. This patch changes
> the value shown by this sysfs attribute to use decimal numbers so
> that the correct sampling frequency is shown to the user. Only the
> integer portion is actually passed to isl29028_set_proxim_sampling(),
> but that is ok since the correct sleep time will still be selected.
I'm a little bothered by this because the behaviour is not consistent if we
feed it various values around 2.5 for example.
2.0-2. all get rounded to 2.5 where as 3 gets round to 5.
We need something more logical.

As a side note, 1000/12.5 = 80 not 83. which looks like a bug to me.

All these frequencies are wrong anyway as they are based on the assumption
that all the time is spent in the inter sample sleeps.  I think
the datasheet puts this at 0.54 msecs so doesn't make much difference ;)

I'm not 100% sure if running proximity and ambient light sensing at the same
time changes the frequency or not.

So I'd like to see it do one of two things, reject any value not matching
what is exposed in the _available attribute, or round up on the basis
if we select the sampling frequency we'll typically set it to the lowest
value that meets our requirements.  (I debated rounding to nearest, but
I think for sampling frequency it should be round up).  We should probably
document that as well in the ABI docs as it will be non obvious which one
makes sense for different parameters!

Jonathan
> 
> Signed-off-by: Brian Masney 
> ---
>  drivers/staging/iio/light/isl29028.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/iio/light/isl29028.c 
> b/drivers/staging/iio/light/isl29028.c
> index 5375e7a..c1d6540 100644
> --- a/drivers/staging/iio/light/isl29028.c
> +++ b/drivers/staging/iio/light/isl29028.c
> @@ -472,7 +472,7 @@ static int isl29028_read_raw(struct iio_dev *indio_dev,
>  }
>  
>  static IIO_CONST_ATTR(in_proximity_sampling_frequency_available,
> - "1 3 5 10 13 20 83 100");
> + "1.25 2.5 5 10 13.3 20 83.3 100");
>  static IIO_CONST_ATTR(in_illuminance_scale_available, "125 2000");
>  
>  #define ISL29028_CONST_ATTR(name) (&iio_const_attr_##name.dev_attr.attr)
> 

Re: [kernel-hardening] [RFC 1/7] arch: add __ro_mostly_after_init section marker

[Ard Biesheuvel]

On 19 February 2017 at 10:04, Hoeun Ryu  wrote:
>  After `__ro_after_init` marker is included in kernel, many kernel data
> objects can be read-only-after-init. But there are many other places that
> would be good to read-only-after-init but `__ro_after_init` can not be simply
> applicable to them because they should be writable at some points, which are
> during module_init/exit or dynamic de/registration for a specific subsystem.
>  `__ro_mostly_after_init` is basically the same to `__ro_after_init`. The
> section is mapped as read-only after kernel init. The different thing is
> this section is temporarily mapped as read-write during module_init/exit and
> de/registration of a subsystem using set_ro_mostly_after_init_rw/ro pair.
>  Use `__ro_mostly_after_init` as a way to mark such memory instead when
> `__ro_after_init` is not applicable because the memory should be writable
> at the described points of time. They are read-only right after kernel init
> and writable temporarily only during module_init/exit and dynamic
> de/registration for a subsystem.
>
> Signed-off-by: Hoeun Ryu 
> ---
>  include/asm-generic/sections.h|  1 +
>  include/asm-generic/vmlinux.lds.h | 10 ++
>  include/linux/cache.h | 11 +++
>  3 files changed, 22 insertions(+)
>
> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
> index 4df64a1..16a6f21 100644
> --- a/include/asm-generic/sections.h
> +++ b/include/asm-generic/sections.h
> @@ -34,6 +34,7 @@ extern char __bss_start[], __bss_stop[];
>  extern char __init_begin[], __init_end[];
>  extern char _sinittext[], _einittext[];
>  extern char __start_data_ro_after_init[], __end_data_ro_after_init[];
> +extern char __start_data_ro_mostly_after_init[], 
> __end_data_ro_mostly_after_init[];
>  extern char _end[];
>  extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[];
>  extern char __kprobes_text_start[], __kprobes_text_end[];
> diff --git a/include/asm-generic/vmlinux.lds.h 
> b/include/asm-generic/vmlinux.lds.h
> index 4e09b28..cc5f44e 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -265,6 +265,15 @@
> __end_data_ro_after_init = .;
>  #endif
>
> +#ifndef RO_MOSTLY_AFTER_INIT_DATA
> +#define RO_MOSTLY_AFTER_INIT_DATA(align)   \
> +   . = ALIGN(align);   \
> +   VMLINUX_SYMBOL(__start_data_ro_mostly_after_init) = .;  \
> +   *(.data..ro_mostly_after_init)  \
> +   . = ALIGN(align);   \
> +   VMLINUX_SYMBOL(__end_data_ro_mostly_after_init) = .;
> +#endif
> +
>  /*
>   * Read only Data
>   */
> @@ -275,6 +284,7 @@
> *(.rodata) *(.rodata.*) \
> RO_AFTER_INIT_DATA  /* Read only after init */  \
> KEEP(*(__vermagic)) /* Kernel version magic */  \
> +   RO_MOSTLY_AFTER_INIT_DATA(align)\

You can't really drop this in the middle of a section like this. On
arm64, we try very hard to use a minimal segment alignment of 64 KB
(of 2 MB if DEBUG_ALIGN_RODATA=y), to ensure that the TLB footprint of
the kernel image is minimized.

So this should be a separate section in the arm64 linker script.

> . = ALIGN(8);   \
> VMLINUX_SYMBOL(__start___tracepoints_ptrs) = .; \
> KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer array */ \
> diff --git a/include/linux/cache.h b/include/linux/cache.h
> index 1be04f8..fd1cb9b 100644
> --- a/include/linux/cache.h
> +++ b/include/linux/cache.h
> @@ -30,6 +30,17 @@
>  #define __ro_after_init __attribute__((__section__(".data..ro_after_init")))
>  #endif
>
> +/*
> + * __ro_mostly_after_init is almost like __ro_after_init.
> + * but __ro_mostly_after_init section is temporarily writable only during
> + * module_init/exit or dynamic de/registeration of a subsystem using
> + * set_ro_mostly_after_init_rw/ro pair.
> + */
> +#ifndef __ro_mostly_after_init
> +#define __ro_mostly_after_init \
> +   __attribute__((__section__(".data..ro_mostly_after_init")))
> +#endif
> +
>  #ifndef cacheline_aligned
>  #define cacheline_aligned __attribute__((__aligned__(SMP_CACHE_BYTES)))
>  #endif
> --
> 2.7.4
>

Re: [PATCH v2 2/2] staging: iio: isl29028: move out of staging

[Jonathan Cameron]

On 12/02/17 11:04, Brian Masney wrote:
> On Sun, Feb 12, 2017 at 05:55:34AM -0500, Brian Masney wrote:
>> Move ISL29028 ALS / Proximity Sensor out of staging and into mainline.
>>
>> Signed-off-by: Brian Masney 
> 
> Sorry, Jonathan, I forgot to run git format-patch with --no-renames and
> didn't realize until the emails went out. I attached the driver source
> to make it easier to review inline.
> 
> Brian
> 
Pasting inline for comments:

I only had the one and that was mostly because I thought I should say
something having taken one last look.

If we get patch 1 issues tidied up then moving out of staging is
fine by me.  Lots of time in this cycle anyway so I'm being fussy
than I might otherwise be!

Jonathan
> /*
>  * IIO driver for the light sensor ISL29028.
>  * ISL29028 is Concurrent Ambient Light and Proximity Sensor
>  *
>  * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
>  * Copyright (c) 2016-2017 Brian Masney 
>  *
>  * This program is free software; you can redistribute it and/or modify it
>  * under the terms and conditions of the GNU General Public License,
>  * version 2, as published by the Free Software Foundation.
>  *
>  * This program is distributed in the hope it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>  * more details.
>  *
>  * You should have received a copy of the GNU General Public License
>  * along with this program.  If not, see .
>  */
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define ISL29028_CONV_TIME_MS 100
> 
> #define ISL29028_REG_CONFIGURE0x01
> 
> #define ISL29028_CONF_ALS_IR_MODE_ALS 0
> #define ISL29028_CONF_ALS_IR_MODE_IR  BIT(0)
> #define ISL29028_CONF_ALS_IR_MODE_MASKBIT(0)
> 
> #define ISL29028_CONF_ALS_RANGE_LOW_LUX   0
> #define ISL29028_CONF_ALS_RANGE_HIGH_LUX  BIT(1)
> #define ISL29028_CONF_ALS_RANGE_MASK  BIT(1)
> 
> #define ISL29028_CONF_ALS_DIS 0
> #define ISL29028_CONF_ALS_EN  BIT(2)
> #define ISL29028_CONF_ALS_EN_MASK BIT(2)
> 
> #define ISL29028_CONF_PROX_SLP_SH 4
> #define ISL29028_CONF_PROX_SLP_MASK   (7 << ISL29028_CONF_PROX_SLP_SH)
> 
> #define ISL29028_CONF_PROX_EN BIT(7)
> #define ISL29028_CONF_PROX_EN_MASKBIT(7)
> 
> #define ISL29028_REG_INTERRUPT0x02
> 
> #define ISL29028_REG_PROX_DATA0x08
> #define ISL29028_REG_ALSIR_L  0x09
> #define ISL29028_REG_ALSIR_U  0x0A
> 
> #define ISL29028_REG_TEST1_MODE   0x0E
> #define ISL29028_REG_TEST2_MODE   0x0F
> 
> #define ISL29028_NUM_REGS (ISL29028_REG_TEST2_MODE + 1)
> 
> #define ISL29028_POWER_OFF_DELAY_MS   2000
> 
> static const unsigned int isl29028_prox_sleep_time[] = {800, 400, 200, 100, 
> 75,
>   50, 12, 0};
> 
> enum isl29028_als_ir_mode {
>   ISL29028_MODE_NONE = 0,
>   ISL29028_MODE_ALS,
>   ISL29028_MODE_IR,
> };
> 
> struct isl29028_chip {
>   struct mutexlock;
>   struct regmap   *regmap;
>   unsigned intprox_sampling;
>   boolenable_prox;
>   int lux_scale;
>   enum isl29028_als_ir_mode   als_ir_mode;
> };
> 
> static int isl29028_find_prox_sleep_time_index(int sampling)
> {
>   unsigned int period = DIV_ROUND_UP(1000, sampling);
>   int i;
> 
>   for (i = 0; i < ARRAY_SIZE(isl29028_prox_sleep_time); ++i) {
>   if (period >= isl29028_prox_sleep_time[i])
>   break;
>   }
> 
>   return i;
> }
> 
> static int isl29028_set_proxim_sampling(struct isl29028_chip *chip,
>   unsigned int sampling)
> {
>   struct device *dev = regmap_get_device(chip->regmap);
>   int sleep_index, ret;
> 
>   sleep_index = isl29028_find_prox_sleep_time_index(sampling);
>   ret = regmap_update_bits(chip->regmap, ISL29028_REG_CONFIGURE,
>ISL29028_CONF_PROX_SLP_MASK,
>sleep_index << ISL29028_CONF_PROX_SLP_SH);
> 
>   if (ret < 0) {
>   dev_err(dev, "%s(): Error %d setting the proximity sampling\n",
>   __func__, ret);
>   return ret;
>   }
> 
>   chip->prox_sampling = sampling;
> 
>   return ret;
> }
> 
> static int isl29028_enable_proximity(struct isl29028_chip *chip)
> {
>   int sleep_index, ret;
> 
>   ret = isl29028_set_proxim_sampling(chip, chip->prox_sampling);
>   if (ret < 0)
>

Re: g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

[Ondrej Zary]

On Sunday 19 February 2017 00:27:55 Finn Thain wrote:
> On Sat, 18 Feb 2017, Ondrej Zary wrote:
> > On Friday 17 February 2017 23:38:12 Finn Thain wrote:
> > > On Thu, 16 Feb 2017, Ondrej Zary wrote:
> > > > On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
> > > > [...]
> > > >
> > > > > Are you trying to figure out which commands are going to
> > > > > disconnect during a transfer? This is really a function of the
> > > > > firmware in the target; there are no good heuristics AFAICT, so
> > > > > the PDMA algorithm has to be robust. mac_scsi has to cope with
> > > > > this too.
> > > > >
> > > > > Does the problem go away when you assign no IRQ? When
> > > > > instance->irq == NO_IRQ, the core driver will inhibit disconnect
> > > > > privileges.
> > > >
> > > > Yes, it seems to run fine with IRQ/disconnect disabled. With IRQ
> > > > enabled, "dd if=/dev/sr0 of=anything" stops after a while.
> > >
> > > When you say "stops", do you mean an infinite loop in
> > > generic_NCR5380_pread or does the loop complete (which would
> > > presumably leave the target stuck in DATA IN phase, and a scsi command
> > > timeout would probably follow after 30 seconds...)
> >
> > I've added timeouts to the possibly-infinite loops. It times out waiting
> > for the host buffer to become ready.
>
> In mac_scsi you'll find that the PDMA loop exploits the 15ms poll_politely
> time limit to give the target device time to catch up. You might want to
> do something similar.
>
> > Then everything breaks. Now I found why: pread() returns without waiting
> > for the 53C80 registers to be ready.
>
> Ouch! You can't return control to the core driver when the 53C80 core is
> unavailable. That would need special handling: the core driver would have
> to fail the scsi command and reset the device (and bus), based on the
> result you return from NCR5380_dma_recv_setup/NCR5380_dma_send_setup.
>
> > Adding the wait allows to continue in PIO mode with "tag#0 switching to
> > slow handshake".
>
> I don't think this is the code path you want. The target isn't really
> broken. But yes, we could use PIO as a slow workaround for fragile PDMA
> logic.

Yes, we don't want that.

> > > > I get gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.
> > >
> > > You can use NCR5380_print() to get a decoded register dump.
> > >
> > > When I decode the above values I get,
> > >
> > > BASR   = 0x10 = BASR_IRQ
> > > MODE   = 0x0e = MR_ENABLE_EOP_INTR | MR_MONITOR_BSY | MR_DMA_MODE
> > > STATUS = 0x7c = SR_BSY | SR_REQ | SR_MSG | SR_CD | SR_IO
> > >
> > > Since BASR_PHASE_MATCH is not set, the interrupt is almost certainly a
> > > phase mismatch. The new phase is SR_MSG | SR_CD | SR_IO = PHASE_MSGIN,
> > > which shows that the target has given up on the DATA IN phase and is
> > > presumably trying to send a DISCONNECT message.
> >
> > Looks you're right. The transfersize is 4096, i.e. 2 CD-ROM sectors.
> > When the 2nd sector is not ready in the drive internal buffer, the drive
> > probably disconnects which breaks the fragile pdma transfer. When the
> > transfersize is limited to 2048 bytes, the problem goes away.
>
> OK.
>
> > The problem also went away with enabled interrupts because I had some
> > debug printks added which were slowing down the transfer enough for the
> > drive (SONY CDU-55S) to keep up and not disconnect. Got the same result
> > by inserting udelay(100) after each 128 byte block trasnferred in
> > pread().
>
> Well, yeah, if you change the timing and omit to mention that, as well as
> changing the spinlock_irq_save/restore pairs, then it's going to be
> difficult for me to make sense of your results. Anyway, I'm glad that you
> got to the bottom of this mystery.
>
> > > > When I enable interrupts during PDMA (like the removed UNSAFE macro
> > > > did), the problems go away. I see an IRQ after each pread call.

These two patches are enough to make PDMA work with CD-ROM drives on
53C400(A), with IRQ enabled or not. They even improve transfer rates with
HDDs because of bigger block size.

But DTC436 breaks with CDU-55S, immediately after modprobe.
1) Seems that IRQ timing is slightly different so I rewrote the wait for
the host buffer to include check for CSR_GATED_53C80_IRQ. This allows some
data to be transferred but
2) DTC436 likes to hang (return only 0xff from all registers - like it's
not even present on the bus) on repeating CSR register reads and maybe some
other actions too. This problem already appeared before in pwrite() where
I added the udelay(4) workaround. Now I added udelay(100) to the waits but
it still crashes sometimes (randomly after tenths or hundreds of MB).

diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 6f9665d..9d0cfd4 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -585,26 +585,20 @@ static inline int generic_NCR5380_pwrite(struct 
NCR5380_hostdata *hostdata,
return 0;
 }
 
+#define G_NCR5380_DMA_MAX_SIZE 32768
 static int generic_NCR5380_dma_xfer_len(struct 

Re: [PATCHv3,4/4] MAINTAINERS: Remove powerpc's opal match

[Michael Ellerman]

On Thu, 2017-02-16 at 00:37:15 UTC, Stewart Smith wrote:
> Remove OPAL regex in powerpc to avoid false match
> 
> Signed-off-by: Stewart Smith 
> Reviewed-by: Andrew Donnellan 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/a42715830d552d7c0e3be709383ece

cheers

Re: [RFC 7/7] arm64: map seperately rodata sections for __ro_mostly_after_init section

[Ard Biesheuvel]

On 19 February 2017 at 10:04, Hoeun Ryu  wrote:
> Map rodata sections seperately for the new __ro_mostly_after_init section.
> Attribute of memory for __ro_mostly_after_init section can be changed later
> so we need a dedicated vmalloced region for set_memory_rw/ro api.
>
> Signed-off-by: Hoeun Ryu 
> ---
>  arch/arm64/mm/mmu.c | 30 ++
>  1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 91271b1..4a89a2e 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -434,8 +434,22 @@ void mark_rodata_ro(void)
>  * mark .rodata as read only. Use __init_begin rather than 
> __end_rodata
>  * to cover NOTES and EXCEPTION_TABLE.
>  */
> -   section_size = (unsigned long)__init_begin - (unsigned 
> long)__start_rodata;
> -   create_mapping_late(__pa_symbol(__start_rodata), (unsigned 
> long)__start_rodata,
> +   section_size = (unsigned long)__start_data_ro_mostly_after_init -
> +   (unsigned long)__start_rodata;
> +   create_mapping_late(__pa_symbol(__start_rodata),
> +   (unsigned long)__start_rodata,
> +   section_size, PAGE_KERNEL_RO);
> +
> +   section_size = (unsigned long)__end_data_ro_mostly_after_init -
> +   (unsigned long)__start_data_ro_mostly_after_init;
> +   create_mapping_late(__pa_symbol(__start_data_ro_mostly_after_init),
> +   (unsigned long)__start_data_ro_mostly_after_init,
> +   section_size, PAGE_KERNEL_RO);
> +
> +   section_size = (unsigned long)__init_begin -
> +   (unsigned long)__end_data_ro_mostly_after_init;
> +   create_mapping_late(__pa_symbol(__end_data_ro_mostly_after_init),
> +   (unsigned long)__end_data_ro_mostly_after_init,
> section_size, PAGE_KERNEL_RO);
>
> /* flush the TLBs after updating live kernel mappings */
> @@ -478,10 +492,18 @@ static void __init map_kernel_segment(pgd_t *pgd, void 
> *va_start, void *va_end,
>   */
>  static void __init map_kernel(pgd_t *pgd)
>  {
> -   static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_init, 
> vmlinux_data;
> +   static struct vm_struct vmlinux_text, vmlinux_rodata1, 
> vmlinux_rodata2, vmlinux_ro_mostly_after_init, vmlinux_init, vmlinux_data;
>
> map_kernel_segment(pgd, _text, _etext, PAGE_KERNEL_EXEC, 
> &vmlinux_text);
> -   map_kernel_segment(pgd, __start_rodata, __init_begin, PAGE_KERNEL, 
> &vmlinux_rodata);
> +   map_kernel_segment(pgd, __start_rodata, 
> __start_data_ro_mostly_after_init, PAGE_KERNEL, &vmlinux_rodata1);
> +   __map_kernel_segment(pgd,
> +__start_data_ro_mostly_after_init,
> +__end_data_ro_mostly_after_init,
> +PAGE_KERNEL,
> +&vmlinux_ro_mostly_after_init,
> +VM_MAP | VM_ALLOC);
> +   map_kernel_segment(pgd, __end_data_ro_mostly_after_init, 
> __init_begin, PAGE_KERNEL, &vmlinux_rodata2);
> +
> map_kernel_segment(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC,
>&vmlinux_init);
> map_kernel_segment(pgd, _data, _end, PAGE_KERNEL, &vmlinux_data);
> --
> 2.7.4
>

While it is correct that you are splitting this into three separate
segments (otherwise we would not be able to change the permissions
later without risking splitting to occur), I think this leads to
unnecessary fragmentation.

If there is demand for this feature (but you still need to make the
argument for that), I wonder if it wouldn't be sufficient, and much
more straightforward, to redefine the __ro_after_init semantics to
include the kind of subsystem registration and module init context you
are targeting, and implement some hooks to temporarily lift the
__ro_after_init r/o permission restrictions in a controlled manner.

Kees: any thoughts?

RE: [PATCH] RDMA/qedr: Fix some error handling

[Amrani, Ram]

> 'qedr_alloc_pbl_tbl()' can not return NULL.
> 
> In qedr_init_user_queue():
>  - simplify the test for the return value, no need to test for NULL
>  - propagate the error pointer if needed, otherwise 0 (success) is returned.
>This is spurious.
> 
> In init_mr_info():
>  - test the return value with IS_ERR
>  - propagate the error pointer if needed instead of an exlictit -ENOMEM.
>This is a no-op as the only error pointer that we can have here is
>already -ENOMEM
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/infiniband/hw/qedr/verbs.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/qedr/verbs.c 
> b/drivers/infiniband/hw/qedr/verbs.c
> index ef83a3f322d6..0c51657af151 100644
> --- a/drivers/infiniband/hw/qedr/verbs.c
> +++ b/drivers/infiniband/hw/qedr/verbs.c
> @@ -771,8 +771,10 @@ static inline int qedr_init_user_queue(struct 
> ib_ucontext *ib_ctx,
>   goto err0;
> 
>   q->pbl_tbl = qedr_alloc_pbl_tbl(dev, &q->pbl_info, GFP_KERNEL);
> - if (IS_ERR_OR_NULL(q->pbl_tbl))
> + if (IS_ERR(q->pbl_tbl)) {
> + rc = PTR_ERR(q->pbl_tbl);
>   goto err0;
> + }
> 
>   qedr_populate_pbls(dev, q->umem, q->pbl_tbl, &q->pbl_info);
> 
> @@ -2105,8 +2107,8 @@ static int init_mr_info(struct qedr_dev *dev, struct 
> mr_info *info,
>   goto done;
> 
>   info->pbl_table = qedr_alloc_pbl_tbl(dev, &info->pbl_info, GFP_KERNEL);
> - if (!info->pbl_table) {
> - rc = -ENOMEM;
> + if (IS_ERR(info->pbl_table)) {
> + rc = PTR_ERR(info->pbl_table);
>   goto done;
>   }
> 
> @@ -2117,7 +2119,7 @@ static int init_mr_info(struct qedr_dev *dev, struct 
> mr_info *info,
>* list and allocating another one
>*/
>   tmp = qedr_alloc_pbl_tbl(dev, &info->pbl_info, GFP_KERNEL);
> - if (!tmp) {
> + if (IS_ERR(tmp)) {
>   DP_DEBUG(dev, QEDR_MSG_MR, "Extra PBL is not allocated\n");
>   goto done;
>   }
> --
> 2.9.3


Acked-by: Ram Amrani 

Merci

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Pavel,

> Am 18.02.2017 um 23:54 schrieb Pavel Machek :
> 
> On Sat 2017-02-18 20:17:09, H. Nikolaus Schaller wrote:
>> 
>>> Am 18.02.2017 um 19:08 schrieb Pavel Machek :
>>> 
> And I agree that kernel should _not_ attempt rescaling itself, as it
> would lose precision.
 
 With an almost 1:1 mapping you won't loose precision.
>>> 
>>> How do you propose to do that?
>> 
>> something like
>> 
>> xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate 
>> Transformation Matrix"  1.00 0.00 0.00  0.00 1.00 0.00  0.00 0.00 1.00
>> 
>> but I think it is the default of X11 if you use no coordinate transformation 
>> at all.
>> And having the kernel to properly scale from ADC values to screen 
>> coordinates.
>> 
> 
> No. How do you propose doing rescaling in the kernel without loosing
> precision?

I wonder how it works with your setting

xinput --set-prop --type=float "TSC200X touchscreen" "Coordinate Transformation 
Matrix"  1.10 0.00 -0.05  0.00 1.18 -0.10  0.00 0.00 1.00

This obviously also assumes that the input events report pixel coordinates or 
you would have factors not close to 0.00 and 1.00.
It just aligns the touch with the screen, i.e. calibrates. Or your example was 
incomplete.

About loosing precision: there is already noise (jitter) in real-world devices 
so that you can't achieve subpixel precision anyways (unless your panel has a 
very low resolution). Please see my answer to Dmitry some mails ago.

BR and thanks,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Sebastian,

> Am 19.02.2017 um 00:44 schrieb Sebastian Reichel :
> 
> Hi,
> 
> On Sat, Feb 18, 2017 at 12:33:34PM +0100, H. Nikolaus Schaller wrote:
>> Hi Sebastian,
>> 
>>> Am 18.02.2017 um 04:22 schrieb Sebastian Reichel :
>>> 
>>> Hi,
>>> 
>>> On Fri, Feb 17, 2017 at 12:40:41PM -0800, Dmitry Torokhov wrote:
> AFAIK there is no mainline board using the DT except ours (and the 
> upcoming
> OMAP5-Pyra), so we shouldn't care too much. If you prefer, you can remove 
> this
> compatibility property. We don't need it for our devices.
>>> 
>>> $ cd linux.git/arch
>>> $ git grep -l tsc2004
>>> arm/boot/dts/imx6qdl-nit6xlite.dtsi
>>> arm/boot/dts/imx7d-nitrogen7.dts
>>> arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
>>> arm/boot/dts/omap4-var-som-om44.dtsi
>>> $ git grep -l tsc2005
>>> arm/boot/dts/omap3-n900.dts
>> 
>> Those are not relevant since tsc2004/5 and tsc2007 are independent drivers 
>> and don't
>> share code.
> 
> Yes, I'm aware.
> 
>> Hence the N900 is not influenced by this patch series.
>> If it has a similar issue, it should be fixed of course.
> 
> Right. I added them to see every board affect by the patch suggested
> by me in my last paragraph.

Ok!

> 
>>> $ git grep -l tsc2007
>>> arm/boot/dts/imx28-tx28.dts
>>> arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
>>> arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
>>> arm/boot/dts/imx53-tx53-x03x.dts
>>> arm/boot/dts/imx6qdl-tx6.dtsi
>>> arm/boot/dts/imx6ul-tx6ul.dtsi
>>> arm/boot/dts/omap3-gta04.dtsi
>>> sh/boards/mach-ecovec24/setup.c
>> 
>> Sorry, I was a little imprecise here, because I looked for the min/max 
>> properties.
>> Of course, the imx devices use the tsc2007 as well.
>> 
>> Maybe we should edit all these DTS and set the "ti,report-resistance" 
>> property
>> by default. Then, no user should notice a difference.
> 
> I suggest to create a patch without the report-reistance stuff and
> add it early after the merge window and see what happens. If no
> users notices anything the change is not an ABI break from kernel's
> PoV.

That looks like a good strategy.

> 
>> Is any user/maintainer of these devices following this discussion and can 
>> comment?
>> 
>>> 
 You seem to be treating DT data as something very fluid, which is wrong.
 You need to treat it as a firmware, unlikely to change once device is
 shipped. Unlike legacy platform data, the fact that DTS files are not
 present in mainline does not mean that we can ignore such users and
 change behavior at will.
 
 That said, if driver behavior is out of line from the subsystem
 expectations, we need to fix it.
 
 
> That the function name is wrong is a second issue and this double 
> negation might
> confuse a litte.
> 
> Please test on a real device if the patched driver reports pressure now 
> (unless
> ti,report-resistance is specified).
 
 I unfortunately can not test this driver as I do not have the hardware.
 So all my observations are from code and data sheets.
 
 That said, what is the values emitted as ABS_PRESSURE when finger is not
 touching the device, barely touching the device, or pressing firmly?
 It seems that between TSC2007, TSC2004, TSC2005, and ADS7846, we have
 confusion as to what is being reported.
>>> 
>>> As far as I can see all calculate Rtouch and ADS7846 reports
>>> (Rmax - Rtouch), which looks sensible.
>> 
>> I don't see where this subtraction from Rmax takes place for the tsc2007:
>> 
>> http://lxr.free-electrons.com/source/drivers/input/touchscreen/tsc2007.c#L131
> 
> sorry if I wrote this ambiguous, let me split my sentence
> 
> 1. tsc200x & ads7846 calculate Rtouch
> 2. ads7846 reports Rmax - Rtouch
> (3. tsc200x does not, it reports Rtouch instead)
> 4. ads7846 behaviour looks sensible to me

agreed.

> 
 I am adding a few more folks to the CC so we can try and soft this out.
 Sebastian, Pali, Pavel, any input here?
>>> 
>>> I think tsc200x works, since usually userspace is Xorg and I think
>>> it only cares for x/y coordinates + boolean pressure. Since
>>> no-pressure is correctly reported as 0, everything works as
>>> expected.
>> 
>> No pressure is usually treated as a special case in these drivers,
>> so reduction to "boolean" in user-space works well by accident and
>> might still hide a bug.
> 
> That's what I assumed.
> 
> Btw. how did you notice that tsc2007 sends "inverted" pressure values?
> Just in evtest or in some non-development application? (Just asking because
> the behavour obviously changes at least for that usecase)

I don't really remember when we noticed it first. Maybe it was back in tslib 
times
some years ago where setting the sensitivity threshold made problems. We then
carried along our patch for a long time in our local repo (and modified it
several times) and only started upstreaming some months ago. So it was included
but we never thought about it being something as important as the 
pre-calibration
which 

Re: [PATCH 2/2] iio: adc: stm32: add dt option to set resolution

[Jonathan Cameron]

On 15/02/17 16:55, Fabrice Gasnier wrote:
> stm32 adc supports several resolution. Add 'st,adc-res' dt optional
> property to set it. Default to maximum resolution in case it isn't set.
> 
> Signed-off-by: Fabrice Gasnier 
Implementation looks fine, just waiting on the binding review.

Thanks,

Jonathan
> ---
>  drivers/iio/adc/stm32-adc.c | 50 
> -
>  1 file changed, 49 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index 9b49a6ad..268b457a 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -60,6 +60,8 @@
>  #define STM32F4_EOC  BIT(1)
>  
>  /* STM32F4_ADC_CR1 - bit fields */
> +#define STM32F4_RES_SHIFT24
> +#define STM32F4_RES_MASK GENMASK(25, 24)
>  #define STM32F4_SCAN BIT(8)
>  #define STM32F4_EOCIEBIT(5)
>  
> @@ -141,6 +143,7 @@ struct stm32_adc_regs {
>   * @lock:spinlock
>   * @bufi:data buffer index
>   * @num_conv:expected number of scan conversions
> + * @res: data resolution (e.g. RES bitfield value)
>   * @trigger_polarity:external trigger polarity (e.g. exten)
>   * @dma_chan:dma channel
>   * @rx_buf:  dma rx buffer cpu address
> @@ -157,6 +160,7 @@ struct stm32_adc {
>   spinlock_t  lock;   /* interrupt lock */
>   unsigned intbufi;
>   unsigned intnum_conv;
> + u32 res;
>   u32 trigger_polarity;
>   struct dma_chan *dma_chan;
>   u8  *rx_buf;
> @@ -196,6 +200,11 @@ struct stm32_adc_chan_spec {
>   { IIO_VOLTAGE, 15, "in15" },
>  };
>  
> +static const unsigned int stm32f4_adc_resolutions[] = {
> + /* sorted values so the index matches RES[1:0] in STM32F4_ADC_CR1 */
> + 12, 10, 8, 6,
> +};
> +
>  /**
>   * stm32f4_sq - describe regular sequence registers
>   * - L: sequence len (register & bit field)
> @@ -302,6 +311,14 @@ static void stm32_adc_conv_irq_disable(struct stm32_adc 
> *adc)
>   stm32_adc_clr_bits(adc, STM32F4_ADC_CR1, STM32F4_EOCIE);
>  }
>  
> +static void stm32_adc_set_res(struct stm32_adc *adc)
> +{
> + u32 val = stm32_adc_readl(adc, STM32F4_ADC_CR1);
> +
> + val = (val & ~STM32F4_RES_MASK) | (adc->res << STM32F4_RES_SHIFT);
> + stm32_adc_writel(adc, STM32F4_ADC_CR1, val);
> +}
> +
>  /**
>   * stm32_adc_start_conv() - Start conversions for regular channels.
>   * @adc: stm32 adc instance
> @@ -870,11 +887,37 @@ static irqreturn_t stm32_adc_trigger_handler(int irq, 
> void *p)
>   {},
>  };
>  
> +static int stm32_adc_of_get_resolution(struct iio_dev *indio_dev)
> +{
> + struct device_node *node = indio_dev->dev.of_node;
> + struct stm32_adc *adc = iio_priv(indio_dev);
> + unsigned int i;
> + u32 res;
> +
> + if (of_property_read_u32(node, "st,adc-res", &res))
> + res = stm32f4_adc_resolutions[0];
> +
> + for (i = 0; i < ARRAY_SIZE(stm32f4_adc_resolutions); i++)
> + if (res == stm32f4_adc_resolutions[i])
> + break;
> + if (i >= ARRAY_SIZE(stm32f4_adc_resolutions)) {
> + dev_err(&indio_dev->dev, "Bad resolution: %u bits\n", res);
> + return -EINVAL;
> + }
> +
> + dev_dbg(&indio_dev->dev, "Using %u bits resolution\n", res);
> + adc->res = i;
> +
> + return 0;
> +}
> +
>  static void stm32_adc_chan_init_one(struct iio_dev *indio_dev,
>   struct iio_chan_spec *chan,
>   const struct stm32_adc_chan_spec *channel,
>   int scan_index)
>  {
> + struct stm32_adc *adc = iio_priv(indio_dev);
> +
>   chan->type = channel->type;
>   chan->channel = channel->channel;
>   chan->datasheet_name = channel->name;
> @@ -883,7 +926,7 @@ static void stm32_adc_chan_init_one(struct iio_dev 
> *indio_dev,
>   chan->info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
>   chan->info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE);
>   chan->scan_type.sign = 'u';
> - chan->scan_type.realbits = 12;
> + chan->scan_type.realbits = stm32f4_adc_resolutions[adc->res];
>   chan->scan_type.storagebits = 16;
>   chan->ext_info = stm32_adc_ext_info;
>  }
> @@ -1022,6 +1065,11 @@ static int stm32_adc_probe(struct platform_device 
> *pdev)
>   return ret;
>   }
>  
> + ret = stm32_adc_of_get_resolution(indio_dev);
> + if (ret < 0)
> + goto err_clk_disable;
> + stm32_adc_set_res(adc);
> +
>   ret = stm32_adc_chan_of_init(indio_dev);
>   if (ret < 0)
>   goto err_clk_disable;
> 

Re: [PATCH 1/2] dt-bindings: iio: stm32-adc: add option to set resolution

[Jonathan Cameron]

On 15/02/17 16:55, Fabrice Gasnier wrote:
> Add documentation for 'st,adc-res' dt optional property.
> 
> Signed-off-by: Fabrice Gasnier 
I'm happy with this, but would like to leave time for a device tree review.

Ultimately we may well want to make this a generic property and call it 
something
like adc-resolution but perhaps we need to wait until we have a few more devices
supporting setting it via device tree to figure out what the best interface is.
It would exactly be a problem to support this as a deprecated binding at that
point.

Give me a poke if we hear nothing from Rob or Mark for say another week.

Thanks,

Jonathan

> ---
>  Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt 
> b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> index 5dfc88e..45f7ff2 100644
> --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> @@ -57,6 +57,9 @@ Optional properties:
>  - dmas: Phandle to dma channel for this ADC instance.
>See ../../dma/dma.txt for details.
>  - dma-names: Must be "rx" when dmas property is being used.
> +- st,adc-res: Resolution (bits) to use for conversions. Must match device
> +  available resolutions (e.g. can be 6, 8, 10 or 12 on stm32f4). Default
> +  is maximum resolution if unset.
>  
>  Example:
>   adc: adc@40012000 {
> @@ -84,6 +87,7 @@ Example:
>   st,adc-channels = <8>;
>   dmas = <&dma2 0 0 0x400 0x0>;
>   dma-names = "rx";
> + st,adc-res = <8>;
>   };
>   ...
>   other adc child nodes follow...
> 

Re: [PATCH 4/4] iio: accel: adxl345: Add ACPI support

[Eva Rachel Retuya]

On Sun, Feb 19, 2017 at 11:01:23AM +0100, Lars-Peter Clausen wrote:
> On 02/16/2017 11:02 AM, Eva Rachel Retuya wrote:
> [...]
> > @@ -54,9 +55,17 @@ static const struct i2c_device_id adxl345_i2c_id[] = {
> >  
> >  MODULE_DEVICE_TABLE(i2c, adxl345_i2c_id);
> >  
> > +static const struct acpi_device_id adxl345_acpi_id[] = {
> > +   { "ADX0345", 0 },
> 
> Who allocated this ID? ADX does not seem to be a registered vendor ID
> (http://www.uefi.org/PNP_ACPI_Registry).
> 

Hello Lars,

Pardon the ignorance. I was not aware of this when I set it like that.
Is "ADS0345" OK? Will submit a new version with that ID.

Thanks,
Eva

> > +   { }
> > +};
> 

Re: [PATCH] ASLA: emu10k1: constify snd_emux_operators structure

[Takashi Iwai]

On Sun, 19 Feb 2017 11:21:30 +0100,
Bhumika Goyal wrote:
> 
> Declare snd_emux_operators structure as const as it is only copied into
> another structure. So, snd_emux_operators structures having this property
> can be made const.
> 
> Signed-off-by: Bhumika Goyal 

Applied now (with a typo fix in the subject :)


thanks,

Takashi

[PATCH] HID: i2c-hid: Fix error handling

[Christophe JAILLET]

According to error handling in this function, it is likely that some
resources should be freed before returning.
Replace 'return ret', with 'goto err'.

While at it, remove some spaces at the beginning of the lines to be more
consistent.


Fixes: ead0687fe304a ("HID: i2c-hid: support regulator power on/off")

Signed-off-by: Christophe JAILLET 
---
 drivers/hid/i2c-hid/i2c-hid.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index d5288f3fb5ee..1a57ac2d8524 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -1058,13 +1058,13 @@ static int i2c_hid_probe(struct i2c_client *client,
}
 
ihid->pdata.supply = devm_regulator_get(&client->dev, "vdd");
-   if (IS_ERR(ihid->pdata.supply)) {
-   ret = PTR_ERR(ihid->pdata.supply);
-   if (ret != -EPROBE_DEFER)
-   dev_err(&client->dev, "Failed to get regulator: %d\n",
-   ret);
-   return ret;
-   }
+   if (IS_ERR(ihid->pdata.supply)) {
+   ret = PTR_ERR(ihid->pdata.supply);
+   if (ret != -EPROBE_DEFER)
+   dev_err(&client->dev, "Failed to get regulator: %d\n",
+   ret);
+   goto err;
+   }
  
ret = regulator_enable(ihid->pdata.supply);
if (ret < 0) {
-- 
2.9.3

Re: [PATCH] ASLA: emu10k1: constify snd_emux_operators structure

[Takashi Sakamoto]

On Feb 19 2016 19:21, Bhumika Goyal wrote:

Declare snd_emux_operators structure as const as it is only copied into
another structure. So, snd_emux_operators structures having this property
can be made const.

Signed-off-by: Bhumika Goyal 


Reviewed-by: Takashi Sakamoto 

...The 'ASLA' reminds me of the god in Indian myth[0]. When Buddhism 
disseminated to Japan via China, the god changed its name and became the 
god in Japanese Buddhism, too.


...I'm just a kidding. The title should be fixed with 'ALSA' ;)


---
 sound/pci/emu10k1/emu10k1_callback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/emu10k1/emu10k1_callback.c 
b/sound/pci/emu10k1/emu10k1_callback.c
index d2c7ea3..aa2cc27 100644
--- a/sound/pci/emu10k1/emu10k1_callback.c
+++ b/sound/pci/emu10k1/emu10k1_callback.c
@@ -61,7 +61,7 @@ static struct snd_emux_voice *get_voice(struct snd_emux *emux,
 /*
  * set up operators
  */
-static struct snd_emux_operators emu10k1_ops = {
+static const struct snd_emux_operators emu10k1_ops = {
.owner =THIS_MODULE,
.get_voice =get_voice,
.prepare =  start_voice,


[0] https://en.wikipedia.org/wiki/Asura
[1] https://en.wikipedia.org/wiki/Asura_(Buddhism)


Regards

Takashi Sakamoto

Re: [PATCH v3 04/18] iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs

[Jonathan Cameron]

On 14/02/17 09:40, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
> battery voltage, battery charge and discharge currents, AC-in and VBUS
> voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
> 
> This adds support for most of AXP20X and AXP22X ADCs.
> 
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 
Hi Quentin,

A few bits and bobs inline.  The bigest one is that I don't think
you need to carry your struct axp_data pointer around in the iio_priv
structure as it only seems to be used in probe.

Anyhow, tidy these little bits up (quite a few are optional in the
sense that they are a matter or personal taste and I don't feel
strongly about them) and you can add

Reviewed-by: Jonathan Cameron 

A nice driver.

Jonathan
> ---
> 
> v3:
>  - moved from switch to if condition in axp20x_adc_raw and
>  axp22x_adc_raw,
>  - removed DT support as DT node has been dropped,
>- use of platform_device_id
>  - correctly defined the name of the iio device (name used to probe the
>  driver),
>  - added goto for errors in probe,
>  - added iio_map_array_unregister to the remove function,
> 
> v2:
>  - removed unused defines,
>  - changed BIT(x) to 1 << x when describing bits purpose for which 2 <<
>  x or 3 << x exists, to be consistent,
>  - changed ADC rate defines to macro formulas,
>  - reordered IIO channels, now different measures (current/voltage) of
>  the same part of the PMIC (e.g. battery), have the same IIO channel in
>  their respective IIO type. When a part of the PMIC have only one
>  measure, a number is jumped,
>  - left IIO channel mapping in DT to use iio_map structure,
>  - removed indexing of ADC internal temperature,
>  - removed unused iio_dev structure in axp20x_adc_iio,
>  - added a structure for data specific to AXP20X or AXP22X PMICs instead
>  of using an ID and an if condition when needing to separate the
>  behaviour of both,
>  - added a comment on batt_chrg_i really being on 12bits rather than
>  what the Chinese datasheets say (13 bits),
>  - corrected the offset for AXP22X PMIC temperature,
>  - set the ADC rate to a value (100Hz) shared by the AXP20X and AXP22X,
>  - created macro formulas to compute the ADC rate for each,
>  - added a condition on presence of ADC_EN2 reg before setting/resetting
>  it,
>  - switched from devm_iio_device_unregister to the non-devm function
>  because of the need for a remove function,
>  - removed some dead code,
> 
>  drivers/iio/adc/Kconfig  |  10 +
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/axp20x_adc.c | 606 
> +++
>  3 files changed, 617 insertions(+)
>  create mode 100644 drivers/iio/adc/axp20x_adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 9c8b558..ed17fe1 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -154,6 +154,16 @@ config AT91_SAMA5D2_ADC
> To compile this driver as a module, choose M here: the module will be
> called at91-sama5d2_adc.
>  
> +config AXP20X_ADC
> + tristate "X-Powers AXP20X and AXP22X ADC driver"
> + depends on MFD_AXP20X
> + help
> +   Say yes here to have support for X-Powers power management IC (PMIC)
> +   AXP20X and AXP22X ADC devices.
> +
> +   To compile this driver as a module, choose M here: the module will be
> +   called axp20x_adc.
> +
>  config AXP288_ADC
>   tristate "X-Powers AXP288 ADC driver"
>   depends on MFD_AXP20X
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index d36c4be..f5c28a5 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
>  obj-$(CONFIG_AD799X) += ad799x.o
>  obj-$(CONFIG_AT91_ADC) += at91_adc.o
>  obj-$(CONFIG_AT91_SAMA5D2_ADC) += at91-sama5d2_adc.o
> +obj-$(CONFIG_AXP20X_ADC) += axp20x_adc.o
>  obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
>  obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
>  obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
> diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
> new file mode 100644
> index 000..5ef6af8
> --- /dev/null
> +++ b/drivers/iio/adc/axp20x_adc.c
> @@ -0,0 +1,606 @@
> +/* ADC driver for AXP20X and AXP22X PMICs
> + *
> + * Copyright (c) 2016 Free Electrons NextThing Co.
> + *   Quentin Schulz 
> + *
> + * This program is free software; you can redistribute it and/or modify it 
> under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define AXP20X_ADC_EN1_MASK  GENMASK(7, 0)
> +
> +#define AXP20X_ADC_EN2_MASK  (GENMASK(3, 2) | BIT(7))
> +#define AXP22X_ADC_EN1_MASK  (GENMASK(7, 

Re: [PATCH v2 4/5] iio: trigger: add support for STM32 EXTI triggers

[Jonathan Cameron]

On 17/02/17 16:05, Fabrice Gasnier wrote:
> On 02/11/2017 11:29 AM, Jonathan Cameron wrote:
>> On 06/02/17 16:01, Fabrice Gasnier wrote:
>>> On 02/04/2017 12:39 PM, Jonathan Cameron wrote:
 On 03/02/17 19:40, Linus Walleij wrote:
> On Mon, Jan 30, 2017 at 3:33 PM, Fabrice Gasnier  
> wrote:
>
>> EXTi[0..15] gpio signal can be routed internally as trigger source for
>> ADC or DAC conversions. Configure them as interrupts to configure
>> trigger path in HW.
>>
>> Note: interrupt handler isn't required here, and corresponding interrupt
>> can be kept masked at exti controller level.
>>
>> Signed-off-by: Fabrice Gasnier 
>
> But I see nothing STM32-specific about this driver?
>
> I think we should do everone a service and just create
> drivers/iio/trigger/gpio-trigger.c
>
> I wondered before why we don't have a generic GPIO IIO trigger,
> it seems like such an intuitive and useful thing to have.
 We do, it just got renamed at some point a while back to be
 iio-trig-interrupt after it became clear that it didn't need
 to be a gpio either - just an interrupt.  Can't remember which
 part provided a non gpio interrupt pin and hence drove that
 change.  Was quite a while back!
 d4fd73bf25c3aafc891ef4443fc744d427ec1df0 specifically in 2013

 Handling of the gpio stuff should be handled in the interrupt
 description itself.

 However, it's a bit different - in that in the below it
 would be the equivalent of triggering on the unused exti
 interrupt rather than on the end of conversion.

 In this case, because of the hardware linkage we can effectively
 skip the first interrupt.

 Arguably to make this a general purpose trigger we should enable
 that interrupt if anything other than the STM devices that can
 use it in hardware are hooked on to it.

 So this is an interrupt trigger without the interrupt ever
 being visible to software.

 It might be easy enough to add that support to the generic version
 except that linking said trigger requires some register changes
 in the STM side. + there is a kicker in the various last bit
 of this patch - we need a way to find out if it's the interrupt
 we think it is (i.e. an exti interrupt)
>>>
>>> Hi Jonathan, Linus, all,
>>>
>>> First, many thanks for reviewing.
>>>
>>> In this patch-set, I choose to implement this hardware trigger line
>>> into separate driver... Thinking out loud:
>>> If I try to summarize, as you perfectly describe here before, I see
>>> two items to address: - this is pure HW line, that can either
>>> generate interrupts, and/or start conversions in HW. This may be hard
>>> to combine both, an interrupt handler to call iio_trigger_poll() from
>>> there, for generic devices, but not for stm devices (not sure if this
>>> can benefit to others?).
>> Wouldn't have thought it was that hard to do, but fair enough  + it
>> can definitely be added later if anyone cares.
> 
> Hi Jonathan,
> 
> I hope I'd give some more trials ;-).
> 
>>
>>  - there is need to do some register changes
>>> on stm device side (ADC) as well, when choosing a particular trigger
>>> (EXTI line for instance) e.g. in validate_trigger().
>>>
>>> I'm starting to wonder if this can be separate driver. Maybe this
>>> should be part of device driver (e.g. ADC), at least for the time being.
>> Sure, if it ends up easier that way then do so.  We don't really have
>>  support yet for triggered DACs anyway and as you say this could be
>> modified later - subject to the need to end up with device tree bindings
>> that make sense in that case as well.
> 
> I've just posted an RFC, to add device tree bindings for trigger.
> "iio: trigger: Add OF support and GPIO based trigger"
> I think this is a prerequisite, trying to get more generic implementation.
This is interesting.  Previously in the vast majority of cases we have
left the trigger connectivity up to userspace to define.  The only real
exception has been where we are playing nasty games to do some control and
sampling of a particular analog circuit beyond the ADC.

Will need to think on this and gather opinions on whether it makes sense to
do this.
> 
>>>
>
> Let's see what Jonathan says.


>
>> +config IIO_STM32_EXTI_TRIGGER
>> +   tristate "STM32 EXTI Trigger"
>> +   depends on (ARCH_STM32 && OF) || COMPILE_TEST
>
> config IIO_GPIO_TRIGGER
> depends on GPIOLIB
>
>> +   select STM32_EXTI
>
> Isn't the dependency actually the other way around?
>
> default STM32_EXTI makes more sense, or just put it into the
> defconfig.
>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* STM32 has up to 16 EXTI triggers on GPIOs */
>> +#define STM32_MAX_EXTI_TRIGGER 16
>
> Just don't put an

Re: [Intel-wired-lan] [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

[Neftin, Sasha]

On 2/16/2017 20:42, Bernd Faust wrote:

After an upgrade to Linux kernel v4.x the hardware timestamps of the
82579 Gigabit Ethernet Controller are different than expected.
The values that are being read are almost four times as big as before
the kernel upgrade.

The difference is that after the upgrade the driver sets the clock
frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel
confirmed that the correct frequency for this network adapter is 96MHz.

Signed-off-by: Bernd Faust 
---
  drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 7017281..8b7113d 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3511,6 +3511,12 @@ s32 e1000e_get_base_timinca(struct e1000_adapter 
*adapter, u32 *timinca)

switch (hw->mac.type) {
case e1000_pch2lan:
+   /* Stable 96MHz frequency */
+   incperiod = INCPERIOD_96MHz;
+   incvalue = INCVALUE_96MHz;
+   shift = INCVALUE_SHIFT_96MHz;
+   adapter->cc.shift = shift + INCPERIOD_SHIFT_96MHz;
+   break;
case e1000_pch_lpt:
if (er32(TSYNCRXCTL) & E1000_TSYNCRXCTL_SYSCFI) {
/* Stable 96MHz frequency */
--
2.7.4
___
Intel-wired-lan mailing list
intel-wired-...@lists.osuosl.org
http://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Hello,

e1000_pch2lan mac type corresponds to 82579LM and 82579V network 
adapters. System clock frequency indication (SYSCFI) for these devices 
supports both 25MHz and 96MHz frequency. By default TSYNCRXCTL.SYSCFI is 
set to 1 and that means 96MHz frequency is picked.


It is better to keep the current implementation as it covers all options.

Thanks,

Sasha

Re: [PATCH 1/4] iio: accel: adxl345: Use I2C regmap instead of direct I2C access

[Jonathan Cameron]

On 16/02/17 10:02, Eva Rachel Retuya wrote:
> Convert the driver to use regmap instead of I2C-specific functions. This
> is done in preparation for splitting this driver into core and
> I2C-specific code as well as introduction of SPI driver.
> 
> Signed-off-by: Eva Rachel Retuya 
One minor point inline.

Jonathan
> ---
>  drivers/iio/accel/Kconfig   |  1 +
>  drivers/iio/accel/adxl345.c | 43 +++
>  2 files changed, 32 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 2308bac..26b8614 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -9,6 +9,7 @@ config ADXL345
>   tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer Driver"
>   depends on !(INPUT_ADXL34X=y || INPUT_ADXL34X=m)
>   depends on I2C
> + select REGMAP_I2C
>   help
> Say Y here if you want to build support for the Analog Devices
> ADXL345 3-axis digital accelerometer.
> diff --git a/drivers/iio/accel/adxl345.c b/drivers/iio/accel/adxl345.c
> index c34991f..a1fdf60 100644
> --- a/drivers/iio/accel/adxl345.c
> +++ b/drivers/iio/accel/adxl345.c
> @@ -14,6 +14,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -46,9 +47,15 @@ static const int adxl345_uscale = 38300;
>  
>  struct adxl345_data {
>   struct i2c_client *client;
> + struct regmap *regmap;
>   u8 data_range;
>  };
>  
> +static const struct regmap_config adxl345_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +};
> +
>  #define ADXL345_CHANNEL(reg, axis) { \
>   .type = IIO_ACCEL,  \
>   .modified = 1,  \
> @@ -70,6 +77,7 @@ static int adxl345_read_raw(struct iio_dev *indio_dev,
>  {
>   struct adxl345_data *data = iio_priv(indio_dev);
>   int ret;
> + __le16 regval;
>  
>   switch (mask) {
>   case IIO_CHAN_INFO_RAW:
> @@ -78,11 +86,12 @@ static int adxl345_read_raw(struct iio_dev *indio_dev,
>* ADXL345_REG_DATA(X0/Y0/Z0) contain the least significant byte
>* and ADXL345_REG_DATA(X0/Y0/Z0) + 1 the most significant byte
>*/
> - ret = i2c_smbus_read_word_data(data->client, chan->address);
> + ret = regmap_bulk_read(data->regmap, chan->address, ®val,
> +sizeof(regval));
>   if (ret < 0)
>   return ret;
>  
> - *val = sign_extend32(ret, 12);
> + *val = sign_extend32(le16_to_cpu(regval), 12);
>   return IIO_VAL_INT;
>   case IIO_CHAN_INFO_SCALE:
>   *val = 0;
> @@ -104,15 +113,24 @@ static int adxl345_probe(struct i2c_client *client,
>  {
>   struct adxl345_data *data;
>   struct iio_dev *indio_dev;
> + struct regmap *regmap;
>   int ret;
> + u32 regval;
> +
> + regmap = devm_regmap_init_i2c(client, &adxl345_regmap_config);
> + if (IS_ERR(regmap)) {
> + dev_err(&client->dev, "Error initializing regmap: %d\n",
> + (int)PTR_ERR(regmap));
> + return PTR_ERR(regmap);
> + }
>  
> - ret = i2c_smbus_read_byte_data(client, ADXL345_REG_DEVID);
> + ret = regmap_read(regmap, ADXL345_REG_DEVID, ®val);
>   if (ret < 0) {
>   dev_err(&client->dev, "Error reading device ID: %d\n", ret);
>   return ret;
>   }
>  
> - if (ret != ADXL345_DEVID) {
> + if (regval != ADXL345_DEVID) {
>   dev_err(&client->dev, "Invalid device ID: %d\n", ret);
>   return -ENODEV;
>   }
> @@ -124,11 +142,12 @@ static int adxl345_probe(struct i2c_client *client,
>   data = iio_priv(indio_dev);
>   i2c_set_clientdata(client, indio_dev);
>   data->client = client;
Leaving client behind means that you have a driver that is still implicitly
associated with i2c in more places than it should be.  I'd normally expect
to either see all the access to the underlying dev done through a local
copy of the client's device pointer, or through the device pointer that
can be retrieved form the regmap.

> + data->regmap = regmap;
>   /* Enable full-resolution mode */
>   data->data_range = ADXL345_DATA_FORMAT_FULL_RES;
>  
> - ret = i2c_smbus_write_byte_data(data->client, ADXL345_REG_DATA_FORMAT,
> - data->data_range);
> + ret = regmap_write(data->regmap, ADXL345_REG_DATA_FORMAT,
> +data->data_range);
>   if (ret < 0) {
>   dev_err(&client->dev, "Failed to set data range: %d\n", ret);
>   return ret;
> @@ -142,8 +161,8 @@ static int adxl345_probe(struct i2c_client *client,
>   indio_dev->num_channels = ARRAY_SIZE(adxl345_channels);
>  
>   /* Enable measurement mode */
> - ret = i2c_smbus_write_byte_data(data-

[PATCH] phy: qcom-usb-hsic: Fix error handling

[Christophe JAILLET]

According to error handling in this function, it is likely that going to
'err_ulpi' was expected here.

Fixes:  605b8652f7f0 ("phy: Add support for Qualcomm's USB HSIC phy")

Signed-off-by: Christophe JAILLET 
---
 drivers/phy/phy-qcom-usb-hsic.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-qcom-usb-hsic.c b/drivers/phy/phy-qcom-usb-hsic.c
index 47690f9945b9..b466ccb045fc 100644
--- a/drivers/phy/phy-qcom-usb-hsic.c
+++ b/drivers/phy/phy-qcom-usb-hsic.c
@@ -58,8 +58,10 @@ static int qcom_usb_hsic_phy_power_on(struct phy *phy)
 
/* Configure pins for HSIC functionality */
pins_default = pinctrl_lookup_state(uphy->pctl, PINCTRL_STATE_DEFAULT);
-   if (IS_ERR(pins_default))
-   return PTR_ERR(pins_default);
+   if (IS_ERR(pins_default)) {
+   ret = PTR_ERR(pins_default);
+   goto err_ulpi;
+   }
 
ret = pinctrl_select_state(uphy->pctl, pins_default);
if (ret)
-- 
2.9.3

[PATCH] saa7134: constify nxt200x_config structures

[Bhumika Goyal]

Declare nxt200x_config structures as const as they are only passed as
an argument to the function dvb_attach. dvb_attach calls its first
argument on the rest of its arguments. The first argument of
dvb_attach in the changed cases is nxt200x_attach and the parameter of
this function to which the object references are passed is of type
const. So, nxt200x_config structures having this property can be made
const.

File size before:
   textdata bss dec hex filename
  213203776  16   251126218 saa7134/saa7134-dvb.o

File size after:
   textdata bss dec hex filename
  213843744  16   251446238 saa7134/saa7134-dvb.o

Signed-off-by: Bhumika Goyal 
---
 drivers/media/pci/saa7134/saa7134-dvb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/saa7134/saa7134-dvb.c 
b/drivers/media/pci/saa7134/saa7134-dvb.c
index 598b8bb..36156f1 100644
--- a/drivers/media/pci/saa7134/saa7134-dvb.c
+++ b/drivers/media/pci/saa7134/saa7134-dvb.c
@@ -1046,11 +1046,11 @@ static int md8800_set_high_voltage2(struct dvb_frontend 
*fe, long arg)
  * nxt200x based ATSC cards, helper functions
  */
 
-static struct nxt200x_config avertvhda180 = {
+static const struct nxt200x_config avertvhda180 = {
.demod_address= 0x0a,
 };
 
-static struct nxt200x_config kworldatsc110 = {
+static const struct nxt200x_config kworldatsc110 = {
.demod_address= 0x0a,
 };
 
-- 
1.9.1

[PATCH] b2c2: constify nxt200x_config structure

[Bhumika Goyal]

Declare nxt200x_config structure as const as it is only passed as
an argument to the function dvb_attach. dvb_attach calls its first
argument on the rest of its arguments. The first argument of
dvb_attach in the changed case is nxt200x_attach and the parameter of
this function to which the object reference is passed is of type
const. So, nxt200x_config structures having this property can be made 
const.

File size before:
   textdata bss dec hex filename
   7566 568   081341fc6 common/b2c2/flexcop-fe-tuner.o

File size after:
   textdata bss dec hex filename
   7582 536   081181fb6 common/b2c2/flexcop-fe-tuner.o

Signed-off-by: Bhumika Goyal 
---
 drivers/media/common/b2c2/flexcop-fe-tuner.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/common/b2c2/flexcop-fe-tuner.c 
b/drivers/media/common/b2c2/flexcop-fe-tuner.c
index f595640..e846a97 100644
--- a/drivers/media/common/b2c2/flexcop-fe-tuner.c
+++ b/drivers/media/common/b2c2/flexcop-fe-tuner.c
@@ -474,7 +474,7 @@ static int airstar_atsc1_attach(struct flexcop_device *fc,
 
 /* AirStar ATSC 2nd generation */
 #if FE_SUPPORTED(NXT200X) && FE_SUPPORTED(PLL)
-static struct nxt200x_config samsung_tbmv_config = {
+static const struct nxt200x_config samsung_tbmv_config = {
.demod_address = 0x0a,
 };
 
-- 
1.9.1

Re: [PATCH 2/4] iio: accel: adxl345: Split driver into core and I2C

[Jonathan Cameron]

On 16/02/17 10:02, Eva Rachel Retuya wrote:
> Move I2C-specific code into its own file and rely on regmap to access
> registers. The core code provides access to x, y, z and scale readings.
> 
> Signed-off-by: Eva Rachel Retuya 
A few minor comment inline.  This unwound the comment about client->dev
in the previous patch, but I'd prefer to see it done there as then the
changes in here will be easier to see (with move detection hopefully working!)

Jonathan
> ---
>  drivers/iio/accel/Kconfig|   8 +-
>  drivers/iio/accel/Makefile   |   3 +-
>  drivers/iio/accel/adxl345.c  | 213 
> ---
>  drivers/iio/accel/adxl345.h  |  18 
>  drivers/iio/accel/adxl345_core.c | 182 +
>  drivers/iio/accel/adxl345_i2c.c  |  70 +
This is a case where allowing git to notice the moves would have lead
to easier to read patches (unless this was sufficiently complex that git
couldn't follow it ;)
>  6 files changed, 278 insertions(+), 216 deletions(-)
>  delete mode 100644 drivers/iio/accel/adxl345.c
>  create mode 100644 drivers/iio/accel/adxl345.h
>  create mode 100644 drivers/iio/accel/adxl345_core.c
>  create mode 100644 drivers/iio/accel/adxl345_i2c.c
> 
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 26b8614..5bdd87f 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -6,16 +6,20 @@
>  menu "Accelerometers"
>  
>  config ADXL345
> - tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer Driver"
> + tristate
> +
> +config ADXL345_I2C
> + tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer I2C 
> Driver"
>   depends on !(INPUT_ADXL34X=y || INPUT_ADXL34X=m)
>   depends on I2C
> + select ADXL345
>   select REGMAP_I2C
>   help
> Say Y here if you want to build support for the Analog Devices
> ADXL345 3-axis digital accelerometer.
>  
> To compile this driver as a module, choose M here: the
> -   module will be called adxl345.
> +   module will be called adxl345_i2c.
There are a couple of ways to do this.  I personally kind of prefer the
way the bmc150 does it as it gives a cleaner set of options in Kconfig.

Look at the various ways it is done and if you still prefer this one then
fair enough (it's how we always used to do it ;)
>  
>  config BMA180
>   tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 618488d..3f4a6d6 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -3,7 +3,8 @@
>  #
>  
>  # When adding new entries keep the list in alphabetical order
> -obj-$(CONFIG_ADXL345) += adxl345.o
> +obj-$(CONFIG_ADXL345) += adxl345_core.o
> +obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
>  obj-$(CONFIG_BMA180) += bma180.o
>  obj-$(CONFIG_BMA220) += bma220_spi.o
>  obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
> diff --git a/drivers/iio/accel/adxl345.c b/drivers/iio/accel/adxl345.c
> deleted file mode 100644
> index a1fdf60..000
> --- a/drivers/iio/accel/adxl345.c
> +++ /dev/null
> @@ -1,213 +0,0 @@
> -/*
> - * ADXL345 3-Axis Digital Accelerometer
> - *
> - * Copyright (c) 2017 Eva Rachel Retuya 
> - *
> - * This file is subject to the terms and conditions of version 2 of
> - * the GNU General Public License. See the file COPYING in the main
> - * directory of this archive for more details.
> - *
> - * IIO driver for ADXL345
> - * 7-bit I2C slave address: 0x1D (ALT ADDRESS pin tied to VDDIO) or
> - * 0x53 (ALT ADDRESS pin grounded)
> - */
> -
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -
> -#define ADXL345_REG_DEVID0x00
> -#define ADXL345_REG_POWER_CTL0x2D
> -#define ADXL345_REG_DATA_FORMAT  0x31
> -#define ADXL345_REG_DATAX0   0x32
> -#define ADXL345_REG_DATAY0   0x34
> -#define ADXL345_REG_DATAZ0   0x36
> -
> -#define ADXL345_POWER_CTL_MEASUREBIT(3)
> -#define ADXL345_POWER_CTL_STANDBY0x00
> -
> -#define ADXL345_DATA_FORMAT_FULL_RES BIT(3) /* Up to 13-bits resolution */
> -#define ADXL345_DATA_FORMAT_2G   0
> -#define ADXL345_DATA_FORMAT_4G   1
> -#define ADXL345_DATA_FORMAT_8G   2
> -#define ADXL345_DATA_FORMAT_16G  3
> -
> -#define ADXL345_DEVID0xE5
> -
> -/*
> - * In full-resolution mode, scale factor is maintained at ~4 mg/LSB
> - * in all g ranges.
> - *
> - * At +/- 16g with 13-bit resolution, scale is computed as:
> - * (16 + 16) * 9.81 / (2^13 - 1) = 0.0383
> - */
> -static const int adxl345_uscale = 38300;
> -
> -struct adxl345_data {
> - struct i2c_client *client;
> - struct regmap *regmap;
> - u8 data_range;
> -};
> -
> -static const struct regmap_config adxl345_regmap_config = {
> - .reg_bits = 8,
> - .val_bits = 8,
> -};
> -
> -#define ADXL345_CHANNEL(reg, axis) {   

Re: [PATCH 3/4] iio: accel: adxl345: Add SPI support

[Jonathan Cameron]

On 16/02/17 10:02, Eva Rachel Retuya wrote:
> Add SPI driver for initializing spi regmap for the adxl345 core driver.
> The driver supports the same functionality as I2C namely the x, y, z and
> scale readings.
> 
> Signed-off-by: Eva Rachel Retuya 
Looks nice.  I didn't know about the readmask stuff in regmap so 
always good to see something new.

Jonathan
> ---
>  drivers/iio/accel/Kconfig   | 13 +++
>  drivers/iio/accel/Makefile  |  1 +
>  drivers/iio/accel/adxl345_spi.c | 75 
> +
>  3 files changed, 89 insertions(+)
>  create mode 100644 drivers/iio/accel/adxl345_spi.c
> 
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 5bdd87f..d474fed 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -21,6 +21,19 @@ config ADXL345_I2C
> To compile this driver as a module, choose M here: the
> module will be called adxl345_i2c.
>  
> +config ADXL345_SPI
> + tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer SPI 
> Driver"
> + depends on !(INPUT_ADXL34X=y || INPUT_ADXL34X=m)
> + depends on SPI
> + select ADXL345
> + select REGMAP_SPI
> + help
> +   Say Y here if you want to build support for the Analog Devices
> +   ADXL345 3-axis digital accelerometer.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called adxl345_spi.
> +
>  config BMA180
>   tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
>   depends on I2C
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 3f4a6d6..31fba19 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -5,6 +5,7 @@
>  # When adding new entries keep the list in alphabetical order
>  obj-$(CONFIG_ADXL345) += adxl345_core.o
>  obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
> +obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
>  obj-$(CONFIG_BMA180) += bma180.o
>  obj-$(CONFIG_BMA220) += bma220_spi.o
>  obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
> diff --git a/drivers/iio/accel/adxl345_spi.c b/drivers/iio/accel/adxl345_spi.c
> new file mode 100644
> index 000..5fcd1fa
> --- /dev/null
> +++ b/drivers/iio/accel/adxl345_spi.c
> @@ -0,0 +1,75 @@
> +/*
> + * ADXL345 3-Axis Digital Accelerometer
> + *
> + * Copyright (c) 2017 Eva Rachel Retuya 
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License. See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * SPI driver for ADXL345
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "adxl345.h"
> +
> +#define ADXL345_MAX_SPI_FREQ_HZ  500
> +
> +static const struct regmap_config adxl345_spi_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +  /* Setting bits 7 and 6 enables multiple-byte read */
> + .read_flag_mask = BIT(7) | BIT(6),
Nice. I didn't know about that one ;)
> +};
> +
> +static int adxl345_spi_probe(struct spi_device *spi)
> +{
> + struct regmap *regmap;
> + const struct spi_device_id *id = spi_get_device_id(spi);
> +
> + /* Bail out if max_speed_hz exceeds 5 MHz */
> + if (spi->max_speed_hz > ADXL345_MAX_SPI_FREQ_HZ) {
> + dev_err(&spi->dev, "SPI CLK, %d Hz exceeds 5 MHz\n",
> + spi->max_speed_hz);
> + return -EINVAL;
> + }
> +
> + regmap = devm_regmap_init_spi(spi, &adxl345_spi_regmap_config);
> + if (IS_ERR(regmap)) {
> + dev_err(&spi->dev, "Error initializing spi regmap: %d\n",
> + (int)PTR_ERR(regmap));
> + return PTR_ERR(regmap);
> + }
> +
> + return adxl345_common_probe(&spi->dev, regmap, id->name);
> +}
> +
> +static int adxl345_spi_remove(struct spi_device *spi)
> +{
> + return adxl345_common_remove(&spi->dev);
> +}
> +
> +static const struct spi_device_id adxl345_spi_id[] = {
> + { "adxl345", 0 },
> + { }
> +};
> +
> +MODULE_DEVICE_TABLE(spi, adxl345_spi_id);
> +
> +static struct spi_driver adxl345_spi_driver = {
> + .driver = {
> + .name   = "adxl345_spi",
> + },
> + .probe  = adxl345_spi_probe,
> + .remove = adxl345_spi_remove,
> + .id_table   = adxl345_spi_id,
> +};
> +
> +module_spi_driver(adxl345_spi_driver);
> +
> +MODULE_AUTHOR("Eva Rachel Retuya ");
> +MODULE_DESCRIPTION("ADXL345 3-Axis Digital Accelerometer SPI driver");
> +MODULE_LICENSE("GPL v2");
> 

[PATCH] soc: mediatek: PMIC wrap: Fix error handling

[Christophe JAILLET]

According to error handling in this function, it is likely that going to
'err_out2' was expected here.

Signed-off-by: Christophe JAILLET 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index a5f10936fb9c..285b434449a6 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -1200,7 +1200,8 @@ static int pwrap_probe(struct platform_device *pdev)
 
if (!(pwrap_readl(wrp, PWRAP_WACS2_RDATA) & PWRAP_STATE_INIT_DONE0)) {
dev_dbg(wrp->dev, "initialization isn't finished\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto err_out2;
}
 
/* Initialize watchdog, may not be done by the bootloader */
@@ -1220,8 +1221,10 @@ static int pwrap_probe(struct platform_device *pdev)
goto err_out2;
 
wrp->regmap = devm_regmap_init(wrp->dev, NULL, wrp, 
&pwrap_regmap_config);
-   if (IS_ERR(wrp->regmap))
-   return PTR_ERR(wrp->regmap);
+   if (IS_ERR(wrp->regmap)) {
+   ret = PTR_ERR(wrp->regmap);
+   goto err_out2;
+   }
 
ret = of_platform_populate(np, NULL, NULL, wrp->dev);
if (ret) {
-- 
2.9.3

[PATCH] spi: spi-fsl-dspi: Fix error handling

[Christophe JAILLET]

According to error handling in this function, it is likely that going to
'out_master_put' was expected here.

Signed-off-by: Christophe JAILLET 
---
 drivers/spi/spi-fsl-dspi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 14c8e7ce1913..15201645bdc4 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1002,7 +1002,8 @@ static int dspi_probe(struct platform_device *pdev)
if (IS_ERR(dspi->regmap)) {
dev_err(&pdev->dev, "failed to init regmap: %ld\n",
PTR_ERR(dspi->regmap));
-   return PTR_ERR(dspi->regmap);
+   ret = PTR_ERR(dspi->regmap);
+   goto out_master_put;
}
 
dspi_init(dspi);
-- 
2.9.3

Re: [PATCH V3 0/3] Numabalancing preserve write fix

[Aneesh Kumar K.V]

I am not sure whether we want to merge this debug patch. This will help
us in identifying wrong pte_wrprotect usage in the kernel.

>From a0fb302fd204159a1327b67decb8f14ffa21 Mon Sep 17 00:00:00 2001
From: "Aneesh Kumar K.V" 
Date: Sat, 18 Feb 2017 10:39:47 +0530
Subject: [PATCH] powerpc/autonuma: Add debug check for wrong writable pte
 check

With ppc64, protnone ptes don't use _PAGE_WRITE bit for savedwrite. Hence
we need to make sure we don't do pte_write* functions on protnone ptes.
Add debug check to catch wrong usage.

This should be only used for debugging and can give wrong results w.r.t change
bit on radix. Even on hash with kvm we will insert the page table entry in
guest hash page table with write bit set, even if the pte is marked protnone.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/book3s/64/pgtable.h | 130 +--
 1 file changed, 85 insertions(+), 45 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index d87bee85fc44..1c99deac3966 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -341,10 +341,36 @@ static inline int __ptep_test_and_clear_young(struct 
mm_struct *mm,
__r;\
 })
 
+#undef SAVED_WRITE_DEBUG
+#ifdef CONFIG_NUMA_BALANCING
+static inline int pte_protnone(pte_t pte)
+{
+   /*
+* We want to catch wrong usage of pte_write w.r.t protnone ptes.
+* The way we do that is to make saved write as _PAGE_WRITE for hash
+* translation mode. This only will work with hash translation mode.
+*/
+#ifdef SAVED_WRITE_DEBUG
+   if (!radix_enabled())
+   return (pte_raw(pte) & cpu_to_be64(_PAGE_PRESENT | 
_PAGE_PRIVILEGED)) ==
+   cpu_to_be64(_PAGE_PRESENT | _PAGE_PRIVILEGED);
+#endif
+   return (pte_raw(pte) & cpu_to_be64(_PAGE_PRESENT | _PAGE_PTE | 
_PAGE_RWX)) ==
+   cpu_to_be64(_PAGE_PRESENT | _PAGE_PTE);
+}
+#endif
+
 #define __HAVE_ARCH_PTEP_SET_WRPROTECT
 static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr,
  pte_t *ptep)
 {
+#ifdef SAVED_WRITE_DEBUG
+   /*
+* Cannot use this with protnone pte, For protnone, writes
+* will be marked via savedwrite bit.
+*/
+   VM_WARN_ON(pte_protnone(*ptep));
+#endif
if ((pte_raw(*ptep) & cpu_to_be64(_PAGE_WRITE)) == 0)
return;
 
@@ -430,51 +456,6 @@ static inline pte_t pte_clear_soft_dirty(pte_t pte)
 }
 #endif /* CONFIG_HAVE_ARCH_SOFT_DIRTY */
 
-#ifdef CONFIG_NUMA_BALANCING
-static inline int pte_protnone(pte_t pte)
-{
-   return (pte_raw(pte) & cpu_to_be64(_PAGE_PRESENT | _PAGE_PTE | 
_PAGE_RWX)) ==
-   cpu_to_be64(_PAGE_PRESENT | _PAGE_PTE);
-}
-
-#define pte_mk_savedwrite pte_mk_savedwrite
-static inline pte_t pte_mk_savedwrite(pte_t pte)
-{
-   /*
-* Used by Autonuma subsystem to preserve the write bit
-* while marking the pte PROT_NONE. Only allow this
-* on PROT_NONE pte
-*/
-   VM_BUG_ON((pte_raw(pte) & cpu_to_be64(_PAGE_PRESENT | _PAGE_RWX | 
_PAGE_PRIVILEGED)) !=
- cpu_to_be64(_PAGE_PRESENT | _PAGE_PRIVILEGED));
-   return __pte(pte_val(pte) & ~_PAGE_PRIVILEGED);
-}
-
-#define pte_clear_savedwrite pte_clear_savedwrite
-static inline pte_t pte_clear_savedwrite(pte_t pte)
-{
-   /*
-* Used by KSM subsystem to make a protnone pte readonly.
-*/
-   VM_BUG_ON(!pte_protnone(pte));
-   return __pte(pte_val(pte) | _PAGE_PRIVILEGED);
-}
-
-#define pte_savedwrite pte_savedwrite
-static inline bool pte_savedwrite(pte_t pte)
-{
-   /*
-* Saved write ptes are prot none ptes that doesn't have
-* privileged bit sit. We mark prot none as one which has
-* present and pviliged bit set and RWX cleared. To mark
-* protnone which used to have _PAGE_WRITE set we clear
-* the privileged bit.
-*/
-   VM_BUG_ON(!pte_protnone(pte));
-   return !(pte_raw(pte) & cpu_to_be64(_PAGE_RWX | _PAGE_PRIVILEGED));
-}
-#endif /* CONFIG_NUMA_BALANCING */
-
 static inline int pte_present(pte_t pte)
 {
return !!(pte_raw(pte) & cpu_to_be64(_PAGE_PRESENT));
@@ -500,6 +481,14 @@ static inline unsigned long pte_pfn(pte_t pte)
 /* Generic modifiers for PTE bits */
 static inline pte_t pte_wrprotect(pte_t pte)
 {
+
+#ifdef SAVED_WRITE_DEBUG
+   /*
+* Cannot use this with protnone pte, For protnone, writes
+* will be marked via savedwrite bit.
+*/
+   VM_WARN_ON(pte_protnone(pte));
+#endif
return __pte(pte_val(pte) & ~_PAGE_WRITE);
 }
 
@@ -552,6 +541,57 @@ static inline bool pte_user(pte_t pte)
return !(pte_raw(pte) & cpu_to_be64(_PAGE_PRIVILEGED));
 }
 
+#ifdef CONFIG_NUMA_BALANCING
+#define pte_mk_savedwrite pte_mk_savedwrite
+static inline 

[PATCH] Add model data for Dell Precision 3510 trackpad.

[John L. Preston]

---
 drivers/input/mouse/alps.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 328edc8c8786..c0a4edefe54d 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -139,6 +139,7 @@ static const struct alps_model_info alps_model_data[] = {
{ { 0x52, 0x01, 0x14 }, 0x00, { ALPS_PROTO_V2, 0xff, 0xff,
ALPS_PASS | ALPS_DUALPOINT | ALPS_PS2_INTERLEAVED } },  
/* Toshiba Tecra A11-11L */
{ { 0x73, 0x02, 0x64 }, 0x8a, { ALPS_PROTO_V4, 0x8f, 0x8f, 0 } },
+   { { 0x73, 0x03, 0x28 }, 0x13, { ALPS_PROTO_V8, 0x18, 0x18, 0 } },   
/* Dell Precision 3510 */
 };
 
 static const struct alps_protocol_info alps_v3_protocol_data = {
-- 
2.11.1

Re: Crosstool/kbuild-all toolchain updates

[Fengguang Wu]

Hi Stafford,

On Wed, Feb 01, 2017 at 07:44:38AM +0900, Stafford Horne wrote:

Hi Fengguang/All,

I am working as the OpenRISC linux kernel maintainer.  Currently in
linux-next our patches are causing kbuild test robot to fail.

This is because the patches are taking advantage of 2 'new' (2 year old)
instrucions (l.swa/l.lwa) and the build robots, as far as I can tell,
use the 'make.cross' [0] build script from lkp-tests.git.  These point
to the crosstools [1] toolchains maintained by Tony.

I sent a mail to Tony who maintains the crosstools but I didn't get a
reply and it seems he is not longer working on them [1].

I think our options are:

 1. Update 'make.cross' to point somewhere else for openrisc
 2. Update and maintain crosstools

For 1. its trvial but, maybe not the best solution.


It's a valuable patch, thank you!


For 2. I created new crosstool builds for openrisc [3]. The way the
crosstools are maintained is via a patches.tar file and it seem a custom
buildall script.  I dont see the source for that custom script anywhere.

I am thinking I could help to update and 'opensource' the crosstool
build scripts to make it easier for everyone to update toolchains by
sending patches.

But, I would need access to crosstool on kernel.org and an OK from
everyone.

Any opinions? Questions?


An uptodate crosstool and reasonable active maintainer would be very
welcome. I'll sure be a heavy user. In the past year when crosstool is
not updated to gcc-6, we've resorted to using debian packages for some
ARCHs and building our own cross compliers for the other ARCHs. The
latter are based on Segher's buildall tools (CCed). The private builds
may work for us in short term, however is obvious not a satisfactory
solution.

Thanks,
Fengguang

Re: [PATCH] tools/vm: Fix possible resource leak in page_owner_sort.c

[walter harms]

Am 19.02.2017 06:49, schrieb Saurabh Badhwar:
> Fix possible resource leak in tools/vm/page_owner_sort.c
> Signed-off-by: Saurabh Badhwar 
> ---
>  tools/vm/page_owner_sort.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/vm/page_owner_sort.c b/tools/vm/page_owner_sort.c
> index f1c055f..8346261 100644
> --- a/tools/vm/page_owner_sort.c
> +++ b/tools/vm/page_owner_sort.c
> @@ -110,6 +110,8 @@ int main(int argc, char **argv)
>   buf = malloc(BUF_SIZE);
>   if (!list || !buf) {
>   printf("Out of memory\n");
> + fclose(fin);
> + fclose(fout);
>   exit(1);
>   }

the is no resource leak as file pointer get closed on exit
ntl it is ok the close them
but error messages should go to stderr an be more verbose.

just my 2 cents,
 wh
>  
> @@ -144,6 +146,7 @@ int main(int argc, char **argv)
>  
>   for (i = 0; i < count; i++)
>   fprintf(fout, "%d times:\n%s\n", list2[i].num, list2[i].txt);
> -
> + 
> + fclose(fout);
>   return 0;
>  }

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

[Jan Kiszka]

On 2017-02-18 13:48, Ard Biesheuvel wrote:
> On 16 February 2017 at 07:29, Jan Kiszka  wrote:
>> On 2017-02-16 04:00, Kweh, Hock Leong wrote:
 -Original Message-
 From: Jan Kiszka [mailto:jan.kis...@siemens.com]
 Sent: Thursday, February 16, 2017 3:00 AM
 To: Andy Shevchenko 
 Cc: Matt Fleming ; Ard Biesheuvel
 ; linux-...@vger.kernel.org; Linux Kernel 
 Mailing
 List ; Borislav Petkov ; 
 Kweh,
 Hock Leong ; Bryan O'Donoghue
 
 Subject: Re: [PATCH 0/2] efi: Enhance capsule loader to support signed 
 Quark
 images

 On 2017-02-15 19:50, Jan Kiszka wrote:
> On 2017-02-15 19:46, Andy Shevchenko wrote:
>> On Wed, Feb 15, 2017 at 8:14 PM, Jan Kiszka 
 wrote:
>>> See patch 2 for the background.
>>>
>>> Series has been tested on the Galileo Gen2, to exclude regressions,
>>> with a firmware.cap without security header and the SIMATIC IOT2040
>>> which requires the header because of its mandatory secure boot.
>>
>> Briefly looking to the code it looks like a real hack.
>> Sorry, but it would be carefully (re-)designed.
>
> The interface that the firmware provides us? That should have been
> done differently, I agree, but I'm not too much into those firmware
> details, specifically when it comes to signatures.
>
> The Linux code was designed around that suboptimal situation. If there
> are better ideas, I'm all ears.
>

 Expanding CC's as requested by Andy.

 Jan

>>>
>>> Hi Jan,
>>>
>>> While I upstreaming the capsule loader patches, I did work with maintainer
>>> Matt and look into this security header created for Quark. Eventually both
>>> of us agreed that this will not be upstream to mainline as it is really a 
>>> Quark
>>> specific implementation.
>>
>> This is ... [swallowing down a lengthy rant about Quark upstreaming]
>> unfortunate given that Intel hands out firmware and BSPs to their
>> customers without further explanations on this "minor detail".
>>
>> I have no idea what other integrators of the X102x did with that, but my
>> customer has now thousands and thousands of devices in the field with
>> firmware that works exactly this way. Only for that feature, we will now
>> have to provide a non-upstream kernel in order to keep the installed
>> devices updatable. Or create and maintain a different mechanism. Beautiful.
>>
> 
> OK, so you shipped thousands and thousands of devices with mainline
> kernels and never tested the capsule update feature, which now turns
> out to require modifications to support the non-UEFI compliant
> firmware on these devices.

We are shipping an open platform. The users can download a reference
image with Yocto-Linux that comes with a Yocto kernel plus some enabling
patches. One of them is currently a forward-port of the original Intel
capsule loader driver that does a similar thing like these patches and
therefore works fine (of course firmware update has been tested before
the release).

But in order to overcome the dependencies on Yocto kernels as well our
own patch queue, we are in the process of upstreaming necessary changes
(and upstream cleanups as well, some are already merged). In the end,
our users should have the possibility to chose mainline or Yocto or some
other kernel flavour without having the need for additional BSP patches.
That will ensure long-term support for the hardware, software-wise.
Users already asked us if they will eventually be stuck with a patch
queue and, thus, an outdated kernel like it is a sad standard in this
domain. But that is not our plan.

Yes, in an ideal world, this discussion had happened earlier and
prevented at least our deployment of the non-standard firmware. But the
world is not always working ideally.

> 
> I'm sorry, but that puts it firmly in the 'not our problem' category,
> simply because I refuse to believe that you would seriously consider
> performing this kind of firmware update on that many devices in the
> field if you never tested it in development.

I would recommend reading my email completely (see below) to understand
who I was targeting.

> 
> So while I fully agree that
> a) it is quite unfortunate that Intel, which has such a dominant
> presence in all aspects of UEFI and PI standardization, ships a
> non-compliant BSP, and
> b) it is useful to be able to sign capsules,
> I think we should push back on random, unstandardized signature headers.
> 
> The argument that Quark is the only working implementation of capsule
> updates, and so we should support it, does not hold. First of all,
> arm64 servers are shipping with working capsule update based on the
> current kernel implementation, but what is currently shipping is not
> really the point for mainline imo, but what is intended to be shipped
> with the next kernel release.
> 
> I would not object strongly to having conditionally compiled code in
> mainline that adds support for this, but bod

Re: [PATCH] Add model data for Dell Precision 3510 trackpad.

[Pali Rohár]

On Sunday 19 February 2017 13:16:34 John L. Preston wrote:
> ---
>  drivers/input/mouse/alps.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index 328edc8c8786..c0a4edefe54d 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -139,6 +139,7 @@ static const struct alps_model_info alps_model_data[] = {
>   { { 0x52, 0x01, 0x14 }, 0x00, { ALPS_PROTO_V2, 0xff, 0xff,
>   ALPS_PASS | ALPS_DUALPOINT | ALPS_PS2_INTERLEAVED } },  
> /* Toshiba Tecra A11-11L */
>   { { 0x73, 0x02, 0x64 }, 0x8a, { ALPS_PROTO_V4, 0x8f, 0x8f, 0 } },
> + { { 0x73, 0x03, 0x28 }, 0x13, { ALPS_PROTO_V8, 0x18, 0x18, 0 } },   
> /* Dell Precision 3510 */
>  };
>  
>  static const struct alps_protocol_info alps_v3_protocol_data = {

Hi John! This is not a correct place do add new proto data. I already
proposed reducing this table to just for PROTO_V2, but Dmitry was not
happy about it.

Anyway, look at function alps_identify() where is detection for ALPS_V8:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/mouse/alps.c?h=v4.10-rc8#n2829

V8 is already detected when e7 is (0x73, 0x03, 0x28) and ec[1] is 0x01.
What are your ec data? Probably ec[1] is not 0x01 as otherwise it should
be already detected.

Btw, from where you got your proto data in this patch?

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [PATCH -v1.1] x86: Optimize clear_page()

[Borislav Petkov]

On Wed, Feb 15, 2017 at 12:19:27PM +0100, Borislav Petkov wrote:
> Here's a fixed version of the breakage the 0day bot reported:
> 
> ---
> From: Borislav Petkov 
> Date: Thu, 9 Feb 2017 01:34:49 +0100
> Subject: [PATCH -v1.1] x86: Optimize clear_page()
> 
> Currently, we CALL clear_page() which then JMPs to the proper function
> chosen by the alternatives.
> 
> What we should do instead is CALL the proper function directly. (This
> was something Ingo suggested a while ago). So let's do that.
> 
> Measuring our favourite kernel build workload shows that there are no
> significant changes in performance.

...

> Signed-off-by: Borislav Petkov 
> [ Forgot to add clobbers. ]
> Reported-by: kernel test robot 

Fengguang just confirmed too:

"Yes it works fine for 300 boots.

Tested-by: Fengguang Wu "

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

[Borislav Petkov]

On Sun, Feb 19, 2017 at 09:06:51AM +0800, Fengguang Wu wrote:
> Yes if we add it as a line below the branch URL, it could be a time saver.

Right.

> Since it's hard to teach ALL people about the rule, it'd be best if we
> can work w/o any rules -- unless you want to be accurate&helpful or to
> customize test behaviors.
> 
> Since we already tested the original patch/commit (hence the report),
> we should know where the fixup should be applied to. And it'd be
> reasonably easy to tell whether the fix is incremental or a
> replacement -- just try git-am onto the original commit first, if
> failed, continue to try the parent commit. For old bugs the fix could
> be against linus/master or linux-next/master, which could be tried too.

Makes sense.

> Yes, that'd be most convenient. In general the email interface could
> be something like this:
> 
># "key: value" fields; if you Re: to an earlier bug report, they can 
> be auto retrieved
>compiler: gcc-6 # optional
>base-commit: v4.10-rc8 # the robot knows kernel commits from hundreds 
> of public git trees
>---
>the patch
>---
>attach kconfig files

Yap, just stick those rules somewhere on a website.

Btw, this is not only useful for a follow-on, fix patch but also for
initial test request. For example, I want to backport patch to stable
and would like to run it on a bunch of kernels:

base-commit: v4.4-stable, v4.9-stable, ...

i.e., a list of trees to apply it to. I believe people might like this a
lot.

Or, for example, a patch touching a bunch of arches and author doesn't
necessarily have access to all those different toolchains. Shoot a mail
to the 0day bot:

base-commit: linus/master
arch: x86_64, powerpc, sparc, ...

Would be very useful too.

Anyway, just a couple of ideas.

What would also be cool if you guys had a 0day bot howto with all those
things we should pay attention to and we can go and look up.

Thanks!

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH] IB/hfi1: use size_t for passing array length

[Doug Ledford]

On Tue, 2017-02-14 at 22:23 +0100, Arnd Bergmann wrote:
> gcc-7 produces a mysterious warning about the size argument being
> potentially out
> of range:
> 
> drivers/infiniband/hw/hfi1/verbs.c: In function 'init_cntr_names':
> drivers/infiniband/hw/hfi1/verbs.c:1644:2: error: 'memcpy': specified
> size between 18446744071562067968 and 18446744073709551615 exceeds
> maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
> 
> This seems to refer to a the case where an 64-bit size_t gets
> truncated
> into a negative 'int' and subsequently turned into a high 64-bit
> number
> again.
> 
> The fix is clearly to use size_t here, which matches the type that
> gets
> used for this value elsewhere.
> 
> Fixes: b7481944b06e ("IB/hfi1: Show statistics counters under IB
> stats interface")
> Signed-off-by: Arnd Bergmann 

Thanks, applied.

-- 
Doug Ledford 
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] IB/hns: include linux/module.h

[Doug Ledford]

On Fri, 2017-02-17 at 15:38 +0100, Arnd Bergmann wrote:
> I ran into a build error on arm64 randconfig testing:
> 
> infiniband/hw/hns/hns_roce_main.c:539:1: error: data definition has
> no type or storage class [-Werror]
> infiniband/hw/hns/hns_roce_main.c:539:1: error: type defaults to
> 'int' in declaration of 'MODULE_DEVICE_TABLE' [-Werror=implicit-int]
> infiniband/hw/hns/hns_roce_main.c:539:1: error: parameter names
> (without types) in function declaration [-Werror]
> infiniband/hw/hns/hns_roce_main.c:979:226: error: data definition has
> no type or storage class [-Werror]
> infiniband/hw/hns/hns_roce_main.c:979:226: error: type defaults to
> 'int' in declaration of 'module_init' [-Werror=implicit-int]
> infiniband/hw/hns/hns_roce_main.c:979:1: error: parameter names
> (without types) in function declaration [-Werror]
> 
> Including the module.h makes it build again.
> 
> Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver")
> Signed-off-by: Arnd Bergmann 

Thanks, applied.

-- 
Doug Ledford 
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] RDMA/bnxt_re: add DCB dependency

[Doug Ledford]

On Fri, 2017-02-17 at 15:40 +0100, Arnd Bergmann wrote:
> When CONFIG_DCB is disabled, we get a link error:
> 
> drivers/infiniband/built-in.o: In function `bnxt_re_setup_qos':
> trace.c:(.text+0x155774): undefined reference to
> `dcb_ieee_getapp_mask'
> trace.c:(.text+0x155774): relocation truncated to fit:
> R_AARCH64_CALL26 against undefined symbol `dcb_ieee_getapp_mask'
> trace.c:(.text+0x155794): undefined reference to
> `dcb_ieee_getapp_mask'
> trace.c:(.text+0x155794): relocation truncated to fit:
> R_AARCH64_CALL26 against undefined symbol `dcb_ieee_getapp_mask'
> 
> Like the other drivers that use this function, a Kconfig dependency
> is
> the correct fix.
> 
> Signed-off-by: Arnd Bergmann 

Thanks, applied.

-- 
Doug Ledford 
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] RDMA/qedr: Fix some error handling

[Doug Ledford]

On Sat, 2017-02-18 at 12:28 +0100, Christophe JAILLET wrote:
> 'qedr_alloc_pbl_tbl()' can not return NULL.
> 
> In qedr_init_user_queue():
>  - simplify the test for the return value, no need to test for NULL
>  - propagate the error pointer if needed, otherwise 0 (success) is
> returned.
>    This is spurious.
> 
> In init_mr_info():
>  - test the return value with IS_ERR
>  - propagate the error pointer if needed instead of an exlictit
> -ENOMEM.
>    This is a no-op as the only error pointer that we can have here is
>    already -ENOMEM
> 
> Signed-off-by: Christophe JAILLET 

Thanks, applied.

-- 
Doug Ledford 
    GPG KeyID: B826A3330E572FDD
   
Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


signature.asc
Description: This is a digitally signed message part

next-20170217 boot on POWER8 LPAR : WARNING @kernel/jump_label.c:287

[Sachin Sant]

While booting next-20170217 on a POWER8 LPAR following
warning is displayed.

Reverting the following commit helps boot cleanly.
commit 3821fd35b5 :  jump_label: Reduce the size of struct static_key

[   11.393008] [ cut here ]
[   11.393031] WARNING: CPU: 5 PID: 2890 at kernel/jump_label.c:287 
static_key_set_entries.isra.10+0x3c/0x50
[   11.393035] Modules linked in: nfsd(+) ip_tables x_tables autofs4
[   11.393043] CPU: 5 PID: 2890 Comm: modprobe Not tainted 
4.10.0-rc8-next-20170217-autotest #1
[   11.393047] task: c003a5692500 task.stack: c003a7774000
[   11.393051] NIP: c17bcffc LR: c17bd46c CTR: 
[   11.393054] REGS: c003a800 TRAP: 0700   Not tainted  
(4.10.0-rc8-next-20170217-autotest)
[   11.393058] MSR: 8282b033 
[   11.393065]   CR: 48248282  XER: 0001
[   11.393070] CFAR: c17bcfcc SOFTE: 1
GPR00: c17bd42c c003aa80 c262ce00 d3fdd580
GPR04: d3fe07df 00010017 c17bcd50 
GPR08: 00053a09 0001 c254ce00 0001
GPR12: c1b56c40 cea81400 0020 d5081098
GPR16: c003ada0 c003adec  84a8
GPR20: d3fef000 d3fe2b28 c252dc90 0001
GPR24: c254d314  c25338f8 d3fe089f
GPR28:  d3fe1400 d3fdd578 d3fe07df
[   11.393115] NIP [c17bcffc] static_key_set_entries.isra.10+0x3c/0x50
[   11.393119] LR [c17bd46c] jump_label_module_notify+0x20c/0x420
[   11.393122] Call Trace:
[   11.393125] [c003aa80] [c17bd42c] 
jump_label_module_notify+0x1cc/0x420 (unreliable)
[   11.393132] [c003ab40] [c16b38e0] 
notifier_call_chain+0x90/0x100
[   11.393137] [c003ab90] [c16b3db0] 
__blocking_notifier_call_chain+0x60/0x90
[   11.393142] [c003abe0] [c17357bc] load_module+0x1c1c/0x2750
[   11.393147] [c003ad70] [c1736550] SyS_finit_module+0xc0/0xf0
[   11.393152] [c003ae30] [c15cb8e0] system_call+0x38/0xfc
[   11.393156] Instruction dump:
[   11.393158] 40c20018 e923 792907a0 7c844b78 f883 4e800020 3d42fff2 
892a0514
[   11.393166] 2f89 40feffe0 3921 992a0514 <0fe0> 4bd0 6000 
6000
[   11.393173] ---[ end trace a5f8fbc5d8226aec ]---

Have attached boot log.

Thanks
-Sachin

dmesg_next_20170217.log
Description: Binary data

[PATCH] lightnvm: Fix error handling

[Christophe JAILLET]

According to error handling in this function, it is likely that going to
'out' was expected here.

Signed-off-by: Christophe JAILLET 
---
 drivers/lightnvm/rrpc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index e00b1d7b976f..e68efbcf1188 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -1275,8 +1275,10 @@ static int rrpc_bb_discovery(struct nvm_tgt_dev *dev, 
struct rrpc_lun *rlun)
}
 
nr_blks = nvm_bb_tbl_fold(dev->parent, blks, nr_blks);
-   if (nr_blks < 0)
-   return nr_blks;
+   if (nr_blks < 0) {
+   ret = nr_blks;
+   goto out;
+   }
 
for (i = 0; i < nr_blks; i++) {
if (blks[i] == NVM_BLK_T_FREE)
-- 
2.9.3

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[Pavel Machek]

Hi!

> About loosing precision: there is already noise (jitter) in
> real-world devices so that you can't achieve subpixel precision
> anyways (unless your panel has a very low resolution). Please see my
> answer to Dmitry some mails ago.

Maybe you can achieve better precision with averaging.

Anyway "input is already noisy" does not mean "so it is okay to
degrade it more". Solve it properly. That means passing calibration
data from kernel to userland.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Trying to understand OOM killer

[Michal Hocko]

On Sun 12-02-17 14:47:13, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> since some time, at Linux 4.8, 4.9, and 4.10-rc6, the OOM kicks in on a
> 8 GB machine.
> 
> ```
> Feb 12 08:21:50 asrocke350m1 kernel: updatedb.mlocat invoked oom-killer: 
> gfp_mask=0x16040d0(GFP_TEMPORARY|__GFP_COMP|__GFP_NOTRACK), nodemask=

The output is truncated. Could you send the full oom report? But this
smells like an example of the lowmem exhaustion. This is a lowmem
request on 32b system
[...]
> Feb 12 08:21:53 asrocke350m1 kernel: Node 0 active_anon:479572kB 
> inactive_anon:70712kB active_file:125844kB inactive_file:876364kB unevictable
> Feb 12 08:21:53 asrocke350m1 kernel: DMA free:3840kB min:788kB low:984kB 
> high:1180kB active_anon:0kB inactive_anon:0kB active_file:0kB inactiv
> Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 763 7663 7663
> Feb 12 08:21:53 asrocke350m1 kernel: Normal free:38764kB min:38828kB 
> low:48532kB high:58236kB active_anon:0kB inactive_anon:0kB active_file:16
> Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 0 55201 55201

lowmem is on the min watermark while there is no anonymous memory to be
reclaimed and we cannot really tell how much of the page cache as it is
truncated. We also do not know how large is the request because the
order part is missing. __GFP_COMP would suggest higher order request.

In short it is very likely that the OOM killer is genuine because the
given allocation request cannot be satisfied because the low mem
(~896MB) is depleted. This is an inherent problem of 32b kernels
unfortunately. Maybe there is a larger memory consumer in newer
kernels which changed the picture for you.
-- 
Michal Hocko
SUSE Labs

[PATCH 3/3] DT: i2c: add sht21 to trivial-devices

[Tomasz Duszynski]

Add binding for Sensirion sht21 relative humidity and temperature
sensor driver.

Signed-off-by: Tomasz Duszynski 
---
 Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 539874490492..919a763dcc23 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -79,6 +79,7 @@ ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME 
CLOCK IC
 ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
 samsung,24ad0xd1   S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
 sgx,vz89x  SGX Sensortech VZ89X Sensors
+sensirion,sht21Relative humidity and temperature sensor
 sii,s35390a2-wire CMOS real-time clock
 skyworks,sky81452  Skyworks SKY81452: Six-Channel White LED Driver with 
Touch Panel Bias Supply
 st-micro,24c256i2c serial eeprom  (24cxx)
--
2.11.1

Re: [RFC 7/8] fpga-region: add sysfs interface

[Alan Tull]

On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
 wrote:
> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
>> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
>>  wrote:
>>
>> > Hi all,
>> >Interesting discussion. The discussion so far has brought out many 
>> > concerns such as OS independence. There is an existing format, well-known 
>> > to developers, with widespread support, and which is quite extensible: 
>> > Type-Length-Value triples.
>> >
>> > To elaborate, a TLV-based format has many advantages:
>> > * It is highly extensible in many ways
>> >-- You can express structures and arrays using TLVs. Our needs right 
>> > now may seem limited but requirements grow over time.

Device tree can express arrays.

>> >-- The space of Type values can be decomposed into standard pre-defined 
>> > values that are in upstreamed code, and possibly experimental or 
>> > feature-specific values.
>> >-- Forward compatibility: We can write parsers that can skip unexpected 
>> > type values, thus allowing old parsers to work with new additions. With 
>> > some tweaks, old parsers can also reject unexpected values in some ranges 
>> > while accepting them in other ranges.
>> > * It is OS-independent.
>> > * It can be easily parsed, in kernel or user space.
>
> Are there other users of the format? I have to admit I didn't look very
> long, but couldn't find any libs / existing code at a first glance.

Is there a standard you are looking at?  Have you seen any use of TLV's
in the Linux kernel you could point to?

>
>> > * It can be validated, in terms of Type values, acceptable lengths, etc.
>> >
>> > It  is not directly human-readable but that can be easily addressed with a 
>> > tool that parses TLVs.
>> >
>> > Compared to some other proposals:
>> > * Compared to DTs, TLVs are OS-independent.
>
> That's just alternative facts here. Just because Linux uses fdt for
> devicetree blobs it is *not* OS dependent. There are several (see
> last email) non-Linux users of fdt / libfdt.
>
> Thanks,
>
> Moritz

It is worth repeating that libdtc is GPL/BSD with the intent of
allowing proprietary code to use libdtc.  So license shouldn't be a barrier.

Using device tree in the header would give us a way of doing enumeration at
least for Linux, not sure if that kind of info can be used in Windows
in some way.

Alan

[PATCH 1/3] iio: humidity: add sht21 relative humidity and temperature sensor driver

[Tomasz Duszynski]

Add sht21 relative humidity and temperature sensor driver. There already
exists an in-kernel driver under hwmon but with limited functionality
like humidity and temperature always measured together at predefined
resolutions, etc.

New iio driver comes without limitations of predecessor, uses non-blocking i2c
communication mode and adds triggered buffer support thus is suited for more
use cases.

Device datasheet can be found under:

https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/ \
Dokumente/2_Humidity_Sensors/Sensirion_Humidity_Sensors_SHT21_Datasheet_V4.pdf

Signed-off-by: Tomasz Duszynski 
---
 drivers/iio/humidity/Kconfig  |  10 +
 drivers/iio/humidity/Makefile |   1 +
 drivers/iio/humidity/sht21.c  | 519 ++
 3 files changed, 530 insertions(+)
 create mode 100644 drivers/iio/humidity/sht21.c

diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig
index 866dda16..93247ecc9324 100644
--- a/drivers/iio/humidity/Kconfig
+++ b/drivers/iio/humidity/Kconfig
@@ -35,6 +35,16 @@ config HTU21
  This driver can also be built as a module. If so, the module will
  be called htu21.

+config SHT21
+   tristate "Sensirion SHT21 relative humidity and temperature sensor"
+   depends on I2C
+   help
+ Say yes here to build support for the  Sensirion SHT21 relative
+ humidity and temperature sensor.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sht21.
+
 config SI7005
tristate "SI7005 relative humidity and temperature sensor"
depends on I2C
diff --git a/drivers/iio/humidity/Makefile b/drivers/iio/humidity/Makefile
index c9f089a9a6b8..f2472fd2cc44 100644
--- a/drivers/iio/humidity/Makefile
+++ b/drivers/iio/humidity/Makefile
@@ -5,5 +5,6 @@
 obj-$(CONFIG_DHT11) += dht11.o
 obj-$(CONFIG_HDC100X) += hdc100x.o
 obj-$(CONFIG_HTU21) += htu21.o
+obj-$(CONFIG_SHT21) += sht21.o
 obj-$(CONFIG_SI7005) += si7005.o
 obj-$(CONFIG_SI7020) += si7020.o
diff --git a/drivers/iio/humidity/sht21.c b/drivers/iio/humidity/sht21.c
new file mode 100644
index ..199933b87297
--- /dev/null
+++ b/drivers/iio/humidity/sht21.c
@@ -0,0 +1,519 @@
+/*
+ * Sensirion SHT21 relative humidity and temperature sensor driver
+ *
+ * Copyright (C) 2017 Tomasz Duszynski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 7-bit I2C slave address: 0x40
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SHT21_DRV_NAME "sht21"
+
+#define SHT21_TRIGGER_T_MEASUREMENT 0xF3
+#define SHT21_TRIGGER_RH_MEASUREMENT 0xF5
+
+#define SHT21_WRITE_USER_REG 0xE6
+#define SHT21_READ_USER_REG 0xE7
+#define SHT21_SOFT_RESET 0xFE
+
+#define SHT21_USER_REG_RES_8_12 BIT(0)
+#define SHT21_USER_REG_RES_10_13 BIT(7)
+#define SHT21_USER_REG_RES_11_11 (BIT(7) | BIT(0))
+
+#define SHT21_USER_REG_ENABLE_HEATER BIT(2)
+
+enum {
+   RES_12_14,
+   RES_8_12,
+   RES_10_13,
+   RES_11_11,
+};
+
+/*
+ * Combined sampling frequency i.e measuring RH and T together, which seems
+ * to be common case for pressure/humidity sensors, was chosen so that sensor
+ * is active for only 10% of time thus avoiding self-heating effect.
+ *
+ * Note that sampling frequencies are higher when measuring RH or T separately.
+ *
+ * Following table shows how available resolutions, combined sampling frequency
+ * and frequencies for RH and T when measured separately are related.
+ *
+ * +---+-+-++
+ * | RH / T resolution | RH + T [Hz] | RH [Hz] | T [Hz] |
+ * +---+-+-++
+ * | 12 / 14   | 0.88| 3.45| 1.18   |
+ * +---+-+-++
+ * | 8 / 12| 3.85| 25  | 4.55   |
+ * +---+-+-++
+ * | 10 / 13   | 1.93| 11.11   | 2.33   |
+ * +---+-+-++
+ * | 11 / 11   | 2.28| 6.67| 9.09   |
+ * +---+-+-++
+ */
+static const struct {
+   int freq;
+   int freq2;
+
+   int rh_meas_time;
+   int t_meas_time;
+} sht21_freq_meas_time_tbl[] = {
+   [RES_12_14] = { 0, 88, 29000, 85000 },
+   [RES_8_12] = { 3, 85, 4000, 22000 },
+   [RES_10_13] = { 1, 93, 9000, 43000 },
+   [RES_11_11] = { 2, 28, 15000

[PATCH 2/3] of: add vendor prefix for Sensirion company

[Tomasz Duszynski]

This patch adds prefix for Sensirion company.

Signed-off-by: Tomasz Duszynski 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 44ddc980b085..992ec480be53 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -203,6 +203,7 @@ sbs Smart Battery System
 schindler  Schindler
 seagateSeagate Technology PLC
 semtechSemtech Corporation
+sensirion Sensirion AG
 sgxSGX Sensortech
 sharp  Sharp Corporation
 sigma  Sigma Designs, Inc.
--
2.11.1

Re: [PATCH 1/3] iio: humidity: add sht21 relative humidity and temperature sensor driver

[Jonathan Cameron]

On 19/02/17 14:58, Tomasz Duszynski wrote:
> Add sht21 relative humidity and temperature sensor driver. There already
> exists an in-kernel driver under hwmon but with limited functionality
> like humidity and temperature always measured together at predefined
> resolutions, etc.
> 
> New iio driver comes without limitations of predecessor, uses non-blocking i2c
> communication mode and adds triggered buffer support thus is suited for more
> use cases.
> 
> Device datasheet can be found under:
> 
> https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/ \
> Dokumente/2_Humidity_Sensors/Sensirion_Humidity_Sensors_SHT21_Datasheet_V4.pdf
> 
> Signed-off-by: Tomasz Duszynski 
Hi Tomasz,

I haven't looked at this yet, but one thing we have to do whenever suggesting
replacement of an hwmon driver is to convince the hwmon guys that it is a
good idea.  

As such I've cc'd Guenter, Jean and the list.

Jonathan

p.s Probably won't get to this today as running out of time.  Depending on
how mad the week is it might be next weekend before I get a chance.
> ---
>  drivers/iio/humidity/Kconfig  |  10 +
>  drivers/iio/humidity/Makefile |   1 +
>  drivers/iio/humidity/sht21.c  | 519 
> ++
>  3 files changed, 530 insertions(+)
>  create mode 100644 drivers/iio/humidity/sht21.c
> 
> diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig
> index 866dda16..93247ecc9324 100644
> --- a/drivers/iio/humidity/Kconfig
> +++ b/drivers/iio/humidity/Kconfig
> @@ -35,6 +35,16 @@ config HTU21
> This driver can also be built as a module. If so, the module will
> be called htu21.
> 
> +config SHT21
> + tristate "Sensirion SHT21 relative humidity and temperature sensor"
> + depends on I2C
> + help
> +   Say yes here to build support for the  Sensirion SHT21 relative
> +   humidity and temperature sensor.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called sht21.
> +
>  config SI7005
>   tristate "SI7005 relative humidity and temperature sensor"
>   depends on I2C
> diff --git a/drivers/iio/humidity/Makefile b/drivers/iio/humidity/Makefile
> index c9f089a9a6b8..f2472fd2cc44 100644
> --- a/drivers/iio/humidity/Makefile
> +++ b/drivers/iio/humidity/Makefile
> @@ -5,5 +5,6 @@
>  obj-$(CONFIG_DHT11) += dht11.o
>  obj-$(CONFIG_HDC100X) += hdc100x.o
>  obj-$(CONFIG_HTU21) += htu21.o
> +obj-$(CONFIG_SHT21) += sht21.o
>  obj-$(CONFIG_SI7005) += si7005.o
>  obj-$(CONFIG_SI7020) += si7020.o
> diff --git a/drivers/iio/humidity/sht21.c b/drivers/iio/humidity/sht21.c
> new file mode 100644
> index ..199933b87297
> --- /dev/null
> +++ b/drivers/iio/humidity/sht21.c
> @@ -0,0 +1,519 @@
> +/*
> + * Sensirion SHT21 relative humidity and temperature sensor driver
> + *
> + * Copyright (C) 2017 Tomasz Duszynski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * 7-bit I2C slave address: 0x40
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SHT21_DRV_NAME "sht21"
> +
> +#define SHT21_TRIGGER_T_MEASUREMENT 0xF3
> +#define SHT21_TRIGGER_RH_MEASUREMENT 0xF5
> +
> +#define SHT21_WRITE_USER_REG 0xE6
> +#define SHT21_READ_USER_REG 0xE7
> +#define SHT21_SOFT_RESET 0xFE
> +
> +#define SHT21_USER_REG_RES_8_12 BIT(0)
> +#define SHT21_USER_REG_RES_10_13 BIT(7)
> +#define SHT21_USER_REG_RES_11_11 (BIT(7) | BIT(0))
> +
> +#define SHT21_USER_REG_ENABLE_HEATER BIT(2)
> +
> +enum {
> + RES_12_14,
> + RES_8_12,
> + RES_10_13,
> + RES_11_11,
> +};
> +
> +/*
> + * Combined sampling frequency i.e measuring RH and T together, which seems
> + * to be common case for pressure/humidity sensors, was chosen so that sensor
> + * is active for only 10% of time thus avoiding self-heating effect.
> + *
> + * Note that sampling frequencies are higher when measuring RH or T 
> separately.
> + *
> + * Following table shows how available resolutions, combined sampling 
> frequency
> + * and frequencies for RH and T when measured separately are related.
> + *
> + * +---+-+-++
> + * | RH / T resolution | RH + T [Hz] | RH [Hz] | T [Hz] |
> + * +---+-+-++
> + * | 12 / 14   | 0.88| 3.45| 1.18   |
> + * +---+-+-++
> + * | 8 / 12| 3.85| 

Re: [PATCH v2 1/2] iio: Allow triggers to be used as parent of others triggers

[Jonathan Cameron]

On 16/02/17 14:23, Benjamin Gaignard wrote:
> Add "parent_trigger" sysfs attribute to iio trigger to be able
> to set a parent to the current trigger.
> Parent trigger edges or levels could be used to control current
> trigger status for example to start, stop or reset it.
Reset needs a description as well. In this case I think it boils
down to syncing a periodic timer driven trigger.
> 
> Introduce validate_trigger function in iio_trigger_ops which does
> the same than validate_device but with a trigger as second parameter.
> Driver must implement this function and add dev_attr_parent_trigger
> in their trigger attribute group to be able to use parent trigger
> feature.
> 
> Signed-off-by: Benjamin Gaignard 
I think I'm fine with this but it's 'unusual' enough that I want
to get to the point where we have some more people involved in
the discussion.

Jonathan
> 
> version 2:
> - add comment about parent trigger usage
> - parent trigger attribute must be set the driver no more by IIO core
> ---
>  .../ABI/testing/sysfs-bus-iio-trigger-sysfs| 10 
>  drivers/iio/industrialio-trigger.c | 68 
> ++
>  include/linux/iio/trigger.h|  7 ++-
>  3 files changed, 84 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs 
> b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
> index 04ac623..9862562 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
> @@ -40,3 +40,13 @@ Description:
>   associated file, representing the id of the trigger that needs
>   to be removed. If the trigger can't be found, an invalid
>   argument message will be returned to the user.
> +
> +What:/sys/bus/iio/devices/triggerX/parent_trigger
> +KernelVersion:   4.12
> +Contact: linux-...@vger.kernel.org
> +Description:
> + This attribute is used to set a trigger as parent for the
> + current trigger. If the trigger can't use the parent an
> + invalid argument message will be returned.
> + Parent trigger edges or levels could be used to control current
> + trigger for example to start, stop or reset it.
> diff --git a/drivers/iio/industrialio-trigger.c 
> b/drivers/iio/industrialio-trigger.c
> index 978729f..238aa1a 100644
> --- a/drivers/iio/industrialio-trigger.c
> +++ b/drivers/iio/industrialio-trigger.c
> @@ -58,6 +58,74 @@ static ssize_t iio_trigger_read_name(struct device *dev,
>  
>  static DEVICE_ATTR(name, S_IRUGO, iio_trigger_read_name, NULL);
>  
> +/**
> + * iio_trigger_read_parent() - trigger consumer sysfs query parent trigger
> + * @dev: device associated with an industrial I/O trigger
> + * @attr:pointer to the device_attribute structure that
> + *   is being processed
> + * @buf: buffer where the current trigger name will be printed into
> + *
> + * Return: a negative number on failure, the number of characters written
> + *  on success or 0 if no trigger is available
> + */
> +static ssize_t iio_trigger_read_parent(struct device *dev,
> +struct device_attribute *attr,
> +char *buf)
> +{
> + struct iio_trigger *trig = to_iio_trigger(dev);
> +
> + if (trig->parent_trigger)
> + return sprintf(buf, "%s\n", trig->parent_trigger->name);
> +
> + return 0;
> +}
> +
> +static struct iio_trigger *iio_trigger_find_by_name(const char *name,
> + size_t len);
> +
> +/**
> + * iio_trigger_write_parent() - trigger consumer sysfs set parent trigger
> + * @dev: device associated with an industrial I/O trigger
> + * @attr:device attribute that is being processed
> + * @buf: string buffer that holds the name of the trigger
> + * @len: length of the trigger name held by buf
> + *
> + * Return: negative error code on failure or length of the buffer
> + *  on success
> + */
> +static ssize_t iio_trigger_write_parent(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t len)
> +{
> + struct iio_trigger *parent;
> + struct iio_trigger *child = to_iio_trigger(dev);
> + int ret;
> +
> + if (!child->ops->validate_trigger)
> + return -EINVAL;
> +
> + if (atomic_read(&child->use_count))
> + return -EBUSY;
> +
> + parent = iio_trigger_find_by_name(buf, len);
> +
> + if (parent == child->parent_trigger)
> + return len;
> +
> + ret = child->ops->validate_trigger(child, parent);
> + if (ret)
> + return ret;
> +
> + child->parent_trigger = parent;
> +
> + return len;
> +}
> +
> +DEVICE_ATTR(parent_trigger, S_IRUGO | S_IWUSR,
> +   

Re: [PATCH] Add model data for Dell Precision 3510 trackpad.

[John Preston]

On 2017-02-19 13:35, Pali Rohár wrote:

On Sunday 19 February 2017 13:16:34 John L. Preston wrote:

---
 drivers/input/mouse/alps.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 328edc8c8786..c0a4edefe54d 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -139,6 +139,7 @@ static const struct alps_model_info 
alps_model_data[] = {

{ { 0x52, 0x01, 0x14 }, 0x00, { ALPS_PROTO_V2, 0xff, 0xff,
 		ALPS_PASS | ALPS_DUALPOINT | ALPS_PS2_INTERLEAVED } },/* 
Toshiba Tecra A11-11L */

{ { 0x73, 0x02, 0x64 }, 0x8a, { ALPS_PROTO_V4, 0x8f, 0x8f, 0 } },
+	{ { 0x73, 0x03, 0x28 }, 0x13, { ALPS_PROTO_V8, 0x18, 0x18, 0 } 
},			/* Dell Precision 3510 */

 };

 static const struct alps_protocol_info alps_v3_protocol_data = {


Hi John! This is not a correct place do add new proto data. I already
proposed reducing this table to just for PROTO_V2, but Dmitry was not
happy about it.


Hi Pali. :)



Anyway, look at function alps_identify() where is detection for 
ALPS_V8:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/mouse/alps.c?h=v4.10-rc8#n2829

V8 is already detected when e7 is (0x73, 0x03, 0x28) and ec[1] is 0x01.
What are your ec data? Probably ec[1] is not 0x01 as otherwise it 
should

be already detected.


I have just found that code and am confused because that is not the same 
code I have running on my system. My ec[1] is 0x01 so you are correct, 
it should already be detected and my patch is unnecessary. Sorry for the 
inconvenience.




Btw, from where you got your proto data in this patch?


I pulled it from dmesg:

[john@slate ~]$ dmesg|grep "Unknown ALPS touchpad"
[3.071891] psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 28, 
EC=73 01 13

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Thomas Hellstrom]

So I think we need a quick revert of this commit or a quick stable
follow-up to unbreak things on our side.

/Thomas


On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
> Hi!
>
> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
> node to tell DRM about the monitor layout...
>
> /Thomas
>
>
> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
>> Looking at the ioctl permission checks I noticed that it's impossible
>> to import gem buffers into a control nodes, and fd2handle/handle2fd
>> also don't work, so no joy with dma-bufs.
>>
>> The only way to do anything with a control node is by drawing stuff
>> into a dumb buffer and displaying that. I suspect control nodes are an
>> entirely unused thing, and a cursory check shows that there does not
>> seem to be any callers of drmOpenControl nor of the other drmOpen
>> functions using DRM_MODE_CONTROL.
>>
>> Since I don't like dead uabi, let's remove it. But since this would be
>> a really big change I think it's better to start out small by simply
>> not registering anything. We can garbage-collect the dead code later
>> on, once we're sure it's really not used anywhere.
>>
>> Signed-off-by: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/drm_drv.c | 6 --
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 6efdba4993fc..f085e28ffc6f 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
>>  goto err_free;
>>  }
>>  
>> -if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>> -ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
>> -if (ret)
>> -goto err_minors;
>> -}
>> -
>>  if (drm_core_check_feature(dev, DRIVER_RENDER)) {
>>  ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
>>  if (ret)
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] Re: [PATCH] Staging: ks7010: There should be no spaces at the start of a line

[Julia Lawall]

On Sun, 19 Feb 2017, Arushi Singhal wrote:

>
> Hi Greg
> I think we cannot indent the text otherwise, the print statement will be
> different as it should be

There are newlines in the printed string.  I suspect that there is no need
to print them all at once.

Actually, your change removed spaces inside a string, so it did change the
form of the poutput.

Also, remember not to top post :)

julia

> Thanks
>
> On Saturday, February 18, 2017 at 10:27:19 PM UTC+5:30, gregkh wrote:
>   On Sat, Feb 18, 2017 at 10:10:02PM +0530, Arushi Singhal wrote:
>   > The following patch the checkpatch.pl warning:
>   > drivers/staging/ks7010/ks_hostif.c warning: please, no spaces
>   at the
>   > start of a line
>   >
>   > Signed-off-by: Arushi Singhal 
>   > ---
>   >  drivers/staging/ks7010/ks_hostif.c | 4 ++--
>   >  1 file changed, 2 insertions(+), 2 deletions(-)
>   >
>   > diff --git a/drivers/staging/ks7010/ks_hostif.c
>   b/drivers/staging/ks7010/ks_hostif.c
>   > index 819e08b5fa91..3b2e28749b63 100644
>   > --- a/drivers/staging/ks7010/ks_hostif.c
>   > +++ b/drivers/staging/ks7010/ks_hostif.c
>   > @@ -191,8 +191,8 @@ int get_current_ap(struct ks_wlan_private
>   *priv, struct link_ap_info_t *ap_info)
>   >  }
>   >  DPRINTK(4, "\n    Link AP\n");
>   >  DPRINTK(4, "    bssid=%02X:%02X:%02X:%02X:%02X:%02X\n
>   \
>   > -   essid=%s\n  
>    rate_set=%02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n  
>    channel=%d\n \
>   > -   rssi=%d\n    sq=%d\n    capability=%04X\n", ap->bssid[0],
>   ap->bssid[1], ap->bssid[2], ap->bssid[3], ap->bssid[4],
>   ap->bssid[5], &(ap->ssid.body[0]), ap->rate_set.body[0],
>   ap->rate_set.body[1], ap->rate_set.body[2],
>   ap->rate_set.body[3], ap->rate_set.body[4],
>   ap->rate_set.body[5], ap->rate_set.body[6],
>   ap->rate_set.body[7], ap->channel, ap->rssi, ap->sq,
>   ap->capability);
>   > +essid=%s\n  
>    rate_set=%02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n  
>    channel=%d\n \
>   > +rssi=%d\n    sq=%d\n    capability=%04X\n", ap->bssid[0],
>   ap->bssid[1], ap->bssid[2], ap->bssid[3], ap->bssid[4],
>   ap->bssid[5], &(ap->ssid.body[0]), ap->rate_set.body[0],
>   ap->rate_set.body[1], ap->rate_set.body[2],
>   ap->rate_set.body[3], ap->rate_set.body[4],
>   ap->rate_set.body[5], ap->rate_set.body[6],
>   ap->rate_set.body[7], ap->channel, ap->rssi, ap->sq,
>   ap->capability);
>
>   So don't just remove the spaces, fix it correctly with the
>   proper
>   indentation please.
>
>   thanks,
>
>   greg k-h
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web 
> visithttps://groups.google.com/d/msgid/outreachy-kernel/df1dbfa6-0823-4899-b1b7-
> 4358b18575be%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

Re: Hard-coding PTY device node numbers in userspace

[Florian Weimer]

* Greg KH:

> On Fri, Feb 17, 2017 at 12:02:52PM +0100, Florian Weimer wrote:
>> We want to reject PTY devices from other namespaces as valid input to
>> the ttyname and ttyname_r functions, while still providing a hint to
>> callers that the device is, in fact, a PTY.  Christian Brauner wrote a
>> glibc patch for this:
>> 
>>   
>> 
>> It hard-codes the major PTY device number range.  Is this feasible?
>> Is it part of the stable userspace ABI for the TTY subsystem?
>
> What major numbers are you using in the patch '2' and '3'?

I think there is just one patch, and the check looks like this:

  static inline int
  is_pty (struct stat64 *sb)
  {
int m = major (sb->st_rdev);
return (136 <= m && m <= 143);
  }

> And yes,
> major numbers are static and you should be fine to rely on them.  But
> can't you test that the device is a pty to verify it?

It's not entirely clear what exactly a PTY descriptor should be for
ttyname.  Going forward, we only want to treat descriptors for PTY
devices which can be accessed using /dev/pts paths in the current
namespace as PTYs.  Christian's patch adds a separate error code for
the case where the descriptor is a PTY, but it comes from a different
namespace.

I'm concerned that some software out there assumes that if standard
input is a PTY according to ttyname, it is safe to chown it.  There
have been security issues related to that a long time ago on some UNIX
systems, and I want us to be conservative here.

[PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

[Jason Vas Dias]

Patch to make tsc.c set X86_FEATURE_ART and setup the TSC_ADJUST MSR
correctly on my "i7-4910MQ" CPU, which reports
( boot_cpu_data.cpuid_level==0x13  &&
  boot_cpu_data.extended_cpuid_level==0x8008
), so the code didn't think it supported CPUID:15h, but it does .

Patch:

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 46b2f41..f76cca8 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -1030,6 +1030,7 @@ core_initcall(cpufreq_register_tsc_scaling);
 #endif /* CONFIG_CPU_FREQ */

 #define ART_CPUID_LEAF (0x15)
+#define MINIMUM_CPUID_EXTENDED_LEAF_THAT_MUST_HAVE_ART (0x8008)
 #define ART_MIN_DENOMINATOR (1)


@@ -1038,24 +1039,43 @@ core_initcall(cpufreq_register_tsc_scaling);
  */
 static void detect_art(void)
 {
-   unsigned int unused[2];
-
-   if (boot_cpu_data.cpuid_level < ART_CPUID_LEAF)
-   return;
-
-   cpuid(ART_CPUID_LEAF, &art_to_tsc_denominator,
- &art_to_tsc_numerator, unused, unused+1);
-
+   unsigned int v[2];
+
+   if(boot_cpu_data.cpuid_level < ART_CPUID_LEAF)
+{
+if(boot_cpu_data.extended_cpuid_level >=
MINIMUM_CPUID_EXTENDED_LEAF_THAT_MUST_HAVE_ART)
+{
+pr_info("Would normally not use ART -
cpuid_level:%d < %d - but extended_cpuid_level is: %x, so probing for
ART support.\n",
+boot_cpu_data.cpuid_level, ART_CPUID_LEAF,
boot_cpu_data.extended_cpuid_level);
+}else
+return;
+}
+
+cpuid(ART_CPUID_LEAF, &art_to_tsc_denominator,
+  &art_to_tsc_numerator, v, v+1);
+
/* Don't enable ART in a VM, non-stop TSC required */
if (boot_cpu_has(X86_FEATURE_HYPERVISOR) ||
-   !boot_cpu_has(X86_FEATURE_NONSTOP_TSC) ||
-   art_to_tsc_denominator < ART_MIN_DENOMINATOR)
-   return;
-
-   if (rdmsrl_safe(MSR_IA32_TSC_ADJUST, &art_to_tsc_offset))
-   return;
-
+   !boot_cpu_has(X86_FEATURE_NONSTOP_TSC) ||
+  art_to_tsc_denominator < ART_MIN_DENOMINATOR)
+{
+pr_info("Not using Intel ART for TSC - HYPERVISOR:%d
NO NONSTOP_TSC:%d  bad TSC/Crystal ratio denominator: %d.",
boot_cpu_has(X86_FEATURE_HYPERVISOR),
!boot_cpu_has(X86_FEATURE_NONSTOP_TSC), art_to_tsc_denominator );
+return;
+}
+   if (  (v[0]=rdmsrl_safe(MSR_IA32_TSC_ADJUST,
&art_to_tsc_offset))!=0) /* will get fault on first read if nothing
written yet */
+{
+if((v[1]=wrmsrl_safe(MSR_IA32_TSC_ADJUST, 0))!=0)
+{
+pr_info("Not using Intel ART for TSC - failed
to initialize TSC_ADJUST: %d %d.\n", v[0], v[1] );
+return;
+}else
+{
+art_to_tsc_offset = 0; /* perhaps initalize
to -1 * current rdtsc value ? */
+pr_info("Using Intel ART for TSC - TSC_ADJUST
initialized to %llu.\n",art_to_tsc_offset);
+}
+}
/* Make this sticky over multiple CPU init calls */
+pr_info("Using Intel Always Running Timer (ART) feature %x
for TSC on all CPUs - TSC/CCC: %d/%d offset: %llu.\n",
X86_FEATURE_ART, art_to_tsc_numerator, art_to_tsc_denominator,
art_to_tsc_offset );
setup_force_cpu_cap(X86_FEATURE_ART);
 }


I originally reported this issue on bugzilla.kernel.org : bug # 194609 :
https://bugzilla.kernel.org/show_bug.cgi?id=194609
, but it was not posted to the list , & then I posted it to the list, but
Julia Lawell  kindly suggested I should re-post with
patch inline, & include extra recipients, which includes the last
person to modify tsc.c (Prarit), so am doing so.

My CPU reports 'model name' as
"Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz" ,
has 4 physical & 8 hyperthreading cores with a frequency scalable from 80
to 390 (/sys/devices/system/cpu/cpu0/cpufreq/scaling_{min,max}_freq) , and
flags :
fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1
sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c
rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm
ida arat pln pts

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
$

CPUID:15H is available in user-space, returning the integers : ( 7,
832, 832 ) in EAX:EBX:ECX , yet boot_cpu_data.cpuid_level is 13 , so
in detect_art() in tsc.c,
Linux does not think ART is enabled, and does not set the synthesized CPUID +
((3*32)+10) bit, so a program looking at /dev/cpu/0/cpuid would not
see this bit set .
if an e1000 NIC card had been installed, PTP would no

Re: [RESEND PATCH 1/1] can: m_can: fix bitrate setup on latest silicon

[Oliver Hartkopp]

Hi all,

On 02/15/2017 03:08 PM, Quentin Schulz wrote:

From: Florian Vallee 

According to the m_can user manual changelog the BTP register layout was
updated with core revision 3.1.0

This change is not backward-compatible and using the current driver along
with a recent IP results in an incorrect bitrate on the wire.


the BTP register layout is only one of eleven changes between 3.0.1 and 
3.1.0:


1. Register FBTP renamed to DBTP and restructured
2. Register TEST restructured
3. Register CCCR restructured
4. Register BTP renamed to NBTP and restructured <<< HERE
5. Register PSR updated
6. Register TDCR added
7. Register IR updated
8. Register IE updated
9. Register ILS updated
10. Rx Buffer and FIFO Element updated
11. Tx Buffer Element updated

Especially the change #11 allows the switch between CAN and CAN FD 
frames on a per-frame setting without switching the entire controller 
mode via CCCR register in IP core 3.0.1:


https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/can/m_can/m_can.c?h=linux-4.9.y#n1075

Fortunately I was contacted by Bosch this Friday as they want to 
contribute a driver upgrade to support IP cores up to 3.2.x.
Additionally their plan is to use Device Tree information to determine 
the IP core revision - or at least to cross check its information with 
the register information used in your suggestion.


For that reason I would suggest to wait for the driver updates from 
Bosch instead of adding an incomplete fix for only one change of eleven.


Btw. it would be very cool if you could provide some testing for the 
upcoming changes from Bosch when they are posted.


Best regards,
Oliver



Tested with a SAMA5D2 SoC (CREL = 0x31040730)

Signed-off-by: Florian Vallee 
Tested-by: Quentin Schulz 
---
 drivers/net/can/m_can/m_can.c | 38 +++---
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 195f15e..246584e 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -105,6 +105,10 @@ enum m_can_mram_cfg {
MRAM_CFG_NUM,
 };

+/* Core Release Register (CREL) */
+#define CRR_REL_MASK   0xfff
+#define CRR_REL_SHIFT  20
+
 /* Fast Bit Timing & Prescaler Register (FBTP) */
 #define FBTR_FBRP_MASK 0x1f
 #define FBTR_FBRP_SHIFT16
@@ -136,7 +140,7 @@ enum m_can_mram_cfg {
 #define CCCR_INIT  BIT(0)
 #define CCCR_CANFD 0x10

-/* Bit Timing & Prescaler Register (BTP) */
+/* Bit Timing & Prescaler Register (BTP) (M_CAN IP < 3.1.0) */
 #define BTR_BRP_MASK   0x3ff
 #define BTR_BRP_SHIFT  16
 #define BTR_TSEG1_SHIFT8
@@ -146,6 +150,16 @@ enum m_can_mram_cfg {
 #define BTR_SJW_SHIFT  0
 #define BTR_SJW_MASK   0xf

+/* Nominal Bit Timing & Prescaler Register (NBTP) (M_CAN IP >= 3.1.0) */
+#define NBTR_SJW_SHIFT 25
+#define NBTR_SJW_MASK  (0x7f << NBTR_SJW_SHIFT)
+#define NBTR_BRP_SHIFT 16
+#define NBTR_BRP_MASK  (0x3ff << NBTR_BRP_SHIFT)
+#define NBTR_TSEG1_SHIFT   8
+#define NBTR_TSEG1_MASK(0xff << NBTR_TSEG1_SHIFT)
+#define NBTR_TSEG2_SHIFT   0
+#define NBTR_TSEG2_MASK(0x7f << NBTR_TSEG2_SHIFT)
+
 /* Error Counter Register(ECR) */
 #define ECR_RP BIT(15)
 #define ECR_REC_SHIFT  8
@@ -200,6 +214,9 @@ enum m_can_mram_cfg {
 IR_RF1L | IR_RF0L)
 #define IR_ERR_ALL (IR_ERR_STATE | IR_ERR_BUS)

+/* Core Version */
+#define M_CAN_COREREL_3_1_00x310
+
 /* Interrupt Line Select (ILS) */
 #define ILS_ALL_INT0   0x0
 #define ILS_ALL_INT1   0x
@@ -357,6 +374,13 @@ static inline void m_can_disable_all_interrupts(const 
struct m_can_priv *priv)
m_can_write(priv, M_CAN_ILE, 0x0);
 }

+static inline int m_can_read_core_rev(const struct m_can_priv *priv)
+{
+   u32 reg = m_can_read(priv, M_CAN_CREL);
+
+   return ((reg >> CRR_REL_SHIFT) & CRR_REL_MASK);
+}
+
 static void m_can_read_fifo(struct net_device *dev, u32 rxfs)
 {
struct net_device_stats *stats = &dev->stats;
@@ -811,8 +835,16 @@ static int m_can_set_bittiming(struct net_device *dev)
sjw = bt->sjw - 1;
tseg1 = bt->prop_seg + bt->phase_seg1 - 1;
tseg2 = bt->phase_seg2 - 1;
-   reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
-   (tseg1 << BTR_TSEG1_SHIFT) | (tseg2 << BTR_TSEG2_SHIFT);
+
+   if (m_can_read_core_rev(priv) < M_CAN_COREREL_3_1_0)
+   reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
+   (tseg1 << BTR_TSEG1_SHIFT) |
+   (tseg2 << BTR_TSEG2_SHIFT);
+   else
+   reg_btp = (brp << NBTR_BRP_SHIFT) | (sjw << NBTR_SJW_SHIFT) |
+   (tseg1 << NBTR_TSEG1_SHIFT) |
+   (tseg2 << NBTR_TSEG2_SHIFT)

[ANNOUNCE] v4.9.11-rt9

[Sebastian Andrzej Siewior]

Dear RT folks!

I'm pleased to announce the v4.9.11-rt9 patch set. 

Changes since v4.9.11-rt8:

  - rt_mutex_destroy() is EXPORT_SYMBOL_GPL again. As pointed by Peter
Zijlstra, the removal of _GPL is not required.

  - Added a rescheduling point so we don't forget to run a runnable task
at elevated priority under certain circumstances.

  - The static initializes for PER_CPU locks were wrong. This affects
the local_locks and resulted in lockdep disabling itself a few
minutes after boot on _big_ iron (100 CPUs+). Reported by Mike
Galbraith and patched by Thomas Gleixner.

Known issues
- CPU hotplug got a little better but can deadlock.

The delta patch against v4.9.11-rt9 is appended below and can be found here:
 
 
https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/incr/patch-4.9.11-rt8-rt9.patch.xz

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git 
v4.9.11-rt9

The RT patch against v4.9.11 can be found here:


https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/older/patch-4.9.11-rt9.patch.xz

The split quilt queue is available at:


https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/older/patches-4.9.11-rt9.tar.xz

Sebastian
diff --git a/include/linux/module.h b/include/linux/module.h
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -496,6 +496,7 @@ static inline int module_is_live(struct module *mod)
 struct module *__module_text_address(unsigned long addr);
 struct module *__module_address(unsigned long addr);
 bool is_module_address(unsigned long addr);
+bool __is_module_percpu_address(unsigned long addr, unsigned long *can_addr);
 bool is_module_percpu_address(unsigned long addr);
 bool is_module_text_address(unsigned long addr);
 
diff --git a/include/linux/percpu.h b/include/linux/percpu.h
--- a/include/linux/percpu.h
+++ b/include/linux/percpu.h
@@ -139,6 +139,7 @@ extern int __init pcpu_page_first_chunk(size_t 
reserved_size,
 #endif
 
 extern void __percpu *__alloc_reserved_percpu(size_t size, size_t align);
+extern bool __is_kernel_percpu_address(unsigned long addr, unsigned long 
*can_addr);
 extern bool is_kernel_percpu_address(unsigned long addr);
 
 #if !defined(CONFIG_SMP) || !defined(CONFIG_HAVE_SETUP_PER_CPU_AREA)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -658,6 +658,7 @@ look_up_lock_class(struct lockdep_map *lock, unsigned int 
subclass)
struct lockdep_subclass_key *key;
struct hlist_head *hash_head;
struct lock_class *class;
+   bool is_static = false;
 
if (unlikely(subclass >= MAX_LOCKDEP_SUBCLASSES)) {
debug_locks_off();
@@ -671,10 +672,23 @@ look_up_lock_class(struct lockdep_map *lock, unsigned int 
subclass)
 
/*
 * Static locks do not have their class-keys yet - for them the key
-* is the lock object itself:
+* is the lock object itself. If the lock is in the per cpu area,
+* the canonical address of the lock (per cpu offset removed) is
+* used.
 */
-   if (unlikely(!lock->key))
-   lock->key = (void *)lock;
+   if (unlikely(!lock->key)) {
+   unsigned long can_addr, addr = (unsigned long)lock;
+
+   if (__is_kernel_percpu_address(addr, &can_addr))
+   lock->key = (void *)can_addr;
+   else if (__is_module_percpu_address(addr, &can_addr))
+   lock->key = (void *)can_addr;
+   else if (static_obj(lock))
+   lock->key = (void *)lock;
+   else
+   return ERR_PTR(-EINVAL);
+   is_static = true;
+   }
 
/*
 * NOTE: the class-key must be unique. For dynamic locks, a static
@@ -706,7 +720,7 @@ look_up_lock_class(struct lockdep_map *lock, unsigned int 
subclass)
}
}
 
-   return NULL;
+   return is_static || static_obj(lock->key) ? NULL : ERR_PTR(-EINVAL);
 }
 
 /*
@@ -724,19 +738,18 @@ register_lock_class(struct lockdep_map *lock, unsigned 
int subclass, int force)
DEBUG_LOCKS_WARN_ON(!irqs_disabled());
 
class = look_up_lock_class(lock, subclass);
-   if (likely(class))
+   if (likely(!IS_ERR_OR_NULL(class)))
goto out_set_class_cache;
 
/*
 * Debug-check: all keys must be persistent!
-*/
-   if (!static_obj(lock->key)) {
+*/
+   if (IS_ERR(class)) {
debug_locks_off();
printk("INFO: trying to register non-static key.\n");
printk("the code is fine but needs lockdep annotation.\n");
printk("turning off the locking correctness validator.\n");
dump_stack();
-
return NULL;
}
 
@@ -3410,7 +3423,7 @@ static int match_held_lock(struct held_lock *hlock, 
struct lockde

Re: [PATCH v2 2/2] iio: stm32 trigger: Implement parent trigger feature

[Jonathan Cameron]

Hi All,

Would be really helpful to get some other input on this.
It's fiddly to put it lightly but if we get it right I think
the interface will be useful in all sorts of common cases.

On 16/02/17 14:23, Benjamin Gaignard wrote:
> Add validate_trigger function in iio_trigger_ops and
> dev_attr_parent_trigger into trigger attribute group to be able
> to accept triggers as parents.
> 
> Because the hardware have 8 different ways to use parent levels and
> edges, this patch introduce "slave_mode" sysfs attribute for stm32
> triggers. Modes usages are described in sysfs-bus-iio-timer-stm32
> 
> Signed-off-by: Benjamin Gaignard 
Hi Benjamin,

I'm increasingly convinced we need to be careful with the ABI
on this to end up with something generic. It's useful stuff, but
this particular hardware fuses various concepts based on them
being on the same wire taking no noticed of whether the hardware
upstream constrains what makes sense.

Rarely are those concepts independent of
what is actually wired to that signal so on a real system
it is a lot less flexible than the hardware on it's own might
imply.

This is really giving me a headache on a Sunday afternoon. 
I don't have a good answer (yet). I'd like to completely
separate the concepts but it is not obvious how to do it.

I appreciate that what I'm asking will make this driver more
complex, but I think we need to reflect accurately what the signals
are in order to not leave userspace with access to modes that make
absolutely no sense for a given hardware setup.

This is a bit rambling, but hopefully following through will
make sense...
> 
> version 2:
> - use dev_attr_parent_trigger
> - improve slave modes documentation
> ---
>  .../ABI/testing/sysfs-bus-iio-timer-stm32  |  43 +
>  drivers/iio/trigger/stm32-timer-trigger.c  | 105 
> +
>  2 files changed, 148 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 
> b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> index 6534a60..7d667f9 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
> @@ -27,3 +27,46 @@ Description:
>   Reading returns the current sampling frequency.
>   Writing an value different of 0 set and start sampling.
>   Writing 0 stop sampling.
> +
> +What:/sys/bus/iio/devices/triggerX/slave_mode_available
I think we need to drive this towards a generic description, whether that's 
easy or not.
This needs to be clear and extensible.
> +KernelVersion:   4.12
> +Contact: benjamin.gaign...@st.com
> +Description:
> + Reading returns the list possible slave modes which are:
> + - "disabled"  : Parent trigger levels or edges have do not 
> impact on trigger.
> + Trigger is clocked by the internal clock.
> + This is the default mode.
Don't bother with this first one.  The way to disable a parent trigger is to 
not have
one assigned.

Remember a trigger won't have any effect on anything until we have a buffer
actually using it so it doesn't matter what mode we come up in initially.
Let the default be anything as that will be easier for a generic interface.

> + - "encoder_1" : Trigger internal counter counts up/down on 
> channel 2 edge depending on channel 1 level.
> + - "encoder_2" : Trigger internal counter counts up/down on 
> channel 1 edge depending on channel 2 level.
> + - "encoder_3" : Trigger internal counter counts up/down on 
> channels 1 & 2 edge
> + depending on channel 1 & 2 level.
Conceptually these are clocks that are getting divided down. So the
child trigger has to have some concept of a divisor being applied.
We can then describe these, but it needs to be a truly generic
fashion which will be tricky.  In a sense, I'd expect these to be
properties of the parent trigger rather than how it is being used
by the child.

Hmm.  Not sure on this so would like other opinions.
The concept of triggers having two channels is somewhat of a stretch.

To my mind, whether the inputs are connected to an encoder and what type
it is should probably be a device tree property.  You wouldn't typically
pretend for some channels that you have an encoder and reset on other
channels.  So I think a trigger at the top level should be either
an encoder or not and it should know from DT what type it is.

This may be a pain to implement, but I think we need to do so.

> + - "reset" : Rising edge on parent trigger reinitializes the 
> trigger and generates
> + an update of auto-reload, prescaler and 
> repetition counter registers.
> + - "gated" : The trigger is enabled when the parent trigger 
> input is high.
> + The trigger stops (but is not reset) as soon as 
> the parent trig

Re: Crosstool/kbuild-all toolchain updates

[Guenter Roeck]

On 02/19/2017 05:26 AM, Fengguang Wu wrote:

Hi Stafford,

On Wed, Feb 01, 2017 at 07:44:38AM +0900, Stafford Horne wrote:

Hi Fengguang/All,

I am working as the OpenRISC linux kernel maintainer.  Currently in
linux-next our patches are causing kbuild test robot to fail.

This is because the patches are taking advantage of 2 'new' (2 year old)
instrucions (l.swa/l.lwa) and the build robots, as far as I can tell,
use the 'make.cross' [0] build script from lkp-tests.git.  These point
to the crosstools [1] toolchains maintained by Tony.

I sent a mail to Tony who maintains the crosstools but I didn't get a
reply and it seems he is not longer working on them [1].

I think our options are:

 1. Update 'make.cross' to point somewhere else for openrisc
 2. Update and maintain crosstools

For 1. its trvial but, maybe not the best solution.


It's a valuable patch, thank you!


For 2. I created new crosstool builds for openrisc [3]. The way the
crosstools are maintained is via a patches.tar file and it seem a custom
buildall script.  I dont see the source for that custom script anywhere.

I am thinking I could help to update and 'opensource' the crosstool
build scripts to make it easier for everyone to update toolchains by
sending patches.

But, I would need access to crosstool on kernel.org and an OK from
everyone.

Any opinions? Questions?


An uptodate crosstool and reasonable active maintainer would be very
welcome. I'll sure be a heavy user. In the past year when crosstool is
not updated to gcc-6, we've resorted to using debian packages for some
ARCHs and building our own cross compliers for the other ARCHs. The
latter are based on Segher's buildall tools (CCed). The private builds
may work for us in short term, however is obvious not a satisfactory
solution.



+1

Guenter

[PATCH] ocfs2: Add const to various occurrences of struct ocfs2_lock_res_ops

[Bhumika Goyal]

The field l_ops of structure ocfs2_lock_res can be made const as it
never modified after getting initialized. After making this change the
parameter struct ocfs2_lock_res_ops *ops of function
ocfs2_lock_res_init_common can be made const as ops is only stored
in l_ops. Now the structures of type ocfs2_lock_res_ops can be made
const as they are only passed as an argument to the above updated function.

Signed-off-by: Bhumika Goyal 
---
 fs/ocfs2/dlmglue.c | 26 +-
 fs/ocfs2/ocfs2.h   |  2 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 77d1632..885f200 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -233,12 +233,12 @@ struct ocfs2_lock_res_ops {
  */
 #define LOCK_TYPE_USES_LVB 0x2
 
-static struct ocfs2_lock_res_ops ocfs2_inode_rw_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_inode_rw_lops = {
.get_osb= ocfs2_get_inode_osb,
.flags  = 0,
 };
 
-static struct ocfs2_lock_res_ops ocfs2_inode_inode_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_inode_inode_lops = {
.get_osb= ocfs2_get_inode_osb,
.check_downconvert = ocfs2_check_meta_downconvert,
.set_lvb= ocfs2_set_meta_lvb,
@@ -246,46 +246,46 @@ struct ocfs2_lock_res_ops {
.flags  = LOCK_TYPE_REQUIRES_REFRESH|LOCK_TYPE_USES_LVB,
 };
 
-static struct ocfs2_lock_res_ops ocfs2_super_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_super_lops = {
.flags  = LOCK_TYPE_REQUIRES_REFRESH,
 };
 
-static struct ocfs2_lock_res_ops ocfs2_rename_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_rename_lops = {
.flags  = 0,
 };
 
-static struct ocfs2_lock_res_ops ocfs2_nfs_sync_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_nfs_sync_lops = {
.flags  = 0,
 };
 
-static struct ocfs2_lock_res_ops ocfs2_orphan_scan_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_orphan_scan_lops = {
.flags  = LOCK_TYPE_REQUIRES_REFRESH|LOCK_TYPE_USES_LVB,
 };
 
-static struct ocfs2_lock_res_ops ocfs2_dentry_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_dentry_lops = {
.get_osb= ocfs2_get_dentry_osb,
.post_unlock= ocfs2_dentry_post_unlock,
.downconvert_worker = ocfs2_dentry_convert_worker,
.flags  = 0,
 };
 
-static struct ocfs2_lock_res_ops ocfs2_inode_open_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_inode_open_lops = {
.get_osb= ocfs2_get_inode_osb,
.flags  = 0,
 };
 
-static struct ocfs2_lock_res_ops ocfs2_flock_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_flock_lops = {
.get_osb= ocfs2_get_file_osb,
.flags  = 0,
 };
 
-static struct ocfs2_lock_res_ops ocfs2_qinfo_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_qinfo_lops = {
.set_lvb= ocfs2_set_qinfo_lvb,
.get_osb= ocfs2_get_qinfo_osb,
.flags  = LOCK_TYPE_REQUIRES_REFRESH | LOCK_TYPE_USES_LVB,
 };
 
-static struct ocfs2_lock_res_ops ocfs2_refcount_block_lops = {
+static const struct ocfs2_lock_res_ops ocfs2_refcount_block_lops = {
.check_downconvert = ocfs2_check_refcount_downconvert,
.downconvert_worker = ocfs2_refcount_convert_worker,
.flags  = 0,
@@ -497,7 +497,7 @@ static inline void ocfs2_init_start_time(struct 
ocfs2_mask_waiter *mw)
 static void ocfs2_lock_res_init_common(struct ocfs2_super *osb,
   struct ocfs2_lock_res *res,
   enum ocfs2_lock_type type,
-  struct ocfs2_lock_res_ops *ops,
+  const struct ocfs2_lock_res_ops *ops,
   void *priv)
 {
res->l_type  = type;
@@ -539,7 +539,7 @@ void ocfs2_inode_lock_res_init(struct ocfs2_lock_res *res,
   unsigned int generation,
   struct inode *inode)
 {
-   struct ocfs2_lock_res_ops *ops;
+   const struct ocfs2_lock_res_ops *ops;
 
switch(type) {
case OCFS2_LOCK_TYPE_RW:
diff --git a/fs/ocfs2/ocfs2.h b/fs/ocfs2/ocfs2.h
index 7e5958b..691e0813 100644
--- a/fs/ocfs2/ocfs2.h
+++ b/fs/ocfs2/ocfs2.h
@@ -167,7 +167,7 @@ struct ocfs2_lock_stats {
 
 struct ocfs2_lock_res {
void*l_priv;
-   struct ocfs2_lock_res_ops *l_ops;
+   const struct ocfs2_lock_res_ops *l_ops;
 
 
struct list_head l_blocked_list;
-- 
1.9.1

Re: [PATCH 1/3] iio: humidity: add sht21 relative humidity and temperature sensor driver

[Jonathan Cameron]

On 19/02/17 15:04, Jonathan Cameron wrote:
> On 19/02/17 14:58, Tomasz Duszynski wrote:
>> Add sht21 relative humidity and temperature sensor driver. There already
>> exists an in-kernel driver under hwmon but with limited functionality
>> like humidity and temperature always measured together at predefined
>> resolutions, etc.
>>
>> New iio driver comes without limitations of predecessor, uses non-blocking 
>> i2c
>> communication mode and adds triggered buffer support thus is suited for more
>> use cases.
>>
>> Device datasheet can be found under:
>>
>> https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/ \
>> Dokumente/2_Humidity_Sensors/Sensirion_Humidity_Sensors_SHT21_Datasheet_V4.pdf
>>
>> Signed-off-by: Tomasz Duszynski 
> Hi Tomasz,
> 
> I haven't looked at this yet, but one thing we have to do whenever suggesting
> replacement of an hwmon driver is to convince the hwmon guys that it is a
> good idea.  
> 
> As such I've cc'd Guenter, Jean and the list.
> 
> Jonathan
> 
> p.s Probably won't get to this today as running out of time.  Depending on
> how mad the week is it might be next weekend before I get a chance.
Very quick review follows so as not to leave you without feedback.

I may well have missed stuff though as did this in a few minutes...

J
>> ---
>>  drivers/iio/humidity/Kconfig  |  10 +
>>  drivers/iio/humidity/Makefile |   1 +
>>  drivers/iio/humidity/sht21.c  | 519 
>> ++
>>  3 files changed, 530 insertions(+)
>>  create mode 100644 drivers/iio/humidity/sht21.c
>>
>> diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig
>> index 866dda16..93247ecc9324 100644
>> --- a/drivers/iio/humidity/Kconfig
>> +++ b/drivers/iio/humidity/Kconfig
>> @@ -35,6 +35,16 @@ config HTU21
>>This driver can also be built as a module. If so, the module will
>>be called htu21.
>>
>> +config SHT21
>> +tristate "Sensirion SHT21 relative humidity and temperature sensor"
>> +depends on I2C
>> +help
>> +  Say yes here to build support for the  Sensirion SHT21 relative
>> +  humidity and temperature sensor.
>> +
>> +  To compile this driver as a module, choose M here: the module
>> +  will be called sht21.
>> +
>>  config SI7005
>>  tristate "SI7005 relative humidity and temperature sensor"
>>  depends on I2C
>> diff --git a/drivers/iio/humidity/Makefile b/drivers/iio/humidity/Makefile
>> index c9f089a9a6b8..f2472fd2cc44 100644
>> --- a/drivers/iio/humidity/Makefile
>> +++ b/drivers/iio/humidity/Makefile
>> @@ -5,5 +5,6 @@
>>  obj-$(CONFIG_DHT11) += dht11.o
>>  obj-$(CONFIG_HDC100X) += hdc100x.o
>>  obj-$(CONFIG_HTU21) += htu21.o
>> +obj-$(CONFIG_SHT21) += sht21.o
>>  obj-$(CONFIG_SI7005) += si7005.o
>>  obj-$(CONFIG_SI7020) += si7020.o
>> diff --git a/drivers/iio/humidity/sht21.c b/drivers/iio/humidity/sht21.c
>> new file mode 100644
>> index ..199933b87297
>> --- /dev/null
>> +++ b/drivers/iio/humidity/sht21.c
>> @@ -0,0 +1,519 @@
>> +/*
>> + * Sensirion SHT21 relative humidity and temperature sensor driver
>> + *
>> + * Copyright (C) 2017 Tomasz Duszynski 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * 7-bit I2C slave address: 0x40
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define SHT21_DRV_NAME "sht21"
>> +
>> +#define SHT21_TRIGGER_T_MEASUREMENT 0xF3
>> +#define SHT21_TRIGGER_RH_MEASUREMENT 0xF5
>> +
>> +#define SHT21_WRITE_USER_REG 0xE6
>> +#define SHT21_READ_USER_REG 0xE7
>> +#define SHT21_SOFT_RESET 0xFE
>> +
>> +#define SHT21_USER_REG_RES_8_12 BIT(0)
>> +#define SHT21_USER_REG_RES_10_13 BIT(7)
>> +#define SHT21_USER_REG_RES_11_11 (BIT(7) | BIT(0))
>> +
>> +#define SHT21_USER_REG_ENABLE_HEATER BIT(2)
>> +
>> +enum {
>> +RES_12_14,
>> +RES_8_12,
>> +RES_10_13,
>> +RES_11_11,
>> +};
>> +
>> +/*
>> + * Combined sampling frequency i.e measuring RH and T together, which seems
>> + * to be common case for pressure/humidity sensors, was chosen so that 
>> sensor
>> + * is active for only 10% of time thus avoiding self-heating effect.
>> + *
>> + * Note that sampling frequencies are higher when measuring RH or T 
>> separately.
>> + *
>> + * Following table shows how available resolutions, combined sampling 
>> frequency
>> + * and frequencies for RH and T when measured separately are related.
>> + *
>> + * +---

Re: [PATCH 1/3] iio: humidity: add sht21 relative humidity and temperature sensor driver

[Guenter Roeck]

On 02/19/2017 07:04 AM, Jonathan Cameron wrote:

On 19/02/17 14:58, Tomasz Duszynski wrote:

Add sht21 relative humidity and temperature sensor driver. There already
exists an in-kernel driver under hwmon but with limited functionality
like humidity and temperature always measured together at predefined
resolutions, etc.

New iio driver comes without limitations of predecessor, uses non-blocking i2c
communication mode and adds triggered buffer support thus is suited for more
use cases.

Device datasheet can be found under:

https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/ \
Dokumente/2_Humidity_Sensors/Sensirion_Humidity_Sensors_SHT21_Datasheet_V4.pdf

Signed-off-by: Tomasz Duszynski 

Hi Tomasz,

I haven't looked at this yet, but one thing we have to do whenever suggesting
replacement of an hwmon driver is to convince the hwmon guys that it is a
good idea.

As such I've cc'd Guenter, Jean and the list.



I don't really have a strong opinion. The chip does not have limits,
so no core functionality is lost. Hope replacing a 200 LOC driver with
a 500 LOC driver is worth it. Point of concern may be that other Sensirion
drivers are in hwmon, so moving only this one over is not really optimal.
And newer chips (sht3x) _do_ have limits and alarms.

Please make sure to keep me in the loop, and please also add the functionality
currently being added to the hwmon driver (Electronic Identification Code
retrieval), as available in linux-next. I would also suggest to keep Sensirion
in the loop.

At some point we may want to more seriously discuss a hwmon->iio bridge.
Maybe it is just me, but it still seems to me that might make more sense
than rewriting drivers from scratch.

Guenter


Jonathan

p.s Probably won't get to this today as running out of time.  Depending on
how mad the week is it might be next weekend before I get a chance.

---
 drivers/iio/humidity/Kconfig  |  10 +
 drivers/iio/humidity/Makefile |   1 +
 drivers/iio/humidity/sht21.c  | 519 ++
 3 files changed, 530 insertions(+)
 create mode 100644 drivers/iio/humidity/sht21.c

diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig
index 866dda16..93247ecc9324 100644
--- a/drivers/iio/humidity/Kconfig
+++ b/drivers/iio/humidity/Kconfig
@@ -35,6 +35,16 @@ config HTU21
  This driver can also be built as a module. If so, the module will
  be called htu21.

+config SHT21
+   tristate "Sensirion SHT21 relative humidity and temperature sensor"
+   depends on I2C
+   help
+ Say yes here to build support for the  Sensirion SHT21 relative
+ humidity and temperature sensor.
+
+ To compile this driver as a module, choose M here: the module
+ will be called sht21.
+
 config SI7005
tristate "SI7005 relative humidity and temperature sensor"
depends on I2C
diff --git a/drivers/iio/humidity/Makefile b/drivers/iio/humidity/Makefile
index c9f089a9a6b8..f2472fd2cc44 100644
--- a/drivers/iio/humidity/Makefile
+++ b/drivers/iio/humidity/Makefile
@@ -5,5 +5,6 @@
 obj-$(CONFIG_DHT11) += dht11.o
 obj-$(CONFIG_HDC100X) += hdc100x.o
 obj-$(CONFIG_HTU21) += htu21.o
+obj-$(CONFIG_SHT21) += sht21.o
 obj-$(CONFIG_SI7005) += si7005.o
 obj-$(CONFIG_SI7020) += si7020.o
diff --git a/drivers/iio/humidity/sht21.c b/drivers/iio/humidity/sht21.c
new file mode 100644
index ..199933b87297
--- /dev/null
+++ b/drivers/iio/humidity/sht21.c
@@ -0,0 +1,519 @@
+/*
+ * Sensirion SHT21 relative humidity and temperature sensor driver
+ *
+ * Copyright (C) 2017 Tomasz Duszynski 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 7-bit I2C slave address: 0x40
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SHT21_DRV_NAME "sht21"
+
+#define SHT21_TRIGGER_T_MEASUREMENT 0xF3
+#define SHT21_TRIGGER_RH_MEASUREMENT 0xF5
+
+#define SHT21_WRITE_USER_REG 0xE6
+#define SHT21_READ_USER_REG 0xE7
+#define SHT21_SOFT_RESET 0xFE
+
+#define SHT21_USER_REG_RES_8_12 BIT(0)
+#define SHT21_USER_REG_RES_10_13 BIT(7)
+#define SHT21_USER_REG_RES_11_11 (BIT(7) | BIT(0))
+
+#define SHT21_USER_REG_ENABLE_HEATER BIT(2)
+
+enum {
+   RES_12_14,
+   RES_8_12,
+   RES_10_13,
+   RES_11_11,
+};
+
+/*
+ * Combined sampling frequency i.e measuring RH and T together, which seems
+ * to be common case for pressure/humidity sensors, was chosen so that sensor
+ * is active for only 10% of time thus avoiding 

Applied "ASoC: fix ES8328_I2C/SPI dependencies" to the asoc tree

[Mark Brown]

The patch

   ASoC: fix ES8328_I2C/SPI dependencies

has been applied to the asoc tree at

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

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

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

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

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

Thanks,
Mark

>From 245c5c7b0863eda23e8cb1907e74579a42185888 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann 
Date: Mon, 6 Feb 2017 13:27:11 +0100
Subject: [PATCH] ASoC: fix ES8328_I2C/SPI dependencies

The two front-ends to the codec can now be selected individually, but fail to
build when the bus support is missing:

sound/built-in.o: In function `es8328_spi_probe':
es8328-spi.c:(.text+0x125854): undefined reference to `__devm_regmap_init_spi'
sound/built-in.o: In function `es8328_spi_driver_init':
es8328-spi.c:(.init.text+0x3589): undefined reference to `__spi_register_driver'

Related to this, the added dependency on SND_SOC_ES8328 breaks:

warning: (SND_SOC_ALL_CODECS) selects SND_SOC_ES8328_I2C which has unmet direct 
dependencies (SOUND && !M68K && !UML && SND && SND_SOC && SND_SOC_ES8328 && I2C)

This adds the respective Kconfig dependencies and changes SND_SOC_ES8328 to a 
hidden
symbol that is selected implicitly by the two more specific options, as we do 
for
some other codecs. We have to remove the 'depends on' for SND_SOC_IMX_ES8328 in 
the
same step to avoid a recursive dependency.

Fixes: aa00f2c8aff7 ("ASoC: Allow to select ES8328_I2C and ES8328_SPI directly")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/Kconfig | 12 +++-
 sound/soc/fsl/Kconfig|  2 +-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index cfa423338963..0426e5c53829 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -525,15 +525,17 @@ config SND_SOC_HDMI_CODEC
select HDMI
 
 config SND_SOC_ES8328
-   tristate "Everest Semi ES8328 CODEC"
+   tristate
 
 config SND_SOC_ES8328_I2C
-   depends on SND_SOC_ES8328
-   tristate "I2C support for Everest Semi ES8328 CODEC"
+   tristate "Everest Semi ES8328 CODEC (I2C)"
+   depends on I2C
+   select SND_SOC_ES8328
 
 config SND_SOC_ES8328_SPI
-   depends on SND_SOC_ES8328
-   tristate "SPI support for Everest Semi ES8328 CODEC"
+   tristate "Everest Semi ES8328 CODEC (SPI)"
+   depends on SPI_MASTER
+   select SND_SOC_ES8328
 
 config SND_SOC_GTM601
tristate 'GTM601 UMTS modem audio codec'
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 0b914a1ca8d2..37f9b6201918 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -244,7 +244,7 @@ config SND_SOC_IMX_WM8962
 
 config SND_SOC_IMX_ES8328
tristate "SoC Audio support for i.MX boards with the ES8328 codec"
-   depends on OF && (I2C || SPI) && SND_SOC_ES8328
+   depends on OF && (I2C || SPI)
select SND_SOC_ES8328_I2C if I2C
select SND_SOC_ES8328_SPI if SPI_MASTER
select SND_SOC_IMX_PCM_DMA
-- 
2.11.0

Applied "spi: spi-ti-qspi: Fix error handling" to the spi tree

[Mark Brown]

The patch

   spi: spi-ti-qspi: Fix error handling

has been applied to the spi tree at

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

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

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

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

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

Thanks,
Mark

>From 7abfe04c47d97243a7aeeb8fe211a15687bff67f Mon Sep 17 00:00:00 2001
From: Christophe JAILLET 
Date: Sat, 18 Feb 2017 10:42:02 +0100
Subject: [PATCH] spi: spi-ti-qspi: Fix error handling

'dma_request_chan_by_mask()' can not return NULL.
Try to keep the logic in 'no_dma:' by resetting 'qspi->rx_chan' in case
of error.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-ti-qspi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index e784d0f64dc1..ad76a44fee6f 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -718,9 +718,10 @@ static int ti_qspi_probe(struct platform_device *pdev)
dma_cap_set(DMA_MEMCPY, mask);
 
qspi->rx_chan = dma_request_chan_by_mask(&mask);
-   if (!qspi->rx_chan) {
+   if (IS_ERR(qspi->rx_chan)) {
dev_err(qspi->dev,
"No Rx DMA available, trying mmap mode\n");
+   qspi->rx_chan = NULL;
ret = 0;
goto no_dma;
}
-- 
2.11.0

Applied "spi: spi-ti-qspi: Fix error handling" to the spi tree

[Mark Brown]

The patch

   spi: spi-ti-qspi: Fix error handling

has been applied to the spi tree at

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

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

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

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

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

Thanks,
Mark

>From 30fb27239f987c53429f24297f5d46e28d0e16ed Mon Sep 17 00:00:00 2001
From: Christophe JAILLET 
Date: Sat, 18 Feb 2017 10:42:02 +0100
Subject: [PATCH] spi: spi-ti-qspi: Fix error handling

'dma_request_chan_by_mask()' can not return NULL.
Try to keep the logic in 'no_dma:' by resetting 'qspi->rx_chan' in case
of error.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-ti-qspi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index ec6fb09e2e17..0fefa6423ff4 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -714,9 +714,10 @@ static int ti_qspi_probe(struct platform_device *pdev)
dma_cap_set(DMA_MEMCPY, mask);
 
qspi->rx_chan = dma_request_chan_by_mask(&mask);
-   if (!qspi->rx_chan) {
+   if (IS_ERR(qspi->rx_chan)) {
dev_err(qspi->dev,
"No Rx DMA available, trying mmap mode\n");
+   qspi->rx_chan = NULL;
ret = 0;
goto no_dma;
}
-- 
2.11.0

Applied "ASoC: sun4i-spdif: drop unnessary snd_soc_unregister_component()" to the asoc tree

[Mark Brown]

The patch

   ASoC: sun4i-spdif: drop unnessary snd_soc_unregister_component()

has been applied to the asoc tree at

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

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

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

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

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

Thanks,
Mark

>From c97c4604c008f3d489cc3201de80e313aeb501d6 Mon Sep 17 00:00:00 2001
From: Wei Yongjun 
Date: Mon, 6 Feb 2017 15:22:24 +
Subject: [PATCH] ASoC: sun4i-spdif: drop unnessary
 snd_soc_unregister_component()

It's not necessary to unregister a component registered
with devm_snd_soc_register_component(). Also removed
pointness clk_disable_unprepare() from error path and
snd_soc_unregister_platform() from the remove.

Fixes: f8260afa444b ("ASoC: sunxi: Add support for the SPDIF block")
Signed-off-by: Wei Yongjun 
Acked-by: Maxime Ripard 
Signed-off-by: Mark Brown 
---
 sound/soc/sunxi/sun4i-spdif.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
index c03cd07a9b19..eaefd07a5ed0 100644
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -510,8 +510,7 @@ static int sun4i_spdif_probe(struct platform_device *pdev)
host->spdif_clk = devm_clk_get(&pdev->dev, "spdif");
if (IS_ERR(host->spdif_clk)) {
dev_err(&pdev->dev, "failed to get a spdif clock.\n");
-   ret = PTR_ERR(host->spdif_clk);
-   goto err_disable_apb_clk;
+   return PTR_ERR(host->spdif_clk);
}
 
host->dma_params_tx.addr = res->start + quirks->reg_dac_txdata;
@@ -525,7 +524,7 @@ static int sun4i_spdif_probe(struct platform_device *pdev)
if (IS_ERR(host->rst) && PTR_ERR(host->rst) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
dev_err(&pdev->dev, "Failed to get reset: %d\n", ret);
-   goto err_disable_apb_clk;
+   return ret;
}
if (!IS_ERR(host->rst))
reset_control_deassert(host->rst);
@@ -534,7 +533,7 @@ static int sun4i_spdif_probe(struct platform_device *pdev)
ret = devm_snd_soc_register_component(&pdev->dev,
&sun4i_spdif_component, &sun4i_spdif_dai, 1);
if (ret)
-   goto err_disable_apb_clk;
+   return ret;
 
pm_runtime_enable(&pdev->dev);
if (!pm_runtime_enabled(&pdev->dev)) {
@@ -552,9 +551,6 @@ static int sun4i_spdif_probe(struct platform_device *pdev)
sun4i_spdif_runtime_suspend(&pdev->dev);
 err_unregister:
pm_runtime_disable(&pdev->dev);
-   snd_soc_unregister_component(&pdev->dev);
-err_disable_apb_clk:
-   clk_disable_unprepare(host->apb_clk);
return ret;
 }
 
@@ -564,9 +560,6 @@ static int sun4i_spdif_remove(struct platform_device *pdev)
if (!pm_runtime_status_suspended(&pdev->dev))
sun4i_spdif_runtime_suspend(&pdev->dev);
 
-   snd_soc_unregister_platform(&pdev->dev);
-   snd_soc_unregister_component(&pdev->dev);
-
return 0;
 }
 
-- 
2.11.0