Re: [RFC PATCH v2] mtd: nand: toshiba: Add support for ->exec_op()

2018-08-03 Thread Boris Brezillon
On Sat, 4 Aug 2018 14:26:18 +0900 KOBAYASHI Yoshitake wrote: > This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND > memory devices. This use vendor specific command > (TOSHIBA_NAND_CMD_ECC_STATUS) to know the exact bitflips. However, I

Re: [RFC PATCH v2] mtd: nand: toshiba: Add support for ->exec_op()

2018-08-03 Thread Boris Brezillon
On Sat, 4 Aug 2018 14:26:18 +0900 KOBAYASHI Yoshitake wrote: > This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND > memory devices. This use vendor specific command > (TOSHIBA_NAND_CMD_ECC_STATUS) to know the exact bitflips. However, I

Re: [PATCH v6] mtd: nand: toshiba: Add support for Toshiba Memory BENAND (Built-in ECC NAND)

2018-08-03 Thread Boris Brezillon
On Sat, 4 Aug 2018 14:25:52 +0900 KOBAYASHI Yoshitake wrote: > This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND > memory devices. Check the status of the built-in ECC with the Read > Status command without using the vendor specific command. The Read > Status command only

Re: [PATCH v6] mtd: nand: toshiba: Add support for Toshiba Memory BENAND (Built-in ECC NAND)

2018-08-03 Thread Boris Brezillon
On Sat, 4 Aug 2018 14:25:52 +0900 KOBAYASHI Yoshitake wrote: > This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND > memory devices. Check the status of the built-in ECC with the Read > Status command without using the vendor specific command. The Read > Status command only

[RFC PATCH v2] mtd: nand: toshiba: Add support for ->exec_op()

2018-08-03 Thread KOBAYASHI Yoshitake
This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND memory devices. This use vendor specific command (TOSHIBA_NAND_CMD_ECC_STATUS) to know the exact bitflips. However, I could not test this patch because I do not have a platform that supports chip-> exec_op. Therefore, I post

[RFC PATCH v2] mtd: nand: toshiba: Add support for ->exec_op()

2018-08-03 Thread KOBAYASHI Yoshitake
This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND memory devices. This use vendor specific command (TOSHIBA_NAND_CMD_ECC_STATUS) to know the exact bitflips. However, I could not test this patch because I do not have a platform that supports chip-> exec_op. Therefore, I post

[PATCH v6] mtd: nand: toshiba: Add support for Toshiba Memory BENAND (Built-in ECC NAND)

2018-08-03 Thread KOBAYASHI Yoshitake
This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND memory devices. Check the status of the built-in ECC with the Read Status command without using the vendor specific command. The Read Status command only knows whether there was bitflips above the threshold and can not get

[PATCH v6] mtd: nand: toshiba: Add support for Toshiba Memory BENAND (Built-in ECC NAND)

2018-08-03 Thread KOBAYASHI Yoshitake
This patch is a patch to support TOSHIBA MEMORY CORPORATION BENAND memory devices. Check the status of the built-in ECC with the Read Status command without using the vendor specific command. The Read Status command only knows whether there was bitflips above the threshold and can not get

Re: [PATCH v3 1/4] edac: synps: Add platform specific structures for ddrc controller

2018-08-03 Thread Borislav Petkov
On Thu, Aug 02, 2018 at 06:21:19PM +0530, Manish Narani wrote: > This patch adds platform specific structures, so that we can add "This patch" in a commit message is tautologically redundant. > different IP support later using quirks. > > Signed-off-by: Manish Narani > --- >

Re: [PATCH v3 1/4] edac: synps: Add platform specific structures for ddrc controller

2018-08-03 Thread Borislav Petkov
On Thu, Aug 02, 2018 at 06:21:19PM +0530, Manish Narani wrote: > This patch adds platform specific structures, so that we can add "This patch" in a commit message is tautologically redundant. > different IP support later using quirks. > > Signed-off-by: Manish Narani > --- >

[GIT PULL] xfs: 4.18 fixes, part 3

2018-08-03 Thread Darrick J. Wong
Hi Linus, Here's one more patch for 4.18 to fix a coding error in the iomap_bmap function introduced in -rc1. This series has been run through a full xfstests run during the week and through a quick xfstests run against this morning's master, with no major failures reported. --D The following

[GIT PULL] xfs: 4.18 fixes, part 3

2018-08-03 Thread Darrick J. Wong
Hi Linus, Here's one more patch for 4.18 to fix a coding error in the iomap_bmap function introduced in -rc1. This series has been run through a full xfstests run during the week and through a quick xfstests run against this morning's master, with no major failures reported. --D The following

Re: [PATCH 1/3] um: fix parallel building with O= option

2018-08-03 Thread Masahiro Yamada
2018-08-04 13:47 GMT+09:00 Masahiro Yamada : > Randy Dunlap reports UML occasionally fails to build with -j and > O= options. > > make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64' > UPD include/generated/uapi/linux/version.h > WRAP

Re: [PATCH 1/3] um: fix parallel building with O= option

2018-08-03 Thread Masahiro Yamada
2018-08-04 13:47 GMT+09:00 Masahiro Yamada : > Randy Dunlap reports UML occasionally fails to build with -j and > O= options. > > make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64' > UPD include/generated/uapi/linux/version.h > WRAP

Re: [PATCH v12 0/3] tracing: Centralize preemptirq tracepoints and unify their usage

2018-08-03 Thread Joel Fernandes
Hi Masami, On Fri, Aug 3, 2018 at 12:23 AM, Masami Hiramatsu wrote: > Hi Joel, > > Thank you for trying to fix that. > > On Thu, 2 Aug 2018 19:57:09 -0700 > Joel Fernandes wrote: > >> Hi Masami, >> >> On Thu, Aug 2, 2018 at 7:55 AM, Masami Hiramatsu wrote: >> > Hi Joel, >> > >> > I found this

Re: [PATCH v12 0/3] tracing: Centralize preemptirq tracepoints and unify their usage

2018-08-03 Thread Joel Fernandes
Hi Masami, On Fri, Aug 3, 2018 at 12:23 AM, Masami Hiramatsu wrote: > Hi Joel, > > Thank you for trying to fix that. > > On Thu, 2 Aug 2018 19:57:09 -0700 > Joel Fernandes wrote: > >> Hi Masami, >> >> On Thu, Aug 2, 2018 at 7:55 AM, Masami Hiramatsu wrote: >> > Hi Joel, >> > >> > I found this

[PATCH 3/3] um: clean up archheaders recipe

2018-08-03 Thread Masahiro Yamada
Now that '%asm-generic' is added to no-dot-config-targets, 'make asm-generic' does not include the kernel configuration. You can simply do 'make asm-generic' in the recursed top Makefile without bothering syncconfig. Signed-off-by: Masahiro Yamada --- arch/um/Makefile | 8 +--- 1 file

[PATCH 3/3] um: clean up archheaders recipe

2018-08-03 Thread Masahiro Yamada
Now that '%asm-generic' is added to no-dot-config-targets, 'make asm-generic' does not include the kernel configuration. You can simply do 'make asm-generic' in the recursed top Makefile without bothering syncconfig. Signed-off-by: Masahiro Yamada --- arch/um/Makefile | 8 +--- 1 file

[PATCH 1/3] um: fix parallel building with O= option

2018-08-03 Thread Masahiro Yamada
Randy Dunlap reports UML occasionally fails to build with -j and O= options. make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64' UPD include/generated/uapi/linux/version.h WRAParch/x86/include/generated/asm/dma-contiguous.h WRAP

[PATCH 1/3] um: fix parallel building with O= option

2018-08-03 Thread Masahiro Yamada
Randy Dunlap reports UML occasionally fails to build with -j and O= options. make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64' UPD include/generated/uapi/linux/version.h WRAParch/x86/include/generated/asm/dma-contiguous.h WRAP

[PATCH 2/3] kbuild: add %asm-generic to no-dot-config-targets

2018-08-03 Thread Masahiro Yamada
asm-generic and uapi-asm-generic do not depend on the kernel configuration. In fact, uapi-asm-generic is the prerequisite of headers_{install,check}, hence it should not require the .config file. Signed-off-by: Masahiro Yamada --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 0/3] Kbuild: fix and clean-up arch/um/Makefile

2018-08-03 Thread Masahiro Yamada
1/3 fixes the build failure reported by Randy. (I may have seen a similar report before, but I cannot recall it.) 2/3 and 3/3 clean-up the Makefile a bit more. I'd like to apply this series to kbuild tree. Ack from UML folks are appreciated. Masahiro Yamada (3): um: fix parallel building

[PATCH 2/3] kbuild: add %asm-generic to no-dot-config-targets

2018-08-03 Thread Masahiro Yamada
asm-generic and uapi-asm-generic do not depend on the kernel configuration. In fact, uapi-asm-generic is the prerequisite of headers_{install,check}, hence it should not require the .config file. Signed-off-by: Masahiro Yamada --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 0/3] Kbuild: fix and clean-up arch/um/Makefile

2018-08-03 Thread Masahiro Yamada
1/3 fixes the build failure reported by Randy. (I may have seen a similar report before, but I cannot recall it.) 2/3 and 3/3 clean-up the Makefile a bit more. I'd like to apply this series to kbuild tree. Ack from UML folks are appreciated. Masahiro Yamada (3): um: fix parallel building

Re: [PATCH] RISC-V: Add the directive for alignment of stvec's value

2018-08-03 Thread Palmer Dabbelt
On Wed, 01 Aug 2018 18:26:48 PDT (-0700), zong...@gmail.com wrote: Palmer Dabbelt 於 2018年8月2日 週四 上午8:38寫道: On Wed, 20 Jun 2018 18:40:07 PDT (-0700), z...@andestech.com wrote: > The stvec's value must be 4 byte alignment by specification definition. > This directive avoids to stvec be set the

Re: [PATCH] RISC-V: Add the directive for alignment of stvec's value

2018-08-03 Thread Palmer Dabbelt
On Wed, 01 Aug 2018 18:26:48 PDT (-0700), zong...@gmail.com wrote: Palmer Dabbelt 於 2018年8月2日 週四 上午8:38寫道: On Wed, 20 Jun 2018 18:40:07 PDT (-0700), z...@andestech.com wrote: > The stvec's value must be 4 byte alignment by specification definition. > This directive avoids to stvec be set the

Re: [PATCH 3/6] irqchip: RISC-V Local Interrupt Controller Driver

2018-08-03 Thread Palmer Dabbelt
On Wed, 01 Aug 2018 11:55:06 PDT (-0700), t...@linutronix.de wrote: On Wed, 25 Jul 2018, Christoph Hellwig wrote: On Wed, Jul 25, 2018 at 12:18:39PM +0100, Marc Zyngier wrote: > This feels odd. It means that you cannot have the following sequence: > >local_irq_disable(); >

Re: [PATCH v2] riscv: Add support to no-FPU systems

2018-08-03 Thread Palmer Dabbelt
On Wed, 01 Aug 2018 11:23:43 PDT (-0700), Andrew Waterman wrote: On Wed, Aug 1, 2018 at 10:55 AM, Palmer Dabbelt wrote: On Tue, 26 Jun 2018 21:22:26 PDT (-0700), alan...@andestech.com wrote: This patch adds an option, CONFIG_FPU, to enable/disable floating procedures. Also, some style

Re: [PATCH 3/6] irqchip: RISC-V Local Interrupt Controller Driver

2018-08-03 Thread Palmer Dabbelt
On Wed, 01 Aug 2018 11:55:06 PDT (-0700), t...@linutronix.de wrote: On Wed, 25 Jul 2018, Christoph Hellwig wrote: On Wed, Jul 25, 2018 at 12:18:39PM +0100, Marc Zyngier wrote: > This feels odd. It means that you cannot have the following sequence: > >local_irq_disable(); >

Re: [PATCH v2] riscv: Add support to no-FPU systems

2018-08-03 Thread Palmer Dabbelt
On Wed, 01 Aug 2018 11:23:43 PDT (-0700), Andrew Waterman wrote: On Wed, Aug 1, 2018 at 10:55 AM, Palmer Dabbelt wrote: On Tue, 26 Jun 2018 21:22:26 PDT (-0700), alan...@andestech.com wrote: This patch adds an option, CONFIG_FPU, to enable/disable floating procedures. Also, some style

[PATCH] mfd: sm501: Set coherent_dma_mask when creating subdevices

2018-08-03 Thread Guenter Roeck
Instantiating the sm501 OHCI subdevice results in a kernel warning. sm501-usb sm501-usb: SM501 OHCI sm501-usb sm501-usb: new USB bus registered, assigned bus number 1 WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 ohci_init+0x194/0x2d8 Modules linked in: CPU: 0 PID: 1 Comm: swapper

[PATCH] mfd: sm501: Set coherent_dma_mask when creating subdevices

2018-08-03 Thread Guenter Roeck
Instantiating the sm501 OHCI subdevice results in a kernel warning. sm501-usb sm501-usb: SM501 OHCI sm501-usb sm501-usb: new USB bus registered, assigned bus number 1 WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 ohci_init+0x194/0x2d8 Modules linked in: CPU: 0 PID: 1 Comm: swapper

Re: kbuild: ARCH=um archheaders failed

2018-08-03 Thread Masahiro Yamada
2018-08-04 0:41 GMT+09:00 Randy Dunlap : > On 08/02/2018 05:13 PM, Randy Dunlap wrote: >> Hi Yamada-san, >> >> I see this every few weeks. It's not reproducible (it depends >> on the moon, Mars, etc.). >> >> I'm using O=builddir. The build log is short (below). >> >> Do you see a makefile

Re: kbuild: ARCH=um archheaders failed

2018-08-03 Thread Masahiro Yamada
2018-08-04 0:41 GMT+09:00 Randy Dunlap : > On 08/02/2018 05:13 PM, Randy Dunlap wrote: >> Hi Yamada-san, >> >> I see this every few weeks. It's not reproducible (it depends >> on the moon, Mars, etc.). >> >> I'm using O=builddir. The build log is short (below). >> >> Do you see a makefile

Re: [PATCH] pstore: set PSTORE_ZSTD_COMPRESS to bool

2018-08-03 Thread Kees Cook
On Fri, Aug 3, 2018 at 2:16 AM, Geliang Tang wrote: > Fix build error: > >fs/pstore/platform.o: In function `zbufsize_zstd': >>> platform.c:(.text+0x172): undefined reference to `ZSTD_compressBound' > > Signed-off-by: Geliang Tang Thanks! I'll squash this into the original commit. -Kees >

Re: [PATCH] pstore: set PSTORE_ZSTD_COMPRESS to bool

2018-08-03 Thread Kees Cook
On Fri, Aug 3, 2018 at 2:16 AM, Geliang Tang wrote: > Fix build error: > >fs/pstore/platform.o: In function `zbufsize_zstd': >>> platform.c:(.text+0x172): undefined reference to `ZSTD_compressBound' > > Signed-off-by: Geliang Tang Thanks! I'll squash this into the original commit. -Kees >

[PATCH] spi-nor: add support for is25wp256d

2018-08-03 Thread Palmer Dabbelt
From: "Wesley W. Terpstra" This is used of the HiFive Unleashed development board. Signed-off-by: Wesley W. Terpstra Signed-off-by: Palmer Dabbelt --- drivers/mtd/spi-nor/spi-nor.c | 47 ++- include/linux/mtd/spi-nor.h | 2 ++ 2 files changed, 48

[PATCH] spi-nor: add support for is25wp256d

2018-08-03 Thread Palmer Dabbelt
From: "Wesley W. Terpstra" This is used of the HiFive Unleashed development board. Signed-off-by: Wesley W. Terpstra Signed-off-by: Palmer Dabbelt --- drivers/mtd/spi-nor/spi-nor.c | 47 ++- include/linux/mtd/spi-nor.h | 2 ++ 2 files changed, 48

Re: [PATCH 6/6] dt-bindings: interrupt-controller: RISC-V PLIC documentation

2018-08-03 Thread Palmer Dabbelt
On Wed, 01 Aug 2018 11:26:31 PDT (-0700), r...@kernel.org wrote: On Wed, Aug 1, 2018 at 1:12 AM Christoph Hellwig wrote: On Tue, Jul 31, 2018 at 04:46:30PM -0600, Rob Herring wrote: > Perhaps this should be 'sifive,plic0' Excepet for the fact this the old name has already been in shipping

Re: [PATCH 6/6] dt-bindings: interrupt-controller: RISC-V PLIC documentation

2018-08-03 Thread Palmer Dabbelt
On Wed, 01 Aug 2018 11:26:31 PDT (-0700), r...@kernel.org wrote: On Wed, Aug 1, 2018 at 1:12 AM Christoph Hellwig wrote: On Tue, Jul 31, 2018 at 04:46:30PM -0600, Rob Herring wrote: > Perhaps this should be 'sifive,plic0' Excepet for the fact this the old name has already been in shipping

Re: [PATCH] checkpatch: Check for space after "else" keyword

2018-08-03 Thread Joe Perches
On Thu, 2018-08-02 at 23:20 +0200, Michal Zylowski wrote: > Current checkpatch implementation permits notation like: > } else{ > in kernel code. > It looks like oversight and inconsistency in checkpatch rules (e.g. > instruction like 'do' is tested). > > Add regex for checking space after 'else'

Re: [PATCH] checkpatch: Check for space after "else" keyword

2018-08-03 Thread Joe Perches
On Thu, 2018-08-02 at 23:20 +0200, Michal Zylowski wrote: > Current checkpatch implementation permits notation like: > } else{ > in kernel code. > It looks like oversight and inconsistency in checkpatch rules (e.g. > instruction like 'do' is tested). > > Add regex for checking space after 'else'

Re: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-03 Thread Andrew Pinski
On Fri, Aug 3, 2018 at 5:58 PM Mikulas Patocka wrote: > > > > On Fri, 3 Aug 2018, Richard Earnshaw (lists) wrote: > > > Whoa, hold on. > > > > Memcpy should never be used on device memory. Period. Memcpy doesn't > > know anything about what size of access is needed for accessing a device. > > >

Re: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-03 Thread Andrew Pinski
On Fri, Aug 3, 2018 at 5:58 PM Mikulas Patocka wrote: > > > > On Fri, 3 Aug 2018, Richard Earnshaw (lists) wrote: > > > Whoa, hold on. > > > > Memcpy should never be used on device memory. Period. Memcpy doesn't > > know anything about what size of access is needed for accessing a device. > > >

[PATCH] get_maintainer.pl: Add -mpath= for MAINTAINERS file location

2018-08-03 Thread Joe Perches
Add the ability to have an override for the location of the MAINTAINERS file. Miscellanea: o Properly indent a few lines with leading spaces Suggested-by: Don Zickus Signed-off-by: Joe Perches --- scripts/get_maintainer.pl | 48 +-- 1 file changed,

[PATCH] get_maintainer.pl: Add -mpath= for MAINTAINERS file location

2018-08-03 Thread Joe Perches
Add the ability to have an override for the location of the MAINTAINERS file. Miscellanea: o Properly indent a few lines with leading spaces Suggested-by: Don Zickus Signed-off-by: Joe Perches --- scripts/get_maintainer.pl | 48 +-- 1 file changed,

Re: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-03 Thread Mikulas Patocka
On Fri, 3 Aug 2018, Richard Earnshaw (lists) wrote: > Whoa, hold on. > > Memcpy should never be used on device memory. Period. Memcpy doesn't > know anything about what size of access is needed for accessing a device. > > But why is the buffer in device memory rather than some other form

Re: framebuffer corruption due to overlapping stp instructions on arm64

2018-08-03 Thread Mikulas Patocka
On Fri, 3 Aug 2018, Richard Earnshaw (lists) wrote: > Whoa, hold on. > > Memcpy should never be used on device memory. Period. Memcpy doesn't > know anything about what size of access is needed for accessing a device. > > But why is the buffer in device memory rather than some other form

Re: [PATCH 5/7] x86/mm/init: remove freed kernel image areas from alias mapping

2018-08-03 Thread Hugh Dickins
On Thu, 2 Aug 2018, Dave Hansen wrote: > > From: Dave Hansen > > The kernel image is mapped into two places in the virtual address > space (addresses without KASLR, of course): > > 1. The kernel direct map (0x8800) > 2. The "high kernel map" (0x8100) > > We

Re: [PATCH 5/7] x86/mm/init: remove freed kernel image areas from alias mapping

2018-08-03 Thread Hugh Dickins
On Thu, 2 Aug 2018, Dave Hansen wrote: > > From: Dave Hansen > > The kernel image is mapped into two places in the virtual address > space (addresses without KASLR, of course): > > 1. The kernel direct map (0x8800) > 2. The "high kernel map" (0x8100) > > We

Re: [PATCH 3/7] x86/mm/init: pass unconverted symbol addresses to free_init_pages()

2018-08-03 Thread Hugh Dickins
On Thu, 2 Aug 2018, Dave Hansen wrote: > > From: Dave Hansen > > The x86 code has several places where it frees parts of kernel image: > > 1. Unused SMP alternative > 2. __init code > 3. The hole between text and rodata > 4. The hole between rodata and data > > We call free_init_pages()

Re: [PATCH 3/7] x86/mm/init: pass unconverted symbol addresses to free_init_pages()

2018-08-03 Thread Hugh Dickins
On Thu, 2 Aug 2018, Dave Hansen wrote: > > From: Dave Hansen > > The x86 code has several places where it frees parts of kernel image: > > 1. Unused SMP alternative > 2. __init code > 3. The hole between text and rodata > 4. The hole between rodata and data > > We call free_init_pages()

Re: [PATCH v7 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings

2018-08-03 Thread Stephen Boyd
Quoting Taniya Das (2018-07-24 03:42:49) > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > new file mode 100644 > index 000..22d4355 > --- /dev/null > +++

Re: [PATCH v7 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings

2018-08-03 Thread Stephen Boyd
Quoting Taniya Das (2018-07-24 03:42:49) > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt > new file mode 100644 > index 000..22d4355 > --- /dev/null > +++

Re: [PATCH] mfd: sec: Export OF module alias table

2018-08-03 Thread Javier Martinez Canillas
Hi Krzysztof, On Wed, Jul 25, 2018 at 5:53 PM, Krzysztof Kozlowski wrote: > In case of Device Tree platforms, even though the Samsung PMIC sec > device is instantiated from DT, the driver is still matched through I2C > module alias. That is because I2C core always reports an I2C module > alias

Re: [PATCH] mfd: sec: Export OF module alias table

2018-08-03 Thread Javier Martinez Canillas
Hi Krzysztof, On Wed, Jul 25, 2018 at 5:53 PM, Krzysztof Kozlowski wrote: > In case of Device Tree platforms, even though the Samsung PMIC sec > device is instantiated from DT, the driver is still matched through I2C > module alias. That is because I2C core always reports an I2C module > alias

Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

2018-08-03 Thread Andrew Morton
On Fri, 3 Aug 2018 11:51:43 +0900 Minchan Kim wrote: > > Is it legitimate to be altering the bdi capabilities at this level? Or > > is this hacky? > > Most of device's bdi capability seems to be static but there are few drivers > which can change capability. For example, BDI_CAP_STABLE_WRITES

Re: [PATCH 1/2] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

2018-08-03 Thread Andrew Morton
On Fri, 3 Aug 2018 11:51:43 +0900 Minchan Kim wrote: > > Is it legitimate to be altering the bdi capabilities at this level? Or > > is this hacky? > > Most of device's bdi capability seems to be static but there are few drivers > which can change capability. For example, BDI_CAP_STABLE_WRITES

Re: [PATCH RESEND] exec: don't force_sigsegv processes with a pending fatal signal

2018-08-03 Thread Ivan Delalande
Hi, On Fri, Aug 03, 2018 at 03:39:24PM +0200, Oleg Nesterov wrote: > On 08/02, Dmitry Safonov wrote: > > 2018-07-31 1:56 GMT+01:00 Ivan Delalande : > > > We were seeing unexplained segfaults in coreutils processes and other > > > basic utilities that we tracked down to binfmt_elf failing to load

Re: [PATCH RESEND] exec: don't force_sigsegv processes with a pending fatal signal

2018-08-03 Thread Ivan Delalande
Hi, On Fri, Aug 03, 2018 at 03:39:24PM +0200, Oleg Nesterov wrote: > On 08/02, Dmitry Safonov wrote: > > 2018-07-31 1:56 GMT+01:00 Ivan Delalande : > > > We were seeing unexplained segfaults in coreutils processes and other > > > basic utilities that we tracked down to binfmt_elf failing to load

Re: [PATCH v7 4/8] interconnect: qcom: Add RPM communication

2018-08-03 Thread Evan Green
On Tue, Jul 31, 2018 at 9:13 AM Georgi Djakov wrote: > > On some Qualcomm SoCs, there is a remote processor, which controls some of > the Network-On-Chip interconnect resources. Other CPUs express their needs > by communicating with this processor. Add a driver to handle communication > with this

Re: [PATCH v7 4/8] interconnect: qcom: Add RPM communication

2018-08-03 Thread Evan Green
On Tue, Jul 31, 2018 at 9:13 AM Georgi Djakov wrote: > > On some Qualcomm SoCs, there is a remote processor, which controls some of > the Network-On-Chip interconnect resources. Other CPUs express their needs > by communicating with this processor. Add a driver to handle communication > with this

Re: [PATCH v7 3/8] interconnect: Add debugfs support

2018-08-03 Thread Evan Green
On Tue, Jul 31, 2018 at 9:13 AM Georgi Djakov wrote: > > Add a functionality to provide information about the current constraints > per each node and provider. > > Signed-off-by: Georgi Djakov > --- > drivers/interconnect/core.c | 78 + > 1 file changed, 78

Re: [PATCH v7 3/8] interconnect: Add debugfs support

2018-08-03 Thread Evan Green
On Tue, Jul 31, 2018 at 9:13 AM Georgi Djakov wrote: > > Add a functionality to provide information about the current constraints > per each node and provider. > > Signed-off-by: Georgi Djakov > --- > drivers/interconnect/core.c | 78 + > 1 file changed, 78

Re: [PATCH v7 8/8] interconnect: Allow endpoints translation via DT

2018-08-03 Thread Evan Green
On Tue, Jul 31, 2018 at 9:13 AM Georgi Djakov wrote: > > Currently we support only platform data for specifying the interconnect > endpoints. As now the endpoints are hard-coded into the consumer driver > this may lead to complications when a single driver is used by multiple > SoCs, which may

Re: [PATCH v7 8/8] interconnect: Allow endpoints translation via DT

2018-08-03 Thread Evan Green
On Tue, Jul 31, 2018 at 9:13 AM Georgi Djakov wrote: > > Currently we support only platform data for specifying the interconnect > endpoints. As now the endpoints are hard-coded into the consumer driver > this may lead to complications when a single driver is used by multiple > SoCs, which may

Re: [PATCH] mm: Use special value SHRINKER_REGISTERING instead list_empty() check

2018-08-03 Thread Matthew Wilcox
On Fri, Aug 03, 2018 at 03:51:20PM -0700, Andrew Morton wrote: > On Fri, 03 Aug 2018 18:36:14 +0300 Kirill Tkhai wrote: > > The patch introduces a special value SHRINKER_REGISTERING to use instead > > of list_empty() to detect a semi-registered shrinker. > > All this isn't terribly nice. Why

Re: [PATCH] mm: Use special value SHRINKER_REGISTERING instead list_empty() check

2018-08-03 Thread Matthew Wilcox
On Fri, Aug 03, 2018 at 03:51:20PM -0700, Andrew Morton wrote: > On Fri, 03 Aug 2018 18:36:14 +0300 Kirill Tkhai wrote: > > The patch introduces a special value SHRINKER_REGISTERING to use instead > > of list_empty() to detect a semi-registered shrinker. > > All this isn't terribly nice. Why

Re: [PATCH v7 6/8] interconnect: qcom: Add msm8916 interconnect provider driver

2018-08-03 Thread Evan Green
On Tue, Jul 31, 2018 at 9:13 AM Georgi Djakov wrote: > > Add driver for the Qualcomm interconnect buses found in msm8916 based > platforms. > > Signed-off-by: Georgi Djakov > --- > drivers/interconnect/Kconfig| 5 + > drivers/interconnect/Makefile | 1 + >

Re: [PATCH v7 1/8] interconnect: Add generic on-chip interconnect API

2018-08-03 Thread Evan Green
On Tue, Jul 31, 2018 at 9:13 AM Georgi Djakov wrote: > > This patch introduces a new API to get requirements and configure the > interconnect buses across the entire chipset to fit with the current > demand. > > The API is using a consumer/provider-based model, where the providers are > the

Re: [PATCH v7 6/8] interconnect: qcom: Add msm8916 interconnect provider driver

2018-08-03 Thread Evan Green
On Tue, Jul 31, 2018 at 9:13 AM Georgi Djakov wrote: > > Add driver for the Qualcomm interconnect buses found in msm8916 based > platforms. > > Signed-off-by: Georgi Djakov > --- > drivers/interconnect/Kconfig| 5 + > drivers/interconnect/Makefile | 1 + >

Re: [PATCH v7 1/8] interconnect: Add generic on-chip interconnect API

2018-08-03 Thread Evan Green
On Tue, Jul 31, 2018 at 9:13 AM Georgi Djakov wrote: > > This patch introduces a new API to get requirements and configure the > interconnect buses across the entire chipset to fit with the current > demand. > > The API is using a consumer/provider-based model, where the providers are > the

Re: [PATCH] mm: Use special value SHRINKER_REGISTERING instead list_empty() check

2018-08-03 Thread Andrew Morton
On Fri, 03 Aug 2018 18:36:14 +0300 Kirill Tkhai wrote: > The patch introduces a special value SHRINKER_REGISTERING to use instead > of list_empty() to detect a semi-registered shrinker. > > This should be clearer for a reader since "list is empty" is not > an intuitive state of a shrinker),

Re: [PATCH] mm: Use special value SHRINKER_REGISTERING instead list_empty() check

2018-08-03 Thread Andrew Morton
On Fri, 03 Aug 2018 18:36:14 +0300 Kirill Tkhai wrote: > The patch introduces a special value SHRINKER_REGISTERING to use instead > of list_empty() to detect a semi-registered shrinker. > > This should be clearer for a reader since "list is empty" is not > an intuitive state of a shrinker),

Re: [PATCH] parisc: prefer _THIS_IP_ and _RET_IP_ statement expressions

2018-08-03 Thread Helge Deller
On 03.08.2018 22:33, Nick Desaulniers wrote: > On Fri, Aug 3, 2018 at 12:09 PM John David Anglin > wrote: >> >> On 2018-08-03 2:11 PM, Nick Desaulniers wrote: >>> But the kernel uses the generic_THIS_IP_ *everywhere*, not parisc's >>> custom current_text_addr(). So if this did actually break

Re: [PATCH] parisc: prefer _THIS_IP_ and _RET_IP_ statement expressions

2018-08-03 Thread Helge Deller
On 03.08.2018 22:33, Nick Desaulniers wrote: > On Fri, Aug 3, 2018 at 12:09 PM John David Anglin > wrote: >> >> On 2018-08-03 2:11 PM, Nick Desaulniers wrote: >>> But the kernel uses the generic_THIS_IP_ *everywhere*, not parisc's >>> custom current_text_addr(). So if this did actually break

Re: [PATCH v3 2/2] slab: __GFP_ZERO is incompatible with a constructor

2018-08-03 Thread Matthew Wilcox
On Fri, Aug 03, 2018 at 02:22:57PM -0700, Guenter Roeck wrote: > Hi, > > On Thu, Apr 12, 2018 at 12:13:22PM -0700, Matthew Wilcox wrote: > > From: Matthew Wilcox > > > > __GFP_ZERO requests that the object be initialised to all-zeroes, > > while the purpose of a constructor is to initialise an

Re: [PATCH v3 2/2] slab: __GFP_ZERO is incompatible with a constructor

2018-08-03 Thread Matthew Wilcox
On Fri, Aug 03, 2018 at 02:22:57PM -0700, Guenter Roeck wrote: > Hi, > > On Thu, Apr 12, 2018 at 12:13:22PM -0700, Matthew Wilcox wrote: > > From: Matthew Wilcox > > > > __GFP_ZERO requests that the object be initialised to all-zeroes, > > while the purpose of a constructor is to initialise an

Re: [PATCH v7 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

2018-08-03 Thread Stephen Boyd
Quoting skan...@codeaurora.org (2018-08-03 12:52:48) > On 2018-08-03 12:40, Evan Green wrote: > > Hi Taniya, > > > > On Tue, Jul 24, 2018 at 3:44 AM Taniya Das wrote: > >> > >> + if (src) > >> + c->table[i].frequency = c->xo_rate * lval / > >> 1000; > >> +

Re: [PATCH v7 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

2018-08-03 Thread Stephen Boyd
Quoting skan...@codeaurora.org (2018-08-03 12:52:48) > On 2018-08-03 12:40, Evan Green wrote: > > Hi Taniya, > > > > On Tue, Jul 24, 2018 at 3:44 AM Taniya Das wrote: > >> > >> + if (src) > >> + c->table[i].frequency = c->xo_rate * lval / > >> 1000; > >> +

[PATCH] arm64: dts: sdm845: Add dispcc node

2018-08-03 Thread Matthias Kaehlcke
This adds the display clock controller node to sdm845 based on the examples in the bindings. Signed-off-by: Matthias Kaehlcke --- The dispcc driver and DT bindings landed in the clk-qcom-dispcc-845 branch of the clk tree. arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 + 1 file changed, 9

[PATCH] arm64: dts: sdm845: Add dispcc node

2018-08-03 Thread Matthias Kaehlcke
This adds the display clock controller node to sdm845 based on the examples in the bindings. Signed-off-by: Matthias Kaehlcke --- The dispcc driver and DT bindings landed in the clk-qcom-dispcc-845 branch of the clk tree. arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 + 1 file changed, 9

Re: [PATCH v3 1/2] iio: light: Add support for vishay vcnl4035

2018-08-03 Thread Jonathan Cameron
On Thu, 2 Aug 2018 16:01:32 +0200 Parthiban Nallathambi wrote: > Hi Jonathan, > > General query, for threshold events and persistence value (period) we > don't have any direct MACROS similar to IIO_CONST_ATTR_INT_TIME_AVAIL > as ABI to show the available/range of values. > > For most light and

Re: [PATCH v3 1/2] iio: light: Add support for vishay vcnl4035

2018-08-03 Thread Jonathan Cameron
On Thu, 2 Aug 2018 16:01:32 +0200 Parthiban Nallathambi wrote: > Hi Jonathan, > > General query, for threshold events and persistence value (period) we > don't have any direct MACROS similar to IIO_CONST_ATTR_INT_TIME_AVAIL > as ABI to show the available/range of values. > > For most light and

Re: [PATCH] genirq: Consider domain hierarchy when checking for IRQCHIP_ONESHOT_SAFE

2018-08-03 Thread Thomas Gleixner
On Fri, 3 Aug 2018, Heiner Kallweit wrote: > On 03.08.2018 22:00, Thomas Gleixner wrote: > > On Fri, 3 Aug 2018, Heiner Kallweit wrote: > > > >> In case of a domain hierarchy we may miss the IRQCHIP_ONESHOT_SAFE > >> flag because we look at top of the stack only. See also discussion > >> here:

Re: [PATCH] genirq: Consider domain hierarchy when checking for IRQCHIP_ONESHOT_SAFE

2018-08-03 Thread Thomas Gleixner
On Fri, 3 Aug 2018, Heiner Kallweit wrote: > On 03.08.2018 22:00, Thomas Gleixner wrote: > > On Fri, 3 Aug 2018, Heiner Kallweit wrote: > > > >> In case of a domain hierarchy we may miss the IRQCHIP_ONESHOT_SAFE > >> flag because we look at top of the stack only. See also discussion > >> here:

Re: [PATCH v3 1/3] iio: adc: add support for mcp3911

2018-08-03 Thread Jonathan Cameron
On Thu, 2 Aug 2018 22:52:00 +0300 Andy Shevchenko wrote: > On Thu, Aug 2, 2018 at 10:15 PM, Marcus Folkesson > wrote: > > MCP3911 is a dual channel Analog Front End (AFE) containing two > > synchronous sampling delta-sigma Analog-to-Digital Converters (ADC). > > > > Signed-off-by: Marcus

Re: [PATCH v3 1/3] iio: adc: add support for mcp3911

2018-08-03 Thread Jonathan Cameron
On Thu, 2 Aug 2018 22:52:00 +0300 Andy Shevchenko wrote: > On Thu, Aug 2, 2018 at 10:15 PM, Marcus Folkesson > wrote: > > MCP3911 is a dual channel Analog Front End (AFE) containing two > > synchronous sampling delta-sigma Analog-to-Digital Converters (ADC). > > > > Signed-off-by: Marcus

Loan and investment

2018-08-03 Thread Tajick Ali
Greetings, I represent business group in Middle East looking for projects to fund; we seek any business that will guaranty a safe and secure return on investments. Alternative powers, movies, start up companies etc. We are also looking for commercial building projects, hotels, casino, strip

Loan and investment

2018-08-03 Thread Tajick Ali
Greetings, I represent business group in Middle East looking for projects to fund; we seek any business that will guaranty a safe and secure return on investments. Alternative powers, movies, start up companies etc. We are also looking for commercial building projects, hotels, casino, strip

[PATCH v2 2/4] userfaultfd: selftest: Skip test if userfaultfd() syscall not supported

2018-08-03 Thread Thiago Jung Bauermann
Since there's no point in doing anything in this case, immediately exit the process. And take the opportunity to improve the error message. Before: # ./userfaultfd shmem 10 10 nr_pages: 160, nr_pages_per_cpu: 40 userfaultfd syscall not available in this kernel # echo $? 1 After: #

[PATCH v2 2/4] userfaultfd: selftest: Skip test if userfaultfd() syscall not supported

2018-08-03 Thread Thiago Jung Bauermann
Since there's no point in doing anything in this case, immediately exit the process. And take the opportunity to improve the error message. Before: # ./userfaultfd shmem 10 10 nr_pages: 160, nr_pages_per_cpu: 40 userfaultfd syscall not available in this kernel # echo $? 1 After: #

[PATCH v2 1/4] userfaultfd: selftest: Fix checking of userfaultfd_open() result

2018-08-03 Thread Thiago Jung Bauermann
If the userfaultfd test is run on a kernel with CONFIG_USERFAULTFD=n, it will report that the system call is not available yet go ahead and continue anyway: # ./userfaultfd anon 30 1 nr_pages: 480, nr_pages_per_cpu: 120 userfaultfd syscall not available in this kernel bounces: 0, mode:,

[PATCH v2 0/4] userfaultfd: selftest: Improve behavior with older kernels

2018-08-03 Thread Thiago Jung Bauermann
Hello, A tester ran the upstream selftest on a distro kernel and sounded the alarm when it reported failures for features which aren't included in that kernel. This patch set improves the test behavior in that scenario. Changes since v1: - Patch "userfaultfd: selftest: Skip test if

[PATCH v2 1/4] userfaultfd: selftest: Fix checking of userfaultfd_open() result

2018-08-03 Thread Thiago Jung Bauermann
If the userfaultfd test is run on a kernel with CONFIG_USERFAULTFD=n, it will report that the system call is not available yet go ahead and continue anyway: # ./userfaultfd anon 30 1 nr_pages: 480, nr_pages_per_cpu: 120 userfaultfd syscall not available in this kernel bounces: 0, mode:,

[PATCH v2 0/4] userfaultfd: selftest: Improve behavior with older kernels

2018-08-03 Thread Thiago Jung Bauermann
Hello, A tester ran the upstream selftest on a distro kernel and sounded the alarm when it reported failures for features which aren't included in that kernel. This patch set improves the test behavior in that scenario. Changes since v1: - Patch "userfaultfd: selftest: Skip test if

[PATCH v2 4/4] userfaultfd: selftest: Cope if shmem doesn't support zeropage

2018-08-03 Thread Thiago Jung Bauermann
If userfaultfd runs on a system that doesn't support UFFDIO_ZEROPAGE for shared memory, it currently ends with error code 1 which indicates test failure: # ./userfaultfd shmem 10 10 nr_pages: 160, nr_pages_per_cpu: 80 bounces: 9, mode: rnd poll, unexpected missing ioctl for anon memory #

[PATCH v2 4/4] userfaultfd: selftest: Cope if shmem doesn't support zeropage

2018-08-03 Thread Thiago Jung Bauermann
If userfaultfd runs on a system that doesn't support UFFDIO_ZEROPAGE for shared memory, it currently ends with error code 1 which indicates test failure: # ./userfaultfd shmem 10 10 nr_pages: 160, nr_pages_per_cpu: 80 bounces: 9, mode: rnd poll, unexpected missing ioctl for anon memory #

[PATCH v2 3/4] userfaultfd: selftest: Skip test if a feature isn't supported

2018-08-03 Thread Thiago Jung Bauermann
If userfaultfd runs on a system that doesn't support some feature it is trying to test, it currently ends with error code 1 which indicates test failure: # ./userfaultfd anon 10 10 nr_pages: 160, nr_pages_per_cpu: 80 bounces: 9, mode: rnd poll, userfaults: 7 59 bounces: 8, mode: poll,

[PATCH v2 3/4] userfaultfd: selftest: Skip test if a feature isn't supported

2018-08-03 Thread Thiago Jung Bauermann
If userfaultfd runs on a system that doesn't support some feature it is trying to test, it currently ends with error code 1 which indicates test failure: # ./userfaultfd anon 10 10 nr_pages: 160, nr_pages_per_cpu: 80 bounces: 9, mode: rnd poll, userfaults: 7 59 bounces: 8, mode: poll,

  1   2   3   4   5   6   7   8   9   10   >