Re: [PATCH] HID: asus: fix build warning wiht CONFIG_ASUS_WMI disabled
On Fri, Nov 2, 2018 at 4:16 PM Arnd Bergmann wrote:
> asus_wmi_evaluate_method() is an empty dummy function when CONFIG_ASUS_WMI
> is disabled, or not reachable from a built-in device driver. This leads to
> a theoretical evaluation of an uninitialized variable that the compiler
> complains about, failing to check that the hardcoded return value makes
> this an unreachable code path:
>
> In file included from include/linux/printk.h:336,
> from include/linux/kernel.h:14,
> from include/linux/list.h:9,
> from include/linux/dmi.h:5,
> from drivers/hid/hid-asus.c:29:
> drivers/hid/hid-asus.c: In function 'asus_input_configured':
> include/linux/dynamic_debug.h:135:3: error: 'value' may be used uninitialized
> in this function [-Werror=maybe-uninitialized]
>__dynamic_dev_dbg(, dev, fmt, \
>^
> drivers/hid/hid-asus.c:359:6: note: 'value' was declared here
> u32 value;
> ^
>
> With an extra IS_ENABLED() check, the warning goes away.
>
> Fixes: 3b692c55e58d ("HID: asus: only support backlight when it's not driven
> by WMI")
> Signed-off-by: Arnd Bergmann
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] HID: asus: fix build warning wiht CONFIG_ASUS_WMI disabled
On Fri, Nov 2, 2018 at 4:16 PM Arnd Bergmann wrote:
> asus_wmi_evaluate_method() is an empty dummy function when CONFIG_ASUS_WMI
> is disabled, or not reachable from a built-in device driver. This leads to
> a theoretical evaluation of an uninitialized variable that the compiler
> complains about, failing to check that the hardcoded return value makes
> this an unreachable code path:
>
> In file included from include/linux/printk.h:336,
> from include/linux/kernel.h:14,
> from include/linux/list.h:9,
> from include/linux/dmi.h:5,
> from drivers/hid/hid-asus.c:29:
> drivers/hid/hid-asus.c: In function 'asus_input_configured':
> include/linux/dynamic_debug.h:135:3: error: 'value' may be used uninitialized
> in this function [-Werror=maybe-uninitialized]
>__dynamic_dev_dbg(, dev, fmt, \
>^
> drivers/hid/hid-asus.c:359:6: note: 'value' was declared here
> u32 value;
> ^
>
> With an extra IS_ENABLED() check, the warning goes away.
>
> Fixes: 3b692c55e58d ("HID: asus: only support backlight when it's not driven
> by WMI")
> Signed-off-by: Arnd Bergmann
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
[PATCH] ASoC: Intel: mrfld: fix uninitialized variable access
Randconfig testing revealed a very old bug, with gcc-8:
sound/soc/intel/atom/sst/sst_loader.c: In function 'sst_load_fw':
sound/soc/intel/atom/sst/sst_loader.c:357:5: error: 'fw' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
if (fw == NULL) {
^
sound/soc/intel/atom/sst/sst_loader.c:354:25: note: 'fw' was declared here
const struct firmware *fw;
We must check the return code of request_firmware() before we look at the
pointer result that may be uninitialized when the function fails.
Fixes: 9012c9544eea ("ASoC: Intel: mrfld - Add DSP load and management")
Signed-off-by: Arnd Bergmann
---
sound/soc/intel/atom/sst/sst_loader.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/intel/atom/sst/sst_loader.c
b/sound/soc/intel/atom/sst/sst_loader.c
index 27413ebae956..b8c456753f01 100644
--- a/sound/soc/intel/atom/sst/sst_loader.c
+++ b/sound/soc/intel/atom/sst/sst_loader.c
@@ -354,14 +354,14 @@ static int sst_request_fw(struct intel_sst_drv *sst)
const struct firmware *fw;
retval = request_firmware(, sst->firmware_name, sst->dev);
- if (fw == NULL) {
- dev_err(sst->dev, "fw is returning as null\n");
- return -EINVAL;
- }
if (retval) {
dev_err(sst->dev, "request fw failed %d\n", retval);
return retval;
}
+ if (fw == NULL) {
+ dev_err(sst->dev, "fw is returning as null\n");
+ return -EINVAL;
+ }
mutex_lock(>sst_lock);
retval = sst_cache_and_parse_fw(sst, fw);
mutex_unlock(>sst_lock);
--
2.18.0
[PATCH] ASoC: Intel: mrfld: fix uninitialized variable access
Randconfig testing revealed a very old bug, with gcc-8:
sound/soc/intel/atom/sst/sst_loader.c: In function 'sst_load_fw':
sound/soc/intel/atom/sst/sst_loader.c:357:5: error: 'fw' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
if (fw == NULL) {
^
sound/soc/intel/atom/sst/sst_loader.c:354:25: note: 'fw' was declared here
const struct firmware *fw;
We must check the return code of request_firmware() before we look at the
pointer result that may be uninitialized when the function fails.
Fixes: 9012c9544eea ("ASoC: Intel: mrfld - Add DSP load and management")
Signed-off-by: Arnd Bergmann
---
sound/soc/intel/atom/sst/sst_loader.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/intel/atom/sst/sst_loader.c
b/sound/soc/intel/atom/sst/sst_loader.c
index 27413ebae956..b8c456753f01 100644
--- a/sound/soc/intel/atom/sst/sst_loader.c
+++ b/sound/soc/intel/atom/sst/sst_loader.c
@@ -354,14 +354,14 @@ static int sst_request_fw(struct intel_sst_drv *sst)
const struct firmware *fw;
retval = request_firmware(, sst->firmware_name, sst->dev);
- if (fw == NULL) {
- dev_err(sst->dev, "fw is returning as null\n");
- return -EINVAL;
- }
if (retval) {
dev_err(sst->dev, "request fw failed %d\n", retval);
return retval;
}
+ if (fw == NULL) {
+ dev_err(sst->dev, "fw is returning as null\n");
+ return -EINVAL;
+ }
mutex_lock(>sst_lock);
retval = sst_cache_and_parse_fw(sst, fw);
mutex_unlock(>sst_lock);
--
2.18.0
Re: [PATCH v2 04/11] ext4 resize: lost brelse() in update_backups()
On Wed, Oct 31, 2018 at 12:58:03AM +0300, Vasily Averin wrote:
> bh was not released after error in ext4_journal_get_write_access()
>
> Fixes ac27a0ec112a ("ext4: initial copy of files from ext3") # 2.6.19
>
> Signed-off-by: Vasily Averin
Thanks, applied. I fixed up the commit description and Fixes/Cc
trailers.
- Ted
Re: [PATCH v2 04/11] ext4 resize: lost brelse() in update_backups()
On Wed, Oct 31, 2018 at 12:58:03AM +0300, Vasily Averin wrote:
> bh was not released after error in ext4_journal_get_write_access()
>
> Fixes ac27a0ec112a ("ext4: initial copy of files from ext3") # 2.6.19
>
> Signed-off-by: Vasily Averin
Thanks, applied. I fixed up the commit description and Fixes/Cc
trailers.
- Ted
Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
On Sat, Nov 03 2018, Paul E. McKenney wrote: > On Sat, Nov 03, 2018 at 07:36:19PM +1100, NeilBrown wrote: >> On Fri, Nov 02 2018, Paul E. McKenney wrote: >> >> > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote: >> >> On Thu, Nov 01 2018, Paul E. McKenney wrote: >> >> >> >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: >> >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: >> >> >> > On Wed, Oct 24 2018, Josh Triplett wrote: >> >> >> > >> >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: >> >> >> > >> On Sun, Oct 21 2018, Josh Triplett wrote: >> >> >> > >> >> >> >> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote: >> >> >> > >> >> I call on you, Greg: >> >> >> > >> >> - to abandon this divisive attempt to impose a "Code of >> >> >> > >> >> Conduct" >> >> >> > >> >> - to revert 8a104f8b5867c68 >> >> >> > >> >> - to return to your core competence of building a great team >> >> >> > >> >> around >> >> >> > >> >>a great kernel >> >> >> > >> >> >> >> >> > >> >> #Isupportreversion >> >> >> > >> >> >> >> >> > >> >> I call on the community to consider what *does* need to be >> >> >> > >> >> said, about >> >> >> > >> >> conduct, to people outside the community and who have recently >> >> >> > >> >> joined. >> >> >> > >> >> What is the document that you would have liked to have read as >> >> >> > >> >> you were >> >> >> > >> >> starting out? It is all too long ago for me to remember >> >> >> > >> >> clearly, and so >> >> >> > >> >> much has changed. >> >> >> > >> > >> >> >> > >> > The document I would have liked to have read when starting out >> >> >> > >> > is >> >> >> > >> > currently checked into the source tree in >> >> >> > >> > Documentation/process/code-of-conduct.rst . >> >> >> > >> >> >> >> > >> I'm curious - what would you have gained by reading that document? >> >> >> > > >> >> >> > > I would have then had rather less of a pervasive feeling of "if I >> >> >> > > make >> >> >> > > even a single mistake I get made an example of in ways that will >> >> >> > > feed >> >> >> > > people's quotes files for years to come". >> >> >> > >> >> >> > Thanks for your reply. Certainly feeling safe is important, and >> >> >> > having >> >> >> > clear statements that the community values and promotes psychological >> >> >> > safety is valuable. >> >> >> > >> >> >> > The old "code of conflict" said >> >> >> >If however, anyone feels personally abused, threatened, or >> >> >> > otherwise >> >> >> >uncomfortable due to this process, that is not acceptable. >> >> >> > >> >> >> > would you have not found this a strong enough statement to ward off >> >> >> > that >> >> >> > pervasive feeling? >> >> >> >> >> >> Not when that document started out effectively saying, in an elaborate >> >> >> way, "code > people". >> >> > >> >> > Interesting. >> >> > >> >> > I am curious what leads you to your "code > people" statement. Of >> >> > course, >> >> > one could argue that this does not really matter given that the code of >> >> > conflict is no longer. However, I would like to understand for future >> >> > reference, if for no other reason. >> >> > >> >> > One possibility is that you are restricting the "people" to only those >> >> > people directly contributing in one way or another. But those using the >> >> > kernel (both directly and indirectly) are important as well, and it is >> >> > exactly this group that is served by "the most robust operating system >> >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in >> >> > fact why I must reject (or rework or whatever) any patch that might >> >> > result >> >> > in too-short RCU grace periods: The needs of the patch's submitter are >> >> > quite emphatically outweighed by the needs of the kernel's many users, >> >> > and many of the various technical requirements and restrictions are in >> >> > fact proxies for the needs of these users. >> >> > >> >> > But you knew that already. >> >> > >> >> > Similarly for the Linux kernel's various code-style strictures, which >> >> > serve the surprisingly large group of people reading the kernel's code. >> >> > Including the stricture that I most love to hate, which is the one >> >> > stating that single-line do/for/if/while statements must not be enclosed >> >> > in braces, which sometimes causes me trouble when inserting debug code, >> >> > but which also makes more code fit into a window of a given size. ;-) >> >> > >> >> > But you knew that already, too. >> >> > >> >> > The maintainability requirements can be argued to mostly serve the >> >> > maintainers, but if the code becomes unmaintainable, future users >> >> > will be inconvenienced, to say the least. So even the maintainability >> >> > requirements serve the kernel's many users. >> >> > >> >> > But you also knew that already. >> >> > >> >> > So what am I missing here? >> >> > >> >> >> >> Hi Paul, >> >> thanks for contributing your
Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
On Sat, Nov 03 2018, Paul E. McKenney wrote: > On Sat, Nov 03, 2018 at 07:36:19PM +1100, NeilBrown wrote: >> On Fri, Nov 02 2018, Paul E. McKenney wrote: >> >> > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote: >> >> On Thu, Nov 01 2018, Paul E. McKenney wrote: >> >> >> >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: >> >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: >> >> >> > On Wed, Oct 24 2018, Josh Triplett wrote: >> >> >> > >> >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: >> >> >> > >> On Sun, Oct 21 2018, Josh Triplett wrote: >> >> >> > >> >> >> >> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote: >> >> >> > >> >> I call on you, Greg: >> >> >> > >> >> - to abandon this divisive attempt to impose a "Code of >> >> >> > >> >> Conduct" >> >> >> > >> >> - to revert 8a104f8b5867c68 >> >> >> > >> >> - to return to your core competence of building a great team >> >> >> > >> >> around >> >> >> > >> >>a great kernel >> >> >> > >> >> >> >> >> > >> >> #Isupportreversion >> >> >> > >> >> >> >> >> > >> >> I call on the community to consider what *does* need to be >> >> >> > >> >> said, about >> >> >> > >> >> conduct, to people outside the community and who have recently >> >> >> > >> >> joined. >> >> >> > >> >> What is the document that you would have liked to have read as >> >> >> > >> >> you were >> >> >> > >> >> starting out? It is all too long ago for me to remember >> >> >> > >> >> clearly, and so >> >> >> > >> >> much has changed. >> >> >> > >> > >> >> >> > >> > The document I would have liked to have read when starting out >> >> >> > >> > is >> >> >> > >> > currently checked into the source tree in >> >> >> > >> > Documentation/process/code-of-conduct.rst . >> >> >> > >> >> >> >> > >> I'm curious - what would you have gained by reading that document? >> >> >> > > >> >> >> > > I would have then had rather less of a pervasive feeling of "if I >> >> >> > > make >> >> >> > > even a single mistake I get made an example of in ways that will >> >> >> > > feed >> >> >> > > people's quotes files for years to come". >> >> >> > >> >> >> > Thanks for your reply. Certainly feeling safe is important, and >> >> >> > having >> >> >> > clear statements that the community values and promotes psychological >> >> >> > safety is valuable. >> >> >> > >> >> >> > The old "code of conflict" said >> >> >> >If however, anyone feels personally abused, threatened, or >> >> >> > otherwise >> >> >> >uncomfortable due to this process, that is not acceptable. >> >> >> > >> >> >> > would you have not found this a strong enough statement to ward off >> >> >> > that >> >> >> > pervasive feeling? >> >> >> >> >> >> Not when that document started out effectively saying, in an elaborate >> >> >> way, "code > people". >> >> > >> >> > Interesting. >> >> > >> >> > I am curious what leads you to your "code > people" statement. Of >> >> > course, >> >> > one could argue that this does not really matter given that the code of >> >> > conflict is no longer. However, I would like to understand for future >> >> > reference, if for no other reason. >> >> > >> >> > One possibility is that you are restricting the "people" to only those >> >> > people directly contributing in one way or another. But those using the >> >> > kernel (both directly and indirectly) are important as well, and it is >> >> > exactly this group that is served by "the most robust operating system >> >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in >> >> > fact why I must reject (or rework or whatever) any patch that might >> >> > result >> >> > in too-short RCU grace periods: The needs of the patch's submitter are >> >> > quite emphatically outweighed by the needs of the kernel's many users, >> >> > and many of the various technical requirements and restrictions are in >> >> > fact proxies for the needs of these users. >> >> > >> >> > But you knew that already. >> >> > >> >> > Similarly for the Linux kernel's various code-style strictures, which >> >> > serve the surprisingly large group of people reading the kernel's code. >> >> > Including the stricture that I most love to hate, which is the one >> >> > stating that single-line do/for/if/while statements must not be enclosed >> >> > in braces, which sometimes causes me trouble when inserting debug code, >> >> > but which also makes more code fit into a window of a given size. ;-) >> >> > >> >> > But you knew that already, too. >> >> > >> >> > The maintainability requirements can be argued to mostly serve the >> >> > maintainers, but if the code becomes unmaintainable, future users >> >> > will be inconvenienced, to say the least. So even the maintainability >> >> > requirements serve the kernel's many users. >> >> > >> >> > But you also knew that already. >> >> > >> >> > So what am I missing here? >> >> > >> >> >> >> Hi Paul, >> >> thanks for contributing your
Re: [PATCH v2 03/11] ext4 resize: brelse() cleanup in add_new_gdb_meta_bg()
On Wed, Oct 31, 2018 at 12:57:55AM +0300, Vasily Averin wrote:
> gdb_bh must be released in case of errors before update of s_group_desc
> but it must not be released after update of group descriptors
> because in this case bh can be used later.
>
> Fixes 01f795f9e0d6 ("ext4: add online resizing support for meta_bg ...") # 3.7
>
> Signed-off-by: Vasily Averin
Thanks, applied. The commit description is not accurate (I suspect it
was obsoleted when your patch for RHEL was forward ported) do I
dropped it.
I adjusted the patch summary to be:
ext4: add missing brelse() add_new_gdb_meta_bg()'s error path
The commments for the Fixes and Cc: sta...@kernel.org also apply.
- Ted
Re: [PATCH v2 03/11] ext4 resize: brelse() cleanup in add_new_gdb_meta_bg()
On Wed, Oct 31, 2018 at 12:57:55AM +0300, Vasily Averin wrote:
> gdb_bh must be released in case of errors before update of s_group_desc
> but it must not be released after update of group descriptors
> because in this case bh can be used later.
>
> Fixes 01f795f9e0d6 ("ext4: add online resizing support for meta_bg ...") # 3.7
>
> Signed-off-by: Vasily Averin
Thanks, applied. The commit description is not accurate (I suspect it
was obsoleted when your patch for RHEL was forward ported) do I
dropped it.
I adjusted the patch summary to be:
ext4: add missing brelse() add_new_gdb_meta_bg()'s error path
The commments for the Fixes and Cc: sta...@kernel.org also apply.
- Ted
Re: [PATCH v2 02/11] ext4 resize: missing brelse() after errors in set_flexbg_block_bitmap()
On Wed, Oct 31, 2018 at 12:57:45AM +0300, Vasily Averin wrote:
> Fixes 33afdcc5402d ("ext4: add a function which sets up group blocks ...") #
> 3.3
>
> Signed-off-by: Vasily Averin
Thanks, applied. I adjusted the patch summary:
ext4: add missing brelse() in set_flexbg_block_bitmap()'s error path
Also please note that properly Fixes should have a colon, and to add
Cc: sta...@kernel.org to trailer to make sure they get backported:
Fixes: 33afdcc5402d ("ext4: add a function which sets up group blocks ...")
Cc: sta...@kernel.org # 3.3
- Ted
Re: [PATCH v2 02/11] ext4 resize: missing brelse() after errors in set_flexbg_block_bitmap()
On Wed, Oct 31, 2018 at 12:57:45AM +0300, Vasily Averin wrote:
> Fixes 33afdcc5402d ("ext4: add a function which sets up group blocks ...") #
> 3.3
>
> Signed-off-by: Vasily Averin
Thanks, applied. I adjusted the patch summary:
ext4: add missing brelse() in set_flexbg_block_bitmap()'s error path
Also please note that properly Fixes should have a colon, and to add
Cc: sta...@kernel.org to trailer to make sure they get backported:
Fixes: 33afdcc5402d ("ext4: add a function which sets up group blocks ...")
Cc: sta...@kernel.org # 3.3
- Ted
Re: [PATCH v2 01/11] ext4 resise: extra brelse in setup_new_flex_group_blocks()
On Wed, Oct 31, 2018 at 12:57:37AM +0300, Vasily Averin wrote:
> currently bh is set to NULL only during first iteration of for cycle,
> then this pointer is not cleared after end of using.
> Therefore rollback after errors can lead to extra brelse(bh) call,
> decrements bh counter and later trigger an unexpected warning in __brelse()
>
> Patch moves brelse() calls in body of cycle to exclude requirement of
> brelse() call in rollback.
>
> Fixes 33afdcc5402d ("ext4: add a function which sets up group blocks ...") #
> 3.3+
>
> Signed-off-by: Vasily Averin
Thanks, applied. I addjusted the patch summary to read:
ext4: avoid potential extra brelse in setup_new_flex_group_blocks()
(Note that resise should have been spelled as "resize", by the way.)
- Ted
Re: [PATCH v2 01/11] ext4 resise: extra brelse in setup_new_flex_group_blocks()
On Wed, Oct 31, 2018 at 12:57:37AM +0300, Vasily Averin wrote:
> currently bh is set to NULL only during first iteration of for cycle,
> then this pointer is not cleared after end of using.
> Therefore rollback after errors can lead to extra brelse(bh) call,
> decrements bh counter and later trigger an unexpected warning in __brelse()
>
> Patch moves brelse() calls in body of cycle to exclude requirement of
> brelse() call in rollback.
>
> Fixes 33afdcc5402d ("ext4: add a function which sets up group blocks ...") #
> 3.3+
>
> Signed-off-by: Vasily Averin
Thanks, applied. I addjusted the patch summary to read:
ext4: avoid potential extra brelse in setup_new_flex_group_blocks()
(Note that resise should have been spelled as "resize", by the way.)
- Ted
[PATCH] Revert "kbuild: add --include-dir flag only for out-of-tree build"
This reverts commit 80463f1b7bf9f822fd3495139bcf3ef254fdca10, because it breaks the bindeb-pkg build target in the following way: ... LD [M] sound/soc/rockchip/snd-soc-rk3399-gru-sound.ko LD [M] sound/soc/rockchip/snd-soc-rockchip-pcm.ko LD [M] sound/soc/rockchip/snd-soc-rockchip-rt5645.ko LD [M] sound/soc/rockchip/snd-soc-rockchip-spdif.ko LD [M] sound/soc/sh/rcar/snd-soc-rcar.ko fakeroot -u debian/rules binary make KERNELRELEASE=4.19.0-12677-g19beffaf7a99-dirty ARCH=arm64 KBUILD_SRC= intdeb-pkg /bin/bash /home/ard/linux/scripts/package/builddeb Makefile:600: include/config/auto.conf: No such file or directory *** *** Configuration file ".config" not found! *** *** Please run some configurator (e.g. "make oldconfig" or *** "make menuconfig" or "make xconfig"). *** make[12]: *** [syncconfig] Error 1 make[11]: *** [syncconfig] Error 2 make[10]: *** [include/config/auto.conf] Error 2 make[9]: *** [__sub-make] Error 2 cp: cannot stat '/home/ard/linux/scripts/kconfig/Makefile:69: recipe for target '\''syncconfig'\'' failed'$'\n''/home/ard/linux/Makefile:544: recipe for target '\''syncconfig'\'' failed'$'\n''Makefile:640: recipe for target '\''include/config/auto.conf'\'' failed'$'\n''Makefile:15: recipe for target '\''__sub-make'\'' failed': No such file or directory /home/ard/linux/scripts/package/Makefile:83: recipe for target 'intdeb-pkg' failed make[8]: *** [intdeb-pkg] Error 1 /home/ard/linux/Makefile:1399: recipe for target 'intdeb-pkg' failed make[7]: *** [intdeb-pkg] Error 2 Makefile:152: recipe for target 'sub-make' failed make[6]: *** [sub-make] Error 2 Makefile:15: recipe for target '__sub-make' failed make[5]: *** [__sub-make] Error 2 debian/rules:7: recipe for target 'binary-arch' failed make[4]: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot -u debian/rules binary gave error exit status 2 /home/ard/linux/scripts/package/Makefile:79: recipe for target 'bindeb-pkg' failed make[3]: *** [bindeb-pkg] Error 2 /home/ard/linux/Makefile:1399: recipe for target 'bindeb-pkg' failed make[2]: *** [bindeb-pkg] Error 2 Makefile:152: recipe for target 'sub-make' failed make[1]: *** [sub-make] Error 2 Makefile:15: recipe for target '__sub-make' failed make: *** [__sub-make] Error 2 Signed-off-by: Ard Biesheuvel --- Makefile | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/Makefile b/Makefile index 9aa352b38815..f9d7af9e5146 100644 --- a/Makefile +++ b/Makefile @@ -15,9 +15,10 @@ NAME = "People's Front" PHONY := _all _all: -# Do not use make's built-in rules and variables -# (this increases performance and avoids hard-to-debug behaviour) -MAKEFLAGS += -rR +# o Do not use make's built-in rules and variables +# (this increases performance and avoids hard-to-debug behaviour); +# o Look for make include files relative to root of kernel src +MAKEFLAGS += -rR --include-dir=$(CURDIR) # Avoid funny character set dependencies unexport LC_ALL @@ -135,13 +136,6 @@ KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) \ $(if $(KBUILD_OUTPUT),, \ $(error failed to create output directory "$(saved-output)")) -# Look for make include files relative to root of kernel src -# -# This does not become effective immediately because MAKEFLAGS is re-parsed -# once after the Makefile is read. It is OK since we are going to invoke -# 'sub-make' below. -MAKEFLAGS += --include-dir=$(CURDIR) - PHONY += $(MAKECMDGOALS) sub-make $(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: sub-make -- 2.19.1
[PATCH] Revert "kbuild: add --include-dir flag only for out-of-tree build"
This reverts commit 80463f1b7bf9f822fd3495139bcf3ef254fdca10, because it breaks the bindeb-pkg build target in the following way: ... LD [M] sound/soc/rockchip/snd-soc-rk3399-gru-sound.ko LD [M] sound/soc/rockchip/snd-soc-rockchip-pcm.ko LD [M] sound/soc/rockchip/snd-soc-rockchip-rt5645.ko LD [M] sound/soc/rockchip/snd-soc-rockchip-spdif.ko LD [M] sound/soc/sh/rcar/snd-soc-rcar.ko fakeroot -u debian/rules binary make KERNELRELEASE=4.19.0-12677-g19beffaf7a99-dirty ARCH=arm64 KBUILD_SRC= intdeb-pkg /bin/bash /home/ard/linux/scripts/package/builddeb Makefile:600: include/config/auto.conf: No such file or directory *** *** Configuration file ".config" not found! *** *** Please run some configurator (e.g. "make oldconfig" or *** "make menuconfig" or "make xconfig"). *** make[12]: *** [syncconfig] Error 1 make[11]: *** [syncconfig] Error 2 make[10]: *** [include/config/auto.conf] Error 2 make[9]: *** [__sub-make] Error 2 cp: cannot stat '/home/ard/linux/scripts/kconfig/Makefile:69: recipe for target '\''syncconfig'\'' failed'$'\n''/home/ard/linux/Makefile:544: recipe for target '\''syncconfig'\'' failed'$'\n''Makefile:640: recipe for target '\''include/config/auto.conf'\'' failed'$'\n''Makefile:15: recipe for target '\''__sub-make'\'' failed': No such file or directory /home/ard/linux/scripts/package/Makefile:83: recipe for target 'intdeb-pkg' failed make[8]: *** [intdeb-pkg] Error 1 /home/ard/linux/Makefile:1399: recipe for target 'intdeb-pkg' failed make[7]: *** [intdeb-pkg] Error 2 Makefile:152: recipe for target 'sub-make' failed make[6]: *** [sub-make] Error 2 Makefile:15: recipe for target '__sub-make' failed make[5]: *** [__sub-make] Error 2 debian/rules:7: recipe for target 'binary-arch' failed make[4]: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot -u debian/rules binary gave error exit status 2 /home/ard/linux/scripts/package/Makefile:79: recipe for target 'bindeb-pkg' failed make[3]: *** [bindeb-pkg] Error 2 /home/ard/linux/Makefile:1399: recipe for target 'bindeb-pkg' failed make[2]: *** [bindeb-pkg] Error 2 Makefile:152: recipe for target 'sub-make' failed make[1]: *** [sub-make] Error 2 Makefile:15: recipe for target '__sub-make' failed make: *** [__sub-make] Error 2 Signed-off-by: Ard Biesheuvel --- Makefile | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/Makefile b/Makefile index 9aa352b38815..f9d7af9e5146 100644 --- a/Makefile +++ b/Makefile @@ -15,9 +15,10 @@ NAME = "People's Front" PHONY := _all _all: -# Do not use make's built-in rules and variables -# (this increases performance and avoids hard-to-debug behaviour) -MAKEFLAGS += -rR +# o Do not use make's built-in rules and variables +# (this increases performance and avoids hard-to-debug behaviour); +# o Look for make include files relative to root of kernel src +MAKEFLAGS += -rR --include-dir=$(CURDIR) # Avoid funny character set dependencies unexport LC_ALL @@ -135,13 +136,6 @@ KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) \ $(if $(KBUILD_OUTPUT),, \ $(error failed to create output directory "$(saved-output)")) -# Look for make include files relative to root of kernel src -# -# This does not become effective immediately because MAKEFLAGS is re-parsed -# once after the Makefile is read. It is OK since we are going to invoke -# 'sub-make' below. -MAKEFLAGS += --include-dir=$(CURDIR) - PHONY += $(MAKECMDGOALS) sub-make $(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: sub-make -- 2.19.1
Re: [PATCH] vt: Fix screen updates after CSI K sequences
On Sat, 3 Nov 2018, Samuel Holland wrote: > In d8ae72427187, start was changed to point to the character under the > cursor, instead of the beginning of the cleared area. The offset was > correctly applied when clearing the backing buffer, but not when > updating the framebuffer region. Fix this by having start point once > again to the beginning of the cleared area. There is already a slightly better fix submitted here: https://lkml.org/lkml/2018/10/23/535 Nicolas
Re: [PATCH] vt: Fix screen updates after CSI K sequences
On Sat, 3 Nov 2018, Samuel Holland wrote: > In d8ae72427187, start was changed to point to the character under the > cursor, instead of the beginning of the cleared area. The offset was > correctly applied when clearing the backing buffer, but not when > updating the framebuffer region. Fix this by having start point once > again to the beginning of the cleared area. There is already a slightly better fix submitted here: https://lkml.org/lkml/2018/10/23/535 Nicolas
Re: [PATCH 4/4] ARM: mmp/mmp2: dt: enable the clock
On Tue 2018-09-18 22:54:55, Lubomir Rintel wrote:
> The device-tree booted MMP2 needs to enable the timer clock, otherwise
> the it would stop ticking when the boot finishes.
"the it" -> "it"
> It can also use the clock rate from the clk, the non-DT boards need to
> keep using the hardcoded rates.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> + clk = of_clk_get(np, 0);
> + if (!IS_ERR(clk)) {
> + ret = clk_prepare_enable(clk);
> + if (ret)
> + goto out;
> + rate = clk_get_rate(clk) / 2;
> + } else if (cpu_is_pj4 ()) {
extra space.
> + rate = 650;
> + } else {
> + rate = 325;
> + }
> +
> irq = irq_of_parse_and_map(np, 0);
> if (!irq) {
> ret = -EINVAL;
> @@ -231,7 +239,7 @@ void __init mmp_dt_init_timer(void)
> ret = -ENOMEM;
> goto out;
> }
> - timer_init(irq);
> + timer_init(irq, rate);
> return;
> out:
> pr_err("Failed to get timer from device tree with error:%d\n", ret);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 4/4] ARM: mmp/mmp2: dt: enable the clock
On Tue 2018-09-18 22:54:55, Lubomir Rintel wrote:
> The device-tree booted MMP2 needs to enable the timer clock, otherwise
> the it would stop ticking when the boot finishes.
"the it" -> "it"
> It can also use the clock rate from the clk, the non-DT boards need to
> keep using the hardcoded rates.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> + clk = of_clk_get(np, 0);
> + if (!IS_ERR(clk)) {
> + ret = clk_prepare_enable(clk);
> + if (ret)
> + goto out;
> + rate = clk_get_rate(clk) / 2;
> + } else if (cpu_is_pj4 ()) {
extra space.
> + rate = 650;
> + } else {
> + rate = 325;
> + }
> +
> irq = irq_of_parse_and_map(np, 0);
> if (!irq) {
> ret = -EINVAL;
> @@ -231,7 +239,7 @@ void __init mmp_dt_init_timer(void)
> ret = -ENOMEM;
> goto out;
> }
> - timer_init(irq);
> + timer_init(irq, rate);
> return;
> out:
> pr_err("Failed to get timer from device tree with error:%d\n", ret);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: general protection fault in delayed_uprobe_remove
syzbot has found a reproducer for the following crash on: HEAD commit:25e9471b6a27 Add linux-next specific files for 20181102 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1549cfe540 kernel config: https://syzkaller.appspot.com/x/.config?x=2a22859d870756c1 dashboard link: https://syzkaller.appspot.com/bug?extid=eab6e18f95a9fe69005e compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=137174f540 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1278485d40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+eab6e18f95a9fe690...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 0 PID: 21962 Comm: syz-executor753 Not tainted 4.19.0-next-20181102+ #104 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:delayed_uprobe_remove+0x6f/0x140 kernel/events/uprobes.c:339 Code: 00 00 00 48 81 fb c0 f8 5f 89 4c 8b 23 49 bd 00 00 00 00 00 fc ff df 75 2f e9 98 00 00 00 e8 78 1d e5 ff 4c 89 e0 48 c1 e8 03 <42> 80 3c 28 00 0f 85 91 00 00 00 49 81 fc c0 f8 5f 89 49 8b 04 24 RSP: 0018:8801cc56f178 EFLAGS: 00010a02 RAX: 1bd5a020 RBX: 8801c1fece00 RCX: 11003b2001f4 RDX: RSI: 819a4af8 RDI: 8801c1fece18 RBP: 8801cc56f1a0 R08: 8801d9000fa0 R09: 0006 R10: R11: 8801d9000700 R12: dead0100 R13: dc00 R14: R15: 8801bb484ec0 FS: 7fcaad5a4700() GS:8801dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fcaad5a3e78 CR3: 0001d392f000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: uprobe_clear_state+0xbe/0x390 kernel/events/uprobes.c:1510 __mmput kernel/fork.c:1041 [inline] mmput+0x1bc/0x610 kernel/fork.c:1066 exit_mm kernel/exit.c:545 [inline] do_exit+0xe74/0x26d0 kernel/exit.c:854 do_group_exit+0x177/0x440 kernel/exit.c:970 get_signal+0x8a8/0x1970 kernel/signal.c:2517 do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816 exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4469c9 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 4b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fcaad5a3db8 EFLAGS: 0246 ORIG_RAX: 0003 RAX: RBX: 006dcc38 RCX: 004469c9 RDX: 004469c9 RSI: RDI: 0004 RBP: 006dcc30 R08: R09: R10: R11: 0246 R12: 006dcc3c R13: 7ffc9cc8172f R14: 7fcaad5a49c0 R15: 006dcd2c Modules linked in: ---[ end trace b0de3a2925ef8954 ]--- RIP: 0010:delayed_uprobe_remove+0x6f/0x140 kernel/events/uprobes.c:339 Code: 00 00 00 48 81 fb c0 f8 5f 89 4c 8b 23 49 bd 00 00 00 00 00 fc ff df 75 2f e9 98 00 00 00 e8 78 1d e5 ff 4c 89 e0 48 c1 e8 03 <42> 80 3c 28 00 0f 85 91 00 00 00 49 81 fc c0 f8 5f 89 49 8b 04 24 RSP: 0018:8801cc56f178 EFLAGS: 00010a02 RAX: 1bd5a020 RBX: 8801c1fece00 RCX: 11003b2001f4 RDX: RSI: 819a4af8 RDI: 8801c1fece18 RBP: 8801cc56f1a0 R08: 8801d9000fa0 R09: 0006 R10: R11: 8801d9000700 R12: dead0100 R13: dc00 R14: R15: 8801bb484ec0 FS: 7fcaad5a4700() GS:8801dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0154c000 CR3: 0001d459 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
Re: [GIT PULL] ARM: SoC fixes
On Sat, Nov 3, 2018 at 11:45 AM Olof Johansson wrote: > > ARM: SoC fixes Pulled, Linus
Re: general protection fault in delayed_uprobe_remove
syzbot has found a reproducer for the following crash on: HEAD commit:25e9471b6a27 Add linux-next specific files for 20181102 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1549cfe540 kernel config: https://syzkaller.appspot.com/x/.config?x=2a22859d870756c1 dashboard link: https://syzkaller.appspot.com/bug?extid=eab6e18f95a9fe69005e compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=137174f540 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1278485d40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+eab6e18f95a9fe690...@syzkaller.appspotmail.com kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 0 PID: 21962 Comm: syz-executor753 Not tainted 4.19.0-next-20181102+ #104 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:delayed_uprobe_remove+0x6f/0x140 kernel/events/uprobes.c:339 Code: 00 00 00 48 81 fb c0 f8 5f 89 4c 8b 23 49 bd 00 00 00 00 00 fc ff df 75 2f e9 98 00 00 00 e8 78 1d e5 ff 4c 89 e0 48 c1 e8 03 <42> 80 3c 28 00 0f 85 91 00 00 00 49 81 fc c0 f8 5f 89 49 8b 04 24 RSP: 0018:8801cc56f178 EFLAGS: 00010a02 RAX: 1bd5a020 RBX: 8801c1fece00 RCX: 11003b2001f4 RDX: RSI: 819a4af8 RDI: 8801c1fece18 RBP: 8801cc56f1a0 R08: 8801d9000fa0 R09: 0006 R10: R11: 8801d9000700 R12: dead0100 R13: dc00 R14: R15: 8801bb484ec0 FS: 7fcaad5a4700() GS:8801dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fcaad5a3e78 CR3: 0001d392f000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: uprobe_clear_state+0xbe/0x390 kernel/events/uprobes.c:1510 __mmput kernel/fork.c:1041 [inline] mmput+0x1bc/0x610 kernel/fork.c:1066 exit_mm kernel/exit.c:545 [inline] do_exit+0xe74/0x26d0 kernel/exit.c:854 do_group_exit+0x177/0x440 kernel/exit.c:970 get_signal+0x8a8/0x1970 kernel/signal.c:2517 do_signal+0x9c/0x21c0 arch/x86/kernel/signal.c:816 exit_to_usermode_loop+0x2e5/0x380 arch/x86/entry/common.c:162 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4469c9 Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 4b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fcaad5a3db8 EFLAGS: 0246 ORIG_RAX: 0003 RAX: RBX: 006dcc38 RCX: 004469c9 RDX: 004469c9 RSI: RDI: 0004 RBP: 006dcc30 R08: R09: R10: R11: 0246 R12: 006dcc3c R13: 7ffc9cc8172f R14: 7fcaad5a49c0 R15: 006dcd2c Modules linked in: ---[ end trace b0de3a2925ef8954 ]--- RIP: 0010:delayed_uprobe_remove+0x6f/0x140 kernel/events/uprobes.c:339 Code: 00 00 00 48 81 fb c0 f8 5f 89 4c 8b 23 49 bd 00 00 00 00 00 fc ff df 75 2f e9 98 00 00 00 e8 78 1d e5 ff 4c 89 e0 48 c1 e8 03 <42> 80 3c 28 00 0f 85 91 00 00 00 49 81 fc c0 f8 5f 89 49 8b 04 24 RSP: 0018:8801cc56f178 EFLAGS: 00010a02 RAX: 1bd5a020 RBX: 8801c1fece00 RCX: 11003b2001f4 RDX: RSI: 819a4af8 RDI: 8801c1fece18 RBP: 8801cc56f1a0 R08: 8801d9000fa0 R09: 0006 R10: R11: 8801d9000700 R12: dead0100 R13: dc00 R14: R15: 8801bb484ec0 FS: 7fcaad5a4700() GS:8801dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0154c000 CR3: 0001d459 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
Re: [GIT PULL] ARM: SoC fixes
On Sat, Nov 3, 2018 at 11:45 AM Olof Johansson wrote: > > ARM: SoC fixes Pulled, Linus
Re: [PATCH v2 3/4] ARM: mmp2: initialize clocks before the timer
On Tue 2018-09-18 22:54:54, Lubomir Rintel wrote:
> The timer shall enable its clock.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> arch/arm/mach-mmp/mmp2-dt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
> index 0341359b24a4..50c5e8b5be3d 100644
> --- a/arch/arm/mach-mmp/mmp2-dt.c
> +++ b/arch/arm/mach-mmp/mmp2-dt.c
> @@ -26,8 +26,8 @@ static void __init mmp_init_time(void)
> #ifdef CONFIG_CACHE_TAUROS2
> tauros2_init(0);
> #endif
> - mmp_dt_init_timer();
> of_clk_init(NULL);
> + mmp_dt_init_timer();
> }
>
> static const char *const mmp2_dt_board_compat[] __initconst = {
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v2 3/4] ARM: mmp2: initialize clocks before the timer
On Tue 2018-09-18 22:54:54, Lubomir Rintel wrote:
> The timer shall enable its clock.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> arch/arm/mach-mmp/mmp2-dt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-mmp/mmp2-dt.c b/arch/arm/mach-mmp/mmp2-dt.c
> index 0341359b24a4..50c5e8b5be3d 100644
> --- a/arch/arm/mach-mmp/mmp2-dt.c
> +++ b/arch/arm/mach-mmp/mmp2-dt.c
> @@ -26,8 +26,8 @@ static void __init mmp_init_time(void)
> #ifdef CONFIG_CACHE_TAUROS2
> tauros2_init(0);
> #endif
> - mmp_dt_init_timer();
> of_clk_init(NULL);
> + mmp_dt_init_timer();
> }
>
> static const char *const mmp2_dt_board_compat[] __initconst = {
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v2 2/4] DT: marvell,mmp2: add clock to the timer
On Tue 2018-09-18 22:54:53, Lubomir Rintel wrote:
> The timer needs the timer clock to be enabled, otherwise it stops
> ticking.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> arch/arm/boot/dts/mmp2.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
> index 766bbb8495b6..58e0098a007d 100644
> --- a/arch/arm/boot/dts/mmp2.dtsi
> +++ b/arch/arm/boot/dts/mmp2.dtsi
> @@ -130,6 +130,7 @@
> compatible = "mrvl,mmp-timer";
> reg = <0xd4014000 0x100>;
> interrupts = <13>;
> + clocks = <_clocks MMP2_CLK_TIMER>;
> };
>
> uart1: uart@d403 {
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v2 2/4] DT: marvell,mmp2: add clock to the timer
On Tue 2018-09-18 22:54:53, Lubomir Rintel wrote:
> The timer needs the timer clock to be enabled, otherwise it stops
> ticking.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> arch/arm/boot/dts/mmp2.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
> index 766bbb8495b6..58e0098a007d 100644
> --- a/arch/arm/boot/dts/mmp2.dtsi
> +++ b/arch/arm/boot/dts/mmp2.dtsi
> @@ -130,6 +130,7 @@
> compatible = "mrvl,mmp-timer";
> reg = <0xd4014000 0x100>;
> interrupts = <13>;
> + clocks = <_clocks MMP2_CLK_TIMER>;
> };
>
> uart1: uart@d403 {
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v2 1/4] dt-bindings: mrvl,mmp-timer: add clock
On Tue 2018-09-18 22:54:52, Lubomir Rintel wrote:
> The timer needs the timer clock to be enabled, otherwise it stops
> ticking.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Rob Herring
Acked-by: Pavel Machek
> ---
> Changes since v1:
> - Made the clock optional, to keep compatibility with DTs without it
>
> Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt
> b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt
> index 9a6e251462e7..b8f02c663521 100644
> --- a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt
> +++ b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt
> @@ -5,9 +5,13 @@ Required properties:
> - reg : Address and length of the register set of timer controller.
> - interrupts : Should be the interrupt number.
>
> +Optional properties:
> +- clocks : Should contain a single entry describing the clock input.
> +
> Example:
> timer0: timer@d4014000 {
> compatible = "mrvl,mmp-timer";
> reg = <0xd4014000 0x100>;
> interrupts = <13>;
> + clocks = < 2>;
> };
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v2 1/4] dt-bindings: mrvl,mmp-timer: add clock
On Tue 2018-09-18 22:54:52, Lubomir Rintel wrote:
> The timer needs the timer clock to be enabled, otherwise it stops
> ticking.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Rob Herring
Acked-by: Pavel Machek
> ---
> Changes since v1:
> - Made the clock optional, to keep compatibility with DTs without it
>
> Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt
> b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt
> index 9a6e251462e7..b8f02c663521 100644
> --- a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt
> +++ b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt
> @@ -5,9 +5,13 @@ Required properties:
> - reg : Address and length of the register set of timer controller.
> - interrupts : Should be the interrupt number.
>
> +Optional properties:
> +- clocks : Should contain a single entry describing the clock input.
> +
> Example:
> timer0: timer@d4014000 {
> compatible = "mrvl,mmp-timer";
> reg = <0xd4014000 0x100>;
> interrupts = <13>;
> + clocks = < 2>;
> };
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] spi: pxa2xx: Remove the shutdown callback
On Mon 2018-09-17 14:11:24, Lubomir Rintel wrote:
> It makes no sense to remove the device on shutdown. And it break things
> when the hardware crucial for shutdown (such as the embedded controller)
> is attached to the SPI bus.
Again, are you sure?
On some hardware (sharp zaurus, phones) it is good idea to shut down
hardware before poweroff, as they don't have embedded controller that
would cut the power.
Will this increase power consumption while "off" on such platforms?
Pavel
> Cc: Daniel Mack
> Cc: Haojian Zhuang
> Cc: Robert Jarzmik
> Cc: Mark Brown
> Signed-off-by: Lubomir Rintel
> ---
> drivers/spi/spi-pxa2xx.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
> index 14f4ea59caff..b06f37fb29f6 100644
> --- a/drivers/spi/spi-pxa2xx.c
> +++ b/drivers/spi/spi-pxa2xx.c
> @@ -1764,14 +1764,6 @@ static int pxa2xx_spi_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -static void pxa2xx_spi_shutdown(struct platform_device *pdev)
> -{
> - int status = 0;
> -
> - if ((status = pxa2xx_spi_remove(pdev)) != 0)
> - dev_err(>dev, "shutdown failed with %d\n", status);
> -}
> -
> #ifdef CONFIG_PM_SLEEP
> static int pxa2xx_spi_suspend(struct device *dev)
> {
> @@ -1851,7 +1843,6 @@ static struct platform_driver driver = {
> },
> .probe = pxa2xx_spi_probe,
> .remove = pxa2xx_spi_remove,
> - .shutdown = pxa2xx_spi_shutdown,
> };
>
> static int __init pxa2xx_spi_init(void)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] spi: pxa2xx: Remove the shutdown callback
On Mon 2018-09-17 14:11:24, Lubomir Rintel wrote:
> It makes no sense to remove the device on shutdown. And it break things
> when the hardware crucial for shutdown (such as the embedded controller)
> is attached to the SPI bus.
Again, are you sure?
On some hardware (sharp zaurus, phones) it is good idea to shut down
hardware before poweroff, as they don't have embedded controller that
would cut the power.
Will this increase power consumption while "off" on such platforms?
Pavel
> Cc: Daniel Mack
> Cc: Haojian Zhuang
> Cc: Robert Jarzmik
> Cc: Mark Brown
> Signed-off-by: Lubomir Rintel
> ---
> drivers/spi/spi-pxa2xx.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
> index 14f4ea59caff..b06f37fb29f6 100644
> --- a/drivers/spi/spi-pxa2xx.c
> +++ b/drivers/spi/spi-pxa2xx.c
> @@ -1764,14 +1764,6 @@ static int pxa2xx_spi_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -static void pxa2xx_spi_shutdown(struct platform_device *pdev)
> -{
> - int status = 0;
> -
> - if ((status = pxa2xx_spi_remove(pdev)) != 0)
> - dev_err(>dev, "shutdown failed with %d\n", status);
> -}
> -
> #ifdef CONFIG_PM_SLEEP
> static int pxa2xx_spi_suspend(struct device *dev)
> {
> @@ -1851,7 +1843,6 @@ static struct platform_driver driver = {
> },
> .probe = pxa2xx_spi_probe,
> .remove = pxa2xx_spi_remove,
> - .shutdown = pxa2xx_spi_shutdown,
> };
>
> static int __init pxa2xx_spi_init(void)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] spi: Gracefully handle power supplies with disabled PM
On Mon 2018-09-17 14:10:41, Lubomir Rintel wrote:
> This allows use of SPI when power management is disables, such as on
> early boot;
disabled
boot.
> See also: commit 31eb74318054 ("PM / runtime: Fix handling of suppliers
> with disabled runtime PM")
>
> Cc: Mark Brown
> Signed-off-by: Lubomir Rintel
Plus.. I'm not sure.
I thought you'd cause imbalance between _put and _get, but that one is
probably ok.
On early boot, you probably need to proceed, but is ret == -EACCESS
the right test?
Pavel
> index ec395a6baf9c..6546564e41d0 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1212,7 +1212,7 @@ static void __spi_pump_messages(struct spi_controller
> *ctlr, bool in_kthread)
>
> if (!was_busy && ctlr->auto_runtime_pm) {
> ret = pm_runtime_get_sync(ctlr->dev.parent);
> - if (ret < 0) {
> + if (ret < 0 && ret != -EACCES) {
> pm_runtime_put_noidle(ctlr->dev.parent);
> dev_err(>dev, "Failed to power device: %d\n",
> ret);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] spi: Gracefully handle power supplies with disabled PM
On Mon 2018-09-17 14:10:41, Lubomir Rintel wrote:
> This allows use of SPI when power management is disables, such as on
> early boot;
disabled
boot.
> See also: commit 31eb74318054 ("PM / runtime: Fix handling of suppliers
> with disabled runtime PM")
>
> Cc: Mark Brown
> Signed-off-by: Lubomir Rintel
Plus.. I'm not sure.
I thought you'd cause imbalance between _put and _get, but that one is
probably ok.
On early boot, you probably need to proceed, but is ret == -EACCESS
the right test?
Pavel
> index ec395a6baf9c..6546564e41d0 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1212,7 +1212,7 @@ static void __spi_pump_messages(struct spi_controller
> *ctlr, bool in_kthread)
>
> if (!was_busy && ctlr->auto_runtime_pm) {
> ret = pm_runtime_get_sync(ctlr->dev.parent);
> - if (ret < 0) {
> + if (ret < 0 && ret != -EACCES) {
> pm_runtime_put_noidle(ctlr->dev.parent);
> dev_err(>dev, "Failed to power device: %d\n",
> ret);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 1/2] DT: marvell,mmp2: fix TWSI2
On Mon 2018-09-17 13:39:46, Lubomir Rintel wrote:
> Marvell keeps their MMP2 datasheet secret, but there are good clues
> that TWSI2 is not on 0xd4025000 on that platform, not does it use
> IRQ 58. In fact, the IRQ 58 on MMP2 seems to be a signal processor:
>
>arch/arm/mach-mmp/irqs.h:#define IRQ_MMP2_MSP 58
>
> I'm taking a somewhat educated guess that is probably a copy & paste
> error from PXA168 or PXA910 and that the real controller in fact hides
> at address 0xd4031000 and uses an interrupt line multiplexed via IRQ 17.
>
> I'm also copying some properties from TWSI1 that were missing or
> incorrect.
>
> Tested on a OLPC XO 1.75 machine, where the RTC is on TWSI2.
>
> Cc: Eric Miao
> Cc: Haojian Zhuang
> Cc: Rob Herring
> Cc: Mark Rutland
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> status = "disabled";
> };
>
> - twsi2: i2c@d4025000 {
> + twsi2: i2c@d4031000 {
> compatible = "mrvl,mmp-twsi";
> - reg = <0xd4025000 0x1000>;
> - interrupts = <58>;
> + reg = <0xd4031000 0x1000>;
> + interrupt-parent = <>;
> + interrupts = <0>;
> clocks = <_clocks MMP2_CLK_TWSI1>;
> resets = <_clocks MMP2_CLK_TWSI1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> status = "disabled";
> };
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 2/2] DT: marvell,mmp2: add more TWSI controllers
On Mon 2018-09-17 13:39:47, Lubomir Rintel wrote:
> I've gotten the base addresses, clocks and interrupts from an rusty and old
> out-of-tree driver. I haven't actually checked against the datasheet, since
> that one is reserved for the Marvell inner circle.
>
> Tested with an accelerometer on TWSI6 on an OLPC XO 1.75 machine.
>
> Cc: Eric Miao
> Cc: Haojian Zhuang
> Cc: Rob Herring
> Cc: Mark Rutland
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> arch/arm/boot/dts/mmp2.dtsi | 49 +
> 1 file changed, 49 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
> index 47e5b63339d1..2bd4e94501ce 100644
> --- a/arch/arm/boot/dts/mmp2.dtsi
> +++ b/arch/arm/boot/dts/mmp2.dtsi
> @@ -232,6 +232,55 @@
> status = "disabled";
> };
>
> + twsi3: i2c@d4032000 {
> + compatible = "mrvl,mmp-twsi";
> + reg = <0xd4032000 0x1000>;
> + interrupt-parent = <>;
> + interrupts = <1>;
> + clocks = <_clocks MMP2_CLK_TWSI2>;
> + resets = <_clocks MMP2_CLK_TWSI2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + twsi4: i2c@d4033000 {
> + compatible = "mrvl,mmp-twsi";
> + reg = <0xd4033000 0x1000>;
> + interrupt-parent = <>;
> + interrupts = <2>;
> + clocks = <_clocks MMP2_CLK_TWSI3>;
> + resets = <_clocks MMP2_CLK_TWSI3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> +
> + twsi5: i2c@d4033800 {
> + compatible = "mrvl,mmp-twsi";
> + reg = <0xd4033800 0x1000>;
> + interrupt-parent = <>;
> + interrupts = <3>;
> + clocks = <_clocks MMP2_CLK_TWSI4>;
> + resets = <_clocks MMP2_CLK_TWSI4>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + twsi6: i2c@d4034000 {
> + compatible = "mrvl,mmp-twsi";
> + reg = <0xd4034000 0x1000>;
> + interrupt-parent = <>;
> + interrupts = <4>;
> + clocks = <_clocks MMP2_CLK_TWSI5>;
> + resets = <_clocks MMP2_CLK_TWSI5>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> rtc: rtc@d401 {
> compatible = "mrvl,mmp-rtc";
> reg = <0xd401 0x1000>;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 1/2] DT: marvell,mmp2: fix TWSI2
On Mon 2018-09-17 13:39:46, Lubomir Rintel wrote:
> Marvell keeps their MMP2 datasheet secret, but there are good clues
> that TWSI2 is not on 0xd4025000 on that platform, not does it use
> IRQ 58. In fact, the IRQ 58 on MMP2 seems to be a signal processor:
>
>arch/arm/mach-mmp/irqs.h:#define IRQ_MMP2_MSP 58
>
> I'm taking a somewhat educated guess that is probably a copy & paste
> error from PXA168 or PXA910 and that the real controller in fact hides
> at address 0xd4031000 and uses an interrupt line multiplexed via IRQ 17.
>
> I'm also copying some properties from TWSI1 that were missing or
> incorrect.
>
> Tested on a OLPC XO 1.75 machine, where the RTC is on TWSI2.
>
> Cc: Eric Miao
> Cc: Haojian Zhuang
> Cc: Rob Herring
> Cc: Mark Rutland
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> status = "disabled";
> };
>
> - twsi2: i2c@d4025000 {
> + twsi2: i2c@d4031000 {
> compatible = "mrvl,mmp-twsi";
> - reg = <0xd4025000 0x1000>;
> - interrupts = <58>;
> + reg = <0xd4031000 0x1000>;
> + interrupt-parent = <>;
> + interrupts = <0>;
> clocks = <_clocks MMP2_CLK_TWSI1>;
> resets = <_clocks MMP2_CLK_TWSI1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> status = "disabled";
> };
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 2/2] DT: marvell,mmp2: add more TWSI controllers
On Mon 2018-09-17 13:39:47, Lubomir Rintel wrote:
> I've gotten the base addresses, clocks and interrupts from an rusty and old
> out-of-tree driver. I haven't actually checked against the datasheet, since
> that one is reserved for the Marvell inner circle.
>
> Tested with an accelerometer on TWSI6 on an OLPC XO 1.75 machine.
>
> Cc: Eric Miao
> Cc: Haojian Zhuang
> Cc: Rob Herring
> Cc: Mark Rutland
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> ---
> arch/arm/boot/dts/mmp2.dtsi | 49 +
> 1 file changed, 49 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
> index 47e5b63339d1..2bd4e94501ce 100644
> --- a/arch/arm/boot/dts/mmp2.dtsi
> +++ b/arch/arm/boot/dts/mmp2.dtsi
> @@ -232,6 +232,55 @@
> status = "disabled";
> };
>
> + twsi3: i2c@d4032000 {
> + compatible = "mrvl,mmp-twsi";
> + reg = <0xd4032000 0x1000>;
> + interrupt-parent = <>;
> + interrupts = <1>;
> + clocks = <_clocks MMP2_CLK_TWSI2>;
> + resets = <_clocks MMP2_CLK_TWSI2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + twsi4: i2c@d4033000 {
> + compatible = "mrvl,mmp-twsi";
> + reg = <0xd4033000 0x1000>;
> + interrupt-parent = <>;
> + interrupts = <2>;
> + clocks = <_clocks MMP2_CLK_TWSI3>;
> + resets = <_clocks MMP2_CLK_TWSI3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> +
> + twsi5: i2c@d4033800 {
> + compatible = "mrvl,mmp-twsi";
> + reg = <0xd4033800 0x1000>;
> + interrupt-parent = <>;
> + interrupts = <3>;
> + clocks = <_clocks MMP2_CLK_TWSI4>;
> + resets = <_clocks MMP2_CLK_TWSI4>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + twsi6: i2c@d4034000 {
> + compatible = "mrvl,mmp-twsi";
> + reg = <0xd4034000 0x1000>;
> + interrupt-parent = <>;
> + interrupts = <4>;
> + clocks = <_clocks MMP2_CLK_TWSI5>;
> + resets = <_clocks MMP2_CLK_TWSI5>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> rtc: rtc@d401 {
> compatible = "mrvl,mmp-rtc";
> reg = <0xd401 0x1000>;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] DT: marvell,mmp2: give gpio node a name
On Mon 2018-09-17 13:23:03, Lubomir Rintel wrote:
> This will be useful for boards that actually use GPIO pins.
>
> Cc: Eric Miao
> Cc: Haojian Zhuang
> Cc: Rob Herring
> Cc: Mark Rutland
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> arch/arm/boot/dts/mmp2.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
> index 766bbb8495b6..f8867364e5a1 100644
> --- a/arch/arm/boot/dts/mmp2.dtsi
> +++ b/arch/arm/boot/dts/mmp2.dtsi
> @@ -168,7 +168,7 @@
> status = "disabled";
> };
>
> - gpio@d4019000 {
> + gpio: gpio@d4019000 {
> compatible = "marvell,mmp2-gpio";
> #address-cells = <1>;
> #size-cells = <1>;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] DT: marvell,mmp2: give gpio node a name
On Mon 2018-09-17 13:23:03, Lubomir Rintel wrote:
> This will be useful for boards that actually use GPIO pins.
>
> Cc: Eric Miao
> Cc: Haojian Zhuang
> Cc: Rob Herring
> Cc: Mark Rutland
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
> arch/arm/boot/dts/mmp2.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
> index 766bbb8495b6..f8867364e5a1 100644
> --- a/arch/arm/boot/dts/mmp2.dtsi
> +++ b/arch/arm/boot/dts/mmp2.dtsi
> @@ -168,7 +168,7 @@
> status = "disabled";
> };
>
> - gpio@d4019000 {
> + gpio: gpio@d4019000 {
> compatible = "marvell,mmp2-gpio";
> #address-cells = <1>;
> #size-cells = <1>;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] gpio: pxa: avoid attempting to set pin direction via pinctrl on MMP2
On Mon 2018-09-17 13:17:21, Lubomir Rintel wrote:
> Similarly to PXA3xx pinctrl-single can't set pin direction on MMP2 either.
> See also: commit 9dabfdd84bdfa ("gpio: pxa: disable pinctrl calls for
> PXA3xx")
>
> Cc: Robert Jarzmik
> Cc: Linus Walleij
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] gpio: pxa: avoid attempting to set pin direction via pinctrl on MMP2
On Mon 2018-09-17 13:17:21, Lubomir Rintel wrote:
> Similarly to PXA3xx pinctrl-single can't set pin direction on MMP2 either.
> See also: commit 9dabfdd84bdfa ("gpio: pxa: disable pinctrl calls for
> PXA3xx")
>
> Cc: Robert Jarzmik
> Cc: Linus Walleij
> Signed-off-by: Lubomir Rintel
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 4b42745211af552f170f38a1b97f4a112b5da6b2: Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-10-29 15:37:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to 8008cc78d3d6f5191ffcb2b85a423d516000e7f4: Merge tag 'omap-for-v4.20/omap1-fix-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes (2018-11-02 22:31:40 -0700) ARM: SoC fixes A few fixes who have come in near or during the merge window: - Removal of a VLA usage in Marvell mpp platform code - Enable some IPMI options for ARM64 servers by default, helps testing - Enable PREEMPT on 32-bit ARMv7 defconfig - Minor fix for stm32 DT (removal of an unused DMA property) - Bugfix for TI OMAP1-based ams-delta (-EINVAL -> IRQ_NOTCONNECTED) Alexandre Torgue (1): ARM: dts: stm32: update HASH1 dmas property on stm32mp157c Arnd Bergmann (1): ARM: orion: avoid VLA in orion_mpp_conf Janusz Krzysztofik (1): ARM: OMAP1: ams-delta: Fix impossible .irq < 0 John Garry (1): arm64: defconfig: Enable some IPMI configs Linus Walleij (1): ARM: defconfig: Update multi_v7 to use PREEMPT Marc Zyngier (1): soc: ti: QMSS: Fix usage of irq_set_affinity_hint Olof Johansson (1): Merge tag 'omap-for-v4.20/omap1-fix-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes arch/arm/boot/dts/stm32mp157c.dtsi| 2 +- arch/arm/configs/multi_v7_defconfig | 1 + arch/arm/mach-omap1/board-ams-delta.c | 8 ++-- arch/arm/plat-orion/mpp.c | 7 ++- arch/arm64/configs/defconfig | 3 +++ drivers/soc/ti/knav_qmss.h| 4 ++-- drivers/soc/ti/knav_qmss_acc.c| 10 +- drivers/soc/ti/knav_qmss_queue.c | 22 +++--- 8 files changed, 35 insertions(+), 22 deletions(-)
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 4b42745211af552f170f38a1b97f4a112b5da6b2: Merge tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-10-29 15:37:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to 8008cc78d3d6f5191ffcb2b85a423d516000e7f4: Merge tag 'omap-for-v4.20/omap1-fix-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes (2018-11-02 22:31:40 -0700) ARM: SoC fixes A few fixes who have come in near or during the merge window: - Removal of a VLA usage in Marvell mpp platform code - Enable some IPMI options for ARM64 servers by default, helps testing - Enable PREEMPT on 32-bit ARMv7 defconfig - Minor fix for stm32 DT (removal of an unused DMA property) - Bugfix for TI OMAP1-based ams-delta (-EINVAL -> IRQ_NOTCONNECTED) Alexandre Torgue (1): ARM: dts: stm32: update HASH1 dmas property on stm32mp157c Arnd Bergmann (1): ARM: orion: avoid VLA in orion_mpp_conf Janusz Krzysztofik (1): ARM: OMAP1: ams-delta: Fix impossible .irq < 0 John Garry (1): arm64: defconfig: Enable some IPMI configs Linus Walleij (1): ARM: defconfig: Update multi_v7 to use PREEMPT Marc Zyngier (1): soc: ti: QMSS: Fix usage of irq_set_affinity_hint Olof Johansson (1): Merge tag 'omap-for-v4.20/omap1-fix-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes arch/arm/boot/dts/stm32mp157c.dtsi| 2 +- arch/arm/configs/multi_v7_defconfig | 1 + arch/arm/mach-omap1/board-ams-delta.c | 8 ++-- arch/arm/plat-orion/mpp.c | 7 ++- arch/arm64/configs/defconfig | 3 +++ drivers/soc/ti/knav_qmss.h| 4 ++-- drivers/soc/ti/knav_qmss_acc.c| 10 +- drivers/soc/ti/knav_qmss_queue.c | 22 +++--- 8 files changed, 35 insertions(+), 22 deletions(-)
[PATCH] ia64: export node_distance function
The numa_slit variable used by node_distance is available to a
module as long as it is linked at compile-time. However, it is
not available to loadable modules. Leading to errors such as:
ERROR: "numa_slit" [drivers/nvme/host/nvme-core.ko] undefined!
The error above is caused by the nvme multipath code that makes
use of node_distance for its path calculation. When the patch was
added, the lightnvm subsystem would select nvme and always compile
it in, leading to the node_distance call to always succeed.
However, when this requirement was removed, nvme could be compiled
in as a module, which exposed this bug.
This patch extracts node_distance to a function and exports it.
Since ACPI is depending on node_distance being a simple lookup to
numa_slit, the previous behavior is exposed as slit_distance and its
users updated.
Fixes: f333444708f82 "nvme: take node locality into account when selecting a
path"
Fixes: 73569e11032f "lightnvm: remove dependencies on BLK_DEV_NVME and PCI"
Signed-off-by: Matias Bjøring
---
arch/ia64/include/asm/numa.h | 4 +++-
arch/ia64/kernel/acpi.c | 6 +++---
arch/ia64/mm/numa.c | 6 ++
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/include/asm/numa.h b/arch/ia64/include/asm/numa.h
index ebef7f40aabb..c5c253cb9bd6 100644
--- a/arch/ia64/include/asm/numa.h
+++ b/arch/ia64/include/asm/numa.h
@@ -59,7 +59,9 @@ extern struct node_cpuid_s node_cpuid[NR_CPUS];
*/
extern u8 numa_slit[MAX_NUMNODES * MAX_NUMNODES];
-#define node_distance(from,to) (numa_slit[(from) * MAX_NUMNODES + (to)])
+#define slit_distance(from,to) (numa_slit[(from) * MAX_NUMNODES + (to)])
+extern int __node_distance(int from, int to);
+#define node_distance(from,to) __node_distance(from, to)
extern int paddr_to_nid(unsigned long paddr);
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 1dacbf5e9e09..41eb281709da 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -578,8 +578,8 @@ void __init acpi_numa_fixup(void)
if (!slit_table) {
for (i = 0; i < MAX_NUMNODES; i++)
for (j = 0; j < MAX_NUMNODES; j++)
- node_distance(i, j) = i == j ? LOCAL_DISTANCE :
- REMOTE_DISTANCE;
+ slit_distance(i, j) = i == j ?
+ LOCAL_DISTANCE : REMOTE_DISTANCE;
return;
}
@@ -592,7 +592,7 @@ void __init acpi_numa_fixup(void)
if (!pxm_bit_test(j))
continue;
node_to = pxm_to_node(j);
- node_distance(node_from, node_to) =
+ slit_distance(node_from, node_to) =
slit_table->entry[i * slit_table->locality_count +
j];
}
}
diff --git a/arch/ia64/mm/numa.c b/arch/ia64/mm/numa.c
index aa19b7ac8222..5769d4b21270 100644
--- a/arch/ia64/mm/numa.c
+++ b/arch/ia64/mm/numa.c
@@ -36,6 +36,12 @@ struct node_cpuid_s node_cpuid[NR_CPUS] =
*/
u8 numa_slit[MAX_NUMNODES * MAX_NUMNODES];
+int __node_distance(int from, int to)
+{
+ return slit_distance(from, to);
+}
+EXPORT_SYMBOL(__node_distance);
+
/* Identify which cnode a physical address resides on */
int
paddr_to_nid(unsigned long paddr)
--
2.17.1
[PATCH] ia64: export node_distance function
The numa_slit variable used by node_distance is available to a
module as long as it is linked at compile-time. However, it is
not available to loadable modules. Leading to errors such as:
ERROR: "numa_slit" [drivers/nvme/host/nvme-core.ko] undefined!
The error above is caused by the nvme multipath code that makes
use of node_distance for its path calculation. When the patch was
added, the lightnvm subsystem would select nvme and always compile
it in, leading to the node_distance call to always succeed.
However, when this requirement was removed, nvme could be compiled
in as a module, which exposed this bug.
This patch extracts node_distance to a function and exports it.
Since ACPI is depending on node_distance being a simple lookup to
numa_slit, the previous behavior is exposed as slit_distance and its
users updated.
Fixes: f333444708f82 "nvme: take node locality into account when selecting a
path"
Fixes: 73569e11032f "lightnvm: remove dependencies on BLK_DEV_NVME and PCI"
Signed-off-by: Matias Bjøring
---
arch/ia64/include/asm/numa.h | 4 +++-
arch/ia64/kernel/acpi.c | 6 +++---
arch/ia64/mm/numa.c | 6 ++
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/include/asm/numa.h b/arch/ia64/include/asm/numa.h
index ebef7f40aabb..c5c253cb9bd6 100644
--- a/arch/ia64/include/asm/numa.h
+++ b/arch/ia64/include/asm/numa.h
@@ -59,7 +59,9 @@ extern struct node_cpuid_s node_cpuid[NR_CPUS];
*/
extern u8 numa_slit[MAX_NUMNODES * MAX_NUMNODES];
-#define node_distance(from,to) (numa_slit[(from) * MAX_NUMNODES + (to)])
+#define slit_distance(from,to) (numa_slit[(from) * MAX_NUMNODES + (to)])
+extern int __node_distance(int from, int to);
+#define node_distance(from,to) __node_distance(from, to)
extern int paddr_to_nid(unsigned long paddr);
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 1dacbf5e9e09..41eb281709da 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -578,8 +578,8 @@ void __init acpi_numa_fixup(void)
if (!slit_table) {
for (i = 0; i < MAX_NUMNODES; i++)
for (j = 0; j < MAX_NUMNODES; j++)
- node_distance(i, j) = i == j ? LOCAL_DISTANCE :
- REMOTE_DISTANCE;
+ slit_distance(i, j) = i == j ?
+ LOCAL_DISTANCE : REMOTE_DISTANCE;
return;
}
@@ -592,7 +592,7 @@ void __init acpi_numa_fixup(void)
if (!pxm_bit_test(j))
continue;
node_to = pxm_to_node(j);
- node_distance(node_from, node_to) =
+ slit_distance(node_from, node_to) =
slit_table->entry[i * slit_table->locality_count +
j];
}
}
diff --git a/arch/ia64/mm/numa.c b/arch/ia64/mm/numa.c
index aa19b7ac8222..5769d4b21270 100644
--- a/arch/ia64/mm/numa.c
+++ b/arch/ia64/mm/numa.c
@@ -36,6 +36,12 @@ struct node_cpuid_s node_cpuid[NR_CPUS] =
*/
u8 numa_slit[MAX_NUMNODES * MAX_NUMNODES];
+int __node_distance(int from, int to)
+{
+ return slit_distance(from, to);
+}
+EXPORT_SYMBOL(__node_distance);
+
/* Identify which cnode a physical address resides on */
int
paddr_to_nid(unsigned long paddr)
--
2.17.1
[PATCH] psi: simplify cgroup_move_task
The existing code triggered an invalid warning about 'rq' possibly being
used uninitialized. Instead of doing the silly warning suppression by
initializa it to NULL, refactor the code to bail out early instead.
Warning was:
kernel/sched/psi.c: In function ‘cgroup_move_task’:
kernel/sched/psi.c:639:13: warning: ‘rq’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
Fixes: 2ce7135adc9ad ("psi: cgroup support")
Cc: Johannes Weiner
Signed-off-by: Olof Johansson
---
kernel/sched/psi.c | 43 ++-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7cdecfc010af..3d7355d7c3e3 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -633,38 +633,39 @@ void psi_cgroup_free(struct cgroup *cgroup)
*/
void cgroup_move_task(struct task_struct *task, struct css_set *to)
{
- bool move_psi = !psi_disabled;
unsigned int task_flags = 0;
struct rq_flags rf;
struct rq *rq;
- if (move_psi) {
- rq = task_rq_lock(task, );
+ if (psi_disabled) {
+ /*
+* Lame to do this here, but the scheduler cannot be locked
+* from the outside, so we move cgroups from inside sched/.
+*/
+ rcu_assign_pointer(task->cgroups, to);
+ return;
+ }
- if (task_on_rq_queued(task))
- task_flags = TSK_RUNNING;
- else if (task->in_iowait)
- task_flags = TSK_IOWAIT;
+ rq = task_rq_lock(task, );
- if (task->flags & PF_MEMSTALL)
- task_flags |= TSK_MEMSTALL;
+ if (task_on_rq_queued(task))
+ task_flags = TSK_RUNNING;
+ else if (task->in_iowait)
+ task_flags = TSK_IOWAIT;
- if (task_flags)
- psi_task_change(task, task_flags, 0);
- }
+ if (task->flags & PF_MEMSTALL)
+ task_flags |= TSK_MEMSTALL;
- /*
-* Lame to do this here, but the scheduler cannot be locked
-* from the outside, so we move cgroups from inside sched/.
-*/
+ if (task_flags)
+ psi_task_change(task, task_flags, 0);
+
+ /* See comment above */
rcu_assign_pointer(task->cgroups, to);
- if (move_psi) {
- if (task_flags)
- psi_task_change(task, 0, task_flags);
+ if (task_flags)
+ psi_task_change(task, 0, task_flags);
- task_rq_unlock(rq, task, );
- }
+ task_rq_unlock(rq, task, );
}
#endif /* CONFIG_CGROUPS */
--
2.11.0
[PATCH] psi: simplify cgroup_move_task
The existing code triggered an invalid warning about 'rq' possibly being
used uninitialized. Instead of doing the silly warning suppression by
initializa it to NULL, refactor the code to bail out early instead.
Warning was:
kernel/sched/psi.c: In function ‘cgroup_move_task’:
kernel/sched/psi.c:639:13: warning: ‘rq’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
Fixes: 2ce7135adc9ad ("psi: cgroup support")
Cc: Johannes Weiner
Signed-off-by: Olof Johansson
---
kernel/sched/psi.c | 43 ++-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
index 7cdecfc010af..3d7355d7c3e3 100644
--- a/kernel/sched/psi.c
+++ b/kernel/sched/psi.c
@@ -633,38 +633,39 @@ void psi_cgroup_free(struct cgroup *cgroup)
*/
void cgroup_move_task(struct task_struct *task, struct css_set *to)
{
- bool move_psi = !psi_disabled;
unsigned int task_flags = 0;
struct rq_flags rf;
struct rq *rq;
- if (move_psi) {
- rq = task_rq_lock(task, );
+ if (psi_disabled) {
+ /*
+* Lame to do this here, but the scheduler cannot be locked
+* from the outside, so we move cgroups from inside sched/.
+*/
+ rcu_assign_pointer(task->cgroups, to);
+ return;
+ }
- if (task_on_rq_queued(task))
- task_flags = TSK_RUNNING;
- else if (task->in_iowait)
- task_flags = TSK_IOWAIT;
+ rq = task_rq_lock(task, );
- if (task->flags & PF_MEMSTALL)
- task_flags |= TSK_MEMSTALL;
+ if (task_on_rq_queued(task))
+ task_flags = TSK_RUNNING;
+ else if (task->in_iowait)
+ task_flags = TSK_IOWAIT;
- if (task_flags)
- psi_task_change(task, task_flags, 0);
- }
+ if (task->flags & PF_MEMSTALL)
+ task_flags |= TSK_MEMSTALL;
- /*
-* Lame to do this here, but the scheduler cannot be locked
-* from the outside, so we move cgroups from inside sched/.
-*/
+ if (task_flags)
+ psi_task_change(task, task_flags, 0);
+
+ /* See comment above */
rcu_assign_pointer(task->cgroups, to);
- if (move_psi) {
- if (task_flags)
- psi_task_change(task, 0, task_flags);
+ if (task_flags)
+ psi_task_change(task, 0, task_flags);
- task_rq_unlock(rq, task, );
- }
+ task_rq_unlock(rq, task, );
}
#endif /* CONFIG_CGROUPS */
--
2.11.0
Re: [Patch v4 07/18] x86/smt: Convert cpu_smt_control check to cpu_smt_enabled static key
Tim, On Tue, 30 Oct 2018, Tim Chen wrote: > Change the SMT code paths check from using cpu_smt_control to > cpu_smt_enabled static key. This saves a branching check. and adds extra size to the kernel for the patching. The only reason why it would make sense for kvm is that then the EXPORT of cpu_smt_control can go away, which takes more space than the patch data. Thanks, tglx
Re: [Patch v4 07/18] x86/smt: Convert cpu_smt_control check to cpu_smt_enabled static key
Tim, On Tue, 30 Oct 2018, Tim Chen wrote: > Change the SMT code paths check from using cpu_smt_control to > cpu_smt_enabled static key. This saves a branching check. and adds extra size to the kernel for the patching. The only reason why it would make sense for kvm is that then the EXPORT of cpu_smt_control can go away, which takes more space than the patch data. Thanks, tglx
Re: [PATCH 4.14 000/143] 4.14.79-stable review
On 11/3/18 8:04 AM, Greg Kroah-Hartman wrote:
On Sat, Nov 03, 2018 at 07:31:42AM -0700, Guenter Roeck wrote:
On 11/2/18 11:33 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.79 release.
There are 143 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Nov 4 18:27:59 UTC 2018.
Anything received after that time might be too late.
Build results:
total: 150 pass: 149 fail: 1
Failed builds:
xtensa:allmodconfig
Qemu test results:
total: 318 pass: 318 fail: 0\
Build failure:
In file included from include/linux/mlx5/port.h:36:0,
from include/linux/mlx5/driver.h: In function
‘mlx5_get_vector_affinity_hint’:
include/linux/mlx5/driver.h:1208:13: error:
‘struct irq_desc’ has no member named ‘affinity_hint’
Caused by commit 19b743c448db ("net/mlx5: Fix mlx5_get_vector_affinity
function").
Odd, this should be fixed by a later patch in the same queue, as 0 day
also reported this.
Yes, e3ca34880652 ("net/mlx5: Fix build break when CONFIG_SMP=n") in the
4.14 tree should resolve this. Ah, Sasha added it at the "last minute"
after I did the -rc1 release. So this should be resolved now, I'll push
out a -rc2 so that it can be verified...
v4.14.78-144-gb825fd9fbad5 builds fine.
Thanks,
Guenter
Re: [PATCH 4.14 000/143] 4.14.79-stable review
On 11/3/18 8:04 AM, Greg Kroah-Hartman wrote:
On Sat, Nov 03, 2018 at 07:31:42AM -0700, Guenter Roeck wrote:
On 11/2/18 11:33 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.79 release.
There are 143 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Nov 4 18:27:59 UTC 2018.
Anything received after that time might be too late.
Build results:
total: 150 pass: 149 fail: 1
Failed builds:
xtensa:allmodconfig
Qemu test results:
total: 318 pass: 318 fail: 0\
Build failure:
In file included from include/linux/mlx5/port.h:36:0,
from include/linux/mlx5/driver.h: In function
‘mlx5_get_vector_affinity_hint’:
include/linux/mlx5/driver.h:1208:13: error:
‘struct irq_desc’ has no member named ‘affinity_hint’
Caused by commit 19b743c448db ("net/mlx5: Fix mlx5_get_vector_affinity
function").
Odd, this should be fixed by a later patch in the same queue, as 0 day
also reported this.
Yes, e3ca34880652 ("net/mlx5: Fix build break when CONFIG_SMP=n") in the
4.14 tree should resolve this. Ah, Sasha added it at the "last minute"
after I did the -rc1 release. So this should be resolved now, I'll push
out a -rc2 so that it can be verified...
v4.14.78-144-gb825fd9fbad5 builds fine.
Thanks,
Guenter
Re: [PATCH] cifs: clean up indentation, replace spaces with tab
merged into cifs-2.6.git for-next
On Sat, Nov 3, 2018 at 11:00 AM Colin King wrote:
>
> From: Colin Ian King
>
> Trivial fix to clean up indentation, replace spaces with tab
>
> Signed-off-by: Colin Ian King
> ---
> fs/cifs/cifsencrypt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
> index 85b31cfa2f3c..ecdff344e8fe 100644
> --- a/fs/cifs/cifsencrypt.c
> +++ b/fs/cifs/cifsencrypt.c
> @@ -224,7 +224,7 @@ int cifs_verify_signature(struct smb_rqst *rqst,
> if (cifs_pdu->Command == SMB_COM_LOCKING_ANDX) {
> struct smb_com_lock_req *pSMB =
> (struct smb_com_lock_req *)cifs_pdu;
> - if (pSMB->LockType & LOCKING_ANDX_OPLOCK_RELEASE)
> + if (pSMB->LockType & LOCKING_ANDX_OPLOCK_RELEASE)
> return 0;
> }
>
> --
> 2.19.1
>
--
Thanks,
Steve
Re: [PATCH] cifs: clean up indentation, replace spaces with tab
merged into cifs-2.6.git for-next
On Sat, Nov 3, 2018 at 11:00 AM Colin King wrote:
>
> From: Colin Ian King
>
> Trivial fix to clean up indentation, replace spaces with tab
>
> Signed-off-by: Colin Ian King
> ---
> fs/cifs/cifsencrypt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
> index 85b31cfa2f3c..ecdff344e8fe 100644
> --- a/fs/cifs/cifsencrypt.c
> +++ b/fs/cifs/cifsencrypt.c
> @@ -224,7 +224,7 @@ int cifs_verify_signature(struct smb_rqst *rqst,
> if (cifs_pdu->Command == SMB_COM_LOCKING_ANDX) {
> struct smb_com_lock_req *pSMB =
> (struct smb_com_lock_req *)cifs_pdu;
> - if (pSMB->LockType & LOCKING_ANDX_OPLOCK_RELEASE)
> + if (pSMB->LockType & LOCKING_ANDX_OPLOCK_RELEASE)
> return 0;
> }
>
> --
> 2.19.1
>
--
Thanks,
Steve
Re: [Patch v4 08/18] sched: Deprecate sched_smt_present and use cpu_smt_enabled static key
Tim, On Tue, 30 Oct 2018, Tim Chen wrote: > The cpu_smt_enabled static key serves identical purpose as cpu_smt_enabled That doesn't make any sense. > to enable SMT specific code. > > This patch replaces sched_smt_present in the scheduler with > cpu_smt_enabled and deprecate sched_smt_present. It's not deprecating it, it's replacing and removing it and thereby breaking all architectures which select SCHED_SMT except x86. Thanks, tglx
Re: [Patch v4 08/18] sched: Deprecate sched_smt_present and use cpu_smt_enabled static key
Tim, On Tue, 30 Oct 2018, Tim Chen wrote: > The cpu_smt_enabled static key serves identical purpose as cpu_smt_enabled That doesn't make any sense. > to enable SMT specific code. > > This patch replaces sched_smt_present in the scheduler with > cpu_smt_enabled and deprecate sched_smt_present. It's not deprecating it, it's replacing and removing it and thereby breaking all architectures which select SCHED_SMT except x86. Thanks, tglx
dual-band WiFi adapter for Linux
Amazon UK are selling a dual-band WiFi adapter for about 11 GBP (approx 15 USD). It contains a RealTek chip, and it comes with a CD with source for a linux kernel driver which says it is rtl8821ae . I have a patch to make this work with a 4.19 kernel (Fedora Rawhide a few days ago). I believe the driver from Amazon is GPL2, and I am content for my patch to be taken as GPL2 as well. If anyone wants to integrate this into the Linux kernel, they should contact me directly (tjcw at cantab.net) and I will supply the material which I have. -- Chris Ward
dual-band WiFi adapter for Linux
Amazon UK are selling a dual-band WiFi adapter for about 11 GBP (approx 15 USD). It contains a RealTek chip, and it comes with a CD with source for a linux kernel driver which says it is rtl8821ae . I have a patch to make this work with a 4.19 kernel (Fedora Rawhide a few days ago). I believe the driver from Amazon is GPL2, and I am content for my patch to be taken as GPL2 as well. If anyone wants to integrate this into the Linux kernel, they should contact me directly (tjcw at cantab.net) and I will supply the material which I have. -- Chris Ward
Re: [Patch v4 03/18] x86/speculation: Reorganize cpu_show_common()
Tim,
On Tue, 30 Oct 2018, Tim Chen wrote:
> Extract the logic to show IBPB, STIBP usages in cpu_show_common()
> into helper functions.
>
> Later patches will add other userspace Spectre v2 mitigation modes.
> This patch makes it easy to show IBPB and STIBP
> usage scenario according to the mitigation mode.
First of all, I asked you before to do:
# git grep 'This patch' Documentation/process
This leads you to:
"Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour."
Documentation is there for a reason.
Aside of that, I'd really have a hard time to figure out what you are
trying to say, if I didn't have the context already. Change logs need to
make sense on their own. So something like this:
The Spectre V2 printout in cpu_show_common() handles conditionals for the
various mitigation methods directly in the sprintf() argument list. That's
hard to read and will become unreadable if more complex decisions need to
be made for a particular method.
Move the conditionals for STIBP and IBPB string selection into helper
functions, so they can be extended later on.
follows the obvious ordering for change logs:
1) Describe context and problem
2) Describe the solution
and is understandable without needing to know about the context in which
this change was developed.
Hmm? This is a suggestion, feel free to rewrite it in you own words. The
same applies to other change logs as well. I won't comment on those.
> static ssize_t cpu_show_common(struct device *dev, struct device_attribute
> *attr,
> char *buf, unsigned int bug)
> {
> @@ -872,9 +888,8 @@ static ssize_t cpu_show_common(struct device *dev, struct
> device_attribute *attr
>
> case X86_BUG_SPECTRE_V2:
> return sprintf(buf, "%s%s%s%s%s%s\n",
> spectre_v2_strings[spectre_v2_enabled],
> -boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" :
> "",
> boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ",
> IBRS_FW" : "",
> -(x86_spec_ctrl_base & SPEC_CTRL_STIBP) ? ",
> STIBP" : "",
> +ibpb_state(), stibp_state(),
> boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB
> filling" : "",
> spectre_v2_module_string());
Any particular reason for changing the output ordering here? If yes, then
the changelog should mention it. If no, why?
Thanks,
tglx
Re: [Patch v4 03/18] x86/speculation: Reorganize cpu_show_common()
Tim,
On Tue, 30 Oct 2018, Tim Chen wrote:
> Extract the logic to show IBPB, STIBP usages in cpu_show_common()
> into helper functions.
>
> Later patches will add other userspace Spectre v2 mitigation modes.
> This patch makes it easy to show IBPB and STIBP
> usage scenario according to the mitigation mode.
First of all, I asked you before to do:
# git grep 'This patch' Documentation/process
This leads you to:
"Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour."
Documentation is there for a reason.
Aside of that, I'd really have a hard time to figure out what you are
trying to say, if I didn't have the context already. Change logs need to
make sense on their own. So something like this:
The Spectre V2 printout in cpu_show_common() handles conditionals for the
various mitigation methods directly in the sprintf() argument list. That's
hard to read and will become unreadable if more complex decisions need to
be made for a particular method.
Move the conditionals for STIBP and IBPB string selection into helper
functions, so they can be extended later on.
follows the obvious ordering for change logs:
1) Describe context and problem
2) Describe the solution
and is understandable without needing to know about the context in which
this change was developed.
Hmm? This is a suggestion, feel free to rewrite it in you own words. The
same applies to other change logs as well. I won't comment on those.
> static ssize_t cpu_show_common(struct device *dev, struct device_attribute
> *attr,
> char *buf, unsigned int bug)
> {
> @@ -872,9 +888,8 @@ static ssize_t cpu_show_common(struct device *dev, struct
> device_attribute *attr
>
> case X86_BUG_SPECTRE_V2:
> return sprintf(buf, "%s%s%s%s%s%s\n",
> spectre_v2_strings[spectre_v2_enabled],
> -boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" :
> "",
> boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ",
> IBRS_FW" : "",
> -(x86_spec_ctrl_base & SPEC_CTRL_STIBP) ? ",
> STIBP" : "",
> +ibpb_state(), stibp_state(),
> boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB
> filling" : "",
> spectre_v2_module_string());
Any particular reason for changing the output ordering here? If yes, then
the changelog should mention it. If no, why?
Thanks,
tglx
Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver
Hi Jerome,
Thanks for the review, we really appreciate your time.
I'm very sorry maybe I don't catch all your meaning very well.
Please see my comments below.
On 2018/10/29 3:16, Jerome Brunet wrote:
> On Thu, 2018-10-25 at 22:58 +0200, Martin Blumenstingl wrote:
>> Hi Jerome,
>>
>> On Thu, Oct 25, 2018 at 2:54 PM Jerome Brunet wrote:
>> [snip]
>> +static void clk_regmap_div_init(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct clk_regmap_div_data *div = clk_get_regmap_div_data(clk);
>> + unsigned int val;
>> + int ret;
>> +
>> + ret = regmap_read(clk->map, div->offset, );
>> + if (ret)
>> + return;
>>
>> + val &= (clk_div_mask(div->width) << div->shift);
>> + if (!val)
>> + regmap_update_bits(clk->map, div->offset,
>> +clk_div_mask(div->width) << div->shift,
>> +clk_div_mask(div->width));
>
> This is wrong for several reasons:
> * You should hard code the initial value in the driver.
> * If shift is not 0, I doubt this will give the expected result.
The value 0x00 of divider means nand clock off then read/write nand
register is forbidden.
>>>
>>> That is not entirely true, you can access the clock register or you'd be in
>>> a
>>> chicken and egg situation.
>>>
Should we set the initial value in nand driver, or in sub emmc clk driver?
>>>
>>> In the nand driver, which is the consumer of the clock. see my previous
>>> comments
>>> about it.
>>
>> an old version of this series had the code still in the NAND driver
>> (by writing to the registers directly instead of using the clk API).
>> this looks pretty much like a "sclk-div" to me (as I commented in v3
>> of this series: [0]):
>> - value 0 means disabled
>> - positive divider values
>> - (probably no duty control, but that's optional as far as I
>> understand sclk-div)
>> - uses max divider value when enabling the clock
>>
>> if switching to sclk-div works then we can get rid of some duplicate code
>
> It is possible:
> There is a couple of things to note though:
>
> * sclk does not 'uses max divider value when enabling the clock': Since this
> divider can gate, it needs to save the divider value when disabling, since the
> divider value is no longer stored in the register,
> On init, this cached value is saved as it is. If the divider is initially
> disabled, we have to set the cached value to something that makes sense, in
> case
> the clock is enabled without a prior call to clk_set_rate().
>> So in sclk, the clock setting is not changed nor hard coded in init, and
>> this is
> a very important difference.
>
I think It's ok for the latest sub mmc clock and nand driver now:
1. in mmc_clkc_register_clk_with_parent("div", ...) from mmc_clkc_probe():
cached_div is set to div_max durning clk register，but is not set to div hw
register.
2. In meson nand driver v6:
https://lore.kernel.org/lkml/1541090542-19618-3-git-send-email-jianxin@amlogic.com
1) In meson_nfc_clk_init() from probe: get clock handle, then prepare_enable
and set default rate.
nfc->device_clk = devm_clk_get(nfc->dev, "device");
ret = clk_prepare_enable(nfc->device_clk); //Here div hw
register changed from 0 -> cached_div.
default_clk_rate = clk_round_rate(nfc->device_clk, 2400);
ret = clk_set_rate(nfc->device_clk, default_clk_rate); //Then register
and cached_div are both updated to the default 24M.
2) In meson_nfc_select_chip(), set the actual frequency
ret = clk_set_rate(nfc->device_clk, meson_chip->clk_rate);//Here register
and cached_div are changed again.
3) if clk_disable() is called, set div hw register to zero, and cached_div
keep unchagned.
if clk_disable() is called again, cached_div is restored to div hw register.
When enabling the clock, divider register does not need to be div_max.
Any value is OK except ZERO, the cached_div from init or set_rate is ok
>
> * Even if sclk zero value means gated, it is still a zero based divider, while
> eMMC/Nand divider is one based. It this controller was to sclk, then something
> needs to be done for this.
Could I add another patch to this patchset for sclk to support
CLK_DIVIDER_ONE_BASED ?
>
> * Since sclk caches a value in its data, and there can multiple instance of
> eMMC
> /NAND clock controller, some care must be taken when registering the data.
OK, I will fix it and alloc mmc_clkc_div_data danymicly durning probe.
Thank you.
>
> Both the generic divider and sclk could work here ... it's up to you Jianxin.
>
== Why use meson_sclk_div_ops instead of clk_regmap_divider_ops?
The default divider hw register vaule is 0 when system power on.
Then there is a WARNING in divider_recalc_rate() durning clk_hw_register():
[0.918238] ffe05000.clock-controller#div: Zero divisor and
CLK_DIVIDER_ALLOW_ZERO not set
[0.925581] WARNING: CPU: 3
Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver
Hi Jerome,
Thanks for the review, we really appreciate your time.
I'm very sorry maybe I don't catch all your meaning very well.
Please see my comments below.
On 2018/10/29 3:16, Jerome Brunet wrote:
> On Thu, 2018-10-25 at 22:58 +0200, Martin Blumenstingl wrote:
>> Hi Jerome,
>>
>> On Thu, Oct 25, 2018 at 2:54 PM Jerome Brunet wrote:
>> [snip]
>> +static void clk_regmap_div_init(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct clk_regmap_div_data *div = clk_get_regmap_div_data(clk);
>> + unsigned int val;
>> + int ret;
>> +
>> + ret = regmap_read(clk->map, div->offset, );
>> + if (ret)
>> + return;
>>
>> + val &= (clk_div_mask(div->width) << div->shift);
>> + if (!val)
>> + regmap_update_bits(clk->map, div->offset,
>> +clk_div_mask(div->width) << div->shift,
>> +clk_div_mask(div->width));
>
> This is wrong for several reasons:
> * You should hard code the initial value in the driver.
> * If shift is not 0, I doubt this will give the expected result.
The value 0x00 of divider means nand clock off then read/write nand
register is forbidden.
>>>
>>> That is not entirely true, you can access the clock register or you'd be in
>>> a
>>> chicken and egg situation.
>>>
Should we set the initial value in nand driver, or in sub emmc clk driver?
>>>
>>> In the nand driver, which is the consumer of the clock. see my previous
>>> comments
>>> about it.
>>
>> an old version of this series had the code still in the NAND driver
>> (by writing to the registers directly instead of using the clk API).
>> this looks pretty much like a "sclk-div" to me (as I commented in v3
>> of this series: [0]):
>> - value 0 means disabled
>> - positive divider values
>> - (probably no duty control, but that's optional as far as I
>> understand sclk-div)
>> - uses max divider value when enabling the clock
>>
>> if switching to sclk-div works then we can get rid of some duplicate code
>
> It is possible:
> There is a couple of things to note though:
>
> * sclk does not 'uses max divider value when enabling the clock': Since this
> divider can gate, it needs to save the divider value when disabling, since the
> divider value is no longer stored in the register,
> On init, this cached value is saved as it is. If the divider is initially
> disabled, we have to set the cached value to something that makes sense, in
> case
> the clock is enabled without a prior call to clk_set_rate().
>> So in sclk, the clock setting is not changed nor hard coded in init, and
>> this is
> a very important difference.
>
I think It's ok for the latest sub mmc clock and nand driver now:
1. in mmc_clkc_register_clk_with_parent("div", ...) from mmc_clkc_probe():
cached_div is set to div_max durning clk register，but is not set to div hw
register.
2. In meson nand driver v6:
https://lore.kernel.org/lkml/1541090542-19618-3-git-send-email-jianxin@amlogic.com
1) In meson_nfc_clk_init() from probe: get clock handle, then prepare_enable
and set default rate.
nfc->device_clk = devm_clk_get(nfc->dev, "device");
ret = clk_prepare_enable(nfc->device_clk); //Here div hw
register changed from 0 -> cached_div.
default_clk_rate = clk_round_rate(nfc->device_clk, 2400);
ret = clk_set_rate(nfc->device_clk, default_clk_rate); //Then register
and cached_div are both updated to the default 24M.
2) In meson_nfc_select_chip(), set the actual frequency
ret = clk_set_rate(nfc->device_clk, meson_chip->clk_rate);//Here register
and cached_div are changed again.
3) if clk_disable() is called, set div hw register to zero, and cached_div
keep unchagned.
if clk_disable() is called again, cached_div is restored to div hw register.
When enabling the clock, divider register does not need to be div_max.
Any value is OK except ZERO, the cached_div from init or set_rate is ok
>
> * Even if sclk zero value means gated, it is still a zero based divider, while
> eMMC/Nand divider is one based. It this controller was to sclk, then something
> needs to be done for this.
Could I add another patch to this patchset for sclk to support
CLK_DIVIDER_ONE_BASED ?
>
> * Since sclk caches a value in its data, and there can multiple instance of
> eMMC
> /NAND clock controller, some care must be taken when registering the data.
OK, I will fix it and alloc mmc_clkc_div_data danymicly durning probe.
Thank you.
>
> Both the generic divider and sclk could work here ... it's up to you Jianxin.
>
== Why use meson_sclk_div_ops instead of clk_regmap_divider_ops?
The default divider hw register vaule is 0 when system power on.
Then there is a WARNING in divider_recalc_rate() durning clk_hw_register():
[0.918238] ffe05000.clock-controller#div: Zero divisor and
CLK_DIVIDER_ALLOW_ZERO not set
[0.925581] WARNING: CPU: 3
Re: [GIT PULL] arm64 2nd round of updates for 4.20
On Sat, Nov 3, 2018 at 3:41 AM Catalin Marinas wrote: > > arm64 2nd round of updates for 4.20: Pulled, Linus
Re: [GIT PULL] arm64 2nd round of updates for 4.20
On Sat, Nov 3, 2018 at 3:41 AM Catalin Marinas wrote: > > arm64 2nd round of updates for 4.20: Pulled, Linus
Re: [GIT PULL] more Kbuild updates for v4.20
On Sat, Nov 3, 2018 at 12:58 AM Masahiro Yamada wrote: > > Please pull a little more Kbuild updates. Pulled, Linus
Re: [GIT PULL] more Kbuild updates for v4.20
On Sat, Nov 3, 2018 at 12:58 AM Masahiro Yamada wrote: > > Please pull a little more Kbuild updates. Pulled, Linus
[PATCH] vt: Fix screen updates after CSI K sequences
In d8ae72427187, start was changed to point to the character under the
cursor, instead of the beginning of the cleared area. The offset was
correctly applied when clearing the backing buffer, but not when
updating the framebuffer region. Fix this by having start point once
again to the beginning of the cleared area.
Cc: sta...@vger.kernel.org
Fixes: d8ae72427187 ("vt: preserve unicode values corresponding to screen
characters")
Signed-off-by: Samuel Holland
---
drivers/tty/vt/vt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 5f1183b0b89d..be7bc83d6c41 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1528,7 +1528,7 @@ static void csi_J(struct vc_data *vc, int vpar)
static void csi_K(struct vc_data *vc, int vpar)
{
unsigned int count;
- unsigned short *start = (unsigned short *)vc->vc_pos;
+ unsigned short *start;
int offset;
switch (vpar) {
@@ -1548,7 +1548,8 @@ static void csi_K(struct vc_data *vc, int vpar)
return;
}
vc_uniscr_clear_line(vc, vc->vc_x + offset, count);
- scr_memsetw(start + offset, vc->vc_video_erase_char, 2 * count);
+ start = (unsigned short *)vc->vc_pos + offset;
+ scr_memsetw(start, vc->vc_video_erase_char, 2 * count);
vc->vc_need_wrap = 0;
if (con_should_update(vc))
do_update_region(vc, (unsigned long) start, count);
--
2.18.1
[PATCH] vt: Fix screen updates after CSI K sequences
In d8ae72427187, start was changed to point to the character under the
cursor, instead of the beginning of the cleared area. The offset was
correctly applied when clearing the backing buffer, but not when
updating the framebuffer region. Fix this by having start point once
again to the beginning of the cleared area.
Cc: sta...@vger.kernel.org
Fixes: d8ae72427187 ("vt: preserve unicode values corresponding to screen
characters")
Signed-off-by: Samuel Holland
---
drivers/tty/vt/vt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 5f1183b0b89d..be7bc83d6c41 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1528,7 +1528,7 @@ static void csi_J(struct vc_data *vc, int vpar)
static void csi_K(struct vc_data *vc, int vpar)
{
unsigned int count;
- unsigned short *start = (unsigned short *)vc->vc_pos;
+ unsigned short *start;
int offset;
switch (vpar) {
@@ -1548,7 +1548,8 @@ static void csi_K(struct vc_data *vc, int vpar)
return;
}
vc_uniscr_clear_line(vc, vc->vc_x + offset, count);
- scr_memsetw(start + offset, vc->vc_video_erase_char, 2 * count);
+ start = (unsigned short *)vc->vc_pos + offset;
+ scr_memsetw(start, vc->vc_video_erase_char, 2 * count);
vc->vc_need_wrap = 0;
if (con_should_update(vc))
do_update_region(vc, (unsigned long) start, count);
--
2.18.1
RE: [PATCH 2/5] perf tools: Use fallback for sample_addr_correlates_sym() cases
> -Original Message-
> From: Hunter, Adrian
> Sent: Wednesday, October 31, 2018 11:11 AM
> To: Arnaldo Carvalho de Melo
> Cc: Jiri Olsa ; Andi Kleen ; linux-
> ker...@vger.kernel.org; leo@linaro.org; David Miller
> ; Mathieu Poirier
> Subject: [PATCH 2/5] perf tools: Use fallback for
> sample_addr_correlates_sym() cases
>
> thread__resolve() is used in the sample_addr_correlates_sym() cases where
> 'addr' is a destination of a branch which does not necessarily have the
> same cpumode as the 'ip'. Use the fallback function in that case.
>
> This patch depends on patch "perf tools: Add fallback functions for cases
> where cpumode is insufficient".
>
> Signed-off-by: Adrian Hunter
> Cc: sta...@vger.kernel.org # 4.19
Any comments?
> ---
> tools/perf/util/event.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index 52b24b8ce29e..316f62ffa27b 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
> @@ -1705,7 +1705,7 @@ bool sample_addr_correlates_sym(struct
> perf_event_attr *attr)
> void thread__resolve(struct thread *thread, struct addr_location *al,
>struct perf_sample *sample)
> {
> - thread__find_map(thread, sample->cpumode, sample->addr, al);
> + thread__find_map_fallback(thread, sample->cpumode, sample-
> >addr, al);
>
> al->cpu = sample->cpu;
> al->sym = NULL;
> --
> 2.17.1
RE: [PATCH 2/5] perf tools: Use fallback for sample_addr_correlates_sym() cases
> -Original Message-
> From: Hunter, Adrian
> Sent: Wednesday, October 31, 2018 11:11 AM
> To: Arnaldo Carvalho de Melo
> Cc: Jiri Olsa ; Andi Kleen ; linux-
> ker...@vger.kernel.org; leo@linaro.org; David Miller
> ; Mathieu Poirier
> Subject: [PATCH 2/5] perf tools: Use fallback for
> sample_addr_correlates_sym() cases
>
> thread__resolve() is used in the sample_addr_correlates_sym() cases where
> 'addr' is a destination of a branch which does not necessarily have the
> same cpumode as the 'ip'. Use the fallback function in that case.
>
> This patch depends on patch "perf tools: Add fallback functions for cases
> where cpumode is insufficient".
>
> Signed-off-by: Adrian Hunter
> Cc: sta...@vger.kernel.org # 4.19
Any comments?
> ---
> tools/perf/util/event.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index 52b24b8ce29e..316f62ffa27b 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
> @@ -1705,7 +1705,7 @@ bool sample_addr_correlates_sym(struct
> perf_event_attr *attr)
> void thread__resolve(struct thread *thread, struct addr_location *al,
>struct perf_sample *sample)
> {
> - thread__find_map(thread, sample->cpumode, sample->addr, al);
> + thread__find_map_fallback(thread, sample->cpumode, sample-
> >addr, al);
>
> al->cpu = sample->cpu;
> al->sym = NULL;
> --
> 2.17.1
Re: [RFC PATCH] tracing/kprobes: Avoid parsing symbol+offset when updating arguments
On Sun, 4 Nov 2018 01:03:34 +0900
Masami Hiramatsu wrote:
> Introduce symbol_offset data structure for avoiding symbol+offset
> parsing when updating arguments.
>
> For kprobe events, "@symbol+offset" is supported, that requires
> to be updated when new module is loaded because @symbol address
> can be solved at that point. Currently kprobe events saves
> the "symbol+offset" string and parse it repeatedly, but that
> is inefficient.
Do we care if it's inefficient? It's only done on module load and at
the beginning. That's far from a fast path.
If anything, the original solution saves memory, which is a bigger
concern than speed in this case.
-- Steve
> This introduces symbol_offset data structure which can save the
> offset and symbol separated, so that we don't need to parse it
> anymore.
>
> Signed-off-by: Masami Hiramatsu
> ---
> kernel/trace/trace_probe.c | 49
> +---
> kernel/trace/trace_probe.h |7 +-
> 2 files changed, 34 insertions(+), 22 deletions(-)
>
> diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
> index bd30e9398d2a..0a3af7d6e133 100644
> --- a/kernel/trace/trace_probe.c
> +++ b/kernel/trace/trace_probe.c
> @@ -201,6 +201,26 @@ static int parse_probe_vars(char *arg, const struct
> fetch_type *t,
> return ret;
> }
>
> +static struct symbol_offset *allocate_symbol_offset(char *sym_offs_str)
> +{
> + int ret;
> + long offset = 0;
> + struct symbol_offset *sof;
> +
> + ret = traceprobe_split_symbol_offset(sym_offs_str, );
> + if (ret)
> + return ERR_PTR(ret);
> +
> + sof = kzalloc(sizeof(struct symbol_offset) + strlen(sym_offs_str) + 1,
> + GFP_KERNEL);
> + if (!sof)
> + return ERR_PTR(-ENOMEM);
> +
> + sof->offset = offset;
> + strcpy(sof->symbol, sym_offs_str);
> + return sof;
> +}
> +
> /* Recursive argument parser */
> static int
> parse_probe_arg(char *arg, const struct fetch_type *type,
> @@ -253,9 +273,9 @@ parse_probe_arg(char *arg, const struct fetch_type *type,
>
> /* Preserve symbol for updating */
> code->op = FETCH_NOP_SYMBOL;
> - code->data = kstrdup(arg + 1, GFP_KERNEL);
> - if (!code->data)
> - return -ENOMEM;
> + code->symoffs = allocate_symbol_offset(arg + 1);
> + if (IS_ERR(code->symoffs))
> + return PTR_ERR(code->symoffs);
> if (++code == end)
> return -E2BIG;
>
> @@ -483,7 +503,7 @@ int traceprobe_parse_probe_arg(char *arg, ssize_t *size,
> if (ret) {
> for (code = tmp; code < tmp + FETCH_INSN_MAX; code++)
> if (code->op == FETCH_NOP_SYMBOL)
> - kfree(code->data);
> + kfree(code->symoffs);
> }
> kfree(tmp);
>
> @@ -513,7 +533,7 @@ void traceprobe_free_probe_arg(struct probe_arg *arg)
>
> while (code && code->op != FETCH_OP_END) {
> if (code->op == FETCH_NOP_SYMBOL)
> - kfree(code->data);
> + kfree(code->symoffs);
> code++;
> }
> kfree(arg->code);
> @@ -525,31 +545,18 @@ void traceprobe_free_probe_arg(struct probe_arg *arg)
> int traceprobe_update_arg(struct probe_arg *arg)
> {
> struct fetch_insn *code = arg->code;
> - long offset;
> - char *tmp;
> - char c;
> - int ret = 0;
>
> while (code && code->op != FETCH_OP_END) {
> if (code->op == FETCH_NOP_SYMBOL) {
> if (code[1].op != FETCH_OP_IMM)
> return -EINVAL;
>
> - tmp = strpbrk(code->data, "+-");
> - if (tmp)
> - c = *tmp;
> - ret = traceprobe_split_symbol_offset(code->data,
> - );
> - if (ret)
> - return ret;
> -
> code[1].immediate =
> - (unsigned long)kallsyms_lookup_name(code->data);
> - if (tmp)
> - *tmp = c;
> + (unsigned long)kallsyms_lookup_name(
> + code->symoffs->symbol);
> if (!code[1].immediate)
> return -ENOENT;
> - code[1].immediate += offset;
> + code[1].immediate += code->symoffs->offset;
> }
> code++;
> }
> diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
> index 974afc1a3e73..942424d05427 100644
> --- a/kernel/trace/trace_probe.h
> +++ b/kernel/trace/trace_probe.h
> @@ -103,6 +103,11 @@ enum fetch_op {
Re: [RFC PATCH] tracing/kprobes: Avoid parsing symbol+offset when updating arguments
On Sun, 4 Nov 2018 01:03:34 +0900
Masami Hiramatsu wrote:
> Introduce symbol_offset data structure for avoiding symbol+offset
> parsing when updating arguments.
>
> For kprobe events, "@symbol+offset" is supported, that requires
> to be updated when new module is loaded because @symbol address
> can be solved at that point. Currently kprobe events saves
> the "symbol+offset" string and parse it repeatedly, but that
> is inefficient.
Do we care if it's inefficient? It's only done on module load and at
the beginning. That's far from a fast path.
If anything, the original solution saves memory, which is a bigger
concern than speed in this case.
-- Steve
> This introduces symbol_offset data structure which can save the
> offset and symbol separated, so that we don't need to parse it
> anymore.
>
> Signed-off-by: Masami Hiramatsu
> ---
> kernel/trace/trace_probe.c | 49
> +---
> kernel/trace/trace_probe.h |7 +-
> 2 files changed, 34 insertions(+), 22 deletions(-)
>
> diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
> index bd30e9398d2a..0a3af7d6e133 100644
> --- a/kernel/trace/trace_probe.c
> +++ b/kernel/trace/trace_probe.c
> @@ -201,6 +201,26 @@ static int parse_probe_vars(char *arg, const struct
> fetch_type *t,
> return ret;
> }
>
> +static struct symbol_offset *allocate_symbol_offset(char *sym_offs_str)
> +{
> + int ret;
> + long offset = 0;
> + struct symbol_offset *sof;
> +
> + ret = traceprobe_split_symbol_offset(sym_offs_str, );
> + if (ret)
> + return ERR_PTR(ret);
> +
> + sof = kzalloc(sizeof(struct symbol_offset) + strlen(sym_offs_str) + 1,
> + GFP_KERNEL);
> + if (!sof)
> + return ERR_PTR(-ENOMEM);
> +
> + sof->offset = offset;
> + strcpy(sof->symbol, sym_offs_str);
> + return sof;
> +}
> +
> /* Recursive argument parser */
> static int
> parse_probe_arg(char *arg, const struct fetch_type *type,
> @@ -253,9 +273,9 @@ parse_probe_arg(char *arg, const struct fetch_type *type,
>
> /* Preserve symbol for updating */
> code->op = FETCH_NOP_SYMBOL;
> - code->data = kstrdup(arg + 1, GFP_KERNEL);
> - if (!code->data)
> - return -ENOMEM;
> + code->symoffs = allocate_symbol_offset(arg + 1);
> + if (IS_ERR(code->symoffs))
> + return PTR_ERR(code->symoffs);
> if (++code == end)
> return -E2BIG;
>
> @@ -483,7 +503,7 @@ int traceprobe_parse_probe_arg(char *arg, ssize_t *size,
> if (ret) {
> for (code = tmp; code < tmp + FETCH_INSN_MAX; code++)
> if (code->op == FETCH_NOP_SYMBOL)
> - kfree(code->data);
> + kfree(code->symoffs);
> }
> kfree(tmp);
>
> @@ -513,7 +533,7 @@ void traceprobe_free_probe_arg(struct probe_arg *arg)
>
> while (code && code->op != FETCH_OP_END) {
> if (code->op == FETCH_NOP_SYMBOL)
> - kfree(code->data);
> + kfree(code->symoffs);
> code++;
> }
> kfree(arg->code);
> @@ -525,31 +545,18 @@ void traceprobe_free_probe_arg(struct probe_arg *arg)
> int traceprobe_update_arg(struct probe_arg *arg)
> {
> struct fetch_insn *code = arg->code;
> - long offset;
> - char *tmp;
> - char c;
> - int ret = 0;
>
> while (code && code->op != FETCH_OP_END) {
> if (code->op == FETCH_NOP_SYMBOL) {
> if (code[1].op != FETCH_OP_IMM)
> return -EINVAL;
>
> - tmp = strpbrk(code->data, "+-");
> - if (tmp)
> - c = *tmp;
> - ret = traceprobe_split_symbol_offset(code->data,
> - );
> - if (ret)
> - return ret;
> -
> code[1].immediate =
> - (unsigned long)kallsyms_lookup_name(code->data);
> - if (tmp)
> - *tmp = c;
> + (unsigned long)kallsyms_lookup_name(
> + code->symoffs->symbol);
> if (!code[1].immediate)
> return -ENOENT;
> - code[1].immediate += offset;
> + code[1].immediate += code->symoffs->offset;
> }
> code++;
> }
> diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
> index 974afc1a3e73..942424d05427 100644
> --- a/kernel/trace/trace_probe.h
> +++ b/kernel/trace/trace_probe.h
> @@ -103,6 +103,11 @@ enum fetch_op {
Re: [PATCH 4/5] b43: Use common cordic algorithm from kernel lib
On 11/3/18 4:59 AM, Priit Laes wrote:
Signed-off-by: Priit Laes
Where is the commit message? The stuff in the cover letter (Patch 0/N) never
makes it to the git repository. You must have a message in each of the
individual patches.
NACK.
Larry
---
drivers/net/wireless/broadcom/b43/Kconfig | 1 +
drivers/net/wireless/broadcom/b43/phy_lp.c | 13 +++--
drivers/net/wireless/broadcom/b43/phy_n.c | 13 +++--
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/Kconfig
b/drivers/net/wireless/broadcom/b43/Kconfig
index fba8560..3e41457 100644
--- a/drivers/net/wireless/broadcom/b43/Kconfig
+++ b/drivers/net/wireless/broadcom/b43/Kconfig
@@ -4,6 +4,7 @@ config B43
select BCMA if B43_BCMA
select SSB if B43_SSB
select FW_LOADER
+ select CORDIC
---help---
b43 is a driver for the Broadcom 43xx series wireless devices.
diff --git a/drivers/net/wireless/broadcom/b43/phy_lp.c b/drivers/net/wireless/broadcom/b43/phy_lp.c
index 6922cbb..1718e3b 100644
--- a/drivers/net/wireless/broadcom/b43/phy_lp.c
+++ b/drivers/net/wireless/broadcom/b43/phy_lp.c
@@ -23,6 +23,7 @@
*/
+#include
#include
#include "b43.h"
@@ -1780,9 +1781,9 @@ static void lpphy_start_tx_tone(struct b43_wldev *dev,
s32 freq, u16 max)
{
struct b43_phy_lp *lpphy = dev->phy.lp;
u16 buf[64];
- int i, samples = 0, angle = 0;
+ int i, samples = 0, theta = 0;
int rotation = (((36 * freq) / 20) << 16) / 100;
- struct b43_c32 sample;
+ struct cordic_iq sample;
lpphy->tx_tone_freq = freq;
@@ -1798,10 +1799,10 @@ static void lpphy_start_tx_tone(struct b43_wldev *dev, s32 freq, u16 max)
}
for (i = 0; i < samples; i++) {
- sample = b43_cordic(angle);
- angle += rotation;
- buf[i] = CORDIC_CONVERT((sample.i * max) & 0xFF) << 8;
- buf[i] |= CORDIC_CONVERT((sample.q * max) & 0xFF);
+ sample = cordic_calc_iq(theta);
+ theta += rotation;
+ buf[i] = CORDIC_FLOAT((sample.i * max) & 0xFF) << 8;
+ buf[i] |= CORDIC_FLOAT((sample.q * max) & 0xFF);
}
b43_lptab_write_bulk(dev, B43_LPTAB16(5, 0), samples, buf);
diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
b/drivers/net/wireless/broadcom/b43/phy_n.c
index 44ab080..1f9378a 100644
--- a/drivers/net/wireless/broadcom/b43/phy_n.c
+++ b/drivers/net/wireless/broadcom/b43/phy_n.c
@@ -23,6 +23,7 @@
*/
+#include
#include
#include
#include
@@ -1513,7 +1514,7 @@ static void b43_radio_init2055(struct b43_wldev *dev)
/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/LoadSampleTable */
static int b43_nphy_load_samples(struct b43_wldev *dev,
- struct b43_c32 *samples, u16 len) {
+ struct cordic_iq *samples, u16 len) {
struct b43_phy_n *nphy = dev->phy.n;
u16 i;
u32 *data;
@@ -1544,7 +1545,7 @@ static u16 b43_nphy_gen_load_samples(struct b43_wldev
*dev, u32 freq, u16 max,
{
int i;
u16 bw, len, rot, angle;
- struct b43_c32 *samples;
+ struct cordic_iq *samples;
bw = b43_is_40mhz(dev) ? 40 : 20;
len = bw << 3;
@@ -1561,7 +1562,7 @@ static u16 b43_nphy_gen_load_samples(struct b43_wldev
*dev, u32 freq, u16 max,
len = bw << 1;
}
- samples = kcalloc(len, sizeof(struct b43_c32), GFP_KERNEL);
+ samples = kcalloc(len, sizeof(struct cordic_iq), GFP_KERNEL);
if (!samples) {
b43err(dev->wl, "allocation for samples generation failed\n");
return 0;
@@ -1570,10 +1571,10 @@ static u16 b43_nphy_gen_load_samples(struct b43_wldev
*dev, u32 freq, u16 max,
angle = 0;
for (i = 0; i < len; i++) {
- samples[i] = b43_cordic(angle);
+ samples[i] = cordic_calc_iq(angle);
angle += rot;
- samples[i].q = CORDIC_CONVERT(samples[i].q * max);
- samples[i].i = CORDIC_CONVERT(samples[i].i * max);
+ samples[i].q = CORDIC_FLOAT(samples[i].q * max);
+ samples[i].i = CORDIC_FLOAT(samples[i].i * max);
}
i = b43_nphy_load_samples(dev, samples, len);
Re: [git pull] followup fix to work.afs
On Fri, Nov 2, 2018 at 5:06 PM Al Viro wrote: > > Regression fix for net/9p handling of iov_iter; broken > by braino when switching to iov_iter_is_kvec() et.al., spotted > and fixed by Marc. Pulled, Linus
Re: [PATCH 4/5] b43: Use common cordic algorithm from kernel lib
On 11/3/18 4:59 AM, Priit Laes wrote:
Signed-off-by: Priit Laes
Where is the commit message? The stuff in the cover letter (Patch 0/N) never
makes it to the git repository. You must have a message in each of the
individual patches.
NACK.
Larry
---
drivers/net/wireless/broadcom/b43/Kconfig | 1 +
drivers/net/wireless/broadcom/b43/phy_lp.c | 13 +++--
drivers/net/wireless/broadcom/b43/phy_n.c | 13 +++--
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/Kconfig
b/drivers/net/wireless/broadcom/b43/Kconfig
index fba8560..3e41457 100644
--- a/drivers/net/wireless/broadcom/b43/Kconfig
+++ b/drivers/net/wireless/broadcom/b43/Kconfig
@@ -4,6 +4,7 @@ config B43
select BCMA if B43_BCMA
select SSB if B43_SSB
select FW_LOADER
+ select CORDIC
---help---
b43 is a driver for the Broadcom 43xx series wireless devices.
diff --git a/drivers/net/wireless/broadcom/b43/phy_lp.c b/drivers/net/wireless/broadcom/b43/phy_lp.c
index 6922cbb..1718e3b 100644
--- a/drivers/net/wireless/broadcom/b43/phy_lp.c
+++ b/drivers/net/wireless/broadcom/b43/phy_lp.c
@@ -23,6 +23,7 @@
*/
+#include
#include
#include "b43.h"
@@ -1780,9 +1781,9 @@ static void lpphy_start_tx_tone(struct b43_wldev *dev,
s32 freq, u16 max)
{
struct b43_phy_lp *lpphy = dev->phy.lp;
u16 buf[64];
- int i, samples = 0, angle = 0;
+ int i, samples = 0, theta = 0;
int rotation = (((36 * freq) / 20) << 16) / 100;
- struct b43_c32 sample;
+ struct cordic_iq sample;
lpphy->tx_tone_freq = freq;
@@ -1798,10 +1799,10 @@ static void lpphy_start_tx_tone(struct b43_wldev *dev, s32 freq, u16 max)
}
for (i = 0; i < samples; i++) {
- sample = b43_cordic(angle);
- angle += rotation;
- buf[i] = CORDIC_CONVERT((sample.i * max) & 0xFF) << 8;
- buf[i] |= CORDIC_CONVERT((sample.q * max) & 0xFF);
+ sample = cordic_calc_iq(theta);
+ theta += rotation;
+ buf[i] = CORDIC_FLOAT((sample.i * max) & 0xFF) << 8;
+ buf[i] |= CORDIC_FLOAT((sample.q * max) & 0xFF);
}
b43_lptab_write_bulk(dev, B43_LPTAB16(5, 0), samples, buf);
diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
b/drivers/net/wireless/broadcom/b43/phy_n.c
index 44ab080..1f9378a 100644
--- a/drivers/net/wireless/broadcom/b43/phy_n.c
+++ b/drivers/net/wireless/broadcom/b43/phy_n.c
@@ -23,6 +23,7 @@
*/
+#include
#include
#include
#include
@@ -1513,7 +1514,7 @@ static void b43_radio_init2055(struct b43_wldev *dev)
/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/LoadSampleTable */
static int b43_nphy_load_samples(struct b43_wldev *dev,
- struct b43_c32 *samples, u16 len) {
+ struct cordic_iq *samples, u16 len) {
struct b43_phy_n *nphy = dev->phy.n;
u16 i;
u32 *data;
@@ -1544,7 +1545,7 @@ static u16 b43_nphy_gen_load_samples(struct b43_wldev
*dev, u32 freq, u16 max,
{
int i;
u16 bw, len, rot, angle;
- struct b43_c32 *samples;
+ struct cordic_iq *samples;
bw = b43_is_40mhz(dev) ? 40 : 20;
len = bw << 3;
@@ -1561,7 +1562,7 @@ static u16 b43_nphy_gen_load_samples(struct b43_wldev
*dev, u32 freq, u16 max,
len = bw << 1;
}
- samples = kcalloc(len, sizeof(struct b43_c32), GFP_KERNEL);
+ samples = kcalloc(len, sizeof(struct cordic_iq), GFP_KERNEL);
if (!samples) {
b43err(dev->wl, "allocation for samples generation failed\n");
return 0;
@@ -1570,10 +1571,10 @@ static u16 b43_nphy_gen_load_samples(struct b43_wldev
*dev, u32 freq, u16 max,
angle = 0;
for (i = 0; i < len; i++) {
- samples[i] = b43_cordic(angle);
+ samples[i] = cordic_calc_iq(angle);
angle += rot;
- samples[i].q = CORDIC_CONVERT(samples[i].q * max);
- samples[i].i = CORDIC_CONVERT(samples[i].i * max);
+ samples[i].q = CORDIC_FLOAT(samples[i].q * max);
+ samples[i].i = CORDIC_FLOAT(samples[i].i * max);
}
i = b43_nphy_load_samples(dev, samples, len);
Re: [git pull] followup fix to work.afs
On Fri, Nov 2, 2018 at 5:06 PM Al Viro wrote: > > Regression fix for net/9p handling of iov_iter; broken > by braino when switching to iov_iter_is_kvec() et.al., spotted > and fixed by Marc. Pulled, Linus
Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
On Sat, Nov 03, 2018 at 07:36:19PM +1100, NeilBrown wrote: > On Fri, Nov 02 2018, Paul E. McKenney wrote: > > > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote: > >> On Thu, Nov 01 2018, Paul E. McKenney wrote: > >> > >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: > >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: > >> >> > On Wed, Oct 24 2018, Josh Triplett wrote: > >> >> > > >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > >> >> > >> On Sun, Oct 21 2018, Josh Triplett wrote: > >> >> > >> > >> >> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote: > >> >> > >> >> I call on you, Greg: > >> >> > >> >> - to abandon this divisive attempt to impose a "Code of > >> >> > >> >> Conduct" > >> >> > >> >> - to revert 8a104f8b5867c68 > >> >> > >> >> - to return to your core competence of building a great team > >> >> > >> >> around > >> >> > >> >>a great kernel > >> >> > >> >> > >> >> > >> >> #Isupportreversion > >> >> > >> >> > >> >> > >> >> I call on the community to consider what *does* need to be > >> >> > >> >> said, about > >> >> > >> >> conduct, to people outside the community and who have recently > >> >> > >> >> joined. > >> >> > >> >> What is the document that you would have liked to have read as > >> >> > >> >> you were > >> >> > >> >> starting out? It is all too long ago for me to remember > >> >> > >> >> clearly, and so > >> >> > >> >> much has changed. > >> >> > >> > > >> >> > >> > The document I would have liked to have read when starting out is > >> >> > >> > currently checked into the source tree in > >> >> > >> > Documentation/process/code-of-conduct.rst . > >> >> > >> > >> >> > >> I'm curious - what would you have gained by reading that document? > >> >> > > > >> >> > > I would have then had rather less of a pervasive feeling of "if I > >> >> > > make > >> >> > > even a single mistake I get made an example of in ways that will > >> >> > > feed > >> >> > > people's quotes files for years to come". > >> >> > > >> >> > Thanks for your reply. Certainly feeling safe is important, and > >> >> > having > >> >> > clear statements that the community values and promotes psychological > >> >> > safety is valuable. > >> >> > > >> >> > The old "code of conflict" said > >> >> >If however, anyone feels personally abused, threatened, or > >> >> > otherwise > >> >> >uncomfortable due to this process, that is not acceptable. > >> >> > > >> >> > would you have not found this a strong enough statement to ward off > >> >> > that > >> >> > pervasive feeling? > >> >> > >> >> Not when that document started out effectively saying, in an elaborate > >> >> way, "code > people". > >> > > >> > Interesting. > >> > > >> > I am curious what leads you to your "code > people" statement. Of > >> > course, > >> > one could argue that this does not really matter given that the code of > >> > conflict is no longer. However, I would like to understand for future > >> > reference, if for no other reason. > >> > > >> > One possibility is that you are restricting the "people" to only those > >> > people directly contributing in one way or another. But those using the > >> > kernel (both directly and indirectly) are important as well, and it is > >> > exactly this group that is served by "the most robust operating system > >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in > >> > fact why I must reject (or rework or whatever) any patch that might > >> > result > >> > in too-short RCU grace periods: The needs of the patch's submitter are > >> > quite emphatically outweighed by the needs of the kernel's many users, > >> > and many of the various technical requirements and restrictions are in > >> > fact proxies for the needs of these users. > >> > > >> > But you knew that already. > >> > > >> > Similarly for the Linux kernel's various code-style strictures, which > >> > serve the surprisingly large group of people reading the kernel's code. > >> > Including the stricture that I most love to hate, which is the one > >> > stating that single-line do/for/if/while statements must not be enclosed > >> > in braces, which sometimes causes me trouble when inserting debug code, > >> > but which also makes more code fit into a window of a given size. ;-) > >> > > >> > But you knew that already, too. > >> > > >> > The maintainability requirements can be argued to mostly serve the > >> > maintainers, but if the code becomes unmaintainable, future users > >> > will be inconvenienced, to say the least. So even the maintainability > >> > requirements serve the kernel's many users. > >> > > >> > But you also knew that already. > >> > > >> > So what am I missing here? > >> > > >> > >> Hi Paul, > >> thanks for contributing your thoughts. It is nice to have a new voice > >> in the conversation, it helps me to maintain my illusion that this > >> issue is relevant to the whole community. > > > > I am
Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
On Sat, Nov 03, 2018 at 07:36:19PM +1100, NeilBrown wrote: > On Fri, Nov 02 2018, Paul E. McKenney wrote: > > > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote: > >> On Thu, Nov 01 2018, Paul E. McKenney wrote: > >> > >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote: > >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: > >> >> > On Wed, Oct 24 2018, Josh Triplett wrote: > >> >> > > >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: > >> >> > >> On Sun, Oct 21 2018, Josh Triplett wrote: > >> >> > >> > >> >> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote: > >> >> > >> >> I call on you, Greg: > >> >> > >> >> - to abandon this divisive attempt to impose a "Code of > >> >> > >> >> Conduct" > >> >> > >> >> - to revert 8a104f8b5867c68 > >> >> > >> >> - to return to your core competence of building a great team > >> >> > >> >> around > >> >> > >> >>a great kernel > >> >> > >> >> > >> >> > >> >> #Isupportreversion > >> >> > >> >> > >> >> > >> >> I call on the community to consider what *does* need to be > >> >> > >> >> said, about > >> >> > >> >> conduct, to people outside the community and who have recently > >> >> > >> >> joined. > >> >> > >> >> What is the document that you would have liked to have read as > >> >> > >> >> you were > >> >> > >> >> starting out? It is all too long ago for me to remember > >> >> > >> >> clearly, and so > >> >> > >> >> much has changed. > >> >> > >> > > >> >> > >> > The document I would have liked to have read when starting out is > >> >> > >> > currently checked into the source tree in > >> >> > >> > Documentation/process/code-of-conduct.rst . > >> >> > >> > >> >> > >> I'm curious - what would you have gained by reading that document? > >> >> > > > >> >> > > I would have then had rather less of a pervasive feeling of "if I > >> >> > > make > >> >> > > even a single mistake I get made an example of in ways that will > >> >> > > feed > >> >> > > people's quotes files for years to come". > >> >> > > >> >> > Thanks for your reply. Certainly feeling safe is important, and > >> >> > having > >> >> > clear statements that the community values and promotes psychological > >> >> > safety is valuable. > >> >> > > >> >> > The old "code of conflict" said > >> >> >If however, anyone feels personally abused, threatened, or > >> >> > otherwise > >> >> >uncomfortable due to this process, that is not acceptable. > >> >> > > >> >> > would you have not found this a strong enough statement to ward off > >> >> > that > >> >> > pervasive feeling? > >> >> > >> >> Not when that document started out effectively saying, in an elaborate > >> >> way, "code > people". > >> > > >> > Interesting. > >> > > >> > I am curious what leads you to your "code > people" statement. Of > >> > course, > >> > one could argue that this does not really matter given that the code of > >> > conflict is no longer. However, I would like to understand for future > >> > reference, if for no other reason. > >> > > >> > One possibility is that you are restricting the "people" to only those > >> > people directly contributing in one way or another. But those using the > >> > kernel (both directly and indirectly) are important as well, and it is > >> > exactly this group that is served by "the most robust operating system > >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in > >> > fact why I must reject (or rework or whatever) any patch that might > >> > result > >> > in too-short RCU grace periods: The needs of the patch's submitter are > >> > quite emphatically outweighed by the needs of the kernel's many users, > >> > and many of the various technical requirements and restrictions are in > >> > fact proxies for the needs of these users. > >> > > >> > But you knew that already. > >> > > >> > Similarly for the Linux kernel's various code-style strictures, which > >> > serve the surprisingly large group of people reading the kernel's code. > >> > Including the stricture that I most love to hate, which is the one > >> > stating that single-line do/for/if/while statements must not be enclosed > >> > in braces, which sometimes causes me trouble when inserting debug code, > >> > but which also makes more code fit into a window of a given size. ;-) > >> > > >> > But you knew that already, too. > >> > > >> > The maintainability requirements can be argued to mostly serve the > >> > maintainers, but if the code becomes unmaintainable, future users > >> > will be inconvenienced, to say the least. So even the maintainability > >> > requirements serve the kernel's many users. > >> > > >> > But you also knew that already. > >> > > >> > So what am I missing here? > >> > > >> > >> Hi Paul, > >> thanks for contributing your thoughts. It is nice to have a new voice > >> in the conversation, it helps me to maintain my illusion that this > >> issue is relevant to the whole community. > > > > I am
[PATCH] KEYS: fix parsing invalid pkey info string
From: Eric Biggers
We need to check the return value of match_token() for Opt_err (-1)
before doing anything with it.
Reported-by: syzbot+a22e0dc07567662c5...@syzkaller.appspotmail.com
Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for
asymmetric keys [ver #2]")
Signed-off-by: Eric Biggers
---
security/keys/keyctl_pkey.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/security/keys/keyctl_pkey.c b/security/keys/keyctl_pkey.c
index 783978842f13a..987fac8051d70 100644
--- a/security/keys/keyctl_pkey.c
+++ b/security/keys/keyctl_pkey.c
@@ -50,6 +50,8 @@ static int keyctl_pkey_params_parse(struct kernel_pkey_params
*params)
if (*p == '\0' || *p == ' ' || *p == '\t')
continue;
token = match_token(p, param_keys, args);
+ if (token == Opt_err)
+ return -EINVAL;
if (__test_and_set_bit(token, _mask))
return -EINVAL;
q = args[0].from;
--
2.19.1
[PATCH] KEYS: fix parsing invalid pkey info string
From: Eric Biggers
We need to check the return value of match_token() for Opt_err (-1)
before doing anything with it.
Reported-by: syzbot+a22e0dc07567662c5...@syzkaller.appspotmail.com
Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for
asymmetric keys [ver #2]")
Signed-off-by: Eric Biggers
---
security/keys/keyctl_pkey.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/security/keys/keyctl_pkey.c b/security/keys/keyctl_pkey.c
index 783978842f13a..987fac8051d70 100644
--- a/security/keys/keyctl_pkey.c
+++ b/security/keys/keyctl_pkey.c
@@ -50,6 +50,8 @@ static int keyctl_pkey_params_parse(struct kernel_pkey_params
*params)
if (*p == '\0' || *p == ' ' || *p == '\t')
continue;
token = match_token(p, param_keys, args);
+ if (token == Opt_err)
+ return -EINVAL;
if (__test_and_set_bit(token, _mask))
return -EINVAL;
q = args[0].from;
--
2.19.1
Re: [PATCH v2 5/6] staging:iio:ad2s90: Add IIO_CHAN_INFO_SCALE to channel spec and read_raw
On Sat, 3 Nov 2018 13:04:04 -0300
Matheus Tavares Bernardino wrote:
> On Sun, Oct 28, 2018 at 1:50 PM Jonathan Cameron wrote:
> >
> > On Fri, 26 Oct 2018 23:00:04 -0300
> > Matheus Tavares wrote:
> >
> > > This patch adds the IIO_CHAN_INFO_SCALE mask to ad2s90_chan and
> > > implements the relative read behavior at ad2s90_read_raw.
> > >
> > > Signed-off-by: Victor Colombo
> > > Signed-off-by: Matheus Tavares
> >
> > Hi,
> >
> > A suggestion inline. This is a common case that we have infrastructure
> > to simplify. + I think your scale factor is very slightly wrong.
> >
> > Jonathan
> >
> > > ---
> > > drivers/staging/iio/resolver/ad2s90.c | 32 ++-
> > > 1 file changed, 22 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/staging/iio/resolver/ad2s90.c
> > > b/drivers/staging/iio/resolver/ad2s90.c
> > > index b4a6a89c11b0..52b656875ed1 100644
> > > --- a/drivers/staging/iio/resolver/ad2s90.c
> > > +++ b/drivers/staging/iio/resolver/ad2s90.c
> > > @@ -34,19 +34,31 @@ static int ad2s90_read_raw(struct iio_dev *indio_dev,
> > > int ret;
> > > struct ad2s90_state *st = iio_priv(indio_dev);
> > >
> > > - mutex_lock(>lock);
> > > + switch (m) {
> > > + case IIO_CHAN_INFO_SCALE:
> > > + /* 2 * Pi / (2^12 - 1) ~= 0.001534355 */
> > > + *val = 0;
> > > + *val2 = 1534355;
> > Definitely 2^12 - 1? That's a bit unusual if true as it would imply
> > that 2^12 - 1 and 0 were the same value.
> >
> > Imagine a smaller version with on 2^2 bits so 0, 1, 2, 3
> > Values of each are
> >
> > 0, M_PI/2, M_PI, 3*M_PI/2
> >
> > So the multiplier is 2*M_PI/(2^2) not 2*M_PI/(2^2 - 1)
> > 1/2 vs 2/3 * M_PI
>
> Oh, that makes a lot of sense! We used 2^12 - 1 here based on driver
> drivers/iio/resolver/ad2s1200.c, whose resolution is also 12 bits, as
> the ad2s90.c. Do you think this section is, perhaps, wrong on
> ad2s1200.c too, or maybe there is some difference between these two
> drivers that I didn't catch regarding the resolution?
Certainly seems likely to be wrong. Difference is tiny so no one
probably ever noticed :(
Feel free to post a patch fixing that one as well!
Thanks,
Jonathan
>
> Matheus.
>
> > Now this is a very common case so we have the return type
> > IIO_VAL_FRACTIONAL_LOG2 to give a more obvious and potentially
> > more accurate representation.
> >
> > > + return IIO_VAL_INT_PLUS_NANO;
> > > + case IIO_CHAN_INFO_RAW:
> > > + mutex_lock(>lock);
> > > +
> > > + ret = spi_read(st->sdev, st->rx, 2);
> > > + if (ret < 0) {
> > > + mutex_unlock(>lock);
> > > + return ret;
> > > + }
> > > +
> > > + *val = (((u16)(st->rx[0])) << 4) | ((st->rx[1] & 0xF0) >>
> > > 4);
> > >
> > > - ret = spi_read(st->sdev, st->rx, 2);
> > > - if (ret < 0) {
> > > mutex_unlock(>lock);
> > > - return ret;
> > > - }
> > >
> > > - *val = (((u16)(st->rx[0])) << 4) | ((st->rx[1] & 0xF0) >> 4);
> > > -
> > > - mutex_unlock(>lock);
> > > + return IIO_VAL_INT;
> > > + default:
> > > + break;
> > > + }
> > >
> > > - return IIO_VAL_INT;
> > > + return -EINVAL;
> > > }
> > >
> > > static const struct iio_info ad2s90_info = {
> > > @@ -57,7 +69,7 @@ static const struct iio_chan_spec ad2s90_chan = {
> > > .type = IIO_ANGL,
> > > .indexed = 1,
> > > .channel = 0,
> > > - .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > > BIT(IIO_CHAN_INFO_SCALE),
> > > };
> > >
> > > static int ad2s90_probe(struct spi_device *spi)
> >
[PATCH] sched/core: remove unnecessary unlikely() in push_xx_task
WARN_ON() already contains an unlikely(), so it's not necessary to
use WARN_ON(1).
Signed-off-by: Yangtao Li
---
kernel/sched/deadline.c | 4 +---
kernel/sched/rt.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 91e4202b0634..8b5d964d59c5 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -2041,10 +2041,8 @@ static int push_dl_task(struct rq *rq)
return 0;
retry:
- if (unlikely(next_task == rq->curr)) {
- WARN_ON(1);
+ if (WARN_ON(next_task == rq->curr))
return 0;
- }
/*
* If next_task preempts rq->curr, and rq->curr
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 2e2955a8cf8f..0efd58563c80 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1810,10 +1810,8 @@ static int push_rt_task(struct rq *rq)
return 0;
retry:
- if (unlikely(next_task == rq->curr)) {
- WARN_ON(1);
+ if (WARN_ON(next_task == rq->curr))
return 0;
- }
/*
* It's possible that the next_task slipped in of
--
2.17.0
Re: [PATCH v2 5/6] staging:iio:ad2s90: Add IIO_CHAN_INFO_SCALE to channel spec and read_raw
On Sat, 3 Nov 2018 13:04:04 -0300
Matheus Tavares Bernardino wrote:
> On Sun, Oct 28, 2018 at 1:50 PM Jonathan Cameron wrote:
> >
> > On Fri, 26 Oct 2018 23:00:04 -0300
> > Matheus Tavares wrote:
> >
> > > This patch adds the IIO_CHAN_INFO_SCALE mask to ad2s90_chan and
> > > implements the relative read behavior at ad2s90_read_raw.
> > >
> > > Signed-off-by: Victor Colombo
> > > Signed-off-by: Matheus Tavares
> >
> > Hi,
> >
> > A suggestion inline. This is a common case that we have infrastructure
> > to simplify. + I think your scale factor is very slightly wrong.
> >
> > Jonathan
> >
> > > ---
> > > drivers/staging/iio/resolver/ad2s90.c | 32 ++-
> > > 1 file changed, 22 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/staging/iio/resolver/ad2s90.c
> > > b/drivers/staging/iio/resolver/ad2s90.c
> > > index b4a6a89c11b0..52b656875ed1 100644
> > > --- a/drivers/staging/iio/resolver/ad2s90.c
> > > +++ b/drivers/staging/iio/resolver/ad2s90.c
> > > @@ -34,19 +34,31 @@ static int ad2s90_read_raw(struct iio_dev *indio_dev,
> > > int ret;
> > > struct ad2s90_state *st = iio_priv(indio_dev);
> > >
> > > - mutex_lock(>lock);
> > > + switch (m) {
> > > + case IIO_CHAN_INFO_SCALE:
> > > + /* 2 * Pi / (2^12 - 1) ~= 0.001534355 */
> > > + *val = 0;
> > > + *val2 = 1534355;
> > Definitely 2^12 - 1? That's a bit unusual if true as it would imply
> > that 2^12 - 1 and 0 were the same value.
> >
> > Imagine a smaller version with on 2^2 bits so 0, 1, 2, 3
> > Values of each are
> >
> > 0, M_PI/2, M_PI, 3*M_PI/2
> >
> > So the multiplier is 2*M_PI/(2^2) not 2*M_PI/(2^2 - 1)
> > 1/2 vs 2/3 * M_PI
>
> Oh, that makes a lot of sense! We used 2^12 - 1 here based on driver
> drivers/iio/resolver/ad2s1200.c, whose resolution is also 12 bits, as
> the ad2s90.c. Do you think this section is, perhaps, wrong on
> ad2s1200.c too, or maybe there is some difference between these two
> drivers that I didn't catch regarding the resolution?
Certainly seems likely to be wrong. Difference is tiny so no one
probably ever noticed :(
Feel free to post a patch fixing that one as well!
Thanks,
Jonathan
>
> Matheus.
>
> > Now this is a very common case so we have the return type
> > IIO_VAL_FRACTIONAL_LOG2 to give a more obvious and potentially
> > more accurate representation.
> >
> > > + return IIO_VAL_INT_PLUS_NANO;
> > > + case IIO_CHAN_INFO_RAW:
> > > + mutex_lock(>lock);
> > > +
> > > + ret = spi_read(st->sdev, st->rx, 2);
> > > + if (ret < 0) {
> > > + mutex_unlock(>lock);
> > > + return ret;
> > > + }
> > > +
> > > + *val = (((u16)(st->rx[0])) << 4) | ((st->rx[1] & 0xF0) >>
> > > 4);
> > >
> > > - ret = spi_read(st->sdev, st->rx, 2);
> > > - if (ret < 0) {
> > > mutex_unlock(>lock);
> > > - return ret;
> > > - }
> > >
> > > - *val = (((u16)(st->rx[0])) << 4) | ((st->rx[1] & 0xF0) >> 4);
> > > -
> > > - mutex_unlock(>lock);
> > > + return IIO_VAL_INT;
> > > + default:
> > > + break;
> > > + }
> > >
> > > - return IIO_VAL_INT;
> > > + return -EINVAL;
> > > }
> > >
> > > static const struct iio_info ad2s90_info = {
> > > @@ -57,7 +69,7 @@ static const struct iio_chan_spec ad2s90_chan = {
> > > .type = IIO_ANGL,
> > > .indexed = 1,
> > > .channel = 0,
> > > - .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > > BIT(IIO_CHAN_INFO_SCALE),
> > > };
> > >
> > > static int ad2s90_probe(struct spi_device *spi)
> >
[PATCH] sched/core: remove unnecessary unlikely() in push_xx_task
WARN_ON() already contains an unlikely(), so it's not necessary to
use WARN_ON(1).
Signed-off-by: Yangtao Li
---
kernel/sched/deadline.c | 4 +---
kernel/sched/rt.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 91e4202b0634..8b5d964d59c5 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -2041,10 +2041,8 @@ static int push_dl_task(struct rq *rq)
return 0;
retry:
- if (unlikely(next_task == rq->curr)) {
- WARN_ON(1);
+ if (WARN_ON(next_task == rq->curr))
return 0;
- }
/*
* If next_task preempts rq->curr, and rq->curr
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 2e2955a8cf8f..0efd58563c80 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1810,10 +1810,8 @@ static int push_rt_task(struct rq *rq)
return 0;
retry:
- if (unlikely(next_task == rq->curr)) {
- WARN_ON(1);
+ if (WARN_ON(next_task == rq->curr))
return 0;
- }
/*
* It's possible that the next_task slipped in of
--
2.17.0
Re: [PATCH v3 1/3] staging: iio: ad7780: fix offset read value
On Sat, 3 Nov 2018 12:59:16 -0300 Renato Lui Geh wrote: > Hi, > > >On Thu, 1 Nov 2018 15:02:32 + > >"Ardelean, Alexandru" wrote: > > > >> Good catch. > > That was actually Jonathan's catch. :) > > >> Acked-by: Alexandru Ardelean > > I read up on Acked-by on the kernel docs, as I didn't know exactly what > it meant, but I'm not so sure on how to proceed once the patch has been > acked. For future patches, do I add this Acked-by line on the patch's > message body? Or is this just an informal way of approval? It's formal. You put the line directly below your Signed-off-by: line if you are resending. If I pick up the patch I paste it in there whilst applying. > > >On the basis this has been broken for a long time, and you are clearly > >doing other nearby not fix work, I'm going to take this through the togreg > >tree rather than via the quicker fix path. It makes my life > >easier :) > > > >Applied to the togreg branch of iio.git and pushed out as testing for > >the autobuilders to play with it. > > So this means I should skip this patch on v4, right? Yes. Already in the tree so don't send it again. Thanks Jonathan > > Thanks, > Renato >
Re: [PATCH v3 1/3] staging: iio: ad7780: fix offset read value
On Sat, 3 Nov 2018 12:59:16 -0300 Renato Lui Geh wrote: > Hi, > > >On Thu, 1 Nov 2018 15:02:32 + > >"Ardelean, Alexandru" wrote: > > > >> Good catch. > > That was actually Jonathan's catch. :) > > >> Acked-by: Alexandru Ardelean > > I read up on Acked-by on the kernel docs, as I didn't know exactly what > it meant, but I'm not so sure on how to proceed once the patch has been > acked. For future patches, do I add this Acked-by line on the patch's > message body? Or is this just an informal way of approval? It's formal. You put the line directly below your Signed-off-by: line if you are resending. If I pick up the patch I paste it in there whilst applying. > > >On the basis this has been broken for a long time, and you are clearly > >doing other nearby not fix work, I'm going to take this through the togreg > >tree rather than via the quicker fix path. It makes my life > >easier :) > > > >Applied to the togreg branch of iio.git and pushed out as testing for > >the autobuilders to play with it. > > So this means I should skip this patch on v4, right? Yes. Already in the tree so don't send it again. Thanks Jonathan > > Thanks, > Renato >
Re: [PATCH v3 2/3] staging: iio: ad7780: update voltage on read
On Sat, 3 Nov 2018 13:06:19 -0300 Renato Lui Geh wrote: > On Thu, 1 Nov 2018 15:20:55 + > "Ardelean, Alexandru" wrote: > > > > This looks wrong. > > I admit this was done in the same way in the probe function, but that looks > > a bit wrong as well. > > > > Typically, the return value of `regulator_get_voltage()` would get checked > > with: > > > > ret = regulator_get_voltage(st->reg); > > if (ret < 0) > >return ret; > > *val = ret / 1000; > > > > So, negative values are errors and zero & positive values are valid voltage > > values. > > I see. So -EINVAL is only used when sent the wrong info type? yes. I actually misread what was there and thought we were just talking about using a ret variable rather than returning the error via your local variable. Definitely want to pass on the error from regulator_get_voltage as it may have more meaning than a simple -EINVAL. Thanks, Jonathan
Re: [PATCH v3 2/3] staging: iio: ad7780: update voltage on read
On Sat, 3 Nov 2018 13:06:19 -0300 Renato Lui Geh wrote: > On Thu, 1 Nov 2018 15:20:55 + > "Ardelean, Alexandru" wrote: > > > > This looks wrong. > > I admit this was done in the same way in the probe function, but that looks > > a bit wrong as well. > > > > Typically, the return value of `regulator_get_voltage()` would get checked > > with: > > > > ret = regulator_get_voltage(st->reg); > > if (ret < 0) > >return ret; > > *val = ret / 1000; > > > > So, negative values are errors and zero & positive values are valid voltage > > values. > > I see. So -EINVAL is only used when sent the wrong info type? yes. I actually misread what was there and thought we were just talking about using a ret variable rather than returning the error via your local variable. Definitely want to pass on the error from regulator_get_voltage as it may have more meaning than a simple -EINVAL. Thanks, Jonathan
Re: [PATCH v5 3/3] iio: magnetometer: Add driver support for PNI RM3100
On Fri, 2 Nov 2018 15:42:09 +0800
Song Qiang wrote:
> PNI RM3100 is a high resolution, large signal immunity magnetometer,
> composed of 3 single sensors and a processing chip with a MagI2C
> interface.
>
> Following functions are available:
> - Single-shot measurement from
>/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
> - Triggerd buffer measurement.
> - DRDY pin for data ready trigger.
> - Both i2c and spi interface are supported.
> - Both interrupt and polling measurement is supported, depends on if
>the 'interrupts' in DT is declared.
>
> Signed-off-by: Song Qiang
Hi Song.
I think the optimized read of X and Z actually puts the data in the
wrong locations, should be XXXxZZZx but I think you have XXXxZZZx
I would just fix that up, but I can't test it - so back to you one more
time!
The currentmode thing looks like a core bug to me. All devices should come
up in DIRECTMODE. Even for devices that don't actually support direct reading
they can't come up in buffered mode because there will be configuration to do.
Right now they come up in no mode at all - hence your fix.
A default of DIRECTMODE makes sense to me - probably wants to be set in
the initial allocation code so if there is a reason to override it that can
still be done. Fine to have it set in your driver until that fix is in
place in the core.
A few totally trivial other things I would just have fixed if we didn't have
the axis question.
Jonathan
> ---
> MAINTAINERS| 7 +
> drivers/iio/magnetometer/Kconfig | 29 ++
> drivers/iio/magnetometer/Makefile | 4 +
> drivers/iio/magnetometer/rm3100-core.c | 613 +
> drivers/iio/magnetometer/rm3100-i2c.c | 54 +++
> drivers/iio/magnetometer/rm3100-spi.c | 64 +++
> drivers/iio/magnetometer/rm3100.h | 17 +
> 7 files changed, 788 insertions(+)
> create mode 100644 drivers/iio/magnetometer/rm3100-core.c
> create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
> create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
> create mode 100644 drivers/iio/magnetometer/rm3100.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1c0f771b859e..ca7a31736256 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11824,6 +11824,13 @@ M: "Rafael J. Wysocki"
> S: Maintained
> F: drivers/pnp/
>
> +PNI RM3100 IIO DRIVER
> +M: Song Qiang
> +L: linux-...@vger.kernel.org
> +S: Maintained
> +F: drivers/iio/magnetometer/rm3100*
> +F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
> +
> POSIX CLOCKS and TIMERS
> M: Thomas Gleixner
> L: linux-kernel@vger.kernel.org
> diff --git a/drivers/iio/magnetometer/Kconfig
> b/drivers/iio/magnetometer/Kconfig
> index ed9d776d01af..8a63cbbca4b7 100644
> --- a/drivers/iio/magnetometer/Kconfig
> +++ b/drivers/iio/magnetometer/Kconfig
> @@ -175,4 +175,33 @@ config SENSORS_HMC5843_SPI
> - hmc5843_core (core functions)
> - hmc5843_spi (support for HMC5983)
>
> +config SENSORS_RM3100
> + tristate
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> +
> +config SENSORS_RM3100_I2C
> + tristate "PNI RM3100 3-Axis Magnetometer (I2C)"
> + depends on I2C
> + select SENSORS_RM3100
> + select REGMAP_I2C
> + help
> + Say Y here to add support for the PNI RM3100 3-Axis Magnetometer.
> +
> + This driver can also be compiled as a module.
> + To compile this driver as a module, choose M here: the module
> + will be called rm3100-i2c.
> +
> +config SENSORS_RM3100_SPI
> + tristate "PNI RM3100 3-Axis Magnetometer (SPI)"
> + depends on SPI_MASTER
> + select SENSORS_RM3100
> + select REGMAP_SPI
> + help
> + Say Y here to add support for the PNI RM3100 3-Axis Magnetometer.
> +
> + This driver can also be compiled as a module.
> + To compile this driver as a module, choose M here: the module
> + will be called rm3100-spi.
> +
> endmenu
> diff --git a/drivers/iio/magnetometer/Makefile
> b/drivers/iio/magnetometer/Makefile
> index 664b2f866472..ba1bc34b82fa 100644
> --- a/drivers/iio/magnetometer/Makefile
> +++ b/drivers/iio/magnetometer/Makefile
> @@ -24,3 +24,7 @@ obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o
> obj-$(CONFIG_SENSORS_HMC5843)+= hmc5843_core.o
> obj-$(CONFIG_SENSORS_HMC5843_I2C)+= hmc5843_i2c.o
> obj-$(CONFIG_SENSORS_HMC5843_SPI)+= hmc5843_spi.o
> +
> +obj-$(CONFIG_SENSORS_RM3100) += rm3100-core.o
> +obj-$(CONFIG_SENSORS_RM3100_I2C) += rm3100-i2c.o
> +obj-$(CONFIG_SENSORS_RM3100_SPI) += rm3100-spi.o
> diff --git a/drivers/iio/magnetometer/rm3100-core.c
> b/drivers/iio/magnetometer/rm3100-core.c
> new file mode 100644
> index ..8523548b7fb7
> --- /dev/null
> +++ b/drivers/iio/magnetometer/rm3100-core.c
> @@ -0,0 +1,613 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PNI RM3100 3-axis geomagnetic sensor driver core.
> + *
> + * Copyright (C)
Re: [PATCH v5 3/3] iio: magnetometer: Add driver support for PNI RM3100
On Fri, 2 Nov 2018 15:42:09 +0800
Song Qiang wrote:
> PNI RM3100 is a high resolution, large signal immunity magnetometer,
> composed of 3 single sensors and a processing chip with a MagI2C
> interface.
>
> Following functions are available:
> - Single-shot measurement from
>/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
> - Triggerd buffer measurement.
> - DRDY pin for data ready trigger.
> - Both i2c and spi interface are supported.
> - Both interrupt and polling measurement is supported, depends on if
>the 'interrupts' in DT is declared.
>
> Signed-off-by: Song Qiang
Hi Song.
I think the optimized read of X and Z actually puts the data in the
wrong locations, should be XXXxZZZx but I think you have XXXxZZZx
I would just fix that up, but I can't test it - so back to you one more
time!
The currentmode thing looks like a core bug to me. All devices should come
up in DIRECTMODE. Even for devices that don't actually support direct reading
they can't come up in buffered mode because there will be configuration to do.
Right now they come up in no mode at all - hence your fix.
A default of DIRECTMODE makes sense to me - probably wants to be set in
the initial allocation code so if there is a reason to override it that can
still be done. Fine to have it set in your driver until that fix is in
place in the core.
A few totally trivial other things I would just have fixed if we didn't have
the axis question.
Jonathan
> ---
> MAINTAINERS| 7 +
> drivers/iio/magnetometer/Kconfig | 29 ++
> drivers/iio/magnetometer/Makefile | 4 +
> drivers/iio/magnetometer/rm3100-core.c | 613 +
> drivers/iio/magnetometer/rm3100-i2c.c | 54 +++
> drivers/iio/magnetometer/rm3100-spi.c | 64 +++
> drivers/iio/magnetometer/rm3100.h | 17 +
> 7 files changed, 788 insertions(+)
> create mode 100644 drivers/iio/magnetometer/rm3100-core.c
> create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
> create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
> create mode 100644 drivers/iio/magnetometer/rm3100.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1c0f771b859e..ca7a31736256 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11824,6 +11824,13 @@ M: "Rafael J. Wysocki"
> S: Maintained
> F: drivers/pnp/
>
> +PNI RM3100 IIO DRIVER
> +M: Song Qiang
> +L: linux-...@vger.kernel.org
> +S: Maintained
> +F: drivers/iio/magnetometer/rm3100*
> +F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
> +
> POSIX CLOCKS and TIMERS
> M: Thomas Gleixner
> L: linux-kernel@vger.kernel.org
> diff --git a/drivers/iio/magnetometer/Kconfig
> b/drivers/iio/magnetometer/Kconfig
> index ed9d776d01af..8a63cbbca4b7 100644
> --- a/drivers/iio/magnetometer/Kconfig
> +++ b/drivers/iio/magnetometer/Kconfig
> @@ -175,4 +175,33 @@ config SENSORS_HMC5843_SPI
> - hmc5843_core (core functions)
> - hmc5843_spi (support for HMC5983)
>
> +config SENSORS_RM3100
> + tristate
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> +
> +config SENSORS_RM3100_I2C
> + tristate "PNI RM3100 3-Axis Magnetometer (I2C)"
> + depends on I2C
> + select SENSORS_RM3100
> + select REGMAP_I2C
> + help
> + Say Y here to add support for the PNI RM3100 3-Axis Magnetometer.
> +
> + This driver can also be compiled as a module.
> + To compile this driver as a module, choose M here: the module
> + will be called rm3100-i2c.
> +
> +config SENSORS_RM3100_SPI
> + tristate "PNI RM3100 3-Axis Magnetometer (SPI)"
> + depends on SPI_MASTER
> + select SENSORS_RM3100
> + select REGMAP_SPI
> + help
> + Say Y here to add support for the PNI RM3100 3-Axis Magnetometer.
> +
> + This driver can also be compiled as a module.
> + To compile this driver as a module, choose M here: the module
> + will be called rm3100-spi.
> +
> endmenu
> diff --git a/drivers/iio/magnetometer/Makefile
> b/drivers/iio/magnetometer/Makefile
> index 664b2f866472..ba1bc34b82fa 100644
> --- a/drivers/iio/magnetometer/Makefile
> +++ b/drivers/iio/magnetometer/Makefile
> @@ -24,3 +24,7 @@ obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o
> obj-$(CONFIG_SENSORS_HMC5843)+= hmc5843_core.o
> obj-$(CONFIG_SENSORS_HMC5843_I2C)+= hmc5843_i2c.o
> obj-$(CONFIG_SENSORS_HMC5843_SPI)+= hmc5843_spi.o
> +
> +obj-$(CONFIG_SENSORS_RM3100) += rm3100-core.o
> +obj-$(CONFIG_SENSORS_RM3100_I2C) += rm3100-i2c.o
> +obj-$(CONFIG_SENSORS_RM3100_SPI) += rm3100-spi.o
> diff --git a/drivers/iio/magnetometer/rm3100-core.c
> b/drivers/iio/magnetometer/rm3100-core.c
> new file mode 100644
> index ..8523548b7fb7
> --- /dev/null
> +++ b/drivers/iio/magnetometer/rm3100-core.c
> @@ -0,0 +1,613 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PNI RM3100 3-axis geomagnetic sensor driver core.
> + *
> + * Copyright (C)
Re: [PATCH v3] genirq/matrix: Choose CPU for managed IRQs based on how many of them are allocated
On Sat, 3 Nov 2018, Thomas Gleixner wrote: > On Fri, 2 Nov 2018, Long Li wrote: > > /** > > * irq_matrix_assign_system - Assign system wide entry in the matrix > > * @m: Matrix pointer > > @@ -269,7 +291,7 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, > > const struct cpumask *msk, > > if (cpumask_empty(msk)) > > return -EINVAL; > > > > - cpu = matrix_find_best_cpu(m, msk); > > + cpu = matrix_find_best_cpu_managed(m, msk); > > if (cpu == UINT_MAX) > > return -ENOSPC; > > > > @@ -282,6 +304,7 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, > > const struct cpumask *msk, > > return -ENOSPC; > > set_bit(bit, cm->alloc_map); > > cm->allocated++; > > + cm->managed_allocated++; > > m->total_allocated++; > > *mapped_cpu = cpu; > > trace_irq_matrix_alloc_managed(bit, cpu, m, cm); > > so far so good. But what exactly decrements managed_allocated ? Another thing. If we add that counter, then it would be good to expose it in the debugfs files as well. Thanks, tglx
Re: [PATCH v3] genirq/matrix: Choose CPU for managed IRQs based on how many of them are allocated
On Sat, 3 Nov 2018, Thomas Gleixner wrote: > On Fri, 2 Nov 2018, Long Li wrote: > > /** > > * irq_matrix_assign_system - Assign system wide entry in the matrix > > * @m: Matrix pointer > > @@ -269,7 +291,7 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, > > const struct cpumask *msk, > > if (cpumask_empty(msk)) > > return -EINVAL; > > > > - cpu = matrix_find_best_cpu(m, msk); > > + cpu = matrix_find_best_cpu_managed(m, msk); > > if (cpu == UINT_MAX) > > return -ENOSPC; > > > > @@ -282,6 +304,7 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, > > const struct cpumask *msk, > > return -ENOSPC; > > set_bit(bit, cm->alloc_map); > > cm->allocated++; > > + cm->managed_allocated++; > > m->total_allocated++; > > *mapped_cpu = cpu; > > trace_irq_matrix_alloc_managed(bit, cpu, m, cm); > > so far so good. But what exactly decrements managed_allocated ? Another thing. If we add that counter, then it would be good to expose it in the debugfs files as well. Thanks, tglx
Re: [GIT PULL] vfs: fix many problems in vfs clone/dedupe implementation
On Fri, Nov 2, 2018 at 4:36 PM Dave Chinner wrote: > > On Fri, Nov 02, 2018 at 09:35:23AM -0700, Linus Torvalds wrote: > > > > I don't love the timing of this at the end of the merge window, but pulled, > > When would have been a better time? It's too big for a late -rc, and > it contains stuff that needs fixing pretty urgently. So if the merge > window is not appropriate, what should we have done here? No, I think that with the timing of the problem finding, it was probably the only thing to do, but generally I like these kinds of somewhat scary and disruptive patches (just because it touches multiple filesystems) _early_ in the merge window if at all possible, and showing that the development was done before and not some rushed thing.. Linus
Re: [GIT PULL] vfs: fix many problems in vfs clone/dedupe implementation
On Fri, Nov 2, 2018 at 4:36 PM Dave Chinner wrote: > > On Fri, Nov 02, 2018 at 09:35:23AM -0700, Linus Torvalds wrote: > > > > I don't love the timing of this at the end of the merge window, but pulled, > > When would have been a better time? It's too big for a late -rc, and > it contains stuff that needs fixing pretty urgently. So if the merge > window is not appropriate, what should we have done here? No, I think that with the timing of the problem finding, it was probably the only thing to do, but generally I like these kinds of somewhat scary and disruptive patches (just because it touches multiple filesystems) _early_ in the merge window if at all possible, and showing that the development was done before and not some rushed thing.. Linus
[PATCH 8/8] tpm: remove @space from tpm_transmit()
Remove @space from tpm_transmit() API` in order to completely remove the
bound between low-level transmission functionality and TPM spaces. The
only real dependency existing is the amount of data saved before trying
to send a command to the TPM.
It doesn't really matter if we save always a bit more than needed so
this commit changes the amount saved always to be the size of the TPM
header and three handles.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-dev-common.c | 2 +-
drivers/char/tpm/tpm-interface.c | 25 ++---
drivers/char/tpm/tpm-sysfs.c | 5 ++---
drivers/char/tpm/tpm.h| 10 +-
drivers/char/tpm/tpm1-cmd.c | 16 +++-
drivers/char/tpm/tpm2-cmd.c | 30 ++
drivers/char/tpm/tpm2-space.c | 6 ++
drivers/char/tpm/tpm_vtpm_proxy.c | 2 +-
8 files changed, 42 insertions(+), 54 deletions(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 22c7ac819662..5ec5c0c352af 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -49,7 +49,7 @@ static ssize_t tpm_dev_transmit(struct tpm_chip *chip, struct
tpm_space *space,
if (ret)
goto out;
- len = tpm_transmit(chip, space, buf, bufsiz, TPM_TRANSMIT_UNLOCKED);
+ len = tpm_transmit(chip, buf, bufsiz, TPM_TRANSMIT_UNLOCKED);
if (len < 0) {
ret = len;
goto out;
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 6441486f9e1f..bb8e4da41fde 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -120,9 +120,7 @@ static int tpm_go_idle(struct tpm_chip *chip, unsigned int
flags)
return chip->ops->go_idle(chip);
}
-static ssize_t tpm_try_transmit(struct tpm_chip *chip,
- struct tpm_space *space,
- u8 *buf, size_t bufsiz,
+static ssize_t tpm_try_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
unsigned int flags)
{
struct tpm_output_header *header = (void *)buf;
@@ -193,7 +191,6 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
/**
* tpm_transmit - Internal kernel interface to transmit TPM commands.
* @chip: a TPM chip to use
- * @space: a TPM space
* @buf: a TPM command buffer
* @bufsiz:length of the TPM command buffer
* @flags: TPM transmit flags
@@ -209,8 +206,8 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
* * The response length - OK
* * -errno- A system error
*/
-ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space,
-u8 *buf, size_t bufsiz, unsigned int flags)
+ssize_t tpm_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
+unsigned int flags)
{
struct tpm_output_header *header = (struct tpm_output_header *)buf;
/* space for header and handles */
@@ -219,8 +216,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
bool has_locality = false;
u32 rc = 0;
ssize_t ret;
- const size_t save_size = min(space ? sizeof(save) : TPM_HEADER_SIZE,
-bufsiz);
+ const size_t save_size = min(sizeof(save), bufsiz);
/* the command code is where the return code will be */
u32 cc = be32_to_cpu(header->return_code);
@@ -250,7 +246,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
if (ret)
goto out_locality;
- ret = tpm_try_transmit(chip, space, buf, bufsiz, flags);
+ ret = tpm_try_transmit(chip, buf, bufsiz, flags);
/* This may fail but do not override ret. */
tpm_go_idle(chip, flags);
@@ -296,7 +292,6 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
/**
* tpm_transmit_cmd - send a tpm command to the device
* @chip: a TPM chip to use
- * @space: a TPM space
* @buf: a TPM command buffer
* @min_rsp_body_length: minimum expected length of response body
* @flags: TPM transmit flags
@@ -307,16 +302,16 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
* * -errno- A system error
* * TPM_RC- A TPM error
*/
-ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_space *space,
-struct tpm_buf *buf, size_t min_rsp_body_length,
-unsigned int flags, const char *desc)
+ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
+size_t min_rsp_body_length, unsigned int flags,
+const char *desc)
{
const struct tpm_output_header *header =
(struct tpm_output_header
[PATCH 7/8] tpm: move TPM space code out of tpm_transmit()
Prepare and commit TPM space before and after calling tpm_transmit()
instead of doing that inside tpm_transmit(). After this change we can
remove TPM_TRANSMIT_NESTED flag from tpm2_prepare_space() and
tpm2_commit_space() and replace it with TPM_TRANSMIT_UNLOCKED.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-dev-common.c | 31 ---
drivers/char/tpm/tpm-interface.c | 19 ---
drivers/char/tpm/tpm2-space.c | 12 ++--
3 files changed, 34 insertions(+), 28 deletions(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index cbb0ee30b511..22c7ac819662 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -30,13 +30,38 @@ static DEFINE_MUTEX(tpm_dev_wq_lock);
static ssize_t tpm_dev_transmit(struct tpm_chip *chip, struct tpm_space *space,
u8 *buf, size_t bufsiz)
{
- ssize_t ret;
+ struct tpm_output_header *header = (void *)buf;
+ ssize_t ret, len;
mutex_lock(>tpm_mutex);
- ret = tpm_transmit(chip, space, buf, bufsiz, TPM_TRANSMIT_UNLOCKED);
+ ret = tpm2_prepare_space(chip, space, buf, bufsiz);
+ /* If the command is not implemented by the TPM, synthesize a
+* response with a TPM2_RC_COMMAND_CODE return for user-space.
+*/
+ if (ret == -EOPNOTSUPP) {
+ header->length = cpu_to_be32(sizeof(*header));
+ header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
+ header->return_code = cpu_to_be32(TPM2_RC_COMMAND_CODE |
+ TSS2_RESMGR_TPM_RC_LAYER);
+ ret = sizeof(*header);
+ goto out;
+ }
+ if (ret)
+ goto out;
+
+ len = tpm_transmit(chip, space, buf, bufsiz, TPM_TRANSMIT_UNLOCKED);
+ if (len < 0) {
+ ret = len;
+ goto out;
+ }
+
+ ret = tpm2_commit_space(chip, space, buf, );
+out:
mutex_unlock(>tpm_mutex);
+ if (ret)
+ return ret;
- return ret;
+ return len;
}
static void tpm_dev_async_work(struct work_struct *work)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 670882f6177b..6441486f9e1f 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -147,21 +147,6 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
return -E2BIG;
}
- rc = tpm2_prepare_space(chip, space, buf, bufsiz);
- /*
-* If the command is not implemented by the TPM, synthesize a
-* response with a TPM2_RC_COMMAND_CODE return for user-space.
-*/
- if (rc == -EOPNOTSUPP) {
- header->length = cpu_to_be32(sizeof(*header));
- header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
- header->return_code = cpu_to_be32(TPM2_RC_COMMAND_CODE |
- TSS2_RESMGR_TPM_RC_LAYER);
- return sizeof(*header);
- }
- if (rc)
- return rc;
-
rc = chip->ops->send(chip, buf, count);
if (rc < 0) {
if (rc != -EPIPE)
@@ -202,10 +187,6 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
if (len < TPM_HEADER_SIZE || len != be32_to_cpu(header->length))
return -EFAULT;
- rc = tpm2_commit_space(chip, space, buf, );
- if (rc)
- return rc;
-
return len;
}
diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
index a8c13c8e88ed..ad8efd9afc4b 100644
--- a/drivers/char/tpm/tpm2-space.c
+++ b/drivers/char/tpm/tpm2-space.c
@@ -39,7 +39,7 @@ static void tpm2_flush_sessions(struct tpm_chip *chip, struct
tpm_space *space)
for (i = 0; i < ARRAY_SIZE(space->session_tbl); i++) {
if (space->session_tbl[i])
tpm2_flush_context_cmd(chip, space->session_tbl[i],
- TPM_TRANSMIT_NESTED);
+ TPM_TRANSMIT_UNLOCKED);
}
}
@@ -84,7 +84,7 @@ static int tpm2_load_context(struct tpm_chip *chip, u8 *buf,
tpm_buf_append(, [*offset], body_size);
rc = tpm_transmit_cmd(chip, NULL, , 4,
- TPM_TRANSMIT_NESTED, NULL);
+ TPM_TRANSMIT_UNLOCKED, NULL);
if (rc < 0) {
dev_warn(>dev, "%s: failed with a system error %d\n",
__func__, rc);
@@ -133,7 +133,7 @@ static int tpm2_save_context(struct tpm_chip *chip, u32
handle, u8 *buf,
tpm_buf_append_u32(, handle);
rc = tpm_transmit_cmd(chip, NULL, , 0,
- TPM_TRANSMIT_NESTED, NULL);
+ TPM_TRANSMIT_UNLOCKED, NULL);
if (rc < 0) {
dev_warn(>dev, "%s: failed with a system error
[PATCH 6/8] tpm: encapsulate tpm_dev_transmit()
Encapsulate tpm_transmit() call pattern to tpm_dev_transmit() because it
is identically used from two places. Use unlocked version of
tpm_transmit() so that we are able to move the calls to
tpm2_prepare_space() and tpm2_commit_space() later on to this new
function.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-dev-common.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 99b5133a9d05..cbb0ee30b511 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -27,7 +27,19 @@
static struct workqueue_struct *tpm_dev_wq;
static DEFINE_MUTEX(tpm_dev_wq_lock);
-static void tpm_async_work(struct work_struct *work)
+static ssize_t tpm_dev_transmit(struct tpm_chip *chip, struct tpm_space *space,
+ u8 *buf, size_t bufsiz)
+{
+ ssize_t ret;
+
+ mutex_lock(>tpm_mutex);
+ ret = tpm_transmit(chip, space, buf, bufsiz, TPM_TRANSMIT_UNLOCKED);
+ mutex_unlock(>tpm_mutex);
+
+ return ret;
+}
+
+static void tpm_dev_async_work(struct work_struct *work)
{
struct file_priv *priv =
container_of(work, struct file_priv, async_work);
@@ -35,9 +47,8 @@ static void tpm_async_work(struct work_struct *work)
mutex_lock(>buffer_mutex);
priv->command_enqueued = false;
- ret = tpm_transmit(priv->chip, priv->space, priv->data_buffer,
- sizeof(priv->data_buffer), 0);
-
+ ret = tpm_dev_transmit(priv->chip, priv->space, priv->data_buffer,
+ sizeof(priv->data_buffer));
tpm_put_ops(priv->chip);
if (ret > 0) {
priv->data_pending = ret;
@@ -78,7 +89,7 @@ void tpm_common_open(struct file *file, struct tpm_chip *chip,
mutex_init(>buffer_mutex);
timer_setup(>user_read_timer, user_reader_timeout, 0);
INIT_WORK(>timeout_work, tpm_timeout_work);
- INIT_WORK(>async_work, tpm_async_work);
+ INIT_WORK(>async_work, tpm_dev_async_work);
init_waitqueue_head(>async_wait);
file->private_data = priv;
}
@@ -163,8 +174,8 @@ ssize_t tpm_common_write(struct file *file, const char
__user *buf,
return size;
}
- ret = tpm_transmit(priv->chip, priv->space, priv->data_buffer,
- sizeof(priv->data_buffer), 0);
+ ret = tpm_dev_transmit(priv->chip, priv->space, priv->data_buffer,
+ sizeof(priv->data_buffer));
tpm_put_ops(priv->chip);
if (ret > 0) {
--
2.19.1
[PATCH 8/8] tpm: remove @space from tpm_transmit()
Remove @space from tpm_transmit() API` in order to completely remove the
bound between low-level transmission functionality and TPM spaces. The
only real dependency existing is the amount of data saved before trying
to send a command to the TPM.
It doesn't really matter if we save always a bit more than needed so
this commit changes the amount saved always to be the size of the TPM
header and three handles.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-dev-common.c | 2 +-
drivers/char/tpm/tpm-interface.c | 25 ++---
drivers/char/tpm/tpm-sysfs.c | 5 ++---
drivers/char/tpm/tpm.h| 10 +-
drivers/char/tpm/tpm1-cmd.c | 16 +++-
drivers/char/tpm/tpm2-cmd.c | 30 ++
drivers/char/tpm/tpm2-space.c | 6 ++
drivers/char/tpm/tpm_vtpm_proxy.c | 2 +-
8 files changed, 42 insertions(+), 54 deletions(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 22c7ac819662..5ec5c0c352af 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -49,7 +49,7 @@ static ssize_t tpm_dev_transmit(struct tpm_chip *chip, struct
tpm_space *space,
if (ret)
goto out;
- len = tpm_transmit(chip, space, buf, bufsiz, TPM_TRANSMIT_UNLOCKED);
+ len = tpm_transmit(chip, buf, bufsiz, TPM_TRANSMIT_UNLOCKED);
if (len < 0) {
ret = len;
goto out;
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 6441486f9e1f..bb8e4da41fde 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -120,9 +120,7 @@ static int tpm_go_idle(struct tpm_chip *chip, unsigned int
flags)
return chip->ops->go_idle(chip);
}
-static ssize_t tpm_try_transmit(struct tpm_chip *chip,
- struct tpm_space *space,
- u8 *buf, size_t bufsiz,
+static ssize_t tpm_try_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
unsigned int flags)
{
struct tpm_output_header *header = (void *)buf;
@@ -193,7 +191,6 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
/**
* tpm_transmit - Internal kernel interface to transmit TPM commands.
* @chip: a TPM chip to use
- * @space: a TPM space
* @buf: a TPM command buffer
* @bufsiz:length of the TPM command buffer
* @flags: TPM transmit flags
@@ -209,8 +206,8 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
* * The response length - OK
* * -errno- A system error
*/
-ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space,
-u8 *buf, size_t bufsiz, unsigned int flags)
+ssize_t tpm_transmit(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
+unsigned int flags)
{
struct tpm_output_header *header = (struct tpm_output_header *)buf;
/* space for header and handles */
@@ -219,8 +216,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
bool has_locality = false;
u32 rc = 0;
ssize_t ret;
- const size_t save_size = min(space ? sizeof(save) : TPM_HEADER_SIZE,
-bufsiz);
+ const size_t save_size = min(sizeof(save), bufsiz);
/* the command code is where the return code will be */
u32 cc = be32_to_cpu(header->return_code);
@@ -250,7 +246,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
if (ret)
goto out_locality;
- ret = tpm_try_transmit(chip, space, buf, bufsiz, flags);
+ ret = tpm_try_transmit(chip, buf, bufsiz, flags);
/* This may fail but do not override ret. */
tpm_go_idle(chip, flags);
@@ -296,7 +292,6 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
/**
* tpm_transmit_cmd - send a tpm command to the device
* @chip: a TPM chip to use
- * @space: a TPM space
* @buf: a TPM command buffer
* @min_rsp_body_length: minimum expected length of response body
* @flags: TPM transmit flags
@@ -307,16 +302,16 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
tpm_space *space,
* * -errno- A system error
* * TPM_RC- A TPM error
*/
-ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_space *space,
-struct tpm_buf *buf, size_t min_rsp_body_length,
-unsigned int flags, const char *desc)
+ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_buf *buf,
+size_t min_rsp_body_length, unsigned int flags,
+const char *desc)
{
const struct tpm_output_header *header =
(struct tpm_output_header
[PATCH 7/8] tpm: move TPM space code out of tpm_transmit()
Prepare and commit TPM space before and after calling tpm_transmit()
instead of doing that inside tpm_transmit(). After this change we can
remove TPM_TRANSMIT_NESTED flag from tpm2_prepare_space() and
tpm2_commit_space() and replace it with TPM_TRANSMIT_UNLOCKED.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-dev-common.c | 31 ---
drivers/char/tpm/tpm-interface.c | 19 ---
drivers/char/tpm/tpm2-space.c | 12 ++--
3 files changed, 34 insertions(+), 28 deletions(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index cbb0ee30b511..22c7ac819662 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -30,13 +30,38 @@ static DEFINE_MUTEX(tpm_dev_wq_lock);
static ssize_t tpm_dev_transmit(struct tpm_chip *chip, struct tpm_space *space,
u8 *buf, size_t bufsiz)
{
- ssize_t ret;
+ struct tpm_output_header *header = (void *)buf;
+ ssize_t ret, len;
mutex_lock(>tpm_mutex);
- ret = tpm_transmit(chip, space, buf, bufsiz, TPM_TRANSMIT_UNLOCKED);
+ ret = tpm2_prepare_space(chip, space, buf, bufsiz);
+ /* If the command is not implemented by the TPM, synthesize a
+* response with a TPM2_RC_COMMAND_CODE return for user-space.
+*/
+ if (ret == -EOPNOTSUPP) {
+ header->length = cpu_to_be32(sizeof(*header));
+ header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
+ header->return_code = cpu_to_be32(TPM2_RC_COMMAND_CODE |
+ TSS2_RESMGR_TPM_RC_LAYER);
+ ret = sizeof(*header);
+ goto out;
+ }
+ if (ret)
+ goto out;
+
+ len = tpm_transmit(chip, space, buf, bufsiz, TPM_TRANSMIT_UNLOCKED);
+ if (len < 0) {
+ ret = len;
+ goto out;
+ }
+
+ ret = tpm2_commit_space(chip, space, buf, );
+out:
mutex_unlock(>tpm_mutex);
+ if (ret)
+ return ret;
- return ret;
+ return len;
}
static void tpm_dev_async_work(struct work_struct *work)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 670882f6177b..6441486f9e1f 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -147,21 +147,6 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
return -E2BIG;
}
- rc = tpm2_prepare_space(chip, space, buf, bufsiz);
- /*
-* If the command is not implemented by the TPM, synthesize a
-* response with a TPM2_RC_COMMAND_CODE return for user-space.
-*/
- if (rc == -EOPNOTSUPP) {
- header->length = cpu_to_be32(sizeof(*header));
- header->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
- header->return_code = cpu_to_be32(TPM2_RC_COMMAND_CODE |
- TSS2_RESMGR_TPM_RC_LAYER);
- return sizeof(*header);
- }
- if (rc)
- return rc;
-
rc = chip->ops->send(chip, buf, count);
if (rc < 0) {
if (rc != -EPIPE)
@@ -202,10 +187,6 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
if (len < TPM_HEADER_SIZE || len != be32_to_cpu(header->length))
return -EFAULT;
- rc = tpm2_commit_space(chip, space, buf, );
- if (rc)
- return rc;
-
return len;
}
diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
index a8c13c8e88ed..ad8efd9afc4b 100644
--- a/drivers/char/tpm/tpm2-space.c
+++ b/drivers/char/tpm/tpm2-space.c
@@ -39,7 +39,7 @@ static void tpm2_flush_sessions(struct tpm_chip *chip, struct
tpm_space *space)
for (i = 0; i < ARRAY_SIZE(space->session_tbl); i++) {
if (space->session_tbl[i])
tpm2_flush_context_cmd(chip, space->session_tbl[i],
- TPM_TRANSMIT_NESTED);
+ TPM_TRANSMIT_UNLOCKED);
}
}
@@ -84,7 +84,7 @@ static int tpm2_load_context(struct tpm_chip *chip, u8 *buf,
tpm_buf_append(, [*offset], body_size);
rc = tpm_transmit_cmd(chip, NULL, , 4,
- TPM_TRANSMIT_NESTED, NULL);
+ TPM_TRANSMIT_UNLOCKED, NULL);
if (rc < 0) {
dev_warn(>dev, "%s: failed with a system error %d\n",
__func__, rc);
@@ -133,7 +133,7 @@ static int tpm2_save_context(struct tpm_chip *chip, u32
handle, u8 *buf,
tpm_buf_append_u32(, handle);
rc = tpm_transmit_cmd(chip, NULL, , 0,
- TPM_TRANSMIT_NESTED, NULL);
+ TPM_TRANSMIT_UNLOCKED, NULL);
if (rc < 0) {
dev_warn(>dev, "%s: failed with a system error
[PATCH 6/8] tpm: encapsulate tpm_dev_transmit()
Encapsulate tpm_transmit() call pattern to tpm_dev_transmit() because it
is identically used from two places. Use unlocked version of
tpm_transmit() so that we are able to move the calls to
tpm2_prepare_space() and tpm2_commit_space() later on to this new
function.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-dev-common.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 99b5133a9d05..cbb0ee30b511 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -27,7 +27,19 @@
static struct workqueue_struct *tpm_dev_wq;
static DEFINE_MUTEX(tpm_dev_wq_lock);
-static void tpm_async_work(struct work_struct *work)
+static ssize_t tpm_dev_transmit(struct tpm_chip *chip, struct tpm_space *space,
+ u8 *buf, size_t bufsiz)
+{
+ ssize_t ret;
+
+ mutex_lock(>tpm_mutex);
+ ret = tpm_transmit(chip, space, buf, bufsiz, TPM_TRANSMIT_UNLOCKED);
+ mutex_unlock(>tpm_mutex);
+
+ return ret;
+}
+
+static void tpm_dev_async_work(struct work_struct *work)
{
struct file_priv *priv =
container_of(work, struct file_priv, async_work);
@@ -35,9 +47,8 @@ static void tpm_async_work(struct work_struct *work)
mutex_lock(>buffer_mutex);
priv->command_enqueued = false;
- ret = tpm_transmit(priv->chip, priv->space, priv->data_buffer,
- sizeof(priv->data_buffer), 0);
-
+ ret = tpm_dev_transmit(priv->chip, priv->space, priv->data_buffer,
+ sizeof(priv->data_buffer));
tpm_put_ops(priv->chip);
if (ret > 0) {
priv->data_pending = ret;
@@ -78,7 +89,7 @@ void tpm_common_open(struct file *file, struct tpm_chip *chip,
mutex_init(>buffer_mutex);
timer_setup(>user_read_timer, user_reader_timeout, 0);
INIT_WORK(>timeout_work, tpm_timeout_work);
- INIT_WORK(>async_work, tpm_async_work);
+ INIT_WORK(>async_work, tpm_dev_async_work);
init_waitqueue_head(>async_wait);
file->private_data = priv;
}
@@ -163,8 +174,8 @@ ssize_t tpm_common_write(struct file *file, const char
__user *buf,
return size;
}
- ret = tpm_transmit(priv->chip, priv->space, priv->data_buffer,
- sizeof(priv->data_buffer), 0);
+ ret = tpm_dev_transmit(priv->chip, priv->space, priv->data_buffer,
+ sizeof(priv->data_buffer));
tpm_put_ops(priv->chip);
if (ret > 0) {
--
2.19.1
