Re: [PATCH 39/48] powerpc: Replace __get_cpu_var uses

[Mike Galbraith]

On Fri, 2014-02-14 at 23:26 -0500, Steven Rostedt wrote: 
> On Sat, 15 Feb 2014 14:50:08 +1100
> Benjamin Herrenschmidt  wrote:
> 
> > For some reason Im still getting these as attachments instead of inline
> > in the email, which makes reviewing a major PITA. Christoph, I'm not
> > sure what you are doing wrong here but you should consider fixing it :-)
> 
> Get a better email client ;-)

Yeah, evolution shows them inline just fine (thought you made it do bad
things too, it couldn't save signed patches or such).

-Mike

--
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] [RFC] staging: rtl8821ae: fix invalid bit mask on MSR_AP check

[Levente Kurusa]

On 02/14/2014 11:00 PM, Dan Carpenter wrote:
> [...]
>>  Hi,
>>
>>  This might not be the real solution since it is also possible that
>>  the particular condition never really happens. I seek comments
>>  so that I can post the proper patch.
>>
> 
> I can't test it either but I think your fix is correct.
> 
> Reviewed-by: Dan Carpenter 
> [...]

Thanks Dan, maybe you know some people who could test it?
RTLXX guys? Or maybe we can take the patch as is?
I cannot really think of any other solution other than removing
the other clause, but since that was written to the file,
there must have been some logic behind that. I am slightly
disappointed get_maintainer didn't really find anybody for
this patch...

Greg, can you take it as is or you would need the RFC tag removed?
(ie, repost)
Maybe you know somebody who could test it as well?

-- 
Regards,
Levente Kurusa
--
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: [char-misc-next 3/4] mei: add mei_hbuf_acquire wrapper

[Winkler, Tomas]

> 
> This patch fails to apply:
>   checking file drivers/misc/mei/amthif.c
>   checking file drivers/misc/mei/client.c
>   Hunk #4 FAILED at 681.
>   Hunk #5 succeeded at 815 (offset -2 lines).
>   Hunk #6 succeeded at 848 (offset -2 lines).
>   1 out of 6 hunks FAILED
>   checking file drivers/misc/mei/hw-me.c
>   checking file drivers/misc/mei/hw-txe.c
>   checking file drivers/misc/mei/interrupt.c
>   checking file drivers/misc/mei/mei_dev.h
>   checking file drivers/misc/mei/wd.c

Did I missed something in the process? 
This patch series has dependency on path that was destined for stable 
https://lkml.org/lkml/2014/2/12/389
 as stated in 0/4 http://www.spinics.net/lists/kernel/msg1686728.html
Quoting:
"In order to avoid conflicts please apply after
mei: set client's read_cb to NULL when flow control fails
https://lkml.org/lkml/2014/2/12/389;


Thanks
Tomas

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

[PATCH 1/3] staging: r8712u: delete unnecessary field initialization

[Julia Lawall]

From: Julia Lawall 

On success, the function netdev_alloc_skb initializes the dev field of its
result to its first argument, so this doesn't have to be done in the
calling context.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression skb,privn,e;
@@

skb = netdev_alloc_skb(privn,...);
... when strict
(
-skb->dev = privn;
|
?skb = e
)
// 

Signed-off-by: Julia Lawall 

---
 drivers/staging/rtl8712/rtl8712_recv.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c 
b/drivers/staging/rtl8712/rtl8712_recv.c
index ea96537..0723b2f 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -90,7 +90,6 @@ int r8712_init_recv_priv(struct recv_priv *precvpriv, struct 
_adapter *padapter)
pskb = netdev_alloc_skb(padapter->pnetdev, MAX_RECVBUF_SZ +
   RECVBUFF_ALIGN_SZ);
if (pskb) {
-   pskb->dev = padapter->pnetdev;
tmpaddr = (addr_t)pskb->data;
alignment = tmpaddr & (RECVBUFF_ALIGN_SZ-1);
skb_reserve(pskb, (RECVBUFF_ALIGN_SZ - alignment));
@@ -1083,7 +1082,6 @@ static int recvbuf2recvframe(struct _adapter *padapter, 
struct sk_buff *pskb)
alloc_sz += 6;
pkt_copy = netdev_alloc_skb(padapter->pnetdev, alloc_sz);
if (pkt_copy) {
-   pkt_copy->dev = padapter->pnetdev;
precvframe->u.hdr.pkt = pkt_copy;
skb_reserve(pkt_copy, 4 - ((addr_t)(pkt_copy->data)
% 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 3/3] caif: delete unnecessary field initialization

[Julia Lawall]

From: Julia Lawall 

On success, the function netdev_alloc_skb initializes the dev field of its
result to its first argument, so this doesn't have to be done in the
calling context.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression skb,privn,e;
@@

skb = netdev_alloc_skb(privn,...);
... when strict
(
-skb->dev = privn;
|
?skb = e
)
// 

Signed-off-by: Julia Lawall 

---
 drivers/net/caif/caif_serial.c |1 -
 drivers/net/caif/caif_spi.c|1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
index 88a6a58..fc73865 100644
--- a/drivers/net/caif/caif_serial.c
+++ b/drivers/net/caif/caif_serial.c
@@ -204,7 +204,6 @@ static void ldisc_receive(struct tty_struct *tty, const u8 
*data,
 
skb->protocol = htons(ETH_P_CAIF);
skb_reset_mac_header(skb);
-   skb->dev = ser->dev;
debugfs_rx(ser, data, count);
/* Push received packet up the stack. */
ret = netif_rx_ni(skb);
diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
index 155db68..ff54c0e 100644
--- a/drivers/net/caif/caif_spi.c
+++ b/drivers/net/caif/caif_spi.c
@@ -554,7 +554,6 @@ int cfspi_rxfrm(struct cfspi *cfspi, u8 *buf, size_t len)
 
skb->protocol = htons(ETH_P_CAIF);
skb_reset_mac_header(skb);
-   skb->dev = cfspi->ndev;
 
/*
 * Push received packet up the stack.

--
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/3] staging: r8188eu: delete unnecessary field initialization

[Julia Lawall]

From: Julia Lawall 

On success, the function netdev_alloc_skb initializes the dev field of its
result to its first argument, so this doesn't have to be done in the
calling context.

The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression skb,privn,e;
@@

skb = netdev_alloc_skb(privn,...);
... when strict
(
-skb->dev = privn;
|
?skb = e
)
// 

Signed-off-by: Julia Lawall 

---
 drivers/staging/rtl8188eu/hal/usb_ops_linux.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/usb_ops_linux.c 
b/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
index 74ee2e6..b92b4f5 100644
--- a/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/hal/usb_ops_linux.c
@@ -384,7 +384,6 @@ static int recvbuf2recvframe(struct adapter *adapt, struct 
sk_buff *pskb)
 
pkt_copy = netdev_alloc_skb(adapt->pnetdev, alloc_sz);
if (pkt_copy) {
-   pkt_copy->dev = adapt->pnetdev;
precvframe->u.hdr.pkt = pkt_copy;
precvframe->u.hdr.rx_head = pkt_copy->data;
precvframe->u.hdr.rx_end = pkt_copy->data + alloc_sz;

--
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] rcu: move SRCU grace period work to power efficient workqueue

[Mike Galbraith]

On Fri, 2014-02-14 at 15:24 -0800, Kevin Hilman wrote: 
> Tejun Heo  writes:
> 
> > Hello,
> >
> > On Wed, Feb 12, 2014 at 11:02:41AM -0800, Paul E. McKenney wrote:
> >> +2.Use the /sys/devices/virtual/workqueue/*/cpumask sysfs files
> >> +  to force the WQ_SYSFS workqueues to run on the specified set
> >> +  of CPUs.  The set of WQ_SYSFS workqueues can be displayed using
> >> +  "ls sys/devices/virtual/workqueue".
> >
> > One thing to be careful about is that once published, it becomes part
> > of userland visible interface.  Maybe adding some words warning
> > against sprinkling WQ_SYSFS willy-nilly is a good idea?
> 
> In the NO_HZ_FULL case, it seems to me we'd always want all unbound
> workqueues to have their affinity set to the housekeeping CPUs.
> 
> Is there any reason not to enable WQ_SYSFS whenever WQ_UNBOUND is set so
> the affinity can be controlled?  I guess the main reason would be that 
> all of these workqueue names would become permanent ABI.
> 
> At least for NO_HZ_FULL, maybe this should be automatic.  The cpumask of
> unbound workqueues should default to !tick_nohz_full_mask?  Any WQ_SYSFS
> workqueues could still be overridden from userspace, but at least the
> default would be sane, and help keep full dyntics CPUs isolated.

What I'm thinking is that it should be automatic, but not necessarily
based upon the nohz full mask, rather maybe based upon whether sched
domains exist, or perhaps a generic exclusive cpuset property, though
some really don't want anything to do with cpusets.

Why? Because there are jitter intolerant loads where nohz full isn't all
that useful, because you'll be constantly restarting and stopping the
tick, and eating the increased accounting overhead to no gain because
there are frequently multiple realtime tasks running.  For these loads
(I have a user with such a fairly hefty 80 core rt load), dynamically
turning the tick _on_ is currently a better choice than nohz_full.
Point being, control of where unbound workqueues are allowed to run
isn't only desirable for single task HPC loads, other loads exist.

For my particular fairly critical 80 core load, workqueues aren't a real
big hairy deal, because its jitter tolerance isn't _all_ that tight (30
us max is easy enough to meet with room to spare).  The load can slice
through workers well enough to meet requirements, but it would certainly
be a win to be able to keep them at bay.  (gonna measure it, less jitter
is better even if it's only a little bit better.. eventually somebody
will demand what's currently impossible to deliver)

-Mike

--
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 0/5] arch: atomic rework

[Paul E. McKenney]

On Fri, Feb 14, 2014 at 10:35:44PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 14, 2014 at 06:48:02PM -0800, Linus Torvalds wrote:
> > On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds
> >  wrote:
> > >
> > > And conversely, the C11 people can walk away from us too. But if they
> > > can't make us happy (and by "make us happy", I really mean no stupid
> > > games on our part) I personally think they'll have a stronger
> > > standard, and a real use case, and real arguments. I'm assuming they
> > > want that.
> > 
> > I should have somebody who proof-reads my emails before I send them out.
> > 
> > I obviously meant "if they *can* make us happy" (not "can't").
> 
> Understood.  My next step is to take a more detailed look at the piece
> of the standard that should support RCU.  Depending on how that turns
> out, I might look at other parts of the standard vs. Linux's atomics
> and memory-ordering needs.  Should be interesting.  ;-)

And perhaps a better way to represent the roles is that I am not the
buyer, but rather the purchasing agent for the -potential- buyer.  -You-
are of course the potential buyer.

If I were to see myself as the buyer, then I must confess that the
concerns you implicitly expressed in your prior email would be all too
well-founded!

Thanx, Paul

--
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: KSM on Android

[Pradeep Sawlani]

> Re-sending this in plain text format (Apologies)
>
> Hello,
>
> In pursuit of saving memory on Android, I started experimenting with
> Kernel Same Page Merging(KSM).
> Number of pages shared because of KSM is reported by
> /sys/kernel/mm/pages_sharing.
> Documentation/vm/ksm.txt explains this as:
>
> "pages_sharing- how many more sites are sharing them i.e. how much saved"
>
> After enabling KSM on Android device, this number was reported as 19666 pages.
> Obvious optimization is to find out source of sharing and see if we
> can avoid duplicate pages at first place.
> In order to collect the data needed, It needed few
> modifications(trace_printk) statement in mm/ksm.c.
> Data should be collected from second cycle because that's when ksm
> starts merging
> pages. First KSM cycle is only used to calculate the checksum, pages
> are added to
> unstable tree and eventually moved to stable tree after this.
>
> After analyzing data from second KSM cycle, few things which stood out:
> 1.  In the same cycle, KSM can scan same page multiple times. Scanning
> a page involves
> comparing page with pages in stable tree, if no match is found
> checksum is calculated.
> From the look of it, it seems to be cpu intensive operation and
> impacts dcache as well.
>
> 2.  Same page which is already shared by multiple process can be
> replaced by KSM page.
> In this case, let say a particular page is mapped 24 times and is
> replaced by KSM page then
> eventually all 24 entries will point to KSM page. pages_sharing
> will account for all 24 pages.
> so pages _sharing does not actually report amount of memory saved.
> From the above example actual
> savings is one page.
>
> Both cases happen very often with Android because of its architecture
> - Zygote spawning(fork) multiple
> applications. To calculate actual savings, we should account for same
> page(pfn)replaced by same KSM page only once.
> In the case 2 example, page_sharing should account only one page.
> After recalculating memory saving comes out to be 8602 pages (~34MB).
>
> I am trying to find out right solution to fix pages_sharing and
> eventually optimize KSM to scan page
> once even if it is mapped multiple times.
>
> Comments?
>
Correct Izik's email address.

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: [RFC][PATCH 0/5] arch: atomic rework

[Paul E. McKenney]

On Fri, Feb 14, 2014 at 06:48:02PM -0800, Linus Torvalds wrote:
> On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds
>  wrote:
> >
> > And conversely, the C11 people can walk away from us too. But if they
> > can't make us happy (and by "make us happy", I really mean no stupid
> > games on our part) I personally think they'll have a stronger
> > standard, and a real use case, and real arguments. I'm assuming they
> > want that.
> 
> I should have somebody who proof-reads my emails before I send them out.
> 
> I obviously meant "if they *can* make us happy" (not "can't").

Understood.  My next step is to take a more detailed look at the piece
of the standard that should support RCU.  Depending on how that turns
out, I might look at other parts of the standard vs. Linux's atomics
and memory-ordering needs.  Should be interesting.  ;-)

Thanx, Paul

--
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: [CRIU] [PATCH 1/3] prctl: reduce permissions to change boundaries of data, brk and stack

[Cyrill Gorcunov]

On Fri, Feb 14, 2014 at 12:18:46PM -0800, Eric W. Biederman wrote:
> >> > 
> >> > Why can't you have the process of interest do:
> >> >  ptrace(PTRACE_ATTACHME);
> >> >  execve(executable, args, ...);
> >> > 
> >> > /* Have the ptracer inject the recovery/fixup code */
> >> >  /* Fix up the mostly correct process to look like it has been
> >> >  * executing for a while.
> >> >  */
> >
> > Erik, it seems I don't understand how it will help us to restore
> > the mm fields mentioned above?
> 
> Because exec is how those mm fields are set when you don't use
> prctl_set_mm.  So execpt for the stack and the brk limits that
> will simply result in the values being set to what the usually
> would be set to.

Yes, all these fields are set up by kernel's elf loader but this
routine is a way more time consuming than a clone call. But gimme
some time to examine all possible problems we might have with such
approach and if there a way to solve them.

> >> Let's imagine we do that.
> >> 
> >> This means, that the whole memory contents should be restored _after_
> >> the execve() call, since the execve() flushes old mappings. In
> >> that case we lose the ability to preserve any shared memory regions
> >> between any two processes. This "shared" can be either regular
> >> MAP_SHARED mappings or MAP_ANONYMOUS but still not COW-ed ones.
--
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] spi: core: Validate lenght of the transfers in message

[Ivan T. Ivanov]

From: "Ivan T. Ivanov" 

SPI transfer lenght should be a power-of-two multiple
of eight bits.

Signed-off-by: Ivan T. Ivanov 
---
 drivers/spi/spi.c |   17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index d0b28bb..9bed365 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1617,6 +1617,7 @@ static int __spi_validate(struct spi_device *spi, struct 
spi_message *message)
 {
struct spi_master *master = spi->master;
struct spi_transfer *xfer;
+   int w_size, n_words;
 
if (list_empty(>transfers))
return -EINVAL;
@@ -1668,6 +1669,22 @@ static int __spi_validate(struct spi_device *spi, struct 
spi_message *message)
return -EINVAL;
}
 
+   /*
+* SPI transfer length should be multiple of SPI word size
+* where SPI word size should be power-of-two multiple
+*/
+   if (xfer->bits_per_word <= 8)
+   w_size = 1;
+   else if (xfer->bits_per_word <= 16)
+   w_size = 2;
+   else
+   w_size = 4;
+
+   n_words = xfer->len / w_size;
+   /* No partial transfers accepted */
+   if (!n_words || xfer->len % xfer->bits_per_word)
+   return -EINVAL;
+
if (xfer->speed_hz && master->min_speed_hz &&
xfer->speed_hz < master->min_speed_hz)
return -EINVAL;
-- 
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] ACPI, APEI: Remove X86 redundant dependency for APEI Generic Hardware Error Source.

[Borislav Petkov]

On Sat, Feb 15, 2014 at 01:57:48AM +0100, Rafael J. Wysocki wrote:
> On Monday, February 10, 2014 05:23:36 PM Tomasz Nowicki wrote:
> > ACPI_APEI is already dependent on X86, hence, there is no need to
> > define such dependency for ACPI_APEI_GHES again.
> > 
> > Signed-off-by: Tomasz Nowicki 
> 
> Tony, Boris, if you're fine with this, I'll take it for 3.15.

Acked-by: Borislav Petkov 

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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: 3.14-rc2 XFS backtrace because irqs_disabled.

[Al Viro]

On Thu, Feb 13, 2014 at 09:58:47AM -0800, Linus Torvalds wrote:
> On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov  wrote:
> >
> > And we should be careful with SIGQUEUE_PREALLOC, at least
> > collect_signal() should not do list_del_init()... Plus we need to
> > handle the SEND_SIG_FORCED-like case.
> 
> I don't think the users need to care. They'd just call
> "sigqueue_free()" not knowing about our preallocations etc. That kind
> of detail should be confined to inside signal.c.
> 
> But there really aren't that many users. There's a couple of
> "dequeue_signal_lock()" users, but they don't actually *want* the
> siginfo at all (they're kernel threads), so we can just make that
> function free the siginfo immediately (and get rid of the totally
> unnecessay kernel stack allocation). And outside of signal.c only
> signalfd uses "dequeue_signal()" itself, and that would be the only
> one that would need to be taught to use (in signalfd_copyinfo()) and
> then free the sigqueue entry.
> 
> So it really looks like the right thing to do, and fairly
> straightforward. But I'm leaving the coding proof to Al, since he
> already offered ;)

OK, _very_ preliminary patch follows.  It's uglier than it has to and it's
not in the form I would consider suitable for merge.  It doesn't depend
on conversions of architectures to use of ksignal as prereqs; instead of
that it has config symbol (ARCH_USES_KSIGNAL) that can be selected on
architectures already through that conversion (in this patch - just on
x86, since that was all I could test on at the moment; e.g. alpha and
arm could also get such selects right now).  If it isn't selected, everything
builds as usual.  With large siginfo on stack for signal path, as before.
We get ksiginfo_t as an alias for siginfo_t in that case, dismiss_siginfo()
is a no-op, etc.  If it _is_ selected, ksiginfo_t is much smaller than
siginfo_t.

Of course, we pay for that with ifdefs in places that need to understand
[k]siginfo_t guts; signalfd_copyinfo(), copy_siginfo_from_user{,32}() and
copy_ksiginfo_to_user{,32}(), tracepoint for deliver_signal(), collect_signal(),
trivial ones in dequeue_signal() and an ugly bugger in ptrace_signal().
No way around that until all architectures are converted.  Other places
get away with some siginfo_t replaced with ksiginfo_t and dismiss_siginfo()
added in some places.  arch/x86/ia32/ia32_signal.c needed a bit of change
(we probably ought to unify copy_siginfo_from_user32() on all architectures
that have it, actually).

The sucker survived LTP syscall tests and hasn't died on xfstests yet either
(== doesn't seem to leak horribly).  Consider it a proof-of-concept and no
more than that.  One thing I'm really not satisfied with is signal sending
pathway - it would probably make a lot of sense to use ksiginfo there as
well, and have insertion into queue simply steal info->q instead of allocating
and copying.  Another is that ifdefs like that are tolerable only if we
plan to convert everything during this cycle; I believe it to be doable,
actually.  Having that sucker go before the conversions would make for
simpler logistics wrt architecture trees, but it may be better to get
all conversions merged first.  Not sure...  Anyway, here is it; comments
are welcome.

Signed-off-by: Al Viro 
---
diff --git a/arch/Kconfig b/arch/Kconfig
index 80bbb8c..f753561 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -522,4 +522,7 @@ config OLD_SIGACTION
 config COMPAT_OLD_SIGACTION
bool
 
+config ARCH_USES_KSIGNAL
+   bool
+
 source "kernel/gcov/Kconfig"
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0af5250..4ec468d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -127,6 +127,7 @@ config X86
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
select HAVE_CC_STACKPROTECTOR
+   select ARCH_USES_KSIGNAL
 
 config INSTRUCTION_DECODER
def_bool y
diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
index 2206757..611a03e 100644
--- a/arch/x86/ia32/ia32_signal.c
+++ b/arch/x86/ia32/ia32_signal.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 
-int copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t *from)
+int __copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t 
*from)
 {
int err = 0;
bool ia32 = test_thread_flag(TIF_IA32);
@@ -105,6 +105,25 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, 
const siginfo_t *from)
return err;
 }
 
+int copy_siginfo_to_user32(compat_siginfo_t __user *to, const ksiginfo_t *from)
+{
+   int err = 0;
+   if (!from->q) {
+   if (!access_ok(VERIFY_WRITE, to, sizeof(compat_siginfo_t)))
+   return -EFAULT;
+   put_user_try {
+   /* fast case */
+   put_user_ex(from->si_signo, >si_signo);
+   put_user_ex(0, >si_errno);
+   put_user_ex((short)from->si_code, >si_code);
+ 

[PATCH] workqueue: Remove unused __cancel_delayed_work

[Tan Xiaojun]

We use safer cancel_delayed_work() instead of __cancel_delayed_work,
and no one will use __cancel_delayed_work. So remove it.

Signed-off-by: Tan Xiaojun 
---
 include/linux/workqueue.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 594521b..edc9410 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -605,21 +605,6 @@ static inline bool keventd_up(void)
return system_wq != NULL;
 }
 
-/*
- * Like above, but uses del_timer() instead of del_timer_sync(). This means,
- * if it returns 0 the timer function may be running and the queueing is in
- * progress.
- */
-static inline bool __deprecated __cancel_delayed_work(struct delayed_work 
*work)
-{
-   bool ret;
-
-   ret = del_timer(>timer);
-   if (ret)
-   work_clear_pending(>work);
-   return ret;
-}
-
 /* used to be different but now identical to flush_work(), deprecated */
 static inline bool __deprecated flush_work_sync(struct work_struct *work)
 {
-- 
1.8.0


--
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 kernel 3.13.3 is added into www.xrefs.info

[John Smith]

hi, Linux kernel 3.13.3 is added into http://www.xrefs.info.
For the people don't know, http://www.xrefs.info covers many open
source projects source coe cross reference search based on OpenGrok.
Check it, and hope it helps. Feel free to leave a comment. Thx.
xrefs.info admin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sched/deadline: Fix bad accounting of nr_running

[Steven Rostedt]

My test suite was locking up hard when enabling mmiotracer. This was due
to the mmiotracer placing all but one CPU offline. I found this out
when I was able to reproduce the bug with just my stress-cpu-hotplug
test. This bug baffled me because it would not always trigger, and
would only trigger on the first run after boot up. The
stress-cpu-hotplug test would crash hard the first run, or never crash
at all. But a new reboot may cause it to crash on the first run again.

I spent all week bisecting this, as I couldn't find a consistent
reproducer. I finally narrowed it down to the sched deadline patches,
and even more peculiar, to the commit that added the sched
deadline boot up self test to the latency tracer. Then it dawned on me
to what the bug was.

All it took was to run a task under sched deadline to screw up the CPU
hot plugging. This explained why it would lock up only on the first run
of the stress-cpu-hotplug test. The bug happened when the boot up self
test of the schedule latency tracer would test a deadline task. The
deadline task would corrupt something that would cause CPU hotplug to
fail. If it didn't corrupt it, the stress test would always work
(there's no other sched deadline tasks that would run to cause
problems). If it did corrupt on boot up, the first test would lockup
hard.

I proved this theory by running my deadline test program on another box,
and then run the stress-cpu-hotplug test, and it would now consistently
lock up. I could run stress-cpu-hotplug over and over with no problem,
but once I ran the deadline test, the next run of the
stress-cpu-hotplug would lock hard.

After adding lots of tracing to the code, I found the cause. The
function tracer showed that migrate_tasks() was stuck in an infinite
loop, where rq->nr_running never equaled 1 to break out of it. When I
added a trace_printk() to see what that number was, it was 335 and
never decrementing!

Looking at the deadline code I found:

static void __dequeue_task_dl(struct rq *rq, struct task_struct *p, int
flags) {
dequeue_dl_entity(>dl);
dequeue_pushable_dl_task(rq, p);
}

static void dequeue_task_dl(struct rq *rq, struct task_struct *p, int
flags) {
update_curr_dl(rq);
__dequeue_task_dl(rq, p, flags);

dec_nr_running(rq);
}

And this:

if (dl_runtime_exceeded(rq, dl_se)) {
__dequeue_task_dl(rq, curr, 0);
if (likely(start_dl_timer(dl_se, curr->dl.dl_boosted)))
dl_se->dl_throttled = 1;
else
enqueue_task_dl(rq, curr, ENQUEUE_REPLENISH);

if (!is_leftmost(curr, >dl))
resched_task(curr);
}

Notice how we call __dequeue_task_dl() and in the else case we
call enqueue_task_dl()? Also notice that dequeue_task_dl() has
underscores where enqueue_task_dl() does not. The enqueue_task_dl()
calls inc_nr_running(rq), but __dequeue_task_dl() does not. This is
where we get nr_running out of sync.

By moving the dec_nr_running() from dequeue_task_dl() to
__dequeue_task_dl(), everything works again. That is, I can run the
deadline test program and then run the stress-cpu-hotplug() and all
would be fine.

For reference on my test programs:

  http://rostedt.homelinux.com/private/stress-cpu-hotplug
  http://rostedt.homelinux.com/private/deadline.c

Signed-off-by: Steven Rostedt 

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 0dd5e09..84c2454 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -844,14 +844,14 @@ static void __dequeue_task_dl(struct rq *rq,
struct task_struct *p, int flags) {
dequeue_dl_entity(>dl);
dequeue_pushable_dl_task(rq, p);
+
+   dec_nr_running(rq);
 }
 
 static void dequeue_task_dl(struct rq *rq, struct task_struct *p, int
flags) {
update_curr_dl(rq);
__dequeue_task_dl(rq, p, flags);
-
-   dec_nr_running(rq);
 }
 
 /*
--
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 39/48] powerpc: Replace __get_cpu_var uses

[Steven Rostedt]

On Sat, 15 Feb 2014 14:50:08 +1100
Benjamin Herrenschmidt  wrote:

> For some reason Im still getting these as attachments instead of inline
> in the email, which makes reviewing a major PITA. Christoph, I'm not
> sure what you are doing wrong here but you should consider fixing it :-)

Get a better email client ;-)

They show up fine for me. Looking at the raw format, could it possibly
be the DKIM-Signature? Here's (most of) the header:

Return-Path: c...@linux.com
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on goliath
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
LOCAL_SUBJECT_PATCH,RCVD_IN_DNSWL_NONE autolearn=unavailable 
version=3.3.2
Delivered-To: rost...@goodmis.org
X-FDA: 68539149672.07.nose31_2242917219f26
X-HE-Tag: nose31_2242917219f26
X-Filterd-Recvd-Size: 34239
Received: from mail.hover.com.cust.hostedemail.com [216.40.42.134]
by goliath with IMAP (fetchmail-6.3.26)
for  (single-drop); Fri, 14 Feb 2014 15:23:03 -0500 
(EST)
Received: from qmta09.emeryville.ca.mail.comcast.net 
(qmta09.emeryville.ca.mail.comcast.net [76.96.30.96])
by imf20.hostedemail.com (Postfix) with ESMTP
for ; Fri, 14 Feb 2014 20:20:35 + (UTC)
Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71])
by qmta09.emeryville.ca.mail.comcast.net with comcast
id SKft1n0011Y3wxoA9LLbGd; Fri, 14 Feb 2014 20:20:35 +
Received: from gentwo.org ([98.213.233.247])
by omta15.emeryville.ca.mail.comcast.net with comcast
id SLLY1n0095Lw0ES8bLLZFV; Fri, 14 Feb 2014 20:20:34 +
Received: by gentwo.org (Postfix, from userid 1001)
id 2941A68181; Fri, 14 Feb 2014 14:19:08 -0600 (CST)
Message-Id: <20140214201908.082769...@linux.com>
Date: Fri, 14 Feb 2014 14:19:20 -0600
From: Christoph Lameter 
To: Tejun Heo 
Cc: a...@linuxfoundation.org,
 rost...@goodmis.org,
 linux-kernel@vger.kernel.org,
 Ingo Molnar ,
 Peter Zijlstra ,
 Thomas Gleixner ,
 Benjamin Herrenschmidt ,
 Paul Mackerras 
Subject: [PATCH 39/48] powerpc: Replace __get_cpu_var uses
References: <20140214201841.826179...@linux.com>
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline; filename=this_powerpc
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
s=q20121106; t=1392409235;
bh=3eMNjwtVIqOOdbqtLUxQGKw+WvtREJiNlp1vuKEVub8=;
h=Received:Received:Received:Message-Id:Date:From:To:Subject:
 Content-Type;
b=AtOZLlCPJL9tvUnoSyw0qPmNQym1dGDConwMdjEnayz2rNubuobF/JYdewBUypgbZ
 3sq/JQoBriYX8NsMHQhzZL4bh+7gM6OPWhGSIczq6MNuzFvw7E9MVTeX+t+yhVXMNG
 O+sWkLbWkM18luLRPlJU7wD6ANEFrGgQvt7i1GqSrCVZ+qKgXq9brzu9NTsMp4ODzv
 Djs9LTZEBTjbYxllW+16x+lV/Y6zY9LYQzsB6VEEpjO2J5Z6Wbk12K4puGL0rPPKoW
 rpxrQjP44g+Tgr5iguuBUQAqIuzcgbDu3MtOwz+HllZuKiye+qQB+Eq/U5+CqtaIxl
 FN9CB0XgHTDJA==


-- Steve
--
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 0/6] mailbox: add common framework and port drivers

[Jassi Brar]

On 15 February 2014 09:41, Greg Kroah-Hartman
 wrote:
> On Sat, Feb 15, 2014 at 09:27:48AM +0530, Jassi Brar wrote:
>> On 15 February 2014 09:10, Greg Kroah-Hartman
>>  wrote:
>> > On Sat, Feb 15, 2014 at 09:02:07AM +0530, Jassi Brar wrote:
>> >> Hi,
>> >>
>> >> On 8 February 2014 06:20, Courtney Cavin  
>> >> wrote:
>> >> > There is currently no common framework for mailbox drivers, so this is 
>> >> > my
>> >> > attempt to come up with something suitable.  There seems to be a need 
>> >> > for
>> >> > making this generic, so I have attempted to do just that.  Most of this 
>> >> > is
>> >> > modeled pretty strongly after the pwm core, with some influences from 
>> >> > the clock
>> >> > core.
>> >> >
>> >> > Looking at the existing use-cases, and some new ones, it would appear 
>> >> > that the
>> >> > requirements here are rather simple. We need essentially two things for
>> >> > consumers:
>> >> > - put_message
>> >> > - callback for receiving messages
>> >> >
>> >> > The code currently uses atomic notifiers for callbacks.  The common 
>> >> > omap core
>> >> > deals with fifos and work-queues in order to escape atomic contexts, 
>> >> > but from
>> >> > what I can see, this is unneeded.  I am also of the opinion that the 
>> >> > contexts
>> >> > can be much better managed in the drivers which are working with these
>> >> > contexts, rather than generically.
>> >> >
>> >> > Hopefully this will be suitable for the plethora of other drivers 
>> >> > around the
>> >> > kernel which implement mailboxes, as well.  In any case, I'm rather 
>> >> > interested
>> >> > to see what the rest of the world thinks.
>> >> >
>> >> > Keep in mind that while the pl320 & omap code should compile, I don't 
>> >> > currently
>> >> > have a platform on which I can perform proper testing.  I also removed 
>> >> > the
>> >> > context save/restore code from omap2 mailbox support, because I think 
>> >> > it should
>> >> > be able to be done via driver suspend/resume, but haven't done a full
>> >> > investigation just yet.
>> >> >
>> >> > I'm also aware that breaking omap, just to fix it again probably isn't 
>> >> > the best
>> >> > course of action, and I'm open to suggestions.
>> >> >
>> >> Did you try to look up the history of mailbox api development?  Google
>> >> search: 'mailbox common api'
>> >>
>> >> I (Linaro/Fujitsu), Suman Anna (TI), LeyFoon Tan (Intel), Craig
>> >> McGeachie(Broadcom) and Loic Pallardy(ST) already worked a generic
>> >> Mailbox framework and infact have controller drivers working over
>> >> them.
>> >>  For some confidentiality and some lazy and some confusion or whatever
>> >> reasons the final version of drivers and API wasn't submitted upstream
>> >> yet.
>> >
>> > Then, in all reality, it doesn't exist at all, and so, we will evaluate
>> > this submission instead.
>> >
>> > Just because you all can't send something for merging, doesn't mean you
>> > get to block someone else who has got their act together, that's not
>> > fair.
>> >
>> Yup probably not much fair. But then also one usually look for any
>> early development efforts. IIRC only I and Anna started. Others later
>> joined us looking at archives. Not to vindicate our gang though.
>>
>>  Now we could either punish us and have this api tread the same
>> development path where everyone had their requirements (and the
>> only-waiting-for-approval controller drivers to convert)  OR we
>> could see if our/original/old API just works for the purposes of Sony
>> as well (which it will most probably) and then we could upstream it
>> with one more 'works-for-me-too'.
>
> What is stopping you submitting your patches right now?
>
Nothing. I'll freshen it up and submit today.

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 v1 0/2] exynos_mct driver: fix irq allocation and cleanup

[Tarek Dakhran]

On Thu, Feb 13, 2014 at 10:31 PM, Tarek Dakhran  wrote:
> Hi Tomasz,
>
> On Thursday, February 13, 2014, Tomasz Figa  wrote:
>>
>> Hi Tarek,
>>
>> On 13.02.2014 04:08, Tarek Dakhran wrote:
>>>
>>> exynos4_local_timer_setup called on the secondary cpu before
>>> irqs are enabled. request_irq can sleep, which produces next warning:
>>>
>>> on boot:
>>> [0.37] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
>>> [0.37] Setting up static identity map for 0x403b5700 - 0x403b5758
>>> [0.395000] CPU1: Booted secondary processor
>>> [0.395000] [ cut here ]
>>> [0.395000] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2742
>>> lockdep_trace_alloc+0xe0/0xfc()
>>> [0.395000] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
>>> [0.395000] Modules linked in:
>>> [0.395000] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
>>> 3.14.0-rc2-4-g0db95f4 #128
>>> [0.395000] [] (unwind_backtrace) from []
>>> (show_stack+0x10/0x14)
>>> [0.395000] [] (show_stack) from []
>>> (dump_stack+0x6c/0xb8)
>>> [0.395000] [] (dump_stack) from []
>>> (warn_slowpath_common+0x68/0x8c)
>>> [0.395000] [] (warn_slowpath_common) from []
>>> (warn_slowpath_fmt+0x30/0x40)
>>> [0.395000] [] (warn_slowpath_fmt) from []
>>> (lockdep_trace_alloc+0xe0/0xfc)
>>> [0.395000] [] (lockdep_trace_alloc) from []
>>> (kmem_cache_alloc+0x24/0x160)
>>> [0.395000] [] (kmem_cache_alloc) from []
>>> (request_threaded_irq+0x64/0x130)
>>> [0.395000] [] (request_threaded_irq) from []
>>> (exynos4_local_timer_setup+0xd0/0x124)
>>> [0.395000] [] (exynos4_local_timer_setup) from []
>>> (exynos4_mct_cpu_notify+0x78/0xf0)
>>> [0.395000] [] (exynos4_mct_cpu_notify) from []
>>> (notifier_call_chain+0x44/0x84)
>>> [0.395000] [] (notifier_call_chain) from []
>>> (__cpu_notify+0x24/0x40)
>>> [0.395000] [] (__cpu_notify) from []
>>> (secondary_start_kernel+0xe4/0x134)
>>> [0.395000] [] (secondary_start_kernel) from [<40008624>]
>>> (0x40008624)
>>> [0.395000] ---[ end trace 347890460e745f50 ]---
>>> [0.42] CPU1: update cpu_power 1024
>>> [0.42] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
>>>
>>> on hotplug:
>>> [  108.04] CPU3: Booted secondary processor
>>> [  108.04] BUG: sleeping function called from invalid context at
>>> mm/slub.c:965
>>> [  108.04] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name:
>>> swapper/3
>>> [  108.04] INFO: lockdep is turned off.
>>> [  108.04] irq event stamp: 0
>>> [  108.04] hardirqs last  enabled at (0): [<  (null)>]   (null)
>>> [  108.04] hardirqs last disabled at (0): []
>>> copy_process.part.2+0x2a4/0x12f4
>>> [  108.04] softirqs last  enabled at (0): []
>>> copy_process.part.2+0x2a4/0x12f4
>>> [  108.04] softirqs last disabled at (0): [<  (null)>]   (null)
>>> [  108.04] CPU: 3 PID: 0 Comm: swapper/3 Tainted: GW
>>> 3.14.0-rc2-4-g0db95f4 #128
>>> [  108.04] [] (unwind_backtrace) from []
>>> (show_stack+0x10/0x14)
>>> [  108.04] [] (show_stack) from []
>>> (dump_stack+0x6c/0xb8)
>>> [  108.04] [] (dump_stack) from []
>>> (kmem_cache_alloc+0xd4/0x160)
>>> [  108.04] [] (kmem_cache_alloc) from []
>>> (request_threaded_irq+0x64/0x130)
>>> [  108.04] [] (request_threaded_irq) from []
>>> (exynos4_local_timer_setup+0xd0/0x124)
>>> [  108.04] [] (exynos4_local_timer_setup) from []
>>> (exynos4_mct_cpu_notify+0x78/0xf0)
>>> [  108.04] [] (exynos4_mct_cpu_notify) from []
>>> (notifier_call_chain+0x44/0x84)
>>> [  108.04] [] (notifier_call_chain) from []
>>> (__cpu_notify+0x24/0x40)
>>> [  108.04] [] (__cpu_notify) from []
>>> (secondary_start_kernel+0xe4/0x134)
>>> [  108.04] [] (secondary_start_kernel) from [<40008624>]
>>> (0x40008624)
>>>
>>> First patch fixes this problem by removing request_irq from
>>> exynos4_local_timer_setup
>>> Second removes non-dt stuff.
>>>
>>> Tested on linux kernel v3.14-rc2.
>>
>>
>> It would be nice to say on which boards it has been tested. Let me check
>> this on our boards anyway.
>>
>> Best regards,
>> Tomasz
>
>
> Tested on smdk5410 reference board with lockdep enabled.
> I think the problem will present on all boards due to call sleeping function
> in irq_disabled context.
>
> Best Regards,
> Tarek
>
Has anyone else tested this patches?
if yes, what is the result?


Best regards,
. Tarek
--
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] backing_dev: Fix hung task on sync

[Derek Basehore]

bdi_wakeup_thread_delayed used the mod_delayed_work function to schedule work
to writeback dirty inodes. The problem with this is that it can delay work that
is scheduled for immediate execution, such as the work from sync_inodes_sb.
This can happen since mod_delayed_work can now steal work from a work_queue.
This fixes the problem by using queue_delayed_work instead. This is a
regression from the move to the bdi workqueue design.

The reason that this causes a problem is that laptop-mode will change the
delay, dirty_writeback_centisecs, to 6 (10 minutes) by default. In the case
that bdi_wakeup_thread_delayed races with sync_inodes_sb, sync will be stopped
for 10 minutes and trigger a hung task. Even if dirty_writeback_centisecs is
not long enough to cause a hung task, we still don't want to delay sync for
that long.

For the same reason, this also changes bdi_writeback_workfn to immediately
queue the work again in the case that the work_list is not empty. The same
problem can happen if the sync work is run on the rescue worker.

Signed-off-by: Derek Basehore 
---
 fs/fs-writeback.c | 5 +++--
 mm/backing-dev.c  | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index e0259a1..95b7b8c 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1047,8 +1047,9 @@ void bdi_writeback_workfn(struct work_struct *work)
trace_writeback_pages_written(pages_written);
}
 
-   if (!list_empty(>work_list) ||
-   (wb_has_dirty_io(wb) && dirty_writeback_interval))
+   if (!list_empty(>work_list))
+   mod_delayed_work(bdi_wq, >dwork, 0);
+   else if (wb_has_dirty_io(wb) && dirty_writeback_interval)
queue_delayed_work(bdi_wq, >dwork,
msecs_to_jiffies(dirty_writeback_interval * 10));
 
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index ce682f7..3fde024 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -294,7 +294,7 @@ void bdi_wakeup_thread_delayed(struct backing_dev_info *bdi)
unsigned long timeout;
 
timeout = msecs_to_jiffies(dirty_writeback_interval * 10);
-   mod_delayed_work(bdi_wq, >wb.dwork, timeout);
+   queue_delayed_work(bdi_wq, >wb.dwork, timeout);
 }
 
 /*
-- 
1.9.0.rc1.175.g0b1dcb5

--
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 0/6] mailbox: add common framework and port drivers

[Greg Kroah-Hartman]

On Sat, Feb 15, 2014 at 09:27:48AM +0530, Jassi Brar wrote:
> On 15 February 2014 09:10, Greg Kroah-Hartman
>  wrote:
> > On Sat, Feb 15, 2014 at 09:02:07AM +0530, Jassi Brar wrote:
> >> Hi,
> >>
> >> On 8 February 2014 06:20, Courtney Cavin  
> >> wrote:
> >> > There is currently no common framework for mailbox drivers, so this is my
> >> > attempt to come up with something suitable.  There seems to be a need for
> >> > making this generic, so I have attempted to do just that.  Most of this 
> >> > is
> >> > modeled pretty strongly after the pwm core, with some influences from 
> >> > the clock
> >> > core.
> >> >
> >> > Looking at the existing use-cases, and some new ones, it would appear 
> >> > that the
> >> > requirements here are rather simple. We need essentially two things for
> >> > consumers:
> >> > - put_message
> >> > - callback for receiving messages
> >> >
> >> > The code currently uses atomic notifiers for callbacks.  The common omap 
> >> > core
> >> > deals with fifos and work-queues in order to escape atomic contexts, but 
> >> > from
> >> > what I can see, this is unneeded.  I am also of the opinion that the 
> >> > contexts
> >> > can be much better managed in the drivers which are working with these
> >> > contexts, rather than generically.
> >> >
> >> > Hopefully this will be suitable for the plethora of other drivers around 
> >> > the
> >> > kernel which implement mailboxes, as well.  In any case, I'm rather 
> >> > interested
> >> > to see what the rest of the world thinks.
> >> >
> >> > Keep in mind that while the pl320 & omap code should compile, I don't 
> >> > currently
> >> > have a platform on which I can perform proper testing.  I also removed 
> >> > the
> >> > context save/restore code from omap2 mailbox support, because I think it 
> >> > should
> >> > be able to be done via driver suspend/resume, but haven't done a full
> >> > investigation just yet.
> >> >
> >> > I'm also aware that breaking omap, just to fix it again probably isn't 
> >> > the best
> >> > course of action, and I'm open to suggestions.
> >> >
> >> Did you try to look up the history of mailbox api development?  Google
> >> search: 'mailbox common api'
> >>
> >> I (Linaro/Fujitsu), Suman Anna (TI), LeyFoon Tan (Intel), Craig
> >> McGeachie(Broadcom) and Loic Pallardy(ST) already worked a generic
> >> Mailbox framework and infact have controller drivers working over
> >> them.
> >>  For some confidentiality and some lazy and some confusion or whatever
> >> reasons the final version of drivers and API wasn't submitted upstream
> >> yet.
> >
> > Then, in all reality, it doesn't exist at all, and so, we will evaluate
> > this submission instead.
> >
> > Just because you all can't send something for merging, doesn't mean you
> > get to block someone else who has got their act together, that's not
> > fair.
> >
> Yup probably not much fair. But then also one usually look for any
> early development efforts. IIRC only I and Anna started. Others later
> joined us looking at archives. Not to vindicate our gang though.
> 
>  Now we could either punish us and have this api tread the same
> development path where everyone had their requirements (and the
> only-waiting-for-approval controller drivers to convert)  OR we
> could see if our/original/old API just works for the purposes of Sony
> as well (which it will most probably) and then we could upstream it
> with one more 'works-for-me-too'.

What is stopping you submitting your patches right 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/

[PATCH v2] cgroup: fix top cgroup refcnt leak

[Li Zefan]

If we mount the same cgroupfs in serveral mount points, and then
umount all of them, kill_sb() will be called only once.

Therefore it's wrong to increment top_cgroup's refcnt when we find
an existing cgroup_root.

Try:
# mount -t cgroup -o cpuacct xxx /cgroup
# mount -t cgroup -o cpuacct xxx /cgroup2
# cat /proc/cgroups | grep cpuacct
cpuacct 2   1   1
# umount /cgroup
# umount /cgroup2
# cat /proc/cgroups | grep cpuacct
cpuacct 2   1   1

You'll see cgroupfs will never be freed.

v2: change to take the refcnt and drop it after kernfs_mount().

Signed-off-by: Li Zefan 
---
 kernel/cgroup.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 37d94a2..eaffc08 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1477,6 +1477,7 @@ static struct dentry *cgroup_mount(struct 
file_system_type *fs_type,
struct cgroup_sb_opts opts;
struct dentry *dentry;
int ret;
+   bool new_root = false;
 
/*
 * The first time anyone tries to mount a cgroup, enable the list
@@ -1536,6 +1537,10 @@ retry:
 * destruction to complete so that the subsystems are free.
 * We can use wait_queue for the wait but this path is
 * super cold.  Let's just sleep for a bit and retry.
+*
+* Take a reference so root won't be freed after we drop
+* cgroup mutexes, and drop it after we've done the real
+* mount through kernfs.
 */
if (!atomic_inc_not_zero(>top_cgroup.refcnt)) {
mutex_unlock(_mutex);
@@ -1551,6 +1556,7 @@ retry:
}
 
/* no such thing, create a new one */
+   new_root = true;
root = cgroup_root_from_opts();
if (IS_ERR(root)) {
ret = PTR_ERR(root);
@@ -1572,7 +1578,7 @@ out_unlock:
return ERR_PTR(ret);
 
dentry = kernfs_mount(fs_type, flags, root->kf_root);
-   if (IS_ERR(dentry))
+   if (IS_ERR(dentry) || !new_root)
cgroup_put(>top_cgroup);
return dentry;
 }
-- 
1.8.0.2

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

Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option

[Luiz Capitulino]

On Fri, 14 Feb 2014 15:14:22 -0800 (PST)
David Rientjes  wrote:

> On Thu, 13 Feb 2014, Luiz Capitulino wrote:
> 
> > From: Luiz capitulino 
> > 
> > The HugeTLB command-line option hugepages= allows a user to specify how
> > many huge pages should be allocated at boot. This option is needed because
> > it improves reliability when allocating 1G huge pages, which are better
> > allocated as early as possible due to fragmentation.
> > 
> > However, hugepages= has a limitation. On NUMA systems, hugepages= will
> > automatically distribute memory allocation equally among nodes. For
> > example, if you have a 2-node NUMA system and allocate 200 huge pages,
> > than hugepages= will try to allocate 100 huge pages from node0 and 100
> > from node1.
> > 
> > This is very unflexible, as it doesn't allow you to specify which nodes
> > the huge pages should be allocated from. For example, there are use-cases
> > where the user wants to specify that a 1GB huge page should be allocated
> > from node 2 or that 300 2MB huge pages should be allocated from node 0.
> > 
> > The hugepages_node= command-line option introduced by this commit allows
> > just that.
> > 
> > The syntax is:
> > 
> >   hugepages_node=nid:nr_pages:size,...
> > 
> 
> Again, I think this syntax is horrendous and doesn't couple well with the 
> other hugepage-related kernel command line options.  We already have 
> hugepages= and hugepagesz= which you can interleave on the command line to 
> get 100 2M hugepages and 10 1GB hugepages, for example.
> 
> This patchset is simply introducing another variable to the matter: the 
> node that the hugepages should be allocated on.  So just introduce a 
> hugepagesnode= parameter to couple with the others so you can do
> 
>   hugepagesz= hugepagesnode= hugepages=<#>

That was my first try but it turned out really bad. First, for every node
you specify you need three options. So, if you want to setup memory for
three nodes you'll need to specify nine options. And it gets worse, because
hugepagesz= and hugepages= have strict ordering (which is a mistake, IMHO) so
you have to specify them in the right order otherwise things don't work as
expected and you have no idea why (have been there myself).

IMO, hugepages_node=::,... is good enough. It's concise,
and don't depend on any other option to function. Also, there are lots of other
kernel command-line options that require you to specify multiple fields, so
it's not like hugepages_node= is totally different in that regard.

> 
> instead of having completely confusing interfaces where you want to do 
> hugepages_node=1:1:1G for a 1GB hugepage on page 1 (and try remembering 
> which "1" means what, yuck) and "hugepagesz=1GB hugepages=1" if you're 
> indifferent to the node.
> 
--
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: Loseing my patience with libata and sata_nv

[Gene Heskett]

On Friday 14 February 2014, Larry Finger wrote:
>On 02/14/2014 12:42 PM, Randy Dunlap wrote:
>> On 02/14/2014 08:31 AM, Gene Heskett wrote:
>>> Which is required for my $290 ASUS M2n-SLI Deluxe motherboard to boot.
>>> 
>>> Not finding the option in any kernel tree that exists on my system,
>>> except it appears its been replaced or something.
>>> 
>>> This once in a lifetime boot, to 3.12.9, shows from an lsmod:
>>> libata146855  2 sata_nv,pata_amd
>>> scsi_mod  153579  4 sr_mod,sg,sd_mod,libata
>>> 
>>> I haven't a clue how I got it in this boot, and I built it.  And
>>> apparently a make oldconfig, carefully done by hand (takes about an
>>> hour 30 to do) is not capable of adding it to a .config BECAUSE it
>>> does NOT exist in any of the arch/x86/configs/i386_defconfig's
>>> present on this machine.
>> 
>> It does not have to exist in any defconfig.  Those are just default
>> config files and SATA_NV is not enabled by default, but you can still
>> enable it.
>> 
>>> Here is how I searched:
>>> 
>>> gene@coyote:~/src/linux-3.0.69$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.0.69$ cd
>>> ../linux-3.2.40
>>> gene@coyote:~/src/linux-3.2.40$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.2.40$ cd
>>> ../linux-3.4.36
>>> gene@coyote:~/src/linux-3.4.36$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.4.36$ cd
>>> ../linux-3.8.2
>>> gene@coyote:~/src/linux-3.8.2$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.8.2$ cd
>>> ../linux-3.8.3
>>> gene@coyote:~/src/linux-3.8.3$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.8.3$ cd
>>> ../linux-3.12.0
>>> gene@coyote:~/src/linux-3.12.0$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.12.0$ cd
>>> ../linux-3.12.6
>>> gene@coyote:~/src/linux-3.12.6$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.12.6$ cd
>>> ../linux-3.12.9
>>> gene@coyote:~/src/linux-3.12.9$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.12.9$ cd
>>> ../linux-3.13.1
>>> gene@coyote:~/src/linux-3.13.1$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.13.1$ cd
>>> ../linux-3.13.2
>>> gene@coyote:~/src/linux-3.13.2$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.13.2$
>>> 
>>> I've been fighting with this, intermittently for about 6 months. 
>>> Except for this 3.12.9 where I must have been holding my mouth right,
>>> all the rest are boot failures because it can't find the boot drive
>>> with so-and-so for a UUID. sata_nv is on the missing list, even in
>>> this WORKing boots defconfig. "Working" however is a miss-statement,
>>> no multimedia stuff was built.
>>> 
>>> There has to be a rule I am violating, but even with Randy's D's help,
>>> it is not becoming obvious.  FWIW libata references also can't be
>>> found, but as can be seen, its in memory right now.
>> 
>> libata is built whenever CONFIG_ATA is enabled.
>> 
>>> So please guys, what is the magic dependency that causes libata and
>>> sata_nv to be included in a .config?
>> 
>> The SATA_NV kconfig symbol depends on (requires) the following other
>> kconfig
>> 
>> symbols to be enabled:
>>  ATA_SFF and ATA_BMDMA and PCI and ATA
>> 
>> If those are not enabled, then you will need to use 'make config'
>> to enabled them before you can enable SATA_NV.
>
>Gene,
>
>Your CONFIG indicates that you are building both libata and sata_nv.
>Perhaps you are not including them in your initrd, or whatever it is
>called in your distro. That makes them unavailable at boot time due to
>the chicken-and-egg problem. You need those drivers to access the drive,
>but that is where they reside. An easy way might be to make those two
>drivers be built in rather than as modules.
>
>Larry

Almost exactly the same, Larry, I waited for the 2 minute timeout that 
tried to print something on the top line of the screen before I got up to 
walk over and reset it, but this time there was about a 1 minute blast of 
disk activity from the drive it was trying to boot from, and I thought I 
might have been an e2fsck, so I waited till the drive leds went off and 
stayed off before resetting it.  Nothing on the screen changed after that.

So call me clueless & you would be pretty accurate. :(

Is there another dependency yet?

Thanks.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

--
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] Staging: comedi: kcomedilib: replace deprecated simple_strtoul() with kstrtouint()

[Chase Southwood]

Since simple_strtoul() has been deprecated, replace it with kstrtouint().
Also, since return code checking for this new function is enforced, add a
check to ensure that the conversion has succeeded.

Signed-off-by: Chase Southwood 
---
 drivers/staging/comedi/kcomedilib/kcomedilib_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/kcomedilib/kcomedilib_main.c 
b/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
index 7dc5a18..8923e65 100644
--- a/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
+++ b/drivers/staging/comedi/kcomedilib/kcomedilib_main.c
@@ -41,7 +41,8 @@ struct comedi_device *comedi_open(const char *filename)
if (strncmp(filename, "/dev/comedi", 11) != 0)
return NULL;
 
-   minor = simple_strtoul(filename + 11, NULL, 0);
+   if (kstrtouint(filename + 11, 0, ))
+   return NULL;
 
if (minor >= COMEDI_NUM_BOARD_MINORS)
return NULL;
-- 
1.8.5.3

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

Re: [RFC 0/6] mailbox: add common framework and port drivers

[Jassi Brar]

On 15 February 2014 09:10, Greg Kroah-Hartman
 wrote:
> On Sat, Feb 15, 2014 at 09:02:07AM +0530, Jassi Brar wrote:
>> Hi,
>>
>> On 8 February 2014 06:20, Courtney Cavin  
>> wrote:
>> > There is currently no common framework for mailbox drivers, so this is my
>> > attempt to come up with something suitable.  There seems to be a need for
>> > making this generic, so I have attempted to do just that.  Most of this is
>> > modeled pretty strongly after the pwm core, with some influences from the 
>> > clock
>> > core.
>> >
>> > Looking at the existing use-cases, and some new ones, it would appear that 
>> > the
>> > requirements here are rather simple. We need essentially two things for
>> > consumers:
>> > - put_message
>> > - callback for receiving messages
>> >
>> > The code currently uses atomic notifiers for callbacks.  The common omap 
>> > core
>> > deals with fifos and work-queues in order to escape atomic contexts, but 
>> > from
>> > what I can see, this is unneeded.  I am also of the opinion that the 
>> > contexts
>> > can be much better managed in the drivers which are working with these
>> > contexts, rather than generically.
>> >
>> > Hopefully this will be suitable for the plethora of other drivers around 
>> > the
>> > kernel which implement mailboxes, as well.  In any case, I'm rather 
>> > interested
>> > to see what the rest of the world thinks.
>> >
>> > Keep in mind that while the pl320 & omap code should compile, I don't 
>> > currently
>> > have a platform on which I can perform proper testing.  I also removed the
>> > context save/restore code from omap2 mailbox support, because I think it 
>> > should
>> > be able to be done via driver suspend/resume, but haven't done a full
>> > investigation just yet.
>> >
>> > I'm also aware that breaking omap, just to fix it again probably isn't the 
>> > best
>> > course of action, and I'm open to suggestions.
>> >
>> Did you try to look up the history of mailbox api development?  Google
>> search: 'mailbox common api'
>>
>> I (Linaro/Fujitsu), Suman Anna (TI), LeyFoon Tan (Intel), Craig
>> McGeachie(Broadcom) and Loic Pallardy(ST) already worked a generic
>> Mailbox framework and infact have controller drivers working over
>> them.
>>  For some confidentiality and some lazy and some confusion or whatever
>> reasons the final version of drivers and API wasn't submitted upstream
>> yet.
>
> Then, in all reality, it doesn't exist at all, and so, we will evaluate
> this submission instead.
>
> Just because you all can't send something for merging, doesn't mean you
> get to block someone else who has got their act together, that's not
> fair.
>
Yup probably not much fair. But then also one usually look for any
early development efforts. IIRC only I and Anna started. Others later
joined us looking at archives. Not to vindicate our gang though.

 Now we could either punish us and have this api tread the same
development path where everyone had their requirements (and the
only-waiting-for-approval controller drivers to convert)  OR we
could see if our/original/old API just works for the purposes of Sony
as well (which it will most probably) and then we could upstream it
with one more 'works-for-me-too'.

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 39/48] powerpc: Replace __get_cpu_var uses

[Benjamin Herrenschmidt]

For some reason Im still getting these as attachments instead of inline
in the email, which makes reviewing a major PITA. Christoph, I'm not
sure what you are doing wrong here but you should consider fixing it :-)

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/

Re: [RFC 0/6] mailbox: add common framework and port drivers

[Jassi Brar]

Hi,

On 8 February 2014 06:20, Courtney Cavin  wrote:
> There is currently no common framework for mailbox drivers, so this is my
> attempt to come up with something suitable.  There seems to be a need for
> making this generic, so I have attempted to do just that.  Most of this is
> modeled pretty strongly after the pwm core, with some influences from the 
> clock
> core.
>
> Looking at the existing use-cases, and some new ones, it would appear that the
> requirements here are rather simple. We need essentially two things for
> consumers:
> - put_message
> - callback for receiving messages
>
> The code currently uses atomic notifiers for callbacks.  The common omap core
> deals with fifos and work-queues in order to escape atomic contexts, but from
> what I can see, this is unneeded.  I am also of the opinion that the contexts
> can be much better managed in the drivers which are working with these
> contexts, rather than generically.
>
> Hopefully this will be suitable for the plethora of other drivers around the
> kernel which implement mailboxes, as well.  In any case, I'm rather interested
> to see what the rest of the world thinks.
>
> Keep in mind that while the pl320 & omap code should compile, I don't 
> currently
> have a platform on which I can perform proper testing.  I also removed the
> context save/restore code from omap2 mailbox support, because I think it 
> should
> be able to be done via driver suspend/resume, but haven't done a full
> investigation just yet.
>
> I'm also aware that breaking omap, just to fix it again probably isn't the 
> best
> course of action, and I'm open to suggestions.
>
Did you try to look up the history of mailbox api development?  Google
search: 'mailbox common api'

I (Linaro/Fujitsu), Suman Anna (TI), LeyFoon Tan (Intel), Craig
McGeachie(Broadcom) and Loic Pallardy(ST) already worked a generic
Mailbox framework and infact have controller drivers working over
them.
 For some confidentiality and some lazy and some confusion or whatever
reasons the final version of drivers and API wasn't submitted upstream
yet.

 I think the shortest path to have some generic mailbox framework
upstream is for you to adapt your controller driver to that api and
maybe help pushing it upstream. (I should have clearance to push my
controller driver in a couple of weeks).
It might need a bit api update
https://github.com/sumananna/mailbox/commits/jassiv3-3.10-omap

Thanks
Jassi
--
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 0/6] mailbox: add common framework and port drivers

[Greg Kroah-Hartman]

On Sat, Feb 15, 2014 at 09:02:07AM +0530, Jassi Brar wrote:
> Hi,
> 
> On 8 February 2014 06:20, Courtney Cavin  
> wrote:
> > There is currently no common framework for mailbox drivers, so this is my
> > attempt to come up with something suitable.  There seems to be a need for
> > making this generic, so I have attempted to do just that.  Most of this is
> > modeled pretty strongly after the pwm core, with some influences from the 
> > clock
> > core.
> >
> > Looking at the existing use-cases, and some new ones, it would appear that 
> > the
> > requirements here are rather simple. We need essentially two things for
> > consumers:
> > - put_message
> > - callback for receiving messages
> >
> > The code currently uses atomic notifiers for callbacks.  The common omap 
> > core
> > deals with fifos and work-queues in order to escape atomic contexts, but 
> > from
> > what I can see, this is unneeded.  I am also of the opinion that the 
> > contexts
> > can be much better managed in the drivers which are working with these
> > contexts, rather than generically.
> >
> > Hopefully this will be suitable for the plethora of other drivers around the
> > kernel which implement mailboxes, as well.  In any case, I'm rather 
> > interested
> > to see what the rest of the world thinks.
> >
> > Keep in mind that while the pl320 & omap code should compile, I don't 
> > currently
> > have a platform on which I can perform proper testing.  I also removed the
> > context save/restore code from omap2 mailbox support, because I think it 
> > should
> > be able to be done via driver suspend/resume, but haven't done a full
> > investigation just yet.
> >
> > I'm also aware that breaking omap, just to fix it again probably isn't the 
> > best
> > course of action, and I'm open to suggestions.
> >
> Did you try to look up the history of mailbox api development?  Google
> search: 'mailbox common api'
> 
> I (Linaro/Fujitsu), Suman Anna (TI), LeyFoon Tan (Intel), Craig
> McGeachie(Broadcom) and Loic Pallardy(ST) already worked a generic
> Mailbox framework and infact have controller drivers working over
> them.
>  For some confidentiality and some lazy and some confusion or whatever
> reasons the final version of drivers and API wasn't submitted upstream
> yet.

Then, in all reality, it doesn't exist at all, and so, we will evaluate
this submission instead.

Just because you all can't send something for merging, doesn't mean you
get to block someone else who has got their act together, that's not
fair.

sorry,

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: [PATCH cgroup/for-3.14-fixes] cgroup: update cgroup_enable_task_cg_lists() to grab siglock

[Li Zefan]

On 2014/2/14 2:29, Tejun Heo wrote:
> Currently, there's nothing preventing cgroup_enable_task_cg_lists()
> from missing set PF_EXITING and race against cgroup_exit().  Depending
> on the timing, cgroup_exit() may finish with the task still linked on
> css_set leading to list corruption.  Fix it by grabbing siglock in
> cgroup_enable_task_cg_lists() so that PF_EXITING is guaranteed to be
> visible.
> 
> This whole on-demand cg_list optimization is extremely fragile and has
> ample possibility to lead to bugs which can cause things like
> once-a-year oops during boot.  I'm wondering whether the better
> approach would be just adding "cgroup_disable=all" handling which
> disables the whole cgroup rather than tempting fate with this
> on-demand craziness.
> 
> Signed-off-by: Tejun Heo 
> Cc: sta...@vger.kernel.org

Acked-by: Li Zefan 

--
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] Fix dump failure caused by DMA through an IOMMU

[Bill Sumner]

Renamed from "Crashdump Accepting Active IOMMU" to better communicate
the purpose of this patch.

This patch implements a fix for:
A kdump problem about DMA that has been discussed for a long time. That is,
when a kernel panics and boots into the kdump kernel, DMA started by the 
panicked kernel is not stopped before the kdump kernel is booted and the 
kdump kernel disables the IOMMU while this DMA continues.  This causes the
IOMMU to stop translating the DMA addresses as IOVAs and begin to treat them 
as physical memory addresses -- which causes the DMA to either:
(1) generate DMAR errors or (2) generate PCI SERR errors or (3) transfer  
data to or from incorrect areas of memory. Often this causes the dump to fail.

This patch modifies the behavior of the Intel iommu in the crashdump kernel:
1. to skip disabling the IOMMU translation of IO Virtual Addresses (IOVA),
2. to leave the current translations in-place so that legacy DMA will continue
   using its current buffers until the device drivers in the crashdump kernel
   initialize and initialize their devices,
3. to use different portions of the iova address ranges for the device drivers
   in the crashdump kernel than the iova ranges that were in-use at the time
   of the panic.  

Advantages of this approach:
1. All manipulation of the IO-device is done by the Linux device-driver
   for that device.
2. This approach behaves in a manner very similar to operation without an
   active iommu.
3. Any activity between the IO-device and its RMRR areas is handled by the
   device-driver in the same manner as during a non-kdump boot.
4. If an IO-device has no driver in the kdump kernel, it is simply left alone.
   This supports the practice of creating a special kdump kernel without
   drivers for any devices that are not required for taking a crashdump. 

High-level overview:
During a crashdump, this code operates primarily during iommu initialization
and device-driver initialization -- in essentially the following order:

During intel-iommu hardware initialization:
In intel_iommu_init(void)
* If (This is the crash kernel)
  .  Set flag: crashdump_with_iommu (all changes below check this)
  .  Skip disabling the iommu hardware translations

In init_dmars()
* Duplicate the intel iommu translation tables from the old kernel
  into the new kernel
  . The root-entry table, all context-entry tables,
and all page-translation-entry tables
  . The duplicate tables contain updated physical addresses to link them 
together.
  . The duplicate tables are mapped into kernel virtual addresses
in the new kernel which allows most of the existing iommu code
to operate without change.
  . Do some minimal sanity-checks during the copy
  . Place the address of the new root-entry structure into "struct intel_iommu"

* Skip setting-up new domains for 'si', 'rmrr', 'isa' 
  . Translations for 'rmrr' and 'isa' ranges have been copied from the old 
kernel
  . This patch has not yet been tested with iommu pass-through enabled

* Existing (unchanged) code near the end of dmar_init:
  . Loads the address of the duplicated root-entry structure from
"struct intel_iommu" into the iommu hardware and does the hardware flushes.
This changes the active translation tables from the ones in the old kernel
to the copies in the new kernel.
  . This is legal because the translations in the two sets of tables are
currently identical:
  Virtualization Technology for Directed I/O. Architecture Specification,
  February 2011, Rev. 1.3  (section 11.2, paragraph 2) 

In iommu_init_domains()
* Mark as in-use all domain-id's from the old kernel
  . In case the new kernel contains a device that was not in the old kernel
and a new, unused domain-id is actually needed, the bitmap will give us one.

During Device Driver Initialization:
When a new domain is created for a device:
* If (this device has a context in the old kernel)
  . Get domain-id, address-width, and IOVA ranges from the old kernel context;
  . Get address(page-entry-tables) from the copy in the new kernel;
  . And apply all of the above values to the new domain structure.
* Else
  . Create a new domain as normal


Changes from: [PATCHv3 0/6] Crashdump Accepting Active IOMMU
1. Rearranged the patch cover-letter to provide a clearer and shorter
   explanation of the problem, how the problem is being solved, and
   the advantages of this approach.
2. Combined the multiple patches of the previous patch-set into this
   single patch.
3. Deleted two purely diagnostic print functions that were unnecessary 
   to the primary purpose of this fix.  These could be submitted later
   as separate, independent patches.
4. Changed the patch subject to more accurately reflect its purpose.
5. Made a few changes to better match the style of the mainline code.
6. Added comments at the front of several of the new functions.  
7. Re-edited this patch log 


Signed-off-by: Bill Sumner 
---
 drivers/iommu/intel-iommu.c | 1233 

[PATCH 0/1] Fix Crashdump failure caused by leftover DMA through a hardware IOMMU

[Bill Sumner]

Renamed from previous email thread: Crashdump Accepting Active IOMMU

This patch implements a fix for:
A kdump problem about DMA that has been discussed for a long time. That is,
when a kernel panics and boots into the kdump kernel, DMA started by the 
panicked kernel is not stopped before the kdump kernel is booted and the 
kdump kernel disables the IOMMU while this DMA continues.  This causes the
IOMMU to stop translating the DMA addresses as IOVAs and begin to treat them 
as physical memory addresses -- which causes the DMA to either:
(1) generate DMAR errors or (2) generate PCI SERR errors or (3) transfer  
data to or from incorrect areas of memory. Often this causes the dump to fail.

This patch modifies the behavior of the Intel iommu in the crashdump kernel: 
1. to skip disabling the iommu hardware translations
2. to leave the current translations in-place so that legacy DMA will continue
   using its current buffers until the device drivers in the crashdump kernel
   initialize and initialize their devices,
3. to use different portions of the iova address ranges for the device drivers
   in the crashdump kernel than the iova ranges that were in-use at the time
   of the panic.  

Advantages of this approach:
1. All manipulation of the IO-device is done by the Linux device-driver
   for that device.
2. This approach behaves in a manner very similar to operation when the
   panicked kernel was not using a hardware IOMMU.
3. Any activity between the IO-device and its RMRR areas is handled by the
   device-driver in the same manner as during a non-kdump boot.
4. If an IO-device has no driver in the kdump kernel, it is simply left alone.
   This supports the practice of creating a special kdump kernel without
   drivers for any devices that are not required for taking a crashdump. 

Bill Sumner (1):
  Fix Crashdump failure caused by leftover DMA through a hardware IOMMU

 drivers/iommu/intel-iommu.c | 1233 ---
 1 file changed, 1172 insertions(+), 61 deletions(-)

-- 
Bill Sumner 

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

[RFC v2 3/4] xen-netback: use a random MAC address

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

The purpose of using a static MAC address of FE:FF:FF:FF:FF:FF
was to prevent our backend interfaces from being used by the
bridge and nominating our interface as a root bridge. This was
possible given that the bridge code will use the lowest MAC
address for a port once a new interface gets added to the bridge.
The bridge code has a generic feature now to allow interfaces
to opt out from root bridge nominations, use that instead.

Cc: Paul Durrant 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: xen-de...@lists.xenproject.org
Cc: net...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 drivers/net/xen-netback/interface.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index fff8cdd..d380e3f 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -42,6 +42,8 @@
 #define XENVIF_QUEUE_LENGTH 32
 #define XENVIF_NAPI_WEIGHT  64
 
+static const u8 xen_oui[3] = { 0x00, 0x16, 0x3e };
+
 int xenvif_schedulable(struct xenvif *vif)
 {
return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
@@ -347,15 +349,9 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t 
domid,
for (i = 0; i < MAX_PENDING_REQS; i++)
vif->mmap_pages[i] = NULL;
 
-   /*
-* Initialise a dummy MAC address. We choose the numerically
-* largest non-broadcast address to prevent the address getting
-* stolen by an Ethernet bridge for STP purposes.
-* (FE:FF:FF:FF:FF:FF)
-*/
-   memset(dev->dev_addr, 0xFF, ETH_ALEN);
-   dev->dev_addr[0] &= ~0x01;
-
+   eth_hw_addr_random(dev);
+   memcpy(dev->dev_addr, xen_oui, 3);
+   dev->priv_flags |= IFF_BRIDGE_NON_ROOT;
netif_napi_add(dev, >napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
 
netif_carrier_off(dev);
-- 
1.8.5.2

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

[RFC v2 2/4] net: enables interface option to skip IP

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

Some interfaces do not need to have any IPv4 or IPv6
addresses, so enable an option to specify this. One
example where this is observed are virtualization
backend interfaces which just use the net_device
constructs to help with their respective frontends.

This should optimize boot time and complexity on
virtualization environments for each backend interface
while also avoiding triggering SLAAC and DAD, which is
simply pointless for these type of interfaces.

Cc: "David S. Miller" 
cC: Alexey Kuznetsov 
Cc: James Morris 
Cc: Hideaki YOSHIFUJI 
Cc: Patrick McHardy 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 include/uapi/linux/if.h | 1 +
 net/ipv4/devinet.c  | 3 +++
 net/ipv6/addrconf.c | 6 ++
 3 files changed, 10 insertions(+)

diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
index 8d10382..566d856 100644
--- a/include/uapi/linux/if.h
+++ b/include/uapi/linux/if.h
@@ -85,6 +85,7 @@
 * change when it's running */
 #define IFF_MACVLAN 0x20   /* Macvlan device */
 #define IFF_BRIDGE_NON_ROOT 0x40/* Don't consider for root bridge */
+#define IFF_SKIP_IP0x80/* Skip IPv4, IPv6 */
 
 
 #define IF_GET_IFACE   0x0001  /* for querying only */
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index a1b5bcb..8e9ef07 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1342,6 +1342,9 @@ static int inetdev_event(struct notifier_block *this, 
unsigned long event,
 
ASSERT_RTNL();
 
+   if (dev->priv_flags & IFF_SKIP_IP)
+   goto out;
+
if (!in_dev) {
if (event == NETDEV_REGISTER) {
in_dev = inetdev_init(dev);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 4b6b720..57f58e3 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -314,6 +314,9 @@ static struct inet6_dev *ipv6_add_dev(struct net_device 
*dev)
 
ASSERT_RTNL();
 
+   if (dev->priv_flags & IFF_SKIP_IP)
+   return NULL;
+
if (dev->mtu < IPV6_MIN_MTU)
return NULL;
 
@@ -2749,6 +2752,9 @@ static int addrconf_notify(struct notifier_block *this, 
unsigned long event,
int run_pending = 0;
int err;
 
+   if (dev->priv_flags & IFF_SKIP_IP)
+   return NOTIFY_OK;
+
switch (event) {
case NETDEV_REGISTER:
if (!idev && dev->mtu >= IPV6_MIN_MTU) {
-- 
1.8.5.2

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

[RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

It doesn't make sense for some interfaces to become a root bridge
at any point in time. One example is virtual backend interfaces
which rely on other entities on the bridge for actual physical
connectivity. They only provide virtual access.

Device drivers that know they should never become part of the
root bridge have been using a trick of setting their MAC address
to a high broadcast MAC address such as FE:FF:FF:FF:FF:FF. Instead
of using these hacks lets the interfaces annotate its intent and
generalizes a solution for multiple drivers, while letting the
drivers use a random MAC address or one prefixed with a proper OUI.
This sort of hack is used by both qemu and xen for their backend
interfaces.

Cc: Stephen Hemminger 
Cc: bri...@lists.linux-foundation.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 include/uapi/linux/if.h | 1 +
 net/bridge/br_if.c  | 2 ++
 net/bridge/br_private.h | 1 +
 net/bridge/br_stp_if.c  | 2 ++
 4 files changed, 6 insertions(+)

diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h
index d758163..8d10382 100644
--- a/include/uapi/linux/if.h
+++ b/include/uapi/linux/if.h
@@ -84,6 +84,7 @@
 #define IFF_LIVE_ADDR_CHANGE 0x10  /* device supports hardware address
 * change when it's running */
 #define IFF_MACVLAN 0x20   /* Macvlan device */
+#define IFF_BRIDGE_NON_ROOT 0x40/* Don't consider for root bridge */
 
 
 #define IF_GET_IFACE   0x0001  /* for querying only */
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 4bf02ad..a745415 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -228,6 +228,8 @@ static struct net_bridge_port *new_nbp(struct net_bridge 
*br,
br_init_port(p);
p->state = BR_STATE_DISABLED;
br_stp_port_timer_init(p);
+   if (dev->priv_flags & IFF_BRIDGE_NON_ROOT)
+   p->flags |= BR_DONT_ROOT;
br_multicast_add_port(p);
 
return p;
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 045d56e..a89e8ad 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -173,6 +173,7 @@ struct net_bridge_port
 #define BR_ADMIN_COST  0x0010
 #define BR_LEARNING0x0020
 #define BR_FLOOD   0x0040
+#define BR_DONT_ROOT   0x0080
 
 #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
struct bridge_mcast_query   ip4_query;
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index 656a6f3..12fd848 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -228,6 +228,8 @@ bool br_stp_recalculate_bridge_id(struct net_bridge *br)
return false;
 
list_for_each_entry(p, >port_list, list) {
+   if (p->flags & BR_DONT_ROOT)
+   continue;
if (addr == br_mac_zero ||
memcmp(p->dev->dev_addr, addr, ETH_ALEN) < 0)
addr = p->dev->dev_addr;
-- 
1.8.5.2

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

[RFC v2 0/4] net: bridge / ip optimizations for virtual net backends

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

This v2 series changes the approach from my original virtualization
multicast patch series [0] by abandoning completely the multicast
issues and instead generalizing an approach for virtualization
backends. There are two things in common with virtualization
backends:

  0) they should not become the root bridge
  1) they don't need ipv4 / ipv6 interfaces

Both qemu's usage of TAP interfaces and xen-netback's driver
avoid getting their interfaces added to the root bridge by
using a high MAC address. Lets just generalize the solution
by making this a flag.

The skipping of IPv4 / IPv6 interfaces is an optimization
I observed possible while studying the xen-netback in a
shared physical bridge environment. I haven't been able
to test the NAT environment so I appreciate it if someone
can test these patches for that case if I don't get to it
eventually.

The same flags can be embraced by TAP interfaces when needed,
I tested this as a temporary patch as follows:

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 44c4db8..19b967e 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -940,6 +940,7 @@ static void tun_net_init(struct net_device *dev)
ether_setup(dev);
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+   dev->priv_flags |= IFF_BRIDGE_NON_ROOT | IFF_SKIP_IP;
 
eth_hw_addr_random(dev);
 

a proper followup would be to specify the flags during open() or any
way prior, just to register_netdevice(). Before that is done we'd
need to evaluate all qemu use cases of the TAP interfaces both
for the xen HVM case (which tests fine for me) and for KVM's
use cases on both shared physical and in the NAT case. That is,
test the above patch and this series for all KVM / xen use cases.

[0] http://marc.info/?l=linux-netdev=139207142110536=2

Luis R. Rodriguez (4):
  bridge: enable interfaces to opt out from becoming the root bridge
  net: enables interface option to skip IP
  xen-netback: use a random MAC address
  xen-netback: skip IPv4 and IPv6 interfaces

 drivers/net/xen-netback/interface.c | 14 +-
 include/uapi/linux/if.h |  2 ++
 net/bridge/br_if.c  |  2 ++
 net/bridge/br_private.h |  1 +
 net/bridge/br_stp_if.c  |  2 ++
 net/ipv4/devinet.c  |  3 +++
 net/ipv6/addrconf.c |  6 ++
 7 files changed, 21 insertions(+), 9 deletions(-)

-- 
1.8.5.2

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

[RFC v2 4/4] xen-netback: skip IPv4 and IPv6 interfaces

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

The xen-netback driver is used only to provide a backend
interface for the frontend. The link is the only thing we
use, and that is used internally for letting us know when the
xen-netfront is ready, when it switches to XenbusStateConnected.

Note that only when the both the xen-netfront and xen-netback
are both in state XenbusStateConnected will xen-netback allow
userspace on the host (backend) to bring up the interface. Enabling
and disabling the interface will simply enable or disable NAPI
respectively, and that's used for IRQ communication set up with
the xen event channels.

Cc: Paul Durrant 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: xen-de...@lists.xenproject.org
Cc: net...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 drivers/net/xen-netback/interface.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index d380e3f..07e6fd2 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -351,7 +351,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t 
domid,
 
eth_hw_addr_random(dev);
memcpy(dev->dev_addr, xen_oui, 3);
-   dev->priv_flags |= IFF_BRIDGE_NON_ROOT;
+   dev->priv_flags |= IFF_BRIDGE_NON_ROOT | IFF_SKIP_IP;
netif_napi_add(dev, >napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
 
netif_carrier_off(dev);
-- 
1.8.5.2

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

Re: [RFC][PATCH 0/5] arch: atomic rework

[Linus Torvalds]

On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds
 wrote:
>
> And conversely, the C11 people can walk away from us too. But if they
> can't make us happy (and by "make us happy", I really mean no stupid
> games on our part) I personally think they'll have a stronger
> standard, and a real use case, and real arguments. I'm assuming they
> want that.

I should have somebody who proof-reads my emails before I send them out.

I obviously meant "if they *can* make us happy" (not "can't").

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

Re: [PATCH v16 0/10] Add 32 bit VDSO time function support

[Greg KH]

On Fri, Feb 14, 2014 at 02:40:12PM -0800, Andy Lutomirski wrote:
> On Fri, Feb 14, 2014 at 12:52 AM, Stefani Seibold  wrote:
> > This patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> > and vdso_time() to the 32 bit VDSO.
> 
> Is there any chance you can shove this in a git tree somewhere for the
> next version (in addition to sending patches)?  I don't have magic
> scripts to make pulling these things in from gmail easy.

I'd recommend not using gmail for getting kernel patches, that's what
the imap interface is for :)
--
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 0/5] arch: atomic rework

[Linus Torvalds]

On Fri, Feb 14, 2014 at 6:08 PM, Paul E. McKenney
 wrote:
>
> One way of looking at the discussion between Torvald and myself would be
> as a seller (Torvald) and a buyer (me) haggling over the fine print in
> a proposed contract (the standard).  Whether that makes you feel better
> or worse about the situation I cannot say.  ;-)

Oh, I'm perfectly fine with that. But we're not desperate to buy, and
I actually think the C11 people are - or at least should be - *way*
more desperate to sell their model to us than we are to take it.

Which means that as a buyer you should say "this is what we want, if
you don't give us this, we'll just walk away". Not try to see how much
we can pay for it. Because there is very little upside for us, and
_unless_ the C11 standard gets things right it's just extra complexity
for us, coupled with new compiler fragility and years of code
generation bugs.

Why would we want that extra complexity and inevitable compiler bugs?
If we then have to fight compiler writers that point to the standard
and say "..but look, the standard says we can do this", then at that
point it went from "extra complexity and compiler bugs" to a whole
'nother level of frustration and pain.

So just walk away unless the C11 standard gives us exactly what we
want. Not "something kind of like what we'd use". EXACTLY. Because I'm
not in the least interested in fighting compiler people that have a
crappy standard they can point to. Been there, done that, got the
T-shirt and learnt my lesson.

And the thing is, I suspect that the Linux kernel is the most complete
- and most serious - user of true atomics that the C11 people can sell
their solution to.

If we don't buy it, they have no serious user. Sure, they'll have lots
of random other one-off users for their atomics, where each user wants
one particular thing, but I suspect that we'll have the only really
unified portable code base that handles pretty much *all* the serious
odd cases that the C11 atomics can actually talk about to each other.

Oh, they'll push things through with or without us, and it will be a
collection of random stuff, where they tried to please everybody, with
particularly compiler/architecture people who have no f*cking clue
about how their stuff is used pushing to make it easy/efficient for
their particular compiler/architecture.

But we have real optimized uses of pretty much all relevant cases that
people actually care about.

We can walk away from them, and not really lose anything but a small
convenience (and it's a convenience *only* if the standard gets things
right).

And conversely, the C11 people can walk away from us too. But if they
can't make us happy (and by "make us happy", I really mean no stupid
games on our part) I personally think they'll have a stronger
standard, and a real use case, and real arguments. I'm assuming they
want that.

That's why I complain when you talk about things like marking control
dependencies explicitly. That's *us* bending over backwards. And as a
buyer, we have absolutely zero reason to do that.

Tell the C11 people: "no speculative writes". Full stop. End of story.
Because we're not buying anything else.

Similarly, if we need to mark atomics "volatile", then now the C11
atomics are no longer even a "small convenience", now they are just
extra complexity wrt what we already have. So just make it clear that
if the C11 standard needs to mark atomics volatile in order to get
non-speculative and non-reloading behavior, then the C11 atomics are
useless to us, and we're not buying.

Remember: a compiler can *always* do "as if" optimizations - if a
compiler writer can prove that the end result acts 100% the same using
an optimized sequence, then they can do whatever the hell they want.
That's not the issue. But if we can *ever* see semantic impact of
speculative writes, the compiler is buggy, and the compiler writers
need to be aware that it is buggy. No ifs, buts, maybes about it.

So I'm perfectly fine with you seeing yourself as a buyer. But I want
you to be a really *picky* and anal buyer - one that knows he has the
upper hand, and can walk away with no downside.

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

Re: [PATCH] oprofile: check whether oprofile perf enabled in op_overflow_handler()

[Weng Meiling]

Hi Will,

 I test kernel with this patch, the problem has be fixed. When the
 event's sample_period is small, the cpu will not stall except printing
 warning "oprofile: ignoring spurious overflow ignoring spurious overflow".
 This is normal for unregistered event.

 So would you please send a formal one? :) Thanks very much!

On 2014/2/11 23:52, Will Deacon wrote:
> On Tue, Feb 11, 2014 at 04:33:51AM +, Weng Meiling wrote:
>> Hi Will,
> 
> Hello,
> 
> how userland can be notified about throttling. Throttling could be
> worth for operf too, not only for the oprofile kernel driver.
>
>>>
> From a quick look it seems there is also code in x86 that dynamically
> adjusts the rate which might be worth being implemented for ARM too.

 Are you referring to the perf_sample_event_took callback? If so, that
 certainly looks worth persuing. I'll stick it on my list, thanks!

>>
>> Is there any progress on this work? Because this is important for me.
>> Sorry for trouble you.
> 
> Oops, I totally forgot about this. Does the below patch work for you?
> 
> Will
> 
> --->8
> 
> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 361a1aaee7c8..a6bc431cde70 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -302,6 +302,8 @@ static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
> struct arm_pmu *armpmu;
> struct platform_device *plat_device;
> struct arm_pmu_platdata *plat;
> +   int ret;
> +   u64 start_clock, finish_clock;
>  
> if (irq_is_percpu(irq))
> dev = *(void **)dev;
> @@ -309,10 +311,15 @@ static irqreturn_t armpmu_dispatch_irq(int irq, void 
> *dev)
> plat_device = armpmu->plat_device;
> plat = dev_get_platdata(_device->dev);
>  
> +   start_clock = sched_clock();
> if (plat && plat->handle_irq)
> -   return plat->handle_irq(irq, dev, armpmu->handle_irq);
> +   ret = plat->handle_irq(irq, dev, armpmu->handle_irq);
> else
> -   return armpmu->handle_irq(irq, dev);
> +   ret = armpmu->handle_irq(irq, dev);
> +   finish_clock = sched_clock();
> +
> +   perf_sample_event_took(finish_clock - start_clock);
> +   return ret;
>  }
>  
>  static void
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 56003c6edfd3..6fcc293d77a4 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -237,6 +237,8 @@ void perf_sample_event_took(u64 sample_len_ns)
> u64 local_samples_len;
> u64 allowed_ns = ACCESS_ONCE(perf_sample_allowed_ns);
>  
> +   pr_info("perf_sample_event_took(%llu ns)\n", sample_len_ns);
> +
> if (allowed_ns == 0)
> return;
>  
>  
> 
> .
> 


--
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/4] Documentation: mailbox: APM X-Gene SoC QMTM

[Ravi Patel]

This patch adds documentation for APM X-Gene SoC Queue Manager/Traffic Manager.

Signed-off-by: Ravi Patel 
Signed-off-by: Keyur Chudgar 
---
 Documentation/mailbox/apm-xgene-qmtm.txt |  149 ++
 1 file changed, 149 insertions(+)
 create mode 100644 Documentation/mailbox/apm-xgene-qmtm.txt

diff --git a/Documentation/mailbox/apm-xgene-qmtm.txt 
b/Documentation/mailbox/apm-xgene-qmtm.txt
new file mode 100644
index 000..2b4ff09
--- /dev/null
+++ b/Documentation/mailbox/apm-xgene-qmtm.txt
@@ -0,0 +1,149 @@
+AppliedMicro X-Gene SOC Queue Manager/Traffic Manager Document
+
+Copyright (c) 2013 Applied Micro Circuits Corporation.
+Author: Ravi Patel 
+
+This program is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License version 2 as published by
+the Free Software Foundation.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+
+Overview:
+QMTM is a device which interacts with CPU, Ethernet, PktDMA and Security
+subsystems through AXI BUS. Its centralized resource manager/driver exports
+APIs for CPU, Ethernet, PktDMA and Security subsystems to
+1. Initialize & allocate queue & pbn.
+2. Read queue state so that subsystems driver knows how much more work it can
+   offload to its subsystem.
+3. Apply QoS for subsystems on their queues.
+
+Layout:
+The layout represents run-time flow of messages between Ethernet subsystem, CPU
+and QMTM in APM X-Gene SOC. PktDMA and Security subsystems interfaces with QMTM
+in the same way as Ethernet.
+
+
+  CPU
+  o-o
+  | |
+ +|[2]   {5}|+
+ || [1] {4} ||
+Register |o--+---+--o| Register
+Write|CPU WR |   | CPU RD| Write
+to start v  MSG  v   ^  MSG  v to notify
+packet   |   |DDR|   | packet
+transmit |  o+-o-+o  | received
+ |  | Q0   M . M M | M M . M   Q1 |  |
+ |  | for  S . S S | S S . S  for |  |
+ |  | ETH  G . G G | G G . G  ETH |  |
+ |  | TX   n . 2 1 | 1 2 . n   RX |  |
+ |  o--+---o---+--o  |
+ | |   | |
+ v v   ^ v
+ | |   | |
+o|-|---|-|o
+|| |   | || Coherent
+|v v   ^ v| I/O
+|| |   | || BUS
+o|-|---|-|o
+ | [3] |   | {3} |
+ v QMTM RD v   ^ QMTM WR v
+ |   MSG   |   |   MSG   |
+o+o+---o---+o+o
+| Queue 0 ||| Queue 1 |
+| Command o ETH PBN 0  o  CPU PBN 0 o Command | Queue Manager/
+| Register|||Register | Traffic Manager
+o-o---+o+---o-o
+  | |
+  v ^
+Ethernet RD MSG   | [4]   ETH   {2} |  Ethernet WR MSG
+from its PBN  o---+-+---o to CPU PBN
+  | |
+  | Egress MAC  Ingress MAC |
+  | [5] {1} |
+  o--|---|--o
+ v   ^
+ |   |
+  TX Data RX Data
+
+Transmit Flow
+[1] CPU (Ethernet driver) prepares 32 byte Ethernet egress work message and
+enqueues the message to the queue in DDR.
+[2] CPU (Ethernet driver) notifies QMTM that there is a message enqueued in
+Ethernet transmit queue (e.g. Q0).
+[3] QMTM prefetches the Ethernet egress work messages into Ethernet PBN
+(e.g. ETH PBN 0).
+[4] Ethernet reads work messages from its PBN.
+[5] Ethernet DMAs payload from DDR to its egress FIFO and transmits data out.
+
+Receive Flow
+{1} Ethernet receives data and DMAs payload from its ingress FIFO to DDR and
+prepares a Ethernet ingress work message.
+{2} Ethernet pushes work message to QMTM.
+{3} QMTM prefetches the Ethernet ingress work messages into CPU PBN
+(e.g. CPU PBN 0) and then interrupts CPU.
+{4} CPU (Ethernet driver) dequeues the 32 bytes Ethernet ingress work message
+from the queue in DDR.
+{5} CPU (Ethernet driver) notifies QMTM that it dequeued a message from
+Ethernet receive queue (e.g. Q1).
+
+
+Definition:
+1. QMTM (Queue/Traffic Manager)
+   QMTM manages queues and pbns for CPU, Ethernet, PktDMA and Security
+   Subsystems. It also performs flow control and QoS 

[PATCH V3 3/4] mailbox: xgene: base driver for APM X-Gene SoC QMTM

[Ravi Patel]

This patch adds APM X-Gene SoC Queue Manager/Traffic Manager base driver.
QMTM is requried by Ethernet, PktDMA (XOR Engine) and Security subsystems.

Signed-off-by: Ravi Patel 
Signed-off-by: Keyur Chudgar 
---
 MAINTAINERS  |9 +
 drivers/mailbox/Kconfig  |2 +
 drivers/mailbox/Makefile |1 +
 drivers/mailbox/xgene/Kconfig|9 +
 drivers/mailbox/xgene/Makefile   |7 +
 drivers/mailbox/xgene/xgene_qmtm_main.c  |  516 ++
 drivers/mailbox/xgene/xgene_qmtm_main.h  |  112 +++
 drivers/mailbox/xgene/xgene_qmtm_storm.c |  358 +
 include/linux/platform_data/xgene_qmtm.h |  300 +
 9 files changed, 1314 insertions(+)
 create mode 100644 drivers/mailbox/xgene/Kconfig
 create mode 100644 drivers/mailbox/xgene/Makefile
 create mode 100644 drivers/mailbox/xgene/xgene_qmtm_main.c
 create mode 100644 drivers/mailbox/xgene/xgene_qmtm_main.h
 create mode 100644 drivers/mailbox/xgene/xgene_qmtm_storm.c
 create mode 100644 include/linux/platform_data/xgene_qmtm.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 2507f38..3e09f39 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -678,6 +678,15 @@ S: Maintained
 F: drivers/net/appletalk/
 F: net/appletalk/
 
+APPLIEDMICRO (APM) X-GENE SOC QUEUE MANAGER/TRAFFIC MANAGER (QMTM) DRIVER
+M: Ravi Patel 
+M: Keyur Chudgar 
+S: Maintained
+F: drivers/mailbox/xgene/
+F: include/linux/platform_data/xgene_qmtm.h
+F: Documentation/devicetree/bindings/mailbox/apm-xgene-qmtm.txt
+F: Documentation/mailbox/apm-xgene-qmtm
+
 APTINA CAMERA SENSOR PLL
 M: Laurent Pinchart 
 L: linux-me...@vger.kernel.org
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index c8b5c13..52653d4 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -50,4 +50,6 @@ config OMAP_MBOX_KFIFO_SIZE
  Specify the default size of mailbox's kfifo buffers (bytes).
  This can also be changed at runtime (via the mbox_kfifo_size
  module parameter).
+
+source "drivers/mailbox/xgene/Kconfig"
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index e0facb3..6faee7e 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_OMAP1_MBOX)+= mailbox_omap1.o
 mailbox_omap1-objs := mailbox-omap1.o
 obj-$(CONFIG_OMAP2PLUS_MBOX)   += mailbox_omap2.o
 mailbox_omap2-objs := mailbox-omap2.o
+obj-$(CONFIG_XGENE_MBOX)   += xgene/
diff --git a/drivers/mailbox/xgene/Kconfig b/drivers/mailbox/xgene/Kconfig
new file mode 100644
index 000..0843303
--- /dev/null
+++ b/drivers/mailbox/xgene/Kconfig
@@ -0,0 +1,9 @@
+config XGENE_MBOX
+   tristate "APM X-Gene Queue Manager/Traffic Manager Mailbox"
+   depends on ARM64 || COMPILE_TEST
+   default y
+   help
+ This option enables APM X-Gene Queue Manager Traffic Manager (QMTM)
+ mailbox support.
+ QMTM is required for Ethernet, PktDMA (XOR Engine) and Security
+ Engine.
diff --git a/drivers/mailbox/xgene/Makefile b/drivers/mailbox/xgene/Makefile
new file mode 100644
index 000..574e1b8
--- /dev/null
+++ b/drivers/mailbox/xgene/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for APM X-GENE Queue Manager Traffic Manager mailbox
+#
+
+obj-$(CONFIG_XGENE_MBOX) += xgene-qmtm.o
+
+xgene-qmtm-objs := xgene_qmtm_main.o xgene_qmtm_storm.o
diff --git a/drivers/mailbox/xgene/xgene_qmtm_main.c 
b/drivers/mailbox/xgene/xgene_qmtm_main.c
new file mode 100644
index 000..bc50cd9
--- /dev/null
+++ b/drivers/mailbox/xgene/xgene_qmtm_main.c
@@ -0,0 +1,516 @@
+/*
+ * AppliedMicro X-Gene SoC Queue Manager/Traffic Manager driver
+ *
+ * Copyright (c) 2013 Applied Micro Circuits Corporation.
+ * Author: Ravi Patel 
+ * Keyur Chudgar 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "xgene_qmtm_main.h"
+
+#define XGENE_QMTM_DRIVER_VER  "1.0"
+#define XGENE_QMTM_DRIVER_NAME "xgene-qmtm"
+#define XGENE_QMTM_DRIVER_DESC "APM X-Gene QMTM driver"
+
+/* CSR Address Macros */
+#define CSR_QM_CONFIG_ADDR 0x0004
+#define  QM_ENABLE_WR(src) (((u32)(src)<<31) & 0x8000)
+
+#define CSR_PBM_ADDR   0x0008
+#define  OVERWRITE_WR(src) (((u32)(src)<<31) & 0x8000)
+#define  SLVID_PBN_WR(src) (((u32)(src)) & 0x03ff)
+
+#define CSR_PBM_BUF_WR_ADDR0x000c
+#define CSR_PBM_BUF_RD_ADDR0x0010
+#define  PB_SIZE_WR(src)   

[PATCH V3 0/4] mailbox: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager

[Ravi Patel]

This patch adds support for APM X-Gene SoC Queue Manager/Traffic Manager.
 QMTM is required by APM X-Gene SoC Ethernet, PktDMA (XOR Engine) and
 Security Engine subsystems. All subsystems communicate with QMTM using
 messages which include information about the work to be performed and
 the location of associated data buffers.

V3:
 * Switch to mailbox framework
 * Add support for little and big endian kernel
 * Change virt_to_phys function call to dma_zalloc_coherent

V2:
 * Adding COMPILE_TEST dependency for QMTM in Kconfig
 * Updated license banner as per review comments
 * Fixed alignment for macros
 * Changed EXPORT_SYMBOL to EXPORT_SYMBOL_GPL

V1:
 * inital version

Signed-off-by: Ravi Patel 
Signed-off-by: Keyur Chudgar 
---
Ravi Patel (4):
  Documentation: mailbox: APM X-Gene SoC QMTM
  Documentation: devicetree: bindings for APM X-Gene SoC QMTM
  mailbox: xgene: base driver for APM X-Gene SoC QMTM
  arm64: boot: dts: entries for APM X-Gene SoC QMTM

 .../devicetree/bindings/mailbox/apm-xgene-qmtm.txt |   53 ++
 Documentation/mailbox/apm-xgene-qmtm.txt   |  149 ++
 MAINTAINERS|9 +
 arch/arm64/boot/dts/apm-storm.dtsi |   18 +-
 drivers/mailbox/Kconfig|2 +
 drivers/mailbox/Makefile   |1 +
 drivers/mailbox/xgene/Kconfig  |9 +
 drivers/mailbox/xgene/Makefile |7 +
 drivers/mailbox/xgene/xgene_qmtm_main.c|  516 
 drivers/mailbox/xgene/xgene_qmtm_main.h|  112 +
 drivers/mailbox/xgene/xgene_qmtm_storm.c   |  358 ++
 include/linux/platform_data/xgene_qmtm.h   |  300 
 12 files changed, 1533 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mailbox/apm-xgene-qmtm.txt
 create mode 100644 Documentation/mailbox/apm-xgene-qmtm.txt
 create mode 100644 drivers/mailbox/xgene/Kconfig
 create mode 100644 drivers/mailbox/xgene/Makefile
 create mode 100644 drivers/mailbox/xgene/xgene_qmtm_main.c
 create mode 100644 drivers/mailbox/xgene/xgene_qmtm_main.h
 create mode 100644 drivers/mailbox/xgene/xgene_qmtm_storm.c
 create mode 100644 include/linux/platform_data/xgene_qmtm.h

-- 
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 V3 2/4] Documentation: devicetree: bindings for APM X-Gene SoC QMTM

[Ravi Patel]

This patch adds devicetree bindings documentation for APM X-Gene SoC Queue
Manager/Traffic Manager.

Signed-off-by: Ravi Patel 
Signed-off-by: Keyur Chudgar 
---
 .../devicetree/bindings/mailbox/apm-xgene-qmtm.txt |   53 
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/apm-xgene-qmtm.txt

diff --git a/Documentation/devicetree/bindings/mailbox/apm-xgene-qmtm.txt 
b/Documentation/devicetree/bindings/mailbox/apm-xgene-qmtm.txt
new file mode 100644
index 000..cb17d5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/apm-xgene-qmtm.txt
@@ -0,0 +1,53 @@
+* APM X-Gene SoC Queue Manager/Traffic Manager mailbox nodes
+
+Mailbox nodes are defined to describe on-chip Queue Managers in APM X-Gene SoC.
+APM X-Gene SoC Ethernet, PktDMA (XOR Engine), and Security Engine subsystems
+communicate with a central Queue Manager using messages which include
+information about the work to be performed and the location of the associated
+data buffers. There are multiple instances of QMTM. Each QMTM instance has its
+own node. Its corresponding clock nodes are shown below.
+
+Required properties:
+- compatible   : Shall be "apm,xgene-qmtm"
+- reg  : First memory resource shall be the QMTM register
+ memory resource.
+ Second memory resource shall be the QMTM IO-Fabric
+ memory resource.
+- #mailbox-cells   : Shall be 4 as it expects following arguments
+ First cell for 64-bit mailbox bus address MSB.
+ Second cell for 64-bit mailbox bus address LSB.
+ Third cell for 32-bit mailbox size.
+ Fourth cell for 32-bit mailbox signal/id value.
+- interrupts   : First interrupt resource shall be the QMTM Error
+ interrupt.
+ Remaining interrupt resources shall be the Ingress
+ work message interrupt mapping for receiver,
+ receiving work messages for the QMTM.
+- clocks   : Reference to the clock entry.
+
+Optional properties:
+- status   : Shall be "ok" if enabled or "disabled" if disabled.
+ Default is "ok".
+
+Example:
+   qmlclk: qmlclk {
+   compatible = "apm,xgene-device-clock";
+   #clock-cells = <1>;
+   clock-names = "socplldiv2";
+   status = "ok";
+   csr-offset = <0x0>;
+   csr-mask = <0x3>;
+   enable-offset = <0x8>;
+   enable-mask = <0x3>;
+   };
+
+   qmlite: mailbox@1703 {
+   compatible = "apm,xgene-qmtm";
+   #mailbox-cells = <4>;
+   status = "ok";
+   reg = <0x0 0x1703 0x0 0x1>,
+ <0x0 0x1000 0x0 0x40>;
+   interrupts = <0x0 0x40 0x4>,
+<0x0 0x3c 0x4>;
+   clocks = < 0>;
+   };
-- 
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 V3 4/4] arm64: boot: dts: entries for APM X-Gene SoC QMTM

[Ravi Patel]

This patch adds APM X-Gene SoC Queue Manager/Traffic Manager DTS entries.

Signed-off-by: Ravi Patel 
Signed-off-by: Keyur Chudgar 
---
 arch/arm64/boot/dts/apm-storm.dtsi |   18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..70b2725 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -148,10 +148,15 @@
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
clocks = < 0>;
-   clock-names = "qmlclk";
+   clock-names = "socplldiv2";
reg = <0x0 0x1703C000 0x0 0x1000>;
reg-names = "csr-reg";
clock-output-names = "qmlclk";
+   status = "ok";
+   csr-offset = <0x0>;
+   csr-mask = <0x3>;
+   enable-offset = <0x8>;
+   enable-mask = <0x3>;
};
 
ethclk: ethclk {
@@ -187,5 +192,16 @@
interrupt-parent = <>;
interrupts = <0x0 0x4c 0x4>;
};
+
+   qmlite: mailbox@1703 {
+   compatible = "apm,xgene-qmtm";
+   #mailbox-cells = <4>;
+   status = "ok";
+   reg = <0x0 0x1703 0x0 0x1>,
+ <0x0 0x1000 0x0 0x40>;
+   interrupts = <0x0 0x40 0x4>,
+<0x0 0x3c 0x4>;
+   clocks = < 0>;
+   };
};
 };
-- 
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 v2 cgroup/for-3.15] cgroup: make cgroup_enable_task_cg_lists() to grab siglock

[Li Zefan]

On 2014/2/15 4:47, Tejun Heo wrote:
> Currently, there's nothing explicitly preventing
> cgroup_enable_task_cg_lists() from missing set PF_EXITING and race
> against cgroup_exit(), and, depending on the timing, cgroup_exit()
> seemingly may finish with the task still linked on css_set leading to
> list corruption because cgroup_enable_task_cg_lists() can end up
> linking it after list_empty(>cg_list) test in cgroup_exit().
> 
> This can't really happen because exit_mm() grabs and release
> task_lock() between setting of PF_EXITING and cgroup_exit(), and
> cgroup_enable_task_cg_lists() synchronizes against task_lock too;
> however, this is fragile and more of a happy accident.  Let's make the
> synchronization explicit by making cgroup_enable_task_cg_lists() grab
> siglock around PF_EXITING testing.
> 
> This whole on-demand cg_list optimization is extremely fragile and has
> ample possibility to lead to bugs which can cause things like
> once-a-year oops during boot.  I'm wondering whether the better
> approach would be just adding "cgroup_disable=all" handling which
> disables the whole cgroup rather than tempting fate with this dynamic
> optimization craziness.
> 
> v2: Li pointed out that the race condition can't actually happen due
> to task_lock locking in exit_mm().  Updated the patch description
> accordingly and dropped -stable cc.
> 

I realise exit_mm() is a no-op for threads... There're quite a few places
task_lock is used between exit_signal() and cgroup_exit(), but they're
all conditional, so I think your original changelog stands!

--
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 0/5] arch: atomic rework

[Paul E. McKenney]

On Fri, Feb 14, 2014 at 12:02:23PM -0800, Linus Torvalds wrote:
> On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds
>  wrote:
> >
> > Why are we still discussing this idiocy? It's irrelevant. If the
> > standard really allows random store speculation, the standard doesn't
> > matter, and sane people shouldn't waste their time arguing about it.
> 
> Btw, the other part of this coin is that our manual types (using
> volatile and various architecture-specific stuff) and our manual
> barriers and inline asm accesses are generally *fine*.
> 
> The C11 stuff doesn't buy us anything. The argument that "new
> architectures might want to use it" is prue and utter bollocks, since
> unless the standard gets the thing *right*, nobody sane would ever use
> it for some new architecture, when the sane thing to do is to just
> fill in the normal barriers and inline asms.
> 
> So I'm very very serious: either the compiler and the standard gets
> things right, or we don't use it. There is no middle ground where "we
> might use it for one or two architectures and add random hints".
> That's just stupid.
> 
> The only "middle ground" is about which compiler version we end up
> trusting _if_ it turns out that the compiler and standard do get
> things right. From Torvald's explanations (once I don't mis-read them
> ;), my take-away so far has actually been that the standard *does* get
> things right, but I do know from over-long personal experience that
> compiler people sometimes want to be legalistic and twist the
> documentation to the breaking point, at which point we just go "we'd
> be crazy do use that".
> 
> See our use of "-fno-strict-aliasing", for example. The C standard
> aliasing rules are a mistake, stupid, and wrong, and gcc uses those
> stupid type-based alias rules even when statically *proving* the
> aliasing gives the opposite result. End result: we turn the shit off.
> 
> Exact same deal wrt atomics. We are *not* going to add crazy "this
> here is a control dependency" crap. There's a test, the compiler
> *sees* the control dependency for chrissake, and it still generates
> crap, we turn that broken "optimization" off. It really is that
> simple.

>From what I can see at the moment, the standard -generally- avoids
speculative stores, but there are a few corner cases where it might
allow them.  I will be working with the committee to see exactly what the
situation is.  Might be that I am confused and that everything really
is OK, might be that I am right but the corner cases are things that
no sane kernel developer would do anyway, it might be that the standard
needs a bit of repair, or it might be that the corner cases are somehow
inherent and problematic (but I hope not!).  I will let you know what
I find, but it will probably be a few months.

In the meantime, agreed, we keep doing what we have been doing.  And
maybe in the long term as well, for that matter.

One way of looking at the discussion between Torvald and myself would be
as a seller (Torvald) and a buyer (me) haggling over the fine print in
a proposed contract (the standard).  Whether that makes you feel better
or worse about the situation I cannot say.  ;-)

Thanx, Paul

--
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] nfsd: check passed socket's net matches NFSd superblock's one

[Weng Meiling]

Hi Bruce,

The upstream has merged your git tree for-3.14, but there is no this patch?
Do you forget this patch?

Thanks!
Weng Meiling


On 2014/1/4 6:22, J. Bruce Fields wrote:
> On Mon, Dec 30, 2013 at 05:23:59PM +0300, Stanislav Kinsbursky wrote:
>> There could be a case, when NFSd file system is mounted in network, different
>> to socket's one, like below:
>>
>> "ip netns exec" creates new network and mount namespace, which duplicates 
>> NFSd
>> mount point, created in init_net context. And thus NFS server stop in nested
>> network context leads to RPCBIND client destruction in init_net.
>> Then, on NFSd start in nested network context, rpc.nfsd process creates 
>> socket
>> in nested net and passes it into "write_ports", which leads to RPCBIND 
>> sockets
>> creation in init_net context because of the same reason (NFSd monut point was
>> created in init_net context). An attempt to register passed socket in nested
>> net leads to panic, because no RPCBIND client present in nexted network
>> namespace.
> 
> So it's the attempt to use a NULL ->rpcb_local_clnt4?
> 
> Interesting, thanks--applying with a minor fix to logged message.
> 
> --b.
> 



--
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: task_ctx_sched_out WARN_ON triggered.

[Dave Jones]

On Wed, Jan 29, 2014 at 04:32:04PM +0100, Peter Zijlstra wrote:
 > On Wed, Jan 29, 2014 at 03:07:44PM +0100, Peter Zijlstra wrote:
 > > Let me see if I can make a 'nice' function to dump state though, it
 > > might come in handy more often.
 > 
 > Compile tested only...

This took a while, but I finally got a trace out with this debugging stuff 
enabled.

Dave

ctx->type = 0
[ cut here ]
WARNING: CPU: 0 PID: 12579 at kernel/events/core.c:2539 
task_ctx_sched_out+0x503/0x8a0()
Modules linked in: nf_conntrack_netlink nf_conntrack pn_pep llc2 af_key rfcomm 
bnep snd_seq_dummy tun fuse hidp nfnetlink scsi_transport_iscsi can_raw can_bcm 
ipt_ULOG nfc caif_socket caif af_802154 phonet af_rxrpc can pppoe pppox 
ppp_generic slhc irda crc_ccitt rds rose x25 atm netrom appletalk ipx p8023 
psnap p8022 llc ax25 cfg80211 snd_hda_codec_hdmi xfs snd_hda_codec_realtek 
coretemp hwmon snd_hda_codec_generic x86_pkg_temp_thermal snd_hda_intel 
kvm_intel snd_hda_codec kvm btusb snd_hwdep bluetooth snd_seq snd_seq_device 
crct10dif_pclmul snd_pcm crc32c_intel e1000e ghash_clmulni_intel 6lowpan_iphc 
libcrc32c microcode rfkill snd_timer serio_raw pcspkr usb_debug shpchp snd ptp 
soundcore pps_core
CPU: 0 PID: 12579 Comm: trinity-c5 Not tainted 3.14.0-rc2+ #117
 0009 44d442b6 88009e1b7de0 9972b1d1
  88009e1b7e18 9906d0cd 88024d017700
 8801185e5898 0282 88023a892e60 8801185e5898
Call Trace:
 [] dump_stack+0x4e/0x7a
 [] warn_slowpath_common+0x7d/0xa0
 [] warn_slowpath_null+0x1a/0x20
 [] task_ctx_sched_out+0x503/0x8a0
 [] perf_event_comm+0x108/0x260
 [] ? perf_event_fork+0x20/0x20
 [] ? set_task_comm+0x25/0xc0
 [] ? get_parent_ip+0xd/0x50
 [] set_task_comm+0x4f/0xc0
 [] SyS_prctl+0x22b/0x3d0
 [] tracesys+0xd4/0xd9
---[ end trace 6cce6761d7b505a6 ]---
Event (880160cc6618) created by task: (null)
  cpu: -1
  cgrp: (null)
  task: 12611/trinity-c19
  group: 
  attr: {
.type = 1,
.config = 0x4,
.read_format = 0x4,
.inherit = 1,
.exclusive = 1,
.exclude_hv = 1,
.exclude_idle = 1,
.comm = 1,
.task = 1,
.watermark = 1,
.precise_ip = 1,
.exclude_guest = 1,
  };
Event (8800308e6f60) created by task: (null)
  cpu: -1
  cgrp: (null)
  task: 7371/trinity-main
  group: 
  attr: {
.type = 4,
.config = 0x188688,
.read_format = 0x3,
.disabled = 1,
.inherit = 1,
.exclusive = 1,
.exclude_kernel = 1,
.exclude_hv = 1,
.mmap = 1,
.comm = 1,
.inherit_stat = 1,
  };
Event (8800308e2520) created by task: (null)
  cpu: -1
  cgrp: (null)
  task: 7371/trinity-main
  group: 
  attr: {
.config = 0x9,
.read_format = 0x3,
.inherit = 1,
.pinned = 1,
.exclude_user = 1,
.exclude_kernel = 1,
.exclude_hv = 1,
.exclude_idle = 1,
.mmap = 1,
.watermark = 1,
.mmap_data = 1,
.sample_id_all = 1,
.exclude_guest = 1,
.exclude_callchain_kernel = 1,
  };
Event (88018cc14a40) created by task: (null)
  cpu: -1
  cgrp: (null)
  task: 12579/trinity-c5
  group: 
  attr: {
.type = 1,
.sample_period = -2930868092,
.sample_type = 0x2a2cc,
.read_format = 0x3,
.disabled = 1,
.inherit = 1,
.exclude_hv = 1,
.exclude_idle = 1,
.comm = 1,
.inherit_stat = 1,
.task = 1,
.precise_ip = 3,
.mmap_data = 1,
.exclude_host = 1,
.exclude_guest = 1,
.exclude_callchain_user = 1,
.wakeup_events = 62,
.branch_sample_type = 0x7f,
  };
Event (88018cc16618) created by task: (null)
  cpu: -1
  cgrp: (null)
  task: 10057/trinity-c0
  group: 
  attr: {
.type = 4,
.config = 0x188688,
.read_format = 0x3,
.disabled = 1,
.inherit = 1,
.exclusive = 1,
.exclude_kernel = 1,
.exclude_hv = 1,
.mmap = 1,
.comm = 1,
.inherit_stat = 1,
  };
Event (88018cc1) created by task: (null)
  cpu: -1
  cgrp: (null)
  task: 10057/trinity-c0
  group: 
  attr: {
.config = 0x9,
.read_format = 0x3,
.inherit = 1,
.pinned = 1,
.exclude_user = 1,
.exclude_kernel = 1,
.exclude_hv = 1,
.exclude_idle = 1,
.mmap = 1,
.watermark = 1,
.mmap_data = 1,
.sample_id_all = 1,
.exclude_guest = 1,
.exclude_callchain_kernel = 1,
  };
Event (880160f00948) created by task: (null)
  cpu: -1
  cgrp: (null)
  task: 12579/trinity-c5
  group: 
  attr: {
.type = 4,
.config = 0x188688,
.read_format = 0x3,
.disabled = 1,
.inherit = 1,
.exclusive = 1,
.exclude_kernel = 1,
.exclude_hv = 1,
.mmap = 1,
.comm = 

[PATCH 1/3] ARM: at91: Add at91sam9rl DT SoC support

[Alexandre Belloni]

This adds preliminary DT support for the at91sam9rl.

Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/at91sam9rl.dtsi | 626 ++
 arch/arm/mach-at91/at91sam9rl.c   |  16 +
 2 files changed, 642 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91sam9rl.dtsi

diff --git a/arch/arm/boot/dts/at91sam9rl.dtsi 
b/arch/arm/boot/dts/at91sam9rl.dtsi
new file mode 100644
index ..cf67d3a553b2
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9rl.dtsi
@@ -0,0 +1,626 @@
+/*
+ * at91sam9rl.dtsi - Device Tree Include file for AT91SAM9RL family SoC
+ *
+ *  Copyright (C) 2014 Alexandre Belloni 
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include "skeleton.dtsi"
+#include 
+#include 
+#include 
+
+/ {
+   model = "Atmel AT91SAM9RL family SoC";
+   compatible = "atmel,at91sam9rl";
+   interrupt-parent = <>;
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   gpio0 = 
+   gpio1 = 
+   gpio2 = 
+   gpio3 = 
+   tcb0 = 
+   i2c0 = 
+   i2c1 = 
+   ssc0 = 
+   ssc1 = 
+   };
+   cpus {
+   #address-cells = <0>;
+   #size-cells = <0>;
+
+   cpu {
+   compatible = "arm,arm926ej-s";
+   device_type = "cpu";
+   };
+   };
+
+   memory {
+   reg = <0x2000 0x0400>;
+   };
+
+   ahb {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   apb {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   tcb0: timer@fffa {
+   compatible = "atmel,at91rm9200-tcb";
+   reg = <0xfffa 0x100>;
+   interrupts = <16 IRQ_TYPE_LEVEL_HIGH 0
+ 17 IRQ_TYPE_LEVEL_HIGH 0
+ 18 IRQ_TYPE_LEVEL_HIGH 0>;
+   };
+
+   mmc0: mmc@fffa4000 {
+   compatible = "atmel,hsmci";
+   reg = <0xfffa4000 0x600>;
+   interrupts = <10 IRQ_TYPE_LEVEL_HIGH 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   status = "disabled";
+   };
+
+   i2c0: i2c@fffa8000 {
+   compatible = "atmel,at91sam9260-i2c";
+   reg = <0xfffa8000 0x100>;
+   interrupts = <11 IRQ_TYPE_LEVEL_HIGH 6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@fffac000 {
+   compatible = "atmel,at91sam9260-i2c";
+   reg = <0xfffac000 0x100>;
+   interrupts = <12 IRQ_TYPE_LEVEL_HIGH 6>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   usart0: serial@fffb {
+   compatible = "atmel,at91sam9260-usart";
+   reg = <0xfffb 0x200>;
+   interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
+   atmel,use-dma-rx;
+   atmel,use-dma-tx;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usart0>;
+   status = "disabled";
+   };
+
+   usart1: serial@fffb4000 {
+   compatible = "atmel,at91sam9260-usart";
+   reg = <0xfffb4000 0x200>;
+   interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
+   atmel,use-dma-rx;
+   atmel,use-dma-tx;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usart1>;
+   status = "disabled";
+   };
+
+   usart2: serial@fffb8000 {
+   compatible = "atmel,at91sam9260-usart";
+   reg = <0xfffb8000 0x200>;
+  

[PATCH 2/3] ARM: at91/defconfig: Add the sam9rl to the list of DT-enabled SOCs

[Alexandre Belloni]

at91sam9rl now has a device tree, add it to the at91_dt_defconfig.

Signed-off-by: Alexandre Belloni 
---
 arch/arm/configs/at91_dt_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/at91_dt_defconfig 
b/arch/arm/configs/at91_dt_defconfig
index 690e89273230..c03f5f4c79f6 100644
--- a/arch/arm/configs/at91_dt_defconfig
+++ b/arch/arm/configs/at91_dt_defconfig
@@ -20,6 +20,7 @@ CONFIG_SOC_AT91SAM9263=y
 CONFIG_SOC_AT91SAM9G45=y
 CONFIG_SOC_AT91SAM9X5=y
 CONFIG_SOC_AT91SAM9N12=y
+CONFIG_SOC_AT91SAM9RL=y
 CONFIG_MACH_AT91RM9200_DT=y
 CONFIG_MACH_AT91SAM9_DT=y
 CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
-- 
1.8.3.2

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

[PATCH 3/3] ARM: at91: dt: sam9rl: Device Tree for the at91sam9rlek

[Alexandre Belloni]

Add a device tree for the at91sam9rl-ek. For now it supports:
 - MMC
 - dbgu
 - usart1
 - watchdog
 - nand
 - leds
 - buttons

Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/at91sam9rlek.dts | 151 +
 2 files changed, 153 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91sam9rlek.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d57c1a65b24f..bb28e65d17ee 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -28,6 +28,8 @@ dtb-$(CONFIG_ARCH_AT91) += at91sam9m10g45ek.dtb
 dtb-$(CONFIG_ARCH_AT91) += pm9g45.dtb
 # sam9n12
 dtb-$(CONFIG_ARCH_AT91) += at91sam9n12ek.dtb
+# sam9rl
+dtb-$(CONFIG_ARCH_AT91) += at91sam9rlek.dtb
 # sam9x5
 dtb-$(CONFIG_ARCH_AT91) += at91-ariag25.dtb
 dtb-$(CONFIG_ARCH_AT91) += at91sam9g15ek.dtb
diff --git a/arch/arm/boot/dts/at91sam9rlek.dts 
b/arch/arm/boot/dts/at91sam9rlek.dts
new file mode 100644
index ..5ec9589613a1
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9rlek.dts
@@ -0,0 +1,151 @@
+/*
+ * at91sam9rlek.dts - Device Tree file for Atmel at91sam9rl reference board
+ *
+ *  Copyright (C) 2014  Alexandre Belloni 

+ *
+ * Licensed under GPLv2 only
+ */
+/dts-v1/;
+#include "at91sam9rl.dtsi"
+
+/ {
+   model = "Atmel at91sam9rlek";
+   compatible = "atmel,at91sam9rlek", "atmel,at91sam9rl", "atmel,at91sam9";
+
+   chosen {
+   bootargs = "console=ttyS0,115200 rootfstype=ubifs 
root=ubi0:rootfs ubi.mtd=7 rw";
+   };
+
+   memory {
+   reg = <0x2000 0x400>;
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   main_clock: clock@0 {
+   compatible = "atmel,osc", "fixed-clock";
+   clock-frequency = <1200>;
+   };
+   };
+
+   ahb {
+   apb {
+   mmc0: mmc@fffa4000 {
+   pinctrl-0 = <
+   _board_mmc0
+   _mmc0_clk
+   _mmc0_slot0_cmd_dat0
+   _mmc0_slot0_dat1_3>;
+   status = "okay";
+   slot@0 {
+   reg = <0>;
+   bus-width = <4>;
+   cd-gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   dbgu: serial@f200 {
+   status = "okay";
+   };
+
+   usart0: serial@fffb {
+   pinctrl-0 = <
+   _usart0
+   _usart0_rts
+   _usart0_cts>;
+   status = "okay";
+   };
+
+   pinctrl@f400 {
+   mmc0 {
+   pinctrl_board_mmc0: mmc0-board {
+   atmel,pins =
+   ;
+   };
+   };
+   };
+
+   watchdog@fd40 {
+   status = "okay";
+   };
+   };
+
+   nand0: nand@4000 {
+   nand-bus-width = <8>;
+   nand-ecc-mode = "soft";
+   nand-on-flash-bbt = <1>;
+   status = "okay";
+
+   at91bootstrap@0 {
+   label = "at91bootstrap";
+   reg = <0x0 0x4>;
+   };
+
+   bootloader@4 {
+   label = "bootloader";
+   reg = <0x4 0x8>;
+   };
+
+   bootloaderenv@c {
+   label = "bootloader env";
+   reg = <0xc 0xc>;
+   };
+
+   dtb@18 {
+   label = "device tree";
+   reg = <0x18 0x8>;
+   };
+
+   kernel@20 {
+   label = "kernel";
+   reg = <0x20 0x60>;
+   };
+
+   rootfs@80 {
+   label = "rootfs";
+   reg = <0x80 0x0f80>;
+   };
+   };
+   };
+
+   leds {
+   compatible = 

[PATCH 0/3] Device tree support for the at91sam9rlek

[Alexandre Belloni]

This series adds DT support for the at91sam9rl SoC, then the at91sam9rl-ek
evaluation board.

While the at91sam9rl dtsi should be almost complete (still missing LCD and
touchscreen bits). The at91sam9rlek DT now support the following tested
features:
 - MMC
 - dbgu
 - usart1
 - watchdog
 - nand
 - leds
 - buttons

Next:
 - spi
 - dataflash
 - i2c
 - lcd
 - touchscreen
 - usb gadget
 - audio
 - common clock framework conversion

Alexandre Belloni (3):
  ARM: at91: Add at91sam9rl DT SoC support
  ARM: at91/defconfig: Add the sam9rl to the list of DT-enabled SOCs
  ARM: at91: dt: sam9rl: Device Tree for the at91sam9rlek

 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/at91sam9rl.dtsi  | 626 +
 arch/arm/boot/dts/at91sam9rlek.dts | 151 +
 arch/arm/configs/at91_dt_defconfig |   1 +
 arch/arm/mach-at91/at91sam9rl.c|  16 +
 5 files changed, 796 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91sam9rl.dtsi
 create mode 100644 arch/arm/boot/dts/at91sam9rlek.dts

-- 
1.8.3.2

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

[patch 1/2] genirq: Provide synchronize_hardirq()

[Thomas Gleixner]

synchronize_irq() waits for hard irq and threaded handlers to complete
before returning. For some special cases we only need to make sure
that the hard interrupt part of the irq line is not in progress when
we disabled the - possibly shared - interrupt at the device level.

A proper use case for this was provided by Russell. The sdhci driver
requires some irq triggered functions to be run in thread context. The
current implementation of the thread context is a sdio private kthread
construct, which has quite some shortcomings. These can be avoided
when the thread is directly associated to the device interrupt via the
generic threaded irq infrastructure.

Though there is a corner case related to run time power management
where one side disables the device interrupts at the device level and
needs to make sure, that an already running hard interrupt handler has
completed before proceeding further. Though that hard interrupt
handler might wake the associated thread, which in turn can request
the runtime PM to reenable the device. Using synchronize_irq() leads
to an immediate deadlock of the irq thread waiting for the PM lock and
the synchronize_irq() waiting for the irq thread to complete.

Due to the fact that it is sufficient for this case to ensure that no
hard irq handler is executing a new function which avoids the check
for the thread is required.

Add a function, which just monitors the hard irq parts and ignores the
threaded handlers.

Signed-off-by: Thomas Gleixner 
---
 include/linux/hardirq.h |1 
 kernel/irq/manage.c |   67 +---
 2 files changed, 48 insertions(+), 20 deletions(-)

Index: linux-2.6/include/linux/hardirq.h
===
--- linux-2.6.orig/include/linux/hardirq.h
+++ linux-2.6/include/linux/hardirq.h
@@ -9,6 +9,7 @@
 
 
 extern void synchronize_irq(unsigned int irq);
+extern void synchronize_hardirq(unsigned int irq);
 
 #if defined(CONFIG_TINY_RCU)
 
Index: linux-2.6/kernel/irq/manage.c
===
--- linux-2.6.orig/kernel/irq/manage.c
+++ linux-2.6/kernel/irq/manage.c
@@ -32,24 +32,10 @@ static int __init setup_forced_irqthread
 early_param("threadirqs", setup_forced_irqthreads);
 #endif
 
-/**
- * synchronize_irq - wait for pending IRQ handlers (on other CPUs)
- * @irq: interrupt number to wait for
- *
- * This function waits for any pending IRQ handlers for this interrupt
- * to complete before returning. If you use this function while
- * holding a resource the IRQ handler may need you will deadlock.
- *
- * This function may be called - with care - from IRQ context.
- */
-void synchronize_irq(unsigned int irq)
+static void __synchronize_hardirq(struct irq_desc *desc)
 {
-   struct irq_desc *desc = irq_to_desc(irq);
bool inprogress;
 
-   if (!desc)
-   return;
-
do {
unsigned long flags;
 
@@ -67,12 +53,53 @@ void synchronize_irq(unsigned int irq)
 
/* Oops, that failed? */
} while (inprogress);
+}
 
-   /*
-* We made sure that no hardirq handler is running. Now verify
-* that no threaded handlers are active.
-*/
-   wait_event(desc->wait_for_threads, !atomic_read(>threads_active));
+/**
+ * synchronize_hardirq - wait for pending hard IRQ handlers (on other CPUs)
+ * @irq: interrupt number to wait for
+ *
+ * This function waits for any pending hard IRQ handlers for this
+ * interrupt to complete before returning. If you use this
+ * function while holding a resource the IRQ handler may need you
+ * will deadlock. It does not take associated threaded handlers into
+ * account.
+ *
+ * This function may be called - with care - from IRQ context.
+ */
+void synchronize_hardirq(unsigned int irq)
+{
+   struct irq_desc *desc = irq_to_desc(irq);
+
+   if (desc)
+   __synchronize_hardirq(desc);
+}
+EXPORT_SYMBOL(synchronize_hardirq);
+
+/**
+ * synchronize_irq - wait for pending IRQ handlers (on other CPUs)
+ * @irq: interrupt number to wait for
+ *
+ * This function waits for any pending IRQ handlers for this interrupt
+ * to complete before returning. If you use this function while
+ * holding a resource the IRQ handler may need you will deadlock.
+ *
+ * This function may be called - with care - from IRQ context.
+ */
+void synchronize_irq(unsigned int irq)
+{
+   struct irq_desc *desc = irq_to_desc(irq);
+
+   if (desc) {
+   __synchronize_hardirq(desc);
+   /*
+* We made sure that no hardirq handler is
+* running. Now verify that no threaded handlers are
+* active.
+*/
+   wait_event(desc->wait_for_threads,
+  !atomic_read(>threads_active));
+   }
 }
 EXPORT_SYMBOL(synchronize_irq);
 

[patch 0/2] genirq: Add functions to avoid driver hackery

[Thomas Gleixner]

Russell tricked me to look into the homebrewn kthread hackery of
drivers/mmc. I'm still trying to recover from that.

But it spurred an interesting discussion how to improve things and the
outcome was the following series of patches:

1) Provide means to synchronize only hard irq context

2) Provide means to trigger a threaded irq handler from any context

The main rationale is to cleanup the mess in drivers/mmc and other
places but each of the patches has a justification for itself
exemplified by the drivers/mmc use case, which is explained in detail
in the changelogs of the individual patches.

Russell has a working implementation for sdhci which relies on patch
#1 ready and quite some ideas how to make use of #2 to kill the
sdio_irq kthread hackery.

Thanks,

tglx



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

[patch 2/2] genirq: Provide irq_wake_thread()

[Thomas Gleixner]

In course of the sdhci/sdio discussion with Russell about killing the
sdio kthread hackery we discovered the need to be able to wake an
interrupt thread from software.

The rationale for this is, that sdio hardware can lack proper
interrupt support for certain features. So the driver needs to poll
the status registers, but at the same time it needs to be woken up by
an hardware interrupt.

To be able to get rid of the home brewn kthread construct of sdio we
need a way to wake an irq thread independent of an actual hardware
interrupt.

Provide an irq_wake_thread() function which wakes up the thread which
is associated to a given dev_id. This allows sdio to invoke the irq
thread from the hardware irq handler via the IRQ_WAKE_THREAD return
value and provides a possibility to wake it via a timer for the
polling scenarios. That allows to simplify the sdio logic
significantly.

Signed-off-by: Thomas Gleixner 
---
 include/linux/interrupt.h |1 +
 kernel/irq/handle.c   |4 ++--
 kernel/irq/internals.h|1 +
 kernel/irq/manage.c   |   27 +++
 4 files changed, 31 insertions(+), 2 deletions(-)

Index: linux-2.6/include/linux/interrupt.h
===
--- linux-2.6.orig/include/linux/interrupt.h
+++ linux-2.6/include/linux/interrupt.h
@@ -183,6 +183,7 @@ extern void disable_irq(unsigned int irq
 extern void disable_percpu_irq(unsigned int irq);
 extern void enable_irq(unsigned int irq);
 extern void enable_percpu_irq(unsigned int irq, unsigned int type);
+extern void irq_wake_thread(unsigned int irq, void *dev_id);
 
 /* The following three functions are for the core kernel use only. */
 extern void suspend_device_irqs(void);
Index: linux-2.6/kernel/irq/handle.c
===
--- linux-2.6.orig/kernel/irq/handle.c
+++ linux-2.6/kernel/irq/handle.c
@@ -51,7 +51,7 @@ static void warn_no_thread(unsigned int
   "but no thread function available.", irq, action->name);
 }
 
-static void irq_wake_thread(struct irq_desc *desc, struct irqaction *action)
+void __irq_wake_thread(struct irq_desc *desc, struct irqaction *action)
 {
/*
 * In case the thread crashed and was killed we just pretend that
@@ -157,7 +157,7 @@ handle_irq_event_percpu(struct irq_desc
break;
}
 
-   irq_wake_thread(desc, action);
+   __irq_wake_thread(desc, action);
 
/* Fall through to add to randomness */
case IRQ_HANDLED:
Index: linux-2.6/kernel/irq/internals.h
===
--- linux-2.6.orig/kernel/irq/internals.h
+++ linux-2.6/kernel/irq/internals.h
@@ -82,6 +82,7 @@ irqreturn_t handle_irq_event(struct irq_
 /* Resending of interrupts :*/
 void check_irq_resend(struct irq_desc *desc, unsigned int irq);
 bool irq_wait_for_poll(struct irq_desc *desc);
+void __irq_wake_thread(struct irq_desc *desc, struct irqaction *action);
 
 #ifdef CONFIG_PROC_FS
 extern void register_irq_proc(unsigned int irq, struct irq_desc *desc);
Index: linux-2.6/kernel/irq/manage.c
===
--- linux-2.6.orig/kernel/irq/manage.c
+++ linux-2.6/kernel/irq/manage.c
@@ -908,6 +908,33 @@ static int irq_thread(void *data)
return 0;
 }
 
+/**
+ * irq_wake_thread - wake the irq thread for the action identified by 
dev_id
+ * @irq:   Interrupt line
+ * @dev_id:Device identity for which the thread should be woken
+ *
+ */
+void irq_wake_thread(unsigned int irq, void *dev_id)
+{
+   struct irq_desc *desc = irq_to_desc(irq);
+   struct irqaction *action;
+   unsigned long flags;
+
+   if (!desc || WARN_ON(irq_settings_is_per_cpu_devid(desc)))
+   return;
+
+   raw_spin_lock_irqsave(>lock, flags);
+   for (action = desc->action; action; action = action->next) {
+   if (action->dev_id == dev_id) {
+   if (action->thread)
+   __irq_wake_thread(desc, action);
+   break;
+   }
+   }
+   raw_spin_unlock_irqrestore(>lock, flags);
+}
+EXPORT_SYMBOL_GPL(irq_wake_thread);
+
 static void irq_setup_forced_threading(struct irqaction *new)
 {
if (!force_irqthreads)


--
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] ACPI, PCI, ISA: Call ISA-specific code only for architectures which support ISA.

[Rafael J. Wysocki]

On Monday, February 10, 2014 02:00:10 PM Tomasz Nowicki wrote:
> This commit enables ISA-specific code if and only if CONFIG_{E}ISA is set
> in the kernel configuration so that we do not have to maintain
> acpi_isa_irq_to_gsi() function for architectures which do not support ISA.
> 
> Signed-off-by: Tomasz Nowicki 
> ---
>  drivers/acpi/pci_irq.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
> index 41c5e1b..b0e31b6 100644
> --- a/drivers/acpi/pci_irq.c
> +++ b/drivers/acpi/pci_irq.c
> @@ -418,6 +418,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
>* driver reported one, then use it. Exit in any case.
>*/
>   if (gsi < 0) {
> +#if IS_ENABLED(CONFIG_ISA) || IS_ENABLED(CONFIG_EISA)

Can you please move the code in question into a separate function and make
that function depend on the above (with an empty stub for when they are not
enabled)?

>   u32 dev_gsi;
>   /* Interrupt Line values above 0xF are forbidden */
>   if (dev->irq > 0 && (dev->irq <= 0xF) &&
> @@ -427,10 +428,9 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
>   acpi_register_gsi(>dev, dev_gsi,
> ACPI_LEVEL_SENSITIVE,
> ACPI_ACTIVE_LOW);
> - } else {
> - dev_warn(>dev, "PCI INT %c: no GSI\n",
> -  pin_name(pin));
> - }
> + } else
> +#endif
> + dev_warn(>dev, "PCI INT %c: no GSI\n", pin_name(pin));
>  
>   return 0;
>   }
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] perf, nmi: fix unknown NMI warning

[Andi Kleen]

From: Markus Metzger 

[From Markus, just sending for him because he had problems with his mail]

When using BTS on Core i7-4*, I get the below kernel warning.

$ perf record -c 1 -e branches:u ls
Message from syslogd@labpc1501 at Nov 11 15:49:25 ...
 kernel:[  438.317893] Uhhuh. NMI received for unknown reason 31 on CPU 2.

Message from syslogd@labpc1501 at Nov 11 15:49:25 ...
 kernel:[  438.317920] Do you have a strange power saving mode enabled?

Message from syslogd@labpc1501 at Nov 11 15:49:25 ...
 kernel:[  438.317945] Dazed and confused, but trying to continue

Make intel_pmu_handle_irq() take the full exit path when returning early.

Signed-off-by: Markus Metzger 
Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/cpu/perf_event_intel.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index 0fa4f24..698ae77 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1361,10 +1361,8 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
intel_pmu_disable_all();
handled = intel_pmu_drain_bts_buffer();
status = intel_pmu_get_status();
-   if (!status) {
-   intel_pmu_enable_all(0);
-   return handled;
-   }
+   if (!status)
+   goto done;
 
loops = 0;
 again:
-- 
1.8.5.3

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

Re: [PATCH] ACPI, APEI: Remove X86 redundant dependency for APEI Generic Hardware Error Source.

[Rafael J. Wysocki]

On Monday, February 10, 2014 05:23:36 PM Tomasz Nowicki wrote:
> ACPI_APEI is already dependent on X86, hence, there is no need to
> define such dependency for ACPI_APEI_GHES again.
> 
> Signed-off-by: Tomasz Nowicki 

Tony, Boris, if you're fine with this, I'll take it for 3.15.

> ---
>  drivers/acpi/apei/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
> index 786294b..1d7ca6e 100644
> --- a/drivers/acpi/apei/Kconfig
> +++ b/drivers/acpi/apei/Kconfig
> @@ -13,7 +13,7 @@ config ACPI_APEI
>  
>  config ACPI_APEI_GHES
>   bool "APEI Generic Hardware Error Source"
> - depends on ACPI_APEI && X86
> + depends on ACPI_APEI
>   select ACPI_HED
>   select IRQ_WORK
>   select GENERIC_ALLOCATOR
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] ACPI / dock: Make 'docked' sysfs attribute work as documented

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

After recent ACPI core changes acpi_bus_get_device() will always
succeed for dock station ACPI device objects, so show_docked()
should not use that function's return value as an indicator of
whether or not the dock device is present.

Make it use acpi_device_enumerated() for this purpose.

Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes 
in the namespace)
Signed-off-by: Rafael J. Wysocki 
---

3.14 material overlooked previously.

And I actually was able to test this one some. :-)

Thanks,
Rafael

---
 drivers/acpi/dock.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/acpi/dock.c
===
--- linux-pm.orig/drivers/acpi/dock.c
+++ linux-pm/drivers/acpi/dock.c
@@ -713,13 +713,11 @@ static acpi_status __init find_dock_devi
 static ssize_t show_docked(struct device *dev,
   struct device_attribute *attr, char *buf)
 {
-   struct acpi_device *tmp;
-
struct dock_station *dock_station = dev->platform_data;
+   struct acpi_device *adev = NULL;
 
-   if (!acpi_bus_get_device(dock_station->handle, ))
-   return snprintf(buf, PAGE_SIZE, "1\n");
-   return snprintf(buf, PAGE_SIZE, "0\n");
+   acpi_bus_get_device(dock_station->handle, );
+   return snprintf(buf, PAGE_SIZE, "%u\n", acpi_device_enumerated(adev));
 }
 static DEVICE_ATTR(docked, S_IRUGO, show_docked, NULL);
 

--
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/9] slab: makes clear_obj_pfmemalloc() just return store masked value

[Christoph Lameter]

On Fri, 14 Feb 2014, David Rientjes wrote:

> Yeah, you don't need it, but don't you think it makes the code more
> readable?  Otherwise this is going to be just doing
>
>   return (unsigned long)objp & ~SLAB_OBJ_PFMEMALLOC;
>
> and you gotta figure out the function type to understand it's returned as

Isnt there something like PTR_ALIGN() for this case that would make it
more readable?

--
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 10/11] powerpc/perf: add kconfig option for hypervisor provided counters

[Cody P Schafer]

On Fri, Feb 14, 2014 at 04:32:13PM -0600, Scott Wood wrote:
> On Fri, 2014-02-14 at 14:02 -0800, Cody P Schafer wrote:
> > Signed-off-by: Cody P Schafer 
> > ---
> >  arch/powerpc/perf/Makefile | 2 ++
> >  arch/powerpc/platforms/Kconfig.cputype | 6 ++
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
> > index 60d71ee..f9c083a 100644
> > --- a/arch/powerpc/perf/Makefile
> > +++ b/arch/powerpc/perf/Makefile
> > @@ -11,5 +11,7 @@ obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
> >  obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
> >  obj-$(CONFIG_FSL_EMB_PERF_EVENT_E500) += e500-pmu.o e6500-pmu.o
> >  
> > +obj-$(CONFIG_HV_PERF_CTRS) += hv-24x7.o hv-gpci.o hv-common.o
> > +
> >  obj-$(CONFIG_PPC64)+= $(obj64-y)
> >  obj-$(CONFIG_PPC32)+= $(obj32-y)
> > diff --git a/arch/powerpc/platforms/Kconfig.cputype 
> > b/arch/powerpc/platforms/Kconfig.cputype
> > index 434fda3..dcc67cd 100644
> > --- a/arch/powerpc/platforms/Kconfig.cputype
> > +++ b/arch/powerpc/platforms/Kconfig.cputype
> > @@ -364,6 +364,12 @@ config PPC_PERF_CTRS
> > help
> >   This enables the powerpc-specific perf_event back-end.
> >  
> > +config HV_PERF_CTRS
> > +   def_bool y
> > +   depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT
> > +   help
> > + Enable access to perf counters provided by the hypervisor
> 
> Please don't add default-y stuff that is platform-specific, and
> definitely point out that platform dependency in the config description
> -- I have to look elsewhere in the patchset to determine that this is
> for "Power Hypervisor".  PPC_HAVE_PMU_SUPPORT is enabled by all 6xx
> builds, even for hardware like e300 that doesn't have PMU at all (it has
> the FSL embedded perfmon instead), much less this hv interface.
> 
> And yes, PPC_PERF_CTRS has the same problem and should be fixed. :-)

Yep, I just based this one on what PPC_PERF_CTRS was doing.

How about the following:

+config HV_PERF_CTRS
+   bool "Perf Hypervisor supplied counters"
+   default y
+   depends on PERF_EVENTS && PPC_HAVE_PMU_SUPPORT && PPC_PSERIES
+   help
+ Enable access to hypervisor supplied counters in perf. Currently,
+ this enables code that uses the hcall GetPerfCounterInfo and 24x7
+ interfaces to retrieve counters. GPCI exists on Power 6 and later
+ systems. 24x7 is available on Power 8 systems.
+
+  If unsure, select Y.

And relocated to arch/powerpc/platforms/Kconfig (as this isn't really
strictly "cputype" related).

--
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: Loseing my patience with libata and sata_nv

[Larry Finger]

On 02/14/2014 12:42 PM, Randy Dunlap wrote:

On 02/14/2014 08:31 AM, Gene Heskett wrote:

Which is required for my $290 ASUS M2n-SLI Deluxe motherboard to boot.

Not finding the option in any kernel tree that exists on my system,
except it appears its been replaced or something.

This once in a lifetime boot, to 3.12.9, shows from an lsmod:
libata146855  2 sata_nv,pata_amd
scsi_mod  153579  4 sr_mod,sg,sd_mod,libata

I haven't a clue how I got it in this boot, and I built it.  And
apparently a make oldconfig, carefully done by hand (takes about an hour
30 to do) is not capable of adding it to a .config BECAUSE it does NOT
exist in any of the arch/x86/configs/i386_defconfig's present on this machine.


It does not have to exist in any defconfig.  Those are just default config files
and SATA_NV is not enabled by default, but you can still enable it.


Here is how I searched:

gene@coyote:~/src/linux-3.0.69$ grep SATA_NV arch/x86/configs/i386_defconfig
gene@coyote:~/src/linux-3.0.69$ cd ../linux-3.2.40
gene@coyote:~/src/linux-3.2.40$ grep SATA_NV arch/x86/configs/i386_defconfig
gene@coyote:~/src/linux-3.2.40$ cd ../linux-3.4.36
gene@coyote:~/src/linux-3.4.36$ grep SATA_NV arch/x86/configs/i386_defconfig
gene@coyote:~/src/linux-3.4.36$ cd ../linux-3.8.2
gene@coyote:~/src/linux-3.8.2$ grep SATA_NV arch/x86/configs/i386_defconfig
gene@coyote:~/src/linux-3.8.2$ cd ../linux-3.8.3
gene@coyote:~/src/linux-3.8.3$ grep SATA_NV arch/x86/configs/i386_defconfig
gene@coyote:~/src/linux-3.8.3$ cd ../linux-3.12.0
gene@coyote:~/src/linux-3.12.0$ grep SATA_NV arch/x86/configs/i386_defconfig
gene@coyote:~/src/linux-3.12.0$ cd ../linux-3.12.6
gene@coyote:~/src/linux-3.12.6$ grep SATA_NV arch/x86/configs/i386_defconfig
gene@coyote:~/src/linux-3.12.6$ cd ../linux-3.12.9
gene@coyote:~/src/linux-3.12.9$ grep SATA_NV arch/x86/configs/i386_defconfig
gene@coyote:~/src/linux-3.12.9$ cd ../linux-3.13.1
gene@coyote:~/src/linux-3.13.1$ grep SATA_NV arch/x86/configs/i386_defconfig
gene@coyote:~/src/linux-3.13.1$ cd ../linux-3.13.2
gene@coyote:~/src/linux-3.13.2$ grep SATA_NV arch/x86/configs/i386_defconfig
gene@coyote:~/src/linux-3.13.2$

I've been fighting with this, intermittently for about 6 months.  Except
for this 3.12.9 where I must have been holding my mouth right, all the
rest are boot failures because it can't find the boot drive with so-and-so
for a UUID. sata_nv is on the missing list, even in this WORKing boots 
defconfig.
"Working" however is a miss-statement, no multimedia stuff was built.

There has to be a rule I am violating, but even with Randy's D's help, it is
not becoming obvious.  FWIW libata references also can't be found, but as
can be seen, its in memory right now.


libata is built whenever CONFIG_ATA is enabled.



So please guys, what is the magic dependency that causes libata and
sata_nv to be included in a .config?


The SATA_NV kconfig symbol depends on (requires) the following other kconfig
symbols to be enabled:
ATA_SFF and ATA_BMDMA and PCI and ATA

If those are not enabled, then you will need to use 'make config' to
enabled them before you can enable SATA_NV.


Gene,

Your CONFIG indicates that you are building both libata and sata_nv. Perhaps you 
are not including them in your initrd, or whatever it is called in your distro. 
That makes them unavailable at boot time due to the chicken-and-egg problem. You 
need those drivers to access the drive, but that is where they reside. An easy 
way might be to make those two drivers be built in rather than as modules.


Larry


--
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 0/7] cpufreq: suspend early/resume late: dpm_{suspend|resume}()

[Stephen Warren]

On 02/14/2014 03:23 PM, Rafael J. Wysocki wrote:
> On Friday, February 14, 2014 12:42:53 PM Stephen Warren wrote:
>> On 02/12/2014 11:50 PM, Viresh Kumar wrote:
>>> This patchset creates/calls cpufreq suspend/resume callbacks from 
>>> dpm_{suspend|resume}()
>>> for handling suspend/resume of cpufreq governors and core.
>>
>> Are these patches for 3.14 or 3.15?
> 
> I don't think they are suitable for 3.14, honestly.
> 
>> I ask because I just tested Linus's master from a few days back (some
>> point after v3.14-rc2; commit 9398a10cd964 Merge tag
>> 'regulator-v3.14-rc2'), and I see a lot of the following messages during
>> suspend and/or resume (about 2-7 times, perhaps more of them from the
>> resume path, but it's hard to tell):
>>
>> cpufreq: __cpufreq_driver_target: Failed to change cpu frequency: -16
>>
>> This series does appear to solve those, so I think at least part of it
>> needs to be applied for 3.14.
> 
> Well, it would be good to verify which part, then.

Patch 2/7 appears to stop that message from being printed during
suspend, and perhaps reduce the number of times it's printed during
resume. Patch 7/7 stops the message being printed at all.

Looking at patch 7, I wonder if it's simply because tegra_target() was
modified never to return -EBUSY, so the bug is still there, but it's
just been hidden.

>> Also, I sometimes see the following during resume. I saw it twice with
>> Linus's tree, but then I did 10 more reboot+suspend+resume cycles and
>> couldn't repro it, and I saw it once with Linus's tree plus this series
>> applied, then couldn't reproduce it in 5 more tries.

Oops. I screwed up my re-testing (tested on the wrong board, without
cpufreq active:-/). The message below is reproducible 100% of the time
with or without this series.

>>> [ 48.500410] [ cut here ]
>>> [ 48.505252] WARNING: CPU: 0 PID: 877 at fs/sysfs/dir.c:52 
>>> sysfs_warn_dup+0x68/0x84()
>>> [ 48.513005] sysfs: cannot create duplicate filename 
>>> '/devices/system/cpu/cpu1/cpufreq'
>>> [ 48.520995] Modules linked in: brcmfmac brcmutil
>>> [ 48.525740] CPU: 0 PID: 877 Comm: test-rtc-resume Not tainted 
>>> 3.14.0-rc2-00259-g9398a10cd964 #12
...
>>> [ 48.575024] [] (sysfs_warn_dup) from [] 
>>> (sysfs_do_create_link_sd+0xb0/0xb8)
>>> [ 48.583772] [] (sysfs_do_create_link_sd) from [] 
>>> (__cpufreq_add_dev.isra.27+0x2a8/0x814)
>>> [ 48.593701] [] (__cpufreq_add_dev.isra.27) from [] 
>>> (cpufreq_cpu_callback+0x70/0x8c)
>>> [ 48.603198] [] (cpufreq_cpu_callback) from [] 
>>> (notifier_call_chain+0x44/0x84)
>>> [ 48.612166] [] (notifier_call_chain) from [] 
>>> (__cpu_notify+0x28/0x44)
>>> [ 48.620424] [] (__cpu_notify) from [] 
>>> (_cpu_up+0xf0/0x140)
>>> [ 48.627748] [] (_cpu_up) from [] 
>>> (enable_nonboot_cpus+0x68/0xb0)
>>> [ 48.635579] [] (enable_nonboot_cpus) from [] 
>>> (suspend_devices_and_enter+0x198/0x2dc)
--
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] lkdtm: include cacheflush.h

[Kees Cook]

Some architectures need cacheflush.h explicitly included (mips) for
use of flush_icache_range():

config: make ARCH=mips allmodconfig
All error/warnings:
>> ERROR: "flush_icache_range" undefined!

Reported-by: Fengguang Wu 
Signed-off-by: Kees Cook 
---
 drivers/misc/lkdtm.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
index 47ed2d321351..2ebd52e05773 100644
--- a/drivers/misc/lkdtm.c
+++ b/drivers/misc/lkdtm.c
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_IDE
 #include 
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security
--
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 v9] PM / Hibernate: use name_to_dev_t to parse resume

[Pavel Machek]

Hi!

> Use the name_to_dev_t call to parse the device name echo'd to
> to /sys/power/resume.  This imitates the method used in hibernate.c
> in software_resume, and allows the resume partition to be specified
> using other equivalent device formats as well.  By allowing
> /sys/debug/resume to accept the same syntax as the resume=device
> parameter, we can parse the resume=device in the init script and
> use the resume device directly from the kernel command line.
> 
> Signed-off-by: Sebastian Capella 
> Cc: Len Brown 
> Cc: Pavel Machek 
> Cc: "Rafael J. Wysocki" 

Acked-by: Pavel Machek 

> @@ -972,16 +972,20 @@ static ssize_t resume_show(struct kobject *kobj, struct 
> kobj_attribute *attr,
>  static ssize_t resume_store(struct kobject *kobj, struct kobj_attribute 
> *attr,
>   const char *buf, size_t n)
>  {
> - unsigned int maj, min;
>   dev_t res;
> - int ret = -EINVAL;
> + int len = n;
> + char *name;
>  
> - if (sscanf(buf, "%u:%u", , ) != 2)
> - goto out;
> + if (len && buf[len-1] == '\n')
> + len--;
> + name = kstrndup(buf, len, GFP_KERNEL);
> + if (!name)
> + return -ENOMEM;

And yes, it seems to do right thing even if "\n" is passed to it.

> - res = MKDEV(maj,min);
> - if (maj != MAJOR(res) || min != MINOR(res))
> - goto out;
> + res = name_to_dev_t(name);
> + kfree(name);

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] Documentation/SubmittingPatches: Reported-by tags and permission

[Randy Dunlap]

On 02/14/2014 01:30 AM, Dan Carpenter wrote:
> The reported-by text says you have to ask for permission, but that's
> only if the bug was reported in private.  These days the standard is to
> always give reported-by credit or it's considered a bit rude.
> 
> Signed-off-by: Dan Carpenter 

Acked-by: Randy Dunlap 

Thanks.

> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index 26b1e31d5a13..f72ce7803b71 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -432,12 +432,9 @@ have been included in the discussion
>  
>  14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
>  
> -If this patch fixes a problem reported by somebody else, consider adding a
> -Reported-by: tag to credit the reporter for their contribution.  Please
> -note that this tag should not be added without the reporter's permission,
> -especially if the problem was not reported in a public forum.  That said,
> -if we diligently credit our bug reporters, they will, hopefully, be
> -inspired to help us again in the future.
> +The Reported-by tag is to give credit to people who find bugs and report 
> them.
> +Please note that if the bug was reported in private, then ask for permission
> +first before using the Reported-by tag.
>  
>  A Tested-by: tag indicates that the patch has been successfully tested (in
>  some environment) by the person named.  This tag informs maintainers that
> --


-- 
~Randy
--
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 dmaengine-fixes 1/1] dmaengine: read completed cookie before used cookie

[Siva Yerramreddy]

When running dmatest with my yet-to-be submitted driver for the Intel MIC DMA
engine, dmatest detected "dma0chan3-copy5: result #8096161:completion busy
status with src_off=0x0 dst_off=0x0 len=0x40 (0)". This is caused by reading
the used cookie before the completed cookie in dma_cookie_status(),  if a DMA
request is submitted in between the two reads, and completes,  the completed
cookie will be newer than the used cookie value read previously.  Reversing
the order of reads ensures that the completed cookie is for a DMA request
older than the used cookie.

Reviewed-by: Ashutosh Dixit 
Reviewed-by: Sudeep Dutt 
Reviewed-by: Nikhil Rao 
Signed-off-by: Siva Yerramreddy 
---
 drivers/dma/dmaengine.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
index 17f983a..4c96892 100644
--- a/drivers/dma/dmaengine.h
+++ b/drivers/dma/dmaengine.h
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 
 /**
  * dma_cookie_init - initialize the cookies for a DMA channel
@@ -69,8 +70,13 @@ static inline enum dma_status dma_cookie_status(struct 
dma_chan *chan,
 {
dma_cookie_t used, complete;
 
-   used = chan->cookie;
complete = chan->completed_cookie;
+   /*
+* If this order is not maintained, used can end up being older than
+* complete
+*/
+   smp_rmb();
+   used = chan->cookie;
barrier();
if (state) {
state->last = complete;
-- 
1.8.2.2

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

Re: [PATCH] tracing: Allow instances to have independent trace flags/trace options.

[Bharath Ravi]

Hi Steven,

What are your thoughts on this patch?
--
Bharath Ravi |  rbhar...@google.com


On Thu, Jan 23, 2014 at 11:46 AM, Bharath Ravi  wrote:
> Hi Steven,
>
> This patch allows instances to have their own independent trace
> options (as opposed to the current globally shared trace options)
>
> Does this look like a reasonable change?
> Bharath Ravi |  rbhar...@google.com
>
>
> On Fri, Nov 22, 2013 at 10:51 AM, Bharath Ravi  wrote:
>> Currently, the trace options are global, and shared among all
>> instances. This change divides the set of trace options into global
>> options and instance specific options. Instance specific options may be
>> set independently by an instance without affecting either the global
>> tracer or other instances. Global options are viewable and modifiable
>> only from the global tracer, preventing tracers from modifying shared
>> flags.
>>
>> Currently, only the "overwrite" flag is a per-instance flag. Others may
>> be supported as and when instances are modified to support more tracers.
>>
>> As a side-effect, the global trace_flags variable is replaced by
>> instance specific trace_flags in trace_array. References to the old
>> global flags variable are replaced with accessors to the global_tracer's
>> trace_flags.
>>
>> Signed-off-by: Bharath Ravi 
>> ---
>>  kernel/trace/blktrace.c  |   5 +-
>>  kernel/trace/ftrace.c|   4 +-
>>  kernel/trace/trace.c | 131 
>> +--
>>  kernel/trace/trace.h |  51 +++---
>>  kernel/trace/trace_events.c  |   2 +-
>>  kernel/trace/trace_functions_graph.c |  10 +--
>>  kernel/trace/trace_irqsoff.c |   3 +-
>>  kernel/trace/trace_kdb.c |   6 +-
>>  kernel/trace/trace_output.c  |   8 +--
>>  kernel/trace/trace_printk.c  |   8 +--
>>  kernel/trace/trace_sched_wakeup.c|   3 +-
>>  kernel/trace/trace_syscalls.c|   2 +-
>>  12 files changed, 149 insertions(+), 84 deletions(-)
>>
>> diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
>> index b8b8560..0d71009 100644
>> --- a/kernel/trace/blktrace.c
>> +++ b/kernel/trace/blktrace.c
>> @@ -1350,7 +1350,7 @@ static enum print_line_t print_one_line(struct 
>> trace_iterator *iter,
>>
>> t  = te_blk_io_trace(iter->ent);
>> what   = t->action & ((1 << BLK_TC_SHIFT) - 1);
>> -   long_act   = !!(trace_flags & TRACE_ITER_VERBOSE);
>> +   long_act   = !!(global_trace_flags() & TRACE_ITER_VERBOSE);
>> log_action = classic ? _log_action_classic : _log_action;
>>
>> if (t->action == BLK_TN_MESSAGE) {
>> @@ -1411,12 +1411,15 @@ static enum print_line_t 
>> blk_tracer_print_line(struct trace_iterator *iter)
>>
>>  static int blk_tracer_set_flag(u32 old_flags, u32 bit, int set)
>>  {
>> +   unsigned long trace_flags = global_trace_flags();
>> /* don't output context-info for blk_classic output */
>> if (bit == TRACE_BLK_OPT_CLASSIC) {
>> if (set)
>> trace_flags &= ~TRACE_ITER_CONTEXT_INFO;
>> else
>> trace_flags |= TRACE_ITER_CONTEXT_INFO;
>> +
>> +   set_global_trace_flags(trace_flags);
>> }
>> return 0;
>>  }
>> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
>> index 03cf44a..c356d5d 100644
>> --- a/kernel/trace/ftrace.c
>> +++ b/kernel/trace/ftrace.c
>> @@ -911,7 +911,7 @@ static void profile_graph_return(struct ftrace_graph_ret 
>> *trace)
>>
>> calltime = trace->rettime - trace->calltime;
>>
>> -   if (!(trace_flags & TRACE_ITER_GRAPH_TIME)) {
>> +   if (!(global_trace_flags() & TRACE_ITER_GRAPH_TIME)) {
>> int index;
>>
>> index = trace->depth;
>> @@ -4836,7 +4836,7 @@ ftrace_graph_probe_sched_switch(void *ignore,
>>  * Does the user want to count the time a function was asleep.
>>  * If so, do not update the time stamps.
>>  */
>> -   if (trace_flags & TRACE_ITER_SLEEP_TIME)
>> +   if (global_trace_flags() & TRACE_ITER_SLEEP_TIME)
>> return;
>>
>> timestamp = trace_clock_local();
>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>> index 7974ba2..7add8bc 100644
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -386,11 +386,16 @@ static inline void trace_access_lock_init(void)
>>
>>  #endif
>>
>> -/* trace_flags holds trace_options default values */
>> -unsigned long trace_flags = TRACE_ITER_PRINT_PARENT | TRACE_ITER_PRINTK |
>> -   TRACE_ITER_ANNOTATE | TRACE_ITER_CONTEXT_INFO | 
>> TRACE_ITER_SLEEP_TIME |
>> -   TRACE_ITER_GRAPH_TIME | TRACE_ITER_RECORD_CMD | TRACE_ITER_OVERWRITE 
>> |
>> -   TRACE_ITER_IRQ_INFO | TRACE_ITER_MARKERS | TRACE_ITER_FUNCTION;
>> +/* Sets default values for a tracer's trace_options */
>> +static inline void init_trace_flags(unsigned long *trace_flags)
>> +{
>> +   *trace_flags = 

Re: [PATCH v2] tracing: Allow changing default ring buffer size for ftrace instances.

[Bharath Ravi]

Hi Steven,

Does this version of the patch look reasonable?
--
Bharath Ravi |  rbhar...@google.com


On Thu, Jan 23, 2014 at 11:37 AM, Bharath Ravi  wrote:
>
> It is often memory efficient to start instances off with a smaller ring
> buffer size than the current default. This is particularly true on
> systems with many cores, or when multiple ftrace instances are created,
> where the current (higher) default value results in allocation failures.
>
> The global trace buffer allows initialization with a minimal (1 byte)
> size, to save memory using a "ring_buffer_expanded" flag. To allow
> instances a similar capability, trace option named "expand-new-buffers"
> is added. If set to true, ftrace instances created will be initialized
> with ring buffers of the default size. If set to false, the buffers will
> be initialized with a size of 1 byte. By default, the expand_new_buffers
> flag is true.
>
> Tested: Booted into a kernel with these changes, verified reading and
> writing the new trace_option. Ensured that new ftrace instances created
> used the appropriate size while initializing their ring buffers.
>
> Signed-off-by: Bharath Ravi 
> ---
>  kernel/trace/trace.c | 13 ++---
>  kernel/trace/trace.h |  1 +
>  2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 9d20cd9..c17c12f 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -410,7 +410,8 @@ static inline void trace_access_lock_init(void)
>  unsigned long trace_flags = TRACE_ITER_PRINT_PARENT | TRACE_ITER_PRINTK |
> TRACE_ITER_ANNOTATE | TRACE_ITER_CONTEXT_INFO | TRACE_ITER_SLEEP_TIME 
> |
> TRACE_ITER_GRAPH_TIME | TRACE_ITER_RECORD_CMD | TRACE_ITER_OVERWRITE |
> -   TRACE_ITER_IRQ_INFO | TRACE_ITER_MARKERS | TRACE_ITER_FUNCTION;
> +   TRACE_ITER_IRQ_INFO | TRACE_ITER_MARKERS | TRACE_ITER_FUNCTION |
> +   TRACE_EXPAND_NEW_BUFFERS;
>
>  static void tracer_tracing_on(struct trace_array *tr)
>  {
> @@ -753,6 +754,7 @@ static const char *trace_options[] = {
> "irq-info",
> "markers",
> "function-trace",
> +   "expand-new-buffers",
> NULL
>  };
>
> @@ -5930,7 +5932,7 @@ static int allocate_trace_buffers(struct trace_array 
> *tr, int size)
>  static int new_instance_create(const char *name)
>  {
> struct trace_array *tr;
> -   int ret;
> +   int ret, ring_buffer_size;
>
> mutex_lock(_types_lock);
>
> @@ -5961,7 +5963,12 @@ static int new_instance_create(const char *name)
> INIT_LIST_HEAD(>systems);
> INIT_LIST_HEAD(>events);
>
> -   if (allocate_trace_buffers(tr, trace_buf_size) < 0)
> +   /* allocate memory only if buffers are to be expanded */
> +   if (trace_flags & TRACE_EXPAND_NEW_BUFFERS)
> +   ring_buffer_size = trace_buf_size;
> +   else
> +   ring_buffer_size = 1
> +   if (allocate_trace_buffers(tr, ring_buffer_size) < 0)
> goto out_free_tr;
>
> tr->dir = debugfs_create_dir(name, trace_instance_dir);
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index ea189e0..15ddbf4 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -888,6 +888,7 @@ enum trace_iterator_flags {
> TRACE_ITER_IRQ_INFO = 0x80,
> TRACE_ITER_MARKERS  = 0x100,
> TRACE_ITER_FUNCTION = 0x200,
> +   TRACE_EXPAND_NEW_BUFFERS= 0x400,
>  };
>
>  /*
> --
> 1.8.5.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] rcu: move SRCU grace period work to power efficient workqueue

[Kevin Hilman]

Tejun Heo  writes:

> Hello,
>
> On Wed, Feb 12, 2014 at 11:02:41AM -0800, Paul E. McKenney wrote:
>> +2.  Use the /sys/devices/virtual/workqueue/*/cpumask sysfs files
>> +to force the WQ_SYSFS workqueues to run on the specified set
>> +of CPUs.  The set of WQ_SYSFS workqueues can be displayed using
>> +"ls sys/devices/virtual/workqueue".
>
> One thing to be careful about is that once published, it becomes part
> of userland visible interface.  Maybe adding some words warning
> against sprinkling WQ_SYSFS willy-nilly is a good idea?

In the NO_HZ_FULL case, it seems to me we'd always want all unbound
workqueues to have their affinity set to the housekeeping CPUs.

Is there any reason not to enable WQ_SYSFS whenever WQ_UNBOUND is set so
the affinity can be controlled?  I guess the main reason would be that 
all of these workqueue names would become permanent ABI.

At least for NO_HZ_FULL, maybe this should be automatic.  The cpumask of
unbound workqueues should default to !tick_nohz_full_mask?  Any WQ_SYSFS
workqueues could still be overridden from userspace, but at least the
default would be sane, and help keep full dyntics CPUs isolated.

Example patch below, only boot tested on 4-CPU ARM system with
CONFIG_NO_HZ_FULL_ALL=y and verified that 'cat
/sys/devices/virtual/workqueue/writeback/cpumask' looked sane.  If this
looks OK, I can maybe clean it up a bit and make it runtime check
instead of a compile time check.

Kevin



>From 902a2b58d61a51415457ea6768d687cdb7532eff Mon Sep 17 00:00:00 2001
From: Kevin Hilman 
Date: Fri, 14 Feb 2014 15:10:58 -0800
Subject: [PATCH] workqueue: for NO_HZ_FULL, set default cpumask to
 !tick_nohz_full_mask

To help in keeping NO_HZ_FULL CPUs isolated, keep unbound workqueues
from running on full dynticks CPUs.  To do this, set the default
workqueue cpumask to be the set of "housekeeping" CPUs instead of all
possible CPUs.

This is just just the starting/default cpumask, and can be overridden
with all the normal ways (NUMA settings, apply_workqueue_attrs and via
sysfs for workqueus with the WQ_SYSFS attribute.)

Cc: Tejun Heo 
Cc: Paul McKenney 
Cc: Frederic Weisbecker 
Signed-off-by: Kevin Hilman 
---
 kernel/workqueue.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 987293d03ebc..9a9d9b0eaf6d 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -48,6 +48,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "workqueue_internal.h"
 
@@ -3436,7 +3437,11 @@ struct workqueue_attrs *alloc_workqueue_attrs(gfp_t 
gfp_mask)
if (!alloc_cpumask_var(>cpumask, gfp_mask))
goto fail;
 
+#ifdef CONFIG_NO_HZ_FULL
+   cpumask_complement(attrs->cpumask, tick_nohz_full_mask);
+#else
cpumask_copy(attrs->cpumask, cpu_possible_mask);
+#endif
return attrs;
 fail:
free_workqueue_attrs(attrs);
-- 
1.8.3

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

Re: [PATCH 3/9] slab: move up code to get kmem_cache_node in free_block()

[David Rientjes]

On Fri, 14 Feb 2014, Joonsoo Kim wrote:

> node isn't changed, so we don't need to retreive this structure
> everytime we move the object. Maybe compiler do this optimization,
> but making it explicitly is better.
> 

Would it be possible to make it const struct kmem_cache_node *n then?
--
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/9] slab: makes clear_obj_pfmemalloc() just return store masked value

[David Rientjes]

On Fri, 14 Feb 2014, Christoph Lameter wrote:

> > @@ -215,9 +215,9 @@ static inline void set_obj_pfmemalloc(void **objp)
> > return;
> >  }
> >
> > -static inline void clear_obj_pfmemalloc(void **objp)
> > +static inline void *clear_obj_pfmemalloc(void *objp)
> >  {
> > -   *objp = (void *)((unsigned long)*objp & ~SLAB_OBJ_PFMEMALLOC);
> > +   return (void *)((unsigned long)objp & ~SLAB_OBJ_PFMEMALLOC);
> >  }
> 
> I dont think you need the (void *) cast here.
> 

Yeah, you don't need it, but don't you think it makes the code more 
readable?  Otherwise this is going to be just doing

return (unsigned long)objp & ~SLAB_OBJ_PFMEMALLOC;

and you gotta figure out the function type to understand it's returned as 
a pointer.
--
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] MAINTAINERS: Add Broadcom GPIO maintainer

[Christian Daudt]

On Wed, Feb 12, 2014 at 3:42 PM, Markus Mayer  wrote:
> List myself as maintainer for Broadcom's Kona GPIO driver.
>
> Signed-off-by: Markus Mayer 
> ---
>
> Does that look like a reasonable way to make this change? I added the
> entry alphabetically in the BROADCOM section.
>
>  MAINTAINERS |7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b2cf5cf..896cf2b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1909,6 +1909,13 @@ L:   linux-s...@vger.kernel.org
>  S: Supported
>  F: drivers/scsi/bnx2i/
>
> +BROADCOM KONA GPIO DRIVER
> +M: Markus Mayer 
> +L: bcm-kernel-feedback-l...@broadcom.com
> +S: Supported
> +F: drivers/gpio/gpio-bcm-kona.c
> +F: Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
> +
>  BROADCOM SPECIFIC AMBA DRIVER (BCMA)
>  M: Rafał Miłecki 
>  L: linux-wirel...@vger.kernel.org
> --
> 1.7.9.5
>
Acked-by: Christian Daudt 
--
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/9] slab: add unlikely macro to help compiler

[David Rientjes]

On Fri, 14 Feb 2014, Joonsoo Kim wrote:

> slab_should_failslab() is called on every allocation, so to optimize it
> is reasonable. We normally don't allocate from kmem_cache. It is just
> used when new kmem_cache is created, so it's very rare case. Therefore,
> add unlikely macro to help compiler optimization.
> 
> Signed-off-by: Joonsoo Kim 

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

Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option

[David Rientjes]

On Thu, 13 Feb 2014, Luiz Capitulino wrote:

> From: Luiz capitulino 
> 
> The HugeTLB command-line option hugepages= allows a user to specify how
> many huge pages should be allocated at boot. This option is needed because
> it improves reliability when allocating 1G huge pages, which are better
> allocated as early as possible due to fragmentation.
> 
> However, hugepages= has a limitation. On NUMA systems, hugepages= will
> automatically distribute memory allocation equally among nodes. For
> example, if you have a 2-node NUMA system and allocate 200 huge pages,
> than hugepages= will try to allocate 100 huge pages from node0 and 100
> from node1.
> 
> This is very unflexible, as it doesn't allow you to specify which nodes
> the huge pages should be allocated from. For example, there are use-cases
> where the user wants to specify that a 1GB huge page should be allocated
> from node 2 or that 300 2MB huge pages should be allocated from node 0.
> 
> The hugepages_node= command-line option introduced by this commit allows
> just that.
> 
> The syntax is:
> 
>   hugepages_node=nid:nr_pages:size,...
> 

Again, I think this syntax is horrendous and doesn't couple well with the 
other hugepage-related kernel command line options.  We already have 
hugepages= and hugepagesz= which you can interleave on the command line to 
get 100 2M hugepages and 10 1GB hugepages, for example.

This patchset is simply introducing another variable to the matter: the 
node that the hugepages should be allocated on.  So just introduce a 
hugepagesnode= parameter to couple with the others so you can do

hugepagesz= hugepagesnode= hugepages=<#>

instead of having completely confusing interfaces where you want to do 
hugepages_node=1:1:1G for a 1GB hugepage on page 1 (and try remembering 
which "1" means what, yuck) and "hugepagesz=1GB hugepages=1" if you're 
indifferent to the node.
--
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/

[PATCHv2 2/5] wl1251: move power GPIO handling into the driver

[Sebastian Reichel]

Move the power GPIO handling from the board code into
the driver. This is a dependency for device tree support.

Signed-off-by: Sebastian Reichel 
Reviewed-by: Pavel Machek 
Acked-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-omap3pandora.c |  2 ++
 arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++
 drivers/net/wireless/ti/wl1251/sdio.c| 21 +-
 drivers/net/wireless/ti/wl1251/spi.c | 33 ++--
 drivers/net/wireless/ti/wl1251/wl1251.h  |  2 +-
 include/linux/wl12xx.h   |  2 +-
 6 files changed, 43 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
index 24f3c1b..cf18340 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -541,6 +541,8 @@ static void __init pandora_wl1251_init(void)
 
memset(_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
 
+   pandora_wl1251_pdata.power_gpio = -1;
+
ret = gpio_request_one(PANDORA_WIFI_IRQ_GPIO, GPIOF_IN, "wl1251 irq");
if (ret < 0)
goto fail;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index e05e740..ddfc8df 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1173,13 +1173,7 @@ static inline void board_smc91x_init(void)
 
 #endif
 
-static void rx51_wl1251_set_power(bool enable)
-{
-   gpio_set_value(RX51_WL1251_POWER_GPIO, enable);
-}
-
 static struct gpio rx51_wl1251_gpios[] __initdata = {
-   { RX51_WL1251_POWER_GPIO, GPIOF_OUT_INIT_LOW,   "wl1251 power"  },
{ RX51_WL1251_IRQ_GPIO,   GPIOF_IN, "wl1251 irq"},
 };
 
@@ -1196,17 +1190,16 @@ static void __init rx51_init_wl1251(void)
if (irq < 0)
goto err_irq;
 
-   wl1251_pdata.set_power = rx51_wl1251_set_power;
+   wl1251_pdata.power_gpio = RX51_WL1251_POWER_GPIO;
rx51_peripherals_spi_board_info[RX51_SPI_WL1251].irq = irq;
 
return;
 
 err_irq:
gpio_free(RX51_WL1251_IRQ_GPIO);
-   gpio_free(RX51_WL1251_POWER_GPIO);
 error:
printk(KERN_ERR "wl1251 board initialisation failed\n");
-   wl1251_pdata.set_power = NULL;
+   wl1251_pdata.power_gpio = -1;
 
/*
 * Now rx51_peripherals_spi_board_info[1].irq is zero and
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c 
b/drivers/net/wireless/ti/wl1251/sdio.c
index b75a37a..b661f89 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "wl1251.h"
 
@@ -182,8 +183,9 @@ static int wl1251_sdio_set_power(struct wl1251 *wl, bool 
enable)
 * callback in case it wants to do any additional setup,
 * for example enabling clock buffer for the module.
 */
-   if (wl->set_power)
-   wl->set_power(true);
+   if (gpio_is_valid(wl->power_gpio))
+   gpio_set_value(wl->power_gpio, true);
+
 
ret = pm_runtime_get_sync(>dev);
if (ret < 0) {
@@ -203,8 +205,8 @@ static int wl1251_sdio_set_power(struct wl1251 *wl, bool 
enable)
if (ret < 0)
goto out;
 
-   if (wl->set_power)
-   wl->set_power(false);
+   if (gpio_is_valid(wl->power_gpio))
+   gpio_set_value(wl->power_gpio, false);
}
 
 out:
@@ -256,11 +258,20 @@ static int wl1251_sdio_probe(struct sdio_func *func,
 
wl1251_board_data = wl1251_get_platform_data();
if (!IS_ERR(wl1251_board_data)) {
-   wl->set_power = wl1251_board_data->set_power;
+   wl->power_gpio = wl1251_board_data->power_gpio;
wl->irq = wl1251_board_data->irq;
wl->use_eeprom = wl1251_board_data->use_eeprom;
}
 
+   if (gpio_is_valid(wl->power_gpio)) {
+   ret = devm_gpio_request(>dev, wl->power_gpio,
+   "wl1251 power");
+   if (ret) {
+   wl1251_error("Failed to request gpio: %d\n", ret);
+   goto disable;
+   }
+   }
+
if (wl->irq) {
irq_set_status_flags(wl->irq, IRQ_NOAUTOEN);
ret = request_irq(wl->irq, wl1251_line_irq, 0, "wl1251", wl);
diff --git a/drivers/net/wireless/ti/wl1251/spi.c 
b/drivers/net/wireless/ti/wl1251/spi.c
index 62403a1..6abcbc3 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "wl1251.h"
 #include "reg.h"
@@ -221,8 +222,8 @@ static void wl1251_spi_disable_irq(struct wl1251 *wl)
 
 static int 

[PATCHv2 3/5] wl1251: spi: add vio regulator support

[Sebastian Reichel]

This patch adds support for requesting the regulator powering
the vio pin.

Signed-off-by: Sebastian Reichel 
Reviewed-by: Pavel Machek 
---
 drivers/net/wireless/ti/wl1251/spi.c| 19 +--
 drivers/net/wireless/ti/wl1251/wl1251.h |  2 ++
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ti/wl1251/spi.c 
b/drivers/net/wireless/ti/wl1251/spi.c
index 6abcbc3..0a8aacc 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "wl1251.h"
 #include "reg.h"
@@ -306,13 +307,26 @@ static int wl1251_spi_probe(struct spi_device *spi)
 
irq_set_irq_type(wl->irq, IRQ_TYPE_EDGE_RISING);
 
-   ret = wl1251_init_ieee80211(wl);
+   wl->vio = devm_regulator_get(>dev, "vio");
+   if (IS_ERR(wl->vio)) {
+   ret = PTR_ERR(wl->vio);
+   wl1251_error("vio regulator missing: %d", ret);
+   goto out_free;
+   }
+
+   ret = regulator_enable(wl->vio);
if (ret)
goto out_free;
 
+   ret = wl1251_init_ieee80211(wl);
+   if (ret)
+   goto disable_regulator;
+
return 0;
 
- out_free:
+disable_regulator:
+   regulator_disable(wl->vio);
+out_free:
ieee80211_free_hw(hw);
 
return ret;
@@ -324,6 +338,7 @@ static int wl1251_spi_remove(struct spi_device *spi)
 
free_irq(wl->irq, wl);
wl1251_free_hw(wl);
+   regulator_disable(wl->vio);
 
return 0;
 }
diff --git a/drivers/net/wireless/ti/wl1251/wl1251.h 
b/drivers/net/wireless/ti/wl1251/wl1251.h
index 389fe25..16dae52 100644
--- a/drivers/net/wireless/ti/wl1251/wl1251.h
+++ b/drivers/net/wireless/ti/wl1251/wl1251.h
@@ -280,6 +280,8 @@ struct wl1251 {
int irq;
bool use_eeprom;
 
+   struct regulator *vio;
+
spinlock_t wl_lock;
 
enum wl1251_state state;
-- 
1.8.5.3

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

[PATCHv2 5/5] Documentation: dt: wireless: Add wl1251

[Sebastian Reichel]

Add device tree binding documentation for Texas Instrument's wl1251
wireless lan chip. For now only the SPI binding is documented.

Signed-off-by: Sebastian Reichel 
---
 .../devicetree/bindings/net/wireless/ti,wl1251.txt | 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
new file mode 100644
index 000..189ae5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
@@ -0,0 +1,39 @@
+* Texas Instruments wl1251 wireless lan controller
+
+The wl1251 chip can be connected via SPI or via SDIO. This
+document describes the binding for the SPI connected chip.
+
+Required properties:
+- compatible :Should be "ti,wl1251"
+- reg :   Chip select address of device
+- spi-max-frequency : Maximum SPI clocking speed of device in Hz
+- interrupts :Should contain interrupt line
+- interrupt-parent :  Should be the phandle for the interrupt controller
+  that services interrupts for this device
+- vio-supply :phandle to regulator providing VIO
+- ti,power-gpio : GPIO connected to chip's PMEN pin
+
+Optional properties:
+- ti,wl1251-has-eeprom : boolean, the wl1251 has an eeprom connected, which
+ provides configuration data (calibration, MAC, ...)
+- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
+  for optional SPI connection related properties,
+
+Examples:
+
+ {
+   wl1251@0 {
+   compatible = "ti,wl1251";
+
+   reg = <0>;
+   spi-max-frequency = <4800>;
+   spi-cpol;
+   spi-cpha;
+
+   interrupt-parent = <>;
+   interrupts = <10 IRQ_TYPE_NONE>; /* gpio line 42 */
+
+   vio-supply = <>;
+   ti,power-gpio = < 23 GPIO_ACTIVE_HIGH>; /* 87 */
+   };
+};
-- 
1.8.5.3

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

[PATCHv2 4/5] wl1251: spi: add device tree support

[Sebastian Reichel]

Add device tree support for the spi variant of wl1251.

Signed-off-by: Sebastian Reichel 
---
 drivers/net/wireless/ti/wl1251/spi.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wl1251/spi.c 
b/drivers/net/wireless/ti/wl1251/spi.c
index 0a8aacc..b06d36d 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include "wl1251.h"
@@ -240,13 +242,13 @@ static const struct wl1251_if_operations wl1251_spi_ops = 
{
 
 static int wl1251_spi_probe(struct spi_device *spi)
 {
-   struct wl1251_platform_data *pdata;
+   struct wl1251_platform_data *pdata = dev_get_platdata(>dev);
+   struct device_node *np = spi->dev.of_node;
struct ieee80211_hw *hw;
struct wl1251 *wl;
int ret;
 
-   pdata = dev_get_platdata(>dev);
-   if (!pdata) {
+   if (!np && !pdata) {
wl1251_error("no platform data");
return -ENODEV;
}
@@ -273,7 +275,18 @@ static int wl1251_spi_probe(struct spi_device *spi)
goto out_free;
}
 
-   wl->power_gpio = pdata->power_gpio;
+   if (np) {
+   wl->use_eeprom = of_property_read_bool(np, 
"ti,wl1251-has-eeprom");
+   wl->power_gpio = of_get_named_gpio(np, "ti,power-gpio", 0);
+   } else if (pdata) {
+   wl->power_gpio = pdata->power_gpio;
+   wl->use_eeprom = pdata->use_eeprom;
+   }
+
+   if (wl->power_gpio == -EPROBE_DEFER) {
+   ret = -EPROBE_DEFER;
+   goto out_free;
+   }
 
if (gpio_is_valid(wl->power_gpio)) {
ret = devm_gpio_request_one(>dev, wl->power_gpio,
@@ -295,8 +308,6 @@ static int wl1251_spi_probe(struct spi_device *spi)
goto out_free;
}
 
-   wl->use_eeprom = pdata->use_eeprom;
-
irq_set_status_flags(wl->irq, IRQ_NOAUTOEN);
ret = devm_request_irq(>dev, wl->irq, wl1251_irq, 0,
DRIVER_NAME, wl);
-- 
1.8.5.3

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

[RESEND] [PATCHv2 0/5] wl1251 device tree support

[Sebastian Reichel]

Hi John,

The following patchset adds device tree support to the spi variant of the
wl1251 driver, which is used in the Nokia N900. Tony requested, that you
take the whole series even if that may introduce merge conflicts:

> Sebastian, please resend the whole series to John and feel free to add my
> acks.  It's best that John picks them all up, otherwise we'll have the same
> issue for v3.15. It seems that we should have just taken the merge conflict
> rather than going back and forth with this.

-- Sebastian

Luciano Coelho (1):
  wl1251: split wl251 platform data to a separate structure

Sebastian Reichel (4):
  wl1251: move power GPIO handling into the driver
  wl1251: spi: add vio regulator support
  wl1251: spi: add device tree support
  Documentation: dt: wireless: Add wl1251

 .../devicetree/bindings/net/wireless/ti,wl1251.txt | 39 
 arch/arm/mach-omap2/board-omap3pandora.c   |  6 +-
 arch/arm/mach-omap2/board-rx51-peripherals.c   | 13 +---
 drivers/net/wireless/ti/wilink_platform_data.c | 37 +--
 drivers/net/wireless/ti/wl1251/sdio.c  | 31 +++---
 drivers/net/wireless/ti/wl1251/spi.c   | 71 --
 drivers/net/wireless/ti/wl1251/wl1251.h|  4 +-
 include/linux/wl12xx.h | 24 +++-
 8 files changed, 176 insertions(+), 49 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt

-- 
1.8.5.3

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

[PATCHv2 1/5] wl1251: split wl251 platform data to a separate structure

[Sebastian Reichel]

From: Luciano Coelho 

Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251.  Change the platform data built-in
block and board files accordingly.

Signed-off-by: Luciano Coelho 
Acked-by: Tony Lindgren 
Reviewed-by: Felipe Balbi 
Reviewed-by: Sebastian Reichel 
Reviewed-by: Pavel Machek 
---
 arch/arm/mach-omap2/board-omap3pandora.c   |  4 +--
 arch/arm/mach-omap2/board-rx51-peripherals.c   |  2 +-
 drivers/net/wireless/ti/wilink_platform_data.c | 37 +-
 drivers/net/wireless/ti/wl1251/sdio.c  | 12 -
 drivers/net/wireless/ti/wl1251/spi.c   |  2 +-
 include/linux/wl12xx.h | 22 ++-
 6 files changed, 62 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
index de1bc6b..24f3c1b 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -536,7 +536,7 @@ static struct spi_board_info omap3pandora_spi_board_info[] 
__initdata = {
 
 static void __init pandora_wl1251_init(void)
 {
-   struct wl12xx_platform_data pandora_wl1251_pdata;
+   struct wl1251_platform_data pandora_wl1251_pdata;
int ret;
 
memset(_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
@@ -550,7 +550,7 @@ static void __init pandora_wl1251_init(void)
goto fail_irq;
 
pandora_wl1251_pdata.use_eeprom = true;
-   ret = wl12xx_set_platform_data(_wl1251_pdata);
+   ret = wl1251_set_platform_data(_wl1251_pdata);
if (ret < 0)
goto fail_irq;
 
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 8760bbe..e05e740 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -84,7 +84,7 @@ enum {
RX51_SPI_MIPID, /* LCD panel */
 };
 
-static struct wl12xx_platform_data wl1251_pdata;
+static struct wl1251_platform_data wl1251_pdata;
 static struct tsc2005_platform_data tsc2005_pdata;
 
 #if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
diff --git a/drivers/net/wireless/ti/wilink_platform_data.c 
b/drivers/net/wireless/ti/wilink_platform_data.c
index 998e958..a92bd3e 100644
--- a/drivers/net/wireless/ti/wilink_platform_data.c
+++ b/drivers/net/wireless/ti/wilink_platform_data.c
@@ -23,17 +23,17 @@
 #include 
 #include 
 
-static struct wl12xx_platform_data *platform_data;
+static struct wl12xx_platform_data *wl12xx_platform_data;
 
 int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
 {
-   if (platform_data)
+   if (wl12xx_platform_data)
return -EBUSY;
if (!data)
return -EINVAL;
 
-   platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
-   if (!platform_data)
+   wl12xx_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+   if (!wl12xx_platform_data)
return -ENOMEM;
 
return 0;
@@ -41,9 +41,34 @@ int __init wl12xx_set_platform_data(const struct 
wl12xx_platform_data *data)
 
 struct wl12xx_platform_data *wl12xx_get_platform_data(void)
 {
-   if (!platform_data)
+   if (!wl12xx_platform_data)
return ERR_PTR(-ENODEV);
 
-   return platform_data;
+   return wl12xx_platform_data;
 }
 EXPORT_SYMBOL(wl12xx_get_platform_data);
+
+static struct wl1251_platform_data *wl1251_platform_data;
+
+int __init wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+   if (wl1251_platform_data)
+   return -EBUSY;
+   if (!data)
+   return -EINVAL;
+
+   wl1251_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+   if (!wl1251_platform_data)
+   return -ENOMEM;
+
+   return 0;
+}
+
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+   if (!wl1251_platform_data)
+   return ERR_PTR(-ENODEV);
+
+   return wl1251_platform_data;
+}
+EXPORT_SYMBOL(wl1251_get_platform_data);
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c 
b/drivers/net/wireless/ti/wl1251/sdio.c
index e2b3d9c..b75a37a 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -227,7 +227,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
struct wl1251 *wl;
struct ieee80211_hw *hw;
struct wl1251_sdio *wl_sdio;
-   const struct wl12xx_platform_data *wl12xx_board_data;
+   const struct wl1251_platform_data *wl1251_board_data;
 
hw = wl1251_alloc_hw();
if (IS_ERR(hw))
@@ -254,11 +254,11 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl->if_priv = wl_sdio;
wl->if_ops = _sdio_ops;
 
-   wl12xx_board_data = wl12xx_get_platform_data();
-   if (!IS_ERR(wl12xx_board_data)) {
-   wl->set_power = wl12xx_board_data->set_power;
- 

Re: [PATCH 03/11] Input: synaptics-rmi4 - do not update configuration in rmi_f01_probe()

[Christopher Heiny]

On 02/13/2014 01:54 PM, Dmitry Torokhov wrote:

On Thu, Feb 13, 2014 at 11:23:44AM -0800, Christopher Heiny wrote:

>On 02/12/2014 09:27 PM, Dmitry Torokhov wrote:

> >Do not write configuration data in probe(), we have config() for that.

>
>Then we should call config() in rmi_function_probe() to ensure that
>any platform data or device tree configuration settings get written
>to the device.

>

Well, yes, we may elect to update device configuration in probe, but
then we should not be doing that 2nd time in ->config(). We shoudl pick
either one or another.


But as the code currently stands, config() is only called when a device 
reset is detected, not during initialization.  So if there's platform 
specific configuration data that needs to be written to a function, it 
won't get written until after a device reset occurs, which might never 
happen.  So either we need to write that data (or call config()) in each 
function's probe(), or in rmi_function_probe().

--
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 v9] PM / Hibernate: use name_to_dev_t to parse resume

[Sebastian Capella]

Use the name_to_dev_t call to parse the device name echo'd to
to /sys/power/resume.  This imitates the method used in hibernate.c
in software_resume, and allows the resume partition to be specified
using other equivalent device formats as well.  By allowing
/sys/debug/resume to accept the same syntax as the resume=device
parameter, we can parse the resume=device in the init script and
use the resume device directly from the kernel command line.

Signed-off-by: Sebastian Capella 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: "Rafael J. Wysocki" 
---
 kernel/power/hibernate.c |   22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 0121dab..a5f702a 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -972,16 +972,20 @@ static ssize_t resume_show(struct kobject *kobj, struct 
kobj_attribute *attr,
 static ssize_t resume_store(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t n)
 {
-   unsigned int maj, min;
dev_t res;
-   int ret = -EINVAL;
+   int len = n;
+   char *name;
 
-   if (sscanf(buf, "%u:%u", , ) != 2)
-   goto out;
+   if (len && buf[len-1] == '\n')
+   len--;
+   name = kstrndup(buf, len, GFP_KERNEL);
+   if (!name)
+   return -ENOMEM;
 
-   res = MKDEV(maj,min);
-   if (maj != MAJOR(res) || min != MINOR(res))
-   goto out;
+   res = name_to_dev_t(name);
+   kfree(name);
+   if (!res)
+   return -EINVAL;
 
lock_system_sleep();
swsusp_resume_device = res;
@@ -989,9 +993,7 @@ static ssize_t resume_store(struct kobject *kobj, struct 
kobj_attribute *attr,
printk(KERN_INFO "PM: Starting manual resume from disk\n");
noresume = 0;
software_resume();
-   ret = n;
- out:
-   return ret;
+   return n;
 }
 
 power_attr(resume);
-- 
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 v9 0/1] hibernation related patches

[Sebastian Capella]

Patchset related to hibernation resume:
  - enhancement to make the use of an existing resume file more general

  Patch is based on the 3.13 tag.  This was tested on a Beaglebone black
  with partial hibernation support, also compiled for x86_64.

[PATCH v9 1/1] PM / Hibernate: use name_to_dev_t to parse resume
  kernel/power/hibernate.c |   22 --
  1 file changed, 12 insertions(+), 10 deletions(-)

  Use name_to_dev_t to parse the /sys/power/resume file making the
  syntax more flexible.  It supports the previous use syntax
  and additionally can support other formats such as
  /dev/devicenode and UUID= formats.

  By changing /sys/debug/resume to accept the same syntax as
  the resume=device parameter, we can parse the resume=device
  in the initrd init script and use the resume device directly
  from the kernel command line.

Changes in v9:
--
* Dropped util changes based on feedback
* Reverted to handling newlines in resume_store

Changes in v8:
--
* Dropped cleanup checkpatch warnings in hibernate.c file
* Review comments for more compact checking in hibernate.c

Changes in v7:
--
* Switch to trim only one trailing newline if present using kstrdup_trimnl
* remove kstrimdup patch
* add kstrdup_trimnl patch
* Add clean up patch for kernel/power/hibernate.c checkpatch warnings

Changes in v6:
--
* Revert tricky / confusing while loop indexing

Changes in v5:
--
* Change kstrimdup to minimize allocated memory.  Now allocates only
  the memory needed for the string instead of using strim.

Changes in v4:
--
* Dropped name_to_dev_t rework in favor of adding kstrimdup
* adjusted resume_store

Changes in v3:
--
* Dropped documentation patch as it went in through trivial
* Added patch for name_to_dev_t to support directly parsing userspace
  buffer

Changes in v2:
--
* Added check for null return of kstrndup in hibernate.c


Thanks,

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

[WARNING - 3.14-rc2] i915: pipe_off wait timed out

[Steven Rostedt]

I get the following splat in my tests running 3.14-rc2:

[3.955123] WARNING: CPU: 0 PID: 1 at 
/work/autotest/nobackup/linux-test.git/drivers/gpu/drm/i915/intel_display.c:857 
intel_wait_for_pipe_off+0x17a/0x2d0()
[3.955124] pipe_off wait timed out
[3.955127] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc2-test+ #10
[3.955128] Hardware name:  /DG965MQ, BIOS 
MQ96510J.86A.0372.2006.0605.1717 06/05/2006
[3.955133]  0359 88007d075868 828dff7d 
0006
[3.955136]  88007d0758b8 88007d0758a8 8106c015 
1000^M
[3.955139]  880078d58000 00071008 fffb7b90 
1000
[3.955140] Call Trace:
[3.955144]  [] dump_stack+0x77/0x9e
[3.955147]  [] warn_slowpath_common+0xa5/0xf0
[3.955150]  [] warn_slowpath_fmt+0x51/0x60
[3.955153]  [] ? gen4_read32+0x52/0x70
[3.955156]  [] intel_wait_for_pipe_off+0x17a/0x2d0
[3.955158]  [] intel_disable_pipe+0x104/0x110^M
[3.955161]  [] i9xx_crtc_disable+0x11e/0x4a0
[3.955163]  [] intel_crtc_update_dpms+0x94/0xe0
[3.955166]  [] intel_modeset_setup_hw_state+0x9f8/0x1020
[3.955168]  [] ? gen4_write64+0x80/0x80
[3.955170]  [] intel_modeset_gem_init+0x62/0x80
[3.955173]  [] i915_driver_load+0x15e0/0x1760
[3.955176]  [] ? device_add+0x31b/0xa20
[3.955180]  [] drm_dev_register+0xb4/0x260
[3.955182]  [] drm_get_pci_dev+0x15e/0x320
[3.955186]  [] ? trace_hardirqs_on+0x1d/0x30
[3.955188]  [] i915_pci_probe+0x4e/0x80
[3.955191]  [] pci_device_probe+0xdd/0x190
[3.955194]  [] driver_probe_device+0xc8/0x550
[3.955196]  [] __driver_attach+0xfb/0x110
[3.955198]  [] ? driver_probe_device+0x550/0x550
[3.955200]  [] bus_for_each_dev+0x9e/0xf0
[3.955202]  [] driver_attach+0x21/0x30
[3.955204]  [] bus_add_driver+0x16f/0x340
[3.955207]  [] driver_register+0xa7/0x190
[3.955209]  [] __pci_register_driver+0x6f/0x80
[3.955211]  [] drm_pci_init+0x159/0x170
[3.955214]  [] ? radeon_init+0xfb/0xfb^M
[3.955217]  [] i915_init+0xa5/0xae
[3.955220]  [] do_one_initcall+0xe1/0x1b2
[3.955223]  [] kernel_init_freeable+0x19c/0x29d
[3.955225]  [] ? loglevel+0x46/0x46
[3.955228]  [] ? rest_init+0x120/0x120
[3.955230]  [] kernel_init+0x11/0x1a0
[3.955233]  [] ret_from_fork+0x7c/0xb0
[3.955235]  [] ? rest_init+0x120/0x120^M
[3.955256] ---[ end trace 708152452bf03fad ]---


Config attached.

-- Steve


config.gz
Description: GNU Zip compressed data

Re: [PATCH v16 0/10] Add 32 bit VDSO time function support

[Andy Lutomirski]

On Fri, Feb 14, 2014 at 12:52 AM, Stefani Seibold  wrote:
> This patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> and vdso_time() to the 32 bit VDSO.

Is there any chance you can shove this in a git tree somewhere for the
next version (in addition to sending patches)?  I don't have magic
scripts to make pulling these things in from gmail easy.

--Andy

>
> The reason to do this was to get a fast reliable time stamp. Many developers
> uses TSC to get a fast time stamp, without knowing the pitfalls. VDSO
> time functions a fast and a reliable way, because the kernel knows the
> best time source and the P- and C-state of the CPU.
>
> The helper library to use the VDSO functions can be download at
> http://http://seibold.net/vdso.c
> The libary is very small, only 228 lines of code. Compile it with
> gcc -Wall -O3 -fpic vdso.c -lrt -shared -o libvdso.so
> and use it with LD_PRELOAD=/libvdso.so
>
> This kind of helper must be integrated into glibc, for x86 64 bit and
> PowerPC it is already there.
>
> Some linux 32 bit kernel benchmark results (all measurements are in nano
> seconds):
>
> Intel(R) Celeron(TM) CPU 400MHz
>
> Average time kernel call:
>  gettimeofday(): 1039
>  clock_gettime(): 1578
>  time(): 526
> Average time VDSO call:
>  gettimeofday(): 378
>  clock_gettime(): 303
>  time(): 60
>
> Celeron(R) Dual-Core CPU T3100 1.90GHz
>
> Average time kernel call:
>  gettimeofday(): 209
>  clock_gettime(): 406
>  time(): 135
> Average time VDSO call:
>  gettimeofday(): 51
>  clock_gettime(): 43
>  time(): 10
>
> So you can see a performance increase between 4 and 13, depending on the
> CPU and the function.
>
> The address layout of the VDSO has changed, because there is no fixed
> address space available on a x86 32 bit kernel, despite the name. Because
> someone decided to add an offset to the __FIXADDR_TOP for virtualization.
>
> Also the IA32 Emulation uses the whole 4 GB address space, so there is no
> fixed address available.
>
> This was the reason not depend on this kind of address and change the layout
> of the VDSO. The VDSO for a 32 bit application has now three pages:
>
> ^ Higher Address
> |
> ++
> + VDSO page (includes code) ro+x +
> ++
> + VVAR page (export kernel variables) ro +
> ++
> + HPET page (mapped registers) ro
> ++
> |
> ^ Lower Address
>
> The VDSO page for a 32 bit resided still on 0xe000, the the VVAR and
> HPET page are mapped before.
>
> In the non compat mode the VMA of the VDSO is now 3 pages for a 32 bit kernel.
> So this decrease the available logical address room by 2 pages.
>
> The patch is against kernel 3.14 (e7651b819e90da924991d727d3c007200a18670d)
>
> Changelog:
> 25.11.2012 - first release and proof of concept for linux 3.4
> 11.12.2012 - Port to linux 3.7 and code cleanup
> 12.12.2012 - fixes suggested by Andy Lutomirski
>- fixes suggested by John Stultz
>- use call VDSO32_vsyscall instead of int 80
>- code cleanup
> 17.12.2012 - support for IA32_EMULATION, this includes
>  - code cleanup
>  - include cleanup to fix compile warnings and errors
>  - move out seqcount from seqlock, enable use in VDSO
>  - map FIXMAP and HPET into the 32 bit address space
> 18.12.2012 - split into separate patches
> 30.01.2014 - revamp the code
>  - code clean up
>  - VDSO layout changed
>  - no fixed addresses
>  - port to 3.14
> 01.02.2014 - code cleanup
> 02.02.2014 - code cleanup
>  - split into more patches
>  - use HPET_COUNTER instead of hard coded value
>  - fix changelog to the right year ;-)
> 02.02.2014 - reverse the mapping, this make the new VDSO 32 bit support
>  full compatible.
> 03.02.2014 - code cleanup
>  - fix comment
>  - fix ABI break in vdso32.lds.S
> 04.02.2014 - revamp IA32 emulation support
>  - introduce VVAR macro
>  - rearranged vsyscall_gtod_data struture for IA32 emulation 
> support
>  - code cleanup
> 05.02.2014 - revamp IA32 emulation support
>  - replace seqcount_t by an unsigned, to make the 
> vsyscall_gtod_data
>structure independed of kernel config and functions.
> 08.02.2014 - revamp IA32 emulation support
>  - replace all internal structures by fix size elements
> 10.02.2014 - code cleanup
>  - add commets
>  - revamp inline assembly
> 12.02.2014 - add conditional fixmap of vvar and hpet pages for 32 bit kernel
> 14.02.2014 - fix CONFIG_PARAVIRT_CLOCK, which is not supported in 32 bit VDSO



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

[PATCH v9] PM / Hibernate: use name_to_dev_t to parse resume

[Sebastian Capella]

Use the name_to_dev_t call to parse the device name echo'd to
to /sys/power/resume.  This imitates the method used in hibernate.c
in software_resume, and allows the resume partition to be specified
using other equivalent device formats as well.  By allowing
/sys/debug/resume to accept the same syntax as the resume=device
parameter, we can parse the resume=device in the init script and
use the resume device directly from the kernel command line.

Signed-off-by: Sebastian Capella 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: "Rafael J. Wysocki" 
---
 kernel/power/hibernate.c |   22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index 0121dab..a5f702a 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -972,16 +972,20 @@ static ssize_t resume_show(struct kobject *kobj, struct 
kobj_attribute *attr,
 static ssize_t resume_store(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t n)
 {
-   unsigned int maj, min;
dev_t res;
-   int ret = -EINVAL;
+   int len = n;
+   char *name;
 
-   if (sscanf(buf, "%u:%u", , ) != 2)
-   goto out;
+   if (len && buf[len-1] == '\n')
+   len--;
+   name = kstrndup(buf, len, GFP_KERNEL);
+   if (!name)
+   return -ENOMEM;
 
-   res = MKDEV(maj,min);
-   if (maj != MAJOR(res) || min != MINOR(res))
-   goto out;
+   res = name_to_dev_t(name);
+   kfree(name);
+   if (!res)
+   return -EINVAL;
 
lock_system_sleep();
swsusp_resume_device = res;
@@ -989,9 +993,7 @@ static ssize_t resume_store(struct kobject *kobj, struct 
kobj_attribute *attr,
printk(KERN_INFO "PM: Starting manual resume from disk\n");
noresume = 0;
software_resume();
-   ret = n;
- out:
-   return ret;
+   return n;
 }
 
 power_attr(resume);
-- 
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 v16 0/10] Add 32 bit VDSO time function support

[H. Peter Anvin]

I still get build errors.

i386 allyesconfig, i386 allmodconfig as well as a more basic i386
configuration:

arch/x86/vdso/vdso32-int80.so.dbg: undefined symbols found
make[4]: *** [arch/x86/vdso/vdso32-int80.so.dbg] Error 1

x86-64 allyesconfig and x86-64 allmodconfig:

/home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:128:4: 
warning:
symbol 'hpet_page' was not declared
. Should it be static?
/home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:134:33:
warning: incorrect type in argument 1 (diff
erent address spaces)
/home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:134:33:
   expected void const volatile [noderef] <
asn:2>*addr
/home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:134:33:
   got unsigned char [toplevel] *
/home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:294:13:
warning: symbol '__vdso_clock_gettime' was
not declared. Should it be static?
/home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:322:13:
warning: symbol '__vdso_gettimeofday' was n
ot declared. Should it be static?
/home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:343:16:
warning: symbol '__vdso_time' was not decla
red. Should it be static?
  CC  arch/x86/vdso/vdso32/vclock_gettime.o
/home/hpa/kernel/distwork/arch/x86/vdso/vdso32/vclock_gettime.c:1:0:
sorry, unimplemented: -mfentry isn’t supported fo
r 32-bit in combination with -fpic
 #define BUILD_VDSO32
 ^
make[4]: *** [arch/x86/vdso/vdso32/vclock_gettime.o] Error 1
make[3]: *** [arch/x86/vdso] Error 2
make[3]: *** Waiting for unfinished jobs

This is after I removed the incorrect "generated/" filename prefix in
patch 9.

-hpa

--
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 0/3] Quirk Intel PCH root ports for ACS-like features

[Alex Williamson]

On Fri, 2014-02-14 at 14:43 -0700, Bjorn Helgaas wrote:
> [+cc Don]
> 
> On Mon, Feb 03, 2014 at 02:27:27PM -0700, Alex Williamson wrote:
> > v2:
> >  - Remove bus #0 bug in filtering matching
> >  - Add 2/3 introducing PCI_DEV_FLAGS_ACS_ENABLED_QUIRK, this gives
> >is better tracking and addresses the theoretical hotplug issue
> >  - Update 3/3 for PCI_DEV_FLAGS_ACS_ENABLED_QUIRK
> >  - Add dev_info to print regardless of whether we changes bits
> >  - Add Intel cc
> >
> > As described in 3/3 many Intel root ports lack PCIe ACS capabilities
> > which results in excessively large IOMMU groups.  Many of these root
> > ports do provide isolation capabilities, we just need to use device
> > specific mechanisms to enable and verify.  Long term, I hope we can
> > round out this list (particularly to include X79 root ports) and
> > more importantly, encourage proper PCIe ACS support in future
> > products.  I'm really hoping we can get this in during the 3.14 cycle.
> > Thanks,
> >
> > Alex
> > ---
> >
> > Alex Williamson (3):
> >   pci: Add device specific PCI ACS enable
> >   pci: Add pci_dev_flag for ACS enable quirks
> >   pci/quirks: Enable quirks for PCIe ACS on Intel PCH root ports
> 
> I applied these (with Don's ack for 3/3) to pci/virtualization.
> 
> I tried to figure out how to handle post-merge window patches.  Per
> Documentation/development-process/2.Process, "[after -rc1], only patches
> which fix problems should be submitted to the mainline," so one might
> conclude that a fix for any sort of problem is allowed.  However,
> Documentation/networking/netdev-FAQ.txt says "No new features get mainlined
> after this [-rc1] -- only fixes to the rc1 content are expected," which is
> how I've been operating.
> 
> In any case, these patches look more like new functionality (enabling a
> non-standard ACS feature) than a bug fix to me, so my preference is to
> merge them during the v3.15 merge window.
> 
> I understand the desire for v3.14, namely, "lots of Intel devices don't
> support ACS, and that makes it hard for users to expose devices to
> userspace with fine granularity, and waiting for v3.15 will mean another
> two months."  But this problem is really of Intel's own making: if they'd
> used standard ACS, or if they'd documented their non-standard mechanism,
> this wouldn't be an issue.

I appreciate you taking the time to consider it for 3.14.  I'll look
forward to it appearing in linux-next for 3.15.  Thanks for review and
applying,

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: [RFC PATCH v4 01/10] driver core: export driver_probe_device()

[Greg KH]

On Sat, Feb 08, 2014 at 06:29:31PM +0100, Antonios Motakis wrote:
> From: Kim Phillips 
> 
> Needed by drivers, such as the vfio platform driver [1], seeking to
> bypass bind_store()'s driver_match_device(), and bind to any device
> via a private sysfs bind file.
> 
> [1] https://lkml.org/lkml/2013/12/11/522
> 
> note: the EXPORT_SYMBOL is needed because vfio-platform can be built
> as a module.

No code outside of drivers/base/ should be calling this function, you
are doing something wrong in your bus if you want to do this, please fix
your bus code.

sorry, I can't accept this at all.

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/

[PATCH v9 0/1] hibernation related patches

[Sebastian Capella]

Patchset related to hibernation resume:
  - enhancement to make the use of an existing resume file more general

  Patch is based on the 3.13 tag.  This was tested on a Beaglebone black
  with partial hibernation support, also compiled for x86_64.

[PATCH v9 1/1] PM / Hibernate: use name_to_dev_t to parse resume
  kernel/power/hibernate.c |   22 --
  1 file changed, 12 insertions(+), 10 deletions(-)

  Use name_to_dev_t to parse the /sys/power/resume file making the
  syntax more flexible.  It supports the previous use syntax
  and additionally can support other formats such as
  /dev/devicenode and UUID= formats.

  By changing /sys/debug/resume to accept the same syntax as
  the resume=device parameter, we can parse the resume=device
  in the initrd init script and use the resume device directly
  from the kernel command line.

Changes in v9:
--
* Dropped util changes based on feedback
* Reverted to special newline handling in resume_store

Changes in v8:
--
* Dropped cleanup checkpatch warnings in hibernate.c file
* Review comments for more compact checking in hibernate.c

Changes in v7:
--
* Switch to trim only one trailing newline if present using kstrdup_trimnl
* remove kstrimdup patch
* add kstrdup_trimnl patch
* Add clean up patch for kernel/power/hibernate.c checkpatch warnings

Changes in v6:
--
* Revert tricky / confusing while loop indexing

Changes in v5:
--
* Change kstrimdup to minimize allocated memory.  Now allocates only
  the memory needed for the string instead of using strim.

Changes in v4:
--
* Dropped name_to_dev_t rework in favor of adding kstrimdup
* adjusted resume_store

Changes in v3:
--
* Dropped documentation patch as it went in through trivial
* Added patch for name_to_dev_t to support directly parsing userspace
  buffer

Changes in v2:
--
* Added check for null return of kstrndup in hibernate.c


Thanks,

Sebastian

--
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 0/3] Quirk Intel PCH root ports for ACS-like features

[Dugger, Donald D]

In re: Feature vs. bug fix

At the risk of trying to arguing about the meaning of `is' I would argue that 
this is more a bug fix than a feature.  We're not adding a new capability, we 
are trying to work around deficient HW (no argument that we should have 
implemented ACS on all platforms).

Having said that, although I would obviously prefer to see this in v3.14 we can 
live with this hitting v3.15.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com] 
Sent: Friday, February 14, 2014 2:43 PM
To: Alex Williamson
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Dugger, Donald D
Subject: Re: [PATCH v2 0/3] Quirk Intel PCH root ports for ACS-like features

[+cc Don]

On Mon, Feb 03, 2014 at 02:27:27PM -0700, Alex Williamson wrote:
> v2:
>  - Remove bus #0 bug in filtering matching
>  - Add 2/3 introducing PCI_DEV_FLAGS_ACS_ENABLED_QUIRK, this gives
>is better tracking and addresses the theoretical hotplug issue
>  - Update 3/3 for PCI_DEV_FLAGS_ACS_ENABLED_QUIRK
>  - Add dev_info to print regardless of whether we changes bits
>  - Add Intel cc
>
> As described in 3/3 many Intel root ports lack PCIe ACS capabilities 
> which results in excessively large IOMMU groups.  Many of these root 
> ports do provide isolation capabilities, we just need to use device 
> specific mechanisms to enable and verify.  Long term, I hope we can 
> round out this list (particularly to include X79 root ports) and more 
> importantly, encourage proper PCIe ACS support in future products.  
> I'm really hoping we can get this in during the 3.14 cycle.
> Thanks,
>
> Alex
> ---
>
> Alex Williamson (3):
>   pci: Add device specific PCI ACS enable
>   pci: Add pci_dev_flag for ACS enable quirks
>   pci/quirks: Enable quirks for PCIe ACS on Intel PCH root ports

I applied these (with Don's ack for 3/3) to pci/virtualization.

I tried to figure out how to handle post-merge window patches.  Per 
Documentation/development-process/2.Process, "[after -rc1], only patches which 
fix problems should be submitted to the mainline," so one might conclude that a 
fix for any sort of problem is allowed.  However, 
Documentation/networking/netdev-FAQ.txt says "No new features get mainlined 
after this [-rc1] -- only fixes to the rc1 content are expected," which is how 
I've been operating.

In any case, these patches look more like new functionality (enabling a 
non-standard ACS feature) than a bug fix to me, so my preference is to merge 
them during the v3.15 merge window.

I understand the desire for v3.14, namely, "lots of Intel devices don't support 
ACS, and that makes it hard for users to expose devices to userspace with fine 
granularity, and waiting for v3.15 will mean another two months."  But this 
problem is really of Intel's own making: if they'd used standard ACS, or if 
they'd documented their non-standard mechanism, this wouldn't be an issue.

Bjorn

Re: Loseing my patience with libata and sata_nv

[Randy Dunlap]

On 02/14/2014 11:21 AM, Gene Heskett wrote:
> On Friday 14 February 2014, Randy Dunlap wrote:
>> On 02/14/2014 08:31 AM, Gene Heskett wrote:
>>> Which is required for my $290 ASUS M2n-SLI Deluxe motherboard to boot.
>>>
>>> Not finding the option in any kernel tree that exists on my system,
>>> except it appears its been replaced or something.
>>>
>>> This once in a lifetime boot, to 3.12.9, shows from an lsmod:
>>> libata146855  2 sata_nv,pata_amd
>>> scsi_mod  153579  4 sr_mod,sg,sd_mod,libata
>>>
>>> I haven't a clue how I got it in this boot, and I built it.  And
>>> apparently a make oldconfig, carefully done by hand (takes about an
>>> hour 30 to do) is not capable of adding it to a .config BECAUSE it
>>> does NOT exist in any of the arch/x86/configs/i386_defconfig's present
>>> on this machine.
>>
>> It does not have to exist in any defconfig.  Those are just default
>> config files and SATA_NV is not enabled by default, but you can still
>> enable it.
>>
>>> Here is how I searched:
>>>
>>> gene@coyote:~/src/linux-3.0.69$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.0.69$ cd
>>> ../linux-3.2.40
>>> gene@coyote:~/src/linux-3.2.40$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.2.40$ cd
>>> ../linux-3.4.36
>>> gene@coyote:~/src/linux-3.4.36$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.4.36$ cd
>>> ../linux-3.8.2
>>> gene@coyote:~/src/linux-3.8.2$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.8.2$ cd
>>> ../linux-3.8.3
>>> gene@coyote:~/src/linux-3.8.3$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.8.3$ cd
>>> ../linux-3.12.0
>>> gene@coyote:~/src/linux-3.12.0$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.12.0$ cd
>>> ../linux-3.12.6
>>> gene@coyote:~/src/linux-3.12.6$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.12.6$ cd
>>> ../linux-3.12.9
>>> gene@coyote:~/src/linux-3.12.9$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.12.9$ cd
>>> ../linux-3.13.1
>>> gene@coyote:~/src/linux-3.13.1$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.13.1$ cd
>>> ../linux-3.13.2
>>> gene@coyote:~/src/linux-3.13.2$ grep SATA_NV
>>> arch/x86/configs/i386_defconfig gene@coyote:~/src/linux-3.13.2$
>>>
>>> I've been fighting with this, intermittently for about 6 months. 
>>> Except for this 3.12.9 where I must have been holding my mouth right,
>>> all the rest are boot failures because it can't find the boot drive
>>> with so-and-so for a UUID. sata_nv is on the missing list, even in
>>> this WORKing boots defconfig. "Working" however is a miss-statement,
>>> no multimedia stuff was built.
>>>
>>> There has to be a rule I am violating, but even with Randy's D's help,
>>> it is not becoming obvious.  FWIW libata references also can't be
>>> found, but as can be seen, its in memory right now.
>>
>> libata is built whenever CONFIG_ATA is enabled.
> 
> I don't believe the help states that.

AFAICT the Kconfig help does not tell what builds libata.
Would it help if it did?

Maybe by adding 'libata' to this prompt text:
"Serial ATA and Parallel ATA drivers"
e.g.,
"Serial ATA and Parallel ATA drivers (libata)"


> 
>>> So please guys, what is the magic dependency that causes libata and
>>> sata_nv to be included in a .config?
>>
>> The SATA_NV kconfig symbol depends on (requires) the following other
>> kconfig symbols to be enabled:
>>  ATA_SFF and ATA_BMDMA and PCI and ATA
> 
> I wrote down those deps from the make menuconfig help screen, they are as 
> stated.  I made sure with gedit and grep...
> 
> It gets to:
> 
> Early console decompressing the kernel
> booting the kernel
> 
> Thats it, no disk activity, its hung.
> 
> .config for a 3.13.2 attached.
>>
>> If those are not enabled, then you will need to use 'make config'
>> to enabled them before you can enable SATA_NV.

Please add this string to the kernel command line to see if helps to
narrow down what is happening:
initcall_debug


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

[ANNOUNCE] Git v1.9.0

[Junio C Hamano]

The latest feature release Git v1.9.0 is now available at the
usual places.

The release tarballs are found at:

http://code.google.com/p/git-core/downloads/list

and their SHA-1 checksums are:

e60667fc16e5a5f1cde46616b0458cc802707743  git-1.9.0.tar.gz
65eb3f411f4699695c7081a7c716cabb9ce23d75  git-htmldocs-1.9.0.tar.gz
cff590c92b4d1c8a143c078473140b653cc5d56a  git-manpages-1.9.0.tar.gz

The following public repositories all have a copy of the v1.9.0
tag and the master branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Also, http://www.kernel.org/pub/software/scm/git/ has copies of the
release tarballs.

Git v1.9.0 Release Notes


Backward compatibility notes


"git submodule foreach $cmd $args" used to treat "$cmd $args" the same
way "ssh" did, concatenating them into a single string and letting the
shell unquote. Careless users who forget to sufficiently quote $args
get their argument split at $IFS whitespaces by the shell, and got
unexpected results due to this. Starting from this release, the
command line is passed directly to the shell, if it has an argument.

Read-only support for experimental loose-object format, in which users
could optionally choose to write their loose objects for a short
while between v1.4.3 and v1.5.3 era, has been dropped.

The meanings of the "--tags" option to "git fetch" has changed; the
command fetches tags _in addition to_ what is fetched by the same
command line without the option.

The way "git push $there $what" interprets the $what part given on the
command line, when it does not have a colon that explicitly tells us
what ref at the $there repository is to be updated, has been enhanced.

A handful of ancient commands that have long been deprecated are
finally gone (repo-config, tar-tree, lost-found, and peek-remote).


Backward compatibility notes (for Git 2.0.0)


When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there).  In Git 2.0, the default will change to the "simple"
semantics, which pushes:

 - only the current branch to the branch with the same name, and only
   when the current branch is set to integrate with that remote
   branch, if you are pushing to the same remote as you fetch from; or

 - only the current branch to the branch with the same name, if you
   are pushing to a remote that is not where you usually fetch from.

Use the user preference configuration variable "push.default" to
change this.  If you are an old-timer who is used to the "matching"
semantics, you can set the variable to "matching" to keep the
traditional behaviour.  If you want to live in the future early, you
can set it to "simple" today without waiting for Git 2.0.

When "git add -u" (and "git add -A") is run inside a subdirectory and
does not specify which paths to add on the command line, it
will operate on the entire tree in Git 2.0 for consistency
with "git commit -a" and other commands.  There will be no
mechanism to make plain "git add -u" behave like "git add -u .".
Current users of "git add -u" (without a pathspec) should start
training their fingers to explicitly say "git add -u ."
before Git 2.0 comes.  A warning is issued when these commands are
run without a pathspec and when you have local changes outside the
current directory, because the behaviour in Git 2.0 will be different
from today's version in such a situation.

In Git 2.0, "git add " will behave as "git add -A ", so
that "git add dir/" will notice paths you removed from the directory
and record the removal.  Versions before Git 2.0, including this
release, will keep ignoring removals, but the users who rely on this
behaviour are encouraged to start using "git add --ignore-removal "
now before 2.0 is released.

The default prefix for "git svn" will change in Git 2.0.  For a long
time, "git svn" created its remote-tracking branches directly under
refs/remotes, but it will place them under refs/remotes/origin/ unless
it is told otherwise with its --prefix option.


Updates since v1.8.5


Foreign interfaces, subsystems and ports.

 * The HTTP transport, when talking GSS-Negotiate, uses "100
   Continue" response to avoid having to rewind and resend a large
   payload, which may not be always doable.

 * Various bugfixes to remote-bzr and remote-hg (in contrib/).

 * The build procedure is aware of MirBSD now.

 * Various "git p4", "git svn" and "gitk" updates.


UI, Workflows & Features

 * Fetching from a shallowly-cloned repository used to be forbidden,
 

Re: [PATCH V5 0/7] cpufreq: suspend early/resume late: dpm_{suspend|resume}()

[Rafael J. Wysocki]

On Friday, February 14, 2014 12:42:53 PM Stephen Warren wrote:
> On 02/12/2014 11:50 PM, Viresh Kumar wrote:
> > This patchset creates/calls cpufreq suspend/resume callbacks from 
> > dpm_{suspend|resume}()
> > for handling suspend/resume of cpufreq governors and core.
> 
> Are these patches for 3.14 or 3.15?

I don't think they are suitable for 3.14, honestly.

> I ask because I just tested Linus's master from a few days back (some
> point after v3.14-rc2; commit 9398a10cd964 Merge tag
> 'regulator-v3.14-rc2'), and I see a lot of the following messages during
> suspend and/or resume (about 2-7 times, perhaps more of them from the
> resume path, but it's hard to tell):
> 
> cpufreq: __cpufreq_driver_target: Failed to change cpu frequency: -16
> 
> This series does appear to solve those, so I think at least part of it
> needs to be applied for 3.14.

Well, it would be good to verify which part, then.

> Also, I sometimes see the following during resume. I saw it twice with
> Linus's tree, but then I did 10 more reboot+suspend+resume cycles and
> couldn't repro it, and I saw it once with Linus's tree plus this series
> applied, then couldn't reproduce it in 5 more tries.
> 
> > [ 48.500410] [ cut here ]
> > [ 48.505252] WARNING: CPU: 0 PID: 877 at fs/sysfs/dir.c:52 
> > sysfs_warn_dup+0x68/0x84()
> > [ 48.513005] sysfs: cannot create duplicate filename 
> > '/devices/system/cpu/cpu1/cpufreq'
> > [ 48.520995] Modules linked in: brcmfmac brcmutil
> > [ 48.525740] CPU: 0 PID: 877 Comm: test-rtc-resume Not tainted 
> > 3.14.0-rc2-00259-g9398a10cd964 #12
> > [ 48.534645] [] (unwind_backtrace) from [] 
> > (show_stack+0x10/0x14)
> > [ 48.542440] [] (show_stack) from [] 
> > (dump_stack+0x80/0xcc)
> > [ 48.549757] [] (dump_stack) from [] 
> > (warn_slowpath_common+0x64/0x88)
> > [ 48.557964] [] (warn_slowpath_common) from [] 
> > (warn_slowpath_fmt+0x30/0x40)
> > [ 48.566756] [] (warn_slowpath_fmt) from [] 
> > (sysfs_warn_dup+0x68/0x84)
> > [ 48.575024] [] (sysfs_warn_dup) from [] 
> > (sysfs_do_create_link_sd+0xb0/0xb8)
> > [ 48.583772] [] (sysfs_do_create_link_sd) from [] 
> > (__cpufreq_add_dev.isra.27+0x2a8/0x814)
> > [ 48.593701] [] (__cpufreq_add_dev.isra.27) from [] 
> > (cpufreq_cpu_callback+0x70/0x8c)
> > [ 48.603198] [] (cpufreq_cpu_callback) from [] 
> > (notifier_call_chain+0x44/0x84)
> > [ 48.612166] [] (notifier_call_chain) from [] 
> > (__cpu_notify+0x28/0x44)
> > [ 48.620424] [] (__cpu_notify) from [] 
> > (_cpu_up+0xf0/0x140)
> > [ 48.627748] [] (_cpu_up) from [] 
> > (enable_nonboot_cpus+0x68/0xb0)
> > [ 48.635579] [] (enable_nonboot_cpus) from [] 
> > (suspend_devices_and_enter+0x198/0x2dc)
> > [ 48.645136] [] (suspend_devices_and_enter) from [] 
> > (pm_suspend+0x174/0x1e8)
> > [ 48.653862] [] (pm_suspend) from [] 
> > (state_store+0x6c/0xbc)
> > [ 48.661258] [] (state_store) from [] 
> > (kobj_attr_store+0x14/0x20)
> > [ 48.669083] [] (kobj_attr_store) from [] 
> > (sysfs_kf_write+0x44/0x48)
> > [ 48.677163] [] (sysfs_kf_write) from [] 
> > (kernfs_fop_write+0xb4/0x14c)
> > [ 48.685432] [] (kernfs_fop_write) from [] 
> > (vfs_write+0xa8/0x180)
> > [ 48.693214] [] (vfs_write) from [] 
> > (SyS_write+0x3c/0x70)
> > [ 48.700349] [] (SyS_write) from [] 
> > (ret_fast_syscall+0x0/0x30)
> > [ 48.708053] ---[ end trace 76969904b614c18f ]--- 
> 
> Do you have any idea what the problem might be, and how to solve it?

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] Revert "ACPI / video: Add HP EliteBook Revolve 810 to the blacklist"

[Rafael J. Wysocki]

On Friday, February 14, 2014 05:26:01 PM Mika Westerberg wrote:
> On Fri, Feb 14, 2014 at 03:46:20PM +0100, Takashi Iwai wrote:
> > The acpi_osi blacklist is just a workaround, and if we have better
> > solutions, it should be removed.  That's why I'm asking it.
> > 
> > So, after removing acpi_osi blacklist, and keeping your video
> > blacklist patch, the backlight works?
> 
> Yes, the backlight works (there is only intel_backlight listed under
> /sys/class/backlight).
> 
> > If yes, as mentioned, we should think of rather extending this video
> > blacklist to more EliteBook G1 and ProBook G1 machines, and remove
> > acpi_osi blacklist instead.
> 
> Makes sense to me. (Well, I'm fine as long as backlight on my machine works
> ;-))
> 
> Aaron, Rafael, any comments on this?

I generally agree with Takashi, but I'm not sure what to do for 3.14.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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 03/11] sysfs: create bin_attributes under the requested group

[Cody P Schafer]

bin_attributes created/updated in create_files() (such as those listed
via (struct device).attribute_groups) were not placed under the
specified group, and instead appeared in the base kobj directory.

Fix this by making bin_attributes use creating code similar to normal
attributes.

A quick grep shows that no one is using bin_attrs in a named attribute
group yet, so we can do this without breaking anything in usespace.

Note that I do not add is_visible() support to
bin_attributes, though that could be done as well.

Signed-off-by: Cody P Schafer 
---
 fs/sysfs/group.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 6b57938..aa04068 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -70,8 +70,11 @@ static int create_files(struct kernfs_node *parent, struct 
kobject *kobj,
if (grp->bin_attrs) {
for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
if (update)
-   sysfs_remove_bin_file(kobj, *bin_attr);
-   error = sysfs_create_bin_file(kobj, *bin_attr);
+   kernfs_remove_by_name(parent,
+   (*bin_attr)->attr.name);
+   error = sysfs_add_file_mode_ns(parent,
+   &(*bin_attr)->attr, true,
+   (*bin_attr)->attr.mode, NULL);
if (error)
break;
}
-- 
1.8.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/