Re: [PATCH] clarify how insecure CPU is
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
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()
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()
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()
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()
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
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
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
> 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
> 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
> > 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
> > 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
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
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
> 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
> 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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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()
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()
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
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
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
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
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
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
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()
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
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()
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
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
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
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()
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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()
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
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()
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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
From: Fengguang Wudrivers/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
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
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()
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
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
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
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
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
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
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()
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()
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