* Re: [PATCH] [Powerpc V2.1] fix switch_slb handling of 1T ESID values
From: Benjamin Herrenschmidt @ 2007-10-31 0:55 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071030185932.6368.7796.stgit@farscape.rchland.ibm.com>
On Tue, 2007-10-30 at 13:59 -0500, Will Schmidt wrote:
> [Powerpc] fix switch_slb handling of 1T ESID values
>
> Now that we have 1TB segment size support, we need to be using the
> GET_ESID_1T macro when comparing ESID values for pc,stack, and
> unmapped_base within switch_slb(). A new helper function called
> esids_match() contains the logic for deciding when to call GET_ESID
> and GET_ESID_1T.
>
> This also happens to fix a duplicate-slb-entry inspired machine-check
> exception I was seeing when trying to run java on a power6 partition.
>
> Tested on power6 and power5.
>
> Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
>
> ---
>
> Just a bit of whitespace cosmetic touchup in this version, as suggested
> by Stephen Rothwell.
> ---
>
> arch/powerpc/mm/slb.c | 34 +++++++++++++++++++++++++++++++---
> 1 files changed, 31 insertions(+), 3 deletions(-)
>
>
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index bbd2c51..8cbbfab 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -148,6 +148,35 @@ void slb_vmalloc_update(void)
> slb_flush_and_rebolt();
> }
>
> +/* Helper function to compare esids. There are four cases to handle.
> + * 1. The system is not 1T segment size capable. Use the GET_ESID compare.
> + * 2. The system is 1T capable, both addresses are < 1T, use the GET_ESID compare.
> + * 3. The system is 1T capable, only one of the two addresses is > 1T. This is not a match.
> + * 4. The system is 1T capable, both addresses are > 1T, use the GET_ESID_1T macro to compare.
> + */
> +static inline int esids_match(unsigned long addr1, unsigned long addr2)
> +{
> + int esid_1t_count;
> +
> + /* System is not 1T segment size capable. */
> + if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
> + return (GET_ESID(addr1) == GET_ESID(addr2));
> +
> + esid_1t_count = (((addr1 >> SID_SHIFT_1T) != 0) +
> + ((addr2 >> SID_SHIFT_1T) != 0));
> +
> + /* both addresses are < 1T */
> + if (esid_1t_count == 0)
> + return (GET_ESID(addr1) == GET_ESID(addr2));
> +
> + /* One address < 1T, the other > 1T. Not a match */
> + if (esid_1t_count == 1)
> + return 0;
> +
> + /* Both addresses are > 1T. */
> + return (GET_ESID_1T(addr1) == GET_ESID_1T(addr2));
> +}
> +
> /* Flush all user entries from the segment table of the current processor. */
> void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> {
> @@ -193,15 +222,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> return;
> slb_allocate(pc);
>
> - if (GET_ESID(pc) == GET_ESID(stack))
> + if (esids_match(pc,stack))
> return;
>
> if (is_kernel_addr(stack))
> return;
> slb_allocate(stack);
>
> - if ((GET_ESID(pc) == GET_ESID(unmapped_base))
> - || (GET_ESID(stack) == GET_ESID(unmapped_base)))
> + if (esids_match(pc,unmapped_base) || esids_match(stack,unmapped_base))
> return;
>
> if (is_kernel_addr(unmapped_base))
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: libfdt as its own repo and submodule of dtc?
From: David Gibson @ 2007-10-30 23:40 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linux-ppc list, Jon Loeliger
In-Reply-To: <4727665E.1070109@ge.com>
On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote:
> Jon Loeliger wrote:
>> So, like, the other day Kumar Gala mumbled:
>>> Jon,
>>>
>>> It seems like have libfdt as a unique git repo that is a submodule of
>>> the things that need it (dtc, u-boot, etc.) might make some sense and it
>>> easier for the projects that need to pull it in.
>>>
>>> Is this something you can take a look at? (or have other ideas on).
>> I would be fine with making libfdt a git repository separate
>> from the DTC repository if that makes it easier to integrate
>> it with other projects.
I don't think it's a good idea to make dtc and libfdt entirely
seperate repositories (again). Being able to use both together in
their combined testsuite is very useful (libfdt is used to check trees
generated by dtc, dtc is used to generate example trees for libfdt
testing).
I'm not sure how submodules/subrepositories work so I don't know if
that makes sense.
> That sounds like a good idea to me. I would really prefer pulling patches
> out of a libfdt repo into the u-boot repo rather than trying to kerchunk
> upgrade lumps. While we can do this with a dtc repo, it potentially makes
> it a lot more difficult.
I don't think upgrading embedded copies by diff is a good way to go.
The upgrade method I had in mind was to pull out a whole new copy of
libfdt, drop that into the embedding project verbatim and generate a
new diff there in whatever their source tracking system is. I set out
the repository to make this easy.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 23:27 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F26EE@az33exm25.fsl.freescale.net>
On Tue, Oct 30, 2007 at 07:56:33AM -0700, Yoder Stuart-B08248 wrote:
[snip]
> > Yeah.. what he said.
> >
> > The *only* substantive change with the "class" proposal is the fact
> > that multiple classes can be specified. That's nice, but I don't
> > think it's worth the trouble of attempting to define a whole new chunk
> > of standard for.
>
> I tend to agree, but I think device_type serves a useful
> purpose. I don't think we should deprecate it.
>
> > Stuart, I think you overestimate the value of this class property to a
> > human reader. The generic names convention (not followed as much as
> > it should be) means the name should give the reader some idea of what
> > the device is, in most cases. For trickier cases, if we really want
> > something for humans reading the tree, we could add an optional
> > "comment" or "description" property with purely human readable
> > information.
> >
> > I think we should leave existing IEEE1275 defined uses of device_type,
> > in order not to make flat trees gratuitously different from real-OF
> > trees, but we should avoid any new use of device_type.
>
> I'm fine with keeping device_type, but there are a few
> of things I don't like about the 'no new use'.
>
> 1. There are types of nodes that don't have a programming
> inteface per se and thus no compatible.
> "cpu", "memory", "cache" are 3 that come to mind.
Well, yes, this is why I suggested treating these "fundamental" nodes
as a special case in an earlier mail.
> What if there is a _new_ class of nodes of this type?
> What is wrong with a new use of device_type for something
> say like "i2c"?
Memory and cpu are pretty clearly special cases - if they're not
there, you don't have a computer at all. The programming model for
"memory" is always the same", and the programming model for the cpu
has to be known before reading the device tree anyway. I don't think
we need to worry about new classes of such things - i2c is *certainly*
not an example of such.
cache is a bit weird, because although there can be different types,
the programming model is essentially determined by the cpu to which it
is attached, and the nodes for cache are really just to give details
of sizes and levels.
> Conceptually and ideally, what _is_ the right way to
> represent these types of devices.
>
> 2. 'Existing IEEE1275 defined uses' of device_type is
> actually very vague. There are a conglomeration of
> old bindings, recommended practices, proposals and
> it is not clear at all which are useful or not. What
> are the existing IEEE1275 uses??? I actually went
> through all the OF documents and there are dozens
> of device types that have no practical use.
>
> Also, many 'real-OF' trees seem to follow no published
> binding at all.
>
> Conceptually, I'd like to a crisp list of 'official'
> bindings and hope that the current ePAPR work in
> power.org will establish this list.
Yeah, sorry, I am being a bit vauge here and we do need to be more
specific. My point is that if you take a tree from a real OF, with
lots of device_type values representing programming interfaces, then
flatten it, it shouldn't be considered "bad" as a flattened tree.
It's fine if most or all of the device_type values are optional in the
flattened tree, so that it's ok whether or not they're present.
> 3. You're advocating deprecating device_class, but still
> requiring it for certain node types. So a "network"
> node is _required_ to have the deprecated
> device_type="network". But a "i2c" node is required
> _not_ to have device_type. Long term, I'd like to see
> any inconsitency be removed. If device_type is
> deprecated, it's use should be optional in flat
> device trees. That goes for "cpu", "memory", etc.
>
> I think what we should do is keep device_type, including
> permitting new uses of it in a limited way-- only permitting
> the use of device_type when there is an official binding
> (like in the power.org ePAPR) defined.
That's what I was thinking when we first started defining flat tree
bindings. But the more time I've spent thinking about it, and the
more time I've spent reviewing people's proposed bindings, the less
useful I think it is.
The *only* reason I'm suggesting leaving device_type values for
IEEE1275 defined classes is so that flat trees written as flat trees
look more similar to OF derived trees.
> > Explicitly specifying what device class bindings / conventions the
> > node complies with is cute, but not actually all that useful in
> > practice. If it looks like a "duck" class device node, and it
> > quacks^Whas the properties of a "duck" class device node, it's "duck"
> > class compliant.
> >
> > Or to look at it another way, "class bindings" aren't really bindings,
> > but rather a set of conventions that device bindings for specific
> > devices in that class ought to follow.
>
> I tend to think of a 'binding' as a 'set of conventions'.
Well, whatever. My point is that conventions are most flexible if you
don't have to explicitly announce that you're following them - you
just go ahead and follow as many conventions as make sense for your
device.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: David Gibson @ 2007-10-30 23:08 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071030165650.GA22107@ru.mvista.com>
On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> PowerPC 440GRx Rainier DTS.
[snip]
> + SDRAM0: sdram {
> + device_type = "memory-controller";
How many times do we need to say it...
Don't make up random device_type values. This does not belong here.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 23:02 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F2872@az33exm25.fsl.freescale.net>
On Tue, Oct 30, 2007 at 12:06:33PM -0700, Yoder Stuart-B08248 wrote:
>
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, October 30, 2007 11:34 AM
> > To: Yoder Stuart-B08248
> > Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
> > Subject: Re: RFC: replace device_type with new "class" property?
> >
> > On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
> > > mpic: pic@40000 {
> > > clock-frequency = <0>;
> > > interrupt-controller;
> > > #address-cells = <0>;
> > > #interrupt-cells = <2>;
> > > reg = <40000 40000>;
> > > compatible = "fsl,xyz";
> > > big-endian;
> > > }
> > >
> > > Note-- I removed the device_type property and changed
> > > compatible somewhat. How are you going to find where
> > > the meaning interrupt controller's interrupt cells are
> > > defined? What spec will you look at?
> >
> > The binding for fsl,xyz.
>
> Not every string listed in compatible has a spec
> backing it (or should be required to). You would
> have to go look at the source code and cross your
> fingers that the comments were sufficient.
But that's true in general. open-pic is practically the only time
device_type will let you avoid that.
> Another good reason for device_type-- it helps
> distinguish between two similar classes of devices.
> Both "open-pic" and "isa-pic" look very similar but
> have different encodings of their interrupt cells.
> Without a device_type it may be difficult or impossible
> to distinguish them unless the "name" and
> "compatible" are luckily clear enough.
This is a totally misleading argument. There may be one or two cases
where the device_type is useful, but in most cases device_type will be
either not specific enough to give you the information you need, or it
we add lots of new device_type values, it will be so specific that it
suffers the same problem as looking at name or compatible - you have
to find the finding that goes with a particular device_type.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 22:58 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F278B@az33exm25.fsl.freescale.net>
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
>
> > Explicitly specifying what device class bindings / conventions the
> > node complies with is cute, but not actually all that useful in
> > practice. If it looks like a "duck" class device node, and it
> > quacks^Whas the properties of a "duck" class device node, it's "duck"
> > class compliant.
>
> Don't know how cute it is, but I think it is practically
> helpful. Take another example:
>
> Say you-- a human reader-- see this in a device
> tree:
>
> ...
> interrupts = <b 8>;
> interrupt-parent = < &mpic >;
> ...
>
> What does the 'b' and '8' mean? You look
> at the interrupt controller node--
>
> mpic: pic@40000 {
> clock-frequency = <0>;
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <40000 40000>;
> compatible = "fsl,xyz";
> big-endian;
> }
>
> Note-- I removed the device_type property and changed
> compatible somewhat. How are you going to find where
> the meaning interrupt controller's interrupt cells are
> defined? What spec will you look at?
>
> device_type = "open-pic"; makes it perfectly clear.
> It's an open-pic type controller and follows that
> binding.
That's an extremely contrived example - it only works because for
historical reasons the "open-pic" device_type describes a programming
model as well as an OF method interface. In general, you always need
to look at a node's "compatible" and the binding for that to work out
what it's properties mean, or if it's an interrupt controller what the
format of its interrupt specifiers is.
open-pic is the *only* example I can think of where device_type will
tell you this. In fact, "open-pic" really belongs in compatible.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Michael Ellerman @ 2007-10-30 22:50 UTC (permalink / raw)
To: Christoph Raisch
Cc: Thomas Q Klein, ossthema, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Marcus Eder, Stefan Roscher
In-Reply-To: <OF79E7ACE7.5D0488CE-ONC1257384.002E58C0-C1257384.002F8561@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote:
>
> Michael Ellerman <michael@ellerman.id.au> wrote on 28.10.2007 23:32:17:
> >
> >
> > How do you plan to support kdump?
> >
>
> When kexec is fully supported kdump should work out of the box
> as for any other ethernet card (if you load the right eth driver).
> There's nothing specific to kdump you have to handle in
> ethernet device drivers.
> Hope I didn't miss anything here...
Perhaps. When we kdump the kernel does not call the reboot notifiers, so
the code Jan-Bernd just added won't get called. So the eHEA resources
won't be freed. When the kdump kernel tries to load the eHEA driver what
will happen?
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] [powerpc v2] update xmon slb code
From: Will Schmidt @ 2007-10-30 21:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
[powerpc] update xmon slb code
This adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size. (1T or 256M). This supresses the output for any slb entries
that contain only zeros.
sample output from power6 (1T segment support):
00 c000000008000000 40004f7ca3000500 1T ESID= c00000 VSID=40004f7ca3 LLP bits:100
01 d000000008000000 4000eb71b0000400 1T ESID= d00000 VSID=4000eb71b0 LLP bits: 0
03 0000000008000000 0000628021c6ac80 256M ESID= 0 VSID= 628021c6a LLP bits: 0
04 00000f0008000000 400095c1e8000c80 1T ESID= f VSID=400095c1e8 LLP bits: 0
22 cf00000008000000 400011b260000500 1T ESID= cf0000 VSID=400011b260 LLP bits:100
62 0000040008000000 40005d488d000c80 1T ESID= 4 VSID=40005d488d LLP bits: 0
63 0000000018000000 0000633f90285c80 256M ESID= 1 VSID= 633f90285 LLP bits: 0
sample output from power5 (notice the non-valid but non-zero entries)
00 c000000008000000 0000408f92c94500 256M ESID=c00000000 VSID= 408f92c94 LLP bits:100
01 d000000008000000 0000f09b89af5400 256M ESID=d00000000 VSID= f09b89af5 LLP bits: 0
03 0000000010000000 0000136eafb0bc80
11 0000000008000000 00005928811f2c80 256M ESID= 0 VSID= 5928811f2 LLP bits: 0
12 00000000f8000000 0000645ff8d87c80 256M ESID= f VSID= 645ff8d87 LLP bits: 0
13 0000000048000000 00005c263aa5ec80 256M ESID= 4 VSID= 5c263aa5e LLP bits: 0
14 0000000018000000 000059e7ef80dc80 256M ESID= 1 VSID= 59e7ef80d LLP bits: 0
15 0000000010000000 000059e7ef80dc80
Tested on power5 and power6.
Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
---
This version adds padding around the ESID and VSID fields, and the LLP bits
are displayed too. (Per request from Olof and Ben).
I'll try to follow up sometime later with code that will handle decoding page
sizes. I dont have a testcase handy to properly exercise that yet. :-)
---
arch/powerpc/xmon/xmon.c | 27 +++++++++++++++++++++------
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 121b04d..93c26c3 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2527,16 +2527,31 @@ static void xmon_print_symbol(unsigned long address, const char *mid,
static void dump_slb(void)
{
int i;
- unsigned long tmp;
+ unsigned long esid,vsid,valid;
+ unsigned long llp_bits;
printf("SLB contents of cpu %x\n", smp_processor_id());
for (i = 0; i < SLB_NUM_ENTRIES; i++) {
- asm volatile("slbmfee %0,%1" : "=r" (tmp) : "r" (i));
- printf("%02d %016lx ", i, tmp);
-
- asm volatile("slbmfev %0,%1" : "=r" (tmp) : "r" (i));
- printf("%016lx\n", tmp);
+ asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
+ asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (i));
+ valid = (esid & SLB_ESID_V);
+ if (valid | esid | vsid) {
+ printf("%02d %016lx %016lx", i, esid, vsid);
+ if (valid) {
+ llp_bits = vsid & SLB_VSID_LLP;
+ if (vsid & SLB_VSID_B_1T) {
+ printf(" 1T ESID=%9lx VSID=%10lx LLP bits:%3lx \n",
+ GET_ESID_1T(esid),vsid >> SLB_VSID_SHIFT_1T,
+ llp_bits);
+ } else {
+ printf(" 256M ESID=%9lx VSID=%10lx LLP bits:%3lx \n",
+ GET_ESID(esid),vsid >> SLB_VSID_SHIFT,
+ llp_bits);
+ }
+ } else
+ printf("\n");
+ }
}
}
^ permalink raw reply related
* Re: PPC405GP Walnut irq patch
From: Steven A. Falco @ 2007-10-30 21:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47279CF0.4050600@harris.com>
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
I realized that I should have done this from the root level. So here is
the corrected patch.
Signed-off-by: Steve Falco <sfalco at harris.com>
Steven A. Falco wrote:
> Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
> the ethernet interrupts in the walnut.dts file doesn't match the
> documentation. I discovered this when porting the BSP to a custom
> board - the ethernet would not work. The attached patch corrects that.
>
> This is the first patch I am submitting, so please advise me if there
> is anything I should do differently.
>
> Signed-off-by: Steve Falco <sfalco at harris.com>
>
>
[-- Attachment #2: irq.patch --]
[-- Type: text/x-patch, Size: 660 bytes --]
diff --git a/arch/powerpc/boot/dts/walnut.dts b/arch/powerpc/boot/dts/walnut.dts
index 27bef06..dd65115 100644
--- a/arch/powerpc/boot/dts/walnut.dts
+++ b/arch/powerpc/boot/dts/walnut.dts
@@ -67,7 +67,7 @@
num-tx-chans = <2>;
num-rx-chans = <1>;
interrupt-parent = <&UIC0>;
- interrupts = <a 4 b 4 c 4 d 4 e 4>;
+ interrupts = <b 4 c 4 a 4 d 4 e 4>;
};
POB0: opb {
@@ -117,7 +117,7 @@
device_type = "network";
compatible = "ibm,emac-405gp", "ibm,emac";
interrupt-parent = <&UIC0>;
- interrupts = <9 4 f 4>;
+ interrupts = <f 4 9 4>;
reg = <ef600800 70>;
mal-device = <&MAL>;
mal-tx-channel = <0 1>;
^ permalink raw reply related
* PPC405GP Walnut irq patch
From: Steven A. Falco @ 2007-10-30 21:06 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't match the
documentation. I discovered this when porting the BSP to a custom board
- the ethernet would not work. The attached patch corrects that.
This is the first patch I am submitting, so please advise me if there is
anything I should do differently.
Signed-off-by: Steve Falco <sfalco at harris.com>
[-- Attachment #2: irq.patch --]
[-- Type: text/x-patch, Size: 578 bytes --]
--- walnut.dts.orig 2007-10-30 15:27:49.000000000 -0400
+++ walnut.dts 2007-10-30 15:29:40.000000000 -0400
@@ -67,7 +67,7 @@
num-tx-chans = <2>;
num-rx-chans = <1>;
interrupt-parent = <&UIC0>;
- interrupts = <a 4 b 4 c 4 d 4 e 4>;
+ interrupts = <b 4 c 4 a 4 d 4 e 4>;
};
POB0: opb {
@@ -117,7 +117,7 @@
device_type = "network";
compatible = "ibm,emac-405gp", "ibm,emac";
interrupt-parent = <&UIC0>;
- interrupts = <9 4 f 4>;
+ interrupts = <f 4 9 4>;
reg = <ef600800 70>;
mal-device = <&MAL>;
mal-tx-channel = <0 1>;
^ permalink raw reply
* Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)
From: Wolfgang Denk @ 2007-10-30 21:23 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, linux-kernel, Lennart Sorensen
In-Reply-To: <200710301216.15033.stefan.roese@gmail.com>
Hello Stefan,
In message <200710301216.15033.stefan.roese@gmail.com> you wrote:
>
> I already have it running on my system using a quick hack (see patch below) in
> include/asm-ppc/nmi.h (yes, still arch/ppc for now :-( ). But for a clean
> implementation, that has chances for upstream merge (in arch/powerpc later),
> I would really like to hear if I should move on further this way.
>
> My impression is, that changing the name from touch_nmi_watchdog() to
> something like touch_watchdog(), and therefore touching lots of files, makes
> it more unlikely that this resulting patch will get accepted. But
> implementing this bootup watchdog support in asm-ppc(asm-powerpc)/nmi.h
> header seems also not totally correct, since it's not really an NMI in this
> case.
Indeed. Using the header file <asm/nmi.h> is seriously misleading for
the PowerPC version, as is the function name touch_nmi_watchdog() -
thius has nothing to do with NMIs on PowerPC, and most probably not on
any other non-x86 architecture as well.
To make this mechanism generally usable (which is a good idea IMO) the
names should be changed to get rid of the "nmi" reference.
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
It may be that your whole purpose in life is simply to serve as a
warning to others.
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
From: Josh Boyer @ 2007-10-30 21:07 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1193775391.9928.78.camel@pasglop>
On Wed, 31 Oct 2007 07:16:31 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > > Fortunately, we don't support SMP on these or this solution wouldn't
> > > work.
> >
> > We should mark 44x BROKEN on SMP in Kconfig.
>
> Can we enable SMP on 44x at all currently ?
Not without editing the Kconfig.cputypes file. I was thinking of being
a bit proactive so people didn't just add || 44x to it and think it
would work. But it's minor.
> > No arch/ppc fix? I know we all want it to die as soon as possible, but
> > still... :)
>
> Yeah, I didn't do it yet, which is one reason this patch is marked
> RFC :-)
Fair enough.
> > > /* interrupts are hard-disabled at this point */
> > > restore:
> > > +#ifdef CONFIG_44x
> > > + lis r4,icache_44x_need_flush@ha
> > > + lwz r5,icache_44x_need_flush@l(r4)
> > > + cmplwi cr0,r5,0
> > > + beq+ 1f
> > > + iccci r0,r0
> > > + li r6,0
> > > + iccci r0,r0
> > > + stw r6,icache_44x_need_flush@l(r4)
> > > +1:
> >
> > Why two iccci's here?
>
> No idea... thinko/typo.
And here I thought you were being extra careful ;)
josh
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
From: Benjamin Herrenschmidt @ 2007-10-30 20:16 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071030072310.51870c65@weaponx.rchland.ibm.com>
> > Fortunately, we don't support SMP on these or this solution wouldn't
> > work.
>
> We should mark 44x BROKEN on SMP in Kconfig.
Can we enable SMP on 44x at all currently ?
> No arch/ppc fix? I know we all want it to die as soon as possible, but
> still... :)
Yeah, I didn't do it yet, which is one reason this patch is marked
RFC :-)
> > /* interrupts are hard-disabled at this point */
> > restore:
> > +#ifdef CONFIG_44x
> > + lis r4,icache_44x_need_flush@ha
> > + lwz r5,icache_44x_need_flush@l(r4)
> > + cmplwi cr0,r5,0
> > + beq+ 1f
> > + iccci r0,r0
> > + li r6,0
> > + iccci r0,r0
> > + stw r6,icache_44x_need_flush@l(r4)
> > +1:
>
> Why two iccci's here?
No idea... thinko/typo.
Ben.
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
From: Josh Boyer @ 2007-10-30 20:16 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071030164511.GA21973@ru.mvista.com>
On Tue, 30 Oct 2007 19:45:11 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> The following patches add PowerPC 440GRx Rainier board support.
> The board is almost identical to Sequoia, but doesn't have USB
> and FPU is not supported.
So why do we need anything other than the DTS and the defconfig? I
would think the sequoia wrapper and platform files would suffice
completely for this.
josh
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.
From: Arnd Bergmann @ 2007-10-30 19:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071030165739.GA22126@ru.mvista.com>
T24gVHVlc2RheSAzMCBPY3RvYmVyIDIwMDcsIFZhbGVudGluZSBCYXJzaGFrIHdyb3RlOgo+ICtz
dGF0aWMgc3RydWN0IG9mX2RldmljZV9pZCByYWluaWVyX29mX2J1c1tdID0gewo+ICugoKCgoKCg
eyAuY29tcGF0aWJsZSA9ICJpYm0scGxiNCIsIH0sCj4gK6CgoKCgoKB7IC5jb21wYXRpYmxlID0g
ImlibSxvcGIiLCB9LAo+ICugoKCgoKCgeyAuY29tcGF0aWJsZSA9ICJpYm0sZWJjIiwgfSwKPiAr
oKCgoKCgoHt9LAo+ICt9Owo+ICsKPiArc3RhdGljIGludCBfX2luaXQgcmFpbmllcl9kZXZpY2Vf
cHJvYmUodm9pZCkKPiArewo+ICugoKCgoKCgaWYgKCFtYWNoaW5lX2lzKHJhaW5pZXIpKQo+ICug
oKCgoKCgoKCgoKCgoKByZXR1cm4gMDsKPiArCj4gK6CgoKCgoKBvZl9wbGF0Zm9ybV9idXNfcHJv
YmUoTlVMTCwgcmFpbmllcl9vZl9idXMsIE5VTEwpOwo+ICsKPiAroKCgoKCgoHJldHVybiAwOwo+
ICt9Cj4gK2RldmljZV9pbml0Y2FsbChyYWluaWVyX2RldmljZV9wcm9iZSk7Cj4gKwo+ICtzdGF0
aWMgaW50IF9faW5pdCByYWluaWVyX3Byb2JlKHZvaWQpCj4gK3sKPiAroKCgoKCgoHVuc2lnbmVk
IGxvbmcgcm9vdCA9IG9mX2dldF9mbGF0X2R0X3Jvb3QoKTsKPiArCj4gK6CgoKCgoKBpZiAoIW9m
X2ZsYXRfZHRfaXNfY29tcGF0aWJsZShyb290LCAiYW1jYyxyYWluaWVyIikpCj4gK6CgoKCgoKCg
oKCgoKCgoHJldHVybiAwOwo+ICsKPiAroKCgoKCgoHJldHVybiAxOwo+ICt9Cj4gKwo+ICtkZWZp
bmVfbWFjaGluZShyYWluaWVyKSB7Cj4gK6CgoKCgoKAubmFtZSCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoD0gIlJhaW5pZXIiLAo+ICugoKCgoKCgLnByb2JlIKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKA9IHJhaW5pZXJfcHJvYmUsCj4gK6CgoKCgoKAucHJvZ3Jlc3MgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoD0gdWRiZ19wcm9ncmVzcywKPiAroKCgoKCgoC5pbml0X0lSUSCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgPSB1aWNfaW5pdF90cmVlLAo+ICugoKCgoKCgLmdldF9pcnEgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKA9IHVpY19nZXRfaXJxLAo+ICugoKCgoKCgLnJlc3RhcnSgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKA9IHBwYzQ0eF9yZXNldF9zeXN0ZW0sCj4gK6CgoKCgoKAuY2FsaWJyYXRlX2Rl
Y3KgoKCgoKCgoKCgoKCgoKCgoD0gZ2VuZXJpY19jYWxpYnJhdGVfZGVjciwKPiArfTsKCldvdywg
dGhpcyBpcyBnZXR0aW5nIHJlYWxseSBzbWFsbCB0aGVzZSBkYXlzLiBJIHdvbmRlciBpZiB3ZSBz
aG91bGQgYWRkIHR3bwptb3JlIGdlbmVyaWMgaGVscGVycyB0byB0dXJuIHRoaXMgaW50byBqdXN0
CgpkZWZpbmVfbWFjaGluZShyYWluaWVyKSB7CiAgICAgICAubmFtZSAgICAgICAgICAgICAgICAg
ICAgICAgICAgID0gIlJhaW5pZXIiLAogICAgICAgLmNvbXBhdGlibGUgICAgICAgICAgICAgICAg
ICAgICA9ICJhbWNjLHJhaW5pZXIiLCAgICAgICAgIC8qIG5ldyAqLwogICAgICAgLnByb2JlX2J1
c2VzCQkgICAgICAgPSAmNHh4X2dlbmVyaWNfYnVzX3Byb2JlLCAvKiBuZXcgKi8KICAgICAgIC5w
cm9ncmVzcyAgICAgICAgICAgICAgICAgICAgICAgPSB1ZGJnX3Byb2dyZXNzLAogICAgICAgLmlu
aXRfSVJRICAgICAgICAgICAgICAgICAgICAgICA9IHVpY19pbml0X3RyZWUsCiAgICAgICAuZ2V0
X2lycSAgICAgICAgICAgICAgICAgICAgICAgID0gdWljX2dldF9pcnEsCiAgICAgICAucmVzdGFy
dCAgICAgICAgICAgICAgICAgICAgICAgID0gcHBjNDR4X3Jlc2V0X3N5c3RlbSwKICAgICAgIC5j
YWxpYnJhdGVfZGVjciAgICAgICAgICAgICAgICAgPSBnZW5lcmljX2NhbGlicmF0ZV9kZWNyLAp9
OwoKCUFybmQgPD48Cg==
^ permalink raw reply
* [patch 05/28] Add cmpxchg64 and cmpxchg64_local to powerpc
From: Mathieu Desnoyers @ 2007-10-30 19:16 UTC (permalink / raw)
To: akpm, linux-kernel, matthew, linux-arch, penberg, linux-mm,
Christoph Lameter
Cc: Paul Mackerras, Mathieu Desnoyers, linuxppc-dev
In-Reply-To: <20071030191557.947156623@polymtl.ca>
Make sure that at least cmpxchg64_local is available on all architectures to use
for unsigned long long values.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@ozlabs.org
---
include/asm-powerpc/system.h | 6 ++++++
1 file changed, 6 insertions(+)
Index: linux-2.6-lttng/include/asm-powerpc/system.h
===================================================================
--- linux-2.6-lttng.orig/include/asm-powerpc/system.h 2007-09-24 10:50:11.000000000 -0400
+++ linux-2.6-lttng/include/asm-powerpc/system.h 2007-09-24 11:01:04.000000000 -0400
@@ -488,6 +488,12 @@ __cmpxchg_local(volatile void *ptr, unsi
*/
#define NET_IP_ALIGN 0
#define NET_SKB_PAD L1_CACHE_BYTES
+
+#define cmpxchg64 cmpxchg
+#define cmpxchg64_local cmpxchg_local
+#else
+#include <asm-generic/cmpxchg-local.h>
+#define cmpxchg64_local(ptr,o,n) __cmpxchg64_local_generic((ptr), (o), (n))
#endif
#define arch_align_stack(x) (x)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Grant Likely @ 2007-10-30 19:38 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, David Gibson, linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F2872@az33exm25.fsl.freescale.net>
On 10/30/07, Yoder Stuart-B08248 <stuart.yoder@freescale.com> wrote:
> Another good reason for device_type-- it helps
> distinguish between two similar classes of devices.
> Both "open-pic" and "isa-pic" look very similar but
> have different encodings of their interrupt cells.
> Without a device_type it may be difficult or impossible
> to distinguish them unless the "name" and
> "compatible" are luckily clear enough.
I don't think you want to go down that path. If your compatible list
does not uniquely describe what the device is (followed by a list of
devices it is compatible with); then it is not specific enough. It's
fine for a device driver to go looking at other properties to get more
details; but drivers should primarily bind on the compatible list.
In other words; device_type and/or class are a coarser grained
description of the device than the compatible list. If you match on
compatible; why would there be any need at all to look at 'name',
'device_type' or the proposed 'class' properties?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Gianfar skb panic when bonding a VLAN interface
From: Jay Vosburgh @ 2007-10-30 19:07 UTC (permalink / raw)
To: Demke Torsten-atd012; +Cc: linuxppc-dev
In-Reply-To: <67194FEE6056B947B4EF756C9E497A2E01DB237A@zuk35exm60.ds.mot.com>
Demke Torsten-atd012 <torsten.demke@motorola.com> wrote:
>I tried to ping over a bonded VLAN tagged interface.
>(e.g -> ifenslave bond0 eth3.24)
[...]
>It seems that the skb headroom is to small. How can I solve this?
>I could insert skb_realloc_headroom() call, but where it's the best
>place then?
>What about alignement?
What kernel are you using? There was a fix applied to the
bonding driver about a year ago to resolve this problem with gianfar:
commit 54ef313714070b397d3857289f0fd099b7643631
Author: Jay Vosburgh <fubar@us.ibm.com>
Date: Fri Sep 22 21:53:39 2006 -0700
[PATCH] bonding: Handle large hard_header_len
The bonding driver fails to adjust its hard_header_len when enslaving
interfaces. Whenever an interface with a hard_header_len greater than the
ETH_HLEN default is enslaved, the potential for an oops exists, and if the
oops happens while responding to an arp request, for example, the system
panics. GIANFAR devices may use an extended hard_header for VLAN or
hardware checksumming. Enslaving such a device and then transmitting over
it causes a kernel panic.
Patch modified from submitter's original, but submitter agreed with this
patch in private email.
Signed-off-by: Mark Huth <mhuth@mvista.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* RE: RFC: replace device_type with new "class" property?
From: Yoder Stuart-B08248 @ 2007-10-30 19:06 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Olof Johansson, linuxppc-dev, David Gibson
In-Reply-To: <20071030163343.GA4517@loki.buserror.net>
=20
> -----Original Message-----
> From: Wood Scott-B07421=20
> Sent: Tuesday, October 30, 2007 11:34 AM
> To: Yoder Stuart-B08248
> Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>=20
> On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
> > mpic: pic@40000 {
> > clock-frequency =3D <0>;
> > interrupt-controller;
> > #address-cells =3D <0>;
> > #interrupt-cells =3D <2>;
> > reg =3D <40000 40000>;
> > compatible =3D "fsl,xyz";
> > big-endian;
> > }
> >=20
> > Note-- I removed the device_type property and changed
> > compatible somewhat. How are you going to find where
> > the meaning interrupt controller's interrupt cells are
> > defined? What spec will you look at?
>=20
> The binding for fsl,xyz.
Not every string listed in compatible has a spec=20
backing it (or should be required to). You would
have to go look at the source code and cross your
fingers that the comments were sufficient.
Another good reason for device_type-- it helps=20
distinguish between two similar classes of devices.
Both "open-pic" and "isa-pic" look very similar but
have different encodings of their interrupt cells.
Without a device_type it may be difficult or impossible
to distinguish them unless the "name" and
"compatible" are luckily clear enough.
Stuart
^ permalink raw reply
* [PATCH] [Powerpc V2.1] fix switch_slb handling of 1T ESID values
From: Will Schmidt @ 2007-10-30 18:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
[Powerpc] fix switch_slb handling of 1T ESID values
Now that we have 1TB segment size support, we need to be using the
GET_ESID_1T macro when comparing ESID values for pc,stack, and
unmapped_base within switch_slb(). A new helper function called
esids_match() contains the logic for deciding when to call GET_ESID
and GET_ESID_1T.
This also happens to fix a duplicate-slb-entry inspired machine-check
exception I was seeing when trying to run java on a power6 partition.
Tested on power6 and power5.
Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
---
Just a bit of whitespace cosmetic touchup in this version, as suggested
by Stephen Rothwell.
---
arch/powerpc/mm/slb.c | 34 +++++++++++++++++++++++++++++++---
1 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index bbd2c51..8cbbfab 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -148,6 +148,35 @@ void slb_vmalloc_update(void)
slb_flush_and_rebolt();
}
+/* Helper function to compare esids. There are four cases to handle.
+ * 1. The system is not 1T segment size capable. Use the GET_ESID compare.
+ * 2. The system is 1T capable, both addresses are < 1T, use the GET_ESID compare.
+ * 3. The system is 1T capable, only one of the two addresses is > 1T. This is not a match.
+ * 4. The system is 1T capable, both addresses are > 1T, use the GET_ESID_1T macro to compare.
+ */
+static inline int esids_match(unsigned long addr1, unsigned long addr2)
+{
+ int esid_1t_count;
+
+ /* System is not 1T segment size capable. */
+ if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ esid_1t_count = (((addr1 >> SID_SHIFT_1T) != 0) +
+ ((addr2 >> SID_SHIFT_1T) != 0));
+
+ /* both addresses are < 1T */
+ if (esid_1t_count == 0)
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ /* One address < 1T, the other > 1T. Not a match */
+ if (esid_1t_count == 1)
+ return 0;
+
+ /* Both addresses are > 1T. */
+ return (GET_ESID_1T(addr1) == GET_ESID_1T(addr2));
+}
+
/* Flush all user entries from the segment table of the current processor. */
void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
{
@@ -193,15 +222,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
return;
slb_allocate(pc);
- if (GET_ESID(pc) == GET_ESID(stack))
+ if (esids_match(pc,stack))
return;
if (is_kernel_addr(stack))
return;
slb_allocate(stack);
- if ((GET_ESID(pc) == GET_ESID(unmapped_base))
- || (GET_ESID(stack) == GET_ESID(unmapped_base)))
+ if (esids_match(pc,unmapped_base) || esids_match(stack,unmapped_base))
return;
if (is_kernel_addr(unmapped_base))
^ permalink raw reply related
* Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
From: Jeff Garzik @ 2007-10-30 18:32 UTC (permalink / raw)
To: Dale Farnsworth
Cc: Tzachi Perelstein, netdev, Luis R. Rodriguez, Lennert Buytenhek,
linuxppc-dev
In-Reply-To: <20071029223900.GA7097@xyzzy.farnsworth.org>
Dale Farnsworth wrote:
> On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
>> This commit made an incorrect assumption:
>> --
>> Author: Lennert Buytenhek <buytenh@wantstofly.org>
>> Date: Fri Oct 19 04:10:10 2007 +0200
>>
>> mv643xx_eth: Move ethernet register definitions into private header
>>
>> Move the mv643xx's ethernet-related register definitions from
>> include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since
>> they aren't of any use outside the ethernet driver.
>>
>> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
>> Acked-by: Tzachi Perelstein <tzachi@marvell.com>
>> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
>> --
>>
>> arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there.
>>
>> mcgrof@pogo:~/devel/wireless-2.6$ git-describe
>>
>> v2.6.24-rc1-138-g0119130
>>
>> This patch fixes this by internalizing 3 defines onto pegasos which are
>> simply no longer available elsewhere. Without this your compile will fail
>
> That compile failure was fixed in commit
> 30e69bf4cce16d4c2dcfd629a60fcd8e1aba9fee by Al Viro.
>
> However, as I examine that commit, I see that it defines offsets from
> the eth block in the chip, rather than the full chip registeri block
> as the Pegasos 2 code expects. So, I think it fixes the compile
> failure, but leaves the Pegasos 2 broken.
>
> Luis, do you have Pegasos 2 hardware? Can you (or anyone) verify that
> the following patch is needed for the Pegasos 2?
>
> Thanks,
> -Dale
>
> ---------------------------------
>
> mv643xx_eth: Fix MV643XX_ETH offsets used by Pegasos 2
>
> In the mv643xx_eth driver, we now use offsets from the ethernet
> register block within the chip, but the pegasos 2 platform still
> needs offsets from the full chip's register base address.
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> ---
> include/linux/mv643xx_eth.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
> index 8df230a..30e11aa 100644
> --- a/include/linux/mv643xx_eth.h
> +++ b/include/linux/mv643xx_eth.h
> @@ -8,9 +8,9 @@
> #define MV643XX_ETH_NAME "mv643xx_eth"
> #define MV643XX_ETH_SHARED_REGS 0x2000
> #define MV643XX_ETH_SHARED_REGS_SIZE 0x2000
> -#define MV643XX_ETH_BAR_4 0x220
> -#define MV643XX_ETH_SIZE_REG_4 0x224
> -#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x0290
> +#define MV643XX_ETH_BAR_4 0x2220
> +#define MV643XX_ETH_SIZE_REG_4 0x2224
> +#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x2290
applied
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
From: Valentine Barshak @ 2007-10-30 18:31 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071030131703.3b4b4056@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Tue, 30 Oct 2007 19:45:11 +0300
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
>> The following patches add PowerPC 440GRx Rainier board support.
>> The board is almost identical to Sequoia, but doesn't have USB
>> and FPU is not supported.
>
> General FYI, I'm probably going to queue these up for .25. We should
> be in bug-fix mode for .24.
OK, thanks,
Valentine.
>
> josh
^ permalink raw reply
* Re: [PATCH v2] using mii-bitbang on different processor ports
From: Scott Wood @ 2007-10-30 18:23 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <1193767812.6244.46.camel@p60635-ste.ids.de>
Sergej Stepanov wrote:
> + if( !of_address_to_resource(np, 1, &res[1])) {
The spacing is still wrong.
> - iounmap(bitbang->dir);
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
> + iounmap(bitbang->mdio.dir);
> + iounmap(bitbang->mdc.dir);
And here.
-Scott
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
From: Josh Boyer @ 2007-10-30 18:17 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071030164511.GA21973@ru.mvista.com>
On Tue, 30 Oct 2007 19:45:11 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> The following patches add PowerPC 440GRx Rainier board support.
> The board is almost identical to Sequoia, but doesn't have USB
> and FPU is not supported.
General FYI, I'm probably going to queue these up for .25. We should
be in bug-fix mode for .24.
josh
^ permalink raw reply
* [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: Badari Pulavarty @ 2007-10-30 19:19 UTC (permalink / raw)
To: Paul Mackerras, KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, anton, linux-mm
In-Reply-To: <18178.52359.953289.638736@cargo.ozlabs.ibm.com>
Hi KAME,
As I mentioned while ago, ppc64 does not export information about
"system RAM" in /proc/iomem. Looking at the code and usage
scenerios I am not sure what its really serving. Could you
explain what its purpose & how the range can be invalid ?
At least on ppc64, all the memory ranges we get passed comes from
/sysfs memblock information and they are guaranteed to match
device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
and it will be part of the /proc/device-tree entry. Since we do
"online" or "offline" to /sysfs entries to add/remove pages -
these ranges are guaranteed to be valid.
Since this check is redundant for ppc64, I propose following patch.
Is this acceptable ? If some one really really wants, I can code
up this to walk lmb or /proc/device-tree and verify the range &
adjust the entries for overlap (I don't see how that can happen).
Paul & Kame, please comment.
Thanks,
Badari
---
arch/powerpc/Kconfig | 3 +++
arch/powerpc/mm/mem.c | 13 +++++++++++++
kernel/resource.c | 2 +-
3 files changed, 17 insertions(+), 1 deletion(-)
Index: linux-2.6.24-rc1/arch/powerpc/mm/mem.c
===================================================================
--- linux-2.6.24-rc1.orig/arch/powerpc/mm/mem.c 2007-10-30 07:39:16.000000000 -0800
+++ linux-2.6.24-rc1/arch/powerpc/mm/mem.c 2007-10-30 10:05:09.000000000 -0800
@@ -129,6 +129,19 @@ int __devinit arch_add_memory(int nid, u
return __add_pages(zone, start_pfn, nr_pages);
}
+/*
+ * I don't think we really need to do anything here to validate the memory
+ * range or walk the memory resource in lmb or device-tree. Only way we get
+ * the memory range here is through /sysfs in 16MB chunks and we are guaranteed
+ * to have a corresponding device-tree entry.
+ */
+int
+walk_memory_resource(unsigned long start_pfn, unsigned long nr_pages, void *arg,
+ int (*func)(unsigned long, unsigned long, void *))
+{
+ return (*func)(start_pfn, nr_pages, arg);
+}
+
#endif /* CONFIG_MEMORY_HOTPLUG */
#ifdef CONFIG_MEMORY_HOTREMOVE
Index: linux-2.6.24-rc1/kernel/resource.c
===================================================================
--- linux-2.6.24-rc1.orig/kernel/resource.c 2007-10-23 20:50:57.000000000 -0700
+++ linux-2.6.24-rc1/kernel/resource.c 2007-10-30 08:58:41.000000000 -0800
@@ -228,7 +228,7 @@ int release_resource(struct resource *ol
EXPORT_SYMBOL(release_resource);
-#ifdef CONFIG_MEMORY_HOTPLUG
+#if defined(CONFIG_MEMORY_HOTPLUG) && !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
/*
* Finds the lowest memory reosurce exists within [res->start.res->end)
* the caller must specify res->start, res->end, res->flags.
Index: linux-2.6.24-rc1/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.24-rc1.orig/arch/powerpc/Kconfig 2007-10-30 07:39:17.000000000 -0800
+++ linux-2.6.24-rc1/arch/powerpc/Kconfig 2007-10-30 08:54:57.000000000 -0800
@@ -234,6 +234,9 @@ config HOTPLUG_CPU
config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
+config ARCH_HAS_WALK_MEMORY
+ def_bool y
+
config ARCH_ENABLE_MEMORY_HOTREMOVE
def_bool y
^ 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