1) Add compiler support for IVRS.
2) Update disassembler support for IVRS.
3) Add a new utility, UtIsIdInteger to determine if a HID/CID is
an integer or a string.
Each type of iASL error is associate with a 4-digit error ID. This is
done in order to ignore or expect entire classes of remarks/warnings/errors.
However, there is a desire to expect these compiler messages on a
line-based granularity. This allows finer-grained testing of iASL
compiler messages.
The following example illustrates the use of this feature:
DefinitionBlock ("", "DSDT", 2, "", "", 0x1)
{
Device (ABCD)
{
}
}
Compiling the above code will result in a warning like this:
dsdt.asl 3: Device (ABCD)
Warning 3141 - ^ Missing dependency (Device object requires a _HID or _ADR in same scope)
The following tells iASL to expect error code 3141 on line 3:
DefinitionBlock ("", "DSDT", 2, "", "", 0x1)
{
Device (ABCD) __EXPECT__(3141)
{
}
}
Compiling this will expect the warning to be raised and result in a
successful compilation:
ASL Input: dsdt.asl - 97 bytes 1 keywords 9 source lines
AML Output: dsdt.aml - 43 bytes 0 opcodes 1 named objects
Compilation successful. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
However, if the warning does not appear, compilation will result in
an error. This code snippet does not exhibit warning 3141 but still
expects this error code on line 3:
DefinitionBlock ("", "DSDT", 2, "", "", 0x1)
{
Device (ABCD) __EXPECT__(3141)
{
Name (_ADR, 0x12345678)
}
}
This code will result in the following compiler error because error
code 3141 was not generated during compilation.
dsdt.asl 3: Device (ABCD) __EXPECT__(3141)
Error 6149 - ^ Expected remark, warning, or error did not occur. Message ID: (3141)
ASL Input: dsdt.asl - 129 bytes 2 keywords 10 source lines
Compilation failed. 1 Errors, 0 Warnings, 0 Remarks
Telling iASL about expected errors inline as a part of ASL code
allows us to contain all expected error information as a part of the
ASL codebase rather than requiring -vx flags to be placed inside of
makefiles.
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
XfGetParentMethod is used in namespace cross reference and method
analysis so this function should be a part of a aslutils.c rather
than aslxref.c. This function is similar to UtGetParentMethodNode but
returns an ACPI_PARSE_OBJECT so rename it to UtGetParentMethodOp for
clarity.
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
This function returns a namespace node so renaming it as
UtGetParentMethodNode adds more clarity to the usage of this
function.
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
Macro was not being used across all "printf-like" functions.
Also, cleanup all calls to such functions now that they are
analyzed by the compiler (gcc). Both in 32-bit mode and 64-bit
mode.
Performing parse tree analysis on all definition blocks
simultaneously results in more effective namespace cross-reference.
This enables iASL static analysis to determine unresolved external
declarations and namespace collisions during compilation.
In order to take advantage of this, compile definition blocks
with the following command:
iasl dsdt.asl ssdt1.asl ssdt2.asl ...
*** Changes related to multiple files:
Keep track of all files in a global list that is persistent
throughout compilation of both files. This is done in order to
compile multiple ASL files in the same namespace and parse tree.
This also resulted in moving the file handle assignment for the -vi
option during file initialization rather than commandline processing.
As each definition block is parsed, it is connected as a sibling node
to the previous definiton block.
*** Changes related to iASL error reporting:
Also, more error messages were added by replacing the fprintf to
stderr with AslError. By doing so, an error can be logged properly
and AML output files will be cleaned if there is a compiler error.
Adds the ability to print the correct source line by logging the .src
filename in each error node. This is necessary for errors that point
to an include file.
New iASL error: emitting an error when compiling duplicate files.
Ignore max error count when compiling with -f because
compilation needs to continue.
Fix parser error path to correctly abort compilation rather
than trying to proceed with more compilation.
*** Changes related to codegen behavior:
Seek to the end of the AML output file after codegen in case multiple
definition blocks need to be encoded in the same AML file. This makes
other parts of the codebase a little more convinent since it doesn't
have to seek to the correct place in the AML.
*** Misc changes:
Remove a call to ACPI_FREE. We should never be calling ACPI_FREE in
memory allocated in caches.
Display compilation summaries for multiple input files. Files that
have parser errors are reported as having parser errors. The summary
is based on the global file list.
Encapsulate global variables in global file nodes used for summary
reporting.
Final cleanup functions for iASL has been consolidated to the main()
function for simplicity.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Forward references have never been allowed within control methods,
and now there are illegal from module-level code (This makes
ACPICA compatible with "other" acpi implementations).
Both types of fwd refs now generate an error message (this is
also a new addition to iASL).
If a name alredy exists in scope error occurs, an error message pointing to
the duplicate declaration is helpful because it informs users on the error
locations of conflicting declarations. This change adds support for
AslDualParseOpError, a function that can allow the error message like below.
DSDT.iiii 1692: Device(PEG2) {
Error 6074 - ^ Name already exists in scope (PEG2)
Original name creation/declaration below:
DSDT.iiii 93: External(\_SB.PCI0.PEG2, DeviceObj)
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Improve adherence to ACPI spec for implicit and explicit conversions
Adds octal support for constants in ASL code
Adds integer overflow errors for constants during ASL compilation
Eliminates most of the existing complex flags parameters
Simplify support for implicit/explicit runtime conversions
Adds one new file, utilities/utstrsuppt.c
The -vx [messageId] option, where the x stands for EXpect, allows the
compiler to expect that the compilation will result in an ASL exception
with a particular messageId. If this error is not raised. The
compilation will result in an error. This will help create a whole new
class of compilation tests in ASLTS.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Fix some confusion between "parse op" and "parse node".
Adds a new file, aslparseop.c
Consistently use "parse op" to describe the elements of the
parse tree data structure.
An "Op" is the primary data structure element, even though
it sounds odd.
PinGroupConfig() is analogous to PinGroupFunction() but instead of mode
(muxing), it is used to apply specific fine-grained configuration to a
set of referenced pins.
The format of this new resource is:
PinGroupConfig (Shared/Exclusive, PinConfigType, PinConfigValue,
ResourceSource, ResourceSourceIndex, ResourceSourceLabel,
ResourceUsage, DescriptorName, VendorData)
The PinConfigType/PinConfigValue are the same used by PinConfig()
resource.
Here also the combination of ResourceSource and ResourceSourceLabel is
used to specify the PinGroup() this resource refers to.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
PinGroupFunction() is a new resource introduced with ACPI 6.2. It is
used with PinGroup() to configure specific mode for a set of pins
exposed by a GPIO controller.
The format of the resource is:
PinGroupFunction (Shared/Exclusive, FunctionNumber, ResourceSource,
ResourceSourceIndex, ResourceSourceLabel,
ResourceUsage, DescriptorName, VendorData)
The ResourceSource and ResourceSourceLabel fields are used to specify
the PinGroup() resource referenced by PinGroupFunction().
Device (GPIO)
{
Name (_CRS, ResourceTemplate () {
PinGroup ("group1") {2, 3}
PinGroup ("group2") {4, 5}
...
})
}
Device (I2C)
{
Name (_CRS, ResourceTemplate () {
PinGroupFunction (Exclusive, 6, "^GPIO", 0, "mygroup2")
})
}
In the above example the PinGroupFunction() references the second
PinGroup() resource (using label "mygroup2" and configures pins 4 and 5
into mode 6.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI 6.2 introduced a new resource that is used to declare set of pins
belonging to a GPIO controller. This resource is referenced by new
PinGroupFunction() and PinGroupConfig() resources using ResourceSource
and ResourceLabel fields.
The PinGroup() resource looks like this:
PinGroup (ResourceLabel, ResourceUsage, DescriptorName,
VendorData) {Pin List}
This resource should be listed in _CRS under the GPIO/pincontroller
device providing these pins.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI 6.2 introduced a new resource that is used to specify fine-grained
configuration of a pin or set of pins used by a device. The ASL syntax of
this new resource looks like:
PinConfig (Shared/Exclusive, PinConfigType, PinConfigValue,
ResourceSource, ResourceSourceIndex, ResourceUsage,
DescriptorName, VendorData) {Pin List}
PinConfigType is an integer with following accepted values:
0x00 (Default) - No configuration is applied to the pin
0x01 (Bias Pull-up) - Pin is pulled up using certain size resistor
0x02 (Bias Pull-down) - Pin is pulled down using certain size resistor
0x03 (Bias Default) - Set to default biasing
0x04 (Bias Disable) - All bias settings will be disabled
0x05 (Bias High Impedance) - Configure the pin as HiZ
0x06 (Bias Bus Hold) - Configure the pin in a weak latch state where
it drives the last value on a tristate bus
0x07 (Drive Open Drain) - Configure the pin into open drain state
0x08 (Drive Open Source) - Configure the pin into open source state
0x09 (Drive Push Pull) - Configure the pin into push-pull state
0x0a (Drive Strength) - How much the pin can supply current
0x0b (Slew Rate) - Configure slew rate of the pin
0x0c (Input Debounce) - Enable input debouncer for the pin
0x0d (Input Schmitt Trigger) - Enable schmitt trigger for the pin
0x0e - 0x7f - Reserved
0x80 - 0xff - Vendor defined types
The PinConfigValue depends on the type and is expressed as units
suitable for that type (for example bias uses Ohms).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI 6.2 introduced a new resource that is used to describe how certain
pins are muxed for a device. The ASL syntax of this new resource looks
like below:
PinFunction(Shared, PinConfig, FunctionNumber, ResourceSource,
ResourceSourceIndex, ResourceUsage, DescriptorName,
VendorData) {Pin List}
Which is pretty similar to GpioIo()/GpioInt() resources.
Teach ACPICA about this new resource.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Adds the dual GNU/BSD dual license to the existing Intel license.
Provides all licensing information in each source module.
Affects all ACPICA source modules.
The key feature of this utility is that the original comments within
the input ASL files are preserved during the conversion process, and
included within the converted ASL+ file -- thus creating a transparent
conversion of existing ASL files to ASL+ (ASL 2.0)
We in fact is always using the compiler specific stdarg.h for GCC even
when ACPI_USE_STANDARD_HEADERS is not defined. So that the va_arg usages
can always be correct for different compiler options.
Likewise, the va_arg implemented in acenv.h is actually MSVC specific,
this patch also moves it to acmsvc.h and tunes acwin.h to correctly use
it.
After cleaning up, this patch removes all <stdarg.h> inclusions from
other files, but doesn't touch the BSD headers. It seems on BSD clones, for
the _KERNEL builds, <machine/stdarg.h> and <stdarg.h> should be the same
file, and both of them can be removed. However this patch leaves this to
the BSD developers to confirm. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
