September 2021 - Devel

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

9 months

3
8
0 / 0

[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

9 months

1
0
0 / 0

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!

9 months

1
1
0 / 0

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.

9 months

1
0
0 / 0

[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

9 months

1
0
0 / 0

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

9 months

1
0
0 / 0

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) >

9 months

2
1
0 / 0

[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

9 months

1
0
0 / 0

[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

9 months

1
0
0 / 0

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.

9 months, 1 week

2
1
0 / 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Devel September 2021