Question about ACPICA, QNX and making beeps
by Devin Steffler
Hello,
I am using ACPICA to read battery information in QNX. That part is working
great so far. However, now some code that is being used to make beeps via
the PC speaker stopped working.
Strangely, this code stops working on a few devices only after ACPICA runs.
It works fine if I don't start ACPICA. The code is using I/O ports 0x43,
0x42, and 0x61 to generate beeps. This seems to be an industry standard way
to make beeps on x86 based PCs using a Programmable Interval Timer (PIT).
What could my ACPICA be doing (or failing to do) that could cause the beeps
to stop working with the code below? Is the PIT being disabled somehow? I
guess I'll need to learn more about the PIT and how to check its status to
see if it's being disabled after ACPICA runs.
Here's example code for QNX to generate a beep using the PC speaker:
// -----------------------------------------------
#include <sys/neutrino.h>
#include <hw/inout.h>
#include <unistd.h>
int main(void) {
ThreadCtl( _NTO_TCTL_IO, 0 ); // get I/O permissions
// start a beep
int freq = 1000;
int scale = 1193046 / freq;
out8(0x43, 0xb6);
out8(0x42, scale & 0xff);
out8(0x42, scale >> 8);
out8(0x61, in8(0x61) | 3);
// let the beep play for a second
delay(1000);
// stop the beep
out8(0x61, in8(0x61) & ~3);
return 0;
}
// -----------------------------------------------
Thanks,
Devin
1 week, 6 days
[rafael-pm:bleeding-edge] BUILD SUCCESS 28f08c3dc673d5c3f83fda3af11eab85d82842af
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 28f08c3dc673d5c3f83fda3af11eab85d82842af Merge branch 'acpica' into bleeding-edge
elapsed time: 739m
configs tested: 106
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20210930
mips ip27_defconfig
arm cns3420vb_defconfig
arm realview_defconfig
sparc sparc32_defconfig
sh ul2_defconfig
arm stm32_defconfig
m68k sun3x_defconfig
powerpc wii_defconfig
powerpc canyonlands_defconfig
powerpc mpc837x_mds_defconfig
m68k sun3_defconfig
ia64 alldefconfig
powerpc mpc8315_rdb_defconfig
arm footbridge_defconfig
powerpc sequoia_defconfig
powerpc taishan_defconfig
mips ath79_defconfig
sh lboxre2_defconfig
arm randconfig-c002-20210930
x86_64 randconfig-c001-20210930
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210930
i386 randconfig-a001-20210930
i386 randconfig-a004-20210930
i386 randconfig-a002-20210930
i386 randconfig-a006-20210930
i386 randconfig-a005-20210930
x86_64 randconfig-a004-20210930
x86_64 randconfig-a001-20210930
x86_64 randconfig-a002-20210930
x86_64 randconfig-a005-20210930
x86_64 randconfig-a006-20210930
x86_64 randconfig-a003-20210930
arc randconfig-r043-20210930
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
i386 randconfig-c001-20210930
arm randconfig-c002-20210930
powerpc randconfig-c003-20210930
mips randconfig-c004-20210930
s390 randconfig-c005-20210930
riscv randconfig-c006-20210930
x86_64 randconfig-c007-20210930
x86_64 randconfig-a015-20210930
x86_64 randconfig-a011-20210930
x86_64 randconfig-a012-20210930
x86_64 randconfig-a013-20210930
x86_64 randconfig-a016-20210930
x86_64 randconfig-a014-20210930
i386 randconfig-a014-20210930
i386 randconfig-a013-20210930
i386 randconfig-a011-20210930
i386 randconfig-a015-20210930
i386 randconfig-a016-20210930
i386 randconfig-a012-20210930
riscv randconfig-r042-20210930
hexagon randconfig-r041-20210930
s390 randconfig-r044-20210930
hexagon randconfig-r045-20210930
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
2 weeks, 1 day
Re: [PATCH] ACPI: avoid NULL pointer arithmetic
by Rafael J. Wysocki
On Mon, Sep 27, 2021 at 2:13 PM Arnd Bergmann <arnd(a)kernel.org> wrote:
>
> From: Arnd Bergmann <arnd(a)arndb.de>
>
> There are some very old macros for doing an open-coded offsetof() and
> cast between pointer and integer in ACPI headers. clang-14 now complains
> about these:
>
> drivers/acpi/acpica/tbfadt.c:86:3: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction]
> ACPI_FADT_OFFSET(pm_timer_block),
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/acpi/actbl.h:376:47: note: expanded from macro 'ACPI_FADT_OFFSET'
> #define ACPI_FADT_OFFSET(f) (u16) ACPI_OFFSET (struct acpi_table_fadt, f)
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/acpi/actypes.h:511:41: note: expanded from macro 'ACPI_OFFSET'
> #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/acpi/actypes.h:505:79: note: expanded from macro 'ACPI_PTR_DIFF'
> #define ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8, (a)) - ACPI_CAST_PTR (u8, (b))))
> ^ ~~~~~~~~~~~~~~~~~~~~~~~
> Convert them to the modern equivalents.
>
> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
> ---
> include/acpi/actypes.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
> index 92c71dfce0d5..285bc7b73de3 100644
> --- a/include/acpi/actypes.h
> +++ b/include/acpi/actypes.h
> @@ -507,8 +507,8 @@ typedef u64 acpi_integer;
> /* Pointer/Integer type conversions */
>
> #define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, (acpi_size) (i))
> -#define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) 0)
> -#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
> +#define ACPI_TO_INTEGER(p) ((uintptr_t)(p))
> +#define ACPI_OFFSET(d, f) offsetof(d, f)
> #define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i)
> #define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
>
> --
Queued up as 5.16 material, converted into an upstream ACPICA pull
request and submitted, thanks!
2 weeks, 1 day
ACPICA version 20210930 released
by Moore, Robert
30 September 2021. Summary of changes for version 20210930:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Hardware: Avoid evaluating methods too early during system resume. During wakeup from system-wide sleep states, AcpiGetSleepTypeData() is called and it tries to get memory from the OS in order to evaluate a control method, but if KFENCE is enabled in the Linux kernel, the memory allocation attempt causes an IRQ work to be queued and a self-IPI to be sent to the CPU running the code which requires the memory controller to be ready, so if that happens too early in the wakeup path, it doesn't work.
Prevent that from taking place by calling AcpiGetSleepTypeData() for S0 upfront, when preparing to enter a given sleep state, and saving the data obtained by it for later use during system wakeup.
Added a new _OSI string, "Windows 2020". Posted by superm1.
2) iASL Compiler/Disassembler and ACPICA tools:
iASL compiler: Updated the check for usage of _CRS, _DIS, _PRS, and _SRS objects:
New/latest rules: Under a Device Object:
1) If _PRS is present, must have _CRS and _SRS
2) If _SRS is present, must have _PRS (_PRS requires _CRS and _SRS)
3) If _DIS is present, must have _SRS (_SRS requires _PRS, _PRS requires _CRS and _SRS)
4) If _SRS is present, probably should have a _DIS (Remark only)
iASL table disassembler: Added disassembly support for the NHLT ACPI table. Note: support for Vendor-defined microphone arrays and SNR extensions are not supported at this time -- mostly due to a lack of example tables. Actual compiler support for NHLT is forthcoming.
Added a new subtable type for ACPI 6.4 SRAT Generic Port Affinity. It uses the same subtable structure as the existing Generic Initiator Affinity type.
Added the flag for online capable in the MADT, introduced in ACPI 6.3. Posted by superm1.
3) ACPICA documentation: Updated the legal info (that appears at the start of the Documents) to clarify distribution rights that are granted.
2 weeks, 1 day
[rafael-pm:bleeding-edge] BUILD SUCCESS fb49d3272e86255e33a132a455cd965e578f9a8e
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: fb49d3272e86255e33a132a455cd965e578f9a8e Merge branch 'acpica' into bleeding-edge
elapsed time: 731m
configs tested: 92
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20210929
powerpc sam440ep_defconfig
arm axm55xx_defconfig
sh se7343_defconfig
arm nhk8815_defconfig
powerpc mpc836x_rdk_defconfig
powerpc mpc8272_ads_defconfig
mips malta_kvm_defconfig
mips capcella_defconfig
arm am200epdkit_defconfig
x86_64 randconfig-c001-20210929
arm randconfig-c002-20210929
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a002-20210929
x86_64 randconfig-a005-20210929
x86_64 randconfig-a001-20210929
x86_64 randconfig-a006-20210929
x86_64 randconfig-a003-20210929
x86_64 randconfig-a004-20210929
i386 randconfig-a001-20210929
i386 randconfig-a005-20210929
i386 randconfig-a002-20210929
i386 randconfig-a006-20210929
i386 randconfig-a004-20210929
i386 randconfig-a003-20210929
arc randconfig-r043-20210929
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a014-20210929
x86_64 randconfig-a011-20210929
x86_64 randconfig-a013-20210929
x86_64 randconfig-a015-20210929
x86_64 randconfig-a012-20210929
x86_64 randconfig-a016-20210929
i386 randconfig-a014-20210929
i386 randconfig-a013-20210929
i386 randconfig-a016-20210929
i386 randconfig-a011-20210929
i386 randconfig-a015-20210929
i386 randconfig-a012-20210929
hexagon randconfig-r045-20210929
riscv randconfig-r042-20210929
hexagon randconfig-r041-20210929
s390 randconfig-r044-20210929
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
2 weeks, 1 day
Re: [PATCH v2] Revert "ACPI: Add memory semantics to acpi_os_map_memory()"
by Lorenzo Pieralisi
[+Tony]
On Tue, Sep 28, 2021 at 07:26:52PM +0200, Rafael J. Wysocki wrote:
> On 9/24/2021 11:04 AM, Lorenzo Pieralisi wrote:
> > On Thu, Sep 23, 2021 at 02:54:52PM +0200, Rafael J. Wysocki wrote:
> > > On Thu, Sep 23, 2021 at 2:26 PM Mark Kettenis <mark.kettenis(a)xs4all.nl> wrote:
> > > > > From: "Rafael J. Wysocki" <rafael(a)kernel.org>
> > > > > Date: Thu, 23 Sep 2021 13:05:05 +0200
> > > > >
> > > > > On Thu, Sep 23, 2021 at 11:40 AM Lorenzo Pieralisi
> > > > > <lorenzo.pieralisi(a)arm.com> wrote:
> > > > > > On Thu, Sep 23, 2021 at 01:09:58AM +0200, Mark Kettenis wrote:
> > > > > > > > Date: Wed, 22 Sep 2021 17:33:36 +0100
> > > > > > > > From: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
> > > > > > > >
> > > > > > > > On Fri, Sep 10, 2021 at 10:32:23PM +0800, Jia He wrote:
> > > > > > > > > This reverts commit 437b38c51162f8b87beb28a833c4d5dc85fa864e.
> > > > > > > > >
> > > > > > > > > After this commit, a boot panic is alway hit on an Ampere EMAG server
> > > > > > > > > with call trace as follows:
> > > > > > > > > Internal error: synchronous external abort: 96000410 [#1] SMP
> > > > > > > > > Modules linked in:
> > > > > > > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+ #462
> > > > > > > > > Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 0.14 02/22/2019
> > > > > > > > > pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > > > > > [...snip...]
> > > > > > > > > Call trace:
> > > > > > > > > acpi_ex_system_memory_space_handler+0x26c/0x2c8
> > > > > > > > > acpi_ev_address_space_dispatch+0x228/0x2c4
> > > > > > > > > acpi_ex_access_region+0x114/0x268
> > > > > > > > > acpi_ex_field_datum_io+0x128/0x1b8
> > > > > > > > > acpi_ex_extract_from_field+0x14c/0x2ac
> > > > > > > > > acpi_ex_read_data_from_field+0x190/0x1b8
> > > > > > > > > acpi_ex_resolve_node_to_value+0x1ec/0x288
> > > > > > > > > acpi_ex_resolve_to_value+0x250/0x274
> > > > > > > > > acpi_ds_evaluate_name_path+0xac/0x124
> > > > > > > > > acpi_ds_exec_end_op+0x90/0x410
> > > > > > > > > acpi_ps_parse_loop+0x4ac/0x5d8
> > > > > > > > > acpi_ps_parse_aml+0xe0/0x2c8
> > > > > > > > > acpi_ps_execute_method+0x19c/0x1ac
> > > > > > > > > acpi_ns_evaluate+0x1f8/0x26c
> > > > > > > > > acpi_ns_init_one_device+0x104/0x140
> > > > > > > > > acpi_ns_walk_namespace+0x158/0x1d0
> > > > > > > > > acpi_ns_initialize_devices+0x194/0x218
> > > > > > > > > acpi_initialize_objects+0x48/0x50
> > > > > > > > > acpi_init+0xe0/0x498
> > > > > > > > >
> > > > > > > > > As mentioned by Lorenzo:
> > > > > > > > > "We are forcing memory semantics mappings to PROT_NORMAL_NC, which
> > > > > > > > > eMAG does not like at all and I'd need to understand why. It looks
> > > > > > > > > like the issue happen in SystemMemory Opregion handler."
> > > > > > > > >
> > > > > > > > > Hence just revert it before everything is clear.
> > > > > > > > >
> > > > > > > > > Fixes: 437b38c51162 ("ACPI: Add memory semantics to acpi_os_map_memory()")
> > > > > > > > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
> > > > > > > > > Cc: Ard Biesheuvel <ardb(a)kernel.org>
> > > > > > > > > Cc: Hanjun Guo <guohanjun(a)huawei.com>
> > > > > > > > > Cc: Catalin Marinas <catalin.marinas(a)arm.com>
> > > > > > > > > Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
> > > > > > > > > Cc: Harb Abdulhamid <harb(a)amperecomputing.com>
> > > > > > > > >
> > > > > > > > > Signed-off-by: Jia He <justin.he(a)arm.com>
> > > > > > > > Rewrote the commit log, please take the patch below and repost
> > > > > > > > it as a v3.
> > > > > > > >
> > > > > > > > It would still be great if Ampere can help us understand why
> > > > > > > > the NormalNC attributes trigger a sync abort on the opregion
> > > > > > > > before merging it.
> > > > > > > To be honest, I don't think you really need an explanation from Ampere
> > > > > > > here. Mapping a part of the address space that doesn't provide memory
> > > > > > > semantics with NormalNC attributes is wrong and triggering a sync
> > > > > > > abort in that case is way better than silently ignoring the access.
> > > > > > That's understood and that's what I explained in the revert commit
> > > > > > log, no question about it.
> > > > > >
> > > > > > I was just asking to confirm if that's what's actually happening.
> > > > > >
> > > > > > > Putting my OpenBSD hat on (where we have our own ACPI OSPM
> > > > > > > implementation) I must say that we always interpreted SystemMemory as
> > > > > > > memory mapped IO and I think that is a logical choice as SystemIO is
> > > > > > > used for (non-memory mapped) IO. And I'd say that the ACPI OSPM code
> > > > > > > should make sure that it uses properly aligned access to any Field
> > > > > > > object that doesn't use AnyAcc as its access type. Even on x86! And
> > > > > > > I'd say that AML that uses AnyAcc fields for SystemMemory OpRegions on
> > > > > > > arm64 is buggy.
> > > > > > >
> > > > > > > But maybe relaxing this when the EFI memory map indicates that the
> > > > > > > address space in question does provide memory semantics does make
> > > > > > > sense. That should defenitely be documented in the ACPI standard
> > > > > > > though.
> > > > > > Mapping SystemMemory Opregions as "memory" does not make sense
> > > > > > at all to me. Still, that's what Linux ACPICA code does (*if*
> > > > > > that's what acpi_os_map_memory() is supposed to mean).
> > > > > >
> > > > > > https://lore.kernel.org/linux-acpi/20210916160827.GA4525@lpieralisi
> > > > > It doesn't need to do that, though, if there are good enough arguments
> > > > > to change the current behavior (and the argument here is that it may
> > > > > be an MMIO region, so mapping it as memory doesn't really work, but it
> > > > > also may be a region in memory - there is no rule in the spec by which
> > > > > SystemMemory Opregions cannot be "memory" AFAICS) and if that change
> > > > > doesn't introduce regressions in the installed base.
> > > > >
> > > > > > Where do we go from here, to be defined, we still have a bug
> > > > > > to fix after the revert is applied.
> > > > > >
> > > > > > drivers/acpi/sysfs.c
> > > > > >
> > > > > > maps BERT error regions with acpi_os_map_memory().
> > > > > That mechanism is basically used for exporting ACPI tables to user
> > > > > space and they are known to reside in memory. Whether or not BERT
> > > > > regions should be mapped in the same way is a good question.
> > > > It is not inconceivable that BERT regions actually live in memory of
> > > > the BMC that is exposed over a bus that doesn't implement memory
> > > > semantics is it?
> > > No, it isn't, which is why I think that mapping them as RAM may not be
> > > a good idea in general.
> > Should I patch acpi_data_show() to map BERT error regions (well, that's
> > what acpi_data_show() is used on at the moment) as MMIO and use the
> > related memcpy routine to read them then :) ?
>
> It actually would be good to clean it up so it is clear that this is only
> used for BERT.
>
> And then there is this question: if this is not RAM (so effectively it is
> device memory), should it be exposed directly to user space?
Do you mean from a security standpoint ? I believe there might be users
out there so if we want to remove that sysfs entry it may be
problematic.
Maybe Tony has more insights into this than I do:
commit 7dae6326ed76 ("ACPI / sysfs: Extend ACPI sysfs to provide access to boot error region")
Thanks,
Lorenzo
2 weeks, 2 days
Re: [PATCH] ACPI: avoid NULL pointer arithmetic
by Moore, Robert
I can take this patch as-is, I think. I'll try for the next acpica release later this week.
-----Original Message-----
From: Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>
Sent: Tuesday, September 28, 2021 10:44 AM
To: Arnd Bergmann <arnd(a)kernel.org>; Moore, Robert <robert.moore(a)intel.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>; Nathan Chancellor <nathan(a)kernel.org>; Nick Desaulniers <ndesaulniers(a)google.com>; Erik Kaneda <erik.kaneda(a)intel.com>; linux-acpi(a)vger.kernel.org; devel(a)acpica.org; linux-kernel(a)vger.kernel.org; llvm(a)lists.linux.dev; Len Brown <lenb(a)kernel.org>; Rafael J. Wysocki <rafael(a)kernel.org>
Subject: Re: [PATCH] ACPI: avoid NULL pointer arithmetic
Bob, this is ACPICA material.
Would it be possible to apply this to the upstream from the patch or do you need a PR for this?
On 9/27/2021 2:13 PM, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd(a)arndb.de>
>
> There are some very old macros for doing an open-coded offsetof() and
> cast between pointer and integer in ACPI headers. clang-14 now
> complains about these:
>
> drivers/acpi/acpica/tbfadt.c:86:3: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction]
> ACPI_FADT_OFFSET(pm_timer_block),
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/acpi/actbl.h:376:47: note: expanded from macro 'ACPI_FADT_OFFSET'
> #define ACPI_FADT_OFFSET(f) (u16) ACPI_OFFSET (struct acpi_table_fadt, f)
>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/acpi/actypes.h:511:41: note: expanded from macro 'ACPI_OFFSET'
> #define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/acpi/actypes.h:505:79: note: expanded from macro 'ACPI_PTR_DIFF'
> #define ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8, (a)) - ACPI_CAST_PTR (u8, (b))))
>
> ^ ~~~~~~~~~~~~~~~~~~~~~~~ Convert them to the modern equivalents.
>
> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
> ---
> include/acpi/actypes.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index
> 92c71dfce0d5..285bc7b73de3 100644
> --- a/include/acpi/actypes.h
> +++ b/include/acpi/actypes.h
> @@ -507,8 +507,8 @@ typedef u64 acpi_integer;
> /* Pointer/Integer type conversions */
>
> #define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, (acpi_size) (i))
> -#define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) 0)
> -#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
> +#define ACPI_TO_INTEGER(p) ((uintptr_t)(p))
> +#define ACPI_OFFSET(d, f) offsetof(d, f)
> #define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i)
> #define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
>
2 weeks, 2 days
[rafael-pm:bleeding-edge] BUILD SUCCESS WITH WARNING 5264d800ffd532b515f32ad3a3439b5611438157
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 5264d800ffd532b515f32ad3a3439b5611438157 Merge branch 'pm-pci' into linux-next
Warning reports:
https://lore.kernel.org/linux-pm/202109291232.WuE3FUSQ-lkp@intel.com
Warning in current branch:
drivers/pci/pci-acpi.c:1125:12: warning: 'adev' is used uninitialized [-Wuninitialized]
drivers/pci/pci-acpi.c:1127:12: warning: 'adev' is used uninitialized [-Wuninitialized]
Warning ids grouped by kconfigs:
gcc_recent_errors
|-- ia64-defconfig
| `-- drivers-pci-pci-acpi.c:warning:adev-is-used-uninitialized
`-- ia64-randconfig-r031-20210928
`-- drivers-pci-pci-acpi.c:warning:adev-is-used-uninitialized
elapsed time: 739m
configs tested: 180
configs skipped: 3
gcc tested configs:
arm allyesconfig
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allmodconfig
i386 randconfig-c001-20210928
i386 randconfig-c001-20210929
i386 randconfig-c001-20210927
arm imx_v6_v7_defconfig
powerpc mpc832x_mds_defconfig
powerpc bamboo_defconfig
mips maltaup_xpa_defconfig
arm ep93xx_defconfig
powerpc amigaone_defconfig
powerpc ksi8560_defconfig
powerpc sam440ep_defconfig
sh rsk7203_defconfig
powerpc ebony_defconfig
mips ar7_defconfig
xtensa smp_lx200_defconfig
arm iop32x_defconfig
powerpc mpc8560_ads_defconfig
m68k mac_defconfig
powerpc mpc837x_mds_defconfig
powerpc mpc85xx_cds_defconfig
sh ap325rxa_defconfig
powerpc mgcoge_defconfig
riscv allyesconfig
mips lemote2f_defconfig
sh sh7757lcr_defconfig
sh alldefconfig
nios2 10m50_defconfig
powerpc arches_defconfig
mips decstation_defconfig
arm s5pv210_defconfig
sh sh7785lcr_32bit_defconfig
powerpc skiroot_defconfig
sh se7722_defconfig
arm pleb_defconfig
arm am200epdkit_defconfig
mips maltasmvp_defconfig
powerpc mpc837x_rdb_defconfig
nds32 alldefconfig
mips jazz_defconfig
arm netwinder_defconfig
arm colibri_pxa270_defconfig
mips maltaaprp_defconfig
arm imx_v4_v5_defconfig
powerpc tqm8541_defconfig
powerpc linkstation_defconfig
sh sh7763rdp_defconfig
arm sama7_defconfig
powerpc tqm8560_defconfig
nds32 defconfig
powerpc ep88xc_defconfig
m68k atari_defconfig
mips ip32_defconfig
arc nsimosci_defconfig
arm bcm2835_defconfig
powerpc ep8248e_defconfig
m68k bvme6000_defconfig
sh se7721_defconfig
mips loongson1c_defconfig
mips mpc30x_defconfig
riscv nommu_k210_sdcard_defconfig
arc nsim_700_defconfig
arm tegra_defconfig
riscv alldefconfig
sparc64 defconfig
arm hisi_defconfig
powerpc kilauea_defconfig
arm keystone_defconfig
arm mvebu_v7_defconfig
mips gpr_defconfig
mips sb1250_swarm_defconfig
arm spear6xx_defconfig
m68k mvme16x_defconfig
sparc sparc32_defconfig
arm mmp2_defconfig
arm assabet_defconfig
sh sh2007_defconfig
arm ixp4xx_defconfig
sh urquell_defconfig
mips ip27_defconfig
mips fuloong2e_defconfig
sh r7780mp_defconfig
m68k m5272c3_defconfig
sh shx3_defconfig
microblaze mmu_defconfig
sh se7751_defconfig
powerpc tqm5200_defconfig
sh sdk7780_defconfig
arm ezx_defconfig
x86_64 randconfig-c001-20210928
arm randconfig-c002-20210928
x86_64 randconfig-c001-20210929
arm randconfig-c002-20210929
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k defconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
csky defconfig
alpha defconfig
alpha allyesconfig
nios2 allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
xtensa allyesconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 allyesconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a014-20210928
x86_64 randconfig-a011-20210928
x86_64 randconfig-a013-20210928
x86_64 randconfig-a012-20210928
x86_64 randconfig-a015-20210928
x86_64 randconfig-a016-20210928
i386 randconfig-a014-20210928
i386 randconfig-a013-20210928
i386 randconfig-a016-20210928
i386 randconfig-a011-20210928
i386 randconfig-a015-20210928
i386 randconfig-a012-20210928
arc randconfig-r043-20210928
riscv randconfig-r042-20210928
s390 randconfig-r044-20210928
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
powerpc randconfig-c003-20210927
x86_64 randconfig-c007-20210927
mips randconfig-c004-20210927
arm randconfig-c002-20210927
riscv randconfig-c006-20210927
s390 randconfig-c005-20210927
i386 randconfig-c001-20210927
x86_64 randconfig-a002-20210928
x86_64 randconfig-a005-20210928
x86_64 randconfig-a001-20210928
x86_64 randconfig-a006-20210928
x86_64 randconfig-a003-20210928
x86_64 randconfig-a004-20210928
i386 randconfig-a001-20210928
i386 randconfig-a005-20210928
i386 randconfig-a002-20210928
i386 randconfig-a006-20210928
i386 randconfig-a004-20210928
i386 randconfig-a003-20210928
hexagon randconfig-r045-20210928
hexagon randconfig-r041-20210928
hexagon randconfig-r045-20210929
riscv randconfig-r042-20210929
hexagon randconfig-r041-20210929
s390 randconfig-r044-20210929
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
2 weeks, 2 days
[rafael-pm:linux-next 20/23] drivers/pci/pci-acpi.c:1127:12: warning: 'adev' is used uninitialized
by kernel test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
head: 5264d800ffd532b515f32ad3a3439b5611438157
commit: 9896a58cdd59a6454adeebbe10a881b05550e63a [20/23] PCI: ACPI: PM: Do not use pci_platform_pm_ops for ACPI
config: ia64-randconfig-r031-20210928 (attached as .config)
compiler: ia64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commi...
git remote add rafael-pm https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
git fetch --no-tags rafael-pm linux-next
git checkout 9896a58cdd59a6454adeebbe10a881b05550e63a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
All warnings (new ones prefixed by >>):
In file included from arch/ia64/include/asm/pgtable.h:153,
from include/linux/pgtable.h:6,
from arch/ia64/include/asm/uaccess.h:40,
from include/linux/uaccess.h:11,
from arch/ia64/include/asm/sections.h:11,
from include/linux/interrupt.h:21,
from include/linux/pci.h:38,
from drivers/pci/pci-acpi.c:13:
arch/ia64/include/asm/mmu_context.h: In function 'reload_context':
arch/ia64/include/asm/mmu_context.h:127:48: warning: variable 'old_rr4' set but not used [-Wunused-but-set-variable]
127 | unsigned long rr0, rr1, rr2, rr3, rr4, old_rr4;
| ^~~~~~~
drivers/pci/pci-acpi.c: In function 'acpi_pci_need_resume':
>> drivers/pci/pci-acpi.c:1127:12: warning: 'adev' is used uninitialized [-Wuninitialized]
1127 | if (!adev || !acpi_device_power_manageable(adev))
| ^
vim +/adev +1127 drivers/pci/pci-acpi.c
b67ea76172d4b19 Rafael J. Wysocki 2010-02-17 1109
9896a58cdd59a64 Rafael J. Wysocki 2021-09-20 1110 bool acpi_pci_need_resume(struct pci_dev *dev)
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1111 {
9896a58cdd59a64 Rafael J. Wysocki 2021-09-20 1112 struct acpi_device *adev;
9896a58cdd59a64 Rafael J. Wysocki 2021-09-20 1113
9896a58cdd59a64 Rafael J. Wysocki 2021-09-20 1114 if (acpi_pci_disabled)
9896a58cdd59a64 Rafael J. Wysocki 2021-09-20 1115 return false;
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1116
26112ddc254c986 Rafael J. Wysocki 2018-06-30 1117 /*
26112ddc254c986 Rafael J. Wysocki 2018-06-30 1118 * In some cases (eg. Samsung 305V4A) leaving a bridge in suspend over
26112ddc254c986 Rafael J. Wysocki 2018-06-30 1119 * system-wide suspend/resume confuses the platform firmware, so avoid
9d64b539b738fc1 Rafael J. Wysocki 2018-08-16 1120 * doing that. According to Section 16.1.6 of ACPI 6.2, endpoint
26112ddc254c986 Rafael J. Wysocki 2018-06-30 1121 * devices are expected to be in D3 before invoking the S3 entry path
26112ddc254c986 Rafael J. Wysocki 2018-06-30 1122 * from the firmware, so they should not be affected by this issue.
26112ddc254c986 Rafael J. Wysocki 2018-06-30 1123 */
9d64b539b738fc1 Rafael J. Wysocki 2018-08-16 1124 if (pci_is_bridge(dev) && acpi_target_system_state() != ACPI_STATE_S0)
26112ddc254c986 Rafael J. Wysocki 2018-06-30 1125 return true;
26112ddc254c986 Rafael J. Wysocki 2018-06-30 1126
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 @1127 if (!adev || !acpi_device_power_manageable(adev))
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1128 return false;
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1129
9896a58cdd59a64 Rafael J. Wysocki 2021-09-20 1130 adev = ACPI_COMPANION(&dev->dev);
9a51c6b1f9e0239 Rafael J. Wysocki 2019-05-16 1131 if (adev->wakeup.flags.valid &&
9a51c6b1f9e0239 Rafael J. Wysocki 2019-05-16 1132 device_may_wakeup(&dev->dev) != !!adev->wakeup.prepare_count)
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1133 return true;
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1134
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1135 if (acpi_target_system_state() == ACPI_STATE_S0)
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1136 return false;
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1137
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1138 return !!adev->power.flags.dsw_present;
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1139 }
bac2a909a096c91 Rafael J. Wysocki 2015-01-21 1140
:::::: The code at line 1127 was first introduced by commit
:::::: bac2a909a096c9110525c18cbb8ce73c660d5f71 PCI / PM: Avoid resuming PCI devices during system suspend
:::::: TO: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
:::::: CC: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
2 weeks, 2 days
Re: [PATCH v2] Revert "ACPI: Add memory semantics to acpi_os_map_memory()"
by Rafael J. Wysocki
On Thu, Sep 23, 2021 at 2:26 PM Mark Kettenis <mark.kettenis(a)xs4all.nl> wrote:
>
> > From: "Rafael J. Wysocki" <rafael(a)kernel.org>
> > Date: Thu, 23 Sep 2021 13:05:05 +0200
> >
> > On Thu, Sep 23, 2021 at 11:40 AM Lorenzo Pieralisi
> > <lorenzo.pieralisi(a)arm.com> wrote:
> > >
> > > On Thu, Sep 23, 2021 at 01:09:58AM +0200, Mark Kettenis wrote:
> > > > > Date: Wed, 22 Sep 2021 17:33:36 +0100
> > > > > From: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
> > > > >
> > > > > On Fri, Sep 10, 2021 at 10:32:23PM +0800, Jia He wrote:
> > > > > > This reverts commit 437b38c51162f8b87beb28a833c4d5dc85fa864e.
> > > > > >
> > > > > > After this commit, a boot panic is alway hit on an Ampere EMAG server
> > > > > > with call trace as follows:
> > > > > > Internal error: synchronous external abort: 96000410 [#1] SMP
> > > > > > Modules linked in:
> > > > > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0+ #462
> > > > > > Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 0.14 02/22/2019
> > > > > > pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > > > > > [...snip...]
> > > > > > Call trace:
> > > > > > acpi_ex_system_memory_space_handler+0x26c/0x2c8
> > > > > > acpi_ev_address_space_dispatch+0x228/0x2c4
> > > > > > acpi_ex_access_region+0x114/0x268
> > > > > > acpi_ex_field_datum_io+0x128/0x1b8
> > > > > > acpi_ex_extract_from_field+0x14c/0x2ac
> > > > > > acpi_ex_read_data_from_field+0x190/0x1b8
> > > > > > acpi_ex_resolve_node_to_value+0x1ec/0x288
> > > > > > acpi_ex_resolve_to_value+0x250/0x274
> > > > > > acpi_ds_evaluate_name_path+0xac/0x124
> > > > > > acpi_ds_exec_end_op+0x90/0x410
> > > > > > acpi_ps_parse_loop+0x4ac/0x5d8
> > > > > > acpi_ps_parse_aml+0xe0/0x2c8
> > > > > > acpi_ps_execute_method+0x19c/0x1ac
> > > > > > acpi_ns_evaluate+0x1f8/0x26c
> > > > > > acpi_ns_init_one_device+0x104/0x140
> > > > > > acpi_ns_walk_namespace+0x158/0x1d0
> > > > > > acpi_ns_initialize_devices+0x194/0x218
> > > > > > acpi_initialize_objects+0x48/0x50
> > > > > > acpi_init+0xe0/0x498
> > > > > >
> > > > > > As mentioned by Lorenzo:
> > > > > > "We are forcing memory semantics mappings to PROT_NORMAL_NC, which
> > > > > > eMAG does not like at all and I'd need to understand why. It looks
> > > > > > like the issue happen in SystemMemory Opregion handler."
> > > > > >
> > > > > > Hence just revert it before everything is clear.
> > > > > >
> > > > > > Fixes: 437b38c51162 ("ACPI: Add memory semantics to acpi_os_map_memory()")
> > > > > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
> > > > > > Cc: Ard Biesheuvel <ardb(a)kernel.org>
> > > > > > Cc: Hanjun Guo <guohanjun(a)huawei.com>
> > > > > > Cc: Catalin Marinas <catalin.marinas(a)arm.com>
> > > > > > Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
> > > > > > Cc: Harb Abdulhamid <harb(a)amperecomputing.com>
> > > > > >
> > > > > > Signed-off-by: Jia He <justin.he(a)arm.com>
> > > > >
> > > > > Rewrote the commit log, please take the patch below and repost
> > > > > it as a v3.
> > > > >
> > > > > It would still be great if Ampere can help us understand why
> > > > > the NormalNC attributes trigger a sync abort on the opregion
> > > > > before merging it.
> > > >
> > > > To be honest, I don't think you really need an explanation from Ampere
> > > > here. Mapping a part of the address space that doesn't provide memory
> > > > semantics with NormalNC attributes is wrong and triggering a sync
> > > > abort in that case is way better than silently ignoring the access.
> > >
> > > That's understood and that's what I explained in the revert commit
> > > log, no question about it.
> > >
> > > I was just asking to confirm if that's what's actually happening.
> > >
> > > > Putting my OpenBSD hat on (where we have our own ACPI OSPM
> > > > implementation) I must say that we always interpreted SystemMemory as
> > > > memory mapped IO and I think that is a logical choice as SystemIO is
> > > > used for (non-memory mapped) IO. And I'd say that the ACPI OSPM code
> > > > should make sure that it uses properly aligned access to any Field
> > > > object that doesn't use AnyAcc as its access type. Even on x86! And
> > > > I'd say that AML that uses AnyAcc fields for SystemMemory OpRegions on
> > > > arm64 is buggy.
> > > >
> > > > But maybe relaxing this when the EFI memory map indicates that the
> > > > address space in question does provide memory semantics does make
> > > > sense. That should defenitely be documented in the ACPI standard
> > > > though.
> > >
> > > Mapping SystemMemory Opregions as "memory" does not make sense
> > > at all to me. Still, that's what Linux ACPICA code does (*if*
> > > that's what acpi_os_map_memory() is supposed to mean).
> > >
> > > https://lore.kernel.org/linux-acpi/20210916160827.GA4525@lpieralisi
> >
> > It doesn't need to do that, though, if there are good enough arguments
> > to change the current behavior (and the argument here is that it may
> > be an MMIO region, so mapping it as memory doesn't really work, but it
> > also may be a region in memory - there is no rule in the spec by which
> > SystemMemory Opregions cannot be "memory" AFAICS) and if that change
> > doesn't introduce regressions in the installed base.
> >
> > > Where do we go from here, to be defined, we still have a bug
> > > to fix after the revert is applied.
> > >
> > > drivers/acpi/sysfs.c
> > >
> > > maps BERT error regions with acpi_os_map_memory().
> >
> > That mechanism is basically used for exporting ACPI tables to user
> > space and they are known to reside in memory. Whether or not BERT
> > regions should be mapped in the same way is a good question.
>
> It is not inconceivable that BERT regions actually live in memory of
> the BMC that is exposed over a bus that doesn't implement memory
> semantics is it?
No, it isn't, which is why I think that mapping them as RAM may not be
a good idea in general.
At the same time, mapping the ACPI tables like the DSDT etc. as RAM is
always valid.
3 weeks