[PATCH V3 0/2] dma: mmp_pdma: Fix phy channels not protected issue

[Xiang Wang]

From: Xiang Wang 

This patch set deals with the issues that 1) phy channels are not protected
in mmp_pdma. 2) dma request<->channel mapping is not cleared when a phy chan
is freed.

Xiang Wang (2):
  dma: mmp_pdma: add protect when alloc/free phy channels
  dma: mmp_pdma: clear DRCMR when free a phy channel

 drivers/dma/mmp_pdma.c |   48 
 1 files changed, 32 insertions(+), 16 deletions(-)

-- 
1.7.5.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 V3 2/2] dma: mmp_pdma: clear DRCMR when free a phy channel

[Xiang Wang]

From: Xiang Wang 

In mmp pdma, phy channels are allocated/freed dynamically.
The mapping from DMA request to DMA channel number in DRCMR
should be cleared when a phy channel is freed. Otherwise
conflicts will happen when:
1. A is using channel 2 and free it after finished, but A
still maps to channel 2 in DRCMR of A.
2. Now another one B gets channel 2. So B maps to channel 2
too in DRCMR of B.
In the datasheet, it is described that "Do not map two active
requests to the same channel since it produces unpredictable
results" and we can observe that during test.

Signed-off-by: Xiang Wang 
---
 drivers/dma/mmp_pdma.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index 226158d..2844eaf 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -252,10 +252,16 @@ static void mmp_pdma_free_phy(struct mmp_pdma_chan *pchan)
 {
struct mmp_pdma_device *pdev = to_mmp_pdma_dev(pchan->chan.device);
unsigned long flags;
+   u32 reg;
 
if (!pchan->phy)
return;
 
+   /* clear the channel mapping in DRCMR */
+   reg = pchan->phy->vchan->drcmr;
+   reg = ((reg < 64) ? 0x0100 : 0x1100) + ((reg & 0x3f) << 2);
+   writel(0, pchan->phy->base + reg);
+
spin_lock_irqsave(&pdev->phy_lock, flags);
pchan->phy->vchan = NULL;
pchan->phy = NULL;
-- 
1.7.5.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 V3 1/2] dma: mmp_pdma: add protect when alloc/free phy channels

[Xiang Wang]

From: Xiang Wang 

In mmp pdma, phy channels are allocated/freed dynamically
and frequently. But no proper protection is added.
Conflict will happen when multi-users are requesting phy
channels at the same time. Use spinlock to protect.

Signed-off-by: Xiang Wang 
---
 drivers/dma/mmp_pdma.c |   42 ++
 1 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index c26699f..226158d 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -121,6 +121,7 @@ struct mmp_pdma_device {
struct device   *dev;
struct dma_device   device;
struct mmp_pdma_phy *phy;
+   spinlock_t phy_lock; /* protect alloc/free phy channels */
 };
 
 #define tx_to_mmp_pdma_desc(tx) container_of(tx, struct mmp_pdma_desc_sw, 
async_tx)
@@ -219,6 +220,7 @@ static struct mmp_pdma_phy *lookup_phy(struct mmp_pdma_chan 
*pchan)
int prio, i;
struct mmp_pdma_device *pdev = to_mmp_pdma_dev(pchan->chan.device);
struct mmp_pdma_phy *phy;
+   unsigned long flags;
 
/*
 * dma channel priorities
@@ -227,6 +229,8 @@ static struct mmp_pdma_phy *lookup_phy(struct mmp_pdma_chan 
*pchan)
 * ch 8 - 11, 24 - 27  <--> (2)
 * ch 12 - 15, 28 - 31  <--> (3)
 */
+
+   spin_lock_irqsave(&pdev->phy_lock, flags);
for (prio = 0; prio <= (((pdev->dma_channels - 1) & 0xf) >> 2); prio++) 
{
for (i = 0; i < pdev->dma_channels; i++) {
if (prio != ((i & 0xf) >> 2))
@@ -234,14 +238,30 @@ static struct mmp_pdma_phy *lookup_phy(struct 
mmp_pdma_chan *pchan)
phy = &pdev->phy[i];
if (!phy->vchan) {
phy->vchan = pchan;
+   spin_unlock_irqrestore(&pdev->phy_lock, flags);
return phy;
}
}
}
 
+   spin_unlock_irqrestore(&pdev->phy_lock, flags);
return NULL;
 }
 
+static void mmp_pdma_free_phy(struct mmp_pdma_chan *pchan)
+{
+   struct mmp_pdma_device *pdev = to_mmp_pdma_dev(pchan->chan.device);
+   unsigned long flags;
+
+   if (!pchan->phy)
+   return;
+
+   spin_lock_irqsave(&pdev->phy_lock, flags);
+   pchan->phy->vchan = NULL;
+   pchan->phy = NULL;
+   spin_unlock_irqrestore(&pdev->phy_lock, flags);
+}
+
 /* desc->tx_list ==> pending list */
 static void append_pending_queue(struct mmp_pdma_chan *chan,
struct mmp_pdma_desc_sw *desc)
@@ -277,10 +297,7 @@ static void start_pending_queue(struct mmp_pdma_chan *chan)
 
if (list_empty(&chan->chain_pending)) {
/* chance to re-fetch phy channel with higher prio */
-   if (chan->phy) {
-   chan->phy->vchan = NULL;
-   chan->phy = NULL;
-   }
+   mmp_pdma_free_phy(chan);
dev_dbg(chan->dev, "no pending list\n");
return;
}
@@ -377,10 +394,7 @@ static int mmp_pdma_alloc_chan_resources(struct dma_chan 
*dchan)
dev_err(chan->dev, "unable to allocate descriptor pool\n");
return -ENOMEM;
}
-   if (chan->phy) {
-   chan->phy->vchan = NULL;
-   chan->phy = NULL;
-   }
+   mmp_pdma_free_phy(chan);
chan->idle = true;
chan->dev_addr = 0;
return 1;
@@ -411,10 +425,7 @@ static void mmp_pdma_free_chan_resources(struct dma_chan 
*dchan)
chan->desc_pool = NULL;
chan->idle = true;
chan->dev_addr = 0;
-   if (chan->phy) {
-   chan->phy->vchan = NULL;
-   chan->phy = NULL;
-   }
+   mmp_pdma_free_phy(chan);
return;
 }
 
@@ -581,10 +592,7 @@ static int mmp_pdma_control(struct dma_chan *dchan, enum 
dma_ctrl_cmd cmd,
switch (cmd) {
case DMA_TERMINATE_ALL:
disable_chan(chan->phy);
-   if (chan->phy) {
-   chan->phy->vchan = NULL;
-   chan->phy = NULL;
-   }
+   mmp_pdma_free_phy(chan);
spin_lock_irqsave(&chan->desc_lock, flags);
mmp_pdma_free_desc_list(chan, &chan->chain_pending);
mmp_pdma_free_desc_list(chan, &chan->chain_running);
@@ -777,6 +785,8 @@ static int mmp_pdma_probe(struct platform_device *op)
return -ENOMEM;
pdev->dev = &op->dev;
 
+   spin_lock_init(&pdev->phy_lock);
+
iores = platform_get_resource(op, IORESOURCE_MEM, 0);
if (!iores)
return -EINVAL;
-- 
1.7.5.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 t

Re: [RFC] should read(2) update the position if it returns an error?

[Al Viro]

On Fri, Jun 14, 2013 at 08:38:19AM -0700, Linus Torvalds wrote:
> On Fri, Jun 14, 2013 at 1:05 AM, Al Viro  wrote:
> >
> > Comments?  I'd obviously prefer to solve it that way (i.e. leave
> > ->f_pos untouched if vfs_read() returns an error), but I might be missing
> > some case where we want position updated even though read() returns an
> > error.  I can't come up with one, but then I hadn't RTFS through every
> > ->read() instance in drivers in search of weird cases like that - we've
> > too many instances ;-/
> 
> Not updating f_pos on errors sounds like the right thing to do to me,
> and if it also ends up fixing some nasty issues with hpfs and
> potentially other cases, I'd say "go for it".
> 
> Not for 3.10, though. It's not like this is a new - or acute - problem.

Grr...  I've just crawled through ->llseek() instances and I really wonder
what to do with that crap.  Debugfs idiocies had been obvious, but there
are much stranger turds floating there.

Some random examples:
drivers/sbus/char/flash.c:
SEEK_CUR beyond the EOF silently trims position to EOF
SEEK_SET to the same position just sets it
SEEK_END sets position to EOF, period - offset is simply ignored

cris eeprom:
SEEK_END inverts the sign of offset
any seek to negative returns EOVERFLOW (instead of usual EINVAL)
*and* sets position to 0
any seek to or beyond the EOF (there's an off-by-one) also
returns EOVERFLOW *and* sets position to EOF - 1.  Yes, that includes
lseek(fd, SEEK_END, 0)

carma-fpga-program.c:
SEEK_END inverts sign of offset
seeks past EOF give EINVAL
seeks to negative offsets pass on 32bit and give EINVAL on 64bit

drivers/s390/char/vmur.c:
fails when offset is not a multiple of 4Kb; the trouble
being, read() can bloody well leave you with position not being such
a multiple, so that check buys us nothing - SEEK_CUR for 12Kb might
be an equivalent of SEEK_SET to 13Kb; the former is allowed, the
latter isn't.

drivers/staging/vme/devices/vme_user.c:
apparent off-by-one - SEEK_END:-1 succeeds, SEEK_END:0 gives
EINVAL.

Then there's a bunch of drivers that either don't allow SEEK_END while
having an upper limit to seekable positions acting as EOF would or
allow seeks past what SEEK_END:0 yields.

All that mess is a user-visible ABI and at least for the weird eeprom
devices I would be very cautious with fixing it - the userland code
dealing with those animals is rather obscure, can easily turn out
to rely on the idiotic behaviour and brick the boxen if things go
wrong.

I'm switching everything I can to use of generic_file_llseek_size();
quite a few can be switched, often along with dropping the locking
that served only to serialize lseek vs. lseek.  The rest is going to
be unpleasant.

There's another pile of fun around f_pos manipulations - try to run
ecryptfs on top of tmpfs or ceph and do seeks on directories.
ecryptfs ->readdir() assigns ->f_pos of underlying file and calls
underlying ->readdir(); the trouble is, underlying fs has things it
wants done on ->f_pos changes (cursor needs to be moved, etc.).
ecryptfs on top of hpfs is also a lot of fun, not that anybody had been
using that combination.

Sigh...
--
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 0/6] ipc/sem.c: performance improvements, FIFO

[Mike Galbraith]

On Sat, 2013-06-15 at 13:10 +0200, Manfred Spraul wrote: 
> On 06/14/2013 09:05 PM, Mike Galbraith wrote:
> > # Events: 802K cycles
> > #
> > # Overhead  Symbol
> > #   ..
> > #
> >  18.42%  [k] SYSC_semtimedop
> >  15.39%  [k] sem_lock
> >  10.26%  [k] _raw_spin_lock
> >   9.00%  [k] perform_atomic_semop
> >   7.89%  [k] system_call
> >   7.70%  [k] ipc_obtain_object_check
> >   6.95%  [k] ipcperms
> >   6.62%  [k] copy_user_generic_string
> >   4.16%  [.] __semop
> >   2.57%  [.] worker_thread(void*)
> >   2.30%  [k] copy_from_user
> >   1.75%  [k] sem_unlock
> >   1.25%  [k] ipc_obtain_object
> ~ 280 mio ops.
> 2.3% copy_from_user,
> 9% perform_atomic_semop.
> 
> > # Events: 802K cycles
> > #
> > # Overhead   Symbol
> > #   ...
> > #
> >  17.38%  [k] SYSC_semtimedop
> >  13.26%  [k] system_call
> >  11.31%  [k] copy_user_generic_string
> >   7.62%  [.] __semop
> >   7.18%  [k] _raw_spin_lock
> >   5.66%  [k] ipcperms
> >   5.40%  [k] sem_lock
> >   4.65%  [k] perform_atomic_semop
> >   4.22%  [k] ipc_obtain_object_check
> >   4.08%  [.] worker_thread(void*)
> >   4.06%  [k] copy_from_user
> >   2.40%  [k] ipc_obtain_object
> >   1.98%  [k] pid_vnr
> >   1.45%  [k] wake_up_sem_queue_do
> >   1.39%  [k] sys_semop
> >   1.35%  [k] sys_semtimedop
> >   1.30%  [k] sem_unlock
> >   1.14%  [k] security_ipc_permission
> ~ 700 mio ops.
> 4% copy_from_user -> as expected a bit more
> 4.6% perform_atomic_semop --> less.
> 
> Thus: Could you send the oprofile output from perform_atomic_semop()?
> 
> Perhaps that gives us a hint.
> 
> My current guess:
> sem_lock() somehow ends up in lock_array.
> Lock_array scans all struct sem -> transfer of that cacheline from all 
> cpus to the cpu that does the lock_array..
> Then the next write by the "correct" cpu causes a transfer back when 
> setting sem->pid.

Profiling sem_lock(), observe sma->complex_count.

 :   again:
 :  if (nsops == 1 && !sma->complex_count) {
0.00 :  81258a64:   75 5a   jne
81258ac0 
0.50 :  81258a66:   41 8b 44 24 7c  mov
0x7c(%r12),%eax
   23.04 :  81258a6b:   85 c0   test   %eax,%eax
0.00 :  81258a6d:   75 51   jne
81258ac0 
 :  struct sem *sem = sma->sem_base + sops->sem_num;
0.01 :  81258a6f:   41 0f b7 1e movzwl 
(%r14),%ebx
0.48 :  81258a73:   48 c1 e3 06 shl$0x6,%rbx
0.52 :  81258a77:   49 03 5c 24 40  add
0x40(%r12),%rbx
 :  raw_spin_lock_init(&(_lock)->rlock);\
 :  } while (0)
 :
 :  static inline void spin_lock(spinlock_t *lock)
 :  {
 :  raw_spin_lock(&lock->rlock);
1.45 :  81258a7c:   4c 8d 6b 08 lea
0x8(%rbx),%r13
0.47 :  81258a80:   4c 89 efmov%r13,%rdi
0.50 :  81258a83:   e8 08 4f 35 00  callq  
815ad990 <_raw_spin_lock>
 :
 :  /*
 :   * If sma->complex_count was set while we were 
spinning,
 :   * we may need to look at things we did not 
lock here.
 :   */
 :  if (unlikely(sma->complex_count)) {
0.53 :  81258a88:   41 8b 44 24 7c  mov
0x7c(%r12),%eax
   34.33 :  81258a8d:   85 c0   test   %eax,%eax
0.02 :  81258a8f:   75 29   jne
81258aba 
 :  __add(&lock->tickets.head, 1, UNLOCK_LOCK_PREFIX);
 :  }
 :

We're taking cache misses for _both_ reads, so I speculated that
somebody somewhere has to be banging on that structure, so I tried
putting complex_count on a different cache line, and indeed, the
overhead disappeared, and box started scaling linearly and reliably so
to 32 cores.  64 is still unstable, but 32 became rock solid.

Moving cacheline_aligned_in_smp upward one at a time to try to find
out which field was causing trouble, I ended up at sem_base.. a pointer
that's not modified.  That makes zero sense to me, does anybody have an
idea why having sem_base and complex_count in the same cache line would
cause this?

---
 include/linux/sem.h |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6/include/linux/sem.h
===
--- linux-2.6.orig/include/linux/sem.h
+++

Re: + include-linux-smph-on_each_cpu-switch-back-to-a-macro.patch added to -mm tree

[Stephen Rothwell]

Hi Andrew,

On Mon, 17 Jun 2013 13:31:17 -0700 a...@linux-foundation.org wrote:
>
> From: Andrew Morton 
> Subject: include/linux/smp.h:on_each_cpu(): switch back to a macro
> 
> f21afc25f9ed4 ("smp.h: Use local_irq_{save,restore}() in !SMP version of
> on_each_cpu()") converted on_each_cpu() to a C function.  This required
> inclusion of irqflags.h, which broke ia64 and mn10300 (at least) due to
> header ordering hell.
> 
> Switch on_each_cpu() back to a macro to fix this.
> 
> Reported-by: Geert Uytterhoeven 
> Cc: David Daney 
> Cc: Ralf Baechle 
> Cc: Stephen Rothwell 
> Signed-off-by: Andrew Morton 
> ---
> 
>  include/linux/smp.h |   20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff -puN 
> include/linux/smp.h~include-linux-smph-on_each_cpu-switch-back-to-a-macro 
> include/linux/smp.h
> --- 
> a/include/linux/smp.h~include-linux-smph-on_each_cpu-switch-back-to-a-macro
> +++ a/include/linux/smp.h
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  extern void cpu_idle(void);
>  
> @@ -140,17 +139,14 @@ static inline int up_smp_call_function(s
>  }
>  #define smp_call_function(func, info, wait) \
>   (up_smp_call_function(func, info))
> -
> -static inline int on_each_cpu(smp_call_func_t func, void *info, int wait)
> -{
> - unsigned long flags;
> -
> - local_irq_save(flags);
> - func(info);
> - local_irq_restore(flags);
> - return 0;
> -}
> -
> +#define on_each_cpu(func,info,wait)  \
> + ({  \
> + unsigned long flags;\
> + local_irq_save(flags);  \
> + func(info); \
> + local_irq_restore(flags);   \
> + 0;  \
> + })
>  /*
>   * Note we still need to test the mask even for UP
>   * because we actually can get an empty mask from

I added this to the akpm tree in linux-next today - but with
s/flags/__flags/ in appropriate places.

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


pgpkCSBcDRgii.pgp
Description: PGP signature

[PATCH] gpio-langwell: remove Withney point support

[Andy Shevchenko]

It seems there is no user of the wp_gpio driver in the kernel. Let's remove it.

Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
---
 drivers/gpio/gpio-langwell.c | 69 +---
 1 file changed, 1 insertion(+), 68 deletions(-)

diff --git a/drivers/gpio/gpio-langwell.c b/drivers/gpio/gpio-langwell.c
index 2db6ef7..bfa1af1 100644
--- a/drivers/gpio/gpio-langwell.c
+++ b/drivers/gpio/gpio-langwell.c
@@ -20,7 +20,6 @@
 /* Supports:
  * Moorestown platform Langwell chip.
  * Medfield platform Penwell chip.
- * Whitney point.
  */
 
 #include 
@@ -390,75 +389,9 @@ static struct pci_driver lnw_gpio_driver = {
},
 };
 
-
-static int wp_gpio_probe(struct platform_device *pdev)
-{
-   struct lnw_gpio *lnw;
-   struct gpio_chip *gc;
-   struct resource *rc;
-   int retval;
-
-   lnw = devm_kzalloc(&pdev->dev, sizeof(struct lnw_gpio), GFP_KERNEL);
-   if (!lnw) {
-   dev_err(&pdev->dev, "can't allocate chip data\n");
-   return -ENOMEM;
-   }
-
-   rc = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   lnw->reg_base = devm_ioremap_resource(&pdev->dev, rc);
-   if (IS_ERR(lnw->reg_base))
-   return PTR_ERR(lnw->reg_base);
-
-   spin_lock_init(&lnw->lock);
-   gc = &lnw->chip;
-   gc->label = dev_name(&pdev->dev);
-   gc->owner = THIS_MODULE;
-   gc->direction_input = lnw_gpio_direction_input;
-   gc->direction_output = lnw_gpio_direction_output;
-   gc->get = lnw_gpio_get;
-   gc->set = lnw_gpio_set;
-   gc->to_irq = NULL;
-   gc->base = 0;
-   gc->ngpio = 64;
-   gc->can_sleep = 0;
-   retval = gpiochip_add(gc);
-   if (retval) {
-   dev_err(&pdev->dev, "gpiochip_add error %d\n", retval);
-   return retval;
-   }
-   platform_set_drvdata(pdev, lnw);
-   return 0;
-}
-
-static int wp_gpio_remove(struct platform_device *pdev)
-{
-   struct lnw_gpio *lnw = platform_get_drvdata(pdev);
-   int err;
-   err = gpiochip_remove(&lnw->chip);
-   if (err)
-   dev_err(&pdev->dev, "failed to remove gpio_chip.\n");
-   return 0;
-}
-
-static struct platform_driver wp_gpio_driver = {
-   .probe  = wp_gpio_probe,
-   .remove = wp_gpio_remove,
-   .driver = {
-   .name   = "wp_gpio",
-   .owner  = THIS_MODULE,
-   },
-};
-
 static int __init lnw_gpio_init(void)
 {
-   int ret;
-   ret =  pci_register_driver(&lnw_gpio_driver);
-   if (ret < 0)
-   return ret;
-   ret = platform_driver_register(&wp_gpio_driver);
-   if (ret < 0)
-   pci_unregister_driver(&lnw_gpio_driver);
-   return ret;
+   return pci_register_driver(&lnw_gpio_driver);
 }
 
 device_initcall(lnw_gpio_init);
-- 
1.8.3.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/

Re: [PATCH] Re: [Patch] MCE, APEI: Don't enable CMCI when Firmware First mode is set in

[Naveen N. Rao]

The Corrected Machine Check structure (CMC) in HEST has a flag which can be
set by the firmware to indicate to the OS that it prefers to process the
corrected error events first. In this scenario, the OS is expected to not
monitor for corrected errors (through CMCI/polling). Instead, the firmware
notifies the OS on corrected error events through GHES.

Linux already has support for GHES. This patch adds support for parsing CMC
structure and to disable CMCI/polling if the firmware first flag is set.

Further, the list of machine check bank structures at the end of CMC is used
to determine which MCA banks function in FF mode, so that we continue to
monitor error events on the other banks.


- Naveen

Signed-off-by: Naveen N. Rao 
---
 arch/x86/include/asm/mce.h|3 ++
 arch/x86/kernel/cpu/mcheck/mce-internal.h |3 ++
 arch/x86/kernel/cpu/mcheck/mce.c  |   23 +
 arch/x86/kernel/cpu/mcheck/mce_intel.c|   40 +++--
 drivers/acpi/apei/hest.c  |   36 ++
 5 files changed, 97 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index fa5f71e..380fff8 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -188,6 +188,9 @@ extern void register_mce_write_callback(ssize_t (*)(struct 
file *filp,
const char __user *ubuf,
size_t usize, loff_t *off));
 
+/* Disable CMCI/polling for MCA bank claimed by firmware */
+extern void mce_disable_ce_bank(int bank);
+
 /*
  * Exception handler
  */
diff --git a/arch/x86/kernel/cpu/mcheck/mce-internal.h 
b/arch/x86/kernel/cpu/mcheck/mce-internal.h
index 5b7d4fa..193edc1 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-internal.h
+++ b/arch/x86/kernel/cpu/mcheck/mce-internal.h
@@ -25,6 +25,9 @@ int mce_severity(struct mce *a, int tolerant, char **msg);
 struct dentry *mce_get_debugfs_dir(void);
 
 extern struct mce_bank *mce_banks;
+extern mce_banks_t mce_banks_ce_disabled;
+
+void cmci_disable_bank(int bank);
 
 #ifdef CONFIG_X86_MCE_INTEL
 unsigned long mce_intel_adjust_timer(unsigned long interval);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 9239504..4bd9973 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -94,6 +94,9 @@ DEFINE_PER_CPU(mce_banks_t, mce_poll_banks) = {
[0 ... BITS_TO_LONGS(MAX_NR_BANKS)-1] = ~0UL
 };
 
+/* MCA banks controlled through firmware first for corrected errors */
+mce_banks_t mce_banks_ce_disabled;
+
 static DEFINE_PER_CPU(struct work_struct, mce_work);
 
 static void (*quirk_no_way_out)(int bank, struct mce *m, struct pt_regs *regs);
@@ -1932,6 +1935,26 @@ static struct miscdevice mce_chrdev_device = {
&mce_chrdev_ops,
 };
 
+static void __mce_disable_ce_bank(void *arg)
+{
+   int bank = *((int *)arg);
+
+   /* Ensure we don't poll this bank */
+   __clear_bit(bank, __get_cpu_var(mce_poll_banks));
+   /* Disable CMCI */
+   cmci_disable_bank(bank);
+}
+
+void mce_disable_ce_bank(int bank)
+{
+   if (bank >= mca_cfg.banks) {
+   pr_info("mce_disable_bank: Invalid MCA bank %d ignored.\n", 
bank);
+   return;
+   }
+   set_bit(bank, mce_banks_ce_disabled);
+   on_each_cpu(__mce_disable_ce_bank, &bank, 1);
+}
+
 /*
  * mce=off Disables machine check
  * mce=no_cmci Disables CMCI
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c 
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index ae1697c..78256c0 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -191,6 +191,10 @@ static void cmci_discover(int banks)
if (test_bit(i, owned))
continue;
 
+   /* Skip banks in firmware first mode */
+   if (test_bit(i, mce_banks_ce_disabled))
+   continue;
+
rdmsrl(MSR_IA32_MCx_CTL2(i), val);
 
/* Already owned by someone else? */
@@ -259,6 +263,20 @@ void cmci_recheck(void)
local_irq_restore(flags);
 }
 
+/* Caller must hold the lock on cmci_discover_lock */
+static void __cmci_disable_bank(int bank)
+{
+   u64 val;
+
+   if (!test_bit(bank, __get_cpu_var(mce_banks_owned)))
+   return;
+   /* Disable CMCI */
+   rdmsrl(MSR_IA32_MCx_CTL2(bank), val);
+   val &= ~MCI_CTL2_CMCI_EN;
+   wrmsrl(MSR_IA32_MCx_CTL2(bank), val);
+   __clear_bit(bank, __get_cpu_var(mce_banks_owned));
+}
+
 /*
  * Disable CMCI on this CPU for all banks it owns when it goes down.
  * This allows other CPUs to claim the banks on rediscovery.
@@ -268,19 +286,12 @@ void cmci_clear(void)
unsigned long flags;
int i;
int banks;
-   u64 val;
 
if (!cmci_supported(&banks))
return;
raw_spin_lock_irqsave(&cmci_discover_lock, flags);
for (i = 0; 

[PATCH v11 6/8] dmaengine: edma: enable build for AM33XX

[Joel A Fernandes]

From: Matt Porter 

Enable TI EDMA option on OMAP.

Signed-off-by: Matt Porter 
Signed-off-by: Joel A Fernandes 
---
 drivers/dma/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index e992489..3215a3c 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -213,7 +213,7 @@ config SIRF_DMA
 
 config TI_EDMA
tristate "TI EDMA support"
-   depends on ARCH_DAVINCI
+   depends on ARCH_DAVINCI || ARCH_OMAP
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
default n
-- 
1.7.9.5

--
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 1/3] cpufreq: Add boost frequency support in core

[Viresh Kumar]

On 17 June 2013 19:21, Lukasz Majewski  wrote:
> On Mon, 17 Jun 2013 18:40:50 +0530, Viresh Kumar wrote:
>> >> > The core acpi-cpufreq.c code hadn't been changed by me, so I
>> >> > assume that it will work as before.
>> >>
>> >> That should adapt your patch in your patchset.
>
> Could you explain what do you mean?

Update acpi-cpufreq to use your infrastructure.

>> >> From sysfs?? I thought we are going to have some automatic control
>> >> of this stuff from inside kernel.
>> >
>> > From sysfs I just enable the boost. I do not order from userpace the
>> > cpufreq to run with a particular (boosted) frequency.
>> >
>> > When I enable boost - I ask (politely) the cpufreq core to
>> > reevaluate policies and when applicable increase policy->max.
>> >
>> > Then governor can use this new frequencies for normal operation.
>>
>> So, with your current patchset in, ondemand or conservative governors
>> will start using boost frequencies. Which might burn your chip.
>
> Two scenarios:
> 1. Thermal framework is compiled in and enabled (for exynos/other SoC)
> -> trip point is reached -> boost is disabled -> frequency is reduced ->
> SoC is cooled down.
>
> I think, that thermal framework is a good "safe valve" here.

Even in this case boost shouldn't have been enabled by default.
Its not only about burning the chip but more than that.

According to my understanding, boost was important for power
saving. In case a high load can be managed by a single cpu with
boost freqs, then its better to use boost freqs rather than bringing
another cpu up.

Normally boost freqs are not so useful if we talk about powersaving,
as their energy consumption is much higher with not so great impact
on performance.

That's why when this thread started we talked about boost only when
one cpu is operational. But with your patch all cores can use boost
freq and thermal will come into picture just to save the chip.

That's wrong. This isn't why we invented boost here. Otherwise you
just don't need boost feature at all for your SoC. Just make these
freqs as available freqs and let thermal control policy->max/min
to save your chip.

> 2. Thermal framework is disabled and user has enabled boost and used
> ondemand / conservative governor.
> Then execute gzip < /dev/urandom > /dev/null & (on all cores).
>
> Then yes, chip will hang/burn due to crossing operating point (or burn).
>
>
> What other means of control (despite of thermal) would you consider
> applicable?
>
> What comes to my mind is modifying governor logic to count how long the
> CPU run with boost enabled and then disable it.

Its not about how long.. One cpu type can work longer with boost freq
compared to other.

What we probably need is:
- Enabled boost from sysfs if required (now below steps will come into
  picture)
- See how many cpus are running, if only one then start using boost freqs
- Now thermal should be come into picture to save chip in case a single
cpu running at boost can burn it out.
--
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 v2 2/4] SUNRPC: fix races on PipeFS MOUNT notifications

[Stanislav Kinsbursky]

17.06.2013 22:20, Myklebust, Trond пишет:

On Tue, 2013-06-11 at 18:39 +0400, Stanislav Kinsbursky wrote:

Below are races, when RPC client can be created without PiepFS dentries

CPU#0   CPU#1
-   -
rpc_new_client  rpc_fill_super
rpc_setup_pipedir
mutex_lock(&sn->pipefs_sb_lock)
rpc_get_sb_net == NULL
(no per-net PipeFS superblock)
sn->pipefs_sb = sb;
notifier_call_chain(MOUNT)
(client is not in the list)
rpc_register_client
(client without pipes dentries)

To fix this patch:
1) makes PipeFS mount notification call with pipefs_sb_lock being held.
2) releases pipefs_sb_lock on new SUNRPC client creation only after
registration.

Signed-off-by: Stanislav Kinsbursky 
Cc: sta...@vger.kernel.org


Hi Stanislav,

This isn't going to apply to the stable kernels without the cleanup
patch. Could you please reorganise this patch series so that the cleanup
comes last.

Thanks,
   Trond




Hello, Trond.
Sure, will do.

--
Best regards,
Stanislav Kinsbursky
--
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 v11 2/8] ARM: edma: Add DT and runtime PM support to the private EDMA API

[Joel A Fernandes]

From: Matt Porter 

Adds support for parsing the TI EDMA DT data into the required EDMA
private API platform data. Enables runtime PM support to initialize
the EDMA hwmod. Enables build on OMAP.

Changes by Joel:
* Setup default one-to-one mapping for queue_priority and queue_tc
mapping as discussed in [1].
* Split out xbar stuff to separate patch. [1]

[1] https://patchwork.kernel.org/patch/2226761/

Signed-off-by: Matt Porter 
Acked-by: Sekhar Nori 
Signed-off-by: Joel A Fernandes 
---
 arch/arm/common/edma.c |  190 +---
 arch/arm/mach-omap2/Kconfig|1 +
 include/linux/platform_data/edma.h |4 +-
 3 files changed, 181 insertions(+), 14 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a1db6cd..9823b79 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -1369,31 +1376,173 @@ void edma_clear_event(unsigned channel)
 EXPORT_SYMBOL(edma_clear_event);
 
 /*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
+{
+   int ret;
+
+   ret = of_property_read_u8_array(np, propname, out_values, sz);
+   if (ret)
+   return ret;
+
+   /* Terminate it */
+   *out_values++ = -1;
+   *out_values++ = -1;
+
+   return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16 *out_values,
+size_t sz)
+{
+   int ret;
+
+   ret = of_property_read_u16_array(np, propname, out_values, sz);
+   if (ret)
+   return ret;
+
+   /* Terminate it */
+   *out_values++ = -1;
+   *out_values++ = -1;
+
+   return 0;
+}
 
-static int __init edma_probe(struct platform_device *pdev)
+static int edma_of_parse_dt(struct device *dev,
+   struct device_node *node,
+   struct edma_soc_info *pdata)
+{
+   int ret = 0, i;
+   u32 value;
+   struct property *prop;
+   size_t sz;
+   struct edma_rsv_info *rsv_info;
+   const s16 (*rsv_chans)[2], (*rsv_slots)[2];
+   s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+   memset(pdata, 0, sizeof(struct edma_soc_info));
+
+   ret = of_property_read_u32(node, "dma-channels", &value);
+   if (ret < 0)
+   return ret;
+   pdata->n_channel = value;
+
+   ret = of_property_read_u32(node, "ti,edma-regions", &value);
+   if (ret < 0)
+   return ret;
+   pdata->n_region = value;
+
+   ret = of_property_read_u32(node, "ti,edma-slots", &value);
+   if (ret < 0)
+   return ret;
+   pdata->n_slot = value;
+
+   pdata->n_cc = 1;
+   pdata->n_tc = 3;
+
+   rsv_info =
+   devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
+   if (!rsv_info)
+   return -ENOMEM;
+   pdata->rsv = rsv_info;
+
+   queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
+   if (!queue_tc_map)
+   return -ENOMEM;
+
+   for (i = 0; i < 3; i++)
+   queue_tc_map[i][0] = queue_tc_map[i][1] = i;
+   queue_tc_map[i][0] = queue_tc_map[i][1] = -1;
+
+   pdata->queue_tc_mapping = queue_tc_map;
+
+   queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
+   if (!queue_priority_map)
+   return -ENOMEM;
+
+   for (i = 0; i < 3; i++)
+   queue_priority_map[i][0] = queue_priority_map[i][1] = i;
+   queue_priority_map[i][0] = queue_priority_map[i][1] = -1;
+
+   pdata->queue_priority_mapping = queue_priority_map;
+
+   pdata->default_queue = 0;
+
+
+   return ret;
+}
+
+static struct of_dma_filter_info edma_filter_info = {
+   .filter_fn = edma_filter_fn,
+};
+
+static int edma_probe(struct platform_device *pdev)
 {
struct edma_soc_info**info = pdev->dev.platform_data;
-   const s8(*queue_priority_mapping)[2];
-   const s8(*queue_tc_mapping)[2];
+   struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL, NULL};
+   struct edma_soc_infotmpinfo;
+   s8  (*queue_priority_mapping)[2];
+   s8  (*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
int status = -1;
const s16   (*rsv_chans)[2];
const s16   (*rsv_slots)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
-   struct resource *r[EDMA_MAX_CC] = {NUL

[PATCH v11 1/8] dmaengine: edma: Add TI EDMA device tree binding

[Joel A Fernandes]

From: Matt Porter 

The binding definition is based on the generic DMA controller
binding.

Joel:
* Droped reserved and queue DT entries from Documentation
for now from the original patch series (v10)
* Included properties in Documentation and clarified DMA properties (V11)
* Made ti,hwmod option
* Clarified DMA entries

Signed-off-by: Matt Porter 
Signed-off-by: Joel A Fernandes 
---
 Documentation/devicetree/bindings/dma/ti-edma.txt |   34 +
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt

diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..9fbbdb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,34 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- #dma-cells: Should be set to <1>
+  Clients should use a single channel number per DMA request.
+- dma-channels: Specify total DMA channels per CC
+- reg: Memory map for accessing module
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Exactly 3 interrupts need to be specified in the order:
+  1. Transfer completion interrupt.
+  2. Memory protection interrupt.
+  3. Error interrupt.
+Optional properties:
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+   reg = <0x4900 0x1>;
+   interrupt-parent = <&intc>;
+   interrupts = <12 13 14>;
+   compatible = "ti,edma3";
+   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+   #dma-cells = <1>;
+   dma-channels = <64>;
+   ti,edma-regions = <4>;
+   ti,edma-slots = <256>;
+   ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
-- 
1.7.9.5

--
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 v11 0/8] ] DMA Engine support for AM33XX

[Joel A Fernandes]

This series is a repost of Matt Porter's EDMA patches for AM33XX EDMA support
with changes for few pending review comments on v9 series.

Currently this is required for AM33XX (Beaglebone or EVM) to access MMC
and be able mount to rootfs and boot till command prompt over MMC.
Unless there are other pending review comments, I hope this series can
make it into 3.11 merge window, the dependent series has been posted at [1]
and completed review.

Tested EDMA on AM1808 EVM and AM33XX Beaglebone with MMC.

Sekhar Nori has posted a GIT PULL [1] which has 2 patches this series depends 
on:
[1] http://www.spinics.net/lists/arm-kernel/msg251503.html

Changes since v10:
- Reworked documentation based on Arnd's feedback
- Moved EDMA bindings documentation earlier in series
- Dropped mention on am33xx on 2/8 and 3/8 in the series

Changes since v9:
- Droped reserved and queue DT entries from Documentation
for now from the original patch series.
- Drop DT entries that are non-hardware-description
- Split EDMA xbar support out of original EDMA DT parsing patch
to keep it easier for review.
- Rewrite shift and offset calculation xbar event mapping.
- Setup default one-to-one mapping for queue_priority and queue_tc
mapping as discussed in.
- Split out xbar stuff to separate patch.

Reference discussion:
   https://patchwork.kernel.org/patch/2226761/

Changes since v8:
- Removed edma node interrupt-parent property, it is inherited

Changes since v7:
- Dropped dmaengine compat() patch. It is upstream.
- Submitted edma_alloc_slot() error checking bug fix separately,
  now a dependency
- Fixed bisect issues due to 3/10 hunks that went into 1/10
- Fixed incorrect IS_ERRVALUE() use in 3/10

Changes since v6:
- Converted edma_of_read_*() to wrappers around of_property_read_*()
- Fixed wording on the omap-spi generic DMA properties
- Added comment/check to clarify that the driver only supports
  a single EDMA instance when booting from DT

Changes since v5:
- Dropped mmc portion and moved it to a separate series
- Incorporate corrected version of dma_request_slave_channel_compat()
- Fix #defines and enablement of TI_PRIV_EDMA option

Changes since v4:
- Fixed debug section mismatch in private edma api [01/14]
- Respun format-patch to catch the platform_data/edma.h rename [01/14]
- Removed address/size-cells from the EDMA binding [05/14]

Changes since v3:
- Rebased on 3.8-rc3
- No longer an RFC
- Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia
- Restored all the Davinci pdata to const
- Removed max_segs hack in favor of using dma_get_channel_caps()
- Fixed extra parens, __raw_* accessors and, ioremap error checks
  in xbar handling
- Removed excess license info in platform_data/edma.h
- Removed unneeded reserved channels data for AM33xx
- Removed test-specific pinmuxing from dts files
- Adjusted mmc1 node to be disabled by default in the dtsi

Changes since v2:
- Rebased on 3.7-rc1
- Fixed bug in DT/pdata parsing first found by Gururaja
  that turned out to be masked by some toolchains
- Dropped unused mach-omap2/devices.c hsmmc patch
- Added AM33XX crossbar DMA event mux support
- Added am335x-evm support

Changes since v1:
- Rebased on top of mainline from 12250d8
- Dropped the feature removal schedule patch
- Implemented dma_request_slave_channel_compat() and
  converted the mmc and spi drivers to use it
- Dropped unneeded #address-cells and #size-cells from
  EDMA DT support
- Moved private EDMA header to linux/platform_data/ and
  removed some unneeded definitions
- Fixed parsing of optional properties

This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.

The series applies on top of 3.10-rc4.

The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so the upstream generic DT DMA helpers are
leveraged to register EDMA DMAC with the of_dma framework. SPI (and
MMC in a separate series) are supported using the upstream
dma_request_slave_channel_compat() dmaengine call that allows
compatibility with !DT platforms.

With this series both BeagleBone and the AM335x EVM have working
SPI DMA support (and MMC support with the separate MMC series).

This is test

[PATCH v11 4/8] ARM: dts: add AM33XX EDMA support

[Joel A Fernandes]

From: Matt Porter 

Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt

Joel: Drop DT entries that are non-hardware-description for now as discussed in 
[1]

[1] https://patchwork.kernel.org/patch/2226761/

Signed-off-by: Matt Porter 
Signed-off-by: Joel A Fernandes 
---
 arch/arm/boot/dts/am33xx.dtsi |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index d9cad72..3d59bb3 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -89,6 +89,18 @@
reg = <0x4820 0x1000>;
};
 
+   edma: edma@4900 {
+   compatible = "ti,edma3";
+   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+   reg =   <0x4900 0x1>,
+   <0x44e10f90 0x10>;
+   interrupts = <12 13 14>;
+   #dma-cells = <1>;
+   dma-channels = <64>;
+   ti,edma-regions = <4>;
+   ti,edma-slots = <256>;
+   };
+
gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
-- 
1.7.9.5

--
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 v11 5/8] ARM: dts: add AM33XX SPI DMA support

[Joel A Fernandes]

From: Matt Porter 

Adds DMA resources to the AM33XX SPI nodes.

Signed-off-by: Matt Porter 
Signed-off-by: Joel A Fernandes 
---
 arch/arm/boot/dts/am33xx.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3d59bb3..fb17103 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -361,6 +361,11 @@
interrupts = <65>;
ti,spi-num-cs = <2>;
ti,hwmods = "spi0";
+   dmas = <&edma 16
+   &edma 17
+   &edma 18
+   &edma 19>;
+   dma-names = "tx0", "rx0", "tx1", "rx1";
status = "disabled";
};
 
@@ -372,6 +377,11 @@
interrupts = <125>;
ti,spi-num-cs = <2>;
ti,hwmods = "spi1";
+   dmas = <&edma 42
+   &edma 43
+   &edma 44
+   &edma 45>;
+   dma-names = "tx0", "rx0", "tx1", "rx1";
status = "disabled";
};
 
-- 
1.7.9.5

--
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 v11 8/8] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()

[Joel A Fernandes]

From: Matt Porter 

Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.

Signed-off-by: Matt Porter 
Acked-by: Mark Brown 
Signed-off-by: Joel A Fernandes 
---
 drivers/spi/spi-omap2-mcspi.c |   64 -
 1 file changed, 44 insertions(+), 20 deletions(-)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 86d2158..ca4ab78 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
 
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+   char dma_rx_ch_name[14];
+   char dma_tx_ch_name[14];
 };
 
 /* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -830,12 +833,20 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma->dma_rx_sync_dev;
-   mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+   mcspi_dma->dma_rx =
+   dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_rx_ch_name);
if (!mcspi_dma->dma_rx)
goto no_dma;
 
sig = mcspi_dma->dma_tx_sync_dev;
-   mcspi_dma->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+   mcspi_dma->dma_tx =
+   dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_tx_ch_name);
+
if (!mcspi_dma->dma_tx) {
dma_release_channel(mcspi_dma->dma_rx);
mcspi_dma->dma_rx = NULL;
@@ -1256,29 +1267,42 @@ static int omap2_mcspi_probe(struct platform_device 
*pdev)
goto free_master;
 
for (i = 0; i < master->num_chipselect; i++) {
-   char dma_ch_name[14];
+   char *dma_rx_ch_name = mcspi->dma_channels[i].dma_rx_ch_name;
+   char *dma_tx_ch_name = mcspi->dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
 
-   sprintf(dma_ch_name, "rx%d", i);
-   dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
-   dma_ch_name);
-   if (!dma_res) {
-   dev_dbg(&pdev->dev, "cannot get DMA RX channel\n");
-   status = -ENODEV;
-   break;
-   }
+   sprintf(dma_rx_ch_name, "rx%d", i);
+   if (!pdev->dev.of_node) {
+   dma_res =
+   platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+   if (!dma_res) {
+   dev_dbg(&pdev->dev,
+   "cannot get DMA RX channel\n");
+   status = -ENODEV;
+   break;
+   }
 
-   mcspi->dma_channels[i].dma_rx_sync_dev = dma_res->start;
-   sprintf(dma_ch_name, "tx%d", i);
-   dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
-   dma_ch_name);
-   if (!dma_res) {
-   dev_dbg(&pdev->dev, "cannot get DMA TX channel\n");
-   status = -ENODEV;
-   break;
+   mcspi->dma_channels[i].dma_rx_sync_dev =
+   dma_res->start;
}
+   sprintf(dma_tx_ch_name, "tx%d", i);
+   if (!pdev->dev.of_node) {
+   dma_res =
+   platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+   if (!dma_res) {
+   dev_dbg(&pdev->dev,
+   "cannot get DMA TX channel\n");
+   status = -ENODEV;
+   break;
+   }
 
-   mcspi->dma_channels[i].dma_tx_sync_dev = dma_res->start;
+   mcspi->dma_channels[i].dma_tx_sync_dev =
+   dma_res->start;
+   }
}
 
if (status < 0)
-- 
1.7.9.5

--
To unsubscribe from this list: send

[PATCH v11 3/8] ARM: edma: Add EDMA crossbar event mux support

[Joel A Fernandes]

From: Matt Porter 

Changes by Joel:
* Split EDMA xbar support out of original EDMA DT parsing patch
to keep it easier for review.
* Rewrite shift and offset calculation.

Suggested-by: Sekhar Nori 
Suggested by: Andy Shevchenko 
Signed-off-by: Joel A Fernandes 

Reference:
[1] https://patchwork.kernel.org/patch/2226991/
---
 arch/arm/common/edma.c |   59 
 include/linux/platform_data/edma.h |1 +
 2 files changed, 60 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 9823b79..1c2fb15 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1410,6 +1410,52 @@ static int edma_of_read_u32_to_s16_array(const struct 
device_node *np,
return 0;
 }
 
+static int edma_xbar_event_map(struct device *dev,
+  struct device_node *node,
+  struct edma_soc_info *pdata, int len)
+{
+   int ret = 0;
+   int i;
+   struct resource res;
+   void *xbar;
+   const s16 (*xbar_chans)[2];
+   u32 shift, offset, mux;
+
+   xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+   if (!xbar_chans)
+   return -ENOMEM;
+
+   ret = of_address_to_resource(node, 1, &res);
+   if (ret)
+   return -EIO;
+
+   xbar = devm_ioremap(dev, res.start, resource_size(&res));
+   if (!xbar)
+   return -ENOMEM;
+
+   ret = edma_of_read_u32_to_s16_array(node,
+   "ti,edma-xbar-event-map",
+   (s16 *)xbar_chans,
+   len/sizeof(u32));
+   if (ret)
+   return -EIO;
+
+   for (i = 0; xbar_chans[i][0] != -1; i++) {
+   shift = (xbar_chans[i][1] & 0x03) << 3;
+   offset = xbar_chans[i][1] & 0xfffc;
+   mux = readl((void *)((u32)xbar + offset));
+   mux &= ~(0xff << shift);
+   mux |= xbar_chans[i][0] << shift;
+   writel(mux, (void *)((u32)xbar + offset));
+   }
+
+   pdata->xbar_chans = xbar_chans;
+
+   return 0;
+}
+
 static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
@@ -1470,6 +1516,9 @@ static int edma_of_parse_dt(struct device *dev,
 
pdata->default_queue = 0;
 
+   prop = of_find_property(node, "ti,edma-xbar-event-map", &sz);
+   if (prop)
+   ret = edma_xbar_event_map(dev, node, pdata, sz);
 
return ret;
 }
@@ -1489,6 +1538,7 @@ static int edma_probe(struct platform_device *pdev)
int status = -1;
const s16   (*rsv_chans)[2];
const s16   (*rsv_slots)[2];
+   const s16   (*xbar_chans)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
struct resource *r[EDMA_MAX_CC] = {NULL, NULL};
@@ -1617,6 +1667,15 @@ static int edma_probe(struct platform_device *pdev)
}
}
 
+   /* Clear the xbar mapped channels in unused list */
+   xbar_chans = info[j]->xbar_chans;
+   if (xbar_chans) {
+   for (i = 0; xbar_chans[i][1] != -1; i++) {
+   off = xbar_chans[i][1];
+   clear_bits(off, 1,
+   edma_cc[j]->edma_unused);
+   }
+   }
 
if (node)
irq[j] = irq_of_parse_and_map(node, 0);
diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index 317f2be..57300fd 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -177,6 +177,7 @@ struct edma_soc_info {
 
s8  (*queue_tc_mapping)[2];
s8  (*queue_priority_mapping)[2];
+   const s16   (*xbar_chans)[2];
 };
 
 #endif
-- 
1.7.9.5

--
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 v11 7/8] spi: omap2-mcspi: add generic DMA request support to the DT binding

[Joel A Fernandes]

From: Matt Porter 

The binding definition is based on the generic DMA request binding

Signed-off-by: Matt Porter 
Signed-off-by: Joel A Fernandes 
---
 Documentation/devicetree/bindings/spi/omap-spi.txt |   27 +++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt 
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..4c85c4c 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
  input. The default is D0 as input and
  D1 as output.
 
-Example:
+Optional properties:
+- dmas: List of DMA specifiers with the controller specific format
+   as described in the generic DMA client binding. A tx and rx
+   specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+   1:1 with the DMA specifiers listed in dmas. The string naming
+   is to be "rxN" and "txN" for RX and TX requests,
+   respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
 
 mcspi1: mcspi@1 {
 #address-cells = <1>;
@@ -20,3 +31,17 @@ mcspi1: mcspi@1 {
 ti,spi-num-cs = <4>;
 };
 
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "ti,omap4-mcspi";
+ti,hwmods = "mcspi1";
+ti,spi-num-cs = <2>;
+dmas = <&edma 42
+   &edma 43
+   &edma 44
+   &edma 45>;
+dma-names = "tx0", "rx0", "tx1", "rx1";
+};
-- 
1.7.9.5

--
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: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

[Glauber Costa]

On Tue, Jun 18, 2013 at 12:46:23PM +1000, Dave Chinner wrote:
> On Tue, Jun 18, 2013 at 02:30:05AM +0400, Glauber Costa wrote:
> > On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
> > > On Mon, 17 Jun 2013 19:14:12 +0400 Glauber Costa  
> > > wrote:
> > > 
> > > > > I managed to trigger:
> > > > > [ 1015.776029] kernel BUG at mm/list_lru.c:92!
> > > > > [ 1015.776029] invalid opcode:  [#1] SMP
> > > > > with Linux next (next-20130607) with 
> > > > > https://lkml.org/lkml/2013/6/17/203
> > > > > on top. 
> > > > > 
> > > > > This is obviously BUG_ON(nlru->nr_items < 0) and 
> > > > > 81122d0b:   48 85 c0test   %rax,%rax
> > > > > 81122d0e:   49 89 44 24 18  mov%rax,0x18(%r12)
> > > > > 81122d13:   0f 84 87 00 00 00   je 
> > > > > 81122da0 
> > > > > 81122d19:   49 83 7c 24 18 00   cmpq   $0x0,0x18(%r12)
> > > > > 81122d1f:   78 7b   js 
> > > > > 81122d9c 
> > > > > [...]
> > > > > 81122d9c:   0f 0b   ud2
> > > > > 
> > > > > RAX is -1UL.
> > > > Yes, fearing those kind of imbalances, we decided to leave the counter 
> > > > as a signed quantity
> > > > and BUG, instead of an unsigned quantity.
> > > > 
> > > > > 
> > > > > I assume that the current backtrace is of no use and it would most
> > > > > probably be some shrinker which doesn't behave.
> > > > > 
> > > > There are currently 3 users of list_lru in tree: dentries, inodes and 
> > > > xfs.
> > > > Assuming you are not using xfs, we are left with dentries and inodes.
> > > > 
> > > > The first thing to do is to find which one of them is misbehaving. You 
> > > > can try finding
> > > > this out by the address of the list_lru, and where it lays in the 
> > > > superblock.
> > > > 
> > > > Once we know each of them is misbehaving, then we'll have to figure out 
> > > > why.
> > > 
> > > The trace says shrink_slab_node->super_cache_scan->prune_icache_sb.  So
> > > it's inodes?
> > > 
> > Assuming there is no memory corruption of any sort going on , let's check 
> > the code.
> > nr_item is only manipulated in 3 places:
> > 
> > 1) list_lru_add, where it is increased
> > 2) list_lru_del, where it is decreased in case the user have voluntarily 
> > removed the
> >element from the list
> > 3) list_lru_walk_node, where an element is removing during shrink.
> > 
> > All three excerpts seem to be correctly locked, so something like this 
> > indicates an imbalance.
> 
> inode_lru_isolate() looks suspicious to me:
> 
> WARN_ON(inode->i_state & I_NEW);
> inode->i_state |= I_FREEING;
> spin_unlock(&inode->i_lock);
> 
> list_move(&inode->i_lru, freeable);
> this_cpu_dec(nr_unused);
>   return LRU_REMOVED;
> }
> 
> All the other cases where I_FREEING is set and the inode is removed
> from the LRU are completely done under the inode->i_lock. i.e. from
> an external POV, the state change to I_FREEING and removal from LRU
> are supposed to be atomic, but they are not here.
> 
> I'm not sure this is the source of the problem, but it definitely
> needs fixing.
> 
Yes, I missed that yesterday, but that does look suspicious to me as well.

Michal, if you can manually move this one inside the lock as well and see
if it fixes your problem as well... Otherwise I can send you a patch as well
so we don't get lost on what is patched and what is not.

Let us at least know if this is the problem.

> > callers:
> > iput_final, evict_inodes, invalidate_inodes.
> > Both evict_inodes and invalidate_inodes will do the following pattern:
> > 
> > inode->i_state |= I_FREEING;
> > 
> > inode_lru_list_del(inode);
> > spin_unlock(&inode->i_lock);
> > list_add(&inode->i_lru, &dispose);
> > 
> > IOW, they will remove the element from the LRU, and add it to the dispose 
> > list.
> > Both of them will also bail out if they see I_FREEING already set, so they 
> > are safe
> > against each other - because the flag is manipulated inside the lock.
> > 
> > But how about iput_final? It seems to me that if we are calling iput_final 
> > at the
> > same time as the other two, this *could* happen (maybe there is some extra 
> > protection
> > that can be seen from Australia but not from here. Dave?)
> 
> If I_FREEING is set before we enter iput_final(), then something
> else is screwed up. I_FREEING is only set once the last reference
> has gone away and we are killing the inode. All the other callers
> that set I_FREEING check that the reference count on the inode is
> zero before they set I_FREEING. Hence I_FREEING cannot be set on the
> transition of i_count from 1 to 0 when iput_final() is called. So
> the patch won't do anything to avoid the problem being seen.
> 
Yes, but isn't things like evict_inodes and invalidate_inodes called at
umount time, for instance?

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

[Glauber Costa]

On Tue, Jun 18, 2013 at 02:30:05AM +0400, Glauber Costa wrote:
> On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
> > On Mon, 17 Jun 2013 19:14:12 +0400 Glauber Costa  wrote:
> > 
> > > > I managed to trigger:
> > > > [ 1015.776029] kernel BUG at mm/list_lru.c:92!
> > > > [ 1015.776029] invalid opcode:  [#1] SMP
> > > > with Linux next (next-20130607) with https://lkml.org/lkml/2013/6/17/203
> > > > on top. 
> > > > 
> > > > This is obviously BUG_ON(nlru->nr_items < 0) and 
> > > > 81122d0b:   48 85 c0test   %rax,%rax
> > > > 81122d0e:   49 89 44 24 18  mov%rax,0x18(%r12)
> > > > 81122d13:   0f 84 87 00 00 00   je 81122da0 
> > > > 
> > > > 81122d19:   49 83 7c 24 18 00   cmpq   $0x0,0x18(%r12)
> > > > 81122d1f:   78 7b   js 81122d9c 
> > > > 
> > > > [...]
> > > > 81122d9c:   0f 0b   ud2
> > > > 
> > > > RAX is -1UL.
> > > Yes, fearing those kind of imbalances, we decided to leave the counter as 
> > > a signed quantity
> > > and BUG, instead of an unsigned quantity.
> > > 
> > > > 
> > > > I assume that the current backtrace is of no use and it would most
> > > > probably be some shrinker which doesn't behave.
> > > > 
> > > There are currently 3 users of list_lru in tree: dentries, inodes and xfs.
> > > Assuming you are not using xfs, we are left with dentries and inodes.
> > > 
> > > The first thing to do is to find which one of them is misbehaving. You 
> > > can try finding
> > > this out by the address of the list_lru, and where it lays in the 
> > > superblock.
> > > 
> > > Once we know each of them is misbehaving, then we'll have to figure out 
> > > why.
> > 
> > The trace says shrink_slab_node->super_cache_scan->prune_icache_sb.  So
> > it's inodes?
> > 
> Assuming there is no memory corruption of any sort going on , let's check the 
> code.
> nr_item is only manipulated in 3 places:
> 
> 1) list_lru_add, where it is increased
> 2) list_lru_del, where it is decreased in case the user have voluntarily 
> removed the
>element from the list
> 3) list_lru_walk_node, where an element is removing during shrink.
> 
> All three excerpts seem to be correctly locked, so something like this 
> indicates an imbalance.
> Either the element was never added to the list, or it was added, removed, and 
> we didn't notice
> it. (Again, your backing storage is not XFS, is it? If it is , we have 
> another user to look for)
> 
> I will assume that Andrew is correct and this is inode related. list_lru_del 
> reads as follows:
> spin_lock(&nlru->lock);
> if (!list_empty(item)) { ... }
> 
> So one possibility is that we are manipulating this list outside this lock 
> somewhere. Going to
> inode.c... We always manipulate the LRU inside the lock, but the element is 
> not always in the LRU,
> if it is in a list. Could it be possible that the element is in the 
> dispose_list, and at the same
> time someone calls list_lru_del at it, creating the imbalance ?
> 
> callers:
> iput_final, evict_inodes, invalidate_inodes.
> Both evict_inodes and invalidate_inodes will do the following pattern:
> 
> inode->i_state |= I_FREEING;  
>   
> inode_lru_list_del(inode);
> spin_unlock(&inode->i_lock);
> list_add(&inode->i_lru, &dispose);
> 
> IOW, they will remove the element from the LRU, and add it to the dispose 
> list.
> Both of them will also bail out if they see I_FREEING already set, so they 
> are safe
> against each other - because the flag is manipulated inside the lock.
> 
> But how about iput_final? It seems to me that if we are calling iput_final at 
> the
> same time as the other two, this *could* happen (maybe there is some extra 
> protection
> that can be seen from Australia but not from here. Dave?)
> 
> Right now this is my best theory.
> 
> I am attaching a patch that should make a difference in case I am right.
> 
> 
> 

Which is obviously borked since I did not fix the other callers so to move 
I_FREEING
after lru del.

Michal, would you mind testing the following patch?

diff --git a/fs/inode.c b/fs/inode.c
index 00b804e..48eafa6 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -419,6 +419,8 @@ void inode_add_lru(struct inode *inode)
 
 static void inode_lru_list_del(struct inode *inode)
 {
+   if (inode->i_state & I_FREEING)
+   return;
 
if (list_lru_del(&inode->i_sb->s_inode_lru, &inode->i_lru))
this_cpu_dec(nr_unused);
@@ -609,8 +611,8 @@ void evict_inodes(struct super_block *sb)
continue;
}
 
-   inode->i_state |= I_FREEING;
inode_lru_list_del(inode);
+   inode->i_state |= I_FREEING;
spin_unlock(&inode->i_lock);
list_add(&inode->i_lru, &dispose);
}
@@ -6

[PATCH] sched: fix load_above_capacity underflow

[Lei Wen]

Apparently we don't want to see sds->busiest_nr_running is small than
sds->busiest_group_capacity, while our load_above_capacity is
an "unsigned long" type.

Signed-off-by: Lei Wen 
---
 kernel/sched/fair.c |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c61a614..fd90b17 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4780,12 +4780,17 @@ static inline void calculate_imbalance(struct lb_env 
*env, struct sd_lb_stats *s
/*
 * Don't want to pull so many tasks that a group would go idle.
 */
-   load_above_capacity = (sds->busiest_nr_running -
-   sds->busiest_group_capacity);
+   if (sds->busiest_has_capacity)
+   load_above_capacity = 0;
+   else {
+   load_above_capacity = (sds->busiest_nr_running -
+   sds->busiest_group_capacity);
 
-   load_above_capacity *= (SCHED_LOAD_SCALE * SCHED_POWER_SCALE);
+   load_above_capacity *=
+   (SCHED_LOAD_SCALE * SCHED_POWER_SCALE);
 
-   load_above_capacity /= sds->busiest->sgp->power;
+   load_above_capacity /= sds->busiest->sgp->power;
+   }
}
 
/*
-- 
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 v2] dma: mmp_pdma: fix a memory alloc error

[Xiang Wang]

From: Xiang Wang 

pdev->phy is of type "struct mmp_pdma_phy *". But when
allocating memory for it, "struct mmp_pdma_chan" is used
by mistake.

Signed-off-by: Xiang Wang 
---
 drivers/dma/mmp_pdma.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index c26699f..18ac57f 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -801,7 +801,7 @@ static int mmp_pdma_probe(struct platform_device *op)
}
 
pdev->phy = devm_kzalloc(pdev->dev,
-   dma_channels * sizeof(struct mmp_pdma_chan), GFP_KERNEL);
+   dma_channels * sizeof(*pdev->phy), GFP_KERNEL);
if (pdev->phy == NULL)
return -ENOMEM;
 
-- 
1.7.5.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: [Part1 PATCH v5 16/22] x86, mm, numa: Move numa emulation handling down.

[Yinghai Lu]

On Mon, Jun 17, 2013 at 6:58 PM, Tejun Heo  wrote:
> On Thu, Jun 13, 2013 at 09:03:03PM +0800, Tang Chen wrote:
>> From: Yinghai Lu 
>>
>> numa_emulation() needs to allocate buffer for new numa_meminfo
>> and distance matrix, so execute it later in x86_numa_init().
>>
>> Also we change the behavoir:
>>   - before this patch, if user input wrong data in command
>> line, it will fall back to next numa probing or disabling
>> numa.
>>   - after this patch, if user input wrong data in command line,
>> it will stay with numa info probed from previous probing,
>> like ACPI SRAT or amd_numa.
>>
>> We need to call numa_check_memblks to reject wrong user inputs early
>> so that we can keep the original numa_meminfo not changed.
>
> So, this is another very subtle ordering you're adding without any
> comment and I'm not sure it even makes sense because the function can
> fail after that point.

Yes, if it fail, we will stay with current numa info from firmware.
That looks like right behavior.

Before this patch, it will fail to next numa way like if acpi srat + user
input fail, it will try to go with amd_numa then try apply user info.

>
> I'm getting really doubtful about this whole approach of carefully
> splitting discovery and registration.  It's inherently fragile like
> hell and the poor documentation makes it a lot worse.  I'm gonna reply
> to the head message.

Maybe look at the patch is not clear enough, but if looks at the final changed
code it would be more clear.

Thanks

Yinghai
--
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 arm-soc tree with the usb tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/usb/phy/phy-rcar-usb.c between commit 56a9a6de2a87 ("usb: phy:
rcar-usb: Fix comment w.r.t. devm_ioremap_resource") from the usb tree
and commit 725bf9dcafe1 ("phy-rcar-usb: correct base address") from the
arm-soc tree.

I fixed it up (The latter removed the comment corrected by the former)
and can carry the fix as necessary (no action is required).

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


pgpC9vLCRokhy.pgp
Description: PGP signature

Re: [PATCH] [RFC] mnt: restrict a number of "struct mnt"

[Andrew Vagin]

On Mon, Jun 17, 2013 at 03:56:14PM -0700, Andrew Morton wrote:
> On Mon, 17 Jun 2013 12:58:00 -0700 ebied...@xmission.com (Eric W. Biederman) 
> wrote:
> 
> > > I found that a few processes can eat all host memory and nobody can kill 
> > > them.
> > > $ mount -t tmpfs xxx /mnt
> > > $ mount --make-shared /mnt
> > > $ for i in `seq 30`; do mount --bind /mnt `mktemp -d /mnt/test.XX` & 
> > > done
> > >
> > > All this processes are unkillable, because they took i_mutex and waits
> > > namespace_lock.
> > >
> > > ...
> > > 21715 pts/0 __D __0:00 __\_ mount --bind /mnt 
> > > /mnt/test.ht6jzO
> > > 21716 pts/0 __D __0:00 __\_ mount --bind /mnt 
> > > /mnt/test.97K4mI
> > > 21717 pts/0 __R __0:01 __\_ mount --bind /mnt 
> > > /mnt/test.gO2CD9
> > > ...
> > >
> > > Each of this process doubles a number of mounts, so at the end we will
> > > have about 2^32 mounts and the size of struct mnt is 256 bytes, so we
> > > need about 1TB of RAM.
> > >
> > > Another problem is that ___umount___ of a big tree is very hard operation
> > > and it requires a lot of time.
> > > E.g.:
> > > 16411
> > > umount("/tmp/xxx", MNT_DETACH) __= 0 <7.852066> (7.8 sec)
> > > 32795
> > > umount("/tmp/xxx", MNT_DETACH) __= 0 <34.485501> ( 34 sec)
> > >
> > > For all this time sys_umoun takes namespace_sem and vfsmount_lock...
> > >
> > > Due to all this reasons I suggest to restrict a number of mounts.
> > > Probably we can optimize this code in a future, but now this restriction
> > > can help.
> > 
> > So for anyone seriously worried about this kind of thing in general we
> > already have the memory control group, which is quite capable of
> > limiting this kind of thing, and it limits all memory allocations not
> > just mount.
> 
> What is the exposure here?  By what means can a non-CAP_SYS_ADMIN user
> run sys_mount() under the namespace system?
> 
> IOW, what does the sysadmin have to do to permit this?  Is that a
> typical thing to do, or did the sysadmin make a mistake?

It's a problem for Linux Containers. Because usually the root user in
container should have enough rights to mount something (tmpfs,
bindmounts, etc).  Our target is to make containers completely isolated.

A container is isolated with help of namespaces. The user namespace
creates a new sets of capabilities and users.


> --
> 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/
--
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 6/7] sound/usb/misc/ua101.c: convert __list_for_each usage to list_for_each

[Takashi Iwai]

At Mon, 17 Jun 2013 22:26:57 -0400,
Dave Jones wrote:
> 
> Signed-off-by: Dave Jones 

Thanks, applied now to sound git tree.


Takashi

> ---
>  sound/usb/misc/ua101.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/usb/misc/ua101.c b/sound/usb/misc/ua101.c
> index 6ad617b..8b5d2c5 100644
> --- a/sound/usb/misc/ua101.c
> +++ b/sound/usb/misc/ua101.c
> @@ -1349,7 +1349,7 @@ static void ua101_disconnect(struct usb_interface 
> *interface)
>   snd_card_disconnect(ua->card);
>  
>   /* make sure that there are no pending USB requests */
> - __list_for_each(midi, &ua->midi_list)
> + list_for_each(midi, &ua->midi_list)
>   snd_usbmidi_disconnect(midi);
>   abort_alsa_playback(ua);
>   abort_alsa_capture(ua);
> -- 
> 1.8.1.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: [PATCH] dmatest: masking tests for channel capabilities

[Andy Shevchenko]

On Tue, Jun 18, 2013 at 12:12 AM, Dan Williams  wrote:
> On Mon, Jun 17, 2013 at 2:10 PM, Dan Williams  wrote:
>>> +Example to perform only MEMCPY and PQ mode tests (0x01 | 0x04 = 0x05):
>>> +
>>> +% modprobe dmatest
>>> +% echo dma0chan0 > /sys/kernel/debug/dmatest/channel
>>> +% echo 5  > /sys/kernel/debug/dmatest/cap_mask
>>> +% echo 1 > /sys/kernel/debug/dmatest/iterations
>>> +% echo 1 > /sys/kernel/debug/dmatest/run
>>
>>
>> Hmmm, I should have paid more attention when the debugfs support was
>> initially proposed for dmatest.  As it is I see duplication and
>> configuration parameters getting out of sync with their module parameter
>> equivalents versus just having all configuration go through module
>> parameters.  module_param_call() can be used for the more complex options.
>> Debugfs at this point looks like overkill for what amounts to some simple
>> configuration variables and a result line.

There two main issues we fight against:
 - test automation, where we can collect results and use them later
 - annoying modprobe / modprobe -r for each test case

The module parameters were left to support old behaviour of the module.

--
With Best Regards,
Andy Shevchenko
--
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] usb: host: Faraday fotg210-hcd driver

[Yuan-Hsin Chen]

Hi,

On Tue, Jun 18, 2013 at 11:07 AM, Sarah Sharp
 wrote:
> On Tue, Jun 18, 2013 at 10:42:09AM +0800, Yuan-Hsin Chen wrote:
>> Hi,
>>
>> On Tue, Jun 18, 2013 at 4:39 AM, Greg KH  wrote:
>> > On Wed, Jun 05, 2013 at 05:15:43PM +, Yuan-Hsin Chen wrote:
>> >> FOTG210 is an OTG controller which can be configured as an
>> >> USB2.0 host. FOTG210 host is an ehci-like controller with
>> >> some differences. First, register layout of FOTG210 is
>> >> incompatible with EHCI. Furthermore, FOTG210 is lack of
>> >> siTDs which means iTDs are used for both HS and FS ISO
>> >> transfer.
>> >>
>> >> Signed-off-by: Yuan-Hsin Chen 
>> >> ---
>> >>  drivers/usb/Makefile   |1 +
>> >>  drivers/usb/host/Kconfig   |   12 +
>> >>  drivers/usb/host/Makefile  |1 +
>> >>  drivers/usb/host/fotg210-hcd.c | 5967 
>> >> 
>> >>  drivers/usb/host/fotg210.h |  746 +
>> >>  5 files changed, 6727 insertions(+), 0 deletions(-)
>> >>  create mode 100644 drivers/usb/host/fotg210-hcd.c
>> >>  create mode 100644 drivers/usb/host/fotg210.h
>> >
>> > You obviously didn't even run this through checkpatch.pl, did you?
>> >
>> > $ ./scripts/checkpatch.pl --terse ../usb.mbox | tail -n 1
>> > total: 138 errors, 618 warnings, 6742 lines checked
>> >
>> > Please fix all of these if you wish us to at least start reviewing the
>> > patch.  Your internal Q/A should have caught this first, please be more
>> > careful in the future.
>> >
>>
>> Actually I did run checkpatch.pl and found that almost all errors and
>> warnings are from ehci core (ehci-hcd.c, ehci-hub.c and so on) where
>> my driver borrowed most of code.
>>
>> $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hub.c | tail -n 1
>> total: 18 errors, 69 warnings, 1138 lines checked
>>
>> $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hcd.c | tail -n 1
>> total: 17 errors, 78 warnings, 1403 lines checked
>>
>> So you're saying that I should fix them, is that right?
>
> In that case, no, you should be figuring out how to refactor and reuse
> the EHCI code instead of copying it straight into your driver.

I was trying to use ehci-platform.c, anonymous union/struct, and quirk
flags to avoid copying EHCI code.
But there are too big incompatibilities between fotg210/fusbh200
controller and EHCI.
That's why Alan agreed that I could create a stand-alone driver for
fusbh200 host controller.
Since fotg210 and fusbh200 have the same issue,  fotg210 hcd is
supposed to be stand-alone.
More details please refer to mail sequence
http://www.spinics.net/lists/linux-usb/msg83812.html

Thanks,

Yuan-Hsin

>
> Sarah Sharp
--
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] tcp: Modify the condition for the first skb to collapse

[Eric Dumazet]

On Tue, 2013-06-18 at 05:52 -0400, Jun Chen wrote:
> > 
> There are many warning for tcp_recvmsg before this crash. I can't find
> other memory warning in the logs, but I'm not sure whether there are
> memory issues because of the length limitation of saved logs. I think
> this logs will give you more information.
> 
> <4>[ 7736.343742] [ cut here ]
> 
> <4>[ 7736.343759] WARNING:
> at /data/buildbot/workdir/jb/kernel/net/ipv4/tcp.c:1496 tcp_recvmsg
> +0x3bf/0x910()
> 
> <4>[ 7736.343775] recvmsg bug: copied AB57C870 seq AB57CD95 rcvnxt
> AB57F19F fl 0
> 
> <4>[ 7736.343845] Call Trace:
> 
> <4>[ 7736.343865]  [] warn_slowpath_common+0x72/0xa0
> 
> <4>[ 7736.343888]  [] ? tcp_recvmsg+0x3bf/0x910
> 
> <4>[ 7736.343902]  [] ? tcp_recvmsg+0x3bf/0x910
> 
> <4>[ 7736.343922]  [] warn_slowpath_fmt+0x33/0x40
> 
> <4>[ 7736.343944]  [] tcp_recvmsg+0x3bf/0x910
> 
> <4>[ 7736.343968]  [] inet_recvmsg+0x85/0xa0
> 
> <4>[ 7736.343992]  [] sock_aio_read+0x140/0x160
> 
> <4>[ 7736.344016]  [] ? set_next_entity+0xc1/0xf0
> 
> <4>[ 7736.344039]  [] do_sync_read+0xb7/0xf0
> 
> <4>[ 7736.344064]  [] ? rw_verify_area+0x6c/0x120
> 
> <4>[ 7736.344077]  [] ? sys_epoll_wait+0x68/0x360
> 
> <4>[ 7736.344098]  [] vfs_read+0x149/0x160
> 
> <4>[ 7736.344120]  [] ? fget_light+0x58/0xd0
> 
> <4>[ 7736.344142]  [] sys_read+0x3d/0x70
> 
> <4>[ 7736.344164]  [] syscall_call+0x7/0xb
> 
> <4>[ 7736.344187]  [] ? perf_cpu_notify+0x45/0x89
> 
> <4>[ 7736.344205] ---[ end trace b3c5b245ce7ff5b5 ]---
> 

Thats exactly the interesting stuff ;)

This was fixed, or should be fixed if still happening on more recent
kernels.

Basically, once we are in this state, there is nothing we can do to
prevent a crash.

Please try to reproduce the issue using 3.9 or David trees (net-next or
net )

Thanks


--
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 v10 0/8] DMA Engine support for AM33XX

[Sekhar Nori]

Joel,

When you respin this, please base on top of Prabhakar's clean-up titled:
"ARM: edma: Convert to devm_* api".

Or better still, include his patch in your series.

Thanks,
Sekhar
--
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 RESEND v5] fat: editions to support fat_fallocate

[Namjae Jeon]

Hi, OGAWA.

We checked several cases with respect to your questions. But we cannot
find any issue.
Also, We compare the results with Ext4. It is same.
>cluster size == 512b

>1) create new file
>2) fallocate 100MB
>3) write(2) data for each 512b

>With this, write_begin() will be called for each 512b data. When we
>allocates new page for this file, write_begin() writes data 0-512. Then,
>we have to initialize 512-4096 by zero. Because mmap read maps 0-4096,
>even if i_size == 512.

>Who is initializing area for 512-4096?
When we checked, we found that page which is allocated to mmap is
already filled with zeros. And 512byte is filled in this page. If we
try to read mmap beyond the file size of 512 bytes , nulls are
returned . Hence , mmap works correctly in such cases .

>From other view, I guess fat_zero_falloc_area() is for filling zero for
>0-1, in the following case?

> 1) create new file
> 2) lseek(1)
> 3) write data by write(2)

>This job is for cont_write_begin(). If example is correct, why
>cont_write_begin() doesn't work? I guess, because get_block() doesn't
>set buffer_new() for those area.
If we will not call fallocate with keep size flags, cont_write_begin
will work and zero out on lseek area (this works like expanding
truncate).

>If above is correct, right implement to change get_block().
Now when we try to write in the fallocated region ( with keep size) in
the fat_write_begin when it is called first time it checks that the
mismatch is present between the mmu_private and mmu_actual , and hence
zero out the region ; since buffer_new is not set for fallocated
region by fat_get_block , we explicitly zero out the lseeked region
using “fat_zero_falloc_area” and normal write occurs beyond that , and
i_size is updated accordingly , and as such there is no need to move
the code to fat_get_block .
>I'm ok as start if it works.
>
>But from this discussion, discard at last close(2) doesn't look like
>working for your requirement. Since you want to discard at last close of
>inode, so, rather, I guess you actually want to discard at last
>dereference of inode.
We also moved the release of fallocated clusters from the
“fat_file_release” to “fat_evict_inode” and on the basis of i_count so
that the fallocated clusters are released at the last reference of the
inode.

Thanks.
--
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 irqdomain tree with the tree

[Stephen Rothwell]

Hi Grant,

Today's linux-next merge of the irqdomain tree got a conflict in
kernel/irq/irqdomain.c between commit c5cdc67a58a2 ("irqdomain: Remove
temporary MIPS workaround code") from the mips tree and commit
bd4641e31e90 ("irq: fix checkpatch error") from the irqdomain 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 kernel/irq/irqdomain.c
index a341b3d,13f2654..000
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@@ -665,8 -475,20 +475,8 @@@ unsigned int irq_create_of_mapping(stru
  
domain = controller ? irq_find_host(controller) : irq_default_domain;
if (!domain) {
-   pr_warning("no irq domain found for %s !\n",
-  of_node_full_name(controller));
 -#ifdef CONFIG_MIPS
 -  /*
 -   * Workaround to avoid breaking interrupt controller drivers
 -   * that don't yet register an irq_domain.  This is temporary
 -   * code. ~~~gcl, Feb 24, 2012
 -   *
 -   * Scheduled for removal in Linux v3.6.  That should be enough
 -   * time.
 -   */
 -  if (intsize > 0)
 -  return intspec[0];
 -#endif
+   pr_warn("no irq domain found for %s !\n",
+   of_node_full_name(controller));
return 0;
}
  


pgpwDUecySNMf.pgp
Description: PGP signature

Re: [Part1 PATCH v5 00/22] x86, ACPI, numa: Parse numa info earlier

[Tang Chen]

Hi tj,

On 06/18/2013 10:03 AM, Tejun Heo wrote:
..


So, can you please explain why you're doing the above?  What are you
trying to achieve in the end and why is this the best approach?  This
is all for memory hotplug, right?


Yes, this is all for memory hotplug.

[why]
At early boot time (before parsing SRAT), memblock will allocate memory
for kernel to use. But the memory could be hotpluggable memory because
at such an early time, we don't know which memory is hotpluggable. This
will cause hotpluggable memory un-hotpluggable. What we are trying to
do is to prevent memblock from allocating hotpluggable memory.

[approach]
Parse SRAT earlier before memblock starts to work, because there is a
bit in SRAT specifying which memory is hotpluggable.

I'm not saying this is the best approach. I can also see that this
patch-set touches a lot of boot code. But i think parsing SRAT earlier
is reasonable because this is the only way for now to know which memory
is hotpluggable from firmware.



I can understand the part where you're move NUMA discovery before
initializations which will get allocated permanent addresses in the
wrong nodes, but trying to do the same with memblock itself is making
the code extremely fragile.  It's nasty because there's nothing
apparent which seems to necessitate such ordering.  The ordering looks
rather arbitrary but changing the orders will subtly break memory
hotplug support, which is a really bad way to structure the code.

Can't you just move memblock arrays after NUMA init is complete?
That'd be a lot simpler and way more robust than the proposed changes,
no?


Sorry, I don't quite understand the approach you are suggesting. If we
move memblock arrays, we need to update all the pointers pointing to
the moved memory. How can we do this ?

Thanks. :)
--
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/2] Initial support for Allwinner's Security ID fuses

[Andy Shevchenko]

On Mon, Jun 17, 2013 at 11:59 PM, Oliver Schinagl
 wrote:
> From: Oliver Schinagl 
>
> Allwinner has electric fuses (efuse) on their line of chips. This driver
> reads those fuses, seeds the kernel entropy and exports them as a sysfs node.
>
> These fuses are most likly to be programmed at the factory, encoding
> things like Chip ID, some sort of serial number etc and appear to be
> reasonable unique.
> While in theory, these should be writeable by the user, it will probably
> be inconvinient to do so. Allwinner recommends that a certain input pin,
> labeled 'efuse_vddq', be connected to GND. To write these fuses, 2.5 V
> needs to be applied to this pin.
>
> Even so, they can still be used to generate a board-unique mac from, board
> unique RSA key and seed the kernel RNG.
>

> +++ b/drivers/misc/eeprom/sunxi_sid.c
> @@ -0,0 +1,147 @@

> +#include 

I don't think you have to use this header explicitly.

> +#define DRV_NAME "sunxi-sid"

> +   if (size > (SID_SIZE - pos))

Useless internal braces.

> +static int sunxi_sid_remove(struct platform_device *pdev)
> +{
> +   device_remove_bin_file(&pdev->dev, &sid_bin_attr);
> +   dev_dbg(&pdev->dev, "%s driver unloaded\n", DRV_NAME);

It's useless to use DRV_NAME in conjunction with dev_* macros. dev_*
will print driver name as a prefix.

--
With Best Regards,
Andy Shevchenko
--
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] clocksource: sh_cmt: 32-bit control register support

[Magnus Damm]

Hi Laurent,

On Tue, Jun 18, 2013 at 3:37 AM, Laurent Pinchart
 wrote:
> Hi Magnus,
>
> Thanks for the patch.
>
> On Monday 17 June 2013 15:40:52 Magnus Damm wrote:
>> From: Magnus Damm 
>>
>> Add support for CMT hardware with 32-bit control and counter
>> registers, as found on r8a73a4 and r8a7790. To use the CMT
>> with 32-bit hardware a second I/O memory resource needs to
>> point out the CMSTR register and it needs to be 32 bit wide.
>
> Is a memory second resource required ? Can't we use a single resource that
> will contain all the registers ?

The CMT hardware block comes with a shared timer start stop register
that historically has been left out of the resource. The location of
this register has so far been pointed out by the "channel offset"
platform data member, together with information about which bit that
happens to be assigned to the timer channel. This start stop register
has happened to be kept in the same page of I/O memory as the main
timer channel resource, so at this point we're sort of "lucky" that a
single ioremap() has covered all cases.

With this patch it becomes optional to instead of platform data use a
second resource to point out the timer start/stop register. While we
do that we can also use the size of that resource to determine the I/O
access width, which happens to be something that is needed to enable
the driver on certain SoCs.

> Time to switch to devm_* managed functions ? :-)

Yes, indeed. That among other things, like converting the driver to in
a more optimal way support clock source only or clock event only
configurations. Also, some more modern CMT hardware versions have
extended registers with 48-bit counters, and we can also often use
more high frequency clocks to improve timer resolution.

As you can tell, in general there are many things that can be improved
with this driver. I thought a first shot could be to make it actually
work on more recent CMT hardware with 32-bit only registers. So that's
what this patch does!

Cheers,

/ magnus
--
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 V5 1/3] pci: Add PCIe driver for Samsung Exynos

[Jingoo Han]

On Monday, June 17, 2013 9:45 PM, Arnd Bergmann wrote:
> On Monday 17 June 2013 18:45:52 Jingoo Han wrote:
> > On Friday, June 14, 2013 9:54 PM, Arnd Bergmann wrote:
> > >
[.]
> > > > > > +static int __exit exynos_pcie_remove(struct platform_device *pdev)
> > > > > > +{
> > > > > > +   struct pcie_port *pp = platform_get_drvdata(pdev);
> > > > > > +
> > > > > > +   clk_disable_unprepare(pp->bus_clk);
> > > > > > +   clk_disable_unprepare(pp->clk);
> > > > > > +
> > > > > > +   return 0;
> > > > > > +}
> > > > >
> > > > > You also don't remove the PCI devices here, as mentioned in an earlier
> > > > > review.
> > > >
> > > > I reviewed Marvell PCIe driver and Tegra PCIe driver; however,
> > > > I cannot know what you mean.
> > > >
> > > > Could let me know which additional functions are needed?
> > >
> > > The mvebu driver does not allow module unload. I haven't looked at the
> > > tegra driver. If you allow unloading the driver and provide a 'remove'
> > > callback, that callback needs to clean up the entire bus and remove
> > > all child devices that were added as well as undo everything the
> > > probe function did. I think it would be great if you can do that, although
> > > it might not be easy. The simplest solution would be to not support
> > > unloading though.
> >
> > As the mvebu driver uses platform_driver_probe(), the Exynos driver uses
> > platform_driver_probe(). Thus, I will not provide a 'remove' callback.
> 
> Well, the important part is not to provide a module_exit() function, which
> will ensure the driver cannot be unloaded.

Aha, I see.
I will not provide a module_exit() function), as the mvebu driver does.

Best regards,
Jingoo Han

> 
>   Arnd

--
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 4/4] idr: Percpu ida

[Kent Overstreet]

Percpu frontend for allocating ids. With percpu allocation (that works),
it's impossible to guarantee it will always be possible to allocate all
nr_tags - typically, some will be stuck on a remote percpu freelist
where the current job can't get to them.

We do guarantee that it will always be possible to allocate at least
(nr_tags / 2) tags - this is done by keeping track of which and how many
cpus have tags on their percpu freelists. On allocation failure if
enough cpus have tags that there could potentially be (nr_tags / 2) tags
stuck on remote percpu freelists, we then pick a remote cpu at random to
steal from.

Note that the synchronization is _definitely_ tricky - we're using
xchg()/cmpxchg() on the percpu lists, to synchronize between
steal_tags().

The alternative would've been adding a spinlock to protect the percpu
freelists, but that would've required some different tricky code to
avoid deadlock because of the lock ordering.

Note that there's no cpu hotplug notifier - we don't care, because
steal_tags() will eventually get the down cpu's tags. We _could_ satisfy
more allocations if we had a notifier - but we'll still meet our
guarantees and it's absolutely not a correctness issue, so I don't think
it's worth the extra code.

Signed-off-by: Kent Overstreet 
Cc: Tejun Heo 
Cc: Oleg Nesterov 
Cc: Christoph Lameter 
Cc: Ingo Molnar 
Cc: Andi Kleen 
Cc: Jens Axboe 
Cc: "Nicholas A. Bellinger" 
---
 include/linux/idr.h |  48 
 lib/idr.c   | 312 ++--
 2 files changed, 352 insertions(+), 8 deletions(-)

diff --git a/include/linux/idr.h b/include/linux/idr.h
index 9169e18..afaa071 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* IDA */
 
@@ -97,6 +99,52 @@ static inline void ida_init(struct ida *ida)
ida_init_prealloc(ida, 0);
 }
 
+/* Percpu IDA/tag allocator */
+
+struct percpu_ida_cpu;
+
+struct percpu_ida {
+   /*
+* number of tags available to be allocated, as passed to
+* percpu_ida_init()
+*/
+   unsignednr_tags;
+
+   struct percpu_ida_cpu __percpu  *tag_cpu;
+
+   /*
+* Bitmap of cpus that (may) have tags on their percpu freelists:
+* steal_tags() uses this to decide when to steal tags, and which cpus
+* to try stealing from.
+*
+* It's ok for a freelist to be empty when its bit is set - steal_tags()
+* will just keep looking - but the bitmap _must_ be set whenever a
+* percpu freelist does have tags.
+*/
+   unsigned long   *cpus_have_tags;
+
+   struct {
+   /*
+* When we go to steal tags from another cpu (see steal_tags()),
+* we want to pick a cpu at random. Cycling through them every
+* time we steal is a bit easier and more or less equivalent:
+*/
+   unsignedcpu_last_stolen;
+
+   /* For sleeping on allocation failure */
+   wait_queue_head_t   wait;
+
+   /* Global freelist */
+   struct ida  ida;
+   } cacheline_aligned_in_smp;
+};
+
+int percpu_ida_alloc(struct percpu_ida *pool, gfp_t gfp);
+void percpu_ida_free(struct percpu_ida *pool, unsigned tag);
+
+void percpu_ida_destroy(struct percpu_ida *pool);
+int percpu_ida_init(struct percpu_ida *pool, unsigned long nr_tags);
+
 /* IDR */
 
 /*
diff --git a/lib/idr.c b/lib/idr.c
index 7d89587..401933f 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -28,17 +28,20 @@
  * with the slab allocator.
  */
 
-#ifndef TEST// to test in user space...
-#include 
-#include 
-#include 
-#endif
+#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 #define IDA_TREE_ARY   BITS_PER_LONG
 
@@ -527,6 +530,299 @@ int ida_init_prealloc(struct ida *ida, unsigned prealloc)
 }
 EXPORT_SYMBOL(ida_init_prealloc);
 
+/* Percpu IDA */
+
+/*
+ * Number of tags we move between the percpu freelist and the global freelist 
at
+ * a time
+ */
+#define TAG_CPU_BATCH_MOVE 32U
+
+/* Max size of percpu freelist, */
+#define TAG_CPU_SIZE   (TAG_CPU_BATCH_MOVE + TAG_CPU_BATCH_MOVE / 2)
+
+struct percpu_ida_cpu {
+   spinlock_t  lock;
+   unsignednr_free;
+   unsignedfreelist[];
+};
+
+/*
+ * Try to steal tags from a remote cpu's percpu freelist.
+ *
+ * We first check how many percpu freelists have tags - we don't steal tags
+ * unless enough percpu freelists have tags on them that it's possible more 
than
+ * half the total tags could be stuck on remote percpu freelists.
+ *
+ * Then we iterate through the cpus until we find some tags - we don't at

[PATCH 3/4] idr: Rewrite ida

[Kent Overstreet]

This is a new, from scratch implementation of ida that should be
simpler, faster and more space efficient.

Two primary reasons for the rewrite:
 * A future patch will reimplement idr on top of this ida implementation +
   radix trees. Once that's done, the end result will be ~1k fewer lines
   of code, much simpler and easier to understand and it should be quite
   a bit faster.

 * The performance improvements and addition of ganged allocation should
   make ida more suitable for use by a percpu id/tag allocator, which
   would then act as a frontend to this allocator.

The old ida implementation was done with the idr data structures - this
was IMO backwards. I'll soon be reimplementing idr on top of this new
ida implementation and radix trees - using a separate dedicated data
structure for the free ID bitmap should actually make idr faster, and
the end result is _significantly_ less code.

This implementation conceptually isn't that different from the old one -
it's a tree of bitmaps, where one bit in a given node indicates whether
or not there are free bits in a child node.

The main difference (and advantage) over the old version is that the
tree isn't implemented with pointers - it's implemented in an array,
like how heaps are implemented, which both better space efficiency and
it'll be faster since there's no pointer chasing.

This does mean that the entire bitmap is stored in one contiguous memory
allocation - and as currently implemented we won't be able to allocate
_quite_ as many ids as with the previous implementation.

I don't expect this to be an issue in practice since anywhere this is
used, an id corresponds to a struct allocation somewher else - we can't
allocate an unbounded number of ids, we'll run out of memory somewhere
else eventually, and I expect that to be the limiting factor in
practice.

If a user/use case does come up where this matters I can add some
sharding (or perhaps add a separate big_ida implementation) - but the
extra complexity would adversely affect performance for the users that
don't need > millions of ids, so I intend to leave the implementation as
is until if and when this becomes an issue.

Signed-off-by: Kent Overstreet 
Cc: Andrew Morton 
Cc: Tejun Heo 
Cc: Stephen Rothwell 
Cc: Fengguang Wu 
---
 include/linux/idr.h | 118 +---
 lib/idr.c   | 776 +---
 2 files changed, 573 insertions(+), 321 deletions(-)

diff --git a/include/linux/idr.h b/include/linux/idr.h
index c0e0c54..9169e18 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -17,6 +17,88 @@
 #include 
 #include 
 
+/* IDA */
+
+#define IDA_INLINE_NODES   4
+
+struct ida {
+   spinlock_t  lock;
+
+   /*
+* cur_id and allocated_ids are for ida_alloc_cyclic. For cyclic
+* allocations we search for new ids to allocate starting from the last
+* id allocated - cur_id is the next id to try allocating.
+*
+* But we also don't want the allocated ids to be arbitrarily sparse -
+* the memory usage for the bitmap could be arbitrarily bad, and if
+* they're used as keys in a radix tree the memory overhead of the radix
+* tree could be quite bad as well. So we use allocated_ids to decide
+* when to restart cur_id from 0, and bound how sparse the bitmap can
+* be.
+*/
+   unsignedcur_id;
+   unsignedallocated_ids;
+
+   /* size of ida->tree */
+   unsignednodes;
+
+   /*
+* Index of first leaf node in ida->tree; equal to the number of non
+* leaf nodes, ida->nodes - ida->first_leaf == number of leaf nodes
+*/
+   unsignedfirst_leaf;
+
+   unsigned long   *tree;
+   unsigned long   inline_nodes[IDA_INLINE_NODES];
+};
+
+#define IDA_INIT(name) \
+{  \
+   .lock   = __SPIN_LOCK_UNLOCKED(name.lock),  \
+   .nodes  = IDA_INLINE_NODES, \
+   .first_leaf = 1,\
+   .tree   = name.inline_nodes,\
+}
+#define DEFINE_IDA(name)   struct ida name = IDA_INIT(name)
+
+void ida_remove(struct ida *ida, unsigned id);
+int ida_alloc_range(struct ida *ida, unsigned int start,
+ unsigned int end, gfp_t gfp);
+int ida_alloc_cyclic(struct ida *ida, unsigned start, unsigned end, gfp_t gfp);
+void ida_destroy(struct ida *ida);
+int ida_init_prealloc(struct ida *ida, unsigned prealloc);
+
+/**
+ * ida_alloc_range - allocate a new id.
+ * @ida: the (initialized) ida.
+ * @gfp_mask: memory allocation flags
+ *
+ * Allocates an id in the range [0, INT_MAX]. Returns -ENOSPC if no ids are
+ * available, or -ENOMEM on memory allocation failure.
+ *
+ * Returns the smallest available id
+ *
+ * Use id

RE: [PATCH 1/4] MFD: Palmas: Add Interrupt feature

[J, KEERTHY]

Hi Mark,

Thanks for the review.

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Monday, June 17, 2013 9:46 PM
> To: J, KEERTHY
> Cc: linux-o...@vger.kernel.org; ldewan...@nvidia.com;
> sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> g...@slimlogic.co.uk
> Subject: Re: [PATCH 1/4] MFD: Palmas: Add Interrupt feature
> 
> On Mon, Jun 17, 2013 at 05:39:11PM +0530, J Keerthy wrote:
> 
> > Palmas PMICs have an INT line. This line is one single Interrupt line
> > to the application processor. The interrupt feature enables to
> > selectively request irq for only those specific chips which have INT
> > line connected to a valid IRQ line of the application processor.
> 
> Does the support for the interrupt line need to be explicitly flagged
> like this or can the driver not simply support an interrupt line not
> being configured?  That would also support cases where the hardware has
> an interrupt line but the system integrator has opeted not to connect
> it for some reason which seems generally more flexible than doing
> things on a chip ID basis.
> 

I understand your point. The IRQ is passed from device tree node.
Say if the chip for some reason is not connected to any valid
IRQ line the driver might end up requesting for a wrong IRQ line.

So should I be validating the irq entry populated from  device tree?

Explicitly checking on chip ID helps to avoid wrongly populated
Device tree data. 

> > +/**
> > + * DOC: Palmas PMIC feature types
> > + *
> 
> Is "DOC: " normal kerneldoc?

Normal kerneldoc I shall remove "DOC:"

Regards,
Keerthy
--
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] drivers: hv: switch to use mb() instead of smp_mb()

[Jason Wang]

Even if guest were compiled without SMP support, it could not assume that host
wasn't. So switch to use mb() instead of smp_mb() to force memory barriers for
UP guest.

Cc: K. Y. Srinivasan 
Cc: Haiyang Zhang 
Cc: sta...@vger.kernel.org
Signed-off-by: Jason Wang 
---
 drivers/hv/ring_buffer.c |   10 +-
 drivers/hv/vmbus_drv.c   |2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
index d6fbb57..791f45d 100644
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -32,7 +32,7 @@
 void hv_begin_read(struct hv_ring_buffer_info *rbi)
 {
rbi->ring_buffer->interrupt_mask = 1;
-   smp_mb();
+   mb();
 }
 
 u32 hv_end_read(struct hv_ring_buffer_info *rbi)
@@ -41,7 +41,7 @@ u32 hv_end_read(struct hv_ring_buffer_info *rbi)
u32 write;
 
rbi->ring_buffer->interrupt_mask = 0;
-   smp_mb();
+   mb();
 
/*
 * Now check to see if the ring buffer is still empty.
@@ -71,7 +71,7 @@ u32 hv_end_read(struct hv_ring_buffer_info *rbi)
 
 static bool hv_need_to_signal(u32 old_write, struct hv_ring_buffer_info *rbi)
 {
-   smp_mb();
+   mb();
if (rbi->ring_buffer->interrupt_mask)
return false;
 
@@ -442,7 +442,7 @@ int hv_ringbuffer_write(struct hv_ring_buffer_info 
*outring_info,
 sizeof(u64));
 
/* Issue a full memory barrier before updating the write index */
-   smp_mb();
+   mb();
 
/* Now, update the write location */
hv_set_next_write_location(outring_info, next_write_location);
@@ -549,7 +549,7 @@ int hv_ringbuffer_read(struct hv_ring_buffer_info 
*inring_info, void *buffer,
/* Make sure all reads are done before we update the read index since */
/* the writer may start writing to the read area once the read index */
/*is updated */
-   smp_mb();
+   mb();
 
/* Update the read index */
hv_set_next_read_location(inring_info, next_read_location);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index bf421e0..4004e54 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -434,7 +434,7 @@ static void vmbus_on_msg_dpc(unsigned long data)
 * will not deliver any more messages since there is
 * no empty slot
 */
-   smp_mb();
+   mb();
 
if (msg->header.message_flags.msg_pending) {
/*
-- 
1.7.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/

Re: [PATCH] Allow binding drivers/uio/uio_pdrv_genirq.c to devices using command line option

[Sachin Kamat]

Hi Greg,

On 17 June 2013 23:07, Greg KH  wrote:
> On Mon, Jun 17, 2013 at 03:47:41PM +0200, Pavel Machek wrote:
>> Hi!
>>
>> > This adds ability to bind uio driver to given open firmware device
>> > using command line option. Thus, userspace driver can be developed and
>> > used without modifying the kernel.
>> >
>> > Signed-off-by: Pavel Machek 
>>
>> Ping? Greg, could you apply this patch? Or is there someone else I
>> should ask to apply it?
>
> Ugh, Hans seems to have dropped off of the net for a long time now, so I
> guess I'll start queueing up UIO patches again.  Care to resend this?
>

Even I have a couple of outstanding UIO patches [1-2]. Shall I resend
them as well?

[1] https://lkml.org/lkml/2013/3/14/154
[2] https://patchwork.kernel.org/patch/2268921/


-- 
With warm regards,
Sachin
--
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/

[RESEND PATCH v1 2/3] spi: s3c64xx: Added provision for dedicated cs pin

[girishks2000]

From: Girish K S 

The existing driver supports gpio based /cs signal.
For controller's that have one device per controller,
the slave device's /cs signal might be internally controlled
by the chip select bit of slave select register. They are not
externally asserted/deasserted using gpio pin.

This patch adds support for controllers with dedicated /cs pin.
if "cs-gpio" property doesnt exist in a spi dts node, the controller
would treat the /cs pin as dedicated.

Signed-off-by: Girish K S 
---
changes in v1:
Added the missing data structure that caused the
compilation error

 drivers/spi/spi-s3c64xx.c |   34 ++
 1 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 0a80692..eaf9e1c 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -208,6 +208,7 @@ struct s3c64xx_spi_driver_data {
struct s3c64xx_spi_port_config  *port_conf;
unsigned intport_id;
unsigned long   gpios[4];
+   boolcs_gpio;
 };
 
 static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
@@ -570,14 +571,16 @@ static inline void enable_cs(struct 
s3c64xx_spi_driver_data *sdd,
if (sdd->tgl_spi != spi) { /* if last mssg on diff device */
/* Deselect the last toggled device */
cs = sdd->tgl_spi->controller_data;
-   gpio_set_value(cs->line,
-   spi->mode & SPI_CS_HIGH ? 0 : 1);
+   if (sdd->cs_gpio)
+   gpio_set_value(cs->line,
+   spi->mode & SPI_CS_HIGH ? 0 : 1);
}
sdd->tgl_spi = NULL;
}
 
cs = spi->controller_data;
-   gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+   if (sdd->cs_gpio)
+   gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
 
/* Start the signals */
writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -709,7 +712,8 @@ static inline void disable_cs(struct 
s3c64xx_spi_driver_data *sdd,
if (sdd->tgl_spi == spi)
sdd->tgl_spi = NULL;
 
-   gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
+   if (sdd->cs_gpio)
+   gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 0 : 1);
 
/* Quiese the signals */
writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
@@ -997,8 +1001,10 @@ static struct s3c64xx_spi_csinfo 
*s3c64xx_get_slave_ctrldata(
 {
struct s3c64xx_spi_csinfo *cs;
struct device_node *slave_np, *data_np = NULL;
+   struct s3c64xx_spi_driver_data *sdd;
u32 fb_delay = 0;
 
+   sdd = spi_master_get_devdata(spi->master);
slave_np = spi->dev.of_node;
if (!slave_np) {
dev_err(&spi->dev, "device node not found\n");
@@ -1018,7 +1024,10 @@ static struct s3c64xx_spi_csinfo 
*s3c64xx_get_slave_ctrldata(
return ERR_PTR(-ENOMEM);
}
 
-   cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+   /* The CS line is asserted/deasserted by the gpio pin */
+   if (sdd->cs_gpio)
+   cs->line = of_get_named_gpio(data_np, "cs-gpio", 0);
+
if (!gpio_is_valid(cs->line)) {
dev_err(&spi->dev, "chip select gpio is not specified or 
invalid\n");
kfree(cs);
@@ -1058,7 +1067,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
return -ENODEV;
}
 
-   if (!spi_get_ctldata(spi)) {
+   /* Request gpio only if cs line is asserted by gpio pins */
+   if (sdd->cs_gpio) {
err = gpio_request_one(cs->line, GPIOF_OUT_INIT_HIGH,
   dev_name(&spi->dev));
if (err) {
@@ -1067,9 +1077,11 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
cs->line, err);
goto err_gpio_req;
}
-   spi_set_ctldata(spi, cs);
}
 
+   if (!spi_get_ctldata(spi))
+   spi_set_ctldata(spi, cs);
+
sci = sdd->cntrlr_info;
 
spin_lock_irqsave(&sdd->lock, flags);
@@ -1147,8 +1159,10 @@ err_gpio_req:
 static void s3c64xx_spi_cleanup(struct spi_device *spi)
 {
struct s3c64xx_spi_csinfo *cs = spi_get_ctldata(spi);
+   struct s3c64xx_spi_driver_data *sdd;
 
-   if (cs) {
+   sdd = spi_master_get_devdata(spi->master);
+   if (cs && sdd->cs_gpio) {
gpio_free(cs->line);
if (spi->dev.of_node)
kfree(cs);
@@ -1325,7 +1339,11 @@ static int s3c64xx_spi_probe(struct platform_device 
*pdev)
sdd->cntrlr_info = sci;
sdd->pdev = pdev;
sdd->sfr_start = mem_res->start;
+   sdd->cs_gpio = false;
if (pdev->dev.of_node) {
+ 

[RESEND PATCH v1 1/3] spi: s3c64xx: added support for polling mode

[girishks2000]

From: Girish K S 

The 64xx spi driver supports partial polling mode.
Only the last chunk of the transfer length is transferred
or recieved in polling mode.

Some SoC's that adopt this controller might not have have dma
interface. This patch adds support for complete polling mode
and gives flexibity for the user to select poll/dma mode.

Signed-off-by: Girish K S 
---
changes in v1:
Addressed the performance issue reported by Mark Brown
caused due to this patch. The wait_for_timeout function is modified to
address this issue in dma mode.

 drivers/spi/spi-s3c64xx.c |  153 ++--
 1 files changed, 104 insertions(+), 49 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 5000586..0a80692 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -39,6 +39,7 @@
 #endif
 
 #define MAX_SPI_PORTS  3
+#define S3C64XX_SPI_QUIRK_POLL (1 << 0)
 
 /* Registers and bit-fields */
 
@@ -130,6 +131,7 @@
 #define S3C64XX_SPI_TRAILCNT   S3C64XX_SPI_MAX_TRAILCNT
 
 #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
+#define is_polling(x)  (x->port_conf->quirks & S3C64XX_SPI_QUIRK_POLL)
 
 #define RXBUSY(1<<2)
 #define TXBUSY(1<<3)
@@ -158,6 +160,7 @@ struct s3c64xx_spi_port_config {
int fifo_lvl_mask[MAX_SPI_PORTS];
int rx_lvl_offset;
int tx_st_done;
+   int quirks;
boolhigh_speed;
boolclk_from_cmu;
 };
@@ -344,8 +347,12 @@ static int s3c64xx_spi_prepare_transfer(struct spi_master 
*spi)
 {
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
-   /* Acquire DMA channels */
-   while (!acquire_dma(sdd))
+   /*
+* If DMA resource was not available during
+* probe, no need to continue with dma requests
+* else Acquire DMA channels
+*/
+   while (!is_polling(sdd) && !acquire_dma(sdd))
usleep_range(1, 11000);
 
pm_runtime_get_sync(&sdd->pdev->dev);
@@ -358,9 +365,12 @@ static int s3c64xx_spi_unprepare_transfer(struct 
spi_master *spi)
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
/* Free DMA channels */
-   sdd->ops->release((enum dma_ch)sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
-   sdd->ops->release((enum dma_ch)sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
-
+   if (!is_polling(sdd)) {
+   sdd->ops->release((enum dma_ch)sdd->rx_dma.ch,
+   &s3c64xx_spi_dma_client);
+   sdd->ops->release((enum dma_ch)sdd->tx_dma.ch,
+   &s3c64xx_spi_dma_client);
+   }
pm_runtime_put(&sdd->pdev->dev);
 
return 0;
@@ -464,8 +474,10 @@ static int s3c64xx_spi_unprepare_transfer(struct 
spi_master *spi)
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
/* Free DMA channels */
-   dma_release_channel(sdd->rx_dma.ch);
-   dma_release_channel(sdd->tx_dma.ch);
+   if (!is_polling(sdd)) {
+   dma_release_channel(sdd->rx_dma.ch);
+   dma_release_channel(sdd->tx_dma.ch);
+   }
 
pm_runtime_put(&sdd->pdev->dev);
return 0;
@@ -566,6 +578,30 @@ static inline void enable_cs(struct 
s3c64xx_spi_driver_data *sdd,
 
cs = spi->controller_data;
gpio_set_value(cs->line, spi->mode & SPI_CS_HIGH ? 1 : 0);
+
+   /* Start the signals */
+   writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
+}
+
+static u32 wait_for_timeout(struct s3c64xx_spi_driver_data *sdd,
+   int timeout_ms)
+{
+   void __iomem *regs = sdd->regs;
+   unsigned long val = 1;
+   u32 status;
+
+   /* max fifo depth available */
+   u32 max_fifo = (FIFO_LVL_MASK(sdd) >> 1) + 1;
+
+   if (timeout_ms)
+   val = msecs_to_loops(timeout_ms);
+
+   do {
+   status = readl(regs + S3C64XX_SPI_STATUS);
+   } while (RX_FIFO_LVL(status, sdd) < max_fifo && --val);
+
+   /* return the actual received data length */
+   return RX_FIFO_LVL(status, sdd);
 }
 
 static int wait_for_xfer(struct s3c64xx_spi_driver_data *sdd,
@@ -590,20 +626,19 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data 
*sdd,
} while (RX_FIFO_LVL(status, sdd) < xfer->len && --val);
}
 
-   if (!val)
-   return -EIO;
-
if (dma_mode) {
u32 status;
 
/*
+* If the previous xfer was completed within timeout, then
+* proceed further else return -EIO.
 * DmaTx returns after simply writing data in the FIFO,
 * w/o waiting for real transmission on the bus to finish.
 * DmaRx returns only after Dma read data from FIFO which
 * needs bus transmission to finish, so we don't worry if
 * Xfer

[RESEND PATCH v1 0/3] Polling support for s3c64xx spi controller

[girishks2000]

From: Girish K S 

This patch series adds support for the polling mode only. Also 2nd patch
in the series adds support for dedicated cs pin. After Thomas's patch for
using default gpio is merged(commit id: 00ab539), one of the patch in this
series is dropped and new series is generated.

Girish K S (3):
  spi: s3c64xx: added support for polling mode
  spi: s3c64xx: Added provision for dedicated cs pin
  spi: s3c64xx: Added support for exynos5440 spi

 drivers/spi/spi-s3c64xx.c |  197 -
 1 files changed, 140 insertions(+), 57 deletions(-)

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

[RESEND PATCH v1 3/3] spi: s3c64xx: Added support for exynos5440 spi

[girishks2000]

From: Girish K S 

This patch adds support for the exynos5440 spi controller.
The integration of the spi IP in exynos5440 is different from
other SoC's. The I/O pins are no more configured via gpio, they
have dedicated pins.

Signed-off-by: Girish K S 
---
 drivers/spi/spi-s3c64xx.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index eaf9e1c..bd43888 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1608,6 +1608,15 @@ static struct s3c64xx_spi_port_config 
exynos4_spi_port_config = {
.clk_from_cmu   = true,
 };
 
+static struct s3c64xx_spi_port_config exynos5440_spi_port_config = {
+   .fifo_lvl_mask  = { 0x1ff },
+   .rx_lvl_offset  = 15,
+   .tx_st_done = 25,
+   .high_speed = true,
+   .clk_from_cmu   = true,
+   .quirks = S3C64XX_SPI_QUIRK_POLL,
+};
+
 static struct platform_device_id s3c64xx_spi_driver_ids[] = {
{
.name   = "s3c2443-spi",
@@ -1636,6 +1645,9 @@ static const struct of_device_id s3c64xx_spi_dt_match[] = 
{
{ .compatible = "samsung,exynos4210-spi",
.data = (void *)&exynos4_spi_port_config,
},
+   { .compatible = "samsung,exynos5440-spi",
+   .data = (void *)&exynos5440_spi_port_config,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, s3c64xx_spi_dt_match);
-- 
1.7.5.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: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

[Alex Shi]

On 06/07/2013 03:29 PM, Alex Shi wrote:
> Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
> smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
> vaiables to describe them. unsigned long is more efficient and convenience.
> 

update with a a bit clean up in tg_load_down()
---

>From e78ccc55dff1a5ef406a100f6453d0b8c86ca310 Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Thu, 6 Jun 2013 20:12:36 +0800
Subject: [PATCH 1/5] sched: change cfs_rq load avg to unsigned long

Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
variables to describe them. unsigned long is more efficient and convenience.

Signed-off-by: Alex Shi 
Reviewed-by: Paul Turner 
Tested-by: Vincent Guittot 
---
 kernel/sched/debug.c | 4 ++--
 kernel/sched/fair.c  | 7 ++-
 kernel/sched/sched.h | 2 +-
 3 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 75024a6..160afdc 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -211,9 +211,9 @@ void print_cfs_rq(struct seq_file *m, int cpu, struct 
cfs_rq *cfs_rq)
SEQ_printf(m, "  .%-30s: %ld\n", "load", cfs_rq->load.weight);
 #ifdef CONFIG_FAIR_GROUP_SCHED
 #ifdef CONFIG_SMP
-   SEQ_printf(m, "  .%-30s: %lld\n", "runnable_load_avg",
+   SEQ_printf(m, "  .%-30s: %ld\n", "runnable_load_avg",
cfs_rq->runnable_load_avg);
-   SEQ_printf(m, "  .%-30s: %lld\n", "blocked_load_avg",
+   SEQ_printf(m, "  .%-30s: %ld\n", "blocked_load_avg",
cfs_rq->blocked_load_avg);
SEQ_printf(m, "  .%-30s: %lld\n", "tg_load_avg",
(unsigned long 
long)atomic64_read(&cfs_rq->tg->load_avg));
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 395f57c..39a5bae 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4186,12 +4186,9 @@ static int tg_load_down(struct task_group *tg, void 
*data)
if (!tg->parent) {
load = cpu_rq(cpu)->avg.load_avg_contrib;
} else {
-   unsigned long tmp_rla;
-   tmp_rla = tg->parent->cfs_rq[cpu]->runnable_load_avg + 1;
-
load = tg->parent->cfs_rq[cpu]->h_load;
-   load *= tg->se[cpu]->avg.load_avg_contrib;
-   load /= tmp_rla;
+   load = div64_ul(load * tg->se[cpu]->avg.load_avg_contrib,
+   tg->parent->cfs_rq[cpu]->runnable_load_avg + 1);
}
 
tg->cfs_rq[cpu]->h_load = load;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 0684c26..762fa63 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -277,7 +277,7 @@ struct cfs_rq {
 * This allows for the description of both thread and group usage (in
 * the FAIR_GROUP_SCHED case).
 */
-   u64 runnable_load_avg, blocked_load_avg;
+   unsigned long runnable_load_avg, blocked_load_avg;
atomic64_t decay_counter, removed_load;
u64 last_decay;
 
-- 
1.7.12

--
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 staging tree with the usb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/serqt_usb2/serqt_usb2.c between commit 1143832eca8f
("USB: serial: ports: add minor and port number") from the usb tree and
commit d68edc2881b1 ("staging: serqt_usb2: Fixed coding style
CamelCases") from the staging 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 drivers/staging/serqt_usb2/serqt_usb2.c
index 880f5c0,39de5e0..000
--- a/drivers/staging/serqt_usb2/serqt_usb2.c
+++ b/drivers/staging/serqt_usb2/serqt_usb2.c
@@@ -870,10 -870,10 +870,10 @@@ static int qt_open(struct tty_struct *t
usb_clear_halt(serial->dev, port->read_urb->pipe);
port0->open_ports++;
  
-   result = qt_get_device(serial, &port0->DeviceData);
+   result = qt_get_device(serial, &port0->device_data);
  
/* Port specific setups */
-   result = qt_open_channel(serial, port->port_number, &ChannelData);
 -  result = qt_open_channel(serial, port->number, &channel_data);
++  result = qt_open_channel(serial, port->port_number, &channel_data);
if (result < 0) {
dev_dbg(&port->dev, "qt_open_channel failed\n");
return result;
@@@ -1239,23 -1245,25 +1239,23 @@@ static void qt_set_termios(struct tty_s
  
/* Now determine flow control */
if (cflag & CRTSCTS) {
 -  dev_dbg(&port->dev, "%s - Enabling HW flow control port %d\n",
 -  __func__, port->number);
 +  dev_dbg(&port->dev, "%s - Enabling HW flow control\n", 
__func__);
  
/* Enable RTS/CTS flow control */
-   status = BoxSetHW_FlowCtrl(port->serial, index, 1);
+   status = box_set_hw_flow_ctrl(port->serial, index, 1);
  
if (status < 0) {
-   dev_dbg(&port->dev, "BoxSetHW_FlowCtrl failed\n");
+   dev_dbg(&port->dev, "box_set_hw_flow_ctrl failed\n");
return;
}
} else {
/* Disable RTS/CTS flow control */
dev_dbg(&port->dev,
 -  "%s - disabling HW flow control port %d\n",
 -  __func__, port->number);
 +  "%s - disabling HW flow control\n", __func__);
  
-   status = BoxSetHW_FlowCtrl(port->serial, index, 0);
+   status = box_set_hw_flow_ctrl(port->serial, index, 0);
if (status < 0) {
-   dev_dbg(&port->dev, "BoxSetHW_FlowCtrl failed\n");
+   dev_dbg(&port->dev, "box_set_hw_flow_ctrl failed\n");
return;
}
  
@@@ -1324,12 -1332,12 +1324,12 @@@ static inline int qt_real_tiocmget(stru
int status;
unsigned int index;
  
 -  index = tty->index - serial->minor;
 +  index = port->port_number;
status =
-   BoxGetRegister(port->serial, index, MODEM_CONTROL_REGISTER, &mcr);
+   box_get_register(port->serial, index, MODEM_CONTROL_REGISTER, &mcr);
if (status >= 0) {
status =
-   BoxGetRegister(port->serial, index,
+   box_get_register(port->serial, index,
   MODEM_STATUS_REGISTER, &msr);
  
}
@@@ -1363,9 -1371,9 +1363,9 @@@ static inline int qt_real_tiocmset(stru
int status;
unsigned int index;
  
 -  index = tty->index - serial->minor;
 +  index = port->port_number;
status =
-   BoxGetRegister(port->serial, index, MODEM_CONTROL_REGISTER, &mcr);
+   box_get_register(port->serial, index, MODEM_CONTROL_REGISTER, &mcr);
if (status < 0)
return -ESPIPE;
  


pgpN_pQeyeEEz.pgp
Description: PGP signature

Re: Build regressions/improvements in v3.10-rc6

[Michael Ellerman]

On Mon, Jun 17, 2013 at 09:19:51PM +0200, Geert Uytterhoeven wrote:
> On Mon, 17 Jun 2013, Geert Uytterhoeven wrote:
> 
> powerpc-randconfig

>   + arch/powerpc/include/asm/mmu-hash64.h: error: control reaches end of 
> non-void function [-Werror=return-type]:  => 180:1

This is running past a BUG(), which must mean we have CONFIG_BUG=n.
BUG() turning into nothing is a bug in the CONFIG_BUG=n implementation IMHO.
There was a discussion about this recently, I didn't see what the resolution
was.

>   + arch/powerpc/kvm/book3s_hv.c: error: 'vcpus_to_update[need_vpa_update]' 
> may be used uninitialized in this function [-Werror=uninitialized]:  => 
> 1187:22

This looks bogus to me:

  if (need_vpa_update) {
spin_unlock(&vc->lock);
for (i = 0; i < need_vpa_update; ++i) 
kvmppc_update_vpas(vcpus_to_update[i]);

I fail to see how that accesses vcpus_to_update[need_vpa_update].

>   + arch/powerpc/platforms/cell/beat_iommu.c: error: 'dma_base' may be used 
> uninitialized in this function [-Werror=uninitialized]:  => 69:11
>   + arch/powerpc/platforms/cell/beat_iommu.c: error: 'dma_size' may be used 
> uninitialized in this function [-Werror=uninitialized]:  => 68:2
>   + arch/powerpc/platforms/cell/beat_iommu.c: error: 'io_page_size' may be 
> used uninitialized in this function [-Werror=uninitialized]:  => 68:54
>   + arch/powerpc/platforms/cell/beat_wrapper.h: error: 'io_space_id' may be 
> used uninitialized in this function [-Werror=uninitialized]:  => 249:2
>   + arch/powerpc/platforms/cell/beat_wrapper.h: error: 'ioid' may be used 
> uninitialized in this function [-Werror=uninitialized]:  => 249:2

The above are all false warnings AFAICS.

> We need more randconfig builds to divert attention from powerpc ;-)

Or we could just drop them, with all the false positives from -Wuninitialized
it's hard to spot any real problems.

cheers
--
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 v2 2/2] mmc: dw_mmc: Add the ability to set the ciu clock frequency

[Jaehoon Chung]

Hi Doug,

I have one question for using .
I found the fixed-rate-clocks feature.
If we want to set , then can we use the fixed-rate-clocks?
i'm not sure how use the fixed-rate-clocks. but it seems to set fixed-rate 
value for clock frequency.

clk_set_rate() didn't ensure to set the  value.

Best Regards,
Jaehoon Chung

On 06/08/2013 02:28 AM, Doug Anderson wrote:
> As of now we rely on code outside of the driver to set the ciu clock
> frequency.  There's no reason to do that.  Add support for setting up
> the clock in the driver during probe.
> 
> Signed-off-by: Doug Anderson 
> Acked-by: Jaehoon Chung 
> ---
> Changes in v2:
> - Added example as per Jaehoon.
> 
>  .../devicetree/bindings/mmc/synopsis-dw-mshc.txt| 16 
>  drivers/mmc/host/dw_mmc.c   | 17 
> +
>  2 files changed, 29 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt 
> b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
> index d5cc94e..dd31b00 100644
> --- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
> @@ -39,6 +39,19 @@ Required Properties:
>  
>  Optional properties:
>  
> +* clocks: from common clock binding: handle to biu and ciu clocks for the
> +  bus interface unit clock and the card interface unit clock.
> +
> +* clock-names: from common clock binding: Shall be "biu" and "ciu".
> +  If the biu clock is missing we'll simply skip enabling it.  If the
> +  ciu clock is missing we'll just assume that the clock is running at
> +  clock-frequency.  It is an error to omit both the ciu clock and the
> +  clock-frequency.
> +
> +* clock-frequency: should be the frequency (in Hz) of the ciu clock.  If this
> +  is specified and the ciu clock is specified then we'll try to set the ciu
> +  clock to this at probe time.
> +
>  * num-slots: specifies the number of slots supported by the controller.
>The number of physical slots actually used could be equal or less than the
>value specified by num-slots. If this property is not specified, the value
> @@ -70,6 +83,8 @@ board specific portions as listed below.
>  
>   dwmmc0@1220 {
>   compatible = "snps,dw-mshc";
> + clocks = <&clock 351>, <&clock 132>;
> + clock-names = "biu", "ciu";
>   reg = <0x1220 0x1000>;
>   interrupts = <0 75 0>;
>   #address-cells = <1>;
> @@ -77,6 +92,7 @@ board specific portions as listed below.
>   };
>  
>   dwmmc0@1220 {
> + clock-frequency = <4>;
>   num-slots = <1>;
>   supports-highspeed;
>   broken-cd;
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index ab5642d..b8a2f16 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2107,6 +2107,7 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
> dw_mci *host)
>   struct device_node *np = dev->of_node;
>   const struct dw_mci_drv_data *drv_data = host->drv_data;
>   int idx, ret;
> + u32 clock_frequency;
>  
>   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>   if (!pdata) {
> @@ -2133,6 +2134,9 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
> dw_mci *host)
>  
>   of_property_read_u32(np, "card-detect-delay", &pdata->detect_delay_ms);
>  
> + if (!of_property_read_u32(np, "clock-frequency", &clock_frequency))
> + pdata->bus_hz = clock_frequency;
> +
>   if (drv_data && drv_data->parse_dt) {
>   ret = drv_data->parse_dt(host);
>   if (ret)
> @@ -2190,18 +2194,23 @@ int dw_mci_probe(struct dw_mci *host)
>   host->ciu_clk = devm_clk_get(host->dev, "ciu");
>   if (IS_ERR(host->ciu_clk)) {
>   dev_dbg(host->dev, "ciu clock not available\n");
> + host->bus_hz = host->pdata->bus_hz;
>   } else {
>   ret = clk_prepare_enable(host->ciu_clk);
>   if (ret) {
>   dev_err(host->dev, "failed to enable ciu clock\n");
>   goto err_clk_biu;
>   }
> - }
>  
> - if (IS_ERR(host->ciu_clk))
> - host->bus_hz = host->pdata->bus_hz;
> - else
> + if (host->pdata->bus_hz) {
> + ret = clk_set_rate(host->ciu_clk, host->pdata->bus_hz);
> + if (ret)
> + dev_warn(host->dev,
> +  "Unable to set bus rate to %ul\n",
> +  host->pdata->bus_hz);
> + }
>   host->bus_hz = clk_get_rate(host->ciu_clk);
> + }
>  
>   if (drv_data && drv_data->setup_clock) {
>   ret = drv_data->setup_clock(host);
> 

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

Re: [PATCH] build some drivers only when compile-testing

[Michal Marek]

Dne 17.6.2013 22:05, Jiri Slaby napsal(a):
> On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
>> On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
>>> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
 Some drivers can be built on more platforms than they run on. This
 causes users and distributors packaging burden when they have to
 manually deselect some drivers from their allmodconfigs. Or sometimes
 it is even impossible to disable the drivers without patching the
 kernel.

 Introduce a new config option COMPILE_TEST and make all those drivers
 to depend on the platform they run on, or on the COMPILE_TEST option.
 Now, when users/distributors choose COMPILE_TEST=n they will not have
 the drivers in their allmodconfig setups, but developers still can
 compile-test them with COMPILE_TEST=y.
>>>
>>> I understand the urge, and it's getting hard for distros to handle these
>>> drivers that just don't work on other architectures, but it's really
>>> valuable to ensure that they build properly, for those of us that don't
>>> have many/any cross compilers set up.
> 
> But this is exactly what COMPILE_TEST will give us when set to "y", or
> am I missing something?
> 
 Now the drivers where we use this new option:
 * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
   processors so it should depend on x86.
 * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
 * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
   systems -- which do not actually support the hardware via that
   method.
>>>
>>> This seems ripe to start to get really messy, really quickly.  Shouldn't
>>> "default configs" handle if this "should" be enabled for a platform or
>>> not, and let the rest of us just build them with no problems?
>>
>> If every time a new Kconfig option is added, corresponding default
>> config updates come with it, sure. I just don't see that happening,
>> especially when it can be done much more clearly in the Kconfig while
>> the developer is writing the driver.
>>
>>> What problems is this causing you?  Are you running out of space in
>>> kernel packages with drivers that will never be actually used?
>>
>> Wasted build resources. Wasted disk space on /every/ system the kernel
>> package is installed on. We're all trying to pare down the kernel
>> packages to eliminate wasted space and doing it manually means a bunch
>> of research, sometimes with incorrect assumptions about the results,
>> needs to be done by someone not usually associated with that code. That
>> research gets repeated by people maintaining kernel packages for pretty
>> much every distro.
> 
> I second all the above.
> 
 +config COMPILE_TEST
 +  bool "Compile also drivers which will not load" if EXPERT
>>>
>>> EXPERT is getting to be the "let's hide it here" option, isn't it...
>>>
>>> I don't know, if no one else strongly objects, I can be convinced that
>>> this is needed, but so far, I don't see why it really is, or what this
>>> is going to help with.
>>
>> I'm not convinced adding a || COMPILE_TEST option to every driver that
>> may be arch specific is the best way to go either. Perhaps adding a new
>> Kconfig verb called "archdepends on" or something that will evaluate as
>> true if COMPILE_TEST is enabled but will evaluate the conditional if
>> not. *waves hands*
> 
> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want
> to extend the kconfig language for this purpose (which I support). That
> a config option is fine and sufficient in this case [1]. Except he
> called the config option "SHOW_ALL_DRIVERS". Adding the current
> maintainer to CCs ;).

I agree with Sam. 'depends on XY || COMPILE_TEST' is quite
self-explanatory. And even if it's not, you can look up the help text
for COMPILE_TEST. With "archdepends on" or "available on", you need to
know what to look for to override the dependency.

Michal
--
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 V2 Resend 4/4] timer: Migrate running timer

[Viresh Kumar]

On 31 May 2013 16:19, Viresh Kumar  wrote:
> On 22 May 2013 14:04, Viresh Kumar  wrote:
>> Sorry for being late in replying to your queries.
>>
>> On 13 May 2013 16:05, Thomas Gleixner  wrote:
>>> Which mechanism is migrating the timer away?
>>
>> It will be the same: get_nohz_timer_target() which will decide target
>> cpu for migration.
>>
>>> I have no objections to the functionality per se, but the proposed
>>> solution is not going to fly.
>>>
>>> Aside of bloating the data structure you're changing the semantics of
>>> __mod_timer(). No __mod_timer() caller can deal with -EBUSY. So you'd
>>> break the world and some more.
>>
>> Ahh.. That idea was dropped already.
>>
>>> Here is a list of questions:
>>>
>>>   - Which mechanism migrates timers?
>>>
>>>   - How is that mechanism triggered?
>>
>> The mechanism remains the same as is for non-rearmed timers.
>> i.e. get_nohz_timer_target()..
>>
>> We are just trying to give a approach with which we can migrate
>> running timers. i.e. those which re-arm themselves from their
>> handlers.
>>
>>>   - How does that deal with CPU bound timers?
>>
>> We will still check 'Pinned' for this timer as is done for any other
>> normal timer. So, we don't migrate them.
>>
>> So, this is the clean draft for the idea I had.. (Naming is poor for
>> now):
>>
>> diff --git a/include/linux/timer.h b/include/linux/timer.h
>> index 8c5a197..ad00ebe 100644
>> --- a/include/linux/timer.h
>> +++ b/include/linux/timer.h
>> @@ -20,6 +20,7 @@ struct timer_list {
>>
>> void (*function)(unsigned long);
>> unsigned long data;
>> +   int wait_for_migration_to_complete;
>>
>> int slack;
>>
>> diff --git a/kernel/timer.c b/kernel/timer.c
>> index a860bba..7791f28 100644
>> --- a/kernel/timer.c
>> +++ b/kernel/timer.c
>> @@ -746,21 +746,15 @@ __mod_timer(struct timer_list *timer, unsigned
>> long expires,
>> new_base = per_cpu(tvec_bases, cpu);
>>
>> if (base != new_base) {
>> -   /*
>> -* We are trying to schedule the timer on the local CPU.
>> -* However we can't change timer's base while it is running,
>> -* otherwise del_timer_sync() can't detect that the timer's
>> -* handler yet has not finished. This also guarantees that
>> -* the timer is serialized wrt itself.
>> -*/
>> -   if (likely(base->running_timer != timer)) {
>> -   /* See the comment in lock_timer_base() */
>> -   timer_set_base(timer, NULL);
>> -   spin_unlock(&base->lock);
>> -   base = new_base;
>> -   spin_lock(&base->lock);
>> -   timer_set_base(timer, base);
>> -   }
>> +   if (base->running_timer == timer)
>> +   timer->wait_for_migration_to_complete = 1;
>> +
>> +   /* See the comment in lock_timer_base() */
>> +   timer_set_base(timer, NULL);
>> +   spin_unlock(&base->lock);
>> +   base = new_base;
>> +   spin_lock(&base->lock);
>> +   timer_set_base(timer, base);
>> }
>>
>> timer->expires = expires;
>> @@ -990,7 +984,8 @@ int try_to_del_timer_sync(struct timer_list *timer)
>>
>> base = lock_timer_base(timer, &flags);
>>
>> -   if (base->running_timer != timer) {
>> +   if ((base->running_timer != timer) &&
>> +   !timer->wait_for_migration_to_complete) {
>> timer_stats_timer_clear_start_info(timer);
>> ret = detach_if_pending(timer, base, true);
>> }
>> @@ -1183,6 +1178,8 @@ static inline void __run_timers(struct tvec_base *base)
>> call_timer_fn(timer, fn, data);
>> spin_lock_irq(&base->lock);
>> }
>> +   if (timer->wait_for_migration_to_complete)
>> +   timer->wait_for_migration_to_complete = 0;
>> }
>> }
>> base->running_timer = NULL;
>>
>>
>> Please see if it a junk idea or has some light of hope :)
>
> Ping!!

Ping!!
--
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] cpufreq: userspace: Simplify governor

[Viresh Kumar]

On 5 June 2013 18:38, Viresh Kumar  wrote:
> To be honest with the amount of experience I have now, my log was
> poor :(
>
> I have used following log in the attached patch:
>
> Subject: [PATCH] cpufreq: userspace: Simplify governor
>
> Userspace governor has got more code than what it needs for its functioning.
> Lets simplify it. Portions of code removed are:
> - Extra header files which aren't required anymore (rearranged them as well)
> - cpu_{max|min|cur|set}_freq, as they are always same as policy->{max|min|cur}
> - userspace_cpufreq_notifier_block as we don't need to set cpu_cur_freq 
> anymore
> - cpus_using_userspace_governor as it was for notifier code
>
> Signed-off-by: Viresh Kumar 

Hi Rafael,

Are you happy with the log & description of this patch now?
--
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 v10 5/8] dmaengine: edma: Add TI EDMA device tree binding

[Sekhar Nori]

On 6/17/2013 9:10 PM, Fernandes, Joel A wrote:
> Hi Arnd,
> 
>> -Original Message-
>> From: Arnd Bergmann [mailto:a...@arndb.de]
>> Sent: Monday, June 17, 2013 6:13 AM
>> To: Fernandes, Joel A
>> Cc: Tony Lindgren; Nori, Sekhar; Matt Porter; Grant Likely; Rob Herring; 
>> Vinod
>> Koul; Mark Brown; Cousson, Benoit; Russell King; Rob Landley; Andrew
>> Morton; Jason Kridner; Koen Kooi; Devicetree Discuss; Linux OMAP List; Linux
>> ARM Kernel List; Linux DaVinci Kernel List; Linux Kernel Mailing List; Linux
>> Documentation List; Linux MMC List; Linux SPI Devel List
>> Subject: Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree
>> binding
>>
>> On Friday 14 June 2013 21:32:47 Joel A Fernandes wrote:
>>>
>>> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> b/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> new file mode 100644
>>> index 000..ada0018
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
>>> @@ -0,0 +1,26 @@
>>> +TI EDMA
>>> +
>>> +Required properties:
>>> +- compatible : "ti,edma3"
>>> +- ti,hwmods: Name of the hwmods associated to the EDMA
>>> +- ti,edma-regions: Number of regions
>>> +- ti,edma-slots: Number of slots
>>> +
>>> +Optional properties:
>>> +- ti,edma-xbar-event-map: Crossbar event to channel map
>>
>> You need to list #dma-cells as required here, and which values are accepted
>> by the driver (I suppose only <1>). You should also explain the format of the
>> dma-specifier for a slave here for each possible value of #dma-cells.
>>
>> For each of the standard properties (reg, interrupts, dma-channels), list
>> whether they are optional or required. Since the example has three
>> interrupts, you should probably list how many interrupts need to be specified
>> (minimum and maximum if the number is variable) and in what order to
>> expect them.
>  
> [Joel] Thanks for the suggestion, I updated it and it looks like this now:
>   
>
> Required properties:  
>  
> - compatible : "ti,edma3" 
>  
> - ti,hwmods: Name of the hwmods associated to the EDMA  

I have already asked for ti,hwmods to be made optional. Please see my
comment from yesterday.

Thanks,
Sekhar
--
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] input/joystick: Fix for xpad driver support of "Mad Catz Street Fighter IV FightPad" controllers

[Shawn]

From: shawn joseph 

Added MAP_TRIGGERS_TO_BUTTONS for Mad Catz Street Fighter IV FightPad
device. This controller model was already supported by the xpad
driver, but none of the buttons work correctly without this change.
Tested on kernel version 3.9.5.
Signed-off-by: shawn joseph 
---
--- linux-3.9.5/drivers/input/
joystick/xpad.c.orig  2013-06-16 15:09:47.974170141 -0400
+++ linux-3.9.5/drivers/input/joystick/xpad.c   2013-06-16
15:10:24.070611282 -0400
@@ -137,7 +137,7 @@ static const struct xpad_device {
{ 0x0738, 0x4540, "Mad Catz Beat Pad", MAP_DPAD_TO_BUTTONS,
XTYPE_XBOX },
{ 0x0738, 0x4556, "Mad Catz Lynx Wireless Controller", 0, XTYPE_XBOX },
{ 0x0738, 0x4716, "Mad Catz Wired Xbox 360 Controller", 0,
XTYPE_XBOX360 },
-   { 0x0738, 0x4728, "Mad Catz Street Fighter IV FightPad",
XTYPE_XBOX360 },
+   { 0x0738, 0x4728, "Mad Catz Street Fighter IV FightPad",
MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x0738, 0x4738, "Mad Catz Wired Xbox 360 Controller (SFIV)",
MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x0738, 0x6040, "Mad Catz Beat Pad Pro",
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
{ 0x0738, 0xbeef, "Mad Catz JOYTECH NEO SE Advanced GamePad",
XTYPE_XBOX360 },
--
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/4] KVM: PPC: Add support for IOMMU in-kernel handling

[Benjamin Herrenschmidt]

On Mon, 2013-06-17 at 20:32 -0600, Alex Williamson wrote:

> Right, we don't want to create dependencies across modules.  I don't
> have a vision for how this should work.  This is effectively a complete
> side-band to vfio, so we're really just dealing in the iommu group
> space.  Maybe there needs to be some kind of registration of ownership
> for the group using some kind of token.  It would need to include some
> kind of notification when that ownership ends.  That might also be a
> convenient tag to toggle driver probing off for devices in the group.
> Other ideas?  Thanks,

All of that smells nasty like it will need a pile of bloody
infrastructure which makes me think it's too complicated and not the
right approach.

How does access control work today on x86/VFIO ? Can you give me a bit
more details ? I didn't get a good grasp in your previous email

>From the look of it, the VFIO file descriptor is what has the "access
control" to the underlying iommu, is this right ? So we somewhat need to
transfer (or copy) that ownership from the VFIO fd to the KVM VM.

I don't see a way to do that without some cross-layering here...

Rusty, are you aware of some kernel mechanism we can use for that ?

Cheers,
Ben.


--
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 V2 11/15] regulator: ti-abb: Convert to use devm_ioremap_resource

[Tushar Behera]

Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()")
introduced devm_ioremap_resource() and deprecated the use of
devm_request_and_ioremap().

While at it, remove the error message as devm_ioremap_resource prints a similar
error message.

Signed-off-by: Tushar Behera 
CC: Mark Brown 
CC: Liam Girdwood 
---
Changes for V2:
* Removed error messages from devm_ioremap_resource exit path

 drivers/regulator/ti-abb-regulator.c |   14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/ti-abb-regulator.c 
b/drivers/regulator/ti-abb-regulator.c
index 870d209..3753ed0 100644
--- a/drivers/regulator/ti-abb-regulator.c
+++ b/drivers/regulator/ti-abb-regulator.c
@@ -722,10 +722,9 @@ static int ti_abb_probe(struct platform_device *pdev)
ret = -ENODEV;
goto err;
}
-   abb->base = devm_request_and_ioremap(dev, res);
-   if (!abb->base) {
-   dev_err(dev, "Unable to map '%s'\n", pname);
-   ret = -ENOMEM;
+   abb->base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(abb->base)) {
+   ret = PTR_ERR(abb->base);
goto err;
}
 
@@ -776,10 +775,9 @@ static int ti_abb_probe(struct platform_device *pdev)
ret = -ENODEV;
goto skip_opt;
}
-   abb->ldo_base = devm_request_and_ioremap(dev, res);
-   if (!abb->ldo_base) {
-   dev_err(dev, "Unable to map '%s'\n", pname);
-   ret = -ENOMEM;
+   abb->ldo_base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(abb->ldo_base)) {
+   ret = PTR_ERR(abb->ldo_base);
goto err;
}
 
-- 
1.7.9.5

--
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 -next] pinctrl: core: fix missing unlock on error in pinctrl_find_gpio_range_from_pin()

[Wei Yongjun]

From: Wei Yongjun 

Add the missing unlock before return from function 
pinctrl_find_gpio_range_from_pin()
in the error handling case.

Introduced by commit 2ff3477efd7086544b9e298fc63afab0645921b4.
(pinctrl: add pin list based GPIO ranges)

Signed-off-by: Wei Yongjun 
---
 drivers/pinctrl/core.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 33710b5..28a3f7b 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -465,7 +465,7 @@ struct pinctrl_gpio_range *
 pinctrl_find_gpio_range_from_pin(struct pinctrl_dev *pctldev,
 unsigned int pin)
 {
-   struct pinctrl_gpio_range *range = NULL;
+   struct pinctrl_gpio_range *range;
 
mutex_lock(&pctldev->mutex);
/* Loop over the ranges */
@@ -475,17 +475,16 @@ pinctrl_find_gpio_range_from_pin(struct pinctrl_dev 
*pctldev,
int a;
for (a = 0; a < range->npins; a++) {
if (range->pins[a] == pin)
-   return range;
+   goto out;
}
} else if (pin >= range->pin_base &&
-  pin < range->pin_base + range->npins) {
-   mutex_unlock(&pctldev->mutex);
-   return range;
-   }
+  pin < range->pin_base + range->npins)
+   goto out;
}
+   range = NULL;
+out:
mutex_unlock(&pctldev->mutex);
-
-   return NULL;
+   return range;
 }
 EXPORT_SYMBOL_GPL(pinctrl_find_gpio_range_from_pin);
 

--
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: [RFC PATCH v4 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support

[Nicolas Pitre]

On Mon, 17 Jun 2013, Lorenzo Pieralisi wrote:

> The TC2 versatile express core tile integrates a logic block that provides the
> interface between the dual cluster test-chip and the M3 microcontroller that
> carries out power management. The logic block, called Serial Power Controller
> (SPC), contains several memory mapped registers to control among other things
> low-power states, operating points and reset control.

[...]

I slightly modified the following before committing this patch to my TC2 
branch:

> +/**
> + * ve_spc_cpu_wakeup_irq()
> + *
> + * Function to set/clear per-CPU wake-up IRQs. Not protected by locking since
> + * it might be used in code paths where normal cacheable locks are not
> + * working. Locking must be provided by the caller to ensure atomicity.
> + *
> + * @cpu: mpidr[7:0] bitfield describing cpu affinity level
> + * @cluster: mpidr[15:8] bitfield describing cluster affinity level
> + * @set: if true, wake-up IRQs are set, if false they are cleared
> + */
> +void ve_spc_cpu_wakeup_irq(u32 cpu, u32 cluster, bool set)
> +{

I made cluster first then cpu.  All the other functions have the cluster 
argument first, and ve_spc_set_resume_addr() already uses that order.

[...]
> +#ifdef CONFIG_VEXPRESS_SPC
> +int ve_spc_probe(void);
> +int ve_spc_get_freq(u32 cluster);
> +int ve_spc_set_freq(u32 cluster, u32 freq);
> +int ve_spc_get_freq_table(u32 cluster, const u32 **fptr);
> +void ve_spc_global_wakeup_irq(bool set);
> +void ve_spc_cpu_wakeup_irq(u32 cpu, u32 cluster, bool set);
> +void ve_spc_set_resume_addr(u32 cluster, u32 cpu, u32 addr);
> +u32 ve_spc_get_nr_cpus(u32 cluster);
> +void ve_spc_powerdown(u32 cluster, bool enable);
> +#else
> +static inline bool ve_spc_probe(void) { return -ENODEV; }

s/bool/int/


Nicolas
--
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] x86, efi: retry ExitBootServices() on failure

[Zachary Bobroff]

The timer is shutdown before callbacks on exitbootservices are called.  The 
bios should be entirely single threaded at this point unless Linux has started 
some other CPUs.  So exitbootservices will not return until each until each 
callback is complete.  In short, then it would return the status of failure if 
the memory map has changed, success otherwise.  The callbacks are not called on 
any subsequent call to exitbootservices, so the map should stay the same then.

Sent from my iPhone

On Jun 17, 2013, at 10:48 PM, "joeyli"  wrote:

> Hi Zach, 
> 
> 於 二，2013-06-18 於 00:18 +，Zachary Bobroff 提到：
>> All,
>> 
 Why a single retry is having reasonable guarantees to work when the
>> original one failed (nothing prevents an event handler to do another
>> allocation the next time through).
>> 
>> This patch is being submitted because of the potential issues that
>> occur when 3rd party option ROMs are signaled by the ExitBootServices
>> event. At the time they are signaled, they can perform any number of
>> actions that would change the EFI Memory map.  This wasn't actually
>> seen with our default implementation of our firmware, it was seen when
>> this plug-in card's option rom was run.
>> 
>> We only need to retry once because of what is in the UEFI
>> specification 2.3.1 Errata C.  The exact verbiage is as follows:
>> 
>> The ExitBootServices() function is called by the currently executing
>> EFI OS loader image to terminate all boot services. On success, the
>> loader becomes responsible for the continued operation of the system.
>> All events of type EVT_SIGNAL_EXIT_BOOT_SERVICES must be signaled
>> before ExitBootServices() returns EFI_SUCCESS. The events are only
>> signaled once even if ExitBootServices() is called multiple times.
>> 
>> Since the firmware will only signal the ExitBootServices event once,
>> the code that has the potential to change the memory map will only be
>> signaled on the first call to exit boot services. 
> 
> Does it possible have any delay time of 3rd party ROMs to change EFI
> memory map after they are signaled?
> or ExitBootServices() will wait all 3rd party ROMs updated memory map
> finished then return true/false to kernel?
> 
> 
> Thanks a lot!
> Joey Lee
> 

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc.  This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.
--
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] firmware loader: fix use-after-free by double abort

[Ming Lei]

On Tue, Jun 18, 2013 at 12:05 PM, Guenter Roeck  wrote:
>>
> I may be missing something, but why would mainline not need it ?
> Or do you mean "mainline plus 3.9" ?

Yes, mainline need it of course, sorry for not mentioning that explicitly.

Thanks,
--
Ming Lei
--
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 0/8] Volatile Ranges (v8?)

[Minchan Kim]

Hello Dhaval,

On Mon, Jun 17, 2013 at 12:24:07PM -0400, Dhaval Giani wrote:
> Hi John,
> 
> I have been giving your git tree a whirl, and in order to simulate a
> limited memory environment, I was using memory cgroups.
> 
> The program I was using to test is attached here. It is your test
> code, with some changes (changing the syscall interface, reducing
> the memory pressure to be generated).
> 
> I trapped it in a memory cgroup with 1MB memory.limit_in_bytes and hit this,
> 
> [  406.207612] [ cut here ]
> [  406.207621] kernel BUG at mm/vrange.c:523!
> [  406.207626] invalid opcode:  [#1] SMP
> [  406.207631] Modules linked in:
> [  406.207637] CPU: 0 PID: 1579 Comm: volatile-test Not tainted

Thanks for the testing!
Does below patch fix your problem?

diff --git a/mm/swapfile.c b/mm/swapfile.c
index d41c63f..1f6c80e 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -751,7 +751,7 @@ int __free_swap_and_cache(swp_entry_t entry)
page = find_get_page(swap_address_space(entry),
entry.val);
}
-   spin_unlock(&swap_lock);
+   spin_unlock(&p->lock);
}
 
if (page) {
diff --git a/mm/vrange.c b/mm/vrange.c
index fa965fb..dc32cfa 100644
--- a/mm/vrange.c
+++ b/mm/vrange.c
@@ -485,7 +485,7 @@ int try_to_discard_one(struct vrange_root *vroot, struct 
page *page,
 {
struct mm_struct *mm = vma->vm_mm;
pte_t *pte;
-   pte_t pteval;
+   pte_t pteval, pteswap;
spinlock_t *ptl;
int ret = 0;
bool present;
@@ -505,7 +505,7 @@ int try_to_discard_one(struct vrange_root *vroot, struct 
page *page,
present = pte_present(*pte);
flush_cache_page(vma, address, page_to_pfn(page));
 
-   ptep_clear_flush(vma, address, pte);
+   pteswap = ptep_clear_flush(vma, address, pte);
pteval = pte_mkvrange(*pte);
 
update_hiwater_rss(mm);
@@ -517,10 +517,11 @@ int try_to_discard_one(struct vrange_root *vroot, struct 
page *page,
page_remove_rmap(page);
page_cache_release(page);
if (!present) {
-   swp_entry_t entry = pte_to_swp_entry(*pte);
+   swp_entry_t entry = pte_to_swp_entry(pteswap);
dec_mm_counter(mm, MM_SWAPENTS);
-   if (unlikely(!__free_swap_and_cache(entry)))
+   if (unlikely(!__free_swap_and_cache(entry))) {
BUG_ON(1);
+   }
}
 
set_pte_at(mm, address, pte, pteval);
-- 
1.7.9.5

-- 
Kind regards,
Minchan Kim
--
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/

[x86] only print out DR registers if they are not power-on defaults.

[Dave Jones]

The DR registers are rarely useful when decoding oopses.
With screen real estate during oopses at a premium, we can save two lines
by only printing out these registers when they are set to something other
than they power-on state.

Signed-off-by: Dave Jones 

diff -durpN '--exclude-from=/home/davej/.exclude' 
/home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c 
linux-dj/arch/x86/kernel/process_64.c
--- /home/davej/src/kernel/git-trees/linux/arch/x86/kernel/process_64.c 
2013-05-01 10:02:52.064151923 -0400
+++ linux-dj/arch/x86/kernel/process_64.c   2013-05-06 20:35:09.219868881 
-0400
@@ -105,11 +105,18 @@ void __show_regs(struct pt_regs *regs, i
get_debugreg(d0, 0);
get_debugreg(d1, 1);
get_debugreg(d2, 2);
-   printk(KERN_DEFAULT "DR0: %016lx DR1: %016lx DR2: %016lx\n", d0, d1, 
d2);
get_debugreg(d3, 3);
get_debugreg(d6, 6);
get_debugreg(d7, 7);
+
+   /* Only print out debug registers if they are in their non-default 
state. */
+   if ((d0 == 0) && (d1 == 0) && (d2 == 0) && (d3 == 0) &&
+   (d6 & ~DR6_RESERVED) && (d7 == 0x400))
+   return;
+
+   printk(KERN_DEFAULT "DR0: %016lx DR1: %016lx DR2: %016lx\n", d0, d1, 
d2);
printk(KERN_DEFAULT "DR3: %016lx DR6: %016lx DR7: %016lx\n", d3, d6, 
d7);
+
 }
 
 void release_thread(struct task_struct *dead_task)

diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 7305f7d..5905dc5 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -110,11 +110,16 @@ void __show_regs(struct pt_regs *regs, int all)
get_debugreg(d1, 1);
get_debugreg(d2, 2);
get_debugreg(d3, 3);
-   printk(KERN_DEFAULT "DR0: %08lx DR1: %08lx DR2: %08lx DR3: %08lx\n",
-   d0, d1, d2, d3);
-
get_debugreg(d6, 6);
get_debugreg(d7, 7);
+
+   /* Only print out debug registers if they are in their non-default 
state. */
+   if ((d0 == 0) && (d1 == 0) && (d2 == 0) && (d3 == 0) &&
+   (d6 & ~DR6_RESERVED) && (d7 == 0x400))
+   return;
+
+   printk(KERN_DEFAULT "DR0: %08lx DR1: %08lx DR2: %08lx DR3: %08lx\n",
+   d0, d1, d2, d3);
printk(KERN_DEFAULT "DR6: %08lx DR7: %08lx\n",
d6, d7);
 }
--
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] net: fec: Fix build for MCF5272

[Guenter Roeck]

On Mon, Jun 17, 2013 at 04:11:51PM -0700, David Miller wrote:
> From: Guenter Roeck 
> Date: Mon, 17 Jun 2013 13:16:19 -0700
> 
> > Commits 4c09eed9 (net: fec: Enable imx6 enet checksum acceleration) and
> > baa70a5c (net: fec: enable pause frame to improve rx prefomance for 1G
> > network) introduced functionality into the FEC driver which is not
> > supported on MCF5272. As result, building images for MCF5272 fails,
> > complaining about several undefined symbols.
> > 
> > Disabled the added functionality for MCF5272 builds.
> > 
> > Cc: Frank Li 
> > Cc: Jim Baxter 
> > Signed-off-by: Guenter Roeck 
> > ---
> > Sorry for the added ifdefs. If anyone has a better idea on how to fix
> > the problems, let me know.
> > 
> > This problem exists in 3.9 as well.
> 
> Does the M5272 not have these registers, or have you simply not added
> defines for where there offsets are in that silicon instance?
> 
> I'd much rather you add the register offset defines than pepper the
> entire driver with ifdefs.
> 
I agree, and that would have been my preferred solution as well.
Unfortunately, according to the user manual (MCF5272 ColdFire
Integrated Microprocessor User's Manual), the registers do not exist
on this chip.

Guenter
--
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] firmware loader: fix use-after-free by double abort

[Guenter Roeck]

On Tue, Jun 18, 2013 at 08:33:55AM +0800, Ming Lei wrote:
> On Tue, Jun 18, 2013 at 7:59 AM, Greg Kroah-Hartman
>  wrote:
> > On Sat, Jun 15, 2013 at 04:36:38PM +0800, Ming Lei wrote:
> >> fw_priv->buf is accessed in both request_firmware_load() and
> >> writing to sysfs file of 'loading' context, but not protected
> >> by 'fw_lock' entirely. The patch makes sure that access on
> >> 'fw_priv->buf' is protected by the lock.
> >>
> >> So fixes the double abort problem reported by nirinA raseliarison:
> >>
> >>   http://lkml.org/lkml/2013/6/14/188
> >>
> >> Reported-and-tested-by: nirinA raseliarison 
> >> Cc: Guenter Roeck 
> >> Cc: Bjorn Helgaas 
> >> Cc: stable 
> >> Signed-off-by: Ming Lei 
> >
> > So this is a 3.9-stable thing?  Anything newer than that?
> 
> Yes, only 3.9-stable need this.
> 
I may be missing something, but why would mainline not need it ?
Or do you mean "mainline plus 3.9" ?

Thanks,
Guenter
--
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: [GIT PULL] extcon for 3.11

[Chanwoo Choi]

On 06/18/2013 08:03 AM, Greg KH wrote:
> On Mon, Jun 17, 2013 at 04:01:19PM -0700, Greg KH wrote:
>> On Fri, Jun 14, 2013 at 09:39:13PM +0900, Chanwoo Choi wrote:
>>> Hi Greg,
>>>
>>> First of all, I'm so sorry about previous wrong pull-request.
>>> I will be careful and not to make same mistakes
>>>
>>> This is extcon-next pull request for 3.11
>>> Please pull extcon with following updates.
>>>
>>> I combined the patch of small fix and new drivers becasue
>>> 3.10-rc version is large.
>>>
>>> Best Regards,
>>> Chanwoo Choi
>>>
>>> The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10:
>>>
>>>   Linux 3.10-rc5 (2013-06-08 17:41:04 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
>>> tags/extcon-next-for-3.11
>>>
>>> for you to fetch changes up to f7ae906806279e5b57bfd302b945e1bcdddce95b:
>>>
>>>   extcon: Add an API to get extcon device from dt node (2013-06-14 18:36:34 
>>> +0900)
>>>
>>> 
>>> Update extcon for 3.11
>>>
>>> This patchset modify small fix of extcon core driver and add new extcon
>>> driver for Palmas device which is USB tranceiver device. Also, support
>>> OF helper API to get the name of extcon device(producer driver) on extcon
>>> consumer driver.
>>>
>>> Detailed description for patchset:
>>> 1. Modify extcon-class driver
>>> - Change permission 'state' sysfs entry(rw->r)
>>> - Use EXPORT_SYMBOL_GPL for exported functions
>>> - Fix bug null pointer when call extcon_unregister_interest
>>>
>>> 2. Modify Kconfig of extcon
>>> - Change the extcon config type to bool from module. If extcon
>>> is built as module and then extcon consumer driver uses API of,
>>> extcon, compiler happen "undefined reference to" build error.
>>>
>>> 3. Add new extcon driver for Palmas device and OF helper API
>>> - Add new extcon drvier for Palmas which is USB tranceiver device
>>> - Add OF(Open Firmware) Helper API which is of_extcon_get_extcon_dev()
>>>   This helper API get the extcon device name on extcon consumer device.
>>>
>>> 
>>> Chanwoo Choi (1):
>>>   extcon: Change permission 'state' sysfs entry (rw -> r)
>>>
>>> Graeme Gregory (1):
>>>   extcon: Palmas Extcon Driver
>>>
>>> Jonghwa Lee (1):
>>>   extcon: class: Add NULL pointer checking for removing notifier block.
>>>
>>> Kishon Vijay Abraham I (3):
>>>   extcon: Kconfig: Make extcon config type as bool
>>
>> Why is this change made?  Why can't I have the extcon core as a module?
>> What changed to prevent this?
> 
> And hint, I know why you did this, and it's not the correct way, please
> fix it up properly...

OK, I fix this issue by using the following way:
- The extcon consumer driver must have the dependency of CONFIG_EXTCON
on consumer driver's Kconfig. If extcon core is built as module,
all of the extcon consumer driver will be built as moduel too.

Thanks for your comment.

Best Regards,
Chanwoo Choi


--
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 2/5] arm: mmp: use matrix_keymap for all boards

[Chao Xie]

Compile passed for the configuration

pxa168_defconfig
  aspenite.c(MACH_ASPENITE), teton_bgs.c(MACH_TENTON_BGA)

Signed-off-by: Chao Xie 
---
 arch/arm/mach-mmp/aspenite.c  |   10 +++---
 arch/arm/mach-mmp/teton_bga.c |   10 +++---
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mmp/aspenite.c b/arch/arm/mach-mmp/aspenite.c
index 9f64d56..1e23346 100644
--- a/arch/arm/mach-mmp/aspenite.c
+++ b/arch/arm/mach-mmp/aspenite.c
@@ -205,7 +205,7 @@ struct pxa168fb_mach_info aspenite_lcd_info = {
.invert_pixclock= 0,
 };
 
-static unsigned int aspenite_matrix_key_map[] = {
+static const unsigned int aspenite_matrix_key_map[] = {
KEY(0, 6, KEY_UP),  /* SW 4 */
KEY(0, 7, KEY_DOWN),/* SW 5 */
KEY(1, 6, KEY_LEFT),/* SW 6 */
@@ -214,11 +214,15 @@ static unsigned int aspenite_matrix_key_map[] = {
KEY(4, 7, KEY_ESC), /* SW 9 */
 };
 
+static struct matrix_keymap_data aspenite_matrix_keymap_data = {
+   .keymap = aspenite_matrix_key_map,
+   .keymap_size= ARRAY_SIZE(aspenite_matrix_key_map),
+};
+
 static struct pxa27x_keypad_platform_data aspenite_keypad_info __initdata = {
.matrix_key_rows= 5,
.matrix_key_cols= 8,
-   .matrix_key_map = aspenite_matrix_key_map,
-   .matrix_key_map_size= ARRAY_SIZE(aspenite_matrix_key_map),
+   .matrix_keymap_data = &aspenite_matrix_keymap_data,
.debounce_interval  = 30,
 };
 
diff --git a/arch/arm/mach-mmp/teton_bga.c b/arch/arm/mach-mmp/teton_bga.c
index 8609967..2021769 100644
--- a/arch/arm/mach-mmp/teton_bga.c
+++ b/arch/arm/mach-mmp/teton_bga.c
@@ -49,18 +49,22 @@ static unsigned long teton_bga_pin_config[] __initdata = {
GPIO78_GPIO,
 };
 
-static unsigned int teton_bga_matrix_key_map[] = {
+static const unsigned int teton_bga_matrix_key_map[] = {
KEY(0, 6, KEY_ESC),
KEY(0, 7, KEY_ENTER),
KEY(1, 6, KEY_LEFT),
KEY(1, 7, KEY_RIGHT),
 };
 
+static struct matrix_keymap_data teton_bga_matrix_keymap_data = {
+   .keymap = teton_bga_matrix_key_map,
+   .keymap_size= ARRAY_SIZE(teton_bga_matrix_key_map),
+};
+
 static struct pxa27x_keypad_platform_data teton_bga_keypad_info __initdata = {
.matrix_key_rows= 2,
.matrix_key_cols= 8,
-   .matrix_key_map = teton_bga_matrix_key_map,
-   .matrix_key_map_size= ARRAY_SIZE(teton_bga_matrix_key_map),
+   .matrix_keymap_data = &teton_bga_matrix_keymap_data,
.debounce_interval  = 30,
 };
 
-- 
1.7.4.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 V3 0/5] input: pxa27x-keypad: enhancement and device tree support

[Chao Xie]

The patches include 2 parts
1. use matrix_keypad for matrix keyes support
2. add device tree support for pxa27x-keypad

V2->V1:
Do not copy the members from pdata. For device tree support,
directly allocate the pdata structure.

V3->V2
add matrix_keypad changes for all boards using pxa27x-keypad
under mach-pxa.
The patch "arm: pxa: use matrix_keymap for all boards" is new.
The patch "arm: mmp: use matrix_keymap for all boards" merges
previous changes for aspenite and teton_bga.
All other patches are not modified.

Chao Xie (5):
  input: pxa27x-keypad: use matrix_keymap for matrix keyes
  arm: mmp: use matrix_keymap for all boards
  arm: pxa: use matrix_keymap for all boards
  input: pxa27x-keypad: remove the unused members at platform data
  input: pxa27x-keypad: add device tree support

 .../devicetree/bindings/input/pxa27x-keypad.txt|   60 +
 arch/arm/mach-mmp/aspenite.c   |   10 +-
 arch/arm/mach-mmp/teton_bga.c  |   10 +-
 arch/arm/mach-pxa/em-x270.c|   20 +-
 arch/arm/mach-pxa/ezx.c|   60 +++--
 arch/arm/mach-pxa/littleton.c  |   10 +-
 arch/arm/mach-pxa/mainstone.c  |   10 +-
 arch/arm/mach-pxa/mioa701.c|   11 +-
 arch/arm/mach-pxa/palmld.c |   10 +-
 arch/arm/mach-pxa/palmt5.c |   10 +-
 arch/arm/mach-pxa/palmtreo.c   |   23 ++-
 arch/arm/mach-pxa/palmtx.c |   10 +-
 arch/arm/mach-pxa/palmz72.c|   10 +-
 arch/arm/mach-pxa/tavorevb.c   |   10 +-
 arch/arm/mach-pxa/z2.c |   10 +-
 arch/arm/mach-pxa/zylonite.c   |   10 +-
 drivers/input/keyboard/Kconfig |1 +
 drivers/input/keyboard/pxa27x_keypad.c |  266 ++--
 include/linux/platform_data/keypad-pxa27x.h|3 +-
 19 files changed, 468 insertions(+), 86 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/pxa27x-keypad.txt

-- 
1.7.4.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 V3 3/5] arm: pxa: use matrix_keymap for all boards

[Chao Xie]

Compile passed for configurations

em_x270_defconfig
  em_x270x.c(MACH_EM_X270, MACH_EXEDA)

ezx_defconfig
  ezx.c(MACH_EZX_A780, MACH_EZX_E680, MACH_EZX_A1200,
MACH_EZX_A910, MACH_EZX_E6, MACH_EZX_E2)

palmz72_defconfig
  palmld.c(MACH_PALMLD), palmtreo.c(PALM_TREO),
  palmtx.c(MACH_PALMTX), palmz72.c(MACH_PALMZ72),
  palmt5.c(MACH_PALMT5)

pxa3xx_defconfig
  littleton.c(MACH_LITTLETON), tarvorevb.c(MACH_TAVOREVB),
  zylonite.c(MACH_ZYLONITE320), mioa701.c(MACH_MIOA701),
  z2.c(MACH_ZIPIT2)

mainstone_defconfig
  maintone.c(MACH_MAINSTONE)

Signed-off-by: Chao Xie 
---
 arch/arm/mach-pxa/em-x270.c   |   20 +
 arch/arm/mach-pxa/ezx.c   |   60 
 arch/arm/mach-pxa/littleton.c |   10 +--
 arch/arm/mach-pxa/mainstone.c |   10 +--
 arch/arm/mach-pxa/mioa701.c   |   11 +--
 arch/arm/mach-pxa/palmld.c|   10 +--
 arch/arm/mach-pxa/palmt5.c|   10 +--
 arch/arm/mach-pxa/palmtreo.c  |   23 ++-
 arch/arm/mach-pxa/palmtx.c|   10 +--
 arch/arm/mach-pxa/palmz72.c   |   10 +--
 arch/arm/mach-pxa/tavorevb.c  |   10 +--
 arch/arm/mach-pxa/z2.c|   10 +--
 arch/arm/mach-pxa/zylonite.c  |   10 +--
 13 files changed, 142 insertions(+), 62 deletions(-)

diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index 446563a..f6726bb 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -833,21 +833,25 @@ static inline void em_x270_init_ac97(void) {}
 #endif
 
 #if defined(CONFIG_KEYBOARD_PXA27x) || defined(CONFIG_KEYBOARD_PXA27x_MODULE)
-static unsigned int em_x270_module_matrix_keys[] = {
+static const unsigned int em_x270_module_matrix_keys[] = {
KEY(0, 0, KEY_A), KEY(1, 0, KEY_UP), KEY(2, 1, KEY_B),
KEY(0, 2, KEY_LEFT), KEY(1, 1, KEY_ENTER), KEY(2, 0, KEY_RIGHT),
KEY(0, 1, KEY_C), KEY(1, 2, KEY_DOWN), KEY(2, 2, KEY_D),
 };
 
+static struct matrix_keymap_data em_x270_matrix_keymap_data = {
+   .keymap = em_x270_module_matrix_keys,
+   .keymap_size= ARRAY_SIZE(em_x270_module_matrix_keys),
+};
+
 struct pxa27x_keypad_platform_data em_x270_module_keypad_info = {
/* code map for the matrix keys */
.matrix_key_rows= 3,
.matrix_key_cols= 3,
-   .matrix_key_map = em_x270_module_matrix_keys,
-   .matrix_key_map_size= ARRAY_SIZE(em_x270_module_matrix_keys),
+   .matrix_keymap_data = &em_x270_matrix_keymap_data,
 };
 
-static unsigned int em_x270_exeda_matrix_keys[] = {
+static const unsigned int em_x270_exeda_matrix_keys[] = {
KEY(0, 0, KEY_RIGHTSHIFT), KEY(0, 1, KEY_RIGHTCTRL),
KEY(0, 2, KEY_RIGHTALT), KEY(0, 3, KEY_SPACE),
KEY(0, 4, KEY_LEFTALT), KEY(0, 5, KEY_LEFTCTRL),
@@ -889,12 +893,16 @@ static unsigned int em_x270_exeda_matrix_keys[] = {
KEY(7, 6, 0), KEY(7, 7, 0),
 };
 
+static struct matrix_keymap_data em_x270_exeda_matrix_keymap_data = {
+   .keymap = em_x270_exeda_matrix_keys,
+   .keymap_size= ARRAY_SIZE(em_x270_exeda_matrix_keys),
+};
+
 struct pxa27x_keypad_platform_data em_x270_exeda_keypad_info = {
/* code map for the matrix keys */
.matrix_key_rows= 8,
.matrix_key_cols= 8,
-   .matrix_key_map = em_x270_exeda_matrix_keys,
-   .matrix_key_map_size= ARRAY_SIZE(em_x270_exeda_matrix_keys),
+   .matrix_keymap_data = &em_x270_exeda_matrix_keymap_data,
 };
 
 static void __init em_x270_init_keypad(void)
diff --git a/arch/arm/mach-pxa/ezx.c b/arch/arm/mach-pxa/ezx.c
index dca1070..fe2eb83 100644
--- a/arch/arm/mach-pxa/ezx.c
+++ b/arch/arm/mach-pxa/ezx.c
@@ -392,7 +392,7 @@ static unsigned long e6_pin_config[] __initdata = {
 
 /* KEYPAD */
 #ifdef CONFIG_MACH_EZX_A780
-static unsigned int a780_key_map[] = {
+static const unsigned int a780_key_map[] = {
KEY(0, 0, KEY_SEND),
KEY(0, 1, KEY_BACK),
KEY(0, 2, KEY_END),
@@ -424,11 +424,15 @@ static unsigned int a780_key_map[] = {
KEY(4, 4, KEY_DOWN),
 };
 
+static struct matrix_keymap_data a780_matrix_keymap_data = {
+   .keymap = a780_key_map,
+   .keymap_size= ARRAY_SIZE(a780_key_map),
+};
+
 static struct pxa27x_keypad_platform_data a780_keypad_platform_data = {
.matrix_key_rows = 5,
.matrix_key_cols = 5,
-   .matrix_key_map = a780_key_map,
-   .matrix_key_map_size = ARRAY_SIZE(a780_key_map),
+   .matrix_keymap_data = &a780_matrix_keymap_data,
 
.direct_key_map = { KEY_CAMERA },
.direct_key_num = 1,
@@ -438,7 +442,7 @@ static struct pxa27x_keypad_platform_data 
a780_keypad_platform_data = {
 #endif /* CONFIG_MACH_EZX_A780 */
 
 #ifdef CONFIG_MACH_EZX_E680
-static unsigned int e680_key_map[] = {
+static const unsigned int e680_key_map[] = {
KEY(0, 0, KEY_UP),
KEY(0, 1, KEY_RIGHT),
KEY(0, 2, KEY_RESERVED),
@@ -455,11 +4

[PATCH V3 5/5] input: pxa27x-keypad: add device tree support

[Chao Xie]

Signed-off-by: Chao Xie 
---
 .../devicetree/bindings/input/pxa27x-keypad.txt|   60 +
 drivers/input/keyboard/pxa27x_keypad.c |  232 +++-
 2 files changed, 288 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/pxa27x-keypad.txt

diff --git a/Documentation/devicetree/bindings/input/pxa27x-keypad.txt 
b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
new file mode 100644
index 000..f8674f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
@@ -0,0 +1,60 @@
+* Marvell PXA Keypad controller
+
+Required Properties
+- compatible : should be "marvell,pxa27x-keypad"
+- reg : Address and length of the register set for the device
+- interrupts : The interrupt for the keypad controller
+- marvell,debounce-interval : How long time the key will be
+  recognized when it is pressed. It is a u32 value, and bit[31:16]
+  is debounce interval for direct key and bit[15:0] is debounce
+  interval for matrix key. The value is in binary number of 2ms
+
+Optional Properties For Matrix Keyes
+Please refer to matrix-keymap.txt
+
+Optional Properties for Direct Keyes
+- marvell,direct-key-count : How many direct keyes are used.
+- marvell,direct-key-mask : The mask indicates which keyes
+  are used. If bit[X] of the mask is set, the direct key X
+  is used.
+- marvell,direct-key-low-active : Direct key status register
+  tells the level of pins that connects to the direct keyes.
+  When this property is set, it means that when the pin level
+  is low, the key is pressed(active).
+- marvell,direct-key-map : It is a u16 array. Each item indicates
+  the linux key-code for the direct key.
+
+Optional Properties For Rotary
+- marvell,rotary0 : It is a u32 value. Bit[31:16] is the
+  linux key-code for rotary up. Bit[15:0] is the linux key-code
+  for rotary down. It is for rotary 0.
+- marvell,rotary1 : Same as marvell,rotary0. It is for rotary 1.
+- marvell,rotary-rel-key : When rotary is used for relative axes
+  in the device, the value indicates the key-code for relative
+  axes measurement in the device. It is a u32 value. Bit[31:16]
+  is for rotary 1, and Bit[15:0] is for rotary 0.
+
+Examples:
+   keypad: keypad@d4012000 {
+   keypad,num-rows = <3>;
+   keypad,num-columns = <5>;
+   linux,keymap = <0x000e  /* KEY_BACKSPACE */
+   0x0001006b  /* KEY_END */
+   0x00020061  /* KEY_RIGHTCTRL */
+   0x0003000b  /* KEY_0 */
+   0x00040002  /* KEY_1 */
+   0x018b  /* KEY_MENU */
+   0x01010066  /* KEY_HOME */
+   0x010200e7  /* KEY_SEND */
+   0x01030009  /* KEY_8 */
+   0x0104000a  /* KEY_9 */
+   0x02000160  /* KEY_OK */
+   0x02010003  /* KEY_2 */
+   0x02020004  /* KEY_3 */
+   0x02030005  /* KEY_4 */
+   0x02040006>;/* KEY_5 */
+   marvell,rotary0 = <0x006c0067>; /* KEY_UP & KEY_DOWN */
+   marvell,direct-key-count = <1>;
+   marvell,direct-key-map = <0x001c>;
+   marvell,debounce-interval = <0x001e001e>;
+   };
diff --git a/drivers/input/keyboard/pxa27x_keypad.c 
b/drivers/input/keyboard/pxa27x_keypad.c
index 947d657..16cf9a5 100644
--- a/drivers/input/keyboard/pxa27x_keypad.c
+++ b/drivers/input/keyboard/pxa27x_keypad.c
@@ -118,6 +118,217 @@ struct pxa27x_keypad {
unsigned int direct_key_mask;
 };
 
+static int pxa27x_keypad_matrix_key_parse_dt(struct pxa27x_keypad *keypad)
+{
+   int ret;
+   u32 rows, cols;
+   struct input_dev *input_dev = keypad->input_dev;
+   struct device *dev = input_dev->dev.parent;
+   struct pxa27x_keypad_platform_data *pdata = keypad->pdata;
+
+   ret = matrix_keypad_parse_of_params(dev, &rows, &cols);
+   if (ret)
+   return ret;
+
+   if (rows > MAX_MATRIX_KEY_ROWS || cols > MAX_MATRIX_KEY_COLS) {
+   dev_err(dev, "rows or cols exceeds maximum value\n");
+   return -EINVAL;
+   }
+
+   pdata->matrix_key_rows = rows;
+   pdata->matrix_key_cols = cols;
+
+   ret = matrix_keypad_build_keymap(NULL, NULL,
+pdata->matrix_key_rows,
+pdata->matrix_key_cols,
+keypad->keycodes, input_dev);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static int pxa27x_keypad_direct_key_parse_dt(struct pxa27x_keypad *keypad)
+{
+   const __be16 *prop;
+   unsigned short code;
+   int i, ret;
+   unsigned int proplen, si

[PATCH V3 4/5] input: pxa27x-keypad: remove the unused members at platform data

[Chao Xie]

Now pxa27x-keypad make use matrix_keymap for matrix keyes, so
remove the unused members in platform data.

Signed-off-by: Chao Xie 
---
 include/linux/platform_data/keypad-pxa27x.h |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/include/linux/platform_data/keypad-pxa27x.h 
b/include/linux/platform_data/keypad-pxa27x.h
index 0db423b..2462556 100644
--- a/include/linux/platform_data/keypad-pxa27x.h
+++ b/include/linux/platform_data/keypad-pxa27x.h
@@ -39,8 +39,6 @@ struct pxa27x_keypad_platform_data {
const struct matrix_keymap_data *matrix_keymap_data;
unsigned intmatrix_key_rows;
unsigned intmatrix_key_cols;
-   unsigned int*matrix_key_map;
-   int matrix_key_map_size;
 
/* direct keys */
int direct_key_num;
-- 
1.7.4.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 V3 1/5] input: pxa27x-keypad: use matrix_keymap for matrix keyes

[Chao Xie]

pxa27x-keypad includes matrix keyes. Make use of matrix_keymap
for the matrix keyes.

Signed-off-by: Chao Xie 
---
 drivers/input/keyboard/Kconfig  |1 +
 drivers/input/keyboard/pxa27x_keypad.c  |   36 +-
 include/linux/platform_data/keypad-pxa27x.h |1 +
 3 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 37c3666..706e11b 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -451,6 +451,7 @@ config KEYBOARD_OPENCORES
 config KEYBOARD_PXA27x
tristate "PXA27x/PXA3xx keypad support"
depends on PXA27x || PXA3xx || ARCH_MMP
+   select INPUT_MATRIXKMAP
help
  Enable support for PXA27x/PXA3xx keypad controller.
 
diff --git a/drivers/input/keyboard/pxa27x_keypad.c 
b/drivers/input/keyboard/pxa27x_keypad.c
index b674e7a..947d657 100644
--- a/drivers/input/keyboard/pxa27x_keypad.c
+++ b/drivers/input/keyboard/pxa27x_keypad.c
@@ -118,25 +118,29 @@ struct pxa27x_keypad {
unsigned int direct_key_mask;
 };
 
-static void pxa27x_keypad_build_keycode(struct pxa27x_keypad *keypad)
+static int pxa27x_keypad_build_keycode(struct pxa27x_keypad *keypad)
 {
struct pxa27x_keypad_platform_data *pdata = keypad->pdata;
struct input_dev *input_dev = keypad->input_dev;
unsigned short keycode;
-   int i;
+   int ret, i;
+   const struct matrix_keymap_data *keymap_data =
+   pdata ? pdata->matrix_keymap_data : NULL;
 
-   for (i = 0; i < pdata->matrix_key_map_size; i++) {
-   unsigned int key = pdata->matrix_key_map[i];
-   unsigned int row = KEY_ROW(key);
-   unsigned int col = KEY_COL(key);
-   unsigned int scancode = MATRIX_SCAN_CODE(row, col,
-MATRIX_ROW_SHIFT);
+   ret = matrix_keypad_build_keymap(keymap_data, NULL,
+pdata->matrix_key_rows,
+pdata->matrix_key_cols,
+keypad->keycodes, input_dev);
+   if (ret)
+   return ret;
 
-   keycode = KEY_VAL(key);
-   keypad->keycodes[scancode] = keycode;
-   __set_bit(keycode, input_dev->keybit);
-   }
+   /*
+* The keycodes may not only includes matrix key but also the direct
+* key or rotary key.
+*/
+   input_dev->keycodemax = ARRAY_SIZE(keypad->keycodes);
 
+   /* For direct key. */
for (i = 0; i < pdata->direct_key_num; i++) {
keycode = pdata->direct_key_map[i];
keypad->keycodes[MAX_MATRIX_KEY_NUM + i] = keycode;
@@ -178,6 +182,8 @@ static void pxa27x_keypad_build_keycode(struct 
pxa27x_keypad *keypad)
}
 
__clear_bit(KEY_RESERVED, input_dev->keybit);
+
+   return 0;
 }
 
 static void pxa27x_keypad_scan_matrix(struct pxa27x_keypad *keypad)
@@ -555,7 +561,11 @@ static int pxa27x_keypad_probe(struct platform_device 
*pdev)
input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REP);
input_set_capability(input_dev, EV_MSC, MSC_SCAN);
 
-   pxa27x_keypad_build_keycode(keypad);
+   error  = pxa27x_keypad_build_keycode(keypad);
+   if (error) {
+   dev_err(&pdev->dev, "failed to build keycode\n");
+   goto failed_put_clk;
+   }
 
if ((pdata->enable_rotary0 && keypad->rotary_rel_code[0] != -1) ||
(pdata->enable_rotary1 && keypad->rotary_rel_code[1] != -1)) {
diff --git a/include/linux/platform_data/keypad-pxa27x.h 
b/include/linux/platform_data/keypad-pxa27x.h
index 5ce8d5e6..0db423b 100644
--- a/include/linux/platform_data/keypad-pxa27x.h
+++ b/include/linux/platform_data/keypad-pxa27x.h
@@ -36,6 +36,7 @@
 struct pxa27x_keypad_platform_data {
 
/* code map for the matrix keys */
+   const struct matrix_keymap_data *matrix_keymap_data;
unsigned intmatrix_key_rows;
unsigned intmatrix_key_cols;
unsigned int*matrix_key_map;
-- 
1.7.4.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/

Re: [PATCH V5 1/3] pci: Add PCIe driver for Samsung Exynos

[Jingoo Han]

On Monday, June 17, 2013 9:45 PM, Arnd Bergmann wrote:
> On Monday 17 June 2013 18:45:52 Jingoo Han wrote:
> > On Friday, June 14, 2013 9:54 PM, Arnd Bergmann wrote:
> > >
> > > Please look up the documentation about inbound viewport and describe
> > > in a code comment what it does. I /assume/ that this is how DMA accesses
> > > from the bus get translated into AXI bus transactions. If so, you have
> > > to let the window translate addresses from RAM. If it's something else,
> > > then you should document what it is and how it needs to be set up.
> >
> > One of our hardware engineer confirmed it.
> > He said that these inbound functions are unnecessary.
> > Also, I checked that PCIe works properly without these functions.
> > So, I will remove these inbound functions.
> 
> Ok, good. So DMA just gets translated 1:1 independent of the
> inbound viewport? Have you tested this with PCI device using
> DMA?

According to our hardware engineer,
He said that
"That's correct. We tested it by doing a memory write from the device.
A device DMA is a series of memory r/w so I expect it to work same way."

Also, he thought that I already tested too, since it works after removing
the functions.

> 
> > static int exynos_pcie_setup(int nr, struct pci_sys_data *sys)
> > {
> > struct pcie_port *pp;
> >
> > pp = sys_to_pcie(sys);
> >
> > if (!pp)
> > return 0;
> >
> > if (global_io_offset < SZ_1M && pp->config.io_size > 0) {
> > sys->io_offset = global_io_offset - pp->config.io_bus_addr; /* 
> > normally 0 */
> > pci_ioremap_io(sys->io_offset, pp->io.start);
> > global_io_offset += SZ_64K;
> > }
> >
> > sys->mem_offset = pp->mem.start - pp->config.mem_bus_addr; /* normally 
> > 0 */
> >
> > pci_add_resource_offset(&sys->resources, &pp->io, sys->io_offset);
> > pci_add_resource_offset(&sys->resources, &pp->mem, sys->mem_offset);
> >
> > return 1;
> > }
> 
> This is what I meant, yes.
> 
> > In this case, boot message is as below:
> >
> > PCI host bridge to bus :00
> > pci_bus :00: root bus resource [io  0x40001000-0x40010fff]
> > pci_bus :00: root bus resource [mem 0x40011000-0x5fff]
> > pci_bus :00: No busn resource found for root bus, will use [bus 00-ff]
> > pci :00:00.0: [144d:a549] type 01 class 0x060400
> > [.]
> > PCI host bridge to bus 0001:00
> > pci_bus 0001:00: root bus resource [io  0x60001000-0x60010fff] (bus address 
> > [0x5fff1000-0x6000
> > 0fff])
> > pci_bus 0001:00: root bus resource [mem 0x60011000-0x7fff]
> > pci_bus 0001:00: No busn resource found for root bus, will use [bus 00-ff]
> > pci 0001:00:00.0: [144d:a549] type 01 class 0x060400
> 
> The io resources here look wrong. I would have expected
> 
> pci_bus :00: root bus resource [io  0x001000-0x00]
> pci_bus 0001:00: root bus resource [io  0x01-0x01] (bus address 
> [0x00-0x00])
> 
> Please have a look at the pci-mvebu driver and how it calculates its
> 'realio' resource.

I looked at the pci-mvebu driver,
Then I fixed it as the pci-mvebu driver did.
Also, I added 'global_io_offset'.

@@ -909,6 +909,12 @@ static int __init exynos_pcie_probe(struct platform_device 
*pdev)
if (restype == IORESOURCE_IO) {
of_pci_range_to_resource(&range, np, &pp->io);
pp->io.name = "I/O";
+   pp->io.start = max_t(resource_size_t,
+   PCIBIOS_MIN_IO,
+   range.pci_addr + 
global_io_offset);
+   pp->io.end = min_t(resource_size_t,
+   IO_SPACE_LIMIT,
+   range.pci_addr + range.size + 
global_io_offset);
pp->config.io_size = resource_size(&pp->io);
pp->config.io_bus_addr = range.pci_addr;

In this case, boot message is as below:

PCI host bridge to bus :00
pci_bus :00: root bus resource [io  0x1000-0x1]
pci_bus :00: root bus resource [mem 0x40011000-0x5fff]
[.]
PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [io  0x1-0x2] (bus address 
[0x-0x1])
pci_bus 0001:00: root bus resource [mem 0x60011000-0x7fff]



> 
> > > > > > +static int __exit exynos_pcie_remove(struct platform_device *pdev)
> > > > > > +{
> > > > > > +   struct pcie_port *pp = platform_get_drvdata(pdev);
> > > > > > +
> > > > > > +   clk_disable_unprepare(pp->bus_clk);
> > > > > > +   clk_disable_unprepare(pp->clk);
> > > > > > +
> > > > > > +   return 0;
> > > > > > +}
> > > > >
> > > > > You also don't remove the PCI devices here, as mentioned in an earlier
> > > > > review.
> > > >
> > > > I reviewed Marvell PCIe driver and Tegra PCIe driver; however,
> > > > I cannot know what you mean.
> > > >
> > > > Could let me know which additional functions are needed?
> > >
> > > The mvebu 

Re: [patch v8 6/9] sched: compute runnable load avg in cpu_load and cpu_avg_load_per_task

[Alex Shi]

On 06/18/2013 07:00 AM, Paul Turner wrote:
> On Mon, Jun 17, 2013 at 6:57 AM, Alex Shi  wrote:
>> > On 06/17/2013 08:17 PM, Paul Turner wrote:
>>> >> On Mon, Jun 17, 2013 at 3:51 AM, Paul Turner  wrote:
 >>> On Fri, Jun 7, 2013 at 12:20 AM, Alex Shi  wrote:
>  They are the base values in load balance, update them with rq 
>  runnable
>  load average, then the load balance will consider runnable load avg
>  naturally.
> 
>  We also try to include the blocked_load_avg as cpu load in balancing,
>  but that cause kbuild performance drop 6% on every Intel machine, and
>  aim7/oltp drop on some of 4 CPU sockets machines.
> 
 >>>
 >>> This looks fine.
 >>>
 >>> Did you try including blocked_load_avg in only get_rq_runnable_load()
 >>> [ and not weighted_cpuload() which is called by new-idle ]?
>>> >>
>>> >> Looking at this more this feels less correct since you're taking
>>> >> averages of averages.
>>> >>
>>> >> This was previously discussed at:
>>> >>   https://lkml.org/lkml/2013/5/6/109
>>> >>
>>> >> And  you later replied suggesting this didn't seem to hurt; what's the
>>> >> current status there?
>> >
>> > Yes, your example show the blocked_load_avg value.
>> > So I had given a patch for review at that time before do detailed
>> > testing. https://lkml.org/lkml/2013/5/7/66
>> >
>> > But in detailed testing, the patch cause a big performance regression.
>> > When I look into for details. I found some cpu in kbuild just had a big
>> > blocked_load_avg, with a very small runnable_load_avg value.
>> >
>> > Seems accumulating current blocked_load_avg into cpu load isn't a good
>> > idea. Because:
> So I think this describes an alternate implementation to the one suggested in:
>   https://lkml.org/lkml/2013/5/7/66
> 
> Specifically, we _don't_ want to accumulate into cpu-load.  Taking an
> "average of the average" loses the mobility that the new
> representation allows.
> 
>> > 1, The blocked_load_avg is decayed same as runnable load, sometime is
>> > far bigger than runnable load, that drive tasks to other idle or slight
>> > load cpu, than cause both performance and power issue. But if the
>> > blocked load is decayed too fast, it lose its effect.
> This is why the idea would be to use an instantaneous load in
> weighted_cpuload() and one that incorporated averages on (wants a
> rename) get_rq_runnable_load().
> 
> For non-instaneous load-indexes we're pulling for stability.

Paul, could I summary your point here:
keep current weighted_cpu_load, but add blocked load avg in
get_rq_runnable_load?

I will test this change.
> 
>> > 2, Another issue of blocked load is that when waking up task, we can not
>> > know blocked load proportion of the task on rq. So, the blocked load is
>> > meaningless in wake affine decision.
> I think this is confusing two things:
> 
> (a) A wake-idle wake-up
> (b) A wake-affine wake-up

what's I mean the wake affine is (b). Anyway, blocked load is no help on
the scenario.
> 
> In (a) we do not care about the blocked load proportion, only whether
> a cpu is idle.
> 
> But once (a) has failed we should absolutely care how much load is
> blocked in (b) as:
> - We know we're going to queue for bandwidth on the cpu [ otherwise
> we'd be in (a) ]
> - Blocked load predicts how much _other_ work is expected to also
> share the queue with us during the quantum
> 


-- 
Thanks
Alex
--
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: Re: [PATCH 2/3] tracing/kprobes: Kill probe_enable_lock

[Masami Hiramatsu]

(2013/06/18 0:18), Oleg Nesterov wrote:
>> because
>> those calls are the reason why I have introduced this lock.
> 
> Please do not hesitate to nack this patch if you think that we should
> keep probe_enable_lock for safety even if it is not currently needed.
> In this case I'd suggest to move lock/unlock into kprobe_register()
> but this is minor.

Oh, I agree with removing probe_enable_lock itself :)
I just concerned only about the exceptional case of __init test
function, which can mislead someone to use enable/disable_trace_probe
at other racy point.

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
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] arch/*/asm/include/bitops.h: api issue, find_*_bit() defination are different with each other

[Chen Gang]

Hello related Maintainers:

Please help check this patch when you have time.

Thanks.

On 06/06/2013 05:37 PM, Chen Gang wrote:
> 
> For arm and m68k, they customize find_*_bit(), but the API is different
> with 'generic'.
> 
> avr32, s390, and unicore32 also customize find_*_bit(), but the API is
> the same with 'generic', and the left architectures all use 'generic'.
> 
> So need change arm and m68k related API to match the 'generic', then
> all another modules can face same public API for various architectures.
> 
> Also beautify code and comments to pass "./scripts/checkpatch.pl"
> 
> 
> Signed-off-by: Chen Gang 
> ---
>  arch/arm/include/asm/bitops.h  |   26 ++
>  arch/arm/lib/findbit.S |   14 ++
>  arch/m68k/include/asm/bitops.h |   25 ++---
>  3 files changed, 42 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
> index e691ec9..83e4d3a 100644
> --- a/arch/arm/include/asm/bitops.h
> +++ b/arch/arm/include/asm/bitops.h
> @@ -161,18 +161,28 @@ extern int _test_and_change_bit(int nr, volatile 
> unsigned long * p);
>  /*
>   * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
>   */
> -extern int _find_first_zero_bit_le(const void * p, unsigned size);
> -extern int _find_next_zero_bit_le(const void * p, int size, int offset);
> -extern int _find_first_bit_le(const unsigned long *p, unsigned size);
> -extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
> +extern unsigned long _find_first_zero_bit_le(const void *p,
> + unsigned long size);
> +extern unsigned long _find_next_zero_bit_le(const void *p, unsigned long 
> size,
> + unsigned long offset);
> +extern unsigned long _find_first_bit_le(const unsigned long *p,
> + unsigned long size);
> +extern unsigned long _find_next_bit_le(const unsigned long *p,
> + unsigned long size,
> + unsigned long offset);
>  
>  /*
>   * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
>   */
> -extern int _find_first_zero_bit_be(const void * p, unsigned size);
> -extern int _find_next_zero_bit_be(const void * p, int size, int offset);
> -extern int _find_first_bit_be(const unsigned long *p, unsigned size);
> -extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
> +extern unsigned long _find_first_zero_bit_be(const void *p,
> + unsigned long size);
> +extern unsigned long _find_next_zero_bit_be(const void *p, unsigned long 
> size,
> + unsigned long offset);
> +extern unsigned long _find_first_bit_be(const unsigned long *p,
> + unsigned long size);
> +extern unsigned long _find_next_bit_be(const unsigned long *p,
> + unsigned long size,
> + unsigned long offset);
>  
>  #ifndef CONFIG_SMP
>  /*
> diff --git a/arch/arm/lib/findbit.S b/arch/arm/lib/findbit.S
> index 64f6bc1..817dd70 100644
> --- a/arch/arm/lib/findbit.S
> +++ b/arch/arm/lib/findbit.S
> @@ -19,7 +19,8 @@
>  
>  /*
>   * Purpose  : Find a 'zero' bit
> - * Prototype: int find_first_zero_bit(void *addr, unsigned int maxbit);
> + * Prototype: unsigned long find_first_zero_bit(const void *p,
> + *   unsigned long size);
>   */
>  ENTRY(_find_first_zero_bit_le)
>   teq r1, #0  
> @@ -40,7 +41,9 @@ ENDPROC(_find_first_zero_bit_le)
>  
>  /*
>   * Purpose  : Find next 'zero' bit
> - * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int 
> offset)
> + * Prototype: unsigned long find_next_zero_bit(const void *p,
> + *   unsigned long size,
> + *   unsigned long offset);
>   */
>  ENTRY(_find_next_zero_bit_le)
>   teq r1, #0
> @@ -60,7 +63,8 @@ ENDPROC(_find_next_zero_bit_le)
>  
>  /*
>   * Purpose  : Find a 'one' bit
> - * Prototype: int find_first_bit(const unsigned long *addr, unsigned int 
> maxbit);
> + * Prototype: unsigned long find_first_bit(const unsigned long *p,
> + *   unsigned long size);
>   */
>  ENTRY(_find_first_bit_le)
>   teq r1, #0  
> @@ -81,7 +85,9 @@ ENDPROC(_find_first_bit_le)
>  
>  /*
>   * Purpose  : Find next 'one' bit
> - * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int 
> offset)
> + * Prototype: unsigned long find_next_bit(const unsigned long *p,
> + *   unsigned long size,
> + *   unsigned long offset);
>   */
>  ENTRY(_find_next_bit_le)
>   teq r1, #0
> diff 

[PATCH 3/4] Staging: silicom: move assignments out of if conditions

[Chad Williamson]

Remove a bunch of assignments from if-statement conditions in
bpctl_mod.c, resolving checkpatch.pl errors. (This isn't all of
them, but the patch is getting rather long...)

Signed-off-by: Chad Williamson 
---
 drivers/staging/silicom/bpctl_mod.c | 54 +++--
 1 file changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/silicom/bpctl_mod.c 
b/drivers/staging/silicom/bpctl_mod.c
index 893737a..19a9239 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -306,7 +306,8 @@ static void write_pulse(bpctl_dev_t *pbpctl_dev,
ctrl = BP10G_READ_REG(pbpctl_dev, ESDP);
 
if (pbpctl_dev->bp_10g9) {
-   if (!(pbpctl_dev_c = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_c)
return;
ctrl = BP10G_READ_REG(pbpctl_dev_c, ESDP);
}
@@ -606,7 +607,8 @@ static int read_pulse(bpctl_dev_t *pbpctl_dev, unsigned int 
ctrl_ext,
if (pbpctl_dev->bp_540)
ctrl = BP10G_READ_REG(pbpctl_dev, ESDP);
if (pbpctl_dev->bp_10g9) {
-   if (!(pbpctl_dev_c = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_c)
return -1;
ctrl = BP10G_READ_REG(pbpctl_dev_c, ESDP);
}
@@ -774,7 +776,8 @@ static void write_reg(bpctl_dev_t *pbpctl_dev, unsigned 
char value,
bpctl_dev_t *pbpctl_dev_c = NULL;
unsigned long flags;
if (pbpctl_dev->bp_10g9) {
-   if (!(pbpctl_dev_c = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_c)
return;
}
if ((pbpctl_dev->wdt_status == WDT_STATUS_EN) &&
@@ -952,7 +955,8 @@ static int read_reg(bpctl_dev_t *pbpctl_dev, unsigned char 
addr)
atomic_set(&pbpctl_dev->wdt_busy, 1);
 #endif
if (pbpctl_dev->bp_10g9) {
-   if (!(pbpctl_dev_c = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_c)
return -1;
}
 
@@ -1223,7 +1227,8 @@ static int wdt_pulse(bpctl_dev_t *pbpctl_dev)
return -1;
 #endif
if (pbpctl_dev->bp_10g9) {
-   if (!(pbpctl_dev_c = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_c = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_c)
return -1;
}
 
@@ -1743,7 +1748,8 @@ static int write_data_int(bpctl_dev_t *pbpctl_dev, 
unsigned char value)
 {
bpctl_dev_t *pbpctl_dev_b = NULL;
 
-   if (!(pbpctl_dev_b = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_b = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_b)
return -1;
atomic_set(&pbpctl_dev->wdt_busy, 1);
write_data_port_int(pbpctl_dev, value & 0x3);
@@ -1961,7 +1967,8 @@ int tpl_hw_on(bpctl_dev_t *pbpctl_dev)
int ret = 0, ctrl = 0;
bpctl_dev_t *pbpctl_dev_b = NULL;
 
-   if (!(pbpctl_dev_b = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_b = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_b)
return BP_NOT_CAP;
 
if (pbpctl_dev->bp_caps_ex & TPL2_CAP_EX) {
@@ -1988,7 +1995,8 @@ int tpl_hw_off(bpctl_dev_t *pbpctl_dev)
int ret = 0, ctrl = 0;
bpctl_dev_t *pbpctl_dev_b = NULL;
 
-   if (!(pbpctl_dev_b = get_status_port_fn(pbpctl_dev)))
+   pbpctl_dev_b = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_b)
return BP_NOT_CAP;
if (pbpctl_dev->bp_caps_ex & TPL2_CAP_EX) {
cmnd_on(pbpctl_dev);
@@ -3231,8 +3239,10 @@ int bypass_from_last_read(bpctl_dev_t *pbpctl_dev)
uint32_t ctrl_ext = 0;
bpctl_dev_t *pbpctl_dev_b = NULL;
 
-   if ((pbpctl_dev->bp_caps & SW_CTL_CAP)
-   && (pbpctl_dev_b = get_status_port_fn(pbpctl_dev))) {
+   if (pbpctl_dev->bp_caps & SW_CTL_CAP) {
+   pbpctl_dev_b = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_b)
+   return BP_NOT_CAP;
ctrl_ext = BPCTL_READ_REG(pbpctl_dev_b, CTRL_EXT);
BPCTL_BP_WRITE_REG(pbpctl_dev_b, CTRL_EXT,
   (ctrl_ext & ~BPCTLI_CTRL_EXT_SDP7_DIR));
@@ -3248,9 +3258,10 @@ int bypass_status_clear(bpctl_dev_t *pbpctl_dev)
 {
bpctl_dev_t *pbpctl_dev_b = NULL;
 
-   if ((pbpctl_dev->bp_caps & SW_CTL_CAP)
-   && (pbpctl_dev_b = get_status_port_fn(pbpctl_dev))) {
-
+   if (pbpctl_dev->bp_caps & SW_CTL_CAP) {
+   pbpctl_dev_b = get_status_port_fn(pbpctl_dev);
+   if (!pbpctl_dev_b)
+   return BP_NOT_CAP;
send_bypass_clear_pulse(pbpctl_dev_b, 1);
  

[PATCH 1/4] Staging: silicom: remove unnecessary braces in bpctl_mod.c

[Chad Williamson]

Remove unnecessary braces in bpctl_mod.c, resolving checkpatch.pl
warnings.

Signed-off-by: Chad Williamson 
---
 drivers/staging/silicom/bpctl_mod.c | 58 +++--
 1 file changed, 23 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/silicom/bpctl_mod.c 
b/drivers/staging/silicom/bpctl_mod.c
index 4c8fb86..c09dc02 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -720,16 +720,15 @@ static int read_pulse(bpctl_dev_t *pbpctl_dev, unsigned 
int ctrl_ext,
 BP10G_MDIO_DATA_OUT));
 
}
-   if (pbpctl_dev->bp_10g9) {
-   ctrl_ext = BP10G_READ_REG(pbpctl_dev, I2CCTL);
 
-   } else if ((pbpctl_dev->bp_fiber5) || (pbpctl_dev->bp_i80)) {
+   if (pbpctl_dev->bp_10g9)
+   ctrl_ext = BP10G_READ_REG(pbpctl_dev, I2CCTL);
+   else if ((pbpctl_dev->bp_fiber5) || (pbpctl_dev->bp_i80))
ctrl_ext = BPCTL_READ_REG(pbpctl_dev, CTRL);
-   } else if (pbpctl_dev->bp_540) {
+   else if (pbpctl_dev->bp_540)
ctrl_ext = BP10G_READ_REG(pbpctl_dev, ESDP);
-   } else if (pbpctl_dev->bp_10gb)
+   else if (pbpctl_dev->bp_10gb)
ctrl_ext = BP10GB_READ_REG(pbpctl_dev, MISC_REG_SPIO);
-
else if (!pbpctl_dev->bp_10g)
ctrl_ext = BPCTL_READ_REG(pbpctl_dev, CTRL_EXT);
else
@@ -1920,13 +1919,10 @@ int disc_port_on(bpctl_dev_t *pbpctl_dev)
return BP_NOT_CAP;
 
if (pbpctl_dev_m->bp_caps_ex & DISC_PORT_CAP_EX) {
-   if (is_bypass_fn(pbpctl_dev) == 1) {
-
+   if (is_bypass_fn(pbpctl_dev) == 1)
write_data(pbpctl_dev_m, TX_DISA);
-   } else {
-
+   else
write_data(pbpctl_dev_m, TX_DISB);
-   }
 
msec_delay_bp(LATCH_DELAY);
 
@@ -2017,9 +2013,9 @@ int wdt_off(bpctl_dev_t *pbpctl_dev)
int ret = BP_NOT_CAP;
 
if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
-   if (INTEL_IF_SERIES(pbpctl_dev->subdevice)) {
+   if (INTEL_IF_SERIES(pbpctl_dev->subdevice))
bypass_off(pbpctl_dev);
-   } else if (pbpctl_dev->bp_ext_ver >= PXG2BPI_VER)
+   else if (pbpctl_dev->bp_ext_ver >= PXG2BPI_VER)
write_data(pbpctl_dev, WDT_OFF);
else
data_pulse(pbpctl_dev, WDT_OFF);
@@ -2404,12 +2400,10 @@ static int set_tx(bpctl_dev_t *pbpctl_dev, int tx_state)
}
 
}
-   if (pbpctl_dev->bp_fiber5) {
+   if (pbpctl_dev->bp_fiber5)
ctrl = BPCTL_READ_REG(pbpctl_dev, CTRL_EXT);
-
-   } else if (pbpctl_dev->bp_10gb)
+   else if (pbpctl_dev->bp_10gb)
ctrl = BP10GB_READ_REG(pbpctl_dev, MISC_REG_GPIO);
-
else if (!pbpctl_dev->bp_10g)
ctrl = BPCTL_READ_REG(pbpctl_dev, CTRL);
else
@@ -4054,9 +4048,8 @@ void bypass_caps_init(bpctl_dev_t *pbpctl_dev)
pbpctl_dev->bp_caps |=
(TX_CTL_CAP | TX_STATUS_CAP | TPL_CAP);
 
-   if (TPL_IF_SERIES(pbpctl_dev->subdevice)) {
+   if (TPL_IF_SERIES(pbpctl_dev->subdevice))
pbpctl_dev->bp_caps |= TPL_CAP;
-   }
 
if (INTEL_IF_SERIES(pbpctl_dev->subdevice)) {
pbpctl_dev->bp_caps |=
@@ -4196,9 +4189,9 @@ void bypass_caps_init(bpctl_dev_t *pbpctl_dev)
if (PEG5_IF_SERIES(pbpctl_dev->subdevice))
pbpctl_dev->bp_caps |= (TX_CTL_CAP | TX_STATUS_CAP);
 
-   if (BP10GB_IF_SERIES(pbpctl_dev->subdevice)) {
+   if (BP10GB_IF_SERIES(pbpctl_dev->subdevice))
pbpctl_dev->bp_caps &= ~(TX_CTL_CAP | TX_STATUS_CAP);
-   }
+
pbpctl_dev_m = get_master_port_fn(pbpctl_dev);
if (pbpctl_dev_m != NULL) {
int cap_reg = 0;
@@ -4327,10 +4320,9 @@ int set_bypass_wd_auto(bpctl_dev_t *pbpctl_dev, unsigned 
int param)
 
 int get_bypass_wd_auto(bpctl_dev_t *pbpctl_dev)
 {
-
-   if (pbpctl_dev->bp_caps & WD_CTL_CAP) {
+   if (pbpctl_dev->bp_caps & WD_CTL_CAP)
return pbpctl_dev->reset_time;
-   }
+
return BP_NOT_CAP;
 }
 
@@ -5036,23 +5028,19 @@ static void bp_tpl_timer_fn(unsigned long param)
 
link2 = get_bypass_link_status(pbpctl_dev_b);
if ((link1) && (tx_status(pbpctl_dev))) {
-   if ((!link2) && (tx_status(pbpctl_dev_b))) {
+   if ((!link2) && (tx_status(pbpctl_dev_b)))
set_tx(pbpctl_dev, 0);
-   } else if (!tx_status(pbpctl_dev_b)) {
+   else if (!tx_status(pbpctl_dev_b))
  

[PATCH 0/4] Staging: silicom: coding style cleanup

[Chad Williamson]

More coding style cleanup in bpctl_mod.c, resolving many checkpatch.pl
warnings and errors. I've skipped a number of issues in functions that
are going to need to be split up/rewritten anyway, etc. Tearing out the
new typedefs is next on my todo list...

Chad Williamson (4):
  Staging: silicom: remove unnecessary braces in bpctl_mod.c
  Staging: silicom: whitespace fixes in bpctl_mod.c
  Staging: silicom: move assignments out of if conditions
  Staging: silicom: move more assignments out of if conditions

 drivers/staging/silicom/bpctl_mod.c | 171 
 1 file changed, 94 insertions(+), 77 deletions(-)

-- 
1.8.1.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 2/4] Staging: silicom: whitespace fixes in bpctl_mod.c

[Chad Williamson]

Two trivial whitespace fixes in bpctl_mod.c for the sake of
checkpatch.pl happiness, etc.

Signed-off-by: Chad Williamson 
---
 drivers/staging/silicom/bpctl_mod.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/silicom/bpctl_mod.c 
b/drivers/staging/silicom/bpctl_mod.c
index c09dc02..893737a 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -2028,8 +2028,8 @@ int wdt_off(bpctl_dev_t *pbpctl_dev)
 /* WDT_ON (0x10)*/
 
 /***Global***/
-static unsigned int
-wdt_val_array[] = { 1000, 1500, 2000, 3000, 4000, 8000, 16000, 32000, 0 };
+static unsigned int wdt_val_array[]
+   = { 1000, 1500, 2000, 3000, 4000, 8000, 16000, 32000, 0 };
 
 int wdt_on(bpctl_dev_t *pbpctl_dev, unsigned int timeout)
 {
@@ -6617,7 +6617,7 @@ static void find_fw(bpctl_dev_t *dev)
ioremap(mmio_start, mmio_len);
 
dev->bp_fw_ver = bypass_fw_ver(dev);
-   if (dev-> bp_fw_ver == 0xa8)
+   if (dev->bp_fw_ver == 0xa8)
break;
}
}
-- 
1.8.1.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 4/4] Staging: silicom: move more assignments out of if conditions

[Chad Williamson]

Remove more assignments from if-statement conditions in bpctl_mod.c,
resolving checkpatch.pl errors. Those that remain need more attention
than I'm presently prepared to give them.

Signed-off-by: Chad Williamson 
---
 drivers/staging/silicom/bpctl_mod.c | 53 -
 1 file changed, 34 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/silicom/bpctl_mod.c 
b/drivers/staging/silicom/bpctl_mod.c
index 19a9239..91a6afd 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -4222,9 +4222,8 @@ void bypass_caps_init(bpctl_dev_t *pbpctl_dev)
 
 int bypass_off_init(bpctl_dev_t *pbpctl_dev)
 {
-   int ret = 0;
-
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   int ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (INTEL_IF_SERIES(pbpctl_dev->subdevice))
return dis_bypass_cap(pbpctl_dev);
@@ -4409,7 +4408,8 @@ int set_bypass_fn(bpctl_dev_t *pbpctl_dev, int 
bypass_mode)
 
if (!(pbpctl_dev->bp_caps & BP_CAP))
return BP_NOT_CAP;
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (!bypass_mode)
ret = bypass_off(pbpctl_dev);
@@ -4441,7 +4441,8 @@ int set_dis_bypass_fn(bpctl_dev_t *pbpctl_dev, int 
dis_param)
 
if (!(pbpctl_dev->bp_caps & BP_DIS_CAP))
return BP_NOT_CAP;
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (dis_param)
ret = dis_bypass_cap(pbpctl_dev);
@@ -4467,7 +4468,8 @@ int set_bypass_pwoff_fn(bpctl_dev_t *pbpctl_dev, int 
bypass_mode)
 
if (!(pbpctl_dev->bp_caps & BP_PWOFF_CTL_CAP))
return BP_NOT_CAP;
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (bypass_mode)
ret = bypass_state_pwroff(pbpctl_dev);
@@ -4493,7 +4495,8 @@ int set_bypass_pwup_fn(bpctl_dev_t *pbpctl_dev, int 
bypass_mode)
 
if (!(pbpctl_dev->bp_caps & BP_PWUP_CTL_CAP))
return BP_NOT_CAP;
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (bypass_mode)
ret = bypass_state_pwron(pbpctl_dev);
@@ -4520,7 +4523,8 @@ int set_bypass_wd_fn(bpctl_dev_t *pbpctl_dev, int timeout)
if (!(pbpctl_dev->bp_caps & WD_CTL_CAP))
return BP_NOT_CAP;
 
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (!timeout)
ret = wdt_off(pbpctl_dev);
@@ -4589,7 +4593,8 @@ int set_std_nic_fn(bpctl_dev_t *pbpctl_dev, int nic_mode)
if (!(pbpctl_dev->bp_caps & STD_NIC_CAP))
return BP_NOT_CAP;
 
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
if (nic_mode)
ret = std_nic_on(pbpctl_dev);
@@ -4655,7 +4660,8 @@ int get_tap_pwup_fn(bpctl_dev_t *pbpctl_dev)
if (!pbpctl_dev)
return -1;
 
-   if ((ret = default_pwron_tap_status(pbpctl_dev)) < 0)
+   ret = default_pwron_tap_status(pbpctl_dev);
+   if (ret < 0)
return ret;
return ((ret == 0) ? 1 : 0);
 }
@@ -4830,7 +4836,8 @@ int get_disc_port_pwup_fn(bpctl_dev_t *pbpctl_dev)
if (!pbpctl_dev)
return -1;
 
-   if ((ret = default_pwron_disc_port_status(pbpctl_dev)) < 0)
+   ret = default_pwron_disc_port_status(pbpctl_dev);
+   if (ret < 0)
return ret;
return ((ret == 0) ? 1 : 0);
 }
@@ -4857,7 +4864,8 @@ int reset_cont_fn(bpctl_dev_t *pbpctl_dev)
if (!pbpctl_dev)
return -1;
 
-   if ((ret = cmnd_on(pbpctl_dev)) < 0)
+   ret = cmnd_on(pbpctl_dev);
+   if (ret < 0)
return ret;
return reset_cont(pbpctl_dev);
 }
@@ -4873,8 +4881,10 @@ int set_tx_fn(bpctl_dev_t *pbpctl_dev, int tx_state)
(pbpctl_dev->bp_caps & SW_CTL_CAP)) {
if ((pbpctl_dev->bp_tpl_flag))
return BP_NOT_CAP;
-   } else if ((pbpctl_dev_b = get_master_port_fn(pbpctl_dev))) {
-   if ((pbpctl_dev_b->bp_caps & TPL_CAP) &&
+   } else {
+   pbpctl_dev_b = get_master_port_fn(pbpctl_dev);
+   if (pbpctl_dev_b &&
+   (pbpctl_dev_b->bp_caps & TPL_CAP) &&
(pbpctl_dev_b->bp_tpl_flag))
return BP_NOT_CAP;
}
@@ -4990,8 +5000,10 @@ int get_tx_fn(bpctl_dev_t *pbpctl_dev)
(pbpctl_dev->bp_caps & SW_CTL_CAP)) {
if ((pbpctl_dev->bp_tpl_flag))
return BP_NOT_CAP;
-   } else if ((pbpctl_dev_b = get_master_port_

[PATCH v3 3/3] sched: scale cpu load for judgment of group imbalance

[Lei Wen]

We cannot compare two load directly from two cpus, since the cpu power
over two cpu may vary largely.

Suppose we meet such two kind of cpus.
CPU A:
No real time work, and there are 3 task, with rq->load.weight
being 512.
CPU B:
Has real time work, and it take 3/4 of the cpu power, which
makes CFS only take 1/4, that is 1024/4=256 cpu power. And over its CFS
runqueue, there is only one task with weight as 128.

Since both cpu's CFS task take for half of the CFS's cpu power, it
should be considered as balanced in such case.

But original judgment like:
if ((max_cpu_load - min_cpu_load) >= avg_load_per_task &&
(max_nr_running - min_nr_running) > 1)
It makes (512-128)>=((512+128)/4), and lead to imbalance conclusion...

Make the load as scaled, to avoid such case.

Signed-off-by: Lei Wen 
---
 kernel/sched/fair.c |   19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6173095..12826f9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4434,7 +4434,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
int local_group, int *balance, struct sg_lb_stats *sgs)
 {
unsigned long nr_running, max_nr_running, min_nr_running;
-   unsigned long load, max_cpu_load, min_cpu_load;
+   unsigned long scaled_load, load, max_cpu_load, min_cpu_load;
unsigned int balance_cpu = -1, first_idle_cpu = 0;
unsigned long avg_load_per_task = 0;
int i;
@@ -4464,10 +4464,12 @@ static inline void update_sg_lb_stats(struct lb_env 
*env,
load = target_load(i, load_idx);
} else {
load = source_load(i, load_idx);
-   if (load > max_cpu_load)
-   max_cpu_load = load;
-   if (min_cpu_load > load)
-   min_cpu_load = load;
+   scaled_load = load * SCHED_POWER_SCALE
+   / cpu_rq(i)->cpu_power;
+   if (scaled_load > max_cpu_load)
+   max_cpu_load = scaled_load;
+   if (min_cpu_load > scaled_load)
+   min_cpu_load = scaled_load;
 
if (nr_running > max_nr_running)
max_nr_running = nr_running;
@@ -4511,8 +4513,11 @@ static inline void update_sg_lb_stats(struct lb_env *env,
 *  normalized nr_running number somewhere that negates
 *  the hierarchy?
 */
-   if (sgs->sum_nr_running)
-   avg_load_per_task = sgs->sum_weighted_load / 
sgs->sum_nr_running;
+   if (sgs->sum_nr_running) {
+   avg_load_per_task = sgs->sum_weighted_load * SCHED_POWER_SCALE
+   / group->sgp->power;
+   avg_load_per_task /= sgs->sum_nr_running;
+   }
 
if ((max_cpu_load - min_cpu_load) >= avg_load_per_task &&
(max_nr_running - min_nr_running) > 1)
-- 
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: ext4 extent status tree LRU locking

[Zheng Liu]

On Mon, Jun 17, 2013 at 10:51:34PM -0400, Theodore Ts'o wrote:
> On Tue, Jun 18, 2013 at 10:25:48AM +0800, Zheng Liu wrote:
> > Ah, sorry, I forgot to mention that this patch bases against ext4/master
> > branch.  Now ext4/dev branch has some regression when I run xfstests.
> 
> What regressions are you seeing?

generic/300.

When I try to test my patch, I know that there has a report that
invalidate page range patch set causes a regression, and I am not sure
whether invalidate page range patch set causes it or not.  So I decide
to generate my patch against ext4/master.  So, don't worry. :-)

BTW, I will run xfstests this week.  If I meet any regression, I will
let you know.

> 
> > Ted, I notice that now in ext4 tree we have 'dev', 'dev-with-revert',
> > and 'dev2' branches.  Which one is the best to generate a new patch for
> > the next merge window?
> 
> Either the dev branch or the master branch.   
> 
> The dev-with-revert and dev2 were branches that I had created when
> investigating a potential regression with the invalidage page range
> patch set.  I've since determined that it's a timing issue and it's
> not a new regression --- we've had xfstests failures with test
> generic/300 for a while now.

Thanks for pointing it out.

- Zheng
--
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 1/3] sched: reduce calculation effort in fix_small_imbalance

[Lei Wen]

Actually all below item could be repalced by scaled_busy_load_per_task
(sds->busiest_load_per_task * SCHED_POWER_SCALE)
/sds->busiest->sgp->power;

Signed-off-by: Lei Wen 
---
 kernel/sched/fair.c |   19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c61a614..28052fa 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4727,20 +4727,17 @@ void fix_small_imbalance(struct lb_env *env, struct 
sd_lb_stats *sds)
pwr_now /= SCHED_POWER_SCALE;
 
/* Amount of load we'd subtract */
-   tmp = (sds->busiest_load_per_task * SCHED_POWER_SCALE) /
-   sds->busiest->sgp->power;
-   if (sds->max_load > tmp)
+   if (sds->max_load > scaled_busy_load_per_task) {
pwr_move += sds->busiest->sgp->power *
-   min(sds->busiest_load_per_task, sds->max_load - tmp);
-
-   /* Amount of load we'd add */
-   if (sds->max_load * sds->busiest->sgp->power <
-   sds->busiest_load_per_task * SCHED_POWER_SCALE)
-   tmp = (sds->max_load * sds->busiest->sgp->power) /
-   sds->this->sgp->power;
-   else
+   min(sds->busiest_load_per_task,
+   sds->max_load - scaled_busy_load_per_task);
tmp = (sds->busiest_load_per_task * SCHED_POWER_SCALE) /
sds->this->sgp->power;
+   } else
+   tmp = (sds->max_load * sds->busiest->sgp->power) /
+   sds->this->sgp->power;
+
+   /* Amount of load we'd add */
pwr_move += sds->this->sgp->power *
min(sds->this_load_per_task, sds->this_load + tmp);
pwr_move /= SCHED_POWER_SCALE;
-- 
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: [PATCH] kernel: timer: looping issue, need reset variable 'found'

[Chen Gang]

Sorry again for replying late, and now I can focus on this patch, I will
see the related details again.


Thanks.

On 06/13/2013 11:39 AM, Chen Gang wrote:
> 
> Sorry for replying late during these days, firstly.
> 
> 
> On 06/10/2013 10:12 PM, Thomas Gleixner wrote:
>> On Sun, 9 Jun 2013, Chen Gang wrote:
>>

 According to __internal_add_timer(), in _next_timer_interrupt(), when
 'tv1.vec' find one, but need 'cascade bucket(s)', we still need find
 each slot of 'tv*.vec'.
>> No, we do not. We only need to scan the first cascade array after the
>> enqueued timer. If there is nothing in tv2 which might come before the
>> found timer, then any timer in tv3 will be later than the one we found
>> in the primary wheel.
>>
> 
> OK, thanks, I should read details to confirm it (at least now, I still
> not quite be sure about it).
> 
> 
 So need reset variable 'found', so can fully scan ''do {...} while()''
 for 'tv*.vec'.
>> And thereby lose the information, that we already found a timer in the
>> scan of the primary array.
> 
> Hmm..., I should read details.
> 
> 
> And excuse me, I also have to do another things during these days, so
> maybe reply late.
> 
> 
> Thanks.
> 


-- 
Chen Gang

Asianux Corporation
--
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 0/3] small fix for scale usage

[Lei Wen]

Here are three patches which correct scale usage in both fix_small_imbalance
and update_sg_lb_stats.

And give out comment over when fix_small_imbalance would cause load change.

V2: fix scale usage for update_sg_lb_stats

V3: fix scale problem in comparing sds->busiest_load_per_task
and sds->avg_load when there is not balanced group inside the domain


Lei Wen (3):
  sched: reduce calculation effort in fix_small_imbalance
  sched: scale the busy and this queue's per-task load before compare
  sched: scale cpu load for judgment of group imbalance

 kernel/sched/fair.c |   64 +++
 1 file changed, 39 insertions(+), 25 deletions(-)

-- 
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 v3 2/3] sched: scale the busy and this queue's per-task load before compare

[Lei Wen]

Since for max_load and this_load, they are the value that already be
scaled. It is not reasonble to get a minimum value between the scaled
and non-scaled value, like below example.
min(sds->busiest_load_per_task, sds->max_load);

Also add comment over in what condition, there would be cpu power gain
in move the load.

Signed-off-by: Lei Wen 
---
 kernel/sched/fair.c |   38 +-
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 28052fa..6173095 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4692,10 +4692,14 @@ void fix_small_imbalance(struct lb_env *env, struct 
sd_lb_stats *sds)
 {
unsigned long tmp, pwr_now = 0, pwr_move = 0;
unsigned int imbn = 2;
-   unsigned long scaled_busy_load_per_task;
 
if (sds->this_nr_running) {
sds->this_load_per_task /= sds->this_nr_running;
+
+   /* Scale this_load_per_task to local power not related */
+   sds->this_load_per_task <<= SCHED_POWER_SHIFT;
+   sds->this_load_per_task /= sds->this->sgp->power;
+
if (sds->busiest_load_per_task >
sds->this_load_per_task)
imbn = 1;
@@ -4704,12 +4708,8 @@ void fix_small_imbalance(struct lb_env *env, struct 
sd_lb_stats *sds)
cpu_avg_load_per_task(env->dst_cpu);
}
 
-   scaled_busy_load_per_task = sds->busiest_load_per_task
-* SCHED_POWER_SCALE;
-   scaled_busy_load_per_task /= sds->busiest->sgp->power;
-
-   if (sds->max_load - sds->this_load + scaled_busy_load_per_task >=
-   (scaled_busy_load_per_task * imbn)) {
+   if (sds->max_load - sds->this_load + sds->busiest_load_per_task >=
+   (sds->busiest_load_per_task * imbn)) {
env->imbalance = sds->busiest_load_per_task;
return;
}
@@ -4727,22 +4727,29 @@ void fix_small_imbalance(struct lb_env *env, struct 
sd_lb_stats *sds)
pwr_now /= SCHED_POWER_SCALE;
 
/* Amount of load we'd subtract */
-   if (sds->max_load > scaled_busy_load_per_task) {
+   if (sds->max_load > sds->busiest_load_per_task) {
pwr_move += sds->busiest->sgp->power *
min(sds->busiest_load_per_task,
-   sds->max_load - scaled_busy_load_per_task);
-   tmp = (sds->busiest_load_per_task * SCHED_POWER_SCALE) /
-   sds->this->sgp->power;
+   sds->max_load - sds->busiest_load_per_task);
+   tmp = sds->busiest_load_per_task;
} else
-   tmp = (sds->max_load * sds->busiest->sgp->power) /
-   sds->this->sgp->power;
+   tmp = sds->max_load;
 
+   /* Scale to this queue from busiest queue */
+   tmp = (tmp * sds->busiest->sgp->power) /
+   sds->this->sgp->power;
/* Amount of load we'd add */
pwr_move += sds->this->sgp->power *
min(sds->this_load_per_task, sds->this_load + tmp);
pwr_move /= SCHED_POWER_SCALE;
 
/* Move if we gain throughput */
+   /*
+* The only possibilty for below statement be true, is:
+* sds->max_load is larger than sds->busiest_load_per_task, while,
+* sds->busiest_load_per_task is larger than sds->this_load plus by
+* the scaled sds->busiest_load_per_task moved into this queue
+*/
if (pwr_move > pwr_now)
env->imbalance = sds->busiest_load_per_task;
 }
@@ -4758,6 +4765,11 @@ static inline void calculate_imbalance(struct lb_env 
*env, struct sd_lb_stats *s
unsigned long max_pull, load_above_capacity = ~0UL;
 
sds->busiest_load_per_task /= sds->busiest_nr_running;
+
+   /* Scale busiest_load_per_task to local power not related */
+   sds->busiest_load_per_task <<= SCHED_POWER_SHIFT;
+   sds->busiest_load_per_task /= sds->busiest->sgp->power;
+
if (sds->group_imb) {
sds->busiest_load_per_task =
min(sds->busiest_load_per_task, sds->avg_load);
-- 
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: [RFC 08/10] irqdomain: Refactor irq_domain_associate_many()

[Mike Qiu]

于 2013/6/10 8:49, Grant Likely 写道:

Originally, irq_domain_associate_many() was designed to unwind the
mapped irqs on a failure of any individual association. However, that
proved to be a problem with certain IRQ controllers. Some of them only
support a subset of irqs, and will fail when attempting to map a
reserved IRQ. In those cases we want to map as many IRQs as possible, so
instead it is better for irq_domain_associate_many() to make a
best-effort attempt to map irqs, but not fail if any or all of them
don't succeed. If a caller really cares about how many irqs got
associated, then it should instead go back and check that all of the
irqs is cares about were mapped.

The original design open-coded the individual association code into the
body of irq_domain_associate_many(), but with no longer needing to
unwind associations, the code becomes simpler to split out
irq_domain_associate() to contain the bulk of the logic, and
irq_domain_associate_many() to be a simple loop wrapper.

This patch also adds a new error check to the associate path to make
sure it isn't called for an irq larger than the controller can handle,
and adds locking so that the irq_domain_mutex is held while setting up a
new association.

Signed-off-by: Grant Likely 
---
  include/linux/irqdomain.h |  22 +++---
  kernel/irq/irqdomain.c| 185 +++---
  2 files changed, 101 insertions(+), 106 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index fd4b26f..f9e8e06 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -103,6 +103,7 @@ struct irq_domain {
struct irq_domain_chip_generic *gc;

/* reverse map data. The linear map gets appended to the irq_domain */
+   irq_hw_number_t hwirq_max;
unsigned int revmap_direct_max_irq;
unsigned int revmap_size;
struct radix_tree_root revmap_tree;
@@ -110,8 +111,8 @@ struct irq_domain {
  };

  #ifdef CONFIG_IRQ_DOMAIN
-struct irq_domain *__irq_domain_add(struct device_node *of_node,
-   int size, int direct_max,
+struct irq_domain *__irq_domain_add(struct device_node *of_node, int size,
+   irq_hw_number_t hwirq_max, int direct_max,
const struct irq_domain_ops *ops,
void *host_data);
  struct irq_domain *irq_domain_add_simple(struct device_node *of_node,
@@ -140,14 +141,14 @@ static inline struct irq_domain 
*irq_domain_add_linear(struct device_node *of_no
 const struct irq_domain_ops *ops,
 void *host_data)
  {
-   return __irq_domain_add(of_node, size, 0, ops, host_data);
+   return __irq_domain_add(of_node, size, size, 0, ops, host_data);
  }
  static inline struct irq_domain *irq_domain_add_nomap(struct device_node 
*of_node,
 unsigned int max_irq,
 const struct irq_domain_ops *ops,
 void *host_data)
  {
-   return __irq_domain_add(of_node, 0, max_irq, ops, host_data);
+   return __irq_domain_add(of_node, 0, max_irq, max_irq, ops, host_data);
  }
  static inline struct irq_domain *irq_domain_add_legacy_isa(
struct device_node *of_node,
@@ -166,14 +167,11 @@ static inline struct irq_domain 
*irq_domain_add_tree(struct device_node *of_node

  extern void irq_domain_remove(struct irq_domain *host);

-extern int irq_domain_associate_many(struct irq_domain *domain,
-unsigned int irq_base,
-irq_hw_number_t hwirq_base, int count);
-static inline int irq_domain_associate(struct irq_domain *domain, unsigned int 
irq,
-   irq_hw_number_t hwirq)
-{
-   return irq_domain_associate_many(domain, irq, hwirq, 1);
-}
+extern int irq_domain_associate(struct irq_domain *domain, unsigned int irq,
+   irq_hw_number_t hwirq);
+extern void irq_domain_associate_many(struct irq_domain *domain,
+ unsigned int irq_base,
+ irq_hw_number_t hwirq_base, int count);

  extern unsigned int irq_create_mapping(struct irq_domain *host,
   irq_hw_number_t hwirq);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 280b804..80e9249 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -35,8 +35,8 @@ static struct irq_domain *irq_default_domain;
   * register allocated irq_domain with irq_domain_register().  Returns pointer
   * to IRQ domain, or NULL on failure.
   */
-struct irq_domain *__irq_domain_add(struct device_node *of_node,
-   int size, int direct_max,
+struct irq_domain *__irq_domain_add(struct devi

Re: [PATCH] usb: host: Faraday fotg210-hcd driver

[Sarah Sharp]

On Tue, Jun 18, 2013 at 10:42:09AM +0800, Yuan-Hsin Chen wrote:
> Hi,
> 
> On Tue, Jun 18, 2013 at 4:39 AM, Greg KH  wrote:
> > On Wed, Jun 05, 2013 at 05:15:43PM +, Yuan-Hsin Chen wrote:
> >> FOTG210 is an OTG controller which can be configured as an
> >> USB2.0 host. FOTG210 host is an ehci-like controller with
> >> some differences. First, register layout of FOTG210 is
> >> incompatible with EHCI. Furthermore, FOTG210 is lack of
> >> siTDs which means iTDs are used for both HS and FS ISO
> >> transfer.
> >>
> >> Signed-off-by: Yuan-Hsin Chen 
> >> ---
> >>  drivers/usb/Makefile   |1 +
> >>  drivers/usb/host/Kconfig   |   12 +
> >>  drivers/usb/host/Makefile  |1 +
> >>  drivers/usb/host/fotg210-hcd.c | 5967 
> >> 
> >>  drivers/usb/host/fotg210.h |  746 +
> >>  5 files changed, 6727 insertions(+), 0 deletions(-)
> >>  create mode 100644 drivers/usb/host/fotg210-hcd.c
> >>  create mode 100644 drivers/usb/host/fotg210.h
> >
> > You obviously didn't even run this through checkpatch.pl, did you?
> >
> > $ ./scripts/checkpatch.pl --terse ../usb.mbox | tail -n 1
> > total: 138 errors, 618 warnings, 6742 lines checked
> >
> > Please fix all of these if you wish us to at least start reviewing the
> > patch.  Your internal Q/A should have caught this first, please be more
> > careful in the future.
> >
> 
> Actually I did run checkpatch.pl and found that almost all errors and
> warnings are from ehci core (ehci-hcd.c, ehci-hub.c and so on) where
> my driver borrowed most of code.
> 
> $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hub.c | tail -n 1
> total: 18 errors, 69 warnings, 1138 lines checked
> 
> $ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hcd.c | tail -n 1
> total: 17 errors, 78 warnings, 1403 lines checked
> 
> So you're saying that I should fix them, is that right?

In that case, no, you should be figuring out how to refactor and reuse
the EHCI code instead of copying it straight into your driver.

Sarah Sharp
--
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 drm-intel tree with the drm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_fb.c between commit b72447cdf129 ("drm/i915:
Drop bogus fbdev sprite disable code") from the drm tree and commit
b51b32cde175 ("drm/i915: s/drm_i915_private_t/struct drm_i915_private/")
from the drm-intel 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 drivers/gpu/drm/i915/intel_fb.c
index 3b03c3c,244060a..000
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@@ -291,7 -292,9 +292,7 @@@ void intel_fb_output_poll_changed(struc
  void intel_fb_restore_mode(struct drm_device *dev)
  {
int ret;
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
 -  struct drm_mode_config *config = &dev->mode_config;
 -  struct drm_plane *plane;
  
if (INTEL_INFO(dev)->num_pipes == 0)
return;


pgp1v0yfFTF8K.pgp
Description: PGP signature

Re: ext4 extent status tree LRU locking

[Theodore Ts'o]

On Tue, Jun 18, 2013 at 10:25:48AM +0800, Zheng Liu wrote:
> Ah, sorry, I forgot to mention that this patch bases against ext4/master
> branch.  Now ext4/dev branch has some regression when I run xfstests.

What regressions are you seeing?

> Ted, I notice that now in ext4 tree we have 'dev', 'dev-with-revert',
> and 'dev2' branches.  Which one is the best to generate a new patch for
> the next merge window?

Either the dev branch or the master branch.   

The dev-with-revert and dev2 were branches that I had created when
investigating a potential regression with the invalidage page range
patch set.  I've since determined that it's a timing issue and it's
not a new regression --- we've had xfstests failures with test
generic/300 for a while now.

- 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/3] tracing/kprobes: Kill probe_enable_lock

[Masami Hiramatsu]

(2013/06/18 0:18), Oleg Nesterov wrote:
> On 06/17, Masami Hiramatsu wrote:
>>
>> (2013/06/17 2:21), Oleg Nesterov wrote:
>>> enable_trace_probe() and disable_trace_probe() should not worry about
>>> serialization, the caller (perf_trace_init or __ftrace_set_clr_event)
>>> holds event_mutex.
>>>
>>> They are also called by kprobe_trace_self_tests_init(), but this __init
>>> function can't race with itself or trace_events.c
>>
>> Right,
>> For safety, we should comment this at the caller side,
> 
> Which caller do you mean?

I meant the caller was kprobe_test_self_tests_init().
Since that function calls enable/disable_trace_probe()
without holding event_mutex, we need to notice that
(this is safe because there is no race) at the calling
places :)

Thank you,

> 
> The patch adds
> 
>   /*
>* This and enable_trace_probe/disable_trace_probe rely on event_mutex
>* held by the caller, __ftrace_set_clr_event().
>*/
> 
> above trace_probe_nr_files() but the next patch removes this function
> with the comment...
> 
> Will you agree with this patch if I add something like
> 
>   /*
>* called by perf_trace_init() or __ftrace_set_clr_event() under 
> event_mutex
>*/
> 
> above kprobe_register() ? Perhaps it makes sense to add
> lockdep_assert_held(&event_mutex) into the body?
> 
> And:
> 
>> because
>> those calls are the reason why I have introduced this lock.
> 
> Please do not hesitate to nack this patch if you think that we should
> keep probe_enable_lock for safety even if it is not currently needed.
> In this case I'd suggest to move lock/unlock into kprobe_register()
> but this is minor.
> 
> Oleg.
> 
> 


-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
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] x86, efi: retry ExitBootServices() on failure

[joeyli]

Hi Zach, 

於 二，2013-06-18 於 00:18 +，Zachary Bobroff 提到：
> All,
> 
> >> Why a single retry is having reasonable guarantees to work when the
> original one failed (nothing prevents an event handler to do another
> allocation the next time through).
> 
> This patch is being submitted because of the potential issues that
> occur when 3rd party option ROMs are signaled by the ExitBootServices
> event. At the time they are signaled, they can perform any number of
> actions that would change the EFI Memory map.  This wasn't actually
> seen with our default implementation of our firmware, it was seen when
> this plug-in card's option rom was run.
> 
> We only need to retry once because of what is in the UEFI
> specification 2.3.1 Errata C.  The exact verbiage is as follows:
> 
> The ExitBootServices() function is called by the currently executing
> EFI OS loader image to terminate all boot services. On success, the
> loader becomes responsible for the continued operation of the system.
> All events of type EVT_SIGNAL_EXIT_BOOT_SERVICES must be signaled
> before ExitBootServices() returns EFI_SUCCESS. The events are only
> signaled once even if ExitBootServices() is called multiple times.
> 
> Since the firmware will only signal the ExitBootServices event once,
> the code that has the potential to change the memory map will only be
> signaled on the first call to exit boot services. 

Does it possible have any delay time of 3rd party ROMs to change EFI
memory map after they are signaled?
or ExitBootServices() will wait all 3rd party ROMs updated memory map
finished then return true/false to kernel?


Thanks a lot!
Joey 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/

Re: ext4 extent status tree LRU locking

[Theodore Ts'o]

> Subject: [PATCH v2] ext4: improve extent cache shrink mechanism to avoid to 
> burn CPU time
> 
> From: Zheng Liu 
> 
> Now we maintain an proper in-order LRU list in ext4 to reclaim entries
> from extent status tree when we are under heavy memory pressure.  For
> keeping this order, a spin lock is used to protect this list.  But this
> lock burns a lot of CPU time.  We can use the following steps to trigger
> it.
> 
>   % cd /dev/shm
>   % dd if=/dev/zero of=ext4-img bs=1M count=2k
>   % mkfs.ext4 ext4-img
>   % mount -t ext4 -o loop ext4-img /mnt
>   % cd /mnt
>   % for ((i=0;i<160;i++)); do truncate -s 64g $i; done
>   % for ((i=0;i<160;i++)); do cp $i /dev/null &; done
>   % perf record -a -g
>   % perf report
> 
> This commit tries to fix this problem.  Now a new member called
> i_touch_when is added into ext4_inode_info to record the last access
> time for an inode.  Meanwhile we never need to keep a proper in-order
> LRU list.  So this can avoid to burns some CPU time.  When we try to
> reclaim some entries from extent status tree, we use list_sort() to get
> a proper in-order list.  Then we traverse this list to discard some
> entries.  In ext4_sb_info, we use s_es_last_sorted to record the last
> time of sorting this list.  When we traverse the list, we skip the inode
> that is newer than this time, and move this inode to the tail of LRU
> list.  When the head of the list is newer than s_es_last_sorted, we will
> sort the LRU list again.
> 
> In this commit, we break the loop if s_extent_cache_cnt == 0 because
> that means that all extents in extent status tree have been reclaimed.
> 
> Meanwhile in this commit, ext4_es_{un}register_shrinker()'s prototype is
> changed to save a local variable in these functions.
> 
> Reported-by: Dave Hansen 
> Cc: "Theodore Ts'o" 
> Signed-off-by: Zheng Liu 

Applied, thanks.

- 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: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

[Dave Chinner]

On Tue, Jun 18, 2013 at 02:30:05AM +0400, Glauber Costa wrote:
> On Mon, Jun 17, 2013 at 02:35:08PM -0700, Andrew Morton wrote:
> > On Mon, 17 Jun 2013 19:14:12 +0400 Glauber Costa  wrote:
> > 
> > > > I managed to trigger:
> > > > [ 1015.776029] kernel BUG at mm/list_lru.c:92!
> > > > [ 1015.776029] invalid opcode:  [#1] SMP
> > > > with Linux next (next-20130607) with https://lkml.org/lkml/2013/6/17/203
> > > > on top. 
> > > > 
> > > > This is obviously BUG_ON(nlru->nr_items < 0) and 
> > > > 81122d0b:   48 85 c0test   %rax,%rax
> > > > 81122d0e:   49 89 44 24 18  mov%rax,0x18(%r12)
> > > > 81122d13:   0f 84 87 00 00 00   je 81122da0 
> > > > 
> > > > 81122d19:   49 83 7c 24 18 00   cmpq   $0x0,0x18(%r12)
> > > > 81122d1f:   78 7b   js 81122d9c 
> > > > 
> > > > [...]
> > > > 81122d9c:   0f 0b   ud2
> > > > 
> > > > RAX is -1UL.
> > > Yes, fearing those kind of imbalances, we decided to leave the counter as 
> > > a signed quantity
> > > and BUG, instead of an unsigned quantity.
> > > 
> > > > 
> > > > I assume that the current backtrace is of no use and it would most
> > > > probably be some shrinker which doesn't behave.
> > > > 
> > > There are currently 3 users of list_lru in tree: dentries, inodes and xfs.
> > > Assuming you are not using xfs, we are left with dentries and inodes.
> > > 
> > > The first thing to do is to find which one of them is misbehaving. You 
> > > can try finding
> > > this out by the address of the list_lru, and where it lays in the 
> > > superblock.
> > > 
> > > Once we know each of them is misbehaving, then we'll have to figure out 
> > > why.
> > 
> > The trace says shrink_slab_node->super_cache_scan->prune_icache_sb.  So
> > it's inodes?
> > 
> Assuming there is no memory corruption of any sort going on , let's check the 
> code.
> nr_item is only manipulated in 3 places:
> 
> 1) list_lru_add, where it is increased
> 2) list_lru_del, where it is decreased in case the user have voluntarily 
> removed the
>element from the list
> 3) list_lru_walk_node, where an element is removing during shrink.
> 
> All three excerpts seem to be correctly locked, so something like this 
> indicates an imbalance.

inode_lru_isolate() looks suspicious to me:

WARN_ON(inode->i_state & I_NEW);
inode->i_state |= I_FREEING;
spin_unlock(&inode->i_lock);

list_move(&inode->i_lru, freeable);
this_cpu_dec(nr_unused);
return LRU_REMOVED;
}

All the other cases where I_FREEING is set and the inode is removed
from the LRU are completely done under the inode->i_lock. i.e. from
an external POV, the state change to I_FREEING and removal from LRU
are supposed to be atomic, but they are not here.

I'm not sure this is the source of the problem, but it definitely
needs fixing.

> callers:
> iput_final, evict_inodes, invalidate_inodes.
> Both evict_inodes and invalidate_inodes will do the following pattern:
> 
> inode->i_state |= I_FREEING;  
>   
> inode_lru_list_del(inode);
> spin_unlock(&inode->i_lock);
> list_add(&inode->i_lru, &dispose);
> 
> IOW, they will remove the element from the LRU, and add it to the dispose 
> list.
> Both of them will also bail out if they see I_FREEING already set, so they 
> are safe
> against each other - because the flag is manipulated inside the lock.
> 
> But how about iput_final? It seems to me that if we are calling iput_final at 
> the
> same time as the other two, this *could* happen (maybe there is some extra 
> protection
> that can be seen from Australia but not from here. Dave?)

If I_FREEING is set before we enter iput_final(), then something
else is screwed up. I_FREEING is only set once the last reference
has gone away and we are killing the inode. All the other callers
that set I_FREEING check that the reference count on the inode is
zero before they set I_FREEING. Hence I_FREEING cannot be set on the
transition of i_count from 1 to 0 when iput_final() is called. So
the patch won't do anything to avoid the problem being seen.

Keep in mind that we this is actually a new warning on the count of
inodes on the LRU - we never had a check that it didn't go negative
before

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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: [lttng-dev] [-stable 3.8.1 performance regression] madvise POSIX_FADV_DONTNEED

[Andrew Morton]

On Mon, 17 Jun 2013 22:15:28 -0400 Mathieu Desnoyers 
 wrote:

> * Andrew Morton (a...@linux-foundation.org) wrote:
> > On Mon, 17 Jun 2013 17:39:36 -0400 Rapha__l Beamonte 
> >  wrote:
> > 
> > > 2013/6/17 Andrew Morton 
> > > 
> > > > That change wasn't terribly efficient - if there are any unpopulated
> > > > pages in the range (which is quite likely), fadvise() will now always
> > > > call invalidate_mapping_pages() a second time.
> > > >
> > > > Perhaps this is fixable.  Say, make lru_add_drain_all() return a
> > > > success code, or even teach lru_add_drain_all() to return a code
> > > > indicating that one of the spilled pages was (or might have been) on a
> > > > particular mapping.
> > > >
> > > 
> > > Following our tests results, that was the call to lru_add_drain_all() that
> > > causes the problem. The second call to invalidate_mapping_pages() isn't
> > > really important. We tried to compile a kernel with the commit introducing
> > > this change but with the "lru_add_drain_all()" line removed, and the
> > > problem disappeared, even if we called two times 
> > > invalidate_mapping_pages()
> > > (as the rest of the commit was still here).
> > 
> > Ah, OK, schedule_on_each_cpu() could certainly do that - it has to wait
> > for every CPU to context switch and schedule the worker function.
> > 
> > There's a lot we could do here.  Such as not doing the schedule_work()
> > at all for a cpu which has an empty lru_add_pvec.
> 
> First approach proposed, submitted as RFC. Compile-tested only.
> 
> ...
>
> Second approach, submitted as RFC with some questions left unanswered
> in the code. Compile-tested only.
> 
> ---
>  include/linux/swap.h |1 
>  mm/fadvise.c |2 -
>  mm/swap.c|   62 
> +++
>  3 files changed, 64 insertions(+), 1 deletion(-)
> 
> Index: linux/include/linux/swap.h
> ===
> --- linux.orig/include/linux/swap.h
> +++ linux/include/linux/swap.h
> @@ -242,6 +242,7 @@ extern void mark_page_accessed(struct pa
>  extern void lru_add_drain(void);
>  extern void lru_add_drain_cpu(int cpu);
>  extern int lru_add_drain_all(void);
> +extern int lru_add_drain_mapping(struct address_space *mapping);
>  extern void rotate_reclaimable_page(struct page *page);
>  extern void deactivate_page(struct page *page);
>  extern void swap_setup(void);
> Index: linux/mm/swap.c
> ===
> --- linux.orig/mm/swap.c
> +++ linux/mm/swap.c
> @@ -689,6 +689,68 @@ int lru_add_drain_all(void)
>  }
>  
>  /*
> + * Returns 0 for success
> + */
> +int lru_add_drain_mapping(struct address_space *mapping)
> +{
> + int cpu;
> + struct work_struct __percpu *works;
> +
> + works = alloc_percpu(struct work_struct);
> + if (!works)
> + return -ENOMEM;
> +
> + get_online_cpus();
> +
> + for_each_online_cpu(cpu) {
> + struct pagevec *pvecs = per_cpu(lru_add_pvecs, cpu);
> + struct work_struct *work = per_cpu_ptr(works, cpu);
> + struct pagevec *pvec;
> + int lru;
> +
> + INIT_WORK(work, lru_add_drain_per_cpu);
> + for_each_lru(lru) {
> + int i;
> +
> + pvec = &pvecs[lru - LRU_BASE];
> + /*
> +  * Race failure mode is to flush unnecessarily.
> +  * We use PAGEVEC_SIZE rather than pvec->nr to
> +  * stay on the safe-side wrt pvec resize.
> +  */
> + for (i = 0; i < PAGEVEC_SIZE; i++) {
> + struct page *page;
> +
> + /*
> +  * Racy access to page. TODO: is it OK
> +  * to access it from the remote CPU's
> +  * lru without any kind of ownership or
> +  * synchronization ?
> +  */

Almost.  The only problem I can think of is that the other CPU flushes
its pagevec then a page gets freed then a memory hot-unplug occurs and
the memory hotplug handler frees and then unmaps the memory which was
used to hold the page's `struct page' (I don't think the current
mem-hotplug code even does this) and now this cpu's page->mapping
access goes oops.  

IOW, not worth worrying for a prototype "hey lets test this and see if
it fixes things" patch.


> + page = ACCESS_ONCE(pvec->pages[i]);
> + if (!pvec->pages[i])
> + continue;
> + if (page->mapping == mapping) {
> + schedule_work_on(cpu, work);
> + goto next_cpu;
> + }
> + }
> + }
> + next_cpu: ; 

Re: [PATCH] usb: host: Faraday fotg210-hcd driver

[Yuan-Hsin Chen]

Hi,

On Tue, Jun 18, 2013 at 4:39 AM, Greg KH  wrote:
> On Wed, Jun 05, 2013 at 05:15:43PM +, Yuan-Hsin Chen wrote:
>> FOTG210 is an OTG controller which can be configured as an
>> USB2.0 host. FOTG210 host is an ehci-like controller with
>> some differences. First, register layout of FOTG210 is
>> incompatible with EHCI. Furthermore, FOTG210 is lack of
>> siTDs which means iTDs are used for both HS and FS ISO
>> transfer.
>>
>> Signed-off-by: Yuan-Hsin Chen 
>> ---
>>  drivers/usb/Makefile   |1 +
>>  drivers/usb/host/Kconfig   |   12 +
>>  drivers/usb/host/Makefile  |1 +
>>  drivers/usb/host/fotg210-hcd.c | 5967 
>> 
>>  drivers/usb/host/fotg210.h |  746 +
>>  5 files changed, 6727 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/usb/host/fotg210-hcd.c
>>  create mode 100644 drivers/usb/host/fotg210.h
>
> You obviously didn't even run this through checkpatch.pl, did you?
>
> $ ./scripts/checkpatch.pl --terse ../usb.mbox | tail -n 1
> total: 138 errors, 618 warnings, 6742 lines checked
>
> Please fix all of these if you wish us to at least start reviewing the
> patch.  Your internal Q/A should have caught this first, please be more
> careful in the future.
>

Actually I did run checkpatch.pl and found that almost all errors and
warnings are from ehci core (ehci-hcd.c, ehci-hub.c and so on) where
my driver borrowed most of code.

$ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hub.c | tail -n 1
total: 18 errors, 69 warnings, 1138 lines checked

$ ./scripts/checkpatch.pl --terse -f drivers/usb/host/ehci-hcd.c | tail -n 1
total: 17 errors, 78 warnings, 1403 lines checked

So you're saying that I should fix them, is that right?

thanks,

Yuan-Hsin

> thanks,
>
> greg k-h
--
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: power-efficient scheduling design

[David Lang]

On Fri, 14 Jun 2013, Morten Rasmussen wrote:


Looking at the discussion it seems that people have slightly different
views, but most agree that the goal is an integrated scheduling,
frequency, and idle policy like you pointed out from the beginning.

What is less clear is how such design would look like. Catalin has
suggested two different approaches. Integrating cpufreq into the load
balancing, or let the scheduler focus on load balancing and extend
cpufreq to also restrict number of cpus available to the scheduler using
cpu_power. The former approach would increase the scheduler complexity
significantly as I already highlighted in my first reply. The latter
approach introduces a way to, at lease initially, separate load
balancing from capacity management, which I think is an interesting
approach. Based on this idea I propose the following design:

+-+
| | +--+
current load| Power scheduler |<+ cpufreq  |
 +->| sched/power.c   +>| driver   |
 |  | | +--+
 |  +---+-+
 | ^|
   +-+-+   ||
   |   |   || available capacity
   | Scheduler |<--++ (e.g. cpu_power)
   | sched/fair.c  |   |
   |   +--+|
   +---+  ||
  ^   ||
  |   v|
+-++  +--+
| task load metric |  | cpuidle  |
| arch/*   |  | driver   |
+--+  +--+

The intention is that the power scheduler will implement the (unified)
power policy. It gets the current load of the system from the scheduler.
Based on this information it will adjust the compute capacity available
to the scheduler and drive frequency changes such that enough compute
capacity is available to handle the current load. If the total load can
be handled by a subset of cpus, it will reduce the capacity of the
excess cpus to 0 (cpu_power=1). Likewise, if the load increases it will
increase capacity of one or more idle cpus to allow the scheduler to
spread the load. The power scheduler has knowledge about the power
topology and will guide the scheduler to idle the most optimum cpus by
reducing its capacity. Global idle decision will be handled by the power
scheduler, so cpuidle can over time be reduced to become just a driver,
once we have added C-state selection to the power scheduler.

The scheduler is left to focus on scheduling mechanics and finding the
best possible load balance on the cpu capacities set by the power
scheduler. It will share a detailed view of the current load with the
power scheduler to enable it to make the right capacity adjustments. The
scheduler will need some optimization to cope better with asymmetric
compute capacities. We may want to reduce capacity of some cpu to
increase their idle time while letting others take the majority of the
load.

Frequency scaling has a problematic impact on PJT's load metic, which
was pointed out a while ago by Chris Redpath
.  So I agree with Arjan's
suggestion to change the load calculation basis to something which is
frequency invariant. Use whatever counters that are available on the
specific platform.

I'm aware that the scheduler and power scheduler decisions may be
inextricably linked so we may decide to merge them. However, I think it
is worth trying to keep the power scheduling decisions out of the
scheduler until we have proven it infeasible.

We are going to start working on this design and see where it takes us.
We will post any results and suggested patches for folk to comment on.
As a starting point we are planning to create a power scheduler
(kernel/sched/power.c) similar to a cpufreq governor that does capacity
management, and then evolve the solution from there.


I don't think that you are passing nearly enough information around.

A fairly simple example

take a relatively modern 4-core system with turbo mode where speed controls 
affect two cores at a time (I don't know the details of the available CPUs to 
know if this is an exact fit to any existing system, but I think it's a 
reasonable fit)


If you are running with a loadave of 2, should you power down 2 cores and run 
the other two in turbo mode, power down 2 cores and not increase the speed, or 
leave all 4 cores running as is.


Depending on the mix of processes, I could see any one of the three being the 
right answer.


If you have a process that's maxing out it's cpu time on one core, going to 
turbo mode is the right thing as the other processes should fit on the other 
core and that process will use more CPU (theoretically getting done sooner)


If no process is close to maxing out the core, then if you are in power saving 
mode, you probably want to shut down two cores and run everything on the 

Re: [PATCH 4/4 v2] silicom: checkpatch: errors caused by macros

[Joe Perches]

On Mon, 2013-06-17 at 14:14 -0700, Greg KH wrote:
> On Mon, Jun 17, 2013 at 02:03:43PM -0700, Joe Perches wrote:
> > Generally I think it's better that new submitters patches
> > should go through more strict reviews and be as correct
> > as possible.  I think this is especially true for patches
> > that are just checkpatch driven.
> 
> I totally disagree, sorry.

I'm unsurprised.  We have different tastes.

While whitespace only cleanup patches have some use,
for these types of patches, I'm more interested in
educating others what sorts of patches have higher
value.

o defects
o style/readability
o whitespace

As always, ymmv.

--
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/4] KVM: PPC: Add support for IOMMU in-kernel handling

[Alex Williamson]

On Mon, 2013-06-17 at 13:56 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2013-06-16 at 21:13 -0600, Alex Williamson wrote:
> 
> > IOMMU groups themselves don't provide security, they're accessed by
> > interfaces like VFIO, which provide the security.  Given a brief look, I
> > agree, this looks like a possible backdoor.  The typical VFIO way to
> > handle this would be to pass a VFIO file descriptor here to prove that
> > the process has access to the IOMMU group.  This is how /dev/vfio/vfio
> > gains the ability to setup an IOMMU domain an do mappings with the
> > SET_CONTAINER ioctl using a group fd.  Thanks,
> 
> How do you envision that in the kernel ? IE. I'm in KVM code, gets that
> vfio fd, what do I do with it ?
> 
> Basically, KVM needs to know that the user is allowed to use that iommu
> group. I don't think we want KVM however to call into VFIO directly
> right ?

Right, we don't want to create dependencies across modules.  I don't
have a vision for how this should work.  This is effectively a complete
side-band to vfio, so we're really just dealing in the iommu group
space.  Maybe there needs to be some kind of registration of ownership
for the group using some kind of token.  It would need to include some
kind of notification when that ownership ends.  That might also be a
convenient tag to toggle driver probing off for devices in the group.
Other ideas?  Thanks,

Alex

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