[PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver

Introduce new Mellanox platform driver to allow access to Mellanox programmable device register space trough sysfs interface. The driver purpose is to provide sysfs interface for user space for the registers essential for system control and monitoring. The sets of registers for sysfs access are

[PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver

Introduce new Mellanox platform driver to allow access to Mellanox programmable device register space trough sysfs interface. The driver purpose is to provide sysfs interface for user space for the registers essential for system control and monitoring. The sets of registers for sysfs access are

Re: [PATCH v2 4/4] drm/tinydrm: new driver for ILI9341 display panels

-Lechner/drm-tinydrm-new-dirver-for-ILI9341-displays/20180527-182036 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/tinydrm/ili9341.c:128:30: sparse: to

Re: [PATCH v2 4/4] drm/tinydrm: new driver for ILI9341 display panels

-Lechner/drm-tinydrm-new-dirver-for-ILI9341-displays/20180527-182036 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/tinydrm/ili9341.c:128:30: sparse: to

Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem

On Sat, May 26, 2018 at 6:33 PM, Linus Torvalds wrote: > Thus commit f511c0b17b08 "Yes, people use FOLL_FORCE ;)" > > Side note, that very sam ecommit f511c0b17b08 is also the explanation for > why the patch under discussion now seems broken. > > People really do

Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem

On Sat, May 26, 2018 at 6:33 PM, Linus Torvalds wrote: > Thus commit f511c0b17b08 "Yes, people use FOLL_FORCE ;)" > > Side note, that very sam ecommit f511c0b17b08 is also the explanation for > why the patch under discussion now seems broken. > > People really do use "write to /proc/self/mem" as

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

Hi Stefan, On Thu, 24 May 2018 14:19:18 +0200, Stefan Agner wrote: > On 24.05.2018 13:53, Boris Brezillon wrote: > > Hi Benjamin, > > > > On Thu, 24 May 2018 13:30:14 +0200 > > Benjamin Lindqvist wrote: > > > >> Hi Stefan, > >> > >> It seems

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

Hi Stefan, On Thu, 24 May 2018 14:19:18 +0200, Stefan Agner wrote: > On 24.05.2018 13:53, Boris Brezillon wrote: > > Hi Benjamin, > > > > On Thu, 24 May 2018 13:30:14 +0200 > > Benjamin Lindqvist wrote: > > > >> Hi Stefan, > >> > >> It seems to me that a probe similar to what the BootROM

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

Hi Stefan, On Fri, 25 May 2018 00:56:23 +0200, Stefan Agner wrote: > On 24.05.2018 14:41, Boris Brezillon wrote: > > On Thu, 24 May 2018 14:23:56 +0200 > > Boris Brezillon wrote: > > > >> On Thu, 24 May 2018 13:09:53 +0200 > >> Stefan Agner

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

Hi Stefan, On Fri, 25 May 2018 00:56:23 +0200, Stefan Agner wrote: > On 24.05.2018 14:41, Boris Brezillon wrote: > > On Thu, 24 May 2018 14:23:56 +0200 > > Boris Brezillon wrote: > > > >> On Thu, 24 May 2018 13:09:53 +0200 > >> Stefan Agner wrote: > >> > >> > On 24.05.2018 10:56, Boris

Re: [PATCH v2 4/4] drm/tinydrm: new driver for ILI9341 display panels

/drm-tinydrm-new-dirver-for-ILI9341-displays/20180527-182036 config: i386-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/g

Re: [PATCH v2 4/4] drm/tinydrm: new driver for ILI9341 display panels

/drm-tinydrm-new-dirver-for-ILI9341-displays/20180527-182036 config: i386-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/g

Re: [PATCH v2 4/4] drm/tinydrm: new driver for ILI9341 display panels

/drm-tinydrm-new-dirver-for-ILI9341-displays/20180527-182036 config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 8.1.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross

Re: [PATCH v2 4/4] drm/tinydrm: new driver for ILI9341 display panels

/drm-tinydrm-new-dirver-for-ILI9341-displays/20180527-182036 config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 8.1.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross

[PATCH 2/2] ARM: OMAP1: ams-delta: assign LED GPIO numbers from descriptors

Assign a label to latch1 GPIO device the LEDs hang off, enumerate its pins for the purpose of indexing gpio_led table, remove hardcoded GPIO numbers from that table replacing them with invalid GPIO numbers and remove initialization of incompletely described LED device from machine_init. As soon

[PATCH 1/2] ARM: OMAP1: ams-delta: refactor late_init()

Before the board level GPIO handling is converted from GPIO numbers to GPIO descriptors, split late_init() into functional blocks and move them to separate functions. While being at it, drop machine type check from late_init() - the function is now called from the board init_late callback so

[PATCH 2/2] ARM: OMAP1: ams-delta: assign LED GPIO numbers from descriptors

Assign a label to latch1 GPIO device the LEDs hang off, enumerate its pins for the purpose of indexing gpio_led table, remove hardcoded GPIO numbers from that table replacing them with invalid GPIO numbers and remove initialization of incompletely described LED device from machine_init. As soon

[PATCH 1/2] ARM: OMAP1: ams-delta: refactor late_init()

Before the board level GPIO handling is converted from GPIO numbers to GPIO descriptors, split late_init() into functional blocks and move them to separate functions. While being at it, drop machine type check from late_init() - the function is now called from the board init_late callback so

Re: [PATCH v3 15/16] mtd: rawnand: qcom: helper function for raw read

Hi Abhishek, On Fri, 25 May 2018 17:51:43 +0530, Abhishek Sahu wrote: > This patch does minor code reorganization for raw reads. > Currently the raw read is required for complete page but for > subsequent patches related with erased codeword bit flips > detection, only

Re: [PATCH v3 15/16] mtd: rawnand: qcom: helper function for raw read

Hi Abhishek, On Fri, 25 May 2018 17:51:43 +0530, Abhishek Sahu wrote: > This patch does minor code reorganization for raw reads. > Currently the raw read is required for complete page but for > subsequent patches related with erased codeword bit flips > detection, only few CW should be read.

Re: [f2fs-dev] [PATCH] f2fs-tools: fix overflow bug of start_sector when computing zone_align_start_offset

Just keep it same with u_int64_t defined in mkfs/f2fs_format.c, and c.start_sector * c.sector_size may be u32 overflow, so add (u_int64_t) before c.start_sector * c.sector_size and change the target value zone_align_start_offset to (u_int64_t). On 2018/5/26 19:27, Junling Zheng wrote: No neet

Re: [f2fs-dev] [PATCH] f2fs-tools: fix overflow bug of start_sector when computing zone_align_start_offset

Just keep it same with u_int64_t defined in mkfs/f2fs_format.c, and c.start_sector * c.sector_size may be u32 overflow, so add (u_int64_t) before c.start_sector * c.sector_size and change the target value zone_align_start_offset to (u_int64_t). On 2018/5/26 19:27, Junling Zheng wrote: No neet

[PATCH] staging: mt7621-pci: Fix line size exceeding 80 columns.

This patch fixes the checkpatch.pl warning: WARNING: line over 80 characters Signed-off-by: Sankalp Negi --- drivers/staging/mt7621-pci/pci-mt7621.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c

[PATCH] staging: mt7621-pci: Fix line size exceeding 80 columns.

This patch fixes the checkpatch.pl warning: WARNING: line over 80 characters Signed-off-by: Sankalp Negi --- drivers/staging/mt7621-pci/pci-mt7621.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c

[PATCH] iptables-compat: homogenize error message

There is a difference between error messages in iptables and iptables-compat: #sudo iptables-compat -D INPUT 4 iptables: No chain/target/match by that name. #sudo iptables -D INPUT 4 iptables: Index of deletion too big. Now, will show same error message. Signed-off-by: Arushi Singhal

[PATCH] iptables-compat: homogenize error message

There is a difference between error messages in iptables and iptables-compat: #sudo iptables-compat -D INPUT 4 iptables: No chain/target/match by that name. #sudo iptables -D INPUT 4 iptables: Index of deletion too big. Now, will show same error message. Signed-off-by: Arushi Singhal ---

Re: [PATCH] doc: document scope NOFS, NOIO APIs

On Fri, May 25, 2018 at 10:16:24AM +0200, Michal Hocko wrote: > On Fri 25-05-18 08:17:15, Dave Chinner wrote: > > On Thu, May 24, 2018 at 01:43:41PM +0200, Michal Hocko wrote: > [...] > > > +FS/IO code then simply calls the appropriate save function right at the > > > +layer where a lock taken

Re: [PATCH] doc: document scope NOFS, NOIO APIs

On Fri, May 25, 2018 at 10:16:24AM +0200, Michal Hocko wrote: > On Fri 25-05-18 08:17:15, Dave Chinner wrote: > > On Thu, May 24, 2018 at 01:43:41PM +0200, Michal Hocko wrote: > [...] > > > +FS/IO code then simply calls the appropriate save function right at the > > > +layer where a lock taken

Re: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

On 27 May 2018 at 10:37, Prakhya, Sai Praneeth wrote: >> > One more question again, if we are sure that non-blocking variants >> > will _always_ be called in atomic context, then, we got it covered. >> > Because, in >> > set_variable() and query_variable_info()

Re: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

On 27 May 2018 at 10:37, Prakhya, Sai Praneeth wrote: >> > One more question again, if we are sure that non-blocking variants >> > will _always_ be called in atomic context, then, we got it covered. >> > Because, in >> > set_variable() and query_variable_info() (both blocking and >> >

Re: [alsa-devel] [PATCH] ASoC: AMD: make channel 1 dma as circular

/ASoC-AMD-make-channel-1-dma-as-circular/20180527-170008 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: i386-randconfig-s0-201821 (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: # save the attached .config to linux

Re: [alsa-devel] [PATCH] ASoC: AMD: make channel 1 dma as circular

/ASoC-AMD-make-channel-1-dma-as-circular/20180527-170008 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: x86_64-randconfig-x014-201821 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build

Re: [alsa-devel] [PATCH] ASoC: AMD: make channel 1 dma as circular

/ASoC-AMD-make-channel-1-dma-as-circular/20180527-170008 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: i386-randconfig-s0-201821 (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: # save the attached .config to linux

Re: [alsa-devel] [PATCH] ASoC: AMD: make channel 1 dma as circular

/ASoC-AMD-make-channel-1-dma-as-circular/20180527-170008 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next config: x86_64-randconfig-x014-201821 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build

[PATCH bpf 0/2] Use __aligned_u64 in UAPI fields

Hello. It was discovered during strace development that struct bpf_map_info and struct bpf_prog_info now have different layouts of i386/compat and x86_64. Since it's already broken and bpf syscall has no separate compat (as far as I can see), and the affecting change was introduced recently (in

[PATCH bpf 2/2] bpf: enforce usage of __aligned_u64 in the UAPI header

Use __aligned_u64 instead of __u64 everywhere in the UAPI header, similarly to v4.17-rc1~94^2~58^2 "RDMA: Change all uapi headers to use __aligned_u64 instead of __u64". This commit doesn't change structure layouts, but imposes additional alignment requirements on struct bpf_stack_build_id,

[PATCH bpf 1/2] bpf: fix alignment of netns_dev/netns_ino fields in bpf_{map,prog}_info

Recent introduction of netns_dev/netns_ino to bpf_map_info/bpf_prog info has broken compat, as offsets of these fields are different in 32-bit and 64-bit ABIs. One fix (other than implementing compat support in syscall in order to handle this discrepancy) is to use __aligned_u64 instead of __u64

[PATCH bpf 0/2] Use __aligned_u64 in UAPI fields

Hello. It was discovered during strace development that struct bpf_map_info and struct bpf_prog_info now have different layouts of i386/compat and x86_64. Since it's already broken and bpf syscall has no separate compat (as far as I can see), and the affecting change was introduced recently (in

[PATCH bpf 2/2] bpf: enforce usage of __aligned_u64 in the UAPI header

Use __aligned_u64 instead of __u64 everywhere in the UAPI header, similarly to v4.17-rc1~94^2~58^2 "RDMA: Change all uapi headers to use __aligned_u64 instead of __u64". This commit doesn't change structure layouts, but imposes additional alignment requirements on struct bpf_stack_build_id,

[PATCH bpf 1/2] bpf: fix alignment of netns_dev/netns_ino fields in bpf_{map,prog}_info

Recent introduction of netns_dev/netns_ino to bpf_map_info/bpf_prog info has broken compat, as offsets of these fields are different in 32-bit and 64-bit ABIs. One fix (other than implementing compat support in syscall in order to handle this discrepancy) is to use __aligned_u64 instead of __u64

[PATCH v5 0/3] IR decoding using BPF

The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most widely used IR protocols, but there are many protocols which are not supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes, many of which are not supported by rc-core. There is a "long tail" of

[PATCH v5 2/3] media: rc: introduce BPF_PROG_LIRC_MODE2

Add support for BPF_PROG_LIRC_MODE2. This type of BPF program can call rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report that the last key should be repeated. The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall; the target_fd must be the /dev/lircN

[PATCH v5 0/3] IR decoding using BPF

The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most widely used IR protocols, but there are many protocols which are not supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes, many of which are not supported by rc-core. There is a "long tail" of

[PATCH v5 2/3] media: rc: introduce BPF_PROG_LIRC_MODE2

Add support for BPF_PROG_LIRC_MODE2. This type of BPF program can call rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report that the last key should be repeated. The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall; the target_fd must be the /dev/lircN

[PATCH v5 3/3] bpf: add selftest for lirc_mode2 type program

This is simple test over rc-loopback. Acked-by: Yonghong Song Signed-off-by: Sean Young --- tools/bpf/bpftool/prog.c | 1 + tools/include/uapi/linux/bpf.h| 53 - tools/include/uapi/linux/lirc.h | 217

[PATCH v5 3/3] bpf: add selftest for lirc_mode2 type program

This is simple test over rc-loopback. Acked-by: Yonghong Song Signed-off-by: Sean Young --- tools/bpf/bpftool/prog.c | 1 + tools/include/uapi/linux/bpf.h| 53 - tools/include/uapi/linux/lirc.h | 217 ++

[PATCH v5 1/3] bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not found

This makes is it possible for bpf prog detach to return -ENOENT. Acked-by: Yonghong Song Signed-off-by: Sean Young --- kernel/bpf/core.c| 11 +-- kernel/trace/bpf_trace.c | 2 ++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git

[PATCH v5 1/3] bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not found

This makes is it possible for bpf prog detach to return -ENOENT. Acked-by: Yonghong Song Signed-off-by: Sean Young --- kernel/bpf/core.c| 11 +-- kernel/trace/bpf_trace.c | 2 ++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/core.c

Re: Why does d_splice_alias need to check IS_ROOT?

Al Viro 于2018年5月27日周日 上午1:12写道： > On Sun, May 27, 2018 at 12:33:40AM +0800, Lei Chen wrote: > > Hello list, > > > > I'm insteresting in how hard link and denry lookup work and their > > implementation. > > > > I know that this interface tries to connect an inode to a

Re: Why does d_splice_alias need to check IS_ROOT?

Al Viro 于2018年5月27日周日 上午1:12写道： > On Sun, May 27, 2018 at 12:33:40AM +0800, Lei Chen wrote: > > Hello list, > > > > I'm insteresting in how hard link and denry lookup work and their > > implementation. > > > > I know that this interface tries to connect an inode to a dentry, but > > why does it

Re: [PATCH] PM / runtime: Drop usage count for suppliers at device link removal

On Thu, May 24, 2018 at 10:33 AM, Ulf Hansson wrote: > In the case consumer device is runtime resumed, while the link to the > supplier is removed, the earlier call to pm_runtime_get_sync() made from > rpm_get_suppliers() does not get properly balanced with a corresponding

Re: [PATCH] PM / runtime: Drop usage count for suppliers at device link removal

On Thu, May 24, 2018 at 10:33 AM, Ulf Hansson wrote: > In the case consumer device is runtime resumed, while the link to the > supplier is removed, the earlier call to pm_runtime_get_sync() made from > rpm_get_suppliers() does not get properly balanced with a corresponding > call to

Re: [PATCH v3 1/2] sched/cpufreq: always consider blocked FAIR utilization

On Thu, May 24, 2018 at 4:10 PM, Patrick Bellasi wrote: > Since the refactoring introduced by: > >commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") > > we aggregate FAIR utilization only if this class has runnable tasks. > This was mainly due to

Re: [PATCH v3 1/2] sched/cpufreq: always consider blocked FAIR utilization

On Thu, May 24, 2018 at 4:10 PM, Patrick Bellasi wrote: > Since the refactoring introduced by: > >commit 8f111bc357aa ("cpufreq/schedutil: Rewrite CPUFREQ_RT support") > > we aggregate FAIR utilization only if this class has runnable tasks. > This was mainly due to avoid the risk to stay on

Re: [PATCH v7 0/3] acpi: apei: Drop panic() on fatal errors policy

On Fri, May 25, 2018 at 5:53 PM, Alexandru Gagniuc wrote: > FFS (firmware-first) handling through APEI seems to have developed a > policy to panic() on any fatal errors. This policy is completely > independent of the non-FFS case. It is also inconsistent with how the >

Re: [PATCH v7 0/3] acpi: apei: Drop panic() on fatal errors policy

On Fri, May 25, 2018 at 5:53 PM, Alexandru Gagniuc wrote: > FFS (firmware-first) handling through APEI seems to have developed a > policy to panic() on any fatal errors. This policy is completely > independent of the non-FFS case. It is also inconsistent with how the > native error handlers, a

Re: [PATCH] iio: adc: sun4i-gpadc: select REGMAP_IRQ

On Fri, 25 May 2018 17:34:23 +0200 Arnd Bergmann wrote: > We can't call regmap_irq_get_virq() unless the regmap-irq support > is enabled: > > drivers/iio/adc/sun4i-gpadc-iio.o: In function `sun4i_irq_init': > sun4i-gpadc-iio.c:(.text+0x59c): undefined reference to

Re: [PATCH] iio: adc: sun4i-gpadc: select REGMAP_IRQ

On Fri, 25 May 2018 17:34:23 +0200 Arnd Bergmann wrote: > We can't call regmap_irq_get_virq() unless the regmap-irq support > is enabled: > > drivers/iio/adc/sun4i-gpadc-iio.o: In function `sun4i_irq_init': > sun4i-gpadc-iio.c:(.text+0x59c): undefined reference to `regmap_irq_get_virq' > > I

[PATCH v6] Refactor part of the oom report in dump_header

The dump_header does not print the memcg's name when the system oom happened, so users cannot locate the certain container which contains the task that has been killed by the oom killer. I follow the advices of David Rientjes and Michal Hocko, and refactor part of the oom report in a backwards

[PATCH v6] Refactor part of the oom report in dump_header

The dump_header does not print the memcg's name when the system oom happened, so users cannot locate the certain container which contains the task that has been killed by the oom killer. I follow the advices of David Rientjes and Michal Hocko, and refactor part of the oom report in a backwards

Re: [PATCH 2/2] iio: 104-quad-8: Provide defines for magic numbers

On Thu, 24 May 2018 16:37:58 -0400 William Breathitt Gray wrote: > This patch adds several register and bit defines to help improve the > clarity of the code by cleaning up magic numbers throughout the driver > source code. > > Signed-off-by: William Breathitt Gray

Re: [PATCH 2/2] iio: 104-quad-8: Provide defines for magic numbers

On Thu, 24 May 2018 16:37:58 -0400 William Breathitt Gray wrote: > This patch adds several register and bit defines to help improve the > clarity of the code by cleaning up magic numbers throughout the driver > source code. > > Signed-off-by: William Breathitt Gray Hi William I'd prefer a

Re: [PATCH 1/2] iio: 104-quad-8: Fix off-by-one error in register selection

On Thu, 24 May 2018 16:37:46 -0400 William Breathitt Gray wrote: > The reset flags operation is selected by bit 2 in the "Reset and Load > Signals Decoders" register, not bit 1. > > Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES > 104-QUAD-8") >

Re: [PATCH 1/2] iio: 104-quad-8: Fix off-by-one error in register selection

On Thu, 24 May 2018 16:37:46 -0400 William Breathitt Gray wrote: > The reset flags operation is selected by bit 2 in the "Reset and Load > Signals Decoders" register, not bit 1. > > Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES > 104-QUAD-8") > Signed-off-by: William

Re: arch/powerpc/kernel/head_32.S:1106: Error: missing operand

Le 26/05/2018 à 20:27, Paul Menzel a écrit : Dear Christophe, Am 26.05.2018 um 18:02 schrieb christophe leroy: Le 26/05/2018 à 06:35, Paul Menzel a écrit : Building the configuration created with `make tinyconfig` on the Power 8 system IBM S822LC with Ubuntu 18.04 fails with the error

Re: arch/powerpc/kernel/head_32.S:1106: Error: missing operand

Le 26/05/2018 à 20:27, Paul Menzel a écrit : Dear Christophe, Am 26.05.2018 um 18:02 schrieb christophe leroy: Le 26/05/2018 à 06:35, Paul Menzel a écrit : Building the configuration created with `make tinyconfig` on the Power 8 system IBM S822LC with Ubuntu 18.04 fails with the error

Re: [PATCH v3 02/16] mtd: rawnand: denali: use helper function for ecc setup

2018-05-25 21:21 GMT+09:00 Abhishek Sahu : > Use the NAND core helper function nand_ecc_choose_conf to tune > the ECC parameters instead of the function locally defined. > > CC: Masahiro Yamada You can replace the CC with my Acked-by:

Re: [PATCH v3 02/16] mtd: rawnand: denali: use helper function for ecc setup

2018-05-25 21:21 GMT+09:00 Abhishek Sahu : > Use the NAND core helper function nand_ecc_choose_conf to tune > the ECC parameters instead of the function locally defined. > > CC: Masahiro Yamada You can replace the CC with my Acked-by: Masahiro Yamada > Acked-by: Miquel Raynal >

Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma

On 2018-05-25 16:51, Tudor Ambarus wrote: > We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th > slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND > (7th slave). Exactly how do I accomplish that? I can see how I can move the LCD between slave DDR port 2

Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma

On 2018-05-25 16:51, Tudor Ambarus wrote: > We think the best way is to keep LCD on DDR Ports 2 and 3 (8th and 9th > slaves), to have maximum bandwidth and to use DMA on DDR port 1 for NAND > (7th slave). Exactly how do I accomplish that? I can see how I can move the LCD between slave DDR port 2

Re: [PATCH v4 1/4] tpm: migrate tpm2_shutdown() to use struct tpm_buf

On Wed May 23 18, Jarkko Sakkinen wrote: On Fri, May 18, 2018 at 03:30:32PM -0700, Jerry Snitselaar wrote: On Mon Mar 26 18, Jarkko Sakkinen wrote: > In order to make struct tpm_buf the first class object for constructing TPM > commands, migrate tpm2_shutdown() to use it. In addition, removed

Re: [PATCH v4 1/4] tpm: migrate tpm2_shutdown() to use struct tpm_buf

On Wed May 23 18, Jarkko Sakkinen wrote: On Fri, May 18, 2018 at 03:30:32PM -0700, Jerry Snitselaar wrote: On Mon Mar 26 18, Jarkko Sakkinen wrote: > In order to make struct tpm_buf the first class object for constructing TPM > commands, migrate tpm2_shutdown() to use it. In addition, removed

[GIT PULL] Kbuild fixes for v4.17-rc7

Hi Linus, Please pull a little more Kbuild fixes for v4.17 Thanks. The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb: Linux 4.17-rc4 (2018-05-06 16:57:38 -1000) are available in the git repository at:

[GIT PULL] Kbuild fixes for v4.17-rc7

Hi Linus, Please pull a little more Kbuild fixes for v4.17 Thanks. The following changes since commit 75bc37fefc4471e718ba8e651aa74673d4e0a9eb: Linux 4.17-rc4 (2018-05-06 16:57:38 -1000) are available in the git repository at:

RE: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

> > One more question again, if we are sure that non-blocking variants > > will _always_ be called in atomic context, then, we got it covered. > > Because, in > > set_variable() and query_variable_info() (both blocking and > > non-blocking) we check for in_atomic() and if so, we don't use

RE: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

> > One more question again, if we are sure that non-blocking variants > > will _always_ be called in atomic context, then, we got it covered. > > Because, in > > set_variable() and query_variable_info() (both blocking and > > non-blocking) we check for in_atomic() and if so, we don't use

Re: [PATCH 7/9] clk: bd71837: Build ROHM BD71837 PMIC clock driver

Hi Matti, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on ljones-mfd/for-mfd-next] [also build test WARNING on v4.17-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] clk: bd71837: fix platform_no_drv_owner.cocci warnings

From: kbuild test robot drivers/clk/clk-bd71837.c:145:6-11: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Fixes: 0e03c7b6a3c7 ("clk:

Re: [PATCH 7/9] clk: bd71837: Build ROHM BD71837 PMIC clock driver

Hi Matti, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on ljones-mfd/for-mfd-next] [also build test WARNING on v4.17-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] clk: bd71837: fix platform_no_drv_owner.cocci warnings

From: kbuild test robot drivers/clk/clk-bd71837.c:145:6-11: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Fixes: 0e03c7b6a3c7 ("clk: bd71837: Build ROHM

Re: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

On 27 May 2018 at 07:32, Prakhya, Sai Praneeth wrote: >> > Assume some user requested to execute some non-blocking variant of >> > efi_rts and the kernel hasn't called efi_call_virt() yet, but was >> > scheduled out. IOW, even though user requests for non-blocking

Re: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

On 27 May 2018 at 07:32, Prakhya, Sai Praneeth wrote: >> > Assume some user requested to execute some non-blocking variant of >> > efi_rts and the kernel hasn't called efi_call_virt() yet, but was >> > scheduled out. IOW, even though user requests for non-blocking efi call, we >> might still

Re: [RESEND PATCH V5 00/33] block: support multipage bvec

On Fri, May 25, 2018 at 10:30:46AM -0600, Jens Axboe wrote: > On 5/24/18 10:53 PM, Kent Overstreet wrote: > > On Fri, May 25, 2018 at 11:45:48AM +0800, Ming Lei wrote: > >> Hi, > >> > >> This patchset brings multipage bvec into block layer: > > > > patch series looks sane to me. goddamn that's a

Re: [RESEND PATCH V5 00/33] block: support multipage bvec

On Fri, May 25, 2018 at 10:30:46AM -0600, Jens Axboe wrote: > On 5/24/18 10:53 PM, Kent Overstreet wrote: > > On Fri, May 25, 2018 at 11:45:48AM +0800, Ming Lei wrote: > >> Hi, > >> > >> This patchset brings multipage bvec into block layer: > > > > patch series looks sane to me. goddamn that's a

Re: [PATCH 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device

On Sun, May 27, 2018 at 07:48:47AM +0200, Marcus Folkesson wrote: > On Sat, May 26, 2018 at 10:56:52PM +0200, Greg Kroah-Hartman wrote: > > On Sat, May 26, 2018 at 10:33:59PM +0200, Marcus Folkesson wrote: > > > Signed-off-by: Marcus Folkesson > > > > I can't take

Re: [PATCH 1/3] usb: gadget: ccid: add support for USB CCID Gadget Device

On Sun, May 27, 2018 at 07:48:47AM +0200, Marcus Folkesson wrote: > On Sat, May 26, 2018 at 10:56:52PM +0200, Greg Kroah-Hartman wrote: > > On Sat, May 26, 2018 at 10:33:59PM +0200, Marcus Folkesson wrote: > > > Signed-off-by: Marcus Folkesson > > > > I can't take patches without any changelog

Re: [PATCH] cpufreq: reinitialize new policy min/max when writing scaling_(max|min)_freq

-Wangtao/cpufreq-reinitialize-new-policy-min-max-when-writing-scaling_-max-min-_freq/20180527-132510 base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next config: i386-randconfig-x079-201821 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce

Re: [PATCH] cpufreq: reinitialize new policy min/max when writing scaling_(max|min)_freq

-Wangtao/cpufreq-reinitialize-new-policy-min-max-when-writing-scaling_-max-min-_freq/20180527-132510 base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next config: i386-randconfig-x079-201821 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce

<    1   2   3   4