Hi Linus !
Here are a bunch of minor powerpc updates for 2.6.31. Mostly a few
more alloc_bootmem -> km/zalloc changes to avoid warnings at boot,
a bug or two, minor cosmetic stuffs, and some changes of a whole
bunch of pr_debug() into pr_devel() for low level stuff that really
doesn't want those b
On Mon, 2009-06-22 at 08:34 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2009-06-21 at 20:18 +0200, Gerhard Pircher wrote:
> > Hi,
> >
> > Takashi Iwai posted patches to make ALSA work on non-coherent PPC32
> > systems (almost exactly) a year ago. See here:
> > http://www.nabble.com/-PATCH-0-3--
On Tue, 2009-07-07 at 21:23 -0400, Geoff Thorpe wrote:
> The bitops.h functions that operate on a single bit in a bitfield are
> implemented by operating on the corresponding word location. In all
> cases the inner logic is valid if the mask being applied has more than
> one bit set, so this patch
From: Anton Vorontsov
Date: Tue, 7 Jul 2009 22:38:42 +0400
> We can reclaim transmitted skbs to use in the receive path, so-called
> skb recycling support.
>
> Also reorder ucc_geth_poll() steps, so that we'll clean tx ring firstly,
> thus maybe reclaim some skbs for rx.
>
> Signed-off-by: Anto
From: Anton Vorontsov
Date: Tue, 7 Jul 2009 19:12:41 +0400
> ->restart() will dereference phydev, which is NULL.
>
> grep for 'phydev' in fs_enet/mac-*.c.
Ok, so this patch still needs a little bit more work.
Thanks for testing!
___
Linuxppc-dev mail
The bitops.h functions that operate on a single bit in a bitfield are
implemented by operating on the corresponding word location. In all
cases the inner logic is valid if the mask being applied has more than
one bit set, so this patch exposes those inner operations. Indeed,
set_bits() was already
On Wed, 2009-07-08 at 01:18 +0400, Andrey Gusev wrote:
> I tried this drive on ide1 and ide2, there are same issue. This drive worked
> on P-III before (as separate on channel, with another hard drive and with
> cdrom)
> and I didn't have any problem with it. There are chunks of dmesg.
Wow... It
On Tuesday 07 July 2009 21:08:25 Benjamin Herrenschmidt wrote:
> On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
> >
> > When the 32 and 64bit DMA code was merged in .28 , map_/unmap_page() was
> > added in favour of map_/unmap_single() (which was later removed in .29)
> > so you'll have to
Hi,
I'm trying to implement some PCI quirks for the AmigaOne, as the
firmware puts PCI devices with 16 bit BARs too high in the PCI I/O
space (above 64k). Currently I'm just writing new values to the BARs
before the PCI layer actually probes and allocates them:
static void quirk_vt82c686_sound_io
On Tue, 07 Jul 2009 09:23:42 +1000
Benjamin Herrenschmidt wrote:
> On Mon, 2009-07-06 at 17:04 +0200, Bartlomiej Zolnierkiewicz wrote:
>
> > > Delay is fixed itself in 2.6.31-rc2. Most likely it was platform
> > > specific issue. But lost interrupt still exists. There is log of
> > > 2.6.31-rc2:
Anton Vorontsov wrote:
On Tue, Jul 07, 2009 at 11:47:38AM -0700, Rick Jones wrote:
Admittedly, all the world is not TCP, but a big chunk is, so are you
likely to have reference counts go to zero on the tx queue for
anything other than small standalone TCP ACK segments?
That's a generic questi
On Tue, Jul 07, 2009 at 11:47:38AM -0700, Rick Jones wrote:
> Anton Vorontsov wrote:
> >We can reclaim transmitted skbs to use in the receive path, so-called
> >skb recycling support.
> >
> >Also reorder ucc_geth_poll() steps, so that we'll clean tx ring firstly,
> >thus maybe reclaim some skbs for
Anton Vorontsov wrote:
We can reclaim transmitted skbs to use in the receive path, so-called
skb recycling support.
Also reorder ucc_geth_poll() steps, so that we'll clean tx ring firstly,
thus maybe reclaim some skbs for rx.
Admittedly, all the world is not TCP, but a big chunk is, so are you
We can reclaim transmitted skbs to use in the receive path, so-called
skb recycling support.
Also reorder ucc_geth_poll() steps, so that we'll clean tx ring firstly,
thus maybe reclaim some skbs for rx.
Signed-off-by: Anton Vorontsov
---
drivers/net/ucc_geth.c | 40 +++
On Tue, Jul 07, 2009 at 03:45:29PM +0200, Roman Fietze wrote:
> Hallo,
>
> I tried to define my MTD partitions in a device tree as
> documented. The function of_flash_probe() inside teh file physmap_of.c
> never compiled the code below
>
> #ifdef CONFIG_MTD_OF_PARTS
>
> because when the MTD subs
On Jul 7, 2009, at 10:24 AM, Kári Davíðsson wrote:
Yes the device pointer was invalid.
I was passing the of_device pointer instead of
the address of of_device->dev.
But I am sure this was working (passing of_device pointer) with
earlier kernels.
Thanks for the help.
rg
kd
earlier kernels
On Tue, Jul 7, 2009 at 8:31 AM, Henk Stegeman wrote:
> I tried to make use of the irq-controller mode of the GPT as
> suggested, however I'm not getting the IRQ.
> Does anyone have an idea what I could be missing? (I've been testing
> with 2.6.30).
Make sure the 5200 general purpose timer driver i
On Jul 7, 2009, at 9:37 AM, Kumar Gala wrote:
On Jul 7, 2009, at 6:08 AM, Benjamin Herrenschmidt wrote:
On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
When the 32 and 64bit DMA code was merged in .28 , map_/
unmap_page() was
added in favour of map_/unmap_single() (which was later r
Yes the device pointer was invalid.
I was passing the of_device pointer instead of
the address of of_device->dev.
But I am sure this was working (passing of_device pointer) with
earlier kernels.
Thanks for the help.
rg
kd
Kumar Gala wrote:
On Jul 7, 2009, at 6:08 AM, Benjamin Herrenschmidt w
On Fri, Jul 03, 2009 at 04:20:19PM -0600, Grant Likely wrote:
> From: Grant Likely
>
> The MDIO rework patches broke the handling of fixed MII links.
[...]
> Signed-off-by: Grant Likely
> ---
> Anton, can you please review, comment and test? I've tested it on an
> mpc8349 board, but that is the
I tried to make use of the irq-controller mode of the GPT as
suggested, however I'm not getting the IRQ.
Does anyone have an idea what I could be missing? (I've been testing
with 2.6.30).
The driver reports from it's probe:
[1.502853] spi_master spi32766.0 Unable to get sample IRQ from of
My
On Jul 7, 2009, at 6:08 AM, Benjamin Herrenschmidt wrote:
On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
When the 32 and 64bit DMA code was merged in .28 , map_/
unmap_page() was
added in favour of map_/unmap_single() (which was later removed in .
29)
so you'll have to replace your
On Fri, Jul 03, 2009 at 04:20:19PM -0600, Grant Likely wrote:
> From: Grant Likely
>
> The MDIO rework patches broke the handling of fixed MII links.
[...]
> Signed-off-by: Grant Likely
> ---
> Anton, can you please review, comment and test? I've tested it on an
> mpc8349 board, but that is the
This patch sets the port autodetect mode as default for the ehca driver. The
autodetect code has been in the kernel for several releases now and has
proved to be stable.
---
Roland, please queue this change for 2.6.32 if you are okay with it.
drivers/infiniband/hw/ehca/ehca_main.c |8 ---
Hallo,
I tried to define my MTD partitions in a device tree as
documented. The function of_flash_probe() inside teh file physmap_of.c
never compiled the code below
#ifdef CONFIG_MTD_OF_PARTS
because when the MTD subsystem is compiled as a module I can only find
CONFIG_MTD_OF_PARTS_MODULE beeing
On Tue, Jul 07, 2009 at 02:40:02PM +0200, Andreas Schwab wrote:
> Gabriel Paubert writes:
>
> > On Fri, Jul 03, 2009 at 10:57:12PM +0200, Andreas Schwab wrote:
> >> The 'Z' constraint is required for a memory operand for insns that don't
> >> have an update form (which would be selected by the %U
On Mon, Jul 6, 2009 at 1:51 PM, Kári Davíðsson wrote:
> I am doing a driver that uses dma_map_single().
>
> After changing to to linux 2.6.29.3 I am getting
> segfaults in dma_map_single() because dma_ops->map_page is NULL.
> Actually dma_ops looks funky too.
>
> The driver is an of_platform_driver
Gabriel Paubert writes:
> On Fri, Jul 03, 2009 at 10:57:12PM +0200, Andreas Schwab wrote:
>> The 'Z' constraint is required for a memory operand for insns that don't
>> have an update form (which would be selected by the %U modifier).
>
> Hmmm, I believed that it was for instructions that only
On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
>
> When the 32 and 64bit DMA code was merged in .28 , map_/unmap_page() was
> added in favour of map_/unmap_single() (which was later removed in .29)
> so you'll have to replace your calls to dma_map_single() with
> dma_map_page(). Just pass i
On Tue, Jul 07, 2009 at 10:32:33AM +1000, Michael Ellerman wrote:
> I was also wondering, was this workaround ever required in a released
> chip - or was it just dev samples? If it's the latter, do we still need
> to carry it at all?
It's needed on all versions of hardware but for slightly differ
30 matches
Mail list logo
