[PATCH v2 5/5] arm: kexec_file: load zImage or uImage, initrd and dtb
This is kexec_file_load implementation for ARM. It loads zImage and
initrd from file descripters and resuses DTB.
Most code is derived from arm64 kexec_file_load implementation
and from kexec-tools.
Cc: AKASHI Takahiro
Signed-off-by: Łukasz Stelmach
---
arch/arm/Kconfig | 25
arch/arm/include/asm/image.h | 26
arch/arm/include/asm/kexec.h | 14 ++
arch/arm/kernel/Makefile | 5 +-
arch/arm/kernel/kexec_uimage.c | 80 ++
arch/arm/kernel/kexec_zimage.c | 194
arch/arm/kernel/machine_kexec.c | 11 +-
arch/arm/kernel/machine_kexec_file.c | 211 +++
8 files changed, 561 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/kernel/kexec_uimage.c
create mode 100644 arch/arm/kernel/kexec_zimage.c
create mode 100644 arch/arm/kernel/machine_kexec_file.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c77c93c485a0..c592c58e78f1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1917,6 +1917,31 @@ config KEXEC
is properly shutdown, so do not be surprised if this code does not
initially work for you.
+config KEXEC_FILE
+ bool "Kexec file based system call (EXPERIMENTAL)"
+ depends on (!SMP || PM_SLEEP_SMP)
+ depends on USE_OF
+ select KEXEC_CORE
+ select CRC32
+ help
+ This is new version of kexec system call. This system call is
+ file based and takes file descriptors as system call argument
+ for kernel and initramfs as opposed to list of segments as
+ accepted by previous system call.
+
+ The kernel to be loaded MUST support Flattened Device Tree
+ (selected with CONFIG_USE_OF).
+
+config KEXEC_FILE_UIMAGE
+ bool "Load legacy uImage files with kexec_file_load() (EXPERIMENTAL)"
+ depends on KEXEC_FILE
+ default n
+ help
+ This options enables support for the legacy uImage files as
+ created by mkimage. These are not the new FIT files.
+
+ If unsure say N.
+
config ATAGS_PROC
bool "Export atags in procfs"
depends on ATAGS && KEXEC
diff --git a/arch/arm/include/asm/image.h b/arch/arm/include/asm/image.h
index 55b51faa6b7e..596b32952958 100644
--- a/arch/arm/include/asm/image.h
+++ b/arch/arm/include/asm/image.h
@@ -8,8 +8,13 @@
(((x) >> 8) & 0xff00) | \
(((x) << 8) & 0x00ff) | \
(((x) << 24) & 0xff00))
+#define UIMAGE_MAGIC(x) (x)
#else
#define ZIMAGE_MAGIC(x) (x)
+#define UIMAGE_MAGIC(x) x) >> 24) & 0x00ff) | \
+(((x) >> 8) & 0xff00) | \
+(((x) << 8) & 0x00ff) | \
+(((x) << 24) & 0xff00))
#endif
#define ARM_ZIMAGE_MAGIC1 ZIMAGE_MAGIC(0x016f2818)
@@ -17,6 +22,12 @@
#define ARM_ZIMAGE_MAGIC3 ZIMAGE_MAGIC(0x5a534c4b)
#define ARM_ZIMAGE_MAGIC4 ZIMAGE_MAGIC(0x5a534344)
+#define ARM_UIMAGE_MAGIC UIMAGE_MAGIC(0x27051956)
+#define ARM_UIMAGE_NAME_LEN32
+#define ARM_UIMAGE_TYPE_KERNEL 2
+#define ARM_UIMAGE_TYPE_KERNEL_NOLOAD 14
+#define ARM_UIMAGE_ARCH_ARM2
+
#ifndef __ASSEMBLY__
#include
@@ -33,6 +44,21 @@ struct arm_zimage_header {
__le32 extension_tag_offset;
};
+struct arm_uimage_header {
+ __be32 magic;
+ __be32 hdr_crc;
+ __be32 time;
+ __be32 size;
+ __be32 load;
+ __be32 entry;
+ __be32 crc;
+ __u8 os;
+ __u8 arch;
+ __u8 type;
+ __u8 comp;
+ __u8 name[ARM_UIMAGE_NAME_LEN];
+};
+
struct arm_zimage_tag {
struct tag_header hdr;
union {
diff --git a/arch/arm/include/asm/kexec.h b/arch/arm/include/asm/kexec.h
index 22751b5b5735..fda35afa7195 100644
--- a/arch/arm/include/asm/kexec.h
+++ b/arch/arm/include/asm/kexec.h
@@ -83,6 +83,20 @@ static inline struct page *boot_pfn_to_page(unsigned long
boot_pfn)
}
#define boot_pfn_to_page boot_pfn_to_page
+#ifdef CONFIG_KEXEC_FILE
+
+extern const struct kexec_file_ops kexec_zimage_ops;
+extern const struct kexec_file_ops kexec_uimage_ops;
+
+struct kimage;
+
+extern int load_other_segments(struct kimage *image,
+ unsigned long kernel_load_addr, unsigned long kernel_size,
+ char *initrd, unsigned long initrd_len,
+ unsigned long initrd_offset, char *cmdline);
+
+#endif /* CONFIG_KEXEC_FILE */
+
#endif /* __ASSEMBLY__ */
#endif /* CONFIG_KEXEC */
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 89e5d864e923..453ecf7305e2 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -3,6 +3,7 @@
# Makefile for the linux kernel.
#
+CFLAGS_kexec_zimage.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
CPPFLAGS_vmlinux.lds := -DTEXT_OFFSET=$(TEXT_OFFSET)
AFLAGS_head.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
@@ -56,7 +57,9 @@
[PATCH v2 1/5] arm: decompressor: set malloc pool size for the decompressor
Move the definition of malloc pool size of the decompressor to a single place. This value will be exposed later for kexec_file loader. Signed-off-by: Łukasz Stelmach --- arch/arm/boot/compressed/Makefile | 7 +-- arch/arm/boot/compressed/head.S | 6 -- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile index 9c11e7490292..c4195651e371 100644 --- a/arch/arm/boot/compressed/Makefile +++ b/arch/arm/boot/compressed/Makefile @@ -7,7 +7,9 @@ OBJS = -AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET) +MALLOC_SIZE =0x1 + +AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET) -DMALLOC_SIZE=$(MALLOC_SIZE) HEAD = head.o OBJS += misc.o decompress.o ifeq ($(CONFIG_DEBUG_UNCOMPRESS),y) @@ -68,7 +70,8 @@ ZTEXTADDR := 0 ZBSSADDR := ALIGN(8) endif -CPPFLAGS_vmlinux.lds := -DTEXT_START="$(ZTEXTADDR)" -DBSS_START="$(ZBSSADDR)" +CPPFLAGS_vmlinux.lds := -DTEXT_START="$(ZTEXTADDR)" -DBSS_START="$(ZBSSADDR)" \ + -DMALLOC_SIZE="$(MALLOC_SIZE)" compress-$(CONFIG_KERNEL_GZIP) = gzip compress-$(CONFIG_KERNEL_LZO) = lzo diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index e8e1c866e413..55758264e776 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -309,7 +309,8 @@ restart:adr r0, LC0 #ifndef CONFIG_ZBOOT_ROM /* malloc space is above the relocated stack (64k max) */ add sp, sp, r0 - add r10, sp, #0x1 + mov r10, #MALLOC_SIZE + add r10, r10, sp #else /* * With ZBOOT_ROM the bss/stack is non relocatable, @@ -623,7 +624,8 @@ not_relocated: mov r0, #0 */ mov r0, r4 mov r1, sp @ malloc space above stack - add r2, sp, #0x1@ 64k max + mov r2, #MALLOC_SIZE@ 64k max + add r2, r2, sp mov r3, r7 bl decompress_kernel -- 2.26.2
Re: [PATCH 4/4] workqueue: slash half memory usage in 32bit system
Hello, On Tue, Jun 02, 2020 at 08:08:10AM +0800, Lai Jiangshan wrote: > It is not noticable from the "free" command. > By counting the number of allocated pwq (mainly percpu pwq), > it saves 20k in my simple kvm guest (4cpu). > I guess it highly various in different boxes with various > kernel modules loaded. Hmm... I find it difficult to judge in any direction. 32 bit machines are smaller and have less of everything - including CPUs and workqueues themselves, so while changing configuration for 32bit systems would reduce memory usage the impact isn't gonna be that big either and I have no data supporting whether the reduction is gonna help or hurt. Thanks. -- tejun
Re: [PATCH] cxl: Fix kobject memleak
Le 02/06/2020 à 14:07, Wang Hai a écrit :
Currently the error return path from kobject_init_and_add() is not
followed by a call to kobject_put() - which means we are leaking
the kobject.
Fix it by adding a call to kobject_put() in the error path of
kobject_init_and_add().
Fixes: b087e6190ddc ("cxl: Export optional AFU configuration record in sysfs")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
Indeed, a call to kobject_put() is needed when the init fails.
Thanks!
Acked-by: Frederic Barrat
---
drivers/misc/cxl/sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c
index f0263d1..d97a243 100644
--- a/drivers/misc/cxl/sysfs.c
+++ b/drivers/misc/cxl/sysfs.c
@@ -624,7 +624,7 @@ static struct afu_config_record
*cxl_sysfs_afu_new_cr(struct cxl_afu *afu, int c
rc = kobject_init_and_add(>kobj, _config_record_type,
>dev.kobj, "cr%i", cr->cr);
if (rc)
- goto err;
+ goto err1;
rc = sysfs_create_bin_file(>kobj, >config_attr);
if (rc)
[GIT PULL] kgdb changes for v5.8-rc1
The following changes since commit 6a8b55ed4056ea5559ebe4f6a4b247f627870d4c: Linux 5.7-rc3 (2020-04-26 13:51:02 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux.git/ tags/kgdb-5.8-rc1 for you to fetch changes up to c893de12e1ef17b581eb2cf8fc9018ec0cbd07df: kdb: Remove the misfeature 'KDBFLAGS' (2020-06-02 15:15:46 +0100) kgdb patches for 5.8-rc1 By far the biggest change in this cycle are the changes that allow much earlier debug of systems that are hooked up via UART by taking advantage of the earlycon framework to implement the kgdb I/O hooks before handing over to the regular polling I/O drivers once they are available. When discussing Doug's work we also found and fixed an broken raw_smp_processor_id() sequence in in_dbg_master(). Also included are a collection of much smaller fixes and tweaks: a couple of tweaks to ged rid of doc gen or coccicheck warnings, future proof some internal calculations that made implicit power-of-2 assumptions and eliminate some rather weird handling of magic environment variables in kdb. Signed-off-by: Daniel Thompson Andy Shevchenko (1): kgdb: Drop malformed kernel doc comment Daniel Thompson (2): kgdb: Fix spurious true from in_dbg_master() serial: kgdboc: Allow earlycon initialization to be deferred Douglas Anderson (13): kgdb: Disable WARN_CONSOLE_UNLOCKED for all kgdb Revert "kgdboc: disable the console lock when in kgdb" kgdboc: Use a platform device to handle tty drivers showing up late kgdb: Delay "kgdbwait" to dbg_late_init() by default kgdb: Prevent infinite recursive entries to the debugger kgdboc: Remove useless #ifdef CONFIG_KGDB_SERIAL_CONSOLE in kgdboc kgdboc: Add kgdboc_earlycon to support early kgdb using boot consoles kgdboc: Disable all the early code when kgdboc is a module kgdb: Don't call the deinit under spinlock Documentation: kgdboc: Document new kgdboc_earlycon parameter serial: qcom_geni_serial: Support kgdboc_earlycon serial: 8250_early: Support kgdboc_earlycon kdb: Cleanup math with KDB_CMD_HISTORY_COUNT Jason Yan (1): kgdb: Return true in kgdb_nmi_poll_knock() Sumit Garg (1): serial: amba-pl011: Support kgdboc_earlycon Wei Li (1): kdb: Remove the misfeature 'KDBFLAGS' Documentation/admin-guide/kernel-parameters.txt | 20 ++ Documentation/dev-tools/kgdb.rst| 24 ++ arch/x86/Kconfig| 1 + drivers/tty/serial/8250/8250_early.c| 23 ++ drivers/tty/serial/amba-pl011.c | 32 +++ drivers/tty/serial/kgdboc.c | 318 +--- drivers/tty/serial/qcom_geni_serial.c | 32 +++ include/linux/kdb.h | 2 +- include/linux/kgdb.h| 8 +- kernel/debug/debug_core.c | 57 +++-- kernel/debug/kdb/kdb_main.c | 11 +- lib/Kconfig.kgdb| 18 ++ 12 files changed, 490 insertions(+), 56 deletions(-)
Re: linux-next: manual merge of the hyperv tree with the kvm tree
On 02/06/20 15:56, Wei Liu wrote:
>>
>> between commit:
>>
>> 22ad0026d097 ("x86/hyper-v: Add synthetic debugger definitions")
>>
> Paolo
>
> As far as I can tell you merged that series a few days ago. Do you plan
> to submit it to Linus in this merge window? How do you want to proceed
> to fix the conflict?
Hi, Linus can fix this conflict.
Paolo
Re: [PATCH 5.6 000/174] 5.6.16-rc2 review
On Tue, 2 Jun 2020 at 15:55, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.6.16 release. > There are 174 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 04 Jun 2020 10:16:52 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.16-rc2.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.6.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.6.16-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.6.y git commit: 4ceaad0d95e7a56ea839541b0e825af93e4817d9 git describe: v5.6.15-175-g4ceaad0d95e7 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.6-oe/build/v5.6.15-175-g4ceaad0d95e7 No regressions (compared to build v5.6.15) No fixes (compared to build v5.6.15) Ran 32298 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * libgpiod * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fs-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * kvm-unit-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * network-basic-tests * v4l2-compliance * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * kselftest/networking * ltp-ipc-tests * ltp-open-posix-tests -- Linaro LKFT https://lkft.linaro.org
[GIT PULL] xfs: new code for 5.8 (now with fixed To line)
Sorry Linus, I totally FUBARed the addressing on the pull request. Resending directly to you so that it doesn't get lost in the spam folder. --D --- Hi Linus, Please pull the new XFS code for 5.8. Most of the changes this cycle are refactoring of existing code in preparation for things landing in the future. We also fixed various problems and deficiencies in the quota implementation, and (I hope) the last of the stale read vectors by forcing write allocations to go through the unwritten state until the write completes. This branch merges cleanly with master as of a few minutes ago, so please let me know if anything strange happens. I anticipate a second pull request next week for a DAX-related restructuring that requires the DAX branch (sent separately). --D The following changes since commit 0e698dfa282211e414076f9dc7e83c1c288314fd: Linux 5.7-rc4 (2020-05-03 14:56:04 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/xfs-5.8-merge-8 for you to fetch changes up to 6dcde60efd946e38fac8d276a6ca47492103e856: xfs: more lockdep whackamole with kmem_alloc* (2020-05-27 08:49:28 -0700) New code for 5.8: - Various cleanups to remove dead code, unnecessary conditionals, asserts, etc. - Fix a linker warning caused by xfs stuffing '-g' into CFLAGS redundantly. - Tighten up our dmesg logging to ensure that everything is prefixed with 'XFS' for easier grepping. - Kill a bunch of typedefs. - Refactor the deferred ops code to reduce indirect function calls. - Increase type-safety with the deferred ops code. - Make the DAX mount options a tri-state. - Fix some error handling problems in the inode flush code and clean up other inode flush warts. - Refactor log recovery so that each log item recovery functions now live with the other log item processing code. - Fix some SPDX forms. - Fix quota counter corruption if the fs crashes after running quotacheck but before any dquots get logged. - Don't fail metadata verification on zero-entry attr leaf blocks, since they're just part of the disk format now due to a historic lack of log atomicity. - Don't allow SWAPEXT between files with different [ugp]id when quotas are enabled. - Refactor inode fork reading and verification to run directly from the inode-from-disk function. This means that we now actually guarantee that _iget'ted inodes are totally verified and ready to go. - Move the incore inode fork format and extent counts to the ifork structure. - Scalability improvements by reducing cacheline pingponging in struct xfs_mount. - More scalability improvements by removing m_active_trans from the hot path. - Fix inode counter update sanity checking to run /only/ on debug kernels. - Fix longstanding inconsistency in what error code we return when a program hits project quota limits (ENOSPC). - Fix group quota returning the wrong error code when a program hits group quota limits. - Fix per-type quota limits and grace periods for group and project quotas so that they actually work. - Allow extension of individual grace periods. - Refactor the non-reclaim inode radix tree walking code to remove a bunch of stupid little functions and straighten out the inconsistent naming schemes. - Fix a bug in speculative preallocation where we measured a new allocation based on the last extent mapping in the file instead of looking farther for the last contiguous space allocation. - Force delalloc writes to unwritten extents. This closes a stale disk contents exposure vector if the system goes down before the write completes. - More lockdep whackamole. Arnd Bergmann (1): xfs: stop CONFIG_XFS_DEBUG from changing compiler flags Brian Foster (19): xfs: refactor failed buffer resubmission into xfsaild xfs: factor out buffer I/O failure code xfs: simplify inode flush error handling xfs: remove unnecessary shutdown check from xfs_iflush() xfs: reset buffer write failure state on successful completion xfs: refactor ratelimited buffer error messages into helper xfs: ratelimit unmount time per-buffer I/O error alert xfs: fix duplicate verification from xfs_qm_dqflush() xfs: abort consistently on dquot flush failure xfs: acquire ->ail_lock from xfs_trans_ail_delete() xfs: use delete helper for items expected to be in AIL xfs: drop unused shutdown parameter from xfs_trans_ail_remove() xfs: combine xfs_trans_ail_[remove|delete]() xfs: remove unused iflush stale parameter xfs: random buffer write failure errortag xfs: remove unused shutdown types xfs: remove
Re: memory leak in exfat_parse_param
On Tue, Jun 02, 2020 at 01:03:05PM +0800, butt3rflyh4ck wrote:
> I report a bug (in linux-5.7.0-rc7) found by syzkaller.
>
> kernel config:
> https://github.com/butterflyhack/syzkaller-fuzz/blob/master/config-v5.7.0-rc7
>
> and can reproduce.
>
> A param->string held by exfat_mount_options.
Humm...
First of all, exfat_free() ought to call exfat_free_upcase_table().
What's more, WTF bother with that kstrdup(), anyway? Just steal the string
and be done with that...
Signed-off-by: Al Viro
---
diff --git a/fs/exfat/super.c b/fs/exfat/super.c
index 0565d5539d57..01cd7ed1614d 100644
--- a/fs/exfat/super.c
+++ b/fs/exfat/super.c
@@ -259,9 +259,8 @@ static int exfat_parse_param(struct fs_context *fc, struct
fs_parameter *param)
break;
case Opt_charset:
exfat_free_iocharset(sbi);
- opts->iocharset = kstrdup(param->string, GFP_KERNEL);
- if (!opts->iocharset)
- return -ENOMEM;
+ opts->iocharset = param->string;
+ param->string = NULL;
break;
case Opt_errors:
opts->errors = result.uint_32;
@@ -611,7 +610,10 @@ static int exfat_get_tree(struct fs_context *fc)
static void exfat_free(struct fs_context *fc)
{
- kfree(fc->s_fs_info);
+ struct exfat_sb_info *sbi = fc->s_fs_info;
+
+ exfat_free_iocharset(sbi);
+ kfree(sbi);
}
static const struct fs_context_operations exfat_context_ops = {
[GIT PULL] keys: Changes for 5.8
Hi Linus, Could you pull these keyrings fixes please? (1) Fix a documentation warning. (2) Replace a [0] array with []. (3) Make the big_key key type use ChaCha20Poly1305 and use the crypto algorithm directly rather than going through the crypto layer. (4) Implement the update op for the big_key type. Thanks, David --- The following changes since commit 6a8b55ed4056ea5559ebe4f6a4b247f627870d4c: Linux 5.7-rc3 (2020-04-26 13:51:02 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/keys-next-20200602 for you to fetch changes up to b6f61c31464940513ef4eccb3a030a405b4256d6: keys: Implement update for the big_key type (2020-06-02 17:22:31 +0100) Keyrings changes Ben Boeckel (1): Documentation: security: core.rst: add missing argument David Howells (1): keys: Implement update for the big_key type Gustavo A. R. Silva (1): KEYS: Replace zero-length array with flexible-array Jason A. Donenfeld (1): security/keys: rewrite big_key crypto to use library interface Documentation/security/keys/core.rst | 8 +- include/keys/big_key-type.h | 1 + include/keys/user-type.h | 2 +- security/keys/Kconfig| 4 +- security/keys/big_key.c | 257 +++ 5 files changed, 60 insertions(+), 212 deletions(-)
Re: linux-next: manual merge of the hyperv tree with the kvm tree
On Tue, Jun 02, 2020 at 06:26:26PM +0200, Paolo Bonzini wrote:
> On 02/06/20 15:56, Wei Liu wrote:
> >>
> >> between commit:
> >>
> >> 22ad0026d097 ("x86/hyper-v: Add synthetic debugger definitions")
> >>
> > Paolo
> >
> > As far as I can tell you merged that series a few days ago. Do you plan
> > to submit it to Linus in this merge window? How do you want to proceed
> > to fix the conflict?
>
> Hi, Linus can fix this conflict.
OK. I will write down in my pull request what needs to be done to fix
the conflicts.
Wei.
>
> Paolo
>
Re: [PATCH net-next v7 09/10] net: phy: smsc: use phy_read_poll_timeout() to simplify the code
On Mon, Jun 01, 2020 at 02:58:21PM -0400, Kevin Groeneveld wrote:
> On Mon, Mar 23, 2020 at 11:10 AM Dejin Zheng wrote:
> >
> > use phy_read_poll_timeout() to replace the poll codes for
> > simplify lan87xx_read_status() function.
> >
> > Suggested-by: Andrew Lunn
> > Reviewed-by: Florian Fainelli
> > Signed-off-by: Dejin Zheng
> > ---
> > v6 -> v7:
> > - adapt to a newly added parameter sleep_before_read.
> > v5 -> v6:
> > - no changed.
> > v4 -> v5:
> > - add msleep before phy_read_poll_timeout() to keep the
> > code more similar
> > v3 -> v4:
> > - add this patch by Andrew's suggestion. Thanks Andrew!
> >
> > drivers/net/phy/smsc.c | 16 +---
> > 1 file changed, 5 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
> > index b73298250793..93da7d3d0954 100644
> > --- a/drivers/net/phy/smsc.c
> > +++ b/drivers/net/phy/smsc.c
> > @@ -112,8 +112,6 @@ static int lan87xx_read_status(struct phy_device
> *phydev)
> > int err = genphy_read_status(phydev);
> >
> > if (!phydev->link && priv->energy_enable) {
> > - int i;
> > -
> > /* Disable EDPD to wake up PHY */
> > int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
> > if (rc < 0)
> > @@ -125,15 +123,11 @@ static int lan87xx_read_status(struct phy_device
> *phydev)
> > return rc;
> >
> > /* Wait max 640 ms to detect energy */
> > - for (i = 0; i < 64; i++) {
> > - /* Sleep to allow link test pulses to be sent */
> > - msleep(10);
> > - rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
> > - if (rc < 0)
> > - return rc;
> > - if (rc & MII_LAN83C185_ENERGYON)
> > - break;
> > - }
> > + phy_read_poll_timeout(phydev, MII_LAN83C185_CTRL_STATUS,
> > + rc & MII_LAN83C185_ENERGYON, 1,
> > + 64, true);
> > + if (rc < 0)
> > + return rc;
> >
> > /* Re-enable EDPD */
> > rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
> > --
> > 2.25.0
> >
>
> This patch causes the kernel log to be spammed with the following when
> Ethernet cable is not connected:
> SMSC LAN8710/LAN8720 2188000.ethernet-1:00: lan87xx_read_status failed: -110
>
Kevin, I am very sorry for the trouble caused by my patch.
> It still seems to work but I think that is only a fluke.
>
> The "if (rc < 0)" is not actually checking the return value of
> phy_read_poll_timeout but is looking at the value of the register read. I
> don't think rc will ever be negative in this case. If you change the code
> to "rc = phy_read_poll_timeout(...)" so that it actually checks the error
> then the function will behave differently than before. The original code
> would only return an error if phy_read returned an error. On a timeout it
> just continued. So the "if" could be changed to "if (rc < 0 && rc !=
> -ETIMEDOUT)". But you will still get the extra messages in the log that
> were not there before.
>
Yes, My patch did change the original behavior. It will not have error message
whether it is timeout or phy_read fails, but my patch changed it and will
print some error messages. It is my mistake. I'm so sorry for that.
How do you think of the following fix?
> > /* Wait max 640 ms to detect energy */
> > - for (i = 0; i < 64; i++) {
> > - /* Sleep to allow link test pulses to be sent */
> > - msleep(10);
> > - rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
> > - if (rc < 0)
> > - return rc;
> > - if (rc & MII_LAN83C185_ENERGYON)
> > - break;
> > - }
> > + phy_read_poll_timeout(phydev, MII_LAN83C185_CTRL_STATUS,
> > + rc & MII_LAN83C185_ENERGYON, 1,
> > + 64, true);
> > + if (rc < 0)
> > + return rc;
ret = read_poll_timeout(phy_read, rc, rc &
MII_LAN83C185_ENERGYON || rc < 0,
1, 64, true, phydev,
MII_LAN83C185_CTRL_STATUS);
if (!ret && rc < 0)
return rc;
BR,
Dejin
>
> Kevin
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote: > So vhost needs to poke at userspace *a lot* in a quick succession. It > is thus benefitial to enable userspace access, do our thing, then > disable. Except access_ok has already been pre-validated with all the > relevant nospec checks, so we don't need that. Add an API to allow > userspace access after access_ok and barrier_nospec are done. This is the wrong way to do it, and this API is certain to be abused elsewhere. NAK - we need to sort out vhost-related problems, but this is not an acceptable solution. Sorry.
Re: [PATCH] nvme-fc: Only call nvme_cleanup_cmd() for normal operations
On 5/29/2020 4:37 AM, Daniel Wagner wrote:
Asynchronous event notifications do not have an request
associated. When fcp_io() fails we unconditionally call
nvme_cleanup_cmd() which leads to a crash.
Fixes: 16686f3a6c3c ("nvme: move common call to nvme_cleanup_cmd to core layer")
Cc: Max Gurtovoy
Signed-off-by: Daniel Wagner
---
drivers/nvme/host/fc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
index 7dfc4a2ecf1e..287a3e8ea317 100644
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -2300,10 +2300,11 @@ nvme_fc_start_fcp_op(struct nvme_fc_ctrl *ctrl, struct
nvme_fc_queue *queue,
opstate = atomic_xchg(>state, FCPOP_STATE_COMPLETE);
__nvme_fc_fcpop_chk_teardowns(ctrl, op, opstate);
- if (!(op->flags & FCOP_FLAGS_AEN))
+ if (!(op->flags & FCOP_FLAGS_AEN)) {
nvme_fc_unmap_data(ctrl, op->rq, op);
+ nvme_cleanup_cmd(op->rq);
+ }
- nvme_cleanup_cmd(op->rq);
nvme_fc_ctrl_put(ctrl);
if (ctrl->rport->remoteport.port_state == FC_OBJSTATE_ONLINE &&
Reviewed-by: James Smart
-- james
Re: [PATCH v5 11/11] PCI: qcom: Add Force GEN1 support
On Tue, Jun 02, 2020 at 01:53:52PM +0200, Ansuel Smith wrote:
> From: Sham Muthayyan
>
> Add Force GEN1 support needed in some ipq8064 board that needs to limit
> some PCIe line to gen1 for some hardware limitation. This is set by the
> max-link-speed binding and needed by some soc based on ipq8064. (for
> example Netgear R7800 router)
>
> Signed-off-by: Sham Muthayyan
> Signed-off-by: Ansuel Smith
> Reviewed-by: Rob Herring
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> b/drivers/pci/controller/dwc/pcie-qcom.c
> index 259b627bf890..0ce15d53c46e 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -27,6 +27,7 @@
> #include
> #include
>
> +#include "../../pci.h"
> #include "pcie-designware.h"
>
> #define PCIE20_PARF_SYS_CTRL 0x00
> @@ -99,6 +100,8 @@
> #define PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE 0x358
> #define SLV_ADDR_SPACE_SZ0x1000
>
> +#define PCIE20_LNK_CONTROL2_LINK_STATUS2 0xa0
> +
> #define DEVICE_TYPE_RC 0x4
>
> #define QCOM_PCIE_2_1_0_MAX_SUPPLY 3
> @@ -195,6 +198,7 @@ struct qcom_pcie {
> struct phy *phy;
> struct gpio_desc *reset;
> const struct qcom_pcie_ops *ops;
> + int gen;
> };
>
> #define to_qcom_pcie(x) dev_get_drvdata((x)->dev)
> @@ -395,6 +399,11 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie)
> /* wait for clock acquisition */
> usleep_range(1000, 1500);
>
> + if (pcie->gen == 1) {
> + val = readl(pci->dbi_base + PCIE20_LNK_CONTROL2_LINK_STATUS2);
> + val |= 1;
Is this the same bit that's visible in config space as
PCI_EXP_LNKSTA_CLS_2_5GB? Why not use that #define?
There are a bunch of other #defines in this file that look like
redefinitions of standard things:
#define PCIE20_COMMAND_STATUS 0x04
Looks like PCI_COMMAND
#define CMD_BME_VAL 0x4
Looks like PCI_COMMAND_MASTER
#define PCIE20_DEVICE_CONTROL2_STATUS2 0x98
Looks like (PCIE20_CAP + PCI_EXP_DEVCTL2)
#define PCIE_CAP_CPL_TIMEOUT_DISABLE0x10
Looks like PCI_EXP_DEVCTL2_COMP_TMOUT_DIS
#define PCIE20_CAP 0x70
This one is obviously device-specific
#define PCIE20_CAP_LINK_CAPABILITIES(PCIE20_CAP + 0xC)
Looks like (PCIE20_CAP + PCI_EXP_LNKCAP)
#define PCIE20_CAP_ACTIVE_STATE_LINK_PM_SUPPORT (BIT(10) | BIT(11))
Looks like PCI_EXP_LNKCAP_ASPMS
#define PCIE20_CAP_LINK_1 (PCIE20_CAP + 0x14)
#define PCIE_CAP_LINK1_VAL 0x2FD7F
This looks like PCIE20_CAP_LINK_1 should be (PCIE20_CAP +
PCI_EXP_SLTCAP), but "CAP_LINK_1" doesn't sound like the Slot
Capabilities register, and I don't know what PCIE_CAP_LINK1_VAL
means.
> + writel(val, pci->dbi_base + PCIE20_LNK_CONTROL2_LINK_STATUS2);
> + }
>
> /* Set the Max TLP size to 2K, instead of using default of 4K */
> writel(CFG_REMOTE_RD_REQ_BRIDGE_SIZE_2K,
> @@ -1397,6 +1406,10 @@ static int qcom_pcie_probe(struct platform_device
> *pdev)
> goto err_pm_runtime_put;
> }
>
> + pcie->gen = of_pci_get_max_link_speed(pdev->dev.of_node);
> + if (pcie->gen < 0)
> + pcie->gen = 2;
> +
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "parf");
> pcie->parf = devm_ioremap_resource(dev, res);
> if (IS_ERR(pcie->parf)) {
> --
> 2.25.1
>
Re: [PATCH 0/4] selftests, sysctl, lib: Fix prime_numbers and sysctl test to run
On 5/29/20 8:39 AM, Masami Hiramatsu wrote: On Fri, 29 May 2020 08:14:39 -0600 Shuah Khan wrote: On 5/28/20 8:51 AM, Masami Hiramatsu wrote: Hi, Recently, I found some tests were always skipped. Here is a series of patches to fix those issues. The prime_numbers test is skipped in some cases because prime_numbers.ko is not always compiled. Since the CONFIG_PRIME_NUMBERS is not independently configurable item (it has no title and help), it is enabled only if other configs (DRM_DEBUG_SELFTEST etc.) select it. To fix this issue, I added a title and help for CONFIG_PRIME_NUMBERS. The sysctl test is skipped because - selftests/sysctl/config requires CONFIG_TEST_SYSCTL=y. But since lib/test_sysctl.c doesn't use module_init(), the test_syscall is not listed under /sys/module/ and the test script gives up. - Even if we make CONFIG_TEST_SYSCTL=m, the test script checks /sys/modules/test_sysctl before loading module and gives up. - Ayway, since the test module introduces useless sysctl interface to the kernel, it would better be a module. This series includes fixes for above 3 points. - Fix lib/test_sysctl.c to use module_init() - Fix tools/testing/selftests/sysctl/sysctl.sh to try to load test module if it is not loaded (nor embedded). - Fix tools/testing/selftests/sysctl/config to require CONFIG_TEST_SYSCTL=m, not y. Thank you, --- Masami Hiramatsu (4): lib: Make prime number generator independently selectable lib: Make test_sysctl initialized as module selftests/sysctl: Fix to load test_sysctl module selftests/sysctl: Make sysctl test driver as a module lib/math/Kconfig |7 ++- lib/test_sysctl.c|2 +- tools/testing/selftests/sysctl/config|2 +- tools/testing/selftests/sysctl/sysctl.sh | 13 ++--- 4 files changed, 10 insertions(+), 14 deletions(-) -- Masami Hiramatsu (Linaro) Thanks Masami. I see Kees reviewing patches. I will wait for Luis to weigh in on patch 2 before pulling this series in. OK, Thanks Shuah! Applied to linux-kselftest next for Linux 5.8-rc1. thanks, -- Shuah
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On Tue, Jun 02, 2020 at 06:15:57PM +0800, Jason Wang wrote: > > On 2020/6/2 下午4:45, Michael S. Tsirkin wrote: > > So vhost needs to poke at userspace *a lot* in a quick succession. It > > is thus benefitial to enable userspace access, do our thing, then > > disable. Except access_ok has already been pre-validated with all the > > relevant nospec checks, so we don't need that. Add an API to allow > > userspace access after access_ok and barrier_nospec are done. > > > > Signed-off-by: Michael S. Tsirkin > > --- > > > > Jason, so I've been thinking using something along these lines, > > then switching vhost to use unsafe_copy_to_user and friends would > > solve lots of problems you observed with SMAP. > > > > What do you think? > > > I'm fine with this approach. I am not. > > Do we need any other APIs to make it practical? > > > It's not clear whether we need a new API, I think __uaccess_being() has the > assumption that the address has been validated by access_ok(). __uaccess_begin() is a stopgap, not a public API. The problem is real, but "let's add a public API that would do user_access_begin() with access_ok() already done" is no-go.
Re: [PATCH 4.9 00/59] 4.9.226-rc2 review
On Tue, Jun 02, 2020 at 08:37:26AM -0700, Guenter Roeck wrote: On 6/2/20 3:23 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.226 release. There are 59 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu, 04 Jun 2020 10:16:52 +. Anything received after that time might be too late. Many arm builds still fail as attached. Is it really only me seeing this problem ? FWIW, if we need/want to use unified assembler in v4.9.y, shouldn't all unified assembler patches be applied ? We don't - I took 71f8af111010 as a dependency rather than on its own merit. $ git log --oneline v4.9..c001899a5d6 arch/arm | grep unified c001899a5d6c ARM: 8843/1: use unified assembler in headers a216376add73 ARM: 8841/1: use unified assembler in macros eb7ff9023e4f ARM: 8829/1: spinlock: use unified assembler language syntax 32fdb046ac43 ARM: 8828/1: uaccess: use unified assembler language syntax 1293c2b5d790 ARM: dts: berlin2q: add "cache-unified" to l2 node 75fea300d73a ARM: 8723/2: always assume the "unified" syntax for assembly code I am quite concerned especially about missing commit 75fea300d73a, which removes the ARM_ASM_UNIFIED configuration option. That means it is still present in v4.9.y, but the failing builds don't enable it. Given that, the build failures don't seem to be surprising. I'm just going to drop this series from 4.9 for now, until we can figure out how to do it right. -- Thanks, Sasha
Re: [PATCH 4.4 00/47] 4.4.226-rc2 review
On 02/06/2020 11:16, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.226 release. > There are 47 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 04 Jun 2020 09:57:12 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.226-rc2.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v4.4: 6 builds: 6 pass, 0 fail 12 boots: 12 pass, 0 fail 19 tests: 19 pass, 0 fail Linux version: 4.4.226-rc2-gab13e7ba60cc Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra30-cardhu-a04 Cheers Jon -- nvpublic
[PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop
Sometimes the stop triggers a watchdog rather than a stop-ack. Update
the running state to false on requesting stop to skip the watchdog
instead.
Error Logs:
$ echo stop > /sys/class/remoteproc/remoteproc0/state
ipa 1e4.ipa: received modem stopping event
remoteproc-modem: watchdog received: sys_m_smsm_mpss.c:291:APPS force stop
qcom-q6v5-mss 408.remoteproc-modem: port failed halt
ipa 1e4.ipa: received modem offline event
remoteproc0: stopped remote processor 408.remoteproc-modem
Fixes: 3b415c8fb263 ("remoteproc: q6v5: Extract common resource handling")
Cc: sta...@vger.kernel.org
Signed-off-by: Sibi Sankar
---
drivers/remoteproc/qcom_q6v5.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
index 111a442c993c4..fd6fd36268d93 100644
--- a/drivers/remoteproc/qcom_q6v5.c
+++ b/drivers/remoteproc/qcom_q6v5.c
@@ -153,6 +153,8 @@ int qcom_q6v5_request_stop(struct qcom_q6v5 *q6v5)
{
int ret;
+ q6v5->running = false;
+
qcom_smem_state_update_bits(q6v5->state,
BIT(q6v5->stop_bit), BIT(q6v5->stop_bit));
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 2/2] remoteproc: qcom_q6v5_mss: Remove redundant running state
Remove the redundant running state, as an equivalent is maintained in
the common q6v5 resource handling helpers.
Signed-off-by: Sibi Sankar
---
drivers/remoteproc/qcom_q6v5_mss.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index feb70283b6a21..702352cd66188 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -178,8 +178,6 @@ struct q6v5 {
int active_reg_count;
int proxy_reg_count;
- bool running;
-
bool dump_mba_loaded;
unsigned long dump_segment_mask;
unsigned long dump_complete_mask;
@@ -1275,7 +1273,6 @@ static int q6v5_start(struct rproc *rproc)
/* Reset Dump Segment Mask */
qproc->dump_segment_mask = 0;
- qproc->running = true;
return 0;
@@ -1290,8 +1287,6 @@ static int q6v5_stop(struct rproc *rproc)
struct q6v5 *qproc = (struct q6v5 *)rproc->priv;
int ret;
- qproc->running = false;
-
ret = qcom_q6v5_request_stop(>q6v5);
if (ret == -ETIMEDOUT)
dev_err(qproc->dev, "timed out on wait\n");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] ARM: dts: AM33xx-l4: add gpio-ranges
On Tue, Jun 02, 2020 at 06:51:55AM -0700, Tony Lindgren wrote: > * Grygorii Strashko [200602 13:44]: > > > > > > On 02/06/2020 16:14, Drew Fustini wrote: > > > Add gpio-ranges properties to the gpio controller nodes. > > > > > > These gpio-ranges were created based on "Table 9-10. CONTROL_MODULE > > > REGISTERS" in the "AM335x Technical Reference Manual" [0] and "Table > > > 4-2. Pin Attributes" in the "AM335x Sitara Processor datasheet" [1]. > > > A csv file with this data is available for reference [2]. > > > > It will be good if you can explain not only "what" is changed, but > > also "why" it's needed in commit message. > > Also, please check (again) that this is the same for all the am3 > variants. For omap3, we had different pad assignments even between > SoC revisions. Different pad routings should be easy to deal with > in the dts if needed though. > > Regards, > > Tony It appears that the only usage of am33xx-l4.dtsi is for am335x for which specific parts mentioned in those dtsi files are 3352, 3358, and 3359. $ git grep am33xx-l4.dtsi arch/arm/boot/dts/am33xx.dtsi:#include "am33xx-l4.dtsi" $ git grep -l '#include "am33xx.dtsi"' arch/ |wc -l 27 $ git grep -l '#include "am33xx.dtsi"' arch/ |grep -v am335x |wc -l 0 Also, it appears that the only AM33xx parts that actually exist are [0]: AM3351, AM3352, AM3354, AM3356, AM3357, AM3358, AM3359 I clicked on the datasheet link for each product page and while the URL has the specific part number in it [1], they all end up loading the exact same PDF. The header states: "AM3359, AM3358, AM3357, AM3356, AM3354, AM3352, AM3351 SPRS717L – OCTOBER 2011 – REVISED MARCH 2020" Thus, I do believe all SoC's using am33xx-l4.dtsi would have the same memory map for the pin control registers and the same relationshop from pin to gpio line. For example, GPMC_A0 has mode 7 and it is labeled gpio1_16. conf_gpmc_a0 is at offset 840h which makes it pin 16. Maybe am33xx-l4.dtsi should have actually been named am335x-l4.dtsi? Though I suppose there is no point in changing that now. thanks, drew [0] http://www.ti.com/processors/sitara-arm/am335x-cortex-a8/overview.html [1] https://www.ti.com/lit/ds/symlink/am3359.pdf
Re: [PATCH 4.14 00/76] 4.14.183-rc2 review
On 02/06/2020 11:23, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.183 release. > There are 76 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 04 Jun 2020 10:16:52 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.183-rc2.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v4.14: 8 builds: 8 pass, 0 fail 16 boots: 16 pass, 0 fail 24 tests: 24 pass, 0 fail Linux version: 4.14.183-rc2-g3b54ad8f9c83 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH 2/2] mtd: spi-nor: intel-spi: fix forced writable option
On Thu, May 28, 2020 at 03:55:21PM +, Jinhua Wu (jinhwu) wrote: > On 2020/5/28, 11:48 PM, "Jinhua Wu" wrote: > Hi Vignesh, > BIOS just locked down parts of flash (such as, code region), others are still > writeable. Once the SPI locked down,it can't be override unless platfrom > reset > and set WPD (write protect disable) will fail, so ispi->writeable will always > be 0, then the driver will always make the whole flash read only, even if we > have set the parameter writable = 1. > Now the flash is totally not writeable, just part of it is read only. Why not > making > 'writeable' working when explicitly enabled? > > >On 2020/5/28, 7:02 PM, "Vignesh Raghavendra" wrote: > >On 18/05/20 11:29 pm, Daniel Walker wrote: > >> This option currently doesn't work as expected. If the BIOS has this > >> flash as read-only there is no way to change this thru the driver. > >> There is a parameter which allows the flash to become writable with the > >> "writable" option to the module, but it does nothing if the BIOS has it > >> set to read-only. > >> > >> I would expect this option would make the flash writable regardless of > >> the BIOS settings. This patch changes this option so the BIOS setting > >> doesn't stop the writable option from enabling read write on the flash. > >> > > > >I am confused you say "If the BIOS has this flash as read-only there is > >no way to change this thru the driver", so is it possible to override > >BIOS setting? If yes, where is the code in the driver? > > > >What happens if BIOS is set to allow writes but writeable is set to 0? > > > >Also please send patch series as thread (2/2 in reply to 1/2). You can > >use tool like git send-email > > Vignesh, do you still have concerns about this change ? Daniel
Re: [PATCH v2 00/33] iommu: Move iommu_group setup to IOMMU core code
On Tue Jun 02 20, Joerg Roedel wrote:
Hi Jerry,
On Mon, Jun 01, 2020 at 05:02:36PM -0700, Jerry Snitselaar wrote:
Yeah, that will solve the panic.
If you still see the kdump faults, can you please try with the attached
diff? I was not able to reproduce them in my setup.
Regards,
Joerg
I have another hp proliant server now, and reproduced. I will have the
patch below tested shortly. Minor change, I switched group->domain to
domain since group isn't an argument, and *data being passed in comes
from group->domain anyways.
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b5ea203f6c68..5a6d509f72b6 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1680,8 +1680,12 @@ static void probe_alloc_default_domain(struct bus_type
*bus,
static int iommu_group_do_dma_attach(struct device *dev, void *data)
{
struct iommu_domain *domain = data;
+ int ret = 0;
- return __iommu_attach_device(domain, dev);
+ if (!iommu_is_attach_deferred(group->domain, dev))
+ ret = __iommu_attach_device(group->domain, dev);
+
+ return ret;
}
static int __iommu_group_dma_attach(struct iommu_group *group)
___
iommu mailing list
io...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1] PCI: controller: convert to devm_platform_ioremap_resource_byname()
On Tue, Jun 02, 2020 at 02:13:23AM +0800, kbuild test robot wrote:
> Hi Dejin,
>
> Thank you for the patch! Perhaps something to improve:
>
Yes, you are right, I should not modify this file
drivers/pci/controller/pcie-xilinx-nwl.c.
I will sent the patch v2. Thanks very much!
BR,
Dejin
> [auto build test WARNING on pci/next]
> [also build test WARNING on tegra/for-next rockchip/for-next v5.7
> next-20200529]
> [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/Dejin-Zheng/PCI-controller-convert-to-devm_platform_ioremap_resource_byname/20200601-223757
> base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
> config: x86_64-allyesconfig (attached as .config)
> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
> 2388a096e7865c043e83ece4e26654bd3d1a20d5)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install x86_64 cross compiling tool for clang build
> # apt-get install binutils-x86-64-linux-gnu
> # 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 warnings (new ones prefixed by >>, old ones prefixed by <<):
>
> >> drivers/pci/controller/pcie-xilinx-nwl.c:783:25: warning: variable 'res'
> >> is uninitialized when used here [-Wuninitialized]
> pcie->phys_breg_base = res->start;
> ^~~
> drivers/pci/controller/pcie-xilinx-nwl.c:778:22: note: initialize the
> variable 'res' to silence this warning
> struct resource *res;
> ^
> = NULL
> 1 warning generated.
>
> vim +/res +783 drivers/pci/controller/pcie-xilinx-nwl.c
>
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 773
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 774 static int nwl_pcie_parse_dt(struct nwl_pcie *pcie,
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 775struct platform_device *pdev)
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 776 {
> adf9e284b4f76d drivers/pci/host/pcie-xilinx-nwl.c Bjorn Helgaas
> 2016-10-06 777 struct device *dev = pcie->dev;
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 778 struct resource *res;
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 779
> 213cf573e1a8b2 drivers/pci/controller/pcie-xilinx-nwl.c Dejin Zheng
> 2020-06-01 780 pcie->breg_base =
> devm_platform_ioremap_resource_byname(pdev, "breg");
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 781 if (IS_ERR(pcie->breg_base))
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 782 return PTR_ERR(pcie->breg_base);
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 @783 pcie->phys_breg_base = res->start;
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 784
> 213cf573e1a8b2 drivers/pci/controller/pcie-xilinx-nwl.c Dejin Zheng
> 2020-06-01 785 pcie->pcireg_base =
> 213cf573e1a8b2 drivers/pci/controller/pcie-xilinx-nwl.c Dejin Zheng
> 2020-06-01 786 devm_platform_ioremap_resource_byname(pdev,
> "pcireg");
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 787 if (IS_ERR(pcie->pcireg_base))
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 788 return PTR_ERR(pcie->pcireg_base);
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 789 pcie->phys_pcie_reg_base = res->start;
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 790
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 791 res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "cfg");
> cd00f084ed1d50 drivers/pci/host/pcie-xilinx-nwl.c Lorenzo Pieralisi
> 2017-04-19 792 pcie->ecam_base = devm_pci_remap_cfg_resource(dev, res);
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 793 if (IS_ERR(pcie->ecam_base))
> ab597d35ef11d2 drivers/pci/host/pcie-xilinx-nwl.c Bharat Kumar Gogada
> 2016-03-06 794 return
[RESEND PATCH] dt-bindings: property-units: Add picoseconds type
Add the '-ps' picosecond unit suffix for property names. Signed-off-by: Dan Murphy --- Documentation/devicetree/bindings/property-units.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/property-units.txt b/Documentation/devicetree/bindings/property-units.txt index e9b8360b3288..00094070bdac 100644 --- a/Documentation/devicetree/bindings/property-units.txt +++ b/Documentation/devicetree/bindings/property-units.txt @@ -17,6 +17,7 @@ Time/Frequency -ms: millisecond -us: microsecond -ns: nanosecond +-ps: picosecond Distance -- 2.26.2
Re: [PATCH 0/5] cleanups
On Mon, Jun 01, 2020 at 07:45:47PM +0100, Jules Irenge wrote: > > Jules Irenge (5): > rcu/rcutorture: replace 0 with false > rcu: replace 1 with true I queued these two, thank you! > rcu: replace + with | This one I am not all that excited about, so I am leaving it off. Thanx, Paul > x86/ftrace: Add annotations for ftrace_arch_code_modify_prepare() and > ftrace_arch_code_modify_post_process() > sfc: add missing annotation for efx_ef10_try_update_nic_stats_vf() > > arch/x86/kernel/ftrace.c| 2 ++ > drivers/net/ethernet/sfc/ef10.c | 1 + > kernel/rcu/rcutorture.c | 2 +- > kernel/rcu/tree_plugin.h| 22 +++--- > kernel/rcu/update.c | 2 +- > 5 files changed, 16 insertions(+), 13 deletions(-) > > -- > 2.18.2 >
[PATCH net-next v5 0/4] RGMII Internal delay common property
Hello The RGMII internal delay is a common setting found in most RGMII capable PHY devices. It was found that many vendor specific device tree properties exist to do the same function. This creates a common property to be used for PHY's that have tunable internal delays for the Rx and Tx paths. Dan Murphy (4): dt-bindings: net: Add tx and rx internal delays net: phy: Add a helper to return the index for of the internal delay dt-bindings: net: Add RGMII internal delay for DP83869 net: dp83869: Add RGMII internal delay configuration .../devicetree/bindings/net/ethernet-phy.yaml | 13 +++ .../devicetree/bindings/net/ti,dp83869.yaml | 16 +++- drivers/net/phy/dp83869.c | 82 ++- drivers/net/phy/phy_device.c | 51 include/linux/phy.h | 2 + 5 files changed, 160 insertions(+), 4 deletions(-) -- 2.26.2
Re: [PATCH 1/2] sched/uclamp: Add a new sysctl to control RT default boost value
On 29.05.20 12:08, Mel Gorman wrote: > On Thu, May 28, 2020 at 06:11:12PM +0200, Peter Zijlstra wrote: >>> FWIW, I think you're referring to Mel's notice in OSPM regarding the >>> overhead. >>> Trying to see what goes on in there. >> >> Indeed, that one. The fact that regular distros cannot enable this >> feature due to performance overhead is unfortunate. It means there is a >> lot less potential for this stuff. > > During that talk, I was a vague about the cost, admitted I had not looked > too closely at mainline performance and had since deleted the data given > that the problem was first spotted in early April. If I heard someone > else making statements like I did at the talk, I would consider it a bit > vague, potentially FUD, possibly wrong and worth rechecking myself. In > terms of distributions "cannot enable this", we could but I was unwilling > to pay the cost for a feature no one has asked for yet. If they had, I > would endevour to put it behind static branches and disable it by default > (like what happened for PSI). I was contacted offlist about my comments > at OSPM and gathered new data to respond properly. For the record, here > is an editted version of my response; [...] I ran these tests on 'Ubuntu 18.04 Desktop' on Intel E5-2690 v2 (2 sockets * 10 cores * 2 threads) with powersave governor as: $ numactl -N 0 ./run-mmtests.sh XXX w/ config-network-netperf-unbound. Running w/o 'numactl -N 0' gives slightly worse results. without-clamp : CONFIG_UCLAMP_TASK is not set with-clamp : CONFIG_UCLAMP_TASK=y, CONFIG_UCLAMP_TASK_GROUP is not set with-clamp-tskgrp : CONFIG_UCLAMP_TASK=y, CONFIG_UCLAMP_TASK_GROUP=y netperf-udp ./5.7.0-rc7./5.7.0-rc7 ./5.7.0-rc7 without-clamp with-clamp with-clamp-tskgrp Hmean send-64 153.62 ( 0.00%) 151.80 * -1.19%* 155.60 * 1.28%* Hmean send-128306.77 ( 0.00%) 306.27 * -0.16%* 309.39 * 0.85%* Hmean send-256608.54 ( 0.00%) 604.28 * -0.70%* 613.42 * 0.80%* Hmean send-1024 2395.80 ( 0.00%) 2365.67 * -1.26%* 2409.50 * 0.57%* Hmean send-2048 4608.70 ( 0.00%) 4544.02 * -1.40%* 4665.96 * 1.24%* Hmean send-3312 7223.97 ( 0.00%) 7158.88 * -0.90%* 7331.23 * 1.48%* Hmean send-4096 8729.53 ( 0.00%) 8598.78 * -1.50%* 8860.47 * 1.50%* Hmean send-8192 14961.77 ( 0.00%)14418.92 * -3.63%*14908.36 * -0.36%* Hmean send-1638425799.50 ( 0.00%)25025.64 * -3.00%*25831.20 * 0.12%* Hmean recv-64 153.62 ( 0.00%) 151.80 * -1.19%* 155.60 * 1.28%* Hmean recv-128306.77 ( 0.00%) 306.27 * -0.16%* 309.39 * 0.85%* Hmean recv-256608.54 ( 0.00%) 604.28 * -0.70%* 613.42 * 0.80%* Hmean recv-1024 2395.80 ( 0.00%) 2365.67 * -1.26%* 2409.50 * 0.57%* Hmean recv-2048 4608.70 ( 0.00%) 4544.02 * -1.40%* 4665.95 * 1.24%* Hmean recv-3312 7223.97 ( 0.00%) 7158.88 * -0.90%* 7331.23 * 1.48%* Hmean recv-4096 8729.53 ( 0.00%) 8598.78 * -1.50%* 8860.47 * 1.50%* Hmean recv-8192 14961.61 ( 0.00%)14418.88 * -3.63%*14908.30 * -0.36%* Hmean recv-1638425799.39 ( 0.00%)25025.49 * -3.00%*25831.00 * 0.12%* netperf-tcp Hmean 64 818.65 ( 0.00%) 812.98 * -0.69%* 826.17 * 0.92%* Hmean 1281569.55 ( 0.00%) 1555.79 * -0.88%* 1586.94 * 1.11%* Hmean 2562952.86 ( 0.00%) 2915.07 * -1.28%* 2968.15 * 0.52%* Hmean 1024 10425.91 ( 0.00%)10296.68 * -1.24%*10418.38 * -0.07%* Hmean 2048 17454.51 ( 0.00%)17369.57 * -0.49%*17419.24 * -0.20%* Hmean 3312 22509.95 ( 0.00%)9.69 * -1.25%*22373.32 * -0.61%* Hmean 4096 25033.23 ( 0.00%)24859.59 * -0.69%*24912.50 * -0.48%* Hmean 8192 32080.51 ( 0.00%)31744.51 * -1.05%*31800.45 * -0.87%* Hmean 16384 36531.86 ( 0.00%)37064.68 * 1.46%*37397.71 * 2.37%* The diffs are smaller than on openSUSE Leap 15.1 and some of the uclamp taskgroup results are better? With this test setup we now can play with the uclamp code in enqueue_task() and dequeue_task(). --- W/ config-network-netperf-unbound (only netperf-udp and buffer size 64): $ perf diff 5.7.0-rc7_without-clamp/perf.data 5.7.0-rc7_with-clamp/perf.data | grep activate_task # Event 'cycles:ppp' # # Baseline Delta Abs Shared ObjectSymbol 0.02% +0.54% [kernel.vmlinux] [k] activate_task 0.02% +0.38% [kernel.vmlinux] [k] deactivate_task $ perf diff
[PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
Add RGMII internal delay configuration for Rx and Tx.
Signed-off-by: Dan Murphy
---
drivers/net/phy/dp83869.c | 82 +--
1 file changed, 79 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index cfb22a21a2e6..ba1e3d599888 100644
--- a/drivers/net/phy/dp83869.c
+++ b/drivers/net/phy/dp83869.c
@@ -64,6 +64,10 @@
#define DP83869_RGMII_TX_CLK_DELAY_EN BIT(1)
#define DP83869_RGMII_RX_CLK_DELAY_EN BIT(0)
+/* RGMIIDCTL */
+#define DP83869_RGMII_CLK_DELAY_SHIFT 4
+#define DP83869_CLK_DELAY_DEF 7
+
/* STRAP_STS1 bits */
#define DP83869_STRAP_OP_MODE_MASK GENMASK(2, 0)
#define DP83869_STRAP_STS1_RESERVEDBIT(11)
@@ -78,9 +82,6 @@
#define DP83869_PHYCR_FIFO_DEPTH_MASK GENMASK(15, 12)
#define DP83869_PHYCR_RESERVED_MASKBIT(11)
-/* RGMIIDCTL bits */
-#define DP83869_RGMII_TX_CLK_DELAY_SHIFT 4
-
/* IO_MUX_CFG bits */
#define DP83869_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
@@ -99,6 +100,10 @@
#define DP83869_OP_MODE_MIIBIT(5)
#define DP83869_SGMII_RGMII_BRIDGE BIT(6)
+static const int dp83869_internal_delay[] = {250, 500, 750, 1000, 1250, 1500,
+1750, 2000, 2250, 2500, 2750, 3000,
+3250, 3500, 3750, 4000};
+
enum {
DP83869_PORT_MIRRORING_KEEP,
DP83869_PORT_MIRRORING_EN,
@@ -108,6 +113,8 @@ enum {
struct dp83869_private {
int tx_fifo_depth;
int rx_fifo_depth;
+ s32 rx_id_delay;
+ s32 tx_id_delay;
int io_impedance;
int port_mirroring;
bool rxctrl_strap_quirk;
@@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device *phydev)
>tx_fifo_depth))
dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
+ ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
+ >rx_id_delay);
+ if (ret) {
+ dp83869->rx_id_delay =
+ dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
+ ret = 0;
+ }
+
+ ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
+ >tx_id_delay);
+ if (ret) {
+ dp83869->tx_id_delay =
+ dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
+ ret = 0;
+ }
+
return ret;
}
#else
@@ -367,10 +390,35 @@ static int dp83869_configure_mode(struct phy_device
*phydev,
return ret;
}
+static int dp83869_get_delay(struct phy_device *phydev)
+{
+ struct dp83869_private *dp83869 = phydev->priv;
+ int delay_size = ARRAY_SIZE(dp83869_internal_delay);
+ int tx_delay;
+ int rx_delay;
+
+ tx_delay = phy_get_delay_index(phydev, _internal_delay[0],
+ delay_size, dp83869->tx_id_delay);
+ if (tx_delay < 0) {
+ phydev_err(phydev, "Tx internal delay is invalid\n");
+ return tx_delay;
+ }
+
+ rx_delay = phy_get_delay_index(phydev, _internal_delay[0],
+ delay_size, dp83869->rx_id_delay);
+ if (rx_delay < 0) {
+ phydev_err(phydev, "Rx internal delay is invalid\n");
+ return rx_delay;
+ }
+
+ return rx_delay | tx_delay << DP83869_RGMII_CLK_DELAY_SHIFT;
+}
+
static int dp83869_config_init(struct phy_device *phydev)
{
struct dp83869_private *dp83869 = phydev->priv;
int ret, val;
+ int delay;
ret = dp83869_configure_mode(phydev, dp83869);
if (ret)
@@ -394,6 +442,34 @@ static int dp83869_config_init(struct phy_device *phydev)
dp83869->clk_output_sel <<
DP83869_IO_MUX_CFG_CLK_O_SEL_SHIFT);
+ if (phy_interface_is_rgmii(phydev)) {
+ delay = dp83869_get_delay(phydev);
+ if (delay < 0)
+ return delay;
+
+ ret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIIDCTL,
+ delay);
+ if (ret)
+ return ret;
+
+ val = phy_read_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL);
+ val &= ~(DP83869_RGMII_TX_CLK_DELAY_EN |
+DP83869_RGMII_RX_CLK_DELAY_EN);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ val |= (DP83869_RGMII_TX_CLK_DELAY_EN |
+ DP83869_RGMII_RX_CLK_DELAY_EN);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
+ val |= DP83869_RGMII_TX_CLK_DELAY_EN;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
+ val |= DP83869_RGMII_RX_CLK_DELAY_EN;
+
[PATCH net-next v5 2/4] net: phy: Add a helper to return the index for of the internal delay
Add a helper function that will return the index in the array for the
passed in internal delay value. The helper requires the array, size and
delay value.
The helper will then return the index for the exact match or return the
index for the index to the closest smaller value.
Signed-off-by: Dan Murphy
---
drivers/net/phy/phy_device.c | 51
include/linux/phy.h | 2 ++
2 files changed, 53 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 04946de74fa0..5d4e7520b15e 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2657,6 +2657,57 @@ void phy_get_pause(struct phy_device *phydev, bool
*tx_pause, bool *rx_pause)
}
EXPORT_SYMBOL(phy_get_pause);
+/**
+ * phy_get_delay_index - returns the index of the internal delay
+ * @phydev: phy_device struct
+ * @delay_values: array of delays the PHY supports
+ * @size: the size of the delay array
+ * @int_delay: the internal delay to be looked up
+ *
+ * Returns the index within the array of internal delay passed in.
+ * The array must be in ascending order.
+ * Return errno if the delay is invalid or cannot be found.
+ */
+s32 phy_get_delay_index(struct phy_device *phydev, const int *delay_values,
+ int size, int int_delay)
+{
+ int i;
+
+ if (int_delay < 0)
+ return -EINVAL;
+
+ if (size <= 0)
+ return -EINVAL;
+
+ if (int_delay < delay_values[0] || int_delay > delay_values[size - 1]) {
+ phydev_err(phydev, "Delay %d is out of range\n", int_delay);
+ return -EINVAL;
+ }
+
+ if (int_delay == delay_values[0])
+ return 0;
+
+ for (i = 1; i < size; i++) {
+ if (int_delay == delay_values[i])
+ return i;
+
+ /* Find an approximate index by looking up the table */
+ if (int_delay > delay_values[i - 1] &&
+ int_delay < delay_values[i]) {
+ if (int_delay - delay_values[i - 1] <
+ delay_values[i] - int_delay)
+ return i - 1;
+ else
+ return i;
+ }
+ }
+
+ phydev_err(phydev, "error finding internal delay index for %d\n",
+ int_delay);
+ return -EINVAL;
+}
+EXPORT_SYMBOL(phy_get_delay_index);
+
static bool phy_drv_supports_irq(struct phy_driver *phydrv)
{
return phydrv->config_intr && phydrv->ack_interrupt;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 8c05d0fb5c00..a4327e6fd356 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1430,6 +1430,8 @@ void phy_set_asym_pause(struct phy_device *phydev, bool
rx, bool tx);
bool phy_validate_pause(struct phy_device *phydev,
struct ethtool_pauseparam *pp);
void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause);
+int phy_get_delay_index(struct phy_device *phydev, const int *delay_values,
+ int size, int delay);
void phy_resolve_pause(unsigned long *local_adv, unsigned long *partner_adv,
bool *tx_pause, bool *rx_pause);
--
2.26.2
[PATCH net-next v5 1/4] dt-bindings: net: Add tx and rx internal delays
tx-internal-delays and rx-internal-delays are a common setting for RGMII capable devices. These properties are used when the phy-mode or phy-controller is set to rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the controller that the PHY will add the internal delay for the connection. Signed-off-by: Dan Murphy --- .../devicetree/bindings/net/ethernet-phy.yaml | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 9b1f1147ca36..edd0245d132b 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -162,6 +162,19 @@ properties: description: Specifies a reference to a node representing a SFP cage. + + rx-internal-delay-ps: +$ref: /schemas/types.yaml#definitions/uint32 +description: | + RGMII Receive PHY Clock Delay defined in pico seconds. This is used for + PHY's that have configurable RX internal delays. + + tx-internal-delay-ps: +$ref: /schemas/types.yaml#definitions/uint32 +description: | + RGMII Transmit PHY Clock Delay defined in pico seconds. This is used for + PHY's that have configurable TX internal delays. + required: - reg -- 2.26.2
[PATCH net-next v5 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
Add the internal delay values into the header and update the binding with the internal delay properties. Signed-off-by: Dan Murphy --- .../devicetree/bindings/net/ti,dp83869.yaml | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml index 5b69ef03bbf7..71e90a3e4652 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#; title: TI DP83869 ethernet PHY allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: "ethernet-phy.yaml#" maintainers: - Dan Murphy @@ -64,6 +64,18 @@ properties: Operational mode for the PHY. If this is not set then the operational mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values + rx-internal-delay-ps: +description: Delay is in pico seconds +enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000, +3250, 3500, 3750, 4000 ] +default: 2000 + + tx-internal-delay-ps: +description: Delay is in pico seconds +enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000, +3250, 3500, 3750, 4000 ] +default: 2000 + required: - reg @@ -80,5 +92,7 @@ examples: ti,op-mode = ; ti,max-output-impedance = "true"; ti,clk-output-sel = ; +rx-internal-delay-ps = <2000>; +tx-internal-delay-ps = <2000>; }; }; -- 2.26.2
Re: [PATCH 05/14] mm: workingset: let cache workingset challenge anon
On Tue, Jun 02, 2020 at 11:34:17AM +0900, Joonsoo Kim wrote:
> 2020년 6월 2일 (화) 오전 12:56, Johannes Weiner 님이 작성:
> > On Mon, Jun 01, 2020 at 03:14:24PM +0900, Joonsoo Kim wrote:
> > > But, I still think that modified refault activation equation isn't
> > > safe. The next
> > > problem I found is related to the scan ratio limit patch ("limit the
> > > range of
> > > LRU type balancing") on this series. See the below example.
> > >
> > > anon: Hot (X M)
> > > file: Hot (200 M) / dummy (200 M)
> > > P: 1200 M (3 parts, each one 400 M, P1, P2, P3)
> > > Access Pattern: A -> F(H) -> P1 -> A -> F(H) -> P2 -> ... ->
> > >
> > > Without this patch, A and F(H) are kept on the memory and look like
> > > it's correct.
> > >
> > > With this patch and below fix, refault equation for Pn would be:
> > >
> > > Refault dist of Pn = 1200 (from file non-resident) + 1200 * anon scan
> > > ratio (from anon non-resident)
> > > anon + active file = X + 200
> > > 1200 + 1200 * anon scan ratio (0.5 ~ 2) < X + 200
> >
> > That doesn't look quite right to me. The anon part of the refault
> > distance is driven by X, so the left-hand of this formula contains X
> > as well.
> >
> > 1000 file (1200M reuse distance, 200M in-core size) + F(H) reactivations +
> > X * scan ratio < X + 1000
>
> As I said before, there is no X on left-hand of this formula. To
> access all Pn and
> re-access P1, we need 1200M file list scan and reclaim. More scan isn't
> needed.
> With your patch "limit the range of LRU type balancing", scan ratio
> between file/anon
> list is limited to 0.5 ~ 2.0, so, maximum anon scan would be 1200 M *
> 2.0, that is,
> 2400 M and not bounded by X. That means that file list cannot be
> stable with some X.
Oh, no X on the left because you're talking about the number of pages
scanned until the first refaults, which is fixed - so why are we still
interpreting the refault distance against a variable anon size X?
Well, that's misleading. We compare against anon because part of the
cache is already encoded in the refault distance. What we're really
checking is access distance against total amount of available RAM.
Consider this. We want to activate pages where
access_distance <= RAM
and our measure of access distance is:
access_distance = refault_distance + inactive_file
So the comparison becomes:
refault_distance + inactive_file < RAM
which we simplify to:
refault_distance < active_file + anon
There is a certain threshold for X simply because there is a certain
threshold for RAM beyond which we need to start activating. X cannot
be arbitrary, it must be X + cache filling up memory - after all we
have page reclaim evicting pages.
Again, this isn't new. In the current code, we activate when:
refault_distance < active_file
which is
access_distance <= RAM - anon
You can see, whether things are stable or not always depends on the
existing workingset size. It's just a proxy for how much total RAM we
have potentially available to the refaulting page.
> If my lastly found example is a correct example (your confirm is required),
> it is also related to the correctness issue since cold pages causes
> eviction of the hot pages repeatedly.
I think your example is correct, but it benefits from the VM
arbitrarily making an assumption that has a 50/50 shot of being true.
You and I know which pages are hot and which are cold because you
designed the example.
All the VM sees is this:
- We have an established workingset that has previously shown an
access distance <= RAM and therefor was activated.
- We now have another set that also appears to have an access distance
<= RAM. The only way to know for sure, however, is sample the
established workingset and compare the relative access frequencies.
Currently, we just assume the incoming pages are colder. Clearly
that's beneficial when it's true. Clearly that can be totally wrong.
We must allow a fair comparison between these two sets.
For cache, that's already the case - that's why I brought up the
cache-only example: if refault distances are 50M and you have 60M of
active cache, we activate all refaults and force an even competition
between the established workingset and the new pages.
Whether we can protect active file when anon needs to shrink first and
can't (the activate/iocost split) that's a different question. But I'm
no longer so sure after looking into it further.
First, we would need two different refault distances: either we
consider anon age and need to compare to active_file + anon, or we
don't and compare to active_file only. We cannot mix willy nilly,
because the metrics wouldn't be comparable. We don't have the space to
store two different eviction timestamps, nor could we afford to cut
the precision in half.
Second, the additional page flag required to implement it.
Third, it's somewhat moot because we still have the same behavior when
active_file would need to shrink and can't. There can't be a
[PATCH v3 2/4] iio: chemical: scd30: add I2C interface driver
Add I2C interface driver for the SCD30 sensor.
Signed-off-by: Tomasz Duszynski
---
MAINTAINERS | 1 +
drivers/iio/chemical/Kconfig | 11 +++
drivers/iio/chemical/Makefile| 1 +
drivers/iio/chemical/scd30_i2c.c | 134 +++
4 files changed, 147 insertions(+)
create mode 100644 drivers/iio/chemical/scd30_i2c.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 41a509cca6f1..13aed3473b7e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15142,6 +15142,7 @@ M: Tomasz Duszynski
S: Maintained
F: drivers/iio/chemical/scd30.h
F: drivers/iio/chemical/scd30_core.c
+F: drivers/iio/chemical/scd30_i2c.c
SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
M: Tomasz Duszynski
diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
index 99e852b67e55..970d34888c2e 100644
--- a/drivers/iio/chemical/Kconfig
+++ b/drivers/iio/chemical/Kconfig
@@ -96,6 +96,17 @@ config SCD30_CORE
To compile this driver as a module, choose M here: the module will
be called scd30_core.
+config SCD30_I2C
+ tristate "SCD30 carbon dioxide sensor I2C driver"
+ depends on SCD30_CORE && I2C
+ select CRC8
+ help
+ Say Y here to build support for the Sensirion SCD30 I2C interface
+ driver.
+
+ To compile this driver as a module, choose M here: the module will
+ be called scd30_i2c.
+
config SENSIRION_SGP30
tristate "Sensirion SGPxx gas sensors"
depends on I2C
diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
index c9804b041ecd..0966ca34e34b 100644
--- a/drivers/iio/chemical/Makefile
+++ b/drivers/iio/chemical/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_CCS811) += ccs811.o
obj-$(CONFIG_IAQCORE) += ams-iaq-core.o
obj-$(CONFIG_PMS7003) += pms7003.o
obj-$(CONFIG_SCD30_CORE) += scd30_core.o
+obj-$(CONFIG_SCD30_I2C) += scd30_i2c.o
obj-$(CONFIG_SENSIRION_SGP30) += sgp30.o
obj-$(CONFIG_SPS30) += sps30.o
obj-$(CONFIG_VZ89X)+= vz89x.o
diff --git a/drivers/iio/chemical/scd30_i2c.c b/drivers/iio/chemical/scd30_i2c.c
new file mode 100644
index ..a6b532b83669
--- /dev/null
+++ b/drivers/iio/chemical/scd30_i2c.c
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sensirion SCD30 carbon dioxide sensor i2c driver
+ *
+ * Copyright (c) 2020 Tomasz Duszynski
+ *
+ * I2C slave address: 0x61
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "scd30.h"
+
+#define SCD30_I2C_MAX_BUF_SIZE 18
+#define SCD30_I2C_CRC8_POLYNOMIAL 0x31
+
+static u16 scd30_i2c_cmd_lookup_tbl[] = {
+ [CMD_START_MEAS] = 0x0010,
+ [CMD_STOP_MEAS] = 0x0104,
+ [CMD_MEAS_INTERVAL] = 0x4600,
+ [CMD_MEAS_READY] = 0x0202,
+ [CMD_READ_MEAS] = 0x0300,
+ [CMD_ASC] = 0x5306,
+ [CMD_FRC] = 0x5204,
+ [CMD_TEMP_OFFSET] = 0x5403,
+ [CMD_FW_VERSION] = 0xd100,
+ [CMD_RESET] = 0xd304,
+};
+
+DECLARE_CRC8_TABLE(scd30_i2c_crc8_tbl);
+
+static int scd30_i2c_xfer(struct scd30_state *state, char *txbuf, int txsize,
+ char *rxbuf, int rxsize)
+{
+ struct i2c_client *client = to_i2c_client(state->dev);
+ int ret;
+
+ /*
+* repeated start is not supported hence instead of sending two i2c
+* messages in a row we send one by one
+*/
+ ret = i2c_master_send(client, txbuf, txsize);
+ if (ret != txsize)
+ return ret < 0 ? ret : -EIO;
+
+ if (!rxbuf)
+ return 0;
+
+ ret = i2c_master_recv(client, rxbuf, rxsize);
+ if (ret != rxsize)
+ return ret < 0 ? ret : -EIO;
+
+ return 0;
+}
+
+static int scd30_i2c_command(struct scd30_state *state, enum scd30_cmd cmd,
+u16 arg, void *response, int size)
+{
+ char crc, buf[SCD30_I2C_MAX_BUF_SIZE], *rsp = response;
+ int i, ret;
+
+ put_unaligned_be16(scd30_i2c_cmd_lookup_tbl[cmd], buf);
+ i = 2;
+
+ if (rsp) {
+ /* each two bytes are followed by a crc8 */
+ size += size / 2;
+ } else {
+ put_unaligned_be16(arg, buf + i);
+ crc = crc8(scd30_i2c_crc8_tbl, buf + i, 2, CRC8_INIT_VALUE);
+ i += 2;
+ buf[i] = crc;
+ i += 1;
+
+ /* commands below don't take an argument */
+ if ((cmd == CMD_STOP_MEAS) || (cmd == CMD_RESET))
+ i -= 3;
+ }
+
+ ret = scd30_i2c_xfer(state, buf, i, buf, size);
+ if (ret)
+ return ret;
+
+ /* validate received data and strip off crc bytes */
+ for (i = 0; i < size; i += 3) {
+ crc = crc8(scd30_i2c_crc8_tbl, buf + i, 2, CRC8_INIT_VALUE);
+ if (crc != buf[i + 2]) {
+ dev_err(state->dev, "data integrity check failed\n");
+ return
[PATCH] ntfs: Fix ntfs_test_inode and ntfs_init_locked_inode function type
If the kernel is built with CFI we hit a __cfi_check_fail
while mounting a partition
Call trace:
__cfi_check_fail+0x1c/0x24
name_to_dev_t+0x0/0x404
iget5_locked+0x594/0x5e8
ntfs_fill_super+0xbfc/0x43ec
mount_bdev+0x30c/0x3cc
ntfs_mount+0x18/0x24
mount_fs+0x1b0/0x380
vfs_kern_mount+0x90/0x398
do_mount+0x5d8/0x1a10
SyS_mount+0x108/0x144
el0_svc_naked+0x34/0x38
Fixing iget5_locked and ilookup5 callers seems enough
Signed-off-by: Luca Stefani
Tested-by: freak07
---
fs/ntfs/dir.c | 2 +-
fs/ntfs/inode.c | 23 ---
fs/ntfs/inode.h | 4 +---
fs/ntfs/mft.c | 5 ++---
4 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/fs/ntfs/dir.c b/fs/ntfs/dir.c
index 3c4811469ae8..e278bfc5ee7f 100644
--- a/fs/ntfs/dir.c
+++ b/fs/ntfs/dir.c
@@ -1503,7 +1503,7 @@ static int ntfs_dir_fsync(struct file *filp, loff_t
start, loff_t end,
na.type = AT_BITMAP;
na.name = I30;
na.name_len = 4;
- bmp_vi = ilookup5(vi->i_sb, vi->i_ino, (test_t)ntfs_test_inode, );
+ bmp_vi = ilookup5(vi->i_sb, vi->i_ino, ntfs_test_inode, );
if (bmp_vi) {
write_inode_now(bmp_vi, !datasync);
iput(bmp_vi);
diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index d4359a1df3d5..34c919bc0dfe 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -30,7 +30,7 @@
/**
* ntfs_test_inode - compare two (possibly fake) inodes for equality
* @vi:vfs inode which to test
- * @na:ntfs attribute which is being tested with
+ * @data: data which is being tested with
*
* Compare the ntfs attribute embedded in the ntfs specific part of the vfs
* inode @vi for equality with the ntfs attribute @na.
@@ -43,8 +43,9 @@
* NOTE: This function runs with the inode_hash_lock spin lock held so it is
not
* allowed to sleep.
*/
-int ntfs_test_inode(struct inode *vi, ntfs_attr *na)
+int ntfs_test_inode(struct inode *vi, void *data)
{
+ ntfs_attr *na = data;
ntfs_inode *ni;
if (vi->i_ino != na->mft_no)
@@ -72,7 +73,7 @@ int ntfs_test_inode(struct inode *vi, ntfs_attr *na)
/**
* ntfs_init_locked_inode - initialize an inode
* @vi:vfs inode to initialize
- * @na:ntfs attribute which to initialize @vi to
+ * @data: data which to initialize @vi to
*
* Initialize the vfs inode @vi with the values from the ntfs attribute @na in
* order to enable ntfs_test_inode() to do its work.
@@ -87,8 +88,9 @@ int ntfs_test_inode(struct inode *vi, ntfs_attr *na)
* NOTE: This function runs with the inode->i_lock spin lock held so it is not
* allowed to sleep. (Hence the GFP_ATOMIC allocation.)
*/
-static int ntfs_init_locked_inode(struct inode *vi, ntfs_attr *na)
+static int ntfs_init_locked_inode(struct inode *vi, void *data)
{
+ ntfs_attr *na = data;
ntfs_inode *ni = NTFS_I(vi);
vi->i_ino = na->mft_no;
@@ -131,7 +133,6 @@ static int ntfs_init_locked_inode(struct inode *vi,
ntfs_attr *na)
return 0;
}
-typedef int (*set_t)(struct inode *, void *);
static int ntfs_read_locked_inode(struct inode *vi);
static int ntfs_read_locked_attr_inode(struct inode *base_vi, struct inode
*vi);
static int ntfs_read_locked_index_inode(struct inode *base_vi,
@@ -164,8 +165,8 @@ struct inode *ntfs_iget(struct super_block *sb, unsigned
long mft_no)
na.name = NULL;
na.name_len = 0;
- vi = iget5_locked(sb, mft_no, (test_t)ntfs_test_inode,
- (set_t)ntfs_init_locked_inode, );
+ vi = iget5_locked(sb, mft_no, ntfs_test_inode,
+ ntfs_init_locked_inode, );
if (unlikely(!vi))
return ERR_PTR(-ENOMEM);
@@ -225,8 +226,8 @@ struct inode *ntfs_attr_iget(struct inode *base_vi,
ATTR_TYPE type,
na.name = name;
na.name_len = name_len;
- vi = iget5_locked(base_vi->i_sb, na.mft_no, (test_t)ntfs_test_inode,
- (set_t)ntfs_init_locked_inode, );
+ vi = iget5_locked(base_vi->i_sb, na.mft_no, ntfs_test_inode,
+ ntfs_init_locked_inode, );
if (unlikely(!vi))
return ERR_PTR(-ENOMEM);
@@ -280,8 +281,8 @@ struct inode *ntfs_index_iget(struct inode *base_vi,
ntfschar *name,
na.name = name;
na.name_len = name_len;
- vi = iget5_locked(base_vi->i_sb, na.mft_no, (test_t)ntfs_test_inode,
- (set_t)ntfs_init_locked_inode, );
+ vi = iget5_locked(base_vi->i_sb, na.mft_no, ntfs_test_inode,
+ ntfs_init_locked_inode, );
if (unlikely(!vi))
return ERR_PTR(-ENOMEM);
diff --git a/fs/ntfs/inode.h b/fs/ntfs/inode.h
index 98e670fbdd31..363e4e820673 100644
--- a/fs/ntfs/inode.h
+++ b/fs/ntfs/inode.h
@@ -253,9 +253,7 @@ typedef struct {
ATTR_TYPE type;
} ntfs_attr;
-typedef int (*test_t)(struct inode *, void *);
-
-extern int ntfs_test_inode(struct inode *vi, ntfs_attr *na);
[PATCH v3 0/4] Add support for SCD30 sensor
Following series adds support for Sensirion SCD30 sensor module capable of measuring carbon dioxide, temperature and relative humidity. CO2 measurements base on NDIR principle while temperature and relative humidity are measured by the on board SHT31. As for sensor communication, both I2C and serial interfaces are supported. v3: * simplify code by scaling temperature & humidity in _read_meas() * update realbits in scan types * s/adjecent/adjacent * drop IIO_CHAN_INFO_RAW from _write_raw_get_fmt because there's no raw output channel * rework locking in _read_raw * fix endianess problem on BE machine * align timestamp properly before pushing to buffers * explain why interrupt gets disabled after registration * add trigger validation * drop SCALE for temperature and humidity channel as they are processed * register action which stops measuring after starting measurements * spit generic calibration attr into two doing specific things * add comment explaining why priv in struct scd30_state is for * rename node in binding example to co2-sensor v2: * move asm/byteorder.h towards the bottom of include list * make channel address names in enum more specific * add postfixes to defines and extra comments * drop unneeded i2c include from scd30 header * break generic command sending function into specialized options * expose automatic calibration and forced calibration via the same attr * use SAMP_FREQ to set frequency instead of meas_interval attr * use CALISCALE to set pressure compensation instead of pressure_comp attr * use CALIBBIAS to set temperature offset instead of temp_offset attr * fix order in MAINTAINERS * drop attribute allowing one to reset sensor * as we have dt probing drop board file based probing (i2c_device_id) * merge patches touching related files * use fwnode API to retrieve interrupt from dt * fix interrupt-parent spelling * change binding license * drop supply from required property Tomasz Duszynski (4): iio: chemical: scd30: add core driver iio: chemical: scd30: add I2C interface driver iio: chemical: scd30: add serial interface driver dt-bindings: iio: scd30: add device binding file Documentation/ABI/testing/sysfs-bus-iio-scd30 | 34 + .../iio/chemical/sensirion,scd30.yaml | 68 ++ MAINTAINERS | 9 + drivers/iio/chemical/Kconfig | 33 + drivers/iio/chemical/Makefile | 3 + drivers/iio/chemical/scd30.h | 80 ++ drivers/iio/chemical/scd30_core.c | 783 ++ drivers/iio/chemical/scd30_i2c.c | 134 +++ drivers/iio/chemical/scd30_serial.c | 266 ++ 9 files changed, 1410 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-scd30 create mode 100644 Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml create mode 100644 drivers/iio/chemical/scd30.h create mode 100644 drivers/iio/chemical/scd30_core.c create mode 100644 drivers/iio/chemical/scd30_i2c.c create mode 100644 drivers/iio/chemical/scd30_serial.c -- 2.26.2
[PATCH v3 1/4] iio: chemical: scd30: add core driver
Add Sensirion SCD30 carbon dioxide core driver.
Signed-off-by: Tomasz Duszynski
---
Documentation/ABI/testing/sysfs-bus-iio-scd30 | 34 +
MAINTAINERS | 6 +
drivers/iio/chemical/Kconfig | 11 +
drivers/iio/chemical/Makefile | 1 +
drivers/iio/chemical/scd30.h | 80 ++
drivers/iio/chemical/scd30_core.c | 783 ++
6 files changed, 915 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-scd30
create mode 100644 drivers/iio/chemical/scd30.h
create mode 100644 drivers/iio/chemical/scd30_core.c
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-scd30
b/Documentation/ABI/testing/sysfs-bus-iio-scd30
new file mode 100644
index ..b9712f390bec
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-scd30
@@ -0,0 +1,34 @@
+What: /sys/bus/iio/devices/iio:deviceX/calibration_auto_enable
+Date: June 2020
+KernelVersion: 5.8
+Contact: linux-...@vger.kernel.org
+Description:
+ Contaminants build-up in the measurement chamber or optical
+ elements deterioration leads to sensor drift.
+
+ One can compensate for sensor drift by using automatic self
+ calibration procedure (asc).
+
+ Writing 1 or 0 to this attribute will respectively activate or
+ deactivate asc.
+
+ Upon reading current asc status is returned.
+
+What: /sys/bus/iio/devices/iio:deviceX/calibration_forced_value
+Date: June 2020
+KernelVersion: 5.8
+Contact: linux-...@vger.kernel.org
+Description:
+ Contaminants build-up in the measurement chamber or optical
+ elements deterioration leads to sensor drift.
+
+ One can compensate for sensor drift by using forced
+ recalibration (frc). This is useful in case there's known
+ co2 reference available nearby the sensor.
+
+ Picking value from the range [400 1 2000] and writing it to the
+ sensor will set frc.
+
+ Upon reading current frc value is returned. Note that after
+ power cycling default value (i.e 400) is returned even though
+ internally sensor had recalibrated itself.
diff --git a/MAINTAINERS b/MAINTAINERS
index 60ed2963efaa..41a509cca6f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15137,6 +15137,12 @@ S: Maintained
F: drivers/misc/phantom.c
F: include/uapi/linux/phantom.h
+SENSIRION SCD30 CARBON DIOXIDE SENSOR DRIVER
+M: Tomasz Duszynski
+S: Maintained
+F: drivers/iio/chemical/scd30.h
+F: drivers/iio/chemical/scd30_core.c
+
SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
M: Tomasz Duszynski
S: Maintained
diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
index 7f21afd73b1c..99e852b67e55 100644
--- a/drivers/iio/chemical/Kconfig
+++ b/drivers/iio/chemical/Kconfig
@@ -85,6 +85,17 @@ config PMS7003
To compile this driver as a module, choose M here: the module will
be called pms7003.
+config SCD30_CORE
+ tristate "SCD30 carbon dioxide sensor driver"
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say Y here to build support for the Sensirion SCD30 sensor with carbon
+ dioxide, relative humidity and temperature sensing capabilities.
+
+ To compile this driver as a module, choose M here: the module will
+ be called scd30_core.
+
config SENSIRION_SGP30
tristate "Sensirion SGPxx gas sensors"
depends on I2C
diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
index aba4167db745..c9804b041ecd 100644
--- a/drivers/iio/chemical/Makefile
+++ b/drivers/iio/chemical/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_BME680_SPI) += bme680_spi.o
obj-$(CONFIG_CCS811) += ccs811.o
obj-$(CONFIG_IAQCORE) += ams-iaq-core.o
obj-$(CONFIG_PMS7003) += pms7003.o
+obj-$(CONFIG_SCD30_CORE) += scd30_core.o
obj-$(CONFIG_SENSIRION_SGP30) += sgp30.o
obj-$(CONFIG_SPS30) += sps30.o
obj-$(CONFIG_VZ89X)+= vz89x.o
diff --git a/drivers/iio/chemical/scd30.h b/drivers/iio/chemical/scd30.h
new file mode 100644
index ..38dcf5647d7f
--- /dev/null
+++ b/drivers/iio/chemical/scd30.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _SCD30_H
+#define _SCD30_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct scd30_state;
+
+enum scd30_cmd {
+ /* start continuous measurement with pressure compensation */
+ CMD_START_MEAS,
+ /* stop continuous measurement */
+ CMD_STOP_MEAS,
+ /* set/get measurement interval */
+ CMD_MEAS_INTERVAL,
+ /* check whether new measurement is ready */
+ CMD_MEAS_READY,
+ /* get measurement */
+ CMD_READ_MEAS,
+ /* turn on/off automatic self
[PATCH v3 3/4] iio: chemical: scd30: add serial interface driver
Add serial interface driver for the SCD30 sensor.
Signed-off-by: Tomasz Duszynski
---
MAINTAINERS | 1 +
drivers/iio/chemical/Kconfig| 11 ++
drivers/iio/chemical/Makefile | 1 +
drivers/iio/chemical/scd30_serial.c | 266
4 files changed, 279 insertions(+)
create mode 100644 drivers/iio/chemical/scd30_serial.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 13aed3473b7e..5db4b446c8ba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15143,6 +15143,7 @@ S: Maintained
F: drivers/iio/chemical/scd30.h
F: drivers/iio/chemical/scd30_core.c
F: drivers/iio/chemical/scd30_i2c.c
+F: drivers/iio/chemical/scd30_serial.c
SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
M: Tomasz Duszynski
diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
index 970d34888c2e..10bb431bc3ce 100644
--- a/drivers/iio/chemical/Kconfig
+++ b/drivers/iio/chemical/Kconfig
@@ -107,6 +107,17 @@ config SCD30_I2C
To compile this driver as a module, choose M here: the module will
be called scd30_i2c.
+config SCD30_SERIAL
+ tristate "SCD30 carbon dioxide sensor serial driver"
+ depends on SCD30_CORE && SERIAL_DEV_BUS
+ select CRC16
+ help
+ Say Y here to build support for the Sensirion SCD30 serial interface
+ driver.
+
+ To compile this driver as a module, choose M here: the module will
+ be called scd30_serial.
+
config SENSIRION_SGP30
tristate "Sensirion SGPxx gas sensors"
depends on I2C
diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
index 0966ca34e34b..fef63dd5bf92 100644
--- a/drivers/iio/chemical/Makefile
+++ b/drivers/iio/chemical/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_IAQCORE) += ams-iaq-core.o
obj-$(CONFIG_PMS7003) += pms7003.o
obj-$(CONFIG_SCD30_CORE) += scd30_core.o
obj-$(CONFIG_SCD30_I2C) += scd30_i2c.o
+obj-$(CONFIG_SCD30_SERIAL) += scd30_serial.o
obj-$(CONFIG_SENSIRION_SGP30) += sgp30.o
obj-$(CONFIG_SPS30) += sps30.o
obj-$(CONFIG_VZ89X)+= vz89x.o
diff --git a/drivers/iio/chemical/scd30_serial.c
b/drivers/iio/chemical/scd30_serial.c
new file mode 100644
index ..07d7d3110fe0
--- /dev/null
+++ b/drivers/iio/chemical/scd30_serial.c
@@ -0,0 +1,266 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sensirion SCD30 carbon dioxide sensor serial driver
+ *
+ * Copyright (c) 2020 Tomasz Duszynski
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "scd30.h"
+
+#define SCD30_SERDEV_ADDR 0x61
+#define SCD30_SERDEV_WRITE 0x06
+#define SCD30_SERDEV_READ 0x03
+#define SCD30_SERDEV_MAX_BUF_SIZE 17
+#define SCD30_SERDEV_RX_HEADER_SIZE 3
+#define SCD30_SERDEV_CRC_SIZE 2
+#define SCD30_SERDEV_TIMEOUT msecs_to_jiffies(200)
+
+struct scd30_serdev_priv {
+ struct completion meas_ready;
+ char *buf;
+ int num_expected;
+ int num;
+};
+
+static u16 scd30_serdev_cmd_lookup_tbl[] = {
+ [CMD_START_MEAS] = 0x0036,
+ [CMD_STOP_MEAS] = 0x0037,
+ [CMD_MEAS_INTERVAL] = 0x0025,
+ [CMD_MEAS_READY] = 0x0027,
+ [CMD_READ_MEAS] = 0x0028,
+ [CMD_ASC] = 0x003a,
+ [CMD_FRC] = 0x0039,
+ [CMD_TEMP_OFFSET] = 0x003b,
+ [CMD_FW_VERSION] = 0x0020,
+ [CMD_RESET] = 0x0034,
+};
+
+static u16 scd30_serdev_calc_crc(const char *buf, int size)
+{
+ return crc16(0x, buf, size);
+}
+
+static int scd30_serdev_xfer(struct scd30_state *state, char *txbuf, int
txsize,
+char *rxbuf, int rxsize)
+{
+ struct serdev_device *serdev = to_serdev_device(state->dev);
+ struct scd30_serdev_priv *priv = state->priv;
+ int ret;
+
+ priv->buf = rxbuf;
+ priv->num_expected = rxsize;
+ priv->num = 0;
+
+ ret = serdev_device_write(serdev, txbuf, txsize, SCD30_SERDEV_TIMEOUT);
+ if (ret < txsize)
+ return ret < 0 ? ret : -EIO;
+
+ ret = wait_for_completion_interruptible_timeout(>meas_ready,
+ SCD30_SERDEV_TIMEOUT);
+ if (ret > 0)
+ ret = 0;
+ else if (!ret)
+ ret = -ETIMEDOUT;
+
+ return ret;
+}
+
+static int scd30_serdev_command(struct scd30_state *state, enum scd30_cmd cmd,
+ u16 arg, void *response, int size)
+{
+ /*
+* Communication over serial line is based on modbus protocol (or rather
+* its variation called modbus over serial to be precise). Upon
+* receiving a request device should reply with response.
+*
+* Frame below represents a request message. Each field takes
+* exactly one byte.
+*
+* +--+--+-+-+---+---+-+-+
+* | dev | op | reg | reg | byte1 | byte0 | crc | crc |
+* | addr | code | msb |
[PATCH v3 4/4] dt-bindings: iio: scd30: add device binding file
Add SCD30 sensor binding file.
Signed-off-by: Tomasz Duszynski
---
.../iio/chemical/sensirion,scd30.yaml | 68 +++
MAINTAINERS | 1 +
2 files changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml
diff --git
a/Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml
b/Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml
new file mode 100644
index ..40d87346ff4c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/chemical/sensirion,scd30.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sensirion SCD30 carbon dioxide sensor
+
+maintainers:
+ - Tomasz Duszynski
+
+description: |
+ Air quality sensor capable of measuring co2 concentration, temperature
+ and relative humidity.
+
+properties:
+ compatible:
+enum:
+ - sensirion,scd30
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ vdd-supply: true
+
+ sensirion,sel-gpios:
+description: GPIO connected to the SEL line
+maxItems: 1
+
+ sensirion,pwm-gpios:
+description: GPIO connected to the PWM line
+maxItems: 1
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+# include
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ co2-sensor@61 {
+compatible = "sensirion,scd30";
+reg = <0x61>;
+vdd-supply = <>;
+interrupt-parent = <>;
+interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ };
+};
+ - |
+# include
+serial {
+ co2-sensor {
+compatible = "sensirion,scd30";
+vdd-supply = <>;
+interrupt-parent = <>;
+interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+ };
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 5db4b446c8ba..0ab9cf39e051 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15140,6 +15140,7 @@ F: include/uapi/linux/phantom.h
SENSIRION SCD30 CARBON DIOXIDE SENSOR DRIVER
M: Tomasz Duszynski
S: Maintained
+F: Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml
F: drivers/iio/chemical/scd30.h
F: drivers/iio/chemical/scd30_core.c
F: drivers/iio/chemical/scd30_i2c.c
--
2.26.2
Re: [PATCH v3 0/4] Add support for SCD30 sensor
On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski wrote: > > Following series adds support for Sensirion SCD30 sensor module capable of > measuring carbon dioxide, temperature and relative humidity. CO2 measurements > base on NDIR principle while temperature and relative humidity are measured by > the on board SHT31. As for sensor communication, both I2C and serial > interfaces > are supported. Btw, since we have relaxed 80 limit to 100, I recommend to reconsider some lines to be joined. -- With Best Regards, Andy Shevchenko
Re: [PATCH] Documentation: kunit: Add some troubleshooting tips to the FAQ
On Mon, 1 Jun 2020, David Gow wrote: > Add an FAQ entry to the KUnit documentation with some tips for > troubleshooting KUnit and kunit_tool. > > These suggestions largely came from an email thread: > https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b94...@intel.com/T/#m23213d4e156db6d59b0b460a9014950f5ff6eb03 > > Signed-off-by: David Gow > --- > Documentation/dev-tools/kunit/faq.rst | 32 +++ > 1 file changed, 32 insertions(+) > > diff --git a/Documentation/dev-tools/kunit/faq.rst > b/Documentation/dev-tools/kunit/faq.rst > index ea55b2467653..40109d425988 100644 > --- a/Documentation/dev-tools/kunit/faq.rst > +++ b/Documentation/dev-tools/kunit/faq.rst > @@ -61,3 +61,35 @@ test, or an end-to-end test. >kernel by installing a production configuration of the kernel on production >hardware with a production userspace and then trying to exercise some > behavior >that depends on interactions between the hardware, the kernel, and > userspace. > + > +KUnit isn't working, what should I do? > +== > + > +Unfortunately, there are a number of things which can break, but here are > some > +things to try. > + > +1. Try running ``./tools/testing/kunit/kunit.py run`` with the > ``--raw_output`` > + parameter. This might show details or error messages hidden by the > kunit_tool > + parser. > +2. Instead of running ``kunit.py run``, try running ``kunit.py config``, > + ``kunit.py build``, and ``kunit.py exec`` independently. This can help > track > + down where an issue is occurring. (If you think the parser is at fault, > you > + can run it manually against stdin or a file with ``kunit.py parse``.) > +3. Running the UML kernel directly can often reveal issues or error messages > + kunit_tool ignores. This should be as simple as running ``./vmlinux`` > after > + building the UML kernel (e.g., by using ``kunit.py build``). Note that UML > + has some unusual requirements (such as the host having a tmpfs filesystem > + mounted), and has had issues in the past when built statically and the > host > + has KASLR enabled. (On older host kernels, you may need to run ``setarch > + `uname -m` -R ./vmlinux`` to disable KASLR.) > +4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test > + (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config > + around, so you can see what config was used after running ``kunit.py > run``. > + It also preserves any config changes you might make, so you can > + enable/disable things with ``make ARCH=um menuconfig`` or similar, and > then > + re-run kunit_tool. > +5. Finally, running ``make ARCH=um defconfig`` before running ``kunit.py > run`` > + may help clean up any residual config items which could be causing > problems. > + Looks great! Could we add something like: 6. Try running kunit standalone (without UML). KUnit and associated tests can be built into a standard kernel or built as a module; doing so allows us to verify test behaviour independent of UML so can be useful to do if running under UML is failing. When tests are built-in they will execute on boot, and modules will automatically execute associated tests when loaded. Test results can be collected from /sys/kernel/debug/kunit//results. For more details see "KUnit on non-UML architectures" in :doc:`usage`. Reviewed-by: Alan Maguire
4.9.0+4.19.0: Bug in megasas driver (?), if booting from USB stick
Hello kernel hackers, I've this "funny" problem: if I netboot servers via the firmware in the network card, the system comes up normal. If I boot iPXE from a usb stick and then netboot, the megasas driver fails to init (call trace below, full dmesg attached). The system also hangs during the init for probably 30 seconds. Same kernel, same kernel parameters, same OS. I can reproduce this on Dell R815, Dell R710 with 3.5" disks, but not on Dell R710 with 2.5" disk slots. I can also reproduce this with 4.9.0-11-amd64 and 4.19.0-9-amd64 (current Debian Buster). Does anyone have an idea what the influence booting from an USB stick can have on the megasas controller? In these boxes there is a Perc H700 and I've seen the same behaviour with Perc H800 as well. I played with edd=off (which is required for some R710s), but that does not fix the problem. Any pointers are much appreciated. Best regards, Nico dmesg-r815 Description: Binary data [ 264.944087] megaraid_sas :05:00.0: Failed to init firmware [ 264.946621] [ cut here ] [ 264.946677] WARNING: CPU: 0 PID: 827 at /build/linux-XzZAcJ/linux-4.9.189/kernel/irq/manage.c:1493 __free_irq+0xa2/0x280 [ 264.946776] Trying to free already-free IRQ 180 [ 264.946821] Modules linked in: sd_mod joydev uas usb_storage hid_generic usbhid hid sg sr_mod cdrom ipmi_devintf evdev dcdbas amd64_edac_mod edac_mce_amd edac_core ahci libahci kvm_amd kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ohci_pci megaraid_sas(+) ixgbe ghash_clmulni_intel ptp libata pps_core mdio mgag200 ohci_hcd aesni_intel aes_x86_64 ttm lrw drm_kms_helper ehci_pci gf128mul dca glue_helper bnx2 sp5100_tco ablk_helper psmouse ehci_hcd pcspkr serio_raw drm cryptd fam15h_power i2c_algo_bit k10temp i2c_piix4 usbcore ipmi_si scsi_mod usb_common shpchp ipmi_msghandler acpi_power_meter button [ 264.947638] CPU: 0 PID: 827 Comm: kworker/0:2 Not tainted 4.9.0-11-amd64 #1 Debian 4.9.189-3 [ 264.947716] Hardware name: Dell Inc. PowerEdge R815/04Y8PT, BIOS 3.2.2 09/15/2014 [ 264.947791] Workqueue: events work_for_cpu_fn [ 264.947839] 8ef353d4 a83e7353bc30 [ 264.947927] 8ec7a83b 00b4 a83e7353bc88 9d3bd2731200 [ 264.948013] 00b4 9d3bd27312d4 0246 8ec7a8bf [ 264.948099] Call Trace: [ 264.948136] [] ? dump_stack+0x5c/0x78 [ 264.948190] [] ? __warn+0xcb/0xf0 [ 264.948242] [] ? warn_slowpath_fmt+0x5f/0x80 [ 264.948313] [] ? megasas_free_cmds+0x48/0x70 [megaraid_sas] [ 264.948384] [] ? __free_irq+0xa2/0x280 [ 264.948438] [] ? free_irq+0x37/0x90 [ 264.948498] [] ? megasas_destroy_irqs+0x45/0x80 [megaraid_sas] [ 264.948578] [] ? megasas_probe_one+0xa05/0x1d30 [megaraid_sas] [ 264.948652] [] ? __kthread_create_on_node+0x132/0x180 [ 264.948721] [] ? check_preempt_wakeup+0x103/0x210 [ 264.948785] [] ? local_pci_probe+0x44/0xa0 [ 264.948842] [] ? work_for_cpu_fn+0x16/0x20 [ 264.948899] [] ? process_one_work+0x18a/0x430 [ 264.948958] [] ? worker_thread+0x1ca/0x490 [ 264.949016] [] ? process_one_work+0x430/0x430 [ 264.949078] [] ? kthread+0xd9/0xf0 [ 264.949130] [] ? kthread_park+0x60/0x60 [ 264.949188] [] ? ret_from_fork+0x44/0x70 [ 264.949243] ---[ end trace 277700523668533a ]--- -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
Re: [PATCH v1] PCI: controller: convert to devm_platform_ioremap_resource_byname()
On Mon, Jun 01, 2020 at 04:22:29PM -0600, Rob Herring wrote:
> On Mon, Jun 01, 2020 at 10:33:45PM +0800, Dejin Zheng wrote:
> > Use devm_platform_ioremap_resource_byname() to simplify codes.
> > it contains platform_get_resource_byname() and devm_ioremap_resource().
> >
> > Signed-off-by: Dejin Zheng
> > ---
> > drivers/pci/controller/cadence/pcie-cadence-ep.c | 3 +--
> > drivers/pci/controller/cadence/pcie-cadence-host.c | 3 +--
> > drivers/pci/controller/pci-tegra.c | 8 +++-
> > drivers/pci/controller/pci-xgene.c | 3 +--
> > drivers/pci/controller/pcie-altera-msi.c | 3 +--
> > drivers/pci/controller/pcie-altera.c | 9 +++--
> > drivers/pci/controller/pcie-mediatek.c | 4 +---
> > drivers/pci/controller/pcie-rockchip.c | 5 ++---
> > drivers/pci/controller/pcie-xilinx-nwl.c | 7 +++
> > 9 files changed, 16 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c
> > b/drivers/pci/controller/cadence/pcie-cadence-ep.c
> > index 1c15c8352125..74ffa03fde5f 100644
> > --- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
> > +++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
> > @@ -408,8 +408,7 @@ int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
> >
> > pcie->is_rc = false;
> >
> > - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "reg");
> > - pcie->reg_base = devm_ioremap_resource(dev, res);
> > + pcie->reg_base = devm_platform_ioremap_resource_byname(pdev, "reg");
> > if (IS_ERR(pcie->reg_base)) {
> > dev_err(dev, "missing \"reg\"\n");
> > return PTR_ERR(pcie->reg_base);
> > diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
> > b/drivers/pci/controller/cadence/pcie-cadence-host.c
> > index 8c2543f28ba0..dcc460a54875 100644
> > --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
> > +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
> > @@ -225,8 +225,7 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
> > rc->device_id = 0x;
> > of_property_read_u32(np, "device-id", >device_id);
> >
> > - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "reg");
> > - pcie->reg_base = devm_ioremap_resource(dev, res);
> > + pcie->reg_base = devm_platform_ioremap_resource_byname(pdev, "reg");
> > if (IS_ERR(pcie->reg_base)) {
> > dev_err(dev, "missing \"reg\"\n");
> > return PTR_ERR(pcie->reg_base);
> > diff --git a/drivers/pci/controller/pci-tegra.c
> > b/drivers/pci/controller/pci-tegra.c
> > index e3e917243e10..3e608383df66 100644
> > --- a/drivers/pci/controller/pci-tegra.c
> > +++ b/drivers/pci/controller/pci-tegra.c
> > @@ -1462,7 +1462,7 @@ static int tegra_pcie_get_resources(struct tegra_pcie
> > *pcie)
> > {
> > struct device *dev = pcie->dev;
> > struct platform_device *pdev = to_platform_device(dev);
> > - struct resource *pads, *afi, *res;
> > + struct resource *res;
> > const struct tegra_pcie_soc *soc = pcie->soc;
> > int err;
> >
> > @@ -1486,15 +1486,13 @@ static int tegra_pcie_get_resources(struct
> > tegra_pcie *pcie)
> > }
> > }
> >
> > - pads = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pads");
> > - pcie->pads = devm_ioremap_resource(dev, pads);
> > + pcie->pads = devm_platform_ioremap_resource_byname(pdev, "pads");
> > if (IS_ERR(pcie->pads)) {
> > err = PTR_ERR(pcie->pads);
> > goto phys_put;
> > }
> >
> > - afi = platform_get_resource_byname(pdev, IORESOURCE_MEM, "afi");
> > - pcie->afi = devm_ioremap_resource(dev, afi);
> > + pcie->afi = devm_platform_ioremap_resource_byname(pdev, "afi");
> > if (IS_ERR(pcie->afi)) {
> > err = PTR_ERR(pcie->afi);
> > goto phys_put;
> > diff --git a/drivers/pci/controller/pci-xgene.c
> > b/drivers/pci/controller/pci-xgene.c
> > index d1efa8ffbae1..1431a18eb02c 100644
> > --- a/drivers/pci/controller/pci-xgene.c
> > +++ b/drivers/pci/controller/pci-xgene.c
> > @@ -355,8 +355,7 @@ static int xgene_pcie_map_reg(struct xgene_pcie_port
> > *port,
> > if (IS_ERR(port->csr_base))
> > return PTR_ERR(port->csr_base);
> >
> > - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
> > - port->cfg_base = devm_ioremap_resource(dev, res);
> > + port->cfg_base = devm_platform_ioremap_resource_byname(pdev, "cfg");
> > if (IS_ERR(port->cfg_base))
> > return PTR_ERR(port->cfg_base);
> > port->cfg_addr = res->start;
> > diff --git a/drivers/pci/controller/pcie-altera-msi.c
> > b/drivers/pci/controller/pcie-altera-msi.c
> > index 16d938920ca5..613e19af71bd 100644
> > --- a/drivers/pci/controller/pcie-altera-msi.c
> > +++ b/drivers/pci/controller/pcie-altera-msi.c
> > @@ -228,8 +228,7 @@ static int altera_msi_probe(struct platform_device
> > *pdev)
> > mutex_init(>lock);
> > msi->pdev = pdev;
> >
> > -
[GIT PULL] vfs: improve DAX behavior for 5.8, part 1
Hi Linus, After many years of LKML-wrangling about how to enable programs to query and influence the file data access mode (DAX) when a filesystem resides on storage devices such as persistent memory, Ira Weiny has emerged with a proposed set of standard behaviors that has not been shot down by anyone! We're more or less standardizing on the current XFS behavior and adapting ext4 to do the same. This pull request is the first of a handful that will make ext4 and XFS present a consistent interface for user programs that care about DAX. We add a statx attribute that programs can check to see if DAX is enabled on a particular file. Then, we update the DAX documentation to spell out the user-visible behaviors that filesystems will guarantee (until the next storage industry shakeup). The on-disk inode flag has been in XFS for a few years now. Note that Stephen Rothwell reported a minor merge conflict[1] between the first cleanup patch and a different change in the block layer. The resolution looks pretty straightforward, but let me know if you encounter problems. --D [1] https://lore.kernel.org/linux-next/20200522145848.38cdc...@canb.auug.org.au/ The following changes since commit 0e698dfa282211e414076f9dc7e83c1c288314fd: Linux 5.7-rc4 (2020-05-03 14:56:04 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/vfs-5.8-merge-1 for you to fetch changes up to 83d9088659e8f113741bb197324bd9554d159657: Documentation/dax: Update Usage section (2020-05-04 08:49:39 -0700) New code for 5.8: - Clean up io_is_direct. - Add a new statx flag to indicate when file data access is being done via DAX (as opposed to the page cache). - Update the documentation for how system administrators and application programmers can take advantage of the (still experimental DAX) feature. Ira Weiny (3): fs: Remove unneeded IS_DAX() check in io_is_direct() fs/stat: Define DAX statx attribute Documentation/dax: Update Usage section Documentation/filesystems/dax.txt | 142 +- drivers/block/loop.c | 6 +- fs/stat.c | 3 + include/linux/fs.h| 7 +- include/uapi/linux/stat.h | 1 + 5 files changed, 147 insertions(+), 12 deletions(-)
Re: [PATCH net-next v2] af-packet: new flag to indicate all csums are good
On 02-06-2020 16:29, Willem de Bruijn wrote:
> On Tue, Jun 2, 2020 at 4:05 AM Victor Julien wrote:
>>
>> Introduce a new flag (TP_STATUS_CSUM_UNNECESSARY) to indicate
>> that the driver has completely validated the checksums in the packet.
>>
>> The TP_STATUS_CSUM_UNNECESSARY flag differs from TP_STATUS_CSUM_VALID
>> in that the new flag will only be set if all the layers are valid,
>> while TP_STATUS_CSUM_VALID is set as well if only the IP layer is valid.
>
> transport, not ip checksum.
Allow me a n00b question: what does transport refer to here? Things like
ethernet? It isn't clear to me from the doc.
(happy to follow up with a patch to clarify the doc when I understand
things better)
> But as I understand it drivers set CHECKSUM_COMPLETE if they fill in
> skb->csum over the full length of the packet. This does not
> necessarily imply that any of the checksum fields in the packet are
> valid yet (see also skb->csum_valid). Protocol code later compares
> checksum fields against this using __skb_checksum_validate_complete and
> friends.
>
> But packet sockets may be called before any of this, however. So I wonder
> how valid the checksum really is right now when setting TP_STATUS_CSUM_VALID.
> I assume it's correct, but don't fully understand where the validation
> has taken place..
I guess I'm more confused now about what TP_STATUS_CSUM_VALID actually
means. It sounds almost like the opposite of TP_STATUS_CSUMNOTREADY, but
I'm not sure I understand what the value would be.
It would be great if someone could help clear this up. Everything I
thought I knew/understood so far has been proven wrong, so I'm not too
confident about my patch anymore...
> Similar to commit 682f048bd494 ("af_packet: pass checksum validation
> status to the user"), please update tpacket_rcv and packet_rcv.
Ah yes, good catch. Will add it there as well.
> Note also that net-next is currently closed.
Should I hold off on sending a v3 until it reopens?
Regards / Groeten,
Victor
>
>
>
>> for convenience there are also the following defines::
>>
>> diff --git a/include/uapi/linux/if_packet.h b/include/uapi/linux/if_packet.h
>> index 3d884d68eb30..76a5c762e2e0 100644
>> --- a/include/uapi/linux/if_packet.h
>> +++ b/include/uapi/linux/if_packet.h
>> @@ -113,6 +113,7 @@ struct tpacket_auxdata {
>> #define TP_STATUS_BLK_TMO (1 << 5)
>> #define TP_STATUS_VLAN_TPID_VALID (1 << 6) /* auxdata has valid
>> tp_vlan_tpid */
>> #define TP_STATUS_CSUM_VALID (1 << 7)
>> +#define TP_STATUS_CSUM_UNNECESSARY (1 << 8)
>>
>> /* Tx ring - header status */
>> #define TP_STATUS_AVAILABLE 0
>> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
>> index 29bd405adbbd..94e213537646 100644
>> --- a/net/packet/af_packet.c
>> +++ b/net/packet/af_packet.c
>> @@ -2215,10 +2215,13 @@ static int tpacket_rcv(struct sk_buff *skb, struct
>> net_device *dev,
>>
>> if (skb->ip_summed == CHECKSUM_PARTIAL)
>> status |= TP_STATUS_CSUMNOTREADY;
>> - else if (skb->pkt_type != PACKET_OUTGOING &&
>> -(skb->ip_summed == CHECKSUM_COMPLETE ||
>> - skb_csum_unnecessary(skb)))
>> - status |= TP_STATUS_CSUM_VALID;
>> + else if (skb->pkt_type != PACKET_OUTGOING) {
>> + if (skb->ip_summed == CHECKSUM_UNNECESSARY)
>> + status |= TP_STATUS_CSUM_UNNECESSARY |
>> TP_STATUS_CSUM_VALID;
>> + else if (skb->ip_summed == CHECKSUM_COMPLETE ||
>> +skb_csum_unnecessary(skb))
>> + status |= TP_STATUS_CSUM_VALID;
>> + }
>>
>> if (snaplen > res)
>> snaplen = res;
>> --
>> 2.17.1
>>
--
-
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
-
Re: [PATCH] arch/x86: reset MXCSR to default in kernel_fpu_begin()
On Tue, Jun 2, 2020 at 3:56 AM Borislav Petkov wrote: > > Hi, > > On Tue, Jun 02, 2020 at 01:29:51PM +0300, Petteri Aimonen wrote: > > The kernel module is not actually x86-specific, even though it is > > currently only enabled for x86. amdgpu driver already does kernel mode > > floating point operations on PPC64 also, and the same module could be > > used to test the same thing there. > > Then make it generic please and put the user portion in, say, > tools/testing/selftests/fpu/ and we can ask ppc people to test it too. > People might wanna add more stuff to it in the future, which would be > good. > > > To deterministically trigger the bug, the syscall has to come from the > > same thread that has modified MXCSR. Going through /usr/sbin/modprobe > > won't work, and manually doing the necessary syscalls for module loading > > seems too complicated. > > Ok, fair enough. But put that file in debugfs pls. I think I agree. While it would be delightful to have general selftest tooling for kernel modules, we don't have that right now, and having the test just work with an appropriately configured kernel would be nice. How about putting the file you frob in /sys/kernel/debug/selftest_helpers/something_or_other. The idea would be that /sys/kernel/debug/selftest_helpers would be a general place for kernel helpers needed to make selftests work. --Andy
Re: [PATCH v3 3/4] iio: chemical: scd30: add serial interface driver
On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski
wrote:
>
> Add serial interface driver for the SCD30 sensor.
...
> +static u16 scd30_serdev_cmd_lookup_tbl[] = {
> + [CMD_START_MEAS] = 0x0036,
> + [CMD_STOP_MEAS] = 0x0037,
> + [CMD_MEAS_INTERVAL] = 0x0025,
> + [CMD_MEAS_READY] = 0x0027,
> + [CMD_READ_MEAS] = 0x0028,
> + [CMD_ASC] = 0x003a,
> + [CMD_FRC] = 0x0039,
> + [CMD_TEMP_OFFSET] = 0x003b,
> + [CMD_FW_VERSION] = 0x0020,
> + [CMD_RESET] = 0x0034,
Hmm... Can't we keep them ordered by value?
> +};
...
> + ret = wait_for_completion_interruptible_timeout(>meas_ready,
> + SCD30_SERDEV_TIMEOUT);
> + if (ret > 0)
> + ret = 0;
> + else if (!ret)
> + ret = -ETIMEDOUT;
> +
> + return ret;
Perhaps
if (ret < 0)
return ret;
if (ret == 0)
return -ETIMEDOUT;
return 0;
?
...
> + char txbuf[SCD30_SERDEV_MAX_BUF_SIZE] = { SCD30_SERDEV_ADDR },
> +rxbuf[SCD30_SERDEV_MAX_BUF_SIZE], *rsp = response;
Please, apply type to each variable separately.
...
> + switch (txbuf[1]) {
> + case SCD30_SERDEV_WRITE:
> + if (memcmp(txbuf, txbuf, txsize)) {
I'm not sure I understand this.
> + dev_err(state->dev, "wrong message received\n");
> + return -EIO;
> + }
> + break;
> + case SCD30_SERDEV_READ:
> + if (rxbuf[2] != (rxsize -
> +SCD30_SERDEV_RX_HEADER_SIZE -
> +SCD30_SERDEV_CRC_SIZE)) {
Perhaps you can come up with better indentation/ line split?
> + dev_err(state->dev,
> + "received data size does not match header\n");
> + return -EIO;
> + }
> +
> + rxsize -= SCD30_SERDEV_CRC_SIZE;
> + crc = get_unaligned_le16(rxbuf + rxsize);
> + if (crc != scd30_serdev_calc_crc(rxbuf, rxsize)) {
> + dev_err(state->dev, "data integrity check failed\n");
> + return -EIO;
> + }
> +
> + rxsize -= SCD30_SERDEV_RX_HEADER_SIZE;
> + memcpy(rsp, rxbuf + SCD30_SERDEV_RX_HEADER_SIZE, rxsize);
> + break;
> + default:
> + dev_err(state->dev, "received unknown op code\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
...
> +static struct serdev_device_driver scd30_serdev_driver = {
> + .driver = {
> + .name = KBUILD_MODNAME,
This is not the best what we can do. The name is an ABI and better if
it will be constant (independent on file name).
> + .of_match_table = scd30_serdev_of_match,
> + .pm = _pm_ops,
> + },
> + .probe = scd30_serdev_probe,
> +};
--
With Best Regards,
Andy Shevchenko
RE: [PATCH 0/2] PCI: dwc: Add support to handle prefetchable memory separately
On Tue, Jun 2, 2020 at 11:9:38, Vidya Sagar wrote: > In this patch series, > Patch-1 > adds required infrastructure to deal with prefetchable memory region > information coming from 'ranges' property of the respective device-tree node > separately from non-prefetchable memory region information. > Patch-2 > Adds support to use ATU region-3 for establishing the mapping between CPU > addresses and PCIe bus addresses. > It also changes the logic to determine whether mapping is required or not by > checking both CPU address and PCIe bus address for both prefetchable and > non-prefetchable regions. If the addresses are same, then, it is understood > that 1:1 mapping is in place and there is no need to setup ATU mapping > whereas if the addresses are not the same, then, there is a need to setup ATU > mapping. This is certainly true for Tegra194 and what I heard from our HW > engineers is that it should generally be true for any DWC based implementation > also. > Hence, I request Synopsys folks (Jingoo Han & Gustavo Pimentel ??) to confirm > the same so that this particular patch won't cause any regressions for other > DWC based platforms. Hi Vidya, Unfortunately due to the COVID-19 lockdown, I can't access my development prototype setup to test your patch. It might take some while until I get the possibility to get access to it again. -Gustavo > > Vidya Sagar (2): > PCI: dwc: Add support to handle prefetchable memory separately > PCI: dwc: Use ATU region to map prefetchable memory region > > .../pci/controller/dwc/pcie-designware-host.c | 46 ++- > drivers/pci/controller/dwc/pcie-designware.c | 6 ++- > drivers/pci/controller/dwc/pcie-designware.h | 8 +++- > 3 files changed, 45 insertions(+), 15 deletions(-) > > -- > 2.17.1
R: [PATCH v5 11/11] PCI: qcom: Add Force GEN1 support
> On Tue, Jun 02, 2020 at 01:53:52PM +0200, Ansuel Smith wrote:
> > From: Sham Muthayyan
> >
> > Add Force GEN1 support needed in some ipq8064 board that needs to
> limit
> > some PCIe line to gen1 for some hardware limitation. This is set by the
> > max-link-speed binding and needed by some soc based on ipq8064. (for
> > example Netgear R7800 router)
> >
> > Signed-off-by: Sham Muthayyan
> > Signed-off-by: Ansuel Smith
> > Reviewed-by: Rob Herring
> > ---
> > drivers/pci/controller/dwc/pcie-qcom.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> b/drivers/pci/controller/dwc/pcie-qcom.c
> > index 259b627bf890..0ce15d53c46e 100644
> > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > @@ -27,6 +27,7 @@
> > #include
> > #include
> >
> > +#include "../../pci.h"
> > #include "pcie-designware.h"
> >
> > #define PCIE20_PARF_SYS_CTRL 0x00
> > @@ -99,6 +100,8 @@
> > #define PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE 0x358
> > #define SLV_ADDR_SPACE_SZ 0x1000
> >
> > +#define PCIE20_LNK_CONTROL2_LINK_STATUS2 0xa0
> > +
> > #define DEVICE_TYPE_RC 0x4
> >
> > #define QCOM_PCIE_2_1_0_MAX_SUPPLY 3
> > @@ -195,6 +198,7 @@ struct qcom_pcie {
> > struct phy *phy;
> > struct gpio_desc *reset;
> > const struct qcom_pcie_ops *ops;
> > + int gen;
> > };
> >
> > #define to_qcom_pcie(x)dev_get_drvdata((x)->dev)
> > @@ -395,6 +399,11 @@ static int qcom_pcie_init_2_1_0(struct
> qcom_pcie *pcie)
> > /* wait for clock acquisition */
> > usleep_range(1000, 1500);
> >
> > + if (pcie->gen == 1) {
> > + val = readl(pci->dbi_base +
> PCIE20_LNK_CONTROL2_LINK_STATUS2);
> > + val |= 1;
>
> Is this the same bit that's visible in config space as
> PCI_EXP_LNKSTA_CLS_2_5GB? Why not use that #define?
>
> There are a bunch of other #defines in this file that look like
> redefinitions of standard things:
>
> #define PCIE20_COMMAND_STATUS 0x04
> Looks like PCI_COMMAND
>
> #define CMD_BME_VAL 0x4
> Looks like PCI_COMMAND_MASTER
>
> #define PCIE20_DEVICE_CONTROL2_STATUS2 0x98
> Looks like (PCIE20_CAP + PCI_EXP_DEVCTL2)
>
> #define PCIE_CAP_CPL_TIMEOUT_DISABLE0x10
> Looks like PCI_EXP_DEVCTL2_COMP_TMOUT_DIS
>
> #define PCIE20_CAP 0x70
> This one is obviously device-specific
>
> #define PCIE20_CAP_LINK_CAPABILITIES(PCIE20_CAP + 0xC)
> Looks like (PCIE20_CAP + PCI_EXP_LNKCAP)
>
> #define PCIE20_CAP_ACTIVE_STATE_LINK_PM_SUPPORT (BIT(10) |
> BIT(11))
> Looks like PCI_EXP_LNKCAP_ASPMS
>
> #define PCIE20_CAP_LINK_1 (PCIE20_CAP + 0x14)
> #define PCIE_CAP_LINK1_VAL 0x2FD7F
> This looks like PCIE20_CAP_LINK_1 should be (PCIE20_CAP +
> PCI_EXP_SLTCAP), but "CAP_LINK_1" doesn't sound like the Slot
> Capabilities register, and I don't know what PCIE_CAP_LINK1_VAL
> means.
>
The define are used by ipq8074 and I really can't test the changes. Anyway
it shouldn't make a difference use the define instead of the custom value so
a patch should not harm anything... Problem is the last 2 define that we
really
don't know what they are about... How should I proceed? Change only the
value related to PCI_EXP_LNKSTA_CLS_2_5GB or change all the other except the
last 2?
> > + writel(val, pci->dbi_base +
> PCIE20_LNK_CONTROL2_LINK_STATUS2);
> > + }
> >
> > /* Set the Max TLP size to 2K, instead of using default of 4K */
> > writel(CFG_REMOTE_RD_REQ_BRIDGE_SIZE_2K,
> > @@ -1397,6 +1406,10 @@ static int qcom_pcie_probe(struct
> platform_device *pdev)
> > goto err_pm_runtime_put;
> > }
> >
> > + pcie->gen = of_pci_get_max_link_speed(pdev->dev.of_node);
> > + if (pcie->gen < 0)
> > + pcie->gen = 2;
> > +
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "parf");
> > pcie->parf = devm_ioremap_resource(dev, res);
> > if (IS_ERR(pcie->parf)) {
> > --
> > 2.25.1
> >
Re: [PATCH] x86/resctrl: Fix memory bandwidth counter width for AMD
Hi Babu, On 6/1/2020 4:00 PM, Babu Moger wrote: > Memory bandwidth is calculated reading the monitoring counter > at two intervals and calculating the delta. It is the software’s > responsibility to read the count often enough to avoid having > the count roll over _twice_ between reads. > > The current code hardcodes the bandwidth monitoring counter's width > to 24 bits for AMD. This is due to default base counter width which > is 24. Currently, AMD does not implement the CPUID 0xF.[ECX=1]:EAX > to adjust the counter width. But, the AMD hardware supports much > wider bandwidth counter with the default width of 44 bits. > > Kernel reads these monitoring counters every 1 second and adjusts the > counter value for overflow. With 24 bits and scale value of 64 for AMD, > it can only measure up to 1GB/s without overflowing. For the rates > above 1GB/s this will fail to measure the bandwidth. > > Fix the issue setting the default width to 44 bits by adjusting the > offset. > > AMD future products will implement the CPUID 0xF.[ECX=1]:EAX. > > Signed-off-by: Babu Moger There is no fixes tag but if I understand correctly this issue has been present since AMD support was added to resctrl. This fix builds on top of a recent feature addition and would thus not work for earlier kernels. Are you planning to create a different fix for earlier kernels? Reinette
Re: [PATCH v3 2/4] iio: chemical: scd30: add I2C interface driver
On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski
wrote:
>
> Add I2C interface driver for the SCD30 sensor.
...
> +static u16 scd30_i2c_cmd_lookup_tbl[] = {
> + [CMD_START_MEAS] = 0x0010,
> + [CMD_STOP_MEAS] = 0x0104,
> + [CMD_MEAS_INTERVAL] = 0x4600,
> + [CMD_MEAS_READY] = 0x0202,
> + [CMD_READ_MEAS] = 0x0300,
> + [CMD_ASC] = 0x5306,
> + [CMD_FRC] = 0x5204,
> + [CMD_TEMP_OFFSET] = 0x5403,
> + [CMD_FW_VERSION] = 0xd100,
> + [CMD_RESET] = 0xd304,
Keep sorted by value?
> +};
...
> + ret = i2c_master_send(client, txbuf, txsize);
> + if (ret != txsize)
> + return ret < 0 ? ret : -EIO;
Wouldn't be better
if (ret < 0)
return ret;
if (ret != txsize)
return -EIO;
?
> + if (!rxbuf)
> + return 0;
> +
> + ret = i2c_master_recv(client, rxbuf, rxsize);
> + if (ret != rxsize)
> + return ret < 0 ? ret : -EIO;
Ditto.
...
> +static int scd30_i2c_command(struct scd30_state *state, enum scd30_cmd cmd,
> +u16 arg, void *response, int size)
> +{
> + char crc, buf[SCD30_I2C_MAX_BUF_SIZE], *rsp = response;
> + int i, ret;
i -> offset ?
> + put_unaligned_be16(scd30_i2c_cmd_lookup_tbl[cmd], buf);
> + i = 2;
> +
> + if (rsp) {
> + /* each two bytes are followed by a crc8 */
> + size += size / 2;
> + } else {
> + put_unaligned_be16(arg, buf + i);
> + crc = crc8(scd30_i2c_crc8_tbl, buf + i, 2, CRC8_INIT_VALUE);
> + i += 2;
> + buf[i] = crc;
> + i += 1;
buf[offset++] = crc; ?
> + /* commands below don't take an argument */
> + if ((cmd == CMD_STOP_MEAS) || (cmd == CMD_RESET))
> + i -= 3;
> + }
> +
> + ret = scd30_i2c_xfer(state, buf, i, buf, size);
> + if (ret)
> + return ret;
> +
> + /* validate received data and strip off crc bytes */
> + for (i = 0; i < size; i += 3) {
> + crc = crc8(scd30_i2c_crc8_tbl, buf + i, 2, CRC8_INIT_VALUE);
> + if (crc != buf[i + 2]) {
> + dev_err(state->dev, "data integrity check failed\n");
> + return -EIO;
> + }
> +
> + *rsp++ = buf[i];
+ 0 (for the sake of consistency?
> + *rsp++ = buf[i + 1];
> + }
> +
> + return 0;
> +}
...
> +static struct i2c_driver scd30_i2c_driver = {
> + .driver = {
> + .name = KBUILD_MODNAME,
Better to hard code.
> + .of_match_table = scd30_i2c_of_match,
> + .pm = _pm_ops,
> + },
> + .probe_new = scd30_i2c_probe,
> +};
--
With Best Regards,
Andy Shevchenko
[PATCH v2] PCI: controller: convert to devm_platform_ioremap_resource_byname()
Use devm_platform_ioremap_resource_byname() to simplify codes.
it contains platform_get_resource_byname() and devm_ioremap_resource().
Signed-off-by: Dejin Zheng
---
v1 -> v2:
- Discard changes to the file drivers/pci/controller/pcie-xilinx-nwl.c
Due to my mistakes, my patch will modify pcie-xilinx-nwl.c,
but it still need to use the res variable, but
devm_platform_ioremap_resource_byname() funtion can't assign a
value to the variable res. kbuild test robot report it. Thanks
very much for kbuild test robot .
drivers/pci/controller/cadence/pcie-cadence-ep.c | 3 +--
drivers/pci/controller/cadence/pcie-cadence-host.c | 3 +--
drivers/pci/controller/pci-tegra.c | 8 +++-
drivers/pci/controller/pci-xgene.c | 3 +--
drivers/pci/controller/pcie-altera-msi.c | 3 +--
drivers/pci/controller/pcie-altera.c | 9 +++--
drivers/pci/controller/pcie-mediatek.c | 4 +---
drivers/pci/controller/pcie-rockchip.c | 5 ++---
8 files changed, 13 insertions(+), 25 deletions(-)
diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c
b/drivers/pci/controller/cadence/pcie-cadence-ep.c
index 1c15c8352125..74ffa03fde5f 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
@@ -408,8 +408,7 @@ int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
pcie->is_rc = false;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "reg");
- pcie->reg_base = devm_ioremap_resource(dev, res);
+ pcie->reg_base = devm_platform_ioremap_resource_byname(pdev, "reg");
if (IS_ERR(pcie->reg_base)) {
dev_err(dev, "missing \"reg\"\n");
return PTR_ERR(pcie->reg_base);
diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
b/drivers/pci/controller/cadence/pcie-cadence-host.c
index 8c2543f28ba0..dcc460a54875 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
@@ -225,8 +225,7 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
rc->device_id = 0x;
of_property_read_u32(np, "device-id", >device_id);
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "reg");
- pcie->reg_base = devm_ioremap_resource(dev, res);
+ pcie->reg_base = devm_platform_ioremap_resource_byname(pdev, "reg");
if (IS_ERR(pcie->reg_base)) {
dev_err(dev, "missing \"reg\"\n");
return PTR_ERR(pcie->reg_base);
diff --git a/drivers/pci/controller/pci-tegra.c
b/drivers/pci/controller/pci-tegra.c
index e3e917243e10..3e608383df66 100644
--- a/drivers/pci/controller/pci-tegra.c
+++ b/drivers/pci/controller/pci-tegra.c
@@ -1462,7 +1462,7 @@ static int tegra_pcie_get_resources(struct tegra_pcie
*pcie)
{
struct device *dev = pcie->dev;
struct platform_device *pdev = to_platform_device(dev);
- struct resource *pads, *afi, *res;
+ struct resource *res;
const struct tegra_pcie_soc *soc = pcie->soc;
int err;
@@ -1486,15 +1486,13 @@ static int tegra_pcie_get_resources(struct tegra_pcie
*pcie)
}
}
- pads = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pads");
- pcie->pads = devm_ioremap_resource(dev, pads);
+ pcie->pads = devm_platform_ioremap_resource_byname(pdev, "pads");
if (IS_ERR(pcie->pads)) {
err = PTR_ERR(pcie->pads);
goto phys_put;
}
- afi = platform_get_resource_byname(pdev, IORESOURCE_MEM, "afi");
- pcie->afi = devm_ioremap_resource(dev, afi);
+ pcie->afi = devm_platform_ioremap_resource_byname(pdev, "afi");
if (IS_ERR(pcie->afi)) {
err = PTR_ERR(pcie->afi);
goto phys_put;
diff --git a/drivers/pci/controller/pci-xgene.c
b/drivers/pci/controller/pci-xgene.c
index d1efa8ffbae1..1431a18eb02c 100644
--- a/drivers/pci/controller/pci-xgene.c
+++ b/drivers/pci/controller/pci-xgene.c
@@ -355,8 +355,7 @@ static int xgene_pcie_map_reg(struct xgene_pcie_port *port,
if (IS_ERR(port->csr_base))
return PTR_ERR(port->csr_base);
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg");
- port->cfg_base = devm_ioremap_resource(dev, res);
+ port->cfg_base = devm_platform_ioremap_resource_byname(pdev, "cfg");
if (IS_ERR(port->cfg_base))
return PTR_ERR(port->cfg_base);
port->cfg_addr = res->start;
diff --git a/drivers/pci/controller/pcie-altera-msi.c
b/drivers/pci/controller/pcie-altera-msi.c
index 16d938920ca5..613e19af71bd 100644
--- a/drivers/pci/controller/pcie-altera-msi.c
+++ b/drivers/pci/controller/pcie-altera-msi.c
@@ -228,8 +228,7 @@ static int altera_msi_probe(struct platform_device *pdev)
mutex_init(>lock);
msi->pdev = pdev;
- res =
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On Tue, Jun 2, 2020 at 9:33 AM Al Viro wrote: > > > > > It's not clear whether we need a new API, I think __uaccess_being() has the > > assumption that the address has been validated by access_ok(). > > __uaccess_begin() is a stopgap, not a public API. Correct. It's just an x86 implementation detail. > The problem is real, but "let's add a public API that would do > user_access_begin() > with access_ok() already done" is no-go. Yeah, it's completely pointless. The solution to this is easy: remove the incorrect and useless early "access_ok()". Boom, done. Then use user_access_begin() and the appropriate unsage_get/put_user() sequence, and user_access_end(). The range test that user-access-begin does is not just part of the ABI, it's just required in general. We have almost thirty years of history of trying to avoid it, AND IT WAS ALL BOGUS. The fact is, the range check is pretty damn cheap, and not doing the range check has always been a complete and utter disaster. You have exactly two cases: (a) the access_ok() would be right above the code and can't be missed (b) not and in (a) the solution is: remove the access_ok() and let user_access_begin() do the range check. In (b), the solution is literally "DON'T DO THAT!" Because EVERY SINGLE TIME people have eventually noticed (possibly after code movement) that "oops, we never did the access_ok at all, and now we can be fooled into kernel corruption and a security issue". And even if that didn't happen, the worry was there. End result: use user_access_begin() and stop trying to remove the two cycles or whatever of the limit checking cost. The "upside" of removing that limit check just isn't. It's a downside. Linus
Re: WARNING in snd_usbmidi_submit_urb/usb_submit_urb
On Mon, Jun 1, 2020 at 2:29 PM Greg KH wrote:
>
> On Mon, Jun 01, 2020 at 02:22:40PM +0200, Andrey Konovalov wrote:
> > On Mon, Jun 1, 2020 at 10:43 AM Greg KH wrote:
> > >
> > > On Mon, Jun 01, 2020 at 12:24:03AM -0700, syzbot wrote:
> > > > syzbot has bisected this bug to:
> > > >
> > > > commit f2c2e717642c66f7fe7e5dd69b2e8ff5849f4d10
> > > > Author: Andrey Konovalov
> > > > Date: Mon Feb 24 16:13:03 2020 +
> > > >
> > > > usb: gadget: add raw-gadget interface
> > > >
> > > > bisection log:
> > > > https://syzkaller.appspot.com/x/bisect.txt?x=164afcf210
> > > > start commit: bdc48fa1 checkpatch/coding-style: deprecate 80-column
> > > > warn..
> > > > git tree: upstream
> > > > final crash:
> > > > https://syzkaller.appspot.com/x/report.txt?x=154afcf210
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=114afcf210
> > > > kernel config:
> > > > https://syzkaller.appspot.com/x/.config?x=129ea1e5950835e5
> > > > dashboard link:
> > > > https://syzkaller.appspot.com/bug?extid=5f1d24c49c1d2c427497
> > > > syz repro:
> > > > https://syzkaller.appspot.com/x/repro.syz?x=12d70cf210
> > > >
> > > > Reported-by: syzbot+5f1d24c49c1d2c427...@syzkaller.appspotmail.com
> > > > Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface")
> > > >
> > > > For information about bisection process see:
> > > > https://goo.gl/tpsmEJ#bisection
> > >
> > > So the tool that was used to create the bug has bisected the problem to
> > > the patch that adds the tool to the kernel to test for the issue?
> > >
> > > This feels wrong...
> >
> > That's the expected result of bisection with the way it's intended to
> > work. We'll be getting more bisection results pointing to that commit
> > for old USB bugs. For new ones (that are introduced after raw-gadget),
> > the bisection should point to proper commits.
>
> Ok, can you then mute any bisection emails that are about to get sent
> out that resolve to this commit to save us the effort of just ignoring
> the thing on our end?
Sent syzbot change: https://github.com/google/syzkaller/pull/1782
Re: [PATCH] cxl: Fix kobject memory leak in cxl_sysfs_afu_new_cr()
> Fix it by adding a call to kobject_put() in the error path of > kobject_init_and_add(). Thanks for another completion of the exception handling. Would an other patch subject be a bit nicer? … > +++ b/drivers/misc/cxl/sysfs.c > @@ -624,7 +624,7 @@ static struct afu_config_record > *cxl_sysfs_afu_new_cr(struct cxl_afu *afu, int c > rc = kobject_init_and_add(>kobj, _config_record_type, > >dev.kobj, "cr%i", cr->cr); > if (rc) > - goto err; > + goto err1; … Can an other label be more reasonable here? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=f359287765c04711ff54fbd11645271d8e5ff763#n465 Regards, Markus
Re: [PATCH V11 11/11] fs/xfs: Update xfs_ioctl_setattr_dax_invalidate()
On Tue, Apr 28, 2020 at 01:11:38PM -0700, Darrick J. Wong wrote:
> On Mon, Apr 27, 2020 at 05:21:42PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Because of the separation of FS_XFLAG_DAX from S_DAX and the delayed
> > setting of S_DAX, data invalidation no longer needs to happen when
> > FS_XFLAG_DAX is changed.
> >
> > Change xfs_ioctl_setattr_dax_invalidate() to be
> > xfs_ioctl_dax_check_set_cache() and alter the code to reflect the new
> > functionality.
> >
> > Furthermore, we no longer need the locking so we remove the join_flags
> > logic.
> >
> > Signed-off-by: Ira Weiny
>
> Looks ok,
> Reviewed-by: Darrick J. Wong
>
> --D
>
> >
> > ---
> > Changes from V10:
> > adjust for renamed d_mark_dontcache() function
> >
> > Changes from V9:
> > Change name of function to xfs_ioctl_setattr_prepare_dax()
> >
> > Changes from V8:
> > Change name of function to xfs_ioctl_dax_check_set_cache()
> > Update commit message
> > Fix bit manipulations
> >
> > Changes from V7:
> > Use new flag_inode_dontcache()
> > Skip don't cache if mount over ride is active.
> >
> > Changes from v6:
> > Fix completely broken implementation and update commit message.
> > Use the new VFS layer I_DONTCACHE to facilitate inode eviction
> > and S_DAX changing on drop_caches
> >
> > Changes from v5:
> > New patch
> > ---
> > fs/xfs/xfs_ioctl.c | 108 +
> > 1 file changed, 20 insertions(+), 88 deletions(-)
> >
> > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> > index 104495ac187c..ff474f2c9acf 100644
> > --- a/fs/xfs/xfs_ioctl.c
> > +++ b/fs/xfs/xfs_ioctl.c
> > @@ -1245,64 +1245,26 @@ xfs_ioctl_setattr_xflags(
> > return 0;
> > }
> >
> > -/*
> > - * If we are changing DAX flags, we have to ensure the file is clean and
> > any
> > - * cached objects in the address space are invalidated and removed. This
> > - * requires us to lock out other IO and page faults similar to a truncate
> > - * operation. The locks need to be held until the transaction has been
> > committed
> > - * so that the cache invalidation is atomic with respect to the DAX flag
> > - * manipulation.
> > - */
> > -static int
> > -xfs_ioctl_setattr_dax_invalidate(
> > +static void
> > +xfs_ioctl_setattr_prepare_dax(
> > struct xfs_inode*ip,
> > - struct fsxattr *fa,
> > - int *join_flags)
> > + struct fsxattr *fa)
> > {
> > - struct inode*inode = VFS_I(ip);
> > - struct super_block *sb = inode->i_sb;
> > - int error;
> > -
> > - *join_flags = 0;
> > -
> > - /*
> > -* It is only valid to set the DAX flag on regular files and
> > -* directories on filesystems where the block size is equal to the page
> > -* size. On directories it serves as an inherited hint so we don't
> > -* have to check the device for dax support or flush pagecache.
> > -*/
> > - if (fa->fsx_xflags & FS_XFLAG_DAX) {
> > - struct xfs_buftarg *target = xfs_inode_buftarg(ip);
> > -
> > - if (!bdev_dax_supported(target->bt_bdev, sb->s_blocksize))
> > - return -EINVAL;
> > - }
> > -
> > - /* If the DAX state is not changing, we have nothing to do here. */
> > - if ((fa->fsx_xflags & FS_XFLAG_DAX) && IS_DAX(inode))
> > - return 0;
> > - if (!(fa->fsx_xflags & FS_XFLAG_DAX) && !IS_DAX(inode))
> > - return 0;
> > + struct xfs_mount*mp = ip->i_mount;
> > + struct inode*inode = VFS_I(ip);
> >
> > if (S_ISDIR(inode->i_mode))
> > - return 0;
> > -
> > - /* lock, flush and invalidate mapping in preparation for flag change */
> > - xfs_ilock(ip, XFS_MMAPLOCK_EXCL | XFS_IOLOCK_EXCL);
> > - error = filemap_write_and_wait(inode->i_mapping);
> > - if (error)
> > - goto out_unlock;
> > - error = invalidate_inode_pages2(inode->i_mapping);
> > - if (error)
> > - goto out_unlock;
> > -
> > - *join_flags = XFS_MMAPLOCK_EXCL | XFS_IOLOCK_EXCL;
> > - return 0;
> > + return;
> >
> > -out_unlock:
> > - xfs_iunlock(ip, XFS_MMAPLOCK_EXCL | XFS_IOLOCK_EXCL);
> > - return error;
> > + if ((mp->m_flags & XFS_MOUNT_DAX_ALWAYS) ||
> > + (mp->m_flags & XFS_MOUNT_DAX_NEVER))
> > + return;
> >
> > + if (((fa->fsx_xflags & FS_XFLAG_DAX) &&
> > + !(ip->i_d.di_flags2 & XFS_DIFLAG2_DAX)) ||
> > + (!(fa->fsx_xflags & FS_XFLAG_DAX) &&
> > +(ip->i_d.di_flags2 & XFS_DIFLAG2_DAX)))
> > + d_mark_dontcache(inode);
Now that I think about this further, are we /really/ sure that we want
to let unprivileged userspace cause inode evictions?
--D
> > }
> >
> > /*
> > @@ -1310,17 +1272,10 @@ xfs_ioctl_setattr_dax_invalidate(
> > * have permission to do so. On success, return a clean transaction and the
> > * inode locked exclusively ready for further operation specific
[PATCH] clk: baikal-t1: remove redundant assignment to variable 'divider'
From: Colin Ian King
The variable divider is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/clk/baikal-t1/ccu-div.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/baikal-t1/ccu-div.c b/drivers/clk/baikal-t1/ccu-div.c
index bd40f5936f08..4062092d67f9 100644
--- a/drivers/clk/baikal-t1/ccu-div.c
+++ b/drivers/clk/baikal-t1/ccu-div.c
@@ -248,7 +248,7 @@ static int ccu_div_var_set_rate_fast(struct clk_hw *hw,
unsigned long rate,
unsigned long parent_rate)
{
struct ccu_div *div = to_ccu_div(hw);
- unsigned long flags, divider = 1;
+ unsigned long flags, divider;
u32 val;
divider = ccu_div_var_calc_divider(rate, parent_rate, div->mask);
--
2.25.1
[GIT PULL] vfs: improve DAX behavior for 5.8, part 2
Hi Linus, Please pull this second part of the 5.8 DAX changes. This time around, we're hoisting the DONTCACHE flag from XFS into the VFS so that we can make the incore DAX mode changes become effective sooner. We can't change the file data access mode on a live inode because we don't have a safe way to change the file ops pointers. The incore state change becomes effective at inode loading time, which can happen if the inode is evicted. Therefore, we're making it so that filesystems can ask the VFS to evict the inode as soon as the last holder drops. The per-fs changes to make this call this will be in subsequent pull requests from Ted and myself. I did a test merge of this branch against upstream this morning and there weren't any conflicts. Please let us know if you have any complaints about pulling this. --D The following changes since commit 83d9088659e8f113741bb197324bd9554d159657: Documentation/dax: Update Usage section (2020-05-04 08:49:39 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/vfs-5.8-merge-2 for you to fetch changes up to 2c567af418e3f9380c2051aada58b4e5a4b5c2ad: fs: Introduce DCACHE_DONTCACHE (2020-05-13 08:44:35 -0700) (More) new code for 5.8: - Introduce DONTCACHE flags for dentries and inodes. This hint will cause the VFS to drop the associated objects immediately after the last put, so that we can change the file access mode (DAX or page cache) on the fly. Ira Weiny (2): fs: Lift XFS_IDONTCACHE to the VFS layer fs: Introduce DCACHE_DONTCACHE fs/dcache.c| 19 +++ fs/xfs/xfs_icache.c| 4 ++-- fs/xfs/xfs_inode.h | 3 +-- fs/xfs/xfs_super.c | 2 +- include/linux/dcache.h | 2 ++ include/linux/fs.h | 7 ++- 6 files changed, 31 insertions(+), 6 deletions(-)
Re: [PATCH] arch/x86: reset MXCSR to default in kernel_fpu_begin()
On 6/2/20 11:03 AM, Andy Lutomirski wrote: On Tue, Jun 2, 2020 at 3:56 AM Borislav Petkov wrote: Hi, On Tue, Jun 02, 2020 at 01:29:51PM +0300, Petteri Aimonen wrote: The kernel module is not actually x86-specific, even though it is currently only enabled for x86. amdgpu driver already does kernel mode floating point operations on PPC64 also, and the same module could be used to test the same thing there. Then make it generic please and put the user portion in, say, tools/testing/selftests/fpu/ and we can ask ppc people to test it too. People might wanna add more stuff to it in the future, which would be good. To deterministically trigger the bug, the syscall has to come from the same thread that has modified MXCSR. Going through /usr/sbin/modprobe won't work, and manually doing the necessary syscalls for module loading seems too complicated. Ok, fair enough. But put that file in debugfs pls. I think I agree. While it would be delightful to have general selftest tooling for kernel modules, we don't have that right now, and having the test just work with an appropriately configured kernel would be nice. Let's extend it to do what we want it to do. I will happy to take patches. If you have some concrete ideas on what we can add, please do a short summary of what is missing. I will find a way to get this done. How about putting the file you frob in /sys/kernel/debug/selftest_helpers/something_or_other. The idea would be that /sys/kernel/debug/selftest_helpers would be a general place for kernel helpers needed to make selftests work. Is this a workaround for the lack of selftest tooling for kernel modules? In which case, let's us focus on fix selftest tooling. thanks, -- Shuah
Re: R: [PATCH v5 11/11] PCI: qcom: Add Force GEN1 support
[+cc Varada]
On Tue, Jun 02, 2020 at 07:07:27PM +0200, ansuels...@gmail.com wrote:
> > On Tue, Jun 02, 2020 at 01:53:52PM +0200, Ansuel Smith wrote:
> > > From: Sham Muthayyan
> > >
> > > Add Force GEN1 support needed in some ipq8064 board that needs to
> > limit
> > > some PCIe line to gen1 for some hardware limitation. This is set by the
> > > max-link-speed binding and needed by some soc based on ipq8064. (for
> > > example Netgear R7800 router)
> > >
> > > Signed-off-by: Sham Muthayyan
> > > Signed-off-by: Ansuel Smith
> > > Reviewed-by: Rob Herring
> > > ---
> > > drivers/pci/controller/dwc/pcie-qcom.c | 13 +
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> > b/drivers/pci/controller/dwc/pcie-qcom.c
> > > index 259b627bf890..0ce15d53c46e 100644
> > > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > > @@ -27,6 +27,7 @@
> > > #include
> > > #include
> > >
> > > +#include "../../pci.h"
> > > #include "pcie-designware.h"
> > >
> > > #define PCIE20_PARF_SYS_CTRL 0x00
> > > @@ -99,6 +100,8 @@
> > > #define PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE 0x358
> > > #define SLV_ADDR_SPACE_SZ0x1000
> > >
> > > +#define PCIE20_LNK_CONTROL2_LINK_STATUS2 0xa0
> > > +
> > > #define DEVICE_TYPE_RC 0x4
> > >
> > > #define QCOM_PCIE_2_1_0_MAX_SUPPLY 3
> > > @@ -195,6 +198,7 @@ struct qcom_pcie {
> > > struct phy *phy;
> > > struct gpio_desc *reset;
> > > const struct qcom_pcie_ops *ops;
> > > + int gen;
> > > };
> > >
> > > #define to_qcom_pcie(x) dev_get_drvdata((x)->dev)
> > > @@ -395,6 +399,11 @@ static int qcom_pcie_init_2_1_0(struct
> > qcom_pcie *pcie)
> > > /* wait for clock acquisition */
> > > usleep_range(1000, 1500);
> > >
> > > + if (pcie->gen == 1) {
> > > + val = readl(pci->dbi_base +
> > PCIE20_LNK_CONTROL2_LINK_STATUS2);
> > > + val |= 1;
> >
> > Is this the same bit that's visible in config space as
> > PCI_EXP_LNKSTA_CLS_2_5GB? Why not use that #define?
> >
> > There are a bunch of other #defines in this file that look like
> > redefinitions of standard things:
> >
> > #define PCIE20_COMMAND_STATUS 0x04
> > Looks like PCI_COMMAND
> >
> > #define CMD_BME_VAL 0x4
> > Looks like PCI_COMMAND_MASTER
> >
> > #define PCIE20_DEVICE_CONTROL2_STATUS2 0x98
> > Looks like (PCIE20_CAP + PCI_EXP_DEVCTL2)
> >
> > #define PCIE_CAP_CPL_TIMEOUT_DISABLE0x10
> > Looks like PCI_EXP_DEVCTL2_COMP_TMOUT_DIS
> >
> > #define PCIE20_CAP 0x70
> > This one is obviously device-specific
> >
> > #define PCIE20_CAP_LINK_CAPABILITIES(PCIE20_CAP + 0xC)
> > Looks like (PCIE20_CAP + PCI_EXP_LNKCAP)
> >
> > #define PCIE20_CAP_ACTIVE_STATE_LINK_PM_SUPPORT (BIT(10) |
> > BIT(11))
> > Looks like PCI_EXP_LNKCAP_ASPMS
> >
> > #define PCIE20_CAP_LINK_1 (PCIE20_CAP + 0x14)
> > #define PCIE_CAP_LINK1_VAL 0x2FD7F
> > This looks like PCIE20_CAP_LINK_1 should be (PCIE20_CAP +
> > PCI_EXP_SLTCAP), but "CAP_LINK_1" doesn't sound like the Slot
> > Capabilities register, and I don't know what PCIE_CAP_LINK1_VAL
> > means.
>
> The define are used by ipq8074 and I really can't test the changes.
> Anyway it shouldn't make a difference use the define instead of the
> custom value so a patch should not harm anything... Problem is the
> last 2 define that we really don't know what they are about... How
> should I proceed? Change only the value related to
> PCI_EXP_LNKSTA_CLS_2_5GB or change all the other except the last 2?
I personally would change all the ones I mentioned above (in a
separate patch from the one that adds "max-link-speed" support).
Testing isn't a big deal because changing the #defines shouldn't
change the generated code at all.
PCIE20_CAP_LINK_1 / PCIE_CAP_LINK1_VAL looks like a potential bug or
at least a very misleading name. I wouldn't touch it unless we can
figure out what's going on.
Looks like most of this was added by 5d76117f070d ("PCI: qcom: Add
support for IPQ8074 PCIe controller"). Shame on me for not asking
these questions at the time.
Sham, Varada, can you shed any light on PCIE20_CAP_LINK_1 and
PCIE_CAP_LINK1_VAL?
> > > + writel(val, pci->dbi_base +
> > PCIE20_LNK_CONTROL2_LINK_STATUS2);
> > > + }
> > >
> > > /* Set the Max TLP size to 2K, instead of using default of 4K */
> > > writel(CFG_REMOTE_RD_REQ_BRIDGE_SIZE_2K,
> > > @@ -1397,6 +1406,10 @@ static int qcom_pcie_probe(struct
> > platform_device *pdev)
> > > goto err_pm_runtime_put;
> > > }
> > >
> > > + pcie->gen = of_pci_get_max_link_speed(pdev->dev.of_node);
> > > + if (pcie->gen < 0)
> > > + pcie->gen = 2;
> > > +
> > > res = platform_get_resource_byname(pdev,
[PATCH] mmc: core: Add error check to avoid kernel panic caused by NULL pointer
If __mmc_start_req(host, mrq) fails with error, the mrq->cmd->mrq will
be NULL. This will cause kernel panic in the following
mmc_wait_for_req_done(host, mrq). Add error check to cancle unnecessary
mmc_wait_for_req_done(host, mrq) if __mmc_start_req(host, mrq) fails.
Signed-off-by: Corey Gao
---
drivers/mmc/core/core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2553d903a82b..b13b484e64aa 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -734,9 +734,11 @@ EXPORT_SYMBOL(mmc_start_req);
*/
void mmc_wait_for_req(struct mmc_host *host, struct mmc_request *mrq)
{
- __mmc_start_req(host, mrq);
+ int err;
- if (!mrq->cap_cmd_during_tfr)
+ err = __mmc_start_req(host, mrq);
+
+ if (!mrq->cap_cmd_during_tfr && !err)
mmc_wait_for_req_done(host, mrq);
}
EXPORT_SYMBOL(mmc_wait_for_req);
--
2.17.1
Re: [PATCH] x86/resctrl: Fix memory bandwidth counter width for AMD
On 6/2/20 12:13 PM, Reinette Chatre wrote: > Hi Babu, > > On 6/1/2020 4:00 PM, Babu Moger wrote: >> Memory bandwidth is calculated reading the monitoring counter >> at two intervals and calculating the delta. It is the software’s >> responsibility to read the count often enough to avoid having >> the count roll over _twice_ between reads. >> >> The current code hardcodes the bandwidth monitoring counter's width >> to 24 bits for AMD. This is due to default base counter width which >> is 24. Currently, AMD does not implement the CPUID 0xF.[ECX=1]:EAX >> to adjust the counter width. But, the AMD hardware supports much >> wider bandwidth counter with the default width of 44 bits. >> >> Kernel reads these monitoring counters every 1 second and adjusts the >> counter value for overflow. With 24 bits and scale value of 64 for AMD, >> it can only measure up to 1GB/s without overflowing. For the rates >> above 1GB/s this will fail to measure the bandwidth. >> >> Fix the issue setting the default width to 44 bits by adjusting the >> offset. >> >> AMD future products will implement the CPUID 0xF.[ECX=1]:EAX. >> >> Signed-off-by: Babu Moger > > There is no fixes tag but if I understand correctly this issue has been > present since AMD support was added to resctrl. This fix builds on top > of a recent feature addition and would thus not work for earlier > kernels. Are you planning to create a different fix for earlier kernels? Yes. This was there from day one. I am going to back port to older kernels once we arrive on the final patch. Do we need fixes tag here?
[PATCH v3 01/10] dmaengine: Actions: get rid of bit fields from dma descriptor
At the moment, Driver uses bit fields to describe registers of the DMA
descriptor structure that makes it less portable and maintainable, and
Andre suugested(and even sketched important bits for it) to make use of
array to describe this DMA descriptors instead. It gives the flexibility
while extending support for other platform such as Actions S700.
This commit removes the "owl_dma_lli_hw" (that includes bit-fields) and
uses array to describe DMA descriptor.
Suggested-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v2:
* No change.
Changes since v1:
* Defined macro for frame count value.
* Introduced llc_hw_flen() from patch 2/9.
* Removed the unnecessary line break.
Changes since rfc:
* No change.
---
drivers/dma/owl-dma.c | 84 ---
1 file changed, 40 insertions(+), 44 deletions(-)
diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
index c683051257fd..dd85c205454e 100644
--- a/drivers/dma/owl-dma.c
+++ b/drivers/dma/owl-dma.c
@@ -120,30 +120,21 @@
#define BIT_FIELD(val, width, shift, newshift) \
val) >> (shift)) & ((BIT(width)) - 1)) << (newshift))
-/**
- * struct owl_dma_lli_hw - Hardware link list for dma transfer
- * @next_lli: physical address of the next link list
- * @saddr: source physical address
- * @daddr: destination physical address
- * @flen: frame length
- * @fcnt: frame count
- * @src_stride: source stride
- * @dst_stride: destination stride
- * @ctrla: dma_mode and linklist ctrl config
- * @ctrlb: interrupt config
- * @const_num: data for constant fill
- */
-struct owl_dma_lli_hw {
- u32 next_lli;
- u32 saddr;
- u32 daddr;
- u32 flen:20;
- u32 fcnt:12;
- u32 src_stride;
- u32 dst_stride;
- u32 ctrla;
- u32 ctrlb;
- u32 const_num;
+/* Frame count value is fixed as 1 */
+#define FCNT_VAL 0x1
+
+/* Describe DMA descriptor, hardware link list for dma transfer */
+enum owl_dmadesc_offsets {
+ OWL_DMADESC_NEXT_LLI = 0,
+ OWL_DMADESC_SADDR,
+ OWL_DMADESC_DADDR,
+ OWL_DMADESC_FLEN,
+ OWL_DMADESC_SRC_STRIDE,
+ OWL_DMADESC_DST_STRIDE,
+ OWL_DMADESC_CTRLA,
+ OWL_DMADESC_CTRLB,
+ OWL_DMADESC_CONST_NUM,
+ OWL_DMADESC_SIZE
};
/**
@@ -153,7 +144,7 @@ struct owl_dma_lli_hw {
* @node: node for txd's lli_list
*/
struct owl_dma_lli {
- struct owl_dma_lli_hw hw;
+ u32 hw[OWL_DMADESC_SIZE];
dma_addr_t phys;
struct list_headnode;
};
@@ -320,6 +311,11 @@ static inline u32 llc_hw_ctrlb(u32 int_ctl)
return ctl;
}
+static u32 llc_hw_flen(struct owl_dma_lli *lli)
+{
+ return lli->hw[OWL_DMADESC_FLEN] & GENMASK(19, 0);
+}
+
static void owl_dma_free_lli(struct owl_dma *od,
struct owl_dma_lli *lli)
{
@@ -351,8 +347,9 @@ static struct owl_dma_lli *owl_dma_add_lli(struct
owl_dma_txd *txd,
list_add_tail(>node, >lli_list);
if (prev) {
- prev->hw.next_lli = next->phys;
- prev->hw.ctrla |= llc_hw_ctrla(OWL_DMA_MODE_LME, 0);
+ prev->hw[OWL_DMADESC_NEXT_LLI] = next->phys;
+ prev->hw[OWL_DMADESC_CTRLA] |=
+ llc_hw_ctrla(OWL_DMA_MODE_LME, 0);
}
return next;
@@ -365,8 +362,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan
*vchan,
struct dma_slave_config *sconfig,
bool is_cyclic)
{
- struct owl_dma_lli_hw *hw = >hw;
- u32 mode;
+ u32 mode, ctrlb;
mode = OWL_DMA_MODE_PW(0);
@@ -407,22 +403,22 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan
*vchan,
return -EINVAL;
}
- hw->next_lli = 0; /* One link list by default */
- hw->saddr = src;
- hw->daddr = dst;
-
- hw->fcnt = 1; /* Frame count fixed as 1 */
- hw->flen = len; /* Max frame length is 1MB */
- hw->src_stride = 0;
- hw->dst_stride = 0;
- hw->ctrla = llc_hw_ctrla(mode,
-OWL_DMA_LLC_SAV_LOAD_NEXT |
-OWL_DMA_LLC_DAV_LOAD_NEXT);
+ lli->hw[OWL_DMADESC_CTRLA] = llc_hw_ctrla(mode,
+ OWL_DMA_LLC_SAV_LOAD_NEXT |
+ OWL_DMA_LLC_DAV_LOAD_NEXT);
if (is_cyclic)
- hw->ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_BLOCK);
+ ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_BLOCK);
else
- hw->ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_SUPER_BLOCK);
+ ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_SUPER_BLOCK);
+
+ lli->hw[OWL_DMADESC_NEXT_LLI] = 0;
+ lli->hw[OWL_DMADESC_SADDR] = src;
+
[PATCH 1/3] x86, kcsan: Remove __no_kcsan_or_inline usage
Now that KCSAN relies on -tsan-distinguish-volatile we no longer need
the annotation for constant_test_bit(). Remove it.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/bitops.h |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -201,12 +201,8 @@ arch_test_and_change_bit(long nr, volati
return GEN_BINARY_RMWcc(LOCK_PREFIX __ASM_SIZE(btc), *addr, c, "Ir",
nr);
}
-static __no_kcsan_or_inline bool constant_test_bit(long nr, const volatile
unsigned long *addr)
+static __always_inline bool constant_test_bit(long nr, const volatile unsigned
long *addr)
{
- /*
-* Because this is a plain access, we need to disable KCSAN here to
-* avoid double instrumentation via instrumented bitops.
-*/
return ((1UL << (nr & (BITS_PER_LONG-1))) &
(addr[nr >> _BITOPS_LONG_SHIFT])) != 0;
}
[PATCH v3 00/10] Add MMC and DMA support for Actions S700
This Series(v3) addressed the review comments provide by Rob, and there are changes in patch 5/10 for it. Also, one of the important change for this series(v3) is about the way we we handle address range conflict between pinctrl and sps node. In the last Series(v2), patch 4/10 was sent as *do not merge* but while discussing about some proper solution for it, we have come up with idea of limiting pinctrl address range(to 0x100) to avoid this conflict. This is safe to do as current pinctrl driver uses address range only up to 0x100 (even less than that?), and this would let sps to work properly. Since sps block is now enabled , we have to provide power-domain bit for dma to work properly and patch 6/10 has that change now. Looking forward have some comments for this series. --- Series(v2) addressed the review comments provided by Andre, and there are changes in patch 1/10, 2/10, 5/10 and 9/10. * Accessor function (to get the frame lenght) has moved from patch 2/9 to patch 1/9 with inline removed. * Removed the unnecessary line break. * Added comments about the way DMA descriptor differs between S700 and S900. * Added a macro to define fcnt value. * Updated dma DT bindings. * Used SoC secific compatible string for MMC. Apart from it, a new patch 8/10 is added in this series to update mmc DT bindings. Series is rebased on 5.7.0-rc6. - Series(v1) have following changes from the previous series. New patch(5/8) has been introduced that converts dma dt-binding for Actions OWL SoC from text format to yaml file. For patch(2/8) new accessor function is added to get the frame lenght which is common to both S900 and S700. Apart from it SoC check is removed from irq routine as it is not needed. Patch(4/8) which is an hack to prove our DMA and MMC works for S700 is now sent as *do not merge* patch. DMA is tested using dmatest with follwoing result: root@ubuntu:~# echo dma0chan1 > /sys/module/dmatest/parameters/channel root@ubuntu:~# echo 2000 > /sys/module/dmatest/parameters/timeout root@ubuntu:~# echo 1 > /sys/module/dmatest/parameters/iterations root@ubuntu:~# echo 1 > /sys/module/dmatest/parameters/run root@ubuntu:~# dmesg | tail [ 303.362586] dmatest: Added 1 threads using dma0chan1 [ 317.258658] dmatest: Started 1 threads using dma0chan1 [ 317.259397] dmatest: dma0chan1-copy0: summary 1 tests, 0 failures 16129.03 iops 32258 KB/s (0) --- The intention of RFC series is to enable uSD and DMA support for Cubieboard7 based on Actions S700 SoC, and on the way we found that it requires changes in dmaengine present on S700 as its different from what is present on S900. Patch(1/8) does provide a new way to describe DMA descriptor, idea is to remove the bit-fields as its less maintainable. It is only build tested and it would be great if this can be tested on S900 based hardware. Patch(2/8) adds S700 DMA engine support, there is new compatible string added for it, which means a changed bindings needed to submitted for this. I would plan to send it later the converted "owl-dma.yaml". Patch(4/8) disables the sps node as its memory range is conflicting pinctrl node and results in pinctrl proble failure. Rest of patches in the series adds DMA/MMC nodes for S700 alone with binding constants and enables the uSD for Cubieboard7. This whole series is tested, by building/compiling Kernel on Cubieboard7-lite which was *almost* successful (OOM kicked in, while Linking due to less RAM present on hardware). Following is the mmc speed : ubuntu@ubuntu:~$ sudo hdparm -tT /dev/mmcblk0 /dev/mmcblk0: Timing cached reads: 1310 MB in 2.00 seconds = 655.15 MB/sec Timing buffered disk reads: 62 MB in 3.05 seconds = 20.30 MB/sec Amit Singh Tomar (10): dmaengine: Actions: get rid of bit fields from dma descriptor dmaengine: Actions: Add support for S700 DMA engine clk: actions: Add MMC clock-register reset bits arm64: dts: actions: limit address range for pinctrl node dt-bindings: dmaengine: convert Actions Semi Owl SoCs bindings to yaml arm64: dts: actions: Add DMA Controller for S700 dt-bindings: reset: s700: Add binding constants for mmc dt-bindings: mmc: owl: add compatible string actions,s700-mmc arm64: dts: actions: Add MMC controller support for S700 arm64: dts: actions: Add uSD support for Cubieboard7 Documentation/devicetree/bindings/dma/owl-dma.txt | 47 Documentation/devicetree/bindings/dma/owl-dma.yaml | 79 + Documentation/devicetree/bindings/mmc/owl-mmc.yaml | 6 +- arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 41 +++ arch/arm64/boot/dts/actions/s700.dtsi | 51 - drivers/clk/actions/owl-s700.c | 3 + drivers/dma/owl-dma.c | 126
[PATCH 2/3] kcsan: Remove __no_kcsan_or_inline
There are no more user of this function attribute, also, with us now
actively supporting '__no_kcsan inline' it doesn't make sense to have
in any case.
Signed-off-by: Peter Zijlstra (Intel)
---
Documentation/dev-tools/kcsan.rst |6 --
include/linux/compiler_types.h|5 +
2 files changed, 1 insertion(+), 10 deletions(-)
--- a/Documentation/dev-tools/kcsan.rst
+++ b/Documentation/dev-tools/kcsan.rst
@@ -114,12 +114,6 @@ functions, compilation units, or entire
To dynamically limit for which functions to generate reports, see the
`DebugFS interface`_ blacklist/whitelist feature.
- For ``__always_inline`` functions, replace ``__always_inline`` with
- ``__no_kcsan_or_inline`` (which implies ``__always_inline``)::
-
-static __no_kcsan_or_inline void foo(void) {
-...
-
* To disable data race detection for a particular compilation unit, add to the
``Makefile``::
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -193,10 +193,7 @@ struct ftrace_likely_data {
#define __no_kcsan __no_sanitize_thread
#ifdef __SANITIZE_THREAD__
-# define __no_kcsan_or_inline __no_kcsan notrace __maybe_unused
-# define __no_sanitize_or_inline __no_kcsan_or_inline
-#else
-# define __no_kcsan_or_inline __always_inline
+# define __no_sanitize_or_inline __no_kcsan notrace __maybe_unused
#endif
#ifndef __no_sanitize_or_inline
[PATCH 0/3] KCSAN cleanups and noinstr
Hi all, Here's two KCSAN cleanups and the required noinstr change for x86.
[PATCH 3/3] x86, kcsan: Add __no_kcsan to noinstr
The 'noinstr' function attribute means no-instrumentation, this should
very much include *SAN. Because lots of that is broken at present,
only include KCSAN for now, as that is limited to clang11, which has
sane function attribute behaviour.
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/compiler_types.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -118,10 +118,6 @@ struct ftrace_likely_data {
#define notrace
__attribute__((__no_instrument_function__))
#endif
-/* Section for code which can't be instrumented at all */
-#define noinstr
\
- noinline notrace __attribute((__section__(".noinstr.text")))
-
/*
* it doesn't make sense on ARM (currently the only user of __naked)
* to trace naked functions because then mcount is called without
@@ -200,6 +196,10 @@ struct ftrace_likely_data {
#define __no_sanitize_or_inline __always_inline
#endif
+/* Section for code which can't be instrumented at all */
+#define noinstr
\
+ noinline notrace __attribute((__section__(".noinstr.text"))) __no_kcsan
+
#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */
[PATCH v3 02/10] dmaengine: Actions: Add support for S700 DMA engine
DMA controller present on S700 SoC is compatible with the one on S900
(as most of registers are same), but it has different DMA descriptor
structure where registers "fcnt" and "ctrlb" uses different encoding.
For instance, on S900 "fcnt" starts at offset 0x0c and uses upper 12
bits whereas on S700, it starts at offset 0x1c and uses lower 12 bits.
This commit adds support for DMA controller present on S700.
Signed-off-by: Amit Singh Tomar
---
Changes since v2:
* No changes.
Changes since v1:
* Moved llc_hw_flen() to patch 1/9.
* provided comments about dma descriptor difference.
between S700 and S900.
Changes since RFC:
* Added accessor function to get the frame lenght.
* Removed the SoC specific check in IRQ routine.
---
drivers/dma/owl-dma.c | 46 +-
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
index dd85c205454e..17d2fc2d568b 100644
--- a/drivers/dma/owl-dma.c
+++ b/drivers/dma/owl-dma.c
@@ -137,6 +137,11 @@ enum owl_dmadesc_offsets {
OWL_DMADESC_SIZE
};
+enum owl_dma_id {
+ S900_DMA,
+ S700_DMA,
+};
+
/**
* struct owl_dma_lli - Link list for dma transfer
* @hw: hardware link list
@@ -203,6 +208,7 @@ struct owl_dma_vchan {
* @pchans: array of data for the physical channels
* @nr_vchans: the number of physical channels
* @vchans: array of data for the physical channels
+ * @devid: device id based on OWL SoC
*/
struct owl_dma {
struct dma_device dma;
@@ -217,6 +223,7 @@ struct owl_dma {
unsigned intnr_vchans;
struct owl_dma_vchan*vchans;
+ enum owl_dma_id devid;
};
static void pchan_update(struct owl_dma_pchan *pchan, u32 reg,
@@ -306,6 +313,11 @@ static inline u32 llc_hw_ctrlb(u32 int_ctl)
{
u32 ctl;
+ /*
+* Irrespective of the SoC, ctrlb value starts filling from
+* bit 18.
+*/
+
ctl = BIT_FIELD(int_ctl, 7, 0, 18);
return ctl;
@@ -362,6 +374,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan
*vchan,
struct dma_slave_config *sconfig,
bool is_cyclic)
{
+ struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
u32 mode, ctrlb;
mode = OWL_DMA_MODE_PW(0);
@@ -417,8 +430,18 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan
*vchan,
lli->hw[OWL_DMADESC_DADDR] = dst;
lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
- lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
- lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
+
+ /*
+* S700 put flen and fcnt at offset 0x0c and 0x1c respectively,
+* whereas S900 put flen and fcnt at offset 0x0c.
+*/
+ if (od->devid == S700_DMA) {
+ lli->hw[OWL_DMADESC_FLEN] = len;
+ lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
+ } else {
+ lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
+ lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
+ }
return 0;
}
@@ -580,7 +603,7 @@ static irqreturn_t owl_dma_interrupt(int irq, void *dev_id)
global_irq_pending = dma_readl(od, OWL_DMA_IRQ_PD0);
- if (chan_irq_pending && !(global_irq_pending & BIT(i))) {
+ if (chan_irq_pending && !(global_irq_pending & BIT(i))) {
dev_dbg(od->dma.dev,
"global and channel IRQ pending match err\n");
@@ -1038,11 +1061,20 @@ static struct dma_chan *owl_dma_of_xlate(struct
of_phandle_args *dma_spec,
return chan;
}
+static const struct of_device_id owl_dma_match[] = {
+ { .compatible = "actions,s900-dma", .data = (void *)S900_DMA,},
+ { .compatible = "actions,s700-dma", .data = (void *)S700_DMA,},
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, owl_dma_match);
+
static int owl_dma_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct owl_dma *od;
int ret, i, nr_channels, nr_requests;
+ const struct of_device_id *of_id =
+ of_match_device(owl_dma_match, >dev);
od = devm_kzalloc(>dev, sizeof(*od), GFP_KERNEL);
if (!od)
@@ -1067,6 +1099,8 @@ static int owl_dma_probe(struct platform_device *pdev)
dev_info(>dev, "dma-channels %d, dma-requests %d\n",
nr_channels, nr_requests);
+ od->devid = (enum owl_dma_id)of_id->data;
+
od->nr_pchans = nr_channels;
od->nr_vchans = nr_requests;
@@ -1199,12 +1233,6 @@ static int owl_dma_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id owl_dma_match[] = {
- { .compatible = "actions,s900-dma", },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, owl_dma_match);
-
Re: kobject_init_and_add is easy to misuse
On Tue, Jun 02, 2020 at 08:25:14AM -0700, James Bottomley wrote: > On Tue, 2020-06-02 at 05:10 -0700, Matthew Wilcox wrote: > > On Tue, Jun 02, 2020 at 07:50:33PM +0800, Wang Hai wrote: > > > syzkaller reports for memory leak when kobject_init_and_add() > > > returns an error in the function sysfs_slab_add() [1] > > > > > > When this happened, the function kobject_put() is not called for > > > the > > > corresponding kobject, which potentially leads to memory leak. > > > > > > This patch fixes the issue by calling kobject_put() even if > > > kobject_init_and_add() fails. > > > > I think this speaks to a deeper problem with kobject_init_and_add() > > -- the need to call kobject_put() if it fails is not readily apparent > > to most users. This same bug appears in the first three users of > > kobject_init_and_add() that I checked -- > > arch/ia64/kernel/topology.c > > drivers/firmware/dmi-sysfs.c > > drivers/firmware/efi/esrt.c > > drivers/scsi/iscsi_boot_sysfs.c > > > > Some do get it right -- > > arch/powerpc/kernel/cacheinfo.c > > drivers/gpu/drm/ttm/ttm_bo.c > > drivers/gpu/drm/ttm/ttm_memory.c > > drivers/infiniband/hw/mlx4/sysfs.c > > > > I'd argue that the current behaviour is wrong, > > Absolutely agree with this. We have a big meta pattern here where we > introduce functions with tortuous semantics then someone creates a > checker for the semantics and misuses come crawling out of the woodwork > leading to floods of patches, usually for little or never used error > paths, which really don't buy anything apart from theoretical > correctness. Just insisting on simple semantics would have avoided > this. I "introduced" this way back at the end of 2007. It's not exactly a new function. > > that kobject_init_and_add() should call kobject_put() if the add > > fails. This would need a tree-wide audit. But somebody needs to do > > that anyway because based on my random sampling, half of the users > > currently get it wrong. > > Well, the semantics of kobject_init() are free on fail, so these are > the ones everyone seems to be using. The semantics of kobject_add are > put on fail. The problem is that put on fail isn't necessarily correct > in the kobject_init() case: the release function may make assumptions > about the object hierarchy which aren't satisfied in the kobject_init() > failure case. This argues that kobject_init_and_add() can't ever have > correct semantics and we should eliminate it. At the time, it did reduce common functionality and error handling all into a simpler function. And, given it's history, it must have somehow worked for the past 12 years or so :) Odds are, lots of the callers shouldn't be messing around with kobjects in the first place. Originally it was only assumed that there would be very few users. But it has spread to filesystems and firmware subsystems. Drivers should never use it though, so it's a good hint something is wrong there... Anyway, patches to fix this up to make a "sane" api for kobjects is always appreciated. Personally I don't have the time at the moment. thanks, greg k-h
[PATCH v3 03/10] clk: actions: Add MMC clock-register reset bits
This commit adds reset bits needed for MMC clock registers present
on Actions S700 SoC.
Signed-off-by: Amit Singh Tomar
---
Changes from v2:
* No change.
Changes from v1:
* No change.
Changes from RFC:
* No change.
---
drivers/clk/actions/owl-s700.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/actions/owl-s700.c b/drivers/clk/actions/owl-s700.c
index a2f34d13fb54..cd60eca7727d 100644
--- a/drivers/clk/actions/owl-s700.c
+++ b/drivers/clk/actions/owl-s700.c
@@ -577,6 +577,9 @@ static const struct owl_reset_map s700_resets[] = {
[RESET_DSI] = { CMU_DEVRST0, BIT(2) },
[RESET_CSI] = { CMU_DEVRST0, BIT(13) },
[RESET_SI] = { CMU_DEVRST0, BIT(14) },
+ [RESET_SD0] = { CMU_DEVRST0, BIT(22) },
+ [RESET_SD1] = { CMU_DEVRST0, BIT(23) },
+ [RESET_SD2] = { CMU_DEVRST0, BIT(24) },
[RESET_I2C0]= { CMU_DEVRST1, BIT(0) },
[RESET_I2C1]= { CMU_DEVRST1, BIT(1) },
[RESET_I2C2]= { CMU_DEVRST1, BIT(2) },
--
2.7.4
Re: [PATCH] kcsan: Prefer '__no_kcsan inline' in test
On Tue, Jun 02, 2020 at 04:36:33PM +0200, Marco Elver wrote: > Instead of __no_kcsan_or_inline, prefer '__no_kcsan inline' in test -- > this is in case we decide to remove __no_kcsan_or_inline. > > Suggested-by: Peter Zijlstra > Signed-off-by: Marco Elver > --- > > Hi Paul, > > This is to prepare eventual removal of __no_kcsan_or_inline, and avoid a > series that doesn't apply to anything other than -next (because some > bits are in -tip and the test only in -rcu; although this problem might > be solved in 2 weeks). This patch is to make sure in case the > __kcsan_or_inline series is based on -tip, integration in -next doesn't > cause problems. > > This came up in > https://lkml.kernel.org/r/20200529185923.go706...@hirez.programming.kicks-ass.net Thanks Marco! I just sent the rest of that patch here: https://lkml.kernel.org/r/20200602173103.931412...@infradead.org
[PATCH v3 04/10] arm64: dts: actions: limit address range for pinctrl node
After commit 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for
Actions Semi S700") following error has been observed while booting
Linux on Cubieboard7-lite(based on S700 SoC).
[0.257415] pinctrl-s700 e01b.pinctrl: can't request region for
resource [mem 0xe01b-0xe01b0fff]
[0.266902] pinctrl-s700: probe of e01b.pinctrl failed with error -16
This is due to the fact that memory range for "sps" power domain controller
clashes with pinctrl.
One way to fix it, is to limit pinctrl address range which is safe
to do as current pinctrl driver uses address range only up to 0x100.
This commit limits the pinctrl address range to 0x100 so that it doesn't
conflict with sps range.
Fixes: 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for Actions
Semi S700")
Suggested-by: Andre Przywara
Signed-off-by: Amit Singh Tomar
---
Changes since v2:
* this is no more don't merge and fixed
the broken S700 boot by limiting pinctrl
address range.
* Modified the subject to reflect the changes.
Changes since v1:
* No change.
Changes since RFC:
* kept as do not merge.
---
arch/arm64/boot/dts/actions/s700.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi
b/arch/arm64/boot/dts/actions/s700.dtsi
index 2006ad5424fa..f8eb72bb4125 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -231,7 +231,7 @@
pinctrl: pinctrl@e01b {
compatible = "actions,s700-pinctrl";
- reg = <0x0 0xe01b 0x0 0x1000>;
+ reg = <0x0 0xe01b 0x0 0x100>;
clocks = < CLK_GPIO>;
gpio-controller;
gpio-ranges = < 0 0 136>;
--
2.7.4
[PATCH v3 05/10] dt-bindings: dmaengine: convert Actions Semi Owl SoCs bindings to yaml
Converts the device tree bindings for the Actions Semi Owl SoCs DMA
Controller over to YAML schemas.
It also adds new compatible string "actions,s700-dma".
Signed-off-by: Amit Singh Tomar
---
Changes since v2:
* Addressed Rob's comments:
- removed unnecessary description.
- added unevaluatedProperties
- added relevant information about
dma-channels and dma-request
* Added power-domain property.
Change since v1:
* Updated the description field to reflect
only the necessary information.
* replaced the maxItems field with description for each
controller attribute(except interrupts).
* Replaced the clock macro with number to keep the example
as independent as possible.
New patch, was not there in RFC.
---
Documentation/devicetree/bindings/dma/owl-dma.txt | 47 -
Documentation/devicetree/bindings/dma/owl-dma.yaml | 79 ++
2 files changed, 79 insertions(+), 47 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.yaml
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.txt
b/Documentation/devicetree/bindings/dma/owl-dma.txt
deleted file mode 100644
index 03e9bb12b75f..
--- a/Documentation/devicetree/bindings/dma/owl-dma.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Actions Semi Owl SoCs DMA controller
-
-This binding follows the generic DMA bindings defined in dma.txt.
-
-Required properties:
-- compatible: Should be "actions,s900-dma".
-- reg: Should contain DMA registers location and length.
-- interrupts: Should contain 4 interrupts shared by all channel.
-- #dma-cells: Must be <1>. Used to represent the number of integer
- cells in the dmas property of client device.
-- dma-channels: Physical channels supported.
-- dma-requests: Number of DMA request signals supported by the controller.
-Refer to Documentation/devicetree/bindings/dma/dma.txt
-- clocks: Phandle and Specifier of the clock feeding the DMA controller.
-
-Example:
-
-Controller:
-dma: dma-controller@e026 {
-compatible = "actions,s900-dma";
-reg = <0x0 0xe026 0x0 0x1000>;
-interrupts = ,
- ,
- ,
- ;
-#dma-cells = <1>;
-dma-channels = <12>;
-dma-requests = <46>;
-clocks = < CLK_DMAC>;
-};
-
-Client:
-
-DMA clients connected to the Actions Semi Owl SoCs DMA controller must
-use the format described in the dma.txt file, using a two-cell specifier
-for each channel.
-
-The two cells in order are:
-1. A phandle pointing to the DMA controller.
-2. The channel id.
-
-uart5: serial@e012a000 {
-...
-dma-names = "tx", "rx";
-dmas = < 26>, < 27>;
-...
-};
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.yaml
b/Documentation/devicetree/bindings/dma/owl-dma.yaml
new file mode 100644
index ..5577cd910781
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/owl-dma.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/owl-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl SoCs DMA controller
+
+description: |
+ The OWL DMA is a general-purpose direct memory access controller capable of
+ supporting 10 and 12 independent DMA channels for S700 and S900 SoCs
+ respectively.
+
+maintainers:
+ - Manivannan Sadhasivam
+
+allOf:
+ - $ref: "dma-controller.yaml#"
+
+properties:
+ compatible:
+enum:
+ - actions,s900-dma
+ - actions,s700-dma
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description:
+ controller supports 4 interrupts, which are freely assignable to the
+ DMA channels.
+maxItems: 4
+
+ "#dma-cells":
+const: 1
+
+ dma-channels:
+maximum: 12
+
+ dma-requests:
+maximum: 46
+
+ clocks:
+maxItems: 1
+description:
+ Phandle and Specifier of the clock feeding the DMA controller.
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#dma-cells"
+ - dma-channels
+ - dma-requests
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+dma: dma-controller@e026 {
+compatible = "actions,s900-dma";
+reg = <0x0 0xe026 0x0 0x1000>;
+interrupts = ,
+ ,
+ ,
+ ;
+#dma-cells = <1>;
+dma-channels = <12>;
+dma-requests = <46>;
+clocks = < 22>;
+};
+
+...
--
2.7.4
Re: [PATCH net-next v2] af-packet: new flag to indicate all csums are good
On Tue, Jun 2, 2020 at 1:03 PM Victor Julien wrote:
>
> On 02-06-2020 16:29, Willem de Bruijn wrote:
> > On Tue, Jun 2, 2020 at 4:05 AM Victor Julien wrote:
> >>
> >> Introduce a new flag (TP_STATUS_CSUM_UNNECESSARY) to indicate
> >> that the driver has completely validated the checksums in the packet.
> >>
> >> The TP_STATUS_CSUM_UNNECESSARY flag differs from TP_STATUS_CSUM_VALID
> >> in that the new flag will only be set if all the layers are valid,
> >> while TP_STATUS_CSUM_VALID is set as well if only the IP layer is valid.
> >
> > transport, not ip checksum.
>
> Allow me a n00b question: what does transport refer to here? Things like
> ethernet? It isn't clear to me from the doc.
The TCP/UDP/.. transport protocol checksum.
> (happy to follow up with a patch to clarify the doc when I understand
> things better)
>
> > But as I understand it drivers set CHECKSUM_COMPLETE if they fill in
> > skb->csum over the full length of the packet. This does not
> > necessarily imply that any of the checksum fields in the packet are
> > valid yet (see also skb->csum_valid). Protocol code later compares
> > checksum fields against this using __skb_checksum_validate_complete and
> > friends.
> >
> > But packet sockets may be called before any of this, however. So I wonder
> > how valid the checksum really is right now when setting
> > TP_STATUS_CSUM_VALID.
> > I assume it's correct, but don't fully understand where the validation
> > has taken place..
>
> I guess I'm more confused now about what TP_STATUS_CSUM_VALID actually
> means. It sounds almost like the opposite of TP_STATUS_CSUMNOTREADY, but
> I'm not sure I understand what the value would be.
>
> It would be great if someone could help clear this up. Everything I
> thought I knew/understood so far has been proven wrong, so I'm not too
> confident about my patch anymore...
Agreed that we should clear this up.
> > Similar to commit 682f048bd494 ("af_packet: pass checksum validation
> > status to the user"), please update tpacket_rcv and packet_rcv.
>
> Ah yes, good catch. Will add it there as well.
>
> > Note also that net-next is currently closed.
>
> Should I hold off on sending a v3 until it reopens?
Yep, thanks. You can always check
http://vger.kernel.org/~davem/net-next.html when unsure.
[PATCH v3 08/10] dt-bindings: mmc: owl: add compatible string actions,s700-mmc
The commit adds a new SoC specific compatible string "actions,s700-mmc" in combination with more generic string "actions,owl-mmc". Placement order of these strings should abide by the principle of "from most specific to most general". Reviewed-by: Rob Herring Signed-off-by: Amit Singh Tomar --- Changes since v2: * Added Rob's Reviewed-by tag * Newly added patch in v2. --- Documentation/devicetree/bindings/mmc/owl-mmc.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml index 12b40213426d..9604ef695585 100644 --- a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml @@ -14,7 +14,11 @@ maintainers: properties: compatible: -const: actions,owl-mmc +oneOf: + - const: actions,owl-mmc + - items: + - const: actions,s700-mmc + - const: actions,owl-mmc reg: maxItems: 1 -- 2.7.4
[PATCH v3 10/10] arm64: dts: actions: Add uSD support for Cubieboard7
This commit adds uSD support for Cubieboard7 board based on Actions Semi
S700 SoC. SD0 is connected to uSD slot. Since there is no PMIC support
added yet, fixed regulator has been used as a regulator node.
Signed-off-by: Amit Singh Tomar
---
Changes since v2:
* No change.
Changes since v1:
* No change.
Changes since RFC:
* No change.
---
arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 41
arch/arm64/boot/dts/actions/s700.dtsi| 1 +
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
index 63e375cd9eb4..ec117eb12f3a 100644
--- a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
+++ b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
@@ -13,6 +13,7 @@
aliases {
serial3 =
+ mmc0 =
};
chosen {
@@ -28,6 +29,23 @@
device_type = "memory";
reg = <0x1 0xe000 0x0 0x0>;
};
+
+ /* Fixed regulator used in the absence of PMIC */
+ vcc_3v1: vcc-3v1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <310>;
+ regulator-max-microvolt = <310>;
+ };
+
+ /* Fixed regulator used in the absence of PMIC */
+ sd_vcc: sd-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <310>;
+ regulator-max-microvolt = <310>;
+ regulator-always-on;
+ };
};
{
@@ -81,6 +99,14 @@
bias-pull-up;
};
};
+
+ mmc0_default: mmc0_default {
+ pinmux {
+ groups = "sd0_d0_mfp", "sd0_d1_mfp", "sd0_d2_d3_mfp",
+"sd0_cmd_mfp", "sd0_clk_mfp";
+ function = "sd0";
+ };
+ };
};
{
@@ -90,3 +116,18 @@
{
status = "okay";
};
+
+/* uSD */
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+ cd-gpios = < 120 GPIO_ACTIVE_LOW>;
+ no-sdio;
+ no-mmc;
+ no-1-8-v;
+ bus-width = <4>;
+ vmmc-supply = <_vcc>;
+ vqmmc-supply = <_vcc>;
+};
+
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi
b/arch/arm64/boot/dts/actions/s700.dtsi
index b1a34f95d44c..2bb29bc683ef 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
--
2.7.4
[PATCH v3 06/10] arm64: dts: actions: Add DMA Controller for S700
This commit adds DAM controller present on Actions S700, it differs from
S900 in terms of number of dma channels and requests.
Signed-off-by: Amit Singh Tomar
---
Changes since v2:
* added power-domain property as sps
is enabled now and DMA needs it.
Changes since v1:
* No Change.
Changes since RFC:
* No Change.
---
arch/arm64/boot/dts/actions/s700.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi
b/arch/arm64/boot/dts/actions/s700.dtsi
index f8eb72bb4125..605594dd7a0e 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
/ {
compatible = "actions,s700";
@@ -244,5 +245,19 @@
,
;
};
+
+ dma: dma-controller@e023 {
+ compatible = "actions,s700-dma";
+ reg = <0x0 0xe023 0x0 0x1000>;
+ interrupts = ,
+,
+,
+;
+ #dma-cells = <1>;
+ dma-channels = <10>;
+ dma-requests = <44>;
+ clocks = < CLK_DMAC>;
+ power-domains = < S700_PD_DMA>;
+ };
};
};
--
2.7.4
[PATCH v3 09/10] arm64: dts: actions: Add MMC controller support for S700
This commits adds support for MMC controllers present on Actions S700 SoC,
there are 3 MMC controllers in this SoC which can be used for accessing
SD/EMMC/SDIO cards.
Signed-off-by: Amit Singh Tomar
---
Changes since v2:
* No change.
Changes since v1:
* Added SoC specific compatibe string.
Changes since RFC:
* No change
---
arch/arm64/boot/dts/actions/s700.dtsi | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi
b/arch/arm64/boot/dts/actions/s700.dtsi
index 605594dd7a0e..b1a34f95d44c 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -259,5 +259,38 @@
clocks = < CLK_DMAC>;
power-domains = < S700_PD_DMA>;
};
+
+ mmc0: mmc@e021 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe021 0x0 0x4000>;
+ interrupts = ;
+ clocks = < CLK_SD0>;
+ resets = < RESET_SD0>;
+ dmas = < 2>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc1: mmc@e0214000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0214000 0x0 0x4000>;
+ interrupts = ;
+ clocks = < CLK_SD1>;
+ resets = < RESET_SD1>;
+ dmas = < 3>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc2: mmc@e0218000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0218000 0x0 0x4000>;
+ interrupts = ;
+ clocks = < CLK_SD2>;
+ resets = < RESET_SD2>;
+ dmas = < 4>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
};
};
--
2.7.4
[PATCH v3 07/10] dt-bindings: reset: s700: Add binding constants for mmc
This commit adds device tree binding reset constants for mmc controller present on Actions S700 Soc. Acked-by: Rob Herring Signed-off-by: Amit Singh Tomar --- Changes since v2: * No change. Changes since v1: * No change. Changes since RFC: * added Rob's acked-by tag --- include/dt-bindings/reset/actions,s700-reset.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/dt-bindings/reset/actions,s700-reset.h b/include/dt-bindings/reset/actions,s700-reset.h index 5e3b16b8ef53..a3118de6d7aa 100644 --- a/include/dt-bindings/reset/actions,s700-reset.h +++ b/include/dt-bindings/reset/actions,s700-reset.h @@ -30,5 +30,8 @@ #define RESET_UART420 #define RESET_UART521 #define RESET_UART622 +#define RESET_SD0 23 +#define RESET_SD1 24 +#define RESET_SD2 25 #endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */ -- 2.7.4
Re: [PATCH 2/2] remoteproc: qcom_q6v5_mss: Remove redundant running state
On Tue, Jun 2, 2020 at 9:33 AM Sibi Sankar wrote: > > Remove the redundant running state, as an equivalent is maintained in > the common q6v5 resource handling helpers. > > Signed-off-by: Sibi Sankar This variable was written to and never read, sigh. Thanks for cleaning it up. Reviewed-by: Evan Green
Re: [PATCH 5.4 000/139] 5.4.44-rc2 review
On Tue, 2 Jun 2020 at 15:54, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.44 release. > There are 139 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu, 04 Jun 2020 10:16:52 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.44-rc2.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.4.44-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: f5694d7c427e7134b05b816e56fc41c191c4782b git describe: v5.4.43-140-gf5694d7c427e Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.43-140-gf5694d7c427e No regressions (compared to build v5.4.43) No fixes (compared to build v5.4.43) Ran 25227 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-kasan - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * kselftest/networking * libgpiod * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * v4l2-compliance * kvm-unit-tests * ltp-commands-tests * ltp-cve-tests * ltp-dio-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-sched-tests * network-basic-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-native/networking * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * kselftest-vsyscall-mode-none/networking -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On Tue, Jun 02, 2020 at 10:18:09AM -0700, Linus Torvalds wrote: > You have exactly two cases: > > (a) the access_ok() would be right above the code and can't be missed > > (b) not (c) what you really want is not quite access_ok(). Again, that "not quite access_ok()" should be right next to STAC, and come from the same primitive - I'm not saying the current model is anywhere near sane. We need a range-checking primitive right next to memory access; it's just that for KVM and vhost we might want a different check and, for things like s390 and sparc (mips as well, in some configs), potentially different part that would do the memory access itself as well.
Re: [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop
On Tue, Jun 2, 2020 at 9:33 AM Sibi Sankar wrote:
>
> Sometimes the stop triggers a watchdog rather than a stop-ack. Update
> the running state to false on requesting stop to skip the watchdog
> instead.
>
> Error Logs:
> $ echo stop > /sys/class/remoteproc/remoteproc0/state
> ipa 1e4.ipa: received modem stopping event
> remoteproc-modem: watchdog received: sys_m_smsm_mpss.c:291:APPS force stop
> qcom-q6v5-mss 408.remoteproc-modem: port failed halt
> ipa 1e4.ipa: received modem offline event
> remoteproc0: stopped remote processor 408.remoteproc-modem
>
> Fixes: 3b415c8fb263 ("remoteproc: q6v5: Extract common resource handling")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sibi Sankar
> ---
Are you sure you want to tolerate this behavior from MSS? This is a
graceful shutdown, modem shouldn't have a problem completing the
proper handshake. If they do, isn't that a bug on the modem side?
I just worry this will mask real issues that happen during graceful shutdown.
-Evan
Re: [PATCH RFC] uaccess: user_access_begin_after_access_ok()
On Tue, Jun 02, 2020 at 06:44:30PM +0100, Al Viro wrote: > On Tue, Jun 02, 2020 at 10:18:09AM -0700, Linus Torvalds wrote: > > > > You have exactly two cases: > > > > (a) the access_ok() would be right above the code and can't be missed > > > > (b) not > >(c) what you really want is not quite access_ok(). > > Again, that "not quite access_ok()" should be right next to STAC, and > come from the same primitive - I'm not saying the current model is > anywhere near sane. We need a range-checking primitive right next > to memory access; it's just that for KVM and vhost we might want > a different check and, for things like s390 and sparc (mips as well, things like vhost on s390 and sparc, that is. > in some configs), potentially different part that would do the memory > access itself as well.
[GIT PULL] Hyper-V commits for 5.8
Hi Linus Please pull the signed tag for Hyper-V commits for 5.8. There is a conflict in arch/x86/include/asm/hyperv-tlfs.h with a patch in KVM tree. Michael Kelley and Jon Doron touched that file separately. Michael's patches are going through the Hyper-V tree while Jon's patches are going through KVM tree. A fix for the conflict can be found at: https://lore.kernel.org/lkml/20200602171802.560d0...@canb.auug.org.au/ For the same reason, you will see a build failure after merging Hyper-V and KVM tree. That's because a constant was renamed from HV_X64_DEBUGGING to HV_DEBUGGING. A patch to fix the build can be found at: https://lore.kernel.org/lkml/20200602173556.17ad0...@canb.auug.org.au/ The following changes since commit ae83d0b416db002fe95601e7f97f64b59514d936: Linux 5.7-rc2 (2020-04-19 14:35:30 -0700) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-next-signed for you to fetch changes up to afaa33da08abd10be8978781d7c99a9e67d2bbff: Drivers: hv: vmbus: Resolve more races involving init_vp_index() (2020-05-23 09:07:00 +) - A series from Andrea to support channel reassignment - A series from Vitaly to clean up Vmbus message handling - A series from Michael to clean up and augment hyperv-tlfs.h - Patches from Andy to clean up GUID usage in Hyper-V code - A few other misc patches Andrea Parri (Microsoft) (13): Drivers: hv: vmbus: Always handle the VMBus messages on CPU0 Drivers: hv: vmbus: Don't bind the offer works to a specific CPU Drivers: hv: vmbus: Replace the per-CPU channel lists with a global array of channels hv_netvsc: Disable NAPI before closing the VMBus channel hv_utils: Always execute the fcopy and vss callbacks in a tasklet Drivers: hv: vmbus: Use a spin lock for synchronizing channel scheduling vs. channel removal PCI: hv: Prepare hv_compose_msi_msg() for the VMBus-channel-interrupt-to-vCPU reassignment functionality Drivers: hv: vmbus: Remove the unused HV_LOCALIZED channel affinity logic Drivers: hv: vmbus: Synchronize init_vp_index() vs. CPU hotplug Drivers: hv: vmbus: Introduce the CHANNELMSG_MODIFYCHANNEL message type scsi: storvsc: Re-init stor_chns when a channel interrupt is re-assigned Drivers: hv: vmbus: Resolve race between init_vp_index() and CPU hotplug Drivers: hv: vmbus: Resolve more races involving init_vp_index() Andy Shevchenko (4): hyper-v: Use UUID API for exporting the GUID (part 2) hyper-v: Supply GUID pointer to printf() like functions hyper-v: Replace open-coded variant of %*phN specifier hyper-v: Switch to use UUID types directly Colin Ian King (1): drivers: hv: remove redundant assignment to pointer primary_channel Gustavo A. R. Silva (1): vmbus: Replace zero-length array with flexible-array Michael Kelley (4): KVM: x86: hyperv: Remove duplicate definitions of Reference TSC Page x86/hyperv: Remove HV_PROCESSOR_POWER_STATE #defines x86/hyperv: Split hyperv-tlfs.h into arch dependent and independent files asm-generic/hyperv: Add definitions for Get/SetVpRegister hypercalls Vitaly Kuznetsov (5): Drivers: hv: copy from message page only what's needed Drivers: hv: allocate the exact needed memory for messages Drivers: hv: avoid passing opaque pointer to vmbus_onmessage() Drivers: hv: make sure that 'struct vmbus_channel_message_header' compiles correctly Drivers: hv: check VMBus messages lengths Wei Liu (1): Driver: hv: vmbus: drop a no long applicable comment MAINTAINERS | 1 + arch/x86/include/asm/hyperv-tlfs.h | 472 +++--- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kvm/hyperv.c | 4 +- drivers/hv/channel.c| 58 +++-- drivers/hv/channel_mgmt.c | 439 +--- drivers/hv/connection.c | 58 + drivers/hv/hv.c | 16 +- drivers/hv/hv_fcopy.c | 2 +- drivers/hv/hv_snapshot.c| 2 +- drivers/hv/hv_trace.h | 25 +- drivers/hv/hyperv_vmbus.h | 81 -- drivers/hv/vmbus_drv.c | 314 +-- drivers/net/hyperv/netvsc.c | 7 +- drivers/pci/controller/pci-hyperv.c | 44 ++-- drivers/scsi/storvsc_drv.c | 96 ++- include/asm-generic/hyperv-tlfs.h | 493 include/linux/hyperv.h | 68 +++-- include/linux/mod_devicetable.h | 2 +- 19 files changed, 1309 insertions(+), 875 deletions(-) create mode 100644 include/asm-generic/hyperv-tlfs.h
Re: [PATCH v3 2/4] iio: chemical: scd30: add I2C interface driver
Hello Andy,
On Tue, Jun 02, 2020 at 08:14:13PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski
> wrote:
> >
> > Add I2C interface driver for the SCD30 sensor.
>
> ...
>
> > +static u16 scd30_i2c_cmd_lookup_tbl[] = {
> > + [CMD_START_MEAS] = 0x0010,
> > + [CMD_STOP_MEAS] = 0x0104,
> > + [CMD_MEAS_INTERVAL] = 0x4600,
> > + [CMD_MEAS_READY] = 0x0202,
> > + [CMD_READ_MEAS] = 0x0300,
> > + [CMD_ASC] = 0x5306,
> > + [CMD_FRC] = 0x5204,
> > + [CMD_TEMP_OFFSET] = 0x5403,
> > + [CMD_FW_VERSION] = 0xd100,
> > + [CMD_RESET] = 0xd304,
>
> Keep sorted by value?
>
I'd rather leave it as is simply because order here matches order in
sensor datasheet.
> > +};
>
> ...
>
> > + ret = i2c_master_send(client, txbuf, txsize);
>
> > + if (ret != txsize)
> > + return ret < 0 ? ret : -EIO;
>
> Wouldn't be better
>
> if (ret < 0)
> return ret;
> if (ret != txsize)
> return -EIO;
>
> ?
>
Hmm, okay. Perhaps slightly easier to read.
> > + if (!rxbuf)
> > + return 0;
> > +
> > + ret = i2c_master_recv(client, rxbuf, rxsize);
>
> > + if (ret != rxsize)
> > + return ret < 0 ? ret : -EIO;
>
> Ditto.
>
> ...
>
> > +static int scd30_i2c_command(struct scd30_state *state, enum scd30_cmd cmd,
> > +u16 arg, void *response, int size)
> > +{
> > + char crc, buf[SCD30_I2C_MAX_BUF_SIZE], *rsp = response;
> > + int i, ret;
>
> i -> offset ?
>
'i' is shorter and I am lazy :).
> > + put_unaligned_be16(scd30_i2c_cmd_lookup_tbl[cmd], buf);
> > + i = 2;
> > +
> > + if (rsp) {
> > + /* each two bytes are followed by a crc8 */
> > + size += size / 2;
> > + } else {
> > + put_unaligned_be16(arg, buf + i);
> > + crc = crc8(scd30_i2c_crc8_tbl, buf + i, 2, CRC8_INIT_VALUE);
> > + i += 2;
>
> > + buf[i] = crc;
> > + i += 1;
>
> buf[offset++] = crc; ?
>
I'd rather stick to what I have now. It looks more consistent.
> > + /* commands below don't take an argument */
> > + if ((cmd == CMD_STOP_MEAS) || (cmd == CMD_RESET))
> > + i -= 3;
> > + }
> > +
> > + ret = scd30_i2c_xfer(state, buf, i, buf, size);
> > + if (ret)
> > + return ret;
> > +
> > + /* validate received data and strip off crc bytes */
> > + for (i = 0; i < size; i += 3) {
> > + crc = crc8(scd30_i2c_crc8_tbl, buf + i, 2, CRC8_INIT_VALUE);
> > + if (crc != buf[i + 2]) {
> > + dev_err(state->dev, "data integrity check
> > failed\n");
> > + return -EIO;
> > + }
> > +
>
> > + *rsp++ = buf[i];
>
> + 0 (for the sake of consistency?
>
Adding 0 is a little bit odd.
> > + *rsp++ = buf[i + 1];
> > + }
> > +
> > + return 0;
> > +}
>
> ...
>
> > +static struct i2c_driver scd30_i2c_driver = {
> > + .driver = {
>
> > + .name = KBUILD_MODNAME,
>
> Better to hard code.
>
I seriously doubt anyone will ever want to change module name. What for?
> > + .of_match_table = scd30_i2c_of_match,
> > + .pm = _pm_ops,
> > + },
> > + .probe_new = scd30_i2c_probe,
> > +};
>
> --
> With Best Regards,
> Andy Shevchenko
Re: [PATCH v3 015/105] drm/vc4: hvs: Boost the core clock during modeset
On Tue, Jun 2, 2020 at 5:52 AM Maxime Ripard wrote: > > Hi Eric, > > On Wed, May 27, 2020 at 09:33:44AM -0700, Eric Anholt wrote: > > On Wed, May 27, 2020 at 8:49 AM Maxime Ripard wrote: > > > > > > In order to prevent timeouts and stalls in the pipeline, the core clock > > > needs to be maxed at 500MHz during a modeset on the BCM2711. > > > > Like, the whole system's core clock? > > Yep, unfortunately... > > > How is it reasonable for some device driver to crank the system's core > > clock up and back down to some fixed-in-the-driver frequency? Sounds > > like you need some sort of opp thing here. > > That frequency is the minimum rate of that clock. However, since other > devices have similar requirements (unicam in particular) with different > minimum requirements, we will switch to setting a minimum rate instead > of enforcing a particular rate, so that patch would be essentially > s/clk_set_rate/clk_set_min_rate/. clk_set_min_rate makes a lot more sense to me. r-b with that obvious change. Thanks!
Re: PANIC: double fault in fixup_bad_iret
You were a bit faster with the other patches ;-) I was still experimenting the the patches, but let me briefly respond here. On Tue, 2 Jun 2020 at 11:41, Peter Zijlstra wrote: > > On Mon, Jun 01, 2020 at 02:40:31PM +0200, Marco Elver wrote: > > I think Peter wanted to send a patch to add __no_kcsan to noinstr: > > https://lkml.kernel.org/r/20200529170755.gn706...@hirez.programming.kicks-ass.net > > > > In the same patch we can add __no_sanitize_address to noinstr. But: > > > > - We're missing a definition for __no_sanitize_undefined and > > __no_sanitize_coverage. > > Do those function attributes actually work? Because the last time I > played with some of that I didn't. __no_sanitize_coverage won't work, because neither compiler has an attribute to disable coverage instrumentation. I'll try and add this to compilers, but KCOV_INSTRUMENT := n is in the right places right now it seems. More on that in the patch adding this. > Specifically: unmarked __always_inline functions must not generate > instrumentation when they're inlined into a __no_*san function. > > (and that fails to build on some GCC versions, and I think fails to > actually work on the rest of them, but I'd have to double check) We'll probably need to bump the required compiler version if anybody still attempts to use these old compilers with sanitizers. The precise versions of compilers and what mixes with what is a bit of a nightmare. For now I'd just say, let's add the attributes, and see where that gets us. Surely it won't be more broken than before. ;-) > > - We still need the above blanket no-instrument for x86 because of > > GCC. We could guard it with "ifdef CONFIG_CC_IS_GCC". > > Right; so all of GCC is broken vs that function attribute stuff? Any > plans of getting that fixed? Do we have GCC that care? > > Does the GCC plugin approach sound like a viable alternative > implementation of all this? I don't think it's realistic to maintain a GCC plugin like that indefinitely. We can investigate, but it's not a quick fix. > Anyway, we can make it: > > KASAN := SANITIZER_HAS_FUNCTION_ATTRIBUTES > > or something, and only make that 'y' when the compiler is sane. We have all attributes except __no_sanitize_coverage. GCC <= 7 has problems with __always_inline, so we may just have to bump the required compiler or emit a warning. > > Not sure what the best strategy is to minimize patch conflicts. For > > now I could send just the patches to add missing definitions. If you'd > > like me to send all patches (including modifying 'noinstr'), let me > > know. > > If you're going to do patches anyway, might as well do that :-) I was stuck on trying to find ways to emulate __no_sanitize_coverage (with no success), and then agonizing which patches to send in which sequence. ;-) You made that decision by sending the KCSAN noinstr series first, so let me respond to that with what I think we can add for KASAN and UBSAN at least. Thanks, -- Marco
Re: [PATCH 04/13] perf tests: Add another metric parsing test
On Tue, Jun 2, 2020 at 4:51 AM Jiri Olsa wrote:
>
> The test goes through all metrics compiled for arch
> within pmu events and try to parse them.
>
> This test is different from 'test_parsing' in that
> we go through all the events in the current arch,
> not just one defined for current CPU model. Using
> 'fake_pmu' to parse events which do not have PMUs
> defined in the system.
>
> Say there's bad change in ivybridge metrics file, like:
>
> --- a/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json
> +++ b/tools/perf/pmu-events/arch/x86/ivybridge/ivb-metrics.json
> @@ -8,7 +8,7 @@
> -"MetricExpr": "IDQ_UOPS_NOT_DELIVERED.CORE / (4 * ((
> +"MetricExpr": "IDQ_UOPS_NOT_DELIVERED.CORE / / (4 *
>
> the test fails with (on my kabylake laptop):
>
> $ perf test 'Parsing of PMU event table metrics with fake PMUs' -v
> parsing 'idq_uops_not_delivered.core / / (4 * (( ( cpu_clk_unh...
> syntax error, line 1
> expr__parse failed
> test child finished with -1
> ...
For this example as the problem is the expression, presumably this was
"passing" with test_parsing due to returning TEST_SKIP? I did this
initially so that we could get the test merged and then the metrics
fixed. I'd prefer if test_parsing were returning TEST_FAIL.
> The test also defines its own list of metrics and
> tries to parse them. It's handy for developing.
>
> Signed-off-by: Jiri Olsa
> ---
> tools/perf/tests/pmu-events.c | 117 +-
> 1 file changed, 114 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/tests/pmu-events.c b/tools/perf/tests/pmu-events.c
> index f65380d2066f..d3343827eb4d 100644
> --- a/tools/perf/tests/pmu-events.c
> +++ b/tools/perf/tests/pmu-events.c
> @@ -390,7 +390,8 @@ static bool is_number(const char *str)
> return errno == 0 && end_ptr != str;
> }
>
> -static int check_parse_id(const char *id, struct parse_events_error *error)
> +static int check_parse_id(const char *id, struct parse_events_error *error,
> + bool fake_pmu)
> {
> struct evlist *evlist;
> int ret;
> @@ -403,7 +404,7 @@ static int check_parse_id(const char *id, struct
> parse_events_error *error)
> if (!evlist)
> return -ENOMEM;
> memset(error, 0, sizeof(*error));
> - ret = parse_events(evlist, id, error, false);
> + ret = parse_events(evlist, id, error, fake_pmu);
> evlist__delete(evlist);
> return ret;
> }
> @@ -412,7 +413,7 @@ static int check_parse_cpu(const char *id, bool same_cpu,
> struct pmu_event *pe)
> {
> struct parse_events_error error;
>
> - int ret = check_parse_id(id, );
> + int ret = check_parse_id(id, , false);
> if (ret && same_cpu) {
> pr_warning("Parse event failed metric '%s' id '%s' expr
> '%s'\n",
> pe->metric_name, id, pe->metric_expr);
> @@ -430,6 +431,18 @@ static int check_parse_cpu(const char *id, bool
> same_cpu, struct pmu_event *pe)
> return ret;
> }
>
> +static int check_parse_fake(const char *id)
> +{
> + struct parse_events_error error;
nit: this reads funny as it isn't clear, without looking at
check_parse_id, that error is zero initialized.
Thanks,
Ian
> + int ret = check_parse_id(id, , true);
> +
> + free(error.str);
> + free(error.help);
> + free(error.first_str);
> + free(error.first_help);
> + return ret;
> +}
> +
> static void expr_failure(const char *msg,
> const struct pmu_events_map *map,
> const struct pmu_event *pe)
> @@ -499,6 +512,100 @@ static int test_parsing(void)
> return ret == 0 ? TEST_OK : TEST_SKIP;
> }
>
> +struct test_metric {
> + const char *str;
> +};
> +
> +static struct test_metric metrics[] = {
> + { "(unc_p_power_state_occupancy.cores_c0 / unc_p_clockticks) * 100."
> },
> + { "imx8_ddr0@read\\-cycles@ * 4 * 4", },
> + { "imx8_ddr0@axid\\-read\\,axi_mask\\=0x\\,axi_id\\=0x@ * 4",
> },
> + { "(cstate_pkg@c2\\-residency@ / msr@tsc@) * 100", },
> + { "(imx8_ddr0@read\\-cycles@ + imx8_ddr0@write\\-cycles@)", },
> +};
> +
> +static int metric_parse_fake(const char *str)
> +{
> + struct expr_parse_ctx ctx;
> + struct hashmap_entry *cur;
> + double result;
> + int ret = -1;
> + size_t bkt;
> + int i;
> +
> + pr_debug("parsing '%s'\n", str);
> +
> + expr__ctx_init();
> + if (expr__find_other(str, NULL, , 0) < 0) {
> + pr_err("expr__find_other failed\n");
> + return -1;
> + }
> +
> + /*
> +* Add all ids with a made up value. The value may
> +* trigger divide by zero when subtracted and so try to
> +* make them unique.
> +*/
> + i = 1;
> + hashmap__for_each_entry((), cur, bkt)
> + expr__add_id(, strdup(cur->key), i++);
> +
> +
Re: [PATCH v3 3/4] iio: chemical: scd30: add serial interface driver
On Tue, Jun 02, 2020 at 08:04:16PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 2, 2020 at 7:49 PM Tomasz Duszynski
> wrote:
> >
> > Add serial interface driver for the SCD30 sensor.
>
> ...
>
> > +static u16 scd30_serdev_cmd_lookup_tbl[] = {
> > + [CMD_START_MEAS] = 0x0036,
> > + [CMD_STOP_MEAS] = 0x0037,
> > + [CMD_MEAS_INTERVAL] = 0x0025,
> > + [CMD_MEAS_READY] = 0x0027,
> > + [CMD_READ_MEAS] = 0x0028,
> > + [CMD_ASC] = 0x003a,
> > + [CMD_FRC] = 0x0039,
> > + [CMD_TEMP_OFFSET] = 0x003b,
> > + [CMD_FW_VERSION] = 0x0020,
> > + [CMD_RESET] = 0x0034,
>
> Hmm... Can't we keep them ordered by value?
>
> > +};
>
> ...
>
> > + ret = wait_for_completion_interruptible_timeout(>meas_ready,
> > +
> > SCD30_SERDEV_TIMEOUT);
> > + if (ret > 0)
> > + ret = 0;
> > + else if (!ret)
> > + ret = -ETIMEDOUT;
> > +
> > + return ret;
>
> Perhaps
>
> if (ret < 0)
> return ret;
> if (ret == 0)
> return -ETIMEDOUT;
> return 0;
>
> ?
Matter of style but since I will be doing other changes I can touch that
too.
>
> ...
>
> > + char txbuf[SCD30_SERDEV_MAX_BUF_SIZE] = { SCD30_SERDEV_ADDR },
> > +rxbuf[SCD30_SERDEV_MAX_BUF_SIZE], *rsp = response;
>
> Please, apply type to each variable separately.
>
Fine.
> ...
>
> > + switch (txbuf[1]) {
> > + case SCD30_SERDEV_WRITE:
>
> > + if (memcmp(txbuf, txbuf, txsize)) {
>
> I'm not sure I understand this.
>
Ah, thanks for catching this. tx should be compared to rx.
> > + dev_err(state->dev, "wrong message received\n");
> > + return -EIO;
> > + }
> > + break;
> > + case SCD30_SERDEV_READ:
>
> > + if (rxbuf[2] != (rxsize -
> > +SCD30_SERDEV_RX_HEADER_SIZE -
> > +SCD30_SERDEV_CRC_SIZE)) {
>
> Perhaps you can come up with better indentation/ line split?
>
I'd rather leave it as is.
> > + dev_err(state->dev,
> > + "received data size does not match
> > header\n");
> > + return -EIO;
> > + }
> > +
> > + rxsize -= SCD30_SERDEV_CRC_SIZE;
> > + crc = get_unaligned_le16(rxbuf + rxsize);
> > + if (crc != scd30_serdev_calc_crc(rxbuf, rxsize)) {
> > + dev_err(state->dev, "data integrity check
> > failed\n");
> > + return -EIO;
> > + }
> > +
> > + rxsize -= SCD30_SERDEV_RX_HEADER_SIZE;
> > + memcpy(rsp, rxbuf + SCD30_SERDEV_RX_HEADER_SIZE, rxsize);
> > + break;
> > + default:
> > + dev_err(state->dev, "received unknown op code\n");
> > + return -EIO;
> > + }
> > +
> > + return 0;
> > +}
>
> ...
>
> > +static struct serdev_device_driver scd30_serdev_driver = {
> > + .driver = {
>
> > + .name = KBUILD_MODNAME,
>
> This is not the best what we can do. The name is an ABI and better if
> it will be constant (independent on file name).
>
> > + .of_match_table = scd30_serdev_of_match,
> > + .pm = _pm_ops,
> > + },
> > + .probe = scd30_serdev_probe,
> > +};
>
> --
> With Best Regards,
> Andy Shevchenko
Re: PANIC: double fault in fixup_bad_iret
On Tue, Jun 02, 2020 at 07:51:40PM +0200, Marco Elver wrote: > We have all attributes except __no_sanitize_coverage. GCC <= 7 has > problems with __always_inline, so we may just have to bump the > required compiler or emit a warning. GCC <= 7 will hard fail the compile with those function attributes. Bumping the min GCC version for KASAN/UBSAN to avoid that might be best. > > > Not sure what the best strategy is to minimize patch conflicts. For > > > now I could send just the patches to add missing definitions. If you'd > > > like me to send all patches (including modifying 'noinstr'), let me > > > know. > > > > If you're going to do patches anyway, might as well do that :-) > > I was stuck on trying to find ways to emulate __no_sanitize_coverage > (with no success), and then agonizing which patches to send in which > sequence. ;-) You made that decision by sending the KCSAN noinstr > series first, so let me respond to that with what I think we can add > for KASAN and UBSAN at least. Excellent, thanks!
Re: [PATCHv1 00/19] Improve SBS battery support
Hi, On Tue, Jun 02, 2020 at 09:17:09AM +0200, Marek Szyprowski wrote: > Hi Sebastian, > > On 01.06.2020 19:05, Sebastian Reichel wrote: > > On Mon, Jun 01, 2020 at 12:40:27PM +0200, Marek Szyprowski wrote: > >> On 13.05.2020 20:55, Sebastian Reichel wrote: > >>> This patchset improves support for SBS compliant batteries. Due to > >>> the changes, the battery now exposes 32 power supply properties and > >>> (un)plugging it generates a backtrace containing the following message > >>> without the first patch in this series: > >>> > >>> --- > >>> WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 > >>> add_uevent_var+0xd4/0x104 > >>> add_uevent_var: too many keys > >>> --- > >>> > >>> For references this is what an SBS battery status looks like after > >>> the patch series has been applied: > >>> > >>> cat /sys/class/power_supply/sbs-0-000b/uevent > >>> POWER_SUPPLY_NAME=sbs-0-000b > >>> POWER_SUPPLY_TYPE=Battery > >>> POWER_SUPPLY_STATUS=Discharging > >>> POWER_SUPPLY_CAPACITY_LEVEL=Normal > >>> POWER_SUPPLY_HEALTH=Good > >>> POWER_SUPPLY_PRESENT=1 > >>> POWER_SUPPLY_TECHNOLOGY=Li-ion > >>> POWER_SUPPLY_CYCLE_COUNT=12 > >>> POWER_SUPPLY_VOLTAGE_NOW=11441000 > >>> POWER_SUPPLY_CURRENT_NOW=-26000 > >>> POWER_SUPPLY_CURRENT_AVG=-24000 > >>> POWER_SUPPLY_CAPACITY=76 > >>> POWER_SUPPLY_CAPACITY_ERROR_MARGIN=1 > >>> POWER_SUPPLY_TEMP=198 > >>> POWER_SUPPLY_TIME_TO_EMPTY_AVG=438600 > >>> POWER_SUPPLY_TIME_TO_FULL_AVG=3932100 > >>> POWER_SUPPLY_SERIAL_NUMBER= > >>> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=1080 > >>> POWER_SUPPLY_VOLTAGE_MAX_DESIGN=1080 > >>> POWER_SUPPLY_ENERGY_NOW=3109 > >>> POWER_SUPPLY_ENERGY_FULL=4245 > >>> POWER_SUPPLY_ENERGY_FULL_DESIGN=4104 > >>> POWER_SUPPLY_CHARGE_NOW=2924000 > >>> POWER_SUPPLY_CHARGE_FULL=3898000 > >>> POWER_SUPPLY_CHARGE_FULL_DESIGN=380 > >>> POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=300 > >>> POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=1230 > >>> POWER_SUPPLY_MANUFACTURE_YEAR=2017 > >>> POWER_SUPPLY_MANUFACTURE_MONTH=7 > >>> POWER_SUPPLY_MANUFACTURE_DAY=3 > >>> POWER_SUPPLY_MANUFACTURER=UR18650A > >>> POWER_SUPPLY_MODEL_NAME=GEHC > >> This patch landed in linux-next dated 20200529. Sadly it causes a > >> regression on Samsung Exynos-based Chromebooks (Exynos5250 Snow, > >> Exynos5420 Peach-Pi and Exynos5800 Peach-Pit). System boots to > >> userspace, but then, when udev populates /dev, booting hangs: > >> > >> [ 4.435167] VFS: Mounted root (ext4 filesystem) readonly on device > >> 179:51. > >> [ 4.457477] devtmpfs: mounted > >> [ 4.460235] Freeing unused kernel memory: 1024K > >> [ 4.464022] Run /sbin/init as init process > >> INIT: version 2.88 booting > >> [info] Using makefile-style concurrent boot in runlevel S. > >> [ 5.102096] random: crng init done > >> [] Starting the hotplug events dispatcher: systemd-udevdstarting > >> version 236 > >> [ ok . > >> [] Synthesizing the initial hotplug events...[ ok done. > >> [] Waiting for /dev to be fully populated...[ 34.409914] > >> TPS65090_RAILSDCDC1: disabling > >> [ 34.412977] TPS65090_RAILSDCDC2: disabling > >> [ 34.417021] TPS65090_RAILSDCDC3: disabling > >> [ 34.423848] TPS65090_RAILSLDO1: disabling > >> [ 34.429068] TPS65090_RAILSLDO2: disabling > > :( > > > > log does not look useful either. > > > >> Bisect between v5.7-rc1 and next-20200529 pointed me to the first bad > >> commit: [c4b12a2f3f3de670f6be5e96092a2cab0b877f1a] power: supply: > >> sbs-battery: simplify read_read_string_data. > > ok. I tested this on an to-be-upstreamed i.MX6 based system > > and arch/arm/boot/dts/imx53-ppd.dts. I think the difference > > is, that i2c-exynos5 does not expose I2C_FUNC_SMBUS_READ_BLOCK_DATA. > > I hoped all systems using SBS battery support this, but now > > I see I2C_FUNC_SMBUS_EMUL only supports writing block data. > > Looks like I need to add another patch implementing that > > using the old code with added PEC support. > > > > In any case that should only return -ENODEV for the property > > (and uevent), but not break boot. So something fishy is going > > on. > > > >> However reverting it in linux-next doesn't fix the issue, so the > >> next commits are also relevant to this issue. > > The next patch, which adds PEC support depends on the simplification > > of sbs_read_string_data. The old, open coded variant will result in > > PEC failure for string properties (which should not stop boot either > > of course). Can you try reverting both? > Indeed, reverting both (and fixing the conflict) restores proper boot. Ok, I pushed out a revert of those two patches. They should land in tomorrows linux-next release. Please test it. > > If that helps I will revert those two instead of dropping the whole > > series for this merge window. > > > >> Let me know how can I help debugging it. > > I suspect, that this is userspace endlessly retrying reading the > > battery uevent when an error is returned. Could you check
[PATCH 5/6] arm64/vdso: Restrict splitting VVAR VMA
Forbid splitting VVAR VMA resulting in a stricter ABI and reducing the
amount of corner-cases to consider while working further on VDSO time
namespace support.
As the offset from timens to VVAR page is computed compile-time, the pages
in VVAR should stay together and not being partically mremap()'ed.
Reviewed-by: Vincenzo Frascino
Signed-off-by: Andrei Vagin
---
arch/arm64/kernel/vdso.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index f3baecd8edfb..8b17d7d10729 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -235,6 +235,17 @@ static vm_fault_t vvar_fault(const struct
vm_special_mapping *sm,
return vmf_insert_pfn(vma, vmf->address, pfn);
}
+static int vvar_mremap(const struct vm_special_mapping *sm,
+ struct vm_area_struct *new_vma)
+{
+ unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
+
+ if (new_size != VVAR_NR_PAGES * PAGE_SIZE)
+ return -EINVAL;
+
+ return 0;
+}
+
static int __setup_additional_pages(enum arch_vdso_type arch_index,
struct mm_struct *mm,
struct linux_binprm *bprm,
@@ -317,6 +328,7 @@ static struct vm_special_mapping aarch32_vdso_spec[C_PAGES]
= {
{
.name = "[vvar]",
.fault = vvar_fault,
+ .mremap = vvar_mremap,
},
{
.name = "[vdso]",
@@ -488,6 +500,7 @@ static struct vm_special_mapping vdso_spec[A_PAGES]
__ro_after_init = {
{
.name = "[vvar]",
.fault = vvar_fault,
+ .mremap = vvar_mremap,
},
{
.name = "[vdso]",
--
2.24.1
[PATCH 4/6] arm64/vdso: Handle faults on timens page
If a task belongs to a time namespace then the VVAR page which contains
the system wide VDSO data is replaced with a namespace specific page
which has the same layout as the VVAR page.
Reviewed-by: Vincenzo Frascino
Signed-off-by: Andrei Vagin
---
arch/arm64/kernel/vdso.c | 57 +---
1 file changed, 53 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 1fa6f9362e56..f3baecd8edfb 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -175,15 +176,63 @@ int vdso_join_timens(struct task_struct *task, struct
time_namespace *ns)
up_write(>mmap_sem);
return 0;
}
+
+static struct page *find_timens_vvar_page(struct vm_area_struct *vma)
+{
+ if (likely(vma->vm_mm == current->mm))
+ return current->nsproxy->time_ns->vvar_page;
+
+ /*
+* VM_PFNMAP | VM_IO protect .fault() handler from being called
+* through interfaces like /proc/$pid/mem or
+* process_vm_{readv,writev}() as long as there's no .access()
+* in special_mapping_vmops().
+* For more details check_vma_flags() and __access_remote_vm()
+*/
+
+ WARN(1, "vvar_page accessed remotely");
+
+ return NULL;
+}
+#else
+static inline struct page *find_timens_vvar_page(struct vm_area_struct *vma)
+{
+ return NULL;
+}
#endif
static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
struct vm_area_struct *vma, struct vm_fault *vmf)
{
- if (vmf->pgoff == 0)
- return vmf_insert_pfn(vma, vmf->address,
- sym_to_pfn(vdso_data));
- return VM_FAULT_SIGBUS;
+ struct page *timens_page = find_timens_vvar_page(vma);
+ unsigned long pfn;
+
+ switch (vmf->pgoff) {
+ case VVAR_DATA_PAGE_OFFSET:
+ if (timens_page)
+ pfn = page_to_pfn(timens_page);
+ else
+ pfn = sym_to_pfn(vdso_data);
+ break;
+#ifdef CONFIG_TIME_NS
+ case VVAR_TIMENS_PAGE_OFFSET:
+ /*
+* If a task belongs to a time namespace then a namespace
+* specific VVAR is mapped with the VVAR_DATA_PAGE_OFFSET and
+* the real VVAR page is mapped with the VVAR_TIMENS_PAGE_OFFSET
+* offset.
+* See also the comment near timens_setup_vdso_data().
+*/
+ if (!timens_page)
+ return VM_FAULT_SIGBUS;
+ pfn = sym_to_pfn(vdso_data);
+ break;
+#endif /* CONFIG_TIME_NS */
+ default:
+ return VM_FAULT_SIGBUS;
+ }
+
+ return vmf_insert_pfn(vma, vmf->address, pfn);
}
static int __setup_additional_pages(enum arch_vdso_type arch_index,
--
2.24.1
[PATCH 3/6] arm64/vdso: Add time namespace page
Allocate the time namespace page among VVAR pages. Provide
__arch_get_timens_vdso_data() helper for VDSO code to get the
code-relative position of VVARs on that special page.
If a task belongs to a time namespace then the VVAR page which contains
the system wide VDSO data is replaced with a namespace specific page
which has the same layout as the VVAR page. That page has vdso_data->seq
set to 1 to enforce the slow path and vdso_data->clock_mode set to
VCLOCK_TIMENS to enforce the time namespace handling path.
The extra check in the case that vdso_data->seq is odd, e.g. a concurrent
update of the VDSO data is in progress, is not really affecting regular
tasks which are not part of a time namespace as the task is spin waiting
for the update to finish and vdso_data->seq to become even again.
If a time namespace task hits that code path, it invokes the corresponding
time getter function which retrieves the real VVAR page, reads host time
and then adds the offset for the requested clock which is stored in the
special VVAR page.
Cc: Mark Rutland
Reviewed-by: Vincenzo Frascino
Signed-off-by: Andrei Vagin
---
arch/arm64/include/asm/vdso.h | 6 +
.../include/asm/vdso/compat_gettimeofday.h| 12 ++
arch/arm64/include/asm/vdso/gettimeofday.h| 8 +++
arch/arm64/kernel/vdso.c | 22 ---
arch/arm64/kernel/vdso/vdso.lds.S | 5 -
arch/arm64/kernel/vdso32/vdso.lds.S | 5 -
include/vdso/datapage.h | 1 +
7 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/vdso.h b/arch/arm64/include/asm/vdso.h
index 07468428fd29..351c145d3808 100644
--- a/arch/arm64/include/asm/vdso.h
+++ b/arch/arm64/include/asm/vdso.h
@@ -12,6 +12,12 @@
*/
#define VDSO_LBASE 0x0
+#ifdef CONFIG_TIME_NS
+#define __VVAR_PAGES2
+#else
+#define __VVAR_PAGES1
+#endif
+
#ifndef __ASSEMBLY__
#include
diff --git a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
index b6907ae78e53..b7c549d46d18 100644
--- a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
@@ -152,6 +152,18 @@ static __always_inline const struct vdso_data
*__arch_get_vdso_data(void)
return ret;
}
+#ifdef CONFIG_TIME_NS
+static __always_inline const struct vdso_data
*__arch_get_timens_vdso_data(void)
+{
+ const struct vdso_data *ret;
+
+ /* See __arch_get_vdso_data(). */
+ asm volatile("mov %0, %1" : "=r"(ret) : "r"(_timens_data));
+
+ return ret;
+}
+#endif
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_VDSO_GETTIMEOFDAY_H */
diff --git a/arch/arm64/include/asm/vdso/gettimeofday.h
b/arch/arm64/include/asm/vdso/gettimeofday.h
index afba6ba332f8..cf39eae5eaaf 100644
--- a/arch/arm64/include/asm/vdso/gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/gettimeofday.h
@@ -96,6 +96,14 @@ const struct vdso_data *__arch_get_vdso_data(void)
return _vdso_data;
}
+#ifdef CONFIG_TIME_NS
+static __always_inline
+const struct vdso_data *__arch_get_timens_vdso_data(void)
+{
+ return _timens_data;
+}
+#endif
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_VDSO_GETTIMEOFDAY_H */
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 33df3cdf7982..1fa6f9362e56 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -46,6 +46,14 @@ enum arch_vdso_type {
#define VDSO_TYPES (ARM64_VDSO + 1)
#endif /* CONFIG_COMPAT_VDSO */
+enum vvar_pages {
+ VVAR_DATA_PAGE_OFFSET,
+#ifdef CONFIG_TIME_NS
+ VVAR_TIMENS_PAGE_OFFSET,
+#endif /* CONFIG_TIME_NS */
+ VVAR_NR_PAGES,
+};
+
struct __vdso_abi {
const char *name;
const char *vdso_code_start;
@@ -81,6 +89,12 @@ static union {
} vdso_data_store __page_aligned_data;
struct vdso_data *vdso_data = vdso_data_store.data;
+
+struct vdso_data *arch_get_vdso_data(void *vvar_page)
+{
+ return (struct vdso_data *)(vvar_page);
+}
+
static int __vdso_remap(enum arch_vdso_type arch_index,
const struct vm_special_mapping *sm,
struct vm_area_struct *new_vma)
@@ -180,9 +194,11 @@ static int __setup_additional_pages(enum arch_vdso_type
arch_index,
unsigned long vdso_base, vdso_text_len, vdso_mapping_len;
void *ret;
+ BUILD_BUG_ON(VVAR_NR_PAGES != __VVAR_PAGES);
+
vdso_text_len = vdso_lookup[arch_index].vdso_pages << PAGE_SHIFT;
/* Be sure to map the data page */
- vdso_mapping_len = vdso_text_len + PAGE_SIZE;
+ vdso_mapping_len = vdso_text_len + VVAR_NR_PAGES * PAGE_SIZE;
vdso_base = get_unmapped_area(NULL, 0, vdso_mapping_len, 0, 0);
if (IS_ERR_VALUE(vdso_base)) {
@@ -190,13 +206,13 @@ static int __setup_additional_pages(enum arch_vdso_type
arch_index,
goto up_fail;
}
- ret =
[PATCH 2/6] arm64/vdso: Zap vvar pages when switching to a time namespace
The VVAR page layout depends on whether a task belongs to the root or
non-root time namespace. Whenever a task changes its namespace, the VVAR
page tables are cleared and then they will be re-faulted with a
corresponding layout.
Reviewed-by: Vincenzo Frascino
Signed-off-by: Andrei Vagin
---
arch/arm64/kernel/vdso.c | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 031ee1a8d4a8..33df3cdf7982 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -131,6 +131,38 @@ static int __vdso_init(enum arch_vdso_type arch_index)
return 0;
}
+#ifdef CONFIG_TIME_NS
+/*
+ * The vvar page layout depends on whether a task belongs to the root or
+ * non-root time namespace. Whenever a task changes its namespace, the VVAR
+ * page tables are cleared and then they will re-faulted with a
+ * corresponding layout.
+ * See also the comment near timens_setup_vdso_data() for details.
+ */
+int vdso_join_timens(struct task_struct *task, struct time_namespace *ns)
+{
+ struct mm_struct *mm = task->mm;
+ struct vm_area_struct *vma;
+
+ if (down_write_killable(>mmap_sem))
+ return -EINTR;
+
+ for (vma = mm->mmap; vma; vma = vma->vm_next) {
+ unsigned long size = vma->vm_end - vma->vm_start;
+
+ if (vma_is_special_mapping(vma, vdso_lookup[ARM64_VDSO].dm))
+ zap_page_range(vma, vma->vm_start, size);
+#ifdef CONFIG_COMPAT_VDSO
+ if (vma_is_special_mapping(vma, vdso_lookup[ARM64_VDSO32].dm))
+ zap_page_range(vma, vma->vm_start, size);
+#endif
+ }
+
+ up_write(>mmap_sem);
+ return 0;
+}
+#endif
+
static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
struct vm_area_struct *vma, struct vm_fault *vmf)
{
--
2.24.1
[PATCH 6/6] arm64: enable time namespace support
CONFIG_TIME_NS is dependes on GENERIC_VDSO_TIME_NS. Reviewed-by: Vincenzo Frascino Signed-off-by: Andrei Vagin --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 5d513f461957..27d7e4ed1c93 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -111,6 +111,7 @@ config ARM64 select GENERIC_STRNLEN_USER select GENERIC_TIME_VSYSCALL select GENERIC_GETTIMEOFDAY + select GENERIC_VDSO_TIME_NS select HANDLE_DOMAIN_IRQ select HARDIRQS_SW_RESEND select HAVE_PCI -- 2.24.1
