gmane.linux.ports.ppc.embedded

Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling

David Gibson — 2013-05-25T02:45:24

So, in the case of MULTITCE, that's not quite right.  PR KVM can
emulate a PAPR system on a BookE machine, and there's no reason not to
allow TCE acceleration as well.  We can't make it dependent on PAPR
mode being selected, because that's enabled per-vcpu, whereas these
capabilities are queried on the VM before the vcpus are created.

CAP_SPAPR_TCE_IOMMU should be dependent on the presence of suitable
host side hardware (i.e. a PAPR style IOMMU), though.


Ah, yeah, that needs to be fixed.  Those were interim numbers so that
we didn't have to keep changing our internal trees as new upstream
ioctls got added to the list.  We need to get a proper number for the
merge, though.

[PATCH RESEND v2 2/2] serial/mpc52xx_uart: add MPC5125 PSC support

Anatolij Gustschin — 2013-05-24T18:24:59

From: Matteo Facchinetti <matteo.facchinetti< at >sirius-es.it>

Add MPC5125 PSC register layout structure, MPC5125 specific
psc_ops function set and the compatible string.

Signed-off-by: Vladimir Ermakov <vooon341< at >gmail.com>
Signed-off-by: Matteo Facchinetti <matteo.facchinetti< at >sirius-es.it>
Signed-off-by: Anatolij Gustschin <agust< at >denx.de>
---
Changes in v2:
 - split into two patches to simplify review
 - minor coding style changes 
 - revise commit log

 arch/powerpc/include/asm/mpc52xx_psc.h |   49 +++++++
 drivers/tty/serial/mpc52xx_uart.c      |  241 ++++++++++++++++++++++++++++++++
 2 files changed, 290 insertions(+)

diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h b/arch/powerpc/include/asm/mpc52xx_psc.h
index 2966df6..d0ece25 100644
--- a/arch/powerpc/include/asm/mpc52xx_psc.h
+++ b/arch/powerpc/include/asm/mpc52xx_psc.h
< at >< at > -299,4 +299,53 < at >< at > struct mpc512x_psc_fifo {
 #define rxdata_32 rxdata.rxdata_32
 };
 
+struct mpc5125_psc {
+u8mr1;/* PSC + 0x00 */
+u8reserved0[3];
+u8mr2;/* PSC

[PATCH RESEND v2 1/2] serial/mpc52xx_uart: prepare for adding MPC5125 PSC UART support

Anatolij Gustschin — 2013-05-24T18:24:58

From: Matteo Facchinetti <matteo.facchinetti< at >sirius-es.it>

MPC5125 PSC controller has different register layout than MPC5121.
To support MPC5125 PSC in this driver we have to provide further
psc_ops functions for SoC specific register accesses.

Add new register access functions to the psc_ops structure and
provide MPC52xx and MPC512x specific implementation for them.
Then replace remaining direct register accesses in the driver by
appropriate psc_ops function calls. The subsequent patch can now
add MPC5125 specific set of psc_ops functions.

Signed-off-by: Vladimir Ermakov <vooon341< at >gmail.com>
Signed-off-by: Matteo Facchinetti <matteo.facchinetti< at >sirius-es.it>
Signed-off-by: Anatolij Gustschin <agust< at >denx.de>
---

Changes in v2:
 - split into two patches to simplify review
 - minor coding style changes
 - revise commit log

 drivers/tty/serial/mpc52xx_uart.c |  161 +++++++++++++++++++++++++++----------
 1 file changed, 119 insertions(+), 42 deletions(-)

diff --git a/drivers/tty/serial/mpc52xx_uart.c b/dri

Re: [PATCH v2 1/2] serial/mpc52xx_uart: prepare for adding MPC5125 PSC UART support

Greg Kroah-Hartman — 2013-05-24T17:57:11

Sorry, I somehow lost this, so I can't see the original patch at all.
Care to resend it?

thanks,

greg k-h

Re: [PATCH v2 1/2] serial/mpc52xx_uart: prepare for adding MPC5125 PSC UART support

Anatolij Gustschin — 2013-05-24T17:49:12

On Wed, 17 Apr 2013 23:21:41 +0200
Anatolij Gustschin <agust< at >denx.de> wrote:


ping ...

Thanks,

Anatolij

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

Jason Gunthorpe — 2013-05-24T17:33:06


I disagree. The manul is very clear how PSC1 must be set for proper
operation. Clk125BypassEn bit is used only for loopback testing, it
should never set for driver operation. Similarly PortReset must be
cleared for driver operation.

It is always safe for the driver to clear these bits, if it knows they
are available.  In fact, I would argue the driver should always clear
these bits so that the bootloader isn't relied on to do it. It doesn't
matter if the SOC errantly sets the bit or not, it can *always* be
safely cleared.

Further, I compared my 88F6282/88F6283 manual against the public
88F6180/88F619x/88F6281 spec and confirmed that the PSC1 layout is the
same.

So all of these SOC's can share a driver compatible string.

AFAICT the only reason the driver doesn't touch PSC1 today is because
the PSC1 was introduced in a later IP revision and its presence isn't
auto-detectable.

The last bit of the puzzle to get bootloader independence on kirkwood
is to encode the phy interface type (GMII/RGMII/BASE-X) in

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

Sebastian Hesselbarth — 2013-05-24T17:25:11

Don't get me wrong. I want mv643xx_eth DT or even platform_data to
evolve to a fully self configured driver not depending on proper u-boot
setup at all.

But I don't want to go that road now and I wonder if it might be safer
for us (and PPC guys) if we start mv643xx_eth over from scratch one day.

For this patch set, I want a basic DT binding that works. Patching the
driver to play with kirkwood loosing the MAC and other important
registers is not my main concern here. If clearing that one bit doesn't
help for all kirkwood boards, I'd rather leave the non-gating
workaround.

mv643xx_eth not knowing DT for ARM is stalling last important bits for
Orion SoCs. I want this to go in first as with David another maintainer
is involved.

Sebastian

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

Russell King - ARM Linux — 2013-05-24T17:13:00

Then you're into scenarios like I have with my laptop, where - those
of you who check the nightly build results will have noticed - one
of my serial ports doesn't always exist.  That's because the ACPI data
in the BIOS is *wrong*.  It reports that it has been enabled when it
hasn't, and the disassembled byte code is at fault here.

The fix?  God knows.  As far as I'm concerned as a user, or even as an
OS developer, it's unfixable without getting the ACPI data structures
changed, and that's not something I can do.

Do you really want that on ARM?  Given the fiasco with the location of
the registers, are you sure you want to place more trust in that
direction?  Does it give you a warm fuzzy feeling to know that you
might have to work out some way to patch vendor supplied bytecode?

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

Jason Cooper — 2013-05-24T17:03:35

Do you have a board set up for testing you could try Sebastian's
forthcoming series on (with "marvell,kirkwood-eth")?

thx,

Jason.

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

Jason Cooper — 2013-05-24T17:01:25

This is the first I've heard this rant.  :(

To that end, I agree with you.  My frustration boiled down to trying to
predict the future, which is futile. :-P

For our scenario, once we can confirm our least popular kirkwood
variant, the 6282, behaves the same as we've seen so far, then
"marvell,kirkwood-eth" is fine by me.


Agree.


shudder.  I like embedded systems because the *don't* have a bios.

thx,

Jason.

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

Jason Cooper — 2013-05-24T16:53:38

Sorry, yep, one or the other.


For a second, I read this as "tsk tsk tsk..." ;-)


Okay, as I mentioned to Jason, I would like to test 6282 before we
settle on this path.  Other than that, I'm fine with it.


Good point, but if the eth can be gated to save power, we shouldn't
limit the user's ability just because the SoC is primarily in NAS's.

thx,

Jason.

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

Jason Cooper — 2013-05-24T16:46:36

I'm not keen on it because we don't have a document saying "All kirkwood
SoCs need PSC1 set to X after reset."  We know it, but have we tested
the 6282?

That being said, if "marvell,kirkwood-eth" is the best we can do for
now, I'm all for it.  I would just like to be reasonably certain that
the binding we are creating doesn't lock us into a difficult decision
later.


Agreed.


After glancing a LinusW's email, I'm thinking this isn't the correct
path.  I'll write more in my response to him.

thx,

Jason.

[PATCH v3 00/11] uaccess: better might_sleep/might_fault behavior

Michael S. Tsirkin — 2013-05-24T14:17:32

This improves the might_fault annotations used
by uaccess routines:

1. The only reason uaccess routines might sleep
   is if they fault. Make this explicit for
   all architectures.
2. a voluntary preempt point in uaccess functions
   means compiler can't inline them efficiently,
   this breaks assumptions that they are very
   fast and small that e.g. net code seems to make.
   remove this preempt point so behaviour
   matches what callers assume.
3. Accesses (e.g through socket ops) to kernel memory
   with KERNEL_DS like net/sunrpc does will never sleep.
   Remove an unconditinal might_sleep in the inline
   might_fault in kernel.h
   (used when PROVE_LOCKING is not set).
4. Accesses with pagefault_disable return EFAULT
   but won't cause caller to sleep.
   Check for that and avoid might_sleep when
   PROVE_LOCKING is set.

I'd like these changes to go in for 3.11:
besides a general benefit of improved
consistency and performance, I would also like them
for the vhost driver where we want to call socket

[PATCH v3 07/11] powerpc: uaccess s/might_sleep/might_fault/

Michael S. Tsirkin — 2013-05-24T14:18:20

The only reason uaccess routines might sleep
is if they fault. Make this explicit.

Arnd Bergmann suggested that the following code
if (!is_kernel_addr((unsigned long)__pu_addr))
might_fault();
can be further simplified by adding a version of might_fault
that includes the kernel addr check.

Will be considered as a further optimization in future.

Signed-off-by: Michael S. Tsirkin <mst< at >redhat.com>
---
 arch/powerpc/include/asm/uaccess.h | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 4db4959..9485b43 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
< at >< at > -178,7 +178,7 < at >< at > do {\
 long __pu_err;\
 __typeof__(*(ptr)) __user *__pu_addr = (ptr);\
 if (!is_kernel_addr((unsigned long)__pu_addr))\
-might_sleep();\
+might_fault();\
 __chk_user_ptr(ptr);\
 __put_user_size((x), __pu_addr, (size), __pu_err);\
 __pu_err;

Re: [PATCH 3/3] powerpc/vfio: Enable on pSeries platform

Alex Williamson — 2013-05-24T14:03:37

Acked-by: Alex Williamson <alex.williamson< at >redhat.com>

Re: [PATCH 2/3] powerpc/vfio: Implement IOMMU driver for VFIO

Alex Williamson — 2013-05-24T14:03:07

Acked-by: Alex Williamson <alex.williamson< at >redhat.com>

Re: [PATCH v2 07/10] powerpc: uaccess s/might_sleep/might_fault/

Arnd Bergmann — 2013-05-24T13:30:20

Yes, makes sense.

Arnd

Re: [PATCH v2 07/10] powerpc: uaccess s/might_sleep/might_fault/

Michael S. Tsirkin — 2013-05-24T13:11:04

OK I spoke too fast: I found this:

    powerpc: Fix incorrect might_sleep in __get_user/__put_user on kernel addresses
    
    We have a case where __get_user and __put_user can validly be used
    on kernel addresses in interrupt context - namely, the alignment
    exception handler, as our get/put_unaligned just do a single access
    and rely on the alignment exception handler to fix things up in the
    rare cases where the cpu can't handle it in hardware.  Thus we can
    get alignment exceptions in the network stack at interrupt level.
    The alignment exception handler does a __get_user to read the
    instruction and blows up in might_sleep().
    
    Since a __get_user on a kernel address won't actually ever sleep,
    this makes the might_sleep conditional on the address being less
    than PAGE_OFFSET.
    
    Signed-off-by: Paul Mackerras <paulus< at >samba.org>

So this won't work, unless we add the is_kernel_addr check
to might_fault. That will become possible on top of this patchset
but let's

Re: [PATCH v2 07/10] powerpc: uaccess s/might_sleep/might_fault/

Michael S. Tsirkin — 2013-05-24T13:00:32

Well not exactly. The non-inline might_fault checks the
current segment, not the address.
I'm guessing this is trying to do the same just without
pulling in segment_eq, but I'd like a confirmation
from more PPC maintainers.

Guys would you ack

- if (!is_kernel_addr((unsigned long)__pu_addr))
- might_fault();
+ might_fault();

on top of this patch?

Also, any volunteer to test this (not just test-build)?

Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs

Linus Walleij — 2013-05-24T11:03:25

On Fri, May 24, 2013 at 12:40 AM, Sebastian Hesselbarth
<sebastian.hesselbarth< at >gmail.com> wrote:


One of the things I've been ranting about lately is that Linux
subsystem maintainers have become de-facto device tree
standard commite chairs. :-(

So to the actual question:

In general I think we need to draw a line and define what we
mean with "describing the hardware" in a device tree.

We have some consensus:
- <reg> properties to describe regsiter BASE offset in physical
  memory and size.
- Resources like IRQ, DMA channel, regulator, GPIO pin control
  handles, are passed using <&ampersand> notation.

And so it goes on.

When it comes to defining different registers and their individual
bits and the meaning of these and/or default values, I personally
think that is making things harder for developers rather than
simplifying things. I know that pinctrl-single is anyway doing this
and I was talked into accepting it under circumstances where
developers are being passed opaque machine-generated
data that wou

[git pull] Please pull powerpc.git merge branch

Benjamin Herrenschmidt — 2013-05-24T09:41:30

Hi Linus !

Here are a few more powerpc fixes for 3.10. Some more P8 related
bits, a bunch of fixes for our P7+/P8 HW crypto drivers, some added
workarounds for those radeons that don't do proper 64-bit MSIs and
a couple of other trivialities by myself.

Cheers,
Ben.

The following changes since commit 519fe2ecb755b875d9814cdda19778c2e88c6901:

  Merge branch 'leds-fixes-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds (2013-05-21 11:41:07 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge

for you to fetch changes up to f1dd153121dcb872ae6cba8d52bec97519eb7d97:

  powerpc/pseries: Make 32-bit MSI quirk work on systems lacking firmware support (2013-05-24 18:16:54 +1000)

----------------------------------------------------------------
Benjamin Herrenschmidt (5):
      powerpc: Fix TLB cleanup at boot on POWER8
      powerpc/pci: Fix bogus message at boot about empty memory resources
      powerpc/powernv: Fix con