[ANNOUNCE] 3.18.42-rt45

Dear RT Folks, I'm pleased to announce the 3.18.42-rt45 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.18-rt Head SHA1: 940c8067f2f58aab66fa27a6a64bd1d5eeecdab9 Or to build 3.18.42-rt45

[ANNOUNCE] 4.1.33-rt38

Dear RT Folks, I'm pleased to announce the 4.1.33-rt38 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.1-rt Head SHA1: 08c164be8174a7c236d0ff09a691571f1834b13d Or to build 4.1.33-rt38

Re: [PATCH] selftests/futex: Check ANSI terminal color support

On Sun, Oct 02, 2016 at 11:02:18AM +0900, SeongJae Park wrote: > Because test for color support of the running shell does not aware ANSI > type terminals, it does not print colorful messages on some environemnt. > This commit modifies the test to aware ANSI type terminal, too. > > Signed-off-by:

Re: [PATCH] selftests/futex: Check ANSI terminal color support

On Sun, Oct 02, 2016 at 11:02:18AM +0900, SeongJae Park wrote: > Because test for color support of the running shell does not aware ANSI > type terminals, it does not print colorful messages on some environemnt. > This commit modifies the test to aware ANSI type terminal, too. > > Signed-off-by:

Re: [PATCH] [media] : Removing warnings caught by checkpatch.pl

On Sun, Oct 02, 2016 at 02:30:45AM +0530, Harman Kalra wrote: > static int iss_video_queue_setup(struct vb2_queue *vq, > - unsigned int *count, unsigned int *num_planes, > - unsigned int sizes[], struct device > *alloc_devs[]) > +

Re: [PATCH] [media] : Removing warnings caught by checkpatch.pl

On Sun, Oct 02, 2016 at 02:30:45AM +0530, Harman Kalra wrote: > static int iss_video_queue_setup(struct vb2_queue *vq, > - unsigned int *count, unsigned int *num_planes, > - unsigned int sizes[], struct device > *alloc_devs[]) > +

Re: [PATCH v6] powerpc: Do not make the entire heap executable

On Mon, Oct 3, 2016 at 9:13 AM, Denys Vlasenko wrote: > On 32-bit powerpc the ELF PLT sections of binaries (built with --bss-plt, > or with a toolchain which defaults to it) look like this: > > [17] .sbss NOBITS 0002aff8 01aff8 14 00 WA 0 0 >

Re: [PATCH v6] powerpc: Do not make the entire heap executable

On Mon, Oct 3, 2016 at 9:13 AM, Denys Vlasenko wrote: > On 32-bit powerpc the ELF PLT sections of binaries (built with --bss-plt, > or with a toolchain which defaults to it) look like this: > > [17] .sbss NOBITS 0002aff8 01aff8 14 00 WA 0 0 > 4 > [18] .plt

Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer

HI Matt, On 16 August 2016 at 20:25, Matt Mullins wrote: > On Tue, Aug 16, 2016 at 12:19:42PM -0700, Yinghai Lu wrote: >> On Mon, Aug 15, 2016 at 9:01 PM, Matt Mullins wrote: >> > >> > This appears to have a negative effect on booting the Intel Edison >> >

Re: [PATCH 2/6] x86/boot: Move compressed kernel to end of decompression buffer

HI Matt, On 16 August 2016 at 20:25, Matt Mullins wrote: > On Tue, Aug 16, 2016 at 12:19:42PM -0700, Yinghai Lu wrote: >> On Mon, Aug 15, 2016 at 9:01 PM, Matt Mullins wrote: >> > >> > This appears to have a negative effect on booting the Intel Edison >> > platform, as >> > it uses u-boot as

ATENCIÓN;

ATENCIÓN; Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de

ATENCIÓN;

ATENCIÓN; Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de

[PATCH] hpfs: support FIEMAP

Support the FIEMAP ioctl that reports extents allocated by a file. Signed-off-by: Mikulas Patocka --- fs/hpfs/file.c |6 ++ 1 file changed, 6 insertions(+) Index: linux-2.6/fs/hpfs/file.c

[PATCH] hpfs: support FIEMAP

Support the FIEMAP ioctl that reports extents allocated by a file. Signed-off-by: Mikulas Patocka --- fs/hpfs/file.c |6 ++ 1 file changed, 6 insertions(+) Index: linux-2.6/fs/hpfs/file.c === ---

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Mon, Oct 3, 2016 at 2:21 PM, Rik van Riel wrote: > On Mon, 2016-10-03 at 13:54 -0700, Andy Lutomirski wrote: >> On Sat, Oct 1, 2016 at 5:08 PM, Rik van Riel wrote: >> > >> > On Sat, 2016-10-01 at 16:44 -0700, Andy Lutomirski wrote: >> > > >> > > On Sat, Oct

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Mon, Oct 3, 2016 at 2:21 PM, Rik van Riel wrote: > On Mon, 2016-10-03 at 13:54 -0700, Andy Lutomirski wrote: >> On Sat, Oct 1, 2016 at 5:08 PM, Rik van Riel wrote: >> > >> > On Sat, 2016-10-01 at 16:44 -0700, Andy Lutomirski wrote: >> > > >> > > On Sat, Oct 1, 2016 at 1:31 PM, wrote: >> > >

[PULL] Documentation for 4.9

[Note you'll get a small conflict with Documentation/sphinx-static/theme_overrides.css; just take the docs-4.9 side. That's entirely the result of me still figuring out the best fix-vs-features workflow, shouldn't happen again.] The following changes since commit

[PULL] Documentation for 4.9

[Note you'll get a small conflict with Documentation/sphinx-static/theme_overrides.css; just take the docs-4.9 side. That's entirely the result of me still figuring out the best fix-vs-features workflow, shouldn't happen again.] The following changes since commit

Re: [x86] 811565123a: BUG: kernel hang in early-boot stage, last printk: Probing EDD (edd=off to disable)... ok

On Sat, Oct 01, 2016 at 10:59:38AM +0800, kernel test robot wrote: > FYI, we noticed the following commit: > > https://github.com/0day-ci/linux > Andi-Kleen/x86-Report-Intel-platform_id-in-proc-cpuinfo/20160924-100841 > commit 811565123a194d9cc0b490719bef761e1730dbf4 ("x86: Report Intel >

Re: [x86] 811565123a: BUG: kernel hang in early-boot stage, last printk: Probing EDD (edd=off to disable)... ok

On Sat, Oct 01, 2016 at 10:59:38AM +0800, kernel test robot wrote: > FYI, we noticed the following commit: > > https://github.com/0day-ci/linux > Andi-Kleen/x86-Report-Intel-platform_id-in-proc-cpuinfo/20160924-100841 > commit 811565123a194d9cc0b490719bef761e1730dbf4 ("x86: Report Intel >

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Mon, 2016-10-03 at 13:54 -0700, Andy Lutomirski wrote: > On Sat, Oct 1, 2016 at 5:08 PM, Rik van Riel wrote: > > > > On Sat, 2016-10-01 at 16:44 -0700, Andy Lutomirski wrote: > > > > > > On Sat, Oct 1, 2016 at 1:31 PM,   wrote: > > > > > > > > > > > >  

[PATCH v3 02/11] block-throttle: add .high interface

Add high limit for cgroup and corresponding cgroup interface. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 139 +++ 1 file changed, 107 insertions(+), 32 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Mon, 2016-10-03 at 13:54 -0700, Andy Lutomirski wrote: > On Sat, Oct 1, 2016 at 5:08 PM, Rik van Riel wrote: > > > > On Sat, 2016-10-01 at 16:44 -0700, Andy Lutomirski wrote: > > > > > > On Sat, Oct 1, 2016 at 1:31 PM,   wrote: > > > > > > > > > > > >  #define CREATE_TRACE_POINTS > > > >  

[PATCH v3 02/11] block-throttle: add .high interface

Add high limit for cgroup and corresponding cgroup interface. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 139 +++ 1 file changed, 107 insertions(+), 32 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index

[PATCH v3 08/11] blk-throttle: detect completed idle cgroup

cgroup could be assigned a limit, but doesn't dispatch enough IO, eg the cgroup is idle. When this happens, the cgroup doesn't hit its limit, so we can't move the state machine to higher level and all cgroups will be throttled to thier lower limit, so we waste bandwidth. Detecting idle cgroup is

[PATCH v3 08/11] blk-throttle: detect completed idle cgroup

cgroup could be assigned a limit, but doesn't dispatch enough IO, eg the cgroup is idle. When this happens, the cgroup doesn't hit its limit, so we can't move the state machine to higher level and all cgroups will be throttled to thier lower limit, so we waste bandwidth. Detecting idle cgroup is

[PATCH v3 09/11] block-throttle: make bandwidth change smooth

When cgroups all reach high limit, cgroups can dispatch more IO. This could make some cgroups dispatch more IO but others not, and even some cgroups could dispatch less IO than their high limit. For example, cg1 high limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is 120M/s for the

[PATCH v3 09/11] block-throttle: make bandwidth change smooth

When cgroups all reach high limit, cgroups can dispatch more IO. This could make some cgroups dispatch more IO but others not, and even some cgroups could dispatch less IO than their high limit. For example, cg1 high limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is 120M/s for the

[PATCH v3 06/11] blk-throttle: make sure expire time isn't too big

cgroup could be throttled to a limit but when all cgroups cross high limit, queue enters a higher state and so the group should be throttled to a higher limit. It's possible the cgroup is sleeping because of throttle and other cgroups don't dispatch IO any more. In this case, nobody can trigger

[PATCH v3 05/11] block-throttle: add downgrade logic

When queue state machine is in LIMIT_MAX state, but a cgroup is below its high limit for some time, the queue should be downgraded to lower state as one cgroup's high limit isn't met. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 187

[PATCH v3 05/11] block-throttle: add downgrade logic

When queue state machine is in LIMIT_MAX state, but a cgroup is below its high limit for some time, the queue should be downgraded to lower state as one cgroup's high limit isn't met. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 187 +++ 1

[PATCH v3 06/11] blk-throttle: make sure expire time isn't too big

cgroup could be throttled to a limit but when all cgroups cross high limit, queue enters a higher state and so the group should be throttled to a higher limit. It's possible the cgroup is sleeping because of throttle and other cgroups don't dispatch IO any more. In this case, nobody can trigger

[PATCH v3 07/11] blk-throttle: make throtl_slice tunable

throtl_slice is important for blk-throttling. A lot of stuffes depend on it, for example, throughput measurement. It has 100ms default value, which is not appropriate for all disks. For example, for SSD we might use a smaller value to make the throughput smoother. This patch makes it tunable.

[PATCH v3 03/11] block-throttle: configure bps/iops limit for cgroup in high limit

each queue will have a state machine. Initially queue is in LIMIT_HIGH state, which means all cgroups will be throttled according to their high limit. After all cgroups with high limit cross the limit, the queue state gets upgraded to LIMIT_MAX state. cgroups without high limit will use max limit

[PATCH v3 04/11] block-throttle: add upgrade logic for LIMIT_HIGH state

When queue is in LIMIT_HIGH state and all cgroups with high limit cross the bps/iops limitation, we will upgrade queue's state to LIMIT_MAX For a cgroup hierarchy, there are two cases. Children has lower high limit than parent. Parent's high limit is meaningless. If children's bps/iops cross high

[PATCH v3 01/11] block-throttle: prepare support multiple limits

We are going to support high/max limit, each cgroup will have 2 limits after that. This patch prepares for the multiple limits change. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 109 --- 1 file changed, 68 insertions(+), 41

[PATCH v3 07/11] blk-throttle: make throtl_slice tunable

throtl_slice is important for blk-throttling. A lot of stuffes depend on it, for example, throughput measurement. It has 100ms default value, which is not appropriate for all disks. For example, for SSD we might use a smaller value to make the throughput smoother. This patch makes it tunable.

[PATCH v3 03/11] block-throttle: configure bps/iops limit for cgroup in high limit

each queue will have a state machine. Initially queue is in LIMIT_HIGH state, which means all cgroups will be throttled according to their high limit. After all cgroups with high limit cross the limit, the queue state gets upgraded to LIMIT_MAX state. cgroups without high limit will use max limit

[PATCH v3 01/11] block-throttle: prepare support multiple limits

We are going to support high/max limit, each cgroup will have 2 limits after that. This patch prepares for the multiple limits change. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 109 --- 1 file changed, 68 insertions(+), 41 deletions(-)

[PATCH v3 04/11] block-throttle: add upgrade logic for LIMIT_HIGH state

When queue is in LIMIT_HIGH state and all cgroups with high limit cross the bps/iops limitation, we will upgrade queue's state to LIMIT_MAX For a cgroup hierarchy, there are two cases. Children has lower high limit than parent. Parent's high limit is meaningless. If children's bps/iops cross high

[PATCH v3 11/11] blk-throttle: ignore idle cgroup limit

Last patch introduces a way to detect idle cgroup. We use it to make upgrade/downgrade decision. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 31 +++ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/block/blk-throttle.c

[PATCH v3 11/11] blk-throttle: ignore idle cgroup limit

Last patch introduces a way to detect idle cgroup. We use it to make upgrade/downgrade decision. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 31 +++ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c

[PATCH V3 00/11] block-throttle: add .high limit

Hi, The background is we don't have an ioscheduler for blk-mq yet, so we can't prioritize processes/cgroups. This patch set tries to add basic arbitration between cgroups with blk-throttle. It adds a new limit io.high for blk-throttle. It's only for cgroup2. io.max is a hard limit throttling.

[PATCH V3 00/11] block-throttle: add .high limit

Hi, The background is we don't have an ioscheduler for blk-mq yet, so we can't prioritize processes/cgroups. This patch set tries to add basic arbitration between cgroups with blk-throttle. It adds a new limit io.high for blk-throttle. It's only for cgroup2. io.max is a hard limit throttling.

[PATCH v3 10/11] block-throttle: add a simple idle detection

A cgroup gets assigned a high limit, but the cgroup could never dispatch enough IO to cross the high limit. In such case, the queue state machine will remain in LIMIT_HIGH state and all other cgroups will be throttled according to high limit. This is unfair for other cgroups. We should treat the

[PATCH v3 10/11] block-throttle: add a simple idle detection

A cgroup gets assigned a high limit, but the cgroup could never dispatch enough IO to cross the high limit. In such case, the queue state machine will remain in LIMIT_HIGH state and all other cgroups will be throttled according to high limit. This is unfair for other cgroups. We should treat the

Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support

On Fri, Sep 30, 2016 at 02:56:27AM -0700, Christoph Hellwig wrote: > > -/* > > - * We use lowest available bit in exceptional entry for locking, other two > > - * bits to determine entry type. In total 3 special bits. > > - */ > > -#define RADIX_DAX_SHIFT(RADIX_TREE_EXCEPTIONAL_SHIFT + 3) > >

Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support

On Fri, Sep 30, 2016 at 02:56:27AM -0700, Christoph Hellwig wrote: > > -/* > > - * We use lowest available bit in exceptional entry for locking, other two > > - * bits to determine entry type. In total 3 special bits. > > - */ > > -#define RADIX_DAX_SHIFT(RADIX_TREE_EXCEPTIONAL_SHIFT + 3) > >

[RFC v4 2/2] usb: typec: Type-C Port Controller Interface driver (tcpci)

The port controller interface driver interconnects the Type-C Port Manager with a Type-C Port Controller Interface (TCPCI) compliant port controller. Signed-off-by: Guenter Roeck --- v4: - Fix RP value set for ports supporting 3A current - Implement support for DRP toggling

[RFC v4 2/2] usb: typec: Type-C Port Controller Interface driver (tcpci)

The port controller interface driver interconnects the Type-C Port Manager with a Type-C Port Controller Interface (TCPCI) compliant port controller. Signed-off-by: Guenter Roeck --- v4: - Fix RP value set for ports supporting 3A current - Implement support for DRP toggling in hardware - When

Re: [PATCH v4 00/12] re-enable DAX PMD support

On Fri, Sep 30, 2016 at 04:48:58PM +1000, Dave Chinner wrote: > On Thu, Sep 29, 2016 at 09:03:43PM -0600, Ross Zwisler wrote: > > On Fri, Sep 30, 2016 at 09:43:45AM +1000, Dave Chinner wrote: > > > Finally: none of the patches in your tree have reviewed-by tags. > > > That says to me that none of

Re: [PATCH v4 00/12] re-enable DAX PMD support

On Fri, Sep 30, 2016 at 04:48:58PM +1000, Dave Chinner wrote: > On Thu, Sep 29, 2016 at 09:03:43PM -0600, Ross Zwisler wrote: > > On Fri, Sep 30, 2016 at 09:43:45AM +1000, Dave Chinner wrote: > > > Finally: none of the patches in your tree have reviewed-by tags. > > > That says to me that none of

[RFC v4 1/2] usb: typec: USB Type-C Port Manager (tcpm)

This driver implements the USB Type-C Power Delivery state machine for both source and sink ports. Alternate mode support is not fully implemented. The driver attaches to the USB Type-C class code implemented in the following patches. usb: typec: add driver for Intel Whiskey Cove PMIC

[RFC v4 1/2] usb: typec: USB Type-C Port Manager (tcpm)

This driver implements the USB Type-C Power Delivery state machine for both source and sink ports. Alternate mode support is not fully implemented. The driver attaches to the USB Type-C class code implemented in the following patches. usb: typec: add driver for Intel Whiskey Cove PMIC

[RFC v4 0/2] USB Type-C Port Manager

The following series of patches implements a USB Type-C Port Manager using the pending USB Type-C class code as basis. The code is still WIP, but I think it is important to get feedback from the community at this point. There are two patches in the series. The first patch implements the Type-C

[RFC v4 0/2] USB Type-C Port Manager

The following series of patches implements a USB Type-C Port Manager using the pending USB Type-C class code as basis. The code is still WIP, but I think it is important to get feedback from the community at this point. There are two patches in the series. The first patch implements the Type-C

Re: [Nbd] [PATCH][V3] nbd: add multi-connection support

Alex, Christoph, On Mon, Oct 03, 2016 at 12:34:33PM +0100, Alex Bligh wrote: > On 3 Oct 2016, at 08:57, Christoph Hellwig wrote: > >> Can you clarify what you mean by that? Why is it an "odd flush > >> definition", and how would you "properly" define it? > > > > E.g. take

Re: [Nbd] [PATCH][V3] nbd: add multi-connection support

Alex, Christoph, On Mon, Oct 03, 2016 at 12:34:33PM +0100, Alex Bligh wrote: > On 3 Oct 2016, at 08:57, Christoph Hellwig wrote: > >> Can you clarify what you mean by that? Why is it an "odd flush > >> definition", and how would you "properly" define it? > > > > E.g. take the defintion from

Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support

On Mon, Oct 03, 2016 at 12:59:49PM +0200, Jan Kara wrote: > On Thu 29-09-16 16:49:28, Ross Zwisler wrote: > > @@ -420,15 +439,39 @@ restart: > > mapping_gfp_mask(mapping) & ~__GFP_HIGHMEM); > > if (err) > > return ERR_PTR(err); > > -

Re: [PATCH v4 10/12] dax: add struct iomap based DAX PMD support

On Mon, Oct 03, 2016 at 12:59:49PM +0200, Jan Kara wrote: > On Thu 29-09-16 16:49:28, Ross Zwisler wrote: > > @@ -420,15 +439,39 @@ restart: > > mapping_gfp_mask(mapping) & ~__GFP_HIGHMEM); > > if (err) > > return ERR_PTR(err); > > -

Re: [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use

On Mon, May 2, 2016 at 5:52 PM, Andreas Dilger wrote: > On Apr 29, 2016, at 6:58 AM, David Howells wrote: >> >> Make windows attributes available for CIFS, NTFS and FAT to use in the >> statx struct. The attribute flags map directly by value to those in

Re: [PATCH 5/6] statx: Make windows attributes available for CIFS, NTFS and FAT to use

On Mon, May 2, 2016 at 5:52 PM, Andreas Dilger wrote: > On Apr 29, 2016, at 6:58 AM, David Howells wrote: >> >> Make windows attributes available for CIFS, NTFS and FAT to use in the >> statx struct. The attribute flags map directly by value to those in the >> CIFS PDU flags. Some of these

Re: [PATCH] spmi: regmap: enable userspace writes

On 09/30, kgu...@codeaurora.org wrote: > On 2016-09-29 23:30, Mark Brown wrote: > >On Thu, Sep 29, 2016 at 05:06:26PM +0530, Kiran Gunda wrote: > > > >>-#undef REGMAP_ALLOW_WRITE_DEBUGFS > >>+#define REGMAP_ALLOW_WRITE_DEBUGFS > > > >This is completely inappropriate for upstream, if you need to do

Re: [PATCH] spmi: regmap: enable userspace writes

On 09/30, kgu...@codeaurora.org wrote: > On 2016-09-29 23:30, Mark Brown wrote: > >On Thu, Sep 29, 2016 at 05:06:26PM +0530, Kiran Gunda wrote: > > > >>-#undef REGMAP_ALLOW_WRITE_DEBUGFS > >>+#define REGMAP_ALLOW_WRITE_DEBUGFS > > > >This is completely inappropriate for upstream, if you need to do

Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded

On Mon, 2016-10-03 at 13:49 -0700, Dave Hansen wrote: > On 10/03/2016 01:22 PM, Rik van Riel wrote: > > > > > > > > > > > > > What are the preempt rules with this thing?  This needs to be > > > > called > > > > in preempt-disabled contexts, right? > > Indeed, all the FPU context switching code

Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded

On Mon, 2016-10-03 at 13:49 -0700, Dave Hansen wrote: > On 10/03/2016 01:22 PM, Rik van Riel wrote: > > > > > > > > > > > > > What are the preempt rules with this thing?  This needs to be > > > > called > > > > in preempt-disabled contexts, right? > > Indeed, all the FPU context switching code

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Sat, Oct 1, 2016 at 5:08 PM, Rik van Riel wrote: > On Sat, 2016-10-01 at 16:44 -0700, Andy Lutomirski wrote: >> On Sat, Oct 1, 2016 at 1:31 PM, wrote: >> > >> > #define CREATE_TRACE_POINTS >> > #include >> > @@ -197,6 +198,9 @@ __visible inline void >> >

Re: [PATCH RFC 2/5] x86,fpu: delay FPU register loading until switch to userspace

On Sat, Oct 1, 2016 at 5:08 PM, Rik van Riel wrote: > On Sat, 2016-10-01 at 16:44 -0700, Andy Lutomirski wrote: >> On Sat, Oct 1, 2016 at 1:31 PM, wrote: >> > >> > #define CREATE_TRACE_POINTS >> > #include >> > @@ -197,6 +198,9 @@ __visible inline void >> > prepare_exit_to_usermode(struct

Re: [PATCH] pinctrl: qcom: fix masking of pinmux functions

On Mon, Oct 3, 2016 at 6:31 AM, Linus Walleij wrote: > On Mon, Sep 26, 2016 at 5:52 PM, Bjorn Andersson > wrote: >> On Sun 25 Sep 23:36 PDT 2016, Stephen Boyd wrote: >> >>> On Mon, Sep 12, 2016 at 2:36 AM, John Crispin

Re: [PATCH] pinctrl: qcom: fix masking of pinmux functions

On Mon, Oct 3, 2016 at 6:31 AM, Linus Walleij wrote: > On Mon, Sep 26, 2016 at 5:52 PM, Bjorn Andersson > wrote: >> On Sun 25 Sep 23:36 PDT 2016, Stephen Boyd wrote: >> >>> On Mon, Sep 12, 2016 at 2:36 AM, John Crispin wrote: >>> > The following commit introduced a regression by not properly

Re: [PATCH v21 06/19] perf, tools: Support alias descriptions

Em Wed, Sep 28, 2016 at 11:29:16AM -0700, Sukadev Bhattiprolu escreveu: > Arnaldo Carvalho de Melo [a...@kernel.org] wrote: > > Em Tue, Sep 27, 2016 at 11:11:16AM -0700, Sukadev Bhattiprolu escreveu: > > > Arnaldo Carvalho de Melo [a...@kernel.org] wrote: > > > > Em Thu, Sep 15, 2016 at 03:24:43PM

Re: [PATCH v21 06/19] perf, tools: Support alias descriptions

Em Wed, Sep 28, 2016 at 11:29:16AM -0700, Sukadev Bhattiprolu escreveu: > Arnaldo Carvalho de Melo [a...@kernel.org] wrote: > > Em Tue, Sep 27, 2016 at 11:11:16AM -0700, Sukadev Bhattiprolu escreveu: > > > Arnaldo Carvalho de Melo [a...@kernel.org] wrote: > > > > Em Thu, Sep 15, 2016 at 03:24:43PM

Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded

On 10/03/2016 01:22 PM, Rik van Riel wrote: >> > What are the preempt rules with this thing? This needs to be called >> > in preempt-disabled contexts, right? > Indeed, all the FPU context switching code needs > to be called in preempt-disabled contexts. > > You do not want to get preempted

Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded

On 10/03/2016 01:22 PM, Rik van Riel wrote: >> > What are the preempt rules with this thing? This needs to be called >> > in preempt-disabled contexts, right? > Indeed, all the FPU context switching code needs > to be called in preempt-disabled contexts. > > You do not want to get preempted

Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded

On Mon, 2016-10-03 at 13:04 -0700, Dave Hansen wrote: > On 10/01/2016 01:31 PM, r...@redhat.com wrote: > > > >  /* > > + * Check whether an FPU's register set is still loaded in the CPU. > > + */ > > +static inline bool fpu_lazy_skip_restore(struct fpu *fpu) > > +{ > > + bool still_loaded =

Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded

On Mon, 2016-10-03 at 13:04 -0700, Dave Hansen wrote: > On 10/01/2016 01:31 PM, r...@redhat.com wrote: > > > >  /* > > + * Check whether an FPU's register set is still loaded in the CPU. > > + */ > > +static inline bool fpu_lazy_skip_restore(struct fpu *fpu) > > +{ > > + bool still_loaded =

Re: BUG: scheduling while atomic in f_fs when gadget remove driver

On Mon, Oct 3, 2016 at 1:07 PM, Michal Nazarewicz wrote: > On Mon, Oct 03 2016, John Stultz wrote: >> On Wed, Sep 28, 2016 at 2:38 PM, Michal Nazarewicz wrote: >>> On Wed, Sep 28 2016, Michal Nazarewicz wrote: With that done, the only thing which needs

Re: BUG: scheduling while atomic in f_fs when gadget remove driver

On Mon, Oct 3, 2016 at 1:07 PM, Michal Nazarewicz wrote: > On Mon, Oct 03 2016, John Stultz wrote: >> On Wed, Sep 28, 2016 at 2:38 PM, Michal Nazarewicz wrote: >>> On Wed, Sep 28 2016, Michal Nazarewicz wrote: With that done, the only thing which needs a mutex is epfile->read_buffer.

[PATCH v4 7/7] i2c: bcm2835: Add support for dynamic clock

Support a dynamic clock by reading the frequency and setting the divisor in the transfer function instead of during probe. Signed-off-by: Noralf Trønnes Reviewed-by: Martin Sperl --- drivers/i2c/busses/i2c-bcm2835.c | 51

Re: BUG: scheduling while atomic in f_fs when gadget remove driver

On Mon, Oct 03 2016, John Stultz wrote: > On Wed, Sep 28, 2016 at 2:38 PM, Michal Nazarewicz wrote: >> On Wed, Sep 28 2016, Michal Nazarewicz wrote: >>> With that done, the only thing which needs a mutex is >>> epfile->read_buffer. >> >> Perhaps this would do: >> >> >8

[PATCH v4 5/7] i2c: bcm2835: Add support for Repeated Start Condition

Documentation/i2c/i2c-protocol states that Combined transactions should separate messages with a Start bit and end the whole transaction with a Stop bit. This patch adds support for issuing only a Start between messages instead of a Stop followed by a Start. This implementation differs from

[PATCH v4 7/7] i2c: bcm2835: Add support for dynamic clock

Support a dynamic clock by reading the frequency and setting the divisor in the transfer function instead of during probe. Signed-off-by: Noralf Trønnes Reviewed-by: Martin Sperl --- drivers/i2c/busses/i2c-bcm2835.c | 51 +--- 1 file changed, 32

Re: BUG: scheduling while atomic in f_fs when gadget remove driver

On Mon, Oct 03 2016, John Stultz wrote: > On Wed, Sep 28, 2016 at 2:38 PM, Michal Nazarewicz wrote: >> On Wed, Sep 28 2016, Michal Nazarewicz wrote: >>> With that done, the only thing which needs a mutex is >>> epfile->read_buffer. >> >> Perhaps this would do: >> >> >8

[PATCH v4 5/7] i2c: bcm2835: Add support for Repeated Start Condition

Documentation/i2c/i2c-protocol states that Combined transactions should separate messages with a Start bit and end the whole transaction with a Stop bit. This patch adds support for issuing only a Start between messages instead of a Stop followed by a Start. This implementation differs from

[PATCH v4 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts

If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0), the driver has no way to fill/drain the FIFO to stop the interrupts. In this case the controller has to be disabled and the transfer completed to avoid hang. (CLKT | ERR) and DONE interrupts are completed in their own paths,

[PATCH v4 4/7] i2c: bcm2835: Can't support I2C_M_IGNORE_NAK

The controller can't support this flag, so remove it. Documentation/i2c/i2c-protocol states that all of the message is sent: I2C_M_IGNORE_NAK: Normally message is interrupted immediately if there is [NA] from the client. Setting this flag treats any [NA] as [A], and all of message is

[PATCH v4 2/7] i2c: bcm2835: Protect against unexpected TXW/RXR interrupts

If an unexpected TXW or RXR interrupt occurs (msg_buf_remaining == 0), the driver has no way to fill/drain the FIFO to stop the interrupts. In this case the controller has to be disabled and the transfer completed to avoid hang. (CLKT | ERR) and DONE interrupts are completed in their own paths,

[PATCH v4 4/7] i2c: bcm2835: Can't support I2C_M_IGNORE_NAK

The controller can't support this flag, so remove it. Documentation/i2c/i2c-protocol states that all of the message is sent: I2C_M_IGNORE_NAK: Normally message is interrupted immediately if there is [NA] from the client. Setting this flag treats any [NA] as [A], and all of message is

[PATCH v4 6/7] i2c: bcm2835: Support i2c-dev ioctl I2C_TIMEOUT

Use i2c_adapter->timeout for the completion timeout value. The core default is 1 second. Signed-off-by: Noralf Trønnes Reviewed-by: Eric Anholt --- drivers/i2c/busses/i2c-bcm2835.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH v4 6/7] i2c: bcm2835: Support i2c-dev ioctl I2C_TIMEOUT

Use i2c_adapter->timeout for the completion timeout value. The core default is 1 second. Signed-off-by: Noralf Trønnes Reviewed-by: Eric Anholt --- drivers/i2c/busses/i2c-bcm2835.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-bcm2835.c

[PATCH v4 3/7] i2c: bcm2835: Use dev_dbg logging on transfer errors

Writing to an AT24C32 generates on average 2x i2c transfer errors per 32-byte page write. Which amounts to a lot for a 4k write. This is due to the fact that the chip doesn't respond during it's internal write cycle when the at24 driver tries and retries the next write. Only a handful drivers use

[PATCH v4 0/7] i2c: bcm2835: Bring in changes from downstream

This patchset tries to bring in the lessons learned in the downstream driver i2c-bcm2708. The downstream clock stretcing timeout patch has been left out since clock stretching is broken/unreliable on this controller, so no point in setting it. Changes since version 3: - Add comment about

[PATCH v4 1/7] i2c: bcm2835: Fix hang for writing messages larger than 16 bytes

Writing messages larger than the FIFO size results in a hang, rendering the machine unusable. This is because the RXD status flag is set on the first interrupt which results in bcm2835_drain_rxfifo() stealing bytes from the buffer. The controller continues to trigger interrupts waiting for the

[PATCH v4 0/7] i2c: bcm2835: Bring in changes from downstream

This patchset tries to bring in the lessons learned in the downstream driver i2c-bcm2708. The downstream clock stretcing timeout patch has been left out since clock stretching is broken/unreliable on this controller, so no point in setting it. Changes since version 3: - Add comment about

[PATCH v4 1/7] i2c: bcm2835: Fix hang for writing messages larger than 16 bytes

Writing messages larger than the FIFO size results in a hang, rendering the machine unusable. This is because the RXD status flag is set on the first interrupt which results in bcm2835_drain_rxfifo() stealing bytes from the buffer. The controller continues to trigger interrupts waiting for the

[PATCH v4 3/7] i2c: bcm2835: Use dev_dbg logging on transfer errors

Writing to an AT24C32 generates on average 2x i2c transfer errors per 32-byte page write. Which amounts to a lot for a 4k write. This is due to the fact that the chip doesn't respond during it's internal write cycle when the at24 driver tries and retries the next write. Only a handful drivers use

Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded

On 10/01/2016 01:31 PM, r...@redhat.com wrote: > /* > + * Check whether an FPU's register set is still loaded in the CPU. > + */ > +static inline bool fpu_lazy_skip_restore(struct fpu *fpu) > +{ > + bool still_loaded = (fpu->fpstate_active && > + fpu->last_cpu ==

Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded

On 10/01/2016 01:31 PM, r...@redhat.com wrote: > /* > + * Check whether an FPU's register set is still loaded in the CPU. > + */ > +static inline bool fpu_lazy_skip_restore(struct fpu *fpu) > +{ > + bool still_loaded = (fpu->fpstate_active && > + fpu->last_cpu ==

ATENCIÓN;

ATENCIÓN; Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de

ATENCIÓN;

ATENCIÓN; Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de

<    1   2   3   4   5   6   7   8   9   10   >