[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 year, 3 months
Re: power-off delay/hang due to commit 6d25be57 (mainline)
by Rafael J. Wysocki
On Wed, Dec 2, 2020 at 7:03 PM Sebastian Andrzej Siewior
<bigeasy(a)linutronix.de> wrote:
>
> On 2020-10-26 18:20:59 [+0100], To Rafael J. Wysocki wrote:
> > > > > > Done as Bug 208877.
> > > > Rafael, do you have any suggestions?
> > >
> > > I've lost track of this sorry.
> > >
> > > I have ideas, let me get back to this next week.
> >
> > :)
>
> Rafael, any update? If you outline an idea or so then I may be able to
> form a patch out of it. Otherwise I have no idea how to fix this - other
> than telling the driver to not poll in smaller intervals than
> 30secs.
The idea, roughly speaking, is to limit the number of outstanding work
items in the queue (basically, if there's a notification occurring
before the previous one can be handled, there is no need to queue up
another work item for it).
1 year, 6 months
[pm:bleeding-edge] BUILD SUCCESS WITH WARNING 2e19c856a4614c113119f3f4d4795b190c5c828f
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 2e19c856a4614c113119f3f4d4795b190c5c828f Merge branch 'acpi-platform' into bleeding-edge
Warning reports:
https://lore.kernel.org/linux-acpi/[email protected]
Warning in current branch:
drivers/acpi/x86/s2idle.c:108:30: warning: variable 'info' set but not used [-Wunused-but-set-variable]
drivers/acpi/x86/s2idle.c:138:25: warning: variable 'obj_new' set but not used [-Wunused-but-set-variable]
Warning ids grouped by kconfigs:
gcc_recent_errors
|-- i386-allyesconfig
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- i386-defconfig
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- i386-randconfig-a011-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- i386-randconfig-a012-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- i386-randconfig-a013-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- i386-randconfig-a015-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- i386-randconfig-a016-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- i386-randconfig-m021-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- i386-randconfig-p002-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-allyesconfig
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-defconfig
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-kexec
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-randconfig-a001-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-randconfig-a003-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-randconfig-a005-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-randconfig-a006-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-randconfig-s022-20201230
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-rhel
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-rhel-7.6-kselftests
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-rhel-8.3
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
`-- x86_64-rhel-8.3-kbuiltin
|-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
`-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
elapsed time: 725m
configs tested: 95
configs skipped: 2
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
sh rts7751r2d1_defconfig
m68k alldefconfig
m68k m5407c3_defconfig
sh shmin_defconfig
arm s3c6400_defconfig
mips rs90_defconfig
h8300 h8300h-sim_defconfig
sh shx3_defconfig
mips sb1250_swarm_defconfig
powerpc akebono_defconfig
powerpc obs600_defconfig
powerpc klondike_defconfig
arm mvebu_v5_defconfig
s390 alldefconfig
sh rts7751r2dplus_defconfig
powerpc sam440ep_defconfig
arc haps_hs_smp_defconfig
ia64 alldefconfig
sh sh7710voipgw_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-a005-20201230
i386 randconfig-a006-20201230
i386 randconfig-a004-20201230
i386 randconfig-a003-20201230
i386 randconfig-a002-20201230
i386 randconfig-a001-20201230
i386 randconfig-a016-20201230
i386 randconfig-a014-20201230
i386 randconfig-a012-20201230
i386 randconfig-a015-20201230
i386 randconfig-a011-20201230
i386 randconfig-a013-20201230
x86_64 randconfig-a005-20201230
x86_64 randconfig-a001-20201230
x86_64 randconfig-a006-20201230
x86_64 randconfig-a002-20201230
x86_64 randconfig-a004-20201230
x86_64 randconfig-a003-20201230
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-a015-20201230
x86_64 randconfig-a014-20201230
x86_64 randconfig-a016-20201230
x86_64 randconfig-a011-20201230
x86_64 randconfig-a013-20201230
x86_64 randconfig-a012-20201230
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
1 year, 6 months
Re: [PATCH v3 14/14] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver
by Andy Shevchenko
On Tue, Dec 29, 2020 at 2:07 AM Laurent Pinchart
<laurent.pinchart(a)ideasonboard.com> wrote:
> On Tue, Dec 29, 2020 at 01:54:59AM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 29, 2020 at 1:08 AM Laurent Pinchart wrote:
...
> > +#include <linux/videodev2.h>
>
> I think this can be dropped.
I dropped above (I noticed it's included by a half of the headers listed below.
> > +#include <media/media-device.h>
> > +#include <media/media-entity.h>
> > +#include <media/v4l2-async.h>
> > +#include <media/v4l2-dev.h>
> > +#include <media/v4l2-device.h>
> > +#include <media/v4l2-subdev.h>
> > +#include <media/videobuf2-core.h>
> > +#include <media/videobuf2-v4l2.h>
...
> How about grouping all forward declarations at the top ?
Done.
> Otherwise this looks good,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Thanks!
I just sent a formal patch with your tag included.
--
With Best Regards,
Andy Shevchenko
1 year, 6 months
[pm:bleeding-edge] BUILD REGRESSION 0c7a6fd3a0e835b0158a1f52176f5d3858fac110
by kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 0c7a6fd3a0e835b0158a1f52176f5d3858fac110 Merge branch 'pm-cpuidle-next' into bleeding-edge
Error/Warning reports:
https://lore.kernel.org/linux-acpi/[email protected]
https://lore.kernel.org/linux-acpi/[email protected]
https://lore.kernel.org/linux-acpi/[email protected]
https://lore.kernel.org/linux-acpi/[email protected]
Error/Warning in current branch:
drivers/acpi/platform_profile.c:147:24: warning: address of array 'pprof->choices' will always evaluate to 'true' [-Wpointer-bool-conversion]
drivers/acpi/x86/s2idle.c:108:30: warning: variable 'info' set but not used [-Wunused-but-set-variable]
drivers/acpi/x86/s2idle.c:138:25: warning: variable 'obj_new' set but not used [-Wunused-but-set-variable]
dtpm.c:(.text+0x24c): undefined reference to `__udivdi3'
dtpm.c:(.text+0x2a4): undefined reference to `__udivdi3'
dtpm.c:(.text+0x3bc): undefined reference to `__udivdi3'
dtpm.c:(.text+0x514): undefined reference to `__aeabi_uldivmod'
dtpm.c:(.text+0x52d): undefined reference to `__udivdi3'
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- arm-allmodconfig
| `-- dtpm.c:(.text):undefined-reference-to-__aeabi_uldivmod
|-- arm-allyesconfig
| `-- dtpm.c:(.text):undefined-reference-to-__aeabi_uldivmod
|-- h8300-allmodconfig
| `-- dtpm.c:(.text):undefined-reference-to-__udivdi3
|-- h8300-allyesconfig
| `-- dtpm.c:(.text):undefined-reference-to-__udivdi3
|-- i386-allyesconfig
| `-- dtpm.c:(.text):undefined-reference-to-__udivdi3
|-- i386-randconfig-a006-20201229
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- i386-randconfig-r002-20201229
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- i386-randconfig-s001-20201229
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- m68k-allmodconfig
| `-- dtpm.c:(.text):undefined-reference-to-__udivdi3
|-- m68k-allyesconfig
| `-- dtpm.c:(.text):undefined-reference-to-__udivdi3
|-- sh-allmodconfig
| `-- dtpm.c:(.text):undefined-reference-to-__udivdi3
|-- x86_64-randconfig-a002-20201229
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
|-- x86_64-randconfig-a004-20201229
| |-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
| `-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
`-- x86_64-randconfig-s021-20201229
|-- drivers-acpi-x86-s2idle.c:warning:variable-info-set-but-not-used
`-- drivers-acpi-x86-s2idle.c:warning:variable-obj_new-set-but-not-used
clang_recent_errors
|-- x86_64-randconfig-a011-20201229
| `-- drivers-acpi-platform_profile.c:warning:address-of-array-pprof-choices-will-always-evaluate-to-true
|-- x86_64-randconfig-a012-20201229
| `-- drivers-acpi-platform_profile.c:warning:address-of-array-pprof-choices-will-always-evaluate-to-true
|-- x86_64-randconfig-a013-20201229
| `-- drivers-acpi-platform_profile.c:warning:address-of-array-pprof-choices-will-always-evaluate-to-true
|-- x86_64-randconfig-a014-20201229
| `-- drivers-acpi-platform_profile.c:warning:address-of-array-pprof-choices-will-always-evaluate-to-true
|-- x86_64-randconfig-a015-20201229
| `-- drivers-acpi-platform_profile.c:warning:address-of-array-pprof-choices-will-always-evaluate-to-true
`-- x86_64-randconfig-a016-20201229
`-- drivers-acpi-platform_profile.c:warning:address-of-array-pprof-choices-will-always-evaluate-to-true
elapsed time: 724m
configs tested: 95
configs skipped: 2
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
sh se7619_defconfig
sh sh7785lcr_defconfig
arm trizeps4_defconfig
mips workpad_defconfig
um x86_64_defconfig
mips cu1000-neo_defconfig
m68k sun3x_defconfig
mips bcm47xx_defconfig
arm mps2_defconfig
mips tb0287_defconfig
s390 debug_defconfig
arm sama5_defconfig
arm s3c2410_defconfig
arm lpc18xx_defconfig
sh microdev_defconfig
arm s5pv210_defconfig
mips tb0226_defconfig
arm pxa910_defconfig
c6x evmc6474_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
x86_64 randconfig-a001-20201229
x86_64 randconfig-a006-20201229
x86_64 randconfig-a002-20201229
x86_64 randconfig-a004-20201229
x86_64 randconfig-a003-20201229
x86_64 randconfig-a005-20201229
i386 randconfig-a002-20201229
i386 randconfig-a005-20201229
i386 randconfig-a004-20201229
i386 randconfig-a006-20201229
i386 randconfig-a003-20201229
i386 randconfig-a001-20201229
i386 randconfig-a014-20201229
i386 randconfig-a012-20201229
i386 randconfig-a011-20201229
i386 randconfig-a016-20201229
i386 randconfig-a015-20201229
i386 randconfig-a013-20201229
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-a014-20201229
x86_64 randconfig-a015-20201229
x86_64 randconfig-a016-20201229
x86_64 randconfig-a012-20201229
x86_64 randconfig-a011-20201229
x86_64 randconfig-a013-20201229
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
1 year, 6 months
Re: [External] Re: [pm:bleeding-edge 8612/8615] drivers/acpi/platform_profile.c:147:24: warning: address of array 'pprof->choices' will always evaluate to 'true'
by Rafael J. Wysocki
On Tue, Dec 29, 2020 at 4:36 PM Mark Pearson <markpearson(a)lenovo.com> wrote:
>
> Hi Rafael
>
> On 29/12/2020 10:23, Rafael J. Wysocki wrote:
> > On Tue, Dec 29, 2020 at 12:18 AM Mark Pearson <markpearson(a)lenovo.com> wrote:
> >>
> >> Hi Hans
> >>
> >> On 27/12/2020 06:56, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 12/27/20 6:11 AM, kernel test robot wrote:
> >>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
> >>>> head: a33520709645543f108361fe21fa9434a351c4e9
> >>>> commit: 8c9b909fb1282e43792433e6c1cba125ccfc6201 [8612/8615] ACPI: platform-profile: Add platform profile support
> >>>> config: x86_64-randconfig-a015-20201221 (attached as .config)
> >>>> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project cee1e7d14f4628d6174b33640d502bff3b54ae45)
> >>>> 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
> >>>> # install x86_64 cross compiling tool for clang build
> >>>> # apt-get install binutils-x86-64-linux-gnu
> >>>> # 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 bleeding-edge
> >>>> git checkout 8c9b909fb1282e43792433e6c1cba125ccfc6201
> >>>> # save the attached .config to linux build tree
> >>>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
> >>>>
> >>>> 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 >>):
> >>>>
> >>>>>> drivers/acpi/platform_profile.c:147:24: warning: address of array 'pprof->choices' will always evaluate to 'true' [-Wpointer-bool-conversion]
> >>>> if (!pprof || !pprof->choices || !pprof->profile_set ||
> >>>> ~~~~~~~~^~~~~~~
> >>>> 1 warning generated.
> >>>
> >>>
> >>> Ah, this is caused by changing choices from a single long to:
> >>>
> >>> unsigned long choices[BITS_TO_LONGS(PLATFORM_PROFILE_LAST)];
> >>>
> >>> So that we can use for_each_set_bit and are future proof for more then
> >>> 32 profiles.
> >>>
> >>> To fix this the check should be changed into this (untested):
> >>>
> >>> #include <linux/bitmap.h>
> >>>
> >>> if (!pprof || bitmap_empty(pprof->choices, PLATFORM_PROFILE_LAST) ||
> >>> !pprof->profile_set || !pprof->profile_get) {
> >>> mutex_unlock(&profile_lock);
> >>> return -EINVAL;
> >>> }
> >>>
> >>> Mark can you provide a (tested) patch for this?
> >>>
> >>> Regards,
> >>>
> >>> Hans
> >>>
> >> Will do!
> >
> > Please note that I'm not going to push the material to Linus with this
> > warning, so if you want it to go into 5.11, that needs to be addressed
> > timely.
> >
> > Thanks!
> >
> Understood :) I tested this last night and it looks good. Do I push this
> as a v8 patch on the current series or as a new standalone patch?
An incremental patch to fix the issue, please.
1 year, 6 months
Re: [External] Re: [pm:bleeding-edge 8612/8615] drivers/acpi/platform_profile.c:147:24: warning: address of array 'pprof->choices' will always evaluate to 'true'
by Rafael J. Wysocki
On Tue, Dec 29, 2020 at 12:18 AM Mark Pearson <markpearson(a)lenovo.com> wrote:
>
> Hi Hans
>
> On 27/12/2020 06:56, Hans de Goede wrote:
> > Hi,
> >
> > On 12/27/20 6:11 AM, kernel test robot wrote:
> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
> >> head: a33520709645543f108361fe21fa9434a351c4e9
> >> commit: 8c9b909fb1282e43792433e6c1cba125ccfc6201 [8612/8615] ACPI: platform-profile: Add platform profile support
> >> config: x86_64-randconfig-a015-20201221 (attached as .config)
> >> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project cee1e7d14f4628d6174b33640d502bff3b54ae45)
> >> 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
> >> # install x86_64 cross compiling tool for clang build
> >> # apt-get install binutils-x86-64-linux-gnu
> >> # 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 bleeding-edge
> >> git checkout 8c9b909fb1282e43792433e6c1cba125ccfc6201
> >> # save the attached .config to linux build tree
> >> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
> >>
> >> 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 >>):
> >>
> >>>> drivers/acpi/platform_profile.c:147:24: warning: address of array 'pprof->choices' will always evaluate to 'true' [-Wpointer-bool-conversion]
> >> if (!pprof || !pprof->choices || !pprof->profile_set ||
> >> ~~~~~~~~^~~~~~~
> >> 1 warning generated.
> >
> >
> > Ah, this is caused by changing choices from a single long to:
> >
> > unsigned long choices[BITS_TO_LONGS(PLATFORM_PROFILE_LAST)];
> >
> > So that we can use for_each_set_bit and are future proof for more then
> > 32 profiles.
> >
> > To fix this the check should be changed into this (untested):
> >
> > #include <linux/bitmap.h>
> >
> > if (!pprof || bitmap_empty(pprof->choices, PLATFORM_PROFILE_LAST) ||
> > !pprof->profile_set || !pprof->profile_get) {
> > mutex_unlock(&profile_lock);
> > return -EINVAL;
> > }
> >
> > Mark can you provide a (tested) patch for this?
> >
> > Regards,
> >
> > Hans
> >
> Will do!
Please note that I'm not going to push the material to Linus with this
warning, so if you want it to go into 5.11, that needs to be addressed
timely.
Thanks!
1 year, 6 months
Re: [PATCH v3 14/14] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver
by Andy Shevchenko
On Tue, Dec 29, 2020 at 1:08 AM Laurent Pinchart
<laurent.pinchart(a)ideasonboard.com> wrote:
>
> On Tue, Dec 29, 2020 at 12:55:44AM +0200, Andy Shevchenko wrote:
> > On Mon, Dec 28, 2020 at 10:37:38PM +0000, Daniel Scally wrote:
> > > On 28/12/2020 17:05, Sakari Ailus wrote:
...
> > > Which do you prefer?
> >
> > Actually ipu3-cio2.h misses a lot of inclusions (like mutex.h which I
> > immediately noticed when scrolled over data types).
>
> Then ipu3-cio2.h should be fixed :-)
Below is a draft patch (it is possible mangled, due to Gmail). Can you
look at it and tell me what you think?
I believe some headers can be removed, but I have no idea about header
inclusion guarantees that v4l2 provides.
From 10fa6c7ff66ded35a246677ffe20c677e8453f5b3 Mon Sep 17 00:00:00 2001
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Date: Tue, 29 Dec 2020 01:42:03 +0200
Subject: [PATCH 1/1] media: ipu3-cio2: Add headers that ipu3-cio2.h is direct
user of
Add headers that ipu3-cio2.h is direct user of.
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
---
drivers/media/pci/intel/ipu3/ipu3-cio2.h | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.h
b/drivers/media/pci/intel/ipu3/ipu3-cio2.h
index ccf0b85ae36f..9ea154c50ba1 100644
--- a/drivers/media/pci/intel/ipu3/ipu3-cio2.h
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.h
@@ -4,8 +4,25 @@
#ifndef __IPU3_CIO2_H
#define __IPU3_CIO2_H
+#include <linux/bits.h>
+#include <linux/dma-mapping.h>
+#include <linux/kernel.h>
+#include <linux/mutex.h>
#include <linux/types.h>
+#include <asm/page.h>
+
+#include <linux/videodev2.h>
+
+#include <media/media-device.h>
+#include <media/media-entity.h>
+#include <media/v4l2-async.h>
+#include <media/v4l2-dev.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-subdev.h>
+#include <media/videobuf2-core.h>
+#include <media/videobuf2-v4l2.h>
+
#define CIO2_NAME "ipu3-cio2"
#define CIO2_DEVICE_NAME "Intel IPU3 CIO2"
#define CIO2_ENTITY_NAME "ipu3-csi2"
@@ -325,6 +342,8 @@ struct csi2_bus_info {
u32 lanes;
};
+struct cio2_fbpt_entry;
+
struct cio2_queue {
/* mutex to be used by vb2_queue */
struct mutex lock;
@@ -355,6 +374,8 @@ struct cio2_queue {
atomic_t bufs_queued;
};
+struct pci_dev;
+
struct cio2_device {
struct pci_dev *pci_dev;
void __iomem *base;
--
2.29.2
--
With Best Regards,
Andy Shevchenko
1 year, 6 months
Re: [PATCH v3 14/14] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver
by Andy Shevchenko
On Tue, Dec 29, 2020 at 1:30 AM Daniel Scally <djrscally(a)gmail.com> wrote:
>
> Hi Andy
>
> On 28/12/2020 22:55, Andy Shevchenko wrote:
> > On Mon, Dec 28, 2020 at 10:37:38PM +0000, Daniel Scally wrote:
> >> On 28/12/2020 17:05, Sakari Ailus wrote:
> >>> On Thu, Dec 24, 2020 at 02:54:44PM +0200, Andy Shevchenko wrote:
> > ...
> >
> >>>>> +#include <linux/property.h>
> >>>>> +
> >>>>> +#define CIO2_HID "INT343E"
> >>>>> +#define CIO2_NUM_PORTS 4
> >>> This is already defined in ipu3-cio2.h. Could you include that instead?
> >> Yes; but I'd need to also include media/v4l2-device.h and
> >> media/videobuf2-dma-sg.h (they're included in ipu3-cio2-main.c at the
> >> moment). It didn't seem worth it; but I can move those two includes from
> >> the .c to the .h and then include ipu3-cio2.h in cio2-bridge.h
> >>
> >> Which do you prefer?
> > I think here should be a
> > compromise variant, split out something like ipu3-cio2-defs.h which can be
> > included in both ipu3-cio2.h and cio2-bridge.h.
>
> And just including all the things that need to be in both files you mean?
Something which may be logically grouped together. It may include
something which cio2-bridge doesn't need, but at least it will be in
one place (for example, if you move one CIO2_PCI_* constant, that
means you better move all, or so, the rest CIO2_PCI_* constants as
well).
--
With Best Regards,
Andy Shevchenko
1 year, 6 months
Re: [PATCH v3 14/14] ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver
by Andy Shevchenko
On Mon, Dec 28, 2020 at 10:37:38PM +0000, Daniel Scally wrote:
> On 28/12/2020 17:05, Sakari Ailus wrote:
> > On Thu, Dec 24, 2020 at 02:54:44PM +0200, Andy Shevchenko wrote:
...
> >>> +#include <linux/property.h>
> >>> +
> >>> +#define CIO2_HID "INT343E"
> >>> +#define CIO2_NUM_PORTS 4
> >
> > This is already defined in ipu3-cio2.h. Could you include that instead?
>
> Yes; but I'd need to also include media/v4l2-device.h and
> media/videobuf2-dma-sg.h (they're included in ipu3-cio2-main.c at the
> moment). It didn't seem worth it; but I can move those two includes from
> the .c to the .h and then include ipu3-cio2.h in cio2-bridge.h
>
> Which do you prefer?
Actually ipu3-cio2.h misses a lot of inclusions (like mutex.h which I
immediately noticed when scrolled over data types). I think here should be a
compromise variant, split out something like ipu3-cio2-defs.h which can be
included in both ipu3-cio2.h and cio2-bridge.h.
And cio2-bridge.h needs more inclusions like types.h.
--
With Best Regards,
Andy Shevchenko
1 year, 6 months