date:20140430

On Tue, Apr 22, 2014 at 12:47:29PM +0200, Geert Uytterhoeven wrote:
> drivers/base/regmap/regmap.c: In function 
> ‘_regmap_range_multi_paged_reg_write’:
> drivers/base/regmap/regmap.c:1665: warning: ‘this_page’ may be used 
> uninitialized in this function
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> This may be a false positive, if "range" is guaranteed to be non-zero
> during the first iteration of the loop

Applied, though with this sort of thing it's generally a bit better to
do the init at the start of the loop rather than at declaration - init
at declaration is a common pattern for just shutting up warnings as
opposed to analyisng to make sure that there's really not an issue.

signature.asc
Description: Digital signature

Re: [PATCH] w1: do not unlock unheld list_mutex in __w1_remove_master_device()

2014-04-30 Thread David Fries

On Thu, May 01, 2014 at 12:37:58AM +0400, Alexey Khoroshilov wrote:
> w1_process_callbacks() expects to be called with dev->list_mutex held,
> but it is the fact only in w1_process(). __w1_remove_master_device()
> calls w1_process_callbacks() after it releases list_mutex.
> 
> The patch fixes __w1_remove_master_device() to acquire list_mutex
> for w1_process_callbacks(). It is implemented by moving
> w1_process_callbacks() functionality to __w1_process_callbacks()
> and adding a wrapper with the old name.

Good catch.  I guess as it was in the shutdown path it failed the
unlock silently.

I would prefer a different fix.  If w1_process_callbacks was more of a
public facing API called from multiple locations where the caller
doesn't have access to the locks, something like this would probably
be the way to go.  This is called from two areas of the code, and not
likely to be called from any new areas in the future.

Adding a documentation comment is good.  I would be tempted in
__w1_remove_master_device to move the dev->list_mutex down after the
while loop, but I can't be sure that whatever has a refcnt wouldn't
need list_mutex.  The last w1_process_callbacks after the while loop
shouldn't be needed I wouldn't think, I was just being defensive.  By
the time it completes the while loop the reference count is 0 so there
shouldn't be anything left for it to process and if there is, it's a
race condition and game over anyway.  So just sandwich
w1_process_callbacks with the lock/unlock in
__w1_remove_master_device please.

> Found by Linux Driver Verification project (linuxtesting.org).

Was this found with code inspection or hardware testing with lock
debugging enabled?

> Signed-off-by: Alexey Khoroshilov 
> ---
>  drivers/w1/w1.c |  8 +---
>  drivers/w1/w1.h | 13 -
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
> index ff52618cafbe..e507c51512aa 100644
> --- a/drivers/w1/w1.c
> +++ b/drivers/w1/w1.c
> @@ -1075,12 +1075,14 @@ static void w1_search_process(struct w1_master *dev, 
> u8 search_type)
>  }
>  
>  /**
> - * w1_process_callbacks() - execute each dev->async_list callback entry
> + * __w1_process_callbacks() - execute each dev->async_list callback entry
>   * @dev: w1_master device
>   *
> + * The w1 master list_mutex must be held.
> + *
>   * Return: 1 if there were commands to executed 0 otherwise
>   */
> -int w1_process_callbacks(struct w1_master *dev)
> +int __w1_process_callbacks(struct w1_master *dev)
>  {
>   int ret = 0;
>   struct w1_async_cmd *async_cmd, *async_n;
> @@ -1122,7 +1124,7 @@ int w1_process(void *data)
>   /* Note, w1_process_callback drops the lock while processing,
>* but locks it again before returning.
>*/
> - if (!w1_process_callbacks(dev) && jremain) {
> + if (!__w1_process_callbacks(dev) && jremain) {
>   /* a wake up is either to stop the thread, process
>* callbacks, or search, it isn't process callbacks, so
>* schedule a search.
> diff --git a/drivers/w1/w1.h b/drivers/w1/w1.h
> index 734dab7fc687..e357321a5e13 100644
> --- a/drivers/w1/w1.h
> +++ b/drivers/w1/w1.h
> @@ -341,9 +341,20 @@ extern int w1_max_slave_ttl;
>  extern struct list_head w1_masters;
>  extern struct mutex w1_mlock;
>  
> -extern int w1_process_callbacks(struct w1_master *dev);
> +extern int __w1_process_callbacks(struct w1_master *dev);
>  extern int w1_process(void *);
>  
> +static inline int w1_process_callbacks(struct w1_master *dev)
> +{
> + int ret;
> +
> + mutex_lock(>list_mutex);
> + ret = __w1_process_callbacks(dev);
> + mutex_unlock(>list_mutex);
> + return ret;
> +}
> +
> +
>  #endif /* __KERNEL__ */
>  
>  #endif /* __W1_H */
> -- 
> 1.8.3.2
> 
> --
> 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/

-- 
David Fries PGP pub CB1EE8F0
http://fries.net/~david/
--
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: [PATCHv3 0/2] add DT endianness binding support

2014-04-30 Thread Richard Cochran

On Wed, Apr 30, 2014 at 11:25:00AM -0700, Mark Brown wrote:
> On Wed, Apr 30, 2014 at 09:10:12AM +0200, Richard Cochran wrote:
> > Shouldn't this go to the arm list and rmk for review, too?
> 
> Is there any particular reason for including rmk?  It's generally not
> helpful to spam people with serieses without reason, we all get quite a
> lot of mail already...

I recall seeing him writing at length about cpu/peripheral endianness
issues, so I assume he has some expertise here. It would be a shame if
a new DT feature were overlooking something important.

Thanks,
Richard
--
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 v3 11/12] ARM: EXYNOS: Add platform driver support for Exynos PMU.

2014-04-30 Thread Pankaj Dubey


On 04/30/2014 03:05 PM, Vikas Sajjan wrote:

Hi Pankaj,

On Wed, Apr 30, 2014 at 10:47 AM, Pankaj Dubey  wrote:

This patch modifies Exynos Power Management Unit (PMU) initialization
implementation in following way:

- Added platform_device support by registering static platform device.
- Added platform struct exynos_pmu_data to hold platform specific data.
- For each SoC's PMU support now we can add platform data and statically
   bind PMU configuration and SoC specific initialization function.
- Probe function will scan DT and based on matching PMU compatibility
   string initialize pmu_context which will be platform_data for driver.
- Obtain PMU regmap handle using "syscon_regmap_lookup_by_phandle" so
   that we can reduce dependency over machine header files.
- Separate each SoC's PMU initialization function and make it as part of
   platform data.
- It also removes uses of soc_is_exynos() thus making PMU implementation
   independent of "plat/cpu.h".

Signed-off-by: Pankaj Dubey 
Signed-off-by: Young-Gun Jang 
---
  arch/arm/mach-exynos/pmu.c |  280 +++-
  1 file changed, 224 insertions(+), 56 deletions(-)

diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 67116a5..030df96 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd.
   * http://www.samsung.com/
   *
   * EXYNOS - CPU PMU(Power Management Unit) support
@@ -9,20 +9,33 @@
   * published by the Free Software Foundation.
   */

-#include 
-#include 
+#include 
  #include 
-
-#include 
+#include 
+#include 
+#include 
+#include 

  #include "common.h"
  #include "regs-pmu.h"

-static const struct exynos_pmu_conf *exynos_pmu_config;
-static struct regmap *pmu_regmap;
+struct exynos_pmu_data {
+   const struct exynos_pmu_conf *pmu_config;
+   const struct exynos_pmu_conf *pmu_config_extra;
+   void (*pmu_init)(void);
+   void (*powerdown_conf)(enum sys_powerdown);
+};
+
+struct exynos_pmu_context {
+   struct device *dev;
+   struct exynos_pmu_data *pmu_data;
+   struct regmap   *pmu_regmap;
+};
+
+static struct exynos_pmu_context   *pmu_context;

  static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
-   /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
+   /* { .offset = address, .val = { AFTR, LPA, SLEEP } */
 { S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
 { S5P_DIS_IRQ_CORE0,{ 0x0, 0x0, 0x0 } },
 { S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
@@ -216,7 +229,7 @@ static const struct exynos_pmu_conf exynos4412_pmu_config[] 
= {
  };

  static const struct exynos_pmu_conf exynos5250_pmu_config[] = {
-   /* { .reg = address, .val = { AFTR, LPA, SLEEP } */
+   /* { .offset = address, .val = { AFTR, LPA, SLEEP } */
 { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
 { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
 { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
@@ -339,7 +352,7 @@ static unsigned int const exynos5_list_diable_wfi_wfe[] = {
 EXYNOS5_ISP_ARM_OPTION,
  };

-static void exynos5_init_pmu(void)
+void exynos5_powerdown_conf(enum sys_powerdown mode)
  {
 unsigned int i;
 unsigned int tmp;
@@ -348,81 +361,236 @@ static void exynos5_init_pmu(void)
  * Enable both SC_FEEDBACK and SC_COUNTER
  */
 for (i = 0 ; i < ARRAY_SIZE(exynos5_list_both_cnt_feed) ; i++) {
-   regmap_read(pmu_regmap, exynos5_list_both_cnt_feed[i], );
+   regmap_read(pmu_context->pmu_regmap,
+   exynos5_list_both_cnt_feed[i], );
 tmp |= (EXYNOS5_USE_SC_FEEDBACK |
 EXYNOS5_USE_SC_COUNTER);
-   regmap_write(pmu_regmap, exynos5_list_both_cnt_feed[i], tmp);
+   regmap_write(pmu_context->pmu_regmap,
+   exynos5_list_both_cnt_feed[i], tmp);
 }

 /*
  * SKIP_DEACTIVATE_ACEACP_IN_PWDN_BITFIELD Enable
  */
-   regmap_read(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, );
+   regmap_read(pmu_context->pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, );
 tmp |= EXYNOS5_SKIP_DEACTIVATE_ACEACP_IN_PWDN;
-   regmap_write(pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);
+   regmap_write(pmu_context->pmu_regmap, EXYNOS5_ARM_COMMON_OPTION, tmp);

 /*
  * Disable WFI/WFE on XXX_OPTION
  */
 for (i = 0 ; i < ARRAY_SIZE(exynos5_list_diable_wfi_wfe) ; i++) {
-   tmp = regmap_read(pmu_regmap, exynos5_list_diable_wfi_wfe[i],
-   );
+   tmp = regmap_read(pmu_context->pmu_regmap,
+   exynos5_list_diable_wfi_wfe[i],

Re: [PATCH] regmap: Fix possible ZERO_SIZE_PTR pointer dereferencing error.

On Wed, Apr 30, 2014 at 05:31:08PM +0800, Xiubo Li wrote:
> Since we cannot make sure the 'len = pair_size * num_regs' will always
> be none zero from the users, and then if 'num_regs' equals to zero by
> mistake or other reasons, the kzalloc() will return ZERO_SIZE_PTR, which
> equals to ((void *)16).

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH 05/15] ASoC: nuc900: export nuc900_ac97_data

On Tue, Apr 29, 2014 at 07:18:26PM +0800, Xia Kaixu wrote:
> From: Arnd Bergmann 
> 
> The symbol "nuc900_ac97_data" is used by the nuc900_pcm driver, 
> which may be a loadable module, so we should export it.

Applied, thanks.


signature.asc
Description: Digital signature

[PATCH] aio: fix potential leak in aio_run_iocb().

2014-04-30 Thread Leon Yu

iovec should be reclaimed whenever caller of rw_copy_check_uvector() returns,
but it doesn't hold when failure happens right after aio_setup_vectored_rw().

Fix that in a such way to avoid hairy goto.

Signed-off-by: Leon Yu 
---
 fs/aio.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 12a3de0e..04cd768 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1299,10 +1299,8 @@ rw_common:
, compat)
: aio_setup_single_vector(req, rw, buf, _segs,
  iovec);
-   if (ret)
-   return ret;
-
-   ret = rw_verify_area(rw, file, >ki_pos, req->ki_nbytes);
+   if (!ret)
+   ret = rw_verify_area(rw, file, >ki_pos, 
req->ki_nbytes);
if (ret < 0) {
if (iovec != _vec)
kfree(iovec);
-- 
1.9.2

--
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 04/15] ASoC: samsung-idma: avoid 64-bit division

On Tue, Apr 29, 2014 at 07:18:25PM +0800, Xia Kaixu wrote:
> From: Arnd Bergmann 
> 
> dma_addr_t may be 64 bit wide, which causes a build failure
> when doing a division on it. Here it is safe to cast to an
> u32 type, which avoids the problem.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH 6/6 v2] staging: comedi: addi_apci_1564: remove use of devpriv->s_EeParameters

2014-04-30 Thread Chase Southwood

Hartley,

Yes, you raise very good points.  In any case, I have added cover
letters to my submitting checklist so hopefully everything will be a
lot easier for everyone next go round.

Thanks,
Chase

On Wed, Apr 30, 2014 at 11:58 AM, Hartley Sweeten
 wrote:
> On Wednesday, April 30, 2014 12:52 AM, Chase Southwood wrote:
>> Thanks so much, I greatly appreciate the review.  I'll fix the
>> changelog for patch 4 and send once more (as I assume that's easier
>> for Greg).  Also, I should know better about the cover letter as
>> well...I was once told not to send them for strictly cleanup patchsets
>> (as Greg can't do anything with them and cleanups should be obvious)
>> but I've gotten in the habit of not doing a cover letter for any
>> patchsets.  I will send cover letters (and be more careful about my
>> other mistakes) in the future.
>
> Chase,
>
> Good job on the cleanup you have done so far.
>
> The cover letter does not get committed as part of the patch set. But
> when you are submitting a series it give a convenient  place to add
> the sign off tag for a series. Also, if you would have done a cover letter
> for this series you would have probably spotted the subject line issues
> in patches 5 and 6.
>
> Keep up the good work!
>
> Hartley
>
--
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 03/15] ASoC: SMDK_WM8580_PCM needs REGMAP_I2C

On Tue, Apr 29, 2014 at 07:18:24PM +0800, Xia Kaixu wrote:
> From: Arnd Bergmann 
> 
> This adds a missing dependency for SND_SOC_SMDK_WM8580_PCM to
> require REGMAP_I2C to be enabled, avoiding possible build
> erorrs.

Applied, thanks.  As well as the Cc list thing please try to use subject
lines matching the style for the subsystem.

signature.asc
Description: Digital signature

Re: [PATCH 02/15] ASoC: davinci: add dependencies for SND_SOC_TLV320AIC3X

On Tue, Apr 29, 2014 at 07:18:23PM +0800, Xia Kaixu wrote:
> From: Arnd Bergmann 
> 
> This codec requires I2C to be enabled, so any other option
> that selects it should also depend on I2C.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [alsa-devel] [PATCH 01/15] ASoC: CS42L51 and WM8962 codecs depend on INPUT

On Thu, May 01, 2014 at 02:16:27AM +, Austin, Brian wrote:

> Apparently not.
> I would like to come up with a better solution than making INPUT a 
> requirement. I just need some time.
> In the meantime I suppose it’s OK to apply it? 

Yeah.  Realistically it's probably not going to ever be a practical
problem - the number of systems with audio but no input is likely to be
very close to zero.

signature.asc
Description: Digital signature

[PATCH] splice: fix possible memory leak in vmsplice_to_user().

2014-04-30 Thread Leon Yu

Since commit 6130f5315 ("switch vmsplice_to_user() to copy_page_to_iter()"),
rw_copy_check_uvector is used for sanity check, however, iov can be leaked if
that check failed.

So, fix it by handling this error path properly.

Signed-off-by: Leon Yu 
---
 fs/splice.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/splice.c b/fs/splice.c
index 9bc07d2..b789328 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1546,7 +1546,7 @@ static long vmsplice_to_user(struct file *file, const 
struct iovec __user *uiov,
ret = rw_copy_check_uvector(READ, uiov, nr_segs,
ARRAY_SIZE(iovstack), iovstack, );
if (ret <= 0)
-   return ret;
+   goto out;
 
iov_iter_init(, iov, nr_segs, count, 0);
 
@@ -1560,6 +1560,7 @@ static long vmsplice_to_user(struct file *file, const 
struct iovec __user *uiov,
ret = __splice_from_pipe(pipe, , pipe_to_user);
pipe_unlock(pipe);
 
+out:
if (iov != iovstack)
kfree(iov);
 
-- 
1.9.2

--
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/

[PATCH v3] rwsem: Support optimistic spinning

2014-04-30 Thread Davidlohr Bueso

We have reached the point where our mutexes are quite fine tuned
for a number of situations. This includes the use of heuristics
and optimistic spinning, based on MCS locking techniques.

Exclusive ownership of read-write semaphores are, conceptually,
just about the same as mutexes, making them close cousins. To
this end we need to make them both perform similarly, and
right now, rwsems are simply not up to it. This was discovered
by both reverting commit 4fc3f1d6 (mm/rmap, migration: Make
rmap_walk_anon() and try_to_unmap_anon() more scalable) and
similarly, converting some other mutexes (ie: i_mmap_mutex) to
rwsems. This creates a situation where users have to choose
between a rwsem and mutex taking into account this important
performance difference. Specifically, biggest difference between
both locks is when we fail to acquire a mutex in the fastpath,
optimistic spinning comes in to play and we can avoid a large
amount of unnecessary sleeping and overhead of moving tasks in
and out of wait queue. Rwsems do not have such logic.

This patch, based on the work from Tim Chen and I, adds support
for write-side optimistic spinning when the lock is contended.
It also includes support for the recently added cancelable MCS
locking for adaptive spinning. Note that is is only applicable
to the xadd method, and the spinlock rwsem variant remains intact.

Allowing optimistic spinning before putting the writer on the wait
queue reduces wait queue contention and provided greater chance
for the rwsem to get acquired. With these changes, rwsem is on par
with mutex. The performance benefits can be seen on a number of
workloads. For instance, on a 8 socket, 80 core 64bit Westmere box,
aim7 shows the following improvements in throughput:

+--+-+-+
|   Workload   | throughput-increase | number of users |
+--+-+-+
| alltests | 20% | >1000   |
| custom   | 27%, 60%| 10-100, >1000   |
| high_systime | 36%, 30%| >100, >1000 |
| shared   | 58%, 29%| 10-100, >1000   |
+--+-+-+

There was also improvement on smaller systems, such as a quad-core
x86-64 laptop running a 30Gb PostgreSQL (pgbench) workload for up
to +60% in throughput for over 50 clients. Additionally, benefits
were also noticed in exim (mail server) workloads. Furthermore, no
performance regression have been seen at all.

Signed-off-by: Davidlohr Bueso 
Signed-off-by: Tim Chen 
---
Changes from v2 (https://lkml.org/lkml/2014/4/28/610):
 - Documented owner entry in struct rw_semaphore.

 - For rwsem_down_write_failed(): Use set_current_state() family 
   instead of through a tsk variable. Also cleanup. The 'waiting'
   boolean was kept as we do endup having to check the list_empty
   later on, and since we endup adding a new element to the list,
   it is much simpler and straightforward to keep it around calling
   __rwsem_do_wake().

 - Rewrote rwsem_can_spin_on_owner(), including checking for
   need_resched().
   
 - Cleaned up rwsem_try_write_lock_unqueued().

 - Added more comments.

 - Did more testing, so far no regressions or issues.

Changes from v1 (http://www.spinics.net/lists/kernel/msg1727764.html):
 - Explicitly mention in the changelog that this works only for xadd rwsem 
method.
 - Make clear/set owner functions depend on CONFIG_SMP and 
CONFIG_RWSEM_XCHGADD_ALGORITHM
 - Make sure we clear the owner before releasing the write lock.

 include/linux/rwsem.h   |  25 -
 kernel/locking/rwsem-xadd.c | 224 ++--
 kernel/locking/rwsem.c  |  31 +-
 3 files changed, 245 insertions(+), 35 deletions(-)

diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 03f3b05..3e108f1 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -16,6 +16,7 @@
 
 #include 
 
+struct optimistic_spin_queue;
 struct rw_semaphore;
 
 #ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
@@ -23,9 +24,17 @@ struct rw_semaphore;
 #else
 /* All arch specific implementations share the same struct */
 struct rw_semaphore {
-   longcount;
-   raw_spinlock_t  wait_lock;
-   struct list_headwait_list;
+   long count;
+   raw_spinlock_t wait_lock;
+   struct list_head wait_list;
+#ifdef CONFIG_SMP
+   /*
+* Write owner. Used as a speculative check to see
+* if the owner is running on the cpu.
+*/
+   struct task_struct *owner;
+   struct optimistic_spin_queue *osq; /* spinner MCS lock */
+#endif
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map  dep_map;
 #endif
@@ -55,11 +64,21 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
 # define __RWSEM_DEP_MAP_INIT(lockname)
 #endif
 
+#ifdef CONFIG_SMP
+#define __RWSEM_INITIALIZER(name)  \
+   { RWSEM_UNLOCKED_VALUE,

Re: dcache shrink list corruption?

2014-04-30 Thread Al Viro

On Wed, Apr 30, 2014 at 07:59:43PM -0700, Linus Torvalds wrote:
> On Wed, Apr 30, 2014 at 7:51 PM, Al Viro  wrote:
> >
> >   Help with profiling is needed; the loads to watch are
> > the ones where dentry_kill() + dentry_free() are sufficiently high in 
> > profiles
> > for the differences to matter.  Any takers?
> 
> I really hope there are no such loads, my "lock/unlock pairing"
> suggestion was mostly so that the pairing is clearer, not necessarily
> for performance.
> 
> That said, I'd assume that it migth be worth testing at least the
> "lots of concurrent lookups of 'simple_dentry_operations' dentries".
> So most of /proc, most uses of simple_lookup(). That at least triggers
> the dentry_kill() path in dput(), so it should be fairly easy to get
> profiles.
> 
> But real loads with real filesystems? That sounds harder.

Well, the simplest way to do that is a bunch of open/unlink/close.  Another
one is cp -rl / rm -rf of a large tree (rmdir(2) does shrink_dcache_parent()). 
For that matter, unmapping an anon shared mapping will trigger the same path.
--
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: dcache shrink list corruption?

2014-04-30 Thread Linus Torvalds

On Wed, Apr 30, 2014 at 7:51 PM, Al Viro  wrote:
>
>   Help with profiling is needed; the loads to watch are
> the ones where dentry_kill() + dentry_free() are sufficiently high in profiles
> for the differences to matter.  Any takers?

I really hope there are no such loads, my "lock/unlock pairing"
suggestion was mostly so that the pairing is clearer, not necessarily
for performance.

That said, I'd assume that it migth be worth testing at least the
"lots of concurrent lookups of 'simple_dentry_operations' dentries".
So most of /proc, most uses of simple_lookup(). That at least triggers
the dentry_kill() path in dput(), so it should be fairly easy to get
profiles.

But real loads with real filesystems? That sounds harder.

  Linus
--
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: dcache shrink list corruption?

2014-04-30 Thread Al Viro

On Wed, Apr 30, 2014 at 05:18:23PM -0700, Linus Torvalds wrote:

> and then suddenly it looks like we have a common exit sequence from
> that dentry_kill() function, no?
> 
> (The earlier "unlock_on_failure" exit case is altogether a different case).
> 
> I dunno. Maybe not a big deal, but one reason I prefer doing that
> "free" flag is because I really tend to prefer the simple case of
> lock-unlock pairing cleanly at the same level. NOT the pattern where
> you have one lock at one indentation level, paired with multiple
> unlocks for all the different cases.

Yeah, but... I have such variant, but the best I could get still generated
the code that wasn't particulary nice.  Part might be gcc code generation
sucking for bool, part - extra register pressure...  It has slightly lower
i-cache footprint, though, so it might be worth doing.  Hell knows; that's a
fairly hot codepath, so let's do it that way - I've just pushed an alternative
branch with bool can_free variant; branches in question: vfs.git#for-linus and
vfs.git#dentry_kill-2. Help with profiling is needed; the loads to watch are
the ones where dentry_kill() + dentry_free() are sufficiently high in profiles
for the differences to matter.  Any takers?
--
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/

[PATCH] SCHED: allow wait_on_bit_action functions to support a timeout.

2014-04-30 Thread NeilBrown


[[ This patch depends on the previously posted:
[PATCH] SCHED: remove proliferation of wait_on_bit action functions.

   This version is much smaller then the previous and better tested.

   I'm hoping it too will go though the scheduler tree and the the
   NFS changes won't cause too many conflicts...

]]

It is currently not possible for various wait_on_bit functions to
implement a timeout.
While the "action" function that is called to do the waiting could
certainly use schedule_timeout(), there is no way to carry forward the
remaining timeout after a false wake-up.
As false-wakeups a clearly possible at least due to possible
hash collisions in bit_waitqueue(), this is a real problem.

The 'action' function is currently passed a pointer to the word
containing the bit being waited on.  No current action functions use
this pointer.  So changing it to something else will be a little noisy
but will have no immediate effect.

This patch changes the 'action' function to take a pointer to the
"struct wait_bit_key", which contains a pointer to the word
containing the bit so nothing is really lost.

It also adds a 'private' field to "struct wait_bit_key", which is
initialized to zero.

An action function can now implement a timeout with something like

static int timed_out_waiter(struct wait_bit_key *key)
{
unsigned long waited;
if (key->private == 0) {
key->private = jiffies;
if (key->private == 0)
key->private -= 1;
}
waited = jiffies - key->private;
if (waited > 10 * HZ)
return -EAGAIN;
schedule_timeout(waited - 10 * HZ);
return 0;
}

If any other need for context in a waiter were found it would be easy
to use ->private for some other purpose, or even extend "struct
wait_bit_key".

My particular need is to support timeouts in nfs_release_page() to
avoid deadlocks with loopback mounted NFS.

While wait_on_bit_timeout() would be a cleaner interface, it will not
meet my need.  I need the timeout to be sensitive to the state of
the connection with the server, which could change.  So I need to
use an 'action' interface.

Signed-off-by: NeilBrown 

diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index cd6e656d839e..5c19408c8345 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -75,7 +75,7 @@ nfs_fattr_to_ino_t(struct nfs_fattr *fattr)
  * nfs_wait_bit_killable - helper for functions that are sleeping on bit locks
  * @word: long word containing the bit lock
  */
-int nfs_wait_bit_killable(void *word)
+int nfs_wait_bit_killable(struct wait_bit_key *key)
 {
if (fatal_signal_pending(current))
return -ERESTARTSYS;
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index dd8bfc2e2464..9bafea8ecc54 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -342,7 +342,7 @@ extern int nfs_drop_inode(struct inode *);
 extern void nfs_clear_inode(struct inode *);
 extern void nfs_evict_inode(struct inode *);
 void nfs_zap_acl_cache(struct inode *inode);
-extern int nfs_wait_bit_killable(void *word);
+extern int nfs_wait_bit_killable(struct wait_bit_key *key);
 
 /* super.c */
 extern const struct super_operations nfs_sops;
diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c
index f369a74f2b31..3f7c25736659 100644
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -112,7 +112,7 @@ __nfs_iocounter_wait(struct nfs_io_counter *c)
set_bit(NFS_IO_INPROGRESS, >flags);
if (atomic_read(>io_count) == 0)
break;
-   ret = nfs_wait_bit_killable(>flags);
+   ret = nfs_wait_bit_killable();
} while (atomic_read(>io_count) != 0);
finish_wait(wq, );
return ret;
diff --git a/include/linux/sunrpc/sched.h b/include/linux/sunrpc/sched.h
index 3a847de83fab..592be588ce62 100644
--- a/include/linux/sunrpc/sched.h
+++ b/include/linux/sunrpc/sched.h
@@ -236,7 +236,7 @@ void *  rpc_malloc(struct rpc_task *, size_t);
 void   rpc_free(void *);
 intrpciod_up(void);
 void   rpciod_down(void);
-int__rpc_wait_for_completion_task(struct rpc_task *task, int 
(*)(void *));
+int__rpc_wait_for_completion_task(struct rpc_task *task, int 
(*)(struct wait_bit_key *));
 #ifdef RPC_DEBUG
 struct net;
 void   rpc_show_tasks(struct net *);
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 438dc6044587..162cbcde9dae 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -25,6 +25,7 @@ struct wait_bit_key {
void*flags;
int bit_nr;
 #define WAIT_ATOMIC_T_BIT_NR   -1
+   unsigned long   private;
 };
 
 struct wait_bit_queue {
@@ -147,12 +148,12 @@ void __wake_up_sync_key(wait_queue_head_t *q, unsigned 
int mode, int nr, void *k
 void __wake_up_locked(wait_queue_head_t *q, unsigned int mode, int nr);
 void __wake_up_sync(wait_queue_head_t *q, unsigned int mode,

[PATCH] SCHED: remove proliferation of wait_on_bit action functions.

2014-04-30 Thread NeilBrown


[[ get_maintainer.pl suggested 61 email address for this patch.
   I've trimmed that list somewhat.  Hope I didn't miss anyone
   important...
   I'm hoping it will go in through the scheduler tree, but would
   particularly like an Acked-by for the fscache parts.  Other acks
   welcome.
]]

The current "wait_on_bit" interface requires an 'action' function
to be provided which does the actual waiting.
There are over 20 such functions, many of them identical.
Most cases can be satisfied by one of just two functions, one
which uses io_schedule() and one which just uses schedule().

So:
 Rename wait_on_bit andwait_on_bit_lock to
wait_on_bit_action and wait_on_bit_lock_action
 to make it explicit that they need an action function.

 Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
 which are *not* given an action function but implicitly use
 a standard one.
 The decision to error-out if a signal is pending is now made
 based on the 'mode' argument rather than being encoded in the action
 function.


 All instances of the old wait_on_bit and wait_on_bit_lock which
 can use the new version have been changed accordingly and their
 action functions have been discarded.
 wait_on_bit{_lock} does not return any specific error code in the
 event of a signal so the caller must check for non-zero and
 interpolate their own error code as appropriate.

The wait_on_bit() call in __fscache_wait_on_invalidate() was ambiguous
as it specified TASK_UNINTERRUPTIBLE but used
fscache_wait_bit_interruptible as an action function.
As any error return is never checked I assumed that 'uninterruptible'
was correct.

The main remaining user of wait_on_bit{,_lock}_action is NFS which
needs to use a freezer-aware schedule() call.

A comment in fs/gfs2/glock.c notes that having multiple 'action'
functions is useful as they display differently in the 'wchan' field
of 'ps'. (and /proc/$PID/wchan).
As the new bit_wait{,_io} functions are tagged "__sched", they will
not show up at all, but something higher in the stack.  So the
distinction will still be visible, only with different function names
(gds2_glock_wait versus gfs2_glock_dq_wait in the gfs2/glock.c case).


Signed-off-by: NeilBrown 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: David Howells  (fscache)
Cc: Steven Whitehouse  (gfs2)

diff --git a/Documentation/filesystems/caching/operations.txt 
b/Documentation/filesystems/caching/operations.txt
index bee2a5f93d60..a1c052cbba35 100644
--- a/Documentation/filesystems/caching/operations.txt
+++ b/Documentation/filesystems/caching/operations.txt
@@ -90,7 +90,7 @@ operations:
  to be cleared before proceeding:
 
wait_on_bit(>flags, FSCACHE_OP_WAITING,
-   fscache_wait_bit, TASK_UNINTERRUPTIBLE);
+   TASK_UNINTERRUPTIBLE);
 
 
  (2) The operation may be fast asynchronous (FSCACHE_OP_FAST), in which case it
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index 66c5d130c8c2..c6b692dd3b88 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -615,16 +615,6 @@ static void write_endio(struct bio *bio, int error)
 }
 
 /*
- * This function is called when wait_on_bit is actually waiting.
- */
-static int do_io_schedule(void *word)
-{
-   io_schedule();
-
-   return 0;
-}
-
-/*
  * Initiate a write on a dirty buffer, but don't wait for it.
  *
  * - If the buffer is not dirty, exit.
@@ -640,8 +630,8 @@ static void __write_dirty_buffer(struct dm_buffer *b,
return;
 
clear_bit(B_DIRTY, >state);
-   wait_on_bit_lock(>state, B_WRITING,
-do_io_schedule, TASK_UNINTERRUPTIBLE);
+   wait_on_bit_lock_io(>state, B_WRITING,
+   TASK_UNINTERRUPTIBLE);
 
if (!write_list)
submit_io(b, WRITE, b->block, write_endio);
@@ -675,9 +665,9 @@ static void __make_buffer_clean(struct dm_buffer *b)
if (!b->state)  /* fast case */
return;
 
-   wait_on_bit(>state, B_READING, do_io_schedule, TASK_UNINTERRUPTIBLE);
+   wait_on_bit_io(>state, B_READING, TASK_UNINTERRUPTIBLE);
__write_dirty_buffer(b, NULL);
-   wait_on_bit(>state, B_WRITING, do_io_schedule, TASK_UNINTERRUPTIBLE);
+   wait_on_bit_io(>state, B_WRITING, TASK_UNINTERRUPTIBLE);
 }
 
 /*
@@ -1030,7 +1020,7 @@ static void *new_read(struct dm_bufio_client *c, sector_t 
block,
if (need_submit)
submit_io(b, READ, b->block, read_endio);
 
-   wait_on_bit(>state, B_READING, do_io_schedule, TASK_UNINTERRUPTIBLE);
+   wait_on_bit_io(>state, B_READING, TASK_UNINTERRUPTIBLE);
 
if (b->read_error) {
int error = b->read_error;
@@ -1209,15 +1199,13 @@ again:
dropped_lock = 1;
b->hold_count++;
dm_bufio_unlock(c);
-   wait_on_bit(>state, B_WRITING,
-

[PATCH v5 6/6] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

This patch adds 4 levels of translation tables implementation for both
HYP and stage2.

Both symmetric and asymmetric configurations for page size and translation
levels are are validated on Fast Models:

 1) 4KB  + 3 levels guest on 4KB  + 3 levels host

 2) 4KB  + 4 levels guest on 4KB  + 3 levels host

 3) 64KB + 2 levels guest on 4KB  + 3 levels host

 4) 4KB  + 3 levels guest on 4KB  + 4 levels host

 5) 4KB  + 4 levels guest on 4KB  + 4 levels host

 6) 64KB + 2 levels guest on 4KB  + 4 levels host

 7) 4KB  + 3 levels guest on 64KB + 2 levels host

 8) 4KB  + 4 levels guest on 64KB + 2 levels host

 9) 64KB + 2 levels guest on 64KB + 2 levels host

Cc: Marc Zyngier 
Cc: Christoffer Dall 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm/include/asm/kvm_mmu.h   |   10 +
 arch/arm/kvm/mmu.c   |   88 +-
 arch/arm64/include/asm/kvm_arm.h |   34 ---
 arch/arm64/include/asm/kvm_mmu.h |   12 ++
 4 files changed, 127 insertions(+), 17 deletions(-)

diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 5c7aa3c..31eaaa6 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -37,6 +37,11 @@
  */
 #define TRAMPOLINE_VA  UL(CONFIG_VECTORS_BASE)
 
+/*
+ * MMU_CACHE_MIN_PAGES is the number of stage2 page table translation levels.
+ */
+#define MMU_CACHE_MIN_PAGES2
+
 #ifndef __ASSEMBLY__
 
 #include 
@@ -94,6 +99,11 @@ static inline void kvm_clean_pgd(pgd_t *pgd)
clean_dcache_area(pgd, PTRS_PER_S2_PGD * sizeof(pgd_t));
 }
 
+static inline void kvm_clean_pmd(pmd_t *pmd)
+{
+   clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t));
+}
+
 static inline void kvm_clean_pmd_entry(pmd_t *pmd)
 {
clean_pmd_entry(pmd);
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 80bb1e6..3ffbdfb 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -388,13 +388,44 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned 
long start,
return 0;
 }
 
+static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
+  unsigned long end, unsigned long pfn,
+  pgprot_t prot)
+{
+   pud_t *pud;
+   pmd_t *pmd;
+   unsigned long addr, next;
+
+   addr = start;
+   do {
+   pud = pud_offset(pgd, addr);
+
+   if (pud_none_or_clear_bad(pud)) {
+   pmd = pmd_alloc_one(NULL, addr);
+   if (!pmd) {
+   kvm_err("Cannot allocate Hyp pmd\n");
+   return -ENOMEM;
+   }
+   pud_populate(NULL, pud, pmd);
+   get_page(virt_to_page(pud));
+   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+   }
+
+   next = pud_addr_end(addr, end);
+
+   create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+   pfn += (next - addr) >> PAGE_SHIFT;
+   } while (addr = next, addr != end);
+
+   return 0;
+}
+
 static int __create_hyp_mappings(pgd_t *pgdp,
 unsigned long start, unsigned long end,
 unsigned long pfn, pgprot_t prot)
 {
pgd_t *pgd;
pud_t *pud;
-   pmd_t *pmd;
unsigned long addr, next;
int err = 0;
 
@@ -403,22 +434,23 @@ static int __create_hyp_mappings(pgd_t *pgdp,
end = PAGE_ALIGN(end);
do {
pgd = pgdp + pgd_index(addr);
-   pud = pud_offset(pgd, addr);
 
-   if (pud_none_or_clear_bad(pud)) {
-   pmd = pmd_alloc_one(NULL, addr);
-   if (!pmd) {
-   kvm_err("Cannot allocate Hyp pmd\n");
+   if (pgd_none(*pgd)) {
+   pud = pud_alloc_one(NULL, addr);
+   if (!pud) {
+   kvm_err("Cannot allocate Hyp pud\n");
err = -ENOMEM;
goto out;
}
-   pud_populate(NULL, pud, pmd);
-   get_page(virt_to_page(pud));
-   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
+   pgd_populate(NULL, pgd, pud);
+   get_page(virt_to_page(pgd));
+   kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
}
 
next = pgd_addr_end(addr, end);
-   err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
+
+   err = create_hyp_pud_mappings(pgd, addr, next, pfn, prot);
+
if (err)
goto out;
pfn += (next - addr) >> PAGE_SHIFT;
@@ -563,6 +595,24 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
kvm->arch.pgd = NULL;
 }
 
+static pud_t *stage2_get_pud(struct kvm

[PATCH v5 5/6] arm64: mm: Implement 4 levels of translation tables

This patch implements 4 levels of translation tables since 3 levels
of page tables with 4KB pages cannot support 40-bit physical address
space described in [1] due to the following issue.

It is a restriction that kernel logical memory map with 4KB + 3 levels
(0xffc0-0x) cannot cover RAM region from
544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
mapping for this region in map_mem function since __phys_to_virt for
this region reaches to address overflow.

If SoC design follows the document, [1], over 32GB RAM would be placed
from 544GB. Even 64GB system is supposed to use the region from 544GB
to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
of page tables to avoid hacking __virt_to_phys and __phys_to_virt.

However, it is recommended 4 levels of page table should be only enabled
if memory map is too sparse or there is about 512GB RAM.

References
--
[1]: Principles of ARM Memory Maps, White Paper, Issue C

Cc: Catalin Marinas 
Cc: Steve Capper 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm64/Kconfig |8 ++
 arch/arm64/include/asm/memblock.h  |6 +
 arch/arm64/include/asm/page.h  |4 ++-
 arch/arm64/include/asm/pgalloc.h   |   20 ++
 arch/arm64/include/asm/pgtable-hwdef.h |6 +++--
 arch/arm64/include/asm/pgtable.h   |   45 +++
 arch/arm64/include/asm/tlb.h   |9 +++
 arch/arm64/kernel/head.S   |   46 +---
 arch/arm64/kernel/traps.c  |5 
 arch/arm64/mm/fault.c  |1 +
 arch/arm64/mm/mmu.c|   16 ---
 11 files changed, 150 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b438540..3e49671 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -182,12 +182,17 @@ config ARM64_VA_BITS_42
bool "42-bit"
depends on ARM64_64K_PAGES
 
+config ARM64_VA_BITS_48
+   bool "48-bit"
+   depends on ARM64_4K_PAGES
+
 endchoice
 
 config ARM64_VA_BITS
int
default 39 if ARM64_VA_BITS_39
default 42 if ARM64_VA_BITS_42
+   default 48 if ARM64_VA_BITS_48
 
 config ARM64_2_LEVELS
def_bool y if ARM64_64K_PAGES && ARM64_VA_BITS_42
@@ -195,6 +200,9 @@ config ARM64_2_LEVELS
 config ARM64_3_LEVELS
def_bool y if ARM64_4K_PAGES && ARM64_VA_BITS_39
 
+config ARM64_4_LEVELS
+   def_bool y if ARM64_4K_PAGES && ARM64_VA_BITS_48
+
 config CPU_BIG_ENDIAN
bool "Build big-endian kernel"
help
diff --git a/arch/arm64/include/asm/memblock.h 
b/arch/arm64/include/asm/memblock.h
index 6afeed2..e4ac8bf 100644
--- a/arch/arm64/include/asm/memblock.h
+++ b/arch/arm64/include/asm/memblock.h
@@ -16,6 +16,12 @@
 #ifndef __ASM_MEMBLOCK_H
 #define __ASM_MEMBLOCK_H
 
+#ifndef CONFIG_ARM64_4_LEVELS
+#define MEMBLOCK_INITIAL_LIMIT PGDIR_SIZE
+#else
+#define MEMBLOCK_INITIAL_LIMIT PUD_SIZE
+#endif
+
 extern void arm64_memblock_init(void);
 
 #endif
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 268e53d..83b5289 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -35,8 +35,10 @@
 
 #ifdef CONFIG_ARM64_2_LEVELS
 #include 
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
 #include 
+#else
+#include 
 #endif
 
 extern void __cpu_clear_user_page(void *p, unsigned long user);
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 4829837..8d745fa 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,6 +26,26 @@
 
 #define check_pgt_cache()  do { } while (0)
 
+#ifdef CONFIG_ARM64_4_LEVELS
+
+static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
+{
+   return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
+}
+
+static inline void pud_free(struct mm_struct *mm, pud_t *pud)
+{
+   BUG_ON((unsigned long)pud & (PAGE_SIZE-1));
+   free_page((unsigned long)pud);
+}
+
+static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
+{
+   set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));
+}
+
+#endif  /* CONFIG_ARM64_4_LEVELS */
+
 #ifndef CONFIG_ARM64_2_LEVELS
 
 static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
b/arch/arm64/include/asm/pgtable-hwdef.h
index 9cd86c6..ba30053 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -18,8 +18,10 @@
 
 #ifdef CONFIG_ARM64_2_LEVELS
 #include 
-#else
+#elif defined(CONFIG_ARM64_3_LEVELS)
 #include 
+#else
+#include 
 #endif
 
 /*
@@ -27,7 +29,7 @@
  *
  * Level 1 descriptor (PUD).
  */
-
+#define PUD_TYPE_TABLE (_AT(pudval_t, 3) << 0)
 #define PUD_TABLE_BIT  (_AT(pgdval_t, 1) << 1)
 
 /*
diff --git a/arch/arm64/include/asm/pgtable.h

[PATCH v5 3/6] arm64: Add a description on 48-bit address space with 4KB pages

This patch adds memory layout and translation lookup information
about 48-bit address space with 4K pages. The description is based
on 4 levels of translation tables.

Cc: Catalin Marinas 
Cc: Steve Capper 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 Documentation/arm64/memory.txt |   59 ++--
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index d50fa61..8142709 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the 
AArch64
 Linux kernel. The architecture allows up to 4 levels of translation
 tables with a 4KB page size and up to 3 levels with a 64KB page size.
 
-AArch64 Linux uses 3 levels of translation tables with the 4KB page
-configuration, allowing 39-bit (512GB) virtual addresses for both user
-and kernel. With 64KB pages, only 2 levels of translation tables are
-used but the memory layout is the same.
+AArch64 Linux uses 3 levels and 4 levels of translation tables with
+the 4KB page configuration, allowing 39-bit (512GB) and 48-bit (256TB)
+virtual addresses, respectively, for both user and kernel. With 64KB
+pages, only 2 levels of translation tables are used but the memory layout
+is the same.
 
 User addresses have bits 63:39 set to 0 while the kernel addresses have
 the same bits set to 1. TTBRx selection is given by bit 63 of the
@@ -21,7 +22,7 @@ The swapper_pgd_dir address is written to TTBR1 and never 
written to
 TTBR0.
 
 
-AArch64 Linux memory layout with 4KB pages:
+AArch64 Linux memory layout with 4KB pages + 3 levels:
 
 Start  End SizeUse
 ---
@@ -48,7 +49,34 @@ ffbffc00 ffbf  64MB  
modules
 ffc0    256GB  kernel logical 
memory map
 
 
-AArch64 Linux memory layout with 64KB pages:
+AArch64 Linux memory layout with 4KB pages + 4 levels:
+
+Start  End SizeUse
+---
+    256TB  user
+
+   7bfe~124TB  vmalloc
+
+7bff   7bff  64KB  [guard page]
+
+7c00   7dff   2TB  vmemmap
+
+7e00   7bbf  ~2TB  [guard, future 
vmmemap]
+
+7a00   7aff  16MB  PCI I/O space
+
+7b00   7bbf  12MB  [guard]
+
+7bc0   7bdf   2MB  earlyprintk 
device
+
+7be0   7bff   2MB  [guard]
+
+7c00   7fff  64MB  modules
+
+8000    128TB  kernel logical 
memory map
+
+
+AArch64 Linux memory layout with 64KB pages + 2 levels:
 
 Start  End SizeUse
 ---
@@ -75,7 +103,7 @@ fdfffc00 fdff  64MB  
modules
 fe00      2TB  kernel logical 
memory map
 
 
-Translation table lookup with 4KB pages:
+Translation table lookup with 4KB pages + 3 levels:
 
 +++++++++
 |6356|5548|4740|3932|3124|2316|15 8|7  0|
@@ -90,7 +118,22 @@ Translation table lookup with 4KB pages:
  +-> [63] TTBR0/1
 
 
-Translation table lookup with 64KB pages:
+Translation table lookup with 4KB pages + 4 levels:
+
++++++++++
+|6356|5548|4740|3932|3124|2316|15 8|7  0|
++++++++++
+ | | | | | |
+ | | | | | v
+ | | | | |   [11:0]  in-page offset
+ | | | | +-> [20:12] L3 index
+ | | | +---> [29:21] L2 index
+ | | +-> [38:30] L1 index
+ | +---> [47:39] L0 index
+ +-> [63] TTBR0/1
+
+
+Translation table lookup with 64KB pages + 2 levels:
 
 +++++++++
 |6356|5548|4740|3932|3124|2316|15 8|7  0|

[PATCH v5 4/6] arm64: Add 4 levels of page tables definition with 4KB pages

This patch adds hardware definition and types for 4 levels of
translation tables with 4KB pages.

Cc: Catalin Marinas 
Cc: Steve Capper 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm64/include/asm/pgtable-4level-hwdef.h |   50 +
 arch/arm64/include/asm/pgtable-4level-types.h |   71 +
 2 files changed, 121 insertions(+)
 create mode 100644 arch/arm64/include/asm/pgtable-4level-hwdef.h
 create mode 100644 arch/arm64/include/asm/pgtable-4level-types.h

diff --git a/arch/arm64/include/asm/pgtable-4level-hwdef.h 
b/arch/arm64/include/asm/pgtable-4level-hwdef.h
new file mode 100644
index 000..0ec84e2
--- /dev/null
+++ b/arch/arm64/include/asm/pgtable-4level-hwdef.h
@@ -0,0 +1,50 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_PGTABLE_4LEVEL_HWDEF_H
+#define __ASM_PGTABLE_4LEVEL_HWDEF_H
+
+#define PTRS_PER_PTE   512
+#define PTRS_PER_PMD   512
+#define PTRS_PER_PUD   512
+#define PTRS_PER_PGD   512
+
+/*
+ * PGDIR_SHIFT determines the size a top-level page table entry can map.
+ */
+#define PGDIR_SHIFT39
+#define PGDIR_SIZE (_AC(1, UL) << PGDIR_SHIFT)
+#define PGDIR_MASK (~(PGDIR_SIZE-1))
+
+/*
+ * PUD_SHIFT determines the size the second level page table entry can map.
+ */
+#define PUD_SHIFT  30
+#define PUD_SIZE   (_AC(1, UL) << PUD_SHIFT)
+#define PUD_MASK   (~(PUD_SIZE-1))
+
+/*
+ * PMD_SHIFT determines the size the third level page table entry can map.
+ */
+#define PMD_SHIFT  21
+#define PMD_SIZE   (_AC(1, UL) << PMD_SHIFT)
+#define PMD_MASK   (~(PMD_SIZE-1))
+
+/*
+ * section address mask and size definitions.
+ */
+#define SECTION_SHIFT  21
+#define SECTION_SIZE   (_AC(1, UL) << SECTION_SHIFT)
+#define SECTION_MASK   (~(SECTION_SIZE-1))
+
+#endif
diff --git a/arch/arm64/include/asm/pgtable-4level-types.h 
b/arch/arm64/include/asm/pgtable-4level-types.h
new file mode 100644
index 000..7ad8dd2
--- /dev/null
+++ b/arch/arm64/include/asm/pgtable-4level-types.h
@@ -0,0 +1,71 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_PGTABLE_4LEVEL_TYPES_H
+#define __ASM_PGTABLE_4LEVEL_TYPES_H
+
+#include 
+
+typedef u64 pteval_t;
+typedef u64 pmdval_t;
+typedef u64 pudval_t;
+typedef u64 pgdval_t;
+
+#undef STRICT_MM_TYPECHECKS
+
+#ifdef STRICT_MM_TYPECHECKS
+
+/*
+ * These are used to make use of C type-checking..
+ */
+typedef struct { pteval_t pte; } pte_t;
+typedef struct { pmdval_t pmd; } pmd_t;
+typedef struct { pudval_t pud; } pud_t;
+typedef struct { pgdval_t pgd; } pgd_t;
+typedef struct { pteval_t pgprot; } pgprot_t;
+
+#define pte_val(x) ((x).pte)
+#define pmd_val(x) ((x).pmd)
+#define pud_val(x) ((x).pud)
+#define pgd_val(x) ((x).pgd)
+#define pgprot_val(x)  ((x).pgprot)
+
+#define __pte(x)   ((pte_t) { (x) } )
+#define __pmd(x)   ((pmd_t) { (x) } )
+#define __pud(x)   ((pud_t) { (x) } )
+#define __pgd(x)   ((pgd_t) { (x) } )
+#define __pgprot(x)((pgprot_t) { (x) } )
+
+#else  /* !STRICT_MM_TYPECHECKS */
+
+typedef pteval_t pte_t;
+typedef pmdval_t pmd_t;
+typedef pudval_t pud_t;
+typedef pgdval_t pgd_t;
+typedef pteval_t pgprot_t;
+
+#define pte_val(x) (x)
+#define pmd_val(x) (x)
+#define pud_val(x) (x)
+#define pgd_val(x) (x)
+#define pgprot_val(x)  (x)
+
+#define __pte(x)   (x)
+#define __pmd(x)   (x)
+#define __pud(x)   (x)
+#define __pgd(x)   (x)
+#define __pgprot(x)(x)
+
+#endif /* STRICT_MM_TYPECHECKS */
+
+#endif /* __ASM_PGTABLE_4LEVEL_TYPES_H */
-- 
1.7.10.4


--
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

[PATCH v5 2/6] arm64: Introduce VA_BITS and translation level options

This patch adds virtual address space size and a level of translation
tables to kernel configuration. It facilicates introduction of
different MMU options, such as 4KB + 4 levels, 16KB + 4 levels and
64KB + 3 levels, easily.

The idea is based on the discussion with Catalin Marinas:
http://www.spinics.net/linux/lists/arm-kernel/msg319552.html

Cc: Catalin Marinas 
Cc: Steve Capper 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm64/Kconfig |   45 +++-
 arch/arm64/include/asm/memory.h|6 +
 arch/arm64/include/asm/page.h  |2 +-
 arch/arm64/include/asm/pgalloc.h   |4 +--
 arch/arm64/include/asm/pgtable-hwdef.h |2 +-
 arch/arm64/include/asm/pgtable.h   |8 +++---
 arch/arm64/include/asm/tlb.h   |2 +-
 7 files changed, 54 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e759af5..b438540 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -144,14 +144,57 @@ endmenu
 
 menu "Kernel Features"
 
+choice
+   prompt "Page size"
+   default ARM64_4K_PAGES
+   help
+ Allows page size.
+
+config ARM64_4K_PAGES
+   bool "4KB"
+   help
+ This feature enables 4KB pages support.
+
 config ARM64_64K_PAGES
-   bool "Enable 64KB pages support"
+   bool "64KB"
help
  This feature enables 64KB pages support (4KB by default)
  allowing only two levels of page tables and faster TLB
  look-up. AArch32 emulation is not available when this feature
  is enabled.
 
+endchoice
+
+choice
+   prompt "Virtual address space size"
+   default ARM64_VA_BITS_39 if ARM64_4K_PAGES
+   default ARM64_VA_BITS_42 if ARM64_64K_PAGES
+   help
+ Allows virtual address space size. A level of translation tables
+ is determined by a combination of page size and virtual address
+ space size.
+
+config ARM64_VA_BITS_39
+   bool "39-bit"
+   depends on ARM64_4K_PAGES
+
+config ARM64_VA_BITS_42
+   bool "42-bit"
+   depends on ARM64_64K_PAGES
+
+endchoice
+
+config ARM64_VA_BITS
+   int
+   default 39 if ARM64_VA_BITS_39
+   default 42 if ARM64_VA_BITS_42
+
+config ARM64_2_LEVELS
+   def_bool y if ARM64_64K_PAGES && ARM64_VA_BITS_42
+
+config ARM64_3_LEVELS
+   def_bool y if ARM64_4K_PAGES && ARM64_VA_BITS_39
+
 config CPU_BIG_ENDIAN
bool "Build big-endian kernel"
help
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index e94f945..f6e7480 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -41,11 +41,7 @@
  * The module space lives between the addresses given by TASK_SIZE
  * and PAGE_OFFSET - it must be within 128MB of the kernel text.
  */
-#ifdef CONFIG_ARM64_64K_PAGES
-#define VA_BITS(42)
-#else
-#define VA_BITS(39)
-#endif
+#define VA_BITS(CONFIG_ARM64_VA_BITS)
 #define PAGE_OFFSET(UL(0x) << (VA_BITS - 1))
 #define MODULES_END(PAGE_OFFSET)
 #define MODULES_VADDR  (MODULES_END - SZ_64M)
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 46bf666..268e53d 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -33,7 +33,7 @@
 
 #ifndef __ASSEMBLY__
 
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
 #include 
 #else
 #include 
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 9bea6e7..4829837 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,7 +26,7 @@
 
 #define check_pgt_cache()  do { } while (0)
 
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
 
 static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
 {
@@ -44,7 +44,7 @@ static inline void pud_populate(struct mm_struct *mm, pud_t 
*pud, pmd_t *pmd)
set_pud(pud, __pud(__pa(pmd) | PMD_TYPE_TABLE));
 }
 
-#endif /* CONFIG_ARM64_64K_PAGES */
+#endif /* CONFIG_ARM64_2_LEVELS */
 
 extern pgd_t *pgd_alloc(struct mm_struct *mm);
 extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
b/arch/arm64/include/asm/pgtable-hwdef.h
index 5fc8a66..9cd86c6 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -16,7 +16,7 @@
 #ifndef __ASM_PGTABLE_HWDEF_H
 #define __ASM_PGTABLE_HWDEF_H
 
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
 #include 
 #else
 #include 
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 90c811f..a64ce5e 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -47,7 +47,7 @@ extern void __pmd_error(const char *file, int line, unsigned 
long val);
 extern void __pgd_error(const char *file,

[PATCH v5 1/6] arm64: Use pr_* instead of printk

This patch fixed the following checkpatch complaint as using pr_*
instead of printk.

WARNING: printk() should include KERN_ facility level

Cc: Catalin Marinas 
Signed-off-by: Jungseok Lee 
Reviewed-by: Sungjinn Chung 
---
 arch/arm64/kernel/traps.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 7ffaddd..268ce96 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -156,7 +156,7 @@ static void dump_backtrace(struct pt_regs *regs, struct 
task_struct *tsk)
frame.pc = thread_saved_pc(tsk);
}
 
-   printk("Call trace:\n");
+   pr_emerg("Call trace:\n");
while (1) {
unsigned long where = frame.pc;
int ret;
@@ -328,17 +328,17 @@ asmlinkage void bad_mode(struct pt_regs *regs, int 
reason, unsigned int esr)
 
 void __pte_error(const char *file, int line, unsigned long val)
 {
-   printk("%s:%d: bad pte %016lx.\n", file, line, val);
+   pr_crit("%s:%d: bad pte %016lx.\n", file, line, val);
 }
 
 void __pmd_error(const char *file, int line, unsigned long val)
 {
-   printk("%s:%d: bad pmd %016lx.\n", file, line, val);
+   pr_crit("%s:%d: bad pmd %016lx.\n", file, line, val);
 }
 
 void __pgd_error(const char *file, int line, unsigned long val)
 {
-   printk("%s:%d: bad pgd %016lx.\n", file, line, val);
+   pr_crit("%s:%d: bad pgd %016lx.\n", file, line, val);
 }
 
 void __init trap_init(void)
-- 
1.7.10.4


--
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/

[PATCH v5 0/6] Support 4 levels of translation tables for ARM64

Hi All,

This v5 patchset supports 4 levels of tranlsation tables for ARM64.

Firstly, the patchset introduces virtual address space size and
translation level options as taking account into the comment from
Catalin Marinas:
http://www.spinics.net/linux/lists/arm-kernel/msg319552.html

Then, it implements 4 levels of translation tables for native, HYP and
stage2 sides.

All ARMv8 and ARMv7 related changes are validated with FastModels+kvmtool and
A15+QEMU, respectively.

Changes since v1:
- fixed unmatched data types as per Steve's comment
- removed unnecessary #ifdef in arch/arm64/mm/* as per Steve's comment
- revised create_pgd_entry to deal with PUD entry as per Steve's comment
- introduced a macro for initial memblock limit as per Steve's comment
- dropped "Fix line length exceeding 80 characters" patch as per Marc's comment
- removed unnecessary #ifdef in arch/arm/kvm/mmu.c as per Marc's comment
- added a macro for a number of objects of as per Marc's comment

Changes since v2:
- revised some macros in a generic way as per Marc's comment
- added a 2 level option for kvm mmu cache allocation as per Marc's comment

Changes since v3:
- added #ifdef to decide swapper and idmap size as per Steve's comment
- introduced Steve's create_pgd_entry

Changes since v4:
- hided translation level options from menuconfig as per Catalin's comment
- dropped some printk changes as per Mitchel's comment
- squashed VA_BITS related patches into a single patch

Jungseok Lee (6):
  arm64: Use pr_* instead of printk
  arm64: Introduce VA_BITS and translation level options
  arm64: Add a description on 48-bit address space with 4KB pages
  arm64: Add 4 levels of page tables definition with 4KB pages
  arm64: mm: Implement 4 levels of translation tables
  arm64: KVM: Implement 4 levels of translation tables for HYP and
stage2

 Documentation/arm64/memory.txt|   59 ++---
 arch/arm/include/asm/kvm_mmu.h|   10 +++
 arch/arm/kvm/mmu.c|   88 +
 arch/arm64/Kconfig|   53 ++-
 arch/arm64/include/asm/kvm_arm.h  |   34 --
 arch/arm64/include/asm/kvm_mmu.h  |   12 
 arch/arm64/include/asm/memblock.h |6 ++
 arch/arm64/include/asm/memory.h   |6 +-
 arch/arm64/include/asm/page.h |6 +-
 arch/arm64/include/asm/pgalloc.h  |   24 ++-
 arch/arm64/include/asm/pgtable-4level-hwdef.h |   50 ++
 arch/arm64/include/asm/pgtable-4level-types.h |   71 
 arch/arm64/include/asm/pgtable-hwdef.h|8 ++-
 arch/arm64/include/asm/pgtable.h  |   53 +--
 arch/arm64/include/asm/tlb.h  |   11 +++-
 arch/arm64/kernel/head.S  |   46 ++---
 arch/arm64/kernel/traps.c |   13 ++--
 arch/arm64/mm/fault.c |1 +
 arch/arm64/mm/mmu.c   |   16 +++--
 19 files changed, 507 insertions(+), 60 deletions(-)
 create mode 100644 arch/arm64/include/asm/pgtable-4level-hwdef.h
 create mode 100644 arch/arm64/include/asm/pgtable-4level-types.h

-- 
1.7.10.4


--
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: [alsa-devel] [PATCH 01/15] ASoC: CS42L51 and WM8962 codecs depend on INPUT

2014-04-30 Thread Austin, Brian


On Apr 30, 2014, at 8:54 PM, Austin, Brian  wrote:

> 
> 
>> On Apr 30, 2014, at 20:31, "Mark Brown"  wrote:
>> 
>>> On Tue, Apr 29, 2014 at 09:31:30PM -0500, Brian Austin wrote:
>>> 
>>> I assume you mean the CS42L52 instead of the L51. INPUT is used for a BEEP
>>> Generator but when I disable CONFIG_INPUT I do not get an error. Is there
>>> any information available on what the error is?
>> 
>> I suspect it's ASoC built in and INPUT build as a module.
> Ok, I'll try that next.
> Doesn't IS_ENABLED cover that?
Apparently not.
I would like to come up with a better solution than making INPUT a requirement. 
I just need some time.
In the meantime I suppose it’s OK to apply it? 


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [alsa-devel] [PATCH 01/15] ASoC: CS42L51 and WM8962 codecs depend on INPUT

2014-04-30 Thread Austin, Brian



> On Apr 30, 2014, at 20:31, "Mark Brown"  wrote:
> 
>> On Tue, Apr 29, 2014 at 09:31:30PM -0500, Brian Austin wrote:
>> 
>> I assume you mean the CS42L52 instead of the L51. INPUT is used for a BEEP
>> Generator but when I disable CONFIG_INPUT I do not get an error. Is there
>> any information available on what the error is?
> 
> I suspect it's ASoC built in and INPUT build as a module.
Ok, I'll try that next.
Doesn't IS_ENABLED cover that?
--
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/

linux-next: manual merge of the pm tree with the mips tree

2014-04-30 Thread Stephen Rothwell

Hi Rafael,

Today's linux-next merge of the pm tree got a conflict in
arch/mips/loongson/lemote-2f/clock.c between commit a68ce6507a45
("MIPS/loongson2_cpufreq: Fix CPU clock rate setting") from the mips tree
and commit 4966ee4037fe ("mips: lemote 2f: Use cpufreq_for_each_entry
macro for iteration") from the pm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/mips/loongson/lemote-2f/clock.c
index 67dd94ef28e6,1eed38e28b1e..
--- a/arch/mips/loongson/lemote-2f/clock.c
+++ b/arch/mips/loongson/lemote-2f/clock.c
@@@ -91,10 -91,9 +91,10 @@@ EXPORT_SYMBOL(clk_put)
  
  int clk_set_rate(struct clk *clk, unsigned long rate)
  {
 +  unsigned int rate_khz = rate / 1000;
+   struct cpufreq_frequency_table *pos;
int ret = 0;
int regval;
-   int i;
  
if (likely(clk->ops && clk->ops->set_rate)) {
unsigned long flags;
@@@ -107,15 -106,10 +107,10 @@@
if (unlikely(clk->flags & CLK_RATE_PROPAGATES))
propagate_rate(clk);
  
-   for (i = 0; loongson2_clockmod_table[i].frequency != CPUFREQ_TABLE_END;
-i++) {
-   if (loongson2_clockmod_table[i].frequency ==
-   CPUFREQ_ENTRY_INVALID)
-   continue;
-   if (rate_khz == loongson2_clockmod_table[i].frequency)
+   cpufreq_for_each_valid_entry(pos, loongson2_clockmod_table)
 -  if (rate == pos->frequency)
++  if (rate_khz == pos->frequency)
break;
-   }
-   if (rate_khz != loongson2_clockmod_table[i].frequency)
 -  if (rate != pos->frequency)
++  if (rate_khz != pos->frequency)
return -ENOTSUPP;
  
clk->rate = rate;


pgp8CAz9alH3T.pgp
Description: PGP signature

Re: [PATCH] random: Add "initialized" variable to proc

2014-04-30 Thread Theodore Ts'o

On Wed, Apr 30, 2014 at 01:52:35PM -0700, Andy Lutomirski wrote:
> 
> 1. It simply doesn't work on my system.  In particular, it never returns
> entropy.  It just blocks forever.

Why?  Is this a bug in qemu?  The host OS?  The guest OS?  It is qemu
trying to use /dev/random instead of /dev/urandom?  Any thing else?

> 3. There should be a way to provide some entropy-free cryptographically
> secure data, too.  Regardless of the speed of the hosts's /dev/random,
> the guest should start with at least 256 bits of cryptographically
> secure seed material IMO.

Well, the simplest way to do this is to pass it in via the command
line, and then have the the kernel make sure it gets obscured so it's
not exposed via /proc/cmdline.

Otherwise we would have to define an extension where we pass 32 bytes
or so after the boot command line.  But the downside of doing that is
we would have to modify every single architecture to define where
those 32 bytes could be found.

Aside from passing it on the command line as being a bit grotty, the
other big problem this is that some architectures only have 256 bytes
of command line, and if we use a base 64 encoding, 256 bits will take
43 characters.  Not a problem on x86, and it seems rather unlikely
that people would want to virtualize a m68k or avr32 CPU.  It just
feels really unclean.

I've cc'ed Peter Anvin for his opinion about extending Linux boot
parameter protocol.  I agree it would be a lot simpler and easier to
enable things like Kernel ASLR with real randomness on guest OS's if
we didn't have to erect the whole virtio-pci infrastructure during
early boot.  :-)

 -Ted
--
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 2/2] mm/compaction: cleanup isolate_freepages()

2014-04-30 Thread Michal Nazarewicz

On Fri, Apr 25 2014, Joonsoo Kim wrote:
> Subject: [PATCH] mm-compaction-cleanup-isolate_freepages-fix3
>
> What I did here is taking end_pfn out of the loop and considering zone
> boundary once. After then, we can just set previous pfn to end_pfn on
> every iteration to move scanning window. With this change, we can remove
> local variable, z_end_pfn.
>
> Another things I did are removing max() operation and un-needed
> assignment to isolate variable.
>
> In addition, I change both the variable names, from pfn and
> end_pfn to block_start_pfn and block_end_pfn, respectively.
> They represent their meaning perfectly.
>
> Signed-off-by: Joonsoo Kim 

Acked-by: Michal Nazarewicz 

> diff --git a/mm/compaction.c b/mm/compaction.c
> index 1c992dc..ba80bea 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -671,10 +671,10 @@ static void isolate_freepages(struct zone *zone,
>   struct compact_control *cc)
>  {
>   struct page *page;
> - unsigned long pfn;   /* scanning cursor */
> + unsigned long block_start_pfn;  /* start of current pageblock */
> + unsigned long block_end_pfn;/* end of current pageblock */
>   unsigned long low_pfn;   /* lowest pfn scanner is able to scan */
>   unsigned long next_free_pfn; /* start pfn for scaning at next round */
> - unsigned long z_end_pfn; /* zone's end pfn */
>   int nr_freepages = cc->nr_freepages;
>   struct list_head *freelist = >freepages;
>  
> @@ -682,31 +682,33 @@ static void isolate_freepages(struct zone *zone,
>* Initialise the free scanner. The starting point is where we last
>* successfully isolated from, zone-cached value, or the end of the
>* zone when isolating for the first time. We need this aligned to
> -  * the pageblock boundary, because we do pfn -= pageblock_nr_pages
> -  * in the for loop.
> +  * the pageblock boundary, because we do
> +  * block_start_pfn -= pageblock_nr_pages in the for loop.
> +  * For ending point, take care when isolating in last pageblock of a
> +  * a zone which ends in the middle of a pageblock.
>* The low boundary is the end of the pageblock the migration scanner
>* is using.
>*/
> - pfn = cc->free_pfn & ~(pageblock_nr_pages-1);
> + block_start_pfn = cc->free_pfn & ~(pageblock_nr_pages-1);
> + block_end_pfn = min(block_start_pfn + pageblock_nr_pages,
> + zone_end_pfn(zone));
>   low_pfn = ALIGN(cc->migrate_pfn + 1, pageblock_nr_pages);
>  
>   /*
> -  * Seed the value for max(next_free_pfn, pfn) updates. If no pages are
> -  * isolated, the pfn < low_pfn check will kick in.
> +  * If no pages are isolated, the block_start_pfn < low_pfn check
> +  * will kick in.
>*/
>   next_free_pfn = 0;
>  
> - z_end_pfn = zone_end_pfn(zone);
> -
>   /*
>* Isolate free pages until enough are available to migrate the
>* pages on cc->migratepages. We stop searching if the migrate
>* and free page scanners meet or enough free pages are isolated.
>*/
> - for (; pfn >= low_pfn && cc->nr_migratepages > nr_freepages;
> - pfn -= pageblock_nr_pages) {
> + for (;block_start_pfn >= low_pfn && cc->nr_migratepages > nr_freepages;
> + block_end_pfn = block_start_pfn,
> + block_start_pfn -= pageblock_nr_pages) {
>   unsigned long isolated;
> - unsigned long end_pfn;
>  
>   /*
>* This can iterate a massively long zone without finding any
> @@ -715,7 +717,7 @@ static void isolate_freepages(struct zone *zone,
>*/
>   cond_resched();
>  
> - if (!pfn_valid(pfn))
> + if (!pfn_valid(block_start_pfn))
>   continue;
>  
>   /*
> @@ -725,7 +727,7 @@ static void isolate_freepages(struct zone *zone,
>* i.e. it's possible that all pages within a zones range of
>* pages do not belong to a single zone.
>*/
> - page = pfn_to_page(pfn);
> + page = pfn_to_page(block_start_pfn);
>   if (page_zone(page) != zone)
>   continue;
>  
> @@ -738,15 +740,8 @@ static void isolate_freepages(struct zone *zone,
>   continue;
>  
>   /* Found a block suitable for isolating free pages from */
> - isolated = 0;
> -
> - /*
> -  * Take care when isolating in last pageblock of a zone which
> -  * ends in the middle of a pageblock.
> -  */
> - end_pfn = min(pfn + pageblock_nr_pages, z_end_pfn);
> - isolated = isolate_freepages_block(cc, pfn, end_pfn,
> -freelist, false);
> + isolated =

Re: [PATCH] spi: Fix hung task timeout when initialization fails

On Wed, Apr 30, 2014 at 12:36:11PM +0200, Ricardo Ribalda Delgado wrote:

> Since "786235eeba0e1e85e5cbbb9f97d1087ad03dfa21 kthread:
> make kthread_create() killable" kthread_run can be killed by the user,
> ie, by killing modprobe.

> - flush_kthread_worker(>kworker);
> - kthread_stop(master->kworker_task);
> + if (!IS_ERR(master->kworker_task)) {
> + flush_kthread_worker(>kworker);
> + kthread_stop(master->kworker_task);
> + }

How does this fix avoid racing with the task being killed?  It will
improve things but it doesn't look like a full fix.

Please don't include entire backtraces in commit messages, they're
typically extremely long and don't really add anything - edited
highlights are fine but try to keep it to the point.

signature.asc
Description: Digital signature

Re: [alsa-devel] [PATCH 01/15] ASoC: CS42L51 and WM8962 codecs depend on INPUT

On Tue, Apr 29, 2014 at 09:31:30PM -0500, Brian Austin wrote:

> I assume you mean the CS42L52 instead of the L51. INPUT is used for a BEEP
> Generator but when I disable CONFIG_INPUT I do not get an error. Is there
> any information available on what the error is?

I suspect it's ASoC built in and INPUT build as a module.


signature.asc
Description: Digital signature

Re: [PATCH 01/15] ASoC: CS42L51 and WM8962 codecs depend on INPUT

On Tue, Apr 29, 2014 at 07:18:22PM +0800, Xia Kaixu wrote:
> From: Arnd Bergmann 
> 
> Building ARM randconfig got into a situation where CONFIG_INPUT
> is turned off and SND_SOC_ALL_CODECS is turned on, which failed
> for two codecs trying to use the input subsystem. Some other 

Applied, but...

> Cc: Mark Brown 
> Cc: Liam Girdwood 
> Cc: Ben Dooks 
> Cc: Kukjin Kim 
> Cc: Sangbeom Kim 
> Cc: Lars-Peter Clausen 
> Cc: Timur Tabi 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-in...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org

...please don't include noise like this in patch submissions, especially
with such long lists (which still manage to miss the driver maintainers
concerned).


signature.asc
Description: Digital signature

Re: [RFC PATCH] regulator: virtual: Introduce a new virtual locker regulator type

On Wed, Apr 30, 2014 at 11:56:08AM -0700, Doug Anderson wrote:

> I cornered Rob and Mark Rutland a little bit about this at ELC today
> (sorry!).  Neither of them was a huge ran of adding a pseudo device.
> Rob suggested that Mark Brown might be the best person to give
> direction here.  Mark Brown: any thoughts?

I glanced at this briefly and couldn't really understand what it was
supposed to do from a quick glance but I do tend to agree that it's too
complex and confusing.  Quite what the virtual regulator is supposed to
represent or how it is used is distinctly non-obvious.

> Potentially we could also make this type of thing a core regulator property:

Yes, that seems like the obvious solution if it's in the core.  Someone
would need to write the code of course.

> Another option is to add no device tree code at all and add code to
> the devfreq / cpufreq drivers used on this device.  In order to do
> this cleanly I think we'd need to extend the regulator core's
> notification scheme to introduce a new event:
> REGULATOR_EVENT_VOLTAGE_CHANGING that's called _before_ a voltage
> change happened.

That only works if it's the same thing scaling both voltages.  That
might be true most of the time but is it true all of the time?  If it is
then that's great.

signature.asc
Description: Digital signature

Re: [PATCH] ASoC: cq93vc: fix cq93vc_get_regmap build error

On Wed, Apr 30, 2014 at 11:06:29AM +0200, Arnd Bergmann wrote:
> 49101a25acd69c "ASoC: cq93vc: Remove the set_cache_io() entirely from
> ASoC probe" introduced the cq93vc_get_regmap function that has an
> obvious build error referring to the 'codec' variable that is not
> declared anywhere"

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCHv3 0/2] add DT endianness binding support

On Wed, Apr 30, 2014 at 09:10:12AM +0200, Richard Cochran wrote:
> Shouldn't this go to the arm list and rmk for review, too?

Is there any particular reason for including rmk?  It's generally not
helpful to spam people with serieses without reason, we all get quite a
lot of mail already...


signature.asc
Description: Digital signature

Re: [PATCH] spi: Force the registration of the spidev devices

On Wed, Apr 30, 2014 at 11:06:09AM -0700, Maxime Ripard wrote:
> On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:

> > Why can we not handle this by using sysfs to bind spidev to the
> > device?

> I just tried it, and apparently, you can't really use this, since spi
> devices are created from the device tree (or ACPI) whenever the master
> registers.

Can you be more specific as to what the issue is here?  If we actually
have a specific kernel driver for a device I would strongly expect that
we would want to use it and not spidev, if we don't have one I don't see
the issue.

> It doesn't really work either for a device that would be bound to a
> driver, that you unbind, and then try to bind to spidev instead. It
> looks like the device is released whenever you unbind it, so you can't
> really use it afterwards.

I guess this is the issue...  what exactly is the use case here?  I
would only expect spidev to be used if there is no in kernel driver for
a device.

signature.asc
Description: Digital signature

[RFC PATCH 2/3] of: mtd: add NAND randomizer mode retrieval

Signed-off-by: Boris BREZILLON 
---
 drivers/of/of_mtd.c| 35 +++
 include/linux/of_mtd.h |  6 ++
 2 files changed, 41 insertions(+)

diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
index a862c08..f941a5e 100644
--- a/drivers/of/of_mtd.c
+++ b/drivers/of/of_mtd.c
@@ -84,6 +84,41 @@ int of_get_nand_ecc_strength(struct device_node *np)
 EXPORT_SYMBOL_GPL(of_get_nand_ecc_strength);
 
 /**
+ * It maps 'enum nand_rnd_modes_t' found in include/linux/mtd/nand.h
+ * into the device tree binding of 'nand-rnd', so that MTD
+ * device driver can get nand rnd from device tree.
+ */
+static const char * const nand_rnd_modes[] = {
+   [NAND_RND_NONE] = "none",
+   [NAND_RND_SOFT] = "soft",
+   [NAND_RND_HW]   = "hw",
+};
+
+/**
+ * of_get_nand_rnd_mode - Get nand randomizer mode for given device_node
+ * @np:Pointer to the given device_node
+ *
+ * The function gets randomizer mode string from property 'nand-rnd-mode',
+ * and return its index in nand_rnd_modes table, or errno in error case.
+ */
+int of_get_nand_rnd_mode(struct device_node *np)
+{
+   const char *pm;
+   int err, i;
+
+   err = of_property_read_string(np, "nand-rnd-mode", );
+   if (err < 0)
+   return err;
+
+   for (i = 0; i < ARRAY_SIZE(nand_rnd_modes); i++)
+   if (!strcasecmp(pm, nand_rnd_modes[i]))
+   return i;
+
+   return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(of_get_nand_rnd_mode);
+
+/**
  * of_get_nand_bus_width - Get nand bus witdh for given device_node
  * @np:Pointer to the given device_node
  *
diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
index d0145fb..2f43362 100644
--- a/include/linux/of_mtd.h
+++ b/include/linux/of_mtd.h
@@ -15,6 +15,7 @@
 int of_get_nand_ecc_mode(struct device_node *np);
 int of_get_nand_ecc_step_size(struct device_node *np);
 int of_get_nand_ecc_strength(struct device_node *np);
+int of_get_nand_rnd_mode(struct device_node *np);
 int of_get_nand_bus_width(struct device_node *np);
 bool of_get_nand_on_flash_bbt(struct device_node *np);
 int of_get_nand_onfi_timing_mode(struct device_node *np);
@@ -36,6 +37,11 @@ static inline int of_get_nand_ecc_strength(struct 
device_node *np)
return -ENOSYS;
 }
 
+static inline int of_get_nand_rnd_mode(struct device_node *np)
+{
+   return -ENOSYS;
+}
+
 static inline int of_get_nand_bus_width(struct device_node *np)
 {
return -ENOSYS;
-- 
1.8.3.2

--
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/

[RFC PATCH 1/3] mtd: nand: introduce a randomizer layer in the NAND framework

This patch introduce a new layer in the NAND framework to support both HW
and SW randomizers.

This randomization is required on some MLC/TLC NAND chips which do not
support large islands of same patterns.

The randomizer layer defines a nand_rnd_ctrl struct which is intended to
be used by NAND core functions or NAND drivers to randomize/derandomize
data stored on NAND chips.

The implementation can implement any of these functions:
- config: prepare a random transfer to/from the NAND chip
- write_buf: randomize and write data to the NAND chip
- read_buf: read and derandomize data from the NAND chip

read/write_buf functions are always called after a config call.
The config call specify the page, the column within the page and the action
that will take place after the config (either read or write).
If column is set to -1, the randomizer is disabled.
If page is set to -1, we keep working on the same page.

The randomizer layer provides helper functions that choose wether the
randomizer or the chip read/write_buf should be used.

Signed-off-by: Boris BREZILLON 
---
 drivers/mtd/nand/nand_base.c | 280 ++-
 include/linux/mtd/nand.h |  98 +++
 2 files changed, 323 insertions(+), 55 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 4a28383..a8530a9 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1048,6 +1048,62 @@ out:
 EXPORT_SYMBOL(nand_lock);
 
 /**
+ * nand_rnd_is_activ - check wether a region of a NAND page requires NAND
+ *randomizer to be disabled
+ * @mtd:   mtd info
+ * @page:  NAND page
+ * @column:offset within the page
+ * @len:   len of the region
+ *
+ * Returns 1 if the randomizer should be enabled, 0 if not, or -ERR in case of
+ * error.
+ *
+ * In case of success len will contain the size of the region:
+ *  - if the requested region fits in a NAND random region len will not change
+ *  - else len will be replaced by the available length within the NAND random
+ *region
+ */
+int nand_rnd_is_activ(struct mtd_info *mtd, int page, int column, int *len)
+{
+   struct nand_chip *chip = mtd->priv;
+   struct nand_rnd_layout *layout = chip->cur_rnd->layout;
+   struct nand_rndfree *range;
+   int ret = 1;
+   int tmp;
+   int i;
+
+   if (!len || *len < 0 || column < 0 ||
+   column + *len > mtd->writesize + mtd->oobsize)
+   return -EINVAL;
+
+   if (layout) {
+   for (i = 0; i < layout->nranges; i++) {
+   range = >ranges[i];
+   if (column + *len <= range->offset) {
+   break;
+   } else if (column >= range->offset + range->length) {
+   continue;
+   } else if (column < range->offset) {
+   tmp = range->offset - column;
+   if (*len > tmp)
+   *len = tmp;
+   break;
+   } else {
+   tmp = range->offset + range->length - column;
+   if (*len > tmp)
+   *len = tmp;
+   ret = 0;
+   break;
+   }
+
+   }
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL(nand_rnd_is_activ);
+
+/**
  * nand_page_is_empty - check wether a NAND page contains only FFs
  * @mtd:   mtd info
  *
@@ -1156,9 +1212,14 @@ EXPORT_SYMBOL(nand_pst_create);
 static int nand_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
  uint8_t *buf, int oob_required, int page)
 {
-   chip->read_buf(mtd, buf, mtd->writesize);
-   if (oob_required)
-   chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
+   nand_rnd_config(mtd, page, 0, NAND_RND_READ);
+   nand_rnd_read_buf(mtd, buf, mtd->writesize);
+   if (oob_required) {
+   nand_rnd_config(mtd, page, mtd->writesize, NAND_RND_READ);
+   nand_rnd_read_buf(mtd, chip->oob_poi, mtd->oobsize);
+   }
+   nand_rnd_config(mtd, -1, -1, NAND_RND_READ);
+
return 0;
 }
 
@@ -1180,28 +1241,40 @@ static int nand_read_page_raw_syndrome(struct mtd_info 
*mtd,
int eccbytes = chip->cur_ecc->bytes;
uint8_t *oob = chip->oob_poi;
int steps, size;
+   int column = 0;
 
for (steps = chip->cur_ecc->steps; steps > 0; steps--) {
-   chip->read_buf(mtd, buf, eccsize);
+   nand_rnd_config(mtd, page, column, NAND_RND_READ);
+   nand_rnd_read_buf(mtd, buf, eccsize);
buf += eccsize;
+   column += eccsize;
 
if (chip->cur_ecc->prepad) {
-   chip->read_buf(mtd, oob, chip->cur_ecc->prepad);
+

[RFC PATCH 3/3] mtd: nand: add sunxi randomizer support

Add support for the HW randomizer available in the sunxi IP.

Signed-off-by: Boris BREZILLON 
---
 drivers/mtd/nand/sunxi_nand.c | 511 +-
 1 file changed, 500 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 54d3ebd..2f76912 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -171,6 +171,7 @@ struct sunxi_nand_hw_ecc {
 struct sunxi_nand_part {
struct nand_part part;
struct nand_ecc_ctrl ecc;
+   struct nand_rnd_ctrl rnd;
 };
 
 static inline struct sunxi_nand_part *
@@ -179,6 +180,17 @@ to_sunxi_nand_part(struct nand_part *part)
return container_of(part, struct sunxi_nand_part, part);
 }
 
+struct sunxi_nand_hw_rnd {
+   int page;
+   int column;
+   int nseeds;
+   u16 *seeds;
+   u16 *subseeds;
+   u16 (*step)(struct mtd_info *mtd, u16 state, int column, int *left);
+   int left;
+   u16 state;
+};
+
 struct sunxi_nand_chip {
struct list_head node;
struct nand_chip nand;
@@ -380,6 +392,175 @@ static void sunxi_nfc_write_buf(struct mtd_info *mtd, 
const uint8_t *buf,
}
 }
 
+static u16 sunxi_nfc_hwrnd_step(struct sunxi_nand_hw_rnd *rnd, u16 state,
+   int count)
+{
+   state &= 0x7fff;
+   count *= 8;
+   while (count--)
+   state = ((state >> 1) |
+state >> 0) ^ (state >> 1)) & 1) << 14)) & 0x7fff;
+
+   return state;
+}
+
+static int sunxi_nfc_hwrnd_config(struct mtd_info *mtd, int page, int column,
+ enum nand_rnd_action action)
+{
+   struct nand_chip *nand = mtd->priv;
+   struct sunxi_nand_hw_rnd *rnd = nand->cur_rnd->priv;
+   u16 state;
+
+   if (page < 0 && column < 0) {
+   rnd->page = -1;
+   rnd->column = -1;
+   return 0;
+   }
+
+   if (column < 0)
+   column = 0;
+   if (page < 0)
+   page = rnd->page;
+
+   if (page < 0)
+   return -EINVAL;
+
+   if (page != rnd->page && action == NAND_RND_READ) {
+   int status;
+
+   status = nand_page_get_status(mtd, page);
+   if (status == NAND_PAGE_STATUS_UNKNOWN) {
+   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, 0, -1);
+   sunxi_nfc_read_buf(mtd, nand->buffers->databuf,
+  mtd->writesize + mtd->oobsize);
+
+   if (nand_page_is_empty(mtd))
+   status = NAND_PAGE_EMPTY;
+   else
+   status = NAND_PAGE_FILLED;
+
+   nand_page_set_status(mtd, page, status);
+   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, column, -1);
+   }
+   }
+
+   state = rnd->seeds[page % rnd->nseeds];
+   rnd->page = page;
+   rnd->column = column;
+
+   if (rnd->step) {
+   rnd->state = rnd->step(mtd, state, column, >left);
+   } else {
+   rnd->state = sunxi_nfc_hwrnd_step(rnd, state, column % 4096);
+   rnd->left = mtd->oobsize + mtd->writesize - column;
+   }
+
+   return 0;
+}
+
+static void sunxi_nfc_hwrnd_write_buf(struct mtd_info *mtd, const uint8_t *buf,
+ int len)
+{
+   struct nand_chip *nand = mtd->priv;
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct sunxi_nand_hw_rnd *rnd = nand->cur_rnd->priv;
+   u32 tmp = readl(nfc->regs + NFC_REG_ECC_CTL);
+   int cnt;
+   int offs = 0;
+   int rndactiv;
+
+   tmp &= ~(NFC_RANDOM_DIRECTION | NFC_RANDOM_SEED | NFC_RANDOM_EN);
+   writel(tmp, nfc->regs + NFC_REG_ECC_CTL);
+
+   if (rnd->page < 0) {
+   sunxi_nfc_write_buf(mtd, buf, len);
+   return;
+   }
+
+   while (len > offs) {
+   cnt = len - offs;
+   if (cnt > 1024)
+   cnt = 1024;
+
+   rndactiv = nand_rnd_is_activ(mtd, rnd->page, rnd->column,
+);
+   if (rndactiv > 0) {
+   writel(tmp | NFC_RANDOM_EN | (rnd->state << 16),
+  nfc->regs + NFC_REG_ECC_CTL);
+   if (rnd->left < cnt)
+   cnt = rnd->left;
+   }
+
+   sunxi_nfc_write_buf(mtd, buf + offs, cnt);
+
+   if (rndactiv > 0)
+   writel(tmp & ~NFC_RANDOM_EN,
+  nfc->regs + NFC_REG_ECC_CTL);
+
+   offs += cnt;
+   if (len <= offs)
+   break;
+
+   sunxi_nfc_hwrnd_config(mtd, -1, rnd->column + cnt,
+  NAND_RND_WRITE);
+   }
+}
+
+static void

[RFC PATCH 0/3] mtd: nand: add randomizer support

Hello,

This series is a proposal to add support for randomizers (either software
or hardware) to NAND flash controller drivers.

The last patch is the sunxi HW randomizer implementation and is just given
as an example (it won't apply on the MTD tree, because it depends on other
stuff not yet posted on the MTD ML, but if you want a full overview of the
NAND Flash controller driver you can take a look at this series [2]).

I can also provide a software implementation based on LFSR (Left Feedback
Shift Register) algorithm, thought I haven't tested it yet, hence why it's
not part of this series. Let me know if you're interested in this
implementation.

This series depends on the "per-partition ECC" series [1], because I need
the randomizer seed to be different depending on the partition (for the
same reason I needed ECC config to be different for each partition: the
bootrom config might not fit the NAND chip requirements).

I'd like to have feedback from both MTD maintainers and driver
developers who might need to implement (or use) a randomizer in their
system, so feel free to comment on this series.

Best Regards,

Boris

[1] https://lkml.org/lkml/2014/2/12/627
[2] https://groups.google.com/forum/#!msg/linux-sunxi/s3lBb01I0Js/z2NoCFJ83g4J 


Boris BREZILLON (3):
  mtd: nand: introduce a randomizer layer in the NAND framework
  of: mtd: add NAND randomizer mode retrieval
  mtd: nand: add sunxi randomizer support

 drivers/mtd/nand/nand_base.c  | 278 ++-
 drivers/mtd/nand/sunxi_nand.c | 507 +-
 drivers/of/of_mtd.c   |  35 +++
 include/linux/mtd/nand.h  |  98 
 include/linux/of_mtd.h|   6 +
 5 files changed, 858 insertions(+), 66 deletions(-)

-- 
1.8.3.2

--
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 v4 4/7] arm64: Add a description on 48-bit address space with 4KB pages

On Wednesday, April 30, 2014 10:12 PM, Catalin Marinas wrote:
> On Wed, Apr 30, 2014 at 07:41:40AM +0100, Jungseok Lee wrote:
> > On Tuesday, April 29, 2014 11:48 PM, Catalin Marinas wrote:
> > > On Tue, Apr 29, 2014 at 05:59:27AM +0100, Jungseok Lee wrote:
> > > > --- a/Documentation/arm64/memory.txt
> > > > +++ b/Documentation/arm64/memory.txt
> > > > @@ -8,10 +8,11 @@ This document describes the virtual memory
> > > > layout used by the AArch64  Linux kernel. The architecture allows
> > > > up to 4 levels of translation  tables with a 4KB page size and up to 3 
> > > > levels with a 64KB page
> size.
> > > >
> > > > -AArch64 Linux uses 3 levels of translation tables with the 4KB
> > > > page -configuration, allowing 39-bit (512GB) virtual addresses for
> > > > both user -and kernel. With 64KB pages, only 2 levels of
> > > > translation tables are -used but the memory layout is the same.
> > > > +AArch64 Linux uses 3 levels and 4 levels of translation tables
> > > > +with the 4KB page configuration, allowing 39-bit (512GB) and
> > > > +48-bit
> > > > +(256TB) virtual addresses, respectively, for both user and kernel.
> > > > +With 64KB pages, only 2 levels of translation tables are used but
> > > > +the memory layout is the same.
> > >
> > > Any reason why we couldn't use 48-bit address space with 64K pages 
> > > (implying 3 levels)?
> >
> > No technical reason.
> > Since 64K+3levels is not implemented in this set, I didn't add it.
> >
> > Should 64K+3levels be prepared in this patchset?
> >
> > > > -AArch64 Linux memory layout with 64KB pages:
> > > > +AArch64 Linux memory layout with 4KB pages + 4 levels:
> > > > +
> > > > +Start  End SizeUse
> > > > +---
> > > > +    256TB  user
> > > > +
> > > > +   7bfe~124TB  vmalloc
> > >
> > > BTW, maybe as a separate patch we should change the "end" to be
> > > exclusive. It becomes harder to modify (I've been through this a few 
> > > times already ;)) and even
> follow the changes.
> >
> > Does "exclusive" mean that  is changed to 0001?
> > Or Does it mean that "End" column is dropped?
> 
> Not dropped but changed to 0001 (the kernel already prints the memory 
> layout in a similar way).

I see. I will make it as a separate patch.

Best Regards
Jungseok Lee

--
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/

[PATCH RT 3/3] Linux 3.12.15-rt26-rc1

3.12.15-rt26-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: "Steven Rostedt (Red Hat)" 

---
 localversion-rt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/localversion-rt b/localversion-rt
index c5b71f9..02556f4 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt25
+-rt26-rc1
-- 
1.8.5.3


--
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/

[PATCH RT 1/3] rt: Move migrate_disable up in trylocks

3.12.15-rt26-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: Steven Rostedt 

The changes to move the migrate_disable() down in the trylocks()
caused race conditions to appear in the cpu hotplug code. The
migrate disables must be done before any of the rtmutexes are
taken, otherwise a lock may be held that prevents hotplug from
moving forward.

Link: http://lkml.kernel.org/r/20140429201308.63292...@gandalf.local.home

Signed-off-by: Steven Rostedt 
Cc: Mike Galbraith 
Cc: Nicholas Mc Guire 
Cc: Sebastian Andrzej Siewior 
Cc: linux-rt-users 
Cc: Thomas Gleixner 
Cc: John Kacur 
Cc: Clark Williams 
---
 kernel/rt.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/kernel/rt.c b/kernel/rt.c
index 5d17727..5f44def 100644
--- a/kernel/rt.c
+++ b/kernel/rt.c
@@ -180,12 +180,15 @@ EXPORT_SYMBOL(_mutex_unlock);
  */
 int __lockfunc rt_write_trylock(rwlock_t *rwlock)
 {
-   int ret = rt_mutex_trylock(>lock);
+   int ret;
+
+   migrate_disable();
+   ret = rt_mutex_trylock(>lock);
 
-   if (ret) {
+   if (ret)
rwlock_acquire(>dep_map, 0, 1, _RET_IP_);
-   migrate_disable();
-   }
+   else
+   migrate_enable();
 
return ret;
 }
@@ -212,11 +215,12 @@ int __lockfunc rt_read_trylock(rwlock_t *rwlock)
 * write locked.
 */
if (rt_mutex_owner(lock) != current) {
+   migrate_disable();
ret = rt_mutex_trylock(lock);
-   if (ret) {
+   if (ret)
rwlock_acquire(>dep_map, 0, 1, _RET_IP_);
-   migrate_disable();
-   }
+   else
+   migrate_enable();
} else if (!rwlock->read_depth) {
ret = 0;
}
@@ -245,8 +249,8 @@ void __lockfunc rt_read_lock(rwlock_t *rwlock)
 */
if (rt_mutex_owner(lock) != current) {
rwlock_acquire(>dep_map, 0, 0, _RET_IP_);
-   __rt_spin_lock(lock);
migrate_disable();
+   __rt_spin_lock(lock);
}
rwlock->read_depth++;
 }
-- 
1.8.5.3


--
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/

[PATCH RT 2/3] net: gianfar: Fix missing return of gfar_clean_tx_ring()

3.12.15-rt26-rc1 stable review patch.
If anyone has any objections, please let me know.

--

From: "Steven Rostedt (Red Hat)" 

The patch "net: gianfar: do not try to cleanup TX packets if they are
not done" for 3.12-rt left out the return value for gfar_clean_tx_ring().
This would cause an error when building this module. Note, this module
does not build on x86 and was not tested because of that.

Reported-by: Sebastian Andrzej Siewior 
Signed-off-by: Steven Rostedt 
---
 drivers/net/ethernet/freescale/gianfar.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index 091945c..df27493 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -2615,6 +2615,7 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q 
*tx_queue)
tx_queue->dirty_tx = bdp;
 
netdev_tx_completed_queue(txq, howmany, bytes_sent);
+   return howmany;
 }
 
 static void gfar_schedule_cleanup(struct gfar_priv_grp *gfargrp)
-- 
1.8.5.3


--
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/

[PATCH RT 0/3] Linux 3.12.15-rt26-rc1

Dear RT Folks,

The 3.12-rt kernel is entering the stable phase. But instead of
just pulling the last development version into stable, there
were a few bugs that needed to be fixed first. The 3.12.15-rt26
will go through an rc phase before it is officially released as
stable.

This is the RT stable review cycle of patch 3.12.15-rt26-rc1.

Please scream at me if I messed something up. Please test the patches too.

The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release candidate).

The pre-releases will not be pushed to the git repository, only the
final release is.

If all goes well, this patch will be converted to the next main release
on 5/2/2014.

Enjoy,

-- Steve

To build 3.12.15-rt26-rc1 directly, the following patches should be applied:

http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.12.tar.xz

http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.12.15.xz

http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.15-rt26-rc1.patch.xz

You can also build from 3.12.15-rt25 by applying the incremental patch:

http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/incr/patch-3.12.15-rt25-rt26-rc1.patch.xz

Changes from 3.12.15-rt25:

---

Steven Rostedt (1):
rt: Move migrate_disable up in trylocks

Steven Rostedt (Red Hat) (2):
net: gianfar: Fix missing return of gfar_clean_tx_ring()
Linux 3.12.15-rt26-rc1

drivers/net/ethernet/freescale/gianfar.c | 1 +
kernel/rt.c | 20
localversion-rt | 2 +-
3 files changed, 14 insertions(+), 9 deletions(-)
--
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/

[PATCH 1/2] tty/serial: add back missing setup_early_serial8250_console

2014-04-30 Thread Rob Herring

From: Rob Herring 

Commit d2fd6810a823bcd (tty/serial: convert 8250 to generic earlycon)
removed setup_early_serial8250_console, but there are still 2 callers
in:

arch/mips/mti-malta/malta-init.c
drivers/firmware/pcdp.c

Add back the function implemented as a wrapper to setup_earlycon.

Reported-by: Yinghai Lu 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
---
 drivers/tty/serial/8250/8250_early.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_early.c 
b/drivers/tty/serial/8250/8250_early.c
index e83c9db..cfef801 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -156,6 +156,16 @@ static int __init early_serial8250_setup(struct 
earlycon_device *device,
 EARLYCON_DECLARE(uart8250, early_serial8250_setup);
 EARLYCON_DECLARE(uart, early_serial8250_setup);
 
+int __init setup_early_serial8250_console(char *cmdline)
+{
+   char match[] = "uart8250";
+
+   if (cmdline && cmdline[4] == ',')
+   match[4] = '\0';
+
+   return setup_earlycon(cmdline, match, early_serial8250_setup);
+}
+
 int serial8250_find_port_for_earlycon(void)
 {
struct earlycon_device *device = early_device;
-- 
1.9.1

--
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/

[PATCH 2/2] tty/serial: fix generic earlycon option parsing

2014-04-30 Thread Rob Herring

From: Rob Herring 

Commit 9aac5887595 (tty/serial: add generic serial earlycon) moved
console option parsing from 8250_early.c and converted to kstrto*
functions from simple_strtoul along the way. However, kstrto* functions
are not equivalent in that they do not allow non-convertible characters
at the end such as "115200n8". Fix this by changing back to
simple_strtoul and ignore what checkpatch.pl says.

Reported-by: Yinghai Lu 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: linux-ser...@vger.kernel.org
---
 drivers/tty/serial/earlycon.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 73bf1e2..c92e830 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -53,7 +53,7 @@ static int __init parse_options(struct earlycon_device 
*device,
char *options)
 {
struct uart_port *port = >port;
-   int mmio, mmio32, length, ret;
+   int mmio, mmio32, length;
unsigned long addr;
 
if (!options)
@@ -64,25 +64,19 @@ static int __init parse_options(struct earlycon_device 
*device,
if (mmio || mmio32) {
port->iotype = (mmio ? UPIO_MEM : UPIO_MEM32);
options += mmio ? 5 : 7;
-   ret = kstrtoul(options, 0, );
-   if (ret)
-   return ret;
+   addr = simple_strtoul(options, NULL, 0);
port->mapbase = addr;
if (mmio32)
port->regshift = 2;
} else if (!strncmp(options, "io,", 3)) {
port->iotype = UPIO_PORT;
options += 3;
-   ret = kstrtoul(options, 0, );
-   if (ret)
-   return ret;
+   addr = simple_strtoul(options, NULL, 0);
port->iobase = addr;
mmio = 0;
} else if (!strncmp(options, "0x", 2)) {
port->iotype = UPIO_MEM;
-   ret = kstrtoul(options, 0, );
-   if (ret)
-   return ret;
+   addr = simple_strtoul(options, NULL, 0);
port->mapbase = addr;
} else {
return -EINVAL;
@@ -93,9 +87,7 @@ static int __init parse_options(struct earlycon_device 
*device,
options = strchr(options, ',');
if (options) {
options++;
-   ret = kstrtouint(options, 0, >baud);
-   if (ret)
-   return ret;
+   device->baud = simple_strtoul(options, NULL, 0);
length = min(strcspn(options, " ") + 1,
 (size_t)(sizeof(device->options)));
strlcpy(device->options, options, length);
-- 
1.9.1

--
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/

[patch] mm, thp: do not perform sync compaction on pagefault

2014-04-30 Thread David Rientjes

Synchronous memory compaction can be very expensive: it can iterate an enormous 
amount of memory without aborting and it can wait on page locks and writeback 
to 
complete if a pageblock cannot be defragmented.

Unfortunately, it's too expensive for pagefault for transparent hugepages and 
it's much better to simply fallback to pages.  On 128GB machines, we find that 
synchronous memory compaction can take O(seconds) for a single thp fault.

Signed-off-by: David Rientjes 
---
 mm/page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2656,7 +2656,7 @@ rebalance:
/* Wait for some write requests to complete then retry */
wait_iff_congested(preferred_zone, BLK_RW_ASYNC, HZ/50);
goto rebalance;
-   } else {
+   } else if (!(gfp_mask & __GFP_NO_KSWAPD)) {
/*
 * High-order allocations do not necessarily loop after
 * direct reclaim and reclaim/compaction depends on compaction
--
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/

[patch 1/2] mm, migration: add destination page freeing callback

2014-04-30 Thread David Rientjes

Memory migration uses a callback defined by the caller to determine how to
allocate destination pages.  When migration fails for a source page, however, 
it 
frees the destination page back to the system.

This patch adds a memory migration callback defined by the caller to determine 
how to free destination pages.  If a caller, such as memory compaction, builds 
its own freelist for migration targets, this can reuse already freed memory 
instead of scanning additional memory.

If the caller provides a function to handle freeing of destination pages, it is 
called when page migration fails.  Otherwise, it may pass NULL and freeing back 
to the system will be handled as usual.  This patch introduces no functional 
change.

Signed-off-by: David Rientjes 
---
 include/linux/migrate.h | 11 ++
 mm/compaction.c |  2 +-
 mm/memory-failure.c |  4 ++--
 mm/memory_hotplug.c |  2 +-
 mm/mempolicy.c  |  4 ++--
 mm/migrate.c| 54 -
 mm/page_alloc.c |  2 +-
 7 files changed, 50 insertions(+), 29 deletions(-)

diff --git a/include/linux/migrate.h b/include/linux/migrate.h
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -5,7 +5,9 @@
 #include 
 #include 
 
-typedef struct page *new_page_t(struct page *, unsigned long private, int **);
+typedef struct page *new_page_t(struct page *page, unsigned long private,
+   int **reason);
+typedef void free_page_t(struct page *page, unsigned long private);
 
 /*
  * Return values from addresss_space_operations.migratepage():
@@ -38,7 +40,7 @@ enum migrate_reason {
 extern void putback_movable_pages(struct list_head *l);
 extern int migrate_page(struct address_space *,
struct page *, struct page *, enum migrate_mode);
-extern int migrate_pages(struct list_head *l, new_page_t x,
+extern int migrate_pages(struct list_head *l, new_page_t new, free_page_t free,
unsigned long private, enum migrate_mode mode, int reason);
 
 extern int migrate_prep(void);
@@ -56,8 +58,9 @@ extern int migrate_page_move_mapping(struct address_space 
*mapping,
 #else
 
 static inline void putback_movable_pages(struct list_head *l) {}
-static inline int migrate_pages(struct list_head *l, new_page_t x,
-   unsigned long private, enum migrate_mode mode, int reason)
+static inline int migrate_pages(struct list_head *l, new_page_t new,
+   free_page_t free, unsigned long private, enum migrate_mode mode,
+   int reason)
{ return -ENOSYS; }
 
 static inline int migrate_prep(void) { return -ENOSYS; }
diff --git a/mm/compaction.c b/mm/compaction.c
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1023,7 +1023,7 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
}
 
nr_migrate = cc->nr_migratepages;
-   err = migrate_pages(>migratepages, compaction_alloc,
+   err = migrate_pages(>migratepages, compaction_alloc, NULL,
(unsigned long)cc,
cc->sync ? MIGRATE_SYNC_LIGHT : MIGRATE_ASYNC,
MR_COMPACTION);
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1500,7 +1500,7 @@ static int soft_offline_huge_page(struct page *page, int 
flags)
 
/* Keep page count to indicate a given hugepage is isolated. */
list_move(>lru, );
-   ret = migrate_pages(, new_page, MPOL_MF_MOVE_ALL,
+   ret = migrate_pages(, new_page, NULL, MPOL_MF_MOVE_ALL,
MIGRATE_SYNC, MR_MEMORY_FAILURE);
if (ret) {
pr_info("soft offline: %#lx: migration failed %d, type %lx\n",
@@ -1581,7 +1581,7 @@ static int __soft_offline_page(struct page *page, int 
flags)
inc_zone_page_state(page, NR_ISOLATED_ANON +
page_is_file_cache(page));
list_add(>lru, );
-   ret = migrate_pages(, new_page, MPOL_MF_MOVE_ALL,
+   ret = migrate_pages(, new_page, NULL, MPOL_MF_MOVE_ALL,
MIGRATE_SYNC, MR_MEMORY_FAILURE);
if (ret) {
if (!list_empty()) {
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1332,7 +1332,7 @@ do_migrate_range(unsigned long start_pfn, unsigned long 
end_pfn)
 * alloc_migrate_target should be improved!!
 * migrate_pages returns # of failed pages.
 */
-   ret = migrate_pages(, alloc_migrate_target, 0,
+   ret = migrate_pages(, alloc_migrate_target, NULL, 0,
MIGRATE_SYNC, MR_MEMORY_HOTPLUG);
if (ret)
putback_movable_pages();
diff --git a/mm/mempolicy.c

[patch 2/2] mm, compaction: return failed migration target pages back to freelist

2014-04-30 Thread David Rientjes

Memory compaction works by having a "freeing scanner" scan from one end of a 
zone which isolates pages as migration targets while another "migrating 
scanner" 
scans from the other end of the same zone which isolates pages for migration.

When page migration fails for an isolated page, the target page is returned to 
the system rather than the freelist built by the freeing scanner.  This may 
require the freeing scanner to continue scanning memory after suitable 
migration 
targets have already been returned to the system needlessly.

This patch returns destination pages to the freeing scanner freelist when page 
migration fails.  This prevents unnecessary work done by the freeing scanner 
but 
also encourages memory to be as compacted as possible at the end of the zone.

Reported-by: Greg Thelen 
Signed-off-by: David Rientjes 
---
 mm/compaction.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -797,6 +797,19 @@ static struct page *compaction_alloc(struct page 
*migratepage,
 }
 
 /*
+ * This is a migrate-callback that "frees" freepages back to the isolated
+ * freelist.  All pages on the freelist are from the same zone, so there is no
+ * special handling needed for NUMA.
+ */
+static void compaction_free(struct page *page, unsigned long data)
+{
+   struct compact_control *cc = (struct compact_control *)data;
+
+   list_add(>lru, >freepages);
+   cc->nr_freepages++;
+}
+
+/*
  * We cannot control nr_migratepages and nr_freepages fully when migration is
  * running as migrate_pages() has no knowledge of compact_control. When
  * migration is complete, we count the number of pages on the lists by hand.
@@ -1023,8 +1036,8 @@ static int compact_zone(struct zone *zone, struct 
compact_control *cc)
}
 
nr_migrate = cc->nr_migratepages;
-   err = migrate_pages(>migratepages, compaction_alloc, NULL,
-   (unsigned long)cc,
+   err = migrate_pages(>migratepages, compaction_alloc,
+   compaction_free, (unsigned long)cc,
cc->sync ? MIGRATE_SYNC_LIGHT : MIGRATE_ASYNC,
MR_COMPACTION);
update_nr_listpages(cc);
--
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: [RESEND PATCH V5 0/8] remove cpu_load idx

2014-04-30 Thread Alex Shi



于 4/25/14, 0:20, Peter Zijlstra 写道:


OK, this series is a lot saner, with the exception of 3/8 and
dependents.

I do still worry a bit for loosing the longer term view for the big
domains though. Sadly I don't have any really big machines.

I think the entire series is equivalent to setting LB_BIAS to false. So
I suppose we could do that for a while and if nobody reports horrible
things we could just do this.


Very sorry for over look this email!

Yes, it is a good idea to try false LB_BIAS first.


Anybody?


--
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 4/4 v2] rcu: Have the RCU tracepoints use the tracepoint_string infrastructure

On Wed, 30 Apr 2014 18:29:48 -0400
Sasha Levin  wrote:

> Signed-off-by: Steven Rostedt 
> 
> Hi Steven,
> 
> It seems that this patch is causing the following for me on -next kernel:

Really? This patch has been in the kernel since 3.12. Why would it
break something in linux-next. Perhaps something was added to
linux-next that doesn't like this patch?

-- Steve

> 
> [ 1202.780629] general protection fault:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 1202.782056] Dumping ftrace buffer:
> [ 1202.783243](ftrace buffer empty)
> [ 1202.784253] Modules linked in:
> [ 1202.784778] CPU: 7 PID: 65 Comm: rcuos/0 Tainted: GW 
> 3.15.0-rc3-next-201
> 40429-sasha-00015-g7c7e0a7-dirty #427
> [ 1202.787872] task: 880035c63000 ti: 880035c5c000 task.ti: 
> 880035c5c000
> [ 1202.788722] RIP: rcu_note_context_switch (include/trace/events/rcu.h:20 
> kernel/rcu/tree.c:216)
> [ 1202.790083] RSP: 0018:880035c5dcc8  EFLAGS: 00010286
> [ 1202.790468] RAX: 6b6b6b6b6b6b6b6b RBX: 880034608de8 RCX: 
> 0001
> [ 1202.790468] RDX:  RSI: a56dd9ef RDI: 
> 6b6b6b6b6b6b6b6b
> [ 1202.790468] RBP: 880035c5dce8 R08:  R09: 
> 
> [ 1202.790468] R10: 0001 R11:  R12: 
> a56dd9ef
> [ 1202.790468] R13: 0007 R14: a6aca2c3 R15: 
> 880036dd0080
> [ 1202.790468] FS:  () GS:8801ecc0() 
> knlGS:
> [ 1202.790468] CS:  0010 DS:  ES:  CR0: 8005003b
> [ 1202.790468] CR2: 0004 CR3: 25e2d000 CR4: 
> 06a0
> [ 1202.790468] DR0: 006de000 DR1: 006de000 DR2: 
> 
> [ 1202.790468] DR3:  DR6: 0ff0 DR7: 
> 0600
> [ 1202.790468] Stack:
> [ 1202.790468]   880036dd01f0 8801ecdd7840 
> 0007
> [ 1202.790468]  880035c5dd68 a4571dee 880035c5dd08 
> 880036dd01f0
> [ 1202.790468]  880035c5dfd8 001d7840 001d7840 
> 001d7840
> [ 1202.790468] Call Trace:
> [ 1202.790468] __schedule (arch/x86/include/asm/preempt.h:22 
> kernel/sched/core.c:2585 kernel/sched/core.c:2678)
> [ 1202.790468] ? prepare_to_wait_event (kernel/sched/wait.c:218 
> kernel/sched/wait.c:216)
> [ 1202.790468] schedule (kernel/sched/core.c:2765)
> [ 1202.790468] rcu_nocb_kthread (kernel/rcu/tree_plugin.h:2234 (discriminator 
> 9))
> [ 1202.790468] ? rcu_nocb_kthread (kernel/rcu/rcu.h:84 
> kernel/rcu/tree_plugin.h:2280)
> [ 1202.790468] ? preempt_count_sub (kernel/sched/core.c:2541)
> [ 1202.790468] ? bit_waitqueue (kernel/sched/wait.c:291)
> [ 1202.790468] ? rcu_cpu_notify (kernel/rcu/tree_plugin.h:2220)
> [ 1202.790468] kthread (kernel/kthread.c:210)
> [ 1202.790468] ? kthread_create_on_node (kernel/kthread.c:176)
> [ 1202.790468] ret_from_fork (arch/x86/kernel/entry_64.S:552)
> [ 1202.790468] ? kthread_create_on_node (kernel/kthread.c:176)
> [ 1202.790468] Code: 65 ff 0c 25 a0 da 00 00 0f 84 fa 00 00 00 eb 28 0f 1f 84 
> 00 00 00 00 00 48 8b 03 0f 1f 44 00 00 48 8b 7b 08 4c 89 e6 48 83 c3 10  
> d0 48 8b 03 48 85 c0 75 eb eb c9 90 44 89 ef e8 e8 71 ff ff
> [ 1202.790468] RIP rcu_note_context_switch (include/trace/events/rcu.h:20 
> kernel/rcu/tree.c:216)
> [ 1202.790468]  RSP 
> 
> 
> Thanks,
> Sasha

--
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/

[PATCHv5 RFC 11/15] hwspinlock/core: add support for reserved locks

The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.

The HwSpinlock core has been enhanced to:
  1. allow the platform implementations to register a set of 'reserved'
 locks
  2. restrict the anonymous hwspin_lock_request() API to allocate only
 from non-reserved locks
  3. limit these reserved locks to be allocated only using the
 _request_specific() API variants.

The existing platform implementations have also been updated to adjust
for the change of the registration API.

Signed-off-by: Suman Anna 
---
 drivers/hwspinlock/hwspinlock_core.c | 20 
 drivers/hwspinlock/hwspinlock_internal.h |  3 +++
 drivers/hwspinlock/omap_hwspinlock.c |  4 ++--
 drivers/hwspinlock/u8500_hsem.c  |  3 ++-
 include/linux/hwspinlock.h   | 10 +++---
 5 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c 
b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..e05cea8 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -432,6 +432,8 @@ static int hwspinlock_device_add(struct hwspinlock_device 
*bank)
  * @ops: hwspinlock handlers for this device
  * @base_id: id of the first hardware spinlock in this bank
  * @num_locks: number of hwspinlocks provided by this device
+ * @num_reserved_locks: number of reserved hwspinlocks starting from @base_id
+ * on this device
  *
  * This function should be called from the underlying platform-specific
  * implementation, to register a new hwspinlock device instance.
@@ -441,13 +443,15 @@ static int hwspinlock_device_add(struct hwspinlock_device 
*bank)
  * Returns 0 on success, or an appropriate error code on failure
  */
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
-   const struct hwspinlock_ops *ops, int base_id, int num_locks)
+   const struct hwspinlock_ops *ops, int base_id, int num_locks,
+   int num_reserved_locks)
 {
struct hwspinlock *hwlock;
int ret = 0, i;
 
if (!bank || !ops || !dev || !num_locks || !ops->trylock ||
-   !ops->unlock || (dev->of_node && !ops->of_xlate)) {
+   !ops->unlock || (dev->of_node && !ops->of_xlate) ||
+   (num_locks < num_reserved_locks)) {
pr_err("invalid parameters\n");
return -EINVAL;
}
@@ -456,6 +460,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, 
struct device *dev,
bank->ops = ops;
bank->base_id = base_id;
bank->num_locks = num_locks;
+   bank->num_reserved_locks = num_reserved_locks;
 
mutex_lock(_tree_lock);
ret = hwspinlock_device_add(bank);
@@ -468,7 +473,8 @@ int hwspin_lock_register(struct hwspinlock_device *bank, 
struct device *dev,
 
spin_lock_init(>lock);
hwlock->bank = bank;
-   hwlock->type = HWSPINLOCK_UNUSED;
+   hwlock->type = (i < num_reserved_locks ?
+   HWSPINLOCK_RESERVED : HWSPINLOCK_UNUSED);
 
ret = hwspin_lock_register_single(hwlock, base_id + i);
if (ret)
@@ -651,7 +657,13 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned 
int id)
/* sanity check (this shouldn't happen) */
WARN_ON(hwlock_to_id(hwlock) != id);
 
-   /* make sure this hwspinlock is unused */
+   if (hwlock->type != HWSPINLOCK_RESERVED) {
+   pr_warn("hwspinlock %u is not a reserved lock\n", id);
+   hwlock = NULL;
+   goto out;
+   }
+
+   /* make sure this hwspinlock is an unused reserved lock */
ret = radix_tree_tag_get(_tree, id, hwlock->type);
if (ret == 0) {
pr_warn("hwspinlock %u is already in use\n", id);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h 
b/drivers/hwspinlock/hwspinlock_internal.h
index 1be32ca..570e876 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -64,6 +64,8 @@ struct hwspinlock {
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
  * @num_locks: number of locks in this device
+ * @num_reserved_locks: number of reserved locks in this device starting
+ * from @base_id
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
@@ -72,6 +74,7 @@ struct hwspinlock_device {
const struct hwspinlock_ops *ops;
int base_id;
int num_locks;
+   int num_reserved_locks;
struct hwspinlock lock[0];
 };
 
diff --git a/drivers/hwspinlock/omap_hwspinlock.c 
b/drivers/hwspinlock/omap_hwspinlock.c
index 7764291..1d0c78e 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++

[PATCHv5 05/15] hwspinlock/omap: add support for dt nodes

HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.

Signed-off-by: Suman Anna 
[t...@atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren 
---
 MAINTAINERS  |  1 -
 arch/arm/mach-omap2/Makefile |  3 --
 arch/arm/mach-omap2/hwspinlock.c | 60 
 drivers/hwspinlock/omap_hwspinlock.c | 18 ---
 4 files changed, 14 insertions(+), 68 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/hwspinlock.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e67ea24..5147902 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6355,7 +6355,6 @@ M:Ohad Ben-Cohen 
 L: linux-o...@vger.kernel.org
 S: Maintained
 F: drivers/hwspinlock/omap_hwspinlock.c
-F: arch/arm/mach-omap2/hwspinlock.c
 
 OMAP MMC SUPPORT
 M: Jarkko Lavinen 
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8421f38..9f4b6dd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -289,9 +289,6 @@ obj-y   += $(smc91x-m) 
$(smc91x-y)
 
 smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
 obj-y  += $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y  += hwspinlock.o
-endif
 
 emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
 obj-y  += $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175ac..000
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que 
- *  Hari Kanigeri 
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include "soc.h"
-#include "omap_hwmod.h"
-#include "omap_device.h"
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
-   .base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
-   int retval = 0;
-   struct omap_hwmod *oh;
-   struct platform_device *pdev;
-   const char *oh_name = "spinlock";
-   const char *dev_name = "omap_hwspinlock";
-
-   /*
-* Hwmod lookup will fail in case our platform doesn't support the
-* hardware spinlock module, so it is safe to run this initcall
-* on all omaps
-*/
-   oh = omap_hwmod_lookup(oh_name);
-   if (oh == NULL)
-   return -EINVAL;
-
-   pdev = omap_device_build(dev_name, 0, oh, _hwspinlock_pdata,
-   sizeof(struct hwspinlock_pdata));
-   if (IS_ERR(pdev)) {
-   pr_err("Can't build omap_device for %s:%s\n", dev_name,
-   oh_name);
-   retval = PTR_ERR(pdev);
-   }
-
-   return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c 
b/drivers/hwspinlock/omap_hwspinlock.c
index 292869c..9f56fb2 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
 /*
  * OMAP hardware spinlock driver
  *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2014 Texas Instruments Incorporated - http://www.ti.com
  *
  * Contact: Simon Que 
  *  Hari Kanigeri 
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "hwspinlock_internal.h"
@@ -76,18 +77,20 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
.trylock = omap_hwspinlock_trylock,
.unlock = omap_hwspinlock_unlock,
.relax = omap_hwspinlock_relax,
+   .of_xlate = of_hwspin_lock_simple_xlate,
 };
 
 static int omap_hwspinlock_probe(struct platform_device *pdev)
 {
-   struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
+   struct device_node *node = pdev->dev.of_node;
struct hwspinlock_device *bank;
struct hwspinlock *hwlock;
struct resource *res;
void __iomem *io_base;
int num_locks, i, ret;
+   int base_id = 0;
 
-   if (!pdata)
+   if (!node)

[PATCHv5 RFC 14/15] hwspinlock/core: return ERR_PTRs on failure in _request_ api

The various hwspin_lock_request* interfaces return a NULL pointer
on error, or a valid hwlock pointer on success. It is standard
practice to pass the error value back to the consumers on failure
cases, so change the functions to return an equivalent ERR_PTR()
value instead of NULL. The regular client api functions are
also modified to check for an invalid hwlock handle.

The consumers MUST check using IS_ERR() when requesting hwlocks
going forward to determine a valid hwlock.

Signed-off-by: Suman Anna 
---
TODO: Move this patch before the Patch4,
"hwspinlock/core: add common OF helpers"
if accepted to go with the current series
---
 Documentation/hwspinlock.txt | 12 ++--
 drivers/hwspinlock/hwspinlock_core.c | 25 ++---
 2 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 903d477..bf1c7e46 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -35,15 +35,15 @@ independent, drivers.
 2. User API
 
   struct hwspinlock *hwspin_lock_request(void);
-   - dynamically assign an hwspinlock and return its address, or NULL
- in case an unused hwspinlock isn't available. Users of this
+   - dynamically assign a hwspinlock and return its address, or an equivalent
+ ERR_PTR() in case an unused hwspinlock isn't available. Users of this
  API will usually want to communicate the lock's id to the remote core
  before it can be used to achieve synchronization.
  Should be called from a process context (might sleep).
 
   struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
-   - assign a specific hwspinlock id and return its address, or NULL
- if that hwspinlock is already in use. Usually board code will
+   - assign a specific hwspinlock id and return its address, or an equivalent
+ ERR_PTR() if that hwspinlock is already in use. Usually board code will
  be calling this function in order to reserve specific hwspinlock
  ids for predefined purposes.
  Should be called from a process context (might sleep).
@@ -172,7 +172,7 @@ int hwspinlock_example1(void)
 
/* dynamically assign a hwspinlock */
hwlock = hwspin_lock_request();
-   if (!hwlock)
+   if (IS_ERR(hwlock))
...
 
id = hwspin_lock_get_id(hwlock);
@@ -208,7 +208,7 @@ int hwspinlock_example2(void)
 * by board init code.
 */
hwlock = hwspin_lock_request_specific(PREDEFINED_LOCK_ID);
-   if (!hwlock)
+   if (IS_ERR(hwlock))
...
 
/* try to take it, but don't spin on it */
diff --git a/drivers/hwspinlock/hwspinlock_core.c 
b/drivers/hwspinlock/hwspinlock_core.c
index e74b55b..56c4303 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -96,7 +96,7 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int mode, 
unsigned long *flags)
 {
int ret;
 
-   BUG_ON(!hwlock);
+   BUG_ON(IS_ERR_OR_NULL(hwlock));
BUG_ON(!flags && mode == HWLOCK_IRQSTATE);
 
/*
@@ -235,7 +235,7 @@ EXPORT_SYMBOL_GPL(__hwspin_lock_timeout);
  */
 void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 {
-   BUG_ON(!hwlock);
+   BUG_ON(IS_ERR_OR_NULL(hwlock));
BUG_ON(!flags && mode == HWLOCK_IRQSTATE);
 
/*
@@ -600,7 +600,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
  */
 int hwspin_lock_get_id(struct hwspinlock *hwlock)
 {
-   if (!hwlock) {
+   if (IS_ERR_OR_NULL(hwlock)) {
pr_err("invalid hwlock\n");
return -EINVAL;
}
@@ -620,7 +620,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_get_id);
  *
  * Should be called from a process context (might sleep)
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent ERR_PTR()
+ * on error
  */
 struct hwspinlock *hwspin_lock_request(void)
 {
@@ -634,7 +635,7 @@ struct hwspinlock *hwspin_lock_request(void)
0, 1, HWSPINLOCK_UNUSED);
if (ret == 0) {
pr_warn("a free hwspinlock is not available\n");
-   hwlock = NULL;
+   hwlock = ERR_PTR(-ENXIO);
goto out;
}
 
@@ -644,7 +645,7 @@ struct hwspinlock *hwspin_lock_request(void)
/* mark as used and power up */
ret = __hwspin_lock_request(hwlock);
if (ret < 0)
-   hwlock = NULL;
+   hwlock = ERR_PTR(ret);
 
 out:
mutex_unlock(_tree_lock);
@@ -663,7 +664,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request);
  *
  * Should be called from a process context (might sleep)
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent
+ * ERR_PTR() on error
  */
 struct hwspinlock *hwspin_lock_request_specific(unsigned

[PATCHv5 RFC 15/15] hwspinlock/core: change return codes of_hwspin_lock_request_specific

Changed the return statements to return an ERR_PTR instead of NULL
in case of an error. This patch helps with deferred probing of any
client users if the corresponding hwspinlock bank is not yet registered
with the hwspinlock core.

Signed-off-by: Suman Anna 
---
TODO: Collapse into Patch4,
 "hwspinlock/core: add common OF helpers"
if accepted to go with the current series
---
 Documentation/hwspinlock.txt | 4 ++--
 drivers/hwspinlock/hwspinlock_core.c | 9 +
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index bf1c7e46..10d7ecc 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -50,8 +50,8 @@ independent, drivers.
 
   struct hwspinlock *of_hwspin_lock_request_specific(
struct device_node *np, const char *propname, int index);
-   - assign a specific hwspinlock id and return its address, or NULL
- if that hwspinlock is already in use. This function is the OF
+   - assign a specific hwspinlock id and return its address, or an equivalent
+ ERR_PTR() if that hwspinlock is already in use. This function is the OF
  equivalent of hwspin_lock_request_specific() function, and provides
  a means for users of the hwspinlock module to request a specific
  hwspinlock using the phandle of the hwspinlock device.
diff --git a/drivers/hwspinlock/hwspinlock_core.c 
b/drivers/hwspinlock/hwspinlock_core.c
index 56c4303..a838dbd 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -722,7 +722,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request_specific);
  * lock number is indexed relative to the hwspinlock device, unlike the
  * hwspin_lock_request_specific() which is an absolute lock number.
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent
+ * ERR_PTR() on error
  */
 struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
   const char *propname,
@@ -736,7 +737,7 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct 
device_node *np,
ret = of_parse_phandle_with_args(np, propname, "#hwlock-cells", index,
 );
if (ret)
-   return NULL;
+   return ERR_PTR(ret);
 
mutex_lock(_tree_lock);
list_for_each_entry(bank, _devices, list)
@@ -744,11 +745,11 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct 
device_node *np,
break;
mutex_unlock(_tree_lock);
if (>list == _devices)
-   return NULL;
+   return ERR_PTR(-EPROBE_DEFER);
 
id = bank->ops->of_xlate(bank, );
if (id < 0 || id >= bank->num_locks)
-   return NULL;
+   return ERR_PTR(-EINVAL);
 
id += bank->base_id;
return hwspin_lock_request_specific(id);
-- 
1.9.2

--
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/

[PATCHv5 RFC 13/15] hwspinlock/omap: use OF helper to get reserved locks

Retrieve the number of reserved locks for OMAP by using the
of_hwspin_lock_get_num_reserved_locks() OF helper function
provided by the hwspinlock core. The range sanity check will
be performed by the hwspinlock core during the registration.

Signed-off-by: Suman Anna 
---
 drivers/hwspinlock/omap_hwspinlock.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/hwspinlock/omap_hwspinlock.c 
b/drivers/hwspinlock/omap_hwspinlock.c
index 1d0c78e..0dad783 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -143,6 +143,12 @@ static int omap_hwspinlock_probe(struct platform_device 
*pdev)
for (i = 0, hwlock = >lock[0]; i < num_locks; i++, hwlock++)
hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
+   reserved_locks = of_hwspin_lock_get_num_reserved_locks(node);
+   if (reserved_locks < 0) {
+   ret = -EINVAL;
+   goto iounmap_base;
+   }
+
ret = hwspin_lock_register(bank, >dev, _hwspinlock_ops,
base_id, num_locks, reserved_locks);
if (ret)
-- 
1.9.2

--
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/

[PATCHv5 RFC 10/15] hwspinlock/core: prepare core to support reserved locks

The HwSpinlock core allows requesting either a specific lock or
an available normal lock. The specific locks are usually reserved
during board init time, while the normal available locks are
intended to be assigned at runtime.

This patch prepares the hwspinlock core to support this concept
of reserved locks. A new element is added to struct hwlock to
identify whether it is reserved to be allocated using the
hwspin_lock_request_specific() variants or available for dynamic
allocation. A new tag name, HWSPINLOCK_RESERVED, is introduced
to mark the reserved locks as such.

Signed-off-by: Suman Anna 
---
 drivers/hwspinlock/hwspinlock_core.c | 14 --
 drivers/hwspinlock/hwspinlock_internal.h |  2 ++
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c 
b/drivers/hwspinlock/hwspinlock_core.c
index ed47e77..c2063bc 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -33,6 +33,7 @@
 
 /* radix tree tags */
 #define HWSPINLOCK_UNUSED  (0) /* tags an hwspinlock as unused */
+#define HWSPINLOCK_RESERVED(1) /* tags an hwspinlock as reserved */
 
 /*
  * A radix tree is used to maintain the available hwspinlock instances.
@@ -326,7 +327,7 @@ static int hwspin_lock_register_single(struct hwspinlock 
*hwlock, int id)
}
 
/* mark this hwspinlock as available */
-   tmp = radix_tree_tag_set(_tree, id, HWSPINLOCK_UNUSED);
+   tmp = radix_tree_tag_set(_tree, id, hwlock->type);
 
/* self-sanity check which should never fail */
WARN_ON(tmp != hwlock);
@@ -344,7 +345,7 @@ static int hwspin_lock_unregister_single(struct hwspinlock 
*hwlock, int id)
mutex_lock(_tree_lock);
 
/* make sure the hwspinlock is not in use (tag is set) */
-   if (!radix_tree_tag_get(_tree, id, HWSPINLOCK_UNUSED)) {
+   if (!radix_tree_tag_get(_tree, id, hwlock->type)) {
pr_err("hwspinlock %d still in use (or not present)\n", id);
ret = -EBUSY;
goto out;
@@ -467,6 +468,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, 
struct device *dev,
 
spin_lock_init(>lock);
hwlock->bank = bank;
+   hwlock->type = HWSPINLOCK_UNUSED;
 
ret = hwspin_lock_register_single(hwlock, base_id + i);
if (ret)
@@ -551,7 +553,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
 
/* mark hwspinlock as used, should not fail */
tmp = radix_tree_tag_clear(_tree, hwlock_to_id(hwlock),
-   HWSPINLOCK_UNUSED);
+   hwlock->type);
 
/* self-sanity check that should never fail */
WARN_ON(tmp != hwlock);
@@ -650,7 +652,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned 
int id)
WARN_ON(hwlock_to_id(hwlock) != id);
 
/* make sure this hwspinlock is unused */
-   ret = radix_tree_tag_get(_tree, id, HWSPINLOCK_UNUSED);
+   ret = radix_tree_tag_get(_tree, id, hwlock->type);
if (ret == 0) {
pr_warn("hwspinlock %u is already in use\n", id);
hwlock = NULL;
@@ -741,7 +743,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 
/* make sure the hwspinlock is used */
ret = radix_tree_tag_get(_tree, hwlock_to_id(hwlock),
-   HWSPINLOCK_UNUSED);
+   hwlock->type);
if (ret == 1) {
dev_err(dev, "%s: hwlock is already free\n", __func__);
dump_stack();
@@ -756,7 +758,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 
/* mark this hwspinlock as available */
tmp = radix_tree_tag_set(_tree, hwlock_to_id(hwlock),
-   HWSPINLOCK_UNUSED);
+   hwlock->type);
 
/* sanity check (this shouldn't happen) */
WARN_ON(tmp != hwlock);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h 
b/drivers/hwspinlock/hwspinlock_internal.h
index 5e42613..1be32ca 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -47,11 +47,13 @@ struct hwspinlock_ops {
  * struct hwspinlock - this struct represents a single hwspinlock instance
  * @bank: the hwspinlock_device structure which owns this lock
  * @lock: initialized and used by hwspinlock core
+ * @type: type of lock, used to distinguish regular locks from reserved locks
  * @priv: private data, owned by the underlying platform-specific hwspinlock 
drv
  */
 struct hwspinlock {
struct hwspinlock_device *bank;
spinlock_t lock;
+   unsigned int type;
void *priv;
 };
 
-- 
1.9.2

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

[PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks

The property 'hwlock-reserved-locks' will be used to represent
the number of locks to be reserved for clients that would need
to request/operate on specific locks. A new OF helper function,
of_hwspin_lock_get_num_reserved_locks(), is added to minimize
duplication in different platform implementations.

The function will return a value of 0 if the property is not
defined, so as to support a default behavior of marking all
locks as unused and open for anonymous allocations.

Signed-off-by: Suman Anna 
---
 .../devicetree/bindings/hwlock/hwlock.txt  |  3 +++
 drivers/hwspinlock/hwspinlock_core.c   | 25 ++
 include/linux/hwspinlock.h |  1 +
 3 files changed, 29 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt 
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index d538a9b..88d16d2 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,9 @@ Common properties:
property is needed on hwlock devices, where the number
of supported locks within a hwlock device cannot be
read from a register.
+- hwlock-reserved-locks: Number of locks to reserve for clients requiring
+   specific locks. This value cannot exceed the value of
+   hwlock-num-locks.
 - hwlock-base-id:  An unique base Id for the locks for a particular hwlock
device. This property is mandatory ONLY if a SoC has
several hwlock devices.
diff --git a/drivers/hwspinlock/hwspinlock_core.c 
b/drivers/hwspinlock/hwspinlock_core.c
index e05cea8..e74b55b 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -286,6 +286,31 @@ int of_hwspin_lock_get_base_id(struct device_node *dn)
 EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
 
 /**
+ * of_hwspin_lock_get_num_reserved_locks() - retrieve number of reserved locks
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying platform
+ * specific implementations, to retrieve the number of locks to reserve from
+ * the hwspinlock device instance's base id. The hwlock-reserved-locks DT
+ * property needs to be defined for requesting any DT-based locks.
+ *
+ * Returns a positive number of locks on success, a default value of 0 if the
+ * property is missing or an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn)
+{
+   unsigned int val = 0;
+   int ret;
+
+   ret = of_property_read_u32(dn, "hwlock-reserved-locks", );
+   if (!ret || ret == -EINVAL)
+   ret = val;
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_reserved_locks);
+
+/**
  * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
  * @dn: device node pointer
  *
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index d120035..d18431f 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -69,6 +69,7 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device 
*bank,
const struct of_phandle_args *hwlock_spec);
 int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
const struct hwspinlock_ops *ops, int base_id, int num_locks,
int num_reserved_locks);
-- 
1.9.2

--
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/

[PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx

HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
device families as well. The IPs are identical to that of
OMAP4/OMAP5, except for the number of locks.

Add a depends on to the above family of SoCs to enable the
build support for OMAP hwspinlock driver for any of the above
SoC configs.

Signed-off-by: Suman Anna 
---
 drivers/hwspinlock/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 70637d2..3612cb5 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -10,7 +10,7 @@ menu "Hardware Spinlock drivers"
 
 config HWSPINLOCK_OMAP
tristate "OMAP Hardware Spinlock device"
-   depends on ARCH_OMAP4 || SOC_OMAP5
+   depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || 
SOC_AM43XX
select HWSPINLOCK
help
  Say y here to support the OMAP Hardware Spinlock device (firstly
-- 
1.9.2

--
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/

[PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register

The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.

This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.

Signed-off-by: Suman Anna 
---
 drivers/hwspinlock/omap_hwspinlock.c | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/hwspinlock/omap_hwspinlock.c 
b/drivers/hwspinlock/omap_hwspinlock.c
index 9f56fb2..7764291 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -101,10 +101,29 @@ static int omap_hwspinlock_probe(struct platform_device 
*pdev)
if (!io_base)
return -ENOMEM;
 
+   /*
+* make sure the module is enabled and clocked before reading
+* the module SYSSTATUS register
+*/
+   pm_runtime_enable(>dev);
+   ret = pm_runtime_get_sync(>dev);
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
+   goto iounmap_base;
+   }
+
/* Determine number of locks */
i = readl(io_base + SYSSTATUS_OFFSET);
i >>= SPINLOCK_NUMLOCKS_BIT_OFFSET;
 
+   /*
+* runtime PM will make sure the clock of this module is
+* enabled again iff at least one lock is requested
+*/
+   ret = pm_runtime_put_sync(>dev);
+   if (ret < 0)
+   goto iounmap_base;
+
/* one of the four lsb's must be set, and nothing else */
if (hweight_long(i & 0xf) != 1 || i > 8) {
ret = -EINVAL;
@@ -124,12 +143,6 @@ static int omap_hwspinlock_probe(struct platform_device 
*pdev)
for (i = 0, hwlock = >lock[0]; i < num_locks; i++, hwlock++)
hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
-   /*
-* runtime PM will make sure the clock of this module is
-* enabled iff at least one lock is requested
-*/
-   pm_runtime_enable(>dev);
-
ret = hwspin_lock_register(bank, >dev, _hwspinlock_ops,
base_id, num_locks);
if (ret)
@@ -138,9 +151,9 @@ static int omap_hwspinlock_probe(struct platform_device 
*pdev)
return 0;
 
 reg_fail:
-   pm_runtime_disable(>dev);
kfree(bank);
 iounmap_base:
+   pm_runtime_disable(>dev);
iounmap(io_base);
return ret;
 }
-- 
1.9.2

--
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/

[PATCHv5 RFC 09/15] hwspinlock/core: prepare unregister code to support reserved locks

Rearrange the code between hwspin_lock_unregister() and the underlying
hwspin_lock_unregister_single() functions so that the semantics are
similar to the _register_ functions. This change prepares the hwspinlock
driver core to support unregistration of reserved locks better.

Signed-off-by: Suman Anna 
---
 drivers/hwspinlock/hwspinlock_core.c | 37 +++-
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c 
b/drivers/hwspinlock/hwspinlock_core.c
index 4be1664..ed47e77 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -336,29 +336,33 @@ out:
return 0;
 }
 
-static struct hwspinlock *hwspin_lock_unregister_single(unsigned int id)
+static int hwspin_lock_unregister_single(struct hwspinlock *hwlock, int id)
 {
-   struct hwspinlock *hwlock = NULL;
-   int ret;
+   struct hwspinlock *tmp = NULL;
+   int ret = 0;
 
mutex_lock(_tree_lock);
 
/* make sure the hwspinlock is not in use (tag is set) */
-   ret = radix_tree_tag_get(_tree, id, HWSPINLOCK_UNUSED);
-   if (ret == 0) {
+   if (!radix_tree_tag_get(_tree, id, HWSPINLOCK_UNUSED)) {
pr_err("hwspinlock %d still in use (or not present)\n", id);
+   ret = -EBUSY;
goto out;
}
 
-   hwlock = radix_tree_delete(_tree, id);
-   if (!hwlock) {
+   tmp = radix_tree_delete(_tree, id);
+   if (!tmp) {
pr_err("failed to delete hwspinlock %d\n", id);
+   ret = -EIO;
goto out;
}
 
+   /* self-sanity check that should never fail */
+   WARN_ON(tmp != hwlock);
+
 out:
mutex_unlock(_tree_lock);
-   return hwlock;
+   return ret;
 }
 
 /**
@@ -472,8 +476,10 @@ int hwspin_lock_register(struct hwspinlock_device *bank, 
struct device *dev,
return 0;
 
 reg_failed:
-   while (--i >= 0)
-   hwspin_lock_unregister_single(base_id + i);
+   while (--i >= 0) {
+   hwlock =  >lock[i];
+   hwspin_lock_unregister_single(hwlock, base_id + i);
+   }
mutex_lock(_tree_lock);
list_del(>list);
mutex_unlock(_tree_lock);
@@ -494,18 +500,15 @@ EXPORT_SYMBOL_GPL(hwspin_lock_register);
  */
 int hwspin_lock_unregister(struct hwspinlock_device *bank)
 {
-   struct hwspinlock *hwlock, *tmp;
-   int i;
+   struct hwspinlock *hwlock;
+   int i, ret;
 
for (i = 0; i < bank->num_locks; i++) {
hwlock = >lock[i];
 
-   tmp = hwspin_lock_unregister_single(bank->base_id + i);
-   if (!tmp)
+   ret = hwspin_lock_unregister_single(hwlock, bank->base_id + i);
+   if (ret)
return -EBUSY;
-
-   /* self-sanity check that should never fail */
-   WARN_ON(tmp != hwlock);
}
 
mutex_lock(_tree_lock);
-- 
1.9.2

--
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/

[PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT

The HwSpinlock core requires a base id for registering a bank
of hwspinlocks. This base id needs to be unique across multiple
IP instances of a hwspinlock device, so that each hwlock can be
represented uniquely in a system.

Support has been added to represent this in DT through a common
property 'hwlock-base-id', and retrieve the value through a core
OF helper function, of_hwspin_lock_get_base_id(). The representation
in DT provides a uniform way of assigning a fixed base value for a
hwspinlock device across different SoCs.

Signed-off-by: Suman Anna 
---
 Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++
 drivers/hwspinlock/hwspinlock_core.c| 21 +
 include/linux/hwspinlock.h  |  1 +
 3 files changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt 
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index 32381cc..d538a9b 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,12 @@ Common properties:
property is needed on hwlock devices, where the number
of supported locks within a hwlock device cannot be
read from a register.
+- hwlock-base-id:  An unique base Id for the locks for a particular hwlock
+   device. This property is mandatory ONLY if a SoC has
+   several hwlock devices.
+
+   See documentation on struct hwspinlock_pdata in
+   include/linux/hwspinlock.h for more details.
 
 Hwlock Users:
 =
diff --git a/drivers/hwspinlock/hwspinlock_core.c 
b/drivers/hwspinlock/hwspinlock_core.c
index 3966c0c..4be1664 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -264,6 +264,27 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode, 
unsigned long *flags)
 EXPORT_SYMBOL_GPL(__hwspin_unlock);
 
 /**
+ * of_hwspin_lock_get_base_id() - OF helper to retrieve base id
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the base id for the
+ * set of locks present within a hwspinlock device instance.
+ *
+ * Returns the base id value on success, or an appropriate error code
+ * as returned by the OF layer
+ */
+int of_hwspin_lock_get_base_id(struct device_node *dn)
+{
+   unsigned int val;
+   int ret;
+
+   ret = of_property_read_u32(dn, "hwlock-base-id", );
+   return ret ? ret : val;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
+
+/**
  * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
  * @dn: device node pointer
  *
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 068e628..4857728 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -64,6 +64,7 @@ struct hwspinlock_pdata {
 
 int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
const struct of_phandle_args *hwlock_spec);
+int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
const struct hwspinlock_ops *ops, int base_id, int num_locks);
-- 
1.9.2

--
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/

[PATCHv5 02/15] Documentation: dt: add the omap hwspinlock bindings document

HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.

Cc: Rob Herring 
Signed-off-by: Suman Anna 
---
 .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt

diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt 
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 000..568eae2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,24 @@
+OMAP4+ HwSpinlock Driver
+
+
+Required properties:
+- compatible:  Should be "ti,omap4-hwspinlock" for
+   OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the hwspinlock module register address space
+   (base address and length)
+- ti,hwmods:   Name of the hwmod associated with the hwspinlock device
+- #hwlock-cells:   Should be 1. The OMAP hwspinlock users will use a
+   0-indexed relative hwlock number as the argument
+   specifier value for requesting a specific hwspinlock
+   within a hwspinlock bank.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+   compatible = "ti,omap4-hwspinlock";
+   reg = <0x4a0f6000 0x1000>;
+   ti,hwmods = "spinlock";
+   #hwlock-cells = <1>;
+};
-- 
1.9.2

--
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/

[PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks

The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify the bank of locks. The core does not
maintain the hwspinlock_devices itself, but maintains only a radix
tree for all the registered locks. A specific lock can be requested
by users using a global lock id, and any device-specific fields
can be retrieved through a reference to the hwspinlock_device in
each lock.

The global lock id, however, is not friendly to be requested for
users using the device-tree model. The device-tree representation
will typically have each of the hwspinlock devices represented as
a DT node, and a specific lock can be requested using the device's
phandle and a lock specifier. Add support to the core therefore to
maintain all the registered hwspinlock_devices, so that a device
can be looked up and a specific lock belonging to the device
requested through a phandle + args approach.

Signed-off-by: Suman Anna 
---
 Documentation/hwspinlock.txt |  2 ++
 drivers/hwspinlock/hwspinlock_core.c | 51 
 drivers/hwspinlock/hwspinlock_internal.h |  2 ++
 3 files changed, 55 insertions(+)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 62f7d4e..640ae47 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -251,6 +251,7 @@ implementation using the hwspin_lock_register() API.
 
 /**
  * struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
  * @dev: underlying device, will be used to invoke runtime PM api
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
@@ -258,6 +259,7 @@ implementation using the hwspin_lock_register() API.
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
+   struct list_head list;
struct device *dev;
const struct hwspinlock_ops *ops;
int base_id;
diff --git a/drivers/hwspinlock/hwspinlock_core.c 
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..48f7866 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -59,6 +59,11 @@ static RADIX_TREE(hwspinlock_tree, GFP_KERNEL);
  */
 static DEFINE_MUTEX(hwspinlock_tree_lock);
 
+/*
+ * A linked list for maintaining all the registered hwspinlock devices.
+ * The list is maintained in an ordered-list of the supported locks group.
+ */
+static LIST_HEAD(hwspinlock_devices);
 
 /**
  * __hwspin_trylock() - attempt to lock a specific hwspinlock
@@ -307,6 +312,40 @@ out:
return hwlock;
 }
 
+/*
+ * Add a new hwspinlock device to the global list, keeping the list of
+ * devices sorted by base order.
+ *
+ * Returns 0 on success, or -EBUSY if the new device overlaps with some
+ * other device's lock space.
+ */
+static int hwspinlock_device_add(struct hwspinlock_device *bank)
+{
+   struct list_head *entry = _devices;
+   struct hwspinlock_device *_bank;
+   int ret = 0;
+
+   list_for_each(entry, _devices) {
+   _bank = list_entry(entry, struct hwspinlock_device, list);
+   if (_bank->base_id >= bank->base_id + bank->num_locks)
+   break;
+   }
+
+   if (entry != _devices &&
+   entry->prev != _devices) {
+   _bank = list_entry(entry->prev, struct hwspinlock_device, list);
+   if (_bank->base_id + _bank->num_locks > bank->base_id) {
+   dev_err(bank->dev, "hwlock space overlap, cannot add 
device\n");
+   ret = -EBUSY;
+   }
+   }
+
+   if (!ret)
+   list_add_tail(>list, entry);
+
+   return ret;
+}
+
 /**
  * hwspin_lock_register() - register a new hw spinlock device
  * @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -339,6 +378,12 @@ int hwspin_lock_register(struct hwspinlock_device *bank, 
struct device *dev,
bank->base_id = base_id;
bank->num_locks = num_locks;
 
+   mutex_lock(_tree_lock);
+   ret = hwspinlock_device_add(bank);
+   mutex_unlock(_tree_lock);
+   if (ret)
+   return ret;
+
for (i = 0; i < num_locks; i++) {
hwlock = >lock[i];
 
@@ -355,6 +400,9 @@ int hwspin_lock_register(struct hwspinlock_device *bank, 
struct device *dev,
 reg_failed:
while (--i >= 0)
hwspin_lock_unregister_single(base_id + i);
+   mutex_lock(_tree_lock);
+   list_del(>list);
+   mutex_unlock(_tree_lock);
return ret;
 }
 EXPORT_SYMBOL_GPL(hwspin_lock_register);
@@ -386,6 +434,9 @@ int hwspin_lock_unregister(struct hwspinlock_device *bank)
WARN_ON(tmp != hwlock);
}
 
+   mutex_lock(_tree_lock);
+   list_del(>list);
+   mutex_unlock(_tree_lock);
return 0;
 }

[PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock

This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.

All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. The number of locks
is represented by 'hwlock-num-locks' property in DT bindings. A
property for base id is not needed in DT binding, as it can be
satisfied using a phandle + args specifier. The args specifier
length is dependent on each vendor-specific implementation and
is represented through the '#hwlock-cells' property.

Note that the document is named hwlock.txt deliberately to keep it
a bit more generic.

Cc: Rob Herring 
Signed-off-by: Suman Anna 
---
 .../devicetree/bindings/hwlock/hwlock.txt  | 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt 
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index 000..32381cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,52 @@
+Generic hwlock bindings
+===
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations, the retrieved values are used for registering the device
+specific parameters with the hwspinlock core.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if a property is mandatory or optional. Please look through the
+individual platform specific hwlock binding documentations for identifying
+the applicable properties.
+
+Common properties:
+- #hwlock-cells:   Specifies the number of cells needed to represent a
+   specific lock.
+- hwlock-num-locks:Number of locks present in a hwlock device. This
+   property is needed on hwlock devices, where the number
+   of supported locks within a hwlock device cannot be
+   read from a register.
+
+Hwlock Users:
+=
+
+Nodes that require specific hwlock(s) should specify them using one or more
+properties, each containing a phandle to the hwlock node and an args specifier
+value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
+an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+   node {
+   ...
+   hwlocks = < 2>;
+   ...
+   };
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
+
+   node {
+   ...
+   hwlocks = < 2>, < 0 3>;
+   ...
+   };
-- 
1.9.2

--
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/

[PATCHv5 00/15] hwspinlock/omap dt support

Hi Ohad,

This is a refresh/update of the hwspinlock dt support series. The
series is rebased onto v3.15-rc3, and adds 8 new patches (RFC) to
handle various discussion points arised on v4.

Following are the main changes in v5:
- Base DT patches (Patches 1 to 7, except for 4) are identical to v4.
  Patch4 is updated to remove some traces and fix --strict checkpatch warnings.
- Patch 8 brings back the DT-based hwlock-base-id property, for registration
  purposes. Based on v4 discussion [1].
- Patches 9 through 13 introduce the concept of reserved locks, again based
  on the discussion in v4 [1]. The approach taken here is simplistic, each
  hwlock is assigned a type attribute during registration, with the _request_
  apis honoring the lock type attribute.
- Staged patches 14 & 15 for converting return convention to better
  support deferred probing of client drivers. I do think that it is
  still a good idea to return ERR_PTRs (unconcluded discussion in v4 [2]).
  The main advantage is to support deferred probing for DT boots. The
  original argument/change for returning NULL pointers pre-dates both
  the deferred driver probe mechanism and DT-based boot, so it may be
  moot on the current kernel.

I have marked the new patches as RFC, and should ideally be dealt
with as a separate series. I have added these to this series as
they also add couple of DT-based properties, as well as maintain the
discussion context from the previous series. I am ok for the reserved
lock patches to be left out for 3.16 merge window if these patches still
need some work. I am hoping to have the first 7 or 8 patches (and
finalized return code changes) to make it to 3.16.

The validation logs on all the applicable OMAP SoCs are at:
  OMAP4  - http://slexy.org/view/s2MMyLZTiH 
  OMAP5  - http://slexy.org/view/s20U2ElygK 
  DRA74x - http://slexy.org/view/s20fAoWJ84
  AM33xx - http://slexy.org/view/s2HLj2b406 
  AM43xx - http://slexy.org/view/s2JNrJSWLm 

The above logs are generated with some additional test patches staged
here for reference (not for merging)
https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5
https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5-test

regards
Suman

[1] http://marc.info/?l=linux-omap=139510004009415=2
[2] http://marc.info/?l=linux-omap=139490475424338=2

---
v4:
- The DT bindings are split into separate patches, and updated to
  add comments about #hwlock-cells
- Fixed a registration issue with repeated module installation and
  removal.
- Added a new OF helper to support #hwlock-cells in addition to the
  previous OF functions. The OMAP adaptation patch is updated to use
  the default translate function
- Updated hwspinlock documentation to adjust for the structure
  changes and the new api additions.
- Added build support for AM335x, AM43xx and DRA7xx
http://marc.info/?l=linux-omap=138965904015225=2

v3:
- Removed the DT property hwlock-base-id and associated OF helper
- Added changes in core to support requesting a specific hwlock using
  phandle + args approach
- Revised both the common and OMAP DT bindings document
http://marc.info/?l=linux-omap=138143992932197=2

v2:
- Added a new common DT binding documentation and OF helpers.
- Revised OMAP DT parse support to use the new OF helper (Patch2)
- OMAP5 hwspinlock support including the hwmod entry and DT node
- Add AM335x support to OMAP hwspinlock driver, including a fix
  needed in driver given that AM335 spinlock module requires s/w wakeup
- AM335 DT node for spinlock, and a hwmod change to enable smart-idle
  for AM335.
- OMAP4 DT node patch is unchanged
http://marc.info/?l=linux-omap=137944644112727=2

v1:
- Add DT parse support to OMAP hwspinlock driver
- Add OMAP4 DT node and bindings information
http://marc.info/?l=linux-omap=137823082308009=2

---

Suman Anna (15):
  Documentation: dt: add common bindings for hwspinlock
  Documentation: dt: add the omap hwspinlock bindings document
  hwspinlock/core: maintain a list of registered hwspinlock banks
  hwspinlock/core: add common OF helpers
  hwspinlock/omap: add support for dt nodes
  hwspinlock/omap: enable module before reading SYSSTATUS register
  hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
  hwspinlock/core: add support for base id in DT
  hwspinlock/core: prepare unregister code to support reserved locks
  hwspinlock/core: prepare core to support reserved locks
  hwspinlock/core: add support for reserved locks
  hwspinlock/core: add OF helper to parse reserved locks
  hwspinlock/omap: use OF helper to get reserved locks
  hwspinlock/core: return ERR_PTRs on failure in _request_ api
  hwspinlock/core: change return codes of_hwspin_lock_request_specific

 .../devicetree/bindings/hwlock/hwlock.txt  |  61 +
 .../devicetree/bindings/hwlock/omap-hwspinlock.txt |  24 ++
 Documentation/hwspinlock.txt   |  48 +++-
 MAINTAINERS|   1 -
 arch/arm/mach-omap2/Makefile

[PATCHv5 04/15] hwspinlock/core: add common OF helpers

This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.

1. The of_hwspin_lock_get_num_locks() is a common helper
   function to read the common 'hwlock-num-locks' property.
2. The of_hwspin_lock_simple_xlate() is a simple default
   translator function for hwspinlock provider implementations
   that use a single cell number for requesting a specific lock
   (relatively indexed) within a hwlock bank.
3. The of_hwspin_lock_request_specific() API can be used by
   hwspinlock clients to request a specific lock using the
   phandle + args specifier. This function relies on the
   implementation providing back a relative hwlock id within
   the bank from the args specifier.

Signed-off-by: Suman Anna 
---
 Documentation/hwspinlock.txt |  34 ++-
 drivers/hwspinlock/hwspinlock_core.c | 100 ++-
 drivers/hwspinlock/hwspinlock_internal.h |   4 ++
 include/linux/hwspinlock.h   |  22 ++-
 4 files changed, 155 insertions(+), 5 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 640ae47..903d477 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -48,6 +48,15 @@ independent, drivers.
  ids for predefined purposes.
  Should be called from a process context (might sleep).
 
+  struct hwspinlock *of_hwspin_lock_request_specific(
+   struct device_node *np, const char *propname, int index);
+   - assign a specific hwspinlock id and return its address, or NULL
+ if that hwspinlock is already in use. This function is the OF
+ equivalent of hwspin_lock_request_specific() function, and provides
+ a means for users of the hwspinlock module to request a specific
+ hwspinlock using the phandle of the hwspinlock device.
+ Should be called from a process context (might sleep).
+
   int hwspin_lock_free(struct hwspinlock *hwlock);
- free a previously-assigned hwspinlock; returns 0 on success, or an
  appropriate error code on failure (e.g. -EINVAL if the hwspinlock
@@ -243,6 +252,23 @@ int hwspinlock_example2(void)
  Returns the address of hwspinlock on success, or NULL on error (e.g.
  if the hwspinlock is still in use).
 
+  int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+ const struct of_phandle_args *hwlock_spec);
+   - is a simple default OF translate helper function that can be plugged in
+ as the underlying vendor-specific implementation's of_xlate ops function.
+ This can be used by implementations that use a single integer argument in
+ the DT node argument specifier, that indicates the hwlock index number.
+ Returns a hwlock index within a bank, or appropriate error code on
+ failure.
+
+  int of_hwspin_lock_get_num_locks(struct device_node *dn);
+   - is a common OF helper function that can be used by some underlying
+ vendor-specific implementations. This can be used by implementations
+ that require and define the number of locks supported within a hwspinlock
+ bank as a device tree node property. This function should be called by
+ needed implementations before registering a hwspinlock device with the
+ core.
+
 5. Important structs
 
 struct hwspinlock_device is a device which usually contains a bank
@@ -288,12 +314,14 @@ initialized by the hwspinlock core itself.
 
 6. Implementation callbacks
 
-There are three possible callbacks defined in 'struct hwspinlock_ops':
+There are four possible callbacks defined in 'struct hwspinlock_ops':
 
 struct hwspinlock_ops {
int (*trylock)(struct hwspinlock *lock);
void (*unlock)(struct hwspinlock *lock);
void (*relax)(struct hwspinlock *lock);
+   int (*of_xlate)(struct hwspinlock_device *bank,
+   const struct of_phandle_args *hwlock_spec);
 };
 
 The first two callbacks are mandatory:
@@ -307,3 +335,7 @@ may _not_ sleep.
 The ->relax() callback is optional. It is called by hwspinlock core while
 spinning on a lock, and can be used by the underlying implementation to force
 a delay between two successive invocations of ->trylock(). It may _not_ sleep.
+
+The ->of_xlate() callback is mandatory to support requesting hwlocks through
+device-tree nodes. It is called by hwspinlock core to retrieve the relative
+lock index within a bank from the underlying implementation.
diff --git a/drivers/hwspinlock/hwspinlock_core.c 
b/drivers/hwspinlock/hwspinlock_core.c
index 48f7866..3966c0c 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "hwspinlock_internal.h"
 
@@ -262,6 +263,33 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode, 
unsigned long *flags)
 }
 EXPORT_SYMBOL_GPL(__hwspin_unlock);
 
+/**
+ * of_hwspin_lock_get_num_locks() - OF helper to retrieve number

Re: [PATCH] uprobes: use BX register for rip-relative fixups, not AX

On Mon, 2014-04-28 at 19:06 +0200, Denys Vlasenko wrote:
> Otherwise, instructions such as cmpxchg and div will be mishandled.
> 
> Signed-off-by: Denys Vlasenko 
> CC: Jim Keniston 
> CC: Masami Hiramatsu 
> CC: Srikar Dronamraju 
> CC: Ingo Molnar 
> CC: Oleg Nesterov 
> ---
>  arch/x86/kernel/uprobes.c | 57 
> ++-
>  1 file changed, 37 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
...
> @@ -296,41 +296,58 @@ static void riprel_analyze(struct arch_uprobe *auprobe, 
> struct insn *insn)
>*/
>   cursor = auprobe->insn + insn_offset_modrm(insn);
>   /*
> -  * Convert from rip-relative addressing to register-relative addressing
> -  * via a scratch register.
> +  * Convert from rip-relative addressing
> +  * to register-relative addressing via a scratch register.
>*/

This comment looks like a regression. :-)

Looks good otherwise (setting aside your later findings about cmpxchg8b
and such -- I guess we need some way to helpfully reject rip-relative
forms of such instructions).

Reviewed-by: Jim Keniston 

--
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: dcache shrink list corruption?

2014-04-30 Thread Linus Torvalds

On Wed, Apr 30, 2014 at 4:43 PM, Al Viro  wrote:
>
> OK, done and force-pushed.  Should propagate in a few...

That made it more obvious how the DCACHE_MAY_FREE case ends up
working. And in particular, mind rewriting this:

if (dentry->d_flags & DCACHE_MAY_FREE) {
spin_unlock(>d_lock);
dentry_free(dentry);
} else {
spin_unlock(>d_lock);
}
return parent;

as just

bool free = dentry->d_flags & DCACHE_MAY_FREE;
spin_unlock(>d_lock);
if (free)
dentry_free(dentry);
return parent;

instead? In fact, I get the feeling that the other case later on
really fits the same model:

spin_lock(>d_lock);
if (dentry->d_flags & DCACHE_SHRINK_LIST) {
dentry->d_flags |= DCACHE_MAY_FREE;
spin_unlock(>d_lock);
} else {
spin_unlock(>d_lock);
dentry_free(dentry);
  }

ends up really being better as

spin_lock(>d_lock);
free = 1;
if (dentry->d_flags & DCACHE_SHRINK_LIST) {
dentry->d_flags |= DCACHE_MAY_FREE;
free = 0;
}
spin_unlock(>d_lock);
if (free)
dentry_free(dentry);
return parent;

and then suddenly it looks like we have a common exit sequence from
that dentry_kill() function, no?

(The earlier "unlock_on_failure" exit case is altogether a different case).

I dunno. Maybe not a big deal, but one reason I prefer doing that
"free" flag is because I really tend to prefer the simple case of
lock-unlock pairing cleanly at the same level. NOT the pattern where
you have one lock at one indentation level, paired with multiple
unlocks for all the different cases.

  Linus
--
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 v3] uprobes: simplify rip-relative handling

On Mon, 2014-04-28 at 19:06 +0200, Denys Vlasenko wrote:
> It is possible to replace rip-relative addressing mode
> with addressing mode of the same length: (reg+disp32).
> This eliminates the need to fix up immediate
> and correct for changing instruction length.
> 
> v2: Rebased on top of Oleg's latest changes and run-tested.
> v3: Removed unnecessary cast.
> Improved comments based on Oleg's feedback.
> 
> Signed-off-by: Denys Vlasenko 
> CC: Jim Keniston 
> CC: Masami Hiramatsu 
> CC: Srikar Dronamraju 
> CC: Ingo Molnar 
> CC: Oleg Nesterov 

Thanks, Denys.
Reviewed-by: Jim Keniston 

--
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 2/3] bridge: trigger a bridge calculation upon port changes

2014-04-30 Thread Vlad Yasevich

On 04/30/2014 06:59 PM, Luis R. Rodriguez wrote:
> On Wed, Apr 30, 2014 at 04:04:34PM -0400, Vlad Yasevich wrote:
>> On 04/22/2014 03:43 PM, Luis R. Rodriguez wrote:
>>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>>> index 54d207d..dcd9378 100644
>>> --- a/net/bridge/br_if.c
>>> +++ b/net/bridge/br_if.c
>>> @@ -315,6 +315,8 @@ netdev_features_t br_features_recompute(struct 
>>> net_bridge *br,
>>> features &= ~NETIF_F_ONE_FOR_ALL;
>>>  
>>> list_for_each_entry(p, >port_list, list) {
>>> +   if (p->flags & BR_ROOT_BLOCK)
>>> +   continue;
>>> features = netdev_increment_features(features,
>>>  p->dev->features, mask);
>>> }
>>>
>> Hi Luis
>>
>> The hunk above isn't right.  Just because you set ROOT_BLOCK on the port
>> doesn't mean that you should ignore it's device features.  If the device
>> you just added happens to disable or enable some device offload feature,
>> you should take that into account.
> 
> OK thanks, how about this part:
> 
> On 04/22/2014 03:43 PM, Luis R. Rodriguez wrote:
>> On Tue, Mar 18, 2014 at 02:22:43PM -0700, Luis R. Rodriguez wrote:
>> On Tue, Mar 18, 2014 at 01:46:49PM -0700, Cong Wang wrote:
>>> On Fri, Mar 14, 2014 at 6:39 PM, Luis R. Rodriguez  wrote:
 On Thu, Mar 13, 2014 at 11:26:25AM -0700, Cong Wang wrote:
> On Wed, Mar 12, 2014 at 8:15 PM, Luis R. Rodriguez
>  wrote:
>> spin_unlock_bh(>br->lock);
>> +   if (changed)
>> +   
>> call_netdevice_notifiers(NETDEV_CHANGEADDR,
>> +p->br->dev);
>> +   netdev_update_features(p->br->dev);
>

This is actually just a part of it.  You also need to handle the sysfs
changing the flag.

Look at the first 2 patches in this series:
http://www.spinics.net/lists/netdev/msg280863.html

You might need that functionality.

-vlad


> I think this is supposed to be in netdev event handler of br->dev
> instead of here.

 Do you mean netdev_update_features() ? I mimic'd what was being done on
 br_del_if() given that root blocking is doing something similar. If
 we need to change something for the above then I suppose it means we need
 to change br_del_if() too. Let me know if you see any reason for something
 else.

>>>
>>> Yeah, for me it looks like it's better to call netdev_update_features()
>>> in the event handler of br->dev, rather than where calling
>>> call_netdevice_notifiers(..., br->dev);.
>>
>> I still don't see why, in fact trying to verify this I am wondering now
>> if instead we should actually fix br_features_recompute() to take into
>> consideration BR_ROOT_BLOCK as below. Notice how netdev_update_features()
>> is called above even if the MAC address did not change, just as is done
>> on br_del_if(). There is an NETDEV_FEAT_CHANGE event so would it be more
>> appropriate we just call
>>
>> call_netdevice_notifiers(NETDEV_FEAT_CHANGE, p->br->dev)
>>
>> for both the above then and also br_del_if()?
> 
>   Luis
> 

--
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 2/3] uprobes/x86: Kill the "autask" arg of riprel_pre_xol()

On Mon, 2014-04-28 at 12:05 +0530, Srikar Dronamraju wrote:
> * Oleg Nesterov  [2014-04-27 18:52:27]:
> 
> > default_pre_xol_op() passes >utask->autask to riprel_pre_xol()
> > and this is just ugly because it still needs to load current->utask to
> > read ->vaddr.
> > 
> > Remove this argument, change riprel_pre_xol() to use current->utask.
> > 
> > Signed-off-by: Oleg Nesterov 
> 
> Acked-by: Srikar Dronamraju 
> 
Reviewed-by: Jim Keniston 

--
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 3/3] uprobes/x86: Simplify riprel_{pre,post}_xol() and make them similar

On Mon, 2014-04-28 at 12:06 +0530, Srikar Dronamraju wrote:
> * Oleg Nesterov  [2014-04-27 18:52:30]:
> 
> > Ignoring the "correction" logic riprel_pre_xol() and riprel_post_xol()
> > are very similar but look quite differently.
> > 
> > 1. Add the "UPROBE_FIX_RIP_AX | UPROBE_FIX_RIP_CX" check at the start
> >of riprel_pre_xol(), like the same check in riprel_post_xol().
> > 
> > 2. Add the trivial scratch_reg() helper which returns the address of
> >scratch register pre_xol/post_xol need to change.
> > 
> > 3. Change these functions to use the new helper and avoid copy-and-paste
> >under if/else branches.
> > 
> > Signed-off-by: Oleg Nesterov 
> 
> Acked-by: Srikar Dronamraju 
> 
Reviewed-by: Jim Keniston 

--
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 1/3] uprobes/x86: Rename riprel helpers to make the naming consistent