All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Peter Ryser <peter.ryser@xilinx.com>
Cc: Andrei Konovalov <akonovalov@mvista.com>,
	Grant Likely <grant@secretlab.ca>,
	Rick Moleres <Rick.Moleres@xilinx.com>,
	linuxppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: Re: [PATCH 00/10] Updated ML300 & ML403 patches
Date: Tue, 17 Jan 2006 10:30:28 -0700	[thread overview]
Message-ID: <43CD29B4.5070607@secretlab.ca> (raw)
In-Reply-To: <43CD240C.2050907@xilinx.com>

Peter Ryser wrote:
> 
>> I don't understand what you mean.  It sounds like your suggesting I do 
>> exactly opposite what you're arguing; hand modify one of the 
>> xparameters_*.h files.  Are you saying that edk can't generate Linux 
>> redefines for the ml403 at the moment? 
> 
> 
> Yes, it can. It looks they are not present in the xparameters_ml403.h 
> that you submitted as part of your patch. I'll send you the 
> automatically generated file in a seperate email.

okay good; I misunderstood what you were saying.  I pulled 
xparameters_ml403.h out of the ref design w/ the standalone bsp.  I just 
haven't bothered trying to generating the Linux bsp yet.

> 
>> I do *not* think I should replace the edk-generated 
>> xparameters_ml403.h with a hacked xparameters_ml300.h file.  I'd 
>> rather use the generated _ml403 file and change the infrastructure 
>> when the Linux redefines are ready. 
> 
> 
> See above. BTW, I'm not sure how familiar you are with the process in 
> EDK. Let me know if I can help you step through it.

okay, I'll ping you when I've got questions.

>> I understand that it's not *recommended*; I'm just saying it's not 
>> always *reality*  :p 
> 
> 
> Yeah, that's true for user projects. However, I hope that we can get the 
> default included in the Linux 2.6 kernel right.

yes, definately

> 
>> Yes; but I already said that I'll change the patch to use the Xilinx 
>> redefines.  My argument is simply that *if* changes are required, 
>> there is a way for the user to do it.  In the normal (recommended) 
>> case; nothing will need to be done.  (think Larry Wall's quote: "easy 
>> things easy; hard things possible)
>>
>> When it is needed; the fixups will be in xparameters.h; not 
>> xparameters_*.h; and they'll be for a specific port.  The fixups will 
>> only need to be done once per project (most likely). 
> 
> 
> I'm not sure that I follow your argument here.

I'll compose my answer in code; watch for patches.  :)

btw, once Linus closes the 2.6.16 merge window, it looks like we may be 
able to use the powerpc.git tree for tracking these changes.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 663-0761

  reply	other threads:[~2006-01-17 17:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-14  9:46 [PATCH 00/10] Updated ML300 & ML403 patches Grant Likely
     [not found] ` <43CC5453.3060702@xilinx.com>
2006-01-17  7:39   ` Grant Likely
2006-01-17 12:52     ` Peter Ryser
2006-01-17 15:41       ` Grant Likely
2006-01-17 17:06         ` Peter Ryser
2006-01-17 17:30           ` Grant Likely [this message]
2006-01-17 19:31       ` Grant Likely
2006-01-18 23:26         ` Peter Ryser
2006-01-19  5:11           ` Grant Likely
2006-01-19  0:27     ` David H. Lynch Jr.
2006-01-19  7:14       ` jeffer
2006-01-19  7:29         ` Peter Ryser
  -- strict thread matches above, loose matches on Subject: below --
2006-01-17 18:10 John Bonesio
2006-01-17 18:31 ` Grant Likely
     [not found] <mailman.134.1137523561.17753.linuxppc-embedded@ozlabs.org>
2006-01-17 20:12 ` T Ziomek
2006-01-17 20:19   ` Grant Likely
2006-01-17 20:23     ` T Ziomek
2006-01-17 20:37       ` Grant Likely
2006-01-27 12:01 Paula Saameño
2006-01-27 16:37 ` Grant Likely
2006-02-09  7:57 S. Egbert
2006-02-09 14:51 ` Grant Likely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43CD29B4.5070607@secretlab.ca \
    --to=grant.likely@secretlab.ca \
    --cc=Rick.Moleres@xilinx.com \
    --cc=akonovalov@mvista.com \
    --cc=grant@secretlab.ca \
    --cc=linuxppc-embedded@ozlabs.org \
    --cc=peter.ryser@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.