Re: [Devel] Update to acpica (20190405 broke VirtualBox, patch avail)
by Thomas Renninger
Hi Larry,
+ acpica list
+ Erik, author of the patch
while there is a tested patch, there has not been a pull request or a mail
patch submission on the acpcia mailing list to get the fix mainline.
I like to wait until the patch is submitted and reviewed, best accepted.
Once this has happened, I can grab it.
Or better, if the patch is unmodified, you may want to create a submit
request via the Open SUSE Build Servcie (OBS) with a tiny changelog mentioning
the patch and I can simply accept it.
Thanks Larry for the bug identifying, testing and all the details!
Thomas
Background:
On Monday, April 22, 2019 11:03:09 PM CEST Larry Finger wrote:
> Thomas,
>
> I am writing to you as the maintainer of the acpica package.
>
> The recent update to acpica-20190405 broke iASL for the VirtualBox package.
> With it, Windows 7 VM's fail with a Blue Screen complaining about the BIOS.
> As far as I know, no other OS fails. The bug was posted as bsc#1132941,
> which has been assigned to me.
>
> There is a discussion of this bug at
> https://github.com/acpica/acpica/issues/462, where a patch was posted. I
> checked out the package at home:lwfinger:branches:openSUSE:Factory/acpica,
> added the patch, and built the package locally using osc. I then applied
> that package to a rebuild of VB. Once I did that, then Windows 7 VM's work
> again.
>
> I have committed my changes to my copy of acpica. How do you want to proceed
> from here? Should I send an MR on that project? Please advise.
>
> Larry
2 years, 3 months
Re: [Devel] [PATCH v2 0/7] CPPC optional registers AMD support
by Rafael J. Wysocki
On Wed, Apr 17, 2019 at 7:28 PM Ghannam, Yazen <Yazen.Ghannam(a)amd.com> wrote:
>
> > -----Original Message-----
> > From: Rafael J. Wysocki <rafael(a)kernel.org>
> > Sent: Tuesday, April 16, 2019 4:34 AM
> > To: Natarajan, Janakarajan <Janakarajan.Natarajan(a)amd.com>
> > Cc: Natarajan, Janakarajan <Janakarajan.Natarajan(a)amd.com>; linux-acpi(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; linux-
> > pm(a)vger.kernel.org; devel(a)acpica.org; Rafael J . Wysocki <rjw(a)rjwysocki.net>; Len Brown <lenb(a)kernel.org>; Viresh Kumar
> > <viresh.kumar(a)linaro.org>; Robert Moore <robert.moore(a)intel.com>; Erik Schmauss <erik.schmauss(a)intel.com>; Ghannam, Yazen
> > <Yazen.Ghannam(a)amd.com>
> > Subject: Re: [PATCH v2 0/7] CPPC optional registers AMD support
> >
> > On Tue, Apr 16, 2019 at 12:35 AM Janakarajan Natarajan <jnataraj(a)amd.com> wrote:
> > >
> > > On 4/4/19 4:25 PM, Natarajan, Janakarajan wrote:
> > > > CPPC (Collaborative Processor Performance Control) offers optional
> > > > registers which can be used to tune the system based on energy and/or
> > > > performance requirements.
> > > >
> > > > Newer AMD processors add support for a subset of these optional CPPC
> > > > registers, based on ACPI v6.1.
> > > >
> > > > The following are the supported CPPC registers for which sysfs entries
> > > > are created:
> > > > * enable (NEW)
> > > > * max_perf (NEW)
> > > > * min_perf (NEW)
> > > > * energy_perf
> > > > * lowest_perf
> > > > * nominal_perf
> > > > * desired_perf (NEW)
> > > > * feedback_ctrs
> > > > * auto_sel_enable (NEW)
> > > > * lowest_nonlinear_perf
> > > >
> > > > The CPPC driver is updated to enable the OSPM and the userspace to
> > > > access
> > > > the newly supported registers.
> > > >
> > > > The purpose of exposing the registers via the sysfs entries is to allow
> > > > the userspace to:
> > > > * Tweak the values to fit its workload.
> > > > * Apply a profile from AMD's optimization guides.
> > > >
> > > > Profiles will be documented in the performance/optimization guides.
> > > >
> > > > Note:
> > > > * AMD systems will not have a policy applied in the kernel at this time.
> > > > * By default, acpi_cpufreq will still be used.
> > > >
> > > > TODO:
> > > > * Create a linux userspace tool that will help users generate a CPPC
> > > > * profile
> > > > for their target workload.
> > > > * Create or update a driver to apply a general CPPC policy in the
> > > > * kernel.
> > > >
> > > > v1->v2:
> > > > * Add macro to ensure BUFFER only registers have BUFFER type.
> > > > * Add support macro to make the right check based on register type.
> > > > * Remove support checks for registers which are mandatory.
> > >
> > >
> > > Are there any concerns regarding this patchset?
> >
> > Yes, there are.
> >
> > Unfortunately, it is generally problematic.
> >
> > First off, the behavior of existing sysfs files cannot be changed at
> > will, as there may be users of them out there already depending on the
> > current behavior.
> >
>
> The intent is to add new sysfs files without changing the existing files. Is that okay?
>
> Or is the addition of new files also not acceptable?
>
> > Second, at least some CPPC control registers are used by cpufreq
> > drivers (cppc_cpufreq and intel_pstate), so modifying them behind the
> > drivers' backs is not a good idea in general. For this reason, adding
> > new sysfs attributes to allow user space to do that is quite
> > questionable.
> >
>
> Yes, good point.
>
> What if a check is added so that writes only succeed if the CPUFREQ governor is set to userspace?
That wouldn't be particularly straightforward IMO.
What about handling this like the others do, through a proper cpufreq driver?
2 years, 3 months
Re: [Devel] [PATCH v2 0/7] CPPC optional registers AMD support
by Rafael J. Wysocki
On Tue, Apr 16, 2019 at 12:35 AM Janakarajan Natarajan <jnataraj(a)amd.com> wrote:
>
> On 4/4/19 4:25 PM, Natarajan, Janakarajan wrote:
> > CPPC (Collaborative Processor Performance Control) offers optional
> > registers which can be used to tune the system based on energy and/or
> > performance requirements.
> >
> > Newer AMD processors add support for a subset of these optional CPPC
> > registers, based on ACPI v6.1.
> >
> > The following are the supported CPPC registers for which sysfs entries
> > are created:
> > * enable (NEW)
> > * max_perf (NEW)
> > * min_perf (NEW)
> > * energy_perf
> > * lowest_perf
> > * nominal_perf
> > * desired_perf (NEW)
> > * feedback_ctrs
> > * auto_sel_enable (NEW)
> > * lowest_nonlinear_perf
> >
> > The CPPC driver is updated to enable the OSPM and the userspace to
> > access
> > the newly supported registers.
> >
> > The purpose of exposing the registers via the sysfs entries is to allow
> > the userspace to:
> > * Tweak the values to fit its workload.
> > * Apply a profile from AMD's optimization guides.
> >
> > Profiles will be documented in the performance/optimization guides.
> >
> > Note:
> > * AMD systems will not have a policy applied in the kernel at this time.
> > * By default, acpi_cpufreq will still be used.
> >
> > TODO:
> > * Create a linux userspace tool that will help users generate a CPPC
> > * profile
> > for their target workload.
> > * Create or update a driver to apply a general CPPC policy in the
> > * kernel.
> >
> > v1->v2:
> > * Add macro to ensure BUFFER only registers have BUFFER type.
> > * Add support macro to make the right check based on register type.
> > * Remove support checks for registers which are mandatory.
>
>
> Are there any concerns regarding this patchset?
Yes, there are.
Unfortunately, it is generally problematic.
First off, the behavior of existing sysfs files cannot be changed at
will, as there may be users of them out there already depending on the
current behavior.
Second, at least some CPPC control registers are used by cpufreq
drivers (cppc_cpufreq and intel_pstate), so modifying them behind the
drivers' backs is not a good idea in general. For this reason, adding
new sysfs attributes to allow user space to do that is quite
questionable.
Thanks,
Rafael
2 years, 3 months
Re: [Devel] [PATCH] ACPI / device_sysfs: change _ADR representation to 64 bits
by Rafael J. Wysocki
On Tue, Apr 16, 2019 at 5:29 AM Vinod Koul <vkoul(a)kernel.org> wrote:
>
> On 15-04-19, 10:18, Pierre-Louis Bossart wrote:
> > Standards such as the MIPI DisCo for SoundWire 1.0 specification
> > assume the _ADR field is 64 bits.
> >
> > _ADR is defined as an "Integer" represented as 64 bits since ACPI 2.0
> > released in 2002. The low levels already use _ADR as 64 bits, e.g. in
> > struct acpi_device_info.
> >
> > This patch bumps the representation used for sysfs to 64 bits.
> >
> > Example with a SoundWire device, the results show the complete
> > vendorID and linkID which were omitted before:
> >
> > Before:
> > $ more /sys/bus/acpi/devices/device\:38/adr
> > 0x5d070000
> > After:
> > $ more /sys/bus/acpi/devices/device\:38/adr
> > 0x000010025d070000
>
> This looks fine but the sysfs file is an ABI. Not sure if we can modify
> the value returned this way.. Though it should not cause userspace
> reading 32bits to break...
Well, IIRC using "08" instead of "016" in the format field would
preserve the existing behavior for 32-bit values, wouldn't it?
2 years, 3 months
[pm:bleeding-edge 47/52] drivers//acpi/acpi_configfs.c:112:32: error: 'ACPI_NAME_SIZE' undeclared; did you mean 'APR_NAME_SIZE'?
by kbuild test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
head: ea3d77d1940b15ef51a4f4936d05e99fab4cecff
commit: 756ae0e33ac30984626b5f570c21c2bd1defac4d [47/52] ACPICA: Rename nameseg length macro/define for clarity
config: i386-randconfig-x001-201914 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 756ae0e33ac30984626b5f570c21c2bd1defac4d
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
drivers//acpi/acpi_configfs.c: In function 'acpi_table_signature_show':
>> drivers//acpi/acpi_configfs.c:112:32: error: 'ACPI_NAME_SIZE' undeclared (first use in this function); did you mean 'APR_NAME_SIZE'?
return sprintf(str, "%.*s\n", ACPI_NAME_SIZE, h->signature);
^~~~~~~~~~~~~~
APR_NAME_SIZE
drivers//acpi/acpi_configfs.c:112:32: note: each undeclared identifier is reported only once for each function it appears in
drivers//acpi/acpi_configfs.c: In function 'acpi_table_asl_compiler_id_show':
drivers//acpi/acpi_configfs.c:173:32: error: 'ACPI_NAME_SIZE' undeclared (first use in this function); did you mean 'APR_NAME_SIZE'?
return sprintf(str, "%.*s\n", ACPI_NAME_SIZE, h->asl_compiler_id);
^~~~~~~~~~~~~~
APR_NAME_SIZE
>> drivers//acpi/acpi_configfs.c:174:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
drivers//acpi/acpi_configfs.c: In function 'acpi_table_signature_show':
drivers//acpi/acpi_configfs.c:113:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
vim +112 drivers//acpi/acpi_configfs.c
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 104
c62c15a9 drivers/acpi/acpi_configfs.c Andy Shevchenko 2019-03-11 105 static ssize_t acpi_table_signature_show(struct config_item *cfg, char *str)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 106 {
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 107 struct acpi_table_header *h = get_header(cfg);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 108
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 109 if (!h)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 110 return -EINVAL;
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 111
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 @112 return sprintf(str, "%.*s\n", ACPI_NAME_SIZE, h->signature);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 113 }
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 114
c62c15a9 drivers/acpi/acpi_configfs.c Andy Shevchenko 2019-03-11 115 static ssize_t acpi_table_length_show(struct config_item *cfg, char *str)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 116 {
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 117 struct acpi_table_header *h = get_header(cfg);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 118
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 119 if (!h)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 120 return -EINVAL;
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 121
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 122 return sprintf(str, "%d\n", h->length);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 123 }
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 124
c62c15a9 drivers/acpi/acpi_configfs.c Andy Shevchenko 2019-03-11 125 static ssize_t acpi_table_revision_show(struct config_item *cfg, char *str)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 126 {
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 127 struct acpi_table_header *h = get_header(cfg);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 128
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 129 if (!h)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 130 return -EINVAL;
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 131
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 132 return sprintf(str, "%d\n", h->revision);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 133 }
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 134
c62c15a9 drivers/acpi/acpi_configfs.c Andy Shevchenko 2019-03-11 135 static ssize_t acpi_table_oem_id_show(struct config_item *cfg, char *str)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 136 {
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 137 struct acpi_table_header *h = get_header(cfg);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 138
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 139 if (!h)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 140 return -EINVAL;
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 141
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 142 return sprintf(str, "%.*s\n", ACPI_OEM_ID_SIZE, h->oem_id);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 143 }
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 144
c62c15a9 drivers/acpi/acpi_configfs.c Andy Shevchenko 2019-03-11 145 static ssize_t acpi_table_oem_table_id_show(struct config_item *cfg, char *str)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 146 {
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 147 struct acpi_table_header *h = get_header(cfg);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 148
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 149 if (!h)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 150 return -EINVAL;
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 151
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 152 return sprintf(str, "%.*s\n", ACPI_OEM_TABLE_ID_SIZE, h->oem_table_id);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 153 }
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 154
c62c15a9 drivers/acpi/acpi_configfs.c Andy Shevchenko 2019-03-11 155 static ssize_t acpi_table_oem_revision_show(struct config_item *cfg, char *str)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 156 {
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 157 struct acpi_table_header *h = get_header(cfg);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 158
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 159 if (!h)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 160 return -EINVAL;
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 161
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 162 return sprintf(str, "%d\n", h->oem_revision);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 163 }
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 164
c62c15a9 drivers/acpi/acpi_configfs.c Andy Shevchenko 2019-03-11 165 static ssize_t acpi_table_asl_compiler_id_show(struct config_item *cfg,
c62c15a9 drivers/acpi/acpi_configfs.c Andy Shevchenko 2019-03-11 166 char *str)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 167 {
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 168 struct acpi_table_header *h = get_header(cfg);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 169
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 170 if (!h)
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 171 return -EINVAL;
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 172
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 173 return sprintf(str, "%.*s\n", ACPI_NAME_SIZE, h->asl_compiler_id);
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 @174 }
612bd01f drivers/acpi/configfs.c Octavian Purdila 2016-07-08 175
:::::: The code at line 112 was first introduced by commit
:::::: 612bd01fc6e04c3ce9eb59587b4a7e4ebd6aff35 ACPI: add support for loading SSDTs via configfs
:::::: TO: Octavian Purdila <octavian.purdila(a)intel.com>
:::::: CC: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
2 years, 3 months
[pm:bleeding-edge 47/52] drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c:233:32: error: 'ACPI_NAME_SIZE' undeclared; did you mean 'APR_NAME_SIZE'?
by kbuild test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
head: ea3d77d1940b15ef51a4f4936d05e99fab4cecff
commit: 756ae0e33ac30984626b5f570c21c2bd1defac4d [47/52] ACPICA: Rename nameseg length macro/define for clarity
config: x86_64-rhel-7.6 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 756ae0e33ac30984626b5f570c21c2bd1defac4d
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c: In function 'get_single_name':
>> drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c:233:32: error: 'ACPI_NAME_SIZE' undeclared (first use in this function); did you mean 'APR_NAME_SIZE'?
memcpy(name, buffer.pointer, ACPI_NAME_SIZE);
^~~~~~~~~~~~~~
APR_NAME_SIZE
drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c:233:32: note: each undeclared identifier is reported only once for each function it appears in
vim +233 drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 223
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 224
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 225 /* get device name from acpi handle */
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 226 static void get_single_name(acpi_handle handle, char *name)
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 227 {
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 228 struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER};
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 229
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 230 if (ACPI_FAILURE(acpi_get_name(handle, ACPI_SINGLE_NAME, &buffer)))
1820142f5 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Sumeet Pawnikar 2017-08-04 231 pr_warn("Failed to get device name from acpi handle\n");
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 232 else {
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 @233 memcpy(name, buffer.pointer, ACPI_NAME_SIZE);
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 234 kfree(buffer.pointer);
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 235 }
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 236 }
52b1c69d7 drivers/thermal/int340x_thermal/acpi_thermal_rel.c Jacob Pan 2014-09-03 237
:::::: The code at line 233 was first introduced by commit
:::::: 52b1c69d7e3cd8bdba0e55bde24093f0779bb29d Thermal: int340x_thermal: expose acpi thermal relationship tables
:::::: TO: Jacob Pan <jacob.jun.pan(a)linux.intel.com>
:::::: CC: Zhang Rui <rui.zhang(a)intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
2 years, 3 months
Field Offset constraints
by Patrick Georgi
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
2 years, 3 months
ACPICA version 20190405 released
by Moore, Robert
05 April 2019. Summary of changes for version 20190405:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Event Manager: History: Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume") was added earlier to stop clearing of event status bits unconditionally on suspend and resume paths. Though this change fixed an issue on suspend path, it introduced regressions on several resume paths. In the case of S0ix, events are enabled as part of device suspend path. If status bits for the events are set when they are enabled, it could result in premature wake from S0ix. If status is cleared for any event that is being enabled so that any stale events are cleared out. In case of S0ix, events are enabled as part of device suspend path. If status bits for the events are set when they are enabled, it could result in premature wake from S0ix.
This change ensures that status is cleared for any event that is being enabled so that any stale events are cleared out.
2) iASL Compiler/Disassembler and ACPICA tools:
iASL: Implemented an enhanced multiple file compilation that combines named objects from all input files to a single namespace. With this feature, any unresolved external declarations as well as duplicate named object declarations can be detected during compilation rather than generating errors much later at runtime. The following commands are examples that utilize this feature:
iasl dsdt.asl ssdt.asl
iasl dsdt.asl ssdt1.asl ssdt2.asl
iasl dsdt.asl ssdt*.asl
2 years, 3 months
git tag issue ACPICA version 20190329
by Schmauss, Erik
Hi everyone,
For those of you who have pulled the new release sometime between 3/29 and yesterday, you may notice that this "HEAD" tag exists. This was unintentional and have since fixed it with the proper tag. If you have a tag called "HEAD" please fetch and pull the current repository and do the following command: "git tag -d HEAD" to remove this tag in your local repositories. If you've pulled or cloned the repository today, please ignore this email.
Thanks,
Erik Schmauss
2 years, 3 months
