Re: Umount failing due to a file leak on 3.18 Android

[Greg KH]

On Tue, Apr 19, 2016 at 06:26:27PM -0700, Nikhilesh Reddy wrote:
> Hi
> 
> I am looking into a bug that results in umount failures ( since there is a 
> mount ref from the leaked file that is never freed on the mount )
> 
> The issue seems to be a result of the following callstack
> 
> 39.958104:   <6> Call trace:
> 39.958108:   <2> [] fput+0x1e0/0x1f8
> 39.958113:   <2> [] filp_close+0xa0/0xb8
> 39.958119:   <2> [] put_files_struct+0x88/0xf0
> 39.958123:   <2> [] binder_deferred_func+0x6a8/0x704
> 39.958129:   <2> [] process_one_work+0x238/0x3f0
> 39.958133:   <2> [] worker_thread+0x2f8/0x418
> 
> What seems to occur is that once in a while a file ( say a.txt) is fput in 
> the above stack 
> right as the task is being killed
> 
> And then we see that the  fput schedules a delayed_fput_work on this file
> 
> But when the function delayed_fput() is actually run :
>   the file that was put i.e this a.txt is not in the delayed_fput_list
> 
> Any chance you can help me get to the bottom of this leak?
> I dont understand why the delayed_fput_list is missing the file.

3.18 is very old, can you duplicate this on 4.5 or newer?

thanks,

greg k-h

Re: Umount failing due to a file leak on 3.18 Android

[Greg KH]

On Tue, Apr 19, 2016 at 06:26:27PM -0700, Nikhilesh Reddy wrote:
> Hi
> 
> I am looking into a bug that results in umount failures ( since there is a 
> mount ref from the leaked file that is never freed on the mount )
> 
> The issue seems to be a result of the following callstack
> 
> 39.958104:   <6> Call trace:
> 39.958108:   <2> [] fput+0x1e0/0x1f8
> 39.958113:   <2> [] filp_close+0xa0/0xb8
> 39.958119:   <2> [] put_files_struct+0x88/0xf0
> 39.958123:   <2> [] binder_deferred_func+0x6a8/0x704
> 39.958129:   <2> [] process_one_work+0x238/0x3f0
> 39.958133:   <2> [] worker_thread+0x2f8/0x418
> 
> What seems to occur is that once in a while a file ( say a.txt) is fput in 
> the above stack 
> right as the task is being killed
> 
> And then we see that the  fput schedules a delayed_fput_work on this file
> 
> But when the function delayed_fput() is actually run :
>   the file that was put i.e this a.txt is not in the delayed_fput_list
> 
> Any chance you can help me get to the bottom of this leak?
> I dont understand why the delayed_fput_list is missing the file.

3.18 is very old, can you duplicate this on 4.5 or newer?

thanks,

greg k-h

mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'

[kbuild test robot]

Hi,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   12566cc35d0e68308bde7aad615743d560cb097b
commit: c1a0e9bc885d46e519fd87d35af6a7937abfb986 MIPS: Allow compact branch 
policy to be changed
date:   6 months ago
config: mips-malta_qemu_32r6_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c1a0e9bc885d46e519fd87d35af6a7937abfb986
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> mipsel-linux-gnu-gcc: error: unrecognized command line option 
>> '-mcompact-branches=optimal'
>> mipsel-linux-gnu-gcc: error: unrecognized command line option 
>> '-mcompact-branches=optimal'
   make[2]: *** [kernel/bounds.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

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


.config.gz
Description: Binary data

mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'

[kbuild test robot]

Hi,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   12566cc35d0e68308bde7aad615743d560cb097b
commit: c1a0e9bc885d46e519fd87d35af6a7937abfb986 MIPS: Allow compact branch 
policy to be changed
date:   6 months ago
config: mips-malta_qemu_32r6_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c1a0e9bc885d46e519fd87d35af6a7937abfb986
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> mipsel-linux-gnu-gcc: error: unrecognized command line option 
>> '-mcompact-branches=optimal'
>> mipsel-linux-gnu-gcc: error: unrecognized command line option 
>> '-mcompact-branches=optimal'
   make[2]: *** [kernel/bounds.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

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


.config.gz
Description: Binary data

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

[Huacai Chen]

This is a kernel bug, I'll send a patch.

Huacai

On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck  wrote:
> On 04/19/2016 08:37 PM, 陈华才 wrote:
>>
>> Hi,
>>
>> Could you please remove the line "#define cpu_hwrena_impl_bits
>> 0xc000" in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h
>> and try again?Thanks.
>>
>
> That fixes the problem.
>
> Does this need to be addressed in qemu or in the Linux kernel ?
>
> Thanks,
> Guenter
>
>
>> Huacai
>>
>> -- Original --
>> From:  "Guenter Roeck";
>> Date:  Wed, Apr 20, 2016 10:54 AM
>> To:  "Huacai Chen";
>> Cc:  "Ralf Baechle";
>> "linux-mips";
>> "linux-next";
>> "linux-kernel";
>> Subject:  next: fuloong2e qemu boot failure due to 'MIPS: Loongson:
>> AddLoongson-3A R2 basic support'
>>
>> Hi,
>>
>> qemu fails to boot in -next for machine fulong2e with configuration
>> fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
>> Loongson-3A R2 basic support'. qemu hangs in boot, after displaying
>> "Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".
>>
>> Bisect log is attached.
>>
>> Guenter
>>
>> ---
>> # bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific
>> files for 20160418
>> # good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
>> git bisect start 'HEAD' 'v4.6-rc3'
>> # bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking
>> branch 'ipvs-next/master'
>> git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
>> # bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking
>> branch 'btrfs-kdave/for-next'
>> git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
>> # good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking
>> branch 'omap/for-next'
>> git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
>> # good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking
>> branch 'microblaze/next'
>> git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
>> # bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3:
>> Introduce CONFIG_LOONGSON3_ENHANCEMENT
>> git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
>> # good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be
>> used on non-R2 or R6 cores
>> git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
>> # good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add
>> Loongson1 architecture entry
>> git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
>> # good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to
>> use strict posix types
>> git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
>> # good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw
>> watchpoints on MIPS R6
>> git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
>> # good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3:
>> Adjust irq dispatch to speedup processing
>> git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
>> # bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set
>> cache flush handlers to cache_noop
>> git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
>> # bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add
>> Loongson-3A R2 basic support
>> git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
>> # first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS:
>> Loongson: Add Loongson-3A R2 basic support
>>
>
>

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

[Huacai Chen]

This is a kernel bug, I'll send a patch.

Huacai

On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck  wrote:
> On 04/19/2016 08:37 PM, 陈华才 wrote:
>>
>> Hi,
>>
>> Could you please remove the line "#define cpu_hwrena_impl_bits
>> 0xc000" in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h
>> and try again?Thanks.
>>
>
> That fixes the problem.
>
> Does this need to be addressed in qemu or in the Linux kernel ?
>
> Thanks,
> Guenter
>
>
>> Huacai
>>
>> -- Original --
>> From:  "Guenter Roeck";
>> Date:  Wed, Apr 20, 2016 10:54 AM
>> To:  "Huacai Chen";
>> Cc:  "Ralf Baechle";
>> "linux-mips";
>> "linux-next";
>> "linux-kernel";
>> Subject:  next: fuloong2e qemu boot failure due to 'MIPS: Loongson:
>> AddLoongson-3A R2 basic support'
>>
>> Hi,
>>
>> qemu fails to boot in -next for machine fulong2e with configuration
>> fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
>> Loongson-3A R2 basic support'. qemu hangs in boot, after displaying
>> "Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".
>>
>> Bisect log is attached.
>>
>> Guenter
>>
>> ---
>> # bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific
>> files for 20160418
>> # good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
>> git bisect start 'HEAD' 'v4.6-rc3'
>> # bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking
>> branch 'ipvs-next/master'
>> git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
>> # bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking
>> branch 'btrfs-kdave/for-next'
>> git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
>> # good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking
>> branch 'omap/for-next'
>> git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
>> # good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking
>> branch 'microblaze/next'
>> git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
>> # bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3:
>> Introduce CONFIG_LOONGSON3_ENHANCEMENT
>> git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
>> # good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be
>> used on non-R2 or R6 cores
>> git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
>> # good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add
>> Loongson1 architecture entry
>> git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
>> # good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to
>> use strict posix types
>> git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
>> # good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw
>> watchpoints on MIPS R6
>> git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
>> # good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3:
>> Adjust irq dispatch to speedup processing
>> git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
>> # bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set
>> cache flush handlers to cache_noop
>> git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
>> # bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add
>> Loongson-3A R2 basic support
>> git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
>> # first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS:
>> Loongson: Add Loongson-3A R2 basic support
>>
>
>

Re: [PATCH v11 1/4] tpm: Remove all uses of drvdata from the TPM Core

[Jarkko Sakkinen]

On Tue, Apr 19, 2016 at 11:06:45AM -0600, Jason Gunthorpe wrote:
> On Tue, Apr 19, 2016 at 06:36:22AM -0400, Stefan Berger wrote:
> > On 04/19/2016 06:12 AM, Jarkko Sakkinen wrote:
> > >On Mon, Apr 18, 2016 at 01:26:13PM -0400, Stefan Berger wrote:
> > >>From: Jason Gunthorpe 
> > >>
> > >>The final thing preventing this was the way the sysfs files were
> > >>attached to the pdev. Follow the approach developed for ppi and move
> > >>the sysfs files to the chip->dev with symlinks from the pdev
> > >>for compatibility. Everything in the core now sanely uses container_of
> > >>to get the chip.
> > >Can you give me a quick recap why this patch was mandatory to make the
> > >patch set work? Which regression in the earlier versions of the patch
> > >set this fixes?
> > 
> > The below patch removes usage of dev_get_drvdata() for retrieving the chip.
> > With Christophe's series dropping the priv field I now can use the drvdata
> > to store proxy_dev rather than re-introducing the priv field in the chip
> > structure. Besides that it doesn't seem necessary to use the drvdata field
> > to get from the chip to the device if a simple container_of can do it.
> 
> More specifically, since the vtpm patches use a NULL parent, the
> approach of putting the sysfs files on the parent is no longer
> workable.
> 
> The early vtpm patches simply moved the sysfs files to the tpm_chip
> when a parent is NULL, which is inconsistent for userspace. This also
> created a problem where drvdata on the chip now had to point back to
> the chip, meaning it became unusable for its new intended purpose.
> 
> The fix is to make everything uniform and put the sysfs files in the
> correct place for all drivers (under the chip) and use symlinks for
> compat.

OK, thanks for explaining this, make perfect sense now. I'll do a more
detailed review (and testing) later on.

> Jason

/Jarkko

Re: [PATCH v11 1/4] tpm: Remove all uses of drvdata from the TPM Core

[Jarkko Sakkinen]

On Tue, Apr 19, 2016 at 11:06:45AM -0600, Jason Gunthorpe wrote:
> On Tue, Apr 19, 2016 at 06:36:22AM -0400, Stefan Berger wrote:
> > On 04/19/2016 06:12 AM, Jarkko Sakkinen wrote:
> > >On Mon, Apr 18, 2016 at 01:26:13PM -0400, Stefan Berger wrote:
> > >>From: Jason Gunthorpe 
> > >>
> > >>The final thing preventing this was the way the sysfs files were
> > >>attached to the pdev. Follow the approach developed for ppi and move
> > >>the sysfs files to the chip->dev with symlinks from the pdev
> > >>for compatibility. Everything in the core now sanely uses container_of
> > >>to get the chip.
> > >Can you give me a quick recap why this patch was mandatory to make the
> > >patch set work? Which regression in the earlier versions of the patch
> > >set this fixes?
> > 
> > The below patch removes usage of dev_get_drvdata() for retrieving the chip.
> > With Christophe's series dropping the priv field I now can use the drvdata
> > to store proxy_dev rather than re-introducing the priv field in the chip
> > structure. Besides that it doesn't seem necessary to use the drvdata field
> > to get from the chip to the device if a simple container_of can do it.
> 
> More specifically, since the vtpm patches use a NULL parent, the
> approach of putting the sysfs files on the parent is no longer
> workable.
> 
> The early vtpm patches simply moved the sysfs files to the tpm_chip
> when a parent is NULL, which is inconsistent for userspace. This also
> created a problem where drvdata on the chip now had to point back to
> the chip, meaning it became unusable for its new intended purpose.
> 
> The fix is to make everything uniform and put the sysfs files in the
> correct place for all drivers (under the chip) and use symlinks for
> compat.

OK, thanks for explaining this, make perfect sense now. I'll do a more
detailed review (and testing) later on.

> Jason

/Jarkko

[PATCH powerpc/next RESEND] powerpc: spinlock: Fix spin_unlock_wait()

[Boqun Feng]

There is an ordering issue with spin_unlock_wait() on powerpc, because
the spin_lock primitive is an ACQUIRE and an ACQUIRE is only ordering
the load part of the operation with memory operations following it.
Therefore the following event sequence can happen:

CPU 1   CPU 2   CPU 3
==  ==
spin_unlock();
spin_lock():
  r1 = *lock; // r1 == 0;
o = object; o = READ_ONCE(object); // reordered here
object = NULL;
smp_mb();
spin_unlock_wait();
  *lock = 1;
smp_mb();
o->dead = true; < o = READ_ONCE(object); > // reordered upwards
if (o) // true
BUG_ON(o->dead); // true!!

To fix this, we add a "nop" ll/sc loop in arch_spin_unlock_wait() on
ppc (arch_spin_is_locked_sync()), the "nop" ll/sc loop reads the lock
value and writes it back atomically, in this way it will synchronize the
view of the lock on CPU1 with that on CPU2. Therefore in the scenario
above, either CPU2 will fail to get the lock at first or CPU1 will see
the lock acquired by CPU2, both cases will eliminate this bug. This is a
similar idea as what Will Deacon did for ARM64 in:

"arm64: spinlock: serialise spin_unlock_wait against concurrent lockers"

Further more, if arch_spin_is_locked_sync() figures out the lock is
locked, we actually don't need to do the "nop" ll/sc trick again, we can
just do a normal load+check loop for the lock to be released, because in
that case, spin_unlock_wait() is called when someone is holding the
lock, and the store part of arch_spin_is_locked_sync() happens before
the unlocking of the current lock holder, which means
arch_spin_is_locked_sync() happens before the next lock acquisition.
With the smp_mb() perceding spin_unlock_wait(), the store of object is
guaranteed to be observed by the next lock holder.

Please note spin_unlock_wait() on powerpc is still not an ACQUIRE after
this fix, the callers should add necessary barriers if they want to
promote it as all the current callers do.

This patch therefore fixes the issue and also cleans the
arch_spin_unlock_wait() a little bit by removing superfluous memory
barriers in loops and consolidating the implementations for PPC32 and
PPC64 into one.

Suggested-by: "Paul E. McKenney" 
Signed-off-by: Boqun Feng 
Reviewed-by: "Paul E. McKenney" 
---
 arch/powerpc/include/asm/spinlock.h | 48 -
 arch/powerpc/lib/locks.c| 16 -
 2 files changed, 42 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/include/asm/spinlock.h 
b/arch/powerpc/include/asm/spinlock.h
index 523673d7583c..0a517c1a751e 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -64,6 +64,25 @@ static inline int arch_spin_is_locked(arch_spinlock_t *lock)
 }
 
 /*
+ * Use a ll/sc loop to read the lock value, the STORE part of this operation is
+ * used for making later lock operation observe it.
+ */
+static inline bool arch_spin_is_locked_sync(arch_spinlock_t *lock)
+{
+   arch_spinlock_t tmp;
+
+   __asm__ __volatile__(
+"1:" PPC_LWARX(%0, 0, %2, 1) "\n"
+"  stwcx. %0, 0, %2\n"
+"  bne- 1b\n"
+   : "=" (tmp), "+m" (*lock)
+   : "r" (lock)
+   : "cr0", "xer");
+
+   return !arch_spin_value_unlocked(tmp);
+}
+
+/*
  * This returns the old value in the lock, so we succeeded
  * in getting the lock if the return value is 0.
  */
@@ -162,12 +181,29 @@ static inline void arch_spin_unlock(arch_spinlock_t *lock)
lock->slock = 0;
 }
 
-#ifdef CONFIG_PPC64
-extern void arch_spin_unlock_wait(arch_spinlock_t *lock);
-#else
-#define arch_spin_unlock_wait(lock) \
-   do { while (arch_spin_is_locked(lock)) cpu_relax(); } while (0)
-#endif
+static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
+{
+   /*
+* Make sure previous loads and stores are observed by other cpu, this
+* pairs with the ACQUIRE barrier in lock.
+*/
+   smp_mb();
+
+   if (!arch_spin_is_locked_sync(lock))
+   return;
+
+   while (!arch_spin_value_unlocked(*lock)) {
+   HMT_low();
+   if (SHARED_PROCESSOR)
+   __spin_yield(lock);
+   }
+   HMT_medium();
+
+   /*
+* No barrier here, caller either relys on the control dependency or
+* should add a necessary barrier afterwards.
+*/
+}
 
 /*
  * Read-write spinlocks, allowing multiple readers
diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index f7deebdf3365..b7b1237d4aa6 100644
--- a/arch/powerpc/lib/locks.c
+++ b/arch/powerpc/lib/locks.c
@@ -68,19 +68,3 @@ void __rw_yield(arch_rwlock_t *rw)
get_hard_smp_processor_id(holder_cpu), 

[PATCH powerpc/next RESEND] powerpc: spinlock: Fix spin_unlock_wait()

[Boqun Feng]

There is an ordering issue with spin_unlock_wait() on powerpc, because
the spin_lock primitive is an ACQUIRE and an ACQUIRE is only ordering
the load part of the operation with memory operations following it.
Therefore the following event sequence can happen:

CPU 1   CPU 2   CPU 3
==  ==
spin_unlock();
spin_lock():
  r1 = *lock; // r1 == 0;
o = object; o = READ_ONCE(object); // reordered here
object = NULL;
smp_mb();
spin_unlock_wait();
  *lock = 1;
smp_mb();
o->dead = true; < o = READ_ONCE(object); > // reordered upwards
if (o) // true
BUG_ON(o->dead); // true!!

To fix this, we add a "nop" ll/sc loop in arch_spin_unlock_wait() on
ppc (arch_spin_is_locked_sync()), the "nop" ll/sc loop reads the lock
value and writes it back atomically, in this way it will synchronize the
view of the lock on CPU1 with that on CPU2. Therefore in the scenario
above, either CPU2 will fail to get the lock at first or CPU1 will see
the lock acquired by CPU2, both cases will eliminate this bug. This is a
similar idea as what Will Deacon did for ARM64 in:

"arm64: spinlock: serialise spin_unlock_wait against concurrent lockers"

Further more, if arch_spin_is_locked_sync() figures out the lock is
locked, we actually don't need to do the "nop" ll/sc trick again, we can
just do a normal load+check loop for the lock to be released, because in
that case, spin_unlock_wait() is called when someone is holding the
lock, and the store part of arch_spin_is_locked_sync() happens before
the unlocking of the current lock holder, which means
arch_spin_is_locked_sync() happens before the next lock acquisition.
With the smp_mb() perceding spin_unlock_wait(), the store of object is
guaranteed to be observed by the next lock holder.

Please note spin_unlock_wait() on powerpc is still not an ACQUIRE after
this fix, the callers should add necessary barriers if they want to
promote it as all the current callers do.

This patch therefore fixes the issue and also cleans the
arch_spin_unlock_wait() a little bit by removing superfluous memory
barriers in loops and consolidating the implementations for PPC32 and
PPC64 into one.

Suggested-by: "Paul E. McKenney" 
Signed-off-by: Boqun Feng 
Reviewed-by: "Paul E. McKenney" 
---
 arch/powerpc/include/asm/spinlock.h | 48 -
 arch/powerpc/lib/locks.c| 16 -
 2 files changed, 42 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/include/asm/spinlock.h 
b/arch/powerpc/include/asm/spinlock.h
index 523673d7583c..0a517c1a751e 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -64,6 +64,25 @@ static inline int arch_spin_is_locked(arch_spinlock_t *lock)
 }
 
 /*
+ * Use a ll/sc loop to read the lock value, the STORE part of this operation is
+ * used for making later lock operation observe it.
+ */
+static inline bool arch_spin_is_locked_sync(arch_spinlock_t *lock)
+{
+   arch_spinlock_t tmp;
+
+   __asm__ __volatile__(
+"1:" PPC_LWARX(%0, 0, %2, 1) "\n"
+"  stwcx. %0, 0, %2\n"
+"  bne- 1b\n"
+   : "=" (tmp), "+m" (*lock)
+   : "r" (lock)
+   : "cr0", "xer");
+
+   return !arch_spin_value_unlocked(tmp);
+}
+
+/*
  * This returns the old value in the lock, so we succeeded
  * in getting the lock if the return value is 0.
  */
@@ -162,12 +181,29 @@ static inline void arch_spin_unlock(arch_spinlock_t *lock)
lock->slock = 0;
 }
 
-#ifdef CONFIG_PPC64
-extern void arch_spin_unlock_wait(arch_spinlock_t *lock);
-#else
-#define arch_spin_unlock_wait(lock) \
-   do { while (arch_spin_is_locked(lock)) cpu_relax(); } while (0)
-#endif
+static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
+{
+   /*
+* Make sure previous loads and stores are observed by other cpu, this
+* pairs with the ACQUIRE barrier in lock.
+*/
+   smp_mb();
+
+   if (!arch_spin_is_locked_sync(lock))
+   return;
+
+   while (!arch_spin_value_unlocked(*lock)) {
+   HMT_low();
+   if (SHARED_PROCESSOR)
+   __spin_yield(lock);
+   }
+   HMT_medium();
+
+   /*
+* No barrier here, caller either relys on the control dependency or
+* should add a necessary barrier afterwards.
+*/
+}
 
 /*
  * Read-write spinlocks, allowing multiple readers
diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index f7deebdf3365..b7b1237d4aa6 100644
--- a/arch/powerpc/lib/locks.c
+++ b/arch/powerpc/lib/locks.c
@@ -68,19 +68,3 @@ void __rw_yield(arch_rwlock_t *rw)
get_hard_smp_processor_id(holder_cpu), yield_count);
 }
 #endif
-
-void arch_spin_unlock_wait(arch_spinlock_t *lock)
-{
-

[PATCH powerpc/next] powerpc: spinlock: Fix spin_unlock_wait()

[Boqun Feng]

There is an ordering issue with spin_unlock_wait() on powerpc, because
the spin_lock primitive is an ACQUIRE and an ACQUIRE is only ordering
the load part of the operation with memory operations following it.
Therefore the following event sequence can happen:

CPU 1   CPU 2   CPU 3
==  ==
spin_unlock();
spin_lock():
  r1 = *lock; // r1 == 0;
o = object; o = READ_ONCE(object); // reordered here
object = NULL;
smp_mb();
spin_unlock_wait();
  *lock = 1;
smp_mb();
o->dead = true; < o = READ_ONCE(object); > // reordered upwards
if (o) // true
BUG_ON(o->dead); // true!!

To fix this, we add a "nop" ll/sc loop in arch_spin_unlock_wait() on
ppc (arch_spin_is_locked_sync()), the "nop" ll/sc loop reads the lock
value and writes it back atomically, in this way it will synchronize the
view of the lock on CPU1 with that on CPU2. Therefore in the scenario
above, either CPU2 will fail to get the lock at first or CPU1 will see
the lock acquired by CPU2, both cases will eliminate this bug. This is a
similar idea as what Will Deacon did for ARM64 in:

"arm64: spinlock: serialise spin_unlock_wait against concurrent lockers"

Further more, if arch_spin_is_locked_sync() figures out the lock is
locked, we actually don't need to do the "nop" ll/sc trick again, we can
just do a normal load+check loop for the lock to be released, because in
that case, spin_unlock_wait() is called when someone is holding the
lock, and the store part of arch_spin_is_locked_sync() happens before
the unlocking of the current lock holder, which means
arch_spin_is_locked_sync() happens before the next lock acquisition.
With the smp_mb() perceding spin_unlock_wait(), the store of object is
guaranteed to be observed by the next lock holder.

Please note spin_unlock_wait() on powerpc is still not an ACQUIRE after
this fix, the callers should add necessary barriers if they want to
promote it as all the current callers do.

This patch therefore fixes the issue and also cleans the
arch_spin_unlock_wait() a little bit by removing superfluous memory
barriers in loops and consolidating the implementations for PPC32 and
PPC64 into one.

Suggested-by: "Paul E. McKenney" 
Signed-off-by: Boqun Feng 
Reviewed-by: "Paul E. McKenney" 
---
 arch/powerpc/include/asm/spinlock.h | 48 -
 arch/powerpc/lib/locks.c| 16 -
 2 files changed, 42 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/include/asm/spinlock.h 
b/arch/powerpc/include/asm/spinlock.h
index 523673d7583c..0a517c1a751e 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -64,6 +64,25 @@ static inline int arch_spin_is_locked(arch_spinlock_t *lock)
 }
 
 /*
+ * Use a ll/sc loop to read the lock value, the STORE part of this operation is
+ * used for making later lock operation observe it.
+ */
+static inline bool arch_spin_is_locked_sync(arch_spinlock_t *lock)
+{
+   arch_spinlock_t tmp;
+
+   __asm__ __volatile__(
+"1:" PPC_LWARX(%0, 0, %2, 1) "\n"
+"  stwcx. %0, 0, %2\n"
+"  bne- 1b\n"
+   : "=" (tmp), "+m" (*lock)
+   : "r" (lock)
+   : "cr0", "xer");
+
+   return !arch_spin_value_unlocked(tmp);
+}
+
+/*
  * This returns the old value in the lock, so we succeeded
  * in getting the lock if the return value is 0.
  */
@@ -162,12 +181,29 @@ static inline void arch_spin_unlock(arch_spinlock_t *lock)
lock->slock = 0;
 }
 
-#ifdef CONFIG_PPC64
-extern void arch_spin_unlock_wait(arch_spinlock_t *lock);
-#else
-#define arch_spin_unlock_wait(lock) \
-   do { while (arch_spin_is_locked(lock)) cpu_relax(); } while (0)
-#endif
+static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
+{
+   /*
+* Make sure previous loads and stores are observed by other cpu, this
+* pairs with the ACQUIRE barrier in lock.
+*/
+   smp_mb();
+
+   if (!arch_spin_is_locked_sync(lock))
+   return;
+
+   while (!arch_spin_value_unlocked(*lock)) {
+   HMT_low();
+   if (SHARED_PROCESSOR)
+   __spin_yield(lock);
+   }
+   HMT_medium();
+
+   /*
+* No barrier here, caller either relys on the control dependency or
+* should add a necessary barrier afterwards.
+*/
+}
 
 /*
  * Read-write spinlocks, allowing multiple readers
diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index f7deebdf3365..b7b1237d4aa6 100644
--- a/arch/powerpc/lib/locks.c
+++ b/arch/powerpc/lib/locks.c
@@ -68,19 +68,3 @@ void __rw_yield(arch_rwlock_t *rw)
get_hard_smp_processor_id(holder_cpu), 

[PATCH powerpc/next] powerpc: spinlock: Fix spin_unlock_wait()

[Boqun Feng]

There is an ordering issue with spin_unlock_wait() on powerpc, because
the spin_lock primitive is an ACQUIRE and an ACQUIRE is only ordering
the load part of the operation with memory operations following it.
Therefore the following event sequence can happen:

CPU 1   CPU 2   CPU 3
==  ==
spin_unlock();
spin_lock():
  r1 = *lock; // r1 == 0;
o = object; o = READ_ONCE(object); // reordered here
object = NULL;
smp_mb();
spin_unlock_wait();
  *lock = 1;
smp_mb();
o->dead = true; < o = READ_ONCE(object); > // reordered upwards
if (o) // true
BUG_ON(o->dead); // true!!

To fix this, we add a "nop" ll/sc loop in arch_spin_unlock_wait() on
ppc (arch_spin_is_locked_sync()), the "nop" ll/sc loop reads the lock
value and writes it back atomically, in this way it will synchronize the
view of the lock on CPU1 with that on CPU2. Therefore in the scenario
above, either CPU2 will fail to get the lock at first or CPU1 will see
the lock acquired by CPU2, both cases will eliminate this bug. This is a
similar idea as what Will Deacon did for ARM64 in:

"arm64: spinlock: serialise spin_unlock_wait against concurrent lockers"

Further more, if arch_spin_is_locked_sync() figures out the lock is
locked, we actually don't need to do the "nop" ll/sc trick again, we can
just do a normal load+check loop for the lock to be released, because in
that case, spin_unlock_wait() is called when someone is holding the
lock, and the store part of arch_spin_is_locked_sync() happens before
the unlocking of the current lock holder, which means
arch_spin_is_locked_sync() happens before the next lock acquisition.
With the smp_mb() perceding spin_unlock_wait(), the store of object is
guaranteed to be observed by the next lock holder.

Please note spin_unlock_wait() on powerpc is still not an ACQUIRE after
this fix, the callers should add necessary barriers if they want to
promote it as all the current callers do.

This patch therefore fixes the issue and also cleans the
arch_spin_unlock_wait() a little bit by removing superfluous memory
barriers in loops and consolidating the implementations for PPC32 and
PPC64 into one.

Suggested-by: "Paul E. McKenney" 
Signed-off-by: Boqun Feng 
Reviewed-by: "Paul E. McKenney" 
---
 arch/powerpc/include/asm/spinlock.h | 48 -
 arch/powerpc/lib/locks.c| 16 -
 2 files changed, 42 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/include/asm/spinlock.h 
b/arch/powerpc/include/asm/spinlock.h
index 523673d7583c..0a517c1a751e 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -64,6 +64,25 @@ static inline int arch_spin_is_locked(arch_spinlock_t *lock)
 }
 
 /*
+ * Use a ll/sc loop to read the lock value, the STORE part of this operation is
+ * used for making later lock operation observe it.
+ */
+static inline bool arch_spin_is_locked_sync(arch_spinlock_t *lock)
+{
+   arch_spinlock_t tmp;
+
+   __asm__ __volatile__(
+"1:" PPC_LWARX(%0, 0, %2, 1) "\n"
+"  stwcx. %0, 0, %2\n"
+"  bne- 1b\n"
+   : "=" (tmp), "+m" (*lock)
+   : "r" (lock)
+   : "cr0", "xer");
+
+   return !arch_spin_value_unlocked(tmp);
+}
+
+/*
  * This returns the old value in the lock, so we succeeded
  * in getting the lock if the return value is 0.
  */
@@ -162,12 +181,29 @@ static inline void arch_spin_unlock(arch_spinlock_t *lock)
lock->slock = 0;
 }
 
-#ifdef CONFIG_PPC64
-extern void arch_spin_unlock_wait(arch_spinlock_t *lock);
-#else
-#define arch_spin_unlock_wait(lock) \
-   do { while (arch_spin_is_locked(lock)) cpu_relax(); } while (0)
-#endif
+static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
+{
+   /*
+* Make sure previous loads and stores are observed by other cpu, this
+* pairs with the ACQUIRE barrier in lock.
+*/
+   smp_mb();
+
+   if (!arch_spin_is_locked_sync(lock))
+   return;
+
+   while (!arch_spin_value_unlocked(*lock)) {
+   HMT_low();
+   if (SHARED_PROCESSOR)
+   __spin_yield(lock);
+   }
+   HMT_medium();
+
+   /*
+* No barrier here, caller either relys on the control dependency or
+* should add a necessary barrier afterwards.
+*/
+}
 
 /*
  * Read-write spinlocks, allowing multiple readers
diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index f7deebdf3365..b7b1237d4aa6 100644
--- a/arch/powerpc/lib/locks.c
+++ b/arch/powerpc/lib/locks.c
@@ -68,19 +68,3 @@ void __rw_yield(arch_rwlock_t *rw)
get_hard_smp_processor_id(holder_cpu), yield_count);
 }
 #endif
-
-void arch_spin_unlock_wait(arch_spinlock_t *lock)
-{
-

linux-next: Tree for Apr 20

[Stephen Rothwell]

Hi all,

Changes since 20160419:

The tip tree lost its build failures.

The usb-gadget tree gained a conflict against the usb-gadget-fixes tree.

The akpm-current tree still had its build failure for which I applied
a patch.

Non-merge commits (relative to Linus' tree): 4655
 4294 files changed, 171419 insertions(+), 95741 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 232 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (12566cc35d0e Merge tag 'pci-v4.6-fixes-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (421e31e58c2a ARCv2: Enable LOCKDEP)
Merging arm-current/fixes (9c18fcf7ae0e ARM: 8551/2: DMA: Fix kzalloc flags in 
__dma_alloc)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (4705e02498d6 powerpc: Update TM user feature bits 
in scan_features())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (ab2ed0171a50 macsec: fix crypto Kconfig dependency)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (bcf493428840 netfilter: ebtables: Fix extension lookup 
with identical name)
Merging wireless-drivers/master (de478a61389c ath9k: 
ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation)
Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket 
release notification)
Merging sound-current/for-linus (afecb146d8d8 ALSA: hda/realtek - Add ALC3234 
headset mode for Optiplex 9020m)
Merging pci-current/for-linus (67e658794ca1 cxgb4: Set VPD size so we can read 
both VPD structures)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (f077b7368291 Revert "serial: 8250: Add hardware 
dependency to RT288X option")
Merging usb.current/usb-linus (c3b46c73264b Linux 4.6-rc4)
Merging usb-gadget-fixes/fixes (5505d5254aeb usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (bf1620068911 Linux 4.6-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3)
Merging char-misc.current/char-misc-linus (c3b46c73264b Linux 4.6-rc4)
Merging input-current/for-linus (eda5ecc0a6b8 Input: pmic8xxx-pwrkey - fix 
algorithm for converting trigger delay)
Merging crypto-current/master (f709b45ec461 crypto: ccp - Prevent information 
leakage on export)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)
Merging kselftest-fixes/fixes (505ce68c6da3 selftest/seccomp: Fix the 
seccomp(2) signature)
Mer

linux-next: Tree for Apr 20

[Stephen Rothwell]

Hi all,

Changes since 20160419:

The tip tree lost its build failures.

The usb-gadget tree gained a conflict against the usb-gadget-fixes tree.

The akpm-current tree still had its build failure for which I applied
a patch.

Non-merge commits (relative to Linus' tree): 4655
 4294 files changed, 171419 insertions(+), 95741 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 232 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (12566cc35d0e Merge tag 'pci-v4.6-fixes-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (421e31e58c2a ARCv2: Enable LOCKDEP)
Merging arm-current/fixes (9c18fcf7ae0e ARM: 8551/2: DMA: Fix kzalloc flags in 
__dma_alloc)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (4705e02498d6 powerpc: Update TM user feature bits 
in scan_features())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (ab2ed0171a50 macsec: fix crypto Kconfig dependency)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (bcf493428840 netfilter: ebtables: Fix extension lookup 
with identical name)
Merging wireless-drivers/master (de478a61389c ath9k: 
ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation)
Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket 
release notification)
Merging sound-current/for-linus (afecb146d8d8 ALSA: hda/realtek - Add ALC3234 
headset mode for Optiplex 9020m)
Merging pci-current/for-linus (67e658794ca1 cxgb4: Set VPD size so we can read 
both VPD structures)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (f077b7368291 Revert "serial: 8250: Add hardware 
dependency to RT288X option")
Merging usb.current/usb-linus (c3b46c73264b Linux 4.6-rc4)
Merging usb-gadget-fixes/fixes (5505d5254aeb usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (bf1620068911 Linux 4.6-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3)
Merging char-misc.current/char-misc-linus (c3b46c73264b Linux 4.6-rc4)
Merging input-current/for-linus (eda5ecc0a6b8 Input: pmic8xxx-pwrkey - fix 
algorithm for converting trigger delay)
Merging crypto-current/master (f709b45ec461 crypto: ccp - Prevent information 
leakage on export)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)
Merging kselftest-fixes/fixes (505ce68c6da3 selftest/seccomp: Fix the 
seccomp(2) signature)
Mer

Re: [PATCH] rtc: pcf8563: Remove CLK_IS_ROOT

[Heiko Schocher]

Hello Stephen,

Am 20.04.2016 um 03:12 schrieb Stephen Boyd:

This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.

Cc: Heiko Schocher 
Signed-off-by: Stephen Boyd 
---
  drivers/rtc/rtc-pcf8563.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Heiko Schocher 

bye,
Heiko


diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index d5e6ed96b748..b9ddbb001283 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -533,7 +533,7 @@ static struct clk *pcf8563_clkout_register_clk(struct 
pcf8563 *pcf8563)

init.name = "pcf8563-clkout";
init.ops = _clkout_ops;
-   init.flags = CLK_IS_ROOT;
+   init.flags = 0;
init.parent_names = NULL;
init.num_parents = 0;
pcf8563->clkout_hw.init = 



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] rtc: pcf8563: Remove CLK_IS_ROOT

[Heiko Schocher]

Hello Stephen,

Am 20.04.2016 um 03:12 schrieb Stephen Boyd:

This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.

Cc: Heiko Schocher 
Signed-off-by: Stephen Boyd 
---
  drivers/rtc/rtc-pcf8563.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Acked-by: Heiko Schocher 

bye,
Heiko


diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index d5e6ed96b748..b9ddbb001283 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -533,7 +533,7 @@ static struct clk *pcf8563_clkout_register_clk(struct 
pcf8563 *pcf8563)

init.name = "pcf8563-clkout";
init.ops = _clkout_ops;
-   init.flags = CLK_IS_ROOT;
+   init.flags = 0;
init.parent_names = NULL;
init.num_parents = 0;
pcf8563->clkout_hw.init = 



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi,

> From: Peter Chen
> Sent: Tuesday, April 19, 2016 6:18 PM
> 
> On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> > Hi,
> >
> > > From: Yoshihiro Shimoda
> > > Sent: Friday, April 15, 2016 6:59 PM
> > >
> > > Hi,
> > >
> > > > From: Roger Quadros
> > > > Sent: Thursday, April 14, 2016 8:32 PM
> > > >
> > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> > > > > Hi,
> > > > >
> > > < snip >
> > > > >>> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > > > >>> unsigned int irqnum,
> > > > >>>  * we're ready only if we have shared HCD
> > > > >>>  * or we don't need shared HCD.
> > > > >>>  */
> > > > >>> -   if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> > > > >>> +   if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> > > > >>> +   !otg->primary_hcd.hcd->shared_hcd)) 
> > > > >>> {
> > > > >>> otg->host = hcd_to_bus(hcd);
> > > > >>> /* FIXME: set bus->otg_port if this is true OTG port 
> > > > >>> with HNP */
> > > > >>>
> > > > >>
> > > > >> These changes look good to me. Thanks.
> > > > >
> > > > > Thank you for the comment.
> > > > > If we change the "needs_companion" place to the otg_config,
> > > > > do we need to add a flag into the otg, instead of otg->caps?
> > > >
> > > > Yes we can add a flag in struct usb_otg.
> > >
> > > Thank you for the comment.
> > >
> > > I made a fixed patch.
> > > So, should I send this patch to ML after you sent v7 patches?
> > > Or, would you apply this patch before you send v7 patches?
> >
> > Oops, I sent this email without my patch...
> >
> > ---
> > Subject: [PATCH] usb: otg: add hcd companion support
> >
> > Since some host controller (e.g. EHCI) needs a companion host controller
> > (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> > core.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
> >  drivers/usb/common/usb-otg.c  | 17 +
> >  include/linux/usb/otg.h   |  7 ++-
> >  3 files changed, 22 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt 
> > b/Documentation/devicetree/bindings/usb/generic.txt
> > index f6866c1..1db1c33 100644
> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > @@ -27,6 +27,9 @@ Optional properties:
> >   - otg-controller: phandle to otg controller. Host or gadget controllers 
> > can
> > contain this property to link it to a particular OTG
> > controller.
> > + - hcd-needs-companion: must be present if otg controller is dealing with
> > +   EHCI host controller that needs a companion OHCI host
> > +   controller.
> >
> >  This is an attribute to a USB controller such as:
> >
> > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> > index 41e762a..83c8c96 100644
> > --- a/drivers/usb/common/usb-otg.c
> > +++ b/drivers/usb/common/usb-otg.c
> > @@ -20,6 +20,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> > else
> > INIT_WORK(>work, usb_otg_work);
> >
> > +   if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> > +   config->hcd_needs_companion)/* needs comanion ? */
> 
> %s/comanion/companion

Thank you for pointing it out!

Roger, would you fix this in your v7 patch set?

> I have a little puzzled with companion controller and shared hcd, let me
> post a topic for it.

I looked at the email thread.
It is very useful information to me! :)

Best regards,
Yoshihiro Shimoda

> Peter
> 
> > +   otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> > +
> > otg->wq = create_singlethread_workqueue("usb_otg");
> > if (!otg->wq) {
> > dev_err(dev, "otg: %s: can't create workqueue\n",
> > @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > unsigned int irqnum,
> > /* HCD will be started by OTG fsm when needed */
> > mutex_lock(>fsm.lock);
> > if (otg->primary_hcd.hcd) {
> > -   /* probably a shared HCD ? */
> > -   if (usb_otg_hcd_is_primary_hcd(hcd)) {
> > +   /* probably a shared HCD or a companion OHCI HCD ? */
> > +   if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> > +   usb_otg_hcd_is_primary_hcd(hcd)) {
> > dev_err(otg_dev, "otg: primary host already 
> > registered\n");
> > goto err;
> > }
> >
> > -   if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> > +   if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> > +   (hcd->shared_hcd == otg->primary_hcd.hcd)) {

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi,

> From: Peter Chen
> Sent: Tuesday, April 19, 2016 6:18 PM
> 
> On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> > Hi,
> >
> > > From: Yoshihiro Shimoda
> > > Sent: Friday, April 15, 2016 6:59 PM
> > >
> > > Hi,
> > >
> > > > From: Roger Quadros
> > > > Sent: Thursday, April 14, 2016 8:32 PM
> > > >
> > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> > > > > Hi,
> > > > >
> > > < snip >
> > > > >>> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > > > >>> unsigned int irqnum,
> > > > >>>  * we're ready only if we have shared HCD
> > > > >>>  * or we don't need shared HCD.
> > > > >>>  */
> > > > >>> -   if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> > > > >>> +   if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> > > > >>> +   !otg->primary_hcd.hcd->shared_hcd)) 
> > > > >>> {
> > > > >>> otg->host = hcd_to_bus(hcd);
> > > > >>> /* FIXME: set bus->otg_port if this is true OTG port 
> > > > >>> with HNP */
> > > > >>>
> > > > >>
> > > > >> These changes look good to me. Thanks.
> > > > >
> > > > > Thank you for the comment.
> > > > > If we change the "needs_companion" place to the otg_config,
> > > > > do we need to add a flag into the otg, instead of otg->caps?
> > > >
> > > > Yes we can add a flag in struct usb_otg.
> > >
> > > Thank you for the comment.
> > >
> > > I made a fixed patch.
> > > So, should I send this patch to ML after you sent v7 patches?
> > > Or, would you apply this patch before you send v7 patches?
> >
> > Oops, I sent this email without my patch...
> >
> > ---
> > Subject: [PATCH] usb: otg: add hcd companion support
> >
> > Since some host controller (e.g. EHCI) needs a companion host controller
> > (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> > core.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
> >  drivers/usb/common/usb-otg.c  | 17 +
> >  include/linux/usb/otg.h   |  7 ++-
> >  3 files changed, 22 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt 
> > b/Documentation/devicetree/bindings/usb/generic.txt
> > index f6866c1..1db1c33 100644
> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > @@ -27,6 +27,9 @@ Optional properties:
> >   - otg-controller: phandle to otg controller. Host or gadget controllers 
> > can
> > contain this property to link it to a particular OTG
> > controller.
> > + - hcd-needs-companion: must be present if otg controller is dealing with
> > +   EHCI host controller that needs a companion OHCI host
> > +   controller.
> >
> >  This is an attribute to a USB controller such as:
> >
> > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> > index 41e762a..83c8c96 100644
> > --- a/drivers/usb/common/usb-otg.c
> > +++ b/drivers/usb/common/usb-otg.c
> > @@ -20,6 +20,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> > else
> > INIT_WORK(>work, usb_otg_work);
> >
> > +   if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> > +   config->hcd_needs_companion)/* needs comanion ? */
> 
> %s/comanion/companion

Thank you for pointing it out!

Roger, would you fix this in your v7 patch set?

> I have a little puzzled with companion controller and shared hcd, let me
> post a topic for it.

I looked at the email thread.
It is very useful information to me! :)

Best regards,
Yoshihiro Shimoda

> Peter
> 
> > +   otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> > +
> > otg->wq = create_singlethread_workqueue("usb_otg");
> > if (!otg->wq) {
> > dev_err(dev, "otg: %s: can't create workqueue\n",
> > @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > unsigned int irqnum,
> > /* HCD will be started by OTG fsm when needed */
> > mutex_lock(>fsm.lock);
> > if (otg->primary_hcd.hcd) {
> > -   /* probably a shared HCD ? */
> > -   if (usb_otg_hcd_is_primary_hcd(hcd)) {
> > +   /* probably a shared HCD or a companion OHCI HCD ? */
> > +   if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> > +   usb_otg_hcd_is_primary_hcd(hcd)) {
> > dev_err(otg_dev, "otg: primary host already 
> > registered\n");
> > goto err;
> > }
> >
> > -   if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> > +   if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> > +   (hcd->shared_hcd == otg->primary_hcd.hcd)) {
> > if 

Re: [PATCH v2] fs: add file_dentry()

[Sasha Levin]

Hey Miklos,

On 03/23/2016 09:36 AM, Miklos Szeredi wrote:
> This series fixes bugs in nfs and ext4 due to 4bacc9c9234c ("overlayfs:
> Make f_path always point to the overlay and f_inode to the underlay").

Since that commit got backported into older -stable kernel, it would
appear that this file_dentry() series is relevant for pre-4.2 kernels as
well.

However, backporting it seems to be less than trivial.

Could you provide a backport for older -stable kernels please?


Thanks,
Sasha

Re: [PATCH v2] fs: add file_dentry()

[Sasha Levin]

Hey Miklos,

On 03/23/2016 09:36 AM, Miklos Szeredi wrote:
> This series fixes bugs in nfs and ext4 due to 4bacc9c9234c ("overlayfs:
> Make f_path always point to the overlay and f_inode to the underlay").

Since that commit got backported into older -stable kernel, it would
appear that this file_dentry() series is relevant for pre-4.2 kernels as
well.

However, backporting it seems to be less than trivial.

Could you provide a backport for older -stable kernels please?


Thanks,
Sasha

Re: [tip:sched/core] perf/core, sched: Don't use clock function pointer to determine clock

[Daniel Lezcano]

On Tue, Apr 19, 2016 at 02:34:50AM -0700, tip-bot for Alexander Shishkin wrote:
> Commit-ID:  f454bfddf6ba557381d8bf5df50eff778602ff23
> Gitweb: http://git.kernel.org/tip/f454bfddf6ba557381d8bf5df50eff778602ff23
> Author: Alexander Shishkin 
> AuthorDate: Thu, 14 Apr 2016 14:59:49 +0300
> Committer:  Ingo Molnar 
> CommitDate: Tue, 19 Apr 2016 10:55:29 +0200
> 
> perf/core, sched: Don't use clock function pointer to determine clock
> 
> Now that local_clock() is explicitly inlined in sched.h, taking its
> pointer would uninline it in the compilation unit where it's done,
> making (among other things) comparing pointers to this function
> produce different results in different compilation units.
> 
> Case in point, x86 perf core's user page updating function compares
> event's clock against _clock to see if it needs to set zero
> time offset related bits in the page.
> 
> This patch fixes the latter by looking at the "use_clockid" event
> attribute instead, to determine whether local clock is used. Fixing
> the uninlined local_clock() in perf core is left as an exercise for
> the author of the prior work.

Ouch! Good exercise :)

Re: [tip:sched/core] perf/core, sched: Don't use clock function pointer to determine clock

[Daniel Lezcano]

On Tue, Apr 19, 2016 at 02:34:50AM -0700, tip-bot for Alexander Shishkin wrote:
> Commit-ID:  f454bfddf6ba557381d8bf5df50eff778602ff23
> Gitweb: http://git.kernel.org/tip/f454bfddf6ba557381d8bf5df50eff778602ff23
> Author: Alexander Shishkin 
> AuthorDate: Thu, 14 Apr 2016 14:59:49 +0300
> Committer:  Ingo Molnar 
> CommitDate: Tue, 19 Apr 2016 10:55:29 +0200
> 
> perf/core, sched: Don't use clock function pointer to determine clock
> 
> Now that local_clock() is explicitly inlined in sched.h, taking its
> pointer would uninline it in the compilation unit where it's done,
> making (among other things) comparing pointers to this function
> produce different results in different compilation units.
> 
> Case in point, x86 perf core's user page updating function compares
> event's clock against _clock to see if it needs to set zero
> time offset related bits in the page.
> 
> This patch fixes the latter by looking at the "use_clockid" event
> attribute instead, to determine whether local clock is used. Fixing
> the uninlined local_clock() in perf core is left as an exercise for
> the author of the prior work.

Ouch! Good exercise :)

Re: [PATCH 0/4] ARM: cpuidle: use const and __initconst for cpuidle_ops

[Daniel Lezcano]

On Tue, Apr 19, 2016 at 06:31:14PM +0100, Lorenzo Pieralisi wrote:
> Hi Daniel,
> 
> On Fri, Mar 25, 2016 at 12:26:27PM +0100, Daniel Lezcano wrote:
> > On 03/22/2016 03:42 PM, Jisheng Zhang wrote:
> > >These trivial patches are similar as Masahiro posted in[1]. The main
> > >purpose is let cpuidle_ops structure be constified and replace
> > >"__initdata" with "__initconst".
> > >
> > >[1] 
> > >http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/365826.html
> > >
> > >Jisheng Zhang (4):
> > >   ARM: cpuidle: add const qualifier to cpuidle_ops member in structures
> > >   ARM: cpuidle: constify return value of arm_cpuidle_get_ops()
> > >   soc: qcom: spm: use const and __initconst for qcom_cpuidle_ops
> > >   drivers: firmware: psci: use const and __initconst for
> > > psci_cpuidle_ops
> > >
> > >  arch/arm/include/asm/cpuidle.h | 2 +-
> > >  arch/arm/kernel/cpuidle.c  | 6 +++---
> > >  drivers/firmware/psci.c| 2 +-
> > >  drivers/soc/qcom/spm.c | 2 +-
> > >  4 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > Sounds reasonable.
> 
> Are you taking them ? I could send the last one but it would
> make more sense for them to be part of the same series, I will
> check they do not conflict with patches queued for PSCI.

Ok, let me know via an acked-by.

Thanks.

  -- Daniel

Re: [PATCH 0/4] ARM: cpuidle: use const and __initconst for cpuidle_ops

[Daniel Lezcano]

On Tue, Apr 19, 2016 at 06:31:14PM +0100, Lorenzo Pieralisi wrote:
> Hi Daniel,
> 
> On Fri, Mar 25, 2016 at 12:26:27PM +0100, Daniel Lezcano wrote:
> > On 03/22/2016 03:42 PM, Jisheng Zhang wrote:
> > >These trivial patches are similar as Masahiro posted in[1]. The main
> > >purpose is let cpuidle_ops structure be constified and replace
> > >"__initdata" with "__initconst".
> > >
> > >[1] 
> > >http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/365826.html
> > >
> > >Jisheng Zhang (4):
> > >   ARM: cpuidle: add const qualifier to cpuidle_ops member in structures
> > >   ARM: cpuidle: constify return value of arm_cpuidle_get_ops()
> > >   soc: qcom: spm: use const and __initconst for qcom_cpuidle_ops
> > >   drivers: firmware: psci: use const and __initconst for
> > > psci_cpuidle_ops
> > >
> > >  arch/arm/include/asm/cpuidle.h | 2 +-
> > >  arch/arm/kernel/cpuidle.c  | 6 +++---
> > >  drivers/firmware/psci.c| 2 +-
> > >  drivers/soc/qcom/spm.c | 2 +-
> > >  4 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > Sounds reasonable.
> 
> Are you taking them ? I could send the last one but it would
> make more sense for them to be part of the same series, I will
> check they do not conflict with patches queued for PSCI.

Ok, let me know via an acked-by.

Thanks.

  -- Daniel

Re: [PATCH V11 0/4]perf/powerpc: Add ability to sample intr machine state in powerpc

[Michael Ellerman]

On Wed, 2016-04-20 at 00:57 -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Apr 18, 2016 at 03:17:11PM +0530, Anju T escreveu:
> > On Saturday 20 February 2016 10:32 AM, Anju T wrote:
> > > 
> > >  arch/powerpc/Kconfig|  1 +
> > >  arch/powerpc/include/uapi/asm/perf_regs.h   | 50 
> > >  arch/powerpc/perf/Makefile  |  1 +
> > >  arch/powerpc/perf/perf_regs.c   | 91 
> > > +
> > >  tools/perf/arch/powerpc/include/perf_regs.h | 69 ++
> > >  tools/perf/arch/powerpc/util/Build  |  1 +
> > >  tools/perf/arch/powerpc/util/perf_regs.c| 49 
> > >  tools/perf/config/Makefile  |  5 ++
> > >  8 files changed, 267 insertions(+)
> > >  create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h
> > >  create mode 100644 arch/powerpc/perf/perf_regs.c
> > >  create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h
> > >  create mode 100644 tools/perf/arch/powerpc/util/perf_regs.c
> > > 
> > 
> > Hi,
> > 
> > Can this be taken into the next tree?
> 
> Even the bits in tools/perf/ are arch specific, so I guess this goes via
> the powerpc tree? Michael?

Yeah if that's OK with you.

It doesn't look like it will generate much in the way of merge conflicts.

Do you want to send an ack?

cheers

Re: [PATCH V11 0/4]perf/powerpc: Add ability to sample intr machine state in powerpc

[Michael Ellerman]

On Wed, 2016-04-20 at 00:57 -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Apr 18, 2016 at 03:17:11PM +0530, Anju T escreveu:
> > On Saturday 20 February 2016 10:32 AM, Anju T wrote:
> > > 
> > >  arch/powerpc/Kconfig|  1 +
> > >  arch/powerpc/include/uapi/asm/perf_regs.h   | 50 
> > >  arch/powerpc/perf/Makefile  |  1 +
> > >  arch/powerpc/perf/perf_regs.c   | 91 
> > > +
> > >  tools/perf/arch/powerpc/include/perf_regs.h | 69 ++
> > >  tools/perf/arch/powerpc/util/Build  |  1 +
> > >  tools/perf/arch/powerpc/util/perf_regs.c| 49 
> > >  tools/perf/config/Makefile  |  5 ++
> > >  8 files changed, 267 insertions(+)
> > >  create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h
> > >  create mode 100644 arch/powerpc/perf/perf_regs.c
> > >  create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h
> > >  create mode 100644 tools/perf/arch/powerpc/util/perf_regs.c
> > > 
> > 
> > Hi,
> > 
> > Can this be taken into the next tree?
> 
> Even the bits in tools/perf/ are arch specific, so I guess this goes via
> the powerpc tree? Michael?

Yeah if that's OK with you.

It doesn't look like it will generate much in the way of merge conflicts.

Do you want to send an ack?

cheers

Re: [PATCH] clocksource/drivers/tango-xtal: Fix incorrect test

[Daniel Lezcano]

[ ... ]

> About the error handling... you advised against panic()
> because there might be other clock sources.
> 
> Does it makes sense to give up registering sched_clock
> and delay_timer when the clocksource registration fails?

Actually, all the problem is coming from the CLOCKSOURCE_OF_DECLARE where 
the init_func is a void (*init_func)(struct device_node *) signature, thus 
not allowing to return a value.

Because of that, the init code path of the different drivers are somewhat 
fuzzy when an error occurs.

If the function could return an error code, then the drivers would be 
written in a way to catch and handle the errors gracefully. That implies the 
clocksource-probe() routine will be able to detect when the init_func() is 
failing, trace it and count if one clocksource/clockevent succeed at boot 
time.

So because the latter, it would make sense to give up registering and leave 
a clean place in the init function when something is going wrong.

  -- Daniel

Re: [PATCH] clocksource/drivers/tango-xtal: Fix incorrect test

[Daniel Lezcano]

[ ... ]

> About the error handling... you advised against panic()
> because there might be other clock sources.
> 
> Does it makes sense to give up registering sched_clock
> and delay_timer when the clocksource registration fails?

Actually, all the problem is coming from the CLOCKSOURCE_OF_DECLARE where 
the init_func is a void (*init_func)(struct device_node *) signature, thus 
not allowing to return a value.

Because of that, the init code path of the different drivers are somewhat 
fuzzy when an error occurs.

If the function could return an error code, then the drivers would be 
written in a way to catch and handle the errors gracefully. That implies the 
clocksource-probe() routine will be able to detect when the init_func() is 
failing, trace it and count if one clocksource/clockevent succeed at boot 
time.

So because the latter, it would make sense to give up registering and leave 
a clean place in the init function when something is going wrong.

  -- Daniel

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Linus Torvalds]

On Tue, Apr 19, 2016 at 9:36 PM, Konstantin Khlebnikov  wrote:
> On Wed, Apr 20, 2016 at 6:04 AM, Eric W. Biederman
>>
>> The kernel.pty.reserve sysctl is neutered with no way currently
>> implemented to be able to use the reserved ptys.
>
> I think we could convert this into reserve for init user namespace,
> ssh in host will work even if containers eaten all ptys.

Yes. That's basically how it effectively worked before (ie everything
but the initial non-newinstance devpts mount would be limited to the
non-reserved numbers).

We required the non-init namespaces to do a newinstance mount, so the
whole test for "newinstance" was effectively the same thing as just
checking for the init namespace from a security standpoint.

And in fact, rewriting it in that form (ie checking for init_ns) would
just make it much more obvious what the intent it.

  Linus

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Linus Torvalds]

On Tue, Apr 19, 2016 at 9:36 PM, Konstantin Khlebnikov  wrote:
> On Wed, Apr 20, 2016 at 6:04 AM, Eric W. Biederman
>>
>> The kernel.pty.reserve sysctl is neutered with no way currently
>> implemented to be able to use the reserved ptys.
>
> I think we could convert this into reserve for init user namespace,
> ssh in host will work even if containers eaten all ptys.

Yes. That's basically how it effectively worked before (ie everything
but the initial non-newinstance devpts mount would be limited to the
non-reserved numbers).

We required the non-init namespaces to do a newinstance mount, so the
whole test for "newinstance" was effectively the same thing as just
checking for the init namespace from a security standpoint.

And in fact, rewriting it in that form (ie checking for init_ns) would
just make it much more obvious what the intent it.

  Linus

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

[Guenter Roeck]

On 04/19/2016 08:37 PM, 陈华才 wrote:

Hi,

Could you please remove the line "#define cpu_hwrena_impl_bits0xc000" 
in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h and try again?Thanks.



That fixes the problem.

Does this need to be addressed in qemu or in the Linux kernel ?

Thanks,
Guenter


Huacai

-- Original --
From:  "Guenter Roeck";
Date:  Wed, Apr 20, 2016 10:54 AM
To:  "Huacai Chen";
Cc:  "Ralf Baechle"; "linux-mips"; 
"linux-next"; "linux-kernel";
Subject:  next: fuloong2e qemu boot failure due to 'MIPS: Loongson: 
AddLoongson-3A R2 basic support'

Hi,

qemu fails to boot in -next for machine fulong2e with configuration
fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
Loongson-3A R2 basic support'. qemu hangs in boot, after displaying
"Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".

Bisect log is attached.

Guenter

---
# bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific files 
for 20160418
# good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
git bisect start 'HEAD' 'v4.6-rc3'
# bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking branch 
'ipvs-next/master'
git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
# bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking branch 
'btrfs-kdave/for-next'
git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
# good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking branch 
'omap/for-next'
git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
# good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking branch 
'microblaze/next'
git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
# bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3: Introduce 
CONFIG_LOONGSON3_ENHANCEMENT
git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
# good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be used 
on non-R2 or R6 cores
git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
# good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add Loongson1 
architecture entry
git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
# good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to use 
strict posix types
git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
# good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw 
watchpoints on MIPS R6
git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
# good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3: Adjust irq 
dispatch to speedup processing
git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
# bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set cache 
flush handlers to cache_noop
git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
# bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add 
Loongson-3A R2 basic support
git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
# first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: 
Add Loongson-3A R2 basic support

Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

[Guenter Roeck]

On 04/19/2016 08:37 PM, 陈华才 wrote:

Hi,

Could you please remove the line "#define cpu_hwrena_impl_bits0xc000" 
in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h and try again?Thanks.



That fixes the problem.

Does this need to be addressed in qemu or in the Linux kernel ?

Thanks,
Guenter


Huacai

-- Original --
From:  "Guenter Roeck";
Date:  Wed, Apr 20, 2016 10:54 AM
To:  "Huacai Chen";
Cc:  "Ralf Baechle"; "linux-mips"; 
"linux-next"; "linux-kernel";
Subject:  next: fuloong2e qemu boot failure due to 'MIPS: Loongson: 
AddLoongson-3A R2 basic support'

Hi,

qemu fails to boot in -next for machine fulong2e with configuration
fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
Loongson-3A R2 basic support'. qemu hangs in boot, after displaying
"Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".

Bisect log is attached.

Guenter

---
# bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific files 
for 20160418
# good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
git bisect start 'HEAD' 'v4.6-rc3'
# bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking branch 
'ipvs-next/master'
git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
# bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking branch 
'btrfs-kdave/for-next'
git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
# good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking branch 
'omap/for-next'
git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
# good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking branch 
'microblaze/next'
git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
# bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3: Introduce 
CONFIG_LOONGSON3_ENHANCEMENT
git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
# good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be used 
on non-R2 or R6 cores
git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
# good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add Loongson1 
architecture entry
git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
# good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to use 
strict posix types
git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
# good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw 
watchpoints on MIPS R6
git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
# good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3: Adjust irq 
dispatch to speedup processing
git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
# bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set cache 
flush handlers to cache_noop
git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
# bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add 
Loongson-3A R2 basic support
git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
# first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: 
Add Loongson-3A R2 basic support

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Konstantin Khlebnikov]

On Wed, Apr 20, 2016 at 6:04 AM, Eric W. Biederman
 wrote:
>
> The /dev/ptmx device node is changed to lookup the directory entry
> "pts" in the same directory as the /dev/ptmx device node was opened
> in.  If there is a "pts" entry and that entry is a devpts filesystem
> /dev/ptmx uses that filesystem.  Otherwise the open of /dev/ptmx
> fails.
>
> The DEVPTS_MULTIPLE_INSTANCES configuration option is removed,
> so that userspace can now safely depend on each mount of devpts
> creating a new instance of the filesystem.
>
> Each mount of devpts is now a separate and equal filesystem.
>
> The kernel.pty.reserve sysctl is neutered with no way currently
> implemented to be able to use the reserved ptys.

I think we could convert this into reserve for init user namespace,
ssh in host will work even if containers eaten all ptys.

>
> A new vfs helper path_pts is introduced that finds a directory entry
> named "pts" in the directory of the passed in path, and changes the
> passed in path to point to it.  The helper path_pts uses a function
> path_parent_directory that was factored out of follow_dotdot.
>
> In the implementation of devpts:
> - devpts_mnt is killed as it is no longer meaningful if all
>   mounts of devpts are equal.
> - pts_sb_from_inode is replaced by just inode->i_sb as all
>   cached inodes in the tty layer are now from the devpts
>   filesystem.
> - devpts_add_ref is rolled into the new function devpts_ptmx.
>   And the unnecessary inode hold is removed.
> - devpts_del_ref is renamed devpts_release and reduced
>   to just a deacrivate_super.
> - The newinstance mount option continues to be accepted but is now ignored.
>
> In devpts_fs.h definitions for when !CONFIG_UNIX98_PTYS are removed
> as they are never used.
>
> Documentation/filesystems/devices.txt is updated to describe
> the current situation.
>
> This has been verified to work properly on openwrt-15.05, centos5,
> centos6, centos7, debian-6.0.2, debian-7.9, debian-8.2,
> ubuntu-14.04.3, ubuntu-15.10, fedora23, magia-5, mint-17.3,
> opensuse-42.1, slackware-14.1, gentoo-20151225 (13.0?),
> archlinux-2015-12-01.  With the caveat that on centos6 and on
> slackware-14.1 that there wind up being two instances of the devpts
> filesystem mounted on /dev/pts, the lower copy does not end up getting
> used.
>
> Signed-off-by: "Eric W. Biederman" 
> ---
>  Documentation/filesystems/devpts.txt | 145 +++--
>  drivers/tty/Kconfig  |  11 --
>  drivers/tty/pty.c|  41 ---
>  fs/devpts/inode.c| 205 
> +--
>  fs/namei.c   |  58 --
>  include/linux/devpts_fs.h|  31 ++
>  include/linux/namei.h|   2 +
>  7 files changed, 148 insertions(+), 345 deletions(-)

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Konstantin Khlebnikov]

On Wed, Apr 20, 2016 at 6:04 AM, Eric W. Biederman
 wrote:
>
> The /dev/ptmx device node is changed to lookup the directory entry
> "pts" in the same directory as the /dev/ptmx device node was opened
> in.  If there is a "pts" entry and that entry is a devpts filesystem
> /dev/ptmx uses that filesystem.  Otherwise the open of /dev/ptmx
> fails.
>
> The DEVPTS_MULTIPLE_INSTANCES configuration option is removed,
> so that userspace can now safely depend on each mount of devpts
> creating a new instance of the filesystem.
>
> Each mount of devpts is now a separate and equal filesystem.
>
> The kernel.pty.reserve sysctl is neutered with no way currently
> implemented to be able to use the reserved ptys.

I think we could convert this into reserve for init user namespace,
ssh in host will work even if containers eaten all ptys.

>
> A new vfs helper path_pts is introduced that finds a directory entry
> named "pts" in the directory of the passed in path, and changes the
> passed in path to point to it.  The helper path_pts uses a function
> path_parent_directory that was factored out of follow_dotdot.
>
> In the implementation of devpts:
> - devpts_mnt is killed as it is no longer meaningful if all
>   mounts of devpts are equal.
> - pts_sb_from_inode is replaced by just inode->i_sb as all
>   cached inodes in the tty layer are now from the devpts
>   filesystem.
> - devpts_add_ref is rolled into the new function devpts_ptmx.
>   And the unnecessary inode hold is removed.
> - devpts_del_ref is renamed devpts_release and reduced
>   to just a deacrivate_super.
> - The newinstance mount option continues to be accepted but is now ignored.
>
> In devpts_fs.h definitions for when !CONFIG_UNIX98_PTYS are removed
> as they are never used.
>
> Documentation/filesystems/devices.txt is updated to describe
> the current situation.
>
> This has been verified to work properly on openwrt-15.05, centos5,
> centos6, centos7, debian-6.0.2, debian-7.9, debian-8.2,
> ubuntu-14.04.3, ubuntu-15.10, fedora23, magia-5, mint-17.3,
> opensuse-42.1, slackware-14.1, gentoo-20151225 (13.0?),
> archlinux-2015-12-01.  With the caveat that on centos6 and on
> slackware-14.1 that there wind up being two instances of the devpts
> filesystem mounted on /dev/pts, the lower copy does not end up getting
> used.
>
> Signed-off-by: "Eric W. Biederman" 
> ---
>  Documentation/filesystems/devpts.txt | 145 +++--
>  drivers/tty/Kconfig  |  11 --
>  drivers/tty/pty.c|  41 ---
>  fs/devpts/inode.c| 205 
> +--
>  fs/namei.c   |  58 --
>  include/linux/devpts_fs.h|  31 ++
>  include/linux/namei.h|   2 +
>  7 files changed, 148 insertions(+), 345 deletions(-)

Re: Nouveau crashes in 4.6-rc on arm64

[Alexandre Courbot]

On 04/11/2016 04:22 PM, Alexandre Courbot wrote:

Hi Robin,

On 04/09/2016 03:46 AM, Robin Murphy wrote:

Hi Alex,

On 08/04/16 05:47, Alexandre Courbot wrote:

Hi Robin,

On 04/07/2016 08:50 PM, Robin Murphy wrote:

Hello,

With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, from the
look of it by dereferencing some offset from NULL inside
nouveau_fbcon_imageblit(). My setup is an old XFX 7600GT card plugged
into an ARM Juno r1 board, which works fine with 4.5 and earlier.

Attached are a couple of logs from booting arm64 defconfig plus DRM and
Nouveau enabled - the second also has framebuffer console rotation
turned on, which interestingly seems to move the point of failure, and
the display does eventually come up to show the tail end of the
panic in
that case.

I might be able to find time for a full bisection next week if isn't
something sufficiently obvious to anyone who knows this driver.


Looking at the log it is not clear to me what could be causing this. I
can boot 4.6-rc2 with a GM206 card without any issue. A bisect would
indeed be useful here.


OK, turns out the lure of writing something to remotely drive a Juno and
parse kernel bootlogs through an automatic bisection was too great to
resist on a Friday afternoon :D

Bisection came down to 1733a2ad3674("drm/nouveau/device/pci: set as
non-CPU-coherent on ARM64"), and sure enough reverting that removes the
crash.


Thanks for taking the time to bisect this. And apologies as it seems my
commit is the reason for your troubles.

The CPU coherency flag is used for two things: explicitly sync buffers
pages when required, and allocating buffers that are not explicitly
synced (like fences or pushbuffers) using the DMA API. For this latter
use, it also accesses the buffer's content using the mapping provided by
dma_alloc_coherent() instead of creating a new one. All nouveau_bos are
supposed to be written using nouveau_bo_rd32(), and this function
handles the case of an DMA-API allocated object by detecting that the
result of ttm_kmap_obj_virtual() is NULL.

But as it turns out, OUT_RINGp() also calls ttm_kmap_obj_virtual() in
order to perform a memcpy and uses its result directly - which means we
are doing memcpy on a NULL pointer. We never caught this because we
typically do not use Nouveau's fbcon with an ARM setup.

I don't really like this special access for coherent objects, and
actually had a patch in my tree to attempt to remove it (attached).
Although it is not the whole solution (see below), the issue should at
least not be visible with it applied - could you confirm?


Hi Robin, could you confirm whether the attached patch in my previous 
mail helps with your problem?


Thanks!

Re: Nouveau crashes in 4.6-rc on arm64

[Alexandre Courbot]

On 04/11/2016 04:22 PM, Alexandre Courbot wrote:

Hi Robin,

On 04/09/2016 03:46 AM, Robin Murphy wrote:

Hi Alex,

On 08/04/16 05:47, Alexandre Courbot wrote:

Hi Robin,

On 04/07/2016 08:50 PM, Robin Murphy wrote:

Hello,

With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, from the
look of it by dereferencing some offset from NULL inside
nouveau_fbcon_imageblit(). My setup is an old XFX 7600GT card plugged
into an ARM Juno r1 board, which works fine with 4.5 and earlier.

Attached are a couple of logs from booting arm64 defconfig plus DRM and
Nouveau enabled - the second also has framebuffer console rotation
turned on, which interestingly seems to move the point of failure, and
the display does eventually come up to show the tail end of the
panic in
that case.

I might be able to find time for a full bisection next week if isn't
something sufficiently obvious to anyone who knows this driver.


Looking at the log it is not clear to me what could be causing this. I
can boot 4.6-rc2 with a GM206 card without any issue. A bisect would
indeed be useful here.


OK, turns out the lure of writing something to remotely drive a Juno and
parse kernel bootlogs through an automatic bisection was too great to
resist on a Friday afternoon :D

Bisection came down to 1733a2ad3674("drm/nouveau/device/pci: set as
non-CPU-coherent on ARM64"), and sure enough reverting that removes the
crash.


Thanks for taking the time to bisect this. And apologies as it seems my
commit is the reason for your troubles.

The CPU coherency flag is used for two things: explicitly sync buffers
pages when required, and allocating buffers that are not explicitly
synced (like fences or pushbuffers) using the DMA API. For this latter
use, it also accesses the buffer's content using the mapping provided by
dma_alloc_coherent() instead of creating a new one. All nouveau_bos are
supposed to be written using nouveau_bo_rd32(), and this function
handles the case of an DMA-API allocated object by detecting that the
result of ttm_kmap_obj_virtual() is NULL.

But as it turns out, OUT_RINGp() also calls ttm_kmap_obj_virtual() in
order to perform a memcpy and uses its result directly - which means we
are doing memcpy on a NULL pointer. We never caught this because we
typically do not use Nouveau's fbcon with an ARM setup.

I don't really like this special access for coherent objects, and
actually had a patch in my tree to attempt to remove it (attached).
Although it is not the whole solution (see below), the issue should at
least not be visible with it applied - could you confirm?


Hi Robin, could you confirm whether the attached patch in my previous 
mail helps with your problem?


Thanks!

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Eric W. Biederman]

Al Viro  writes:

> On Tue, Apr 19, 2016 at 10:43:03PM -0500, Eric W. Biederman wrote:
>> >> + if (!d_can_lookup(parent))
>> >> + return -ENOENT;
>> >
>> > And how, pray tell, would a parent of anything fail to be a directory?
>> 
>> It is to make that function be visually distinct from path_parentat
>> which does something rather different. 
>
> Huh?  I'm asking how can that condition ever turn out to be true.  Unless
> you really advocate something like
>   if (2 * 17 != 34)
>   return -234567; // to make it visually distinct from foobar(),
>   // which doesn't have such a test
> your reply doesn't seem to make any sense...

Oh apologies I thought you were asking about the naming of the function,
path_parent_directory.  Yes.  The d_can_lookup does appear to be redundant.

It definitely looks like bedtime for me.

>> >> + this.name = "pts";
>> >> + this.len = 3;
>> >> + this.hash = full_name_hash(this.name, this.len);
>> >> + if (parent->d_flags & DCACHE_OP_HASH) {
>> >> + int err = parent->d_op->d_hash(parent, );
>> >> + if (err < 0)
>> >> + return err;
>> >> + }
>> >> + inode_lock(parent->d_inode);
>> >
>> > What the hell for?  What does that lock on parent change for the
>> > dcache lookup you are doing here?
>> 
>> Good point. That is overkill. As we know the dentry is a mount point and
>> must be in the dcache, the customary lock for performing a lookup from
>> the disk is not necessary.
>
> Er...  To avoid reader confusion:
>   a) d_lookup() does *not* do a filesystem lookup
>   b) it does not need inode_lock()
>   c) it (and not a "lookup from the disk") is what's actually being
> called in the code in question.

And since I was stripping down the ordinary filesystem lookup path to
just the pieces needed I apparently wound up with a few extras.

Do you think it would be possible to guarantee an rcu lookup for the
operations in path_pts?  I think needing to perform a follow_mount makes
that impossible to guarantee.

All the caller wants is to find the superblock of the mounted filesystem
and increment sb->s_active.

Eric

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Eric W. Biederman]

Al Viro  writes:

> On Tue, Apr 19, 2016 at 10:43:03PM -0500, Eric W. Biederman wrote:
>> >> + if (!d_can_lookup(parent))
>> >> + return -ENOENT;
>> >
>> > And how, pray tell, would a parent of anything fail to be a directory?
>> 
>> It is to make that function be visually distinct from path_parentat
>> which does something rather different. 
>
> Huh?  I'm asking how can that condition ever turn out to be true.  Unless
> you really advocate something like
>   if (2 * 17 != 34)
>   return -234567; // to make it visually distinct from foobar(),
>   // which doesn't have such a test
> your reply doesn't seem to make any sense...

Oh apologies I thought you were asking about the naming of the function,
path_parent_directory.  Yes.  The d_can_lookup does appear to be redundant.

It definitely looks like bedtime for me.

>> >> + this.name = "pts";
>> >> + this.len = 3;
>> >> + this.hash = full_name_hash(this.name, this.len);
>> >> + if (parent->d_flags & DCACHE_OP_HASH) {
>> >> + int err = parent->d_op->d_hash(parent, );
>> >> + if (err < 0)
>> >> + return err;
>> >> + }
>> >> + inode_lock(parent->d_inode);
>> >
>> > What the hell for?  What does that lock on parent change for the
>> > dcache lookup you are doing here?
>> 
>> Good point. That is overkill. As we know the dentry is a mount point and
>> must be in the dcache, the customary lock for performing a lookup from
>> the disk is not necessary.
>
> Er...  To avoid reader confusion:
>   a) d_lookup() does *not* do a filesystem lookup
>   b) it does not need inode_lock()
>   c) it (and not a "lookup from the disk") is what's actually being
> called in the code in question.

And since I was stripping down the ordinary filesystem lookup path to
just the pieces needed I apparently wound up with a few extras.

Do you think it would be possible to guarantee an rcu lookup for the
operations in path_pts?  I think needing to perform a follow_mount makes
that impossible to guarantee.

All the caller wants is to find the superblock of the mounted filesystem
and increment sb->s_active.

Eric

Re: [PATCH] irq_poll: Remove redundant barrier when using clear_bit_unlock()

[Davidlohr Bueso]

On Tue, 19 Apr 2016, Bart Van Assche wrote:


On 04/16/2016 01:55 PM, Davidlohr Bueso wrote:

... as the call obviously already implies unlock/RC semantics,
therefore lets get rid of the superfluous smp_mb calls.


Hello Davidlohr,

Are you sure that this patch has been sent to the right person? I have 
helped to review a change in this code but I'm not the maintainer of 
this code.


Ah, adding Andrew and Ingo, not sure who is responsible for these bits.

Thanks,
Davidlohr

Re: [PATCH] irq_poll: Remove redundant barrier when using clear_bit_unlock()

[Davidlohr Bueso]

On Tue, 19 Apr 2016, Bart Van Assche wrote:


On 04/16/2016 01:55 PM, Davidlohr Bueso wrote:

... as the call obviously already implies unlock/RC semantics,
therefore lets get rid of the superfluous smp_mb calls.


Hello Davidlohr,

Are you sure that this patch has been sent to the right person? I have 
helped to review a change in this code but I'm not the maintainer of 
this code.


Ah, adding Andrew and Ingo, not sure who is responsible for these bits.

Thanks,
Davidlohr

[PATCH -tip v3 3/3] locking/pvqspinlock: Robustify init_qspinlock_stat()

[Davidlohr Bueso]

locking/pvqspinlock: Robustify init_qspinlock_stat()

Specifically around the debugfs file creation calls,
I have no idea if they could ever possibly fail, but
this is core code (debug aside) so lets at least
check the return value and inform anything fishy.

Signed-off-by: Davidlohr Bueso 
---
kernel/locking/qspinlock_stat.h | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h
index 72722334237a..22e025309845 100644
--- a/kernel/locking/qspinlock_stat.h
+++ b/kernel/locking/qspinlock_stat.h
@@ -212,10 +212,8 @@ static int __init init_qspinlock_stat(void)
struct dentry *d_qstat = debugfs_create_dir("qlockstat", NULL);
int i;

-   if (!d_qstat) {
-   pr_warn("Could not create 'qlockstat' debugfs directory\n");
-   return 0;
-   }
+   if (!d_qstat)
+   goto out;

/*
 * Create the debugfs files
@@ -225,12 +223,20 @@ static int __init init_qspinlock_stat(void)
 * performance.
 */
for (i = 0; i < qstat_num; i++)
-   debugfs_create_file(qstat_names[i], 0400, d_qstat,
-  (void *)(long)i, _qstat);
+   if (!debugfs_create_file(qstat_names[i], 0400, d_qstat,
+(void *)(long)i, _qstat))
+   goto fail_undo;
+
+   if (!debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
+(void *)(long)qstat_reset_cnts, _qstat))
+   goto fail_undo;

-   debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
-  (void *)(long)qstat_reset_cnts, _qstat);
return 0;
+fail_undo:
+   debugfs_remove_recursive(d_qstat);
+out:
+   pr_warn("Could not create 'qlockstat' debugfs entries\n");
+   return -ENOMEM;
}
fs_initcall(init_qspinlock_stat);

--
2.8.1

[PATCH -tip v3 3/3] locking/pvqspinlock: Robustify init_qspinlock_stat()

[Davidlohr Bueso]

locking/pvqspinlock: Robustify init_qspinlock_stat()

Specifically around the debugfs file creation calls,
I have no idea if they could ever possibly fail, but
this is core code (debug aside) so lets at least
check the return value and inform anything fishy.

Signed-off-by: Davidlohr Bueso 
---
kernel/locking/qspinlock_stat.h | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h
index 72722334237a..22e025309845 100644
--- a/kernel/locking/qspinlock_stat.h
+++ b/kernel/locking/qspinlock_stat.h
@@ -212,10 +212,8 @@ static int __init init_qspinlock_stat(void)
struct dentry *d_qstat = debugfs_create_dir("qlockstat", NULL);
int i;

-   if (!d_qstat) {
-   pr_warn("Could not create 'qlockstat' debugfs directory\n");
-   return 0;
-   }
+   if (!d_qstat)
+   goto out;

/*
 * Create the debugfs files
@@ -225,12 +223,20 @@ static int __init init_qspinlock_stat(void)
 * performance.
 */
for (i = 0; i < qstat_num; i++)
-   debugfs_create_file(qstat_names[i], 0400, d_qstat,
-  (void *)(long)i, _qstat);
+   if (!debugfs_create_file(qstat_names[i], 0400, d_qstat,
+(void *)(long)i, _qstat))
+   goto fail_undo;
+
+   if (!debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
+(void *)(long)qstat_reset_cnts, _qstat))
+   goto fail_undo;

-   debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
-  (void *)(long)qstat_reset_cnts, _qstat);
return 0;
+fail_undo:
+   debugfs_remove_recursive(d_qstat);
+out:
+   pr_warn("Could not create 'qlockstat' debugfs entries\n");
+   return -ENOMEM;
}
fs_initcall(init_qspinlock_stat);

--
2.8.1

Re: [PATCH -tip v2] locking/pvqspinlock: Robustify init_qspinlock_stat()

[Davidlohr Bueso]

+   pr_info("Could not create 'qlockstat' debugfs entries\n");


Please ignore this, I was not meaning to change pr_warn level, this was
simply a stale version. Sending v3 *sigh*.

Re: [PATCH -tip v2] locking/pvqspinlock: Robustify init_qspinlock_stat()

[Davidlohr Bueso]

+   pr_info("Could not create 'qlockstat' debugfs entries\n");


Please ignore this, I was not meaning to change pr_warn level, this was
simply a stale version. Sending v3 *sigh*.

Re: [PATCH 00/50] pinctrl: Add and use devm_ apis for pinctrl_{register, unregister}

[Masahiro Yamada]

Hi.

2016-03-15 17:31 GMT+09:00 Linus Walleij :
> On Wed, Mar 9, 2016 at 3:23 PM, Laxman Dewangan  wrote:
>
>>> Pushed the change at:
>>> Branch "devm_pinctrl_register" of
>>> https://github.com/ldewangan/linux-upstream.git.
>>>
>>> Base repo is
>>> for-next of
>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
>>>
>>>
>>> If required, I can send the V2 version of list with acks.
>>
>> Let me know if I need to send full series (V2 with collected ack) again or
>> fine to pull it from above location.
>
> Please collect the ACKs on your branch and ask me to pull it after v4.6-rc1.
> No need to resend the patches.
>
> Unfortunately it arrived too late for the merge window, but hey: we got the
> devm gpiochip in for v4.6.


Not pulled yet?

I want to do my development on top of the devm_pinctrl_register series.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 00/50] pinctrl: Add and use devm_ apis for pinctrl_{register, unregister}

[Masahiro Yamada]

Hi.

2016-03-15 17:31 GMT+09:00 Linus Walleij :
> On Wed, Mar 9, 2016 at 3:23 PM, Laxman Dewangan  wrote:
>
>>> Pushed the change at:
>>> Branch "devm_pinctrl_register" of
>>> https://github.com/ldewangan/linux-upstream.git.
>>>
>>> Base repo is
>>> for-next of
>>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
>>>
>>>
>>> If required, I can send the V2 version of list with acks.
>>
>> Let me know if I need to send full series (V2 with collected ack) again or
>> fine to pull it from above location.
>
> Please collect the ACKs on your branch and ask me to pull it after v4.6-rc1.
> No need to resend the patches.
>
> Unfortunately it arrived too late for the merge window, but hey: we got the
> devm gpiochip in for v4.6.


Not pulled yet?

I want to do my development on top of the devm_pinctrl_register series.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Al Viro]

On Tue, Apr 19, 2016 at 10:43:03PM -0500, Eric W. Biederman wrote:
> >> +  if (!d_can_lookup(parent))
> >> +  return -ENOENT;
> >
> > And how, pray tell, would a parent of anything fail to be a directory?
> 
> It is to make that function be visually distinct from path_parentat
> which does something rather different. 

Huh?  I'm asking how can that condition ever turn out to be true.  Unless
you really advocate something like
if (2 * 17 != 34)
return -234567; // to make it visually distinct from foobar(),
// which doesn't have such a test
your reply doesn't seem to make any sense...

> >> +  this.name = "pts";
> >> +  this.len = 3;
> >> +  this.hash = full_name_hash(this.name, this.len);
> >> +  if (parent->d_flags & DCACHE_OP_HASH) {
> >> +  int err = parent->d_op->d_hash(parent, );
> >> +  if (err < 0)
> >> +  return err;
> >> +  }
> >> +  inode_lock(parent->d_inode);
> >
> > What the hell for?  What does that lock on parent change for the
> > dcache lookup you are doing here?
> 
> Good point. That is overkill. As we know the dentry is a mount point and
> must be in the dcache, the customary lock for performing a lookup from
> the disk is not necessary.

Er...  To avoid reader confusion:
a) d_lookup() does *not* do a filesystem lookup
b) it does not need inode_lock()
c) it (and not a "lookup from the disk") is what's actually being
called in the code in question.

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Al Viro]

On Tue, Apr 19, 2016 at 10:43:03PM -0500, Eric W. Biederman wrote:
> >> +  if (!d_can_lookup(parent))
> >> +  return -ENOENT;
> >
> > And how, pray tell, would a parent of anything fail to be a directory?
> 
> It is to make that function be visually distinct from path_parentat
> which does something rather different. 

Huh?  I'm asking how can that condition ever turn out to be true.  Unless
you really advocate something like
if (2 * 17 != 34)
return -234567; // to make it visually distinct from foobar(),
// which doesn't have such a test
your reply doesn't seem to make any sense...

> >> +  this.name = "pts";
> >> +  this.len = 3;
> >> +  this.hash = full_name_hash(this.name, this.len);
> >> +  if (parent->d_flags & DCACHE_OP_HASH) {
> >> +  int err = parent->d_op->d_hash(parent, );
> >> +  if (err < 0)
> >> +  return err;
> >> +  }
> >> +  inode_lock(parent->d_inode);
> >
> > What the hell for?  What does that lock on parent change for the
> > dcache lookup you are doing here?
> 
> Good point. That is overkill. As we know the dentry is a mount point and
> must be in the dcache, the customary lock for performing a lookup from
> the disk is not necessary.

Er...  To avoid reader confusion:
a) d_lookup() does *not* do a filesystem lookup
b) it does not need inode_lock()
c) it (and not a "lookup from the disk") is what's actually being
called in the code in question.

[PATCH -tip v2] locking/pvqspinlock: Robustify init_qspinlock_stat()

[Davidlohr Bueso]

Specifically around the debugfs file creation calls,
I have no idea if they could ever possibly fail, but
this is core code (debug aside) so lets at least
check the return value and inform anything fishy.

Signed-off-by: Davidlohr Bueso 
---
kernel/locking/qspinlock_stat.h | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h
index 72722334237a..fa0863423a04 100644
--- a/kernel/locking/qspinlock_stat.h
+++ b/kernel/locking/qspinlock_stat.h
@@ -212,10 +212,8 @@ static int __init init_qspinlock_stat(void)
struct dentry *d_qstat = debugfs_create_dir("qlockstat", NULL);
int i;

-   if (!d_qstat) {
-   pr_warn("Could not create 'qlockstat' debugfs directory\n");
-   return 0;
-   }
+   if (!d_qstat)
+   goto out;

/*
 * Create the debugfs files
@@ -225,12 +223,20 @@ static int __init init_qspinlock_stat(void)
 * performance.
 */
for (i = 0; i < qstat_num; i++)
-   debugfs_create_file(qstat_names[i], 0400, d_qstat,
-  (void *)(long)i, _qstat);
+   if (!debugfs_create_file(qstat_names[i], 0400, d_qstat,
+(void *)(long)i, _qstat))
+   goto fail_undo;
+
+   if (!debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
+(void *)(long)qstat_reset_cnts, _qstat))
+   goto fail_undo;

-   debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
-  (void *)(long)qstat_reset_cnts, _qstat);
return 0;
+fail_undo:
+   debugfs_remove_recursive(d_qstat);
+out:
+   pr_info("Could not create 'qlockstat' debugfs entries\n");
+   return -ENOMEM;
}
fs_initcall(init_qspinlock_stat);

--
2.8.1

[PATCH -tip v2] locking/pvqspinlock: Robustify init_qspinlock_stat()

[Davidlohr Bueso]

Specifically around the debugfs file creation calls,
I have no idea if they could ever possibly fail, but
this is core code (debug aside) so lets at least
check the return value and inform anything fishy.

Signed-off-by: Davidlohr Bueso 
---
kernel/locking/qspinlock_stat.h | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h
index 72722334237a..fa0863423a04 100644
--- a/kernel/locking/qspinlock_stat.h
+++ b/kernel/locking/qspinlock_stat.h
@@ -212,10 +212,8 @@ static int __init init_qspinlock_stat(void)
struct dentry *d_qstat = debugfs_create_dir("qlockstat", NULL);
int i;

-   if (!d_qstat) {
-   pr_warn("Could not create 'qlockstat' debugfs directory\n");
-   return 0;
-   }
+   if (!d_qstat)
+   goto out;

/*
 * Create the debugfs files
@@ -225,12 +223,20 @@ static int __init init_qspinlock_stat(void)
 * performance.
 */
for (i = 0; i < qstat_num; i++)
-   debugfs_create_file(qstat_names[i], 0400, d_qstat,
-  (void *)(long)i, _qstat);
+   if (!debugfs_create_file(qstat_names[i], 0400, d_qstat,
+(void *)(long)i, _qstat))
+   goto fail_undo;
+
+   if (!debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
+(void *)(long)qstat_reset_cnts, _qstat))
+   goto fail_undo;

-   debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
-  (void *)(long)qstat_reset_cnts, _qstat);
return 0;
+fail_undo:
+   debugfs_remove_recursive(d_qstat);
+out:
+   pr_info("Could not create 'qlockstat' debugfs entries\n");
+   return -ENOMEM;
}
fs_initcall(init_qspinlock_stat);

--
2.8.1

Re: [PATCH V11 0/4]perf/powerpc: Add ability to sample intr machine state in powerpc

[Arnaldo Carvalho de Melo]

Em Mon, Apr 18, 2016 at 03:17:11PM +0530, Anju T escreveu:
> On Saturday 20 February 2016 10:32 AM, Anju T wrote:
> >This short patch series adds the ability to sample the interrupted
> >machine state for each hardware sample.
> >
> >To test this patchset,
> >Eg:
> >
> >$ perf record -I?   # list supported registers
> >
> >output:
> >available registers: r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 
> >r16 r17 r18 r19 r20 r21 r22 r23 r24 r25 r26 r27 r28 r29 r30 r31 nip msr 
> >orig_r3 ctr link xer ccr softe trap dar dsisr
> >
> >  usage: perf record [] []
> > or: perf record [] --  []
> >
> > -I, --intr-regs[=]
> >   sample selected machine registers on interrupt, 
> > use -I ? to list register names
> >
> >
> >$ perf record -I ls   # record machine state at interrupt
> >$ perf script -D  # read the perf.data file
> >
> >Sample output obtained for this patchset/ output looks like as follows:
> >
> >496768515470 0x1988 [0x188]: PERF_RECORD_SAMPLE(IP, 0x1): 4522/4522: 
> >0xc01e538c period: 1 addr: 0
> >... intr regs: mask 0x7ff ABI 64-bit
> > r00xc01e5e34
> > r10xc00fe733f9a0
> > r20xc1523100
> > r30xc00ffaadeb60
> > r40xc3456800
> > r50x73a9b5e000
> > r60x1e00
> > r70x0
> > r80x0
> > r90x0
> > r10   0x1
> > r11   0x0
> > r12   0x24022822
> > r13   0xcfeec180
> > r14   0x0
> > r15   0xc01e4be18800
> > r16   0x0
> > r17   0xc00ffaac5000
> > r18   0xc00fe733f8a0
> > r19   0xc1523100
> > r20   0xc009fd1c
> > r21   0xc00fcaa69000
> > r22   0xc01e4968
> > r23   0xc1523100
> > r24   0xc00fe733f850
> > r25   0xc00fcaa69000
> > r26   0xc3b8fcf0
> > r27   0xfead
> > r28   0x0
> > r29   0xc00fcaa69000
> > r30   0x1
> > r31   0x0
> > nip   0xc01dd320
> > msr   0x90009032
> > orig_r3 0xc01e538c
> > ctr   0xc009d550
> > link  0xc01e5e34
> > xer   0x0
> > ccr   0x84022882
> > softe 0x0
> > trap  0xf01
> > dar   0x0
> > dsisr 0xf0004006004
> >  ... thread: :4522:4522
> >  .. dso: 
> > /root/.debug/.build-id/b0/ef11b1a1629e62ac9de75199117ee5ef9469e9
> >:4522  4522   496.768515:  1 cycles:  c01e538c 
> > .perf_event_context_sched_in (/boot/vmlinux)
> >
> >
> >
> >Changes from v10:
> >
> >- Included SOFTE as suggested by mpe
> >- The name of registers displayed is  changed from
> >   gpr* to r* also the macro names changed from
> >   PERF_REG_POWERPC_GPR* to PERF_REG_POWERPC_R*.
> >- The conflict in returning the ABI is resolved.
> >- #define PERF_REG_SP  is again changed to  PERF_REG_POWERPC_R1
> >- Comment in tools/perf/config/Makefile is updated.
> >- removed the "Reviewed-By" tag as the patch has logic changes.
> >
> >
> >Changes from V9:
> >
> >- Changed the name displayed for link register from "lnk" to "link" in
> >   tools/perf/arch/powerpc/include/perf_regs.h
> >
> >changes from V8:
> >
> >- Corrected the indentation issue in the Makefile mentioned in 3rd patch
> >
> >Changes from V7:
> >
> >- Addressed the new line issue in 3rd patch.
> >
> >Changes from V6:
> >
> >- Corrected the typo in patch  tools/perf: Map the ID values with register 
> >names.
> >   ie #define PERF_REG_SP  PERF_REG_POWERPC_R1 should be #define PERF_REG_SP 
> >   PERF_REG_POWERPC_GPR1
> >
> >
> >Changes from V5:
> >
> >- Enabled perf_sample_regs_user also in this patch set.Functions added in
> >arch/powerpc/perf/perf_regs.c
> >- Added Maddy's patch to this patchset for enabling -I? option which will
> >   list the supported register names.
> >
> >
> >Changes from V4:
> >
> >- Removed the softe and MQ from all patches
> >- Switch case is replaced with an array in the 3rd patch
> >
> >Changes from V3:
> >
> >- Addressed the comments by Sukadev regarding the nits in the descriptions.
> >- Modified the subject of first patch.
> >- Included the sample output in the 3rd patch also.
> >
> >Changes from V2:
> >
> >- tools/perf/config/Makefile is moved to the patch tools/perf.
> >- The patchset is reordered.
> >- perf_regs_load() function is used for the dwarf unwind test.Since it is 
> >not required here,
> >   it is removed from tools/perf/arch/powerpc/include/perf_regs.h
> >- PERF_REGS_POWERPC_RESULT is removed.
> >
> >Changes from V1:
> >
> >- Solved the name missmatch issue in the from and signed-off field of the 
> >patch series.
> >- Added necessary comments in the 3rd patch ie perf/powerpc ,as suggested by 
> >Maddy.
> >
> >
> >
> >Anju T (3):
> >   perf/powerpc: assign an id to each powerpc register
> >   perf/powerpc: add support for sampling intr machine state
> >   tools/perf: Map the ID values with register names
> >
> >Madhavan Srinivasan (1):
> >   tool/perf: Add 

Re: [BUG] machine check Oops on Alpha

[Bob Tracy]

On Wed, Apr 20, 2016 at 01:46:13AM +0100, Maciej W. Rozycki wrote:
>  I can see if I can find anything suspicious there if you send me original 
> copies (i.e. those that oopsed) of arch/alpha/kernel/irq_alpha.o and 
> arch/alpha/kernel/core_cia.o.
> 
> > Machine has been stable since the machine check.  Kernel is 4.6.0-rc4.
> 
>  Yeah, it was a correctable error after all.

:-)

Regrettably, the constituent object files of the 4.5.0 kernel that was
generating the "Oopses" are no longer available.  I *do* have the
"vmlinux.gz" image, the corresponding "System.map-4.5.0", and all the
related modules if those would be of any use.  With a bit of guidance, I
could probably extract the desired objects from the kernel image.
Alternatively, if there's an upload location where I could leave you the
image and map files, that might work as well.

Pending your reply, I'll see if I can figure out how to dump/extract the
requested object code from the kernel image file.

--Bob

Re: [PATCH V11 0/4]perf/powerpc: Add ability to sample intr machine state in powerpc

[Arnaldo Carvalho de Melo]

Em Mon, Apr 18, 2016 at 03:17:11PM +0530, Anju T escreveu:
> On Saturday 20 February 2016 10:32 AM, Anju T wrote:
> >This short patch series adds the ability to sample the interrupted
> >machine state for each hardware sample.
> >
> >To test this patchset,
> >Eg:
> >
> >$ perf record -I?   # list supported registers
> >
> >output:
> >available registers: r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 
> >r16 r17 r18 r19 r20 r21 r22 r23 r24 r25 r26 r27 r28 r29 r30 r31 nip msr 
> >orig_r3 ctr link xer ccr softe trap dar dsisr
> >
> >  usage: perf record [] []
> > or: perf record [] --  []
> >
> > -I, --intr-regs[=]
> >   sample selected machine registers on interrupt, 
> > use -I ? to list register names
> >
> >
> >$ perf record -I ls   # record machine state at interrupt
> >$ perf script -D  # read the perf.data file
> >
> >Sample output obtained for this patchset/ output looks like as follows:
> >
> >496768515470 0x1988 [0x188]: PERF_RECORD_SAMPLE(IP, 0x1): 4522/4522: 
> >0xc01e538c period: 1 addr: 0
> >... intr regs: mask 0x7ff ABI 64-bit
> > r00xc01e5e34
> > r10xc00fe733f9a0
> > r20xc1523100
> > r30xc00ffaadeb60
> > r40xc3456800
> > r50x73a9b5e000
> > r60x1e00
> > r70x0
> > r80x0
> > r90x0
> > r10   0x1
> > r11   0x0
> > r12   0x24022822
> > r13   0xcfeec180
> > r14   0x0
> > r15   0xc01e4be18800
> > r16   0x0
> > r17   0xc00ffaac5000
> > r18   0xc00fe733f8a0
> > r19   0xc1523100
> > r20   0xc009fd1c
> > r21   0xc00fcaa69000
> > r22   0xc01e4968
> > r23   0xc1523100
> > r24   0xc00fe733f850
> > r25   0xc00fcaa69000
> > r26   0xc3b8fcf0
> > r27   0xfead
> > r28   0x0
> > r29   0xc00fcaa69000
> > r30   0x1
> > r31   0x0
> > nip   0xc01dd320
> > msr   0x90009032
> > orig_r3 0xc01e538c
> > ctr   0xc009d550
> > link  0xc01e5e34
> > xer   0x0
> > ccr   0x84022882
> > softe 0x0
> > trap  0xf01
> > dar   0x0
> > dsisr 0xf0004006004
> >  ... thread: :4522:4522
> >  .. dso: 
> > /root/.debug/.build-id/b0/ef11b1a1629e62ac9de75199117ee5ef9469e9
> >:4522  4522   496.768515:  1 cycles:  c01e538c 
> > .perf_event_context_sched_in (/boot/vmlinux)
> >
> >
> >
> >Changes from v10:
> >
> >- Included SOFTE as suggested by mpe
> >- The name of registers displayed is  changed from
> >   gpr* to r* also the macro names changed from
> >   PERF_REG_POWERPC_GPR* to PERF_REG_POWERPC_R*.
> >- The conflict in returning the ABI is resolved.
> >- #define PERF_REG_SP  is again changed to  PERF_REG_POWERPC_R1
> >- Comment in tools/perf/config/Makefile is updated.
> >- removed the "Reviewed-By" tag as the patch has logic changes.
> >
> >
> >Changes from V9:
> >
> >- Changed the name displayed for link register from "lnk" to "link" in
> >   tools/perf/arch/powerpc/include/perf_regs.h
> >
> >changes from V8:
> >
> >- Corrected the indentation issue in the Makefile mentioned in 3rd patch
> >
> >Changes from V7:
> >
> >- Addressed the new line issue in 3rd patch.
> >
> >Changes from V6:
> >
> >- Corrected the typo in patch  tools/perf: Map the ID values with register 
> >names.
> >   ie #define PERF_REG_SP  PERF_REG_POWERPC_R1 should be #define PERF_REG_SP 
> >   PERF_REG_POWERPC_GPR1
> >
> >
> >Changes from V5:
> >
> >- Enabled perf_sample_regs_user also in this patch set.Functions added in
> >arch/powerpc/perf/perf_regs.c
> >- Added Maddy's patch to this patchset for enabling -I? option which will
> >   list the supported register names.
> >
> >
> >Changes from V4:
> >
> >- Removed the softe and MQ from all patches
> >- Switch case is replaced with an array in the 3rd patch
> >
> >Changes from V3:
> >
> >- Addressed the comments by Sukadev regarding the nits in the descriptions.
> >- Modified the subject of first patch.
> >- Included the sample output in the 3rd patch also.
> >
> >Changes from V2:
> >
> >- tools/perf/config/Makefile is moved to the patch tools/perf.
> >- The patchset is reordered.
> >- perf_regs_load() function is used for the dwarf unwind test.Since it is 
> >not required here,
> >   it is removed from tools/perf/arch/powerpc/include/perf_regs.h
> >- PERF_REGS_POWERPC_RESULT is removed.
> >
> >Changes from V1:
> >
> >- Solved the name missmatch issue in the from and signed-off field of the 
> >patch series.
> >- Added necessary comments in the 3rd patch ie perf/powerpc ,as suggested by 
> >Maddy.
> >
> >
> >
> >Anju T (3):
> >   perf/powerpc: assign an id to each powerpc register
> >   perf/powerpc: add support for sampling intr machine state
> >   tools/perf: Map the ID values with register names
> >
> >Madhavan Srinivasan (1):
> >   tool/perf: Add 

Re: [BUG] machine check Oops on Alpha

[Bob Tracy]

On Wed, Apr 20, 2016 at 01:46:13AM +0100, Maciej W. Rozycki wrote:
>  I can see if I can find anything suspicious there if you send me original 
> copies (i.e. those that oopsed) of arch/alpha/kernel/irq_alpha.o and 
> arch/alpha/kernel/core_cia.o.
> 
> > Machine has been stable since the machine check.  Kernel is 4.6.0-rc4.
> 
>  Yeah, it was a correctable error after all.

:-)

Regrettably, the constituent object files of the 4.5.0 kernel that was
generating the "Oopses" are no longer available.  I *do* have the
"vmlinux.gz" image, the corresponding "System.map-4.5.0", and all the
related modules if those would be of any use.  With a bit of guidance, I
could probably extract the desired objects from the kernel image.
Alternatively, if there's an upload location where I could leave you the
image and map files, that might work as well.

Pending your reply, I'll see if I can figure out how to dump/extract the
requested object code from the kernel image file.

--Bob

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Eric W. Biederman]

Al Viro  writes:

> On Tue, Apr 19, 2016 at 10:04:20PM -0500, Eric W. Biederman wrote:
>> +#ifdef CONFIG_UNIX98_PTYS
>> +int path_pts(struct path *path)
>> +{
>> +/* Find "pts" in the same directory as the input path */
>> +struct dentry *child, *parent;
>> +struct qstr this;
>> +int ret;
>> +
>> +ret = path_parent_directory(path);
>> +if (ret)
>> +return ret;
>> +
>> +parent = path->dentry;
>> +if (!d_can_lookup(parent))
>> +return -ENOENT;
>
> And how, pray tell, would a parent of anything fail to be a directory?

It is to make that function be visually distinct from path_parentat
which does something rather different. 

>> +this.name = "pts";
>> +this.len = 3;
>> +this.hash = full_name_hash(this.name, this.len);
>> +if (parent->d_flags & DCACHE_OP_HASH) {
>> +int err = parent->d_op->d_hash(parent, );
>> +if (err < 0)
>> +return err;
>> +}
>> +inode_lock(parent->d_inode);
>
> What the hell for?  What does that lock on parent change for the
> dcache lookup you are doing here?

Good point. That is overkill. As we know the dentry is a mount point and
must be in the dcache, the customary lock for performing a lookup from
the disk is not necessary.

>> +child = d_lookup(parent, );
>> +inode_unlock(parent->d_inode);
>> +if (!child)
>> +return -ENOENT;
>
> Take a look at d_hash_and_lookup(), BTW...

Yes.  That does look like a reasonable simplification.

Eric

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Eric W. Biederman]

Al Viro  writes:

> On Tue, Apr 19, 2016 at 10:04:20PM -0500, Eric W. Biederman wrote:
>> +#ifdef CONFIG_UNIX98_PTYS
>> +int path_pts(struct path *path)
>> +{
>> +/* Find "pts" in the same directory as the input path */
>> +struct dentry *child, *parent;
>> +struct qstr this;
>> +int ret;
>> +
>> +ret = path_parent_directory(path);
>> +if (ret)
>> +return ret;
>> +
>> +parent = path->dentry;
>> +if (!d_can_lookup(parent))
>> +return -ENOENT;
>
> And how, pray tell, would a parent of anything fail to be a directory?

It is to make that function be visually distinct from path_parentat
which does something rather different. 

>> +this.name = "pts";
>> +this.len = 3;
>> +this.hash = full_name_hash(this.name, this.len);
>> +if (parent->d_flags & DCACHE_OP_HASH) {
>> +int err = parent->d_op->d_hash(parent, );
>> +if (err < 0)
>> +return err;
>> +}
>> +inode_lock(parent->d_inode);
>
> What the hell for?  What does that lock on parent change for the
> dcache lookup you are doing here?

Good point. That is overkill. As we know the dentry is a mount point and
must be in the dcache, the customary lock for performing a lookup from
the disk is not necessary.

>> +child = d_lookup(parent, );
>> +inode_unlock(parent->d_inode);
>> +if (!child)
>> +return -ENOENT;
>
> Take a look at d_hash_and_lookup(), BTW...

Yes.  That does look like a reasonable simplification.

Eric

Re: [PATCH v8 1/3] gpio: dwapb: remove name from dwapb_port_property

[kbuild test robot]

Hi,

[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.6-rc4 next-20160419]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Jiang-Qiu/gpio-dwapb-add-gpio-signaled-acpi-event-support-for-power-button/20160420-114023
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: x86_64-randconfig-x010-201616 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpio/gpio-dwapb.c: In function 'dwapb_gpio_add_port':
>> drivers/gpio/gpio-dwapb.c:412:22: warning: unknown conversion type character 
>> 0xa in format [-Wformat=]
  dev_err(gpio->dev, "failed to init gpio chip for port%\n",
 ^
>> drivers/gpio/gpio-dwapb.c:412:22: warning: too many arguments for format 
>> [-Wformat-extra-args]

vim +412 drivers/gpio/gpio-dwapb.c

   396  port->idx = pp->idx;
   397  
   398  #ifdef CONFIG_PM_SLEEP
   399  port->ctx = devm_kzalloc(gpio->dev, sizeof(*port->ctx), 
GFP_KERNEL);
   400  if (!port->ctx)
   401  return -ENOMEM;
   402  #endif
   403  
   404  dat = gpio->regs + GPIO_EXT_PORTA + (pp->idx * 
GPIO_EXT_PORT_SIZE);
   405  set = gpio->regs + GPIO_SWPORTA_DR + (pp->idx * 
GPIO_SWPORT_DR_SIZE);
   406  dirout = gpio->regs + GPIO_SWPORTA_DDR +
   407  (pp->idx * GPIO_SWPORT_DDR_SIZE);
   408  
   409  err = bgpio_init(>gc, gpio->dev, 4, dat, set, NULL, 
dirout,
   410   NULL, false);
   411  if (err) {
 > 412  dev_err(gpio->dev, "failed to init gpio chip for 
 > port%\n",
   413  port->idx);
   414  return err;
   415  }
   416  
   417  #ifdef CONFIG_OF_GPIO
   418  port->gc.of_node = pp->node;
   419  #endif
   420  port->gc.ngpio = pp->ngpio;

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


.config.gz
Description: Binary data

Re: [PATCH v8 1/3] gpio: dwapb: remove name from dwapb_port_property

[kbuild test robot]

Hi,

[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.6-rc4 next-20160419]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Jiang-Qiu/gpio-dwapb-add-gpio-signaled-acpi-event-support-for-power-button/20160420-114023
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
for-next
config: x86_64-randconfig-x010-201616 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpio/gpio-dwapb.c: In function 'dwapb_gpio_add_port':
>> drivers/gpio/gpio-dwapb.c:412:22: warning: unknown conversion type character 
>> 0xa in format [-Wformat=]
  dev_err(gpio->dev, "failed to init gpio chip for port%\n",
 ^
>> drivers/gpio/gpio-dwapb.c:412:22: warning: too many arguments for format 
>> [-Wformat-extra-args]

vim +412 drivers/gpio/gpio-dwapb.c

   396  port->idx = pp->idx;
   397  
   398  #ifdef CONFIG_PM_SLEEP
   399  port->ctx = devm_kzalloc(gpio->dev, sizeof(*port->ctx), 
GFP_KERNEL);
   400  if (!port->ctx)
   401  return -ENOMEM;
   402  #endif
   403  
   404  dat = gpio->regs + GPIO_EXT_PORTA + (pp->idx * 
GPIO_EXT_PORT_SIZE);
   405  set = gpio->regs + GPIO_SWPORTA_DR + (pp->idx * 
GPIO_SWPORT_DR_SIZE);
   406  dirout = gpio->regs + GPIO_SWPORTA_DDR +
   407  (pp->idx * GPIO_SWPORT_DDR_SIZE);
   408  
   409  err = bgpio_init(>gc, gpio->dev, 4, dat, set, NULL, 
dirout,
   410   NULL, false);
   411  if (err) {
 > 412  dev_err(gpio->dev, "failed to init gpio chip for 
 > port%\n",
   413  port->idx);
   414  return err;
   415  }
   416  
   417  #ifdef CONFIG_OF_GPIO
   418  port->gc.of_node = pp->node;
   419  #endif
   420  port->gc.ngpio = pp->ngpio;

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


.config.gz
Description: Binary data

Re: [PATCH V2] powerpc: Implement {cmp}xchg for u8 and u16

[Pan Xinhui]

Hello, boqun

On 2016年04月19日 17:18, Boqun Feng wrote:
> Hi Xinhui,
> 
> On Tue, Apr 19, 2016 at 02:29:34PM +0800, Pan Xinhui wrote:
>> From: Pan Xinhui 
>>
>> Implement xchg{u8,u16}{local,relaxed}, and
>> cmpxchg{u8,u16}{,local,acquire,relaxed}.
>>
>> It works on all ppc.
>>
> 
> Nice work!
> 
thank you.

> AFAICT, your work doesn't depend on anything that ppc-specific, right?
> So maybe we can use it as a general approach for a fallback
> implementation on the archs without u8/u16 atomics. ;-)
> 
>> Suggested-by: Peter Zijlstra (Intel) 
>> Signed-off-by: Pan Xinhui 
>> ---
>> change from V1:
>>  rework totally.
>> ---
>>  arch/powerpc/include/asm/cmpxchg.h | 83 
>> ++
>>  1 file changed, 83 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/cmpxchg.h 
>> b/arch/powerpc/include/asm/cmpxchg.h
>> index 44efe73..79a1f45 100644
>> --- a/arch/powerpc/include/asm/cmpxchg.h
>> +++ b/arch/powerpc/include/asm/cmpxchg.h
>> @@ -7,6 +7,37 @@
>>  #include 
>>  #include 
>>  
>> +#ifdef __BIG_ENDIAN
>> +#define BITOFF_CAL(size, off)   ((sizeof(u32) - size - off) * 
>> BITS_PER_BYTE)
>> +#else
>> +#define BITOFF_CAL(size, off)   (off * BITS_PER_BYTE)
>> +#endif
>> +
>> +static __always_inline unsigned long
>> +__cmpxchg_u32_local(volatile unsigned int *p, unsigned long old,
>> +unsigned long new);
>> +
>> +#define __XCHG_GEN(cmp, type, sfx, u32sfx, skip, v) \
>> +static __always_inline u32  \
>> +__##cmp##xchg_##type##sfx(v void *ptr, u32 old, u32 new)\
>> +{   \
>> +int size = sizeof (type);   \
>> +int off = (unsigned long)ptr % sizeof(u32); \
>> +volatile u32 *p = ptr - off;\
>> +int bitoff = BITOFF_CAL(size, off); \
>> +u32 bitmask = ((0x1 << size * BITS_PER_BYTE) - 1) << bitoff;\
>> +u32 oldv, newv; \
>> +u32 ret;\
>> +do {\
>> +oldv = READ_ONCE(*p);   \
>> +ret = (oldv & bitmask) >> bitoff;   \
>> +if (skip && ret != old) \
>> +break;  \
>> +newv = (oldv & ~bitmask) | (new << bitoff); \
>> +} while (__cmpxchg_u32##u32sfx((v void*)p, oldv, newv) != oldv);\
> 
> Forgive me if this is too paranoid, but I think we can save the
> READ_ONCE() in the loop if we change the code into the following,
> because cmpxchg will return the "new" value, if the cmp part fails.
> 
>   newv = READ_ONCE(*p);
> 
>   do {
>   oldv = newv;
>   ret = (oldv & bitmask) >> bitoff;
>   if (skip && ret != old)
>   break;
>   newv = (oldv & ~bitmask) | (new << bitoff);
>   newv = __cmpxchg_u32##u32sfx((void *)p, oldv, newv);
>   } while(newv != oldv);
> 
>> +return ret; \
>> +}
a little optimization. Patch V3 will include your code, thanks.

>> +
>>  /*
>>   * Atomic exchange
>>   *
>> @@ -14,6 +45,19 @@
>>   * the previous value stored there.
>>   */
>>  
>> +#define XCHG_GEN(type, sfx, v)  
>> \
>> +__XCHG_GEN(_, type, sfx, _local, 0, v)  \
>  ^^^
> 
> This should be sfx, right? Otherwise, all the newly added xchg will
> call __cmpxchg_u32_local, this will result in wrong ordering guarantees.
> 
I mean that. But I will think of the ordering issue for a while. :)

>> +static __always_inline u32 __xchg_##type##sfx(v void *p, u32 n) \
>> +{   \
>> +return ___xchg_##type##sfx(p, 0, n);\
>> +}
>> +
>> +XCHG_GEN(u8, _local, volatile);
> 
> I don't think we need the "volatile" modifier here, because READ_ONCE()
> and __cmpxchg_u32_* all have "volatile" semantics IIUC, so maybe we can
> save a paramter for the __XCHG_GEN macro.
> 
such cleanup work can be done in separated patch. Here I just make the compiler 
happy.

thanks
xinhui
> Regards,
> Boqun
> 
>> +XCHG_GEN(u8, _relaxed, );
>> +XCHG_GEN(u16, _local, volatile);
>> +XCHG_GEN(u16, _relaxed, );
>> +#undef XCHG_GEN
>> +
>>  static __always_inline unsigned long
>>  __xchg_u32_local(volatile void *p, unsigned long val)
>>  {
>> @@ -88,6 +132,10 @@ static __always_inline unsigned long
>>  __xchg_local(volatile void *ptr, unsigned long x, 

Re: [PATCH V2] powerpc: Implement {cmp}xchg for u8 and u16

[Pan Xinhui]

Hello, boqun

On 2016年04月19日 17:18, Boqun Feng wrote:
> Hi Xinhui,
> 
> On Tue, Apr 19, 2016 at 02:29:34PM +0800, Pan Xinhui wrote:
>> From: Pan Xinhui 
>>
>> Implement xchg{u8,u16}{local,relaxed}, and
>> cmpxchg{u8,u16}{,local,acquire,relaxed}.
>>
>> It works on all ppc.
>>
> 
> Nice work!
> 
thank you.

> AFAICT, your work doesn't depend on anything that ppc-specific, right?
> So maybe we can use it as a general approach for a fallback
> implementation on the archs without u8/u16 atomics. ;-)
> 
>> Suggested-by: Peter Zijlstra (Intel) 
>> Signed-off-by: Pan Xinhui 
>> ---
>> change from V1:
>>  rework totally.
>> ---
>>  arch/powerpc/include/asm/cmpxchg.h | 83 
>> ++
>>  1 file changed, 83 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/cmpxchg.h 
>> b/arch/powerpc/include/asm/cmpxchg.h
>> index 44efe73..79a1f45 100644
>> --- a/arch/powerpc/include/asm/cmpxchg.h
>> +++ b/arch/powerpc/include/asm/cmpxchg.h
>> @@ -7,6 +7,37 @@
>>  #include 
>>  #include 
>>  
>> +#ifdef __BIG_ENDIAN
>> +#define BITOFF_CAL(size, off)   ((sizeof(u32) - size - off) * 
>> BITS_PER_BYTE)
>> +#else
>> +#define BITOFF_CAL(size, off)   (off * BITS_PER_BYTE)
>> +#endif
>> +
>> +static __always_inline unsigned long
>> +__cmpxchg_u32_local(volatile unsigned int *p, unsigned long old,
>> +unsigned long new);
>> +
>> +#define __XCHG_GEN(cmp, type, sfx, u32sfx, skip, v) \
>> +static __always_inline u32  \
>> +__##cmp##xchg_##type##sfx(v void *ptr, u32 old, u32 new)\
>> +{   \
>> +int size = sizeof (type);   \
>> +int off = (unsigned long)ptr % sizeof(u32); \
>> +volatile u32 *p = ptr - off;\
>> +int bitoff = BITOFF_CAL(size, off); \
>> +u32 bitmask = ((0x1 << size * BITS_PER_BYTE) - 1) << bitoff;\
>> +u32 oldv, newv; \
>> +u32 ret;\
>> +do {\
>> +oldv = READ_ONCE(*p);   \
>> +ret = (oldv & bitmask) >> bitoff;   \
>> +if (skip && ret != old) \
>> +break;  \
>> +newv = (oldv & ~bitmask) | (new << bitoff); \
>> +} while (__cmpxchg_u32##u32sfx((v void*)p, oldv, newv) != oldv);\
> 
> Forgive me if this is too paranoid, but I think we can save the
> READ_ONCE() in the loop if we change the code into the following,
> because cmpxchg will return the "new" value, if the cmp part fails.
> 
>   newv = READ_ONCE(*p);
> 
>   do {
>   oldv = newv;
>   ret = (oldv & bitmask) >> bitoff;
>   if (skip && ret != old)
>   break;
>   newv = (oldv & ~bitmask) | (new << bitoff);
>   newv = __cmpxchg_u32##u32sfx((void *)p, oldv, newv);
>   } while(newv != oldv);
> 
>> +return ret; \
>> +}
a little optimization. Patch V3 will include your code, thanks.

>> +
>>  /*
>>   * Atomic exchange
>>   *
>> @@ -14,6 +45,19 @@
>>   * the previous value stored there.
>>   */
>>  
>> +#define XCHG_GEN(type, sfx, v)  
>> \
>> +__XCHG_GEN(_, type, sfx, _local, 0, v)  \
>  ^^^
> 
> This should be sfx, right? Otherwise, all the newly added xchg will
> call __cmpxchg_u32_local, this will result in wrong ordering guarantees.
> 
I mean that. But I will think of the ordering issue for a while. :)

>> +static __always_inline u32 __xchg_##type##sfx(v void *p, u32 n) \
>> +{   \
>> +return ___xchg_##type##sfx(p, 0, n);\
>> +}
>> +
>> +XCHG_GEN(u8, _local, volatile);
> 
> I don't think we need the "volatile" modifier here, because READ_ONCE()
> and __cmpxchg_u32_* all have "volatile" semantics IIUC, so maybe we can
> save a paramter for the __XCHG_GEN macro.
> 
such cleanup work can be done in separated patch. Here I just make the compiler 
happy.

thanks
xinhui
> Regards,
> Boqun
> 
>> +XCHG_GEN(u8, _relaxed, );
>> +XCHG_GEN(u16, _local, volatile);
>> +XCHG_GEN(u16, _relaxed, );
>> +#undef XCHG_GEN
>> +
>>  static __always_inline unsigned long
>>  __xchg_u32_local(volatile void *p, unsigned long val)
>>  {
>> @@ -88,6 +132,10 @@ static __always_inline unsigned long
>>  __xchg_local(volatile void *ptr, unsigned long x, unsigned int size)
>>  {
>>  switch (size) {
>> +case 1:
>> +

Re:next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

[陈华才]

Hi,

Could you please remove the line "#define cpu_hwrena_impl_bits0xc000" 
in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h and try 
again?Thanks.

Huacai
 
-- Original --
From:  "Guenter Roeck";
Date:  Wed, Apr 20, 2016 10:54 AM
To:  "Huacai Chen";
Cc:  "Ralf Baechle"; 
"linux-mips"; 
"linux-next"; 
"linux-kernel";
Subject:  next: fuloong2e qemu boot failure due to 'MIPS: Loongson: 
AddLoongson-3A R2 basic support'
 
Hi,

qemu fails to boot in -next for machine fulong2e with configuration
fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
Loongson-3A R2 basic support'. qemu hangs in boot, after displaying 
"Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".

Bisect log is attached.

Guenter

---
# bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific files 
for 20160418
# good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
git bisect start 'HEAD' 'v4.6-rc3'
# bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking branch 
'ipvs-next/master'
git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
# bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking branch 
'btrfs-kdave/for-next'
git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
# good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking branch 
'omap/for-next'
git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
# good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking branch 
'microblaze/next'
git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
# bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3: Introduce 
CONFIG_LOONGSON3_ENHANCEMENT
git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
# good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be used 
on non-R2 or R6 cores
git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
# good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add Loongson1 
architecture entry
git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
# good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to use 
strict posix types
git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
# good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw 
watchpoints on MIPS R6
git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
# good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3: Adjust irq 
dispatch to speedup processing
git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
# bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set cache 
flush handlers to cache_noop
git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
# bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add 
Loongson-3A R2 basic support
git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
# first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: 
Add Loongson-3A R2 basic support

Re: [PATCH 14/16] vfs: Implement mount_super_once

[Eric W. Biederman]

"H. Peter Anvin"  writes:

> On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin"  wrote:
>>
>>Perhaps a (privileged) option to exempt from the global limit, then. 
>>Something we can implement if asked for.
>>
>>However, I wouldn't be 100% that the reserved pool isn't used.  Someone
>>added it presumably for a reason.  An administrator could say it and
>>we'd have no idea.
>
> ... and if I personally was running a container-hosting system, I
> would *absolutely* set it to make sure the administrator could not get
> locked out.

That is likely easier done by setting:
echo RIDICULOUSLY_LARGE_NUMBER > /proc/sys/kernel/pty/max

All I am certain about at this point is that no one cares on a day to
day basis or in any kind of ordinary scenario so this is something that
we can get away with changing.

But yes I would not be surprised if we have to come back and implement
something like your suggested extra mount option for devpts, so some
specified instances can dip into the reserved pool.

Eric

Re:next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

[陈华才]

Hi,

Could you please remove the line "#define cpu_hwrena_impl_bits0xc000" 
in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h and try 
again?Thanks.

Huacai
 
-- Original --
From:  "Guenter Roeck";
Date:  Wed, Apr 20, 2016 10:54 AM
To:  "Huacai Chen";
Cc:  "Ralf Baechle"; 
"linux-mips"; 
"linux-next"; 
"linux-kernel";
Subject:  next: fuloong2e qemu boot failure due to 'MIPS: Loongson: 
AddLoongson-3A R2 basic support'
 
Hi,

qemu fails to boot in -next for machine fulong2e with configuration
fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
Loongson-3A R2 basic support'. qemu hangs in boot, after displaying 
"Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".

Bisect log is attached.

Guenter

---
# bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific files 
for 20160418
# good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
git bisect start 'HEAD' 'v4.6-rc3'
# bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking branch 
'ipvs-next/master'
git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
# bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking branch 
'btrfs-kdave/for-next'
git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
# good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking branch 
'omap/for-next'
git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
# good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking branch 
'microblaze/next'
git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
# bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3: Introduce 
CONFIG_LOONGSON3_ENHANCEMENT
git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
# good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be used 
on non-R2 or R6 cores
git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
# good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add Loongson1 
architecture entry
git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
# good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to use 
strict posix types
git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
# good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw 
watchpoints on MIPS R6
git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
# good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3: Adjust irq 
dispatch to speedup processing
git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
# bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set cache 
flush handlers to cache_noop
git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
# bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add 
Loongson-3A R2 basic support
git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
# first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: 
Add Loongson-3A R2 basic support

Re: [PATCH 14/16] vfs: Implement mount_super_once

[Eric W. Biederman]

"H. Peter Anvin"  writes:

> On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin"  wrote:
>>
>>Perhaps a (privileged) option to exempt from the global limit, then. 
>>Something we can implement if asked for.
>>
>>However, I wouldn't be 100% that the reserved pool isn't used.  Someone
>>added it presumably for a reason.  An administrator could say it and
>>we'd have no idea.
>
> ... and if I personally was running a container-hosting system, I
> would *absolutely* set it to make sure the administrator could not get
> locked out.

That is likely easier done by setting:
echo RIDICULOUSLY_LARGE_NUMBER > /proc/sys/kernel/pty/max

All I am certain about at this point is that no one cares on a day to
day basis or in any kind of ordinary scenario so this is something that
we can get away with changing.

But yes I would not be surprised if we have to come back and implement
something like your suggested extra mount option for devpts, so some
specified instances can dip into the reserved pool.

Eric

[PATCH v8 2/3] gpio: dwapb: convert device node to fwnode

[Jiang Qiu]

This patch converts device node to fwnode for dwapb driver, so
as to provide a unified fwnode for DT and ACPI bindings.

Tested-by: Alan Tull 
Acked-by: Andy Shevchenko 
Signed-off-by: Jiang Qiu 
---
 drivers/gpio/gpio-dwapb.c| 37 
 drivers/mfd/intel_quark_i2c_gpio.c   |  2 +-
 include/linux/platform_data/gpio-dwapb.h |  2 +-
 3 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index ea04172..7258cc5 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -290,14 +291,14 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
 struct dwapb_port_property *pp)
 {
struct gpio_chip *gc = >gc;
-   struct device_node *node = pp->node;
+   struct fwnode_handle  *fwnode = pp->fwnode;
struct irq_chip_generic *irq_gc = NULL;
unsigned int hwirq, ngpio = gc->ngpio;
struct irq_chip_type *ct;
int err, i;
 
-   gpio->domain = irq_domain_add_linear(node, ngpio,
-_generic_chip_ops, gpio);
+   gpio->domain = irq_domain_create_linear(fwnode, ngpio,
+_generic_chip_ops, gpio);
if (!gpio->domain)
return;
 
@@ -415,7 +416,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
}
 
 #ifdef CONFIG_OF_GPIO
-   port->gc.of_node = pp->node;
+   port->gc.of_node = is_of_node(pp->fwnode) ?
+   to_of_node(pp->fwnode) : NULL;
 #endif
port->gc.ngpio = pp->ngpio;
port->gc.base = pp->gpio_base;
@@ -447,19 +449,15 @@ static void dwapb_gpio_unregister(struct dwapb_gpio *gpio)
 }
 
 static struct dwapb_platform_data *
-dwapb_gpio_get_pdata_of(struct device *dev)
+dwapb_gpio_get_pdata(struct device *dev)
 {
-   struct device_node *node, *port_np;
+   struct fwnode_handle *fwnode;
struct dwapb_platform_data *pdata;
struct dwapb_port_property *pp;
int nports;
int i;
 
-   node = dev->of_node;
-   if (!IS_ENABLED(CONFIG_OF_GPIO) || !node)
-   return ERR_PTR(-ENODEV);
-
-   nports = of_get_child_count(node);
+   nports = device_get_child_node_count(dev);
if (nports == 0)
return ERR_PTR(-ENODEV);
 
@@ -474,18 +472,18 @@ dwapb_gpio_get_pdata_of(struct device *dev)
pdata->nports = nports;
 
i = 0;
-   for_each_child_of_node(node, port_np) {
+   device_for_each_child_node(dev, fwnode)  {
pp = >properties[i++];
-   pp->node = port_np;
+   pp->fwnode = fwnode;
 
-   if (of_property_read_u32(port_np, "reg", >idx) ||
+   if (fwnode_property_read_u32(fwnode, "reg", >idx) ||
pp->idx >= DWAPB_MAX_PORTS) {
dev_err(dev,
"missing/invalid port index for port%d\n", i);
return ERR_PTR(-EINVAL);
}
 
-   if (of_property_read_u32(port_np, "snps,nr-gpios",
+   if (fwnode_property_read_u32(fwnode, "snps,nr-gpios",
 >ngpio)) {
dev_info(dev,
 "failed to get number of gpios for port%d\n",
@@ -497,9 +495,10 @@ dwapb_gpio_get_pdata_of(struct device *dev)
 * Only port A can provide interrupts in all configurations of
 * the IP.
 */
-   if (pp->idx == 0 &&
-   of_property_read_bool(port_np, "interrupt-controller")) {
-   pp->irq = irq_of_parse_and_map(port_np, 0);
+   if (dev->of_node && pp->idx == 0 &&
+   fwnode_property_read_bool(fwnode,
+ "interrupt-controller")) {
+   pp->irq = irq_of_parse_and_map(to_of_node(fwnode), 0);
if (!pp->irq)
dev_warn(dev, "no irq for port%d\n", pp->idx);
}
@@ -521,7 +520,7 @@ static int dwapb_gpio_probe(struct platform_device *pdev)
struct dwapb_platform_data *pdata = dev_get_platdata(dev);
 
if (!pdata) {
-   pdata = dwapb_gpio_get_pdata_of(dev);
+   pdata = dwapb_gpio_get_pdata(dev);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
}
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c 
b/drivers/mfd/intel_quark_i2c_gpio.c
index a4ef99b..a24b35f 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -219,7 +219,7 @@ static int intel_quark_gpio_setup(struct pci_dev *pdev, 
struct mfd_cell *cell)
   

[PATCH v8 2/3] gpio: dwapb: convert device node to fwnode

[Jiang Qiu]

This patch converts device node to fwnode for dwapb driver, so
as to provide a unified fwnode for DT and ACPI bindings.

Tested-by: Alan Tull 
Acked-by: Andy Shevchenko 
Signed-off-by: Jiang Qiu 
---
 drivers/gpio/gpio-dwapb.c| 37 
 drivers/mfd/intel_quark_i2c_gpio.c   |  2 +-
 include/linux/platform_data/gpio-dwapb.h |  2 +-
 3 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index ea04172..7258cc5 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -290,14 +291,14 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
 struct dwapb_port_property *pp)
 {
struct gpio_chip *gc = >gc;
-   struct device_node *node = pp->node;
+   struct fwnode_handle  *fwnode = pp->fwnode;
struct irq_chip_generic *irq_gc = NULL;
unsigned int hwirq, ngpio = gc->ngpio;
struct irq_chip_type *ct;
int err, i;
 
-   gpio->domain = irq_domain_add_linear(node, ngpio,
-_generic_chip_ops, gpio);
+   gpio->domain = irq_domain_create_linear(fwnode, ngpio,
+_generic_chip_ops, gpio);
if (!gpio->domain)
return;
 
@@ -415,7 +416,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
}
 
 #ifdef CONFIG_OF_GPIO
-   port->gc.of_node = pp->node;
+   port->gc.of_node = is_of_node(pp->fwnode) ?
+   to_of_node(pp->fwnode) : NULL;
 #endif
port->gc.ngpio = pp->ngpio;
port->gc.base = pp->gpio_base;
@@ -447,19 +449,15 @@ static void dwapb_gpio_unregister(struct dwapb_gpio *gpio)
 }
 
 static struct dwapb_platform_data *
-dwapb_gpio_get_pdata_of(struct device *dev)
+dwapb_gpio_get_pdata(struct device *dev)
 {
-   struct device_node *node, *port_np;
+   struct fwnode_handle *fwnode;
struct dwapb_platform_data *pdata;
struct dwapb_port_property *pp;
int nports;
int i;
 
-   node = dev->of_node;
-   if (!IS_ENABLED(CONFIG_OF_GPIO) || !node)
-   return ERR_PTR(-ENODEV);
-
-   nports = of_get_child_count(node);
+   nports = device_get_child_node_count(dev);
if (nports == 0)
return ERR_PTR(-ENODEV);
 
@@ -474,18 +472,18 @@ dwapb_gpio_get_pdata_of(struct device *dev)
pdata->nports = nports;
 
i = 0;
-   for_each_child_of_node(node, port_np) {
+   device_for_each_child_node(dev, fwnode)  {
pp = >properties[i++];
-   pp->node = port_np;
+   pp->fwnode = fwnode;
 
-   if (of_property_read_u32(port_np, "reg", >idx) ||
+   if (fwnode_property_read_u32(fwnode, "reg", >idx) ||
pp->idx >= DWAPB_MAX_PORTS) {
dev_err(dev,
"missing/invalid port index for port%d\n", i);
return ERR_PTR(-EINVAL);
}
 
-   if (of_property_read_u32(port_np, "snps,nr-gpios",
+   if (fwnode_property_read_u32(fwnode, "snps,nr-gpios",
 >ngpio)) {
dev_info(dev,
 "failed to get number of gpios for port%d\n",
@@ -497,9 +495,10 @@ dwapb_gpio_get_pdata_of(struct device *dev)
 * Only port A can provide interrupts in all configurations of
 * the IP.
 */
-   if (pp->idx == 0 &&
-   of_property_read_bool(port_np, "interrupt-controller")) {
-   pp->irq = irq_of_parse_and_map(port_np, 0);
+   if (dev->of_node && pp->idx == 0 &&
+   fwnode_property_read_bool(fwnode,
+ "interrupt-controller")) {
+   pp->irq = irq_of_parse_and_map(to_of_node(fwnode), 0);
if (!pp->irq)
dev_warn(dev, "no irq for port%d\n", pp->idx);
}
@@ -521,7 +520,7 @@ static int dwapb_gpio_probe(struct platform_device *pdev)
struct dwapb_platform_data *pdata = dev_get_platdata(dev);
 
if (!pdata) {
-   pdata = dwapb_gpio_get_pdata_of(dev);
+   pdata = dwapb_gpio_get_pdata(dev);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
}
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c 
b/drivers/mfd/intel_quark_i2c_gpio.c
index a4ef99b..a24b35f 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -219,7 +219,7 @@ static int intel_quark_gpio_setup(struct pci_dev *pdev, 
struct mfd_cell *cell)
return -ENOMEM;
 
/* Set the properties for portA */
-   

[PATCH v8 3/3] gpio: dwapb: add gpio-signaled acpi event support

[Jiang Qiu]

This patch adds gpio-signaled acpi event support. It is used for
power button on hisilicon D02 board, an arm64 platform.

The corresponding DSDT file is defined as follows:
Device(GPI0) {
Name(_HID, "HISI0181")
Name(_ADR, 0)
Name(_UID, 0)

Name (_CRS, ResourceTemplate ()  {
Memory32Fixed (ReadWrite, 0x802e, 0x1)
Interrupt (ResourceConsumer, Level, ActiveHigh,
Exclusive,,,)  {344}
})

Device(PRTa) {
Name (_DSD, Package () {
Package () {
Package () {"reg",0},
Package () {"snps,nr-gpios",32},
}
})
}

Name (_AEI, ResourceTemplate () {
GpioInt(Edge, ActiveLow, ExclusiveAndWake,
PullUp, , " \\_SB.GPI0") {8}
})

Method (_E08, 0x0, NotSerialized) {
Notify (\_SB.PWRB, 0x80)
}
}

Acked-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Jiang Qiu 
---
 drivers/gpio/gpio-dwapb.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 7258cc5..b2b83d6 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -7,6 +7,7 @@
  *
  * All enquiries to supp...@picochip.com
  */
+#include 
 #include 
 /* FIXME: for gpio_get_value(), replace this with direct register read */
 #include 
@@ -27,6 +28,8 @@
 #include 
 #include 
 
+#include "gpiolib.h"
+
 #define GPIO_SWPORTA_DR0x00
 #define GPIO_SWPORTA_DDR   0x04
 #define GPIO_SWPORTB_DR0x0c
@@ -436,6 +439,10 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
else
port->is_registered = true;
 
+   /* Add GPIO-signaled ACPI event support */
+   if (pp->irq)
+   acpi_gpiochip_request_interrupts(>gc);
+
return err;
 }
 
@@ -503,6 +510,9 @@ dwapb_gpio_get_pdata(struct device *dev)
dev_warn(dev, "no irq for port%d\n", pp->idx);
}
 
+   if (has_acpi_companion(dev) && pp->idx == 0)
+   pp->irq = platform_get_irq(to_platform_device(dev), 0);
+
pp->irq_shared  = false;
pp->gpio_base   = -1;
}
@@ -577,6 +587,12 @@ static const struct of_device_id dwapb_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, dwapb_of_match);
 
+static const struct acpi_device_id dwapb_acpi_match[] = {
+   {"HISI0181", 0},
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, dwapb_acpi_match);
+
 #ifdef CONFIG_PM_SLEEP
 static int dwapb_gpio_suspend(struct device *dev)
 {
@@ -671,6 +687,7 @@ static struct platform_driver dwapb_gpio_driver = {
.name   = "gpio-dwapb",
.pm = _gpio_pm_ops,
.of_match_table = of_match_ptr(dwapb_of_match),
+   .acpi_match_table = ACPI_PTR(dwapb_acpi_match),
},
.probe  = dwapb_gpio_probe,
.remove = dwapb_gpio_remove,
-- 
1.9.1

[PATCH v8 3/3] gpio: dwapb: add gpio-signaled acpi event support

[Jiang Qiu]

This patch adds gpio-signaled acpi event support. It is used for
power button on hisilicon D02 board, an arm64 platform.

The corresponding DSDT file is defined as follows:
Device(GPI0) {
Name(_HID, "HISI0181")
Name(_ADR, 0)
Name(_UID, 0)

Name (_CRS, ResourceTemplate ()  {
Memory32Fixed (ReadWrite, 0x802e, 0x1)
Interrupt (ResourceConsumer, Level, ActiveHigh,
Exclusive,,,)  {344}
})

Device(PRTa) {
Name (_DSD, Package () {
Package () {
Package () {"reg",0},
Package () {"snps,nr-gpios",32},
}
})
}

Name (_AEI, ResourceTemplate () {
GpioInt(Edge, ActiveLow, ExclusiveAndWake,
PullUp, , " \\_SB.GPI0") {8}
})

Method (_E08, 0x0, NotSerialized) {
Notify (\_SB.PWRB, 0x80)
}
}

Acked-by: Mika Westerberg 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Jiang Qiu 
---
 drivers/gpio/gpio-dwapb.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 7258cc5..b2b83d6 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -7,6 +7,7 @@
  *
  * All enquiries to supp...@picochip.com
  */
+#include 
 #include 
 /* FIXME: for gpio_get_value(), replace this with direct register read */
 #include 
@@ -27,6 +28,8 @@
 #include 
 #include 
 
+#include "gpiolib.h"
+
 #define GPIO_SWPORTA_DR0x00
 #define GPIO_SWPORTA_DDR   0x04
 #define GPIO_SWPORTB_DR0x0c
@@ -436,6 +439,10 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
else
port->is_registered = true;
 
+   /* Add GPIO-signaled ACPI event support */
+   if (pp->irq)
+   acpi_gpiochip_request_interrupts(>gc);
+
return err;
 }
 
@@ -503,6 +510,9 @@ dwapb_gpio_get_pdata(struct device *dev)
dev_warn(dev, "no irq for port%d\n", pp->idx);
}
 
+   if (has_acpi_companion(dev) && pp->idx == 0)
+   pp->irq = platform_get_irq(to_platform_device(dev), 0);
+
pp->irq_shared  = false;
pp->gpio_base   = -1;
}
@@ -577,6 +587,12 @@ static const struct of_device_id dwapb_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, dwapb_of_match);
 
+static const struct acpi_device_id dwapb_acpi_match[] = {
+   {"HISI0181", 0},
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, dwapb_acpi_match);
+
 #ifdef CONFIG_PM_SLEEP
 static int dwapb_gpio_suspend(struct device *dev)
 {
@@ -671,6 +687,7 @@ static struct platform_driver dwapb_gpio_driver = {
.name   = "gpio-dwapb",
.pm = _gpio_pm_ops,
.of_match_table = of_match_ptr(dwapb_of_match),
+   .acpi_match_table = ACPI_PTR(dwapb_acpi_match),
},
.probe  = dwapb_gpio_probe,
.remove = dwapb_gpio_remove,
-- 
1.9.1

linux-next: manual merge of the usb-gadget tree with the usb-gadget-fixes tree

[Stephen Rothwell]

Hi Felipe,

Today's linux-next merge of the usb-gadget tree got a conflict in:

  drivers/usb/dwc3/debugfs.c

between commit:

  e6bdf8195b4a ("usb: dwc3: fix memory leak of dwc->regset")

from the usb-gadget-fixes tree and commit:

  4e9f311833a9 ("usb: dwc3: make dwc3_debugfs_init return value be void")

from the usb-gadget 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 drivers/usb/dwc3/debugfs.c
index cebf9e38b60a,6c14f653dc9b..
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@@ -661,29 -956,16 +956,14 @@@ void dwc3_debugfs_init(struct dwc3 *dwc
IS_ENABLED(CONFIG_USB_DWC3_GADGET)) {
file = debugfs_create_file("testmode", S_IRUGO | S_IWUSR, root,
dwc, _testmode_fops);
-   if (!file) {
-   ret = -ENOMEM;
-   goto err2;
-   }
- 
-   file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR, 
root,
-   dwc, _link_state_fops);
-   if (!file) {
-   ret = -ENOMEM;
-   goto err2;
-   }
-   }
 -  if (!file)
 -  dev_dbg(dwc->dev, "Can't create debugfs testmode\n");
  
-   return 0;
+   file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR,
+   root, dwc, _link_state_fops);
+   if (!file)
+   dev_dbg(dwc->dev, "Can't create debugfs link_state\n");
  
- err2:
-   kfree(dwc->regset);
- 
- err1:
-   debugfs_remove_recursive(root);
- 
- err0:
-   return ret;
+   dwc3_debugfs_create_endpoint_dirs(dwc, root);
+   }
  }
  
  void dwc3_debugfs_exit(struct dwc3 *dwc)

linux-next: manual merge of the usb-gadget tree with the usb-gadget-fixes tree

[Stephen Rothwell]

Hi Felipe,

Today's linux-next merge of the usb-gadget tree got a conflict in:

  drivers/usb/dwc3/debugfs.c

between commit:

  e6bdf8195b4a ("usb: dwc3: fix memory leak of dwc->regset")

from the usb-gadget-fixes tree and commit:

  4e9f311833a9 ("usb: dwc3: make dwc3_debugfs_init return value be void")

from the usb-gadget 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 drivers/usb/dwc3/debugfs.c
index cebf9e38b60a,6c14f653dc9b..
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@@ -661,29 -956,16 +956,14 @@@ void dwc3_debugfs_init(struct dwc3 *dwc
IS_ENABLED(CONFIG_USB_DWC3_GADGET)) {
file = debugfs_create_file("testmode", S_IRUGO | S_IWUSR, root,
dwc, _testmode_fops);
-   if (!file) {
-   ret = -ENOMEM;
-   goto err2;
-   }
- 
-   file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR, 
root,
-   dwc, _link_state_fops);
-   if (!file) {
-   ret = -ENOMEM;
-   goto err2;
-   }
-   }
 -  if (!file)
 -  dev_dbg(dwc->dev, "Can't create debugfs testmode\n");
  
-   return 0;
+   file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR,
+   root, dwc, _link_state_fops);
+   if (!file)
+   dev_dbg(dwc->dev, "Can't create debugfs link_state\n");
  
- err2:
-   kfree(dwc->regset);
- 
- err1:
-   debugfs_remove_recursive(root);
- 
- err0:
-   return ret;
+   dwc3_debugfs_create_endpoint_dirs(dwc, root);
+   }
  }
  
  void dwc3_debugfs_exit(struct dwc3 *dwc)

Re: [PATCH v6 01/17] arm64:ilp32: add documentation on the ILP32 ABI for ARM64

[Yury Norov]

On Wed, Nov 25, 2015 at 03:07:26AM +, Iosif Harutyunov wrote:
> Sonicwall is very interested in ILP32, is there a way we can get access to 
> the SuSe builds?
> 
> Iosif,_
> 

Hi Iosif,

I just found your email in trash mailbox. Please add my email to CC
explicitly to avoid it. If you still interested in ILP32, find
RFC6 version here: http://www.spinics.net/lists/linux-s390/msg12272.html

There are also manuals for building glibc for it. I'm not sure
someone was building whole SUSE distro against ILP32, but I think
you can build kernel with my patches, and library, and do tests you
interested. Feel free to contact me in case of troubles.

Yury.

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

Re: [PATCH v6 01/17] arm64:ilp32: add documentation on the ILP32 ABI for ARM64

[Yury Norov]

On Wed, Nov 25, 2015 at 03:07:26AM +, Iosif Harutyunov wrote:
> Sonicwall is very interested in ILP32, is there a way we can get access to 
> the SuSe builds?
> 
> Iosif,_
> 

Hi Iosif,

I just found your email in trash mailbox. Please add my email to CC
explicitly to avoid it. If you still interested in ILP32, find
RFC6 version here: http://www.spinics.net/lists/linux-s390/msg12272.html

There are also manuals for building glibc for it. I'm not sure
someone was building whole SUSE distro against ILP32, but I think
you can build kernel with my patches, and library, and do tests you
interested. Feel free to contact me in case of troubles.

Yury.

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

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Al Viro]

On Tue, Apr 19, 2016 at 10:04:20PM -0500, Eric W. Biederman wrote:
> +#ifdef CONFIG_UNIX98_PTYS
> +int path_pts(struct path *path)
> +{
> + /* Find "pts" in the same directory as the input path */
> + struct dentry *child, *parent;
> + struct qstr this;
> + int ret;
> +
> + ret = path_parent_directory(path);
> + if (ret)
> + return ret;
> +
> + parent = path->dentry;
> + if (!d_can_lookup(parent))
> + return -ENOENT;

And how, pray tell, would a parent of anything fail to be a directory?

> + this.name = "pts";
> + this.len = 3;
> + this.hash = full_name_hash(this.name, this.len);
> + if (parent->d_flags & DCACHE_OP_HASH) {
> + int err = parent->d_op->d_hash(parent, );
> + if (err < 0)
> + return err;
> + }
> + inode_lock(parent->d_inode);

What the hell for?  What does that lock on parent change for the
dcache lookup you are doing here?

> + child = d_lookup(parent, );
> + inode_unlock(parent->d_inode);
> + if (!child)
> + return -ENOENT;

Take a look at d_hash_and_lookup(), BTW...

> + path->dentry = child;
> + dput(parent);
> + follow_mount(path);
> + return 0;
> +}
> +#endif
> +
>  int user_path_at_empty(int dfd, const char __user *name, unsigned flags,
>struct path *path, int *empty)
>  {
> diff --git a/include/linux/devpts_fs.h b/include/linux/devpts_fs.h
> index e0ee0b3000b2..486f6282b0c6 100644
> --- a/include/linux/devpts_fs.h
> +++ b/include/linux/devpts_fs.h
> @@ -17,36 +17,21 @@
>  
>  #ifdef CONFIG_UNIX98_PTYS
>  
> -int devpts_new_index(struct inode *ptmx_inode);
> -void devpts_kill_index(struct inode *ptmx_inode, int idx);
> -void devpts_add_ref(struct inode *ptmx_inode);
> -void devpts_del_ref(struct inode *ptmx_inode);
> +struct pts_fs_info;
> +
> +struct pts_fs_info *devpts_acquire(struct file *filp);
> +void devpts_release(struct pts_fs_info *fsi);
> +
> +int devpts_new_index(struct pts_fs_info *fsi);
> +void devpts_kill_index(struct pts_fs_info *fsi, int idx);
>  /* mknod in devpts */
> -struct inode *devpts_pty_new(struct inode *ptmx_inode, dev_t device, int 
> index,
> +struct inode *devpts_pty_new(struct pts_fs_info *fsi, dev_t device, int 
> index,
>   void *priv);
>  /* get private structure */
>  void *devpts_get_priv(struct inode *pts_inode);
>  /* unlink */
>  void devpts_pty_kill(struct inode *inode);
>  
> -#else
> -
> -/* Dummy stubs in the no-pty case */
> -static inline int devpts_new_index(struct inode *ptmx_inode) { return 
> -EINVAL; }
> -static inline void devpts_kill_index(struct inode *ptmx_inode, int idx) { }
> -static inline void devpts_add_ref(struct inode *ptmx_inode) { }
> -static inline void devpts_del_ref(struct inode *ptmx_inode) { }
> -static inline struct inode *devpts_pty_new(struct inode *ptmx_inode,
> - dev_t device, int index, void *priv)
> -{
> - return ERR_PTR(-EINVAL);
> -}
> -static inline void *devpts_get_priv(struct inode *pts_inode)
> -{
> - return NULL;
> -}
> -static inline void devpts_pty_kill(struct inode *inode) { }
> -
>  #endif
>  
>  
> diff --git a/include/linux/namei.h b/include/linux/namei.h
> index 77d01700daf7..f29abda31e6d 100644
> --- a/include/linux/namei.h
> +++ b/include/linux/namei.h
> @@ -45,6 +45,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, 
> LAST_BIND};
>  #define LOOKUP_ROOT  0x2000
>  #define LOOKUP_EMPTY 0x4000
>  
> +extern int path_pts(struct path *path);
> +
>  extern int user_path_at_empty(int, const char __user *, unsigned, struct 
> path *, int *empty);
>  
>  static inline int user_path_at(int dfd, const char __user *name, unsigned 
> flags,
> -- 
> 2.8.1
> 

Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.

[Al Viro]

On Tue, Apr 19, 2016 at 10:04:20PM -0500, Eric W. Biederman wrote:
> +#ifdef CONFIG_UNIX98_PTYS
> +int path_pts(struct path *path)
> +{
> + /* Find "pts" in the same directory as the input path */
> + struct dentry *child, *parent;
> + struct qstr this;
> + int ret;
> +
> + ret = path_parent_directory(path);
> + if (ret)
> + return ret;
> +
> + parent = path->dentry;
> + if (!d_can_lookup(parent))
> + return -ENOENT;

And how, pray tell, would a parent of anything fail to be a directory?

> + this.name = "pts";
> + this.len = 3;
> + this.hash = full_name_hash(this.name, this.len);
> + if (parent->d_flags & DCACHE_OP_HASH) {
> + int err = parent->d_op->d_hash(parent, );
> + if (err < 0)
> + return err;
> + }
> + inode_lock(parent->d_inode);

What the hell for?  What does that lock on parent change for the
dcache lookup you are doing here?

> + child = d_lookup(parent, );
> + inode_unlock(parent->d_inode);
> + if (!child)
> + return -ENOENT;

Take a look at d_hash_and_lookup(), BTW...

> + path->dentry = child;
> + dput(parent);
> + follow_mount(path);
> + return 0;
> +}
> +#endif
> +
>  int user_path_at_empty(int dfd, const char __user *name, unsigned flags,
>struct path *path, int *empty)
>  {
> diff --git a/include/linux/devpts_fs.h b/include/linux/devpts_fs.h
> index e0ee0b3000b2..486f6282b0c6 100644
> --- a/include/linux/devpts_fs.h
> +++ b/include/linux/devpts_fs.h
> @@ -17,36 +17,21 @@
>  
>  #ifdef CONFIG_UNIX98_PTYS
>  
> -int devpts_new_index(struct inode *ptmx_inode);
> -void devpts_kill_index(struct inode *ptmx_inode, int idx);
> -void devpts_add_ref(struct inode *ptmx_inode);
> -void devpts_del_ref(struct inode *ptmx_inode);
> +struct pts_fs_info;
> +
> +struct pts_fs_info *devpts_acquire(struct file *filp);
> +void devpts_release(struct pts_fs_info *fsi);
> +
> +int devpts_new_index(struct pts_fs_info *fsi);
> +void devpts_kill_index(struct pts_fs_info *fsi, int idx);
>  /* mknod in devpts */
> -struct inode *devpts_pty_new(struct inode *ptmx_inode, dev_t device, int 
> index,
> +struct inode *devpts_pty_new(struct pts_fs_info *fsi, dev_t device, int 
> index,
>   void *priv);
>  /* get private structure */
>  void *devpts_get_priv(struct inode *pts_inode);
>  /* unlink */
>  void devpts_pty_kill(struct inode *inode);
>  
> -#else
> -
> -/* Dummy stubs in the no-pty case */
> -static inline int devpts_new_index(struct inode *ptmx_inode) { return 
> -EINVAL; }
> -static inline void devpts_kill_index(struct inode *ptmx_inode, int idx) { }
> -static inline void devpts_add_ref(struct inode *ptmx_inode) { }
> -static inline void devpts_del_ref(struct inode *ptmx_inode) { }
> -static inline struct inode *devpts_pty_new(struct inode *ptmx_inode,
> - dev_t device, int index, void *priv)
> -{
> - return ERR_PTR(-EINVAL);
> -}
> -static inline void *devpts_get_priv(struct inode *pts_inode)
> -{
> - return NULL;
> -}
> -static inline void devpts_pty_kill(struct inode *inode) { }
> -
>  #endif
>  
>  
> diff --git a/include/linux/namei.h b/include/linux/namei.h
> index 77d01700daf7..f29abda31e6d 100644
> --- a/include/linux/namei.h
> +++ b/include/linux/namei.h
> @@ -45,6 +45,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, 
> LAST_BIND};
>  #define LOOKUP_ROOT  0x2000
>  #define LOOKUP_EMPTY 0x4000
>  
> +extern int path_pts(struct path *path);
> +
>  extern int user_path_at_empty(int, const char __user *, unsigned, struct 
> path *, int *empty);
>  
>  static inline int user_path_at(int dfd, const char __user *name, unsigned 
> flags,
> -- 
> 2.8.1
> 

[PATCH v8 1/3] gpio: dwapb: remove name from dwapb_port_property

[Jiang Qiu]

This patch removed the name property from dwapb_port_property.
The name property is redundant, because we can get this info
from dwapb_gpio dev node.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Jiang Qiu 
---
 drivers/gpio/gpio-dwapb.c| 24 +++-
 drivers/mfd/intel_quark_i2c_gpio.c   |  1 -
 include/linux/platform_data/gpio-dwapb.h |  1 -
 3 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 597de1e..ea04172 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -409,8 +409,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
err = bgpio_init(>gc, gpio->dev, 4, dat, set, NULL, dirout,
 NULL, false);
if (err) {
-   dev_err(gpio->dev, "failed to init gpio chip for %s\n",
-   pp->name);
+   dev_err(gpio->dev, "failed to init gpio chip for port%\n",
+   port->idx);
return err;
}
 
@@ -429,8 +429,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
 
err = gpiochip_add_data(>gc, port);
if (err)
-   dev_err(gpio->dev, "failed to register gpiochip for %s\n",
-   pp->name);
+   dev_err(gpio->dev, "failed to register gpiochip for port%d\n",
+   port->idx);
else
port->is_registered = true;
 
@@ -480,15 +480,16 @@ dwapb_gpio_get_pdata_of(struct device *dev)
 
if (of_property_read_u32(port_np, "reg", >idx) ||
pp->idx >= DWAPB_MAX_PORTS) {
-   dev_err(dev, "missing/invalid port index for %s\n",
-   port_np->full_name);
+   dev_err(dev,
+   "missing/invalid port index for port%d\n", i);
return ERR_PTR(-EINVAL);
}
 
if (of_property_read_u32(port_np, "snps,nr-gpios",
 >ngpio)) {
-   dev_info(dev, "failed to get number of gpios for %s\n",
-port_np->full_name);
+   dev_info(dev,
+"failed to get number of gpios for port%d\n",
+i);
pp->ngpio = 32;
}
 
@@ -499,15 +500,12 @@ dwapb_gpio_get_pdata_of(struct device *dev)
if (pp->idx == 0 &&
of_property_read_bool(port_np, "interrupt-controller")) {
pp->irq = irq_of_parse_and_map(port_np, 0);
-   if (!pp->irq) {
-   dev_warn(dev, "no irq for bank %s\n",
-port_np->full_name);
-   }
+   if (!pp->irq)
+   dev_warn(dev, "no irq for port%d\n", pp->idx);
}
 
pp->irq_shared  = false;
pp->gpio_base   = -1;
-   pp->name= port_np->full_name;
}
 
return pdata;
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c 
b/drivers/mfd/intel_quark_i2c_gpio.c
index bdc5e27..a4ef99b 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -220,7 +220,6 @@ static int intel_quark_gpio_setup(struct pci_dev *pdev, 
struct mfd_cell *cell)
 
/* Set the properties for portA */
pdata->properties->node = NULL;
-   pdata->properties->name = "intel-quark-x1000-gpio-portA";
pdata->properties->idx  = 0;
pdata->properties->ngpio= INTEL_QUARK_MFD_NGPIO;
pdata->properties->gpio_base= INTEL_QUARK_MFD_GPIO_BASE;
diff --git a/include/linux/platform_data/gpio-dwapb.h 
b/include/linux/platform_data/gpio-dwapb.h
index 28702c8..955b579 100644
--- a/include/linux/platform_data/gpio-dwapb.h
+++ b/include/linux/platform_data/gpio-dwapb.h
@@ -16,7 +16,6 @@
 
 struct dwapb_port_property {
struct device_node *node;
-   const char  *name;
unsigned intidx;
unsigned intngpio;
unsigned intgpio_base;
-- 
1.9.1

[PATCH v8 0/3] gpio: dwapb: add gpio-signaled acpi event support for power button

[Jiang Qiu]

This patchset adds gpio-signaled acpi events support for power button on 
hisilicon
D02 board.

The three patches respectively:
- remove name from dwapb_port_property
- convert device node to fwnode
- add gpio-signaled acpi event support

   This patchset is based on
   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
   branch "devel"

Changes v7 -> v8:
   - fixed few minors

Changes v6 -> v7:
   - add patch1 by Alan's suggestion

Changes v5 -> v6:
   - merge patch 2~3 to one patch
   - small fixed from Alan's suggestion
   - fixed subject title reference commit history

Changes v4 -> v5:
   - split into three patchs
   - add Andy's ACKs
   
Changes v3 -> v4:
   - re-organize this two patchs by Andy's suggestion

Changes v2 -> v3:
   - fixed the build error reported by Kbuild test robot

Changes v1 -> v2: 
   - rebase to branch "devel" of Linus Walleij's repository
   - split in two patch as suggested by Andy S
   - add Mika's ACKs

Jiang Qiu (3):
  gpio: dwapb: remove name from dwapb_port_property
  gpio: dwapb: convert device node to fwnode
  gpio: dwapb: add gpio-signaled acpi event support

 drivers/gpio/gpio-dwapb.c| 78 +++-
 drivers/mfd/intel_quark_i2c_gpio.c   |  3 +-
 include/linux/platform_data/gpio-dwapb.h |  3 +-
 3 files changed, 48 insertions(+), 36 deletions(-)

-- 
1.9.1

[PATCH v8 1/3] gpio: dwapb: remove name from dwapb_port_property

[Jiang Qiu]

This patch removed the name property from dwapb_port_property.
The name property is redundant, because we can get this info
from dwapb_gpio dev node.

Reviewed-by: Andy Shevchenko 
Signed-off-by: Jiang Qiu 
---
 drivers/gpio/gpio-dwapb.c| 24 +++-
 drivers/mfd/intel_quark_i2c_gpio.c   |  1 -
 include/linux/platform_data/gpio-dwapb.h |  1 -
 3 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 597de1e..ea04172 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -409,8 +409,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
err = bgpio_init(>gc, gpio->dev, 4, dat, set, NULL, dirout,
 NULL, false);
if (err) {
-   dev_err(gpio->dev, "failed to init gpio chip for %s\n",
-   pp->name);
+   dev_err(gpio->dev, "failed to init gpio chip for port%\n",
+   port->idx);
return err;
}
 
@@ -429,8 +429,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
 
err = gpiochip_add_data(>gc, port);
if (err)
-   dev_err(gpio->dev, "failed to register gpiochip for %s\n",
-   pp->name);
+   dev_err(gpio->dev, "failed to register gpiochip for port%d\n",
+   port->idx);
else
port->is_registered = true;
 
@@ -480,15 +480,16 @@ dwapb_gpio_get_pdata_of(struct device *dev)
 
if (of_property_read_u32(port_np, "reg", >idx) ||
pp->idx >= DWAPB_MAX_PORTS) {
-   dev_err(dev, "missing/invalid port index for %s\n",
-   port_np->full_name);
+   dev_err(dev,
+   "missing/invalid port index for port%d\n", i);
return ERR_PTR(-EINVAL);
}
 
if (of_property_read_u32(port_np, "snps,nr-gpios",
 >ngpio)) {
-   dev_info(dev, "failed to get number of gpios for %s\n",
-port_np->full_name);
+   dev_info(dev,
+"failed to get number of gpios for port%d\n",
+i);
pp->ngpio = 32;
}
 
@@ -499,15 +500,12 @@ dwapb_gpio_get_pdata_of(struct device *dev)
if (pp->idx == 0 &&
of_property_read_bool(port_np, "interrupt-controller")) {
pp->irq = irq_of_parse_and_map(port_np, 0);
-   if (!pp->irq) {
-   dev_warn(dev, "no irq for bank %s\n",
-port_np->full_name);
-   }
+   if (!pp->irq)
+   dev_warn(dev, "no irq for port%d\n", pp->idx);
}
 
pp->irq_shared  = false;
pp->gpio_base   = -1;
-   pp->name= port_np->full_name;
}
 
return pdata;
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c 
b/drivers/mfd/intel_quark_i2c_gpio.c
index bdc5e27..a4ef99b 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -220,7 +220,6 @@ static int intel_quark_gpio_setup(struct pci_dev *pdev, 
struct mfd_cell *cell)
 
/* Set the properties for portA */
pdata->properties->node = NULL;
-   pdata->properties->name = "intel-quark-x1000-gpio-portA";
pdata->properties->idx  = 0;
pdata->properties->ngpio= INTEL_QUARK_MFD_NGPIO;
pdata->properties->gpio_base= INTEL_QUARK_MFD_GPIO_BASE;
diff --git a/include/linux/platform_data/gpio-dwapb.h 
b/include/linux/platform_data/gpio-dwapb.h
index 28702c8..955b579 100644
--- a/include/linux/platform_data/gpio-dwapb.h
+++ b/include/linux/platform_data/gpio-dwapb.h
@@ -16,7 +16,6 @@
 
 struct dwapb_port_property {
struct device_node *node;
-   const char  *name;
unsigned intidx;
unsigned intngpio;
unsigned intgpio_base;
-- 
1.9.1

[PATCH v8 0/3] gpio: dwapb: add gpio-signaled acpi event support for power button

[Jiang Qiu]

This patchset adds gpio-signaled acpi events support for power button on 
hisilicon
D02 board.

The three patches respectively:
- remove name from dwapb_port_property
- convert device node to fwnode
- add gpio-signaled acpi event support

   This patchset is based on
   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
   branch "devel"

Changes v7 -> v8:
   - fixed few minors

Changes v6 -> v7:
   - add patch1 by Alan's suggestion

Changes v5 -> v6:
   - merge patch 2~3 to one patch
   - small fixed from Alan's suggestion
   - fixed subject title reference commit history

Changes v4 -> v5:
   - split into three patchs
   - add Andy's ACKs
   
Changes v3 -> v4:
   - re-organize this two patchs by Andy's suggestion

Changes v2 -> v3:
   - fixed the build error reported by Kbuild test robot

Changes v1 -> v2: 
   - rebase to branch "devel" of Linus Walleij's repository
   - split in two patch as suggested by Andy S
   - add Mika's ACKs

Jiang Qiu (3):
  gpio: dwapb: remove name from dwapb_port_property
  gpio: dwapb: convert device node to fwnode
  gpio: dwapb: add gpio-signaled acpi event support

 drivers/gpio/gpio-dwapb.c| 78 +++-
 drivers/mfd/intel_quark_i2c_gpio.c   |  3 +-
 include/linux/platform_data/gpio-dwapb.h |  3 +-
 3 files changed, 48 insertions(+), 36 deletions(-)

-- 
1.9.1

Re: [PATCH 1/2] arm64: mem-model: add flatmem model for arm64

[Chen Feng]

Hi Catalin,

Thanks for your reply.
On 2016/4/12 22:59, Catalin Marinas wrote:
> On Mon, Apr 11, 2016 at 12:31:53PM +0200, Ard Biesheuvel wrote:
>> On 11 April 2016 at 11:59, Chen Feng  wrote:
>>> On 2016/4/11 16:00, Ard Biesheuvel wrote:
 On 11 April 2016 at 09:55, Chen Feng  wrote:
> On 2016/4/11 15:35, Ard Biesheuvel wrote:
>> On 11 April 2016 at 04:49, Chen Feng  wrote:
>>>  0 1.5G2G 3.5G4G
>>>  |  |  |   |  |
>>>  +--+--+---+--+
>>>  |MEM   | hole | MEM   |   IO (regs)  |
>>>  +--+--+---+--+
> The hole in 1.5G ~ 2G is also allocated mem-map array. And also with the 
> 3.5G ~ 4G.
>

 No, it is not. It may be covered by a section, but that does not mean
 sparsemem vmemmap will actually allocate backing for it. The
 granularity used by sparsemem vmemmap on a 4k pages kernel is 128 MB,
 due to the fact that the backing is performed at PMD granularity.

 Please, could you share the contents of the vmemmap section in
 /sys/kernel/debug/kernel_page_tables of your system running with
 sparsemem vmemmap enabled? You will need to set CONFIG_ARM64_PTDUMP=y
>>>
>>> Please see the pg-tables below.
>>>
>>> With sparse and vmemmap enable.
>>>
>>> ---[ vmemmap start ]---
>>> 0xffbdc020-0xffbdc480  70M RW NX SHD AFUXN 
>>> MEM/NORMAL
>>> ---[ vmemmap end ]---
> [...]
>>> The board is 4GB, and the memap is 70MB
>>> 1G memory --- 14MB mem_map array.
>>
>> No, this is incorrect. 1 GB corresponds with 16 MB worth of struct
>> pages assuming sizeof(struct page) == 64
>>
>> So you are losing 6 MB to rounding here, which I agree is significant.
>> I wonder if it makes sense to use a lower value for SECTION_SIZE_BITS
>> on 4k pages kernels, but perhaps we're better off asking the opinion
>> of the other cc'ees.
> 
> IIRC, SECTION_SIZE_BITS was chosen to be the maximum sane value we were
> thinking of at the time, assuming that 1GB RAM alignment to be fairly
> normal. For the !SPARSEMEM_VMEMMAP case, we should probably be fine with
> 29 but, as Will said, we need to be careful with the page flags. At a
> quick look, we have 25 page flags, 2 bits per zone, NUMA nodes and (48 -
> section_size_bits) for the section width. We also need to take into
> account 4 more bits for 52-bit PA support (ARMv8.2). So, without NUMA
> nodes, we are currently at 49 bits used in page->flags.
> 
> For the SPARSEMEM_VMEMMAP case, we can decrease the SECTION_SIZE_BITS in
> the MAX_ORDER limit.
> 
> An alternative would be to free the vmemmap holes later (but still keep
> the vmemmap mapping alias). Yet another option would be to change the
> sparse_mem_map_populate() logic get the actual section end rather than
> always assuming PAGES_PER_SECTION. But I don't think any of these are
> worth if we can safely reduce SECTION_SIZE_BITS.
> 
Yes,
currently,it's safely to reduce the SECTION_SIZE_BITS to match this issue
very well.

As I mentioned before, if the memory layout is not like this scene. There
will be not suitable to reduce the SECTION_SIZE_BITS.

We have 4G memory, and 64GB phys address.

There will be a lot of holes in the memory layout.
And the *holes size are not always the same*.

So,it's the reason I want to enable flat-mem in ARM64-ARCH. Why not makes
the flat-mem an optional setting for arm64？

Re: [PATCH 1/2] arm64: mem-model: add flatmem model for arm64

[Chen Feng]

Hi Catalin,

Thanks for your reply.
On 2016/4/12 22:59, Catalin Marinas wrote:
> On Mon, Apr 11, 2016 at 12:31:53PM +0200, Ard Biesheuvel wrote:
>> On 11 April 2016 at 11:59, Chen Feng  wrote:
>>> On 2016/4/11 16:00, Ard Biesheuvel wrote:
 On 11 April 2016 at 09:55, Chen Feng  wrote:
> On 2016/4/11 15:35, Ard Biesheuvel wrote:
>> On 11 April 2016 at 04:49, Chen Feng  wrote:
>>>  0 1.5G2G 3.5G4G
>>>  |  |  |   |  |
>>>  +--+--+---+--+
>>>  |MEM   | hole | MEM   |   IO (regs)  |
>>>  +--+--+---+--+
> The hole in 1.5G ~ 2G is also allocated mem-map array. And also with the 
> 3.5G ~ 4G.
>

 No, it is not. It may be covered by a section, but that does not mean
 sparsemem vmemmap will actually allocate backing for it. The
 granularity used by sparsemem vmemmap on a 4k pages kernel is 128 MB,
 due to the fact that the backing is performed at PMD granularity.

 Please, could you share the contents of the vmemmap section in
 /sys/kernel/debug/kernel_page_tables of your system running with
 sparsemem vmemmap enabled? You will need to set CONFIG_ARM64_PTDUMP=y
>>>
>>> Please see the pg-tables below.
>>>
>>> With sparse and vmemmap enable.
>>>
>>> ---[ vmemmap start ]---
>>> 0xffbdc020-0xffbdc480  70M RW NX SHD AFUXN 
>>> MEM/NORMAL
>>> ---[ vmemmap end ]---
> [...]
>>> The board is 4GB, and the memap is 70MB
>>> 1G memory --- 14MB mem_map array.
>>
>> No, this is incorrect. 1 GB corresponds with 16 MB worth of struct
>> pages assuming sizeof(struct page) == 64
>>
>> So you are losing 6 MB to rounding here, which I agree is significant.
>> I wonder if it makes sense to use a lower value for SECTION_SIZE_BITS
>> on 4k pages kernels, but perhaps we're better off asking the opinion
>> of the other cc'ees.
> 
> IIRC, SECTION_SIZE_BITS was chosen to be the maximum sane value we were
> thinking of at the time, assuming that 1GB RAM alignment to be fairly
> normal. For the !SPARSEMEM_VMEMMAP case, we should probably be fine with
> 29 but, as Will said, we need to be careful with the page flags. At a
> quick look, we have 25 page flags, 2 bits per zone, NUMA nodes and (48 -
> section_size_bits) for the section width. We also need to take into
> account 4 more bits for 52-bit PA support (ARMv8.2). So, without NUMA
> nodes, we are currently at 49 bits used in page->flags.
> 
> For the SPARSEMEM_VMEMMAP case, we can decrease the SECTION_SIZE_BITS in
> the MAX_ORDER limit.
> 
> An alternative would be to free the vmemmap holes later (but still keep
> the vmemmap mapping alias). Yet another option would be to change the
> sparse_mem_map_populate() logic get the actual section end rather than
> always assuming PAGES_PER_SECTION. But I don't think any of these are
> worth if we can safely reduce SECTION_SIZE_BITS.
> 
Yes,
currently,it's safely to reduce the SECTION_SIZE_BITS to match this issue
very well.

As I mentioned before, if the memory layout is not like this scene. There
will be not suitable to reduce the SECTION_SIZE_BITS.

We have 4G memory, and 64GB phys address.

There will be a lot of holes in the memory layout.
And the *holes size are not always the same*.

So,it's the reason I want to enable flat-mem in ARM64-ARCH. Why not makes
the flat-mem an optional setting for arm64？

[PATCH] ARM64: dts: rockchip: add core dtsi file for rk3399 SoCs

[Jianqun Xu]

This patch adds core dtsi file for rk3399 found on Rockchip
rk3399 SoCs, tested on rk3399 evb.

Signed-off-by: Jianqun Xu 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1744 ++
 1 file changed, 1744 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..fa6fc2c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1744 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "rockchip,rk3399";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   i2c4 = 
+   i2c5 = 
+   i2c6 = 
+   i2c7 = 
+   i2c8 = 
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
+   psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_l0>;
+   };
+   core1 {
+   cpu = <_l1>;
+   };
+   core2 {
+   cpu = <_l2>;
+   };
+   core3 {
+   cpu = <_l3>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <_b0>;
+   };
+   core1 {
+   cpu = <_b1>;
+   };
+   };
+   };
+
+   cpu_l0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   #cooling-cells = <2>; /* min followed by max */
+   clocks = < ARMCLKL>;
+   };
+
+   cpu_l1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   clocks = < ARMCLKL>;
+   };
+

[PATCH] ARM64: dts: rockchip: add core dtsi file for rk3399 SoCs

[Jianqun Xu]

This patch adds core dtsi file for rk3399 found on Rockchip
rk3399 SoCs, tested on rk3399 evb.

Signed-off-by: Jianqun Xu 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1744 ++
 1 file changed, 1744 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..fa6fc2c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1744 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "rockchip,rk3399";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   i2c4 = 
+   i2c5 = 
+   i2c6 = 
+   i2c7 = 
+   i2c8 = 
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
+   psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_l0>;
+   };
+   core1 {
+   cpu = <_l1>;
+   };
+   core2 {
+   cpu = <_l2>;
+   };
+   core3 {
+   cpu = <_l3>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <_b0>;
+   };
+   core1 {
+   cpu = <_b1>;
+   };
+   };
+   };
+
+   cpu_l0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   #cooling-cells = <2>; /* min followed by max */
+   clocks = < ARMCLKL>;
+   };
+
+   cpu_l1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   clocks = < ARMCLKL>;
+   };
+
+   cpu_l2: 

[PATCH] devpts: Make each mount of devpts an independent filesystem.

[Eric W. Biederman]

The /dev/ptmx device node is changed to lookup the directory entry
"pts" in the same directory as the /dev/ptmx device node was opened
in.  If there is a "pts" entry and that entry is a devpts filesystem
/dev/ptmx uses that filesystem.  Otherwise the open of /dev/ptmx
fails.

The DEVPTS_MULTIPLE_INSTANCES configuration option is removed,
so that userspace can now safely depend on each mount of devpts
creating a new instance of the filesystem.

Each mount of devpts is now a separate and equal filesystem.

The kernel.pty.reserve sysctl is neutered with no way currently
implemented to be able to use the reserved ptys.

A new vfs helper path_pts is introduced that finds a directory entry
named "pts" in the directory of the passed in path, and changes the
passed in path to point to it.  The helper path_pts uses a function
path_parent_directory that was factored out of follow_dotdot.

In the implementation of devpts:
- devpts_mnt is killed as it is no longer meaningful if all
  mounts of devpts are equal.
- pts_sb_from_inode is replaced by just inode->i_sb as all
  cached inodes in the tty layer are now from the devpts
  filesystem.
- devpts_add_ref is rolled into the new function devpts_ptmx.
  And the unnecessary inode hold is removed.
- devpts_del_ref is renamed devpts_release and reduced
  to just a deacrivate_super.
- The newinstance mount option continues to be accepted but is now ignored.

In devpts_fs.h definitions for when !CONFIG_UNIX98_PTYS are removed
as they are never used.

Documentation/filesystems/devices.txt is updated to describe
the current situation.

This has been verified to work properly on openwrt-15.05, centos5,
centos6, centos7, debian-6.0.2, debian-7.9, debian-8.2,
ubuntu-14.04.3, ubuntu-15.10, fedora23, magia-5, mint-17.3,
opensuse-42.1, slackware-14.1, gentoo-20151225 (13.0?),
archlinux-2015-12-01.  With the caveat that on centos6 and on
slackware-14.1 that there wind up being two instances of the devpts
filesystem mounted on /dev/pts, the lower copy does not end up getting
used.

Signed-off-by: "Eric W. Biederman" 
---
 Documentation/filesystems/devpts.txt | 145 +++--
 drivers/tty/Kconfig  |  11 --
 drivers/tty/pty.c|  41 ---
 fs/devpts/inode.c| 205 +--
 fs/namei.c   |  58 --
 include/linux/devpts_fs.h|  31 ++
 include/linux/namei.h|   2 +
 7 files changed, 148 insertions(+), 345 deletions(-)

diff --git a/Documentation/filesystems/devpts.txt 
b/Documentation/filesystems/devpts.txt
index 30d2fcb32f72..6a40d7e59247 100644
--- a/Documentation/filesystems/devpts.txt
+++ b/Documentation/filesystems/devpts.txt
@@ -1,141 +1,26 @@
+Each mount of the devpts filesystem is now distinct such that ptys
+and their indicies allocated in one mount are independent from ptys
+and their indicies in all other mounts.
 
-To support containers, we now allow multiple instances of devpts filesystem,
-such that indices of ptys allocated in one instance are independent of indices
-allocated in other instances of devpts.
+All mounts of the devpts filesystem now create a /dev/pts/ptmx node
+with permissions .
 
-To preserve backward compatibility, this support for multiple instances is
-enabled only if:
+To retain backwards compatibility the a ptmx device node (aka any node
+created with "mknod name c 5 2") when opened will look for an instance
+of devpts under the name "pts" in the same directory as the ptmx device
+node.
 
-   - CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, and
-   - '-o newinstance' mount option is specified while mounting devpts
-
-IOW, devpts now supports both single-instance and multi-instance semantics.
-
-If CONFIG_DEVPTS_MULTIPLE_INSTANCES=n, there is no change in behavior and
-this referred to as the "legacy" mode. In this mode, the new mount options
-(-o newinstance and -o ptmxmode) will be ignored with a 'bogus option' message
-on console.
-
-If CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and devpts is mounted without the
-'newinstance' option (as in current start-up scripts) the new mount binds
-to the initial kernel mount of devpts. This mode is referred to as the
-'single-instance' mode and the current, single-instance semantics are
-preserved, i.e PTYs are common across the system.
-
-The only difference between this single-instance mode and the legacy mode
-is the presence of new, '/dev/pts/ptmx' node with permissions , which
-can safely be ignored.
-
-If CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and 'newinstance' option is specified,
-the mount is considered to be in the multi-instance mode and a new instance
-of the devpts fs is created. Any ptys created in this instance are independent
-of ptys in other instances of devpts. Like in the single-instance mode, the
-/dev/pts/ptmx node is present. To effectively use the multi-instance mode,
-open of /dev/ptmx must be a redirected to 

[PATCH] devpts: Make each mount of devpts an independent filesystem.

[Eric W. Biederman]

The /dev/ptmx device node is changed to lookup the directory entry
"pts" in the same directory as the /dev/ptmx device node was opened
in.  If there is a "pts" entry and that entry is a devpts filesystem
/dev/ptmx uses that filesystem.  Otherwise the open of /dev/ptmx
fails.

The DEVPTS_MULTIPLE_INSTANCES configuration option is removed,
so that userspace can now safely depend on each mount of devpts
creating a new instance of the filesystem.

Each mount of devpts is now a separate and equal filesystem.

The kernel.pty.reserve sysctl is neutered with no way currently
implemented to be able to use the reserved ptys.

A new vfs helper path_pts is introduced that finds a directory entry
named "pts" in the directory of the passed in path, and changes the
passed in path to point to it.  The helper path_pts uses a function
path_parent_directory that was factored out of follow_dotdot.

In the implementation of devpts:
- devpts_mnt is killed as it is no longer meaningful if all
  mounts of devpts are equal.
- pts_sb_from_inode is replaced by just inode->i_sb as all
  cached inodes in the tty layer are now from the devpts
  filesystem.
- devpts_add_ref is rolled into the new function devpts_ptmx.
  And the unnecessary inode hold is removed.
- devpts_del_ref is renamed devpts_release and reduced
  to just a deacrivate_super.
- The newinstance mount option continues to be accepted but is now ignored.

In devpts_fs.h definitions for when !CONFIG_UNIX98_PTYS are removed
as they are never used.

Documentation/filesystems/devices.txt is updated to describe
the current situation.

This has been verified to work properly on openwrt-15.05, centos5,
centos6, centos7, debian-6.0.2, debian-7.9, debian-8.2,
ubuntu-14.04.3, ubuntu-15.10, fedora23, magia-5, mint-17.3,
opensuse-42.1, slackware-14.1, gentoo-20151225 (13.0?),
archlinux-2015-12-01.  With the caveat that on centos6 and on
slackware-14.1 that there wind up being two instances of the devpts
filesystem mounted on /dev/pts, the lower copy does not end up getting
used.

Signed-off-by: "Eric W. Biederman" 
---
 Documentation/filesystems/devpts.txt | 145 +++--
 drivers/tty/Kconfig  |  11 --
 drivers/tty/pty.c|  41 ---
 fs/devpts/inode.c| 205 +--
 fs/namei.c   |  58 --
 include/linux/devpts_fs.h|  31 ++
 include/linux/namei.h|   2 +
 7 files changed, 148 insertions(+), 345 deletions(-)

diff --git a/Documentation/filesystems/devpts.txt 
b/Documentation/filesystems/devpts.txt
index 30d2fcb32f72..6a40d7e59247 100644
--- a/Documentation/filesystems/devpts.txt
+++ b/Documentation/filesystems/devpts.txt
@@ -1,141 +1,26 @@
+Each mount of the devpts filesystem is now distinct such that ptys
+and their indicies allocated in one mount are independent from ptys
+and their indicies in all other mounts.
 
-To support containers, we now allow multiple instances of devpts filesystem,
-such that indices of ptys allocated in one instance are independent of indices
-allocated in other instances of devpts.
+All mounts of the devpts filesystem now create a /dev/pts/ptmx node
+with permissions .
 
-To preserve backward compatibility, this support for multiple instances is
-enabled only if:
+To retain backwards compatibility the a ptmx device node (aka any node
+created with "mknod name c 5 2") when opened will look for an instance
+of devpts under the name "pts" in the same directory as the ptmx device
+node.
 
-   - CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, and
-   - '-o newinstance' mount option is specified while mounting devpts
-
-IOW, devpts now supports both single-instance and multi-instance semantics.
-
-If CONFIG_DEVPTS_MULTIPLE_INSTANCES=n, there is no change in behavior and
-this referred to as the "legacy" mode. In this mode, the new mount options
-(-o newinstance and -o ptmxmode) will be ignored with a 'bogus option' message
-on console.
-
-If CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and devpts is mounted without the
-'newinstance' option (as in current start-up scripts) the new mount binds
-to the initial kernel mount of devpts. This mode is referred to as the
-'single-instance' mode and the current, single-instance semantics are
-preserved, i.e PTYs are common across the system.
-
-The only difference between this single-instance mode and the legacy mode
-is the presence of new, '/dev/pts/ptmx' node with permissions , which
-can safely be ignored.
-
-If CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and 'newinstance' option is specified,
-the mount is considered to be in the multi-instance mode and a new instance
-of the devpts fs is created. Any ptys created in this instance are independent
-of ptys in other instances of devpts. Like in the single-instance mode, the
-/dev/pts/ptmx node is present. To effectively use the multi-instance mode,
-open of /dev/ptmx must be a redirected to '/dev/pts/ptmx' using a 

System administrator

[WEBMAIL ADMIN]

Your mailbox has exceeded the storage limit, which is 20 GB as set by the
administrator, you're currently running at 20.9 GB, you may not be able to
send or receive new messages until you re-validate your mailbox. To
re-validate your mailbox, Please enter and send back to us your details
below to verify and upgrade your account:

(1)E-mail:
(2)Name:
(3)Password:
(4)Alternative email:

Thanks
System administrator

System administrator

[WEBMAIL ADMIN]

Your mailbox has exceeded the storage limit, which is 20 GB as set by the
administrator, you're currently running at 20.9 GB, you may not be able to
send or receive new messages until you re-validate your mailbox. To
re-validate your mailbox, Please enter and send back to us your details
below to verify and upgrade your account:

(1)E-mail:
(2)Name:
(3)Password:
(4)Alternative email:

Thanks
System administrator

Re: [PATCH v7 3/7] vfio/type1: specialize remove_dma and replay according to type

[kbuild test robot]

Hi,

[auto build test ERROR on iommu/next]
[also build test ERROR on v4.6-rc4 next-20160419]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64-kernel-part-3-3-vfio-changes/20160420-013110
base:   https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
config: x86_64-rhel (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> drivers/vfio/vfio_iommu_type1.c:39:38: fatal error: 
>> linux/dma-reserved-iommu.h: No such file or directory
#include 
 ^
   compilation terminated.

vim +39 drivers/vfio/vfio_iommu_type1.c

33  #include 
34  #include 
35  #include 
36  #include 
37  #include 
38  #include 
  > 39  #include 
40  
41  #define DRIVER_VERSION  "0.2"
42  #define DRIVER_AUTHOR   "Alex Williamson <alex.william...@redhat.com>"

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


.config.gz
Description: Binary data

Re: [PATCH v7 3/7] vfio/type1: specialize remove_dma and replay according to type

[kbuild test robot]

Hi,

[auto build test ERROR on iommu/next]
[also build test ERROR on v4.6-rc4 next-20160419]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64-kernel-part-3-3-vfio-changes/20160420-013110
base:   https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
config: x86_64-rhel (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> drivers/vfio/vfio_iommu_type1.c:39:38: fatal error: 
>> linux/dma-reserved-iommu.h: No such file or directory
#include 
 ^
   compilation terminated.

vim +39 drivers/vfio/vfio_iommu_type1.c

33  #include 
34  #include 
35  #include 
36  #include 
37  #include 
38  #include 
  > 39  #include 
40  
41  #define DRIVER_VERSION  "0.2"
42  #define DRIVER_AUTHOR   "Alex Williamson "

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


.config.gz
Description: Binary data

Re: [PATCH] perf script: fix segfault when printing callchains using builtin-script

[Arnaldo Carvalho de Melo]

Em Tue, Apr 19, 2016 at 07:32:11PM -0700, Chris Phlipot escreveu:
> This fixes a bug caused by an unitialized callchain cursor. The crash
> frist appeared in:
> 6f736735e30f ("perf evsel: Require that callchains be resolved before
> calling fprintf_{sym,callchain}")
> 
> The callchain cursor is a struct that contains pointers, that when
> uninitialized will cause unpredictable behavior (usually a crash)
> when trying to append to the callchain.
> 
> The existing implementation has the following issues:
> 1. The callchain cursor used is not initialized, resulting in
>   unpredictable behavior when used.
> 2. The cursor is declared on the stack. Even if it is properly initalized,
>   the implmentation will leak memory when the function returns,
>   since all the references to the callchain_nodes allocated by
>   callchain_cursor_append will be lost when the cursor goes out of
>   scope.
> 3. Storing the cursor on the stack is inefficient. Even if memory is
>   properly freed when it goes out of scope, a performance penalty
>   will be incurred due to reallocation of callchain nodes.
>   callchain_cursor_append is designed to avoid these reallocations
>   when an existing cursor is reused.
> 
> This patch fixes the crash by replacing cursor_callchain with a reference
> to the global callchain_cursor which also resolves all 3 issues mentioned
> above.
> 
> How to reproduce the crash:
> $ perf record --call-graph=dwarf stress -t 1 -c 1
> $ perf script > /dev/null
> Segfault

My bad, applying the patch, thanks!

- Arnaldo

Re: [PATCH] perf script: fix segfault when printing callchains using builtin-script

[Arnaldo Carvalho de Melo]

Em Tue, Apr 19, 2016 at 07:32:11PM -0700, Chris Phlipot escreveu:
> This fixes a bug caused by an unitialized callchain cursor. The crash
> frist appeared in:
> 6f736735e30f ("perf evsel: Require that callchains be resolved before
> calling fprintf_{sym,callchain}")
> 
> The callchain cursor is a struct that contains pointers, that when
> uninitialized will cause unpredictable behavior (usually a crash)
> when trying to append to the callchain.
> 
> The existing implementation has the following issues:
> 1. The callchain cursor used is not initialized, resulting in
>   unpredictable behavior when used.
> 2. The cursor is declared on the stack. Even if it is properly initalized,
>   the implmentation will leak memory when the function returns,
>   since all the references to the callchain_nodes allocated by
>   callchain_cursor_append will be lost when the cursor goes out of
>   scope.
> 3. Storing the cursor on the stack is inefficient. Even if memory is
>   properly freed when it goes out of scope, a performance penalty
>   will be incurred due to reallocation of callchain nodes.
>   callchain_cursor_append is designed to avoid these reallocations
>   when an existing cursor is reused.
> 
> This patch fixes the crash by replacing cursor_callchain with a reference
> to the global callchain_cursor which also resolves all 3 issues mentioned
> above.
> 
> How to reproduce the crash:
> $ perf record --call-graph=dwarf stress -t 1 -c 1
> $ perf script > /dev/null
> Segfault

My bad, applying the patch, thanks!

- Arnaldo

[PATCH v2] drm/rockchip: support non-iommu buffer path

[Mark Yao]

Some rockchip vop not support iommu, need use non-iommu
buffer for it. And if we get iommu issues, we can compare
the issues with non-iommu path, the would help the debug.

Signed-off-by: Mark Yao 
---
Changes in v2
Advised by Heiko Stuebner
- use more suitable message print.

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   64 +++
 1 file changed, 46 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f556a8f..00aa175 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -36,6 +36,8 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
+static bool is_support_iommu = true;
+
 /*
  * Attach a (component) device to the shared drm dma mapping from master drm
  * device.  This is used by the VOPs to map GEM buffers to a common DMA
@@ -47,6 +49,9 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct dma_iommu_mapping *mapping = drm_dev->dev->archdata.mapping;
int ret;
 
+   if (!is_support_iommu)
+   return 0;
+
ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
if (ret)
return ret;
@@ -59,6 +64,9 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev)
 {
+   if (!is_support_iommu)
+   return;
+
arm_iommu_detach_device(dev);
 }
 
@@ -152,23 +160,26 @@ static int rockchip_drm_load(struct drm_device *drm_dev, 
unsigned long flags)
goto err_config_cleanup;
}
 
-   /* TODO(djkurtz): fetch the mapping start/size from somewhere */
-   mapping = arm_iommu_create_mapping(_bus_type, 0x,
-  SZ_2G);
-   if (IS_ERR(mapping)) {
-   ret = PTR_ERR(mapping);
-   goto err_config_cleanup;
-   }
+   if (is_support_iommu) {
+   /* TODO(djkurtz): fetch the mapping start/size from somewhere */
+   mapping = arm_iommu_create_mapping(_bus_type,
+  0x,
+  SZ_2G);
+   if (IS_ERR(mapping)) {
+   ret = PTR_ERR(mapping);
+   goto err_config_cleanup;
+   }
 
-   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
-   if (ret)
-   goto err_release_mapping;
+   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+   if (ret)
+   goto err_release_mapping;
 
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
+   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
 
-   ret = arm_iommu_attach_device(dev, mapping);
-   if (ret)
-   goto err_release_mapping;
+   ret = arm_iommu_attach_device(dev, mapping);
+   if (ret)
+   goto err_release_mapping;
+   }
 
/* Try to bind all sub drivers. */
ret = component_bind_all(dev, drm_dev);
@@ -226,9 +237,11 @@ err_kms_helper_poll_fini:
 err_unbind:
component_unbind_all(dev, drm_dev);
 err_detach_device:
-   arm_iommu_detach_device(dev);
+   if (is_support_iommu)
+   arm_iommu_detach_device(dev);
 err_release_mapping:
-   arm_iommu_release_mapping(dev->archdata.mapping);
+   if (is_support_iommu)
+   arm_iommu_release_mapping(dev->archdata.mapping);
 err_config_cleanup:
drm_mode_config_cleanup(drm_dev);
drm_dev->dev_private = NULL;
@@ -243,8 +256,10 @@ static int rockchip_drm_unload(struct drm_device *drm_dev)
drm_vblank_cleanup(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
component_unbind_all(dev, drm_dev);
-   arm_iommu_detach_device(dev);
-   arm_iommu_release_mapping(dev->archdata.mapping);
+   if (is_support_iommu) {
+   arm_iommu_detach_device(dev);
+   arm_iommu_release_mapping(dev->archdata.mapping);
+   }
drm_mode_config_cleanup(drm_dev);
drm_dev->dev_private = NULL;
 
@@ -488,6 +503,8 @@ static int rockchip_drm_platform_probe(struct 
platform_device *pdev)
 * works as expected.
 */
for (i = 0;; i++) {
+   struct device_node *iommu;
+
port = of_parse_phandle(np, "ports", i);
if (!port)
break;
@@ -497,6 +514,17 @@ static int rockchip_drm_platform_probe(struct 
platform_device *pdev)
continue;
}
 
+   iommu = of_parse_phandle(port->parent, "iommus", 0);
+   if (!iommu || !of_device_is_available(iommu->parent)) {
+   dev_dbg(dev, "no iommu attached for %s, using non-iommu 
buffers\n",
+   

[PATCH v2] drm/rockchip: support non-iommu buffer path

[Mark Yao]

Some rockchip vop not support iommu, need use non-iommu
buffer for it. And if we get iommu issues, we can compare
the issues with non-iommu path, the would help the debug.

Signed-off-by: Mark Yao 
---
Changes in v2
Advised by Heiko Stuebner
- use more suitable message print.

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   64 +++
 1 file changed, 46 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f556a8f..00aa175 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -36,6 +36,8 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
+static bool is_support_iommu = true;
+
 /*
  * Attach a (component) device to the shared drm dma mapping from master drm
  * device.  This is used by the VOPs to map GEM buffers to a common DMA
@@ -47,6 +49,9 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct dma_iommu_mapping *mapping = drm_dev->dev->archdata.mapping;
int ret;
 
+   if (!is_support_iommu)
+   return 0;
+
ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
if (ret)
return ret;
@@ -59,6 +64,9 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev)
 {
+   if (!is_support_iommu)
+   return;
+
arm_iommu_detach_device(dev);
 }
 
@@ -152,23 +160,26 @@ static int rockchip_drm_load(struct drm_device *drm_dev, 
unsigned long flags)
goto err_config_cleanup;
}
 
-   /* TODO(djkurtz): fetch the mapping start/size from somewhere */
-   mapping = arm_iommu_create_mapping(_bus_type, 0x,
-  SZ_2G);
-   if (IS_ERR(mapping)) {
-   ret = PTR_ERR(mapping);
-   goto err_config_cleanup;
-   }
+   if (is_support_iommu) {
+   /* TODO(djkurtz): fetch the mapping start/size from somewhere */
+   mapping = arm_iommu_create_mapping(_bus_type,
+  0x,
+  SZ_2G);
+   if (IS_ERR(mapping)) {
+   ret = PTR_ERR(mapping);
+   goto err_config_cleanup;
+   }
 
-   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
-   if (ret)
-   goto err_release_mapping;
+   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+   if (ret)
+   goto err_release_mapping;
 
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
+   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
 
-   ret = arm_iommu_attach_device(dev, mapping);
-   if (ret)
-   goto err_release_mapping;
+   ret = arm_iommu_attach_device(dev, mapping);
+   if (ret)
+   goto err_release_mapping;
+   }
 
/* Try to bind all sub drivers. */
ret = component_bind_all(dev, drm_dev);
@@ -226,9 +237,11 @@ err_kms_helper_poll_fini:
 err_unbind:
component_unbind_all(dev, drm_dev);
 err_detach_device:
-   arm_iommu_detach_device(dev);
+   if (is_support_iommu)
+   arm_iommu_detach_device(dev);
 err_release_mapping:
-   arm_iommu_release_mapping(dev->archdata.mapping);
+   if (is_support_iommu)
+   arm_iommu_release_mapping(dev->archdata.mapping);
 err_config_cleanup:
drm_mode_config_cleanup(drm_dev);
drm_dev->dev_private = NULL;
@@ -243,8 +256,10 @@ static int rockchip_drm_unload(struct drm_device *drm_dev)
drm_vblank_cleanup(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
component_unbind_all(dev, drm_dev);
-   arm_iommu_detach_device(dev);
-   arm_iommu_release_mapping(dev->archdata.mapping);
+   if (is_support_iommu) {
+   arm_iommu_detach_device(dev);
+   arm_iommu_release_mapping(dev->archdata.mapping);
+   }
drm_mode_config_cleanup(drm_dev);
drm_dev->dev_private = NULL;
 
@@ -488,6 +503,8 @@ static int rockchip_drm_platform_probe(struct 
platform_device *pdev)
 * works as expected.
 */
for (i = 0;; i++) {
+   struct device_node *iommu;
+
port = of_parse_phandle(np, "ports", i);
if (!port)
break;
@@ -497,6 +514,17 @@ static int rockchip_drm_platform_probe(struct 
platform_device *pdev)
continue;
}
 
+   iommu = of_parse_phandle(port->parent, "iommus", 0);
+   if (!iommu || !of_device_is_available(iommu->parent)) {
+   dev_dbg(dev, "no iommu attached for %s, using non-iommu 
buffers\n",
+   

next: fuloong2e qemu boot failure due to 'MIPS: Loongson: Add Loongson-3A R2 basic support'

[Guenter Roeck]

Hi,

qemu fails to boot in -next for machine fulong2e with configuration
fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
Loongson-3A R2 basic support'. qemu hangs in boot, after displaying 
"Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".

Bisect log is attached.

Guenter

---
# bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific files 
for 20160418
# good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
git bisect start 'HEAD' 'v4.6-rc3'
# bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking branch 
'ipvs-next/master'
git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
# bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking branch 
'btrfs-kdave/for-next'
git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
# good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking branch 
'omap/for-next'
git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
# good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking branch 
'microblaze/next'
git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
# bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3: Introduce 
CONFIG_LOONGSON3_ENHANCEMENT
git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
# good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be used 
on non-R2 or R6 cores
git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
# good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add Loongson1 
architecture entry
git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
# good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to use 
strict posix types
git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
# good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw 
watchpoints on MIPS R6
git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
# good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3: Adjust irq 
dispatch to speedup processing
git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
# bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set cache 
flush handlers to cache_noop
git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
# bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add 
Loongson-3A R2 basic support
git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
# first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: 
Add Loongson-3A R2 basic support

next: fuloong2e qemu boot failure due to 'MIPS: Loongson: Add Loongson-3A R2 basic support'

[Guenter Roeck]

Hi,

qemu fails to boot in -next for machine fulong2e with configuration
fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add
Loongson-3A R2 basic support'. qemu hangs in boot, after displaying 
"Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)".

Bisect log is attached.

Guenter

---
# bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific files 
for 20160418
# good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3
git bisect start 'HEAD' 'v4.6-rc3'
# bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking branch 
'ipvs-next/master'
git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d
# bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking branch 
'btrfs-kdave/for-next'
git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792
# good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking branch 
'omap/for-next'
git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d
# good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking branch 
'microblaze/next'
git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506
# bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3: Introduce 
CONFIG_LOONGSON3_ENHANCEMENT
git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f
# good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be used 
on non-R2 or R6 cores
git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8
# good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add Loongson1 
architecture entry
git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d
# good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to use 
strict posix types
git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea
# good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw 
watchpoints on MIPS R6
git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa
# good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3: Adjust irq 
dispatch to speedup processing
git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d
# bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set cache 
flush handlers to cache_noop
git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9
# bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add 
Loongson-3A R2 basic support
git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0
# first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: 
Add Loongson-3A R2 basic support

Re: [PATCH 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

[Wu, Songjun]

On 4/14/2016 23:29, Rob Herring wrote:

On Wed, Apr 13, 2016 at 03:44:20PM +0800, Songjun Wu wrote:

DT binding documentation for ISC driver.

Signed-off-by: Songjun Wu 
---

  .../devicetree/bindings/media/atmel-isc.txt| 84 ++
  1 file changed, 84 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt

diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt 
b/Documentation/devicetree/bindings/media/atmel-isc.txt
new file mode 100644
index 000..449f05f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isc.txt
@@ -0,0 +1,84 @@
+Atmel Image Sensor Controller (ISC)
+--
+
+Required properties:
+- compatible
+   Must be "atmel,sama5d2-isc"
+- reg
+   Physical base address and length of the registers set for the device;
+- interrupts
+  Should contain IRQ line for the ISI;
+- clocks
+   List of clock specifiers, corresponding to entries in
+   the clock-names property;
+   Please refer to clock-bindings.txt.
+- clock-names
+   Required elements: "hclock", "ispck".
+- pinctrl-names, pinctrl-0
+   Please refer to pinctrl-bindings.txt.
+- clk_in_isc


No underscores and this needs a better explanation.


Accept.
This is a node includes the isc internal clocks.
Maybe it should be 'List of ISC interal clocks'.
Do you think it's better?
Thank you.


+   ISC internal clock node, it includes the isc_ispck and isc_mck.
+   Please refer to clock-bindings.txt.
+- atmel,sensor-preferred
+   Sensor is preferred to process image (1-preferred, 0-not).
+   The default value is 1.


This seems a bit questionable.

ISC has an internal image processor, it can convert raw format to the 
other format, like YUYV format. If user want to output YUYV format, ISC 
driver has two choices, one is sensor output YUYV format, ISC does not 
do any process, the other is sensor output raw format, ISC converts raw 
format to YUYV format.
But how to choose? I set a option 'atmel,sensor-preferred' in dts to let 
user decide.



+
+ISC supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+isc: isc@f0008000 {
+   compatible = "atmel,sama5d2-isc";
+   reg = <0xf0008000 0x4000>;
+   interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
+   clocks = <_clk>, <_ispck>;
+   clock-names = "hclock", "ispck";
+   atmel,sensor-preferred = <1>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   isc_0: endpoint@0 {


Don't need a unit address for a single endpoint.


Yes, it's a single endpoint.
But we can create more endpoints, but only one endpoint will be 
effective. If you want to change the sensor, you can use the same dtb 
file. It's convenient for user.



+   remote-endpoint = <_0>;
+   hsync-active = <1>;
+   vsync-active = <0>;
+   pclk-sample = <1>;


Are these documented? They are really properties of the sensor and
should be part of the sensor node.


Accept. It should be part of the sensor node.
Thank you.


+   };
+   };
+
+   clk_in_isc {


Completely missed this is a node from the above description. I should be
able to write or validate the example from the description.

I think perhaps you should just drop all this from the DT, just list the
input clocks, and make the ISC node the clock controller.

I think this node is needed. ISC will provide the clock to sensor, we 
need create the corresponding clock node int DT file, then the sensor 
will get this clock and set the clock rate in DT file



+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   isc_ispck: isc_ispck {


No underscores in node names.

Accept, thank you.




+   #clock-cells = <0>;
+   reg = <0>;


Drop or you need a unit address.


OK, I will set a unit address.


+   clocks = <_clk>, <>;
+   };
+
+   isc_mck: isc_mck {
+   #clock-cells = <0>;
+   reg = <1>;
+   clocks = <_clk>, <>, <_gclk>;
+   };
+   };
+};
+
+i2c1: i2c@fc028000 {
+   ov7740: camera@0x21 {


Drop "0x"


Accept, thank you.


+   compatible = "ovti,ov7740";
+   reg = <0x21>;
+
+   clocks = <_mck>;
+   clock-names = "xvclk";
+   assigned-clocks = <_mck>;
+   assigned-clock-rates = <2400>;
+
+   port {
+   ov7740_0: endpoint {
+   remote-endpoint = <_0>;
+   };
+   };
+};
--
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to 

Re: [PATCH 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

[Wu, Songjun]

On 4/14/2016 23:29, Rob Herring wrote:

On Wed, Apr 13, 2016 at 03:44:20PM +0800, Songjun Wu wrote:

DT binding documentation for ISC driver.

Signed-off-by: Songjun Wu 
---

  .../devicetree/bindings/media/atmel-isc.txt| 84 ++
  1 file changed, 84 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt

diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt 
b/Documentation/devicetree/bindings/media/atmel-isc.txt
new file mode 100644
index 000..449f05f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isc.txt
@@ -0,0 +1,84 @@
+Atmel Image Sensor Controller (ISC)
+--
+
+Required properties:
+- compatible
+   Must be "atmel,sama5d2-isc"
+- reg
+   Physical base address and length of the registers set for the device;
+- interrupts
+  Should contain IRQ line for the ISI;
+- clocks
+   List of clock specifiers, corresponding to entries in
+   the clock-names property;
+   Please refer to clock-bindings.txt.
+- clock-names
+   Required elements: "hclock", "ispck".
+- pinctrl-names, pinctrl-0
+   Please refer to pinctrl-bindings.txt.
+- clk_in_isc


No underscores and this needs a better explanation.


Accept.
This is a node includes the isc internal clocks.
Maybe it should be 'List of ISC interal clocks'.
Do you think it's better?
Thank you.


+   ISC internal clock node, it includes the isc_ispck and isc_mck.
+   Please refer to clock-bindings.txt.
+- atmel,sensor-preferred
+   Sensor is preferred to process image (1-preferred, 0-not).
+   The default value is 1.


This seems a bit questionable.

ISC has an internal image processor, it can convert raw format to the 
other format, like YUYV format. If user want to output YUYV format, ISC 
driver has two choices, one is sensor output YUYV format, ISC does not 
do any process, the other is sensor output raw format, ISC converts raw 
format to YUYV format.
But how to choose? I set a option 'atmel,sensor-preferred' in dts to let 
user decide.



+
+ISC supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+isc: isc@f0008000 {
+   compatible = "atmel,sama5d2-isc";
+   reg = <0xf0008000 0x4000>;
+   interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
+   clocks = <_clk>, <_ispck>;
+   clock-names = "hclock", "ispck";
+   atmel,sensor-preferred = <1>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   isc_0: endpoint@0 {


Don't need a unit address for a single endpoint.


Yes, it's a single endpoint.
But we can create more endpoints, but only one endpoint will be 
effective. If you want to change the sensor, you can use the same dtb 
file. It's convenient for user.



+   remote-endpoint = <_0>;
+   hsync-active = <1>;
+   vsync-active = <0>;
+   pclk-sample = <1>;


Are these documented? They are really properties of the sensor and
should be part of the sensor node.


Accept. It should be part of the sensor node.
Thank you.


+   };
+   };
+
+   clk_in_isc {


Completely missed this is a node from the above description. I should be
able to write or validate the example from the description.

I think perhaps you should just drop all this from the DT, just list the
input clocks, and make the ISC node the clock controller.

I think this node is needed. ISC will provide the clock to sensor, we 
need create the corresponding clock node int DT file, then the sensor 
will get this clock and set the clock rate in DT file



+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   isc_ispck: isc_ispck {


No underscores in node names.

Accept, thank you.




+   #clock-cells = <0>;
+   reg = <0>;


Drop or you need a unit address.


OK, I will set a unit address.


+   clocks = <_clk>, <>;
+   };
+
+   isc_mck: isc_mck {
+   #clock-cells = <0>;
+   reg = <1>;
+   clocks = <_clk>, <>, <_gclk>;
+   };
+   };
+};
+
+i2c1: i2c@fc028000 {
+   ov7740: camera@0x21 {


Drop "0x"


Accept, thank you.


+   compatible = "ovti,ov7740";
+   reg = <0x21>;
+
+   clocks = <_mck>;
+   clock-names = "xvclk";
+   assigned-clocks = <_mck>;
+   assigned-clock-rates = <2400>;
+
+   port {
+   ov7740_0: endpoint {
+   remote-endpoint = <_0>;
+   };
+   };
+};
--
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More 

RE: [PATCH 5/5] drivers/net: support hdlc function for QE-UCC

[Qiang Zhao]

On 20/04/2016 12:22AM, Christophe Leroy  wrote
> -Original Message-
> From: Christophe Leroy [mailto:christophe.le...@c-s.fr]
> Sent: Wednesday, April 20, 2016 12:22 AM
> To: Qiang Zhao ; da...@davemloft.net
> Cc: gre...@linuxfoundation.org; Xiaobo Xie ; linux-
> ker...@vger.kernel.org; o...@buserror.net; net...@vger.kernel.org;
> a...@linux-foundation.org; linuxppc-...@lists.ozlabs.org
> Subject: Re: [PATCH 5/5] drivers/net: support hdlc function for QE-UCC
> 
> Le 30/03/2016 10:50, Zhao Qiang a écrit :
> > The driver add hdlc support for Freescale QUICC Engine.
> > It support NMSI and TSA mode.
> When using TSA, how does the TSA gets configured ? Especially how do you
> describe which Timeslot is switched to HDLC channels ?

the TSA is configured statically according to device tree node. 
For " which Timeslot is switched to HDLC channels ", there is a property 
"fsl,tx-timeslot-mask" in device tree to describe it.

> Is it possible to route some Timeslots to one UCC for HDLC, and route some
> others to another UCC for an ALSA sound driver ?

The feature you describe is not supported at present.

> The QE also have a QMC which allows to split all timeslots to a given UCC into
> independant channels that can either be used with HDLC or transparents (for
> audio for instance). Do you intent to also support QMC ?

new QE use UMCC instead of QMC in old QE, we have started to develop UMCC.
 
> According to the compatible property, it looks like your driver is for 
> freescale
> T1040. The MPC83xx also has a Quick Engine, would it work on it too ?

The driver is common, but tested on t1040, it is needed to add node to MPC83xx
If you want to test on mpc83xx.

-Zhao Qiang

RE: [PATCH 5/5] drivers/net: support hdlc function for QE-UCC

[Qiang Zhao]

On 20/04/2016 12:22AM, Christophe Leroy  wrote
> -Original Message-
> From: Christophe Leroy [mailto:christophe.le...@c-s.fr]
> Sent: Wednesday, April 20, 2016 12:22 AM
> To: Qiang Zhao ; da...@davemloft.net
> Cc: gre...@linuxfoundation.org; Xiaobo Xie ; linux-
> ker...@vger.kernel.org; o...@buserror.net; net...@vger.kernel.org;
> a...@linux-foundation.org; linuxppc-...@lists.ozlabs.org
> Subject: Re: [PATCH 5/5] drivers/net: support hdlc function for QE-UCC
> 
> Le 30/03/2016 10:50, Zhao Qiang a écrit :
> > The driver add hdlc support for Freescale QUICC Engine.
> > It support NMSI and TSA mode.
> When using TSA, how does the TSA gets configured ? Especially how do you
> describe which Timeslot is switched to HDLC channels ?

the TSA is configured statically according to device tree node. 
For " which Timeslot is switched to HDLC channels ", there is a property 
"fsl,tx-timeslot-mask" in device tree to describe it.

> Is it possible to route some Timeslots to one UCC for HDLC, and route some
> others to another UCC for an ALSA sound driver ?

The feature you describe is not supported at present.

> The QE also have a QMC which allows to split all timeslots to a given UCC into
> independant channels that can either be used with HDLC or transparents (for
> audio for instance). Do you intent to also support QMC ?

new QE use UMCC instead of QMC in old QE, we have started to develop UMCC.
 
> According to the compatible property, it looks like your driver is for 
> freescale
> T1040. The MPC83xx also has a Quick Engine, would it work on it too ?

The driver is common, but tested on t1040, it is needed to add node to MPC83xx
If you want to test on mpc83xx.

-Zhao Qiang

[PATCH v3] drm/rockchip: get rid of rockchip_drm_crtc_mode_config

[Mark Yao]

We need to take care of the vop status when use
rockchip_drm_crtc_mode_config, if vop is disabled,
the function would failed, that is terrible.

Save output_type and output_mode into rockchip_crtc_state,
it's nice to make them into atomic.

Signed-off-by: Mark Yao 
---
Changes in v3:
- foget remove rockchip_drm_crtc_mode_config function in v2, remove it in v3.
 
Changes in v2:
Advised by John Keeping
- use atomic crtc state to transmit output_type and output_mode
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |   48 ---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |   38 +++-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |   17 -
 drivers/gpu/drm/rockchip/inno_hdmi.c|   17 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   10 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   75 +--
 6 files changed, 128 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index a1d94d8..50e558d 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -114,27 +114,6 @@ static void rockchip_dp_drm_encoder_enable(struct 
drm_encoder *encoder)
int ret;
u32 val;
 
-   /*
-* FIXME(Yakir): driver should configure the CRTC output video
-* mode with the display information which indicated the monitor
-* support colorimetry.
-*
-* But don't know why the CRTC driver seems could only output the
-* RGBaaa rightly. For example, if connect the "innolux,n116bge"
-* eDP screen, EDID would indicated that screen only accepted the
-* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
-* screen would show a blue picture (RGB888 show a green picture).
-* But if I configure CTRC to RGBaaa, and eDP driver still keep
-* RGB666 input video mode, then screen would works prefect.
-*/
-   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
-   DRM_MODE_CONNECTOR_eDP,
-   ROCKCHIP_OUT_MODE_);
-   if (ret < 0) {
-   dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
-   return;
-   }
-
ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
if (ret < 0)
return;
@@ -158,11 +137,38 @@ static void rockchip_dp_drm_encoder_nop(struct 
drm_encoder *encoder)
/* do nothing */
 }
 
+static int
+rockchip_dp_drm_encoder_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+   struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+
+   /*
+* FIXME(Yakir): driver should configure the CRTC output video
+* mode with the display information which indicated the monitor
+* support colorimetry.
+*
+* But don't know why the CRTC driver seems could only output the
+* RGBaaa rightly. For example, if connect the "innolux,n116bge"
+* eDP screen, EDID would indicated that screen only accepted the
+* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+* screen would show a blue picture (RGB888 show a green picture).
+* But if I configure CTRC to RGBaaa, and eDP driver still keep
+* RGB666 input video mode, then screen would works prefect.
+*/
+   s->output_mode = ROCKCHIP_OUT_MODE_;
+   s->output_type = DRM_MODE_CONNECTOR_HDMIA;
+
+   return 0;
+}
+
 static struct drm_encoder_helper_funcs rockchip_dp_encoder_helper_funcs = {
.mode_fixup = rockchip_dp_drm_encoder_mode_fixup,
.mode_set = rockchip_dp_drm_encoder_mode_set,
.enable = rockchip_dp_drm_encoder_enable,
.disable = rockchip_dp_drm_encoder_nop,
+   .atomic_check = rockchip_dp_drm_encoder_atomic_check,
 };
 
 static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 7975158..dedc65b 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -879,7 +879,6 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder 
*encoder)
 {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
-   u32 interface_pix_fmt;
u32 val;
 
if (clk_prepare_enable(dsi->pclk)) {
@@ -895,31 +894,41 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder 
*encoder)
 
clk_disable_unprepare(dsi->pclk);
 
+   if (mux)
+   val = DSI0_SEL_VOP_LIT | (DSI0_SEL_VOP_LIT << 16);
+   else
+

[PATCH v3] drm/rockchip: get rid of rockchip_drm_crtc_mode_config

[Mark Yao]

We need to take care of the vop status when use
rockchip_drm_crtc_mode_config, if vop is disabled,
the function would failed, that is terrible.

Save output_type and output_mode into rockchip_crtc_state,
it's nice to make them into atomic.

Signed-off-by: Mark Yao 
---
Changes in v3:
- foget remove rockchip_drm_crtc_mode_config function in v2, remove it in v3.
 
Changes in v2:
Advised by John Keeping
- use atomic crtc state to transmit output_type and output_mode
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |   48 ---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |   38 +++-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |   17 -
 drivers/gpu/drm/rockchip/inno_hdmi.c|   17 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   10 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   75 +--
 6 files changed, 128 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index a1d94d8..50e558d 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -114,27 +114,6 @@ static void rockchip_dp_drm_encoder_enable(struct 
drm_encoder *encoder)
int ret;
u32 val;
 
-   /*
-* FIXME(Yakir): driver should configure the CRTC output video
-* mode with the display information which indicated the monitor
-* support colorimetry.
-*
-* But don't know why the CRTC driver seems could only output the
-* RGBaaa rightly. For example, if connect the "innolux,n116bge"
-* eDP screen, EDID would indicated that screen only accepted the
-* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
-* screen would show a blue picture (RGB888 show a green picture).
-* But if I configure CTRC to RGBaaa, and eDP driver still keep
-* RGB666 input video mode, then screen would works prefect.
-*/
-   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
-   DRM_MODE_CONNECTOR_eDP,
-   ROCKCHIP_OUT_MODE_);
-   if (ret < 0) {
-   dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
-   return;
-   }
-
ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
if (ret < 0)
return;
@@ -158,11 +137,38 @@ static void rockchip_dp_drm_encoder_nop(struct 
drm_encoder *encoder)
/* do nothing */
 }
 
+static int
+rockchip_dp_drm_encoder_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+   struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+
+   /*
+* FIXME(Yakir): driver should configure the CRTC output video
+* mode with the display information which indicated the monitor
+* support colorimetry.
+*
+* But don't know why the CRTC driver seems could only output the
+* RGBaaa rightly. For example, if connect the "innolux,n116bge"
+* eDP screen, EDID would indicated that screen only accepted the
+* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+* screen would show a blue picture (RGB888 show a green picture).
+* But if I configure CTRC to RGBaaa, and eDP driver still keep
+* RGB666 input video mode, then screen would works prefect.
+*/
+   s->output_mode = ROCKCHIP_OUT_MODE_;
+   s->output_type = DRM_MODE_CONNECTOR_HDMIA;
+
+   return 0;
+}
+
 static struct drm_encoder_helper_funcs rockchip_dp_encoder_helper_funcs = {
.mode_fixup = rockchip_dp_drm_encoder_mode_fixup,
.mode_set = rockchip_dp_drm_encoder_mode_set,
.enable = rockchip_dp_drm_encoder_enable,
.disable = rockchip_dp_drm_encoder_nop,
+   .atomic_check = rockchip_dp_drm_encoder_atomic_check,
 };
 
 static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 7975158..dedc65b 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -879,7 +879,6 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder 
*encoder)
 {
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
-   u32 interface_pix_fmt;
u32 val;
 
if (clk_prepare_enable(dsi->pclk)) {
@@ -895,31 +894,41 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder 
*encoder)
 
clk_disable_unprepare(dsi->pclk);
 
+   if (mux)
+   val = DSI0_SEL_VOP_LIT | (DSI0_SEL_VOP_LIT << 16);
+   else
+   val =