Hi Bin,
On Tue, 28 Apr 2020 at 08:34, Bin Meng <bmeng...@gmail.com> wrote:
>
> Hi Simon,
>
> On Tue, Apr 28, 2020 at 10:19 PM Simon Glass <s...@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Mon, 27 Apr 2020 at 21:25, Bin Meng <bmeng...@gmail.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Tue, Apr 28, 2020 at 11:06 AM Simon Glass <s...@chromium.org> wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Mon, 27 Apr 2020 at 20:42, Bin Meng <bmeng...@gmail.com> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Tue, Apr 28, 2020 at 10:29 AM Simon Glass <s...@chromium.org>
> > > > > wrote:
> > > > > >
> > > > > > Hi Bin,
> > > > > >
> > > > > > On Mon, 27 Apr 2020 at 19:30, Bin Meng <bmeng...@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Tue, Apr 28, 2020 at 1:02 AM Simon Glass <s...@chromium.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Move the alignment code into acpi_setup_base_tables() so that
> > > > > > > > test and
> > > > > > > > production code are in alignment.
> > > > > > > >
> > > > > > > > This brings x86/master into line with patch series v8.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass <s...@chromium.org>
> > > > > > > > ---
> > > > > > > >
> > > > > > > > arch/x86/lib/acpi_table.c | 5 -----
> > > > > > > > lib/acpi/acpi_table.c | 7 ++++++-
> > > > > > > > 2 files changed, 6 insertions(+), 6 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/x86/lib/acpi_table.c
> > > > > > > > b/arch/x86/lib/acpi_table.c
> > > > > > > > index 600bde2f5f..13f1409de8 100644
> > > > > > > > --- a/arch/x86/lib/acpi_table.c
> > > > > > > > +++ b/arch/x86/lib/acpi_table.c
> > > > > > > > @@ -375,11 +375,6 @@ ulong write_acpi_tables(ulong start_addr)
> > > > > > > > debug("ACPI: Writing ACPI tables at %lx\n", start_addr);
> > > > > > > >
> > > > > > > > acpi_setup_base_tables(ctx, start);
> > > > > > > > - /*
> > > > > > > > - * Per ACPI spec, the FACS table address must be
> > > > > > > > aligned to a 64 byte
> > > > > > > > - * boundary (Windows checks this, but Linux does not).
> > > > > > > > - */
> > > > > > > > - acpi_align64(ctx);
> > > > > > > >
> > > > > > > > debug("ACPI: * FACS\n");
> > > > > > > > facs = ctx->current;
> > > > > > > > diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
> > > > > > > > index 5abf1cad50..1c253af3bf 100644
> > > > > > > > --- a/lib/acpi/acpi_table.c
> > > > > > > > +++ b/lib/acpi/acpi_table.c
> > > > > > > > @@ -145,7 +145,7 @@ int acpi_add_table(struct acpi_ctx *ctx,
> > > > > > > > void *table)
> > > > > > > > }
> > > > > > > >
> > > > > > > > if (i >= entries_num) {
> > > > > > > > - debug("ACPI: Error: too many tables\n");
> > > > > > > > + log_err("ACPI: Error: too many tables\n");
> > > > > > > > return -E2BIG;
> > > > > > > > }
> > > > > > > >
> > > > > > > > @@ -256,4 +256,9 @@ void acpi_setup_base_tables(struct acpi_ctx
> > > > > > > > *ctx, void *start)
> > > > > > > > acpi_write_rsdp(ctx->rsdp, ctx->rsdt, ctx->xsdt);
> > > > > > > > acpi_write_rsdt(ctx->rsdt);
> > > > > > > > acpi_write_xsdt(ctx->xsdt);
> > > > > > > > + /*
> > > > > > > > + * Per ACPI spec, the FACS table address must be
> > > > > > > > aligned to a 64 byte
> > > > > > > > + * boundary (Windows checks this, but Linux does not).
> > > > > > > > + */
> > > > > > > > + acpi_align64(ctx);
> > > > > > > > }
> > > > > > > > --
> > > > > > >
> > > > > > > Could you please point out which commit in u-boot-x86/master
> > > > > > > should
> > > > > > > squash in this patch to fix the build error on sandbox?
> > > > > >
> > > > > > It might be easier to pick up v8 in that case. I think there are
> > > > > > three
> > > > > > patches that need to change because of conflicts caused by the first
> > > > > > one.
> > > > > >
> > > > > > So can you pick up the v8 patches? Also you do need to rebase on
> > > > > > master because of the str_to_upper patches.
> > > > >
> > > > > But v8 is a complete new series for part B? I think we'd better re-tag
> > > > > v8 as v1. It's quite confusing.
> > > >
> > > > No I mean the part A series. Let's get that applied and then we will
> > > > be in a brave new world.
> > >
> > > Is the v8 this one?
> > > http://patchwork.ozlabs.org/user/todo/uboot/?series=172777
> >
> > No it is this one:
> >
> > http://patchwork.ozlabs.org/project/uboot/list/?series=172776
> >
> > >
> > > The part A series are already applied, but it has a build error as I
> > > mentioned.
> >
> > Right, but the options are to do a fixup patch or to pick up the v8
> > series instead. Unfortunately there are merge conflicts in patches so
> > if you just pick up one patch it won't apply cleanly.
> >
>
> But we still need maintain bisectablity right? To do that we need a
> fix patch that can be squashed into the u-boot-x86/master. Picking up
> the v8 series does not fix the bisectiablity I think.
But my suggestion is to pick up the v8 patch *and drop what you
currently have in x86/master*. Otherwise, as you say, bisect might not
work.
I should have objected at the time to Andy refactoring patch, but I
wasn't sure when my stuff would land so it did not seem reasonable to
do so.
Regards,
SImon
