All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Georgi <pgeorgi at google.com>
To: devel@acpica.org
Subject: [Devel] Field Offset constraints
Date: Wed, 03 Apr 2019 09:14:17 +0200	[thread overview]
Message-ID: <CAE-gjdWGiG2s31qRr4yZv2ZUs1BNdE5af1eBVmCiuvRSZPhbqA@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

Hi everybody,

at coreboot[1] we use iasl to compile static ASL for various hardware.
Recent versions of iasl emit a notice for redundant Offset statements in
Fields, apparently with the expectation that they shouldn't exist.

This poses a problem for us since we're sometimes using Offset as a guard,
making sure that we didn't inadvertedly shifted fields around (too much),
with the expectation that these were redundant in the "good" case.

Since that operator wasn't really suited for that purpose anyway, and now
throws warnings (which we try to avoid in our builds), are there plans to
add some keyword for compile time constraints checks, or any objections to
having such a feature (should one of us decide to implement it)?

Maybe something like

Field (NAME, ByteAcc, Lock, Preserve)
{
    Item(FIE1, 0, 0, 8)
    Item(FIE2, 1, 0, 8)
    Offset(0x10)
    Item(FIE3, 0x10, 0, 8)
}

in which Item(Name, Byte, Bit, Length) would compile to "Name, Length,"
inside a field after ensuring that the byte and bit offsets match the
current location.

Thoughts?

Thanks,
Patrick Georgi

[1] https://www.coreboot.org/
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1833 bytes --]

             reply	other threads:[~2019-04-03  7:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03  7:14 Patrick Georgi [this message]
2019-04-03 17:38 [Devel] Field Offset constraints Moore, Robert
2019-04-03 18:07 Patrick Georgi
2019-04-03 19:07 Moore, Robert
2019-04-03 21:26 Schmauss, Erik
2019-04-03 21:51 Patrick Georgi
2019-04-04 20:12 Schmauss, Erik
2019-04-04 20:35 Patrick Georgi
2019-04-05 19:16 Moore, Robert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAE-gjdWGiG2s31qRr4yZv2ZUs1BNdE5af1eBVmCiuvRSZPhbqA@mail.gmail.com \
    --to=devel@acpica.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.