> -----Original Message----- > From: Linda Knippers [mailto:linda.knippers@xxxxxxx] > Sent: Tuesday, June 13, 2017 6:42 AM > To: Rafael J. Wysocki <rafael@xxxxxxxxxx> > Cc: Moore, Robert <robert.moore@xxxxxxxxx>; Zheng, Lv > <lv.zheng@xxxxxxxxx>; Wysocki, Rafael J <rafael.j.wysocki@xxxxxxxxx>; > Rafael J . Wysocki <rjw@xxxxxxxxxxxxx>; Brown, Len > <len.brown@xxxxxxxxx>; Box, David E <david.e.box@xxxxxxxxx>; Lv Zheng > <zetalog@xxxxxxxxx>; ACPI Devel Maling List <linux-acpi@xxxxxxxxxxxxxxx> > Subject: Re: [PATCH 01/15] ACPICA: Disassembler: Enhance resource > descriptor detection > > > > On 6/5/2017 4:55 PM, Rafael J. Wysocki wrote: > > On Mon, Jun 5, 2017 at 10:51 PM, Linda Knippers > <linda.knippers@xxxxxxx> wrote: > >> On 6/5/2017 4:42 PM, Rafael J. Wysocki wrote: > >> <snip> > >> > >>>> I talked to our FW team and we do generate checksums and not a zero > >>>> for at least some of the AML. Please revert this change until you > >>>> can also validate a checksum. Or shall I post a patch to remove > >>>> the check? > >>> > >>> > >>> I'll skip this patch, no need to do anything else. Thanks for your > >>> report! > >> > >> > >> Thanks. This patch is already in as of 4.12rc1 and not part of the > >> most recent ACPICA drop. > > > > Ah, OK. > > > > I should have checked I guess. :-) > > > > Anyway, I'll revert it, then. > > Hi Rafael, Is this still in the queue to be reverted? > I see it's still in rc5 but it really needs to go before 4.12 is > released. > We've been broken since rc1. > > Thanks, > > -- ljk > > > >>> Bob, can you revert this upstream, please? It looks like the > >>> assumption it is based on doesn't hold. > >> [Moore, Robert] It is on our list of things to look at, now that acpi 6.2 is released. This has been a rather odd problem that we have been trying to fix for some time now; so we will of course need to come up with a permanent fix. > >> Bob, I'm happy to test something if there is a new patch that looks > >> for zero or a valid checksum. TBH, I'm not 100% certain that our > >> checksums are correct because nothing has ever tried to verify them. > > > > Well, that's part of the problem here I guess. If they have never > > been tested, they cannot be trusted. > > > > Still, the commit in question clearly assumed that value to always be > > 0 and it clearly is not the case here. > > > > Thanks, > > Rafael > > ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
