Re: [PATCH] [v2] i2c: stm32f7: Fix runtime PM imbalance on error
Hi,
Reviewed-by: Alain Volmat
Thanks,
Alain
On Wed, May 27, 2020 at 01:38:53AM +, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a pairing decrement is needed
> on the error handling path to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu
> ---
>
> Changelog:
>
> v2: - Use pm_runtime_put_noidle() instead of
> pm_runtime_put_autosuspend(). Fix 5 more
> similar cases within this dirver.
> ---
> drivers/i2c/busses/i2c-stm32f7.c | 24 ++--
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-stm32f7.c
> b/drivers/i2c/busses/i2c-stm32f7.c
> index 330ffed011e0..822fd1f5b5ae 100644
> --- a/drivers/i2c/busses/i2c-stm32f7.c
> +++ b/drivers/i2c/busses/i2c-stm32f7.c
> @@ -1620,8 +1620,10 @@ static int stm32f7_i2c_xfer(struct i2c_adapter
> *i2c_adap,
> f7_msg->smbus = false;
>
> ret = pm_runtime_get_sync(i2c_dev->dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_noidle(i2c_dev->dev);
> return ret;
> + }
>
> ret = stm32f7_i2c_wait_free_bus(i2c_dev);
> if (ret)
> @@ -1666,8 +1668,10 @@ static int stm32f7_i2c_smbus_xfer(struct i2c_adapter
> *adapter, u16 addr,
> f7_msg->smbus = true;
>
> ret = pm_runtime_get_sync(dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_noidle(dev);
> return ret;
> + }
>
> ret = stm32f7_i2c_wait_free_bus(i2c_dev);
> if (ret)
> @@ -1767,8 +1771,10 @@ static int stm32f7_i2c_reg_slave(struct i2c_client
> *slave)
> return ret;
>
> ret = pm_runtime_get_sync(dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_noidle(dev);
> return ret;
> + }
>
> if (!stm32f7_i2c_is_slave_registered(i2c_dev))
> stm32f7_i2c_enable_wakeup(i2c_dev, true);
> @@ -1837,8 +1843,10 @@ static int stm32f7_i2c_unreg_slave(struct i2c_client
> *slave)
> WARN_ON(!i2c_dev->slave[id]);
>
> ret = pm_runtime_get_sync(i2c_dev->dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_noidle(i2c_dev->dev);
> return ret;
> + }
>
> if (id == 0) {
> mask = STM32F7_I2C_OAR1_OA1EN;
> @@ -2182,8 +2190,10 @@ static int stm32f7_i2c_regs_backup(struct
> stm32f7_i2c_dev *i2c_dev)
> struct stm32f7_i2c_regs *backup_regs = _dev->backup_regs;
>
> ret = pm_runtime_get_sync(i2c_dev->dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_noidle(i2c_dev->dev);
> return ret;
> + }
>
> backup_regs->cr1 = readl_relaxed(i2c_dev->base + STM32F7_I2C_CR1);
> backup_regs->cr2 = readl_relaxed(i2c_dev->base + STM32F7_I2C_CR2);
> @@ -2204,8 +2214,10 @@ static int stm32f7_i2c_regs_restore(struct
> stm32f7_i2c_dev *i2c_dev)
> struct stm32f7_i2c_regs *backup_regs = _dev->backup_regs;
>
> ret = pm_runtime_get_sync(i2c_dev->dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_noidle(i2c_dev->dev);
> return ret;
> + }
>
> cr1 = readl_relaxed(i2c_dev->base + STM32F7_I2C_CR1);
> if (cr1 & STM32F7_I2C_CR1_PE)
> --
> 2.17.1
>
Re: [PATCH v2] dt-bindings: media: venus: Add an optional power domain for perf voting
On 5/28/2020 1:06 AM, Rob Herring wrote: On Wed, May 13, 2020 at 11:33:27AM +0530, Rajendra Nayak wrote: Add an optional power domain which when specified can be used for setting the performance state of Venus. Signed-off-by: Rajendra Nayak --- Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml| 6 +- Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml | 6 +- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml index 764affa..ac1ed64 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml @@ -25,12 +25,16 @@ properties: maxItems: 1 power-domains: -maxItems: 2 +minItems: 2 +maxItems: 3 power-domain-names: +minItems: 2 +maxItems: 3 items: - const: venus - const: vcodec0 + - const: opp-pd Humm, looks suspicious. This is a phyical power island in this block? yes, this is used to represent the physical 'cx' power island in the SoC (Its a shared power island, not a power island specific to this block) that can be scaled to different 'performance levels' based on the frequency the codec is expected to run at. Because that's what 'power-domains' are supposed to represent. Not $os pm-domain construct. Rob -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
sh: 1: scripts/ld-version.sh: Permission denied
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 commit: 9553d16fa671b9621c5e2847d08bd90d3be3349c init/kconfig: Add LD_VERSION Kconfig date: 9 weeks ago config: x86_64-allyesconfig 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 git checkout 9553d16fa671b9621c5e2847d08bd90d3be3349c COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 allyesconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot All errors (new ones prefixed by >>, old ones prefixed by <<): sh: 1: scripts/gcc-version.sh: Permission denied sh: 1: scripts/gcc-version.sh: Permission denied init/Kconfig:18: syntax error init/Kconfig:17: invalid statement init/Kconfig:18: invalid statement >> sh: 1: scripts/ld-version.sh: Permission denied init/Kconfig:23: syntax error init/Kconfig:22: invalid statement sh: 1: scripts/clang-version.sh: Permission denied init/Kconfig:30: syntax error init/Kconfig:29: invalid statement sh: 1: scripts/gcc-plugin.sh: Permission denied make[2]: *** [scripts/kconfig/Makefile:75: allyesconfig] Error 1 make[1]: *** [Makefile:567: allyesconfig] Error 2 make: *** [Makefile:179: sub-make] Error 2 -- sh: 1: scripts/gcc-version.sh: Permission denied sh: 1: scripts/gcc-version.sh: Permission denied init/Kconfig:18: syntax error init/Kconfig:17: invalid statement init/Kconfig:18: invalid statement >> sh: 1: scripts/ld-version.sh: Permission denied init/Kconfig:23: syntax error init/Kconfig:22: invalid statement sh: 1: scripts/clang-version.sh: Permission denied init/Kconfig:30: syntax error init/Kconfig:29: invalid statement sh: 1: scripts/gcc-plugin.sh: Permission denied make[2]: *** [scripts/kconfig/Makefile:75: oldconfig] Error 1 make[1]: *** [Makefile:567: oldconfig] Error 2 make: *** [Makefile:179: sub-make] Error 2 -- sh: 1: scripts/gcc-version.sh: Permission denied sh: 1: scripts/gcc-version.sh: Permission denied init/Kconfig:18: syntax error init/Kconfig:17: invalid statement init/Kconfig:18: invalid statement >> sh: 1: scripts/ld-version.sh: Permission denied init/Kconfig:23: syntax error init/Kconfig:22: invalid statement sh: 1: scripts/clang-version.sh: Permission denied init/Kconfig:30: syntax error init/Kconfig:29: invalid statement sh: 1: scripts/gcc-plugin.sh: Permission denied make[2]: *** [scripts/kconfig/Makefile:75: olddefconfig] Error 1 make[1]: *** [Makefile:567: olddefconfig] Error 2 make: *** [Makefile:179: sub-make] Error 2 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:WIP.sched/core] BUILD REGRESSION 1f8db4150536431b031585ecc2a6793f69245de2
sh espt_defconfig arm omap1_defconfig arm spear13xx_defconfig sparc64 allyesconfig microblazenommu_defconfig arc axs101_defconfig powerpc maple_defconfig nds32 allnoconfig sh allmodconfig armmvebu_v5_defconfig arcnsim_700_defconfig armmvebu_v7_defconfig mips maltaaprp_defconfig s390 zfcpdump_defconfig s390 allyesconfig arm cns3420vb_defconfig armspear3xx_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig shallnoconfig microblazeallnoconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20200529 i386 randconfig-a001-20200529 i386 randconfig-a002-20200529 i386 randconfig-a006-20200529 i386 randconfig-a003-20200529 i386 randconfig-a005-20200529 i386 randconfig-a004-20200531 i386 randconfig-a003-20200531 i386 randconfig-a006-20200531 i386 randconfig-a002-20200531 i386 randconfig-a005-20200531 i386 randconfig-a001-20200531 x86_64 randconfig-a011-20200531 x86_64 randconfig-a016-20200531 x86_64 randconfig-a012-20200531 x86_64 randconfig-a014-20200531 x86_64 randconfig-a013-20200531 x86_64 randconfig-a015-20200531 x86_64 randconfig-a002-20200529 x86_64 randconfig-a006-20200529 x86_64 randconfig-a005-20200529 x86_64 randconfig-a001-20200529 x86_64 randconfig-a004-20200529 x86_64 randconfig-a003-20200529 i386 randconfig-a013-20200529 i386 randconfig-a011-20200529 i386 randconfig-a012-20200529 i386 randconfig-a015-20200529 i386 randconfig-a016-20200529 i386 randconfig-a014-20200529 i386 randconfig-a013-20200531 i386 randconfig-a012-20200531 i386 randconfig-a015-20200531 i386 randconfig-a011-20200531 i386 randconfig-a016-20200531 i386 randconfig-a014-20200531 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allnoconfig s390defconfig s390 allmodconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allmodconfig umallnoconfig um allyesconfig
[tip:sched/core] BUILD SUCCESS 58ef57b16d9e91cce1c640a6fe8a21d53a85181d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core branch HEAD: 58ef57b16d9e91cce1c640a6fe8a21d53a85181d Merge branch 'core/rcu' into sched/core, to pick up dependency i386-tinyconfig vmlinux size: == TOTAL TEXT try_invoke_on_locked_down_task() arch/x86/events/zhaoxin/built-in.* == -1 0 -136 c6e7bd7afaeb sched/core: Optimize ttwu() spinning on p->on_cpu 0 0 +136 2ebb17717550 sched/core: Offload wakee task activation if it the wakee is 0 0 -136 498bdcdb949e Merge branch 'sched/urgent' into sched/core, to pick up fix +172 +172 +76 58ef57b16d9e Merge branch 'core/rcu' into sched/core, to pick up dependen +171 +172 +76 -136 d505b8af5891..58ef57b16d9e (ALL COMMITS) == elapsed time: 5488m configs tested: 124 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig powerpc pasemi_defconfig sparc sparc64_defconfig mips decstation_64_defconfig mips ath79_defconfig armpleb_defconfig sh espt_defconfig arm omap1_defconfig arm spear13xx_defconfig sparc64 allyesconfig microblazenommu_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20200531 i386 randconfig-a003-20200531 i386 randconfig-a006-20200531 i386 randconfig-a002-20200531 i386 randcon
[tip:perf/core] BUILD SUCCESS 5cde265384cad739b162cf08afba6da8857778bd
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core branch HEAD: 5cde265384cad739b162cf08afba6da8857778bd perf/x86/rapl: Add AMD Fam17h RAPL support elapsed time: 5488m configs tested: 86 configs skipped: 4 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm mainstone_defconfig armhisi_defconfig powerpc mpc83xx_defconfig m68k multi_defconfig m68k allyesconfig powerpc pseries_defconfig armdove_defconfig h8300alldefconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig umallnoconfig um defconfig um allmodconfig um allyesconfig x86_64 rhel x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[rcu:dev.2020.05.25b] BUILD SUCCESS 39d28156618fd7787f3363cf66d77918c94abc54
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2020.05.25b
branch HEAD: 39d28156618fd7787f3363cf66d77918c94abc54 refperf: Output
per-experiment data points
i386-tinyconfig vmlinux size:
TOTAL TEXT built-in.* arch/x86/events/zhaoxin/built-in.*
-233 -233 8747b07d1944
Merge branch 'kcsan-dev.2020.04.13c' into HEAD
0 0 03e8e094dad9
Merge branch 'lkmm-dev.2020.05.16a' into HEAD
0 0 17e0ee2a3ec9
torture: Remove qemu dependency on EFI firmware
0 0 c58148777978
torture: Add script to smoke-test commits in a branch
+38 +38 396a79cc6818
fork: Annotate a data race in vm_area_dup()
0 0 8035e0fc710a
x86/mm/pat: Mark an intentional data race
0 0 d7a51c24ee4b
rculist: Add ASSERT_EXCLUSIVE_ACCESS() to __list_splice_init
0 0 e5efa2f1b7b6
locktorture: Use true and false to assign to bool variables
0 0 7514d7f181ab
srcu: Fix a typo in comment "amoritized"->"amortized"
0 0 9dbd776542e3 rcu:
Simplify the calculation of rcu_state.ncpus
0 0 df12d657bcc0
docs: RCU: Convert checklist.txt to ReST
0 0 fdfeb779e1bd
docs: RCU: Convert lockdep-splat.txt to ReST
0 0 68b5951f7eb2
docs: RCU: Convert lockdep.txt to ReST
0 0 ce9edc0c8a82
docs: RCU: Convert rculist_nulls.txt to ReST
0 0 1bee818b03c7
docs: RCU: Convert torture.txt to ReST
0 0 9100131711bc
docs: RCU: Convert rcuref.txt to ReST
0 0 080f194cfa87
docs: RCU: Convert stallwarn.txt to ReST
0 0 6999f47d8456
docs: RCU: Don't duplicate chapter names in rculist_nulls.rs
0 0 55ce2e8178f2
rcutorture: Add races with task-exit processing
0 0 1c60a5e52538
torture: Set configfile variable to current scenario
0 0 9969401f1706
rcutorture: Handle non-statistic bang-string error messages
0 0 6f099e1b362b
rcutorture: NULL rcu_torture_current earlier in cleanup code
0 0 6816417616c4
kcsan: Add test suite
0 0 848d16e04f52 doc:
Timer problems can cause RCU CPU stall warnings
0 0 2364a9f967ec rcu:
Add callbacks-invoked counters
0 0 2775724beeef rcu:
Add comment documenting rcu_callback_map's purpose
0 0 +138684 bfd78bca7bdf
Revert b8c17e6664c4 ("rcu: Maintain special bits at bottom o
+1 0 -138684 8903088434e7
rcu/tree: Add better tracing for dyntick-idle
-1 0 c0601bb42994
rcu/tree: Clean up dynticks counter usage
0 0 3f3baaf3ac07
rcu/tree: Remove dynticks_nmi_nesting counter
+1 0 725e4ad9e020
trace: events: rcu: Change description of rcu_dyntick trace
0 0 a9b73fda34ec
[rcu:dev.2020.05.26a] BUILD REGRESSION 63fdce1252f16032c9e1eb7244bb674ba4f84855
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2020.05.26a
branch HEAD: 63fdce1252f16032c9e1eb7244bb674ba4f84855 fixup! refperf: Provide
module parameter to specify number of experiments
Error/Warning in current branch:
m68k-linux-ld: refperf.c:(.text+0x8f2): undefined reference to `__udivdi3'
refperf.c:(.text+0x762): undefined reference to `__umoddi3'
Error/Warning ids grouped by kconfigs:
recent_errors
`-- m68k-allyesconfig
|-- m68k-linux-ld:refperf.c:(.text):undefined-reference-to-__udivdi3
`-- refperf.c:(.text):undefined-reference-to-__umoddi3
i386-tinyconfig vmlinux size:
TOTAL TEXT built-in.*
-233 -233 8747b07d1944 Merge branch 'kcsan-dev.2020.04.13c'
into HEAD
0 0 03e8e094dad9 Merge branch 'lkmm-dev.2020.05.16a' into
HEAD
0 0 17e0ee2a3ec9 torture: Remove qemu dependency on EFI
firmware
0 0 c58148777978 torture: Add script to smoke-test
commits in a branch
+38 +38 396a79cc6818 fork: Annotate a data race in
vm_area_dup()
0 0 8035e0fc710a x86/mm/pat: Mark an intentional data
race
0 0 d7a51c24ee4b rculist: Add ASSERT_EXCLUSIVE_ACCESS()
to __list_splice_init
0 0 e5efa2f1b7b6 locktorture: Use true and false to
assign to bool variables
0 0 7514d7f181ab srcu: Fix a typo in comment
"amoritized"->"amortized"
0 0 9dbd776542e3 rcu: Simplify the calculation of
rcu_state.ncpus
0 0 df12d657bcc0 docs: RCU: Convert checklist.txt to ReST
0 0 fdfeb779e1bd docs: RCU: Convert lockdep-splat.txt to
ReST
0 0 68b5951f7eb2 docs: RCU: Convert lockdep.txt to ReST
0 0 ce9edc0c8a82 docs: RCU: Convert rculist_nulls.txt to
ReST
0 0 1bee818b03c7 docs: RCU: Convert torture.txt to ReST
0 0 9100131711bc docs: RCU: Convert rcuref.txt to ReST
0 0 080f194cfa87 docs: RCU: Convert stallwarn.txt to ReST
0 0 6999f47d8456 docs: RCU: Don't duplicate chapter names
in rculist_nulls.rs
0 0 55ce2e8178f2 rcutorture: Add races with task-exit
processing
0 0 1c60a5e52538 torture: Set configfile variable to
current scenario
0 0 9969401f1706 rcutorture: Handle non-statistic
bang-string error messages
0 0 6f099e1b362b rcutorture: NULL rcu_torture_current
earlier in cleanup code
0 0 6816417616c4 kcsan: Add test suite
0 0 848d16e04f52 doc: Timer problems can cause RCU CPU
stall warnings
0 0 2364a9f967ec rcu: Add callbacks-invoked counters
0 0 2775724beeef rcu: Add comment documenting
rcu_callback_map's purpose
0 0 +138684 bfd78bca7bdf Revert b8c17e6664c4 ("rcu: Maintain
special bits at bottom o
+1 0 -138684 8903088434e7 rcu/tree: Add better tracing for
dyntick-idle
-1 0 c0601bb42994 rcu/tree: Clean up dynticks counter
usage
0 0 3f3baaf3ac07 rcu/tree: Remove dynticks_nmi_nesting
counter
+1 0 725e4ad9e020 trace: events: rcu: Change description
of rcu_dyntick trace
0 0 a9b73fda34ec torture: Remove whitespace from
identify_qemu_vcpus output
-1 0 +138684 6267bacdff81 torture: Add --allcpus argument to the
kvm.sh script
+1 0 -138684 5c6aa32472cb rcu: Grace-period-kthread related sleeps
to idle priority
-1 0 +138684 f334f4fee6e2 rcu: Priority-boost-related sleeps to
idle priority
0 0 0 d49cb59f19b6 rcu: No-CBs-related sleeps to idle
priority
+1 0 -138684 4cc4ce9b67ec rcu: Expedited grace-period sleeps to
idle priority
-1 0 +138684 cef0575caddb rcu-tasks: Convert sleeps to idle
priority
0 0 0 988aef3524e2 fs/btrfs: Add cond_resched() for
try_release_extent_mapping(
0 0 -138684 70ca490c7ab3 locking/osq_lock: Annotate a data
[PATCH v3 6/8] mtd: spi-nor: cadence-quadspi: Drop redundant WREN in erase path
Drop redundant WREN command in cqspi_erase() as SPI NOR core takes care of sending WREN command before sending erase command. Signed-off-by: Vignesh Raghavendra --- drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c index 0570ebca135a..6b1cbad25e3f 100644 --- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c @@ -1016,11 +1016,6 @@ static int cqspi_erase(struct spi_nor *nor, loff_t offs) if (ret) return ret; - /* Send write enable, then erase commands. */ - ret = nor->controller_ops->write_reg(nor, SPINOR_OP_WREN, NULL, 0); - if (ret) - return ret; - /* Set up command buffer. */ ret = cqspi_command_write_addr(nor, nor->erase_opcode, offs); if (ret) -- 2.26.2
[PATCH v3 7/8] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
From: Ramuthevar Vadivel Murugan
Move cadence-quadspi driver to use spi-mem framework. This is required
to make the driver support for SPI NAND flashes in future.
Driver is feature compliant with existing SPI NOR version.
Signed-off-by: Ramuthevar Vadivel Murugan
Signed-off-by: Vignesh Raghavendra
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 476 +++---
1 file changed, 191 insertions(+), 285 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 6b1cbad25e3f..c12a1c0191b9 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -3,6 +3,8 @@
* Driver for Cadence QSPI Controller
*
* Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+ * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
*/
#include
#include
@@ -17,9 +19,6 @@
#include
#include
#include
-#include
-#include
-#include
#include
#include
#include
@@ -27,6 +26,7 @@
#include
#include
#include
+#include
#include
#define CQSPI_NAME "cadence-qspi"
@@ -36,16 +36,12 @@
#define CQSPI_NEEDS_WR_DELAY BIT(0)
#define CQSPI_DISABLE_DAC_MODE BIT(1)
-/* Capabilities mask */
-#define CQSPI_BASE_HWCAPS_MASK \
- (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
- SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
- SNOR_HWCAPS_PP)
+/* Capabilities */
+#define CQSPI_SUPPORTS_OCTAL BIT(0)
struct cqspi_st;
struct cqspi_flash_pdata {
- struct spi_nor nor;
struct cqspi_st *cqspi;
u32 clk_rate;
u32 read_delay;
@@ -57,8 +53,6 @@ struct cqspi_flash_pdata {
u8 addr_width;
u8 data_width;
u8 cs;
- boolregistered;
- booluse_direct_mode;
};
struct cqspi_st {
@@ -71,7 +65,6 @@ struct cqspi_st {
void __iomem*ahb_base;
resource_size_t ahb_size;
struct completion transfer_complete;
- struct mutexbus_mutex;
struct dma_chan *rx_chan;
struct completion rx_dma_complete;
@@ -85,6 +78,7 @@ struct cqspi_st {
boolrclk_en;
u32 trigger_address;
u32 wr_delay;
+ booluse_direct_mode;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
};
@@ -283,9 +277,8 @@ static irqreturn_t cqspi_irq_handler(int this_irq, void
*dev)
return IRQ_HANDLED;
}
-static unsigned int cqspi_calc_rdreg(struct spi_nor *nor)
+static unsigned int cqspi_calc_rdreg(struct cqspi_flash_pdata *f_pdata)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
u32 rdreg = 0;
rdreg |= f_pdata->inst_width << CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB;
@@ -352,19 +345,21 @@ static int cqspi_exec_flash_cmd(struct cqspi_st *cqspi,
unsigned int reg)
return cqspi_wait_idle(cqspi);
}
-static int cqspi_command_read(struct spi_nor *nor, u8 opcode,
- u8 *rxbuf, size_t n_rx)
+static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
+ const struct spi_mem_op *op)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
void __iomem *reg_base = cqspi->iobase;
+ u8 *rxbuf = op->data.buf.in;
+ u8 opcode = op->cmd.opcode;
+ size_t n_rx = op->data.nbytes;
unsigned int rdreg;
unsigned int reg;
size_t read_len;
int status;
if (!n_rx || n_rx > CQSPI_STIG_DATA_LEN_MAX || !rxbuf) {
- dev_err(nor->dev,
+ dev_err(>pdev->dev,
"Invalid input argument, len %zu rxbuf 0x%p\n",
n_rx, rxbuf);
return -EINVAL;
@@ -372,7 +367,7 @@ static int cqspi_command_read(struct spi_nor *nor, u8
opcode,
reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
- rdreg = cqspi_calc_rdreg(nor);
+ rdreg = cqspi_calc_rdreg(f_pdata);
writel(rdreg, reg_base + CQSPI_REG_RD_INSTR);
reg |= (0x1 << CQSPI_REG_CMDCTRL_RD_EN_LSB);
@@ -401,25 +396,36 @@ static int cqspi_command_read(struct spi_nor *nor, u8
opcode,
return 0;
}
-static int cqspi_command_write(struct spi_nor *nor, const u8 opcode,
- const u8 *txbuf, size_t n_tx)
+static int cqspi_command_write(struct cqspi_flash_pdata *f_pdata,
+ const struct spi_mem_op *op)
{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
void __iomem *reg_base = cqspi->iobase;
+
[PATCH v3 2/8] mtd: spi-nor: cadence-quadspi: Provide a way to disable DAC mode
Currently direct access mode is used on platforms that have AHB window
(memory mapped window) larger than flash size. This feature is limited
to TI platforms as non TI platforms have < 1MB of AHB window.
Therefore introduce a driver quirk to disable DAC mode and set it for
non TI compatibles. This is in preparation to move to spi-mem framework
where flash geometry cannot be known.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 9b8554d44fac..8a9e17f79d8d 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -34,6 +34,7 @@
/* Quirks */
#define CQSPI_NEEDS_WR_DELAY BIT(0)
+#define CQSPI_DISABLE_DAC_MODE BIT(1)
/* Capabilities mask */
#define CQSPI_BASE_HWCAPS_MASK \
@@ -1261,7 +1262,8 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
struct device_node *np)
f_pdata->registered = true;
- if (mtd->size <= cqspi->ahb_size) {
+ if (mtd->size <= cqspi->ahb_size &&
+ !(ddata->quirks & CQSPI_DISABLE_DAC_MODE)) {
f_pdata->use_direct_mode = true;
dev_dbg(nor->dev, "using direct mode for %s\n",
mtd->name);
@@ -1457,6 +1459,7 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
static const struct cqspi_driver_platdata cdns_qspi = {
.hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
+ .quirks = CQSPI_DISABLE_DAC_MODE,
};
static const struct cqspi_driver_platdata k2g_qspi = {
--
2.26.2
Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface
On Mon, Jun 01, 2020 at 12:47:12PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2020-05-26 at 08:51 +0200, Greg KH wrote: > > > > And get them to sign off on it too, showing they agree with the design > > decisions here :) > > Isn't it generally frowned upon to publish a patch with internal sign- > off's on it already ? Not at all. > Or do you mean for us to publicly sign off once we have reviewed ? Either is fine, as long as you do the public one "quickly" and don't rely on others to do the review first :) thanks, greg k-h
Re: [2/2] Coccinelle: memdup_user: Extending data processing for special tokens
> Unfortunately, the Coccinelle software does not like the following > SmPL code variant so far. > > to = > ( > - \( kmalloc \| kzalloc \) > + memdup_user > | > - \( kvmalloc \| kvzalloc \) > + vmemdup_user > ) > ( > - size, \( GFP_KERNEL \| GFP_USER \) > + from, size > ); > > > Message: > 25: no available token to attach to I have adjusted a bit of OCaml source code. Thus I could see where such information was provided. https://github.com/coccinelle/coccinelle/blob/7cf2c23e64066d5249a64a316cc5347831f7a63f/parsing_cocci/insert_plus.ml#L1041 … | (((infop,count,pcode) as p) :: ps) as all -> (* … modifications. for the moment, we thus give an error, asking the user to rewrite the semantic patch. *) if greater_than_end infop infom1 || is_minus m1 || !empty_isos … Will the referenced comment get any more software development attention? Regards, Markus
[PATCH v3 1/8] mtd: spi-nor: cadence-quadspi: Make driver independent of flash geometry
Drop configuration of Flash size, erase size and page size
configuration. Flash size is needed only if using AHB decoder (BIT 23 of
CONFIG_REG) which is not used by the driver.
Erase size and page size are needed if IP is configured to send WREN
automatically. But since SPI NOR layer takes care of sending WREN, there
is no need to configure these fields either.
Therefore drop these in preparation to move the driver to spi-mem
framework where flash geometry is not visible to controller driver.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 36 +--
1 file changed, 1 insertion(+), 35 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 494dcab4..9b8554d44fac 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -77,9 +77,6 @@ struct cqspi_st {
dma_addr_t mmap_phys_base;
int current_cs;
- int current_page_size;
- int current_erase_size;
- int current_addr_width;
unsigned long master_ref_clk_hz;
boolis_decoded_cs;
u32 fifo_depth;
@@ -736,32 +733,6 @@ static void cqspi_chipselect(struct spi_nor *nor)
writel(reg, reg_base + CQSPI_REG_CONFIG);
}
-static void cqspi_configure_cs_and_sizes(struct spi_nor *nor)
-{
- struct cqspi_flash_pdata *f_pdata = nor->priv;
- struct cqspi_st *cqspi = f_pdata->cqspi;
- void __iomem *iobase = cqspi->iobase;
- unsigned int reg;
-
- /* configure page size and block size. */
- reg = readl(iobase + CQSPI_REG_SIZE);
- reg &= ~(CQSPI_REG_SIZE_PAGE_MASK << CQSPI_REG_SIZE_PAGE_LSB);
- reg &= ~(CQSPI_REG_SIZE_BLOCK_MASK << CQSPI_REG_SIZE_BLOCK_LSB);
- reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
- reg |= (nor->page_size << CQSPI_REG_SIZE_PAGE_LSB);
- reg |= (ilog2(nor->mtd.erasesize) << CQSPI_REG_SIZE_BLOCK_LSB);
- reg |= (nor->addr_width - 1);
- writel(reg, iobase + CQSPI_REG_SIZE);
-
- /* configure the chip select */
- cqspi_chipselect(nor);
-
- /* Store the new configuration of the controller */
- cqspi->current_page_size = nor->page_size;
- cqspi->current_erase_size = nor->mtd.erasesize;
- cqspi->current_addr_width = nor->addr_width;
-}
-
static unsigned int calculate_ticks_for_ns(const unsigned int ref_clk_hz,
const unsigned int ns_val)
{
@@ -867,18 +838,13 @@ static void cqspi_configure(struct spi_nor *nor)
int switch_cs = (cqspi->current_cs != f_pdata->cs);
int switch_ck = (cqspi->sclk != sclk);
- if ((cqspi->current_page_size != nor->page_size) ||
- (cqspi->current_erase_size != nor->mtd.erasesize) ||
- (cqspi->current_addr_width != nor->addr_width))
- switch_cs = 1;
-
if (switch_cs || switch_ck)
cqspi_controller_enable(cqspi, 0);
/* Switch chip select. */
if (switch_cs) {
cqspi->current_cs = f_pdata->cs;
- cqspi_configure_cs_and_sizes(nor);
+ cqspi_chipselect(nor);
}
/* Setup baudrate divisor and delays */
--
2.26.2
[PATCH v3 4/8] mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire reset lines
Make sure to undo the prior changes done by the driver when exiting due
to failure to acquire reset lines.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 379e22c11c87..608ca657ff7f 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1359,13 +1359,13 @@ static int cqspi_probe(struct platform_device *pdev)
rstc = devm_reset_control_get_optional_exclusive(dev, "qspi");
if (IS_ERR(rstc)) {
dev_err(dev, "Cannot get QSPI reset.\n");
- return PTR_ERR(rstc);
+ goto probe_reset_failed;
}
rstc_ocp = devm_reset_control_get_optional_exclusive(dev, "qspi-ocp");
if (IS_ERR(rstc_ocp)) {
dev_err(dev, "Cannot get QSPI OCP reset.\n");
- return PTR_ERR(rstc_ocp);
+ goto probe_reset_failed;
}
reset_control_assert(rstc);
@@ -1384,7 +1384,7 @@ static int cqspi_probe(struct platform_device *pdev)
pdev->name, cqspi);
if (ret) {
dev_err(dev, "Cannot request IRQ.\n");
- goto probe_irq_failed;
+ goto probe_reset_failed;
}
cqspi_wait_idle(cqspi);
@@ -1401,7 +1401,7 @@ static int cqspi_probe(struct platform_device *pdev)
return ret;
probe_setup_failed:
cqspi_controller_enable(cqspi, 0);
-probe_irq_failed:
+probe_reset_failed:
clk_disable_unprepare(cqspi->clk);
probe_clk_failed:
pm_runtime_put_sync(dev);
--
2.26.2
[PATCH v3 5/8] mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting DMA channel
dma_request_chan_by_mask() can throw EPROBE_DEFER if DMA provider
is not yet probed. Currently driver just falls back to using PIO mode
(which is less efficient) in this case. Instead return probe deferral
error as is so that driver will be re probed once DMA provider is
available.
Signed-off-by: Vignesh Raghavendra
---
.../mtd/spi-nor/controllers/cadence-quadspi.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 608ca657ff7f..0570ebca135a 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1169,7 +1169,7 @@ static void cqspi_controller_init(struct cqspi_st *cqspi)
cqspi_controller_enable(cqspi, 1);
}
-static void cqspi_request_mmap_dma(struct cqspi_st *cqspi)
+static int cqspi_request_mmap_dma(struct cqspi_st *cqspi)
{
dma_cap_mask_t mask;
@@ -1178,11 +1178,16 @@ static void cqspi_request_mmap_dma(struct cqspi_st
*cqspi)
cqspi->rx_chan = dma_request_chan_by_mask();
if (IS_ERR(cqspi->rx_chan)) {
- dev_err(>pdev->dev, "No Rx DMA available\n");
+ int ret = PTR_ERR(cqspi->rx_chan);
+
+ if (ret != -EPROBE_DEFER)
+ dev_err(>pdev->dev, "No Rx DMA available\n");
cqspi->rx_chan = NULL;
- return;
+ return ret;
}
init_completion(>rx_dma_complete);
+
+ return 0;
}
static const struct spi_nor_controller_ops cqspi_controller_ops = {
@@ -1269,8 +1274,11 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi,
struct device_node *np)
dev_dbg(nor->dev, "using direct mode for %s\n",
mtd->name);
- if (!cqspi->rx_chan)
- cqspi_request_mmap_dma(cqspi);
+ if (!cqspi->rx_chan) {
+ ret = cqspi_request_mmap_dma(cqspi);
+ if (ret == -EPROBE_DEFER)
+ goto err;
+ }
}
}
--
2.26.2
[PATCH v3 8/8] spi: Move cadence-quadspi driver to drivers/spi/
From: Ramuthevar Vadivel Murugan
Now that cadence-quadspi has been converted to use spi-mem framework,
move it under drivers/spi/
Update license header to match SPI subsystem style
Signed-off-by: Ramuthevar Vadivel Murugan
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/controllers/Kconfig| 11 ---
drivers/mtd/spi-nor/controllers/Makefile | 1 -
drivers/spi/Kconfig| 11 +++
drivers/spi/Makefile | 1 +
.../spi-cadence-quadspi.c} | 14 +++---
5 files changed, 19 insertions(+), 19 deletions(-)
rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
spi/spi-cadence-quadspi.c} (99%)
diff --git a/drivers/mtd/spi-nor/controllers/Kconfig
b/drivers/mtd/spi-nor/controllers/Kconfig
index d89a5ea9446a..5c0e0ec2e6d1 100644
--- a/drivers/mtd/spi-nor/controllers/Kconfig
+++ b/drivers/mtd/spi-nor/controllers/Kconfig
@@ -9,17 +9,6 @@ config SPI_ASPEED_SMC
and support for the SPI flash memory controller (SPI) for
the host firmware. The implementation only supports SPI NOR.
-config SPI_CADENCE_QUADSPI
- tristate "Cadence Quad SPI controller"
- depends on OF && (ARM || ARM64 || COMPILE_TEST)
- help
- Enable support for the Cadence Quad SPI Flash controller.
-
- Cadence QSPI is a specialized controller for connecting an SPI
- Flash over 1/2/4-bit wide bus. Enable this option if you have a
- device with a Cadence QSPI controller and want to access the
- Flash as an MTD device.
-
config SPI_HISI_SFC
tristate "Hisilicon FMC SPI NOR Flash Controller(SFC)"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/mtd/spi-nor/controllers/Makefile
b/drivers/mtd/spi-nor/controllers/Makefile
index 46e6fbe586e3..e7abba491d98 100644
--- a/drivers/mtd/spi-nor/controllers/Makefile
+++ b/drivers/mtd/spi-nor/controllers/Makefile
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
-obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o
obj-$(CONFIG_SPI_HISI_SFC) += hisi-sfc.o
obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o
obj-$(CONFIG_SPI_INTEL_SPI)+= intel-spi.o
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 099d6a75a371..2de8098b26c1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -200,6 +200,17 @@ config SPI_CADENCE
This selects the Cadence SPI controller master driver
used by Xilinx Zynq and ZynqMP.
+config SPI_CADENCE_QUADSPI
+ tristate "Cadence Quad SPI controller"
+ depends on OF && (ARM || ARM64 || COMPILE_TEST)
+ help
+ Enable support for the Cadence Quad SPI Flash controller.
+
+ Cadence QSPI is a specialized controller for connecting an SPI
+ Flash over 1/2/4-bit wide bus. Enable this option if you have a
+ device with a Cadence QSPI controller and want to access the
+ Flash as an MTD device.
+
config SPI_CLPS711X
tristate "CLPS711X host SPI controller"
depends on ARCH_CLPS711X || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 889368f4ad53..f03834d1d312 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_SPI_BCM_QSPI)+= spi-iproc-qspi.o
spi-brcmstb-qspi.o spi-bcm-qspi.
obj-$(CONFIG_SPI_BITBANG) += spi-bitbang.o
obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o
obj-$(CONFIG_SPI_CADENCE) += spi-cadence.o
+obj-$(CONFIG_SPI_CADENCE_QUADSPI) += spi-cadence-quadspi.o
obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o
obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o
obj-$(CONFIG_SPI_DAVINCI) += spi-davinci.o
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
similarity index 99%
rename from drivers/mtd/spi-nor/controllers/cadence-quadspi.c
rename to drivers/spi/spi-cadence-quadspi.c
index c12a1c0191b9..1c1a9d17eec0 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1,11 +1,11 @@
// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Driver for Cadence QSPI Controller
- *
- * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
- * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
- * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
- */
+//
+// Driver for Cadence QSPI Controller
+//
+// Copyright Altera Corporation (C) 2012-2014. All rights reserved.
+// Copyright Intel Corporation (C) 2019-2020. All rights reserved.
+// Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+
#include
#include
#include
--
2.26.2
[PATCH v3 3/8] mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on failure
If driver fails to acquire DMA channel then don't initialize
rx_dma_complete struct as it won't be used.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Tudor Ambarus
---
drivers/mtd/spi-nor/controllers/cadence-quadspi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
index 8a9e17f79d8d..379e22c11c87 100644
--- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
@@ -1180,6 +1180,7 @@ static void cqspi_request_mmap_dma(struct cqspi_st *cqspi)
if (IS_ERR(cqspi->rx_chan)) {
dev_err(>pdev->dev, "No Rx DMA available\n");
cqspi->rx_chan = NULL;
+ return;
}
init_completion(>rx_dma_complete);
}
--
2.26.2
[PATCH v3 0/8] mtd: spi-nor: Move cadence-qaudspi to spi-mem framework
This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add
support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX
that intended to move
cadence-quadspi driver to spi-mem framework
Those patches were trying to accomplish too many things in a single set
of patches and need to split into smaller patches. This is reduced
version of above series.
Changes that are intended to make migration easy are split into separate
patches. Patches 1 to 3 drop features that cannot be supported under
spi-mem at the moment (backward compatibility is maintained).
Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to
spi-mem and patch 7 moves the driver to drivers/spi folder.
I have tested both INDAC mode (used by non TI platforms like Altera
SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs.
Patches to move move bindings over to
"Documentation/devicetree/bindings/spi/" directory and also conversion
of bindig doc to YAML will be posted separately. Support for Intel
platform would follow that.
v3:
Split handling of probe deferral into separate patch (out of 5/6)
Split dropping of redundant WREN to separate patch (out of 5/6)
Fix a possible memleak due to lack of spi_master_put()
Parse all SPI slave nodes in cqspi_setup_flash()
Address misc comments from Tudor on v2
Rebase onto latest spi-nor/next
v2:
Rework patch 1/6 to keep "cdns,is-decoded-cs" property supported.
Ramuthevar Vadivel Murugan (2):
mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
spi: Move cadence-quadspi driver to drivers/spi/
Vignesh Raghavendra (6):
mtd: spi-nor: cadence-quadspi: Make driver independent of flash
geometry
mtd: spi-nor: cadence-quadspi: Provide a way to disable DAC mode
mtd: spi-nor: cadence-quadspi: Don't initialize rx_dma_complete on
failure
mtd: spi-nor: cadence-quadspi: Fix error path on failure to acquire
reset lines
mtd: spi-nor: cadence-quadspi: Handle probe deferral while requesting
DMA channel
mtd: spi-nor: cadence-quadspi: Drop redundant WREN in erase path
drivers/mtd/spi-nor/controllers/Kconfig | 11 -
drivers/mtd/spi-nor/controllers/Makefile | 1 -
drivers/spi/Kconfig | 11 +
drivers/spi/Makefile | 1 +
.../spi-cadence-quadspi.c}| 541 +++---
5 files changed, 222 insertions(+), 343 deletions(-)
rename drivers/{mtd/spi-nor/controllers/cadence-quadspi.c =>
spi/spi-cadence-quadspi.c} (74%)
--
2.26.2
Re: [PATCH] drivers/dax/bus: Use kobj_to_dev() API
On Fri, May 29, 2020 at 11:42:57AM +0800, Shuai He wrote:
> Use kobj_to_dev() API instead of container_of().
>
> Signed-off-by: Shuai He
Seems reasonable:
Reviewed-by: Ira Weiny
> ---
> drivers/dax/bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index df238c8..24625d2 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -331,7 +331,7 @@ static DEVICE_ATTR_RO(numa_node);
>
> static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a,
> int n)
> {
> - struct device *dev = container_of(kobj, struct device, kobj);
> + struct device *dev = kobj_to_dev(kobj);
> struct dev_dax *dev_dax = to_dev_dax(dev);
>
> if (a == _attr_target_node.attr && dev_dax_target_node(dev_dax) < 0)
> --
> 2.7.4
> ___
> Linux-nvdimm mailing list -- linux-nvd...@lists.01.org
> To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
[PATCH] iommu: amd: Fix IO_PAGE_FAULT due to __unmap_single() size overflow
Currently, an integer is used to specify the size in unmap_sg().
With 2GB worth of pages (512k 4k pages), it requires 31 bits
(i.e. (1 << 19) << 12), which overflows the integer, and ends up
unmapping more pages than intended. Subsequently, this results in
IO_PAGE_FAULT.
Uses size_t instead of int to pass parameter to __unmap_single().
Reported-by: Robert Lippert
Signed-off-by: Suravee Suthikulpanit
---
Note: This patch is intended for stable tree prior 5.5 due to commit
be62dbf554c5 ("iommu/amd: Convert AMD iommu driver to the dma-iommu api"),
where the function unmap_sg() was removed.
drivers/iommu/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 32de8e7bb8b4..7adc021932b8 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2670,7 +2670,7 @@ static void unmap_sg(struct device *dev, struct
scatterlist *sglist,
struct protection_domain *domain;
struct dma_ops_domain *dma_dom;
unsigned long startaddr;
- int npages;
+ size_t npages;
domain = get_domain(dev);
if (IS_ERR(domain))
--
2.17.1
Re: [PATCH] soundwire: clarify SPDX use of GPL-2.0
On Mon, Jun 01, 2020 at 01:28:07AM +0800, Bard Liao wrote: > From: Pierre-Louis Bossart > > Change SPDX from GPL-2.0 to GPL-2.0-only for Intel-contributed > code. This was explicit before the transition to SPDX and lost in > translation. It is also explicit in the "GPL-2.0" lines as well, did you read the LICENSES/preferred/GPL-2.0 file for the allowed tags to be used for this license? So this doesn't change anything, and we are trying to cut down on this type of churn until, maybe, after the whole kernel has proper SPDX lines. thanks, greg k-h
[tip:x86/build] BUILD SUCCESS 38f3e775e9c242f5430a9c08c11be7577f63a41c
randconfig-a004-20200529 x86_64 randconfig-a003-20200529 i386 randconfig-a004-20200529 i386 randconfig-a001-20200529 i386 randconfig-a002-20200529 i386 randconfig-a006-20200529 i386 randconfig-a003-20200529 i386 randconfig-a005-20200529 i386 randconfig-a004-20200531 i386 randconfig-a003-20200531 i386 randconfig-a006-20200531 i386 randconfig-a002-20200531 i386 randconfig-a005-20200531 i386 randconfig-a001-20200531 x86_64 randconfig-a011-20200531 x86_64 randconfig-a016-20200531 x86_64 randconfig-a012-20200531 x86_64 randconfig-a014-20200531 x86_64 randconfig-a013-20200531 x86_64 randconfig-a015-20200531 i386 randconfig-a013-20200529 i386 randconfig-a011-20200529 i386 randconfig-a012-20200529 i386 randconfig-a015-20200529 i386 randconfig-a016-20200529 i386 randconfig-a014-20200529 i386 randconfig-a013-20200531 i386 randconfig-a012-20200531 i386 randconfig-a015-20200531 i386 randconfig-a011-20200531 i386 randconfig-a016-20200531 i386 randconfig-a014-20200531 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allmodconfig um allmodconfig umallnoconfig um defconfig um allyesconfig x86_64 rhel x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH v2 2/2] vhost: convert get_user_pages() --> pin_user_pages()
This code was using get_user_pages*(), in approximately a "Case 5" scenario (accessing the data within a page), using the categorization from [1]. That means that it's time to convert the get_user_pages*() + put_page() calls to pin_user_pages*() + unpin_user_pages() calls. There is some helpful background in [2]: basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Cc: Michael S. Tsirkin Cc: Jason Wang Cc: k...@vger.kernel.org Cc: virtualizat...@lists.linux-foundation.org Cc: net...@vger.kernel.org Signed-off-by: John Hubbard --- drivers/vhost/vhost.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 21a59b598ed8..596132a96cd5 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -1762,15 +1762,14 @@ static int set_bit_to_user(int nr, void __user *addr) int bit = nr + (log % PAGE_SIZE) * 8; int r; - r = get_user_pages_fast(log, 1, FOLL_WRITE, ); + r = pin_user_pages_fast(log, 1, FOLL_WRITE, ); if (r < 0) return r; BUG_ON(r != 1); base = kmap_atomic(page); set_bit(bit, base); kunmap_atomic(base); - set_page_dirty_lock(page); - put_page(page); + unpin_user_pages_dirty_lock(, 1, true); return 0; } -- 2.26.2
[PATCH v2 0/2] vhost, docs: convert to pin_user_pages(), new "case 5"
This is based on Linux 5.7, plus one prerequisite patch: "mm/gup: update pin_user_pages.rst for "case 3" (mmu notifiers)" [1] Changes since v1: removed references to set_page_dirty*(), in response to Souptick Joarder's review (thanks!). Cover letter for v1, edited/updated slightly: It recently became clear to me that there are some get_user_pages*() callers that don't fit neatly into any of the four cases that are so far listed in pin_user_pages.rst. vhost.c is one of those. Add a Case 5 to the documentation, and refer to that when converting vhost.c. Thanks to Jan Kara for helping me (again) in understanding the interaction between get_user_pages() and page writeback [2]. Note that I have only compile-tested the vhost.c patch, although that does also include cross-compiling for a few other arches. Any run-time testing would be greatly appreciated. [1] https://lore.kernel.org/r/20200527194953.11130-1-jhubb...@nvidia.com [2] https://lore.kernel.org/r/20200529070343.gl14...@quack2.suse.cz John Hubbard (2): docs: mm/gup: pin_user_pages.rst: add a "case 5" vhost: convert get_user_pages() --> pin_user_pages() Documentation/core-api/pin_user_pages.rst | 18 ++ drivers/vhost/vhost.c | 5 ++--- 2 files changed, 20 insertions(+), 3 deletions(-) base-commit: 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 -- 2.26.2
[PATCH v2 1/2] docs: mm/gup: pin_user_pages.rst: add a "case 5"
There are four cases listed in pin_user_pages.rst. These are intended to help developers figure out whether to use get_user_pages*(), or pin_user_pages*(). However, the four cases do not cover all the situations. For example, drivers/vhost/vhost.c has a "pin, write to page, set page dirty, unpin" case. Add a fifth case, to help explain that there is a general pattern that requires pin_user_pages*() API calls. Cc: Vlastimil Babka Cc: Jan Kara Cc: Jérôme Glisse Cc: Dave Chinner Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: linux-fsde...@vger.kernel.org Signed-off-by: John Hubbard --- Documentation/core-api/pin_user_pages.rst | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst index 4675b04e8829..6068266dd303 100644 --- a/Documentation/core-api/pin_user_pages.rst +++ b/Documentation/core-api/pin_user_pages.rst @@ -171,6 +171,24 @@ If only struct page data (as opposed to the actual memory contents that a page is tracking) is affected, then normal GUP calls are sufficient, and neither flag needs to be set. +CASE 5: Pinning in order to write to the data within the page +- +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, +write to a page's data, unpin" can cause a problem. Case 5 may be considered a +superset of Case 1, plus Case 2, plus anything that invokes that pattern. In +other words, if the code is neither Case 1 nor Case 2, it may still require +FOLL_PIN, for patterns like this: + +Correct (uses FOLL_PIN calls): +pin_user_pages() +write to the data within the pages +unpin_user_pages() + +INCORRECT (uses FOLL_GET calls): +get_user_pages() +write to the data within the pages +put_page() + page_maybe_dma_pinned(): the whole point of pinning === -- 2.26.2
Re: [PATCH 2/3] mfd: madera: Fix minor formatting issues
On Fri, 29 May 2020, Charles Keepax wrote:
Still needs a commit log.
> Signed-off-by: Charles Keepax
> ---
> drivers/mfd/madera-core.c| 12 ++--
> drivers/mfd/madera-i2c.c | 1 -
> include/linux/mfd/madera/pdata.h | 1 -
> 3 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
> index 7e0835cb062b1..4724c1a01a39f 100644
> --- a/drivers/mfd/madera-core.c
> +++ b/drivers/mfd/madera-core.c
> @@ -44,7 +44,7 @@ static const char * const madera_core_supplies[] = {
> };
>
> static const struct mfd_cell madera_ldo1_devs[] = {
> - { .name = "madera-ldo1" },
> + { .name = "madera-ldo1", },
What issue does this solve?
Why are ','s a requirement, even for single entries?
> };
>
> static const char * const cs47l15_supplies[] = {
> @@ -55,8 +55,8 @@ static const char * const cs47l15_supplies[] = {
>
> static const struct mfd_cell cs47l15_devs[] = {
> { .name = "madera-pinctrl", },
> - { .name = "madera-irq" },
> - { .name = "madera-gpio" },
> + { .name = "madera-irq", },
> + { .name = "madera-gpio", },
> {
> .name = "madera-extcon",
> .parent_supplies = cs47l15_supplies,
> @@ -108,7 +108,7 @@ static const char * const cs47l85_supplies[] = {
> static const struct mfd_cell cs47l85_devs[] = {
> { .name = "madera-pinctrl", },
> { .name = "madera-irq", },
> - { .name = "madera-micsupp" },
> + { .name = "madera-micsupp", },
> { .name = "madera-gpio", },
> {
> .name = "madera-extcon",
> @@ -155,10 +155,10 @@ static const char * const cs47l92_supplies[] = {
> };
>
> static const struct mfd_cell cs47l92_devs[] = {
> - { .name = "madera-pinctrl" },
> + { .name = "madera-pinctrl", },
> { .name = "madera-irq", },
> { .name = "madera-micsupp", },
> - { .name = "madera-gpio" },
> + { .name = "madera-gpio", },
> {
> .name = "madera-extcon",
> .parent_supplies = cs47l92_supplies,
> diff --git a/drivers/mfd/madera-i2c.c b/drivers/mfd/madera-i2c.c
> index 6b965eb034b6c..7df5b9ba58554 100644
> --- a/drivers/mfd/madera-i2c.c
> +++ b/drivers/mfd/madera-i2c.c
> @@ -88,7 +88,6 @@ static int madera_i2c_probe(struct i2c_client *i2c,
> if (!madera)
> return -ENOMEM;
>
> -
> madera->regmap = devm_regmap_init_i2c(i2c, regmap_16bit_config);
> if (IS_ERR(madera->regmap)) {
> ret = PTR_ERR(madera->regmap);
> diff --git a/include/linux/mfd/madera/pdata.h
> b/include/linux/mfd/madera/pdata.h
> index fa9595dd42ba5..601cbbc10370c 100644
> --- a/include/linux/mfd/madera/pdata.h
> +++ b/include/linux/mfd/madera/pdata.h
> @@ -21,7 +21,6 @@
>
> struct gpio_desc;
> struct pinctrl_map;
> -struct madera_codec_pdata;
This is not a formatting issue.
> /**
> * struct madera_pdata - Configuration data for Madera devices
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH] soundwire: clarify SPDX use of GPL-2.0
From: Pierre-Louis Bossart Change SPDX from GPL-2.0 to GPL-2.0-only for Intel-contributed code. This was explicit before the transition to SPDX and lost in translation. No change to the dual-license parts, the only clarification is to the GPL-2.0 term. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Signed-off-by: Bard Liao --- drivers/soundwire/bus.c | 2 +- drivers/soundwire/bus.h | 2 +- drivers/soundwire/bus_type.c| 2 +- drivers/soundwire/cadence_master.c | 2 +- drivers/soundwire/cadence_master.h | 2 +- drivers/soundwire/intel.c | 2 +- drivers/soundwire/intel.h | 2 +- drivers/soundwire/intel_init.c | 2 +- drivers/soundwire/mipi_disco.c | 2 +- drivers/soundwire/slave.c | 2 +- drivers/soundwire/stream.c | 2 +- include/linux/soundwire/sdw.h | 2 +- include/linux/soundwire/sdw_intel.h | 2 +- include/linux/soundwire/sdw_registers.h | 2 +- include/linux/soundwire/sdw_type.h | 2 +- 15 files changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index 24ba77226376..2289c2ac8c5a 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) // Copyright(c) 2015-17 Intel Corporation. #include diff --git a/drivers/soundwire/bus.h b/drivers/soundwire/bus.h index 82484f741168..697a5b371568 100644 --- a/drivers/soundwire/bus.h +++ b/drivers/soundwire/bus.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) */ /* Copyright(c) 2015-17 Intel Corporation. */ #ifndef __SDW_BUS_H diff --git a/drivers/soundwire/bus_type.c b/drivers/soundwire/bus_type.c index de9a671802b8..95a87d4e26c2 100644 --- a/drivers/soundwire/bus_type.c +++ b/drivers/soundwire/bus_type.c @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 +// SPDX-License-Identifier: GPL-2.0-only // Copyright(c) 2015-17 Intel Corporation. #include diff --git a/drivers/soundwire/cadence_master.c b/drivers/soundwire/cadence_master.c index 9ea87538b9ef..fe238645ed2c 100644 --- a/drivers/soundwire/cadence_master.c +++ b/drivers/soundwire/cadence_master.c @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) // Copyright(c) 2015-17 Intel Corporation. /* diff --git a/drivers/soundwire/cadence_master.h b/drivers/soundwire/cadence_master.h index b410656f8194..ea606b4fba76 100644 --- a/drivers/soundwire/cadence_master.h +++ b/drivers/soundwire/cadence_master.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) */ /* Copyright(c) 2015-17 Intel Corporation. */ #include diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index 4cfdd074e310..1eda63f488f5 100644 --- a/drivers/soundwire/intel.c +++ b/drivers/soundwire/intel.c @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) // Copyright(c) 2015-17 Intel Corporation. /* diff --git a/drivers/soundwire/intel.h b/drivers/soundwire/intel.h index 38b7c125fb10..7b4af8018e1a 100644 --- a/drivers/soundwire/intel.h +++ b/drivers/soundwire/intel.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) */ /* Copyright(c) 2015-17 Intel Corporation. */ #ifndef __SDW_INTEL_LOCAL_H diff --git a/drivers/soundwire/intel_init.c b/drivers/soundwire/intel_init.c index d5d42795a48f..947345d5c960 100644 --- a/drivers/soundwire/intel_init.c +++ b/drivers/soundwire/intel_init.c @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) // Copyright(c) 2015-17 Intel Corporation. /* diff --git a/drivers/soundwire/mipi_disco.c b/drivers/soundwire/mipi_disco.c index 4ae62b452b8c..dbd8fc6f4dad 100644 --- a/drivers/soundwire/mipi_disco.c +++ b/drivers/soundwire/mipi_disco.c @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) // Copyright(c) 2015-17 Intel Corporation. /* diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c index 0839445ee07b..8e8b62dff51c 100644 --- a/drivers/soundwire/slave.c +++ b/drivers/soundwire/slave.c @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) // Copyright(c) 2015-17 Intel Corporation. #include diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index a9a72574b34a..296cea48bdcc 100644 --- a/drivers/soundwire/stream.c +++
Re: Re: Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new
> > If there's *any* error, it'll check the pointer, if it's non-NULL, > > it'll call the destructor. If kzalloc() fails, the pointer will be > > NULL, there's no double-free bug. *every* subdev is written this way > > to avoid duplicating cleanup logic. > Actually, gm20b_clk_new_speedo0() may have a bug here if kzalloc() > fails as it doesn't overwrite the previous pointer from > gm20b_clk_new(). That whole ctor() sequence is written a little > strangely. > It's clear to me, thank your for your explanation! As for gm20b_clk_new_speedo0(), I think its bug pattern is not very clear. Maybe we should keep it until we find an use chain that could lead to a bug. Regards, Dinghao
[tip:auto-latest] BUILD SUCCESS 4e052965f46b6fd9641d79bf10208eac2631475f
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git auto-latest branch HEAD: 4e052965f46b6fd9641d79bf10208eac2631475f Merge branch 'efi/core' elapsed time: 5276m configs tested: 114 configs skipped: 8 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig powerpc tqm8xx_defconfig i386 allyesconfig sh polaris_defconfig mips mtx1_defconfig arm spear13xx_defconfig powerpc pasemi_defconfig sparc sparc64_defconfig mips decstation_64_defconfig mips ath79_defconfig powerpc mgcoge_defconfig nds32 allnoconfig s390 allnoconfig arm vf610m4_defconfig arm pxa168_defconfig mips ip27_defconfig arc nsimosci_hs_smp_defconfig shshmin_defconfig microblaze defconfig arm pxa_defconfig c6xevmc6678_defconfig m68km5407c3_defconfig sh j2_defconfig armmulti_v7_defconfig arm mainstone_defconfig armhisi_defconfig powerpc mpc83xx_defconfig m68k multi_defconfig m68k allyesconfig xtensa allyesconfig sh sdk7780_defconfig mipsjmr3927_defconfig sh cayman_defconfig powerpcadder875_defconfig mipsar7_defconfig armkeystone_defconfig arm viper_defconfig mips rm200_defconfig armmvebu_v5_defconfig arm assabet_defconfig xtensa alldefconfig i386 allnoconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64
[PATCH V4] pwm: tegra: dynamic clk freq configuration by PWM driver
Added support for dynamic clock freq configuration in pwm kernel driver.
Earlier the pwm driver used to cache boot time clock rate by pwm clock
parent during probe. Hence dynamically changing pwm frequency was not
possible for all the possible ranges. With this change, dynamic calculation
is enabled and it is able to set the requested period from sysfs knob
provided the value is supported by clock source.
Changes mainly have 2 parts:
- T186 and later chips [1]
- T210 and prior chips [2]
For [1] - Changes implemented to set pwm period dynamically and
also checks added to allow only if requested period(ns) is
below or equals to higher range.
For [2] - Only checks if the requested period(ns) is below or equals
to higher range defined by max clock limit. The limitation
in T210 or prior chips are due to the reason of having only
one pwm-controller supporting multiple channels. But later
chips have multiple pwm controller instances each having
single channel support.
Signed-off-by: Sandipan Patra
---
PATCH V4:
1. Code comments fixes
PATCH V3:
1. Return -EINVAL if requested period does not fall inside limit.
2. Store the new clock rate for further references.
3. Variable name change reverted.
4. Comments corrected and new comments are added.
PATCH V2:
1. Maximum frequency calculation is moved to probe.
2. Added descriptions for PWM register bits and functional behavior
of the controller when new configuration is applied.
3. Setting period with possible value when supplied period is below limit.
4. Corrected the earlier code comment:
plus 1 instead of minus 1 during pwm calculation
drivers/pwm/pwm-tegra.c | 80 ++---
1 file changed, 76 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
index d26ed8f..1daf591 100644
--- a/drivers/pwm/pwm-tegra.c
+++ b/drivers/pwm/pwm-tegra.c
@@ -4,8 +4,36 @@
*
* Tegra pulse-width-modulation controller driver
*
- * Copyright (c) 2010, NVIDIA Corporation.
+ * Copyright (c) 2010-2020, NVIDIA Corporation.
* Based on arch/arm/plat-mxc/pwm.c by Sascha Hauer
+ *
+ * Overview of Tegra Pulse Width Modulator Register:
+ * 1. 13-bit: Frequency division (SCALE)
+ * 2. 8-bit : Pulse division (DUTY)
+ * 3. 1-bit : Enable bit
+ *
+ * The PWM clock frequency is divided by 256 before subdividing it based
+ * on the programmable frequency division value to generate the required
+ * frequency for PWM output. The maximum output frequency that can be
+ * achieved is (max rate of source clock) / 256.
+ * e.g. if source clock rate is 408 MHz, maximum output frequency can be:
+ * 408 MHz/256 = 1.6 MHz.
+ * This 1.6 MHz frequency can further be divided using SCALE value in PWM.
+ *
+ * PWM pulse width: 8 bits are usable [23:16] for varying pulse width.
+ * To achieve 100% duty cycle, program Bit [24] of this register to
+ * 1’b1. In which case the other bits [23:16] are set to don't care.
+ *
+ * Limitations:
+ * - When PWM is disabled, the output is driven to inactive.
+ * - It does not allow the current PWM period to complete and
+ * stops abruptly.
+ *
+ * - If the register is reconfigured while PWM is running,
+ * it does not complete the currently running period.
+ *
+ * - If the user input duty is beyond acceptible limits,
+ * -EINVAL is returned.
*/
#include
@@ -41,6 +69,7 @@ struct tegra_pwm_chip {
struct reset_control*rst;
unsigned long clk_rate;
+ unsigned long min_period_ns;
void __iomem *regs;
@@ -68,7 +97,7 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
{
struct tegra_pwm_chip *pc = to_tegra_pwm_chip(chip);
unsigned long long c = duty_ns, hz;
- unsigned long rate;
+ unsigned long rate, required_clk_rate;
u32 val = 0;
int err;
@@ -83,9 +112,47 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
val = (u32)c << PWM_DUTY_SHIFT;
/*
+* min period = max clock limit >> PWM_DUTY_WIDTH
+*/
+ if (period_ns < pc->min_period_ns)
+ return -EINVAL;
+
+ /*
* Compute the prescaler value for which (1 << PWM_DUTY_WIDTH)
* cycles at the PWM clock rate will take period_ns nanoseconds.
+*
+* num_channels: If single instance of PWM controller has multiple
+* channels (e.g. Tegra210 or older) then it is not possible to
+* configure separate clock rates to each of the channels, in such
+* case the value stored during probe will be referred.
+*
+* If every PWM controller instance has one channel respectively, i.e.
+* nums_channels == 1 then only the clock rate can be modified
+* dynamically (e.g. Tegra186 or Tegra194).
*/
+ if (pc->soc->num_channels == 1) {
+ /*
+* Rate is
Re: [PATCH] staging: qlge: qlge_main.c: fixed spaces coding style issues
On 2020-05-29 17:17 +0200, Jil Rouceau wrote:
> Fixed the missing spaces before and after binary operators.
>
> Signed-off-by: Jil Rouceau
This patch does not apply cleanly. I think your base tree is missing
commit ec269f1250c6 ("staging: qlge: Remove unnecessary spaces in
qlge_main.c").
[tip:master] BUILD SUCCESS 14bf8733b3c1887abab08371c47e68f2afbc0b93
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: 14bf8733b3c1887abab08371c47e68f2afbc0b93 Merge branch 'x86/urgent' elapsed time: 3625m configs tested: 118 configs skipped: 6 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm pxa3xx_defconfig arm palmz72_defconfig shshmin_defconfig ia64zx1_defconfig riscv rv32_defconfig um x86_64_defconfig m68k m5249evb_defconfig sh sh7770_generic_defconfig arm vf610m4_defconfig armtrizeps4_defconfig powerpc pasemi_defconfig sparc sparc64_defconfig mips decstation_64_defconfig mips ath79_defconfig shsh7763rdp_defconfig s390 allnoconfig mips tb0226_defconfig m68k multi_defconfig sh rsk7269_defconfig ia64generic_defconfig arm pxa_defconfig c6xevmc6678_defconfig m68km5407c3_defconfig sh j2_defconfig armmulti_v7_defconfig xtensa allyesconfig sh sdk7780_defconfig mipsjmr3927_defconfig riscv defconfig sh cayman_defconfig powerpcadder875_defconfig mipsar7_defconfig armkeystone_defconfig arm viper_defconfig ia64 allnoconfig armpleb_defconfig sh espt_defconfig arm omap1_defconfig arm spear13xx_defconfig sparc64 allyesconfig microblazenommu_defconfig s390 zfcpdump_defconfig s390 allyesconfig arm cns3420vb_defconfig armspear3xx_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig riscvallyesconfig riscv allnoconfig riscvallmodconfig s390 allmodconfig s390
[tip:efi/urgent] BUILD SUCCESS 9bb4cbf4862dfa139f73e12912129e5b76baea1a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git efi/urgent branch HEAD: 9bb4cbf4862dfa139f73e12912129e5b76baea1a Merge tag 'efi-fixes-for-v5.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/urgent elapsed time: 13521m configs tested: 103 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig m68k allyesconfig arm pxa_defconfig c6xevmc6678_defconfig m68km5407c3_defconfig sh j2_defconfig armmulti_v7_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20200524 i386 randconfig-a004-20200524 i386 randconfig-a006-20200524 i386 randconfig-a003-20200524 i386 randconfig-a002-20200524 i386 randconfig-a005-20200524 x86_64 randconfig-a013-20200524 x86_64 randconfig-a015-20200524 x86_64 randconfig-a016-20200524 x86_64 randconfig-a012-20200524 x86_64 randconfig-a014-20200524 x86_64 randconfig-a011-20200524 i386 randconfig-a013-20200524 i386 randconfig-a015-20200524 i386 randconfig-a012-20200524 i386 randconfig-a011-20200524 i386 randconfig-a016-20200524 i386 randconfig-a014-20200524 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig x86_64 defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig umallnoconfig um defconfig um allmodconfig um allyesconfig x86_64 rhel x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64
[tip:irq/core] BUILD SUCCESS 76fe06c1e68b8f8dfb63d5b268623830dcb16ed0
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core branch HEAD: 76fe06c1e68b8f8dfb63d5b268623830dcb16ed0 Merge tag 'irqchip-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core elapsed time: 2567m configs tested: 146 configs skipped: 20 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig mips mpc30x_defconfig mips rbtx49xx_defconfig m68kstmark2_defconfig um x86_64_defconfig m68k m5249evb_defconfig sh sh7770_generic_defconfig arm vf610m4_defconfig armtrizeps4_defconfig powerpc ppc44x_defconfig powerpc pasemi_defconfig sparc sparc64_defconfig mips decstation_64_defconfig mips ath79_defconfig powerpc mgcoge_defconfig arm pxa168_defconfig nds32 allnoconfig s390 allnoconfig mips ip27_defconfig arc nsimosci_hs_smp_defconfig mips mtx1_defconfig shshmin_defconfig microblaze defconfig arm shannon_defconfig powerpc ppc6xx_defconfig powerpc64alldefconfig microblazenommu_defconfig arm pxa_defconfig c6xevmc6678_defconfig m68km5407c3_defconfig sh j2_defconfig armmulti_v7_defconfig arm mainstone_defconfig armhisi_defconfig powerpc mpc83xx_defconfig m68k multi_defconfig m68k allyesconfig sh sdk7780_defconfig mipsjmr3927_defconfig riscv defconfig sh cayman_defconfig shtitan_defconfig arm netwinder_defconfig pariscgeneric-32bit_defconfig sh rsk7264_defconfig armspear6xx_defconfig m68k sun3_defconfig sh se7619_defconfig arc haps_hs_smp_defconfig arm at91_dt_defconfig sh espt_defconfig armrealview_defconfig arm footbridge_defconfig arm davinci_all_defconfig c6x defconfig x86_64 defconfig i386 allnoconfig riscv rv32_defconfig um alldefconfig arc tb10x_defconfig armmvebu_v7_defconfig powerpcmpc7448_hpc2_defconfig c6x dsk6455_defconfig riscvnommu_virt_defconfig shapsh4ad0a_defconfig sh se7343_defconfig mips rm200_defconfig armmvebu_v5_defconfig arm assabet_defconfig xtensa alldefconfig powerpc tqm8xx_defconfig sh se7750_defconfig xtensa virt_defconfig armmulti_v5_defconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68kdefconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig csky allyesconfig csky
[tip:WIP.locking/core] BUILD SUCCESS 19f545b6e07f753c4dc639c2f0ab52345733b6a8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git WIP.locking/core branch HEAD: 19f545b6e07f753c4dc639c2f0ab52345733b6a8 zram: Use local lock to protect per-CPU data elapsed time: 5454m configs tested: 126 configs skipped: 7 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm allyesconfig arm allmodconfig sparc sparc64_defconfig mips decstation_64_defconfig mips ath79_defconfig powerpc pasemi_defconfig h8300allyesconfig sh sh03_defconfig sh se7343_defconfig arm badge4_defconfig sh se7780_defconfig xtensa virt_defconfig arm milbeaut_m10v_defconfig arm lpd270_defconfig sh rsk7269_defconfig mips allyesconfig ia64generic_defconfig m68kq40_defconfig sh se7724_defconfig mipsmalta_qemu_32r6_defconfig mipse55_defconfig mips lemote2f_defconfig armpleb_defconfig sh espt_defconfig arm omap1_defconfig arm spear13xx_defconfig sparc64 allyesconfig microblazenommu_defconfig arc axs101_defconfig powerpc maple_defconfig nds32 allnoconfig sh allmodconfig armmvebu_v5_defconfig arcnsim_700_defconfig armmvebu_v7_defconfig mips maltaaprp_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allmodconfig xtensa defconfig arc allyesconfig shallnoconfig arc defconfig microblazeallnoconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20200529 i386 randconfig-a001-20200529 i386 randconfig-a002-20200529 i386 randconfig-a006-20200529 i386 randconfig-a003-20200529 i386 randconfig-a005-20200529 x86_64 randconfig-a002-20200529 x86_64 randconfig-a006-20200529 x86_64 randconfig-a005-20200529 x86_64 randconfig-a001-20200529 x86_64 randconfig-a004-20200529 x86_64 randconfig-a003-20200529 i386 randconfig-a013-20200529 i386 randconfig-a011-20200529 i386 randconfig-a012-20200529 i386 randconfig-a015-20200529 i386
[tip:x86/cleanups] BUILD SUCCESS 2ca41f555e857ec5beef6063bfa43a17ee76d7ec
randconfig-a004-20200531 i386 randconfig-a003-20200531 i386 randconfig-a006-20200531 i386 randconfig-a002-20200531 i386 randconfig-a005-20200531 i386 randconfig-a001-20200531 x86_64 randconfig-a002-20200529 x86_64 randconfig-a006-20200529 x86_64 randconfig-a005-20200529 x86_64 randconfig-a001-20200529 x86_64 randconfig-a004-20200529 x86_64 randconfig-a003-20200529 x86_64 randconfig-a011-20200531 x86_64 randconfig-a016-20200531 x86_64 randconfig-a012-20200531 x86_64 randconfig-a014-20200531 x86_64 randconfig-a013-20200531 x86_64 randconfig-a015-20200531 i386 randconfig-a013-20200529 i386 randconfig-a011-20200529 i386 randconfig-a012-20200529 i386 randconfig-a015-20200529 i386 randconfig-a016-20200529 i386 randconfig-a014-20200529 i386 randconfig-a013-20200531 i386 randconfig-a012-20200531 i386 randconfig-a015-20200531 i386 randconfig-a011-20200531 i386 randconfig-a016-20200531 i386 randconfig-a014-20200531 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig umallnoconfig um allyesconfig um defconfig um allmodconfig x86_64 rhel x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:locking/kcsan] BUILD SUCCESS f05e1242fbb2d149ceaa87310cf67d03fe007a25
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking/kcsan
branch HEAD: f05e1242fbb2d149ceaa87310cf67d03fe007a25 compiler_types.h: Use
unoptimized __unqual_scalar_typeof for sparse
i386-tinyconfig vmlinux size:
+---++---+
| DELTA | SYMBOL |
COMMIT |
+---++---+
| -5517 | TOTAL | ffed638b6a21..f05e1242fbb2 (ALL
COMMITS) |
| -5517 | TOTAL | 777f73c4e791 compiler.h: Remove
data_race() and unnecessary checks from { |
| -5517 | TEXT | 777f73c4e791 compiler.h: Remove
data_race() and unnecessary checks from { |
| +136 | arch/x86/events/zhaoxin/built-in.* | a5dead405f6b compiler_types.h:
Optimize __unqual_scalar_typeof compilatio |
| -136 | arch/x86/events/zhaoxin/built-in.* | e87c5783e9e4 ubsan, kcsan: Don't
combine sanitizer with kcov on clang |
| +65 | get_page_from_freelist() | 777f73c4e791 compiler.h: Remove
data_race() and unnecessary checks from { |
| -98 | __wakeup_flusher_threads_bdi() | 777f73c4e791 compiler.h: Remove
data_race() and unnecessary checks from { |
+---++---+
elapsed time: 5453m
configs tested: 153
configs skipped: 17
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64allyesconfig
arm64 defconfig
arm64allmodconfig
arm64 allnoconfig
powerpc ppc44x_defconfig
powerpc pasemi_defconfig
sparc sparc64_defconfig
mips decstation_64_defconfig
mips ath79_defconfig
powerpc mgcoge_defconfig
nds32 allnoconfig
s390 allnoconfig
arm vf610m4_defconfig
arm pxa168_defconfig
mips ip27_defconfig
arc nsimosci_hs_smp_defconfig
mips mtx1_defconfig
shshmin_defconfig
microblaze defconfig
arm shannon_defconfig
powerpc ppc6xx_defconfig
powerpc64alldefconfig
microblazenommu_defconfig
powerpc mpc885_ads_defconfig
arm aspeed_g5_defconfig
mipsmaltaup_defconfig
arc nps_defconfig
arm pxa_defconfig
c6xevmc6678_defconfig
m68km5407c3_defconfig
sh j2_defconfig
armmulti_v7_defconfig
arm mainstone_defconfig
armhisi_defconfig
powerpc mpc83xx_defconfig
m68k multi_defconfig
m68k allyesconfig
um x86_64_defconfig
shtitan_defconfig
arm netwinder_defconfig
pariscgeneric-32bit_defconfig
sh rsk7264_defconfig
armspear6xx_defconfig
sh sh7770_generic_defconfig
m68k sun3_defconfig
sh se7619_defconfig
arm ebsa110_defconfig
armlart_defconfig
sh microdev_defconfig
x86_64 defconfig
arm badge4_defconfig
armoxnas_v6_defconfig
arc haps_hs_smp_defconfig
arm at91_dt_defconfig
sh espt_defconfig
armrealview_defconfig
arm footbridge_defconfig
armdove_defconfig
h8300alldefconfig
um alldefconfig
nds32alldefconfig
arm s3c6400_defconfig
m68kmvme16x_defconfig
mips pistachio_defconfig
arc tb10x_defconfig
armmvebu_v7_defconfig
powerpc
[rcu:dev.2020.05.29a] BUILD SUCCESS f088eeb5bd99e97a2e8cea15279bbab273f2d7c8
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2020.05.29a
branch HEAD: f088eeb5bd99e97a2e8cea15279bbab273f2d7c8 refperf: Work around
64-bit division
i386-tinyconfig vmlinux size:
TOTAL TEXT arch/x86/events/zhaoxin/built-in.* built-in.*
-233 -233 8747b07d1944
Merge branch 'kcsan-dev.2020.04.13c' into HEAD
0 0 03e8e094dad9
Merge branch 'lkmm-dev.2020.05.16a' into HEAD
0 0 17e0ee2a3ec9
torture: Remove qemu dependency on EFI firmware
0 0 c58148777978
torture: Add script to smoke-test commits in a branch
+38 +38 396a79cc6818
fork: Annotate a data race in vm_area_dup()
0 0 8035e0fc710a
x86/mm/pat: Mark an intentional data race
0 0 d7a51c24ee4b
rculist: Add ASSERT_EXCLUSIVE_ACCESS() to __list_splice_init
0 0 e5efa2f1b7b6
locktorture: Use true and false to assign to bool variables
0 0 7514d7f181ab
srcu: Fix a typo in comment "amoritized"->"amortized"
0 0 9dbd776542e3 rcu:
Simplify the calculation of rcu_state.ncpus
0 0 df12d657bcc0
docs: RCU: Convert checklist.txt to ReST
0 0 fdfeb779e1bd
docs: RCU: Convert lockdep-splat.txt to ReST
0 0 68b5951f7eb2
docs: RCU: Convert lockdep.txt to ReST
0 0 ce9edc0c8a82
docs: RCU: Convert rculist_nulls.txt to ReST
0 0 1bee818b03c7
docs: RCU: Convert torture.txt to ReST
0 0 9100131711bc
docs: RCU: Convert rcuref.txt to ReST
0 0 080f194cfa87
docs: RCU: Convert stallwarn.txt to ReST
0 0 6999f47d8456
docs: RCU: Don't duplicate chapter names in rculist_nulls.rs
0 0 55ce2e8178f2
rcutorture: Add races with task-exit processing
0 0 1c60a5e52538
torture: Set configfile variable to current scenario
0 0 9969401f1706
rcutorture: Handle non-statistic bang-string error messages
0 0 6f099e1b362b
rcutorture: NULL rcu_torture_current earlier in cleanup code
0 0 6816417616c4
kcsan: Add test suite
0 0 848d16e04f52 doc:
Timer problems can cause RCU CPU stall warnings
0 0 2364a9f967ec rcu:
Add callbacks-invoked counters
0 0 2775724beeef rcu:
Add comment documenting rcu_callback_map's purpose
0 0 +138684 bfd78bca7bdf
Revert b8c17e6664c4 ("rcu: Maintain special bits at bottom o
+1 0 -138684 8903088434e7
rcu/tree: Add better tracing for dyntick-idle
-1 0 c0601bb42994
rcu/tree: Clean up dynticks counter usage
0 0 3f3baaf3ac07
rcu/tree: Remove dynticks_nmi_nesting counter
+1 0 725e4ad9e020
trace: events: rcu: Change description of rcu_dyntick trace
0 0 a9b73fda34ec
[tip:efi/core] BUILD SUCCESS e9524fb97ab5b41b85e1d3408f8e513433798f3c
powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig x86_64 randconfig-a002-20200529 x86_64 randconfig-a006-20200529 x86_64 randconfig-a005-20200529 x86_64 randconfig-a001-20200529 x86_64 randconfig-a004-20200529 x86_64 randconfig-a003-20200529 i386 randconfig-a004-20200529 i386 randconfig-a001-20200529 i386 randconfig-a002-20200529 i386 randconfig-a006-20200529 i386 randconfig-a003-20200529 i386 randconfig-a005-20200529 i386 randconfig-a004-20200531 i386 randconfig-a003-20200531 i386 randconfig-a006-20200531 i386 randconfig-a002-20200531 i386 randconfig-a005-20200531 i386 randconfig-a001-20200531 x86_64 randconfig-a011-20200531 x86_64 randconfig-a016-20200531 x86_64 randconfig-a012-20200531 x86_64 randconfig-a014-20200531 x86_64 randconfig-a013-20200531 x86_64 randconfig-a015-20200531 i386 randconfig-a013-20200529 i386 randconfig-a011-20200529 i386 randconfig-a012-20200529 i386 randconfig-a015-20200529 i386 randconfig-a016-20200529 i386 randconfig-a014-20200529 i386 randconfig-a013-20200531 i386 randconfig-a012-20200531 i386 randconfig-a015-20200531 i386 randconfig-a011-20200531 i386 randconfig-a016-20200531 i386 randconfig-a014-20200531 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allmodconfig umallnoconfig um defconfig um allmodconfig um allyesconfig x86_64 rhel x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:x86/urgent] BUILD SUCCESS aa61b7bb00f7c0738823237a06161d568442b93c
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent branch HEAD: aa61b7bb00f7c0738823237a06161d568442b93c Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs into x86/urgent i386-tinyconfig vmlinux size: == TOTAL TEXT copy_xstate_to_kernel() copy_part() == +204 +205 +109 +96 aa61b7bb00f7 Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/k +204 +205 +109 +96 4bfe6cce133c..aa61b7bb00f7 (ALL COMMITS) == elapsed time: 3621m configs tested: 131 configs skipped: 114 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm pxa3xx_defconfig arm palmz72_defconfig shshmin_defconfig ia64zx1_defconfig riscv rv32_defconfig powerpc pasemi_defconfig sparc sparc64_defconfig mips decstation_64_defconfig mips ath79_defconfig shsh7763rdp_defconfig s390 allnoconfig mips tb0226_defconfig m68k multi_defconfig h8300allyesconfig sh sh03_defconfig sh se7343_defconfig arm badge4_defconfig sh se7780_defconfig sh rsk7269_defconfig ia64generic_defconfig mips allyesconfig xtensa allyesconfig sh sdk7780_defconfig mipsjmr3927_defconfig riscv defconfig sh cayman_defconfig arm ebsa110_defconfig armlart_defconfig sh microdev_defconfig x86_64 defconfig armoxnas_v6_defconfig arc axs101_defconfig powerpc maple_defconfig nds32 allnoconfig sh allmodconfig armqcom_defconfig powerpcamigaone_defconfig nios2 10m50_defconfig arm s3c6400_defconfig openriscdefconfig s390 zfcpdump_defconfig s390 allyesconfig arm cns3420vb_defconfig armspear3xx_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nds32 defconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig h8300allmodconfig xtensa defconfig nios2 defconfig nios2allyesconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig arc defconfig arc allyesconfig shallnoconfig microblazeallnoconfig mips allnoconfig mips
[rcu:master] BUILD SUCCESS 8747b07d19443724745de86964e8818404112220
allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig nios2 defconfig nios2allyesconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig parisc defconfig pariscallnoconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig x86_64 randconfig-a002-20200529 x86_64 randconfig-a006-20200529 x86_64 randconfig-a005-20200529 x86_64 randconfig-a001-20200529 x86_64 randconfig-a004-20200529 x86_64 randconfig-a003-20200529 i386 randconfig-a004-20200531 i386 randconfig-a003-20200531 i386 randconfig-a006-20200531 i386 randconfig-a002-20200531 i386 randconfig-a005-20200531 i386 randconfig-a001-20200531 i386 randconfig-a004-20200529 i386 randconfig-a001-20200529 i386 randconfig-a002-20200529 i386 randconfig-a006-20200529 i386 randconfig-a003-20200529 i386 randconfig-a005-20200529 x86_64 randconfig-a011-20200531 x86_64 randconfig-a016-20200531 x86_64 randconfig-a012-20200531 x86_64 randconfig-a014-20200531 x86_64 randconfig-a013-20200531 x86_64 randconfig-a015-20200531 i386 randconfig-a013-20200529 i386 randconfig-a011-20200529 i386 randconfig-a012-20200529 i386 randconfig-a015-20200529 i386 randconfig-a016-20200529 i386 randconfig-a014-20200529 i386 randconfig-a013-20200531 i386 randconfig-a012-20200531 i386 randconfig-a015-20200531 i386 randconfig-a011-20200531 i386 randconfig-a016-20200531 i386 randconfig-a014-20200531 riscvallyesconfig riscv allnoconfig riscvallmodconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allmodconfig um allmodconfig umallnoconfig um defconfig um allyesconfig x86_64 rhel x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:x86/entry] BUILD REGRESSION 5980d208e5ef28455e9e8b08f6250b443a2f0893
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry branch HEAD: 5980d208e5ef28455e9e8b08f6250b443a2f0893 x86/idt: Consolidate idt functionality Error/Warning in current branch: arch/x86/kernel/idt.c:177:43: error: expected ';' before ')' token arch/x86/kernel/idt.c:177:43: error: expected statement before ')' token arch/x86/kernel/idt.c:177:45: error: expected expression before '==' token Error/Warning ids grouped by kconfigs: recent_errors `-- i386-randconfig-c001-20200529 |-- arch-x86-kernel-idt.c:error:expected-before-)-token |-- arch-x86-kernel-idt.c:error:expected-expression-before-token `-- arch-x86-kernel-idt.c:error:expected-statement-before-)-token i386-tinyconfig vmlinux size: +---++--+ | DELTA | SYMBOL | COMMIT | +---++--+ | +171 | TOTAL | 5a7462b1f9c1..5980d208e5ef (ALL COMMITS) | | +167 | TEXT | 5a7462b1f9c1..5980d208e5ef (ALL COMMITS) | | +2048 | idt_table | 5a7462b1f9c1..5980d208e5ef (ALL COMMITS) | | +154 | init.text | 5a7462b1f9c1..5980d208e5ef (ALL COMMITS) | | +85 | idt_setup_apic_and_irq_gates() | 5a7462b1f9c1..5980d208e5ef (ALL COMMITS) | | -2048 | idt_table | 5a7462b1f9c1..5980d208e5ef (ALL COMMITS) | +---++--+ elapsed time: 2564m configs tested: 112 configs skipped: 8 arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig mips mpc30x_defconfig mips rbtx49xx_defconfig m68kstmark2_defconfig um x86_64_defconfig m68k m5249evb_defconfig sh sh7770_generic_defconfig arm vf610m4_defconfig armtrizeps4_defconfig powerpc pasemi_defconfig sparc sparc64_defconfig mips decstation_64_defconfig mips ath79_defconfig arm pxa_defconfig c6xevmc6678_defconfig m68km5407c3_defconfig sh j2_defconfig armmulti_v7_defconfig sh sdk7780_defconfig mipsjmr3927_defconfig riscv defconfig sh cayman_defconfig arm davinci_all_defconfig c6x defconfig x86_64 defconfig i386 allnoconfig riscv rv32_defconfig arc tb10x_defconfig armmvebu_v7_defconfig powerpcmpc7448_hpc2_defconfig xtensa defconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips
[tip:x86/splitlock] BUILD SUCCESS 429ac8b75a0b1c3478ffd584de8a63075cbe25e7
allnoconfig powerpc defconfig x86_64 randconfig-a002-20200529 x86_64 randconfig-a006-20200529 x86_64 randconfig-a005-20200529 x86_64 randconfig-a001-20200529 x86_64 randconfig-a004-20200529 x86_64 randconfig-a003-20200529 i386 randconfig-a004-20200529 i386 randconfig-a001-20200529 i386 randconfig-a002-20200529 i386 randconfig-a006-20200529 i386 randconfig-a003-20200529 i386 randconfig-a005-20200529 i386 randconfig-a004-20200531 i386 randconfig-a003-20200531 i386 randconfig-a006-20200531 i386 randconfig-a002-20200531 i386 randconfig-a005-20200531 i386 randconfig-a001-20200531 x86_64 randconfig-a011-20200531 x86_64 randconfig-a016-20200531 x86_64 randconfig-a012-20200531 x86_64 randconfig-a014-20200531 x86_64 randconfig-a013-20200531 x86_64 randconfig-a015-20200531 i386 randconfig-a013-20200529 i386 randconfig-a011-20200529 i386 randconfig-a012-20200529 i386 randconfig-a015-20200529 i386 randconfig-a016-20200529 i386 randconfig-a014-20200529 i386 randconfig-a013-20200531 i386 randconfig-a012-20200531 i386 randconfig-a015-20200531 i386 randconfig-a011-20200531 i386 randconfig-a016-20200531 i386 randconfig-a014-20200531 riscv allnoconfig riscv defconfig riscvallmodconfig riscvallyesconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allmodconfig umallnoconfig um allyesconfig um defconfig x86_64 rhel x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:core/rcu] BUILD SUCCESS 806f04e9fd2c6ad1e39bc2dba77155be0e4becde
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/rcu branch HEAD: 806f04e9fd2c6ad1e39bc2dba77155be0e4becde rcu: Allow for smp_call_function() running callbacks from idle elapsed time: 5451m configs tested: 124 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm allyesconfig arm allmodconfig arm allnoconfig powerpc pasemi_defconfig sparc sparc64_defconfig mips decstation_64_defconfig mips ath79_defconfig armpleb_defconfig sh espt_defconfig arm omap1_defconfig arm spear13xx_defconfig sparc64 allyesconfig microblazenommu_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc allyesconfig sh allmodconfig shallnoconfig arc defconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a004-20200531 i386 randconfig-a003-20200531 i386 randconfig-a006-20200531 i386 randconfig-a002-20200531 i386 randconfig-a005-20200531 i386 randconfig-a001-20200531 i386 randconfig-a004-20200529 i386 randconfig-a001-20200529 i386 randconfig-a002-20200529 i386 randconfig-a006-20200529 i386 randconfig-a003-20200529 i386 randconfig-a005-20200529 x86_64 randconfig-a011-20200531 x86_64 randconfig-a016-20200531 x86_64 randconfig-a012-20200531 x86_64 randconfig-a014-20200531 x86_64 randconfig-a013-20200531 x86_64 randconfig-a015-20200531 i386 randconfig-a013-20200529 i386 randconfig-a011-20200529 i386 randconfig-a012-20200529 i386 randconfig-a015-20200529 i386 randconfig-a016-20200529 i386 randconfig-a014-20200529 i386 randconfig-a013-20200531 i386 randconfig-a012-20200531 i386 randconfig-a015-20200531 i386 randconfig-a011-20200531 i386 randconfig-a016-20200531 i386 randconfig-a014-20200531 x86_64 randconfig-a002-20200529 x86_64 randconfig-a006-20200529 x86_64 randconfig-a005-20200529 x86_64 randconfig-a001-20200529 x86_64 randconfig-a004-20200529 x86_64 randconfig-a003-20200529 riscv
[PATCH v7 4/4] kasan: update documentation for generic kasan
Generic KASAN will support to record the last two call_rcu() call stacks and print them in KASAN report. So that need to update documentation. Signed-off-by: Walter Wu Reviewed-and-tested-by: Dmitry Vyukov Reviewed-by: Andrey Konovalov Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Jonathan Corbet --- Documentation/dev-tools/kasan.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index c652d740735d..fede42e6536b 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -193,6 +193,9 @@ function calls GCC directly inserts the code to check the shadow memory. This option significantly enlarges kernel but it gives x1.1-x2 performance boost over outline instrumented kernel. +Generic KASAN prints up to 2 call_rcu() call stacks in reports, the last one +and the second to last. + Software tag-based KASAN -- 2.18.0
Re: [PATCH 1/2] docs: mm/gup: pin_user_pages.rst: add a "case 5"
On 2020-05-31 00:11, Souptick Joarder wrote: ... diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst index 4675b04e8829..b9f2688a2c67 100644 --- a/Documentation/core-api/pin_user_pages.rst +++ b/Documentation/core-api/pin_user_pages.rst @@ -171,6 +171,26 @@ If only struct page data (as opposed to the actual memory contents that a page is tracking) is affected, then normal GUP calls are sufficient, and neither flag needs to be set. +CASE 5: Pinning in order to write to the data within the page +- +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, +access page's data, unpin" can cause a problem. Will it be, *"pin, access page's data, set page dirty, unpin" * ? Well...the problem can show up with just accessing (writing) the data. But it is true that this statement is a little different from the patterns below, which is confusing. I'll delete set_page_dirty() from each of them, in order to avoid confusing things. (Although each is correct.) And I'll also change the above to "pin, write to a page's data, upin". set_page_dirty() interactions are really just extra credit here. :) And fully read-only situations won't cause a problem. Case 5 may be considered a +superset of Case 1, plus Case 2, plus anything that invokes that pattern. In +other words, if the code is neither Case 1 nor Case 2, it may still require +FOLL_PIN, for patterns like this: + +Correct (uses FOLL_PIN calls): +pin_user_pages() +access the data within the pages +set_page_dirty_lock() +unpin_user_pages() + +INCORRECT (uses FOLL_GET calls): +get_user_pages() +access the data within the pages +set_page_dirty_lock() +put_page() + I'll send a v2 shortly. thanks, -- John Hubbard NVIDIA
[PATCH v7 3/4] kasan: add tests for call_rcu stack recording
Test call_rcu() call stack recording and verify whether it correctly
is printed in KASAN report.
Signed-off-by: Walter Wu
Reviewed-and-tested-by: Dmitry Vyukov
Reviewed-by: Andrey Konovalov
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Matthias Brugger
---
Changes since v6:
- renamed the variable name in testcase
---
lib/test_kasan.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index e3087d90e00d..19c72c1501ef 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -792,6 +792,35 @@ static noinline void __init vmalloc_oob(void)
static void __init vmalloc_oob(void) {}
#endif
+static struct kasan_rcu_info {
+ int i;
+ struct rcu_head rcu;
+} *global_rcu_ptr;
+
+static noinline void __init kasan_rcu_reclaim(struct rcu_head *rp)
+{
+ struct kasan_rcu_info *fp = container_of(rp,
+ struct kasan_rcu_info, rcu);
+
+ kfree(fp);
+ fp->i = 1;
+}
+
+static noinline void __init kasan_rcu_uaf(void)
+{
+ struct kasan_rcu_info *ptr;
+
+ pr_info("use-after-free in kasan_rcu_reclaim\n");
+ ptr = kmalloc(sizeof(struct kasan_rcu_info), GFP_KERNEL);
+ if (!ptr) {
+ pr_err("Allocation failed\n");
+ return;
+ }
+
+ global_rcu_ptr = rcu_dereference_protected(ptr, NULL);
+ call_rcu(_rcu_ptr->rcu, kasan_rcu_reclaim);
+}
+
static int __init kmalloc_tests_init(void)
{
/*
@@ -839,6 +868,7 @@ static int __init kmalloc_tests_init(void)
kasan_bitops();
kmalloc_double_kzfree();
vmalloc_oob();
+ kasan_rcu_uaf();
kasan_restore_multi_shot(multishot);
--
2.18.0
[PATCH v7 2/4] kasan: record and print the free track
Move free track from kasan_alloc_meta to kasan_free_meta in order
to make struct kasan_alloc_meta and kasan_free_meta size are both
16 bytes. It is a good size because it is the minimal redzone size
and a good number of alignment.
For free track, we make some modifications as shown below:
1) Remove the free_track from struct kasan_alloc_meta.
2) Add the free_track into struct kasan_free_meta.
3) Add a macro KASAN_KMALLOC_FREETRACK in order to check whether
it can print free stack in KASAN report.
[1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
Signed-off-by: Walter Wu
Suggested-by: Dmitry Vyukov
Co-developed-by: Dmitry Vyukov
Reviewed-and-tested-by: Dmitry Vyukov
Reviewed-by: Andrey Konovalov
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
---
mm/kasan/common.c | 22 ++
mm/kasan/generic.c| 22 ++
mm/kasan/generic_report.c | 1 +
mm/kasan/kasan.h | 13 +++--
mm/kasan/quarantine.c | 1 +
mm/kasan/report.c | 26 --
mm/kasan/tags.c | 37 +
7 files changed, 78 insertions(+), 44 deletions(-)
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 8bc618289bb1..47b53912f322 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -51,7 +51,7 @@ depot_stack_handle_t kasan_save_stack(gfp_t flags)
return stack_depot_save(entries, nr_entries, flags);
}
-static inline void set_track(struct kasan_track *track, gfp_t flags)
+void kasan_set_track(struct kasan_track *track, gfp_t flags)
{
track->pid = current->pid;
track->stack = kasan_save_stack(flags);
@@ -299,24 +299,6 @@ struct kasan_free_meta *get_free_info(struct kmem_cache
*cache,
return (void *)object + cache->kasan_info.free_meta_offset;
}
-
-static void kasan_set_free_info(struct kmem_cache *cache,
- void *object, u8 tag)
-{
- struct kasan_alloc_meta *alloc_meta;
- u8 idx = 0;
-
- alloc_meta = get_alloc_info(cache, object);
-
-#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
- idx = alloc_meta->free_track_idx;
- alloc_meta->free_pointer_tag[idx] = tag;
- alloc_meta->free_track_idx = (idx + 1) % KASAN_NR_FREE_STACKS;
-#endif
-
- set_track(_meta->free_track[idx], GFP_NOWAIT);
-}
-
void kasan_poison_slab(struct page *page)
{
unsigned long i;
@@ -492,7 +474,7 @@ static void *__kasan_kmalloc(struct kmem_cache *cache,
const void *object,
KASAN_KMALLOC_REDZONE);
if (cache->flags & SLAB_KASAN)
- set_track(_alloc_info(cache, object)->alloc_track, flags);
+ kasan_set_track(_alloc_info(cache, object)->alloc_track,
flags);
return set_tag(object, tag);
}
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 8acf48882ba2..4b3cbad7431b 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -346,3 +346,25 @@ void kasan_record_aux_stack(void *addr)
alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
alloc_info->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
}
+
+void kasan_set_free_info(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_free_meta *free_meta;
+
+ free_meta = get_free_info(cache, object);
+ kasan_set_track(_meta->free_track, GFP_NOWAIT);
+
+ /*
+* the object was freed and has free track set
+*/
+ *(u8 *)kasan_mem_to_shadow(object) = KASAN_KMALLOC_FREETRACK;
+}
+
+struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ if (*(u8 *)kasan_mem_to_shadow(object) != KASAN_KMALLOC_FREETRACK)
+ return NULL;
+ return _free_info(cache, object)->free_track;
+}
diff --git a/mm/kasan/generic_report.c b/mm/kasan/generic_report.c
index e200acb2d292..a38c7a9e192a 100644
--- a/mm/kasan/generic_report.c
+++ b/mm/kasan/generic_report.c
@@ -80,6 +80,7 @@ static const char *get_shadow_bug_type(struct
kasan_access_info *info)
break;
case KASAN_FREE_PAGE:
case KASAN_KMALLOC_FREE:
+ case KASAN_KMALLOC_FREETRACK:
bug_type = "use-after-free";
break;
case KASAN_ALLOCA_LEFT:
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index a7391bc83070..ef655a1c6e15 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -17,15 +17,17 @@
#define KASAN_PAGE_REDZONE 0xFE /* redzone for kmalloc_large allocations
*/
#define KASAN_KMALLOC_REDZONE 0xFC /* redzone inside slub object */
#define KASAN_KMALLOC_FREE 0xFB /* object was freed
(kmem_cache_free/kfree) */
+#define KASAN_KMALLOC_FREETRACK 0xFA /* object was freed and has free track
set */
#else
#define KASAN_FREE_PAGE KASAN_TAG_INVALID
#define KASAN_PAGE_REDZONE KASAN_TAG_INVALID
#define KASAN_KMALLOC_REDZONE KASAN_TAG_INVALID
#define KASAN_KMALLOC_FREE KASAN_TAG_INVALID
+#define
[PATCH v7 1/4] rcu: kasan: record and print call_rcu() call stack
This feature will record the last two call_rcu() call stacks and
prints up to 2 call_rcu() call stacks in KASAN report.
When call_rcu() is called, we store the call_rcu() call stack into
slub alloc meta-data, so that the KASAN report can print rcu stack.
[1]https://bugzilla.kernel.org/show_bug.cgi?id=198437
[2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ
Signed-off-by: Walter Wu
Suggested-by: Dmitry Vyukov
Acked-by: Paul E. McKenney
Reviewed-and-tested-by: Dmitry Vyukov
Reviewed-by: Andrey Konovalov
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Andrew Morton
Cc: Josh Triplett
Cc: Mathieu Desnoyers
Cc: Lai Jiangshan
Cc: Joel Fernandes
---
Changes since v6:
- fix typo
---
include/linux/kasan.h | 2 ++
kernel/rcu/tree.c | 2 ++
mm/kasan/common.c | 4 ++--
mm/kasan/generic.c| 21 +
mm/kasan/kasan.h | 10 ++
mm/kasan/report.c | 28 +++-
6 files changed, 60 insertions(+), 7 deletions(-)
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 31314ca7c635..23b7ee00572d 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -174,11 +174,13 @@ static inline size_t kasan_metadata_size(struct
kmem_cache *cache) { return 0; }
void kasan_cache_shrink(struct kmem_cache *cache);
void kasan_cache_shutdown(struct kmem_cache *cache);
+void kasan_record_aux_stack(void *ptr);
#else /* CONFIG_KASAN_GENERIC */
static inline void kasan_cache_shrink(struct kmem_cache *cache) {}
static inline void kasan_cache_shutdown(struct kmem_cache *cache) {}
+static inline void kasan_record_aux_stack(void *ptr) {}
#endif /* CONFIG_KASAN_GENERIC */
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 06548e2ebb72..36a4ff7f320b 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -57,6 +57,7 @@
#include
#include
#include
+#include
#include "../time/tick-internal.h"
#include "tree.h"
@@ -2668,6 +2669,7 @@ __call_rcu(struct rcu_head *head, rcu_callback_t func)
head->func = func;
head->next = NULL;
local_irq_save(flags);
+ kasan_record_aux_stack(head);
rdp = this_cpu_ptr(_data);
/* Add the callback to our list. */
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 2906358e42f0..8bc618289bb1 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -41,7 +41,7 @@
#include "kasan.h"
#include "../slab.h"
-static inline depot_stack_handle_t save_stack(gfp_t flags)
+depot_stack_handle_t kasan_save_stack(gfp_t flags)
{
unsigned long entries[KASAN_STACK_DEPTH];
unsigned int nr_entries;
@@ -54,7 +54,7 @@ static inline depot_stack_handle_t save_stack(gfp_t flags)
static inline void set_track(struct kasan_track *track, gfp_t flags)
{
track->pid = current->pid;
- track->stack = save_stack(flags);
+ track->stack = kasan_save_stack(flags);
}
void kasan_enable_current(void)
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index 56ff8885fe2e..8acf48882ba2 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -325,3 +325,24 @@ DEFINE_ASAN_SET_SHADOW(f2);
DEFINE_ASAN_SET_SHADOW(f3);
DEFINE_ASAN_SET_SHADOW(f5);
DEFINE_ASAN_SET_SHADOW(f8);
+
+void kasan_record_aux_stack(void *addr)
+{
+ struct page *page = kasan_addr_to_page(addr);
+ struct kmem_cache *cache;
+ struct kasan_alloc_meta *alloc_info;
+ void *object;
+
+ if (!(page && PageSlab(page)))
+ return;
+
+ cache = page->slab_cache;
+ object = nearest_obj(cache, page, addr);
+ alloc_info = get_alloc_info(cache, object);
+
+ /*
+* record the last two call_rcu() call stacks.
+*/
+ alloc_info->aux_stack[1] = alloc_info->aux_stack[0];
+ alloc_info->aux_stack[0] = kasan_save_stack(GFP_NOWAIT);
+}
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index e8f37199d885..a7391bc83070 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -104,7 +104,15 @@ struct kasan_track {
struct kasan_alloc_meta {
struct kasan_track alloc_track;
+#ifdef CONFIG_KASAN_GENERIC
+ /*
+* call_rcu() call stack is stored into struct kasan_alloc_meta.
+* The free stack is stored into struct kasan_free_meta.
+*/
+ depot_stack_handle_t aux_stack[2];
+#else
struct kasan_track free_track[KASAN_NR_FREE_STACKS];
+#endif
#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
u8 free_pointer_tag[KASAN_NR_FREE_STACKS];
u8 free_track_idx;
@@ -159,6 +167,8 @@ void kasan_report_invalid_free(void *object, unsigned long
ip);
struct page *kasan_addr_to_page(const void *addr);
+depot_stack_handle_t kasan_save_stack(gfp_t flags);
+
#if defined(CONFIG_KASAN_GENERIC) && \
(defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
void quarantine_put(struct kasan_free_meta *info, struct kmem_cache *cache);
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
[PATCH v7 0/4] kasan: memorize and print call_rcu stack
This patchset improves KASAN reports by making them to have call_rcu() call stack information. It is useful for programmers to solve use-after-free or double-free memory issue. The KASAN report was as follows(cleaned up slightly): BUG: KASAN: use-after-free in kasan_rcu_reclaim+0x58/0x60 Freed by task 0: kasan_save_stack+0x24/0x50 kasan_set_track+0x24/0x38 kasan_set_free_info+0x18/0x20 __kasan_slab_free+0x10c/0x170 kasan_slab_free+0x10/0x18 kfree+0x98/0x270 kasan_rcu_reclaim+0x1c/0x60 Last call_rcu(): kasan_save_stack+0x24/0x50 kasan_record_aux_stack+0xbc/0xd0 call_rcu+0x8c/0x580 kasan_rcu_uaf+0xf4/0xf8 Generic KASAN will record the last two call_rcu() call stacks and print up to 2 call_rcu() call stacks in KASAN report. it is only suitable for generic KASAN. This feature considers the size of struct kasan_alloc_meta and kasan_free_meta, we try to optimize the structure layout and size , lets it get better memory consumption. [1]https://bugzilla.kernel.org/show_bug.cgi?id=198437 [2]https://groups.google.com/forum/#!searchin/kasan-dev/better$20stack$20traces$20for$20rcu%7Csort:date/kasan-dev/KQsjT_88hDE/7rNUZprRBgAJ Changes since v1: - remove new config option, default enable it in generic KASAN - test this feature in SLAB/SLUB, it is pass. - modify macro to be more clearly - modify documentation Changes since v2: - change recording from first/last to the last two call stacks - move free track into kasan free meta - init slab_free_meta on object slot creation - modify documentation Changes since v3: - change variable name to be more clearly - remove the redundant condition - remove init free meta-data and increasing object condition Changes since v4: - add a macro KASAN_KMALLOC_FREETRACK in order to check whether print free stack - change printing message - remove descriptions in Kocong.kasan Changes since v5: - reuse print_stack() in print_track() Changes since v6: - fix typo - renamed the variable name in testcase Walter Wu (4): rcu: kasan: record and print call_rcu() call stack kasan: record and print the free track kasan: add tests for call_rcu stack recording kasan: update documentation for generic kasan Documentation/dev-tools/kasan.rst | 3 +++ include/linux/kasan.h | 2 ++ kernel/rcu/tree.c | 2 ++ lib/test_kasan.c | 30 ++ mm/kasan/common.c | 26 -- mm/kasan/generic.c| 43 +++ mm/kasan/generic_report.c | 1 + mm/kasan/kasan.h | 23 +-- mm/kasan/quarantine.c | 1 + mm/kasan/report.c | 54 +++--- mm/kasan/tags.c | 37 + 11 files changed, 171 insertions(+), 51 deletions(-)
[PATCH v2] RISC-V: Don't mark init section as non-executable
The head text section (i.e. _start, secondary_start_sbi, etc) and the
init section fall under same page table level-1 mapping.
Currently, the runtime CPU hotplug is broken because we are marking
init section as non-executable which in-turn marks head text section
as non-executable.
Further investigating other architectures, it seems marking the init
section as non-executable is redundant because the init section pages
are anyway poisoned and freed.
To fix broken runtime CPU hotplug, we simply remove the code marking
the init section as non-executable.
Fixes: d27c3c90817e ("riscv: add STRICT_KERNEL_RWX support")
Cc: sta...@vger.kernel.org
Signed-off-by: Anup Patel
---
Changes since v1:
- Updated free_initmem() is same as generic free_initmem() defined in
init/main.c so we completely remove free_initmem() from arch/riscv
---
arch/riscv/mm/init.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 736de6c8739f..fdc772f57edc 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -479,17 +479,6 @@ static void __init setup_vm_final(void)
csr_write(CSR_SATP, PFN_DOWN(__pa_symbol(swapper_pg_dir)) | SATP_MODE);
local_flush_tlb_all();
}
-
-void free_initmem(void)
-{
- unsigned long init_begin = (unsigned long)__init_begin;
- unsigned long init_end = (unsigned long)__init_end;
-
- /* Make the region as non-execuatble. */
- set_memory_nx(init_begin, (init_end - init_begin) >> PAGE_SHIFT);
- free_initmem_default(POISON_FREE_INITMEM);
-}
-
#else
asmlinkage void __init setup_vm(uintptr_t dtb_pa)
{
--
2.25.1
Re: [PATCH 2/2] USB: PHY: JZ4770: Add support for Ingenic X1000 and X1830.
Hi "周琰杰,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on balbi-usb/testing/next]
[also build test WARNING on v5.7]
[cannot apply to usb/usb-testing 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/Zhou-Yanjie/Add-USB-PHY-support-for-Ingenic-X1000-and-X1830/20200601-030314
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
testing/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/usb/phy/phy-jz4770.c:267:19: warning: cast to smaller integer type
>> 'enum ingenic_usb_phy_version' from 'const void *'
>> [-Wvoid-pointer-to-enum-cast]
priv->version = (enum ingenic_usb_phy_version)match->data;
^
1 warning generated.
vim +267 drivers/usb/phy/phy-jz4770.c
253
254 static int jz4770_phy_probe(struct platform_device *pdev)
255 {
256 struct device *dev = >dev;
257 struct jz4770_phy *priv;
258 const struct of_device_id *match;
259 int err;
260
261 priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
262 if (!priv)
263 return -ENOMEM;
264
265 match = of_match_device(ingenic_usb_phy_of_matches, dev);
266 if (match)
> 267 priv->version = (enum
> ingenic_usb_phy_version)match->data;
268 else
269 return -ENODEV;
270
271 platform_set_drvdata(pdev, priv);
272 priv->dev = dev;
273 priv->phy.dev = dev;
274 priv->phy.otg = >otg;
275 priv->phy.label = "ingenic-usb-phy";
276 priv->phy.init = jz4770_phy_init;
277 priv->phy.shutdown = jz4770_phy_shutdown;
278
279 priv->otg.state = OTG_STATE_UNDEFINED;
280 priv->otg.usb_phy = >phy;
281 priv->otg.set_host = jz4770_phy_set_host;
282 priv->otg.set_peripheral = jz4770_phy_set_peripheral;
283
284 priv->base = devm_platform_ioremap_resource(pdev, 0);
285 if (IS_ERR(priv->base)) {
286 dev_err(dev, "Failed to map registers");
287 return PTR_ERR(priv->base);
288 }
289
290 priv->clk = devm_clk_get(dev, NULL);
291 if (IS_ERR(priv->clk)) {
292 err = PTR_ERR(priv->clk);
293 if (err != -EPROBE_DEFER)
294 dev_err(dev, "Failed to get clock");
295 return err;
296 }
297
298 priv->vcc_supply = devm_regulator_get(dev, "vcc");
299 if (IS_ERR(priv->vcc_supply)) {
300 err = PTR_ERR(priv->vcc_supply);
301 if (err != -EPROBE_DEFER)
302 dev_err(dev, "Failed to get regulator");
303 return err;
304 }
305
306 err = usb_add_phy(>phy, USB_PHY_TYPE_USB2);
307 if (err) {
308 if (err != -EPROBE_DEFER)
309 dev_err(dev, "Unable to register PHY");
310 return err;
311 }
312
313 return devm_add_action_or_reset(dev, jz4770_phy_remove,
>phy);
314 }
315
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2 5/6] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
On 30/05/20 7:20 pm, tudor.amba...@microchip.com wrote:
> Hi, Vignesh,
>
> On Tuesday, May 26, 2020 12:36:03 PM EEST Vignesh Raghavendra wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> From: Ramuthevar Vadivel Murugan
>>
>>
>> Move cadence-quadspi driver to use spi-mem framework. This is required
>> to make the driver support for SPI NAND flashes in future.
>>
>> Driver is feature compliant with existing SPI NOR version.
>>
>> Signed-off-by: Ramuthevar Vadivel Murugan
>> Signed-off-by: Vignesh
>> Raghavendra
>> ---
>> .../mtd/spi-nor/controllers/cadence-quadspi.c | 469 +++---
>> 1 file changed, 183 insertions(+), 286 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
>> b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c index
>> 608ca657ff7f..c1df4b221889 100644
>> --- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
>> +++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
>> @@ -3,6 +3,8 @@
>> * Driver for Cadence QSPI Controller
>> *
>> * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
>> + * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
>> + * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
>> */
>> #include
>> #include
>> @@ -17,9 +19,6 @@
>> #include
>> #include
>> #include
>> -#include
>> -#include
>> -#include
>> #include
>> #include
>> #include
>> @@ -27,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #define CQSPI_NAME "cadence-qspi"
>> @@ -36,16 +36,12 @@
>> #define CQSPI_NEEDS_WR_DELAY BIT(0)
>> #define CQSPI_DISABLE_DAC_MODE BIT(1)
>>
>> -/* Capabilities mask */
>> -#define CQSPI_BASE_HWCAPS_MASK \
>> - (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
>> - SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
>> - SNOR_HWCAPS_PP)
>> +/* Capabilities */
>> +#define CQSPI_SUPPORTS_OCTAL BIT(0)
>>
>> struct cqspi_st;
>>
>> struct cqspi_flash_pdata {
>> - struct spi_nor nor;
>> struct cqspi_st *cqspi;
>> u32 clk_rate;
>> u32 read_delay;
>> @@ -58,7 +54,6 @@ struct cqspi_flash_pdata {
>> u8 data_width;
>> u8 cs;
>> boolregistered;
>
> you can drop this, as it is no longer used
>
>> - booluse_direct_mode;
>> };
>>
>> struct cqspi_st {
>> @@ -71,7 +66,6 @@ struct cqspi_st {
>> void __iomem*ahb_base;
>> resource_size_t ahb_size;
>> struct completion transfer_complete;
>> - struct mutexbus_mutex;
>>
>> struct dma_chan *rx_chan;
>> struct completion rx_dma_complete;
>> @@ -85,6 +79,7 @@ struct cqspi_st {
>> boolrclk_en;
>> u32 trigger_address;
>> u32 wr_delay;
>> + booluse_dac_mode;
>
> is use_dac_mode better than use_direct_mode? If you prefer "dac", maybe you
> can rename this variable in 2/6
I will just keep "use_direct_mode" as is to minimize churn
>
>> struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
>> };
>>
>> @@ -283,9 +278,8 @@ static irqreturn_t cqspi_irq_handler(int this_irq, void
>> *dev) return IRQ_HANDLED;
>> }
>>
>> -static unsigned int cqspi_calc_rdreg(struct spi_nor *nor)
>> +static unsigned int cqspi_calc_rdreg(struct cqspi_flash_pdata *f_pdata)
>> {
>> - struct cqspi_flash_pdata *f_pdata = nor->priv;
>> u32 rdreg = 0;
>>
>> rdreg |= f_pdata->inst_width << CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB;
>> @@ -352,19 +346,21 @@ static int cqspi_exec_flash_cmd(struct cqspi_st
>> *cqspi, unsigned int reg) return cqspi_wait_idle(cqspi);
>> }
>>
>> -static int cqspi_command_read(struct spi_nor *nor, u8 opcode,
>> - u8 *rxbuf, size_t n_rx)
>> +static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
>> + const struct spi_mem_op *op)
>> {
>> - struct cqspi_flash_pdata *f_pdata = nor->priv;
>> struct cqspi_st *cqspi = f_pdata->cqspi;
>> void __iomem *reg_base = cqspi->iobase;
>> + u8 *rxbuf = op->data.buf.in;
>> + u8 opcode = op->cmd.opcode;
>
> dedicated variable for opcode is not really needed, it is used only once.
I did this intentionaly in view of 2 byte opcodes being added for Octal
DDR mode
>
>> + size_t n_rx = op->data.nbytes;
>> unsigned int rdreg;
>> unsigned int reg;
>> size_t read_len;
>> int status;
>>
>> if (!n_rx || n_rx > CQSPI_STIG_DATA_LEN_MAX || !rxbuf) {
>> - dev_err(nor->dev,
>> + dev_err(>pdev->dev,
>> "Invalid input argument, len %zu rxbuf 0x%p\n",
Re: [PATCH net-next v4] hinic: add set_channels ethtool_ops support
On Mon, Jun 01, 2020 at 09:42:06AM +, Luo bin wrote:
> add support to change TX/RX queue number with ethtool -L ethx combined
>
> Signed-off-by: Luo bin
> ---
[...]
The patch looks correct but I'm not sure how is this change
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_tx.c
> b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
> index 4c66a0bc1b28..6da761d7a6ef 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_tx.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
> @@ -470,6 +470,11 @@ netdev_tx_t hinic_xmit_frame(struct sk_buff *skb, struct
> net_device *netdev)
> struct hinic_txq *txq;
> struct hinic_qp *qp;
>
> + if (unlikely(!netif_carrier_ok(netdev))) {
> + dev_kfree_skb_any(skb);
> + return NETDEV_TX_OK;
> + }
> +
> txq = _dev->txqs[q_id];
> qp = container_of(txq->sq, struct hinic_qp, sq);
>
related to the rest. It rather looks as a fix/workaround for a race
condition you encountered while testing it but which could also happen
under other circumstances.
Michal
Re: [PATCH v4 4/4] kdb: Switch to use safer dbg_io_ops over console APIs
On Sun, 31 May 2020 at 10:58, kbuild test robot wrote:
>
> Hi Sumit,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on tty/tty-testing]
> [also build test ERROR on usb/usb-testing v5.7-rc7 next-20200529]
> [cannot apply to kgdb/kgdb-next]
> [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/Sumit-Garg/kdb-Improve-console-handling/20200531-075431
> base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
> tty-testing
> 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 errors (new ones prefixed by >>, old ones prefixed by <<):
>
> >> drivers/usb/early/ehci-dbgp.c:1062:24: error: assigning to 'struct console
> >> *' from incompatible type 'struct console'; take the address with &
> kgdbdbgp_io_ops.cons = early_dbgp_console;
> ^ ~~
> &
> 1 error generated.
>
Ah, my bad. Will fix it up in the next version.
-Sumit
> vim +1062 drivers/usb/early/ehci-dbgp.c
>
> 1046
> 1047 static int __init kgdbdbgp_parse_config(char *str)
> 1048 {
> 1049 char *ptr;
> 1050
> 1051 if (!ehci_debug) {
> 1052 if (early_dbgp_init(str))
> 1053 return -1;
> 1054 }
> 1055 ptr = strchr(str, ',');
> 1056 if (ptr) {
> 1057 ptr++;
> 1058 kgdbdbgp_wait_time = simple_strtoul(ptr, , 10);
> 1059 }
> 1060 kgdb_register_io_module(_io_ops);
> 1061 if (early_dbgp_console.index != -1)
> > 1062 kgdbdbgp_io_ops.cons = early_dbgp_console;
> 1063
> 1064 return 0;
> 1065 }
> 1066 early_param("kgdbdbgp", kgdbdbgp_parse_config);
> 1067
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Wohltätigkeitsspende von 2.000.000 Millionen Euro
Lieber Freund, Ich bin Herr Tayeb Souami, New Jersey, Vereinigte Staaten von Amerika, der Mega-Gewinner von $ 315million In Mega Millions Jackpot, spende ich an 5 zufällige Personen, wenn Sie diese E-Mail erhalten, dann wurde Ihre E-Mail nach einem Spinball ausgewählt.Ich habe den größten Teil meines Vermögens auf eine Reihe von Wohltätigkeitsorganisationen und Organisationen verteilt.Ich habe mich freiwillig dazu entschieden, die Summe von € 2.000.000,00 an Sie als eine der ausgewählten 5 zu spenden, um meine Gewinne zu überprüfen, sehen Sie bitte meine You Tube Seite unten. UHR MICH HIER: https://www.youtube.com/watch?v=Z6ui8ZDQ6Ks Das ist dein Spendencode: [TS530342018] Antworten Sie mit dem SPENDE-CODE an diese E-Mail:tayebsouam.spe...@gmail.com Ich hoffe, Sie und Ihre Familie glücklich zu machen. Grüße Herr Tayeb Souami
Re: [RFC PATCH -rcu lkmm] tools/memory-model/README: Expand dependency of klitmus7
On Mon, Jun 01, 2020 at 12:37:20AM +0900, Akira Yokosawa wrote:
> From 87048d7212f6cb16b0a2b85fa6d2f34c28b078c0 Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa
> Date: Sun, 31 May 2020 20:04:32 +0900
> Subject: [PATCH RFC] tools/memory-model/README: Expand dependency of klitmus7
>
> klitmus7 is independent of the memory model but depends on the
> build-target kernel release.
> It occasionally lost compatibility due to kernel API changes [1, 2, 3].
> It was remedied in a backwards-compatible manner respectively [4, 5, 6].
>
> Reflect this fact in README.
>
> [1]: b899a850431e ("compiler.h: Remove ACCESS_ONCE()")
> [2]: 0bb95f80a38f ("Makefile: Globally enable VLA warning")
> [3]: d56c0d45f0e2 ("proc: decouple proc from VFS with "struct proc_ops"")
> [4]: https://github.com/herd/herdtools7/commit/e87d7f9287d1
> ("klitmus: Use WRITE_ONCE and READ_ONCE in place of deprecated
> ACCESS_ONCE")
> [5]: https://github.com/herd/herdtools7/commit/a0cbb10d02be
> ("klitmus: Avoid variable length array")
> [6]: https://github.com/herd/herdtools7/commit/46b9412d3a58
> ("klitmus: Linux kernel v5.6.x compat")
>
> NOTE: [5] was ahead of herdtools7 7.53, which did not make an
> official release. Code generated by klitmus7 without [5] can still be
> built targeting Linux 4.20--5.5 if you don't care VLA warnings.
>
> Signed-off-by: Akira Yokosawa
Acked-by: Andrea Parri
Andrea
> ---
> Hi all,
>
> Recent struggle of Andrii with the use of klitmus7 on an up-to-date
> Linux system prompted me to add some explanation of klitmus7's dependency
> in README.
>
> As herdtools7 7.56 is still under development, I called out just HEAD
> in the compatibility table. Once 7.56 is released, the table can be
> updated.
>
> I'm not sure if this is the right place to carry such info.
> Anyway, I'd be glad if this patch can trigger a meaningful update of
> README.
>
> Thanks, Akira
> --
> tools/memory-model/README | 30 --
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/tools/memory-model/README b/tools/memory-model/README
> index b9c562e92981..90af203c3cf1 100644
> --- a/tools/memory-model/README
> +++ b/tools/memory-model/README
> @@ -28,8 +28,34 @@ downloaded separately:
> See "herdtools7/INSTALL.md" for installation instructions.
>
> Note that although these tools usually provide backwards compatibility,
> -this is not absolutely guaranteed. Therefore, if a later version does
> -not work, please try using the exact version called out above.
> +this is not absolutely guaranteed.
> +
> +For example, a future version of herd7 might not work with the model
> +in this release. A compatible model will likely be made available in
> +a later release of Linux kernel.
> +
> +If you absolutely need to run the model in this particular release,
> +please try using the exact version called out above.
> +
> +klitmus7 is independent of the model provided here. It has its own
> +dependency on a target kernel release where converted code is built
> +and executed. Any change in kernel APIs essential to klitmus7 will
> +necessitate an upgrade of klitmus7.
> +
> +If you find any compatibility issues in klitmus7, please inform the
> +memory model maintainers.
> +
> +klitmus7 Compatibility Table
> +
> +
> + ==
> + target Linux herdtools7
> + --
> + -- 4.18 7.48 --
> + 4.15 -- 4.19 7.49 --
> + 4.20 -- 5.5 7.54 --
> + 5.6 -- HEAD
> + ==
>
>
> ==
> --
> 2.17.1
>
Re: [PATCH] RDMA/hns: Uninitialized variable in modify_qp_init_to_rtr()
On Fri, May 29, 2020 at 11:39:18AM +0300, Dan Carpenter wrote:
> The "dmac" variable is used before it is initialized.
>
> Fixes: 494c3b312255 ("RDMA/hns: Refactor the QP context filling process
> related to WQE buffer configure")
> Signed-off-by: Dan Carpenter
> ---
> drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Thanks,
Reviewed-by: Leon Romanovsky
Re: [PATCH v5 02/11] dt-bindings: dma: dw: Add max burst transaction length property
On 29-05-20, 17:40, Serge Semin wrote: > This array property is used to indicate the maximum burst transaction > length supported by each DMA channel. > > Signed-off-by: Serge Semin > Cc: Alexey Malahov > Cc: Thomas Bogendoerfer > Cc: Arnd Bergmann > Cc: Andy Shevchenko > Cc: linux-m...@vger.kernel.org > > --- > > Changelog v2: > - Rearrange SoBs. > - Move $ref to the root level of the properties. So do with the > constraints. > - Set default max-burst-len to 256 TR-WIDTH words. > > Changelog v3: > - Add more details into the property description about what limitations > snps,max-burst-len defines. > --- > .../bindings/dma/snps,dma-spear1340.yaml | 15 +++ > 1 file changed, 15 insertions(+) Acked-by: Viresh Kumar -- viresh
Re: [PATCH v5 01/11] dt-bindings: dma: dw: Convert DW DMAC to DT binding
On 29-05-20, 17:40, Serge Semin wrote: > Modern device tree bindings are supposed to be created as YAML-files > in accordance with dt-schema. This commit replaces the Synopsis > Designware DMA controller legacy bare text bindings with YAML file. > The only required prorties are "compatible", "reg", "#dma-cells" and > "interrupts", which will be used by the driver to correctly find the > controller memory region and handle its events. The rest of the properties > are optional, since in case if either "dma-channels" or "dma-masters" isn't > specified, the driver will attempt to auto-detect the IP core > configuration. > > Signed-off-by: Serge Semin > Reviewed-by: Rob Herring Acked-by: Viresh Kumar -- viresh
Re: [PATCH] RISC-V: Don't mark init section as non-executable
On Sun, May 31, 2020 at 3:28 PM Anup Patel wrote:
>
> The head text section (i.e. _start, secondary_start_sbi, etc) and the
> init section fall under same page table level-1 mapping.
>
> Currently, the runtime CPU hotplug is broken because we are marking
> init section as non-executable which in-turn marks head text section
> as non-executable.
>
> Further investigating other architectures, it seems marking the init
> section as non-executable is redundant because the init section pages
> are anyway poisoned and freed.
>
> To fix broken runtime CPU hotplug, we simply remove the code marking
> the init section as non-executable.
>
> Fixes: d27c3c90817e ("riscv: add STRICT_KERNEL_RWX support")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Anup Patel
> ---
> arch/riscv/mm/init.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 736de6c8739f..e0f8ccab8a41 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -482,11 +482,6 @@ static void __init setup_vm_final(void)
>
> void free_initmem(void)
> {
> - unsigned long init_begin = (unsigned long)__init_begin;
> - unsigned long init_end = (unsigned long)__init_end;
> -
> - /* Make the region as non-execuatble. */
> - set_memory_nx(init_begin, (init_end - init_begin) >> PAGE_SHIFT);
> free_initmem_default(POISON_FREE_INITMEM);
> }
I just realized that updated free_initmem() over here is exactly
same as generic free_initmem() defined in init/main.c so it's better
to remove free_initmem() from here. I will send v2.
Regards,
Anup
Re: [PATCH v11 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
On Fri, May 15, 2020 at 2:53 PM Xin Ji wrote:
> +
> +static int anx7625_bridge_attach(struct drm_bridge *bridge)
Latest drm_bridge api:
int (*attach)(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags);
https://elixir.bootlin.com/linux/v5.7-rc7/source/include/drm/drm_bridge.h#L70
> +{
> + struct anx7625_data *ctx = bridge_to_anx7625(bridge);
> + int err;
Can i trust you?
Dear Friend, Please i want you to read this letter very carefully and i must apologize for berging this message into your mail box without any formal introduction due to the urgency and confidential of this issue and i know that this message will come to you as a surprise, Please this is not a joke and i will not like you to joke with it.I am Mr.Suleman Bello, a staff in African Development Bank (A.D.B) Ouagadougou, Burkina faso West Africa.I discovered existing dormant account for years. When I discovered that there had been neither continuation nor withdrawals from this account for this long period and according to the laws and constitution guiding this banking institution, any unserviceable account for more than (7) seven years, that fund will be transferred to national treasury as unclaimed fund. I Hoped that you will not expose or betray this trust and confident that i am about to extablish with you for the mutual benefit of you and i,I need your urgent assistance in transferring the sum of $10.5 )million usd into your account within 7 banking days. This money has been dormant for years in our Bank, and The request of foreigner in this transaction is necessary because our late customer was a foreigner and a burkinabe cannot stand as next of kin to a foreigner.Because of the static of this transaction I want you to stand as the next of kin so that our bank will accord you the recognition and have the fund transferred to your account. Upon your response, I shall then provide you with further information and more deities that will help you understand the transaction. I am expecting your urgent response to enable me inform you on how the business will be executed. Please I would like you to keep this transaction confidential and as a top secret or delete if you are not interested. Thanks Mr.Suleman Bello.
Re: [PATCH] usb: cdns3: fix possible buffer overflow caused by bad DMA value
On 20-05-30 11:24:00, Jia-Ju Bai wrote: > In cdns3_ep0_setup_phase(): > struct usb_ctrlrequest *ctrl = priv_dev->setup_buf; > > Because priv_dev->setup_buf (allocated in cdns3_gadget_start) is stored > in DMA memory, and thus ctrl is a DMA value. > > cdns3_ep0_setup_phase() > cdns3_ep0_standard_request(priv_dev, ctrl) > cdns3_req_ep0_get_status(priv_dev, ctrl) > index = cdns3_ep_addr_to_index(ctrl->wIndex); > priv_ep = priv_dev->eps[index]; > > cdns3_ep0_setup_phase() > cdns3_ep0_standard_request(priv_dev, ctrl) > cdns3_req_ep0_handle_feature(priv_dev, ctrl_req, 0) > cdns3_ep0_feature_handle_endpoint(priv_dev, ctrl, set) > index = cdns3_ep_addr_to_index(ctrl->wIndex); > priv_ep = priv_dev->eps[index]; > > In these cases, ctrl->wIndex can be be modified at anytime by malicious > hardware, and thus a buffer overflow can occur when the code > "priv_dev->eps[index]" is executed. > Did you see the setup buffer is overwritten before the setup handling is finished? > To fix these possible bugs, index is checked before being used. I think the better fix is to use one additional buffer for struct usb_ctrlrequest, and copy the dma_buf to it after setup packet has received, then use the value stored in this buffer for later operation, it could avoid quitting the code which is useful in fact. Peter > > Signed-off-by: Jia-Ju Bai > --- > drivers/usb/cdns3/ep0.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/usb/cdns3/ep0.c b/drivers/usb/cdns3/ep0.c > index e71240b386b4..0a80c7ade613 100644 > --- a/drivers/usb/cdns3/ep0.c > +++ b/drivers/usb/cdns3/ep0.c > @@ -265,6 +265,8 @@ static int cdns3_req_ep0_get_status(struct cdns3_device > *priv_dev, > return cdns3_ep0_delegate_req(priv_dev, ctrl); > case USB_RECIP_ENDPOINT: > index = cdns3_ep_addr_to_index(ctrl->wIndex); > + if (index >= CDNS3_ENDPOINTS_MAX_COUNT) > + return -EINVAL; > priv_ep = priv_dev->eps[index]; > > /* check if endpoint is stalled or stall is pending */ > @@ -388,6 +390,9 @@ static int cdns3_ep0_feature_handle_endpoint(struct > cdns3_device *priv_dev, > return 0; > > index = cdns3_ep_addr_to_index(ctrl->wIndex); > + if (index >= CDNS3_ENDPOINTS_MAX_COUNT) > + return -EINVAL; > + > priv_ep = priv_dev->eps[index]; > > cdns3_select_ep(priv_dev, ctrl->wIndex); > -- > 2.17.1 > -- Thanks, Peter Chen
Re: [PATCH v6 3/6] irqchip: RISC-V per-HART local interrupt controller driver
On Sun, May 31, 2020 at 4:23 PM Marc Zyngier wrote: > > On 2020-05-31 11:06, Anup Patel wrote: > > On Sun, May 31, 2020 at 3:03 PM Marc Zyngier wrote: > >> > >> On 2020-05-31 06:36, Anup Patel wrote: > >> > On Sat, May 30, 2020 at 5:31 PM Marc Zyngier wrote: > >> > >> [...] > >> > >> >> > plic_set_threshold(handler, PLIC_DISABLE_THRESHOLD); > >> >> > >> >> Why do you need to both disable the interrupt *and* change the > >> >> priority > >> >> threshold? It seems to be that one of them should be enough, but my > >> >> kno9wledge of the PLIC is limited. In any case, this would deserve a > >> >> comment. > >> > > >> > Okay, I will test and remove "disable the interrupt" part from > >> > plic_dying_cpu(). > >> > >> Be careful, as interrupt enabling/disabling is refcounted in order > >> to allow nesting. If you only enable on CPU_ON and not disable > >> on CPU_OFF, you will end-up with a depth that only increases, > >> up to the point where you hit the roof (it will take a while though). > >> > >> I would keep the enable/disable as is, and drop the priority > >> setting from the CPU_OFF path. > > > > The PLIC threshold is like GICv2 CPU interface enable/disable. > > Looking at the documentation[1], that's not really a correct analogy: > > - The PLIC is far removed from the CPU, and is more akin a GICv3 >distributor. The INTC itself is more like a GICv3 redistributor, >as it deals with local interrupts only. I don't see anything >in the RISC-V architecture that actually behaves like a GIC >CPU interface (not necessarily a bad thing...). > > - The threshold register is not an ON/OFF, but a priority mask, >similar to the GIC PMR (except that the PMR lives in the CPU >interface and affects all interrupts targetting this CPU while >this only seem to affect PLIC interrupts and not the INTC interrupts). >You may be using it as an ON/OFF for now as you don't support >multiple priorities yet, but that's just a SW thing. Yes, your analogy is correct. BTW, PLIC does not handle MSI and does not have virtualization support pass-through interrupts. We will most likely see a new RISC-V interrupt controller spec for these capabilities. Also, the PLIC spec is now owned by RISC-V foundation (not SiFive) so we will have to rename the driver to "irq-riscv-plic" and will have a new generic compatible string "riscv,plic-1.0.0". One of us (me or Palmer) will send separate patches for this renaming. I hope you will be fine with this?? (Refer, https://github.com/riscv/riscv-plic-spec) > > > Based on your comment, we should only program the PLIC threshold > > in CPU_ON and don't touch the PLIC threshold in CPU_OFF. Right?? > > This seems like the correct thing to do. Sure, I will update. > > M. > > [1] > https://sifive.cdn.prismic.io/sifive%2Fdc4980ff-17db-448b-b521-4c7ab26b7488_sifive+u54-mc+manual+v19.08.pdf > -- > Jazz is not dead. It just smells funny... Regards, Anup
Re: [PATCH] OPP: Check for bandwidth values before creating icc paths
On 29-05-20, 19:47, Sibi Sankar wrote: > opp_np needs to be subjected > to NULL check as well. No, it isn't. It should already be valid and is set by the OPP core. Actually we don't need to do of_node_get(opp_table->np) and just use np, I did that to not have a special case while putting the resource. > Tested-by: Sibi Sankar > Reviewed-by: Sibi Sankar Thanks. -- viresh
Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass
On 5/22/20 9:08 PM, Thiago Jung Bauermann wrote: Hello Prakhar, Prakhar Srivastava writes: On 5/12/20 4:05 PM, Rob Herring wrote: On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote: Hi Mark, Please don't top post. This patch set currently only address the Pure DT implementation. EFI and ACPI implementations will be posted in subsequent patchsets. The logs are intended to be carried over the kexec and once read the logs are no longer needed and in prior conversation with James( https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1...@arm.com/) the apporach of using a chosen node doesn't support the case. The DT entries make the reservation permanent and thus doesnt need kernel segments to be used for this, however using a chosen-node with reserved memory only changes the node information but memory still is reserved via reserved-memory section. I think Mark's point was whether it needs to be permanent. We don't hardcode the initrd address for example. Thankyou for clarifying my misunderstanding, i am modelling this keeping to the TPM log implementation that uses a reserved memory. I will rev up the version with chosen-node support. That will make the memory reservation free after use. Nice. Do you intend to use the same property that powerpc uses (linux,ima-kexec-buffer)? I was naming it ima-buffer, but naming is not a huge concern. I will use linux,ima-kexec-buffer. On 5/5/20 2:59 AM, Mark Rutland wrote: Hi Prakhar, On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote: IMA during kexec(kexec file load) verifies the kernel signature and measures What's IMAIMA is a LSM attempting to detect if files have been accidentally or maliciously altered, both remotely and locally, it can also be used to appraise a file's measurement against a "good" value stored as an extended attribute, and enforce local file integrity. IMA also validates and measures the signers of the kernel and initrd during kexec. The measurements are extended to PCR 10(configurable) and the logs stored in memory, however once kexec'd the logs are lost. Kexec is used as secondary boot loader in may use cases and loosing the signer creates a security hole. This patch is an implementation to carry over the logs and making it possible to remotely validate the signers of the kernel and initrd. Such a support exits only in powerpc. This patch makes the carry over of logs architecture independent and puts the complexity in a driver. If I'm not mistaken, the code at arch/powerpc/kexec/ima.c isn't actually powerpc-specific. It could be moved to an arch-independent directory and used by any other architecture which supports device trees. I think that's the simplest way forward. And to be honest I'm still trying to understand why you didn't take that approach. Did you try it and hit some obstacle or noticed a disadvantage for your use case? The approach i have in this patch set is to provide an abstraction layer that can be called from any architecture. However taking a deeper look only the setup dtb is probably architecture specific, only because the architecture specific kexec sets up the device tree. I can also move the code up in security/ima. However i do have some concerns with layering. I am hoping you can provide me with some guidance in this aspect, i will send you the patch i am working on to get some early feedback. Thanks, Prakhar Srivastava -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH] input: tablet: aiptek: fix possible buffer overflow caused by bad DMA value in aiptek_irq()
Hi Jia-Ju,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on input/next]
[also build test WARNING on 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/Jia-Ju-Bai/input-tablet-aiptek-fix-possible-buffer-overflow-caused-by-bad-DMA-value-in-aiptek_irq/20200601-015649
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: mips-randconfig-r032-20200531 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 9.3.0
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
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
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 <<):
In file included from include/asm-generic/div64.h:25,
from arch/mips/include/asm/div64.h:12,
from include/linux/math64.h:6,
from include/linux/jiffies.h:6,
from drivers/input/tablet/aiptek.c:60:
drivers/input/tablet/aiptek.c: In function 'aiptek_irq':
drivers/input/tablet/aiptek.c:744:7: error: 'marco' undeclared (first use in
this function); did you mean 'macro'?
744 | if (marco > 0 && macro < 25) {
| ^
include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) :
__trace_if_value(cond))
|^~~~
>> drivers/input/tablet/aiptek.c:744:3: note: in expansion of macro 'if'
744 | if (marco > 0 && macro < 25) {
| ^~
drivers/input/tablet/aiptek.c:744:7: note: each undeclared identifier is
reported only once for each function it appears in
744 | if (marco > 0 && macro < 25) {
| ^
include/linux/compiler.h:58:52: note: in definition of macro '__trace_if_var'
58 | #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) :
__trace_if_value(cond))
|^~~~
>> drivers/input/tablet/aiptek.c:744:3: note: in expansion of macro 'if'
744 | if (marco > 0 && macro < 25) {
| ^~
vim +/if +744 drivers/input/tablet/aiptek.c
377
378 /***
379 * aiptek_irq can receive one of six potential reports.
380 * The documentation for each is in the body of the function.
381 *
382 * The tablet reports on several attributes per invocation of
383 * aiptek_irq. Because the Linux Input Event system allows the
384 * transmission of ONE attribute per input_report_xxx() call,
385 * collation has to be done on the other end to reconstitute
386 * a complete tablet report. Further, the number of Input Event reports
387 * submitted varies, depending on what USB report type, and
circumstance.
388 * To deal with this, EV_MSC is used to indicate an 'end-of-report'
389 * message. This has been an undocumented convention understood by the
kernel
390 * tablet driver and clients such as gpm and XFree86's tablet drivers.
391 *
392 * Of the information received from the tablet, the one piece I
393 * cannot transmit is the proximity bit (without resorting to an EV_MSC
394 * convention above.) I therefore have taken over REL_MISC and ABS_MISC
395 * (for relative and absolute reports, respectively) for communicating
396 * Proximity. Why two events? I thought it interesting to know if the
397 * Proximity event occurred while the tablet was in absolute or relative
398 * mode.
399 * Update: REL_MISC proved not to be such a good idea. With REL_MISC you
400 * get an event transmitted each time. ABS_MISC works better, since it
401 * can be set and re-set. Thus, only using ABS_MISC from now on.
402 *
403 * Other tablets use the notion of a certain minimum stylus pressure
404 * to infer proximity. While that could have been done, that is yet
405 * another 'by convention' behavior, the documentation for which
406 * would be spread between two (or more) pieces of software.
407 *
408 * EV_MSC usage was terminated for this purpose in Linux 2.5.x, and
409 * replaced with the input_sync() method (which emits EV_SYN.)
410 */
411
412 static void aiptek_irq(struct urb *urb)
413 {
414 struct aiptek *aiptek = urb->context;
415 unsigned char *data = aiptek->data;
416 struct input_dev *inputdev
Re: [PATCH] i2c: sh_mobile: Fix compilation warning
On 29-05-20, 14:12, Wolfram Sang wrote: > On Thu, May 09, 2019 at 10:13:46AM +0530, Viresh Kumar wrote: > > This currently generates a warning: > > > > drivers/i2c/busses/i2c-sh_mobile.c: In function 'sh_mobile_i2c_isr': > > drivers/i2c/busses/i2c-sh_mobile.c:399:26: warning: 'data' may be used > > uninitialized in this function [-Wmaybe-uninitialized] > > > > Though the code looks okay and shouldn't ever use the variable > > uninitialized. > > > > Fix the warning by moving the code around and getting rid of 'data'. > > > > Compile tested only. > > > > Signed-off-by: Viresh Kumar > > Tested on a Renesas Lager board (R-Car H2). Dumping register sets > produces identical results. > > Tested-by: Wolfram Sang > > And code is actually cleaner now. > > Applied to for-next, thanks! > Almost after an year, wondering on how you reached this patch now :) -- viresh
[PATCH V2] mailbox: imx: Add context save/restore for suspend/resume
From: Dong Aisheng
For "mem" mode suspend on i.MX8 SoCs, MU settings could be
lost because its power is off, so save/restore is needed
for MU settings during suspend/resume. However, the restore
can ONLY be done when MU settings are actually lost, for the
scenario of settings NOT lost in "freeze" mode suspend, since
there could be still IPC going on multiple CPUs, restoring the
MU settings could overwrite the TIE by mistake and cause system
freeze, so need to make sure ONLY restore the MU settings when
it is powered off, Anson fixes this by checking whether restore
is actually needed when resume.
Signed-off-by: Dong Aisheng
Signed-off-by: Anson Huang
---
Changes since V1:
- change the author and add more fix note in commit log.
---
drivers/mailbox/imx-mailbox.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 97bf0ac..b53cf63 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -67,6 +67,8 @@ struct imx_mu_priv {
struct clk *clk;
int irq;
+ u32 xcr;
+
boolside_b;
};
@@ -583,12 +585,45 @@ static const struct of_device_id imx_mu_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
+static int imx_mu_suspend_noirq(struct device *dev)
+{
+ struct imx_mu_priv *priv = dev_get_drvdata(dev);
+
+ priv->xcr = imx_mu_read(priv, priv->dcfg->xCR);
+
+ return 0;
+}
+
+static int imx_mu_resume_noirq(struct device *dev)
+{
+ struct imx_mu_priv *priv = dev_get_drvdata(dev);
+
+ /*
+* ONLY restore MU when context lost, the TIE could
+* be set during noirq resume as there is MU data
+* communication going on, and restore the saved
+* value will overwrite the TIE and cause MU data
+* send failed, may lead to system freeze. This issue
+* is observed by testing freeze mode suspend.
+*/
+ if (!imx_mu_read(priv, priv->dcfg->xCR))
+ imx_mu_write(priv, priv->xcr, priv->dcfg->xCR);
+
+ return 0;
+}
+
+static const struct dev_pm_ops imx_mu_pm_ops = {
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx_mu_suspend_noirq,
+ imx_mu_resume_noirq)
+};
+
static struct platform_driver imx_mu_driver = {
.probe = imx_mu_probe,
.remove = imx_mu_remove,
.driver = {
.name = "imx_mu",
.of_match_table = imx_mu_dt_ids,
+ .pm = _mu_pm_ops,
},
};
module_platform_driver(imx_mu_driver);
--
2.7.4
WARNING in snd_usbmidi_submit_urb/usb_submit_urb
Hello, syzbot found the following crash on: HEAD commit:bdc48fa1 checkpatch/coding-style: deprecate 80-column warn.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15d6458610 kernel config: https://syzkaller.appspot.com/x/.config?x=129ea1e5950835e5 dashboard link: https://syzkaller.appspot.com/bug?extid=5f1d24c49c1d2c427497 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12d70cf210 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+5f1d24c49c1d2c427...@syzkaller.appspotmail.com RBP: 0078bf00 R08: R09: R10: R11: 0246 R12: 0004 R13: 07dc R14: 004cab2a R15: 7f5ab0e216d4 [ cut here ] URB d6b1ff88 submitted while active WARNING: CPU: 1 PID: 8661 at drivers/usb/core/urb.c:363 usb_submit_urb+0x10c1/0x13b0 drivers/usb/core/urb.c:363 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 8661 Comm: syz-executor.0 Not tainted 5.7.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x188/0x20d lib/dump_stack.c:118 panic+0x2e3/0x75c kernel/panic.c:221 __warn.cold+0x2f/0x35 kernel/panic.c:582 report_bug+0x27b/0x2f0 lib/bug.c:195 fixup_bug arch/x86/kernel/traps.c:175 [inline] fixup_bug arch/x86/kernel/traps.c:170 [inline] do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:267 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:286 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027 RIP: 0010:usb_submit_urb+0x10c1/0x13b0 drivers/usb/core/urb.c:363 Code: 89 de e8 32 54 6a fc 84 db 0f 85 42 f6 ff ff e8 f5 52 6a fc 4c 89 fe 48 c7 c7 60 46 ab 88 c6 05 22 f3 7b 05 01 e8 b7 82 3b fc <0f> 0b e9 20 f6 ff ff c7 44 24 14 01 00 00 00 e9 d7 f6 ff ff 41 bd RSP: 0018:c9000a37f2c8 EFLAGS: 00010282 RAX: RBX: RCX: RDX: RSI: 815cf161 RDI: f5200146fe4b RBP: dc00 R08: 88808f2242c0 R09: ed1015ce66a9 R10: 8880ae733547 R11: ed1015ce66a8 R12: 0cc0 R13: fff0 R14: 8880a37b6400 R15: 8880894c1600 snd_usbmidi_submit_urb+0x19/0x60 sound/usb/midi.c:194 snd_usbmidi_input_start_ep sound/usb/midi.c:2313 [inline] snd_usbmidi_input_start.part.0+0xbe/0x1c0 sound/usb/midi.c:2329 snd_usbmidi_input_start sound/usb/midi.c:1119 [inline] substream_open.isra.0+0x505/0x830 sound/usb/midi.c:1119 open_substream+0x42e/0x880 sound/core/rawmidi.c:299 rawmidi_open_priv+0x2e8/0x6e0 sound/core/rawmidi.c:342 snd_rawmidi_kernel_open+0x1b5/0x270 sound/core/rawmidi.c:382 midisynth_subscribe+0xf2/0x330 sound/core/seq/seq_midi.c:170 subscribe_port sound/core/seq/seq_ports.c:412 [inline] check_and_subscribe_port+0x5b5/0x800 sound/core/seq/seq_ports.c:495 snd_seq_port_connect+0x2e4/0x510 sound/core/seq/seq_ports.c:564 snd_seq_ioctl_subscribe_port+0x1df/0x310 sound/core/seq/seq_clientmgr.c:1484 snd_seq_kernel_client_ctl+0xeb/0x130 sound/core/seq/seq_clientmgr.c:2353 snd_seq_oss_midi_open+0x3cb/0x640 sound/core/seq/oss/seq_oss_midi.c:364 snd_seq_oss_synth_setup_midi+0x123/0x520 sound/core/seq/oss/seq_oss_synth.c:269 snd_seq_oss_open+0x7fa/0x980 sound/core/seq/oss/seq_oss_init.c:261 odev_open+0x6c/0x90 sound/core/seq/oss/seq_oss.c:125 soundcore_open+0x446/0x600 sound/sound_core.c:593 chrdev_open+0x219/0x5c0 fs/char_dev.c:414 do_dentry_open+0x4ba/0x1290 fs/open.c:797 do_open fs/namei.c:3229 [inline] path_openat+0x1e59/0x27d0 fs/namei.c:3346 do_filp_open+0x192/0x260 fs/namei.c:3373 do_sys_openat2+0x585/0x7d0 fs/open.c:1148 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
[PATCH] riscv: fix build warning of missing prototypes
Add the missing header in file, it was losed in original implementation.
The warning message as follows:
- no previous prototype for 'patch_text_nosync' [-Wmissing-prototypes]
- no previous prototype for 'patch_text' [-Wmissing-prototypes]
Signed-off-by: Zong Li
Reported-by: kbuild test robot
---
arch/riscv/kernel/patch.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c
index 5805791cd5b5..d4a64dfed342 100644
--- a/arch/riscv/kernel/patch.c
+++ b/arch/riscv/kernel/patch.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
struct patch_insn {
void *addr;
--
2.26.2
[PATCH V2 3/3] clk: imx8mp: add mu root clk
From: Peng Fan
Add mu root clk for mu mailbox usage.
Signed-off-by: Peng Fan
Reviewed-by: Dong Aisheng
---
drivers/clk/imx/clk-imx8mp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index b4d9db9d5bf1..ca747712400f 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -680,6 +680,7 @@ static int imx8mp_clocks_probe(struct platform_device *pdev)
hws[IMX8MP_CLK_I2C2_ROOT] = imx_clk_hw_gate4("i2c2_root_clk", "i2c2",
ccm_base + 0x4180, 0);
hws[IMX8MP_CLK_I2C3_ROOT] = imx_clk_hw_gate4("i2c3_root_clk", "i2c3",
ccm_base + 0x4190, 0);
hws[IMX8MP_CLK_I2C4_ROOT] = imx_clk_hw_gate4("i2c4_root_clk", "i2c4",
ccm_base + 0x41a0, 0);
+ hws[IMX8MP_CLK_MU_ROOT] = imx_clk_hw_gate4("mu_root_clk", "ipg_root",
ccm_base + 0x4210, 0);
hws[IMX8MP_CLK_OCOTP_ROOT] = imx_clk_hw_gate4("ocotp_root_clk",
"ipg_root", ccm_base + 0x4220, 0);
hws[IMX8MP_CLK_PCIE_ROOT] = imx_clk_hw_gate4("pcie_root_clk",
"pcie_aux", ccm_base + 0x4250, 0);
hws[IMX8MP_CLK_PWM1_ROOT] = imx_clk_hw_gate4("pwm1_root_clk", "pwm1",
ccm_base + 0x4280, 0);
--
2.16.4
[PATCH V2 2/3] arm64: dts: imx8m: add mu node
From: Peng Fan
Add mu node to let A53 could communicate with M Core.
Signed-off-by: Peng Fan
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 9 +
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 9 +
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 9 +
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 9 +
4 files changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index aaf6e71101a1..fc001fb971e9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -775,6 +775,15 @@
status = "disabled";
};
+ mu: mailbox@30aa {
+ compatible = "fsl,imx8mm-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa 0x1>;
+ interrupts = ;
+ clocks = < IMX8MM_CLK_MU_ROOT>;
+ clock-names = "mu";
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mm-usdhc",
"fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 9a4b65a267d4..c8290d21ccc9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -675,6 +675,15 @@
status = "disabled";
};
+ mu: mailbox@30aa {
+ compatible = "fsl,imx8mn-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa 0x1>;
+ interrupts = ;
+ clocks = < IMX8MN_CLK_MU_ROOT>;
+ clock-names = "mu";
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mn-usdhc",
"fsl,imx7d-usdhc";
reg = <0x30b4 0x1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 45e2c0a4e889..b530804f763e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -621,6 +621,15 @@
status = "disabled";
};
+ mu: mailbox@30aa {
+ compatible = "fsl,imx8mp-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa 0x1>;
+ interrupts = ;
+ clocks = < IMX8MP_CLK_MU_ROOT>;
+ clock-names = "mu";
+ #mbox-cells = <2>;
+ };
+
i2c5: i2c@30ad {
compatible = "fsl,imx8mp-i2c", "fsl,imx21-i2c";
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 978f8122c0d2..66ba8da704f6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -959,6 +959,15 @@
status = "disabled";
};
+ mu: mailbox@30aa {
+ compatible = "fsl,imx8mq-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa 0x1>;
+ interrupts = ;
+ clocks = < IMX8MQ_CLK_MU_ROOT>;
+ clock-names = "mu";
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b4 {
compatible = "fsl,imx8mq-usdhc",
"fsl,imx7d-usdhc";
--
2.16.4
[PATCH V2 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
From: Peng Fan Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs Signed-off-by: Peng Fan --- Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt index 26b7a88c2fea..906377acf2cd 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt @@ -18,7 +18,8 @@ Messaging Unit Device Node: Required properties: --- - compatible : should be "fsl,-mu", the supported chips include - imx6sx, imx7s, imx8qxp, imx8qm. + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn, + imx8mp. The "fsl,imx6sx-mu" compatible is seen as generic and should be included together with SoC specific compatible. There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" -- 2.16.4
[PATCH V2 0/3] imx8m: add mu support
From: Peng Fan V2: Add dt-bindings Merge dts changes into one patch, since all is to add mu node Add mu dt bindings Add mu node Add i.MX8MP mu root clk Peng Fan (3): dt-bindings: mailbox: imx-mu: support i.MX8M arm64: dts: imx8m: add mu node clk: imx8mp: add mu root clk Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++- arch/arm64/boot/dts/freescale/imx8mm.dtsi| 9 + arch/arm64/boot/dts/freescale/imx8mn.dtsi| 9 + arch/arm64/boot/dts/freescale/imx8mp.dtsi| 9 + arch/arm64/boot/dts/freescale/imx8mq.dtsi| 9 + drivers/clk/imx/clk-imx8mp.c | 1 + 6 files changed, 39 insertions(+), 1 deletion(-) -- 2.16.4
Re: [PATCH] usb: gadget: f_acm: don't disable disabled EP
On 20-05-30 19:15:52, Michał Mirosław wrote:
> On Sat, May 30, 2020 at 01:03:17AM +, Peter Chen wrote:
> >
> > > > > @@ -425,9 +425,11 @@ static int acm_set_alt(struct usb_function *f,
> > > > > unsigned
> > > intf, unsigned alt)
> > > > > /* we know alt == 0, so this is an activation or a reset */
> > > > >
> > > > > if (intf == acm->ctrl_id) {
> > > > > - dev_vdbg(>gadget->dev,
> > > > > - "reset acm control interface %d\n",
> > > > > intf);
> > > > > - usb_ep_disable(acm->notify);
> > > > > + if (acm->notify->enabled) {
> > > > > + dev_vdbg(>gadget->dev,
> > > > > + "reset acm control interface
> > > > > %d\n", intf);
> > > > > + usb_ep_disable(acm->notify);
> > > > > + }
> > > >
> > > > But it does not fix any issues, the usb_ep_disable checks 'enabled'
> > > > flag.
> > >
> > > It generates spurious trace events if you enable them.
> > You mean the trace events from core.c? If it is, we could try to improve it
> > and indicate it is already enabled or disabled.
>
> It is indicated in return code, but the problem is that this generates
> noise and wastes debugging time. The problem I was seeing manifested
> itself as disabling disabled EPs and desync of EP state between core
> and UDC driver. The patch avoids the noise and makes the code obvious.
> (This check was there at some point in time, BTW.)
>
Reviewed-by: Peter Chen
--
Thanks,
Peter Chen
[PATCH] misc: atmel-ssc: lock with mutex instead of spinlock
Uninterruptible context is not needed in the driver and causes lockdep
warning because of mutex taken in of_alias_get_id(). Convert the lock to
mutex to avoid the issue.
Cc: sta...@vger.kernel.org
Signed-off-by: Michał Mirosław
---
drivers/misc/atmel-ssc.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 1322e29bc37a..5cc032097476 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -20,7 +20,7 @@
#include "../../sound/soc/atmel/atmel_ssc_dai.h"
/* Serialize access to ssc_list and user count */
-static DEFINE_SPINLOCK(user_lock);
+static DEFINE_MUTEX(user_lock);
static LIST_HEAD(ssc_list);
struct ssc_device *ssc_request(unsigned int ssc_num)
@@ -28,7 +28,7 @@ struct ssc_device *ssc_request(unsigned int ssc_num)
int ssc_valid = 0;
struct ssc_device *ssc;
- spin_lock(_lock);
+ mutex_lock(_lock);
list_for_each_entry(ssc, _list, list) {
if (ssc->pdev->dev.of_node) {
if (of_alias_get_id(ssc->pdev->dev.of_node, "ssc")
@@ -44,18 +44,18 @@ struct ssc_device *ssc_request(unsigned int ssc_num)
}
if (!ssc_valid) {
- spin_unlock(_lock);
+ mutex_unlock(_lock);
pr_err("ssc: ssc%d platform device is missing\n", ssc_num);
return ERR_PTR(-ENODEV);
}
if (ssc->user) {
- spin_unlock(_lock);
+ mutex_unlock(_lock);
dev_dbg(>pdev->dev, "module busy\n");
return ERR_PTR(-EBUSY);
}
ssc->user++;
- spin_unlock(_lock);
+ mutex_unlock(_lock);
clk_prepare(ssc->clk);
@@ -67,14 +67,14 @@ void ssc_free(struct ssc_device *ssc)
{
bool disable_clk = true;
- spin_lock(_lock);
+ mutex_lock(_lock);
if (ssc->user)
ssc->user--;
else {
disable_clk = false;
dev_dbg(>pdev->dev, "device already free\n");
}
- spin_unlock(_lock);
+ mutex_unlock(_lock);
if (disable_clk)
clk_unprepare(ssc->clk);
@@ -246,9 +246,9 @@ static int ssc_probe(struct platform_device *pdev)
return -ENXIO;
}
- spin_lock(_lock);
+ mutex_lock(_lock);
list_add_tail(>list, _list);
- spin_unlock(_lock);
+ mutex_unlock(_lock);
platform_set_drvdata(pdev, ssc);
@@ -267,9 +267,9 @@ static int ssc_remove(struct platform_device *pdev)
ssc_sound_dai_remove(ssc);
- spin_lock(_lock);
+ mutex_lock(_lock);
list_del(>list);
- spin_unlock(_lock);
+ mutex_unlock(_lock);
return 0;
}
--
2.20.1
[PATCH V2] dt-bindings: thermal: Convert qoriq to json-schema
Convert the qoriq thermal binding to DT schema format using json-schema
Signed-off-by: Anson Huang
---
Changes since V1:
- add 'maxItems' for 'fsl,tmu-range' property;
- add 'minItems'/'maxItems' and items descriptions for
'fsl,tmu-calibration' property;
- remove description for common property '#thermal-sensor-cells';
- refine 'fsl,tmu-calibration' format in example.
---
.../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -
.../devicetree/bindings/thermal/qoriq-thermal.yaml | 112 +
2 files changed, 112 insertions(+), 71 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
deleted file mode 100644
index 28f2cba..000
--- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
-
-Required properties:
-- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The
- version of the device is determined by the TMU IP Block Revision
- Register (IPBRR0) at offset 0x0BF8.
- Table of correspondences between IPBRR0 values and example chips:
- Value Device
- -- -
- 0x01900102 T1040
-- reg : Address range of TMU registers.
-- interrupts : Contains the interrupt for TMU.
-- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by
- the SoC reference manual. The first cell is TTR0CR, the second is
- TTR1CR, etc.
-- fsl,tmu-calibration : A list of cell pairs containing temperature
- calibration data, as specified by the SoC reference manual.
- The first cell of each pair is the value to be written to TTCFGR,
- and the second is the value to be written to TSCFGR.
-- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring
- site ID, and represents the "n" in TRITSRn and TRATSRn.
-
-Optional property:
-- little-endian : If present, the TMU registers are little endian. If absent,
- the default is big endian.
-- clocks : the clock for clocking the TMU silicon.
-
-Example:
-
-tmu@f {
- compatible = "fsl,qoriq-tmu";
- reg = <0xf 0x1000>;
- interrupts = <18 2 0 0>;
- fsl,tmu-range = <0x000a 0x00090026 0x0008004a 0x0001006a>;
- fsl,tmu-calibration = <0x 0x0025
- 0x0001 0x0028
- 0x0002 0x002d
- 0x0003 0x0031
- 0x0004 0x0036
- 0x0005 0x003a
- 0x0006 0x0040
- 0x0007 0x0044
- 0x0008 0x004a
- 0x0009 0x004f
- 0x000a 0x0054
-
- 0x0001 0x000d
- 0x00010001 0x0013
- 0x00010002 0x0019
- 0x00010003 0x001f
- 0x00010004 0x0025
- 0x00010005 0x002d
- 0x00010006 0x0033
- 0x00010007 0x0043
- 0x00010008 0x004b
- 0x00010009 0x0053
-
- 0x0002 0x0010
- 0x00020001 0x0017
- 0x00020002 0x001f
- 0x00020003 0x0029
- 0x00020004 0x0031
- 0x00020005 0x003c
- 0x00020006 0x0042
- 0x00020007 0x004d
- 0x00020008 0x0056
-
- 0x0003 0x0012
- 0x00030001 0x001d>;
- #thermal-sensor-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
new file mode 100644
index 000..c5df999
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
+
+maintainers:
+ - Hongtao Jia
+
+properties:
+ compatible:
+description: |
+ The version of the device is determined by
Re: Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new
On Mon, 1 Jun 2020 at 13:37, Ben Skeggs wrote: > > On Mon, 1 Jun 2020 at 13:27, wrote: > > > > > > Hi Ben, > > > > > > When gk20a_clk_ctor() returns an error code, pointer "clk" > > > > should be released. It's the same when gm20b_clk_new() > > > > returns from elsewhere following this call. > > > This shouldn't be necessary. If a subdev constructor fails, and > > > returns a pointer, the core will call the destructor to clean things > > > up. > > > > > > > I'm not familiar with the behavior of the caller of gm20b_clk_new(). > > If the subdev constructor fails, the core will check the pointer > > (here is "pclk"), then it's ok and there is no bug (Do you mean > > this?). If the core executes error handling code only according to > > the error code, there may be a memory leak bug (the caller cannot > > know if -ENOMEM comes from the failure of kzalloc or gk20a_clk_ctor). > > If the core always calls the destructor as long as the constructor > > fails (even if the kzalloc fails), we may have a double free bug. > > > > Would you like to give a more detailed explanation about the behavior > > of the core? > If there's *any* error, it'll check the pointer, if it's non-NULL, > it'll call the destructor. If kzalloc() fails, the pointer will be > NULL, there's no double-free bug. *every* subdev is written this way > to avoid duplicating cleanup logic. Actually, gm20b_clk_new_speedo0() may have a bug here if kzalloc() fails as it doesn't overwrite the previous pointer from gm20b_clk_new(). That whole ctor() sequence is written a little strangely. > > Ben. > > > > Regards, > > Dinghao
Re: Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new
On Mon, 1 Jun 2020 at 13:27, wrote: > > > Hi Ben, > > > > When gk20a_clk_ctor() returns an error code, pointer "clk" > > > should be released. It's the same when gm20b_clk_new() > > > returns from elsewhere following this call. > > This shouldn't be necessary. If a subdev constructor fails, and > > returns a pointer, the core will call the destructor to clean things > > up. > > > > I'm not familiar with the behavior of the caller of gm20b_clk_new(). > If the subdev constructor fails, the core will check the pointer > (here is "pclk"), then it's ok and there is no bug (Do you mean > this?). If the core executes error handling code only according to > the error code, there may be a memory leak bug (the caller cannot > know if -ENOMEM comes from the failure of kzalloc or gk20a_clk_ctor). > If the core always calls the destructor as long as the constructor > fails (even if the kzalloc fails), we may have a double free bug. > > Would you like to give a more detailed explanation about the behavior > of the core? If there's *any* error, it'll check the pointer, if it's non-NULL, it'll call the destructor. If kzalloc() fails, the pointer will be NULL, there's no double-free bug. *every* subdev is written this way to avoid duplicating cleanup logic. Ben. > > Regards, > Dinghao
Re: [PATCH] opp: avoid uninitialized-variable use
On 30-05-20, 14:40, Arnd Bergmann wrote: > On Sat, May 30, 2020 at 11:21 AM Viresh Kumar wrote: > > On 29-05-20, 22:17, Arnd Bergmann wrote: > > > An uninitialized pointer is passed into another function but > > > --- a/drivers/opp/core.c > > > +++ b/drivers/opp/core.c > > > @@ -872,7 +872,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned > > > long target_freq) > > > goto put_opp_table; > > > } > > > > > > - ret = _set_opp_bw(opp_table, opp, dev, true); > > > + ret = _set_opp_bw(opp_table, NULL, dev, true); > > > if (ret) > > > return ret; > > > > > > > Not sure why people are still seeing this, I pushed a fix for this 2 > > days back. > > I was on next-20200528, which was the first version that was broken for me, > and I sent all my fixes after I had tested them. Since a lot of things > got broken > at once that day, it took me until the end of 20200529 to get it all tested > properly and then send them out. Okay, I asked as around 3-4 people have already sent out this patch to me :) -- viresh
Re: Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new
Hi Ben, > > When gk20a_clk_ctor() returns an error code, pointer "clk" > > should be released. It's the same when gm20b_clk_new() > > returns from elsewhere following this call. > This shouldn't be necessary. If a subdev constructor fails, and > returns a pointer, the core will call the destructor to clean things > up. > I'm not familiar with the behavior of the caller of gm20b_clk_new(). If the subdev constructor fails, the core will check the pointer (here is "pclk"), then it's ok and there is no bug (Do you mean this?). If the core executes error handling code only according to the error code, there may be a memory leak bug (the caller cannot know if -ENOMEM comes from the failure of kzalloc or gk20a_clk_ctor). If the core always calls the destructor as long as the constructor fails (even if the kzalloc fails), we may have a double free bug. Would you like to give a more detailed explanation about the behavior of the core? Regards, Dinghao
Re: [PATCH RFC] KVM: arm64: Sidestep stage2_unmap_vm() on vcpu reset when S2FWB is supported
Hi Alex,
On 2020/5/30 18:46, Alexandru Elisei wrote:
Hi,
On 4/20/20 5:10 PM, Alexandru Elisei wrote:
[ For some unknown reasons, I had missed your reply one month ago.
Sorry, I'm going to fix my email settings ... ]
Hi,
On 4/15/20 8:28 AM, Zenghui Yu wrote:
stage2_unmap_vm() was introduced to unmap user RAM region in the stage2
page table to make the caches coherent. E.g., a guest reboot with stage1
MMU disabled will access memory using non-cacheable attributes. If the
RAM and caches are not coherent at this stage, some evicted dirty cache
line may go and corrupt guest data in RAM.
Since ARMv8.4, S2FWB feature is mandatory and KVM will take advantage
of it to configure the stage2 page table and the attributes of memory
access. So we ensure that guests always access memory using cacheable
attributes and thus, the caches always be coherent.
So on CPUs that support S2FWB, we can safely reset the vcpu without a
heavy stage2 unmapping.
Cc: Marc Zyngier
Cc: Christoffer Dall
Cc: James Morse
Cc: Julien Thierry
Cc: Suzuki K Poulose
Signed-off-by: Zenghui Yu
---
If this is correct, there should be a great performance improvement on
a guest reboot (or reset) on systems support S2FWB. But I'm afraid that
I've missed some points here, so please comment!
The commit 957db105c997 ("arm/arm64: KVM: Introduce stage2_unmap_vm")
was merged about six years ago and I failed to track its histroy and
intention. Instead of a whole stage2 unmapping, something like
stage2_flush_vm() looks enough to me. But again, I'm unsure...
Thanks for having a look!
I had a chat with Christoffer about stage2_unmap_vm, and as I understood it, the
purpose was to make sure that any changes made by userspace were seen by the
guest
while the MMU is off. When a stage 2 fault happens, we do clean+inval on the
dcache, or inval on the icache if it was an exec fault. This means that whatever
the host userspace writes while the guest is shut down and is still in the
cache,
the guest will be able to read/execute.
This can be relevant if the guest relocates the kernel and overwrites the
original
image location, and userspace copies the original kernel image back in before
restarting the vm.
Yes, I-cache coherency is what I had missed! So without a S2 unmapping
on reboot, if there's any stale and "valid" cache line in the I-cache,
guest may fetch the wrong instructions directly from it, and bad things
will happen... (We will otherwise get a translation fault and a
permission fault and invalidate the I-cache as needed.)
virt/kvm/arm/arm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 48d0ec44ad77..e6378162cdef 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -983,8 +983,11 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu
*vcpu,
/*
* Ensure a rebooted VM will fault in RAM pages and detect if the
* guest MMU is turned off and flush the caches as needed.
+*
+* S2FWB enforces all memory accesses to RAM being cacheable, we
+* ensure that the cache is always coherent.
*/
- if (vcpu->arch.has_run_once)
+ if (vcpu->arch.has_run_once &&
!cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
I think userspace does not invalidate the icache when loading a new kernel
image,
and if the guest patched instructions, they could potentially still be in the
icache. Should the icache be invalidated if FWB is present?
I noticed that this was included in the current pull request and I remembered
that
I wasn't sure about this part. Did some more digging and it turns out that FWB
implies no cache maintenance needed for *data to instruction* coherence. From
ARM
DDI 0487F.b, page D5-2635:
"When ARMv8.4-S2FWB is implemented, the architecture requires that
CLIDR_EL1.{LOUU, LOIUS} are zero so that no levels of data cache need to be
cleaned in order to manage coherency with instruction fetches".
However, there's no mention that I found for instruction to data coherence,
meaning that the icache would still need to be invalidated on each vcpu in order
to prevent fetching of patched instructions from the icache. Am I missing
something?
Thanks for the head up and Marc's fix!
Thanks both,
Zenghui
[PATCH] shmem, memcg: enable memcg aware shrinker
Since v4.19 commit b0dedc49a2da ("mm/vmscan.c: iterate only over charged
shrinkers during memcg shrink_slab()") a memcg aware shrinker is only
called when the per-memcg per-node shrinker_map indicates that the
shrinker may have objects to release to the memcg and node.
shmem_unused_huge_count and shmem_unused_huge_scan support the per-tmpfs
shrinker which advertises per memcg and numa awareness. The shmem
shrinker releases memory by splitting hugepages that extend beyond
i_size.
Shmem does not currently set bits in shrinker_map. So, starting with
b0dedc49a2da, memcg reclaim avoids calling the shmem shrinker under
pressure. This leads to undeserved memcg OOM kills.
Example that reliably sees memcg OOM kill in unpatched kernel:
FS=/tmp/fs
CONTAINER=/cgroup/memory/tmpfs_shrinker
mkdir -p $FS
mount -t tmpfs -o huge=always nodev $FS
# Create 1000 MB container, which shouldn't suffer OOM.
mkdir $CONTAINER
echo 1000M > $CONTAINER/memory.limit_in_bytes
echo $BASHPID >> $CONTAINER/cgroup.procs
# Create 4000 files. Ideally each file uses 4k data page + a little
# metadata. Assume 8k total per-file, 32MB (4000*8k) should easily
# fit within container's 1000 MB. But if data pages use 2MB
# hugepages (due to aggressive huge=always) then files consume 8GB,
# which hits memcg 1000 MB limit.
for i in {1..4000}; do
echo . > $FS/$i
done
v5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg
aware") maintains the per-node per-memcg shrinker bitmap for THP
shrinker. But there's no such logic in shmem. Make shmem set the
per-memcg per-node shrinker bits when it modifies inodes to have
shrinkable pages.
Fixes: b0dedc49a2da ("mm/vmscan.c: iterate only over charged shrinkers during
memcg shrink_slab()")
Cc: # 4.19+
Signed-off-by: Greg Thelen
---
mm/shmem.c | 61 +++---
1 file changed, 35 insertions(+), 26 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index bd8840082c94..e11090f78cb5 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1002,6 +1002,33 @@ static int shmem_getattr(const struct path *path, struct
kstat *stat,
return 0;
}
+/*
+ * Expose inode and optional page to shrinker as having a possibly splittable
+ * hugepage that reaches beyond i_size.
+ */
+static void shmem_shrinker_add(struct shmem_sb_info *sbinfo,
+ struct inode *inode, struct page *page)
+{
+ struct shmem_inode_info *info = SHMEM_I(inode);
+
+ spin_lock(>shrinklist_lock);
+ /*
+* _careful to defend against unlocked access to ->shrink_list in
+* shmem_unused_huge_shrink()
+*/
+ if (list_empty_careful(>shrinklist)) {
+ list_add_tail(>shrinklist, >shrinklist);
+ sbinfo->shrinklist_len++;
+ }
+ spin_unlock(>shrinklist_lock);
+
+#ifdef CONFIG_MEMCG
+ if (page && PageTransHuge(page))
+ memcg_set_shrinker_bit(page->mem_cgroup, page_to_nid(page),
+ inode->i_sb->s_shrink.id);
+#endif
+}
+
static int shmem_setattr(struct dentry *dentry, struct iattr *attr)
{
struct inode *inode = d_inode(dentry);
@@ -1048,17 +1075,13 @@ static int shmem_setattr(struct dentry *dentry, struct
iattr *attr)
* to shrink under memory pressure.
*/
if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
- spin_lock(>shrinklist_lock);
- /*
-* _careful to defend against unlocked access to
-* ->shrink_list in shmem_unused_huge_shrink()
-*/
- if (list_empty_careful(>shrinklist)) {
- list_add_tail(>shrinklist,
- >shrinklist);
- sbinfo->shrinklist_len++;
- }
- spin_unlock(>shrinklist_lock);
+ struct page *page;
+
+ page = find_get_page(inode->i_mapping,
+ (newsize & HPAGE_PMD_MASK) >>
PAGE_SHIFT);
+ shmem_shrinker_add(sbinfo, inode, page);
+ if (page)
+ put_page(page);
}
}
}
@@ -1889,21 +1912,7 @@ static int shmem_getpage_gfp(struct inode *inode,
pgoff_t index,
if (PageTransHuge(page) &&
DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE) <
hindex + HPAGE_PMD_NR - 1) {
- /*
-* Part of the huge page is beyond i_size: subject
-* to shrink under memory pressure.
-*/
- spin_lock(>shrinklist_lock);
-
[PATCH RESEND] mm, swap: delete meaningless __add_to_swap_cache() declaration
From: Miaohe Lin
Since commit 8d93b41c09d1 ("mm: Convert add_to_swap_cache to XArray"),
__add_to_swap_cache and add_to_swap_cache are combined into one function.
There is no __add_to_swap_cache() anymore.
CC: Matthew Wilcox
Reviewed-by: "Huang, Ying"
Signed-off-by: Miaohe Lin
---
include/linux/swap.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index e1bbf7a16b27..d70e6017d835 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -408,7 +408,6 @@ extern unsigned long total_swapcache_pages(void);
extern void show_swap_cache_info(void);
extern int add_to_swap(struct page *page);
extern int add_to_swap_cache(struct page *, swp_entry_t, gfp_t);
-extern int __add_to_swap_cache(struct page *page, swp_entry_t entry);
extern void __delete_from_swap_cache(struct page *, swp_entry_t entry);
extern void delete_from_swap_cache(struct page *);
extern void free_page_and_swap_cache(struct page *);
--
2.19.1
[PATCH] soundwire: bus: clock_stop: don't deal with UNATTACHED Slave devices
We don't need to do anything for the slave if it is unattached during
clock stop prepare and exit sequences.
Signed-off-by: Bard Liao
---
drivers/soundwire/bus.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 2289c2ac8c5a..405335fb790a 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -863,13 +863,13 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
if (!slave->dev_num)
continue;
- /* Identify if Slave(s) are available on Bus */
- is_slave = true;
-
if (slave->status != SDW_SLAVE_ATTACHED &&
slave->status != SDW_SLAVE_ALERT)
continue;
+ /* Identify if Slave(s) are available on Bus */
+ is_slave = true;
+
slave_mode = sdw_get_clk_stop_mode(slave);
slave->curr_clk_stop_mode = slave_mode;
@@ -900,6 +900,10 @@ int sdw_bus_prep_clk_stop(struct sdw_bus *bus)
return ret;
}
+ /* Don't need to inform slaves if there is no slave attached */
+ if (!is_slave)
+ return ret;
+
/* Inform slaves that prep is done */
list_for_each_entry(slave, >slaves, node) {
if (!slave->dev_num)
@@ -985,13 +989,13 @@ int sdw_bus_exit_clk_stop(struct sdw_bus *bus)
if (!slave->dev_num)
continue;
- /* Identify if Slave(s) are available on Bus */
- is_slave = true;
-
if (slave->status != SDW_SLAVE_ATTACHED &&
slave->status != SDW_SLAVE_ALERT)
continue;
+ /* Identify if Slave(s) are available on Bus */
+ is_slave = true;
+
mode = slave->curr_clk_stop_mode;
if (mode == SDW_CLK_STOP_MODE1) {
@@ -1016,6 +1020,13 @@ int sdw_bus_exit_clk_stop(struct sdw_bus *bus)
if (is_slave && !simple_clk_stop)
sdw_bus_wait_for_clk_prep_deprep(bus, SDW_BROADCAST_DEV_NUM);
+ /*
+* Don't need to call slave callback function if there is no slave
+* attached
+*/
+ if (!is_slave)
+ return 0;
+
list_for_each_entry(slave, >slaves, node) {
if (!slave->dev_num)
continue;
--
2.17.1
Re: [PATCH V2] mm, memory_failure: don't send BUS_MCEERR_AO for action required error
On Sat, May 30, 2020 at 09:08:43AM +0200, Pankaj Gupta wrote:
> > Some processes dont't want to be killed early, but in "Action Required"
> > case, those also may be killed by BUS_MCEERR_AO when sharing memory
> > with other which is accessing the fail memory.
> > And sending SIGBUS with BUS_MCEERR_AO for action required error is
> > strange, so ignore the non-current processes here.
> >
> > Suggested-by: Naoya Horiguchi
> > Signed-off-by: Wetp Zhang
> > ---
> > mm/memory-failure.c | 15 +--
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index a96364be8ab4..dd3862fcf2e9 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -210,14 +210,17 @@ static int kill_proc(struct to_kill *tk, unsigned
> > long pfn, int flags)
> > {
> > struct task_struct *t = tk->tsk;
> > short addr_lsb = tk->size_shift;
> > - int ret;
> > + int ret = 0;
> >
> > - pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due to
> > hardware memory corruption\n",
> > - pfn, t->comm, t->pid);
> > + if ((t->mm == current->mm) || !(flags & MF_ACTION_REQUIRED))
> > + pr_err("Memory failure: %#lx: Sending SIGBUS to %s:%d due
> > to hardware memory corruption\n",
> > + pfn, t->comm, t->pid);
>
> Maybe we can generalize the message condition for better readability.
> Thought a bit but did not get any other idea.
This odd condition might imply that we could have better fix in
task_early_kill(), but that should come after fixing priority issue of
early-kill flag, so let's go with this fix for now.
> >
> > - if ((flags & MF_ACTION_REQUIRED) && t->mm == current->mm) {
> > - ret = force_sig_mceerr(BUS_MCEERR_AR, (void __user
> > *)tk->addr,
> > - addr_lsb);
> > + if (flags & MF_ACTION_REQUIRED) {
> > + if (t->mm == current->mm)
> > + ret = force_sig_mceerr(BUS_MCEERR_AR,
> > +(void __user *)tk->addr, addr_lsb);
> > + /* send no signal to non-current processes */
> > } else {
> > /*
> > * Don't use force here, it's convenient if the signal
> > --
>
> Looks good to me.
> Acked-by: Pankaj Gupta
Thanks!
Acked-by: Naoya Horiguchi
Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface
On Thu, 2020-05-28 at 15:12 +0200, Greg KH wrote: > So at runtime, after all is booted and up and going, you just ripped > cores out from under someone's feet? :) > > And the code really handles writing to that value while the module is > already loaded and up and running? At a quick glance, it didn't seem > like it would handle that very well as it only is checked at ne_init() > time. > > Or am I missing something? > > Anyway, yes, if you can dynamically do this at runtime, that's great, > but it feels ackward to me to rely on one configuration thing as a > module parameter, and everything else through the ioctl interface. > Unification would seem to be a good thing, right? I personally still prefer a sysfs file :) I really don't like module parameters as a way to do such things. Cheers, Ben.
Re: [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()
On Sun, May 31, 2020 at 12:43:11PM +0200, Geert Uytterhoeven wrote: > Hi Adrian, > > On Sun, May 31, 2020 at 11:59 AM John Paul Adrian Glaubitz > wrote: > > On 5/31/20 11:54 AM, John Paul Adrian Glaubitz wrote: > > > On 5/31/20 11:52 AM, Geert Uytterhoeven wrote: > > >> As this is the 64-bit variant, I think this single move should be > > >> replaced by a double move: > > >> > > >>"mov #0,%R1\n\t" \ > > >>"mov #0,%S1\n\t" \ > > >> > > >> Same for the big endian version below. > > >> > > >> Disclaimer: uncompiled, untested, no SH assembler expert. > > > > > > Right, this makes sense. I'll send a new patch shortly. > > > > Hmm, this change is not the case for __put_user_asm() vs. __put_user_u64(). > > But I have to admit, I don't know what the part below "3:\n\t" is for. > > It's part of the exception handling, in case the passed (userspace) pointer > points to an inaccessible address, and triggers an exception. > > For an invalid store, nothing is done, besides returning -EFAULT. > Hence there's no "mov #0, %1\n\t" in the put_user case. > For an invalid load, the data is replaced by zero, and -EFAULT is returned. > > > +__asm__ __volatile__( \ > > + "1:\n\t" \ > > + "mov.l %2,%R1\n\t" \ > > + "mov.l %T2,%S1\n\t" \ > > + "2:\n" \ > > (reordering the two sections for easier explanation) > > > + ".section __ex_table,\"a\"\n\t" \ > > + ".long 1b, 3b\n\t" \ > > In case an exception happens for the instruction at 1b, jump to 3b. > > Note that the m68k version has two entries here: one for each half of > the 64-bit access[*]. > I don't know if that is really needed (and thus SH needs it, too), or if > the exception code handles subsequent instructions automatically. Can I propose a different solution? For archs where there isn't actually any 64-bit load or store instruction, does it make sense to be writing asm just to do two 32-bit loads/stores, especially when this code is not in a hot path? What about just having the 64-bit versions call the corresponding 32-bit version twice? (Ideally this would even be arch-generic and could replace the m68k asm.) It would return EFAULT if either of the 32-bit calls did. Rich
[PATCH] f2fs: protect new segment allocation in expand_inode_data
From: Daeho Jeong Found a new segemnt allocation without f2fs_lock_op() in expand_inode_data(). So, when we do fallocate() for a pinned file and trigger checkpoint very frequently and simultaneously. F2FS gets stuck in the below code of do_checkpoint() forever. f2fs_sync_meta_pages(sbi, META, LONG_MAX, FS_CP_META_IO); /* Wait for all dirty meta pages to be submitted for IO */ <= if fallocate() here, f2fs_wait_on_all_pages(sbi, F2FS_DIRTY_META); <= it'll wait forever. Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu --- fs/f2fs/file.c | 4 1 file changed, 4 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index f7de2a1da528..14ace885baa9 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -1660,7 +1660,11 @@ static int expand_inode_data(struct inode *inode, loff_t offset, down_write(>pin_sem); map.m_seg_type = CURSEG_COLD_DATA_PINNED; + + f2fs_lock_op(sbi); f2fs_allocate_new_segments(sbi, CURSEG_COLD_DATA); + f2fs_unlock_op(sbi); + err = f2fs_map_blocks(inode, , 1, F2FS_GET_BLOCK_PRE_DIO); up_write(>pin_sem); -- 2.27.0.rc0.183.gde8f92d652-goog
Re: [PATCH v3 01/18] nitro_enclaves: Add ioctl interface definition
On Wed, 2020-05-27 at 09:49 +0100, Stefan Hajnoczi wrote: > > What about feature bits or a API version number field? If you add > features to the NE driver, how will userspace detect them? > > Even if you intend to always compile userspace against the exact kernel > headers that the program will run on, it can still be useful to have an > API version for informational purposes and to easily prevent user > errors (running a new userspace binary on an old kernel where the API is > different). > > Finally, reserved struct fields may come in handy in the future. That > way userspace and the kernel don't need to explicitly handle multiple > struct sizes. Beware, Greg might disagree :) That said, yes, at least a way to query the API version would be useful. Cheers, Ben.
Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface
On Wed, 2020-05-27 at 00:24 +0200, Greg KH wrote: > > Would you want random users to get the ability to hot unplug CPUs from your > > system? At unlimited quantity? I don't :). > > A random user, no, but one with admin rights, why not? They can do that > already today on your system, this isn't new. So I agree with you that a module parameter sucks. I disagree on the ioctl :) This is the kind of setup task that will probably end up being done by some shell script at boot time based on some config file. Being able to echo something in a sysfs file which will parse the standard-format CPU list using the existing kernel functions to turn that into a cpu_mask makes a lot more sense than having a binary interface via an ioctl which will require an extra userspace program for use by the admin for that one single task. So sysfs is my preference here. Another approach would be configfs, which would provide a more flexible interface to potentially create multiple "CPU sets" that could be given to different users or classes of users etc... but that might be pushing it, I don't know. Cheers, Ben.
Re: [PATCH v3 02/18] nitro_enclaves: Define the PCI device interface
On Wed, 2020-05-27 at 00:21 +0200, Greg KH wrote: > > There are a couple of data structures with more than one member and multiple > > field sizes. And for the ones that are not, gathered as feedback from > > previous rounds of review that should consider adding a "flags" field in > > there for further extensibility. > > Please do not do that in ioctls. Just create new calls instead of > trying to "extend" existing ones. It's always much easier. > > > I can modify to have "__packed" instead of the attribute callout. > > Make sure you even need that, as I don't think you do for structures > like the above one, right? Hrm, my impression (granted I only just started to look at this code) is that these are protocol messages with the PCI devices, not strictly just ioctl arguments (though they do get conveyed via such ioctls). Andra-Irina, did I get that right ? :-) That said, I still think that by carefully ordering the fields and using explicit padding, we can avoid the need of the packed attributed. Cheers, Ben.
[GIT PULL] pstore updates for v5.8-rc1
Hi Linus, Please pull these pstore updates for v5.8-rc1. This is a pretty big set of changes (relative to past pstore pulls), but they've lived in -next for a while. The biggest change here is the ability to support a block device as a pstore backend, which has been desired for a while. A lot of additional fixes and refactorings are also included, mostly in support of the new features. Thanks! -Kees The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136: Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/pstore-v5.8-rc1 for you to fetch changes up to 78c08247b9d3e03192f8b359aa079024e805a948: mtd: Support kmsg dumper based on pstore/blk (2020-05-31 19:49:01 -0700) Fixes and new features for pstore - refactor pstore locking for safer module unloading (Kees Cook) - remove orphaned records from pstorefs when backend unloaded (Kees Cook) - refactor dump_oops parameter into max_reason (Pavel Tatashin) - introduce pstore/zone for common code for contiguous storage (WeiXiong Liao) - introduce pstore/blk for block device backend (WeiXiong Liao) - introduce mtd backend (WeiXiong Liao) Kees Cook (22): pstore: Drop useless try_module_get() for backend pstore: Rename "pstore_lock" to "psinfo_lock" pstore: Convert "psinfo" locking to mutex pstore: Rename "allpstore" to "records_list" pstore: Convert "records_list" locking to mutex pstore: Add proper unregister lock checking pstore: Refactor pstorefs record list removal pstore: Add locking around superblock changes pstore: Do not leave timer disabled for next backend pstore: Remove filesystem records when backend is unregistered pstore: Make sure console capturing will restart pstore/platform: Switch pstore_info::name to const pstore/platform: Use backend name for console registration pstore/platform: Move module params after declarations pstore/ram: Adjust module param permissions to reflect reality pstore/ram: Refactor DT size parsing pstore/ram: Refactor ftrace buffer merging pstore/ftrace: Provide ftrace log merging routine printk: Collapse shutdown types into a single dump reason printk: Introduce kmsg_dump_reason_str() pstore/ram: Introduce max_reason and convert dump_oops pstore/blk: Introduce "best_effort" mode Pavel Tatashin (3): printk: honor the max_reason field in kmsg_dumper pstore/platform: Pass max_reason to kmesg dump ramoops: Add "max-reason" optional field to ramoops DT node WeiXiong Liao (10): pstore/zone: Introduce common layer to manage storage zones pstore/blk: Introduce backend for block devices pstore/zone,blk: Add support for pmsg frontend pstore/zone,blk: Add console frontend support pstore/zone,blk: Add ftrace frontend support Documentation: Add details for pstore/blk pstore/zone: Provide way to skip "broken" zone for MTD devices pstore/blk: Provide way to query pstore configuration pstore/blk: Support non-block storage devices mtd: Support kmsg dumper based on pstore/blk Documentation/admin-guide/pstore-blk.rst | 243 Documentation/admin-guide/ramoops.rst | 14 +- .../bindings/reserved-memory/ramoops.txt | 13 +- MAINTAINERS|1 + arch/powerpc/kernel/nvram_64.c |4 +- drivers/mtd/Kconfig| 10 + drivers/mtd/Makefile |1 + drivers/mtd/mtdpstore.c| 578 drivers/platform/chrome/chromeos_pstore.c |2 +- fs/pstore/Kconfig | 109 ++ fs/pstore/Makefile |6 + fs/pstore/blk.c| 517 +++ fs/pstore/ftrace.c | 54 + fs/pstore/inode.c | 129 +- fs/pstore/internal.h | 11 +- fs/pstore/platform.c | 117 +- fs/pstore/ram.c| 155 +-- fs/pstore/zone.c | 1465 include/linux/kmsg_dump.h | 12 +- include/linux/pstore.h |9 +- include/linux/pstore_blk.h | 118 ++ include/linux/pstore_ram.h |2 +- include/linux/pstore_zone.h| 60 + kernel/printk/printk.c | 32 +- kernel/reboot.c|6 +- tools/testing/selftests/pstore/pstore_tests|
Re: [PATCH v3 04/18] nitro_enclaves: Init PCI device driver
On Tue, 2020-05-26 at 21:35 +0300, Paraschiv, Andra-Irina wrote: > This was needed to have an identifier for the overall NE logic - PCI > dev, ioctl and misc dev. > > The ioctl and misc dev logic has pr_* logs, but I can update them to > dev_* with misc dev, then remove this prefix. Or #define pr_fmt, but dev_ is better. Cheers, Ben.
Re: [GIT PULL] sh: remove sh5 support
On Sun, May 31, 2020 at 10:03:13AM +0200, John Paul Adrian Glaubitz wrote: > On 5/31/20 5:20 AM, Rob Landley wrote: > > On 5/30/20 3:08 AM, John Paul Adrian Glaubitz wrote: > >> On 5/29/20 7:53 PM, Rich Felker wrote: > >>> Frustratingly, I _still_ don't have an official tree on kernel.org for > >>> the purpose of being the canonical place for linux-next to pull from, > >>> due to policies around pgp keys and nobody following up on signing > >>> mine. This is all really silly since there are ridiculously many > >>> independent channels I could cryptographically validate identity > >>> through with vanishing probability that they're all compromised. For > >>> the time being I'll reactivate my repo on git.musl-libc.org. > >> > >> May I suggest to pick up these patches, for example? There might be > >> more I missed, but getting these merged should already help a lot with > >> the clean-up of arch/sh. > > > > Does that include the 2 fixes to build with current binutils I made puppy > > eyes > > about last -rc7 (in march)? > > > > https://marc.info/?l=linux-sh=158544749818664=2 > Yes, listed as "[PATCH 1/2] arch/sh: vmlinux.scr". > > @Rich: Do you think you can merge all those fixes in your local tree within >the next days and send a PR to Linus? > > Otherwise, I can volunteer to become a third maintainer for arch/sh as I have > the hardware for testing and can accept patches and send PRs. > > We shouldn't let contributors to arch/sh wait for too long. Yes, I'll try to get my tree ready for next/PR use tomorrow. Rich
Re: [PATCH v3 02/18] nitro_enclaves: Define the PCI device interface
On Tue, 2020-05-26 at 20:01 +0300, Paraschiv, Andra-Irina wrote:
>
> On 26/05/2020 09:44, Greg KH wrote:
> > On Tue, May 26, 2020 at 01:13:18AM +0300, Andra Paraschiv wrote:
> > > +struct enclave_get_slot_req {
> > > + /* Context ID (CID) for the enclave vsock device. */
> > > + u64 enclave_cid;
> > > +} __attribute__ ((__packed__));
> >
> > Can you really "pack" a single member structure?
> >
> > Anyway, we have better ways to specify this instead of the "raw"
> > __attribute__ option. But first see if you really need any of
> > these, at
> > first glance, I do not think you do at all, and they can all be
> > removed.
>
> There are a couple of data structures with more than one member and
> multiple field sizes. And for the ones that are not, gathered as
> feedback from previous rounds of review that should consider adding
> a
> "flags" field in there for further extensibility.
>
> I can modify to have "__packed" instead of the attribute callout.
I tend to prefer designing the protocol so that all the fields are
naturally aligned, which should avoid the need for the attribute. Is
it possible in this case ?
Cheers,
Ben.
Re: [PATCH v3 07/18] nitro_enclaves: Init misc device providing the ioctl interface
On Tue, 2020-05-26 at 14:44 +0200, Alexander Graf wrote: > So I really don't think an ioctl would be a great user experience. Same > for a sysfs file - although that's probably slightly better than the ioctl. What would be wrong with a sysfs file ? Another way to approach that makes sense from a kernel perspective is to have the user first offline the CPUs, then "donate" them to the driver via a sysfs file. > Other options I can think of: > >* sysctl (for modules?) Why would that be any good ? If anything sysctl's are even more awkward in my book :) >* module parameter (as implemented here) >* proc file (deprecated FWIW) Yeah no. > The key is the tenant split: Admin sets the pool up, user consumes. This > setup should happen (early) on boot, so that system services can spawn > enclaves. Right and you can have some init script or udev rule that sets that up from a sys admin produced config file at boot upon detection of the enclave PCI device for example. > > module parameters are a major pain, you know this :) > > I think in this case it's the least painful option ;). But I'm really > happy to hear about an actually good alternative to it. Right now, I > just can't think of any. Cheers, Ben.
