Re: [PATCH 05/11] [media] s5p-mfc: Add support for HEVC decoder

On 18.01.2017 11:02, Smitha T Murthy wrote: > Add support for codec definition and corresponding buffer > requirements for HEVC decoder. > > Signed-off-by: Smitha T Murthy > --- > drivers/media/platform/s5p-mfc/regs-mfc-v10.h |3 +++ >

Re: [PATCH 05/11] [media] s5p-mfc: Add support for HEVC decoder

On 18.01.2017 11:02, Smitha T Murthy wrote: > Add support for codec definition and corresponding buffer > requirements for HEVC decoder. > > Signed-off-by: Smitha T Murthy > --- > drivers/media/platform/s5p-mfc/regs-mfc-v10.h |3 +++ > drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3

Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()

On Feb 1, 2017, at 09:52, Arnd Bergmann wrote: > > lustre uses a fake switch() statement as a compile-time assert, but > unfortunately > each use of that causes a warning when building with clang: > > drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2907:2: warning: no case

Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()

On Feb 1, 2017, at 09:52, Arnd Bergmann wrote: > > lustre uses a fake switch() statement as a compile-time assert, but > unfortunately > each use of that causes a warning when building with clang: > > drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2907:2: warning: no case > matching

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

Hi Finn, Am 01.02.2017 um 21:40 schrieb Finn Thain: > > On Fri, 27 Jan 2017, Michael Schmitz wrote: > >> Am 26.01.2017 um 21:47 schrieb Finn Thain: >> >>> This would imply CPU overhead that is half of that which mac_scsi >>> incurs. That's the best case, but I see no reason to expect worse

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

Hi Finn, Am 01.02.2017 um 21:40 schrieb Finn Thain: > > On Fri, 27 Jan 2017, Michael Schmitz wrote: > >> Am 26.01.2017 um 21:47 schrieb Finn Thain: >> >>> This would imply CPU overhead that is half of that which mac_scsi >>> incurs. That's the best case, but I see no reason to expect worse

Re: [PATCH 09/33] Input: sun4i-lradc-keys - Drop unnecessary call to platform_set_drvdata and other changes

On Thu, Jan 19, 2017 at 1:46 AM, Guenter Roeck wrote: > There is no call to platform_get_drvdata() or dev_get_drvdata(). > Drop the unnecessary call to platform_set_drvdata(). > Other relevant changes: > Simplify error return > > This conversion was done automatically with

Re: [PATCH 09/33] Input: sun4i-lradc-keys - Drop unnecessary call to platform_set_drvdata and other changes

On Thu, Jan 19, 2017 at 1:46 AM, Guenter Roeck wrote: > There is no call to platform_get_drvdata() or dev_get_drvdata(). > Drop the unnecessary call to platform_set_drvdata(). > Other relevant changes: > Simplify error return > > This conversion was done automatically with coccinelle using the

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

On February 1, 2017 11:16:00 PM PST, Ingo Molnar wrote: > >* Nicolas Iooss wrote: > >> With %Ld, my compiler (gcc 6.3.1 on x86_64) complains: >> >> arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument >of >> type ‘long long int’, but

Re: [PATCH 12/33] Input: axp20x-pek - Use devm_add_action_or_reset and other changes

On Thu, Jan 19, 2017 at 1:46 AM, Guenter Roeck wrote: > Replace devm_add_action() followed by failure action with > devm_add_action_or_reset() > > This conversion was done automatically with coccinelle using the > following semantic patches. The semantic patches and the

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

On February 1, 2017 11:16:00 PM PST, Ingo Molnar wrote: > >* Nicolas Iooss wrote: > >> With %Ld, my compiler (gcc 6.3.1 on x86_64) complains: >> >> arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument >of >> type ‘long long int’, but argument 2 has type ‘Elf64_Off {aka long >>

Re: [PATCH 12/33] Input: axp20x-pek - Use devm_add_action_or_reset and other changes

On Thu, Jan 19, 2017 at 1:46 AM, Guenter Roeck wrote: > Replace devm_add_action() followed by failure action with > devm_add_action_or_reset() > > This conversion was done automatically with coccinelle using the > following semantic patches. The semantic patches and the scripts > used to generate

Re: crash in perf_event_read

On Tue, Jan 31, 2017 at 2:27 AM, Peter Zijlstra wrote: > On Mon, Jan 30, 2017 at 11:04:08PM -0800, Alexei Starovoitov wrote: >> Hi Peter, >> >> rarely I'm seeing the following crash: >> [40196.164255] BUG: unable to handle kernel paging request at >> a11a >>

Re: crash in perf_event_read

On Tue, Jan 31, 2017 at 2:27 AM, Peter Zijlstra wrote: > On Mon, Jan 30, 2017 at 11:04:08PM -0800, Alexei Starovoitov wrote: >> Hi Peter, >> >> rarely I'm seeing the following crash: >> [40196.164255] BUG: unable to handle kernel paging request at >> a11a >> [40196.179636] IP:

Re: [PATCH v2 00/10] serial: st-asc: Allow handling of RTS line

Hi Greg, Jiri, > When hardware flow-control is disabled, manual toggling of the UART's > reset line (RTS) using userland applications (e.g. stty) is not > possible, since the ASC IP does not provide this functionality in the > same was as some other IPs do. Thus, we have to do this manually. >

Re: [PATCH v2 00/10] serial: st-asc: Allow handling of RTS line

Hi Greg, Jiri, > When hardware flow-control is disabled, manual toggling of the UART's > reset line (RTS) using userland applications (e.g. stty) is not > possible, since the ASC IP does not provide this functionality in the > same was as some other IPs do. Thus, we have to do this manually. >

Re: [PATCH 5/5] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

Hi, On Fri, Jan 27, 2017 at 5:27 AM, Rask Ingemann Lambertsen wrote: > The Suncip CX-A99 board is found in at least four brands of media players. > It features an Allwinner A80 ARM SoC and is found in two models: > > 1) 2 GiB DDR3 DRAM and 16 GB eMMC > 2) 4 GiB DDR3 DRAM and

Re: [PATCH 5/5] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

Hi, On Fri, Jan 27, 2017 at 5:27 AM, Rask Ingemann Lambertsen wrote: > The Suncip CX-A99 board is found in at least four brands of media players. > It features an Allwinner A80 ARM SoC and is found in two models: > > 1) 2 GiB DDR3 DRAM and 16 GB eMMC > 2) 4 GiB DDR3 DRAM and 32 GB eMMC > > For

Re: [PATCH v5 1/4] mm/migration: make isolate_movable_page() return int type

On Wed, Feb 01, 2017 at 11:00:23AM +0100, Michal Hocko wrote: > On Wed 01-02-17 18:46:36, Minchan Kim wrote: > > On Wed, Feb 01, 2017 at 08:59:24AM +0100, Michal Hocko wrote: > > > On Wed 01-02-17 15:48:21, Minchan Kim wrote: > > > > Hi Yisheng, > > > > > > > > On Tue, Jan 31, 2017 at 09:06:18PM

Re: [PATCH v5 1/4] mm/migration: make isolate_movable_page() return int type

On Wed, Feb 01, 2017 at 11:00:23AM +0100, Michal Hocko wrote: > On Wed 01-02-17 18:46:36, Minchan Kim wrote: > > On Wed, Feb 01, 2017 at 08:59:24AM +0100, Michal Hocko wrote: > > > On Wed 01-02-17 15:48:21, Minchan Kim wrote: > > > > Hi Yisheng, > > > > > > > > On Tue, Jan 31, 2017 at 09:06:18PM

Re: [PATCH 4/5] regulator: axp20x: Add support for the AXP808 PMIC

On Fri, Jan 27, 2017 at 7:42 PM, Mark Brown wrote: > On Thu, Jan 26, 2017 at 10:18:11PM +0100, Rask Ingemann Lambertsen wrote: >> The regulators are the same as on the AXP806. > > Acked-by: Mark Brown Acked-by: Chen-Yu Tsai This probably

Re: [PATCH 4/5] regulator: axp20x: Add support for the AXP808 PMIC

On Fri, Jan 27, 2017 at 7:42 PM, Mark Brown wrote: > On Thu, Jan 26, 2017 at 10:18:11PM +0100, Rask Ingemann Lambertsen wrote: >> The regulators are the same as on the AXP806. > > Acked-by: Mark Brown Acked-by: Chen-Yu Tsai This probably needs to go in with the mfd patches adding the ID.

Re: [PATCH 3/5] mfd: axp20x: Add support for the AXP808 PMIC

On Fri, Jan 27, 2017 at 5:25 AM, Rask Ingemann Lambertsen wrote: > The X-Powers AXP808 is a PMIC which, like the very similar AXP806, is > used on boards featuring Allwinner's A80 SoC. Unlike the AXP806, it > doesn't support address space extension and its associated registers,

Re: [PATCH 3/5] mfd: axp20x: Add support for the AXP808 PMIC

On Fri, Jan 27, 2017 at 5:25 AM, Rask Ingemann Lambertsen wrote: > The X-Powers AXP808 is a PMIC which, like the very similar AXP806, is > used on boards featuring Allwinner's A80 SoC. Unlike the AXP806, it > doesn't support address space extension and its associated registers, > but the two are

linux-next: Tree for Feb 2

Hi all, Changes since 20170201: Dropped tree: vfs-miklos (build failure and out of date) The vfs-miklos tree still had its build failure, so I just dropped it again for today. The v4l-dvb tree still had its build failure so I used the version from next-20170130. The net-next tree gained

linux-next: Tree for Feb 2

Hi all, Changes since 20170201: Dropped tree: vfs-miklos (build failure and out of date) The vfs-miklos tree still had its build failure, so I just dropped it again for today. The v4l-dvb tree still had its build failure so I used the version from next-20170130. The net-next tree gained

Re: [PATCH 2/5] DT: mfd: axp20x: Add binding for the AXP808

On Wed, Feb 1, 2017 at 9:27 PM, Rob Herring wrote: > On Thu, Jan 26, 2017 at 10:16:13PM +0100, Rask Ingemann Lambertsen wrote: >> The AXP808 does not support address space extension, but is otherwise >> identical to the AXP806, including the chip ID, so add a compatible >> string

Re: [PATCH 2/5] DT: mfd: axp20x: Add binding for the AXP808

On Wed, Feb 1, 2017 at 9:27 PM, Rob Herring wrote: > On Thu, Jan 26, 2017 at 10:16:13PM +0100, Rask Ingemann Lambertsen wrote: >> The AXP808 does not support address space extension, but is otherwise >> identical to the AXP806, including the chip ID, so add a compatible >> string for it to the

Re: [PATCH 03/11] [media] s5p-mfc: Use min scratch buffer size

On 18.01.2017 11:02, Smitha T Murthy wrote: > After MFC v8.0, mfc f/w lets the driver know how much scratch buffer > size is required for decoder. If mfc f/w has the functionality, > E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size > is required for encoder too. Subject

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

* Nicolas Iooss wrote: > With %Ld, my compiler (gcc 6.3.1 on x86_64) complains: > > arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument of > type ‘long long int’, but argument 2 has type ‘Elf64_Off {aka long > unsigned int}’ [-Werror=format=] How

Re: [PATCH 03/11] [media] s5p-mfc: Use min scratch buffer size

On 18.01.2017 11:02, Smitha T Murthy wrote: > After MFC v8.0, mfc f/w lets the driver know how much scratch buffer > size is required for decoder. If mfc f/w has the functionality, > E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size > is required for encoder too. Subject

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

* Nicolas Iooss wrote: > With %Ld, my compiler (gcc 6.3.1 on x86_64) complains: > > arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument of > type ‘long long int’, but argument 2 has type ‘Elf64_Off {aka long > unsigned int}’ [-Werror=format=] How did it pick up that type as an

[tip:x86/mm] x86/mpx: Re-add MPX to selftests Makefile

Commit-ID: e64d5fbe56259c94df504af8ce804cfc6a022adb Gitweb: http://git.kernel.org/tip/e64d5fbe56259c94df504af8ce804cfc6a022adb Author: Dave Hansen AuthorDate: Wed, 1 Feb 2017 14:56:29 -0800 Committer: Ingo Molnar CommitDate: Thu, 2 Feb

[tip:x86/mm] x86/mpx: Re-add MPX to selftests Makefile

Commit-ID: e64d5fbe56259c94df504af8ce804cfc6a022adb Gitweb: http://git.kernel.org/tip/e64d5fbe56259c94df504af8ce804cfc6a022adb Author: Dave Hansen AuthorDate: Wed, 1 Feb 2017 14:56:29 -0800 Committer: Ingo Molnar CommitDate: Thu, 2 Feb 2017 08:09:18 +0100 x86/mpx: Re-add MPX to

Re: [PATCH v2] ARM: dts: i.MX25: add AIPS control registers

Hi Martin, On Wed, Feb 01, 2017 at 11:16:18PM +0100, Martin Kaiser wrote: > The i.MX25 contains two AHB to IP bridges (AIPS), each of which has a set of > control registers. Add the memory regions for the control registers to > the Device Tree. > > Signed-off-by: Martin Kaiser

Re: [PATCH v2] ARM: dts: i.MX25: add AIPS control registers

Hi Martin, On Wed, Feb 01, 2017 at 11:16:18PM +0100, Martin Kaiser wrote: > The i.MX25 contains two AHB to IP bridges (AIPS), each of which has a set of > control registers. Add the memory regions for the control registers to > the Device Tree. > > Signed-off-by: Martin Kaiser > --- > v2: >

Re: [PATCH] x86, mpx: re-add MPX to selftests Makefile

* Dave Hansen wrote: > > From: Dave Hansen > > Ingo pointed out that the MPX tests were no longer in the selftests > Makefile. It appears that I shot myself in the foot on this one > and accidentally removed them when I added the

Re: [PATCH] x86, mpx: re-add MPX to selftests Makefile

* Dave Hansen wrote: > > From: Dave Hansen > > Ingo pointed out that the MPX tests were no longer in the selftests > Makefile. It appears that I shot myself in the foot on this one > and accidentally removed them when I added the pkeys tests, probably > from bungling a merge conflict.

Re: [PATCH] pinctrl: samsung: mark PM functions as __maybe_unused

Hi Arnd, On 2017-02-01 17:16, Arnd Bergmann wrote: The rework of the suspend/resume handling uses the wrong #ifdef check, leading to a build warning without CONFIG_PM_SLEEP: drivers/pinctrl/samsung/pinctrl-samsung.c:1142:12: error: 'samsung_pinctrl_resume' defined but not used

Re: [PATCH] pinctrl: samsung: mark PM functions as __maybe_unused

Hi Arnd, On 2017-02-01 17:16, Arnd Bergmann wrote: The rework of the suspend/resume handling uses the wrong #ifdef check, leading to a build warning without CONFIG_PM_SLEEP: drivers/pinctrl/samsung/pinctrl-samsung.c:1142:12: error: 'samsung_pinctrl_resume' defined but not used

linux-next: build warning after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig and x86_64 allmodconfig) produced this warning: fs/ext4/file.c:279:1: warning: 'ext4_dax_huge_fault' defined but not used [-Wunused-function] ext4_dax_huge_fault(struct vm_fault *vmf) ^

linux-next: build warning after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig and x86_64 allmodconfig) produced this warning: fs/ext4/file.c:279:1: warning: 'ext4_dax_huge_fault' defined but not used [-Wunused-function] ext4_dax_huge_fault(struct vm_fault *vmf) ^

Re: [PATCH v2 3/4] phy: Add USB3 PHY support for Broadcom NSP SoC

[Resending with fixed/complete Cc-s] On Tue, 17 Jan 2017 11:14:29 -0500, Yendapally Reddy Dhananjaya Reddy wrote:> This patch adds support for Broadcom NSP USB3 PHY > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy

Re: [PATCH v2 3/4] phy: Add USB3 PHY support for Broadcom NSP SoC

[Resending with fixed/complete Cc-s] On Tue, 17 Jan 2017 11:14:29 -0500, Yendapally Reddy Dhananjaya Reddy wrote:> This patch adds support for Broadcom NSP USB3 PHY > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy Seriously?! I really dislike what you did there. NACK. You are aware

[PATCH 3/4] tools lib feature: Do not redefine compiler configuration

Feature detection redefines CC, CCX and PKG_CONFIG, making the output of feature detection inconsistent with the actual features available during compilation when the above variables are used. Fix it by using conditional assignment. Signed-off-by: David Carrillo-Cisneros ---

[PATCH 3/4] tools lib feature: Do not redefine compiler configuration

Feature detection redefines CC, CCX and PKG_CONFIG, making the output of feature detection inconsistent with the actual features available during compilation when the above variables are used. Fix it by using conditional assignment. Signed-off-by: David Carrillo-Cisneros ---

[PATCH 1/4] perf tools: pass PYTHON config to feature detection

Python's CC and link Makefile variables were not passed to feature detection, causing feature detection to use system's Python rather than PYTHON_CONFIG's one. This created a mismatch between the detected Python support and the one actually used by perf when PYTHON_CONFIG is specified. Fix it by

[PATCH 1/4] perf tools: pass PYTHON config to feature detection

Python's CC and link Makefile variables were not passed to feature detection, causing feature detection to use system's Python rather than PYTHON_CONFIG's one. This created a mismatch between the detected Python support and the one actually used by perf when PYTHON_CONFIG is specified. Fix it by

[PATCH 4/4] tools include: Fix include path for uapi/asm-generic/mman.h

commit f3539c12d819 ("tools include: Add uapi mman.h for each architecture") copied include/uapi/linux/mman.h into tools/include/uapi/linux/mman.h but did not update the include path for uapi/asm-generic/mman.h. Fix it. Signed-off-by: David Carrillo-Cisneros ---

[PATCH 4/4] tools include: Fix include path for uapi/asm-generic/mman.h

commit f3539c12d819 ("tools include: Add uapi mman.h for each architecture") copied include/uapi/linux/mman.h into tools/include/uapi/linux/mman.h but did not update the include path for uapi/asm-generic/mman.h. Fix it. Signed-off-by: David Carrillo-Cisneros --- tools/include/uapi/linux/mman.h

[PATCH 0/4] Fixes for perf build and feature detection

Fixes for minor problems with Makefiles and libs that I found while building perf. David Carrillo-Cisneros (4): perf tools: pass PYTHON config to feature detection tools lib traceevent: Robustify do_generate_dynamic_list_file tools lib feature: Do not redefine compiler configuration tools

[PATCH 2/4] tools lib traceevent: Robustify do_generate_dynamic_list_file

The dynamic-list-file used to export dynamic symbols introduced in commit e3d09ec8126f ("tools lib traceevent: Export dynamic symbols used by traceevent plugins") is generated without any sort of error checking. I experienced problems due to an old version of nm (v 0.158) that outputs in a

[PATCH 0/4] Fixes for perf build and feature detection

Fixes for minor problems with Makefiles and libs that I found while building perf. David Carrillo-Cisneros (4): perf tools: pass PYTHON config to feature detection tools lib traceevent: Robustify do_generate_dynamic_list_file tools lib feature: Do not redefine compiler configuration tools

[PATCH 2/4] tools lib traceevent: Robustify do_generate_dynamic_list_file

The dynamic-list-file used to export dynamic symbols introduced in commit e3d09ec8126f ("tools lib traceevent: Export dynamic symbols used by traceevent plugins") is generated without any sort of error checking. I experienced problems due to an old version of nm (v 0.158) that outputs in a

Re: [PATCH] drm/amdgpu: shut up #warning for compile testing

On 02/02/17 12:59 AM, Arnd Bergmann wrote: > My randconfig tests on linux-next showed a newly introduced warning: > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function > 'amdgpu_bo_create_restricted': > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:377:2: error: #warning Please > enable

Re: [PATCH] drm/amdgpu: shut up #warning for compile testing

On 02/02/17 12:59 AM, Arnd Bergmann wrote: > My randconfig tests on linux-next showed a newly introduced warning: > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function > 'amdgpu_bo_create_restricted': > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:377:2: error: #warning Please > enable

Re: [PATCH v2] staging: rtl8188eu: remove not necessary braces {} (checkpatch fix)

On 02/01/2017 08:11 PM, Joe Perches wrote: ...and clarifying the code for a human reader is much more important than making a file not have any checkpatch warnings. I agree. I respect the developers' own coding style and believe that some things (>80 characters long lines, name conventions,

Re: [PATCH v2] staging: rtl8188eu: remove not necessary braces {} (checkpatch fix)

On 02/01/2017 08:11 PM, Joe Perches wrote: ...and clarifying the code for a human reader is much more important than making a file not have any checkpatch warnings. I agree. I respect the developers' own coding style and believe that some things (>80 characters long lines, name conventions,

Re: [PATCHv7 4/8] printk: always use deferred printk when flush printk_safe lines

On (02/01/17 11:06), Steven Rostedt wrote: [..] > > static void printk_safe_flush_line(const char *text, int len) > > { > > /* > > -* The buffers are flushed in NMI only on panic. The messages must > > -* go only into the ring buffer at this stage. Consoles will get > > -*

Re: [PATCHv7 4/8] printk: always use deferred printk when flush printk_safe lines

On (02/01/17 11:06), Steven Rostedt wrote: [..] > > static void printk_safe_flush_line(const char *text, int len) > > { > > /* > > -* The buffers are flushed in NMI only on panic. The messages must > > -* go only into the ring buffer at this stage. Consoles will get > > -*

Re: [PATCH 3/6] async_tx: Handle DMA devices having support for fewer PQ coefficients

On Wed, Feb 1, 2017 at 8:47 PM, Anup Patel wrote: > The DMAENGINE framework assumes that if PQ offload is supported by a > DMA device then all 256 PQ coefficients are supported. This assumption > does not hold anymore because we now have BCM-SBA-RAID offload engine >

Re: [PATCH 3/6] async_tx: Handle DMA devices having support for fewer PQ coefficients

On Wed, Feb 1, 2017 at 8:47 PM, Anup Patel wrote: > The DMAENGINE framework assumes that if PQ offload is supported by a > DMA device then all 256 PQ coefficients are supported. This assumption > does not hold anymore because we now have BCM-SBA-RAID offload engine > which supports PQ offload

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

Hi, > Am 01.02.2017 um 23:28 schrieb Dmitry Torokhov : > > On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote: >> Hello Nikolaus, >> >> On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote: >>> Hi Dmitry, Javier, >>> Am 29.01.2017 um 19:25

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

Hi, > Am 01.02.2017 um 23:28 schrieb Dmitry Torokhov : > > On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote: >> Hello Nikolaus, >> >> On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote: >>> Hi Dmitry, Javier, >>> Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller

Re: [PATCH] gpio: aspeed: Remove dependence on GPIOF_* macros

On Thu, Feb 2, 2017 at 2:58 PM, Andrew Jeffery wrote: > 1736f75d35e47409ad776273133d0f558a4c8253 is a (v2) patch which had > unresolved review comments[1]. Address the comments by removing the use > of macros from the consumer header (this patch represents the diff > between v2

Re: [PATCH] gpio: aspeed: Remove dependence on GPIOF_* macros

On Thu, Feb 2, 2017 at 2:58 PM, Andrew Jeffery wrote: > 1736f75d35e47409ad776273133d0f558a4c8253 is a (v2) patch which had > unresolved review comments[1]. Address the comments by removing the use > of macros from the consumer header (this patch represents the diff > between v2 and v3[2]). > >

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

On 02/01/2017 04:56 AM, Paolo Valente wrote: >> +/* >> + * add rq to rbtree and fifo >> + */ >> +static void dd_insert_request(struct blk_mq_hw_ctx *hctx, struct request >> *rq, >> + bool at_head) >> +{ >> +struct request_queue *q = hctx->queue; >> +struct

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

On 02/01/2017 04:56 AM, Paolo Valente wrote: >> +/* >> + * add rq to rbtree and fifo >> + */ >> +static void dd_insert_request(struct blk_mq_hw_ctx *hctx, struct request >> *rq, >> + bool at_head) >> +{ >> +struct request_queue *q = hctx->queue; >> +struct

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

On 02/01/2017 04:11 AM, Paolo Valente wrote: >> +static bool dd_bio_merge(struct blk_mq_hw_ctx *hctx, struct bio *bio) >> +{ >> +struct request_queue *q = hctx->queue; >> +struct deadline_data *dd = q->elevator->elevator_data; >> +int ret; >> + >> +spin_lock(>lock); >> +ret =

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

On 02/01/2017 04:11 AM, Paolo Valente wrote: >> +static bool dd_bio_merge(struct blk_mq_hw_ctx *hctx, struct bio *bio) >> +{ >> +struct request_queue *q = hctx->queue; >> +struct deadline_data *dd = q->elevator->elevator_data; >> +int ret; >> + >> +spin_lock(>lock); >> +ret =

Re: [RFC 0/6]mm: add new LRU list for MADV_FREE pages

Hi Johannes, On Tue, Jan 31, 2017 at 04:38:10PM -0500, Johannes Weiner wrote: > On Tue, Jan 31, 2017 at 11:45:47AM -0800, Shaohua Li wrote: > > On Tue, Jan 31, 2017 at 01:59:49PM -0500, Johannes Weiner wrote: > > > Hi Shaohua, > > > > > > On Sun, Jan 29, 2017 at 09:51:17PM -0800, Shaohua Li

Re: [RFC 0/6]mm: add new LRU list for MADV_FREE pages

Hi Johannes, On Tue, Jan 31, 2017 at 04:38:10PM -0500, Johannes Weiner wrote: > On Tue, Jan 31, 2017 at 11:45:47AM -0800, Shaohua Li wrote: > > On Tue, Jan 31, 2017 at 01:59:49PM -0500, Johannes Weiner wrote: > > > Hi Shaohua, > > > > > > On Sun, Jan 29, 2017 at 09:51:17PM -0800, Shaohua Li

Re: [PATCH v5 1/3] dt: bindings: add documentation for zx2967 family thermal sensor

Hey Bao, On Wed, Jan 18, 2017 at 12:42:00PM +0800, Baoyou Xie wrote: > This patch adds dt-binding documentation for zx2967 family thermal sensor. > > Signed-off-by: Baoyou Xie > Acked-by: Rob Herring > Reviewed-by: Shawn Guo > --- >

Re: [PATCH v5 1/3] dt: bindings: add documentation for zx2967 family thermal sensor

Hey Bao, On Wed, Jan 18, 2017 at 12:42:00PM +0800, Baoyou Xie wrote: > This patch adds dt-binding documentation for zx2967 family thermal sensor. > > Signed-off-by: Baoyou Xie > Acked-by: Rob Herring > Reviewed-by: Shawn Guo > --- > .../devicetree/bindings/thermal/zx2967-thermal.txt | 109 >

Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures

On Wed, Feb 1, 2017 at 3:12 PM, James Bottomley wrote: > On Tue, 2017-01-31 at 16:26 -0800, Andrew Morton wrote: >> On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller >> wrote: >> >> > The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18,

Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures

On Wed, Feb 1, 2017 at 3:12 PM, James Bottomley wrote: > On Tue, 2017-01-31 at 16:26 -0800, Andrew Morton wrote: >> On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller >> wrote: >> >> > The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but >> > implemented for PowerPC only. This trivial

Re: [PATCH v5 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family

Hey Bao, On Wed, Jan 18, 2017 at 12:42:02PM +0800, Baoyou Xie wrote: > This patch adds thermal driver for ZTE's zx2967 family. > > Signed-off-by: Baoyou Xie > + > + /* > + * Calculate temperature > + * 922initial value of calibration cure > +

Re: [PATCH v5 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family

Hey Bao, On Wed, Jan 18, 2017 at 12:42:02PM +0800, Baoyou Xie wrote: > This patch adds thermal driver for ZTE's zx2967 family. > > Signed-off-by: Baoyou Xie > + > + /* > + * Calculate temperature > + * 922initial value of calibration cure > + * 1.951 slope

Re: [PATCH] printk: fix printk.devkmsg sysctl

Hello, sorry, catching up with the emails. there seems to be two independent patches. I'll just comment in one thread. On (01/31/17 14:55), Petr Mladek wrote: [..] > From 0ce6125caf314270cb48202390d8a0938fdf316e Mon Sep 17 00:00:00 2001 > From: Petr Mladek > Date: Tue, 31

Re: [PATCH] printk: fix printk.devkmsg sysctl

Hello, sorry, catching up with the emails. there seems to be two independent patches. I'll just comment in one thread. On (01/31/17 14:55), Petr Mladek wrote: [..] > From 0ce6125caf314270cb48202390d8a0938fdf316e Mon Sep 17 00:00:00 2001 > From: Petr Mladek > Date: Tue, 31 Jan 2017 12:00:13

[PATCH 4/6] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output of Tx descriptor is to be used by next/dependent Tx descriptor. The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome() when calling dma->device_prep_dma_pq() under following conditions: 1. ASYNC_TX_FENCE not

[PATCH 6/6] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

This patch adds the DT bindings document for newly added Broadcom SBA RAID driver. Signed-off-by: Anup Patel Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29

[PATCH 6/6] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

This patch adds the DT bindings document for newly added Broadcom SBA RAID driver. Signed-off-by: Anup Patel Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 ++ 1 file changed, 29 insertions(+) create mode 100644

[PATCH 4/6] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output of Tx descriptor is to be used by next/dependent Tx descriptor. The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome() when calling dma->device_prep_dma_pq() under following conditions: 1. ASYNC_TX_FENCE not

[PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver

The Broadcom stream buffer accelerator (SBA) provides offloading capabilities for RAID operations. This SBA offload engine is accessible via Broadcom SoC specific ring manager. This patch adds Broadcom SBA RAID driver which provides one DMA device with RAID capabilities using one or more Broadcom

[PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver

The Broadcom stream buffer accelerator (SBA) provides offloading capabilities for RAID operations. This SBA offload engine is accessible via Broadcom SoC specific ring manager. This patch adds Broadcom SBA RAID driver which provides one DMA device with RAID capabilities using one or more Broadcom

[PATCH 0/6] Broadcom SBA RAID support

The Broadcom SBA RAID is a stream-based device which provides RAID5/6 offload. It requires a SoC specific ring manager (such as Broadcom FlexRM ring manager) to provide ring-based programming interface. Due to this, the Broadcom SBA RAID driver (mailbox client) implements DMA device having one

[PATCH 0/6] Broadcom SBA RAID support

The Broadcom SBA RAID is a stream-based device which provides RAID5/6 offload. It requires a SoC specific ring manager (such as Broadcom FlexRM ring manager) to provide ring-based programming interface. Due to this, the Broadcom SBA RAID driver (mailbox client) implements DMA device having one

[PATCH 3/6] async_tx: Handle DMA devices having support for fewer PQ coefficients

The DMAENGINE framework assumes that if PQ offload is supported by a DMA device then all 256 PQ coefficients are supported. This assumption does not hold anymore because we now have BCM-SBA-RAID offload engine which supports PQ offload with limited number of PQ coefficients. This patch extends

[PATCH 2/6] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The Linux async_tx framework pass values from raid6_gfexp as coefficients for each source to prep_dma_pq() callback of DMA channel with PQ capability. This creates problem for RAID6 offload engines (such as Broadcom SBA) which take

[PATCH 3/6] async_tx: Handle DMA devices having support for fewer PQ coefficients

The DMAENGINE framework assumes that if PQ offload is supported by a DMA device then all 256 PQ coefficients are supported. This assumption does not hold anymore because we now have BCM-SBA-RAID offload engine which supports PQ offload with limited number of PQ coefficients. This patch extends

[PATCH 2/6] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The Linux async_tx framework pass values from raid6_gfexp as coefficients for each source to prep_dma_pq() callback of DMA channel with PQ capability. This creates problem for RAID6 offload engines (such as Broadcom SBA) which take

[PATCH 1/6] mailbox: Add new API mbox_channel_device() for clients

The remote processor can have DMAENGINE capabilities and client can pass data to be processed via main memory. In such cases, the client will require DMAble memory for remote processor. This patch adds new API mbox_channel_device() which can be used by clients to get struct device pointer of

[PATCH 1/6] mailbox: Add new API mbox_channel_device() for clients

The remote processor can have DMAENGINE capabilities and client can pass data to be processed via main memory. In such cases, the client will require DMAble memory for remote processor. This patch adds new API mbox_channel_device() which can be used by clients to get struct device pointer of

Re: ibmvtpm byteswapping inconsistency

> On Jan 26, 2017, at 5:58 PM, Ashley Lai wrote: > > Adding Vicky from IBM. > > > On 01/26/2017 04:05 PM, Jason Gunthorpe wrote: >> On Thu, Jan 26, 2017 at 09:22:48PM +0100, Michal Such??nek wrote: >> >>> This is repeated a few times in the driver so I added memset to

Re: ibmvtpm byteswapping inconsistency

> On Jan 26, 2017, at 5:58 PM, Ashley Lai wrote: > > Adding Vicky from IBM. > > > On 01/26/2017 04:05 PM, Jason Gunthorpe wrote: >> On Thu, Jan 26, 2017 at 09:22:48PM +0100, Michal Such??nek wrote: >> >>> This is repeated a few times in the driver so I added memset to quiet >>> gcc and make

[GIT PULL] Thermal-SoC management updates for v4.10-rc7

Hello Rui, Please consider the following four small fixes on TI and MTK thermal drivers. BR, Eduardo The following changes since commit a4685d2f58e2230d4e27fb2ee581d7ea35e5d046: Merge branch 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2017-01-23 13:51:59

[GIT PULL] Thermal-SoC management updates for v4.10-rc7

Hello Rui, Please consider the following four small fixes on TI and MTK thermal drivers. BR, Eduardo The following changes since commit a4685d2f58e2230d4e27fb2ee581d7ea35e5d046: Merge branch 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2017-01-23 13:51:59

[PATCH] gpio: aspeed: Remove dependence on GPIOF_* macros

1736f75d35e47409ad776273133d0f558a4c8253 is a (v2) patch which had unresolved review comments[1]. Address the comments by removing the use of macros from the consumer header (this patch represents the diff between v2 and v3[2]). [1] https://lkml.org/lkml/2017/1/26/337 [2]

[PATCH] gpio: aspeed: Remove dependence on GPIOF_* macros

1736f75d35e47409ad776273133d0f558a4c8253 is a (v2) patch which had unresolved review comments[1]. Address the comments by removing the use of macros from the consumer header (this patch represents the diff between v2 and v3[2]). [1] https://lkml.org/lkml/2017/1/26/337 [2]

  1   2   3   4   5   6   7   8   9   10   >