[ 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
[ 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
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
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
>
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
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
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
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)
> > [
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:
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:
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(-)
>>
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
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
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
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
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
__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
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
__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
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
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
---
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
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
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
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
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
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
'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
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
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
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
'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
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
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
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
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
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
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
* 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
* 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
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
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
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
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
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
Benvenuto al nostro negozio
24.88 euro per gli occhiali da sole di Ray Ban, trasporto libero direttamente
alla vostra casa
web: rbewpt .com
一份心情,飘飞着心絮的痕迹;一段友情,彼此永远珍藏在心底。深深祝福你,我的朋友:永远幸福!永远快乐!
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
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
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
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
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
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
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
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
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
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
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
---
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
+++
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")
>
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:
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
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
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
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
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
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
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
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
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
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:
> > >
> > >
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
> >
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
> >
[+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.
[+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.
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:
>>
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:
>>
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
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
---
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
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
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:
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-
>
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
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
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;
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;
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
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
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
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
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
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
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.
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
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.
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
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:
-
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
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
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 - 100 of 2256 matches
Mail list logo