Hi David,
On Tue, 15 Jul 2008 09:31:29 -0600, David Hubbard wrote:
On Tue, Jul 15, 2008 at 2:36 AM, Jean Delvare [EMAIL PROTECTED] wrote:
I always assumed that there was no way to know in advance if a
Super-I/O (LPC) chip was present or not, let alone the exact model of
the chip. The I/O
On Wednesday 16 July 2008, Roland Dreier wrote:
Strong ordering is only active when both the bridge and the IOMMU enable
it, but for correctly written drivers, this only results in a slowdown.
So when would someone use this dma attribute? As a hack to fix drivers
where the real fix is
On Wednesday 16 July 2008, Dave Jones wrote:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
/builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129:
undefined reference to `alloc_mdio_bitbang'
Hi,
I am writing a soc sound driver for MPC8323 board linux 2.6.24 in which i want
to do data transfer to and from device myself using BUFFER DESCRIPTOR not with
the usual DMA transfer.
Please help me.
___
Linuxppc-dev mailing list
On 16-07-08 09:46, Jean Delvare wrote:
As a conclusion, there is no clear relationship between the presence
of an ISA or LPC bridge and the presence of a Super-I/O chip. All we
can say is that apparently all PC systems have an ISA bridge. So
indeed we can probably make the probes conditional
Hi Wolfgang,
On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
For hwmon chips, probing only occurs if the i2c adapter accepts to be
probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
you do not want a given i2c bus to be probed, then do
Hi Jean;
Jean Delvare wrote:
Hi Wolfgang,
On Wed, 16 Jul 2008 11:12:50 +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
For hwmon chips, probing only occurs if the i2c adapter accepts to be
probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
you do not want a given i2c
On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
The problem is that at this point in time, only a couple hwmon drivers
have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
would break most systems.
I have a set of patches converting
no i am working on powerpc. MPC8323
-Original Message-
From: Nobin Mathew [EMAIL PROTECTED]
To: dinesh [EMAIL PROTECTED]
Cc: Grant Likely [EMAIL PROTECTED], linuxppc-dev@ozlabs.org,
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA
Date:
Jean Delvare wrote:
On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
The problem is that at this point in time, only a couple hwmon drivers
have been converted to new-style i2c. So, dropping the I2C_CLASS_HWMON
would break most systems.
I have a set of
Hi dinesh,
If you are working on ARM, see the ARM AACi code, in sound/arm/aaci.c
Thanks
Nobin Mathew.
On 7/16/08, dinesh [EMAIL PROTECTED] wrote:
Hi,
I am writing a soc sound driver for MPC8323 board linux 2.6.24 in which i
want to do data transfer to and from device myself using BUFFER
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property probe of the FDT I2C device node:
[EMAIL PROTECTED] {
...
compatible = fsl-i2c;
probe;
On Wed, 2008-07-16 at 10:51 +0200, Arnd Bergmann wrote:
On Wednesday 16 July 2008, Dave Jones wrote:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
/builddir/build/BUILD/kernel-2.6.26/linux-2.6.26.ppc/arch/powerpc/platforms/82xx/ep8248e.c:129:
undefined reference to
On Tue, 15 Jul 2008 22:34:36 -0700
[EMAIL PROTECTED] wrote:
From: Victor Gallardo [EMAIL PROTECTED]
ppc4xx: Add AMCC Arches DTS
Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/arches.dts | 522
++
1 files changed, 522
On Tue, 15 Jul 2008 22:33:26 -0700
[EMAIL PROTECTED] wrote:
From: Victor Gallardo [EMAIL PROTECTED]
ppc4xx: Add AMCC Arches 460GT eval board support
Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
From what I can tell, you don't even need this patch or the defconfig.
Nothing differs at
Hi Wolfgang,
On Wed, 16 Jul 2008 12:47:25 +0200, Wolfgang Grandegger wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property probe of the FDT I2C device node:
On 7/16/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property probe of the FDT I2C device node:
All this patch seems to be
On Jul 16, 2008, at 6:13 AM, Benjamin Herrenschmidt wrote:
On Wed, 2008-07-16 at 10:51 +0200, Arnd Bergmann wrote:
On Wednesday 16 July 2008, Dave Jones wrote:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
Jean Delvare wrote:
Hi Wolfgang,
On Wed, 16 Jul 2008 12:47:25 +0200, Wolfgang Grandegger wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property probe of the FDT I2C device
Jon Smirl wrote:
On 7/16/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property probe of the FDT I2C device node:
All this
If we don't enable FS_ENET we get build issues:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
`alloc_mdio_bitbang'
arch/powerpc/platforms/82xx/ep8248e.c:143: undefined reference to
`mdiobus_register'
On Jul 11, 2008, at 6:04 PM, Scott Wood wrote:
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
Documentation/powerpc/dts-bindings/fsl/tsec.txt | 31
+--
1 files changed, 12 insertions(+), 19 deletions(-)
applied.
- k
___
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-next
to receive the following updates:
Documentation/powerpc/booting-without-of.txt| 189 ++--
Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt |
On Wed, Jul 16, 2008 at 12:10:59PM +0200, Jean Delvare wrote:
On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
Yep, as probing might not be acceptable in some cases, I makes sense to
add a property to suppress probing:
It'd rather make no-probing the
On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote:
On Tue, 15 Jul 2008 22:33:26 -0700
[EMAIL PROTECTED] wrote:
From: Victor Gallardo [EMAIL PROTECTED]
ppc4xx: Add AMCC Arches 460GT eval board support
Signed-off-by: Victor Gallardo [EMAIL PROTECTED]
From what I can
On 7/16/08, Grant Likely [EMAIL PROTECTED] wrote:
On Wed, Jul 16, 2008 at 12:10:59PM +0200, Jean Delvare wrote:
On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
Yep, as probing might not be acceptable in some cases, I makes sense to
add a
On 7/16/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
On 7/16/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable
On Wed, Jul 16, 2008 at 12:47:25PM +0200, Wolfgang Grandegger wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property probe of the FDT I2C device node:
[EMAIL
On Wed, 16 Jul 2008 10:18:26 -0400, Jon Smirl wrote:
On 7/16/08, Grant Likely [EMAIL PROTECTED] wrote:
On Wed, Jul 16, 2008 at 12:10:59PM +0200, Jean Delvare wrote:
On Wed, 16 Jul 2008 11:50:15 +0200, Wolfgang Grandegger wrote:
Jean Delvare wrote:
Yep, as probing might not
On Wed, Jul 16, 2008 at 10:24:22AM -0400, Jon Smirl wrote:
On 7/16/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
On 7/16/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable
Segher Boessenkool wrote:
Trying to cross-compile arch/powerpc for an freescale 8280:
Gcc 4.1.2
Binutils 2.17
BFD: ./vmlinux.strip.7812: section .text lma 0xc000 overlaps
previous sections
[etc]
Could you try with binutils 2.18?
Not easilly, I would have to rebuild the cross
On Wed, 16 Jul 2008 08:15:39 -0600
Grant Likely [EMAIL PROTECTED] wrote:
On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote:
On Tue, 15 Jul 2008 22:33:26 -0700
[EMAIL PROTECTED] wrote:
From: Victor Gallardo [EMAIL PROTECTED]
ppc4xx: Add AMCC Arches 460GT eval board
On 7/16/08, Grant Likely [EMAIL PROTECTED] wrote:
On Wed, Jul 16, 2008 at 10:24:22AM -0400, Jon Smirl wrote:
On 7/16/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
On 7/16/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Currently, the I2C buses are
On Wednesday 16 July 2008, Grant Likely wrote:
And then you don't need this file at all. Just add a
amcc,canyonlands string to your root node compatible property.
No! Don't do this because it is not true!
Instead, add your board name to canyonlands.c in canyonlands_probe().
It's
Hi Grant,
On Wed, Jul 16, 2008 at 12:47:25PM +0200, Wolfgang Grandegger wrote:
Currently, the I2C buses are probed for HWMON I2C devices, which might
not be acceptable in same cases. This patch makes device probing
configurable through the property probe of the FDT I2C device node:
Jon Smirl wrote:
Probing an i2c bus does not necessarily come to a good conclusion. The
probes for some chips can alter the states in others. People have
accidentally changed voltage settings and fried CPU chips. The process
is not well defined.
I agree. We should not be implementing any
On Wed, Jul 16, 2008 at 10:37:52AM -0400, Josh Boyer wrote:
On Wed, 16 Jul 2008 08:15:39 -0600
Grant Likely [EMAIL PROTECTED] wrote:
On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote:
And then you don't need this file at all. Just add a
amcc,canyonlands string to your root
On Wed, Jul 16, 2008 at 04:46:01PM +0200, Arnd Bergmann wrote:
On Wednesday 16 July 2008, Grant Likely wrote:
And then you don't need this file at all. Just add a
amcc,canyonlands string to your root node compatible property.
No! Don't do this because it is not true!
Hi.
I've been working with Debian bintuils 2.17-3 (which identifies
itself as 2.17) on my build box for some time.
When testing all-yes-config, I was getting warnings, but the
vmlinux was booting via kexec.
Since I was replicating the warnings from BFD about section lmas
overlapping in
It seems that some machines, like a default RHEL4 install, will
not have a definition for YYRHSLOC, and that prevents building
dtc. This supplies what appears to be the standard definition
for it in the event that the host system does not have it defined.
Signed-off-by: Paul Gortmaker [EMAIL
address: 0xc002d114
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=32 pSeries
Modules linked in:
NIP: c002d114 LR: c05d3c68 CTR:
REGS: c000e9137580 TRAP: 0300 Not tainted
(2.6.26-next-20080716-08333-g49de20b)
MSR: 80009032 EE,ME,IR
Timur Tabi wrote:
The defconfigs for Freescale 85xx and 86xx SOCs had bad choices for some
audio related options. In particular, OSS emulation should be enabled,
and the old ALSA API should be disabled.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
Kumar, can you apply this patch,
* 64-bit PTEs and reader vs writer hazards. How do we ensure that
the
TLB miss handler samples a consistent view of the pte. pte_updates
seem ok since we only update the flag word. However set_pte_at seems
like it could be problematic.
eieio on the writer and a data dependency on the
Arnd Bergmann wrote:
On Tuesday 15 July 2008, Rune Torgersen wrote:
Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile
test I did is almost identical (within 1%) of what the arch/powerpc
2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25
(I'll see if I can
On Jul 16, 2008, at 3:57 PM, Kumar Gala wrote:
* 64-bit PTEs and reader vs writer hazards. How do we ensure that
the
TLB miss handler samples a consistent view of the pte. pte_updates
seem ok since we only update the flag word. However set_pte_at
seems
like it could be problematic.
We need to create a false data dependency to ensure the loads of
the pte are done in the right order.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/kernel/head_fsl_booke.S | 24
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git
There are some minor issues with support 64-bit PTEs on a 32-bit processor
when dealing with SMP.
* We need to order the stores in set_pte_at to make sure the flag word
is set second.
* We want to ensure that set_pte_at is always called w/a pte that is not
valid. Change kunmap_atomic to
Hi Ben,
Here are two more PS3 patches for 2.6.27. Please apply.
-Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
From: Masakazu Mokuno [EMAIL PROTECTED]
Add sub match id for ps3 system bus so that two different system bus
devices can be connected to a shared device.
Signed-off-by: Masakazu Mokuno [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
arch/powerpc/platforms/ps3/device-init.c
On Wed, 2008-07-16 at 15:57 -0500, Kumar Gala wrote:
This makes sense. I think we need to order the stores in set_pte_at
regardless of CONFIG_SMP.
Nah, that shouldn't be necessary.
Also, I think we should change pte_clear to
use pte_update() so we only clear the low-order flag bits.
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
If we don't enable FS_ENET we get build issues:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
`alloc_mdio_bitbang'
Arnd Bergmann wrote:
Ok, I think this could be related mostly to two changes:
* In 2.6.23, the process scheduler was replaced, the new one
is the CFS,
the 'completely fair scheduler'. This has changed a lot of data.
To verify this, you could check out a git version just before and
just
On Jun 24, 2008, at 5:35 PM, Timur Tabi wrote:
The defconfigs for Freescale 85xx and 86xx SOCs had bad choices for
some
audio related options. In particular, OSS emulation should be
enabled,
and the old ALSA API should be disabled.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
On Jul 16, 2008, at 4:47 PM, Scott Wood wrote:
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
If we don't enable FS_ENET we get build issues:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
arch/powerpc/platforms/82xx/ep8248e.c:129: undefined reference to
On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
If we don't enable FS_ENET we get build issues:
arch/powerpc/platforms/built-in.o: In function `ep8248e_mdio_probe':
We need to pass the kernel stack pointer instead of the user space
stack pointer in save_stack_trace_tsk().
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
On Wednesday 16 July 2008, Nathan Lynch wrote:
Arnd Bergmann wrote:
Implement save_stack_trace_tsk on powerpc, so that we can run with
On Sat, 28 Jun 2008 13:16:16 -0600
Grant Likely [EMAIL PROTECTED] wrote:
On Sat, Jun 28, 2008 at 12:31 PM, Wolfram Sang
[EMAIL PROTECTED] wrote:
If an I2C device node does not specify an interrupt, the .irq
member of the board_info struct was set to -1. This caused crashes
on following
On Jul 16, 2008, at 4:41 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-07-16 at 15:57 -0500, Kumar Gala wrote:
This makes sense. I think we need to order the stores in set_pte_at
regardless of CONFIG_SMP.
Nah, that shouldn't be necessary.
Yeah I finally came to that realization.
Also,
On Wed, Jul 16, 2008 at 4:15 PM, Sean MacLennan [EMAIL PROTECTED] wrote:
On Sat, 28 Jun 2008 13:16:16 -0600
Grant Likely [EMAIL PROTECTED] wrote:
On Sat, Jun 28, 2008 at 12:31 PM, Wolfram Sang
[EMAIL PROTECTED] wrote:
If an I2C device node does not specify an interrupt, the .irq
member of
On Wed, Jul 16, 2008 at 05:10:29PM -0500, Kumar Gala wrote:
On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
If we don't enable FS_ENET we get build issues:
On Jul 16, 2008, at 5:10 PM, Kumar Gala wrote:
On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
If we don't enable FS_ENET we get build issues:
On Thu, 2008-07-17 at 00:12 +0200, Arnd Bergmann wrote:
We need to pass the kernel stack pointer instead of the user space
stack pointer in save_stack_trace_tsk().
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
On Wednesday 16 July 2008, Nathan Lynch wrote:
Arnd Bergmann wrote:
On Wednesday 16 July 2008, Rune Torgersen wrote:
I did run oprofile, but I could not figure out how to get it to show me
where in the kernel it was spending time. It showed that a lot of time
was spent in vmlinux, but not anything specific. I probably just don't
know how to set up or run
Arnd Bergmann wrote:
We need to pass the kernel stack pointer instead of the user space
stack pointer in save_stack_trace_tsk().
Thanks, this fixes it, and latencytop even seems to work. :)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
On Jul 16, 2008, at 5:19 PM, Dave Jones wrote:
On Wed, Jul 16, 2008 at 05:10:29PM -0500, Kumar Gala wrote:
On Jul 16, 2008, at 4:57 PM, Dave Jones wrote:
On Wed, Jul 16, 2008 at 04:47:23PM -0500, Scott Wood wrote:
On Wed, Jul 16, 2008 at 08:39:12AM -0500, Kumar Gala wrote:
If we don't
On Wednesday 16 July 2008, Grant Likely wrote:
Shouldn't it be enough to have a common compatible value in each
of these boards, e.g. amcc,generic-ppc44x and then just ignore the
specific type unless you need to do something special?
This is bad for the same reason that amcc,44x-blah
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
powerpc-next
Note: this tree is based on Linus's master as I need to revert a commit he
applied to the ep8248e board.
to receive the following updates:
Its possible to build the phylib as a module, however this breaks the
board code because alloc_mdio_bitbang and mdiobus_register are not
available if we build as a module. These are needed by the board code
since it implements the low level mdio bitbang ops.
So we unconditionally select PHYLIB
On Tue, 15 Jul 2008, Anton Vorontsov wrote:
Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
is not much code can be shared between the two drivers (both are mostly
driver bindings anyway).
Why can't this driver use the existing gpio-led driver? Basically, do
something
From: Lee Nipper [EMAIL PROTECTED]
Remove of_node_put calls since there is no corresponding of_node_get.
This patch prevents an exception when talitos is loaded a 2nd time.
This sequence: modprobe talitos; rmmod talitos; modprobe talitos
causes this message: WARNING: Bad of_node_put() on /[EMAIL
From: Lee Nipper [EMAIL PROTECTED]
Seems that dst == src, but this fixes the logic in case it's not.
Signed-off-by: Lee Nipper [EMAIL PROTECTED]
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
drivers/crypto/talitos.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
add requests pending/submit count to prevent request queue full
condition by preempting h/w overflow interrupts in software.
We do this due to the delay in the delivery and handling of the
channel overflow error interrupt.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
Acked-by: Lee Nipper [EMAIL
use GFP_ATOMIC when necessary; use atomic_t when allocating submit_count.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
Acked-by: Lee Nipper [EMAIL PROTECTED]
---
drivers/crypto/talitos.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c
free edescriptor when returning error (such as -EAGAIN).
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
Acked-by: Lee Nipper [EMAIL PROTECTED]
---
drivers/crypto/talitos.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c
On Tue, 15 Jul 2008, Richard Purdie wrote:
On Tue, 2008-07-15 at 18:23 +0400, Anton Vorontsov wrote:
Spell out openfirmware :). I initially had no idea of == openfirmware
and I suspect others won't either...
This would be unusually long name, that is
$ find . -iname '*openfirmware*' | wc -l
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
drivers/crypto/talitos.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index a81265b..681c15f 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@
On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
use GFP_ATOMIC when necessary; use atomic_t when allocating
submit_count.
why?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
. = ALIGN(0x1000) /* this align directive aparently gets lost
when stripping the file */
.rodata: AT (.rodata - LOAD_OFFSET): {
...
}
the effects of that align were dropped during strip, shifting all
following sections up in memory and the resulting failure.
The ELF
On 7/16/08, Milton Miller [EMAIL PROTECTED] wrote:
Hi.
Previous threads have mentioned that binutil-2.17 is broken for
building powerpc kernels. It is fixed in binutils-2.18.
I have encountered this and upgrading to 2.18 fixed my build. The
symptom is large kernel sizes and a long time in gzip.
On Wed, Jul 16, 2008 at 08:38:14PM -0400, Jon Smirl wrote:
On 7/16/08, Milton Miller [EMAIL PROTECTED] wrote:
Hi.
Previous threads have mentioned that binutil-2.17 is broken for
building powerpc kernels. It is fixed in binutils-2.18.
I have encountered this and upgrading to 2.18 fixed my
On Thu, 2008-07-17 at 00:58 +0200, Arnd Bergmann wrote:
On Wednesday 16 July 2008, Grant Likely wrote:
Shouldn't it be enough to have a common compatible value in each
of these boards, e.g. amcc,generic-ppc44x and then just ignore the
specific type unless you need to do something
Shouldn't it be enough to have a common compatible value in each
of these boards, e.g. amcc,generic-ppc44x and then just ignore the
specific type unless you need to do something special?
This is bad for the same reason that amcc,44x-blah compatible
values
are bad in device nodes. The
And then you don't need this file at all. Just add a
amcc,canyonlands string to your root node compatible property.
No! Don't do this because it is not true!
If the board actually _is_ compatible to the canyonlands board (it
only _adds_ stuff, doesn't change things or takes away things), it
Shouldn't it be enough to have a common compatible value in each
of these boards, e.g. amcc,generic-ppc44x and then just ignore the
specific type unless you need to do something special?
This is bad for the same reason that amcc,44x-blah compatible
values
are bad in device nodes. The
On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
On Tue, 15 Jul 2008, Anton Vorontsov wrote:
Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
is not much code can be shared between the two drivers (both are mostly
driver bindings anyway).
Why can't this
__WARN() is not defined for all configs, use WARN_ON(1) instead.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/lib/feature-fixups.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/lib/feature-fixups.c
The offb driver already has a collection of hacks to be able to set
the palette on various chips. This adds support for r5xx/r6xx radeons.
This is needed as offb is the only console solution on these currently
and the firmware in some cases sets a really bad color palette. This
fixes using some
on Wed, 16 Jul 2008, Grant Likely wrote:
On Wed, Jul 16, 2008 at 04:18:52PM -0700, Trent Piepho wrote:
On Tue, 15 Jul 2008, Anton Vorontsov wrote:
Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
is not much code can be shared between the two drivers (both are mostly
Nathan Lynch wrote:
Arnd Bergmann wrote:
We need to pass the kernel stack pointer instead of the user space
stack pointer in save_stack_trace_tsk().
Thanks, this fixes it, and latencytop even seems to work. :)
Sweet. One week from mention to working in -next...not bad.
My thanks to Arnd
On Wed, Jul 16, 2008 at 01:53:57PM -0400, Paul Gortmaker wrote:
It seems that some machines, like a default RHEL4 install, will
not have a definition for YYRHSLOC, and that prevents building
dtc. This supplies what appears to be the standard definition
for it in the event that the host system
The OF parsing code for PCI addresses isn't always treating properly
the address space indication 0b11 (ie. 0x3) as meaning 64 bits
memory space.
This means that it fails to parse addresses for PCI BARs that have
this encoding set by the firmware, which happens on some SLOF
versions and breaks
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
b/Documentation/powerpc/dts-bindings/gpio/led.txt
new file mode 100644
index 000..7e9ce81
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -0,0 +1,15 @@
+LED connected to GPIO
+
+Required properties:
+-
92 matches
Mail list logo
