Re: [PATCH v5 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi, On 7/5/2020 8:22 am, Randy Dunlap wrote: On 5/6/20 5:15 PM, Ramuthevar,Vadivel MuruganX wrote: diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index a80a46bb5b8b..a026bec28f39 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -457,6 +457,14 @@ config MTD_NAND_CADENCE Enable the driver for NAND flash on platforms using a Cadence NAND controller. +config MTD_NAND_INTEL_LGM + tristate "Support for NAND controller on Intel LGM SoC" + depends on OF || COMPILE_TEST + depends on HAS_IOMEM + help + Enables support for NAND Flash chips on Intel's LGM SoC. + NAND flash interfaced through the External Bus Unit. Please use one tab + 2 spaces for indentation in the line above. Thank you for the review comments, will update in the next patch-set. Regards Vadivel + comment "Misc" config MTD_SM_COMMON
memory leak in inet6_create (2)
Hello, syzbot found the following crash on: HEAD commit:f66ed1eb Merge tag 'iomap-5.7-fixes-1' of git://git.kernel.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12cf3c4c10 kernel config: https://syzkaller.appspot.com/x/.config?x=36dc1e5ad3e26c41 dashboard link: https://syzkaller.appspot.com/bug?extid=db84db800df5aa102826 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1269d24c10 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16d01c4c10 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+db84db800df5aa102...@syzkaller.appspotmail.com BUG: memory leak unreferenced object 0x888110ef1800 (size 1840): comm "syz-executor783", pid 8417, jiffies 4294954395 (age 25.940s) hex dump (first 32 bytes): 00 00 00 00 7f 00 00 06 15 14 f5 21 4e 20 22 dc ...!N ". 0a 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@ backtrace: [<7986323e>] sk_prot_alloc+0x3c/0x170 net/core/sock.c:1598 [<2fc61b2a>] sk_alloc+0x30/0x330 net/core/sock.c:1658 [<0d7242e5>] inet6_create net/ipv6/af_inet6.c:181 [inline] [<0d7242e5>] inet6_create+0x112/0x4d0 net/ipv6/af_inet6.c:108 [] __sock_create+0x14a/0x220 net/socket.c:1433 [<7253d628>] sock_create net/socket.c:1484 [inline] [<7253d628>] __sys_socket+0x60/0x110 net/socket.c:1526 [<503be95b>] __do_sys_socket net/socket.c:1535 [inline] [<503be95b>] __se_sys_socket net/socket.c:1533 [inline] [<503be95b>] __x64_sys_socket+0x1a/0x20 net/socket.c:1533 [<42ce79c0>] do_syscall_64+0x6e/0x220 arch/x86/entry/common.c:295 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x888110eaf620 (size 32): comm "syz-executor783", pid 8417, jiffies 4294954395 (age 25.940s) hex dump (first 32 bytes): 02 00 00 00 00 00 00 00 c0 d8 f0 10 81 88 ff ff 01 00 00 00 03 00 00 00 33 00 00 00 00 00 00 00 3... backtrace: [<0d2c6b3e>] kmalloc include/linux/slab.h:555 [inline] [<0d2c6b3e>] kzalloc include/linux/slab.h:669 [inline] [<0d2c6b3e>] selinux_sk_alloc_security+0x43/0xa0 security/selinux/hooks.c:5126 [ ] security_sk_alloc+0x42/0x70 security/security.c:2120 [<9002ddd9>] sk_prot_alloc+0x9c/0x170 net/core/sock.c:1607 [<2fc61b2a>] sk_alloc+0x30/0x330 net/core/sock.c:1658 [<0d7242e5>] inet6_create net/ipv6/af_inet6.c:181 [inline] [<0d7242e5>] inet6_create+0x112/0x4d0 net/ipv6/af_inet6.c:108 [ ] __sock_create+0x14a/0x220 net/socket.c:1433 [<7253d628>] sock_create net/socket.c:1484 [inline] [<7253d628>] __sys_socket+0x60/0x110 net/socket.c:1526 [<503be95b>] __do_sys_socket net/socket.c:1535 [inline] [<503be95b>] __se_sys_socket net/socket.c:1533 [inline] [<503be95b>] __x64_sys_socket+0x1a/0x20 net/socket.c:1533 [<42ce79c0>] do_syscall_64+0x6e/0x220 arch/x86/entry/common.c:295 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x888110f0d8c0 (size 64): comm "syz-executor783", pid 8417, jiffies 4294954395 (age 25.940s) hex dump (first 32 bytes): 15 00 00 01 00 00 00 00 a0 39 dc 10 81 88 ff ff .9.. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<2bb571e8>] kmalloc include/linux/slab.h:555 [inline] [<2bb571e8>] kzalloc include/linux/slab.h:669 [inline] [<2bb571e8>] netlbl_secattr_alloc include/net/netlabel.h:382 [inline] [<2bb571e8>] selinux_netlbl_sock_genattr+0x48/0x180 security/selinux/netlabel.c:76 [<201274d5>] selinux_netlbl_socket_post_create+0x41/0xb0 security/selinux/netlabel.c:398 [<189429bf>] selinux_socket_post_create+0x182/0x390 security/selinux/hooks.c:4541 [<54916bb2>] security_socket_post_create+0x54/0x80 security/security.c:2032 [<85ba4813>] __sock_create+0x1cc/0x220 net/socket.c:1449 [<7253d628>] sock_create net/socket.c:1484 [inline] [<7253d628>] __sys_socket+0x60/0x110 net/socket.c:1526 [<503be95b>] __do_sys_socket net/socket.c:1535 [inline] [<503be95b>] __se_sys_socket net/socket.c:1533 [inline] [<503be95b>] __x64_sys_socket+0x1a/0x20 net/socket.c:1533 [<42ce79c0>] do_syscall_64+0x6e/0x220 arch/x86/entry/common.c:295 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x888110dc39a0 (size 32): comm "syz-executor783", pid 8417, jiffies 4294954395 (age 25.940s) hex dump (first 32 bytes): 6b 65 72 6e 65 6c 5f 74 00 73 79
Re: [PATCH 06/11] net: ethernet: mtk-eth-mac: new driver
On Wed, May 06, 2020 at 12:23:29PM -0700, Jakub Kicinski wrote: > On Wed, 6 May 2020 22:16:11 +0300 Leon Romanovsky wrote: > > > +#define MTK_MAC_DRVNAME"mtk_eth_mac" > > > +#define MTK_MAC_VERSION"1.0" > > > > Please don't add driver version to new driver. > > It has already been pointed out. Please trim your replies. Off-topic. Is there any simple way to trim replies semi-automatically in VIM? Right now, I'm doing it manually, but maybe there is some better way to do it. Thanks
Re: [PATCH v12 02/10] KVM: VMX: Set guest CET MSRs per KVM and host configuration
Hi Yang, Thank you for the patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on tip/auto-latest linus/master v5.7-rc4 next-20200505] [cannot apply to kvm/linux-next linux/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Yang-Weijiang/Introduce-support-for-guest-CET-feature/20200507-021021 base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next config: x86_64-allyesconfig (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 54b35c066417d4856e9d53313f7e98b354274584) reproduce: 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 # 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: kbuild test robot All errors (new ones prefixed by >>): >> arch/x86/kvm/vmx/vmx.c:3026:26: error: use of undeclared identifier >> 'X86_FEATURE_SHSTK'; did you mean 'XFEATURE_SSE'? (guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) || ^ XFEATURE_SSE arch/x86/include/asm/fpu/types.h:104:2: note: 'XFEATURE_SSE' declared here XFEATURE_SSE, ^ arch/x86/kvm/vmx/vmx.c:3027:25: error: use of undeclared identifier 'X86_FEATURE_IBT' guest_cpuid_has(vcpu, X86_FEATURE_IBT))); ^ arch/x86/kvm/vmx/vmx.c:7114:40: error: use of undeclared identifier 'XFEATURE_MASK_CET_USER' incpt = !is_cet_state_supported(vcpu, XFEATURE_MASK_CET_USER); ^ >> arch/x86/kvm/vmx/vmx.c:7119:40: error: use of undeclared identifier >> 'MSR_IA32_U_CET' vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_U_CET, MSR_TYPE_RW, ^ >> arch/x86/kvm/vmx/vmx.c:7121:40: error: use of undeclared identifier >> 'MSR_IA32_PL3_SSP' vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_PL3_SSP, MSR_TYPE_RW, ^ arch/x86/kvm/vmx/vmx.c:7124:40: error: use of undeclared identifier 'XFEATURE_MASK_CET_KERNEL' incpt = !is_cet_state_supported(vcpu, XFEATURE_MASK_CET_KERNEL); ^ >> arch/x86/kvm/vmx/vmx.c:7129:40: error: use of undeclared identifier >> 'MSR_IA32_S_CET' vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_S_CET, MSR_TYPE_RW, ^ >> arch/x86/kvm/vmx/vmx.c:7131:40: error: use of undeclared identifier >> 'MSR_IA32_PL0_SSP' vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_PL0_SSP, MSR_TYPE_RW, ^ >> arch/x86/kvm/vmx/vmx.c:7133:40: error: use of undeclared identifier >> 'MSR_IA32_PL1_SSP' vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_PL1_SSP, MSR_TYPE_RW, ^ >> arch/x86/kvm/vmx/vmx.c:7135:40: error: use of undeclared identifier >> 'MSR_IA32_PL2_SSP' vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_PL2_SSP, MSR_TYPE_RW, ^ arch/x86/kvm/vmx/vmx.c:7138:34: error: use of undeclared identifier 'X86_FEATURE_SHSTK'; did you mean 'XFEATURE_SSE'? incpt |= !guest_cpuid_has(vcpu, X86_FEATURE_SHSTK); ^ XFEATURE_SSE arch/x86/include/asm/fpu/types.h:104:2: note: 'XFEATURE_SSE' declared here XFEATURE_SSE, ^ >> arch/x86/kvm/vmx/vmx.c:7140:40: error: use of undeclared identifier >> 'MSR_IA32_INT_SSP_TAB' vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_INT_SSP_TAB, MSR_TYPE_RW, ^ arch/x86/kvm/vmx/vmx.c:7183:23: error: use of undeclared identifier 'XFEATURE_MASK_CET_KERNEL' if (supported_xss & (XFEATURE_MASK_CET_KERNEL | XFEATURE_MASK_CET_USER)) ^ arch/x86/kvm/vmx/vmx.c:7183:50: error: use of undeclared identifier 'XFEATURE_MASK_CET_USER' if (supported_xss & (XFEATURE_MASK_CET_KERNEL | XFEATURE_MASK_CET_USER)) ^ 14 errors generated. vim +3026 arch/x86/kvm/vmx/vmx.c 3022 3023 static bool
Re: [PATCH bpf] security: Fix the default value of fs_context_parse_param hook
On Thu, Apr 30, 2020 at 8:46 PM James Morris wrote: > > On Thu, 30 Apr 2020, KP Singh wrote: > > > From: KP Singh > > > > Applied to: > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git > for-v5.7 > James, could you please send PR to Linus this week to make sure the fix makes it into the next -rc ? Few other people reported issues that are fixed by this patch. Thanks!
Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass
Hi Mark, This patch set currently only address the Pure DT implementation. EFI and ACPI implementations will be posted in subsequent patchsets. The logs are intended to be carried over the kexec and once read the logs are no longer needed and in prior conversation with James( https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1...@arm.com/) the apporach of using a chosen node doesn't support the case. The DT entries make the reservation permanent and thus doesnt need kernel segments to be used for this, however using a chosen-node with reserved memory only changes the node information but memory still is reserved via reserved-memory section. On 5/5/20 2:59 AM, Mark Rutland wrote: Hi Prakhar, On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: IMA during kexec(kexec file load) verifies the kernel signature and measures the signature of the kernel. The signature in the logs can be used to verfiy the authenticity of the kernel. The logs don not get carried over kexec and thus remote attesation cannot verify the signature of the running kernel. Introduce an ABI to carry forward the ima logs over kexec. Memory reserved via device tree reservation can be used to store and read via the of_* functions. This flow needs to work for: 1) Pure DT 2) DT + EFI memory map 3) ACPI + EFI memory map ... and if this is just for transiently passing the log, I don't think that a reserved memory region is the right thing to use, since they're supposed to be more permanent. This sounds analogous to passing the initrd, and should probably use properties under the chosen node (which can be used for all three boot flows above). For reference, how big is the IMA log likely to be? Does it need physically contiguous space? It purely depends on the policy used and the modules/files that are accessed for my local testing over a kexec session the log in about 30KB. Current implementation expects enough contiguous memory to allocated to carry forward the logs. If the log size exceeds the reserved memory the call will fail. Thanks, Prakhar Srivastava Thanks, Mark. Reserved memory stores the size(sizeof(size_t)) of the buffer in the starting address, followed by the IMA log contents. Tested on: arm64 with Uboot Prakhar Srivastava (2): Add a layer of abstraction to use the memory reserved by device tree for ima buffer pass. Add support for ima buffer pass using reserved memory for arm64 kexec. Update the arch sepcific code path in kexec file load to store the ima buffer in the reserved memory. The same reserved memory is read on kexec or cold boot. arch/arm64/Kconfig | 1 + arch/arm64/include/asm/ima.h | 22 arch/arm64/include/asm/kexec.h | 5 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/ima_kexec.c | 64 ++ arch/arm64/kernel/machine_kexec_file.c | 1 + arch/powerpc/include/asm/ima.h | 3 +- arch/powerpc/kexec/ima.c | 14 ++- drivers/of/Kconfig | 6 + drivers/of/Makefile| 1 + drivers/of/of_ima.c| 165 + include/linux/of.h | 34 + security/integrity/ima/ima_kexec.c | 15 ++- 13 files changed, 325 insertions(+), 7 deletions(-) create mode 100644 arch/arm64/include/asm/ima.h create mode 100644 arch/arm64/kernel/ima_kexec.c create mode 100644 drivers/of/of_ima.c -- 2.25.1
RE: [PATCH v4 3/5] iommu/vt-d: Disable non-recoverable fault processing before unbind
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:56 AM
>
> When a PASID is used for SVA by the device, it's possible that the PASID
> entry is cleared before the device flushes all ongoing DMA requests. The
> IOMMU should ignore the non-recoverable faults caused by these requests.
> Intel VT-d provides such function through the FPD bit of the PASID entry.
> This sets FPD bit when PASID entry is cleared in the mm notifier and
> clear it when the pasid is unbound.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel-iommu.c | 4 ++--
> drivers/iommu/intel-pasid.c | 26 +-
> drivers/iommu/intel-pasid.h | 3 ++-
> drivers/iommu/intel-svm.c | 9 ++---
> 4 files changed, 31 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index d1866c0905b1..7811422b5a68 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -5352,7 +5352,7 @@ static void __dmar_remove_one_dev_info(struct
> device_domain_info *info)
> if (info->dev) {
> if (dev_is_pci(info->dev) && sm_supported(iommu))
> intel_pasid_tear_down_entry(iommu, info->dev,
> - PASID_RID2PASID);
> + PASID_RID2PASID, false);
>
> iommu_disable_dev_iotlb(info);
> domain_context_clear(iommu, info->dev);
> @@ -5587,7 +5587,7 @@ static void aux_domain_remove_dev(struct
> dmar_domain *domain,
> auxiliary_unlink_device(domain, dev);
>
> spin_lock(>lock);
> - intel_pasid_tear_down_entry(iommu, dev, domain->default_pasid);
> + intel_pasid_tear_down_entry(iommu, dev, domain->default_pasid,
> false);
> domain_detach_iommu(domain, iommu);
> spin_unlock(>lock);
>
> diff --git a/drivers/iommu/intel-pasid.c b/drivers/iommu/intel-pasid.c
> index 7969e3dac2ad..11aef6c12972 100644
> --- a/drivers/iommu/intel-pasid.c
> +++ b/drivers/iommu/intel-pasid.c
> @@ -292,7 +292,20 @@ static inline void pasid_clear_entry(struct
> pasid_entry *pe)
> WRITE_ONCE(pe->val[7], 0);
> }
>
> -static void intel_pasid_clear_entry(struct device *dev, int pasid)
> +static inline void pasid_clear_entry_with_fpd(struct pasid_entry *pe)
> +{
> + WRITE_ONCE(pe->val[0], PASID_PTE_FPD);
> + WRITE_ONCE(pe->val[1], 0);
> + WRITE_ONCE(pe->val[2], 0);
> + WRITE_ONCE(pe->val[3], 0);
> + WRITE_ONCE(pe->val[4], 0);
> + WRITE_ONCE(pe->val[5], 0);
> + WRITE_ONCE(pe->val[6], 0);
> + WRITE_ONCE(pe->val[7], 0);
> +}
> +
> +static void
> +intel_pasid_clear_entry(struct device *dev, int pasid, bool pf_ignore)
Hi, Baolu,
Just curious whether it makes sense to always set FPD here. Yes, SVA is
one known example that non-recoverable fault associated with a PASID
entry might be caused after the entry is cleared and those are considered
benign. But even in a general context (w/o SVA) why do we care about
such faults after a PASID entry is torn down?
Thanks
Kevin
> {
> struct pasid_entry *pe;
>
> @@ -300,7 +313,10 @@ static void intel_pasid_clear_entry(struct device
> *dev, int pasid)
> if (WARN_ON(!pe))
> return;
>
> - pasid_clear_entry(pe);
> + if (pf_ignore)
> + pasid_clear_entry_with_fpd(pe);
> + else
> + pasid_clear_entry(pe);
> }
>
> static inline void pasid_set_bits(u64 *ptr, u64 mask, u64 bits)
> @@ -533,8 +549,8 @@ devtlb_invalidation_with_pasid(struct intel_iommu
> *iommu,
> qi_flush_dev_iotlb(iommu, sid, pfsid, qdep, 0, 64 - VTD_PAGE_SHIFT);
> }
>
> -void intel_pasid_tear_down_entry(struct intel_iommu *iommu,
> - struct device *dev, int pasid)
> +void intel_pasid_tear_down_entry(struct intel_iommu *iommu, struct
> device *dev,
> + int pasid, bool pf_ignore)
> {
> struct pasid_entry *pte;
> u16 did;
> @@ -544,7 +560,7 @@ void intel_pasid_tear_down_entry(struct
> intel_iommu *iommu,
> return;
>
> did = pasid_get_domain_id(pte);
> - intel_pasid_clear_entry(dev, pasid);
> + intel_pasid_clear_entry(dev, pasid, pf_ignore);
>
> if (!ecap_coherent(iommu->ecap))
> clflush_cache_range(pte, sizeof(*pte));
> diff --git a/drivers/iommu/intel-pasid.h b/drivers/iommu/intel-pasid.h
> index a41b09b3ffde..e6dd95ffe381 100644
> --- a/drivers/iommu/intel-pasid.h
> +++ b/drivers/iommu/intel-pasid.h
> @@ -15,6 +15,7 @@
> #define PASID_MAX0x10
> #define PASID_PTE_MASK 0x3F
> #define PASID_PTE_PRESENT1
> +#define PASID_PTE_FPD2
> #define PDE_PFN_MASK PAGE_MASK
> #define PASID_PDE_SHIFT 6
> #define MAX_NR_PASID_BITS20
> @@ -120,7 +121,7 @@ int intel_pasid_setup_nested(struct intel_iommu
> *iommu,
>struct iommu_gpasid_bind_data_vtd *pasid_data,
>
Re: [PATCH] arm64: dts: qcom: c630: Make i2c devices active high
On Sun 05 Apr 22:24 PDT 2020, Bjorn Andersson wrote:
> The two i2c hid devices on i2c3 are supposed to have interrupts
> triggered active high, update this.
>
While this is what the DSDT says, keeping it as RISING avoids occasional
drops of keyboard entries. So let's ignore this for now.
> Signed-off-by: Bjorn Andersson
> ---
> arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> index be6635068dc3..d4cdde496b74 100644
> --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> @@ -338,7 +338,7 @@ hid@15 {
> reg = <0x15>;
> hid-descr-addr = <0x1>;
>
> - interrupts-extended = < 37 IRQ_TYPE_EDGE_RISING>;
> + interrupts-extended = < 37 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> hid@2c {
> @@ -346,7 +346,7 @@ hid@2c {
> reg = <0x2c>;
> hid-descr-addr = <0x20>;
>
> - interrupts-extended = < 37 IRQ_TYPE_EDGE_RISING>;
> + interrupts-extended = < 37 IRQ_TYPE_LEVEL_HIGH>;
>
> pinctrl-names = "default";
> pinctrl-0 = <_hid_active>;
> --
> 2.26.0
>
RE: [PATCH v4 2/5] iommu/vt-d: debugfs: Add support to show inv queue internals
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:56 AM
>
> Export invalidation queue internals of each iommu device through the
> debugfs.
>
> Example of such dump on a Skylake machine:
>
> $ sudo cat /sys/kernel/debug/iommu/intel/invalidation_queue
> Invalidation queue on IOMMU: dmar1
> Base: 0x1672c9000 Head: 80Tail: 80
> Index qw0 qw1 status
> 0 0004
> 1 000200250001672be804
> 2 0011
> 3 000200250001672be80c
> 4 00d2
> 5 000200250001672be814
> 6 0014
> 7 000200250001672be81c
> 8 0014
> 9 000200250001672be824
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel-iommu-debugfs.c | 62
> +
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/iommu/intel-iommu-debugfs.c b/drivers/iommu/intel-
> iommu-debugfs.c
> index 3eb1fe240fb0..e3089865b8f3 100644
> --- a/drivers/iommu/intel-iommu-debugfs.c
> +++ b/drivers/iommu/intel-iommu-debugfs.c
> @@ -372,6 +372,66 @@ static int domain_translation_struct_show(struct
> seq_file *m, void *unused)
> }
> DEFINE_SHOW_ATTRIBUTE(domain_translation_struct);
>
> +static void invalidation_queue_entry_show(struct seq_file *m,
> + struct intel_iommu *iommu)
> +{
> + int index, shift = qi_shift(iommu);
> + struct qi_desc *desc;
> + int offset;
> +
> + if (ecap_smts(iommu->ecap))
> + seq_puts(m,
> "Index\t\tqw0\t\t\tqw1\t\t\tqw2\t\t\tqw3\t\t\tstatus\n");
> + else
> + seq_puts(m, "Index\t\tqw0\t\t\tqw1\t\t\tstatus\n");
> +
> + for (index = 0; index < QI_LENGTH; index++) {
> + offset = index << shift;
> + desc = iommu->qi->desc + offset;
> + if (ecap_smts(iommu->ecap))
> + seq_printf(m,
> "%5d\t%016llx\t%016llx\t%016llx\t%016llx\t%016x\n",
> +index, desc->qw0, desc->qw1,
> +desc->qw2, desc->qw3,
> +iommu->qi->desc_status[index]);
> + else
> + seq_printf(m, "%5d\t%016llx\t%016llx\t%016x\n",
> +index, desc->qw0, desc->qw1,
> +iommu->qi->desc_status[index]);
> + }
> +}
> +
> +static int invalidation_queue_show(struct seq_file *m, void *unused)
> +{
> + struct dmar_drhd_unit *drhd;
> + struct intel_iommu *iommu;
> + unsigned long flags;
> + struct q_inval *qi;
> + int shift;
> +
> + rcu_read_lock();
> + for_each_active_iommu(iommu, drhd) {
> + qi = iommu->qi;
> + shift = qi_shift(iommu);
> +
> + if (!qi || !ecap_qis(iommu->ecap))
> + continue;
> +
> + seq_printf(m, "Invalidation queue on IOMMU: %s\n",
> iommu->name);
> +
> + raw_spin_lock_irqsave(>q_lock, flags);
> + seq_printf(m, " Base: 0x%llx\tHead: %lld\tTail: %lld\n",
> +virt_to_phys(qi->desc),
> +dmar_readq(iommu->reg + DMAR_IQH_REG) >>
> shift,
> +dmar_readq(iommu->reg + DMAR_IQT_REG) >>
> shift);
> + invalidation_queue_entry_show(m, iommu);
> + raw_spin_unlock_irqrestore(>q_lock, flags);
> + seq_putc(m, '\n');
> + }
> + rcu_read_unlock();
> +
> + return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(invalidation_queue);
> +
> #ifdef CONFIG_IRQ_REMAP
> static void ir_tbl_remap_entry_show(struct seq_file *m,
> struct intel_iommu *iommu)
> @@ -490,6 +550,8 @@ void __init intel_iommu_debugfs_init(void)
> debugfs_create_file("domain_translation_struct", 0444,
> intel_iommu_debug, NULL,
> _translation_struct_fops);
> + debugfs_create_file("invalidation_queue", 0444, intel_iommu_debug,
> + NULL, _queue_fops);
> #ifdef CONFIG_IRQ_REMAP
> debugfs_create_file("ir_translation_struct", 0444,
> intel_iommu_debug,
> NULL, _translation_struct_fops);
> --
> 2.17.1
Reviewed-by: Kevin Tian
Re: [PATCH] printk: Add loglevel for "do not print to consoles".
On 2020/05/07 14:30, Joe Perches wrote: > I proposed awhile back making functions for pr_ > https://lore.kernel.org/lkml/1466739971-30399-1-git-send-email-...@perches.com/ Great. That will also benefit KERN_NO_CONSOLES. > > Maybe it's time for that and something appropriate > like it for your next use too. How to pass KERN_NO_CONSOLES (if KERN_NO_CONSOLES is acceptable) is a future patch. I believe that there is no remaining problem regarding KERN_NO_CONSOLES itself.
[PATCH -next] phy: ti: j721e-wiz: Fix some error return code in wiz_probe()
Fix to return negative error code from some error handling
cases instead of 0, as done elsewhere in this function.
Fixes: 091876cc355d ("phy: ti: j721e-wiz: Add support for WIZ module present in
TI J721E SoC")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/phy/ti/phy-j721e-wiz.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 1d12d1b1b63a..30ea5b207285 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -841,8 +841,10 @@ static int wiz_probe(struct platform_device *pdev)
}
base = devm_ioremap(dev, res.start, resource_size());
- if (!base)
+ if (!base) {
+ ret = -ENOMEM;
goto err_addr_to_resource;
+ }
regmap = devm_regmap_init_mmio(dev, base, _regmap_config);
if (IS_ERR(regmap)) {
@@ -859,6 +861,7 @@ static int wiz_probe(struct platform_device *pdev)
if (num_lanes > WIZ_MAX_LANES) {
dev_err(dev, "Cannot support %d lanes\n", num_lanes);
+ ret = -ENODEV;
goto err_addr_to_resource;
}
@@ -948,6 +951,7 @@ static int wiz_probe(struct platform_device *pdev)
serdes_pdev = of_platform_device_create(child_node, NULL, dev);
if (!serdes_pdev) {
dev_WARN(dev, "Unable to create SERDES platform device\n");
+ ret = -ENOMEM;
goto err_pdev_create;
}
wiz->serdes_pdev = serdes_pdev;
linux-next: build failure after merge of the vhost tree
Hi all,
After merging the vhost tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/net/virtio_net.c: In function 'try_fill_recv':
drivers/net/virtio_net.c:1250:3: error: too few arguments to function
'u64_stats_update_end_irqrestore'
1250 | u64_stats_update_end_irqrestore(>stats.syncp);
| ^~~
In file included from include/net/snmp.h:47,
from include/net/netns/mib.h:5,
from include/net/net_namespace.h:17,
from include/linux/netdevice.h:38,
from drivers/net/virtio_net.c:7:
include/linux/u64_stats_sync.h:149:1: note: declared here
149 | u64_stats_update_end_irqrestore(struct u64_stats_sync *syncp,
| ^~~
Caused by commit
fa74db4261e1 ("virtio_net: fix lockdep warning on 32 bit")
I have used the version of the vhost tree from next-20200505.
--
Cheers,
Stephen Rothwell
pgp2I08WSs78e.pgp
Description: OpenPGP digital signature
[PATCH] coresight: cti: remove incorrect NULL return check
fwnode_find_reference() doesn't return NULL and hence that check
should be avoided.
Signed-off-by: Calvin Johnson
Reviewed-by: Mathieu Poirier
---
drivers/hwtracing/coresight/coresight-cti-platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-cti-platform.c
b/drivers/hwtracing/coresight/coresight-cti-platform.c
index b44d83142b62..2fdaeec80ee5 100644
--- a/drivers/hwtracing/coresight/coresight-cti-platform.c
+++ b/drivers/hwtracing/coresight/coresight-cti-platform.c
@@ -120,7 +120,7 @@ static int cti_plat_create_v8_etm_connection(struct device
*dev,
/* Can optionally have an etm node - return if not */
cs_fwnode = fwnode_find_reference(root_fwnode, CTI_DT_CSDEV_ASSOC, 0);
- if (IS_ERR_OR_NULL(cs_fwnode))
+ if (IS_ERR(cs_fwnode))
return 0;
/* allocate memory */
@@ -393,7 +393,7 @@ static int cti_plat_create_connection(struct device *dev,
/* associated device ? */
cs_fwnode = fwnode_find_reference(fwnode,
CTI_DT_CSDEV_ASSOC, 0);
- if (!IS_ERR_OR_NULL(cs_fwnode)) {
+ if (!IS_ERR(cs_fwnode)) {
assoc_name = cti_plat_get_csdev_or_node_name(cs_fwnode,
);
fwnode_handle_put(cs_fwnode);
--
2.17.1
RE: [PATCH v4 1/5] iommu/vt-d: Multiple descriptors per qi_submit_sync()
> From: Lu Baolu
> Sent: Thursday, May 7, 2020 8:56 AM
>
> Current qi_submit_sync() only supports single invalidation descriptor
> per submission and appends wait descriptor after each submission to
> poll the hardware completion. This extends the qi_submit_sync() helper
> to support multiple descriptors, and add an option so that the caller
> could specify the Page-request Drain (PD) bit in the wait descriptor.
>
> Signed-off-by: Jacob Pan
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/dmar.c| 63 +
> drivers/iommu/intel-pasid.c | 4 +-
> drivers/iommu/intel-svm.c | 6 +--
> drivers/iommu/intel_irq_remapping.c | 2 +-
> include/linux/intel-iommu.h | 9 -
> 5 files changed, 52 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> index d9dc787feef7..61d049e91f84 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -1157,12 +1157,11 @@ static inline void reclaim_free_desc(struct
> q_inval *qi)
> }
> }
>
> -static int qi_check_fault(struct intel_iommu *iommu, int index)
> +static int qi_check_fault(struct intel_iommu *iommu, int index, int
> wait_index)
> {
> u32 fault;
> int head, tail;
> struct q_inval *qi = iommu->qi;
> - int wait_index = (index + 1) % QI_LENGTH;
> int shift = qi_shift(iommu);
>
> if (qi->desc_status[wait_index] == QI_ABORT)
> @@ -1225,17 +1224,21 @@ static int qi_check_fault(struct intel_iommu
> *iommu, int index)
> }
>
> /*
> - * Submit the queued invalidation descriptor to the remapping
> - * hardware unit and wait for its completion.
> + * Function to submit invalidation descriptors of all types to the queued
> + * invalidation interface(QI). Multiple descriptors can be submitted at a
> + * time, a wait descriptor will be appended to each submission to ensure
> + * hardware has completed the invalidation before return. Wait descriptors
> + * can be part of the submission but it will not be polled for completion.
> */
> -int qi_submit_sync(struct qi_desc *desc, struct intel_iommu *iommu)
> +int qi_submit_sync(struct intel_iommu *iommu, struct qi_desc *desc,
> +unsigned int count, unsigned long options)
> {
> - int rc;
> struct q_inval *qi = iommu->qi;
> - int offset, shift, length;
> struct qi_desc wait_desc;
> int wait_index, index;
> unsigned long flags;
> + int offset, shift;
> + int rc, i;
>
> if (!qi)
> return 0;
> @@ -1244,32 +1247,41 @@ int qi_submit_sync(struct qi_desc *desc, struct
> intel_iommu *iommu)
> rc = 0;
>
> raw_spin_lock_irqsave(>q_lock, flags);
> - while (qi->free_cnt < 3) {
> + /*
> + * Check if we have enough empty slots in the queue to submit,
> + * the calculation is based on:
> + * # of desc + 1 wait desc + 1 space between head and tail
> + */
> + while (qi->free_cnt < count + 2) {
> raw_spin_unlock_irqrestore(>q_lock, flags);
> cpu_relax();
> raw_spin_lock_irqsave(>q_lock, flags);
> }
>
> index = qi->free_head;
> - wait_index = (index + 1) % QI_LENGTH;
> + wait_index = (index + count) % QI_LENGTH;
> shift = qi_shift(iommu);
> - length = 1 << shift;
>
> - qi->desc_status[index] = qi->desc_status[wait_index] = QI_IN_USE;
> + for (i = 0; i < count; i++) {
> + offset = ((index + i) % QI_LENGTH) << shift;
> + memcpy(qi->desc + offset, [i], 1 << shift);
> + qi->desc_status[(index + i) % QI_LENGTH] = QI_IN_USE;
> + }
> + qi->desc_status[wait_index] = QI_IN_USE;
>
> - offset = index << shift;
> - memcpy(qi->desc + offset, desc, length);
> wait_desc.qw0 = QI_IWD_STATUS_DATA(QI_DONE) |
> QI_IWD_STATUS_WRITE | QI_IWD_TYPE;
> + if (options & QI_OPT_WAIT_DRAIN)
> + wait_desc.qw0 |= QI_IWD_PRQ_DRAIN;
> wait_desc.qw1 = virt_to_phys(>desc_status[wait_index]);
> wait_desc.qw2 = 0;
> wait_desc.qw3 = 0;
>
> offset = wait_index << shift;
> - memcpy(qi->desc + offset, _desc, length);
> + memcpy(qi->desc + offset, _desc, 1 << shift);
>
> - qi->free_head = (qi->free_head + 2) % QI_LENGTH;
> - qi->free_cnt -= 2;
> + qi->free_head = (qi->free_head + count + 1) % QI_LENGTH;
> + qi->free_cnt -= count + 1;
>
> /*
>* update the HW tail register indicating the presence of
> @@ -1285,7 +1297,7 @@ int qi_submit_sync(struct qi_desc *desc, struct
> intel_iommu *iommu)
>* a deadlock where the interrupt context can wait
> indefinitely
>* for free slots in the queue.
>*/
> - rc = qi_check_fault(iommu, index);
> + rc = qi_check_fault(iommu, index, wait_index);
> if (rc)
> break;
>
> @@ -1294,7 +1306,8 @@ int qi_submit_sync(struct qi_desc
Re: [PATCH] printk: Add loglevel for "do not print to consoles".
On Thu, 2020-05-07 at 14:13 +0900, Tetsuo Handa wrote: > On 2020/05/07 10:02, Joe Perches wrote: > > > > printk_get_level / printk_skip_level and the various > > > > uses of %pV using printk_get_level > > > > > > > > > > Excuse me, but what do you mean? > > > > > > I wish printk() accepts "loglevel" argument detached from "fmt" argument > > > (e.g. > > > > I think that's a bad idea as it would expand > > _every_ use of printk with another argument > > and overall code size would increase for very > > little value. > > I'm not saying that we should add loglevel argument to all printk() callers. > I'm saying that we could add a variant of printk() which accepts loglevel > argument (say, e.g. printkl() and vprintkl()). > > I think that some of printk_get_level() users are using printk_get_level() > only > for detaching loglevel argument from fmt argument. I believe wrote all of those. > I don't know how the lockless logbuf will replace printk_safe_flush_buffer(). > But I guess > it is possible to avoid printk_safe_flush_buffer() and printk_skip_level() as > demonstrated > by > https://lkml.kernel.org/r/5e192ca2-3b24-0b45-fc13-51feec43c...@i-love.sakura.ne.jp > . > > Then, printk_skip_headers() will be the only user of printk_skip_level(). I > don't know how > vkdb_printf() works, but vkdb_printf() is currently using printk_skip_level() > in order to > remove loglevel argument. We can avoid printk_skip_level() if loglevel > argument is detached > from fmt argument. a vprintk_emit variant would probably do. I proposed awhile back making functions for pr_ https://lore.kernel.org/lkml/1466739971-30399-1-git-send-email-...@perches.com/ Maybe it's time for that and something appropriate like it for your next use too.
Re: [PATCH v5 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
On Thu, 7 May 2020 08:15:37 +0800 "Ramuthevar,Vadivel MuruganX" wrote: > + reg = readl(ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num)); > + writel(reg | EBU_ADDR_MASK(5) | EBU_ADDR_SEL_REGEN, > +ebu_host->ebu + EBU_ADDR_SEL(ebu_host->cs_num)); Seriously, did you really think I would not notice what you're doing here? You're reading the previous value which either contains a default mapping or has the mapping set by the bootloader, and write it back to the register along with a new mask and the REGEN bit set (which BTW is wrong since you don't mask out other fields before updating them). This confirms that this Core -> FPI address translation exists and has to be set properly, so please stop lying about that.
Re: [PATCH] slub: limit count of partial slabs scanned to gather statistics
On 06/05/2020 14.56, Vlastimil Babka wrote:
On 5/4/20 6:07 PM, Konstantin Khlebnikov wrote:
To get exact count of free and used objects slub have to scan list of
partial slabs. This may take at long time. Scanning holds spinlock and
blocks allocations which move partial slabs to per-cpu lists and back.
Example found in the wild:
# cat /sys/kernel/slab/dentry/partial
14478538 N0=7329569 N1=7148969
# time cat /sys/kernel/slab/dentry/objects
286225471 N0=136967768 N1=149257703
real0m1.722s
user0m0.001s
sys 0m1.721s
The same problem in slab was addressed in commit f728b0a5d72a ("mm, slab:
faster active and free stats") by adding more kmem cache statistics.
For slub same approach requires atomic op on fast path when object frees.
In general yeah, but are you sure about this one? AFAICS this is about pages in
the n->partial list, where manipulations happen under n->list_lock and shouldn't
be fast path. It should be feasible to add a counter under the same lock, so it
wouldn't even need to be atomic?
SLUB allocates objects from prepared per-cpu slabs, they could be subtracted
from
count of free object under this lock in advance when slab moved out of this
list.
But at freeing path object might belong to any slab, including global partials.
Let's simply limit count of scanned slabs and print warning.
Limit set in /sys/module/slub/parameters/max_partial_to_count.
Default is 1 which should be enough for most sane cases.
Return linear approximation if list of partials is longer than limit.
Nobody should notice difference.
Signed-off-by: Konstantin Khlebnikov
BTW there was a different patch in that area proposed recently [1] for slabinfo.
Christopher argued that we can do that for slabinfo but leave /sys stats
precise. Guess not then?
[1]
https://lore.kernel.org/linux-mm/20200222092428.99488-1-weny...@linux.alibaba.com/
---
mm/slub.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/mm/slub.c b/mm/slub.c
index 9bf44955c4f1..86a366f7acb6 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2407,16 +2407,29 @@ static inline unsigned long node_nr_objs(struct
kmem_cache_node *n)
#endif /* CONFIG_SLUB_DEBUG */
#if defined(CONFIG_SLUB_DEBUG) || defined(CONFIG_SYSFS)
+
+static unsigned long max_partial_to_count __read_mostly = 1;
+module_param(max_partial_to_count, ulong, 0644);
+
static unsigned long count_partial(struct kmem_cache_node *n,
int (*get_count)(struct page *))
{
+ unsigned long counted = 0;
unsigned long flags;
unsigned long x = 0;
struct page *page;
spin_lock_irqsave(>list_lock, flags);
- list_for_each_entry(page, >partial, slab_list)
+ list_for_each_entry(page, >partial, slab_list) {
x += get_count(page);
+
+ if (++counted > max_partial_to_count) {
+ pr_warn_once("SLUB: too much partial slabs to count all
objects, increase max_partial_to_count.\n");
+ /* Approximate total count of objects */
+ x = mult_frac(x, n->nr_partial, counted);
+ break;
+ }
+ }
spin_unlock_irqrestore(>list_lock, flags);
return x;
}
Re: [PATCH v7 07/10] phy: samsung-ufs: add UFS PHY driver for samsung SoC
+Vinod
Hi Alim,
On 4/26/2020 11:00 PM, Alim Akhtar wrote:
> This patch introduces Samsung UFS PHY driver. This driver
> supports to deal with phy calibration and power control
> according to UFS host driver's behavior.
>
> Reviewed-by: Kiwoong Kim
> Signed-off-by: Seungwon Jeon
> Signed-off-by: Alim Akhtar
> Cc: Kishon Vijay Abraham I
> Tested-by: Paweł Chmiel
> ---
> drivers/phy/samsung/Kconfig | 9 +
> drivers/phy/samsung/Makefile | 1 +
> drivers/phy/samsung/phy-exynos7-ufs.h | 85 ++
> drivers/phy/samsung/phy-samsung-ufs.c | 369 ++
> drivers/phy/samsung/phy-samsung-ufs.h | 142 ++
> 5 files changed, 606 insertions(+)
> create mode 100644 drivers/phy/samsung/phy-exynos7-ufs.h
> create mode 100644 drivers/phy/samsung/phy-samsung-ufs.c
> create mode 100644 drivers/phy/samsung/phy-samsung-ufs.h
>
> diff --git a/drivers/phy/samsung/Kconfig b/drivers/phy/samsung/Kconfig
> index 9e483d1fdaf2..fc1e3c17f842 100644
> --- a/drivers/phy/samsung/Kconfig
> +++ b/drivers/phy/samsung/Kconfig
> @@ -29,6 +29,15 @@ config PHY_EXYNOS_PCIE
> Enable PCIe PHY support for Exynos SoC series.
> This driver provides PHY interface for Exynos PCIe controller.
>
> +config PHY_SAMSUNG_UFS
> + tristate "SAMSUNG SoC series UFS PHY driver"
> + depends on OF && (ARCH_EXYNOS || COMPILE_TEST)
> + select GENERIC_PHY
> + help
> + Enable this to support the Samsung UFS PHY driver for
> + Samsung SoCs. This driver provides the interface for UFS
> + host controller to do PHY related programming.
> +
> config PHY_SAMSUNG_USB2
> tristate "Samsung USB 2.0 PHY driver"
> depends on HAS_IOMEM
> diff --git a/drivers/phy/samsung/Makefile b/drivers/phy/samsung/Makefile
> index db9b1aa0de6e..3959100fe8a2 100644
> --- a/drivers/phy/samsung/Makefile
> +++ b/drivers/phy/samsung/Makefile
> @@ -2,6 +2,7 @@
> obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)+= phy-exynos-dp-video.o
> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> obj-$(CONFIG_PHY_EXYNOS_PCIE)+= phy-exynos-pcie.o
> +obj-$(CONFIG_PHY_SAMSUNG_UFS)+= phy-samsung-ufs.o
> obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o
> phy-exynos-usb2-y+= phy-samsung-usb2.o
> phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4210_USB2)+= phy-exynos4210-usb2.o
> diff --git a/drivers/phy/samsung/phy-exynos7-ufs.h
> b/drivers/phy/samsung/phy-exynos7-ufs.h
> new file mode 100644
> index ..da981c1ac040
> --- /dev/null
> +++ b/drivers/phy/samsung/phy-exynos7-ufs.h
> @@ -0,0 +1,85 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * UFS PHY driver data for Samsung EXYNOS7 SoC
> + *
> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
> + */
> +#ifndef _PHY_EXYNOS7_UFS_H_
> +#define _PHY_EXYNOS7_UFS_H_
> +
> +#include "phy-samsung-ufs.h"
> +
> +#define EXYNOS7_EMBEDDED_COMBO_PHY_CTRL 0x720
> +#define EXYNOS7_EMBEDDED_COMBO_PHY_CTRL_MASK 0x1
> +#define EXYNOS7_EMBEDDED_COMBO_PHY_CTRL_EN BIT(0)
> +
> +/* Calibration for phy initialization */
> +static const struct samsung_ufs_phy_cfg exynos7_pre_init_cfg[] = {
> + PHY_COMN_REG_CFG(0x00f, 0xfa, PWR_MODE_ANY),
> + PHY_COMN_REG_CFG(0x010, 0x82, PWR_MODE_ANY),
> + PHY_COMN_REG_CFG(0x011, 0x1e, PWR_MODE_ANY),
> + PHY_COMN_REG_CFG(0x017, 0x84, PWR_MODE_ANY),
> + PHY_TRSV_REG_CFG(0x035, 0x58, PWR_MODE_ANY),
> + PHY_TRSV_REG_CFG(0x036, 0x32, PWR_MODE_ANY),
> + PHY_TRSV_REG_CFG(0x037, 0x40, PWR_MODE_ANY),
> + PHY_TRSV_REG_CFG(0x03b, 0x83, PWR_MODE_ANY),
> + PHY_TRSV_REG_CFG(0x042, 0x88, PWR_MODE_ANY),
> + PHY_TRSV_REG_CFG(0x043, 0xa6, PWR_MODE_ANY),
> + PHY_TRSV_REG_CFG(0x048, 0x74, PWR_MODE_ANY),
> + PHY_TRSV_REG_CFG(0x04c, 0x5b, PWR_MODE_ANY),
> + PHY_TRSV_REG_CFG(0x04d, 0x83, PWR_MODE_ANY),
> + PHY_TRSV_REG_CFG(0x05c, 0x14, PWR_MODE_ANY),
> + END_UFS_PHY_CFG
> +};
> +
> +static const struct samsung_ufs_phy_cfg exynos7_post_init_cfg[] = {
> + END_UFS_PHY_CFG
> +};
> +
> +/* Calibration for HS mode series A/B */
> +static const struct samsung_ufs_phy_cfg exynos7_pre_pwr_hs_cfg[] = {
> + PHY_COMN_REG_CFG(0x00f, 0xfa, PWR_MODE_HS_ANY),
> + PHY_COMN_REG_CFG(0x010, 0x82, PWR_MODE_HS_ANY),
> + PHY_COMN_REG_CFG(0x011, 0x1e, PWR_MODE_HS_ANY),
> + /* Setting order: 1st(0x16, 2nd(0x15) */
> + PHY_COMN_REG_CFG(0x016, 0xff, PWR_MODE_HS_ANY),
> + PHY_COMN_REG_CFG(0x015, 0x80, PWR_MODE_HS_ANY),
> + PHY_COMN_REG_CFG(0x017, 0x94, PWR_MODE_HS_ANY),
> + PHY_TRSV_REG_CFG(0x036, 0x32, PWR_MODE_HS_ANY),
> + PHY_TRSV_REG_CFG(0x037, 0x43, PWR_MODE_HS_ANY),
> + PHY_TRSV_REG_CFG(0x038, 0x3f, PWR_MODE_HS_ANY),
> + PHY_TRSV_REG_CFG(0x042, 0x88, PWR_MODE_HS_G2_SER_A),
> + PHY_TRSV_REG_CFG(0x042, 0xbb, PWR_MODE_HS_G2_SER_B),
> + PHY_TRSV_REG_CFG(0x043, 0xa6, PWR_MODE_HS_ANY),
> + PHY_TRSV_REG_CFG(0x048, 0x74, PWR_MODE_HS_ANY),
> +
Re: [PATCH v12 06/10] KVM: x86: Add userspace access interface for CET MSRs
Hi Yang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on vhost/linux-next]
[also build test ERROR on tip/auto-latest linus/master v5.7-rc4 next-20200505]
[cannot apply to kvm/linux-next linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Yang-Weijiang/Introduce-support-for-guest-CET-feature/20200507-021021
base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
arch/x86/kvm/x86.c: In function 'kvm_set_cr0':
arch/x86/kvm/x86.c:808:53: error: 'X86_CR4_CET' undeclared (first use in
this function); did you mean 'X86_CR0_ET'?
if (!(cr0 & X86_CR0_WP) && kvm_read_cr4_bits(vcpu, X86_CR4_CET))
^~~
X86_CR0_ET
arch/x86/kvm/x86.c:808:53: note: each undeclared identifier is reported only
once for each function it appears in
arch/x86/kvm/x86.c: At top level:
arch/x86/kvm/x86.c:1232:16: error: 'MSR_IA32_U_CET' undeclared here (not in
a function); did you mean 'MSR_IA32_TSC'?
MSR_IA32_XSS, MSR_IA32_U_CET, MSR_IA32_S_CET,
^~
MSR_IA32_TSC
arch/x86/kvm/x86.c:1232:32: error: 'MSR_IA32_S_CET' undeclared here (not in
a function); did you mean 'MSR_IA32_U_CET'?
MSR_IA32_XSS, MSR_IA32_U_CET, MSR_IA32_S_CET,
^~
MSR_IA32_U_CET
arch/x86/kvm/x86.c:1233:2: error: 'MSR_IA32_PL0_SSP' undeclared here (not in
a function); did you mean 'MSR_IA32_MCG_ESP'?
MSR_IA32_PL0_SSP, MSR_IA32_PL1_SSP, MSR_IA32_PL2_SSP,
^~~~
MSR_IA32_MCG_ESP
arch/x86/kvm/x86.c:1233:20: error: 'MSR_IA32_PL1_SSP' undeclared here (not
in a function); did you mean 'MSR_IA32_PL0_SSP'?
MSR_IA32_PL0_SSP, MSR_IA32_PL1_SSP, MSR_IA32_PL2_SSP,
^~~~
MSR_IA32_PL0_SSP
arch/x86/kvm/x86.c:1233:38: error: 'MSR_IA32_PL2_SSP' undeclared here (not
in a function); did you mean 'MSR_IA32_PL1_SSP'?
MSR_IA32_PL0_SSP, MSR_IA32_PL1_SSP, MSR_IA32_PL2_SSP,
^~~~
MSR_IA32_PL1_SSP
arch/x86/kvm/x86.c:1234:2: error: 'MSR_IA32_PL3_SSP' undeclared here (not in
a function); did you mean 'MSR_IA32_PL2_SSP'?
MSR_IA32_PL3_SSP, MSR_IA32_INT_SSP_TAB,
^~~~
MSR_IA32_PL2_SSP
arch/x86/kvm/x86.c:1234:20: error: 'MSR_IA32_INT_SSP_TAB' undeclared here
(not in a function); did you mean 'MSR_IA32_PL3_SSP'?
MSR_IA32_PL3_SSP, MSR_IA32_INT_SSP_TAB,
^~~~
MSR_IA32_PL3_SSP
arch/x86/kvm/x86.c: In function 'is_xsaves_msr':
arch/x86/kvm/x86.c:3278:15: error: comparison between pointer and integer
[-Werror]
return index == MSR_IA32_U_CET ||
^~
arch/x86/kvm/x86.c:3279:16: error: comparison between pointer and integer
[-Werror]
(index >= MSR_IA32_PL0_SSP && index <= MSR_IA32_PL3_SSP);
^~
arch/x86/kvm/x86.c:3279:45: error: comparison between pointer and integer
[-Werror]
(index >= MSR_IA32_PL0_SSP && index <= MSR_IA32_PL3_SSP);
^~
arch/x86/kvm/x86.c: In function 'kvm_arch_hardware_setup':
arch/x86/kvm/x86.c:191:34: error: 'XFEATURE_MASK_CET_USER' undeclared (first
use in this function); did you mean 'XFEATURE_MASK_BNDCSR'?
#define KVM_SUPPORTED_XSS (XFEATURE_MASK_CET_USER | \
^
arch/x86/kvm/x86.c:9707:30: note: in expansion of macro 'KVM_SUPPORTED_XSS'
supported_xss = host_xss & KVM_SUPPORTED_XSS;
^
arch/x86/kvm/x86.c:192:6: error: 'XFEATURE_MASK_CET_KERNEL' undeclared
(first use in this function); did you mean 'XFEATURE_MASK_CET_USER'?
XFEATURE_MASK_CET_KERNEL)
^
arch/x86/kvm/x86.c:9707:30: note: in expansion of macro 'KVM_SUPPORTED_XSS'
supported_xss = host_xss & KVM_SUPPORTED_XSS;
^
arch/x86/kvm/x86.c:191:57: error: invalid operands to binary | (have 'const
u32 * {aka const unsigned int *}' and 'const u32 * {aka const unsigned int *}')
#define KVM_SUPPORTED_XSS (XFEATURE_MASK_CET_USER | \
Re: [PATCH v2 1/2] cpufreq: qoriq: convert to a platform driver
On 28-04-20, 16:31, Viresh Kumar wrote: > On 21-04-20, 10:29, Mian Yousaf Kaukab wrote: > > The driver has to be manually loaded if it is built as a module. It > > is neither exporting MODULE_DEVICE_TABLE nor MODULE_ALIAS. Moreover, > > no platform-device is created (and thus no uevent is sent) for the > > clockgen nodes it depends on. > > > > Convert the module to a platform driver with its own alias. Moreover, > > drop whitelisted SOCs. Platform device will be created only for the > > compatible platforms. > > > > Reviewed-by: Yuantian Tang > > Acked-by: Viresh Kumar > > Signed-off-by: Mian Yousaf Kaukab > > --- > > v2: > > +Rafael, Stephen, linux-clk > > Add Reviewed-by and Acked-by tags > > > > drivers/cpufreq/qoriq-cpufreq.c | 76 > > - > > 1 file changed, 29 insertions(+), 47 deletions(-) > > @Rafael, > > Though this looks to be PPC stuff, but it is used on both ARM and PPC. Do you > want to pick them up or should I do that ? Applied now. Thanks. -- viresh
[PATCH -next] visorbus: fix error return code in visorchipset_init()
Fix to return negative error code -ENODEV from the visor_check_channel()
error handling case instead of 0. Also change the error code to -ENOMEM
in kzalloc() error case.
Signed-off-by: Wei Yongjun
---
drivers/visorbus/visorchipset.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/visorbus/visorchipset.c b/drivers/visorbus/visorchipset.c
index cb1eb7e05f87..5668cad86e37 100644
--- a/drivers/visorbus/visorchipset.c
+++ b/drivers/visorbus/visorchipset.c
@@ -1561,7 +1561,7 @@ static void controlvm_periodic_work(struct work_struct
*work)
static int visorchipset_init(struct acpi_device *acpi_device)
{
- int err = -ENODEV;
+ int err = -ENOMEM;
struct visorchannel *controlvm_channel;
chipset_dev = kzalloc(sizeof(*chipset_dev), GFP_KERNEL);
@@ -1584,8 +1584,10 @@ static int visorchipset_init(struct acpi_device
*acpi_device)
"controlvm",
sizeof(struct visor_controlvm_channel),
VISOR_CONTROLVM_CHANNEL_VERSIONID,
-VISOR_CHANNEL_SIGNATURE))
+VISOR_CHANNEL_SIGNATURE)) {
+ err = -ENODEV;
goto error_delete_groups;
+ }
/* if booting in a crash kernel */
if (is_kdump_kernel())
INIT_DELAYED_WORK(_dev->periodic_controlvm_work,
[PATCH] input/misc/drv260x: Remove a useless comparison
Fix the following warning:
'mode' and 'library' are u32, they are never be negative,
DRV260X_LRA_MODE and DRV260X_LIB_EMPTY are 0x00, the comparison
is always false.
drivers/input/misc/drv260x.c:478:20: warning:
comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (haptics->mode < DRV260X_LRA_MODE ||
drivers/input/misc/drv260x.c:490:23: warning:
comparison of unsigned expression < 0 is always false [-Wtype-limits]
if (haptics->library < DRV260X_LIB_EMPTY ||
Reported-by: Hulk Robot
Signed-off-by: ChenTao
---
drivers/input/misc/drv260x.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/misc/drv260x.c b/drivers/input/misc/drv260x.c
index 79d7fa710a71..0078f742df5c 100644
--- a/drivers/input/misc/drv260x.c
+++ b/drivers/input/misc/drv260x.c
@@ -475,8 +475,7 @@ static int drv260x_probe(struct i2c_client *client,
return error;
}
- if (haptics->mode < DRV260X_LRA_MODE ||
- haptics->mode > DRV260X_ERM_MODE) {
+ if (haptics->mode > DRV260X_ERM_MODE) {
dev_err(dev, "Vibrator mode is invalid: %i\n", haptics->mode);
return -EINVAL;
}
@@ -487,8 +486,7 @@ static int drv260x_probe(struct i2c_client *client,
return error;
}
- if (haptics->library < DRV260X_LIB_EMPTY ||
- haptics->library > DRV260X_ERM_LIB_F) {
+ if (haptics->library > DRV260X_ERM_LIB_F) {
dev_err(dev,
"Library value is invalid: %i\n", haptics->library);
return -EINVAL;
--
2.22.0
Re: [PATCH] media: usb: ttusb-dec: avoid buffer overflow in ttusb_dec_handle_irq() when DMA failures/attacks occur
On 2020/5/7 1:43, Greg KH wrote: On Thu, May 07, 2020 at 12:48:47AM +0800, Jia-Ju Bai wrote: Yes, I agree that this issue is not new, because DMA attacks are old problems. But I am a little surprised that many current drivers are still vulnerable to DMA attacks. Given that the attack vector is very hard to actually do, that's not a suprise. It's only a very recent thing that Linux drivers have started to work on "we don't trust the data coming from the hardware" path. Previously we always trusted that, but did not trust data coming from userspace. So work on fixing up drivers in this area is always encouraged. An example of this would be all of the fuzzing that USB drivers have been getting with custom loop-back interfaces and the like over the past year or so. Expanding that to "we don't trust PCI device data" should be the next step on this, and would help out your area as well. Okay, I am glad to hear that :) Hardware security for the Linux kernel should receive more attention. Last year some researchers finished an interesting work about fuzzing the inputs from hardware: https://github.com/securesystemslab/periscope If you trust a device enough to plug it in, well, you need to trust it :) Well, maybe I need to trust all devices in my computer :) Anyway, thanks a lot for your patient explanation and reply. If you have encountered other kinds of DMA-related bugs/vulnerabilities, maybe I can help to detect them using my static-analysis tool :) Did you only find a problem in this one driver? Have you run it on any more "complex" drivers and gotten any good results showing either that we are programming defensively in this area, or not? At present, I only detect the cases that a DMA value *directly* taints array index, loop condition and important kernel-interface calls (such as request_irq()). In this one driver, I only find two problems that mentioned in this patch. With the kernel configuration "allyesconfig" in my x86_64 machine, I find nearly 200 such problems (intra-procedurally and inter-procedurally) in all the compiled device drivers. I also find that several drivers check the data from DMA memory, but some of these checks can be bypassed. Here is an example in drivers/scsi/esas2r/esas2r_vda.c: The function esas2r_read_vda() uses a DMA value "vi": struct atto_ioctl_vda *vi = (struct atto_ioctl_vda *)a->vda_buffer; Then esas2r_read_vda() calls esas2r_process_vda_ioctl() with vi: esas2r_process_vda_ioctl(a, vi, rq, ); In esas2r_process_vda_ioctl(), the DMA value "vi->function" is used at many places, such as: if (vi->function >= vercnt) ... if (vi->version > esas2r_vdaioctl_versions[vi->function]) ... However, when DMA failures or attacks occur, the value of vi->function can be changed at any time. In this case, vi->function can be first smaller than vercnt, and then it can be larger than vercnt when it is used as the array index of esas2r_vdaioctl_versions, causing a buffer-overflow vulnerability. I also submitted this patch, but no one has replied yet: https://lore.kernel.org/lkml/20200504172412.25985-1-baijiaju1...@gmail.com/ Best wishes, Jia-Ju Bai
Re: [PATCH] slub: limit count of partial slabs scanned to gather statistics
On 07/05/2020 06.01, Qian Cai wrote:
On May 6, 2020, at 3:06 PM, Qian Cai wrote:
On May 4, 2020, at 12:07 PM, Konstantin Khlebnikov
wrote:
To get exact count of free and used objects slub have to scan list of
partial slabs. This may take at long time. Scanning holds spinlock and
blocks allocations which move partial slabs to per-cpu lists and back.
Example found in the wild:
# cat /sys/kernel/slab/dentry/partial
14478538 N0=7329569 N1=7148969
# time cat /sys/kernel/slab/dentry/objects
286225471 N0=136967768 N1=149257703
real0m1.722s
user0m0.001s
sys 0m1.721s
The same problem in slab was addressed in commit f728b0a5d72a ("mm, slab:
faster active and free stats") by adding more kmem cache statistics.
For slub same approach requires atomic op on fast path when object frees.
Let's simply limit count of scanned slabs and print warning.
Limit set in /sys/module/slub/parameters/max_partial_to_count.
Default is 1 which should be enough for most sane cases.
Return linear approximation if list of partials is longer than limit.
Nobody should notice difference.
Signed-off-by: Konstantin Khlebnikov
This patch will trigger the warning under memory pressure, and then makes
lockdep unhappy. Also, it is almost impossible tell how many
max_partial_to_count is sufficient from user perspective.
Oops, my bad. Printing under this lock indeed a bad idea.
Probably it's better to simply remove this message.
I cannot imagine situation when precise count of object matters at such scale.
Andrew, Stephen, can you remove this patch from linux-next?
Even read some procfs files would trigger the warning and lockdep on a debug
kernel probably due to kmemleak and debugobjects that would require more
partial slabs objects. Thus, it would be problematic to break testing bots on
linux-next like this.
[ 6371.600511] SLUB: too much partial slabs to count all objects, increase
max_partial_to_count.
[ 6371.601399] irq event stamp: 8132599
[ 6371.611415] ==
[ 6371.611417] WARNING: possible circular locking dependency detected
[ 6371.611419] 5.7.0-rc4-mm1+ #1 Not tainted
[ 6371.611421] --
[ 6371.611423] oom02/43515 is trying to acquire lock:
[ 6371.611425] 893b8980 (console_owner){-.-.}-{0:0}, at:
console_unlock+0x240/0x750
[ 6371.611433] but task is already holding lock:
[ 6371.611434] 8886456fcb98 (>list_lock){-.-.}-{2:2}, at:
count_partial+0x29/0xe0
[ 6371.611441] which lock already depends on the new lock.
[ 6371.611445] the existing dependency chain (in reverse order) is:
[ 6371.611446] -> #3 (>list_lock){-.-.}-{2:2}:
[ 6371.611452]_raw_spin_lock+0x2f/0x40
[ 6371.611453]deactivate_slab+0x37a/0x690
[ 6371.611455]___slab_alloc+0x65d/0x810
[ 6371.611456]__slab_alloc+0x43/0x70
[ 6371.611457]__kmalloc+0x2b2/0x430
[ 6371.611459]__tty_buffer_request_room+0x100/0x250
[ 6371.611460]tty_insert_flip_string_fixed_flag+0x67/0x130
[ 6371.611462]pty_write+0xa2/0xf0
[ 6371.611463]n_tty_write+0x36b/0x7c0
[ 6371.611464]tty_write+0x275/0x500
[ 6371.611466]__vfs_write+0x50/0xa0
[ 6371.611467]vfs_write+0x10b/0x290
[ 6371.611468]redirected_tty_write+0x6a/0xc0
[ 6371.611470]do_iter_write+0x253/0x2b0
[ 6371.611471]vfs_writev+0x152/0x1f0
[ 6371.611472]do_writev+0xda/0x180
[ 6371.611474]__x64_sys_writev+0x45/0x50
[ 6371.611475]do_syscall_64+0xcc/0xaf0
[ 6371.611477]entry_SYSCALL_64_after_hwframe+0x49/0xb3
[ 6371.611478] -> #2 (>lock#2){-.-.}-{2:2}:
[ 6371.611484]_raw_spin_lock_irqsave+0x3a/0x50
[ 6371.611486]tty_port_tty_get+0x22/0xa0
[ 6371.611487]tty_port_default_wakeup+0xf/0x30
[ 6371.611489]tty_port_tty_wakeup+0x39/0x40
[ 6371.611490]uart_write_wakeup+0x2a/0x40
[ 6371.611492]serial8250_tx_chars+0x22e/0x410
[ 6371.611493]serial8250_handle_irq.part.21+0x17c/0x180
[ 6371.611495]serial8250_default_handle_irq+0x5c/0x90
[ 6371.611496]serial8250_interrupt+0xa6/0x130
[ 6371.611498]__handle_irq_event_percpu+0x81/0x550
[ 6371.611499]handle_irq_event_percpu+0x70/0x100
[ 6371.611501]handle_irq_event+0x5a/0x8b
[ 6371.611502]handle_edge_irq+0x10c/0x370
[ 6371.611503]do_IRQ+0x9e/0x1d0
[ 6371.611505]ret_from_intr+0x0/0x37
[ 6371.611506]cpuidle_enter_state+0x148/0x910
[ 6371.611507]cpuidle_enter+0x41/0x70
[ 6371.611509]do_idle+0x3cf/0x440
[ 6371.611510]cpu_startup_entry+0x1d/0x1f
[ 6371.611511]start_secondary+0x29a/0x340
[ 6371.611513]secondary_startup_64+0xb6/0xc0
[ 6371.611516] -> #1 (>lock){-.-.}-{2:2}:
[ 6371.611522]_raw_spin_lock_irqsave+0x3a/0x50
[ 6371.611525]serial8250_console_write+0x113/0x560
[ 6371.611527]univ8250_console_write+0x4b/0x60
[ 6371.611529]
Re: [PATCH] printk: Add loglevel for "do not print to consoles".
On 2020/05/07 10:02, Joe Perches wrote:
>>> printk_get_level / printk_skip_level and the various
>>> uses of %pV using printk_get_level
>>>
>>
>> Excuse me, but what do you mean?
>>
>> I wish printk() accepts "loglevel" argument detached from "fmt" argument
>> (e.g.
>
> I think that's a bad idea as it would expand
> _every_ use of printk with another argument
> and overall code size would increase for very
> little value.
I'm not saying that we should add loglevel argument to all printk() callers.
I'm saying that we could add a variant of printk() which accepts loglevel
argument (say, e.g. printkl() and vprintkl()).
I think that some of printk_get_level() users are using printk_get_level() only
for detaching loglevel argument from fmt argument.
For example, fs/f2fs/f2fs.h defines f2fs_{err,warn,notice,info,debug}() which
pass
KERN_* to f2fs_printk(), but f2fs_printk() in fs/f2fs/super.c trims KERN_* and
passes
it back to printk(). If printkl() were there, f2fs_err() etc. can directly call
printkl() (and avoids printk_get_level(), printk_skip_level() and "struct
va_format").
fs/btrfs/ctree.h similarly defines
btrfs_{emerg,alert,crit,err,warn,notice,info}() and
their RCU and latelimited variants which pass KERN_* to btrfs_printk(), but
btrfs_printk() in fs/btrfs/super.c trims KERN_* and passes it back to printk().
If printkl() were there, btrfs_emerg() etc. can avoid printk_get_level() and
printk_skip_level().
sound/core/misc.c defines __snd_printk() which allows inserting filename and
line number.
If printkl() were there, __snd_printk() can avoid printk_get_level() and
printk_skip_level(),
and can constify format argument variable (which is currently writable just in
order to embed
loglevel argument).
I don't know how the lockless logbuf will replace printk_safe_flush_buffer().
But I guess
it is possible to avoid printk_safe_flush_buffer() and printk_skip_level() as
demonstrated
by
https://lkml.kernel.org/r/5e192ca2-3b24-0b45-fc13-51feec43c...@i-love.sakura.ne.jp
.
Then, printk_skip_headers() will be the only user of printk_skip_level(). I
don't know how
vkdb_printf() works, but vkdb_printf() is currently using printk_skip_level()
in order to
remove loglevel argument. We can avoid printk_skip_level() if loglevel argument
is detached
from fmt argument.
>
> And do look at the code and uses of printk_get_level.
And again, what am I missing?
Re: [PATCH 15/15] x86: use non-set_fs based maccess routines
On Wed, May 06, 2020 at 12:01:32PM -0700, Linus Torvalds wrote:
> Oh, absolutely. I did *NOT* mean that you'd use "unsafe_get_user()" as
> the actual interface. I just meant that as an implementation detail on
> x86, using "unsafe_get_user()" instead of "__get_user_size()"
> internally both simplifies the implementation, and means that it
> doesn't clash horribly with my local changes.
I had a version that just wrapped them, but somehow wasn't able to
make it work due to all the side effects vs macros issues. Maybe I
need to try again, the current version seemed like a nice way out
as it avoided a lot of the silly casting.
> Btw, that brings up another issue: so that people can't mis-use those
> kernel accessors and use them for user addresses, they probably should
> actually do something like
>
> if ((long)addr >= 0)
> goto error_label;
>
> on x86. IOW, have the "strict" kernel pointer behavior.
>
> Otherwise somebody will start using them for user pointers, and it
> will happen to work on old x86 without CLAC/STAC support.
>
> Of course, maybe CLAC/STAC is so common these days (at least with
> developers) that we don't have to worry about it.
The actual public routines (probe_kernel_read and co) get these
checks through probe_kernel_read_allowed, which is implemented by
the x86 code. Doing this for every 1-8 byte access might be a little
slow, though. Do you really fear drivers starting to use the low-level
helper? Maybe we need to move those into a different header than
that makes it more clear that they are internal?
> But here you see what it is, if you want to. __get_user_size()
> technically still exists, but it has the "target branch" semantics in
> here, so your patch clashes badly with it.
The target branch semantics actually are what I want, that is how the
maccess code is structured. This is the diff I'd need for the calling
conventions in your bundle:
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 765e18417b3ba..d1c8aacedade1 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -526,14 +526,8 @@ do {
\
#define HAVE_ARCH_PROBE_KERNEL
#define arch_kernel_read(dst, src, type, err_label)\
-do { \
-int __kr_err; \
- \
__get_user_size(*((type *)dst), (__force type __user *)src, \
- sizeof(type), __kr_err);\
-if (unlikely(__kr_err))
\
- goto err_label; \
-} while (0)
+ sizeof(type), err_label); \
#define arch_kernel_write(dst, src, type, err_label) \
__put_user_size(*((type *)(src)), (__force type __user *)(dst), \
[rcu:kcsan-dev] BUILD SUCCESS 50a19ad4b1ec531eb550183cb5d4ab9f25a56bf8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git kcsan-dev branch HEAD: 50a19ad4b1ec531eb550183cb5d4ab9f25a56bf8 objtool, kcsan: Add kcsan_disable_current() and kcsan_enable_current_nowarn() elapsed time: 483m configs tested: 174 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm allyesconfig arm64allmodconfig arm allmodconfig arm64 allnoconfig arm allnoconfig sparcallyesconfig m68k allyesconfig ia64 allyesconfig i386 allnoconfig s390 allmodconfig csky allyesconfig mips allyesconfig riscv defconfig openriscdefconfig powerpc defconfig h8300allmodconfig ia64 alldefconfig xtensa defconfig openrisc allyesconfig um allmodconfig nds32 defconfig i386 allyesconfig i386 alldefconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig m68k allmodconfig m68k sun3_defconfig m68k multi_defconfig m68kdefconfig nios2 defconfig nios2allyesconfig c6x allyesconfig c6x allnoconfig nds32 allnoconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig arc allyesconfig microblaze allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips 64r6el_defconfig mips allnoconfig mips 32r2_defconfig mips allmodconfig pariscallnoconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc alldefconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig m68k randconfig-a001-20200506 mips randconfig-a001-20200506 nds32randconfig-a001-20200506 parisc randconfig-a001-20200506 alpharandconfig-a001-20200506 riscvrandconfig-a001-20200506 m68k randconfig-a001-20200507 mips randconfig-a001-20200507 nds32randconfig-a001-20200507 parisc randconfig-a001-20200507 alpharandconfig-a001-20200507 riscvrandconfig-a001-20200507 h8300randconfig-a001-20200506 nios2randconfig-a001-20200506 microblaze randconfig-a001-20200506 c6x randconfig-a001-20200506 sparc64 randconfig-a001-20200506 h8300randconfig-a001-20200507 nios2randconfig-a001-20200507 microblaze randconfig-a001-20200507 c6x randconfig-a001-20200507 sparc64 randconfig-a001-20200507 s390 randconfig-a001-20200506 xtensa randconfig-a001-20200506 sh randconfig-a001-20200506 openrisc randconfig-a001-20200506 csky randconfig-a001-20200506 xtensa randconfig-a001-20200507 sh randconfig-a001-20200507 openrisc randconfig-a001-20200507 csky randconfig-a001-20200507 i386 randconfig-b003-20200506 i386 randconfig-b001-20200506 x86_64 randconfig-b001-20200506 x86_64 randconfig-b003-20200506 i386 randconfig-b002-20200506 x86_64 randconfig-c002-20200507 x86_64 randconfig-c001-20200507 i386 randconfig-c002-20200507 i386
[PATCH v3 2/2] PCI: hv: Retry PCI bus D0 entry when the first attempt failed with invalid device state
In the case of kdump, the PCI device was not cleanly shut down
before the kdump kernel starts. This causes the initial
attempt of entering D0 state in the kdump kernel to fail with
invalid device state returned from Hyper-V host.
When this happens, explicitly call PCI bus exit and retry to
enter the D0 state.
Signed-off-by: Wei Hu
---
v2: Incorporate review comments from Michael Kelley, Dexuan Cui and
Bjorn Helgaas
drivers/pci/controller/pci-hyperv.c | 40 +++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pci-hyperv.c
b/drivers/pci/controller/pci-hyperv.c
index e6fac0187722..92092a47d3af 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -2739,6 +2739,8 @@ static void hv_free_config_window(struct hv_pcibus_device
*hbus)
vmbus_free_mmio(hbus->mem_config->start, PCI_CONFIG_MMIO_LENGTH);
}
+static int hv_pci_bus_exit(struct hv_device *hdev, bool keep_devs);
+
/**
* hv_pci_enter_d0() - Bring the "bus" into the D0 power state
* @hdev: VMBus's tracking struct for this root PCI bus
@@ -2751,8 +2753,10 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
struct pci_bus_d0_entry *d0_entry;
struct hv_pci_compl comp_pkt;
struct pci_packet *pkt;
+ bool retry = true;
int ret;
+enter_d0_retry:
/*
* Tell the host that the bus is ready to use, and moved into the
* powered-on state. This includes telling the host which region
@@ -2779,6 +2783,38 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
if (ret)
goto exit;
+ /*
+* In certain case (Kdump) the pci device of interest was
+* not cleanly shut down and resource is still held on host
+* side, the host could return invalid device status.
+* We need to explicitly request host to release the resource
+* and try to enter D0 again.
+*/
+ if (comp_pkt.completion_status < 0 && retry) {
+ retry = false;
+
+ dev_err(>device, "Retrying D0 Entry\n");
+
+ /*
+* Hv_pci_bus_exit() calls hv_send_resource_released()
+* to free up resources of its child devices.
+* In the kdump kernel we need to set the
+* wslot_res_allocated to 255 so it scans all child
+* devices to release resources allocated in the
+* normal kernel before panic happened.
+*/
+ hbus->wslot_res_allocated = 255;
+
+ ret = hv_pci_bus_exit(hdev, true);
+
+ if (ret == 0) {
+ kfree(pkt);
+ goto enter_d0_retry;
+ }
+ dev_err(>device,
+ "Retrying D0 failed with ret %d\n", ret);
+ }
+
if (comp_pkt.completion_status < 0) {
dev_err(>device,
"PCI Pass-through VSP failed D0 Entry with status %x\n",
@@ -3185,7 +3221,7 @@ static int hv_pci_probe(struct hv_device *hdev,
return ret;
}
-static int hv_pci_bus_exit(struct hv_device *hdev, bool hibernating)
+static int hv_pci_bus_exit(struct hv_device *hdev, bool keep_devs)
{
struct hv_pcibus_device *hbus = hv_get_drvdata(hdev);
struct {
@@ -3203,7 +3239,7 @@ static int hv_pci_bus_exit(struct hv_device *hdev, bool
hibernating)
if (hdev->channel->rescind)
return 0;
- if (!hibernating) {
+ if (!keep_devs) {
/* Delete any children which might still exist. */
dr = kzalloc(sizeof(*dr), GFP_KERNEL);
if (dr && hv_pci_start_relations_work(hbus, dr))
--
2.20.1
[PATCH v3 1/2] PCI: hv: Fix the PCI HyperV probe failure path to release resource properly
In some error cases in hv_pci_probe(), allocated resources are not freed.
Fix this by adding a field to keep track of the high water mark for slots
that have resources allocated to them. In case of an error, this high
water mark is used to know which slots have resources that must be released.
Since slots are numbered starting with zero, a value of -1 indicates no
slots have been allocated resources. There may be unused slots in the range
between slot 0 and the high water mark slot, but these slots are already
ignored by the existing code in the allocate and release loops with the call
to get_pcichild_wslot().
Signed-off-by: Wei Hu
---
v3: Add detailed explanation of this patch in commit log per Lorenzo
Pieralisi's suggestions.
drivers/pci/controller/pci-hyperv.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pci-hyperv.c
b/drivers/pci/controller/pci-hyperv.c
index e15022ff63e3..e6fac0187722 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -480,6 +480,9 @@ struct hv_pcibus_device {
struct workqueue_struct *wq;
+ /* Highest slot of child device with resources allocated */
+ int wslot_res_allocated;
+
/* hypercall arg, must not cross page boundary */
struct hv_retarget_device_interrupt retarget_msi_interrupt_params;
@@ -2847,7 +2850,7 @@ static int hv_send_resources_allocated(struct hv_device
*hdev)
struct hv_pci_dev *hpdev;
struct pci_packet *pkt;
size_t size_res;
- u32 wslot;
+ int wslot;
int ret;
size_res = (hbus->protocol_version < PCI_PROTOCOL_VERSION_1_2)
@@ -2900,6 +2903,8 @@ static int hv_send_resources_allocated(struct hv_device
*hdev)
comp_pkt.completion_status);
break;
}
+
+ hbus->wslot_res_allocated = wslot;
}
kfree(pkt);
@@ -2918,10 +2923,10 @@ static int hv_send_resources_released(struct hv_device
*hdev)
struct hv_pcibus_device *hbus = hv_get_drvdata(hdev);
struct pci_child_message pkt;
struct hv_pci_dev *hpdev;
- u32 wslot;
+ int wslot;
int ret;
- for (wslot = 0; wslot < 256; wslot++) {
+ for (wslot = hbus->wslot_res_allocated; wslot >= 0; wslot--) {
hpdev = get_pcichild_wslot(hbus, wslot);
if (!hpdev)
continue;
@@ -2936,8 +2941,12 @@ static int hv_send_resources_released(struct hv_device
*hdev)
VM_PKT_DATA_INBAND, 0);
if (ret)
return ret;
+
+ hbus->wslot_res_allocated = wslot - 1;
}
+ hbus->wslot_res_allocated = -1;
+
return 0;
}
@@ -3037,6 +3046,7 @@ static int hv_pci_probe(struct hv_device *hdev,
if (!hbus)
return -ENOMEM;
hbus->state = hv_pcibus_init;
+ hbus->wslot_res_allocated = -1;
/*
* The PCI bus "domain" is what is called "segment" in ACPI and other
@@ -3136,7 +3146,7 @@ static int hv_pci_probe(struct hv_device *hdev,
ret = hv_pci_allocate_bridge_windows(hbus);
if (ret)
- goto free_irq_domain;
+ goto exit_d0;
ret = hv_send_resources_allocated(hdev);
if (ret)
@@ -3154,6 +3164,8 @@ static int hv_pci_probe(struct hv_device *hdev,
free_windows:
hv_pci_free_bridge_windows(hbus);
+exit_d0:
+ (void) hv_pci_bus_exit(hdev, true);
free_irq_domain:
irq_domain_remove(hbus->irq_domain);
free_fwnode:
--
2.20.1
[PATCH v3 0/2] Fix PCI HyperV device error handling
This series better handles some PCI HyperV error cases in general and for kdump case. Some of review comments from previous individual patch reviews, including splitting into separate patches, have already been incorporated. Thanks Lorenzo Pieralisi for the review and suggestions, as well as Michael Kelley's contribution to the commit log. Thanks, Wei Wei Hu (2): PCI: hv: Fix the PCI HyperV probe failure path to release resource properly PCI: hv: Retry PCI bus D0 entry when the first attempt failed with invalid device state drivers/pci/controller/pci-hyperv.c | 60 ++--- 1 file changed, 54 insertions(+), 6 deletions(-) -- 2.20.1
Re: [PATCH v29 00/20] Intel SGX foundations
On Wed, 06 May 2020 17:14:22 -0500, Sean Christopherson
wrote:
On Wed, May 06, 2020 at 05:42:42PM -0400, Nathaniel McCallum wrote:
Tested on Enarx. This requires a patch[0] for v29 support.
Tested-by: Nathaniel McCallum
However, we did uncover a small usability issue. See below.
[0]:
https://github.com/enarx/enarx/pull/507/commits/80da2352aba46aa7bc6b4d1fccf20fe1bda58662
...
> * Disallow mmap(PROT_NONE) from /dev/sgx. Any mapping (e.g.
anonymous) can
> be used to reserve the address range. Now /dev/sgx supports only
opaque
> mappings to the (initialized) enclave data.
The statement "Any mapping..." isn't actually true.
Enarx creates a large enclave (currently 64GiB). This worked when we
created a file-backed mapping on /dev/sgx/enclave. However, switching
to an anonymous mapping fails with ENOMEM. We suspect this is because
the kernel attempts to allocate all the pages and zero them but there
is insufficient RAM available. We currently work around this by
creating a shared mapping on /dev/zero.
Hmm, the kernel shouldn't actually allocate physical pages unless they're
written. I'll see if I can reproduce.
For larger size mmap, I think it requires enabling vm overcommit mode 1:
echo 1 | sudo tee /proc/sys/vm/overcommit_memory
If we want to keep this mmap() strategy, we probably don't want to
advise mmap(ANON) if it allocates all the memory for the enclave ahead
of time, even if it won't be used. This would be wasteful.
OTOH, having to mmap("/dev/zero") seems a bit awkward.
--
Using Opera's mail client: http://www.opera.com/mail/
[rcu:dev.2020.05.06a] BUILD SUCCESS b93fdeb9aaec0c7769bac9c9333e50789a5d2e50
ps allyesconfig mips 64r6el_defconfig mips allnoconfig mips 32r2_defconfig mips allmodconfig pariscallnoconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc alldefconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig m68k randconfig-a001-20200506 mips randconfig-a001-20200506 nds32randconfig-a001-20200506 parisc randconfig-a001-20200506 alpharandconfig-a001-20200506 riscvrandconfig-a001-20200506 m68k randconfig-a001-20200507 mips randconfig-a001-20200507 nds32randconfig-a001-20200507 parisc randconfig-a001-20200507 alpharandconfig-a001-20200507 riscvrandconfig-a001-20200507 h8300randconfig-a001-20200506 nios2randconfig-a001-20200506 microblaze randconfig-a001-20200506 c6x randconfig-a001-20200506 sparc64 randconfig-a001-20200506 s390 randconfig-a001-20200506 xtensa randconfig-a001-20200506 sh randconfig-a001-20200506 openrisc randconfig-a001-20200506 csky randconfig-a001-20200506 x86_64 randconfig-c002-20200506 i386 randconfig-c002-20200506 i386 randconfig-c003-20200506 i386 randconfig-c001-20200506 i386 randconfig-e003-20200506 x86_64 randconfig-e003-20200506 x86_64 randconfig-e001-20200506 i386 randconfig-e002-20200506 i386 randconfig-e001-20200506 x86_64 randconfig-a003-20200506 x86_64 randconfig-a001-20200506 x86_64 randconfig-a002-20200506 i386 randconfig-a001-20200506 i386 randconfig-a002-20200506 i386 randconfig-a003-20200506 x86_64 randconfig-g003-20200506 i386 randconfig-g003-20200506 i386 randconfig-g002-20200506 x86_64 randconfig-g001-20200506 i386 randconfig-g001-20200506 x86_64 randconfig-g002-20200506 i386 randconfig-h002-20200506 i386 randconfig-h001-20200506 i386 randconfig-h003-20200506 x86_64 randconfig-h002-20200506 x86_64 randconfig-h003-20200506 x86_64 randconfig-h001-20200506 ia64 randconfig-a001-20200507 arm64randconfig-a001-20200507 arc randconfig-a001-20200507 arm randconfig-a001-20200507 sparcrandconfig-a001-20200507 riscvallyesconfig riscv allnoconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 alldefconfig s390defconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig um x86_64_defconfig um i386_defconfig um allyesconfig um defconfig x86_64 rhel x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH V2 08/11] arch/kmap: Ensure kmap_prot visibility
On Sun, May 03, 2020 at 06:09:09PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > We want to support kmap_atomic_prot() on all architectures and it makes > sense to define kmap_atomic() to use the default kmap_prot. > > So we ensure all arch's have a globally available kmap_prot either as a > define or exported symbol. > > Signed-off-by: Ira Weiny Looks good, Reviewed-by: Christoph Hellwig
linux-next: manual merge of the chrome-platform tree with the pstore tree
Hi all,
Today's linux-next merge of the chrome-platform tree got a conflict in:
drivers/platform/chrome/chromeos_pstore.c
between commit:
7bddec15c574 ("pstore/ram: Introduce max_reason and convert dump_oops")
from the pstore tree and commit:
1c7c51347f2e ("platform/chrome: chromeos_pstore: set user space log size")
from the chrome-platform tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/platform/chrome/chromeos_pstore.c
index fa51153688b4,82dea8cb5da1..
--- a/drivers/platform/chrome/chromeos_pstore.c
+++ b/drivers/platform/chrome/chromeos_pstore.c
@@@ -57,7 -57,8 +57,8 @@@ static struct ramoops_platform_data chr
.record_size= 0x4,
.console_size = 0x2,
.ftrace_size= 0x2,
+ .pmsg_size = 0x2,
- .dump_oops = 1,
+ .max_reason = KMSG_DUMP_OOPS,
};
static struct platform_device chromeos_ramoops = {
pgpAvvJmbD31x.pgp
Description: OpenPGP digital signature
Re: [PATCH] wcn36xx: Fix error handling path in 'wcn36xx_probe()'
On Wed 06 May 21:36 PDT 2020, Christophe JAILLET wrote:
> In case of error, 'qcom_wcnss_open_channel()' must be undone by a call to
> 'rpmsg_destroy_ept()', as already done in the remove function.
>
> Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to
> rpmsg")
It seems I introduced this bug in f303a9311065 ("wcn36xx: Transition
driver to SMD client"), but your patch should should apply back to your
Fixes, so I think it's good.
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> Signed-off-by: Christophe JAILLET
> ---
> Not 100% sure of the commit for Fixes, but it is consistent with the
> analysis in efad8396e906 where the same call has been added in the remove
> function.
> ---
> drivers/net/wireless/ath/wcn36xx/main.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
> b/drivers/net/wireless/ath/wcn36xx/main.c
> index e49c306e0eef..1acdc13a74fc 100644
> --- a/drivers/net/wireless/ath/wcn36xx/main.c
> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
> @@ -1339,7 +1339,7 @@ static int wcn36xx_probe(struct platform_device *pdev)
> if (addr && ret != ETH_ALEN) {
> wcn36xx_err("invalid local-mac-address\n");
> ret = -EINVAL;
> - goto out_wq;
> + goto out_channel;
> } else if (addr) {
> wcn36xx_info("mac address: %pM\n", addr);
> SET_IEEE80211_PERM_ADDR(wcn->hw, addr);
> @@ -1347,7 +1347,7 @@ static int wcn36xx_probe(struct platform_device *pdev)
>
> ret = wcn36xx_platform_get_resources(wcn, pdev);
> if (ret)
> - goto out_wq;
> + goto out_channel;
>
> wcn36xx_init_ieee80211(wcn);
> ret = ieee80211_register_hw(wcn->hw);
> @@ -1359,6 +1359,8 @@ static int wcn36xx_probe(struct platform_device *pdev)
> out_unmap:
> iounmap(wcn->ccu_base);
> iounmap(wcn->dxe_base);
> +out_channel:
> + rpmsg_destroy_ept(wcn->smd_channel);
> out_wq:
> ieee80211_free_hw(hw);
> out_err:
> --
> 2.25.1
>
Re: [PATCH v2] xhci: Set port link to RxDetect if port is not enabled after resume
> On Apr 28, 2020, at 00:49, Mathias Nyman
> wrote:
>
> On 27.4.2020 12.05, Kai-Heng Feng wrote:
>>
>>
>>> On Apr 23, 2020, at 19:25, Mathias Nyman
>>> wrote:
>>>
>>> Was this roothub port forcefully suspended xhci_bus_suspend()?
>>> i.e. was a bit set in bus_state->bus_suspended for this port?
>>
>> No, it's a USB3 device so it was set to U3 via USB_PORT_FEAT_LINK_STATE.
>
> Logs show port was first forced by xhci_bus_suspend() to U3 ("port 0 not
> suspended" message)
> and only later set to U3 by USB_PORT_FEAT_LINK_STATE.
> Seems line wrong order or race.
The "port 0 not suspended" is actually for 3-1, if we print bus num and port +
1:
[ 213.732977] xhci_hcd :3f:00.0: port 3-1 not suspended
For port 4-1 it's always suspended before suspend the bus.
I'll send a patch to adjust the debug message for better clarity.
>
> while suspended we get a port event about a connect status change,
> showing port link state is in disabled.
> Cherry picked messages:
>
> [ 1330.021450] xhci_hcd :3f:00.0: port 0 not suspended
> [ 1330.036822] xhci_hcd :3f:00.0: Set port 4-1 link state, portsc:
> 0x1203, write 0x11261
> [ 1331.020736] xhci_hcd :3f:00.0: Port change event, 4-1, id 1, portsc:
> 0x20280
> [ 1331.020738] xhci_hcd :3f:00.0: resume root hub
> [ 1331.020741] xhci_hcd :3f:00.0: handle_port_status: starting port
> polling.
>
> If we force the port link state to U3 in xhci_bus_suspend() maybe it would
> make
> sense to try and recover it in xhci_bus_resume(). But only for that forced
> port.
>
> None of the previous suspend/resume cycles in the logs went smooth either.
> Each time device 4-1 was forced to U3 bus xhci_bus_suspend(), and at resume
> the
> link was stuck in polling until timeout, after which it went to compliance
> mode,
> and had to be warm reset to recover.
If my observation above is true, port 4-1 is indeed suspended by
usb_port_suspend() rather than xhci_bus_suspend().
>
> We could add the code to recover USB3 ports from disabled state in case we
> forced them to U3, but the rootcause of theus suspend/resume issues should
> be found as well
Seems like the issue doesn't happen if the host system use S2Idle instead of S3.
However, I can't see any difference in xHCI driver with different suspend
methods.
Maybe the root cause is that, ASMedia controller and SMSC hub are just quirky?
>
> Limiting your code to USB3 devices that xhi_bus_suspend forced to U3 would
> look
> something like this:
>
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 9eca1fe81061..0f16dd936ab8 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -1789,6 +1789,15 @@ int xhci_bus_resume(struct usb_hcd *hcd)
> case XDEV_RESUME:
> /* resume already initiated */
> break;
> + case XDEV_DISABLED:
> + if (hcd->speed >= HCD_USB3) {
> + portsc = xhci_port_state_to_neutral(
> + portsc);
> + portsc &= ~PORT_PLS_MASK;
> + portsc |= PORT_LINK_STROBE |
> + XDEV_RXDETECT;
> + }
> + /* fall through for both USB3 abd USB2 */
> default:
> /* not in a resumeable state, ignore it */
> clear_bit(port_index,
This doesn't work because port 4-1 isn't suspended by xhci_bus_suspend().
Maybe we can restrict the case to ports that are suspended by
USB_PORT_FEAT_LINK_STATE.
Is the following patch looks good to you?
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index f37316d2c8fa..dc2e14ea308d 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1787,6 +1787,16 @@ int xhci_bus_resume(struct usb_hcd *hcd)
clear_bit(port_index, _state->bus_suspended);
continue;
}
+
+ if (bus_state->suspended_ports & (1 << port_index)) {
+ if ((portsc & PORT_PLS_MASK) == XDEV_DISABLED &&
+ hcd->speed >= HCD_USB3) {
+ portsc = xhci_port_state_to_neutral(portsc);
+ portsc &= ~PORT_PLS_MASK;
+ portsc |= PORT_LINK_STROBE | XDEV_RXDETECT;
+ }
+ }
+
/* resume if we suspended the link, and it is still suspended */
if (test_bit(port_index, _state->bus_suspended))
switch (portsc & PORT_PLS_MASK) {
Kai-Heng
>
> -Mathias
Re: x86/uv cleanups
On Wed, May 06, 2020 at 04:36:50PM -0500, Russ Anderson wrote: > In addition to Christoph's patches, we will soon be submitting > additional clean up patches. Mike Travis is working on a patch > to remove old SGI UV1 code. Dimitri Sivanich is working on a > sgi_rtc cleanup patch. We are looking at additional cleanup > that should have been done previously. If you plan to submit these very soon I'll happily defer this cleanup series a bit and can resubmit it on top of your changes.
Re: [PATCH v7 2/3] phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver
+Vinod Hi, On 4/2/2020 3:40 AM, Laurent Pinchart wrote: > From: Anurag Kumar Vulisha > > Xilinx ZynqMP SoCs have a Gigabit Transceiver with four lanes. All the > high speed peripherals such as USB, SATA, PCIE, Display Port and > Ethernet SGMII can rely on any of the four GT lanes for PHY layer. This > patch adds driver for that ZynqMP GT core. > > Signed-off-by: Anurag Kumar Vulisha > Signed-off-by: Laurent Pinchart > --- > Changes since v5: > > - Cleanup headers > - Organize the code in sections > - Constify data tables and structures > - Allocate all PHY instances in one go > - Add I/O accessors > - Move DP-specific init to a separate function > - Use devm_platform_ioremap_resource_byname() > - Simplify acquisition of reset controllers > - Implement .configure() PHY operation for DP > - Implement .power_on() and .power_off() operations > - Wait for PLL lock for DP PHY too > - Remove USB core reset operations > - Fix SGMII bus width settings > - Update copyright notice and authors list > - Disable error messages on probe deferral > - Update reset names to new DT bindings > - Update to removal of subnodes in new DT bindings > - Handle reference clocks through CCF > - Add MAINTAINERS entry > - Drop reset handling > - Split TX term fix to separate function > - Remove unused registers > --- > MAINTAINERS | 9 + > drivers/phy/Kconfig | 8 + > drivers/phy/Makefile | 1 + > drivers/phy/phy-zynqmp.c | 995 +++ Better to add a xilinx directory for this driver. > 4 files changed, 1013 insertions(+) > create mode 100644 drivers/phy/phy-zynqmp.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 07293073c4f6..19e630fcaf62 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -18406,6 +18406,15 @@ F: > Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml > F: drivers/dma/xilinx/xilinx_dpdma.c > F: include/dt-bindings/dma/xlnx-zynqmp-dpdma.h > > +XILINX ZYNQMP GSPTR PHY DRIVER Looks like a typo here, rest of the place seems to use PSGTR > +M: Anurag Kumar Vulisha > +M: Laurent Pinchart > +L: linux-kernel@vger.kernel.org > +T: git https://github.com/Xilinx/linux-xlnx.git > +S: Supported > +F: Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml > +F: drivers/phy/phy-zynqmp.c > + > XILLYBUS DRIVER > M: Eli Billauer > L: linux-kernel@vger.kernel.org > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index b3ed94b98d9b..b8251b9f3d87 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -49,6 +49,14 @@ config PHY_XGENE > help > This option enables support for APM X-Gene SoC multi-purpose PHY. > > +config PHY_XILINX_ZYNQMP > + tristate "Xilinx ZynqMP PHY driver" > + depends on ARCH_ZYNQMP > + select GENERIC_PHY > + help > + Enable this to support ZynqMP High Speed Gigabit Transceiver > + that is part of ZynqMP SoC. > + > source "drivers/phy/allwinner/Kconfig" > source "drivers/phy/amlogic/Kconfig" > source "drivers/phy/broadcom/Kconfig" > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile > index 310c149a9df5..5dc7469f078b 100644 > --- a/drivers/phy/Makefile > +++ b/drivers/phy/Makefile > @@ -8,6 +8,7 @@ obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY) += phy-core-mipi-dphy.o > obj-$(CONFIG_PHY_LPC18XX_USB_OTG)+= phy-lpc18xx-usb-otg.o > obj-$(CONFIG_PHY_XGENE) += phy-xgene.o > obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o > +obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o > obj-$(CONFIG_ARCH_SUNXI) += allwinner/ > obj-$(CONFIG_ARCH_MESON) += amlogic/ > obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/ > diff --git a/drivers/phy/phy-zynqmp.c b/drivers/phy/phy-zynqmp.c > new file mode 100644 > index ..8ab99d6b9220 > --- /dev/null > +++ b/drivers/phy/phy-zynqmp.c > @@ -0,0 +1,995 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * phy-zynqmp.c - PHY driver for Xilinx ZynqMP GT. > + * > + * Copyright (C) 2018-20 Xilinx Inc. > + * > + * Author: Anurag Kumar Vulisha > + * Author: Subbaraya Sundeep > + * Author: Laurent Pinchart > + * > + * This driver is tested for USB, SATA and Display Port currently. > + * Other controllers PCIe and SGMII should also work but that is > + * experimental as of now. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +/* > + * Lane Registers > + */ > + > +/* TX De-emphasis parameters */ > +#define L0_TX_ANA_TM_18 0x0048 > +#define L0_TX_ANA_TM_118 0x01d8 > +#define L0_TX_ANA_TM_118_FORCE_17_0 BIT(0) > + > +/* DN Resistor calibration code parameters */ > +#define L0_TXPMA_ST_30x0b0c > +#define L0_DN_CALIB_CODE 0x3f > + > +/* PMA control parameters */ > +#define L0_TXPMD_TM_45 0x0cb4 > +#define L0_TXPMD_TM_48
Re: [PATCH next] ARM: dts: am437x: fix networking on boards with ksz9031 phy
Hi Grygorii,
thank you for you patches!
On Wed, May 06, 2020 at 10:08:35PM +0300, Grygorii Strashko wrote:
> Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the
> KSZ9031 PHY") the networking is broken on boards:
> am437x-gp-evm
> am437x-sk-evm
> am437x-idk-evm
>
> All above boards have phy-mode = "rgmii" and this is worked before, because
> KSZ9031 PHY started with default RGMII internal delays configuration (TX
> off, RX on 1.2 ns) and MAC provided TX delay. After above commit, the
> KSZ9031 PHY starts handling phy mode properly and disables RX delay, as
> result networking is become broken.
>
> Fix it by switching to phy-mode = "rgmii-rxid" to reflect previous
> behavior.
>
> Cc: Oleksij Rempel
> Cc: Andrew Lunn
> Cc: Philippe Schenker
> Fixes: commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the
> KSZ9031 PHY")
> Signed-off-by: Grygorii Strashko
> ---
> arch/arm/boot/dts/am437x-gp-evm.dts | 2 +-
> arch/arm/boot/dts/am437x-idk-evm.dts | 2 +-
> arch/arm/boot/dts/am437x-sk-evm.dts | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
> b/arch/arm/boot/dts/am437x-gp-evm.dts
> index 811c8cae315b..d692e3b2812a 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -943,7 +943,7 @@
>
> _emac0 {
> phy-handle = <>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-rxid";
> };
>
> {
> diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts
> b/arch/arm/boot/dts/am437x-idk-evm.dts
> index 9f66f96d09c9..a7495fb364bf 100644
> --- a/arch/arm/boot/dts/am437x-idk-evm.dts
> +++ b/arch/arm/boot/dts/am437x-idk-evm.dts
> @@ -504,7 +504,7 @@
>
> _emac0 {
> phy-handle = <>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> };
Do you have here really rgmii-id?
> {
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
> b/arch/arm/boot/dts/am437x-sk-evm.dts
> index 25222497f828..4d5a7ca2e25d 100644
> --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -833,13 +833,13 @@
>
> _emac0 {
> phy-handle = <>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-rxid";
> dual_emac_res_vlan = <1>;
> };
>
> _emac1 {
> phy-handle = <>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-rxid";
> dual_emac_res_vlan = <2>;
> };
>
> --
> 2.17.1
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
[PATCH] wcn36xx: Fix error handling path in 'wcn36xx_probe()'
In case of error, 'qcom_wcnss_open_channel()' must be undone by a call to
'rpmsg_destroy_ept()', as already done in the remove function.
Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to
rpmsg")
Signed-off-by: Christophe JAILLET
---
Not 100% sure of the commit for Fixes, but it is consistent with the
analysis in efad8396e906 where the same call has been added in the remove
function.
---
drivers/net/wireless/ath/wcn36xx/main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
b/drivers/net/wireless/ath/wcn36xx/main.c
index e49c306e0eef..1acdc13a74fc 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -1339,7 +1339,7 @@ static int wcn36xx_probe(struct platform_device *pdev)
if (addr && ret != ETH_ALEN) {
wcn36xx_err("invalid local-mac-address\n");
ret = -EINVAL;
- goto out_wq;
+ goto out_channel;
} else if (addr) {
wcn36xx_info("mac address: %pM\n", addr);
SET_IEEE80211_PERM_ADDR(wcn->hw, addr);
@@ -1347,7 +1347,7 @@ static int wcn36xx_probe(struct platform_device *pdev)
ret = wcn36xx_platform_get_resources(wcn, pdev);
if (ret)
- goto out_wq;
+ goto out_channel;
wcn36xx_init_ieee80211(wcn);
ret = ieee80211_register_hw(wcn->hw);
@@ -1359,6 +1359,8 @@ static int wcn36xx_probe(struct platform_device *pdev)
out_unmap:
iounmap(wcn->ccu_base);
iounmap(wcn->dxe_base);
+out_channel:
+ rpmsg_destroy_ept(wcn->smd_channel);
out_wq:
ieee80211_free_hw(hw);
out_err:
--
2.25.1
Re: [PATCH v4 1/1] scsi: pm: Balance pm_only counter of request queue during system resume
On 2020-05-05 21:55, Can Guo wrote: > During system resume, scsi_resume_device() decreases a request queue's > pm_only counter if the scsi device was quiesced before. But after that, > if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is > still held (non-zero). Current scsi resume hook only sets the RPM status > of the scsi device and its request queue to RPM_ACTIVE, but leaves the > pm_only counter unchanged. This may make the request queue's pm_only > counter remain non-zero after resume hook returns, hence those who are > waiting on the mq_freeze_wq would never be woken up. Fix this by calling > blk_post_runtime_resume() if a sdev's RPM status was RPM_SUSPENDED. Reviewed-by: Bart Van Assche Thank you for having root-caused and fixed this! Bart.
Re: [RFC PATCH v2 3/3] docs: scheduler: Add introduction to scheduler context-switch
On 5/6/20 7:39 AM, john mathew wrote: > From: John Mathew > > Add documentation for introduction to > -context-switch > -x86 context-switch > -MIPS context switch > > Suggested-by: Lukas Bulwahn > Co-developed-by: Mostafa Chamanara > Signed-off-by: Mostafa Chamanara > Co-developed-by: Oleg Tsymbal > Signed-off-by: Oleg Tsymbal > Signed-off-by: John Mathew > --- > Documentation/scheduler/arch-specific.rst | 3 + > Documentation/scheduler/context-switching.rst | 126 ++ > Documentation/scheduler/index.rst | 1 + > .../scheduler/mips-context-switch.rst | 88 > .../scheduler/sched-data-structs.rst | 2 +- > .../scheduler/x86-context-switch.rst | 65 + > 6 files changed, 284 insertions(+), 1 deletion(-) > create mode 100644 Documentation/scheduler/context-switching.rst > create mode 100644 Documentation/scheduler/mips-context-switch.rst > create mode 100644 Documentation/scheduler/x86-context-switch.rst > > diff --git a/Documentation/scheduler/context-switching.rst > b/Documentation/scheduler/context-switching.rst > new file mode 100644 > index ..af79a2c55713 > --- /dev/null > +++ b/Documentation/scheduler/context-switching.rst > @@ -0,0 +1,126 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +== > +Process context switching > +== > + > +Context Switching > +- > + > +Context switching, the switching from a running task to another, > +is done by the context_switch() function defined in > +kernel/sched.c. It is called by __schedule() when a new process has kernel/sched/core.c. > +been selected to run. > + > + The execution flow is as follows: > + > +* prepare_task_switch() performs necessary kernel preparations for the > + context switch and then calls prepare_arch_switch() for architecture > + specific context switch preparation. This call must be paired with a > + subsequent finish_task_switch() after the context switch. The various > + steps are: > + > + - Prepare kcov for context switch. Context switch does switch_mm() to the > +next task's mm, then switch_to() that new task. This means vmalloc'd > +regions which had previously been faulted in can transiently disappear in > +the context of the prev task. Functions instrumented by KCOV may try to > +access a vmalloc'd kcov_area during this window, and result in a > recursive > +fault. This is avoided by setting a new flag: KCOV_IN_CTXSW in kcov_mode > +prior to switching the mm, and cleared once the new task is live. > + - Update sched_info statistics for both the prev and next tasks. > + - Handle perf subsytem context switch from previous task to next. subsystem > +The various steps are: > + > +- Remove perf events for the task being context-switched out. > +- Stop each perf event and update the event value in event->count. > +- Call the context switch callback for PMU with flag indicating > + schedule out. > +- Create a PERF_RECORD_MISC_SWITCH_OUT perf event. > +- Context switch the perf event contexts between the current and next > tasks. > +- Schedule out current cgroup events if cgroup perf events exist on the > + CPU end with '.' period. > + > + - Set TIF_NOTIFY_RESUME flag on the current thread for the Restartable > +sequence mechanism. Restartable sequences allow user-space to perform > +update operations on per-cpu data without requiring heavy-weight atomic > +operations. > + - Fire preempt notifiers. A task can request the scheduler to notify it > +whenever it is preempted or scheduled back in. This allows the task to > +swap any special-purpose registers like the fpu or Intel's VT registers. FPU > + - Claim the next task as running to prevent load balancing run on it. > + > +* arch_start_context_switch() batches the reload of page tables and other > + process state with the actual context switch code for paravirtualized > + guests. > + > +* Transfer the real and anonymous address spaces between the switching tasks. > + Four possible transfer types are: > + > + - kernel task switching to another kernel task > + - user task switching to a kernel task > + - kernel task switching to user task > + - user task switching to user task > + > + For a kernel task switching to kernel task enter_lazy_tlb() is called > + which is an architecture specific implementation to handle a context > + without an mm. Architectures implement lazy tricks to minimize tlb TLB > + flushes here. The active address space from the previous task is > + borrowed (transferred) to the next task. > + > + For a user task switching to kernel task it will have a real address > + space and so its anonymous users counter is incremented. This makes > +
Re: [PATCH 2/5] input: misc: bma150: Conditionally disable bma023 support
On Wed, May 06, 2020 at 08:46:12PM -0700, Jonathan Bakker wrote: > Hi Linus, > > On 2020-05-06 5:46 a.m., Linus Walleij wrote: > > On Sun, May 3, 2020 at 7:22 PM Jonathan Bakker wrote: > > > >> The bma180 IIO driver has been extended for support for bma023. > >> However, this could cause conflicts with this driver. Since some > >> setups may depend upon the evdev setup, disable support in this > >> driver for the bma023 only when the IIO driver is being built. > >> > >> Signed-off-by: Jonathan Bakker > > > > I would just fix this with KConfig instead, like add mutually > > exclusive depends on these two drivers. > > > > Set this input driver as: > > depends on BMA180=n > > > > And the IIO driver as: > > depends on INPUT_BMA150=n > > > > It's a rough measure but this input driver should anyway > > go away. Isn't the driver handle more than bma023? I see bma150 and smb380 ID's. If we go Kconfig route we will be disabling it for them as well when IIO driver is enabled. > > > > Ok, sounds good to me. If I include a patch removing the input > driver, can I just drop this patch entirely? > > The only in-tree user of the input driver (based on i2c ids) is Intel > Mid. Not sure what the kernel policy on dropping drivers is. Do we still support this platform? I'd start there. Thanks. -- Dmitry
[PATCH] sched/fair: Fix typo in comment
check_prempt_curr() -> check_preempt_curr() Signed-off-by: Xianting Tian --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 02f323b85..458ab5521 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6858,7 +6858,7 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p, int wake_ /* * This is possible from callers such as attach_tasks(), in which we -* unconditionally check_prempt_curr() after an enqueue (which may have +* unconditionally check_preempt_curr() after an enqueue (which may have * lead to a throttle). This both saves work and prevents false * next-buddy nomination below. */ -- 2.17.1 - ±¾Óʼþ¼°Æ丽¼þº¬ÓÐлªÈý¼¯Íŵı£ÃÜÐÅÏ¢£¬½öÏÞÓÚ·¢Ë͸øÉÏÃæµØÖ·ÖÐÁгö µÄ¸öÈË»òȺ×é¡£½ûÖ¹ÈκÎÆäËûÈËÒÔÈκÎÐÎʽʹÓ㨰üÀ¨µ«²»ÏÞÓÚÈ«²¿»ò²¿·ÖµØй¶¡¢¸´ÖÆ¡¢ »òÉ¢·¢£©±¾ÓʼþÖеÄÐÅÏ¢¡£Èç¹ûÄú´íÊÕÁ˱¾Óʼþ£¬ÇëÄúÁ¢¼´µç»°»òÓʼþ֪ͨ·¢¼þÈ˲¢É¾³ý±¾ Óʼþ£¡ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
Re: [PATCH -next] iwlwifi: pcie: Use bitwise instead of arithmetic operator for flags
Both of you are right. I neglected, and this patch is wrong. Thanks. On 2020/5/6 23:15, Joe Perches wrote: On Wed, 2020-05-06 at 16:51 +0300, Luciano Coelho wrote: On Tue, 2020-05-05 at 20:19 -0700, Joe Perches wrote: On Wed, 2020-05-06 at 11:07 +0800, Samuel Zou wrote: This silences the following coccinelle warning: "WARNING: sum of probable bitmasks, consider |" I suggest instead ignoring bad and irrelevant warnings. PREFIX_LEN is 32 not 0x20 or BIT(5) PCI_DUMP_SIZE is 352 diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c [] @@ -109,9 +109,9 @@ void iwl_trans_pcie_dump_regs(struct iwl_trans *trans) /* Alloc a max size buffer */ alloc_size = PCI_ERR_ROOT_ERR_SRC + 4 + PREFIX_LEN; - alloc_size = max_t(u32, alloc_size, PCI_DUMP_SIZE + PREFIX_LEN); - alloc_size = max_t(u32, alloc_size, PCI_MEM_DUMP_SIZE + PREFIX_LEN); - alloc_size = max_t(u32, alloc_size, PCI_PARENT_DUMP_SIZE + PREFIX_LEN); + alloc_size = max_t(u32, alloc_size, PCI_DUMP_SIZE | PREFIX_LEN); + alloc_size = max_t(u32, alloc_size, PCI_MEM_DUMP_SIZE | PREFIX_LEN); + alloc_size = max_t(u32, alloc_size, PCI_PARENT_DUMP_SIZE | PREFIX_LEN); buf = kmalloc(alloc_size, GFP_ATOMIC); if (!buf) Yeah, those macros are clearly not bitmasks. I'm dropping this patch. Can the cocci script that generated this warning scripts/coccinelle/misc/orplus.cocci be dropped or improved to validate the likelihood that the defines or constants used are more likely than not are bit values? Maybe these should be defined as hex or BIT or BIT_ULL or GENMASK or the like? Right now it seems it just tests for two constants. .
Re: [PATCH] ath10k: Replace zero-length array with flexible-array
Kalle, On 5/5/20 02:51, Kalle Valo wrote: > > Fails to apply, please rebase on top of ath.git master branch. > > error: patch failed: drivers/net/wireless/ath/ath10k/pci.h:182 > error: drivers/net/wireless/ath/ath10k/pci.h: patch does not apply > stg import: Diff does not apply cleanly > > Patch set to Changes Requested. > Sorry for the late reply. I've had some troubles with my email settings and LKML, recently. I've just sent v2: https://lore.kernel.org/lkml/20200507041127.GA31587@embeddedor/ Thanks -- Gustavo
[PATCH v2] ath10k: Replace zero-length array with flexible-array
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
- Rebase on top of ath.git master branch.
drivers/net/wireless/ath/ath10k/ce.h | 2 +-
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/coredump.h | 4 +--
drivers/net/wireless/ath/ath10k/debug.h| 2 +-
drivers/net/wireless/ath/ath10k/htt.h | 42 +++---
drivers/net/wireless/ath/ath10k/hw.h | 2 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 6 ++--
drivers/net/wireless/ath/ath10k/wmi.h | 42 +++---
8 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.h
b/drivers/net/wireless/ath/ath10k/ce.h
index 9711f0eb9117..75df79d43120 100644
--- a/drivers/net/wireless/ath/ath10k/ce.h
+++ b/drivers/net/wireless/ath/ath10k/ce.h
@@ -110,7 +110,7 @@ struct ath10k_ce_ring {
struct ce_desc_64 *shadow_base;
/* keep last */
- void *per_transfer_context[0];
+ void *per_transfer_context[];
};
struct ath10k_ce_pipe {
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index ceac76553b8f..5c18f6c20462 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -1262,7 +1262,7 @@ struct ath10k {
int coex_gpio_pin;
/* must be last */
- u8 drv_priv[0] __aligned(sizeof(void *));
+ u8 drv_priv[] __aligned(sizeof(void *));
};
static inline bool ath10k_peer_stats_enabled(struct ath10k *ar)
diff --git a/drivers/net/wireless/ath/ath10k/coredump.h
b/drivers/net/wireless/ath/ath10k/coredump.h
index 8bf03e8c1d3a..e760ce1a5f1e 100644
--- a/drivers/net/wireless/ath/ath10k/coredump.h
+++ b/drivers/net/wireless/ath/ath10k/coredump.h
@@ -88,7 +88,7 @@ struct ath10k_dump_file_data {
u8 unused[128];
/* struct ath10k_tlv_dump_data + more */
- u8 data[0];
+ u8 data[];
} __packed;
struct ath10k_dump_ram_data_hdr {
@@ -100,7 +100,7 @@ struct ath10k_dump_ram_data_hdr {
/* length of payload data, not including this header */
__le32 length;
- u8 data[0];
+ u8 data[];
};
/* magic number to fill the holes not copied due to sections in regions */
diff --git a/drivers/net/wireless/ath/ath10k/debug.h
b/drivers/net/wireless/ath/ath10k/debug.h
index 4cbfd9279d6f..997c1c80aba7 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -65,7 +65,7 @@ struct ath10k_pktlog_hdr {
__le16 log_type; /* Type of log information foll this header */
__le16 size; /* Size of variable length log information in bytes */
__le32 timestamp;
- u8 payload[0];
+ u8 payload[];
} __packed;
/* FIXME: How to calculate the buffer size sanely? */
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 8f3710cf28f4..e504be63173a 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -289,12 +289,12 @@ struct htt_rx_ring_setup_hdr {
struct htt_rx_ring_setup_32 {
struct htt_rx_ring_setup_hdr hdr;
- struct htt_rx_ring_setup_ring32 rings[0];
+ struct htt_rx_ring_setup_ring32 rings[];
} __packed;
struct htt_rx_ring_setup_64 {
struct htt_rx_ring_setup_hdr hdr;
- struct htt_rx_ring_setup_ring64 rings[0];
+ struct htt_rx_ring_setup_ring64 rings[];
} __packed;
/*
@@ -732,7 +732,7 @@ struct htt_rx_indication {
* %mpdu_ranges starts
Re: [GIT] Networking
The pull request you sent on Wed, 06 May 2020 20:40:39 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git refs/heads/master has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a811c1fa0a02c062555b54651065899437bacdbe Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH RESEND] tpm: eventlog: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
Also, the following issue shows up due to the flexible-array member
having incomplete type[4]:
drivers/char/tpm/eventlog/tpm2.c: In function ‘tpm2_bios_measurements_start’:
drivers/char/tpm/eventlog/tpm2.c:54:46: error: invalid application of ‘sizeof’
to incomplete type ‘u8[]’ {aka ‘unsigned char[]’}
54 | size = sizeof(struct tcg_pcr_event) - sizeof(event_header->event)
| ^
drivers/char/tpm/eventlog/tpm2.c: In function ‘tpm2_bios_measurements_next’:
drivers/char/tpm/eventlog/tpm2.c:102:10: error: invalid application of ‘sizeof’
to incomplete type ‘u8[]’ {aka ‘unsigned char[]’}
102 |sizeof(event_header->event) + event_header->event_size;
| ^
drivers/char/tpm/eventlog/tpm2.c: In function
‘tpm2_binary_bios_measurements_show’:
drivers/char/tpm/eventlog/tpm2.c:140:10: error: invalid application of ‘sizeof’
to incomplete type ‘u8[]’ {aka ‘unsigned char[]’}
140 |sizeof(event_header->event) + event_header->event_size;
| ^
scripts/Makefile.build:266: recipe for target
'drivers/char/tpm/eventlog/tpm2.o' failed
make[3]: *** [drivers/char/tpm/eventlog/tpm2.o] Error 1
As mentioned above: "Flexible array members have incomplete type, and
so the sizeof operator may not be applied. As a quirk of the original
implementation of zero-length arrays, sizeof evaluates to zero."[1] So,
the sizeof(flexible-array) can be safely removed to fix the error above.
Lastly, prefer sizeof(*ptr) over sizeof(struct foo).
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
[4] https://github.com/KSPP/linux/issues/43
Signed-off-by: Gustavo A. R. Silva
---
Hi,
I'm resending this because LKML is eating some messages, recently.
Sorry for the noise in case you've already received this patch.
Thanks
drivers/char/tpm/eventlog/tpm2.c | 10 +++---
include/linux/tpm_eventlog.h | 2 +-
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/char/tpm/eventlog/tpm2.c b/drivers/char/tpm/eventlog/tpm2.c
index e741b1157525..351a2989b3c6 100644
--- a/drivers/char/tpm/eventlog/tpm2.c
+++ b/drivers/char/tpm/eventlog/tpm2.c
@@ -51,8 +51,7 @@ static void *tpm2_bios_measurements_start(struct seq_file *m,
loff_t *pos)
int i;
event_header = addr;
- size = sizeof(struct tcg_pcr_event) - sizeof(event_header->event)
- + event_header->event_size;
+ size = sizeof(*event_header) + event_header->event_size;
if (*pos == 0) {
if (addr + size < limit) {
@@ -98,8 +97,7 @@ static void *tpm2_bios_measurements_next(struct seq_file *m,
void *v,
event_header = log->bios_event_log;
if (v == SEQ_START_TOKEN) {
- event_size = sizeof(struct tcg_pcr_event) -
- sizeof(event_header->event) + event_header->event_size;
+ event_size = sizeof(*event_header) + event_header->event_size;
marker = event_header;
} else {
event = v;
@@ -136,9 +134,7 @@ static int tpm2_binary_bios_measurements_show(struct
seq_file *m, void *v)
size_t size;
if (v == SEQ_START_TOKEN) {
- size = sizeof(struct tcg_pcr_event) -
- sizeof(event_header->event) + event_header->event_size;
-
+ size = sizeof(*event_header) + event_header->event_size;
temp_ptr = event_header;
if (size > 0)
diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index c253461b1c4e..4f8c90c93c29 100644
--- a/include/linux/tpm_eventlog.h
+++
linux-next: manual merge of the iommu tree with the s390 tree
Hi all,
Today's linux-next merge of the iommu tree got a conflict in:
drivers/iommu/s390-iommu.c
between commit:
d08d6f5d7524 ("s390/pci: adaptation of iommu to multifunction")
from the s390 tree and commit:
522af649e57b ("iommu/s390: Convert to probe/release_device() call-backs")
from the iommu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/iommu/s390-iommu.c
index c60d5c776fc6,610f0828f22d..
--- a/drivers/iommu/s390-iommu.c
+++ b/drivers/iommu/s390-iommu.c
@@@ -166,23 -166,16 +166,16 @@@ static void s390_iommu_detach_device(st
}
}
- static int s390_iommu_add_device(struct device *dev)
+ static struct iommu_device *s390_iommu_probe_device(struct device *dev)
{
- struct iommu_group *group = iommu_group_get_for_dev(dev);
- struct zpci_dev *zdev = to_pci_dev(dev)->sysdata;
+ struct zpci_dev *zdev = to_zpci_dev(dev);
- if (IS_ERR(group))
- return PTR_ERR(group);
-
- iommu_group_put(group);
- iommu_device_link(>iommu_dev, dev);
-
- return 0;
+ return >iommu_dev;
}
- static void s390_iommu_remove_device(struct device *dev)
+ static void s390_iommu_release_device(struct device *dev)
{
- struct zpci_dev *zdev = to_pci_dev(dev)->sysdata;
+ struct zpci_dev *zdev = to_zpci_dev(dev);
struct iommu_domain *domain;
/*
pgpyxqsaetNIX.pgp
Description: OpenPGP digital signature
Re: [PATCH 0/5] iio: accel: Add bma023 support to bma180
Hi Linus, On 2020-05-06 5:47 a.m., Linus Walleij wrote: > On Sun, May 3, 2020 at 7:22 PM Jonathan Bakker wrote: > >> This patchset adds support for the bma023 three axis accelerometer >> to the bma180 IIO driver. The bma023 is found on several ~2010 >> phones, including the first-gen Galaxy S series. >> >> The bma023 differs from later chips (bma180, bma25x) in that it >> has no low power but still working mode and no temperature >> channel. >> >> The bma023 is already supported by a misc input driver (bma150), so >> when both are enabled, the iio driver is preferred. The bma150 >> is very similar to the bma023, but has a temperature channel. >> Support for the bma150 is not added in this patchset. > > I'd say, if it's not too much trouble please also patch in > support for BMA150 and SMB380 to the IIO driver so > we can delete this old Input driver, we have done this > before and thes "input drivers" are just causing headaches > and wasting time for the Input maintainer. > Looking at the bma150, it looks the same. The temperature is implemented slightly differently than on the bma180+ (unsigned vs signed) but should be quite easy to add. I'll add a new patch for it in v2. > It can be in a separate patch set from this one if you > don't want to get stuck on this. > > Yours, > Linus Walleij > Thanks, Jonathan
[PATCH -next] ALSA: sound/ppc: Use bitwise instead of arithmetic operator for flags
Fix the following coccinelle warnings: sound/ppc/pmac.c:729:57-58: WARNING: sum of probable bitmasks, consider | sound/ppc/pmac.c:229:37-38: WARNING: sum of probable bitmasks, consider | Reported-by: Hulk Robot Signed-off-by: Samuel Zou --- sound/ppc/pmac.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/ppc/pmac.c b/sound/ppc/pmac.c index 592532c..2e750b3 100644 --- a/sound/ppc/pmac.c +++ b/sound/ppc/pmac.c @@ -226,7 +226,7 @@ static int snd_pmac_pcm_prepare(struct snd_pmac *chip, struct pmac_stream *rec, offset += rec->period_size; } /* make loop */ - cp->command = cpu_to_le16(DBDMA_NOP + BR_ALWAYS); + cp->command = cpu_to_le16(DBDMA_NOP | BR_ALWAYS); cp->cmd_dep = cpu_to_le32(rec->cmd.addr); snd_pmac_dma_stop(rec); @@ -726,7 +726,7 @@ void snd_pmac_beep_dma_start(struct snd_pmac *chip, int bytes, unsigned long add chip->extra_dma.cmds->xfer_status = cpu_to_le16(0); chip->extra_dma.cmds->cmd_dep = cpu_to_le32(chip->extra_dma.addr); chip->extra_dma.cmds->phy_addr = cpu_to_le32(addr); - chip->extra_dma.cmds->command = cpu_to_le16(OUTPUT_MORE + BR_ALWAYS); + chip->extra_dma.cmds->command = cpu_to_le16(OUTPUT_MORE | BR_ALWAYS); out_le32(>awacs->control, (in_le32(>awacs->control) & ~0x1f00) | (speed << 8)); -- 2.6.2
[PATCH] pinctrl: sprd: Fix the incorrect pull-up definition
The bits of pull up resistor selection were defined mistakenly,
thus fix them.
Fixes: 41d32cfce1ae ("pinctrl: sprd: Add Spreadtrum pin control driver")
Signed-off-by: Baolin Wang
---
drivers/pinctrl/sprd/pinctrl-sprd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sprd/pinctrl-sprd.c
b/drivers/pinctrl/sprd/pinctrl-sprd.c
index 48cbf2a..08dc193 100644
--- a/drivers/pinctrl/sprd/pinctrl-sprd.c
+++ b/drivers/pinctrl/sprd/pinctrl-sprd.c
@@ -68,8 +68,8 @@
#define SLEEP_PULL_UP_MASK 0x1
#define SLEEP_PULL_UP_SHIFT3
-#define PULL_UP_20K(BIT(12) | BIT(7))
-#define PULL_UP_4_7K BIT(12)
+#define PULL_UP_4_7K (BIT(12) | BIT(7))
+#define PULL_UP_20KBIT(7)
#define PULL_UP_MASK 0x21
#define PULL_UP_SHIFT 7
--
1.9.1
Re: [PATCH 2/5] input: misc: bma150: Conditionally disable bma023 support
Hi Linus, On 2020-05-06 5:46 a.m., Linus Walleij wrote: > On Sun, May 3, 2020 at 7:22 PM Jonathan Bakker wrote: > >> The bma180 IIO driver has been extended for support for bma023. >> However, this could cause conflicts with this driver. Since some >> setups may depend upon the evdev setup, disable support in this >> driver for the bma023 only when the IIO driver is being built. >> >> Signed-off-by: Jonathan Bakker > > I would just fix this with KConfig instead, like add mutually > exclusive depends on these two drivers. > > Set this input driver as: > depends on BMA180=n > > And the IIO driver as: > depends on INPUT_BMA150=n > > It's a rough measure but this input driver should anyway > go away. > Ok, sounds good to me. If I include a patch removing the input driver, can I just drop this patch entirely? The only in-tree user of the input driver (based on i2c ids) is Intel Mid. Not sure what the kernel policy on dropping drivers is. > Yours, > Linus Walleij > Thanks, Jonathan
Re: [RFC PATCH v2 2/3] docs: scheduler: Add scheduler overview documentation
Hi-- On 5/6/20 7:39 AM, john mathew wrote: > From: John Mathew > > Add documentation for > -scheduler overview > -scheduler state transtion > -CFS overview > -scheduler data structs > > Add rst for scheduler APIs and modify sched/core.c > to add kernel-doc comments. > > Suggested-by: Lukas Bulwahn > Co-developed-by: Mostafa Chamanara > Signed-off-by: Mostafa Chamanara > Co-developed-by: Oleg Tsymbal > Signed-off-by: Oleg Tsymbal > Signed-off-by: John Mathew > --- > Documentation/scheduler/cfs-overview.rst | 110 +++ > Documentation/scheduler/index.rst | 3 + > Documentation/scheduler/overview.rst | 269 ++ > .../scheduler/sched-data-structs.rst | 253 > Documentation/scheduler/scheduler-api.rst | 30 ++ > kernel/sched/core.c | 28 +- > kernel/sched/sched.h | 169 ++- > 7 files changed, 855 insertions(+), 7 deletions(-) > create mode 100644 Documentation/scheduler/cfs-overview.rst > create mode 100644 Documentation/scheduler/sched-data-structs.rst > create mode 100644 Documentation/scheduler/scheduler-api.rst > > Request review from Valentin Schneider > for the section describing Scheduler classes in: > .../scheduler/sched-data-structs.rst > > diff --git a/Documentation/scheduler/cfs-overview.rst > b/Documentation/scheduler/cfs-overview.rst > new file mode 100644 > index ..50d94b9bb60e > --- /dev/null > +++ b/Documentation/scheduler/cfs-overview.rst > @@ -0,0 +1,110 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > += > +CFS Overview > += > + > +Linux 2.6.23 introduced a modular scheduler core and a Completely Fair > +Scheduler (CFS) implemented as a scheduling module. A brief overview of the > +CFS design is provided in :doc:`sched-design-CFS` > + > +In addition there have been many improvements to the CFS, a few of which are > + > +**Thermal Pressure**: > +cpu_capacity initially reflects the maximum possible capacity of a CPU. > +Thermal pressure on a CPU means this maximum possible capacity is > +unavailable due to thermal events. Average thermal pressure for a CPU > +is now subtracted from its maximum possible capacity so that cpu_capacity > +reflects the remaining maximum capacity. > + > +**Use Idle CPU for NUMA balancing**: > +Idle CPU is used as a migration target instead of comparing tasks. > +Information on an idle core is cached while gathering statistics > +and this is used to avoid a second scan of the node runqueues if load is > +not imbalanced. Preference is given to an idle core rather than an > +idle SMT sibling to avoid packing HT siblings due to linearly scanning > +the node cpumask. Multiple tasks can attempt to select and idle CPU but > +fail, in this case instead of failing, an alternative idle CPU scanned. I'm having problems parsing that last sentence above. > + > +**Asymmetric CPU capacity wakeup scan**: > +Previous assumption that CPU capacities within an SD_SHARE_PKG_RESOURCES > +domain (sd_llc) are homogeneous didn't hold for newer generations of > big.LITTLE > +systems (DynamIQ) which can accommodate CPUs of different compute capacity > +within a single LLC domain. A new idle sibling helper function was added > +which took CPU capacity in to account. The policy is to pick the first idle into > +CPU which is big enough for the task (task_util * margin < cpu_capacity). why not <= ? > +If no idle CPU is big enough, the idle CPU with the highest capacity was s/was/is/ > +picked. > + > +**Optimized idle core selection**: > +Previously all threads of a core were looped through to evaluate if the > +core is idle or not. This was unnecessary. If a thread of a core is not > +idle, skip evaluating other threads of a core. Also while clearing the > +cpumask, bits of all CPUs of a core can be cleared in one-shot. in one shot. > + > +**Load balance aggressively for SCHED_IDLE CPUs**: > +The fair scheduler performs periodic load balance on every CPU to check > +if it can pull some tasks from other busy CPUs. The duration of this > +periodic load balance is set to scheduler domain's balance_interval and > +multiplied by a busy_factor (set to 32 by default) for the busy CPUs. This > +multiplication is done for busy CPUs to avoid doing load balance too > +often and rather spend more time executing actual task. While that is > +the right thing to do for the CPUs busy with SCHED_OTHER or SCHED_BATCH > +tasks, it may not be the optimal thing for CPUs running only SCHED_IDLE > +tasks. With the recent enhancements in the fair scheduler around SCHED_IDLE > +CPUs, it is now preferred to enqueue a newly-woken task to a SCHED_IDLE > +CPU instead of other busy or idle CPUs. The same reasoning is applied > +to the load balancer as well to make it migrate tasks more aggressively > +to a SCHED_IDLE CPU, as that will reduce
[GIT] Networking
1) Fix reference count leaks in various parts of batman-adv, from Xiyu Yang. 2) Update NAT checksum even when it is zero, from Guillaume Nault. 3) sk_psock reference count leak in tls code, also from Xiyu Yang. 4) Sanity check TCA_FQ_CODEL_DROP_BATCH_SIZE netlink attribute in fq_codel, from Eric Dumazet. 5) Fix panic in choke_reset(), also from Eric Dumazet. 6) Fix VLAN accel handling in bnxt_fix_features(), from Michael Chan. 7) Disallow out of range quantum values in sch_sfq, from Eric Dumazet. 8) Fix crash in x25_disconnect(), from Yue Haibing. 9) Don't pass pointer to local variable back to the caller in nf_osf_hdr_ctx_init(), from Arnd Bergmann. 10) Wireguard should use the ECN decap helper functions, from Toke Høiland-Jørgensen. 11) Fix command entry leak in mlx5 driver, from Moshe Shemesh. 12) Fix uninitialized variable access in mptcp's subflow_syn_recv_sock(), from Paolo Abeni. 13) Fix unnecessary out-of-order ingress frame ordering in macsec, from Scott Dial. 14) IPv6 needs to use a global serial number for dst validation just like ipv4, from David Ahern. 15) Fix up PTP_1588_CLOCK deps, from Clay McClure. 16) Missing NLM_F_MULTI flag in gtp driver netlink messages, from Yoshiyuki Kurauchi. 17) Fix a regression in that dsa user port errors should not be fatal, from Florian Fainelli. 18) Fix iomap leak in enetc driver, from Dejin Zheng. 19) Fix use after free in lec_arp_clear_vccs(), from Cong Wang. 20) Initialize protocol value earlier in neigh code paths when generating events, from Roman Mashak. 21) netdev_update_features() must be called with RTNL mutex in macsec driver, from Antoine Tenart. 22) Validate untrusted GSO packets even more strictly, from Willem de Bruijn. 23) Wireguard decrypt worker needs a cond_resched(), from Jason A. Donenfeld. Please pull, thanks a lot. The following changes since commit b2768df24ec400dd4f7fa79542f797e904812053: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace (2020-04-25 12:25:32 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git for you to fetch changes up to 16f8036086a929694c3c62f577bb5925fe4fd607: net: flow_offload: skip hw stats check for FLOW_ACTION_HW_STATS_DONT_CARE (2020-05-06 20:13:10 -0700) Ahmed Abdelsalam (1): seg6: fix SRH processing to comply with RFC8754 Alex Elder (3): net: ipa: fix a bug in ipa_endpoint_stop() net: ipa: fix an error message in gsi_channel_init_one() net: ipa: zero return code before issuing generic EE command Andy Shevchenko (2): net: macb: Fix runtime PM refcounting stmmac: intel: Fix kernel crash due to wrong error path Anthony Felice (1): net: tc35815: Fix phydev supported/advertising mask Antoine Tenart (1): net: macsec: fix rtnl locking issue Arnd Bergmann (3): netfilter: nf_osf: avoid passing pointer to local var drop_monitor: work around gcc-10 stringop-overflow warning cxgb4/chcr: avoid -Wreturn-local-addr warning Aya Levin (1): devlink: Fix reporter's recovery condition Baruch Siach (1): net: phy: marvell10g: fix temperature sensor on 2110 Christophe JAILLET (2): net/sonic: Fix a resource leak in an error handling path in 'jazz_sonic_probe()' net: moxa: Fix a potential double 'free_irq()' Clay McClure (1): net: Make PTP-specific drivers depend on PTP_1588_CLOCK Colin Ian King (1): net: stmmac: gmac5+: fix potential integer overflow on 32 bit multiply Cong Wang (3): net_sched: fix tcm_parent in tc filter dump atm: fix a UAF in lec_arp_clear_vccs() atm: fix a memory leak of vcc->user_back Dan Carpenter (2): net: mvpp2: prevent buffer overflow in mvpp22_rss_ctx() net: mvpp2: cls: Prevent buffer overflow in mvpp2_ethtool_cls_rule_del() Dan Murphy (2): net: phy: DP83822: Fix WoL in config init to be disabled net: phy: DP83TC811: Fix WoL in config init to be disabled David Ahern (1): ipv6: Use global sernum for dst validation with nexthop objects David S. Miller (12): Merge branch 'vsock-virtio-fixes-about-packet-delivery-to-monitoring-devices' Merge branch 'bnxt_en-fixes' Merge tag 'batadv-net-for-davem-20200427' of git://git.open-mesh.org/linux-merge Merge branch 'wireguard-fixes' Merge branch 'mptcp-fix-incoming-options-parsing' Merge tag 'mlx5-fixes-2020-04-29' of git://git.kernel.org/.../saeed/linux Merge branch 'ionic-fw-upgrade-bug-fixes' Merge branch 'net-ipa-three-bug-fixes' Merge git://git.kernel.org/.../pablo/nf Merge branch 'WoL-fixes-for-DP83822-and-DP83tc811' Merge branch 'FDB-fixes-for-Felix-and-Ocelot-switches' Merge branch 'wireguard-fixes' Dejin Zheng (3): net: macb: fix an issue about leak related
Re: [PATCH] gpiolib: add GPIO_SET_DEBOUNCE_IOCTL
On Mon, May 04, 2020 at 12:31:57PM +0200, Bartosz Golaszewski wrote: > czw., 30 kwi 2020 o 16:58 Kent Gibson napisał(a): > > > > On Thu, Apr 30, 2020 at 01:32:22PM +, Bujanda, Hector wrote: > > > Thanks all for your guidance! > > > > > > First saying that this patch request was sent having our platforms in > > > k4.14 in the way of upgrading to k5.4. > > > In those versions the commit e588bb1eae31be73fbec2b731be986a7c09635a4 > > > "gpio: add new SET_CONFIG ioctl() to gpio chardev" by Kent Gibson was not > > > available. > > > > > > I see that you clearly understand the necessity of having a way of > > > configuring debounce from the userspace. > > > Our platforms make use of hardware debouncing filtering. Up to now we > > > were using the sysfilesystem to let the user handle gpios (including > > > debounce configuration). > > > We wanted now to get rid of sysfilesystem and start using > > > gpiolib/libgpiod but configuring debounce is blocking us. > > > > > > Now I clearly see (as pointed by Bartosz Golaszewski) that my suggested > > > GPIO_SET_DEBOUNCE_IOCTL is wrong as it hits the chip file descriptor > > > while 'Modifying any config settings can only happen on lines previously > > > requested too in user-space'. > > > > > > I agree with all that a flag is needed to allow configuring debounce to > > > '0' which has always meant disabling it. > > > > > > Also agree with 'Kent Gibson' suggestion of 'You might want to add a > > > flag to the GPIOLINE_FLAGs to indicate if debounce is set'. > > > > > > I have my doubts if it is compulsory to extend debounce configuration to > > > the gpioevent_requests since the debounce value configured by a user is > > > normally linked to a hardware noise in a line; and that does not change > > > from one gpioevent_requests to another. So I think this configuration > > > would be useful but not compulsory. > > > > > > > Just to clarify on this point, the reason the SET_CONFIG would have to > > be extended to events is not to alter the debounce on the fly but to set > > it at all. Lines are requested as either handles (for outputs or polled > > inputs) > > or events (for asynchronous edge events on inputs). We cannot extend > > either the handle or event request ioctls themselves as there is no > > provision > > in their data structures for future expansion. There is in the > > SET_CONFIG ioctl - but that doesn't apply to event requests yet... > > > > Indeed. And as I was thinking about it over the weekend I realized > that exposing a setter for a config option that's not settable at > request-time seems wrong. Together with the lineevent structure which > doesn't work on 64-bit kernel with 32-bit user-space this all makes me > think we should design v2 of several of the ioctl() calls with more > care. > > > > > > I agree with Linus Walleij that 'there is a serious user-facing problem > > > here though, because not all GPIO controllers supports debounce'. > > > Our platforms have native freescale/NXP gpiochips not supporting hardware > > > debounce and our own gpiochips having hardware debounce. > > > We have also noticed that 'drivers/input/keyboard/gpio_keys.c contains > > > generic debounce code using kernel timers if the GPIO driver cannot > > > provide debouncing'. That feature is not of our interest (because of > > > having hardware debounce filters) but it would clearly be a very good > > > overall functionality. > > > > > > Having said all above, I wonder how you want to proceed. > > > Our current development in k5.4 and libgpiod1.4.1 is much behind > > > master... what makes collaboration (and reusability) a bit more complex. > > > Also I see the implementation requires a bigger picture than I initially > > > expected. > > > So I wonder if you want me to do the initial steps of the development > > > (what I foresee will require some back and forth) or you prefer > > > implementing all pieces. > > > > > > > I totally agree with you on the widening scope. > > > > Bart - how do you want to go forward with this? I'm available to work > > on it, in part or full. > > > > Personally I'm super busy with my actual job and adding support for > line watch ioctl() to libgpiod ATM. I can't really spare any time on > this. I have some crazy ideas: like storing the debounce time in the > 16 most significant bits of the flags field but this is just papering > over bad ABI. > > Ideally we'd have to introduce new versions of gpioevent_request, > gpioline_request, gpioline_info and gpioevent_data structs - this time > with enough additional padding and no alignment issues. Then we could > add the debounce properly. > Agreed - adding setting only via the SET_CONFIG ioctl is a bit of a hack, and a v2 of the uAPI is required to add it to the requests, and to add the debounce value to the info. > This would of course add a lot of cruft to the uAPI code. I'd start by > moving it out of drivers/gpio/gpiolib.c into a new file: >
Re: [PATCH -next] ASoC: SOF: Intel: Mark cht_debugfs as __maybe_unused
On Thu, 2020-05-07 at 11:19 +0800, YueHaibing wrote:
> When CONFIG_SND_SOC_SOF_BAYTRAIL is not set, gcc warns:
>
> sound/soc/sof/intel/byt.c:85:41: warning: ‘cht_debugfs’ defined but not used
> [-Wunused-const-variable=]
> static const struct snd_sof_debugfs_map cht_debugfs[] = {
> ^~~
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
> sound/soc/sof/intel/byt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/sof/intel/byt.c b/sound/soc/sof/intel/byt.c
> index f872bb1f2682..1c75e4220e9d 100644
> --- a/sound/soc/sof/intel/byt.c
> +++ b/sound/soc/sof/intel/byt.c
> @@ -82,7 +82,7 @@ static const struct snd_sof_debugfs_map byt_debugfs[] = {
>SOF_DEBUGFS_ACCESS_ALWAYS},
> };
>
> -static const struct snd_sof_debugfs_map cht_debugfs[] = {
> +static const struct snd_sof_debugfs_map __maybe_unused cht_debugfs[] = {
> {"dmac0", BYT_DSP_BAR, DMAC0_OFFSET, DMAC_SIZE,
>SOF_DEBUGFS_ACCESS_ALWAYS},
> {"dmac1", BYT_DSP_BAR, DMAC1_OFFSET, DMAC_SIZE,
Likely better moving the struct instead inside the
#ifdef block
---
sound/soc/sof/intel/byt.c | 54 +++
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/sound/soc/sof/intel/byt.c b/sound/soc/sof/intel/byt.c
index f872bb1f2682..3747f2c2c28b 100644
--- a/sound/soc/sof/intel/byt.c
+++ b/sound/soc/sof/intel/byt.c
@@ -82,33 +82,6 @@ static const struct snd_sof_debugfs_map byt_debugfs[] = {
SOF_DEBUGFS_ACCESS_ALWAYS},
};
-static const struct snd_sof_debugfs_map cht_debugfs[] = {
- {"dmac0", BYT_DSP_BAR, DMAC0_OFFSET, DMAC_SIZE,
-SOF_DEBUGFS_ACCESS_ALWAYS},
- {"dmac1", BYT_DSP_BAR, DMAC1_OFFSET, DMAC_SIZE,
-SOF_DEBUGFS_ACCESS_ALWAYS},
- {"dmac2", BYT_DSP_BAR, DMAC2_OFFSET, DMAC_SIZE,
-SOF_DEBUGFS_ACCESS_ALWAYS},
- {"ssp0", BYT_DSP_BAR, SSP0_OFFSET, SSP_SIZE,
-SOF_DEBUGFS_ACCESS_ALWAYS},
- {"ssp1", BYT_DSP_BAR, SSP1_OFFSET, SSP_SIZE,
-SOF_DEBUGFS_ACCESS_ALWAYS},
- {"ssp2", BYT_DSP_BAR, SSP2_OFFSET, SSP_SIZE,
-SOF_DEBUGFS_ACCESS_ALWAYS},
- {"ssp3", BYT_DSP_BAR, SSP3_OFFSET, SSP_SIZE,
-SOF_DEBUGFS_ACCESS_ALWAYS},
- {"ssp4", BYT_DSP_BAR, SSP4_OFFSET, SSP_SIZE,
-SOF_DEBUGFS_ACCESS_ALWAYS},
- {"ssp5", BYT_DSP_BAR, SSP5_OFFSET, SSP_SIZE,
-SOF_DEBUGFS_ACCESS_ALWAYS},
- {"iram", BYT_DSP_BAR, IRAM_OFFSET, IRAM_SIZE,
-SOF_DEBUGFS_ACCESS_D0_ONLY},
- {"dram", BYT_DSP_BAR, DRAM_OFFSET, DRAM_SIZE,
-SOF_DEBUGFS_ACCESS_D0_ONLY},
- {"shim", BYT_DSP_BAR, SHIM_OFFSET, SHIM_SIZE_CHT,
-SOF_DEBUGFS_ACCESS_ALWAYS},
-};
-
static void byt_host_done(struct snd_sof_dev *sdev);
static void byt_dsp_done(struct snd_sof_dev *sdev);
static void byt_get_reply(struct snd_sof_dev *sdev);
@@ -681,6 +654,33 @@ EXPORT_SYMBOL_NS(tng_chip_info, SND_SOC_SOF_MERRIFIELD);
#if IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL)
+static const struct snd_sof_debugfs_map cht_debugfs[] = {
+ {"dmac0", BYT_DSP_BAR, DMAC0_OFFSET, DMAC_SIZE,
+SOF_DEBUGFS_ACCESS_ALWAYS},
+ {"dmac1", BYT_DSP_BAR, DMAC1_OFFSET, DMAC_SIZE,
+SOF_DEBUGFS_ACCESS_ALWAYS},
+ {"dmac2", BYT_DSP_BAR, DMAC2_OFFSET, DMAC_SIZE,
+SOF_DEBUGFS_ACCESS_ALWAYS},
+ {"ssp0", BYT_DSP_BAR, SSP0_OFFSET, SSP_SIZE,
+SOF_DEBUGFS_ACCESS_ALWAYS},
+ {"ssp1", BYT_DSP_BAR, SSP1_OFFSET, SSP_SIZE,
+SOF_DEBUGFS_ACCESS_ALWAYS},
+ {"ssp2", BYT_DSP_BAR, SSP2_OFFSET, SSP_SIZE,
+SOF_DEBUGFS_ACCESS_ALWAYS},
+ {"ssp3", BYT_DSP_BAR, SSP3_OFFSET, SSP_SIZE,
+SOF_DEBUGFS_ACCESS_ALWAYS},
+ {"ssp4", BYT_DSP_BAR, SSP4_OFFSET, SSP_SIZE,
+SOF_DEBUGFS_ACCESS_ALWAYS},
+ {"ssp5", BYT_DSP_BAR, SSP5_OFFSET, SSP_SIZE,
+SOF_DEBUGFS_ACCESS_ALWAYS},
+ {"iram", BYT_DSP_BAR, IRAM_OFFSET, IRAM_SIZE,
+SOF_DEBUGFS_ACCESS_D0_ONLY},
+ {"dram", BYT_DSP_BAR, DRAM_OFFSET, DRAM_SIZE,
+SOF_DEBUGFS_ACCESS_D0_ONLY},
+ {"shim", BYT_DSP_BAR, SHIM_OFFSET, SHIM_SIZE_CHT,
+SOF_DEBUGFS_ACCESS_ALWAYS},
+};
+
static int byt_acpi_probe(struct snd_sof_dev *sdev)
{
struct snd_sof_pdata *pdata = sdev->pdata;
Re: System fails to exit s2idle by a keystroke on my laptop
On Wed, May 6, 2020 at 6:19 PM Rafael J. Wysocki wrote: > > On Wed, May 6, 2020 at 11:32 AM Rafael J. Wysocki wrote: > > > > > > Thanks for the report, the issue evidently is EC-related. > > > > > @@ -1024,7 +1024,7 @@ static bool acpi_s2idle_wake(void) > > > * regarded as a spurious one. > > > */ > > > if (!acpi_ec_dispatch_gpe()) > > > - return false; > > > + return true; > > > > Have you tried commenting out simply removing the if () check and the > > following return statement? > > Scratch that. > > Instead, please try doing > > acpi_ec_dispatch_gpe() > > instead of the if () and the following return statement. Yes. I verified with the modification you suggested on my laptop. It's working OK. I can wake from a keystroke w/o problem. @ -1024,8 +1024,7 @@ static bool acpi_s2idle_wake(void) * If the EC GPE status bit has not been set, the wakeup is * regarded as a spurious one. */ - if (!acpi_ec_dispatch_gpe()) - return false; + acpi_ec_dispatch_gpe(); /* * Cancel the wakeup and process all pending events in case
Re: [PATCH v2 2/7] extcon: arizona: Move binding over to dtschema
Hi Charles,
On 5/7/20 12:57 AM, Charles Keepax wrote:
> Signed-off-by: Charles Keepax
> ---
>
> Changes since v1:
> - Removed some description that duplicates constraints
>
> Thanks,
> Charles
>
> .../devicetree/bindings/extcon/extcon-arizona.txt | 76 -
> .../devicetree/bindings/extcon/wlf,arizona.yaml| 125
> +
> 2 files changed, 125 insertions(+), 76 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> create mode 100644 Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
>
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> deleted file mode 100644
> index 208daaff0be4f..0
> --- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> +++ /dev/null
> @@ -1,76 +0,0 @@
> -Cirrus Logic Arizona class audio SoCs
> -
> -These devices are audio SoCs with extensive digital capabilities and a range
> -of analogue I/O.
> -
> -This document lists Extcon specific bindings, see the primary binding
> document:
> - ../mfd/arizona.txt
> -
> -Optional properties:
> -
> - - wlf,hpdet-channel : Headphone detection channel.
> -ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL
> -ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR
> -If this node is not mentioned or if the value is unknown, then
> -headphone detection mode is set to HPDETL.
> -
> - - wlf,use-jd2 : Use the additional JD input along with JD1 for dual pin
> jack
> -detection.
> - - wlf,use-jd2-nopull : Internal pull on JD2 is disabled when used for
> -jack detection.
> - - wlf,jd-invert : Invert the polarity of the jack detection switch
> -
> - - wlf,micd-software-compare : Use a software comparison to determine mic
> -presence
> - - wlf,micd-detect-debounce : Additional software microphone detection
> -debounce specified in milliseconds.
> - - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
> -polarity if one exists.
> - - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
> -performing microphone detection, specified as per the
> ARIZONA_MICD_TIME_XXX
> -defines.
> - - wlf,micd-rate : Delay between successive microphone detection
> measurements,
> -specified as per the ARIZONA_MICD_TIME_XXX defines.
> - - wlf,micd-dbtime : Microphone detection hardware debounces specified as
> the
> -number of measurements to take, valid values being 2 and 4.
> - - wlf,micd-timeout-ms : Timeout for microphone detection, specified in
> -milliseconds.
> - - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
> -detection.
> - - wlf,micd-configs : Headset polarity configurations (generally used for
> -detection of CTIA / OMTP headsets), the field can be of variable length
> -but should always be a multiple of 3 cells long, each three cell group
> -represents one polarity configuration.
> -The first cell defines the accessory detection pin, zero will use MICDET1
> -and all other values will use MICDET2.
> -The second cell represents the MICBIAS to be used.
> -The third cell represents the value of the micd-pol-gpio pin.
> -
> - - wlf,gpsw : Settings for the general purpose switch, set as one of the
> -ARIZONA_GPSW_XXX defines.
> -
> -Example:
> -
> -codec: wm8280@0 {
> - compatible = "wlf,wm8280";
> - reg = <0>;
> - ...
> -
> - wlf,use-jd2;
> - wlf,use-jd2-nopull;
> - wlf,jd-invert;
> -
> - wlf,micd-software-compare;
> - wlf,micd-detect-debounce = <0>;
> - wlf,micd-pol-gpio = < 2 0>;
> - wlf,micd-rate = ;
> - wlf,micd-dbtime = <4>;
> - wlf,micd-timeout-ms = <100>;
> - wlf,micd-force-micbias;
> - wlf,micd-configs = <
> - 0 1 0 /* MICDET1 MICBIAS1 GPIO=low */
> - 1 2 1 /* MICDET2 MICBIAS2 GPIO=high */
> - >;
> -
> - wlf,gpsw = ;
> -};
> diff --git a/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
> b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
> new file mode 100644
> index 0..f9845dc2f5ae5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/wlf,arizona.yaml
> @@ -0,0 +1,125 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id:
> https://protect2.fireeye.com/url?k=696fcddc-34bc96c8-696e4693-0cc47a31ce4e-2a3e86cfac9f17c2=1=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fextcon%2Fwlf%2Carizona.yaml%23
> +$schema:
> https://protect2.fireeye.com/url?k=afda1ee7-f20945f3-afdb95a8-0cc47a31ce4e-9f3472c530744134=1=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
> +
> +title: Cirrus Logic/Wolfson Microelectronics Arizona class audio SoCs
> +
> +maintainers:
> + - patc...@opensource.cirrus.com
> +
> +description: |
> + These devices are audio SoCs with extensive digital capabilities and a
> +
[PATCH v1 1/1] PCI/ERR: Handle fatal error recovery for non-hotplug capable devices
From: Kuppuswamy Sathyanarayanan
If there are non-hotplug capable devices connected to a given
port, then during the fatal error recovery(triggered by DPC or
AER), after calling reset_link() function, we cannot rely on
hotplug handler to detach and re-enumerate the device drivers
in the affected bus. Instead, we will have to let the error
recovery handler call report_slot_reset() for all devices in
the bus to notify about the reset operation. Although this is
only required for non hot-plug capable devices, doing it for
hotplug capable devices should not affect the functionality.
Along with above issue, this fix also applicable to following
issue.
Commit 6d2c89441571 ("PCI/ERR: Update error status after
reset_link()") added support to store status of reset_link()
call. Although this fixed the error recovery issue observed if
the initial value of error status is PCI_ERS_RESULT_DISCONNECT
or PCI_ERS_RESULT_NO_AER_DRIVER, it also discarded the status
result from report_frozen_detected. This can cause a failure to
recover if _NEED_RESET is returned by report_frozen_detected and
report_slot_reset is not invoked.
Such an event can be induced for testing purposes by reducing the
Max_Payload_Size of a PCIe bridge to less than that of a device
downstream from the bridge, and then initiating I/O through the
device, resulting in oversize transactions. In the presence of DPC,
this results in a containment event and attempted reset and recovery
via pcie_do_recovery. After 6d2c89441571 report_slot_reset is not
invoked, and the device does not recover.
[original patch is from jay.vosbu...@canonical.com]
[original patch link https://lore.kernel.org/linux-pci/18609.1588812972@famine/]
Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
Signed-off-by: Jay Vosburgh
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pcie/err.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index 14bb8f54723e..db80e1ecb2dc 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -165,13 +165,24 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_dbg(dev, "broadcast error_detected message\n");
if (state == pci_channel_io_frozen) {
pci_walk_bus(bus, report_frozen_detected, );
- status = reset_link(dev);
- if (status != PCI_ERS_RESULT_RECOVERED) {
+ status = PCI_ERS_RESULT_NEED_RESET;
+ } else {
+ pci_walk_bus(bus, report_normal_detected, );
+ }
+
+ if (status == PCI_ERS_RESULT_NEED_RESET) {
+ if (reset_link) {
+ if (reset_link(dev) != PCI_ERS_RESULT_RECOVERED)
+ status = PCI_ERS_RESULT_DISCONNECT;
+ } else {
+ if (pci_bus_error_reset(dev))
+ status = PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ if (status == PCI_ERS_RESULT_DISCONNECT) {
pci_warn(dev, "link reset failed\n");
goto failed;
}
- } else {
- pci_walk_bus(bus, report_normal_detected, );
}
if (status == PCI_ERS_RESULT_CAN_RECOVER) {
--
2.17.1
Re: [PATCH] efi: cper: Add support for printing Firmware Error Record Reference
Hi Ard,
Ard Biesheuvel writes:
> Hello Punit,
>
> On Mon, 27 Apr 2020 at 11:03, Punit Agrawal
> wrote:
>>
>> While debugging a boot failure, the following unknown error record was
>> seen in the boot logs.
>>
>> <...>
>> BERT: Error records from previous boot:
>> [Hardware Error]: event severity: fatal
>> [Hardware Error]: Error 0, type: fatal
>> [Hardware Error]: section type: unknown,
>> 81212a96-09ed-4996-9471-8d729c8e69ed
>> [Hardware Error]: section length: 0x290
>> [Hardware Error]: : 0001 00020002
>>
>> [Hardware Error]: 0010: 00020002 001f 0320
>> ...
>> [Hardware Error]: 0020:
>>
>> [Hardware Error]: 0030:
>>
>> <...>
>>
>> On further investigation, it was found that the error record with
>> UUID (81212a96-09ed-4996-9471-8d729c8e69ed) has been defined in the
>> UEFI Specification at least since v2.4 and has recently had additional
>> fields defined in v2.7 Section N.2.10 Firmware Error Record Reference.
>>
>> Add support for parsing and printing the defined fields to give users
>> a chance to figure out what's went wrong.
>>
>> Signed-off-by: Punit Agrawal
>> Cc: Ard Biesheuvel
>> Cc: "Rafael J. Wysocki"
>> Cc: Borislav Petkov
>> Cc: James Morse
>> Cc: linux-a...@vger.kernel.org
>> Cc: linux-...@vger.kernel.org
[...]
>> drivers/firmware/efi/cper.c | 49 +
>> include/linux/cper.h| 11 +
>> 2 files changed, 60 insertions(+)
>>
>> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
>> index 9d2512913d25..153b95257e23 100644
>> --- a/drivers/firmware/efi/cper.c
>> +++ b/drivers/firmware/efi/cper.c
>> @@ -407,6 +407,46 @@ static void cper_print_pcie(const char *pfx, const
>> struct cper_sec_pcie *pcie,
>> }
>> }
>>
>> +static const char * const fw_err_rec_type_strs[] = {
>> + "IPF SAL Error Record",
>> + "SOC Firmware Error Record Type1 (Legacy CrashLog Support)",
>> + "SOC Firmware Error Record Type2",
>> +};
>> +
>> +static void cper_print_fw_err(const char *pfx,
>> + struct acpi_hest_generic_data *gdata,
>> + const struct cper_sec_fw_err_rec_ref *fw_err)
>> +{
>> + void *buf = acpi_hest_get_payload(gdata);
>> + u32 offset, length = gdata->error_data_length;
>> +
>> + printk("%s""Firmware Error Record Type: %s\n", pfx,
>> + fw_err->record_type < ARRAY_SIZE(fw_err_rec_type_strs) ?
>> + fw_err_rec_type_strs[fw_err->record_type] : "unknown");
>> +
>> + /* Record Type based on UEFI 2.7 */
>> + if (fw_err->revision == 0)
>> + printk("%s""Record Identifier: %08llx\n", pfx,
>> + fw_err->record_identifier);
>> + else if (fw_err->revision == 2)
>> + printk("%s""Record Identifier: %pUl\n", pfx,
>> + _err->record_identifier_guid);
>> +
>
> Please use {} for multi-line statements between the ifs
>
>> + if (fw_err->revision == 0)
>> + offset = offsetof(struct cper_sec_fw_err_rec_ref,
>> + record_identifier_guid);
>> + else if (fw_err->revision == 1)
>> + offset = offsetof(struct cper_sec_fw_err_rec_ref,
>> + record_identifier);
>> + else
>> + offset = sizeof(*fw_err);
>> +
>
> This logic is slightly confusing, so it could do with a comment
> regarding which part of the structure is being dumped and why.
>
>
>> + buf += offset;
>> + length -= offset;
>> +
>> + print_hex_dump(pfx, "", DUMP_PREFIX_OFFSET, 16, 4, buf, length,
>> true);
>> +}
>> +
>> static void cper_print_tstamp(const char *pfx,
>>struct acpi_hest_generic_data_v300 *gdata)
>> {
>> @@ -494,6 +534,15 @@ cper_estatus_print_section(const char *pfx, struct
>> acpi_hest_generic_data *gdata
>> else
>> goto err_section_too_small;
>> #endif
>> + } else if (guid_equal(sec_type, _SEC_FW_ERR_REC_REF)) {
>> + struct cper_sec_fw_err_rec_ref *fw_err =
>> acpi_hest_get_payload(gdata);
>> +
>> + printk("%ssection_type: Firmware Error Record Reference\n",
>> + newpfx);
>> + if (gdata->error_data_length >= sizeof(*fw_err))
>> + cper_print_fw_err(newpfx, gdata, fw_err);
>
> This doesn't work for revision 0 structures unless they happen to have
> some trailing data, which is not necessarily the case, right?
Good catch. I will re-work this to avoid skipping revision 0 record.
>> + else
>> + goto err_section_too_small;
>> } else {
>> const void *err =
Re: [PATCH v4 2/2] mailbox: sprd: Add Spreadtrum mailbox driver
Hi Jassi, On Thu, May 7, 2020 at 7:25 AM Jassi Brar wrote: > > On Wed, May 6, 2020 at 8:29 AM Baolin Wang wrote: > > > > Hi Jassi, > > > > On Tue, Apr 28, 2020 at 11:10 AM Baolin Wang wrote: > > > > > > From: Baolin Wang > > > > > > The Spreadtrum mailbox controller supports 8 channels to communicate > > > with MCUs, and it contains 2 different parts: inbox and outbox, which > > > are used to send and receive messages by IRQ mode. > > > > > > Signed-off-by: Baolin Wang > > > Signed-off-by: Baolin Wang > > > --- > > > Changes from v3: > > > - Save the id in mbox_chan.con_priv and remove the 'sprd_mbox_chan' > > > > > > Changes from v2: > > > - None. > > > > > > Changes from v1: > > > - None > > > > Gentle ping, do you have any other comments? Thanks. > > > Yea, I am still not sure about the error returned in send_data(). It > will either never hit or there will be no easy recovery from it. The > api expects the driver to tell it the last-tx was done only when it > can send the next message. (There may be case like sending depend on > remote, which can't be ensured before hand). Actually this is an unusual case, suppose the remote target did not fetch the message as soon as possile, which will cause the FIFO overflow, so in this case we can not send messages to the remote target any more, otherwise messages will be lost. Thus we can return errors to users to indicate that something wrong with the remote target need to be checked. So this validation in send_data() is mostly for debugging for this abnormal case and we will not trigger this issue if the remote target works well. So I think it is useful to keep this validation in send_data(). Thanks. -- Baolin Wang
Re: [PATCH v2 6/6] security: apparmor: default KUNIT_* fragments to KUNIT_RUN_ALL
On Tue, May 5, 2020 at 6:27 PM Anders Roxell wrote: > > This makes it easier to enable all KUnit fragments. > > Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if > someone wants that even though KUNIT_RUN_ALL is enabled. Again, as with the other patches, might be worth revising this description when changing the config name. > > Signed-off-by: Anders Roxell Reviewed-by: David Gow Thanks again for the patchset, it's working well for me. -- David > --- > security/apparmor/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/security/apparmor/Kconfig b/security/apparmor/Kconfig > index 0fe336860773..c4648426ea5d 100644 > --- a/security/apparmor/Kconfig > +++ b/security/apparmor/Kconfig > @@ -70,8 +70,9 @@ config SECURITY_APPARMOR_DEBUG_MESSAGES > the kernel message buffer. > > config SECURITY_APPARMOR_KUNIT_TEST > - bool "Build KUnit tests for policy_unpack.c" > + bool "Build KUnit tests for policy_unpack.c" if !KUNIT_RUN_ALL > depends on KUNIT=y && SECURITY_APPARMOR > + default KUNIT_RUN_ALL > help > This builds the AppArmor KUnit tests. > > -- > 2.20.1 >
Re: [PATCH v2 5/6] fs: ext4: default KUNIT_* fragments to KUNIT_RUN_ALL
On Tue, May 5, 2020 at 6:27 PM Anders Roxell wrote: > > This makes it easier to enable all KUnit fragments. > > Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if > someone wants that even though KUNIT_RUN_ALL is enabled. As with the others, "test"->"tests", and "of"->"off". > > Signed-off-by: Anders Roxell Reviewed-by: David Gow > --- > fs/ext4/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig > index 2a592e38cdfe..76785143259d 100644 > --- a/fs/ext4/Kconfig > +++ b/fs/ext4/Kconfig > @@ -103,9 +103,10 @@ config EXT4_DEBUG > echo 1 > /sys/module/ext4/parameters/mballoc_debug > > config EXT4_KUNIT_TESTS > - tristate "KUnit tests for ext4" > + tristate "KUnit tests for ext4" if !KUNIT_RUN_ALL > select EXT4_FS > depends on KUNIT > + default KUNIT_RUN_ALL > help > This builds the ext4 KUnit tests. > > -- > 2.20.1 >
[PATCH -next] ASoC: SOF: Intel: Mark cht_debugfs as __maybe_unused
When CONFIG_SND_SOC_SOF_BAYTRAIL is not set, gcc warns:
sound/soc/sof/intel/byt.c:85:41: warning: ‘cht_debugfs’ defined but not used
[-Wunused-const-variable=]
static const struct snd_sof_debugfs_map cht_debugfs[] = {
^~~
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
sound/soc/sof/intel/byt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/intel/byt.c b/sound/soc/sof/intel/byt.c
index f872bb1f2682..1c75e4220e9d 100644
--- a/sound/soc/sof/intel/byt.c
+++ b/sound/soc/sof/intel/byt.c
@@ -82,7 +82,7 @@ static const struct snd_sof_debugfs_map byt_debugfs[] = {
SOF_DEBUGFS_ACCESS_ALWAYS},
};
-static const struct snd_sof_debugfs_map cht_debugfs[] = {
+static const struct snd_sof_debugfs_map __maybe_unused cht_debugfs[] = {
{"dmac0", BYT_DSP_BAR, DMAC0_OFFSET, DMAC_SIZE,
SOF_DEBUGFS_ACCESS_ALWAYS},
{"dmac1", BYT_DSP_BAR, DMAC1_OFFSET, DMAC_SIZE,
--
2.17.1
Re: [PATCH] slub: limit count of partial slabs scanned to gather statistics
Hi Qian, On Wed, 6 May 2020 23:01:54 -0400 Qian Cai wrote: > > Andrew, Stephen, can you remove this patch from linux-next? Removed from linux-next. -- Cheers, Stephen Rothwell pgp6aRPJdbwvh.pgp Description: OpenPGP digital signature
Re: [PATCH v4] streamline_config.pl: add LMC_KEEP to preserve some kconfigs
On Sun, May 3, 2020 at 9:11 AM Changbin Du wrote:
>
> Sometimes it is useful to preserve batches of configs when making
> localmodconfig. For example, I usually don't want any usb and fs
> modules to be disabled. Now we can do it by:
>
> $ make LMC_KEEP="drivers/usb;fs" localmodconfig
>
> Signed-off-by: Changbin Du
>
> ---
> v4: fix typo.
> v3: rename LOCALMODCONFIG_PRESERVE to shorter LMC_KEEP.
> v2: fix typo in documentation. (Randy Dunlap)
> ---
Personally, I do not mind the long LOCALMODCONFIG_PRESERVE,
but this tends to be bike-sheding.
I do not have a strong opinion.
> Documentation/admin-guide/README.rst | 8 +++-
> scripts/kconfig/Makefile | 1 +
> scripts/kconfig/streamline_config.pl | 23 +++
> 3 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/README.rst
> b/Documentation/admin-guide/README.rst
> index cc6151fc0845..1371deab8bc7 100644
> --- a/Documentation/admin-guide/README.rst
> +++ b/Documentation/admin-guide/README.rst
> @@ -209,10 +209,16 @@ Configuring the kernel
> store the lsmod of that machine into a file
> and pass it in as a LSMOD parameter.
>
> + Also, you can preserve modules in certain folders
> + or kconfig files by specifying their paths in
> + parameter LMC_KEEP.
> +
> target$ lsmod > /tmp/mylsmod
> target$ scp /tmp/mylsmod host:/tmp
>
> - host$ make LSMOD=/tmp/mylsmod localmodconfig
> + host$ make LSMOD=/tmp/mylsmod \
> + LMC_KEEP="drivers/usb;drivers/gpu;fs" \
This might be another bike-sheding item, but
can you use a space for the delimiter?
LMC_KEEP="drivers/usb drivers/gpu fs"
If you pass multiple directories,
you will need to surround them with double-quotes.
> + localmodconfig
>
> The above also works when cross compiling.
>
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index c9d0a4a8efb3..e0abbf5805f5 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -123,6 +123,7 @@ help:
> @echo ' gconfig - Update current config utilising a GTK+
> based front-end'
> @echo ' oldconfig - Update current config utilising a
> provided .config as base'
> @echo ' localmodconfig - Update current config disabling modules
> not loaded'
> + @echo 'except those preserved by LMC_KEEP
> environment variable'
> @echo ' localyesconfig - Update current config converting local
> mods to core'
> @echo ' defconfig - New config with default from ARCH
> supplied defconfig'
> @echo ' savedefconfig - Save current config as ./defconfig
> (minimal config)'
> diff --git a/scripts/kconfig/streamline_config.pl
> b/scripts/kconfig/streamline_config.pl
> index e2f8504f5a2d..d26543a807c9 100755
> --- a/scripts/kconfig/streamline_config.pl
> +++ b/scripts/kconfig/streamline_config.pl
> @@ -143,6 +143,7 @@ my %depends;
> my %selects;
> my %prompts;
> my %objects;
> +my %config2kfile;
> my $var;
> my $iflevel = 0;
> my @ifdeps;
> @@ -201,6 +202,7 @@ sub read_kconfig {
> if (/^\s*(menu)?config\s+(\S+)\s*$/) {
> $state = "NEW";
> $config = $2;
> + $config2kfile{"CONFIG_$config"} = $kconfig;
>
> # Add depends for 'if' nesting
> for (my $i = 0; $i < $iflevel; $i++) {
> @@ -592,6 +594,22 @@ while ($repeat) {
>
> my %setconfigs;
>
> +my @preserved_kconfigs;
> +@preserved_kconfigs = split(/;/,$ENV{LMC_KEEP}) if (defined($ENV{LMC_KEEP}));
Maybe, you can do 'my' declaration and the assignment
in a single line?
Can you drop the 'if ...' conditional?
Does this work for you?
my @preserved_kconfigs = split(/;/,$ENV{LMC_KEEP});
> +
> +sub in_preserved_kconfigs {
> +my $kconfig = $config2kfile{$_[0]};
> +if (!defined($kconfig)) {
> +return 0;
> +}
> +foreach my $excl (@preserved_kconfigs) {
> +if($kconfig =~ /^$excl/) {
> +return 1;
> +}
> +}
> +return 0;
> +}
> +
> # Finally, read the .config file and turn off any module enabled that
> # we could not find a reason to keep enabled.
> foreach my $line (@config_file) {
> @@ -644,6 +662,11 @@ foreach my $line (@config_file) {
> }
>
> if (/^(CONFIG.*)=(m|y)/) {
> +if (in_preserved_kconfigs($1)) {
> +dprint "Preserve config $1";
> +print;
> +next;
> +}
> if (defined($configs{$1})) {
> if ($localyesconfig) {
> $setconfigs{$1} = 'y';
> --
> 2.25.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 4/6] drivers: base: default KUNIT_* fragments to KUNIT_RUN_ALL
On Tue, May 5, 2020 at 6:27 PM Anders Roxell wrote: > > This makes it easier to enable all KUnit fragments. > > Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if > someone wants that even though KUNIT_RUN_ALL is enabled. As with patch 2, minor typos here. > Signed-off-by: Anders Roxell Reviewed-by: David Gow > --- > drivers/base/Kconfig | 3 ++- > drivers/base/test/Kconfig | 3 ++- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig > index 5f0bc74d2409..c48e6e4ef367 100644 > --- a/drivers/base/Kconfig > +++ b/drivers/base/Kconfig > @@ -149,8 +149,9 @@ config DEBUG_TEST_DRIVER_REMOVE > test this functionality. > > config PM_QOS_KUNIT_TEST > - bool "KUnit Test for PM QoS features" > + bool "KUnit Test for PM QoS features" if !KUNIT_RUN_ALL > depends on KUNIT=y > + default KUNIT_RUN_ALL > > config HMEM_REPORTING > bool > diff --git a/drivers/base/test/Kconfig b/drivers/base/test/Kconfig > index 305c7751184a..0d662d689f6b 100644 > --- a/drivers/base/test/Kconfig > +++ b/drivers/base/test/Kconfig > @@ -9,5 +9,6 @@ config TEST_ASYNC_DRIVER_PROBE > > If unsure say N. > config KUNIT_DRIVER_PE_TEST > - bool "KUnit Tests for property entry API" > + bool "KUnit Tests for property entry API" if !KUNIT_RUN_ALL > depends on KUNIT=y > + default KUNIT_RUN_ALL > -- > 2.20.1 >
Re: [PATCH v2 2/6] kunit: default KUNIT_* fragments to KUNIT_RUN_ALL
On Tue, May 5, 2020 at 6:27 PM Anders Roxell wrote: > > This makes it easier to enable all KUnit fragments. > > Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if > someone wants that even though KUNIT_RUN_ALL is enabled. nit: Should this be "turned off" rather than "turned of" (and "individual tests" rather than "individual test"). It _may_ be worth re-wording it to explain the "if !KUNIT_RUN_ALL" change in more detail: that it's explicitly hiding the prompt if KUNIT_RUN_ALL is enabled. It's probably not worth redoing the patch just for this, but if you've got to re-do all these to change KUNIT_RUN_ALL to KUNIT_ALL_TESTS or similar, maybe. > > Signed-off-by: Anders Roxell Reviewed-by: David Gow > --- > lib/kunit/Kconfig | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig > index 537f37bc8400..e6a60391fa6b 100644 > --- a/lib/kunit/Kconfig > +++ b/lib/kunit/Kconfig > @@ -15,7 +15,8 @@ menuconfig KUNIT > if KUNIT > > config KUNIT_DEBUGFS > - bool "KUnit - Enable /sys/kernel/debug/kunit debugfs representation" > + bool "KUnit - Enable /sys/kernel/debug/kunit debugfs representation" > if !KUNIT_RUN_ALL > + default KUNIT_RUN_ALL > help > Enable debugfs representation for kunit. Currently this consists > of /sys/kernel/debug/kunit//results files for each > @@ -23,7 +24,8 @@ config KUNIT_DEBUGFS > run that occurred. > > config KUNIT_TEST > - tristate "KUnit test for KUnit" > + tristate "KUnit test for KUnit" if !KUNIT_RUN_ALL > + default KUNIT_RUN_ALL > help > Enables the unit tests for the KUnit test framework. These tests > test > the KUnit test framework itself; the tests are both written using > @@ -32,7 +34,8 @@ config KUNIT_TEST > expected. > > config KUNIT_EXAMPLE_TEST > - tristate "Example test for KUnit" > + tristate "Example test for KUnit" if !KUNIT_RUN_ALL > + default KUNIT_RUN_ALL > help > Enables an example unit test that illustrates some of the basic > features of KUnit. This test only exists to help new users > understand > -- > 2.20.1 >
Re: [PATCH v9 0/8] Add endpoint driver for R-Car PCIe controller
Hi Prabhakar,
On 5/5/2020 3:17 PM, Lad, Prabhakar wrote:
> Hi Lorenzo,
>
> On Tue, May 5, 2020 at 10:44 AM Lorenzo Pieralisi
> wrote:
>>
>> On Thu, Apr 30, 2020 at 09:43:20AM +0100, Lad, Prabhakar wrote:
>>> Hi Kishon,
>>>
>>> On Thu, Apr 23, 2020 at 7:23 PM Lad Prabhakar
>>> wrote:
Hi All,
This patch series adds support for endpoint driver for R-Car PCIe
controller on
R-Car/RZ-G2x SoC's, this also extends the epf framework to handle multiple
windows
supported by the controller for mapping PCI address locally.
Note:
The cadence/rockchip/designware endpoint drivers are build tested only.
Changes for v9 (Re-spun this series as there were minimal changes
requested):
* Rebased patches on top of v5.7.rc1
* Replaced mdelay(1) with usleep_range(1000, 1001) in
rcar_pcie_ep_assert_intx()
* Added a check for max_functions read from DT to restrict with
RCAR_EPC_MAX_FUNCTIONS
* Replaced MSICAP0_MMENUM with MSICAP0_MMESE
* Retry ioremap for other windows on failure in pci_epc_mem_alloc_addr()
* Fixed looping for number windows in pci_epc_mem_exit()
* Set maximum to 1 for max-functions in DT binding (I have restored the
acks
from Rob and Shimoda-san)
* Sorted the entry in MAINTAINERS
Changes for v8:
* Dropped adding R8A774C0 (0x002d) pci-id in pci_ids.h
* Fixed typo in commit message for patch 2/8
* Reworded commit message for patch 5/8 as suggested by Bjorn
* Split up patch to add pci_epc_mem_init() interface to add page_size
argument
as suggested by Bjorn.
Changes for v7:
* Fixed review comments pointed by Shimoda-san
1] Made DT bindings dual licensed, added Shimoda-san as maintainer and
fixed
the example as its built with #{address,size}-cells = <1>. I have
still
restored the Ack from Rob and Shimoda-san with these changes.
2] Split up the patches so that they can be picked up by respective
subsystem
patches 1/4-9/11 are now part of this series.
3] Dropped altering a comment in pci-epc.h
4] Used a local variable align_size in pci_epc_mem_alloc_addr() so that
size
variable doesn't get overwritten in the loop.
5] Replaced i-=1 with i--
6] Replaced rcar with R-Car in patch subject and description.
7] Set MACCTLR in init() callback
Changes for v6:
1] Rebased patches on endpoint branch of https://git.kernel.org/pub/
scm/linux/kernel/git/lpieralisi/pci.git/
2] Fixed review comments from Shimoda-san
a] Made sure defconfig changes were in separate patch
b] Created rcar_pcie_host/rcar_pcie_ep structures
c] Added pci-id for R8A774C0
d] Added entry in MAINTAINERS for dt-binding
e] Dropped unnecessary braces
3] Added support for msi.
Changes for v5:
1] Rebased patches on next branch of https://git.kernel.org/pub/scm/
linux/kernel/git/helgaas/pci.git
2] Fixed review comments reported by Kishon while fetching the matching
window in function pci_epc_get_matching_window()
3] Fixed review comments reported by Bjorn
a] Split patch up first patch so that its easier to review and
incremental
b] Fixed typos
4] Included Reviewed tag from Rob for the dt-binding patch
5] Fixed issue reported by Nathan for assigning variable to itself
Changes for v4:
1] Fixed dtb_check error reported by Rob
2] Fixed review comments reported by Kishon
a] Dropped pci_epc_find_best_fit_window()
b] Fixed initializing mem ptr in __pci_epc_mem_init()
c] Dropped map_size from pci_epc_mem_window structure
Changes for v3:
1] Fixed review comments from Bjorn and Kishon.
3] Converted to DT schema
Changes for v2:
1] Fixed review comments from Biju for dt-bindings to include an example
for a tested platform.
2] Fixed review comments from Kishon to extend the features of outbound
regions in epf framework.
3] Added support to parse outbound-ranges in OF.
Lad Prabhakar (8):
PCI: rcar: Rename pcie-rcar.c to pcie-rcar-host.c
PCI: rcar: Move shareable code to a common file
PCI: rcar: Fix calculating mask for PCIEPAMR register
PCI: endpoint: Pass page size as argument to pci_epc_mem_init()
PCI: endpoint: Add support to handle multiple base for mapping
outbound memory
>>> Could you please do the needy for the above two patches, so that this
>>> can be picked up by Lorenzo.
>>
>> Yes please. I would kindly ask you to rebase it on top of my
>> pci/rcar branch - with Kishon's ACK when provided.
>>
> Sure will do that as soon as I get Kishon's Ack.
I've given my Acked by on the two endpoint core patches. I've also tested my
endpoint series [1] after applying this series.
[PATCH] platform/x86: acerhdf: replace space by * in modalias
Using space in module alias makes it harder to parse modules.alias.
Replace it by a star(*).
Reviewed-by: Peter Kästle
Signed-off-by: Chih-Wei Huang
---
drivers/platform/x86/acerhdf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 505224225378..306ea92d5b10 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -837,7 +837,7 @@ MODULE_ALIAS("dmi:*:*Packard*Bell*:pnDOTMU*:");
MODULE_ALIAS("dmi:*:*Packard*Bell*:pnENBFT*:");
MODULE_ALIAS("dmi:*:*Packard*Bell*:pnDOTMA*:");
MODULE_ALIAS("dmi:*:*Packard*Bell*:pnDOTVR46*:");
-MODULE_ALIAS("dmi:*:*Acer*:pnExtensa 5420*:");
+MODULE_ALIAS("dmi:*:*Acer*:pnExtensa*5420*:");
module_init(acerhdf_init);
module_exit(acerhdf_exit);
--
2.21.1
Re: [PATCH v2 3/6] lib: Kconfig.debug: default KUNIT_* fragments to KUNIT_RUN_ALL
On Tue, May 5, 2020 at 6:27 PM Anders Roxell wrote: > > This makes it easier to enable all KUnit fragments. > > Adding 'if !KUNIT_RUN_ALL' so individual test can be turned of if > someone wants that even though KUNIT_RUN_ALL is enabled. > > Signed-off-by: Anders Roxell Reviewed-by: David Gow Thanks! -- David > --- > lib/Kconfig.debug | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 21d9c5f6e7ec..d1a94ff56a87 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -2064,8 +2064,9 @@ config TEST_SYSCTL > If unsure, say N. > > config SYSCTL_KUNIT_TEST > - tristate "KUnit test for sysctl" > + tristate "KUnit test for sysctl" if !KUNIT_RUN_ALL > depends on KUNIT > + default KUNIT_RUN_ALL > help > This builds the proc sysctl unit test, which runs on boot. > Tests the API contract and implementation correctness of sysctl. > @@ -2075,8 +2076,9 @@ config SYSCTL_KUNIT_TEST > If unsure, say N. > > config LIST_KUNIT_TEST > - tristate "KUnit Test for Kernel Linked-list structures" > + tristate "KUnit Test for Kernel Linked-list structures" if > !KUNIT_RUN_ALL > depends on KUNIT > + default KUNIT_RUN_ALL > help > This builds the linked list KUnit test suite. > It tests that the API and basic functionality of the list_head type > -- > 2.20.1 >
[PATCH v2 RESEND] sched/cpuacct: Use __this_cpu_add() instead of this_cpu_ptr()
The cpuacct_charge() and cpuacct_account_field() are called with rq->lock held, and this means preemption(and IRQs) are indeed disabled, so it is safe to use __this_cpu_*() to allow for better code-generation. Signed-off-by: Muchun Song --- Chane in v2: 1. Update changelog. kernel/sched/cpuacct.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c index 9fbb103834345..6448b0438ffb2 100644 --- a/kernel/sched/cpuacct.c +++ b/kernel/sched/cpuacct.c @@ -347,7 +347,7 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime) rcu_read_lock(); for (ca = task_ca(tsk); ca; ca = parent_ca(ca)) - this_cpu_ptr(ca->cpuusage)->usages[index] += cputime; + __this_cpu_add(ca->cpuusage->usages[index], cputime); rcu_read_unlock(); } @@ -363,7 +363,7 @@ void cpuacct_account_field(struct task_struct *tsk, int index, u64 val) rcu_read_lock(); for (ca = task_ca(tsk); ca != _cpuacct; ca = parent_ca(ca)) - this_cpu_ptr(ca->cpustat)->cpustat[index] += val; + __this_cpu_add(ca->cpustat->cpustat[index], val); rcu_read_unlock(); } -- 2.11.0
Re:[PATCH] drm/exynos: make pointer to const data const type
From: Bernard Zhao
Date: 2020-04-26 17:01:42
To: Inki Dae ,Joonyoung Shim
,Seung-Woo Kim ,Kyungmin Park
,David Airlie ,Daniel Vetter
,Kukjin Kim ,Krzysztof Kozlowski
,dri-de...@lists.freedesktop.org,linux-arm-ker...@lists.infradead.org,linux-samsung-...@vger.kernel.org,linux-kernel@vger.kernel.org
Cc: opensource.ker...@vivo.com,Bernard Zhao
Subject: [PATCH] drm/exynos: make pointer to const data const type>Maybe keep
pointer which points to global const string data
>in const type is better, make sure not change const data.
>
>Signed-off-by: Bernard Zhao
>---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>index e080aa92338c..f60d99c85ac9 100644
>--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>@@ -211,7 +211,7 @@
>
> #define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
>
>-static char *clk_names[5] = { "bus_clk", "sclk_mipi",
>+static const char *const clk_names[5] = { "bus_clk", "sclk_mipi",
> "phyclk_mipidphy0_bitclkdiv8", "phyclk_mipidphy0_rxclkesc0",
> "sclk_rgb_vclk_to_dsim0" };
>
>diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
>b/drivers/gpu/drm/exynos/exynos_drm_mic.c
>index f41d75923557..a86abc173605 100644
>--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
>+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
>@@ -88,7 +88,7 @@
>
> #define MIC_BS_SIZE_2D(x) ((x) & 0x3fff)
>
>-static char *clk_names[] = { "pclk_mic0", "sclk_rgb_vclk_to_mic0" };
>+static const char *const clk_names[] = { "pclk_mic0", "sclk_rgb_vclk_to_mic0"
>};
> #define NUM_CLKS ARRAY_SIZE(clk_names)
> static DEFINE_MUTEX(mic_mutex);
>
>--
>2.26.2
>
Re:[PATCH] drm/meson: pm resume add return errno branch
From: Bernard Zhao Date: 2020-04-28 21:17:47 To: Neil Armstrong ,David Airlie ,Daniel Vetter ,Kevin Hilman ,dri-de...@lists.freedesktop.org,linux-amlo...@lists.infradead.org,linux-arm-ker...@lists.infradead.org,linux-kernel@vger.kernel.org Cc: opensource.ker...@vivo.com,Bernard Zhao Subject: [PATCH] drm/meson: pm resume add return errno branch>pm_resump api did not handle drm_mode_config_helper_resume error. >This change add handle to return drm_mode_config_helper_resume`s >error number. This code logic is aligned with api pm_suspend. >After this change, the code maybe a bit readable. > >Signed-off-by: Bernard Zhao >--- > drivers/gpu/drm/meson/meson_drv.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > >diff --git a/drivers/gpu/drm/meson/meson_drv.c >b/drivers/gpu/drm/meson/meson_drv.c >index b5f5eb7b4bb9..8c2e1b47e81a 100644 >--- a/drivers/gpu/drm/meson/meson_drv.c >+++ b/drivers/gpu/drm/meson/meson_drv.c >@@ -412,9 +412,7 @@ static int __maybe_unused meson_drv_pm_resume(struct >device *dev) > if (priv->afbcd.ops) > priv->afbcd.ops->init(priv); > >- drm_mode_config_helper_resume(priv->drm); >- >- return 0; >+ return drm_mode_config_helper_resume(priv->drm); > } > > static int compare_of(struct device *dev, void *data) >-- >2.26.2 >
Re: [PATCH v2 1/6] kunit: Kconfig: enable a KUNIT_RUN_ALL fragment
On Wed, May 6, 2020 at 6:33 PM Anders Roxell wrote: > > Hi David, > > Thank you for the review. > > On Wed, 6 May 2020 at 07:08, David Gow wrote: > > > > On Tue, May 5, 2020 at 6:27 PM Anders Roxell > > wrote: > > > > > > Make it easier to enable all KUnit fragments. This is needed for kernel > > > test-systems, so its easy to get all KUnit tests enabled and if new gets > > > added they will be enabled as well. Fragments that has to be builtin > > > will be missed if CONFIG_KUNIT_RUN_ALL is set as a module. > > > > > > Signed-off-by: Anders Roxell > > > --- > > > lib/kunit/Kconfig | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig > > > index 95d12e3d6d95..537f37bc8400 100644 > > > --- a/lib/kunit/Kconfig > > > +++ b/lib/kunit/Kconfig > > > @@ -41,4 +41,10 @@ config KUNIT_EXAMPLE_TEST > > > is intended for curious hackers who would like to understand > > > how to > > > use KUnit for kernel development. > > > > > > +config KUNIT_RUN_ALL > > > + tristate "KUnit run all test" > > > > I'm not 100% sure about this name and description. It only actually > > "runs" the tests if they're builtin (as modules, they'll only run when > > loaded). > > > > Would KUNIT_BUILD_ALL or KUNIT_ALL_TESTS > > I would like to go with KUNIT_ALL_TESTS if no one objects. > Personally, I'm fine with that. Brendan, thoughts? > > or similar be better? > > > > It also, as mentioned, only really runs all available (i.e., with > > dependencies met in the current .config) tests (as distinct from the > > --alltests flag to kunit.py, which builds UML with allyesconfig), it > > might be good to add this to the description or help. > > > > Something like "Enable all KUnit tests" or "Enable all available KUnit > > tests" (or even something about "all KUnit tests with satisfied > > dependencies") might be clearer. > > I like "All KUnit tests with satisfied dependencies". > > > > > > + help > > > + Enables all KUnit tests, if they can be enabled. > > > + That depends on if KUnit is enabled as a module or builtin. > > > + > > I like the first line here, but the second one could use a bit more > > explanation. Maybe copy some of the boilerplate text from other tests, > > e.g.: > > > > KUnit tests run during boot and output the results to the debug > > log > > in TAP format (http://testanything.org/). Only useful for kernel > > devs > > running the KUnit test harness, and not intended for inclusion > > into a > > production build. > > > > For more information on KUnit and unit tests in general please > > refer > > to the KUnit documentation in Documentation/dev-tools/kunit/. > > > > If unsure, say N. > > Makes much more sense, thanks. > > > > > > endif # KUNIT > > > -- > > > 2.20.1 > > > > > > > Otherwise, this is looking good. I've done some quick testing, and it > > all seems to work for me. As long as it's clear what the difference > > between this and other ways of running "all tests" (like the > > --alltests kunit.py option), > > Do you think it should be made clearer in some way? > I think the changes above should do it. -- David
Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller
John Stultz 于2020年5月7日周四 上午6:27写道： > > On Wed, May 6, 2020 at 2:00 AM Jun Li wrote: > > John Stultz 于2019年10月30日周三 上午5:18写道： > > > On Tue, Oct 29, 2019 at 2:11 AM Felipe Balbi wrote: > > > > John Stultz writes: > > > > > From: Yu Chen > > > > > > > > > > It needs more time for the device controller to clear the CmdAct of > > > > > DEPCMD on Hisilicon Kirin Soc. > > > > > > > > Why does it need more time? Why is it so that no other platform needs > > > > more time, only this one? And which command, specifically, causes > > > > problem? > > > > Sorry for my back to this so late. > > > > This change is required on my dwc3 based HW too, I gave a check > > and the reason is suspend_clk is used in case the PIPE phy is at P3, > > this slow clock makes my EP command below timeout. > > > > dwc3_gadget_ep_cmd: ep0out: cmd 'Set Endpoint Configuration' [401] > > params 1000 0500 --> status: Timed Out > > > > Success case takes about 400us to complete, see below trace(44.286278 > > - 44.285897 = 0.000381): > > > > configfs_acm.sh-822 [000] d..144.285896: dwc3_writel: addr > > 6d59aae1 value 0401 > > configfs_acm.sh-822 [000] d..144.285897: dwc3_readl: addr > > 6d59aae1 value 0401 > > ... ... > > configfs_acm.sh-822 [000] d..144.286278: dwc3_readl: addr > > 6d59aae1 value 0001 > > configfs_acm.sh-822 [000] d..144.286279: dwc3_gadget_ep_cmd: > > ep0out: cmd 'Set Endpoint Configuration' [401] params 1000 > > 0500 --> status: Successful > > > > Hi John, > > > > Do you still have this problem? if yes, What's the value of > > USBLNKST[21:18] when the timeout happens? > > Sorry. As I mentioned, I was working to upstream a patchset that I > hadn't created, so the context I had was limited. As I couldn't > reproduce an issue without the change on the device I had, I figured > it would be best to drop it. That was fine. > > However, as you have some analysis and rational for why such a change > would be needed, I don't have an objection to it. Do you want to > resubmit the patch with your explanation and detailed log above in the > commit message? Sure, I will resubmit the patch with my explanation added in commit message. thanks Li Jun > > thanks > -john
linux-next: build warning after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/gpu/drm/panel/panel-visionox-rm69299.o
see include/linux/module.h for more information
Introduced by commit
c7f66d32dd43 ("drm/panel: add support for rm69299 visionox panel")
--
Cheers,
Stephen Rothwell
pgp0KaDX4YQb3.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] f2fs: shrink spinlock coverage
On 2020/5/6 23:05, Jaegeuk Kim wrote:
> On 05/06, Chao Yu wrote:
>> In f2fs_try_to_free_nids(), .nid_list_lock spinlock critical region will
>> increase as expected shrink number increase, to avoid spining other CPUs
>> for long time, it's better to implement like extent cache and nats
>> shrinker.
>>
>> Signed-off-by: Chao Yu
>> ---
>> v2:
>> - fix unlock wrong spinlock.
>> fs/f2fs/node.c | 15 +++
>> 1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index 4da0d8713df5..ad0b14f4dab8 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -2488,7 +2488,6 @@ void f2fs_alloc_nid_failed(struct f2fs_sb_info *sbi,
>> nid_t nid)
>> int f2fs_try_to_free_nids(struct f2fs_sb_info *sbi, int nr_shrink)
>> {
>> struct f2fs_nm_info *nm_i = NM_I(sbi);
>> -struct free_nid *i, *next;
>> int nr = nr_shrink;
>>
>> if (nm_i->nid_cnt[FREE_NID] <= MAX_FREE_NIDS)
>> @@ -2498,14 +2497,22 @@ int f2fs_try_to_free_nids(struct f2fs_sb_info *sbi,
>> int nr_shrink)
>> return 0;
>>
>> spin_lock(_i->nid_list_lock);
>> -list_for_each_entry_safe(i, next, _i->free_nid_list, list) {
>> -if (nr_shrink <= 0 ||
>> -nm_i->nid_cnt[FREE_NID] <= MAX_FREE_NIDS)
>> +while (nr_shrink) {
>> +struct free_nid *i;
>> +
>> +if (nm_i->nid_cnt[FREE_NID] <= MAX_FREE_NIDS)
>> break;
>>
>> +i = list_first_entry(_i->free_nid_list,
>> +struct free_nid, list);
>> +list_del(>list);
>> +spin_unlock(_i->nid_list_lock);
>> +
>> __remove_free_nid(sbi, i, FREE_NID);
>
> __remove_free_nid() will do list_del again. btw, how about just splitting out
Oh, my bad.
How about moving __remove_free_nid into .nid_list_lock coverage?
> given nr_shrink into multiple trials?
Like this?
while (shrink) {
batch = DEFAULT_BATCH_NUMBER; // 16
spinlock();
list_for_each_entry_safe() {
if (!shrink || !batch)
break;
remove_item_from_list;
shrink--;
batch--;
}
spin_unlock();
}
Thanks,
>
>> kmem_cache_free(free_nid_slab, i);
>> nr_shrink--;
>> +
>> +spin_lock(_i->nid_list_lock);
>> }
>> spin_unlock(_i->nid_list_lock);
>> mutex_unlock(_i->build_lock);
>> --
>> 2.18.0.rc1
> .
>
Re: [PATCH] slub: limit count of partial slabs scanned to gather statistics
> On May 6, 2020, at 3:06 PM, Qian Cai wrote:
>
>
>
>> On May 4, 2020, at 12:07 PM, Konstantin Khlebnikov
>> wrote:
>>
>> To get exact count of free and used objects slub have to scan list of
>> partial slabs. This may take at long time. Scanning holds spinlock and
>> blocks allocations which move partial slabs to per-cpu lists and back.
>>
>> Example found in the wild:
>>
>> # cat /sys/kernel/slab/dentry/partial
>> 14478538 N0=7329569 N1=7148969
>> # time cat /sys/kernel/slab/dentry/objects
>> 286225471 N0=136967768 N1=149257703
>>
>> real 0m1.722s
>> user 0m0.001s
>> sys 0m1.721s
>>
>> The same problem in slab was addressed in commit f728b0a5d72a ("mm, slab:
>> faster active and free stats") by adding more kmem cache statistics.
>> For slub same approach requires atomic op on fast path when object frees.
>>
>> Let's simply limit count of scanned slabs and print warning.
>> Limit set in /sys/module/slub/parameters/max_partial_to_count.
>> Default is 1 which should be enough for most sane cases.
>>
>> Return linear approximation if list of partials is longer than limit.
>> Nobody should notice difference.
>>
>> Signed-off-by: Konstantin Khlebnikov
>
> This patch will trigger the warning under memory pressure, and then makes
> lockdep unhappy. Also, it is almost impossible tell how many
> max_partial_to_count is sufficient from user perspective.
Andrew, Stephen, can you remove this patch from linux-next?
Even read some procfs files would trigger the warning and lockdep on a debug
kernel probably due to kmemleak and debugobjects that would require more
partial slabs objects. Thus, it would be problematic to break testing bots on
linux-next like this.
>
> [ 6371.600511] SLUB: too much partial slabs to count all objects, increase
> max_partial_to_count.
> [ 6371.601399] irq event stamp: 8132599
>
> [ 6371.611415] ==
> [ 6371.611417] WARNING: possible circular locking dependency detected
> [ 6371.611419] 5.7.0-rc4-mm1+ #1 Not tainted
> [ 6371.611421] --
> [ 6371.611423] oom02/43515 is trying to acquire lock:
> [ 6371.611425] 893b8980 (console_owner){-.-.}-{0:0}, at:
> console_unlock+0x240/0x750
>
> [ 6371.611433] but task is already holding lock:
> [ 6371.611434] 8886456fcb98 (>list_lock){-.-.}-{2:2}, at:
> count_partial+0x29/0xe0
>
> [ 6371.611441] which lock already depends on the new lock.
>
>
> [ 6371.611445] the existing dependency chain (in reverse order) is:
>
> [ 6371.611446] -> #3 (>list_lock){-.-.}-{2:2}:
> [ 6371.611452]_raw_spin_lock+0x2f/0x40
> [ 6371.611453]deactivate_slab+0x37a/0x690
> [ 6371.611455]___slab_alloc+0x65d/0x810
> [ 6371.611456]__slab_alloc+0x43/0x70
> [ 6371.611457]__kmalloc+0x2b2/0x430
> [ 6371.611459]__tty_buffer_request_room+0x100/0x250
> [ 6371.611460]tty_insert_flip_string_fixed_flag+0x67/0x130
> [ 6371.611462]pty_write+0xa2/0xf0
> [ 6371.611463]n_tty_write+0x36b/0x7c0
> [ 6371.611464]tty_write+0x275/0x500
> [ 6371.611466]__vfs_write+0x50/0xa0
> [ 6371.611467]vfs_write+0x10b/0x290
> [ 6371.611468]redirected_tty_write+0x6a/0xc0
> [ 6371.611470]do_iter_write+0x253/0x2b0
> [ 6371.611471]vfs_writev+0x152/0x1f0
> [ 6371.611472]do_writev+0xda/0x180
> [ 6371.611474]__x64_sys_writev+0x45/0x50
> [ 6371.611475]do_syscall_64+0xcc/0xaf0
> [ 6371.611477]entry_SYSCALL_64_after_hwframe+0x49/0xb3
>
> [ 6371.611478] -> #2 (>lock#2){-.-.}-{2:2}:
> [ 6371.611484]_raw_spin_lock_irqsave+0x3a/0x50
> [ 6371.611486]tty_port_tty_get+0x22/0xa0
> [ 6371.611487]tty_port_default_wakeup+0xf/0x30
> [ 6371.611489]tty_port_tty_wakeup+0x39/0x40
> [ 6371.611490]uart_write_wakeup+0x2a/0x40
> [ 6371.611492]serial8250_tx_chars+0x22e/0x410
> [ 6371.611493]serial8250_handle_irq.part.21+0x17c/0x180
> [ 6371.611495]serial8250_default_handle_irq+0x5c/0x90
> [ 6371.611496]serial8250_interrupt+0xa6/0x130
> [ 6371.611498]__handle_irq_event_percpu+0x81/0x550
> [ 6371.611499]handle_irq_event_percpu+0x70/0x100
> [ 6371.611501]handle_irq_event+0x5a/0x8b
> [ 6371.611502]handle_edge_irq+0x10c/0x370
> [ 6371.611503]do_IRQ+0x9e/0x1d0
> [ 6371.611505]ret_from_intr+0x0/0x37
> [ 6371.611506]cpuidle_enter_state+0x148/0x910
> [ 6371.611507]cpuidle_enter+0x41/0x70
> [ 6371.611509]do_idle+0x3cf/0x440
> [ 6371.611510]cpu_startup_entry+0x1d/0x1f
> [ 6371.611511]start_secondary+0x29a/0x340
> [ 6371.611513]secondary_startup_64+0xb6/0xc0
>
> [ 6371.611516] -> #1 (>lock){-.-.}-{2:2}:
> [ 6371.611522]_raw_spin_lock_irqsave+0x3a/0x50
> [ 6371.611525]serial8250_console_write+0x113/0x560
> [ 6371.611527]univ8250_console_write+0x4b/0x60
> [
Re: [PATCH v9 5/8] PCI: endpoint: Add support to handle multiple base for mapping outbound memory
On 4/23/2020 11:52 PM, Lad Prabhakar wrote:
> R-Car PCIe controller has support to map multiple memory regions for
> mapping the outbound memory in local system also the controller limits
> single allocation for each region (that is, once a chunk is used from the
> region it cannot be used to allocate a new one). This features inspires to
> add support for handling multiple memory bases in endpoint framework.
>
> With this patch pci_epc_mem_init() initializes address space for endpoint
> controller which support single window and pci_epc_multi_mem_init()
> initializes multiple windows supported by endpoint controller.
>
> Signed-off-by: Lad Prabhakar
Acked-by: Kishon Vijay Abraham I
> ---
> .../pci/controller/dwc/pcie-designware-ep.c | 16 +-
> drivers/pci/endpoint/pci-epc-mem.c| 199 --
> include/linux/pci-epc.h | 33 ++-
> 3 files changed, 170 insertions(+), 78 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index 1cdcbd102ce8..a78902cbf2f0 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -412,11 +412,11 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8
> func_no,
> reg = ep->msi_cap + PCI_MSI_DATA_32;
> msg_data = dw_pcie_readw_dbi(pci, reg);
> }
> - aligned_offset = msg_addr_lower & (epc->mem->page_size - 1);
> + aligned_offset = msg_addr_lower & (epc->mem->window.page_size - 1);
> msg_addr = ((u64)msg_addr_upper) << 32 |
> (msg_addr_lower & ~aligned_offset);
> ret = dw_pcie_ep_map_addr(epc, func_no, ep->msi_mem_phys, msg_addr,
> - epc->mem->page_size);
> + epc->mem->window.page_size);
> if (ret)
> return ret;
>
> @@ -459,9 +459,9 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8
> func_no,
> return -EPERM;
> }
>
> - aligned_offset = msg_addr & (epc->mem->page_size - 1);
> + aligned_offset = msg_addr & (epc->mem->window.page_size - 1);
> ret = dw_pcie_ep_map_addr(epc, func_no, ep->msi_mem_phys, msg_addr,
> - epc->mem->page_size);
> + epc->mem->window.page_size);
> if (ret)
> return ret;
>
> @@ -477,7 +477,7 @@ void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
> struct pci_epc *epc = ep->epc;
>
> pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
> - epc->mem->page_size);
> + epc->mem->window.page_size);
>
> pci_epc_mem_exit(epc);
> }
> @@ -610,15 +610,15 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> if (ret < 0)
> epc->max_functions = 1;
>
> - ret = __pci_epc_mem_init(epc, ep->phys_base, ep->addr_size,
> - ep->page_size);
> + ret = pci_epc_mem_init(epc, ep->phys_base, ep->addr_size,
> +ep->page_size);
> if (ret < 0) {
> dev_err(dev, "Failed to initialize address space\n");
> return ret;
> }
>
> ep->msi_mem = pci_epc_mem_alloc_addr(epc, >msi_mem_phys,
> - epc->mem->page_size);
> + epc->mem->window.page_size);
> if (!ep->msi_mem) {
> dev_err(dev, "Failed to reserve memory for MSI/MSI-X\n");
> return -ENOMEM;
> diff --git a/drivers/pci/endpoint/pci-epc-mem.c
> b/drivers/pci/endpoint/pci-epc-mem.c
> index cdd1d3821249..a3466da2a16f 100644
> --- a/drivers/pci/endpoint/pci-epc-mem.c
> +++ b/drivers/pci/endpoint/pci-epc-mem.c
> @@ -23,7 +23,7 @@
> static int pci_epc_mem_get_order(struct pci_epc_mem *mem, size_t size)
> {
> int order;
> - unsigned int page_shift = ilog2(mem->page_size);
> + unsigned int page_shift = ilog2(mem->window.page_size);
>
> size--;
> size >>= page_shift;
> @@ -36,67 +36,95 @@ static int pci_epc_mem_get_order(struct pci_epc_mem *mem,
> size_t size)
> }
>
> /**
> - * __pci_epc_mem_init() - initialize the pci_epc_mem structure
> + * pci_epc_multi_mem_init() - initialize the pci_epc_mem structure
> * @epc: the EPC device that invoked pci_epc_mem_init
> - * @phys_base: the physical address of the base
> - * @size: the size of the address space
> - * @page_size: size of each page
> + * @windows: pointer to windows supported by the device
> + * @num_windows: number of windows device supports
> *
> * Invoke to initialize the pci_epc_mem structure used by the
> * endpoint functions to allocate mapped PCI address.
> */
> -int __pci_epc_mem_init(struct pci_epc *epc, phys_addr_t phys_base, size_t
> size,
> -size_t page_size)
> +int pci_epc_multi_mem_init(struct pci_epc *epc,
> +
Re: [PATCH v9 4/8] PCI: endpoint: Pass page size as argument to pci_epc_mem_init()
On 4/23/2020 11:52 PM, Lad Prabhakar wrote:
> pci_epc_mem_init() internally used page size equal to *PAGE_SIZE* to
> manage the address space so instead just pass the page size as a
> argument to pci_epc_mem_init().
>
> Also make pci_epc_mem_init() as a C function instead of a macro function
> in preparation for adding support for pci-epc-mem core to handle multiple
> windows.
>
> Signed-off-by: Lad Prabhakar
Acked-by: Kishon Vijay Abraham I
> ---
> drivers/pci/controller/cadence/pcie-cadence-ep.c | 2 +-
> drivers/pci/controller/pcie-rockchip-ep.c| 2 +-
> drivers/pci/endpoint/pci-epc-mem.c | 7 +++
> include/linux/pci-epc.h | 5 ++---
> 4 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c
> b/drivers/pci/controller/cadence/pcie-cadence-ep.c
> index 1c173dad67d1..1c15c8352125 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
> @@ -450,7 +450,7 @@ int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
> epc->max_functions = 1;
>
> ret = pci_epc_mem_init(epc, pcie->mem_res->start,
> -resource_size(pcie->mem_res));
> +resource_size(pcie->mem_res), PAGE_SIZE);
> if (ret < 0) {
> dev_err(dev, "failed to initialize the memory space\n");
> goto err_init;
> diff --git a/drivers/pci/controller/pcie-rockchip-ep.c
> b/drivers/pci/controller/pcie-rockchip-ep.c
> index d743b0a48988..5eaf36629a75 100644
> --- a/drivers/pci/controller/pcie-rockchip-ep.c
> +++ b/drivers/pci/controller/pcie-rockchip-ep.c
> @@ -615,7 +615,7 @@ static int rockchip_pcie_ep_probe(struct platform_device
> *pdev)
> rockchip_pcie_write(rockchip, BIT(0), PCIE_CORE_PHY_FUNC_CFG);
>
> err = pci_epc_mem_init(epc, rockchip->mem_res->start,
> -resource_size(rockchip->mem_res));
> +resource_size(rockchip->mem_res), PAGE_SIZE);
> if (err < 0) {
> dev_err(dev, "failed to initialize the memory space\n");
> goto err_uninit_port;
> diff --git a/drivers/pci/endpoint/pci-epc-mem.c
> b/drivers/pci/endpoint/pci-epc-mem.c
> index abfac1109a13..cdd1d3821249 100644
> --- a/drivers/pci/endpoint/pci-epc-mem.c
> +++ b/drivers/pci/endpoint/pci-epc-mem.c
> @@ -93,6 +93,13 @@ return ret;
> }
> EXPORT_SYMBOL_GPL(__pci_epc_mem_init);
>
> +int pci_epc_mem_init(struct pci_epc *epc, phys_addr_t base,
> + size_t size, size_t page_size)
> +{
> + return __pci_epc_mem_init(epc, base, size, page_size);
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_mem_init);
> +
> /**
> * pci_epc_mem_exit() - cleanup the pci_epc_mem structure
> * @epc: the EPC device that invoked pci_epc_mem_exit
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index e0ed9d01f6e5..5bc1de65849e 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -137,9 +137,6 @@ struct pci_epc_features {
> #define devm_pci_epc_create(dev, ops)\
> __devm_pci_epc_create((dev), (ops), THIS_MODULE)
>
> -#define pci_epc_mem_init(epc, phys_addr, size) \
> - __pci_epc_mem_init((epc), (phys_addr), (size), PAGE_SIZE)
> -
> static inline void epc_set_drvdata(struct pci_epc *epc, void *data)
> {
> dev_set_drvdata(>dev, data);
> @@ -195,6 +192,8 @@ unsigned int pci_epc_get_first_free_bar(const struct
> pci_epc_features
> struct pci_epc *pci_epc_get(const char *epc_name);
> void pci_epc_put(struct pci_epc *epc);
>
> +int pci_epc_mem_init(struct pci_epc *epc, phys_addr_t base,
> + size_t size, size_t page_size);
> int __pci_epc_mem_init(struct pci_epc *epc, phys_addr_t phys_addr, size_t
> size,
> size_t page_size);
> void pci_epc_mem_exit(struct pci_epc *epc);
>
RE: Re: [v4,iproute2-next 1/2] iproute2-next:tc:action: add a gate control action
Hi Stephen,
> -Original Message-
> From: Stephen Hemminger
> Sent: 2020年5月6日 23:22
> To: Po Liu
> Cc: dsah...@gmail.com; linux-kernel@vger.kernel.org;
> net...@vger.kernel.org; vinicius.go...@intel.com;
> da...@davemloft.net; v...@buslov.dev; Claudiu Manoil
> ; Vladimir Oltean ;
> Alexandru Marginean
> Subject: Re: [v4,iproute2-next 1/2] iproute2-next:tc:action: add a
> gate control action
> On Wed, 6 May 2020 16:40:19 +0800
> Po Liu wrote:
>
> > } else if (matches(*argv, "base-time") == 0) {
> > + NEXT_ARG();
> > + if (get_u64(_time, *argv, 10)) {
> > + invalidarg = "base-time";
> > + goto err_arg;
> > + }
> > + } else if (matches(*argv, "cycle-time") == 0) {
> > + NEXT_ARG();
> > + if (get_u64(_time, *argv, 10)) {
> > + invalidarg = "cycle-time";
> > + goto err_arg;
> > + }
> > + } else if (matches(*argv, "cycle-time-ext") == 0) {
> > + NEXT_ARG();
> > + if (get_u64(_time_ext, *argv, 10)) {
> > + invalidarg = "cycle-time-ext";
> > + goto err_arg;
> > + }
>
> Could all these time values use existing TC helper routines?
I agree to keep the tc routines input.
The names of timer input and type is more reference the taprio input.
> See get_time(). The way you have it makes sense for hardware but stands
> out versus the rest of tc.
>
> It maybe that the kernel UAPI is wrong, and should be using same time
> units as rest of tc. Forgot to review that part of the patch.
I would also sync with kernel UAPI if needed.
Br,
Po Liu
[rcu:tglx.2020.05.05a] BUILD REGRESSION e6d36eed49b863bbe393e3c07cae737cd9c475e3
-irq_work.o:warning:objtool:irqst_sysvec_irq_work():undefined-stack-state `-- x86_64-randconfig-h002-20200503 |-- arch-x86-kernel-irq.o:warning:objtool:irqst_sysvec_kvm_posted_intr_ipi():undefined-stack-state |-- arch-x86-kernel-irq.o:warning:objtool:irqst_sysvec_kvm_posted_intr_nested_ipi():undefined-stack-state |-- arch-x86-kernel-irq.o:warning:objtool:irqst_sysvec_kvm_posted_intr_wakeup_ipi():undefined-stack-state `-- arch-x86-kernel-irq_work.o:warning:objtool:irqst_sysvec_irq_work():undefined-stack-state elapsed time: 2138m configs tested: 166 configs skipped: 0 arm64allyesconfig arm allyesconfig arm64allmodconfig arm allmodconfig arm64 allnoconfig arm allnoconfig sparcallyesconfig m68k allyesconfig um x86_64_defconfig ia64 allnoconfig um allyesconfig nds32 defconfig c6x allnoconfig microblaze allyesconfig cskydefconfig ia64 alldefconfig m68k sun3_defconfig microblazeallnoconfig i386defconfig mips allnoconfig xtensa defconfig i386 allnoconfig i386 allyesconfig i386 alldefconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68k multi_defconfig m68kdefconfig c6x allyesconfig nds32 allnoconfig alpha defconfig csky allyesconfig alphaallyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig openrisc allyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig mips allyesconfig mips 64r6el_defconfig mips 32r2_defconfig mips allmodconfig pariscallnoconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc rhel-kconfig powerpc allnoconfig powerpc allyesconfig powerpc alldefconfig powerpc allmodconfig m68k randconfig-a001-20200506 mips randconfig-a001-20200506 nds32randconfig-a001-20200506 parisc randconfig-a001-20200506 alpharandconfig-a001-20200506 riscvrandconfig-a001-20200506 m68k randconfig-a001-20200505 mips randconfig-a001-20200505 nds32randconfig-a001-20200505 parisc randconfig-a001-20200505 alpharandconfig-a001-20200505 riscvrandconfig-a001-20200505 h8300randconfig-a001-20200506 nios2randconfig-a001-20200506 microblaze randconfig-a001-20200506 c6x randconfig-a001-20200506 sparc64 randconfig-a001-20200506 s390 randconfig-a001-20200505 xtensa randconfig-a001-20200505 sh randconfig-a001-20200505 openrisc randconfig-a001-20200505 csky randconfig-a001-20200505 s390 randconfig-a001-20200430 xtensa randconfig-a001-20200430 csky randconfig-a001-20200430 openrisc randconfig-a001-20200430 sh randconfig-a001-20200430 xtensa randconfig-a001-20200503 openrisc randconfig-a001-20200503 csky randconfig-a001-20200503 i386 randconfig-b003-20200503 x86_64 randconfig-b002-20200503 i386 randconfig-b001-20200503 x86_64 randconfig-b003-20200503 x86_64 randconfig-b001-20200503 i386 randconfig-b002-20200503 i386
Re: [PATCH] kernel: add panic_on_taint
> On May 6, 2020, at 6:28 PM, Rafael Aquini wrote: > > Analogously to the introduction of panic_on_warn, this patch > introduces a kernel option named panic_on_taint in order to > provide a simple and generic way to stop execution and catch > a coredump when the kernel gets tainted by any given taint flag. > > This is useful for debugging sessions as it avoids rebuilding > the kernel to explicitly add calls to panic() or BUG() into > code sites that introduce the taint flags of interest. > Another, perhaps less frequent, use for this option would be > as a mean for assuring a security policy (in paranoid mode) > case where no single taint is allowed for the running system. Andrew, you can drop the patch below from -mm now because that one is now obsolete, mm-slub-add-panic_on_error-to-the-debug-facilities.patch
Re: [f2fs-dev] [PATCH] f2fs: change maximum zstd compression buffer size
On 2020/5/6 22:56, Jaegeuk Kim wrote: > On 05/06, Chao Yu wrote: >> On 2020/5/6 7:05, Jaegeuk Kim wrote: >>> On 05/05, Chao Yu wrote: On 2020-5-4 22:30, Jaegeuk Kim wrote: > From: Daeho Jeong > > Current zstd compression buffer size is one page and header size less > than cluster size. By this, zstd compression always succeeds even if > the real compression data is failed to fit into the buffer size, and > eventually reading the cluster returns I/O error with the corrupted > compression data. What's the root cause of this issue? I didn't get it. > > Signed-off-by: Daeho Jeong > --- > fs/f2fs/compress.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c > index 4c7eaeee52336..a9fa8049b295f 100644 > --- a/fs/f2fs/compress.c > +++ b/fs/f2fs/compress.c > @@ -313,7 +313,7 @@ static int zstd_init_compress_ctx(struct compress_ctx > *cc) > cc->private = workspace; > cc->private2 = stream; > > - cc->clen = cc->rlen - PAGE_SIZE - COMPRESS_HEADER_SIZE; > + cc->clen = ZSTD_compressBound(PAGE_SIZE << cc->log_cluster_size); In my machine, the value is 66572 which is much larger than size of dst buffer, so, in where we can tell the real size of dst buffer to zstd compressor? Otherwise, if compressed data size is larger than dst buffer size, when we flush compressed data into dst buffer, we may suffer overflow. >>> >>> Could you give it a try compress_log_size=2 and check decompression works? >> >> I tried some samples before submitting the patch, did you encounter app's >> data >> corruption when using zstd algorithm? If so, let me check this issue. > > Daeho reported: > 1. cp -a src_file comp_dir/dst_file (comp_dir is a directory for compression) > 2. sync comp_dir/dst_file > 3. echo 3 > /proc/sys/vm/drop_caches > 4. cat comp_dir/dst_file > dump (it returns I/O error depending on the file). Let me check this issue. Thanks, > >> >> Thanks, >> >>> > return 0; > } > > @@ -330,7 +330,7 @@ static int zstd_compress_pages(struct compress_ctx > *cc) > ZSTD_inBuffer inbuf; > ZSTD_outBuffer outbuf; > int src_size = cc->rlen; > - int dst_size = src_size - PAGE_SIZE - COMPRESS_HEADER_SIZE; > + int dst_size = cc->clen; > int ret; > > inbuf.pos = 0; > >>> >>> >>> ___ >>> Linux-f2fs-devel mailing list >>> linux-f2fs-de...@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >>> . >>> > . >
Re: [PATCH RFC tip/core/rcu] Add shrinker to shift to fast/inefficient GP mode
On Wed, May 06, 2020 at 05:55:35PM -0700, Andrew Morton wrote:
> On Wed, 6 May 2020 17:42:40 -0700 "Paul E. McKenney"
> wrote:
>
> > This commit adds a shrinker so as to inform RCU when memory is scarce.
> > RCU responds by shifting into the same fast and inefficient mode that is
> > used in the presence of excessive numbers of RCU callbacks. RCU remains
> > in this state for one-tenth of a second, though this time window can be
> > extended by another call to the shrinker.
> >
> > If it proves feasible, a later commit might add a function call directly
> > indicating the end of the period of scarce memory.
>
> (Cc David Chinner, who often has opinions on shrinkers ;))
>
> It's a bit abusive of the intent of the slab shrinkers, but I don't
> immediately see a problem with it. Always returning 0 from
> ->scan_objects might cause a problem in some situations(?).
I could just divide the total number of callbacks by 16 or some such,
if that would work better.
> Perhaps we should have a formal "system getting low on memory, please
> do something" notification API.
That would be a very good thing to have! But from what I can see, the
shrinker interface is currently the closest approximation to such an
interface.
> How significant is this? How much memory can RCU consume?
This depends on the configuration and workload. By default, RCU starts
getting concerned if any CPU exceeds 10,000 callbacks. It is not all
-that- hard to cause RCU to have tens of millions of callbacks queued,
though some would argue that workloads doing this are rather abusive.
But at 1K per, this maps to 10GB of storage.
But in more normal workloads, I would expect the amount of storage
awaiting an RCU grace period to not even come close to a gigabyte.
Thoughts?
Thanx, Paul
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -2368,8 +2368,15 @@ static void force_qs_rnp(int (*f)(struct rcu_data
> > *rdp))
> > struct rcu_data *rdp;
> > struct rcu_node *rnp;
> >
> > - rcu_state.cbovld = rcu_state.cbovldnext;
> > + // Load .oomovld before .oomovldend, pairing with .oomovld set.
> > + rcu_state.cbovld = smp_load_acquire(_state.oomovld) || // ^^^
> > + rcu_state.cbovldnext;
> > rcu_state.cbovldnext = false;
> > + if (READ_ONCE(rcu_state.oomovld) &&
> > + time_after(jiffies, READ_ONCE(rcu_state.oomovldend))) {
> > + WRITE_ONCE(rcu_state.oomovld, false);
> > + pr_info("%s: Ending OOM-mode grace periods.\n", __func__);
> > + }
> > rcu_for_each_leaf_node(rnp) {
> > cond_resched_tasks_rcu_qs();
> > mask = 0;
> > @@ -2697,6 +2704,35 @@ static void check_cb_ovld(struct rcu_data *rdp)
> > raw_spin_unlock_rcu_node(rnp);
> > }
> >
> > +/* Return a rough count of the RCU callbacks outstanding. */
> > +static unsigned long rcu_oom_count(struct shrinker *unused1,
> > + struct shrink_control *unused2)
> > +{
> > + int cpu;
> > + unsigned long ncbs = 0;
> > +
> > + for_each_possible_cpu(cpu)
> > + ncbs += rcu_get_n_cbs_cpu(cpu);
> > + return ncbs;
> > +}
> > +
> > +/* Start up an interval of fast high-overhead grace periods. */
> > +static unsigned long rcu_oom_scan(struct shrinker *unused1,
> > + struct shrink_control *unused2)
> > +{
> > + pr_info("%s: Starting OOM-mode grace periods.\n", __func__);
> > + WRITE_ONCE(rcu_state.oomovldend, jiffies + HZ / 10);
> > + smp_store_release(_state.oomovld, true); // After .oomovldend
> > + rcu_force_quiescent_state(); // Kick grace period
> > + return 0; // We haven't actually reclaimed anything yet.
> > +}
> > +
> > +static struct shrinker rcu_shrinker = {
> > + .count_objects = rcu_oom_count,
> > + .scan_objects = rcu_oom_scan,
> > + .seeks = DEFAULT_SEEKS,
> > +};
> > +
> > /* Helper function for call_rcu() and friends. */
> > static void
> > __call_rcu(struct rcu_head *head, rcu_callback_t func)
> > @@ -4146,6 +4182,7 @@ void __init rcu_init(void)
> > qovld_calc = DEFAULT_RCU_QOVLD_MULT * qhimark;
> > else
> > qovld_calc = qovld;
> > + WARN_ON(register_shrinker(_shrinker));
> > }
> >
> > #include "tree_stall.h"
> > diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> > index 2d7fcb9..c4d8e96 100644
> > --- a/kernel/rcu/tree.h
> > +++ b/kernel/rcu/tree.h
> > @@ -326,6 +326,8 @@ struct rcu_state {
> > int ncpus_snap; /* # CPUs seen last time. */
> > u8 cbovld; /* Callback overload now? */
> > u8 cbovldnext; /* ^^ next time? */
> > + u8 oomovld; /* OOM overload? */
> > + unsigned long oomovldend; /* OOM ovld end, jiffies. */
> >
> > unsigned long jiffies_force_qs; /* Time at which to invoke */
> > /*
[PATCH -next] drm/i2c/tda998x: Make tda998x_audio_digital_mute static
Fix the following sparse warning:
drivers/gpu/drm/i2c/tda998x_drv.c:1136:5: warning:
symbol 'tda998x_audio_digital_mute' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: Samuel Zou
---
drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 3c90d7a..9517f52 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1133,7 +1133,8 @@ static void tda998x_audio_shutdown(struct device *dev,
void *data)
mutex_unlock(>audio_mutex);
}
-int tda998x_audio_digital_mute(struct device *dev, void *data, bool enable)
+static int tda998x_audio_digital_mute(struct device *dev, void *data,
+ bool enable)
{
struct tda998x_priv *priv = dev_get_drvdata(dev);
--
2.6.2
linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/display/intel_fbc.c
between commit:
82152d424b6c ("Make the "Reducing compressed framebufer size" message be
DRM_INFO_ONCE()")
from the drm-intel-fixes tree and commit:
97ed48b5c8b1 ("drm/i915/fbc: convert to drm_device based logging macros.")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/display/intel_fbc.c
index c125ca9ab9b3,56bcd6c52a02..
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@@ -485,7 -485,9 +485,8 @@@ static int intel_fbc_alloc_cfb(struct d
if (!ret)
goto err_llb;
else if (ret > 1) {
- DRM_INFO_ONCE("Reducing the compressed framebuffer size. This
may lead to less power savings than a non-reduced-size. Try to increase stolen
memory size if available in BIOS.\n");
- drm_info(_priv->drm,
++ drm_info_once(_priv->drm,
+"Reducing the compressed framebuffer size. This may
lead to less power savings than a non-reduced-size. Try to increase stolen
memory size if available in BIOS.\n");
-
}
fbc->threshold = ret;
pgplKErgsEiTK.pgp
Description: OpenPGP digital signature
Re: [PATCH] hwspinlock: Simplify Kconfig
Hello, On Wed, 15 Apr 2020 at 10:33, Baolin Wang wrote: > > Hi Ezequiel, > > On Wed, Apr 15, 2020 at 6:09 AM Ezequiel Garcia > wrote: > > > > Every hwspinlock driver is expected to depend on the > > hwspinlock core, so it's possible to simplify the > > Kconfig, factoring out the HWSPINLOCK dependency. > > > > Signed-off-by: Ezequiel Garcia > > Looks reasonable to me. > Reviewed-by: Baolin Wang > Gentle ping. Thanks! Ezequiel > > --- > > drivers/hwspinlock/Kconfig | 10 -- > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig > > index 826a1054100d..32cd26352f38 100644 > > --- a/drivers/hwspinlock/Kconfig > > +++ b/drivers/hwspinlock/Kconfig > > @@ -6,9 +6,10 @@ > > menuconfig HWSPINLOCK > > bool "Hardware Spinlock drivers" > > > > +if HWSPINLOCK > > + > > config HWSPINLOCK_OMAP > > tristate "OMAP Hardware Spinlock device" > > - depends on HWSPINLOCK > > depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || > > SOC_AM43XX || ARCH_K3 || COMPILE_TEST > > help > > Say y here to support the OMAP Hardware Spinlock device (firstly > > @@ -18,7 +19,6 @@ config HWSPINLOCK_OMAP > > > > config HWSPINLOCK_QCOM > > tristate "Qualcomm Hardware Spinlock device" > > - depends on HWSPINLOCK > > depends on ARCH_QCOM || COMPILE_TEST > > select MFD_SYSCON > > help > > @@ -30,7 +30,6 @@ config HWSPINLOCK_QCOM > > > > config HWSPINLOCK_SIRF > > tristate "SIRF Hardware Spinlock device" > > - depends on HWSPINLOCK > > depends on ARCH_SIRF || COMPILE_TEST > > help > > Say y here to support the SIRF Hardware Spinlock device, which > > @@ -43,7 +42,6 @@ config HWSPINLOCK_SIRF > > config HWSPINLOCK_SPRD > > tristate "SPRD Hardware Spinlock device" > > depends on ARCH_SPRD || COMPILE_TEST > > - depends on HWSPINLOCK > > help > > Say y here to support the SPRD Hardware Spinlock device. > > > > @@ -52,7 +50,6 @@ config HWSPINLOCK_SPRD > > config HWSPINLOCK_STM32 > > tristate "STM32 Hardware Spinlock device" > > depends on MACH_STM32MP157 || COMPILE_TEST > > - depends on HWSPINLOCK > > help > > Say y here to support the STM32 Hardware Spinlock device. > > > > @@ -60,7 +57,6 @@ config HWSPINLOCK_STM32 > > > > config HSEM_U8500 > > tristate "STE Hardware Semaphore functionality" > > - depends on HWSPINLOCK > > depends on ARCH_U8500 || COMPILE_TEST > > help > > Say y here to support the STE Hardware Semaphore functionality, > > which > > @@ -68,3 +64,5 @@ config HSEM_U8500 > > SoC. > > > > If unsure, say N. > > + > > +endif # HWSPINLOCK > > -- > > 2.26.0.rc2 > > > > > -- > Baolin Wang
[PATCH v3] net: bpf: permit redirect from ingress L3 to egress L2 devices at near max mtu
From: Maciej Żenczykowski
__bpf_skb_max_len(skb) is used from:
bpf_skb_adjust_room
__bpf_skb_change_tail
__bpf_skb_change_head
but in the case of forwarding we're likely calling these functions
during receive processing on ingress and bpf_redirect()'ing at
a later point in time to egress on another interface, thus these
mtu checks are for the wrong device (input instead of output).
This is particularly problematic if we're receiving on an L3 1500 mtu
cellular interface, trying to add an L2 header and forwarding to
an L3 mtu 1500 mtu wifi/ethernet device (which is thus L2 1514).
The mtu check prevents us from adding the 14 byte ethernet header prior
to forwarding the packet.
After the packet has already been redirected, we'd need to add
an additional 2nd ebpf program on the target device's egress tc hook,
but then we'd also see non-redirected traffic and have no easy
way to tell apart normal egress with ethernet header packets
from forwarded ethernet headerless packets.
Cc: Alexei Starovoitov
Cc: Jakub Kicinski
Signed-off-by: Maciej Żenczykowski
---
net/core/filter.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 7d6ceaa54d21..5c8243930462 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -3159,8 +3159,9 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32
off, u32 len_diff,
static u32 __bpf_skb_max_len(const struct sk_buff *skb)
{
- return skb->dev ? skb->dev->mtu + skb->dev->hard_header_len :
- SKB_MAX_ALLOC;
+ if (skb_at_tc_ingress(skb) || !skb->dev)
+ return SKB_MAX_ALLOC;
+ return skb->dev->mtu + skb->dev->hard_header_len;
}
BPF_CALL_4(bpf_skb_adjust_room, struct sk_buff *, skb, s32, len_diff,
--
2.26.2.526.g744177e7f7-goog
[PATCH v2] KVM: SVM: Disable AVIC before setting V_IRQ
The commit 64b5bd270426 ("KVM: nSVM: ignore L1 interrupt window
while running L2 with V_INTR_MASKING=1") introduced a WARN_ON,
which checks if AVIC is enabled when trying to set V_IRQ
in the VMCB for enabling irq window.
The following warning is triggered because the requesting vcpu
(to deactivate AVIC) does not get to process APICv update request
for itself until the next #vmexit.
WARNING: CPU: 0 PID: 118232 at arch/x86/kvm/svm/svm.c:1372
enable_irq_window+0x6a/0xa0 [kvm_amd]
RIP: 0010:enable_irq_window+0x6a/0xa0 [kvm_amd]
Call Trace:
kvm_arch_vcpu_ioctl_run+0x6e3/0x1b50 [kvm]
? kvm_vm_ioctl_irq_line+0x27/0x40 [kvm]
? _copy_to_user+0x26/0x30
? kvm_vm_ioctl+0xb3e/0xd90 [kvm]
? set_next_entity+0x78/0xc0
kvm_vcpu_ioctl+0x236/0x610 [kvm]
ksys_ioctl+0x8a/0xc0
__x64_sys_ioctl+0x1a/0x20
do_syscall_64+0x58/0x210
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes by sending APICV update request to all other vcpus, and
immediately update APIC for itself.
Signed-off-by: Suravee Suthikulpanit
Link: https://lkml.org/lkml/2020/5/2/167
Fixes: 64b5bd270426 ("KVM: nSVM: ignore L1 interrupt window while running L2
with V_INTR_MASKING=1")
---
arch/x86/kvm/x86.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index df473f9..69a01ea 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8085,6 +8085,7 @@ void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu)
*/
void kvm_request_apicv_update(struct kvm *kvm, bool activate, ulong bit)
{
+ struct kvm_vcpu *except;
unsigned long old, new, expected;
if (!kvm_x86_ops.check_apicv_inhibit_reasons ||
@@ -8110,7 +8111,17 @@ void kvm_request_apicv_update(struct kvm *kvm, bool
activate, ulong bit)
trace_kvm_apicv_update_request(activate, bit);
if (kvm_x86_ops.pre_update_apicv_exec_ctrl)
kvm_x86_ops.pre_update_apicv_exec_ctrl(kvm, activate);
- kvm_make_all_cpus_request(kvm, KVM_REQ_APICV_UPDATE);
+
+ /*
+* Sending request to update APICV for all other vcpus,
+* while update the calling vcpu immediately instead of
+* waiting for another #VMEXIT to handle the request.
+*/
+ except = kvm_get_running_vcpu();
+ kvm_make_all_cpus_request_except(kvm, KVM_REQ_APICV_UPDATE,
+except);
+ if (except)
+ kvm_vcpu_update_apicv(except);
}
EXPORT_SYMBOL_GPL(kvm_request_apicv_update);
--
1.8.3.1
Re: linux-next: build failure after merge of the vfs tree
On Thu, May 07, 2020 at 10:39:21AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the vfs tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> fs/eventfd.c: In function 'eventfd_read':
> fs/eventfd.c:226:6: error: implicit declaration of function 'iov_iter_count'
> [-Werror=implicit-function-declaration]
> 226 | if (iov_iter_count(to) < sizeof(ucnt))
> | ^~
> In file included from include/linux/file.h:9,
> from fs/eventfd.c:9:
> fs/eventfd.c:257:15: error: implicit declaration of function 'copy_to_iter';
> did you mean 'copy_to_user'? [-Werror=implicit-function-declaration]
> 257 | if (unlikely(copy_to_iter(, sizeof(ucnt), to) != sizeof(ucnt)))
> | ^~~~
>
> Caused by commit
>
> a6515b3a7410 ("eventfd: convert to f_op->read_iter()")
>
> I have applied the following patch for today:
[snip]
folded and pushed out
[PATCH -next] drm/ast: Make ast_primary_plane_helper_atomic_update static
Fix the following sparse warning:
drivers/gpu/drm/ast/ast_mode.c:564:6: warning:
symbol 'ast_primary_plane_helper_atomic_update'
was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: Samuel Zou
---
drivers/gpu/drm/ast/ast_mode.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 7062bcd..4ddf770 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -561,8 +561,9 @@ static int ast_primary_plane_helper_atomic_check(struct
drm_plane *plane,
return 0;
}
-void ast_primary_plane_helper_atomic_update(struct drm_plane *plane,
- struct drm_plane_state *old_state)
+static void
+ast_primary_plane_helper_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
{
struct ast_private *ast = plane->dev->dev_private;
struct drm_plane_state *state = plane->state;
--
2.6.2
Re: [PATCH v2] net: bpf: permit redirect from L3 to L2 devices at near max mtu
> > I thought we have established that checking device MTU (m*T*u) > > at ingress makes a very limited amount of sense, no? > > > > Shooting from the hip here, but won't something like: > > > > if (!skb->dev || skb->tc_at_ingress) > > return SKB_MAX_ALLOC; > > return skb->dev->mtu + skb->dev->hard_header_len; > > > > Solve your problem? > > I believe that probably does indeed solve the ingress case of tc > ingress hook on cellular redirecting to wifi. > > However, there's 2 possible uplinks - cellular (rawip, L3), and wifi > (ethernet, L2). > Thus, there's actually 4 things I'm trying to support: > > - ipv6 ingress on cellular uplink (L3/rawip), translate to ipv4, > forward to wifi/ethernet <- need to add ethernet header > > - ipv6 ingress on wifi uplink (L2/ether), translate to ipv4, forward > to wifi/ethernet <- trivial, no packet size change > > - ipv4 egressing through tun (L3), translate to ipv6, forward to > cellular uplink <- trivial, no packet size change > > - ipv4 egressing through tun (L3), translate to ipv6, forward to wifi > uplink <- need to add ethernet header [*] > > I think your approach doesn't solve the reverse path (* up above): > > ie. ipv4 packets hitting a tun device (owned by a clat daemon doing > ipv4<->ipv6 translation in userspace), being stolen by a tc egress > ebpf hook, mutated to ipv6 by ebpf and bpf_redirect'ed to egress > through a wifi ipv6-only uplink. > > Though arguably in this case I could probably simply increase the tun > device mtu by another 14, while keeping ipv4 route mtus low... > (tun mtu already has to be 28 bytes lower then wifi mtu to allow > replacement of ipv4 with ipv6 header (20 bytes extra), with possibly > an ipv6 frag header (8 more bytes)) > > Any further thoughts? Thinking about this some more, that seems to solve the immediate need (case 1 above), and I can work around case 4 with tun mtu bumps. And maybe the real correct fix would be to simply pass in the desired path mtu to these 3 functions via 16-bits of the flags argument.
[PATCH -next] soc: fsl_asrc: Make some functions static
Fix the following warning:
sound/soc/fsl/fsl_asrc.c:157:5: warning:
symbol 'fsl_asrc_request_pair' was not declared. Should it be static?
sound/soc/fsl/fsl_asrc.c:200:6: warning:
symbol 'fsl_asrc_release_pair' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: ChenTao
---
sound/soc/fsl/fsl_asrc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 067a54ab554f..432936039de4 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -154,7 +154,7 @@ static void fsl_asrc_sel_proc(int inrate, int outrate,
* within range [ANCA, ANCA+ANCB-1], depends on the channels of pair A
* while pair A and pair C are comparatively independent.
*/
-int fsl_asrc_request_pair(int channels, struct fsl_asrc_pair *pair)
+static int fsl_asrc_request_pair(int channels, struct fsl_asrc_pair *pair)
{
enum asrc_pair_index index = ASRC_INVALID_PAIR;
struct fsl_asrc *asrc = pair->asrc;
@@ -197,7 +197,7 @@ int fsl_asrc_request_pair(int channels, struct
fsl_asrc_pair *pair)
*
* It clears the resource from asrc and releases the occupied channels.
*/
-void fsl_asrc_release_pair(struct fsl_asrc_pair *pair)
+static void fsl_asrc_release_pair(struct fsl_asrc_pair *pair)
{
struct fsl_asrc *asrc = pair->asrc;
enum asrc_pair_index index = pair->index;
--
2.22.0
RE: [EXT] Re: [v4,iproute2-next 1/2] iproute2-next:tc:action: add a gate control action
Hi Davide,
> -Original Message-
> From: Davide Caratti
> Sent: 2020年5月6日 20:54
> To: Po Liu ; dsah...@gmail.com; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Cc: vinicius.go...@intel.com; step...@networkplumber.org;
> da...@davemloft.net; v...@buslov.dev; Claudiu Manoil
> ; Vladimir Oltean ;
> Alexandru Marginean
> Subject: [EXT] Re: [v4,iproute2-next 1/2] iproute2-next:tc:action: add a
> gate control action
>
> Caution: EXT Email
>
> On Wed, 2020-05-06 at 16:40 +0800, Po Liu wrote:
> > Introduce a ingress frame gate control flow action.
> [...]
>
> hello Po Liu,
>
> [...]
>
> > +create_entry:
> > + e = create_gate_entry(gate_state, interval,
> > + ipv, maxoctets);
> > + if (!e) {
> > + fprintf(stderr, "gate: not enough memory\n");
> > + free_entries(_entries);
> > + return -1;
> > + }
> > +
> > + list_add_tail(>list, _entries);
> > + entry_num++;
> > +
> > + } else if (matches(*argv, "reclassify") == 0 ||
> > +matches(*argv, "drop") == 0 ||
> > +matches(*argv, "shot") == 0 ||
> > +matches(*argv, "continue") == 0 ||
> > +matches(*argv, "pass") == 0 ||
> > +matches(*argv, "ok") == 0 ||
> > +matches(*argv, "pipe") == 0 ||
> > +matches(*argv, "goto") == 0) {
> > + if (parse_action_control(, ,
> > + , false)) {
> > + free_entries(_entries);
> > + return -1;
> > + }
> > + } else if (matches(*argv, "help") == 0) {
> > + usage();
> > + } else {
> > + break;
> > + }
> > +
> > + argc--;
> > + argv++;
> > + }
> > +
> > + parse_action_control_dflt(, , ,
> > + false, TC_ACT_PIPE);
>
> it seems that the control action is parsed twice, and the first time it does
> not allow "jump" and "trap". Is that intentional? IOW, are there some
> "act_gate" configurations that don't allow jump or trap?
It is allowed to jump and trap. I didn't notice it was loaded twice. I would
correct here and remove one parse_action_control()
Thanks a lot!
>
> I don't see anything similar in kernel act_gate.c, where tcf_gate_act() can
> return TC_ACT_SHOT or whatever is written in parm.action. That's why I'm
> asking, if these two control actions are forbidden you should let the kernel
> return -EINVAL with a proper extack in tcf_gate_init(). Can you please
> clarify?
>
> thank you in advance!
> --
> davide
>
Br,
Po Liu
Re: [RESEND PATCH] KVM: x86/pmu: Support full width counting
Hi Paolo, Thanks for your comments! On 2020/5/5 0:57, Paolo Bonzini wrote: On 27/04/20 09:19, Like Xu wrote: + if (vmx_supported_perf_capabilities()) + kvm_cpu_cap_check_and_set(X86_FEATURE_PDCM); I think we can always set it, worst case it will be zero. Sure, we could set it for x86. However, blocking intel_pmu_set_msr altogether is incorrect. Instead, you need to: - list the MSR in msr_based_features_all so that it appears in KVM_GET_MSR_FEATURE_INDEX_LIST - return the supported bits in vmx_get_msr_feature - allow host-initiated writes (as long as they only set supported bits) of the MSR in intel_pmu_set_msr. Please review the v2 patch for this feature, https://lore.kernel.org/kvm/20200507021452.174646-1-like...@linux.intel.com/ Thanks, Like Xu Thanks, Paolo
RE: [PATCH] ASoC: Intel: sst: ipc command timeout
> > Looks there is race between the previous stream stop and the current > stream start here. Can you help try changing the > sst_byt_stream_start/stop() from 'nowait' mode to 'wait' mode, and see if > the issue can be reproduced with it? Hi Keyon, Kernel panic if the mode is changed. The defect could happen to the first ALLOC_STREAM command after bootstrap so I think the START/DROP_STRAM may not work. Regards, Brent > > > Thanks, > ~Keyon >
