Hi Paul,
Can you please apply the following patch to the ameslab ppc64
tree, and/or roll it upwards to the marclello 2.6 tree?
This path is 100% pure cleanup; no functional changes.
I got irritated when I was given a -1 that was cast to an unsigned
int that was then cast to a signed (64-bit) long, and so I received
a value of 4 billion instead of -1. This patch fixes this insanity.
Different files were treating this return code as being signed
or unsigned, 32-bit or 64-bit. The 'real' return code is always
a signed 32-bit quantity, so this patch just makes the usage
consistent across the board.
Signed-off-by: Linas Vepstas <[email protected]>
--linas
Linas,
> Can you please apply the following patch to the ameslab ppc64
> tree, and/or roll it upwards to the marclello 2.6 tree?
> This path is 100% pure cleanup; no functional changes.
>
> I got irritated when I was given a -1 that was cast to an unsigned
> int that was then cast to a signed (64-bit) long, and so I received
> a value of 4 billion instead of -1. This patch fixes this insanity.
>
> Different files were treating this return code as being signed
> or unsigned, 32-bit or 64-bit. The 'real' return code is always
> a signed 32-bit quantity, so this patch just makes the usage
> consistent across the board.
I beat you to the punch on this one, I'm afraid. :) I changed
rtas_call to return an int in the prom cleanup patch I sent to Andrew
last week. You did spot a few places that I missed though, so I'll
send Andrew a patch to fix those up shortly.
Regards,
Paul.
On Wed, Jun 30, 2004 at 09:33:16PM +1000, Paul Mackerras wrote:
> Linas,
>
> > Can you please apply the following patch to the ameslab ppc64
> > tree, and/or roll it upwards to the marclello 2.6 tree?
> > This path is 100% pure cleanup; no functional changes.
> >
> > I got irritated when I was given a -1 that was cast to an unsigned
> > int that was then cast to a signed (64-bit) long, and so I received
> > a value of 4 billion instead of -1. This patch fixes this insanity.
> >
> > Different files were treating this return code as being signed
> > or unsigned, 32-bit or 64-bit. The 'real' return code is always
> > a signed 32-bit quantity, so this patch just makes the usage
> > consistent across the board.
>
> I beat you to the punch on this one, I'm afraid. :) I changed
> rtas_call to return an int in the prom cleanup patch I sent to Andrew
> last week. You did spot a few places that I missed though, so I'll
> send Andrew a patch to fix those up shortly.
Well, your patch is not in the ameslab tree :( at least as of friday
night. I'm working off of ameslab, is there a different tree I should
follow at this time?
--linas
Linas,
> Well, your patch is not in the ameslab tree :( at least as of friday
> night. I'm working off of ameslab, is there a different tree I should
> follow at this time?
We should all be working from the upstream kernel.org tree as much as
possible. In the past we have used ameslab as a repository for the
ppc64 changes that were ready to go but which hadn't got upstream yet.
Now that our patches are going into the upstream BK repository quickly
and reliably there is much less need for ameslab.
If you have something you're working on that isn't ready to go
upstream just yet, post the patch periodically to linuxppc64-dev
and/or linux-kernel. If other developers want to try your stuff
before it's quite ready they should be applying your patches to their
local trees.
Paul.