* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Benjamin Herrenschmidt @ 2008-04-24 3:30 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080424.120722.-1300531374.kouish@swc.toshiba.co.jp>
On Thu, 2008-04-24 at 12:07 +0900, Ishizaki Kou wrote:
>
> I'm sorry to have kept you waiting for my response.
>
> I just finished reviewing your patch. Your patch works well on
> Celleb, and I found I also should do the same thing for Celleb as you
> pointed. I will send a new patch which includes your fix.
Thanks. Please do so ASAP as tomorrow is non-working day and we are
getting close to -rc1.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] [POWERPC] cleanup misc_64.S
From: Kumar Gala @ 2008-04-24 3:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
* Removed get_msr(), get_srr0(), and get_srr1() - not used anywhere
* Use STACK_FRAME_OVERHEAD instead of magic number
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/misc_64.S | 20 ++++----------------
1 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index a3c491e..942951e 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -27,23 +27,11 @@
.text
-_GLOBAL(get_msr)
- mfmsr r3
- blr
-
-_GLOBAL(get_srr0)
- mfsrr0 r3
- blr
-
-_GLOBAL(get_srr1)
- mfsrr1 r3
- blr
-
#ifdef CONFIG_IRQSTACKS
_GLOBAL(call_do_softirq)
mflr r0
std r0,16(r1)
- stdu r1,THREAD_SIZE-112(r3)
+ stdu r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r3)
mr r1,r3
bl .__do_softirq
ld r1,0(r1)
@@ -56,7 +44,7 @@ _GLOBAL(call_handle_irq)
mflr r0
std r0,16(r1)
mtctr r8
- stdu r1,THREAD_SIZE-112(r5)
+ stdu r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r5)
mr r1,r5
bctrl
ld r1,0(r1)
@@ -599,7 +587,7 @@ _GLOBAL(kexec_sequence)
std r0,16(r1)
/* switch stacks to newstack -- &kexec_stack.stack */
- stdu r1,THREAD_SIZE-112(r3)
+ stdu r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r3)
mr r1,r3
li r0,0
@@ -616,7 +604,7 @@ _GLOBAL(kexec_sequence)
std r26,-48(r1)
std r25,-56(r1)
- stdu r1,-112-64(r1)
+ stdu r1,-STACK_FRAME_OVERHEAD-64(r1)
/* save args into preserved regs */
mr r31,r3 /* newstack (both) */
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Ishizaki Kou @ 2008-04-24 3:10 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1208396890.6958.323.camel@pasglop>
Ben-san,
I'm sorry to have kept you waiting for my response.
I just finished reviewing your patch. Your patch works well on
Celleb, and I found I also should do the same thing for Celleb as you
pointed. I will send a new patch which includes your fix.
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> So I found a few issues with your patch. Below is a "Fixup" patch that
> fixes the QS20 cell blades for me, but I would like you to apply that
> directly to your series and post a new version of it so that there
> is no breakage of QS20 during bisection.
>
> Note that I believe Celleb may have some problems too. See below.
>
> So the base issue was that on QS20, there was no struct device, thus the
> dma mapping would crash.
>
> I fixed that by changing the Cell blades code to create
> of_platform_device's for the PCI busses like it does on QS21 or later,
> and removed the initial call to the rtas PCI bus creation.
>
> Now, that doesn't fix it all....
>
> One thing I noticed in celleb_pci is that you initialize the workarounds
> for the bus after it's been created at device_initcall time. This is not
> good because at that time, drivers can already have been loaded &
> initialized, quirks have been run, etc... so it's actually too late to
> initialize the workarounds. They need to be initialized earlier.
You are right. It seems that celleb_pci happened to be initialized
earlier than PCI device drivers, so troubles (except that for quirks)
have been avoided. I will fix it by the new patch.
> I've tried something around the lines of initializing them from within
> the PHB setup callback, which happens before the PCI probe. You should
> be able to use the same approach for Celleb I suppose. Seems to work for
> me so far...
I will do the same way. Thanks for your advice.
> In addition, your patch would have called io_workaround_init() on QS21
> which doesn't need them (no Spider), thus slowing down access on
> machines that don't need the workarounds.
>
> My new code should hopefully only call this when needed. I made the call
> safe to call multiple time to avoid having to test in the caller.
>
> Another thing I noticed is that you removed the workaround to disable
> PCI prefetch. Is there a reason for that ? As far as I understand,
> prefetch is broken and can cause errors ranging from data corruption to
> iommu exceptions if the iommu is enabled. Maybe you want to make it
> depend on the revision of Spider in case your SCC has that fixed ?
Sorry, this was my mistake. I will put it back in a new patch.
> My patch doesn't change that but we might need to...
>
> So here is the patch. Please integrate my changes in your patch serie
> and re-post it (minus the two patches that Paulus already accepted).
Thanks, I'll do so. Can I add your 'Signed-off'?
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Ishizaki Kou @ 2008-04-24 3:07 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1208396890.6958.323.camel@pasglop>
Ben-san,
I'm sorry to have kept you waiting for my response.
I just finished reviewing your patch. Your patch works well on
Celleb, and I found I also should do the same thing for Celleb as you
pointed. I will send a new patch which includes your fix.
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> So I found a few issues with your patch. Below is a "Fixup" patch that
> fixes the QS20 cell blades for me, but I would like you to apply that
> directly to your series and post a new version of it so that there
> is no breakage of QS20 during bisection.
>
> Note that I believe Celleb may have some problems too. See below.
>
> So the base issue was that on QS20, there was no struct device, thus the
> dma mapping would crash.
>
> I fixed that by changing the Cell blades code to create
> of_platform_device's for the PCI busses like it does on QS21 or later,
> and removed the initial call to the rtas PCI bus creation.
>
> Now, that doesn't fix it all....
>
> One thing I noticed in celleb_pci is that you initialize the workarounds
> for the bus after it's been created at device_initcall time. This is not
> good because at that time, drivers can already have been loaded &
> initialized, quirks have been run, etc... so it's actually too late to
> initialize the workarounds. They need to be initialized earlier.
You are right. It seems that celleb_pci happened to be initialized
earlier than PCI device drivers, so troubles (except that for quirks)
have been avoided. I will fix it by the new patch.
> I've tried something around the lines of initializing them from within
> the PHB setup callback, which happens before the PCI probe. You should
> be able to use the same approach for Celleb I suppose. Seems to work for
> me so far...
I will do the same way. Thanks for your advice.
> In addition, your patch would have called io_workaround_init() on QS21
> which doesn't need them (no Spider), thus slowing down access on
> machines that don't need the workarounds.
>
> My new code should hopefully only call this when needed. I made the call
> safe to call multiple time to avoid having to test in the caller.
>
> Another thing I noticed is that you removed the workaround to disable
> PCI prefetch. Is there a reason for that ? As far as I understand,
> prefetch is broken and can cause errors ranging from data corruption to
> iommu exceptions if the iommu is enabled. Maybe you want to make it
> depend on the revision of Spider in case your SCC has that fixed ?
Sorry, this was my mistake. I will put it back in a new patch.
> My patch doesn't change that but we might need to...
>
> So here is the patch. Please integrate my changes in your patch serie
> and re-post it (minus the two patches that Paulus already accepted).
Thanks, I'll do so. Can I add your 'Signed-off'?
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: simpleboot
From: Josh Boyer @ 2008-04-24 3:08 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <480FEA44.8090105@picocomputing.net>
On Wed, 2008-04-23 at 22:02 -0400, David H. Lynch Jr. wrote:
> Josh Boyer wrote:
> > simpleboot is in Linus' tree now. It went in with the first pull
> > request paulus sent for .26.
> >
> I got it, now to figure it out.
> > I don't understand that comment anyway though. If you're working with a
> > PowerPC board, why aren't you using the powerpc tree (paulus') to begin
> > with? "Backporting" pieces of it to some other tree seems to be a waste
> > of time to me...
> >
> I am updating a port I did in 2005 ? based on the ml403 port that
> was in at that time.
> But it is an independent BSP. I need to move it to the current
> powerpc/devicetree,
> but I have to do so without breaking alot of things we have have
> working for years.
OK... and how does that dictate whether to use Linus' tree or paulus'
tree? Both are going to contain roughly the same amount of changes,
with the exception that paulus' tree will have more of the PowerPC
commits in it, including the Xilinx ml403 stuff from Grant.
> At the moment I am somewhat "surely" about a number of the issues
> related to the powerpc/devicetree migration.
> Aside from the BSP issues, this breaks my boot monitor, and is going
> to require adding alot more code than I can either justify
> or see as necescary because there are some aspects of how the
> devicetree/powerpc stuff is architected that
> politely I think are brain dead.
I don't mind people calling it brain dead. But if you were being
polite, you'd call it brain dead and then actually list the issues so
they could be discussed. Others might benefit from that discussion.
josh
^ permalink raw reply
* Re: mpc8379e rdb nand flash support
From: ??? @ 2008-04-24 1:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20080423163538.GA32452@ld0162-tx32.am.freescale.net>
SGkgU2NvdHQgV29vZDoNCiAgIFRoYW5rIHlvdSBmb3IgeW91ciBraW5kbHkgcmVwbHkhDQogICBJ
IGRpZCB1c2UgdGhlIGZyZWVzY2FsZSBic3AgKE1QQzgzN1hFLVJEQi0yMDA3MTEwNS5pc28pLkZv
ciB0aGUgSVNPIGRvZXNuJ3QgaGF2ZSB0aGUgTElOVVggTVREIHBhdGNoZXMgLEkgdXNlZCB0aGUg
TVBDODM3WEUtTURTIHBhdGNoZXMgLkFuZCB0aGUgc2Ftc3VuZyAzMk0gbmFuZCBmbGFzaCB3b3Jr
cyB3ZWxsIGJvdGggaW4gdS1ib290IGFuZCBsaW51eCBrZXJuZWwuDQogICANCiAgIFNpbmNlIG91
ciBwcm9qZWN0cyBuZWVkIG1vcmUgY2FwYWJpbGl0eSB0byBzdG9yZSBmaWxlc3lzdGVtcyxJIGNo
YW5nZWQgbmFuZCBmbGFzaCB0byAxRyBieXRlLg0KICAgIEkgdGhpbmsgaXQgaXMgdGhlIHNhbWUg
dG8gb3BlcmF0ZSBuYW5kIGZsYXNoIGJvdGggaW4gdS1ib290IGFuZCBsaW51eCBrZXJuZWwgLGJl
Y2F1c2UgdGhlIGNvZGUgYWJvdXQgRkNNIG5hbmQgZmxhc2ggY29udHJvbCBpcyBhbG1vc3QgdGhl
IHNhbWUuU28gSSBqdXN0IHRlc3QgaXQgaW4gdS1ib290Lg0KICAgIEZyb20gdGhlIG1wYzgzNzll
IHJlZmVyZW5jZSBtYW51YWwgcGFnZSA0ODQgOg0KICAgICAyMSAgICAgICAgUEdTIE5BTkQgRmxh
c2ggRTJQUk9NIHBhZ2Ugc2l6ZSwgYnVmZmVyIHNpemUsIGFuZCBibG9jayBzaXplLg0KICAgICAg
ICAgIDAgICBQYWdlIHNpemUgb2YgNTEyIG1haW4gYXJlYSBieXRlcyBwbHVzIDE2IHNwYXJlIGFy
ZWEgYnl0ZXMgKHNtYWxsIHBhZ2UgZGV2aWNlcyk7DQogICAgICAgICAgICAgIEZDTSBSQU0gYnVm
ZmVycyBhcmUgMSBLYnl0ZSBlYWNoOyBGbGFzaCBibG9jayBzaXplIG9mIDE2IEtieXRlcy4NCiAg
ICAgICAgICAxICAgUGFnZSBzaXplIG9mIDIwNDggbWFpbiBhcmVhIGJ5dGVzIHBsdXMgNjQgc3Bh
cmUgYXJlYSBieXRlcyAobGFyZ2UgcGFnZSBkZXZpY2VzKTsNCiAgICAgICAgICAgICAgRkNNIFJB
TSBidWZmZXJzIGFyZSA0IEtieXRlcyBlYWNoOyBGbGFzaCBibG9jayBzaXplIG9mIDEyOCBLYnl0
ZXMuDQoNCiAgICBCZWNhdXNlIHRoZSAzMk0gbmFuZCBmbGFzaCBibG9jayBzaXplIGlzIGp1c3Qg
dGhlIDE2S2J5dGVzLGFuZCBpdCB3b3JrcyB3ZWxsLkJ1dCB0aGUgYmxvY2sgc2l6ZSBvZiB0aGUg
MUcgYnl0ZXMgbmFuZCBmbGFzaCBpcyAyNTZLYnl0ZXMsd2hlbiBldmVyeSB0aW1lIEkgdHJpZWQg
dG8gd3JpdGUgdG8gaXQgLEl0IGp1c3QgY2FuIGJlIHdyaXRlZCB0aGUgZmlyc3QgMTI4a2J5dGVz
IG9mIGV2ZXJ5IDI1NmtieXRlcy5BcyBJIA0Kd3JvdGUgaW4gbGFzdCBlbWFpbC4NCiAgICBCZWxv
dyBpcyB0aGUgbGludXgga2VybmVsIGluZm9ybWF0aW9uIHdoZW4gSSBvcGVyYXRlIG5hbmQgZmxh
c2guDQogICANCiAgICBCZXN0IHdpc2hlcyAhDQoNCiAgICBCb2IgeXUgDQogICAgMjAwOC00LTI0
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLg0KLg0KLg0KLg0KDQpzZCAzOjA6MDowOiBBdHRhY2hl
ZCBzY3NpIGdlbmVyaWMgc2cwIHR5cGUgMA0KRnJlZXNjYWxlIGVMQkMgTkFORCBEcml2ZXIgKEMp
IDIwMDYtMjAwNyBGcmVlc2NhbGUNCk5BTkQgZGV2aWNlOiBNYW51ZmFjdHVyZXIgSUQ6IDB4YWQs
IENoaXAgSUQ6IDB4ZDMgKEh5bml4IE5BTkQgMUdpQiAzLDNWIDgtYml0KQ0KU2Nhbm5pbmcgZGV2
aWNlIGZvciBiYWQgYmxvY2tzDQpmc2wtZWxiYyBmc2wtZWxiYy4wOiBVc2luZyBPRiBwYXJ0aXRp
b24gaW5mb3JtYXRpb24NCkNyZWF0aW5nIDEgTVREIHBhcnRpdGlvbnMgb24gIm5hbmQiOg0KMHgw
MDAwMDAwMC0weDQwMDAwMDAwIDogIkpGRlMyLU5BTkQiDQppMmMgL2RldiBlbnRyaWVzIGRyaXZl
cg0KLg0KLg0KLg0KLg0KLXNoLTIuMDViIyBjZCAvDQotc2gtMi4wNWIjIGxzDQpiaW4gICAgICAg
ICBob21lICAgICAgICBtbnQgICAgICAgICByb290ICAgICAgICB0bXANCmJvb3QgICAgICAgIGxp
YiAgICAgICAgIG11c2ljICAgICAgIHNiaW4gICAgICAgIHVzcg0KZGV2ICAgICAgICAgbGludXhy
YyAgICAgb3B0ICAgICAgICAgc2hhcmUgICAgICAgdmFyDQpldGMgICAgICAgICBsb3N0K2ZvdW5k
ICBwcm9jICAgICAgICBzeXMNCi1zaC0yLjA1YiMgc21iZA0KLXNoLTIuMDViIyBjaG1vZCA3Nzcg
Lw0KLXNoLTIuMDViIyBscw0KYmluICAgICAgICAgaG9tZSAgICAgICAgbW50ICAgICAgICAgcm9v
dCAgICAgICAgdGVzdC5qZmZzMg0KYm9vdCAgICAgICAgbGliICAgICAgICAgbXVzaWMgICAgICAg
c2JpbiAgICAgICAgdG1wDQpkZXYgICAgICAgICBsaW51eHJjICAgICBvcHQgICAgICAgICBzaGFy
ZSAgICAgICB1c3INCmV0YyAgICAgICAgIGxvc3QrZm91bmQgIHByb2MgICAgICAgIHN5cyAgICAg
ICAgIHZhcg0KLXNoLTIuMDViIyBjYXQgL3Byb2MvbXRkICAgIA0KZGV2OiAgICBzaXplICAgZXJh
c2VzaXplICBuYW1lDQptdGQwOiA0MDAwMDAwMCAwMDA0MDAwMCAiSkZGUzItTkFORCINCi1zaC0y
LjA1YiMgY3AgdGVzdC5qZmZzMiAvZGV2L210ZGJsb2NrMCANCmVuZF9yZXF1ZXN0OiBJL08gZXJy
b3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAwDQpCdWZmZXIgSS9PIGVycm9yIG9uIGRldmljZSBt
dGRibG9jazAsIGxvZ2ljYWwgYmxvY2sgMA0KbG9zdCBwYWdlIHdyaXRlIGR1ZSB0byBJL08gZXJy
b3Igb24gbXRkYmxvY2swDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBz
ZWN0b3IgOA0KQnVmZmVyIEkvTyBlcnJvciBvbiBkZXZpY2UgbXRkYmxvY2swLCBsb2dpY2FsIGJs
b2NrIDENCmxvc3QgcGFnZSB3cml0ZSBkdWUgdG8gSS9PIGVycm9yIG9uIG10ZGJsb2NrMA0KZW5k
X3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDE2DQpCdWZmZXIgSS9P
IGVycm9yIG9uIGRldmljZSBtdGRibG9jazAsIGxvZ2ljYWwgYmxvY2sgMg0KbG9zdCBwYWdlIHdy
aXRlIGR1ZSB0byBJL08gZXJyb3Igb24gbXRkYmxvY2swDQplbmRfcmVxdWVzdDogSS9PIGVycm9y
LCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjQNCkJ1ZmZlciBJL08gZXJyb3Igb24gZGV2aWNlIG10
ZGJsb2NrMCwgbG9naWNhbCBibG9jayAzDQpsb3N0IHBhZ2Ugd3JpdGUgZHVlIHRvIEkvTyBlcnJv
ciBvbiBtdGRibG9jazANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNl
Y3RvciAzMg0KQnVmZmVyIEkvTyBlcnJvciBvbiBkZXZpY2UgbXRkYmxvY2swLCBsb2dpY2FsIGJs
b2NrIDQNCmxvc3QgcGFnZSB3cml0ZSBkdWUgdG8gSS9PIGVycm9yIG9uIG10ZGJsb2NrMA0KZW5k
X3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDQwDQpCdWZmZXIgSS9P
IGVycm9yIG9uIGRldmljZSBtdGRibG9jazAsIGxvZ2ljYWwgYmxvY2sgNQ0KbG9zdCBwYWdlIHdy
aXRlIGR1ZSB0byBJL08gZXJyb3Igb24gbXRkYmxvY2swDQplbmRfcmVxdWVzdDogSS9PIGVycm9y
LCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgNDgNCkJ1ZmZlciBJL08gZXJyb3Igb24gZGV2aWNlIG10
ZGJsb2NrMCwgbG9naWNhbCBibG9jayA2DQpsb3N0IHBhZ2Ugd3JpdGUgZHVlIHRvIEkvTyBlcnJv
ciBvbiBtdGRibG9jazANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNl
Y3RvciA1Ng0KQnVmZmVyIEkvTyBlcnJvciBvbiBkZXZpY2UgbXRkYmxvY2swLCBsb2dpY2FsIGJs
b2NrIDcNCmxvc3QgcGFnZSB3cml0ZSBkdWUgdG8gSS9PIGVycm9yIG9uIG10ZGJsb2NrMA0KZW5k
X3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDY0DQpCdWZmZXIgSS9P
IGVycm9yIG9uIGRldmljZSBtdGRibG9jazAsIGxvZ2ljYWwgYmxvY2sgOA0KbG9zdCBwYWdlIHdy
aXRlIGR1ZSB0byBJL08gZXJyb3Igb24gbXRkYmxvY2swDQplbmRfcmVxdWVzdDogSS9PIGVycm9y
LCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgNzINCkJ1ZmZlciBJL08gZXJyb3Igb24gZGV2aWNlIG10
ZGJsb2NrMCwgbG9naWNhbCBibG9jayA5DQpsb3N0IHBhZ2Ugd3JpdGUgZHVlIHRvIEkvTyBlcnJv
ciBvbiBtdGRibG9jazANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNl
Y3RvciA4MA0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDg4
DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgOTYNCmVuZF9y
ZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAxMDQNCmVuZF9yZXF1ZXN0
OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAxMTINCmVuZF9yZXF1ZXN0OiBJL08g
ZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAxMjANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3Is
IGRldiBtdGRibG9jazAsIHNlY3RvciAxMjgNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBt
dGRibG9jazAsIHNlY3RvciAxMzYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9j
azAsIHNlY3RvciAxNDQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNl
Y3RvciAxNTINCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAx
NjANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAxNjgNCmVu
ZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAxNzYNCmVuZF9yZXF1
ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAxODQNCmVuZF9yZXF1ZXN0OiBJ
L08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAxOTINCmVuZF9yZXF1ZXN0OiBJL08gZXJy
b3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyMDANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRl
diBtdGRibG9jazAsIHNlY3RvciAyMDgNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRi
bG9jazAsIHNlY3RvciAyMTYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAs
IHNlY3RvciAyMjQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3Rv
ciAyMzINCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyNDAN
CmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyNDgNCmVuZF9y
ZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyNTYNCmVuZF9yZXF1ZXN0
OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyNjQNCmVuZF9yZXF1ZXN0OiBJL08g
ZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyNzINCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3Is
IGRldiBtdGRibG9jazAsIHNlY3RvciAyODANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBt
dGRibG9jazAsIHNlY3RvciAyODgNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9j
azAsIHNlY3RvciAyOTYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNl
Y3RvciAzMDQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAz
MTINCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAzMjANCmVu
ZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAzMjgNCmVuZF9yZXF1
ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAzMzYNCmVuZF9yZXF1ZXN0OiBJ
L08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAzNDQNCmVuZF9yZXF1ZXN0OiBJL08gZXJy
b3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAzNTINCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRl
diBtdGRibG9jazAsIHNlY3RvciAzNjANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRi
bG9jazAsIHNlY3RvciAzNjgNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAs
IHNlY3RvciAzNzYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3Rv
ciAzODQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAzOTIN
CmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA0MDANCmVuZF9y
ZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA0MDgNCmVuZF9yZXF1ZXN0
OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA0MTYNCmVuZF9yZXF1ZXN0OiBJL08g
ZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA0MjQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3Is
IGRldiBtdGRibG9jazAsIHNlY3RvciA0MzINCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBt
dGRibG9jazAsIHNlY3RvciA0NDANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9j
azAsIHNlY3RvciA0NDgNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNl
Y3RvciA0NTYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA0
NjQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA0NzINCmVu
ZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA0ODANCmVuZF9yZXF1
ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA0ODgNCmVuZF9yZXF1ZXN0OiBJ
L08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA0OTYNCmVuZF9yZXF1ZXN0OiBJL08gZXJy
b3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA1MDQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRl
diBtdGRibG9jazAsIHNlY3RvciA1MTINCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRi
bG9jazAsIHNlY3RvciA1MjANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAs
IHNlY3RvciA1MjgNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3Rv
ciA1MzYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA1NDQN
CmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA1NTINCmVuZF9y
ZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA1NjANCmVuZF9yZXF1ZXN0
OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA1NjgNCmVuZF9yZXF1ZXN0OiBJL08g
ZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA1NzYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3Is
IGRldiBtdGRibG9jazAsIHNlY3RvciA1ODQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBt
dGRibG9jazAsIHNlY3RvciA1OTINCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9j
azAsIHNlY3RvciA2MDANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNl
Y3RvciA2MDgNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA2
MTYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA2MjQNCmVu
ZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA2MzINCmVuZF9yZXF1
ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA2NDANCmVuZF9yZXF1ZXN0OiBJ
L08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA2NDgNCmVuZF9yZXF1ZXN0OiBJL08gZXJy
b3IsIGRldiBtdGRibG9jazAsIHNlY3RvciA2NTYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRl
diBtdGRibG9jazAsIHNlY3RvciA2NjQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRi
bG9jazAsIHNlY3RvciA2NzINCnByaW50azogNzQgbWVzc2FnZXMgc3VwcHJlc3NlZC4NCkJ1ZmZl
ciBJL08gZXJyb3Igb24gZGV2aWNlIG10ZGJsb2NrMCwgbG9naWNhbCBibG9jayA4NA0KbG9zdCBw
YWdlIHdyaXRlIGR1ZSB0byBJL08gZXJyb3Igb24gbXRkYmxvY2swDQplbmRfcmVxdWVzdDogSS9P
IGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgNjgwDQplbmRfcmVxdWVzdDogSS9PIGVycm9y
LCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgNjg4DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYg
bXRkYmxvY2swLCBzZWN0b3IgNjk2DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxv
Y2swLCBzZWN0b3IgNzA0DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBz
ZWN0b3IgNzEyDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3Ig
NzIwDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgNzI4DQpl
bmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgNzM2DQplbmRfcmVx
dWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgNzQ0DQplbmRfcmVxdWVzdDog
SS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgNzUyDQplbmRfcmVxdWVzdDogSS9PIGVy
cm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgNzYwDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBk
ZXYgbXRkYmxvY2swLCBzZWN0b3IgNzY4DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRk
YmxvY2swLCBzZWN0b3IgNzc2DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2sw
LCBzZWN0b3IgNzg0DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0
b3IgNzkyDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgODAw
DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgODA4DQplbmRf
cmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgODE2DQplbmRfcmVxdWVz
dDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgODI0DQplbmRfcmVxdWVzdDogSS9P
IGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgODMyDQplbmRfcmVxdWVzdDogSS9PIGVycm9y
LCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgODQwDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYg
bXRkYmxvY2swLCBzZWN0b3IgODQ4DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxv
Y2swLCBzZWN0b3IgODU2DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBz
ZWN0b3IgODY0DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3Ig
ODcyDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgODgwDQpl
bmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgODg4DQplbmRfcmVx
dWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgODk2DQplbmRfcmVxdWVzdDog
SS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgOTA0DQplbmRfcmVxdWVzdDogSS9PIGVy
cm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgOTEyDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBk
ZXYgbXRkYmxvY2swLCBzZWN0b3IgOTIwDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRk
YmxvY2swLCBzZWN0b3IgOTI4DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2sw
LCBzZWN0b3IgOTM2DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0
b3IgOTQ0DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgOTUy
DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgOTYwDQplbmRf
cmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgOTY4DQplbmRfcmVxdWVz
dDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgOTc2DQplbmRfcmVxdWVzdDogSS9P
IGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgOTg0DQplbmRfcmVxdWVzdDogSS9PIGVycm9y
LCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgOTkyDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYg
bXRkYmxvY2swLCBzZWN0b3IgMTAwMA0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJs
b2NrMCwgc2VjdG9yIDEwMDgNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAs
IHNlY3RvciAxMDE2DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0
b3IgMjA0OA0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDIw
NTYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyMDY0DQpl
bmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjA3Mg0KZW5kX3Jl
cXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDIwODANCmVuZF9yZXF1ZXN0
OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyMDg4DQplbmRfcmVxdWVzdDogSS9P
IGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjA5Ng0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJv
ciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDIxMDQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRl
diBtdGRibG9jazAsIHNlY3RvciAyMTEyDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRk
YmxvY2swLCBzZWN0b3IgMjEyMA0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2Nr
MCwgc2VjdG9yIDIxMjgNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNl
Y3RvciAyMTM2DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3Ig
MjE0NA0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDIxNTIN
CmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyMTYwDQplbmRf
cmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjE2OA0KZW5kX3JlcXVl
c3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDIxNzYNCmVuZF9yZXF1ZXN0OiBJ
L08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyMTg0DQplbmRfcmVxdWVzdDogSS9PIGVy
cm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjE5Mg0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwg
ZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDIyMDANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBt
dGRibG9jazAsIHNlY3RvciAyMjA4DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxv
Y2swLCBzZWN0b3IgMjIxNg0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwg
c2VjdG9yIDIyMjQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3Rv
ciAyMjMyDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjI0
MA0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDIyNDgNCmVu
ZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyMjU2DQplbmRfcmVx
dWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjI2NA0KZW5kX3JlcXVlc3Q6
IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDIyNzINCmVuZF9yZXF1ZXN0OiBJL08g
ZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyMjgwDQplbmRfcmVxdWVzdDogSS9PIGVycm9y
LCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjI4OA0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2
IG10ZGJsb2NrMCwgc2VjdG9yIDIyOTYNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRi
bG9jazAsIHNlY3RvciAyMzA0DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2sw
LCBzZWN0b3IgMjMxMg0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2Vj
dG9yIDIzMjANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAy
MzI4DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjMzNg0K
cHJpbnRrOiA3OSBtZXNzYWdlcyBzdXBwcmVzc2VkLg0KQnVmZmVyIEkvTyBlcnJvciBvbiBkZXZp
Y2UgbXRkYmxvY2swLCBsb2dpY2FsIGJsb2NrIDI5Mg0KbG9zdCBwYWdlIHdyaXRlIGR1ZSB0byBJ
L08gZXJyb3Igb24gbXRkYmxvY2swDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxv
Y2swLCBzZWN0b3IgMjM0NA0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwg
c2VjdG9yIDIzNTINCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3Rv
ciAyMzYwDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjM2
OA0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDIzNzYNCmVu
ZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyMzg0DQplbmRfcmVx
dWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjM5Mg0KZW5kX3JlcXVlc3Q6
IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDI0MDANCmVuZF9yZXF1ZXN0OiBJL08g
ZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyNDA4DQplbmRfcmVxdWVzdDogSS9PIGVycm9y
LCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjQxNg0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2
IG10ZGJsb2NrMCwgc2VjdG9yIDI0MjQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRi
bG9jazAsIHNlY3RvciAyNDMyDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2sw
LCBzZWN0b3IgMjQ0MA0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2Vj
dG9yIDI0NDgNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAy
NDU2DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjQ2NA0K
ZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDI0NzINCmVuZF9y
ZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyNDgwDQplbmRfcmVxdWVz
dDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBzZWN0b3IgMjQ4OA0KZW5kX3JlcXVlc3Q6IEkv
TyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9yIDI0OTYNCmVuZF9yZXF1ZXN0OiBJL08gZXJy
b3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyNTA0DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBk
ZXYgbXRkYmxvY2swLCBzZWN0b3IgMjUxMg0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10
ZGJsb2NrMCwgc2VjdG9yIDI1MjANCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9j
azAsIHNlY3RvciAyNTI4DQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbXRkYmxvY2swLCBz
ZWN0b3IgMjUzNg0KZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IG10ZGJsb2NrMCwgc2VjdG9y
IDI1NDQNCmVuZF9yZXF1ZXN0OiBJL08gZXJyb3IsIGRldiBtdGRibG9jazAsIHNlY3RvciAyNTUy
DQovLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KRnJvbTogIlNjb3R0IFdvb2QiIDxzY290dHdvb2RAZnJlZXNjYWxlLmNvbT4NClNlbnQ6IFRo
dXJzZGF5LCBBcHJpbCAyNCwgMjAwOCAxMjozNSBBTQ0KVG86ICI/Pz8iIDx5dXlvbmdiYW9AMTI2
LmNvbT4NCkNjOiA8bGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZz4NClN1YmplY3Q6IFJlOiBt
cGM4Mzc5ZSByZGIgbmFuZCBmbGFzaCBzdXBwb3J0DQoNCj4gT24gV2VkLCBBcHIgMjMsIDIwMDgg
YXQgMDM6NDc6MDBQTSArMDgwMCwgPz8/IHdyb3RlOg0KPj4gRGVhciBhbGw6DQo+PiAgICAgRGlk
IGFueW9uZSB1c2UgbXBjODM3OWVyZGIgYm9hcmQ/ICBJIGNoYW5nZWQgbmFuZCBmbGFzaCBmcm9t
IHNhbXN1bmcgMzJNIHRvIGh5bml4IDFHIGJ5dGUuQW5kIHRoZSAxRyBieXRlIG5hbmQncyBlcmFz
ZSBibG9jayBzaXplIGlzIDI1NktCLg0KPj4gICAgIE5vdyB0aGUgcHJvYmxlbSBpczogd2hlbiBJ
IHVzZSAiIG5hbmQgd3JpdGUuamZmczIiIGNvbW1hbmQgdG8gd3JpdGUgamZmczIgZmlsZXN5c3Rl
bXMgdG8gbmFuZCBmbGFzaCAsdGhlcmUgaXMgb25seSAxMjhLQnl0ZSBvZiBldmVyeSBlcmFzZSBi
bG9ja3MgY2FuIGJlIHdyaXRlZC4NCj4+ICAgICBGcm9tIHRoZSBkYXRhc2hlZXQgb2YgdGhlIG1w
YzgzNzllICwiUGFnZSBzaXplIG9mIDIwNDggbWFpbiBhcmVhIGJ5dGVzIHBsdXMgNjQgc3BhcmUg
YXJlYSBieXRlcyAobGFyZ2UgcGFnZSBkZXZpY2VzKTsNCj4+IEZDTSBSQU0gYnVmZmVycyBhcmUg
NCBLYnl0ZXMgZWFjaDsgRmxhc2ggYmxvY2sgc2l6ZSBvZiAxMjggS2J5dGVzLiINCj4+ICAgICBJ
cyBpdCBtZWFucyBtcGM4Mzc5ZSBvbmx5IHN1cHBvcnQgMTI4S2J5dGVzIGJsb2NrIHNpemU/DQo+
PiAgICAgSGVyZSBpcyB0aGUgaW5mb3JtYXRpb24gd2hlbiBJIHRyaWVkIHRvIHdyaXRlIGl0IDoN
Cj4gDQo+IEl0IGxvb2tzIGxpa2UgeW91J3JlIHRhbGtpbmcgYWJvdXQgdS1ib290LCBub3QgTGlu
dXg7IHRoZSBGQ00gTkFORCBkcml2ZXINCj4gaGFzIG5vdCB5ZXQgYmVlbiBtZXJnZWQuICBBcmUg
eW91IHVzaW5nIGEgRnJlZXNjYWxlIEJTUD8gIElmIHNvLCBpdCdzDQo+IGJlc3QgdG8gZ28gdGhy
b3VnaCBvZmZpY2lhbCBzdXBwb3J0IGNoYW5uZWxzLiAgSWYgeW91J3JlIHVzaW5nIHBhdGNoZXMN
Cj4gdGhhdCB3ZXJlIHJlY2VudGx5IHBvc3RlZCwgbWFrZSBzdXJlIHlvdSBoYXZlIGFsbCB0aGUg
YnVnZml4ZXMgdGhhdA0KPiByZWNlbnRseSB3ZW50IGludG8gdGhlIGxpbnV4IG10ZCB0cmVlLg0K
PiANCj4gLVNjb3R0IA==
^ permalink raw reply
* Re: simpleboot
From: David H. Lynch Jr. @ 2008-04-24 2:02 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <1208999357.2946.6.camel@vader.jdub.homelinux.org>
Josh Boyer wrote:
> simpleboot is in Linus' tree now. It went in with the first pull
> request paulus sent for .26.
>
I got it, now to figure it out.
> I don't understand that comment anyway though. If you're working with a
> PowerPC board, why aren't you using the powerpc tree (paulus') to begin
> with? "Backporting" pieces of it to some other tree seems to be a waste
> of time to me...
>
I am updating a port I did in 2005 ? based on the ml403 port that
was in at that time.
But it is an independent BSP. I need to move it to the current
powerpc/devicetree,
but I have to do so without breaking alot of things we have have
working for years.
At the moment I am somewhat "surely" about a number of the issues
related to the powerpc/devicetree migration.
Aside from the BSP issues, this breaks my boot monitor, and is going
to require adding alot more code than I can either justify
or see as necescary because there are some aspects of how the
devicetree/powerpc stuff is architected that
politely I think are brain dead.
But I will get over it - probably. There just may be a bit of
cursing and foul language before things work.
--
Dave Lynch Pico Computing, Inc.
Software Development Embedded Linux
717.627.3770 dhlii@picocomputing.net http://www.picocomputing.com
fax: 1.253.369.9244 Cell: 1.717.587.7774
Tiny Mighty Machines
^ permalink raw reply
* [PATCH] Use of_get_next_parent() in platforms/cell/axon_msi.c
From: Michael Ellerman @ 2008-04-24 2:08 UTC (permalink / raw)
To: linuxppc-dev
Replace two open-coded occurences of the of_get_next_parent() logic.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
The function touched by the first chunk still needs the tmp variable.
arch/powerpc/platforms/cell/axon_msi.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
index d95e71d..c39f5c2 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -123,7 +123,7 @@ static struct axon_msic *find_msi_translator(struct pci_dev *dev)
return NULL;
}
- for (; dn; tmp = of_get_parent(dn), of_node_put(dn), dn = tmp) {
+ for (; dn; dn = of_get_next_parent(dn)) {
ph = of_get_property(dn, "msi-translator", NULL);
if (ph)
break;
@@ -169,7 +169,7 @@ static int axon_msi_check_device(struct pci_dev *dev, int nvec, int type)
static int setup_msi_msg_address(struct pci_dev *dev, struct msi_msg *msg)
{
- struct device_node *dn, *tmp;
+ struct device_node *dn;
struct msi_desc *entry;
int len;
const u32 *prop;
@@ -182,7 +182,7 @@ static int setup_msi_msg_address(struct pci_dev *dev, struct msi_msg *msg)
entry = list_first_entry(&dev->msi_list, struct msi_desc, list);
- for (; dn; tmp = of_get_parent(dn), of_node_put(dn), dn = tmp) {
+ for (; dn; dn = of_get_next_parent(dn)) {
if (entry->msi_attrib.is_64) {
prop = of_get_property(dn, "msi-address-64", &len);
if (prop)
--
1.5.5
^ permalink raw reply related
* [PATCH] Discourage people from fiddling with kernel data from prom_init
From: Michael Ellerman @ 2008-04-24 2:08 UTC (permalink / raw)
To: linuxppc-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3336 bytes --]
As BenH said the other day, it is an "accident" that prom_init.o is linked
with the rest of the kernel. The truth is a little more subtle, prom_init
isn't truly bootloader, it does fiddle with kernel data in a few places.
What we can do is discourage people from adding new code that accesses
data outside of prom_init. And hence this patch, from the script:
# This script checks prom_init.o to see what external symbols it
# is using, if it finds symbols not in the whitelist it returns
# an error. The point of this is to discourage people from
# intentionally or accidentally adding new code to prom_init.c
# which has side effects on other parts of the kernel.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/Makefile | 9 +++++
arch/powerpc/kernel/prom_init_check.sh | 58 ++++++++++++++++++++++++++++++++
2 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 5183a90..562bb02 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -106,4 +106,13 @@ PHONY += systbl_chk
systbl_chk: $(src)/systbl_chk.sh $(obj)/systbl_chk.i
$(call cmd,systbl_chk)
+$(obj)/built-in.o: prom_init_check
+
+quiet_cmd_prom_init_check = CALL $<
+ cmd_prom_init_check = $(CONFIG_SHELL) $< "$(NM)" "$(obj)/prom_init.o"
+
+PHONY += prom_init_check
+prom_init_check: $(src)/prom_init_check.sh $(obj)/prom_init.o
+ $(call cmd,prom_init_check)
+
clean-files := vmlinux.lds
diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/kernel/prom_init_check.sh
new file mode 100644
index 0000000..8e24fc1
--- /dev/null
+++ b/arch/powerpc/kernel/prom_init_check.sh
@@ -0,0 +1,58 @@
+#!/bin/sh
+#
+# Copyright © 2008 IBM Corporation
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version
+# 2 of the License, or (at your option) any later version.
+
+# This script checks prom_init.o to see what external symbols it
+# is using, if it finds symbols not in the whitelist it returns
+# an error. The point of this is to discourage people from
+# intentionally or accidentally adding new code to prom_init.c
+# which has side effects on other parts of the kernel.
+
+# If you really need to reference something from prom_init.o add
+# it to the list below:
+
+WHITELIST="add_reloc_offset __bss_start __bss_stop copy_and_flush
+_end enter_prom memcpy memset reloc_offset __secondary_hold
+__secondary_hold_acknowledge __secondary_hold_spinloop __start
+strcmp strcpy strlcpy strlen strncmp strstr logo_linux_clut224
+reloc_got2"
+
+NM="$1"
+OBJ="$2"
+
+ERROR=0
+
+for UNDEF in $($NM -u $OBJ | awk '{print $2}')
+do
+ # On 64-bit nm gives us the function descriptors, which have
+ # a leading . on the name, so strip it off here.
+ UNDEF="${UNDEF#.}"
+
+ if [ $KBUILD_VERBOSE ]; then
+ if [ $KBUILD_VERBOSE -ne 0 ]; then
+ echo "Checking prom_init.o symbol '$UNDEF'"
+ fi
+ fi
+
+ OK=0
+ for WHITE in $WHITELIST
+ do
+ if [ "$UNDEF" = "$WHITE" ]; then
+ OK=1
+ break
+ fi
+ done
+
+ if [ $OK -eq 0 ]; then
+ ERROR=1
+ echo "Error: External symbol '$UNDEF' referenced" \
+ "from prom_init.c" >&2
+ fi
+done
+
+exit $ERROR
--
1.5.5
^ permalink raw reply related
* Re: simpleboot
From: David H. Lynch Jr. @ 2008-04-24 1:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40804231248s162479d9o530051d3c88da471@mail.gmail.com>
Grant Likely wrote:
> Its whatever kind of image you pass it.
>
>
The simpleboot stuff must have hit Linux's tree today.
I synced with it.
created an arch/powerpc/boot/dts/pico_e1x.dts that is probably fouled up
- but that is a problem for later.
did:
make -f Makefile ARCH=powerpc CROSS_COMPILE=powerpc-linux-uclibc-
simpleImage.pico_e1x
had to deal with a few different config options and then got:
make[1]: Entering directory `/usr/src/linux-2.6.pico'
make[1]: *** No rule to make target `simpleImage.pico_e1x'. Stop.
make[1]: Leaving directory `/usr/src/linux-2.6.pico'
make: *** [release] Error 2
So how does the top level Makefile know about the simpeImage.% target
in arch/powerpc/boot ?
--
Dave Lynch Pico Computing, Inc.
Software Development Embedded Linux
717.627.3770 dhlii@picocomputing.net http://www.picocomputing.com
fax: 1.253.369.9244 Cell: 1.717.587.7774
Tiny Mighty Machines
^ permalink raw reply
* Re: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
From: Josh Boyer @ 2008-04-24 1:10 UTC (permalink / raw)
To: Stefan Roese; +Cc: u-boot-users, linuxppc-embedded
In-Reply-To: <200804231449.24746.sr@denx.de>
On Wed, 2008-04-23 at 14:49 +0200, Stefan Roese wrote:
> On Wednesday 23 April 2008, Dave Littell wrote:
> > At this point all possibilities are on the table and I'm looking for any
> > input from anyone with experience (good, bad, or whatever) with this
> > processor and/or designs similar to the Sequoia.
>
> If you scan the U-Boot mailing list for 440EPx/Denali DDR2 problems, you will
> most likely find some references.
>
> Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the
> 440EPx CHIP 11 errata. I suggest you take a look at this too and see if this
> changes your behavior.
Explain this a bit more please? Is a kernel change needed here?
josh
^ permalink raw reply
* Re: simpleboot
From: Josh Boyer @ 2008-04-24 1:09 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <480F917F.8040809@picocomputing.net>
On Wed, 2008-04-23 at 15:43 -0400, David H. Lynch Jr. wrote:
> Grant Likely wrote:
> > make simpleImage.<boardname>
> > - or -
> > make simpleImage.initrd.<boardname>
> >
> > The makefile will use arch/powerpc/boot/dts/<boardname>.dts for the device tree.
> Thanks, I suspected most of that. But I have not see simpleboot in
> Linus's tree yet,
> so I have to back port the patch from the paulus tree and that makes
> it harder to just try it.
simpleboot is in Linus' tree now. It went in with the first pull
request paulus sent for .26.
I don't understand that comment anyway though. If you're working with a
PowerPC board, why aren't you using the powerpc tree (paulus') to begin
with? "Backporting" pieces of it to some other tree seems to be a waste
of time to me...
josh
^ permalink raw reply
* Re: Patches added to powerpc.git master and powerpc-next branches
From: Benjamin Herrenschmidt @ 2008-04-24 0:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <CA750B46-2360-4C75-8F8E-5DFD0FB9807C@kernel.crashing.org>
On Wed, 2008-04-23 at 07:49 -0500, Kumar Gala wrote:
> its left over from the x86 port. I'll get rid of
> __FIXADDR_BOOT_SIZE,
> FIXADDR_BOOT_START, and __FIXADDR_TOP.
>
> If we want the early ioremap support in the future we can add back
> __FIXADDR_BOOT_SIZE and FIXADDR_BOOT_START.
Our early ioremap works differently. Do you see any reason why we may
want to do it like x86 instead ? Is it any better ?
Ben.
^ permalink raw reply
* Re: new warnings from stacktrace patch
From: Benjamin Herrenschmidt @ 2008-04-24 0:44 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Stephen Rothwell, Paul Mackerras, ppc-dev
In-Reply-To: <20080423143229.GA18667@lst.de>
On Wed, 2008-04-23 at 16:32 +0200, Christoph Hellwig wrote:
> On Wed, Apr 23, 2008 at 05:59:38PM +1000, Stephen Rothwell wrote:
> > This is from commit fd3e0bbc6052ca9747a5332b382584ece83aab6d ("[POWERPC]
> > Stacktrace support for lockdep"). We don't include asm-offsets.h in any
> > other C file in the powerpc build.
>
> I think the include can be safely removed.
Yup. It's a leftover from before I fixed up some stuff in ptrace.h
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Ack.
> Index: linux-2.6/arch/powerpc/kernel/stacktrace.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/stacktrace.c 2008-04-23 15:28:05.000000000 +0200
> +++ linux-2.6/arch/powerpc/kernel/stacktrace.c 2008-04-23 15:28:16.000000000 +0200
> @@ -13,7 +13,6 @@
> #include <linux/sched.h>
> #include <linux/stacktrace.h>
> #include <asm/ptrace.h>
> -#include <asm/asm-offsets.h>
>
> /*
> * Save stack-backtrace addresses into a stack_trace buffer.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 2/2 v2] mpic_u3msi: mpic_u3msi: failed allocation unnoticed
From: Benjamin Herrenschmidt @ 2008-04-24 0:42 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Roel Kluin, lkml, paulus
In-Reply-To: <1208993783.9245.10.camel@concordia.ozlabs.ibm.com>
On Thu, 2008-04-24 at 09:36 +1000, Michael Ellerman wrote:
>
> I think the real bug is that we're using irq_hw_number_t to represent
> something which isn't. At the end of the day we have to stash the
> hwirq
> into the MSI message data, which is a u32.
>
> I guess we could imagine a driver that does something magic to allow
> it
> to put something bigger than a u32 in the MSI message, but I doubt it.
>
> So I think mpic_msi_alloc_hwirqs() should return a long, which allows
> it to return a full u32 plus the negative error values.
Until it's used on 32 bits...
Make it return an int error code and pass the hwirq elsewhere or use the
"illegal" hwirq number (each PIC defines one) as the error return.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/2 v2] mpic_u3msi: mpic_u3msi: failed allocation unnoticed
From: Michael Ellerman @ 2008-04-23 23:36 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, paulus, lkml
In-Reply-To: <480FB766.1040405@tiscali.nl>
[-- Attachment #1: Type: text/plain, Size: 2304 bytes --]
On Thu, 2008-04-24 at 00:25 +0200, Roel Kluin wrote:
> Segher Boessenkool wrote:
> >> bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may
> >> return -ENOMEM, but hwirq of type irq_hw_number_t which is unsigned.
> >
> >> list_for_each_entry(entry, &pdev->msi_list, list) {
> >> hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
> >> - if (hwirq < 0) {
> >> + if (hwirq == -ENOMEM) {
>
> >
> > Please test for _all_ error values, instead.
> >
> > Segher
>
> In this case -ENOMEM was _all_ error values, but I get your point.
> ---
> bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may return
> signed, but hwirq is unsigned. A failed allocation remains unnoticed.
>
> diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
> index 1d5a408..e790f39 100644
> --- a/arch/powerpc/sysdev/mpic_u3msi.c
> +++ b/arch/powerpc/sysdev/mpic_u3msi.c
> @@ -115,14 +115,16 @@ static int u3msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
> struct msi_desc *entry;
> struct msi_msg msg;
> u64 addr;
> + int ret;
>
> addr = find_ht_magic_addr(pdev);
> msg.address_lo = addr & 0xFFFFFFFF;
> msg.address_hi = addr >> 32;
>
> list_for_each_entry(entry, &pdev->msi_list, list) {
> - hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
> - if (hwirq < 0) {
> + ret = mpic_msi_alloc_hwirqs(msi_mpic, 1);
> + hwirq = ret;
> + if (ret < 0) {
> pr_debug("u3msi: failed allocating hwirq\n");
> return hwirq;
> }
I'm not sure I like this.
I think the real bug is that we're using irq_hw_number_t to represent
something which isn't. At the end of the day we have to stash the hwirq
into the MSI message data, which is a u32.
I guess we could imagine a driver that does something magic to allow it
to put something bigger than a u32 in the MSI message, but I doubt it.
So I think mpic_msi_alloc_hwirqs() should return a long, which allows
it to return a full u32 plus the negative error values.
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
* Re: [PATCH 2/2 v2] mpic_u3msi: mpic_u3msi: failed allocation unnoticed
From: Roel Kluin @ 2008-04-23 23:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus, lkml
In-Reply-To: <480FB766.1040405@tiscali.nl>
Again thanks to Segher and Joe Perches
---
bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may return
signed, but hwirq is unsigned. A failed allocation remains unnoticed.
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index 1d5a408..6e2f868 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -115,17 +115,19 @@ static int u3msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
struct msi_desc *entry;
struct msi_msg msg;
u64 addr;
+ int ret;
addr = find_ht_magic_addr(pdev);
msg.address_lo = addr & 0xFFFFFFFF;
msg.address_hi = addr >> 32;
list_for_each_entry(entry, &pdev->msi_list, list) {
- hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
- if (hwirq < 0) {
+ ret = mpic_msi_alloc_hwirqs(msi_mpic, 1);
+ if (ret < 0) {
pr_debug("u3msi: failed allocating hwirq\n");
- return hwirq;
+ return ret;
}
+ hwirq = ret;
virq = irq_create_mapping(msi_mpic->irqhost, hwirq);
if (virq == NO_IRQ) {
^ permalink raw reply related
* Re: Please pull from 'powerpc-next' branch
From: Kumar Gala @ 2008-04-23 22:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0804231749530.14182@blarg.am.freescale.net>
Here are four patches posted for you to pick up directly:
[POWERPC v7] 85xx: Add support for relocatble kernel (and booting at
non-zero)
[POWERPC v2] Port fixmap from x86 and use for kmap_atomic
[POWERPC] Cleanup asm-offset.c
[POWERPC] Clean up access to thread_info in assembly
- k
^ permalink raw reply
* Please pull from 'powerpc-next' branch
From: Kumar Gala @ 2008-04-23 22:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-next
to receive the following updates:
arch/powerpc/kernel/cpu_setup_6xx.S | 8
arch/ppc/8260_io/fcc_enet.c | 19
arch/ppc/8xx_io/enet.c | 23
arch/ppc/Kconfig | 82 --
arch/ppc/configs/ads8272_defconfig | 930 ----------------------------------
arch/ppc/configs/mpc86x_ads_defconfig | 633 -----------------------
arch/ppc/configs/mpc885ads_defconfig | 622 ----------------------
arch/ppc/platforms/Makefile | 4
arch/ppc/platforms/fads.h | 25
arch/ppc/platforms/mpc8272ads_setup.c | 367 -------------
arch/ppc/platforms/mpc885ads.h | 93 ---
arch/ppc/platforms/mpc885ads_setup.c | 476 -----------------
arch/ppc/platforms/pq2ads.c | 53 -
arch/ppc/platforms/pq2ads.h | 94 ---
arch/ppc/platforms/pq2ads_pd.h | 32 -
arch/ppc/syslib/m8260_setup.c | 6
arch/ppc/syslib/m82xx_pci.c | 38 -
arch/ppc/syslib/m8xx_setup.c | 10
include/asm-ppc/mpc8260.h | 4
include/asm-ppc/mpc8xx.h | 4
20 files changed, 9 insertions(+), 3514 deletions(-)
Kumar Gala (3):
[PPC] Remove mpc8272 ads board from arch/ppc
[PPC] Remove mpc885ads and mpc86x ads boards from arch/ppc
[POWERPC] ppc32: Fix errata for 603 CPUs
^ permalink raw reply
* [PATCH] Add Timur Tabi to the MAINTAINERS file
From: Timur Tabi @ 2008-04-23 22:45 UTC (permalink / raw)
To: linuxppc-dev, paulus; +Cc: Timur Tabi
Add Timur TAbi as the maintainer for the Freescale QE library, the Freescale
QE UART device driver, the Freescale SOC sound drivers, and the Crystal
Semiconductor CS4270 device driver.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch is for 2.6.26.
MAINTAINERS | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 90dcbbc..7a8bc0a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1104,6 +1104,12 @@ M: kernel@wantstofly.org
L: linux-usb@vger.kernel.org
S: Maintained
+CIRRUS LOGIC CS4270 SOUND DRIVER
+P: Timur Tabi
+M: timur@freescale.com
+L: alsa-devel@alsa-project.org
+S: Supported
+
CIRRUS LOGIC CS4280/CS461x SOUNDDRIVER
P: Cirrus Logic Corporation (kernel 2.2 driver)
M: Cirrus Logic Corporation, Thomas Woller <twoller@crystal.cirrus.com>
@@ -1626,6 +1632,12 @@ L: linuxppc-dev@ozlabs.org
L: netdev@vger.kernel.org
S: Maintained
+FREESCALE QUICC ENGINE LIBRARY
+P: Timur Tabi
+M: timur@freescale.com
+L: linuxppc-dev@ozlabs.org
+S: Supported
+
FREESCALE HIGHSPEED USB DEVICE DRIVER
P: Li Yang
M: leoli@freescale.com
@@ -1640,6 +1652,19 @@ L: netdev@vger.kernel.org
L: linuxppc-dev@ozlabs.org
S: Maintained
+FREESCALE QUICC ENGINE UCC UART DRIVER
+P: Timur Tabi
+M: timur@freescale.com
+L: linuxppc-dev@ozlabs.org
+S: Supported
+
+FREESCALE SOC SOUND DRIVERS
+P: Timur Tabi
+M: timur@freescale.com
+L: alsa-devel@alsa-project.org
+L: linuxppc-dev@ozlabs.org
+S: Supported
+
FILE LOCKING (flock() and fcntl()/lockf())
P: Matthew Wilcox
M: matthew@wil.cx
--
1.5.3
^ permalink raw reply related
* [PATCH 1/2 v2] powerpc: mpic_pasemi_msi: failed allocation unnoticed
From: Roel Kluin @ 2008-04-23 22:32 UTC (permalink / raw)
To: paulus, linuxppc-dev; +Cc: lkml
In-Reply-To: <480F6905.3070808@tiscali.nl>
also please add my signoff to
[PATCH 2/2 v2] mpic_u3msi: mpic_u3msi: failed allocation unnoticed
---
bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may return
signed, but hwirq is unsigned. A failed allocation remains unnoticed.
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/powerpc/sysdev/mpic_pasemi_msi.c b/arch/powerpc/sysdev/mpic_pasemi_msi.c
index 33cbfb2..68aff60 100644
--- a/arch/powerpc/sysdev/mpic_pasemi_msi.c
+++ b/arch/powerpc/sysdev/mpic_pasemi_msi.c
@@ -95,6 +95,7 @@ static int pasemi_msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
unsigned int virq;
struct msi_desc *entry;
struct msi_msg msg;
+ int ret;
pr_debug("pasemi_msi_setup_msi_irqs, pdev %p nvec %d type %d\n",
pdev, nvec, type);
@@ -108,8 +109,9 @@ static int pasemi_msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
* few MSIs for someone, but restrictions will apply to how the
* sources can be changed independently.
*/
- hwirq = mpic_msi_alloc_hwirqs(msi_mpic, ALLOC_CHUNK);
- if (hwirq < 0) {
+ ret = mpic_msi_alloc_hwirqs(msi_mpic, ALLOC_CHUNK);
+ hwirq = ret;
+ if (ret < 0) {
pr_debug("pasemi_msi: failed allocating hwirq\n");
return hwirq;
}
^ permalink raw reply related
* [PATCH 2/2 v2] mpic_u3msi: mpic_u3msi: failed allocation unnoticed
From: Roel Kluin @ 2008-04-23 22:25 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus, lkml
In-Reply-To: <df21920e067e73985f73047e2d8bcbda@kernel.crashing.org>
Segher Boessenkool wrote:
>> bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may
>> return -ENOMEM, but hwirq of type irq_hw_number_t which is unsigned.
>
>> list_for_each_entry(entry, &pdev->msi_list, list) {
>> hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
>> - if (hwirq < 0) {
>> + if (hwirq == -ENOMEM) {
>
> Please test for _all_ error values, instead.
>
> Segher
In this case -ENOMEM was _all_ error values, but I get your point.
---
bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may return
signed, but hwirq is unsigned. A failed allocation remains unnoticed.
diff --git a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
index 1d5a408..e790f39 100644
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -115,14 +115,16 @@ static int u3msi_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
struct msi_desc *entry;
struct msi_msg msg;
u64 addr;
+ int ret;
addr = find_ht_magic_addr(pdev);
msg.address_lo = addr & 0xFFFFFFFF;
msg.address_hi = addr >> 32;
list_for_each_entry(entry, &pdev->msi_list, list) {
- hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
- if (hwirq < 0) {
+ ret = mpic_msi_alloc_hwirqs(msi_mpic, 1);
+ hwirq = ret;
+ if (ret < 0) {
pr_debug("u3msi: failed allocating hwirq\n");
return hwirq;
}
^ permalink raw reply related
* Re: [PATCH 2/2] mpic_u3msi: mpic_u3msi: failed allocation unnoticed
From: Segher Boessenkool @ 2008-04-23 22:09 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, paulus, lkml
In-Reply-To: <480F8754.7000200@tiscali.nl>
> bitmap_find_free_region(), called by mpic_msi_alloc_hwirqs() may
> return -ENOMEM, but hwirq of type irq_hw_number_t which is unsigned.
> list_for_each_entry(entry, &pdev->msi_list, list) {
> hwirq = mpic_msi_alloc_hwirqs(msi_mpic, 1);
> - if (hwirq < 0) {
> + if (hwirq == -ENOMEM) {
> pr_debug("u3msi: failed allocating hwirq\n");
> return hwirq;
> }
Please test for _all_ error values, instead.
Segher
^ permalink raw reply
* RE: [PATCH 1/2] spi_mpc83xx: test below 0 on unsigned irq in mpc83xx_spi_probe()
From: Joakim Tjernlund @ 2008-04-23 21:55 UTC (permalink / raw)
To: 'Roel Kluin', galak, linuxppc-dev
Cc: spi-devel-general, dbrownell, 'lkml'
In-Reply-To: <480FA234.1000601@tiscali.nl>
> -----Original Message-----
> From: linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozlabs.org [mailto:linuxppc-dev-
> bounces+joakim.tjernlund=transmode.se@ozlabs.org] On Behalf Of Roel Kluin
> Sent: den 23 april 2008 22:55
> To: galak@kernel.crashing.org; linuxppc-dev@ozlabs.org
> Cc: spi-devel-general@lists.sourceforge.net; dbrownell@users.sourceforge.net; lkml
> Subject: [PATCH 1/2] spi_mpc83xx: test below 0 on unsigned irq in mpc83xx_spi_probe()
>
> mpc83xx_spi->irq is unsigned, so the test fails
>
> Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
hmm, I got a pretty large 83xx spi patch queued at dbrownell. I hope
that one can be applied first. Then you probably need to rediff this patch.
David, any progress on my patch?
Jocke
> ---
> diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
> index be15a62..033fd51 100644
> --- a/drivers/spi/spi_mpc83xx.c
> +++ b/drivers/spi/spi_mpc83xx.c
> @@ -454,12 +454,12 @@ static int __init mpc83xx_spi_probe(struct platform_device *dev)
> goto put_master;
> }
>
> - mpc83xx_spi->irq = platform_get_irq(dev, 0);
> -
> - if (mpc83xx_spi->irq < 0) {
> - ret = -ENXIO;
> + ret = platform_get_irq(dev, 0);
> + if (ret < 0)
> goto unmap_io;
> - }
> +
> + mpc83xx_spi->irq = ret;
> + ret = 0;
>
> /* Register for SPI Interrupt */
> ret = request_irq(mpc83xx_spi->irq, mpc83xx_spi_irq,
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Xilinx PowerPC
From: David H. Lynch Jr. @ 2008-04-23 21:43 UTC (permalink / raw)
To: Yoshio Kashiwagi; +Cc: linuxppc-embedded
In-Reply-To: <JM200804230904046.2598203@co-nss.co.jp>
Thanks alot.
On quick review this looks great. I will see if I can get it working for
me this weekend.
Yoshio Kashiwagi wrote:
> Hi,
>
> I am writing the Non-Xilinx XPS_LL_TEMAC driver.
> Checksum offloading is incomplete although NAPI and KGDBOE are supported.
> Basic operation is working on EDK9.2 and EDK10.1.
>
> Furthermore, although the simple Non-Interrupt version for u-boot is
> also written, it is not known where I should post.
>
> Best Regards,
>
> Yoshio Kashiwagi - Nissin Systems
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ 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