Re: [PATCH] advansys: fix build warning for PCI=n

On 10/24/2016 05:51 PM, Arnd Bergmann wrote: > The advansys probe function tries to handle both ISA and PCI cases, > each hidden in an #ifdef when unused. This leads to a warning > indicating that when PCI is disabled we could be using uninitialized > data: > > drivers/scsi/advansys.c: In

Re: [PATCH] advansys: fix build warning for PCI=n

On 10/24/2016 05:51 PM, Arnd Bergmann wrote: > The advansys probe function tries to handle both ISA and PCI cases, > each hidden in an #ifdef when unused. This leads to a warning > indicating that when PCI is disabled we could be using uninitialized > data: > > drivers/scsi/advansys.c: In

Re: [PATCH 5/7] ASoC: constify snd_soc_ops structures

On Mon, 24 Oct 2016, Mark Brown wrote: > On Sat, Oct 15, 2016 at 04:55:49PM +0200, Julia Lawall wrote: > > > --- > > sound/soc/generic/simple-card.c |2 +- > > sound/soc/generic/simple-scu-card.c |2 +- > > sound/soc/intel/boards/bdw-rt5677.c |

Re: [PATCH 5/7] ASoC: constify snd_soc_ops structures

On Mon, 24 Oct 2016, Mark Brown wrote: > On Sat, Oct 15, 2016 at 04:55:49PM +0200, Julia Lawall wrote: > > > --- > > sound/soc/generic/simple-card.c |2 +- > > sound/soc/generic/simple-scu-card.c |2 +- > > sound/soc/intel/boards/bdw-rt5677.c |

Re: [PATCH 1/6] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation

On Sun, Oct 23, 2016 at 11:45:41PM +0200, Lukasz Majewski wrote: > The code has been rewritten to remove "generic" calls to > imx_pwm_{enable|disable|config}. > > Such approach would facilitate switch to atomic PWM (a.k.a ->apply()) > implementation. > > Suggested-by: Stefan Agner

Re: [PATCH 1/6] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation

On Sun, Oct 23, 2016 at 11:45:41PM +0200, Lukasz Majewski wrote: > The code has been rewritten to remove "generic" calls to > imx_pwm_{enable|disable|config}. > > Such approach would facilitate switch to atomic PWM (a.k.a ->apply()) > implementation. > > Suggested-by: Stefan Agner >

Re: [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz

On Tuesday 25 October 2016 02:28 AM, John Syne wrote: >> > On Oct 23, 2016, at 11:02 PM, Mugunthan V N wrote: >> > >> > Increase ADC reference clock from 3MHz to 24MHz so that the >> > sampling rates goes up from 100K samples per second to 800K >> > samples per second on

Re: [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz

On Tuesday 25 October 2016 02:28 AM, John Syne wrote: >> > On Oct 23, 2016, at 11:02 PM, Mugunthan V N wrote: >> > >> > Increase ADC reference clock from 3MHz to 24MHz so that the >> > sampling rates goes up from 100K samples per second to 800K >> > samples per second on AM335x and AM437x SoC.

Re: [PATCH 1/3] [media] au0828-video: Use kcalloc() in au0828_init_isoc()

On Mon, 24 Oct 2016, Mauro Carvalho Chehab wrote: > Em Mon, 24 Oct 2016 23:28:44 +0100 > Andrey Utkin escreveu: > > > On Mon, Oct 24, 2016 at 10:59:24PM +0200, SF Markus Elfring wrote: > > > From: Markus Elfring > > > Date: Mon, 24 Oct

Re: [PATCH 1/3] [media] au0828-video: Use kcalloc() in au0828_init_isoc()

On Mon, 24 Oct 2016, Mauro Carvalho Chehab wrote: > Em Mon, 24 Oct 2016 23:28:44 +0100 > Andrey Utkin escreveu: > > > On Mon, Oct 24, 2016 at 10:59:24PM +0200, SF Markus Elfring wrote: > > > From: Markus Elfring > > > Date: Mon, 24 Oct 2016 22:08:47 +0200 > > > > > > * Multiplications for the

[PATCH v2] drm/mediatek: fixed the calc method of data rate per lane

Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this signal will cause h-time larger than normal and reduce FPS. Need to multiply a coefficient to offset the extra signal's effect. coefficient =

[PATCH v2] drm/mediatek: fixed the calc method of data rate per lane

Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx, Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this signal will cause h-time larger than normal and reduce FPS. Need to multiply a coefficient to offset the extra signal's effect. coefficient =

Re: [PATCH v2] IB/mlx5: avoid bogus -Wmaybe-uninitialized warning

On Mon, Oct 24, 2016 at 10:48:21PM +0200, Arnd Bergmann wrote: > We get a false-positive warning in linux-next for the mlx5 driver: > > infiniband/hw/mlx5/mr.c: In function ‘mlx5_ib_reg_user_mr’: > infiniband/hw/mlx5/mr.c:1172:5: error: ‘order’ may be used uninitialized in > this function

Re: [PATCH v2] IB/mlx5: avoid bogus -Wmaybe-uninitialized warning

On Mon, Oct 24, 2016 at 10:48:21PM +0200, Arnd Bergmann wrote: > We get a false-positive warning in linux-next for the mlx5 driver: > > infiniband/hw/mlx5/mr.c: In function ‘mlx5_ib_reg_user_mr’: > infiniband/hw/mlx5/mr.c:1172:5: error: ‘order’ may be used uninitialized in > this function

Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness

On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote: > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote: > > Since SID's content is constant over reboot, > > That's not true, at least not across all the Allwinner SoCs, and > especially not on the A10 and A20 that this

Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness

On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote: > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote: > > Since SID's content is constant over reboot, > > That's not true, at least not across all the Allwinner SoCs, and > especially not on the A10 and A20 that this

RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Sent: Tuesday, October 25, 2016 4:30 AM > To: Punnaiah Choudary Kalluri > Cc: Boris Brezillon ; Punnaiah Choudary > Kalluri

RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Sent: Tuesday, October 25, 2016 4:30 AM > To: Punnaiah Choudary Kalluri > Cc: Boris Brezillon ; Punnaiah Choudary > Kalluri ; mark.rutl...@arm.com; linux- > m...@lists.infradead.org;

Re: [PATCH v7 0/6] x86/arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Tue, Oct 18, 2016 at 7:03 PM, Kyle Huey wrote: > rr (http://rr-project.org/), a userspace record-and-replay reverse- > execution debugger, would like to trap and emulate the CPUID instruction. > This would allow us to a) mask away certain hardware features that rr does > not

Re: [PATCH 4/7] mm: defer vmalloc from atomic context

On 10/22/2016 06:17 PM, Christoph Hellwig wrote: > We want to be able to use a sleeping lock for freeing vmap to keep > latency down. For this we need to use the deferred vfree mechanisms > no only from interrupt, but from any atomic context. > > Signed-off-by: Christoph Hellwig

Re: [PATCH v7 0/6] x86/arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

On Tue, Oct 18, 2016 at 7:03 PM, Kyle Huey wrote: > rr (http://rr-project.org/), a userspace record-and-replay reverse- > execution debugger, would like to trap and emulate the CPUID instruction. > This would allow us to a) mask away certain hardware features that rr does > not support (e.g.

Re: [PATCH 4/7] mm: defer vmalloc from atomic context

On 10/22/2016 06:17 PM, Christoph Hellwig wrote: > We want to be able to use a sleeping lock for freeing vmap to keep > latency down. For this we need to use the deferred vfree mechanisms > no only from interrupt, but from any atomic context. > > Signed-off-by: Christoph Hellwig > --- >

Re: [PATCH] shmem: avoid huge pages for small files

On Mon, Oct 24, 2016 at 01:34:53PM -0700, Dave Hansen wrote: > On 10/21/2016 03:50 PM, Dave Chinner wrote: > > On Fri, Oct 21, 2016 at 06:00:07PM +0300, Kirill A. Shutemov wrote: > >> On Fri, Oct 21, 2016 at 04:01:18PM +1100, Dave Chinner wrote: > >> To me, most of things you're talking about is

Re: [PATCH] shmem: avoid huge pages for small files

On Mon, Oct 24, 2016 at 01:34:53PM -0700, Dave Hansen wrote: > On 10/21/2016 03:50 PM, Dave Chinner wrote: > > On Fri, Oct 21, 2016 at 06:00:07PM +0300, Kirill A. Shutemov wrote: > >> On Fri, Oct 21, 2016 at 04:01:18PM +1100, Dave Chinner wrote: > >> To me, most of things you're talking about is

[PATCH V1]iio: adc: spmi-vadc: Changes to support different scaling

Add changes to support different scale functions to convert adc code to physical units. Signed-off-by: Rama Krishna Phani A --- drivers/iio/adc/qcom-spmi-vadc.c | 319 ++- 1 file changed, 249 insertions(+), 70 deletions(-) diff --git

[PATCH V1]iio: adc: spmi-vadc: Changes to support different scaling

Add changes to support different scale functions to convert adc code to physical units. Signed-off-by: Rama Krishna Phani A --- drivers/iio/adc/qcom-spmi-vadc.c | 319 ++- 1 file changed, 249 insertions(+), 70 deletions(-) diff --git

[PATCH 4/6] ACPICA: Events: Cleanup acpi_ev_initialize_region()

This patch changes acpi_ev_initialize_region(), stop returning AE_NOT_EXIST from it so that, not only in acpi_ds_load2_end_op(), but all places invoking this function won't emit exceptions. This patch also removes acpi_ns_locked from acpi_ev_initialize_region() as we have tuned table/namespace

[PATCH 6/6] ACPICA: Tables: Add acpi_tb_unload_table()

This patch introduces acpi_tb_unload_table() to eliminate redundant code from acpi_ex_unload_table() and acpi_unload_parent_table(). No functional change. Lv Zheng. Signed-off-by: Lv Zheng --- drivers/acpi/acpica/actables.h | 2 ++ drivers/acpi/acpica/exconfig.c | 35

[PATCH 5/6] ACPICA: Tables: Cleanup acpi_tb_install_and_load_table()

acpi_tb_install_and_load_table() can invoke acpi_tb_load_table() to eliminate redundant code. No functional change. Lv Zheng. Signed-off-by: Lv Zheng --- drivers/acpi/acpica/actables.h | 3 +-- drivers/acpi/acpica/exconfig.c | 7 +++ drivers/acpi/acpica/tbdata.c |

[PATCH 3/6] ACPICA: Dispatcher: Tune interpreter lock around acpi_ev_initialize_region()

In code path of acpi_ev_initialize_region(), there are namespace modification code unlocked. This patch tunes the code to make sure such modification are locked. Lv Zheng. Reported-by: Imre Deak Signed-off-by: Lv Zheng --- drivers/acpi/acpica/dsinit.c

[PATCH 4/6] ACPICA: Events: Cleanup acpi_ev_initialize_region()

This patch changes acpi_ev_initialize_region(), stop returning AE_NOT_EXIST from it so that, not only in acpi_ds_load2_end_op(), but all places invoking this function won't emit exceptions. This patch also removes acpi_ns_locked from acpi_ev_initialize_region() as we have tuned table/namespace

[PATCH 6/6] ACPICA: Tables: Add acpi_tb_unload_table()

This patch introduces acpi_tb_unload_table() to eliminate redundant code from acpi_ex_unload_table() and acpi_unload_parent_table(). No functional change. Lv Zheng. Signed-off-by: Lv Zheng --- drivers/acpi/acpica/actables.h | 2 ++ drivers/acpi/acpica/exconfig.c | 35

[PATCH 5/6] ACPICA: Tables: Cleanup acpi_tb_install_and_load_table()

acpi_tb_install_and_load_table() can invoke acpi_tb_load_table() to eliminate redundant code. No functional change. Lv Zheng. Signed-off-by: Lv Zheng --- drivers/acpi/acpica/actables.h | 3 +-- drivers/acpi/acpica/exconfig.c | 7 +++ drivers/acpi/acpica/tbdata.c | 45

[PATCH 3/6] ACPICA: Dispatcher: Tune interpreter lock around acpi_ev_initialize_region()

In code path of acpi_ev_initialize_region(), there are namespace modification code unlocked. This patch tunes the code to make sure such modification are locked. Lv Zheng. Reported-by: Imre Deak Signed-off-by: Lv Zheng --- drivers/acpi/acpica/dsinit.c | 11 +++

[PATCH 2/6] ACPICA: Dispatcher: Fix an unbalanced lock exit path in acpi_ds_auto_serialize_method()

There is a lock unbalanced exit path in acpi_ds_initialize_method(), this patch corrects it. Lv Zheng. Signed-off-by: Lv Zheng --- drivers/acpi/acpica/dsmethod.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsmethod.c

[PATCH 1/6] ACPICA: Dispatcher: Fix order issue of method termination

The last step of the method termination should be the end of the method serialization. Otherwise, the steps happening after it will face the race issues that cannot be protected by the method serialization mechanism. This patch fixes this issue by moving the per-method-object deletion code prior

[PATCH 0/6] ACPICA: Interpreter: Improve lock order fixes

This patchset improves ACPICA intepreter lock order fixes. Including several urgent regression fixes [PATCH 0-3]. Patches tested with customized ACPI table where _PS0/_PS3 methods are customized to invoke a serialized control method which creates named objects. When pm_async=yes,

[PATCH 2/6] ACPICA: Dispatcher: Fix an unbalanced lock exit path in acpi_ds_auto_serialize_method()

There is a lock unbalanced exit path in acpi_ds_initialize_method(), this patch corrects it. Lv Zheng. Signed-off-by: Lv Zheng --- drivers/acpi/acpica/dsmethod.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/dsmethod.c b/drivers/acpi/acpica/dsmethod.c

[PATCH 1/6] ACPICA: Dispatcher: Fix order issue of method termination

The last step of the method termination should be the end of the method serialization. Otherwise, the steps happening after it will face the race issues that cannot be protected by the method serialization mechanism. This patch fixes this issue by moving the per-method-object deletion code prior

[PATCH 0/6] ACPICA: Interpreter: Improve lock order fixes

This patchset improves ACPICA intepreter lock order fixes. Including several urgent regression fixes [PATCH 0-3]. Patches tested with customized ACPI table where _PS0/_PS3 methods are customized to invoke a serialized control method which creates named objects. When pm_async=yes,

[PATCH net-next] ibmveth: calculate correct gso_size and set gso_type

We recently encountered a bug where a few customers using ibmveth on the same LPAR hit an issue where a TCP session hung when large receive was enabled. Closer analysis revealed that the session was stuck because the one side was advertising a zero window repeatedly. We narrowed this down to

[PATCH net-next] ibmveth: calculate correct gso_size and set gso_type

We recently encountered a bug where a few customers using ibmveth on the same LPAR hit an issue where a TCP session hung when large receive was enabled. Closer analysis revealed that the session was stuck because the one side was advertising a zero window repeatedly. We narrowed this down to

[PATCH v3 2/2] fpga: Add support for Lattice iCE40 FPGAs

The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. This patch adds support to the FPGA manager for configuring the SRAM of iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite

[PATCH v3 2/2] fpga: Add support for Lattice iCE40 FPGAs

The Lattice iCE40 is a family of FPGAs with a minimalistic architecture and very regular structure, designed for low-cost, high-volume consumer and system applications. This patch adds support to the FPGA manager for configuring the SRAM of iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite

[PATCH v3 1/2] of: Add vendor prefix for Lattice Semiconductor

--- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1992aa9..d64a835 100644 ---

[PATCH v3 1/2] of: Add vendor prefix for Lattice Semiconductor

--- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1992aa9..d64a835 100644 ---

Re: [v2 2/2] fpga: Add support for Lattice iCE40 FPGAs

Hi Joel, Thanks for submitting your driver! I didn't see any huge problems, just minor things below... Alan Hi Alan, Thanks for your feedback. I've implemented all your suggestions and I'll resubmit. I had a question about the status of the fpga-manager framework. Is there active work

Re: [v2 2/2] fpga: Add support for Lattice iCE40 FPGAs

Hi Joel, Thanks for submitting your driver! I didn't see any huge problems, just minor things below... Alan Hi Alan, Thanks for your feedback. I've implemented all your suggestions and I'll resubmit. I had a question about the status of the fpga-manager framework. Is there active work

RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Sent: Tuesday, October 25, 2016 10:16 AM > To: Punnaiah Choudary Kalluri > Cc: Boris Brezillon ; > mark.rutl...@arm.com;

RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Sent: Tuesday, October 25, 2016 10:16 AM > To: Punnaiah Choudary Kalluri > Cc: Boris Brezillon ; > mark.rutl...@arm.com; linux-...@lists.infradead.org; > michal.si...@xilinx.com;

Re: [RFC 0/8] Define coherent device memory node

Jerome Glisse writes: > On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual wrote: > >> [...] > >> Core kernel memory features like reclamation, evictions etc. might >> need to be restricted or modified on the coherent device memory node as >> they can be

Re: [RFC 0/8] Define coherent device memory node

Jerome Glisse writes: > On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual wrote: > >> [...] > >> Core kernel memory features like reclamation, evictions etc. might >> need to be restricted or modified on the coherent device memory node as >> they can be performance limiting. The

[PATCH] gpio: mxc: Shift generic request/free after gpiochip registration

generic gpio request/free should be added after gpiocip registration to validate mapping of gpiochip with pinctrl subsystem. gpiochip->pin_ranges list contains the information used by pinctrl subsystem to configure corresponding pins for gpio usage. This list will be empty if gpiochip fails to

[PATCH] gpio: mxc: Shift generic request/free after gpiochip registration

generic gpio request/free should be added after gpiocip registration to validate mapping of gpiochip with pinctrl subsystem. gpiochip->pin_ranges list contains the information used by pinctrl subsystem to configure corresponding pins for gpio usage. This list will be empty if gpiochip fails to

Re: [v2 2/2] fpga: Add support for Lattice iCE40 FPGAs

On 10/24/2016 04:28 PM, Moritz Fischer wrote: Hi Joel, Ha, finally someone beat me to submitting my driver, I had an ugly hack to bitbang the SPI since I couldn't figure out a good way to assert the creset after the CS. Thanks! Hi Moritz - yeah I figured someone might have a driver in the

Re: [v2 2/2] fpga: Add support for Lattice iCE40 FPGAs

On 10/24/2016 04:28 PM, Moritz Fischer wrote: Hi Joel, Ha, finally someone beat me to submitting my driver, I had an ugly hack to bitbang the SPI since I couldn't figure out a good way to assert the creset after the CS. Thanks! Hi Moritz - yeah I figured someone might have a driver in the

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

On Tue, Oct 25, 2016 at 03:58:49AM +, Punnaiah Choudary Kalluri wrote: > > I have hacked the v7 patchset enough to work on 4.8 and hacked it some > > more to work on my hardware. The driver appears to be in no better > > shape than the 3.12 out-of-tree Xilinx release I was using previously..

Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface

On Tue, Oct 25, 2016 at 03:58:49AM +, Punnaiah Choudary Kalluri wrote: > > I have hacked the v7 patchset enough to work on 4.8 and hacked it some > > more to work on my hardware. The driver appears to be in no better > > shape than the 3.12 out-of-tree Xilinx release I was using previously..

Re: linux.git: printk() problem

On (10/24/16 21:15), Linus Torvalds wrote: [..] > No. Most cont lines never hit the delay, because when the line is > completed, it is flushed (and then printed synchronously, assuming it > can get the console lock). > > So the timeout only ever comes into effect if the line isn't completed > in

Re: linux.git: printk() problem

On (10/24/16 21:15), Linus Torvalds wrote: [..] > No. Most cont lines never hit the delay, because when the line is > completed, it is flushed (and then printed synchronously, assuming it > can get the console lock). > > So the timeout only ever comes into effect if the line isn't completed > in

[PATCH v1] I2C Designware Core Supports SMBUS BLOCK

From: Tin Huynh Free and Open IPMI use SMBUS BLOCK Read/Write to support SSIF protocol. However, I2C Designwave Core Driver doesn't handle the case at the moment. The below patch supports this feature. Signed-off-by: Tin Huynh ---

[PATCH v1] I2C Designware Core Supports SMBUS BLOCK

From: Tin Huynh Free and Open IPMI use SMBUS BLOCK Read/Write to support SSIF protocol. However, I2C Designwave Core Driver doesn't handle the case at the moment. The below patch supports this feature. Signed-off-by: Tin Huynh --- drivers/i2c/busses/i2c-designware-core.c| 42

Re: [RFC 0/8] Define coherent device memory node

Jerome Glisse writes: > On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual wrote: > >> [...] > >> Core kernel memory features like reclamation, evictions etc. might >> need to be restricted or modified on the coherent device memory node as >> they can be

Re: [RFC 0/8] Define coherent device memory node

Jerome Glisse writes: > On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual wrote: > >> [...] > >> Core kernel memory features like reclamation, evictions etc. might >> need to be restricted or modified on the coherent device memory node as >> they can be performance limiting. The

Re: linux.git: printk() problem

On Mon, Oct 24, 2016 at 9:06 PM, Sergey Senozhatsky wrote: > > 1) the way we dumpstack on x86 (at least on x86) is a spaghetti of > printk() and pr_cont() calls. for instance, arch/x86/kernel/dumpstack_64.c > show_regs() does pr_cont() to print out the

Re: linux.git: printk() problem

On Mon, Oct 24, 2016 at 9:06 PM, Sergey Senozhatsky wrote: > > 1) the way we dumpstack on x86 (at least on x86) is a spaghetti of > printk() and pr_cont() calls. for instance, arch/x86/kernel/dumpstack_64.c > show_regs() does pr_cont() to print out the registers, while the stack and > backtrace

Re: [RFC 3/8] mm: Isolate coherent device memory nodes from HugeTLB allocation paths

Dave Hansen writes: > On 10/23/2016 09:31 PM, Anshuman Khandual wrote: >> This change is part of the isolation requiring coherent device memory nodes >> implementation. >> >> Isolation seeking coherent device memory node requires allocation isolation >> from implicit

Re: [RFC 3/8] mm: Isolate coherent device memory nodes from HugeTLB allocation paths

Dave Hansen writes: > On 10/23/2016 09:31 PM, Anshuman Khandual wrote: >> This change is part of the isolation requiring coherent device memory nodes >> implementation. >> >> Isolation seeking coherent device memory node requires allocation isolation >> from implicit memory allocations from

Re: linux.git: printk() problem

On Tue, 2016-10-25 at 13:06 +0900, Sergey Senozhatsky wrote: > so how about skipping mod_timer in deferred_cont_flush() and just > cont_flush() when we are in oops? here is probably one more thing we > need to "fix" first. oops_in_progress is unreliable. x86 oops_end() > does

Re: linux.git: printk() problem

On Tue, 2016-10-25 at 13:06 +0900, Sergey Senozhatsky wrote: > so how about skipping mod_timer in deferred_cont_flush() and just > cont_flush() when we are in oops? here is probably one more thing we > need to "fix" first. oops_in_progress is unreliable. x86 oops_end() > does

Re: [PATCH 5/8] ARM: gr8: Add missing pwm channel 1 pin

On Fri, Oct 21, 2016 at 1:07 AM, Maxime Ripard wrote: > On Thu, Oct 20, 2016 at 10:10:03PM +0800, Chen-Yu Tsai wrote: >> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard >> wrote: >> > The PWM controller has two different

Re: [PATCH 5/8] ARM: gr8: Add missing pwm channel 1 pin

On Fri, Oct 21, 2016 at 1:07 AM, Maxime Ripard wrote: > On Thu, Oct 20, 2016 at 10:10:03PM +0800, Chen-Yu Tsai wrote: >> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard >> wrote: >> > The PWM controller has two different channels, but only the first pin was >> > exposed in the DTSI. Add the other

Re: linux.git: printk() problem

On (10/24/16 19:22), Linus Torvalds wrote: > On Mon, Oct 24, 2016 at 7:06 PM, Linus Torvalds > wrote: > > On Mon, Oct 24, 2016 at 6:55 PM, Sergey Senozhatsky > > wrote: > >> > >> I think cont_flush() should grab the logbuf_lock

Re: linux.git: printk() problem

On (10/24/16 19:22), Linus Torvalds wrote: > On Mon, Oct 24, 2016 at 7:06 PM, Linus Torvalds > wrote: > > On Mon, Oct 24, 2016 at 6:55 PM, Sergey Senozhatsky > > wrote: > >> > >> I think cont_flush() should grab the logbuf_lock lock, because > >> it does log_store() and touches the cont.len. so

[PATCH] powerpc: Use pr_warn instead of pr_warning

At some point, pr_warning will be removed so all logging messages use a consistent _warn style. Update arch/powerpc/ Miscellanea: o Coalesce formats o Realign arguments o Use %s, __func__ instead of embedded function names o Remove unnecessary line continuations Signed-off-by: Joe Perches

[PATCH] powerpc: Use pr_warn instead of pr_warning

At some point, pr_warning will be removed so all logging messages use a consistent _warn style. Update arch/powerpc/ Miscellanea: o Coalesce formats o Realign arguments o Use %s, __func__ instead of embedded function names o Remove unnecessary line continuations Signed-off-by: Joe Perches ---

Re: [PATCH] ARM64: dts: bcm2835: Fix bcm2837 compatible string

e<#secure method=pgpmime mode=sign> Andreas Färber writes: > bcm2837-rpi-3-b.dts, its only in-tree user, was overriding it as > "brcm,bcm2837" already. Pulled to bcm2835-dt-64-next. Thanks!

Re: [PATCH] ARM64: dts: bcm2835: Fix bcm2837 compatible string

e<#secure method=pgpmime mode=sign> Andreas Färber writes: > bcm2837-rpi-3-b.dts, its only in-tree user, was overriding it as > "brcm,bcm2837" already. Pulled to bcm2835-dt-64-next. Thanks!

Re: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

On Sun, Oct 23, 2016 at 11:29:25AM +, Li, Liang Z wrote: > > On Fri, Oct 21, 2016 at 10:25:21AM -0700, Dave Hansen wrote: > > > On 10/20/2016 11:24 PM, Liang Li wrote: > > > > Dave Hansen suggested a new scheme to encode the data structure, > > > > because of additional complexity, it's not

Re: [RESEND PATCH v3 kernel 0/7] Extend virtio-balloon for fast (de)inflating & fast live migration

On Sun, Oct 23, 2016 at 11:29:25AM +, Li, Liang Z wrote: > > On Fri, Oct 21, 2016 at 10:25:21AM -0700, Dave Hansen wrote: > > > On 10/20/2016 11:24 PM, Liang Li wrote: > > > > Dave Hansen suggested a new scheme to encode the data structure, > > > > because of additional complexity, it's not

Re: [PATCH 0/6] pwm: imx: Provide atomic operation for IMX PWM driver

Hi Lukasz, Thanks for your work, great to see this coming along! :-) On 2016-10-24 23:26, Lukasz Majewski wrote: > Hi Boris, > >> On Sun, 23 Oct 2016 23:45:40 +0200 >> Lukasz Majewski wrote: >> >> > This patch set brings atomic operation to i.MX's PWMv2 driver. >> > >> >

Re: [PATCH 0/6] pwm: imx: Provide atomic operation for IMX PWM driver

Hi Lukasz, Thanks for your work, great to see this coming along! :-) On 2016-10-24 23:26, Lukasz Majewski wrote: > Hi Boris, > >> On Sun, 23 Oct 2016 23:45:40 +0200 >> Lukasz Majewski wrote: >> >> > This patch set brings atomic operation to i.MX's PWMv2 driver. >> > >> > This work has been

Re: [PATCH][TRIVIAL] crypto: ccp - fix typo "CPP"

Paul Bolle wrote: > The abbreviation for Cryptographic Coprocessor is "CCP". > > Signed-off-by: Paul Bolle Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: [PATCH V2 4/8] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage()

On 24-10-16, 16:14, Stephen Boyd wrote: > On 10/20, Viresh Kumar wrote: > > Pass the entire supply structure instead of all of its fields. > > > > Signed-off-by: Viresh Kumar > > --- > > This patch should be combined with the previous one. I think it is a fair to do

Re: [PATCH][TRIVIAL] crypto: ccp - fix typo "CPP"

Paul Bolle wrote: > The abbreviation for Cryptographic Coprocessor is "CCP". > > Signed-off-by: Paul Bolle Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH V2 4/8] PM / OPP: Pass struct dev_pm_opp_supply to _set_opp_voltage()

On 24-10-16, 16:14, Stephen Boyd wrote: > On 10/20, Viresh Kumar wrote: > > Pass the entire supply structure instead of all of its fields. > > > > Signed-off-by: Viresh Kumar > > --- > > This patch should be combined with the previous one. I think it is a fair to do this separately as this is

Re: [PATCH] hwrng: meson: Remove unneeded platform MODULE_ALIAS

On Wed, Oct 19, 2016 at 04:50:18PM -0300, Javier Martinez Canillas wrote: > The Amlogic Meson is a DT-only platform, which means the devices are > registered via OF and not using the legacy platform devices support. > > So there's no need to have a MODULE_ALIAS("platform:meson-rng") since > the

Re: [PATCH] hwrng: meson: Remove unneeded platform MODULE_ALIAS

On Wed, Oct 19, 2016 at 04:50:18PM -0300, Javier Martinez Canillas wrote: > The Amlogic Meson is a DT-only platform, which means the devices are > registered via OF and not using the legacy platform devices support. > > So there's no need to have a MODULE_ALIAS("platform:meson-rng") since > the

Re: [PATCH] crypto: engine - Handle the kthread worker using the new API

On Wed, Oct 19, 2016 at 01:54:30PM +0200, Petr Mladek wrote: > Use the new API to create and destroy the crypto engine kthread > worker. The API hides some implementation details. > > In particular, kthread_create_worker() allocates and initializes > struct kthread_worker. It runs the kthread the

Re: [PATCH] crypto: engine - Handle the kthread worker using the new API

On Wed, Oct 19, 2016 at 01:54:30PM +0200, Petr Mladek wrote: > Use the new API to create and destroy the crypto engine kthread > worker. The API hides some implementation details. > > In particular, kthread_create_worker() allocates and initializes > struct kthread_worker. It runs the kthread the

Re: [PATCH v2] hwrng: meson: Fix module autoload for OF registration

On Mon, Oct 17, 2016 at 04:51:17PM -0300, Javier Martinez Canillas wrote: > If the driver is built as a module, autoload won't work because the module > alias information is not filled. So user-space can't match the registered > device with the corresponding module. > > Export the module alias

Re: [PATCH v2] hwrng: meson: Fix module autoload for OF registration

On Mon, Oct 17, 2016 at 04:51:17PM -0300, Javier Martinez Canillas wrote: > If the driver is built as a module, autoload won't work because the module > alias information is not filled. So user-space can't match the registered > device with the corresponding module. > > Export the module alias

Re: [RESEND][PATCH] crypto: caam: add support for iMX6UL

On Mon, Oct 17, 2016 at 01:28:00PM +0200, Marcus Folkesson wrote: > i.MX6UL does only require three clocks to enable CAAM module. > > Signed-off-by: Marcus Folkesson > Acked-by: Rob Herring > Reviewed-by: Horia Geantă Patch

Re: [RESEND][PATCH] crypto: caam: add support for iMX6UL

On Mon, Oct 17, 2016 at 01:28:00PM +0200, Marcus Folkesson wrote: > i.MX6UL does only require three clocks to enable CAAM module. > > Signed-off-by: Marcus Folkesson > Acked-by: Rob Herring > Reviewed-by: Horia Geantă Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH] padata: Remove unused but set variables

Steffen Klassert wrote: > On Mon, Oct 17, 2016 at 12:16:08PM +0200, Tobias Klauser wrote: >> Remove the unused but set variable pinst in padata_parallel_worker to >> fix the following warning when building with 'W=1': >> >> kernel/padata.c: In function

Re: [PATCH] padata: Remove unused but set variables

Steffen Klassert wrote: > On Mon, Oct 17, 2016 at 12:16:08PM +0200, Tobias Klauser wrote: >> Remove the unused but set variable pinst in padata_parallel_worker to >> fix the following warning when building with 'W=1': >> >> kernel/padata.c: In function ‘padata_parallel_worker’: >>

Re: [PATCH V2 2/8] PM / OPP: Don't use OPP structure outside of rcu protected section

On 24-10-16, 15:52, Stephen Boyd wrote: > On 10/20, Viresh Kumar wrote: > > The OPP structure must not be used out of the rcu protected section. > > Cache the values to be used in separate variables instead. > > > > Signed-off-by: Viresh Kumar > > Was this found by

Re: [PATCH V2 2/8] PM / OPP: Don't use OPP structure outside of rcu protected section

On 24-10-16, 15:52, Stephen Boyd wrote: > On 10/20, Viresh Kumar wrote: > > The OPP structure must not be used out of the rcu protected section. > > Cache the values to be used in separate variables instead. > > > > Signed-off-by: Viresh Kumar > > Was this found by visual inspection or through

Re: linux-next: manual merge of the pm tree with the imx-mxs tree

On Tue, Oct 25 2016 at 17:51 -0600, Rafael J. Wysocki wrote: On Tuesday, October 25, 2016 10:47:29 AM Stephen Rothwell wrote: Hi Rafael, Today's linux-next merge of the pm tree got a conflict in: arch/arm/mach-imx/gpc.c between commits: eef0b282bb58 ("ARM: imx: gpc: Initialize all power

linux-next: Tree for Oct 25

Hi all, There will probably be no linux-next releases next week while I attend the Kernel Summit. Changes since 20161024: The pm tree gained a conflict against the imx-mxs tree. The mali-dp tree gained a conflict against the drm-misc tree. The sunxi tree gained a build failure so I used

  1   2   3   4   5   6   7   8   9   10   >