thoughts and questions on 8xx patches
Robert P. J. Day
rpjday at mindspring.com
Tue Sep 21 20:59:22 EST 2004
On Tue, 21 Sep 2004, Wolfgang Denk wrote:
> In message <Pine.LNX.4.60.0409210605090.9033 at dell.enoriver.com> you wrote:
>> rather than get into more detailed discussion on microcode patches,
>> here's a (partial) patch that represents what i'd really, really,
>> *really* like to see.
>> +config I2C_SPI_PATCH
>> + bool "I2C/SPI relocation patch"
>> +config I2C_SPI_SMC1_PATCH
>> + bool "I2C/SPI/SMC1 relocation patch"
> Why? As far as I understand the I2C/SPI patch has been obsolteted by
> the I2C/SPI/SMC1 patch. So only the latter is needed.
what i was showing was just an example, it didn't need to represent
*exactly* the set of choices that would be in the final menu. if the
above is the case, that's fine. but there's still then, at the very
least, the list of possible patches that are in *your* 2.4 kernel
source tree. i wasn't submitting a final list of patches, just a
suggested *format* for selection, that's all. don't get ahead of me
>> it adds a simple choice entry to the MPC8xx menu, from which you can
>> select the appropriate patch -- it's as easy as that.
> No, it is not that easy.
yes, it is.
>> note that that's not the entire list of possible patches -- i have
>> the list from wolfgang's tree that distinguishes between 850 and 8xx
>> (non-850) patches in some cases so the list is actually longer than
>> this one. but, really, selecting a patch should be this easy -- pick
> Indeed. And AFAICT there is no way to get the processor version from
> any other CONFIG option that the board name, so this would become an
> awfully long list.
in what way? the denx 2.4 kernel source tree defines all of 5
patches. i don't see that as an overly long list, and given that the
default selection would be "None", people who don't even know what a
patch is would never have to make that decision.
at the moment, your denx tree supports a number of patches that
require users to edit source files and manually define constants. in
what way is this a better idea than picking from a drop down choice
(and i never suggested that the config process automatically detect
the 850 or non-850-ness of the processor. that would be a manual
selection by the user, just as it is in your source tree at the
moment. and it's *still* a short list.)
>> one and check the box. and this makes it trivial to add or delete
>> patches appropriately as time goes by.
>> obviously, this menu requires changes in the underlying micropatch.c
>> file (which aren't shown here), but i'm curious about whether this
>> approach would overly offend anyone.
> This has been discussed many times before.
yes, it has, and the conversation has typically gone something like
me: ... general whine about something i don't like that could be
reply: "yes, that's a problem, you're right, so stop whining and
submit a patch."
me: "um ... ok, what about a patch like this?"
and around and around we go ...
More information about the Linuxppc-dev