Rasmus Villemoes wrote:
> Would you consider adding a Kconfig knob to not include all this (and
> all the extra tricks that syscall might learn down the road)?
I guess that can be done, though the bits are spread out into various
filesystems.
David
Rasmus Villemoes wrote:
> Would you consider adding a Kconfig knob to not include all this (and
> all the extra tricks that syscall might learn down the road)?
I guess that can be done, though the bits are spread out into various
filesystems.
David
Alan Jenkins wrote:
> I replied last time to wonder about the MNT_UMOUNT mnt_flag. So I've tested it
> now :-), on David's current tree (commit 5581f4935add).
>
> The modified do_move_mount() allows re-attaching something that was
> lazy-unmounted. But the lazy unmount sets MNT_UMOUNT. And this
On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> Hi all,
Hi, nice series, I have a lot of details to grok, but I like the idea of PE
> Proxy Execution (also goes under several other names) isn't a new
> concept, it has been mentioned already in the past to this community
> (both in
Alan Jenkins wrote:
> I replied last time to wonder about the MNT_UMOUNT mnt_flag. So I've tested it
> now :-), on David's current tree (commit 5581f4935add).
>
> The modified do_move_mount() allows re-attaching something that was
> lazy-unmounted. But the lazy unmount sets MNT_UMOUNT. And this
On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> Hi all,
Hi, nice series, I have a lot of details to grok, but I like the idea of PE
> Proxy Execution (also goes under several other names) isn't a new
> concept, it has been mentioned already in the past to this community
> (both in
On Mon, Oct 8, 2018 at 5:58 PM Arnd Bergmann wrote:
> Removing the linux/gpio.h include means we no longer have a declaration
> of gpiochip_lock_as_irq() when CONFIG_GPIOLIB is disabled:
>
> drivers/pinctrl/mediatek/mtk-eint.c: In function
> 'mtk_eint_irq_request_resources':
>
On Mon, Oct 8, 2018 at 5:58 PM Arnd Bergmann wrote:
> Removing the linux/gpio.h include means we no longer have a declaration
> of gpiochip_lock_as_irq() when CONFIG_GPIOLIB is disabled:
>
> drivers/pinctrl/mediatek/mtk-eint.c: In function
> 'mtk_eint_irq_request_resources':
>
Hi Robin,
On 10/10/2018 12:31 PM, Robin Murphy wrote:
> On 09/10/18 17:06, Lukasz Luba wrote:
>> Hi Peter,
>>
>> On 10/09/2018 05:43 PM, Peter Zijlstra wrote:
>>> On Tue, Oct 09, 2018 at 05:39:27PM +0200, Lukasz Luba wrote:
This patch add some warning related to performance drop.
It
On Mon, Oct 8, 2018 at 12:57 AM Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix gpio kernel-doc generation after rename of the devres.c file.
> Fixes these errors & warning:
>
> Error: Cannot open file ../drivers/gpio/devres.c
> Error: Cannot open file ../drivers/gpio/devres.c
> WARNING:
Hi Robin,
On 10/10/2018 12:31 PM, Robin Murphy wrote:
> On 09/10/18 17:06, Lukasz Luba wrote:
>> Hi Peter,
>>
>> On 10/09/2018 05:43 PM, Peter Zijlstra wrote:
>>> On Tue, Oct 09, 2018 at 05:39:27PM +0200, Lukasz Luba wrote:
This patch add some warning related to performance drop.
It
On Mon, Oct 8, 2018 at 12:57 AM Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix gpio kernel-doc generation after rename of the devres.c file.
> Fixes these errors & warning:
>
> Error: Cannot open file ../drivers/gpio/devres.c
> Error: Cannot open file ../drivers/gpio/devres.c
> WARNING:
On (10/10/18 13:35), Michal Hocko wrote:
> > Just flooding out of memory messages can trigger RCU stall problems.
> > For example, a severe skbuff_head_cache or kmalloc-512 leak bug is causing
>
> [...]
>
> Quite some of them, indeed! I guess we want to rate limit the output.
> What about the
On (10/10/18 13:35), Michal Hocko wrote:
> > Just flooding out of memory messages can trigger RCU stall problems.
> > For example, a severe skbuff_head_cache or kmalloc-512 leak bug is causing
>
> [...]
>
> Quite some of them, indeed! I guess we want to rate limit the output.
> What about the
On Wed, Oct 10, 2018 at 1:19 PM Luis Henriques wrote:
>
> Ilya Dryomov writes:
>
> > On Wed, Oct 10, 2018 at 6:21 AM Yan, Zheng wrote:
> >>
> >> On Wed, Oct 10, 2018 at 1:54 AM Luis Henriques wrote:
>
>
>
> >> Applied, thanks
> >
> > I don't think it should go to stable kernels. Strictly
On Wed, Oct 10, 2018 at 1:19 PM Luis Henriques wrote:
>
> Ilya Dryomov writes:
>
> > On Wed, Oct 10, 2018 at 6:21 AM Yan, Zheng wrote:
> >>
> >> On Wed, Oct 10, 2018 at 1:54 AM Luis Henriques wrote:
>
>
>
> >> Applied, thanks
> >
> > I don't think it should go to stable kernels. Strictly
On Wed, Oct 10, 2018 at 02:23:40PM +0300, Talel Shenhar wrote:
> On 10/10/2018 01:18 PM, Mark Brown wrote:
> > On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
> >> The dw spi controller has an auto-deselect of Chip-Select, in case there is
> >> no data inside the Tx FIFO. While
On Wed, Oct 10, 2018 at 02:23:40PM +0300, Talel Shenhar wrote:
> On 10/10/2018 01:18 PM, Mark Brown wrote:
> > On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
> >> The dw spi controller has an auto-deselect of Chip-Select, in case there is
> >> no data inside the Tx FIFO. While
On Wed 10-10-18 19:43:38, Tetsuo Handa wrote:
> On 2018/10/10 17:59, Michal Hocko wrote:
> > On Wed 10-10-18 09:12:45, Tetsuo Handa wrote:
> >> syzbot is hitting RCU stall due to memcg-OOM event.
> >> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
> >
> > This is
On Wed 10-10-18 19:43:38, Tetsuo Handa wrote:
> On 2018/10/10 17:59, Michal Hocko wrote:
> > On Wed 10-10-18 09:12:45, Tetsuo Handa wrote:
> >> syzbot is hitting RCU stall due to memcg-OOM event.
> >> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
> >
> > This is
Hi all,
On Tue, 9 Oct 2018 11:24:26 +0200
Juri Lelli wrote:
> Hi all,
>
> Proxy Execution (also goes under several other names) isn't a new
> concept, it has been mentioned already in the past to this community
> (both in email discussions and at conferences [1, 2]), but no actual
>
Hi all,
On Tue, 9 Oct 2018 11:24:26 +0200
Juri Lelli wrote:
> Hi all,
>
> Proxy Execution (also goes under several other names) isn't a new
> concept, it has been mentioned already in the past to this community
> (both in email discussions and at conferences [1, 2]), but no actual
>
The way we calculate logbuf free space percentage overflows signed
integer:
int free;
free = __LOG_BUF_LEN - log_next_idx;
pr_info("early log buf free: %u(%u%%)\n",
free, (free * 100) / __LOG_BUF_LEN);
We support LOG_BUF_LEN of up to 1<<25 bytes. Since
The way we calculate logbuf free space percentage overflows signed
integer:
int free;
free = __LOG_BUF_LEN - log_next_idx;
pr_info("early log buf free: %u(%u%%)\n",
free, (free * 100) / __LOG_BUF_LEN);
We support LOG_BUF_LEN of up to 1<<25 bytes. Since
On (10/10/18 19:38), Sergey Senozhatsky wrote:
> The way we calculate free logbuf free space percentage
> overflows signed integer:
>
> int free;
>
> free = __LOG_BUF_LEN - log_next_idx;
> pr_info("early log buf free: %u(%u%%)\n",
> free, (free * 100) /
On (10/10/18 19:38), Sergey Senozhatsky wrote:
> The way we calculate free logbuf free space percentage
> overflows signed integer:
>
> int free;
>
> free = __LOG_BUF_LEN - log_next_idx;
> pr_info("early log buf free: %u(%u%%)\n",
> free, (free * 100) /
On Wed, 2018-10-10 at 13:34 +0300, Talel Shenhar wrote:
> > On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
> >
> > > The dw spi controller has an auto-deselect of Chip-Select, in
> > > case there is
> > > no data inside the Tx FIFO. While working on platforms with
> > > Alpine
On Wed, 2018-10-10 at 13:34 +0300, Talel Shenhar wrote:
> > On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
> >
> > > The dw spi controller has an auto-deselect of Chip-Select, in
> > > case there is
> > > no data inside the Tx FIFO. While working on platforms with
> > > Alpine
On 10/10/2018 01:18 PM, Mark Brown wrote:
> On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
>
>> The dw spi controller has an auto-deselect of Chip-Select, in case there is
>> no data inside the Tx FIFO. While working on platforms with Alpine chips,
> Why would we ever want to
On 10/10/2018 01:18 PM, Mark Brown wrote:
> On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
>
>> The dw spi controller has an auto-deselect of Chip-Select, in case there is
>> no data inside the Tx FIFO. While working on platforms with Alpine chips,
> Why would we ever want to
On Wed, Oct 10, 2018 at 01:16:29PM +0200, luca abeni wrote:
> On Wed, 10 Oct 2018 12:57:10 +0200
> Peter Zijlstra wrote:
>
> > On Wed, Oct 10, 2018 at 12:34:17PM +0200, luca abeni wrote:
> > > So, I would propose to make the proxy() function of patch more
> > > generic, and not strictly bound to
On Wed, Oct 10, 2018 at 01:16:29PM +0200, luca abeni wrote:
> On Wed, 10 Oct 2018 12:57:10 +0200
> Peter Zijlstra wrote:
>
> > On Wed, Oct 10, 2018 at 12:34:17PM +0200, luca abeni wrote:
> > > So, I would propose to make the proxy() function of patch more
> > > generic, and not strictly bound to
Hi Mark,
Ok, thanks for your help
Best regards,
Chunhui Li
-邮件原件-
发件人: Mark Rutland [mailto:mark.rutl...@arm.com]
发送时间: 2018年10月10日 17:26
收件人: Chunhui Li (李春辉)
抄送: Catalin Marinas; Will Deacon; Matthias Brugger; Marc Zyngier; Ard
Biesheuvel; James Morse; Masahiro Yamada;
Hi Mark,
Ok, thanks for your help
Best regards,
Chunhui Li
-邮件原件-
发件人: Mark Rutland [mailto:mark.rutl...@arm.com]
发送时间: 2018年10月10日 17:26
收件人: Chunhui Li (李春辉)
抄送: Catalin Marinas; Will Deacon; Matthias Brugger; Marc Zyngier; Ard
Biesheuvel; James Morse; Masahiro Yamada;
On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
wrote:
>
> Hi,
>
>
> I see a bunch of vendor (or SoC) names in
> Documentation/device/bindings/arm/
>
> ./Documentation/devicetree/bindings/arm/altera
> ./Documentation/devicetree/bindings/arm/amlogic
Yeah, it's kind of a mixture of board/soc
On Wed, Oct 10, 2018 at 6:08 AM Masahiro Yamada
wrote:
>
> Hi,
>
>
> I see a bunch of vendor (or SoC) names in
> Documentation/device/bindings/arm/
>
> ./Documentation/devicetree/bindings/arm/altera
> ./Documentation/devicetree/bindings/arm/amlogic
Yeah, it's kind of a mixture of board/soc
Ilya Dryomov writes:
> On Wed, Oct 10, 2018 at 6:21 AM Yan, Zheng wrote:
>>
>> On Wed, Oct 10, 2018 at 1:54 AM Luis Henriques wrote:
>> Applied, thanks
>
> I don't think it should go to stable kernels. Strictly speaking it's
> a behaviour change -- it's been this way for many years and,
Ilya Dryomov writes:
> On Wed, Oct 10, 2018 at 6:21 AM Yan, Zheng wrote:
>>
>> On Wed, Oct 10, 2018 at 1:54 AM Luis Henriques wrote:
>> Applied, thanks
>
> I don't think it should go to stable kernels. Strictly speaking it's
> a behaviour change -- it's been this way for many years and,
On Wed, 10 Oct 2018 12:57:10 +0200
Peter Zijlstra wrote:
> On Wed, Oct 10, 2018 at 12:34:17PM +0200, luca abeni wrote:
> > So, I would propose to make the proxy() function of patch more
> > generic, and not strictly bound to mutexes. Maybe a task structure
> > can contain a list of tasks for
On Wed, 10 Oct 2018 12:57:10 +0200
Peter Zijlstra wrote:
> On Wed, Oct 10, 2018 at 12:34:17PM +0200, luca abeni wrote:
> > So, I would propose to make the proxy() function of patch more
> > generic, and not strictly bound to mutexes. Maybe a task structure
> > can contain a list of tasks for
Hi,
On Tue, 9 Oct 2018 11:24:31 +0200
Juri Lelli wrote:
[...]
> +migrate_task:
[...]
> + put_prev_task(rq, next);
> + if (rq->curr != rq->idle) {
> + rq->proxy = rq->idle;
> + set_tsk_need_resched(rq->idle);
> + /*
> + * XXX [juril] don't
Hi,
On Tue, 9 Oct 2018 11:24:31 +0200
Juri Lelli wrote:
[...]
> +migrate_task:
[...]
> + put_prev_task(rq, next);
> + if (rq->curr != rq->idle) {
> + rq->proxy = rq->idle;
> + set_tsk_need_resched(rq->idle);
> + /*
> + * XXX [juril] don't
Hi,
I see a bunch of vendor (or SoC) names in
Documentation/device/bindings/arm/
./Documentation/devicetree/bindings/arm/altera
./Documentation/devicetree/bindings/arm/amlogic
./Documentation/devicetree/bindings/arm/apm
./Documentation/devicetree/bindings/arm/bcm
Hi,
I see a bunch of vendor (or SoC) names in
Documentation/device/bindings/arm/
./Documentation/devicetree/bindings/arm/altera
./Documentation/devicetree/bindings/arm/amlogic
./Documentation/devicetree/bindings/arm/apm
./Documentation/devicetree/bindings/arm/bcm
On 10/10/18 12:43, luca abeni wrote:
> Hi,
>
> On Tue, 9 Oct 2018 11:24:29 +0200
> Juri Lelli wrote:
>
> > From: Peter Zijlstra
> >
> > Track the blocked-on relation for mutexes, this allows following this
> > relation at schedule time. Add blocked_task to track the inverse
> > relation.
> >
On 10/10/18 12:43, luca abeni wrote:
> Hi,
>
> On Tue, 9 Oct 2018 11:24:29 +0200
> Juri Lelli wrote:
>
> > From: Peter Zijlstra
> >
> > Track the blocked-on relation for mutexes, this allows following this
> > relation at schedule time. Add blocked_task to track the inverse
> > relation.
> >
Add the full text of the ISC license to the kernel tree. It was copied
directly from:
https://spdx.org/licenses/ISC.html
With the mention of "ISC" in the warranty disclaimer replaced with
"THE AUTHOR" as done in the ISC license headers used in the ath10k and
brcmfmac wifi drivers.
Cc: Kalle
Add the full text of the ISC license to the kernel tree. It was copied
directly from:
https://spdx.org/licenses/ISC.html
With the mention of "ISC" in the warranty disclaimer replaced with
"THE AUTHOR" as done in the ISC license headers used in the ath10k and
brcmfmac wifi drivers.
Cc: Kalle
The only reason we have the CDDL-1.0 license text around is for some
dual-licensed files from virtualbox. New code should not use this license.
Add a note about this and change the example tag to be dual-licensed.
Signed-off-by: Hans de Goede
---
LICENSES/other/CDDL-1.0 | 4 +++-
1 file
The only reason we have the CDDL-1.0 license text around is for some
dual-licensed files from virtualbox. New code should not use this license.
Add a note about this and change the example tag to be dual-licensed.
Signed-off-by: Hans de Goede
---
LICENSES/other/CDDL-1.0 | 4 +++-
1 file
On Wed, Oct 10, 2018 at 12:34:17PM +0200, luca abeni wrote:
> So, I would propose to make the proxy() function of patch more generic,
> and not strictly bound to mutexes. Maybe a task structure can contain a
> list of tasks for which the task can act as a proxy, and we can have a
> function like
On Wed, Oct 10, 2018 at 12:34:17PM +0200, luca abeni wrote:
> So, I would propose to make the proxy() function of patch more generic,
> and not strictly bound to mutexes. Maybe a task structure can contain a
> list of tasks for which the task can act as a proxy, and we can have a
> function like
On Montag, 8. Oktober 2018 23:09:04 CEST Colin King wrote:
> From: Colin Ian King
>
> The IIO_CHAN_INFO_SCALE case is missing a break statement and in
> the unlikely event that chan->address is not matched in the nested
> switch statement then the code falls through to the following
>
On Montag, 8. Oktober 2018 23:09:04 CEST Colin King wrote:
> From: Colin Ian King
>
> The IIO_CHAN_INFO_SCALE case is missing a break statement and in
> the unlikely event that chan->address is not matched in the nested
> switch statement then the code falls through to the following
>
Assend Agency & Recruitment
Looking for a job!!
Want to work abroad in the United Kingdom?
Job Offers available for periods of 6months to 1year
Jobs Available
Cleaners Wanted
Models Wanted
Bar Staffs Wanted
Builders Wanted
Cares Wanted
Accomodations and flight will be paid for the
Assend Agency & Recruitment
Looking for a job!!
Want to work abroad in the United Kingdom?
Job Offers available for periods of 6months to 1year
Jobs Available
Cleaners Wanted
Models Wanted
Bar Staffs Wanted
Builders Wanted
Cares Wanted
Accomodations and flight will be paid for the
Hi all,
There have been various issues and limitations with the way perf uses
(task) contexts to track events. Most notable is the single hardware PMU
task context, which has resulted in a number of yucky things (both
proposed and merged).
Notably:
- HW breakpoint PMU
- ARM big.little PMU
-
Hi all,
There have been various issues and limitations with the way perf uses
(task) contexts to track events. Most notable is the single hardware PMU
task context, which has resulted in a number of yucky things (both
proposed and merged).
Notably:
- HW breakpoint PMU
- ARM big.little PMU
-
On 2018/10/10 17:59, Michal Hocko wrote:
> On Wed 10-10-18 09:12:45, Tetsuo Handa wrote:
>> syzbot is hitting RCU stall due to memcg-OOM event.
>> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
>
> This is really interesting. If we do not have any eligible oom
On 2018/10/10 17:59, Michal Hocko wrote:
> On Wed 10-10-18 09:12:45, Tetsuo Handa wrote:
>> syzbot is hitting RCU stall due to memcg-OOM event.
>> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
>
> This is really interesting. If we do not have any eligible oom
Hi,
On Tue, 9 Oct 2018 11:24:29 +0200
Juri Lelli wrote:
> From: Peter Zijlstra
>
> Track the blocked-on relation for mutexes, this allows following this
> relation at schedule time. Add blocked_task to track the inverse
> relation.
>
> ,-> task
> | |
On Wed, Oct 10, 2018 at 6:21 AM Yan, Zheng wrote:
>
> On Wed, Oct 10, 2018 at 1:54 AM Luis Henriques wrote:
> >
> > Current implementation of cephfs fallocate isn't correct as it doesn't
> > really reserve the space in the cluster, which means that a subsequent
> > call to a write may actually
Hi,
On Tue, 9 Oct 2018 11:24:29 +0200
Juri Lelli wrote:
> From: Peter Zijlstra
>
> Track the blocked-on relation for mutexes, this allows following this
> relation at schedule time. Add blocked_task to track the inverse
> relation.
>
> ,-> task
> | |
On Wed, Oct 10, 2018 at 6:21 AM Yan, Zheng wrote:
>
> On Wed, Oct 10, 2018 at 1:54 AM Luis Henriques wrote:
> >
> > Current implementation of cephfs fallocate isn't correct as it doesn't
> > really reserve the space in the cluster, which means that a subsequent
> > call to a write may actually
The way we calculate free logbuf free space percentage
overflows signed integer:
int free;
free = __LOG_BUF_LEN - log_next_idx;
pr_info("early log buf free: %u(%u%%)\n",
free, (free * 100) / __LOG_BUF_LEN);
We support LOG_BUF_LEN of up to 2G, since
The way we calculate free logbuf free space percentage
overflows signed integer:
int free;
free = __LOG_BUF_LEN - log_next_idx;
pr_info("early log buf free: %u(%u%%)\n",
free, (free * 100) / __LOG_BUF_LEN);
We support LOG_BUF_LEN of up to 2G, since
On Wednesday 10 Oct 2018 at 12:14:32 (+0200), Vincent Guittot wrote:
> On Wed, 10 Oct 2018 at 11:55, Quentin Perret wrote:
> >
> > Hi Vincent,
> >
> > On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> > > The problem with reflecting directly the capping is that it happens
> >
On Wednesday 10 Oct 2018 at 12:14:32 (+0200), Vincent Guittot wrote:
> On Wed, 10 Oct 2018 at 11:55, Quentin Perret wrote:
> >
> > Hi Vincent,
> >
> > On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> > > The problem with reflecting directly the capping is that it happens
> >
> On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
>
>> The dw spi controller has an auto-deselect of Chip-Select, in case there is
>> no data inside the Tx FIFO. While working on platforms with Alpine chips,
> Why would we ever want to use this behaviour? It will be broken for any
> On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
>
>> The dw spi controller has an auto-deselect of Chip-Select, in case there is
>> no data inside the Tx FIFO. While working on platforms with Alpine chips,
> Why would we ever want to use this behaviour? It will be broken for any
Current dynamic burst length is based on the whole transfer length,
that's ok if there is only one sg, but is not right in case multi sgs
in one transfer,because the tail data should be based on the last sg
length instead of the whole transfer length. Move wml setting for DMA
to the later place,
Correct wml as the last rx sg length instead of the whole transfer
length. Otherwise, mtd_stresstest will be failed as below:
insmod mtd_stresstest.ko dev=0
=
mtd_stresstest: MTD device: 0
mtd_stresstest: not NAND flash, assume page size is 512
Use PIO mode instead if size is smaller than fifo size, since
dma may be less efficient.
Signed-off-by: Robin Gong
---
drivers/spi/spi-imx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 037abbb..dd1ce12 100644
---
Current dynamic burst length is based on the whole transfer length,
that's ok if there is only one sg, but is not right in case multi sgs
in one transfer,because the tail data should be based on the last sg
length instead of the whole transfer length. Othwise, the last dma
done interrupt will
Current dynamic burst length is based on the whole transfer length,
that's ok if there is only one sg, but is not right in case multi sgs
in one transfer,because the tail data should be based on the last sg
length instead of the whole transfer length. Othwise, the last dma
done interrupt will
Current dynamic burst length is based on the whole transfer length,
that's ok if there is only one sg, but is not right in case multi sgs
in one transfer,because the tail data should be based on the last sg
length instead of the whole transfer length. Move wml setting for DMA
to the later place,
Correct wml as the last rx sg length instead of the whole transfer
length. Otherwise, mtd_stresstest will be failed as below:
insmod mtd_stresstest.ko dev=0
=
mtd_stresstest: MTD device: 0
mtd_stresstest: not NAND flash, assume page size is 512
Use PIO mode instead if size is smaller than fifo size, since
dma may be less efficient.
Signed-off-by: Robin Gong
---
drivers/spi/spi-imx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 037abbb..dd1ce12 100644
---
On 09/10/18 17:06, Lukasz Luba wrote:
Hi Peter,
On 10/09/2018 05:43 PM, Peter Zijlstra wrote:
On Tue, Oct 09, 2018 at 05:39:27PM +0200, Lukasz Luba wrote:
This patch add some warning related to performance drop.
It should be mentioned that this is not for free
and the platfrom resources
On 09/10/18 17:06, Lukasz Luba wrote:
Hi Peter,
On 10/09/2018 05:43 PM, Peter Zijlstra wrote:
On Tue, Oct 09, 2018 at 05:39:27PM +0200, Lukasz Luba wrote:
This patch add some warning related to performance drop.
It should be mentioned that this is not for free
and the platfrom resources
On Tue, Oct 09, 2018 at 04:58:18PM +0100, Will Deacon wrote:
> On Tue, Oct 09, 2018 at 05:43:59PM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 09, 2018 at 05:39:27PM +0200, Lukasz Luba wrote:
> > > This patch add some warning related to performance drop.
> > > It should be mentioned that this is
On Tue, Oct 09, 2018 at 04:58:18PM +0100, Will Deacon wrote:
> On Tue, Oct 09, 2018 at 05:43:59PM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 09, 2018 at 05:39:27PM +0200, Lukasz Luba wrote:
> > > This patch add some warning related to performance drop.
> > > It should be mentioned that this is
On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
> The dw spi controller has an auto-deselect of Chip-Select, in case there is
> no data inside the Tx FIFO. While working on platforms with Alpine chips,
Why would we ever want to use this behaviour? It will be broken for any
On Wed, Oct 10, 2018 at 10:08:12AM +0300, Talel Shenhar wrote:
> The dw spi controller has an auto-deselect of Chip-Select, in case there is
> no data inside the Tx FIFO. While working on platforms with Alpine chips,
Why would we ever want to use this behaviour? It will be broken for any
On 2018/10/10 6:19, Tetsuo Handa wrote:
> Do you think that adding cmpxchg() & retry logic to this API generates better
> result than simple fallback? buffered_printk() does not add a new locking
> dependency
> is a good point of this API. Showing the backtrace (by enabling a debug
> kernel
On 2018/10/10 6:19, Tetsuo Handa wrote:
> Do you think that adding cmpxchg() & retry logic to this API generates better
> result than simple fallback? buffered_printk() does not add a new locking
> dependency
> is a good point of this API. Showing the backtrace (by enabling a debug
> kernel
On Wed, 10 Oct 2018 at 11:55, Quentin Perret wrote:
>
> Hi Vincent,
>
> On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> > The problem with reflecting directly the capping is that it happens
> > far more often than the pace at which cpu_capacity_orig is updated in
> > the
On Wed, 10 Oct 2018 at 11:55, Quentin Perret wrote:
>
> Hi Vincent,
>
> On Wednesday 10 Oct 2018 at 10:50:05 (+0200), Vincent Guittot wrote:
> > The problem with reflecting directly the capping is that it happens
> > far more often than the pace at which cpu_capacity_orig is updated in
> > the
On 09/10/2018 17:19, Laurent Vivier wrote:
> Le 09/10/2018 à 17:16, Tycho Andersen a écrit :
>> On Tue, Oct 09, 2018 at 12:37:52PM +0200, Laurent Vivier wrote:
>>> @@ -80,18 +74,32 @@ static int entry_count;
>>> */
>>> #define MAX_REGISTER_LENGTH 1920
>>>
>>> +static struct binfmt_namespace
On 09/10/2018 17:19, Laurent Vivier wrote:
> Le 09/10/2018 à 17:16, Tycho Andersen a écrit :
>> On Tue, Oct 09, 2018 at 12:37:52PM +0200, Laurent Vivier wrote:
>>> @@ -80,18 +74,32 @@ static int entry_count;
>>> */
>>> #define MAX_REGISTER_LENGTH 1920
>>>
>>> +static struct binfmt_namespace
On Wed, 10 Oct 2018 at 11:56, Lukasz Luba wrote:
>
> Hi Krzysztof,
>
> Is it still valid that the Exynos has locking issues?
The prepare lock of clocks was not solved entirely. We just
implemented a set of workarounds.
> Or is it enabled 'just-in-case'?
Yes, all debugging features are
On Wed, 10 Oct 2018 at 11:56, Lukasz Luba wrote:
>
> Hi Krzysztof,
>
> Is it still valid that the Exynos has locking issues?
The prepare lock of clocks was not solved entirely. We just
implemented a set of workarounds.
> Or is it enabled 'just-in-case'?
Yes, all debugging features are
On Tue, Oct 09, 2018 at 04:04:47PM -0700, Joel Fernandes wrote:
> On Wed, Oct 10, 2018 at 01:02:22AM +0300, Kirill A. Shutemov wrote:
> > On Tue, Oct 09, 2018 at 01:14:00PM -0700, Joel Fernandes (Google) wrote:
> > > Android needs to mremap large regions of memory during memory management
> > >
On Tue, Oct 09, 2018 at 04:04:47PM -0700, Joel Fernandes wrote:
> On Wed, Oct 10, 2018 at 01:02:22AM +0300, Kirill A. Shutemov wrote:
> > On Tue, Oct 09, 2018 at 01:14:00PM -0700, Joel Fernandes (Google) wrote:
> > > Android needs to mremap large regions of memory during memory management
> > >
On Wed, Oct 10, 2018 at 11:53 AM, Sebastian Andrzej Siewior
wrote:
> On 2018-10-10 11:45:32 [+0200], Dmitry Vyukov wrote:
>> > Should I repost Clark's patch?
>>
>>
>> I am much more comfortable with just changing the type of the lock.
>
> Yes, that is what Clark's patch does. Should I resent it?
On Wed, Oct 10, 2018 at 11:53 AM, Sebastian Andrzej Siewior
wrote:
> On 2018-10-10 11:45:32 [+0200], Dmitry Vyukov wrote:
>> > Should I repost Clark's patch?
>>
>>
>> I am much more comfortable with just changing the type of the lock.
>
> Yes, that is what Clark's patch does. Should I resent it?
On Wed, Oct 10, 2018 at 12:18:32AM -0700, Wendy Liang wrote:
> Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block
> in ZynqMP SoC used for the communication between various processor
> systems.
>
> Signed-off-by: Wendy Liang
[...]
> +Optional properties:
> +
>
On Wed, Oct 10, 2018 at 12:18:32AM -0700, Wendy Liang wrote:
> Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block
> in ZynqMP SoC used for the communication between various processor
> systems.
>
> Signed-off-by: Wendy Liang
[...]
> +Optional properties:
> +
>
Hi Krzysztof,
Is it still valid that the Exynos has locking issues?
Or is it enabled 'just-in-case'?
On arm64 the config misses that setting.
Should be enabled there as well?
You have introduced this entry a year ago, probably during bug
investigation.
The issue is in lockdep, the setting which
Hi Krzysztof,
Is it still valid that the Exynos has locking issues?
Or is it enabled 'just-in-case'?
On arm64 the config misses that setting.
Should be enabled there as well?
You have introduced this entry a year ago, probably during bug
investigation.
The issue is in lockdep, the setting which
1101 - 1200 of 1504 matches
Mail list logo
