Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

On Friday 15 April 2016 07:45:19 Ingo Molnar wrote: > > * Denys Vlasenko wrote: > > > > In fact, the following patch seems to fix it: > > > > > > diff --git a/include/scsi/scsi_transport_fc.h > > > b/include/scsi/scsi_transport_fc.h > > > index bf66ea6..56b9e81 100644 > >

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

On Friday 15 April 2016 07:45:19 Ingo Molnar wrote: > > * Denys Vlasenko wrote: > > > > In fact, the following patch seems to fix it: > > > > > > diff --git a/include/scsi/scsi_transport_fc.h > > > b/include/scsi/scsi_transport_fc.h > > > index bf66ea6..56b9e81 100644 > > > ---

Re: [PATCH 04/12] mtd: nand: atmel: set ECC algorithm explicitly

On Fri, 15 Apr 2016 21:54:04 +0200 Rafał Miłecki wrote: > Set it to value obtained from platform data with fallback to Hamming. > This is part of process deprecating NAND_ECC_SOFT_BCH (and switching to > enum nand_ecc_algo). > > Signed-off-by: Rafał Miłecki

Re: [PATCH 04/12] mtd: nand: atmel: set ECC algorithm explicitly

On Fri, 15 Apr 2016 21:54:04 +0200 Rafał Miłecki wrote: > Set it to value obtained from platform data with fallback to Hamming. > This is part of process deprecating NAND_ECC_SOFT_BCH (and switching to > enum nand_ecc_algo). > > Signed-off-by: Rafał Miłecki > --- >

Re: [PATCH 03/12] avr32: set Atmel NAND ECC algorithm explicitly

On Fri, 15 Apr 2016 21:54:03 +0200 Rafał Miłecki wrote: > This is part of process deprecating NAND_ECC_SOFT_BCH (and switching to > enum nand_ecc_algo). Not sure we really need to add this ->ecc_algo field: none of the existing AVR32 boards use software BCH implementation, and

Re: [PATCH 03/12] avr32: set Atmel NAND ECC algorithm explicitly

On Fri, 15 Apr 2016 21:54:03 +0200 Rafał Miłecki wrote: > This is part of process deprecating NAND_ECC_SOFT_BCH (and switching to > enum nand_ecc_algo). Not sure we really need to add this ->ecc_algo field: none of the existing AVR32 boards use software BCH implementation, and I don't expect to

Re: [PATCH V6 08/13] PCI: generic, thunder: update to use generic ECAM API

On Saturday 16 April 2016 12:50:13 Jayachandran C wrote: > > > > I still think it would be better to keep the loadable PCI host drivers > > separate from the ACPI PCI infrastructure. There are a number of > > simplifications that we want to do to the DT based drivers in the long > > run, so it's

Re: [PATCH V6 08/13] PCI: generic, thunder: update to use generic ECAM API

On Saturday 16 April 2016 12:50:13 Jayachandran C wrote: > > > > I still think it would be better to keep the loadable PCI host drivers > > separate from the ACPI PCI infrastructure. There are a number of > > simplifications that we want to do to the DT based drivers in the long > > run, so it's

[PATCH 12/28] mm, page_alloc: Remove unnecessary initialisation from __alloc_pages_nodemask()

page is guaranteed to be set before it is read with or without the initialisation. Signed-off-by: Mel Gorman --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index f5ddb342c967..df03ccc7f07c

[PATCH 12/28] mm, page_alloc: Remove unnecessary initialisation from __alloc_pages_nodemask()

page is guaranteed to be set before it is read with or without the initialisation. Signed-off-by: Mel Gorman --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index f5ddb342c967..df03ccc7f07c 100644 --- a/mm/page_alloc.c

Re: [PATCH V6 08/13] PCI: generic, thunder: update to use generic ECAM API

On Sat, Apr 16, 2016 at 12:09 AM, Arnd Bergmann wrote: > On Friday 15 April 2016 19:06:43 Tomasz Nowicki wrote: >> -MODULE_DEVICE_TABLE(of, thunder_pem_of_match); >> - >> -static int thunder_pem_probe(struct platform_device *pdev) >> +static int thunder_pem_init(struct device *dev,

Re: [PATCH V6 08/13] PCI: generic, thunder: update to use generic ECAM API

On Sat, Apr 16, 2016 at 12:09 AM, Arnd Bergmann wrote: > On Friday 15 April 2016 19:06:43 Tomasz Nowicki wrote: >> -MODULE_DEVICE_TABLE(of, thunder_pem_of_match); >> - >> -static int thunder_pem_probe(struct platform_device *pdev) >> +static int thunder_pem_init(struct device *dev, struct

[PATCH] staging: media/omap1: assign resource before use

A recent cleanup patch accidentally moved the initial assignment of the register resource after its first use, as shown by this gcc warning: drivers/staging/media/omap1/omap1_camera.c: In function 'omap1_cam_probe': include/linux/ioport.h:191:12: error: 'res' may be used uninitialized in this

[PATCH] staging: media/omap1: assign resource before use

A recent cleanup patch accidentally moved the initial assignment of the register resource after its first use, as shown by this gcc warning: drivers/staging/media/omap1/omap1_camera.c: In function 'omap1_cam_probe': include/linux/ioport.h:191:12: error: 'res' may be used uninitialized in this

Re: INFO: inconsistent lock state in ecryptfs_calculate_md5

On Thu, Apr 14, 2016 at 10:03:48PM +0800, Nicolas Boichat wrote: > > We've run into the following lockdep warning while using a system with > ecryptfs, under heavy memory pressure. > > If I understand the issue correctly, > fs/ecryptfs/crypto.c:ecryptfs_calculate_md5: > - Locks

Re: INFO: inconsistent lock state in ecryptfs_calculate_md5

On Thu, Apr 14, 2016 at 10:03:48PM +0800, Nicolas Boichat wrote: > > We've run into the following lockdep warning while using a system with > ecryptfs, under heavy memory pressure. > > If I understand the issue correctly, > fs/ecryptfs/crypto.c:ecryptfs_calculate_md5: > - Locks

[PATCH] ARM: dts: omap3-n900: Specify peripherals LDO regulators initial mode

Without that, regulators are left in the mode last set by the bootloader or by the kernel the device was rebooted from. This leads to various problems like non-working peripherals. Signed-off-by: Ivaylo Dimitrov --- arch/arm/boot/dts/omap3-n900.dts | 9 + 1

[PATCH] ARM: dts: omap3-n900: Specify peripherals LDO regulators initial mode

Without that, regulators are left in the mode last set by the bootloader or by the kernel the device was rebooted from. This leads to various problems like non-working peripherals. Signed-off-by: Ivaylo Dimitrov --- arch/arm/boot/dts/omap3-n900.dts | 9 + 1 file changed, 9 insertions(+)

Re: [ANNOUNCE] 2016-Q1 release of KVMGT (Was Re: KVMGT - the implementation of ...)

Hi all, We are pleased to announce another update of Intel GVT-g for KVM. Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is

Re: [ANNOUNCE] 2016-Q1 release of KVMGT (Was Re: KVMGT - the implementation of ...)

Hi all, We are pleased to announce another update of Intel GVT-g for KVM. Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is

[PATCH] ARM: dts: omap3: Fix ISP syscon register offset

According to the TRM, SCM CONTROL_CSIRXFE register is on offset 0x6c Signed-off-by: Ivaylo Dimitrov --- arch/arm/boot/dts/omap34xx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap34xx.dtsi

[PATCH] ARM: dts: omap3: Fix ISP syscon register offset

According to the TRM, SCM CONTROL_CSIRXFE register is on offset 0x6c Signed-off-by: Ivaylo Dimitrov --- arch/arm/boot/dts/omap34xx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi index 5cdba1f..e446562

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

On Fri, Apr 15, 2016 at 05:37:32PM -0600, Jason Gunthorpe wrote: > On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote: > > > Intel as usual decided to do it in their way and the result is presented > > on this mailing list. > > Dennis was pretty clear he was going to send the

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

On Fri, Apr 15, 2016 at 07:28:01PM -0400, Ira Weiny wrote: > On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote: > Do you have a technical reason that this patch series does not fix the > write/writev issue brought up by Al? Sure, I truly believe that we can do common API in a months

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

On Fri, Apr 15, 2016 at 05:37:32PM -0600, Jason Gunthorpe wrote: > On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote: > > > Intel as usual decided to do it in their way and the result is presented > > on this mailing list. > > Dennis was pretty clear he was going to send the

Re: [PATCH 0/7] IB/hfi1: Remove write() and use ioctl() for user access

On Fri, Apr 15, 2016 at 07:28:01PM -0400, Ira Weiny wrote: > On Sat, Apr 16, 2016 at 12:23:28AM +0300, Leon Romanovsky wrote: > Do you have a technical reason that this patch series does not fix the > write/writev issue brought up by Al? Sure, I truly believe that we can do common API in a months

Re: Allocation of frame buffer at a specific memory range or address

On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote: > And now the question is how to force DRM subsystem or just that driver > to use whatever predefined (say via device tree) location in memory > for data buffer allocation. It seems this is pretty easy to do with DT reserved-memory binding.

Re: Allocation of frame buffer at a specific memory range or address

On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote: > And now the question is how to force DRM subsystem or just that driver > to use whatever predefined (say via device tree) location in memory > for data buffer allocation. It seems this is pretty easy to do with DT reserved-memory binding.

Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler

Hi Il giorno 16/apr/2016, alle ore 00:45, Tejun Heo ha scritto: > Hello, Paolo. > > On Sat, Apr 16, 2016 at 12:08:44AM +0200, Paolo Valente wrote: >> Maybe the source of confusion is the fact that a simple sector-based, >> proportional share scheduler always distributes total

Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler

Hi Il giorno 16/apr/2016, alle ore 00:45, Tejun Heo ha scritto: > Hello, Paolo. > > On Sat, Apr 16, 2016 at 12:08:44AM +0200, Paolo Valente wrote: >> Maybe the source of confusion is the fact that a simple sector-based, >> proportional share scheduler always distributes total bandwidth >>

<    1   2   3   4   5