Tejun Heo wrote:
Impact: remove spurious WARN on legacy SMP percpu allocator
Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
allocator. Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
for UP but legac
The following commits have been added to powerpc test:
Andrew Klossner (1):
powerpc/udbg: Fix lost byte during console handover; change LFCR
to CRLF
Benjamin Herrenschmidt (10):
powerpc/mm: Properly wire up get_user_pages_fast() on 32-bit
powerpc/kconfig: Kill PPC_MULTIPLATFORM
The following commits have been added to powerpc next:
Anton Vorontsov (1):
powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers
Arnd Bergmann (1):
powerpc/spufs: Initialize ctx->stats.tstamp correctly
Benjamin Herrenschmidt (1):
powerpc: Wire up /proc/vmallo
Impact: remove spurious WARN on legacy SMP percpu allocator
Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
allocator. Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
for UP but legacy SMP allocator was
Impact: remove spurious WARN on legacy SMP percpu allocator
Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
allocator. Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
for UP but legacy SMP allocator was
On Thu, 2009-03-05 at 13:53 -0600, Nathan Fontenot wrote:
> The return code from invoking the notifier chain when updating the
> ibm,dynamic-memory property is not handled properly. In failure
> cases (rc == NOTIFY_BAD) we should be restoring the original value
> of the property. In success (rc ==
On Mon, 2009-03-09 at 09:23 -0600, Grant Likely wrote:
> From: Grant Likely
>
> fixed-head.o must be linked into the bootwrapper for raw-binary images to
> work. This patch adds it into the bootwrapper.
>
> Signed-off-by: Grant Likely
> Reported-by: Eddie Dawydiuk
> ---
Ack :-)
> I pulled t
> Alan did have one valid point though. Determining how long to loop
> for is architecture-specific. Using jiffies is bad, because even one
> jiffy is too long. Adding a udelay() inside the loop means that it
> only checks he condition every microsecond. So the real solution is
> to use ke
Sachin P. Sant wrote:
While booting Next 20090310 on a powerpc box (Power6 9117-MMA)
i observed the following badness :
[0.339662] [ cut here ]
[0.339666] Badness at mm/allocpercpu.c:123
[0.339670] NIP: c01129dc LR: c01129b8 CTR
On Mon, 2009-03-09 at 13:59 +, David Woodhouse wrote:
> On Mon, 2009-03-09 at 14:26 +0100, Geert Uytterhoeven wrote:
> > PowerPC has been a long time user of the generic RTC abstraction, so hook up
> > rtc-generic:
> > - Create the "rtc-generic" platform device if ppc_md.get_rtc_time is set,
On Mon, 2009-03-09 at 16:36 +, David Howells wrote:
> In ehea_probe_adapter() the initial memory allocation and initialisation does
> not need to be done with the ehea_fw_handles.lock semaphore held. Doing so
> extends the amount of time the lock is held unnecessarily.
Can you resend with net
On Fri, 2009-03-06 at 23:45 +0100, Joachim Foerster wrote:
> Hi,
>
> On Fri, 2009-03-06 at 16:51 +0100, A. Nolson wrote:
> > just a little question. I am using 2.6.24-rc3 (secretlab) and I would
> > like to use c67x00 driver from Peter Kosgaard for USB-Host in my Xilinx
> > ML403 board. Is there
This moves some MMU related init code out of setup_64.c into hash_utils_64.c
and calls it early_init_mmu() and early_init_mmu_secondary(). This will
make it easier to plug in a new MMU type.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/mmu-hash64.h |2 -
arch/powerpc/i
ppc32 has it already, add it to ppc64 as a preliminary for adding
support for Book3E 64-bit support
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/pgtable-ppc64.h | 12 +++-
arch/powerpc/include/asm/pte-hash64.h|2 ++
2 files changed, 13 insertions(+), 1 de
We need to use %zu instead of %d when printing a sizeof()
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/mm/mmu_context_nohash.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/mm/mmu_context_nohash.c2009-03-11
11:51:05.0 +1100
This file is only useful on 64-bit, so we name it accordingly.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/mm/Makefile |2
arch/powerpc/mm/mmap.c| 109 --
arch/powerpc/mm/mmap_64.c | 109 +
Now that they are almost identical, we can merge some of the definitions
related to the PTE format into common files.
This creates a new pte-common.h which is included by both 32 and 64-bit
right after the CPU specific pte-*.h file, and which defines some
bits to "default" values if they haven't b
This patch tweaks the way some PTE bit combinations are defined, in such a
way that the 32 and 64-bit variant become almost identical and that will
make it easier to bring in a new common pte-* file for the new variant
of the Book3-E support.
The combination of bits defining access to kernel pages
This updates the 32-bit headers to use the same definitions for the RPN
shift inside the PTE as 64-bit, and thus updates _PAGE_CHG_MASK to
become identical.
This does introduce a runtime visible difference, which is that now,
_PAGE_HASHPTE will be part of _PAGE_CHG_MASK and thus preserved. However
CONFIG_PPC_MULTIPLATFORM is a remain of the pre-powerpc days and isn't
really meaningful anymore. It was basically equivalent to PPC64 || 6xx.
This removes it along with the following changes:
- 32-bit platforms that relied on PPC32 && PPC_MULTIPLATFORM now rely
on 6xx which is what they want
This series of patches does some ground work to make 32 and 64-bit
page table and PTE access slightly more common and to facilitate
the addition of a new MMU type (Book3-E version 2.06 and later)
for which I'd like to be able to use the same definitions for both
32 and 64-bit implementations.
Ther
While we did add support for _PAGE_SPECIAL on some 32-bit platforms,
we never actually built get_user_pages_fast() on them. This fixes
it which requires a little bit of ifdef'ing around.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/mm/Makefile |4 ++--
arch/powerpc/mm/gup.c|
> Yes, you could phrase it that way. According to the PPC440EPx manual,
> the total memory size is calculated based on the following formula:
> memsize = cs * (1 << (col+row)) * bank * dpath;
> So, if both chipselects are used, we add an extra bit to the memory
> address to distinguish between t
On Wed, 2009-03-11 at 00:46 +, Thomas Gleixner wrote:
> plain text document attachment
> (powerpc-convert-obsolete-hw-interrupt-type.patch)
> Impact: cleanup
>
> Convert the last remaining users to struct irq_chip.
Ack too, same comment, happy to have that one in powerpc.
Ben.
> Signed-off-
On Wed, 2009-03-11 at 00:45 +, Thomas Gleixner wrote:
> plain text document attachment
> (powerpc-convert-obsolete-irq-desc-t-typedef.patch)
> Impact: cleanup
>
> Convert the last remaining users.
Ack. This would be more easily carried in my -next tree if that's ok
with you.
> Signed-off-by:
Mikhail Zolotaryov wrote:
Valentine Barshak wrote:
According to the AMCC 440EPX/GRX user manual,
the Chip Select width is always fixed at 1 bit no matter
what is actually read from register DDR_10.
Well, from my point of view original kernel code is correct in this part.
Adding one bit into m
Impact: cleanup
Convert the last remaining users to struct irq_chip.
Signed-off-by: Thomas Gleixner
CC: Benjamin Herrenschmidt
CC: linuxppc-dev@ozlabs.org
---
arch/powerpc/include/asm/hw_irq.h |2 +-
arch/powerpc/platforms/powermac/pic.h |2 +-
2 files changed, 2 insertions(+), 2 d
Impact: cleanup
Convert the last remaining users.
Signed-off-by: Thomas Gleixner
CC: Benjamin Herrenschmidt
CC: linuxppc-dev@ozlabs.org
---
arch/powerpc/kernel/irq.c|4 ++--
arch/powerpc/platforms/iseries/irq.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
Index:
On Wed, Mar 11, 2009 at 10:59:11AM +1100, Benjamin Herrenschmidt wrote:
>On Tue, 2009-03-10 at 18:37 -0400, Josh Boyer wrote:
>> On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
>> > Timur Tabi wrote:
>> >> The macro spin_event_timeout() takes a condition and timeout value
>> >> (in micr
On Tue, Mar 10, 2009 at 05:58:58PM -0500, Scott Wood wrote:
> Josh Boyer wrote:
>> On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
>>> Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either t
On Tue, Mar 10, 2009 at 6:59 PM, Benjamin Herrenschmidt
wrote:
> And ? We can disagree with Alan...
If you guys want to argue with Alan on lkml, please go ahead. I could
use the support.
Alan did have one valid point though. Determining how long to loop
for is architecture-specific. Using ji
On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote:
>
> Alan did have one valid point though. Determining how long to loop
> for is architecture-specific. Using jiffies is bad, because even one
> jiffy is too long. Adding a udelay() inside the loop means that it
> only checks he condition ever
On Wed, 2009-03-11 at 01:39 +0200, Felix Radensky wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2009-03-11 at 00:14 +0200, Felix Radensky wrote:
> >
> >> Yes, seems logical. U-boot has code to enable and disable loopback clock
> >> for 440SPE, 440EPX,440GRX,405EX, 460EX and 460GT.
> >>
> >>
On Tue, 2009-03-10 at 18:37 -0400, Josh Boyer wrote:
> On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
> > Timur Tabi wrote:
> >> The macro spin_event_timeout() takes a condition and timeout value
> >> (in microseconds) as parameters. It spins until either the condition is
> >> true
>
On Tue, 2009-03-10 at 17:11 -0500, Timur Tabi wrote:
> The macro spin_event_timeout() takes a condition and timeout value
> (in microseconds) as parameters. It spins until either the condition is true
> or the timeout expires. It returns zero if the timeout expires first,
> non-zero
> otherwise.
Hi Linus !
Here are some late fixes for 2.6.29. I've included a radeonfb/aty128fb commit
as it only affects a powerpc specific code path and solves a reported
regression.
There's also an hvc_console commit that only affects powerpc pseries backends,
and also solves a regression. The rest are defc
On Tue, Mar 10, 2009 at 4:55 PM, Johns Daniel wrote:
> For those of you who are running into this error:
> 24520:01 not found
> eth0: Could not attach to PHY
> IP-Config: Failed to open eth0
> IP-Config: Device `eth0' not found.
>
> There is a bug in recent kernels. I f
Unfortunately, the 2.6.24-rc3 stuff in my git tree is really old.
I've been getting all of my recent work into mainline. The CF driver
is in much better shape there. The c67x00 driver is merged into
mainline, but I haven't tested it at all in the last year so I don't
know how well it will work.
Hi,
I am using 2.6.24-rc3 ( secretlabs git) in an ML403 where I want to
use the USB c67x00 based host with Peter Kosgaard driver. I am using it
together with the sysace device for CF access ( in the ML403 those two
share lines, but I managed to insert some logic to multiplex both
devices). I hav
(I did not get to complete the message!)
For those of you who are running into this error:
24520:01 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
There is a bug in recent kernels. I found it in 2.6.28.7:
Josh Boyer wrote:
On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns zero if the timeou
For those of you who are running into this error:
24520:01 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
There is a bug in recent kernels. I found it in 2.6.28.7:
linux/arch/powerpc/sysdev/fsl_soc.c.~1
On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
> Timur Tabi wrote:
>> The macro spin_event_timeout() takes a condition and timeout value
>> (in microseconds) as parameters. It spins until either the condition is true
>> or the timeout expires. It returns zero if the timeout expires f
Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns zero if the timeout expires first, non-zero
otherwise.
This primary purpose of this macro is to p
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns zero if the timeout expires first, non-zero
otherwise.
This primary purpose of this macro is to poll on a hardware re
Valentine Barshak wrote:
According to the AMCC 440EPX/GRX user manual,
the Chip Select width is always fixed at 1 bit no matter
what is actually read from register DDR_10.
Well, from my point of view original kernel code is correct in this part.
Adding one bit into memory address means multipl
I was just going to submit a patch for that too.
Indeed, the denali_fixup_memsize() miscalculated a couple of address
field widths. We were lucky to eventually get the right result,
because the effect of the first error was killed by the other one.
According to the AMCC 440EPX/GRX user manual,
the
On Tue, Mar 10, 2009 at 01:48:26PM -0600, Grant Likely wrote:
[...]
> >> eliminates the assumption that the PHY for the FEC is always
> >> attached to the FEC's own MDIO bus. With this patch, the FEC can
> >> use a PHY attached to any MDIO bus if it is described in the device
> >> tree.
> >
> > AFA
On Tue, Mar 10, 2009 at 1:16 PM, Anton Vorontsov
wrote:
> On Tue, Mar 10, 2009 at 09:22:24AM -0600, Grant Likely wrote:
>> From: Grant Likely
> [...]
>> +static int mpc52xx_fec_notifier_phy_add(struct notifier_block *nb,
>> + unsigned long event, void *_dev)
>>
On Tue, Mar 10, 2009 at 09:22:24AM -0600, Grant Likely wrote:
> From: Grant Likely
[...]
> +static int mpc52xx_fec_notifier_phy_add(struct notifier_block *nb,
> + unsigned long event, void *_dev)
> +{
[...]
> + rc = phy_connect_direct(priv->ndev, priv->phyde
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
(The i2c patch was ack'd by Ben Dooks & cpm_uart has historically gone via
powerpc tree as a PPC specific driver).
Documentation/powerpc/dts-bindings/f
On Mar 9, 2009, at 10:09 PM, Liu Yu wrote:
There is no dependece between efp and math-emu.
But when disalbe math-emu, the efp code cannot be built.
This patch fixes it.
Signed-off-by: Liu Yu
---
It would be nice to see this patch go along with 2.6.29
not critical enough for .29. applied to
On Mar 10, 2009, at 1:43 PM, Thomas Gleixner wrote:
setup_irq(0, NULL) is broken as setup_irq() dereferences action
unconditionally.
Signed-off-by: Thomas Gleixner
CC: Kumar Gala
CC: Linux PPC Development
---
arch/powerpc/platforms/85xx/ksi8560.c |2 --
1 file changed, 2 deletions(-)
a
setup_irq(0, NULL) is broken as setup_irq() dereferences action
unconditionally.
Signed-off-by: Thomas Gleixner
CC: Kumar Gala
CC: Linux PPC Development
---
arch/powerpc/platforms/85xx/ksi8560.c |2 --
1 file changed, 2 deletions(-)
Index: linux-2.6-tip/arch/powerpc/platforms/85xx/ksi8560
Hi,
not critical problem here.
IBM EMAC driver performs device reset (drivers/net/ibm_newemac/core.c:
emac_probe() -> emac_init_phy() -> emac_reset()) before registering
appropriate net_device (emac_probe() -> register_netdev()), so
net_device name contains raw format string during EMAC reset
On Tue, Mar 10, 2009 at 11:19 AM, David Miller wrote:
> Send it to netdev, CC:'d to me, Jeff hasn't been handling networking
> driver changes for a while now.
Ah, okay. I didn't know. I looked in MAINTAINERS today, and Jeff is
listed there for NETWORK DEVICE DRIVERS.
g.
--
Grant Likely, B.Sc
From: Grant Likely
Date: Tue, 10 Mar 2009 11:13:02 -0600
> Hi Henk,
>
> Acked-by: Grant Likely
...
> Jeff, after Henk provides his s-o-b line, do you want to pick it up,
> or should I merge it through my mpc52xx powerpc tree (via benh).
Send it to netdev, CC:'d to me, Jeff hasn't been handlin
Hi Henk,
Acked-by: Grant Likely
Can you please repost with a blurb for the commit description and your
signed-off-by line? The blub below makes sense in the context of this
mailing list thread, but it won't be very useful for someone looking
at the commit message in git. Also, your patch is li
On 03/09/2009 06:26 AM, Geert Uytterhoeven wrote:
> Create a real RTC driver for PS3, and unhook the deprecated
> ppc_md.[gs]et_rtc_time.
>
> Signed-off-by: Geert Uytterhoeven
> Cc: Geoff Levand
> ---
> arch/powerpc/include/asm/ps3.h|3 +
> arch/powerpc/platforms/ps3/os-area.c |
Signed-off-by: Wolfram Sang
---
Changes since V1:
* removed defconfig
* reworked localbus node
arch/powerpc/boot/dts/pcm032.dts | 392 ++
arch/powerpc/platforms/52xx/Kconfig |1 +
arch/powerpc/platforms/52xx/mpc5200_simple.c |3 +-
3 files ch
From: Grant Likely
The patch reworks the MPC5200 Fast Ethernet Controller (FEC) driver to
use the of_mdio infrastructure for registering PHY devices from data out
openfirmware device tree, and eliminates the assumption that the PHY
for the FEC is always attached to the FEC's own MDIO bus. With t
From: Grant Likely
Add support for parsing the device tree for PHY devices on an MDIO bus
CC: Andy Fleming
CC: linuxppc-dev@ozlabs.org
CC: devtree-disc...@ozlabs.org
Signed-off-by: Grant Likely
---
drivers/of/Kconfig |6
drivers/of/Makefile |1 +
drivers/of/of_mdio.c
From: Grant Likely
Add phy_connect_direct() and phy_attach_direct() functions so that
drivers can use a pointer to the phy_device instead of trying to determine
the phy's bus_id string.
This patch is useful for OF device tree descriptions of phy devices where
the driver doesn't need or know what
From: Grant Likely
This patch makes changes in preparation for supporting open firmware
device tree descriptions of MDIO busses. Changes include:
- Cleanup handling of phy_map[] entries; they are already NULLed when
registering and so don't need to be re-cleared, and it is good practice
to c
From: Grant Likely
bus_register_notifier_alldev() is a variation on bus_register_notifier()
which also triggers the notifier callback for devices already on the bus
and already bound to drivers.
This function is useful for the case where a driver needs to get a
reference to a struct device other
Hi all,
This series reworks some of the phylib code to allow PHY descriptions and
connections to be extracted from the OF device tree. MDIO bus drivers gain
a common helper function for parsing the PHY data and registering new
phy_devices to match. Ethernet controller drivers gain the ability to
On Mar 10, 2009, at 9:38 AM, Kumar Gala wrote:
From: Ted Peters
The PCI irqs for the protected sources where not correct for PCI PHBs
Signed-off-by: Ted Peters
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts |2 +-
arch/powerpc/boot/dts/mpc8572ds_camp_core1.
From: Ted Peters
The PCI irqs for the protected sources where not correct for PCI PHBs
Signed-off-by: Ted Peters
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts |2 +-
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts |2 +-
2 files changed, 2 insertions(+),
Mel Gorman wrote:
Well, the machine must have started with some kernel. What mainline
version does that correspond to and can you bisect it?
The last booted kernel was a 2.6.25 based kernel. I am trying to find out
the last good kernel.org kernel. I should have that information by tomorrow.
Hello all：
We use the AMCC PowerPC 405ex through emac1 way RGMII with realtek RTL8211
Giga phy linked to, At present the PHY Address is: 00110
add delay 2ns for RGMII
CONFIG[8:5]:AUTO_Negotiation
=NWay,advertise ，all capabilities,prefer Slave
mode;1=RGMII mode
Clk on the hardwar
While booting Next 20090310 on a powerpc box (Power6 9117-MMA)
i observed the following badness :
[0.339662] [ cut here ]
[0.339666] Badness at mm/allocpercpu.c:123
[0.339670] NIP: c01129dc LR: c01129b8 CTR:
[0.339676] REGS
On Tue, Mar 10, 2009 at 11:36:41AM +0530, Sachin P. Sant wrote:
> Sachin P. Sant wrote:
>> sure if this is a new problem or a recurring one. Will try booting
>> some older kernels on this box and will report the results.
> I tried few older kernels till 2.6.28 and all of them had the
> same problem
On Tue, Mar 10, 2009 at 11:36:15AM +1100, Benjamin Herrenschmidt wrote:
>On Mon, 2009-03-09 at 20:05 -0400, Josh Boyer wrote:
>> [cfffb830] [c05fe504] .mutex_lock_nested+0x78/0x4b0
>> (unreliable)
>> [cfffb950] [c039d520] .echo_char_raw+0x40/0x98
>> [cfffb9f0
On Tue, 10 Mar 2009 10:21:14 +0100 (CET)
Geert Uytterhoeven wrote:
> Alessandro prefers not to have generic RTC drivers on top of some other
> abstraction, but wants platform/chip-specific drivers under drivers/rtc/
> instead. The goal is to convert all RTC drivers buried in platform code
> to se
On Mon, 9 Mar 2009, Geoff Levand wrote:
> On 03/09/2009 06:26 AM, Geert Uytterhoeven wrote:
> > Create a real RTC driver for PS3, and unhook the deprecated
> > ppc_md.[gs]et_rtc_time.
>
> > 8 files changed, 132 insertions(+), 18 deletions(-)
>
> Sorry, I hadn't been following the discussion clos
75 matches
Mail list logo
