Skip to contentSkip to conversation

x86: minor PAT adaptations

PATCH Applied Andreas Herrmann 2 participants 4 messages Jun 10, 2008 – Jun 12, 2008

lore
Share & tools
lore
#0 lore raw

cover x86: minor PAT adaptations

Following some patches to slightly adapt the PAT code.

patch 1 - enable PAT for all AMD CPUs that have the PAT feature flag set patch 2 - fix up paranoia check in pat_init and fix the logic to
enable/disable PAT (IMHO the current code enables PAT on all Transmeta and Centaur CPUs even if no PAT feature flag is set) (I admit I should have changed the sequence of patches 1 and 2.)
patch 3 - fix some checkpatch errors
patch 4 - variable renaming
patch 5 - slightly changing the code that is doing the intersection of
pat_type and mtrr_type to be more readable (from my point of view)

Patches are against x86/pat (as of version v2.6.26-rc3-6-g46dd98a).

Please apply (at least patches 1 and 2).
Patches 3-5 are more a cleanup kind of thing.

Thanks.

Andreas

Applied
#1 lore raw
Quoted 9 lines · Andreas Herrmann

Following some patches to slightly adapt the PAT code.

patch 1 - enable PAT for all AMD CPUs that have the PAT feature flag set patch 2 - fix up paranoia check in pat_init and fix the logic to
enable/disable PAT (IMHO the current code enables PAT on all Transmeta and Centaur CPUs even if no PAT feature flag is set) (I admit I should have changed the sequence of patches 1 and 2.)
patch 3 - fix some checkpatch errors
patch 4 - variable renaming

applied to tip/x86/pat, thanks Andreas. (i presume you'll send a followup patch for the suggestions that came up in the discussion)

Quoted 4 lines

patch 5 - slightly changing the code that is doing the intersection of
pat_type and mtrr_type to be more readable (from my point of view)

Patches are against x86/pat (as of version v2.6.26-rc3-6-g46dd98a).

#5 makes sense too, but it didnt apply cleanly:

Applying patch patches/pat-x86-pat-make-pat-x-mtrr-type-more-readable.patch patching file arch/x86/mm/pat.c
Hunk #1 FAILED at 185.
1 out of 1 hunk FAILED -- rejects in file arch/x86/mm/pat.c

(it didnt apply neither against tip/x86/pat or tip/master, nor against linus/master. I guess it's some mixup somewhere.)

Ingo

#2 lore raw
Quoted 13 lines · Ingo Molnar
Quoted 9 lines · Andreas Herrmann

Following some patches to slightly adapt the PAT code.

patch 1 - enable PAT for all AMD CPUs that have the PAT feature flag set patch 2 - fix up paranoia check in pat_init and fix the logic to
enable/disable PAT (IMHO the current code enables PAT on all Transmeta and Centaur CPUs even if no PAT feature flag is set) (I admit I should have changed the sequence of patches 1 and 2.)
patch 3 - fix some checkpatch errors
patch 4 - variable renaming

Quoted 2 lines

applied to tip/x86/pat, thanks Andreas. (i presume you'll send a followup patch for the suggestions that came up in the discussion)

Yes, I'll do.

Quoted 6 lines
Quoted 4 lines

patch 5 - slightly changing the code that is doing the intersection of
pat_type and mtrr_type to be more readable (from my point of view)

Patches are against x86/pat (as of version v2.6.26-rc3-6-g46dd98a).

#5 makes sense too, but it didnt apply cleanly:

That's odd. I've double checked it by doing a fresh

$ git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
$ git remote update
$ git checkout tip/x86/pat

and applying patches 1-5 in sequence without problems. (Patches were taken from emails that arrived via my linux-kernel subscription.) Probably your tip/x86/pat is not at v2.6.26-rc3-6-g46dd98a?

When trying to apply the patches to tip/master I get rejects for patches 3 and 5.

Hence I think creating my patches against a feature branch was not a good idea.

Quoted 8 lines

Applying patch patches/pat-x86-pat-make-pat-x-mtrr-type-more-readable.patch patching file arch/x86/mm/pat.c
Hunk #1 FAILED at 185.
1 out of 1 hunk FAILED -- rejects in file arch/x86/mm/pat.c

(it didnt apply neither against tip/x86/pat or tip/master, nor against linus/master. I guess it's some mixup somewhere.)

Ok, it's commit 282c454cd3a7041f59a37112bb2f82263bc38f6c which was not contained in the tip/x86/pat branch. This means I have to adapt patch 5.

Finally a dumb question. What patches do you prefer? Patches against feature branches (say tip/x86/foo), against tip/master or against tip/auto-latest as described in your tip.git-Readme?

Thanks,

Andreas

#3 lore raw
Quoted 10 lines · Andreas Herrmann
Quoted 7 lines
Quoted 5 lines

patch 5 - slightly changing the code that is doing the intersection of
pat_type and mtrr_type to be more readable (from my point of view)

Patches are against x86/pat (as of version
v2.6.26-rc3-6-g46dd98a).

#5 makes sense too, but it didnt apply cleanly:

That's odd. I've double checked it by doing a fresh

Quoted 8 lines
$ git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
$ git remote update
$ git checkout tip/x86/pat

and applying patches 1-5 in sequence without problems. (Patches were taken from emails that arrived via my linux-kernel subscription.) Probably your tip/x86/pat is not at v2.6.26-rc3-6-g46dd98a?

it was there - but some other commit from upstream interfered.

Quoted 5 lines

When trying to apply the patches to tip/master I get rejects for patches 3 and 5.

Hence I think creating my patches against a feature branch was not a good idea.

it was a good idea - as that the final destination where the PAT patches end up.

current tip/x86/pat head is:

tip/x86/pat 499f8f8: x86: rename pat_wc_enabled to pat_enabled

Quoted 8 lines
Quoted 4 lines

1 out of 1 hunk FAILED -- rejects in file arch/x86/mm/pat.c

(it didnt apply neither against tip/x86/pat or tip/master, nor against linus/master. I guess it's some mixup somewhere.)

Ok, it's commit 282c454cd3a7041f59a37112bb2f82263bc38f6c which was not contained in the tip/x86/pat branch. This means I have to adapt patch 5.

indeed. I cherry-picked this commit meanwhile into x86/pat.

Quoted 3 lines

Finally a dumb question. What patches do you prefer? Patches against feature branches (say tip/x86/foo), against tip/master or against tip/auto-latest as described in your tip.git-Readme?

either is fine - but if you make specific topic updates it's best to do them against the topic branch and we'll integrate them all together. If in doubt, using tip/master doesnt hurt.

usually i do this: i update x86/pat, then i switch to 'master' and check whether it all merges cleanly via 'git-merge x86/pat'.

when you switch to a topic branch, you might also want to update to the latest linus tree via 'git-merge linus/master', to pick up all other fixes as well. The topic branches always merge cleanly to linus-latest. (we automate that - the x86/pat topic branch is not stale as its -rc3 base would suggest, there simply was no need to merge it to Linus-latest up to now)

Ingo