gmane.linux.ports.ppc.embedded

Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS

Anthony Foiani — 2012-05-26T06:53:20


My impression is that the simplest fix is Adrian's patch, which simply
keys off CONFIG_MPC831x_RDB.  It's not very satisfying, but I'll take
"working" vs. "rare lockups at boot".

If there is some other defining characteristic of boards that require
this patch, then a simple KConfig snippit with a description would be
even better.  Without any KConfig support for this variable, I lost it
even after using an oldconfig from my vendor.

(Or, if it was preserved, I might have removed it when trying to
optimize the kernel for support for our hardware, and I had no way of
knowing that the MPC8315_DS had any impact on my system at all...)

If it's actually a CPU/SOC-level problem, then an ideal situation
would conditionalize the fix by examining CPU version or stepping.
That would allow us to get rid of the config variable entirely.


Possibly.  :)

I only saw the problem (failure to SATA handshake at 3Gbps?) very
rarely, maybe one in 100 warm boot cycles.

I've added the patch to my current project, and have not

Re: [git pull] signals, the first series

Al Viro — 2012-05-25T21:48:45

Grr...  *Another* missing prereq for task_work_add() series, this time on
ppc64.  Could somebody familiar with that beast take a look at this and
tell if the change is sane?  What we want is
r0 = r3 & MSR_PR ?
_TIF_NEED_RESCHED | _TIF_NOTIFY_RESUME | _TIF_SIGPENDING :
_TIF_NEED_RESCHED;
and when Roland re-added NOTIFY_RESUME he'd missed that hack (non-PREEMPT
variant and 32bit code all just check _TIF_USER_WORK_MASK, so updating
it had been enough in those cases).  I don't have the hardware in
question; the same instructions in userland on ppc32 box produce the
right value.  Unless NAKed I'm going to throw that one into the second
pull request from signal.git, so if anyone has objections, please yell.

I'll gladly replace that with better solution if one shows up (or, better
yet, goes via ppc tree).  AFAICS the diff below should work, but whether
it's the best variant or not... No idea.

Back to massaging VFS queue for pull...

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.

Re: [PATCH] gianfar:don't add FCB length to hard_header_len

Paul Gortmaker — 2012-05-25T20:04:51

Can't get much easier than using one of these:

http://www.kernel.org/pub/tools/crosstool/

Just untar, export PATH ARCH CROSS_COMPILE and go.

Can't get much lazier than that. Great to have around.

Paul.

Re: [PATCH] gianfar:don't add FCB length to hard_header_len

Joe Perches — 2012-05-25T19:51:05

No cross compiler either, and I'm lazy 'bout that...

cheers, Joe

Re: Oops with Radeon/Uninorth on Maple

Alex Deucher — 2012-05-25T15:06:23

On Thu, May 24, 2012 at 2:18 AM, Dmitry Eremin-Solenikov
<dmitry_eremin< at >mentor.com> wrote:

For future reference, you can disable AGP by loading radeon with the
agpmode parameter set to -1, e.g., radeon.agpmode=-1

No need to edit the source.

Alex

Re: [PATCH] gianfar:don't add FCB length to hard_header_len

Paul Gortmaker — 2012-05-25T15:58:20


There is no card.  The gianfar is a SOC for freescale 83xx, 85xx, 86xx
CPUs.  If need be, I can test just as I did for your name overrun fix
in commit 0015e551e.

But you really shouldn't need the hardware to validate this kind of
patch anyways -- aside from your code flow change in the irq routine of
gianfar_ptp, you should have been simply able to check for object file
equivalence before and after your change.

Paul.


[...]

Re: pread() and pwrite() system calls

Gabriel Paubert — 2012-05-25T16:45:51

Huh? Won't fly, r0 is used for the system call number!

On the other hand, I believed PPC had no problems passing
up to 8 32 bit arguments in registers (r3 to r10), but
I may be confusing with the standard ABI for function calls.

Hmm, a quick look at kernel/entry_32.s shows that it should 
be able to use at least r3 to r8, which should be sufficient.

I think that it is an uClibc problem.

Gabriel

pread() and pwrite() system calls

David Laight — 2012-05-25T13:29:06

We have a system with linux 2.6.32 and the somewhat archaic
uClibc 0.9.27 (but I'm not sure the current version is
any better, and I think there are binary compatibility
if we update).

I've just discovered that pread() is 'implemented'
by using 3 lseek() system calls and read().
(the same is true for the 64bit versions).

I thought that pread() was supposed to be atomic
(so usable concurrently by multiple threads) which
means that this implementation is completely broken.

I've not looked to see what glibc does.

I can see that part of the problem is the alignment
of the 64bit value on the argument list of syscall()
(when the register save area is cast to a sycall
argument structure).
But it also looks as though the uClibc syscall()
stub can only pass 5 arguments in registers, and
pread() (with an aligned 64bit offset) requires 6.

The ucLibc source seems to be predicated by __NR_pread,
but if that were defined it would try to call
__syscall_pread() and I can't find that anywhere.

A special pread/pwrite as

Re: module loading issue/flaw in busy memory situation?

Steffen Rumler — 2012-05-25T07:56:07

Hi,

The basic question is, has the GPR r11 a dedicated function (to point to the previous stack frame)
or is it still a volatile GPR, according to EABI definition ?
In the case of a dedicated function was assigned, the trampoline code generation in

     arch/powerpc/kernel/module_32.c

must be corrected. I'd suggest to use r12 instead of r11, in this case.

Best Regards
Steffen

Re: [PATCH v3 1/2] powerpc/PCI: move DMA & IRQ init to device_add() notification path

Benjamin Herrenschmidt — 2012-05-25T03:38:25

I'm not that worried about cardbus ... in fact I wouldn't be surprised
if it's already somewhat broken, I haven't tested it in a long time...

I'm more worried about basic functionality and expectations about when
things happen during boot vs. platform hacks, that and pseries specific
kind of hotplug which can be a bit odd.

Cheers,
Ben.

Re: [PATCH v3 1/2] powerpc/PCI: move DMA & IRQ init to device_add() notification path

Bjorn Helgaas — 2012-05-25T03:08:24

On Thu, May 24, 2012 at 9:00 PM, Benjamin Herrenschmidt
<benh< at >kernel.crashing.org> wrote:

OK.  Are you worried about cardbus in particular?

This is headed for the 3.6, not 3.5, so we should have plenty of time.
 As soon as everything for the current merge window gets merged and
-next is ready for the next batch, I'll put this in there.

Re: [PATCH v3 1/2] powerpc/PCI: move DMA & IRQ init to device_add() notification path

Benjamin Herrenschmidt — 2012-05-25T03:00:11

Hrm. That will require a good deal of testing... Unfortunately I'm out
for a few weeks getting some surgery and then recovering...

Our PCI code has ancient roots and I wouldn't be surprised if that
change breaks subtle assumptions made here or there, we'd need to test
at least on a good range of macs and ibm hotplug stuff.

Cheers,
Ben.

Re: Oops with Radeon/Uninorth on Maple

Benjamin Herrenschmidt — 2012-05-25T00:59:55

Machine Check probably means that there's a HW configuration issue,
possibly something missing in the initialization of the AGP hardware to
make it actually work.

Cheers,
Ben.

module loading issue/flaw in busy memory situation?

Wrobel Heinz-R39252 — 2012-05-24T20:05:19

Hi,

let's assume a module gets loaded into an already busy system, and the ".init.text" section with the __init function gets loaded into one memory region, and the normal ".text" section gets loaded into a totally different memory region.
Now assume that both regions are >32MB apart in addressing, so that a call from the __init .init.text function to any function in .text requires a trampoline as set up by the do_plt_call() function in arch/kernel/module*.c
So far so good for user code.

Now assume that the __init function is not trivial and will require register save/restore functions in prologue/epilogue with such calls generated by gcc, e.g., the __init function calls _rest32gpr_28_x() in the epilogue. This restore functions however is in the .text section due to the static link of the normal libs.

Now we have the __init function calling the trampoline, which is destroying r11. The trampoline is then jumping to the register restore function which relies on r11 still being intact, which it now isn't any

Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.

David Daney — 2012-05-24T19:19:53

You will have to debug it and find out why the device match is failing, 
then fix it.

David Daney

Re: [PATCH] gianfar:don't add FCB length to hard_header_len

Jan Ceuleers — 2012-05-24T18:03:13

Thanks Joe.

I also don't have the card; the kinds of changes I was proposing to make
are code-neutral, whose correctness I was intending to prove by a binary
compare of the before-and-after .o.

Still happy to do that taking your contribution as a starting point.

Thanks, Jan

Re: [PATCH] gianfar:don't add FCB length to hard_header_len

Jan Ceuleers — 2012-05-24T15:04:34

May I give that a go?

Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.

Timur Tabi — 2012-05-24T19:03:33


Ok, let me give you some background.  We actually already have MDIO muxing
code in-house, but it's different from yours.  So now I'm rewriting it to
use your design instead.

So our current code looks for "virtual MDIO nodes", and we call
mdiobus_alloc() and then of_mdiobus_register().  I think this is what I'm
missing now.

I just don't know what to do next.  Part of the problem is that I don't
have much experience with MDIO drivers.


Ok, that makes sense.


I only gave you part of the device tree.  Here's my mdio mux node:

mdio-mux {
compatible = "mdio-mux-gpio";
gpios = <&gpio0 0 0>, <&gpio0 1 0>;
mdio-parent-bus = <&mdio0>;
#address-cells = <1>;
#size-cells = <0>;

mdio< at >2 {
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;

phy21: ethernet-phy< at >1 {
reg = <1>;
//compatible = "marvell,88e1149r", "ethernet-phy-ieee802.3-c22";
marvell,reg-init = <3 0x10 0 0x5777>,
<3 0x11 0 0x00aa>,
<3 0x12 0 0x4105>,
<3 0x13 0 0x0a60>;
interrupt-parent = <&gpio0>;

Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.

David Daney — 2012-05-24T18:50:26

Well, the MDIO bus must have an associated device tree node.

For my OCTEON code, the MDIO bus device is created as a result of the 
call to of_platform_bus_probe(), which takes care of filling in all the 
device tree nodes of the devices it finds and creates.


For starters, I do not see any compatible properties that would allow 
the proper drivers to be bound to anything.

Also I see no MDIO mux node there, so it is unclear why you are even 
asking these questions.

David Daney

Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.

Timur Tabi — 2012-05-24T18:28:40

I'm till have trouble understanding all this.  I'm just hacking things up
in order to help me understand it, but it's a slow and painful process.

This call in mdio_mux_init() is failing:

parent_bus = of_mdio_find_bus(parent_bus_node);

It returns NULL.  Here is my MDIO node:

fman0: fman< at >400000 {
enet0: ethernet< at >e0000 {
tbi-handle = <&tbi0>;
phy-handle = <&phy0>;
phy-connection-type = "sgmii";
};

mdio0: mdio< at >e1120 {
gpios = <&gpio0 0 0
 &gpio0 1 0>;

tbi0: tbi-phy< at >8 {
reg = <0x8>;
device_type = "tbi-phy";
};

phy0: ethernet-phy< at >1c {
reg = <0x1c>;
};
};
};

What am I missing?  What do I need to do in order to get
of_mdio_find_bus() to return a real value?

Re: [PATCH] gianfar:don't add FCB length to hard_header_len

Joe Perches — 2012-05-24T16:16:50

I have scripts that automate most of this.
I don't have the card though.

Maybe this is a starting point?
It doesn't fix most 80 column warnings.

 drivers/net/ethernet/freescale/gianfar.c         |  299 +++++++++++-----------
 drivers/net/ethernet/freescale/gianfar_ethtool.c |  131 +++++-----
 drivers/net/ethernet/freescale/gianfar_ptp.c     |    8 +-
 drivers/net/ethernet/freescale/gianfar_sysfs.c   |    2 +-
 4 files changed, 225 insertions(+), 215 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 1adb024..b1985aa 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
< at >< at > -87,10 +87,10 < at >< at >
 #include <linux/in.h>
 #include <linux/net_tstamp.h>
 
-#include <asm/io.h>
+#include <linux/io.h>
 #include <asm/reg.h>
 #include <asm/irq.h>
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
 #include <linux/module.h>
 #include <linux/dma-mapping.h>
 #include <linux/crc32.h>
< at >< at > -114,7 +114,7 < at >< at > static v