Re: [PATCH v5 0/2] Add device driver for APU2/APU3 GPIOs
Hello Andy > Btw, is the statement in above email still actual? "...I can fix > required things." Yes i will fix your hints tomorrow and send a v6 of my patchset. Thank you for your hints and time It would be nice if you could fix ACPI problemmatik. I would like to see the ACPI dump for that... See https://github.com/openwrt/openwrt/pull/1232#issuecomment-443224576 In this comment Michał Żygowski appended to this thread the missing files you want to have. Regards Flo
Re: [PATCH v5 0/2] Add device driver for APU2/APU3 GPIOs
Hello Andy > Btw, is the statement in above email still actual? "...I can fix > required things." Yes i will fix your hints tomorrow and send a v6 of my patchset. Thank you for your hints and time It would be nice if you could fix ACPI problemmatik. I would like to see the ACPI dump for that... See https://github.com/openwrt/openwrt/pull/1232#issuecomment-443224576 In this comment Michał Żygowski appended to this thread the missing files you want to have. Regards Flo
Re: [PATCH v2 06/17] Platform: OLPC: Add XO-1.75 EC driver
On Mon, Dec 3, 2018 at 1:13 AM Darren Hart wrote: > On Fri, Nov 16, 2018 at 05:23:52PM +0100, Lubomir Rintel wrote: > > It's based off the driver from the OLPC kernel sources. Somewhat > > modernized and cleaned up, for better or worse. > > > > Modified to plug into the olpc-ec driver infrastructure (so that battery > > interface and debugfs could be reused) and the SPI slave framework. > > - Count the terminating NUL in LOG_BUF_SIZE > > - Make olpc_xo175_ec_is_valid_cmd() return -EINVAL instead of -1 > > on error > > - Spell keyboard/touchpad in full for CHAN_KEYBOARD/TOUCHPAD messages > > - Use a #define for PM wakeup processing time > > - Log a message on unknown event > > - Escape logging payload with %*pE > > - Replace an open-coded min() > > - Correct an error code on short read > > - replaced PM callback #ifdefs with __maybe_unusedm SET_RUNTIME_PM_OPS > > and SET_NOIRQ_SYSTEM_SLEEP_PM_OPS > > - dev_get_drvdata() instead of a round-trip through platform device > > - s/unsigned char x/u8 x/ in olpc_xo175_ec_resume() > > - Use GENMASK() instead of 0x for the event mask > > - Replace cmd tx/resp rx buffers with structures > > - Turned suspend hint arguments into a struct, and tidied up the comment > > Just from these comments, each of these could be a separate patch. You > can group related things together, or those that change the same line or > function for example. Order them with cleanups / non-functional-changes > first, followed by functional changes. > > > > > Basically all of the above is based on the review by Andy Shevchenko. > > Andy, what was your intent for Lubomir here? From the above, this looks > like it should be several patches to me. This is a new module, I don't see why it can't be one patch. For the existing code I agree with you. -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 06/17] Platform: OLPC: Add XO-1.75 EC driver
On Mon, Dec 3, 2018 at 1:13 AM Darren Hart wrote: > On Fri, Nov 16, 2018 at 05:23:52PM +0100, Lubomir Rintel wrote: > > It's based off the driver from the OLPC kernel sources. Somewhat > > modernized and cleaned up, for better or worse. > > > > Modified to plug into the olpc-ec driver infrastructure (so that battery > > interface and debugfs could be reused) and the SPI slave framework. > > - Count the terminating NUL in LOG_BUF_SIZE > > - Make olpc_xo175_ec_is_valid_cmd() return -EINVAL instead of -1 > > on error > > - Spell keyboard/touchpad in full for CHAN_KEYBOARD/TOUCHPAD messages > > - Use a #define for PM wakeup processing time > > - Log a message on unknown event > > - Escape logging payload with %*pE > > - Replace an open-coded min() > > - Correct an error code on short read > > - replaced PM callback #ifdefs with __maybe_unusedm SET_RUNTIME_PM_OPS > > and SET_NOIRQ_SYSTEM_SLEEP_PM_OPS > > - dev_get_drvdata() instead of a round-trip through platform device > > - s/unsigned char x/u8 x/ in olpc_xo175_ec_resume() > > - Use GENMASK() instead of 0x for the event mask > > - Replace cmd tx/resp rx buffers with structures > > - Turned suspend hint arguments into a struct, and tidied up the comment > > Just from these comments, each of these could be a separate patch. You > can group related things together, or those that change the same line or > function for example. Order them with cleanups / non-functional-changes > first, followed by functional changes. > > > > > Basically all of the above is based on the review by Andy Shevchenko. > > Andy, what was your intent for Lubomir here? From the above, this looks > like it should be several patches to me. This is a new module, I don't see why it can't be one patch. For the existing code I agree with you. -- With Best Regards, Andy Shevchenko
[PATCH 4/7] microblaze: fix multiple bugs in arch/microblaze/boot/Makefile
This Makefile is wrong in multiple ways.
The first issue is the breakage of 'linux.bin.ub' target since commit
ece97f3a5fb5 ("microblaze: Fix simpleImage format generation")
because the addition of UIMAGE_{IN,OUT} obviously affected it.
make ARCH=microblaze CROSS_COMPILE=microblaze-linux- linux.bin.ub
[ snip ]
OBJCOPY arch/microblaze/boot/linux.bin
UIMAGE arch/microblaze/boot/linux.bin.ub.ub
/usr/bin/mkimage: Can't open arch/microblaze/boot/linux.bin.ub: No such file or
directory
make[1]: *** [arch/microblaze/boot/Makefile;14:
arch/microblaze/boot/linux.bin.ub] Error 1
make: *** [arch/microblaze/Makefile;83: linux.bin.ub] Error 2
The second issue is the use of the "if_changed" multiple times for
the same target.
As commit 92a4728608a8 ("x86/boot: Fix if_changed build flip/flop bug")
pointed out, this never works properly. Moreover, generating multiple
images as a side-effect is extremely confusing and wrong.
As far as I understood, "simpleImage." works like a phony target
to generate the following four images.
- arch/microblaze/boot/simpleImage.:
identical to arch/microblaze/boot/linux.bin
- arch/microblaze/boot/simpleImage..unstrip:
identical to vmlinux
- arch/microblaze/boot/simpleImage..ub:
identical to arch/microblaze/boot/linux.bin.ub
- arch/microblaze/boot/simpleImage..strip:
stripped vmlinux
The first three are just aliases of other images. Separate the recipe
for each image.
Signed-off-by: Masahiro Yamada
---
arch/microblaze/Makefile | 2 +-
arch/microblaze/boot/Makefile | 27 ---
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
index cfd7bfca..c5d5b0e 100644
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -84,7 +84,7 @@ linux.bin linux.bin.gz linux.bin.ub: vmlinux
@echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')'
simpleImage.%: vmlinux
- $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
+ $(Q)$(MAKE) $(build)=$(boot) simple_images
@echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')'
define archhelp
diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index c2579a7..f12a9d7 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -3,7 +3,7 @@
# arch/microblaze/boot/Makefile
#
-targets := linux.bin linux.bin.gz linux.bin.ub simpleImage.%
+targets := linux.bin linux.bin.gz linux.bin.ub simpleImage.*.strip
OBJCOPYFLAGS := -R .note -R .comment -R .note.gnu.build-id -O binary
@@ -16,21 +16,26 @@ $(obj)/linux.bin.ub: $(obj)/linux.bin FORCE
$(obj)/linux.bin.gz: $(obj)/linux.bin FORCE
$(call if_changed,gzip)
-quiet_cmd_cp = CP $< $@$2
- cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false)
-
quiet_cmd_strip = STRIP $< $@$2
cmd_strip = $(STRIP) -K microblaze_start -K _end -K __log_buf \
-K _fdt_start $< -o $@$2
UIMAGE_LOADADDR = $(CONFIG_KERNEL_BASE_ADDR)
-UIMAGE_IN = $@
-UIMAGE_OUT = $@.ub
-$(obj)/simpleImage.%: vmlinux FORCE
- $(call if_changed,cp,.unstrip)
- $(call if_changed,objcopy)
- $(call if_changed,uimage)
- $(call if_changed,strip,.strip)
+PHONY += simple_images
+simple_images: $(addprefix $(obj)/simpleImage., $(DTB) $(DTB).ub
$(DTB).unstrip $(DTB).strip)
+ @:
+
+$(obj)/simpleImage.$(DTB): $(obj)/linux.bin
+ $(call cmd,shipped)
+
+$(obj)/simpleImage.$(DTB).ub: $(obj)/linux.bin.ub
+ $(call cmd,shipped)
+
+$(obj)/simpleImage.$(DTB).unstrip: vmlinux
+ $(call cmd,shipped)
+
+$(obj)/simpleImage.$(DTB).strip: vmlinux FORCE
+ $(call if_changed,strip)
clean-files += simpleImage.*
--
2.7.4
[PATCH 4/7] microblaze: fix multiple bugs in arch/microblaze/boot/Makefile
This Makefile is wrong in multiple ways.
The first issue is the breakage of 'linux.bin.ub' target since commit
ece97f3a5fb5 ("microblaze: Fix simpleImage format generation")
because the addition of UIMAGE_{IN,OUT} obviously affected it.
make ARCH=microblaze CROSS_COMPILE=microblaze-linux- linux.bin.ub
[ snip ]
OBJCOPY arch/microblaze/boot/linux.bin
UIMAGE arch/microblaze/boot/linux.bin.ub.ub
/usr/bin/mkimage: Can't open arch/microblaze/boot/linux.bin.ub: No such file or
directory
make[1]: *** [arch/microblaze/boot/Makefile;14:
arch/microblaze/boot/linux.bin.ub] Error 1
make: *** [arch/microblaze/Makefile;83: linux.bin.ub] Error 2
The second issue is the use of the "if_changed" multiple times for
the same target.
As commit 92a4728608a8 ("x86/boot: Fix if_changed build flip/flop bug")
pointed out, this never works properly. Moreover, generating multiple
images as a side-effect is extremely confusing and wrong.
As far as I understood, "simpleImage." works like a phony target
to generate the following four images.
- arch/microblaze/boot/simpleImage.:
identical to arch/microblaze/boot/linux.bin
- arch/microblaze/boot/simpleImage..unstrip:
identical to vmlinux
- arch/microblaze/boot/simpleImage..ub:
identical to arch/microblaze/boot/linux.bin.ub
- arch/microblaze/boot/simpleImage..strip:
stripped vmlinux
The first three are just aliases of other images. Separate the recipe
for each image.
Signed-off-by: Masahiro Yamada
---
arch/microblaze/Makefile | 2 +-
arch/microblaze/boot/Makefile | 27 ---
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
index cfd7bfca..c5d5b0e 100644
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -84,7 +84,7 @@ linux.bin linux.bin.gz linux.bin.ub: vmlinux
@echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')'
simpleImage.%: vmlinux
- $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
+ $(Q)$(MAKE) $(build)=$(boot) simple_images
@echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')'
define archhelp
diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index c2579a7..f12a9d7 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -3,7 +3,7 @@
# arch/microblaze/boot/Makefile
#
-targets := linux.bin linux.bin.gz linux.bin.ub simpleImage.%
+targets := linux.bin linux.bin.gz linux.bin.ub simpleImage.*.strip
OBJCOPYFLAGS := -R .note -R .comment -R .note.gnu.build-id -O binary
@@ -16,21 +16,26 @@ $(obj)/linux.bin.ub: $(obj)/linux.bin FORCE
$(obj)/linux.bin.gz: $(obj)/linux.bin FORCE
$(call if_changed,gzip)
-quiet_cmd_cp = CP $< $@$2
- cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false)
-
quiet_cmd_strip = STRIP $< $@$2
cmd_strip = $(STRIP) -K microblaze_start -K _end -K __log_buf \
-K _fdt_start $< -o $@$2
UIMAGE_LOADADDR = $(CONFIG_KERNEL_BASE_ADDR)
-UIMAGE_IN = $@
-UIMAGE_OUT = $@.ub
-$(obj)/simpleImage.%: vmlinux FORCE
- $(call if_changed,cp,.unstrip)
- $(call if_changed,objcopy)
- $(call if_changed,uimage)
- $(call if_changed,strip,.strip)
+PHONY += simple_images
+simple_images: $(addprefix $(obj)/simpleImage., $(DTB) $(DTB).ub
$(DTB).unstrip $(DTB).strip)
+ @:
+
+$(obj)/simpleImage.$(DTB): $(obj)/linux.bin
+ $(call cmd,shipped)
+
+$(obj)/simpleImage.$(DTB).ub: $(obj)/linux.bin.ub
+ $(call cmd,shipped)
+
+$(obj)/simpleImage.$(DTB).unstrip: vmlinux
+ $(call cmd,shipped)
+
+$(obj)/simpleImage.$(DTB).strip: vmlinux FORCE
+ $(call if_changed,strip)
clean-files += simpleImage.*
--
2.7.4
[PATCH 1/7] microblaze: fix cleaning of boot images
The simpleImage. target generates the following files: arch/microblaze/boot/simpleImage. arch/microblaze/boot/simpleImage..ub arch/microblaze/boot/simpleImage..strip arch/microblaze/boot/simpleImage..unstrip However, "make ARCH=microblaze clean" only cleans up the unstrip image. Fix the clean-files to take care of all the four. Adding linux.bin.ub to clean-files is redundant because it is already added into "targets". Signed-off-by: Masahiro Yamada --- arch/microblaze/boot/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile index 600e5a1..e8684a2 100644 --- a/arch/microblaze/boot/Makefile +++ b/arch/microblaze/boot/Makefile @@ -37,4 +37,4 @@ $(obj)/simpleImage.%: vmlinux FORCE $(call if_changed,strip,.strip) @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')' -clean-files += simpleImage.*.unstrip linux.bin.ub +clean-files += simpleImage.* -- 2.7.4
Re: jffs2: Fix use of uninitialized delayed_work, lockdep breakage
On Fri, 2018-10-19 at 08:30:20 UTC, Daniel Santos wrote:
> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
> is defined then a write buffer is available and has been initialized.
> However, this does is not the case when the mtd device has no
> out-of-band buffer:
>
> int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
> {
> if (!c->mtd->oobsize)
> return 0;
> ...
>
> The resulting call to cancel_delayed_work_sync passing a uninitialized
> (but zeroed) delayed_work struct forces lockdep to become disabled.
>
> [ 90.050639] overlayfs: upper fs does not support tmpfile.
> [ 90.652264] INFO: trying to register non-static key.
> [ 90.662171] the code is fine but needs lockdep annotation.
> [ 90.673090] turning off the locking correctness validator.
> [ 90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
> [ 90.696672] Stack : 80d8f6a2 0038 805f 80444600
> 8fe364f4 805dfbe7
> [ 90.713349] 80563a30 06e2 8068370c 0001 0001
> 8e2fdc48
> [ 90.730020] 80d9 0106
> 6465746e 312e3420
> [ 90.746690] 6b636f6c 03bf f800 20676e69 8000
> 8e2c2a90
> [ 90.763362] 80d9 0001 8e2c2a90 0003 80260dc0
> 08052098 8068
> [ 90.780033] ...
> [ 90.784902] Call Trace:
> [ 90.789793] [<8000f0d8>] show_stack+0xb8/0x148
> [ 90.798659] [<8005a000>] register_lock_class+0x270/0x55c
> [ 90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
> [ 90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
> [ 90.828345] [<8003f27c>] flush_work+0x200/0x24c
> [ 90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
> [ 90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
> [ 90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
> [ 90.866729] [<80158fc4>] sys_sync+0x44/0x9c
> [ 90.875067] [<80014424>] syscall_common+0x34/0x58
>
> Signed-off-by: Daniel Santos
> Reviewed-by: Hou Tao
Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks.
Boris
[PATCH 6/7] microblaze: fix race condition in building boot images
I fixed a race condition in the parallel building of ARM in commit
3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
generate invalid images").
I see the same problem for MicroBlaze too.
"make -j ARCH=microblaze all linux.bin.ub" results in a broken build
since two threads descend into arch/microblaze/boot simultaneously.
Add proper dependencies to avoid it.
Signed-off-by: Masahiro Yamada
---
arch/microblaze/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
index 7a5df02..544796d 100644
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -79,13 +79,15 @@ all: linux.bin
archclean:
$(Q)$(MAKE) $(clean)=$(boot)
+linux.bin.ub linux.bin.gz: linux.bin
+
PHONY += linux.bin linux.bin.gz linux.bin.ub
linux.bin linux.bin.gz linux.bin.ub: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
@echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')'
PHONY += simpleImage.$(DTB)
-simpleImage.$(DTB): vmlinux
+simpleImage.$(DTB): linux.bin.ub
$(Q)$(MAKE) $(build)=$(boot) simple_images
@echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')'
--
2.7.4
[PATCH 7/7] microblaze: remove the unneeded code just in case file copy fails
I guess
|| (rm -f $@ && echo false)
... should be
|| (rm -f $@ && false)
since printing the string "false" on the console has no point.
Moreover, no Makefile needs to delete a target on error explicitly
since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
target").
Reuse equivalent cmd_shipped from scripts/Makefile.lib.
Signed-off-by: Masahiro Yamada
---
arch/microblaze/boot/dts/Makefile | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/microblaze/boot/dts/Makefile
b/arch/microblaze/boot/dts/Makefile
index c7324e7..ef00dd3 100644
--- a/arch/microblaze/boot/dts/Makefile
+++ b/arch/microblaze/boot/dts/Makefile
@@ -12,12 +12,9 @@ $(obj)/linked_dtb.o: $(obj)/system.dtb
# Generate system.dtb from $(DTB).dtb
ifneq ($(DTB),system)
$(obj)/system.dtb: $(obj)/$(DTB).dtb
- $(call if_changed,cp)
+ $(call if_changed,shipped)
endif
endif
-quiet_cmd_cp = CP $< $@$2
- cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false)
-
# Rule to build device tree blobs
DTC_FLAGS := -p 1024
--
2.7.4
[PATCH 3/7] microblaze: move "... is ready" message to arch/microblaze/Makefile
To prepare for more fixes, move this to arch/microblaze/Makefile. Otherwise, the same "... is ready" would be printed multiple times. (Another solution would be, to remove these messages entirely unless people persist with them.) Signed-off-by: Masahiro Yamada --- arch/microblaze/Makefile | 2 ++ arch/microblaze/boot/Makefile | 4 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile index 97e1384..cfd7bfca 100644 --- a/arch/microblaze/Makefile +++ b/arch/microblaze/Makefile @@ -81,9 +81,11 @@ archclean: linux.bin linux.bin.gz linux.bin.ub: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ + @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')' simpleImage.%: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ + @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')' define archhelp echo '* linux.bin- Create raw binary' diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile index e8684a2..c2579a7 100644 --- a/arch/microblaze/boot/Makefile +++ b/arch/microblaze/boot/Makefile @@ -9,15 +9,12 @@ OBJCOPYFLAGS := -R .note -R .comment -R .note.gnu.build-id -O binary $(obj)/linux.bin: vmlinux FORCE $(call if_changed,objcopy) - @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' $(obj)/linux.bin.ub: $(obj)/linux.bin FORCE $(call if_changed,uimage) - @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' $(obj)/linux.bin.gz: $(obj)/linux.bin FORCE $(call if_changed,gzip) - @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' quiet_cmd_cp = CP $< $@$2 cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false) @@ -35,6 +32,5 @@ $(obj)/simpleImage.%: vmlinux FORCE $(call if_changed,objcopy) $(call if_changed,uimage) $(call if_changed,strip,.strip) - @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')' clean-files += simpleImage.* -- 2.7.4
Re: mtd: nftl: clean up indentation, remove extraneous tabs
On Sun, 2018-11-18 at 16:36:56 UTC, Colin King wrote: > From: Colin Ian King > > The hunk of code is indented too much by one level, fix this by > removing the extraneous tabs. Also terminate block comment using > the recommended coding style to clean up checkpatch warning. > > Signed-off-by: Colin Ian King Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks. Boris
[PATCH 5/7] microblaze: add linux.bin* and simpleImage.* to PHONY
linux.bin, linux.bin.gz, and linux.bin.ub are phony targets to generate a corresponding image under arch/microblaze/boot/. simpleImage.% also works like a PHONY target, but a pattern that contains '%' cannot be a PHONY target. I renamed it to equivalent simpleImage.$(DTB). Signed-off-by: Masahiro Yamada --- arch/microblaze/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile index c5d5b0e..7a5df02 100644 --- a/arch/microblaze/Makefile +++ b/arch/microblaze/Makefile @@ -79,11 +79,13 @@ all: linux.bin archclean: $(Q)$(MAKE) $(clean)=$(boot) +PHONY += linux.bin linux.bin.gz linux.bin.ub linux.bin linux.bin.gz linux.bin.ub: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')' -simpleImage.%: vmlinux +PHONY += simpleImage.$(DTB) +simpleImage.$(DTB): vmlinux $(Q)$(MAKE) $(build)=$(boot) simple_images @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')' -- 2.7.4
[PATCH 1/7] microblaze: fix cleaning of boot images
The simpleImage. target generates the following files: arch/microblaze/boot/simpleImage. arch/microblaze/boot/simpleImage..ub arch/microblaze/boot/simpleImage..strip arch/microblaze/boot/simpleImage..unstrip However, "make ARCH=microblaze clean" only cleans up the unstrip image. Fix the clean-files to take care of all the four. Adding linux.bin.ub to clean-files is redundant because it is already added into "targets". Signed-off-by: Masahiro Yamada --- arch/microblaze/boot/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile index 600e5a1..e8684a2 100644 --- a/arch/microblaze/boot/Makefile +++ b/arch/microblaze/boot/Makefile @@ -37,4 +37,4 @@ $(obj)/simpleImage.%: vmlinux FORCE $(call if_changed,strip,.strip) @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')' -clean-files += simpleImage.*.unstrip linux.bin.ub +clean-files += simpleImage.* -- 2.7.4
Re: jffs2: Fix use of uninitialized delayed_work, lockdep breakage
On Fri, 2018-10-19 at 08:30:20 UTC, Daniel Santos wrote:
> jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
> is defined then a write buffer is available and has been initialized.
> However, this does is not the case when the mtd device has no
> out-of-band buffer:
>
> int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
> {
> if (!c->mtd->oobsize)
> return 0;
> ...
>
> The resulting call to cancel_delayed_work_sync passing a uninitialized
> (but zeroed) delayed_work struct forces lockdep to become disabled.
>
> [ 90.050639] overlayfs: upper fs does not support tmpfile.
> [ 90.652264] INFO: trying to register non-static key.
> [ 90.662171] the code is fine but needs lockdep annotation.
> [ 90.673090] turning off the locking correctness validator.
> [ 90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
> [ 90.696672] Stack : 80d8f6a2 0038 805f 80444600
> 8fe364f4 805dfbe7
> [ 90.713349] 80563a30 06e2 8068370c 0001 0001
> 8e2fdc48
> [ 90.730020] 80d9 0106
> 6465746e 312e3420
> [ 90.746690] 6b636f6c 03bf f800 20676e69 8000
> 8e2c2a90
> [ 90.763362] 80d9 0001 8e2c2a90 0003 80260dc0
> 08052098 8068
> [ 90.780033] ...
> [ 90.784902] Call Trace:
> [ 90.789793] [<8000f0d8>] show_stack+0xb8/0x148
> [ 90.798659] [<8005a000>] register_lock_class+0x270/0x55c
> [ 90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
> [ 90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
> [ 90.828345] [<8003f27c>] flush_work+0x200/0x24c
> [ 90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
> [ 90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
> [ 90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
> [ 90.866729] [<80158fc4>] sys_sync+0x44/0x9c
> [ 90.875067] [<80014424>] syscall_common+0x34/0x58
>
> Signed-off-by: Daniel Santos
> Reviewed-by: Hou Tao
Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks.
Boris
[PATCH 6/7] microblaze: fix race condition in building boot images
I fixed a race condition in the parallel building of ARM in commit
3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
generate invalid images").
I see the same problem for MicroBlaze too.
"make -j ARCH=microblaze all linux.bin.ub" results in a broken build
since two threads descend into arch/microblaze/boot simultaneously.
Add proper dependencies to avoid it.
Signed-off-by: Masahiro Yamada
---
arch/microblaze/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
index 7a5df02..544796d 100644
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -79,13 +79,15 @@ all: linux.bin
archclean:
$(Q)$(MAKE) $(clean)=$(boot)
+linux.bin.ub linux.bin.gz: linux.bin
+
PHONY += linux.bin linux.bin.gz linux.bin.ub
linux.bin linux.bin.gz linux.bin.ub: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
@echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')'
PHONY += simpleImage.$(DTB)
-simpleImage.$(DTB): vmlinux
+simpleImage.$(DTB): linux.bin.ub
$(Q)$(MAKE) $(build)=$(boot) simple_images
@echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')'
--
2.7.4
[PATCH 7/7] microblaze: remove the unneeded code just in case file copy fails
I guess
|| (rm -f $@ && echo false)
... should be
|| (rm -f $@ && false)
since printing the string "false" on the console has no point.
Moreover, no Makefile needs to delete a target on error explicitly
since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
target").
Reuse equivalent cmd_shipped from scripts/Makefile.lib.
Signed-off-by: Masahiro Yamada
---
arch/microblaze/boot/dts/Makefile | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/microblaze/boot/dts/Makefile
b/arch/microblaze/boot/dts/Makefile
index c7324e7..ef00dd3 100644
--- a/arch/microblaze/boot/dts/Makefile
+++ b/arch/microblaze/boot/dts/Makefile
@@ -12,12 +12,9 @@ $(obj)/linked_dtb.o: $(obj)/system.dtb
# Generate system.dtb from $(DTB).dtb
ifneq ($(DTB),system)
$(obj)/system.dtb: $(obj)/$(DTB).dtb
- $(call if_changed,cp)
+ $(call if_changed,shipped)
endif
endif
-quiet_cmd_cp = CP $< $@$2
- cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false)
-
# Rule to build device tree blobs
DTC_FLAGS := -p 1024
--
2.7.4
[PATCH 3/7] microblaze: move "... is ready" message to arch/microblaze/Makefile
To prepare for more fixes, move this to arch/microblaze/Makefile. Otherwise, the same "... is ready" would be printed multiple times. (Another solution would be, to remove these messages entirely unless people persist with them.) Signed-off-by: Masahiro Yamada --- arch/microblaze/Makefile | 2 ++ arch/microblaze/boot/Makefile | 4 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile index 97e1384..cfd7bfca 100644 --- a/arch/microblaze/Makefile +++ b/arch/microblaze/Makefile @@ -81,9 +81,11 @@ archclean: linux.bin linux.bin.gz linux.bin.ub: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ + @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')' simpleImage.%: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ + @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')' define archhelp echo '* linux.bin- Create raw binary' diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile index e8684a2..c2579a7 100644 --- a/arch/microblaze/boot/Makefile +++ b/arch/microblaze/boot/Makefile @@ -9,15 +9,12 @@ OBJCOPYFLAGS := -R .note -R .comment -R .note.gnu.build-id -O binary $(obj)/linux.bin: vmlinux FORCE $(call if_changed,objcopy) - @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' $(obj)/linux.bin.ub: $(obj)/linux.bin FORCE $(call if_changed,uimage) - @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' $(obj)/linux.bin.gz: $(obj)/linux.bin FORCE $(call if_changed,gzip) - @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' quiet_cmd_cp = CP $< $@$2 cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false) @@ -35,6 +32,5 @@ $(obj)/simpleImage.%: vmlinux FORCE $(call if_changed,objcopy) $(call if_changed,uimage) $(call if_changed,strip,.strip) - @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')' clean-files += simpleImage.* -- 2.7.4
Re: mtd: nftl: clean up indentation, remove extraneous tabs
On Sun, 2018-11-18 at 16:36:56 UTC, Colin King wrote: > From: Colin Ian King > > The hunk of code is indented too much by one level, fix this by > removing the extraneous tabs. Also terminate block comment using > the recommended coding style to clean up checkpatch warning. > > Signed-off-by: Colin Ian King Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks. Boris
[PATCH 5/7] microblaze: add linux.bin* and simpleImage.* to PHONY
linux.bin, linux.bin.gz, and linux.bin.ub are phony targets to generate a corresponding image under arch/microblaze/boot/. simpleImage.% also works like a PHONY target, but a pattern that contains '%' cannot be a PHONY target. I renamed it to equivalent simpleImage.$(DTB). Signed-off-by: Masahiro Yamada --- arch/microblaze/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile index c5d5b0e..7a5df02 100644 --- a/arch/microblaze/Makefile +++ b/arch/microblaze/Makefile @@ -79,11 +79,13 @@ all: linux.bin archclean: $(Q)$(MAKE) $(clean)=$(boot) +PHONY += linux.bin linux.bin.gz linux.bin.ub linux.bin linux.bin.gz linux.bin.ub: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')' -simpleImage.%: vmlinux +PHONY += simpleImage.$(DTB) +simpleImage.$(DTB): vmlinux $(Q)$(MAKE) $(build)=$(boot) simple_images @echo 'Kernel: $(boot)/$@ is ready' ' (#'`cat .version`')' -- 2.7.4
Re: [v3] mtd: change len type from signed to unsigned type
On Thu, 2018-11-29 at 04:19:51 UTC, Huijin Park wrote: > From: "huijin.park" > > Callers of erase_write() always pass an unsigned int. > So this patch avoids a cast to an int. > > Signed-off-by: huijin.park > Reviewed-by: Miquel Raynal Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks. Boris
Re: [v3] mtd: spi-nor: cast to u64 to avoid uint overflows
On Wed, 2018-11-28 at 08:02:14 UTC, Huijin Park wrote: > From: "huijin.park" > > The "params->size" is defined as "u64". > And "info->sector_size" and "info->n_sectors" are defined as > unsigned int and u16. > Thus, u64 data might have strange data(loss data) if the result > overflows an unsigned int. > This patch casts "info->sector_size" to an u64. > > Signed-off-by: huijin.park > Reviewed-by: Geert Uytterhoeven Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks. Boris
[PATCH 0/7] microblaze: fix various problems in building boot images
This patch set fixes various issues in microblaze Makefiles. BTW, "simpleImage." works like a phony target to generate the following four images, where the first three are just aliases. - arch/microblaze/boot/simpleImage.: identical to arch/microblaze/boot/linux.bin - arch/microblaze/boot/simpleImage..unstrip: identical to vmlinux - arch/microblaze/boot/simpleImage..ub: identical to arch/microblaze/boot/linux.bin.ub - arch/microblaze/boot/simpleImage..strip: stripped vmlinux I am not sure how much useful those copies are, but, I tried my best to keep the same behavior. IMHO, I guess DTB= would be more sensible, but it is up to Michal. Masahiro Yamada (7): microblaze: fix cleaning of boot images microblaze: adjust the help to the real behavior microblaze: move "... is ready" message to arch/microblaze/Makefile microblaze: fix multiple bugs in arch/microblaze/boot/Makefile microblaze: add linux.bin* and simpleImage.* to PHONY microblaze: fix race condition in building boot images microblaze: remove the unneeded code just in case file copy fails arch/microblaze/Makefile | 14 +- arch/microblaze/boot/Makefile | 33 + arch/microblaze/boot/dts/Makefile | 5 + 3 files changed, 27 insertions(+), 25 deletions(-) -- 2.7.4
[PATCH 2/7] microblaze: adjust the help to the real behavior
"make ARCH=microblaze help" mentions simpleImage..unstrip, but it never works because Makefile assumes "system.unstrip" is the name of DT. $ make ARCH=microblaze CROSS_COMPILE=microblaze-linux- simpleImage.system.unstrip [ snip ] make[1]: *** No rule to make target 'arch/microblaze/boot/dts/system.unstrip.dtb', needed by 'arch/microblaze/boot/dts/system.dtb'. Stop. make: *** [Makefile;1060: arch/microblaze/boot/dts] Error 2 make: *** Waiting for unfinished jobs Rip off the never-working target. In my understanding, simpleImage. works like a phony target that generates multiple images. Reflect the behavior to the help message. Signed-off-by: Masahiro Yamada --- arch/microblaze/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile index 0823d29..97e1384 100644 --- a/arch/microblaze/Makefile +++ b/arch/microblaze/Makefile @@ -89,9 +89,7 @@ define archhelp echo '* linux.bin- Create raw binary' echo ' linux.bin.gz - Create compressed raw binary' echo ' linux.bin.ub - Create U-Boot wrapped raw binary' - echo ' simpleImage. - ELF image with $(arch)/boot/dts/.dts linked in' - echo ' - stripped elf with fdt blob' - echo ' simpleImage..unstrip - full ELF image with fdt blob' + echo ' simpleImage. - Create images with $(arch)/boot/dts/.dts linked in' echo ' *_defconfig - Select default config from arch/microblaze/configs' echo '' echo ' Targets with embed a device tree blob inside the image' -- 2.7.4
Re: mtd: use DEFINE_SHOW_ATTRIBUTE() instead of open-coding it
On Sun, 2018-12-02 at 08:33:58 UTC, Yangtao Li wrote: > DEFINE_SHOW_ATTRIBUTE macro can help us simplify the code,so change > to it.And change the DEBUGFS_RO_ATTR macro defined in some file to a > standard macro. > > Signed-off-by: Yangtao Li Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks. Boris
Re: [v3] mtd: change len type from signed to unsigned type
On Thu, 2018-11-29 at 04:19:51 UTC, Huijin Park wrote: > From: "huijin.park" > > Callers of erase_write() always pass an unsigned int. > So this patch avoids a cast to an int. > > Signed-off-by: huijin.park > Reviewed-by: Miquel Raynal Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks. Boris
Re: [v3] mtd: spi-nor: cast to u64 to avoid uint overflows
On Wed, 2018-11-28 at 08:02:14 UTC, Huijin Park wrote: > From: "huijin.park" > > The "params->size" is defined as "u64". > And "info->sector_size" and "info->n_sectors" are defined as > unsigned int and u16. > Thus, u64 data might have strange data(loss data) if the result > overflows an unsigned int. > This patch casts "info->sector_size" to an u64. > > Signed-off-by: huijin.park > Reviewed-by: Geert Uytterhoeven Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks. Boris
[PATCH 0/7] microblaze: fix various problems in building boot images
This patch set fixes various issues in microblaze Makefiles. BTW, "simpleImage." works like a phony target to generate the following four images, where the first three are just aliases. - arch/microblaze/boot/simpleImage.: identical to arch/microblaze/boot/linux.bin - arch/microblaze/boot/simpleImage..unstrip: identical to vmlinux - arch/microblaze/boot/simpleImage..ub: identical to arch/microblaze/boot/linux.bin.ub - arch/microblaze/boot/simpleImage..strip: stripped vmlinux I am not sure how much useful those copies are, but, I tried my best to keep the same behavior. IMHO, I guess DTB= would be more sensible, but it is up to Michal. Masahiro Yamada (7): microblaze: fix cleaning of boot images microblaze: adjust the help to the real behavior microblaze: move "... is ready" message to arch/microblaze/Makefile microblaze: fix multiple bugs in arch/microblaze/boot/Makefile microblaze: add linux.bin* and simpleImage.* to PHONY microblaze: fix race condition in building boot images microblaze: remove the unneeded code just in case file copy fails arch/microblaze/Makefile | 14 +- arch/microblaze/boot/Makefile | 33 + arch/microblaze/boot/dts/Makefile | 5 + 3 files changed, 27 insertions(+), 25 deletions(-) -- 2.7.4
[PATCH 2/7] microblaze: adjust the help to the real behavior
"make ARCH=microblaze help" mentions simpleImage..unstrip, but it never works because Makefile assumes "system.unstrip" is the name of DT. $ make ARCH=microblaze CROSS_COMPILE=microblaze-linux- simpleImage.system.unstrip [ snip ] make[1]: *** No rule to make target 'arch/microblaze/boot/dts/system.unstrip.dtb', needed by 'arch/microblaze/boot/dts/system.dtb'. Stop. make: *** [Makefile;1060: arch/microblaze/boot/dts] Error 2 make: *** Waiting for unfinished jobs Rip off the never-working target. In my understanding, simpleImage. works like a phony target that generates multiple images. Reflect the behavior to the help message. Signed-off-by: Masahiro Yamada --- arch/microblaze/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile index 0823d29..97e1384 100644 --- a/arch/microblaze/Makefile +++ b/arch/microblaze/Makefile @@ -89,9 +89,7 @@ define archhelp echo '* linux.bin- Create raw binary' echo ' linux.bin.gz - Create compressed raw binary' echo ' linux.bin.ub - Create U-Boot wrapped raw binary' - echo ' simpleImage. - ELF image with $(arch)/boot/dts/.dts linked in' - echo ' - stripped elf with fdt blob' - echo ' simpleImage..unstrip - full ELF image with fdt blob' + echo ' simpleImage. - Create images with $(arch)/boot/dts/.dts linked in' echo ' *_defconfig - Select default config from arch/microblaze/configs' echo '' echo ' Targets with embed a device tree blob inside the image' -- 2.7.4
Re: mtd: use DEFINE_SHOW_ATTRIBUTE() instead of open-coding it
On Sun, 2018-12-02 at 08:33:58 UTC, Yangtao Li wrote: > DEFINE_SHOW_ATTRIBUTE macro can help us simplify the code,so change > to it.And change the DEBUGFS_RO_ATTR macro defined in some file to a > standard macro. > > Signed-off-by: Yangtao Li Applied to http://git.infradead.org/linux-mtd.git mtd/next, thanks. Boris
[PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)
* Linus Torvalds wrote:
> The patch stats this week look a little bit more normal than last tim,
> probably simply because it's also a normal-sized rc4 rather than the
> unusually small rc3.
So there's a new regression in v4.20-rc4, my desktop produces this
lockdep splat:
[ 1772.588771] WARNING: pkexec/4633 still has locks held!
[ 1772.588773] 4.20.0-rc4-custom-00213-g93a49841322b #1 Not tainted
[ 1772.588775]
[ 1772.588776] 1 lock held by pkexec/4633:
[ 1772.588778] #0: ed85fbf8 (>cred_guard_mutex){+.+.}, at:
prepare_bprm_creds+0x2a/0x70
[ 1772.588786] stack backtrace:
[ 1772.588789] CPU: 7 PID: 4633 Comm: pkexec Not tainted
4.20.0-rc4-custom-00213-g93a49841322b #1
[ 1772.588792] Call Trace:
[ 1772.588800] dump_stack+0x85/0xcb
[ 1772.588803] flush_old_exec+0x116/0x890
[ 1772.588807] ? load_elf_phdrs+0x72/0xb0
[ 1772.588809] load_elf_binary+0x291/0x1620
[ 1772.588815] ? sched_clock+0x5/0x10
[ 1772.588817] ? search_binary_handler+0x6d/0x240
[ 1772.588820] search_binary_handler+0x80/0x240
[ 1772.588823] load_script+0x201/0x220
[ 1772.588825] search_binary_handler+0x80/0x240
[ 1772.588828] __do_execve_file.isra.32+0x7d2/0xa60
[ 1772.588832] ? strncpy_from_user+0x40/0x180
[ 1772.588835] __x64_sys_execve+0x34/0x40
[ 1772.588838] do_syscall_64+0x60/0x1c0
The warning gets triggered by an ancient lockdep check in the freezer:
(gdb) list *0x812ece06
0x812ece06 is in flush_old_exec (./include/linux/freezer.h:57).
52 * DO NOT ADD ANY NEW CALLERS OF THIS FUNCTION
53 * If try_to_freeze causes a lockdep warning it means the caller may
deadlock
54 */
55 static inline bool try_to_freeze_unsafe(void)
56 {
57 might_sleep();
58 if (likely(!freezing(current)))
59 return false;
60 return __refrigerator(false);
61 }
I reviewed the ->cred_guard_mutex code, and the mutex is held across all
of exec() - and we always did this.
But there's this recent -rc4 commit:
> Chanho Min (1):
> exec: make de_thread() freezable
c22397888f1e: exec: make de_thread() freezable
I believe this commit is bogus, you cannot call try_to_freeze() from
de_thread(), because it's holding the ->cred_guard_mutex.
Also, I'm 3 times grumpy:
#1: I think this commit was never tested with lockdep turned on, as I
think splat this should trigger 100% of the time with the ELF
binfmt loader.
#2: Less than 4 days passed between the commit on Nov 19 and it being
upstream by Nov 23. *Please* give it more testing if you change
something as central as fs/exec.c ...
#3 Also, please also proof-read changelogs before committing them:
>> The casue is that de_thread() sleeps in TASK_UNINTERRUPTIBLE waiting
for
>> [...]
>>
>> In our machine, it causes freeze timeout as bellows.
That's *three* typos in a single commit:
s/casue/cause
s/In our/On our
s/bellows/below
...
Grump! :-)
Note that I haven't tested the revert yet, but the code and the breakage
looks pretty obvious. (I'll boot the revert, will follow up if that
didn't solve the problem.)
Thanks,
Ingo
Signed-off-by: Ingo Molnar
This reverts commit c22397888f1eed98cd59f0a88f2a5f6925f80e15.
---
fs/exec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index acc3a5536384..fc281b738a98 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -62,7 +62,6 @@
#include
#include
#include
-#include
#include
#include
@@ -1084,7 +1083,7 @@ static int de_thread(struct task_struct *tsk)
while (sig->notify_count) {
__set_current_state(TASK_KILLABLE);
spin_unlock_irq(lock);
- freezable_schedule();
+ schedule();
if (unlikely(__fatal_signal_pending(tsk)))
goto killed;
spin_lock_irq(lock);
@@ -1112,7 +,7 @@ static int de_thread(struct task_struct *tsk)
__set_current_state(TASK_KILLABLE);
write_unlock_irq(_lock);
cgroup_threadgroup_change_end(tsk);
- freezable_schedule();
+ schedule();
if (unlikely(__fatal_signal_pending(tsk)))
goto killed;
}
[PATCH] Revert "exec: make de_thread() freezable (was: Re: Linux 4.20-rc4)
* Linus Torvalds wrote:
> The patch stats this week look a little bit more normal than last tim,
> probably simply because it's also a normal-sized rc4 rather than the
> unusually small rc3.
So there's a new regression in v4.20-rc4, my desktop produces this
lockdep splat:
[ 1772.588771] WARNING: pkexec/4633 still has locks held!
[ 1772.588773] 4.20.0-rc4-custom-00213-g93a49841322b #1 Not tainted
[ 1772.588775]
[ 1772.588776] 1 lock held by pkexec/4633:
[ 1772.588778] #0: ed85fbf8 (>cred_guard_mutex){+.+.}, at:
prepare_bprm_creds+0x2a/0x70
[ 1772.588786] stack backtrace:
[ 1772.588789] CPU: 7 PID: 4633 Comm: pkexec Not tainted
4.20.0-rc4-custom-00213-g93a49841322b #1
[ 1772.588792] Call Trace:
[ 1772.588800] dump_stack+0x85/0xcb
[ 1772.588803] flush_old_exec+0x116/0x890
[ 1772.588807] ? load_elf_phdrs+0x72/0xb0
[ 1772.588809] load_elf_binary+0x291/0x1620
[ 1772.588815] ? sched_clock+0x5/0x10
[ 1772.588817] ? search_binary_handler+0x6d/0x240
[ 1772.588820] search_binary_handler+0x80/0x240
[ 1772.588823] load_script+0x201/0x220
[ 1772.588825] search_binary_handler+0x80/0x240
[ 1772.588828] __do_execve_file.isra.32+0x7d2/0xa60
[ 1772.588832] ? strncpy_from_user+0x40/0x180
[ 1772.588835] __x64_sys_execve+0x34/0x40
[ 1772.588838] do_syscall_64+0x60/0x1c0
The warning gets triggered by an ancient lockdep check in the freezer:
(gdb) list *0x812ece06
0x812ece06 is in flush_old_exec (./include/linux/freezer.h:57).
52 * DO NOT ADD ANY NEW CALLERS OF THIS FUNCTION
53 * If try_to_freeze causes a lockdep warning it means the caller may
deadlock
54 */
55 static inline bool try_to_freeze_unsafe(void)
56 {
57 might_sleep();
58 if (likely(!freezing(current)))
59 return false;
60 return __refrigerator(false);
61 }
I reviewed the ->cred_guard_mutex code, and the mutex is held across all
of exec() - and we always did this.
But there's this recent -rc4 commit:
> Chanho Min (1):
> exec: make de_thread() freezable
c22397888f1e: exec: make de_thread() freezable
I believe this commit is bogus, you cannot call try_to_freeze() from
de_thread(), because it's holding the ->cred_guard_mutex.
Also, I'm 3 times grumpy:
#1: I think this commit was never tested with lockdep turned on, as I
think splat this should trigger 100% of the time with the ELF
binfmt loader.
#2: Less than 4 days passed between the commit on Nov 19 and it being
upstream by Nov 23. *Please* give it more testing if you change
something as central as fs/exec.c ...
#3 Also, please also proof-read changelogs before committing them:
>> The casue is that de_thread() sleeps in TASK_UNINTERRUPTIBLE waiting
for
>> [...]
>>
>> In our machine, it causes freeze timeout as bellows.
That's *three* typos in a single commit:
s/casue/cause
s/In our/On our
s/bellows/below
...
Grump! :-)
Note that I haven't tested the revert yet, but the code and the breakage
looks pretty obvious. (I'll boot the revert, will follow up if that
didn't solve the problem.)
Thanks,
Ingo
Signed-off-by: Ingo Molnar
This reverts commit c22397888f1eed98cd59f0a88f2a5f6925f80e15.
---
fs/exec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index acc3a5536384..fc281b738a98 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -62,7 +62,6 @@
#include
#include
#include
-#include
#include
#include
@@ -1084,7 +1083,7 @@ static int de_thread(struct task_struct *tsk)
while (sig->notify_count) {
__set_current_state(TASK_KILLABLE);
spin_unlock_irq(lock);
- freezable_schedule();
+ schedule();
if (unlikely(__fatal_signal_pending(tsk)))
goto killed;
spin_lock_irq(lock);
@@ -1112,7 +,7 @@ static int de_thread(struct task_struct *tsk)
__set_current_state(TASK_KILLABLE);
write_unlock_irq(_lock);
cgroup_threadgroup_change_end(tsk);
- freezable_schedule();
+ schedule();
if (unlikely(__fatal_signal_pending(tsk)))
goto killed;
}
RE: rcu_preempt caused oom
Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. echo 1 > /proc/sys/kernel/panic_on_rcu_stall -Original Message- From: Paul E. McKenney Sent: Saturday, December 1, 2018 12:49 AM To: He, Bo Cc: Steven Rostedt ; linux-kernel@vger.kernel.org; j...@joshtriplett.org; mathieu.desnoy...@efficios.com; jiangshan...@gmail.com; Zhang, Jun ; Xiao, Jin ; Zhang, Yanmin Subject: Re: rcu_preempt caused oom On Fri, Nov 30, 2018 at 03:18:58PM +, He, Bo wrote: > Here is the kernel cmdline: Thank you! > Kernel command line: androidboot.acpio_idx=0 > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_03- > userdebug androidboot.diskbus=00.0 androidboot.verifiedbootstate=green > androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti > ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt > loglevel=4 androidboot.hardware=gordon_peak > firmware_class.path=/vendor/firmware relative_sleep_states=1 > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/prope > rties/android/ pstore.backend=ramoops memmap=0x140$0x5000 > ramoops.mem_address=0x5000 ramoops.mem_size=0x140 > ramoops.record_size=0x4000 ramoops.console_size=0x100 > ramoops.ftrace_size=0x1 ramoops.dump_oops=1 vga=current > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > drm.vblankoffdelay= And no sign of any suppression of RCU CPU stall warnings. Hmmm... It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: rcupdate.rcu_cpu_stall_timeout=7 This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. Thanx, Paul > -Original Message- > From: Steven Rostedt > Sent: Friday, November 30, 2018 11:17 PM > To: Paul E. McKenney > Cc: He, Bo ; linux-kernel@vger.kernel.org; > j...@joshtriplett.org; mathieu.desnoy...@efficios.com; > jiangshan...@gmail.com; Zhang, Jun ; Xiao, Jin > ; Zhang, Yanmin > Subject: Re: rcu_preempt caused oom > > On Fri, 30 Nov 2018 06:43:17 -0800 > "Paul E. McKenney" wrote: > > > Could you please send me your list of kernel boot parameters? They > > usually appear near the start of your console output. > > Or just: cat /proc/cmdline > > -- Steve >
RE: rcu_preempt caused oom
Thanks, we have run the test for the whole weekend and not reproduce the issue, so we confirm the CONFIG_RCU_BOOST can fix the issue. We have enabled the rcupdate.rcu_cpu_stall_timeout=7 and also set panic on rcu stall and will see if we can see the panic, will keep you posed with the test results. echo 1 > /proc/sys/kernel/panic_on_rcu_stall -Original Message- From: Paul E. McKenney Sent: Saturday, December 1, 2018 12:49 AM To: He, Bo Cc: Steven Rostedt ; linux-kernel@vger.kernel.org; j...@joshtriplett.org; mathieu.desnoy...@efficios.com; jiangshan...@gmail.com; Zhang, Jun ; Xiao, Jin ; Zhang, Yanmin Subject: Re: rcu_preempt caused oom On Fri, Nov 30, 2018 at 03:18:58PM +, He, Bo wrote: > Here is the kernel cmdline: Thank you! > Kernel command line: androidboot.acpio_idx=0 > androidboot.bootloader=efiwrapper-02_03-userdebug_kernelflinger-06_03- > userdebug androidboot.diskbus=00.0 androidboot.verifiedbootstate=green > androidboot.bootreason=power-on androidboot.serialno=R1J56L6006a7bb > g_ffs.iSerialNumber=R1J56L6006a7bb no_timer_check noxsaves > reboot_panic=p,w i915.hpd_sense_invert=0x7 mem=2G nokaslr nopti > ftrace_dump_on_oops trace_buf_size=1024K intel_iommu=off gpt > loglevel=4 androidboot.hardware=gordon_peak > firmware_class.path=/vendor/firmware relative_sleep_states=1 > enforcing=0 androidboot.selinux=permissive cpu_init_udelay=10 > androidboot.android_dt_dir=/sys/bus/platform/devices/ANDR0001:00/prope > rties/android/ pstore.backend=ramoops memmap=0x140$0x5000 > ramoops.mem_address=0x5000 ramoops.mem_size=0x140 > ramoops.record_size=0x4000 ramoops.console_size=0x100 > ramoops.ftrace_size=0x1 ramoops.dump_oops=1 vga=current > i915.modeset=1 drm.atomic=1 i915.nuclear_pageflip=1 > drm.vblankoffdelay= And no sign of any suppression of RCU CPU stall warnings. Hmmm... It does take more than 21 seconds to OOM? Or do things happen faster than that? If they do happen faster than that, then on approach would be to add something like this to the kernel command line: rcupdate.rcu_cpu_stall_timeout=7 This would set the stall timeout to seven seconds. Note that timeouts less than three seconds are silently interpreted as three seconds. Thanx, Paul > -Original Message- > From: Steven Rostedt > Sent: Friday, November 30, 2018 11:17 PM > To: Paul E. McKenney > Cc: He, Bo ; linux-kernel@vger.kernel.org; > j...@joshtriplett.org; mathieu.desnoy...@efficios.com; > jiangshan...@gmail.com; Zhang, Jun ; Xiao, Jin > ; Zhang, Yanmin > Subject: Re: rcu_preempt caused oom > > On Fri, 30 Nov 2018 06:43:17 -0800 > "Paul E. McKenney" wrote: > > > Could you please send me your list of kernel boot parameters? They > > usually appear near the start of your console output. > > Or just: cat /proc/cmdline > > -- Steve >
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Hi,
On 2018/11/30 17:16, Stephen Boyd wrote:
Quoting Sugaya, Taichi (2018-11-29 04:24:51)
On 2018/11/28 11:01, Stephen Boyd wrote:
Quoting Sugaya Taichi (2018-11-18 17:01:07)
create mode 100644
Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
new file mode 100644
index 000..f5d906c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
@@ -0,0 +1,12 @@
+Socionext M10V SMP trampoline driver binding
+
+This is a driver to wait for sub-cores while boot process.
+
+- compatible: should be "socionext,smp-trampoline"
+- reg: should be <0x4C000100 0x100>
+
+EXAMPLE
+ trampoline: trampoline@0x4C000100 {
Drop the 0x part of unit addresses.
Okay.
+ compatible = "socionext,smp-trampoline";
+ reg = <0x4C000100 0x100>;
Looks like a software construct, which we wouldn't want to put into DT
this way. DT doesn't describe drivers.
We would like to use this node only getting the address of the
trampoline area
in which sub-cores wait. (They have finished to go to this area in previous
bootloader process.)
Is this area part of memory, or a special SRAM? If it's part of memory,
I would expect this node to be under the reserved-memory node and
pointed to by some other node that uses this region. Could even be the
CPU nodes.
Yes, 0x4C000100 is a part of memory under the reserved-memory node. So
we would like to use the SRAM ( allocated 0x ) area instead.
BTW, sorry, the trampoline address of this example is simply wrong. We
were going to use a part of the SRAM from the beginning.
So should we embed the constant value in source codes instead of getting
from
DT because the address is constant at the moment? Or is there other
approach?
If it's constant then that also works. Why does it need to come from DT
at all then?
We think it is not good to embed constant value in driver codes and do
not have another way...
Are there better ways?
Thanks
Sugaya Taichi
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Hi,
On 2018/11/30 17:16, Stephen Boyd wrote:
Quoting Sugaya, Taichi (2018-11-29 04:24:51)
On 2018/11/28 11:01, Stephen Boyd wrote:
Quoting Sugaya Taichi (2018-11-18 17:01:07)
create mode 100644
Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
new file mode 100644
index 000..f5d906c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
@@ -0,0 +1,12 @@
+Socionext M10V SMP trampoline driver binding
+
+This is a driver to wait for sub-cores while boot process.
+
+- compatible: should be "socionext,smp-trampoline"
+- reg: should be <0x4C000100 0x100>
+
+EXAMPLE
+ trampoline: trampoline@0x4C000100 {
Drop the 0x part of unit addresses.
Okay.
+ compatible = "socionext,smp-trampoline";
+ reg = <0x4C000100 0x100>;
Looks like a software construct, which we wouldn't want to put into DT
this way. DT doesn't describe drivers.
We would like to use this node only getting the address of the
trampoline area
in which sub-cores wait. (They have finished to go to this area in previous
bootloader process.)
Is this area part of memory, or a special SRAM? If it's part of memory,
I would expect this node to be under the reserved-memory node and
pointed to by some other node that uses this region. Could even be the
CPU nodes.
Yes, 0x4C000100 is a part of memory under the reserved-memory node. So
we would like to use the SRAM ( allocated 0x ) area instead.
BTW, sorry, the trampoline address of this example is simply wrong. We
were going to use a part of the SRAM from the beginning.
So should we embed the constant value in source codes instead of getting
from
DT because the address is constant at the moment? Or is there other
approach?
If it's constant then that also works. Why does it need to come from DT
at all then?
We think it is not good to embed constant value in driver codes and do
not have another way...
Are there better ways?
Thanks
Sugaya Taichi
Re: [PATCH v2 06/15] m68k: define syscall_get_arch()
Hi Dmitry,
On Mon, Dec 3, 2018 at 1:24 AM Dmitry V. Levin wrote:
> On Sun, Dec 02, 2018 at 11:29:10AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Nov 20, 2018 at 1:15 AM Dmitry V. Levin wrote:
> > > syscall_get_arch() is required to be implemented on all architectures
> > > in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
> > > request.
> > >
> > > Signed-off-by: Dmitry V. Levin
> >
> > Reviewed-by: Geert Uytterhoeven
> >
> > What's your plan w.r.t. the upstreaming strategy?
> > Do you plan to get this series in as a whole, or through individual
> > architecture
> > maintainers?
>
> Given that the last patch in this series adds an argument
> to syscall_get_arch(), my plan is to get this series in
> as a whole along with PTRACE_GET_SYSCALL_INFO series.
Cool, thanks!
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 06/15] m68k: define syscall_get_arch()
Hi Dmitry,
On Mon, Dec 3, 2018 at 1:24 AM Dmitry V. Levin wrote:
> On Sun, Dec 02, 2018 at 11:29:10AM +0100, Geert Uytterhoeven wrote:
> > On Tue, Nov 20, 2018 at 1:15 AM Dmitry V. Levin wrote:
> > > syscall_get_arch() is required to be implemented on all architectures
> > > in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
> > > request.
> > >
> > > Signed-off-by: Dmitry V. Levin
> >
> > Reviewed-by: Geert Uytterhoeven
> >
> > What's your plan w.r.t. the upstreaming strategy?
> > Do you plan to get this series in as a whole, or through individual
> > architecture
> > maintainers?
>
> Given that the last patch in this series adds an argument
> to syscall_get_arch(), my plan is to get this series in
> as a whole along with PTRACE_GET_SYSCALL_INFO series.
Cool, thanks!
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
linux-next: Tree for Dec 3
Hi all,
Changes since 20181130:
The arm-soc tree gained a conflict against the kbuild tree.
The reset tree gained a conflict against the arm-soc tree.
The clk tree lost its build failure.
The vfs tree gained a conflict against the fscrypt tree.
The net-next tree gained conflicts against the net and bpf trees.
The akpm tree still had its build failure so I added another fix patch.
Non-merge commits (relative to Linus' tree): 5737
5828 files changed, 283447 insertions(+), 161618 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 286 trees (counting Linus' and 67 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (6a512726090a Merge tag 'armsoc-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging fixes/master (d8c137546ef8 powerpc: tag implicit fall throughs)
Merging kbuild-current/fixes (8d6237bb5d27 kbuild: fix UML build error with
CONFIG_GCC_PLUGINS)
Merging arc-current/for-curr (10d443431dc2 ARC: io.h: Implement
reads{x}()/writes{x}())
Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false
positive with FORTIFY_SOURCE)
Merging arm64-fixes/for-next/fixes (ea2412dc21cc ACPI/IORT: Fix
iort_get_platform_device_domain() uninitialized pointer value)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (bf3d6afbb234 powerpc: Look for "stdout-path" when
setting up legacy consoles)
Merging sparc/master (e399ef194171 sparc32: supress another
implicit-fallthrough warning)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (35b827b6d061 tun: forbid iface creation with rtnl ops)
Merging bpf/master (dcb40590e69e bpf: refactor bpf_test_run() to separate own
failures and test program result)
Merging ipsec/master (4a135e538962 xfrm_user: fix freeing of xfrm states on
acquire)
Merging netfilter/master (d78a5ebd8b18 Merge branch '1GbE' of
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates
of non-anonymous set)
Merging wireless-drivers/master (2e6e902d1850 Linux 4.20-rc4)
Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore
during STA disconnect in concurrent interfaces)
Merging rdma-fixes/for-rc (7bca603a69c0 RDMA/mlx5: Initialize return variable
in case pagefault was skipped)
Merging sound-current/for-linus (5363857b916c ALSA: pcm: Fix interval
evaluation with openmin/max)
Merging sound-asoc-fixes/for-linus (b586eb05a2b8 Merge branch 'asoc-4.20' into
asoc-linus)
Merging regmap-fixes/for-linus (9ff01193a20d Linux 4.20-rc3)
Merging regulator-fixes/for-linus (af4d024d23b5 Merge branch 'regulator-4.20'
into regulator-linus)
Merging spi-fixes/for-linus (5377ce14c76a Merge branch 'spi-4.20' into
spi-linus)
Merging pci-current/for-linus (c74eadf881ad Merge remote-tracking branch
'lorenzo/pci/controller-fixes' into for-linus)
Merging driver-core.current/driver-core-linus (d8f190ee836a Merge branch 'akpm'
(patches from Andrew))
Merging tty.current/tty-linus (2a48602615e0 tty: do not set TTY_IO_ERROR flag
if console port)
Merging usb.current/usb-linus (d8f190ee836a Merge branch 'akpm' (patches from
Andrew))
Merging usb-gadget-fixes/fixes
linux-next: Tree for Dec 3
Hi all,
Changes since 20181130:
The arm-soc tree gained a conflict against the kbuild tree.
The reset tree gained a conflict against the arm-soc tree.
The clk tree lost its build failure.
The vfs tree gained a conflict against the fscrypt tree.
The net-next tree gained conflicts against the net and bpf trees.
The akpm tree still had its build failure so I added another fix patch.
Non-merge commits (relative to Linus' tree): 5737
5828 files changed, 283447 insertions(+), 161618 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 286 trees (counting Linus' and 67 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (6a512726090a Merge tag 'armsoc-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging fixes/master (d8c137546ef8 powerpc: tag implicit fall throughs)
Merging kbuild-current/fixes (8d6237bb5d27 kbuild: fix UML build error with
CONFIG_GCC_PLUGINS)
Merging arc-current/for-curr (10d443431dc2 ARC: io.h: Implement
reads{x}()/writes{x}())
Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false
positive with FORTIFY_SOURCE)
Merging arm64-fixes/for-next/fixes (ea2412dc21cc ACPI/IORT: Fix
iort_get_platform_device_domain() uninitialized pointer value)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (bf3d6afbb234 powerpc: Look for "stdout-path" when
setting up legacy consoles)
Merging sparc/master (e399ef194171 sparc32: supress another
implicit-fallthrough warning)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (35b827b6d061 tun: forbid iface creation with rtnl ops)
Merging bpf/master (dcb40590e69e bpf: refactor bpf_test_run() to separate own
failures and test program result)
Merging ipsec/master (4a135e538962 xfrm_user: fix freeing of xfrm states on
acquire)
Merging netfilter/master (d78a5ebd8b18 Merge branch '1GbE' of
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates
of non-anonymous set)
Merging wireless-drivers/master (2e6e902d1850 Linux 4.20-rc4)
Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore
during STA disconnect in concurrent interfaces)
Merging rdma-fixes/for-rc (7bca603a69c0 RDMA/mlx5: Initialize return variable
in case pagefault was skipped)
Merging sound-current/for-linus (5363857b916c ALSA: pcm: Fix interval
evaluation with openmin/max)
Merging sound-asoc-fixes/for-linus (b586eb05a2b8 Merge branch 'asoc-4.20' into
asoc-linus)
Merging regmap-fixes/for-linus (9ff01193a20d Linux 4.20-rc3)
Merging regulator-fixes/for-linus (af4d024d23b5 Merge branch 'regulator-4.20'
into regulator-linus)
Merging spi-fixes/for-linus (5377ce14c76a Merge branch 'spi-4.20' into
spi-linus)
Merging pci-current/for-linus (c74eadf881ad Merge remote-tracking branch
'lorenzo/pci/controller-fixes' into for-linus)
Merging driver-core.current/driver-core-linus (d8f190ee836a Merge branch 'akpm'
(patches from Andrew))
Merging tty.current/tty-linus (2a48602615e0 tty: do not set TTY_IO_ERROR flag
if console port)
Merging usb.current/usb-linus (d8f190ee836a Merge branch 'akpm' (patches from
Andrew))
Merging usb-gadget-fixes/fixes
Re: [PATCH v2] x86/hyper-v: Mark TLFS structures packed
On Mon, Dec 03, 2018 at 12:35:35AM +0100, Vitaly Kuznetsov wrote:
> Nadav Amit writes:
>
> [skip]
>
> >
> > Having said that, something else is sort of strange in the TLFS definitions,
> > I think (I really know little about this whole protocol). Look at the
> > following definitions from hyperv-tlfs.h:
> >
> >> struct hv_vpset {
> >> u64 format;
> >> u64 valid_bank_mask;
> >> u64 bank_contents[];
> >> };
> >>
> >> struct hv_tlb_flush_ex {
> >> u64 address_space;
> >> u64 flags;
> >> struct hv_vpset hv_vp_set;
> >> u64 gva_list[];
> >> };
> >
> > It seems you have two flexible array members at the end of hv_tlb_flush_ex.
> > This causes bank_contents[x] and gva_list[x] to overlap. So unless they have
> > the same meaning, this asks for trouble IMHO.
> >
>
> This is weird but intentional :-) We're just following Hyper-V spec
> here.
>
> E.g. HvFlushVirtualAddressListEx hypercall has the following input ABI:
>
> [Fixed len head][[Fixed len VP set spec]Var len VP set][Var len addr List]
>
> "Fixed len VP set spec" defines the true length of "Var len VP set" and
> "Address List" starts right after that. The length of the whole
> structure is also known.
>
> So bank_contents[] and gva_list[] do overlap (and have different
> meaning). We take special precautions when forming the structure
> (e.g. fill_gva_list() takes 'offset').
This basically means that the argument of this hypercall can't be
represented by a C struct. gva_list just can't be used. So I'd rather
remove it from the struct (but leave a comment to that end perhaps), and
construct the message in place (as is done now anyway).
Roman.
Re: [PATCH v2] x86/hyper-v: Mark TLFS structures packed
On Mon, Dec 03, 2018 at 12:35:35AM +0100, Vitaly Kuznetsov wrote:
> Nadav Amit writes:
>
> [skip]
>
> >
> > Having said that, something else is sort of strange in the TLFS definitions,
> > I think (I really know little about this whole protocol). Look at the
> > following definitions from hyperv-tlfs.h:
> >
> >> struct hv_vpset {
> >> u64 format;
> >> u64 valid_bank_mask;
> >> u64 bank_contents[];
> >> };
> >>
> >> struct hv_tlb_flush_ex {
> >> u64 address_space;
> >> u64 flags;
> >> struct hv_vpset hv_vp_set;
> >> u64 gva_list[];
> >> };
> >
> > It seems you have two flexible array members at the end of hv_tlb_flush_ex.
> > This causes bank_contents[x] and gva_list[x] to overlap. So unless they have
> > the same meaning, this asks for trouble IMHO.
> >
>
> This is weird but intentional :-) We're just following Hyper-V spec
> here.
>
> E.g. HvFlushVirtualAddressListEx hypercall has the following input ABI:
>
> [Fixed len head][[Fixed len VP set spec]Var len VP set][Var len addr List]
>
> "Fixed len VP set spec" defines the true length of "Var len VP set" and
> "Address List" starts right after that. The length of the whole
> structure is also known.
>
> So bank_contents[] and gva_list[] do overlap (and have different
> meaning). We take special precautions when forming the structure
> (e.g. fill_gva_list() takes 'offset').
This basically means that the argument of this hypercall can't be
represented by a C struct. gva_list just can't be used. So I'd rather
remove it from the struct (but leave a comment to that end perhaps), and
construct the message in place (as is done now anyway).
Roman.
Re: [PATCH AUTOSEL 4.14 25/35] iomap: sub-block dio needs to zeroout beyond EOF
On Mon, Dec 3, 2018 at 1:23 AM Dave Chinner wrote: > > On Sat, Dec 01, 2018 at 02:49:09AM -0500, Sasha Levin wrote: > > On Sat, Dec 01, 2018 at 08:50:05AM +1100, Dave Chinner wrote: > > >On Fri, Nov 30, 2018 at 05:14:41AM -0500, Sasha Levin wrote: > > >>On Fri, Nov 30, 2018 at 09:22:03AM +0100, Greg KH wrote: > > >>>On Fri, Nov 30, 2018 at 09:40:19AM +1100, Dave Chinner wrote: > > I stopped my tests at 5 billion ops yesterday (i.e. 20 billion ops > > aggregate) to focus on testing the copy_file_range() changes, but > > Darrick's tests are still ongoing and have passed 40 billion ops in > > aggregate over the past few days. > > > > The reason we are running these so long is that we've seen fsx data > > corruption failures after 12+ hours of runtime and hundreds of > > millions of ops. Hence the testing for backported fixes will need to > > replicate these test runs across multiple configurations for > > multiple days before we have any confidence that we've actually > > fixed the data corruptions and not introduced any new ones. > > > > If you pull only a small subset of the fixes, the fsx will still > > fail and we have no real way of actually verifying that there have > > been no regression introduced by the backport. IOWs, there's a > > /massive/ amount of QA needed for ensuring that these backports work > > correctly. > > > > Right now the XFS developers don't have the time or resources > > available to validate stable backports are correct and regression > > fre because we are focussed on ensuring the upstream fixes we've > > already made (and are still writing) are solid and reliable. > > >>> > > >>>Ok, that's fine, so users of XFS should wait until the 4.20 release > > >>>before relying on it? :) > > >> > > >>It's getting to the point that with the amount of known issues with XFS > > >>on LTS kernels it makes sense to mark it as CONFIG_BROKEN. > > > > > >Really? Where are the bug reports? > > > > In 'git log'! You report these every time you fix something in upstream > > xfs but don't backport it to stable trees: > > That is so wrong on so many levels I don't really know where to > begin. I guess doing a *basic risk analysis* demonstrating that none > of those fixes are backport candidates is a good start: > > > $ git log --oneline v4.18-rc1..v4.18 fs/xfs > > d4a34e165557 xfs: properly handle free inodes in extent hint validators > > Found by QA with generic/229 on a non-standard config. Not user > reported, unlikely to ever be seen by users. > > > 9991274fddb9 xfs: Initialize variables in xfs_alloc_get_rec before using > > them > > Cleaning up coverity reported issues to do with corruption log > messages. No visible symptoms, Not user reported. > > > d8cb5e423789 xfs: fix fdblocks accounting w/ RMAPBT per-AG reservation > > Minor free space accounting issue, not user reported, doesn't affect > normal operation. > > > e53c4b598372 xfs: ensure post-EOF zeroing happens after zeroing part of a > > file > > Found with fsx via generic/127. Not user reported, doesn't affect > userspace operation at all. > > > a3a374bf1889 xfs: fix off-by-one error in xfs_rtalloc_query_range > > Regression fix for code introduced in 4.18-rc1. Not user reported > because the code has never been released. > > > 232d0a24b0fc xfs: fix uninitialized field in rtbitmap fsmap backend > > Coverity warning fix, not user reported, not user impact. > > > 5bd88d153998 xfs: recheck reflink state after grabbing ILOCK_SHARED for a > > write > > Fixes warning from generic/166, not user reported. Could affect > users mixing direct IO with reflink, but we expect people using > new functionality like reflink to be tracking TOT fairly closely > anyway. > > > f62cb48e4319 xfs: don't allow insert-range to shift extents past the > > maximum offset > > Found by QA w/ generic/465. Not user reported, only affects files in > the exabyte range so not a real world problem > > > aafe12cee0b1 xfs: don't trip over negative free space in xfs_reserve_blocks > > Found during ENOSPC stress tests that depeleted the reserve pool. > Not user reported, unlikely to ever be hit by users. > > > 10ee25268e1f xfs: allow empty transactions while frozen > > Removes a spurious warning when running GETFSMAP ioctl on a frozen > filesystem. Not user reported, highly unlikely any user will ever > hit this as nothing but XFs utilities use GETFSMAP at the moment. > > > e53946dbd31a xfs: xfs_iflush_abort() can be called twice on cluster > > writeback failure > > Bug in corrupted filesystem handling, been there for ~15 years IIRC. > Not user reported - found by one of our shutdown stress tests > on a debug kernel (generic/388, IIRC). Highly unlikely to show up in > the real world given how long the bug has been there. > > > 23fcb3340d03 xfs: More robust inode extent count validation > > Found by filesystem image fuzzing (i.e. intentional filesystem > corruption). Not user
Re: [PATCH AUTOSEL 4.14 25/35] iomap: sub-block dio needs to zeroout beyond EOF
On Mon, Dec 3, 2018 at 1:23 AM Dave Chinner wrote: > > On Sat, Dec 01, 2018 at 02:49:09AM -0500, Sasha Levin wrote: > > On Sat, Dec 01, 2018 at 08:50:05AM +1100, Dave Chinner wrote: > > >On Fri, Nov 30, 2018 at 05:14:41AM -0500, Sasha Levin wrote: > > >>On Fri, Nov 30, 2018 at 09:22:03AM +0100, Greg KH wrote: > > >>>On Fri, Nov 30, 2018 at 09:40:19AM +1100, Dave Chinner wrote: > > I stopped my tests at 5 billion ops yesterday (i.e. 20 billion ops > > aggregate) to focus on testing the copy_file_range() changes, but > > Darrick's tests are still ongoing and have passed 40 billion ops in > > aggregate over the past few days. > > > > The reason we are running these so long is that we've seen fsx data > > corruption failures after 12+ hours of runtime and hundreds of > > millions of ops. Hence the testing for backported fixes will need to > > replicate these test runs across multiple configurations for > > multiple days before we have any confidence that we've actually > > fixed the data corruptions and not introduced any new ones. > > > > If you pull only a small subset of the fixes, the fsx will still > > fail and we have no real way of actually verifying that there have > > been no regression introduced by the backport. IOWs, there's a > > /massive/ amount of QA needed for ensuring that these backports work > > correctly. > > > > Right now the XFS developers don't have the time or resources > > available to validate stable backports are correct and regression > > fre because we are focussed on ensuring the upstream fixes we've > > already made (and are still writing) are solid and reliable. > > >>> > > >>>Ok, that's fine, so users of XFS should wait until the 4.20 release > > >>>before relying on it? :) > > >> > > >>It's getting to the point that with the amount of known issues with XFS > > >>on LTS kernels it makes sense to mark it as CONFIG_BROKEN. > > > > > >Really? Where are the bug reports? > > > > In 'git log'! You report these every time you fix something in upstream > > xfs but don't backport it to stable trees: > > That is so wrong on so many levels I don't really know where to > begin. I guess doing a *basic risk analysis* demonstrating that none > of those fixes are backport candidates is a good start: > > > $ git log --oneline v4.18-rc1..v4.18 fs/xfs > > d4a34e165557 xfs: properly handle free inodes in extent hint validators > > Found by QA with generic/229 on a non-standard config. Not user > reported, unlikely to ever be seen by users. > > > 9991274fddb9 xfs: Initialize variables in xfs_alloc_get_rec before using > > them > > Cleaning up coverity reported issues to do with corruption log > messages. No visible symptoms, Not user reported. > > > d8cb5e423789 xfs: fix fdblocks accounting w/ RMAPBT per-AG reservation > > Minor free space accounting issue, not user reported, doesn't affect > normal operation. > > > e53c4b598372 xfs: ensure post-EOF zeroing happens after zeroing part of a > > file > > Found with fsx via generic/127. Not user reported, doesn't affect > userspace operation at all. > > > a3a374bf1889 xfs: fix off-by-one error in xfs_rtalloc_query_range > > Regression fix for code introduced in 4.18-rc1. Not user reported > because the code has never been released. > > > 232d0a24b0fc xfs: fix uninitialized field in rtbitmap fsmap backend > > Coverity warning fix, not user reported, not user impact. > > > 5bd88d153998 xfs: recheck reflink state after grabbing ILOCK_SHARED for a > > write > > Fixes warning from generic/166, not user reported. Could affect > users mixing direct IO with reflink, but we expect people using > new functionality like reflink to be tracking TOT fairly closely > anyway. > > > f62cb48e4319 xfs: don't allow insert-range to shift extents past the > > maximum offset > > Found by QA w/ generic/465. Not user reported, only affects files in > the exabyte range so not a real world problem > > > aafe12cee0b1 xfs: don't trip over negative free space in xfs_reserve_blocks > > Found during ENOSPC stress tests that depeleted the reserve pool. > Not user reported, unlikely to ever be hit by users. > > > 10ee25268e1f xfs: allow empty transactions while frozen > > Removes a spurious warning when running GETFSMAP ioctl on a frozen > filesystem. Not user reported, highly unlikely any user will ever > hit this as nothing but XFs utilities use GETFSMAP at the moment. > > > e53946dbd31a xfs: xfs_iflush_abort() can be called twice on cluster > > writeback failure > > Bug in corrupted filesystem handling, been there for ~15 years IIRC. > Not user reported - found by one of our shutdown stress tests > on a debug kernel (generic/388, IIRC). Highly unlikely to show up in > the real world given how long the bug has been there. > > > 23fcb3340d03 xfs: More robust inode extent count validation > > Found by filesystem image fuzzing (i.e. intentional filesystem > corruption). Not user
Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote: > The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from > STMicroelectronics. > The STPMIC1 regulators supply power to an application processor as well as > to external system peripherals such as DDR, Flash memories and system > devices. It also features onkey button input and an hardware watchdog. > The STPMIC1 is controlled via I2C. > > Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and > irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd > as parent. > > STPMIC1 MFD and regulator drivers maybe mandatory at boot time. > > Pascal Paillet (7): > changes in v7: > * rebase on regul/for-next > > dt-bindings: mfd: document stpmic1 > mfd: stpmic1: add stpmic1 driver > dt-bindings: input: document stpmic1 pmic onkey > input: stpmic1: add stpmic1 onkey driver > dt-bindings: watchdog: document stpmic1 pmic watchdog > watchdog: stpmic1: add stpmic1 watchdog driver > regulator: stpmic1: fix regulator_lock usage > > .../devicetree/bindings/input/st,stpmic1-onkey.txt | 28 +++ > .../devicetree/bindings/mfd/st,stpmic1.txt | 61 ++ > .../bindings/watchdog/st,stpmic1-wdt.txt | 11 ++ > drivers/input/misc/Kconfig | 11 ++ > drivers/input/misc/Makefile| 2 + > drivers/input/misc/stpmic1_onkey.c | 198 +++ > drivers/mfd/Kconfig| 16 ++ > drivers/mfd/Makefile | 1 + > drivers/mfd/stpmic1.c | 213 > + > drivers/regulator/stpmic1_regulator.c | 2 +- Is it just Mark you're waiting on now? > drivers/watchdog/Kconfig | 12 ++ > drivers/watchdog/Makefile | 1 + > drivers/watchdog/stpmic1_wdt.c | 139 ++ > include/dt-bindings/mfd/st,stpmic1.h | 50 + > include/linux/mfd/stpmic1.h| 212 > 15 files changed, 956 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt > create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt > create mode 100644 > Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt > create mode 100644 drivers/input/misc/stpmic1_onkey.c > create mode 100644 drivers/mfd/stpmic1.c > create mode 100644 drivers/watchdog/stpmic1_wdt.c > create mode 100644 include/dt-bindings/mfd/st,stpmic1.h > create mode 100644 include/linux/mfd/stpmic1.h > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote: > The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from > STMicroelectronics. > The STPMIC1 regulators supply power to an application processor as well as > to external system peripherals such as DDR, Flash memories and system > devices. It also features onkey button input and an hardware watchdog. > The STPMIC1 is controlled via I2C. > > Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and > irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd > as parent. > > STPMIC1 MFD and regulator drivers maybe mandatory at boot time. > > Pascal Paillet (7): > changes in v7: > * rebase on regul/for-next > > dt-bindings: mfd: document stpmic1 > mfd: stpmic1: add stpmic1 driver > dt-bindings: input: document stpmic1 pmic onkey > input: stpmic1: add stpmic1 onkey driver > dt-bindings: watchdog: document stpmic1 pmic watchdog > watchdog: stpmic1: add stpmic1 watchdog driver > regulator: stpmic1: fix regulator_lock usage > > .../devicetree/bindings/input/st,stpmic1-onkey.txt | 28 +++ > .../devicetree/bindings/mfd/st,stpmic1.txt | 61 ++ > .../bindings/watchdog/st,stpmic1-wdt.txt | 11 ++ > drivers/input/misc/Kconfig | 11 ++ > drivers/input/misc/Makefile| 2 + > drivers/input/misc/stpmic1_onkey.c | 198 +++ > drivers/mfd/Kconfig| 16 ++ > drivers/mfd/Makefile | 1 + > drivers/mfd/stpmic1.c | 213 > + > drivers/regulator/stpmic1_regulator.c | 2 +- Is it just Mark you're waiting on now? > drivers/watchdog/Kconfig | 12 ++ > drivers/watchdog/Makefile | 1 + > drivers/watchdog/stpmic1_wdt.c | 139 ++ > include/dt-bindings/mfd/st,stpmic1.h | 50 + > include/linux/mfd/stpmic1.h| 212 > 15 files changed, 956 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt > create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt > create mode 100644 > Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt > create mode 100644 drivers/input/misc/stpmic1_onkey.c > create mode 100644 drivers/mfd/stpmic1.c > create mode 100644 drivers/watchdog/stpmic1_wdt.c > create mode 100644 include/dt-bindings/mfd/st,stpmic1.h > create mode 100644 include/linux/mfd/stpmic1.h > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
How are you today?
Good Day Dear, I'm Ms Amelia and am new here looking for a serious relationship with someone i can spend the rest of my life with, someone who is loving, caring, honest and faithful to spend the rest of my life with, i came across your profile and its very interesting to me and i would like to know more about you to see if this will work out for both of us...Kindly reply me to know more about each other better. Here is my email address ( mis.ameliahal...@gmail.com ) Love Ms Amelia
How are you today?
Good Day Dear, I'm Ms Amelia and am new here looking for a serious relationship with someone i can spend the rest of my life with, someone who is loving, caring, honest and faithful to spend the rest of my life with, i came across your profile and its very interesting to me and i would like to know more about you to see if this will work out for both of us...Kindly reply me to know more about each other better. Here is my email address ( mis.ameliahal...@gmail.com ) Love Ms Amelia
Re: [PATCH 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
On Sat, 01 Dec 2018, Jonathan Cameron wrote: > On Wed, 28 Nov 2018 09:14:32 + > Lee Jones wrote: > > > On Mon, 19 Nov 2018, Vignesh R wrote: > > > > > When performing single ended measurements with TSCADC, its recommended > > > to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the > > > corresponding STEP_CONFIGx register. > > > Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0) > > > reference voltage for ADC step needs to be set to VREFP and VREFN > > > respectively in STEP_CONFIGx register. > > > Without these changes, there may be variation of as much as ~2% in the > > > ADC's digital output which is bad for precise measurement. > > > > > > Signed-off-by: Vignesh R > > > --- > > > drivers/iio/adc/ti_am335x_adc.c | 5 - > > > > > include/linux/mfd/ti_am335x_tscadc.h | 4 > > > > Acked-by: Lee Jones > > > I'll leave this for v2 given changes in the first patch. > > My assumption is at the moment that both will go through mfd. > Shout Lee if you have other plans. I'm fine with that. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
On Sat, 01 Dec 2018, Jonathan Cameron wrote: > On Wed, 28 Nov 2018 09:14:32 + > Lee Jones wrote: > > > On Mon, 19 Nov 2018, Vignesh R wrote: > > > > > When performing single ended measurements with TSCADC, its recommended > > > to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the > > > corresponding STEP_CONFIGx register. > > > Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0) > > > reference voltage for ADC step needs to be set to VREFP and VREFN > > > respectively in STEP_CONFIGx register. > > > Without these changes, there may be variation of as much as ~2% in the > > > ADC's digital output which is bad for precise measurement. > > > > > > Signed-off-by: Vignesh R > > > --- > > > drivers/iio/adc/ti_am335x_adc.c | 5 - > > > > > include/linux/mfd/ti_am335x_tscadc.h | 4 > > > > Acked-by: Lee Jones > > > I'll leave this for v2 given changes in the first patch. > > My assumption is at the moment that both will go through mfd. > Shout Lee if you have other plans. I'm fine with that. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
linux-next: build failure after merge of the akpm tree
Hi Andrew, After merging the akpm tree, today's linux-next build (powerpc_le perf) failed like this: bench/numa.c:37:10: fatal error: linux/numa.h: No such file or directory #include ^~ Caused by patches "mm: replace all open encodings for NUMA_NO_NODE" "mm-replace-all-open-encodings-for-numa_no_node-fix" For linux/numa.h to be generally availble to the tools builds, it must be copied into tools/include/linux ... I have done that copy for today: From 6dabc11d5513510d0ec0a6b0a4aa8b9051b71516 Mon Sep 17 00:00:00 2001 From: Stephen Rothwell Date: Mon, 3 Dec 2018 17:57:27 +1100 Subject: [PATCH] linux/numa.h is now needed for the perf build Signed-off-by: Stephen Rothwell --- tools/include/linux/numa.h | 16 1 file changed, 16 insertions(+) create mode 100644 tools/include/linux/numa.h diff --git a/tools/include/linux/numa.h b/tools/include/linux/numa.h new file mode 100644 index ..110b0e5d0fb0 --- /dev/null +++ b/tools/include/linux/numa.h @@ -0,0 +1,16 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _LINUX_NUMA_H +#define _LINUX_NUMA_H + + +#ifdef CONFIG_NODES_SHIFT +#define NODES_SHIFT CONFIG_NODES_SHIFT +#else +#define NODES_SHIFT 0 +#endif + +#define MAX_NUMNODES(1 << NODES_SHIFT) + +#defineNUMA_NO_NODE(-1) + +#endif /* _LINUX_NUMA_H */ -- 2.19.1 -- Cheers, Stephen Rothwell pgp_cz06gl83p.pgp Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm tree
Hi Andrew, After merging the akpm tree, today's linux-next build (powerpc_le perf) failed like this: bench/numa.c:37:10: fatal error: linux/numa.h: No such file or directory #include ^~ Caused by patches "mm: replace all open encodings for NUMA_NO_NODE" "mm-replace-all-open-encodings-for-numa_no_node-fix" For linux/numa.h to be generally availble to the tools builds, it must be copied into tools/include/linux ... I have done that copy for today: From 6dabc11d5513510d0ec0a6b0a4aa8b9051b71516 Mon Sep 17 00:00:00 2001 From: Stephen Rothwell Date: Mon, 3 Dec 2018 17:57:27 +1100 Subject: [PATCH] linux/numa.h is now needed for the perf build Signed-off-by: Stephen Rothwell --- tools/include/linux/numa.h | 16 1 file changed, 16 insertions(+) create mode 100644 tools/include/linux/numa.h diff --git a/tools/include/linux/numa.h b/tools/include/linux/numa.h new file mode 100644 index ..110b0e5d0fb0 --- /dev/null +++ b/tools/include/linux/numa.h @@ -0,0 +1,16 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _LINUX_NUMA_H +#define _LINUX_NUMA_H + + +#ifdef CONFIG_NODES_SHIFT +#define NODES_SHIFT CONFIG_NODES_SHIFT +#else +#define NODES_SHIFT 0 +#endif + +#define MAX_NUMNODES(1 << NODES_SHIFT) + +#defineNUMA_NO_NODE(-1) + +#endif /* _LINUX_NUMA_H */ -- 2.19.1 -- Cheers, Stephen Rothwell pgp_cz06gl83p.pgp Description: OpenPGP digital signature
Re: [PATCH V2 3/5] PM / Domains: Save OPP table pointer in genpd
On 30-11-18, 09:53, Ulf Hansson wrote: > On Mon, 26 Nov 2018 at 09:10, Viresh Kumar wrote: > > > > We will need these going forward in hotpath, i.e. from within > > dev_pm_genpd_set_performance_state(). > > Well, as for patch2, please try to be a bit more descriptive of why > and what this patch does. PM / Domains: Save OPP table pointer in genpd dev_pm_genpd_set_performance_state() will be required to call dev_pm_opp_xlate_performance_state() going forward to translate from performance state of a sub-domain to performance state of its master. And dev_pm_opp_xlate_performance_state() needs pointers to the OPP tables of both genpd and its master. Lets fetch and save them while the OPP tables are added. Fetching the OPP tables should never fail as we just added the OPP tables and so add a WARN_ON() for such a bug instead of full error paths. Signed-off-by: Viresh Kumar Good enough ? -- viresh
Re: [PATCH V2 3/5] PM / Domains: Save OPP table pointer in genpd
On 30-11-18, 09:53, Ulf Hansson wrote: > On Mon, 26 Nov 2018 at 09:10, Viresh Kumar wrote: > > > > We will need these going forward in hotpath, i.e. from within > > dev_pm_genpd_set_performance_state(). > > Well, as for patch2, please try to be a bit more descriptive of why > and what this patch does. PM / Domains: Save OPP table pointer in genpd dev_pm_genpd_set_performance_state() will be required to call dev_pm_opp_xlate_performance_state() going forward to translate from performance state of a sub-domain to performance state of its master. And dev_pm_opp_xlate_performance_state() needs pointers to the OPP tables of both genpd and its master. Lets fetch and save them while the OPP tables are added. Fetching the OPP tables should never fail as we just added the OPP tables and so add a WARN_ON() for such a bug instead of full error paths. Signed-off-by: Viresh Kumar Good enough ? -- viresh
Re: [PATCH 4.19.6] BFS: static inode bitmap and extra sanity checking
On Sun, Dec 02, 2018 at 08:21:30PM +, Tigran Aivazian wrote: > On Sun, 2 Dec 2018 at 20:13, Greg KH wrote: > > What is the git commit id of this patch in Linus's tree? > > In linux-next the commit id is > d2e6681167c634cfc3558991b59a6f614a31d226 , but it is not in Linus' > tree (i.e. at github.com/torvalds/linux) yet. It went into Andrew > Morton's "-mm" tree and then into "linux-next" tree. Please take a look at: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to get a patch into the stable tree. The patch needs to be in Linus's tree first, linux-next does not count, sorry. thanks, greg k-h
Re: [PATCH 4.19.6] BFS: static inode bitmap and extra sanity checking
On Sun, Dec 02, 2018 at 08:21:30PM +, Tigran Aivazian wrote: > On Sun, 2 Dec 2018 at 20:13, Greg KH wrote: > > What is the git commit id of this patch in Linus's tree? > > In linux-next the commit id is > d2e6681167c634cfc3558991b59a6f614a31d226 , but it is not in Linus' > tree (i.e. at github.com/torvalds/linux) yet. It went into Andrew > Morton's "-mm" tree and then into "linux-next" tree. Please take a look at: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to get a patch into the stable tree. The patch needs to be in Linus's tree first, linux-next does not count, sorry. thanks, greg k-h
[PATCH 1/2] HID: use macros in IS_INPUT_APPLICATION
Add missing definition for HID_DG_WHITEBOARD then replace the hid
usage hex with macros for better readibility.
Signed-off-by: Chris Chiu
---
include/linux/hid.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index a355d61940f2..ce5f996c8d3d 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -238,6 +238,7 @@ struct hid_item {
#define HID_DG_LIGHTPEN0x000d0003
#define HID_DG_TOUCHSCREEN 0x000d0004
#define HID_DG_TOUCHPAD0x000d0005
+#define HID_DG_WHITEBOARD 0x000d0006
#define HID_DG_STYLUS 0x000d0020
#define HID_DG_PUCK0x000d0021
#define HID_DG_FINGER 0x000d0022
@@ -836,7 +837,10 @@ static inline bool hid_is_using_ll_driver(struct
hid_device *hdev,
/* Applications from HID Usage Tables 4/8/99 Version 1.1 */
/* We ignore a few input applications that are not widely used */
-#define IS_INPUT_APPLICATION(a) (((a >= 0x0001) && (a <= 0x00010008)) ||
(a == 0x00010080) || (a == 0x000c0001) || ((a >= 0x000d0002) && (a <=
0x000d0006)))
+#define IS_INPUT_APPLICATION(a) \
+ (((a >= HID_UP_GENDESK) && (a <= HID_GD_MULTIAXIS)) \
+ || ((a >= HID_DG_PEN) && (a <= HID_DG_WHITEBOARD)) \
+ || (a == HID_GD_SYSTEM_CONTROL) || (a ==
HID_CP_CONSUMER_CONTROL))
/* HID core API */
--
2.19.1
[PATCH 2/2] HID: input: support Microsoft wireless radio control hotkey
The ASUS laptops start to support the airplane mode radio management to replace the original mechanism of airplane mode toggle hotkey. On the ASUS P5440FF, it presents as a HID device connecting via I2C, named i2c-AMPD0001. When pressing it, the Embedded Controller send hid report via I2C and switch the airplane mode indicator LED based on the status. However, it's not working because it fails to be identified as a hidinput device. It fails in hidinput_connect() due to the macro IS_INPUT_APPLICATION doesn't have HID_GD_WIRELESS_RADIO_CTLS as a legit application code. It's easy to add the HID I2C vendor and product id to the quirk list and apply HID_QUIRK_HIDINPUT_FORCE to make it work. But it makes more sense to support it as a generic input application. Signed-off-by: Chris Chiu --- include/linux/hid.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/hid.h b/include/linux/hid.h index ce5f996c8d3d..42079116fb61 100644 --- a/include/linux/hid.h +++ b/include/linux/hid.h @@ -840,7 +840,8 @@ static inline bool hid_is_using_ll_driver(struct hid_device *hdev, #define IS_INPUT_APPLICATION(a) \ (((a >= HID_UP_GENDESK) && (a <= HID_GD_MULTIAXIS)) \ || ((a >= HID_DG_PEN) && (a <= HID_DG_WHITEBOARD)) \ - || (a == HID_GD_SYSTEM_CONTROL) || (a == HID_CP_CONSUMER_CONTROL)) + || (a == HID_GD_SYSTEM_CONTROL) || (a == HID_CP_CONSUMER_CONTROL) \ + || (a == HID_GD_WIRELESS_RADIO_CTLS)) /* HID core API */ -- 2.19.1
[PATCH 1/2] HID: use macros in IS_INPUT_APPLICATION
Add missing definition for HID_DG_WHITEBOARD then replace the hid
usage hex with macros for better readibility.
Signed-off-by: Chris Chiu
---
include/linux/hid.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index a355d61940f2..ce5f996c8d3d 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -238,6 +238,7 @@ struct hid_item {
#define HID_DG_LIGHTPEN0x000d0003
#define HID_DG_TOUCHSCREEN 0x000d0004
#define HID_DG_TOUCHPAD0x000d0005
+#define HID_DG_WHITEBOARD 0x000d0006
#define HID_DG_STYLUS 0x000d0020
#define HID_DG_PUCK0x000d0021
#define HID_DG_FINGER 0x000d0022
@@ -836,7 +837,10 @@ static inline bool hid_is_using_ll_driver(struct
hid_device *hdev,
/* Applications from HID Usage Tables 4/8/99 Version 1.1 */
/* We ignore a few input applications that are not widely used */
-#define IS_INPUT_APPLICATION(a) (((a >= 0x0001) && (a <= 0x00010008)) ||
(a == 0x00010080) || (a == 0x000c0001) || ((a >= 0x000d0002) && (a <=
0x000d0006)))
+#define IS_INPUT_APPLICATION(a) \
+ (((a >= HID_UP_GENDESK) && (a <= HID_GD_MULTIAXIS)) \
+ || ((a >= HID_DG_PEN) && (a <= HID_DG_WHITEBOARD)) \
+ || (a == HID_GD_SYSTEM_CONTROL) || (a ==
HID_CP_CONSUMER_CONTROL))
/* HID core API */
--
2.19.1
[PATCH 2/2] HID: input: support Microsoft wireless radio control hotkey
The ASUS laptops start to support the airplane mode radio management to replace the original mechanism of airplane mode toggle hotkey. On the ASUS P5440FF, it presents as a HID device connecting via I2C, named i2c-AMPD0001. When pressing it, the Embedded Controller send hid report via I2C and switch the airplane mode indicator LED based on the status. However, it's not working because it fails to be identified as a hidinput device. It fails in hidinput_connect() due to the macro IS_INPUT_APPLICATION doesn't have HID_GD_WIRELESS_RADIO_CTLS as a legit application code. It's easy to add the HID I2C vendor and product id to the quirk list and apply HID_QUIRK_HIDINPUT_FORCE to make it work. But it makes more sense to support it as a generic input application. Signed-off-by: Chris Chiu --- include/linux/hid.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/hid.h b/include/linux/hid.h index ce5f996c8d3d..42079116fb61 100644 --- a/include/linux/hid.h +++ b/include/linux/hid.h @@ -840,7 +840,8 @@ static inline bool hid_is_using_ll_driver(struct hid_device *hdev, #define IS_INPUT_APPLICATION(a) \ (((a >= HID_UP_GENDESK) && (a <= HID_GD_MULTIAXIS)) \ || ((a >= HID_DG_PEN) && (a <= HID_DG_WHITEBOARD)) \ - || (a == HID_GD_SYSTEM_CONTROL) || (a == HID_CP_CONSUMER_CONTROL)) + || (a == HID_GD_SYSTEM_CONTROL) || (a == HID_CP_CONSUMER_CONTROL) \ + || (a == HID_GD_WIRELESS_RADIO_CTLS)) /* HID core API */ -- 2.19.1
Re: [PATCH] scsi: megaraid_sas: NULL check before some freeing functions is not needed
On Wed, Nov 28, 2018 at 1:36 PM Wen Yang wrote:
>
> dma_pool_destroy(NULL) is safe, so removes NULL check before freeing
> the mem. This patch also fix the ifnullfree.cocci warnings.
>
> Signed-off-by: Wen Yang
Acked-by: Sumit Saxena
> CC: Julia Lawall
> CC: Kashyap Desai
> CC: Sumit Saxena
> CC: Shivasharan S
> CC: linux-kernel@vger.kernel.org
> ---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index f74b5ea24f0f..aa477f09a7a5 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -807,10 +807,8 @@ megasas_free_rdpq_fusion(struct megasas_instance
> *instance) {
>
> }
>
> - if (fusion->reply_frames_desc_pool)
> - dma_pool_destroy(fusion->reply_frames_desc_pool);
> - if (fusion->reply_frames_desc_pool_align)
> - dma_pool_destroy(fusion->reply_frames_desc_pool_align);
> + dma_pool_destroy(fusion->reply_frames_desc_pool);
> + dma_pool_destroy(fusion->reply_frames_desc_pool_align);
>
> if (fusion->rdpq_virt)
> dma_free_coherent(>pdev->dev,
> @@ -830,8 +828,7 @@ megasas_free_reply_fusion(struct megasas_instance
> *instance) {
> fusion->reply_frames_desc[0],
> fusion->reply_frames_desc_phys[0]);
>
> - if (fusion->reply_frames_desc_pool)
> - dma_pool_destroy(fusion->reply_frames_desc_pool);
> + dma_pool_destroy(fusion->reply_frames_desc_pool);
>
> }
>
> @@ -1627,8 +1624,7 @@ static inline void megasas_free_ioc_init_cmd(struct
> megasas_instance *instance)
> fusion->ioc_init_cmd->frame,
> fusion->ioc_init_cmd->frame_phys_addr);
>
> - if (fusion->ioc_init_cmd)
> - kfree(fusion->ioc_init_cmd);
> + kfree(fusion->ioc_init_cmd);
> }
>
> /**
> --
> 2.19.1
>
Re: [PATCH] scsi: megaraid_sas: NULL check before some freeing functions is not needed
On Wed, Nov 28, 2018 at 1:36 PM Wen Yang wrote:
>
> dma_pool_destroy(NULL) is safe, so removes NULL check before freeing
> the mem. This patch also fix the ifnullfree.cocci warnings.
>
> Signed-off-by: Wen Yang
Acked-by: Sumit Saxena
> CC: Julia Lawall
> CC: Kashyap Desai
> CC: Sumit Saxena
> CC: Shivasharan S
> CC: linux-kernel@vger.kernel.org
> ---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index f74b5ea24f0f..aa477f09a7a5 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -807,10 +807,8 @@ megasas_free_rdpq_fusion(struct megasas_instance
> *instance) {
>
> }
>
> - if (fusion->reply_frames_desc_pool)
> - dma_pool_destroy(fusion->reply_frames_desc_pool);
> - if (fusion->reply_frames_desc_pool_align)
> - dma_pool_destroy(fusion->reply_frames_desc_pool_align);
> + dma_pool_destroy(fusion->reply_frames_desc_pool);
> + dma_pool_destroy(fusion->reply_frames_desc_pool_align);
>
> if (fusion->rdpq_virt)
> dma_free_coherent(>pdev->dev,
> @@ -830,8 +828,7 @@ megasas_free_reply_fusion(struct megasas_instance
> *instance) {
> fusion->reply_frames_desc[0],
> fusion->reply_frames_desc_phys[0]);
>
> - if (fusion->reply_frames_desc_pool)
> - dma_pool_destroy(fusion->reply_frames_desc_pool);
> + dma_pool_destroy(fusion->reply_frames_desc_pool);
>
> }
>
> @@ -1627,8 +1624,7 @@ static inline void megasas_free_ioc_init_cmd(struct
> megasas_instance *instance)
> fusion->ioc_init_cmd->frame,
> fusion->ioc_init_cmd->frame_phys_addr);
>
> - if (fusion->ioc_init_cmd)
> - kfree(fusion->ioc_init_cmd);
> + kfree(fusion->ioc_init_cmd);
> }
>
> /**
> --
> 2.19.1
>
Re: [PATCH V2 2/5] OPP: Add dev_pm_opp_xlate_performance_state() helper
On 30-11-18, 09:45, Ulf Hansson wrote: > On Mon, 26 Nov 2018 at 09:10, Viresh Kumar wrote: > > > > Introduce a new helper dev_pm_opp_xlate_performance_state() which will > > be used to translate from pstate of a device to another one. > > I don't get this, could you please elaborate? > > > > > Initially this will be used by genpd to find pstate of a master domain > > using its sub-domain's pstate. > > I assume pstate is the performance state of a genpd that you refer to, > no? Please try to be a bit more descriptive in your changelogs, to > avoid confusions. Here is the new changelog: OPP: Add dev_pm_opp_xlate_performance_state() helper dev_pm_genpd_set_performance_state() needs to handle performance state propagation going forward. Currently this routine only gets the required performance state of the device's genpd as an argument, but it doesn't know how to translate that to master genpd(s) of the device's genpd. Introduce a new helper dev_pm_opp_xlate_performance_state() which will be used to translate from performance state of a device (or genpd sub-domain) to another device (or master genpd). Normally the src_table (of genpd sub-domain) will have the "required_opps" property set to point to one of the OPPs in the dst_table (of master genpd), but in some cases the genpd and its master have one to one mapping of performance states and so none of them have the "required-opps" property set. Return the performance state of the src_table as it is in such cases. Signed-off-by: Viresh Kumar Hope this looks fine ? -- viresh
Re: [PATCH V2 2/5] OPP: Add dev_pm_opp_xlate_performance_state() helper
On 30-11-18, 09:45, Ulf Hansson wrote: > On Mon, 26 Nov 2018 at 09:10, Viresh Kumar wrote: > > > > Introduce a new helper dev_pm_opp_xlate_performance_state() which will > > be used to translate from pstate of a device to another one. > > I don't get this, could you please elaborate? > > > > > Initially this will be used by genpd to find pstate of a master domain > > using its sub-domain's pstate. > > I assume pstate is the performance state of a genpd that you refer to, > no? Please try to be a bit more descriptive in your changelogs, to > avoid confusions. Here is the new changelog: OPP: Add dev_pm_opp_xlate_performance_state() helper dev_pm_genpd_set_performance_state() needs to handle performance state propagation going forward. Currently this routine only gets the required performance state of the device's genpd as an argument, but it doesn't know how to translate that to master genpd(s) of the device's genpd. Introduce a new helper dev_pm_opp_xlate_performance_state() which will be used to translate from performance state of a device (or genpd sub-domain) to another device (or master genpd). Normally the src_table (of genpd sub-domain) will have the "required_opps" property set to point to one of the OPPs in the dst_table (of master genpd), but in some cases the genpd and its master have one to one mapping of performance states and so none of them have the "required-opps" property set. Return the performance state of the src_table as it is in such cases. Signed-off-by: Viresh Kumar Hope this looks fine ? -- viresh
Re: [PATCH] percpu_rwsem: fix missed wakeup due to reordering of load
On 2018-11-30 07:10, Prateek Sood wrote: In a scenario where cpu_hotplug_lock percpu_rw_semaphore is already acquired for read operation by P1 using percpu_down_read(). Now we have P1 in the path of releaseing the cpu_hotplug_lock and P2 is in the process of acquiring cpu_hotplug_lock. P1 P2 percpu_up_read() path percpu_down_write() path rcu_sync_enter() //gp_state=GP_PASSED rcu_sync_is_idle() //returns falsedown_write(rw_sem) __percpu_up_read() [L] task = rcu_dereference(w->task) //NULL smp_rmb() [S] w->task = current smp_mb() [L] readers_active_check() //fails schedule() [S] __this_cpu_dec(read_count) Since load of task can result in NULL. This can lead to missed wakeup in rcuwait_wake_up(). Above sequence violated the following constraint in rcuwait_wake_up(): WAITWAKE [S] tsk = current [S] cond = true MB (A) MB (B) [L] cond [L] tsk Hmm yeah we don't want rcu_wake_up() to get hoisted over the __this_cpu_dec(read_count). The smp_rmb() does not make sense to me here in the first place. Did you run into this scenario by code inspection or you actually it the issue? Thanks, Davidlohr
Re: [PATCH] percpu_rwsem: fix missed wakeup due to reordering of load
On 2018-11-30 07:10, Prateek Sood wrote: In a scenario where cpu_hotplug_lock percpu_rw_semaphore is already acquired for read operation by P1 using percpu_down_read(). Now we have P1 in the path of releaseing the cpu_hotplug_lock and P2 is in the process of acquiring cpu_hotplug_lock. P1 P2 percpu_up_read() path percpu_down_write() path rcu_sync_enter() //gp_state=GP_PASSED rcu_sync_is_idle() //returns falsedown_write(rw_sem) __percpu_up_read() [L] task = rcu_dereference(w->task) //NULL smp_rmb() [S] w->task = current smp_mb() [L] readers_active_check() //fails schedule() [S] __this_cpu_dec(read_count) Since load of task can result in NULL. This can lead to missed wakeup in rcuwait_wake_up(). Above sequence violated the following constraint in rcuwait_wake_up(): WAITWAKE [S] tsk = current [S] cond = true MB (A) MB (B) [L] cond [L] tsk Hmm yeah we don't want rcu_wake_up() to get hoisted over the __this_cpu_dec(read_count). The smp_rmb() does not make sense to me here in the first place. Did you run into this scenario by code inspection or you actually it the issue? Thanks, Davidlohr
[PATCH v2] mailbox: Hi3660: Fixup mailbox state machine malfunction issue
Current mailbox driver of Hi3660 release the mailbox directly
before sending a new message which may cause last message lost
and next message sending doesn't take effect actually.
This patch fixes this issue by following the right process below,
each time before sending a message, mailbox driver will check
whether the mailbox is in ready state, if last message has been
acknowledged, mailbox driver will clear the ack state to turn
the mailbox to ready state again.
Signed-off-by: Kevin Wangtao
---
Changes v1 -> v2:
- update commit message
drivers/mailbox/hi3660-mailbox.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/mailbox/hi3660-mailbox.c b/drivers/mailbox/hi3660-mailbox.c
index 3eea6b6..035b71a 100644
--- a/drivers/mailbox/hi3660-mailbox.c
+++ b/drivers/mailbox/hi3660-mailbox.c
@@ -38,6 +38,7 @@
#define MBOX_AUTOMATIC_ACK 1
#define MBOX_STATE_IDLEBIT(4)
+#define MBOX_STATE_READY BIT(5)
#define MBOX_STATE_ACK BIT(7)
#define MBOX_MSG_LEN 8
@@ -91,8 +92,8 @@ static int hi3660_mbox_check_state(struct mbox_chan *chan)
unsigned long val;
unsigned int ret;
- /* Mailbox is idle so directly bail out */
- if (readl(base + MBOX_MODE_REG) & MBOX_STATE_IDLE)
+ /* Mailbox is ready to use */
+ if (readl(base + MBOX_MODE_REG) & MBOX_STATE_READY)
return 0;
/* Wait for acknowledge from remote */
@@ -103,9 +104,9 @@ static int hi3660_mbox_check_state(struct mbox_chan *chan)
return ret;
}
- /* Ensure channel is released */
- writel(0x, base + MBOX_IMASK_REG);
- writel(BIT(mchan->ack_irq), base + MBOX_SRC_REG);
+ /* clear ack state, mailbox will get back to ready state */
+ writel(BIT(mchan->ack_irq), base + MBOX_ICLR_REG);
+
return 0;
}
@@ -160,10 +161,6 @@ static int hi3660_mbox_startup(struct mbox_chan *chan)
{
int ret;
- ret = hi3660_mbox_check_state(chan);
- if (ret)
- return ret;
-
ret = hi3660_mbox_unlock(chan);
if (ret)
return ret;
@@ -183,10 +180,11 @@ static int hi3660_mbox_send_data(struct mbox_chan *chan,
void *msg)
void __iomem *base = MBOX_BASE(mbox, ch);
u32 *buf = msg;
unsigned int i;
+ int ret;
- /* Ensure channel is released */
- writel_relaxed(0x, base + MBOX_IMASK_REG);
- writel_relaxed(BIT(mchan->ack_irq), base + MBOX_SRC_REG);
+ ret = hi3660_mbox_check_state(chan);
+ if (ret)
+ return ret;
/* Clear mask for destination interrupt */
writel_relaxed(~BIT(mchan->dst_irq), base + MBOX_IMASK_REG);
--
2.8.1
[PATCH v2] mailbox: Hi3660: Fixup mailbox state machine malfunction issue
Current mailbox driver of Hi3660 release the mailbox directly
before sending a new message which may cause last message lost
and next message sending doesn't take effect actually.
This patch fixes this issue by following the right process below,
each time before sending a message, mailbox driver will check
whether the mailbox is in ready state, if last message has been
acknowledged, mailbox driver will clear the ack state to turn
the mailbox to ready state again.
Signed-off-by: Kevin Wangtao
---
Changes v1 -> v2:
- update commit message
drivers/mailbox/hi3660-mailbox.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/mailbox/hi3660-mailbox.c b/drivers/mailbox/hi3660-mailbox.c
index 3eea6b6..035b71a 100644
--- a/drivers/mailbox/hi3660-mailbox.c
+++ b/drivers/mailbox/hi3660-mailbox.c
@@ -38,6 +38,7 @@
#define MBOX_AUTOMATIC_ACK 1
#define MBOX_STATE_IDLEBIT(4)
+#define MBOX_STATE_READY BIT(5)
#define MBOX_STATE_ACK BIT(7)
#define MBOX_MSG_LEN 8
@@ -91,8 +92,8 @@ static int hi3660_mbox_check_state(struct mbox_chan *chan)
unsigned long val;
unsigned int ret;
- /* Mailbox is idle so directly bail out */
- if (readl(base + MBOX_MODE_REG) & MBOX_STATE_IDLE)
+ /* Mailbox is ready to use */
+ if (readl(base + MBOX_MODE_REG) & MBOX_STATE_READY)
return 0;
/* Wait for acknowledge from remote */
@@ -103,9 +104,9 @@ static int hi3660_mbox_check_state(struct mbox_chan *chan)
return ret;
}
- /* Ensure channel is released */
- writel(0x, base + MBOX_IMASK_REG);
- writel(BIT(mchan->ack_irq), base + MBOX_SRC_REG);
+ /* clear ack state, mailbox will get back to ready state */
+ writel(BIT(mchan->ack_irq), base + MBOX_ICLR_REG);
+
return 0;
}
@@ -160,10 +161,6 @@ static int hi3660_mbox_startup(struct mbox_chan *chan)
{
int ret;
- ret = hi3660_mbox_check_state(chan);
- if (ret)
- return ret;
-
ret = hi3660_mbox_unlock(chan);
if (ret)
return ret;
@@ -183,10 +180,11 @@ static int hi3660_mbox_send_data(struct mbox_chan *chan,
void *msg)
void __iomem *base = MBOX_BASE(mbox, ch);
u32 *buf = msg;
unsigned int i;
+ int ret;
- /* Ensure channel is released */
- writel_relaxed(0x, base + MBOX_IMASK_REG);
- writel_relaxed(BIT(mchan->ack_irq), base + MBOX_SRC_REG);
+ ret = hi3660_mbox_check_state(chan);
+ if (ret)
+ return ret;
/* Clear mask for destination interrupt */
writel_relaxed(~BIT(mchan->dst_irq), base + MBOX_IMASK_REG);
--
2.8.1
[GIT] IDE
A missing of_node_put() and a small cleanup. Please pull, thanks! The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7: Linux 4.20-rc5 (2018-12-02 15:07:55 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git for you to fetch changes up to 94d0fb159da94cb4522e14d6004bb7acf2ff0387: ide: Change to use DEFINE_SHOW_ATTRIBUTE macro (2018-12-02 22:09:09 -0800) Yangtao Li (2): ide: pmac: add of_node_put() ide: Change to use DEFINE_SHOW_ATTRIBUTE macro drivers/ide/ide-proc.c | 15 ++- drivers/ide/pmac.c | 1 + 2 files changed, 3 insertions(+), 13 deletions(-)
[GIT] IDE
A missing of_node_put() and a small cleanup. Please pull, thanks! The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7: Linux 4.20-rc5 (2018-12-02 15:07:55 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git for you to fetch changes up to 94d0fb159da94cb4522e14d6004bb7acf2ff0387: ide: Change to use DEFINE_SHOW_ATTRIBUTE macro (2018-12-02 22:09:09 -0800) Yangtao Li (2): ide: pmac: add of_node_put() ide: Change to use DEFINE_SHOW_ATTRIBUTE macro drivers/ide/ide-proc.c | 15 ++- drivers/ide/pmac.c | 1 + 2 files changed, 3 insertions(+), 13 deletions(-)
Re: [PATCH v2 1/9] mm: Introduce new vm_insert_range API
On Mon, Dec 03, 2018 at 09:51:45AM +0530, Souptick Joarder wrote:
> Hi Mike,
>
> On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
> >
> > On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > > Previouly drivers have their own way of mapping range of
> > > kernel pages/memory into user vma and this was done by
> > > invoking vm_insert_page() within a loop.
> > >
> > > As this pattern is common across different drivers, it can
> > > be generalized by creating a new function and use it across
> > > the drivers.
> > >
> > > vm_insert_range is the new API which will be used to map a
> > > range of kernel memory/pages to user vma.
> > >
> > > This API is tested by Heiko for Rockchip drm driver, on rk3188,
> > > rk3288, rk3328 and rk3399 with graphics.
> > >
> > > Signed-off-by: Souptick Joarder
> > > Reviewed-by: Matthew Wilcox
> > > Tested-by: Heiko Stuebner
> > > ---
> > > include/linux/mm_types.h | 3 +++
> > > mm/memory.c | 38 ++
> > > mm/nommu.c | 7 +++
> > > 3 files changed, 48 insertions(+)
> > >
> > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > > index 5ed8f62..15ae24f 100644
> > > --- a/include/linux/mm_types.h
> > > +++ b/include/linux/mm_types.h
> > > @@ -523,6 +523,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb,
> > > struct mm_struct *mm,
> > > extern void tlb_finish_mmu(struct mmu_gather *tlb,
> > > unsigned long start, unsigned long end);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count);
> > > +
> >
> > This seem to belong to include/linux/mm.h, near vm_insert_page()
>
> Ok, I will change it. Apart from this change does it looks good ?
With this change you can add
Reviewed-by: Mike Rapoport
> >
> > > static inline void init_tlb_flush_pending(struct mm_struct *mm)
> > > {
> > > atomic_set(>tlb_flush_pending, 0);
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 15c417e..84ea46c 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > >
> > > /**
> > > + * vm_insert_range - insert range of kernel pages into user vma
> > > + * @vma: user vma to map to
> > > + * @addr: target user address of this page
> > > + * @pages: pointer to array of source kernel pages
> > > + * @page_count: number of pages need to insert into user vma
> > > + *
> > > + * This allows drivers to insert range of kernel pages they've allocated
> > > + * into a user vma. This is a generic function which drivers can use
> > > + * rather than using their own way of mapping range of kernel pages into
> > > + * user vma.
> > > + *
> > > + * If we fail to insert any page into the vma, the function will return
> > > + * immediately leaving any previously-inserted pages present. Callers
> > > + * from the mmap handler may immediately return the error as their caller
> > > + * will destroy the vma, removing any successfully-inserted pages. Other
> > > + * callers should make their own arrangements for calling unmap_region().
> > > + *
> > > + * Context: Process context. Called by mmap handlers.
> > > + * Return: 0 on success and error code otherwise
> > > + */
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + unsigned long uaddr = addr;
> > > + int ret = 0, i;
> > > +
> > > + for (i = 0; i < page_count; i++) {
> > > + ret = vm_insert_page(vma, uaddr, pages[i]);
> > > + if (ret < 0)
> > > + return ret;
> > > + uaddr += PAGE_SIZE;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > +/**
> > > * vm_insert_page - insert single page into user vma
> > > * @vma: user vma to map to
> > > * @addr: target user address of this page
> > > diff --git a/mm/nommu.c b/mm/nommu.c
> > > index 749276b..d6ef5c7 100644
> > > --- a/mm/nommu.c
> > > +++ b/mm/nommu.c
> > > @@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > > EXPORT_SYMBOL(vm_insert_page);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + return -EINVAL;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > /*
> > > * sys_brk() for the most part doesn't need the global kernel
> > > * lock, except when an application is doing something nasty
> > > --
> > > 1.9.1
> > >
> >
> > --
> > Sincerely yours,
> > Mike.
> >
>
--
Sincerely yours,
Mike.
Re: [PATCH v2 1/9] mm: Introduce new vm_insert_range API
On Mon, Dec 03, 2018 at 09:51:45AM +0530, Souptick Joarder wrote:
> Hi Mike,
>
> On Sun, Dec 2, 2018 at 4:43 PM Mike Rapoport wrote:
> >
> > On Sun, Dec 02, 2018 at 11:49:44AM +0530, Souptick Joarder wrote:
> > > Previouly drivers have their own way of mapping range of
> > > kernel pages/memory into user vma and this was done by
> > > invoking vm_insert_page() within a loop.
> > >
> > > As this pattern is common across different drivers, it can
> > > be generalized by creating a new function and use it across
> > > the drivers.
> > >
> > > vm_insert_range is the new API which will be used to map a
> > > range of kernel memory/pages to user vma.
> > >
> > > This API is tested by Heiko for Rockchip drm driver, on rk3188,
> > > rk3288, rk3328 and rk3399 with graphics.
> > >
> > > Signed-off-by: Souptick Joarder
> > > Reviewed-by: Matthew Wilcox
> > > Tested-by: Heiko Stuebner
> > > ---
> > > include/linux/mm_types.h | 3 +++
> > > mm/memory.c | 38 ++
> > > mm/nommu.c | 7 +++
> > > 3 files changed, 48 insertions(+)
> > >
> > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > > index 5ed8f62..15ae24f 100644
> > > --- a/include/linux/mm_types.h
> > > +++ b/include/linux/mm_types.h
> > > @@ -523,6 +523,9 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb,
> > > struct mm_struct *mm,
> > > extern void tlb_finish_mmu(struct mmu_gather *tlb,
> > > unsigned long start, unsigned long end);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count);
> > > +
> >
> > This seem to belong to include/linux/mm.h, near vm_insert_page()
>
> Ok, I will change it. Apart from this change does it looks good ?
With this change you can add
Reviewed-by: Mike Rapoport
> >
> > > static inline void init_tlb_flush_pending(struct mm_struct *mm)
> > > {
> > > atomic_set(>tlb_flush_pending, 0);
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 15c417e..84ea46c 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > >
> > > /**
> > > + * vm_insert_range - insert range of kernel pages into user vma
> > > + * @vma: user vma to map to
> > > + * @addr: target user address of this page
> > > + * @pages: pointer to array of source kernel pages
> > > + * @page_count: number of pages need to insert into user vma
> > > + *
> > > + * This allows drivers to insert range of kernel pages they've allocated
> > > + * into a user vma. This is a generic function which drivers can use
> > > + * rather than using their own way of mapping range of kernel pages into
> > > + * user vma.
> > > + *
> > > + * If we fail to insert any page into the vma, the function will return
> > > + * immediately leaving any previously-inserted pages present. Callers
> > > + * from the mmap handler may immediately return the error as their caller
> > > + * will destroy the vma, removing any successfully-inserted pages. Other
> > > + * callers should make their own arrangements for calling unmap_region().
> > > + *
> > > + * Context: Process context. Called by mmap handlers.
> > > + * Return: 0 on success and error code otherwise
> > > + */
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + unsigned long uaddr = addr;
> > > + int ret = 0, i;
> > > +
> > > + for (i = 0; i < page_count; i++) {
> > > + ret = vm_insert_page(vma, uaddr, pages[i]);
> > > + if (ret < 0)
> > > + return ret;
> > > + uaddr += PAGE_SIZE;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > +/**
> > > * vm_insert_page - insert single page into user vma
> > > * @vma: user vma to map to
> > > * @addr: target user address of this page
> > > diff --git a/mm/nommu.c b/mm/nommu.c
> > > index 749276b..d6ef5c7 100644
> > > --- a/mm/nommu.c
> > > +++ b/mm/nommu.c
> > > @@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma,
> > > unsigned long addr,
> > > }
> > > EXPORT_SYMBOL(vm_insert_page);
> > >
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + return -EINVAL;
> > > +}
> > > +EXPORT_SYMBOL(vm_insert_range);
> > > +
> > > /*
> > > * sys_brk() for the most part doesn't need the global kernel
> > > * lock, except when an application is doing something nasty
> > > --
> > > 1.9.1
> > >
> >
> > --
> > Sincerely yours,
> > Mike.
> >
>
--
Sincerely yours,
Mike.
Re: [PATCH] Uprobes: Fix kernel oops with delayed_uprobe_remove()
Hi Steve, Please pull this patch. Thanks. On 11/15/18 6:13 PM, Oleg Nesterov wrote: > On 11/15, Ravi Bangoria wrote: >> >> There could be a race between task exit and probe unregister: >> >> exit_mm() >> mmput() >> __mmput() uprobe_unregister() >> uprobe_clear_state() put_uprobe() >> delayed_uprobe_remove() delayed_uprobe_remove() >> >> put_uprobe() is calling delayed_uprobe_remove() without taking >> delayed_uprobe_lock and thus the race sometimes results in a >> kernel crash. Fix this by taking delayed_uprobe_lock before >> calling delayed_uprobe_remove() from put_uprobe(). >> >> Detailed crash log can be found at: >> https://lkml.org/lkml/2018/11/1/1244 > > Thanks, looks good, > > Oleg. >
[PATCH] udlfb: fix potential NULL pointer dereference in dlfb_usb_probe
This patch fixes a possible null pointer dereference in
dlfb_usb_probe, detected by the semantic patch deref_null.cocci,
with the following warning:
drivers/video/fbdev/udlfb.c:1704:11-15: ERROR: dlfb is NULL but dereferenced.
The following code has potential null pointer references:
1597 /* usb initialization */
1598 dlfb = kzalloc(sizeof(*dlfb), GFP_KERNEL);
1599 if (!dlfb) {
...
1601 goto error;
1602 }
...
1703 error:
1704 if (dlfb->info) {
1705 dlfb_ops_destroy(dlfb->info);
1706 } else if (dlfb) {
1707 usb_put_dev(dlfb->udev);
1708 kfree(dlfb);
1709 }
Signed-off-by: Wen Yang
CC: Bernie Thompson
CC: Bartlomiej Zolnierkiewicz
CC: linux-fb...@vger.kernel.org
CC: dri-de...@lists.freedesktop.org
CC: linux-kernel@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 070026a7e55a..df37cfaa2362 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1701,7 +1701,7 @@ static int dlfb_usb_probe(struct usb_interface *intf,
return 0;
error:
- if (dlfb->info) {
+ if (dlfb && dlfb->info) {
dlfb_ops_destroy(dlfb->info);
} else if (dlfb) {
usb_put_dev(dlfb->udev);
--
2.19.1
Re: [PATCH] Uprobes: Fix kernel oops with delayed_uprobe_remove()
Hi Steve, Please pull this patch. Thanks. On 11/15/18 6:13 PM, Oleg Nesterov wrote: > On 11/15, Ravi Bangoria wrote: >> >> There could be a race between task exit and probe unregister: >> >> exit_mm() >> mmput() >> __mmput() uprobe_unregister() >> uprobe_clear_state() put_uprobe() >> delayed_uprobe_remove() delayed_uprobe_remove() >> >> put_uprobe() is calling delayed_uprobe_remove() without taking >> delayed_uprobe_lock and thus the race sometimes results in a >> kernel crash. Fix this by taking delayed_uprobe_lock before >> calling delayed_uprobe_remove() from put_uprobe(). >> >> Detailed crash log can be found at: >> https://lkml.org/lkml/2018/11/1/1244 > > Thanks, looks good, > > Oleg. >
[PATCH] udlfb: fix potential NULL pointer dereference in dlfb_usb_probe
This patch fixes a possible null pointer dereference in
dlfb_usb_probe, detected by the semantic patch deref_null.cocci,
with the following warning:
drivers/video/fbdev/udlfb.c:1704:11-15: ERROR: dlfb is NULL but dereferenced.
The following code has potential null pointer references:
1597 /* usb initialization */
1598 dlfb = kzalloc(sizeof(*dlfb), GFP_KERNEL);
1599 if (!dlfb) {
...
1601 goto error;
1602 }
...
1703 error:
1704 if (dlfb->info) {
1705 dlfb_ops_destroy(dlfb->info);
1706 } else if (dlfb) {
1707 usb_put_dev(dlfb->udev);
1708 kfree(dlfb);
1709 }
Signed-off-by: Wen Yang
CC: Bernie Thompson
CC: Bartlomiej Zolnierkiewicz
CC: linux-fb...@vger.kernel.org
CC: dri-de...@lists.freedesktop.org
CC: linux-kernel@vger.kernel.org
---
drivers/video/fbdev/udlfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 070026a7e55a..df37cfaa2362 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1701,7 +1701,7 @@ static int dlfb_usb_probe(struct usb_interface *intf,
return 0;
error:
- if (dlfb->info) {
+ if (dlfb && dlfb->info) {
dlfb_ops_destroy(dlfb->info);
} else if (dlfb) {
usb_put_dev(dlfb->udev);
--
2.19.1
Re: [PATCH v4 7/7] cgroup: document cgroup v2 freezer interface
On Fri, Nov 30, 2018 at 03:47:45PM -0800, Roman Gushchin wrote: > Describe cgroup v2 freezer interface in the cgroup v2 admin guide. > > Signed-off-by: Roman Gushchin > Cc: Tejun Heo > Cc: linux-...@vger.kernel.org > Cc: kernel-t...@fb.com Reviewed-by: Mike Rapoport > --- > Documentation/admin-guide/cgroup-v2.rst | 27 + > 1 file changed, 27 insertions(+) > > diff --git a/Documentation/admin-guide/cgroup-v2.rst > b/Documentation/admin-guide/cgroup-v2.rst > index 07e06136a550..f8335e26b362 100644 > --- a/Documentation/admin-guide/cgroup-v2.rst > +++ b/Documentation/admin-guide/cgroup-v2.rst > @@ -864,6 +864,8 @@ All cgroup core files are prefixed with "cgroup." > populated > 1 if the cgroup or its descendants contains any live > processes; otherwise, 0. > + frozen > + 1 if the cgroup is frozen; otherwise, 0. > >cgroup.max.descendants > A read-write single value files. The default is "max". > @@ -897,6 +899,31 @@ All cgroup core files are prefixed with "cgroup." > A dying cgroup can consume system resources not exceeding > limits, which were active at the moment of cgroup deletion. > > + cgroup.freeze > + A read-write single value file which exists on non-root cgroups. > + Allowed values are "0" and "1". The default is "0". > + > + Writing "1" to the file causes freezing of the cgroup and all > + descendant cgroups. This means that all belonging processes will > + be stopped and will not run until the cgroup will be explicitly > + unfrozen. Freezing of the cgroup may take some time; when this action > + is completed, the "frozen" value in the cgroup.events control file > + will be updated to "1" and the corresponding notification will be > + issued. > + > + A cgroup can be frozen either by its own settings, or by settings > + of any ancestor cgroups. If any of ancestor cgroups is frozen, the > + cgroup will remain frozen. > + > + Processes in the frozen cgroup can be killed by a fatal signal. > + They also can enter and leave a frozen cgroup: either by an explicit > + move by a user, or if freezing of the cgroup races with fork(). > + If a process is moved to a frozen cgroup, it stops. If a process is > + moved out of a frozen cgroup, it becomes running. > + > + Frozen status of a cgroup doesn't affect any cgroup tree operations: > + it's possible to delete a frozen (and empty) cgroup, as well as > + create new sub-cgroups. > > Controllers > === > -- > 2.17.2 > -- Sincerely yours, Mike.
Re: [PATCH v4 7/7] cgroup: document cgroup v2 freezer interface
On Fri, Nov 30, 2018 at 03:47:45PM -0800, Roman Gushchin wrote: > Describe cgroup v2 freezer interface in the cgroup v2 admin guide. > > Signed-off-by: Roman Gushchin > Cc: Tejun Heo > Cc: linux-...@vger.kernel.org > Cc: kernel-t...@fb.com Reviewed-by: Mike Rapoport > --- > Documentation/admin-guide/cgroup-v2.rst | 27 + > 1 file changed, 27 insertions(+) > > diff --git a/Documentation/admin-guide/cgroup-v2.rst > b/Documentation/admin-guide/cgroup-v2.rst > index 07e06136a550..f8335e26b362 100644 > --- a/Documentation/admin-guide/cgroup-v2.rst > +++ b/Documentation/admin-guide/cgroup-v2.rst > @@ -864,6 +864,8 @@ All cgroup core files are prefixed with "cgroup." > populated > 1 if the cgroup or its descendants contains any live > processes; otherwise, 0. > + frozen > + 1 if the cgroup is frozen; otherwise, 0. > >cgroup.max.descendants > A read-write single value files. The default is "max". > @@ -897,6 +899,31 @@ All cgroup core files are prefixed with "cgroup." > A dying cgroup can consume system resources not exceeding > limits, which were active at the moment of cgroup deletion. > > + cgroup.freeze > + A read-write single value file which exists on non-root cgroups. > + Allowed values are "0" and "1". The default is "0". > + > + Writing "1" to the file causes freezing of the cgroup and all > + descendant cgroups. This means that all belonging processes will > + be stopped and will not run until the cgroup will be explicitly > + unfrozen. Freezing of the cgroup may take some time; when this action > + is completed, the "frozen" value in the cgroup.events control file > + will be updated to "1" and the corresponding notification will be > + issued. > + > + A cgroup can be frozen either by its own settings, or by settings > + of any ancestor cgroups. If any of ancestor cgroups is frozen, the > + cgroup will remain frozen. > + > + Processes in the frozen cgroup can be killed by a fatal signal. > + They also can enter and leave a frozen cgroup: either by an explicit > + move by a user, or if freezing of the cgroup races with fork(). > + If a process is moved to a frozen cgroup, it stops. If a process is > + moved out of a frozen cgroup, it becomes running. > + > + Frozen status of a cgroup doesn't affect any cgroup tree operations: > + it's possible to delete a frozen (and empty) cgroup, as well as > + create new sub-cgroups. > > Controllers > === > -- > 2.17.2 > -- Sincerely yours, Mike.
[PATCH 1/2] dt-bindings: interrupt-controller: New binding for Meson-G12A SoC
Update the dt-binding document to support new compatible string for the GPIO interrupt controller which found in Amlogic's Meson-G12A SoC. Signed-off-by: Xingyu Chen Signed-off-by: Jianxin Pan --- .../bindings/interrupt-controller/amlogic,meson-gpio-intc.txt| 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt index 1502a51548bb..7d531d5fff29 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt @@ -15,6 +15,7 @@ Required properties: "amlogic,meson-gxbb-gpio-intc" for GXBB SoCs (S905) or "amlogic,meson-gxl-gpio-intc" for GXL SoCs (S905X, S912) "amlogic,meson-axg-gpio-intc" for AXG SoCs (A113D, A113X) +"amlogic,meson-g12a-gpio-intc" for G12A SoCs (S905D2, S905X2, S905Y2) - reg : Specifies base physical address and size of the registers. - interrupt-controller : Identifies the node as an interrupt controller. - #interrupt-cells : Specifies the number of cells needed to encode an -- 2.19.2
[PATCH 2/2] irqchip/meson-gpio: Add support for Meson-G12A SoC
The Meson-G12A SoC uses the same GPIO interrupt controller IP block as the
other Meson SoCs, A totle of 100 pins can be spied on, which is the sum of:
- 223:100 undefined (no interrupt)
- 99:97 3 pins on bank GPIOE
- 96:77 20 pins on bank GPIOX
- 76:61 16 pins on bank GPIOA
- 60:53 8 pins on bank GPIOC
- 52:37 16 pins on bank BOOT
- 36:28 9 pins on bank GPIOH
- 27:12 16 pins on bank GPIOZ
- 11:012 pins in the AO domain
Signed-off-by: Xingyu Chen
Signed-off-by: Jianxin Pan
---
drivers/irqchip/irq-meson-gpio.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/irqchip/irq-meson-gpio.c b/drivers/irqchip/irq-meson-gpio.c
index 7b531fd075b8..971e8dea069a 100644
--- a/drivers/irqchip/irq-meson-gpio.c
+++ b/drivers/irqchip/irq-meson-gpio.c
@@ -67,12 +67,17 @@ static const struct meson_gpio_irq_params axg_params = {
.nr_hwirq = 100,
};
+static const struct meson_gpio_irq_params g12a_params = {
+ .nr_hwirq = 100,
+};
+
static const struct of_device_id meson_irq_gpio_matches[] = {
{ .compatible = "amlogic,meson8-gpio-intc", .data = _params },
{ .compatible = "amlogic,meson8b-gpio-intc", .data = _params },
{ .compatible = "amlogic,meson-gxbb-gpio-intc", .data = _params },
{ .compatible = "amlogic,meson-gxl-gpio-intc", .data = _params },
{ .compatible = "amlogic,meson-axg-gpio-intc", .data = _params },
+ { .compatible = "amlogic,meson-g12a-gpio-intc", .data = _params },
{ }
};
--
2.19.2
[PATCH 1/2] dt-bindings: interrupt-controller: New binding for Meson-G12A SoC
Update the dt-binding document to support new compatible string for the GPIO interrupt controller which found in Amlogic's Meson-G12A SoC. Signed-off-by: Xingyu Chen Signed-off-by: Jianxin Pan --- .../bindings/interrupt-controller/amlogic,meson-gpio-intc.txt| 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt index 1502a51548bb..7d531d5fff29 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt @@ -15,6 +15,7 @@ Required properties: "amlogic,meson-gxbb-gpio-intc" for GXBB SoCs (S905) or "amlogic,meson-gxl-gpio-intc" for GXL SoCs (S905X, S912) "amlogic,meson-axg-gpio-intc" for AXG SoCs (A113D, A113X) +"amlogic,meson-g12a-gpio-intc" for G12A SoCs (S905D2, S905X2, S905Y2) - reg : Specifies base physical address and size of the registers. - interrupt-controller : Identifies the node as an interrupt controller. - #interrupt-cells : Specifies the number of cells needed to encode an -- 2.19.2
[PATCH 2/2] irqchip/meson-gpio: Add support for Meson-G12A SoC
The Meson-G12A SoC uses the same GPIO interrupt controller IP block as the
other Meson SoCs, A totle of 100 pins can be spied on, which is the sum of:
- 223:100 undefined (no interrupt)
- 99:97 3 pins on bank GPIOE
- 96:77 20 pins on bank GPIOX
- 76:61 16 pins on bank GPIOA
- 60:53 8 pins on bank GPIOC
- 52:37 16 pins on bank BOOT
- 36:28 9 pins on bank GPIOH
- 27:12 16 pins on bank GPIOZ
- 11:012 pins in the AO domain
Signed-off-by: Xingyu Chen
Signed-off-by: Jianxin Pan
---
drivers/irqchip/irq-meson-gpio.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/irqchip/irq-meson-gpio.c b/drivers/irqchip/irq-meson-gpio.c
index 7b531fd075b8..971e8dea069a 100644
--- a/drivers/irqchip/irq-meson-gpio.c
+++ b/drivers/irqchip/irq-meson-gpio.c
@@ -67,12 +67,17 @@ static const struct meson_gpio_irq_params axg_params = {
.nr_hwirq = 100,
};
+static const struct meson_gpio_irq_params g12a_params = {
+ .nr_hwirq = 100,
+};
+
static const struct of_device_id meson_irq_gpio_matches[] = {
{ .compatible = "amlogic,meson8-gpio-intc", .data = _params },
{ .compatible = "amlogic,meson8b-gpio-intc", .data = _params },
{ .compatible = "amlogic,meson-gxbb-gpio-intc", .data = _params },
{ .compatible = "amlogic,meson-gxl-gpio-intc", .data = _params },
{ .compatible = "amlogic,meson-axg-gpio-intc", .data = _params },
+ { .compatible = "amlogic,meson-g12a-gpio-intc", .data = _params },
{ }
};
--
2.19.2
[PATCH 0/2] irqchip/meson-gpio: Add support for Meson-G12A SoC
This series try to add GPIO interrupt controller support for Meson-G12A SoCs. Although the total number of pins is the same as the Meson-AXG SoC, the gpio banks and irq numbers are different. To avoid confusion on use, i think the new compatible string is needed. Xingyu Chen (2): dt-bindings: interrupt-controller: New binding for Meson-G12A SoC irqchip/meson-gpio: Add support for Meson-G12A SoC .../interrupt-controller/amlogic,meson-gpio-intc.txt | 1 + drivers/irqchip/irq-meson-gpio.c | 5 + 2 files changed, 6 insertions(+) -- 2.19.2
[PATCH 0/2] irqchip/meson-gpio: Add support for Meson-G12A SoC
This series try to add GPIO interrupt controller support for Meson-G12A SoCs. Although the total number of pins is the same as the Meson-AXG SoC, the gpio banks and irq numbers are different. To avoid confusion on use, i think the new compatible string is needed. Xingyu Chen (2): dt-bindings: interrupt-controller: New binding for Meson-G12A SoC irqchip/meson-gpio: Add support for Meson-G12A SoC .../interrupt-controller/amlogic,meson-gpio-intc.txt | 1 + drivers/irqchip/irq-meson-gpio.c | 5 + 2 files changed, 6 insertions(+) -- 2.19.2
Re: [PATCH v4 7/7] zram: writeback throttle
On (12/03/18 15:02), Sergey Senozhatsky wrote: > Seems like I misread writeback_limit_store() a bit. > > So, if I want to, say, let only 10M of writteback pages, I need to > do > > echo 0 > writeback_limit > echo 10M > writeback_limit_store// memparse format is for > // simplicity only; I know > // it should be in 4K units. > > every day. How about dropping the "echo 0" and ->stop_writeback? Ah, this breaks the unlimited writeback. So, nevermind my comment. -ss
Re: [PATCH v4 7/7] zram: writeback throttle
On (12/03/18 15:02), Sergey Senozhatsky wrote: > Seems like I misread writeback_limit_store() a bit. > > So, if I want to, say, let only 10M of writteback pages, I need to > do > > echo 0 > writeback_limit > echo 10M > writeback_limit_store// memparse format is for > // simplicity only; I know > // it should be in 4K units. > > every day. How about dropping the "echo 0" and ->stop_writeback? Ah, this breaks the unlimited writeback. So, nevermind my comment. -ss
Re: [PATCH] Malformatted switch statment
From: Joris Gutjahr Date: Sun, 28 Oct 2018 17:45:46 +0100 > I fixed this coding style error I got after running > checkpatch --file on this file. > The problem was that the whole case block was on one line. > > Signed-off-by: Joris Gutjahr Frankly I think the existing code is more compact and easier to read and understand. Checkpatch is a tool, and it's results need be interpreated and evaluated by human beings. It's not to be taken as the final verdict. I'm not applying this, sorry.
Re: [PATCH] Malformatted switch statment
From: Joris Gutjahr Date: Sun, 28 Oct 2018 17:45:46 +0100 > I fixed this coding style error I got after running > checkpatch --file on this file. > The problem was that the whole case block was on one line. > > Signed-off-by: Joris Gutjahr Frankly I think the existing code is more compact and easier to read and understand. Checkpatch is a tool, and it's results need be interpreated and evaluated by human beings. It's not to be taken as the final verdict. I'm not applying this, sorry.
Re: [PATCH v4 7/7] zram: writeback throttle
On (12/03/18 14:50), Sergey Senozhatsky wrote:
> On (12/03/18 11:40), Minchan Kim wrote:
> [..]
> > + down_read(>init_lock);
> > + atomic64_set(>stats.bd_wb_limit, val);
> > + if (val == 0)
> > + zram->stop_writeback = false;
> > + up_read(>init_lock);
>
> [..]
>
> > + if (zram->stop_writeback) {
> > + ret = -EIO;
> > + break;
> > + }
> > +
> > if (!blk_idx) {
> > blk_idx = alloc_block_bdev(zram);
> > if (!blk_idx) {
> > @@ -694,6 +732,11 @@ static ssize_t writeback_store(struct device *dev,
> > zram_set_element(zram, index, blk_idx);
> > blk_idx = 0;
> > atomic64_inc(>stats.pages_stored);
> > + if (atomic64_add_unless(>stats.bd_wb_limit,
> > + -1 << (PAGE_SHIFT - 12), 0)) {
> > + if (atomic64_read(>stats.bd_wb_limit) == 0)
> > + zram->stop_writeback = true;
> > + }
>
> Do we need ->stop_writeback? It should be identical to
>
> atomic64_read(>stats.bd_wb_limit) == 0
Seems like I misread writeback_limit_store() a bit.
So, if I want to, say, let only 10M of writteback pages, I need to
do
echo 0 > writeback_limit
echo 10M > writeback_limit_store// memparse format is for
// simplicity only; I know
// it should be in 4K units.
every day. How about dropping the "echo 0" and ->stop_writeback?
So then we can just do
echo 10M > writeback_limit_store
every day: if we have ->bd_wb_limit budget then we writeback,
otherwise we don't.
-ss
Re: [PATCH v4 7/7] zram: writeback throttle
On (12/03/18 14:50), Sergey Senozhatsky wrote:
> On (12/03/18 11:40), Minchan Kim wrote:
> [..]
> > + down_read(>init_lock);
> > + atomic64_set(>stats.bd_wb_limit, val);
> > + if (val == 0)
> > + zram->stop_writeback = false;
> > + up_read(>init_lock);
>
> [..]
>
> > + if (zram->stop_writeback) {
> > + ret = -EIO;
> > + break;
> > + }
> > +
> > if (!blk_idx) {
> > blk_idx = alloc_block_bdev(zram);
> > if (!blk_idx) {
> > @@ -694,6 +732,11 @@ static ssize_t writeback_store(struct device *dev,
> > zram_set_element(zram, index, blk_idx);
> > blk_idx = 0;
> > atomic64_inc(>stats.pages_stored);
> > + if (atomic64_add_unless(>stats.bd_wb_limit,
> > + -1 << (PAGE_SHIFT - 12), 0)) {
> > + if (atomic64_read(>stats.bd_wb_limit) == 0)
> > + zram->stop_writeback = true;
> > + }
>
> Do we need ->stop_writeback? It should be identical to
>
> atomic64_read(>stats.bd_wb_limit) == 0
Seems like I misread writeback_limit_store() a bit.
So, if I want to, say, let only 10M of writteback pages, I need to
do
echo 0 > writeback_limit
echo 10M > writeback_limit_store// memparse format is for
// simplicity only; I know
// it should be in 4K units.
every day. How about dropping the "echo 0" and ->stop_writeback?
So then we can just do
echo 10M > writeback_limit_store
every day: if we have ->bd_wb_limit budget then we writeback,
otherwise we don't.
-ss
RE: [PATCH] scsi: qedf: NULL check before some freeing functions is not needed.
> -Original Message- > From: Thomas Meyer > Sent: Monday, December 3, 2018 2:22 AM > To: Dept-Eng QLogic Storage Upstream upstr...@cavium.com>; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH] scsi: qedf: NULL check before some freeing functions is not > needed. > > External Email > > NULL check before some freeing functions is not needed. > > Signed-off-by: Thomas Meyer > --- > > diff -u -p a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c > --- a/drivers/scsi/qedf/qedf_main.c > +++ b/drivers/scsi/qedf/qedf_main.c > @@ -2935,8 +2935,7 @@ static void qedf_free_fcoe_pf_param(stru > > qedf_free_global_queues(qedf); > > - if (qedf->global_queues) > - kfree(qedf->global_queues); > + kfree(qedf->global_queues); > } > > /* Thanks Acked-by: Manish Rangankar
RE: [PATCH] scsi: qedf: NULL check before some freeing functions is not needed.
> -Original Message- > From: Thomas Meyer > Sent: Monday, December 3, 2018 2:22 AM > To: Dept-Eng QLogic Storage Upstream upstr...@cavium.com>; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: [PATCH] scsi: qedf: NULL check before some freeing functions is not > needed. > > External Email > > NULL check before some freeing functions is not needed. > > Signed-off-by: Thomas Meyer > --- > > diff -u -p a/drivers/scsi/qedf/qedf_main.c b/drivers/scsi/qedf/qedf_main.c > --- a/drivers/scsi/qedf/qedf_main.c > +++ b/drivers/scsi/qedf/qedf_main.c > @@ -2935,8 +2935,7 @@ static void qedf_free_fcoe_pf_param(stru > > qedf_free_global_queues(qedf); > > - if (qedf->global_queues) > - kfree(qedf->global_queues); > + kfree(qedf->global_queues); > } > > /* Thanks Acked-by: Manish Rangankar
[PATCH v5 1/3] thermal: tegra: remove unnecessary warnings
Convert warnings to info as not all platforms may
have all the thresholds and sensors enabled.
Signed-off-by: Wei Ni
---
drivers/thermal/tegra/soctherm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index ed28110a3535..f07de8258e93 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -569,7 +569,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
set_throttle:
ret = get_hot_temp(tz, , );
if (ret) {
- dev_warn(dev, "throttrip: %s: missing hot temperature\n",
+ dev_info(dev, "throttrip: %s: missing hot temperature\n",
sg->name);
return 0;
}
@@ -600,7 +600,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
}
if (i == THROTTLE_SIZE)
- dev_warn(dev, "throttrip: %s: missing throttle cdev\n",
+ dev_info(dev, "throttrip: %s: missing throttle cdev\n",
sg->name);
return 0;
--
2.7.4
[PATCH] igb: Fix an issue that PME is not enabled during runtime suspend
I210 ethernet card doesn't wakeup when a cable gets plugged. It's
because its PME is not set.
Since commit 42eca2302146 ("PCI: Don't touch card regs after runtime
suspend D3"), if the PCI state is saved, pci_pm_runtime_suspend() stops
calling pci_finish_runtime_suspend(), which enables the PCI PME.
To fix the issue, let's not to save PCI states when it's runtime
suspend, to let the PCI subsytem enables PME.
Fixes: 42eca2302146 ("PCI: Don't touch card regs after runtime suspend D3")
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/intel/igb/igb_main.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 5df88ad8ac81..93f150784cfc 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -8770,9 +8770,11 @@ static int __igb_shutdown(struct pci_dev *pdev, bool
*enable_wake,
rtnl_unlock();
#ifdef CONFIG_PM
- retval = pci_save_state(pdev);
- if (retval)
- return retval;
+ if (!runtime) {
+ retval = pci_save_state(pdev);
+ if (retval)
+ return retval;
+ }
#endif
status = rd32(E1000_STATUS);
--
2.17.1
[PATCH v5 3/3] thermal: tegra: parse sensor id before sensor register
Since different platforms may not support all 4
sensors, so the sensor registration may be failed.
Add codes to parse dt to find sensor id which
need to be registered. So that the registration
can be successful on all platform.
Signed-off-by: Wei Ni
---
drivers/thermal/tegra/soctherm.c | 45 ++--
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index fd2703c0cfc5..45e3ae8aac86 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -1224,6 +1224,41 @@ static void soctherm_init(struct platform_device *pdev)
tegra_soctherm_throttle(>dev);
}
+static bool tegra_soctherm_find_sensor_id(unsigned int sensor_id)
+{
+ bool ret = false;
+ struct of_phandle_args sensor_specs;
+ struct device_node *np, *sensor_np;
+
+ np = of_find_node_by_name(NULL, "thermal-zones");
+ if (!np)
+ return ret;
+
+ for_each_available_child_of_node(np, sensor_np) {
+ if (of_parse_phandle_with_args(sensor_np, "thermal-sensors",
+"#thermal-sensor-cells",
+0, _specs))
+ continue;
+
+ if (sensor_specs.args_count != 1) {
+ WARN(sensor_specs.args_count != 1,
+"%s: wrong cells in sensor specifier %d\n",
+sensor_specs.np->name, sensor_specs.args_count);
+ continue;
+ }
+
+ if (sensor_specs.args[0] == sensor_id) {
+ ret = true;
+ break;
+ }
+ }
+
+ of_node_put(np);
+ of_node_put(sensor_np);
+
+ return ret;
+}
+
static const struct of_device_id tegra_soctherm_of_match[] = {
#ifdef CONFIG_ARCH_TEGRA_124_SOC
{
@@ -1365,13 +1400,16 @@ static int tegra_soctherm_probe(struct platform_device
*pdev)
zone->sg = soc->ttgs[i];
zone->ts = tegra;
+ if (!tegra_soctherm_find_sensor_id(soc->ttgs[i]->id))
+ continue;
+
z = devm_thermal_zone_of_sensor_register(>dev,
soc->ttgs[i]->id, zone,
_of_thermal_ops);
if (IS_ERR(z)) {
err = PTR_ERR(z);
- dev_err(>dev, "failed to register sensor: %d\n",
- err);
+ dev_err(>dev, "failed to register sensor %s:
%d\n",
+ soc->ttgs[i]->name, err);
goto disable_clocks;
}
@@ -1434,6 +1472,9 @@ static int __maybe_unused soctherm_resume(struct device
*dev)
struct thermal_zone_device *tz;
tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
+ if (!tz)
+ continue;
+
err = tegra_soctherm_set_hwtrips(dev, soc->ttgs[i], tz);
if (err) {
dev_err(>dev,
--
2.7.4
[PATCH v5 2/3] thermal: tegra: fix memory allocation
Fix memory allocation to store the pointers to thermal_zone_device. Signed-off-by: Wei Ni Acked-by: Thierry Reding --- drivers/thermal/tegra/soctherm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c index f07de8258e93..fd2703c0cfc5 100644 --- a/drivers/thermal/tegra/soctherm.c +++ b/drivers/thermal/tegra/soctherm.c @@ -1339,7 +1339,7 @@ static int tegra_soctherm_probe(struct platform_device *pdev) } tegra->thermctl_tzs = devm_kcalloc(>dev, - soc->num_ttgs, sizeof(*z), + soc->num_ttgs, sizeof(z), GFP_KERNEL); if (!tegra->thermctl_tzs) return -ENOMEM; -- 2.7.4
[PATCH v5 0/3] Fixes for Tegra soctherm
This series fixed some issues for Tegra soctherm Main changes from v4: 1. fixed for the parsing sensor id. 2. keep warning for missing critical trips. Main changes from v3: 1. updated codes for parsing sensor id, per Thierry's comments Main changes from v2: 1. add codes to parse sensor id to avoid registration failure. Main changes from v1: 1. Acked by Thierry Reding for the patch "thermal: tegra: fix memory allocation". 2. Print out the sensor name when register failed. 2. Remove patch "thermal: tegra: fix coverity defect" Wei Ni (3): thermal: tegra: remove unnecessary warnings thermal: tegra: fix memory allocation thermal: tegra: parse sensor id before sensor register drivers/thermal/tegra/soctherm.c | 51 1 file changed, 46 insertions(+), 5 deletions(-) -- 2.7.4
[PATCH v5 1/3] thermal: tegra: remove unnecessary warnings
Convert warnings to info as not all platforms may
have all the thresholds and sensors enabled.
Signed-off-by: Wei Ni
---
drivers/thermal/tegra/soctherm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index ed28110a3535..f07de8258e93 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -569,7 +569,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
set_throttle:
ret = get_hot_temp(tz, , );
if (ret) {
- dev_warn(dev, "throttrip: %s: missing hot temperature\n",
+ dev_info(dev, "throttrip: %s: missing hot temperature\n",
sg->name);
return 0;
}
@@ -600,7 +600,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
}
if (i == THROTTLE_SIZE)
- dev_warn(dev, "throttrip: %s: missing throttle cdev\n",
+ dev_info(dev, "throttrip: %s: missing throttle cdev\n",
sg->name);
return 0;
--
2.7.4
[PATCH] igb: Fix an issue that PME is not enabled during runtime suspend
I210 ethernet card doesn't wakeup when a cable gets plugged. It's
because its PME is not set.
Since commit 42eca2302146 ("PCI: Don't touch card regs after runtime
suspend D3"), if the PCI state is saved, pci_pm_runtime_suspend() stops
calling pci_finish_runtime_suspend(), which enables the PCI PME.
To fix the issue, let's not to save PCI states when it's runtime
suspend, to let the PCI subsytem enables PME.
Fixes: 42eca2302146 ("PCI: Don't touch card regs after runtime suspend D3")
Signed-off-by: Kai-Heng Feng
---
drivers/net/ethernet/intel/igb/igb_main.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 5df88ad8ac81..93f150784cfc 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -8770,9 +8770,11 @@ static int __igb_shutdown(struct pci_dev *pdev, bool
*enable_wake,
rtnl_unlock();
#ifdef CONFIG_PM
- retval = pci_save_state(pdev);
- if (retval)
- return retval;
+ if (!runtime) {
+ retval = pci_save_state(pdev);
+ if (retval)
+ return retval;
+ }
#endif
status = rd32(E1000_STATUS);
--
2.17.1
[PATCH v5 3/3] thermal: tegra: parse sensor id before sensor register
Since different platforms may not support all 4
sensors, so the sensor registration may be failed.
Add codes to parse dt to find sensor id which
need to be registered. So that the registration
can be successful on all platform.
Signed-off-by: Wei Ni
---
drivers/thermal/tegra/soctherm.c | 45 ++--
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/tegra/soctherm.c b/drivers/thermal/tegra/soctherm.c
index fd2703c0cfc5..45e3ae8aac86 100644
--- a/drivers/thermal/tegra/soctherm.c
+++ b/drivers/thermal/tegra/soctherm.c
@@ -1224,6 +1224,41 @@ static void soctherm_init(struct platform_device *pdev)
tegra_soctherm_throttle(>dev);
}
+static bool tegra_soctherm_find_sensor_id(unsigned int sensor_id)
+{
+ bool ret = false;
+ struct of_phandle_args sensor_specs;
+ struct device_node *np, *sensor_np;
+
+ np = of_find_node_by_name(NULL, "thermal-zones");
+ if (!np)
+ return ret;
+
+ for_each_available_child_of_node(np, sensor_np) {
+ if (of_parse_phandle_with_args(sensor_np, "thermal-sensors",
+"#thermal-sensor-cells",
+0, _specs))
+ continue;
+
+ if (sensor_specs.args_count != 1) {
+ WARN(sensor_specs.args_count != 1,
+"%s: wrong cells in sensor specifier %d\n",
+sensor_specs.np->name, sensor_specs.args_count);
+ continue;
+ }
+
+ if (sensor_specs.args[0] == sensor_id) {
+ ret = true;
+ break;
+ }
+ }
+
+ of_node_put(np);
+ of_node_put(sensor_np);
+
+ return ret;
+}
+
static const struct of_device_id tegra_soctherm_of_match[] = {
#ifdef CONFIG_ARCH_TEGRA_124_SOC
{
@@ -1365,13 +1400,16 @@ static int tegra_soctherm_probe(struct platform_device
*pdev)
zone->sg = soc->ttgs[i];
zone->ts = tegra;
+ if (!tegra_soctherm_find_sensor_id(soc->ttgs[i]->id))
+ continue;
+
z = devm_thermal_zone_of_sensor_register(>dev,
soc->ttgs[i]->id, zone,
_of_thermal_ops);
if (IS_ERR(z)) {
err = PTR_ERR(z);
- dev_err(>dev, "failed to register sensor: %d\n",
- err);
+ dev_err(>dev, "failed to register sensor %s:
%d\n",
+ soc->ttgs[i]->name, err);
goto disable_clocks;
}
@@ -1434,6 +1472,9 @@ static int __maybe_unused soctherm_resume(struct device
*dev)
struct thermal_zone_device *tz;
tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
+ if (!tz)
+ continue;
+
err = tegra_soctherm_set_hwtrips(dev, soc->ttgs[i], tz);
if (err) {
dev_err(>dev,
--
2.7.4
