Re: [PATCH] device-dax: fix 'dax' device filesystem inode destruction crash

[ adding lkml, dropping 'ndctl prefix ] On Thu, Jun 1, 2017 at 10:39 PM, Dan Williams wrote: > The inode destruction path for the 'dax' device filesystem incorrectly > assumes that the inode was initialized through 'alloc_dax()'. However, > if someone attempts to

Re: [PATCH] device-dax: fix 'dax' device filesystem inode destruction crash

[ adding lkml, dropping 'ndctl prefix ] On Thu, Jun 1, 2017 at 10:39 PM, Dan Williams wrote: > The inode destruction path for the 'dax' device filesystem incorrectly > assumes that the inode was initialized through 'alloc_dax()'. However, > if someone attempts to directly mount the dax

Re: [PATCH -mm 05/13] block, THP: Make block_device_operations.rw_page support THP

On Thu, May 25, 2017 at 02:46:27PM +0800, Huang, Ying wrote: > From: Huang Ying > > The .rw_page in struct block_device_operations is used by the swap > subsystem to read/write the page contents from/into the corresponding > swap slot in the swap device. To support the THP

Re: [PATCH -mm 05/13] block, THP: Make block_device_operations.rw_page support THP

On Thu, May 25, 2017 at 02:46:27PM +0800, Huang, Ying wrote: > From: Huang Ying > > The .rw_page in struct block_device_operations is used by the swap > subsystem to read/write the page contents from/into the corresponding > swap slot in the swap device. To support the THP (Transparent Huge >

linux-next: Tree for Jun 2

Hi all, Changes since 20170601: The mfd tree still had its build failure so I used the version from next-20170530. The target-bva tree gained a conflict against the target-updates tree but the resolution just caused a build failure, so I dropped the target-bva tree for today. Non-merge commits

linux-next: Tree for Jun 2

Hi all, Changes since 20170601: The mfd tree still had its build failure so I used the version from next-20170530. The target-bva tree gained a conflict against the target-updates tree but the resolution just caused a build failure, so I dropped the target-bva tree for today. Non-merge commits

Re: [PATCH] PCI / PM: Restore the status of PCI devices across hibernation

On Fri, Jun 02, 2017 at 01:22:28AM +0200, Rafael J. Wysocki wrote: > On Thu, May 25, 2017 at 10:49 AM, Chen Yu wrote: > > Currently we saw a lot of "No irq handler" errors during hibernation, > > which caused the system hang finally: > > > > [ 710.141581] ata4.00: qc timeout

Re: [PATCH] PCI / PM: Restore the status of PCI devices across hibernation

On Fri, Jun 02, 2017 at 01:22:28AM +0200, Rafael J. Wysocki wrote: > On Thu, May 25, 2017 at 10:49 AM, Chen Yu wrote: > > Currently we saw a lot of "No irq handler" errors during hibernation, > > which caused the system hang finally: > > > > [ 710.141581] ata4.00: qc timeout (cmd 0xec) > > [

Re: [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a

On 06/01/2017 02:25 PM, Thomas Meyer wrote: > Am Donnerstag, den 01.06.2017, 22:58 +0200 schrieb Richard Weinberger: >> >> Sorry, I thought you are CC'ed. >> Thomas please speak up. AFAIR UML fails to boot on one of your new >> Laptops. > > Hi, > > yes, the first userspace process failes here:

Re: [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a

On 06/01/2017 02:25 PM, Thomas Meyer wrote: > Am Donnerstag, den 01.06.2017, 22:58 +0200 schrieb Richard Weinberger: >> >> Sorry, I thought you are CC'ed. >> Thomas please speak up. AFAIR UML fails to boot on one of your new >> Laptops. > > Hi, > > yes, the first userspace process failes here:

Re: [PATCH v2 2/6] Documentation: devicetree: add bindings to support ARM MHU doorbells

Hi Rob, On Wed, May 31, 2017 at 10:38 PM, Rob Herring wrote: > On Thu, May 25, 2017 at 02:23:44PM +0100, Sudeep Holla wrote: >> >> >> .../devicetree/bindings/mailbox/arm-mhu.txt| 46 >> >> -- >> >> 1 file changed, 43 insertions(+), 3 deletions(-) >>

Re: [PATCH v2 2/6] Documentation: devicetree: add bindings to support ARM MHU doorbells

Hi Rob, On Wed, May 31, 2017 at 10:38 PM, Rob Herring wrote: > On Thu, May 25, 2017 at 02:23:44PM +0100, Sudeep Holla wrote: >> >> >> .../devicetree/bindings/mailbox/arm-mhu.txt| 46 >> >> -- >> >> 1 file changed, 43 insertions(+), 3 deletions(-) >> >> >> >> diff

Re: [PATCH] PCI/PM: Set D3 power state only if the end device supports it.

On Wed, May 31, 2017 at 6:13 PM, Alex Williamson wrote: > On Wed, 31 May 2017 17:03:32 +0530 > Geetha sowjanya wrote: > >> Pci driver doesn't check if the device supports D3hot/D3cold power states >> while setting these power states. The

Re: [PATCH] PCI/PM: Set D3 power state only if the end device supports it.

On Wed, May 31, 2017 at 6:13 PM, Alex Williamson wrote: > On Wed, 31 May 2017 17:03:32 +0530 > Geetha sowjanya wrote: > >> Pci driver doesn't check if the device supports D3hot/D3cold power states >> while setting these power states. The device that doesn't support these >> states will fail when

Re: [PATCH v2 27/28] ext4: xattr inode deduplication

On Wed, May 31, 2017 at 03:33:57PM -0700, Tahsin Erdogan wrote: > Ext4 now supports xattr values that are up to 64k in size (vfs limit). > Large xattr values are stored in external inodes each one holding a > single value. Once written the data blocks of these inodes are immutable. > > The real

Re: [PATCH v2 27/28] ext4: xattr inode deduplication

On Wed, May 31, 2017 at 03:33:57PM -0700, Tahsin Erdogan wrote: > Ext4 now supports xattr values that are up to 64k in size (vfs limit). > Large xattr values are stored in external inodes each one holding a > single value. Once written the data blocks of these inodes are immutable. > > The real

[PATCH 2/6] spi: imx: Drop unnecessary check

__spi_validate makes sure that every transfer has a valid bits_per_word and speed_hz setting. We do not need to fallback to values from the spi_device. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 7 --- 1 file changed, 7 deletions(-) diff --git

spi: i.MX: Some cleanup patches

This series contains some drive-by cleanup patches I came up with while reviewing other patches for this driver, Jiada, please consider basing your next round of patches on this when Mark signals he is ok with this series. Sascha

[PATCH 2/6] spi: imx: Drop unnecessary check

__spi_validate makes sure that every transfer has a valid bits_per_word and speed_hz setting. We do not need to fallback to values from the spi_device. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/spi/spi-imx.c

spi: i.MX: Some cleanup patches

This series contains some drive-by cleanup patches I came up with while reviewing other patches for this driver, Jiada, please consider basing your next round of patches on this when Mark signals he is ok with this series. Sascha

[PATCH 3/6] spi: imx: put struct spi_imx_config members into driver private struct

struct spi_imx_config used to hold data specific to the current transfer. However, other data is in the drivers private data struct. Let's drop struct spi_imx_config and put the variables into the drivers private data struct aswell. Signed-off-by: Sascha Hauer ---

[PATCH v2] misc: atmel-ssc: Handle return value of clk_prepare_enable and clk_prepare

clk_prepare_enable() and clk_prepare() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/misc/atmel-ssc.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/misc/atmel-ssc.c

Re: [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode

On Thu, Jun 01, 2017 at 04:58:47AM -0700, Jiada Wang wrote: > Hi Sascha > > On 05/29/2017 02:50 AM, Sascha Hauer wrote: > > Hi, > > > > On Thu, May 25, 2017 at 10:02:42PM -0700, jiada_w...@mentor.com wrote: > > > From: Jiada Wang > > > > > > previously burst length

[PATCH 3/6] spi: imx: put struct spi_imx_config members into driver private struct

struct spi_imx_config used to hold data specific to the current transfer. However, other data is in the drivers private data struct. Let's drop struct spi_imx_config and put the variables into the drivers private data struct aswell. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 50

[PATCH v2] misc: atmel-ssc: Handle return value of clk_prepare_enable and clk_prepare

clk_prepare_enable() and clk_prepare() can fail here and we must check its return value. Signed-off-by: Arvind Yadav --- drivers/misc/atmel-ssc.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c index

Re: [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode

On Thu, Jun 01, 2017 at 04:58:47AM -0700, Jiada Wang wrote: > Hi Sascha > > On 05/29/2017 02:50 AM, Sascha Hauer wrote: > > Hi, > > > > On Thu, May 25, 2017 at 10:02:42PM -0700, jiada_w...@mentor.com wrote: > > > From: Jiada Wang > > > > > > previously burst length (BURST_LENGTH) is always set

[PATCH 1/6] spi: imx: Nothing to do in setupxfer when transfer is NULL

When the spi_transfer given in spi_imx_setupxfer is NULL then we have nothing to do. Bail out early in this case so that we do not have to test for t != NULL multiple times later. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 10 +- 1 file changed, 5

[PATCH 6/6] spi: imx: rename 'bpw' variables

'bpw' is ambiguous and only the context makes sure if bytes_per_word or bits_per_word is meant. Use the full names instead to make reading the code easier. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 12 ++-- 1 file changed, 6 insertions(+), 6

[PATCH 5/6] spi: imx: remove bytes_per_word from private driver struct

We already have bits_per_word in the private driver struct and bytes_per_word can be calculated from it, so remove bits_per_word. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git

[PATCH 4/6] spi: imx: drop bogus unnecessary dma config

It's unnecessary to call spi_imx_dma_configure() from probe(). It will be called later anyway again when an actual DMA transfer is prepared. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/spi/spi-imx.c

[PATCH 1/6] spi: imx: Nothing to do in setupxfer when transfer is NULL

When the spi_transfer given in spi_imx_setupxfer is NULL then we have nothing to do. Bail out early in this case so that we do not have to test for t != NULL multiple times later. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 10 +- 1 file changed, 5 insertions(+), 5

[PATCH 6/6] spi: imx: rename 'bpw' variables

'bpw' is ambiguous and only the context makes sure if bytes_per_word or bits_per_word is meant. Use the full names instead to make reading the code easier. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

[PATCH 5/6] spi: imx: remove bytes_per_word from private driver struct

We already have bits_per_word in the private driver struct and bytes_per_word can be calculated from it, so remove bits_per_word. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/spi/spi-imx.c

[PATCH 4/6] spi: imx: drop bogus unnecessary dma config

It's unnecessary to call spi_imx_dma_configure() from probe(). It will be called later anyway again when an actual DMA transfer is prepared. Signed-off-by: Sascha Hauer --- drivers/spi/spi-imx.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c

Re: [PATCH v5 04/11] arm64: dts: Initial DTS files for Broadcom Stingray SOC

On 05/26/2017 02:24 AM, Anup Patel wrote: > The Broadcom Stingray SoC is a new member in Broadcom iProc > SoC family. > > This patch adds initial DTS files for Broadcom Stingray SoC > and two of its reference boards (bcm958742k and bcm958742t). > > We have lot of reference boards and large

Re: [PATCH v5 04/11] arm64: dts: Initial DTS files for Broadcom Stingray SOC

On 05/26/2017 02:24 AM, Anup Patel wrote: > The Broadcom Stingray SoC is a new member in Broadcom iProc > SoC family. > > This patch adds initial DTS files for Broadcom Stingray SoC > and two of its reference boards (bcm958742k and bcm958742t). > > We have lot of reference boards and large

Re: [PATCH v5 0/5] mtd: mchp23k256: device tree and mchp23lcv1024

Hi Chris, Le Fri, 2 Jun 2017 15:21:14 +1200, Chris Packham a écrit : > This series adds device tree support to the mchp23k256 driver and > support for the mchp23lcv1024 chip. I suspect there are more compatible > variants that we could now enumerate if

Re: [PATCH v5 0/5] mtd: mchp23k256: device tree and mchp23lcv1024

Hi Chris, Le Fri, 2 Jun 2017 15:21:14 +1200, Chris Packham a écrit : > This series adds device tree support to the mchp23k256 driver and > support for the mchp23lcv1024 chip. I suspect there are more compatible > variants that we could now enumerate if desired. > > Note: I've included 2

Re: [v4.12-rc3] Early boot panic on Broadwell

* Linus Torvalds wrote: > On Thu, Jun 1, 2017 at 1:27 AM, Chris Wilson wrote: > > > > I hit an early boot panic on a Broadwell laptop (xps13-9343) that I > > bisected to: > > > > commit cbed27cdf0e3f7ea3b2259e86b9e34df02be3fe4 > > This

Re: [v4.12-rc3] Early boot panic on Broadwell

* Linus Torvalds wrote: > On Thu, Jun 1, 2017 at 1:27 AM, Chris Wilson wrote: > > > > I hit an early boot panic on a Broadwell laptop (xps13-9343) that I > > bisected to: > > > > commit cbed27cdf0e3f7ea3b2259e86b9e34df02be3fe4 > > This is already reverted in -tip afaik, I just haven't gotten

Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

On Wed, May 31, 2017 at 08:45:23AM -0400, Jeff Layton wrote: > v5: don't retrofit old API over the new infrastructure > add fstype flag to indicate how wb errors are tracked within that fs > add more function variants that take a errseq_t "since" value > add second errseq_t to struct

Re: [PATCH v5 00/17] fs: introduce new writeback error reporting and convert ext2 and ext4 to use it

On Wed, May 31, 2017 at 08:45:23AM -0400, Jeff Layton wrote: > v5: don't retrofit old API over the new infrastructure > add fstype flag to indicate how wb errors are tracked within that fs > add more function variants that take a errseq_t "since" value > add second errseq_t to struct

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

On 06/01/2017 04:36 AM, Michael Ellerman wrote: > Michael Bringmann writes: > >> On 05/29/2017 12:32 AM, Michael Ellerman wrote: >>> Reza Arbab writes: >>> On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote: > Reza

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

On 06/01/2017 04:36 AM, Michael Ellerman wrote: > Michael Bringmann writes: > >> On 05/29/2017 12:32 AM, Michael Ellerman wrote: >>> Reza Arbab writes: >>> On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote: > Reza Arbab writes: > >> On Thu, May 25, 2017 at

Ciao ゐ

Ciao Benvenuto al nostro negozio 24.88 euro per gli occhiali da sole di Ray Ban, trasporto libero direttamente alla vostra casa web: rbewpt .com 一份心情，飘飞着心絮的痕迹；一段友情，彼此永远珍藏在心底。深深祝福你，我的朋友：永远幸福！永远快乐！

Ciao ゐ

Ciao Benvenuto al nostro negozio 24.88 euro per gli occhiali da sole di Ray Ban, trasporto libero direttamente alla vostra casa web: rbewpt .com 一份心情，飘飞着心絮的痕迹；一段友情，彼此永远珍藏在心底。深深祝福你，我的朋友：永远幸福！永远快乐！

Re: [lustre-devel] [PATCH] drivers: staging/lustre: conrpc.c - fix sparse error: incompatible types in comparison expression (different address spaces)

On 02/06/17 01:08, Dilger, Andreas wrote: > On Jun 1, 2017, at 14:56, Tordek wrote: >> This is fairly minor but it reveals a few hidden warnings, could I get some >> feedback on it? > > This is a known problem, but can't immediately be fixed because it affects > the interface

Re: [lustre-devel] [PATCH] drivers: staging/lustre: conrpc.c - fix sparse error: incompatible types in comparison expression (different address spaces)

On 02/06/17 01:08, Dilger, Andreas wrote: > On Jun 1, 2017, at 14:56, Tordek wrote: >> This is fairly minor but it reveals a few hidden warnings, could I get some >> feedback on it? > > This is a known problem, but can't immediately be fixed because it affects > the interface with > userspace

Re: linux-next: upcoming conflict between the target-updates and target-bva trees

On 06/01/17 21:03, Nicholas A. Bellinger wrote: On Fri, 2017-06-02 at 13:39 +1000, Stephen Rothwell wrote: Last night the target-bva tree was rebased on top of the target-updates tree. Just now, part of the target-updates tree has been rewritten. So now I expect to get conflict(s) when I merge

Re: linux-next: upcoming conflict between the target-updates and target-bva trees

On 06/01/17 21:03, Nicholas A. Bellinger wrote: On Fri, 2017-06-02 at 13:39 +1000, Stephen Rothwell wrote: Last night the target-bva tree was rebased on top of the target-updates tree. Just now, part of the target-updates tree has been rewritten. So now I expect to get conflict(s) when I merge

Re: [PATCH] Input: synaptics-rmi4 - use %ph to form F34 configuration ID

On Wed, May 31, 2017 at 10:11:14PM +0100, Nick Dyer wrote: > On Tue, May 30, 2017 at 09:59:13AM -0700, Dmitry Torokhov wrote: > > On Tue, May 30, 2017 at 10:23:58AM +0200, Benjamin Tissoires wrote: > > > On May 29 2017 or thereabouts, Dmitry Torokhov wrote: > > > > Instead of printing bytes one by

Re: [PATCH] Input: synaptics-rmi4 - use %ph to form F34 configuration ID

On Wed, May 31, 2017 at 10:11:14PM +0100, Nick Dyer wrote: > On Tue, May 30, 2017 at 09:59:13AM -0700, Dmitry Torokhov wrote: > > On Tue, May 30, 2017 at 10:23:58AM +0200, Benjamin Tissoires wrote: > > > On May 29 2017 or thereabouts, Dmitry Torokhov wrote: > > > > Instead of printing bytes one by

Re: [PATCH v2] Input: tm2-touchkey - use LEN_ON as boolean value instead of LED_FULL

On Thu, Jun 01, 2017 at 10:47:36AM +0900, Andi Shyti wrote: > Commit 4e552c8cb5bc ("leds: add LED_ON brightness as boolean value") > has introduced the LED_ON enumeration value that can be used > instead of LED_FULL which has more of a linear value. > > Because the tm2-touchscreen doesn't have

Re: [PATCH v2] Input: tm2-touchkey - use LEN_ON as boolean value instead of LED_FULL

On Thu, Jun 01, 2017 at 10:47:36AM +0900, Andi Shyti wrote: > Commit 4e552c8cb5bc ("leds: add LED_ON brightness as boolean value") > has introduced the LED_ON enumeration value that can be used > instead of LED_FULL which has more of a linear value. > > Because the tm2-touchscreen doesn't have

[PATCH v2] perf sort: only insert overhead && overhead_children when no overhead* field given

From: Changbin Du If we always insert 'overhead' and 'overhead_children' as sort keys, this make it impossible to sort as overhead (which displayed as Self) first.Ths will be a problem if the data is collected with call-graph enabled. Then we never can sort the result as

[PATCH v2] perf sort: only insert overhead && overhead_children when no overhead* field given

From: Changbin Du If we always insert 'overhead' and 'overhead_children' as sort keys, this make it impossible to sort as overhead (which displayed as Self) first.Ths will be a problem if the data is collected with call-graph enabled. Then we never can sort the result as self-overhead on this

[PATCH] sched/header: Remove a redundant comment.

There is no more set_task_vxid() helper. remove it from the comment. Signed-off-by: Perr Zhang --- include/linux/sched.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 2b69fc650201..1abaa3728bf7 100644 ---

[PATCH] sched/header: Remove a redundant comment.

There is no more set_task_vxid() helper. remove it from the comment. Signed-off-by: Perr Zhang --- include/linux/sched.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/linux/sched.h b/include/linux/sched.h index 2b69fc650201..1abaa3728bf7 100644 --- a/include/linux/sched.h +++

Re: linux-next: manual merge of the target-bva tree with the target-updates tree

Hi all, On Fri, 2 Jun 2017 14:05:35 +1000 Stephen Rothwell wrote: > > Today's linux-next merge of the target-bva tree got a conflict in: > > drivers/target/target_core_tpg.c > > between commits: > > 06fd91ce633d ("target/configfs: Kill se_lun->lun_link_magic") >

Re: linux-next: manual merge of the target-bva tree with the target-updates tree

Hi all, On Fri, 2 Jun 2017 14:05:35 +1000 Stephen Rothwell wrote: > > Today's linux-next merge of the target-bva tree got a conflict in: > > drivers/target/target_core_tpg.c > > between commits: > > 06fd91ce633d ("target/configfs: Kill se_lun->lun_link_magic") > 4f61e1e687c4 ("target:

Re: [lustre-devel] [PATCH] drivers: staging/lustre: conrpc.c - fix sparse error: incompatible types in comparison expression (different address spaces)

On Jun 1, 2017, at 14:56, Tordek wrote: > This is fairly minor but it reveals a few hidden warnings, could I get some > feedback on it? This is a known problem, but can't immediately be fixed because it affects the interface with userspace tools. The correct solution is to

Re: [lustre-devel] [PATCH] drivers: staging/lustre: conrpc.c - fix sparse error: incompatible types in comparison expression (different address spaces)

On Jun 1, 2017, at 14:56, Tordek wrote: > This is fairly minor but it reveals a few hidden warnings, could I get some > feedback on it? This is a known problem, but can't immediately be fixed because it affects the interface with userspace tools. The correct solution is to not use struct

[git pull] drm quirk displayport descriptions

Hi Linus, As mentioned I have a separate request for fixing a regression, but also keeping the broken hw working, for certain USB-C DP adapters they require a minimised n/m parameters, but an attempt to do this generically has failed, we need to quirk these specific adapters. However doing it

[git pull] drm quirk displayport descriptions

Hi Linus, As mentioned I have a separate request for fixing a regression, but also keeping the broken hw working, for certain USB-C DP adapters they require a minimised n/m parameters, but an attempt to do this generically has failed, we need to quirk these specific adapters. However doing it

linux-next: manual merge of the target-bva tree with the target-updates tree

Hi Bart, Today's linux-next merge of the target-bva tree got a conflict in: drivers/target/target_core_tpg.c between commits: 06fd91ce633d ("target/configfs: Kill se_lun->lun_link_magic") 4f61e1e687c4 ("target: Avoid target_shutdown_sessions loop during queue_depth change") from the

linux-next: manual merge of the target-bva tree with the target-updates tree

Hi Bart, Today's linux-next merge of the target-bva tree got a conflict in: drivers/target/target_core_tpg.c between commits: 06fd91ce633d ("target/configfs: Kill se_lun->lun_link_magic") 4f61e1e687c4 ("target: Avoid target_shutdown_sessions loop during queue_depth change") from the

Re: linux-next: upcoming conflict between the target-updates and target-bva trees

On Fri, 2017-06-02 at 13:39 +1000, Stephen Rothwell wrote: > Hi all, > > Last night the tagret-bva tree was rebased on top of the target-updates > tree. Just now, part of the target-updates tree has been rewritten. > So now I expect to get conflict(s) when I merge these trees since the > commits

Re: linux-next: upcoming conflict between the target-updates and target-bva trees

On Fri, 2017-06-02 at 13:39 +1000, Stephen Rothwell wrote: > Hi all, > > Last night the tagret-bva tree was rebased on top of the target-updates > tree. Just now, part of the target-updates tree has been rewritten. > So now I expect to get conflict(s) when I merge these trees since the > commits

Re: linux-next: build warnings after merge of the drm tree

Hi all, On Thu, 25 May 2017 11:49:42 +1000 Stephen Rothwell wrote: > > On Fri, 19 May 2017 10:49:06 -0700 Eric Anholt wrote: > > > > Stephen Rothwell writes: > > > > > After merging the drm tree, today's linux-next build

Re: linux-next: build warnings after merge of the drm tree

Hi all, On Thu, 25 May 2017 11:49:42 +1000 Stephen Rothwell wrote: > > On Fri, 19 May 2017 10:49:06 -0700 Eric Anholt wrote: > > > > Stephen Rothwell writes: > > > > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig) > > > produced these warnings: > > > > > >

Re: linux-next: manual merge of the target-bva tree with the target-updates tree

On Thu, 2017-06-01 at 14:14 -0700, Bart Van Assche wrote: > On 05/31/17 22:04, Nicholas A. Bellinger wrote: > > Go ahead and get list review on drivers/target/ changes before pushing > > them into linux-next, please. > > > > Btw, I don't care if you queue up one's that do have at least two > >

Re: linux-next: manual merge of the target-bva tree with the target-updates tree

On Thu, 2017-06-01 at 14:14 -0700, Bart Van Assche wrote: > On 05/31/17 22:04, Nicholas A. Bellinger wrote: > > Go ahead and get list review on drivers/target/ changes before pushing > > them into linux-next, please. > > > > Btw, I don't care if you queue up one's that do have at least two > >

Re: [PATCH] acpi/iort, numa: Add numa node mapping for smmuv3 devices

[+Cc Lv Zheng] On 2017/6/2 0:21, Lorenzo Pieralisi wrote: > On Thu, Jun 01, 2017 at 07:35:37PM +0530, Ganapatrao Kulkarni wrote: >> ARM IORT specification has provision to define Proximity domain >> in SMMUv3 IORT table. Adding required code to parse Proximity domain of >> SMMUv3 IORT table.

Re: [PATCH] acpi/iort, numa: Add numa node mapping for smmuv3 devices

[+Cc Lv Zheng] On 2017/6/2 0:21, Lorenzo Pieralisi wrote: > On Thu, Jun 01, 2017 at 07:35:37PM +0530, Ganapatrao Kulkarni wrote: >> ARM IORT specification has provision to define Proximity domain >> in SMMUv3 IORT table. Adding required code to parse Proximity domain of >> SMMUv3 IORT table.

Re: [PATCH] modpost: abort if a module name is too long

On 2017/6/2 11:04, Wanlong Gao wrote: > > > On 2017/6/2 7:23, Jessica Yu wrote: >> +++ Wanlong Gao [31/05/17 11:48 +0800]: >>> >>> >>> On 2017/5/31 11:30, Jessica Yu wrote: +++ Wanlong Gao [31/05/17 10:23 +0800]: > Hi Jessica, > > On 2017/5/29 17:10, Jessica Yu wrote: >>

Re: [PATCH] modpost: abort if a module name is too long

On 2017/6/2 11:04, Wanlong Gao wrote: > > > On 2017/6/2 7:23, Jessica Yu wrote: >> +++ Wanlong Gao [31/05/17 11:48 +0800]: >>> >>> >>> On 2017/5/31 11:30, Jessica Yu wrote: +++ Wanlong Gao [31/05/17 10:23 +0800]: > Hi Jessica, > > On 2017/5/29 17:10, Jessica Yu wrote: >>

[PATCH] media: platform: s3c-camif: fix arguments position in function call

Hi Sylwester, Here is another patch in case you decide that it is better to apply this one. Thanks -- Gustavo A. R. Silva == Fix the position of the arguments in function call. Addresses-Coverity-ID: 1248800 Addresses-Coverity-ID: 1269141 Signed-off-by: Gustavo A. R. Silva

[PATCH] media: platform: s3c-camif: fix arguments position in function call

Hi Sylwester, Here is another patch in case you decide that it is better to apply this one. Thanks -- Gustavo A. R. Silva == Fix the position of the arguments in function call. Addresses-Coverity-ID: 1248800 Addresses-Coverity-ID: 1269141 Signed-off-by: Gustavo A. R. Silva ---

linux-next: upcoming conflict between the target-updates and target-bva trees

Hi all, Last night the tagret-bva tree was rebased on top of the target-updates tree. Just now, part of the target-updates tree has been rewritten. So now I expect to get conflict(s) when I merge these trees since the commits in the target-updates tree are no longer the same as those that the

linux-next: upcoming conflict between the target-updates and target-bva trees

Hi all, Last night the tagret-bva tree was rebased on top of the target-updates tree. Just now, part of the target-updates tree has been rewritten. So now I expect to get conflict(s) when I merge these trees since the commits in the target-updates tree are no longer the same as those that the

Re: [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get the dma-buf

On Fri, 2 Jun 2017 03:24:35 + "Chen, Xiaoguang" wrote: > Hi Alex, > > >-Original Message- > >From: Alex Williamson [mailto:alex.william...@redhat.com] > >Sent: Friday, June 02, 2017 2:08 AM > >To: Chen, Xiaoguang > >Cc:

Re: [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get the dma-buf

On Fri, 2 Jun 2017 03:24:35 + "Chen, Xiaoguang" wrote: > Hi Alex, > > >-Original Message- > >From: Alex Williamson [mailto:alex.william...@redhat.com] > >Sent: Friday, June 02, 2017 2:08 AM > >To: Chen, Xiaoguang > >Cc: kra...@redhat.com; ch...@chris-wilson.co.uk; intel- >

Re: [PATCH] perf sort: only insert overhead && overhead_children when no overhead* field given

On Fri, Jun 02, 2017 at 10:52:24AM +0800, Du, Changbin wrote: > On Thu, Jun 01, 2017 at 12:21:39PM +0200, Jiri Olsa wrote: > > On Thu, Jun 01, 2017 at 05:03:21PM +0800, changbin...@intel.com wrote: > > > diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c > > > index 5762ae4..69eea3a

Re: [PATCH] perf sort: only insert overhead && overhead_children when no overhead* field given

On Fri, Jun 02, 2017 at 10:52:24AM +0800, Du, Changbin wrote: > On Thu, Jun 01, 2017 at 12:21:39PM +0200, Jiri Olsa wrote: > > On Thu, Jun 01, 2017 at 05:03:21PM +0800, changbin...@intel.com wrote: > > > diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c > > > index 5762ae4..69eea3a

RE: [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get the dma-buf

Hi Alex, >-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Friday, June 02, 2017 2:08 AM >To: Chen, Xiaoguang >Cc: kra...@redhat.com; ch...@chris-wilson.co.uk; intel- >g...@lists.freedesktop.org; linux-kernel@vger.kernel.org;

RE: [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get the dma-buf

Hi Alex, >-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Friday, June 02, 2017 2:08 AM >To: Chen, Xiaoguang >Cc: kra...@redhat.com; ch...@chris-wilson.co.uk; intel- >g...@lists.freedesktop.org; linux-kernel@vger.kernel.org; >zhen...@linux.intel.com;

[PATCH v5 3/5] mtd: handle partitioning on devices with 0 erasesize

erasesize is meaningful for flash devices but for SRAM there is no concept of an erase block so erasesize is set to 0. When partitioning these devices instead of ensuring partitions fall on erasesize boundaries we ensure they fall on writesize boundaries. Helped-by: Boris Brezillon

[PATCH v5 0/5] mtd: mchp23k256: device tree and mchp23lcv1024

This series adds device tree support to the mchp23k256 driver and support for the mchp23lcv1024 chip. I suspect there are more compatible variants that we could now enumerate if desired. Note: I've included 2 patches that have already been applied to l2-mtd.git for context and so as not to upset

[PATCH v5 3/5] mtd: handle partitioning on devices with 0 erasesize

erasesize is meaningful for flash devices but for SRAM there is no concept of an erase block so erasesize is set to 0. When partitioning these devices instead of ensuring partitions fall on erasesize boundaries we ensure they fall on writesize boundaries. Helped-by: Boris Brezillon

[PATCH v5 0/5] mtd: mchp23k256: device tree and mchp23lcv1024

This series adds device tree support to the mchp23k256 driver and support for the mchp23lcv1024 chip. I suspect there are more compatible variants that we could now enumerate if desired. Note: I've included 2 patches that have already been applied to l2-mtd.git for context and so as not to upset

[PATCH v2 0/4] fix some issues for Rockchip usb2-phy and add rk3228 SoCs' support

These series of patches fix some issues for rockchip usb2-phy and amend usb2-phy framework to support one phy which comprises with two host-ports. In addition, this change also add rk3228 usb2-phy support. Changes from v1: - Replaced rk322x with rk3228 for PATCH 4/4. - Included devicetree

[PATCH v2 0/4] fix some issues for Rockchip usb2-phy and add rk3228 SoCs' support

These series of patches fix some issues for rockchip usb2-phy and amend usb2-phy framework to support one phy which comprises with two host-ports. In addition, this change also add rk3228 usb2-phy support. Changes from v1: - Replaced rk322x with rk3228 for PATCH 4/4. - Included devicetree

[PATCH v5 5/5] mtd: mchp23k256: Add support for mchp23lcv1024

The mchp23lcv1024 is similar to the mchp23k256, the differences (from a software point of view) are the capacity of the chip and the size of the addresses used. There is no way to detect the specific chip so we must be told via a Device Tree or default to mchp23k256 when device tree is not used.

[PATCH v5 4/5] mtd: mchp23k256: add partitioning support

Setting the of_node for the mtd device allows the generic mtd code to setup the partitions. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect revew/test from Andrew Changes

[PATCH v5 5/5] mtd: mchp23k256: Add support for mchp23lcv1024

The mchp23lcv1024 is similar to the mchp23k256, the differences (from a software point of view) are the capacity of the chip and the size of the addresses used. There is no way to detect the specific chip so we must be told via a Device Tree or default to mchp23k256 when device tree is not used.

[PATCH v5 4/5] mtd: mchp23k256: add partitioning support

Setting the of_node for the mtd device allows the generic mtd code to setup the partitions. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect revew/test from Andrew Changes in v3: - remove setting of erasesize Changes in v4: - none Changes

[PATCH v5 1/5] mtd: mchp23k256: Add OF device ID table

This allows registering of this device via a Device Tree. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2: - collect review/test from Andrew Changes in v3: - None Changes in v4: -

[PATCH v5 2/5] mtd: mchp23k256: switch to mtd_device_register()

Use mtd_device_register() instead of mtd_device_parse_register() to eliminate two unused parameters. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect review/test from

[PATCH v5 1/5] mtd: mchp23k256: Add OF device ID table

This allows registering of this device via a Device Tree. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2: - collect review/test from Andrew Changes in v3: - None Changes in v4: - None Changes in v5: - None (note this has already been applied to

[PATCH v5 2/5] mtd: mchp23k256: switch to mtd_device_register()

Use mtd_device_register() instead of mtd_device_parse_register() to eliminate two unused parameters. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn --- Changes in v2 - collect review/test from Andrew Changes in v3: - None Changes in v4: - None Changes in v5: -

  1   2   3   4   5   6   7   8   9   10   >