Re: [PATCH] clarify how insecure CPU is

2018-03-03 Thread Thomas Gleixner
On Sat, 3 Mar 2018, Pavel Machek wrote:
> On Tue 2018-01-09 00:44:30, Thomas Gleixner wrote:
> > On Tue, 9 Jan 2018, Pavel Machek wrote:
> > 
> > > On Mon 2018-01-08 21:27:25, Thomas Gleixner wrote:
> > > > On Mon, 8 Jan 2018, Pavel Machek wrote:
> > > > 
> > > > > 
> > > > > First, what is going on with X86_BUG_AMD_E400 and X86_BUG_AMD_APIC_C1E
> > > > > ? They seem to refer to the same bug, perhaps comment should mention
> > > > > that? (Do we need two flags for one bug?)
> > > > > 
> > > > > Next, maybe X86_BUG_CPU_INSECURE is a bit too generic? This seems to
> > > > > address "Meltdown" problem, but not "Spectre". Should it be limited to
> > > > > PPro and newer Intel CPUs?
> > > > > 
> > > > > Should another erratum be added for "Spectre"? This is present even on
> > > > > AMD CPUs, but should not be present in 486, maybe Pentium, and some
> > > > > Atom chips?
> > > > > 
> > > > > Plus... is this reasonable interface?
> > > > > 
> > > > > bugs  : cpu_insecure
> > > > 
> > > > We've renamed it to meltdown already and added spectre_v1/v2 bits for 
> > > > the
> > > > rest of the mess.
> > > 
> > > Could you explain (best with code comment) what is going on with
> > > X86_BUG_AMD_E400 and X86_BUG_AMD_APIC_C1E ? They seem to refer to the
> > > same bug.
> > 
> > Sorry, that;s really not the time for this.
> 
> Ok, is there better time now? The code is a bit confusing...

What's confusing? Here are the relevant code snippets in invocation order.

/*
 * Check whether the machine is affected by erratum 400. This is
 * used to select the proper idle routine and to enable the check
 * whether the machine is affected in arch_post_acpi_init(), which
 * sets the X86_BUG_AMD_APIC_C1E bug depending on the MSR check.
 */
if (cpu_has_amd_erratum(c, amd_erratum_400))
set_cpu_bug(c, X86_BUG_AMD_E400);

This sets the errate 400 bug bit to tell subsequent code that the CPU might
be affected by that erratum.

void select_idle_routine(const struct cpuinfo_x86 *c)
{

if (boot_cpu_has_bug(X86_BUG_AMD_E400)) {
pr_info("using AMD E400 aware idle routine\n");
x86_idle = amd_e400_idle;

Selects the idle routine depending on the bug flag

void __init arch_post_acpi_subsys_init(void)
{
u32 lo, hi;

if (!boot_cpu_has_bug(X86_BUG_AMD_E400))
return;

/*
 * AMD E400 detection needs to happen after ACPI has been enabled. If
 * the machine is affected K8_INTP_C1E_ACTIVE_MASK bits are set in
 * MSR_K8_INT_PENDING_MSG.
 */
rdmsr(MSR_K8_INT_PENDING_MSG, lo, hi);
if (!(lo & K8_INTP_C1E_ACTIVE_MASK))
return;

Late detection whether C1E which halts TSC and APIC is enabled. This needs
to be done after ACPI is initialized.

/*
 * AMD Erratum 400 aware idle routine. We handle it the same way as C3 power
 * states (local apic timer and TSC stop).
 */
static void amd_e400_idle(void)
{
/*
 * We cannot use static_cpu_has_bug() here because X86_BUG_AMD_APIC_C1E
 * gets set after static_cpu_has() places have been converted via
 * alternatives.
 */
if (!boot_cpu_has_bug(X86_BUG_AMD_APIC_C1E)) {
default_idle();
return;
}

The actual idle routine. If the C1E bug flag is not set, CPU is not
affected, use default idle, otherwise handle it like other C-States which
stop TSC and APIC.


The comments are clear enough, but Feel free to send patches which enhance
them if you think thats necessary.

Thanks,

tglx


Re: [PATCH] clarify how insecure CPU is

2018-03-03 Thread Thomas Gleixner
On Sat, 3 Mar 2018, Pavel Machek wrote:
> On Tue 2018-01-09 00:44:30, Thomas Gleixner wrote:
> > On Tue, 9 Jan 2018, Pavel Machek wrote:
> > 
> > > On Mon 2018-01-08 21:27:25, Thomas Gleixner wrote:
> > > > On Mon, 8 Jan 2018, Pavel Machek wrote:
> > > > 
> > > > > 
> > > > > First, what is going on with X86_BUG_AMD_E400 and X86_BUG_AMD_APIC_C1E
> > > > > ? They seem to refer to the same bug, perhaps comment should mention
> > > > > that? (Do we need two flags for one bug?)
> > > > > 
> > > > > Next, maybe X86_BUG_CPU_INSECURE is a bit too generic? This seems to
> > > > > address "Meltdown" problem, but not "Spectre". Should it be limited to
> > > > > PPro and newer Intel CPUs?
> > > > > 
> > > > > Should another erratum be added for "Spectre"? This is present even on
> > > > > AMD CPUs, but should not be present in 486, maybe Pentium, and some
> > > > > Atom chips?
> > > > > 
> > > > > Plus... is this reasonable interface?
> > > > > 
> > > > > bugs  : cpu_insecure
> > > > 
> > > > We've renamed it to meltdown already and added spectre_v1/v2 bits for 
> > > > the
> > > > rest of the mess.
> > > 
> > > Could you explain (best with code comment) what is going on with
> > > X86_BUG_AMD_E400 and X86_BUG_AMD_APIC_C1E ? They seem to refer to the
> > > same bug.
> > 
> > Sorry, that;s really not the time for this.
> 
> Ok, is there better time now? The code is a bit confusing...

What's confusing? Here are the relevant code snippets in invocation order.

/*
 * Check whether the machine is affected by erratum 400. This is
 * used to select the proper idle routine and to enable the check
 * whether the machine is affected in arch_post_acpi_init(), which
 * sets the X86_BUG_AMD_APIC_C1E bug depending on the MSR check.
 */
if (cpu_has_amd_erratum(c, amd_erratum_400))
set_cpu_bug(c, X86_BUG_AMD_E400);

This sets the errate 400 bug bit to tell subsequent code that the CPU might
be affected by that erratum.

void select_idle_routine(const struct cpuinfo_x86 *c)
{

if (boot_cpu_has_bug(X86_BUG_AMD_E400)) {
pr_info("using AMD E400 aware idle routine\n");
x86_idle = amd_e400_idle;

Selects the idle routine depending on the bug flag

void __init arch_post_acpi_subsys_init(void)
{
u32 lo, hi;

if (!boot_cpu_has_bug(X86_BUG_AMD_E400))
return;

/*
 * AMD E400 detection needs to happen after ACPI has been enabled. If
 * the machine is affected K8_INTP_C1E_ACTIVE_MASK bits are set in
 * MSR_K8_INT_PENDING_MSG.
 */
rdmsr(MSR_K8_INT_PENDING_MSG, lo, hi);
if (!(lo & K8_INTP_C1E_ACTIVE_MASK))
return;

Late detection whether C1E which halts TSC and APIC is enabled. This needs
to be done after ACPI is initialized.

/*
 * AMD Erratum 400 aware idle routine. We handle it the same way as C3 power
 * states (local apic timer and TSC stop).
 */
static void amd_e400_idle(void)
{
/*
 * We cannot use static_cpu_has_bug() here because X86_BUG_AMD_APIC_C1E
 * gets set after static_cpu_has() places have been converted via
 * alternatives.
 */
if (!boot_cpu_has_bug(X86_BUG_AMD_APIC_C1E)) {
default_idle();
return;
}

The actual idle routine. If the C1E bug flag is not set, CPU is not
affected, use default idle, otherwise handle it like other C-States which
stop TSC and APIC.


The comments are clear enough, but Feel free to send patches which enhance
them if you think thats necessary.

Thanks,

tglx


Re: [PATCH] x86: devicetree: fix config option around x86_flattree_get_config()

2018-03-03 Thread Thomas Gleixner
On Sat, 3 Mar 2018, Frank Rowand wrote:
> I sent this patch to the x86 maintainers and to Rob because of a patch
> series that is modifying arch/x86/kernel/devicetree.c, in
> x86_flattree_get_config() [1].  It does not look like my patch will
> conflict with that patch at the moment, but it is possible that a conflict
> could develop as that patch is developed.

Even if it conflicts, its trivial enough 


Re: [PATCH] x86: devicetree: fix config option around x86_flattree_get_config()

2018-03-03 Thread Thomas Gleixner
On Sat, 3 Mar 2018, Frank Rowand wrote:
> I sent this patch to the x86 maintainers and to Rob because of a patch
> series that is modifying arch/x86/kernel/devicetree.c, in
> x86_flattree_get_config() [1].  It does not look like my patch will
> conflict with that patch at the moment, but it is possible that a conflict
> could develop as that patch is developed.

Even if it conflicts, its trivial enough 


Re: [PATCH v7 1/5] x86: devicetree: fix config option around x86_flattree_get_config()

2018-03-03 Thread Thomas Gleixner
On Sat, 3 Mar 2018, Frank Rowand wrote:

> On 03/03/18 16:17, frowand.l...@gmail.com wrote:
> > From: Frank Rowand 
> > 
> > x86_flattree_get_config() is incorrectly protected by
> > ifdef CONFIG_OF_FLATTREE.  It uses of_get_flat_dt_size(), which
> > only exists if CONFIG_OF_EARLY_FLATTREE.  This issue has not
> > been exposed previously because OF_FLATTREE did not occur unless
> > it was selected by OF_EARLY_FLATTREE.  A devicetree overlay change
> > is selecting OF_FLATTREE directly instead of indirectly enabling
> > it by selecting OF_EARLY_FLATTREE.
> > 
> > This problem was exposed by a randconfig generated by the kbuild
> > test robot, where Platform OLPC was enabled.  OLPC selects
> > OF_PROMTREE instead of OF_EARLY_FLATREE.  The only other x86
> > platform that selects OF is X86_INTEL_CE, which does select
> > OF_EARLY_FLATTREE.
> > 
> > Signed-off-by: Frank Rowand 
> > ---
> > 
> > x86 Maintainers, please ack this patch for Rob to accept

Acked-by: Thomas Gleixner 


Re: [PATCH v7 1/5] x86: devicetree: fix config option around x86_flattree_get_config()

2018-03-03 Thread Thomas Gleixner
On Sat, 3 Mar 2018, Frank Rowand wrote:

> On 03/03/18 16:17, frowand.l...@gmail.com wrote:
> > From: Frank Rowand 
> > 
> > x86_flattree_get_config() is incorrectly protected by
> > ifdef CONFIG_OF_FLATTREE.  It uses of_get_flat_dt_size(), which
> > only exists if CONFIG_OF_EARLY_FLATTREE.  This issue has not
> > been exposed previously because OF_FLATTREE did not occur unless
> > it was selected by OF_EARLY_FLATTREE.  A devicetree overlay change
> > is selecting OF_FLATTREE directly instead of indirectly enabling
> > it by selecting OF_EARLY_FLATTREE.
> > 
> > This problem was exposed by a randconfig generated by the kbuild
> > test robot, where Platform OLPC was enabled.  OLPC selects
> > OF_PROMTREE instead of OF_EARLY_FLATREE.  The only other x86
> > platform that selects OF is X86_INTEL_CE, which does select
> > OF_EARLY_FLATTREE.
> > 
> > Signed-off-by: Frank Rowand 
> > ---
> > 
> > x86 Maintainers, please ack this patch for Rob to accept

Acked-by: Thomas Gleixner 


[PATCH] memory-failure: fix section mismatch

2018-03-03 Thread Nick Desaulniers
Clang complains when a variable is declared extern twice, but with two
different sections. num_poisoned_pages is marked extern and __read_mostly
in include/linux/swapops.h, but only extern in include/linux/mm.h. Some
c source files must include both, and thus see the conflicting
declarations.

Signed-off-by: Nick Desaulniers 
---
 include/linux/mm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index ad06d42adb1a..bd4bd59f02c1 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2582,7 +2582,7 @@ extern int get_hwpoison_page(struct page *page);
 extern int sysctl_memory_failure_early_kill;
 extern int sysctl_memory_failure_recovery;
 extern void shake_page(struct page *p, int access);
-extern atomic_long_t num_poisoned_pages;
+extern atomic_long_t num_poisoned_pages __read_mostly;
 extern int soft_offline_page(struct page *page, int flags);
 
 
-- 
2.14.1



[PATCH] memory-failure: fix section mismatch

2018-03-03 Thread Nick Desaulniers
Clang complains when a variable is declared extern twice, but with two
different sections. num_poisoned_pages is marked extern and __read_mostly
in include/linux/swapops.h, but only extern in include/linux/mm.h. Some
c source files must include both, and thus see the conflicting
declarations.

Signed-off-by: Nick Desaulniers 
---
 include/linux/mm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index ad06d42adb1a..bd4bd59f02c1 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2582,7 +2582,7 @@ extern int get_hwpoison_page(struct page *page);
 extern int sysctl_memory_failure_early_kill;
 extern int sysctl_memory_failure_recovery;
 extern void shake_page(struct page *p, int access);
-extern atomic_long_t num_poisoned_pages;
+extern atomic_long_t num_poisoned_pages __read_mostly;
 extern int soft_offline_page(struct page *page, int flags);
 
 
-- 
2.14.1



RE: [PATCH net-next 1/5] net: mvpp2: use the same buffer pool for all ports

2018-03-03 Thread Stefan Chulski
> Hello,
> 
> On Fri,  2 Mar 2018 16:40:40 +0100, Antoine Tenart wrote:
> > +static struct {
> > +   int pkt_size;
> > +   int buf_num;
> > +} mvpp2_pools[MVPP2_BM_POOLS_NUM];
> 
> Any reason for not doing:
> 
> } mvpp2_pools[MVPP2_BM_POOLS_NUM] = {
>   [MVPP2_BM_SHORT] = {
>   .pkt_size = MVPP2_BM_SHORT_PKT_SIZE,
>   .buf_num = MVPP2_BM_SHORT_BUF_NUM
>   },
>   [MVPP2_BM_LONG] = {
>   .pkt_size = MVPP2_BM_LONG_PKT_SIZE,
>   .buf_num = MVPP2_BM_LONG_BUF_NUM,
>   },
> };
> 
> And get rid of:
> 
> > +static void mvpp2_setup_bm_pool(void) {
> > +   /* Short pool */
> > +   mvpp2_pools[MVPP2_BM_SHORT].buf_num  =
> MVPP2_BM_SHORT_BUF_NUM;
> > +   mvpp2_pools[MVPP2_BM_SHORT].pkt_size =
> MVPP2_BM_SHORT_PKT_SIZE;
> > +
> > +   /* Long pool */
> > +   mvpp2_pools[MVPP2_BM_LONG].buf_num  =
> MVPP2_BM_LONG_BUF_NUM;
> > +   mvpp2_pools[MVPP2_BM_LONG].pkt_size =
> MVPP2_BM_LONG_PKT_SIZE; }
> 
>  ?
> 

No, we can change it.

Stefan.


RE: [PATCH net-next 1/5] net: mvpp2: use the same buffer pool for all ports

2018-03-03 Thread Stefan Chulski
> Hello,
> 
> On Fri,  2 Mar 2018 16:40:40 +0100, Antoine Tenart wrote:
> > +static struct {
> > +   int pkt_size;
> > +   int buf_num;
> > +} mvpp2_pools[MVPP2_BM_POOLS_NUM];
> 
> Any reason for not doing:
> 
> } mvpp2_pools[MVPP2_BM_POOLS_NUM] = {
>   [MVPP2_BM_SHORT] = {
>   .pkt_size = MVPP2_BM_SHORT_PKT_SIZE,
>   .buf_num = MVPP2_BM_SHORT_BUF_NUM
>   },
>   [MVPP2_BM_LONG] = {
>   .pkt_size = MVPP2_BM_LONG_PKT_SIZE,
>   .buf_num = MVPP2_BM_LONG_BUF_NUM,
>   },
> };
> 
> And get rid of:
> 
> > +static void mvpp2_setup_bm_pool(void) {
> > +   /* Short pool */
> > +   mvpp2_pools[MVPP2_BM_SHORT].buf_num  =
> MVPP2_BM_SHORT_BUF_NUM;
> > +   mvpp2_pools[MVPP2_BM_SHORT].pkt_size =
> MVPP2_BM_SHORT_PKT_SIZE;
> > +
> > +   /* Long pool */
> > +   mvpp2_pools[MVPP2_BM_LONG].buf_num  =
> MVPP2_BM_LONG_BUF_NUM;
> > +   mvpp2_pools[MVPP2_BM_LONG].pkt_size =
> MVPP2_BM_LONG_PKT_SIZE; }
> 
>  ?
> 

No, we can change it.

Stefan.


RE: [PATCH net-next 5/5] net: mvpp2: jumbo frames support

2018-03-03 Thread Stefan Chulski
> > netdev_err(port->dev, "Invalid pool %d\n", pool);
> > return NULL;
> > }
> > @@ -4596,11 +4604,24 @@ mvpp2_bm_pool_use(struct mvpp2_port
> *port, int
> > pool, int pkt_size)  static int mvpp2_swf_bm_pool_init(struct
> > mvpp2_port *port)  {
> > int rxq;
> > +   enum mvpp2_bm_pool_log_num long_log_pool, short_log_pool;
> > +
> > +   /* If port pkt_size is higher than 1518B:
> > +* HW Long pool - SW Jumbo pool, HW Short pool - SW Short pool
> 
> The comment is wrong. In this case, the HW short pool is the SW long pool.

You right. Comment is wrong.

> > +   if (port->pool_long->id == MVPP2_BM_JUMBO && port->id != 0) {
> 
> Again, all over the place we hardcode the fact that Jumbo frames can only be
> used on port 0. I know port 0 is the only one that can do 10G, but are there
> possibly some use cases where you may want Jumbo frame on another port
> ?
> 
> This all really feels very hardcoded to me.
> 

All ports support Jumbo frames.
But only port 0 can do TX HW checksum offload(due to TX FIFO size).

Packet processor 2.2 has only 19KB TX FIFO size.
So in TX FIFO config code assign for Port 0 - 10KB, Port 1 - 3KB and Port 1 - 
3KB.

To perform checksum in HW, HW obviously should work in store and forward mode. 
Store all frame in TX FIFO and then check checksum.
If mtu 1500B, everything fine and all port can do this.

If mtu is 9KB and 9KB frame transmitted, Port 0 still can do HW checksum. But 
ports 1 and 2 doesn't has enough FIFO for this.
So we cannot offload this feature and SW should perform checksum.

> > +   /* 9704 == 9728 - 20 and rounding to 8 */
> > +   dev->max_mtu = MVPP2_BM_JUMBO_PKT_SIZE;
> 
> Is this correct for all ports ? Shouldn't the maximum MTU be different
> between port 0 (that supports Jumbo frames) and the other ports ?

This is correct for all ports. All ports can support Jumbo frames.

Stefan.


RE: [PATCH net-next 5/5] net: mvpp2: jumbo frames support

2018-03-03 Thread Stefan Chulski
> > netdev_err(port->dev, "Invalid pool %d\n", pool);
> > return NULL;
> > }
> > @@ -4596,11 +4604,24 @@ mvpp2_bm_pool_use(struct mvpp2_port
> *port, int
> > pool, int pkt_size)  static int mvpp2_swf_bm_pool_init(struct
> > mvpp2_port *port)  {
> > int rxq;
> > +   enum mvpp2_bm_pool_log_num long_log_pool, short_log_pool;
> > +
> > +   /* If port pkt_size is higher than 1518B:
> > +* HW Long pool - SW Jumbo pool, HW Short pool - SW Short pool
> 
> The comment is wrong. In this case, the HW short pool is the SW long pool.

You right. Comment is wrong.

> > +   if (port->pool_long->id == MVPP2_BM_JUMBO && port->id != 0) {
> 
> Again, all over the place we hardcode the fact that Jumbo frames can only be
> used on port 0. I know port 0 is the only one that can do 10G, but are there
> possibly some use cases where you may want Jumbo frame on another port
> ?
> 
> This all really feels very hardcoded to me.
> 

All ports support Jumbo frames.
But only port 0 can do TX HW checksum offload(due to TX FIFO size).

Packet processor 2.2 has only 19KB TX FIFO size.
So in TX FIFO config code assign for Port 0 - 10KB, Port 1 - 3KB and Port 1 - 
3KB.

To perform checksum in HW, HW obviously should work in store and forward mode. 
Store all frame in TX FIFO and then check checksum.
If mtu 1500B, everything fine and all port can do this.

If mtu is 9KB and 9KB frame transmitted, Port 0 still can do HW checksum. But 
ports 1 and 2 doesn't has enough FIFO for this.
So we cannot offload this feature and SW should perform checksum.

> > +   /* 9704 == 9728 - 20 and rounding to 8 */
> > +   dev->max_mtu = MVPP2_BM_JUMBO_PKT_SIZE;
> 
> Is this correct for all ports ? Shouldn't the maximum MTU be different
> between port 0 (that supports Jumbo frames) and the other ports ?

This is correct for all ports. All ports can support Jumbo frames.

Stefan.


[PATCH] certs/blacklist: fix const confusion

2018-03-03 Thread Nick Desaulniers
Fixes commit 2be04df5668d ("certs/blacklist_nohashes.c: fix const confusion
in certs blacklist")

Signed-off-by: Nick Desaulniers 
---
 certs/blacklist.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/certs/blacklist.h b/certs/blacklist.h
index 150d82da8e99..1efd6fa0dc60 100644
--- a/certs/blacklist.h
+++ b/certs/blacklist.h
@@ -1,3 +1,3 @@
 #include 
 
-extern const char __initdata *const blacklist_hashes[];
+extern const char __initconst *const blacklist_hashes[];
-- 
2.14.1



[PATCH] certs/blacklist: fix const confusion

2018-03-03 Thread Nick Desaulniers
Fixes commit 2be04df5668d ("certs/blacklist_nohashes.c: fix const confusion
in certs blacklist")

Signed-off-by: Nick Desaulniers 
---
 certs/blacklist.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/certs/blacklist.h b/certs/blacklist.h
index 150d82da8e99..1efd6fa0dc60 100644
--- a/certs/blacklist.h
+++ b/certs/blacklist.h
@@ -1,3 +1,3 @@
 #include 
 
-extern const char __initdata *const blacklist_hashes[];
+extern const char __initconst *const blacklist_hashes[];
-- 
2.14.1



RE: [PATCH net-next 3/5] net: mvpp2: use a data size of 10kB for Tx FIFO on port 0

2018-03-03 Thread Stefan Chulski

> On Fri,  2 Mar 2018 16:40:42 +0100, Antoine Tenart wrote:
> 
> > -/* Initialize Tx FIFO's */
> > +/* Initialize Tx FIFO's
> > + * The CP110's total tx-fifo size is 19kB.
> > + * Use large-size 10kB for fast port but 3kB for others.
> > + */
> 
> Is there a reason to hardcode 10KB for port 0, and 3KB for the other ports ?
> Would there be use cases where the user may want different configurations
> ?
> 

Design requirement are 10KB TX FIFO for the 10Gb/sec and 2.5KB for the 
2.5Gb/sec.
Since only port 0 support 10Gb/sec and ports 1&2 support up to 2.5Gb/sec.
I don't see any reason to change this configurations.
Also TX FIFO size could be set only during probe.

> It's just that it feels very "hardcoded" to enforce specifically those 
> numbers.
> 
> Also, does it make sense to mention the CP110 here ? Is this 19 KB limitation
> a limit of the PPv2.2 IP, or of the CP110 ?

PPv2.2 IP is part of 110 communication processor.
Next communication processor will has different Packet processor or next 
generation of PPv2.x
Limit is PPv2.2 TX FIFO.

Stefan.


RE: [PATCH net-next 3/5] net: mvpp2: use a data size of 10kB for Tx FIFO on port 0

2018-03-03 Thread Stefan Chulski

> On Fri,  2 Mar 2018 16:40:42 +0100, Antoine Tenart wrote:
> 
> > -/* Initialize Tx FIFO's */
> > +/* Initialize Tx FIFO's
> > + * The CP110's total tx-fifo size is 19kB.
> > + * Use large-size 10kB for fast port but 3kB for others.
> > + */
> 
> Is there a reason to hardcode 10KB for port 0, and 3KB for the other ports ?
> Would there be use cases where the user may want different configurations
> ?
> 

Design requirement are 10KB TX FIFO for the 10Gb/sec and 2.5KB for the 
2.5Gb/sec.
Since only port 0 support 10Gb/sec and ports 1&2 support up to 2.5Gb/sec.
I don't see any reason to change this configurations.
Also TX FIFO size could be set only during probe.

> It's just that it feels very "hardcoded" to enforce specifically those 
> numbers.
> 
> Also, does it make sense to mention the CP110 here ? Is this 19 KB limitation
> a limit of the PPv2.2 IP, or of the CP110 ?

PPv2.2 IP is part of 110 communication processor.
Next communication processor will has different Packet processor or next 
generation of PPv2.x
Limit is PPv2.2 TX FIFO.

Stefan.


Re: [PATCH 0/7] fujitsu-laptop: Consistent naming of constants

2018-03-03 Thread Jonathan Woithe
Hi Michal

On Tue, Feb 27, 2018 at 10:15:32PM +0100, Micha?? K??pie?? wrote:
> This patch series is an attempt to organize all the named constants used
> throughout fujitsu-laptop so that their names more clearly convey their
> purpose: a set of prefixes is introduced to "map" constant names to
> call_fext_func() parameters.

While fairly superficial in nature I think this patch set is worthwhile. 
Features have been progressively added to fujitsu-laptop over the last 10 or
so years from a number of sources but a consistent naming methodology for
constants has not emerged.  Having at least some consistency across the
constant names will help clarify the intent of the code.

> Some changes (like those in patches 4/7 and 5/7) may be perceived as
> bikeshedding, so please just think of them as proposals, not fixes.

Patches 4 and 5 don't bother me within the context of the patch series as a
whole.

> Finally, patch 7/7 again [1] proposes a set of helper functions which
> seem to be making quite a difference in terms of code readability in
> certain places (especially in long conditional expressions).  YMMV,
> though, feel free to disagree.

As before, I can't see any strong arguments one way or the other.  The
helper functions certainly save a line in many of the call sites, but
whether they provide significant advantages I cannot say (I personally have
no fundamental problems with either version).  I guess if pushed I'd
probably come down on the side of leaving things as they are: in principle
defining a bunch of thin wrapper functions to save one parameter isn't
something I tend to do since it doesn't seem worth it.  However, what has
changed since the last iteration of this idea is the use of identifiers
rather than numbers for many of call_fext_func()'s parameters, which adds
length to each call site.

If there is general agreement that using these functions is beneficial in
this context I certainly won't block it.

Regards
  jonathan


Re: [PATCH 0/7] fujitsu-laptop: Consistent naming of constants

2018-03-03 Thread Jonathan Woithe
Hi Michal

On Tue, Feb 27, 2018 at 10:15:32PM +0100, Micha?? K??pie?? wrote:
> This patch series is an attempt to organize all the named constants used
> throughout fujitsu-laptop so that their names more clearly convey their
> purpose: a set of prefixes is introduced to "map" constant names to
> call_fext_func() parameters.

While fairly superficial in nature I think this patch set is worthwhile. 
Features have been progressively added to fujitsu-laptop over the last 10 or
so years from a number of sources but a consistent naming methodology for
constants has not emerged.  Having at least some consistency across the
constant names will help clarify the intent of the code.

> Some changes (like those in patches 4/7 and 5/7) may be perceived as
> bikeshedding, so please just think of them as proposals, not fixes.

Patches 4 and 5 don't bother me within the context of the patch series as a
whole.

> Finally, patch 7/7 again [1] proposes a set of helper functions which
> seem to be making quite a difference in terms of code readability in
> certain places (especially in long conditional expressions).  YMMV,
> though, feel free to disagree.

As before, I can't see any strong arguments one way or the other.  The
helper functions certainly save a line in many of the call sites, but
whether they provide significant advantages I cannot say (I personally have
no fundamental problems with either version).  I guess if pushed I'd
probably come down on the side of leaving things as they are: in principle
defining a bunch of thin wrapper functions to save one parameter isn't
something I tend to do since it doesn't seem worth it.  However, what has
changed since the last iteration of this idea is the use of identifiers
rather than numbers for many of call_fext_func()'s parameters, which adds
length to each call site.

If there is general agreement that using these functions is beneficial in
this context I certainly won't block it.

Regards
  jonathan


Re: [PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for FUNC operations

2018-03-03 Thread Jonathan Woithe
On Wed, Feb 28, 2018 at 06:08:52PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 27, 2018 at 11:15 PM, Micha?? K??pie??  wrote:
> > Various functions exposed by the firmware through the FUNC interface
> > tend to use a consistent set of integers for denoting the type of
> > operation to be performed for a specified feature.  Use named constants
> > instead of integers in each call_fext_func() invocation in order to more
> > clearly convey the intent of each call.
> >
> > Note that FUNC_FLAGS is a bit peculiar:
> 
> > +/* FUNC interface - operations */
> > +#define OP_GET BIT(1)
> > +#define OP_GET_CAPS0
> > +#define OP_GET_EVENTS  BIT(0)
> > +#define OP_GET_EXT BIT(2)
> > +#define OP_SET BIT(0)
> > +#define OP_SET_EXT (BIT(2) | BIT(0))
> 
> Hmm... this looks unordered a bit.

It seems to be ordered alphabetically on the identifier.  Andy, is it
preferred to order defines like this based on resolved numeric order?

There is a lack of apparent consistency in the numeric mapping; for example,
OP_SET_EXT includes the OP_SET bit, but OP_GET_EXT does not include the
OP_GET bit.  However, after inspecting the code I think this is simply
reflecting what the hardware expects.

> And plain 0 doesn't look right in this concept (something like (0 <<
> 0) would probably do it).

Given that all other definitions are in terms of BIT(), to my eye "(0 << 0)"
looks as much out of place as plain "0".  However, if the convention in this
case would be to use the former then I have no objections.  I presume the
"(0 << 0)" idea comes from the fact that BIT() ultimately expands to some
form of shift.

Regards
  jonathan


Re: [PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for FUNC operations

2018-03-03 Thread Jonathan Woithe
On Wed, Feb 28, 2018 at 06:08:52PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 27, 2018 at 11:15 PM, Micha?? K??pie??  wrote:
> > Various functions exposed by the firmware through the FUNC interface
> > tend to use a consistent set of integers for denoting the type of
> > operation to be performed for a specified feature.  Use named constants
> > instead of integers in each call_fext_func() invocation in order to more
> > clearly convey the intent of each call.
> >
> > Note that FUNC_FLAGS is a bit peculiar:
> 
> > +/* FUNC interface - operations */
> > +#define OP_GET BIT(1)
> > +#define OP_GET_CAPS0
> > +#define OP_GET_EVENTS  BIT(0)
> > +#define OP_GET_EXT BIT(2)
> > +#define OP_SET BIT(0)
> > +#define OP_SET_EXT (BIT(2) | BIT(0))
> 
> Hmm... this looks unordered a bit.

It seems to be ordered alphabetically on the identifier.  Andy, is it
preferred to order defines like this based on resolved numeric order?

There is a lack of apparent consistency in the numeric mapping; for example,
OP_SET_EXT includes the OP_SET bit, but OP_GET_EXT does not include the
OP_GET bit.  However, after inspecting the code I think this is simply
reflecting what the hardware expects.

> And plain 0 doesn't look right in this concept (something like (0 <<
> 0) would probably do it).

Given that all other definitions are in terms of BIT(), to my eye "(0 << 0)"
looks as much out of place as plain "0".  However, if the convention in this
case would be to use the former then I have no objections.  I presume the
"(0 << 0)" idea comes from the fact that BIT() ultimately expands to some
form of shift.

Regards
  jonathan


[PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node

2018-03-03 Thread Haiyue Wang
The IPMI KCS device part of the LPC interface and is used for
communication with the host processor.

Signed-off-by: Haiyue Wang 
---
Hi Joel & Andrew,

The kcs-bmc-aspeed module has been in:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/char/ipmi/kcs_bmc_aspeed.c
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt

I updated the device tree node about kcs-bmc, this is passed on my board.

And the patch is generated by rebasing on:
https://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
Please help to review.

BR,
Haiyue
---
 arch/arm/boot/dts/aspeed-g5.dtsi | 43 +++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 8eac57c..f443169 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -267,8 +267,40 @@
ranges = <0x0 0x1e789000 0x1000>;
 
lpc_bmc: lpc-bmc@0 {
-   compatible = "aspeed,ast2500-lpc-bmc";
+   compatible = "aspeed,ast2500-lpc-bmc", 
"simple-mfd", "syscon";
reg = <0x0 0x80>;
+   reg-io-width = <4>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x80>;
+
+   kcs1: kcs1@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0x80>;
+   interrupts = <8>;
+   kcs_chan = <1>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
+
+   kcs2: kcs2@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0x80>;
+   interrupts = <8>;
+   kcs_chan = <2>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
+
+   kcs3: kcs3@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0x80>;
+   interrupts = <8>;
+   kcs_chan = <3>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
};
 
lpc_host: lpc-host@80 {
@@ -294,6 +326,15 @@
status = "disabled";
};
 
+   kcs4: kcs4@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0xa0>;
+   interrupts = <8>;
+   kcs_chan = <4>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
+
lhc: lhc@20 {
compatible = 
"aspeed,ast2500-lhc";
reg = <0x20 0x24 0x48 0x8>;
-- 
2.7.4



[PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node

2018-03-03 Thread Haiyue Wang
The IPMI KCS device part of the LPC interface and is used for
communication with the host processor.

Signed-off-by: Haiyue Wang 
---
Hi Joel & Andrew,

The kcs-bmc-aspeed module has been in:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/char/ipmi/kcs_bmc_aspeed.c
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt

I updated the device tree node about kcs-bmc, this is passed on my board.

And the patch is generated by rebasing on:
https://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
Please help to review.

BR,
Haiyue
---
 arch/arm/boot/dts/aspeed-g5.dtsi | 43 +++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 8eac57c..f443169 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -267,8 +267,40 @@
ranges = <0x0 0x1e789000 0x1000>;
 
lpc_bmc: lpc-bmc@0 {
-   compatible = "aspeed,ast2500-lpc-bmc";
+   compatible = "aspeed,ast2500-lpc-bmc", 
"simple-mfd", "syscon";
reg = <0x0 0x80>;
+   reg-io-width = <4>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x80>;
+
+   kcs1: kcs1@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0x80>;
+   interrupts = <8>;
+   kcs_chan = <1>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
+
+   kcs2: kcs2@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0x80>;
+   interrupts = <8>;
+   kcs_chan = <2>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
+
+   kcs3: kcs3@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0x80>;
+   interrupts = <8>;
+   kcs_chan = <3>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
};
 
lpc_host: lpc-host@80 {
@@ -294,6 +326,15 @@
status = "disabled";
};
 
+   kcs4: kcs4@0 {
+   compatible = 
"aspeed,ast2500-kcs-bmc";
+   reg = <0x0 0xa0>;
+   interrupts = <8>;
+   kcs_chan = <4>;
+   kcs_addr = <0x0>;
+   status = "disabled";
+   };
+
lhc: lhc@20 {
compatible = 
"aspeed,ast2500-lhc";
reg = <0x20 0x24 0x48 0x8>;
-- 
2.7.4



Re: [PATCH v4 16/22] nvmem: meson-efuse: Do no gate COMPILE_TEST with MESON_SM

2018-03-03 Thread kbuild test robot
Hi Andrey,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc3 next-20180302]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrey-Smirnov/Verbatim-device-names-and-devm_nvmem_-un-register/20180303-220801
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   drivers/nvmem/meson-efuse.o: In function `meson_efuse_read':
>> meson-efuse.c:(.text+0x28): undefined reference to `meson_sm_call_read'
   drivers/nvmem/meson-efuse.o: In function `meson_efuse_probe':
>> meson-efuse.c:(.text+0x64): undefined reference to `meson_sm_call'

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


.config.gz
Description: application/gzip


Re: [RFC PATCH] Randomization of address chosen by mmap.

2018-03-03 Thread Matthew Wilcox
On Sat, Mar 03, 2018 at 04:00:45PM -0500, Daniel Micay wrote:
> The main thing I'd like to see is just the option to get a guarantee
> of enforced gaps around mappings, without necessarily even having
> randomization of the gap size. It's possible to add guard pages in
> userspace but it adds overhead by doubling the number of system calls
> to map memory (mmap PROT_NONE region, mprotect the inner portion to
> PROT_READ|PROT_WRITE) and *everything* using mmap would need to
> cooperate which is unrealistic.

So something like this?

To use it, OR in PROT_GUARD(n) to the PROT flags of mmap, and it should
pad the map by n pages.  I haven't tested it, so I'm sure it's buggy,
but it seems like a fairly cheap way to give us padding after every
mapping.

Running it on an old kernel will result in no padding, so to see if it
worked or not, try mapping something immediately after it.

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 4ef7fb1726ab..9da6df7f62fc 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2183,8 +2183,8 @@ extern int install_special_mapping(struct mm_struct *mm,
 extern unsigned long get_unmapped_area(struct file *, unsigned long, unsigned 
long, unsigned long, unsigned long);
 
 extern unsigned long mmap_region(struct file *file, unsigned long addr,
-   unsigned long len, vm_flags_t vm_flags, unsigned long pgoff,
-   struct list_head *uf);
+   unsigned long len, unsigned long pad_len, vm_flags_t vm_flags,
+   unsigned long pgoff, struct list_head *uf);
 extern unsigned long do_mmap(struct file *file, unsigned long addr,
unsigned long len, unsigned long prot, unsigned long flags,
vm_flags_t vm_flags, unsigned long pgoff, unsigned long *populate,
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 1c5dea402501..9c2b66fa0561 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -299,6 +299,7 @@ struct vm_area_struct {
struct mm_struct *vm_mm;/* The address space we belong to. */
pgprot_t vm_page_prot;  /* Access permissions of this VMA. */
unsigned long vm_flags; /* Flags, see mm.h. */
+   unsigned int vm_guard;  /* Number of trailing guard pages */
 
/*
 * For areas with an address space and backing store,
diff --git a/include/uapi/asm-generic/mman-common.h 
b/include/uapi/asm-generic/mman-common.h
index f8b134f5608f..d88babdf97f9 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -12,6 +12,7 @@
 #define PROT_EXEC  0x4 /* page can be executed */
 #define PROT_SEM   0x8 /* page may be used for atomic ops */
 #define PROT_NONE  0x0 /* page can not be accessed */
+#define PROT_GUARD(x)  ((x) & 0x) << 4 /* guard pages */
 #define PROT_GROWSDOWN 0x0100  /* mprotect flag: extend change to 
start of growsdown vma */
 #define PROT_GROWSUP   0x0200  /* mprotect flag: extend change to end 
of growsup vma */
 
diff --git a/mm/memory.c b/mm/memory.c
index 1cfc4699db42..5b0f87afa0af 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4125,6 +4125,9 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned 
long address,
flags & FAULT_FLAG_REMOTE))
return VM_FAULT_SIGSEGV;
 
+   if (DIV_ROUND_UP(vma->vm_end - address, PAGE_SIZE) < vma->vm_guard)
+   return VM_FAULT_SIGSEGV;
+
/*
 * Enable the memcg OOM handling for faults triggered in user
 * space.  Kernel faults are handled more gracefully.
diff --git a/mm/mmap.c b/mm/mmap.c
index 575766ec02f8..b9844b810ee7 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1433,6 +1433,7 @@ unsigned long do_mmap(struct file *file, unsigned long 
addr,
unsigned long pgoff, unsigned long *populate,
struct list_head *uf)
 {
+   unsigned int guard_len = ((prot >> 4) & 0x) << PAGE_SHIFT;
struct mm_struct *mm = current->mm;
int pkey = 0;
 
@@ -1458,6 +1459,8 @@ unsigned long do_mmap(struct file *file, unsigned long 
addr,
len = PAGE_ALIGN(len);
if (!len)
return -ENOMEM;
+   if (len + guard_len < len)
+   return -ENOMEM;
 
/* offset overflow? */
if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
@@ -1472,7 +1475,7 @@ unsigned long do_mmap(struct file *file, unsigned long 
addr,
/* Obtain the address to map to. we verify (or select) it and ensure
 * that it represents a valid section of the address space.
 */
-   addr = get_unmapped_area(file, addr, len, pgoff, flags);
+   addr = get_unmapped_area(file, addr, len + guard_len, pgoff, flags);
if (offset_in_page(addr))
return addr;
 
@@ -1591,7 +1594,7 @@ unsigned long do_mmap(struct file *file, unsigned long 
addr,
vm_flags |= VM_NORESERVE;
}
 
-   

Re: [PATCH v4 16/22] nvmem: meson-efuse: Do no gate COMPILE_TEST with MESON_SM

2018-03-03 Thread kbuild test robot
Hi Andrey,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc3 next-20180302]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrey-Smirnov/Verbatim-device-names-and-devm_nvmem_-un-register/20180303-220801
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   `.exit.data' referenced in section `.exit.text' of drivers/tty/n_hdlc.o: 
defined in discarded section `.exit.data' of drivers/tty/n_hdlc.o
   drivers/nvmem/meson-efuse.o: In function `meson_efuse_read':
>> meson-efuse.c:(.text+0x28): undefined reference to `meson_sm_call_read'
   drivers/nvmem/meson-efuse.o: In function `meson_efuse_probe':
>> meson-efuse.c:(.text+0x64): undefined reference to `meson_sm_call'

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


.config.gz
Description: application/gzip


Re: [RFC PATCH] Randomization of address chosen by mmap.

2018-03-03 Thread Matthew Wilcox
On Sat, Mar 03, 2018 at 04:00:45PM -0500, Daniel Micay wrote:
> The main thing I'd like to see is just the option to get a guarantee
> of enforced gaps around mappings, without necessarily even having
> randomization of the gap size. It's possible to add guard pages in
> userspace but it adds overhead by doubling the number of system calls
> to map memory (mmap PROT_NONE region, mprotect the inner portion to
> PROT_READ|PROT_WRITE) and *everything* using mmap would need to
> cooperate which is unrealistic.

So something like this?

To use it, OR in PROT_GUARD(n) to the PROT flags of mmap, and it should
pad the map by n pages.  I haven't tested it, so I'm sure it's buggy,
but it seems like a fairly cheap way to give us padding after every
mapping.

Running it on an old kernel will result in no padding, so to see if it
worked or not, try mapping something immediately after it.

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 4ef7fb1726ab..9da6df7f62fc 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2183,8 +2183,8 @@ extern int install_special_mapping(struct mm_struct *mm,
 extern unsigned long get_unmapped_area(struct file *, unsigned long, unsigned 
long, unsigned long, unsigned long);
 
 extern unsigned long mmap_region(struct file *file, unsigned long addr,
-   unsigned long len, vm_flags_t vm_flags, unsigned long pgoff,
-   struct list_head *uf);
+   unsigned long len, unsigned long pad_len, vm_flags_t vm_flags,
+   unsigned long pgoff, struct list_head *uf);
 extern unsigned long do_mmap(struct file *file, unsigned long addr,
unsigned long len, unsigned long prot, unsigned long flags,
vm_flags_t vm_flags, unsigned long pgoff, unsigned long *populate,
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 1c5dea402501..9c2b66fa0561 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -299,6 +299,7 @@ struct vm_area_struct {
struct mm_struct *vm_mm;/* The address space we belong to. */
pgprot_t vm_page_prot;  /* Access permissions of this VMA. */
unsigned long vm_flags; /* Flags, see mm.h. */
+   unsigned int vm_guard;  /* Number of trailing guard pages */
 
/*
 * For areas with an address space and backing store,
diff --git a/include/uapi/asm-generic/mman-common.h 
b/include/uapi/asm-generic/mman-common.h
index f8b134f5608f..d88babdf97f9 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -12,6 +12,7 @@
 #define PROT_EXEC  0x4 /* page can be executed */
 #define PROT_SEM   0x8 /* page may be used for atomic ops */
 #define PROT_NONE  0x0 /* page can not be accessed */
+#define PROT_GUARD(x)  ((x) & 0x) << 4 /* guard pages */
 #define PROT_GROWSDOWN 0x0100  /* mprotect flag: extend change to 
start of growsdown vma */
 #define PROT_GROWSUP   0x0200  /* mprotect flag: extend change to end 
of growsup vma */
 
diff --git a/mm/memory.c b/mm/memory.c
index 1cfc4699db42..5b0f87afa0af 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4125,6 +4125,9 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned 
long address,
flags & FAULT_FLAG_REMOTE))
return VM_FAULT_SIGSEGV;
 
+   if (DIV_ROUND_UP(vma->vm_end - address, PAGE_SIZE) < vma->vm_guard)
+   return VM_FAULT_SIGSEGV;
+
/*
 * Enable the memcg OOM handling for faults triggered in user
 * space.  Kernel faults are handled more gracefully.
diff --git a/mm/mmap.c b/mm/mmap.c
index 575766ec02f8..b9844b810ee7 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1433,6 +1433,7 @@ unsigned long do_mmap(struct file *file, unsigned long 
addr,
unsigned long pgoff, unsigned long *populate,
struct list_head *uf)
 {
+   unsigned int guard_len = ((prot >> 4) & 0x) << PAGE_SHIFT;
struct mm_struct *mm = current->mm;
int pkey = 0;
 
@@ -1458,6 +1459,8 @@ unsigned long do_mmap(struct file *file, unsigned long 
addr,
len = PAGE_ALIGN(len);
if (!len)
return -ENOMEM;
+   if (len + guard_len < len)
+   return -ENOMEM;
 
/* offset overflow? */
if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
@@ -1472,7 +1475,7 @@ unsigned long do_mmap(struct file *file, unsigned long 
addr,
/* Obtain the address to map to. we verify (or select) it and ensure
 * that it represents a valid section of the address space.
 */
-   addr = get_unmapped_area(file, addr, len, pgoff, flags);
+   addr = get_unmapped_area(file, addr, len + guard_len, pgoff, flags);
if (offset_in_page(addr))
return addr;
 
@@ -1591,7 +1594,7 @@ unsigned long do_mmap(struct file *file, unsigned long 
addr,
vm_flags |= VM_NORESERVE;
}
 
-   

[PATCH 1/3] net: core: dst_cache: Fix a typo in a comment

2018-03-03 Thread Jonathan Neuschäfer
Signed-off-by: Jonathan Neuschäfer 
---
 include/net/dst_cache.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/dst_cache.h b/include/net/dst_cache.h
index 72fd5067c353..844906fbf8c9 100644
--- a/include/net/dst_cache.h
+++ b/include/net/dst_cache.h
@@ -71,7 +71,7 @@ struct dst_entry *dst_cache_get_ip6(struct dst_cache 
*dst_cache,
  * dst_cache_reset - invalidate the cache contents
  * @dst_cache: the cache
  *
- * This do not free the cached dst to avoid races and contentions.
+ * This does not free the cached dst to avoid races and contentions.
  * the dst will be freed on later cache lookup.
  */
 static inline void dst_cache_reset(struct dst_cache *dst_cache)
-- 
2.16.1



[PATCH 1/3] net: core: dst_cache: Fix a typo in a comment

2018-03-03 Thread Jonathan Neuschäfer
Signed-off-by: Jonathan Neuschäfer 
---
 include/net/dst_cache.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/dst_cache.h b/include/net/dst_cache.h
index 72fd5067c353..844906fbf8c9 100644
--- a/include/net/dst_cache.h
+++ b/include/net/dst_cache.h
@@ -71,7 +71,7 @@ struct dst_entry *dst_cache_get_ip6(struct dst_cache 
*dst_cache,
  * dst_cache_reset - invalidate the cache contents
  * @dst_cache: the cache
  *
- * This do not free the cached dst to avoid races and contentions.
+ * This does not free the cached dst to avoid races and contentions.
  * the dst will be freed on later cache lookup.
  */
 static inline void dst_cache_reset(struct dst_cache *dst_cache)
-- 
2.16.1



[PATCH 3/3] net: core: dst: Add kernel-doc for 'net' parameter

2018-03-03 Thread Jonathan Neuschäfer
This fixes the following kernel-doc warning:

./include/net/dst.h:366: warning: Function parameter or member 'net' not 
described in 'skb_tunnel_rx'

Fixes: ea23192e8e57 ("tunnels: harmonize cleanup done on skb on rx path")
Signed-off-by: Jonathan Neuschäfer 
---
 include/net/dst.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/net/dst.h b/include/net/dst.h
index c63d2c37f6e9..b3219cd8a5a1 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -356,6 +356,7 @@ static inline void __skb_tunnel_rx(struct sk_buff *skb, 
struct net_device *dev,
  * skb_tunnel_rx - prepare skb for rx reinsert
  * @skb: buffer
  * @dev: tunnel device
+ * @net: netns for packet i/o
  *
  * After decapsulation, packet is going to re-enter (netif_rx()) our stack,
  * so make some cleanups, and perform accounting.
-- 
2.16.1



[PATCH 2/3] net: core: dst_cache_set_ip6: Rename 'addr' parameter to 'saddr' for consistency

2018-03-03 Thread Jonathan Neuschäfer
The other dst_cache_{get,set}_ip{4,6} functions, and the doc comment for
dst_cache_set_ip6 use 'saddr' for their source address parameter. Rename
the parameter to increase consistency.

This fixes the following kernel-doc warnings:

./include/net/dst_cache.h:58: warning: Function parameter or member 'addr' not 
described in 'dst_cache_set_ip6'
./include/net/dst_cache.h:58: warning: Excess function parameter 'saddr' 
description in 'dst_cache_set_ip6'

Fixes: 911362c70df5 ("net: add dst_cache support")
Signed-off-by: Jonathan Neuschäfer 
---
 include/net/dst_cache.h | 2 +-
 net/core/dst_cache.c| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/net/dst_cache.h b/include/net/dst_cache.h
index 844906fbf8c9..67634675e919 100644
--- a/include/net/dst_cache.h
+++ b/include/net/dst_cache.h
@@ -54,7 +54,7 @@ void dst_cache_set_ip4(struct dst_cache *dst_cache, struct 
dst_entry *dst,
  * local BH must be disabled.
  */
 void dst_cache_set_ip6(struct dst_cache *dst_cache, struct dst_entry *dst,
-  const struct in6_addr *addr);
+  const struct in6_addr *saddr);
 
 /**
  * dst_cache_get_ip6 - perform cache lookup and fetch ipv6 source address
diff --git a/net/core/dst_cache.c b/net/core/dst_cache.c
index 554d36449231..64cef977484a 100644
--- a/net/core/dst_cache.c
+++ b/net/core/dst_cache.c
@@ -107,7 +107,7 @@ EXPORT_SYMBOL_GPL(dst_cache_set_ip4);
 
 #if IS_ENABLED(CONFIG_IPV6)
 void dst_cache_set_ip6(struct dst_cache *dst_cache, struct dst_entry *dst,
-  const struct in6_addr *addr)
+  const struct in6_addr *saddr)
 {
struct dst_cache_pcpu *idst;
 
@@ -117,7 +117,7 @@ void dst_cache_set_ip6(struct dst_cache *dst_cache, struct 
dst_entry *dst,
idst = this_cpu_ptr(dst_cache->cache);
dst_cache_per_cpu_dst_set(this_cpu_ptr(dst_cache->cache), dst,
  rt6_get_cookie((struct rt6_info *)dst));
-   idst->in6_saddr = *addr;
+   idst->in6_saddr = *saddr;
 }
 EXPORT_SYMBOL_GPL(dst_cache_set_ip6);
 
-- 
2.16.1



[PATCH 3/3] net: core: dst: Add kernel-doc for 'net' parameter

2018-03-03 Thread Jonathan Neuschäfer
This fixes the following kernel-doc warning:

./include/net/dst.h:366: warning: Function parameter or member 'net' not 
described in 'skb_tunnel_rx'

Fixes: ea23192e8e57 ("tunnels: harmonize cleanup done on skb on rx path")
Signed-off-by: Jonathan Neuschäfer 
---
 include/net/dst.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/net/dst.h b/include/net/dst.h
index c63d2c37f6e9..b3219cd8a5a1 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -356,6 +356,7 @@ static inline void __skb_tunnel_rx(struct sk_buff *skb, 
struct net_device *dev,
  * skb_tunnel_rx - prepare skb for rx reinsert
  * @skb: buffer
  * @dev: tunnel device
+ * @net: netns for packet i/o
  *
  * After decapsulation, packet is going to re-enter (netif_rx()) our stack,
  * so make some cleanups, and perform accounting.
-- 
2.16.1



[PATCH 2/3] net: core: dst_cache_set_ip6: Rename 'addr' parameter to 'saddr' for consistency

2018-03-03 Thread Jonathan Neuschäfer
The other dst_cache_{get,set}_ip{4,6} functions, and the doc comment for
dst_cache_set_ip6 use 'saddr' for their source address parameter. Rename
the parameter to increase consistency.

This fixes the following kernel-doc warnings:

./include/net/dst_cache.h:58: warning: Function parameter or member 'addr' not 
described in 'dst_cache_set_ip6'
./include/net/dst_cache.h:58: warning: Excess function parameter 'saddr' 
description in 'dst_cache_set_ip6'

Fixes: 911362c70df5 ("net: add dst_cache support")
Signed-off-by: Jonathan Neuschäfer 
---
 include/net/dst_cache.h | 2 +-
 net/core/dst_cache.c| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/net/dst_cache.h b/include/net/dst_cache.h
index 844906fbf8c9..67634675e919 100644
--- a/include/net/dst_cache.h
+++ b/include/net/dst_cache.h
@@ -54,7 +54,7 @@ void dst_cache_set_ip4(struct dst_cache *dst_cache, struct 
dst_entry *dst,
  * local BH must be disabled.
  */
 void dst_cache_set_ip6(struct dst_cache *dst_cache, struct dst_entry *dst,
-  const struct in6_addr *addr);
+  const struct in6_addr *saddr);
 
 /**
  * dst_cache_get_ip6 - perform cache lookup and fetch ipv6 source address
diff --git a/net/core/dst_cache.c b/net/core/dst_cache.c
index 554d36449231..64cef977484a 100644
--- a/net/core/dst_cache.c
+++ b/net/core/dst_cache.c
@@ -107,7 +107,7 @@ EXPORT_SYMBOL_GPL(dst_cache_set_ip4);
 
 #if IS_ENABLED(CONFIG_IPV6)
 void dst_cache_set_ip6(struct dst_cache *dst_cache, struct dst_entry *dst,
-  const struct in6_addr *addr)
+  const struct in6_addr *saddr)
 {
struct dst_cache_pcpu *idst;
 
@@ -117,7 +117,7 @@ void dst_cache_set_ip6(struct dst_cache *dst_cache, struct 
dst_entry *dst,
idst = this_cpu_ptr(dst_cache->cache);
dst_cache_per_cpu_dst_set(this_cpu_ptr(dst_cache->cache), dst,
  rt6_get_cookie((struct rt6_info *)dst));
-   idst->in6_saddr = *addr;
+   idst->in6_saddr = *saddr;
 }
 EXPORT_SYMBOL_GPL(dst_cache_set_ip6);
 
-- 
2.16.1



[PATCH 05/12] staging: iio: tsl2x7x: convert mutex_trylock() to mutex_lock()

2018-03-03 Thread Brian Masney
The driver uses mutex_lock() and mutex_trylock() in several places.
Convert the mutex_trylock() to mutex_lock() for consistency with other
IIO light drivers in mainline.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index cf16dd206c0b..5c611250127f 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -350,8 +350,7 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
u32 ch0lux = 0;
u32 ch1lux = 0;
 
-   if (mutex_trylock(>als_mutex) == 0)
-   return chip->als_cur_info.lux; /* busy, so return LAST VALUE */
+   mutex_lock(>als_mutex);
 
if (chip->tsl2x7x_chip_status != TSL2X7X_CHIP_WORKING) {
/* device is not enabled */
@@ -478,11 +477,7 @@ static int tsl2x7x_get_prox(struct iio_dev *indio_dev)
u8 chdata[2];
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
 
-   if (mutex_trylock(>prox_mutex) == 0) {
-   dev_err(>client->dev,
-   "%s: Can't get prox mutex\n", __func__);
-   return -EBUSY;
-   }
+   mutex_lock(>prox_mutex);
 
ret = tsl2x7x_read_status(chip);
if (ret < 0)
-- 
2.14.3



[PATCH 05/12] staging: iio: tsl2x7x: convert mutex_trylock() to mutex_lock()

2018-03-03 Thread Brian Masney
The driver uses mutex_lock() and mutex_trylock() in several places.
Convert the mutex_trylock() to mutex_lock() for consistency with other
IIO light drivers in mainline.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index cf16dd206c0b..5c611250127f 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -350,8 +350,7 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
u32 ch0lux = 0;
u32 ch1lux = 0;
 
-   if (mutex_trylock(>als_mutex) == 0)
-   return chip->als_cur_info.lux; /* busy, so return LAST VALUE */
+   mutex_lock(>als_mutex);
 
if (chip->tsl2x7x_chip_status != TSL2X7X_CHIP_WORKING) {
/* device is not enabled */
@@ -478,11 +477,7 @@ static int tsl2x7x_get_prox(struct iio_dev *indio_dev)
u8 chdata[2];
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
 
-   if (mutex_trylock(>prox_mutex) == 0) {
-   dev_err(>client->dev,
-   "%s: Can't get prox mutex\n", __func__);
-   return -EBUSY;
-   }
+   mutex_lock(>prox_mutex);
 
ret = tsl2x7x_read_status(chip);
if (ret < 0)
-- 
2.14.3



[PATCH 02/12] staging: iio: tsl2x7x: add common function for clearing interrupts

2018-03-03 Thread Brian Masney
There were three places where the same chunk of code was used to clear
interrupts. This patch creates a common function
tsl2x7x_clear_interrupts() to reduce duplicate code.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 52 +
 1 file changed, 24 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index b7e3f966c3a6..c02db03ef369 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -279,6 +279,20 @@ static const u8 device_channel_config[] = {
ALSPRX2
 };
 
+static int tsl2x7x_clear_interrupts(struct tsl2X7X_chip *chip, int reg)
+{
+   int ret;
+
+   ret = i2c_smbus_write_byte(chip->client,
+  TSL2X7X_CMD_REG | TSL2X7X_CMD_SPL_FN | reg);
+   if (ret < 0)
+   dev_err(>client->dev,
+   "%s: failed to clear interrupt status %x: %d\n",
+   __func__, reg, ret);
+
+   return ret;
+}
+
 /**
  * tsl2x7x_get_lux() - Reads and calculates current lux value.
  * @indio_dev: pointer to IIO device
@@ -346,16 +360,9 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
buf[i] = ret;
}
 
-   /* clear any existing interrupt status */
-   ret = i2c_smbus_write_byte(chip->client,
-  TSL2X7X_CMD_REG |
-  TSL2X7X_CMD_SPL_FN |
-  TSL2X7X_CMD_ALS_INT_CLR);
-   if (ret < 0) {
-   dev_err(>client->dev,
-   "i2c_write_command failed - err = %d\n", ret);
-   goto out_unlock; /* have no data, so return failure */
-   }
+   ret = tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_ALS_INT_CLR);
+   if (ret < 0)
+   goto out_unlock;
 
/* extract ALS/lux data */
ch0 = le16_to_cpup((const __le16 *)[0]);
@@ -706,17 +713,10 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
"%s: failed in tsl2x7x_IOCTL_INT_SET.\n",
__func__);
 
-   /* Clear out any initial interrupts  */
-   ret = i2c_smbus_write_byte(chip->client,
-  TSL2X7X_CMD_REG |
-  TSL2X7X_CMD_SPL_FN |
-  TSL2X7X_CMD_PROXALS_INT_CLR);
-   if (ret < 0) {
-   dev_err(>client->dev,
-   "%s: Failed to clear Int status\n",
-   __func__);
-   return ret;
-   }
+   ret = tsl2x7x_clear_interrupts(chip,
+  TSL2X7X_CMD_PROXALS_INT_CLR);
+   if (ret < 0)
+   return ret;
}
 
return ret;
@@ -1421,14 +1421,10 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
IIO_EV_DIR_EITHER),
   timestamp);
}
-   /* Clear interrupt now that we have handled it. */
-   ret = i2c_smbus_write_byte(chip->client,
-  TSL2X7X_CMD_REG | TSL2X7X_CMD_SPL_FN |
-  TSL2X7X_CMD_PROXALS_INT_CLR);
+
+   ret = tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_PROXALS_INT_CLR);
if (ret < 0)
-   dev_err(>client->dev,
-   "Failed to clear irq from event handler. err = %d\n",
-   ret);
+   return ret;
 
return IRQ_HANDLED;
 }
-- 
2.14.3



[PATCH 10/12] staging: iio: tsl2x7x: make logging consistent and correct newlines

2018-03-03 Thread Brian Masney
This patch updates all of the logging commands so that they are
consistent with the other messages, includes __func__ in the message,
and all of the messages include newlines.

This patch also removes some debug log messages from tsl2x7x_prox_cal().

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 58 -
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index da7a4e025083..fb91c46c8747 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -378,7 +378,8 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
ret = i2c_smbus_read_byte_data(chip->client, reg);
if (ret < 0) {
dev_err(>client->dev,
-   "failed to read. err=%x\n", ret);
+   "%s: failed to read from register %x: %d\n",
+   __func__, reg, ret);
goto out_unlock;
}
 
@@ -424,7 +425,9 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
 
/* note: lux is 31 bit max at this point */
if (ch1lux > ch0lux) {
-   dev_dbg(>client->dev, "ch1lux > ch0lux-return last 
value\n");
+   dev_dbg(>client->dev,
+   "%s: ch1lux > ch0lux; returning last value\n",
+   __func__);
ret = chip->als_cur_info.lux;
goto out_unlock;
}
@@ -600,7 +603,8 @@ static int tsl2x7x_als_calibrate(struct iio_dev *indio_dev)
 
chip->settings.als_gain_trim = ret;
dev_info(>client->dev,
-"%s als_calibrate completed\n", chip->client->name);
+"%s: %s ALS calibration successfully completed\n",
+__func__, chip->client->name);
 
return ret;
 }
@@ -644,7 +648,8 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
/* and make sure we're not already on */
if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_WORKING) {
/* if forcing a register update - turn off, then on */
-   dev_info(>client->dev, "device is already enabled\n");
+   dev_info(>client->dev, "%s: device is already enabled\n",
+__func__);
return -EINVAL;
}
 
@@ -681,12 +686,14 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
 */
for (i = 0, dev_reg = chip->tsl2x7x_config;
i < TSL2X7X_MAX_CONFIG_REG; i++) {
-   ret = i2c_smbus_write_byte_data(chip->client,
-   TSL2X7X_CMD_REG + i,
+   int reg = TSL2X7X_CMD_REG + i;
+
+   ret = i2c_smbus_write_byte_data(chip->client, reg,
*dev_reg++);
if (ret < 0) {
dev_err(>client->dev,
-   "failed on write to reg %d.\n", i);
+   "%s: failed to write to register %x: %d\n",
+   __func__, reg, ret);
return ret;
}
}
@@ -708,7 +715,8 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
chip->tsl2x7x_chip_status = TSL2X7X_CHIP_WORKING;
 
if (chip->settings.interrupts_en != 0) {
-   dev_info(>client->dev, "Setting Up Interrupt(s)\n");
+   dev_info(>client->dev, "%s: Setting up interrupt(s)\n",
+__func__);
 
reg_val = TSL2X7X_CNTL_PWR_ON | TSL2X7X_CNTL_ADC_ENBL;
if (chip->settings.interrupts_en == 0x20 ||
@@ -819,8 +827,8 @@ static int tsl2x7x_prox_cal(struct iio_dev *indio_dev)
 
if (chip->settings.prox_max_samples_cal > MAX_SAMPLES_CAL) {
dev_err(>client->dev,
-   "max prox samples cal is too big: %d\n",
-   chip->settings.prox_max_samples_cal);
+   "%s: prox_max_samples_cal %d is too big\n",
+   __func__, chip->settings.prox_max_samples_cal);
chip->settings.prox_max_samples_cal = MAX_SAMPLES_CAL;
}
 
@@ -845,8 +853,6 @@ static int tsl2x7x_prox_cal(struct iio_dev *indio_dev)
if (ret < 0)
return ret;
prox_history[i] = chip->prox_data;
-   dev_info(>client->dev, "2 i=%d prox data= %d\n",
-i, chip->prox_data);
}
 
ret = tsl2x7x_chip_off(indio_dev);
@@ -857,12 +863,6 @@ static int tsl2x7x_prox_cal(struct iio_dev *indio_dev)
   chip->settings.prox_max_samples_cal, cal);
chip->settings.prox_thres_high = (cal->max << 1) - cal->mean;
 
-   dev_info(>client->dev, " cal min=%d mean=%d max=%d\n",
-cal->min, 

[PATCH 04/12] staging: iio: tsl2x7x: add common function for writing to the control register

2018-03-03 Thread Brian Masney
There were four places where the same chunk of code was used to write
to the control register. This patch creates a common function
tsl2x7x_write_control_reg() to reduce duplicate code.

The function tsl2x7x_chip_off() did not correctly return an error
code so this patch also corrects that issue.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 54 +
 1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 6bb622816660..cf16dd206c0b 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -307,6 +307,21 @@ static int tsl2x7x_read_status(struct tsl2X7X_chip *chip)
return ret;
 }
 
+static int tsl2x7x_write_control_reg(struct tsl2X7X_chip *chip, u8 data)
+{
+   int ret;
+
+   ret = i2c_smbus_write_byte_data(chip->client,
+   TSL2X7X_CMD_REG | TSL2X7X_CNTRL, data);
+   if (ret < 0) {
+   dev_err(>client->dev,
+   "%s: failed to write to control register %x: %d\n",
+   __func__, data, ret);
+   }
+
+   return ret;
+}
+
 /**
  * tsl2x7x_get_lux() - Reads and calculates current lux value.
  * @indio_dev: pointer to IIO device
@@ -597,7 +612,6 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
int i;
int ret = 0;
u8 *dev_reg;
-   u8 utmp;
int als_count;
int als_time;
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
@@ -659,14 +673,9 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
 * TSL2X7X Specific power-on / adc enable sequence
 * Power on the device 1st.
 */
-   utmp = TSL2X7X_CNTL_PWR_ON;
-   ret = i2c_smbus_write_byte_data(chip->client,
-   TSL2X7X_CMD_REG | TSL2X7X_CNTRL, utmp);
-   if (ret < 0) {
-   dev_err(>client->dev,
-   "%s: failed on CNTRL reg.\n", __func__);
+   ret = tsl2x7x_write_control_reg(chip, TSL2X7X_CNTL_PWR_ON);
+   if (ret < 0)
return ret;
-   }
 
/*
 * Use the following shadow copy for our delay before enabling ADC.
@@ -691,16 +700,12 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
 * NOW enable the ADC
 * initialize the desired mode of operation
 */
-   utmp = TSL2X7X_CNTL_PWR_ON |
-   TSL2X7X_CNTL_ADC_ENBL |
-   TSL2X7X_CNTL_PROX_DET_ENBL;
-   ret = i2c_smbus_write_byte_data(chip->client,
-   TSL2X7X_CMD_REG | TSL2X7X_CNTRL, utmp);
-   if (ret < 0) {
-   dev_err(>client->dev,
-   "%s: failed on 2nd CTRL reg.\n", __func__);
+   ret = tsl2x7x_write_control_reg(chip,
+   TSL2X7X_CNTL_PWR_ON |
+   TSL2X7X_CNTL_ADC_ENBL |
+   TSL2X7X_CNTL_PROX_DET_ENBL);
+   if (ret < 0)
return ret;
-   }
 
chip->tsl2x7x_chip_status = TSL2X7X_CHIP_WORKING;
 
@@ -713,13 +718,9 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
reg_val |= TSL2X7X_CNTL_PROX_DET_ENBL;
 
reg_val |= chip->settings.interrupts_en;
-   ret = i2c_smbus_write_byte_data(chip->client,
-   TSL2X7X_CMD_REG | TSL2X7X_CNTRL,
-   reg_val);
+   ret = tsl2x7x_write_control_reg(chip, reg_val);
if (ret < 0)
-   dev_err(>client->dev,
-   "%s: failed in tsl2x7x_IOCTL_INT_SET.\n",
-   __func__);
+   return ret;
 
ret = tsl2x7x_clear_interrupts(chip,
   TSL2X7X_CMD_PROXALS_INT_CLR);
@@ -732,16 +733,11 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
 
 static int tsl2x7x_chip_off(struct iio_dev *indio_dev)
 {
-   int ret;
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
 
/* turn device off */
chip->tsl2x7x_chip_status = TSL2X7X_CHIP_SUSPENDED;
-
-   ret = i2c_smbus_write_byte_data(chip->client,
-   TSL2X7X_CMD_REG | TSL2X7X_CNTRL, 0x00);
-
-   return ret;
+   return tsl2x7x_write_control_reg(chip, 0x00);
 }
 
 /**
-- 
2.14.3



[PATCH 02/12] staging: iio: tsl2x7x: add common function for clearing interrupts

2018-03-03 Thread Brian Masney
There were three places where the same chunk of code was used to clear
interrupts. This patch creates a common function
tsl2x7x_clear_interrupts() to reduce duplicate code.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 52 +
 1 file changed, 24 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index b7e3f966c3a6..c02db03ef369 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -279,6 +279,20 @@ static const u8 device_channel_config[] = {
ALSPRX2
 };
 
+static int tsl2x7x_clear_interrupts(struct tsl2X7X_chip *chip, int reg)
+{
+   int ret;
+
+   ret = i2c_smbus_write_byte(chip->client,
+  TSL2X7X_CMD_REG | TSL2X7X_CMD_SPL_FN | reg);
+   if (ret < 0)
+   dev_err(>client->dev,
+   "%s: failed to clear interrupt status %x: %d\n",
+   __func__, reg, ret);
+
+   return ret;
+}
+
 /**
  * tsl2x7x_get_lux() - Reads and calculates current lux value.
  * @indio_dev: pointer to IIO device
@@ -346,16 +360,9 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
buf[i] = ret;
}
 
-   /* clear any existing interrupt status */
-   ret = i2c_smbus_write_byte(chip->client,
-  TSL2X7X_CMD_REG |
-  TSL2X7X_CMD_SPL_FN |
-  TSL2X7X_CMD_ALS_INT_CLR);
-   if (ret < 0) {
-   dev_err(>client->dev,
-   "i2c_write_command failed - err = %d\n", ret);
-   goto out_unlock; /* have no data, so return failure */
-   }
+   ret = tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_ALS_INT_CLR);
+   if (ret < 0)
+   goto out_unlock;
 
/* extract ALS/lux data */
ch0 = le16_to_cpup((const __le16 *)[0]);
@@ -706,17 +713,10 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
"%s: failed in tsl2x7x_IOCTL_INT_SET.\n",
__func__);
 
-   /* Clear out any initial interrupts  */
-   ret = i2c_smbus_write_byte(chip->client,
-  TSL2X7X_CMD_REG |
-  TSL2X7X_CMD_SPL_FN |
-  TSL2X7X_CMD_PROXALS_INT_CLR);
-   if (ret < 0) {
-   dev_err(>client->dev,
-   "%s: Failed to clear Int status\n",
-   __func__);
-   return ret;
-   }
+   ret = tsl2x7x_clear_interrupts(chip,
+  TSL2X7X_CMD_PROXALS_INT_CLR);
+   if (ret < 0)
+   return ret;
}
 
return ret;
@@ -1421,14 +1421,10 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
IIO_EV_DIR_EITHER),
   timestamp);
}
-   /* Clear interrupt now that we have handled it. */
-   ret = i2c_smbus_write_byte(chip->client,
-  TSL2X7X_CMD_REG | TSL2X7X_CMD_SPL_FN |
-  TSL2X7X_CMD_PROXALS_INT_CLR);
+
+   ret = tsl2x7x_clear_interrupts(chip, TSL2X7X_CMD_PROXALS_INT_CLR);
if (ret < 0)
-   dev_err(>client->dev,
-   "Failed to clear irq from event handler. err = %d\n",
-   ret);
+   return ret;
 
return IRQ_HANDLED;
 }
-- 
2.14.3



[PATCH 10/12] staging: iio: tsl2x7x: make logging consistent and correct newlines

2018-03-03 Thread Brian Masney
This patch updates all of the logging commands so that they are
consistent with the other messages, includes __func__ in the message,
and all of the messages include newlines.

This patch also removes some debug log messages from tsl2x7x_prox_cal().

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 58 -
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index da7a4e025083..fb91c46c8747 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -378,7 +378,8 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
ret = i2c_smbus_read_byte_data(chip->client, reg);
if (ret < 0) {
dev_err(>client->dev,
-   "failed to read. err=%x\n", ret);
+   "%s: failed to read from register %x: %d\n",
+   __func__, reg, ret);
goto out_unlock;
}
 
@@ -424,7 +425,9 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
 
/* note: lux is 31 bit max at this point */
if (ch1lux > ch0lux) {
-   dev_dbg(>client->dev, "ch1lux > ch0lux-return last 
value\n");
+   dev_dbg(>client->dev,
+   "%s: ch1lux > ch0lux; returning last value\n",
+   __func__);
ret = chip->als_cur_info.lux;
goto out_unlock;
}
@@ -600,7 +603,8 @@ static int tsl2x7x_als_calibrate(struct iio_dev *indio_dev)
 
chip->settings.als_gain_trim = ret;
dev_info(>client->dev,
-"%s als_calibrate completed\n", chip->client->name);
+"%s: %s ALS calibration successfully completed\n",
+__func__, chip->client->name);
 
return ret;
 }
@@ -644,7 +648,8 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
/* and make sure we're not already on */
if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_WORKING) {
/* if forcing a register update - turn off, then on */
-   dev_info(>client->dev, "device is already enabled\n");
+   dev_info(>client->dev, "%s: device is already enabled\n",
+__func__);
return -EINVAL;
}
 
@@ -681,12 +686,14 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
 */
for (i = 0, dev_reg = chip->tsl2x7x_config;
i < TSL2X7X_MAX_CONFIG_REG; i++) {
-   ret = i2c_smbus_write_byte_data(chip->client,
-   TSL2X7X_CMD_REG + i,
+   int reg = TSL2X7X_CMD_REG + i;
+
+   ret = i2c_smbus_write_byte_data(chip->client, reg,
*dev_reg++);
if (ret < 0) {
dev_err(>client->dev,
-   "failed on write to reg %d.\n", i);
+   "%s: failed to write to register %x: %d\n",
+   __func__, reg, ret);
return ret;
}
}
@@ -708,7 +715,8 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
chip->tsl2x7x_chip_status = TSL2X7X_CHIP_WORKING;
 
if (chip->settings.interrupts_en != 0) {
-   dev_info(>client->dev, "Setting Up Interrupt(s)\n");
+   dev_info(>client->dev, "%s: Setting up interrupt(s)\n",
+__func__);
 
reg_val = TSL2X7X_CNTL_PWR_ON | TSL2X7X_CNTL_ADC_ENBL;
if (chip->settings.interrupts_en == 0x20 ||
@@ -819,8 +827,8 @@ static int tsl2x7x_prox_cal(struct iio_dev *indio_dev)
 
if (chip->settings.prox_max_samples_cal > MAX_SAMPLES_CAL) {
dev_err(>client->dev,
-   "max prox samples cal is too big: %d\n",
-   chip->settings.prox_max_samples_cal);
+   "%s: prox_max_samples_cal %d is too big\n",
+   __func__, chip->settings.prox_max_samples_cal);
chip->settings.prox_max_samples_cal = MAX_SAMPLES_CAL;
}
 
@@ -845,8 +853,6 @@ static int tsl2x7x_prox_cal(struct iio_dev *indio_dev)
if (ret < 0)
return ret;
prox_history[i] = chip->prox_data;
-   dev_info(>client->dev, "2 i=%d prox data= %d\n",
-i, chip->prox_data);
}
 
ret = tsl2x7x_chip_off(indio_dev);
@@ -857,12 +863,6 @@ static int tsl2x7x_prox_cal(struct iio_dev *indio_dev)
   chip->settings.prox_max_samples_cal, cal);
chip->settings.prox_thres_high = (cal->max << 1) - cal->mean;
 
-   dev_info(>client->dev, " cal min=%d mean=%d max=%d\n",
-cal->min, cal->mean, cal->max);
-   

[PATCH 04/12] staging: iio: tsl2x7x: add common function for writing to the control register

2018-03-03 Thread Brian Masney
There were four places where the same chunk of code was used to write
to the control register. This patch creates a common function
tsl2x7x_write_control_reg() to reduce duplicate code.

The function tsl2x7x_chip_off() did not correctly return an error
code so this patch also corrects that issue.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 54 +
 1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 6bb622816660..cf16dd206c0b 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -307,6 +307,21 @@ static int tsl2x7x_read_status(struct tsl2X7X_chip *chip)
return ret;
 }
 
+static int tsl2x7x_write_control_reg(struct tsl2X7X_chip *chip, u8 data)
+{
+   int ret;
+
+   ret = i2c_smbus_write_byte_data(chip->client,
+   TSL2X7X_CMD_REG | TSL2X7X_CNTRL, data);
+   if (ret < 0) {
+   dev_err(>client->dev,
+   "%s: failed to write to control register %x: %d\n",
+   __func__, data, ret);
+   }
+
+   return ret;
+}
+
 /**
  * tsl2x7x_get_lux() - Reads and calculates current lux value.
  * @indio_dev: pointer to IIO device
@@ -597,7 +612,6 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
int i;
int ret = 0;
u8 *dev_reg;
-   u8 utmp;
int als_count;
int als_time;
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
@@ -659,14 +673,9 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
 * TSL2X7X Specific power-on / adc enable sequence
 * Power on the device 1st.
 */
-   utmp = TSL2X7X_CNTL_PWR_ON;
-   ret = i2c_smbus_write_byte_data(chip->client,
-   TSL2X7X_CMD_REG | TSL2X7X_CNTRL, utmp);
-   if (ret < 0) {
-   dev_err(>client->dev,
-   "%s: failed on CNTRL reg.\n", __func__);
+   ret = tsl2x7x_write_control_reg(chip, TSL2X7X_CNTL_PWR_ON);
+   if (ret < 0)
return ret;
-   }
 
/*
 * Use the following shadow copy for our delay before enabling ADC.
@@ -691,16 +700,12 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
 * NOW enable the ADC
 * initialize the desired mode of operation
 */
-   utmp = TSL2X7X_CNTL_PWR_ON |
-   TSL2X7X_CNTL_ADC_ENBL |
-   TSL2X7X_CNTL_PROX_DET_ENBL;
-   ret = i2c_smbus_write_byte_data(chip->client,
-   TSL2X7X_CMD_REG | TSL2X7X_CNTRL, utmp);
-   if (ret < 0) {
-   dev_err(>client->dev,
-   "%s: failed on 2nd CTRL reg.\n", __func__);
+   ret = tsl2x7x_write_control_reg(chip,
+   TSL2X7X_CNTL_PWR_ON |
+   TSL2X7X_CNTL_ADC_ENBL |
+   TSL2X7X_CNTL_PROX_DET_ENBL);
+   if (ret < 0)
return ret;
-   }
 
chip->tsl2x7x_chip_status = TSL2X7X_CHIP_WORKING;
 
@@ -713,13 +718,9 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
reg_val |= TSL2X7X_CNTL_PROX_DET_ENBL;
 
reg_val |= chip->settings.interrupts_en;
-   ret = i2c_smbus_write_byte_data(chip->client,
-   TSL2X7X_CMD_REG | TSL2X7X_CNTRL,
-   reg_val);
+   ret = tsl2x7x_write_control_reg(chip, reg_val);
if (ret < 0)
-   dev_err(>client->dev,
-   "%s: failed in tsl2x7x_IOCTL_INT_SET.\n",
-   __func__);
+   return ret;
 
ret = tsl2x7x_clear_interrupts(chip,
   TSL2X7X_CMD_PROXALS_INT_CLR);
@@ -732,16 +733,11 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
 
 static int tsl2x7x_chip_off(struct iio_dev *indio_dev)
 {
-   int ret;
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
 
/* turn device off */
chip->tsl2x7x_chip_status = TSL2X7X_CHIP_SUSPENDED;
-
-   ret = i2c_smbus_write_byte_data(chip->client,
-   TSL2X7X_CMD_REG | TSL2X7X_CNTRL, 0x00);
-
-   return ret;
+   return tsl2x7x_write_control_reg(chip, 0x00);
 }
 
 /**
-- 
2.14.3



[PATCH 08/12] staging: iio: tsl2x7x: add error handling to tsl2x7x_prox_cal()

2018-03-03 Thread Brian Masney
tsl2x7x_prox_cal() did not have any error checks. This patch adds
the missing error handling and ensures that any errors are reported to
user space via in_proximity0_calibrate_store().

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 380a6c96a69a..8adc6db44790 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -807,10 +807,10 @@ static void tsl2x7x_prox_calculate(int *data, int length,
  * Calculates a standard deviation based on the samples,
  * and sets the threshold accordingly.
  */
-static void tsl2x7x_prox_cal(struct iio_dev *indio_dev)
+static int tsl2x7x_prox_cal(struct iio_dev *indio_dev)
 {
int prox_history[MAX_SAMPLES_CAL + 1];
-   int i;
+   int i, ret;
struct tsl2x7x_prox_stat prox_stat_data[2];
struct tsl2x7x_prox_stat *cal;
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
@@ -825,25 +825,33 @@ static void tsl2x7x_prox_cal(struct iio_dev *indio_dev)
}
 
/* have to stop to change settings */
-   tsl2x7x_chip_off(indio_dev);
+   ret = tsl2x7x_chip_off(indio_dev);
+   if (ret < 0)
+   return ret;
 
/* Enable proximity detection save just in case prox not wanted yet*/
tmp_irq_settings = chip->settings.interrupts_en;
chip->settings.interrupts_en |= TSL2X7X_CNTL_PROX_INT_ENBL;
 
/*turn on device if not already on*/
-   tsl2x7x_chip_on(indio_dev);
+   ret = tsl2x7x_chip_on(indio_dev);
+   if (ret < 0)
+   return ret;
 
/*gather the samples*/
for (i = 0; i < chip->settings.prox_max_samples_cal; i++) {
usleep_range(15000, 17500);
-   tsl2x7x_get_prox(indio_dev);
+   ret = tsl2x7x_get_prox(indio_dev);
+   if (ret < 0)
+   return ret;
prox_history[i] = chip->prox_data;
dev_info(>client->dev, "2 i=%d prox data= %d\n",
 i, chip->prox_data);
}
 
-   tsl2x7x_chip_off(indio_dev);
+   ret = tsl2x7x_chip_off(indio_dev);
+   if (ret < 0)
+   return ret;
cal = _stat_data[PROX_STAT_CAL];
tsl2x7x_prox_calculate(prox_history,
   chip->settings.prox_max_samples_cal, cal);
@@ -857,8 +865,13 @@ static void tsl2x7x_prox_cal(struct iio_dev *indio_dev)
 
/* back to the way they were */
chip->settings.interrupts_en = tmp_irq_settings;
-   if (current_state == TSL2X7X_CHIP_WORKING)
-   tsl2x7x_chip_on(indio_dev);
+   if (current_state == TSL2X7X_CHIP_WORKING) {
+   ret = tsl2x7x_chip_on(indio_dev);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
 }
 
 static ssize_t
@@ -1018,8 +1031,11 @@ static ssize_t in_proximity0_calibrate_store(struct 
device *dev,
if (strtobool(buf, ))
return -EINVAL;
 
-   if (value)
-   tsl2x7x_prox_cal(indio_dev);
+   if (value) {
+   ret = tsl2x7x_prox_cal(indio_dev);
+   if (ret < 0)
+   return ret;
+   }
 
ret = tsl2x7x_invoke_change(indio_dev);
if (ret < 0)
-- 
2.14.3



[PATCH 03/12] staging: iio: tsl2x7x: add common function for reading chip status

2018-03-03 Thread Brian Masney
There were three places where the same chunk of code was used to read
the chip status. This patch creates a common function
tsl2x7x_read_status() to reduce duplicate code. This patch also corrects
tsl2x7x_event_handler() to properly check for an error after reading the
chip status.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 40 ++---
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index c02db03ef369..6bb622816660 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -293,6 +293,20 @@ static int tsl2x7x_clear_interrupts(struct tsl2X7X_chip 
*chip, int reg)
return ret;
 }
 
+static int tsl2x7x_read_status(struct tsl2X7X_chip *chip)
+{
+   int ret;
+
+   ret = i2c_smbus_read_byte_data(chip->client,
+  TSL2X7X_CMD_REG | TSL2X7X_STATUS);
+   if (ret < 0)
+   dev_err(>client->dev,
+   "%s: failed to read STATUS register: %d\n", __func__,
+   ret);
+
+   return ret;
+}
+
 /**
  * tsl2x7x_get_lux() - Reads and calculates current lux value.
  * @indio_dev: pointer to IIO device
@@ -332,13 +346,10 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
goto out_unlock;
}
 
-   ret = i2c_smbus_read_byte_data(chip->client,
-  TSL2X7X_CMD_REG | TSL2X7X_STATUS);
-   if (ret < 0) {
-   dev_err(>client->dev,
-   "%s: Failed to read STATUS Reg\n", __func__);
+   ret = tsl2x7x_read_status(chip);
+   if (ret < 0)
goto out_unlock;
-   }
+
/* is data new & valid */
if (!(ret & TSL2X7X_STA_ADC_VALID)) {
dev_err(>client->dev,
@@ -458,12 +469,9 @@ static int tsl2x7x_get_prox(struct iio_dev *indio_dev)
return -EBUSY;
}
 
-   ret = i2c_smbus_read_byte_data(chip->client,
-  TSL2X7X_CMD_REG | TSL2X7X_STATUS);
-   if (ret < 0) {
-   dev_err(>client->dev, "i2c err=%d\n", ret);
+   ret = tsl2x7x_read_status(chip);
+   if (ret < 0)
goto prox_poll_err;
-   }
 
switch (chip->id) {
case tsl2571:
@@ -1396,13 +1404,13 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
s64 timestamp = iio_get_time_ns(indio_dev);
int ret;
-   u8 value;
 
-   value = i2c_smbus_read_byte_data(chip->client,
-TSL2X7X_CMD_REG | TSL2X7X_STATUS);
+   ret = tsl2x7x_read_status(chip);
+   if (ret < 0)
+   return ret;
 
/* What type of interrupt do we need to process */
-   if (value & TSL2X7X_STA_PRX_INTR) {
+   if (ret & TSL2X7X_STA_PRX_INTR) {
tsl2x7x_get_prox(indio_dev); /* freshen data for ABI */
iio_push_event(indio_dev,
   IIO_UNMOD_EVENT_CODE(IIO_PROXIMITY,
@@ -1412,7 +1420,7 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
timestamp);
}
 
-   if (value & TSL2X7X_STA_ALS_INTR) {
+   if (ret & TSL2X7X_STA_ALS_INTR) {
tsl2x7x_get_lux(indio_dev); /* freshen data for ABI */
iio_push_event(indio_dev,
   IIO_UNMOD_EVENT_CODE(IIO_LIGHT,
-- 
2.14.3



[PATCH 06/12] staging: iio: tsl2x7x: correctly return errors in tsl2x7x_get_prox()

2018-03-03 Thread Brian Masney
Not all errors that occurred in tsl2x7x_get_prox() were correctly
reported in the return value. This patch changes the error handling
so that errors are now returned properly.

Note that the ret variable is from the call to tsl2x7x_read_status(),
and it already has the correct error check. The -EINVAL error code is
for an unexpected value in the register.

This patch also corrects an unnecessary word wrap in the call to
le16_to_cpup() while changes are being made to this code.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 5c611250127f..cc209b64ed5a 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -489,16 +489,20 @@ static int tsl2x7x_get_prox(struct iio_dev *indio_dev)
case tmd2671:
case tsl2771:
case tmd2771:
-   if (!(ret & TSL2X7X_STA_ADC_VALID))
+   if (!(ret & TSL2X7X_STA_ADC_VALID)) {
+   ret = -EINVAL;
goto prox_poll_err;
+   }
break;
case tsl2572:
case tsl2672:
case tmd2672:
case tsl2772:
case tmd2772:
-   if (!(ret & TSL2X7X_STA_PRX_VALID))
+   if (!(ret & TSL2X7X_STA_PRX_VALID)) {
+   ret = -EINVAL;
goto prox_poll_err;
+   }
break;
}
 
@@ -512,14 +516,13 @@ static int tsl2x7x_get_prox(struct iio_dev *indio_dev)
chdata[i] = ret;
}
 
-   chip->prox_data =
-   le16_to_cpup((const __le16 *)[0]);
+   chip->prox_data = le16_to_cpup((const __le16 *)[0]);
+   ret = chip->prox_data;
 
 prox_poll_err:
-
mutex_unlock(>prox_mutex);
 
-   return chip->prox_data;
+   return ret;
 }
 
 /**
-- 
2.14.3



[PATCH 11/12] staging: iio: tsl2x7x: remove unnecessary sysfs attribute

2018-03-03 Thread Brian Masney
The tsl2771 and tmd2771 devices create the
in_proximity0_calibscale_available sysfs attribute. These two particular
devices do not support changing the proximity gain value on the
chip so this patch removes that sysfs attribute. As expected, these two
devices already did not create the IIO_CHAN_INFO_CALIBSCALE channel and
proximity0_calibrate sysfs attribute.

Page 38 of the tsl2772 data sheet shows that the proximity gain can be
adjusted with bits 2-3 on the control register:
https://ams.com/eng/content/download/291503/1066377/file/TSL2772_DS000181_2-00.pdf

Page 35 of the tsl2771 and tmd2771 data sheets shows that bits 2-3 on
the control register are reserved and changing the proximity gain is
not supported:
https://ams.com/eng/content/download/250264/976045/file/TSL2771_DS000105_3-00.pdf
https://ams.com/eng/content/download/250283/976077/file/TMD2771_DS000177_2-00.pdf

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index fb91c46c8747..8c29a52153c1 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -1477,7 +1477,6 @@ static struct attribute *tsl2x7x_ALSPRX_device_attrs[] = {
_attr_in_illuminance0_target_input.attr,
_attr_in_illuminance0_calibrate.attr,
_attr_in_illuminance0_lux_table.attr,
-   _const_attr_in_proximity0_calibscale_available.dev_attr.attr,
NULL
 };
 
-- 
2.14.3



[PATCH 01/12] staging: iio: tsl2x7x: remove power functions from tsl2X7X_platform_data

2018-03-03 Thread Brian Masney
The tsl2X7X_platform_data structure contains the platform_power,
power_on, and power_off function pointers. These power management
functions should not be in the platform data. These functions were
likely used before the regulator framework was put in place. There are
no users of these functions in the mainline kernel.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 18 --
 drivers/staging/iio/light/tsl2x7x.h |  4 
 2 files changed, 22 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 126e11530ce0..b7e3f966c3a6 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -588,9 +588,6 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
u8 reg_val = 0;
 
-   if (chip->pdata && chip->pdata->power_on)
-   chip->pdata->power_on(indio_dev);
-
/* Non calculated parameters */
chip->tsl2x7x_config[TSL2X7X_PRX_TIME] = chip->settings.prx_time;
chip->tsl2x7x_config[TSL2X7X_WAIT_TIME] = chip->settings.wait_time;
@@ -736,9 +733,6 @@ static int tsl2x7x_chip_off(struct iio_dev *indio_dev)
ret = i2c_smbus_write_byte_data(chip->client,
TSL2X7X_CMD_REG | TSL2X7X_CNTRL, 0x00);
 
-   if (chip->pdata && chip->pdata->power_off)
-   chip->pdata->power_off(chip->client);
-
return ret;
 }
 
@@ -1792,12 +1786,6 @@ static int tsl2x7x_suspend(struct device *dev)
chip->tsl2x7x_chip_status = TSL2X7X_CHIP_SUSPENDED;
}
 
-   if (chip->pdata && chip->pdata->platform_power) {
-   pm_message_t pmm = {PM_EVENT_SUSPEND};
-
-   chip->pdata->platform_power(dev, pmm);
-   }
-
return ret;
 }
 
@@ -1807,12 +1795,6 @@ static int tsl2x7x_resume(struct device *dev)
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
int ret = 0;
 
-   if (chip->pdata && chip->pdata->platform_power) {
-   pm_message_t pmm = {PM_EVENT_RESUME};
-
-   chip->pdata->platform_power(dev, pmm);
-   }
-
if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_SUSPENDED)
ret = tsl2x7x_chip_on(indio_dev);
 
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index df00f2ec1719..6624cbca7a83 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -21,7 +21,6 @@
 
 #ifndef __TSL2X7X_H
 #define __TSL2X7X_H
-#include 
 
 struct tsl2x7x_lux {
unsigned int ratio;
@@ -91,9 +90,6 @@ struct tsl2x7x_settings {
  *
  */
 struct tsl2X7X_platform_data {
-   int (*platform_power)(struct device *dev, pm_message_t);
-   int (*power_on)(struct iio_dev *indio_dev);
-   int (*power_off)(struct i2c_client *dev);
struct tsl2x7x_lux platform_lux_table[TSL2X7X_MAX_LUX_TABLE_SIZE];
struct tsl2x7x_settings *platform_default_settings;
 };
-- 
2.14.3



[PATCH 00/12] staging cleanups

2018-03-03 Thread Brian Masney
Here is another patch series that inches the driver closer to moving out
of staging. The most interesting changes are the last two in the series.
One gets the proximity sensor working and the other one removes the
unnecessary in_proximity0_calibscale_available sysfs attribute from two
of the supported devices. The rest of the patches are not that
interesting and either reduce duplicate code, add error handling, or
other minor cosmetic changes.

Brian Masney (12):
  staging: iio: tsl2x7x: remove power functions from
tsl2X7X_platform_data
  staging: iio: tsl2x7x: add common function for clearing interrupts
  staging: iio: tsl2x7x: add common function for reading chip status
  staging: iio: tsl2x7x: add common function for writing to the control
register
  staging: iio: tsl2x7x: convert mutex_trylock() to mutex_lock()
  staging: iio: tsl2x7x: correctly return errors in tsl2x7x_get_prox()
  staging: iio: tsl2x7x: correct 'Avoid CamelCase' warning from
checkpatch
  staging: iio: tsl2x7x: add error handling to tsl2x7x_prox_cal()
  staging: iio: tsl2x7x: add missing error checks
  staging: iio: tsl2x7x: make logging consistent and correct newlines
  staging: iio: tsl2x7x: remove unnecessary sysfs attribute
  staging: iio: tsl2x7x: make proximity sensor function correctly

 drivers/staging/iio/light/tsl2x7x.c | 346 ++--
 drivers/staging/iio/light/tsl2x7x.h |   6 +-
 2 files changed, 179 insertions(+), 173 deletions(-)

-- 
2.14.3



[PATCH 08/12] staging: iio: tsl2x7x: add error handling to tsl2x7x_prox_cal()

2018-03-03 Thread Brian Masney
tsl2x7x_prox_cal() did not have any error checks. This patch adds
the missing error handling and ensures that any errors are reported to
user space via in_proximity0_calibrate_store().

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 380a6c96a69a..8adc6db44790 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -807,10 +807,10 @@ static void tsl2x7x_prox_calculate(int *data, int length,
  * Calculates a standard deviation based on the samples,
  * and sets the threshold accordingly.
  */
-static void tsl2x7x_prox_cal(struct iio_dev *indio_dev)
+static int tsl2x7x_prox_cal(struct iio_dev *indio_dev)
 {
int prox_history[MAX_SAMPLES_CAL + 1];
-   int i;
+   int i, ret;
struct tsl2x7x_prox_stat prox_stat_data[2];
struct tsl2x7x_prox_stat *cal;
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
@@ -825,25 +825,33 @@ static void tsl2x7x_prox_cal(struct iio_dev *indio_dev)
}
 
/* have to stop to change settings */
-   tsl2x7x_chip_off(indio_dev);
+   ret = tsl2x7x_chip_off(indio_dev);
+   if (ret < 0)
+   return ret;
 
/* Enable proximity detection save just in case prox not wanted yet*/
tmp_irq_settings = chip->settings.interrupts_en;
chip->settings.interrupts_en |= TSL2X7X_CNTL_PROX_INT_ENBL;
 
/*turn on device if not already on*/
-   tsl2x7x_chip_on(indio_dev);
+   ret = tsl2x7x_chip_on(indio_dev);
+   if (ret < 0)
+   return ret;
 
/*gather the samples*/
for (i = 0; i < chip->settings.prox_max_samples_cal; i++) {
usleep_range(15000, 17500);
-   tsl2x7x_get_prox(indio_dev);
+   ret = tsl2x7x_get_prox(indio_dev);
+   if (ret < 0)
+   return ret;
prox_history[i] = chip->prox_data;
dev_info(>client->dev, "2 i=%d prox data= %d\n",
 i, chip->prox_data);
}
 
-   tsl2x7x_chip_off(indio_dev);
+   ret = tsl2x7x_chip_off(indio_dev);
+   if (ret < 0)
+   return ret;
cal = _stat_data[PROX_STAT_CAL];
tsl2x7x_prox_calculate(prox_history,
   chip->settings.prox_max_samples_cal, cal);
@@ -857,8 +865,13 @@ static void tsl2x7x_prox_cal(struct iio_dev *indio_dev)
 
/* back to the way they were */
chip->settings.interrupts_en = tmp_irq_settings;
-   if (current_state == TSL2X7X_CHIP_WORKING)
-   tsl2x7x_chip_on(indio_dev);
+   if (current_state == TSL2X7X_CHIP_WORKING) {
+   ret = tsl2x7x_chip_on(indio_dev);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
 }
 
 static ssize_t
@@ -1018,8 +1031,11 @@ static ssize_t in_proximity0_calibrate_store(struct 
device *dev,
if (strtobool(buf, ))
return -EINVAL;
 
-   if (value)
-   tsl2x7x_prox_cal(indio_dev);
+   if (value) {
+   ret = tsl2x7x_prox_cal(indio_dev);
+   if (ret < 0)
+   return ret;
+   }
 
ret = tsl2x7x_invoke_change(indio_dev);
if (ret < 0)
-- 
2.14.3



[PATCH 03/12] staging: iio: tsl2x7x: add common function for reading chip status

2018-03-03 Thread Brian Masney
There were three places where the same chunk of code was used to read
the chip status. This patch creates a common function
tsl2x7x_read_status() to reduce duplicate code. This patch also corrects
tsl2x7x_event_handler() to properly check for an error after reading the
chip status.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 40 ++---
 1 file changed, 24 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index c02db03ef369..6bb622816660 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -293,6 +293,20 @@ static int tsl2x7x_clear_interrupts(struct tsl2X7X_chip 
*chip, int reg)
return ret;
 }
 
+static int tsl2x7x_read_status(struct tsl2X7X_chip *chip)
+{
+   int ret;
+
+   ret = i2c_smbus_read_byte_data(chip->client,
+  TSL2X7X_CMD_REG | TSL2X7X_STATUS);
+   if (ret < 0)
+   dev_err(>client->dev,
+   "%s: failed to read STATUS register: %d\n", __func__,
+   ret);
+
+   return ret;
+}
+
 /**
  * tsl2x7x_get_lux() - Reads and calculates current lux value.
  * @indio_dev: pointer to IIO device
@@ -332,13 +346,10 @@ static int tsl2x7x_get_lux(struct iio_dev *indio_dev)
goto out_unlock;
}
 
-   ret = i2c_smbus_read_byte_data(chip->client,
-  TSL2X7X_CMD_REG | TSL2X7X_STATUS);
-   if (ret < 0) {
-   dev_err(>client->dev,
-   "%s: Failed to read STATUS Reg\n", __func__);
+   ret = tsl2x7x_read_status(chip);
+   if (ret < 0)
goto out_unlock;
-   }
+
/* is data new & valid */
if (!(ret & TSL2X7X_STA_ADC_VALID)) {
dev_err(>client->dev,
@@ -458,12 +469,9 @@ static int tsl2x7x_get_prox(struct iio_dev *indio_dev)
return -EBUSY;
}
 
-   ret = i2c_smbus_read_byte_data(chip->client,
-  TSL2X7X_CMD_REG | TSL2X7X_STATUS);
-   if (ret < 0) {
-   dev_err(>client->dev, "i2c err=%d\n", ret);
+   ret = tsl2x7x_read_status(chip);
+   if (ret < 0)
goto prox_poll_err;
-   }
 
switch (chip->id) {
case tsl2571:
@@ -1396,13 +1404,13 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
s64 timestamp = iio_get_time_ns(indio_dev);
int ret;
-   u8 value;
 
-   value = i2c_smbus_read_byte_data(chip->client,
-TSL2X7X_CMD_REG | TSL2X7X_STATUS);
+   ret = tsl2x7x_read_status(chip);
+   if (ret < 0)
+   return ret;
 
/* What type of interrupt do we need to process */
-   if (value & TSL2X7X_STA_PRX_INTR) {
+   if (ret & TSL2X7X_STA_PRX_INTR) {
tsl2x7x_get_prox(indio_dev); /* freshen data for ABI */
iio_push_event(indio_dev,
   IIO_UNMOD_EVENT_CODE(IIO_PROXIMITY,
@@ -1412,7 +1420,7 @@ static irqreturn_t tsl2x7x_event_handler(int irq, void 
*private)
timestamp);
}
 
-   if (value & TSL2X7X_STA_ALS_INTR) {
+   if (ret & TSL2X7X_STA_ALS_INTR) {
tsl2x7x_get_lux(indio_dev); /* freshen data for ABI */
iio_push_event(indio_dev,
   IIO_UNMOD_EVENT_CODE(IIO_LIGHT,
-- 
2.14.3



[PATCH 06/12] staging: iio: tsl2x7x: correctly return errors in tsl2x7x_get_prox()

2018-03-03 Thread Brian Masney
Not all errors that occurred in tsl2x7x_get_prox() were correctly
reported in the return value. This patch changes the error handling
so that errors are now returned properly.

Note that the ret variable is from the call to tsl2x7x_read_status(),
and it already has the correct error check. The -EINVAL error code is
for an unexpected value in the register.

This patch also corrects an unnecessary word wrap in the call to
le16_to_cpup() while changes are being made to this code.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 5c611250127f..cc209b64ed5a 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -489,16 +489,20 @@ static int tsl2x7x_get_prox(struct iio_dev *indio_dev)
case tmd2671:
case tsl2771:
case tmd2771:
-   if (!(ret & TSL2X7X_STA_ADC_VALID))
+   if (!(ret & TSL2X7X_STA_ADC_VALID)) {
+   ret = -EINVAL;
goto prox_poll_err;
+   }
break;
case tsl2572:
case tsl2672:
case tmd2672:
case tsl2772:
case tmd2772:
-   if (!(ret & TSL2X7X_STA_PRX_VALID))
+   if (!(ret & TSL2X7X_STA_PRX_VALID)) {
+   ret = -EINVAL;
goto prox_poll_err;
+   }
break;
}
 
@@ -512,14 +516,13 @@ static int tsl2x7x_get_prox(struct iio_dev *indio_dev)
chdata[i] = ret;
}
 
-   chip->prox_data =
-   le16_to_cpup((const __le16 *)[0]);
+   chip->prox_data = le16_to_cpup((const __le16 *)[0]);
+   ret = chip->prox_data;
 
 prox_poll_err:
-
mutex_unlock(>prox_mutex);
 
-   return chip->prox_data;
+   return ret;
 }
 
 /**
-- 
2.14.3



[PATCH 11/12] staging: iio: tsl2x7x: remove unnecessary sysfs attribute

2018-03-03 Thread Brian Masney
The tsl2771 and tmd2771 devices create the
in_proximity0_calibscale_available sysfs attribute. These two particular
devices do not support changing the proximity gain value on the
chip so this patch removes that sysfs attribute. As expected, these two
devices already did not create the IIO_CHAN_INFO_CALIBSCALE channel and
proximity0_calibrate sysfs attribute.

Page 38 of the tsl2772 data sheet shows that the proximity gain can be
adjusted with bits 2-3 on the control register:
https://ams.com/eng/content/download/291503/1066377/file/TSL2772_DS000181_2-00.pdf

Page 35 of the tsl2771 and tmd2771 data sheets shows that bits 2-3 on
the control register are reserved and changing the proximity gain is
not supported:
https://ams.com/eng/content/download/250264/976045/file/TSL2771_DS000105_3-00.pdf
https://ams.com/eng/content/download/250283/976077/file/TMD2771_DS000177_2-00.pdf

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index fb91c46c8747..8c29a52153c1 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -1477,7 +1477,6 @@ static struct attribute *tsl2x7x_ALSPRX_device_attrs[] = {
_attr_in_illuminance0_target_input.attr,
_attr_in_illuminance0_calibrate.attr,
_attr_in_illuminance0_lux_table.attr,
-   _const_attr_in_proximity0_calibscale_available.dev_attr.attr,
NULL
 };
 
-- 
2.14.3



[PATCH 01/12] staging: iio: tsl2x7x: remove power functions from tsl2X7X_platform_data

2018-03-03 Thread Brian Masney
The tsl2X7X_platform_data structure contains the platform_power,
power_on, and power_off function pointers. These power management
functions should not be in the platform data. These functions were
likely used before the regulator framework was put in place. There are
no users of these functions in the mainline kernel.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 18 --
 drivers/staging/iio/light/tsl2x7x.h |  4 
 2 files changed, 22 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 126e11530ce0..b7e3f966c3a6 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -588,9 +588,6 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
u8 reg_val = 0;
 
-   if (chip->pdata && chip->pdata->power_on)
-   chip->pdata->power_on(indio_dev);
-
/* Non calculated parameters */
chip->tsl2x7x_config[TSL2X7X_PRX_TIME] = chip->settings.prx_time;
chip->tsl2x7x_config[TSL2X7X_WAIT_TIME] = chip->settings.wait_time;
@@ -736,9 +733,6 @@ static int tsl2x7x_chip_off(struct iio_dev *indio_dev)
ret = i2c_smbus_write_byte_data(chip->client,
TSL2X7X_CMD_REG | TSL2X7X_CNTRL, 0x00);
 
-   if (chip->pdata && chip->pdata->power_off)
-   chip->pdata->power_off(chip->client);
-
return ret;
 }
 
@@ -1792,12 +1786,6 @@ static int tsl2x7x_suspend(struct device *dev)
chip->tsl2x7x_chip_status = TSL2X7X_CHIP_SUSPENDED;
}
 
-   if (chip->pdata && chip->pdata->platform_power) {
-   pm_message_t pmm = {PM_EVENT_SUSPEND};
-
-   chip->pdata->platform_power(dev, pmm);
-   }
-
return ret;
 }
 
@@ -1807,12 +1795,6 @@ static int tsl2x7x_resume(struct device *dev)
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
int ret = 0;
 
-   if (chip->pdata && chip->pdata->platform_power) {
-   pm_message_t pmm = {PM_EVENT_RESUME};
-
-   chip->pdata->platform_power(dev, pmm);
-   }
-
if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_SUSPENDED)
ret = tsl2x7x_chip_on(indio_dev);
 
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index df00f2ec1719..6624cbca7a83 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -21,7 +21,6 @@
 
 #ifndef __TSL2X7X_H
 #define __TSL2X7X_H
-#include 
 
 struct tsl2x7x_lux {
unsigned int ratio;
@@ -91,9 +90,6 @@ struct tsl2x7x_settings {
  *
  */
 struct tsl2X7X_platform_data {
-   int (*platform_power)(struct device *dev, pm_message_t);
-   int (*power_on)(struct iio_dev *indio_dev);
-   int (*power_off)(struct i2c_client *dev);
struct tsl2x7x_lux platform_lux_table[TSL2X7X_MAX_LUX_TABLE_SIZE];
struct tsl2x7x_settings *platform_default_settings;
 };
-- 
2.14.3



[PATCH 00/12] staging cleanups

2018-03-03 Thread Brian Masney
Here is another patch series that inches the driver closer to moving out
of staging. The most interesting changes are the last two in the series.
One gets the proximity sensor working and the other one removes the
unnecessary in_proximity0_calibscale_available sysfs attribute from two
of the supported devices. The rest of the patches are not that
interesting and either reduce duplicate code, add error handling, or
other minor cosmetic changes.

Brian Masney (12):
  staging: iio: tsl2x7x: remove power functions from
tsl2X7X_platform_data
  staging: iio: tsl2x7x: add common function for clearing interrupts
  staging: iio: tsl2x7x: add common function for reading chip status
  staging: iio: tsl2x7x: add common function for writing to the control
register
  staging: iio: tsl2x7x: convert mutex_trylock() to mutex_lock()
  staging: iio: tsl2x7x: correctly return errors in tsl2x7x_get_prox()
  staging: iio: tsl2x7x: correct 'Avoid CamelCase' warning from
checkpatch
  staging: iio: tsl2x7x: add error handling to tsl2x7x_prox_cal()
  staging: iio: tsl2x7x: add missing error checks
  staging: iio: tsl2x7x: make logging consistent and correct newlines
  staging: iio: tsl2x7x: remove unnecessary sysfs attribute
  staging: iio: tsl2x7x: make proximity sensor function correctly

 drivers/staging/iio/light/tsl2x7x.c | 346 ++--
 drivers/staging/iio/light/tsl2x7x.h |   6 +-
 2 files changed, 179 insertions(+), 173 deletions(-)

-- 
2.14.3



[PATCH 09/12] staging: iio: tsl2x7x: add missing error checks

2018-03-03 Thread Brian Masney
The functions in_illuminance0_calibrate_store() and
in_illuminance0_lux_table_store() did not have complete error handling
in place. This patch adds the missing error handling.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 8adc6db44790..da7a4e025083 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -940,8 +940,11 @@ static ssize_t in_illuminance0_calibrate_store(struct 
device *dev,
if (strtobool(buf, ))
return -EINVAL;
 
-   if (value)
-   tsl2x7x_als_calibrate(indio_dev);
+   if (value) {
+   ret = tsl2x7x_als_calibrate(indio_dev);
+   if (ret < 0)
+   return ret;
+   }
 
ret = tsl2x7x_invoke_change(indio_dev);
if (ret < 0)
@@ -1006,8 +1009,11 @@ static ssize_t in_illuminance0_lux_table_store(struct 
device *dev,
return -EINVAL;
}
 
-   if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_WORKING)
-   tsl2x7x_chip_off(indio_dev);
+   if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_WORKING) {
+   ret = tsl2x7x_chip_off(indio_dev);
+   if (ret < 0)
+   return ret;
+   }
 
/* Zero out the table */
memset(chip->tsl2x7x_device_lux, 0, sizeof(chip->tsl2x7x_device_lux));
-- 
2.14.3



[PATCH 07/12] staging: iio: tsl2x7x: correct 'Avoid CamelCase' warning from checkpatch

2018-03-03 Thread Brian Masney
The statP and calP variables triggered an 'Avoid CamelCase' warning
from checkpatch.pl. This patch renames these variables to stat and cal
to fix this warning.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index cc209b64ed5a..380a6c96a69a 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -773,7 +773,7 @@ static int tsl2x7x_invoke_change(struct iio_dev *indio_dev)
 }
 
 static void tsl2x7x_prox_calculate(int *data, int length,
-  struct tsl2x7x_prox_stat *statP)
+  struct tsl2x7x_prox_stat *stat)
 {
int i;
int sample_sum;
@@ -783,21 +783,21 @@ static void tsl2x7x_prox_calculate(int *data, int length,
length = 1;
 
sample_sum = 0;
-   statP->min = INT_MAX;
-   statP->max = INT_MIN;
+   stat->min = INT_MAX;
+   stat->max = INT_MIN;
for (i = 0; i < length; i++) {
sample_sum += data[i];
-   statP->min = min(statP->min, data[i]);
-   statP->max = max(statP->max, data[i]);
+   stat->min = min(stat->min, data[i]);
+   stat->max = max(stat->max, data[i]);
}
 
-   statP->mean = sample_sum / length;
+   stat->mean = sample_sum / length;
sample_sum = 0;
for (i = 0; i < length; i++) {
-   tmp = data[i] - statP->mean;
+   tmp = data[i] - stat->mean;
sample_sum += tmp * tmp;
}
-   statP->stddev = int_sqrt((long)sample_sum / length);
+   stat->stddev = int_sqrt((long)sample_sum / length);
 }
 
 /**
@@ -812,7 +812,7 @@ static void tsl2x7x_prox_cal(struct iio_dev *indio_dev)
int prox_history[MAX_SAMPLES_CAL + 1];
int i;
struct tsl2x7x_prox_stat prox_stat_data[2];
-   struct tsl2x7x_prox_stat *calP;
+   struct tsl2x7x_prox_stat *cal;
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
u8 tmp_irq_settings;
u8 current_state = chip->tsl2x7x_chip_status;
@@ -844,13 +844,13 @@ static void tsl2x7x_prox_cal(struct iio_dev *indio_dev)
}
 
tsl2x7x_chip_off(indio_dev);
-   calP = _stat_data[PROX_STAT_CAL];
+   cal = _stat_data[PROX_STAT_CAL];
tsl2x7x_prox_calculate(prox_history,
-  chip->settings.prox_max_samples_cal, calP);
-   chip->settings.prox_thres_high = (calP->max << 1) - calP->mean;
+  chip->settings.prox_max_samples_cal, cal);
+   chip->settings.prox_thres_high = (cal->max << 1) - cal->mean;
 
dev_info(>client->dev, " cal min=%d mean=%d max=%d\n",
-calP->min, calP->mean, calP->max);
+cal->min, cal->mean, cal->max);
dev_info(>client->dev,
 "%s proximity threshold set to %d\n",
 chip->client->name, chip->settings.prox_thres_high);
-- 
2.14.3



[PATCH 12/12] staging: iio: tsl2x7x: make proximity sensor function correctly

2018-03-03 Thread Brian Masney
The bits for setting up the proximity diode were not setup correctly and
this was causing the proximity sensor to not function correctly. This
patch sets up the correct bit mask in tsl2x7x_chip_on() based on what
the data sheet expects. From page 35 of the TSL2771 data sheet:
https://ams.com/eng/content/download/250264/976045/file/TSL2771_DS000105_3-00.pdf

- Bits 0-1 is the ALS gain control
- Bits 2-3 is reserved (The proximity gain control on other tsl2x7x chips)
- Bits 4-5 is the proximity diode select
- Bits 6-7 is the LED drive strength

tsl2x7x_chip_on() had the power and diode hardcoded, so these are
extracted out into the settings so that these fields can be configured
in the platform data.

The default prox_gain is changed from 1 (2X gain) to 0 (1X gain) since
the proximity gain control on the TSL2771, TMD2771, and other chips have
these fields listed as reserved, and to write 0 into those bits.

Verified that the proximity sensor now works correctly on a TSL2771
hooked up to a Raspberry Pi 2.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 25 ++---
 drivers/staging/iio/light/tsl2x7x.h |  2 ++
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 8c29a52153c1..ab518cdec43e 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -109,15 +109,15 @@
 #define TSL2X7X_CNTL_INTPROXPON_ENBL   0x2F
 
 /*Prox diode to use */
-#define TSL2X7X_DIODE0 0x10
-#define TSL2X7X_DIODE1 0x20
-#define TSL2X7X_DIODE_BOTH 0x30
+#define TSL2X7X_DIODE0 0x01
+#define TSL2X7X_DIODE1 0x02
+#define TSL2X7X_DIODE_BOTH 0x03
 
 /* LED Power */
 #define TSL2X7X_100_mA 0x00
-#define TSL2X7X_50_mA  0x40
-#define TSL2X7X_25_mA  0x80
-#define TSL2X7X_13_mA  0xD0
+#define TSL2X7X_50_mA  0x01
+#define TSL2X7X_25_mA  0x02
+#define TSL2X7X_13_mA  0x03
 #define TSL2X7X_MAX_TIMER_CNT  0xFF
 
 #define TSL2X7X_MIN_ITIME  3
@@ -228,7 +228,7 @@ static const struct tsl2x7x_settings 
tsl2x7x_default_settings = {
.als_time = 219, /* 101 ms */
.als_gain = 0,
.prx_time = 254, /* 5.4 ms */
-   .prox_gain = 1,
+   .prox_gain = 0,
.wait_time = 245,
.prox_config = 0,
.als_gain_trim = 1000,
@@ -240,7 +240,9 @@ static const struct tsl2x7x_settings 
tsl2x7x_default_settings = {
.prox_thres_low  = 0,
.prox_thres_high = 512,
.prox_max_samples_cal = 30,
-   .prox_pulse_count = 8
+   .prox_pulse_count = 8,
+   .prox_diode = TSL2X7X_DIODE1,
+   .prox_power = TSL2X7X_100_mA
 };
 
 static const s16 tsl2x7x_als_gain[] = {
@@ -664,9 +666,10 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
 
/* Set the gain based on tsl2x7x_settings struct */
chip->tsl2x7x_config[TSL2X7X_GAIN] =
-   chip->settings.als_gain |
-   (TSL2X7X_100_mA | TSL2X7X_DIODE1) |
-   (chip->settings.prox_gain << 2);
+   (chip->settings.als_gain & 0xFF) |
+   ((chip->settings.prox_gain & 0xFF) << 2) |
+   (chip->settings.prox_diode << 4) |
+   (chip->settings.prox_power << 6);
 
/* set chip struct re scaling and saturation */
chip->als_saturation = als_count * 922; /* 90% of full scale */
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index 6624cbca7a83..28b0e7fdc9b8 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -78,6 +78,8 @@ struct tsl2x7x_settings {
int prox_thres_high;
int prox_pulse_count;
int prox_max_samples_cal;
+   int prox_diode;
+   int prox_power;
 };
 
 /**
-- 
2.14.3



[PATCH 09/12] staging: iio: tsl2x7x: add missing error checks

2018-03-03 Thread Brian Masney
The functions in_illuminance0_calibrate_store() and
in_illuminance0_lux_table_store() did not have complete error handling
in place. This patch adds the missing error handling.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 8adc6db44790..da7a4e025083 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -940,8 +940,11 @@ static ssize_t in_illuminance0_calibrate_store(struct 
device *dev,
if (strtobool(buf, ))
return -EINVAL;
 
-   if (value)
-   tsl2x7x_als_calibrate(indio_dev);
+   if (value) {
+   ret = tsl2x7x_als_calibrate(indio_dev);
+   if (ret < 0)
+   return ret;
+   }
 
ret = tsl2x7x_invoke_change(indio_dev);
if (ret < 0)
@@ -1006,8 +1009,11 @@ static ssize_t in_illuminance0_lux_table_store(struct 
device *dev,
return -EINVAL;
}
 
-   if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_WORKING)
-   tsl2x7x_chip_off(indio_dev);
+   if (chip->tsl2x7x_chip_status == TSL2X7X_CHIP_WORKING) {
+   ret = tsl2x7x_chip_off(indio_dev);
+   if (ret < 0)
+   return ret;
+   }
 
/* Zero out the table */
memset(chip->tsl2x7x_device_lux, 0, sizeof(chip->tsl2x7x_device_lux));
-- 
2.14.3



[PATCH 07/12] staging: iio: tsl2x7x: correct 'Avoid CamelCase' warning from checkpatch

2018-03-03 Thread Brian Masney
The statP and calP variables triggered an 'Avoid CamelCase' warning
from checkpatch.pl. This patch renames these variables to stat and cal
to fix this warning.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index cc209b64ed5a..380a6c96a69a 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -773,7 +773,7 @@ static int tsl2x7x_invoke_change(struct iio_dev *indio_dev)
 }
 
 static void tsl2x7x_prox_calculate(int *data, int length,
-  struct tsl2x7x_prox_stat *statP)
+  struct tsl2x7x_prox_stat *stat)
 {
int i;
int sample_sum;
@@ -783,21 +783,21 @@ static void tsl2x7x_prox_calculate(int *data, int length,
length = 1;
 
sample_sum = 0;
-   statP->min = INT_MAX;
-   statP->max = INT_MIN;
+   stat->min = INT_MAX;
+   stat->max = INT_MIN;
for (i = 0; i < length; i++) {
sample_sum += data[i];
-   statP->min = min(statP->min, data[i]);
-   statP->max = max(statP->max, data[i]);
+   stat->min = min(stat->min, data[i]);
+   stat->max = max(stat->max, data[i]);
}
 
-   statP->mean = sample_sum / length;
+   stat->mean = sample_sum / length;
sample_sum = 0;
for (i = 0; i < length; i++) {
-   tmp = data[i] - statP->mean;
+   tmp = data[i] - stat->mean;
sample_sum += tmp * tmp;
}
-   statP->stddev = int_sqrt((long)sample_sum / length);
+   stat->stddev = int_sqrt((long)sample_sum / length);
 }
 
 /**
@@ -812,7 +812,7 @@ static void tsl2x7x_prox_cal(struct iio_dev *indio_dev)
int prox_history[MAX_SAMPLES_CAL + 1];
int i;
struct tsl2x7x_prox_stat prox_stat_data[2];
-   struct tsl2x7x_prox_stat *calP;
+   struct tsl2x7x_prox_stat *cal;
struct tsl2X7X_chip *chip = iio_priv(indio_dev);
u8 tmp_irq_settings;
u8 current_state = chip->tsl2x7x_chip_status;
@@ -844,13 +844,13 @@ static void tsl2x7x_prox_cal(struct iio_dev *indio_dev)
}
 
tsl2x7x_chip_off(indio_dev);
-   calP = _stat_data[PROX_STAT_CAL];
+   cal = _stat_data[PROX_STAT_CAL];
tsl2x7x_prox_calculate(prox_history,
-  chip->settings.prox_max_samples_cal, calP);
-   chip->settings.prox_thres_high = (calP->max << 1) - calP->mean;
+  chip->settings.prox_max_samples_cal, cal);
+   chip->settings.prox_thres_high = (cal->max << 1) - cal->mean;
 
dev_info(>client->dev, " cal min=%d mean=%d max=%d\n",
-calP->min, calP->mean, calP->max);
+cal->min, cal->mean, cal->max);
dev_info(>client->dev,
 "%s proximity threshold set to %d\n",
 chip->client->name, chip->settings.prox_thres_high);
-- 
2.14.3



[PATCH 12/12] staging: iio: tsl2x7x: make proximity sensor function correctly

2018-03-03 Thread Brian Masney
The bits for setting up the proximity diode were not setup correctly and
this was causing the proximity sensor to not function correctly. This
patch sets up the correct bit mask in tsl2x7x_chip_on() based on what
the data sheet expects. From page 35 of the TSL2771 data sheet:
https://ams.com/eng/content/download/250264/976045/file/TSL2771_DS000105_3-00.pdf

- Bits 0-1 is the ALS gain control
- Bits 2-3 is reserved (The proximity gain control on other tsl2x7x chips)
- Bits 4-5 is the proximity diode select
- Bits 6-7 is the LED drive strength

tsl2x7x_chip_on() had the power and diode hardcoded, so these are
extracted out into the settings so that these fields can be configured
in the platform data.

The default prox_gain is changed from 1 (2X gain) to 0 (1X gain) since
the proximity gain control on the TSL2771, TMD2771, and other chips have
these fields listed as reserved, and to write 0 into those bits.

Verified that the proximity sensor now works correctly on a TSL2771
hooked up to a Raspberry Pi 2.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/tsl2x7x.c | 25 ++---
 drivers/staging/iio/light/tsl2x7x.h |  2 ++
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/iio/light/tsl2x7x.c 
b/drivers/staging/iio/light/tsl2x7x.c
index 8c29a52153c1..ab518cdec43e 100644
--- a/drivers/staging/iio/light/tsl2x7x.c
+++ b/drivers/staging/iio/light/tsl2x7x.c
@@ -109,15 +109,15 @@
 #define TSL2X7X_CNTL_INTPROXPON_ENBL   0x2F
 
 /*Prox diode to use */
-#define TSL2X7X_DIODE0 0x10
-#define TSL2X7X_DIODE1 0x20
-#define TSL2X7X_DIODE_BOTH 0x30
+#define TSL2X7X_DIODE0 0x01
+#define TSL2X7X_DIODE1 0x02
+#define TSL2X7X_DIODE_BOTH 0x03
 
 /* LED Power */
 #define TSL2X7X_100_mA 0x00
-#define TSL2X7X_50_mA  0x40
-#define TSL2X7X_25_mA  0x80
-#define TSL2X7X_13_mA  0xD0
+#define TSL2X7X_50_mA  0x01
+#define TSL2X7X_25_mA  0x02
+#define TSL2X7X_13_mA  0x03
 #define TSL2X7X_MAX_TIMER_CNT  0xFF
 
 #define TSL2X7X_MIN_ITIME  3
@@ -228,7 +228,7 @@ static const struct tsl2x7x_settings 
tsl2x7x_default_settings = {
.als_time = 219, /* 101 ms */
.als_gain = 0,
.prx_time = 254, /* 5.4 ms */
-   .prox_gain = 1,
+   .prox_gain = 0,
.wait_time = 245,
.prox_config = 0,
.als_gain_trim = 1000,
@@ -240,7 +240,9 @@ static const struct tsl2x7x_settings 
tsl2x7x_default_settings = {
.prox_thres_low  = 0,
.prox_thres_high = 512,
.prox_max_samples_cal = 30,
-   .prox_pulse_count = 8
+   .prox_pulse_count = 8,
+   .prox_diode = TSL2X7X_DIODE1,
+   .prox_power = TSL2X7X_100_mA
 };
 
 static const s16 tsl2x7x_als_gain[] = {
@@ -664,9 +666,10 @@ static int tsl2x7x_chip_on(struct iio_dev *indio_dev)
 
/* Set the gain based on tsl2x7x_settings struct */
chip->tsl2x7x_config[TSL2X7X_GAIN] =
-   chip->settings.als_gain |
-   (TSL2X7X_100_mA | TSL2X7X_DIODE1) |
-   (chip->settings.prox_gain << 2);
+   (chip->settings.als_gain & 0xFF) |
+   ((chip->settings.prox_gain & 0xFF) << 2) |
+   (chip->settings.prox_diode << 4) |
+   (chip->settings.prox_power << 6);
 
/* set chip struct re scaling and saturation */
chip->als_saturation = als_count * 922; /* 90% of full scale */
diff --git a/drivers/staging/iio/light/tsl2x7x.h 
b/drivers/staging/iio/light/tsl2x7x.h
index 6624cbca7a83..28b0e7fdc9b8 100644
--- a/drivers/staging/iio/light/tsl2x7x.h
+++ b/drivers/staging/iio/light/tsl2x7x.h
@@ -78,6 +78,8 @@ struct tsl2x7x_settings {
int prox_thres_high;
int prox_pulse_count;
int prox_max_samples_cal;
+   int prox_diode;
+   int prox_power;
 };
 
 /**
-- 
2.14.3



[PATCH] usb: dwc2: detect power supplies to reduce spam

2018-03-03 Thread Ioan-Adrian Ratiu
By statically hardcoding at compile time the number of supplies
("#define DWC2_NUM_SUPPLIES ARRAY_SIZE(dwc2_hsotg_supply_names)"), the
driver assumed that every controller uses supplies and issued a
warning if none were detected via the device tree [1], even though the
vast majority of devices (with 1 exception from Samsung) don't need
nor use them.

So to return to normality and stop warning everyone unconditionally,
detect if there are any supplies and no-op just like the dummy
regulator which got loudly auto-asigned does.

This issue has been previously discussed based on an alternative fix
at [2] a year back but nothing came out of it then.

[1]
dwc2 3f98.usb: 3f98.usb supply vusb_d not found, using dummy regulator
dwc2 3f98.usb: 3f98.usb supply vusb_a not found, using dummy regulator

[2]
https://www.spinics.net/lists/linux-usb/msg153010.html

Signed-off-by: Ioan-Adrian Ratiu 
---
 drivers/usb/dwc2/core.h |  5 +++--
 drivers/usb/dwc2/platform.c | 46 +++--
 2 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index cd77af3b1565..c50b9fc4a162 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -128,7 +128,7 @@ static const char * const dwc2_hsotg_supply_names[] = {
"vusb_a",   /* analog USB supply, 1.1V */
 };
 
-#define DWC2_NUM_SUPPLIES ARRAY_SIZE(dwc2_hsotg_supply_names)
+#define DWC2_MAX_SUPPLIES ARRAY_SIZE(dwc2_hsotg_supply_names)
 
 /*
  * EP0_MPS_LIMIT
@@ -921,7 +921,8 @@ struct dwc2_hsotg {
struct phy *phy;
struct usb_phy *uphy;
struct dwc2_hsotg_plat *plat;
-   struct regulator_bulk_data supplies[DWC2_NUM_SUPPLIES];
+   struct regulator_bulk_data supplies[DWC2_MAX_SUPPLIES];
+   u8 num_supplies;
u32 phyif;
 
spinlock_t lock;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 4703478f702f..3acf658af4e9 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -126,10 +126,12 @@ static int __dwc2_lowlevel_hw_enable(struct dwc2_hsotg 
*hsotg)
struct platform_device *pdev = to_platform_device(hsotg->dev);
int ret;
 
-   ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
-   hsotg->supplies);
-   if (ret)
-   return ret;
+   if (hsotg->num_supplies) {
+   ret = regulator_bulk_enable(hsotg->num_supplies,
+   hsotg->supplies);
+   if (ret)
+   return ret;
+   }
 
if (hsotg->clk) {
ret = clk_prepare_enable(hsotg->clk);
@@ -186,8 +188,9 @@ static int __dwc2_lowlevel_hw_disable(struct dwc2_hsotg 
*hsotg)
if (hsotg->clk)
clk_disable_unprepare(hsotg->clk);
 
-   ret = regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies),
-hsotg->supplies);
+   if (hsotg->num_supplies)
+   ret = regulator_bulk_disable(hsotg->num_supplies,
+hsotg->supplies);
 
return ret;
 }
@@ -210,6 +213,7 @@ int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
 
 static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
 {
+   struct regulator *reg;
int i, ret;
 
hsotg->reset = devm_reset_control_get_optional(hsotg->dev, "dwc2");
@@ -290,16 +294,30 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
dev_dbg(hsotg->dev, "cannot get otg clock\n");
}
 
-   /* Regulators */
-   for (i = 0; i < ARRAY_SIZE(hsotg->supplies); i++)
-   hsotg->supplies[i].supply = dwc2_hsotg_supply_names[i];
+   /* Regulators, vast majority of dwc2 devices don't use them at all */
+   for (i = 0; i < DWC2_MAX_SUPPLIES; i++) {
+   reg = regulator_get_optional(hsotg->dev,
+dwc2_hsotg_supply_names[i]);
+
+   /* All or nothing (bulk): regs either are or aren't present */
+   if (IS_ERR(reg)) {
+   while (--i >= 0) {
+   regulator_put(hsotg->supplies[i].consumer);
+   hsotg->supplies[i].consumer = NULL;
+   hsotg->supplies[i].supply = NULL;
+   --hsotg->num_supplies;
+   }
+   break;
+   }
 
-   ret = devm_regulator_bulk_get(hsotg->dev, ARRAY_SIZE(hsotg->supplies),
- hsotg->supplies);
-   if (ret) {
-   dev_err(hsotg->dev, "failed to request supplies: %d\n", ret);
-   return ret;
+   hsotg->supplies[i].consumer = reg;
+   hsotg->supplies[i].supply = dwc2_hsotg_supply_names[i];
+   ++hsotg->num_supplies;
}
+
+   

[PATCH] usb: dwc2: detect power supplies to reduce spam

2018-03-03 Thread Ioan-Adrian Ratiu
By statically hardcoding at compile time the number of supplies
("#define DWC2_NUM_SUPPLIES ARRAY_SIZE(dwc2_hsotg_supply_names)"), the
driver assumed that every controller uses supplies and issued a
warning if none were detected via the device tree [1], even though the
vast majority of devices (with 1 exception from Samsung) don't need
nor use them.

So to return to normality and stop warning everyone unconditionally,
detect if there are any supplies and no-op just like the dummy
regulator which got loudly auto-asigned does.

This issue has been previously discussed based on an alternative fix
at [2] a year back but nothing came out of it then.

[1]
dwc2 3f98.usb: 3f98.usb supply vusb_d not found, using dummy regulator
dwc2 3f98.usb: 3f98.usb supply vusb_a not found, using dummy regulator

[2]
https://www.spinics.net/lists/linux-usb/msg153010.html

Signed-off-by: Ioan-Adrian Ratiu 
---
 drivers/usb/dwc2/core.h |  5 +++--
 drivers/usb/dwc2/platform.c | 46 +++--
 2 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index cd77af3b1565..c50b9fc4a162 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -128,7 +128,7 @@ static const char * const dwc2_hsotg_supply_names[] = {
"vusb_a",   /* analog USB supply, 1.1V */
 };
 
-#define DWC2_NUM_SUPPLIES ARRAY_SIZE(dwc2_hsotg_supply_names)
+#define DWC2_MAX_SUPPLIES ARRAY_SIZE(dwc2_hsotg_supply_names)
 
 /*
  * EP0_MPS_LIMIT
@@ -921,7 +921,8 @@ struct dwc2_hsotg {
struct phy *phy;
struct usb_phy *uphy;
struct dwc2_hsotg_plat *plat;
-   struct regulator_bulk_data supplies[DWC2_NUM_SUPPLIES];
+   struct regulator_bulk_data supplies[DWC2_MAX_SUPPLIES];
+   u8 num_supplies;
u32 phyif;
 
spinlock_t lock;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 4703478f702f..3acf658af4e9 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -126,10 +126,12 @@ static int __dwc2_lowlevel_hw_enable(struct dwc2_hsotg 
*hsotg)
struct platform_device *pdev = to_platform_device(hsotg->dev);
int ret;
 
-   ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
-   hsotg->supplies);
-   if (ret)
-   return ret;
+   if (hsotg->num_supplies) {
+   ret = regulator_bulk_enable(hsotg->num_supplies,
+   hsotg->supplies);
+   if (ret)
+   return ret;
+   }
 
if (hsotg->clk) {
ret = clk_prepare_enable(hsotg->clk);
@@ -186,8 +188,9 @@ static int __dwc2_lowlevel_hw_disable(struct dwc2_hsotg 
*hsotg)
if (hsotg->clk)
clk_disable_unprepare(hsotg->clk);
 
-   ret = regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies),
-hsotg->supplies);
+   if (hsotg->num_supplies)
+   ret = regulator_bulk_disable(hsotg->num_supplies,
+hsotg->supplies);
 
return ret;
 }
@@ -210,6 +213,7 @@ int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
 
 static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
 {
+   struct regulator *reg;
int i, ret;
 
hsotg->reset = devm_reset_control_get_optional(hsotg->dev, "dwc2");
@@ -290,16 +294,30 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
dev_dbg(hsotg->dev, "cannot get otg clock\n");
}
 
-   /* Regulators */
-   for (i = 0; i < ARRAY_SIZE(hsotg->supplies); i++)
-   hsotg->supplies[i].supply = dwc2_hsotg_supply_names[i];
+   /* Regulators, vast majority of dwc2 devices don't use them at all */
+   for (i = 0; i < DWC2_MAX_SUPPLIES; i++) {
+   reg = regulator_get_optional(hsotg->dev,
+dwc2_hsotg_supply_names[i]);
+
+   /* All or nothing (bulk): regs either are or aren't present */
+   if (IS_ERR(reg)) {
+   while (--i >= 0) {
+   regulator_put(hsotg->supplies[i].consumer);
+   hsotg->supplies[i].consumer = NULL;
+   hsotg->supplies[i].supply = NULL;
+   --hsotg->num_supplies;
+   }
+   break;
+   }
 
-   ret = devm_regulator_bulk_get(hsotg->dev, ARRAY_SIZE(hsotg->supplies),
- hsotg->supplies);
-   if (ret) {
-   dev_err(hsotg->dev, "failed to request supplies: %d\n", ret);
-   return ret;
+   hsotg->supplies[i].consumer = reg;
+   hsotg->supplies[i].supply = dwc2_hsotg_supply_names[i];
+   ++hsotg->num_supplies;
}
+
+   WARN_ON(hsotg->num_supplies &&
+

[PATCH AUTOSEL for 4.15 004/102] dma-buf/fence: Fix lock inversion within dma-fence-array

2018-03-03 Thread Sasha Levin
From: Chris Wilson 

[ Upstream commit 03e4e0a9e02cf703da331ff6cfd57d0be9bf5692 ]

Ages ago Rob Clark noted,

"Currently with fence-array, we have a potential deadlock situation.  If
we fence_add_callback() on an array-fence, the array-fence's lock is
acquired first, and in it's ->enable_signaling() callback, it will install
cbs on it's array-member fences, so the array-member's lock is acquired
second.

But in the signal path, the array-member's lock is acquired first, and
the array-fence's lock acquired second."

Rob proposed either extensive changes to dma-fence to unnest the
fence-array signaling, or to defer the signaling onto a workqueue. This
is a more refined version of the later, that should keep the latency
of the fence signaling to a minimum by using an irq-work, which is
executed asap.

Reported-by: Rob Clark 
Suggested-by: Rob Clark 
References: 1476635975-21981-1-git-send-email-robdcl...@gmail.com
Signed-off-by: Chris Wilson 
Cc: Rob Clark 
Cc: Gustavo Padovan 
Cc: Sumit Semwal 
Cc: Christian König 
Reviewed-by: Christian König 
Signed-off-by: Sumit Semwal 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171114162719.30958-1-ch...@chris-wilson.co.uk
Signed-off-by: Sasha Levin 
---
 drivers/base/Kconfig  |  1 +
 drivers/dma-buf/dma-fence-array.c | 14 --
 include/linux/dma-fence-array.h   |  3 +++
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 2415ad9f6dd4..49fd50fccd48 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -249,6 +249,7 @@ config DMA_SHARED_BUFFER
bool
default n
select ANON_INODES
+   select IRQ_WORK
help
  This option enables the framework for buffer-sharing between
  multiple drivers. A buffer is associated with a file using driver
diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 0350829ba62e..dd1edfb27b61 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -31,6 +31,14 @@ static const char *dma_fence_array_get_timeline_name(struct 
dma_fence *fence)
return "unbound";
 }
 
+static void irq_dma_fence_array_work(struct irq_work *wrk)
+{
+   struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
+
+   dma_fence_signal(>base);
+   dma_fence_put(>base);
+}
+
 static void dma_fence_array_cb_func(struct dma_fence *f,
struct dma_fence_cb *cb)
 {
@@ -39,8 +47,9 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
struct dma_fence_array *array = array_cb->array;
 
if (atomic_dec_and_test(>num_pending))
-   dma_fence_signal(>base);
-   dma_fence_put(>base);
+   irq_work_queue(>work);
+   else
+   dma_fence_put(>base);
 }
 
 static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
@@ -136,6 +145,7 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
spin_lock_init(>lock);
dma_fence_init(>base, _fence_array_ops, >lock,
   context, seqno);
+   init_irq_work(>work, irq_dma_fence_array_work);
 
array->num_fences = num_fences;
atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 332a5420243c..bc8940ca280d 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -21,6 +21,7 @@
 #define __LINUX_DMA_FENCE_ARRAY_H
 
 #include 
+#include 
 
 /**
  * struct dma_fence_array_cb - callback helper for fence array
@@ -47,6 +48,8 @@ struct dma_fence_array {
unsigned num_fences;
atomic_t num_pending;
struct dma_fence **fences;
+
+   struct irq_work work;
 };
 
 extern const struct dma_fence_ops dma_fence_array_ops;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 004/102] dma-buf/fence: Fix lock inversion within dma-fence-array

2018-03-03 Thread Sasha Levin
From: Chris Wilson 

[ Upstream commit 03e4e0a9e02cf703da331ff6cfd57d0be9bf5692 ]

Ages ago Rob Clark noted,

"Currently with fence-array, we have a potential deadlock situation.  If
we fence_add_callback() on an array-fence, the array-fence's lock is
acquired first, and in it's ->enable_signaling() callback, it will install
cbs on it's array-member fences, so the array-member's lock is acquired
second.

But in the signal path, the array-member's lock is acquired first, and
the array-fence's lock acquired second."

Rob proposed either extensive changes to dma-fence to unnest the
fence-array signaling, or to defer the signaling onto a workqueue. This
is a more refined version of the later, that should keep the latency
of the fence signaling to a minimum by using an irq-work, which is
executed asap.

Reported-by: Rob Clark 
Suggested-by: Rob Clark 
References: 1476635975-21981-1-git-send-email-robdcl...@gmail.com
Signed-off-by: Chris Wilson 
Cc: Rob Clark 
Cc: Gustavo Padovan 
Cc: Sumit Semwal 
Cc: Christian König 
Reviewed-by: Christian König 
Signed-off-by: Sumit Semwal 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20171114162719.30958-1-ch...@chris-wilson.co.uk
Signed-off-by: Sasha Levin 
---
 drivers/base/Kconfig  |  1 +
 drivers/dma-buf/dma-fence-array.c | 14 --
 include/linux/dma-fence-array.h   |  3 +++
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 2415ad9f6dd4..49fd50fccd48 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -249,6 +249,7 @@ config DMA_SHARED_BUFFER
bool
default n
select ANON_INODES
+   select IRQ_WORK
help
  This option enables the framework for buffer-sharing between
  multiple drivers. A buffer is associated with a file using driver
diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 0350829ba62e..dd1edfb27b61 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -31,6 +31,14 @@ static const char *dma_fence_array_get_timeline_name(struct 
dma_fence *fence)
return "unbound";
 }
 
+static void irq_dma_fence_array_work(struct irq_work *wrk)
+{
+   struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
+
+   dma_fence_signal(>base);
+   dma_fence_put(>base);
+}
+
 static void dma_fence_array_cb_func(struct dma_fence *f,
struct dma_fence_cb *cb)
 {
@@ -39,8 +47,9 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
struct dma_fence_array *array = array_cb->array;
 
if (atomic_dec_and_test(>num_pending))
-   dma_fence_signal(>base);
-   dma_fence_put(>base);
+   irq_work_queue(>work);
+   else
+   dma_fence_put(>base);
 }
 
 static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
@@ -136,6 +145,7 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
spin_lock_init(>lock);
dma_fence_init(>base, _fence_array_ops, >lock,
   context, seqno);
+   init_irq_work(>work, irq_dma_fence_array_work);
 
array->num_fences = num_fences;
atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 332a5420243c..bc8940ca280d 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -21,6 +21,7 @@
 #define __LINUX_DMA_FENCE_ARRAY_H
 
 #include 
+#include 
 
 /**
  * struct dma_fence_array_cb - callback helper for fence array
@@ -47,6 +48,8 @@ struct dma_fence_array {
unsigned num_fences;
atomic_t num_pending;
struct dma_fence **fences;
+
+   struct irq_work work;
 };
 
 extern const struct dma_fence_ops dma_fence_array_ops;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 003/102] drm/edid: set ELD connector type in drm_edid_to_eld()

2018-03-03 Thread Sasha Levin
From: Jani Nikula 

[ Upstream commit 1d1c36650752b7fb81cee515a9bba4131cac4b7c ]

Since drm_edid_to_eld() knows the connector type, we can set the type in
ELD while at it. Most connectors this gets called on are not DP
encoders, and with the HDMI type being 0, this does not change behaviour
for non-DP.

For i915 having this in place earlier would have saved a considerable
amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always
update ELD connector type after get modes"). I don't see other drivers,
even the ones calling drm_edid_to_eld() on DP connectors, setting the
connector type in ELD.

Cc: Alex Deucher 
Cc: Christian König 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Russell King 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Ben Skeggs 
Cc: Mark Yao 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Thierry Reding 
Cc: Eric Anholt 
Reviewed-by: Ville Syrjälä 
Reviewed-by: Alex Deucher 
Acked-by: Thierry Reding 
Signed-off-by: Jani Nikula 
Link: 
https://patchwork.freedesktop.org/patch/msgid/d527b31619528c477c2c136f25cdf118bc0cfc1d.1509545641.git.jani.nik...@intel.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_edid.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 16fb76ba6509..96afdb4d3ecf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3843,8 +3843,7 @@ EXPORT_SYMBOL(drm_edid_get_monitor_name);
  * @edid: EDID to parse
  *
  * Fill the ELD (EDID-Like Data) buffer for passing to the audio driver. The
- * Conn_Type, HDCP and Port_ID ELD fields are left for the graphics driver to
- * fill in.
+ * HDCP and Port_ID ELD fields are left for the graphics driver to fill in.
  */
 void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
 {
@@ -3925,6 +3924,12 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
}
eld[5] |= total_sad_count << 4;
 
+   if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+   connector->connector_type == DRM_MODE_CONNECTOR_eDP)
+   eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_DP;
+   else
+   eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_HDMI;
+
eld[DRM_ELD_BASELINE_ELD_LEN] =
DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
 
-- 
2.14.1


[PATCH AUTOSEL for 4.15 003/102] drm/edid: set ELD connector type in drm_edid_to_eld()

2018-03-03 Thread Sasha Levin
From: Jani Nikula 

[ Upstream commit 1d1c36650752b7fb81cee515a9bba4131cac4b7c ]

Since drm_edid_to_eld() knows the connector type, we can set the type in
ELD while at it. Most connectors this gets called on are not DP
encoders, and with the HDMI type being 0, this does not change behaviour
for non-DP.

For i915 having this in place earlier would have saved a considerable
amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always
update ELD connector type after get modes"). I don't see other drivers,
even the ones calling drm_edid_to_eld() on DP connectors, setting the
connector type in ELD.

Cc: Alex Deucher 
Cc: Christian König 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Russell King 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Ben Skeggs 
Cc: Mark Yao 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Thierry Reding 
Cc: Eric Anholt 
Reviewed-by: Ville Syrjälä 
Reviewed-by: Alex Deucher 
Acked-by: Thierry Reding 
Signed-off-by: Jani Nikula 
Link: 
https://patchwork.freedesktop.org/patch/msgid/d527b31619528c477c2c136f25cdf118bc0cfc1d.1509545641.git.jani.nik...@intel.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_edid.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 16fb76ba6509..96afdb4d3ecf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3843,8 +3843,7 @@ EXPORT_SYMBOL(drm_edid_get_monitor_name);
  * @edid: EDID to parse
  *
  * Fill the ELD (EDID-Like Data) buffer for passing to the audio driver. The
- * Conn_Type, HDCP and Port_ID ELD fields are left for the graphics driver to
- * fill in.
+ * HDCP and Port_ID ELD fields are left for the graphics driver to fill in.
  */
 void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
 {
@@ -3925,6 +3924,12 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
}
eld[5] |= total_sad_count << 4;
 
+   if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+   connector->connector_type == DRM_MODE_CONNECTOR_eDP)
+   eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_DP;
+   else
+   eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_HDMI;
+
eld[DRM_ELD_BASELINE_ELD_LEN] =
DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
 
-- 
2.14.1


[PATCH AUTOSEL for 4.15 002/102] spi: imx: Fix failure path leak on GPIO request error correctly

2018-03-03 Thread Sasha Levin
From: Trent Piepho 

[ Upstream commit 8197f489f4c4398391746a377c10501076b05168 ]

In commit 974488e4ce1e ("spi: imx: Fix failure path leak on GPIO request
error"), spi_bitbang_start() was moved later in the probe sequence.  But
this doesn't work, as spi_bitbang_start() has to be called before
requesting GPIOs because the GPIO data in the spi master is populated when
the master is registed, and that doesn't happen until spi_bitbang_start()
is called.  The default only works if one uses one CS.

So add a failure path call to spi_bitbang_stop() to fix the leak.

CC: Shawn Guo 
CC: Sascha Hauer 
CC: Fabio Estevam 
CC: Mark Brown 
CC: Oleksij Rempel 
Signed-off-by: Trent Piepho 
Reviewed-by: Oleksij Rempel 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/spi/spi-imx.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 40390d31a93b..6f57592a7f95 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1622,6 +1622,11 @@ static int spi_imx_probe(struct platform_device *pdev)
spi_imx->devtype_data->intctrl(spi_imx, 0);
 
master->dev.of_node = pdev->dev.of_node;
+   ret = spi_bitbang_start(_imx->bitbang);
+   if (ret) {
+   dev_err(>dev, "bitbang start failed with %d\n", ret);
+   goto out_clk_put;
+   }
 
/* Request GPIO CS lines, if any */
if (!spi_imx->slave_mode && master->cs_gpios) {
@@ -1640,12 +1645,6 @@ static int spi_imx_probe(struct platform_device *pdev)
}
}
 
-   ret = spi_bitbang_start(_imx->bitbang);
-   if (ret) {
-   dev_err(>dev, "bitbang start failed with %d\n", ret);
-   goto out_clk_put;
-   }
-
dev_info(>dev, "probed\n");
 
clk_disable(spi_imx->clk_ipg);
-- 
2.14.1


[PATCH AUTOSEL for 4.15 008/102] KVM: PPC: Book3S HV: Fix typo in kvmppc_hv_get_dirty_log_radix()

2018-03-03 Thread Sasha Levin
From: Paul Mackerras 

[ Upstream commit 117647ff936e2d9684cc881d87c0291f46669c20 ]

This fixes a typo where the intent was to assign to 'j' in order to
skip some number of bits in the dirty bitmap for a guest.  The effect
of the typo is benign since it means we just iterate through all the
bits rather than skipping bits which we know will be zero.  This issue
was found by Coverity.

Signed-off-by: Paul Mackerras 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c 
b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index 58618f644c56..0c854816e653 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -573,7 +573,7 @@ long kvmppc_hv_get_dirty_log_radix(struct kvm *kvm,
j = i + 1;
if (npages) {
set_dirty_bits(map, i, npages);
-   i = j + npages;
+   j = i + npages;
}
}
return 0;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 010/102] iwlwifi: mvm: rs: don't override the rate history in the search cycle

2018-03-03 Thread Sasha Levin
From: Emmanuel Grumbach 

[ Upstream commit 992172e3aec19e5b0ea5b757ba40a146b9282d1e ]

When we are in a search cycle, we try different combinations
of parameters. Those combinations are called 'columns'.
When we switch to a new column, we first need to check if
this column has a suitable rate, if not, we can't try it.
This means we must not erase the statistics we gathered
for the previous column until we are sure that we are
indeed switching column.

The code that tries to switch to a new column first sets
a whole bunch of things for the new column, and only then
checks that we can find suitable rates in that column.
While doing that, the code mistakenly erased the rate
statistics. This code was right until
struct iwl_scale_tbl_info grew up for TPC.

Fix this to make sure we don't erase the rate statistics
until we are sure that we can indeed switch to the new
column.

Note that this bug is really harmless since it causes a
change in the behavior only when we can't find any rate
in the new column which should really not happen. In the
case we do find a suitable we reset the rate statistics
a few lines later anyway.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index c69515ed72df..fbfa5eafcc93 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -1877,12 +1877,10 @@ static int rs_switch_to_column(struct iwl_mvm *mvm,
struct rs_rate *rate = _tbl->rate;
const struct rs_tx_column *column = _tx_columns[col_id];
const struct rs_tx_column *curr_column = _tx_columns[tbl->column];
-   u32 sz = (sizeof(struct iwl_scale_tbl_info) -
- (sizeof(struct iwl_rate_scale_data) * IWL_RATE_COUNT));
unsigned long rate_mask = 0;
u32 rate_idx = 0;
 
-   memcpy(search_tbl, tbl, sz);
+   memcpy(search_tbl, tbl, offsetof(struct iwl_scale_tbl_info, win));
 
rate->sgi = column->sgi;
rate->ant = column->ant;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 002/102] spi: imx: Fix failure path leak on GPIO request error correctly

2018-03-03 Thread Sasha Levin
From: Trent Piepho 

[ Upstream commit 8197f489f4c4398391746a377c10501076b05168 ]

In commit 974488e4ce1e ("spi: imx: Fix failure path leak on GPIO request
error"), spi_bitbang_start() was moved later in the probe sequence.  But
this doesn't work, as spi_bitbang_start() has to be called before
requesting GPIOs because the GPIO data in the spi master is populated when
the master is registed, and that doesn't happen until spi_bitbang_start()
is called.  The default only works if one uses one CS.

So add a failure path call to spi_bitbang_stop() to fix the leak.

CC: Shawn Guo 
CC: Sascha Hauer 
CC: Fabio Estevam 
CC: Mark Brown 
CC: Oleksij Rempel 
Signed-off-by: Trent Piepho 
Reviewed-by: Oleksij Rempel 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/spi/spi-imx.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 40390d31a93b..6f57592a7f95 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -1622,6 +1622,11 @@ static int spi_imx_probe(struct platform_device *pdev)
spi_imx->devtype_data->intctrl(spi_imx, 0);
 
master->dev.of_node = pdev->dev.of_node;
+   ret = spi_bitbang_start(_imx->bitbang);
+   if (ret) {
+   dev_err(>dev, "bitbang start failed with %d\n", ret);
+   goto out_clk_put;
+   }
 
/* Request GPIO CS lines, if any */
if (!spi_imx->slave_mode && master->cs_gpios) {
@@ -1640,12 +1645,6 @@ static int spi_imx_probe(struct platform_device *pdev)
}
}
 
-   ret = spi_bitbang_start(_imx->bitbang);
-   if (ret) {
-   dev_err(>dev, "bitbang start failed with %d\n", ret);
-   goto out_clk_put;
-   }
-
dev_info(>dev, "probed\n");
 
clk_disable(spi_imx->clk_ipg);
-- 
2.14.1


[PATCH AUTOSEL for 4.15 008/102] KVM: PPC: Book3S HV: Fix typo in kvmppc_hv_get_dirty_log_radix()

2018-03-03 Thread Sasha Levin
From: Paul Mackerras 

[ Upstream commit 117647ff936e2d9684cc881d87c0291f46669c20 ]

This fixes a typo where the intent was to assign to 'j' in order to
skip some number of bits in the dirty bitmap for a guest.  The effect
of the typo is benign since it means we just iterate through all the
bits rather than skipping bits which we know will be zero.  This issue
was found by Coverity.

Signed-off-by: Paul Mackerras 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c 
b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index 58618f644c56..0c854816e653 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -573,7 +573,7 @@ long kvmppc_hv_get_dirty_log_radix(struct kvm *kvm,
j = i + 1;
if (npages) {
set_dirty_bits(map, i, npages);
-   i = j + npages;
+   j = i + npages;
}
}
return 0;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 010/102] iwlwifi: mvm: rs: don't override the rate history in the search cycle

2018-03-03 Thread Sasha Levin
From: Emmanuel Grumbach 

[ Upstream commit 992172e3aec19e5b0ea5b757ba40a146b9282d1e ]

When we are in a search cycle, we try different combinations
of parameters. Those combinations are called 'columns'.
When we switch to a new column, we first need to check if
this column has a suitable rate, if not, we can't try it.
This means we must not erase the statistics we gathered
for the previous column until we are sure that we are
indeed switching column.

The code that tries to switch to a new column first sets
a whole bunch of things for the new column, and only then
checks that we can find suitable rates in that column.
While doing that, the code mistakenly erased the rate
statistics. This code was right until
struct iwl_scale_tbl_info grew up for TPC.

Fix this to make sure we don't erase the rate statistics
until we are sure that we can indeed switch to the new
column.

Note that this bug is really harmless since it causes a
change in the behavior only when we can't find any rate
in the new column which should really not happen. In the
case we do find a suitable we reset the rate statistics
a few lines later anyway.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index c69515ed72df..fbfa5eafcc93 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -1877,12 +1877,10 @@ static int rs_switch_to_column(struct iwl_mvm *mvm,
struct rs_rate *rate = _tbl->rate;
const struct rs_tx_column *column = _tx_columns[col_id];
const struct rs_tx_column *curr_column = _tx_columns[tbl->column];
-   u32 sz = (sizeof(struct iwl_scale_tbl_info) -
- (sizeof(struct iwl_rate_scale_data) * IWL_RATE_COUNT));
unsigned long rate_mask = 0;
u32 rate_idx = 0;
 
-   memcpy(search_tbl, tbl, sz);
+   memcpy(search_tbl, tbl, offsetof(struct iwl_scale_tbl_info, win));
 
rate->sgi = column->sgi;
rate->ant = column->ant;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 006/102] HID: multitouch: Only look at non touch fields in first packet of a frame

2018-03-03 Thread Sasha Levin
From: Hans de Goede 

[ Upstream commit 55746d28d66860bccaae20a67b55b9d5db7c14af ]

Devices in "single finger hybrid mode" will send one report per finger,
on some devices only the first report of such a multi-packet frame will
contain a value for BTN_LEFT, in subsequent reports (if multiple fingers
are down) the value is always 0, causing hid-mt to report BTN_LEFT going
1 - 0 - 1 - 0 when pressing a clickpad and putting down a second finger.
This happens for example on USB 0603:0002 mt touchpads.

This commit fixes this by only reporting non touch fields for the first
packet of a (possibly) multi-packet frame.

Signed-off-by: Hans de Goede 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin 
---
 drivers/hid/hid-multitouch.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 65ea23be9677..397592959238 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -778,9 +778,11 @@ static int mt_touch_event(struct hid_device *hid, struct 
hid_field *field,
 }
 
 static void mt_process_mt_event(struct hid_device *hid, struct hid_field 
*field,
-   struct hid_usage *usage, __s32 value)
+   struct hid_usage *usage, __s32 value,
+   bool first_packet)
 {
struct mt_device *td = hid_get_drvdata(hid);
+   __s32 cls = td->mtclass.name;
__s32 quirks = td->mtclass.quirks;
struct input_dev *input = field->hidinput->input;
 
@@ -837,6 +839,15 @@ static void mt_process_mt_event(struct hid_device *hid, 
struct hid_field *field,
break;
 
default:
+   /*
+* For Win8 PTP touchpads we should only look at
+* non finger/touch events in the first_packet of
+* a (possible) multi-packet frame.
+*/
+   if ((cls == MT_CLS_WIN_8 || cls == MT_CLS_WIN_8_DUAL) &&
+   !first_packet)
+   return;
+
if (usage->type)
input_event(input, usage->type, usage->code,
value);
@@ -856,6 +867,7 @@ static void mt_touch_report(struct hid_device *hid, struct 
hid_report *report)
 {
struct mt_device *td = hid_get_drvdata(hid);
struct hid_field *field;
+   bool first_packet;
unsigned count;
int r, n;
 
@@ -874,6 +886,7 @@ static void mt_touch_report(struct hid_device *hid, struct 
hid_report *report)
td->num_expected = value;
}
 
+   first_packet = td->num_received == 0;
for (r = 0; r < report->maxfield; r++) {
field = report->field[r];
count = field->report_count;
@@ -883,7 +896,7 @@ static void mt_touch_report(struct hid_device *hid, struct 
hid_report *report)
 
for (n = 0; n < count; n++)
mt_process_mt_event(hid, field, >usage[n],
-   field->value[n]);
+   field->value[n], first_packet);
}
 
if (td->num_received >= td->num_expected)
-- 
2.14.1


[PATCH AUTOSEL for 4.15 011/102] ARM: dts: koelsch: Move cec_clock to root node

2018-03-03 Thread Sasha Levin
From: Simon Horman 

[ Upstream commit d72f4f03854d1225c72d682bf0e01377e7016419 ]

cec-clock is a fixed clock generator that is not controlled by i2c5 and
thus should not be a child of the i2c5 bus node. Rather, it should be
a child of the root node of the DT.

Fixes: 02a5ab18d366 ("ARM: dts: koelsch: Add CEC clock for HDMI transmitter")
Reported-by: Laurent Pinchart 
Signed-off-by: Simon Horman 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Sasha Levin 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index e164eda69baf..4126de417922 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -278,6 +278,12 @@
};
};
 
+   cec_clock: cec-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1200>;
+   };
+
hdmi-out {
compatible = "hdmi-connector";
type = "a";
@@ -640,12 +646,6 @@
};
};
 
-   cec_clock: cec-clock {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <1200>;
-   };
-
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 009/102] HID: elo: clear BTN_LEFT mapping

2018-03-03 Thread Sasha Levin
From: Jiri Kosina 

[ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ]

ELO devices have one Button usage in GenDesk field, which makes hid-input map
it to BTN_LEFT; that confuses userspace, which then considers the device to be
a mouse/touchpad instead of touchscreen.

Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place.

Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin 
---
 drivers/hid/hid-elo.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/hid/hid-elo.c b/drivers/hid/hid-elo.c
index 0cd4f7216239..5eea6fe0d7bd 100644
--- a/drivers/hid/hid-elo.c
+++ b/drivers/hid/hid-elo.c
@@ -42,6 +42,12 @@ static int elo_input_configured(struct hid_device *hdev,
 {
struct input_dev *input = hidinput->input;
 
+   /*
+* ELO devices have one Button usage in GenDesk field, which makes
+* hid-input map it to BTN_LEFT; that confuses userspace, which then
+* considers the device to be a mouse/touchpad instead of touchscreen.
+*/
+   clear_bit(BTN_LEFT, input->keybit);
set_bit(BTN_TOUCH, input->keybit);
set_bit(ABS_PRESSURE, input->absbit);
input_set_abs_params(input, ABS_PRESSURE, 0, 256, 0, 0);
-- 
2.14.1


[PATCH AUTOSEL for 4.15 006/102] HID: multitouch: Only look at non touch fields in first packet of a frame

2018-03-03 Thread Sasha Levin
From: Hans de Goede 

[ Upstream commit 55746d28d66860bccaae20a67b55b9d5db7c14af ]

Devices in "single finger hybrid mode" will send one report per finger,
on some devices only the first report of such a multi-packet frame will
contain a value for BTN_LEFT, in subsequent reports (if multiple fingers
are down) the value is always 0, causing hid-mt to report BTN_LEFT going
1 - 0 - 1 - 0 when pressing a clickpad and putting down a second finger.
This happens for example on USB 0603:0002 mt touchpads.

This commit fixes this by only reporting non touch fields for the first
packet of a (possibly) multi-packet frame.

Signed-off-by: Hans de Goede 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin 
---
 drivers/hid/hid-multitouch.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 65ea23be9677..397592959238 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -778,9 +778,11 @@ static int mt_touch_event(struct hid_device *hid, struct 
hid_field *field,
 }
 
 static void mt_process_mt_event(struct hid_device *hid, struct hid_field 
*field,
-   struct hid_usage *usage, __s32 value)
+   struct hid_usage *usage, __s32 value,
+   bool first_packet)
 {
struct mt_device *td = hid_get_drvdata(hid);
+   __s32 cls = td->mtclass.name;
__s32 quirks = td->mtclass.quirks;
struct input_dev *input = field->hidinput->input;
 
@@ -837,6 +839,15 @@ static void mt_process_mt_event(struct hid_device *hid, 
struct hid_field *field,
break;
 
default:
+   /*
+* For Win8 PTP touchpads we should only look at
+* non finger/touch events in the first_packet of
+* a (possible) multi-packet frame.
+*/
+   if ((cls == MT_CLS_WIN_8 || cls == MT_CLS_WIN_8_DUAL) &&
+   !first_packet)
+   return;
+
if (usage->type)
input_event(input, usage->type, usage->code,
value);
@@ -856,6 +867,7 @@ static void mt_touch_report(struct hid_device *hid, struct 
hid_report *report)
 {
struct mt_device *td = hid_get_drvdata(hid);
struct hid_field *field;
+   bool first_packet;
unsigned count;
int r, n;
 
@@ -874,6 +886,7 @@ static void mt_touch_report(struct hid_device *hid, struct 
hid_report *report)
td->num_expected = value;
}
 
+   first_packet = td->num_received == 0;
for (r = 0; r < report->maxfield; r++) {
field = report->field[r];
count = field->report_count;
@@ -883,7 +896,7 @@ static void mt_touch_report(struct hid_device *hid, struct 
hid_report *report)
 
for (n = 0; n < count; n++)
mt_process_mt_event(hid, field, >usage[n],
-   field->value[n]);
+   field->value[n], first_packet);
}
 
if (td->num_received >= td->num_expected)
-- 
2.14.1


[PATCH AUTOSEL for 4.15 011/102] ARM: dts: koelsch: Move cec_clock to root node

2018-03-03 Thread Sasha Levin
From: Simon Horman 

[ Upstream commit d72f4f03854d1225c72d682bf0e01377e7016419 ]

cec-clock is a fixed clock generator that is not controlled by i2c5 and
thus should not be a child of the i2c5 bus node. Rather, it should be
a child of the root node of the DT.

Fixes: 02a5ab18d366 ("ARM: dts: koelsch: Add CEC clock for HDMI transmitter")
Reported-by: Laurent Pinchart 
Signed-off-by: Simon Horman 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Sasha Levin 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index e164eda69baf..4126de417922 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -278,6 +278,12 @@
};
};
 
+   cec_clock: cec-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1200>;
+   };
+
hdmi-out {
compatible = "hdmi-connector";
type = "a";
@@ -640,12 +646,6 @@
};
};
 
-   cec_clock: cec-clock {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <1200>;
-   };
-
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 009/102] HID: elo: clear BTN_LEFT mapping

2018-03-03 Thread Sasha Levin
From: Jiri Kosina 

[ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ]

ELO devices have one Button usage in GenDesk field, which makes hid-input map
it to BTN_LEFT; that confuses userspace, which then considers the device to be
a mouse/touchpad instead of touchscreen.

Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place.

Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin 
---
 drivers/hid/hid-elo.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/hid/hid-elo.c b/drivers/hid/hid-elo.c
index 0cd4f7216239..5eea6fe0d7bd 100644
--- a/drivers/hid/hid-elo.c
+++ b/drivers/hid/hid-elo.c
@@ -42,6 +42,12 @@ static int elo_input_configured(struct hid_device *hdev,
 {
struct input_dev *input = hidinput->input;
 
+   /*
+* ELO devices have one Button usage in GenDesk field, which makes
+* hid-input map it to BTN_LEFT; that confuses userspace, which then
+* considers the device to be a mouse/touchpad instead of touchscreen.
+*/
+   clear_bit(BTN_LEFT, input->keybit);
set_bit(BTN_TOUCH, input->keybit);
set_bit(ABS_PRESSURE, input->absbit);
input_set_abs_params(input, ABS_PRESSURE, 0, 256, 0, 0);
-- 
2.14.1


[PATCH AUTOSEL for 4.15 014/102] drm/amdgpu: fix get_max_engine_clock_in_mhz

2018-03-03 Thread Sasha Levin
From: Felix Kuehling 

[ Upstream commit a9efcc19161e20623c285fac967a32842972cebe ]

Use proper powerplay function. This fixes OpenCL initialization
problems.

Signed-off-by: Felix Kuehling 
Acked-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 5432af39a674..f7fa7675215c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -265,6 +265,9 @@ uint32_t get_max_engine_clock_in_mhz(struct kgd_dev *kgd)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)kgd;
 
-   /* The sclk is in quantas of 10kHz */
-   return adev->pm.dpm.dyn_state.max_clock_voltage_on_ac.sclk / 100;
+   /* the sclk is in quantas of 10kHz */
+   if (amdgpu_sriov_vf(adev))
+   return adev->clock.default_sclk / 100;
+
+   return amdgpu_dpm_get_sclk(adev, false) / 100;
 }
-- 
2.14.1


[PATCH AUTOSEL for 4.15 014/102] drm/amdgpu: fix get_max_engine_clock_in_mhz

2018-03-03 Thread Sasha Levin
From: Felix Kuehling 

[ Upstream commit a9efcc19161e20623c285fac967a32842972cebe ]

Use proper powerplay function. This fixes OpenCL initialization
problems.

Signed-off-by: Felix Kuehling 
Acked-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 5432af39a674..f7fa7675215c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -265,6 +265,9 @@ uint32_t get_max_engine_clock_in_mhz(struct kgd_dev *kgd)
 {
struct amdgpu_device *adev = (struct amdgpu_device *)kgd;
 
-   /* The sclk is in quantas of 10kHz */
-   return adev->pm.dpm.dyn_state.max_clock_voltage_on_ac.sclk / 100;
+   /* the sclk is in quantas of 10kHz */
+   if (amdgpu_sriov_vf(adev))
+   return adev->clock.default_sclk / 100;
+
+   return amdgpu_dpm_get_sclk(adev, false) / 100;
 }
-- 
2.14.1


[PATCH AUTOSEL for 4.15 013/102] ARM: dts: exynos: Correct Trats2 panel reset line

2018-03-03 Thread Sasha Levin
From: Simon Shields 

[ Upstream commit 1b377924841df1e13ab5b225be3a83f807a92b52 ]

Trats2 uses gpf2-1 as the panel reset GPIO. gpy4-5 was only used
on early revisions of the board.

Fixes: 420ae8451a22 ("ARM: dts: exynos4412-trats2: add panel node")
Signed-off-by: Simon Shields 
Acked-by: Marek Szyprowski 
Tested-by: Marek Szyprowski 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Sasha Levin 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 220cdf109405..9f4672ba9943 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -454,7 +454,7 @@
reg = <0>;
vdd3-supply = <_vdd3_reg>;
vci-supply = <_reg>;
-   reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 1 GPIO_ACTIVE_HIGH>;
power-on-delay= <50>;
reset-delay = <100>;
init-delay = <100>;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 013/102] ARM: dts: exynos: Correct Trats2 panel reset line

2018-03-03 Thread Sasha Levin
From: Simon Shields 

[ Upstream commit 1b377924841df1e13ab5b225be3a83f807a92b52 ]

Trats2 uses gpf2-1 as the panel reset GPIO. gpy4-5 was only used
on early revisions of the board.

Fixes: 420ae8451a22 ("ARM: dts: exynos4412-trats2: add panel node")
Signed-off-by: Simon Shields 
Acked-by: Marek Szyprowski 
Tested-by: Marek Szyprowski 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Sasha Levin 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 220cdf109405..9f4672ba9943 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -454,7 +454,7 @@
reg = <0>;
vdd3-supply = <_vdd3_reg>;
vci-supply = <_reg>;
-   reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 1 GPIO_ACTIVE_HIGH>;
power-on-delay= <50>;
reset-delay = <100>;
init-delay = <100>;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 015/102] staging: rtl8822be: fix missing null check on dev_alloc_skb return

2018-03-03 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 3eb23426e1749a0483bc4c9b18e51f657569e3ed ]

dev_alloc_skb can potentially return NULL, so add a null check to
avoid a null pointer dereference on skb

Detected by CoverityScan, CID#1454558 ("Dereference on null return")

Fixes: 7e5b796cde7e ("staging: r8822be: Add the driver code")
Signed-off-by: Colin Ian King 
Acked-by: Larry Finger 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/staging/rtlwifi/rtl8822be/fw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/rtlwifi/rtl8822be/fw.c 
b/drivers/staging/rtlwifi/rtl8822be/fw.c
index f45487122517..483ea85943c3 100644
--- a/drivers/staging/rtlwifi/rtl8822be/fw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/fw.c
@@ -464,6 +464,8 @@ bool rtl8822b_halmac_cb_write_data_rsvd_page(struct 
rtl_priv *rtlpriv, u8 *buf,
int count;
 
skb = dev_alloc_skb(size);
+   if (!skb)
+   return false;
memcpy((u8 *)skb_put(skb, size), buf, size);
 
if (!_rtl8822be_send_bcn_or_cmd_packet(rtlpriv->hw, skb, BEACON_QUEUE))
-- 
2.14.1


[PATCH AUTOSEL for 4.15 015/102] staging: rtl8822be: fix missing null check on dev_alloc_skb return

2018-03-03 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 3eb23426e1749a0483bc4c9b18e51f657569e3ed ]

dev_alloc_skb can potentially return NULL, so add a null check to
avoid a null pointer dereference on skb

Detected by CoverityScan, CID#1454558 ("Dereference on null return")

Fixes: 7e5b796cde7e ("staging: r8822be: Add the driver code")
Signed-off-by: Colin Ian King 
Acked-by: Larry Finger 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/staging/rtlwifi/rtl8822be/fw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/rtlwifi/rtl8822be/fw.c 
b/drivers/staging/rtlwifi/rtl8822be/fw.c
index f45487122517..483ea85943c3 100644
--- a/drivers/staging/rtlwifi/rtl8822be/fw.c
+++ b/drivers/staging/rtlwifi/rtl8822be/fw.c
@@ -464,6 +464,8 @@ bool rtl8822b_halmac_cb_write_data_rsvd_page(struct 
rtl_priv *rtlpriv, u8 *buf,
int count;
 
skb = dev_alloc_skb(size);
+   if (!skb)
+   return false;
memcpy((u8 *)skb_put(skb, size), buf, size);
 
if (!_rtl8822be_send_bcn_or_cmd_packet(rtlpriv->hw, skb, BEACON_QUEUE))
-- 
2.14.1


[PATCH AUTOSEL for 4.15 012/102] clk: meson: gxbb: fix wrong clock for SARADC/SANA

2018-03-03 Thread Sasha Levin
From: Yixun Lan 

[ Upstream commit 75eccf5ed83250c0aeaeeb76f7288254ac0a87b4 ]

According to the datasheet, in Meson-GXBB/GXL series,
The clock gate bit for SARADC is HHI_GCLK_MPEG2 bit[22],
while clock gate bit for SANA is HHI_GCLK_MPEG0 bit[10].

Test passed at gxl-s905x-p212 board.

The following published datasheets are wrong and should be updated
[1] GXBB v1.1.4
[2] GXL v0.3_20170314

Fixes: 738f66d3211d ("clk: gxbb: add AmLogic GXBB clk controller driver")
Tested-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
Signed-off-by: Jerome Brunet 
Signed-off-by: Sasha Levin 
---
 drivers/clk/meson/gxbb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index ae385310e980..2ac9f3fa9578 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -1386,7 +1386,7 @@ static MESON_GATE(gxbb_pl301, HHI_GCLK_MPEG0, 6);
 static MESON_GATE(gxbb_periphs, HHI_GCLK_MPEG0, 7);
 static MESON_GATE(gxbb_spicc, HHI_GCLK_MPEG0, 8);
 static MESON_GATE(gxbb_i2c, HHI_GCLK_MPEG0, 9);
-static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG0, 10);
+static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG0, 10);
 static MESON_GATE(gxbb_smart_card, HHI_GCLK_MPEG0, 11);
 static MESON_GATE(gxbb_rng0, HHI_GCLK_MPEG0, 12);
 static MESON_GATE(gxbb_uart0, HHI_GCLK_MPEG0, 13);
@@ -1437,7 +1437,7 @@ static MESON_GATE(gxbb_usb0_ddr_bridge, HHI_GCLK_MPEG2, 
9);
 static MESON_GATE(gxbb_mmc_pclk, HHI_GCLK_MPEG2, 11);
 static MESON_GATE(gxbb_dvin, HHI_GCLK_MPEG2, 12);
 static MESON_GATE(gxbb_uart2, HHI_GCLK_MPEG2, 15);
-static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG2, 22);
+static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG2, 22);
 static MESON_GATE(gxbb_vpu_intr, HHI_GCLK_MPEG2, 25);
 static MESON_GATE(gxbb_sec_ahb_ahb3_bridge, HHI_GCLK_MPEG2, 26);
 static MESON_GATE(gxbb_clk81_a53, HHI_GCLK_MPEG2, 29);
-- 
2.14.1


[PATCH AUTOSEL for 4.15 019/102] sched: Stop switched_to_rt() from sending IPIs to offline CPUs

2018-03-03 Thread Sasha Levin
From: "Paul E. McKenney" 

[ Upstream commit 2fe2582649aa2355f79acddb86bd4d6c5363eb63 ]

The rcutorture test suite occasionally provokes a splat due to invoking
rt_mutex_lock() which needs to boost the priority of a task currently
sitting on a runqueue that belongs to an offline CPU:

WARNING: CPU: 0 PID: 12 at 
/home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 
native_smp_send_reschedule+0x37/0x40
Modules linked in:
CPU: 0 PID: 12 Comm: rcub/7 Not tainted 4.14.0-rc4+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
task: 9ed3de5f8cc0 task.stack: bbf80012c000
RIP: 0010:native_smp_send_reschedule+0x37/0x40
RSP: 0018:bbf80012fd10 EFLAGS: 00010082
RAX: 002f RBX: 9ed3dd9cb300 RCX: 0004
RDX: 8004 RSI: 0086 RDI: 
RBP: bbf80012fd10 R08: 0009da7a R09: 7b9d
R10: 0001 R11: bb57c2cd R12: 000d
R13: 9ed3de5f8cc0 R14: 0061 R15: 9ed3ded59200
FS:  () GS:9ed3dea0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 080686f0 CR3: 1b9e CR4: 06f0
Call Trace:
 resched_curr+0x61/0xd0
 switched_to_rt+0x8f/0xa0
 rt_mutex_setprio+0x25c/0x410
 task_blocks_on_rt_mutex+0x1b3/0x1f0
 rt_mutex_slowlock+0xa9/0x1e0
 rt_mutex_lock+0x29/0x30
 rcu_boost_kthread+0x127/0x3c0
 kthread+0x104/0x140
 ? rcu_report_unblock_qs_rnp+0x90/0x90
 ? kthread_create_on_node+0x40/0x40
 ret_from_fork+0x22/0x30
Code: f0 00 0f 92 c0 84 c0 74 14 48 8b 05 34 74 c5 00 be fd 00 00 00 ff 90 a0 
00 00 00 5d c3 89 fe 48 c7 c7 a0 c6 fc b9 e8 d5 b5 06 00 <0f> ff 5d c3 0f 1f 44 
00 00 8b 05 a2 d1 13 02 85 c0 75 38 55 48

But the target task's priority has already been adjusted, so the only
purpose of switched_to_rt() invoking resched_curr() is to wake up the
CPU running some task that needs to be preempted by the boosted task.
But the CPU is offline, which presumably means that the task must be
migrated to some other CPU, and that this other CPU will undertake any
needed preemption at the time of migration.  Because the runqueue lock
is held when resched_curr() is invoked, we know that the boosted task
cannot go anywhere, so it is not necessary to invoke resched_curr()
in this particular case.

This commit therefore makes switched_to_rt() refrain from invoking
resched_curr() when the target CPU is offline.

Signed-off-by: Paul E. McKenney 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Signed-off-by: Sasha Levin 
---
 kernel/sched/rt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 3401f588c916..89a086ed2b16 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2218,7 +2218,7 @@ static void switched_to_rt(struct rq *rq, struct 
task_struct *p)
if (p->nr_cpus_allowed > 1 && rq->rt.overloaded)
queue_push_tasks(rq);
 #endif /* CONFIG_SMP */
-   if (p->prio < rq->curr->prio)
+   if (p->prio < rq->curr->prio && cpu_online(cpu_of(rq)))
resched_curr(rq);
}
 }
-- 
2.14.1


[PATCH AUTOSEL for 4.15 012/102] clk: meson: gxbb: fix wrong clock for SARADC/SANA

2018-03-03 Thread Sasha Levin
From: Yixun Lan 

[ Upstream commit 75eccf5ed83250c0aeaeeb76f7288254ac0a87b4 ]

According to the datasheet, in Meson-GXBB/GXL series,
The clock gate bit for SARADC is HHI_GCLK_MPEG2 bit[22],
while clock gate bit for SANA is HHI_GCLK_MPEG0 bit[10].

Test passed at gxl-s905x-p212 board.

The following published datasheets are wrong and should be updated
[1] GXBB v1.1.4
[2] GXL v0.3_20170314

Fixes: 738f66d3211d ("clk: gxbb: add AmLogic GXBB clk controller driver")
Tested-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
Signed-off-by: Jerome Brunet 
Signed-off-by: Sasha Levin 
---
 drivers/clk/meson/gxbb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index ae385310e980..2ac9f3fa9578 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -1386,7 +1386,7 @@ static MESON_GATE(gxbb_pl301, HHI_GCLK_MPEG0, 6);
 static MESON_GATE(gxbb_periphs, HHI_GCLK_MPEG0, 7);
 static MESON_GATE(gxbb_spicc, HHI_GCLK_MPEG0, 8);
 static MESON_GATE(gxbb_i2c, HHI_GCLK_MPEG0, 9);
-static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG0, 10);
+static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG0, 10);
 static MESON_GATE(gxbb_smart_card, HHI_GCLK_MPEG0, 11);
 static MESON_GATE(gxbb_rng0, HHI_GCLK_MPEG0, 12);
 static MESON_GATE(gxbb_uart0, HHI_GCLK_MPEG0, 13);
@@ -1437,7 +1437,7 @@ static MESON_GATE(gxbb_usb0_ddr_bridge, HHI_GCLK_MPEG2, 
9);
 static MESON_GATE(gxbb_mmc_pclk, HHI_GCLK_MPEG2, 11);
 static MESON_GATE(gxbb_dvin, HHI_GCLK_MPEG2, 12);
 static MESON_GATE(gxbb_uart2, HHI_GCLK_MPEG2, 15);
-static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG2, 22);
+static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG2, 22);
 static MESON_GATE(gxbb_vpu_intr, HHI_GCLK_MPEG2, 25);
 static MESON_GATE(gxbb_sec_ahb_ahb3_bridge, HHI_GCLK_MPEG2, 26);
 static MESON_GATE(gxbb_clk81_a53, HHI_GCLK_MPEG2, 29);
-- 
2.14.1


[PATCH AUTOSEL for 4.15 019/102] sched: Stop switched_to_rt() from sending IPIs to offline CPUs

2018-03-03 Thread Sasha Levin
From: "Paul E. McKenney" 

[ Upstream commit 2fe2582649aa2355f79acddb86bd4d6c5363eb63 ]

The rcutorture test suite occasionally provokes a splat due to invoking
rt_mutex_lock() which needs to boost the priority of a task currently
sitting on a runqueue that belongs to an offline CPU:

WARNING: CPU: 0 PID: 12 at 
/home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 
native_smp_send_reschedule+0x37/0x40
Modules linked in:
CPU: 0 PID: 12 Comm: rcub/7 Not tainted 4.14.0-rc4+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
task: 9ed3de5f8cc0 task.stack: bbf80012c000
RIP: 0010:native_smp_send_reschedule+0x37/0x40
RSP: 0018:bbf80012fd10 EFLAGS: 00010082
RAX: 002f RBX: 9ed3dd9cb300 RCX: 0004
RDX: 8004 RSI: 0086 RDI: 
RBP: bbf80012fd10 R08: 0009da7a R09: 7b9d
R10: 0001 R11: bb57c2cd R12: 000d
R13: 9ed3de5f8cc0 R14: 0061 R15: 9ed3ded59200
FS:  () GS:9ed3dea0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 080686f0 CR3: 1b9e CR4: 06f0
Call Trace:
 resched_curr+0x61/0xd0
 switched_to_rt+0x8f/0xa0
 rt_mutex_setprio+0x25c/0x410
 task_blocks_on_rt_mutex+0x1b3/0x1f0
 rt_mutex_slowlock+0xa9/0x1e0
 rt_mutex_lock+0x29/0x30
 rcu_boost_kthread+0x127/0x3c0
 kthread+0x104/0x140
 ? rcu_report_unblock_qs_rnp+0x90/0x90
 ? kthread_create_on_node+0x40/0x40
 ret_from_fork+0x22/0x30
Code: f0 00 0f 92 c0 84 c0 74 14 48 8b 05 34 74 c5 00 be fd 00 00 00 ff 90 a0 
00 00 00 5d c3 89 fe 48 c7 c7 a0 c6 fc b9 e8 d5 b5 06 00 <0f> ff 5d c3 0f 1f 44 
00 00 8b 05 a2 d1 13 02 85 c0 75 38 55 48

But the target task's priority has already been adjusted, so the only
purpose of switched_to_rt() invoking resched_curr() is to wake up the
CPU running some task that needs to be preempted by the boosted task.
But the CPU is offline, which presumably means that the task must be
migrated to some other CPU, and that this other CPU will undertake any
needed preemption at the time of migration.  Because the runqueue lock
is held when resched_curr() is invoked, we know that the boosted task
cannot go anywhere, so it is not necessary to invoke resched_curr()
in this particular case.

This commit therefore makes switched_to_rt() refrain from invoking
resched_curr() when the target CPU is offline.

Signed-off-by: Paul E. McKenney 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Signed-off-by: Sasha Levin 
---
 kernel/sched/rt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 3401f588c916..89a086ed2b16 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2218,7 +2218,7 @@ static void switched_to_rt(struct rq *rq, struct 
task_struct *p)
if (p->nr_cpus_allowed > 1 && rq->rt.overloaded)
queue_push_tasks(rq);
 #endif /* CONFIG_SMP */
-   if (p->prio < rq->curr->prio)
+   if (p->prio < rq->curr->prio && cpu_online(cpu_of(rq)))
resched_curr(rq);
}
 }
-- 
2.14.1


[PATCH AUTOSEL for 4.15 017/102] USB: ledtrig-usbport: fix of-node leak

2018-03-03 Thread Sasha Levin
From: Johan Hovold 

[ Upstream commit 03310a15484ab6a8f6d91bbf7fe486b17275c09a ]

This code looks up a USB device node from a given parent USB device but
never dropped its reference to the returned node.

As only the address of the node is used for a later matching, the
reference can be dropped immediately.

Note that this trigger implementation confuses the description of the
USB device connected to a port with the port itself (which does not have
a device-tree representation).

Fixes: 4f04c210d031 ("usb: core: read USB ports from DT in the usbport LED 
trigger driver")
Cc: Rafał Miłecki 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/core/ledtrig-usbport.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/ledtrig-usbport.c 
b/drivers/usb/core/ledtrig-usbport.c
index 9dbb429cd471..f1fde5165068 100644
--- a/drivers/usb/core/ledtrig-usbport.c
+++ b/drivers/usb/core/ledtrig-usbport.c
@@ -137,11 +137,17 @@ static bool usbport_trig_port_observed(struct 
usbport_trig_data *usbport_data,
if (!led_np)
return false;
 
-   /* Get node of port being added */
+   /*
+* Get node of port being added
+*
+* FIXME: This is really the device node of the connected device
+*/
port_np = usb_of_get_child_node(usb_dev->dev.of_node, port1);
if (!port_np)
return false;
 
+   of_node_put(port_np);
+
/* Amount of trigger sources for this LED */
count = of_count_phandle_with_args(led_np, "trigger-sources",
   "#trigger-source-cells");
-- 
2.14.1


Re: [PATCH v4 06/22] nvmem: uniphier-efuse: Convert to use devm_nvmem_register()

2018-03-03 Thread kbuild test robot
Hi Andrey,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc3 next-20180302]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrey-Smirnov/Verbatim-device-names-and-devm_nvmem_-un-register/20180303-220801


coccinelle warnings: (new ones prefixed by >>)

>> drivers/nvmem/uniphier-efuse.c:64:1-3: WARNING: PTR_ERR_OR_ZERO can be used

Please review and possibly fold the followup patch.

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


[PATCH] nvmem: uniphier-efuse: fix ptr_ret.cocci warnings

2018-03-03 Thread kbuild test robot
From: Fengguang Wu 

drivers/nvmem/uniphier-efuse.c:64:1-3: WARNING: PTR_ERR_OR_ZERO can be used


 Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Generated by: scripts/coccinelle/api/ptr_ret.cocci

Fixes: d562efb89f70 ("nvmem: uniphier-efuse: Convert to use 
devm_nvmem_register()")
CC: Andrey Smirnov 
Signed-off-by: Fengguang Wu 
---

 uniphier-efuse.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

--- a/drivers/nvmem/uniphier-efuse.c
+++ b/drivers/nvmem/uniphier-efuse.c
@@ -61,10 +61,7 @@ static int uniphier_efuse_probe(struct p
econfig.priv = priv;
econfig.dev = dev;
nvmem = devm_nvmem_register(dev, );
-   if (IS_ERR(nvmem))
-   return PTR_ERR(nvmem);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(nvmem);
 }
 
 static const struct of_device_id uniphier_efuse_of_match[] = {


[PATCH AUTOSEL for 4.15 023/102] crypto: keywrap - Add missing ULL suffixes for 64-bit constants

2018-03-03 Thread Sasha Levin
From: Geert Uytterhoeven 

[ Upstream commit c9683276dd89906ca9b65696d09104d542171421 ]

On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1):

crypto/keywrap.c: In function ‘crypto_kw_decrypt’:
crypto/keywrap.c:191: warning: integer constant is too large for ‘long’ type
crypto/keywrap.c: In function ‘crypto_kw_encrypt’:
crypto/keywrap.c:224: warning: integer constant is too large for ‘long’ type

Fixes: 9e49451d7a15365d ("crypto: keywrap - simplify code")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Stephan Mueller 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 crypto/keywrap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/crypto/keywrap.c b/crypto/keywrap.c
index 744e35134c45..ec5c6a087c90 100644
--- a/crypto/keywrap.c
+++ b/crypto/keywrap.c
@@ -188,7 +188,7 @@ static int crypto_kw_decrypt(struct blkcipher_desc *desc,
}
 
/* Perform authentication check */
-   if (block.A != cpu_to_be64(0xa6a6a6a6a6a6a6a6))
+   if (block.A != cpu_to_be64(0xa6a6a6a6a6a6a6a6ULL))
ret = -EBADMSG;
 
memzero_explicit(, sizeof(struct crypto_kw_block));
@@ -221,7 +221,7 @@ static int crypto_kw_encrypt(struct blkcipher_desc *desc,
 * Place the predefined IV into block A -- for encrypt, the caller
 * does not need to provide an IV, but he needs to fetch the final IV.
 */
-   block.A = cpu_to_be64(0xa6a6a6a6a6a6a6a6);
+   block.A = cpu_to_be64(0xa6a6a6a6a6a6a6a6ULL);
 
/*
 * src scatterlist is read-only. dst scatterlist is r/w. During the
-- 
2.14.1


[PATCH AUTOSEL for 4.15 017/102] USB: ledtrig-usbport: fix of-node leak

2018-03-03 Thread Sasha Levin
From: Johan Hovold 

[ Upstream commit 03310a15484ab6a8f6d91bbf7fe486b17275c09a ]

This code looks up a USB device node from a given parent USB device but
never dropped its reference to the returned node.

As only the address of the node is used for a later matching, the
reference can be dropped immediately.

Note that this trigger implementation confuses the description of the
USB device connected to a port with the port itself (which does not have
a device-tree representation).

Fixes: 4f04c210d031 ("usb: core: read USB ports from DT in the usbport LED 
trigger driver")
Cc: Rafał Miłecki 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/core/ledtrig-usbport.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/ledtrig-usbport.c 
b/drivers/usb/core/ledtrig-usbport.c
index 9dbb429cd471..f1fde5165068 100644
--- a/drivers/usb/core/ledtrig-usbport.c
+++ b/drivers/usb/core/ledtrig-usbport.c
@@ -137,11 +137,17 @@ static bool usbport_trig_port_observed(struct 
usbport_trig_data *usbport_data,
if (!led_np)
return false;
 
-   /* Get node of port being added */
+   /*
+* Get node of port being added
+*
+* FIXME: This is really the device node of the connected device
+*/
port_np = usb_of_get_child_node(usb_dev->dev.of_node, port1);
if (!port_np)
return false;
 
+   of_node_put(port_np);
+
/* Amount of trigger sources for this LED */
count = of_count_phandle_with_args(led_np, "trigger-sources",
   "#trigger-source-cells");
-- 
2.14.1


Re: [PATCH v4 06/22] nvmem: uniphier-efuse: Convert to use devm_nvmem_register()

2018-03-03 Thread kbuild test robot
Hi Andrey,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc3 next-20180302]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrey-Smirnov/Verbatim-device-names-and-devm_nvmem_-un-register/20180303-220801


coccinelle warnings: (new ones prefixed by >>)

>> drivers/nvmem/uniphier-efuse.c:64:1-3: WARNING: PTR_ERR_OR_ZERO can be used

Please review and possibly fold the followup patch.

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


[PATCH] nvmem: uniphier-efuse: fix ptr_ret.cocci warnings

2018-03-03 Thread kbuild test robot
From: Fengguang Wu 

drivers/nvmem/uniphier-efuse.c:64:1-3: WARNING: PTR_ERR_OR_ZERO can be used


 Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Generated by: scripts/coccinelle/api/ptr_ret.cocci

Fixes: d562efb89f70 ("nvmem: uniphier-efuse: Convert to use 
devm_nvmem_register()")
CC: Andrey Smirnov 
Signed-off-by: Fengguang Wu 
---

 uniphier-efuse.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

--- a/drivers/nvmem/uniphier-efuse.c
+++ b/drivers/nvmem/uniphier-efuse.c
@@ -61,10 +61,7 @@ static int uniphier_efuse_probe(struct p
econfig.priv = priv;
econfig.dev = dev;
nvmem = devm_nvmem_register(dev, );
-   if (IS_ERR(nvmem))
-   return PTR_ERR(nvmem);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(nvmem);
 }
 
 static const struct of_device_id uniphier_efuse_of_match[] = {


[PATCH AUTOSEL for 4.15 023/102] crypto: keywrap - Add missing ULL suffixes for 64-bit constants

2018-03-03 Thread Sasha Levin
From: Geert Uytterhoeven 

[ Upstream commit c9683276dd89906ca9b65696d09104d542171421 ]

On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1):

crypto/keywrap.c: In function ‘crypto_kw_decrypt’:
crypto/keywrap.c:191: warning: integer constant is too large for ‘long’ type
crypto/keywrap.c: In function ‘crypto_kw_encrypt’:
crypto/keywrap.c:224: warning: integer constant is too large for ‘long’ type

Fixes: 9e49451d7a15365d ("crypto: keywrap - simplify code")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Stephan Mueller 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 crypto/keywrap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/crypto/keywrap.c b/crypto/keywrap.c
index 744e35134c45..ec5c6a087c90 100644
--- a/crypto/keywrap.c
+++ b/crypto/keywrap.c
@@ -188,7 +188,7 @@ static int crypto_kw_decrypt(struct blkcipher_desc *desc,
}
 
/* Perform authentication check */
-   if (block.A != cpu_to_be64(0xa6a6a6a6a6a6a6a6))
+   if (block.A != cpu_to_be64(0xa6a6a6a6a6a6a6a6ULL))
ret = -EBADMSG;
 
memzero_explicit(, sizeof(struct crypto_kw_block));
@@ -221,7 +221,7 @@ static int crypto_kw_encrypt(struct blkcipher_desc *desc,
 * Place the predefined IV into block A -- for encrypt, the caller
 * does not need to provide an IV, but he needs to fetch the final IV.
 */
-   block.A = cpu_to_be64(0xa6a6a6a6a6a6a6a6);
+   block.A = cpu_to_be64(0xa6a6a6a6a6a6a6a6ULL);
 
/*
 * src scatterlist is read-only. dst scatterlist is r/w. During the
-- 
2.14.1


[PATCH AUTOSEL for 4.15 018/102] dt-bindings: serial: Add common rs485 binding for RTS polarity

2018-03-03 Thread Sasha Levin
From: Lukas Wunner 

[ Upstream commit 6abe9ea8a5a5904d935b8a482117a7fd9b25f09e ]

rs485 allows for robust half-duplex serial communication.  It is often
implemented by attaching an rs485 transceiver to a UART.  The UART's
RTS line is wired to the transceiver's Transmit Enable pin and
determines whether the transceiver is sending or receiving.

Examples for such transceivers are Maxim MAX13451E and TI SN65HVD1781A:
https://datasheets.maximintegrated.com/en/ds/MAX13450E-MAX13451E.pdf
http://www.ti.com/lit/ds/symlink/sn65hvd1781a-q1.pdf

In the devicetree, the transceiver itself is not represented, only the
UART is.  A few rs485-specific dt-bindings already exist and these go
into the UART's device node.

This commit adds a binding to set the RTS polarity.  Most (if not all)
transceivers require the Transmit Enable pin be driven high for sending,
but in some cases boards may negate the pin and RTS must then be driven
low.  Consequently the polarity defaults to active high but can be
inverted with the newly added "rs485-rts-active-low" binding.

Document this binding in rs485.txt and in the two drivers fsl-imx-uart
and fsl-lpuart that are about to be amended with support for it.

Curiously, the omap_serial driver defaults to active low and already
supports an "rs485-rts-active-high" binding to invert the polarity.
This is left unchanged to retain compatibility, but the binding is
herewith documented.

Cc: Mark Jackson 
Cc: Michał Oleszczyk 
Cc: Rafael Gago Castano 
Cc: Sascha Hauer 
Acked-by: Rob Herring 
Signed-off-by: Lukas Wunner 
Acked-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 3 ++-
 Documentation/devicetree/bindings/serial/fsl-lpuart.txt   | 3 ++-
 Documentation/devicetree/bindings/serial/omap_serial.txt  | 1 +
 Documentation/devicetree/bindings/serial/rs485.txt| 1 +
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt 
b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
index 860a9559839a..89b92c1314cf 100644
--- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
@@ -9,7 +9,8 @@ Optional properties:
 - fsl,irda-mode : Indicate the uart supports irda mode
 - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works
   in DCE mode by default.
-- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see 
rs485.txt
+- rs485-rts-delay, rs485-rts-active-low, rs485-rx-during-tx,
+  linux,rs485-enabled-at-boot-time: see rs485.txt
 
 Please check Documentation/devicetree/bindings/serial/serial.txt
 for the complete list of generic properties.
diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt 
b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
index 59567b51cf09..6bd3f2e93d61 100644
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
@@ -16,7 +16,8 @@ Required properties:
 Optional properties:
 - dmas: A list of two dma specifiers, one for each entry in dma-names.
 - dma-names: should contain "tx" and "rx".
-- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see 
rs485.txt
+- rs485-rts-delay, rs485-rts-active-low, rs485-rx-during-tx,
+  linux,rs485-enabled-at-boot-time: see rs485.txt
 
 Note: Optional properties for DMA support. Write them both or both not.
 
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 43eac675f21f..4b0f05adb228 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -20,6 +20,7 @@ Optional properties:
  node and a DMA channel number.
 - dma-names : "rx" for receive channel, "tx" for transmit channel.
 - rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see 
rs485.txt
+- rs485-rts-active-high: drive RTS high when sending (default is low).
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/serial/rs485.txt 
b/Documentation/devicetree/bindings/serial/rs485.txt
index b8415936dfdb..b7c29f74ebb2 100644
--- a/Documentation/devicetree/bindings/serial/rs485.txt
+++ b/Documentation/devicetree/bindings/serial/rs485.txt
@@ -12,6 +12,7 @@ Optional properties:
   * b is the delay between end of data sent and rts signal in milliseconds
   it corresponds to the delay after sending data and actual release of the 
line.
   If this property is not specified, <0 0> is assumed.
+- rs485-rts-active-low: drive RTS low when sending (default is high).
 - 

[PATCH AUTOSEL for 4.15 018/102] dt-bindings: serial: Add common rs485 binding for RTS polarity

2018-03-03 Thread Sasha Levin
From: Lukas Wunner 

[ Upstream commit 6abe9ea8a5a5904d935b8a482117a7fd9b25f09e ]

rs485 allows for robust half-duplex serial communication.  It is often
implemented by attaching an rs485 transceiver to a UART.  The UART's
RTS line is wired to the transceiver's Transmit Enable pin and
determines whether the transceiver is sending or receiving.

Examples for such transceivers are Maxim MAX13451E and TI SN65HVD1781A:
https://datasheets.maximintegrated.com/en/ds/MAX13450E-MAX13451E.pdf
http://www.ti.com/lit/ds/symlink/sn65hvd1781a-q1.pdf

In the devicetree, the transceiver itself is not represented, only the
UART is.  A few rs485-specific dt-bindings already exist and these go
into the UART's device node.

This commit adds a binding to set the RTS polarity.  Most (if not all)
transceivers require the Transmit Enable pin be driven high for sending,
but in some cases boards may negate the pin and RTS must then be driven
low.  Consequently the polarity defaults to active high but can be
inverted with the newly added "rs485-rts-active-low" binding.

Document this binding in rs485.txt and in the two drivers fsl-imx-uart
and fsl-lpuart that are about to be amended with support for it.

Curiously, the omap_serial driver defaults to active low and already
supports an "rs485-rts-active-high" binding to invert the polarity.
This is left unchanged to retain compatibility, but the binding is
herewith documented.

Cc: Mark Jackson 
Cc: Michał Oleszczyk 
Cc: Rafael Gago Castano 
Cc: Sascha Hauer 
Acked-by: Rob Herring 
Signed-off-by: Lukas Wunner 
Acked-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 Documentation/devicetree/bindings/serial/fsl-imx-uart.txt | 3 ++-
 Documentation/devicetree/bindings/serial/fsl-lpuart.txt   | 3 ++-
 Documentation/devicetree/bindings/serial/omap_serial.txt  | 1 +
 Documentation/devicetree/bindings/serial/rs485.txt| 1 +
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt 
b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
index 860a9559839a..89b92c1314cf 100644
--- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.txt
@@ -9,7 +9,8 @@ Optional properties:
 - fsl,irda-mode : Indicate the uart supports irda mode
 - fsl,dte-mode : Indicate the uart works in DTE mode. The uart works
   in DCE mode by default.
-- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see 
rs485.txt
+- rs485-rts-delay, rs485-rts-active-low, rs485-rx-during-tx,
+  linux,rs485-enabled-at-boot-time: see rs485.txt
 
 Please check Documentation/devicetree/bindings/serial/serial.txt
 for the complete list of generic properties.
diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt 
b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
index 59567b51cf09..6bd3f2e93d61 100644
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
@@ -16,7 +16,8 @@ Required properties:
 Optional properties:
 - dmas: A list of two dma specifiers, one for each entry in dma-names.
 - dma-names: should contain "tx" and "rx".
-- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see 
rs485.txt
+- rs485-rts-delay, rs485-rts-active-low, rs485-rx-during-tx,
+  linux,rs485-enabled-at-boot-time: see rs485.txt
 
 Note: Optional properties for DMA support. Write them both or both not.
 
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 43eac675f21f..4b0f05adb228 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -20,6 +20,7 @@ Optional properties:
  node and a DMA channel number.
 - dma-names : "rx" for receive channel, "tx" for transmit channel.
 - rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see 
rs485.txt
+- rs485-rts-active-high: drive RTS high when sending (default is low).
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/serial/rs485.txt 
b/Documentation/devicetree/bindings/serial/rs485.txt
index b8415936dfdb..b7c29f74ebb2 100644
--- a/Documentation/devicetree/bindings/serial/rs485.txt
+++ b/Documentation/devicetree/bindings/serial/rs485.txt
@@ -12,6 +12,7 @@ Optional properties:
   * b is the delay between end of data sent and rts signal in milliseconds
   it corresponds to the delay after sending data and actual release of the 
line.
   If this property is not specified, <0 0> is assumed.
+- rs485-rts-active-low: drive RTS low when sending (default is high).
 - linux,rs485-enabled-at-boot-time: empty property telling to enable the rs485
   feature at boot time. It can be disabled later with proper ioctl.
 - rs485-rx-during-tx: empty property that enables the receiving of data even
-- 
2.14.1


[PATCH AUTOSEL for 4.15 024/102] crypto: cavium - fix memory leak on info

2018-03-03 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 87aae50af730a28dc1d8846d86dca5e9aa724a9f ]

The object info is being leaked on an error return path, fix this
by setting ret to -ENOMEM and exiting via the request_cleanup path
that will free info.

Detected by CoverityScan, CID#1408439 ("Resource Leak")

Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT")
Signed-off-by: Colin Ian King 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c 
b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
index 169e66231bcf..b0ba4331944b 100644
--- a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
+++ b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
@@ -459,7 +459,8 @@ int process_request(struct cpt_vf *cptvf, struct 
cpt_request_info *req)
info->completion_addr = kzalloc(sizeof(union cpt_res_s), GFP_KERNEL);
if (unlikely(!info->completion_addr)) {
dev_err(>dev, "Unable to allocate memory for 
completion_addr\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto request_cleanup;
}
 
result = (union cpt_res_s *)info->completion_addr;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 024/102] crypto: cavium - fix memory leak on info

2018-03-03 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 87aae50af730a28dc1d8846d86dca5e9aa724a9f ]

The object info is being leaked on an error return path, fix this
by setting ret to -ENOMEM and exiting via the request_cleanup path
that will free info.

Detected by CoverityScan, CID#1408439 ("Resource Leak")

Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT")
Signed-off-by: Colin Ian King 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c 
b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
index 169e66231bcf..b0ba4331944b 100644
--- a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
+++ b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c
@@ -459,7 +459,8 @@ int process_request(struct cpt_vf *cptvf, struct 
cpt_request_info *req)
info->completion_addr = kzalloc(sizeof(union cpt_res_s), GFP_KERNEL);
if (unlikely(!info->completion_addr)) {
dev_err(>dev, "Unable to allocate memory for 
completion_addr\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto request_cleanup;
}
 
result = (union cpt_res_s *)info->completion_addr;
-- 
2.14.1


[PATCH AUTOSEL for 4.15 021/102] crypto: chelsio - Fix an error code in chcr_hash_dma_map()

2018-03-03 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 7814f552ff826fefa5e1b24083c7a06a9378e9ef ]

The dma_map_sg() function returns zero on error and positive values on
success.  We want to return -ENOMEM on failure here and zero on success.

Fixes: 2f47d5804311 ("crypto: chelsio - Move DMA un/mapping to chcr from lld 
cxgb4 driver")
Signed-off-by: Dan Carpenter 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/chelsio/chcr_algo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/chelsio/chcr_algo.c 
b/drivers/crypto/chelsio/chcr_algo.c
index 4eed7171e2ae..38fe59b5c689 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -2414,7 +2414,7 @@ static inline int chcr_hash_dma_map(struct device *dev,
error = dma_map_sg(dev, req->src, sg_nents(req->src),
   DMA_TO_DEVICE);
if (!error)
-   return error;
+   return -ENOMEM;
req_ctx->is_sg_map = 1;
return 0;
 }
-- 
2.14.1


[PATCH AUTOSEL for 4.15 021/102] crypto: chelsio - Fix an error code in chcr_hash_dma_map()

2018-03-03 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 7814f552ff826fefa5e1b24083c7a06a9378e9ef ]

The dma_map_sg() function returns zero on error and positive values on
success.  We want to return -ENOMEM on failure here and zero on success.

Fixes: 2f47d5804311 ("crypto: chelsio - Move DMA un/mapping to chcr from lld 
cxgb4 driver")
Signed-off-by: Dan Carpenter 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/chelsio/chcr_algo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/chelsio/chcr_algo.c 
b/drivers/crypto/chelsio/chcr_algo.c
index 4eed7171e2ae..38fe59b5c689 100644
--- a/drivers/crypto/chelsio/chcr_algo.c
+++ b/drivers/crypto/chelsio/chcr_algo.c
@@ -2414,7 +2414,7 @@ static inline int chcr_hash_dma_map(struct device *dev,
error = dma_map_sg(dev, req->src, sg_nents(req->src),
   DMA_TO_DEVICE);
if (!error)
-   return error;
+   return -ENOMEM;
req_ctx->is_sg_map = 1;
return 0;
 }
-- 
2.14.1


  1   2   3   4   5   6   7   8   9   10   >