* Re: [PATCH] QE USB Host Integration for MPC832x
From: Anton Vorontsov @ 2009-04-02 18:36 UTC (permalink / raw)
To: Marcel Ziswiler; +Cc: linuxppc-dev, linux-kernel, Timur Tabi
In-Reply-To: <20090402183357.GA29050@oksana.dev.rtsoft.ru>
On Thu, Apr 02, 2009 at 10:33:57PM +0400, Anton Vorontsov wrote:
[...]
> > + compatible = "fsl,mpc8360-qe-usb",
>
> Ditto. No need for mpc8360 compatible.
Oh, I was wrong. fsl_qe_udc driver uses mpc8360 compatible for
matching, so you can't remove it. :-/
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] QE USB Host Integration for MPC832x
From: Anton Vorontsov @ 2009-04-02 18:33 UTC (permalink / raw)
To: Marcel Ziswiler; +Cc: linuxppc-dev, linux-kernel, Timur Tabi
In-Reply-To: <1238622396-9768-1-git-send-email-marcel@ziswiler.com>
[ Cc'ing linuxppc-dev and Timur Tabi ]
On Wed, Apr 01, 2009 at 11:46:36PM +0200, Marcel Ziswiler wrote:
> Open issues:
> - MPC832x_MDS seems to lie about BCSR12_USMODE bit.
> - How to use qe_setbrg() with an external clock pin? Hard-coded for now.
> - How to properly allocate USB pram on MPC832x as standard layout won't work.
> - Detects USB device plugged in but then hangs.
>
> Please CC me personally when answering/commenting my posting, thanks.
Wow, considering erratas, I'm quite surprised that QE USB works on
MPC832x. Well, I see that the USB hangs after all... Does it "work"
with QE microcode update or bare MPC832x can "work" too?
FWIW, I don't see any USB microcode updates on Freescale site
(http://opensource.freescale.com/firmware/), but I recalling some
QE USB firmwares in FSL BSPs...
Some comments down below.
> Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
> ---
> arch/powerpc/boot/dts/mpc832x_mds.dts | 74 ++++-
> arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 361 ++++++++++++-----------
> arch/powerpc/platforms/83xx/Kconfig | 1 +
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 66 ++++
> arch/powerpc/sysdev/qe_lib/qe.c | 10 +-
> drivers/usb/host/fhci-hcd.c | 9 +
> 6 files changed, 336 insertions(+), 185 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts b/arch/powerpc/boot/dts/mpc832x_mds.dts
> index 57c595b..f306edf 100644
> --- a/arch/powerpc/boot/dts/mpc832x_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
> @@ -59,9 +59,36 @@
> reg = <0x00000000 0x08000000>;
> };
>
> - bcsr@f8000000 {
> - compatible = "fsl,mpc8323mds-bcsr";
> - reg = <0xf8000000 0x8000>;
> + localbus@e0005000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8323-localbus", "fsl,pq2pro-localbus",
> + "simple-bus";
> + reg = <0xe0005000 0xd8>;
> + ranges = <0 0 0xfe000000 0x02000000
> + 1 0 0xf8000000 0x00008000>;
> +
> + flash@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 0x2000000>;
> + bank-width = <2>;
> + device-width = <1>;
> + };
> +
> + bcsr@1,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,mpc8323mds-bcsr";
> + reg = <1 0 0x8000>;
> + ranges = <0 1 0 0x8000>;
> +
> + bcsr12: gpio-controller@c {
> + #gpio-cells = <2>;
> + compatible = "fsl,mpc8323mds-bcsr-gpio";
> + reg = <0xc 1>;
> + gpio-controller;
> + };
> + };
> };
>
> soc8323@e0000000 {
> @@ -238,6 +265,14 @@
> };
>
> };
> +
> + qe_pio_a: gpio-controller@1400 {
> + #gpio-cells = <2>;
> + compatible = "fsl,mpc8360-qe-pario-bank",
fsl,mpc8360-qe-pario-bank doesn't fit here, just delete it.
> + "fsl,mpc8323-qe-pario-bank";
> + reg = <0x1400 0x18>;
> + gpio-controller;
> + };
> };
>
> qe@e0100000 {
> @@ -282,11 +317,25 @@
> };
>
> usb@6c0 {
> - compatible = "qe_udc";
> - reg = <0x6c0 0x40 0x8b00 0x100>;
> - interrupts = <11>;
> + compatible = "fsl,mpc8360-qe-usb",
Ditto. No need for mpc8360 compatible.
> + "fsl,mpc8323-qe-usb";
> + /* QUICC Engine Parameter RAM Base Addresses (Suggested
> + Value for User Configuration) Table 19-2 page 778 */
> + reg = <0x6c0 0x40 0x700 0x100>;
> + interrupts = <11>; /* Encoding the Interrupt Vector
> + Table 18-12 page 760 */
> interrupt-parent = <&qeic>;
> - mode = "slave";
> + /* Clock Source Options - Internal Clock Generators
> + Table 20-2 page 804 */
> + fsl,fullspeed-clock = "brg10";
> + fsl,lowspeed-clock = "brg10";
> + gpios = <&qe_pio_a 8 0 /* USBOE */
> + &qe_pio_a 1 0 /* USBTXP */
> + &qe_pio_a 0 0 /* USBTXN */
> + &qe_pio_a 4 0 /* USBRXP */
> + &qe_pio_a 5 0 /* USBRXN */
> + &bcsr12 5 0 /* SPEED */
> + &bcsr12 4 1>; /* POWER */
> };
>
> enet0: ucc@2200 {
> @@ -335,7 +384,6 @@
> pio-handle = < &pio5 >;
> };
>
> -
> mdio@2320 {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -366,6 +414,16 @@
> interrupts = <32 0x8 33 0x8>; //high:32 low:33
> interrupt-parent = <&ipic>;
> };
> +
> + timer@440 {
> + compatible = "fsl,mpc8323-qe-gtm",
> + "fsl,qe-gtm", "fsl,gtm";
> + reg = <0x440 0x40>;
> + interrupts = <12 13 14 15>;
> + interrupt-parent = <&qeic>;
> + /* filled by u-boot */
> + clock-frequency = <0>;
> + };
> };
>
> pci0: pci@e0008500 {
[...defconfig changes snipped..]
> diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
> index 83c664a..68a2aeb 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -20,6 +20,7 @@ config MPC832x_MDS
> bool "Freescale MPC832x MDS"
> select DEFAULT_UIMAGE
> select PPC_MPC832x
> + select FSL_LBC
Unless you use UPM NAND driver you don't need this.
> help
> This option enables support for the MPC832x MDS evaluation board.
>
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> index ec0b401..e9baae5 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> @@ -12,6 +12,7 @@
>
> #include <linux/stddef.h>
> #include <linux/kernel.h>
> +#include <linux/compiler.h>
> #include <linux/init.h>
> #include <linux/errno.h>
> #include <linux/reboot.h>
> @@ -37,6 +38,7 @@
> #include <asm/udbg.h>
> #include <sysdev/fsl_soc.h>
> #include <sysdev/fsl_pci.h>
> +#include <sysdev/simple_gpio.h>
> #include <asm/qe.h>
> #include <asm/qe_ic.h>
>
> @@ -86,6 +88,16 @@ static void __init mpc832x_sys_setup_arch(void)
>
> for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
> par_io_of_config(np);
> +#ifdef CONFIG_QE_USB
> + /* Must fixup Par IO before QE GPIO chips are registered. */
> + par_io_config_pin(0, 8, 1, 0, 3, 0); /* PA8 for USBOE */
> + par_io_config_pin(0, 1, 1, 0, 3, 0); /* PA1 for USBTP */
> + par_io_config_pin(0, 0, 1, 0, 3, 0); /* PA0 for USBTN */
> + par_io_config_pin(0, 6, 2, 0, 3, 0); /* PA6 for USBRXD */
> + par_io_config_pin(0, 4, 2, 1, 3, 0); /* PA4 for USBRP */
> + par_io_config_pin(0, 5, 2, 1, 3, 0); /* PA5 for USBRN */
> + par_io_config_pin(0, 14, 2, 0, 1, 0); /* PA14 for BRG10/CLK11*/
> +#endif /* CONFIG_QE_USB */
> }
>
> if ((np = of_find_compatible_node(NULL, "network", "ucc_geth"))
> @@ -119,6 +131,60 @@ static int __init mpc832x_declare_of_platform_devices(void)
> }
> machine_device_initcall(mpc832x_mds, mpc832x_declare_of_platform_devices);
>
> +#ifdef CONFIG_QE_USB
> +static int __init mpc832x_usb_cfg(void)
> +{
> + u8 __iomem *bcsr;
> + struct device_node *np;
> + const char *mode;
> + int ret = 0;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,mpc8323mds-bcsr");
> + if (!np)
> + return -ENODEV;
> +
> + bcsr = of_iomap(np, 0);
> + of_node_put(np);
> + if (!bcsr)
> + return -ENOMEM;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,mpc8323-qe-usb");
> + if (!np) {
> + ret = -ENODEV;
> + goto err;
> + }
> +
> +#define BCSR12_USBMASK 0x0f
> +#define BCSR12_nUSBEN 0x08 /* 1 - Disable, 0 - Enable */
> +#define BCSR12_USBSPEED 0x04 /* 1 - Full, 0 - Low */
> +#define BCSR12_USBMODE 0x02 /* 1 - Host, 0 - Function */
> +#define BCSR12_nUSBVCC 0x01 /* 1 - gets VBUS, 0 - supplies VBUS */
> +
> + clrsetbits_8(&bcsr[12], BCSR12_USBMASK, BCSR12_USBSPEED);
> +
> + mode = of_get_property(np, "mode", NULL);
> + if (mode && !strcmp(mode, "peripheral")) {
> + setbits8(&bcsr[12], BCSR12_nUSBVCC);
> + qe_usb_clock_set(QE_CLK21, 48000000);
I see that the actual USB clock input is BRG10, while here you
specify CLK21...
> + } else {
> +//Userguide lies about this!
> +// setbits8(&bcsr[12], BCSR12_USBMODE);
Please use canonical comments, i.e.
/*
* Userguide lies about this!
* setbits8(&bcsr[12], BCSR12_USBMODE);
*/
> + /*
> + * The BCSR GPIOs are used to control power and
> + * speed of the USB transceiver. This is needed for
> + * the USB Host only.
> + */
> + simple_gpiochip_init("fsl,mpc8323mds-bcsr-gpio");
> + }
> +
> + of_node_put(np);
> +err:
> + iounmap(bcsr);
> + return ret;
> +}
> +machine_arch_initcall(mpc832x_mds, mpc832x_usb_cfg);
> +#endif /* CONFIG_QE_USB */
> +
> static void __init mpc832x_sys_init_IRQ(void)
> {
> struct device_node *np;
> diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
> index 01bce37..3342f77 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -200,7 +200,11 @@ int qe_setbrg(enum qe_clock brg, unsigned int rate, unsigned int multiplier)
> if ((brg < QE_BRG1) || (brg > QE_BRG16))
> return -EINVAL;
>
> - divisor = qe_get_brg_clk() / (rate * multiplier);
> +#define USB_CLOCK 48000000
> + if(brg == QE_BRG10)
> + divisor = USB_CLOCK / (rate * multiplier);
> + else
> + divisor = qe_get_brg_clk() / (rate * multiplier);
[...]
> +#define BRGC_EXTC_CLK11 0x00004000
> + if(brg == QE_BRG10)
> + tempval |= BRGC_EXTC_CLK11;
> +
> out_be32(&qe_immr->brg.brgc[brg - QE_BRG1], tempval);
Yes, these two changes don't look good, but I'm not sure how to
make them better. Maybe Timur would suggest.
> return 0;
> diff --git a/drivers/usb/host/fhci-hcd.c b/drivers/usb/host/fhci-hcd.c
> index ba622cc..ba26d19 100644
> --- a/drivers/usb/host/fhci-hcd.c
> +++ b/drivers/usb/host/fhci-hcd.c
> @@ -620,12 +620,21 @@ static int __devinit of_fhci_probe(struct of_device *ofdev,
> goto err_pram;
> }
>
> +#ifdef CONFIG_MPC832x_MDS
> + pram_addr = qe_muram_alloc(FHCI_PRAM_SIZE, 64);
> +#else
> pram_addr = cpm_muram_alloc_fixed(iprop[2], FHCI_PRAM_SIZE);
> +#endif
Default (0x8b00) pram location doesn't work on MPC832x? Let's look
into reference manual...
"As the default values are not in the first 16KB memory space of
the Multi-user RAM, the user has to modify the page addresses
using the assign page host command as part of the initialization
process."
Hm.. So MPC832x has only 16 KB of muram. :-/
I just checked on MPC8360 board: dynamic allocation + assign page
works here. So, please don't introduce the #ifdefs, just replace
the fixed allocations with dynamic.
Ah, and don't use "qe_muram_alloc", use cpm_ prefix (qe_ and cpm_
muram functions are identical).
> if (IS_ERR_VALUE(pram_addr)) {
> dev_err(dev, "failed to allocate usb pram\n");
> ret = -ENOMEM;
> goto err_pram;
> }
> +#ifdef CONFIG_MPC832x_MDS
And simply remove this #ifdef.
> + /* Section 19.3.1.1.1 Assign page Command */
Please remove this comment. Section "19.3.1.1.1" may point
to some completely unrelated stuff if we look into RM for
another processor.
> + qe_issue_cmd(QE_ASSIGN_PAGE_TO_DEVICE, QE_CR_SUBBLOCK_USB,
> + QE_CR_PROTOCOL_UNSPECIFIED, pram_addr);
> +#endif
> fhci->pram = cpm_muram_addr(pram_addr);
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29
From: Chris Friesen @ 2009-04-02 17:53 UTC (permalink / raw)
To: Hugh Dickins; +Cc: peterz, linux-kernel, linuxppc-dev, akpm
In-Reply-To: <Pine.LNX.4.64.0904021324070.16207@blonde.anvils>
Hugh Dickins wrote:
> On Thu, 2 Apr 2009, Michael Ellerman wrote:
>> On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
>>> Resending due to lack of response to original post.
>> Hi Chris,
>>
>> You'll probably get a more useful response on lkml. You CC'ed
>> linux-kernel-owner originally :)
>
> Thanks.
Thanks from me too. (Oops.)
>>> I was validating some code dealing with /proc/<pid>/maps on 2.6.29 and
>>> was surprised when it failed. It turns out that at least on my ppc64 G5
>>> machine the offset value for the last entry is strange--it shows up as a
>>> 64-bit value even though the process itself is only 32-bit.
>>>
>>> This behaviour also shows up in 2.6.25, but doesn't in 2.6.14. I
>>> haven't yet tested anything else in between.
>>>
>>> [cfriesen@localhost cfriesen]$ cat /proc/self/maps
>>> 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
>>> 0fe70000-0ffbf000 r-xp 00000000 08:03 4312393 /lib/tls/libc-2.3.3.so
>>> 0ffbf000-0ffc0000 ---p 0014f000 08:03 4312393 /lib/tls/libc-2.3.3.so
>>> 0ffc0000-0ffc2000 r--p 00150000 08:03 4312393 /lib/tls/libc-2.3.3.so
>>> 0ffc2000-0ffc6000 rwxp 00152000 08:03 4312393 /lib/tls/libc-2.3.3.so
>>> 0ffc6000-0ffc8000 rwxp 0ffc6000 00:00 0
>>> 0ffd0000-0ffec000 r-xp 00000000 08:03 4309011 /lib/ld-2.3.3.so
>>> 0fff0000-0fff1000 r--p 00020000 08:03 4309011 /lib/ld-2.3.3.so
>>> 0fff1000-0fff2000 rwxp 00021000 08:03 4309011 /lib/ld-2.3.3.so
>>> 10000000-10004000 r-xp 00000000 08:03 917536 /bin/cat
>>> 10013000-10015000 rwxp 00003000 08:03 917536 /bin/cat
>>> 10015000-10036000 rwxp 10015000 00:00 0 [heap]
>>> f7deb000-f7feb000 r--p 00000000 08:03 2560322
>>> /usr/lib/locale/locale-archive
>>> f7feb000-f7fec000 rw-p f7feb000 00:00 0
>>> ffe6d000-ffe82000 rw-p ffffffeb000 00:00 0 [stack]
> Chris isn't the first to be concerned by that: there's a patch in
> -mm which just shows 0 instead of anon vm_pgoff in /proc/<pid>/maps
> output. That patch is on akpm's list for 2.6.30 merge, but I think
> hasn't gone to Linus yet: expect it in a later batch.
Alternately, what about just making the offset for the stack match the
starting address of the VMA? That way it would look the same as other
anonymous areas, and as a bonus would look the same as previous
releases. Arguably, /proc/<pid>/maps should count as userspace-visible API.
Chris
^ permalink raw reply
* [PATCH] powerpc: Correct dependency of KEXEC (was: Re: kexec: proc/device-tree/chosen/linux,kernel-end: No such file or directory)
From: Geert Uytterhoeven @ 2009-04-02 16:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux/PPC Development
In-Reply-To: <alpine.LRH.2.00.0903311808310.32461@vixen.sonytel.be>
On Tue, 31 Mar 2009, Geert Uytterhoeven wrote:
> With today's kernel, I can no longer kexec any kernel on PS3:
>
> | /proc/device-tree/chosen/linux,kernel-end: No such file or directory
> | Could not get memory layout
>
> Today's bad version: 15f7176eb1cccec0a332541285ee752b935c1c85
> Yesterday's good version: 0d34fb8e93ceba7b6dad0062dbb4a0813bacd75b
>
> Before I start bisecting (tomorrow or the day thereafter), anyone with an idea?
Subject: powerpc: Correct dependency of KEXEC
commit 28794d34ecb6815a3fa0a4256027c9b081a17c5f ("powerpc/kconfig: Kill
PPC_MULTIPLATFORM") broke KEXEC, by making it dependant on BOOK3S, while it
should be PPC_BOOK3S.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -313,7 +313,7 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE
config KEXEC
bool "kexec system call (EXPERIMENTAL)"
- depends on BOOK3S && EXPERIMENTAL
+ depends on PPC_BOOK3S && EXPERIMENTAL
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: issue at the beginning of kernel booting
From: Scott Wood @ 2009-04-02 16:12 UTC (permalink / raw)
To: Sauce.Cheng; +Cc: linuxppc-dev
In-Reply-To: <22840131.post@talk.nabble.com>
On Wed, Apr 01, 2009 at 08:23:42PM -0700, Sauce.Cheng wrote:
> > I don't see where you set up a BAT that covers 0xf0000000.
>
> if i have to set up a BAT that cover 0xF0000000. i had a debug with LEDs
> like that in u-boot code. everything is //normal. 0xF00000000 is the value
> of CFG_IMMR(CONFIG_SYS_IMMR) that memory map register, it is the phy address
> and //base //address of all internal regishters, isnt? you mean that if i
> set BATs, i should not get the phy address like in the //front ?
I don't quite follow the above, but what I meant is that you need to
put a mapping in place that covers your LED I/O once you have the MMU on.
Any mappings that U-boot made will be gone at that point.
> i tried
> CONFIG_PPC_EARLY_DEBUG_CPM=y
> CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf00000008
> how can i make sure CPM_ADDR, 0xf0000008 is default value
Look at the u-boot source, or dump the memory and see if it looks like a
ring buffer.
> PowerPC,8272@0 {
> device_type = "cpu";
> reg = <0>;
> d-cache-line-size = <d#32>;
> i-cache-line-size = <d#32>;
> d-cache-size = <d#16384>;
> i-cache-size = <d#16384>;
This is a dts-v0 tree, which implies it's fairly old.
> brg@119f0 {
> compatible = "fsl,mpc8272-brg",
> "fsl,cpm2-brg",
> "fsl,cpm-brg";
> reg = <119f0 10 115f0 10>;
> };
Make sure that the clock-frequency property of the brg node is being set
by u-boot. I should probably send a patch for that while the merge
window's still open...
> serial@11a82 {
> device_type = "serial";
> compatible = "fsl,mpc8272-smc-uart",
> "fsl,cpm2-smc-uart";
> reg = <11a82 20 87FC 100>;
regs = <11a80 20 87fc 2>;
> interrupts = <28 8>;
interrupts = <4 8>;
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <1>;
> fsl,cpm-command = <00800000>;
You need to update fsl,cpm-command; that is the SCC1 command word.
The SMC1 command is 0x1d000000 (see the ep8248e device tree).
Also make sure that the brg is correct.
-Scott
^ permalink raw reply
* Re: MPC83xx console : no output after handover
From: Matthew L. Creech @ 2009-04-02 15:20 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc-dev
In-Reply-To: <49D498E0.80603@mlbassoc.com>
On Thu, Apr 2, 2009 at 6:52 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>
> Can you share what you had and what you changed it to? =A0I'm
> running on very similar systems and may face this exact problem
> soon.
>
> Thanks
>
I don't actually have a platform-specific bus, but I misread the help
text for CONFIG_SERIAL_OF_PLATFORM and thought that it applied to any
system whose serial port was configured via the DTS file. So I had:
CONFIG_SERIAL_8250=3Dy
CONFIG_SERIAL_8250_CONSOLE=3Dy
...
CONFIG_SERIAL_OF_PLATFORM=3Dy
The result was that my console's serial port was initialized correctly
by the 8250 driver, but then of_platform_serial_probe() immediately
stomped on it. (Not sure what it was doing exactly, I just traced
through far enough to see that printk() worked before
serial8250_register_port() was called in of_serial.c, and not
afterward).
The "fix" for me was simply to disable CONFIG_SERIAL_OF_PLATFORM, as
it's unnecessary in my case.
--=20
Matthew L. Creech
^ permalink raw reply
* Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29
From: Hugh Dickins @ 2009-04-02 12:43 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, peterz, linux-kernel, akpm
In-Reply-To: <1238659491.9041.133.camel@localhost>
On Thu, 2 Apr 2009, Michael Ellerman wrote:
> On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
> > Resending due to lack of response to original post.
>
> Hi Chris,
>
> You'll probably get a more useful response on lkml. You CC'ed
> linux-kernel-owner originally :)
Thanks.
>
> > I was validating some code dealing with /proc/<pid>/maps on 2.6.29 and
> > was surprised when it failed. It turns out that at least on my ppc64 G5
> > machine the offset value for the last entry is strange--it shows up as a
> > 64-bit value even though the process itself is only 32-bit.
> >
> > This behaviour also shows up in 2.6.25, but doesn't in 2.6.14. I
> > haven't yet tested anything else in between.
> >
> > [cfriesen@localhost cfriesen]$ cat /proc/self/maps
> > 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
> > 0fe70000-0ffbf000 r-xp 00000000 08:03 4312393 /lib/tls/libc-2.3.3.so
> > 0ffbf000-0ffc0000 ---p 0014f000 08:03 4312393 /lib/tls/libc-2.3.3.so
> > 0ffc0000-0ffc2000 r--p 00150000 08:03 4312393 /lib/tls/libc-2.3.3.so
> > 0ffc2000-0ffc6000 rwxp 00152000 08:03 4312393 /lib/tls/libc-2.3.3.so
> > 0ffc6000-0ffc8000 rwxp 0ffc6000 00:00 0
> > 0ffd0000-0ffec000 r-xp 00000000 08:03 4309011 /lib/ld-2.3.3.so
> > 0fff0000-0fff1000 r--p 00020000 08:03 4309011 /lib/ld-2.3.3.so
> > 0fff1000-0fff2000 rwxp 00021000 08:03 4309011 /lib/ld-2.3.3.so
> > 10000000-10004000 r-xp 00000000 08:03 917536 /bin/cat
> > 10013000-10015000 rwxp 00003000 08:03 917536 /bin/cat
> > 10015000-10036000 rwxp 10015000 00:00 0 [heap]
> > f7deb000-f7feb000 r--p 00000000 08:03 2560322
> > /usr/lib/locale/locale-archive
> > f7feb000-f7fec000 rw-p f7feb000 00:00 0
> > ffe6d000-ffe82000 rw-p ffffffeb000 00:00 0 [stack]
> >
> > I'm at a loss to explain what's going on here. Anyone got any ideas?
>
> It looks like for vmas that don't have a vm_file (like the stack),
> vm_pgoff is basically "internal use" - and so can be > 32 bit.
Yes, it's just a cosmetic blemish, which comes from how the args on
stack are initially prepared in a 64-bit space, then moved into place
for the 32-bit task - the anon vm_pgoff still reflects the original
location, precisely in order to track pages despite movements.
(2.6.14 had the same use of anon vm_pgoff, but args on stack
were limited, and inserted directly into the 32-bit space.)
Chris isn't the first to be concerned by that: there's a patch in
-mm which just shows 0 instead of anon vm_pgoff in /proc/<pid>/maps
output. That patch is on akpm's list for 2.6.30 merge, but I think
hasn't gone to Linus yet: expect it in a later batch.
Hugh
^ permalink raw reply
* Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
From: Benjamin Krill @ 2009-04-02 13:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, linuxppc-dev,
Cell Broadband Engine OSS Development
In-Reply-To: <200904021515.12082.arnd@arndb.de>
* Arnd Bergmann | 2009-04-02 15:15:11 [+0200]:
>BenK, can you try Geert's patch on QPACE?
Successfully tested on QPACE.
Acked-by: Benjamin Krill <ben@codiert.org>
^ permalink raw reply
* Re: [PATCH 0/7] Generic RTC class driver
From: Kyle McMartin @ 2009-04-02 13:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-m68k, Kyle McMartin, linux-parisc, rtc-linux, Paul Mundt,
Linux Kernel Development, Kyle McMartin, Linux/PPC Development,
Alessandro Zummo, Andrew Morton, Dann Frazier
In-Reply-To: <alpine.LRH.2.00.0904021141080.30882@vixen.sonytel.be>
On Thu, Apr 02, 2009 at 11:42:02AM +0200, Geert Uytterhoeven wrote:
> On Fri, 13 Mar 2009, Kyle McMartin wrote:
> > On Wed, Mar 11, 2009 at 06:26:12PM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 11 Mar 2009, Kyle McMartin wrote:
> > > > On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote:
> > > > > Is it OK for you to take it through your PA-RISC tree?
> > > > > If yes, I can resend the patch series with the collected acks.
> > > >
> > I've pulled it and pushed it back out, I'll submit it when the merge
> > window opens.
>
> Apparently the first half went it through akpm. Will you take care of the
> remaining commits?
>
Yup, I updated the rtc-parisc branch last night, I'll push it along to
Linus this morning.
Thanks again, Geert.
cheers, Kyle
^ permalink raw reply
* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Kumar Gala @ 2009-04-02 13:47 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Scott Wood
In-Reply-To: <49D45D4F.3010103@grandegger.com>
On Apr 2, 2009, at 1:38 AM, Wolfgang Grandegger wrote:
>
> Socrates is a new board and it has no problem using an up-to-date
> version of U-Boot. The socrates.dts file in your "next" tree already
> has
> the "device_type = "soc" removed. We need to add "fsl,soc" to the
> "compatible" property and update fsl_get_sys_freq(), etc. to search
> for
> it as well. And U-Boot should use the same name to fixup the
> frequencies. Are you already working on that issue? Should I provide
> patches?
>
I'm not working on it at all. I'm also guessing at this point the
Socrates support is in Linus tree :)
- k
^ permalink raw reply
* [PATCH] fsl_pq_mdio: Fix compile failure
From: Kumar Gala @ 2009-04-02 13:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxppc-dev
From: Segher Boessenkool <segher@kernel.crashing.org>
Add EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name) for module builds
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Dave,
I think this got lost in a thread on the ppc list.
- k
drivers/net/fsl_pq_mdio.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fsl_pq_mdio.c b/drivers/net/fsl_pq_mdio.c
index d9e1ecf..aa1eb88 100644
--- a/drivers/net/fsl_pq_mdio.c
+++ b/drivers/net/fsl_pq_mdio.c
@@ -204,6 +204,7 @@ void fsl_pq_mdio_bus_name(char *name, struct device_node *np)
snprintf(name, MII_BUS_ID_SIZE, "%s@%llx", np->name,
(unsigned long long)taddr);
}
+EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name);
/* Scan the bus in reverse, looking for an empty spot */
static int fsl_pq_mdio_find_free(struct mii_bus *new_bus)
--
1.5.6.6
^ permalink raw reply related
* Re: [PATCH 0/3] Series short description
From: Grant Likely @ 2009-04-02 13:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linuxppc-dev
In-Reply-To: <20090402.005715.02030593.davem@davemloft.net>
On Thu, Apr 2, 2009 at 1:57 AM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Wed, 01 Apr 2009 00:16:46 -0600
>
>> Here are the fec_mpc52xx patches which should be picked up for 2.6.29.
>> Patch #1 fixes a dma related BUG_ON() discovered after the merge window
>> opened. =A0#2 & #3 were original a single patch posted prior to the merg=
e
>> window, but not having a s-o-b line from the original author held them u=
p.
>> In the end I rewrote it from scratch as two patches just so I can get
>> them merged. =A0#2 makes the driver use net_device_ops, and #3 fixes a N=
ULL
>> dereference.
>>
>> I've tested these patches on several MPC5200 platforms.
>
> All applied, thanks Grant.
Thanks David!
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: UIO: uio_mem does not handle devices above 4 GB address
From: Steven A. Falco @ 2009-04-02 13:20 UTC (permalink / raw)
To: linux-kernel, hjk, Herrera-Bendezu, Luis; +Cc: linuxppc-dev@ozlabs.org
> On Wed, Apr 01, 2009 at 01:20:49PM -0400, Herrera-Bendezu, Luis wrote:
> >> I am working on a PPC440EPx board with some FPGAs located at
> >> addresses above 4 GB
Cc'ing the PPC list, since they have the most experience with this
CPU, and may have some useful insights. The topic is "UIO on the
PPC440EPx - 36-bit physical addresses".
The PPC440EPx uses 36-bit addressing but is a 32-bit processor.
*All* peripherals are above the first 4 GB - that cannot be changed
if you use this CPU chip.
In general, the solution is to use "struct resource" to carry physical
addresses and sizes. The basic type is:
#ifdef CONFIG_PHYS_ADDR_T_64BIT
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
and for this processor, we use u64 rather than u32.
So, if we want to make UIO usable on this class of CPU, we might
replace:
struct uio_mem {
unsigned long addr;
unsigned long size;
int memtype;
void __iomem *internal_addr;
struct uio_map *map;
};
with:
struct uio_mem {
phys_addr_t addr;
phys_addr_t size;
int memtype;
void __iomem *internal_addr;
struct uio_map *map;
};
A few other changes would be needed. We'd have to use something
other than
return sprintf(buf, "0x%lx\n", mem->addr);
because the format would be incorrect for a u64. Also, I believe
we would get warnings in uio_vma_fault(). However, the phys_addr
is really only applicable to UIO_MEM_PHYS, so perhaps we want a
union of phys_addr_t and unsigned long for addr and size?
Anyway, this is a real problem for the PPC440EPx, that board
designers cannot work around.
Steve
^ permalink raw reply
* Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
From: Arnd Bergmann @ 2009-04-02 13:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven, Cell Broadband Engine OSS Development
In-Reply-To: <alpine.LRH.2.00.0904020931520.11458@vixen.sonytel.be>
On Thursday 02 April 2009, Geert Uytterhoeven wrote:
> | arch/powerpc/platforms/built-in.o:(.toc1+0x4e8): undefined reference to `pci_io_base'
>
> due to arch/powerpc/platforms/cell/io-workarounds.c. I guess this file
> shouldn't be built when CONFIG_PCI=n?
Right, the I/O workarounds are specific to the spider PCI implementation,
so there is no point in having them without PCI support.
> As I don't have the hardware to test anyway, I'll give up.
BenK, can you try Geert's patch on QPACE?
Arnd <><
^ permalink raw reply
* Re: [v0 PATCH 2/5] EDAC: Add CPC925 driver source file
From: Arnd Bergmann @ 2009-04-02 12:40 UTC (permalink / raw)
To: Harry Ciao; +Cc: linuxppc-dev, norsk5, linux-kernel, bluesmoke-devel
In-Reply-To: <1238652440-9224-3-git-send-email-qingtao.cao@windriver.com>
On Thursday 02 April 2009, Harry Ciao wrote:
> Introduce IBM CPC925 EDAC driver source file, which makes use of error
> detections on the IBM CPC925 Bridge and Memory Controller.
>
> Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
On a very brief review, the driver looks good to me, but please
post the full series to the linuxppc-dev@ozlabs.org mailing list
as well, because that is likely to have more people that will
comment on it.
The first three patches of your series should be merged into
a single one, because none of them has any signficance by itself.
You may also consider moving the contents of the header file
into the main driver, because it does not actually act as an
interface.
Arnd <><
^ permalink raw reply
* Re: [v0 PATCH 5/5] EDAC: CPC925 MC platform device setup
From: Arnd Bergmann @ 2009-04-02 12:36 UTC (permalink / raw)
To: Harry Ciao; +Cc: linuxppc-dev, norsk5, linux-kernel, bluesmoke-devel
In-Reply-To: <1238652440-9224-6-git-send-email-qingtao.cao@windriver.com>
On Thursday 02 April 2009, Harry Ciao wrote:
> +#ifdef CONFIG_EDAC
> +#define CPC925_MC_START=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A00=
xf8000000
> +#define CPC925_MC_END=A0=A0=A0=A0=A0=A0=A0=A0=A0=A00xf8ffffff /* sizeof =
16MB */
> +/* Register a platform device for CPC925 memory controller */
> +static int __init maple_cpc925_edac_setup(void)
It's not good to have these encoded as magic numbers.
Can't you find the addresses in the device tree? Maybe it's
even possible to make this an of_platform_driver if you
find a good node to bind to.
Does the driver also work on a G5 Mac, or is it limited
to the maple platform?
Arnd <><
^ permalink raw reply
* gianfar ooops after transmit timed out
From: Markus Brunner @ 2009-04-02 12:20 UTC (permalink / raw)
To: Andy Fleming; +Cc: Linuxppc-dev, Rini van Zetten, netdev
Hi,
my mpc8349 based board is known to have some problems with one ethernet phy
and is producing more (< 0.001%) frame errors than it should. This is enough
for the gianfar driver (of 2.6.27.20) to oops when I create lot's of packets
with a ping flood.
The oops occurs after "NETDEV WATCHDOG" reports that a "transmit timed out".
The driver does not oops on the other phy, which does not produce frame
errors.
Any Ideas?
Markus
ops: Kernel access of bad area, sig: 11 [#1]
PREEMPT RSBBA100
Modules linked in:
NIP: c01a10c4 LR: c013b254 CTR: c013c038
REGS: c02e7d20 TRAP: 0300 Not tainted (2.6.27.20)
MSR: 00001032 <ME,IR,DR> CR: 24000082 XER: 20000000
DAR: 000000a0, DSISR: 20000000
TASK = c02ce578[0] 'swapper' THREAD: c02e6000
GPR00: 000000a0 c02e7dd0 c02ce578 00000000 00000040 00000001 c02ec1c0
00001032
GPR08: c080d1e0 df9ea800 00000000 00000000 24000082 ffffffff 0404f000
00000000
GPR16: ffffffbf ffffffff ffffffff ffdff7ff ffffffff c02d0fd4 00100100
00200200
GPR24: c031220c 00000001 00000001 00000000 00000000 df849800 ff109000
df849b80
NIP [c01a10c4] dev_kfree_skb_irq+0x18/0x70
LR [c013b254] gfar_clean_tx_ring+0x70/0x11c
Call Trace:
[c02e7dd0] [c003e978] update_wall_time+0x730/0x744 (unreliable)
[c02e7df0] [c013b254] gfar_clean_tx_ring+0x70/0x11c
[c02e7e10] [c013c07c] gfar_poll+0x44/0x150
[c02e7e30] [c01a064c] net_rx_action+0xa8/0x19c
[c02e7e70] [c00251d4] __do_softirq+0x64/0xc0
[c02e7e90] [c0006384] do_softirq+0x40/0x58
[c02e7ea0] [c00250a8] irq_exit+0x40/0x9c
[c02e7eb0] [c000642c] do_IRQ+0x90/0xac
[c02e7ec0] [c0010ab4] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0x9c/0xf8
LR = cpu_idle+0x9c/0xf8
[c02e7f80] [c0009820] cpu_idle+0x58/0xf8 (unreliable)
[c02e7fa0] [c01fb8c8] __got2_end+0x7c/0x90
[c02e7fc0] [c026c794] start_kernel+0x2c0/0x2d4
[c02e7ff0] [00003438] 0x3438
Instruction dump:
7fa00124 80010024 bba10014 38210020 7c0803a6 4e800020 9421ffe0 7c0802a6
7c6b1b78 90010024 380300a0 bfa10014 <7d200028> 3129ffff 7d20012d 40a2fff4
Kernel panic - not syncing: Fatal exception in interrupt
The Trace with kgdb:
dev_kfree_skb_irq (skb=0x0)
at
arch/powerpc/include/asm/atomic.h:165
165 __asm__ __volatile__(
(gdb) bt
#0 dev_kfree_skb_irq (skb=0x0)
at
arch/powerpc/include/asm/atomic.h:165
#1 0xc013b254 in gfar_clean_tx_ring (dev=0xdf849800) at
drivers/net/gianfar.c:1384
#2 0xc013c07c in gfar_poll (napi=0xdf849ba4, budget=<value optimized
out>) at drivers/net/gianfar.c:1705
#3 0xc01a064c in net_rx_action (h=<value optimized out>) at
net/core/dev.c:2384
#4 0xc00251d4 in __do_softirq () at kernel/softirq.c:208
#5 0xc0006384 in do_softirq () at arch/powerpc/kernel/irq.c:430
#6 0xc00250a8 in irq_exit () at kernel/softirq.c:284
#7 0xc000642c in do_IRQ (regs=<value optimized out>) at
arch/powerpc/kernel/irq.c:325
#8 0xc0010ab4 in ret_from_except_full ()
#9 0xc0009820 in cpu_idle () at arch/powerpc/kernel/idle.c:59
#10 0xc01fb8c8 in rest_init () at init/main.c:481
#11 0xc026c794 in start_kernel () at init/main.c:691
#12 0x00003438 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
^ permalink raw reply
* Re: MPC83xx console : no output after handover
From: Gary Thomas @ 2009-04-02 10:52 UTC (permalink / raw)
To: Matthew L. Creech; +Cc: linuxppc-dev
In-Reply-To: <5ee96a840904011153qc052002i8c35229ca3e85c6c@mail.gmail.com>
Matthew L. Creech wrote:
> It turned out that the normally-initialized 8250 driver was getting
> stomped on by my device tree's serial driver (which is also an 8250) -
> apparently CONFIG_SERIAL_8250[_CONSOLE] and CONFIG_SERIAL_OF_PLATFORM
> don't play well together. Disabling the latter fixed my problem.
>
> Thanks for the help, and sorry for the noise.
>
Can you share what you had and what you changed it to? I'm
running on very similar systems and may face this exact problem
soon.
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 0/7] Generic RTC class driver
From: Geert Uytterhoeven @ 2009-04-02 9:42 UTC (permalink / raw)
To: Kyle McMartin, Andrew Morton
Cc: linux-m68k, Alessandro Zummo, rtc-linux, linux-parisc,
Linux Kernel Development, Kyle McMartin, Linux/PPC Development,
Paul Mundt, Dann Frazier
In-Reply-To: <20090313042543.GA3907@bombadil.infradead.org>
On Fri, 13 Mar 2009, Kyle McMartin wrote:
> On Wed, Mar 11, 2009 at 06:26:12PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 11 Mar 2009, Kyle McMartin wrote:
> > > On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote:
> > > > Is it OK for you to take it through your PA-RISC tree?
> > > > If yes, I can resend the patch series with the collected acks.
> > >
> I've pulled it and pushed it back out, I'll submit it when the merge
> window opens.
Apparently the first half went it through akpm. Will you take care of the
remaining commits?
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Preliminary 64-bit Book3E support
From: Benjamin Herrenschmidt @ 2009-04-02 8:30 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Kumar Gala
Hi !
I've posted for those interested at:
http://gate.crashing.org/~benh/patches-preliminary-book3e.tar.gz
A work-in-progress set of patches for adding support for a new processor
type, which ultimately will be common to 32 and 64-bit, and will
represent processors compliant with the architecture 2.06 "embedded"
variant. (We -might- make that backward compatible with earlier FSL
chips as well at some stage).
The current set of patches is very rough, hackish, and incomplete as you
can expect :-) It's a partial forward-rebase of an internal patch set
based on an earlier kernel which I just got booting in a simulator
internally so I can push it out before I go on vacation.
Among other things:
- It won't boot on anything you have access to :-)
- Even if you did, it's missing any specific Book3E > 2.06 processor
in cputable since neither IBM nor FSL has anything announced at this
stagem and there's no platform neither
- It only does the 64-bit part for now
- It's missing various "features", for example, SMP probably doesn't
work (though it's likely details, the original work does SMP just fine),
hugetlbfs isn't there, etc...
- Some of the early setup code makes assumptions that may not be valid
on all implementations and firmwares. This will have to be cleaned up.
- The patches are gross :-) They need to be split better of course.
Some things might still want to be done a bit differently though it's
actually ported from a reasonably mature code base. For example, the TLB
invalidation code for virtual page tables & indirect entries is a bit
gross right now.
- You may notice the complete lack of useful support for critical,
debug or machine check interrupts :-) There is some initial bits there,
debug interrupts -may- work to some extend from userspace only (though I
may not have ported all the bits to handle that on the C side) etc...
This will all be sorted in another batch later. There are issues that
need to be solved with those guys vs. the TLB miss state stack which
might have to be saved/restored or context switched.
- The move of the kernel virtual space to 0x8000000000000000 is due to
the way the virtual page tables work (when you don't have a HW table
walk, I create a giant linear virtual mapping of the page tables of a
given process so that the TLB miss handler doesn't have to walk down 3
or 4 levels of page table tree each time). It's a bit annoying though,
and I may change that back to 0xD000* using a different technique to
identify VPTs.
- And probably more I don't have off the top of my mind right now
Don't bother looking if that stuff isn't your cup of tea and it's
definitely not in any shape to be merged any time soon, but at least
it's out so those who do care can have a look, discuss, comment, etc...
I'll probably do a new drop some time in May or June.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] fsl_pq_mdio: Revive UCC MDIO support
From: David Miller @ 2009-04-02 8:28 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, leoli, afleming, Joakim.Tjernlund, linuxppc-dev
In-Reply-To: <20090331183352.GA4474@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Tue, 31 Mar 2009 22:33:52 +0400
> commit 1577ecef766650a57fceb171acee2b13cbfaf1d3 ("netdev: Merge UCC
> and gianfar MDIO bus drivers") introduced a regression so that UCC
> MDIO buses no longer work.
>
> This is because fsl_pq_mdio driver wrongly masks all non-TBI PHYs
> for !fsl,gianfar-mdio buses, while it should do that only for
> fsl,gianfar-tbi buses.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ucc_geth: Pass proper device to DMA routines, otherwise oops happens
From: David Miller @ 2009-04-02 8:26 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, leoli, afleming, Joakim.Tjernlund, linuxppc-dev
In-Reply-To: <20090331185837.GA22545@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Tue, 31 Mar 2009 22:58:37 +0400
> The driver should pass a device that actually specifies internal DMA
> ops, but currently it passes netdev's device, which is wrong and that
> causes following oops:
...
> Fix this by passing of_device's device that specifies DMA ops in its
> archdata.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] ucc_geth: Remove unused header
From: David Miller @ 2009-04-02 8:14 UTC (permalink / raw)
To: galak; +Cc: netdev, linuxppc-dev
In-Reply-To: <1238506979-8678-2-git-send-email-galak@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 31 Mar 2009 08:42:59 -0500
> Now that the driver is exclusively an of_platform driver we no longer
> use the structs and #defines in fsl_devices.h
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] gianfar: Remove unused header
From: David Miller @ 2009-04-02 8:14 UTC (permalink / raw)
To: galak; +Cc: netdev, linuxppc-dev
In-Reply-To: <1238506979-8678-1-git-send-email-galak@kernel.crashing.org>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 31 Mar 2009 08:42:58 -0500
> Now that the driver is exclusively an of_platform driver we no longer
> use the structs and #defines in fsl_devices.h
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Applied.
^ permalink raw reply
* Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29
From: Michael Ellerman @ 2009-04-02 8:04 UTC (permalink / raw)
To: Chris Friesen; +Cc: peterz, linuxppc-dev, linux-kernel
In-Reply-To: <49D3F662.4050100@nortel.com>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
> Resending due to lack of response to original post.
Hi Chris,
You'll probably get a more useful response on lkml. You CC'ed
linux-kernel-owner originally :)
> I was validating some code dealing with /proc/<pid>/maps on 2.6.29 and
> was surprised when it failed. It turns out that at least on my ppc64 G5
> machine the offset value for the last entry is strange--it shows up as a
> 64-bit value even though the process itself is only 32-bit.
>
> This behaviour also shows up in 2.6.25, but doesn't in 2.6.14. I
> haven't yet tested anything else in between.
>
> [cfriesen@localhost cfriesen]$ cat /proc/self/maps
> 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
> 0fe70000-0ffbf000 r-xp 00000000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffbf000-0ffc0000 ---p 0014f000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc0000-0ffc2000 r--p 00150000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc2000-0ffc6000 rwxp 00152000 08:03 4312393 /lib/tls/libc-2.3.3.so
> 0ffc6000-0ffc8000 rwxp 0ffc6000 00:00 0
> 0ffd0000-0ffec000 r-xp 00000000 08:03 4309011 /lib/ld-2.3.3.so
> 0fff0000-0fff1000 r--p 00020000 08:03 4309011 /lib/ld-2.3.3.so
> 0fff1000-0fff2000 rwxp 00021000 08:03 4309011 /lib/ld-2.3.3.so
> 10000000-10004000 r-xp 00000000 08:03 917536 /bin/cat
> 10013000-10015000 rwxp 00003000 08:03 917536 /bin/cat
> 10015000-10036000 rwxp 10015000 00:00 0 [heap]
> f7deb000-f7feb000 r--p 00000000 08:03 2560322
> /usr/lib/locale/locale-archive
> f7feb000-f7fec000 rw-p f7feb000 00:00 0
> ffe6d000-ffe82000 rw-p ffffffeb000 00:00 0 [stack]
>
> I'm at a loss to explain what's going on here. Anyone got any ideas?
It looks like for vmas that don't have a vm_file (like the stack),
vm_pgoff is basically "internal use" - and so can be > 32 bit.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox