Re: [PATCH 1/2] ASoC: cygnus-audio: adding device tree bindings

2015-03-30 Thread Mark Brown
On Mon, Mar 30, 2015 at 08:16:23PM -0700, Scott Branden wrote:

> +SSP Subnode properties:
> +- dai-name: The name of the DAI registered with ASOC

ASoC.

Why is this in the DT - it sounds like this is just an internal
implementation detail for Linux, not a property of the hardware.

> +- mode: Controls if this port should be configured as I2S or TDM mode.
> + Valid values are: "tdm" or "i2s"
> +- tdm-bits-per-frame:  only if mode is "tdm" then this property must set.
> + Valid values are (128/256/512)

We'd normally leave these up to the machine driver to set as they're
link wide things for system integration.  The bits per frame in
particular looks like something that's not going to be fixed by the
hardware and could be varied at runtime.

> +- port-status: Controls if port is enabled or not
> + Valid values "enabled" or "disabled"

This sounds like it's replicating the DT standard status property?

> +- channel-group: Control grouping of serial port
> + Valid values are "2_0", "3_1", or "5_1"

What does this mean?  It looks like it's setting the number of channels
which again seems like a runtime thing.


signature.asc
Description: Digital signature


Re: [PATCH 3/4] mm: move lazy free pages to inactive list

2015-03-30 Thread Minchan Kim
On Mon, Mar 30, 2015 at 10:28:47PM -0700, Andrew Morton wrote:
> On Tue, 31 Mar 2015 13:45:25 +0900 Minchan Kim  wrote:
> > > 
> > > deactivate_page() doesn't look at or alter PageReferenced().  Should it?
> > 
> > Absolutely true. Thanks.
> > Here it goes.
> > 
> > >From 2b2c92eb73a1cceac615b9abd4c0f5f0c3395ff5 Mon Sep 17 00:00:00 2001
> > From: Minchan Kim 
> > Date: Tue, 31 Mar 2015 13:38:46 +0900
> > Subject: [PATCH] mm: lru_deactivate_fn should clear PG_referenced
> > 
> > deactivate_page aims for accelerate for reclaiming through
> > moving pages from active list to inactive list so we should
> > clear PG_referenced for the goal.
> > 
> > ...
> >
> > --- a/mm/swap.c
> > +++ b/mm/swap.c
> > @@ -800,6 +800,7 @@ static void lru_deactivate_fn(struct page *page, struct 
> > lruvec *lruvec,
> >  
> > del_page_from_lru_list(page, lruvec, lru + LRU_ACTIVE);
> > ClearPageActive(page);
> > +   ClearPageReferenced(page);
> > add_page_to_lru_list(page, lruvec, lru);
> >  
> > __count_vm_event(PGDEACTIVATE);
> 
> What if we have
> 
>   PageLRU(page) && !PageActive(page) && PageReferenced(page)
> 
> if we really want to "accelerate the reclaim of @page" then we should
> clear PG_referenced there too.

The function's name is *deactivate*_page. IOW, I think it should work
for only pages in active list, IMHO.

> 
> (And what about page_referenced(page) :))

Yes, I considered it when you mentioned PG_referenced. Now, madvise_free
clear out access bit of page table when the syscall is called so
shrink_page_list could reclaim pages easily.

Of course, we could clear access bit by page_referenced for general purpose,
not only madvise_free but it would hurt performance for madvise_free so
I'd like to leave it unless there is a need for the function.

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


[PATCH] dmapool: Declare struct device

2015-03-30 Thread Mark Brown
dmapool uses struct device in function arguments but relies on an implicit
inclusion to declare struct device causing warnings in some configurations:

include/linux/dmapool.h:31:7: warning: 'struct device' declared inside 
parameter list

Fix this by adding a struct device declaration to the file.

Signed-off-by: Mark Brown 
---
 include/linux/dmapool.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/dmapool.h b/include/linux/dmapool.h
index 022e34fcbd1b..52456aa566a0 100644
--- a/include/linux/dmapool.h
+++ b/include/linux/dmapool.h
@@ -14,6 +14,8 @@
 #include 
 #include 
 
+struct device;
+
 struct dma_pool *dma_pool_create(const char *name, struct device *dev, 
size_t size, size_t align, size_t allocation);
 
-- 
2.1.4

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


Re: [PATCH] spi: xilinx: Use standard num-cs binding

2015-03-30 Thread Mark Brown
On Mon, Mar 30, 2015 at 08:46:10AM +0200, Michal Simek wrote:
> On 03/27/2015 06:53 PM, Mark Brown wrote:
> > On Fri, Mar 27, 2015 at 11:55:49AM +0100, Michal Simek wrote:

> > Please fix your mail client to word wrap within paragraphs at less than
> > 80 columns - this makes your mails easier to read and reply to.

> You are the first one who had problem with this. But I have setup lower
> limit and hopefully it is better now.

That looks better, yes...  I may just be the first one who's bothered
remarking on this.

> >> On 03/08/2015 08:00 PM, Mark Brown wrote:
> >>> On Fri, Jan 16, 2015 at 01:55:14PM +0100, Michal Simek wrote:

> > Remember that we can at least in theory have additional chip selects
> > that aren't controlled by the IP block but are instead GPIOs.  

> I agree with you but this can be generic case for every SPI driver. Also
> using external decoder is possible for every driver. Maybe there are
> others options via I2C too.

Remember that this in the context of me saying I don't think num-cs is
a particularly good idea at all...

> > There's
> > also some potential confusion for users between the number of chip
> > selects in use in a given system and the size of the bitfield that the
> > driver needs to take care of.

> num-ss-bits is autogenerated directly from design tools for particular
> hardware design and this size is exactly setup and hardcoded. (num-cs
> can be just the same case)
> If there are 5 bits there are 5 wires from IP. And value of num-ss-bits
> and num-cs will be the same.

But what your patch did was *replace* num-ss-bits in the binding, not
just add it.

> If user wants to use less lines then physically available we could
> potentially extend binding to say. num-ss-bit - number of chip selects
> available in hardware. num-cs - number of chip selects used by the driver.
> But I expect that this will be rejected because it is software setting
> not hardware description.

num-cs *is* a software setting.


signature.asc
Description: Digital signature


Re: [PATCH 12/25] virtio_console: Use bool function return values of true/false not 1/0

2015-03-30 Thread Amit Shah
On (Mon) 30 Mar 2015 [16:46:10], Joe Perches wrote:
> Use the normal return values for bool functions
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/char/virtio_console.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> index 72d7028..50754d20 100644
> --- a/drivers/char/virtio_console.c
> +++ b/drivers/char/virtio_console.c
> @@ -355,7 +355,7 @@ static inline bool use_multiport(struct ports_device 
> *portdev)
>* early_init
>*/
>   if (!portdev->vdev)
> - return 0;
> + return false;

Reviewed-by: Amit Shah 

Amit
--
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 1/2] seccomp.2: Explain blacklisting problems, expand example

2015-03-30 Thread Michael Kerrisk (man-pages)
Hi Jann,

Thanks for the patch. I've applied it.

Cheers,

Michael


On 03/24/2015 07:38 PM, Jann Horn wrote:
> ---
>  man2/seccomp.2 | 73 
> +-
>  1 file changed, 67 insertions(+), 6 deletions(-)
> 
> diff --git a/man2/seccomp.2 b/man2/seccomp.2
> index e2a5060..b596fb8 100644
> --- a/man2/seccomp.2
> +++ b/man2/seccomp.2
> @@ -250,6 +250,55 @@ struct seccomp_data {
>  .fi
>  .in
>  
> +Because the numbers of system calls vary between architectures and
> +some architectures (e.g. X86-64) allow user-space code to use
> +the calling conventions of multiple architectures, it is usually
> +necessary to verify the value of the
> +.IR arch
> +field.
> +
> +It is strongly recommended to use a whitelisting approach whenever
> +possible because such an approach is more robust and simple.
> +A blacklist will have to be updated whenever a potentially
> +dangerous syscall is added (or a dangerous flag or option if those
> +are blacklisted), and it is often possible to alter the
> +representation of a value without altering its meaning, leading to
> +a blacklist bypass.
> +
> +The
> +.IR arch
> +field is not unique for all calling conventions. The X86-64 ABI and
> +the X32 ABI both use
> +.BR AUDIT_ARCH_X86_64
> +as
> +.IR arch ,
> +and they run on the same processors. Instead, the mask
> +.BR __X32_SYSCALL_BIT
> +is used on the system call number to tell the two ABIs apart.
> +This means that in order to create a seccomp-based
> +blacklist for system calls performed through the X86-64 ABI,
> +it is necessary to not only check that
> +.IR arch
> +equals
> +.BR AUDIT_ARCH_X86_64 ,
> +but also to explicitly reject all syscalls that contain
> +.BR __X32_SYSCALL_BIT
> +in
> +.IR nr .
> +
> +When checking values from
> +.IR args
> +against a blacklist, keep in mind that arguments are often
> +silently truncated before being processed, but after the seccomp
> +check. For example, this happens if the i386 ABI is used on an
> +X86-64 kernel: Although the kernel will normally not look beyond
> +the 32 lowest bits of the arguments, the values of the full
> +64-bit registers will be present in the seccomp data. A less
> +surprising example is that if the X86-64 ABI is used to perform
> +a syscall that takes an argument of type int, the
> +more-significant half of the argument register is ignored by
> +the syscall, but visible in the seccomp data.
> +
>  A seccomp filter returns a 32-bit value consisting of two parts:
>  the most significant 16 bits
>  (corresponding to the mask defined by the constant
> @@ -616,38 +665,50 @@ cecilia
>  #include 
>  #include 
>  
> +#define X32_SYSCALL_BIT 0x4000
> +
>  static int
>  install_filter(int syscall_nr, int t_arch, int f_errno)
>  {
> +unsigned int upper_nr_limit = 0x;
> +/* assume that AUDIT_ARCH_X86_64 means the normal X86-64 ABI */
> +if (t_arch == AUDIT_ARCH_X86_64)
> +upper_nr_limit = X32_SYSCALL_BIT - 1;
> +
>  struct sock_filter filter[] = {
>  /* [0] Load architecture from 'seccomp_data' buffer into
> accumulator */
>  BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
>   (offsetof(struct seccomp_data, arch))),
>  
> -/* [1] Jump forward 4 instructions if architecture does not
> +/* [1] Jump forward 5 instructions if architecture does not
> match 't_arch' */
> -BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 4),
> +BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 5),
>  
>  /* [2] Load system call number from 'seccomp_data' buffer into
> accumulator */
>  BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
>   (offsetof(struct seccomp_data, nr))),
>  
> -/* [3] Jump forward 1 instruction if system call number
> +/* [3] Check ABI - only needed for X86-64 in blacklist usecases.
> +   Use JGT instead of checking against the bitmask to avoid
> +   having to reload the syscall number. */
> +BPF_JUMP(BPF_JMP | BPF_JGT | BPF_K, upper_nr_limit, 3, 0),
> +
> +/* [4] Jump forward 1 instruction if system call number
> does not match 'syscall_nr' */
>  BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, syscall_nr, 0, 1),
>  
> -/* [4] Matching architecture and system call: don't execute
> +/* [5] Matching architecture and system call: don't execute
>  the system call, and return 'f_errno' in 'errno' */
>  BPF_STMT(BPF_RET | BPF_K,
>   SECCOMP_RET_ERRNO | (f_errno & SECCOMP_RET_DATA)),
>  
> -/* [5] Destination of system call number mismatch: allow other
> +/* [6] Destination of system call number mismatch: allow other
> system calls */
>  BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),
>  
> -/* [6] Destination of architecture mismatch: kill process */
> +/* [7] Destination of architecture mismatch: kill process */
>

Re: [PATCH 3/4] mm: move lazy free pages to inactive list

2015-03-30 Thread Andrew Morton
On Tue, 31 Mar 2015 13:45:25 +0900 Minchan Kim  wrote:
> > 
> > deactivate_page() doesn't look at or alter PageReferenced().  Should it?
> 
> Absolutely true. Thanks.
> Here it goes.
> 
> >From 2b2c92eb73a1cceac615b9abd4c0f5f0c3395ff5 Mon Sep 17 00:00:00 2001
> From: Minchan Kim 
> Date: Tue, 31 Mar 2015 13:38:46 +0900
> Subject: [PATCH] mm: lru_deactivate_fn should clear PG_referenced
> 
> deactivate_page aims for accelerate for reclaiming through
> moving pages from active list to inactive list so we should
> clear PG_referenced for the goal.
> 
> ...
>
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -800,6 +800,7 @@ static void lru_deactivate_fn(struct page *page, struct 
> lruvec *lruvec,
>  
>   del_page_from_lru_list(page, lruvec, lru + LRU_ACTIVE);
>   ClearPageActive(page);
> + ClearPageReferenced(page);
>   add_page_to_lru_list(page, lruvec, lru);
>  
>   __count_vm_event(PGDEACTIVATE);

What if we have

PageLRU(page) && !PageActive(page) && PageReferenced(page)

if we really want to "accelerate the reclaim of @page" then we should
clear PG_referenced there too.

(And what about page_referenced(page) :))
--
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: Support of usb_phy notifier in generic phy.

2015-03-30 Thread Kishon Vijay Abraham I

Hi,

On Friday 27 March 2015 01:37 PM, Anjana V Kumar wrote:

Hi Kishon

This is regarding the notification of usb_phy_events option which was
available with usb_phy.

In my scenario, the phy driver gets the connect/disconnect event, and
does the initial phy programming. Then I want to notify the gadget
driver of the same.

In usb_phy the notifier option was available, which I could use for the same.

Can you please help me understand if,

1. there a plan to add notifications support to the generic phy?
2. If not, is there other option I can use for the same.


IMO individual PHY drivers should use extcon framework to notify events
to the gadget driver.

Cheers
Kishon
--
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] dmaengine: pl330: fix the race condition in pl330 driver.

2015-03-30 Thread Jassi Brar
On Tue, Mar 31, 2015 at 9:10 AM, Scott Branden  wrote:
> Hi Vinod, Jassi,
>
> Some details on the problem encountered.
>
>
> On 15-03-30 10:25 AM, Vinod Koul wrote:
>>
>> On Mon, Mar 30, 2015 at 10:17:17PM +0530, Jassi Brar wrote:
>>>
>>> On Fri, Mar 27, 2015 at 5:25 AM, Scott Branden 
>>> wrote:

 From: ismail 

 Update the thread running index before issuing the
 GO command to the DMAC.

 Tested-by: Mohamed Ismail Abdul Packir Mohamed 
 Reviewed-by: Ray Jui 
 Reviewed-by: Arun Parameswaran 
 Reviewed-by: Scott Branden 
 Signed-off-by: Scott Branden 
 Signed-off-by: Mohamed Ismail Abdul Packir Mohamed 
 ---
   drivers/dma/pl330.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 0e1f567..631642d 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -1072,11 +1072,11 @@ static bool _trigger(struct pl330_thread *thrd)
  /* Set to generate interrupts for SEV */
  writel(readl(regs + INTEN) | (1 << thrd->ev), regs + INTEN);

 +   thrd->req_running = idx;
 +
  /* Only manager can execute GO */
  _execute_DBGINSN(thrd, insn, true);

 -   thrd->req_running = idx;
 -
>>>
>>> It would help to know what the behavior looks like before and after
>>> the patch. If anything we should look at locking rather the
>>> reordering.
>>
>> Yes that ia fair request, looking at changelog it is hard to understand
>> the
>> issue seen?
>>
> We encountered this problem as we modified the driver to make SMC calls to a
> TZ handler.  This slowed down the driver to the point where DMA transactions
> easily failed.  I believe the same could be accomplished by adding a delay
> between the GOCMD and update of the req_running and running the built in
> dmatest.
>
> The DMA transaction is broken if the interrupt occurs before the
> thrd->req_running is updated.
>
> The pl330 issues a GOCMD (in _trigger function) to start a new transfer.
>
> The issue of GOCMD generates an interrupt and the IRQ handler will call the
> pl330_update function to process the interrupt.
>
> The pl330_update function will verify the thread running index and break the
> transaction, if the thread running index is not set.
>
As I suspected the locking seems screwed up. The following patch
should fix the race properly. Can you please test the attached patches
instead?

Thanks.
From 1c44fc936d05fef3259354da1574c536ed1691c7 Mon Sep 17 00:00:00 2001
From: Jassi Brar 
Date: Tue, 31 Mar 2015 10:16:46 +0530
Subject: [PATCH 1/2] dma: pl330: change busy marker for threads

Instead of a boolean flag to mark a thread busy, use the owner of
the thread as the marker. For free/available threads, the owner is
NULL. This will be useful in finding which channel owns a given
thread.

Signed-off-by: Jassi Brar 
---
 drivers/dma/pl330.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 0e1f567..d1f777e 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -369,8 +369,7 @@ struct _pl330_tbd {
 struct pl330_thread {
 	u8 id;
 	int ev;
-	/* If the channel is not yet acquired by any client */
-	bool free;
+	struct dma_pl330_chan *pch;
 	/* Parent DMAC */
 	struct pl330_dmac *dmac;
 	/* Only two at a time */
@@ -1648,7 +1647,8 @@ static bool _chan_ns(const struct pl330_dmac *pl330, int i)
 /* Upon success, returns IdentityToken for the
  * allocated channel, NULL otherwise.
  */
-static struct pl330_thread *pl330_request_channel(struct pl330_dmac *pl330)
+static struct pl330_thread *pl330_request_channel(struct pl330_dmac *pl330,
+		  struct dma_pl330_chan *pch)
 {
 	struct pl330_thread *thrd = NULL;
 	unsigned long flags;
@@ -1663,11 +1663,11 @@ static struct pl330_thread *pl330_request_channel(struct pl330_dmac *pl330)
 
 	for (i = 0; i < chans; i++) {
 		thrd = >channels[i];
-		if ((thrd->free) && (!_manager_ns(thrd) ||
+		if (!thrd->pch && (!_manager_ns(thrd) ||
 	_chan_ns(pl330, i))) {
 			thrd->ev = _alloc_event(thrd);
 			if (thrd->ev >= 0) {
-thrd->free = false;
+thrd->pch = pch;
 thrd->lstenq = 1;
 thrd->req[0].desc = NULL;
 thrd->req[1].desc = NULL;
@@ -1699,7 +1699,7 @@ static void pl330_release_channel(struct pl330_thread *thrd)
 	struct pl330_dmac *pl330;
 	unsigned long flags;
 
-	if (!thrd || thrd->free)
+	if (!thrd || !thrd->pch)
 		return;
 
 	_stop(thrd);
@@ -1711,7 +1711,7 @@ static void pl330_release_channel(struct pl330_thread *thrd)
 
 	spin_lock_irqsave(>lock, flags);
 	_free_event(thrd, thrd->ev);
-	thrd->free = true;
+	thrd->pch = NULL;
 	spin_unlock_irqrestore(>lock, flags);
 }
 
@@ -1797,14 +1797,14 @@ static int dmac_alloc_threads(struct pl330_dmac *pl330)
 		thrd->id = i;
 		thrd->dmac = pl330;
 		_reset_thread(thrd);
-		thrd->free = true;
+		thrd->pch = NULL;
 	}
 
 	/* MANAGER is indexed at 

Re: [PATCH] of: Custom printk format specifier for device node

2015-03-30 Thread Grant Likely
On Thu, 22 Jan 2015 22:31:46 +0200
, Pantelis Antoniou 
 wrote:
> Hi Joe,
> 
> > On Jan 21, 2015, at 19:37 , Joe Perches  wrote:
> > 
> > On Wed, 2015-01-21 at 19:06 +0200, Pantelis Antoniou wrote:
> >> 90% of the usage of device node's full_name is printing it out
> >> in a kernel message. Preparing for the eventual delayed allocation
> >> introduce a custom printk format specifier that is both more
> >> compact and more pleasant to the eye.
> >> 
> >> For instance typical use is:
> >>pr_info("Frobbing node %s\n", node->full_name);
> >> 
> >> Which can be written now as:
> >>pr_info("Frobbing node %pO\n", node);
> 
> > Still disliking use of %p0.
> > 
> 
> pO - Open Firmware
> 
> pT for tree is bad, cause we plan to use a tree type in the future in OF.

So, here's a radical thought. How about we reserve '%pO' for objects, as
in kobjects.  We'll use extra flags to narrow down specifically to
device tree nodes, but we could teach vsprintf() to treat a plain '%pO'
as plain kobject pointer, and if it is able to recognize the kobj_type,
then run a specific decoder to format it.

This also gives us a namespace for various kinds of firmware data
output. %Od could be a struct device, %On for device tree node, %Oa for
an ACPI node, etc.

> 
> >> More fine-grained control of formatting includes printing the name,
> >> flag, path-spec name, reference count and others, explained in the
> >> documentation entry.
> >> 
> >> Signed-off-by: Pantelis Antoniou 
> >> 
> >> dt-print
> >> ---
> >> Documentation/printk-formats.txt |  29 
> >> lib/vsprintf.c   | 151 
> >> +++
> >> 2 files changed, 180 insertions(+)
> >> 
> >> diff --git a/Documentation/printk-formats.txt 
> >> b/Documentation/printk-formats.txt
> >> index 5a615c1..2d42c04 100644
> >> --- a/Documentation/printk-formats.txt
> >> +++ b/Documentation/printk-formats.txt
> >> @@ -231,6 +231,35 @@ struct va_format:
> >>Do not use this feature without some mechanism to verify the
> >>correctness of the format string and va_list arguments.
> >> 
> >> +Device tree nodes:
> >> +
> >> +  %pO[fnpPcCFr]
> >> +
> >> +  For printing device tree nodes. The optional arguments are:
> >> +f device node full_name
> >> +n device node name
> >> +p device node phandle
> >> +P device node path spec (name + @unit)
> >> +F device node flags
> >> +c major compatible string
> >> +C full compatible string
> >> +r node reference count
> >> +  Without any arguments prints full_name (same as %pOf)
> >> +  The separator when using multiple arguments is '|'
> >> +
> >> +  Examples:
> >> +
> >> +  %pO /foo/bar@0  - Node full name
> >> +  %pOf/foo/bar@0  - Same as above
> >> +  %pOfp   /foo/bar@0|10   - Node full name + phandle
> >> +  %pOfcF  /foo/bar@0|foo,device|--P-  - Node full name +
> >> +major compatible string +
> >> +node flags
> >> +  D - dynamic
> >> +  d - detached
> >> +  P - Populated
> >> +  B - Populated bus
> >> +
> >> u64 SHOULD be printed with %llu/%llx:
> >> 
> >>printk("%llu", u64_var);
> >> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > []
> > 
> > Add #ifdef back ?
> > 
> 
> The whole thing is optimized away when CONFIG_OF is not defined, leaving only
> the return statement.
> 
> >> +static noinline_for_stack
> >> +char *device_node_string(char *buf, char *end, struct device_node *dn,
> >> +   struct printf_spec spec, const char *fmt)
> >> +{
> >> +  char tbuf[sizeof("xx") + 1];
> >> +  const char *fmtp, *p;
> >> +  int len, ret, i, j, pass;
> >> +  char c;
> >> +
> >> +  if (!IS_ENABLED(CONFIG_OF))
> >> +  return string(buf, end, "(!OF)", spec);
> > 
> > Not very descriptive output, maybe the address would be better.
> > 
> 
> OK
> 
> >> +
> >> +  if ((unsigned long)dn < PAGE_SIZE)
> >> +  return string(buf, end, "(null)", spec);
> >> +
> >> +  /* simple case without anything any more format specifiers */
> >> +  if (fmt[1] == '\0' || isspace(fmt[1]))
> >> +  fmt = "Of";

s/isspace()/!isalnum() to match with what the pointer() function does
when finding the end of a format string.

> > 
> > why lower case here but upper case above?
> > 
> 
> Cause '(null)' is what’s printed in string() when null is passed as a 
> pointer.
> 
> >> +
> >> +  len = 0;
> >> +
> >> +  /* two passes; the first calculates length, the second fills in */
> >> +  for (pass = 1; pass <= 2; pass++) {
> >> +  if (pass == 2 && !(spec.flags & LEFT)) {
> >> +  /* padding */
> >> +  while (len < 

Re: [PATCH v2 1/6] phy: miphy365x: Use the generic phy type constants in dt-bindings/phy/phy.h

2015-03-30 Thread Kishon Vijay Abraham I

Hi Patrice, Maxime,

On Monday 30 March 2015 08:47 PM, Peter Griffin wrote:

Now there are generic phy type constants declared in phy.h, migrate over to
using them rather than defining our own. This change has been done as one
atomic commit to be bisectable.

Note: The values of the defines are the same, so there is no ABI breakage
with this patch.

Signed-off-by: Peter Griffin 
Acked-by: Rob Herring 
Acked-by: Lee Jones 


Are you okay for this patch to go via PHY tree? It modifies arch/arm/boot/dts
/stih416.dtsi.

Thanks
Kishon

---
  Documentation/devicetree/bindings/phy/phy-miphy365x.txt |  8 
  arch/arm/boot/dts/stih416.dtsi  |  4 ++--
  drivers/phy/phy-miphy365x.c | 14 +++---
  include/dt-bindings/phy/phy-miphy365x.h | 14 --
  4 files changed, 13 insertions(+), 27 deletions(-)
  delete mode 100644 include/dt-bindings/phy/phy-miphy365x.h

diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt 
b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
index 9802d5d..8772900 100644
--- a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -20,8 +20,8 @@ Required nodes:  A sub-node is required for each 
channel the controller
  Required properties (port (child) node):
  - #phy-cells  : Should be 1 (See second example)
  Cell after port phandle is device type from:
-   - MIPHY_TYPE_SATA
-   - MIPHY_TYPE_PCI
+   - PHY_TYPE_SATA
+   - PHY_TYPE_PCI
  - reg : Address and length of register sets for each device in
  "reg-names"
  - reg-names : The names of the register addresses corresponding to the
@@ -68,10 +68,10 @@ property, containing a phandle to the phy port node and a 
device type.

  Example:

-#include 
+#include 

sata0: sata@fe38 {
...
-   phys  = <_port0 MIPHY_TYPE_SATA>;
+   phys  = <_port0 PHY_TYPE_SATA>;
...
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index ea28eba..eeb7afe 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -10,7 +10,7 @@
  #include "stih416-clock.dtsi"
  #include "stih416-pinctrl.dtsi"

-#include 
+#include 
  #include 
  #include 
  / {
@@ -306,7 +306,7 @@
reg = <0xfe38 0x1000>;
interrupts  = ;
interrupt-names = "hostc";
-   phys= <_port0 MIPHY_TYPE_SATA>;
+   phys= <_port0 PHY_TYPE_SATA>;
phy-names   = "sata-phy";
resets  = < STIH416_SATA0_POWERDOWN>,
  < STIH416_SATA0_SOFTRESET>;
diff --git a/drivers/phy/phy-miphy365x.c b/drivers/phy/phy-miphy365x.c
index 51b459d..019c2d7 100644
--- a/drivers/phy/phy-miphy365x.c
+++ b/drivers/phy/phy-miphy365x.c
@@ -25,7 +25,7 @@
  #include 
  #include 

-#include 
+#include 

  #define HFC_TIMEOUT   100

@@ -177,7 +177,7 @@ static u8 rx_tx_spd[] = {
  static int miphy365x_set_path(struct miphy365x_phy *miphy_phy,
  struct miphy365x_dev *miphy_dev)
  {
-   bool sata = (miphy_phy->type == MIPHY_TYPE_SATA);
+   bool sata = (miphy_phy->type == PHY_TYPE_SATA);

return regmap_update_bits(miphy_dev->regmap,
  miphy_phy->ctrlreg,
@@ -431,7 +431,7 @@ static int miphy365x_init(struct phy *phy)
}

/* Initialise Miphy for PCIe or SATA */
-   if (miphy_phy->type == MIPHY_TYPE_PCIE)
+   if (miphy_phy->type == PHY_TYPE_PCIE)
ret = miphy365x_init_pcie_port(miphy_phy, miphy_dev);
else
ret = miphy365x_init_sata_port(miphy_phy, miphy_dev);
@@ -455,8 +455,8 @@ int miphy365x_get_addr(struct device *dev, struct 
miphy365x_phy *miphy_phy,
return ret;
}

-   if (!((!strncmp(name, "sata", 4) && type == MIPHY_TYPE_SATA) ||
- (!strncmp(name, "pcie", 4) && type == MIPHY_TYPE_PCIE)))
+   if (!((!strncmp(name, "sata", 4) && type == PHY_TYPE_SATA) ||
+ (!strncmp(name, "pcie", 4) && type == PHY_TYPE_PCIE)))
return 0;

miphy_phy->base = of_iomap(phynode, index);
@@ -499,8 +499,8 @@ static struct phy *miphy365x_xlate(struct device *dev,

miphy_phy->type = args->args[0];

-   if (!(miphy_phy->type == MIPHY_TYPE_SATA ||
- miphy_phy->type == MIPHY_TYPE_PCIE)) {
+   if (!(miphy_phy->type == PHY_TYPE_SATA ||
+ miphy_phy->type == PHY_TYPE_PCIE)) {
dev_err(dev, "Unsupported device type: %d\n", miphy_phy->type);
return ERR_PTR(-EINVAL);
}
diff --git 

Re: [PATCH RESEND] phy: exynos5-usbdrd: Add to support for Exynos5433 SoC

2015-03-30 Thread Kishon Vijay Abraham I



On Tuesday 31 March 2015 10:36 AM, Jaewon Kim wrote:

Hi Kishon.

Could you check my patch??


sure.. patch looks fine. will queue it.

-Kishon


On 26/03/2015 14:16, Vivek Gautam wrote:

On Thu, Mar 26, 2015 at 7:48 AM, Jaewon Kim  wrote:

This patch adds driver data to support for Exynos5433 SoC.
The Exynos5433 has one USB3.0 Host and USB3.0 DRD(Dual Role Device).
Exynos5433 is simplar to Eyxnos7 but Exynos5433 have
one more USB3.0 Host controller.

Signed-off-by: Jaewon Kim 
Tested-by: Chanwoo Choi 
---

Patch looks good to me.

Reviewed-by: Vivek Gautam 


  .../devicetree/bindings/phy/samsung-phy.txt|3 ++-
  drivers/phy/phy-exynos5-usbdrd.c   |   10 ++
  include/linux/mfd/syscon/exynos5-pmu.h |3 +++
  3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 91e38cf..60c6f2a 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -128,6 +128,7 @@ Required properties:
  - compatible : Should be set to one of the following supported values:
 - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
 - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+   - "samsung,exynos5433-usbdrd-phy" - for exynos5433 SoC.
 - "samsung,exynos7-usbdrd-phy" - for exynos7 SoC.
  - reg : Register offset and length of USB DRD PHY register set;
  - clocks: Clock IDs array as required by the controller
@@ -139,7 +140,7 @@ Required properties:
PHY operations, associated by phy name. It is used to
determine bit values for clock settings register.
For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
-   - optional clocks: Exynos7 SoC has now following additional
+   - optional clocks: Exynos5433 & Exynos7 SoC has now following
additional
gate clocks available:
- phy_pipe: for PIPE3 phy
- phy_utmi: for UTMI+ phy
diff --git a/drivers/phy/phy-exynos5-usbdrd.c
b/drivers/phy/phy-exynos5-usbdrd.c
index e2a0be7..d72ef15 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -624,6 +624,13 @@ static const struct exynos5_usbdrd_phy_drvdata
exynos5250_usbdrd_phy = {
 .has_common_clk_gate= true,
  };

+static const struct exynos5_usbdrd_phy_drvdata exynos5433_usbdrd_phy = {
+   .phy_cfg= phy_cfg_exynos5,
+   .pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
+   .pmu_offset_usbdrd1_phy = EXYNOS5433_USBHOST30_PHY_CONTROL,
+   .has_common_clk_gate= false,
+};
+
  static const struct exynos5_usbdrd_phy_drvdata exynos7_usbdrd_phy = {
 .phy_cfg= phy_cfg_exynos5,
 .pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
@@ -638,6 +645,9 @@ static const struct of_device_id
exynos5_usbdrd_phy_of_match[] = {
 .compatible = "samsung,exynos5420-usbdrd-phy",
 .data = _usbdrd_phy
 }, {
+   .compatible = "samsung,exynos5433-usbdrd-phy",
+   .data = _usbdrd_phy
+   }, {
 .compatible = "samsung,exynos7-usbdrd-phy",
 .data = _usbdrd_phy
 },
diff --git a/include/linux/mfd/syscon/exynos5-pmu.h
b/include/linux/mfd/syscon/exynos5-pmu.h
index 00ef24b..9352adc 100644
--- a/include/linux/mfd/syscon/exynos5-pmu.h
+++ b/include/linux/mfd/syscon/exynos5-pmu.h
@@ -36,6 +36,9 @@
  #define EXYNOS5420_MTCADC_PHY_CONTROL  (0x724)
  #define EXYNOS5420_DPTX_PHY_CONTROL(0x728)

+/* Exynos5433 specific register definitions */
+#define EXYNOS5433_USBHOST30_PHY_CONTROL   (0x728)
+
  #define EXYNOS5_PHY_ENABLE BIT(0)

  #define EXYNOS5_MIPI_PHY_S_RESETN  BIT(1)
--
1.7.9.5

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



Thanks,
Jaewon Kim.

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


Re: Question on ARC's thread_info

2015-03-30 Thread Vineet Gupta
On Sunday 29 March 2015 04:48 AM, Richard Weinberger wrote:
> Vineet,
>
> I'm working on a patch series which touches sturct thread_info.
> ARC's thread_info has the following comment:
>  * - if the contents of this structure are changed, the assembly constants
>  *   must also be changed
>
> Is this still true? Unless I'm reading the code wrong that case should be
> handled automatically by the asm-offsets mechanism.
> So no manual fixup of magic constants should be needed.


Yep, I think that is the case too - perhaps the comment is dated when we still 
had
magic constants in code :-)
If not I need to fix it anyways so feel free to change it.

-Vineet

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


Re: Re: [Fix kernel crash in cipso_v4_sock_delattr ]

2015-03-30 Thread Maninder Singh
We are currently using 3.10.58 kernel and  we are facing this issue for samck 
enabled system.
and as we can check in other APIs like netlbl_sock_getattr and 
netlbl_conn_setattr have this preventive check so we added this check for 
netlbl_sock_delattr also.

And regarding patch re-submission, actually we have run checkpatch.pl before 
submission(successfull)  But when we submit the patch our editor changes tabs 
into space, we will resubmitt the patch ASAP.

Maninder Singh
--- Original Message ---
Sender : Casey Schaufler
Date : Mar 31, 2015 02:25 (GMT+09:00)
Title : Re: [Fix kernel crash in cipso_v4_sock_delattr ]

On 3/30/2015 4:32 AM, Paul Moore wrote:
> On Monday, March 30, 2015 11:09:00 AM Maninder Singh wrote:
>> Dear All,
>> we found One Kernel Crash issue in cipso_v4_sock_delattr :-
>> As Cipso supports only inet sockets so cipso_v4_sock_delattr will crash when
>> try to access any other socket type.  cipso_v4_sock_delattr access
>> sk_inet->inet_opt which may contain not NULL but invalid address. we found
>> this issue with netlink socket.(reproducible by trinity using sendto system
>> call .) 
> Hello,
>
> First, please go read the Documentation/SubmittingPatches from the kernel 
> sources; your patch needs to be resubmitted and the instructions in that file 
> will show you how to do it correctly next time.
>
> Second, this appears to only affect Smack based systems, yes?  SELinux based 
> systems should have the proper checking in place to prevent this (the checks 
> are handled in the LSM).

This looks like a problem that was fixed some time ago.
The current Smack code clearly checks for this. What kernel
version are you testing against?

> That said, it probably wouldn't hurt to add the 
> extra checking to netlbl_sock_delattr().  If you properly resubmit your patch 
> I'll ACK it.
>
> -Paul
>

Re: [PATCH RESEND] phy: exynos5-usbdrd: Add to support for Exynos5433 SoC

2015-03-30 Thread Jaewon Kim

Hi Kishon.

Could you check my patch??

On 26/03/2015 14:16, Vivek Gautam wrote:

On Thu, Mar 26, 2015 at 7:48 AM, Jaewon Kim  wrote:

This patch adds driver data to support for Exynos5433 SoC.
The Exynos5433 has one USB3.0 Host and USB3.0 DRD(Dual Role Device).
Exynos5433 is simplar to Eyxnos7 but Exynos5433 have
one more USB3.0 Host controller.

Signed-off-by: Jaewon Kim 
Tested-by: Chanwoo Choi 
---

Patch looks good to me.

Reviewed-by: Vivek Gautam 


  .../devicetree/bindings/phy/samsung-phy.txt|3 ++-
  drivers/phy/phy-exynos5-usbdrd.c   |   10 ++
  include/linux/mfd/syscon/exynos5-pmu.h |3 +++
  3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 91e38cf..60c6f2a 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -128,6 +128,7 @@ Required properties:
  - compatible : Should be set to one of the following supported values:
 - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
 - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+   - "samsung,exynos5433-usbdrd-phy" - for exynos5433 SoC.
 - "samsung,exynos7-usbdrd-phy" - for exynos7 SoC.
  - reg : Register offset and length of USB DRD PHY register set;
  - clocks: Clock IDs array as required by the controller
@@ -139,7 +140,7 @@ Required properties:
PHY operations, associated by phy name. It is used to
determine bit values for clock settings register.
For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
-   - optional clocks: Exynos7 SoC has now following additional
+   - optional clocks: Exynos5433 & Exynos7 SoC has now following additional
gate clocks available:
- phy_pipe: for PIPE3 phy
- phy_utmi: for UTMI+ phy
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index e2a0be7..d72ef15 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -624,6 +624,13 @@ static const struct exynos5_usbdrd_phy_drvdata 
exynos5250_usbdrd_phy = {
 .has_common_clk_gate= true,
  };

+static const struct exynos5_usbdrd_phy_drvdata exynos5433_usbdrd_phy = {
+   .phy_cfg= phy_cfg_exynos5,
+   .pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
+   .pmu_offset_usbdrd1_phy = EXYNOS5433_USBHOST30_PHY_CONTROL,
+   .has_common_clk_gate= false,
+};
+
  static const struct exynos5_usbdrd_phy_drvdata exynos7_usbdrd_phy = {
 .phy_cfg= phy_cfg_exynos5,
 .pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
@@ -638,6 +645,9 @@ static const struct of_device_id 
exynos5_usbdrd_phy_of_match[] = {
 .compatible = "samsung,exynos5420-usbdrd-phy",
 .data = _usbdrd_phy
 }, {
+   .compatible = "samsung,exynos5433-usbdrd-phy",
+   .data = _usbdrd_phy
+   }, {
 .compatible = "samsung,exynos7-usbdrd-phy",
 .data = _usbdrd_phy
 },
diff --git a/include/linux/mfd/syscon/exynos5-pmu.h 
b/include/linux/mfd/syscon/exynos5-pmu.h
index 00ef24b..9352adc 100644
--- a/include/linux/mfd/syscon/exynos5-pmu.h
+++ b/include/linux/mfd/syscon/exynos5-pmu.h
@@ -36,6 +36,9 @@
  #define EXYNOS5420_MTCADC_PHY_CONTROL  (0x724)
  #define EXYNOS5420_DPTX_PHY_CONTROL(0x728)

+/* Exynos5433 specific register definitions */
+#define EXYNOS5433_USBHOST30_PHY_CONTROL   (0x728)
+
  #define EXYNOS5_PHY_ENABLE BIT(0)

  #define EXYNOS5_MIPI_PHY_S_RESETN  BIT(1)
--
1.7.9.5

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



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


Re: [PATCH v2] dma: vdma: Fix compilation warnings

2015-03-30 Thread Vinod Koul
On Tue, Mar 31, 2015 at 07:35:43AM +1100, Stephen Rothwell wrote:
Hi Stephen,
>
> On Mon, 30 Mar 2015 22:48:46 +0530 Vinod Koul  wrote:
> >
> > On Mon, Mar 30, 2015 at 06:48:29PM +0530, Kedareswara rao Appana wrote:
> > > This patch fixes the following compilation warnings.
> > > In file included from drivers/dma/xilinx/xilinx_vdma.c:26:0:
> > > include/linux/dmapool.h:18:4: warning: 'struct device' declared inside 
> > > parameter list
> > > size_t size, size_t align, size_t allocation);
> > > ^
> > > include/linux/dmapool.h:18:4: warning: its scope is only this definition 
> > > or declaration, which is probably not what you want
> > > include/linux/dmapool.h:31:7: warning: 'struct device' declared inside 
> > > parameter list
> > >size_t size, size_t align, size_t allocation);
> > >^
> > > drivers/dma/xilinx/xilinx_vdma.c: In function 
> > > 'xilinx_vdma_alloc_chan_resources':
> > > drivers/dma/xilinx/xilinx_vdma.c:501:20: warning: passing argument 2 of 
> > > 'dma_pool_create' from incompatible pointer type
> > >   chan->desc_pool = dma_pool_create("xilinx_vdma_desc_pool",
> > > ^
> > > In file included from drivers/dma/xilinx/xilinx_vdma.c:26:0:
> > > include/linux/dmapool.h:17:18: note: expected 'struct device *' but 
> > > argument is of type 'struct device *'
> > >  struct dma_pool *dma_pool_create(const char *name, struct device *dev, .
> > > 
> > Well this does fix this error but this can also be fixed by rearranging the
> > driver header files order.  Since I am not inclined to update a patch for
> > dmapool.h I would go for rearranging drivers header
> > 
> > --><8---><8--
> > 
> > diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> > b/drivers/dma/xilinx/xilinx_vdma.c
> > index d8434d465885..356ca4bc0ea5 100644
> > --- a/drivers/dma/xilinx/xilinx_vdma.c
> > +++ b/drivers/dma/xilinx/xilinx_vdma.c
> > @@ -23,12 +23,12 @@
> >   */
> > 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > 
> > Any objections?
> 
> Yes.  The error is in dmapool.h so it should be fixed once and for
> all.  The supplied patch is very unintrusive and means that the problem
> won't reappear when someone does some rearrangement of includes in the
> future.  The file in question really has no particular maintainer.
> Even after your suggested patch, dmapool.h still depend on an implicit
> include of device.h.
I agree with your points, but isnt the order of headers also a thumb rule.
Typicaly a driver file will include core includes followed by subsystem
specfic includes.

Should a header have no dependency for its include ? I do come across
multiple examples of this in kernel

Yes fixing it in dmapool is also correct, so should we move to having
headers agnostic to the order of inclusion eventually ?

Thanks
-- 
~Vinod


signature.asc
Description: Digital signature


Re: smp_call_function_single lockups

2015-03-30 Thread Linus Torvalds
On Mon, Mar 30, 2015 at 8:15 PM, Chris J Arges
 wrote:
> [   13.613531] WARNING: CPU: 0 PID: 0 at ./arch/x86/include/asm/apic.h:444 
> apic_ack_edge+0x84/0x90()
> [   13.613531]  [] apic_ack_edge+0x84/0x90
> [   13.613531]  [] handle_edge_irq+0x57/0x120
> [   13.613531]  [] handle_irq+0x22/0x40
> [   13.613531]  [] do_IRQ+0x4f/0x140
> [   13.613531]  [] common_interrupt+0x6d/0x6d
> [   13.613531][] ? hrtimer_start+0x18/0x20
> [   13.613531]  [] ? native_safe_halt+0x6/0x10
> [   13.613531]  [] ? rcu_eqs_enter+0xa3/0xb0
> [   13.613531]  [] default_idle+0x1e/0xc0

Hmm. I didn't notice that "hrtimer_start" was always there as a stale
entry on the stack when this happened.

That may well be immaterial - the CPU being idle means that the last
thing it did before going to sleep was likely that "start timer"
thing, but it's interesting even so.

Some issue with reprogramming the hrtimer as it is triggering, kind of
similar to the bootup case I saw where the keyboard init sequence
raises an interrupt that was already cleared by the time the interrupt
happened.

So maybe something like this happens:

 - local timer is about to go off and raises the interrupt line

 - in the meantime, we're reprogramming the timer into the future

 - the CPU takes the interrupt, but now the timer has been
reprogammed, so the irq line is no longer active, and ISR is zero even
though we took the interrupt (which is why the new warning triggers)

  - we're running the local timer interrupt (which happened due to the
*old* programmed value), but we do something wrong because when we
read the timer state, we see the *new* programmed value and so we
think that it's the new timer that triggered.

I dunno. I don't see why we'd lock up, but DaveJ's old lockup had
several signs that it seemed to be timer-related.

It would be interesting to see the actual irq number. Maybe this has
nothing what-so-ever to do with the hrtimer.

  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 3/4] mm: move lazy free pages to inactive list

2015-03-30 Thread Minchan Kim
Hello Andrew,

On Mon, Mar 30, 2015 at 02:20:10PM -0700, Andrew Morton wrote:
> On Mon, 30 Mar 2015 14:35:02 +0900 Minchan Kim  wrote:
> 
> > --- a/mm/swap.c
> > +++ b/mm/swap.c
> > @@ -866,6 +866,13 @@ void deactivate_file_page(struct page *page)
> > }
> >  }
> >  
> > +/**
> > + * deactivate_page - deactivate a page
> > + * @page: page to deactivate
> > + *
> > + * This function moves @page to inactive list if @page was on active list 
> > and
> > + * was not unevictable page to accelerate to reclaim @page.
> > + */
> >  void deactivate_page(struct page *page)
> >  {
> > if (PageLRU(page) && PageActive(page) && !PageUnevictable(page)) {
> 
> Thanks.
> 
> deactivate_page() doesn't look at or alter PageReferenced().  Should it?

Absolutely true. Thanks.
Here it goes.

>From 2b2c92eb73a1cceac615b9abd4c0f5f0c3395ff5 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Tue, 31 Mar 2015 13:38:46 +0900
Subject: [PATCH] mm: lru_deactivate_fn should clear PG_referenced

deactivate_page aims for accelerate for reclaiming through
moving pages from active list to inactive list so we should
clear PG_referenced for the goal.

Suggested-by: Andrew Morton 
Signed-off-by: Minchan Kim 
---
 mm/swap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/swap.c b/mm/swap.c
index b65fc8c..6b420022 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -800,6 +800,7 @@ static void lru_deactivate_fn(struct page *page, struct 
lruvec *lruvec,
 
del_page_from_lru_list(page, lruvec, lru + LRU_ACTIVE);
ClearPageActive(page);
+   ClearPageReferenced(page);
add_page_to_lru_list(page, lruvec, lru);
 
__count_vm_event(PGDEACTIVATE);
-- 
1.9.3



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


Re: [PATCH] [RESEND] drivers: bus: omap_l3: remove deprecated IRQF_DISABLED

2015-03-30 Thread Nishanth Menon
On 03/26/2015 08:11 PM, Michael Opdenacker wrote:
> This patch removes the use of the IRQF_DISABLED flag
> from drivers/bus/omap_l3_*
> 
> It's a NOOP since 2.6.35 and it will be removed one day.
> 
> Signed-off-by: Michael Opdenacker 
> Acked-by: Santosh Shilimkar 

Acked-by: Nishanth Menon 

> ---
>  drivers/bus/omap_l3_noc.c | 4 ++--
>  drivers/bus/omap_l3_smx.c | 6 ++
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
> index 029bc73de001..602298b527e8 100644
> --- a/drivers/bus/omap_l3_noc.c
> +++ b/drivers/bus/omap_l3_noc.c
> @@ -284,7 +284,7 @@ static int omap_l3_probe(struct platform_device *pdev)
>*/
>   l3->debug_irq = platform_get_irq(pdev, 0);
>   ret = devm_request_irq(l3->dev, l3->debug_irq, l3_interrupt_handler,
> -IRQF_DISABLED, "l3-dbg-irq", l3);
> +0, "l3-dbg-irq", l3);
>   if (ret) {
>   dev_err(l3->dev, "request_irq failed for %d\n",
>   l3->debug_irq);
> @@ -293,7 +293,7 @@ static int omap_l3_probe(struct platform_device *pdev)
>  
>   l3->app_irq = platform_get_irq(pdev, 1);
>   ret = devm_request_irq(l3->dev, l3->app_irq, l3_interrupt_handler,
> -IRQF_DISABLED, "l3-app-irq", l3);
> +0, "l3-app-irq", l3);
>   if (ret)
>   dev_err(l3->dev, "request_irq failed for %d\n", l3->app_irq);
>  
> diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
> index 597fdaee7315..0b07895f2eb4 100644
> --- a/drivers/bus/omap_l3_smx.c
> +++ b/drivers/bus/omap_l3_smx.c
> @@ -252,8 +252,7 @@ static int omap3_l3_probe(struct platform_device *pdev)
>  
>   l3->debug_irq = platform_get_irq(pdev, 0);
>   ret = request_irq(l3->debug_irq, omap3_l3_app_irq,
> - IRQF_DISABLED | IRQF_TRIGGER_RISING,
> - "l3-debug-irq", l3);
> + IRQF_TRIGGER_RISING, "l3-debug-irq", l3);
>   if (ret) {
>   dev_err(>dev, "couldn't request debug irq\n");
>   goto err1;
> @@ -261,8 +260,7 @@ static int omap3_l3_probe(struct platform_device *pdev)
>  
>   l3->app_irq = platform_get_irq(pdev, 1);
>   ret = request_irq(l3->app_irq, omap3_l3_app_irq,
> - IRQF_DISABLED | IRQF_TRIGGER_RISING,
> - "l3-app-irq", l3);
> + IRQF_TRIGGER_RISING, "l3-app-irq", l3);
>   if (ret) {
>   dev_err(>dev, "couldn't request app irq\n");
>   goto err2;
> 


-- 
Regards,
Nishanth Menon
--
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] mm: make every pte dirty on do_swap_page

2015-03-30 Thread Minchan Kim
On Tue, Mar 31, 2015 at 12:14:46AM +0300, Cyrill Gorcunov wrote:
> On Mon, Mar 30, 2015 at 05:59:15PM +0900, Minchan Kim wrote:
> > Hi Cyrill,
> > 
> > On Mon, Mar 30, 2015 at 11:51:12AM +0300, Cyrill Gorcunov wrote:
> > > On Mon, Mar 30, 2015 at 02:22:50PM +0900, Minchan Kim wrote:
> > > > 2nd description trial.
> > > ...
> > > Hi Minchan, could you please point for which repo this patch,
> > > linux-next?
> > 
> > It was based on v4.0-rc5-mmotm-2015-03-24-17-02.
> > As well, I confirmed it was applied on local-next-20150327.
> > 
> > Thanks.
> 
> Hi Minchan! I managed to fetch mmotm and the change looks
> reasonable to me. Still better to wait for review from Mel
> or Hugh, maybe I miss something obvious.

Thanks for the review!

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


Re: smp_call_function_single lockups

2015-03-30 Thread Linus Torvalds
On Mon, Mar 30, 2015 at 8:15 PM, Chris J Arges
 wrote:
>
> I've been able to repro with your patch and observed the WARN_ON when booting 
> a
> VM on affected hardware and non affected hardware:

Ok, interesting. So the whole "we try to do an APIC ACK with the ISR
bit clear" seems to be a real issue.

> I modified the posted patch with the following:
> -   WARN_ON_ONCE(!(v & 1));
> +   WARN(!(v & 1), "ack_APIC_irq: vector = %0x\n", vector);

Yes, makes sense, although I'm not sure what the vector translations
end up being. See below.

> And it showed vector = 1b when booting. However, when I run the reproducer on
> an affected machine I get the following WARNs before the hang:

Ok, so the boot-time thing I think happens because a device irq
happens but goes away immediately because the CPU that triggers it
also clears it immediately in the device initialization code, so it's
a level-triggered interrupt that goes away "on its own".

But vector 0x1b seems odd. I thought we mapped external interrupts to
0x20+ (FIRST_EXTERNAL_VECTOR). Ingo/Peter? Is there any sane interface
to look up the percpu apic vector data?

Chris, since this is repeatable for you, can you do

int irq;
irq = __this_cpu_read(vector_irq[vector]);

and print that out too? That *should* show the actual hardware irq,
although there are a few magic cases too (-1/-2 mean special things)

But the fact that you get the warning before the hang is much more interesting.

> [   36.301299] WARNING: CPU: 0 PID: 0 at ./arch/x86/include/asm/apic.h:444 
> apic_ack_edge+0x93/0xa0()
> [   36.301301] ack_APIC_irq: vector = e1

Is this repeatable? Does it happen before *every* hang, or at least
often enough to be a good pattern?

> [   40.430533] ack_APIC_irq: vector = 22
>
> So vector = e1 then 22 before the hang.

Is it always the same ones? I assume that on different machines the
vector allocations would be different, but is it consistent on any
particular machine? That's assuming the whole warning is consistent at
all before the hang, of course.

> Anyway, maybe this sheds some more light on this issue. I can reproduce this 
> at
> will, so let me know of other experiments to do.

Somebody else who knows the apic needs to also take a look, but I'd
love to hear what the actual hardware interrupt is (from that
"vector_irq[vector]" thing above.

I'm not recognizing 0xe1 as any of the hardcoded SMP vectors (they are
0xf0-0xff), so it sounds like an external one. But that then requires
the whole mapping table thing.

Ingo/Peter/Jiang - is there anything else useful we could print out? I
worry about the irq movement code. Can we add printk's to when an irq
is chasing from one CPU to another and doing that "move_in_progress"
thing? I've always been scared of that code.

  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: [v3, 3/3] powerpc/powernv: Introduce sysfs control for fastsleep workaround behavior

2015-03-30 Thread Michael Ellerman
On Mon, 2015-03-30 at 22:45 +0530, Shreyas B Prabhu wrote:
> On Monday 30 March 2015 03:51 PM, Michael Ellerman wrote:
> > 
> > This sounds good, although the name is a bit vague.
 
> How about "fastsleep_workaround_permanent", with default value = 0. User
> can make workaround permanent by echoing 1 to it.

Yeah that's OK.

cheers


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


Re: [PATCH] Input: ALPS - fix max coordinates for v5 and v7 protocols

2015-03-30 Thread Luca Coelho
On Sat, 2015-03-21 at 20:36 -0700, Dmitry Torokhov wrote:
> Commit 3296f71cd2fde7a2ad52e66a27eae419f6328066 ("Input: ALPS - consolidate
> setting protocol parameters") inadvertently moved call to
> alps_dolphin_get_device_area() from v5 to v7 protocol, causing both
> protocols report incorrect maximum values for X and Y axes which resulted
> in crash in Synaptics X driver.
> 
> Reported-by: Santiago Gala 
> Reported-by: Pali Rohár 
> Signed-off-by: Dmitry Torokhov 
> ---

Tested-by: Luciano Coelho 

Tested on a Dell E5250.

Are you planning to send this to 4.0-rc*? That would be nice, since this
is a regression from 3.19.

--
Cheers,
Luca.

--
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] crypto: omap-sham: Use pm_runtime_irq_safe()

2015-03-30 Thread Lokesh Vutla
omap_sham_handle_queue() can be called as part of done_task tasklet.
During this its atomic and any calls to pm functions cannot sleep.

But there is a call to pm_runtime_get_sync() (which can sleep) in
omap_sham_handle_queue(), because of which the following appears:
" [  116.169969] BUG: scheduling while atomic: kworker/0:2/2676/0x0100"

Add pm_runtime_irq_safe() to avoid this.

Signed-off-by: Lokesh Vutla 
---
 drivers/crypto/omap-sham.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index ace5852..81ed511 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1949,6 +1949,7 @@ static int omap_sham_probe(struct platform_device *pdev)
dd->flags |= dd->pdata->flags;
 
pm_runtime_enable(dev);
+   pm_runtime_irq_safe(dev);
pm_runtime_get_sync(dev);
rev = omap_sham_read(dd, SHA_REG_REV(dd));
pm_runtime_put_sync(>dev);
-- 
1.9.1

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


[PATCH] crypto: omap-aes: Fix support for unequal lengths

2015-03-30 Thread Lokesh Vutla
For cases where total length of an input SGs is not same as
length of the input data for encryption, omap-aes driver
crashes. This happens in the case when IPsec is trying to use
omap-aes driver.

To avoid this, we copy all the pages from the input SG list
into a contiguous buffer and prepare a single element SG list
for this buffer with length as the total bytes to crypt, which is
similar thing that is done in case of unaligned lengths.

Fixes: 6242332ff2f3 ("crypto: omap-aes - Add support for cases of unaligned 
lengths")
Signed-off-by: Lokesh Vutla 
---
 drivers/crypto/omap-aes.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 42f95a4..9a28b7e 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -554,15 +554,23 @@ static int omap_aes_crypt_dma_stop(struct omap_aes_dev 
*dd)
return err;
 }
 
-static int omap_aes_check_aligned(struct scatterlist *sg)
+static int omap_aes_check_aligned(struct scatterlist *sg, int total)
 {
+   int len = 0;
+
while (sg) {
if (!IS_ALIGNED(sg->offset, 4))
return -1;
if (!IS_ALIGNED(sg->length, AES_BLOCK_SIZE))
return -1;
+
+   len += sg->length;
sg = sg_next(sg);
}
+
+   if (len != total)
+   return -1;
+
return 0;
 }
 
@@ -633,8 +641,8 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
dd->in_sg = req->src;
dd->out_sg = req->dst;
 
-   if (omap_aes_check_aligned(dd->in_sg) ||
-   omap_aes_check_aligned(dd->out_sg)) {
+   if (omap_aes_check_aligned(dd->in_sg, dd->total) ||
+   omap_aes_check_aligned(dd->out_sg, dd->total)) {
if (omap_aes_copy_sgs(dd))
pr_err("Failed to copy SGs for unaligned cases\n");
dd->sgs_copied = 1;
-- 
1.9.1

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


[PATCH] crypto: omap-sham: Check for HIGHMEM before mapping SG pages

2015-03-30 Thread Lokesh Vutla
Commit 26a05489ee0e ("crypto: omap-sham - Map SG pages if they are HIGHMEM 
before accessing")
says that HIGHMEM pages may not be mapped so we must
kmap them before accessing, but it doesn't check whether the
corresponding page is in highmem or not. Because of this all
the crypto tests are failing.

: d9 a1 1b 7c aa 90 3b aa 11 ab cb 25 00 b8 ac bf
[2.338169] 0010: c1 39 cd ff 48 d0 a8 e2 2b fa 33 a1
[2.344008] alg: hash: Chunking test 1 failed for omap-sha256

So Checking for HIGHMEM before mapping SG pages.

Fixes: 26a05489ee0 ("crypto: omap-sham - Map SG pages if they are HIGHMEM 
before accessing")
Signed-off-by: Lokesh Vutla 
---
 drivers/crypto/omap-sham.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 3c76696..ace5852 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -639,13 +639,17 @@ static size_t omap_sham_append_sg(struct omap_sham_reqctx 
*ctx)
const u8 *vaddr;
 
while (ctx->sg) {
-   vaddr = kmap_atomic(sg_page(ctx->sg));
+   if (PageHighMem(sg_page(ctx->sg)))
+   vaddr = kmap_atomic(sg_page(ctx->sg));
+   else
+   vaddr = sg_virt(ctx->sg);
 
count = omap_sham_append_buffer(ctx,
vaddr + ctx->offset,
ctx->sg->length - ctx->offset);
 
-   kunmap_atomic((void *)vaddr);
+   if (PageHighMem(sg_page(ctx->sg)))
+   kunmap_atomic((void *)vaddr);
 
if (!count)
break;
-- 
1.9.1

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


Re: d63e2e1f3df breaks sparc/T5-8

2015-03-30 Thread David Ahern

On 3/30/15 7:06 PM, Yinghai Lu wrote:

ok, that is really non-pref mmio 64bit.
We can workaround the problem by honoring firmware setting, according
to 
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13

Please check attached updated patches that should fix the regression
and kill those "no compatible window" warnings.


To make sure I am on the same page: these are a new round of patches? 
clear out the old, apply these?


David

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


Re: [PATCH] ARM: dts: Use define for s3c-rtc clock id

2015-03-30 Thread Chanwoo Choi
Hi,

On 03/31/2015 12:21 AM, Krzysztof Kozlowski wrote:
> Use a define instead of raw number as a ID for "rtc_src" clock.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Patch depends on new file "dt-bindings/clock/samsung,s2mps11.h" from:
> http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg43136.html
> ---
>  arch/arm/boot/dts/exynos3250-rinato.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
> b/arch/arm/boot/dts/exynos3250-rinato.dts
> index 3905824cac58..d2cbc95364de 100644
> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
> @@ -16,6 +16,7 @@
>  #include "exynos3250.dtsi"
>  #include 
>  #include 
> +#include 
>  
>  / {
>   model = "Samsung Rinato board";
> @@ -605,7 +606,7 @@
>  };
>  
>   {
> - clocks = < CLK_RTC>, <_osc 0>;
> + clocks = < CLK_RTC>, <_osc S2MPS11_CLK_AP>;
>   clock-names = "rtc", "rtc_src";
>   status = "okay";
>  };
> 

Looks good to me.

Reviewed-by: Chanwoo Choi 

Thanks,
Chanwoo Choi

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


Re: [PATCH 4/9 net-next] ipv6: replace if/BUG by BUG_ON

2015-03-30 Thread YOSHIFUJI Hideaki
Hi,

Fabian Frederick wrote:
> Signed-off-by: Fabian Frederick 
> ---
>  net/ipv6/addrconf.c | 3 +--
>  net/ipv6/esp6.c | 3 +--
>  net/ipv6/netfilter/nf_conntrack_reasm.c | 3 +--
>  3 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 2660263..e205918 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -4805,8 +4805,7 @@ static int inet6_set_link_af(struct net_device *dev, 
> const struct nlattr *nla)
>   if (!idev)
>   return -EAFNOSUPPORT;
>  
> - if (nla_parse_nested(tb, IFLA_INET6_MAX, nla, NULL) < 0)
> - BUG();
> + BUG_ON(nla_parse_nested(tb, IFLA_INET6_MAX, nla, NULL) < 0);
>  

NACK, I do not prefer using BUG_ON() with side effects.

--yoshfuji

>   if (tb[IFLA_INET6_TOKEN]) {
>   err = inet6_set_iftoken(idev, nla_data(tb[IFLA_INET6_TOKEN]));
> diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
> index e48f2c7..9e51b69 100644
> --- a/net/ipv6/esp6.c
> +++ b/net/ipv6/esp6.c
> @@ -280,8 +280,7 @@ static int esp_input_done2(struct sk_buff *skb, int err)
>   if (unlikely(err))
>   goto out;
>  
> - if (skb_copy_bits(skb, skb->len - alen - 2, nexthdr, 2))
> - BUG();
> + BUG_ON(skb_copy_bits(skb, skb->len - alen - 2, nexthdr, 2));
>  
>   err = -EINVAL;
>   padlen = nexthdr[0];
> diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c 
> b/net/ipv6/netfilter/nf_conntrack_reasm.c
> index 6f187c8..cea1a4a 100644
> --- a/net/ipv6/netfilter/nf_conntrack_reasm.c
> +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
> @@ -538,8 +538,7 @@ find_prev_fhdr(struct sk_buff *skb, u8 *prevhdrp, int 
> *prevhoff, int *fhoff)
>   pr_debug("too short\n");
>   return -1;
>   }
> - if (skb_copy_bits(skb, start, , sizeof(hdr)))
> - BUG();
> + BUG_ON(skb_copy_bits(skb, start, , sizeof(hdr)));
>   if (nexthdr == NEXTHDR_AUTH)
>   hdrlen = (hdr.hdrlen+2)<<2;
>   else
> 

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


Re: [PATCH] dmaengine: pl330: fix the race condition in pl330 driver.

2015-03-30 Thread Scott Branden

Hi Vinod, Jassi,

Some details on the problem encountered.

On 15-03-30 10:25 AM, Vinod Koul wrote:

On Mon, Mar 30, 2015 at 10:17:17PM +0530, Jassi Brar wrote:

On Fri, Mar 27, 2015 at 5:25 AM, Scott Branden  wrote:

From: ismail 

Update the thread running index before issuing the
GO command to the DMAC.

Tested-by: Mohamed Ismail Abdul Packir Mohamed 
Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Reviewed-by: Scott Branden 
Signed-off-by: Scott Branden 
Signed-off-by: Mohamed Ismail Abdul Packir Mohamed 
---
  drivers/dma/pl330.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 0e1f567..631642d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1072,11 +1072,11 @@ static bool _trigger(struct pl330_thread *thrd)
 /* Set to generate interrupts for SEV */
 writel(readl(regs + INTEN) | (1 << thrd->ev), regs + INTEN);

+   thrd->req_running = idx;
+
 /* Only manager can execute GO */
 _execute_DBGINSN(thrd, insn, true);

-   thrd->req_running = idx;
-

It would help to know what the behavior looks like before and after
the patch. If anything we should look at locking rather the
reordering.

Yes that ia fair request, looking at changelog it is hard to understand the
issue seen?

We encountered this problem as we modified the driver to make SMC calls 
to a TZ handler.  This slowed down the driver to the point where DMA 
transactions easily failed.  I believe the same could be accomplished by 
adding a delay between the GOCMD and update of the req_running and 
running the built in dmatest.


The DMA transaction is broken if the interrupt occurs before the 
thrd->req_running is updated.


The pl330 issues a GOCMD (in _trigger function) to start a new transfer.

The issue of GOCMD generates an interrupt and the IRQ handler will call 
the pl330_update function to process the interrupt.


The pl330_update function will verify the thread running index and break 
the transaction, if the thread running index is not set.


Regards,
 Scott


--
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/2] i8k.c => dell-smm-hwmon.c

2015-03-30 Thread Guenter Roeck

On 03/29/2015 05:57 AM, Pali Rohár wrote:

This patch series moves drivers/char/i8k.c to drivers/hwmon/dell-smm-hwmon.c
and allows to compile hwmon driver without /proc/i8k file.

Pali Rohár (2):
   hwmon: Rename i8k driver to dell-smm-hwmon and move it to hwmon tree
   hwmon: Allow to compile dell-smm-hwmon driver without /proc/i8k

  MAINTAINERS|4 +-
  arch/x86/Kconfig   |   25 +-
  drivers/char/Makefile  |1 -
  drivers/char/i8k.c | 1005 ---
  drivers/hwmon/Kconfig  |   11 +
  drivers/hwmon/Makefile |1 +
  drivers/hwmon/dell-smm-hwmon.c | 1025 
  7 files changed, 1049 insertions(+), 1023 deletions(-)
  delete mode 100644 drivers/char/i8k.c
  create mode 100644 drivers/hwmon/dell-smm-hwmon.c


I am ok with the series and would take it for 4.1 if Greg agrees.

Greg, any comments ?

Thanks,
Guenter

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


Re: [PATCH] linux/cpumask.h: add typechecking to cpumask_test_cpu

2015-03-30 Thread Rusty Russell
Rasmus Villemoes  writes:
> The Subtlety (1) referred to vanished with 6ba2ef7baac2 ("cpumask:
> Move deprecated functions to end of header."). That used to mention
> some suboptimal code generation by a, by now, rather ancient gcc. With
> gcc 4.7, I don't see any change in the generated code by making it a
> static inline, so let's add type checking and get rid of the ghost
> reference.
>
> Signed-off-by: Rasmus Villemoes 

Thanks, applied.

Cheers,
Rusty.

> ---
>  include/linux/cpumask.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
> index 086549a665e2..972c30e0714e 100644
> --- a/include/linux/cpumask.h
> +++ b/include/linux/cpumask.h
> @@ -289,11 +289,11 @@ static inline void cpumask_clear_cpu(int cpu, struct 
> cpumask *dstp)
>   * @cpumask: the cpumask pointer
>   *
>   * Returns 1 if @cpu is set in @cpumask, else returns 0
> - *
> - * No static inline type checking - see Subtlety (1) above.
>   */
> -#define cpumask_test_cpu(cpu, cpumask) \
> - test_bit(cpumask_check(cpu), cpumask_bits((cpumask)))
> +static inline int cpumask_test_cpu(int cpu, const struct cpumask *cpumask)
> +{
> + return test_bit(cpumask_check(cpu), cpumask_bits((cpumask)));
> +}
>  
>  /**
>   * cpumask_test_and_set_cpu - atomically test and set a cpu in a cpumask
> -- 
> 2.1.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: Revised futex(2) man page for review

2015-03-30 Thread Rusty Russell
"Michael Kerrisk (man-pages)"  writes:
> When executing a futex operation that requests to block a thread,
> the kernel will only block if the futex word has the value that the
> calling thread supplied as expected value.
> The load from the futex word, the comparison with
> the expected value,
> and the actual blocking will happen atomically and totally
> ordered with respect to concurrently executing futex operations
> on the same futex word,
> such as operations that wake threads blocked on this futex word.
> Thus, the futex word is used to connect the synchronization in user spac

Missing 'e' in "space".

> .\" FIXME Please confirm that the following is correct:
> No guarantee is provided about which waiters are awoken
> (e.g., a waiter with a higher scheduling priority is not guaranteed
> to be awoken in preference to a waiter with a lower priority).

This is true.

I didn't read the rest, as that stuff was all written by others.
Documenting them is pretty heroic; good job!

Thanks,
Rusty.
--
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] ARM: dts: mt8173: support arm64 cpuidle-dt

2015-03-30 Thread Howard Chen
add an idle-states node to describe the mt8173 cpu idle
add a reference to the idle-states node in each CPU node

Signed-off-by: Howard Chen 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 8554ec3..96dff1e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -48,6 +48,8 @@
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x000>;
+   enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0_0 _SLEEP_0>;
};
 
cpu1: cpu@1 {
@@ -55,6 +57,7 @@
compatible = "arm,cortex-a53";
reg = <0x001>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0_0 _SLEEP_0>;
};
 
cpu2: cpu@100 {
@@ -62,6 +65,7 @@
compatible = "arm,cortex-a57";
reg = <0x100>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0_0 _SLEEP_0>;
};
 
cpu3: cpu@101 {
@@ -69,15 +73,33 @@
compatible = "arm,cortex-a57";
reg = <0x101>;
enable-method = "psci";
+   cpu-idle-states = <_SLEEP_0_0 _SLEEP_0>;
};
+
+   idle-states {
+   entry-method = "arm,psci-0.2";
+
+   CPU_SLEEP_0_0: cpu-sleep-0-0 {
+   compatible = "arm,idle-state";
+   arm,psci-suspend-param = <0x001>;
+   entry-latency-us = <600>;
+   exit-latency-us = <600>;
+   min-residency-us = <1200>;
+   };
+
+   CLUSTER_SLEEP_0: cluster-sleep-0 {
+   compatible = "arm,idle-state";
+   arm,psci-suspend-param = <0x101>;
+   entry-latency-us = <800>;
+   exit-latency-us = <1000>;
+   min-residency-us = <2000>;
+   wakeup-latency-us = <1000>;
+   };
};
 
psci {
-   compatible = "arm,psci";
+   compatible = "arm,psci-0.2";
method = "smc";
-   cpu_suspend   = <0x8401>;
-   cpu_off   = <0x8402>;
-   cpu_on= <0x8403>;
};
 
uart_clk: dummy26m {
-- 
1.9.1

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


Re: [RFC] bpf: Suggestion on bpf syscall interface

2015-03-30 Thread Alexei Starovoitov

On 3/29/15 8:13 PM, He Kuang wrote:


By using current bpf syscalls, we should keep the program which
attaches bpf programs running background, use it or some other
processes communicate with it to adjust maps parameters, like
sample rate for sys_write.


You can do all of the above by passing fds between processes. I still
don't see a need for sysfs.


In current implementation, we have to use a large and relative
heavy daemon to deal with loading, configuration, adjusting and
unloading works together.


This daemon is actually small and simple.
Just take a look how Daniel did for tc:
http://patchwork.ozlabs.org/patch/456387/
In that example 3 programs are sharing maps and single bpf_agent
monitors maps. Note that tc loaded programs and exited while
agent keeps running. Very straightforward.

--
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] mtd:ts5500_flash: Fix typo in MODULE_DESCRIPTION in ts5500_flash.c

2015-03-30 Thread Brian Norris
On Mon, Mar 30, 2015 at 07:06:22PM +0900, Masanari Iida wrote:
> This patch fix a spelling typo in MODULE_DESCRIPTION in ts5500_flash.c.

Uhh, s/fix/fixes/ ? :)

Fixed and pushed to l2-mtd.git.

Brian

> 
> Signed-off-by: Masanari Iida 
> ---
>  drivers/mtd/maps/ts5500_flash.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/maps/ts5500_flash.c b/drivers/mtd/maps/ts5500_flash.c
> index d1d671d..9969fed 100644
> --- a/drivers/mtd/maps/ts5500_flash.c
> +++ b/drivers/mtd/maps/ts5500_flash.c
> @@ -117,5 +117,5 @@ module_exit(cleanup_ts5500_map);
>  
>  MODULE_LICENSE("GPL");
>  MODULE_AUTHOR("Sean Young ");
> -MODULE_DESCRIPTION("MTD map driver for Techology Systems TS-5500 board");
> +MODULE_DESCRIPTION("MTD map driver for Technology Systems TS-5500 board");
>  
> -- 
> 2.3.4.274.g92e625d
> 
--
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] ASoC: add core audio driver for Broadcom Cygnus SOC.

2015-03-30 Thread Scott Branden
From: Lori Hikichi 

The audio block has 4 serial ports.  3 ports are configurable as
either I2S or TDM.  The 4th port is for SPDIF transmit.

This audio block is found on the bcm958305, bcm958300, and bcm911360.

Reviewed-by: Jonathan Richardson 
Signed-off-by: Lori Hikichi 
Signed-off-by: Scott Branden 
---
 sound/soc/bcm/Kconfig  |   11 +
 sound/soc/bcm/Makefile |5 +-
 sound/soc/bcm/cygnus-pcm.c |  918 +
 sound/soc/bcm/cygnus-pcm.h |   45 ++
 sound/soc/bcm/cygnus-ssp.c | 1613 
 sound/soc/bcm/cygnus-ssp.h |   84 +++
 6 files changed, 2675 insertions(+), 1 deletion(-)
 create mode 100644 sound/soc/bcm/cygnus-pcm.c
 create mode 100644 sound/soc/bcm/cygnus-pcm.h
 create mode 100644 sound/soc/bcm/cygnus-ssp.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.h

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index 6a834e1..2c5ff37 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -7,3 +7,14 @@ config SND_BCM2835_SOC_I2S
  Say Y or M if you want to add support for codecs attached to
  the BCM2835 I2S interface. You will also need
  to select the audio interfaces to support below.
+
+config SND_SOC_CYGNUS
+   tristate "SoC platform audio for Broadcom Cygnus chips"
+   depends on ARCH_BCM_CYGNUS || COMPILE_TEST
+   default ARCH_BCM_CYGNUS
+   help
+ Say Y if you want to add support for ASoC audio on Broadcom
+ Cygnus chips (bcm958300, bcm958305, bcm911360)
+
+ If you don't know what to do here, say N.
+
diff --git a/sound/soc/bcm/Makefile b/sound/soc/bcm/Makefile
index bc816b7..5c39790 100644
--- a/sound/soc/bcm/Makefile
+++ b/sound/soc/bcm/Makefile
@@ -1,5 +1,8 @@
 # BCM2835 Platform Support
 snd-soc-bcm2835-i2s-objs := bcm2835-i2s.o
 
-obj-$(CONFIG_SND_BCM2835_SOC_I2S) += snd-soc-bcm2835-i2s.o
+# CYGNUS Platform Support
+snd-soc-cygnus-objs := cygnus-pcm.o cygnus-ssp.o
 
+obj-$(CONFIG_SND_BCM2835_SOC_I2S) += snd-soc-bcm2835-i2s.o
+obj-$(CONFIG_SND_SOC_CYGNUS) += snd-soc-cygnus.o
diff --git a/sound/soc/bcm/cygnus-pcm.c b/sound/soc/bcm/cygnus-pcm.c
new file mode 100644
index 000..3a4106b
--- /dev/null
+++ b/sound/soc/bcm/cygnus-pcm.c
@@ -0,0 +1,918 @@
+/*
+ * Copyright (C) 2014-2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cygnus-ssp.h"
+#include "cygnus-pcm.h"
+
+/* Register offset needed for ASoC PCM module */
+
+#define INTH_R5F_STATUS_OFFSET 0x040
+#define INTH_R5F_CLEAR_OFFSET  0x048
+#define INTH_R5F_MASK_SET_OFFSET   0x050
+#define INTH_R5F_MASK_CLEAR_OFFSET 0x054
+
+#define BF_REARM_FREE_MARK_OFFSET 0x344
+#define BF_REARM_FULL_MARK_OFFSET 0x348
+
+/* Ring Buffer Ctrl Regs --- Start */
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_RDADDR_REG_BASE */
+#define SRC_RBUF_0_RDADDR_OFFSET 0x500
+#define SRC_RBUF_1_RDADDR_OFFSET 0x518
+#define SRC_RBUF_2_RDADDR_OFFSET 0x530
+#define SRC_RBUF_3_RDADDR_OFFSET 0x548
+#define SRC_RBUF_4_RDADDR_OFFSET 0x560
+#define SRC_RBUF_5_RDADDR_OFFSET 0x578
+#define SRC_RBUF_6_RDADDR_OFFSET 0x590
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_WRADDR_REG_BASE */
+#define SRC_RBUF_0_WRADDR_OFFSET 0x504
+#define SRC_RBUF_1_WRADDR_OFFSET 0x51c
+#define SRC_RBUF_2_WRADDR_OFFSET 0x534
+#define SRC_RBUF_3_WRADDR_OFFSET 0x54c
+#define SRC_RBUF_4_WRADDR_OFFSET 0x564
+#define SRC_RBUF_5_WRADDR_OFFSET 0x57c
+#define SRC_RBUF_6_WRADDR_OFFSET 0x594
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_BASEADDR_REG_BASE */
+#define SRC_RBUF_0_BASEADDR_OFFSET 0x508
+#define SRC_RBUF_1_BASEADDR_OFFSET 0x520
+#define SRC_RBUF_2_BASEADDR_OFFSET 0x538
+#define SRC_RBUF_3_BASEADDR_OFFSET 0x550
+#define SRC_RBUF_4_BASEADDR_OFFSET 0x568
+#define SRC_RBUF_5_BASEADDR_OFFSET 0x580
+#define SRC_RBUF_6_BASEADDR_OFFSET 0x598
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_ENDADDR_REG_BASE */
+#define SRC_RBUF_0_ENDADDR_OFFSET 0x50c
+#define SRC_RBUF_1_ENDADDR_OFFSET 0x524
+#define SRC_RBUF_2_ENDADDR_OFFSET 0x53c
+#define SRC_RBUF_3_ENDADDR_OFFSET 0x554
+#define SRC_RBUF_4_ENDADDR_OFFSET 0x56c
+#define SRC_RBUF_5_ENDADDR_OFFSET 0x584
+#define SRC_RBUF_6_ENDADDR_OFFSET 0x59c
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_FREE_MARK_REG_BASE */
+#define SRC_RBUF_0_FREE_MARK_OFFSET 0x510
+#define SRC_RBUF_1_FREE_MARK_OFFSET 0x528
+#define SRC_RBUF_2_FREE_MARK_OFFSET 0x540
+#define SRC_RBUF_3_FREE_MARK_OFFSET 0x558
+#define SRC_RBUF_4_FREE_MARK_OFFSET 0x570
+#define 

[PATCH 1/2] ASoC: cygnus-audio: adding device tree bindings

2015-03-30 Thread Scott Branden
From: Lori Hikichi 

Add device tree binding documentation for the Cygnus SOC audio block

Reviewed-by: Jonathan Richardson 
Reviewed-by: Ray Jui 
Signed-off-by: Scott Branden 
Signed-off-by: Lori Hikichi 
---
 .../bindings/sound/brcm,cygnus-audio.txt   | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt

diff --git a/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt 
b/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
new file mode 100644
index 000..5358cc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
@@ -0,0 +1,68 @@
+BROADCOM Cygnus Audio I2S/TDM/SPDIF controller
+
+Required properties:
+   - compatible : "brcm,cygnus-audio"
+   - #address-cells: 32bit valued, 1 cell. <1>
+   - #size-cells:  32bit valued, 1 cell. <1>
+   - reg : Should contain audio registers location and length
+   - interrupts: audio DMA interrupt number
+
+SSP Subnode properties:
+- dai-name: The name of the DAI registered with ASOC
+- ssp-port-id: The ssp port interface to use
+   Valid value are 0, 1, 2, or 3 (for spdif)
+- mode: Controls if this port should be configured as I2S or TDM mode.
+   Valid values are: "tdm" or "i2s"
+- tdm-bits-per-frame:  only if mode is "tdm" then this property must set.
+   Valid values are (128/256/512)
+- port-status: Controls if port is enabled or not
+   Valid values "enabled" or "disabled"
+- channel-group: Control grouping of serial port
+   Valid values are "2_0", "3_1", or "5_1"
+
+Example:
+   cygnus_audio: audio@0x180ae000 {
+   compatible = "brcm,cygnus-audio";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x180ae000 0x1000>;
+
+   interrupts = ;
+
+   ssp0: ssp_port@0 {
+   dai-name = "cygnus-ssp0";
+   ssp-port-id = <0>;
+
+   mode = "i2s"; /* "i2s" or "tdm" */
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   port-status = "enabled";
+   };
+
+   ssp1: ssp_port@1 {
+   dai-name = "cygnus-ssp1";
+   ssp-port-id = <1>;
+
+   mode = "i2s"; /* "i2s" or "tdm" */
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   port-status = "disabled";
+   };
+
+   ssp2: ssp_port@2 {
+   dai-name = "cygnus-ssp2";
+   ssp-port-id = <2>;
+
+   mode = "tdm"; /* "i2s" or "tdm" */
+   tdm-bits-per-frame = <256>;
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   port-status = "disabled";
+   };
+
+   spdif: spdif_port@3 {
+   dai-name = "cygnus-spdif";
+   ssp-port-id = <3>;
+
+   mode = "i2s"; /* "i2s" or "tdm" */
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   port-status = "disabled";
+   };
+   };
-- 
2.3.3

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


[PATCH 0/2] Cygnus Audio Driver

2015-03-30 Thread Scott Branden
Please provide comments on the initial version of this driver.

This patchset contains the devicetree bindings and core audio driver
for the Cygnus SoC.

There is an open question on how to fit this driver into the clock
framework (if at all).

The audio PLL is embedded in the audio block and only used
by the audio block. The audio PLL registers are also in the middle of 
the audio register map.

In addition, the audio PLL is adjustable to less than 1 Hz.
The existing clock driver framework does not provide a mechanism to take
advantage of the resolution of the hardware.

Can the audio PLL remain within the audio driver and/or any modifications
required?

Lori Hikichi (2):
  ASoC: cygnus-audio: adding device tree bindings
  ASoC: add core audio driver for Broadcom Cygnus SOC.

 .../bindings/sound/brcm,cygnus-audio.txt   |   68 +
 sound/soc/bcm/Kconfig  |   11 +
 sound/soc/bcm/Makefile |5 +-
 sound/soc/bcm/cygnus-pcm.c |  918 +++
 sound/soc/bcm/cygnus-pcm.h |   45 +
 sound/soc/bcm/cygnus-ssp.c | 1613 
 sound/soc/bcm/cygnus-ssp.h |   84 +
 7 files changed, 2743 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
 create mode 100644 sound/soc/bcm/cygnus-pcm.c
 create mode 100644 sound/soc/bcm/cygnus-pcm.h
 create mode 100644 sound/soc/bcm/cygnus-ssp.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.h

-- 
2.3.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: smp_call_function_single lockups

2015-03-30 Thread Chris J Arges
On Thu, Feb 19, 2015 at 02:45:54PM -0800, Linus Torvalds wrote:
> On Thu, Feb 19, 2015 at 1:59 PM, Linus Torvalds
>  wrote:
> >
> > Is this worth looking at? Or is it something spurious? I might have
> > gotten the vectors wrong, and maybe the warning is not because the ISR
> > bit isn't set, but because I test the wrong bit.
> 
> I edited the patch to do ratelimiting (one per 10s max) rather than
> "once". And tested it some more. It seems to work correctly. The irq
> case during 8042 probing is not repeatable, and I suspect it happens
> because the interrupt source goes away (some probe-time thing that
> first triggers an interrupt, but then clears it itself), so it doesn't
> happen every boot, and I've gotten it with slightly different
> backtraces.
> 
> But it's the only warning that happens for me, so I think my code is
> right (at least for the cases that trigger on this machine). It's
> definitely not a "every interrupt causes the warning because the code
> was buggy, and the WARN_ONCE() just printed the first one".
> 
> It would be interesting to hear if others see spurious APIC EOI cases
> too. In particular, the people seeing the IPI lockup. Because a lot of
> the lockups we've seen have *looked* like the IPI interrupt just never
> happened, and so we're waiting forever for the target CPU to react to
> it. And just maybe the spurious EOI could cause the wrong bit to be
> cleared in the ISR, and then the interrupt never shows up. Something
> like that would certainly explain why it only happens on some machines
> and under certain timing circumstances.
> 
> Linus
> 

Linus,

I'm able to reproduce this IPI lockup easily now when using specific hardware
and nested KVM VMs. However, it seems to only occur when using certain host
hardware. For example:
- Xeon E5620 (Westmere-EP) (fam: 06, model: 2c)
- Xeon E312xx (Sandy Bridge) (fam: 06, model: 2a)
Now I'm not sure if this indicates hardware LAPIC issues or if the timing in
these processors make it more likely to hit this issue. So far I haven't seen
the issue on other CPUs.

To set this up, I've done the following (L0 being the Xeon box):
1) Create an L1 KVM VM with 2 vCPUs (single vCPU case doesn't reproduce)
2) Create an L2 KVM VM inside the L1 VM with 1 vCPU
3) Run something like 'stress -c 1 -m 1 -d 1 -t 1200' inside the L2 VM

Sometimes this is sufficient to reproduce the issue, I've observed that running
KSM in the L1 VM can agitate this issue (it calls native_flush_tlb_others).
If this doesn't reproduce then you can do the following:
4) Migrate the L2 vCPU randomly (via virsh vcpupin --live  OR tasksel) between
L1 vCPUs until the hang occurs.

Pinning L1 vCPUs to L0 initially (i.e. 0->0 1->1) causes the hangs to not occur
in my testing. (Which makes sense because we're unlikely to do real IPIs.)

I've been able to repro with your patch and observed the WARN_ON when booting a
VM on affected hardware and non affected hardware:

[   13.613531] [ cut here ]
[   13.613531] WARNING: CPU: 0 PID: 0 at ./arch/x86/include/asm/apic.h:444 
apic_ack_edge+0x84/0x90()
[   13.613531] Modules linked in: ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E) 
iptable_nat(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) 
xt_conntrack(E) nf_conntrack(E) ipt_REJECT(E) nf_reject_ipv4(E) xt_CHECKSUM(E) 
iptable_mangle(E) xt_tcpudp(E) bridge(E) stp(E) llc(E) ip6table_filter(E) 
ip6_tables(E) iptable_filter(E) ip_tables(E) ebtable_nat(E) ebtables(E) 
x_tables(E) dm_crypt(E) ppdev(E) kvm_intel(E) kvm(E) serio_raw(E) i2c_piix4(E) 
parport_pc(E) pvpanic(E) parport(E) mac_hid(E) nls_utf8(E) isofs(E) psmouse(E) 
floppy(E) cirrus(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) ttm(E) 
drm_kms_helper(E) drm(E) pata_acpi(E)
[   13.613531] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GE   
4.0.0-rc6-460f8calinus1 #4
[   13.613531] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Bochs 01/01/2011
[   13.613531]  81a911a6 88013fc03eb8 817999a7 
0007
[   13.613531]   88013fc03ef8 810734ca 
0092
[   13.613531]  0011 8800b8bbac00 001f 
00b1
[   13.613531] Call Trace:
[   13.613531][] dump_stack+0x45/0x57
[   13.613531]  [] warn_slowpath_common+0x8a/0xc0
[   13.613531]  [] warn_slowpath_null+0x1a/0x20
[   13.613531]  [] apic_ack_edge+0x84/0x90
[   13.613531]  [] handle_edge_irq+0x57/0x120
[   13.613531]  [] handle_irq+0x22/0x40
[   13.613531]  [] do_IRQ+0x4f/0x140
[   13.613531]  [] common_interrupt+0x6d/0x6d
[   13.613531][] ? hrtimer_start+0x18/0x20
[   13.613531]  [] ? native_safe_halt+0x6/0x10
[   13.613531]  [] ? rcu_eqs_enter+0xa3/0xb0
[   13.613531]  [] default_idle+0x1e/0xc0
[   13.613531]  [] arch_cpu_idle+0xf/0x20
[   13.613531]  [] cpu_startup_entry+0x2ff/0x420
[   13.613531]  [] rest_init+0x77/0x80
[   13.613531]  [] start_kernel+0x43c/0x449
[   13.613531]  [] ? 

[RFC PATCH 5 4/7] nfs - cache_lib use service thread if not executing in init namespace

2015-03-30 Thread Ian Kent
From: Ian Kent 

If pipefs is registered within a container pipefs requests should be run
within their originating container also. To do that get a token to a
service thread created within the container environment for usermode
helper calls.

Signed-off-by: Ian Kent 
Cc: Benjamin Coddington 
Cc: Al Viro 
Cc: J. Bruce Fields 
Cc: David Howells 
Cc: Trond Myklebust 
Cc: Oleg Nesterov 
Cc: Eric W. Biederman 
Cc: Jeff Layton 
---
 fs/nfs/cache_lib.c   |7 ++-
 include/linux/sunrpc/cache.h |2 ++
 net/sunrpc/cache.c   |5 +
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/cache_lib.c b/fs/nfs/cache_lib.c
index 5f7b053..78f9b6e 100644
--- a/fs/nfs/cache_lib.c
+++ b/fs/nfs/cache_lib.c
@@ -48,7 +48,12 @@ int nfs_cache_upcall(struct cache_detail *cd, char 
*entry_name)
 
if (nfs_cache_getent_prog[0] == '\0')
goto out;
-   ret = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
+   if (cd->u.pipefs.umh_token) {
+   int token = cd->u.pipefs.umh_token;
+   ret = call_usermodehelper_service(argv[0], argv, envp,
+ token, UMH_WAIT_EXEC);
+   } else
+   ret = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
/*
 * Disable the upcall mechanism if we're getting an ENOENT or
 * EACCES error. The admin can re-enable it on the fly by using
diff --git a/include/linux/sunrpc/cache.h b/include/linux/sunrpc/cache.h
index 437ddb6..bb57c7e 100644
--- a/include/linux/sunrpc/cache.h
+++ b/include/linux/sunrpc/cache.h
@@ -68,6 +68,8 @@ struct cache_detail_procfs {
 
 struct cache_detail_pipefs {
struct dentry *dir;
+   /* Namespace token */
+   int umh_token;
 };
 
 struct cache_detail {
diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
index 5199bb1..eabc0d0 100644
--- a/net/sunrpc/cache.c
+++ b/net/sunrpc/cache.c
@@ -1811,6 +1811,9 @@ int sunrpc_cache_register_pipefs(struct dentry *parent,
if (IS_ERR(dir))
return PTR_ERR(dir);
cd->u.pipefs.dir = dir;
+   if (cd->net != _net)
+   cd->u.pipefs.umh_token =
+umh_wq_get_token(cd->u.pipefs.umh_token, "pipefs");
return 0;
 }
 EXPORT_SYMBOL_GPL(sunrpc_cache_register_pipefs);
@@ -1819,6 +1822,8 @@ void sunrpc_cache_unregister_pipefs(struct cache_detail 
*cd)
 {
rpc_remove_cache_dir(cd->u.pipefs.dir);
cd->u.pipefs.dir = NULL;
+   umh_wq_put_token(cd->u.pipefs.umh_token);
+   cd->u.pipefs.umh_token = 0;
 }
 EXPORT_SYMBOL_GPL(sunrpc_cache_unregister_pipefs);
 

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


[RFC PATCH 5 6/7] KEYS - use correct memory allocation flag in call_usermodehelper_keys()

2015-03-30 Thread Ian Kent
From: Ian Kent 

When call_usermodehelper_keys() is called it assumes it won't be called
with the flag UMH_NO_WAIT. Currently that's always the case.

Change this to check the flag and use the correct kernel memory allocation
flag to guard against future changes.

Signed-off-by: Ian Kent 
Cc: Benjamin Coddington 
Cc: Al Viro 
Cc: J. Bruce Fields 
Cc: David Howells 
Cc: Trond Myklebust 
Cc: Oleg Nesterov 
Cc: Eric W. Biederman 
Cc: Jeff Layton 
---
 security/keys/request_key.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index 486ef6f..e865f9f 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -76,8 +76,10 @@ static int call_usermodehelper_keys(char *path, char **argv, 
char **envp,
struct key *session_keyring, int wait)
 {
struct subprocess_info *info;
+   unsigned int gfp_mask = (wait & UMH_NO_WAIT) ?
+   GFP_ATOMIC : GFP_KERNEL;
 
-   info = call_usermodehelper_setup(path, argv, envp, GFP_KERNEL,
+   info = call_usermodehelper_setup(path, argv, envp, gfp_mask,
  umh_keys_init, umh_keys_cleanup,
  session_keyring);
if (!info)

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


[RFC PATCH 5 7/7] KEYS: exec request key within service thread of key creator

2015-03-30 Thread Ian Kent
From: Ian Kent 

Containerized request key helper callbacks need the ability to execute
a binary in a container's context. To do that get a token to a service
thread created within the container environment for usermode helper calls.

Signed-off-by: Ian Kent 
Cc: Benjamin Coddington 
Cc: Al Viro 
Cc: J. Bruce Fields 
Cc: David Howells 
Cc: Trond Myklebust 
Cc: Oleg Nesterov 
Cc: Eric W. Biederman 
Cc: Jeff Layton 
---
 include/linux/key.h |3 +++
 security/keys/gc.c  |2 ++
 security/keys/key.c |5 +
 security/keys/request_key.c |   34 +++---
 4 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/include/linux/key.h b/include/linux/key.h
index e1d4715..144727d 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -209,6 +209,9 @@ struct key {
} payload;
struct assoc_array keys;
};
+
+   /* Namespace token */
+   int umh_token;
 };
 
 extern struct key *key_alloc(struct key_type *type,
diff --git a/security/keys/gc.c b/security/keys/gc.c
index c795237..c689ffd 100644
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -156,6 +156,8 @@ static noinline void key_gc_unused_keys(struct list_head 
*keys)
 
kfree(key->description);
 
+   umh_wq_put_token(key->umh_token);
+
 #ifdef KEY_DEBUGGING
key->magic = KEY_DEBUG_MAGIC_X;
 #endif
diff --git a/security/keys/key.c b/security/keys/key.c
index aee2ec5..3ca0825 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "internal.h"
 
 struct kmem_cache *key_jar;
@@ -309,6 +311,9 @@ struct key *key_alloc(struct key_type *type, const char 
*desc,
/* publish the key by giving it a serial number */
atomic_inc(>nkeys);
key_alloc_serial(key);
+   /* If running within a container use the container namespace */
+   if (current->nsproxy->net_ns != _net)
+   key->umh_token = umh_wq_get_token(0, "keys");
 
 error:
return key;
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index e865f9f..233e837 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -70,26 +70,40 @@ static void umh_keys_cleanup(struct subprocess_info *info)
 }
 
 /*
- * Call a usermode helper with a specific session keyring.
+ * Call a usermode helper with a specific session keyring and execute
+ * within a namespace.
  */
-static int call_usermodehelper_keys(char *path, char **argv, char **envp,
-   struct key *session_keyring, int wait)
+static int call_usermodehelper_keys_service(char *path,
+   char **argv, char **envp,
+   struct key *session_keyring,
+   int token, unsigned int wait)
 {
struct subprocess_info *info;
unsigned int gfp_mask = (wait & UMH_NO_WAIT) ?
GFP_ATOMIC : GFP_KERNEL;
 
info = call_usermodehelper_setup(path, argv, envp, gfp_mask,
- umh_keys_init, umh_keys_cleanup,
- session_keyring);
+umh_keys_init, umh_keys_cleanup,
+session_keyring);
if (!info)
return -ENOMEM;
+   info->wq_token = token;
 
key_get(session_keyring);
return call_usermodehelper_exec(info, wait);
 }
 
 /*
+ * Call a usermode helper with a specific session keyring.
+ */
+static int call_usermodehelper_keys(char *path, char **argv, char **envp,
+   struct key *session_keyring, int wait)
+{
+   return call_usermodehelper_keys_service(path, argv, envp,
+   session_keyring, 0, wait);
+}
+
+/*
  * Request userspace finish the construction of a key
  * - execute "/sbin/request-key   
"
  */
@@ -174,8 +188,14 @@ static int call_sbin_request_key(struct key_construction 
*cons,
argv[i] = NULL;
 
/* do it */
-   ret = call_usermodehelper_keys(argv[0], argv, envp, keyring,
-  UMH_WAIT_PROC);
+   /* If running within a container use the container namespace */
+   if (key->umh_token)
+   ret = call_usermodehelper_keys_service(argv[0], argv, envp,
+  keyring, key->umh_token,
+  UMH_WAIT_PROC);
+   else
+   ret = call_usermodehelper_keys(argv[0], argv, envp,
+  keyring, UMH_WAIT_PROC);
kdebug("usermode -> 0x%x", ret);
if (ret >= 0) {
/* ret is the exit/wait code */

--
To unsubscribe from this list: send the line 

[RFC PATCH 5 5/7] nfs - objlayout use service thread if not executing in init namespace

2015-03-30 Thread Ian Kent
From: Ian Kent 

If the caller is running within a container then execute the usermode
helper callback within the container also.

Signed-off-by: Ian Kent 
Cc: Benjamin Coddington 
Cc: Al Viro 
Cc: J. Bruce Fields 
Cc: David Howells 
Cc: Trond Myklebust 
Cc: Oleg Nesterov 
Cc: Eric W. Biederman 
Cc: Jeff Layton 
---
 fs/nfs/objlayout/objlayout.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/objlayout/objlayout.c b/fs/nfs/objlayout/objlayout.c
index 919efd4..1d4fd11 100644
--- a/fs/nfs/objlayout/objlayout.c
+++ b/fs/nfs/objlayout/objlayout.c
@@ -600,8 +600,14 @@ static int __objlayout_upcall(struct __auto_login *login)
NULL
};
char *argv[8];
+   int umh_token;
int ret;
 
+   /* If running within a container use the container namespace */
+   umh_token = 0;
+   if (current->nsproxy->net_ns != _net)
+   umh_token = umh_wq_get_token(0, "objlayout");
+
if (unlikely(!osd_login_prog[0])) {
dprintk("%s: osd_login_prog is disabled\n", __func__);
return -EACCES;
@@ -620,7 +626,13 @@ static int __objlayout_upcall(struct __auto_login *login)
argv[6] = login->systemid_hex;
argv[7] = NULL;
 
-   ret = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_PROC);
+   if (!umh_token)
+   ret = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_PROC);
+   else {
+   ret = call_usermodehelper_service(argv[0], argv, envp,
+ umh_token, UMH_WAIT_PROC);
+   umh_wq_put_token(umh_token);
+   }
/*
 * Disable the upcall mechanism if we're getting an ENOENT or
 * EACCES error. The admin can re-enable it on the fly by using

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


[RFC PATCH 5 3/7] nfsd - use service thread if not executing in init namespace

2015-03-30 Thread Ian Kent
From: Ian Kent 

If nfsd is running within a container the client tracking operations
should run within their originating container also. To do that get a
token to a service thread created within the container environment
for usermode helper calls.

Signed-off-by: Ian Kent 
Cc: Benjamin Coddington 
Cc: Al Viro 
Cc: J. Bruce Fields 
Cc: David Howells 
Cc: Trond Myklebust 
Cc: Oleg Nesterov 
Cc: Eric W. Biederman 
Cc: Jeff Layton 
---
 fs/nfsd/netns.h   |3 +++
 fs/nfsd/nfs4recover.c |   48 +++-
 fs/nfsd/nfsctl.c  |6 ++
 3 files changed, 40 insertions(+), 17 deletions(-)

diff --git a/fs/nfsd/netns.h b/fs/nfsd/netns.h
index ea6749a..099a3c5 100644
--- a/fs/nfsd/netns.h
+++ b/fs/nfsd/netns.h
@@ -112,6 +112,9 @@ struct nfsd_net {
u32 clientid_counter;
 
struct svc_serv *nfsd_serv;
+
+   /* Namespace token */
+   int umh_token;
 };
 
 /* Simple check to find out if a given net was properly initialized */
diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c
index 1c307f0..2547edb 100644
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@ -1184,7 +1184,8 @@ nfsd4_cltrack_grace_start(time_t grace_start)
 }
 
 static int
-nfsd4_umh_cltrack_upcall(char *cmd, char *arg, char *env0, char *env1)
+nfsd4_umh_cltrack_upcall(char *cmd, char *arg,
+char *env0, char *env1, int token)
 {
char *envp[3];
char *argv[4];
@@ -1209,7 +1210,11 @@ nfsd4_umh_cltrack_upcall(char *cmd, char *arg, char 
*env0, char *env1)
argv[2] = arg;
argv[3] = NULL;
 
-   ret = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_PROC);
+   if (token > 0)
+   ret = call_usermodehelper_service(argv[0], argv, envp,
+ token, UMH_WAIT_PROC);
+   else
+   ret = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_PROC);
/*
 * Disable the upcall mechanism if we're getting an ENOENT or EACCES
 * error. The admin can re-enable it on the fly by using sysfs
@@ -1252,14 +1257,8 @@ nfsd4_umh_cltrack_init(struct net *net)
struct nfsd_net *nn = net_generic(net, nfsd_net_id);
char *grace_start = nfsd4_cltrack_grace_start(nn->boot_time);
 
-   /* XXX: The usermode helper s not working in container yet. */
-   if (net != _net) {
-   WARN(1, KERN_ERR "NFSD: attempt to initialize umh client "
-   "tracking in a container!\n");
-   return -EINVAL;
-   }
-
-   ret = nfsd4_umh_cltrack_upcall("init", NULL, grace_start, NULL);
+   ret = nfsd4_umh_cltrack_upcall("init", NULL,
+   grace_start, NULL, nn->umh_token);
kfree(grace_start);
return ret;
 }
@@ -1285,6 +1284,7 @@ nfsd4_umh_cltrack_create(struct nfs4_client *clp)
 {
char *hexid, *has_session, *grace_start;
struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id);
+   int ret;
 
/*
 * With v4.0 clients, there's little difference in outcome between a
@@ -1312,7 +1312,10 @@ nfsd4_umh_cltrack_create(struct nfs4_client *clp)
grace_start = nfsd4_cltrack_grace_start(nn->boot_time);
 
nfsd4_cltrack_upcall_lock(clp);
-   if (!nfsd4_umh_cltrack_upcall("create", hexid, has_session, 
grace_start))
+   ret = nfsd4_umh_cltrack_upcall("create",
+  hexid, has_session, grace_start,
+  nn->umh_token);
+   if (!ret)
set_bit(NFSD4_CLIENT_STABLE, >cl_flags);
nfsd4_cltrack_upcall_unlock(clp);
 
@@ -1324,7 +1327,9 @@ nfsd4_umh_cltrack_create(struct nfs4_client *clp)
 static void
 nfsd4_umh_cltrack_remove(struct nfs4_client *clp)
 {
+   struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id);
char *hexid;
+   int ret;
 
if (!test_bit(NFSD4_CLIENT_STABLE, >cl_flags))
return;
@@ -1336,9 +1341,13 @@ nfsd4_umh_cltrack_remove(struct nfs4_client *clp)
}
 
nfsd4_cltrack_upcall_lock(clp);
-   if (test_bit(NFSD4_CLIENT_STABLE, >cl_flags) &&
-   nfsd4_umh_cltrack_upcall("remove", hexid, NULL, NULL) == 0)
-   clear_bit(NFSD4_CLIENT_STABLE, >cl_flags);
+   if (test_bit(NFSD4_CLIENT_STABLE, >cl_flags)) {
+   ret = nfsd4_umh_cltrack_upcall("remove",
+  hexid, NULL, NULL,
+  nn->umh_token);
+   if (ret == 0)
+   clear_bit(NFSD4_CLIENT_STABLE, >cl_flags);
+   }
nfsd4_cltrack_upcall_unlock(clp);
 
kfree(hexid);
@@ -1347,8 +1356,9 @@ nfsd4_umh_cltrack_remove(struct nfs4_client *clp)
 static int
 nfsd4_umh_cltrack_check(struct nfs4_client *clp)
 {
-   int ret;
+   struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id);
char *hexid, *has_session, *legacy;
+   int ret;
 

[RFC PATCH 5 1/7] kmod - add workqueue service thread store

2015-03-30 Thread Ian Kent
From: Ian Kent 

Persistent use of process information is needed for contained
execution in a namespace other than the root init namespace.

Use a simple random token as a key to create and store thread
information in a hashed list for use by the usermode helper
thread runner.

Signed-off-by: Ian Kent 
Cc: Benjamin Coddington 
Cc: Al Viro 
Cc: J. Bruce Fields 
Cc: David Howells 
Cc: Trond Myklebust 
Cc: Oleg Nesterov 
Cc: Eric W. Biederman 
Cc: Jeff Layton 
---
 include/linux/kmod.h |3 +
 kernel/kmod.c|  179 ++
 2 files changed, 181 insertions(+), 1 deletion(-)

diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index 0555cc6..fa46722 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -66,6 +66,9 @@ struct subprocess_info {
void *data;
 };
 
+extern int umh_wq_get_token(int token, const char *service);
+extern void umh_wq_put_token(int token);
+
 extern int
 call_usermodehelper(char *path, char **argv, char **envp, int wait);
 
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 2777f40..55d20ce 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -40,13 +40,30 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
 extern int max_threads;
 
+#define KHELPER"khelper"
 static struct workqueue_struct *khelper_wq;
 
+#define UMH_WQ_HASH_SHIFT  6
+#define UMH_WQ_HASH_SIZE   1 << UMH_WQ_HASH_SHIFT
+
+struct umh_wq_entry {
+   int token;
+   unsigned int count;
+   struct workqueue_struct *wq;
+   struct hlist_node umh_wq_hlist;
+};
+
+static DEFINE_SPINLOCK(umh_wq_hash_lock);
+static struct hlist_head umh_wq_hash[UMH_WQ_HASH_SIZE];
+
 #define CAP_BSET   (void *)1
 #define CAP_PI (void *)2
 
@@ -475,6 +492,165 @@ static void helper_unlock(void)
wake_up(_helpers_waitq);
 }
 
+static void umh_wq_hash_init(void)
+{
+   int i;
+
+   for (i = 0; i < UMH_WQ_HASH_SIZE; i++)
+   INIT_HLIST_HEAD(_wq_hash[i]);
+}
+
+static struct umh_wq_entry *umh_wq_find_entry(int token)
+{
+   struct umh_wq_entry *this, *entry;
+   struct hlist_head *bucket;
+   unsigned int hash;
+
+   hash = hash_32((unsigned long) token, UMH_WQ_HASH_SHIFT);
+   bucket = _wq_hash[hash];
+
+   entry = ERR_PTR(-ENOENT);
+   if (hlist_empty(bucket))
+   goto out;
+
+   hlist_for_each_entry(this, bucket, umh_wq_hlist) {
+   if (this->token == token) {
+   entry = this;
+   break;
+   }
+   }
+out:
+   return entry;
+}
+
+static struct workqueue_struct *umh_find_wq(int token, unsigned int nowait)
+{
+   struct umh_wq_entry *entry;
+   unsigned long flags;
+
+   if (!token)
+   return khelper_wq;
+
+   if (nowait)
+   spin_lock_irqsave(_wq_hash_lock, flags);
+   else
+   spin_lock(_wq_hash_lock);
+   entry = umh_wq_find_entry(token);
+   if (nowait)
+   spin_unlock_irqrestore(_wq_hash_lock, flags);
+   else
+   spin_unlock(_wq_hash_lock);
+
+   return entry->wq;
+}
+
+/**
+ * umh_wq_get_token - create service thread and return an identifying token
+ * @token: token of an existing service thread or 0 to create a new
+ *service thread.
+ * @name: service name to be appended to "khelper" for identification.
+ *
+ * Returns a token that used with calls to call_usermode_helper_service().
+ * If token corresponds to an existing service thread its reference count
+ * is increased and the token returned. On failure returns a negative errno.
+ */
+int umh_wq_get_token(int token, const char *service)
+{
+   struct workqueue_struct *wq;
+   char *wq_name;
+   int wq_name_len;
+   struct umh_wq_entry *entry;
+   struct hlist_head *bucket;
+   unsigned int hash;
+   unsigned int new_token;
+
+   if (token) {
+   spin_lock(_wq_hash_lock);
+   entry = umh_wq_find_entry(token);
+   if (entry) {
+   entry->count++;
+   spin_unlock(_wq_hash_lock);
+   return token;
+   }
+   spin_unlock(_wq_hash_lock);
+   }
+
+   if (!service)
+   return -EINVAL;
+
+   wq_name_len = sizeof(KHELPER) + strlen(service) + 1;
+   wq_name = kmalloc(wq_name_len, GFP_KERNEL);
+   if (!wq_name)
+   return -ENOMEM;
+   strcpy(wq_name, "KHELPER-");
+   strcat(wq_name, service);
+
+   entry = kzalloc(sizeof(struct umh_wq_entry), GFP_KERNEL);
+   if (!entry) {
+   kfree(wq_name);
+   return -ENOMEM;
+   }
+
+   wq = create_singlethread_workqueue(wq_name);
+   if (IS_ERR(wq)) {
+   kfree(wq_name);
+   kfree(entry);
+   return PTR_ERR(wq);
+   }
+   kfree(wq_name);
+   entry->wq = wq;
+
+   do {
+

[RFC PATCH v5 0/7] Another attempt at contained helper execution

2015-03-30 Thread Ian Kent
Following Eric's comments and in light of the most recent nfs and
keys patches here is yet another attempt at the basis of contained
usermode helper execution.

Initially I thought that creating threads to be used when executing
a helper wouldn't be feasible because the number of threads would be
far too large but the recent nfs and keys patches make me think that's
probably not the case.

There's more work to do on this, namely identifying already existing
threads for a requested environment, error handling for environments
that have gone away due to summary execution and similar. But I'd
like to get feedback as to whether I'm on the right track and what I
might be missing before spending more time on it.

---

Ian Kent (7):
  kmod - add workqueue service thread store
  kmod - teach usermodehelper to use service workqueues
  nfsd - use service thread if not executing in init namespace
  nfs - cache_lib use service thread if not executing in init namespace
  nfs - objlayout use service thread if not executing in init namespace
  KEYS - use correct memory allocation flag in call_usermodehelper_keys()
  KEYS: exec request key within service thread of key creator


 fs/nfs/cache_lib.c   |7 +
 fs/nfs/objlayout/objlayout.c |   14 +++
 fs/nfsd/netns.h  |3 +
 fs/nfsd/nfs4recover.c|   48 ++---
 fs/nfsd/nfsctl.c |6 +
 include/linux/key.h  |3 +
 include/linux/kmod.h |8 ++
 include/linux/sunrpc/cache.h |2 
 kernel/kmod.c|  217 --
 net/sunrpc/cache.c   |5 +
 security/keys/gc.c   |2 
 security/keys/key.c  |5 +
 security/keys/request_key.c  |   38 ++-
 13 files changed, 323 insertions(+), 35 deletions(-)

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


[RFC PATCH 5 2/7] kmod - teach usermodehelper to use service workqueues

2015-03-30 Thread Ian Kent
The call_usermodehelper() function executes all binaries in the
global "init" root context. This doesn't allow a binary to be run
within a namespace environment such as a container. To do this
the namespace environment of the contaner must be available to
provide the required execution environment.

This can be done by creating a service thread, identified by
issuing a token identifier, used when executing the helper
with a function that takes the token as a parameter.

Signed-off-by: Ian Kent 
Cc: Benjamin Coddington 
Cc: Al Viro 
Cc: J. Bruce Fields 
Cc: David Howells 
Cc: Trond Myklebust 
Cc: Oleg Nesterov 
Cc: Eric W. Biederman 
Cc: Jeff Layton 
---
 include/linux/kmod.h |5 +
 kernel/kmod.c|   38 +++---
 2 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index fa46722..9a9fcb3 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -56,6 +56,7 @@ struct file;
 struct subprocess_info {
struct work_struct work;
struct completion *complete;
+   int wq_token;
char *path;
char **argv;
char **envp;
@@ -72,6 +73,10 @@ extern void umh_wq_put_token(int token);
 extern int
 call_usermodehelper(char *path, char **argv, char **envp, int wait);
 
+extern int
+call_usermodehelper_service(char *path, char **argv,
+   char **envp, int token, int wait);
+
 extern struct subprocess_info *
 call_usermodehelper_setup(char *path, char **argv, char **envp, gfp_t gfp_mask,
  int (*init)(struct subprocess_info *info, struct cred 
*new),
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 55d20ce..47c5ff5 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -712,6 +712,7 @@ EXPORT_SYMBOL(call_usermodehelper_setup);
  */
 int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait)
 {
+   static struct workqueue_struct *wq;
DECLARE_COMPLETION_ONSTACK(done);
int retval = 0;
 
@@ -720,7 +721,8 @@ int call_usermodehelper_exec(struct subprocess_info 
*sub_info, int wait)
return -EINVAL;
}
helper_lock();
-   if (!khelper_wq || usermodehelper_disabled) {
+   wq = umh_find_wq(sub_info->wq_token, wait);
+   if (!wq || usermodehelper_disabled) {
retval = -EBUSY;
goto out;
}
@@ -732,7 +734,7 @@ int call_usermodehelper_exec(struct subprocess_info 
*sub_info, int wait)
sub_info->complete = (wait == UMH_NO_WAIT) ? NULL : 
sub_info->wait = wait;
 
-   queue_work(khelper_wq, _info->work);
+   queue_work(wq, _info->work);
if (wait == UMH_NO_WAIT)/* task has freed sub_info */
goto unlock;
 
@@ -759,19 +761,21 @@ unlock:
 EXPORT_SYMBOL(call_usermodehelper_exec);
 
 /**
- * call_usermodehelper() - prepare and start a usermode application
+ * call_usermodehelper_service() - start a usermode application within
+ * a service environment.
  * @path: path to usermode executable
  * @argv: arg vector for process
  * @envp: environment for process
+ * @token: token corresponding to a service environment obtained by a
+ *call to umh_wq_get_token().
  * @wait: wait for the application to finish and return status.
  *when UMH_NO_WAIT don't wait at all, but you get no useful error back
  *when the program couldn't be exec'ed. This makes it safe to call
  *from interrupt context.
- *
- * This function is the equivalent to use call_usermodehelper_setup() and
- * call_usermodehelper_exec().
  */
-int call_usermodehelper(char *path, char **argv, char **envp, int wait)
+int call_usermodehelper_service(char *path,
+   char **argv, char **envp,
+   int token, int wait)
 {
struct subprocess_info *info;
gfp_t gfp_mask = (wait == UMH_NO_WAIT) ? GFP_ATOMIC : GFP_KERNEL;
@@ -780,9 +784,29 @@ int call_usermodehelper(char *path, char **argv, char 
**envp, int wait)
 NULL, NULL, NULL);
if (info == NULL)
return -ENOMEM;
+   info->wq_token = token;
 
return call_usermodehelper_exec(info, wait);
 }
+EXPORT_SYMBOL(call_usermodehelper_service);
+
+/**
+ * call_usermodehelper() - prepare and start a usermode application
+ * @path: path to usermode executable
+ * @argv: arg vector for process
+ * @envp: environment for process
+ * @wait: wait for the application to finish and return status.
+ *when UMH_NO_WAIT don't wait at all, but you get no useful error back
+ *when the program couldn't be exec'ed. This makes it safe to call
+ *from interrupt context.
+ *
+ * This function is the equivalent to using call_usermodehelper_setup() and
+ * call_usermodehelper_exec().
+ */
+int call_usermodehelper(char *path, char **argv, char **envp, int wait)
+{
+   return 

Re: [v2,2/2] powerpc32: add support for csum_add()

2015-03-30 Thread Scott Wood
On Tue, Feb 03, 2015 at 12:39:27PM +0100, LEROY Christophe wrote:
> The C version of csum_add() as defined in include/net/checksum.h gives the
> following assembly:
>0:   7c 04 1a 14 add r0,r4,r3
>4:   7c 64 00 10 subfc   r3,r4,r0
>8:   7c 63 19 10 subfe   r3,r3,r3
>c:   7c 63 00 50 subfr3,r3,r0
> 
> include/net/checksum.h also offers the possibility to define an arch specific
> function.
> This patch provides a ppc32 specific csum_add() inline function.
> 
> Signed-off-by: Christophe Leroy 
> ---
> v2: changed constraints on the __asm__
> 
>  arch/powerpc/include/asm/checksum.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/checksum.h 
> b/arch/powerpc/include/asm/checksum.h
> index cfe806a..1e48cc7 100644
> --- a/arch/powerpc/include/asm/checksum.h
> +++ b/arch/powerpc/include/asm/checksum.h
> @@ -141,6 +141,18 @@ static inline __sum16 csum_tcpudp_magic(__be32 saddr, 
> __be32 daddr,
>  {
>   return csum_fold(csum_tcpudp_nofold(saddr, daddr, len, proto, sum));
>  }
> +
> +#define HAVE_ARCH_CSUM_ADD
> +static inline __wsum csum_add(__wsum csum, __wsum addend)
> +{
> +__asm__("\n\

s/__asm__/asm/

Use tabs to indent

> + addc %0,%0,%1 \n\
> + addze %0,%0 \n\

Use ; to separate asm statements instead of using \n
Use string concatenation instead of \

-Scott
--
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] clockevents: Fix cpu down race for hrtimer based broadcasting

2015-03-30 Thread Nicolas Pitre
On Mon, 30 Mar 2015, Preeti U Murthy wrote:

> It was found when doing a hotplug stress test on POWER, that the machine
> either hit softlockups or rcu_sched stall warnings.  The issue was
> traced to commit 7cba160ad789a powernv/cpuidle: Redesign idle states
> management, which exposed the cpu down race with hrtimer based broadcast
> mode(Commit 5d1638acb9f6(tick: Introduce hrtimer based broadcast). This
> is explained below.
> 
> Assume CPU1 is the CPU which holds the hrtimer broadcasting duty before
> it is taken down.
> 
> CPU0  CPU1
> 
> cpu_down()take_cpu_down()
>   disable_interrupts()
> 
> cpu_die()
> 
>  while(CPU1 != CPU_DEAD) {
>   msleep(100);
>switch_to_idle();
> stop_cpu_timer();
>  schedule_broadcast();
>  }
> 
> tick_cleanup_cpu_dead()
>   take_over_broadcast()
> 
> So after CPU1 disabled interrupts it cannot handle the broadcast hrtimer
> anymore, so CPU0 will be stuck forever.
> 
> Fix this by explicitly taking over broadcast duty before cpu_die().
> This is a temporary workaround. What we really want is a callback in the
> clockevent device which allows us to do that from the dying CPU by
> pushing the hrtimer onto a different cpu. That might involve an IPI and
> is definitely more complex than this immediate fix.
> 
> Fixes:
> http://linuxppc.10917.n7.nabble.com/offlining-cpus-breakage-td88619.html
> Suggested-by: Thomas Gleixner 
> Signed-off-by: Preeti U. Murthy 
> [Changelog drawn from: https://lkml.org/lkml/2015/2/16/213]

The lock-up I was experiencing with v1 of this patch is no longer 
reproducible with this one.

Tested-by: Nicolas Pitre 

> ---
> Change from V1: https://lkml.org/lkml/2015/2/26/11
> 1. Decoupled this fix from the kernel/time cleanup patches. V1 had a fail
> related to the cleanup which needs to be fixed. But since this bug fix
> is independent of this and needs to go in quickly, the patch is being posted
> out separately to be merged.
> 
>  include/linux/tick.h |   10 +++---
>  kernel/cpu.c |2 ++
>  kernel/time/tick-broadcast.c |   19 +++
>  3 files changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/include/linux/tick.h b/include/linux/tick.h
> index 9c085dc..3069256 100644
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -94,14 +94,18 @@ extern void tick_cancel_sched_timer(int cpu);
>  static inline void tick_cancel_sched_timer(int cpu) { }
>  # endif
>  
> -# ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
> +# if defined CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
>  extern struct tick_device *tick_get_broadcast_device(void);
>  extern struct cpumask *tick_get_broadcast_mask(void);
>  
> -#  ifdef CONFIG_TICK_ONESHOT
> +#  if defined CONFIG_TICK_ONESHOT
>  extern struct cpumask *tick_get_broadcast_oneshot_mask(void);
> +extern void tick_takeover(int deadcpu);
> +# else
> +static inline void tick_takeover(int deadcpu) {}
>  #  endif
> -
> +# else
> +static inline void tick_takeover(int deadcpu) {}
>  # endif /* BROADCAST */
>  
>  # ifdef CONFIG_TICK_ONESHOT
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 1972b16..f9ca351 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "smpboot.h"
> @@ -411,6 +412,7 @@ static int __ref _cpu_down(unsigned int cpu, int 
> tasks_frozen)
>   while (!idle_cpu(cpu))
>   cpu_relax();
>  
> + tick_takeover(cpu);
>   /* This actually kills the CPU. */
>   __cpu_die(cpu);
>  
> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
> index 066f0ec..0fd6634 100644
> --- a/kernel/time/tick-broadcast.c
> +++ b/kernel/time/tick-broadcast.c
> @@ -669,14 +669,19 @@ static void broadcast_shutdown_local(struct 
> clock_event_device *bc,
>   clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN);
>  }
>  
> -static void broadcast_move_bc(int deadcpu)
> +void tick_takeover(int deadcpu)
>  {
> - struct clock_event_device *bc = tick_broadcast_device.evtdev;
> + struct clock_event_device *bc;
> + unsigned long flags;
>  
> - if (!bc || !broadcast_needs_cpu(bc, deadcpu))
> - return;
> - /* This moves the broadcast assignment to this cpu */
> - clockevents_program_event(bc, bc->next_event, 1);
> + raw_spin_lock_irqsave(_broadcast_lock, flags);
> + bc = tick_broadcast_device.evtdev;
> +
> + if (bc && broadcast_needs_cpu(bc, deadcpu)) {
> + /* This moves the broadcast assignment to this cpu */
> + clockevents_program_event(bc, bc->next_event, 1);
> + }
> + raw_spin_unlock_irqrestore(_broadcast_lock, flags);
>  }
>  
>  /*
> @@ -913,8 +918,6 @@ void tick_shutdown_broadcast_oneshot(unsigned int *cpup)
>   cpumask_clear_cpu(cpu, tick_broadcast_pending_mask);
>   cpumask_clear_cpu(cpu, tick_broadcast_force_mask);
>  
> - broadcast_move_bc(cpu);
> -

Re: [PATCH v2 08/10] perf/hv24x7: Whitespace cleanup

2015-03-30 Thread Joe Perches
On Mon, 2015-03-30 at 18:53 -0700, Sukadev Bhattiprolu wrote:
> Fix minor whitespace damages.

If you are going to do whitespace cleaning,
please verify the patches with scripts/checkpatch.pl --strict.

> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
[]
> @@ -1077,7 +1079,6 @@ static unsigned long single_24x7_request(struct 
> perf_event *event, u64 *count)
>   }
>  
>   resb = _buffer->results[0];
> -
>   *count = be64_to_cpu(resb->elements[0].element_data[0]);
>  out:
>   return ret;

Does this deletion make the code easier to read?

It might be better just to use:

be64 val;
...
val = result_buffer->results[0].elements[0].element_data[0];
*count = be64_to_cpu(val);

--
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] mtd: hisilicon: remove deprecated IRQF_DISABLED

2015-03-30 Thread Brian Norris
On Thu, Mar 26, 2015 at 06:39:53PM -0700, Michael Opdenacker wrote:
> This removes the use of the IRQF_DISABLED flag
> from drivers/mtd/nand/hisi504_nand.c
> 
> It's a NOOP since 2.6.35.
> 
> Signed-off-by: Michael Opdenacker 
> ---
>  drivers/mtd/nand/hisi504_nand.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/hisi504_nand.c b/drivers/mtd/nand/hisi504_nand.c
> index 289ad3ac3e80..e39482441430 100644
> --- a/drivers/mtd/nand/hisi504_nand.c
> +++ b/drivers/mtd/nand/hisi504_nand.c
> @@ -758,7 +758,7 @@ static int hisi_nfc_probe(struct platform_device *pdev)
>  
>   hisi_nfc_host_init(host);
>  
> - ret = devm_request_irq(dev, irq, hinfc_irq_handle, IRQF_DISABLED,
> + ret = devm_request_irq(dev, irq, hinfc_irq_handle, 0,
>   "nandc", host);
>   if (ret) {
>   dev_err(dev, "failed to request IRQ\n");

linux-next has this:

commit d8bf368d0631d4bc2612d8bf2e4e8e74e620d0cc
Author: Valentin Rothberg 
Date:   Thu Mar 5 15:23:08 2015 +0100

genirq: Remove the deprecated 'IRQF_DISABLED' request_irq() flag entirely

Thanks,
Brian
--
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 06/25] powerpc: Use bool function return values of true/false not 1/0

2015-03-30 Thread Benjamin Herrenschmidt
On Mon, 2015-03-30 at 16:46 -0700, Joe Perches wrote:
> Use the normal return values for bool functions

Acked-by: Benjamin Herrenschmidt 

Should we merge it or will you ?

Cheers,
Ben.

> Signed-off-by: Joe Perches 
> ---
>  arch/powerpc/include/asm/dcr-native.h| 2 +-
>  arch/powerpc/include/asm/dma-mapping.h   | 4 ++--
>  arch/powerpc/include/asm/kvm_book3s_64.h | 4 ++--
>  arch/powerpc/sysdev/dcr.c| 2 +-
>  4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/dcr-native.h 
> b/arch/powerpc/include/asm/dcr-native.h
> index 7d2e623..4efc11d 100644
> --- a/arch/powerpc/include/asm/dcr-native.h
> +++ b/arch/powerpc/include/asm/dcr-native.h
> @@ -31,7 +31,7 @@ typedef struct {
>  
>  static inline bool dcr_map_ok_native(dcr_host_native_t host)
>  {
> - return 1;
> + return true;
>  }
>  
>  #define dcr_map_native(dev, dcr_n, dcr_c) \
> diff --git a/arch/powerpc/include/asm/dma-mapping.h 
> b/arch/powerpc/include/asm/dma-mapping.h
> index 894d538..9103687 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -191,11 +191,11 @@ static inline bool dma_capable(struct device *dev, 
> dma_addr_t addr, size_t size)
>   struct dev_archdata *sd = >archdata;
>  
>   if (sd->max_direct_dma_addr && addr + size > sd->max_direct_dma_addr)
> - return 0;
> + return false;
>  #endif
>  
>   if (!dev->dma_mask)
> - return 0;
> + return false;
>  
>   return addr + size - 1 <= *dev->dma_mask;
>  }
> diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h 
> b/arch/powerpc/include/asm/kvm_book3s_64.h
> index 2d81e20..2a244bf 100644
> --- a/arch/powerpc/include/asm/kvm_book3s_64.h
> +++ b/arch/powerpc/include/asm/kvm_book3s_64.h
> @@ -335,7 +335,7 @@ static inline bool hpte_read_permission(unsigned long pp, 
> unsigned long key)
>  {
>   if (key)
>   return PP_RWRX <= pp && pp <= PP_RXRX;
> - return 1;
> + return true;
>  }
>  
>  static inline bool hpte_write_permission(unsigned long pp, unsigned long key)
> @@ -373,7 +373,7 @@ static inline bool slot_is_aligned(struct kvm_memory_slot 
> *memslot,
>   unsigned long mask = (pagesize >> PAGE_SHIFT) - 1;
>  
>   if (pagesize <= PAGE_SIZE)
> - return 1;
> + return true;
>   return !(memslot->base_gfn & mask) && !(memslot->npages & mask);
>  }
>  
> diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
> index 2d8a101..121e26f 100644
> --- a/arch/powerpc/sysdev/dcr.c
> +++ b/arch/powerpc/sysdev/dcr.c
> @@ -54,7 +54,7 @@ bool dcr_map_ok_generic(dcr_host_t host)
>   else if (host.type == DCR_HOST_MMIO)
>   return dcr_map_ok_mmio(host.host.mmio);
>   else
> - return 0;
> + return false;
>  }
>  EXPORT_SYMBOL_GPL(dcr_map_ok_generic);
>  


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


Re: [PATCH_V2 2/2] mtd: nand: jz4780: driver for NAND devices on JZ4780 SoCs

2015-03-30 Thread Brian Norris
I can't compile test most of this, since I don't have the dependencies.
But the code looks mostly OK.

On Mon, Mar 09, 2015 at 11:58:19AM +, Zubair Lutfullah Kakakhel wrote:
> From: Alex Smith 
> 
> Add a driver for NAND devices connected to the NEMC on JZ4780 SoCs, as
> well as the hardware BCH controller. DMA is not currently implemented.
> 
> While older 47xx SoCs also have a BCH controller, they are incompatible
> with the one in the 4780 due to differing register/bit positions, which
> would make implementing a common driver for them quite messy.
> 
> Signed-off-by: Alex Smith 
> Signed-off-by: Zubair Lutfullah Kakakhel 
> 
> ---
> V1 - > V2
> Fixed module license macro
> Rebase to 4.0-rc3
> ---
>  drivers/mtd/nand/Kconfig   |   7 +
>  drivers/mtd/nand/Makefile  |   1 +
>  drivers/mtd/nand/jz4780_bch.c  | 358 +++
>  drivers/mtd/nand/jz4780_bch.h  |  42 +
>  drivers/mtd/nand/jz4780_nand.c | 372 
> +
>  5 files changed, 780 insertions(+)
>  create mode 100644 drivers/mtd/nand/jz4780_bch.c
>  create mode 100644 drivers/mtd/nand/jz4780_bch.h
>  create mode 100644 drivers/mtd/nand/jz4780_nand.c
> 
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 5b76a17..7627002 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -503,6 +503,13 @@ config MTD_NAND_JZ4740
>   help
>   Enables support for NAND Flash on JZ4740 SoC based boards.
>  
> +config MTD_NAND_JZ4780
> + tristate "Support for NAND on JZ4780 SoC"
> + depends on MACH_JZ4780 && JZ4780_NEMC
> + help
> +   Enables support for NAND Flash connected to the NEMC on JZ4780 SoC
> +   based boards, using the BCH controller for hardware error correction.
> +
>  config MTD_NAND_FSMC
>   tristate "Support for NAND on ST Micros FSMC"
>   depends on PLAT_SPEAR || ARCH_NOMADIK || ARCH_U8500 || MACH_U300
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 582bbd05..7c1ebca 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_MTD_NAND_NUC900)   += nuc900_nand.o
>  obj-$(CONFIG_MTD_NAND_MPC5121_NFC)   += mpc5121_nfc.o
>  obj-$(CONFIG_MTD_NAND_RICOH) += r852.o
>  obj-$(CONFIG_MTD_NAND_JZ4740)+= jz4740_nand.o
> +obj-$(CONFIG_MTD_NAND_JZ4780)+= jz4780_nand.o jz4780_bch.o
>  obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/
>  obj-$(CONFIG_MTD_NAND_XWAY)  += xway_nand.o
>  obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/
> diff --git a/drivers/mtd/nand/jz4780_bch.c b/drivers/mtd/nand/jz4780_bch.c
> new file mode 100644
> index 000..eb264be
> --- /dev/null
> +++ b/drivers/mtd/nand/jz4780_bch.c
> @@ -0,0 +1,358 @@
...
> +/**
> + * jz4780_bch_get() - get the BCH controller device
> + * @np: BCH device tree node.
> + * @dev: where to store pointer to BCH controller device.
> + *
> + * Gets the BCH controller device from the specified device tree node. The
> + * device must be released with jz4780_bch_release() when it is no longer 
> being
> + * used.
> + *
> + * Return: 0 on success, -EPROBE_DEFER if the controller has not yet been
> + * initialised.
> + */
> +int jz4780_bch_get(struct device_node *np, struct device **dev)
> +{
> + struct platform_device *pdev;
> + struct jz4780_bch *bch;
> +
> + pdev = of_find_device_by_node(np);
> + if (!pdev || !platform_get_drvdata(pdev))
> + return -EPROBE_DEFER;
> +
> + bch = platform_get_drvdata(pdev);
> + clk_prepare_enable(bch->clk);
> +
> + *dev = >dev;

Might want a get_device() / put_device() pair in this driver, so you
can't unbind the BCH controller device while the NAND driver is using
it?

> + return 0;
> +}
> +EXPORT_SYMBOL(jz4780_bch_get);
> +
> +/**
> + * jz4780_bch_release() - release the BCH controller device
> + * @dev: BCH device.
> + */
> +void jz4780_bch_release(struct device *dev)
> +{
> + struct jz4780_bch *bch = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(bch->clk);
> +}
> +EXPORT_SYMBOL(jz4780_bch_release);
> +
> +static int jz4780_bch_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct jz4780_bch *bch;
> + struct resource *res;
> +
> + bch = devm_kzalloc(dev, sizeof(*bch), GFP_KERNEL);
> + if (!bch)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + bch->base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(bch->base)) {
> + dev_err(dev, "failed to get I/O memory\n");
> + return PTR_ERR(bch->base);
> + }
> +
> + jz4780_bch_disable(bch);
> +
> + bch->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(bch->clk)) {
> + dev_err(dev, "failed to get clock: %ld\n", PTR_ERR(bch->clk));
> + return PTR_ERR(bch->clk);
> + }
> +
> + clk_set_rate(bch->clk, 

Re: [4/4] powerpc/85xx: support sleep feature on QorIQ SoCs with RCPM

2015-03-30 Thread Scott Wood
On Thu, Mar 26, 2015 at 06:18:15PM +0800, chenhui zhao wrote:
> In sleep mode, the clocks of e500 cores and unused IP blocks is
> turned off. The IP blocks which are allowed to wake up the processor
> are still running.
> 
> The sleep mode is equal to the Standby state in Linux. Use the
> command to enter sleep mode:
>   echo standby > /sys/power/state
> 
> Signed-off-by: Chenhui Zhao 
> ---
>  arch/powerpc/Kconfig   |  3 +-
>  arch/powerpc/platforms/85xx/Kconfig|  5 +++
>  arch/powerpc/platforms/85xx/Makefile   |  1 +
>  arch/powerpc/platforms/85xx/qoriq_pm.c | 59 
> ++
>  arch/powerpc/platforms/86xx/Kconfig|  1 +
>  5 files changed, 67 insertions(+), 2 deletions(-)
>  create mode 100644 arch/powerpc/platforms/85xx/qoriq_pm.c
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 9846c83..162eb53 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -233,7 +233,7 @@ config ARCH_HIBERNATION_POSSIBLE
>  config ARCH_SUSPEND_POSSIBLE
>   def_bool y
>   depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
> -(PPC_85xx && !PPC_E500MC) || PPC_86xx || PPC_PSERIES \
> +FSL_SOC_BOOKE || PPC_86xx || PPC_PSERIES \
>  || 44x || 40x
>  
>  config PPC_DCR_NATIVE
> @@ -747,7 +747,6 @@ config FSL_PCI
>  
>  config FSL_PMC
>   bool
> - default y
>   depends on SUSPEND && (PPC_85xx || PPC_86xx)

Get rid of this depends line if you're going to use select instead.

> +static int qoriq_suspend_valid(suspend_state_t state)
> +{
> + unsigned int pm_modes;
> +
> + pm_modes = qoriq_pm_ops->get_pm_modes();
> +
> + if ((state == PM_SUSPEND_STANDBY) && (pm_modes & FSL_PM_SLEEP))
> + return 1;

Unnecessary parentheses around ==

-Scott
--
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] PM / devfreq: tegra: Register governor on module init

2015-03-30 Thread MyungJoo Ham
> Sender : Tomeu Vizoso
> Date : 2015-03-31 00:33 (GMT+09:00)
> Title : [PATCH v2] PM / devfreq: tegra: Register governor on module init
> 
> So this driver builds as a module.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
> 
> v2: * Remove governor if driver registration fails
> ---
> drivers/devfreq/tegra-devfreq.c | 37 ++---
> 1 file changed, 30 insertions(+), 7 deletions(-)
> 

Thanks. Merged.

Signed-off-by: MyungJoo Ham 


Cheers,
MyungJoo.


RE: [PATCHv3 0/1] Intel Quark X1000 DTS thermal driver

2015-03-30 Thread Kweh, Hock Leong
> -Original Message-
> From: Ong, Boon Leong
> Sent: Tuesday, March 31, 2015 7:58 AM
> To: Zhang, Rui; edubez...@gmail.com
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org; Ong, Boon
> Leong; pure.lo...@nexus-software.ie; Kweh, Hock Leong;
> andy.shevche...@gmail.com
> Subject: RE: [PATCHv3 0/1] Intel Quark X1000 DTS thermal driver
> 
> Dear maintainer, gentle ping if this driver is ready for more review/inclusion
> into Linux v4.1 ?
> Thank you very much.
> 
> >-Original Message-
> >From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> >ow...@vger.kernel.org] On Behalf Of Ong Boon Leong
> >Sent: Monday, March 9, 2015 3:43 PM
> >To: Zhang, Rui; edubez...@gmail.com; pure.lo...@nexus-software.ie;
> >Kweh, Hock Leong; andy.shevche...@gmail.com
> >Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> >Subject: [PATCHv3 0/1] Intel Quark X1000 DTS thermal driver
> >
> >Dear maintainers & communities,
> >
> >This patch introduces DTS thermal driver for Intel Quark X1000.
> >The code implementation is based on intel_soc_dts_thermal.c.
> >
> >Intel Quark X1000 has one on-die DTS with two configurable trip points:
> >critical and hot trip points. However, todate, UEFI BIOS for Quark
> >X1000 uses only critical trip point. UEFI BIOS always lock DTS register
> >before hand-over to Linux kernel.
> >
> >The minimalist thermal design is meant to trigger Linux distro to
> >gracefully power-down the system when its DTS temperature exceeds the
> >configured critical trip point.
> >
> >In anticipation that other variant of Quark platform may come with UEFI
> >BIOS that does not lock DTS register during hand-over, this DTS driver
> >is built with logics to handle such case too.
> >
> >I have tested v1 of the patch on Intel Galileo Gen v2 board and found
> >it satisfactory with logs below:
> >
> >  root@quark:/sys/class/thermal/thermal_zone0# echo disabled > mode
> >  [   46.276881] intel_quark_dts_thermal: DTS is locked. Cannot disable DTS
> >  -sh: echo: write error: Operation not permitted
> > root@quark:/sys/class/thermal/thermal_zone0#
> >  root@quark:/sys/class/thermal/thermal_zone0# cat temp
> >  53
> >  root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_0_temp
> >  105
> >  root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_0_type
> > critical  root@quark:/sys/class/thermal/thermal_zone0# cat
> > trip_point_1_temp
> >  20
> >  root@quark:/sys/class/thermal/thermal_zone0# cat trip_point_1_type
> > hot  root@quark:/sys/class/thermal/thermal_zone0# cat type  quark_dts
> >
> >  root@quark:/sys/class/thermal/thermal_zone0# echo 105 > emul_temp
> >  [  179.372981] thermal thermal_zone0: critical temperature reached(0
> >C),shutting down
> >  root@quark:/sys/class/thermal/thermal_zone0#
> >  [  OK  ] Stopped target Multi-User System.
> >   Stopping Telephony service...
> >   Stopping Lightning Fast Webserver With Light System 
> > Requirements...
> >   Stopping Target Communication Framework agent...
> >   Stopping Galileo Arduino Layer...
> >  [  OK  ] Stopped target Login Prompts.
> >   Stopping Getty on tty1...
> >   Stopping Serial Getty on ttyS1...
> >   Stopping Login Service...
> >   Stopping D-Bus System Message Bus...
> >   Starting Store Sound Card State...
> >  [  OK  ] Stopped Telephony service.
> >  [  OK  ] Stopped Galileo Arduino Layer.
> >  [  OK  ] Stopped Login Service.
> >  [  OK  ] Stopped D-Bus System Message Bus.
> >  [  OK  ] Stopped Target Communication Framework agent.
> >  [  OK  ] Stopped Lightning Fast Webserver With Light System Requirements.
> >  [  OK  ] Stopped WPA supplicant.
> >  [  OK  ] Stopped Getty on tty1.
> >  [  OK  ] Stopped Serial Getty on ttyS1.
> >
> >Please kindly review the patch at your convenient time and provide me
> >feedback for improvement. Appreciate your time and effort.
> >
> >Thank You
> >Ong Boon Leong
> >Intel Corp.
> >
> >---
> >Changes in v3:
> >* Kconfig dependency changed to X86_INTEL_QUARK
> >
> >Changes in v2:
> >* Fix several commit write-up grammar, choice of words.
> >* Ensure "int ret" in correct order
> >* Add comment to explain DTS register field read/write bit operation
> >* Change to Dual BSD/GPL license
> >* Add logic to ensure safe trip point threshold value being set
> >
> >Ong Boon Leong (1):
> >  thermal: intel Quark SoC X1000 DTS thermal driver
> >
> > drivers/thermal/Kconfig   |   10
> > drivers/thermal/Makefile  |1
> > drivers/thermal/intel_quark_dts_thermal.c |  434
> >+
> > 3 files changed, 445 insertions(+)
> > create mode 100644 drivers/thermal/intel_quark_dts_thermal.c
> >
> >--
> >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  

Re: [3/4] powerpc: support CPU hotplug for e500mc, e5500 and e6500

2015-03-30 Thread Scott Wood
On Thu, Mar 26, 2015 at 06:18:14PM +0800, chenhui zhao wrote:
> Implemented CPU hotplug on e500mc, e5500 and e6500, and support
> multiple threads mode and 64-bits mode.
> 
> For e6500 with two threads, if one thread is online, it can
> enable/disable the other thread in the same core. If two threads of
> one core are offline, the core will enter the PH20 state (a low power
> state). When the core is up again, Thread0 is up first, and it will be
> bound with the present booting cpu. This way, all CPUs can hotplug
> separately.
> 
> Signed-off-by: Chenhui Zhao 
> ---
>  arch/powerpc/Kconfig  |   2 +-
>  arch/powerpc/include/asm/fsl_pm.h |   4 +
>  arch/powerpc/include/asm/smp.h|   2 +
>  arch/powerpc/kernel/head_64.S |  20 +++--
>  arch/powerpc/kernel/smp.c |   5 ++
>  arch/powerpc/platforms/85xx/smp.c | 182 
> +-
>  arch/powerpc/sysdev/fsl_rcpm.c|  56 
>  7 files changed, 220 insertions(+), 51 deletions(-)

Please factor out changes to generic code (including but not limited to
cur_boot_cpu and PIR handling) into separate patches with clear
explanations.

> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 22b0940..9846c83 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -380,7 +380,7 @@ config SWIOTLB
>  config HOTPLUG_CPU
>   bool "Support for enabling/disabling CPUs"
>   depends on SMP && (PPC_PSERIES || \
> - PPC_PMAC || PPC_POWERNV || (PPC_85xx && !PPC_E500MC))
> + PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE)
>   ---help---
> Say Y here to be able to disable and re-enable individual
> CPUs at runtime on SMP machines.
> diff --git a/arch/powerpc/include/asm/fsl_pm.h 
> b/arch/powerpc/include/asm/fsl_pm.h
> index bbe6089..579f495 100644
> --- a/arch/powerpc/include/asm/fsl_pm.h
> +++ b/arch/powerpc/include/asm/fsl_pm.h
> @@ -34,6 +34,10 @@ struct fsl_pm_ops {
>   void (*cpu_enter_state)(int cpu, int state);
>   /* exit the CPU from the specified state */
>   void (*cpu_exit_state)(int cpu, int state);
> + /* cpu up */
> + void (*cpu_up)(int cpu);

Again, this sort of comment is useless.  Tell us what "cpu up" *does*,
when it should be called, etc.

> @@ -189,16 +193,14 @@ _GLOBAL(fsl_secondary_thread_init)
>   isync
>  
>   /*
> -  * Fix PIR to match the linear numbering in the device tree.
> -  *
> -  * On e6500, the reset value of PIR uses the low three bits for
> -  * the thread within a core, and the upper bits for the core
> -  * number.  There are two threads per core, so shift everything
> -  * but the low bit right by two bits so that the cpu numbering is
> -  * continuous.

Why are you getting rid of this?  If it's to avoid doing it twice on the
same thread, in my work-in-progress kexec patches I instead check to see
whether BUCSR has already been set up -- if it has, I assume we've
already been here.

> +  * The current thread has been in 64-bit mode,
> +  * see the value of TMRN_IMSR.

I don't see what the relevance of this comment is here.

> +  * compute the address of __cur_boot_cpu
>*/
> - mfspr   r3, SPRN_PIR
> - rlwimi  r3, r3, 30, 2, 30
> + bl  10f
> +10:  mflrr22
> + addir22,r22,(__cur_boot_cpu - 10b)
> + lwz r3,0(r22)

Please save non-volatile registers for things that need to stick around
for a while.

>   mtspr   SPRN_PIR, r3

If __cur_boot_cpu is meant to be the PIR of the currently booting CPU,
it's a misleading.  It looks like it's supposed to have something to do
with the boot cpu (not "booting").

Also please don't put leading underscores on symbols just because the
adjacent symbols have them.

> -#ifdef CONFIG_HOTPLUG_CPU
> +#ifdef CONFIG_PPC_E500MC
> +static void qoriq_cpu_wait_die(void)
> +{
> + unsigned int cpu = smp_processor_id();
> +
> + hard_irq_disable();
> + /* mask all irqs to prevent cpu wakeup */
> + qoriq_pm_ops->irq_mask(cpu);
> + idle_task_exit();
> +
> + mtspr(SPRN_TCR, 0);
> + mtspr(SPRN_TSR, mfspr(SPRN_TSR));
> +
> + cur_cpu_spec->cpu_flush_caches();
> +
> + generic_set_cpu_dead(cpu);
> + smp_mb();

Comment memory barriers, as checkpatch says.

> + while (1)
> + ;

Indent the ;

> @@ -174,17 +232,29 @@ static inline u32 read_spin_table_addr_l(void 
> *spin_table)
>  static void wake_hw_thread(void *info)
>  {
>   void fsl_secondary_thread_init(void);
> - unsigned long imsr1, inia1;
> + unsigned long imsr, inia;
>   int nr = *(const int *)info;
> -
> - imsr1 = MSR_KERNEL;
> - inia1 = *(unsigned long *)fsl_secondary_thread_init;
> -
> - mttmr(TMRN_IMSR1, imsr1);
> - mttmr(TMRN_INIA1, inia1);
> - mtspr(SPRN_TENS, TEN_THREAD(1));
> + int hw_cpu = get_hard_smp_processor_id(nr);
> + int thread_idx = cpu_thread_in_core(hw_cpu);
> +
> + __cur_boot_cpu = (u32)hw_cpu;
> + imsr = MSR_KERNEL;
> + inia = 

Re: [PATCH] watchdog: nohz: don't run watchdog on nohz_full cores

2015-03-30 Thread Mike Galbraith
On Mon, 2015-03-30 at 15:12 -0400, Don Zickus wrote:
> On Mon, Mar 30, 2015 at 02:51:05PM -0400, cmetc...@ezchip.com wrote:
> > From: Chris Metcalf 
> > 
> > Running watchdog can be a helpful debugging feature on regular
> > cores, but it's incompatible with nohz_full, since it forces
> > regular scheduling events.  Accordingly, just exit out immediately
> > from any nohz_full core.
> > 
> > An alternate approach would be to add a flags field or function to
> > smp_hotplug_thread to control on which cores the percpu threads
> > are created, but it wasn't clear that much mechanism was useful.
> 
> Hi Chris,
> 
> It seems like the correct solution would be to hook into the idle_loop
> somehow.  If the cpu is idle, then it seems unlikely that a lockup could
> occur.
> 
> My fear with this apporach is a lockup would occur on the nohz cpu and it
> would go undetected because that cpu is disabled.  Further no printk is
> thrown out to even indicate a cpu is disabled making it more difficult to
> debug.

Hm, I don't see why this is needed, for debugging/testing you turn it
on, when you set up for critical operation, you turn it off.

A bigger deal is the clocksource watchdog methinks.  Measurement
inspired me to make it dead yesterday.

-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_V2 1/2] dt-bindings: binding for jz4780-{nand,bch}

2015-03-30 Thread Brian Norris
On Mon, Mar 09, 2015 at 11:58:18AM +, Zubair Lutfullah Kakakhel wrote:
> From: Alex Smith 
> 
> Add DT bindings for NAND devices connected to the NEMC on JZ4780 SoCs,
> as well as the hardware BCH controller, used by the jz4780_{nand,bch}
> drivers.
> 
> Signed-off-by: Alex Smith 
> Signed-off-by: Zubair Lutfullah Kakakhel 
> 
> ---
> V1 - > V2
> Rebase to 4.0-rc3
> ---
>  .../bindings/mtd/ingenic,jz4780-nand.txt   | 57 
> ++
>  1 file changed, 57 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt 
> b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> new file mode 100644
> index 000..6f2e128
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> @@ -0,0 +1,57 @@
> +* Ingenic JZ4780 NAND/BCH
> +
> +This file documents the device tree bindings for NAND flash devices on the
> +JZ4780. NAND devices are connected to the NEMC controller (described in
> +memory-controllers/ingenic,jz4780-nemc.txt), and thus NAND device nodes must
> +be children of the NEMC node.
> +
> +Required NAND device properties:
> +- compatible: Should be set to "ingenic,jz4780-nand".
> +- reg: For each bank with a NAND chip attached, should specify a bank number,
> +  an offset of 0 and a size of 0x100 (i.e. the whole NEMC bank).
> +
> +Optional NAND device properties:
> +- ingenic,bch-device: To make use of the hardware BCH controller, this 
> property
> +  must contain a phandle for the BCH controller node. The required properties
> +  for this node are described below. If this is not specified, software BCH
> +  will be used instead.
> +- ingenic,ecc-size: ECC block size in bytes.
> +- ingenic,ecc-strength: ECC strength (max number of correctable bits).

Can you use the generic nand-ecc-step-size and nand-ecc-strength
properties instead of defining new ones?

> +- ingenic,busy-gpio: GPIO specifier for the busy pin.
> +- ingenic,wp-gpio: GPIO specifier for the write protect pin.

The gipo.txt binding document recommends naming properties *-gpios, not
*-gpio. Also, these look like they are exposing the actualy R/B and WP#
pins as gpios, correct? If so, then I think it'd be good to give them
generic names, not 'ingenic,' names. That way, we might consider
supporting reusable code that handles them. And I see that sunxi-nand
already uses a generic name for the R/B pin: rb-gpios.

So these might work:

  rb-gpios
  wp-gpios


BTW, generic GPIO WP# handling was discussed a few months ago, though I
didn't see any patches yet:

http://lists.infradead.org/pipermail/linux-mtd/2015-January/057256.html

I see that your driver is just using this to disable write-protection
permanently, but I've seen cases where it helps to keep write-protection
enabled whenever you're not writing to the NAND.

> +
> +Example:
> +
> +nemc: nemc@1341 {
> + ...
> +
> + nand: nand@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>;  /* Bank 1 */
> +
> + ingenic,bch-device = <>;
> + ingenic,ecc-size = <1024>;
> + ingenic,ecc-strength = <24>;
> +
> + ingenic,busy-gpio = < 20 GPIO_ACTIVE_LOW>;
> + ingenic,wp-gpio = < 22 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +The BCH controller is a separate SoC component used for error correction on
> +NAND devices. The following is a description of the device properties for a
> +BCH controller.
> +
> +Required BCH properties:
> +- compatible: Should be set to "ingenic,jz4780-bch".
> +- reg: Should specify the BCH controller registers location and length.
> +- clocks: Clock for the BCH controller.
> +
> +Example:
> +
> +bch: bch@134d {
> + compatible = "ingenic,jz4780-bch";
> + reg = <0x134d 0x1>;
> +
> + clocks = < JZ4780_CLK_BCH>;
> +};

Brian
--
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 06/25] powerpc: Use bool function return values of true/false not 1/0

2015-03-30 Thread Joe Perches
On Tue, 2015-03-31 at 12:49 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2015-03-30 at 16:46 -0700, Joe Perches wrote:
> > Use the normal return values for bool functions
> 
> Acked-by: Benjamin Herrenschmidt 
> 
> Should we merge it or will you ?

Hey Ben.

I don't merge stuff.  I just send patches.
So, it'll be better if you do it.

I'll resend whatever doesn't get picked up in
the next couple months on to Andrew Morton.

cheers.  Joe

--
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 02/10] powerpc/hv24x7: Remove unnecessary parameter

2015-03-30 Thread Sukadev Bhattiprolu
Remove the 'success_expected' parameter and log the message unconditionally.

Changelog[v2]
[Michael Ellerman]: Move the change to reduce log message priority
into a separate patch.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 408e6e9..c185dcf 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -986,8 +986,7 @@ static const struct attribute_group *attr_groups[] = {
 };
 
 static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
-u16 lpar, u64 *count,
-bool success_expected)
+u16 lpar, u64 *count)
 {
unsigned long ret;
 
@@ -1028,8 +1027,7 @@ static unsigned long single_24x7_request(u8 domain, u32 
offset, u16 ix,
virt_to_phys(result_buffer),  H24x7_DATA_BUFFER_SIZE);
 
if (ret) {
-   if (success_expected)
-   pr_err_ratelimited("hcall failed: %d %#x %#x %d => "
+   pr_err_ratelimited("hcall failed: %d %#x %#x %d => "
"0x%lx (%ld) detail=0x%x failing ix=%x\n",
domain, offset, ix, lpar, ret, ret,
result_buffer->detailed_rc,
@@ -1044,8 +1042,7 @@ out:
return ret;
 }
 
-static unsigned long event_24x7_request(struct perf_event *event, u64 *res,
-   bool success_expected)
+static unsigned long event_24x7_request(struct perf_event *event, u64 *res)
 {
u16 idx;
unsigned domain = event_get_domain(event);
@@ -1059,8 +1056,7 @@ static unsigned long event_24x7_request(struct perf_event 
*event, u64 *res,
event_get_offset(event),
idx,
event_get_lpar(event),
-   res,
-   success_expected);
+   res);
 }
 
 static int h_24x7_event_init(struct perf_event *event)
@@ -1130,7 +1126,7 @@ static int h_24x7_event_init(struct perf_event *event)
}
 
/* see if the event complains */
-   if (event_24x7_request(event, , false)) {
+   if (event_24x7_request(event, )) {
pr_devel("test hcall failed\n");
return -EIO;
}
@@ -1142,7 +1138,7 @@ static u64 h_24x7_get_value(struct perf_event *event)
 {
unsigned long ret;
u64 ct;
-   ret = event_24x7_request(event, , true);
+   ret = event_24x7_request(event, );
if (ret)
/* We checked this in event init, shouldn't fail here... */
return 0;
-- 
1.8.3.1

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


[PATCH v2 00/10] powerpc/hv-24x7: Reorganize single_24x7_request()

2015-03-30 Thread Sukadev Bhattiprolu
We currently issue a new hcall for to retrieve the value of each 24x7
counter that we want to read.  However, the H_GET_24x7_DATA hcall can
retrieve several counters in a single call, which would be useful in
getting a more consistent snapshot of the system.

Reorganize the code that prepares a 24x7 hcall request, submits it and
processes the result to allow reading seveal counters at once. We still
submit a fresh hcall for each event for now. A follow-on patch-set will
build on this to submit multiple perf_events in a single hcall.

Thanks to Peter Zijlstra for his input.

Changelog[v2]
- Split independent changes in patch 2 into patch 3.
- Minor changes to pr_err() (Patch 4).
- Move whitespace changes to separate patch (Patch  8).
- Minor function renames (Patch 10).

Sukadev Bhattiprolu (10):
  powerpc/hv-24x7: Modify definition of request and result buffers
  powerpc/hv24x7: Remove unnecessary parameter
  perf/hv24x7: Use pr_devel() to log message
  powerpc/hv-24x7: Drop event_24x7_request()
  powerpc/hv24x7: Move debug prints to separate function
  powerpc/hv-24x7: Rename hv_24x7_event_update
  powerpc/hv-24x7: Define add_event_to_24x7_request()
  perf/hv24x7: Whitespace cleanup
  powerpc/hv-24x7: Define update_event_count()
  powerpc/hv-24x7: Break up single_24x7_request

 arch/powerpc/perf/hv-24x7.c | 212 +++-
 arch/powerpc/perf/hv-24x7.h |   8 +-
 2 files changed, 137 insertions(+), 83 deletions(-)

-- 
1.8.3.1

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


[PATCH v2 04/10] powerpc/hv-24x7: Drop event_24x7_request()

2015-03-30 Thread Sukadev Bhattiprolu
The function event_24x7_request() is essentially a wrapper to the
function single_24x7_request() and can be dropped to simplify code.

Changelog [v2]:
- Michael Ellerman: Use fields from the request structure rather
than re-extracting from event structure.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 40 +++-
 1 file changed, 15 insertions(+), 25 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 87c9905..f509f3b 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -985,9 +985,9 @@ static const struct attribute_group *attr_groups[] = {
NULL,
 };
 
-static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
-u16 lpar, u64 *count)
+static unsigned long single_24x7_request(struct perf_event *event, u64 *count)
 {
+   u16 idx;
unsigned long ret;
 
struct hv_24x7_request_buffer *request_buffer;
@@ -1004,17 +1004,22 @@ static unsigned long single_24x7_request(u8 domain, u32 
offset, u16 ix,
memset(request_buffer, 0, 4096);
memset(result_buffer, 0, 4096);
 
+   if (is_physical_domain(event_get_domain(event)))
+   idx = event_get_core(event);
+   else
+   idx = event_get_vcpu(event);
+
request_buffer->interface_version = HV_24X7_IF_VERSION_CURRENT;
request_buffer->num_requests = 1;
 
req = _buffer->requests[0];
 
-   req->performance_domain = domain;
+   req->performance_domain = event_get_domain(event);
req->data_size = cpu_to_be16(8);
-   req->data_offset = cpu_to_be32(offset);
-   req->starting_lpar_ix = cpu_to_be16(lpar),
+   req->data_offset = cpu_to_be32(event_get_offset(event));
+   req->starting_lpar_ix = cpu_to_be16(event_get_lpar(event)),
req->max_num_lpars = cpu_to_be16(1);
-   req->starting_ix = cpu_to_be16(ix);
+   req->starting_ix = cpu_to_be16(idx);
req->max_ix = cpu_to_be16(1);
 
/*
@@ -1029,7 +1034,8 @@ static unsigned long single_24x7_request(u8 domain, u32 
offset, u16 ix,
if (ret) {
pr_devel_ratelimited("hcall failed: %d %#x %#x %d => "
"0x%lx (%ld) detail=0x%x failing ix=%x\n",
-   domain, offset, ix, lpar, ret, ret,
+   req->performance_domain, req->data_offset,
+   idx, req->starting_lpar_ix, ret, ret,
result_buffer->detailed_rc,
result_buffer->failing_request_ix);
goto out;
@@ -1042,22 +1048,6 @@ out:
return ret;
 }
 
-static unsigned long event_24x7_request(struct perf_event *event, u64 *res)
-{
-   u16 idx;
-   unsigned domain = event_get_domain(event);
-
-   if (is_physical_domain(domain))
-   idx = event_get_core(event);
-   else
-   idx = event_get_vcpu(event);
-
-   return single_24x7_request(event_get_domain(event),
-   event_get_offset(event),
-   idx,
-   event_get_lpar(event),
-   res);
-}
 
 static int h_24x7_event_init(struct perf_event *event)
 {
@@ -1126,7 +1116,7 @@ static int h_24x7_event_init(struct perf_event *event)
}
 
/* see if the event complains */
-   if (event_24x7_request(event, )) {
+   if (single_24x7_request(event, )) {
pr_devel("test hcall failed\n");
return -EIO;
}
@@ -1138,7 +1128,7 @@ static u64 h_24x7_get_value(struct perf_event *event)
 {
unsigned long ret;
u64 ct;
-   ret = event_24x7_request(event, );
+   ret = single_24x7_request(event, );
if (ret)
/* We checked this in event init, shouldn't fail here... */
return 0;
-- 
1.8.3.1

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


[PATCH v2 07/10] powerpc/hv-24x7: Define add_event_to_24x7_request()

2015-03-30 Thread Sukadev Bhattiprolu
Move code that maps a perf_event to a 24x7 request buffer into a
separate function, add_event_to_24x7_request().

Changelog[v2]
[Michael Ellerman]: Move white-space changes to separate patch.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 59 -
 1 file changed, 42 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index e78b127..fe74221 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1000,15 +1000,52 @@ static void log_24x7_hcall(struct 
hv_24x7_request_buffer *request_buffer,
result_buffer->failing_request_ix);
 }
 
-static unsigned long single_24x7_request(struct perf_event *event, u64 *count)
+/*
+ * Add the given @event to the next slot in the 24x7 request_buffer.
+ *
+ * Note that H_GET_24X7_DATA hcall allows reading several counters'
+ * values in a single HCALL. We expect the caller to add events to the
+ * request buffer one by one, make the HCALL and process the results.
+ */
+static int add_event_to_24x7_request(struct perf_event *event,
+   struct hv_24x7_request_buffer *request_buffer)
 {
u16 idx;
+   int i;
+   struct hv_24x7_request *req;
+
+   if (request_buffer->num_requests > 254) {
+   pr_devel("Too many requests for 24x7 HCALL %d\n",
+   request_buffer->num_requests);
+   return -EINVAL;
+   }
+
+   if (is_physical_domain(event_get_domain(event)))
+   idx = event_get_core(event);
+   else
+   idx = event_get_vcpu(event);
+
+   i = request_buffer->num_requests++;
+   req = _buffer->requests[i];
+
+   req->performance_domain = event_get_domain(event);
+   req->data_size = cpu_to_be16(8);
+   req->data_offset = cpu_to_be32(event_get_offset(event));
+   req->starting_lpar_ix = cpu_to_be16(event_get_lpar(event)),
+   req->max_num_lpars = cpu_to_be16(1);
+   req->starting_ix = cpu_to_be16(idx);
+   req->max_ix = cpu_to_be16(1);
+
+   return 0;
+}
+
+static unsigned long single_24x7_request(struct perf_event *event, u64 *count)
+{
unsigned long ret;
 
struct hv_24x7_request_buffer *request_buffer;
struct hv_24x7_data_result_buffer *result_buffer;
struct hv_24x7_result *resb;
-   struct hv_24x7_request *req;
 
BUILD_BUG_ON(sizeof(*request_buffer) > 4096);
BUILD_BUG_ON(sizeof(*result_buffer) > 4096);
@@ -1019,23 +1056,11 @@ static unsigned long single_24x7_request(struct 
perf_event *event, u64 *count)
memset(request_buffer, 0, 4096);
memset(result_buffer, 0, 4096);
 
-   if (is_physical_domain(event_get_domain(event)))
-   idx = event_get_core(event);
-   else
-   idx = event_get_vcpu(event);
-
request_buffer->interface_version = HV_24X7_IF_VERSION_CURRENT;
-   request_buffer->num_requests = 1;
-
-   req = _buffer->requests[0];
 
-   req->performance_domain = event_get_domain(event);
-   req->data_size = cpu_to_be16(8);
-   req->data_offset = cpu_to_be32(event_get_offset(event));
-   req->starting_lpar_ix = cpu_to_be16(event_get_lpar(event)),
-   req->max_num_lpars = cpu_to_be16(1);
-   req->starting_ix = cpu_to_be16(idx);
-   req->max_ix = cpu_to_be16(1);
+   ret = add_event_to_24x7_request(event, request_buffer);
+   if (ret)
+   return ret;
 
/*
 * NOTE: Due to variable number of array elements in request and
-- 
1.8.3.1

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


[PATCH v2 08/10] perf/hv24x7: Whitespace cleanup

2015-03-30 Thread Sukadev Bhattiprolu
Fix minor whitespace damages.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index fe74221..676fb2f9 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -161,6 +161,7 @@ static char *event_desc(struct hv_24x7_event_data *ev, int 
*len)
 {
unsigned nl = be16_to_cpu(ev->event_name_len);
__be16 *desc_len = (__be16 *)(ev->remainder + nl - 2);
+
*len = be16_to_cpu(*desc_len) - 2;
return (char *)ev->remainder + nl;
 }
@@ -171,6 +172,7 @@ static char *event_long_desc(struct hv_24x7_event_data *ev, 
int *len)
__be16 *desc_len_ = (__be16 *)(ev->remainder + nl - 2);
unsigned desc_len = be16_to_cpu(*desc_len_);
__be16 *long_desc_len = (__be16 *)(ev->remainder + nl + desc_len - 2);
+
*len = be16_to_cpu(*long_desc_len) - 2;
return (char *)ev->remainder + nl + desc_len;
 }
@@ -248,14 +250,12 @@ static unsigned long h_get_24x7_catalog_page_(unsigned 
long phys_4096,
  unsigned long index)
 {
pr_devel("h_get_24x7_catalog_page(0x%lx, %lu, %lu)",
-   phys_4096,
-   version,
-   index);
+   phys_4096, version, index);
+
WARN_ON(!IS_ALIGNED(phys_4096, 4096));
+
return plpar_hcall_norets(H_GET_24X7_CATALOG_PAGE,
-   phys_4096,
-   version,
-   index);
+   phys_4096, version, index);
 }
 
 static unsigned long h_get_24x7_catalog_page(char page[],
@@ -309,6 +309,7 @@ static ssize_t device_show_string(struct device *dev,
struct dev_ext_attribute *d;
 
d = container_of(attr, struct dev_ext_attribute, attr);
+
return sprintf(buf, "%s\n", (char *)d->var);
 }
 
@@ -323,6 +324,7 @@ static struct attribute *device_str_attr_create_(char 
*name, char *str)
attr->attr.attr.name = name;
attr->attr.attr.mode = 0444;
attr->attr.show = device_show_string;
+
return >attr.attr;
 }
 
@@ -396,7 +398,6 @@ static struct attribute *event_to_attr(unsigned ix,
a_ev_name = kasprintf(GFP_KERNEL, "%.*s%s__%d",
(int)event_name_len, ev_name, ev_suffix, nonce);
 
-
if (!a_ev_name)
goto out_val;
 
@@ -881,6 +882,7 @@ static ssize_t catalog_read(struct file *filp, struct 
kobject *kobj,
uint64_t catalog_version_num = 0;
void *page = kmem_cache_alloc(hv_page_cache, GFP_USER);
struct hv_24x7_catalog_page_0 *page_0 = page;
+
if (!page)
return -ENOMEM;
 
@@ -1077,7 +1079,6 @@ static unsigned long single_24x7_request(struct 
perf_event *event, u64 *count)
}
 
resb = _buffer->results[0];
-
*count = be64_to_cpu(resb->elements[0].element_data[0]);
 out:
return ret;
@@ -1175,6 +1176,7 @@ static void h_24x7_event_read(struct perf_event *event)
 {
s64 prev;
u64 now;
+
now = h_24x7_get_value(event);
prev = local64_xchg(>hw.prev_count, now);
local64_add(now - prev, >count);
-- 
1.8.3.1

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


[PATCH v2 10/10] powerpc/hv-24x7: Break up single_24x7_request

2015-03-30 Thread Sukadev Bhattiprolu
Break up the function single_24x7_request() into smaller functions.
This would later enable us to "prepare" a multi-event request
buffer and then submit a single hcall for several events.

Changelog[v2]:
[Michael Ellerman] Rename start_24x7_get_data() to init_24x7_request()
and commit_24x7_get_data make_24x7_request().

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 56 +
 1 file changed, 42 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index cf82026..46be032 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1003,6 +1003,44 @@ static void log_24x7_hcall(struct hv_24x7_request_buffer 
*request_buffer,
 }
 
 /*
+ * Start the process for a new H_GET_24x7_DATA hcall.
+ */
+static void init_24x7_request(struct hv_24x7_request_buffer *request_buffer,
+   struct hv_24x7_data_result_buffer *result_buffer)
+{
+
+   memset(request_buffer, 0, 4096);
+   memset(result_buffer, 0, 4096);
+
+   request_buffer->interface_version = HV_24X7_IF_VERSION_CURRENT;
+   /* memset above set request_buffer->num_requests to 0 */
+}
+
+/*
+ * Commit (i.e perform) the H_GET_24x7_DATA hcall using the data collected
+ * by 'init_24x7_request()' and 'add_event_to_24x7_request()'.
+ */
+static int make_24x7_request(struct hv_24x7_request_buffer *request_buffer,
+   struct hv_24x7_data_result_buffer *result_buffer)
+{
+   unsigned long ret;
+
+   /*
+* NOTE: Due to variable number of array elements in request and
+*   result buffer(s), sizeof() is not reliable. Use the actual
+*   allocated buffer size, H24x7_DATA_BUFFER_SIZE.
+*/
+   ret = plpar_hcall_norets(H_GET_24X7_DATA,
+   virt_to_phys(request_buffer), H24x7_DATA_BUFFER_SIZE,
+   virt_to_phys(result_buffer),  H24x7_DATA_BUFFER_SIZE);
+
+   if (ret)
+   log_24x7_hcall(request_buffer, result_buffer, ret);
+
+   return ret;
+}
+
+/*
  * Add the given @event to the next slot in the 24x7 request_buffer.
  *
  * Note that H_GET_24X7_DATA hcall allows reading several counters'
@@ -1044,7 +1082,6 @@ static int add_event_to_24x7_request(struct perf_event 
*event,
 static unsigned long single_24x7_request(struct perf_event *event, u64 *count)
 {
unsigned long ret;
-
struct hv_24x7_request_buffer *request_buffer;
struct hv_24x7_data_result_buffer *result_buffer;
struct hv_24x7_result *resb;
@@ -1055,31 +1092,22 @@ static unsigned long single_24x7_request(struct 
perf_event *event, u64 *count)
request_buffer = (void *)get_cpu_var(hv_24x7_reqb);
result_buffer = (void *)get_cpu_var(hv_24x7_resb);
 
-   memset(request_buffer, 0, 4096);
-   memset(result_buffer, 0, 4096);
-
-   request_buffer->interface_version = HV_24X7_IF_VERSION_CURRENT;
+   init_24x7_request(request_buffer, result_buffer);
 
ret = add_event_to_24x7_request(event, request_buffer);
if (ret)
return ret;
 
-   /*
-* NOTE: Due to variable number of array elements in request and
-*   result buffer(s), sizeof() is not reliable. Use the actual
-*   allocated buffer size, H24x7_DATA_BUFFER_SIZE.
-*/
-   ret = plpar_hcall_norets(H_GET_24X7_DATA,
-   virt_to_phys(request_buffer), H24x7_DATA_BUFFER_SIZE,
-   virt_to_phys(result_buffer),  H24x7_DATA_BUFFER_SIZE);
-
+   ret = make_24x7_request(request_buffer, result_buffer);
if (ret) {
log_24x7_hcall(request_buffer, result_buffer, ret);
goto out;
}
 
+   /* process result from hcall */
resb = _buffer->results[0];
*count = be64_to_cpu(resb->elements[0].element_data[0]);
+
 out:
return ret;
 }
-- 
1.8.3.1

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


[PATCH v2 09/10] powerpc/hv-24x7: Define update_event_count()

2015-03-30 Thread Sukadev Bhattiprolu
Move the code to update an event count into a new function,
update_event_count().

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 676fb2f9..cf82026 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1172,16 +1172,22 @@ static u64 h_24x7_get_value(struct perf_event *event)
return ct;
 }
 
-static void h_24x7_event_read(struct perf_event *event)
+static void update_event_count(struct perf_event *event, u64 now)
 {
s64 prev;
-   u64 now;
 
-   now = h_24x7_get_value(event);
prev = local64_xchg(>hw.prev_count, now);
local64_add(now - prev, >count);
 }
 
+static void h_24x7_event_read(struct perf_event *event)
+{
+   u64 now;
+
+   now = h_24x7_get_value(event);
+   update_event_count(event, now);
+}
+
 static void h_24x7_event_start(struct perf_event *event, int flags)
 {
if (flags & PERF_EF_RELOAD)
-- 
1.8.3.1

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


[PATCH v2 03/10] perf/hv24x7: Use pr_devel() to log message

2015-03-30 Thread Sukadev Bhattiprolu
Use pr_devel_ratelimited() to log error message when the 24x7 HCALL
fails. Since users specify events by their sysfs name, the HCALL should
succeed. Any errors reported by the HCALL would be of interest to the
developer, rather than the user/administrator.

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index c185dcf..87c9905 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1027,7 +1027,7 @@ static unsigned long single_24x7_request(u8 domain, u32 
offset, u16 ix,
virt_to_phys(result_buffer),  H24x7_DATA_BUFFER_SIZE);
 
if (ret) {
-   pr_err_ratelimited("hcall failed: %d %#x %#x %d => "
+   pr_devel_ratelimited("hcall failed: %d %#x %#x %d => "
"0x%lx (%ld) detail=0x%x failing ix=%x\n",
domain, offset, ix, lpar, ret, ret,
result_buffer->detailed_rc,
-- 
1.8.3.1

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


[PATCH v2 05/10] powerpc/hv24x7: Move debug prints to separate function

2015-03-30 Thread Sukadev Bhattiprolu
To simplify/cleanup code, move the rather long printk() to a separate
function.

Signed-off-by: Sukadev Bhattiprolu 

Conflicts:
arch/powerpc/perf/hv-24x7.c
---
 arch/powerpc/perf/hv-24x7.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index f509f3b..a58a1df 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -985,6 +985,21 @@ static const struct attribute_group *attr_groups[] = {
NULL,
 };
 
+static void log_24x7_hcall(struct hv_24x7_request_buffer *request_buffer,
+   struct hv_24x7_data_result_buffer *result_buffer,
+   unsigned long ret)
+{
+   struct hv_24x7_request *req;
+
+   req = _buffer->requests[0];
+   pr_notice_ratelimited("hcall failed: [%d %#x %#x %d] => "
+   "ret 0x%lx (%ld) detail=0x%x failing ix=%x\n",
+   req->performance_domain, req->data_offset,
+   req->starting_ix, req->starting_lpar_ix, ret, ret,
+   result_buffer->detailed_rc,
+   result_buffer->failing_request_ix);
+}
+
 static unsigned long single_24x7_request(struct perf_event *event, u64 *count)
 {
u16 idx;
@@ -1032,12 +1047,7 @@ static unsigned long single_24x7_request(struct 
perf_event *event, u64 *count)
virt_to_phys(result_buffer),  H24x7_DATA_BUFFER_SIZE);
 
if (ret) {
-   pr_devel_ratelimited("hcall failed: %d %#x %#x %d => "
-   "0x%lx (%ld) detail=0x%x failing ix=%x\n",
-   req->performance_domain, req->data_offset,
-   idx, req->starting_lpar_ix, ret, ret,
-   result_buffer->detailed_rc,
-   result_buffer->failing_request_ix);
+   log_24x7_hcall(request_buffer, result_buffer, ret);
goto out;
}
 
-- 
1.8.3.1

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


[PATCH v2 06/10] powerpc/hv-24x7: Rename hv_24x7_event_update

2015-03-30 Thread Sukadev Bhattiprolu
For consistency with the pmu operation ->read() and with other
pmus, rename hv_24x7_event_update() to hv_24x7_event_read().

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index a58a1df..e78b127 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1146,7 +1146,7 @@ static u64 h_24x7_get_value(struct perf_event *event)
return ct;
 }
 
-static void h_24x7_event_update(struct perf_event *event)
+static void h_24x7_event_read(struct perf_event *event)
 {
s64 prev;
u64 now;
@@ -1163,7 +1163,7 @@ static void h_24x7_event_start(struct perf_event *event, 
int flags)
 
 static void h_24x7_event_stop(struct perf_event *event, int flags)
 {
-   h_24x7_event_update(event);
+   h_24x7_event_read(event);
 }
 
 static int h_24x7_event_add(struct perf_event *event, int flags)
@@ -1184,7 +1184,7 @@ static struct pmu h_24x7_pmu = {
.del = h_24x7_event_stop,
.start   = h_24x7_event_start,
.stop= h_24x7_event_stop,
-   .read= h_24x7_event_update,
+   .read= h_24x7_event_read,
 };
 
 static int hv_24x7_init(void)
-- 
1.8.3.1

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


[PATCH v2 01/10] powerpc/hv-24x7: Modify definition of request and result buffers

2015-03-30 Thread Sukadev Bhattiprolu
The parameters to the 24x7 HCALL have variable number of elements in them.
Set the minimum number of such elements to 1 rather than 0 and eliminate
the temporary structures.

This would enable us to submit multiple counter requests and process
multiple results from a single HCALL (in a follow on patch).

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 77 ++---
 arch/powerpc/perf/hv-24x7.h |  8 ++---
 2 files changed, 41 insertions(+), 44 deletions(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 9445a82..408e6e9 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -142,6 +142,15 @@ static struct attribute_group event_long_desc_group = {
 
 static struct kmem_cache *hv_page_cache;
 
+/*
+ * request_buffer and result_buffer are not required to be 4k aligned,
+ * but are not allowed to cross any 4k boundary. Aligning them to 4k is
+ * the simplest way to ensure that.
+ */
+#define H24x7_DATA_BUFFER_SIZE 4096
+DEFINE_PER_CPU(char, hv_24x7_reqb[H24x7_DATA_BUFFER_SIZE]) __aligned(4096);
+DEFINE_PER_CPU(char, hv_24x7_resb[H24x7_DATA_BUFFER_SIZE]) __aligned(4096);
+
 static char *event_name(struct hv_24x7_event_data *ev, int *len)
 {
*len = be16_to_cpu(ev->event_name_len) - 2;
@@ -976,31 +985,16 @@ static const struct attribute_group *attr_groups[] = {
NULL,
 };
 
-DEFINE_PER_CPU(char, hv_24x7_reqb[4096]) __aligned(4096);
-DEFINE_PER_CPU(char, hv_24x7_resb[4096]) __aligned(4096);
-
 static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
-u16 lpar, u64 *res,
+u16 lpar, u64 *count,
 bool success_expected)
 {
unsigned long ret;
 
-   /*
-* request_buffer and result_buffer are not required to be 4k aligned,
-* but are not allowed to cross any 4k boundary. Aligning them to 4k is
-* the simplest way to ensure that.
-*/
-   struct reqb {
-   struct hv_24x7_request_buffer buf;
-   struct hv_24x7_request req;
-   } __packed *request_buffer;
-
-   struct {
-   struct hv_24x7_data_result_buffer buf;
-   struct hv_24x7_result res;
-   struct hv_24x7_result_element elem;
-   __be64 result;
-   } __packed *result_buffer;
+   struct hv_24x7_request_buffer *request_buffer;
+   struct hv_24x7_data_result_buffer *result_buffer;
+   struct hv_24x7_result *resb;
+   struct hv_24x7_request *req;
 
BUILD_BUG_ON(sizeof(*request_buffer) > 4096);
BUILD_BUG_ON(sizeof(*result_buffer) > 4096);
@@ -1011,38 +1005,41 @@ static unsigned long single_24x7_request(u8 domain, u32 
offset, u16 ix,
memset(request_buffer, 0, 4096);
memset(result_buffer, 0, 4096);
 
-   *request_buffer = (struct reqb) {
-   .buf = {
-   .interface_version = HV_24X7_IF_VERSION_CURRENT,
-   .num_requests = 1,
-   },
-   .req = {
-   .performance_domain = domain,
-   .data_size = cpu_to_be16(8),
-   .data_offset = cpu_to_be32(offset),
-   .starting_lpar_ix = cpu_to_be16(lpar),
-   .max_num_lpars = cpu_to_be16(1),
-   .starting_ix = cpu_to_be16(ix),
-   .max_ix = cpu_to_be16(1),
-   }
-   };
+   request_buffer->interface_version = HV_24X7_IF_VERSION_CURRENT;
+   request_buffer->num_requests = 1;
+
+   req = _buffer->requests[0];
 
+   req->performance_domain = domain;
+   req->data_size = cpu_to_be16(8);
+   req->data_offset = cpu_to_be32(offset);
+   req->starting_lpar_ix = cpu_to_be16(lpar),
+   req->max_num_lpars = cpu_to_be16(1);
+   req->starting_ix = cpu_to_be16(ix);
+   req->max_ix = cpu_to_be16(1);
+
+   /*
+* NOTE: Due to variable number of array elements in request and
+*   result buffer(s), sizeof() is not reliable. Use the actual
+*   allocated buffer size, H24x7_DATA_BUFFER_SIZE.
+*/
ret = plpar_hcall_norets(H_GET_24X7_DATA,
-   virt_to_phys(request_buffer), sizeof(*request_buffer),
-   virt_to_phys(result_buffer),  sizeof(*result_buffer));
+   virt_to_phys(request_buffer), H24x7_DATA_BUFFER_SIZE,
+   virt_to_phys(result_buffer),  H24x7_DATA_BUFFER_SIZE);
 
if (ret) {
if (success_expected)
pr_err_ratelimited("hcall failed: %d %#x %#x %d => "
"0x%lx (%ld) detail=0x%x failing ix=%x\n",
domain, offset, ix, lpar, ret, ret,
-   result_buffer->buf.detailed_rc,
-

[PATCH 1/1] powerpc/hv-24x7: Add missing put_cpu_var()

2015-03-30 Thread Sukadev Bhattiprolu
From: Sukadev Bhattiprolu 
Date: Tue, 17 Feb 2015 14:14:36 -0500
Subject: [PATCH 1/1] powerpc/hv-24x7: Add missing put_cpu_var()

Add missing put_cpu_var() for 24x7 requests. This went missing in
commit f34b6c7 (3.18-rc3).

Signed-off-by: Sukadev Bhattiprolu 
---
 arch/powerpc/perf/hv-24x7.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 46be032..ead8878 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1096,7 +1096,7 @@ static unsigned long single_24x7_request(struct 
perf_event *event, u64 *count)
 
ret = add_event_to_24x7_request(event, request_buffer);
if (ret)
-   return ret;
+   goto out;
 
ret = make_24x7_request(request_buffer, result_buffer);
if (ret) {
@@ -1109,6 +1109,8 @@ static unsigned long single_24x7_request(struct 
perf_event *event, u64 *count)
*count = be64_to_cpu(resb->elements[0].element_data[0]);
 
 out:
+   put_cpu_var(hv_24x7_reqb);
+   put_cpu_var(hv_24x7_resb);
return ret;
 }
 
-- 
1.8.3.1

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


Re: [patch v11 13/23] ACPI / processor: Introduce phys_cpuid_t for CPU hardware ID

2015-03-30 Thread Hanjun Guo
On 2015/3/30 21:58, Catalin Marinas wrote:
> On Fri, Mar 27, 2015 at 09:40:26PM +0800, Hanjun Guo wrote:
>> On 2015年03月26日 11:49, Hanjun Guo wrote:
>>> On 2015/3/26 1:21, Catalin Marinas wrote:
 On Tue, Mar 24, 2015 at 10:02:46PM +0800, Hanjun Guo wrote:
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -170,7 +170,7 @@ static int acpi_processor_hotadd_init(struct 
> acpi_processor *pr)
>   acpi_status status;
>   int ret;
>
> - if (pr->phys_id == -1)
> + if (pr->phys_id == PHYS_CPUID_INVALID)
>   return -ENODEV;
 If PHYS_CPUID_INVALID is the same as INVALID_HWID, we should get rid of
 the latter in the arm64 code (as a subsequent clean-up patch).
>>> OK, I'm preparing a patch set to introduce invalid_phys_cpuid() and 
>>> invalid_logical_cpuid()
>>> to remove the direct comparison of PHYS_CPUID_INVALID and -1 in ACPI 
>>> processor drivers,
>>> which is suggested by Rafael, I will cleanup PHYS_CPUID_INVALID in this 
>>> patch set.
>> I met difficulty to do so, because we use
>>
>> +#ifndef PHYS_CPUID_INVALID
>> +typedef u32 phys_cpuid_t;
>> +#define PHYS_CPUID_INVALID (phys_cpuid_t)(-1)
>> +#endif
>>
>> in the common head file linux/acpi.h, we need macro
>> PHYS_CPUID_INVALID to identify if phys_cpuid_t is typedefed
>> for different arch, so if we want remove PHYS_CPUID_INVALID
>> for ARM64, we need to got back to typedef phys_cpuid_t for
>> each arch using ACPI. which means that
> What I meant was removing INVALID_HWID from arm64 and always use the
> PHYS_CPUID_INVALID but I think we should leave them as they are for now
> since PHYS_CPUID_INVALID is defined in the asm/acpi.h file.

OK, thanks for the clarify.

Hanjun

--
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/7] clk: Add basic infrastructure for Pistachio clocks

2015-03-30 Thread Andrew Bresticker
Hi Mike,

On Mon, Mar 30, 2015 at 6:36 PM, Michael Turquette
 wrote:
> Quoting Andrew Bresticker (2015-03-30 17:15:43)
>> On Mon, Mar 30, 2015 at 4:59 PM, Stephen Boyd  wrote:
>> > On 02/24/15 19:56, Andrew Bresticker wrote:
>> >> +
>> >> +void pistachio_clk_force_enable(struct pistachio_clk_provider *p,
>> >> + unsigned int *clk_ids, unsigned int num)
>> >> +{
>> >> + unsigned int i;
>> >> + int err;
>> >> +
>> >> + for (i = 0; i < num; i++) {
>> >> + struct clk *clk = p->clk_data.clks[clk_ids[i]];
>> >> +
>> >> + if (IS_ERR(clk))
>> >> + continue;
>> >> +
>> >> + err = clk_prepare_enable(clk);
>> >> + if (err)
>> >> + pr_err("Failed to enable clock %s: %d\n",
>> >> +__clk_get_name(clk), err);
>> >> + }
>> >> +}
>> >>
>> >
>> > Is this to workaround some problems in the framework where clocks are
>> > turned off? Or is it that these clocks are already on before we boot
>> > Linux and we need to make sure the framework knows that?
>>
>> It's the former.  These clocks are enabled at POR and may only be
>> gated as the final step to entering suspend, so they must remain on at
>> runtime.  The issue we were running into was that consumers of these
>> critical clocks or their descendants would enable/disable their clocks
>> during boot or runtime PM and cause these clocks to get disabled.
>> Bumping up the prepare/enable count of these critical clocks seemed
>> like the best way to handle this - is there a more preferred way?
>> FWIW, this is also how the Tegra and Rockchip drivers handled this
>> problem.
>
> Hi Andrew,
>
> Why are your drivers allowed to disable clocks which must not be
> disabled? (you mentioned boot and runtime pm)

The issue is that they do not directly consume a critical clock, but
rather a descendant of the critical clock and thus could cause the
critical clock to be disabled.  For example, the periph_sys clock is
one of these critical clocks and it is the parent of various
peripheral clocks, like the watchdog, I2C, PWM, etc.  If the I2C
driver enables and disables it's clock during probe(), and nothing
else has caused the periph_sys clock to be enabled, the disable() call
will cause periph_sys to become disabled since its enable count drops
to 0.

Now this could be solved if there was a driver to directly consume
these clocks and keep them enabled, but, like Stephen mentioned, there
really isn't a proper driver for that.  So it looks like I want
something like the always-on feature Lee is trying to introduce.

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


[PATCH] mm: numa: disable change protection for vma(VM_HUGETLB)

2015-03-30 Thread Naoya Horiguchi
On Mon, Mar 30, 2015 at 12:59:01PM +0100, Mel Gorman wrote:
> On Mon, Mar 30, 2015 at 07:42:13PM +0900, Naoya Horiguchi wrote:
...
> 
> I note now that the patch was too hasty. By rights, that check
> should be covered by vma_migratable() but it's only checked if
> CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION which means it's x86-only. If you
> are seeing this problem on any other arch then a more correct fix might be
> to remove the CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION check in vma_migratable.

Changing vma_migratable() affects other usecases of hugepage migration like
mbind(), so simply removing the ifdef doesn't work for such usecases.
I didn't test other archs, but I guess that this problem could happen on all
archs enabling numa balancing, whether it supports 
CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION.

So I'd like pick/push your first suggestion. It passed my testing.

Thanks,
Naoya Horiguchi
---
From: Naoya Horiguchi 
Subject: [PATCH] mm: numa: disable change protection for vma(VM_HUGETLB)

Currently when a process accesses to hugetlb range protected with PROTNONE,
unexpected COWs are triggered, which finally put hugetlb subsystem into
broken/uncontrollable state, where for example h->resv_huge_pages is subtracted
too much and wrapped around to a very large number, and free hugepage pool
is no longer maintainable.

This patch simply stops changing protection for vma(VM_HUGETLB) to fix the
problem. And this also allows us to avoid useless overhead of minor faults.

Suggested-by: Mel Gorman 
Signed-off-by: Naoya Horiguchi 
---
 kernel/sched/fair.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7ce18f3c097a..6ad0d570f38e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2161,8 +2161,10 @@ void task_numa_work(struct callback_head *work)
vma = mm->mmap;
}
for (; vma; vma = vma->vm_next) {
-   if (!vma_migratable(vma) || !vma_policy_mof(vma))
+   if (!vma_migratable(vma) || !vma_policy_mof(vma) ||
+   is_vm_hugetlb_page(vma)) {
continue;
+   }
 
/*
 * Shared library pages mapped by multiple processes are not
-- 
1.9.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: [Linaro-acpi] [PATCH 1/2] ARM64 / ACPI: Ignore the return error value of acpi_map_gic_cpu_interface()

2015-03-30 Thread Hanjun Guo
On 2015/3/31 5:53, Al Stone wrote:
> On 03/27/2015 06:14 AM, Hanjun Guo wrote:
>> MADT table scannig will stopped once it gets the errors
>> returned by the handler, which is acpi_map_gic_cpu_interface()
>> in for ARM64, so Ignore the return error value to search for
>> all enabled CPUs for SMP init.
> I think the comment should say something like:
>
> MADT scanning will stop when it gets an error from the handler,
> acpi_map_gic_cpu_interface(), on arm64.  However, we need to
> find all of the enabled CPUs so that SMP initialization can work
> properly.  So, if an error occurs in this case, ignore it for
> now so that we can find all of the enabled CPUs.
>
> Is that what you meant, Hanjun?

That's exactly what I mean, you describe it much clearer :)

Thanks
Hanjun

--
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 char-misc-next v4 02/13] misc: mic: SCIF ring buffer infrastructure

2015-03-30 Thread Sudeep Dutt
SCIF ring buffer is a single producer, single consumer byte stream
ring buffer optimized for avoiding reads across the PCIe bus while
adding the required barriers and hardware workarounds for the MIC
Coprocessor. The ring buffer is used to implement a receive queue for
SCIF driver messaging between two nodes and for byte stream messaging
between SCIF endpoints. The existing in-kernel ring buffer was not
reused since it has not been designed for our use across the PCIe bus
where each node runs an independent OS. Each SCIF node has a receive
queue for every other SCIF node, and each connected endpoint has a
receive queue for messages from its peer. This pair of receive
queues is referred to as a SCIF queue pair.

Reviewed-by: Nikhil Rao 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/scif/scif_rb.h | 100 
 drivers/misc/mic/scif/scif_rb.c | 248 
 2 files changed, 348 insertions(+)
 create mode 100644 drivers/misc/mic/scif/scif_rb.h
 create mode 100644 drivers/misc/mic/scif/scif_rb.c

diff --git a/drivers/misc/mic/scif/scif_rb.h b/drivers/misc/mic/scif/scif_rb.h
new file mode 100644
index 000..166dffe
--- /dev/null
+++ b/drivers/misc/mic/scif/scif_rb.h
@@ -0,0 +1,100 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2014 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License 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.
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2014 Intel Corporation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Intel SCIF driver.
+ */
+#ifndef SCIF_RB_H
+#define SCIF_RB_H
+/*
+ * This file describes a general purpose, byte based ring buffer. Writers to 
the
+ * ring buffer need to synchronize using a lock. The same is true for readers,
+ * although in practice, the ring buffer has a single reader. It is lockless
+ * between producer and consumer so it can handle being used across the PCIe
+ * bus. The ring buffer ensures that there are no reads across the PCIe bus for
+ * performance reasons. Two of these are used to form a single bidirectional
+ * queue-pair across PCIe.
+ */
+/*
+ * struct scif_rb - SCIF Ring Buffer
+ *
+ * @rb_base: The base of the memory used for storing RB messages
+ * @read_ptr: Pointer to the read offset
+ * @write_ptr: Pointer to the write offset
+ * @size: Size of the memory in rb_base
+ * @current_read_offset: Cached read offset for performance
+ * @current_write_offset: Cached write offset for performance
+ */
+struct scif_rb {
+   void *rb_base;
+   u32 *read_ptr;
+   u32 *write_ptr;
+   u32 size;
+   u32 current_read_offset;
+   u32 current_write_offset;
+};
+
+/* methods used by both */
+void scif_rb_init(struct scif_rb *rb, u32 *read_ptr, u32 *write_ptr,
+ void *rb_base, u8 size);
+/* writer only methods */
+/* write a new command, then scif_rb_commit() */
+int scif_rb_write(struct scif_rb *rb, void *msg, u32 

[PATCH char-misc-next v4 01/13] misc: mic: SCIF header file and IOCTL interface

2015-03-30 Thread Sudeep Dutt
This patch introduces the SCIF documentation in the header file
and describes the IOCTL interface for user mode. mic_overview.txt
is updated with documentation on SCIF and a new document
describing SCIF in more details is available in scif_overview.txt.

Reviewed-by: Nikhil Rao 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 Documentation/mic/mic_overview.txt  |  28 +-
 Documentation/mic/scif_overview.txt |  98 
 include/uapi/linux/Kbuild   |   1 +
 include/linux/scif.h| 993 
 include/uapi/linux/scif_ioctl.h | 130 +
 5 files changed, 1238 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/mic/scif_overview.txt
 create mode 100644 include/linux/scif.h
 create mode 100644 include/uapi/linux/scif_ioctl.h

diff --git a/Documentation/mic/mic_overview.txt 
b/Documentation/mic/mic_overview.txt
index 77c5418..1a2f2c8 100644
--- a/Documentation/mic/mic_overview.txt
+++ b/Documentation/mic/mic_overview.txt
@@ -24,6 +24,10 @@ a virtual bus called mic bus is created and virtual dma 
devices are
 created on it by the host/card drivers. On host the channels are private
 and used only by the host driver to transfer data for the virtio devices.
 
+The Symmetric Communication Interface (SCIF (pronounced as skiff)) is a
+low level communications API across PCIe currently implemented for MIC.
+More details are available at scif_overview.txt.
+
 Here is a block diagram of the various components described above. The
 virtio backends are situated on the host rather than the card given better
 single threaded performance for the host compared to MIC, the ability of
@@ -47,18 +51,18 @@ the fact that the virtio block storage backend can only be 
on the host.
   |   |   | Virtio over PCIe IOCTLs  |
   |   |   +--+
 +---+ |   |   |  +---+
-| MIC DMA   | |   |   |  | MIC DMA   |
-| Driver| |   |   |  | Driver|
-+---+ |   |   |  +---+
-  |   |   |   ||
-+---+ |   |   |  ++
-|MIC virtual Bus| |   |   |  |MIC virtual Bus |
-+---+ |   |   |  ++
-  |   |   |   |  |
-  |   +--+|+---+ |
-  |   |Intel MIC |||Intel MIC  | |
-  +---|Card Driver   |||Host Driver| |
-  +--+|+---+-+
+| MIC DMA   | |  +--+ | +---+ |  | MIC DMA   |
+| Driver| |  |  SCIF| | |   SCIF| |  | Driver|
++---+ |  +--+ | +---+ |  +---+
+  |   |   |   |   |   ||
++---+ | +-+-+ | +-+-+ | +---+
+|MIC virtual Bus| | |SCIF HW Bus| | |SCIF HW BUS| | |MIC virtual Bus|
++---+ | +---+ | +-+-+ | +---+
+  |   |   |   |   |   |  |
+  |   +--+|   |   |+---+ |
+  |   |Intel MIC ||   |   ||Intel MIC  | |
+  +---|Card Driver   ++   |   ||Host Driver| |
+  +--+|   ++---+-+
   |   |   |
  +-+
  | |
diff --git a/Documentation/mic/scif_overview.txt 
b/Documentation/mic/scif_overview.txt
new file mode 100644
index 000..0a280d9
--- /dev/null
+++ b/Documentation/mic/scif_overview.txt
@@ -0,0 +1,98 @@
+The Symmetric Communication Interface (SCIF (pronounced as skiff)) is a low
+level communications API across PCIe currently implemented for MIC. Currently
+SCIF provides inter-node communication within a single host platform, where a
+node is a MIC Coprocessor or Xeon based host. SCIF abstracts the details of
+communicating over the PCIe bus while providing an API that is symmetric
+across all the nodes in the PCIe network. An important design objective for 
SCIF
+is to deliver the maximum possible performance given the communication
+abilities of the hardware. SCIF has been used to implement an offload compiler
+runtime and OFED support for MPI implementations for MIC coprocessors.
+
+ SCIF API Components 
+The SCIF API has the 

[PATCH char-misc-next v4 03/13] misc: mic: SCIF Hardware Bus

2015-03-30 Thread Sudeep Dutt
The SCIF hardware bus abstracts the low level hardware driver details
like interrupts and mapping remote memory so that the same SCIF driver
can work without any changes with the MIC host or card driver as long
as the hardware bus operations are implemented. The SCIF hardware
device is registered by the host and card drivers on the SCIF hardware
bus resulting in probing the SCIF driver.

Reviewed-by: Nikhil Rao 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/Kconfig|  17 
 drivers/misc/mic/Makefile   |   2 +-
 drivers/misc/mic/bus/Makefile   |   1 +
 drivers/misc/mic/bus/scif_bus.h | 129 
 drivers/misc/mic/bus/scif_bus.c | 210 
 5 files changed, 358 insertions(+), 1 deletion(-)
 create mode 100644 drivers/misc/mic/bus/scif_bus.h
 create mode 100644 drivers/misc/mic/bus/scif_bus.c

diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig
index cc4eef0..afc9f53 100644
--- a/drivers/misc/mic/Kconfig
+++ b/drivers/misc/mic/Kconfig
@@ -15,6 +15,23 @@ config INTEL_MIC_BUS
  OS and tools for MIC to use with this driver are available from
  .
 
+comment "SCIF Bus Driver"
+
+config SCIF_BUS
+   tristate "SCIF Bus Driver"
+   depends on 64BIT && PCI && X86 && X86_DEV_DMA_OPS
+   help
+ This option is selected by any driver which registers a
+ device or driver on the SCIF Bus, such as CONFIG_INTEL_MIC_HOST
+ and CONFIG_INTEL_MIC_CARD.
+
+ If you are building a host/card kernel with an Intel MIC device
+ then say M (recommended) or Y, else say N. If unsure say N.
+
+ More information about the Intel MIC family as well as the Linux
+ OS and tools for MIC to use with this driver are available from
+ .
+
 comment "Intel MIC Host Driver"
 
 config INTEL_MIC_HOST
diff --git a/drivers/misc/mic/Makefile b/drivers/misc/mic/Makefile
index e9bf148..6bc6083 100644
--- a/drivers/misc/mic/Makefile
+++ b/drivers/misc/mic/Makefile
@@ -4,4 +4,4 @@
 #
 obj-$(CONFIG_INTEL_MIC_HOST) += host/
 obj-$(CONFIG_INTEL_MIC_CARD) += card/
-obj-$(CONFIG_INTEL_MIC_BUS) += bus/
+obj-y += bus/
diff --git a/drivers/misc/mic/bus/Makefile b/drivers/misc/mic/bus/Makefile
index d85c7f2..1ed37e2 100644
--- a/drivers/misc/mic/bus/Makefile
+++ b/drivers/misc/mic/bus/Makefile
@@ -3,3 +3,4 @@
 # Copyright(c) 2014, Intel Corporation.
 #
 obj-$(CONFIG_INTEL_MIC_BUS) += mic_bus.o
+obj-$(CONFIG_SCIF_BUS) += scif_bus.o
diff --git a/drivers/misc/mic/bus/scif_bus.h b/drivers/misc/mic/bus/scif_bus.h
new file mode 100644
index 000..335a228
--- /dev/null
+++ b/drivers/misc/mic/bus/scif_bus.h
@@ -0,0 +1,129 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2014 Intel Corporation.
+ *
+ * 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.
+ *
+ * Intel Symmetric Communications Interface Bus driver.
+ */
+#ifndef _SCIF_BUS_H_
+#define _SCIF_BUS_H_
+/*
+ * Everything a scif driver needs to work with any particular scif
+ * hardware abstraction layer.
+ */
+#include 
+
+#include 
+#include "../common/mic_dev.h"
+
+struct scif_hw_dev_id {
+   u32 device;
+   u32 vendor;
+};
+
+#define MIC_SCIF_DEV 1
+#define SCIF_DEV_ANY_ID 0x
+
+/**
+ * scif_hw_dev - representation of a hardware device abstracted for scif
+ * @hw_ops: the hardware ops supported by this device
+ * @id: the device type identification (used to match it with a driver)
+ * @mmio: MMIO memory window
+ * @aper: Aperture memory window
+ * @dev: underlying device
+ * @dnode - The destination node which this device will communicate with.
+ * @snode - The source node for this device.
+ * @dp - Self device page
+ * @rdp - Remote device page
+ * @dma_ch - Array of DMA channels
+ * @num_dma_ch - Number of DMA channels available
+ */
+struct scif_hw_dev {
+   struct scif_hw_ops *hw_ops;
+   struct scif_hw_dev_id id;
+   struct mic_mw *mmio;
+   struct mic_mw *aper;
+   struct device dev;
+   u8 dnode;
+   u8 snode;
+   void *dp;
+   void __iomem *rdp;
+   struct dma_chan **dma_ch;
+   int num_dma_ch;
+};
+
+/**
+ * scif_driver - operations for a scif I/O driver
+ * @driver: underlying device driver (populate name and owner).
+ * @id_table: the ids serviced by this driver.
+ * @probe: the function to call when a device is found.  Returns 0 or -errno.
+ * @remove: the function to call when a device is removed.
+ */
+struct scif_driver {
+   struct 

Re: [RFC PATCH v3 1/2] clk: samsung: Add a clock lookup function

2015-03-30 Thread Michael Turquette
Quoting Javier Martinez Canillas (2015-03-30 09:08:40)
> Hello Tomasz,
> 
> On 03/30/2015 06:02 PM, Tomasz Figa wrote:
> > Hi Javier,
> > 
> > 2015-03-31 0:53 GMT+09:00 Javier Martinez Canillas
> > :
> >> The Samsung helpers functions to register clocks, add the clock instance
> >> returned by the common clock framework to a lookup table that is used by
> >> OF to lookup the clocks.
> >>
> >> But this table could also be useful to clock drivers if they need to get
> >> a clock instance since the helper functions don't return them.
> >>
> >> The common clock framework __clk_lookup() function from the clk provider
> >> API could be used by drivers as well. But it's more efficient to use the
> >> Samsung specific lookup table that returns the clock instance in constant
> >> time, than using the __clk_lookup() function that uses the clock name as
> >> an index so it has a linear search time.
> > 
> > Is this really something we should be concerned about? If so, maybe
> > the generic look-up function should be rewritten to use something
> > faster, such as tree or hash table?
> >
> 
> I don't performance is a big issue here. I just thought that since the
> lookup table is already filled by the driver and the lookup function
> is one line, we could use that instead to get the performance benefit.
> 
> But I don't mind to drop this patch and use the generic lookup function
> from the CCF API if that is preferred.

Hello,

I am not a fan of __clk_lookup and I don't like to see it used more and
more outside of drivers/clk/clk.c. You mentioned that performance wasn't
really the problem here.  The real method for a driver to get a clock is
with clk_get(). Any reason to not use that?

Regards,
Mike

>  
> > Best regards,
> > Tomasz
> >
> 
> Best regards,
> Javier
--
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 char-misc-next v4 04/13] misc: mic: SCIF Peer Bus

2015-03-30 Thread Sudeep Dutt
The SCIF peer bus is used to register and unregister SCIF peer devices
internally by the SCIF driver to signify the addition and removal of
peer nodes respectively from the SCIF network. This simplifies remote node
handling within SCIF and will also be used to support device probe/remove
for SCIF client drivers (e.g. netdev over SCIF)

Reviewed-by: Nikhil Rao 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/scif/scif_peer_bus.h |  65 ++
 drivers/misc/mic/scif/scif_peer_bus.c | 124 ++
 2 files changed, 189 insertions(+)
 create mode 100644 drivers/misc/mic/scif/scif_peer_bus.h
 create mode 100644 drivers/misc/mic/scif/scif_peer_bus.c

diff --git a/drivers/misc/mic/scif/scif_peer_bus.h 
b/drivers/misc/mic/scif/scif_peer_bus.h
new file mode 100644
index 000..33f0dbb
--- /dev/null
+++ b/drivers/misc/mic/scif/scif_peer_bus.h
@@ -0,0 +1,65 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2014 Intel Corporation.
+ *
+ * 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.
+ *
+ * Intel SCIF driver.
+ */
+#ifndef _SCIF_PEER_BUS_H_
+#define _SCIF_PEER_BUS_H_
+
+#include 
+#include 
+
+/*
+ * Peer devices show up as PCIe devices for the mgmt node but not the cards.
+ * The mgmt node discovers all the cards on the PCIe bus and informs the other
+ * cards about their peers. Upon notification of a peer a node adds a peer
+ * device to the peer bus to maintain symmetry in the way devices are
+ * discovered across all nodes in the SCIF network.
+ */
+/**
+ * scif_peer_dev - representation of a peer SCIF device
+ * @dev: underlying device
+ * @dnode - The destination node which this device will communicate with.
+ */
+struct scif_peer_dev {
+   struct device dev;
+   u8 dnode;
+};
+
+/**
+ * scif_peer_driver - operations for a scif_peer I/O driver
+ * @driver: underlying device driver (populate name and owner).
+ * @id_table: the ids serviced by this driver.
+ * @probe: the function to call when a device is found.  Returns 0 or -errno.
+ * @remove: the function to call when a device is removed.
+ */
+struct scif_peer_driver {
+   struct device_driver driver;
+   const struct scif_peer_dev_id *id_table;
+
+   int (*probe)(struct scif_peer_dev *dev);
+   void (*remove)(struct scif_peer_dev *dev);
+};
+
+struct scif_dev;
+
+int scif_peer_register_driver(struct scif_peer_driver *driver);
+void scif_peer_unregister_driver(struct scif_peer_driver *driver);
+
+struct scif_peer_dev *scif_peer_register_device(struct scif_dev *sdev);
+void scif_peer_unregister_device(struct scif_peer_dev *sdev);
+
+int scif_peer_bus_init(void);
+void scif_peer_bus_exit(void);
+#endif /* _SCIF_PEER_BUS_H */
diff --git a/drivers/misc/mic/scif/scif_peer_bus.c 
b/drivers/misc/mic/scif/scif_peer_bus.c
new file mode 100644
index 000..589ae9a
--- /dev/null
+++ b/drivers/misc/mic/scif/scif_peer_bus.c
@@ -0,0 +1,124 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2014 Intel Corporation.
+ *
+ * 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.
+ *
+ * Intel SCIF driver.
+ */
+#include "scif_main.h"
+#include "../bus/scif_bus.h"
+#include "scif_peer_bus.h"
+
+static inline struct scif_peer_dev *
+dev_to_scif_peer(struct device *dev)
+{
+   return container_of(dev, struct scif_peer_dev, dev);
+}
+
+static inline struct scif_peer_driver *
+drv_to_scif_peer(struct device_driver *drv)
+{
+   return container_of(drv, struct scif_peer_driver, driver);
+}
+
+static int scif_peer_dev_match(struct device *dv, struct device_driver *dr)
+{
+   return !strncmp(dev_name(dv), dr->name, 4);
+}
+
+static int scif_peer_dev_probe(struct device *d)
+{
+   struct scif_peer_dev *dev = dev_to_scif_peer(d);
+   struct scif_peer_driver *drv = drv_to_scif_peer(dev->dev.driver);
+
+   return drv->probe(dev);
+}
+
+static int scif_peer_dev_remove(struct device *d)
+{
+   struct scif_peer_dev *dev = dev_to_scif_peer(d);
+   struct scif_peer_driver *drv = drv_to_scif_peer(dev->dev.driver);
+
+   drv->remove(dev);
+   return 0;
+}
+
+static struct bus_type scif_peer_bus = {
+   .name  = "scif_peer_bus",
+   .match = 

[PATCH char-misc-next v4 07/13] misc: mic: SCIF node queue pair setup management

2015-03-30 Thread Sudeep Dutt
SCIF node queue pair setup creates the SCIF driver kernel
mode private node queue pairs between all the nodes to enable
internal control message communication once SCIF gets probed
by the SCIF hardware bus. Peer to peer communication between
MIC Coprocessor nodes is supported.

Reviewed-by: Nikhil Rao 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/scif/scif_nodeqp.h |  173 +
 drivers/misc/mic/scif/scif_nm.c |  184 +
 drivers/misc/mic/scif/scif_nodeqp.c | 1264 +++
 3 files changed, 1621 insertions(+)
 create mode 100644 drivers/misc/mic/scif/scif_nodeqp.h
 create mode 100644 drivers/misc/mic/scif/scif_nm.c
 create mode 100644 drivers/misc/mic/scif/scif_nodeqp.c

diff --git a/drivers/misc/mic/scif/scif_nodeqp.h 
b/drivers/misc/mic/scif/scif_nodeqp.h
new file mode 100644
index 000..6200292
--- /dev/null
+++ b/drivers/misc/mic/scif/scif_nodeqp.h
@@ -0,0 +1,173 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2014 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License 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.
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2014 Intel Corporation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Intel SCIF driver.
+ *
+ */
+#ifndef SCIF_NODEQP
+#define SCIF_NODEQP
+
+#include "scif_rb.h"
+#include "scif_peer_bus.h"
+
+#define SCIF_INIT 1  /* First message sent to the peer node for discovery */
+#define SCIF_EXIT 2  /* Last message from the peer informing intent to exit */
+#define SCIF_EXIT_ACK 3 /* Response to SCIF_EXIT message */
+#define SCIF_NODE_ADD 4  /* Tell Online nodes a new node exits */
+#define SCIF_NODE_ADD_ACK 5  /* Confirm to mgmt node sequence is finished */
+#define SCIF_NODE_ADD_NACK 6 /* SCIF_NODE_ADD failed */
+#define SCIF_NODE_REMOVE 7 /* Request to deactivate a SCIF node */
+#define SCIF_NODE_REMOVE_ACK 8 /* Response to a SCIF_NODE_REMOVE message */
+#define SCIF_MAX_MSG SCIF_NODE_REMOVE_ACK
+
+/*
+ * struct scifmsg - Node QP message format
+ *
+ * @src: Source information
+ * @dst: Destination information
+ * @uop: The message opcode
+ * @payload: Unique payload format for each message
+ */
+struct scifmsg {
+   struct scif_port_id src;
+   struct scif_port_id dst;
+   u32 uop;
+   u64 payload[4];
+} __packed;
+
+/*
+ * struct scif_qp - Node Queue Pair
+ *
+ * Interesting structure -- a little difficult because we can only
+ * write across the PCIe, so any r/w pointer we need to read is
+ * local. We only need to read the read pointer on the inbound_q
+ * and read the write pointer in the outbound_q
+ *
+ * @magic: Magic value to ensure the peer sees the QP correctly
+ * @outbound_q: The outbound ring buffer for sending messages
+ * @inbound_q: The inbound ring buffer for receiving messages
+ * @local_write: Local write index
+ * @local_read: Local read index
+ * @remote_qp: The remote queue pair
+ * @local_buf: DMA address of local ring buffer
+ 

[PATCH char-misc-next v4 09/13] misc: mic: SCIF connections APIs i.e. accept and connect

2015-03-30 Thread Sudeep Dutt
From: Nikhil Rao 

SCIF connection APIs which establish a SCIF connection between
a pair of SCIF endpoints. A SCIF connection consists of a
dedicated queue-pair between the endpoints. Client messages are
sent over the queue-pair whereas the signaling associated with the
message is multiplexed over the node queue-pair. Similarly other
control messages such as exposing registered memory are also sent
over the node queue-pair. The SCIF endpoints must be in connected
state to exchange messages, register memory, map remote memory and
trigger DMA transfers. SCIF connections can be set up
asynchronously or synchronously.

Thanks to Johnnie S Peters for authoring parts of this patch during
early bring up of the SCIF driver.

Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
Signed-off-by: Nikhil Rao 
---
 drivers/misc/mic/scif/scif_epd.h|   8 +
 drivers/misc/mic/scif/scif_api.c| 457 
 drivers/misc/mic/scif/scif_epd.c| 229 ++
 drivers/misc/mic/scif/scif_fd.c | 106 +
 drivers/misc/mic/scif/scif_main.c   |   1 +
 drivers/misc/mic/scif/scif_nm.c |  36 +++
 drivers/misc/mic/scif/scif_nodeqp.c |  16 +-
 7 files changed, 852 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mic/scif/scif_epd.h b/drivers/misc/mic/scif/scif_epd.h
index b973b99..65c628e 100644
--- a/drivers/misc/mic/scif/scif_epd.h
+++ b/drivers/misc/mic/scif/scif_epd.h
@@ -144,5 +144,13 @@ int scif_rsrv_port(u16 port);
 void scif_get_port(u16 port);
 int scif_get_new_port(void);
 void scif_put_port(u16 port);
+void scif_cnctreq(struct scif_dev *scifdev, struct scifmsg *msg);
+void scif_cnctgnt(struct scif_dev *scifdev, struct scifmsg *msg);
+void scif_cnctgnt_ack(struct scif_dev *scifdev, struct scifmsg *msg);
+void scif_cnctgnt_nack(struct scif_dev *scifdev, struct scifmsg *msg);
+void scif_cnctrej(struct scif_dev *scifdev, struct scifmsg *msg);
+void scif_discnct(struct scif_dev *scifdev, struct scifmsg *msg);
+void scif_discnt_ack(struct scif_dev *scifdev, struct scifmsg *msg);
+int __scif_connect(scif_epd_t epd, struct scif_port_id *dst, bool non_block);
 int __scif_flush(scif_epd_t epd);
 #endif /* SCIF_EPD_H */
diff --git a/drivers/misc/mic/scif/scif_api.c b/drivers/misc/mic/scif/scif_api.c
index cbdc27b..da64cee 100644
--- a/drivers/misc/mic/scif/scif_api.c
+++ b/drivers/misc/mic/scif/scif_api.c
@@ -415,3 +415,460 @@ int scif_listen(scif_epd_t epd, int backlog)
return 0;
 }
 EXPORT_SYMBOL_GPL(scif_listen);
+
+/*
+ 
+ * SCIF connection flow:
+ *
+ * 1) A SCIF listening endpoint can call scif_accept(..) to wait for SCIF
+ * connections via a SCIF_CNCT_REQ message
+ * 2) A SCIF endpoint can initiate a SCIF connection by calling
+ * scif_connect(..) which calls scif_setup_qp_connect(..) which
+ * allocates the local qp for the endpoint ring buffer and then sends
+ * a SCIF_CNCT_REQ to the remote node and waits for a SCIF_CNCT_GNT or
+ * a SCIF_CNCT_REJ message
+ * 3) The peer node handles a SCIF_CNCT_REQ via scif_cnctreq_resp(..) which
+ * wakes up any threads blocked in step 1 or sends a SCIF_CNCT_REJ
+ * message otherwise
+ * 4) A thread blocked waiting for incoming connections allocates its local
+ * endpoint QP and ring buffer following which it sends a SCIF_CNCT_GNT
+ * and waits for a SCIF_CNCT_GNT(N)ACK. If the allocation fails then
+ * the node sends a SCIF_CNCT_REJ message
+ * 5) Upon receipt of a SCIF_CNCT_GNT or a SCIF_CNCT_REJ message the
+ * connecting endpoint is woken up as part of handling
+ * scif_cnctgnt_resp(..) following which it maps the remote endpoints'
+ * QP, updates its outbound QP and sends a SCIF_CNCT_GNTACK message on
+ * success or a SCIF_CNCT_GNTNACK message on failure and completes
+ * the scif_connect(..) API
+ * 6) Upon receipt of a SCIF_CNCT_GNT(N)ACK the accepting endpoint blocked
+ * in step 4 is woken up and completes the scif_accept(..) API
+ * 7) The SCIF connection is now established between the two SCIF endpoints.
+ */
+static int scif_conn_func(struct scif_endpt *ep)
+{
+   int err = 0;
+   struct scifmsg msg;
+   struct device *spdev;
+
+   /* Initiate the first part of the endpoint QP setup */
+   err = scif_setup_qp_connect(ep->qp_info.qp, >qp_info.qp_offset,
+   SCIF_ENDPT_QP_SIZE, ep->remote_dev);
+   if (err) {
+   dev_err(>remote_dev->sdev->dev,
+   "%s err %d qp_offset 0x%llx\n",
+   __func__, err, ep->qp_info.qp_offset);
+   ep->state = SCIFEP_BOUND;
+   goto connect_error_simple;
+   }
+
+   spdev = scif_get_peer_dev(ep->remote_dev);
+   if (IS_ERR(spdev)) {
+   err = PTR_ERR(spdev);
+   goto cleanup_qp;
+   }
+   /* Format connect message and send it */
+   msg.src = ep->port;
+   

[PATCH char-misc-next v4 08/13] misc: mic: SCIF open close bind and listen APIs

2015-03-30 Thread Sudeep Dutt
SCIF character device file operations and kernel APIs for opening and
closing a user and kernel mode SCIF endpoint. This patch also enables
binding to a SCIF port and listening for incoming SCIF connections.

Reviewed-by: Nikhil Rao 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/Kconfig|  19 ++
 drivers/misc/mic/Makefile   |   1 +
 drivers/misc/mic/scif/Makefile  |  15 ++
 drivers/misc/mic/scif/scif_epd.h| 148 +
 drivers/misc/mic/scif/scif_main.h   |   2 +
 drivers/misc/mic/scif/scif_nodeqp.h |  12 +-
 drivers/misc/mic/scif/scif_api.c| 417 
 drivers/misc/mic/scif/scif_epd.c|  92 
 drivers/misc/mic/scif/scif_fd.c | 104 +
 drivers/misc/mic/scif/scif_ports.c  | 124 +++
 10 files changed, 933 insertions(+), 1 deletion(-)
 create mode 100644 drivers/misc/mic/scif/Makefile
 create mode 100644 drivers/misc/mic/scif/scif_epd.h
 create mode 100644 drivers/misc/mic/scif/scif_api.c
 create mode 100644 drivers/misc/mic/scif/scif_epd.c
 create mode 100644 drivers/misc/mic/scif/scif_fd.c
 create mode 100644 drivers/misc/mic/scif/scif_ports.c

diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig
index afc9f53..bcf6e36 100644
--- a/drivers/misc/mic/Kconfig
+++ b/drivers/misc/mic/Kconfig
@@ -69,3 +69,22 @@ config INTEL_MIC_CARD
 
  For more information see
  .
+
+comment "SCIF Driver"
+
+config SCIF
+   tristate "SCIF Driver"
+   depends on 64BIT && PCI && X86 && SCIF_BUS
+   help
+ This enables SCIF Driver support for the Intel Many Integrated
+ Core (MIC) family of PCIe form factor coprocessor devices that
+ run a 64 bit Linux OS. The Symmetric Communication Interface
+ (SCIF (pronounced as skiff)) is a low level communications API
+ across PCIe currently implemented for MIC.
+
+ If you are building a host kernel with an Intel MIC device then
+ say M (recommended) or Y, else say N. If unsure say N.
+
+ More information about the Intel MIC family as well as the Linux
+ OS and tools for MIC to use with this driver are available from
+ .
diff --git a/drivers/misc/mic/Makefile b/drivers/misc/mic/Makefile
index 6bc6083..a74042c 100644
--- a/drivers/misc/mic/Makefile
+++ b/drivers/misc/mic/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_INTEL_MIC_HOST) += host/
 obj-$(CONFIG_INTEL_MIC_CARD) += card/
 obj-y += bus/
+obj-$(CONFIG_SCIF) += scif/
diff --git a/drivers/misc/mic/scif/Makefile b/drivers/misc/mic/scif/Makefile
new file mode 100644
index 000..bf10bb7
--- /dev/null
+++ b/drivers/misc/mic/scif/Makefile
@@ -0,0 +1,15 @@
+#
+# Makefile - SCIF driver.
+# Copyright(c) 2014, Intel Corporation.
+#
+obj-$(CONFIG_SCIF) += scif.o
+scif-objs := scif_main.o
+scif-objs += scif_peer_bus.o
+scif-objs += scif_ports.o
+scif-objs += scif_debugfs.o
+scif-objs += scif_fd.o
+scif-objs += scif_api.o
+scif-objs += scif_epd.o
+scif-objs += scif_rb.o
+scif-objs += scif_nodeqp.o
+scif-objs += scif_nm.o
diff --git a/drivers/misc/mic/scif/scif_epd.h b/drivers/misc/mic/scif/scif_epd.h
new file mode 100644
index 000..b973b99
--- /dev/null
+++ b/drivers/misc/mic/scif/scif_epd.h
@@ -0,0 +1,148 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2014 Intel Corporation.
+ *
+ * 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.
+ *
+ * Intel SCIF driver.
+ *
+ */
+#ifndef SCIF_EPD_H
+#define SCIF_EPD_H
+
+#include 
+#include 
+#include 
+
+#define SCIF_EPLOCK_HELD true
+
+enum scif_epd_state {
+   SCIFEP_UNBOUND,
+   SCIFEP_BOUND,
+   SCIFEP_LISTENING,
+   SCIFEP_CONNECTED,
+   SCIFEP_CONNECTING,
+   SCIFEP_MAPPING,
+   SCIFEP_CLOSING,
+   SCIFEP_CLLISTEN,
+   SCIFEP_DISCONNECTED,
+   SCIFEP_ZOMBIE
+};
+
+/*
+ * struct scif_conreq - Data structure added to the connection list.
+ *
+ * @msg: connection request message received
+ * @list: link to list of connection requests
+ */
+struct scif_conreq {
+   struct scifmsg msg;
+   struct list_head list;
+};
+
+/* Size of the RB for the Endpoint QP */
+#define SCIF_ENDPT_QP_SIZE 0x1000
+
+/*
+ * scif_endpt_qp_info - SCIF endpoint queue pair
+ *
+ * @qp - Qpair for this endpoint
+ * @qp_offset - DMA address of the QP
+ * @gnt_pld - Payload in a SCIF_CNCT_GNT message containing the
+ * physical address of the remote_qp.
+ */
+struct scif_endpt_qp_info {
+   struct scif_qp *qp;
+   dma_addr_t qp_offset;

[PATCH char-misc-next v4 12/13] misc: mic: MIC card driver specific changes to enable SCIF

2015-03-30 Thread Sudeep Dutt
MIC card driver specific changes to enable SCIF. This patch implements
the SCIF hardware bus operations and registers a SCIF device on the
SCIF hardware bus.

Reviewed-by: Nikhil Rao 
Signed-off-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/Kconfig   |   2 +-
 drivers/misc/mic/card/mic_device.h |  11 +++-
 drivers/misc/mic/card/mic_x100.h   |   1 +
 drivers/misc/mic/card/mic_device.c | 132 -
 drivers/misc/mic/card/mic_x100.c   |  61 -
 5 files changed, 201 insertions(+), 6 deletions(-)

diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig
index a2ea3ab..e9f2f56 100644
--- a/drivers/misc/mic/Kconfig
+++ b/drivers/misc/mic/Kconfig
@@ -56,7 +56,7 @@ comment "Intel MIC Card Driver"
 
 config INTEL_MIC_CARD
tristate "Intel MIC Card Driver"
-   depends on 64BIT && X86 && INTEL_MIC_BUS
+   depends on 64BIT && X86 && INTEL_MIC_BUS && SCIF_BUS
select VIRTIO
help
  This enables card driver support for the Intel Many Integrated
diff --git a/drivers/misc/mic/card/mic_device.h 
b/drivers/misc/mic/card/mic_device.h
index 844be8f..1dbf83c 100644
--- a/drivers/misc/mic/card/mic_device.h
+++ b/drivers/misc/mic/card/mic_device.h
@@ -29,9 +29,9 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
+#include "../bus/scif_bus.h"
 
 /**
  * struct mic_intr_info - Contains h/w specific interrupt sources info
@@ -73,6 +73,9 @@ struct mic_device {
  * @irq_info: The OS specific irq information
  * @intr_info: H/W specific interrupt information.
  * @dma_mbdev: dma device on the MIC virtual bus.
+ * @dma_ch - Array of DMA channels
+ * @num_dma_ch - Number of DMA channels available
+ * @scdev: SCIF device on the SCIF virtual bus.
  */
 struct mic_driver {
char name[20];
@@ -84,6 +87,9 @@ struct mic_driver {
struct mic_irq_info irq_info;
struct mic_intr_info intr_info;
struct mbus_device *dma_mbdev;
+   struct dma_chan *dma_ch[MIC_MAX_DMA_CHAN];
+   int num_dma_ch;
+   struct scif_hw_dev *scdev;
 };
 
 /**
@@ -122,10 +128,11 @@ void mic_driver_uninit(struct mic_driver *mdrv);
 int mic_next_card_db(void);
 struct mic_irq *
 mic_request_card_irq(irq_handler_t handler, irq_handler_t thread_fn,
-const char *name, void *data, int intr_src);
+const char *name, void *data, int db);
 void mic_free_card_irq(struct mic_irq *cookie, void *data);
 u32 mic_read_spad(struct mic_device *mdev, unsigned int idx);
 void mic_send_intr(struct mic_device *mdev, int doorbell);
+void mic_send_p2p_intr(int doorbell, struct mic_mw *mw);
 int mic_db_to_irq(struct mic_driver *mdrv, int db);
 u32 mic_ack_interrupt(struct mic_device *mdev);
 void mic_hw_intr_init(struct mic_driver *mdrv);
diff --git a/drivers/misc/mic/card/mic_x100.h b/drivers/misc/mic/card/mic_x100.h
index d66ea55..7e22249 100644
--- a/drivers/misc/mic/card/mic_x100.h
+++ b/drivers/misc/mic/card/mic_x100.h
@@ -35,6 +35,7 @@
 #define MIC_X100_SBOX_SDBIC0 0xCC90
 #define MIC_X100_SBOX_SDBIC0_DBREQ_BIT 0x8000
 #define MIC_X100_SBOX_RDMASR0  0xB180
+#define MIC_X100_SBOX_APICICR0 0xA9D0
 
 #define MIC_X100_MAX_DOORBELL_IDX 8
 
diff --git a/drivers/misc/mic/card/mic_device.c 
b/drivers/misc/mic/card/mic_device.c
index 83819ee..6338908 100644
--- a/drivers/misc/mic/card/mic_device.c
+++ b/drivers/misc/mic/card/mic_device.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include "../common/mic_dev.h"
@@ -240,6 +242,111 @@ static void mic_uninit_irq(void)
kfree(mdrv->irq_info.irq_usage_count);
 }
 
+static inline struct mic_driver *scdev_to_mdrv(struct scif_hw_dev *scdev)
+{
+   return dev_get_drvdata(scdev->dev.parent);
+}
+
+static struct mic_irq *
+___mic_request_irq(struct scif_hw_dev *scdev,
+  irqreturn_t (*func)(int irq, void *data),
+  const char *name, void *data,
+  int db)
+{
+   return mic_request_card_irq(func, NULL, name, data, db);
+}
+
+static void
+___mic_free_irq(struct scif_hw_dev *scdev,
+   struct mic_irq *cookie, void *data)
+{
+   return mic_free_card_irq(cookie, data);
+}
+
+static void ___mic_ack_interrupt(struct scif_hw_dev *scdev, int num)
+{
+   struct mic_driver *mdrv = scdev_to_mdrv(scdev);
+
+   mic_ack_interrupt(>mdev);
+}
+
+static int ___mic_next_db(struct scif_hw_dev *scdev)
+{
+   return mic_next_card_db();
+}
+
+static void ___mic_send_intr(struct scif_hw_dev *scdev, int db)
+{
+   struct mic_driver *mdrv = scdev_to_mdrv(scdev);
+
+   mic_send_intr(>mdev, db);
+}
+
+static void ___mic_send_p2p_intr(struct scif_hw_dev *scdev, int db,
+struct mic_mw *mw)
+{
+   mic_send_p2p_intr(db, mw);
+}
+
+static void __iomem *
+___mic_ioremap(struct scif_hw_dev *scdev,
+  phys_addr_t pa, size_t len)
+{
+   struct 

[PATCH char-misc-next v4 05/13] misc: mic: Common MIC header file changes in preparation for SCIF

2015-03-30 Thread Sudeep Dutt
Update mic_bootparam and define the maximum number of DMA channels

Reviewed-by: Nikhil Rao 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/common/mic_dev.h |  3 +++
 include/uapi/linux/mic_common.h   | 12 
 2 files changed, 15 insertions(+)

diff --git a/drivers/misc/mic/common/mic_dev.h 
b/drivers/misc/mic/common/mic_dev.h
index 92999c2..0b58c46 100644
--- a/drivers/misc/mic/common/mic_dev.h
+++ b/drivers/misc/mic/common/mic_dev.h
@@ -48,4 +48,7 @@ struct mic_mw {
 #define MIC_VIRTIO_PARAM_DEV_REMOVE 0x1
 #define MIC_VIRTIO_PARAM_CONFIG_CHANGED 0x2
 
+/* Maximum number of DMA channels */
+#define MIC_MAX_DMA_CHAN 4
+
 #endif
diff --git a/include/uapi/linux/mic_common.h b/include/uapi/linux/mic_common.h
index 6eb4024..302a2ce 100644
--- a/include/uapi/linux/mic_common.h
+++ b/include/uapi/linux/mic_common.h
@@ -80,6 +80,12 @@ struct mic_device_ctrl {
  * @h2c_config_db: Host to Card Virtio config doorbell set by card
  * @shutdown_status: Card shutdown status set by card
  * @shutdown_card: Set to 1 by the host when a card shutdown is initiated
+ * @tot_nodes: Total number of nodes in the SCIF network
+ * @node_id: Unique id of the node
+ * @h2c_scif_db - Host to card SCIF doorbell set by card
+ * @c2h_scif_db - Card to host SCIF doorbell set by host
+ * @scif_host_dma_addr - SCIF host queue pair DMA address
+ * @scif_card_dma_addr - SCIF card queue pair DMA address
  */
 struct mic_bootparam {
__le32 magic;
@@ -88,6 +94,12 @@ struct mic_bootparam {
__s8 h2c_config_db;
__u8 shutdown_status;
__u8 shutdown_card;
+   __u8 tot_nodes;
+   __u8 node_id;
+   __u8 h2c_scif_db;
+   __u8 c2h_scif_db;
+   __u64 scif_host_dma_addr;
+   __u64 scif_card_dma_addr;
 } __attribute__ ((aligned(8)));
 
 /**
-- 
1.8.2.1

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


[PATCH char-misc-next v4 10/13] misc: mic: SCIF messaging and node enumeration APIs

2015-03-30 Thread Sudeep Dutt
SCIF messaging APIs which allow sending messages between the SCIF
endpoints via a byte stream based ring buffer which has been
optimized to avoid reads across PCIe. The SCIF messaging APIs
are typically used for short < 1024 byte messages for best
performance while the RDMA APIs which will be submitted in a future
patch series is recommended for larger transfers. The node
enumeration API enables a user to query for the number of nodes
online in the SCIF network and their node ids.

Reviewed-by: Ashutosh Dixit 
Signed-off-by: Nikhil Rao 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/scif/scif_epd.h|   4 +
 drivers/misc/mic/scif/scif_api.c| 402 
 drivers/misc/mic/scif/scif_epd.c|  32 +++
 drivers/misc/mic/scif/scif_fd.c |  93 +
 drivers/misc/mic/scif/scif_nm.c |  17 ++
 drivers/misc/mic/scif/scif_nodeqp.c |  36 +++-
 6 files changed, 583 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mic/scif/scif_epd.h b/drivers/misc/mic/scif/scif_epd.h
index 65c628e..331322a 100644
--- a/drivers/misc/mic/scif/scif_epd.h
+++ b/drivers/misc/mic/scif/scif_epd.h
@@ -144,6 +144,8 @@ int scif_rsrv_port(u16 port);
 void scif_get_port(u16 port);
 int scif_get_new_port(void);
 void scif_put_port(u16 port);
+int scif_user_send(scif_epd_t epd, void __user *msg, int len, int flags);
+int scif_user_recv(scif_epd_t epd, void __user *msg, int len, int flags);
 void scif_cnctreq(struct scif_dev *scifdev, struct scifmsg *msg);
 void scif_cnctgnt(struct scif_dev *scifdev, struct scifmsg *msg);
 void scif_cnctgnt_ack(struct scif_dev *scifdev, struct scifmsg *msg);
@@ -151,6 +153,8 @@ void scif_cnctgnt_nack(struct scif_dev *scifdev, struct 
scifmsg *msg);
 void scif_cnctrej(struct scif_dev *scifdev, struct scifmsg *msg);
 void scif_discnct(struct scif_dev *scifdev, struct scifmsg *msg);
 void scif_discnt_ack(struct scif_dev *scifdev, struct scifmsg *msg);
+void scif_clientsend(struct scif_dev *scifdev, struct scifmsg *msg);
+void scif_clientrcvd(struct scif_dev *scifdev, struct scifmsg *msg);
 int __scif_connect(scif_epd_t epd, struct scif_port_id *dst, bool non_block);
 int __scif_flush(scif_epd_t epd);
 #endif /* SCIF_EPD_H */
diff --git a/drivers/misc/mic/scif/scif_api.c b/drivers/misc/mic/scif/scif_api.c
index da64cee..f39d313 100644
--- a/drivers/misc/mic/scif/scif_api.c
+++ b/drivers/misc/mic/scif/scif_api.c
@@ -872,3 +872,405 @@ scif_accept_error_epalloc:
return err;
 }
 EXPORT_SYMBOL_GPL(scif_accept);
+
+/*
+ * scif_msg_param_check:
+ * @epd: The end point returned from scif_open()
+ * @len: Length to receive
+ * @flags: blocking or non blocking
+ *
+ * Validate parameters for messaging APIs scif_send(..)/scif_recv(..).
+ */
+static inline int scif_msg_param_check(scif_epd_t epd, int len, int flags)
+{
+   int ret = -EINVAL;
+
+   if (len < 0)
+   goto err_ret;
+   if (flags && (!(flags & SCIF_RECV_BLOCK)))
+   goto err_ret;
+   ret = 0;
+err_ret:
+   return ret;
+}
+
+static int _scif_send(scif_epd_t epd, void *msg, int len, int flags)
+{
+   struct scif_endpt *ep = (struct scif_endpt *)epd;
+   struct scifmsg notif_msg;
+   int curr_xfer_len = 0, sent_len = 0, write_count;
+   int ret = 0;
+   struct scif_qp *qp = ep->qp_info.qp;
+
+   if (flags & SCIF_SEND_BLOCK)
+   might_sleep();
+
+   spin_lock(>lock);
+   while (sent_len != len && SCIFEP_CONNECTED == ep->state) {
+   write_count = scif_rb_space(>outbound_q);
+   if (write_count) {
+   /* Best effort to send as much data as possible */
+   curr_xfer_len = min(len - sent_len, write_count);
+   ret = scif_rb_write(>outbound_q, msg,
+   curr_xfer_len);
+   if (ret < 0)
+   break;
+   /* Success. Update write pointer */
+   scif_rb_commit(>outbound_q);
+   /*
+* Send a notification to the peer about the
+* produced data message.
+*/
+   notif_msg.src = ep->port;
+   notif_msg.uop = SCIF_CLIENT_SENT;
+   notif_msg.payload[0] = ep->remote_ep;
+   ret = _scif_nodeqp_send(ep->remote_dev, _msg);
+   if (ret)
+   break;
+   sent_len += curr_xfer_len;
+   msg = msg + curr_xfer_len;
+   continue;
+   }
+   curr_xfer_len = min(len - sent_len, SCIF_ENDPT_QP_SIZE - 1);
+   /* Not enough RB space. return for the Non Blocking case */
+   if (!(flags & SCIF_SEND_BLOCK))
+   break;
+
+   spin_unlock(>lock);
+   /* Wait for a SCIF_CLIENT_RCVD message in 

[PATCH char-misc-next v4 13/13] misc: mic: add support for loading/unloading SCIF driver

2015-03-30 Thread Sudeep Dutt
modprobe SCIF driver upon start and remove it upon unload

Reviewed-by: Nikhil Rao 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 Documentation/mic/mpssd/mpss | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/Documentation/mic/mpssd/mpss b/Documentation/mic/mpssd/mpss
index cacbdb0..582aad4 100755
--- a/Documentation/mic/mpssd/mpss
+++ b/Documentation/mic/mpssd/mpss
@@ -35,6 +35,7 @@
 
 exec=/usr/sbin/mpssd
 sysfs="/sys/class/mic"
+mic_modules="mic_host mic_x100_dma scif"
 
 start()
 {
@@ -48,18 +49,15 @@ start()
fi
 
echo -e $"Starting MPSS Stack"
-   echo -e $"Loading MIC_X100_DMA & MIC_HOST Modules"
+   echo -e $"Loading MIC drivers:" $mic_modules
 
-   for f in "mic_host" "mic_x100_dma"
-   do
-   modprobe $f
-   RETVAL=$?
-   if [ $RETVAL -ne 0 ]; then
-   failure
-   echo
-   return $RETVAL
-   fi
-   done
+   modprobe -a $mic_modules
+   RETVAL=$?
+   if [ $RETVAL -ne 0 ]; then
+   failure
+   echo
+   return $RETVAL
+   fi
 
# Start the daemon
echo -n $"Starting MPSSD "
@@ -170,8 +168,8 @@ unload()
stop
 
sleep 5
-   echo -n $"Removing MIC_HOST & MIC_X100_DMA Modules: "
-   modprobe -r mic_host mic_x100_dma
+   echo -n $"Removing MIC drivers:" $mic_modules
+   modprobe -r $mic_modules
RETVAL=$?
[ $RETVAL -ne 0 ] && failure || success
echo
-- 
1.8.2.1

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


[PATCH char-misc-next v4 11/13] misc: mic: MIC host driver specific changes to enable SCIF

2015-03-30 Thread Sudeep Dutt
MIC host driver specific changes to enable SCIF. This patch implements
the SCIF hardware bus operations and registers a SCIF device on the
SCIF hardware bus.

Reviewed-by: Nikhil Rao 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/Kconfig|   2 +-
 drivers/misc/mic/host/mic_device.h  |  11 +-
 drivers/misc/mic/host/mic_intr.h|   3 +-
 drivers/misc/mic/host/mic_smpt.h|   1 +
 drivers/misc/mic/host/mic_boot.c| 264 ++--
 drivers/misc/mic/host/mic_debugfs.c |  13 ++
 drivers/misc/mic/host/mic_main.c|   6 +
 drivers/misc/mic/host/mic_smpt.c|   7 +-
 drivers/misc/mic/host/mic_virtio.c  |   6 +-
 drivers/misc/mic/host/mic_x100.c|   3 +-
 10 files changed, 292 insertions(+), 24 deletions(-)

diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig
index bcf6e36..a2ea3ab 100644
--- a/drivers/misc/mic/Kconfig
+++ b/drivers/misc/mic/Kconfig
@@ -36,7 +36,7 @@ comment "Intel MIC Host Driver"
 
 config INTEL_MIC_HOST
tristate "Intel MIC Host Driver"
-   depends on 64BIT && PCI && X86 && INTEL_MIC_BUS
+   depends on 64BIT && PCI && X86 && INTEL_MIC_BUS && SCIF_BUS
select VHOST_RING
help
  This enables Host Driver support for the Intel Many Integrated
diff --git a/drivers/misc/mic/host/mic_device.h 
b/drivers/misc/mic/host/mic_device.h
index 016bd15..01a7555 100644
--- a/drivers/misc/mic/host/mic_device.h
+++ b/drivers/misc/mic/host/mic_device.h
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-
+#include "../bus/scif_bus.h"
 #include "mic_intr.h"
 
 /* The maximum number of MIC devices supported in a single host system. */
@@ -90,7 +90,9 @@ enum mic_stepping {
  * @vdev_list: list of virtio devices.
  * @pm_notifier: Handles PM notifications from the OS.
  * @dma_mbdev: MIC BUS DMA device.
- * @dma_ch: DMA channel reserved by this driver for use by virtio devices.
+ * @dma_ch - Array of DMA channels
+ * @num_dma_ch - Number of DMA channels available
+ * @scdev: SCIF device on the SCIF virtual bus.
  */
 struct mic_device {
struct mic_mw mmio;
@@ -129,7 +131,9 @@ struct mic_device {
struct list_head vdev_list;
struct notifier_block pm_notifier;
struct mbus_device *dma_mbdev;
-   struct dma_chan *dma_ch;
+   struct dma_chan *dma_ch[MIC_MAX_DMA_CHAN];
+   int num_dma_ch;
+   struct scif_hw_dev *scdev;
 };
 
 /**
@@ -228,4 +232,5 @@ void mic_exit_debugfs(void);
 void mic_prepare_suspend(struct mic_device *mdev);
 void mic_complete_resume(struct mic_device *mdev);
 void mic_suspend(struct mic_device *mdev);
+extern atomic_t g_num_mics;
 #endif
diff --git a/drivers/misc/mic/host/mic_intr.h b/drivers/misc/mic/host/mic_intr.h
index 9f783d4a..cce2882 100644
--- a/drivers/misc/mic/host/mic_intr.h
+++ b/drivers/misc/mic/host/mic_intr.h
@@ -28,8 +28,9 @@
  * 3 for virtio network, console and block devices.
  * 1 for card shutdown notifications.
  * 4 for host owned DMA channels.
+ * 1 for SCIF
  */
-#define MIC_MIN_MSIX 8
+#define MIC_MIN_MSIX 9
 #define MIC_NUM_OFFSETS 32
 
 /**
diff --git a/drivers/misc/mic/host/mic_smpt.h b/drivers/misc/mic/host/mic_smpt.h
index 51970ab..68721c6 100644
--- a/drivers/misc/mic/host/mic_smpt.h
+++ b/drivers/misc/mic/host/mic_smpt.h
@@ -78,6 +78,7 @@ void mic_unmap_single(struct mic_device *mdev,
 dma_addr_t mic_map(struct mic_device *mdev,
dma_addr_t dma_addr, size_t size);
 void mic_unmap(struct mic_device *mdev, dma_addr_t mic_addr, size_t size);
+dma_addr_t mic_to_dma_addr(struct mic_device *mdev, dma_addr_t mic_addr);
 
 /**
  * mic_map_error - Check a MIC address for errors.
diff --git a/drivers/misc/mic/host/mic_boot.c b/drivers/misc/mic/host/mic_boot.c
index ff2b0fb..bb15506 100644
--- a/drivers/misc/mic/host/mic_boot.c
+++ b/drivers/misc/mic/host/mic_boot.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -29,6 +30,188 @@
 #include "mic_smpt.h"
 #include "mic_virtio.h"
 
+static inline struct mic_device *scdev_to_mdev(struct scif_hw_dev *scdev)
+{
+   return dev_get_drvdata(scdev->dev.parent);
+}
+
+static void *__mic_dma_alloc(struct device *dev, size_t size,
+dma_addr_t *dma_handle, gfp_t gfp,
+struct dma_attrs *attrs)
+{
+   struct scif_hw_dev *scdev = dev_get_drvdata(dev);
+   struct mic_device *mdev = scdev_to_mdev(scdev);
+   dma_addr_t tmp;
+   void *va = kmalloc(size, gfp);
+
+   if (va) {
+   tmp = mic_map_single(mdev, va, size);
+   if (dma_mapping_error(dev, tmp)) {
+   kfree(va);
+   va = NULL;
+   } else {
+   *dma_handle = tmp;
+   }
+   }
+   return va;
+}
+
+static void __mic_dma_free(struct device *dev, size_t size, void *vaddr,
+  dma_addr_t dma_handle, struct dma_attrs *attrs)
+{
+   struct scif_hw_dev *scdev = 

[PATCH char-misc-next v4 06/13] misc: mic: SCIF module initialization

2015-03-30 Thread Sudeep Dutt
SCIF module initialization, DMA mapping, ioremap wrapper APIs
and debugfs hooks. SCIF gets probed by the SCIF hardware bus
if SCIF devices were registered by base drivers. A MISC device
is registered to provide the SCIF character device interface.

Reviewed-by: Nikhil Rao 
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Sudeep Dutt 
---
 drivers/misc/mic/scif/scif_main.h| 252 ++
 drivers/misc/mic/scif/scif_map.h | 113 ++
 drivers/misc/mic/scif/scif_debugfs.c |  85 
 drivers/misc/mic/scif/scif_main.c| 391 +++
 4 files changed, 841 insertions(+)
 create mode 100644 drivers/misc/mic/scif/scif_main.h
 create mode 100644 drivers/misc/mic/scif/scif_map.h
 create mode 100644 drivers/misc/mic/scif/scif_debugfs.c
 create mode 100644 drivers/misc/mic/scif/scif_main.c

diff --git a/drivers/misc/mic/scif/scif_main.h 
b/drivers/misc/mic/scif/scif_main.h
new file mode 100644
index 000..acd1233
--- /dev/null
+++ b/drivers/misc/mic/scif/scif_main.h
@@ -0,0 +1,252 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2014 Intel Corporation.
+ *
+ * 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.
+ *
+ * Intel SCIF driver.
+ *
+ */
+#ifndef SCIF_MAIN_H
+#define SCIF_MAIN_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../common/mic_dev.h"
+
+#define SCIF_MGMT_NODE 0
+#define SCIF_DEFAULT_WATCHDOG_TO 30
+#define SCIF_NODE_ACCEPT_TIMEOUT (3 * HZ)
+#define SCIF_NODE_ALIVE_TIMEOUT (SCIF_DEFAULT_WATCHDOG_TO * HZ)
+
+/*
+ * Generic state used for certain node QP message exchanges
+ * like Unregister, Alloc etc.
+ */
+enum scif_msg_state {
+   OP_IDLE = 1,
+   OP_IN_PROGRESS,
+   OP_COMPLETED,
+   OP_FAILED
+};
+
+/*
+ * struct scif_info - Global SCIF information
+ *
+ * @nodeid: Node ID this node is to others
+ * @maxid: Max known node ID
+ * @total: Total number of SCIF nodes
+ * @nr_zombies: number of zombie endpoints
+ * @eplock: Lock to synchronize listening, zombie endpoint lists
+ * @connlock: Lock to synchronize connected and disconnected lists
+ * @nb_connect_lock: Synchronize non blocking connect operations
+ * @port_lock: Synchronize access to SCIF ports
+ * @uaccept: List of user acceptreq waiting for acceptreg
+ * @listen: List of listening end points
+ * @zombie: List of zombie end points with pending RMA's
+ * @connected: List of end points in connected state
+ * @disconnected: List of end points in disconnected state
+ * @nb_connect_list: List for non blocking connections
+ * @misc_work: miscellaneous SCIF tasks
+ * @conflock: Lock to synchronize SCIF node configuration changes
+ * @en_msg_log: Enable debug message logging
+ * @p2p_enable: Enable P2P SCIF network
+ * @mdev: The MISC device
+ * @conn_work: Work for workqueue handling all connections
+ * @exitwq: Wait queue for waiting for an EXIT node QP message response
+ * @loopb_dev: Dummy SCIF device used for loopback
+ * @loopb_wq: Workqueue used for handling loopback messages
+ * @loopb_wqname[16]: Name of loopback workqueue
+ * @loopb_work: Used for submitting work to loopb_wq
+ * @loopb_recv_q: List of messages received on the loopb_wq
+ * @card_initiated_exit: set when the card has initiated the exit
+ */
+struct scif_info {
+   u8 nodeid;
+   u8 maxid;
+   u8 total;
+   u32 nr_zombies;
+   spinlock_t eplock;
+   struct mutex connlock;
+   spinlock_t nb_connect_lock;
+   spinlock_t port_lock;
+   struct list_head uaccept;
+   struct list_head listen;
+   struct list_head zombie;
+   struct list_head connected;
+   struct list_head disconnected;
+   struct list_head nb_connect_list;
+   struct work_struct misc_work;
+   struct mutex conflock;
+   u8 en_msg_log;
+   u8 p2p_enable;
+   struct miscdevice mdev;
+   struct work_struct conn_work;
+   wait_queue_head_t exitwq;
+   struct scif_dev *loopb_dev;
+   struct workqueue_struct *loopb_wq;
+   char loopb_wqname[16];
+   struct work_struct loopb_work;
+   struct list_head loopb_recv_q;
+   bool card_initiated_exit;
+};
+
+/*
+ * struct scif_p2p_info - SCIF mapping information used for P2P
+ *
+ * @ppi_peer_id - SCIF peer node id
+ * @ppi_sg - Scatter list for bar information (One for mmio and one for aper)
+ * @sg_nentries - Number of entries in the scatterlist
+ * @ppi_da: DMA address for MMIO and APER bars
+ * @ppi_len: Length of MMIO and APER bars
+ * @ppi_list: Link in list of mapping information
+ */
+struct scif_p2p_info {
+   u8 ppi_peer_id;
+   struct 

[PATCH char-misc-next v4 00/13] misc: mic: SCIF driver

2015-03-30 Thread Sudeep Dutt
ChangeLog:
=

v3 => v4:
a) Delete unused IOCTL definitions and IOCTL interface fixes as per
feedback from Greg Kroah-Hartman
b) Couple of tiny bug fixes since v3

v2 => v3 @ https://lkml.org/lkml/2015/1/26/849
a) Formatting fixes for SCIF header file documentation, data type fixes
   for SCIF IOCTL interface and added SCIF user space documentation in
   scif_overview.txt as per feedback from Greg Kroah-Hartman

v1 => v2 @ https://lkml.org/lkml/2015/1/12/1029
a) Use kernel-doc formatting for SCIF header file documentation, enhance
   SCIF ring buffer documentation and formatting cleanup in patch 4 as
   per feedback from Greg Kroah-Hartman
b) SCIF bug fixes and cleanups since initial post

v1: Initial post @ https://lkml.org/lkml/2014/12/10/546

Description:


The Symmetric Communication Interface (SCIF (pronounced as skiff)) is a low
level communications API across PCIe currently implemented for MIC. Currently
SCIF provides inter-node communication within a single host platform, where a
node is a MIC Coprocessor or Xeon based host. SCIF abstracts the details of
communicating over the PCIe bus while providing an API that is symmetric
across all the nodes in the PCIe network. An important design objective for SCIF
is to deliver the maximum possible performance given the communication
abilities of the hardware. SCIF has been used to implement an offload compiler
runtime and OFED support for MPI implementations for MIC coprocessors.

 SCIF API Components 
The SCIF API has the following parts:
1. Connection establishment using a client server model
2. Byte stream messaging intended for short messages
3. Node enumeration to determine online nodes
4. Poll semantics for detection of incoming connections and messages
5. Memory registration to pin down pages
6. Remote memory mapping for low latency CPU accesses via mmap
7. Remote DMA (RDMA) for high bandwidth DMA transfers
8. Fence APIs for RDMA synchronization

SCIF exposes the notion of a connection which can be used by peer processes on
nodes in a SCIF PCIe "network" to share memory "windows" and to communicate. A
process in a SCIF node initiates a SCIF connection to a peer process on a
different node via a SCIF "endpoint". SCIF endpoints support messaging APIs
which are similar to connection oriented socket APIs. Connected SCIF endpoints
can also register local memory which is followed by data transfer using either
DMA, CPU copies or remote memory mapping via mmap. SCIF supports both user and
kernel mode clients which are functionally equivalent.

 SCIF Performance for MIC 
DMA bandwidth comparison between the TCP (over ethernet over PCIe) stack versus
SCIF shows the performance advantages of SCIF for HPC applications and runtimes.

 Comparison of TCP and SCIF based BW

  Throughput (GB/sec)
8 + PCIe Bandwidth **
  +TCP ##
7 +** SCIF %%
  |   %%%
6 +   
  | %%
  |   %%%
5 +  %%
  |%%
4 +   %%
  |  %%
3 + %%
  |%
2 +  %%
  | %%
  |%
1 +
  +##
0 +++---+++--+--+-+--+--+-++-+--+-++-+--+-++-+-
  1   10 100  1000   1   10
   Transfer Size (KBytes)

SCIF allows memory sharing via mmap(..) between processes on different PCIe
nodes and thus provides bare-metal PCIe latency. The round trip SCIF mmap
latency from the host to an x100 MIC for an 8 byte message is 0.44 usecs.

For more information on SCIF please refer to the Linux Con 2013 slides titled
"Intel® MIC x100 Coprocessor Driver - on the Frontiers of Linux & HPC" at
http://events.linuxfoundation.org/sites/events/files/slides/LinuxConMicDriver.pdf
The talk can also be viewed at https://www.youtube.com/watch?v=dylbmmQs4W0

This initial patch series introduces the SCIF API and implements the SCIF
connection, messaging and node enumeration APIs. SCIF poll, mmap, RDMA and
fence APIs will be submitted in a future patch series once the initial base
patches are accepted upstream.

This patch series is divided into 13 patches as follows:
1) SCIF header file documenting the API along with the IOCTL interface

2) SCIF ring buffer is a single producer, single consumer byte stream ring
   buffer optimized for avoiding reads across the PCIe bus. The ring buffer is
   used to implement a receive queue for SCIF driver messaging between nodes and
   for byte stream messaging between SCIF endpoints. Each SCIF node has a
   receive queue for every other SCIF node, and each connected endpoint has a
   receive queue for messages from its peer. This pair of receive queues is
   referred to as a SCIF queue pair.

3) SCIF 

Re: [PATCH 2/7] clk: Add basic infrastructure for Pistachio clocks

2015-03-30 Thread Michael Turquette
Quoting Andrew Bresticker (2015-03-30 17:15:43)
> On Mon, Mar 30, 2015 at 4:59 PM, Stephen Boyd  wrote:
> > On 02/24/15 19:56, Andrew Bresticker wrote:
> >> +
> >> +void pistachio_clk_force_enable(struct pistachio_clk_provider *p,
> >> + unsigned int *clk_ids, unsigned int num)
> >> +{
> >> + unsigned int i;
> >> + int err;
> >> +
> >> + for (i = 0; i < num; i++) {
> >> + struct clk *clk = p->clk_data.clks[clk_ids[i]];
> >> +
> >> + if (IS_ERR(clk))
> >> + continue;
> >> +
> >> + err = clk_prepare_enable(clk);
> >> + if (err)
> >> + pr_err("Failed to enable clock %s: %d\n",
> >> +__clk_get_name(clk), err);
> >> + }
> >> +}
> >>
> >
> > Is this to workaround some problems in the framework where clocks are
> > turned off? Or is it that these clocks are already on before we boot
> > Linux and we need to make sure the framework knows that?
> 
> It's the former.  These clocks are enabled at POR and may only be
> gated as the final step to entering suspend, so they must remain on at
> runtime.  The issue we were running into was that consumers of these
> critical clocks or their descendants would enable/disable their clocks
> during boot or runtime PM and cause these clocks to get disabled.
> Bumping up the prepare/enable count of these critical clocks seemed
> like the best way to handle this - is there a more preferred way?
> FWIW, this is also how the Tegra and Rockchip drivers handled this
> problem.

Hi Andrew,

Why are your drivers allowed to disable clocks which must not be
disabled? (you mentioned boot and runtime pm)

Is this the case that a critical clock is not directly disabled, but a
parent of that critical clock is and it is gated as a result?

Regards,
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 2/7] clk: Add basic infrastructure for Pistachio clocks

2015-03-30 Thread Andrew Bresticker
On Mon, Mar 30, 2015 at 6:21 PM, Stephen Boyd  wrote:
> On 03/30/15 17:15, Andrew Bresticker wrote:
>> On Mon, Mar 30, 2015 at 4:59 PM, Stephen Boyd  wrote:
>>> On 02/24/15 19:56, Andrew Bresticker wrote:
 +
 +void pistachio_clk_force_enable(struct pistachio_clk_provider *p,
 + unsigned int *clk_ids, unsigned int num)
 +{
 + unsigned int i;
 + int err;
 +
 + for (i = 0; i < num; i++) {
 + struct clk *clk = p->clk_data.clks[clk_ids[i]];
 +
 + if (IS_ERR(clk))
 + continue;
 +
 + err = clk_prepare_enable(clk);
 + if (err)
 + pr_err("Failed to enable clock %s: %d\n",
 +__clk_get_name(clk), err);
 + }
 +}

>>> Is this to workaround some problems in the framework where clocks are
>>> turned off? Or is it that these clocks are already on before we boot
>>> Linux and we need to make sure the framework knows that?
>> It's the former.  These clocks are enabled at POR and may only be
>> gated as the final step to entering suspend, so they must remain on at
>> runtime.  The issue we were running into was that consumers of these
>> critical clocks or their descendants would enable/disable their clocks
>> during boot or runtime PM and cause these clocks to get disabled.
>> Bumping up the prepare/enable count of these critical clocks seemed
>> like the best way to handle this - is there a more preferred way?
>> FWIW, this is also how the Tegra and Rockchip drivers handled this
>> problem.
>
> Ideally clock providers just provide clocks and don't actually call
> clock consumer APIs. I don't see where these clocks are disabled in this
> series. Is it just because suspend isn't done right now so there isn't a
> place to hook the disable part? I hope that it's a 1:1 relation between
> the clocks that are turned on here and the clocks that are turned off
> during suspend.

Suspend hasn't been hooked up yet and it's still a long ways off.

> I have a slightly similar problem on my hardware. Consider the case
> where the bootloader has left on the display and audio clocks and they
> share a common parent PLL. When the kernel boots up, all it knows is
> that the display clock and audio clock share a common PLL and the rate
> they're running at. If the audio driver probes first, calls clk_enable()
> on the audio clock (almost a no-op except for the fact that we call the
> .enable op when it's already on) and then calls clk_disable() on the
> audio clock when it's done we'll also turn off the shared PLL.
> Unfortunately it's also being used by the display clock for the display
> driver that hasn't probed yet and so the display stops working and it
> may show an artifact or black screen.
>
> Other cases are where certain clocks should never be turned off because
> they're used by some non-linux entity (dram controller for example) and
> we don't have a place to put the clk_prepare_enable() besides in the
> clock driver itself. In these cases, it may be better to tell the
> framework that a clock should always be on. I think this case is what
> Lee Jones is working on here[1].
>
> Do you fall into one of these two cases? It isn't clear to me how
> suspend is special and needs to be dealt with differently. Why wouldn't
> these clocks be always on?

These clocks fall into the latter case in that there's really no good
place to put the clk_prepare_enable() calls, so it looks like I want
to use what Lee is proposing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v10]: clk: Add common clock support for Mediatek MT8135 and MT8173

2015-03-30 Thread Michael Turquette
Quoting Sascha Hauer (2015-03-30 10:40:39)
> The following changes since commit 9eccca0843205f87c00404b663188b88eb248051:
> 
>   Linux 4.0-rc3 (2015-03-08 16:09:09 -0700)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/imx/linux-2.6.git tags/v4.0-clk-mediatek-v10

Hi Sascha et al,

This series looks good to me. I had an incredibly petty nitpick about
some magic numbers, but otherwise this series is good to go and I can
pick it up once those are fixed.

Regards,
Mike

> 
> for you to fetch changes up to 6c36b94751bb2830388c0cc11440f3056db65b6f:
> 
>   dt-bindings: ARM: Mediatek: Document devicetree bindings for clock/reset 
> controllers (2015-03-30 19:37:46 +0200)
> 
> 
> This patchset contains the initial common clock support for Mediatek SoCs.
> Mediatek SoC's clock architecture comprises of various PLLs, dividers, muxes
> and clock gates.
> 
> Changes in v10:
> - polish some commit messages
> 
> Changes in v9:
> - rename 'lock' to 'mt81xx_clk_lock' to get better lockdep output
> 
> Changes in v8:
> - add patch to allow to put parent_name arrays in __initconst
> - put parent_name arrays into __initconst
> 
> Changes in v7:
> - fix duplicate definition/declaration of mtk_register_reset_controller
> - fix pd_reg offset of tvdpll
> - make clk initialization arrays const
> 
> Changes in v6:
> - rework PLL support, only a fraction of original size now
> - Move binding docs to Documentation/devicetree/bindings/arm/mediatek since
>   the units are not really clock specific (they contain reset controllers)
> 
> Changes in v5:
> - Add reset controller support for pericfg/infracfg
> - Use regmap for the gates
> - remove now unnecessary spinlock for the gates
> - Add PMIC wrapper support as of v3
> 
> Changes in v4:
> - Support MT8173 platform.
> - Re-ordered patchset. driver/clk/Makefile in 2nd patch.
> - Extract the common part definition(mtk_gate/mtk_pll/mtk_mux) from
>   clk-mt8135.c/clk-mt8173.c to clk-mtk.c.
> - Refine code. Rmove unnessacary debug information and unsed defines,
>   add prefix "mtk_" for static functions.
> - Remove flag CLK_IGNORE_UNUSED and set flag CLK_SET_RATE_PARENT on
>   gate/mux/fixed-factor.
> - Use spin_lock_irqsave(_ops_lock, flags) instead of mtk_clk_lock.
> - Example above include a node for the clock controller itself, followed
>   by the i2c controller example above.
> 
> Changes in v3:
> - Rebase to 3.19-rc1.
> - Refine code. Remove unneed functions, debug logs and comments, and fine tune
>   error logs.
> 
> Changes in v2:
> - Re-ordered patchset. Fold include/dt-bindings and DT document in 1st patch.
> 
> 
> James Liao (3):
>   clk: mediatek: Add initial common clock support for Mediatek SoCs.
>   clk: mediatek: Add basic clocks for Mediatek MT8135.
>   clk: mediatek: Add basic clocks for Mediatek MT8173.
> 
> Sascha Hauer (3):
>   clk: make strings in parent name arrays const
>   clk: mediatek: Add reset controller support
>   dt-bindings: ARM: Mediatek: Document devicetree bindings for 
> clock/reset controllers
> 
>  .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |  23 +
>  .../bindings/arm/mediatek/mediatek,infracfg.txt|  30 +
>  .../bindings/arm/mediatek/mediatek,pericfg.txt |  30 +
>  .../bindings/arm/mediatek/mediatek,topckgen.txt|  23 +
>  drivers/clk/Makefile   |   1 +
>  drivers/clk/clk-composite.c|   2 +-
>  drivers/clk/clk-mux.c  |   4 +-
>  drivers/clk/mediatek/Makefile  |   4 +
>  drivers/clk/mediatek/clk-gate.c| 137 
>  drivers/clk/mediatek/clk-gate.h|  49 ++
>  drivers/clk/mediatek/clk-mt8135.c  | 640 
>  drivers/clk/mediatek/clk-mt8173.c  | 826 
> +
>  drivers/clk/mediatek/clk-mtk.c | 197 +
>  drivers/clk/mediatek/clk-mtk.h | 165 
>  drivers/clk/mediatek/clk-pll.c | 325 
>  drivers/clk/mediatek/reset.c   |  99 +++
>  include/dt-bindings/clock/mt8135-clk.h | 190 +
>  include/dt-bindings/clock/mt8173-clk.h | 231 ++
>  .../dt-bindings/reset-controller/mt8135-resets.h   |  64 ++
>  .../dt-bindings/reset-controller/mt8173-resets.h   |  63 ++
>  include/linux/clk-provider.h   |   8 +-
>  21 files changed, 3104 insertions(+), 7 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
>  create mode 100644 
> Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
>  create mode 100644 
> Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
>  create mode 100644 
> Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
>  

[PATCH v2] ramoops: make it possible to change mem_type param.

2015-03-30 Thread Wang Long
If we set ramoops.mem_type=1 in command line, the current
code can not change mem_type to 1, because it is assigned
to 0 in function ramoops_register_dummy.

This patch make it possible to change mem_type parameter
in command line.

Signed-off-by: Wang Long 
Acked-by: Tony Lindgren 
---
 fs/pstore/ram.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 44a549b..4449653 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -608,7 +608,7 @@ static void ramoops_register_dummy(void)
 
dummy_data->mem_size = mem_size;
dummy_data->mem_address = mem_address;
-   dummy_data->mem_type = 0;
+   dummy_data->mem_type = mem_type;
dummy_data->record_size = record_size;
dummy_data->console_size = ramoops_console_size;
dummy_data->ftrace_size = ramoops_ftrace_size;
-- 
1.8.3.4

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


Re: [PATCH] mtd: denali: Disable sub-page writes in Denali NAND driver

2015-03-30 Thread Brian Norris
On Wed, Jan 14, 2015 at 09:38:50AM -0600, dingu...@opensource.altera.com wrote:
> From: Graham Moore 
> 
> The Denali Controller IP does not support sub-page writes.
> 
> Signed-off-by: Graham Moore 
> Signed-off-by: Dinh Nguyen 

Pushed to l2-mtd.git. Thanks!

Brian
--
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] mtd: pxa3xx_nand: cleanup wait_for_completion handling

2015-03-30 Thread Brian Norris
On Sun, Feb 01, 2015 at 11:55:37AM -0500, Nicholas Mc Guire wrote:
> return type of wait_for_completion_timeout is unsigned long not int, this
> patch uses the return value of wait_for_completion_timeout in the condition
> directly rather than assigning it to an incorrect type variable.
> 
> The timeout declaration cleanup is just for readability
> 
> Signed-off-by: Nicholas Mc Guire 
> ---
> 
> The variable used for handling the return of wait_for_cmpletion_timeout
> was int but should be unsigned long, where it was not in use for anything
> else and the return value in case of completion (>0) is not used it was
> removed and wait_for_completion_timeout() used directly in the if condition.
> 
> To make the timeout values a bit simpler to read and also handle all of
> the corner cases correctly the declarations are moved to msecs_to_jiffies().
> 
> This patch was only compile tested for pxa3xx_defconfig 
> (implies CONFIG_MTD_NAND_PXA3xx=y)
> 
> Patch is against 3.0.19-rc6 -next-20150130 

Reworked the commit message a bit and pushed to l2-mtd.git.

Brian
--
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: [2/4] powerpc/rcpm: add RCPM driver

2015-03-30 Thread Scott Wood
On Thu, Mar 26, 2015 at 06:18:13PM +0800, chenhui zhao wrote:
> There is a RCPM (Run Control/Power Management) in Freescale QorIQ
> series processors. The device performs tasks associated with device
> run control and power management.
> 
> The driver implements some features: mask/unmask irq, enter/exit low
> power states, freeze time base, etc.
> 
> Signed-off-by: Chenhui Zhao 
> ---
>  Documentation/devicetree/bindings/soc/fsl/rcpm.txt |  23 ++
>  arch/powerpc/include/asm/fsl_guts.h| 105 ++
>  arch/powerpc/include/asm/fsl_pm.h  |  49 +++
>  arch/powerpc/platforms/85xx/Kconfig|   1 +
>  arch/powerpc/sysdev/Kconfig|   5 +
>  arch/powerpc/sysdev/Makefile   |   1 +
>  arch/powerpc/sysdev/fsl_rcpm.c | 353 
> +
>  7 files changed, 537 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/fsl/rcpm.txt
>  create mode 100644 arch/powerpc/include/asm/fsl_pm.h
>  create mode 100644 arch/powerpc/sysdev/fsl_rcpm.c
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt 
> b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> new file mode 100644
> index 000..8c21b6c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> @@ -0,0 +1,23 @@
> +* Run Control and Power Management
> +
> +The RCPM performs all device-level tasks associated with device run control
> +and power management.
> +
> +Required properites:
> +  - reg : Offset and length of the register set of RCPM block.
> +  - compatible : Specifies the compatibility list for the RCPM. The type
> +should be string, such as "fsl,qoriq-rcpm-1.0", "fsl,qoriq-rcpm-2.0".
> +
> +Example:
> +The RCPM node for T4240:
> + rcpm: global-utilities@e2000 {
> + compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
> + reg = <0xe2000 0x1000>;
> + };
> +
> +The RCPM node for P4080:
> + rcpm: global-utilities@e2000 {
> + compatible = "fsl,qoriq-rcpm-1.0";
> + reg = <0xe2000 0x1000>;
> + #sleep-cells = <1>;
> + };

Where is #sleep-cells documented?  It's copy-and-paste from something
that was never finished from many years ago.

> diff --git a/arch/powerpc/include/asm/fsl_pm.h 
> b/arch/powerpc/include/asm/fsl_pm.h
> new file mode 100644
> index 000..bbe6089
> --- /dev/null
> +++ b/arch/powerpc/include/asm/fsl_pm.h
> @@ -0,0 +1,49 @@
> +/*
> + * Support Power Management
> + *
> + * Copyright 2014-2015 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +#ifndef __PPC_FSL_PM_H
> +#define __PPC_FSL_PM_H
> +#ifdef   __KERNEL__

Put a space after #ifdef, not a tab.

> +#define E500_PM_PH10 1
> +#define E500_PM_PH15 2
> +#define E500_PM_PH20 3
> +#define E500_PM_PH30 4
> +#define E500_PM_DOZE E500_PM_PH10
> +#define E500_PM_NAP  E500_PM_PH15
> +
> +#define PLAT_PM_SLEEP20
> +#define PLAT_PM_LPM2030
> +
> +#define FSL_PM_SLEEP (1 << 0)
> +#define FSL_PM_DEEP_SLEEP(1 << 1)
> +
> +struct fsl_pm_ops {
> + /* mask pending interrupts to the RCPM from MPIC */
> + void (*irq_mask)(int cpu);
> + /* unmask pending interrupts to the RCPM from MPIC */
> + void (*irq_unmask)(int cpu);
> + /* place the CPU in the specified state */
> + void (*cpu_enter_state)(int cpu, int state);
> + /* exit the CPU from the specified state */
> + void (*cpu_exit_state)(int cpu, int state);
> + /* place the platform in the sleep state */
> + int (*plat_enter_sleep)(void);
> + /* freeze the time base */
> + void (*freeze_time_base)(int freeze);
> + /* keep the power of IP blocks during sleep/deep sleep */
> + void (*set_ip_power)(int enable, u32 *mask);
> + /* get platform supported power management modes */
> + unsigned int (*get_pm_modes)(void);
> +};

Drop the comments that are basically just a restatement of the function
name.  Where there are comments, it'd be easier to read with a blank line
between a function and the next comment.

s/int enable/bool enable/
s/int freeze/bool freeze/

> +#endif   /* __KERNEL__ */
> +#endif  /* __PPC_FSL_PM_H */

Please be consistent with whitespace.

> + default:
> + pr_err("%s: Unknown cpu PM state (%d)\n", __func__, state);

WARN?

> +static int rcpm_v2_plat_enter_state(int state)
> +{
> + u32 *pmcsr_reg = _v2_regs->powmgtcsr;
> + int ret = 0;
> + int result;
> +
> + switch (state) {
> + case PLAT_PM_LPM20:
> + /* clear previous LPM20 status */
> + setbits32(pmcsr_reg, RCPM_POWMGTCSR_P_LPM20_ST);

How would the bit be set when you enter here, given that you wait for it
to clear when 

Re: [PATCH] ftracetest: Do not use usleep

2015-03-30 Thread Steven Rostedt
On Tue, 31 Mar 2015 02:08:06 +0100
Pádraig Brady  wrote:

> > I'm okay with ping though but worried if some tiny system might lack
> > the ping command..
> 
> I'd use a fallback method like:
> 
>   yield() { sleep .001 || usleep 1 || sleep 1; }
> 
> Then just s/usleep 1/yield/

yield() { ping localhost -c 1 || sleep .001 || usleep 1 || sleep 1; } ;-)


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


  1   2   3   4   5   6   7   8   9   10   >