* Re: [PATCH 5/5 v2] kernel handling of CPU DLPAR
From: Michael Ellerman @ 2009-10-16 0:52 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4AD74261.9040504@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]
On Thu, 2009-10-15 at 10:40 -0500, Nathan Fontenot wrote:
> Michael Ellerman wrote:
> > On Tue, 2009-10-13 at 13:14 -0500, Nathan Fontenot wrote:
> >> This adds the capability to DLPAR add and remove CPUs from the kernel. The
> >> creates two new files /sys/devices/system/cpu/probe and
> >> /sys/devices/system/cpu/release to handle the DLPAR addition and removal of
> >> CPUs respectively.
> >
> > How does this relate to the existing cpu hotplug mechanism? Or is this
> > making the cpu exist (possible), vs marking it as online?
>
> This update makes the cpu exist, it does not mark the cpu online.
>
> >
> > Is some other platform going to want to do the same? ie. should the
> > probe/release part be in generic code?
>
> I thought about making this generic code, perhaps a follow-on patch to move
> the creation of the probe/release files to generic code to see what the
> community thinks. I would assume there would still need to be a arch and/or
> platforms specific callout to do the real work.
I'm not so worried about the code being generic, there's not much that
would be generic. More the mechanism. We don't want to add probe/release
to powerpc, and then have a different mechanism get added later by some
other platform, or generically.
But I guess you CC'ed lkml and there's not much more to do, I don't know
specifically who'd care about it.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
From: Stephen Rothwell @ 2009-10-15 23:38 UTC (permalink / raw)
To: Grant Likely
Cc: monstr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <fa686aa40910151006k43b07c30q1e43c3b1ae4af561@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]
Hi Grant,
On Thu, 15 Oct 2009 11:06:15 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> In the mean time, I've pushed out the current series with acked-bys
> added to my git server. I think I'm ready for things to start going
> into linux-next. Since this is the first time I've asked for a tree
> to be added to linux-next, please let me know if you see anything
> troublesome or problematic. Here's the tree:
>
> The following changes since commit 4bdf0bb7d64cf672199519b3d808e2a82f5b59e9:
> Grant Likely (1):
> powerpc/5200: Update defconfigs
Um, that commit is in no tree but yours ...
> are available in the git repository at:
>
> git://git.secretlab.ca/git/linux-2.6 next-devicetree
I have added this for today, but note that it contains stuff that is not
devicetree related. Trees in linux-next should be based on other trees
in linux-next (almost always Linus' tree, but any other nonrebasing tree
is fine).
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: Wolfgang Denk @ 2009-10-15 23:10 UTC (permalink / raw)
To: Paul Gibson; +Cc: Kári Davíðsson, linuxppc-dev@ozlabs.org
In-Reply-To: <26b052040910151603y8fc9b00g678d6a873083f1e7@mail.gmail.com>
Dear Paul,
In message <26b052040910151603y8fc9b00g678d6a873083f1e7@mail.gmail.com> you wrote:
>
> > The "ltib-mpc5121ads-20090602" branch reflects the exact state of the
> > kernel contained in the LTIB with this name (dated July 2009, despite
> > the name; based at 2.6.24.6, i. e. 7+ kernel versions behind).
>
> I have diff'ed this and it is very similar to the ltib in the BSP.
> The MBX patches may be missing though. These patches can be obtained
> via the Freescale SDK for the OpenGL on the MPC5121e webpage.
Who cares. This code is about 8 (!) kernel releases behind. Scrap
it.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Were there fewer fools, knaves would starve. - Anonymous
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: Paul Gibson @ 2009-10-15 23:03 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Kári Davíðsson, linuxppc-dev@ozlabs.org
In-Reply-To: <20091015183039.A577EECA6BE@gemini.denx.de>
>> The kernel from the BSP on Freescale site is crashing on the CAN in my c=
ase
>> =A0(might be a hardware bug).
>
> I don;t think so. There are some problems in this code, for example
> the clocks seem to be wrong. Not toi menthin that the whole code is
> hoplessly old and without chance of ever being merged into mainline.
The clocks are definitely wrong, but should not cause the crashing.
The only fix I needed for the ADS512101 board was to set the clock to
66MHz, instead of 100MHz in drivers/can/mscan/mscan.c:
clk->rate =3D 66000000;
Its a hack I know.
> The "ltib-mpc5121ads-20090602" branch reflects the exact state of the
> kernel contained in the LTIB with this name (dated July 2009, despite
> the name; based at 2.6.24.6, i. e. 7+ kernel versions behind).
I have diff'ed this and it is very similar to the ltib in the BSP.
The MBX patches may be missing though. These patches can be obtained
via the Freescale SDK for the OpenGL on the MPC5121e webpage.
Paul
^ permalink raw reply
* Re: [PATCH 0/8] Fix 8xx MMU/TLB
From: Scott Wood @ 2009-10-15 22:04 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1255597466-30976-1-git-send-email-Joakim.Tjernlund@transmode.se>
Joakim Tjernlund wrote:
> Now updated with Scott's remarks.
> There is still(probably) a trivial conflict in pte-8xx.h
>
> Joakim Tjernlund (8):
> 8xx: invalidate non present TLBs
> 8xx: Update TLB asm so it behaves as linux mm expects.
> 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
> 8xx: Fixup DAR from buggy dcbX instructions.
> 8xx: Add missing Guarded setting in DTLB Error.
> 8xx: Restore _PAGE_WRITETHRU
> 8xx: start using dcbX instructions in various copy routines
> 8xx: Remove DIRTY pte handling in DTLB Error.
>
> arch/powerpc/include/asm/pte-8xx.h | 14 +-
> arch/powerpc/kernel/head_8xx.S | 341 +++++++++++++++++++++++------------
> arch/powerpc/kernel/misc_32.S | 18 --
> arch/powerpc/lib/copy_32.S | 24 ---
> arch/powerpc/mm/fault.c | 8 +-
> 5 files changed, 238 insertions(+), 167 deletions(-)
I still see the lockup with the dcbX patch. Reverting that (and with
Rex's patch) things look OK.
-Scott
^ permalink raw reply
* Re: powerpc problem with .data.page_aligned -> __page_aligned_data conversion
From: Benjamin Herrenschmidt @ 2009-10-15 20:00 UTC (permalink / raw)
To: Tim Abbott
Cc: linuxppc-dev, Andrew Morton, Linus Torvalds, sam,
linux-kernel@vger.kernel.org
In-Reply-To: <alpine.DEB.1.10.0910151229340.25434@dr-wily.mit.edu>
On Thu, 2009-10-15 at 12:37 -0400, Tim Abbott wrote:
> Just to make sure I understand the nature of the problem, is the
> current
> breakage that gcc < 4.3 will _warn_ on any compilation units on ppc64
> that
> use __page_aligned data, or something worse?
>
> The cropping is clearly a potential problem, but I read the rest of
> your
> email as saying that the cropping of the alignment isn't actually a
> problem with the current kernel because the kernel is currently only
> using
> the macro with things whose size is divisible by PAGE_SIZE. However,
> I am
> not sure how to reconcile that with using the word "break" above...
Break is because we use -Werror on arch/powerpc :-)
Ben.
^ permalink raw reply
* [patch 2/5] macintosh: Remove BKL from nvram driver
From: Thomas Gleixner @ 2009-10-15 20:28 UTC (permalink / raw)
To: LKML; +Cc: Arnd Bergmann, ALan Cox, linuxppc-dev
In-Reply-To: <20091015202722.372890083@linutronix.de>
Drop the bkl from nvram_llseek() as it obviously protects nothing. The
file offset is safe in essence.
The ioctl can be converted to unlocked_ioctl because it just calls
pmac_get_partition() which reads a value from an array which was
initialized at early boot time. No need for serialization.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
---
drivers/macintosh/nvram.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
Index: linux-2.6-tip/drivers/macintosh/nvram.c
===================================================================
--- linux-2.6-tip.orig/drivers/macintosh/nvram.c
+++ linux-2.6-tip/drivers/macintosh/nvram.c
@@ -13,7 +13,6 @@
#include <linux/fcntl.h>
#include <linux/nvram.h>
#include <linux/init.h>
-#include <linux/smp_lock.h>
#include <asm/uaccess.h>
#include <asm/nvram.h>
@@ -21,7 +20,6 @@
static loff_t nvram_llseek(struct file *file, loff_t offset, int origin)
{
- lock_kernel();
switch (origin) {
case 1:
offset += file->f_pos;
@@ -30,12 +28,10 @@ static loff_t nvram_llseek(struct file *
offset += NVRAM_SIZE;
break;
}
- if (offset < 0) {
- unlock_kernel();
+ if (offset < 0)
return -EINVAL;
- }
+
file->f_pos = offset;
- unlock_kernel();
return file->f_pos;
}
@@ -76,8 +72,7 @@ static ssize_t write_nvram(struct file *
return p - buf;
}
-static int nvram_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, unsigned long arg)
+static long nvram_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
switch(cmd) {
case PMAC_NVRAM_GET_OFFSET:
^ permalink raw reply
* Re: UBIFS problem on MPC8536DS
From: Scott Wood @ 2009-10-15 20:07 UTC (permalink / raw)
To: Felix Radensky
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
Adrian Hunter
In-Reply-To: <4AD614E4.6030005@freescale.com>
Scott Wood wrote:
> Felix Radensky wrote:
>> Yes, NAND and NOR are on the same local bus controller.
>>
>> Maybe powerpc folks can provide some insight here.
>> Is it possible that simultaneous access to NOR and NAND
>> on MPC8536 can result in NAND timeouts ?
>
> I've heard other reports of such problems with eLBC, but was unable to
> reproduce it myself last time I tried. Could you reduce this down to a
> minimal set of specific reproduction instructions (e.g. eliminate UBI if
> possible, or else explain how to set up UBI)?
OK, I was able to reproduce the problem on mpc8572 simply by sticking a
read to NOR flash inside fsl_elbc_run_command -- I'm not sure what
happened last time I tried.
I suppose we'll need a special NOR mapping driver that does some sync
with the NAND driver.
-Scott
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Scott Wood @ 2009-10-15 19:32 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linuxppc-dev, brueckner, Timur Tabi, Alan Cox,
Linux Kernel Mailing List
In-Reply-To: <200910152126.28024.borntraeger@de.ibm.com>
Christian Borntraeger wrote:
> About the backends, there are some that spin until the text is delivered (e.g.
> virtio) , others can drop (e.g. iucv is a connection oriented protocol and it
> will (and has to) drop if there is no connection).
Sure, dropping due to not having a connection makes sense. That's
different from merely being busy. Can the iucv code tell the difference
between those two states?
-Scott
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Christian Borntraeger @ 2009-10-15 19:26 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev, brueckner, Timur Tabi, Alan Cox,
Linux Kernel Mailing List
In-Reply-To: <4AD770A9.6070509@freescale.com>
Am Donnerstag 15 Oktober 2009 20:57:45 schrieb Scott Wood:
> Doing it in the backend requires the backend to know whether it's being
> called for printk or for user I/O. In the latter case, we don't want to
> spin, but rather wait for an IRQ (or poll with a timer if there's no IRQ).
Right. Now you have me convinced that we really should have some logic in
hvc_console because, its the only place that knows if it came from printk or
user.
About the backends, there are some that spin until the text is delivered (e.g.
virtio) , others can drop (e.g. iucv is a connection oriented protocol and it
will (and has to) drop if there is no connection).
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Scott Wood @ 2009-10-15 18:57 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linuxppc-dev, brueckner, Timur Tabi, Alan Cox,
Linux Kernel Mailing List
In-Reply-To: <200910152041.26646.borntraeger@de.ibm.com>
Christian Borntraeger wrote:
> Right. Looking at more drivers it seems that both ways (waiting and dropping)
> are used.
>
> Hmmm, if we are ok with having both options, we should let the hvc backend
> decide if it wants to drain or to discard.
I'd say the dropping approach is quite undesirable (significant
potential for output loss unless the buffer is huge), unless there's
simply no way to safely spin. Hopefully there are no such backends, but
if there are perhaps we can have them return some special code to
indicate that.
> If we just busy loop, it actually does not matter how we let hvc_console react
> on 0, as long as we adopt all backends to use that interface consistent.
>
> On the other hand, backends might want to do special magic on congestion so I
> personally tend to let the backend loop instead of hvc_console. But I am really
> not sure.
Doing it in the backend requires the backend to know whether it's being
called for printk or for user I/O. In the latter case, we don't want to
spin, but rather wait for an IRQ (or poll with a timer if there's no IRQ).
-Scott
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Timur Tabi @ 2009-10-15 18:55 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Scott Wood, linuxppc-dev, brueckner, Linux Kernel Mailing List,
Alan Cox
In-Reply-To: <200910152041.26646.borntraeger@de.ibm.com>
Christian Borntraeger wrote:
> Hmmm, if we are ok with having both options, we should let the hvc backend
> decide if it wants to drain or to discard.
>
> If we just busy loop, it actually does not matter how we let hvc_console react
> on 0, as long as we adopt all backends to use that interface consistent.
>
> On the other hand, backends might want to do special magic on congestion so I
> personally tend to let the backend loop instead of hvc_console. But I am really
> not sure.
The reason that we're asking for this change is that I have an hvc client driver that drops characters during heavy printk() output. hvc calls my driver, but the output buffer is still full, so the driver just returns 0.
If I add a spin-loop in the driver, then we don't need to change hvc, but now the driver is blocking during user-space print operations (via hvc_write and hvc_push).
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Christian Borntraeger @ 2009-10-15 18:41 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev, brueckner, Timur Tabi, Alan Cox,
Linux Kernel Mailing List
In-Reply-To: <20091015160906.GA3730@loki.buserror.net>
Am Donnerstag 15 Oktober 2009 18:09:06 schrieb Scott Wood:
> On Thu, Oct 15, 2009 at 01:05:47PM +0200, Christian Borntraeger wrote:
> > The fact that struct console->write returns void indicates that the
> > console layer is not interested in errors. We have two policies we can
> > implement:
> >
> > 1. drop console messages if case of congestion but keep the system going
> > 2. dont drop messages and wait, even if the system might come to a
> > complete stop
> >
> > Looking at drivers/char/vt.c
> > /* console busy or not yet initialized */
> > if (!printable)
> > return;
> > if (!spin_trylock(&printing_lock))
> > return;
> > could mean that Linux consoles should not block.
>
> That's a bit different -- the code above is testing for potential deadlocks
> within Linux (or a not-yet-initialized console), not a device that has yet
> to process the last batch of characters we threw at it. Plus, given the
> "console must be locked when we get here" comment, I'm not sure that you'll
> ever see contention on printing_lock?
>
> Serial consoles currently block when waiting for the buffer to drain:
Right. Looking at more drivers it seems that both ways (waiting and dropping)
are used.
Hmmm, if we are ok with having both options, we should let the hvc backend
decide if it wants to drain or to discard.
If we just busy loop, it actually does not matter how we let hvc_console react
on 0, as long as we adopt all backends to use that interface consistent.
On the other hand, backends might want to do special magic on congestion so I
personally tend to let the backend loop instead of hvc_console. But I am really
not sure.
Christian
^ permalink raw reply
* Re: MPC5121 CAN and USB
From: Wolfgang Denk @ 2009-10-15 18:30 UTC (permalink / raw)
To: Kári Davíðsson
Cc: linuxppc-dev@ozlabs.org, paul.gibson2074@gmail.com
In-Reply-To: <4AD70927.3030401@marel.com>
Dear =?ISO-8859-1?Q?K=E1ri_Dav=ED=F0sson?=,
In message <4AD70927.3030401@marel.com> you wrote:
>
> The kernel from the BSP on Freescale site is crashing on the CAN in my case
> (might be a hardware bug).
I don;t think so. There are some problems in this code, for example
the clocks seem to be wrong. Not toi menthin that the whole code is
hoplessly old and without chance of ever being merged into mainline.
> I could not find the source for the kernel in the BSP or on the freescale site.
Extracting just the sources from LTIB (without actually building all
of it) is indeed not exactly easy.
> I had not looked at http://git.denx.de/?p=linux-2.6-denx.git;a=shortlog;h=refs/heads/ltib-mpc5121ads-20090602
Be careful. There are several branches that are intended for reference
only, or reflect work in progress. These are usually not intended for
use real use in a project:
The "ltib-mpc5121ads-20090602" branch reflects the exact state of the
kernel contained in the LTIB with this name (dated July 2009, despite
the name; based at 2.6.24.6, i. e. 7+ kernel versions behind).
The "mpc512x" branch contains a much smaller subset of drivers, but is
based on a more recent kernel tree (2.6.31-rc5) and is the base of our
(currently dozing) attempts to push this code into mainline.
> I am now in the progress of cloning the linux-mpc512x git from denx and building from it.
> Hopefully that will help me.
Do not do this. This old repository was intended for co-operation
with John Rigby, when he was still working for Freescale. It is a
dead end and totally unsupported. Guess I should remove it. Indeed.
Removed now. Sorry for the confusion.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Anyone who knows history, particularly the history of Europe, will, I
think, recognize that the domination of education or of government by
any one particular religious faith is never a happy arrangement for
the people. - Eleanor Roosevelt
^ permalink raw reply
* Re: [PATCH 2/2][v2] powerpc: Make the CMM memory hotplug aware
From: Gerald Schaefer @ 2009-10-15 18:21 UTC (permalink / raw)
To: linux-kernel, linux-mm, linuxppc-dev, Robert Jennings
Cc: Nick Piggin, Christoph Lameter, Mel Gorman, Martin Schwidefsky,
Badari Pulavarty, KAMEZAWA Hiroyuki, Brian King, Paul Mackerras,
Ingo Molnar, gerald.schaefer
In-Reply-To: <20091008131355.GA22118@austin.ibm.com>
Robert Jennings wrote:
>>> @@ -110,6 +125,9 @@ static long cmm_alloc_pages(long nr)
>>> cmm_dbg("Begin request for %ld pages\n", nr);
>>>
>>> while (nr) {
>>> + if (atomic_read(&hotplug_active))
>>> + break;
>>> +
>>> addr = __get_free_page(GFP_NOIO | __GFP_NOWARN |
>>> __GFP_NORETRY | __GFP_NOMEMALLOC);
>>> if (!addr)
>>> @@ -119,8 +137,10 @@ static long cmm_alloc_pages(long nr)
>>> if (!pa || pa->index >= CMM_NR_PAGES) {
>>> /* Need a new page for the page list. */
>>> spin_unlock(&cmm_lock);
>>> - npa = (struct cmm_page_array *)__get_free_page(GFP_NOIO | __GFP_NOWARN |
>>> - __GFP_NORETRY | __GFP_NOMEMALLOC);
>>> + npa = (struct cmm_page_array *)__get_free_page(
>>> + GFP_NOIO | __GFP_NOWARN |
>>> + __GFP_NORETRY | __GFP_NOMEMALLOC |
>>> + __GFP_MOVABLE);
>>> if (!npa) {
>>> pr_info("%s: Can not allocate new page list\n", __func__);
>>> free_page(addr);
>> Why is the __GFP_MOVABLE added here, for the page list alloc, and not
>> above for the balloon page alloc?
>
> The pages allocated as __GFP_MOVABLE are used to store the list of pages
> allocated by the balloon. They reference virtual addresses and it would
> be fine for the kernel to migrate the physical pages for those, the
> balloon would not notice this.
Does page migration really work for kernel pages that were allocated
with __get_free_page()? I was wondering if we can do this on s390, where
we have a 1:1 mapping of kernel virtual to physical addresses, but
looking at migrate_pages() and friends, it seems that kernel pages
w/o mapping and rmap should not be migrateable at all. Any thoughts from
the memory migration experts?
BTW, since we have real memory hotplug support on s390, allowing us
to add and remove memory chunks to/from ZONE_MOVABLE, this basically
makes cmm ballooning in ZONE_NORMAL obsolete, so we decided not to
support memory hotplug aware cmm on s390.
Regards,
Gerald
^ permalink raw reply
* Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
From: Grant Likely @ 2009-10-15 17:06 UTC (permalink / raw)
To: Stephen Rothwell
Cc: monstr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20091015120007.3780c59b.sfr@canb.auug.org.au>
On Wed, Oct 14, 2009 at 7:00 PM, Stephen Rothwell <sfr@canb.auug.org.au> wr=
ote:
> Hi Grant,
>
> On Tue, 06 Oct 2009 22:29:57 -0600 Grant Likely <grant.likely@secretlab.c=
a> wrote:
>>
>> Well, I've got to start somewhere...
>>
>> So here goes. =A0I've begun the work to merge and clean up the OF device
>> tree handling code and this is my first set of patches. =A0Not fully
>> tested yet, but I'm getting them out to the lists so that I can start
>> responding to comments and collecting acks. =A0This first batch isn't
>> anything exciting, just a merge of common code
>
> This all looks OK to me. =A0One thing: =A0I started in this as well some =
time
> ago and in my attempt I was hoping to avoid the ARCH ifdefs in linux/of.h
> by creating asm/of.h and moving the differing bits in there ...
Thanks Stephen.
At the moment I'm purposefully experimenting with doing arch #ifdefs
in the hope that it will lead to obvious places where the code can be
generalized even further. I'll see how it looks before I commit down
that path though.
In the mean time, I've pushed out the current series with acked-bys
added to my git server. I think I'm ready for things to start going
into linux-next. Since this is the first time I've asked for a tree
to be added to linux-next, please let me know if you see anything
troublesome or problematic. Here's the tree:
The following changes since commit 4bdf0bb7d64cf672199519b3d808e2a82f5b59e9=
:
Grant Likely (1):
powerpc/5200: Update defconfigs
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next-devicetree
Grant Likely (12):
of: Rework linux/of.h and asm/prom.h include ordering
of: merge phandle, ihandle and struct property
of: merge struct device_node
of: Move OF_IS_DYNAMIC and OF_MARK_DYNAMIC macros to of.h
of: add common header for flattened device tree representation
of: merge struct boot_param_header from Microblaze and PowerPC
of: merge of_node_*_flag() and set_node_proc_entry()
of: merge of_read_number() an of_read_ulong()
of: merge of_node_get(), of_node_put() and of_find_all_nodes()
of: merge of_*_flat_dt*() functions
of: merge other miscellaneous prototypes
of: merge of_find_all_nodes() implementations
arch/microblaze/include/asm/prom.h | 135 +-------------------------------=
-
arch/microblaze/kernel/head.S | 2 +-
arch/microblaze/kernel/prom.c | 23 ------
arch/powerpc/include/asm/prom.h | 147 +-------------------------------=
----
arch/powerpc/kernel/prom.c | 23 ------
arch/sparc/include/asm/prom.h | 55 +-------------
drivers/of/base.c | 26 ++++++-
include/linux/of.h | 103 +++++++++++++++++++++++++
include/linux/of_fdt.h | 86 +++++++++++++++++++++
9 files changed, 221 insertions(+), 379 deletions(-)
create mode 100644 include/linux/of_fdt.h
> I'll send out the two patches I did just to show what I mean (these are
> from before microblaze was using the OF stuff).
Got them, thanks.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/8] Fix 8xx MMU/TLB
From: Rex Feany @ 2009-10-15 16:56 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <1255597466-30976-1-git-send-email-Joakim.Tjernlund@transmode.se>
arch/powerpc/kernel/head_8xx.o: In function `FixupDAR':
/home/rfeany/src/lnxnm/linux-dev/arch/powerpc/kernel/head_8xx.S:576: undefined reference to `DARfix'
With all of your patches applied I have this problem:
open("/proc/mounts", O_RDONLY) = 3
fstat64(0x3, 0x7fc6ad58) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3001f000
read(3, 0x3001f000, 1024) = -1 EFAULT (Bad address)
exit_group(0) = ?
but it works fine with /dev/zero:
open("/dev/zero", O_RDONLY) = 3
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30001000
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
If I revert "8xx: start using dcbX instructions in various copy
routines" then it works again. I think it is the cache instructions
added to __copy_tofrom_user: reading from /dev/zero is OK (it uses
__clear_user, no dcbX), but copy_to_user() fails.
It seems stable with all but the dcbX patch applied. I haven't been able
to crash it yet, anyway :)
take care!
/rex.
^ permalink raw reply
* Re: powerpc problem with .data.page_aligned -> __page_aligned_data conversion
From: Tim Abbott @ 2009-10-15 16:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andrew Morton, Linus Torvalds, sam,
linux-kernel@vger.kernel.org
In-Reply-To: <1255584772.2347.86.camel@pasglop>
On Thu, 15 Oct 2009, Benjamin Herrenschmidt wrote:
> What do you recommend I do ?
> I can ban gcc < 4.3 but that's a bit harsh :-)
Yeah, let's try to avoid that.
> I know a few people that won't be happy to be unable to build newer
> kernels with current distro gccs.
>
> Or can do the above making the macro definition drop the alignment part
> on powerpc. Will work for now, but will require great care to avoid
> subtle and nasty breakage (basically same as before)
Yeah, I'd be afraid that changing the generic __page_aligned_data might
cause unexpected problems on some other architecture.
> Or maybe I can do the above but only when using gcc < 4.3 so at least if
> the breakage happen, that will only be with older gccs ...
It sounds like from your grepping, you don't believe that dropping the
alignment part will actually cause any problems on powerpc currently?
If so, dropping the alignment part on powerpc with gcc < 4.3 seems best to
me. It limits the workaround in time (eventually gcc < 4.3 will be
history). It also limits it in scope (to powerpc), where at least you're
well aware of the issue and can pay attention to new code being added that
uses __page_aligned_data. Since most code that has page-aligned data
structures is architecture-specific, there's a good chance that any new
code that would break will be at least looked at by you (and given how few
places it is used currently, this seems pretty unlikely to actually come
up).
-Tim Abbott
^ permalink raw reply
* Please pull mpc5200 and OF changes
From: Grant Likely @ 2009-10-15 16:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Hi Ben.
Here are some OF and MPC5200 changes needed for 2.6.32. Mostly
defconfig updates and a couple of new board dts files.
Cheers,
g.
The following changes since commit 161291396e76e0832c08f617eb9bd364d1648148=
:
Linus Torvalds (1):
Linux 2.6.32-rc4
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 merge
Grant Likely (1):
powerpc/5200: Update defconfigs
Heiko Schocher (2):
mpc5200: support for the MAN mpc5200 based board uc101
mpc5200: support for the MAN mpc5200 based board mucmc52
Julia Lawall (1):
drivers/serial/mpc52xx_uart.c: Use UPIO_MEM rather than SERIAL_IO_MEM
J=E9r=F4me Pouiller (1):
of: Remove nested function
Wolfram Sang (1):
powerpc/boot/dts: drop obsolete 'fsl5200-clocking'
arch/powerpc/boot/dts/cm5200.dts | 1 -
arch/powerpc/boot/dts/digsy_mtc.dts | 1 -
arch/powerpc/boot/dts/lite5200.dts | 2 -
arch/powerpc/boot/dts/lite5200b.dts | 2 -
arch/powerpc/boot/dts/media5200.dts | 2 -
arch/powerpc/boot/dts/motionpro.dts | 1 -
arch/powerpc/boot/dts/mpc5121ads.dts | 3 -
arch/powerpc/boot/dts/mucmc52.dts | 332 +++++++++++++++++++++=
++++
arch/powerpc/boot/dts/pcm030.dts | 2 -
arch/powerpc/boot/dts/pcm032.dts | 2 -
arch/powerpc/boot/dts/tqm5200.dts | 1 -
arch/powerpc/boot/dts/uc101.dts | 284 +++++++++++++++++++++
arch/powerpc/configs/52xx/cm5200_defconfig | 136 ++++++----
arch/powerpc/configs/52xx/lite5200b_defconfig | 153 ++++++++----
arch/powerpc/configs/52xx/motionpro_defconfig | 146 +++++++----
arch/powerpc/configs/52xx/pcm030_defconfig | 142 ++++++-----
arch/powerpc/configs/52xx/tqm5200_defconfig | 148 +++++++----
arch/powerpc/configs/mpc5200_defconfig | 192 ++++++++++-----
arch/powerpc/platforms/52xx/mpc5200_simple.c | 2 +
drivers/of/of_mdio.c | 13 +-
drivers/serial/mpc52xx_uart.c | 2 +-
21 files changed, 1196 insertions(+), 371 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mucmc52.dts
create mode 100644 arch/powerpc/boot/dts/uc101.dts
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: powerpc problem with .data.page_aligned -> __page_aligned_data conversion
From: Tim Abbott @ 2009-10-15 16:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andrew Morton, Linus Torvalds, sam,
linux-kernel@vger.kernel.org
In-Reply-To: <1255584772.2347.86.camel@pasglop>
On Thu, 15 Oct 2009, Benjamin Herrenschmidt wrote:
> For some weird reason, our gcc until 4.3 (fixed in 4.3) had the weird
> idea that the alignment attribute should not be allowed to force an
> alignment greater than 32k. If attempted, it would warn -and- crop the
> alignment to 32k.
[...]
> This has a few issues for us:
>
> - The patch that converted bits of powerpc to the new macro break since
> it now hits that bug
Hi Ben,
Just to make sure I understand the nature of the problem, is the current
breakage that gcc < 4.3 will _warn_ on any compilation units on ppc64 that
use __page_aligned data, or something worse?
The cropping is clearly a potential problem, but I read the rest of your
email as saying that the cropping of the alignment isn't actually a
problem with the current kernel because the kernel is currently only using
the macro with things whose size is divisible by PAGE_SIZE. However, I am
not sure how to reconcile that with using the word "break" above...
-Tim Abbott
^ permalink raw reply
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Scott Wood @ 2009-10-15 16:27 UTC (permalink / raw)
To: Richard Cochran; +Cc: 'linuxppc-dev@lists.ozlabs.org'
In-Reply-To: <95DC1AA8EC908B48939B72CF375AA5E30E2AE72C@alice.at.omicron.at>
On Thu, Oct 15, 2009 at 02:19:30PM +0200, Richard Cochran wrote:
> >-----Original Message----- From: Scott Wood [mailto:scottwood@freescale.com]
> >Because that would be three times the device trees to maintain, and a
> >source of user confusion.
>
> I wonder which is more confusing for the user:
>
> 1. Choosing one of three dts files.
Possibly incorrectly.
> 2. Having only one dts for his board, but Ethernet doesn't work.
The point is to fix u-boot so that it *does* work with only one dts. If
people not upgrading u-boot is your concern, we could put the fixup in the
Linux platform code instead.
And feel free to ask through official Freescale support channels why the
U-Boot that shipped on these boards does not have such a fixup (or why they
decided it was better to make late-rev 8313's interrupt assignments match
other 83xx than for all revs of the same part number to have the same
interrupt assignments).
-Scott
^ permalink raw reply
* Re: [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Scott Wood @ 2009-10-15 16:09 UTC (permalink / raw)
To: Christian Borntraeger
Cc: linuxppc-dev, brueckner, Timur Tabi, Alan Cox,
Linux Kernel Mailing List
In-Reply-To: <200910151305.47100.borntraeger@de.ibm.com>
On Thu, Oct 15, 2009 at 01:05:47PM +0200, Christian Borntraeger wrote:
> The fact that struct console->write returns void indicates that the console
> layer is not interested in errors. We have two policies we can implement:
>
> 1. drop console messages if case of congestion but keep the system going
> 2. dont drop messages and wait, even if the system might come to a complete stop
>
> Looking at drivers/char/vt.c
> /* console busy or not yet initialized */
> if (!printable)
> return;
> if (!spin_trylock(&printing_lock))
> return;
> could mean that Linux consoles should not block.
That's a bit different -- the code above is testing for potential deadlocks
within Linux (or a not-yet-initialized console), not a device that has yet
to process the last batch of characters we threw at it. Plus, given the
"console must be locked when we get here" comment, I'm not sure that you'll
ever see contention on printing_lock?
Serial consoles currently block when waiting for the buffer to drain:
static void serial8250_console_putchar(struct uart_port *port, int ch)
{
struct uart_8250_port *up = (struct uart_8250_port *)port;
wait_for_xmitr(up, UART_LSR_THRE);
serial_out(up, UART_TX, ch);
}
-Scott
^ permalink raw reply
* Re: [PATCH 5/5 v2] kernel handling of CPU DLPAR
From: Nathan Fontenot @ 2009-10-15 15:40 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1255473054.21871.39.camel@concordia>
Michael Ellerman wrote:
> On Tue, 2009-10-13 at 13:14 -0500, Nathan Fontenot wrote:
>> This adds the capability to DLPAR add and remove CPUs from the kernel. The
>> creates two new files /sys/devices/system/cpu/probe and
>> /sys/devices/system/cpu/release to handle the DLPAR addition and removal of
>> CPUs respectively.
>
> How does this relate to the existing cpu hotplug mechanism? Or is this
> making the cpu exist (possible), vs marking it as online?
This update makes the cpu exist, it does not mark the cpu online.
>
> Is some other platform going to want to do the same? ie. should the
> probe/release part be in generic code?
I thought about making this generic code, perhaps a follow-on patch to move
the creation of the probe/release files to generic code to see what the
community thinks. I would assume there would still need to be a arch and/or
platforms specific callout to do the real work.
>
>> Index: powerpc/arch/powerpc/platforms/pseries/dlpar.c
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/platforms/pseries/dlpar.c 2009-10-13 13:08:22.000000000 -0500
>> +++ powerpc/arch/powerpc/platforms/pseries/dlpar.c 2009-10-13 13:09:00.000000000 -0500
>> @@ -1,11 +1,11 @@
>> /*
>> - * dlpar.c - support for dynamic reconfiguration (including PCI
>> - * Hotplug and Dynamic Logical Partitioning on RPA platforms).
>> + * dlpar.c - support for dynamic reconfiguration (including PCI,
>
> We know it's dlpar.c :)
heh! good point. Consider it gone.
>
>> + * Memory, and CPU Hotplug and Dynamic Logical Partitioning on
>> + * PAPR platforms).
>> *
>> * Copyright (C) 2009 Nathan Fontenot
>> * Copyright (C) 2009 IBM Corporation
>> *
>> - *
>> * This program is free software; you can redistribute it and/or
>> * modify it under the terms of the GNU General Public License version
>> * 2 as published by the Free Software Foundation.
>> @@ -19,6 +19,7 @@
>> #include <linux/memory_hotplug.h>
>> #include <linux/sysdev.h>
>> #include <linux/sysfs.h>
>> +#include <linux/cpu.h>
>>
>>
>> #include <asm/prom.h>
>> @@ -408,6 +409,82 @@
>> return 0;
>> }
>>
>> +#ifdef CONFIG_HOTPLUG_CPU
>> +static ssize_t cpu_probe_store(struct class *class, const char *buf,
>> + size_t count)
>> +{
>> + struct device_node *dn;
>> + unsigned long drc_index;
>> + char *cpu_name;
>> + int rc;
>> +
>> + rc = strict_strtoul(buf, 0, &drc_index);
>> + if (rc)
>> + return -EINVAL;
>> +
>> + rc = acquire_drc(drc_index);
>> + if (rc)
>> + return rc;
>> +
>> + dn = configure_connector(drc_index);
>> + if (!dn) {
>> + release_drc(drc_index);
>> + return rc;
>> + }
>> +
>> + /* fixup dn name */
>> + cpu_name = kzalloc(strlen(dn->full_name) + strlen("/cpus/") + 1,
>> + GFP_KERNEL);
>> + if (!cpu_name) {
>> + free_cc_nodes(dn);
>> + release_drc(drc_index);
>> + return -ENOMEM;
>> + }
>> +
>> + sprintf(cpu_name, "/cpus/%s", dn->full_name);
>> + kfree(dn->full_name);
>> + dn->full_name = cpu_name;
>
> What was all that? Firmware gives us a bogus full name? But the parent
> is right?
Yeah, this has always been an oddity to me. The name that is given to us
from firmware puts the cpu node in the root of the device tree as opposed
to /cpus. Since cpu nodes are in /cpus, the name is fixed up to reflect this.
This name fixup has always been done by the drmgr userspace command, which is
where this functionality is being imported from.
>
>> + rc = add_device_tree_nodes(dn);
>> + if (rc)
>> + release_drc(drc_index);
>> +
>> + return rc ? rc : count;
>
> You're sure rc is < 0.
>
Oh, good catch.
>> +}
>> +
>> +static ssize_t cpu_release_store(struct class *class, const char *buf,
>> + size_t count)
>> +{
>> + struct device_node *dn;
>> + u32 *drc_index;
>> + int rc;
>> +
>> + dn = of_find_node_by_path(buf);
>> + if (!dn)
>> + return -EINVAL;
>> +
>> + drc_index = (u32 *)of_get_property(dn, "ibm,my-drc-index", NULL);
>
> No cast required.
ok.
thanks for the review.
-Nathan
>
>> + if (!drc_index) {
>> + of_node_put(dn);
>> + return -EINVAL;
>> + }
>> +
>> + rc = release_drc(*drc_index);
>> + if (rc) {
>> + of_node_put(dn);
>> + return rc;
>> + }
>> +
>> + rc = remove_device_tree_nodes(dn);
>> + if (rc)
>> + acquire_drc(*drc_index);
>> +
>> + of_node_put(dn);
>> + return rc ? rc : count;
>> +}
>
>
> cheers
^ permalink raw reply
* Re: [PATCH 4/5 v3] kernel handling of memory DLPAR
From: Nathan Fontenot @ 2009-10-15 15:23 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1255473061.21871.40.camel@concordia>
Michael Ellerman wrote:
> On Tue, 2009-10-13 at 13:13 -0500, Nathan Fontenot wrote:
>> This adds the capability to DLPAR add and remove memory from the kernel. The
>
> Hi Nathan,
>
> Sorry to only get around to reviewing version 3, time is a commodity in
> short supply :)
>
>> Index: powerpc/arch/powerpc/platforms/pseries/dlpar.c
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/platforms/pseries/dlpar.c 2009-10-08 11:08:42.000000000 -0500
>> +++ powerpc/arch/powerpc/platforms/pseries/dlpar.c 2009-10-13 13:08:22.000000000 -0500
>> @@ -16,6 +16,10 @@
>> #include <linux/notifier.h>
>> #include <linux/proc_fs.h>
>> #include <linux/spinlock.h>
>> +#include <linux/memory_hotplug.h>
>> +#include <linux/sysdev.h>
>> +#include <linux/sysfs.h>
>> +
>>
>> #include <asm/prom.h>
>> #include <asm/machdep.h>
>> @@ -404,11 +408,165 @@
>> return 0;
>> }
>>
>> +#ifdef CONFIG_MEMORY_HOTPLUG
>> +
>> +static struct property *clone_property(struct property *old_prop)
>> +{
>> + struct property *new_prop;
>> +
>> + new_prop = kzalloc((sizeof *new_prop), GFP_KERNEL);
>> + if (!new_prop)
>> + return NULL;
>> +
>> + new_prop->name = kzalloc(strlen(old_prop->name) + 1, GFP_KERNEL);
>
> kstrdup()?
Ahhh.. I did not know of kstrdup(). I will update to use this instead.
>
>> + new_prop->value = kzalloc(old_prop->length + 1, GFP_KERNEL);
>> + if (!new_prop->name || !new_prop->value) {
>> + free_property(new_prop);
>> + return NULL;
>> + }
>> +
>> + strcpy(new_prop->name, old_prop->name);
>> + memcpy(new_prop->value, old_prop->value, old_prop->length);
>> + new_prop->length = old_prop->length;
>> +
>> + return new_prop;
>> +}
>> +
>> +int platform_probe_memory(u64 phys_addr)
>> +{
>> + struct device_node *dn;
>> + struct property *new_prop, *old_prop;
>> + struct property *lmb_sz_prop;
>> + struct of_drconf_cell *drmem;
>> + u64 lmb_size;
>> + int num_entries, i, rc;
>> +
>> + if (!phys_addr)
>> + return -EINVAL;
>> +
>> + dn = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
>> + if (!dn)
>> + return -EINVAL;
>> +
>> + lmb_sz_prop = of_find_property(dn, "ibm,lmb-size", NULL);
>> + lmb_size = *(u64 *)lmb_sz_prop->value;
>
> of_get_property() ?
ok, will switch to of_find_property()
>> +
>> + old_prop = of_find_property(dn, "ibm,dynamic-memory", NULL);
>
> I know we should never fail to find these properties, but it would be
> nice to check just in case.
>
yes, will update.
>> +
>> + num_entries = *(u32 *)old_prop->value;
>> + drmem = (struct of_drconf_cell *)
>> + ((char *)old_prop->value + sizeof(u32));
>
> You do this dance twice (see below), a struct might make it cleaner.
Agreed. I think I will make this update in a separate patch. Updating
this to use a of_drconf struct would benefit this code as well as the code
in powerpc/numa.c that also deals with manipulating this property.
>
>> + for (i = 0; i < num_entries; i++) {
>> + u64 lmb_end_addr = drmem[i].base_addr + lmb_size;
>> + if (phys_addr >= drmem[i].base_addr
>> + && phys_addr < lmb_end_addr)
>> + break;
>> + }
>> +
>> + if (i >= num_entries) {
>> + of_node_put(dn);
>> + return -EINVAL;
>> + }
>> +
>> + if (drmem[i].flags & DRCONF_MEM_ASSIGNED) {
>> + of_node_put(dn);
>> + return 0;
>
> This is the already added case?
Yes. In this case the lmb is already assigned to the system.
>
>> + }
>> +
>> + rc = acquire_drc(drmem[i].drc_index);
>> + if (rc) {
>> + of_node_put(dn);
>> + return -1;
>
> -1 ?
Yeah, bad choice.
>
>> + }
>> +
>> + new_prop = clone_property(old_prop);
>> + drmem = (struct of_drconf_cell *)
>> + ((char *)new_prop->value + sizeof(u32));
>> +
>> + drmem[i].flags |= DRCONF_MEM_ASSIGNED;
>> + prom_update_property(dn, new_prop, old_prop);
>> +
>> + rc = blocking_notifier_call_chain(&pSeries_reconfig_chain,
>> + PSERIES_DRCONF_MEM_ADD,
>> + &drmem[i].base_addr);
>> + if (rc == NOTIFY_BAD) {
>> + prom_update_property(dn, old_prop, new_prop);
>> + release_drc(drmem[i].drc_index);
>> + }
>> +
>> + of_node_put(dn);
>> + return rc == NOTIFY_BAD ? -1 : 0;
>
> -1 ?
Another bad return code choice.
>
>> +}
>> +
>> +static ssize_t memory_release_store(struct class *class, const char *buf,
>> + size_t count)
>> +{
>> + unsigned long drc_index;
>> + struct device_node *dn;
>> + struct property *new_prop, *old_prop;
>> + struct of_drconf_cell *drmem;
>> + int num_entries;
>> + int i, rc;
>> +
>> + rc = strict_strtoul(buf, 0, &drc_index);
>> + if (rc)
>> + return -EINVAL;
>> +
>> + dn = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
>> + if (!dn)
>> + return 0;
>
> 0 really?
... and again...
>
>> +
>> + old_prop = of_find_property(dn, "ibm,dynamic-memory", NULL);
>> + new_prop = clone_property(old_prop);
>> +
>> + num_entries = *(u32 *)new_prop->value;
>> + drmem = (struct of_drconf_cell *)
>> + ((char *)new_prop->value + sizeof(u32));
>> +
>> + for (i = 0; i < num_entries; i++) {
>> + if (drmem[i].drc_index == drc_index)
>> + break;
>> + }
>> +
>> + if (i >= num_entries) {
>> + free_property(new_prop);
>> + of_node_put(dn);
>> + return -EINVAL;
>> + }
>
> Couldn't use old_prop up until here? They're identical aren't they, so
> you can do the clone here and you can avoid the free in the above error
> case.
>
Yes, this is possible. I will clean this up.
>> + drmem[i].flags &= ~DRCONF_MEM_ASSIGNED;
>> + prom_update_property(dn, new_prop, old_prop);
>> +
>> + rc = blocking_notifier_call_chain(&pSeries_reconfig_chain,
>> + PSERIES_DRCONF_MEM_REMOVE,
>> + &drmem[i].base_addr);
>> + if (rc != NOTIFY_BAD)
>> + rc = release_drc(drc_index);
>> +
>> + if (rc)
>> + prom_update_property(dn, old_prop, new_prop);
>> +
>> + of_node_put(dn);
>> + return rc ? -1 : count;
>
> -1, EPERM?
EPERM.
>
>> +}
>> +
>> +static struct class_attribute class_attr_mem_release =
>> + __ATTR(release, S_IWUSR, NULL, memory_release_store);
>> +#endif
>> +
>> static int pseries_dlpar_init(void)
>> {
>> if (!machine_is(pseries))
>> return 0;
>>
>> +#ifdef CONFIG_MEMORY_HOTPLUG
>> + if (sysfs_create_file(&memory_sysdev_class.kset.kobj,
>> + &class_attr_mem_release.attr))
>> + printk(KERN_INFO "DLPAR: Could not create sysfs memory "
>> + "release file\n");
>> +#endif
>> +
>> return 0;
>> }
>> device_initcall(pseries_dlpar_init);
>> Index: powerpc/arch/powerpc/mm/mem.c
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/mm/mem.c 2009-10-08 11:07:45.000000000 -0500
>> +++ powerpc/arch/powerpc/mm/mem.c 2009-10-08 11:08:54.000000000 -0500
>> @@ -111,8 +111,19 @@
>> #ifdef CONFIG_MEMORY_HOTPLUG
>>
>> #ifdef CONFIG_NUMA
>> +int __attribute ((weak)) platform_probe_memory(u64 start)
>
> __weak
>
> Though be careful, I think this is vulnerable to a bug in some
> toolchains where the compiler will inline this version. See the comment
> around early_irq_init() in kernel/softirq.c for example.
>
> This will need to be a ppc_md hook as soon as another platform supports
> memory hotplug, though that may be never :)
>
I didn't know any other way to implement this. If using a weak symbol is ok
I will leave it. I am open to suggestions if there is a better way to do this.
thanks for reviewing the patch.
-Nathan
>> +{
>> + return 0;
>> +}
>> +
>> int memory_add_physaddr_to_nid(u64 start)
>> {
>> + int rc;
>> +
>> + rc = platform_probe_memory(start);
>> + if (rc)
>> + return rc;
>> +
>> return hot_add_scn_to_nid(start);
>> }
>> #endif
>
> cheers
>
^ permalink raw reply
* Re: i2c-powermac fails
From: Jean Delvare @ 2009-10-15 14:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, Tim Shepard, linuxppc-dev
In-Reply-To: <1255605559.2347.102.camel@pasglop>
On Thu, 15 Oct 2009 22:19:19 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2009-10-15 at 12:49 +0200, Jean Delvare wrote:
> > Oh. Well, if that was the case, we would see errors all the time, not
> > just during initialization, right? Or does the I2C clock frequency
> > change over time somehow?
>
> No but maybe we are a bit on the "limit" of the device and some
> registers take long to respond than others ?
Unlikely. The ADT7460 can run at I2C clock rates up to 400 kHz while
the Keywest I2C runs at 25, 50 or 100 kHz if I read the code properly.
I don't know what exact speed is used on Tim's system, apparently it is
read from the hardware in the device tree directly?
We could have low_i2c.c log the I2C clock frequency and/or try to force
the lowest speed (25 kHz) and see if it helps, but I very much doubt
it. And I'd rather wait for Tim to report the result with my last patch
first.
--
Jean Delvare
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox