From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Fri, 9 May 2008 15:27:37 +1000
> David Miller writes:
>
> > This uses APIs that are not generic, or at least not part of
> > what Sparc provides yet.
> >
> > So just PPC_OF this for now just like the EHCI_OF driver.
> >
> > This fixes allmodconfig
David Miller writes:
> This uses APIs that are not generic, or at least not part of
> what Sparc provides yet.
>
> So just PPC_OF this for now just like the EHCI_OF driver.
>
> This fixes allmodconfig build errors on sparc.
Are you going to send this to the USB maintainers, or are you going to
Michael Ellerman writes:
> On Wed, 2008-05-07 at 14:19 -0500, Timur Tabi wrote:
> > Update function of_find_property() to return NULL if the device_node passed
> > to it is also NULL. Otherwise, passing NULL will cause a null pointer
> > dereference.
> >
> > Signed-off-by: Timur Tabi <[EMAIL PRO
On Thu, 2008-05-08 at 11:41 -0500, Nate Case wrote:
> This printk() appears twice in the same function. Only the latter one
> in the inval_range: section appears to be legitimate.
>
> Signed-off-by: Nate Case <[EMAIL PROTECTED]>
Ack.
___
Linuxppc-de
On Thu, 2008-05-08 at 18:26 -0500, Nate Case wrote:
> When mapping an open firmware device tree node to a resource,
> check if the device is on the "isa" legacy bus. In this case,
> pci_address_to_pio() should not be used since that function is only
> for addresses above the 64KB reserved region.
Kamalesh Babulal writes:
> Thanks, after applying the patch the oops is not reproducible on the machine.
> The console
> log had no message starting with SLB: or FWNMI:. I have updated the bugzilla
> also.
>
> Tested-by: Kamalesh Babulal <[EMAIL PROTECTED]>
Could you test Linus' current git tr
This printk() appears twice in the same function. Only the latter one
in the inval_range: section appears to be legitimate.
Signed-off-by: Nate Case <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/kernel/isa-bridge.c b/arch/powerpc/kernel/isa-bridge.c
index ee172aa..e35092e 100644
--- a/arch/p
I'm not sure who packages that, I think it's in powerpc-utils, anyway,
here's a patch that makes it work on device-tree tarballs lsprop'ed from
a LE machine.
--- /home/benh/grabbag/powerpc-utils-1.1.3/lsprop.c 2007-05-11
14:21:23.0 +1000
+++ lsprop.c2008-05-09 10:13:49.0 +
On May 8, 2008, at 12:25 PM, Vitaly Bordug wrote:
On Tue, May 06, 2008 at 12:30:08PM -0400, Jeff Garzik wrote:
Becky Bruce wrote:
This driver has been superseded by fs_enet and is no longer in use.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
I cannot make an informed judgement on this.
When mapping an open firmware device tree node to a resource,
check if the device is on the "isa" legacy bus. In this case,
pci_address_to_pio() should not be used since that function is only
for addresses above the 64KB reserved region.
This was necessary to get IPMI working on a board that acce
On Thu, 2008-05-08 at 09:48 +0200, Jochen Roth wrote:
> >> Unable to handle kernel paging request for data at address
> >> 0xd04fe9a8
> >> Faulting instruction address: 0xd0330ad8
> >> cpu 0x0: Vector: 300 (Data Access) at [c0003c337680]
> >> pc: d0330ad8: .alloc_
On Thu, Apr 24, Olaf Hering wrote:
> Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading
> of modules. modalias files are already present for many other bus types.
> This adds also a newline to the devspec files.
>
> Also create a devspec file for mac-io devices. They were cr
Hi,
The commit "[POWERPC] Port fixmap from x86 and use for kmap_atomic" breaks
dma-noncoherent.c, if highmem is enabled.
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -387,3 +388,25 @@ void kernel_map_pages(struct page *page, int numpages,
> int enable)
>
On Thu, May 08, 2008 at 09:16:10AM -0500, Kumar Gala wrote:
>
> On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote:
>
> >>>
> >>>
> >>>Let me know if this does address your question.
> >>
> >>The problem is MODPOST complains about undefined symbols:
> >>
> >> MODPOST 24 modules
> >>ERROR: "_restgpr_2
On Thu, May 8, 2008 at 12:25 PM, Stephen Neuendorffer
<[EMAIL PROTECTED]> wrote:
> ePAPR drafts propose 'simple-bus' as a generic compatibility type for
> busses which cannot be probed for devices. In addition, the Xilinx
> versions of these IPs seem to be proliferating. Hence, in the future
>
ePAPR drafts propose 'simple-bus' as a generic compatibility type for
busses which cannot be probed for devices. In addition, the Xilinx
versions of these IPs seem to be proliferating. Hence, in the future
let's prefer to use the standard names. I've left the old names in
for short term backward
On Tue, May 06, 2008 at 12:30:08PM -0400, Jeff Garzik wrote:
> Becky Bruce wrote:
> >This driver has been superseded by fs_enet and is no longer in use.
> >
> >Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
>
> I cannot make an informed judgement on this.
>
> ACK, and pass through platform tree,
Hmm... sounds reasonable to me.
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of David
Gibson
> Sent: Wednesday, May 07, 2008 8:30 PM
> To: Josh Boyer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] [POWERPC] Xilinx: add compatibil
At Thu, 08 May 2008 07:53:11 +1000,
Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-05-07 at 09:22 -0500, Timur Tabi wrote:
> > Takashi Iwai wrote:
> >
> > > This is a mmap of the data record to be shared in realtime with apps.
> > > The app updates its data pointer (appl_ptr) on the mmapped buffe
On Thu, May 8, 2008 at 9:10 AM, Fabio Tosetto <[EMAIL PROTECTED]> wrote:
> Ok, maybe it's better to start from the beginning.
> Now I'm using a Lite5200b board, just to avoid problems with my hardware,
> and I'm trying to have a bootable kernel.
>
> With kernel version 2.6.24.6 I do the following
Ok, maybe it's better to start from the beginning.
Now I'm using a Lite5200b board, just to avoid problems with my
hardware, and I'm trying to have a bootable kernel.
With kernel version 2.6.24.6 I do the following commands
$ make ARCH=powerpc lite5200_defconfig
$ make ARCH=powerpc CROSS_COMPI
Currently fsl_uli1575.c's RTC quirk reads at ->start, but I got the RTC
working on the MPC8610HPCD only when reading at 0xa010-0xafff,
i.e. memory outside of behind-the-bridge devices' assigned regions.
This patch wasn't tested on the MPC85xxDS and MPC8641HPCN boards, I
don't have any of t
With this patch we can choose which ULI fixups we want to apply
for the specific boards.
There are no changes to the fixups them selfs.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 11 ++-
arch/powerpc/platforms/86xx/Kconfig|1
These are similar to machine_initcalls, but works for the PCI fixups.
We need this to apply machine specific fixups for the same PCI devices.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
include/asm-powerpc/pci.h | 16
1 files changed, 16 insertions(+), 0 deletions(-)
On Mon, May 05, 2008 at 02:11:30PM -0500, Kumar Gala wrote:
>
> On May 5, 2008, at 1:56 PM, Anton Vorontsov wrote:
>
>> The ULI "Super South Bridge" contains ISA bridge to the legacy
>> devices, such as Super IO mouse/keyboard/floppy disk controllers,
>> parallel port, i8259 interrupt controller an
On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote:
Let me know if this does address your question.
The problem is MODPOST complains about undefined symbols:
MODPOST 24 modules
ERROR: "_restgpr_20_x" [net/key/af_key.ko] undefined!
ERROR: "_restgpr_25_x" [net/key/af_key.ko] undefined!
ERROR: "
GCC 4.4.x looks to be adding support for generating out-of-line register
saves/restores based on:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01678.html
This breaks the bootwrapper as we'd need to link with libgcc to get the
implementation of the register save/restores.
To workaround this issue
Removed duplicated include file in powerpc/kernel/btext.c.
Signed-off-by: Huang Weiyi <[EMAIL PROTECTED]>
--- a/powerpc/kernel/btext.c2008-05-08 21:20:20.0 +0800
+++ b/powerpc/kernel/btext.c2008-05-08 21:20:38.0 +0800
@@ -16,7 +16,6 @@
#include
#include
#include
-#i
Hi,
> On Wed, 7 May 2008 17:42:51 -0400
> Sean MacLennan <[EMAIL PROTECTED]> wrote:
>
>> On Wed, 07 May 2008 16:36:30 +0200
>> "Detlev Zundel" <[EMAIL PROTECTED]> wrote:
>>
>> > It also happened that a driver once posted for what the customer
>> > thought was a completely specific device of his o
Hi,
>>> memcpy_from/to_io() use word aligned accesses on the io side of
>>> memory.
>>> The MPC5200 local plus bus where our flashes are connected does not
>>> allow unaligned accesses, so we have to use the io versions of memcpy.
>>
>> But this region of flash is marked as suitable for execute-in
Greetings.
Attached is a patchset to support the ASP8347E.
http://www.analogue-micro.com/ASP8347.html. Due to the fact that the board
shipped with a root filesystem that requires devfs, you have to run a different
rootfs with all current kernels. I've been using the 8xx root fs from the ELDK
via
On Thu, 8 May 2008 13:30:06 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Wed, May 07, 2008 at 09:46:30PM -0500, Josh Boyer wrote:
> > On Thu, 8 May 2008 10:18:50 +1000
> > David Gibson <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, May 07, 2008 at 01:47:31PM -0700, Stephen Neuendorffer wrote:
We found the problem when porting code from Linux 2.4 to 2.6, where a
user space application maps a 1 MByte region of DRAM with the O_SYNC
flag to communicate with an internal core that shares access to the
DRAM but does not have any cache snooping logic.
In 2.4 the mem driver honors the O_SYNC f
Carl Love wrote:
> +void oprofile_add_value(unsigned long value, int cpu) {
> + struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[cpu];
Shouldn't it be
struct oprofile_cpu_buffer *cpu_buf = &per_cpu(cpu_buffer, cpu);
No, I don't think so. Take a look at the other functions in
driv
On Thu, 2008-05-08 at 00:17 -0700, Nick Spence wrote:
> The page protection seemed to be allocated on a per pte basis, where
> each PTE is a small fixed size. I will need to check the TLB setup
> further.
The problem is that it will then be part of the linear mapping, which
means you'll end up w
Benjamin Herrenschmidt wrote:
On Wed, 2008-05-07 at 23:31 -0700, Spence Nick wrote:
Then you should completely carve it out of the LMB's which will ensure
it's not seen as RAM by /dev/mem and not mapped by the linear mapping
(well, the later depends ... if it's carved out of the top of RAM it
sh
On Wed, May 07, 2008 at 09:46:51PM -0700, Stephen Neuendorffer wrote:
>
> The problem is that the tft driver currently in mainline assumes
> that the dcr control registers are accessed through mmio, and probes
> for a reg=<> property. Since the device is actually a dcr device,
> it can be connect
37 matches
Mail list logo
