[RFC PATCH] compiler.h: give up __compiletime_assert_fallback()

2018-08-18 Thread Masahiro Yamada
__compiletime_assert_fallback() is supposed to stop building earlier
by using the negative-array-size method in case the compiler does not
support "error" attribute, but has never worked like that.

You can try this simple code:

#include 
void foo(void)
{
BUILD_BUG_ON(1);
}

GCC (precisely, GCC 4.3 or later) immediately terminates the build,
but Clang does not report anything because Clang does not support the
"error" attribute now.  It will eventually fail in the link stage,
but at least __compiletime_assert_fallback() is not working.

The root cause is commit 1d6a0d19c855 ("bug.h: prevent double evaluation
of `condition' in BUILD_BUG_ON").  Prior to that commit, BUILD_BUG_ON()
was checked by the negative-array-size method *and* the link-time trick.
Since that commit, the negative-array-size is not effective because
'__cond' is no longer constant.  As the comment in 
says, GCC (and Clang as well) only emits the error for obvious cases.

When '__cond' is a variable,

((void)sizeof(char[1 - 2 * __cond]))

... is not obvious for the compiler to know the array size is negative.

One way to fix this is to stop the variable assignment, i.e. to pass
'!(condition)' directly to __compiletime_error_fallback() at the cost
of the double evaluation of 'condition'.  However, all calls of
BUILD_BUG() would be turned into errors even if they are called from
dead-code.

This commit does not change the current behavior since it just rips
off the code that has not been effective for some years.

Signed-off-by: Masahiro Yamada 
---

 include/linux/compiler.h | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 42506e4..c062238f4 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -295,29 +295,14 @@ unsigned long read_word_at_a_time(const void *addr)
 #endif
 #ifndef __compiletime_error
 # define __compiletime_error(message)
-/*
- * Sparse complains of variable sized arrays due to the temporary variable in
- * __compiletime_assert. Unfortunately we can't just expand it out to make
- * sparse see a constant array size without breaking compiletime_assert on old
- * versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether.
- */
-# ifndef __CHECKER__
-#  define __compiletime_error_fallback(condition) \
-   do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
-# endif
-#endif
-#ifndef __compiletime_error_fallback
-# define __compiletime_error_fallback(condition) do { } while (0)
 #endif
 
 #ifdef __OPTIMIZE__
 # define __compiletime_assert(condition, msg, prefix, suffix)  \
do {\
-   bool __cond = !(condition); \
extern void prefix ## suffix(void) __compiletime_error(msg); \
-   if (__cond) \
+   if (!(condition))   \
prefix ## suffix(); \
-   __compiletime_error_fallback(__cond);   \
} while (0)
 #else
 # define __compiletime_assert(condition, msg, prefix, suffix) do { } while (0)
-- 
2.7.4



Re: problem in building 4.8.0: references to non-existent util CLANG

2018-08-18 Thread L A Walsh

Randy Dunlap wrote:

On 08/18/2018 05:48 PM, Linda Walsh wrote:
  

Is CLANG required for building now?


Looks like this patch should fix it:
https://marc.info/?l=linux-kbuild=153447099313149=2
  

---
 Thanks much!




RE: [char-misc-next 00/12] mei: Add DMA ring

2018-08-18 Thread Winkler, Tomas


> 
> > On Tue, Jul 31, 2018 at 09:35:32AM +0300, Tomas Winkler wrote:
> > > This series adds an alternative method for transferring data between
> > > the mei driver and the device via a DMA ring. The DMA ring allows
> > > transferring data in bigger chunks, up to 128K, than the HW ring 512B.
> > > The actual sizes depend on particular MEI generations.
> > > The HW ring is faster for packets that fits into the HW ring while a
> > > packet that would require fragmentation is faster to send via the
> > > DMA ring.
> >
> > I've applied the first 5 patches now.  Please fix up and resend the rest.
> 
> Greg, as I wrote, we wish to stay with the dual license in that file,  please 
> can
> you apply the patches as they are?

Hi Greg, can you please respond, we have half of the series merged only, it 
should be completed.
Thanks
Tomas



Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"

2018-08-18 Thread Bjorn Helgaas
On Sat, Aug 18, 2018 at 01:24:51PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote:
> > > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76.
> > 
> > Just to be clear, if I understand correctly, this is a pure revert of
> > 44bda4b7d26e and as such it reintroduces the problem solved by that
> > commit.
> > 
> > If your solution turns out to be better, that's great, but it would be
> > nice to avoid the bisection hole of reintroducing the problem, then
> > fixing it again later.
> 
> There is no way to do that other than merging the revert and the fix
> into one. That said, the race is sufficiently hard to hit that I
> wouldn't worry too much about it.

OK, then at least mention that in the changelog.

> > > The new pci state mutex provides a simpler way of addressing
> > > this race and avoids the relative includes added to the powerpc
> > > code.
> 


Re: problem in building 4.8.0: references to non-existent util CLANG

2018-08-18 Thread Randy Dunlap
On 08/18/2018 05:48 PM, Linda Walsh wrote:
> Is CLANG required for building now?
> 
> when I did a "make xconfig" (or any make, for that matter), I get:
> 
>>  make xconfig
> scripts/kconfig/qconf  Kconfig
> invocation line: ./scripts/clang-version.sh gcc ## debug line I added
> ./scripts/clang-version.sh: line 15: ./COPYING: Permission denied
> ./scripts/clang-version.sh: line 23: printf: __clang_major__: invalid number
> ./scripts/clang-version.sh: line 23: printf: __clang_minor__: invalid number
> ./scripts/clang-version.sh: line 23: printf: __clang_patchlevel__: invalid 
> number
> init/Kconfig:24:warning: 'CLANG_VERSION': number is invalid
> .config:50:warning: symbol value '0' invalid for CLANG_VERSION
> 
> The reference to COPYING comes from me running make in the
> top dir, where there is a text file named COPYING, however it is
> not executable.
> 
> I put in an echo to see what command line the script was being passed,
> "gcc"?
> 
> I'm guessing but I don't think the clang script should be getting
> called at all.  I installed the sources by patching 4.17.0 (done via a
> script).
> 
> Are there instructions somewhere for what command(s) to run for patching?
> It seems to have changed from using the standard patch program to using
> a git version that isn't compatible w/the gnu version.  I adapted the
> script to the git version and that's seemed to work since I did
> the change.  But with 4.18.0, I am uncertain if it is working correctly.
> 
> If the above was the only problem, I'd be less concerned, but
> scripts run after the main build to build external modules failed.
> It seems unlikely the two problems are related, but I wanted to fix
> this first before going on to the compile-fails.
> 
> Please Cc me, as I'm not currently on the list.
> 
> Thanks,
> Linda W.
> 

Looks like this patch should fix it:
https://marc.info/?l=linux-kbuild=153447099313149=2



-- 
~Randy


problem in building 4.8.0: references to non-existent util CLANG

2018-08-18 Thread Linda Walsh

Is CLANG required for building now?

when I did a "make xconfig" (or any make, for that matter), I get:


 make xconfig

scripts/kconfig/qconf  Kconfig
invocation line: ./scripts/clang-version.sh gcc ## debug line I added
./scripts/clang-version.sh: line 15: ./COPYING: Permission denied
./scripts/clang-version.sh: line 23: printf: __clang_major__: invalid number
./scripts/clang-version.sh: line 23: printf: __clang_minor__: invalid number
./scripts/clang-version.sh: line 23: printf: __clang_patchlevel__: 
invalid number

init/Kconfig:24:warning: 'CLANG_VERSION': number is invalid
.config:50:warning: symbol value '0' invalid for CLANG_VERSION

The reference to COPYING comes from me running make in the
top dir, where there is a text file named COPYING, however it is
not executable.

I put in an echo to see what command line the script was being passed,
"gcc"?

I'm guessing but I don't think the clang script should be getting
called at all.  I installed the sources by patching 4.17.0 (done via a
script).

Are there instructions somewhere for what command(s) to run for patching?
It seems to have changed from using the standard patch program to using
a git version that isn't compatible w/the gnu version.  I adapted the
script to the git version and that's seemed to work since I did
the change.  But with 4.18.0, I am uncertain if it is working correctly.

If the above was the only problem, I'd be less concerned, but
scripts run after the main build to build external modules failed.
It seems unlikely the two problems are related, but I wanted to fix
this first before going on to the compile-fails.

Please Cc me, as I'm not currently on the list.

Thanks,
Linda W.



Re: linux-next: Signed-off-by missing for commit in the h8300 tree

2018-08-18 Thread Stephen Rothwell
Hi Yoshinori,

On Sun, 19 Aug 2018 01:35:47 +0900 Yoshinori Sato  
wrote:
>
> > Commit
> > 
> >   85f866b60ba7 ("h8300: switch to NO_BOOTMEM")
> > 
> > is missing a Signed-off-by from its committer.  
> 
> OK. Fixed it.

This last one is still missing your Signed-off-by ...
(it is commit 09c7c64733a2, now)

-- 
Cheers,
Stephen Rothwell


pgpmhRUihn_IO.pgp
Description: OpenPGP digital signature


Re: [PATCH] sched: idle: Avoid retaining the tick when it has been stopped

2018-08-18 Thread leo . yan
On Sat, Aug 18, 2018 at 11:57:00PM +0200, Rafael J. Wysocki wrote:

[...]

> > > > Otherwise we can have something like this:
> > > >
> > > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > > > index da9455a..408c985 100644
> > > > --- a/kernel/time/tick-sched.c
> > > > +++ b/kernel/time/tick-sched.c
> > > > @@ -806,6 +806,9 @@ static void tick_nohz_stop_tick(struct tick_sched 
> > > > *ts, int cpu)
> > > >  static void tick_nohz_retain_tick(struct tick_sched *ts)
> > > >  {
> > > > ts->timer_expires_base = 0;
> > > > +
> > > > +   if (ts->tick_stopped)
> > > > +   tick_nohz_restart(ts, ktime_get());
> > > >  }
> > > >
> > > >  #ifdef CONFIG_NO_HZ_FULL
> > > >
> > >
> > > We could do that, but my concern with that approach is that we may end up
> > > stopping and starting the tick back and forth without exiting the loop
> > > in do_idle() just because somebody uses a periodic timer behind our
> > > back and the governor gets confused.
> > >
> > > Besides, that would be a change in behavior, while the $subject patch
> > > simply fixes a mistake in the original design.
> >
> > Ok, let's take the safe approach for now as this is a fix and it should 
> > even be
> > routed to stable.
> 
> Right.  I'll queue up this patch, then.
> 
> > But then in the longer term, perhaps cpuidle_select() should think that
> > through.
> 
> So I have given more consideration to this and my conclusion is that
> restarting the tick between cpuidle_select() and call_cpuidle() is a
> bad idea.
> 
> First off, if need_resched() is "false", the primary reason for
> running the tick on the given CPU is not there, so it only might be
> useful as a "backup" timer to wake up the CPU from an inadequate idle
> state.
> 
> Now, in general, there are two reasons for the idle governor (whatever
> it is) to select an idle state with a target residency below the tick
> period length.  The first reason is when the governor knows that the
> closest timer event is going to occur in this time frame, but in that
> case (as stated above), it is not necessary to worry about the tick,
> because the other timer will trigger soon enough anyway.  The second
> reason is when the governor predicts a wakeup which is not by a timer
> in this time frame and it is quite arguable what the governor should
> do then.  IMO it at least is not unreasonable to throw the prediction
> away and still go for the closest timer event in that case (which is
> the current approach).
> 
> There's more, though.  Restarting the tick between cpuidle_select()
> and call_cpuidle() might introduce quite a bit of latency into that
> point and that would mess up with the idle state selection (e.g.
> selecting a very shallow idle state might not make a lot of sense if
> that latency was high enough, because the expected wakeup might very
> well take place when the tick was being restarted), so it should
> rather be avoided IMO.

I expect the idle governor doesn't introduce many restarting tick
operations, the reason is if there have a close timer event than idle
governor can trust it to wake up CPU so in this case the idle governor
will not restart tick;  if the the timer event is long delta and the
shallow state selection is caused by factors (e.g. typical pattern),
then we need restart tick to avoid powernightmares, for this case we
can restart tick only once at the beginning for the typical pattern
interrupt events; after the typical pattern interrupt doesn't continue
then we can rely on the tick to rescue the idle state to deep one.

Thanks,
Leo Yan


Re: linux-next: manual merge of the nvdimm tree with the tip tree

2018-08-18 Thread Stephen Rothwell
Hi all,

On Tue, 26 Jun 2018 12:18:53 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the nvdimm tree got a conflict in:
> 
>   arch/x86/kernel/cpu/mcheck/mce.c
> 
> between commit:
> 
>   d3d6923cd1ae ("x86/mce: Carve out the crashing_cpu check")
> 
> from the tip tree and commit:
> 
>   f6785eac562b ("x86/memory_failure: Introduce {set,clear}_mce_nospec()")
> 
> from the nvdimm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/kernel/cpu/mcheck/mce.c
> index 9a16f15f79eb,a0fbf0a8b7e6..
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@@ -1076,129 -1070,6 +1072,100 @@@ static int do_memory_failure(struct mc
>   return ret;
>   }
>   
> - #ifndef mce_unmap_kpfn
> - static void mce_unmap_kpfn(unsigned long pfn)
> - {
> - unsigned long decoy_addr;
> - 
> - /*
> -  * Unmap this page from the kernel 1:1 mappings to make sure
> -  * we don't log more errors because of speculative access to
> -  * the page.
> -  * We would like to just call:
> -  *  set_memory_np((unsigned long)pfn_to_kaddr(pfn), 1);
> -  * but doing that would radically increase the odds of a
> -  * speculative access to the poison page because we'd have
> -  * the virtual address of the kernel 1:1 mapping sitting
> -  * around in registers.
> -  * Instead we get tricky.  We create a non-canonical address
> -  * that looks just like the one we want, but has bit 63 flipped.
> -  * This relies on set_memory_np() not checking whether we passed
> -  * a legal address.
> -  */
> - 
> - decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63));
> - 
> - if (set_memory_np(decoy_addr, 1))
> - pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn);
> - }
> - #endif
> - 
> - 
>  +/*
>  + * Cases where we avoid rendezvous handler timeout:
>  + * 1) If this CPU is offline.
>  + *
>  + * 2) If crashing_cpu was set, e.g. we're entering kdump and we need to
>  + *  skip those CPUs which remain looping in the 1st kernel - see
>  + *  crash_nmi_callback().
>  + *
>  + * Note: there still is a small window between kexec-ing and the new,
>  + * kdump kernel establishing a new #MC handler where a broadcasted MCE
>  + * might not get handled properly.
>  + */
>  +static bool __mc_check_crashing_cpu(int cpu)
>  +{
>  +if (cpu_is_offline(cpu) ||
>  +(crashing_cpu != -1 && crashing_cpu != cpu)) {
>  +u64 mcgstatus;
>  +
>  +mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
>  +if (mcgstatus & MCG_STATUS_RIPV) {
>  +mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
>  +return true;
>  +}
>  +}
>  +return false;
>  +}
>  +
>  +static void __mc_scan_banks(struct mce *m, struct mce *final,
>  +unsigned long *toclear, unsigned long *valid_banks,
>  +int no_way_out, int *worst)
>  +{
>  +struct mca_config *cfg = _cfg;
>  +int severity, i;
>  +
>  +for (i = 0; i < cfg->banks; i++) {
>  +__clear_bit(i, toclear);
>  +if (!test_bit(i, valid_banks))
>  +continue;
>  +
>  +if (!mce_banks[i].ctl)
>  +continue;
>  +
>  +m->misc = 0;
>  +m->addr = 0;
>  +m->bank = i;
>  +
>  +m->status = mce_rdmsrl(msr_ops.status(i));
>  +if (!(m->status & MCI_STATUS_VAL))
>  +continue;
>  +
>  +/*
>  + * Corrected or non-signaled errors are handled by
>  + * machine_check_poll(). Leave them alone, unless this panics.
>  + */
>  +if (!(m->status & (cfg->ser ? MCI_STATUS_S : MCI_STATUS_UC)) &&
>  +!no_way_out)
>  +continue;
>  +
>  +/* Set taint even when machine check was not enabled. */
>  +add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
>  +
>  +severity = mce_severity(m, cfg->tolerant, NULL, true);
>  +
>  +/*
>  + * When machine check was for corrected/deferred handler don't
>  + * touch, unless we're panicking.
>  + */
>  +if ((severity == MCE_KEEP_SEVERITY ||
>  + severity == MCE_UCNA_SEVERITY) && !no_way_out)
>  +continue;
>  +
>  +__set_bit(i, toclear);
>  +
>  +/* Machine check event was not enabled. Clear, but ignore. */
>  +if (severity == MCE_NO_SEVERITY)
>  +   

Re: linux-next: manual merge of the driver-core tree with the iommu tree

2018-08-18 Thread Stephen Rothwell
Hi all,

On Wed, 11 Jul 2018 13:14:45 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the driver-core tree got a conflict in:
> 
>   drivers/iommu/ipmmu-vmsa.c
> 
> between commits:
> 
>   0b8ac1409641 ("iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code")
>   3701c123e1c1 ("iommu/ipmmu-vmsa: Hook up r8a779(70|95) DT matching code")
>   98dbffd39a65 ("iommu/ipmmu-vmsa: Hook up R8A77965 DT matching code")
> 
> from the iommu tree and commit:
> 
>   ac6bbf0cdf42 ("iommu: Remove IOMMU_OF_DECLARE")
> 
> from the driver-core tree.
> 
> I fixed it up (I removed the new IOMMU_OF_DECLARE() lines) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the
> conflicting tree to minimise any particularly complex conflicts.

This is now a conflict between Linus' tree and the iommu tree.
-- 
Cheers,
Stephen Rothwell


pgpE5XPJfcurR.pgp
Description: OpenPGP digital signature


donation

2018-08-18 Thread Xiang, Feifei




--
donation of $3 to you, contact hams@hotmail.com to verefly


[PATCH] export.h: remove VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR()

2018-08-18 Thread Masahiro Yamada
With the special case handling for Blackfin and Metag was removed by
commit 94e58e0ac312 ("export.h: remove code for prefixing symbols with
underscore"), VMLINUX_SYMBOL() is no-no.

Replace the remaining usages, then remove the definition of
VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR().

 no longer needs to include .

Signed-off-by: Masahiro Yamada 
---

 certs/system_certificates.S   | 16 
 include/asm-generic/vmlinux.lds.h |  2 --
 include/linux/export.h|  7 ---
 usr/initramfs_data.S  |  4 ++--
 4 files changed, 10 insertions(+), 19 deletions(-)

diff --git a/certs/system_certificates.S b/certs/system_certificates.S
index 3918ff7..8f29058 100644
--- a/certs/system_certificates.S
+++ b/certs/system_certificates.S
@@ -5,8 +5,8 @@
__INITRODATA
 
.align 8
-   .globl VMLINUX_SYMBOL(system_certificate_list)
-VMLINUX_SYMBOL(system_certificate_list):
+   .globl system_certificate_list
+system_certificate_list:
 __cert_list_start:
 #ifdef CONFIG_MODULE_SIG
.incbin "certs/signing_key.x509"
@@ -15,21 +15,21 @@ __cert_list_start:
 __cert_list_end:
 
 #ifdef CONFIG_SYSTEM_EXTRA_CERTIFICATE
-   .globl VMLINUX_SYMBOL(system_extra_cert)
+   .globl system_extra_cert
.size system_extra_cert, CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE
-VMLINUX_SYMBOL(system_extra_cert):
+system_extra_cert:
.fill CONFIG_SYSTEM_EXTRA_CERTIFICATE_SIZE, 1, 0
 
.align 4
-   .globl VMLINUX_SYMBOL(system_extra_cert_used)
-VMLINUX_SYMBOL(system_extra_cert_used):
+   .globl system_extra_cert_used
+system_extra_cert_used:
.int 0
 
 #endif /* CONFIG_SYSTEM_EXTRA_CERTIFICATE */
 
.align 8
-   .globl VMLINUX_SYMBOL(system_certificate_list_size)
-VMLINUX_SYMBOL(system_certificate_list_size):
+   .globl system_certificate_list_size
+system_certificate_list_size:
 #ifdef CONFIG_64BIT
.quad __cert_list_end - __cert_list_start
 #else
diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index f173b5f..7b75ff6 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -54,8 +54,6 @@
 #define LOAD_OFFSET 0
 #endif
 
-#include 
-
 /* Align . to a 8 byte boundary equals to maximum function alignment. */
 #define ALIGN_FUNCTION()  . = ALIGN(8)
 
diff --git a/include/linux/export.h b/include/linux/export.h
index b768d6d..c363bde 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -10,13 +10,6 @@
  * hackers place grumpy comments in header files.
  */
 
-#define __VMLINUX_SYMBOL(x) x
-#define __VMLINUX_SYMBOL_STR(x) #x
-
-/* Indirect, so macros are expanded before pasting. */
-#define VMLINUX_SYMBOL(x) __VMLINUX_SYMBOL(x)
-#define VMLINUX_SYMBOL_STR(x) __VMLINUX_SYMBOL_STR(x)
-
 #ifndef __ASSEMBLY__
 struct kernel_symbol
 {
diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S
index b28da79..d07648f 100644
--- a/usr/initramfs_data.S
+++ b/usr/initramfs_data.S
@@ -30,8 +30,8 @@ __irf_start:
 .incbin __stringify(INITRAMFS_IMAGE)
 __irf_end:
 .section .init.ramfs.info,"a"
-.globl VMLINUX_SYMBOL(__initramfs_size)
-VMLINUX_SYMBOL(__initramfs_size):
+.globl __initramfs_size
+__initramfs_size:
 #ifdef CONFIG_64BIT
.quad __irf_end - __irf_start
 #else
-- 
2.7.4



Re: Fix 80d20d35af1e ("nohz: Fix local_timer_softirq_pending()") may have revealed another problem

2018-08-18 Thread Heiner Kallweit
On 18.08.2018 13:26, Thomas Gleixner wrote:
> On Thu, 16 Aug 2018, Heiner Kallweit wrote:
> 
>> Recently I started to get warning "NOHZ: local_softirq_pending 202" and
>> I think it's related to mentioned commit (didn't bisect it yet).
>> See log from suspending.
>>
>> I have no reason to think the fix is wrong, it may just have revealed
>> another issue which existed before and was hidden by the bug.
> 
> Looks so. That seems to be related to CPU offlining. No idea yet...
> 
I checked a little further and at the time the warning is printed the
cpu is still online but not active any longer.
I can avoid the warning with the following change, but as a
disclaimer: I have no clue of this subsystem and don't know what
I'm doing ..

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 5b33e2f5c..19a030e40 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -862,13 +862,13 @@ static void tick_nohz_full_update_tick(struct tick_sched 
*ts)
 static bool can_stop_idle_tick(int cpu, struct tick_sched *ts)
 {
/*
-* If this CPU is offline and it is the one which updates
+* If this CPU is inactive and it is the one which updates
 * jiffies, then give up the assignment and let it be taken by
 * the CPU which runs the tick timer next. If we don't drop
 * this here the jiffies might be stale and do_timer() never
 * invoked.
 */
-   if (unlikely(!cpu_online(cpu))) {
+   if (unlikely(!cpu_active(cpu))) {
if (cpu == tick_do_timer_cpu)
tick_do_timer_cpu = TICK_DO_TIMER_NONE;
/*
-- 



>> Rgds, Heiner
>>
>> [   75.073353] random: crng init done
>> [   75.073402] random: 7 urandom warning(s) missed due to ratelimiting
>> [   78.619564] PM: suspend entry (deep)
>> [   78.619675] PM: Syncing filesystems ... done.
>> [   78.653684] Freezing user space processes ... (elapsed 0.002 seconds) 
>> done.
>> [   78.656094] OOM killer disabled.
>> [   78.656113] Freezing remaining freezable tasks ... (elapsed 0.001 
>> seconds) done.
>> [   78.658177] Suspending console(s) (use no_console_suspend to debug)
>> [   78.663066] nuvoton-cir 00:07: disabled
>> [   78.671817] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>> [   78.672210] sd 0:0:0:0: [sda] Stopping disk
>> [   78.786651] ACPI: Preparing to enter system sleep state S3
>> [   78.789613] PM: Saving platform NVS memory
>> [   78.789759] Disabling non-boot CPUs ...
>> [   78.805154] NOHZ: local_softirq_pending 202
>> [   78.805182] NOHZ: local_softirq_pending 202
>> [   78.807102] smpboot: CPU 1 is now offline
>>
> 



KINDLY REPLY stemlightresour...@gmail.com URGENTLY

2018-08-18 Thread STEMLIGHTRESOURCES
KINDLY REPLY stemlightresour...@gmail.com URGENTLY


KASAN: use-after-free Read in do_shrink_slab

2018-08-18 Thread syzbot

Hello,

syzbot found the following crash on:

HEAD commit:1f7a4c73a739 Merge tag '9p-for-4.19-2' of git://github.com..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16c46d9a40
kernel config:  https://syzkaller.appspot.com/x/.config?x=68e80edb3c9718c5
dashboard link: https://syzkaller.appspot.com/bug?extid=d5f648a1bfe15678786b
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d5f648a1bfe156787...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in do_shrink_slab+0xbd4/0xcb0 mm/vmscan.c:456
Read of size 8 at addr 8801ae513558 by task syz-executor6/20506

CPU: 0 PID: 20506 Comm: syz-executor6 Not tainted 4.18.0+ #195
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
 print_address_description+0x6c/0x20b mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
 do_shrink_slab+0xbd4/0xcb0 mm/vmscan.c:456
 shrink_slab_memcg mm/vmscan.c:600 [inline]
 shrink_slab+0x7b7/0x990 mm/vmscan.c:673
 shrink_node+0x429/0x16a0 mm/vmscan.c:2734
 shrink_zones mm/vmscan.c:2963 [inline]
 do_try_to_free_pages+0x3e7/0x1290 mm/vmscan.c:3025
 try_to_free_mem_cgroup_pages+0x49d/0xc90 mm/vmscan.c:3323
 memory_high_write+0x283/0x310 mm/memcontrol.c:5399
 cgroup_file_write+0x31f/0x840 kernel/cgroup/cgroup.c:3447
 kernfs_fop_write+0x2ba/0x480 fs/kernfs/file.c:316
 __vfs_write+0x117/0x9d0 fs/read_write.c:485
 __kernel_write+0x10c/0x380 fs/read_write.c:506
 write_pipe_buf+0x181/0x240 fs/splice.c:798
 splice_from_pipe_feed fs/splice.c:503 [inline]
 __splice_from_pipe+0x38e/0x7c0 fs/splice.c:627
 splice_from_pipe+0x1ea/0x340 fs/splice.c:662
 default_file_splice_write+0x3c/0x90 fs/splice.c:810
 do_splice_from fs/splice.c:852 [inline]
 direct_splice_actor+0x128/0x190 fs/splice.c:1019
 splice_direct_to_actor+0x318/0x8f0 fs/splice.c:974
 do_splice_direct+0x2d4/0x420 fs/splice.c:1062
 do_sendfile+0x623/0xe20 fs/read_write.c:1440
 __do_sys_sendfile64 fs/read_write.c:1501 [inline]
 __se_sys_sendfile64 fs/read_write.c:1487 [inline]
 __x64_sys_sendfile64+0x1fd/0x250 fs/read_write.c:1487
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7f7151c7ac78 EFLAGS: 0246 ORIG_RAX: 0028
RAX: ffda RBX: 7f7151c7b6d4 RCX: 00457089
RDX:  RSI: 0005 RDI: 0004
RBP: 009300a0 R08:  R09: 
R10: 0001 R11: 0246 R12: 
R13: 004d3cb0 R14: 004c8769 R15: 

Allocated by task 19741:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
 __do_kmalloc mm/slab.c:3718 [inline]
 __kmalloc+0x14e/0x760 mm/slab.c:3727
 kmalloc_array include/linux/slab.h:635 [inline]
 kcalloc include/linux/slab.h:646 [inline]
 iter_file_splice_write+0x25d/0x1010 fs/splice.c:693
 do_splice_from fs/splice.c:852 [inline]
 direct_splice_actor+0x128/0x190 fs/splice.c:1019
 splice_direct_to_actor+0x318/0x8f0 fs/splice.c:974
 do_splice_direct+0x2d4/0x420 fs/splice.c:1062
 do_sendfile+0x623/0xe20 fs/read_write.c:1440
 __do_sys_sendfile64 fs/read_write.c:1495 [inline]
 __se_sys_sendfile64 fs/read_write.c:1487 [inline]
 __x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1487
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 19741:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
 __cache_free mm/slab.c:3498 [inline]
 kfree+0xd9/0x260 mm/slab.c:3813
 iter_file_splice_write+0x78d/0x1010 fs/splice.c:777
 do_splice_from fs/splice.c:852 [inline]
 direct_splice_actor+0x128/0x190 fs/splice.c:1019
 splice_direct_to_actor+0x318/0x8f0 fs/splice.c:974
 do_splice_direct+0x2d4/0x420 fs/splice.c:1062
 do_sendfile+0x623/0xe20 fs/read_write.c:1440
 __do_sys_sendfile64 fs/read_write.c:1495 [inline]
 __se_sys_sendfile64 fs/read_write.c:1487 [inline]
 __x64_sys_sendfile64+0x15d/0x250 fs/read_write.c:1487
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at 

Re: [PATCH] sched: idle: Avoid retaining the tick when it has been stopped

2018-08-18 Thread Rafael J. Wysocki
On Fri, Aug 17, 2018 at 4:12 PM Frederic Weisbecker  wrote:
>
> On Fri, Aug 17, 2018 at 11:32:07AM +0200, Rafael J. Wysocki wrote:
> > On Thursday, August 16, 2018 3:27:24 PM CEST Frederic Weisbecker wrote:
> > > On Thu, Aug 09, 2018 at 07:08:34PM +0200, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki 
> > > >
> > > > If the tick has been stopped already, but the governor has not asked to
> > > > stop it (which it can do sometimes), the idle loop should invoke
> > > > tick_nohz_idle_stop_tick(), to let tick_nohz_stop_tick() take care
> > > > of this case properly.
> > > >
> > > > Fixes: 554c8aa8ecad (sched: idle: Select idle state before stopping the 
> > > > tick)
> > > > Signed-off-by: Rafael J. Wysocki 
> > > > ---
> > > >  kernel/sched/idle.c |2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > Index: linux-pm/kernel/sched/idle.c
> > > > ===
> > > > --- linux-pm.orig/kernel/sched/idle.c
> > > > +++ linux-pm/kernel/sched/idle.c
> > > > @@ -190,7 +190,7 @@ static void cpuidle_idle_call(void)
> > > >*/
> > > >   next_state = cpuidle_select(drv, dev, _tick);
> > > >
> > > > - if (stop_tick)
> > > > + if (stop_tick || tick_nohz_tick_stopped())
> > > >   tick_nohz_idle_stop_tick();
> > > >   else
> > > >   tick_nohz_idle_retain_tick();
> > >
> > > So what if tick_nohz_idle_stop_tick() sees no timer to schedule and
> > > cancels it, we may remain idle in a shallow state for a long while?
> >
> > Yes, but the governor is expected to avoid using shallow states when the
> > tick is stopped already.
>
> So what kind of sleep do we enter to when an idle tick fires and we go
> back to idle? Is it always deep?

No, it isn't.

The state to select must always fit the time till the closest timer
event and that may be shorter than the tick period.

If there's a non-tick timer to wake the CPU up, we don't need to worry
about restarting the tick, though. :-)

> I believe that ts->tick_stopped == 1 shouldn't be too relevant for the 
> governor.
> We can definetly have scenarios where the idle tick is stopped for a long 
> while,
> then it fires and schedules the next timer at NOW() + TICK_NSEC (as if the 
> tick
> had been restarted). This can even repeat that way for some time, because
> ts->tick_stopped == 1 only implies that the tick has been stopped once since
> we entered the idle loop. After that we may well have a periodic tick 
> behaviour.
> In that case we probably don't want deep idle state. Especially if we have:
>
>   idle_loop() {
>   tick_stop (scheduled several seconds forward)
>   deep_idle_sleep()
>   //several seconds later
>   tick()
>   tick_stop (scheduled TICK_NSEC forward)
>   deep_idle_sleep()
>   tick() {
>   set_need_resched()
>   }
>   exit idle loop
>   }
>
> Here the last deep idle state isn't necessary.

No, it isn't.

However, that is not relevant for the question of whether or not to
restart the tick before entering the idle state IMO (see the
considerations below).

> >
> > > Otherwise we can have something like this:
> > >
> > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > > index da9455a..408c985 100644
> > > --- a/kernel/time/tick-sched.c
> > > +++ b/kernel/time/tick-sched.c
> > > @@ -806,6 +806,9 @@ static void tick_nohz_stop_tick(struct tick_sched 
> > > *ts, int cpu)
> > >  static void tick_nohz_retain_tick(struct tick_sched *ts)
> > >  {
> > > ts->timer_expires_base = 0;
> > > +
> > > +   if (ts->tick_stopped)
> > > +   tick_nohz_restart(ts, ktime_get());
> > >  }
> > >
> > >  #ifdef CONFIG_NO_HZ_FULL
> > >
> >
> > We could do that, but my concern with that approach is that we may end up
> > stopping and starting the tick back and forth without exiting the loop
> > in do_idle() just because somebody uses a periodic timer behind our
> > back and the governor gets confused.
> >
> > Besides, that would be a change in behavior, while the $subject patch
> > simply fixes a mistake in the original design.
>
> Ok, let's take the safe approach for now as this is a fix and it should even 
> be
> routed to stable.

Right.  I'll queue up this patch, then.

> But then in the longer term, perhaps cpuidle_select() should think that
> through.

So I have given more consideration to this and my conclusion is that
restarting the tick between cpuidle_select() and call_cpuidle() is a
bad idea.

First off, if need_resched() is "false", the primary reason for
running the tick on the given CPU is not there, so it only might be
useful as a "backup" timer to wake up the CPU from an inadequate idle
state.

Now, in general, there are two reasons for the idle governor (whatever
it is) to select an idle state with a 

[RFC PATCH] scripts: add header bloat measuring script

2018-08-18 Thread Rasmus Villemoes
With a little cooperation from fixdep, we can rather easily quantify the
header bloat phenomenon.

While computing CONFIG_ dependencies, fixdep opens all the headers used
by a given translation unit anyway, so it's rather cheap to have it
record the number and total size of those in the generated .o.cmd file.

Those lines can then be post-processed and summarized by the new
header-bloat-stat.pl script. For example, backporting this to v4.17 and
v4.18 releases shows that for a defconfig x86_64 kernel, the median
"bloat factor" (total size of translation unit)/(size of .c file)
increased from 237.7 to 239.8, and the average total translation unit
size grew by 2.5% while the average .c file only increased by
0.4%. While these numbers by themselves are not particularly alarming,
when accumulated over several releases, builds do get noticably slower -
back at v3.0, the median bloat factor was 177.8.

Having infrastrucure like this makes it easier to measure the effect
should anyone attempt something similar to the sched.h cleanup, or just
go over a subsystem trimming unused #includes from .c files (if the
script is passed one or more directories it only processes those).

On a positive note, maybe 4.19 will be a rare exception; as of
1f7a4c73a739, the median bloat factor is down to 236.0, the average .c
file has increased by 0.4% but the average total translation unit is
nevertheless 1.2% smaller, compared to v4.18.

Signed-off-by: Rasmus Villemoes 
---
For some statistics, that also include build times, for releases v3.0
through v4.15, see https://wildmoose.dk/header-bloat/ . I'm not sure
that page will remain forever, so not including the url in the commit
log.

I can certainly understand if people feel this is of too little
utility to hook into fixdep like this. It's certainly possible to do
the same statistics with external tools that just parse the .o.cmd
files themselves.

 scripts/basic/fixdep.c   | 18 +++--
 scripts/header-bloat-stat.pl | 95 
 2 files changed, 109 insertions(+), 4 deletions(-)
 create mode 100755 scripts/header-bloat-stat.pl

diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 850966f3d602..f1dec85cf9d9 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -248,7 +248,7 @@ static void parse_config_file(const char *p)
}
 }
 
-static void *read_file(const char *filename)
+static void *read_file(const char *filename, unsigned *size)
 {
struct stat st;
int fd;
@@ -276,6 +276,8 @@ static void *read_file(const char *filename)
}
buf[st.st_size] = '\0';
close(fd);
+   if (size)
+   *size += st.st_size;
 
return buf;
 }
@@ -300,6 +302,8 @@ static void parse_dep_file(char *m, const char *target, int 
insert_extra_deps)
int saw_any_target = 0;
int is_first_dep = 0;
void *buf;
+   unsigned nheaders = 0, c_size = 0, h_size = 0;
+   unsigned *sizevar;
 
while (1) {
/* Skip any "white space" */
@@ -321,6 +325,8 @@ static void parse_dep_file(char *m, const char *target, int 
insert_extra_deps)
/* The /next/ file is the first dependency */
is_first_dep = 1;
} else if (!is_ignored_file(m, p - m)) {
+   sizevar = NULL;
+
*p = '\0';
 
/*
@@ -343,13 +349,16 @@ static void parse_dep_file(char *m, const char *target, 
int insert_extra_deps)
printf("source_%s := %s\n\n",
   target, m);
printf("deps_%s := \\\n", target);
+   sizevar = _size;
}
is_first_dep = 0;
} else {
printf("  %s \\\n", m);
+   sizevar = _size;
+   nheaders++;
}
 
-   buf = read_file(m);
+   buf = read_file(m, sizevar);
parse_config_file(buf);
free(buf);
}
@@ -373,7 +382,8 @@ static void parse_dep_file(char *m, const char *target, int 
insert_extra_deps)
do_extra_deps();
 
printf("\n%s: $(deps_%s)\n\n", target, target);
-   printf("$(deps_%s):\n", target);
+   printf("$(deps_%s):\n\n", target);
+   printf("# header-stats: %u %u %u\n", nheaders, c_size, h_size);
 }
 
 int main(int argc, char *argv[])
@@ -394,7 +404,7 @@ int main(int argc, char *argv[])
 
printf("cmd_%s := %s\n\n", target, cmdline);
 
-   buf = read_file(depfile);
+   buf = read_file(depfile, NULL);
parse_dep_file(buf, target, insert_extra_deps);
free(buf);
 
diff --git a/scripts/header-bloat-stat.pl 

[PATCH] dt-bindings: input: pwm-vibrator: correct pwm-names in example

2018-08-18 Thread Brian Masney
In the example for the pwm-vibrator bindings, pwm8 is the direction pin,
and pwm9 is the enable pin. The pwm-names on the vibrator node has these
two values swapped. This patch corrects the values for pwm-names.

Signed-off-by: Brian Masney 
---
arch/arm/boot/dts/omap4-droid4-xt894.dts is actual implementation for
the example and it is correct.

 Documentation/devicetree/bindings/input/pwm-vibrator.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.txt 
b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
index 09145d18491d..2731cbb7e8d7 100644
--- a/Documentation/devicetree/bindings/input/pwm-vibrator.txt
+++ b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
@@ -60,7 +60,7 @@ Example from Motorola Droid 4:
compatible = "pwm-vibrator";
pwms = < 0 10 0>,
   < 0 10 0>;
-   pwm-names = "enable", "direction";
+   pwm-names = "direction", "enable";
direction-duty-cycle-ns = <10>;
};
 };
-- 
2.17.1



Re: [PATCH] Revert "Permit silencing of __deprecated warnings."

2018-08-18 Thread Linus Torvalds
On Fri, Aug 17, 2018 at 7:45 PM Jason Gunthorpe  wrote:
>
> Linus would prefer that __deprecated never produce a warning in an
> allyesconfig compile. Since we have been at this state for some time,
> the option no longer has a purpose.

I got rid of the option, but of the code too, and - trying to set a
good example - looked around for actual users and got rid of one
long-deprecated function that hasn't had an in-kernel user in four
years.

If there are some out-of-kernel modules still using
pcmcia_request_exclusive_irq(), I can only say "Oh wow, you haven't
fixed your broken out-of-tree module in the 8 years it has been
deprecated, see how much I care about your complaints now".

Maybe somebody will be willing to look at other cases of __deprecated,
but at least I won't be seeing warnings about it any more.

   Linus


[PATCH] staging: rtl8188eu: Removed a function and coded inline

2018-08-18 Thread Bhaskar Singh
This patch removed function named rtw_malloc2d.

I removed this function because this function is used exactly once and
function call have some overhead also.

Maybe this will improve code runtime slightly.

Signed-off-by: Bhaskar Singh 
---
 drivers/staging/rtl8188eu/core/rtw_efuse.c| 10 +-
 drivers/staging/rtl8188eu/include/osdep_service.h |  2 --
 drivers/staging/rtl8188eu/os_dep/osdep_service.c  | 14 --
 3 files changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c 
b/drivers/staging/rtl8188eu/core/rtw_efuse.c
index 0fd306a808c4..befc99c197b1 100644
--- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
+++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
@@ -86,12 +86,20 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 
_size_byte, u8  *pbuf)
u16 **eFuseWord = NULL;
u16 efuse_utilized = 0;
u8 u1temp = 0;
+   int z;
+   void **a = NULL;
 
efuseTbl = kzalloc(EFUSE_MAP_LEN_88E, GFP_KERNEL);
if (!efuseTbl)
return;
 
-   eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E, 
EFUSE_MAX_WORD_UNIT, sizeof(u16));
+   a = kzalloc(EFUSE_MAX_SECTION_88E * sizeof(void *) + 
EFUSE_MAX_SECTION_88E * EFUSE_MAX_WORD_UNIT * sizeof(u16), GFP_KERNEL);
+   if (!a)
+   goto out;
+   for (z = 0; z < EFUSE_MAX_SECTION_88E; z++)
+   a[z] = ((char *)(a + EFUSE_MAX_SECTION_88E)) + z * 
EFUSE_MAX_WORD_UNIT * sizeof(u16);
+out:
+   eFuseWord = (u16 **)a;
if (!eFuseWord) {
DBG_88E("%s: alloc eFuseWord fail!\n", __func__);
goto eFuseWord_failed;
diff --git a/drivers/staging/rtl8188eu/include/osdep_service.h 
b/drivers/staging/rtl8188eu/include/osdep_service.h
index fbcba79a0927..cfe5698fbbb1 100644
--- a/drivers/staging/rtl8188eu/include/osdep_service.h
+++ b/drivers/staging/rtl8188eu/include/osdep_service.h
@@ -64,8 +64,6 @@ static inline int rtw_netif_queue_stopped(struct net_device 
*pnetdev)
 u8 *_rtw_malloc(u32 sz);
 #define rtw_malloc(sz) _rtw_malloc((sz))
 
-void *rtw_malloc2d(int h, int w, int size);
-
 void _rtw_init_queue(struct __queue *pqueue);
 
 struct rtw_netdev_priv_indicator {
diff --git a/drivers/staging/rtl8188eu/os_dep/osdep_service.c 
b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
index 78daef6704ac..105f3f21bdea 100644
--- a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
+++ b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
@@ -18,20 +18,6 @@ u8 *_rtw_malloc(u32 sz)
return kmalloc(sz, in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
 }
 
-void *rtw_malloc2d(int h, int w, int size)
-{
-   int j;
-   void **a = kzalloc(h * sizeof(void *) + h * w * size, GFP_KERNEL);
-
-   if (!a)
-   goto out;
-
-   for (j = 0; j < h; j++)
-   a[j] = ((char *)(a + h)) + j * w * size;
-out:
-   return a;
-}
-
 void _rtw_init_queue(struct __queue *pqueue)
 {
INIT_LIST_HEAD(>queue);
-- 
2.16.4



Re: Current LTS and their EOL

2018-08-18 Thread Ben Hutchings
On Fri, 2018-08-17 at 23:48 +0100, Greg KH wrote:
> On Fri, Aug 17, 2018 at 08:40:06AM -0700, Rodrigo Vivi wrote:
> > Hi Greg, Ben, and all
> > 
> > Is https://www.kernel.org/category/releases.html updated in terms of EOL?
> 
> As of right now, for the kernels I maintain, yes, it is correct.
> 
> > Some news out of Linaro conference [2] generated a lot of doubts and 
> > questions
> > around.
> > 
> > Specially because on the way it was stated by the news 3.16 wouldn't be 
> > active
> > anymore. So I'm not sure about the news, but I'd like confirmation from you 
> > about
> > expected EOL.
> 
> Linaro has nothing to do with the 3.16 kernel, so why are you confusing
> that with what was announced at that conference, which was about the 4.4
> kernel tree?

The article says that other longterm branches are only supported for 2
years - which has been your usual practice, but obviously doesn't
reflect what all stable maintainers have done.

I try to ensure that every stable branch used in a Debian release is
maintained for the lifetime of that Debian release.  That means 5-6
years after the initial release of the kernel version.  So far that has
included 2.6.32 (maintained by Willy Tarreau), 3.2 and 3.16 (maintained
by me).

In the latest release we used Linux 4.9 which currently has a stated
EOL of 2019.  But I'm prepared to take on maintenance from that point
until June 2022.  Greg, is that OK with you and should the EOL be
updated on that basis?

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, on joining IRC




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


[PATCH] cdrom: gdrom: Fix spelling of 'additional'

2018-08-18 Thread Faisal Mehmood
'additional' was misspelled as 'addional'. Fixed it. It is a coding
style change which should have no impact on runtime execution of code.

Signed-off-by: Faisal Mehmood 
---
 drivers/cdrom/gdrom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
index ae3a7537cf0f..38139e0854fb 100644
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -463,7 +463,7 @@ static int gdrom_getsense(short *bufstring)
pr_info("%s\n", sense_texts[sense_key].text);
else
pr_err("Unknown sense key: %d\n", sense_key);
-   if (bufstring) /* return addional sense data */
+   if (bufstring) /* return additional sense data */
memcpy(bufstring, [4], 2);
if (sense_key < 2)
err = 0;
-- 
2.18.0



[PATCH] hid: hid-logitech-hidpp: Fix spelling of 'length'

2018-08-18 Thread Faisal Mehmood
'length' was misspelled as 'lenth'. Fixed it. It is a coding style
change which should have no impact on runtime execution of code.

Signed-off-by: Faisal Mehmood 
---
 drivers/hid/hid-logitech-hidpp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 19cc980eebce..b89c0f5b8895 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -81,7 +81,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
  * where as most newer devices use the FAP protocol. Both protocols are
  * compatible with the underlying transport, which could be usb, Unifiying, or
  * bluetooth. The message lengths are defined by the hid vendor specific report
- * descriptor for the HIDPP_SHORT report type (total message lenth 7 bytes) and
+ * descriptor for the HIDPP_SHORT report type (total message length 7 bytes) 
and
  * the HIDPP_LONG report type (total message length 20 bytes)
  *
  * The RAP protocol uses both report types, whereas the FAP only uses 
HIDPP_LONG
-- 
2.18.0



[PATCH v2 1/1] hdac-codec runtime suspended at PM:Suspend.

2018-08-18 Thread Anshuman Gupta
Keep hdac hdmi codec to be in runtime suspended while entering to
system wide suspend. Currently hdac hdmi codec driver using its
suspend and resume operation in prepare and complete PM callbacks,
and it resumes the hd audio controller (parent of self) from runtime
suspend and blocks the direct complete for hd audio controller.

If hdac-codec is already in runtime suspend state skip its power down
sequence in prepare, power up sequence in complete phase. It enables
direct complete path for hdac-codec and hd audio controller
PCI device.

Signed-off-by: Anshuman Gupta 
---
Changes in v2
- Changed the commit message.
- Using pm_runtime_suspended instead of pm_runtime_status_suspended
  in order to handle any race condition. 
 
sound/soc/codecs/hdac_hdmi.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c
index 84f7a7a..e965338 100644
--- a/sound/soc/codecs/hdac_hdmi.c
+++ b/sound/soc/codecs/hdac_hdmi.c
@@ -1859,6 +1859,9 @@ static int hdmi_codec_prepare(struct device *dev)
struct hdac_ext_device *edev = to_hda_ext_device(dev);
struct hdac_device *hdev = >hdev;
 
+   if (pm_runtime_suspended(dev))
+   return 1;
+
pm_runtime_get_sync(>hdev.dev);
 
/*
@@ -1880,6 +1883,9 @@ static void hdmi_codec_complete(struct device *dev)
struct hdac_hdmi_priv *hdmi = hdev_to_hdmi_priv(>hdev);
struct hdac_device *hdev = >hdev;
 
+   if (pm_runtime_suspended(dev))
+   return;
+
/* Power up afg */
snd_hdac_codec_read(hdev, hdev->afg, 0, AC_VERB_SET_POWER_STATE,
AC_PWRST_D0);
-- 
2.7.4



[PATCH v2 0/1] cover-letter hdac-codec runtime suspended at PM:Suspend.

2018-08-18 Thread Anshuman Gupta
Current implementation of hdac hdmi codec driver uses its
suspend/resume operation callback in its prepare/complete callback
which has issues with hdac direct-complete, it has been reviewed earlier
that hdac hdmi codec driver requires a rework
(https://patchwork.kernel.org/patch/10276021/),
but as there is no rework with driver, it require to fix hdac direct complete
issue to leverage hdac direct complete in order to optimize its resume latency
while resuming from system wide suspend.

Anshuman Gupta (1):
  hdac-codec runtime suspended at PM:Suspend.

 sound/soc/codecs/hdac_hdmi.c | 6 ++
 1 file changed, 6 insertions(+)

-- 
2.7.4



Re: [GIT PULL] RISC-V Updates for the 4.19 Merge Window

2018-08-18 Thread Linus Torvalds
On Fri, Aug 17, 2018 at 1:28 PM Palmer Dabbelt  wrote:
>
> I remember having sent this on Wednesday, but for some reason I don't see it 
> in
> your tree or my outbox so I might be crazy.

You might indeed have been having hallucinations. I don't see any
other pull request from you in my mailbox than this one.

Google does find a posting from you saying

 "Below is the pull request I plan to submit on Wednesday morning"

on the RISC-V development google group list, so I think you just
remembered your _plan_, not your actual email ...

Anyway, I can confirm that this new pull request is now in my queue
even if I don't see any earlier ones.

   Linus


[PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h

2018-08-18 Thread Paul Burton
We have a need to override the definition of
barrier_before_unreachable() for MIPS, which means we either need to add
architecture-specific code into linux/compiler-gcc.h or we need to allow
the architecture to provide a header that can define the macro before
the generic definition. The latter seems like the better approach.

A straightforward approach to the per-arch header is to make use of
asm-generic to provide a default empty header & adjust architectures
which don't need anything specific to make use of that by adding the
header to generic-y. Unfortunately this doesn't work so well due to
commit a95b37e20db9 ("kbuild: get  out of
") which moved the inclusion of linux/compiler.h to
cflags using the -include compiler flag.

Because the -include flag is present for all C files we compile, we need
the architecture-provided header to be present before any C files are
compiled. If any C files can be compiled prior to the asm-generic header
wrappers being generated then we hit a build failure due to missing
header. Such cases do exist - one pointed out by the kbuild test robot
is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
of the archprepare target [1].

This leaves us with a few options:

  1) Use generic-y & fix any build failures we find by enforcing
 ordering such that the asm-generic target occurs before any C
 compilation, such that linux/compiler_types.h can always include
 the generated asm-generic wrapper which in turn includes the empty
 asm-generic header. This would rely on us finding all the
 problematic cases - I don't know for sure that the ia64 issue is
 the only one.

  2) Add an actual empty header to each architecture, so that we don't
 need the generated asm-generic wrapper. This seems messy.

  3) Give up & add #ifdef CONFIG_MIPS or similar to
 linux/compiler_types.h. This seems messy too.

  4) Include the arch header only when it's actually needed, removing
 the need for the asm-generic wrapper for all other architectures.

This patch allows us to use approach 4, by including an
asm/compiler_types.h header using the -include flag in the same way we
do for linux/compiler_types.h, but only if the header actually exists.

[1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html

Signed-off-by: Paul Burton 
Cc: Arnd Bergmann 
Cc: James Hogan 
Cc: Masahiro Yamada 
Cc: Ralf Baechle 
Cc: linux-a...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
Cc: linux-m...@linux-mips.org

---
Any thoughts anyone?

This isn't the prettiest it could possibly be but it's a small change &
clearly shouldn't break anything, which are good qualities for a patch
fixing build failures that we'd ideally backport as far as 4.16.

Changes in v8:
- New patch.

 scripts/Makefile.lib | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 1bb594fcfe12..4e7b41ef029b 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -151,8 +151,11 @@ __a_flags  = $(call flags,_a_flags)
 __cpp_flags = $(call flags,_cpp_flags)
 endif
 
+c_includes = $(wildcard 
$(srctree)/arch/$(SRCARCH)/include/asm/compiler_types.h)
+c_includes += $(srctree)/include/linux/compiler_types.h
+
 c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
--include $(srctree)/include/linux/compiler_types.h   \
+$(addprefix -include ,$(c_includes)) \
 $(__c_flags) $(modkern_cflags)   \
 $(basename_flags) $(modname_flags)
 
-- 
2.18.0



[PATCH v8 2/2] MIPS: Workaround GCC __builtin_unreachable reordering bug

2018-08-18 Thread Paul Burton
Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.

See this potential GCC fix for details:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html

Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):

Initmem setup node 0 [mem 0x8000-0x9fff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes


This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.

This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.

That was actually done already for other reasons by commit 173a3efd3edb
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.

Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:

arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA 
mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA 
mode

Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.

Signed-off-by: Paul Burton 
Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: Arnd Bergmann 
Cc: linux-m...@linux-mips.org

---

Changes in v8:
- Move to asm/compiler_types.h to suit patch 1.
- Commit message improvements.
- Drop James' SoB since this changed a fair bit since he added it.

Changes in v7:
- Elaborate on affected GCC versions in comment.

Changes in v6: None

Changes in v5:
- Comment & commit message tweaks.

Changes in v4: None

Changes in v3:
- Forward port to v4.17-rc and update commit message.
- Drop stable tag for now.

Changes in v2:
- Remove generic-y entry.

 arch/mips/include/asm/compiler_types.h | 39 ++
 include/linux/compiler-gcc.h   |  2 ++
 2 files changed, 41 insertions(+)
 create mode 100644 arch/mips/include/asm/compiler_types.h

diff --git a/arch/mips/include/asm/compiler_types.h 
b/arch/mips/include/asm/compiler_types.h
new file mode 100644
index ..cecd5dc48ce2
--- /dev/null
+++ b/arch/mips/include/asm/compiler_types.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_COMPILER_TYPES_H__
+#define __ASM_COMPILER_TYPES_H__
+
+/*
+ * With GCC 4.5 onwards we can use __builtin_unreachable to indicate to the
+ * compiler that a particular code path will never be hit. This allows it to be
+ * optimised out of the generated binary.
+ *
+ * Unfortunately at least GCC 4.6.3 through 7.3.0 inclusive suffer from a bug
+ * that can lead to instructions from beyond an unreachable statement being
+ * incorrectly reordered into earlier delay slots if the unreachable statement
+ * is the only content of a case in a switch statement. This can lead to
+ * seemingly random behaviour, such as invalid memory accesses from incorrectly
+ * reordered loads or 

[PATCH v8 0/2] MIPS: Override barrier_before_unreachable() to fix microMIPS

2018-08-18 Thread Paul Burton
This series overrides barrier_before_unreachable() for MIPS to add a
.insn assembler directive.

Due to the subsequent __builtin_unreachable(), the assembler can't tell
that a label on the empty inline asm is code rather than data, so any
microMIPS branches targeting it (which sadly can't be removed) raise
errors due to the mismatching ISA mode, Adding the .insn in patch 2
tells the assembler that it should be treated as code.

Applies cleanly atop v4.18.

Changes in v8 (Paul):
- Try something different... including a header that might be an
  asm-generic wrapper in linux/compiler_types.h creates build ordering
  problems for any C file which can be built before the asm-generic
  target. Patch 1 changes tact to avoid asm-generic & the ordering
  problem.
- Commit message improvements in patch 2.

Changes in v7 (Paul):
- Elaborate on affected GCC versions in patch 4.

Changes in v6 (Paul):
- Fix patch 2 to find the generated headers in $(objtree).
- Remove CC's for defunct MIPS email addresses (Matthew & Robert).
- CC linux...@lists.infradead.org.

Changes in v5 (Paul):
- Rebase atop v4.18-rc8.
- Comment & commit message tweaks.
- Add SPDX-License-Identifier to asm-generic/compiler.h.

Changes in v4 (James):
- Fix asm-generic/compiler.h include from check, compiler_types.h is
  included on the command line so linux/compiler.h may not be included
  (kbuild test robot).
- New patch 2 to fix um (kbuild test robot).

Changes in v3 (James):
- New patch 1.
- Rebase after 4.17 arch removal and update commit messages.
- Use asm/compiler.h instead of compiler-gcc.h (Arnd).
- Drop stable tag for now.

Changes in v2 (Paul):
- Add generic-y entries to arch Kbuild files. Oops!

Previous versions:
v1: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00399.html
v2: https://www.linux-mips.org/archives/linux-mips/2016-05/msg00401.html
v3: https://lkml.org/lkml/2018/4/17/228
v4: https://www.linux-mips.org/archives/linux-mips/2018-05/msg00069.html
v5: https://www.spinics.net/lists/mips/msg74408.html
v6: https://www.spinics.net/lists/mips/msg74425.html
v7: https://www.spinics.net/lists/linux-arch/msg47934.html

Older #ifdef-based attempt:
https://marc.info/?l=linux-mips=14921408274=2

Paul Burton (2):
  kbuild: Allow asm-specific compiler_types.h
  MIPS: Workaround GCC __builtin_unreachable reordering bug

 arch/mips/include/asm/compiler_types.h | 39 ++
 include/linux/compiler-gcc.h   |  2 ++
 scripts/Makefile.lib   |  5 +++-
 3 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/include/asm/compiler_types.h

-- 
2.18.0



Re: [PATCH v4 0/2] clk: qcom: Add support for RCG to register for DFS

2018-08-18 Thread Taniya Das

Hello Stephen,

I will test these changes and get back.

On 8/18/2018 7:42 AM, Stephen Boyd wrote:

Quoting Taniya Das (2018-08-10 18:53:54)

  [v4]
   * Add recalc_clk_ops to calculate the clock frequency reading the current
 perf state, also add CLK_GET_RATE_NOCACHE flag.
   * Cleanup 'goto' during mode check in 'clk_rcg2_calculate_freq'.
   * cleanup return from function 'com_cc_register_rcg_dfs'.


I want to squash this in. I have only compile tested it. Let me know
what you think.

8<---
diff --git a/drivers/clk/qcom/clk-rcg.h b/drivers/clk/qcom/clk-rcg.h
index e6300e05d5df..e5eca8a1abe4 100644
--- a/drivers/clk/qcom/clk-rcg.h
+++ b/drivers/clk/qcom/clk-rcg.h
@@ -163,6 +163,15 @@ extern const struct clk_ops clk_pixel_ops;
  extern const struct clk_ops clk_gfx3d_ops;
  extern const struct clk_ops clk_rcg2_shared_ops;
  
+struct clk_rcg_dfs_data {

+   struct clk_rcg2 *rcg;
+   struct clk_init_data *init;
+};
+
+#define DEFINE_RCG_DFS(r) \
+   { .rcg = ##_src, .init = ##_init }
+
  extern int qcom_cc_register_rcg_dfs(struct regmap *regmap,
-struct clk_rcg2 **rcgs, int num_clks);
+   const struct clk_rcg_dfs_data *rcgs,
+   size_t len);
  #endif
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 55a5b58cbb15..bbe2a1916296 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1051,48 +1051,24 @@ static unsigned long
  clk_rcg2_dfs_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
  {
struct clk_rcg2 *rcg = to_clk_rcg2(hw);
-   u32 cfg, hid_div, m = 0, n = 0, mode = 0, mask, level;
-   int num_parents, i;
-   unsigned long prate;
-
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_CMD_DFSR_OFFSET, );
-   level = (GENMASK(4, 1) & cfg) >> 1;
-
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_PERF_DFSR(level), );
-   if (rcg->mnd_width) {
-   mask = BIT(rcg->mnd_width) - 1;
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_PERF_M_DFSR(level), );
-   m &= mask;
-   regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr +
-   SE_PERF_N_DFSR(level), );
-   n =  ~n;
-   n &= mask;
-   n += m;
-   mode = cfg & CFG_MODE_MASK;
-   mode >>= CFG_MODE_SHIFT;
-   }
+   int ret;
+   u32 level;
  
-	mask = BIT(rcg->hid_width) - 1;

-   hid_div = cfg >> CFG_SRC_DIV_SHIFT;
-   hid_div &= mask;
-   cfg &= CFG_SRC_SEL_MASK;
-   cfg >>= CFG_SRC_SEL_SHIFT;
+   regmap_read(rcg->clkr.regmap,
+   rcg->cmd_rcgr + SE_CMD_DFSR_OFFSET, );
+   level &= GENMASK(4, 1);
+   level >>= 1;
  
-	num_parents = clk_hw_get_num_parents(hw);

-   for (i = 0; i < num_parents; i++) {
-   if (cfg == rcg->parent_map[i].cfg) {
-   prate = clk_hw_get_rate(
-   clk_hw_get_parent_by_index(>clkr.hw, i));
-   if (parent_rate != prate)
-   parent_rate = prate;
+   if (!rcg->freq_tbl) {
+   ret = clk_rcg2_dfs_populate_freq_table(rcg);
+   if (ret) {
+   pr_err("Failed to update DFS tables for %s\n",
+   clk_hw_get_name(hw));
+   return ret;
}
}
  
-

-   return calc_rate(parent_rate, m, n, mode, hid_div);
+   return rcg->freq_tbl[level].freq;
  }
  
  static const struct clk_ops clk_rcg2_dfs_ops = {

@@ -1102,9 +1078,11 @@ static const struct clk_ops clk_rcg2_dfs_ops = {
.recalc_rate = clk_rcg2_dfs_recalc_rate,
  };
  
-static int clk_rcg2_enable_dfs(struct clk_rcg2 *rcg, struct regmap *regmap)

+static int clk_rcg2_enable_dfs(const struct clk_rcg_dfs_data *data,
+  struct regmap *regmap)
  {
-   struct clk_init_data *init;
+   struct clk_rcg2 *rcg = data->rcg;
+   struct clk_init_data *init = data->init;
u32 val;
int ret;
  
@@ -1116,18 +1094,13 @@ static int clk_rcg2_enable_dfs(struct clk_rcg2 *rcg, struct regmap *regmap)

if (!(val & SE_CMD_DFS_EN))
return 0;
  
-	init = kzalloc(sizeof(*init), GFP_KERNEL);

-   if (!init)
-   return -ENOMEM;
-
-   init->name = rcg->clkr.hw.init->name;
-   init->flags = rcg->clkr.hw.init->flags;
-   init->parent_names = rcg->clkr.hw.init->parent_names;
-   init->num_parents = rcg->clkr.hw.init->num_parents;
-   init->flags = CLK_GET_RATE_NOCACHE;
+   /*
+* Rate changes with consumer writing a register in
+* their own I/O region
+*/
+   init->flags |= CLK_GET_RATE_NOCACHE;
init->ops = _rcg2_dfs_ops;
  
-	rcg->clkr.hw.init = init;


Re: [GIT PULL] Staging/IIO driver patches for 4.19-rc1

2018-08-18 Thread Linus Torvalds
On Sat, Aug 18, 2018 at 8:57 AM Greg KH  wrote:
>
> Note, you will have a merge problem with a device tree IIO file and the
> MAINTAINERS file, both resolutions are easy, just take all changed.

Heh, no. In neither case should I take all changes: the IIO was
"delete both sides"), and in the MAINTAINERS file, which was delete
one side, add another, somebody can't even sort stuff alphabetically.

> There will be a skein file merge issue as well, but that file got
> deleted so just drop that.

Yes indeed.

   Linus


Re: [PATCH v3 7/9] iio: tsl2772: add support for avago,apds9930

2018-08-18 Thread Jonathan Cameron
On Fri, 3 Aug 2018 22:53:36 +0100
Jonathan Cameron  wrote:

> On Thu,  2 Aug 2018 20:18:58 -0400
> Brian Masney  wrote:
> 
> > The Avago APDS9930 has the same register set as the TAOS/AMS TSL2772 so
> > this patch adds the correct bindings and the appropriate LUX table
> > values derived from the values in the datasheet. Driver was tested on a
> > LG Nexus 5 (hammerhead) phone.
> > 
> > avago,apds9930 datasheet:
> > https://www.mouser.com/datasheet/2/678/avago_AV02-3190EN_DS_APDS-9930_2014-03-25[1]-1217273.pdf
> > 
> > tsl2772 datasheet:
> > https://ams.com/eng/content/download/291503/1066377/file/TSL2772_DS000181_2-00.pdf
> > 
> > Signed-off-by: Brian Masney   
> Glad you noticed they were the same.  will apply once precursors are in.
> 
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.

Thanks,

Jonathan

> Thanks,
> 
> Jonathan
> 
> > ---
> >  drivers/iio/light/tsl2772.c | 18 --
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > index 4a11bf77a4d0..83cece921843 100644
> > --- a/drivers/iio/light/tsl2772.c
> > +++ b/drivers/iio/light/tsl2772.c
> > @@ -124,7 +124,8 @@ enum {
> > tsl2672,
> > tmd2672,
> > tsl2772,
> > -   tmd2772
> > +   tmd2772,
> > +   apds9930,
> >  };
> >  
> >  enum {
> > @@ -213,6 +214,12 @@ static const struct tsl2772_lux 
> > tmd2x72_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > { 0,  0 },
> >  };
> >  
> > +static const struct tsl2772_lux 
> > apds9930_lux_table[TSL2772_DEF_LUX_TABLE_SZ] = {
> > +   { 52000,  96824 },
> > +   { 38792,  67132 },
> > +   { 0,  0 },
> > +};
> > +
> >  static const struct tsl2772_lux *tsl2772_default_lux_table_group[] = {
> > [tsl2571] = tsl2x71_lux_table,
> > [tsl2671] = tsl2x71_lux_table,
> > @@ -224,6 +231,7 @@ static const struct tsl2772_lux 
> > *tsl2772_default_lux_table_group[] = {
> > [tmd2672] = tmd2x72_lux_table,
> > [tsl2772] = tsl2x72_lux_table,
> > [tmd2772] = tmd2x72_lux_table,
> > +   [apds9930] = apds9930_lux_table,
> >  };
> >  
> >  static const struct tsl2772_settings tsl2772_default_settings = {
> > @@ -274,6 +282,7 @@ static const int tsl2772_int_time_avail[][6] = {
> > [tmd2672] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tsl2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > [tmd2772] = { 0, 2730, 0, 2730, 0, 699000 },
> > +   [apds9930] = { 0, 2730, 0, 2730, 0, 699000 },
> >  };
> >  
> >  static int tsl2772_int_calibscale_avail[] = { 1, 8, 16, 120 };
> > @@ -299,7 +308,8 @@ static const u8 device_channel_config[] = {
> > [tsl2672] = PRX2,
> > [tmd2672] = PRX2,
> > [tsl2772] = ALSPRX2,
> > -   [tmd2772] = ALSPRX2
> > +   [tmd2772] = ALSPRX2,
> > +   [apds9930] = ALSPRX2,
> >  };
> >  
> >  static int tsl2772_read_status(struct tsl2772_chip *chip)
> > @@ -513,6 +523,7 @@ static int tsl2772_get_prox(struct iio_dev *indio_dev)
> > case tmd2672:
> > case tsl2772:
> > case tmd2772:
> > +   case apds9930:
> > if (!(ret & TSL2772_STA_PRX_VALID)) {
> > ret = -EINVAL;
> > goto prox_poll_err;
> > @@ -1393,6 +1404,7 @@ static int tsl2772_device_id_verif(int id, int target)
> > case tmd2672:
> > case tsl2772:
> > case tmd2772:
> > +   case apds9930:
> > return (id & 0xf0) == SWORDFISH_ID;
> > }
> >  
> > @@ -1932,6 +1944,7 @@ static const struct i2c_device_id tsl2772_idtable[] = 
> > {
> > { "tmd2672", tmd2672 },
> > { "tsl2772", tsl2772 },
> > { "tmd2772", tmd2772 },
> > +   { "apds9930", apds9930},
> > {}
> >  };
> >  
> > @@ -1948,6 +1961,7 @@ static const struct of_device_id tsl2772_of_match[] = 
> > {
> > { .compatible = "amstaos,tmd2672" },
> > { .compatible = "amstaos,tsl2772" },
> > { .compatible = "amstaos,tmd2772" },
> > +   { .compatible = "avago,apds9930" },
> > {}
> >  };
> >  MODULE_DEVICE_TABLE(of, tsl2772_of_match);  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



Re: [PATCH v3 9/9] ARM: dts: qcom: msm8974-hammerhead: add device tree bindings for ALS / proximity

2018-08-18 Thread Jonathan Cameron
On Thu,  2 Aug 2018 20:19:00 -0400
Brian Masney  wrote:

> This patch adds device tree bindings for the tsl2772 ALS / proximity
> sensor for the LG Nexus 5 (hammerhead) phone.
> 
> Signed-off-by: Brian Masney 
> Signed-off-by: Jonathan Marek 
Acked-by: Jonathan Cameron 

The precursors are working their way through the iio tree, but
it will be the next merge window before they go upstream.

Thanks,

Jonathan

> ---
>  .../qcom-msm8974-lge-nexus5-hammerhead.dts| 27 +++
>  arch/arm/boot/dts/qcom-msm8974.dtsi   | 11 
>  2 files changed, 38 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts 
> b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> index 928affae1885..ed8f064d0895 100644
> --- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> +++ b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> @@ -242,6 +242,15 @@
>   };
>   };
>  
> + i2c3_pins: i2c3 {
> + mux {
> + pins = "gpio10", "gpio11";
> + function = "blsp_i2c3";
> + drive-strength = <2>;
> + bias-disable;
> + };
> + };
> +
>   i2c12_pins: i2c12 {
>   mux {
>   pins = "gpio87", "gpio88";
> @@ -333,6 +342,24 @@
>   };
>   };
>   };
> +
> + i2c@f9925000 {
> + status = "ok";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + clock-frequency = <10>;
> + qcom,src-freq = <5000>;
> +
> + avago_apds993@39 {
> + compatible = "avago,apds9930";
> + reg = <0x39>;
> + interrupts-extended = < 61 
> IRQ_TYPE_EDGE_FALLING>;
> + vdd-supply = <_l17>;
> + vddio-supply = <_lvs1>;
> + led-max-microamp = <10>;
> + amstaos,proximity-diodes = <0>;
> + };
> + };
>  };
>  
>  _bus {
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index cebb6ae9143a..6dcf2bee66fb 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -713,6 +713,17 @@
>   #size-cells = <0>;
>   };
>  
> + blsp_i2c3: i2c@f9925000 {
> + status = "disabled";
> + compatible = "qcom,i2c-qup-v2.1.1";
> + reg = <0xf9925000 0x1000>;
> + interrupts = <0 97 IRQ_TYPE_NONE>;
> + clocks = < GCC_BLSP1_QUP3_I2C_APPS_CLK>, < 
> GCC_BLSP1_AHB_CLK>;
> + clock-names = "core", "iface";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
>   blsp_i2c8: i2c@f9964000 {
>   status = "disabled";
>   compatible = "qcom,i2c-qup-v2.1.1";



Re: [PATCH v3 8/9] dt-bindings: iio: tsl2772: add binding for avago,apds9930

2018-08-18 Thread Jonathan Cameron
On Tue, 7 Aug 2018 11:21:01 -0600
Rob Herring  wrote:

> On Thu, Aug 02, 2018 at 08:18:59PM -0400, Brian Masney wrote:
> > This patch adds avago,apds9930 to the tsl2772 bindings.
> > 
> > Signed-off-by: Brian Masney 
> > ---
> >  Documentation/devicetree/bindings/iio/light/tsl2772.txt | 1 +
> >  1 file changed, 1 insertion(+)  
> 
> Reviewed-by: Rob Herring 

Applied.  Thanks


Re: [PATCH v3 3/9] iio: tsl2772: add support for reading proximity led settings from device tree

2018-08-18 Thread Jonathan Cameron
On Thu,  2 Aug 2018 20:18:54 -0400
Brian Masney  wrote:

> This patch adds support for optionally reading the proximity led diode
> and current settings from device tree. This was tested using a LG
> Nexus 5 (hammerhead) which requires a different diode than the driver
> default for the IR LED.
> 
> Signed-off-by: Brian Masney 

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with them.

thanks,

Jonathan

> ---
>  drivers/iio/light/tsl2772.c | 81 +
>  1 file changed, 81 insertions(+)
> 
> diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> index df5b2a0da96c..ae00edf0d87e 100644
> --- a/drivers/iio/light/tsl2772.c
> +++ b/drivers/iio/light/tsl2772.c
> @@ -107,6 +107,8 @@
>  #define TSL2772_ALS_GAIN_TRIM_MIN250
>  #define TSL2772_ALS_GAIN_TRIM_MAX4000
>  
> +#define TSL2772_MAX_PROX_LEDS2
> +
>  /* Device family members */
>  enum {
>   tsl2571,
> @@ -141,6 +143,14 @@ struct tsl2772_chip_info {
>   const struct iio_info *info;
>  };
>  
> +static const int tsl2772_led_currents[][2] = {
> + { 10, TSL2772_100_mA },
> + {  5, TSL2772_50_mA },
> + {  25000, TSL2772_25_mA },
> + {  13000, TSL2772_13_mA },
> + {  0, 0 }
> +};
> +
>  struct tsl2772_chip {
>   kernel_ulong_t id;
>   struct mutex prox_mutex;
> @@ -515,6 +525,75 @@ static int tsl2772_get_prox(struct iio_dev *indio_dev)
>   return ret;
>  }
>  
> +static int tsl2772_read_prox_led_current(struct tsl2772_chip *chip)
> +{
> + struct device_node *of_node = chip->client->dev.of_node;
> + int ret, tmp, i;
> +
> + ret = of_property_read_u32(of_node, "led-max-microamp", );
> + if (ret < 0)
> + return ret;
> +
> + for (i = 0; tsl2772_led_currents[i][0] != 0; i++) {
> + if (tmp == tsl2772_led_currents[i][0]) {
> + chip->settings.prox_power = tsl2772_led_currents[i][1];
> + return 0;
> + }
> + }
> +
> + dev_err(>client->dev, "Invalid value %d for led-max-microamp\n",
> + tmp);
> +
> + return -EINVAL;
> +
> +}
> +
> +static int tsl2772_read_prox_diodes(struct tsl2772_chip *chip)
> +{
> + struct device_node *of_node = chip->client->dev.of_node;
> + int i, ret, num_leds, prox_diode_mask;
> + u32 leds[TSL2772_MAX_PROX_LEDS];
> +
> + ret = of_property_count_u32_elems(of_node, "amstaos,proximity-diodes");
> + if (ret < 0)
> + return ret;
> +
> + num_leds = ret;
> + if (num_leds > TSL2772_MAX_PROX_LEDS)
> + num_leds = TSL2772_MAX_PROX_LEDS;
> +
> + ret = of_property_read_u32_array(of_node, "amstaos,proximity-diodes",
> +  leds, num_leds);
> + if (ret < 0) {
> + dev_err(>client->dev,
> + "Invalid value for amstaos,proximity-diodes: %d.\n",
> + ret);
> + return ret;
> + }
> +
> + prox_diode_mask = 0;
> + for (i = 0; i < num_leds; i++) {
> + if (leds[i] == 0)
> + prox_diode_mask |= TSL2772_DIODE0;
> + else if (leds[i] == 1)
> + prox_diode_mask |= TSL2772_DIODE1;
> + else {
> + dev_err(>client->dev,
> + "Invalid value %d in 
> amstaos,proximity-diodes.\n",
> + leds[i]);
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void tsl2772_parse_dt(struct tsl2772_chip *chip)
> +{
> + tsl2772_read_prox_led_current(chip);
> + tsl2772_read_prox_diodes(chip);
> +}
> +
>  /**
>   * tsl2772_defaults() - Populates the device nominal operating parameters
>   *  with those provided by a 'platform' data struct or
> @@ -541,6 +620,8 @@ static void tsl2772_defaults(struct tsl2772_chip *chip)
>   memcpy(chip->tsl2772_device_lux,
>  tsl2772_default_lux_table_group[chip->id],
>  TSL2772_DEFAULT_TABLE_BYTES);
> +
> + tsl2772_parse_dt(chip);
>  }
>  
>  /**



Re: [PATCH v3 6/9] dt-bindings: iio: tsl2772: add bindings for regulator framework

2018-08-18 Thread Jonathan Cameron
On Tue, 7 Aug 2018 11:20:28 -0600
Rob Herring  wrote:

> On Fri, Aug 03, 2018 at 10:51:23PM +0100, Jonathan Cameron wrote:
> > On Thu,  2 Aug 2018 20:18:57 -0400
> > Brian Masney  wrote:
> >   
> > > This patch adds device tree bindings to the tsl2772 driver for the
> > > regulator framework.
> > > 
> > > Signed-off-by: Brian Masney   
> > I suspect Rob will tell you this should really have been in the same
> > patch as the earlier bindings.   There is no need for us to wait
> > for the driver support as the binding describes what is there, not
> > what we do with it.  
> 
> Yep.
> 
> > 
> > Otherwise it's fine and if nothing else comes up I can merge them ;)

I merged them.

Jonathan
> > 
> > Jonathan
> >   
> > > ---
> > >  Documentation/devicetree/bindings/iio/light/tsl2772.txt | 4 
> > >  1 file changed, 4 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/iio/light/tsl2772.txt 
> > > b/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > index 6f33169344f2..4e7d98627cbf 100644
> > > --- a/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > +++ b/Documentation/devicetree/bindings/iio/light/tsl2772.txt
> > > @@ -21,6 +21,8 @@ Optional properties:
> > > are the only valid values.
> > >- led-max-microamp - current for the proximity LED. Must be 10, 
> > > 5,
> > > 25000, or 13000.
> > > +  - vdd-supply: phandle to the regulator that provides power to the 
> > > sensor.
> > > +  - vddio-supply: phandle to the regulator that provides power to the 
> > > bus.
> > >- interrupts: the sole interrupt generated by the device
> > >  
> > >Refer to interrupt-controller/interrupts.txt for generic interrupt 
> > > client
> > > @@ -32,6 +34,8 @@ tsl2772@39 {
> > >   compatible = "amstaos,tsl2772";
> > >   reg = <0x39>;
> > >   interrupts-extended = < 61 IRQ_TYPE_EDGE_FALLING>;
> > > + vdd-supply = <_l17>;
> > > + vddio-supply = <_lvs1>;
> > >   amstaos,proximity-diodes = <0>;
> > >   led-max-microamp = <10>;
> > >  };  
> >   



Re: [PATCH v3 4/9] dt-bindings: iio: tsl2772: add new bindings

2018-08-18 Thread Jonathan Cameron
On Tue, 7 Aug 2018 10:54:26 -0600
Rob Herring  wrote:

> On Fri, Aug 03, 2018 at 10:48:38PM +0100, Jonathan Cameron wrote:
> > On Thu,  2 Aug 2018 20:18:55 -0400
> > Brian Masney  wrote:
> >   
> > > This patch adds the new properties amstaos,proximity-diodes and
> > > led-max-microamp to the tsl2772 driver. This patch also removes the
> > > driver from the trivial-devices.txt.
> > > 
> > > Signed-off-by: Brian Masney 
> > > ---  
> > This and the implementation look fine to me, but I'll leave them for
> > now to give Rob time to take a look if he wants to.
> > 
> > Thanks,
> > 
> > Jonathan
> >   
> > > I got a Reviewed-by: Rob Herring  on my last series but
> > > didn't include it due to the new file tsl2772.txt in this patch. Device
> > > tree bindings need to be complete.
> > > 
> > >  .../devicetree/bindings/iio/light/tsl2772.txt | 37 +++
> > >  .../devicetree/bindings/trivial-devices.txt   | 10 -
> > >  2 files changed, 37 insertions(+), 10 deletions(-)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/iio/light/tsl2772.txt  
> 
> Reviewed-by: Rob Herring 

Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to ignore it.

I'll apply the other dt bits to this as fixups.

Jonathan

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



Re: [PATCH v3 1/3] iio: adc: add support for mcp3911

2018-08-18 Thread Jonathan Cameron
On Sat, 4 Aug 2018 08:55:06 +0200
Marcus Folkesson  wrote:

> Hi Andy and Jonathan,
> 
> 
> On Fri, Aug 03, 2018 at 11:09:22PM +0100, Jonathan Cameron wrote:
> > On Thu, 2 Aug 2018 22:52:00 +0300
> > Andy Shevchenko  wrote:
> >   
> > > On Thu, Aug 2, 2018 at 10:15 PM, Marcus Folkesson
> > >  wrote:  
> > > > MCP3911 is a dual channel Analog Front End (AFE) containing two
> > > > synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
> > > >
> > > > Signed-off-by: Marcus Folkesson 
> > >   
> > > > Signed-off-by: Kent Gustavsson 
> > > 
> > > What is this? Why it's here (presense and location in the message)?  
> > To clarify... If Kent wrote the patch and you are simply acting
> > as gatekeeper / upstreamer you should set the mail to be from Kent
> > and put your own Signed-off after his to basically act as a submaintainer
> > certifying you believe his sign off and all that entails.
> > 
> > If it is a bit of a joint effort then that's fine but for copyright
> > purposes there should be some indication of the split.  
> 
> First, thank you Andy for noticing.
> 
> I actually intended to use Co-Developed-by (a pretty new tag)
> in combination with Signed-off-by.
> But the tag must have disappeared in some preparation stage..
> 
> From Documentation/process/submitting-patches.rst ::
> 
>   A Co-Developed-by: states that the patch was also created by another 
> developer
>   along with the original author.  This is useful at times when multiple 
> people
>   work on a single patch.  Note, this person also needs to have a 
> Signed-off-by:
>   line in the patch as well.
> 
> I will switch order and add the Co-Developed-by-tag.
> Is this correct?
> 
> Co-Developed-by: Kent Gustavsson
> Signed-off-by: Kent Gustavsson   
> Signed-off-by: Marcus Folkesson   
> 
> > 
> >   
> > >   
> > > > + * Copyright (C) 2018 Kent Gustavsson 
> > >   
> > > > + *
> > > 
> > > Redundant.
> > >   
> > > > +static int mcp3911_read(struct mcp3911 *adc, u8 reg, u32 *val, u8 len)
> > > > +{
> > > > +   int ret;
> > > > +
> > > > +   reg = MCP3911_REG_READ(reg, adc->dev_addr);
> > > > +   ret = spi_write_then_read(adc->spi, , 1, val, len);
> > > > +   if (ret < 0)
> > > > +   return ret;
> > > > +
> > > > +   be32_to_cpus(val);
> > > > +   *val >>= ((4 - len) * 8);
> > > > +   dev_dbg(>spi->dev, "reading 0x%x from register 0x%x\n", 
> > > > *val,
> > > > +   reg>>1);
> > > > +   return ret;
> > > > +}
> > > > +
> > > > +static int mcp3911_write(struct mcp3911 *adc, u8 reg, u32 val, u8 len)
> > > > +{
> > > > +   dev_dbg(>spi->dev, "writing 0x%x to register 0x%x\n", val, 
> > > > reg);
> > > > +
> > > > +   val <<= (3 - len) * 8;
> > > > +   cpu_to_be32s();
> > > > +   val |= MCP3911_REG_WRITE(reg, adc->dev_addr);
> > > > +
> > > > +   return spi_write(adc->spi, , len + 1);
> > > > +}
> > > 
> > > Can't you use REGMAP_SPI ?  
> > My instinct is not really. The magic device-addr doesn't help.
> > You could work around it but it's not that nice and you'd have
> > to create the regmap mapping on the fly or carry static ones
> > for each value of htat.
> > 
> > 
> >   
> > >   
> > > > +   of_property_read_u32(of_node, "device-addr", >dev_addr);
> > > > +   if (adc->dev_addr > 3) {
> > > > +   dev_err(>spi->dev,
> > > > +   "invalid device address (%i). Must be 
> > > > in range 0-3.\n",
> > > > +   adc->dev_addr);
> > > > +   return -EINVAL;
> > > > +   }
> > > > +   dev_dbg(>spi->dev, "use device address %i\n", 
> > > > adc->dev_addr);
> > > 
> > > Isn't what we called CS (chip select)?  
> > Nope. We went around this in an earlier revision. It's an address 
> > transmitted
> > in the control byte to allow you to 'share' a chip select line between 
> > multiple
> > chips (crazy but true).
> >   
> > >   
> > > > +   if (IS_ERR(adc->vref)) {
> > >   
> > > > +
> > > 
> > > Redundant.
> > >   
> > > > +   if (adc->clki)
> > > 
> > > Seems to be redundant if clock is optional (it should be NULL and API
> > > is NULL-aware).
> > >   
> > > > +   clk_disable_unprepare(adc->clki);
> > >   
> > > > +   if (adc->clki)
> > > > +   clk_disable_unprepare(adc->clki);
> > > 
> > > Ditto.
> > >   
> > > > +#if defined(CONFIG_OF)
> > > 
> > > This prevents playing with the device on ACPI enabled platforms.  
> 
> I will remove the defined(CONFIG_OF) and not use the of_match_ptr()
> macro. 
> 
> > Yeah, that trickery is still little known (and I forget about it from
> > time to time).
> > 
> > The upshot for those who have missed this is you can use a magic
> > acpi device to instantiate based on device tree bindings :)
> > 
> > So we need to strip all this 'obvious' protection stuff out of drivers.  
> 
> Jonathan,
> Do you want me to do the same changes for 

Re: linux-next: Signed-off-by missing for commit in the h8300 tree

2018-08-18 Thread Yoshinori Sato
On Sat, 18 Aug 2018 23:30:05 +0900,
Stephen Rothwell wrote:
> 
> [1  ]
> Hi Yoshinori,
> 
> Commits
> 
>   785b0958b55d ("h8300: gcc-8.1 fix")
>   8eabc2d5fae0 ("h8300: Add missing output register.")
> 
> are missing a Signed-off-by from their authors and committers.
> 
> Commit
> 
>   85f866b60ba7 ("h8300: switch to NO_BOOTMEM")
> 
> is missing a Signed-off-by from its committer.

OK. Fixed it.

> -- 
> Cheers,
> Stephen Rothwell
> [2 OpenPGP digital signature ]
> No public key for 015042F34957D06C created at 2018-08-18T23:30:05+0900 using 
> RSA

-- 
Yosinori Sato


Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0

2018-08-18 Thread Joe Perches
On Sat, 2018-08-18 at 19:21 +0300, Sergei Shtylyov wrote:
> On 08/18/2018 07:15 PM, Joe Perches wrote:
> > > > We should use NULL to compare with pointer-typed value rather than
> > > > 0. The issue is detected with the help of Coccinelle.
> > > 
> > >Your description stopped to match the patch in v2.
> > >Actually, this X ==  NULL to !x preference is largely spocific to 
> > > netdev...
> > > Although, IDE maintainer is the same now person. :-)  
[]
> > > > diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
[]
> > > > @@ -1682,7 +1682,7 @@ static int pmac_ide_init_dma(ide_hwif_t *hwif, 
> > > > const struct ide_port_info *d)
> > > > /* We won't need pci_dev if we switch to generic consistent
> > > >  * DMA routines ...
> > > >  */
> > > > -   if (dev == NULL || pmif->dma_regs == 0)
> > > > +   if (!dev || !pmif->dma_regs)
> > > > return -ENODEV;
> > > > /*
> > > >  * Allocate space for the DBDMA commands.
[]
> > Perhaps discourage trivial changes to this old subsystem.
> > 
> > checkpatch could bleat something if a patch was submitted for ide
> > if the IDE MAINTAINERS entry was marked obsolete.
> 
>Note that the IDE fixes are still OK...

The checkpatch obsolete message is

 is marked as 'obsolete' in the MAINTAINERS hierarchy.  No 
unnecessary modifications please.

---
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e9336962d0f2..3c4992cf5249 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -6933,7 +6933,7 @@ M:"David S. Miller" 
> >  L: linux-...@vger.kernel.org
> >  Q: http://patchwork.ozlabs.org/project/linux-ide/list/
> >  T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git
> > -S: Maintained
> > +S: Maintained / Obsolete (prefer LIBATA)
> 
>What about "S: Odd Fixes"? Perhaps it better reflects the reality...

That'd be up to David.



WARNING in __fsnotify_recalc_mask

2018-08-18 Thread syzbot

Hello,

syzbot found the following crash on:

HEAD commit:1f7a4c73a739 Merge tag '9p-for-4.19-2' of git://github.com..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10cccef240
kernel config:  https://syzkaller.appspot.com/x/.config?x=68e80edb3c9718c5
dashboard link: https://syzkaller.appspot.com/bug?extid=c34692a51b9a6ca93540
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=11c12e8640

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c34692a51b9a6ca93...@syzkaller.appspotmail.com

IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
WARNING: CPU: 1 PID: 12015 at fs/notify/mark.c:139  
__fsnotify_recalc_mask+0x2d7/0x350 fs/notify/mark.c:139

Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 12015 Comm: syz-executor0 Not tainted 4.18.0+ #195
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
 panic+0x238/0x4e7 kernel/panic.c:184
 __warn.cold.8+0x163/0x1ba kernel/panic.c:536
 report_bug+0x252/0x2d0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:178 [inline]
 do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993
RIP: 0010:__fsnotify_recalc_mask+0x2d7/0x350 fs/notify/mark.c:139
Code: 90 00 00 00 48 83 c4 68 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 eb 2d a2  
ff 49 83 ec 04 eb 82 e8 e0 2d a2 ff 0f 0b e8 d9 2d a2 ff <0f> 0b eb a5 e8  
60 24 e1 ff e9 11 ff ff ff 48 89 df e8 f3 24 e1 ff

RSP: 0018:8801b509f5c8 EFLAGS: 00010293
RAX: 8801b2c0a180 RBX: 0002 RCX: 81dabc96
RDX:  RSI: 81dabd67 RDI: 0005
RBP: 8801b509f658 R08: 8801b2c0a180 R09: ed00398cb796
R10: ed00398cb796 R11: 8801cc65bcb3 R12: dc00
R13: 8801cc65bcb0 R14:  R15: 
 fsnotify_put_mark+0x523/0xab0 fs/notify/mark.c:240
 fsnotify_destroy_marks+0x2d1/0x5c0 fs/notify/mark.c:741
 fsnotify_clear_marks_by_inode fs/notify/fsnotify.h:39 [inline]
 __fsnotify_inode_delete+0x19/0x20 fs/notify/fsnotify.c:35
 fsnotify_inoderemove include/linux/fsnotify.h:136 [inline]
 dentry_unlink_inode+0x48b/0x5e0 fs/dcache.c:370
 __dentry_kill+0x44c/0x7a0 fs/dcache.c:566
 dentry_kill+0xc9/0x5a0 fs/dcache.c:685
 dput.part.26+0x66b/0x7a0 fs/dcache.c:846
 dput+0x15/0x20 fs/dcache.c:828
 __fput+0x4c2/0x860 fs/file_table.c:264
 fput+0x15/0x20 fs/file_table.c:282
 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:193 [inline]
 exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
 do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7fcfa3e50c78 EFLAGS: 0246 ORIG_RAX: 0021
RAX: 000a RBX: 7fcfa3e516d4 RCX: 00457089
RDX:  RSI: 000a RDI: 0008
RBP: 009300a0 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 004cb6d0 R14: 004c31f3 R15: 
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.

syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches


Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0

2018-08-18 Thread Sergei Shtylyov
On 08/18/2018 06:53 PM, Sergei Shtylyov wrote:

>> We should use NULL to compare with pointer-typed value rather than
>> 0. The issue is detected with the help of Coccinelle.
> 
>Your description stopped to match the patch in v2.

  And your subject as well...

>Actually, this X ==  NULL to !x preference is largely spocific to netdev...

   Specific, of course. :-)

> Although, IDE maintainer is the same now person. :-)  

  "The same person now" I wanted to type. :-)

>  
>> Signed-off-by: zhong jiang 
[...]

MBR, Sergei


Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0

2018-08-18 Thread Sergei Shtylyov
On 08/18/2018 07:15 PM, Joe Perches wrote:

>>> We should use NULL to compare with pointer-typed value rather than
>>> 0. The issue is detected with the help of Coccinelle.
>>
>>Your description stopped to match the patch in v2.
>>Actually, this X ==  NULL to !x preference is largely spocific to 
>> netdev...
>> Although, IDE maintainer is the same now person. :-)  
>>  
>>> Signed-off-by: zhong jiang 
>>> ---
>>>  drivers/ide/pmac.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
>>> index c5b902b..ca36a97 100644
>>> --- a/drivers/ide/pmac.c
>>> +++ b/drivers/ide/pmac.c
>>> @@ -1682,7 +1682,7 @@ static int pmac_ide_init_dma(ide_hwif_t *hwif, const 
>>> struct ide_port_info *d)
>>> /* We won't need pci_dev if we switch to generic consistent
>>>  * DMA routines ...
>>>  */
>>> -   if (dev == NULL || pmif->dma_regs == 0)
>>> +   if (!dev || !pmif->dma_regs)
>>> return -ENODEV;
>>> /*
>>>  * Allocate space for the DBDMA commands.
>>
>> MBR, Sergei
> 
> Perhaps discourage trivial changes to this old subsystem.
> 
> checkpatch could bleat something if a patch was submitted for ide
> if the IDE MAINTAINERS entry was marked obsolete.

   Note that the IDE fixes are still OK...

> ---
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e9336962d0f2..3c4992cf5249 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6933,7 +6933,7 @@ M:  "David S. Miller" 
>  L:   linux-...@vger.kernel.org
>  Q:   http://patchwork.ozlabs.org/project/linux-ide/list/
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git
> -S:   Maintained
> +S:   Maintained / Obsolete (prefer LIBATA)

   What about "S: Odd Fixes"? Perhaps it better reflects the reality...

>  F:   Documentation/ide/
>  F:   drivers/ide/
>  F:   include/linux/ide.h

MBR, Sergei


Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0

2018-08-18 Thread Joe Perches
On Sat, 2018-08-18 at 18:53 +0300, Sergei Shtylyov wrote:
> On 08/18/2018 09:16 AM, zhong jiang wrote:
> 
> > We should use NULL to compare with pointer-typed value rather than
> > 0. The issue is detected with the help of Coccinelle.
> 
>Your description stopped to match the patch in v2.
>Actually, this X ==  NULL to !x preference is largely spocific to netdev...
> Although, IDE maintainer is the same now person. :-)  
>  
> > Signed-off-by: zhong jiang 
> > ---
> >  drivers/ide/pmac.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
> > index c5b902b..ca36a97 100644
> > --- a/drivers/ide/pmac.c
> > +++ b/drivers/ide/pmac.c
> > @@ -1682,7 +1682,7 @@ static int pmac_ide_init_dma(ide_hwif_t *hwif, const 
> > struct ide_port_info *d)
> > /* We won't need pci_dev if we switch to generic consistent
> >  * DMA routines ...
> >  */
> > -   if (dev == NULL || pmif->dma_regs == 0)
> > +   if (!dev || !pmif->dma_regs)
> > return -ENODEV;
> > /*
> >  * Allocate space for the DBDMA commands.
> 
> MBR, Sergei

Perhaps discourage trivial changes to this old subsystem.

checkpatch could bleat something if a patch was submitted for ide
if the IDE MAINTAINERS entry was marked obsolete.
---
diff --git a/MAINTAINERS b/MAINTAINERS
index e9336962d0f2..3c4992cf5249 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6933,7 +6933,7 @@ M:"David S. Miller" 
 L: linux-...@vger.kernel.org
 Q: http://patchwork.ozlabs.org/project/linux-ide/list/
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git
-S: Maintained
+S: Maintained / Obsolete (prefer LIBATA)
 F: Documentation/ide/
 F: drivers/ide/
 F: include/linux/ide.h



[PATCH v1 1/2] clk: tegra: Don't enable already enabled PLLs

2018-08-18 Thread Dmitry Osipenko
Initially Common Clock Framework isn't aware of the clock-enable status,
this results in enabling of clocks that were enabled by bootloader. This
is not a big deal for a regular clock-gates, but for PLL's it may have
some unpleasant consequences. Thus re-enabling PLLX (the main CPU parent
clock) may result in extra long period of PLL re-locking.

Signed-off-by: Dmitry Osipenko 
---
 drivers/clk/tegra/clk-pll.c | 50 +++--
 1 file changed, 37 insertions(+), 13 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 830d1c87fa7c..ddb431247f08 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -444,6 +444,9 @@ static int clk_pll_enable(struct clk_hw *hw)
unsigned long flags = 0;
int ret;
 
+   if (clk_pll_is_enabled(hw))
+   return 0;
+
if (pll->lock)
spin_lock_irqsave(pll->lock, flags);
 
@@ -939,11 +942,16 @@ static int clk_plle_training(struct tegra_clk_pll *pll)
 static int clk_plle_enable(struct clk_hw *hw)
 {
struct tegra_clk_pll *pll = to_clk_pll(hw);
-   unsigned long input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
struct tegra_clk_pll_freq_table sel;
+   unsigned long input_rate;
u32 val;
int err;
 
+   if (clk_pll_is_enabled(hw))
+   return 0;
+
+   input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
+
if (_get_table_rate(hw, , pll->params->fixed_rate, input_rate))
return -EINVAL;
 
@@ -1354,6 +1362,9 @@ static int clk_pllc_enable(struct clk_hw *hw)
int ret;
unsigned long flags = 0;
 
+   if (clk_pll_is_enabled(hw))
+   return 0;
+
if (pll->lock)
spin_lock_irqsave(pll->lock, flags);
 
@@ -1566,7 +1577,12 @@ static int clk_plle_tegra114_enable(struct clk_hw *hw)
u32 val;
int ret;
unsigned long flags = 0;
-   unsigned long input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
+   unsigned long input_rate;
+
+   if (clk_pll_is_enabled(hw))
+   return 0;
+
+   input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
 
if (_get_table_rate(hw, , pll->params->fixed_rate, input_rate))
return -EINVAL;
@@ -1703,6 +1719,9 @@ static int clk_pllu_tegra114_enable(struct clk_hw *hw)
return -EINVAL;
}
 
+   if (clk_pll_is_enabled(hw))
+   return 0;
+
input_rate = clk_hw_get_rate(__clk_get_hw(osc));
 
if (pll->lock)
@@ -2378,6 +2397,16 @@ struct clk *tegra_clk_register_pllre_tegra210(const char 
*name,
return clk;
 }
 
+static int clk_plle_tegra210_is_enabled(struct clk_hw *hw)
+{
+   struct tegra_clk_pll *pll = to_clk_pll(hw);
+   u32 val;
+
+   val = pll_readl_base(pll);
+
+   return val & PLLE_BASE_ENABLE ? 1 : 0;
+}
+
 static int clk_plle_tegra210_enable(struct clk_hw *hw)
 {
struct tegra_clk_pll *pll = to_clk_pll(hw);
@@ -2385,7 +2414,12 @@ static int clk_plle_tegra210_enable(struct clk_hw *hw)
u32 val;
int ret = 0;
unsigned long flags = 0;
-   unsigned long input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
+   unsigned long input_rate;
+
+   if (clk_plle_tegra210_is_enabled(hw))
+   return 0;
+
+   input_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
 
if (_get_table_rate(hw, , pll->params->fixed_rate, input_rate))
return -EINVAL;
@@ -2496,16 +2530,6 @@ static void clk_plle_tegra210_disable(struct clk_hw *hw)
spin_unlock_irqrestore(pll->lock, flags);
 }
 
-static int clk_plle_tegra210_is_enabled(struct clk_hw *hw)
-{
-   struct tegra_clk_pll *pll = to_clk_pll(hw);
-   u32 val;
-
-   val = pll_readl_base(pll);
-
-   return val & PLLE_BASE_ENABLE ? 1 : 0;
-}
-
 static const struct clk_ops tegra_clk_plle_tegra210_ops = {
.is_enabled =  clk_plle_tegra210_is_enabled,
.enable = clk_plle_tegra210_enable,
-- 
2.18.0



[PATCH v1 2/2] clk: tegra20: Enable lock-status polling for PLLs

2018-08-18 Thread Dmitry Osipenko
Currently all PLL's on Tegra20 use a hardcoded delay despite of having
a lock-status bit. The lock-status polling was disabled ~7 years ago
because apparently some PLL was failing to lock. That issue isn't
observable with the modern kernel, hence let's assume it was some
unrelated bug and enable the lock-status polling. This significantly
reduces delay of any operation that require PLL to lock.

Signed-off-by: Dmitry Osipenko 
---
 drivers/clk/tegra/clk-tegra20.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index cc857d4d4a86..75415854ce12 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -298,7 +298,8 @@ static struct tegra_clk_pll_params pll_c_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_c_freq_table,
-   .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+   .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
 };
 
 static struct tegra_clk_pll_params pll_m_params = {
@@ -314,7 +315,8 @@ static struct tegra_clk_pll_params pll_m_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_m_freq_table,
-   .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+   .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
 };
 
 static struct tegra_clk_pll_params pll_p_params = {
@@ -331,7 +333,7 @@ static struct tegra_clk_pll_params pll_p_params = {
.lock_delay = 300,
.freq_table = pll_p_freq_table,
.flags = TEGRA_PLL_FIXED | TEGRA_PLL_HAS_CPCON |
-TEGRA_PLL_HAS_LOCK_ENABLE,
+TEGRA_PLL_HAS_LOCK_ENABLE | TEGRA_PLL_USE_LOCK,
.fixed_rate =  21600,
 };
 
@@ -348,7 +350,8 @@ static struct tegra_clk_pll_params pll_a_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_a_freq_table,
-   .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+   .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
 };
 
 static struct tegra_clk_pll_params pll_d_params = {
@@ -364,7 +367,8 @@ static struct tegra_clk_pll_params pll_d_params = {
.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
.lock_delay = 1000,
.freq_table = pll_d_freq_table,
-   .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+   .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
 };
 
 static const struct pdiv_map pllu_p[] = {
@@ -387,7 +391,8 @@ static struct tegra_clk_pll_params pll_u_params = {
.lock_delay = 1000,
.pdiv_tohw = pllu_p,
.freq_table = pll_u_freq_table,
-   .flags = TEGRA_PLLU | TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+   .flags = TEGRA_PLLU | TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
 };
 
 static struct tegra_clk_pll_params pll_x_params = {
@@ -403,7 +408,8 @@ static struct tegra_clk_pll_params pll_x_params = {
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
.freq_table = pll_x_freq_table,
-   .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
+   .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
+TEGRA_PLL_USE_LOCK,
 };
 
 static struct tegra_clk_pll_params pll_e_params = {
@@ -421,7 +427,7 @@ static struct tegra_clk_pll_params pll_e_params = {
.pdiv_tohw = plle_p,
.freq_table = pll_e_freq_table,
.flags = TEGRA_PLL_FIXED | TEGRA_PLL_LOCK_MISC |
-TEGRA_PLL_HAS_LOCK_ENABLE,
+TEGRA_PLL_HAS_LOCK_ENABLE | TEGRA_PLL_USE_LOCK,
.fixed_rate = 1,
 };
 
-- 
2.18.0



[PATCH v1 2/5] arm64: dts: mt7622: add a bluetooth 5 device node

2018-08-18 Thread Ryder Lee
Add a built-in bluetooth 5 support for MT7622.

Signed-off-by: Ryder Lee 
Acked-by: Sean Wang 
---
 arch/arm64/boot/dts/mediatek/mt7622.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi 
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index d297100..b4d7934 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -530,6 +530,13 @@
reg-shift = <2>;
reg-io-width = <4>;
status = "disabled";
+
+   bluetooth {
+   compatible = "mediatek,mt7622-bluetooth";
+   power-domains = < MT7622_POWER_DOMAIN_WB>;
+   clocks = <>;
+   clock-names = "ref";
+   };
};
 
nandc: nfi@1100d000 {
-- 
1.9.1



[PATCH v1 4/5] arm64: dts: mt7622: add bananapi BPI-R64 board

2018-08-18 Thread Ryder Lee
Add support for the bananapi R64 (BPI-R64) development board from
BIPAI KEJI. Detailed hardware information for BPI-R64 which could be
found on http://wiki.banana-pi.org/Banana_Pi_BPI-R64

Signed-off-by: Ryder Lee 
---
changes since v1:
- add missing sata nodes.
- fix pinctrl-0 for pcie@1,0.
- switch goio keys from polling mode to intterupt mode.
- add gpio-led nodes.
---
 arch/arm64/boot/dts/mediatek/Makefile  |   1 +
 .../boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts  | 530 +
 2 files changed, 531 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts

diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
b/arch/arm64/boot/dts/mediatek/Makefile
index 5b7fd6a..e8f952f 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -5,4 +5,5 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-bananapi-bpi-r64.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts 
b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
new file mode 100644
index 000..5d6005c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
@@ -0,0 +1,530 @@
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ryder Lee 
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR MIT)
+ */
+
+/dts-v1/;
+#include 
+#include 
+
+#include "mt7622.dtsi"
+#include "mt6380.dtsi"
+
+/ {
+   model = "Bananapi BPI-R64";
+   compatible = "bananapi,bpi-r64", "mediatek,mt7622";
+
+   chosen {
+   bootargs = "earlycon=uart8250,mmio32,0x11002000 
console=ttyS0,115200n1 swiotlb=512";
+   };
+
+   cpus {
+   cpu@0 {
+   proc-supply = <_vcpu_reg>;
+   sram-supply = <_vm_reg>;
+   };
+
+   cpu@1 {
+   proc-supply = <_vcpu_reg>;
+   sram-supply = <_vm_reg>;
+   };
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+
+   factory {
+   label = "factory";
+   linux,code = ;
+   gpios = < 0 GPIO_ACTIVE_HIGH>;
+   };
+
+   wps {
+   label = "wps";
+   linux,code = ;
+   gpios = < 102 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   green {
+   label = "bpi-r64:pio:green";
+   gpios = < 89 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   red {
+   label = "bpi-r64:pio:red";
+   gpios = < 88 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+   };
+
+   memory {
+   reg = <0 0x4000 0 0x4000>;
+   };
+
+   reg_1p8v: regulator-1p8v {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   reg_3p3v: regulator-3p3v {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   reg_5v: regulator-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "fixed-5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+
+   gmac1: mac@1 {
+   compatible = "mediatek,eth-mac";
+   reg = <1>;
+   phy-handle = <>;
+   };
+
+   mdio-bus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   phy5: ethernet-phy@5 {
+   reg = <5>;
+   phy-mode = "sgmii";
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default", 

[PATCH v1 5/5] dt-bindings: arm: mediatek: add support for bananapi BPI-R64 board

2018-08-18 Thread Ryder Lee
Update binding document for bananapi BPI-R64 board being supported.

Signed-off-by: Ryder Lee 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/mediatek.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index 8f260e5..d30f6ce 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -57,6 +57,9 @@ Supported boards:
 - Reference board variant 1 for MT7622:
 Required root node properties:
   - compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622";
+- Bananapi BPI-R64 for MT7622:
+Required root node properties:
+  - compatible = "bananapi,bpi-r64", "mediatek,mt7622";
 - Reference board for MT7623a with eMMC:
 Required root node properties:
   - compatible = "mediatek,mt7623a-rfb-emmc", "mediatek,mt7623";
-- 
1.9.1



[PATCH v1 3/5] arm64: dts: mt7622: fix ram size for rfb1

2018-08-18 Thread Ryder Lee
Fix ram size to 512 megabytes and sort nodes in alphabetical order.

Signed-off-by: Ryder Lee 
Acked-by: Sean Wang 
---
 arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 196 +--
 1 file changed, 98 insertions(+), 98 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts 
b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
index a747b7b..dcad086 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts
@@ -51,7 +51,7 @@
};
 
memory {
-   reg = <0 0x4000 0 0x3F00>;
+   reg = <0 0x4000 0 0x2000>;
};
 
reg_1p8v: regulator-1p8v {
@@ -81,6 +81,103 @@
};
 };
 
+ {
+   status = "disabled";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+
+   gmac1: mac@1 {
+   compatible = "mediatek,eth-mac";
+   reg = <1>;
+   phy-handle = <>;
+   };
+
+   mdio-bus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   phy5: ethernet-phy@5 {
+   reg = <5>;
+   phy-mode = "sgmii";
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default", "state_uhs";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_uhs>;
+   status = "okay";
+   bus-width = <8>;
+   max-frequency = <5000>;
+   cap-mmc-highspeed;
+   mmc-hs200-1_8v;
+   vmmc-supply = <_3p3v>;
+   vqmmc-supply = <_1p8v>;
+   assigned-clocks = < CLK_TOP_MSDC30_0_SEL>;
+   assigned-clock-parents = < CLK_TOP_UNIV48M>;
+   non-removable;
+};
+
+ {
+   pinctrl-names = "default", "state_uhs";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_uhs>;
+   status = "okay";
+   bus-width = <4>;
+   max-frequency = <5000>;
+   cap-sd-highspeed;
+   r_smpl = <1>;
+   cd-gpios = < 81 GPIO_ACTIVE_LOW>;
+   vmmc-supply = <_3p3v>;
+   vqmmc-supply = <_3p3v>;
+   assigned-clocks = < CLK_TOP_MSDC30_1_SEL>;
+   assigned-clock-parents = < CLK_TOP_UNIV48M>;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_nand_pins>;
+   status = "disabled";
+};
+
+_flash {
+   pinctrl-names = "default";
+   pinctrl-0 = <_nor_pins>;
+   status = "disabled";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
@@ -344,103 +441,6 @@
};
 };
 
- {
-   status = "disabled";
-};
-
- {
-   status = "okay";
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   status = "okay";
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   status = "okay";
-
-   gmac1: mac@1 {
-   compatible = "mediatek,eth-mac";
-   reg = <1>;
-   phy-handle = <>;
-   };
-
-   mdio-bus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   phy5: ethernet-phy@5 {
-   reg = <5>;
-   phy-mode = "sgmii";
-   };
-   };
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   status = "okay";
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   status = "okay";
-};
-
- {
-   pinctrl-names = "default", "state_uhs";
-   pinctrl-0 = <_pins_default>;
-   pinctrl-1 = <_pins_uhs>;
-   status = "okay";
-   bus-width = <8>;
-   max-frequency = <5000>;
-   cap-mmc-highspeed;
-   mmc-hs200-1_8v;
-   vmmc-supply = <_3p3v>;
-   vqmmc-supply = <_1p8v>;
-   assigned-clocks = < CLK_TOP_MSDC30_0_SEL>;
-   assigned-clock-parents = < CLK_TOP_UNIV48M>;
-   non-removable;
-};
-
- {
-   pinctrl-names = "default", "state_uhs";
-   pinctrl-0 = <_pins_default>;
-   pinctrl-1 = <_pins_uhs>;
-   status = "okay";
-   bus-width = <4>;
-   max-frequency = <5000>;
-   cap-sd-highspeed;
-   r_smpl = <1>;
-   cd-gpios = < 81 GPIO_ACTIVE_LOW>;
-   vmmc-supply = <_3p3v>;
-   vqmmc-supply = <_3p3v>;
-   assigned-clocks = < CLK_TOP_MSDC30_1_SEL>;
-   assigned-clock-parents = < CLK_TOP_UNIV48M>;
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_nand_pins>;
-   status = "disabled";
-};
-
-_flash {
-   pinctrl-names = "default";
-   pinctrl-0 = <_nor_pins>;
-   status = "disabled";
-
-   flash@0 {
-   compatible = 

[PATCH v1 1/5] arm64: dts: mt7622: add timer, CCI-400 and PMU nodes

2018-08-18 Thread Ryder Lee
Add device tree entries for timer, ARM CCI-400 and its PMU.
Otherwise, we add a cortex-a53-pmu node to enable hw perfevents.

Signed-off-by: Ryder Lee 
---
change since v1:
- add a pmu node.
---
 arch/arm64/boot/dts/mediatek/mt7622.dtsi | 55 
 1 file changed, 55 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi 
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index de2c47bd..d297100 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -79,6 +79,7 @@
#cooling-cells = <2>;
enable-method = "psci";
clock-frequency = <13>;
+   cci-control-port = <_control2>;
};
 
cpu1: cpu@1 {
@@ -92,6 +93,7 @@
#cooling-cells = <2>;
enable-method = "psci";
clock-frequency = <13>;
+   cci-control-port = <_control2>;
};
};
 
@@ -113,6 +115,13 @@
method  = "smc";
};
 
+   pmu {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts = ,
+;
+   interrupt-affinity = <>, <>;
+   };
+
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
@@ -218,6 +227,16 @@
#reset-cells = <1>;
};
 
+timer: timer@10004000 {
+compatible = "mediatek,mt7622-timer",
+ "mediatek,mt6577-timer";
+reg = <0 0x10004000 0 0x80>;
+interrupts = ;
+clocks = < CLK_INFRA_APXGPT_PD>,
+ < CLK_TOP_RTC>;
+clock-names = "system-clk", "rtc-clk";
+};
+
scpsys: scpsys@10006000 {
compatible = "mediatek,mt7622-scpsys",
 "syscon";
@@ -325,6 +344,42 @@
  <0 0x1036 0 0x2000>;
};
 
+   cci: cci@1039 {
+   compatible = "arm,cci-400";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0 0x1039 0 0x1000>;
+   ranges = <0 0 0x1039 0x1>;
+
+   cci_control0: slave-if@1000 {
+   compatible = "arm,cci-400-ctrl-if";
+   interface-type = "ace-lite";
+   reg = <0x1000 0x1000>;
+   };
+
+   cci_control1: slave-if@4000 {
+   compatible = "arm,cci-400-ctrl-if";
+   interface-type = "ace";
+   reg = <0x4000 0x1000>;
+   };
+
+   cci_control2: slave-if@5000 {
+   compatible = "arm,cci-400-ctrl-if";
+   interface-type = "ace";
+   reg = <0x5000 0x1000>;
+   };
+
+   pmu@9000 {
+   compatible = "arm,cci-400-pmu,r1";
+   reg = <0x9000 0x5000>;
+   interrupts = ,
+,
+,
+,
+;
+   };
+   };
+
auxadc: adc@11001000 {
compatible = "mediatek,mt7622-auxadc";
reg = <0 0x11001000 0 0x1000>;
-- 
1.9.1



Re: [GIT PULL] Driver core patches for 4.19-rc1

2018-08-18 Thread Greg KH
On Sat, Aug 18, 2018 at 05:57:58PM +0200, Greg KH wrote:
> The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:
> 
>   Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
> tags/driver-core-4.19-rc1
> 
> for you to fetch changes up to d2fc88a61b4ea99f574bde16e92718e22f312136:
> 
>   Merge 4.18-rc7 into driver-core-next (2018-07-30 10:08:09 +0200)
> 
> 
> Driver core patches for 4.19-rc1
> 
> Here are all of the driver core and related patches for 4.19-rc1.
> 
> ZNothing huge here, just a number of small cleanups and the ability to
> now stop the deferred probing after init happens.
> 
> All of these have been in linux-next for a while with only a merge issue
> reported.  That merge issue is in fs/sysfs/group.c and Stephen has
> posted the diff of what it should be to resolve this.  I'll follow up
> with that diff to this pull request.

Here's Stephen's email with the merge resolution that Rajat verified is
correct:


Date: Mon, 23 Jul 2018 15:12:24 +1000
From: Stephen Rothwell 
To: Greg KH , David Miller , Networking

Cc: Linux-Next Mailing List , Linux Kernel Mailing
List , Dmitry Torokhov
, Rajat Jain 
Subject: linux-next: manual merge of the driver-core tree with the net-next
tree

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in:

  fs/sysfs/group.c

between commit:

  5f81880d5204 ("sysfs, kobject: allow creating kobject belonging to arbitrary 
users")

from the net-next tree and commit:

  c855cf2759d2 ("sysfs: Fix internal_create_group() for named group updates")

from the driver-core tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/sysfs/group.c
index c7a716c4acc9,38240410f831..
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@@ -122,15 -118,23 +122,24 @@@ static int internal_create_group(struc
kobj->name, grp->name ?: "");
return -EINVAL;
}
 +  kobject_get_ownership(kobj, , );
if (grp->name) {
-   kn = kernfs_create_dir_ns(kobj->sd, grp->name,
- S_IRWXU | S_IRUGO | S_IXUGO,
- uid, gid, kobj, NULL);
-   if (IS_ERR(kn)) {
-   if (PTR_ERR(kn) == -EEXIST)
-   sysfs_warn_dup(kobj->sd, grp->name);
-   return PTR_ERR(kn);
+   if (update) {
+   kn = kernfs_find_and_get(kobj->sd, grp->name);
+   if (!kn) {
+   pr_warn("Can't update unknown attr grp name: 
%s/%s\n",
+   kobj->name, grp->name);
+   return -EINVAL;
+   }
+   } else {
 -  kn = kernfs_create_dir(kobj->sd, grp->name,
 - S_IRWXU | S_IRUGO | S_IXUGO,
 - kobj);
++  kn = kernfs_create_dir_ns(kobj->sd, grp->name,
++S_IRWXU | S_IRUGO | S_IXUGO,
++uid, gid, kobj, NULL);
+   if (IS_ERR(kn)) {
+   if (PTR_ERR(kn) == -EEXIST)
+   sysfs_warn_dup(kobj->sd, grp->name);
+   return PTR_ERR(kn);
+   }
}
} else
kn = kobj->sd;


[GIT PULL] Char/Misc driver patches for 4.19-rc1

2018-08-18 Thread Greg KH
The following changes since commit 9d3cce1e8b8561fed5f383d22a4d6949db4eadbe:

  Linux 4.18-rc5 (2018-07-15 12:49:31 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 
tags/char-misc-4.19-rc1

for you to fetch changes up to 128f38041035001276e964cda1cf951f218d965d:

  android: binder: Rate-limit debug and userspace triggered err msgs 
(2018-08-08 11:05:47 +0200)


Char/Misc driver patches for 4.19-rc1

Here is the bit set of char/misc drivers for 4.19-rc1

There is a lot here, much more than normal, seems like everyone is
writing new driver subsystems these days...  Anyway, major things here
are:
- new FSI driver subsystem, yet-another-powerpc low-level
  hardware bus
- gnss, finally an in-kernel GPS subsystem to try to tame all of
  the crazy out-of-tree drivers that have been floating around
  for years, combined with some really hacky userspace
  implementations.  This is only for GNSS receivers, but you
  have to start somewhere, and this is great to see.
Other than that, there are new slimbus drivers, new coresight drivers,
new fpga drivers, and loads of DT bindings for all of these and existing
drivers.

Full details of everything is in the shortlog.

All of these have been in linux-next for a while with no reported
issues.

Signed-off-by: Greg Kroah-Hartman 


Alan Tull (1):
  Documentation: fpga: cleanup

Alexander Kapshuk (2):
  ver_linux: Process input coming from procmaps that matches libc only
  ver_linux: Do not check for ver_linux pattern in version function

Alexander Usyskin (5):
  mei: remove unused MEI_IAMTHIF_STALL_TIMER define
  mei: add optional timeout to internal bus recv
  mei: expose fw version to sysfs
  mei: don't update offset in write
  mei: define dma ring buffer sizes for PCH12 HW and newer

Andrew Jeffery (2):
  fsi: gpio: Trace busy count
  fsi: gpio: Remove unused 'id' variable

Anson Huang (2):
  dt-bindings: nvmem: imx-ocotp: add compatible string for imx6sll
  nvmem: imx-ocotp: add support for imx6sll

Anton Vasilyev (2):
  firmware: vpd: Fix section enabled flag on vpd_section_destroy
  misc: ti-st: Fix memory leak in the error path of probe()

Arjan van de Ven (1):
  use the new async probing feature for the hyperv drivers

Arnd Bergmann (4):
  misc: mic: fix passing the current time
  headers: fix linux/mod_devicetable.h inclusions
  extcon: max3355: include mod_devicetable.h
  coresight: include vmalloc.h for vmap/vunmap

Baolin Wang (1):
  dt-bindings: nvmem: Add Spreadtrum SC27XX efuse controller documentation

Benjamin Herrenschmidt (46):
  fsi/fsi-master-gpio: Sample input data on different clock phase
  fsi/fsi-master-gpio: Add "no-gpio-delays" option
  fsi/fsi-master-gpio: Reduce turnaround clocks
  fsi/fsi-master-gpio: Reduce dpoll clocks
  fsi/fsi-master-gpio: Delay sampling of FSI data input
  fsi/fsi-master-gpio: Implement CRC error recovery
  fsi/fsi-master-gpio: More error handling cleanup
  fsi/sbefifo: Add driver for the SBE FIFO
  fsi: sbefifo: Remove unneeded semicolon
  fsi: scom: Add mutex around FSI2PIB accesses
  fsi: scom: Whitespace fixes
  fsi: scom: Fixup endian annotations
  fsi: scom: Add register definitions
  fsi: scom: Major overhaul
  gpio: aspeed: Rework register type accessors
  gpio: aspeed: Add "Read Data" register to read the write latch
  gpio: aspeed: Add command source registers
  gpio: aspeed: Add interfaces for co-processor to grab GPIOs
  fsi: sbefifo: Fix checker warning about late NULL check
  fsi: Move code around to avoid forward declaration
  fsi: Add mechanism to set the tSendDelay and tEchoDelay values
  fsi: master-gpio: Rename and adjust send delay
  fsi: master-gpio: Add support for link_config
  fsi: master-gpio: Add more tracepoints
  fsi: master-gpio: Remove unused definitions
  fsi: master-gpio: Remove "GPIO" prefix on some definitions
  fsi: Don't use device_unregister() in fsi_master_register()
  fsi: master-gpio: Add missing release function
  fsi: Move various master definitions to a common header
  Merge remote-tracking branch 'gpio/ib-aspeed' into upstream-ready
  devres: Add devm_of_iomap()
  dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"
  fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire
  fsi: sbefifo: Fix inconsistent use of ffdc mutex
  dt-bindings: fsi: Add optional chip-id to CFAMs
  fsi: Add support for device-tree provided chip IDs
  fsi: master-ast-cf: Fix build warnings on 64-bit platforms
  fsi: master-ast-cf: Mask unused bits in RTAG/RCRC
  fsi: master-ast-cf: Rename dump_trace() 

[GIT PULL] Staging/IIO driver patches for 4.19-rc1

2018-08-18 Thread Greg KH
The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:

  Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
tags/staging-4.19-rc1

for you to fetch changes up to e4f6a44c4aeca9eda153302abb0c14d053914f72:

  staging:rtl8192u: Remove unused macro definitions - Style (2018-08-08 
14:27:03 +0200)


Staging/IIO patches for 4.19-rc1

Here are the big staging/iio patches for 4.19-rc1.

Lots of churn here, with tons of cleanups happening in staging drivers,
a removal of an old crypto driver that no one was using (skein), and the
addition of some new IIO drivers.  Also added was a "gasket" driver from
Google that needs loads of work and the erofs filesystem.

Even with adding all of the new drivers and a new filesystem, we are
only adding about 1000 lines overall to the kernel linecount, which
shows just how much cleanup happened, and how big the unused crypto
driver was.

All of these have been in the linux-next tree for a while now with no
reported issues.

Note, you will have a merge problem with a device tree IIO file and the
MAINTAINERS file, both resolutions are easy, just take all changed.
There will be a skein file merge issue as well, but that file got
deleted so just drop that.

Signed-off-by: Greg Kroah-Hartman 


Abdun Nihaal (1):
  staging: mt7621-pci: Fix coding style error

Ajay Singh (56):
  staging: wilc1000: use list_head to maintain 'txq_entry_t' elements of tx 
queue
  staging: wilc1000: use list_head to maintain 'rxq_entry_t elements in rx 
queue
  staging: wilc1000: remove 'rxq_entries' from 'wilc' struct
  staging: wilc1000: move 'txq_spinlock_flags' from 'wilc' structure to 
local variable
  staging: wilc1000: remove host_if_work() to handle TODO list issue
  staging: wilc1000: remove unused marco related to HIF commands
  staging: wilc1000: move the allocation of cmd out of wilc_enqueue_cmd()
  staging: wilc1000: added 'work_comp' completion as part of host_if_msg
  staging: wilc1000: remove 'hif_thread_comp' completions
  staging: wilc1000: rename wilc_enqueue_cmd() to wilc_enqueue_work()
  staging: wilc1000: handle freeing of key data in wep add key
  staging: wilc1000: handle freeing of key data in wilc_add_ptk()
  staging: wilc1000: handle freeing of 'key' & 'seq' data in 
wilc_add_rx_gtk()
  staging: wilc1000: avoid use of static variable 'inactive_time'
  staging: wilc1000: avoid use of static variable 'rssi'
  staging: wilc1000: updated TODO file
  staging: wilc1000: fix static checker warning to unlock mutex in 
wilc_deinit()
  staging: wilc1000: remove unused enum declaration
  staging: wilc1000: remove enum connect_status instead use 
ieee80211_statuscode
  staging: wilc1000: remove extra enum defined for data rates
  staging: wilc1000: remove extra enums defined for ieee80211_eid
  staging: wilc1000: rename goto to avoid leading '_' in label name
  staging: wilc1000: rename enum CURRENT_TXRATE to use lowercase
  staging: wilc1000: rename enum SITESURVEY to use lowercase
  staging: wilc1000: rename enum AUTHTYPE to use lowercase
  staging: wilc1000: remove unused elements in 'wilc' struct
  staging: wilc1000: remove unnecessary elements from 'wilc_priv' struct
  staging: wilc1000: removed unused element from wilc_cfg_frame struct
  staging: wilc1000: remove the mutliple #define used for same macro
  staging: wilc1000: use lowercase for 'IFC_UP' struct element name
  staging: wilc1000: remove unnecessary blank line between variable 
declaration
  staging: wilc1000: use single space before opening brances '{'
  staging: wilc1000: remove unnecessary type used for wid id
  staging: wilc1000: avoid forward declaration for handle_scan_done()
  staging: wilc1000: avoid host_int_get_assoc_res_info() forward declaration
  staging: wilc1000: avoid forward declaration of 
host_int_parse_join_bss_param()
  staging: wilc1000: avoid setting default value for variable at declaration
  staging: wilc1000: use 'int' inplace of 's32' date type
  staging: wilc1000: remove unnecessary 'NULL' check from cfg80211_ops 
callbacks
  staging: wilc1000: move variable assignment along with its declaration
  staging: wilc1000: remove gpio parameter from wilc_netdev_init()
  staging: wilc1000: rename variable from 'gpio' to 'gpio_irq'
  staging: wilc1000: change compatible string from atmel to microchip
  staging: wilc1000: use descriptor-based interface for GPIO
  staging: wilc1000: fix TODO to compile spi and sdio components in single 
module
  staging: wilc1000: remove unnecessary comments and comments description
  staging: wilc1000: modified debug log messages 

[GIT PULL] Driver core patches for 4.19-rc1

2018-08-18 Thread Greg KH
The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:

  Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git 
tags/driver-core-4.19-rc1

for you to fetch changes up to d2fc88a61b4ea99f574bde16e92718e22f312136:

  Merge 4.18-rc7 into driver-core-next (2018-07-30 10:08:09 +0200)


Driver core patches for 4.19-rc1

Here are all of the driver core and related patches for 4.19-rc1.

ZNothing huge here, just a number of small cleanups and the ability to
now stop the deferred probing after init happens.

All of these have been in linux-next for a while with only a merge issue
reported.  That merge issue is in fs/sysfs/group.c and Stephen has
posted the diff of what it should be to resolve this.  I'll follow up
with that diff to this pull request.

Signed-off-by: Greg Kroah-Hartman 


Benjamin Gaignard (1):
  base: core: Remove WARN_ON from link dependencies check

Benjamin Herrenschmidt (1):
  drivers: core: Remove glue dirs from sysfs earlier

Greg Kroah-Hartman (1):
  Merge 4.18-rc7 into driver-core-next

Guenter Roeck (2):
  kernfs: Replace strncpy with memcpy
  kobject: Replace strncpy with memcpy

Javier Martinez Canillas (1):
  driver core: add a debugfs entry to show deferred devices

Joe Perches (1):
  device: Add #define dev_fmt similar to #define pr_fmt

Luis R. Rodriguez (1):
  Documentation: update firmware loader fallback reference

Pingfan Liu (1):
  drivers/base: stop new probing during shutdown

Rajat Jain (1):
  sysfs: Fix internal_create_group() for named group updates

Randy Dunlap (2):
  linux/device.h: fix kernel-doc notation warning
  sysfs.h: fix non-kernel-doc comment

Rob Herring (6):
  driver core: allow stopping deferred probe after init
  dt-bindings: pinctrl: add a 'pinctrl-use-default' property
  pinctrl: Support stopping deferred probe after initcalls
  iommu: Stop deferring probe at end of initcalls
  iommu: Remove IOMMU_OF_DECLARE
  PM / Domains: Stop deferring probe at the end of initcall

Shaokun Zhang (1):
  driver core: remove unnecessary function extern declare

Sudeep Holla (1):
  drivers: base: cacheinfo: use OF property_read_u32 instead of 
get_property,read_number

Todd Poynor (1):
  drivers: base: initcall_debug logs for driver probe times

Wesley W. Terpstra (1):
  base: fix order of OF initialization

 Documentation/admin-guide/kernel-parameters.txt|   9 ++
 .../bindings/pinctrl/pinctrl-bindings.txt  |   6 +
 .../driver-api/firmware/fallback-mechanisms.rst|   7 +-
 drivers/base/base.h|   2 -
 drivers/base/cacheinfo.c   |  24 ++--
 drivers/base/core.c|  23 ++--
 drivers/base/dd.c  | 134 +
 drivers/base/init.c|   2 +-
 drivers/base/power/domain.c|   2 +-
 drivers/iommu/arm-smmu-v3.c|   2 -
 drivers/iommu/arm-smmu.c   |   7 --
 drivers/iommu/exynos-iommu.c   |   2 -
 drivers/iommu/ipmmu-vmsa.c |   3 -
 drivers/iommu/msm_iommu.c  |   2 -
 drivers/iommu/of_iommu.c   |  21 +---
 drivers/iommu/qcom_iommu.c |   2 -
 drivers/iommu/rockchip-iommu.c |   2 -
 drivers/pinctrl/devicetree.c   |  15 ++-
 fs/kernfs/symlink.c|   2 +-
 fs/sysfs/group.c   |  29 +++--
 include/asm-generic/vmlinux.lds.h  |   2 -
 include/linux/device.h | 107 +---
 include/linux/kobject.h|  17 +++
 include/linux/of_iommu.h   |   4 -
 include/linux/sysfs.h  |   6 +-
 lib/kobject.c  |   2 +-
 26 files changed, 273 insertions(+), 161 deletions(-)


[GIT PULL] TTY/Serial patches for 4.19-rc1

2018-08-18 Thread Greg KH
The following changes since commit 021c91791a5e7e85c567452f1be3e4c2c6cb6063:

  Linux 4.18-rc3 (2018-07-01 16:04:53 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-4.19-rc1

for you to fetch changes up to 47ac76662ca9c5852fd353093f19de3ae85f2e66:

  tty: serial: 8250: Revert NXP SC16C2552 workaround (2018-08-12 18:53:30 +0200)


TTY/Serial driver patches for 4.19-rc1

Here is the big tty and serial driver pull request for 4.19-rc1.

It's not all that big, just a number of small serial driver updates and
fixes, along with some better vt handling for unicode characters for
those using braille terminals.

Full details are in the shortlog.

All of these patches have been in linux-next for a long time with no
reported issues.

Signed-off-by: Greg Kroah-Hartman 


Aaron Sierra (1):
  serial: 8250_exar: Read INT0 from slave device, too

Adam Borowski (4):
  vt: don't reinvent min()
  vt: selection: handle storing of characters above U+
  vt: selection: take screen contents from uniscr if available
  vt: drop unused struct vt_struct

Alexander Sverdlin (2):
  serial: 8250: of: Correct of_platform_serial_setup() error handling
  serial: 8250: of: Defer probe on missing IRQ

Andy Shevchenko (5):
  serial: 8250_dw: Introduce IO accessors to extended registers
  serial: 8250_exar: Remove useless has_slave member
  serial: 8250_exar: Describe all members in struct exar8250_board
  serial: 8250_exar: Drop unused variable in pci_xr17v35x_setup()
  serial: 8250: Use cached port name directly in messages

Anton Vasilyev (1):
  tty: rocket: Fix possible buffer overwrite on register_PCI

Arnd Bergmann (1):
  tty: use 64-bit timstamp

Baruch Siach (1):
  dt-bindings: serial: imx: clarify rs485 support usage

Chen Hu (1):
  serial: 8250_dw: always set baud rate in dw8250_set_termios

Chris Brandt (6):
  serial: sh-sci: Add support for R7S9210
  serial: sh-sci: Document r7s9210 bindings
  serial: sh-sci: Improve interrupts description
  serial: sh-sci: Allow for compressed SCIF address
  serial: sh-sci: Remove SCIx_RZ_SCIFA_REGTYPE
  serial: sh-sci: Improve support for separate TEI and DRI interrupts

Christophe JAILLET (1):
  serial: pxa: Fix an error handling path in 'serial_pxa_probe()'

Colin Ian King (2):
  parport: parport_serial: Add WCH CH382L PCIe single parallel port support
  tty: serial: jsm: remove redundant pointer ch

Daniel Golle (1):
  tty: serial: exar: generalize RS485 setup

Geert Uytterhoeven (7):
  serial: sh-sci: Stop RX FIFO timer during port shutdown
  serial: sh-sci: Postpone DMA release when falling back to PIO
  serial: sh-sci: Stop TX DMA workqueue during port shutdown
  serial: sh-sci: Stop using deprecated dmaengine_terminate_all()
  serial: sh-sci: Fix use-after-free on subsequent port startup
  serial: sh-sci: Drop superfluous assignment in sci_request_dma()
  serial: sh-sci: Document that serial aliases became optional

Girish Mahadevan (1):
  tty: serial: qcom_geni_serial: Add support for flow control

Greg Kroah-Hartman (1):
  Merge 4.18-rc3 into tty-next

Helmut Grohne (3):
  serial: xuartps: fix typo in cdns_uart_startup
  serial: xuartps: reduce hardware TX race condition
  serial: xuartps: remove unnecessary register write

Jan Kundrát (1):
  serial: max310x: Check the clock readiness

Jisheng Zhang (4):
  serial: 8250: let serial8250_get_divisor() get uart_port * as param
  serial: 8250: introduce get_divisor() and set_divisor() hook
  serial: 8250: export serial8250_do_set_divisor()
  serial: 8250_dw: add fractional divisor support

Johan Hovold (4):
  serdev: add controller runtime PM support
  tty: fix termios input-speed encoding
  tty: fix termios input-speed encoding when using BOTHER
  tty: support CIBAUD without BOTHER

Mark (1):
  tty: serial: 8250: Revert NXP SC16C2552 workaround

Mars Cheng (3):
  dt-bindings: mediatek: add support for mt6765 reference board
  dt-bindings: mtk-uart: add mt6765 uart bindings
  dt-bindings: interrupt-controller: add binding for mt6765

Matthijs van Duin (1):
  pty: fix O_CLOEXEC for TIOCGPTPEER

Nicolas Pitre (6):
  vt: preserve unicode values corresponding to screen characters
  vt: introduce unicode mode for /dev/vcs
  vt: unicode fallback for scrollback
  vt: coherence validation code for the unicode screen buffer
  vt: add /dev/vcsu* to devices.txt
  vt: avoid a VLA in the unicode screen scroll function

Nishanth Menon (2):
  dt-bindings: serial: 8250_omap: Add compatible for AM654 UART controller
  serial: 8250_omap: Add support for AM654 UART controller

Peter Zijlstra (1):
  atomic/tty: Fix up 

Re: [PATCHv2] ide: Use NULL to compare with pointer-typed value rather than 0

2018-08-18 Thread Sergei Shtylyov
On 08/18/2018 09:16 AM, zhong jiang wrote:

> We should use NULL to compare with pointer-typed value rather than
> 0. The issue is detected with the help of Coccinelle.

   Your description stopped to match the patch in v2.
   Actually, this X ==  NULL to !x preference is largely spocific to netdev...
Although, IDE maintainer is the same now person. :-)  
 
> Signed-off-by: zhong jiang 
> ---
>  drivers/ide/pmac.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
> index c5b902b..ca36a97 100644
> --- a/drivers/ide/pmac.c
> +++ b/drivers/ide/pmac.c
> @@ -1682,7 +1682,7 @@ static int pmac_ide_init_dma(ide_hwif_t *hwif, const 
> struct ide_port_info *d)
>   /* We won't need pci_dev if we switch to generic consistent
>* DMA routines ...
>*/
> - if (dev == NULL || pmif->dma_regs == 0)
> + if (!dev || !pmif->dma_regs)
>   return -ENODEV;
>   /*
>* Allocate space for the DBDMA commands.

MBR, Sergei


Re: [PATCH] iio: accel: cros_ec_accel_legacy: Mark expected switch fall-throughs

2018-08-18 Thread Marcus Folkesson
Hi Gutavo,

Sorry for the delay.

On Wed, Aug 15, 2018 at 12:50:10PM -0500, Gustavo A. R. Silva wrote:
> Hi Marcus,
> 
> On 8/15/18 12:27 PM, Marcus Folkesson wrote:
> > Hi,
> > 
> > On Wed, Aug 15, 2018 at 11:38:52AM -0500, Gustavo A. R. Silva wrote:
> >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> >> where we are expecting to fall through.
> >>
> >> Addresses-Coverity-ID: 1462408 ("Missing break in switch")
> >> Signed-off-by: Gustavo A. R. Silva 
> >> ---
> >>  drivers/iio/accel/cros_ec_accel_legacy.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c 
> >> b/drivers/iio/accel/cros_ec_accel_legacy.c
> >> index 063e89e..d609654 100644
> >> --- a/drivers/iio/accel/cros_ec_accel_legacy.c
> >> +++ b/drivers/iio/accel/cros_ec_accel_legacy.c
> >> @@ -385,8 +385,10 @@ static int cros_ec_accel_legacy_probe(struct 
> >> platform_device *pdev)
> >>switch (i) {
> >>case X:
> >>ec_accel_channels[X].scan_index = Y;
> >> +  /* fall through */
> >>case Y:
> >>ec_accel_channels[Y].scan_index = X;
> >> +  /* fall through */
> >>case Z:
> >>ec_accel_channels[Z].scan_index = Z;
> >>}
> > 
> > Hum, I'm not sure we are supposed to fall through here, even if it does
> > not hurt to do so.
> 
> Yeah. You're right. It doesn't hurt but is actually redundant. I think
> the original intention was to break instead of falling through.
> 
> > I even think we can remove the switch and put that outside the for-loop,
> > e.g:
> > 
> > ec_accel_channels[X].scan_index = Y;
> > ec_accel_channels[Y].scan_index = X;
> > ec_accel_channels[Z].scan_index = Z;
> > 
> > for (i = X ; i < MAX_AXIS; i++) {
> > if (state->sensor_num == MOTIONSENSE_LOC_LID && i != Y)
> > state->sign[i] = -1;
> > else
> > state->sign[i] = 1;
> > }
> > 
> 
> I like this, but the code clearly depends on MAX_AXIS. So, if MAX_AXIS
> will be always 3, then the change you suggest is just fine. Otherwise,
> it seems that adding a break to each case is the right way to go.
> 
> What do you think?

Well, I guess it is a matter of taste after all.
I don't think the number of axis will change, but just put the break in
place is good enough.

Anyway, If we choose to not use the switch, I think we should remove the
for-loop as well, eg:

ec_accel_channels[X].scan_index = Y;
ec_accel_channels[Y].scan_index = X;
ec_accel_channels[Z].scan_index = Z;

if (state->sensor_num == MOTIONSENSE_LOC_LID) {
state->sign[X] = -1;
state->sign[Y] = 1;
state->sign[Z] = -1;
} else {
state->sign[X] = 1;
state->sign[Y] = 1;
state->sign[Z] = 1;
}

But someone else may like to give their point of view on this change.

> 
> Thanks for the feedback.
> --
> Gustavo

Best regards
Marcus Folkesson


signature.asc
Description: PGP signature


Re: [PATCH 4.4 00/13] 4.4.149-stable review

2018-08-18 Thread Rafael David Tinoco
On Thu, Aug 16, 2018 at 08:41:47PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.149 release.
> There are 13 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Aug 18 17:16:16 UTC 2018.
> Anything received after that time might be too late.
> 

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.4.150
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 7dc18ebc3101229d5238a2dc740804cd4836b383
git describe: v4.4.150
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.150


No regressions (compared to build v4.4.148-14-g23871eab85a2)


Ran 5943 total tests in the following environments and test suites.

Environments
--
- qemu_arm
- qemu_x86_64
- x15 - arm

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests

Summary


kernel: 4.4.150-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.150-rc1-hikey-20180817-261
git commit: dc7326348e08ce8a119ce1d545db4258a0313264
git describe: 4.4.150-rc1-hikey-20180817-261
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.150-rc1-hikey-20180817-261


No regressions (compared to build 4.4.149-rc1-hikey-20180816-260)


Ran 2725 total tests in the following environments and test suites.

Environments
--
- hi6220-hikey - arm64
- qemu_arm64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests

-- 
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.18 00/22] 4.18.2-stable review

2018-08-18 Thread Greg Kroah-Hartman
On Sat, Aug 18, 2018 at 11:21:07AM -0300, Rafael David Tinoco wrote:
> On Thu, Aug 16, 2018 at 08:45:16PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.2 release.
> > There are 22 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Aug 18 17:15:44 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Thanks for testing all of these and letting me know.

greg k-h


Re: [PATCH 4.9 00/15] 4.9.121-stable review

2018-08-18 Thread Rafael David Tinoco
On Thu, Aug 16, 2018 at 08:41:53PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.121 release.
> There are 15 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Aug 18 17:16:11 UTC 2018.
> Anything received after that time might be too late.
> 

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.9.122-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: a239ebd443c4cec0db041fbd89ecd4f40738c496
git describe: v4.9.121-2-ga239ebd443c4
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.121-2-ga239ebd443c4


No regressions (compared to build v4.9.119-112-g1a93cfe68391)


Ran 16231 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

AND

Summary


kernel: 4.9.122
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: ea101a702611f987c937a5fafe00f714fd9c1fe8
git describe: v4.9.122
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.122


No regressions (compared to build v4.9.119-112-g1a93cfe68391)


Ran 12144 total tests in the following environments and test suites.

Environments
--
- hi6220-hikey - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH] staging: rtl8188eu: Type cast function argument

2018-08-18 Thread Joe Perches
On Sat, 2018-08-18 at 20:28 +0530, Bhaskar Singh wrote:
> On Sat, Aug 18, 2018 at 10:33:31PM +0800, zhong jiang wrote:
> > On 2018/8/18 22:24, Bhaskar Singh wrote:
> > > This patch might suppress some warrning.
> > > 
> > > The function prototype of rtw_malloc2d is
> > > 
> > > void *rtw_malloc2d(int h, int w, int size)
> > > 
> > > This patch also resolves the checkpatch.pl warning
> > > 
> > > WARNING: line over 80 characters

Please look deeper at the code than checkpatch.

This function is used exactly once and could
likely be removed and coded inline instead to
improve readability.

> > > Signed-off-by: Bhaskar Singh 
> > > ---
> > >  drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c 
> > > b/drivers/staging/rtl8188eu/core/rtw_efuse.c
> > > index 0fd306a808c4..735d654b2844 100644
> > > --- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
> > > +++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
> > > @@ -91,7 +91,8 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 
> > > _size_byte, u8  *pbuf)
> > >   if (!efuseTbl)
> > >   return;
> > >  
> > > - eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E, 
> > > EFUSE_MAX_WORD_UNIT, sizeof(u16));
> > > + eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E,
> > > + EFUSE_MAX_WORD_UNIT, (int)sizeof(u16));
> > >  
> > 
> >   You should be align with left parenthesis.
> > 
> >  Thanks,
> >  zhong jiang
> > >   if (!eFuseWord) {
> > >   DBG_88E("%s: alloc eFuseWord fail!\n", __func__);
> > >   goto eFuseWord_failed;
> > 
> > 
> 
> why post-commit doesn't give some warrning about that (because commits are 
> checked by
> post-commit script)?
> Do I need to resend the patch?
> 


Re: [PATCH] staging: rtl8188eu: Type cast function argument

2018-08-18 Thread Bhaskar Singh
On Sat, Aug 18, 2018 at 10:33:31PM +0800, zhong jiang wrote:
> On 2018/8/18 22:24, Bhaskar Singh wrote:
> > This patch might suppress some warrning.
> >
> > The function prototype of rtw_malloc2d is
> >
> > void *rtw_malloc2d(int h, int w, int size)
> >
> > This patch also resolves the checkpatch.pl warning
> >
> > WARNING: line over 80 characters
> >
> > Signed-off-by: Bhaskar Singh 
> > ---
> >  drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c 
> > b/drivers/staging/rtl8188eu/core/rtw_efuse.c
> > index 0fd306a808c4..735d654b2844 100644
> > --- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
> > +++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
> > @@ -91,7 +91,8 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 
> > _size_byte, u8  *pbuf)
> > if (!efuseTbl)
> > return;
> >  
> > -   eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E, 
> > EFUSE_MAX_WORD_UNIT, sizeof(u16));
> > +   eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E,
> > +   EFUSE_MAX_WORD_UNIT, (int)sizeof(u16));
> >  
>   You should be align with left parenthesis.
> 
>  Thanks,
>  zhong jiang
> > if (!eFuseWord) {
> > DBG_88E("%s: alloc eFuseWord fail!\n", __func__);
> > goto eFuseWord_failed;
> 
>
why post-commit doesn't give some warrning about that (because commits are 
checked by
post-commit script)?
Do I need to resend the patch?



Dearly Beloved In Christ.

2018-08-18 Thread Mrs. Daniella Kyle
Hi Dear,

Sorry to invade your privacy, I am Mrs. Daniella Kyle the wife of Mr
Angelo Kyle,my husband worked with Central Bank Of Philippines for ten
years before he died in the year 2012. When my late husband was alive
he deposited sum amount of Money with a Bank in UK, Presently,this
money is still with the Bank,I am in a hospital in Philippines
receiving treatment
and my doctor has confirmed to me that i have just few days to live on
earth due to my esophageal cancer.

Please I am choosing you to receive this money on my behalf,and use it
to help the less privilege. Contact me on my private email:
daniellaaky...@gmail.com

Your Sister in Christ,
Mrs. Daniella Kyle


Re: [PATCH] Coccinelle: remove pci_alloc_consistent semantic to dectect in zalloc-simple.cocci

2018-08-18 Thread Himanshu Jha
On Sat, Aug 18, 2018 at 10:10:26PM +0800, zhong jiang wrote:
> On 2018/8/18 22:01, Julia Lawall wrote:
> >
> > On Sat, 18 Aug 2018, zhong jiang wrote:
> >
> >> On 2018/8/18 20:52, Himanshu Jha wrote:
> >>> On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
>  Because pci_alloc_consistent has been deprecated. We prefer to use
>  dam_alloc_coherent directly. Therefore, we should remove 
>  pci_alloc_consistent
> >>>   ^^^ typo "dma"
> >>>
> >>> Also, typo in the patch subject "dectect" -> "detect"
> >>  Thanks,  will fix it in v2.
> >>> Otherwise,
> >>>
> >>> Acked-by: Himanshu Jha 
> >>>
> >>> Thanks for cleaning up, we still have few more *_alloc/memset
> >>> in the mainline, especially in the scsi subsystem, even after
> >>> I cleaned up with two long patch series in the past.
> >>>
> >>I post same patches like *_alloc/memset in the scsi subsystem. 
> >> Unfortunately,
> >>Maintainer maybe do not care about the change.  therefore,  None of my 
> >> patches
> >>   are received and rarely feedback.
> > Maybe they will be picked up later.
>  Hope so.  It's been more than a month since I post the patches. Maybe I 
> should give a kindly ping. :-)

Heh! The problem is Martin only when picks up patches if the driver
maintainer Acks them, and it happens very rarely until you have
a *real* bugfix.

But since these patches are simple, so Martin should pick it up
even if the patch doesn't receive any feedback.

If you ping, then certainly Martin will give you the same feedback.

Maybe you can make them happy by sending a syzbot bugfix ;)

-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology


Re: [PATCH 4.14 00/22] 4.14.64-stable review

2018-08-18 Thread Rafael David Tinoco
On Thu, Aug 16, 2018 at 08:45:01PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.64 release.
> There are 22 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Aug 18 17:16:07 UTC 2018.
> Anything received after that time might be too late.
> 

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.14.65
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 4cea13b66144903ae7310331b43e08f7b2d6aadb
git describe: v4.14.65
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.65


No regressions (compared to build v4.14.62-110-gaff06b616b3c)


Ran 8890 total tests in the following environments and test suites.

Environments
--
- hi6220-hikey - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests

--
Linaro LKFT
https://lkft.linaro.org


linux-next: Signed-off-by missing for commit in the drivers-x86 tree

2018-08-18 Thread Stephen Rothwell
Hi all,

Commit

  cda5915d15d3 ("platform/x86: touchscreen_dmi: Add info for the Cube KNote 
i1101 tablet")

is missing a Signed-off-by from its author.

-- 
Cheers,
Stephen Rothwell


pgpo0vHZOCf_2.pgp
Description: OpenPGP digital signature


Re: [PATCH] staging: rtl8188eu: Type cast function argument

2018-08-18 Thread zhong jiang
On 2018/8/18 22:24, Bhaskar Singh wrote:
> This patch might suppress some warrning.
>
> The function prototype of rtw_malloc2d is
>
> void *rtw_malloc2d(int h, int w, int size)
>
> This patch also resolves the checkpatch.pl warning
>
> WARNING: line over 80 characters
>
> Signed-off-by: Bhaskar Singh 
> ---
>  drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c 
> b/drivers/staging/rtl8188eu/core/rtw_efuse.c
> index 0fd306a808c4..735d654b2844 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
> @@ -91,7 +91,8 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 
> _size_byte, u8  *pbuf)
>   if (!efuseTbl)
>   return;
>  
> - eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E, 
> EFUSE_MAX_WORD_UNIT, sizeof(u16));
> + eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E,
> + EFUSE_MAX_WORD_UNIT, (int)sizeof(u16));
>  
  You should be align with left parenthesis.

 Thanks,
 zhong jiang
>   if (!eFuseWord) {
>   DBG_88E("%s: alloc eFuseWord fail!\n", __func__);
>   goto eFuseWord_failed;




linux-next: Signed-off-by missing for commit in the h8300 tree

2018-08-18 Thread Stephen Rothwell
Hi Yoshinori,

Commits

  785b0958b55d ("h8300: gcc-8.1 fix")
  8eabc2d5fae0 ("h8300: Add missing output register.")

are missing a Signed-off-by from their authors and committers.

Commit

  85f866b60ba7 ("h8300: switch to NO_BOOTMEM")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell


pgplIIMk9qtld.pgp
Description: OpenPGP digital signature


[PATCH] staging: rtl8188eu: Type cast function argument

2018-08-18 Thread Bhaskar Singh
This patch might suppress some warrning.

The function prototype of rtw_malloc2d is

void *rtw_malloc2d(int h, int w, int size)

This patch also resolves the checkpatch.pl warning

WARNING: line over 80 characters

Signed-off-by: Bhaskar Singh 
---
 drivers/staging/rtl8188eu/core/rtw_efuse.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_efuse.c 
b/drivers/staging/rtl8188eu/core/rtw_efuse.c
index 0fd306a808c4..735d654b2844 100644
--- a/drivers/staging/rtl8188eu/core/rtw_efuse.c
+++ b/drivers/staging/rtl8188eu/core/rtw_efuse.c
@@ -91,7 +91,8 @@ efuse_phymap_to_logical(u8 *phymap, u16 _offset, u16 
_size_byte, u8  *pbuf)
if (!efuseTbl)
return;
 
-   eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E, 
EFUSE_MAX_WORD_UNIT, sizeof(u16));
+   eFuseWord = (u16 **)rtw_malloc2d(EFUSE_MAX_SECTION_88E,
+   EFUSE_MAX_WORD_UNIT, (int)sizeof(u16));
if (!eFuseWord) {
DBG_88E("%s: alloc eFuseWord fail!\n", __func__);
goto eFuseWord_failed;
-- 
2.16.4



Re: [PATCH 4.18 00/22] 4.18.2-stable review

2018-08-18 Thread Rafael David Tinoco
On Thu, Aug 16, 2018 at 08:45:16PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.2 release.
> There are 22 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Aug 18 17:15:44 UTC 2018.
> Anything received after that time might be too late.
> 

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.18.3-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.18.y
git commit: d86e34a614bfd8fa7278945932dd87f18510611f
git describe: v4.18.2-2-gd86e34a614bf
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.2-2-gd86e34a614bf


No regressions (compared to build v4.18.1)


Ran 14019 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

AND

Summary


kernel: 4.18.3
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.18.y
git commit: 8a8c540db3ff1968317759961c0230221882367d
git describe: v4.18.3
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.3


No regressions (compared to build v4.18.1)


Ran 12427 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* kselftest
* libhugetlbfs
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH] Coccinelle: remove pci_alloc_consistent semantic to dectect in zalloc-simple.cocci

2018-08-18 Thread zhong jiang
On 2018/8/18 22:01, Julia Lawall wrote:
>
> On Sat, 18 Aug 2018, zhong jiang wrote:
>
>> On 2018/8/18 20:52, Himanshu Jha wrote:
>>> On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
 Because pci_alloc_consistent has been deprecated. We prefer to use
 dam_alloc_coherent directly. Therefore, we should remove 
 pci_alloc_consistent
>>>   ^^^ typo "dma"
>>>
>>> Also, typo in the patch subject "dectect" -> "detect"
>>  Thanks,  will fix it in v2.
>>> Otherwise,
>>>
>>> Acked-by: Himanshu Jha 
>>>
>>> Thanks for cleaning up, we still have few more *_alloc/memset
>>> in the mainline, especially in the scsi subsystem, even after
>>> I cleaned up with two long patch series in the past.
>>>
>>I post same patches like *_alloc/memset in the scsi subsystem. 
>> Unfortunately,
>>Maintainer maybe do not care about the change.  therefore,  None of my 
>> patches
>>   are received and rarely feedback.
> Maybe they will be picked up later.
 Hope so.  It's been more than a month since I post the patches. Maybe I should 
give a kindly ping. :-)

 Thanks,
 zhong jiang 
> julia
>
> .
>




Re: [PATCH 4.17 00/21] 4.17.16-stable review

2018-08-18 Thread Rafael David Tinoco
On Thu, Aug 16, 2018 at 08:45:10PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.16 release.
> There are 21 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat Aug 18 17:16:02 UTC 2018.
> Anything received after that time might be too late.

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.17.17-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.17.y
git commit: c3f554469fe42eddeaaef5f3992136828528f8ce
git describe: v4.17.16-2-gc3f554469fe4
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.17-oe/build/v4.17.16-2-gc3f554469fe4


No regressions (compared to build v4.17.15)


Ran 16701 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-fcntl-locktests-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

AND

Summary


kernel: 4.17.17
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.17.y
git commit: fa535b8a37597c80c0ac7d3669edccda9d91195b
git describe: v4.17.17
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.17-oe/build/v4.17.17


No regressions (compared to build v4.17.15)


Ran 7508 total tests in the following environments and test suites.

Environments
--
- hi6220-hikey - arm64
- qemu_arm64
- qemu_x86_64
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-cve-tests
* ltp-fs-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ltp-open-posix-tests

--
Linaro LKFT
https://lkft.linaro.org


[PATCHv2] Coccinelle: remove pci_alloc_consistent semantic to detect in zalloc-simple.cocci

2018-08-18 Thread zhong jiang
Because pci_alloc_consistent has been deprecated. We prefer to use
dma_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
to increase the confidence.

Acked-by: Julia Lawall 
Acked-by: Himanshu Jha 
Signed-off-by: zhong jiang 
---
v1->v2:
 - fix some spelling mistakes.  

 scripts/coccinelle/api/alloc/zalloc-simple.cocci | 41 +---
 1 file changed, 1 insertion(+), 40 deletions(-)

diff --git a/scripts/coccinelle/api/alloc/zalloc-simple.cocci 
b/scripts/coccinelle/api/alloc/zalloc-simple.cocci
index 92b2091..d819275 100644
--- a/scripts/coccinelle/api/alloc/zalloc-simple.cocci
+++ b/scripts/coccinelle/api/alloc/zalloc-simple.cocci
@@ -35,8 +35,7 @@ statement S;
 
 * x = (T)\(kmalloc(E1, ...)\|vmalloc(E1)\|dma_alloc_coherent(...,E1,...)\|
   kmalloc_node(E1, ...)\|kmem_cache_alloc(...)\|kmem_alloc(E1, ...)\|
-  devm_kmalloc(...,E1,...)\|kvmalloc(E1, 
...)\|pci_alloc_consistent(...,E1,...)\|
-  kvmalloc_node(E1,...)\);
+  devm_kmalloc(...,E1,...)\|kvmalloc(E1, ...)\|kvmalloc_node(E1,...)\);
   if ((x==NULL) || ...) S
 * memset((T2)x,0,E1);
 
@@ -124,15 +123,6 @@ statement S;
 - x = (T)kvmalloc(E1,E2);
 + x = (T)kvzalloc(E1,E2);
 |
-- x = pci_alloc_consistent(E2,E1,E3);
-+ x = pci_zalloc_consistent(E2,E1,E3);
-|
-- x = (T *)pci_alloc_consistent(E2,E1,E3);
-+ x = pci_zalloc_consistent(E2,E1,E3);
-|
-- x = (T)pci_alloc_consistent(E2,E1,E3);
-+ x = (T)pci_zalloc_consistent(E2,E1,E3);
-|
 - x = kvmalloc_node(E1,E2,E3);
 + x = kvzalloc_node(E1,E2,E3);
 |
@@ -389,35 +379,6 @@ msg="WARNING: kvzalloc should be used for %s, instead of 
kvmalloc/memset" % (x)
 coccilib.report.print_report(p[0], msg)
 
 //-
-@r8 depends on org || report@
-type T, T2;
-expression x;
-expression E1,E2,E3;
-statement S;
-position p;
-@@
-
- x = (T)pci_alloc_consistent@p(E2,E1,E3);
- if ((x==NULL) || ...) S
- memset((T2)x,0,E1);
-
-@script:python depends on org@
-p << r8.p;
-x << r8.x;
-@@
-
-msg="%s" % (x)
-msg_safe=msg.replace("[","@(").replace("]",")")
-coccilib.org.print_todo(p[0], msg_safe)
-
-@script:python depends on report@
-p << r8.p;
-x << r8.x;
-@@
-
-msg="WARNING: pci_zalloc_consistent should be used for %s, instead of 
pci_alloc_consistent/memset" % (x)
-coccilib.report.print_report(p[0], msg)
-//-
 @r9 depends on org || report@
 type T, T2;
 expression x;
-- 
1.7.12.4



Re: [PATCH] Coccinelle: remove pci_alloc_consistent semantic to dectect in zalloc-simple.cocci

2018-08-18 Thread Julia Lawall



On Sat, 18 Aug 2018, zhong jiang wrote:

> On 2018/8/18 20:52, Himanshu Jha wrote:
> > On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
> >> Because pci_alloc_consistent has been deprecated. We prefer to use
> >> dam_alloc_coherent directly. Therefore, we should remove 
> >> pci_alloc_consistent
> >   ^^^ typo "dma"
> >
> > Also, typo in the patch subject "dectect" -> "detect"
>  Thanks,  will fix it in v2.
> > Otherwise,
> >
> > Acked-by: Himanshu Jha 
> >
> > Thanks for cleaning up, we still have few more *_alloc/memset
> > in the mainline, especially in the scsi subsystem, even after
> > I cleaned up with two long patch series in the past.
> >
>I post same patches like *_alloc/memset in the scsi subsystem. 
> Unfortunately,
>Maintainer maybe do not care about the change.  therefore,  None of my 
> patches
>   are received and rarely feedback.

Maybe they will be picked up later.

julia


Re: [PATCH] Coccinelle: remove pci_alloc_consistent semantic to dectect in zalloc-simple.cocci

2018-08-18 Thread zhong jiang
On 2018/8/18 20:52, Himanshu Jha wrote:
> On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
>> Because pci_alloc_consistent has been deprecated. We prefer to use
>> dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
>   ^^^ typo "dma"
>
> Also, typo in the patch subject "dectect" -> "detect"
 Thanks,  will fix it in v2.
> Otherwise,
>
> Acked-by: Himanshu Jha 
>
> Thanks for cleaning up, we still have few more *_alloc/memset
> in the mainline, especially in the scsi subsystem, even after
> I cleaned up with two long patch series in the past.
>
   I post same patches like *_alloc/memset in the scsi subsystem. Unfortunately,
   Maintainer maybe do not care about the change.  therefore,  None of my 
patches
  are received and rarely feedback.

 Thanks,
 zhong jiang



Lieber Freund

2018-08-18 Thread Angela Sanderson
Lieber Freund

Mein Name ist Angela Sanderson, ich bin 78 Jahre Original aus Island,
aber ich lebe in Manchester City im Vereinigten Königreich. Ich verlor
meinen Mann seit 2016, ohne Kind. Bitte ich brauche Ihre Hilfe, ich
bin ein Krebspatient .on 17/7 / 2018 diagnostizierte der Arzt Dr.
Mervyn Davies im St. James Universitätskrankenhaus meinen Krebs und
bestätigte, dass ich aufgrund schwerer Krebserkrankungen nur noch drei
Monate habe, um wieder zu leben. Ich kontaktierte Sie, weil ich
möchte, dass Sie mir helfen, eine humanitäre Arbeit der Nächstenliebe
zu leisten Ich habe ein Konto bei der UBS Investment Bank London im
Wert von 1,6 Millionen Pfund Sterling (1.600.000,00 GBP), die ich für
wohltätige Zwecke zu Hause und in der Kirche spenden möchte. Ich habe
mich entschieden, dich zu kontaktieren, um mir aus Gründen der
Menschlichkeit zu helfen, und ich bin zuversichtlich und glaube, dass
du mir bei dieser letzten Arbeit auf der Erde hilfst. Auf deine
Antwort werde ich der Bank eine Vollmacht ausstellen, die dir die
Gegenwart beweisen wird Nutznießer dieses Geldes, um mit menschlicher
Arbeit fortzufahren. Auf Ihre Antwort werde ich Ihnen mehr Details
geben


Re: [GIT PULL] RISC-V Updates for the 4.19 Merge Window

2018-08-18 Thread Guenter Roeck
Hi Palmer,

On Fri, Aug 17, 2018 at 01:28:11PM -0700, Palmer Dabbelt wrote:
[ ... ]

> 
> This tag boots a Fedora root filesystem on QEMU's master branch for me,
> and before this morning's rebase (from 4.18-rc8 to 4.18) it booted on
> the HiFive Unleashed.
> 

Do you have vmlinux embedded in bbl ?

With separate bbl and vmlinux, and the following qemu command line 
(with qemu 3.0)

qemu-system-riscv64 -M virt -m 512M -no-reboot \
-bios bbl -kernel vmlinux \
-netdev user,id=net0 -device virtio-net-device,netdev=net0 \
-device virtio-blk-device,drive=d0 \
-drive file=rootfs.ext2,if=none,id=d0,format=raw \
-append 'root=/dev/vda rw console=ttyS0,115200' \
-nographic -monitor none

all I get is

rom: requested regions overlap (rom mrom.reset. free=0x0001cbe8, 
addr=0x1000)

However, the she system boots fine with the same qemu command line if I use qemu
built from https://github.com/riscv/riscv-qemu.git, branch qemu-for-upstream.

Excellent - once this series hits mainline, I'll add riscv to my
boot tests.

Thanks,
Guenter


[PATCH v2 2/8] seq_file: use seq_open_data in single_open

2018-08-18 Thread Rasmus Villemoes
Avoid the somewhat hard to grok assignment by using the seq_open_data
helper.

Signed-off-by: Rasmus Villemoes 
---
 fs/seq_file.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/seq_file.c b/fs/seq_file.c
index c8c86660f6db..518a72e444d9 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -582,10 +582,8 @@ int single_open(struct file *file, int (*show)(struct 
seq_file *, void *),
op->next = single_next;
op->stop = single_stop;
op->show = show;
-   res = seq_open(file, op);
-   if (!res)
-   ((struct seq_file *)file->private_data)->private = data;
-   else
+   res = seq_open_data(file, op, data);
+   if (res)
kfree(op);
}
return res;
-- 
2.16.4



[PATCH v2 3/8] seq_file: use seq_open_data in __seq_open_private

2018-08-18 Thread Rasmus Villemoes
Signed-off-by: Rasmus Villemoes 
---
 fs/seq_file.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/fs/seq_file.c b/fs/seq_file.c
index 518a72e444d9..5cc4670294e7 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -632,18 +632,15 @@ void *__seq_open_private(struct file *f, const struct 
seq_operations *ops,
 {
int rc;
void *private;
-   struct seq_file *seq;
 
private = kzalloc(psize, GFP_KERNEL_ACCOUNT);
if (private == NULL)
goto out;
 
-   rc = seq_open(f, ops);
+   rc = seq_open_data(f, ops, private);
if (rc < 0)
goto out_free;
 
-   seq = f->private_data;
-   seq->private = private;
return private;
 
 out_free:
-- 
2.16.4



[PATCH v2 4/8] proc: use seq_open_data() in proc_id_map_open()

2018-08-18 Thread Rasmus Villemoes
Simplify the code slightly by using the seq_open_data helper.

Signed-off-by: Rasmus Villemoes 
---
Depends on 1/8 introducing seq_open_data.

fs/proc/base.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index aaffc0c30216..32ed72c44412 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2747,7 +2747,6 @@ static int proc_id_map_open(struct inode *inode, struct 
file *file,
 {
struct user_namespace *ns = NULL;
struct task_struct *task;
-   struct seq_file *seq;
int ret = -EINVAL;
 
task = get_proc_task(inode);
@@ -2758,19 +2757,11 @@ static int proc_id_map_open(struct inode *inode, struct 
file *file,
put_task_struct(task);
}
if (!ns)
-   goto err;
+   return ret;
 
-   ret = seq_open(file, seq_ops);
+   ret = seq_open_data(file, seq_ops, ns);
if (ret)
-   goto err_put_ns;
-
-   seq = file->private_data;
-   seq->private = ns;
-
-   return 0;
-err_put_ns:
-   put_user_ns(ns);
-err:
+   put_user_ns(ns);
return ret;
 }
 
-- 
2.16.4



[PATCH v2 5/8] nfsd: use seq_open_data() in exports_net_open()

2018-08-18 Thread Rasmus Villemoes
Using the seq_open_data() helper, exports_net_open() essentially becomes
a oneliner.

Signed-off-by: Rasmus Villemoes 
---
Depends on 1/8 introducing seq_open_data.

fs/nfsd/nfsctl.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
index d107b4426f7e..483a849b9ce1 100644
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -135,17 +135,9 @@ static const struct file_operations transaction_ops = {
 
 static int exports_net_open(struct net *net, struct file *file)
 {
-   int err;
-   struct seq_file *seq;
struct nfsd_net *nn = net_generic(net, nfsd_net_id);
 
-   err = seq_open(file, _exports_op);
-   if (err)
-   return err;
-
-   seq = file->private_data;
-   seq->private = nn->svc_export_cache;
-   return 0;
+   return seq_open_data(file, _exports_op, nn->svc_export_cache);
 }
 
 static int exports_proc_open(struct inode *inode, struct file *file)
-- 
2.16.4



[PATCH v2 8/8] PCI: tegra: use seq_open_data

2018-08-18 Thread Rasmus Villemoes
Simplify the code slightly by having seq_open_data do the ->private
assignment.

Signed-off-by: Rasmus Villemoes 
---
Depends on 1/8 introducing seq_open_data.

Not including Thierry's ack/reviewed-by since it's been half a year since v1.

 drivers/pci/controller/pci-tegra.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/pci/controller/pci-tegra.c 
b/drivers/pci/controller/pci-tegra.c
index f4f53d092e00..e436db8cfe2e 100644
--- a/drivers/pci/controller/pci-tegra.c
+++ b/drivers/pci/controller/pci-tegra.c
@@ -2302,17 +2302,8 @@ static const struct seq_operations 
tegra_pcie_ports_seq_ops = {
 static int tegra_pcie_ports_open(struct inode *inode, struct file *file)
 {
struct tegra_pcie *pcie = inode->i_private;
-   struct seq_file *s;
-   int err;
-
-   err = seq_open(file, _pcie_ports_seq_ops);
-   if (err)
-   return err;
-
-   s = file->private_data;
-   s->private = pcie;
 
-   return 0;
+   return seq_open_data(file, _pcie_ports_seq_ops, pcie);
 }
 
 static const struct file_operations tegra_pcie_ports_ops = {
-- 
2.16.4



[PATCH 2/7] linux/bitmap.h: handle constant zero-size bitmaps correctly

2018-08-18 Thread Rasmus Villemoes
The static inlines in bitmap.h do not handle a compile-time constant
nbits==0 correctly (they dereference the passed src or dst pointers,
despite only 0 words being valid to access). I had the 0-day buildbot
chew on a patch [1] that would cause build failures for such cases
without complaining, suggesting that we don't have any such users
currently, at least for the 70 .config/arch combinations that was
built. Should any turn up, make sure they use the out-of-line versions,
which do handle nbits==0 correctly.

This is of course not the most efficient, but it's much less churn than
teaching all the static inlines an "if (zero_const_nbits())", and since
we don't have any current instances, this doesn't affect existing code
at all.

[1] lkml.kernel.org/r/20180815085539.27485-1-li...@rasmusvillemoes.dk

Signed-off-by: Rasmus Villemoes 
---
 include/linux/bitmap.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 1ee46f492267..b91a6b5d3e78 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -196,8 +196,13 @@ extern int bitmap_print_to_pagebuf(bool list, char *buf,
 #define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 1)))
 #define BITMAP_LAST_WORD_MASK(nbits) (~0UL >> (-(nbits) & (BITS_PER_LONG - 1)))
 
+/*
+ * The static inlines below do not handle constant nbits==0 correctly,
+ * so make such users (should any ever turn up) call the out-of-line
+ * versions.
+ */
 #define small_const_nbits(nbits) \
-   (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG)
+   (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG && (nbits) > 0)
 
 static inline void bitmap_zero(unsigned long *dst, unsigned int nbits)
 {
-- 
2.16.4



[PATCH 4/7] linux/bitmap.h: fix type of nbits in bitmap_shift_right()

2018-08-18 Thread Rasmus Villemoes
Most other bitmap API, including the OOL version __bitmap_shift_right,
take unsigned nbits. This was accidentally left out from 2fbad29917c98.

Fixes: 2fbad29917c98 (lib: bitmap: change bitmap_shift_right to take unsigned 
parameters)
Reported-by: Yury Norov 
Signed-off-by: Rasmus Villemoes 
---
 include/linux/bitmap.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index a7a8b5017d62..e34c361f4a92 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -383,7 +383,7 @@ static __always_inline void bitmap_clear(unsigned long 
*map, unsigned int start,
 }
 
 static inline void bitmap_shift_right(unsigned long *dst, const unsigned long 
*src,
-   unsigned int shift, int nbits)
+   unsigned int shift, unsigned int nbits)
 {
if (small_const_nbits(nbits))
*dst = (*src & BITMAP_LAST_WORD_MASK(nbits)) >> shift;
-- 
2.16.4



[PATCH 5/7] linux/bitmap.h: relax comment on compile-time constant nbits

2018-08-18 Thread Rasmus Villemoes
It's not clear what's so horrible about emitting a function call to
handle a run-time sized bitmap. Moreover, gcc also emits a function call
for a compile-time-constant-but-huge nbits, so the comment isn't even
accurate.

Signed-off-by: Rasmus Villemoes 
---
 include/linux/bitmap.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index e34c361f4a92..3f0cac3aedca 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -28,8 +28,8 @@
  * The available bitmap operations and their rough meaning in the
  * case that the bitmap is a single unsigned long are thus:
  *
- * Note that nbits should be always a compile time evaluable constant.
- * Otherwise many inlines will generate horrible code.
+ * The generated code is more efficient when nbits is known at
+ * compile-time and at most BITS_PER_LONG.
  *
  * ::
  *
-- 
2.16.4



[PATCH 3/7] linux/bitmap.h: remove redundant uses of small_const_nbits()

2018-08-18 Thread Rasmus Villemoes
In the _zero, _fill and _copy functions, the small_const_nbits
branch is redundant. If nbits is small and const, gcc knows full well
that BITS_TO_LONGS(nbits) is 1, so len is also a compile-time
constant (sizeof(long)), and calling memset or memcpy with a length
argument of sizeof(long) makes gcc generate the expected code anyway:

#include 
void a(unsigned long *x) { memset(x, 0, 8); }
void b(unsigned long *x) { memset(x, 0xff, 8); }
void c(unsigned long *x, const unsigned long *y) { memcpy(x, y, 8); }

turns into

 :
   0:   48 c7 07 00 00 00 00movq   $0x0,(%rdi)
   7:   c3  retq
   8:   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
   f:   00

0010 :
  10:   48 c7 07 ff ff ff ffmovq   $0x,(%rdi)
  17:   c3  retq
  18:   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
  1f:   00

0020 :
  20:   48 8b 06mov(%rsi),%rax
  23:   48 89 07mov%rax,(%rdi)
  26:   c3  retq

Signed-off-by: Rasmus Villemoes 
---
 include/linux/bitmap.h | 24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index b91a6b5d3e78..a7a8b5017d62 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -206,33 +206,21 @@ extern int bitmap_print_to_pagebuf(bool list, char *buf,
 
 static inline void bitmap_zero(unsigned long *dst, unsigned int nbits)
 {
-   if (small_const_nbits(nbits))
-   *dst = 0UL;
-   else {
-   unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
-   memset(dst, 0, len);
-   }
+   unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
+   memset(dst, 0, len);
 }
 
 static inline void bitmap_fill(unsigned long *dst, unsigned int nbits)
 {
-   if (small_const_nbits(nbits))
-   *dst = ~0UL;
-   else {
-   unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
-   memset(dst, 0xff, len);
-   }
+   unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
+   memset(dst, 0xff, len);
 }
 
 static inline void bitmap_copy(unsigned long *dst, const unsigned long *src,
unsigned int nbits)
 {
-   if (small_const_nbits(nbits))
-   *dst = *src;
-   else {
-   unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
-   memcpy(dst, src, len);
-   }
+   unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
+   memcpy(dst, src, len);
 }
 
 /*
-- 
2.16.4



[PATCH 7/7] lib/bitmap.c: simplify bitmap_print_to_pagebuf

2018-08-18 Thread Rasmus Villemoes
len is guaranteed to lie in [1, PAGE_SIZE]. If scnprintf is called with
a buffer size of 1, it is guaranteed to return 0. So in the extremely
unlikely case of having just one byte remaining in the page, let's just
call scnprintf anyway. The only difference is that this will write a
'\0' to that final byte in the page, but that's an improvement: We now
guarantee that after the call, buf is a properly terminated C string of
length exactly the return value.

Signed-off-by: Rasmus Villemoes 
---
 lib/bitmap.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 277c9a63a5ab..75175da01fd8 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -469,12 +469,9 @@ int bitmap_print_to_pagebuf(bool list, char *buf, const 
unsigned long *maskp,
int nmaskbits)
 {
ptrdiff_t len = PAGE_SIZE - ((unsigned long)buf & (PAGE_SIZE-1));
-   int n = 0;
 
-   if (len > 1)
-   n = list ? scnprintf(buf, len, "%*pbl\n", nmaskbits, maskp) :
-  scnprintf(buf, len, "%*pb\n", nmaskbits, maskp);
-   return n;
+   return list ? scnprintf(buf, len, "%*pbl\n", nmaskbits, maskp) :
+ scnprintf(buf, len, "%*pb\n", nmaskbits, maskp);
 }
 EXPORT_SYMBOL(bitmap_print_to_pagebuf);
 
-- 
2.16.4



[PATCH 6/7] lib/bitmap.c: fix remaining space computation in bitmap_print_to_pagebuf

2018-08-18 Thread Rasmus Villemoes
For various alignments of buf, the current expression computes

4096 ok
4095 ok
8190
8189
...
4097

i.e., if the caller has already written two bytes into the page buffer,
len is 8190 rather than 4094, because PTR_ALIGN aligns up to the next
boundary. So if the printed version of the bitmap is huge, scnprintf()
ends up writing beyond the page boundary.

I don't think any current callers actually write anything before
bitmap_print_to_pagebuf, but the API seems to be designed to allow it.

Signed-off-by: Rasmus Villemoes 
---
 lib/bitmap.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 1f73b2e52186..277c9a63a5ab 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -460,14 +460,15 @@ EXPORT_SYMBOL(bitmap_parse_user);
  * ranges if list is specified or hex digits grouped into comma-separated
  * sets of 8 digits/set. Returns the number of characters written to buf.
  *
- * It is assumed that @buf is a pointer into a PAGE_SIZE area and that
- * sufficient storage remains at @buf to accommodate the
- * bitmap_print_to_pagebuf() output.
+ * It is assumed that @buf is a pointer into a PAGE_SIZE, page-aligned
+ * area and that sufficient storage remains at @buf to accommodate the
+ * bitmap_print_to_pagebuf() output. Returns the number of characters
+ * actually printed to @buf, excluding terminating '\0'.
  */
 int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp,
int nmaskbits)
 {
-   ptrdiff_t len = PTR_ALIGN(buf + PAGE_SIZE - 1, PAGE_SIZE) - buf;
+   ptrdiff_t len = PAGE_SIZE - ((unsigned long)buf & (PAGE_SIZE-1));
int n = 0;
 
if (len > 1)
-- 
2.16.4



[PATCH 0/7] assorted minor bitmap patches

2018-08-18 Thread Rasmus Villemoes
A recent LKML thread had me look into bitmap.{h,c} again, and I
stumbled on/rediscovered a few things.

Rasmus Villemoes (7):
  lib/bitmap.c: remove wrong documentation
  linux/bitmap.h: handle constant zero-size bitmaps correctly
  linux/bitmap.h: remove redundant uses of small_const_nbits()
  linux/bitmap.h: fix type of nbits in bitmap_shift_right()
  linux/bitmap.h: relax comment on compile-time constant nbits
  lib/bitmap.c: fix remaining space computation in
bitmap_print_to_pagebuf
  lib/bitmap.c: simplify bitmap_print_to_pagebuf

 include/linux/bitmap.h | 37 +++--
 lib/bitmap.c   | 21 +++--
 2 files changed, 22 insertions(+), 36 deletions(-)

-- 
2.16.4



[PATCH 1/7] lib/bitmap.c: remove wrong documentation

2018-08-18 Thread Rasmus Villemoes
This promise is violated in a number of places, e.g. already in the
second function below this paragraph. Since I don't think anybody relies
on this being true, and since actually honouring it would hurt
performance and code size in various places, just remove the paragraph.

Signed-off-by: Rasmus Villemoes 
---
 lib/bitmap.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 58f9750e49c6..1f73b2e52186 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -35,11 +35,6 @@
  * carefully filter out these unused bits from impacting their
  * results.
  *
- * These operations actually hold to a slightly stronger rule:
- * if you don't input any bitmaps to these ops that have some
- * unused bits set, then they won't output any set unused bits
- * in output bitmaps.
- *
  * The byte ordering of bitmaps is more natural on little
  * endian architectures.  See the big-endian headers
  * include/asm-ppc64/bitops.h and include/asm-s390/bitops.h
-- 
2.16.4



Re: [PATCH RESEND v1 2/5] drivers: pinctrl: msm: enable PDC interrupt only during suspend

2018-08-18 Thread Marc Zyngier
Hi Lina,

On Fri, 17 Aug 2018 20:10:23 +0100,
Lina Iyer  wrote:
> 
> During suspend the system may power down some of the system rails. As a
> result, the TLMM hw block may not be operational anymore and wakeup
> capable GPIOs will not be detected. The PDC however will be operational
> and the GPIOs that are routed to the PDC as IRQs can wake the system up.
> 
> To avoid being interrupted twice (for TLMM and once for PDC IRQ) when a
> GPIO trips, use TLMM for active and switch to PDC for suspend. When
> entering suspend, disable the TLMM wakeup interrupt and instead enable
> the PDC IRQ and revert upon resume.
> 
> Signed-off-by: Lina Iyer 
> ---
>  drivers/pinctrl/qcom/pinctrl-msm.c | 60 +-
>  drivers/pinctrl/qcom/pinctrl-msm.h |  3 ++
>  2 files changed, 62 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 03ef1d29d078..17e541f8f09d 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -37,6 +37,7 @@
>  #include "../pinctrl-utils.h"
>  
>  #define MAX_NR_GPIO 300
> +#define MAX_PDC_IRQ 1024

Where is this value coming from? Is it guaranteed to be an
architectural maximum? Or something that is likely to vary in future
implementations?

>  #define PS_HOLD_OFFSET 0x820
>  
>  /**
> @@ -51,6 +52,7 @@
>   * @enabled_irqs:   Bitmap of currently enabled irqs.
>   * @dual_edge_irqs: Bitmap of irqs that need sw emulated dual edge
>   *  detection.
> + * @pdc_irqs:   Bitmap of wakeup capable irqs.
>   * @soc;Reference to soc_data of platform specific data.
>   * @regs:   Base address for the TLMM register map.
>   */
> @@ -68,11 +70,14 @@ struct msm_pinctrl {
>  
>   DECLARE_BITMAP(dual_edge_irqs, MAX_NR_GPIO);
>   DECLARE_BITMAP(enabled_irqs, MAX_NR_GPIO);
> + DECLARE_BITMAP(pdc_irqs, MAX_PDC_IRQ);
>  
>   const struct msm_pinctrl_soc_data *soc;
>   void __iomem *regs;
>  };
>  
> +static bool in_suspend;
> +
>  static int msm_get_groups_count(struct pinctrl_dev *pctldev)
>  {
>   struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
> @@ -787,8 +792,11 @@ static int msm_gpio_irq_set_wake(struct irq_data *d, 
> unsigned int on)
>  
>   raw_spin_lock_irqsave(>lock, flags);
>  
> - if (pdc_irqd)
> + if (pdc_irqd && !in_suspend) {
>   irq_set_irq_wake(pdc_irqd->irq, on);
> + on ? set_bit(pdc_irqd->irq, pctrl->pdc_irqs) :
> +  clear_bit(pdc_irqd->irq, pctrl->pdc_irqs);

I think we'll all survive the two extra lines if you write this as an
'if' statement (unless you're competing for the next IOCCC, and then
you need to up your game a bit).

Also, are you indexing the bitmap using a Linux irq number? If so,
that's an absolute NACK. Out of the box, a Linux IRQ can be up to
NR_IRQS+8196 on arm64, and there are plans to push that to be a much
larger space.

> + }
>  
>   irq_set_irq_wake(pctrl->irq, on);

I'm a bit worried by the way you call into the irq subsystem with this
spinlock held. Have you run that code with lockdep enabled?

>  
> @@ -920,6 +928,8 @@ static int msm_gpio_pdc_pin_request(struct irq_data *d)
>   }
>  
>   irq_set_handler_data(d->irq, irq_get_irq_data(irq));
> + irq_set_handler_data(irq, d);
> + irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY);

Could you explain what this is trying to do? I'm trying to understand
this code, but this function isn't in 4.18...

>   disable_irq(irq);
>  
>   return 0;
> @@ -1070,6 +1080,54 @@ static void msm_pinctrl_setup_pm_reset(struct 
> msm_pinctrl *pctrl)
>   }
>  }
>  
> +int __maybe_unused msm_pinctrl_suspend_late(struct device *dev)
> +{
> + struct msm_pinctrl *pctrl = dev_get_drvdata(dev);
> + struct irq_data *irqd;
> + int i;
> +
> + in_suspend = true;
> + for_each_set_bit(i, pctrl->pdc_irqs, MAX_PDC_IRQ) {
> + irqd = irq_get_handler_data(i);

So this is what I though. You're using the Linux IRQ, and not the pin
number (or whatever HW-dependent index that would otherwise make
sense). Please fix it.

> + /*
> +  * We don't know if the TLMM will be functional
> +  * or not, during the suspend. If its functional,
> +  * we do not want duplicate interrupts from PDC.
> +  * Hence disable the GPIO IRQ and enable PDC IRQ.
> +  */
> + if (irqd_is_wakeup_set(irqd)) {
> + irq_set_irq_wake(irqd->irq, false);
> + disable_irq(irqd->irq);
> + enable_irq(i);
> + }
> + }
> +
> + return 0;
> +}
> +
> +int __maybe_unused msm_pinctrl_resume_late(struct device *dev)
> +{
> + struct msm_pinctrl *pctrl = dev_get_drvdata(dev);
> + struct irq_data *irqd;
> + int i;
> +
> + for_each_set_bit(i, pctrl->pdc_irqs, MAX_PDC_IRQ) {
> + irqd = 

Re: [BUG v4.14-rt] kernel BUG at /work/rt/stable-rt.git/kernel/sched/core.c:1639!

2018-08-18 Thread Mike Galbraith
On Sat, 2018-08-18 at 12:29 +0200, Mike Galbraith wrote:
> On Fri, 2018-08-17 at 16:23 -0400, Steven Rostedt wrote:
> > Pulling in stable releases into v4.14-rt I triggered this with my CPU
> > hotplug test:
> > 
> > [ cut here ]
> > kernel BUG at /work/rt/stable-rt.git/kernel/sched/core.c:1639!
> > invalid opcode:  [#1] PREEMPT SMP PTI
> > Modules linked in: sunrpc ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 
> > nf_defrag_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_idt 
> > snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep 
> > snd_seq snd_seq_device snd_pcm snd_timer snd shpchp i2c_i801 soundcore 
> > floppy i915 drm_kms_helper drm fb_sys_fops sysimgblt sysfillrect 
> > syscopyarea i2c_algo_bit iosf_mbi video [last unloaded: speedstep_lib]
> > CPU: 1 PID: 2944 Comm: mkdumprd Not tainted 4.14.63-test-rt40+ #782
> > Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled 
> > by O.E.M., BIOS SDBLI944.86P 05/08/2007
> > task: 880037888d80 task.stack: c9538000
> > RIP: 0010:select_fallback_rq+0xc3/0x122
> 
> I noticed this upstream, and had started hunting for the origin, but
> had thought that 4.14-rt was OK.  Clearly not the case, but it's not
> 4.14.60.. stable changes interacting badly either, virgin 4.14.59-rt37
> just reproduced in a vm clone of my workstation.

4.15.18-rt37 (4.14-rt rolled forward) does not reproduce, nor does
4.16.18-rt12, but 4.17.0-rt5 (v4.16.12-rt5 rolled forward) does, so
seems it has be something from the 4.17 cycle that went back to 4.14-
stable after 4.1[56]-stable trees went extinct.

-Mike


Re: [PATCH v2] ASoC: tegra: probe deferral error reporting

2018-08-18 Thread Stefan Agner
On 15.08.2018 18:02, Jon Hunter wrote:
> On 14/08/18 15:01, Marcel Ziswiler wrote:
>> From: Marcel Ziswiler 
>>
>> Actually report the error codes from of_get_named_gpio() resp.
>> devm_gpio_request_one() upon trying to get the codec reset resp. sync
>> GPIOs unless it is just a probe deferral.
>>
>> Signed-off-by: Marcel Ziswiler 
>>
>> ---
>>
>> Changes in v2:
>> - Silence probe deferral as suggested by Stefan.
>> - Fix line over 80 characters as reported by checkpatch.
>>
>>  sound/soc/tegra/tegra20_ac97.c | 19 ---
>>  1 file changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/sound/soc/tegra/tegra20_ac97.c b/sound/soc/tegra/tegra20_ac97.c
>> index 682ef33afb5f..2ac6b2d73980 100644
>> --- a/sound/soc/tegra/tegra20_ac97.c
>> +++ b/sound/soc/tegra/tegra20_ac97.c
>> @@ -351,18 +351,31 @@ static int tegra20_ac97_platform_probe(struct 
>> platform_device *pdev)
>>  ret = devm_gpio_request_one(>dev, ac97->reset_gpio,
>>  GPIOF_OUT_INIT_HIGH, "codec-reset");
>>  if (ret) {
>> -dev_err(>dev, "could not get codec-reset GPIO\n");
>> +if (ret != -EPROBE_DEFER)
>> +dev_err(>dev,
>> +"could not get codec-reset GPIO: %d\n",
>> +ret);
>> +
>>  goto err_clk_put;
>>  }
>>  } else {
>> -dev_err(>dev, "no codec-reset GPIO supplied\n");
>> +ret = ac97->reset_gpio;
>> +if (ret != -EPROBE_DEFER)
>> +dev_err(>dev,
>> +"no codec-reset GPIO supplied: %d\n",
>> +ret);
>> +
>>  goto err_clk_put;
>>  }
>>
>>  ac97->sync_gpio = of_get_named_gpio(pdev->dev.of_node,
>>  "nvidia,codec-sync-gpio", 0);
>>  if (!gpio_is_valid(ac97->sync_gpio)) {
>> -dev_err(>dev, "no codec-sync GPIO supplied\n");
>> +ret = ac97->sync_gpio;
>> +if (ret != -EPROBE_DEFER)
>> +dev_err(>dev, "no codec-sync GPIO supplied: %d\n",
>> +ret);
>> +
>>  goto err_clk_put;
>>  }
> 
> Thanks, looks good to me. However, I wonder why we don't request the
> 'sync_gpio' in the probe like we do for the reset? Otherwise ...

The comment in tegra20_ac97_codec_warm_reset() is probably the reason:

/*
 * although sync line is driven by the DAC pad group warm reset using
 * the controller cmd is not working, have to toggle sync line
 * manually.
 */

I guess the GPIO need to be freed so that the DAC pad group can use the
sync line?

> 
> Acked-by: Jon Hunter 

Also looks good to me:

Reviewed-by: Stefan Agner 

--
Stefan


Re: [PATCH] Coccinelle: remove pci_alloc_consistent semantic to dectect in zalloc-simple.cocci

2018-08-18 Thread Himanshu Jha
On Sat, Aug 18, 2018 at 08:01:40PM +0800, zhong jiang wrote:
> Because pci_alloc_consistent has been deprecated. We prefer to use
> dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
  ^^^ typo "dma"

Also, typo in the patch subject "dectect" -> "detect"

Otherwise,

Acked-by: Himanshu Jha 

Thanks for cleaning up, we still have few more *_alloc/memset
in the mainline, especially in the scsi subsystem, even after
I cleaned up with two long patch series in the past.

-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology


Re: [BUG]smt sysfs dir missing on 4.4.148 and 4.14.63

2018-08-18 Thread Thomas Gleixner
On Fri, 17 Aug 2018, Greg Kroah-Hartman wrote:
> On Fri, Aug 17, 2018 at 02:39:00PM +0200, Jinpu Wang wrote:
> >
> > I found the problem, CONFIG_HOTPLUG_SMT is enable due to CONFIG_SMP,
> > but I did explicitly enable CONFIG_HOTPLUG_CPU.
> > 
> > That's why the smt dir is missing, and kernel panic when I boot with
> > 'nosmt' or 'l1tf=full' probably also other combination.
> > 
> > With CONFIG_HOTPLUG_CPU=y, it works fine so far.
> 
> So do we need a new configuration dependancy here to resolve this
> problem?  Why is this not an issue in Linus's tree?

That's probably the same problem on Linus tree. Have not tested it yet
though. I'll have a look.

Thanks,

tglx



Re: [PATCH v4 1/4] edac: synps: Add platform specific structures for ddrc controller

2018-08-18 Thread Borislav Petkov
On Sat, Aug 18, 2018 at 10:11:54AM +, Manish Narani wrote:
> Ping.

First of all, one ping is enough. If your patchset contained, say, 30
patches, were you really going to send a ping for each one of them?!?!?!

Secondly, you do know that we have merge window right now, don't you?

And during the merge window, people are busy with merge window testing
and sending stuff which is ready, upstream - not reviewing new code
which has absolutely no chance of going in now?

Jeez.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--


Re: [PATCH v2] clk: tegra: probe deferral error reporting

2018-08-18 Thread Stefan Agner
On 14.08.2018 11:18, Marcel Ziswiler wrote:
> From: Marcel Ziswiler 
> 
> Actually report the error code from devm_regulator_get() which may as
> well just be a probe deferral.
> 
> Signed-off-by: Marcel Ziswiler 

Reviewed-by: Stefan Agner 

> 
> ---
> 
> Changes in v2:
> - Silence probe deferral as discussed between Peter, Stefan and Stephen.
> - Fix line over 80 characters as reported by checkpatch.
> 
>  drivers/clk/tegra/clk-dfll.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
> index 48ee43734e05..ebb0e1b6bf01 100644
> --- a/drivers/clk/tegra/clk-dfll.c
> +++ b/drivers/clk/tegra/clk-dfll.c
> @@ -1609,8 +1609,12 @@ int tegra_dfll_register(struct platform_device *pdev,
>  
>   td->vdd_reg = devm_regulator_get(td->dev, "vdd-cpu");
>   if (IS_ERR(td->vdd_reg)) {
> - dev_err(td->dev, "couldn't get vdd_cpu regulator\n");
> - return PTR_ERR(td->vdd_reg);
> + ret = PTR_ERR(td->vdd_reg);
> + if (ret != -EPROBE_DEFER)
> + dev_err(td->dev, "couldn't get vdd_cpu regulator: %d\n",
> + ret);
> +
> + return ret;
>   }
>  
>   td->dvco_rst = devm_reset_control_get(td->dev, "dvco");


Re: [PATCH] Coccinelle: remove pci_alloc_consistent semantic to dectect in zalloc-simple.cocci

2018-08-18 Thread Julia Lawall



On Sat, 18 Aug 2018, zhong jiang wrote:

> Because pci_alloc_consistent has been deprecated. We prefer to use
> dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
> to increase the confidence.
>
> Signed-off-by: zhong jiang 

Thanks for the suggestion.

Acked-by: Julia Lawall 

> ---
>  scripts/coccinelle/api/alloc/zalloc-simple.cocci | 41 
> +---
>  1 file changed, 1 insertion(+), 40 deletions(-)
>
> diff --git a/scripts/coccinelle/api/alloc/zalloc-simple.cocci 
> b/scripts/coccinelle/api/alloc/zalloc-simple.cocci
> index 92b2091..d819275 100644
> --- a/scripts/coccinelle/api/alloc/zalloc-simple.cocci
> +++ b/scripts/coccinelle/api/alloc/zalloc-simple.cocci
> @@ -35,8 +35,7 @@ statement S;
>
>  * x = (T)\(kmalloc(E1, ...)\|vmalloc(E1)\|dma_alloc_coherent(...,E1,...)\|
>kmalloc_node(E1, ...)\|kmem_cache_alloc(...)\|kmem_alloc(E1, ...)\|
> -  devm_kmalloc(...,E1,...)\|kvmalloc(E1, 
> ...)\|pci_alloc_consistent(...,E1,...)\|
> -  kvmalloc_node(E1,...)\);
> +  devm_kmalloc(...,E1,...)\|kvmalloc(E1, ...)\|kvmalloc_node(E1,...)\);
>if ((x==NULL) || ...) S
>  * memset((T2)x,0,E1);
>
> @@ -124,15 +123,6 @@ statement S;
>  - x = (T)kvmalloc(E1,E2);
>  + x = (T)kvzalloc(E1,E2);
>  |
> -- x = pci_alloc_consistent(E2,E1,E3);
> -+ x = pci_zalloc_consistent(E2,E1,E3);
> -|
> -- x = (T *)pci_alloc_consistent(E2,E1,E3);
> -+ x = pci_zalloc_consistent(E2,E1,E3);
> -|
> -- x = (T)pci_alloc_consistent(E2,E1,E3);
> -+ x = (T)pci_zalloc_consistent(E2,E1,E3);
> -|
>  - x = kvmalloc_node(E1,E2,E3);
>  + x = kvzalloc_node(E1,E2,E3);
>  |
> @@ -389,35 +379,6 @@ msg="WARNING: kvzalloc should be used for %s, instead of 
> kvmalloc/memset" % (x)
>  coccilib.report.print_report(p[0], msg)
>
>  //-
> -@r8 depends on org || report@
> -type T, T2;
> -expression x;
> -expression E1,E2,E3;
> -statement S;
> -position p;
> -@@
> -
> - x = (T)pci_alloc_consistent@p(E2,E1,E3);
> - if ((x==NULL) || ...) S
> - memset((T2)x,0,E1);
> -
> -@script:python depends on org@
> -p << r8.p;
> -x << r8.x;
> -@@
> -
> -msg="%s" % (x)
> -msg_safe=msg.replace("[","@(").replace("]",")")
> -coccilib.org.print_todo(p[0], msg_safe)
> -
> -@script:python depends on report@
> -p << r8.p;
> -x << r8.x;
> -@@
> -
> -msg="WARNING: pci_zalloc_consistent should be used for %s, instead of 
> pci_alloc_consistent/memset" % (x)
> -coccilib.report.print_report(p[0], msg)
> -//-
>  @r9 depends on org || report@
>  type T, T2;
>  expression x;
> --
> 1.7.12.4
>
>


[PATCH] Coccinelle: remove pci_alloc_consistent semantic to dectect in zalloc-simple.cocci

2018-08-18 Thread zhong jiang
Because pci_alloc_consistent has been deprecated. We prefer to use
dam_alloc_coherent directly. Therefore, we should remove pci_alloc_consistent
to increase the confidence.

Signed-off-by: zhong jiang 
---
 scripts/coccinelle/api/alloc/zalloc-simple.cocci | 41 +---
 1 file changed, 1 insertion(+), 40 deletions(-)

diff --git a/scripts/coccinelle/api/alloc/zalloc-simple.cocci 
b/scripts/coccinelle/api/alloc/zalloc-simple.cocci
index 92b2091..d819275 100644
--- a/scripts/coccinelle/api/alloc/zalloc-simple.cocci
+++ b/scripts/coccinelle/api/alloc/zalloc-simple.cocci
@@ -35,8 +35,7 @@ statement S;
 
 * x = (T)\(kmalloc(E1, ...)\|vmalloc(E1)\|dma_alloc_coherent(...,E1,...)\|
   kmalloc_node(E1, ...)\|kmem_cache_alloc(...)\|kmem_alloc(E1, ...)\|
-  devm_kmalloc(...,E1,...)\|kvmalloc(E1, 
...)\|pci_alloc_consistent(...,E1,...)\|
-  kvmalloc_node(E1,...)\);
+  devm_kmalloc(...,E1,...)\|kvmalloc(E1, ...)\|kvmalloc_node(E1,...)\);
   if ((x==NULL) || ...) S
 * memset((T2)x,0,E1);
 
@@ -124,15 +123,6 @@ statement S;
 - x = (T)kvmalloc(E1,E2);
 + x = (T)kvzalloc(E1,E2);
 |
-- x = pci_alloc_consistent(E2,E1,E3);
-+ x = pci_zalloc_consistent(E2,E1,E3);
-|
-- x = (T *)pci_alloc_consistent(E2,E1,E3);
-+ x = pci_zalloc_consistent(E2,E1,E3);
-|
-- x = (T)pci_alloc_consistent(E2,E1,E3);
-+ x = (T)pci_zalloc_consistent(E2,E1,E3);
-|
 - x = kvmalloc_node(E1,E2,E3);
 + x = kvzalloc_node(E1,E2,E3);
 |
@@ -389,35 +379,6 @@ msg="WARNING: kvzalloc should be used for %s, instead of 
kvmalloc/memset" % (x)
 coccilib.report.print_report(p[0], msg)
 
 //-
-@r8 depends on org || report@
-type T, T2;
-expression x;
-expression E1,E2,E3;
-statement S;
-position p;
-@@
-
- x = (T)pci_alloc_consistent@p(E2,E1,E3);
- if ((x==NULL) || ...) S
- memset((T2)x,0,E1);
-
-@script:python depends on org@
-p << r8.p;
-x << r8.x;
-@@
-
-msg="%s" % (x)
-msg_safe=msg.replace("[","@(").replace("]",")")
-coccilib.org.print_todo(p[0], msg_safe)
-
-@script:python depends on report@
-p << r8.p;
-x << r8.x;
-@@
-
-msg="WARNING: pci_zalloc_consistent should be used for %s, instead of 
pci_alloc_consistent/memset" % (x)
-coccilib.report.print_report(p[0], msg)
-//-
 @r9 depends on org || report@
 type T, T2;
 expression x;
-- 
1.7.12.4



  1   2   3   >