Re: Time to remove platforms/cell?

[Michael Ellerman]

On Thu, 2015-09-17 at 10:43 +0200, Marc Dietrich wrote:
> Am Donnerstag, 17. September 2015, 15:28:47 schrieb Michael Ellerman:
> > Discuss ...
> 
> as long as Geoff still maintains the ps3 port - why?

Because even if Geoff maintains the ps3 port, there's still a non-zero cost to
us for carrying the Cell code.

To be clear there's more to Cell than just ps3. The platforms/cell code is
mainly about supporting the IBM Cell Blades, as well as spufs, which is also
used on ps3.

See for example commit 74b5037baa20 ("powerpc/mm: Fix pte_pagesize_index()
crash on 4K w/64K hash"):

  
https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?id=74b5037baa2011a2799e2c43adde7d171b072f9e

Which is a fix for crashes we were seeing on non-cell machines, caused by some
obscure code that was added for Cell. It took several of us a few days to track
that one down.

But the main motivation would just be to drop code that no one's using. From
December 2013 until April 2015 the Cell machines (not ps3) were broken in
mainline and no one noticed. I now have automated boot tests to prevent that
happening again, but it makes me think no one is using those machines much
anymore.


You also raise a good point, which is that ps3 is a separate platform, so we
could actually keep that but get rid of platforms/cell. If we did that we'd
need to move spufs out of platforms/cell though.

Looking at the code size:

platforms/ps36 KSLOC
platforms/cell  11 KSLOC
platforms/cell/spufs 7 KSLOC
other cell code  2 KSLOC

So dropping platforms/cell but not ps3 would save us ~6 KSLOC.


Having said all that, this email was mainly a fishing expedition to see if
anyone still cares about Cell support at all. It sounds like you at least are
running mainline kernels on PS3?

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] arch-powerpc: Return false instead of -EFAULT

[Peter Senna Tschudin]

On Thu, Sep 17, 2015 at 11:47 AM, Michael Ellerman  wrote:
> On Thu, 2015-09-17 at 11:18 +0200, Peter Senna Tschudin wrote:
>> Returning a negative value for a boolean function seem to have the
>> undesired effect of returning true. Replace -EINVAL by false in a
>> bool-returning function.
>>
>> The diff of the .s file before and after the change (using cross
>> compilation) starts with:
>>
>> 440,441c440,441
>> < .L43:
>> < li 3,1   # D.25775,
>> ---
>> > .L42:
>> > li 3,0   # D.25775,
>> ...
>>
>> while if -EFAULT is replaced by true, the diff is empty.
>
> Ah, that's rather unfortunate.
>
> Can you post the full asm listing, for all three cases?
Sure, but it would be 3 files of 70kb each. You can download them form:

http://petersenna.com/files/module_64.s.tar.xz

Let me know if this download method doesn't work for you.

module_64.s: Original file.
module_64-patched.s: With my patch
module_64-true.s: Changing -EFAULT by true

files were made with:
$ make arch/powerpc/kernel/module_64.s

using:
gcc-powerpc64-linux-gnu-4.9.2-5.fc21.x86_64

>
> cheers
>
>



-- 
Peter
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Time to remove platforms/cell?

[Michael Ellerman]

On Thu, 2015-09-17 at 11:31 +0200, Arnd Bergmann wrote:
> On Thursday 17 September 2015 10:43:39 Marc Dietrich wrote:
> > Am Donnerstag, 17. September 2015, 15:28:47 schrieb Michael Ellerman:
> > > Discuss ...
> > 
> > as long as Geoff still maintains the ps3 port - why?
> > 
> We already removed celleb a while ago, which was arguably the least
> commonly used one.

Hi Arnd,

Thanks for the input, I probably should have CC'ed you, sorry!

> Within platforms/cell, we have three separate portions that we need
> to look at:
> 
> a) Common ps3/ibm parts: spufs, oprofile
>We should not remove them before we plan to also remove platforms/ps3
>support, which doesn't seem likely in the near term. We can move them
>to platforms/ps3 if we decide to remove the rest.

Right. I wouldn't bet money that the oprofile code still works, but spufs
definitely would have to stay.

> b) Support for IBM blades:
>It is unlikely that there are QS20 blades still around and being used
>at all, but there is very little code specific to them.

Wasn't spider QS20 only? So that would be a bit of code that could go,
including (some of) the io-workarounds code (I think).

>For QS21/QS22, there are probably still a few in existence, but
>I have no idea whether anybody would consider running a 4.x kernel
>on them. There are also some customer-specific Cell machines that
>are vaguely related to QS22 and that are in a similar state.
>I don't mind removing the code, but if anybody is still using it
>on new kernels, we should be prepared to put it back.

Yeah, that's my impression. We obviously still have a QS22, but really we're
only keeping it alive for testing purposes.

Hopefully this email will bring some more folks out of the woodwork.

> c) QPACE. We know who the three users were, and they have upgraded to
>QPACE2 (based on Intel Xeon Phi) this year. Removing this would be
>appreciated as it lets us clean up one of the ugly corners of the
>8250 uart driver.

Ah excellent info.

I had done some googling on QPACE and from the web site there is no suggestion
that it's been shutdown, but I guess that's the nature of web pages, they tend
not to get updated:

  
http://www.fz-juelich.de/ias/jsc/EN/Expertise/Supercomputers/QPACE/QPACE_node.html


So we can probably remove the QPACE code sooner rather than later, unless
someone yells.

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

[Thomas Gleixner]

On Wed, 16 Sep 2015, Steven Rostedt wrote:
> On Wed, 16 Sep 2015 22:01:06 +0200 (CEST)
> Thomas Gleixner  wrote:
> > So now I have to chase down that one:
> > 
> > [0.230210] ftrace: allocating 16560 entries in 49 pages
> > [0.273313] [ cut here ]
> > [0.278048] WARNING: at 
> > /home/tglx/work/kernel/tip/tip/kernel/trace/ftrace.c:1974
> 
> OK, so this is where ftrace converts the mcount to nops.
> 
> Just to be clear, there's nothing in the command line that enables any
> function tracing, is there?

Nothing on the command line.

> > Happens somewhere between the powerpc merge and rc1. System boots up
> > to userspace and then locks hard 

Digging deeper. My assumption that it's a post powerpc merge failure
turned out to be wrong.

Some more data points. I see the above splat with

CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y

It goes away with 

CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=n

But the box still does not get to the login prompt.

CONFIG_FUNCTION_TRACER=n

makes it work again.

It's not observable before the ppc merge, but I can't identify the
culprit by bisection. bisection led into lala land.

Thanks,

tglx
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 09/30] cxlflash: Fix to stop interrupt processing on remove

[David Laight]

From: Linuxppc-dev Matthew R. Ochs
> Sent: 16 September 2015 22:28
> Interrupt processing can run in parallel to a remove operation. This
> can lead to a condition where the interrupt handler is processing with
> memory that has been freed.
> 
> To avoid processing an interrupt while memory may be yanked, check for
> removal while in the interrupt handler. Bail when removal is imminent.

On the face of it this just reduces the size of the window somewhat.

What happens if the interrupt routine reads the flag just before it is set
(so is processing the entry that is being removed) and is then (say)
interrupted by a higher priority interrupt that takes longer to execute than
the remove code?

You've still got an interrupt routine accessing freed memory.

David

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Time to remove platforms/cell?

[Arnd Bergmann]

On Thursday 17 September 2015 20:05:25 Michael Ellerman wrote:
> On Thu, 2015-09-17 at 11:31 +0200, Arnd Bergmann wrote:
> > b) Support for IBM blades:
> >It is unlikely that there are QS20 blades still around and being used
> >at all, but there is very little code specific to them.
> 
> Wasn't spider QS20 only? So that would be a bit of code that could go,
> including (some of) the io-workarounds code (I think).

Spider is also used on PS3, so if anyone is still using that as bare-metal
(hacked) rather than OtherOS mode, it would be needed. Don't know if we
ever supported that upstream though.

> >For QS21/QS22, there are probably still a few in existence, but
> >I have no idea whether anybody would consider running a 4.x kernel
> >on them. There are also some customer-specific Cell machines that
> >are vaguely related to QS22 and that are in a similar state.
> >I don't mind removing the code, but if anybody is still using it
> >on new kernels, we should be prepared to put it back.
> 
> Yeah, that's my impression. We obviously still have a QS22, but really we're
> only keeping it alive for testing purposes.
> 
> Hopefully this email will bring some more folks out of the woodwork.

FWIW, the last data points from Mercury and Fixstars (who were both offering
OEM products based on QS2x) were from 2009. IBM officially stopped selling the
QS22 in January 2012, which is much later than what I remembered as the day
they stopped offering support.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Time to remove platforms/cell?

[Marc Dietrich]

Am Donnerstag, 17. September 2015, 19:45:38 schrieb Michael Ellerman:
> On Thu, 2015-09-17 at 10:43 +0200, Marc Dietrich wrote:
> > Am Donnerstag, 17. September 2015, 15:28:47 schrieb Michael Ellerman:
>
> [...]
>
> Having said all that, this email was mainly a fishing expedition to see if
> anyone still cares about Cell support at all. It sounds like you at least
> are running mainline kernels on PS3?

well, I like to but I couldn't get the kernel booting for some reason. Still 
trying. Beside this, I have nothing against dropping the other cell systems, 
but I'm only a "fun user", so my vote probably isn't counting :-)

Marc


signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Time to remove platforms/cell?

[Arnd Bergmann]

On Thursday 17 September 2015 12:28:13 Marc Dietrich wrote:
> Am Donnerstag, 17. September 2015, 19:45:38 schrieb Michael Ellerman:
> > On Thu, 2015-09-17 at 10:43 +0200, Marc Dietrich wrote:
> > > Am Donnerstag, 17. September 2015, 15:28:47 schrieb Michael Ellerman:
> >
> > [...]
> >
> > Having said all that, this email was mainly a fishing expedition to see if
> > anyone still cares about Cell support at all. It sounds like you at least
> > are running mainline kernels on PS3?
> 
> well, I like to but I couldn't get the kernel booting for some reason. Still 
> trying. Beside this, I have nothing against dropping the other cell systems, 
> but I'm only a "fun user", so my vote probably isn't counting 

No, your vote counts at least as much as a commercial user, because
"fun users" are more likely to contribute back patches when something
breaks.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Time to remove platforms/cell?

[Marc Dietrich]

Am Donnerstag, 17. September 2015, 15:28:47 schrieb Michael Ellerman:
> Discuss ...

as long as Geoff still maintains the ps3 port - why?

Marc


signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] arch-powerpc: Return false instead of -EFAULT

[Peter Senna Tschudin]

Returning a negative value for a boolean function seem to have the
undesired effect of returning true. Replace -EINVAL by false in a
bool-returning function.

The diff of the .s file before and after the change (using cross
compilation) starts with:

440,441c440,441
< .L43:
<   li 3,1   # D.25775,
---
> .L42:
>   li 3,0   # D.25775,
...

while if -EFAULT is replaced by true, the diff is empty.

There is only one call site, and it expects a boolean value:
arch/powerpc/kernel/ftrace.c:129:
if (!is_module_trampoline(tramp)) {
pr_err("Not a trampoline\n");
return -EINVAL;
}

This issue was found by the following Coccinelle semantic patch:

@@
identifier f;
constant C;
typedef bool;
@@
bool f (...){
<+...
* return -C;
...+>
}


Signed-off-by: Peter Senna Tschudin 
---
 arch/powerpc/kernel/module_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 6838451..a94a5f1 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -160,7 +160,7 @@ bool is_module_trampoline(u32 *p)
BUILD_BUG_ON(sizeof(ppc64_stub_insns) != sizeof(ppc64_stub_mask));
 
if (probe_kernel_read(insns, p, sizeof(insns)))
-   return -EFAULT;
+   return false;
 
for (i = 0; i < ARRAY_SIZE(ppc64_stub_insns); i++) {
u32 insna = insns[i];
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3] powerpc: msi: mark bitmap with kmemleak_not_leak()

[Catalin Marinas]

On Wed, Sep 16, 2015 at 10:26:14PM +0300, Denis Kirjanov wrote:
> During the MSI bitmap test on boot kmemleak spews the following trace:
> 
> unreferenced object 0xc0016e86c900 (size 64):
> comm "swapper/0", pid 1, jiffies 4294893173 (age 518.024s)
> hex dump (first 32 bytes):
>   00 00 01 ff 7f ff 7f 37 00 00 00 00 00 00 00 00
>   ...7
>   ff ff ff ff ff ff ff ff 01 ff ff ff ff
>   ff ff ff
>   
>   backtrace:
>   [] .zalloc_maybe_bootmem+0x3c/0x380
>   [] .msi_bitmap_alloc+0x3c/0xb0
>   [] .msi_bitmap_selftest+0x30/0x2b4
>   [] .do_one_initcall+0xd4/0x270
>   [] .kernel_init_freeable+0x1a0/0x280
>   [] .kernel_init+0x1c/0x120
>   [] .ret_from_kernel_thread+0x58/0x9c
> 
> Added a flag to msi_bitmap for tracking allocations
> from slab and memblock so we can properly free/handle
> memory in msi_bitmap_free().
> 
> Signed-off-by: Denis Kirjanov 

Reviewed-by: Catalin Marinas 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Time to remove platforms/cell?

[Arnd Bergmann]

On Thursday 17 September 2015 10:43:39 Marc Dietrich wrote:
> Am Donnerstag, 17. September 2015, 15:28:47 schrieb Michael Ellerman:
> > Discuss ...
> 
> as long as Geoff still maintains the ps3 port - why?
> 
We already removed celleb a while ago, which was arguably the least
commonly used one.

Within platforms/cell, we have three separate portions that we need
to look at:

a) Common ps3/ibm parts: spufs, oprofile
   We should not remove them before we plan to also remove platforms/ps3
   support, which doesn't seem likely in the near term. We can move them
   to platforms/ps3 if we decide to remove the rest.

b) Support for IBM blades:
   It is unlikely that there are QS20 blades still around and being used
   at all, but there is very little code specific to them.
   For QS21/QS22, there are probably still a few in existence, but
   I have no idea whether anybody would consider running a 4.x kernel
   on them. There are also some customer-specific Cell machines that
   are vaguely related to QS22 and that are in a similar state.
   I don't mind removing the code, but if anybody is still using it
   on new kernels, we should be prepared to put it back.

c) QPACE. We know who the three users were, and they have upgraded to
   QPACE2 (based on Intel Xeon Phi) this year. Removing this would be
   appreciated as it lets us clean up one of the ugly corners of the
   8250 uart driver.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

[David Laight]

From: Segher Boessenkool
> Sent: 17 September 2015 04:19
> On Thu, Sep 17, 2015 at 12:50:12PM +1000, Michael Ellerman wrote:
> > On Wed, 2015-09-16 at 21:54 -0400, Steven Rostedt wrote:
> > > This could be a symptom and not the problem. What the above shows is
> > > that ftrace tried to convert the mcount at change_protection but what
> > > it expected was there wasn't. Unfortunately, it doesn't state exactly
> > > what it wants (that would take a arch specific function to do that, and
> > > this is in generic code). But what it found was "74 66 74 70", which I
> > > have no idea what type of command that is.
> >
> > This is big endian, so I think that's:
> >
> >   andis.  r6,r3,29808
> >
> > Which is feasible.
> 
> It also says "tftp", which is intriguing if nothing else :-)

Much more likely than the above instruction.
If the address it wass read from is in the dump, look at the entire string.

David

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] arch-powerpc: Return false instead of -EFAULT

[Michael Ellerman]

On Thu, 2015-09-17 at 11:18 +0200, Peter Senna Tschudin wrote:
> Returning a negative value for a boolean function seem to have the
> undesired effect of returning true. Replace -EINVAL by false in a
> bool-returning function.
> 
> The diff of the .s file before and after the change (using cross
> compilation) starts with:
> 
> 440,441c440,441
> < .L43:
> < li 3,1   # D.25775,
> ---
> > .L42:
> > li 3,0   # D.25775,
> ...
> 
> while if -EFAULT is replaced by true, the diff is empty.

Ah, that's rather unfortunate.

Can you post the full asm listing, for all three cases?

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

[Thomas Gleixner]

On Thu, 17 Sep 2015, Steven Rostedt wrote:

> On Thu, 17 Sep 2015 16:38:52 +0200 (CEST)
> Thomas Gleixner  wrote:
> 
> > On Thu, 17 Sep 2015, Steven Rostedt wrote:
> > 
> > > On Thu, 17 Sep 2015 12:13:15 +0200 (CEST)
> > > Thomas Gleixner  wrote:
> > > 
> > > > Digging deeper. My assumption that it's a post powerpc merge failure
> > > > turned out to be wrong.
> > > 
> > > Does 4.2 have the problem?
> > 
> > No. Neither does 
> > 
> > 4c92b5bb1422: Merge branch 'pcmcia' of 
> > git://ftp.arm.linux.org.uk/~rmk/linux-arm
> 
> What's the significance of that commit?

It's the commit before the merge of the powerpc tree.

ff474e8ca854: Merge tag 'powerpc-4.3-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
 
> > It just results in a different failure mode. Instead of silently
> > hanging I get:
> > 
> > [2.248275] Oops: Exception in kernel mode, sig: 4 [#1]
> > [2.253633] PREEMPT lite5200
> > [2.256584] Modules linked in:
> > [2.259723] CPU: 0 PID: 1 Comm: swapper Not tainted 
> > 4.3.0-rc1-51179-gae80a2f-dirty #75
> > [2.267815] task: c383c000 ti: c383a000 task.ti: c383a000
> > [2.273330] NIP: c00e1eec LR: c00df0f4 CTR: 
> > [2.278405] REGS: c383bcd0 TRAP: 0700   Not tainted  
> > (4.3.0-rc1-51179-gae80a2f-dirty)
> > [2.286396] MSR: 00089032   CR: 44824028  XER: 
> > [2.293187] 
> > GPR00: c00def84 c383bd80 c383c000 c3084000 bff1 00677595 c383bdd8 
> >  
> > GPR08: 0001 0001 0400 0002 24828022  c0004254 
> > 84822042 
> > GPR16: 2000 44822042 f000 c3086ffc c06ce248 c383a000 c3082000 
> > c06d 
> > GPR24: c383a000 0ffc 00677595 bff1 c3084000 c3015bfc 0017 
> > c3086000 
> > [2.323656] NIP [c00e1eec] vm_normal_page+0x0/0xdc
> > [2.328560] LR [c00df0f4] follow_page_mask+0x260/0x4fc
> > [2.333807] Call Trace:
> > [2.336321] [c383bd80] [c00def84] follow_page_mask+0xf0/0x4fc 
> > (unreliable)
> > [2.343360] [c383bdd0] [c00df4a4] __get_user_pages.part.28+0x114/0x3e0
> > [2.350050] [c383be30] [c010e788] copy_strings+0x16c/0x2c8
> > [2.355668] [c383bea0] [c010e91c] copy_strings_kernel+0x38/0x50
> > [2.361730] [c383bec0] [c011057c] do_execveat_common+0x440/0x658
> > [2.367877] [c383bf10] [c01107cc] do_execve+0x38/0x48
> > [2.373056] [c383bf20] [c00039f0] try_to_run_init_process+0x24/0x64
> > [2.379469] [c383bf30] [c000430c] kernel_init+0xb8/0x10c
> > [2.384924] [c383bf40] [c0010c40] ret_from_kernel_thread+0x5c/0x64
> > [2.391242] --- interrupt: 0 at   (null)
> > [2.391242] LR =   (null)
> > [2.398263] Instruction dump:
> > [2.401297] 0100 00037000   f000 0001 
> > 0a641e09 acde4823 
> > [2.409237] 000f 179a7b00 07de2900 03ef1480 <01f78a40> 0001c200 
> > 6000 9421fff0 
> 
> Can you objdump this and and see what that is suppose to be.

Certainly not the code at NIP [c00e1eec] vm_normal_page:

c00e1eec :
c00e1eec:   7c 08 02 a6 mflrr0
c00e1ef0:   90 01 00 04 stw r0,4(r1)
c00e1ef4:   4b f2 f6 05 bl  c00114f8 <_mcount>
c00e1ef8:   94 21 ff f0 stwur1,-16(r1)
c00e1efc:   7c 08 02 a6 mflrr0
c00e1f00:   90 01 00 14 stw r0,20(r1)
c00e1f04:   70 a9 08 00 andi.   r9,r5,2048

That looks more like random data corruption.
 
> > [2.417375] ---[ end trace 996fd312ce9c18ce ]---
> > 
> > Again, if I disable CONFIG_TRACER its gone.
> 
> You mean if you disable CONFIG_FUNCTION_TRACER?

I have to disable both to make it boot. Disabling
CONFIG_FUNCTION_TRACER changes the failure mode, but does not make it
go away.
 

> Below is the entire push of ftrace for this merge window. Not much has
> changed. Could using "unsigned long" instead of "long" with the
> MCOUNT_ADDR cause this bug?

No, because the trace merge happened after the powerpc merge. But the
powerpc merge might be a red herring and the whole issue is caused by
something else which just gets unearthed by it.

Thanks,

tglx


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 0/4] PCI: arm64/powerpc: Fix parsing of linux,pci-probe-only

[Bjorn Helgaas]

On Fri, Sep 04, 2015 at 05:50:07PM +0100, Marc Zyngier wrote:
> The pci-host-generic driver parses the linux,pci-probe-only property,
> and assumes that it will have a boolean parameter.
> 
> Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
> property, which leads to the driver dereferencing some unsuspecting
> memory location. Nothing really bad happens (we end up reading some
> other bit of DT, fortunately), but that not a reason to keep it this
> way. Turns out that the Pseries code (where this code was lifted from)
> may suffer from the same issue.
> 
> The first patch introduces a common (and fixed) version of that check
> that can be used by drivers and architectures that require it. The two
> following patches change the pci-host-generic driver and the powerpc
> code to use it.
> 
> Finally, the bad property is removed from the Seatle DTS, because it
> is simply not necessary (it actually prevents me from using SR-IOV,
> which otherwise runs fine without the probe-only thing).
> 
> This has been tested on the offending Seattle board.
> 
> * From v3:
>   - Restrict the property lookup to /chosen (Rob)
>   - Acked-by on patch #4 from Suravee
>   - I swear this is the last time I rework these patches! ;-)
> 
> * From v2:
>   - Use of_property_read_u32 to safely read the property (Rob)
>   - Add a log message to indicate when we enable probe-only
> (probably quite useful for debugging)
> 
> * From v1:
>   - Consolidate the parsing in of_pci.c (Bjorn)
> 
> Marc Zyngier (4):
>   of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"
>   PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
>   powerpc: PCI: Fix lookup of linux,pci-probe-only property
>   arm64: dts: Drop linux,pci-probe-only from the Seattle DTS
> 
>  arch/arm64/boot/dts/amd/amd-overdrive.dts |  1 -
>  arch/powerpc/platforms/pseries/setup.c| 14 ++
>  drivers/of/of_pci.c   | 28 
>  drivers/pci/host/pci-host-generic.c   |  9 +
>  include/linux/of_pci.h|  3 +++
>  5 files changed, 34 insertions(+), 21 deletions(-)

Applied with the comment tweak and acks to pci/host-generic for v4.4,
thanks!
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

[Steven Rostedt]

On Thu, 17 Sep 2015 12:13:15 +0200 (CEST)
Thomas Gleixner  wrote:

> Digging deeper. My assumption that it's a post powerpc merge failure
> turned out to be wrong.

Does 4.2 have the problem?

> 
> Some more data points. I see the above splat with
> 
> CONFIG_FUNCTION_TRACER=y
> CONFIG_FUNCTION_GRAPH_TRACER=y
> 
> It goes away with 
> 
> CONFIG_FUNCTION_TRACER=y
> CONFIG_FUNCTION_GRAPH_TRACER=n

Strange, because function graph tracer should have no effect on the
conversions of mcount calls into nops.


> 
> But the box still does not get to the login prompt.
> 
> CONFIG_FUNCTION_TRACER=n
> 
> makes it work again.
> 
> It's not observable before the ppc merge, but I can't identify the
> culprit by bisection. bisection led into lala land.
> 

If it's a corruption of the mcount tables, it could be specific on what
the compiler does. That is, the working of one kernel to the other, may
only depend on how gcc compiled something. Have you tried different
compilers? Maybe one version of gcc may work over another?

This may explain why turning off function graph made the splat go away.
It changes the way the compiler built the code.

-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

[Steven Rostedt]

On Thu, 17 Sep 2015 16:38:52 +0200 (CEST)
Thomas Gleixner  wrote:

> On Thu, 17 Sep 2015, Steven Rostedt wrote:
> 
> > On Thu, 17 Sep 2015 12:13:15 +0200 (CEST)
> > Thomas Gleixner  wrote:
> > 
> > > Digging deeper. My assumption that it's a post powerpc merge failure
> > > turned out to be wrong.
> > 
> > Does 4.2 have the problem?
> 
> No. Neither does 
> 
> 4c92b5bb1422: Merge branch 'pcmcia' of 
> git://ftp.arm.linux.org.uk/~rmk/linux-arm

What's the significance of that commit?

>  
> > If it's a corruption of the mcount tables, it could be specific on what
> > the compiler does. That is, the working of one kernel to the other, may
> > only depend on how gcc compiled something. Have you tried different
> > compilers? Maybe one version of gcc may work over another?
> 
> It just results in a different failure mode. Instead of silently
> hanging I get:
> 
> [2.248275] Oops: Exception in kernel mode, sig: 4 [#1]
> [2.253633] PREEMPT lite5200
> [2.256584] Modules linked in:
> [2.259723] CPU: 0 PID: 1 Comm: swapper Not tainted 
> 4.3.0-rc1-51179-gae80a2f-dirty #75
> [2.267815] task: c383c000 ti: c383a000 task.ti: c383a000
> [2.273330] NIP: c00e1eec LR: c00df0f4 CTR: 
> [2.278405] REGS: c383bcd0 TRAP: 0700   Not tainted  
> (4.3.0-rc1-51179-gae80a2f-dirty)
> [2.286396] MSR: 00089032   CR: 44824028  XER: 
> [2.293187] 
> GPR00: c00def84 c383bd80 c383c000 c3084000 bff1 00677595 c383bdd8 
>  
> GPR08: 0001 0001 0400 0002 24828022  c0004254 
> 84822042 
> GPR16: 2000 44822042 f000 c3086ffc c06ce248 c383a000 c3082000 
> c06d 
> GPR24: c383a000 0ffc 00677595 bff1 c3084000 c3015bfc 0017 
> c3086000 
> [2.323656] NIP [c00e1eec] vm_normal_page+0x0/0xdc
> [2.328560] LR [c00df0f4] follow_page_mask+0x260/0x4fc
> [2.333807] Call Trace:
> [2.336321] [c383bd80] [c00def84] follow_page_mask+0xf0/0x4fc (unreliable)
> [2.343360] [c383bdd0] [c00df4a4] __get_user_pages.part.28+0x114/0x3e0
> [2.350050] [c383be30] [c010e788] copy_strings+0x16c/0x2c8
> [2.355668] [c383bea0] [c010e91c] copy_strings_kernel+0x38/0x50
> [2.361730] [c383bec0] [c011057c] do_execveat_common+0x440/0x658
> [2.367877] [c383bf10] [c01107cc] do_execve+0x38/0x48
> [2.373056] [c383bf20] [c00039f0] try_to_run_init_process+0x24/0x64
> [2.379469] [c383bf30] [c000430c] kernel_init+0xb8/0x10c
> [2.384924] [c383bf40] [c0010c40] ret_from_kernel_thread+0x5c/0x64
> [2.391242] --- interrupt: 0 at   (null)
> [2.391242] LR =   (null)
> [2.398263] Instruction dump:
> [2.401297] 0100 00037000   f000 0001 0a641e09 
> acde4823 
> [2.409237] 000f 179a7b00 07de2900 03ef1480 <01f78a40> 0001c200 
> 6000 9421fff0 

Can you objdump this and and see what that is suppose to be.

> [2.417375] ---[ end trace 996fd312ce9c18ce ]---
> 
> Again, if I disable CONFIG_TRACER its gone.

You mean if you disable CONFIG_FUNCTION_TRACER?

Below is the entire push of ftrace for this merge window. Not much has
changed. Could using "unsigned long" instead of "long" with the
MCOUNT_ADDR cause this bug?

-- Steve

diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index 7ddb1e319f84..072d3c4d5753 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -686,6 +686,8 @@ The above is mostly meaningful for kernel developers.
 The marks are determined by the difference between this
 current trace and the next trace.
  '$' - greater than 1 second
+ '@' - greater than 100 milisecond
+ '*' - greater than 10 milisecond
  '#' - greater than 1000 microsecond
  '!' - greater than 100 microsecond
  '+' - greater than 10 microsecond
@@ -1939,26 +1941,49 @@ want, depending on your needs.
 
   ie:
 
-  0)   |up_write() {
-  0)   0.646 us|  _spin_lock_irqsave();
-  0)   0.684 us|  _spin_unlock_irqrestore();
-  0)   3.123 us|}
-  0)   0.548 us|fput();
-  0) + 58.628 us   |  }
+  3) # 1837.709 us |  } /* __switch_to */
+  3)   |  finish_task_switch() {
+  3)   0.313 us|_raw_spin_unlock_irq();
+  3)   3.177 us|  }
+  3) # 1889.063 us |} /* __schedule */
+  3) ! 140.417 us  |  } /* __schedule */
+  3) # 2034.948 us |} /* schedule */
+  3) * 33998.59 us |  } /* schedule_preempt_disabled */
 
   [...]
 
-  0)   |  putname() {
-  0)   |kmem_cache_free() {
-  0)   0.518 us|  __phys_addr();
-  0)   1.757 us|}
-  0)   2.861 us|  }
-  0) ! 115.305 us  |}
-  0) ! 116.402 us  |  }
+  1)   0.260 us|  msecs_to_jiffies();
+  1)   0.313 us|  __rcu_read_unlock();
+  1) + 61.770 us   |}
+  1) + 64.479 us   |  

Re: [PATCH v2 09/30] cxlflash: Fix to stop interrupt processing on remove

[Tomas Henzl]

On 16.9.2015 18:53, Matthew R. Ochs wrote:
> Interrupt processing can run in parallel to a remove operation. This
> can lead to a condition where the interrupt handler is processing with
> memory that has been freed.
> 
> To avoid processing an interrupt while memory may be yanked, check for
> removal while in the interrupt handler. Bail when removal is imminent.
>
> Signed-off-by: Matthew R. Ochs 
> Signed-off-by: Manoj N. Kumar 
> ---
>  drivers/scsi/cxlflash/common.h |  2 ++
>  drivers/scsi/cxlflash/main.c   | 21 +++--
>  2 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/cxlflash/common.h b/drivers/scsi/cxlflash/common.h
> index 1abe4e0..03d2cc6 100644
> --- a/drivers/scsi/cxlflash/common.h
> +++ b/drivers/scsi/cxlflash/common.h
> @@ -103,6 +103,8 @@ struct cxlflash_cfg {
>   enum cxlflash_lr_state lr_state;
>   int lr_port;
>  
> + atomic_t remove_active;
> +
>   struct cxl_afu *cxl_afu;
>  
>   struct pci_pool *cxlflash_cmd_pool;
> diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
> index 6e85c77..89ee648 100644
> --- a/drivers/scsi/cxlflash/main.c
> +++ b/drivers/scsi/cxlflash/main.c
> @@ -892,6 +892,7 @@ static void cxlflash_remove(struct pci_dev *pdev)
>   spin_unlock_irqrestore(>tmf_waitq.lock, lock_flags);
>  
>   cfg->state = STATE_FAILTERM;
> + atomic_inc(>remove_active);

Hi Matthew,
you could just call term_afu at this point, this way you don't
need an additional check in all irq functions.
Cheers,
Tomas

>   cxlflash_stop_term_user_contexts(cfg);
>  
>   switch (cfg->init_state) {
> @@ -1380,16 +1381,20 @@ static void afu_err_intr_init(struct afu *afu)
>  static irqreturn_t cxlflash_sync_err_irq(int irq, void *data)
>  {
>   struct afu *afu = (struct afu *)data;
> + struct cxlflash_cfg *cfg = afu->parent;
>   u64 reg;
>   u64 reg_unmasked;
>  
> + if (atomic_read(>remove_active))
> + goto out;
> +
>   reg = readq_be(>host_map->intr_status);
>   reg_unmasked = (reg & SISL_ISTATUS_UNMASK);
>  
>   if (reg_unmasked == 0UL) {
>   pr_err("%s: %llX: spurious interrupt, intr_status %016llX\n",
>  __func__, (u64)afu, reg);
> - goto cxlflash_sync_err_irq_exit;
> + goto out;
>   }
>  
>   pr_err("%s: %llX: unexpected interrupt, intr_status %016llX\n",
> @@ -1397,7 +1402,7 @@ static irqreturn_t cxlflash_sync_err_irq(int irq, void 
> *data)
>  
>   writeq_be(reg_unmasked, >host_map->intr_clear);
>  
> -cxlflash_sync_err_irq_exit:
> +out:
>   pr_debug("%s: returning rc=%d\n", __func__, IRQ_HANDLED);
>   return IRQ_HANDLED;
>  }
> @@ -1412,6 +1417,7 @@ cxlflash_sync_err_irq_exit:
>  static irqreturn_t cxlflash_rrq_irq(int irq, void *data)
>  {
>   struct afu *afu = (struct afu *)data;
> + struct cxlflash_cfg *cfg = afu->parent;
>   struct afu_cmd *cmd;
>   bool toggle = afu->toggle;
>   u64 entry,
> @@ -1421,8 +1427,10 @@ static irqreturn_t cxlflash_rrq_irq(int irq, void 
> *data)
>  
>   /* Process however many RRQ entries that are ready */
>   while (true) {
> - entry = *hrrq_curr;
> + if (atomic_read(>remove_active))
> + goto out;
>  
> + entry = *hrrq_curr;
>   if ((entry & SISL_RESP_HANDLE_T_BIT) != toggle)
>   break;
>  
> @@ -1440,7 +1448,7 @@ static irqreturn_t cxlflash_rrq_irq(int irq, void *data)
>  
>   afu->hrrq_curr = hrrq_curr;
>   afu->toggle = toggle;
> -
> +out:
>   return IRQ_HANDLED;
>  }
>  
> @@ -1454,7 +1462,7 @@ static irqreturn_t cxlflash_rrq_irq(int irq, void *data)
>  static irqreturn_t cxlflash_async_err_irq(int irq, void *data)
>  {
>   struct afu *afu = (struct afu *)data;
> - struct cxlflash_cfg *cfg;
> + struct cxlflash_cfg *cfg = afu->parent;
>   u64 reg_unmasked;
>   const struct asyc_intr_info *info;
>   struct sisl_global_map *global = >afu_map->global;
> @@ -1462,7 +1470,8 @@ static irqreturn_t cxlflash_async_err_irq(int irq, void 
> *data)
>   u8 port;
>   int i;
>  
> - cfg = afu->parent;
> + if (atomic_read(>remove_active))
> + goto out;
>  
>   reg = readq_be(>regs.aintr_status);
>   reg_unmasked = (reg & SISL_ASTATUS_UNMASK);

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

[Thomas Gleixner]

On Thu, 17 Sep 2015, Steven Rostedt wrote:

> On Thu, 17 Sep 2015 12:13:15 +0200 (CEST)
> Thomas Gleixner  wrote:
> 
> > Digging deeper. My assumption that it's a post powerpc merge failure
> > turned out to be wrong.
> 
> Does 4.2 have the problem?

No. Neither does 

4c92b5bb1422: Merge branch 'pcmcia' of git://ftp.arm.linux.org.uk/~rmk/linux-arm
 
> If it's a corruption of the mcount tables, it could be specific on what
> the compiler does. That is, the working of one kernel to the other, may
> only depend on how gcc compiled something. Have you tried different
> compilers? Maybe one version of gcc may work over another?

It just results in a different failure mode. Instead of silently
hanging I get:

[2.248275] Oops: Exception in kernel mode, sig: 4 [#1]
[2.253633] PREEMPT lite5200
[2.256584] Modules linked in:
[2.259723] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.3.0-rc1-51179-gae80a2f-dirty #75
[2.267815] task: c383c000 ti: c383a000 task.ti: c383a000
[2.273330] NIP: c00e1eec LR: c00df0f4 CTR: 
[2.278405] REGS: c383bcd0 TRAP: 0700   Not tainted  
(4.3.0-rc1-51179-gae80a2f-dirty)
[2.286396] MSR: 00089032   CR: 44824028  XER: 
[2.293187] 
GPR00: c00def84 c383bd80 c383c000 c3084000 bff1 00677595 c383bdd8  
GPR08: 0001 0001 0400 0002 24828022  c0004254 84822042 
GPR16: 2000 44822042 f000 c3086ffc c06ce248 c383a000 c3082000 c06d 
GPR24: c383a000 0ffc 00677595 bff1 c3084000 c3015bfc 0017 c3086000 
[2.323656] NIP [c00e1eec] vm_normal_page+0x0/0xdc
[2.328560] LR [c00df0f4] follow_page_mask+0x260/0x4fc
[2.333807] Call Trace:
[2.336321] [c383bd80] [c00def84] follow_page_mask+0xf0/0x4fc (unreliable)
[2.343360] [c383bdd0] [c00df4a4] __get_user_pages.part.28+0x114/0x3e0
[2.350050] [c383be30] [c010e788] copy_strings+0x16c/0x2c8
[2.355668] [c383bea0] [c010e91c] copy_strings_kernel+0x38/0x50
[2.361730] [c383bec0] [c011057c] do_execveat_common+0x440/0x658
[2.367877] [c383bf10] [c01107cc] do_execve+0x38/0x48
[2.373056] [c383bf20] [c00039f0] try_to_run_init_process+0x24/0x64
[2.379469] [c383bf30] [c000430c] kernel_init+0xb8/0x10c
[2.384924] [c383bf40] [c0010c40] ret_from_kernel_thread+0x5c/0x64
[2.391242] --- interrupt: 0 at   (null)
[2.391242] LR =   (null)
[2.398263] Instruction dump:
[2.401297] 0100 00037000   f000 0001 0a641e09 
acde4823 
[2.409237] 000f 179a7b00 07de2900 03ef1480 <01f78a40> 0001c200 6000 
9421fff0 
[2.417375] ---[ end trace 996fd312ce9c18ce ]---

Again, if I disable CONFIG_TRACER its gone.

Thanks,

tglx

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 09/30] cxlflash: Fix to stop interrupt processing on remove

[Matthew R. Ochs]

> On Sep 17, 2015, at 6:58 AM, David Laight  wrote:
> 
> From: Linuxppc-dev Matthew R. Ochs
>> Sent: 16 September 2015 22:28
>> Interrupt processing can run in parallel to a remove operation. This
>> can lead to a condition where the interrupt handler is processing with
>> memory that has been freed.
>> 
>> To avoid processing an interrupt while memory may be yanked, check for
>> removal while in the interrupt handler. Bail when removal is imminent.
> 
> On the face of it this just reduces the size of the window somewhat.

Agreed.

> 
> What happens if the interrupt routine reads the flag just before it is set
> (so is processing the entry that is being removed) and is then (say)
> interrupted by a higher priority interrupt that takes longer to execute than
> the remove code?

Understood. To completely close we'd need to either introduce a lock or a
reciprocal flag/count such that the remove doesn't make forward progress
until after interrupt processing has completed. I can look at introducing such
a mechanism in a later patch to fully remove the exposure.


-matt


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Time to remove platforms/cell?

[Geoff Levand]

On Thu, 2015-09-17 at 20:05 +1000, Michael Ellerman wrote:

> Right. I wouldn't bet money that the oprofile code still works, but spufs
> definitely would have to stay.

oprofile on PS3 needed additional patches [1] that I never
merged upstream, and no longer plan to, so oprofile support
should be removed.

If someone in the future needs oprofile it wouldn't be too
hard to get what is there now working again. 

[1] 
http://git.kernel.org/cgit/linux/kernel/git/geoff/ps3-linux.git/log/?h=ps3-queue-v3.7

-Geoff



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: rackmeter: Fix module autoload for OF platform driver

[Luis de Bethencourt]

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.

Signed-off-by: Luis de Bethencourt 
---

Hello,

This patch adds the missing MODULE_DEVICE_TABLE() for OF to export
that information so modules have the correct aliases built-in and
autoloading works correctly.

A longer explanation by Javier Canillas can be found here:
https://lkml.org/lkml/2015/7/30/519

Thanks,
Luis

 drivers/macintosh/rack-meter.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/macintosh/rack-meter.c b/drivers/macintosh/rack-meter.c
index 048901a..caaec65 100644
--- a/drivers/macintosh/rack-meter.c
+++ b/drivers/macintosh/rack-meter.c
@@ -582,6 +582,7 @@ static struct of_device_id rackmeter_match[] = {
{ .name = "i2s" },
{ }
 };
+MODULE_DEVICE_TABLE(of, rackmeter_match);
 
 static struct macio_driver rackmeter_driver = {
.driver = {
-- 
2.4.6

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 09/30] cxlflash: Fix to stop interrupt processing on remove

[Matthew R. Ochs]

> On Sep 17, 2015, at 7:38 AM, Tomas Henzl  wrote:
> 
> On 16.9.2015 18:53, Matthew R. Ochs wrote:
>> Interrupt processing can run in parallel to a remove operation. This
>> can lead to a condition where the interrupt handler is processing with
>> memory that has been freed.
>> 
>> To avoid processing an interrupt while memory may be yanked, check for
>> removal while in the interrupt handler. Bail when removal is imminent.
>> 
>> Signed-off-by: Matthew R. Ochs 
>> Signed-off-by: Manoj N. Kumar 
>> ---
>> drivers/scsi/cxlflash/common.h |  2 ++
>> drivers/scsi/cxlflash/main.c   | 21 +++--
>> 2 files changed, 17 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drivers/scsi/cxlflash/common.h b/drivers/scsi/cxlflash/common.h
>> index 1abe4e0..03d2cc6 100644
>> --- a/drivers/scsi/cxlflash/common.h
>> +++ b/drivers/scsi/cxlflash/common.h
>> @@ -103,6 +103,8 @@ struct cxlflash_cfg {
>>  enum cxlflash_lr_state lr_state;
>>  int lr_port;
>> 
>> +atomic_t remove_active;
>> +
>>  struct cxl_afu *cxl_afu;
>> 
>>  struct pci_pool *cxlflash_cmd_pool;
>> diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
>> index 6e85c77..89ee648 100644
>> --- a/drivers/scsi/cxlflash/main.c
>> +++ b/drivers/scsi/cxlflash/main.c
>> @@ -892,6 +892,7 @@ static void cxlflash_remove(struct pci_dev *pdev)
>>  spin_unlock_irqrestore(>tmf_waitq.lock, lock_flags);
>> 
>>  cfg->state = STATE_FAILTERM;
>> +atomic_inc(>remove_active);
> 
> Hi Matthew,
> you could just call term_afu at this point, this way you don't
> need an additional check in all irq functions.
> Cheers,
> Tomas

Hi Tomas,

We actually do call term_afu() a few lines down from here. I don't follow
how moving it here would help things.

The reason for the atomic was to provide something lightweight that we
could check _inside_ the processing loop for the read-response queue
handler. A check outside that loop doesn't really provide much in terms
of closing or narrowing down the window of when freed memory can be
accessed.

As David Laight correctly pointed out, this approach does not completely
close the window. We'd need something heavier to fully protect (e.g. a lock
to wrap around the entire loop). I will look into adding this in a future cycle
when I can adequately test.


-matt

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 0/4] PCI: arm64/powerpc: Fix parsing of linux, pci-probe-only

[Bjorn Helgaas]

On Thu, Sep 17, 2015 at 12:17 PM, Marc Zyngier  wrote:
> On 17/09/15 16:30, Bjorn Helgaas wrote:
>> On Fri, Sep 04, 2015 at 05:50:07PM +0100, Marc Zyngier wrote:
>>> The pci-host-generic driver parses the linux,pci-probe-only property,
>>> and assumes that it will have a boolean parameter.
>>>
>>> Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
>>> property, which leads to the driver dereferencing some unsuspecting
>>> memory location. Nothing really bad happens (we end up reading some
>>> other bit of DT, fortunately), but that not a reason to keep it this
>>> way. Turns out that the Pseries code (where this code was lifted from)
>>> may suffer from the same issue.
>>>
>>> The first patch introduces a common (and fixed) version of that check
>>> that can be used by drivers and architectures that require it. The two
>>> following patches change the pci-host-generic driver and the powerpc
>>> code to use it.
>>>
>>> Finally, the bad property is removed from the Seatle DTS, because it
>>> is simply not necessary (it actually prevents me from using SR-IOV,
>>> which otherwise runs fine without the probe-only thing).
>>>
>>> This has been tested on the offending Seattle board.
>>>
>>> * From v3:
>>>   - Restrict the property lookup to /chosen (Rob)
>>>   - Acked-by on patch #4 from Suravee
>>>   - I swear this is the last time I rework these patches! ;-)
>>>
>>> * From v2:
>>>   - Use of_property_read_u32 to safely read the property (Rob)
>>>   - Add a log message to indicate when we enable probe-only
>>> (probably quite useful for debugging)
>>>
>>> * From v1:
>>>   - Consolidate the parsing in of_pci.c (Bjorn)
>>>
>>> Marc Zyngier (4):
>>>   of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"
>>>   PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
>>>   powerpc: PCI: Fix lookup of linux,pci-probe-only property
>>>   arm64: dts: Drop linux,pci-probe-only from the Seattle DTS
>>>
>>>  arch/arm64/boot/dts/amd/amd-overdrive.dts |  1 -
>>>  arch/powerpc/platforms/pseries/setup.c| 14 ++
>>>  drivers/of/of_pci.c   | 28 
>>>  drivers/pci/host/pci-host-generic.c   |  9 +
>>>  include/linux/of_pci.h|  3 +++
>>>  5 files changed, 34 insertions(+), 21 deletions(-)
>>
>> Applied with the comment tweak and acks to pci/host-generic for v4.4,
>> thanks!
>
> Turns out that the 01.org infrastructure has picked up on a compilation
> bug with randconfig. The following patch seems to fix it and should be
> applied on the first patch:
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 485d625..2da5abc 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -6,6 +6,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  static inline int __of_pci_pci_compare(struct device_node *node,
>unsigned int data)
>  {
>
> Sorry for the annoyance.

Folded in and re-pushed, thanks!
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

[Segher Boessenkool]

On Thu, Sep 17, 2015 at 09:47:39AM +, David Laight wrote:
> > It also says "tftp", which is intriguing if nothing else :-)
> 
> Much more likely than the above instruction.
> If the address it wass read from is in the dump, look at the entire string.

And tell us what network drivers you use, what firmware, what bootloader.
Try changing either of those (if feasible), see if the problem goes away.


Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v9 2/5] genalloc:support allocating specific region

[Scott Wood]

On Mon, 2015-09-14 at 09:38 +0800, Zhao Qiang wrote:
> Add new algo for genalloc, it reserve a specific region of
> memory matching the size requirement (no alignment constraint)
> 
> Signed-off-by: Zhao Qiang 
> ---
> Changes for v9:
>   - reserve a specific region, if the return region
>   - is not during the specific region, return fail.
> 
>  include/linux/genalloc.h | 11 +++
>  lib/genalloc.c   | 30 ++
>  2 files changed, 41 insertions(+)
> 
> diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
> index aaf3dc2..85e3b2f 100644
> --- a/include/linux/genalloc.h
> +++ b/include/linux/genalloc.h
> @@ -82,6 +82,13 @@ struct genpool_data_align {
>   int align;  /* alignment by bytes for starting address */
>  };
>  
> +/*
> + *  gen_pool data descriptor for gen_pool_fixed_fit.
> + */
> +struct genpool_data_fixed {
> + unsigned long offset;   /* The offset of the specific region */
> +};
> +
>  extern struct gen_pool *gen_pool_create(int, int);
>  extern phys_addr_t gen_pool_virt_to_phys(struct gen_pool *pool, unsigned 
> long);
>  extern int gen_pool_add_virt(struct gen_pool *, unsigned long, phys_addr_t,
> @@ -121,6 +128,10 @@ extern unsigned long gen_pool_first_fit(unsigned long 
> *map, unsigned long size,
>   unsigned long start, unsigned int nr, void *data,
>   struct gen_pool *pool);
>  
> +extern unsigned long gen_pool_fixed_fit(unsigned long *map,
> + unsigned long size, unsigned long start, unsigned int nr,
> + void *data, struct gen_pool *pool);
> +

"fixed fit" doesn't make much sense...  How about "fixed_alloc"?

 /**
> + * gen_pool_fixed_fit - reserve a specific region of
> + * matching the size requirement (no alignment constraint)
> + * @map: The address to base the search on
> + * @size: The bitmap size in bits
> + * @start: The bitnumber to start searching at
> + * @nr: The number of zeroed bits we're looking for
> + * @data: data for alignment
> + * @pool: pool to get order from
> + */
> +unsigned long gen_pool_fixed_fit(unsigned long *map, unsigned long size,
> + unsigned long start, unsigned int nr, void *data,
> + struct gen_pool *pool)
> +{
> + struct genpool_data_fixed *fixed_data;
> + int order;
> + unsigned long offset_bit;
> + unsigned long start_bit;
> +
> + fixed_data = data;
> + order = pool->min_alloc_order;
> + offset_bit = fixed_data->offset >> order;
> + start_bit = bitmap_find_next_zero_area(map, size,
> + start + offset_bit, nr, 0);
> + if (start_bit != offset_bit)
> + start_bit = size;
> + return start_bit;
> +}
> +EXPORT_SYMBOL(gen_pool_fixed_fit);

This would be simpler with bitmap_allocate_region().

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [BUG] Revert 0b05e2d671c4 'powerpc/32: cacheable_memcpy becomes memcpy'

[Segher Boessenkool]

On Thu, Sep 17, 2015 at 04:38:52PM +0200, Thomas Gleixner wrote:
> [2.398263] Instruction dump:
> [2.401297] 0100 00037000   f000 0001 0a641e09 
> acde4823 
> [2.409237] 000f 179a7b00 07de2900 03ef1480 <01f78a40> 0001c200 
> 6000 9421fff0 

Those are not instructions (until the nop).

Starting three back from the failing instruction, those are

39600 13200 6600 <3300> 115200

so something has been scribbling what looks like clock frequencies
over your code.  Judging from the register contents this has happened
some time before.

Some device trees have similar numbers, e.g. media5200.dts does.


Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v9 3/5] qe_common: add qe_muram_ functions to manage muram

[Scott Wood]

On Mon, 2015-09-14 at 09:38 +0800, Zhao Qiang wrote:
> diff --git a/arch/powerpc/sysdev/qe_lib/qe_common.c 
> b/arch/powerpc/sysdev/qe_lib/qe_common.c
> new file mode 100644
> index 000..1213458
> --- /dev/null
> +++ b/arch/powerpc/sysdev/qe_lib/qe_common.c
> @@ -0,0 +1,242 @@
> +/*
> + * Freescale QE common code
> + *
> + * Author: Zhao Qiang  
> + *
> + * Copyright 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static struct gen_pool *muram_pool;
> +static struct genpool_data_align muram_pool_data;
> +static struct genpool_data_fixed muram_pool_data_fixed;
> +static spinlock_t qe_muram_lock;
> +static u8 __iomem *muram_vbase;
> +static phys_addr_t muram_pbase;
> +
> +struct muram_block {
> + struct list_head head;
> + unsigned long start;
> + int size;
> +};
> +
> +static LIST_HEAD(muram_block_list);
> +
> +/* max address size we deal with */
> +#define OF_MAX_ADDR_CELLS4
> +#define GENPOOL_OFFSET   4096
> +
> +int qe_muram_init(void)
> +{
> + struct device_node *np;
> + struct resource r;
> + u32 zero[OF_MAX_ADDR_CELLS] = {};
> + resource_size_t max = 0;
> + int i = 0;
> + int ret = 0;
> +
> + if (muram_pbase)
> + return 0;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe-muram-data");
> + if (!np) {
> + /* try legacy bindings */
> + np = of_find_node_by_name(NULL, "data-only");
> + if (!np) {
> + pr_err("Cannot find CPM muram data node");
> + ret = -ENODEV;
> + goto out;
> + }
> + }
> +
> + muram_pool = gen_pool_create(1, -1);
> + muram_pbase = of_translate_address(np, zero);
> + if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
> + pr_err("Cannot translate zero through CPM muram node");
> + ret = -ENODEV;
> + goto err;
> + }
> +
> + while (of_address_to_resource(np, i++, ) == 0) {
> + if (r.end > max)
> + max = r.end;
> + ret = gen_pool_add(muram_pool, r.start - muram_pbase +
> +GENPOOL_OFFSET, resource_size(), -1);
> + if (ret) {
> + pr_err("QE: couldn't add muram to pool!\n");
> + goto err;
> + }
> +
> + }
> +
> + muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
> + if (!muram_vbase) {
> + pr_err("Cannot map QE muram");
> + ret = -ENOMEM;
> + goto err;
> + }
> + goto out;
> +err:
> + gen_pool_destroy(muram_pool);
> +out:
> + of_node_put(np);
> + return ret;
> +}
> +
> +/*
> + * qe_muram_alloc - allocate the requested size worth of multi-user ram
> + * @size: number of bytes to allocate
> + * @align: requested alignment, in bytes
> + *
> + * This function returns an offset into the muram area.
> + */
> +unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
> +{
> + unsigned long start;
> + unsigned long flags;
> + struct muram_block *entry;
> +
> + spin_lock_irqsave(_muram_lock, flags);
> + muram_pool_data.align = align;
> + gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
> +   _pool_data);
> + start = gen_pool_alloc(muram_pool, size);
> + if (!start)
> + goto out2;
> + start = start - GENPOOL_OFFSET;
> + memset(qe_muram_addr(start), 0, size);
> + entry = kmalloc(sizeof(*entry), GFP_KERNEL);
> + if (!entry)
> + goto out1;
> + entry->start = start;
> + entry->size = size;
> + list_add(>head, _block_list);
> + spin_unlock_irqrestore(_muram_lock, flags);
> +
> + return start;
> +out1:
> + gen_pool_free(muram_pool, start, size);
> +out2:
> + spin_unlock_irqrestore(_muram_lock, flags);
> + return (unsigned long) -ENOMEM;
> +}
> +EXPORT_SYMBOL(qe_muram_alloc);
> +
> +/*
> + * qe_muram_alloc_fixed - reserve a specific region of multi-user ram
> + * @size: number of bytes to allocate
> + * @offset: offset of allocation start address
> + *
> + * This function returns an offset into the muram area.
> + */
> +unsigned long qe_muram_alloc_fixed(unsigned long offset, unsigned long 
> size)
> +{
> +
> + unsigned long start;
> + unsigned long flags;
> + unsigned long size_alloc = size;
> + struct muram_block *entry;
> + int end_bit;
> + int order = muram_pool -> min_alloc_order;
> +
> + 

Re: [PATCH v9 2/5] genalloc:support allocating specific region

[Scott Wood]

On Thu, 2015-09-17 at 15:19 -0500, Scott Wood wrote:
> On Mon, 2015-09-14 at 09:38 +0800, Zhao Qiang wrote:
> > Add new algo for genalloc, it reserve a specific region of
> > memory matching the size requirement (no alignment constraint)
> > 
> > Signed-off-by: Zhao Qiang 
> > ---
> > Changes for v9:
> >   - reserve a specific region, if the return region
> >   - is not during the specific region, return fail.
> > 
> >  include/linux/genalloc.h | 11 +++
> >  lib/genalloc.c   | 30 ++
> >  2 files changed, 41 insertions(+)
> > 
> > diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
> > index aaf3dc2..85e3b2f 100644
> > --- a/include/linux/genalloc.h
> > +++ b/include/linux/genalloc.h
> > @@ -82,6 +82,13 @@ struct genpool_data_align {
> >   int align;  /* alignment by bytes for starting address 
> > */
> >  };
> >  
> > +/*
> > + *  gen_pool data descriptor for gen_pool_fixed_fit.
> > + */
> > +struct genpool_data_fixed {
> > + unsigned long offset;   /* The offset of the specific 
> > region */
> > +};
> > +
> >  extern struct gen_pool *gen_pool_create(int, int);
> >  extern phys_addr_t gen_pool_virt_to_phys(struct gen_pool *pool, unsigned 
> > long);
> >  extern int gen_pool_add_virt(struct gen_pool *, unsigned long, 
> > phys_addr_t,
> > @@ -121,6 +128,10 @@ extern unsigned long gen_pool_first_fit(unsigned 
> > long 
> > *map, unsigned long size,
> >   unsigned long start, unsigned int nr, void *data,
> >   struct gen_pool *pool);
> >  
> > +extern unsigned long gen_pool_fixed_fit(unsigned long *map,
> > + unsigned long size, unsigned long start, unsigned int nr,
> > + void *data, struct gen_pool *pool);
> > +
> 
> "fixed fit" doesn't make much sense...  How about "fixed_alloc"?
> 
>  /**
> > + * gen_pool_fixed_fit - reserve a specific region of
> > + * matching the size requirement (no alignment constraint)
> > + * @map: The address to base the search on
> > + * @size: The bitmap size in bits
> > + * @start: The bitnumber to start searching at
> > + * @nr: The number of zeroed bits we're looking for
> > + * @data: data for alignment
> > + * @pool: pool to get order from
> > + */
> > +unsigned long gen_pool_fixed_fit(unsigned long *map, unsigned long size,
> > + unsigned long start, unsigned int nr, void *data,
> > + struct gen_pool *pool)
> > +{
> > + struct genpool_data_fixed *fixed_data;
> > + int order;
> > + unsigned long offset_bit;
> > + unsigned long start_bit;
> > +
> > + fixed_data = data;
> > + order = pool->min_alloc_order;
> > + offset_bit = fixed_data->offset >> order;
> > + start_bit = bitmap_find_next_zero_area(map, size,
> > + start + offset_bit, nr, 0);
> > + if (start_bit != offset_bit)
> > + start_bit = size;
> > + return start_bit;
> > +}
> > +EXPORT_SYMBOL(gen_pool_fixed_fit);
> 
> This would be simpler with bitmap_allocate_region().

Never mind, that doesn't fit with how the algorithm is used by the caller, 
and unlike genalloc isn't atomic.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 0/4] PCI: arm64/powerpc: Fix parsing of linux, pci-probe-only

[Marc Zyngier]

On 17/09/15 16:30, Bjorn Helgaas wrote:
> On Fri, Sep 04, 2015 at 05:50:07PM +0100, Marc Zyngier wrote:
>> The pci-host-generic driver parses the linux,pci-probe-only property,
>> and assumes that it will have a boolean parameter.
>>
>> Turns out that the Seattle DTS file has a naked "linux,pci-probe-only"
>> property, which leads to the driver dereferencing some unsuspecting
>> memory location. Nothing really bad happens (we end up reading some
>> other bit of DT, fortunately), but that not a reason to keep it this
>> way. Turns out that the Pseries code (where this code was lifted from)
>> may suffer from the same issue.
>>
>> The first patch introduces a common (and fixed) version of that check
>> that can be used by drivers and architectures that require it. The two
>> following patches change the pci-host-generic driver and the powerpc
>> code to use it.
>>
>> Finally, the bad property is removed from the Seatle DTS, because it
>> is simply not necessary (it actually prevents me from using SR-IOV,
>> which otherwise runs fine without the probe-only thing).
>>
>> This has been tested on the offending Seattle board.
>>
>> * From v3:
>>   - Restrict the property lookup to /chosen (Rob)
>>   - Acked-by on patch #4 from Suravee
>>   - I swear this is the last time I rework these patches! ;-)
>>
>> * From v2:
>>   - Use of_property_read_u32 to safely read the property (Rob)
>>   - Add a log message to indicate when we enable probe-only
>> (probably quite useful for debugging)
>>
>> * From v1:
>>   - Consolidate the parsing in of_pci.c (Bjorn)
>>
>> Marc Zyngier (4):
>>   of/pci: Add of_pci_check_probe_only to parse "linux,pci-probe-only"
>>   PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
>>   powerpc: PCI: Fix lookup of linux,pci-probe-only property
>>   arm64: dts: Drop linux,pci-probe-only from the Seattle DTS
>>
>>  arch/arm64/boot/dts/amd/amd-overdrive.dts |  1 -
>>  arch/powerpc/platforms/pseries/setup.c| 14 ++
>>  drivers/of/of_pci.c   | 28 
>>  drivers/pci/host/pci-host-generic.c   |  9 +
>>  include/linux/of_pci.h|  3 +++
>>  5 files changed, 34 insertions(+), 21 deletions(-)
> 
> Applied with the comment tweak and acks to pci/host-generic for v4.4,
> thanks!

Turns out that the 01.org infrastructure has picked up on a compilation
bug with randconfig. The following patch seems to fix it and should be
applied on the first patch:

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 485d625..2da5abc 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -6,6 +6,8 @@
 #include 
 #include 
 
+#include 
+
 static inline int __of_pci_pci_compare(struct device_node *node,
   unsigned int data)
 {

Sorry for the annoyance.

M.
-- 
Jazz is not dead. It just smells funny...
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 02/30] cxlflash: Replace magic numbers with literals

[Brian King]

Reviewed-by: Brian King 

-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 03/30] cxlflash: Fix read capacity timeout

[Brian King]

On 09/16/2015 04:26 PM, Matthew R. Ochs wrote:
> @@ -296,7 +296,7 @@ static int read_cap16(struct scsi_device *sdev, struct 
> llun_info *lli)
>   int rc = 0;
>   int result = 0;
>   int retry_cnt = 0;
> - u32 tout = (MC_DISCOVERY_TIMEOUT * HZ);
> + u32 to = (CMD_TIMEOUT * HZ);
> 
>  retry:
>   cmd_buf = kzalloc(CMD_BUFSIZE, GFP_KERNEL);
> @@ -315,8 +315,7 @@ retry:
>   retry_cnt ? "re" : "", scsi_cmd[0]);
> 
>   result = scsi_execute(sdev, scsi_cmd, DMA_FROM_DEVICE, cmd_buf,
> -   CMD_BUFSIZE, sense_buf, tout, CMD_RETRIES,
> -   0, NULL);
> +   CMD_BUFSIZE, sense_buf, to, CMD_RETRIES, 0, NULL);
> 
>   if (driver_byte(result) == DRIVER_SENSE) {
>   result &= ~(0xFF<<24); /* DRIVER_SENSE is not an error */
> @@ -1376,8 +1375,8 @@ out_attach:
>   attach->block_size = gli->blk_len;
>   attach->mmio_size = sizeof(afu->afu_map->hosts[0].harea);
>   attach->last_lba = gli->max_lba;
> - attach->max_xfer = (sdev->host->max_sectors * MAX_SECTOR_UNIT) /
> - gli->blk_len;
> + attach->max_xfer = (sdev->host->max_sectors * MAX_SECTOR_UNIT);
> + attach->max_xfer /= gli->blk_len;

This change and the one above are not really part of the patch. Not a big deal, 
but
in future would be good to either call out the fact that there are a couple of 
unrelated
formatting changes, or keep them out and stick them in a separate cleanup patch.

Reviewed-by: Brian King 

-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 05/30] cxlflash: Fix data corruption when vLUN used over multiple cards

[Brian King]

Reviewed-by: Brian King 

-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 01/30] cxlflash: Fix to avoid invalid port_sel value

[Brian King]

Reviewed-by: Brian King 

-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 04/30] cxlflash: Fix potential oops following LUN removal

[Brian King]

On 09/16/2015 04:27 PM, Matthew R. Ochs wrote:
> When a LUN is removed, the sdev that is associated with the LUN
> remains intact until its reference count drops to 0. In order
> to prevent an sdev from being removed while a context is still
> associated with it, obtain an additional reference per-context
> for each LUN attached to the context.
> 
> This resolves a potential Oops in the release handler when a
> dealing with a LUN that has already been removed.
> 
> Signed-off-by: Matthew R. Ochs 
> Signed-off-by: Manoj N. Kumar 
> Suggested-by: Brian King 
> ---
>  drivers/scsi/cxlflash/superpipe.c | 36 
>  1 file changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/scsi/cxlflash/superpipe.c 
> b/drivers/scsi/cxlflash/superpipe.c
> index fa513ba..1fa4af6 100644
> --- a/drivers/scsi/cxlflash/superpipe.c
> +++ b/drivers/scsi/cxlflash/superpipe.c
> @@ -880,6 +880,9 @@ static int _cxlflash_disk_detach(struct scsi_device *sdev,
>   sys_close(lfd);
>   }
> 
> + /* Release the sdev reference that bound this LUN to the context */
> + scsi_device_put(sdev);
> +
>  out:
>   if (put_ctx)
>   put_context(ctxi);
> @@ -1287,11 +1290,18 @@ static int cxlflash_disk_attach(struct scsi_device 
> *sdev,
>   }
>   }
> 
> + rc = scsi_device_get(sdev);
> + if (unlikely(rc)) {
> + dev_err(dev, "%s: Unable to get sdev reference!\n", __func__);
> + goto out;
> + }
> +
>   lun_access = kzalloc(sizeof(*lun_access), GFP_KERNEL);
>   if (unlikely(!lun_access)) {
>   dev_err(dev, "%s: Unable to allocate lun_access!\n", __func__);
> + scsi_device_put(sdev);

Looks like you've got a double scsi_device_put in this path, since there is 
another put
in the the err0 path.

>   rc = -ENOMEM;
> - goto out;
> + goto err0;
>   }
> 
>   lun_access->lli = lli;
> @@ -1311,21 +1321,21 @@ static int cxlflash_disk_attach(struct scsi_device 
> *sdev,
>   dev_err(dev, "%s: Could not initialize context %p\n",
>   __func__, ctx);
>   rc = -ENODEV;
> - goto err0;
> + goto err1;
>   }
> 
>   ctxid = cxl_process_element(ctx);
>   if (unlikely((ctxid > MAX_CONTEXT) || (ctxid < 0))) {
>   dev_err(dev, "%s: ctxid (%d) invalid!\n", __func__, ctxid);
>   rc = -EPERM;
> - goto err1;
> + goto err2;
>   }
> 
>   file = cxl_get_fd(ctx, >cxl_fops, );
>   if (unlikely(fd < 0)) {
>   rc = -ENODEV;
>   dev_err(dev, "%s: Could not get file descriptor\n", __func__);
> - goto err1;
> + goto err2;
>   }
> 
>   /* Translate read/write O_* flags from fcntl.h to AFU permission bits */
> @@ -1335,7 +1345,7 @@ static int cxlflash_disk_attach(struct scsi_device 
> *sdev,
>   if (unlikely(!ctxi)) {
>   dev_err(dev, "%s: Failed to create context! (%d)\n",
>   __func__, ctxid);
> - goto err2;
> + goto err3;
>   }
> 
>   work = >work;
> @@ -1346,13 +1356,13 @@ static int cxlflash_disk_attach(struct scsi_device 
> *sdev,
>   if (unlikely(rc)) {
>   dev_dbg(dev, "%s: Could not start context rc=%d\n",
>   __func__, rc);
> - goto err3;
> + goto err4;
>   }
> 
>   rc = afu_attach(cfg, ctxi);
>   if (unlikely(rc)) {
>   dev_err(dev, "%s: Could not attach AFU rc %d\n", __func__, rc);
> - goto err4;
> + goto err5;
>   }
> 
>   /*
> @@ -1388,13 +1398,13 @@ out:
>   __func__, ctxid, fd, attach->block_size, rc, attach->last_lba);
>   return rc;
> 
> -err4:
> +err5:
>   cxl_stop_context(ctx);
> -err3:
> +err4:
>   put_context(ctxi);
>   destroy_context(cfg, ctxi);
>   ctxi = NULL;
> -err2:
> +err3:
>   /*
>* Here, we're overriding the fops with a dummy all-NULL fops because
>* fput() calls the release fop, which will cause us to mistakenly
> @@ -1406,10 +1416,12 @@ err2:
>   fput(file);
>   put_unused_fd(fd);
>   fd = -1;
> -err1:
> +err2:
>   cxl_release_context(ctx);
> -err0:
> +err1:
>   kfree(lun_access);
> +err0:
> + scsi_device_put(sdev);
>   goto out;
>  }
> 


-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 07/30] cxlflash: Fix context encode mask width

[Brian King]

Reviewed-by: Brian King 


-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 06/30] cxlflash: Fix to avoid sizeof(bool)

[Brian King]

Reviewed-by: Brian King 


-- 
Brian King
Power Linux I/O
IBM Linux Technology Center

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v9 3/5] qe_common: add qe_muram_ functions to manage muram

[Zhao Qiang]

On Mon, 2015-09-18 at 04:28 +0800, Wood Scott-B07421 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, September 18, 2015 4:28 AM
> To: Zhao Qiang-B45475
> Cc: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> Yang-Leo-R58472; pau...@samba.org
> Subject: Re: [PATCH v9 3/5] qe_common: add qe_muram_ functions to manage
> muram
> 
> On Mon, 2015-09-14 at 09:38 +0800, Zhao Qiang wrote:
> > diff --git a/arch/powerpc/sysdev/qe_lib/qe_common.c
> > b/arch/powerpc/sysdev/qe_lib/qe_common.c
> > new file mode 100644
> > index 000..1213458
> > --- /dev/null
> > +++ b/arch/powerpc/sysdev/qe_lib/qe_common.c
> > @@ -0,0 +1,242 @@
> > +/*
> > + * Freescale QE common code
> > + *
> > + * Author: Zhao Qiang  
> > + *
> > + * Copyright 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +static struct gen_pool *muram_pool;
> > +static struct genpool_data_align muram_pool_data; static struct
> > +genpool_data_fixed muram_pool_data_fixed; static spinlock_t
> > +qe_muram_lock; static u8 __iomem *muram_vbase; static phys_addr_t
> > +muram_pbase;
> > +
> > +struct muram_block {
> > + struct list_head head;
> > + unsigned long start;
> > + int size;
> > +};
> > +
> > +static LIST_HEAD(muram_block_list);
> > +
> > +/* max address size we deal with */
> > +#define OF_MAX_ADDR_CELLS4
> > +#define GENPOOL_OFFSET   4096
> > +
> > +int qe_muram_init(void)
> > +{
> > + struct device_node *np;
> > + struct resource r;
> > + u32 zero[OF_MAX_ADDR_CELLS] = {};
> > + resource_size_t max = 0;
> > + int i = 0;
> > + int ret = 0;
> > +
> > + if (muram_pbase)
> > + return 0;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "fsl,qe-muram-data");
> > + if (!np) {
> > + /* try legacy bindings */
> > + np = of_find_node_by_name(NULL, "data-only");
> > + if (!np) {
> > + pr_err("Cannot find CPM muram data node");
> > + ret = -ENODEV;
> > + goto out;
> > + }
> > + }
> > +
> > + muram_pool = gen_pool_create(1, -1);
> > + muram_pbase = of_translate_address(np, zero);
> > + if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
> > + pr_err("Cannot translate zero through CPM muram node");
> > + ret = -ENODEV;
> > + goto err;
> > + }
> > +
> > + while (of_address_to_resource(np, i++, ) == 0) {
> > + if (r.end > max)
> > + max = r.end;
> > + ret = gen_pool_add(muram_pool, r.start - muram_pbase +
> > +GENPOOL_OFFSET, resource_size(), -1);
> > + if (ret) {
> > + pr_err("QE: couldn't add muram to
> pool!\n");
> > + goto err;
> > + }
> > +
> > + }
> > +
> > + muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
> > + if (!muram_vbase) {
> > + pr_err("Cannot map QE muram");
> > + ret = -ENOMEM;
> > + goto err;
> > + }
> > + goto out;
> > +err:
> > + gen_pool_destroy(muram_pool);
> > +out:
> > + of_node_put(np);
> > + return ret;
> > +}
> > +
> > +/*
> > + * qe_muram_alloc - allocate the requested size worth of multi-user
> > +ram
> > + * @size: number of bytes to allocate
> > + * @align: requested alignment, in bytes
> > + *
> > + * This function returns an offset into the muram area.
> > + */
> > +unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
> > +{
> > + unsigned long start;
> > + unsigned long flags;
> > + struct muram_block *entry;
> > +
> > + spin_lock_irqsave(_muram_lock, flags);
> > + muram_pool_data.align = align;
> > + gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
> > +   _pool_data);
> > + start = gen_pool_alloc(muram_pool, size);
> > + if (!start)
> > + goto out2;
> > + start = start - GENPOOL_OFFSET;
> > + memset(qe_muram_addr(start), 0, size);
> > + entry = kmalloc(sizeof(*entry), GFP_KERNEL);
> > + if (!entry)
> > + goto out1;
> > + entry->start = start;
> > + entry->size = size;
> > + list_add(>head, _block_list);
> > + spin_unlock_irqrestore(_muram_lock, flags);
> > +
> > + return start;
> > +out1:
> > + 

Re: [PATCH v9 3/5] qe_common: add qe_muram_ functions to manage muram

[Scott Wood]

On Thu, 2015-09-17 at 21:35 -0500, Zhao Qiang-B45475 wrote:
> On Mon, 2015-09-18 at 04:28 +0800, Wood Scott-B07421 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, September 18, 2015 4:28 AM
> > To: Zhao Qiang-B45475
> > Cc: linux-ker...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
> > Yang-Leo-R58472; pau...@samba.org
> > Subject: Re: [PATCH v9 3/5] qe_common: add qe_muram_ functions to manage
> > muram
> > 
> > On Mon, 2015-09-14 at 09:38 +0800, Zhao Qiang wrote:
> > > diff --git a/arch/powerpc/sysdev/qe_lib/qe_common.c
> > > b/arch/powerpc/sysdev/qe_lib/qe_common.c
> > > new file mode 100644
> > > index 000..1213458
> > > --- /dev/null
> > > +++ b/arch/powerpc/sysdev/qe_lib/qe_common.c
> > > @@ -0,0 +1,242 @@
> > > +/*
> > > + * Freescale QE common code
> > > + *
> > > + * Author: Zhao Qiang  
> > > + *
> > > + * Copyright 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.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +static struct gen_pool *muram_pool;
> > > +static struct genpool_data_align muram_pool_data; static struct
> > > +genpool_data_fixed muram_pool_data_fixed; static spinlock_t
> > > +qe_muram_lock; static u8 __iomem *muram_vbase; static phys_addr_t
> > > +muram_pbase;
> > > +
> > > +struct muram_block {
> > > + struct list_head head;
> > > + unsigned long start;
> > > + int size;
> > > +};
> > > +
> > > +static LIST_HEAD(muram_block_list);
> > > +
> > > +/* max address size we deal with */
> > > +#define OF_MAX_ADDR_CELLS4
> > > +#define GENPOOL_OFFSET   4096
> > > +
> > > +int qe_muram_init(void)
> > > +{
> > > + struct device_node *np;
> > > + struct resource r;
> > > + u32 zero[OF_MAX_ADDR_CELLS] = {};
> > > + resource_size_t max = 0;
> > > + int i = 0;
> > > + int ret = 0;
> > > +
> > > + if (muram_pbase)
> > > + return 0;
> > > +
> > > + np = of_find_compatible_node(NULL, NULL, "fsl,qe-muram-data");
> > > + if (!np) {
> > > + /* try legacy bindings */
> > > + np = of_find_node_by_name(NULL, "data-only");
> > > + if (!np) {
> > > + pr_err("Cannot find CPM muram data node");
> > > + ret = -ENODEV;
> > > + goto out;
> > > + }
> > > + }
> > > +
> > > + muram_pool = gen_pool_create(1, -1);
> > > + muram_pbase = of_translate_address(np, zero);
> > > + if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
> > > + pr_err("Cannot translate zero through CPM muram node");
> > > + ret = -ENODEV;
> > > + goto err;
> > > + }
> > > +
> > > + while (of_address_to_resource(np, i++, ) == 0) {
> > > + if (r.end > max)
> > > + max = r.end;
> > > + ret = gen_pool_add(muram_pool, r.start - muram_pbase +
> > > +GENPOOL_OFFSET, resource_size(), -1);
> > > + if (ret) {
> > > + pr_err("QE: couldn't add muram to
> > pool!\n");
> > > + goto err;
> > > + }
> > > +
> > > + }
> > > +
> > > + muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
> > > + if (!muram_vbase) {
> > > + pr_err("Cannot map QE muram");
> > > + ret = -ENOMEM;
> > > + goto err;
> > > + }
> > > + goto out;
> > > +err:
> > > + gen_pool_destroy(muram_pool);
> > > +out:
> > > + of_node_put(np);
> > > + return ret;
> > > +}
> > > +
> > > +/*
> > > + * qe_muram_alloc - allocate the requested size worth of multi-user
> > > +ram
> > > + * @size: number of bytes to allocate
> > > + * @align: requested alignment, in bytes
> > > + *
> > > + * This function returns an offset into the muram area.
> > > + */
> > > +unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
> > > +{
> > > + unsigned long start;
> > > + unsigned long flags;
> > > + struct muram_block *entry;
> > > +
> > > + spin_lock_irqsave(_muram_lock, flags);
> > > + muram_pool_data.align = align;
> > > + gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
> > > +   _pool_data);
> > > + start = gen_pool_alloc(muram_pool, size);
> > > + if (!start)
> > > + goto out2;
> > > + start = start - GENPOOL_OFFSET;
> > > + 

Re: [PATCH] powerpc: Kconfig: remove BE-only platforms from LE kernel build

[Boqun Feng]

Ping ;-)

Regards,
Boqun

On Mon, Sep 07, 2015 at 07:58:00AM +0800, Boqun Feng wrote:
> Currently, little endian is only supported on powernv and pseries,
> however, Kconfigs still allow us to include other platforms in a LE
> kernel, this may result in space wasting or even build error if some
> BE-only platforms always assume they are built for a BE kernel. So just
> modify the Kconfigs of BE-only platforms to remove them from being built
> for a LE kernel.
> 
> For 32bit only platforms, nothing needs to be done, because
> CPU_LITTLE_ENDIAN depends on PPC64. For 64bit supported platforms, add
> CPU_BIG_ENDIAN to dependencies explicitly, so that these platforms will
> be disabled for LE [Suggested-by: Cédric Le Goater ].
> 
> Signed-off-by: Boqun Feng 
> ---
>  arch/powerpc/platforms/cell/Kconfig | 4 ++--
>  arch/powerpc/platforms/maple/Kconfig| 2 +-
>  arch/powerpc/platforms/pasemi/Kconfig   | 2 +-
>  arch/powerpc/platforms/powermac/Kconfig | 2 +-
>  arch/powerpc/platforms/ps3/Kconfig  | 2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/cell/Kconfig 
> b/arch/powerpc/platforms/cell/Kconfig
> index 2f23133..808a904 100644
> --- a/arch/powerpc/platforms/cell/Kconfig
> +++ b/arch/powerpc/platforms/cell/Kconfig
> @@ -25,7 +25,7 @@ config PPC_CELL_NATIVE
>  
>  config PPC_IBM_CELL_BLADE
>   bool "IBM Cell Blade"
> - depends on PPC64 && PPC_BOOK3S
> + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN
>   select PPC_CELL_NATIVE
>   select PPC_OF_PLATFORM_PCI
>   select PCI
> @@ -35,7 +35,7 @@ config PPC_IBM_CELL_BLADE
>  
>  config PPC_CELL_QPACE
>   bool "IBM Cell - QPACE"
> - depends on PPC64 && PPC_BOOK3S
> + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN
>   select PPC_CELL_COMMON
>  
>  config AXON_MSI
> diff --git a/arch/powerpc/platforms/maple/Kconfig 
> b/arch/powerpc/platforms/maple/Kconfig
> index 1ea621a..e359d0d 100644
> --- a/arch/powerpc/platforms/maple/Kconfig
> +++ b/arch/powerpc/platforms/maple/Kconfig
> @@ -1,5 +1,5 @@
>  config PPC_MAPLE
> - depends on PPC64 && PPC_BOOK3S
> + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN
>   bool "Maple 970FX Evaluation Board"
>   select PCI
>   select MPIC
> diff --git a/arch/powerpc/platforms/pasemi/Kconfig 
> b/arch/powerpc/platforms/pasemi/Kconfig
> index a2aeb32..00d4b28 100644
> --- a/arch/powerpc/platforms/pasemi/Kconfig
> +++ b/arch/powerpc/platforms/pasemi/Kconfig
> @@ -1,5 +1,5 @@
>  config PPC_PASEMI
> - depends on PPC64 && PPC_BOOK3S
> + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN
>   bool "PA Semi SoC-based platforms"
>   default n
>   select MPIC
> diff --git a/arch/powerpc/platforms/powermac/Kconfig 
> b/arch/powerpc/platforms/powermac/Kconfig
> index 607124b..43c6062 100644
> --- a/arch/powerpc/platforms/powermac/Kconfig
> +++ b/arch/powerpc/platforms/powermac/Kconfig
> @@ -1,6 +1,6 @@
>  config PPC_PMAC
>   bool "Apple PowerMac based machines"
> - depends on PPC_BOOK3S
> + depends on PPC_BOOK3S && CPU_BIG_ENDIAN
>   select MPIC
>   select PCI
>   select PPC_INDIRECT_PCI if PPC32
> diff --git a/arch/powerpc/platforms/ps3/Kconfig 
> b/arch/powerpc/platforms/ps3/Kconfig
> index 56f2740..b27f40f 100644
> --- a/arch/powerpc/platforms/ps3/Kconfig
> +++ b/arch/powerpc/platforms/ps3/Kconfig
> @@ -1,6 +1,6 @@
>  config PPC_PS3
>   bool "Sony PS3"
> - depends on PPC64 && PPC_BOOK3S
> + depends on PPC64 && PPC_BOOK3S && CPU_BIG_ENDIAN
>   select PPC_CELL
>   select USB_OHCI_LITTLE_ENDIAN
>   select USB_OHCI_BIG_ENDIAN_MMIO
> -- 
> 2.5.1
> 


signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] PowerPC: Move Freescale device tree files into fsl folder

[Hongtao Jia]

Typo in message.
This patch was superseded.

Please refer to the new one I just sent.

Thanks.

---
Best Regards,
Hongtao


> -Original Message-
> From: Jia Hongtao [mailto:hongtao@freescale.com]
> Sent: Friday, September 18, 2015 11:52 AM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org;
> robh...@kernel.org; Jia Hongtao-B38951
> Subject: [PATCH] PowerPC: Move Freescale device tree files into fsl
> folder
> 
> It makes no sense that some Freescale device tree files are in fsl
> directory while some others not. This patch move Freescale device tree
> files into fsl folder. To do that the following two steps are made:
> - Move Freescale device tree files into fsl folder.
> - Update the include path in these files from "fsl/*.dtsi" to "*.dtsi".
> 
> Plese add "fsl/" prefix when you make dtb using Makefile.
> 
> Signed-off-by: Jia Hongtao 
> ---
>  arch/powerpc/boot/dts/{ => fsl}/b4420qds.dts   | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/b4860qds.dts   | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/b4qds.dtsi | 2 +-
>  arch/powerpc/boot/dts/{ => fsl}/bsc9131rdb.dts | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/bsc9131rdb.dtsi| 0
>  arch/powerpc/boot/dts/{ => fsl}/bsc9132qds.dts | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/bsc9132qds.dtsi| 0
>  arch/powerpc/boot/dts/{ => fsl}/c293pcie.dts   | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/ge_imp3a.dts   | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/kmcoge4.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/mpc8536ds.dts  | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/mpc8536ds.dtsi | 0
>  arch/powerpc/boot/dts/{ => fsl}/mpc8536ds_36b.dts  | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/mpc8540ads.dts | 2 +-
>  arch/powerpc/boot/dts/{ => fsl}/mpc8541cds.dts | 2 +-
>  arch/powerpc/boot/dts/{ => fsl}/mpc8544ds.dts  | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/mpc8544ds.dtsi | 0
>  arch/powerpc/boot/dts/{ => fsl}/mpc8548cds.dtsi| 0
>  arch/powerpc/boot/dts/{ => fsl}/mpc8548cds_32b.dts | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/mpc8548cds_36b.dts | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/mpc8555cds.dts | 2 +-
>  arch/powerpc/boot/dts/{ => fsl}/mpc8560ads.dts | 2 +-
>  arch/powerpc/boot/dts/{ => fsl}/mpc8568mds.dts | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/mpc8569mds.dts | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/mpc8572ds.dts  | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/mpc8572ds.dtsi | 0
>  arch/powerpc/boot/dts/{ => fsl}/mpc8572ds_36b.dts  | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/mpc8572ds_camp_core0.dts   | 0
>  arch/powerpc/boot/dts/{ => fsl}/mpc8572ds_camp_core1.dts   | 0
>  arch/powerpc/boot/dts/{ => fsl}/mvme2500.dts   | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/oca4080.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pa.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pa.dtsi   | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pa_36b.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pb.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pb_36b.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1010rdb.dtsi  | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1010rdb_32b.dtsi  | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1010rdb_36b.dtsi  | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1020mbg-pc.dtsi   | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1020mbg-pc_32b.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1020mbg-pc_36b.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc.dtsi   | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_32b.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_36b.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_camp_core0.dts | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_camp_core1.dts | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pd.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1020rdb.dts   | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1020rdb.dtsi  | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1020rdb_36b.dts   | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1020utm-pc.dtsi   | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1020utm-pc_32b.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1020utm-pc_36b.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1021mds.dts   | 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1021rdb-pc.dtsi   | 0
>  arch/powerpc/boot/dts/{ => fsl}/p1021rdb-pc_32b.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1021rdb-pc_36b.dts| 4 ++--
>  arch/powerpc/boot/dts/{ => fsl}/p1022ds.dtsi  

Re: [PATCH] PowerPC: Move Freescale device tree files into fsl folder

[Scott Wood]

On Fri, 2015-09-18 at 12:00 +0800, Jia Hongtao wrote:
> It makes no sense that some Freescale device tree files are in fsl
> directory while some others not. This patch move Freescale device tree
> files into fsl folder. To do that the following two steps are made:
> - Move Freescale device tree files into fsl folder.
> - Update the include path in these files from "fsl/*.dtsi" to "*.dtsi".
> 
> Please add "fsl/" prefix when you make dtb using Makefile.

The existing arrangement is indeed a bit odd, but the real reason for this is 
the interaction with the preprocessor.  If a dtsi uses preprocessor 
directives, it needs to be included with #include rather than /include/, or 
else the dtsi won't be preprocessed.  However, if a dtsi is included with 
#include, and that dtsi is in fsl/ but the including dts isn't, any 
/include/s within the dtsi will not search that fsl/ because dtc doesn't 
realize that's the directory the content came from.

There was a desire to include  from 
fsl/t1040si-post.dtsi.  In order to make everything work, we need to either 
move all relevant files to the same directory, or convert all /include/s in 
affected files to #include.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] PowerPC: Move Freescale device tree files into fsl folder

[Jia Hongtao]

It makes no sense that some Freescale device tree files are in fsl
directory while some others not. This patch move Freescale device tree
files into fsl folder. To do that the following two steps are made:
- Move Freescale device tree files into fsl folder.
- Update the include path in these files from "fsl/*.dtsi" to "*.dtsi".

Plese add "fsl/" prefix when you make dtb using Makefile.

Signed-off-by: Jia Hongtao 
---
 arch/powerpc/boot/dts/{ => fsl}/b4420qds.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/b4860qds.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/b4qds.dtsi | 2 +-
 arch/powerpc/boot/dts/{ => fsl}/bsc9131rdb.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/bsc9131rdb.dtsi| 0
 arch/powerpc/boot/dts/{ => fsl}/bsc9132qds.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/bsc9132qds.dtsi| 0
 arch/powerpc/boot/dts/{ => fsl}/c293pcie.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/ge_imp3a.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/kmcoge4.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8536ds.dts  | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8536ds.dtsi | 0
 arch/powerpc/boot/dts/{ => fsl}/mpc8536ds_36b.dts  | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8540ads.dts | 2 +-
 arch/powerpc/boot/dts/{ => fsl}/mpc8541cds.dts | 2 +-
 arch/powerpc/boot/dts/{ => fsl}/mpc8544ds.dts  | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8544ds.dtsi | 0
 arch/powerpc/boot/dts/{ => fsl}/mpc8548cds.dtsi| 0
 arch/powerpc/boot/dts/{ => fsl}/mpc8548cds_32b.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8548cds_36b.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8555cds.dts | 2 +-
 arch/powerpc/boot/dts/{ => fsl}/mpc8560ads.dts | 2 +-
 arch/powerpc/boot/dts/{ => fsl}/mpc8568mds.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8569mds.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8572ds.dts  | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8572ds.dtsi | 0
 arch/powerpc/boot/dts/{ => fsl}/mpc8572ds_36b.dts  | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8572ds_camp_core0.dts   | 0
 arch/powerpc/boot/dts/{ => fsl}/mpc8572ds_camp_core1.dts   | 0
 arch/powerpc/boot/dts/{ => fsl}/mvme2500.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/oca4080.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pa.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pa.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pa_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pb.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pb_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb.dtsi  | 0
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb_32b.dtsi  | 0
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb_36b.dtsi  | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020mbg-pc.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020mbg-pc_32b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020mbg-pc_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_32b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_camp_core0.dts | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_camp_core1.dts | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pd.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb.dtsi  | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb_36b.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020utm-pc.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020utm-pc_32b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020utm-pc_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1021mds.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1021rdb-pc.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1021rdb-pc_32b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1021rdb-pc_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1022ds.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1022ds_32b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1022ds_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1022rdk.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1023rdb.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1024rdb.dtsi  | 0
 arch/powerpc/boot/dts/{ => fsl}/p1024rdb_32b.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1024rdb_36b.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1025rdb.dtsi  | 0
 arch/powerpc/boot/dts/{ => 

[PATCH] PowerPC: Move Freescale device tree files into fsl folder

[Jia Hongtao]

It makes no sense that some Freescale device tree files are in fsl
directory while some others not. This patch move Freescale device tree
files into fsl folder. To do that the following two steps are made:
- Move Freescale device tree files into fsl folder.
- Update the include path in these files from "fsl/*.dtsi" to "*.dtsi".

Please add "fsl/" prefix when you make dtb using Makefile.

Signed-off-by: Jia Hongtao 
---
 arch/powerpc/boot/dts/{ => fsl}/b4420qds.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/b4860qds.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/b4qds.dtsi | 2 +-
 arch/powerpc/boot/dts/{ => fsl}/bsc9131rdb.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/bsc9131rdb.dtsi| 0
 arch/powerpc/boot/dts/{ => fsl}/bsc9132qds.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/bsc9132qds.dtsi| 0
 arch/powerpc/boot/dts/{ => fsl}/c293pcie.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/ge_imp3a.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/kmcoge4.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8536ds.dts  | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8536ds.dtsi | 0
 arch/powerpc/boot/dts/{ => fsl}/mpc8536ds_36b.dts  | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8540ads.dts | 2 +-
 arch/powerpc/boot/dts/{ => fsl}/mpc8541cds.dts | 2 +-
 arch/powerpc/boot/dts/{ => fsl}/mpc8544ds.dts  | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8544ds.dtsi | 0
 arch/powerpc/boot/dts/{ => fsl}/mpc8548cds.dtsi| 0
 arch/powerpc/boot/dts/{ => fsl}/mpc8548cds_32b.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8548cds_36b.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8555cds.dts | 2 +-
 arch/powerpc/boot/dts/{ => fsl}/mpc8560ads.dts | 2 +-
 arch/powerpc/boot/dts/{ => fsl}/mpc8568mds.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8569mds.dts | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8572ds.dts  | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8572ds.dtsi | 0
 arch/powerpc/boot/dts/{ => fsl}/mpc8572ds_36b.dts  | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/mpc8572ds_camp_core0.dts   | 0
 arch/powerpc/boot/dts/{ => fsl}/mpc8572ds_camp_core1.dts   | 0
 arch/powerpc/boot/dts/{ => fsl}/mvme2500.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/oca4080.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pa.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pa.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pa_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pb.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb-pb_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb.dtsi  | 0
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb_32b.dtsi  | 0
 arch/powerpc/boot/dts/{ => fsl}/p1010rdb_36b.dtsi  | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020mbg-pc.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020mbg-pc_32b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020mbg-pc_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_32b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_camp_core0.dts | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pc_camp_core1.dts | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb-pd.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb.dtsi  | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020rdb_36b.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020utm-pc.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1020utm-pc_32b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1020utm-pc_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1021mds.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1021rdb-pc.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1021rdb-pc_32b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1021rdb-pc_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1022ds.dtsi   | 0
 arch/powerpc/boot/dts/{ => fsl}/p1022ds_32b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1022ds_36b.dts| 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1022rdk.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1023rdb.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1024rdb.dtsi  | 0
 arch/powerpc/boot/dts/{ => fsl}/p1024rdb_32b.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1024rdb_36b.dts   | 4 ++--
 arch/powerpc/boot/dts/{ => fsl}/p1025rdb.dtsi  | 0
 arch/powerpc/boot/dts/{ =>