call put_device() when device_register() fails.
Signed-off-by: Rahul Ruikar
---
drivers/usb/gadget/fsl_udc_core.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 08a9a62..491fc7a 100644
--- a
Hi,
It seems i forgot to include the relevant TLB entries in U-Boot and the
Device Tree in the e-mail, so here they are:
The TLB entries in U-Boot:
/*
* TLB 3: 256M Non-cacheable, guarded
* 0xc000 256M Rapid IO MEM First half
*/
SET_TLB_ENTRY(1, CONFIG_SYS_RIO_MEM_VIRT, CONFIG_SYS_RIO_MEM
On Sat, 02 Oct 2010 13:20:54 +1000
Benjamin Herrenschmidt wrote:
> On Fri, 2010-10-01 at 21:31 -0400, Josh Boyer wrote:
> > > +config ARCH_DMA_ADDR_T_64BIT
> > > + def_bool ARCH_PHYS_ADDR_T_64BIT
> > > +
> >
> > I seemed to have missed what this is about entirely. Is there some
> > place
> -Original Message-
> From: Anton Vorontsov [mailto:cbouatmai...@gmail.com]
> Sent: Monday, September 20, 2010 21:19 PM
> To: Zang Roy-R61911
> Cc: linux-...@lists.infradead.org; dw...@infradead.org; dedeki...@gmail.com;
> a...@linux-foundation.org; Lan Chunhe-B25806; Wood Scott-B07421;
This looks like duplicated code getting out of sync.
$ diff -Naurd arch/powerpc/lib/div64.S arch/powerpc/boot/div64.S
--- arch/powerpc/lib/div64.S2009-09-09 18:13:59.0 -0400
+++ arch/powerpc/boot/div64.S 2009-09-09 18:13:59.0 -0400
@@ -13,10 +13,10 @@
* as published by the
On the prom boot path, with the firmware supposed to
be managing the MMU, there is a case where:
1. Linux changes some BAT registers.
2. Bits 0x0070 are/become set in the MSR.
3. Linux takes an MMU fault.
4. The firmware handles it.
AFAIK, you can't expect the firmware to leave the BAT alone.
On Thu, Sep 30, 2010 at 05:57:10PM -0700, Dan Williams wrote:
> [ adding Greg ]
>
> On Thu, Sep 30, 2010 at 5:16 PM, Tirumala Marri wrote:
> >> Where ?iop_adma_alloc_slots() is implemented differently between
> >> iop13xx and iop3xx. ?In this case why does ppc440spe-adma.h exist? ?If
> >> it has
On Fri, Oct 01, 2010 at 05:06:02PM +1000, Ian Munsie wrote:
> From: Ian Munsie
>
> On PowerPC the device tree is always big endian, but the CPU could be
> either, so add be32_to_cpu where appropriate and change the types of
> device tree data to __be32 etc to allow sparse to locate endian issues.
Hi Ben and Linus
Here are some powerpc fixes that I had sitting in my tree and forgot
about. They are ready to be merged, and are for the mpc5xxx platform
that I maintain, but Ben hasn't acked them yet. Ben, do you want
Linus to pull this directly, or do you have other powerpc commits that
you w
> Really?
>
> The current dma_addr_t is:
>
> #if defined(__powerpc64__) || defined(CONFIG_PHYS_64BIT)
> typedef u64 dma_addr_t;
> #else
> typedef u32 dma_addr_t;
> #endif
> typedef u64 dma64_addr_t;
-EBRAINFAI ... either I wasn't looking when we changed it or I just
forgot :-) We -used-, I'm pr
On Sat, 2010-10-02 at 21:15 -0600, Grant Likely wrote:
>
> But I won't merge this through my tree unless Ben asks me to.
Being careful heh ? :-)
I'll take care of these.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
Hi all,
My problem is kernel crash under full line rate random packet length
ip network traffic.
I'am using default unmodified kernel and default SMP kernel
configuration, MPC8572DS development board and also using a hardware
packet generator.
My test is ip forwarding between eth0 and eth1, and Har
12 matches
Mail list logo
