Messages in this thread | | | Subject | Re: [PATCH v2 3/4] mtrr, x86: Clean up mtrr_type_lookup() | From | Toshi Kani <> | Date | Fri, 13 Mar 2015 07:53:11 -0600 |
| |
On Fri, 2015-03-13 at 12:37 +0000, Ingo Molnar wrote: > * Toshi Kani <toshi.kani@hp.com> wrote: : > > + /* Look in fixed ranges. Just return the type as per start */ > > + if (mtrr_state.have_fixed && (start < 0x100000)) { > > + int idx; > > + > > + if (start < 0x80000) { > > + idx = 0; > > + idx += (start >> 16); > > + return mtrr_state.fixed_ranges[idx]; > > + } else if (start < 0xC0000) { > > + idx = 1 * 8; > > + idx += ((start - 0x80000) >> 14); > > + return mtrr_state.fixed_ranges[idx]; > > + } else { > > + idx = 3 * 8; > > + idx += ((start - 0xC0000) >> 12); > > + return mtrr_state.fixed_ranges[idx]; > > + } > > + } > > So why not put this into a separate helper function - named > mtrr_type_lookup_fixed()? It has little relation to variable ranges.
Sounds good. I will update as suggested.
> > + > > + /* > > + * Look in variable ranges > > + * Look of multiple ranges matching this address and pick type > > + * as per MTRR precedence > > + */ > > + if (!(mtrr_state.enabled & 2)) > > + return mtrr_state.def_type; > > + > > type = __mtrr_type_lookup(start, end, &partial_end, &repeat); > > And this then should be named mtrr_type_lookup_variable() or so?
Will do as well.
I will send out a new version today since I won't be able to update the patchset next week.
Thanks, -Toshi
| |