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 +++
>
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
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
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
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
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
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
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
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
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
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
>>
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
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
>>
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:
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.
>
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.
>
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
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
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
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
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
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.
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,
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
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
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
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
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
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
* 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
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
* 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
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
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
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
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:
>
* 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
* 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.
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
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
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)
^
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)
^
[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
[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
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
---
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
---
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
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
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
---
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
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
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
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
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
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
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
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,
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,
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
> > -*
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
> > -*
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
>
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
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
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
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
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]).
>
>
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
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
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 =
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 =
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
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
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
> ---
>
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
>
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,
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
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
> +
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
> 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
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
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
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]
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 - 100 of 1862 matches
Mail list logo