[RFC PATCH v2 0/8] ACPI/IORT: Support for IORT RMR node
by Shameer Kolothum
RFC v1 --> v2:
- Added a generic interface for IOMMU drivers to retrieve all the
RMR info associated with a given IOMMU.
- SMMUv3 driver gets the RMR list during probe() and installs
bypass STEs for all the SIDs in the RMR list. This is to keep
the ongoing traffic alive(if any) during SMMUv3 reset. This is
based on the suggestions received for v1 to take care of the
EFI framebuffer use case. Only sanity tested for now.
- During the probe/attach device, SMMUv3 driver reserves any
RMR region associated with the device such that there is a unity
mapping for them in SMMU.
---
The series adds support to IORT RMR nodes specified in IORT
Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
ranges that are used by endpoints and require a unity mapping
in SMMU.
We have faced issues with 3408iMR RAID controller cards which
fail to boot when SMMU is enabled. This is because these controllers
make use of host memory for various caching related purposes and when
SMMU is enabled the iMR firmware fails to access these memory regions
as there is no mapping for them. IORT RMR provides a way for UEFI to
describe and report these memory regions so that the kernel can make
a unity mapping for these in SMMU.
RFC because, Patch #1 is to update the actbl2.h and should be done
through acpica update. I have send out a pull request[1] for that.
Tests:
With a UEFI, that reports the RMR for the dev,
....
[16F0h 5872 1] Type : 06
[16F1h 5873 2] Length : 007C
[16F3h 5875 1] Revision : 00
[1038h 0056 2] Reserved : 00000000
[1038h 0056 2] Identifier : 00000000
[16F8h 5880 4] Mapping Count : 00000001
[16FCh 5884 4] Mapping Offset : 00000040
[1700h 5888 4] Number of RMR Descriptors : 00000002
[1704h 5892 4] RMR Descriptor Offset : 00000018
[1708h 5896 8] Base Address of RMR : 0000E6400000
[1710h 5904 8] Length of RMR : 000000100000
[1718h 5912 4] Reserved : 00000000
[171Ch 5916 8] Base Address of RMR : 0000000027B00000
[1724h 5924 8] Length of RMR : 0000000000C00000
[172Ch 5932 4] Reserved : 00000000
[1730h 5936 4] Input base : 00000000
[1734h 5940 4] ID Count : 00000001
[1738h 5944 4] Output Base : 00000003
[173Ch 5948 4] Output Reference : 00000064
[1740h 5952 4] Flags (decoded below) : 00000001
Single Mapping : 1
...
Without the series the RAID controller initialization fails as
below,
...
[ 12.631117] megaraid_sas 0000:03:00.0: FW supports sync cache : Yes
[ 12.637360] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009
[ 18.776377] megaraid_sas 0000:03:00.0: Init cmd return status FAILED for SCSI host 0
[ 23.019383] megaraid_sas 0000:03:00.0: Waiting for FW to come to ready state
[ 106.684281] megaraid_sas 0000:03:00.0: FW in FAULT state, Fault code:0x10000 subcode:0x0 func:megasas_transition_to_ready
[ 106.695186] megaraid_sas 0000:03:00.0: System Register set:
[ 106.889787] megaraid_sas 0000:03:00.0: Failed to transition controller to ready for scsi0.
[ 106.910475] megaraid_sas 0000:03:00.0: Failed from megasas_init_fw 6407
estuary:/$
With the series, now the kernel has direct mapping for the dev as
below,
estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions
0x0000000008000000 0x00000000080fffff msi
0x0000000027b00000 0x00000000286fffff direct
0x00000000e6400000 0x00000000e64fffff direct
estuary:/$
....
[ 12.254318] megaraid_sas 0000:03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x40000009
[ 12.739089] megaraid_sas 0000:03:00.0: FW provided supportMaxExtLDs: 0 max_lds: 32
[ 12.746628] megaraid_sas 0000:03:00.0: controller type : iMR(0MB)
[ 12.752694] megaraid_sas 0000:03:00.0: Online Controller Reset(OCR) : Enabled
[ 12.759798] megaraid_sas 0000:03:00.0: Secure JBOD support : Yes
[ 12.765778] megaraid_sas 0000:03:00.0: NVMe passthru support : Yes
[ 12.771931] megaraid_sas 0000:03:00.0: FW provided TM TaskAbort/Reset timeou: 6 secs/60 secs
[ 12.780503] megaraid_sas 0000:03:00.0: JBOD sequence map support : Yes
[ 12.787000] megaraid_sas 0000:03:00.0: PCI Lane Margining support : No
[ 12.819179] megaraid_sas 0000:03:00.0: NVME page size : (4096)
[ 12.825672] megaraid_sas 0000:03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x40000000
[ 12.835199] megaraid_sas 0000:03:00.0: INIT adapter done
[ 12.873932] megaraid_sas 0000:03:00.0: pci id : (0x1000)/(0x0017)/(0x19e5)/(0xd213)
[ 12.881644] megaraid_sas 0000:03:00.0: unevenspan support : no
[ 12.887451] megaraid_sas 0000:03:00.0: firmware crash dump : no
[ 12.893344] megaraid_sas 0000:03:00.0: JBOD sequence map : enabled
RAID controller init is now success and can detect the drives
attached as well.
Thanks,
Shameer
[0]. https://developer.arm.com/documentation/den0049/latest/
[1]. https://github.com/acpica/acpica/pull/638
Shameer Kolothum (8):
ACPICA: IORT: Update for revision E
ACPI/IORT: Add support for RMR node parsing
iommu/dma: Introduce generic helper to retrieve RMR info
ACPI/IORT: Add RMR memory regions reservation helper
iommu/arm-smmu-v3: Introduce strtab init helper
iommu/arm-smmu-v3: Add bypass flag to arm_smmu_write_strtab_ent()
iommu/arm-smmu-v3: Get associated RMR info and install bypass STE
iommu/arm-smmu-v3: Reserve any RMR regions associated with a dev
drivers/acpi/arm64/iort.c | 182 +++++++++++++++++++-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 112 ++++++++++--
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 2 +
drivers/iommu/dma-iommu.c | 39 +++++
include/acpi/actbl2.h | 25 ++-
include/linux/acpi_iort.h | 6 +
include/linux/dma-iommu.h | 7 +
include/linux/iommu.h | 16 ++
8 files changed, 367 insertions(+), 22 deletions(-)
--
2.17.1
1 month, 3 weeks
[pm:bleeding-edge] BUILD SUCCESS e86d494782b7e43504b343d37b88c5c1d7af9ff6
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: e86d494782b7e43504b343d37b88c5c1d7af9ff6 Merge branch 'pnp' into linux-next
elapsed time: 724m
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
nios2 3c120_defconfig
powerpc tqm5200_defconfig
arm rpc_defconfig
mips maltaup_xpa_defconfig
powerpc tqm8540_defconfig
sh edosk7705_defconfig
arm imx_v4_v5_defconfig
riscv allnoconfig
m68k sun3_defconfig
riscv allmodconfig
arm colibri_pxa300_defconfig
x86_64 allyesconfig
powerpc mpc8315_rdb_defconfig
arm pxa_defconfig
arm omap2plus_defconfig
powerpc xes_mpc85xx_defconfig
arm lubbock_defconfig
microblaze defconfig
xtensa cadence_csp_defconfig
mips rt305x_defconfig
sh kfr2r09_defconfig
arc nsimosci_hs_smp_defconfig
arm jornada720_defconfig
arc axs101_defconfig
powerpc mpc8540_ads_defconfig
sh j2_defconfig
arm ep93xx_defconfig
sh dreamcast_defconfig
sh rsk7203_defconfig
arm tct_hammer_defconfig
powerpc mvme5100_defconfig
sh se7712_defconfig
c6x evmc6474_defconfig
arm shannon_defconfig
mips pistachio_defconfig
arm multi_v5_defconfig
mips ath79_defconfig
sh se7721_defconfig
mips cu1830-neo_defconfig
xtensa xip_kc705_defconfig
powerpc walnut_defconfig
sh sh03_defconfig
arc nsim_700_defconfig
sh ecovec24_defconfig
xtensa virt_defconfig
powerpc amigaone_defconfig
mips pic32mzda_defconfig
powerpc asp8347_defconfig
sh sh7770_generic_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nds32 allnoconfig
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 tinyconfig
i386 defconfig
arc allyesconfig
c6x allyesconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20210130
i386 randconfig-a003-20210130
i386 randconfig-a002-20210130
i386 randconfig-a001-20210130
i386 randconfig-a004-20210130
i386 randconfig-a006-20210130
i386 randconfig-a013-20210130
i386 randconfig-a011-20210130
i386 randconfig-a015-20210130
i386 randconfig-a012-20210130
i386 randconfig-a014-20210130
i386 randconfig-a016-20210130
x86_64 randconfig-a004-20210130
x86_64 randconfig-a002-20210130
x86_64 randconfig-a001-20210130
x86_64 randconfig-a005-20210130
x86_64 randconfig-a006-20210130
x86_64 randconfig-a003-20210130
riscv allyesconfig
riscv defconfig
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
x86_64 rhel
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a015-20210130
x86_64 randconfig-a011-20210130
x86_64 randconfig-a014-20210130
x86_64 randconfig-a016-20210130
x86_64 randconfig-a012-20210130
x86_64 randconfig-a013-20210130
x86_64 randconfig-a012-20210129
x86_64 randconfig-a015-20210129
x86_64 randconfig-a016-20210129
x86_64 randconfig-a011-20210129
x86_64 randconfig-a013-20210129
x86_64 randconfig-a014-20210129
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
3 months, 2 weeks
[pm:bleeding-edge] BUILD SUCCESS d8eafbfd2e76d83b8740c90ab8466243c93d61b4
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: d8eafbfd2e76d83b8740c90ab8466243c93d61b4 Merge branch 'pm-clk' into bleeding-edge
elapsed time: 732m
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
powerpc mgcoge_defconfig
powerpc g5_defconfig
arm aspeed_g4_defconfig
c6x evmc6678_defconfig
mips malta_defconfig
arc tb10x_defconfig
powerpc mpc885_ads_defconfig
nios2 3c120_defconfig
powerpc xes_mpc85xx_defconfig
powerpc mpc8313_rdb_defconfig
arc hsdk_defconfig
mips bcm63xx_defconfig
mips cavium_octeon_defconfig
sparc allyesconfig
powerpc storcenter_defconfig
x86_64 defconfig
m68k defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
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 defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210128
i386 randconfig-a002-20210128
i386 randconfig-a004-20210128
i386 randconfig-a005-20210128
i386 randconfig-a003-20210128
i386 randconfig-a006-20210128
x86_64 randconfig-a012-20210128
x86_64 randconfig-a015-20210128
x86_64 randconfig-a016-20210128
x86_64 randconfig-a011-20210128
x86_64 randconfig-a013-20210128
x86_64 randconfig-a014-20210128
i386 randconfig-a013-20210128
i386 randconfig-a011-20210128
i386 randconfig-a012-20210128
i386 randconfig-a016-20210128
i386 randconfig-a014-20210128
i386 randconfig-a015-20210128
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 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20210128
x86_64 randconfig-a003-20210128
x86_64 randconfig-a001-20210128
x86_64 randconfig-a005-20210128
x86_64 randconfig-a006-20210128
x86_64 randconfig-a004-20210128
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
3 months, 2 weeks
[pm:bleeding-edge] BUILD SUCCESS d1182f4c1fbc5ad585d78a03d515792aaa3534fd
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: d1182f4c1fbc5ad585d78a03d515792aaa3534fd Merge branch 'acpi-messages' into bleeding-edge
elapsed time: 726m
configs tested: 97
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 secureedge5410_defconfig
c6x dsk6455_defconfig
mips qi_lb60_defconfig
sparc64 defconfig
arm xcep_defconfig
arm lpc32xx_defconfig
sh se7722_defconfig
mips db1xxx_defconfig
m68k m5249evb_defconfig
powerpc g5_defconfig
sh se7343_defconfig
powerpc motionpro_defconfig
i386 alldefconfig
mips maltasmvp_eva_defconfig
sh sh7770_generic_defconfig
mips ath25_defconfig
sh polaris_defconfig
arm corgi_defconfig
powerpc walnut_defconfig
arm mvebu_v7_defconfig
mips mpc30x_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210125
i386 randconfig-a002-20210125
i386 randconfig-a004-20210125
i386 randconfig-a006-20210125
i386 randconfig-a005-20210125
i386 randconfig-a003-20210125
x86_64 randconfig-a012-20210126
x86_64 randconfig-a016-20210126
x86_64 randconfig-a015-20210126
x86_64 randconfig-a011-20210126
x86_64 randconfig-a013-20210126
x86_64 randconfig-a014-20210126
i386 randconfig-a013-20210125
i386 randconfig-a011-20210125
i386 randconfig-a012-20210125
i386 randconfig-a015-20210125
i386 randconfig-a014-20210125
i386 randconfig-a016-20210125
x86_64 randconfig-a003-20210125
x86_64 randconfig-a002-20210125
x86_64 randconfig-a001-20210125
x86_64 randconfig-a005-20210125
x86_64 randconfig-a006-20210125
x86_64 randconfig-a004-20210125
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 rhel-8.3-kbuiltin
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
3 months, 3 weeks
Re: [PATCH] ACPICA: Common: Fix a typo
by Rafael J. Wysocki
On Sun, Jan 24, 2021 at 12:35 PM Christophe JAILLET
<christophe.jaillet(a)wanadoo.fr> wrote:
>
> This module is 'cmfsize', not 'cfsize'.
> Fix it.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
I'm leaving this one to Bob and Erik, thanks!
> ---
> tools/power/acpi/common/cmfsize.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/power/acpi/common/cmfsize.c b/tools/power/acpi/common/cmfsize.c
> index 9ea2c0aeb86c..185b8c588e1d 100644
> --- a/tools/power/acpi/common/cmfsize.c
> +++ b/tools/power/acpi/common/cmfsize.c
> @@ -1,7 +1,7 @@
> // SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
> /******************************************************************************
> *
> - * Module Name: cfsize - Common get file size function
> + * Module Name: cmfsize - Common get file size function
> *
> * Copyright (C) 2000 - 2021, Intel Corp.
> *
> --
> 2.27.0
>
3 months, 3 weeks
Re: power-off delay/hang due to commit 6d25be57 (mainline)
by Rafael J. Wysocki
On Sun, Jan 24, 2021 at 2:49 PM Stephen Berman <stephen.berman(a)gmx.net> wrote:
>
> On Mon, 04 Jan 2021 16:38:43 +0100 Stephen Berman <stephen.berman(a)gmx.net> wrote:
>
> > On Thu, 31 Dec 2020 21:46:11 +0100 "Rafael J. Wysocki" <rjw(a)rjwysocki.net> wrote:
> >
> >> ATM, I'm tempted to do something like the patch below (with the rationale
> >> that it shouldn't be necessary to read the temperature right after updating
> >> the trip points if polling is in use, because the next update through polling
> >> will cause it to be read anyway and it will trigger trip point actions as
> >> needed).
> >>
> >> Stephen, can you give it a go, please?
> >
> > On Sat, 02 Jan 2021 12:03:17 +0100 "Rafael J. Wysocki" <rjw(a)rjwysocki.net> wrote:
> >
> >> There is one more way to address this, probably better: instead of checking the
> >> temperature right away in acpi_thermal_notify(), queue that on
> >> acpi_thermal_pm_queue
> >> and so only if another thermal check is not pending.
> >>
> >> This way there will be at most one temperature check coming from
> >> acpi_thermal_notify() queued up at any time which should prevent the
> >> build-up of work items from taking place.
> >>
> >> So something like this:
> >
> > Thanks for the patches. I'll try them as soon as I can.
>
> FTR, since this is the thread I started for this bug, I've confirmed in
> https://lore.kernel.org/lkml/87y2gi78sg.fsf@gmx.net/T/#t that the latest
> patch fixes the bug.
OK, thanks!
The patch has been applied as 5.11-rc material.
3 months, 3 weeks
[pm:bleeding-edge] BUILD SUCCESS WITH WARNING a44d3fbdfbd1dde8c1726ba55638767fa359103d
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: a44d3fbdfbd1dde8c1726ba55638767fa359103d Merge branch 'pm-domains' into bleeding-edge
Warning ids grouped by kconfigs:
gcc_recent_errors
|-- i386-randconfig-s002-20210124
| `-- drivers-base-power-clock_ops.c:sparse:sparse:context-imbalance-in-pm_clk_list_unlock-wrong-count-at-exit
|-- x86_64-randconfig-s021-20210124
| `-- drivers-base-power-clock_ops.c:sparse:sparse:context-imbalance-in-pm_clk_list_unlock-wrong-count-at-exit
`-- x86_64-randconfig-s022-20210124
`-- drivers-base-power-clock_ops.c:sparse:sparse:context-imbalance-in-pm_clk_list_unlock-wrong-count-at-exit
elapsed time: 737m
configs tested: 95
configs skipped: 2
gcc tested configs:
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm defconfig
mips malta_kvm_guest_defconfig
mips malta_qemu_32r6_defconfig
arm pcm027_defconfig
sparc64 defconfig
arm netwinder_defconfig
powerpc sam440ep_defconfig
sh se7206_defconfig
mips bigsur_defconfig
mips mpc30x_defconfig
mips ath79_defconfig
xtensa smp_lx200_defconfig
mips loongson3_defconfig
powerpc mpc512x_defconfig
sh rsk7269_defconfig
mips mtx1_defconfig
powerpc asp8347_defconfig
powerpc wii_defconfig
powerpc canyonlands_defconfig
sh sh2007_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
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210124
i386 randconfig-a002-20210124
i386 randconfig-a004-20210124
i386 randconfig-a006-20210124
i386 randconfig-a005-20210124
i386 randconfig-a003-20210124
x86_64 randconfig-a012-20210124
x86_64 randconfig-a016-20210124
x86_64 randconfig-a015-20210124
x86_64 randconfig-a011-20210124
x86_64 randconfig-a013-20210124
x86_64 randconfig-a014-20210124
i386 randconfig-a013-20210124
i386 randconfig-a011-20210124
i386 randconfig-a012-20210124
i386 randconfig-a015-20210124
i386 randconfig-a014-20210124
i386 randconfig-a016-20210124
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 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a003-20210124
x86_64 randconfig-a002-20210124
x86_64 randconfig-a001-20210124
x86_64 randconfig-a005-20210124
x86_64 randconfig-a006-20210124
x86_64 randconfig-a004-20210124
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
3 months, 3 weeks
[pm:bleeding-edge] BUILD SUCCESS WITH WARNING 33b4fa8533186db3c463120ced43b1c12ecba18d
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 33b4fa8533186db3c463120ced43b1c12ecba18d Merge branch 'acpi-platform' into bleeding-edge
Warning ids grouped by kconfigs:
gcc_recent_errors
`-- x86_64-randconfig-s022-20210122
`-- include-linux-spinlock.h:sparse:sparse:context-imbalance-in-pm_clk_list_lock-wrong-count-at-exit
elapsed time: 722m
configs tested: 89
configs skipped: 2
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc motionpro_defconfig
c6x evmc6457_defconfig
mips tb0226_defconfig
mips ip22_defconfig
powerpc icon_defconfig
mips nlm_xlp_defconfig
xtensa generic_kc705_defconfig
powerpc socrates_defconfig
m68k atari_defconfig
arm mxs_defconfig
powerpc currituck_defconfig
arm trizeps4_defconfig
powerpc mpc834x_itx_defconfig
arm shmobile_defconfig
um x86_64_defconfig
arc nsimosci_defconfig
m68k m5208evb_defconfig
arm lpc32xx_defconfig
sh se7780_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 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210121
i386 randconfig-a002-20210121
i386 randconfig-a004-20210121
i386 randconfig-a006-20210121
i386 randconfig-a005-20210121
i386 randconfig-a003-20210121
i386 randconfig-a013-20210121
i386 randconfig-a011-20210121
i386 randconfig-a012-20210121
i386 randconfig-a014-20210121
i386 randconfig-a015-20210121
i386 randconfig-a016-20210121
x86_64 randconfig-a002-20210121
x86_64 randconfig-a003-20210121
x86_64 randconfig-a001-20210121
x86_64 randconfig-a005-20210121
x86_64 randconfig-a006-20210121
x86_64 randconfig-a004-20210121
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 rhel-8.3-kbuiltin
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
3 months, 3 weeks
Re: [PATCH] ACPICA: fix -Wfallthrough
by Rafael J. Wysocki
On Thu, Jan 21, 2021 at 11:08 AM Jon Hunter <jonathanh(a)nvidia.com> wrote:
>
>
> On 11/11/2020 02:11, Nick Desaulniers wrote:
> > The "fallthrough" pseudo-keyword was added as a portable way to denote
> > intentional fallthrough. This code seemed to be using a mix of
> > fallthrough comments that GCC recognizes, and some kind of lint marker.
> > I'm guessing that linter hasn't been run in a while from the mixed use
> > of the marker vs comments.
> >
> > Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
>
>
> I know this is not the exact version that was merged, I can't find it on
> the list, but looks like the version that was merged [0],
It would be this patch:
https://patchwork.kernel.org/project/linux-acpi/patch/20210115184826.2250...
Nick, Erik?
> is causing build errors with older toolchains (GCC v6) ...
>
> /dvs/git/dirty/git-master_l4t-upstream/kernel/drivers/acpi/acpica/dscontrol.c: In function ‘acpi_ds_exec_begin_control_op’:
> /dvs/git/dirty/git-master_l4t-upstream/kernel/drivers/acpi/acpica/dscontrol.c:65:3: error: ‘ACPI_FALLTHROUGH’ undeclared (first use in this function)
> ACPI_FALLTHROUGH;
> ^~~~~~~~~~~~~~~~
> /dvs/git/dirty/git-master_l4t-upstream/kernel/drivers/acpi/acpica/dscontrol.c:65:3: note: each undeclared identifier is reported only once for each function it appears in
> /dvs/git/dirty/git-master_l4t-upstream/kernel/scripts/Makefile.build:287: recipe for target 'drivers/acpi/acpica/dscontrol.o' failed
>
> Cheers
> Jon
>
> [0] https://github.com/acpica/acpica/commit/4b9135f5
>
> --
> nvpublic
3 months, 3 weeks
Re: [PATCH v2 2/7] acpi: utils: Add function to fetch dependent acpi_devices
by Rafael J. Wysocki
On Thu, Jan 21, 2021 at 5:34 PM Daniel Scally <djrscally(a)gmail.com> wrote:
>
>
> On 21/01/2021 14:39, Rafael J. Wysocki wrote:
> > On Thu, Jan 21, 2021 at 1:04 PM Daniel Scally <djrscally(a)gmail.com> wrote:
> >>
> >> On 21/01/2021 11:58, Rafael J. Wysocki wrote:
> >>> On Thu, Jan 21, 2021 at 10:47 AM Daniel Scally <djrscally(a)gmail.com> wrote:
> >>>> Hi Rafael
> >>>>
> >>>> On 19/01/2021 13:15, Rafael J. Wysocki wrote:
> >>>>> On Mon, Jan 18, 2021 at 9:51 PM Daniel Scally <djrscally(a)gmail.com> wrote:
> >>>>>> On 18/01/2021 16:14, Rafael J. Wysocki wrote:
> >>>>>>> On Mon, Jan 18, 2021 at 1:37 AM Daniel Scally <djrscally(a)gmail.com> wrote:
> >>>>>>>> In some ACPI tables we encounter, devices use the _DEP method to assert
> >>>>>>>> a dependence on other ACPI devices as opposed to the OpRegions that the
> >>>>>>>> specification intends. We need to be able to find those devices "from"
> >>>>>>>> the dependee, so add a function to parse all ACPI Devices and check if
> >>>>>>>> the include the handle of the dependee device in their _DEP buffer.
> >>>>>>> What exactly do you need this for?
> >>>>>> So, in our DSDT we have devices with _HID INT3472, plus sensors which
> >>>>>> refer to those INT3472's in their _DEP method. The driver binds to the
> >>>>>> INT3472 device, we need to find the sensors dependent on them.
> >>>>>>
> >>>>> Well, this is an interesting concept. :-)
> >>>>>
> >>>>> Why does _DEP need to be used for that? Isn't there any other way to
> >>>>> look up the dependent sensors?
> >>>>>
> >>>>>>> Would it be practical to look up the suppliers in acpi_dep_list instead?
> >>>>>>>
> >>>>>>> Note that supplier drivers may remove entries from there, but does
> >>>>>>> that matter for your use case?
> >>>>>> Ah - that may work, yes. Thank you, let me test that.
> >>>>> Even if that doesn't work right away, but it can be made work, I would
> >>>>> very much prefer that to the driver parsing _DEP for every device in
> >>>>> the namespace by itself.
> >>>> This does work; do you prefer it in scan.c, or in utils.c (in which case
> >>>> with acpi_dep_list declared as external var in internal.h)?
> >>> Let's put it in scan.c for now, because there is the lock protecting
> >>> the list in there too.
> >>>
> >>> How do you want to implement this? Something like "walk the list and
> >>> run a callback for the matching entries" or do you have something else
> >>> in mind?
> >>
> >> Something like this (though with a mutex_lock()). It could be simplified
> >> by dropping the prev stuff, but we have seen INT3472 devices with
> >> multiple sensors declaring themselves dependent on the same device
> >>
> >>
> >> struct acpi_device *
> >> acpi_dev_get_next_dependent_dev(struct acpi_device *supplier,
> >> struct acpi_device *prev)
> >> {
> >> struct acpi_dep_data *dep;
> >> struct acpi_device *adev;
> >> int ret;
> >>
> >> if (!supplier)
> >> return ERR_PTR(-EINVAL);
> >>
> >> if (prev) {
> >> /*
> >> * We need to find the previous device in the list, so we know
> >> * where to start iterating from.
> >> */
> >> list_for_each_entry(dep, &acpi_dep_list, node)
> >> if (dep->consumer == prev->handle &&
> >> dep->supplier == supplier->handle)
> >> break;
> >>
> >> dep = list_next_entry(dep, node);
> >> } else {
> >> dep = list_first_entry(&acpi_dep_list, struct acpi_dep_data,
> >> node);
> >> }
> >>
> >>
> >> list_for_each_entry_from(dep, &acpi_dep_list, node) {
> >> if (dep->supplier == supplier->handle) {
> >> ret = acpi_bus_get_device(dep->consumer, &adev);
> >> if (ret)
> >> return ERR_PTR(ret);
> >>
> >> return adev;
> >> }
> >> }
> >>
> >> return NULL;
> >> }
> > That would work I think, but would it be practical to modify
> > acpi_walk_dep_device_list() so that it runs a callback for every
> > consumer found instead of or in addition to the "delete from the list
> > and free the entry" operation?
>
>
> I think that this would work fine, if that's the way you want to go.
> We'd just need to move everything inside the if (dep->supplier ==
> handle) block to a new callback, and for my purposes I think also add a
> way to stop parsing the list from the callback (so like have the
> callbacks return int and stop parsing on a non-zero return). Do you want
> to expose that ability to pass a callback outside of ACPI?
Yes.
> Or just export helpers to call each of the callbacks (one to fetch the next
> dependent device, one to decrement the unmet dependencies counter)
If you can run a callback for every matching entry, you don't really
need to have a callback to return the next matching entry. You can do
stuff for all of them in one go (note that it probably is not a good
idea to run the callback under the lock, so the for loop currently in
there is not really suitable for that).
> Otherwise, I'd just need to update the 5 users of that function either
> to use the new helper or else to also pass the decrement dependencies
> callback.
Or have a wrapper around it passing the decrement dependencies
callback for the "typical" users.
3 months, 3 weeks