[PATCH v4 01/45] x86: Return mtrr_add_request() to its old purpose

[Simon Glass]

Hi Bin,

On Wed, 12 Jul 2023 at 08:02, Bin Meng <bmeng.cn at gmail.com> wrote:
>
> Hi Simon,
>
> On Mon, Jun 19, 2023 at 8:01 PM Simon Glass <sjg at chromium.org> wrote:
> >
> > This function used to be for adding a list of requests to be actioned on
> > relocation. Revert it back to this purpose, to avoid problems with boards
> > which need control of their MTRRs (i.e. those which don't use FSP).
> >
> > The mtrr_set_next_var() function is available when the next free
> > variable-MTRR must be set, so this can be used instead.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > Fixes: 3bcd6cf89ef ("x86: mtrr: Skip MSRs that were already programmed..")
> > Fixes: 596bd0589ad ("x86: mtrr: Do not clear the unused ones..")
> > ---
> >
> > Changes in v4:
> > - Bring in dropped mtrr_add_request() request patch
> >
>
> As discussed previously in
> https://patchwork.ozlabs.org/project/uboot/patch/20230504225101.2366414-13-sjg@chromium.org/
>
> this patch will cause regressions. We should investigate another way
> to improve the MTRR APIs.

The fix for the regressions is to use mtrr_set_next_var() for boards
which don't want to change what is already there. The problem for
Chromebooks (with newer FSPs) is that they want to set up the MTRRs
from scratch, which is actually what this API was originally for. When
you changed it, I didn't realise the problem right away. But at
present two Chromebooks don't boot due to this bug.

>
> Regards,
> Bin

Regards,
SImon