[pm:acpica-osl 6/6] drivers/acpi/osl.c:1748:46: sparse: sparse: incorrect type in assignment (different address spaces)
by kernel test robot
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpica-osl
head: c32c3c4079f8a62616413abbead45b6622fb7602
commit: c32c3c4079f8a62616413abbead45b6622fb7602 [6/6] ACPI: OSL: Make ACPICA use logical addresses of GPE blocks
config: x86_64-randconfig-s022-20200904 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-191-g10164920-dirty
git checkout c32c3c4079f8a62616413abbead45b6622fb7602
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp(a)intel.com>
sparse warnings: (new ones prefixed by >>)
drivers/acpi/osl.c:376:17: sparse: sparse: cast removes address space '__iomem' of expression
>> drivers/acpi/osl.c:1748:46: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *extern [addressable] [toplevel] acpi_gbl_xgpe0_block_logical_address @@ got void [noderef] __iomem * @@
>> drivers/acpi/osl.c:1748:46: sparse: expected void *extern [addressable] [toplevel] acpi_gbl_xgpe0_block_logical_address
drivers/acpi/osl.c:1748:46: sparse: got void [noderef] __iomem *
>> drivers/acpi/osl.c:1750:46: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *extern [addressable] [toplevel] acpi_gbl_xgpe1_block_logical_address @@ got void [noderef] __iomem * @@
>> drivers/acpi/osl.c:1750:46: sparse: expected void *extern [addressable] [toplevel] acpi_gbl_xgpe1_block_logical_address
drivers/acpi/osl.c:1750:46: sparse: got void [noderef] __iomem *
drivers/acpi/osl.c:1760:20: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *rv @@ got void [noderef] __iomem * @@
drivers/acpi/osl.c:1760:20: sparse: expected void *rv
drivers/acpi/osl.c:1760:20: sparse: got void [noderef] __iomem *
drivers/acpi/osl.c:708:1: sparse: sparse: context imbalance in 'acpi_os_read_memory' - wrong count at exit
drivers/acpi/osl.c:741:1: sparse: sparse: context imbalance in 'acpi_os_write_memory' - wrong count at exit
# https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commi...
git remote add pm https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
git fetch --no-tags pm acpica-osl
git checkout c32c3c4079f8a62616413abbead45b6622fb7602
vim +1748 drivers/acpi/osl.c
1742
1743 acpi_status __init acpi_os_initialize(void)
1744 {
1745 acpi_os_map_generic_address(&acpi_gbl_FADT.xpm1a_event_block);
1746 acpi_os_map_generic_address(&acpi_gbl_FADT.xpm1b_event_block);
1747
> 1748 acpi_gbl_xgpe0_block_logical_address =
1749 acpi_os_map_generic_address(&acpi_gbl_FADT.xgpe0_block);
> 1750 acpi_gbl_xgpe1_block_logical_address =
1751 acpi_os_map_generic_address(&acpi_gbl_FADT.xgpe1_block);
1752
1753 if (acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER) {
1754 /*
1755 * Use acpi_os_map_generic_address to pre-map the reset
1756 * register if it's in system memory.
1757 */
1758 void *rv;
1759
1760 rv = acpi_os_map_generic_address(&acpi_gbl_FADT.reset_register);
1761 pr_debug(PREFIX "%s: map reset_reg %s\n", __func__,
1762 rv ? "successful" : "failed");
1763 }
1764 acpi_os_initialized = true;
1765
1766 return AE_OK;
1767 }
1768
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
1 year, 8 months
Re: [PATCH] ACPI / NUMA: Add stub function for pxm_to_node
by Hanjun Guo
On 2020/9/29 3:45, Nathan Chancellor wrote:
> After commit 01feba590cd6 ("ACPI: Do not create new NUMA domains from
> ACPI static tables that are not SRAT"):
>
> $ scripts/config --file arch/x86/configs/x86_64_defconfig -d NUMA -e ACPI_NFIT
>
> $ make -skj"$(nproc)" distclean defconfig drivers/acpi/nfit/
> drivers/acpi/nfit/core.c: In function ‘acpi_nfit_register_region’:
> drivers/acpi/nfit/core.c:3010:27: error: implicit declaration of
> function ‘pxm_to_node’; did you mean ‘xa_to_node’?
> [-Werror=implicit-function-declaration]
> 3010 | ndr_desc->target_node = pxm_to_node(spa->proximity_domain);
> | ^~~~~~~~~~~
> | xa_to_node
> cc1: some warnings being treated as errors
> ...
>
> Add a stub function like acpi_map_pxm_to_node had so that the build
> continues to work.
>
> Fixes: 01feba590cd6 ("ACPI: Do not create new NUMA domains from ACPI static tables that are not SRAT")
> Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com>
> ---
>
> I am not sure if this is the right place or value for this. It looks
> like there is going to be another stub function added here, which is
> going through -mm:
>
> https://lkml.kernel.org/r/159643094925.4062302.14979872973043772305.stgit...
>
> include/acpi/acpi_numa.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/acpi/acpi_numa.h b/include/acpi/acpi_numa.h
> index fdebcfc6c8df..09eb3bc20ff5 100644
> --- a/include/acpi/acpi_numa.h
> +++ b/include/acpi/acpi_numa.h
> @@ -22,5 +22,10 @@ extern int acpi_numa __initdata;
> extern void bad_srat(void);
> extern int srat_disabled(void);
>
> +#else /* CONFIG_ACPI_NUMA */
> +static inline int pxm_to_node(int pxm)
> +{
> + return 0;
> +}
> #endif /* CONFIG_ACPI_NUMA */
> #endif /* __ACP_NUMA_H */
Looks good to me,
Reviewed-by: Hanjun Guo <guohanjun(a)huawei.com>
1 year, 8 months
Re: PROBLEM : ACPI, Acquiring Mutex Error
by Moore, Robert
Manoj,
Please send the entire dmesg when the machine fails.
Thanks,
Bob
From: ManojKumar <ndmanojkumar(a)gmail.com>
Sent: Monday, September 28, 2020 5:54 AM
To: Moore, Robert <robert.moore(a)intel.com>
Cc: Kaneda, Erik <erik.kaneda(a)intel.com>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>; lenb(a)kernel.org; linux-acpi(a)vger.kernel.org; devel(a)acpica.org; linux-kernel(a)vger.kernel.org; manjunathmurali87(a)gmail.com; naveen.bheemanapalli(a)gmail.com
Subject: Re: PROBLEM : ACPI, Acquiring Mutex Error
Hi,
Attached is the acpidump of the machine.
Thanks,
Manoj.
On Sat, 19 Sep 2020 at 01:24, Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>> wrote:
With PCI support enabled, you should be able to get the acpidump for the machine, correct?
From: ManojKumar <ndmanojkumar(a)gmail.com<mailto:ndmanojkumar@gmail.com>>
Sent: Friday, September 18, 2020 6:02 AM
To: Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>>
Cc: Kaneda, Erik <erik.kaneda(a)intel.com<mailto:erik.kaneda@intel.com>>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com<mailto:rafael.j.wysocki@intel.com>>; lenb(a)kernel.org<mailto:lenb@kernel.org>; linux-acpi(a)vger.kernel.org<mailto:linux-acpi@vger.kernel.org>; devel(a)acpica.org<mailto:devel@acpica.org>; linux-kernel(a)vger.kernel.org<mailto:linux-kernel@vger.kernel.org>; manjunathmurali87(a)gmail.com<mailto:manjunathmurali87@gmail.com>; naveen.bheemanapalli(a)gmail.com<mailto:naveen.bheemanapalli@gmail.com>
Subject: Re: PROBLEM : ACPI, Acquiring Mutex Error
When booted with PCI support the kernel is booting successfully. When PCI supposed disabled, the mentioned error is taking place. (ACPI mutex error)
On Thu 17 Sep, 2020 8:54 pm Moore, Robert, <robert.moore(a)intel.com<mailto:robert.moore@intel.com>> wrote:
From erik:
What happens when they boot with a kernel that has PCI support?
From: ManojKumar <ndmanojkumar(a)gmail.com<mailto:ndmanojkumar@gmail.com>>
Sent: Monday, September 14, 2020 5:14 AM
To: Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>>; Kaneda, Erik <erik.kaneda(a)intel.com<mailto:erik.kaneda@intel.com>>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com<mailto:rafael.j.wysocki@intel.com>>; lenb(a)kernel.org<mailto:lenb@kernel.org>; linux-acpi(a)vger.kernel.org<mailto:linux-acpi@vger.kernel.org>; devel(a)acpica.org<mailto:devel@acpica.org>; linux-kernel(a)vger.kernel.org<mailto:linux-kernel@vger.kernel.org>
Cc: manjunathmurali87(a)gmail.com<mailto:manjunathmurali87@gmail.com>; naveen.bheemanapalli(a)gmail.com<mailto:naveen.bheemanapalli@gmail.com>
Subject: Re: PROBLEM : ACPI, Acquiring Mutex Error
Hi,
The kernel is failing to boot up completely, it is failing to set up the rootfs too and the control drops to the initramfs shell where only some commands are available. So the acpidump doesn't work there. Is there anything else that I can help you with?
Thanks,
Manoj.
On Fri, 11 Sep 2020 at 21:46, Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>> wrote:
Well, I would say that the root of the problem is here:
ACPI Error: AE_BAD_PARAMETER, During Region initialization
Please send the acpidump for the machine.
Thanks,
Bob
From: ManojKumar <ndmanojkumar(a)gmail.com<mailto:ndmanojkumar@gmail.com>>
Sent: Friday, September 11, 2020 12:37 AM
To: Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>>; Kaneda, Erik <erik.kaneda(a)intel.com<mailto:erik.kaneda@intel.com>>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com<mailto:rafael.j.wysocki@intel.com>>; lenb(a)kernel.org<mailto:lenb@kernel.org>; linux-acpi(a)vger.kernel.org<mailto:linux-acpi@vger.kernel.org>; linux-kernel(a)vger.kernel.org<mailto:linux-kernel@vger.kernel.org>; devel(a)acpica.org<mailto:devel@acpica.org>
Cc: manjunathmurali87(a)gmail.com<mailto:manjunathmurali87@gmail.com>; naveen.bheemanapalli(a)gmail.com<mailto:naveen.bheemanapalli@gmail.com>
Subject: Re: PROBLEM : ACPI, Acquiring Mutex Error
Hi Robert,
We are actually trying to boot the kernel without the PCI support. The ACPICA core shouldn't care as you said but the result gives ACPI errors and says Thread could not acquire Mutex[ACPI_MTX_Tables]. The control then drops to the initramfs shell. Kindly see the attachments. (.config to reproduce the same is also provided)
Thanks,
Manoj.
On Thu, 10 Sep 2020 at 20:01, Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>> wrote:
From: ManojKumar <ndmanojkumar(a)gmail.com<mailto:ndmanojkumar@gmail.com>>
Sent: Wednesday, September 09, 2020 1:46 AM
To: Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>>; Kaneda, Erik <erik.kaneda(a)intel.com<mailto:erik.kaneda@intel.com>>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com<mailto:rafael.j.wysocki@intel.com>>; lenb(a)kernel.org<mailto:lenb@kernel.org>; linux-acpi(a)vger.kernel.org<mailto:linux-acpi@vger.kernel.org>; devel(a)acpica.org<mailto:devel@acpica.org>; linux-kernel(a)vger.kernel.org<mailto:linux-kernel@vger.kernel.org>
Cc: manjunathmurali87(a)gmail.com<mailto:manjunathmurali87@gmail.com>; naveen.bheemanapalli(a)gmail.com<mailto:naveen.bheemanapalli@gmail.com>
Subject: Re: PROBLEM : ACPI, Acquiring Mutex Error
Yes Robert. As I went through the code, during the initializing process, the acpi subsystem tries to load the description tables and fails in doing so (we have disabled PCI support via menuconfig). So it decides to terminate the acpi subsystem where it gets deleted.
I don’t understand. Just because PCI support is disabled, the ACPICA core doesn’t (or shouldn’t) care. Could you please send a screenshot of the initialization?
Thanks,
Bob
After this deletion, the mutex is tried to be acquired in the place mentioned below which is why we see mutex errors in the screen.
Function name: acpi_get_table
File name: tbxface.c (line no.318 ) ,
I would like to hear from you if my understanding is correct.
On Tue, 8 Sep 2020 at 21:55, Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>> wrote:
From: ManojKumar <ndmanojkumar(a)gmail.com<mailto:ndmanojkumar@gmail.com>>
Sent: Friday, September 04, 2020 3:14 AM
To: Moore, Robert <robert.moore(a)intel.com<mailto:robert.moore@intel.com>>; Kaneda, Erik <erik.kaneda(a)intel.com<mailto:erik.kaneda@intel.com>>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com<mailto:rafael.j.wysocki@intel.com>>; lenb(a)kernel.org<mailto:lenb@kernel.org>; linux-acpi(a)vger.kernel.org<mailto:linux-acpi@vger.kernel.org>; devel(a)acpica.org<mailto:devel@acpica.org>; linux-kernel(a)vger.kernel.org<mailto:linux-kernel@vger.kernel.org>
Cc: manjunathmurali87(a)gmail.com<mailto:manjunathmurali87@gmail.com>; naveen.bheemanapalli(a)gmail.com<mailto:naveen.bheemanapalli@gmail.com>
Subject: PROBLEM : ACPI, Acquiring Mutex Error
Hello all,
I’ll try to keep it as simple as possible. Hope you understand.
1. 1.One line summary of the problem: ACPI, Acquiring Mutex Error
2. 2.Subsystem: ACPI
3. 3.Full description of the problem: When the kernel is built without the PCI support which is found under Device Drivers via menuconfig, error on acquiring mutex which has already been deleted, will be triggered (ACPI error: AE_BAD_PARAMETER, Thread [3110141952] could not acquire Mutex[ACPI_MTX_Tables] (0x2)). So, I suggest providing a null check before trying to acquire the mutex will prevent the mutex error.
I think the question is: Why is this mutex being deleted in the first place?
4. 4.Place of error: /drivers/acpi/acpica/tbxface.c
5. 5.Kernel information:
a. a.Versions in which errors were found – 5.7.15, 5.8.1, 5.8.5 (can be more)
b. b.Kernel .config file – .config of 5.8.5 is attached in this mail
6. 6.Environment: This error was produced when running Ubuntu 20.04 in VMware virtual machine on a Windows 10 host with x86 architecture.
7. 7.Processor information: Dell, Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
8. 8.Steps to reproduce the error:
a. a.Get the kernel source code and decompress it.
b. b.Go into the source folder.
c. c.Type $make menuconfig.
d. d.Go to Device Drivers and disable PCI support.
e. e.Save the .config file.
f. f.Build the kernel and install it.
g. g.Reboot and you should see the error messages.
9. 9.Attachments of this mail:
a. a. Screenshot of the error
b. b. .config file for 5.8.5.
Will be glad to provide more information if needed.
1 year, 8 months
[pm:bleeding-edge] BUILD SUCCESS eb6335b68ce3fc85a93c4c6cd3bb6bc5ac490efe
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: eb6335b68ce3fc85a93c4c6cd3bb6bc5ac490efe Merge branch 'pnp' into linux-next
elapsed time: 725m
configs tested: 128
configs skipped: 2
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
mips rt305x_defconfig
mips fuloong2e_defconfig
arm versatile_defconfig
mips nlm_xlp_defconfig
sh edosk7705_defconfig
nios2 3c120_defconfig
powerpc arches_defconfig
powerpc cm5200_defconfig
sparc sparc32_defconfig
arm badge4_defconfig
powerpc cell_defconfig
powerpc obs600_defconfig
sh apsh4ad0a_defconfig
sh shmin_defconfig
arm neponset_defconfig
arm collie_defconfig
powerpc rainier_defconfig
powerpc mpc512x_defconfig
mips lemote2f_defconfig
riscv rv32_defconfig
arc hsdk_defconfig
m68k bvme6000_defconfig
arm mv78xx0_defconfig
riscv defconfig
arm spitz_defconfig
powerpc mpc7448_hpc2_defconfig
mips maltaaprp_defconfig
arm spear6xx_defconfig
mips db1xxx_defconfig
powerpc mpc836x_rdk_defconfig
arc axs103_smp_defconfig
arm zx_defconfig
arm mvebu_v5_defconfig
c6x evmc6472_defconfig
mips gcw0_defconfig
m68k allmodconfig
arm vf610m4_defconfig
mips rbtx49xx_defconfig
nios2 10m50_defconfig
mips cu1000-neo_defconfig
sh se7619_defconfig
powerpc stx_gp3_defconfig
sh rts7751r2d1_defconfig
m68k alldefconfig
mips decstation_defconfig
arm stm32_defconfig
powerpc kilauea_defconfig
powerpc pseries_defconfig
arm lpc32xx_defconfig
ia64 zx1_defconfig
arm simpad_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20200928
i386 randconfig-a002-20200928
i386 randconfig-a003-20200928
i386 randconfig-a004-20200928
i386 randconfig-a005-20200928
i386 randconfig-a001-20200928
i386 randconfig-a002-20200927
i386 randconfig-a006-20200927
i386 randconfig-a003-20200927
i386 randconfig-a004-20200927
i386 randconfig-a005-20200927
i386 randconfig-a001-20200927
i386 randconfig-a012-20200928
i386 randconfig-a016-20200928
i386 randconfig-a014-20200928
i386 randconfig-a013-20200928
i386 randconfig-a015-20200928
i386 randconfig-a011-20200928
x86_64 randconfig-a003-20200928
x86_64 randconfig-a002-20200928
x86_64 randconfig-a001-20200928
x86_64 randconfig-a005-20200928
x86_64 randconfig-a004-20200928
x86_64 randconfig-a006-20200928
riscv allyesconfig
riscv allnoconfig
riscv allmodconfig
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a011-20200928
x86_64 randconfig-a013-20200928
x86_64 randconfig-a015-20200928
x86_64 randconfig-a014-20200928
x86_64 randconfig-a016-20200928
x86_64 randconfig-a012-20200928
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
1 year, 9 months
Automatic dereference when reading from ArgX
by dunkaist＠gmail.com
Hello,
I've been struggling to find out how acpiexec behavior corresponds to what ACPI spec says.
ACPI 6.3 spec, Chapter 19.3.5.9.1 ArgX Objects, 1. Read from ArgX parameters:
> ObjectReference - Automatic dereference, return the target of the reference. Use of DeRefOf returns the same.
ACPI spec, Table 19-421 Reading from ArgX Objects:
> Parameter: RefOf(Obj)
> MTHD ArgX Type: Reference to object Obj
> Read operation on ArgX: Store(Arg0, ...)
> Result of read: Obj
Then, here is a table I've written (argx_deref.asl):
DefinitionBlock ("", "DSDT", 1, "BLAH", "BLAHDSDT", 0x00000001)
{
Name (INT5, 5)
Name (INTX, 0)
Method (DRFA, 1) {
printf("Arg0: %o", DeRefOf(Arg0))
printf("Arg0: %o", Arg0)
Store (DeRefOf(Arg0), INTX)
Store (Arg0, INTX) // <- line 10
Debug = INTX
}
Method (MAIN, 0)
{
DRFA(RefOf(INT5))
}
}
Finally, the output of `acpiexec -m -eo argx_deref.aml':
> Intel ACPI Component Architecture
> AML Execution/Debug Utility version 20200717
> ...
> Nested method call : DRFA
> ACPI Debug: "Arg0: 00000005"
> ACPI Debug: "Arg0: [Reference Object]"
> ACPI Error: Cannot assign type [Reference] to [Integer] (must be type Int/Str/Buf) (20200717/exstoren-239)
> Failed at AML Offset 00024, Opcode 0070: Store (Arg0, INTX) /* External reference */
> ...
So, it turnes out (or at least seems to me) that Store(Arg0, ...) at line 10 reads a Reference object, not an Integer one as the spec says.
I.e. there is no automatic dereference.
Do I miss something? Could you elaborate on this, please?
Thank you,
Ivan
1 year, 9 months
[pm:bleeding-edge] BUILD SUCCESS 39d54892be91e1df9d45a5eb813e766035f07e90
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 39d54892be91e1df9d45a5eb813e766035f07e90 Merge branch 'acpi-battery' into bleeding-edge
elapsed time: 723m
configs tested: 88
configs skipped: 2
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
powerpc holly_defconfig
arm multi_v5_defconfig
sh ecovec24_defconfig
mips jmr3927_defconfig
sparc sparc64_defconfig
arm aspeed_g4_defconfig
powerpc ksi8560_defconfig
arm mps2_defconfig
um kunit_defconfig
sh landisk_defconfig
powerpc mpc8540_ads_defconfig
powerpc socrates_defconfig
arm vf610m4_defconfig
arm versatile_defconfig
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
c6x allyesconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a002-20200925
i386 randconfig-a006-20200925
i386 randconfig-a003-20200925
i386 randconfig-a004-20200925
i386 randconfig-a005-20200925
i386 randconfig-a001-20200925
x86_64 randconfig-a011-20200925
x86_64 randconfig-a013-20200925
x86_64 randconfig-a014-20200925
x86_64 randconfig-a015-20200925
x86_64 randconfig-a012-20200925
x86_64 randconfig-a016-20200925
i386 randconfig-a012-20200925
i386 randconfig-a014-20200925
i386 randconfig-a016-20200925
i386 randconfig-a013-20200925
i386 randconfig-a011-20200925
i386 randconfig-a015-20200925
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a005-20200925
x86_64 randconfig-a003-20200925
x86_64 randconfig-a004-20200925
x86_64 randconfig-a002-20200925
x86_64 randconfig-a006-20200925
x86_64 randconfig-a001-20200925
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
1 year, 9 months
[pm:bleeding-edge] BUILD SUCCESS c6fdc99d71f335046a3cf4014097576e9907b94b
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: c6fdc99d71f335046a3cf4014097576e9907b94b Merge branch 'acpi-numa' into bleeding-edge
elapsed time: 720m
configs tested: 90
configs skipped: 2
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
sh rsk7203_defconfig
powerpc mpc8313_rdb_defconfig
sparc alldefconfig
arm h5000_defconfig
m68k sun3_defconfig
arm ixp4xx_defconfig
powerpc arches_defconfig
um i386_defconfig
sh shmin_defconfig
xtensa cadence_csp_defconfig
mips sb1250_swarm_defconfig
sh se7705_defconfig
powerpc amigaone_defconfig
arc nsim_700_defconfig
sh rts7751r2d1_defconfig
sh sh7757lcr_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a002-20200923
i386 randconfig-a006-20200923
i386 randconfig-a003-20200923
i386 randconfig-a004-20200923
i386 randconfig-a005-20200923
i386 randconfig-a001-20200923
x86_64 randconfig-a011-20200923
x86_64 randconfig-a013-20200923
x86_64 randconfig-a014-20200923
x86_64 randconfig-a015-20200923
x86_64 randconfig-a012-20200923
x86_64 randconfig-a016-20200923
i386 randconfig-a012-20200923
i386 randconfig-a014-20200923
i386 randconfig-a016-20200923
i386 randconfig-a013-20200923
i386 randconfig-a011-20200923
i386 randconfig-a015-20200923
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a005-20200923
x86_64 randconfig-a003-20200923
x86_64 randconfig-a004-20200923
x86_64 randconfig-a002-20200923
x86_64 randconfig-a006-20200923
x86_64 randconfig-a001-20200923
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
1 year, 9 months
[pm:bleeding-edge] BUILD SUCCESS fbcfd124b895172288ce3a0faafd9e54f8f15a7b
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: fbcfd124b895172288ce3a0faafd9e54f8f15a7b Merge branch 'pm-cpuidle-next' into bleeding-edge
elapsed time: 725m
configs tested: 89
configs skipped: 2
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
h8300 edosk2674_defconfig
powerpc xes_mpc85xx_defconfig
arm lart_defconfig
powerpc warp_defconfig
powerpc ep8248e_defconfig
sh secureedge5410_defconfig
powerpc ppc6xx_defconfig
sh se7619_defconfig
sh se7722_defconfig
arc haps_hs_smp_defconfig
powerpc fsp2_defconfig
mips maltasmvp_eva_defconfig
arm cns3420vb_defconfig
arc nps_defconfig
arm orion5x_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a002-20200923
i386 randconfig-a006-20200923
i386 randconfig-a003-20200923
i386 randconfig-a004-20200923
i386 randconfig-a005-20200923
i386 randconfig-a001-20200923
x86_64 randconfig-a011-20200923
x86_64 randconfig-a013-20200923
x86_64 randconfig-a014-20200923
x86_64 randconfig-a015-20200923
x86_64 randconfig-a012-20200923
x86_64 randconfig-a016-20200923
i386 randconfig-a012-20200923
i386 randconfig-a014-20200923
i386 randconfig-a016-20200923
i386 randconfig-a013-20200923
i386 randconfig-a011-20200923
i386 randconfig-a015-20200923
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a005-20200923
x86_64 randconfig-a003-20200923
x86_64 randconfig-a004-20200923
x86_64 randconfig-a002-20200923
x86_64 randconfig-a006-20200923
x86_64 randconfig-a001-20200923
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
1 year, 9 months
Re: [PATCH -next] ACPICA: Remove unneeded semicolon
by Moore, Robert
Got it, thanks.
Bob
-----Original Message-----
From: Zou Wei <zou_wei(a)huawei.com>
Sent: Tuesday, September 22, 2020 12:49 AM
To: Moore, Robert <robert.moore(a)intel.com>; Kaneda, Erik <erik.kaneda(a)intel.com>; Wysocki, Rafael J <rafael.j.wysocki(a)intel.com>; lenb(a)kernel.org
Cc: linux-acpi(a)vger.kernel.org; devel(a)acpica.org; linux-kernel(a)vger.kernel.org; Zou Wei <zou_wei(a)huawei.com>
Subject: [PATCH -next] ACPICA: Remove unneeded semicolon
Fixes coccicheck warning:
./drivers/acpi/acpica/nsalloc.c:297:2-3: Unneeded semicolon
Signed-off-by: Zou Wei <zou_wei(a)huawei.com>
---
drivers/acpi/acpica/nsalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/nsalloc.c b/drivers/acpi/acpica/nsalloc.c index fe9b363..83d26ab 100644
--- a/drivers/acpi/acpica/nsalloc.c
+++ b/drivers/acpi/acpica/nsalloc.c
@@ -294,7 +294,7 @@ void acpi_ns_delete_children(struct acpi_namespace_node *parent_node)
node_to_delete = next_node;
next_node = next_node->peer;
acpi_ns_delete_node(node_to_delete);
- };
+ }
/* Clear the parent's child pointer */
--
2.6.2
1 year, 9 months
[pm:bleeding-edge] BUILD SUCCESS f6c2526bd34bc27821a5c75d22b8ef4d386ffb7f
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: f6c2526bd34bc27821a5c75d22b8ef4d386ffb7f Merge branch 'pm-avs' into bleeding-edge
elapsed time: 721m
configs tested: 93
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm64 allyesconfig
arm64 defconfig
arm defconfig
arm allyesconfig
arm allmodconfig
mips ip28_defconfig
powerpc mpc834x_itxgp_defconfig
mips malta_kvm_defconfig
powerpc tqm8555_defconfig
mips lemote2f_defconfig
xtensa virt_defconfig
powerpc asp8347_defconfig
arc nsim_700_defconfig
arm vexpress_defconfig
arm spear13xx_defconfig
arm aspeed_g5_defconfig
mips loongson3_defconfig
mips decstation_r4k_defconfig
powerpc mpc836x_mds_defconfig
powerpc ep88xc_defconfig
arc nsimosci_hs_smp_defconfig
arm cns3420vb_defconfig
h8300 h8300h-sim_defconfig
powerpc mpc837x_rdb_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a002-20200921
i386 randconfig-a006-20200921
i386 randconfig-a003-20200921
i386 randconfig-a004-20200921
i386 randconfig-a005-20200921
i386 randconfig-a001-20200921
i386 randconfig-a012-20200921
i386 randconfig-a014-20200921
i386 randconfig-a016-20200921
i386 randconfig-a013-20200921
i386 randconfig-a011-20200921
i386 randconfig-a015-20200921
x86_64 randconfig-a005-20200922
x86_64 randconfig-a003-20200922
x86_64 randconfig-a004-20200922
x86_64 randconfig-a002-20200922
x86_64 randconfig-a006-20200922
x86_64 randconfig-a001-20200922
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a011-20200920
x86_64 randconfig-a013-20200920
x86_64 randconfig-a014-20200920
x86_64 randconfig-a015-20200920
x86_64 randconfig-a012-20200920
x86_64 randconfig-a016-20200920
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
1 year, 9 months