* Re: [PATCH 1/2] elf loader support for auxvec base platform string
From: Roland McGrath @ 2008-07-08 0:31 UTC (permalink / raw)
To: benh; +Cc: Nathan Lynch, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1215471393.8970.157.camel@pasglop>
> > The kernel does not have to come from the same place as the root
> > filesystem. You may want to run a new kernel with an old filesystem, or
> > vice-versa.
Well, it's not like these bits are really going to change in practice. My
point was just that this is a far "softer" ABI than the general kernel-user
contract. Sorry if my being precise about things gives you indigestion.
> I agree, I'm pretty dubious here...
Dubious about whether the dsocaps bit assignments are "part of the ABI"?
Fine. Let's talk again when you've used up 32 bits and want to figure out
what to do next.
Dubious about whether dsocaps is the right thing to do? I think you are
overlooking what the actual kernel-user compatibility reality is here.
Firstly, what is the "risk" in the "gone wrong" case? The risk is that a
DSO load via ld.so.cache will overlook a /lib/power99/foo.so match and get
a /lib/foo.so match instead because ldconfig doesn't know about "power99".
If foo.so wasn't in ld.so.cache at all, there is no problem.
If you used LD_LIBRARY_PATH, there is no problem.
If you used dlopen with an explicit file name (has /), there is no problem.
What happens if you boot a kernel that uses dsocaps with the new string
"power99", but you are missing the ld.so.conf.d file to match your kernel?
Then a DSO load via ld.so.cache will overlook "power99" matches.
How do you fix it?
Install the right (tiny text) file, and run ldconfig.
What happens now if you are using a new kernel that supplies a new string
"power99" in AT_PLATFORM or another auxv element used the same way, but
with an old root filesystem (say one including any glibc that exists today)?
Then a DSO load via ld.so.cache will overlook "power99" matches.
How do you fix it?
You add a bit assignment in the glibc sources, recompile glibc,
install a new whole glibc package. (Conceivably if you are extremely
careful you can manage to redo an otherwise completely identical
build to the glibc on your old system and replace only ld{64,}.so.1
and ldconfig.) Then run the new ldconfig.
In short, if you use a root filesystem from before kernels started using
the new string, then you will degenerate to default-platform library
matches from loads via ld.so.cache (i.e. /lib/foo.so, not /lib/somecpu/foo.so).
If you want to do better than that for this case, it's intractable using
AT_PLATFORM, and simple using dsocaps (probably simpler than booting a
special kernel was).
I haven't figured out what in this old-vs-new picture you think AT_PLATFORM
or something else like it would ever buy you.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
From: Grant Erickson @ 2008-07-07 23:47 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, sr, jgarzik
In-Reply-To: <1215474042.8970.171.camel@pasglop>
On 7/7/08 4:40 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2008-07-07 at 16:31 -0700, Grant Erickson wrote:
>> #define RGMII_FER_GMII(idx) (0x7 << ((idx) * 4))
>> +#define RGMII_FER_MII(idx) (0x7 << ((idx) * 4))
>
> Hrm... the setting of the register is exactly the same right ?
>
> Do we -really- need that ?
Would you prefer?
+#define RGMII_FER_MII(idx) RGMII_FER_GMII(idx)
Having the "extra" mnemonic makes the code end up looking less like a typo
and more like a conscious decision: "Yes, we know MII and GMII are the same
setting, but we're being explicit about it."
-Grant
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
From: Benjamin Herrenschmidt @ 2008-07-07 23:40 UTC (permalink / raw)
To: Grant Erickson; +Cc: linuxppc-dev, sr, jgarzik
In-Reply-To: <1215473518-14245-1-git-send-email-gerickson@nuovations.com>
On Mon, 2008-07-07 at 16:31 -0700, Grant Erickson wrote:
> #define RGMII_FER_GMII(idx) (0x7 << ((idx) * 4))
> +#define RGMII_FER_MII(idx) (0x7 << ((idx) * 4))
Hrm... the setting of the register is exactly the same right ?
Do we -really- need that ?
Ben.
^ permalink raw reply
* Re: linux-next: kbuild tree build failure
From: Michael Ellerman @ 2008-07-07 23:36 UTC (permalink / raw)
To: Roman Zippel
Cc: Stephen Rothwell, linux-next, Paul Mackerras, Sam Ravnborg,
linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0807071424240.6791@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 3231 bytes --]
On Mon, 2008-07-07 at 18:13 +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 7 Jul 2008, Stephen Rothwell wrote:
>
> > Hi Sam,
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
> > arch/powerpc/platforms/cell/spu_base.c: In function '__spu_trap_data_seg':
> > arch/powerpc/platforms/cell/spu_base.c:194: error: duplicate case value
> > arch/powerpc/platforms/cell/spu_base.c:177: error: previously used here
>
> I guess there also has been a kconfig warning somewhere. :)
> I should have gone through all archs to test this, sorry about that.
> Luckily it's only powerpc that uses 64bit values. I would prefer to
> standardize on 32bit values, as it doesn't really make sense to expect
> from the user to input full 64bit values and it's easy to generate the
> full value in a header. This would also ease on any portability issues
> (kconfig is compiled with the host compiler not the target compiler).
Hi Roman,
I don't really see why it "doesn't make sense" for users to input 64-bit
values, they're configuring addresses for a 64-bit kernel, so some of
the values are going to be 64 bit.
Perhaps all the current values can be generated by shifting 32-bit
constants, but that seems like a hack to me.
Another comment below ..
> Index: linux-2.6/arch/powerpc/Kconfig
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/Kconfig
> +++ linux-2.6/arch/powerpc/Kconfig
> @@ -714,8 +714,8 @@ config PHYSICAL_START_BOOL
>
> config PHYSICAL_START
> hex "Physical address where the kernel is loaded" if PHYSICAL_START_BOOL
> - default "0x02000000" if PPC_STD_MMU && CRASH_DUMP
> - default "0x00000000"
> + default "0x2000000" if PPC_STD_MMU && CRASH_DUMP
> + default "0"
>
> config PHYSICAL_ALIGN
> hex
> @@ -763,7 +763,7 @@ config CONSISTENT_SIZE_BOOL
>
> config CONSISTENT_SIZE
> hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
> - default "0x00200000" if NOT_COHERENT_CACHE
> + default "0x200000" if NOT_COHERENT_CACHE
>
> config PIN_TLB
> bool "Pinned Kernel TLBs (860 ONLY)"
> @@ -773,15 +773,11 @@ endmenu
> if PPC64
> config PAGE_OFFSET
> hex
> - default "0xc000000000000000"
> -config KERNEL_START
> - hex
> - default "0xc000000002000000" if CRASH_DUMP
> - default "0xc000000000000000"
> + default "0xc0000000"
I don't see where you cope with the "if CRASH_DUMP" case, and in fact my
config changes for the worse when I apply your patch and regenerate my
config:
--- .config.orig 2008-07-08 09:30:00.000000000 +1000
+++ .config 2008-07-08 09:30:43.000000000 +1000
@@ -370,9 +370,8 @@
CONFIG_HOTPLUG_PCI_RPA=m
CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
# CONFIG_HAS_RAPIDIO is not set
-CONFIG_PAGE_OFFSET=0xc000000000000000
-CONFIG_KERNEL_START=0xc000000002000000
-CONFIG_PHYSICAL_START=0x02000000
+CONFIG_PAGE_OFFSET=0xc0000000
+CONFIG_PHYSICAL_START=0x2000000
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] ibm_newemac: Add MII mode support to the EMAC RGMII bridge.
From: Grant Erickson @ 2008-07-07 23:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sr, jgarzik
This patch adds support to the RGMII handler in the EMAC driver for
the MII PHY mode such that device tree entries of the form `phy-mode = "mii";'
are recognized and handled appropriately.
While logically, in software, "gmii" and "mii" modes are the same,
they are wired differently, so it makes sense to allow DTS authors to
specify each explicitly.
Signed-off-by: Grant Erickson <gerickson@nuovations.com>
---
drivers/net/ibm_newemac/rgmii.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index e32da3d..5acb006 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -39,6 +39,7 @@
#define RGMII_FER_RGMII(idx) (0x5 << ((idx) * 4))
#define RGMII_FER_TBI(idx) (0x6 << ((idx) * 4))
#define RGMII_FER_GMII(idx) (0x7 << ((idx) * 4))
+#define RGMII_FER_MII(idx) (0x7 << ((idx) * 4))
/* RGMIIx_SSR */
#define RGMII_SSR_MASK(idx) (0x7 << ((idx) * 8))
@@ -49,6 +50,7 @@
static inline int rgmii_valid_mode(int phy_mode)
{
return phy_mode == PHY_MODE_GMII ||
+ phy_mode == PHY_MODE_MII ||
phy_mode == PHY_MODE_RGMII ||
phy_mode == PHY_MODE_TBI ||
phy_mode == PHY_MODE_RTBI;
@@ -63,6 +65,8 @@ static inline const char *rgmii_mode_name(int mode)
return "TBI";
case PHY_MODE_GMII:
return "GMII";
+ case PHY_MODE_MII:
+ return "MII";
case PHY_MODE_RTBI:
return "RTBI";
default:
@@ -79,6 +83,8 @@ static inline u32 rgmii_mode_mask(int mode, int input)
return RGMII_FER_TBI(input);
case PHY_MODE_GMII:
return RGMII_FER_GMII(input);
+ case PHY_MODE_MII:
+ return RGMII_FER_MII(input);
case PHY_MODE_RTBI:
return RGMII_FER_RTBI(input);
default:
--
1.5.4.3
^ permalink raw reply related
* powerpc: Add proper reference to dma_mask
From: Vitaly Bordug @ 2008-07-07 23:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
There is dma_mask in of_device that is being filled upon
of_platform_device_create() but we don't properly set the struct device
in there to point back to it. coherent_dma_mask wasn't set up either -
these caused weird lock-ups and behavior of USB subsystem using
of_device USB host drivers.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/kernel/of_platform.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/of_platform.c b/arch/powerpc/kernel/of_platform.c
index e79ad8a..2bf4c04 100644
--- a/arch/powerpc/kernel/of_platform.c
+++ b/arch/powerpc/kernel/of_platform.c
@@ -76,6 +76,9 @@ struct of_device* of_platform_device_create(struct device_node *np,
return NULL;
dev->dma_mask = 0xffffffffUL;
+ dev->dev.dma_mask = &dev->dma_mask;
+ dev->dev.coherent_dma_mask = DMA_32BIT_MASK;
+
dev->dev.bus = &of_platform_bus_type;
/* We do not fill the DMA ops for platform devices by default.
^ permalink raw reply related
* Re: [PATCH 1/2] elf loader support for auxvec base platform string
From: Benjamin Herrenschmidt @ 2008-07-07 23:00 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel, Roland McGrath
In-Reply-To: <20080707221733.GJ9594@localdomain>
On Mon, 2008-07-07 at 17:17 -0500, Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2008-07-03 at 19:19 -0700, Roland McGrath wrote:
> > > Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits
> > > left there (keeping it to 32), but 3 is not 0. If not that, why not use
> > > dsocaps? That is, some magic in the vDSO, which glibc already supports on
> > > all machines where it uses the vDSO. (For how it works, see the use in
> > > arch/x86/vdso/vdso32/note.S for CONFIG_XEN.)
> >
> > Well, we use strings to represent the platforms already (ie, the actual
> > CPU microarchitecture). Fitting those into bits would be annoying, it
> > makes sense to have AT_BASE_PLATFORM to be the "base" variant of
> > AT_PLATFORM.
> >
> > _However_ there is a bug in that this patch adds an entry without
> > bumping the number of entries in the cached array (ie.
> > AT_VECTOR_SIZE_BASE needs to be updated).
>
> Ugh, yes. I was hoping to work this in such a way that AT_VECTOR_SIZE
> (and thus the size of mm_struct) increases only for architectures that
> implement AT_BASE_PLATFORM... would it be wrong to account for it in
> AT_VECTOR_SIZE_ARCH?
Yes. The later is for things added from ARCH_DLINFO. Since the
code for AT_BASE_PLATFORM is in the generic binfmt_elf, it would
be asking for trouble to not account for it in the base AT_VECTOR_SIZE.
Ben.
^ permalink raw reply
* Re: Deputy maintainer for powerpc
From: Benjamin Herrenschmidt @ 2008-07-07 22:58 UTC (permalink / raw)
To: Josh Boyer
Cc: lkml List, linuxppc-dev list, Paul Mackerras, Andrew Morton,
Linus Torvalds
In-Reply-To: <20080707152548.5075845f@zod.rchland.ibm.com>
On Mon, 2008-07-07 at 15:25 -0400, Josh Boyer wrote:
> > Ben, Do you have a tree that you'll be using to collect things in?
>
> I hope it's the same tree for this merge window.
It's in a different place but it's essentially the same tree (ie, I
pulled in paulus branches and my current heads are identical, at least
until I start adding things to it).
> In the future, I hope the semantics of the various branches of the
> new tree either stays the same, or comes with a detailed description
> of what branch means what (assuming there is a new tree at some
> point).
Branches are the same, master,merge and next (the only subtle difference
is that my next branch is called just "next" and not "powerpc-next").
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] elf loader support for auxvec base platform string
From: Benjamin Herrenschmidt @ 2008-07-07 22:56 UTC (permalink / raw)
To: Andreas Schwab
Cc: linuxppc-dev, Paul Mackerras, Nathan Lynch, linux-kernel,
Roland McGrath
In-Reply-To: <je63rirp1x.fsf@sykes.suse.de>
On Mon, 2008-07-07 at 12:01 +0200, Andreas Schwab wrote:
> Roland McGrath <roland@redhat.com> writes:
>
> > There are 32 bits free now. One can anticipate that reassigning a bit
> > would come up only after these are exhausted. With prudent use, this
> > will take a very long time to happen. Then the oldest CPU type string
> > might be retired to reuse its bit. It seems unlikely that there will
> > be a single installation (root directory) that really needs to have
> > installed both a kernel optimized for the oldest CPU model known and a
> > kernel optimized for the newest CPU model known.
>
> The kernel does not have to come from the same place as the root
> filesystem. You may want to run a new kernel with an old filesystem, or
> vice-versa.
I agree, I'm pretty dubious here...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] i2c-ibm_iic: Remove deprecated OCP style part of thedriver
From: Sean MacLennan @ 2008-07-07 22:55 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080604210400.0d7abb8e@hyperion.delvare>
On Wed, 4 Jun 2008 21:04:00 +0200
"Jean Delvare" <khali@linux-fr.org> wrote:
> On Wed, 4 Jun 2008 17:22:12 +0200, Stefan Roese wrote:
> > The deprecated OCP style driver part is used by the "old" arch/ppc
> > platform. This platform is scheduled for removal in June/July this
> > year. This patch now removes the OCP driver part from the IBM I2C
> > driver.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > ---
> > drivers/i2c/busses/i2c-ibm_iic.c | 181
> > -------------------------------------- 1 files changed, 0
> > insertions(+), 181 deletions(-)
>
> Applied, queued for 2.6.27, thanks Stefan.
>
> BTW, would you happen to know if read-only EEPROMs such as SPD or EDID
> can be found on the i2c-ibm_iic adapters?
>
Jean, where is this patch queued? I have a patch for the iic driver and
it would probably be easiest if I diffed against what you have.
Cheers,
Sean
^ permalink raw reply
* Re: Deputy maintainer for powerpc
From: Benjamin Herrenschmidt @ 2008-07-07 22:50 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds, Paul Mackerras,
lkml List
In-Reply-To: <155B1079-39C4-4D15-B886-F904C424BC8C@kernel.crashing.org>
On Mon, 2008-07-07 at 09:44 -0500, Kumar Gala wrote:
> On Jul 4, 2008, at 1:02 AM, Paul Mackerras wrote:
>
> > I'm going to be on vacation for the next two weeks, and it looks
> > highly likely that Linus will open the 2.6.27 merge window during that
> > time, so I'm appointing Ben Herrenschmidt as my deputy maintainer.
> > During the next two weeks, he'll be the person collecting together any
> > further powerpc-related commits that need to go upstream, and sending
> > pull requests to Linus as necessary.
> >
> > This is the start of a longer-term transition which will ultimately
> > result in me handing over the powerpc architecture maintainership to
> > Ben. Because of various work commitments, this will be a gradual
> > transition taking probably around 6 months.
> >
> > Paul.
>
> Ben, Do you have a tree that you'll be using to collect things in?
I've setup a tree on kernel.org yes, but there's nothing useful in
it yet (it has 3 branches, master, merge and next, but they are
currently pointing to the exact same spot as Paul's).
I've started collecting things yesterday and sending comments, I'll
push some new stuff out today or tomorrow. Mostly been "training" with
git and patchwork so far :-)
Ben.
^ permalink raw reply
* Re: linux-next: scsi tree build failure
From: Benjamin Herrenschmidt @ 2008-07-07 22:48 UTC (permalink / raw)
To: James Bottomley
Cc: Stephen Rothwell, linux-scsi, linuxppc-dev, linux-next,
Paul Mackerras
In-Reply-To: <1215468479.3274.42.camel@localhost.localdomain>
On Mon, 2008-07-07 at 17:07 -0500, James Bottomley wrote:
> I thought it was all done and dusted (which is why I put it in
> scsi-misc). However, now Brian King seems to have some late arriving
> comments.
There are comments on the whole serie yup, I haven't put it in the
tree yet.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: rework 4xx PTE access and TLB miss
From: Sean MacLennan @ 2008-07-07 22:48 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080707100627.4be05488@zod.rchland.ibm.com>
On Mon, 7 Jul 2008 10:06:27 -0400
"Josh Boyer" <jwboyer@linux.vnet.ibm.com> wrote:
> On Tue, 01 Jul 2008 14:35:42 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> I tried testing this on a Sequoia board this morning. Kernel boots,
> but then it hangs when starting the init process. The last message
> seen is:
>
> INIT: version 2.86
> booting
>
> The setup is an tftp'd kernel via U-Boot using cuImage, nfsroot
> filesystem. Sequoia has an FPU, and CONFIG_PPC_FPU is set.
>
> I reverted this patch and used the latest powerpc-next branch and it
> boots fine.
>
> Seems something is wrong here still. I suspect the DSI handler
> changes, but I have no proof and haven't debugged it yet. Until we
> get it fixed, I don't feel overly comfortable putting it in the next
> branch. Which board and setup did you test with?
On a whim, I tired this on the warp platform (440EP) and got the same
result with basically the same setup.
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 156k init
init started: BusyBox v1.9.1 (2008-04-04 14:47:35 EDT)
And then hung. This was against 2.6.26-rc9.
Cheers,
Sean
^ permalink raw reply
* [PATCH] ibmebus: more meaningful variable name
From: Paul Gortmaker @ 2008-07-07 22:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, arnd, Paul Gortmaker
In-Reply-To: <1215469038.8970.137.camel@pasglop>
Choose a more meaningful name for better System.map readability and
autopsy value etc. Part of a cleanup suggested by Benjamin Herrenschmidt.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/kernel/ibmebus.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 9971159..58da8f8 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -53,7 +53,7 @@ static struct device ibmebus_bus_device = { /* fake "parent" device */
struct bus_type ibmebus_bus_type;
/* These devices will automatically be added to the bus during init */
-static struct of_device_id __initdata builtin_matches[] = {
+static struct of_device_id __initdata ibmebus_matches[] = {
{ .compatible = "IBM,lhca" },
{ .compatible = "IBM,lhea" },
{},
@@ -350,7 +350,7 @@ static int __init ibmebus_bus_init(void)
return err;
}
- err = ibmebus_create_devices(builtin_matches);
+ err = ibmebus_create_devices(ibmebus_matches);
if (err) {
device_unregister(&ibmebus_bus_device);
bus_unregister(&ibmebus_bus_type);
--
1.5.6.6.gd3e97
^ permalink raw reply related
* Re: [patch 0/6] Strong Access Ordering page attributes for POWER7
From: Benjamin Herrenschmidt @ 2008-07-07 22:27 UTC (permalink / raw)
To: Joel Schopp
Cc: linux-mm, Andrew Morton, Dave Kleikamp, Paul Mackerras,
Linuxppc-dev
In-Reply-To: <48728942.6050007@austin.ibm.com>
On Mon, 2008-07-07 at 16:23 -0500, Joel Schopp wrote:
> >> We haven't defined a user-visible feature bit (and besides, we're really
> >> getting short on these...). This is becoming a bit of concern btw (the
> >> running out of bits). Maybe we should start defining an AT_HWCAP2 for
> >> powerpc and get libc updated to pick it up ?
> >>
> >
> > Joel,
> > Any thoughts?
> Is it a required or optional feature of the 2.06 architecture spec? If it's required you could just use that. It doesn't solve the problem more generically if other archs decide to implement it though.
And then we start having to expose 2.06S vs. 2.06E .. nah.
I think for now, for SAO, the idea that one can "try" and if -EINVAL,
try again without might work fine.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Power5,Power6 BSR driver
From: Benjamin Herrenschmidt @ 2008-07-07 22:26 UTC (permalink / raw)
To: Sonny Rao; +Cc: sonnyrao, paulus, Nathan Lynch, linuxppc-dev
In-Reply-To: <20080707211740.GA15821@us.ibm.com>
On Mon, 2008-07-07 at 16:17 -0500, Sonny Rao wrote:
> On Mon, Jul 07, 2008 at 02:59:35PM +1000, Benjamin Herrenschmidt wrote:
> >
> > > + cur->bsr_addr = reg[i * 2];
> > > + cur->bsr_len = reg[i * 2 + 1];
> >
> > That's fishy... hand-reading of "reg" property without taking
> > into account the parent's #size-cells/#address-cells... can't you
> > use of_address_to_resource or something similar and carry a struct
> > resource around instead ?
>
> So, with this suggestion I looked at the resource API... not very well
> documented, and I get the feeling like it's more for carving up a PCI
> memory address range. In the case of the BSR, everything is already
> partitioned (by hardware) so I don't see the point of using this API
> here. Or am I missing something about it?
It's about properly parsing a "reg" property in OF. The format of the
reg property depends on the parent #address-cells and #size-cells, and
the addresses in there may need remapping (or not) depending on parent
"ranges" properties. The special cases in prom_parse.c for PCI and ISA
are purely to deal with the additional address space flags those add to
addresses, but you shouldn't hit that with BSR.
> > In fact, same goes with the way you do num_bsr_devs = reg_len / 16.
> >
> > You should rather use -another- property of well known lenght, or
> > get the #address/#size-cells of the parent and use those appropriately.
>
> Well, I check to make sure the lengths are consistent with each other
> right above there so we shouldn't walk off the end of anything, but I
> will take a look at using #size-cells / #address-cells instead.
The code in prom_parse.c will do it for you :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [patch 1/6] mm: Allow architectures to define additional protection bits
From: Benjamin Herrenschmidt @ 2008-07-07 22:24 UTC (permalink / raw)
To: Hugh Dickins
Cc: linux-mm, Andrew Morton, Dave Kleikamp, Paul Mackerras,
Linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0807072143200.27181@blonde.site>
On Mon, 2008-07-07 at 22:11 +0100, Hugh Dickins wrote:
> Sorry, Andrew got the wrong pantomime: I was appearing in Aladdin
> a couple of years ago, but this year I'm the Sleeping Beauty.
> (Did I hear a grumble of dissent from the back stalls?)
No comment :-)
> I don't find Dave's patch very handsome, but it gets the job done
> so I'd better not carp. The ugliness in vm_get_page_prot is just
> an inevitable consequence of growing beyond the traditional neat
> pairing of VM_xxx flags with VM_MAYxxx flags, along with the way
> that opaque pgprot_t type becomes occasionally tiresome, as such
> opaque types do: I don't think there's a better way of handling
> it than Dave has done.
That was also my conclusion. It didn't look pretty but I couldn't come
up with something prettier.
> There is a little inconsistency, that arch_calc_vm_prot_bits
> and arch_vm_get_page_prot just handle the exceptional flag (SAO),
> whereas arch_validate_prot handles all of them; but I don't feel
> so strongly about that to suggest resubmission.
>
> And regarding VM_SAO added to include/linux/mm.h in 3/6: although
> it's odd to be weaving back and forth between arch-specific and
> common, it's already the case that mman definitions and pgtable
> definitions are arch-specific but mm.h common: I'm much happier
> to have VM_SAO defined once there as Dave has it, than get into
> arch-specific vm_flags.
>
> Is someone going to be asking for PROT_WC shortly?
I'll definitely come with PROT_ENDIAN soon :-) (ie, some powerpc
processors can have a per-page endian flag that when set causes all
load/store instructions on this are to be byte-flipped, support for this
feature has been requested for some time, and now I have the
infrastructure to do it).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Use new printk extension %pS to print symbols on oops
From: Benjamin Herrenschmidt @ 2008-07-07 22:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev
In-Reply-To: <alpine.LFD.1.10.0807071006270.11076@woody.linux-foundation.org>
On Mon, 2008-07-07 at 10:08 -0700, Linus Torvalds wrote:
> > This changes the oops and backtrace code to use the new %pS
> > printk extension to print out symbols rather than manually
> > calling print_symbol.
>
> Ok, I ended up committing the suppor for '%pS' early (as a series of
> smaller patches to make it clearer), just because it makes it easier for
> different people to start converthing things with the infrastructure in
> place.
>
> But I wasn't planning on actually merging any of the conversions until
> after 2.6.26 (ie there will be no actual _users_ of '%pS' in 2.6.26)
That's ok. I posted the patch for review/comments, I didn't intend
to have it merged before .27 opens.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] elf loader support for auxvec base platform string
From: Nathan Lynch @ 2008-07-07 22:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul, Mackerras, linux-kernel, Roland McGrath
In-Reply-To: <1215409693.8970.79.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2008-07-03 at 19:19 -0700, Roland McGrath wrote:
> > Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits
> > left there (keeping it to 32), but 3 is not 0. If not that, why not use
> > dsocaps? That is, some magic in the vDSO, which glibc already supports on
> > all machines where it uses the vDSO. (For how it works, see the use in
> > arch/x86/vdso/vdso32/note.S for CONFIG_XEN.)
>
> Well, we use strings to represent the platforms already (ie, the actual
> CPU microarchitecture). Fitting those into bits would be annoying, it
> makes sense to have AT_BASE_PLATFORM to be the "base" variant of
> AT_PLATFORM.
>
> _However_ there is a bug in that this patch adds an entry without
> bumping the number of entries in the cached array (ie.
> AT_VECTOR_SIZE_BASE needs to be updated).
Ugh, yes. I was hoping to work this in such a way that AT_VECTOR_SIZE
(and thus the size of mm_struct) increases only for architectures that
implement AT_BASE_PLATFORM... would it be wrong to account for it in
AT_VECTOR_SIZE_ARCH?
^ permalink raw reply
* Re: [PATCH] legacy-serial: more meaningful names, terminate array
From: Benjamin Herrenschmidt @ 2008-07-07 22:17 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: scottwood, linuxppc-dev, arnd
In-Reply-To: <1215443120-22004-1-git-send-email-paul.gortmaker@windriver.com>
On Mon, 2008-07-07 at 11:05 -0400, Paul Gortmaker wrote:
> Terminate the array of possible legacy serial parents, and
> choose more meaningful names for better autopsy value. Fix
> and cleanups as suggested by Benjamin Herrenschmidt.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
Hi Paul !
Linus already merged my fix for legacy_serial.c, can you split
out the ibmebus part and resend it ? I'll stick it in -next.
Cheers,
Ben.
> arch/powerpc/kernel/ibmebus.c | 4 ++--
> arch/powerpc/kernel/legacy_serial.c | 5 +++--
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
> index 9971159..58da8f8 100644
> --- a/arch/powerpc/kernel/ibmebus.c
> +++ b/arch/powerpc/kernel/ibmebus.c
> @@ -53,7 +53,7 @@ static struct device ibmebus_bus_device = { /* fake "parent" device */
> struct bus_type ibmebus_bus_type;
>
> /* These devices will automatically be added to the bus during init */
> -static struct of_device_id __initdata builtin_matches[] = {
> +static struct of_device_id __initdata ibmebus_matches[] = {
> { .compatible = "IBM,lhca" },
> { .compatible = "IBM,lhea" },
> {},
> @@ -350,7 +350,7 @@ static int __init ibmebus_bus_init(void)
> return err;
> }
>
> - err = ibmebus_create_devices(builtin_matches);
> + err = ibmebus_create_devices(ibmebus_matches);
> if (err) {
> device_unregister(&ibmebus_bus_device);
> bus_unregister(&ibmebus_bus_type);
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index 61dd174..4b01c2b 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -33,13 +33,14 @@ static struct legacy_serial_info {
> phys_addr_t taddr;
> } legacy_serial_infos[MAX_LEGACY_SERIAL_PORTS];
>
> -static struct __initdata of_device_id parents[] = {
> +static struct __initdata of_device_id uart_match[] = {
> {.type = "soc",},
> {.type = "tsi-bridge",},
> {.type = "opb", },
> {.compatible = "ibm,opb",},
> {.compatible = "simple-bus",},
> {.compatible = "wrs,epld-localbus",},
> + {},
> };
>
> static unsigned int legacy_serial_count;
> @@ -322,7 +323,7 @@ void __init find_legacy_serial_ports(void)
> struct device_node *parent = of_get_parent(np);
> if (!parent)
> continue;
> - if (of_match_node(parents, parent) != NULL) {
> + if (of_match_node(uart_match, parent) != NULL) {
> index = add_legacy_soc_port(np, np);
> if (index >= 0 && np == stdout)
> legacy_serial_console = index;
^ permalink raw reply
* Re: linux-next: scsi tree build failure
From: James Bottomley @ 2008-07-07 22:07 UTC (permalink / raw)
To: benh; +Cc: Stephen Rothwell, linux-scsi, linuxppc-dev, linux-next,
Paul Mackerras
In-Reply-To: <1215468350.8970.129.camel@pasglop>
On Tue, 2008-07-08 at 08:05 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2008-07-07 at 09:39 -0500, James Bottomley wrote:
> > > Caused because commit 341b56db6804040aa9559e913865108424e3b18b
> > ("[SCSI]
> > > ibmvscsi: driver enablement for CMO"), which was 15/16 in a series,
> > has
> > > been merged before any of the other patches in the series. I have
> > > reverted that commit.
> >
> > Do I detect the fact that IBM sent a patch for a SCSI driver for which
> > the core features weren't yet enabled (and which I couldn't check, not
> > having a ppc build system)?
>
> I suspect the sender (Robert) was asking for comments/review :-) In any
> case, Robert, next time make it explicit on a patch CCed to a separate
> list from the rest of the serie that it isn't to be merged without
> dependencies.
>
> James, if you ack it, I'll put it in powerpc.git.
I thought it was all done and dusted (which is why I put it in
scsi-misc). However, now Brian King seems to have some late arriving
comments.
James
^ permalink raw reply
* Re: [PATCH] [V2] powerpc: legacy_serial: reg-offset & shift aren't used
From: Benjamin Herrenschmidt @ 2008-07-07 22:00 UTC (permalink / raw)
To: Josh Boyer; +Cc: dwg, linuxppc-dev, paulus, John Linn
In-Reply-To: <20080707070124.73ba794f@zod.rchland.ibm.com>
> > - First if the properties are present but their value match the
> > register layout of a standard UART, we will bail out... not nice.
>
> Why would they be present in that case?
Why not ?
> > - Why don't we just implement support for the reg-shift and
> > offset instead ?
>
> Probably because the last time someone suggested that it spawned a
> lengthy debate about what reg-offset/shift were supposed to do.
That's lame, their definition is already quite there.
Ben.
^ permalink raw reply
* Re: linux-next: scsi tree build failure
From: Benjamin Herrenschmidt @ 2008-07-07 22:05 UTC (permalink / raw)
To: James Bottomley
Cc: Stephen Rothwell, linux-scsi, linuxppc-dev, linux-next,
Paul Mackerras
In-Reply-To: <1215441589.3274.17.camel@localhost.localdomain>
On Mon, 2008-07-07 at 09:39 -0500, James Bottomley wrote:
> > Caused because commit 341b56db6804040aa9559e913865108424e3b18b
> ("[SCSI]
> > ibmvscsi: driver enablement for CMO"), which was 15/16 in a series,
> has
> > been merged before any of the other patches in the series. I have
> > reverted that commit.
>
> Do I detect the fact that IBM sent a patch for a SCSI driver for which
> the core features weren't yet enabled (and which I couldn't check, not
> having a ppc build system)?
I suspect the sender (Robert) was asking for comments/review :-) In any
case, Robert, next time make it explicit on a patch CCed to a separate
list from the rest of the serie that it isn't to be merged without
dependencies.
James, if you ack it, I'll put it in powerpc.git.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Add PPC_FEATURE_PMU_COMPAT
From: Maynard Johnson @ 2008-07-07 22:05 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080707172921.GH9594@localdomain>
Nathan Lynch wrote:
> Kumar Gala wrote:
>
>> On Jul 3, 2008, at 6:20 PM, Nathan Lynch wrote:
>>
>>
>>> Beginning with Power6, there is a set of 32 PMU events which is
>>> compatible across POWER processor lines. PPC_FEATURE_PMU_COMPAT
>>> indicates support for this subset.
>>>
>>> Signed-off-by: Nathan Lynch <ntl@pobox.com>
>>> ---
>>> arch/powerpc/kernel/cputable.c | 4 ++--
>>> include/asm-powerpc/cputable.h | 1 +
>>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>>
>> Can you explain what these PMU events are a bit further?
>>
>
> Maynard, can you help out here...? :)
>
As of POWER6, a set of 32 common events were defined that must be
supported on all future POWER processors -- aka "PMU compat set". The
main impetus for this compat set is the need to support partition
migration, especially from processor P(n) to processor P(n+1), where
performance software that's running in the new partition may not be
knowledgeable about processor P(n+1). If a performance tool determines
it does not support the physical processor, but is told (via the
PPC_FEATURE_PMU_COMPAT bit) that the processor supports the notion of
the PMU compat set, then the performance tool can surface just those
events to the user of the tool.
Hope that helps.
-Maynard
^ permalink raw reply
* Re: [PATCH] powerpc: rework 4xx PTE access and TLB miss
From: Benjamin Herrenschmidt @ 2008-07-07 22:03 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080707100627.4be05488@zod.rchland.ibm.com>
On Mon, 2008-07-07 at 10:06 -0400, Josh Boyer wrote:
> The setup is an tftp'd kernel via U-Boot using cuImage, nfsroot
> filesystem. Sequoia has an FPU, and CONFIG_PPC_FPU is set.
>
> I reverted this patch and used the latest powerpc-next branch and it
> boots fine.
>
> Seems something is wrong here still. I suspect the DSI handler
> changes, but I have no proof and haven't debugged it yet. Until we
> get it fixed, I don't feel overly comfortable putting it in the next
> branch. Which board and setup did you test with?
mambo and another board I don't remember which one precisely.
I'll have a look.
Cheers,
Ben.
^ 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