Re: Is Documentation/networking/phy.txt still up-to-date?

On 11/09/2016 05:24 AM, Sebastian Frias wrote: > Hi, > > Documentation/networking/phy.txt discusses phy_connect and states that: > > "... > > interface is a u32 which specifies the connection type used > between the controller and the PHY. Examples are GMII, MII, > RGMII, and SGMII. For a

Re: Is Documentation/networking/phy.txt still up-to-date?

On 11/09/2016 05:24 AM, Sebastian Frias wrote: > Hi, > > Documentation/networking/phy.txt discusses phy_connect and states that: > > "... > > interface is a u32 which specifies the connection type used > between the controller and the PHY. Examples are GMII, MII, > RGMII, and SGMII. For a

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

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 NOBITS 0002b00c 01aff8 84 00 WAX 0 0 4

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

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 NOBITS 0002b00c 01aff8 84 00 WAX 0 0 4

Re: [PATCH] net/mlx4_en: Fix bpf_prog_add ref_cnt in mlx4

On Wed, Nov 09, 2016 at 10:57:32AM +0100, Daniel Borkmann wrote: > On 11/09/2016 10:45 AM, Zhiyi Sun wrote: > >On Wed, Nov 09, 2016 at 10:05:31AM +0100, Daniel Borkmann wrote: > >>On 11/09/2016 08:35 AM, Zhiyi Sun wrote: > >>>There are rx_ring_num queues. Each queue will load xdp prog. So >

Re: [PATCH] net/mlx4_en: Fix bpf_prog_add ref_cnt in mlx4

On Wed, Nov 09, 2016 at 10:57:32AM +0100, Daniel Borkmann wrote: > On 11/09/2016 10:45 AM, Zhiyi Sun wrote: > >On Wed, Nov 09, 2016 at 10:05:31AM +0100, Daniel Borkmann wrote: > >>On 11/09/2016 08:35 AM, Zhiyi Sun wrote: > >>>There are rx_ring_num queues. Each queue will load xdp prog. So >

Re: Summary of LPC guest MSI discussion in Santa Fe

On Tue, Nov 08, 2016 at 09:52:33PM -0500, Don Dutile wrote: > On 11/08/2016 06:35 PM, Alex Williamson wrote: > >On Tue, 8 Nov 2016 21:29:22 +0100 > >Christoffer Dall wrote: > >>Is my understanding correct, that you need to tell userspace about the > >>location of the

Re: Summary of LPC guest MSI discussion in Santa Fe

On Tue, Nov 08, 2016 at 09:52:33PM -0500, Don Dutile wrote: > On 11/08/2016 06:35 PM, Alex Williamson wrote: > >On Tue, 8 Nov 2016 21:29:22 +0100 > >Christoffer Dall wrote: > >>Is my understanding correct, that you need to tell userspace about the > >>location of the doorbell (in the IOVA space)

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

On 11/09/2016 05:02 AM, Sebastian Frias wrote: > On 11/04/2016 05:49 PM, Måns Rullgård wrote: But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers will apply the delay. I think a better way of dealing with this is that both, PHY and MAC drivers exchange

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

On 11/09/2016 05:02 AM, Sebastian Frias wrote: > On 11/04/2016 05:49 PM, Måns Rullgård wrote: But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers will apply the delay. I think a better way of dealing with this is that both, PHY and MAC drivers exchange

Re: [PATCH 0/2] PCI: Add quirk for Fintek F81504/508/512 on Skylake

Hi Peter, On Mon, Nov 07, 2016 at 05:22:30PM +0800, Ji-Ze Hong (Peter Hong) wrote: > We had tested Fintek F81504/508/512 PCIe-to-UART/GPIO on Intel Skylake > platform. It's maybe flood AER correctable error interrupt and slow down > the system boot. It's the same issue about below link: >

Re: [PATCH 0/2] PCI: Add quirk for Fintek F81504/508/512 on Skylake

Hi Peter, On Mon, Nov 07, 2016 at 05:22:30PM +0800, Ji-Ze Hong (Peter Hong) wrote: > We had tested Fintek F81504/508/512 PCIe-to-UART/GPIO on Intel Skylake > platform. It's maybe flood AER correctable error interrupt and slow down > the system boot. It's the same issue about below link: >

Re: [PATCH 22/25] x86/mcheck: Do the init in one place

On Wed, Nov 09, 2016 at 05:24:51PM +0100, Sebastian Andrzej Siewior wrote: > The behaviour was not changed - it was only reorganized to keep in one > spot. So there's the full CPU init path down cpu_up() -> ... -> identify_cpu() where mcheck_cpu_init() is called and then there's also the hotplug

Re: [PATCH 22/25] x86/mcheck: Do the init in one place

On Wed, Nov 09, 2016 at 05:24:51PM +0100, Sebastian Andrzej Siewior wrote: > The behaviour was not changed - it was only reorganized to keep in one > spot. So there's the full CPU init path down cpu_up() -> ... -> identify_cpu() where mcheck_cpu_init() is called and then there's also the hotplug

[PATCH] ASoC: fix platform_no_drv_owner.cocci warnings

sound/soc/codecs/cs42l42.c:1972:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci CC: James Schulman Signed-off-by: Fengguang Wu

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom > wrote: > >> Well, had to drop it again since it didn't compile: > >> > >> > >> CC [M] drivers/gpu/drm/drm_blend.o > >> drivers/gpu/drm/drm_atomic.c: In

[PATCH] ASoC: fix platform_no_drv_owner.cocci warnings

sound/soc/codecs/cs42l42.c:1972:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci CC: James Schulman Signed-off-by: Fengguang Wu --- cs42l42.c |1 - 1

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom > wrote: > >> Well, had to drop it again since it didn't compile: > >> > >> > >> CC [M] drivers/gpu/drm/drm_blend.o > >> drivers/gpu/drm/drm_atomic.c: In function

sched/autogroup: race if !sysctl_sched_autogroup_enabled ?

I am trying to investigate a bug-report which looks as an autogroup bug, and it seems I found the race which _might_ explain the problem. I'll try to make the fix tomorrow but could you confirm I got it right and answer the question below? Let's look at task_wants_autogroup() /*

sched/autogroup: race if !sysctl_sched_autogroup_enabled ?

I am trying to investigate a bug-report which looks as an autogroup bug, and it seems I found the race which _might_ explain the problem. I'll try to make the fix tomorrow but could you confirm I got it right and answer the question below? Let's look at task_wants_autogroup() /*

Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote: > > > > And Samsung. > > Shall I create the immutable branch now? > > Arnd: are you happy with the new patches and changes? I still had some comments for patch 7, but that shouldn't stop you from creating a branch for the

Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote: > > > > And Samsung. > > Shall I create the immutable branch now? > > Arnd: are you happy with the new patches and changes? I still had some comments for patch 7, but that shouldn't stop you from creating a branch for the

RE: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks

Hi Stephen, >> >> On 11/05/2016 01:48 AM, 'Stephen Boyd' wrote: >> > Well I'm also curious which case is failing. Does turning on the >> > clocks work after the gdsc is enabled? Does turning off the >> > clocks fail because we don't know when the gdsc has turned off? I >> > would hope that the

RE: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks

Hi Stephen, >> >> On 11/05/2016 01:48 AM, 'Stephen Boyd' wrote: >> > Well I'm also curious which case is failing. Does turning on the >> > clocks work after the gdsc is enabled? Does turning off the >> > clocks fail because we don't know when the gdsc has turned off? I >> > would hope that the

Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus

On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote: > v2: > - Drop SoC families and family names; use fixed "Renesas" instead, I think I'd rather have seen the family names left in there, but it's not important, so up to you. > - Use "renesas,prr" and "renesas,cccr" device

Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus

On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote: > v2: > - Drop SoC families and family names; use fixed "Renesas" instead, I think I'd rather have seen the family names left in there, but it's not important, so up to you. > - Use "renesas,prr" and "renesas,cccr" device

Re: [PATCH] drbd: Fix kernel_sendmsg() usage

On 11/09/2016 08:32 AM, Lars Ellenberg wrote: On Tue, Nov 08, 2016 at 09:52:04AM -0700, Jens Axboe wrote: This should go into 4.9, and into all stable branches since and including v4.0, which is the first to contain the exposing change. It is correct for all stable branches older than that as

Re: [PATCH] drbd: Fix kernel_sendmsg() usage

On 11/09/2016 08:32 AM, Lars Ellenberg wrote: On Tue, Nov 08, 2016 at 09:52:04AM -0700, Jens Axboe wrote: This should go into 4.9, and into all stable branches since and including v4.0, which is the first to contain the exposing change. It is correct for all stable branches older than that as

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On 19 October 2016 at 11:53, Peter Zijlstra wrote: > On Wed, Oct 19, 2016 at 08:38:12AM +0200, Vincent Guittot wrote: >> > It might make sense to have helper functions to evaluate those >> >> The main issue is the number of parameters used in these conditions >> that makes

Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On 19 October 2016 at 11:53, Peter Zijlstra wrote: > On Wed, Oct 19, 2016 at 08:38:12AM +0200, Vincent Guittot wrote: >> > It might make sense to have helper functions to evaluate those >> >> The main issue is the number of parameters used in these conditions >> that makes helper function not

Re: KASAN & the vmalloc area

On 11/08/2016 10:03 PM, Mark Rutland wrote: > Hi, > > I see a while back [1] there was a discussion of what to do about KASAN > and vmapped stacks, but it doesn't look like that was solved, judging by > the vmapped stacks pull [2] for v4.9. > > I wondered whether anyone had looked at that since?

Re: KASAN & the vmalloc area

On 11/08/2016 10:03 PM, Mark Rutland wrote: > Hi, > > I see a while back [1] there was a discussion of what to do about KASAN > and vmapped stacks, but it doesn't look like that was solved, judging by > the vmapped stacks pull [2] for v4.9. > > I wondered whether anyone had looked at that since?

Re: [PATCH 1/2] mfd: davinci_voicecodec: tidyup header difinitions

On Thu, 27 Oct 2016, Kuninori Morimoto wrote: > > From: Kuninori Morimoto Please use `git send-mail` to submit your patches. > mach/hardware.h is needed on C source code side, not header. > And struct davinci_vc is duplicated definition. > > Signed-off-by:

Re: [PATCH 1/2] mfd: davinci_voicecodec: tidyup header difinitions

On Thu, 27 Oct 2016, Kuninori Morimoto wrote: > > From: Kuninori Morimoto Please use `git send-mail` to submit your patches. > mach/hardware.h is needed on C source code side, not header. > And struct davinci_vc is duplicated definition. > > Signed-off-by: Kuninori Morimoto > --- >

Re: [Drbd-dev] [PATCH] drbd: Fix kernel_sendmsg() usage

On Wed, Nov 09, 2016 at 04:47:15PM +0100, Richard Weinberger wrote: > > Should I sent two patches, one that applies to 4.5 and later, > > and one that applies to 2.6.33 ... 4.4, or are you or stable > > willing to resolve the trivial "missing comment block" conflict yourself? > > BTW: Why did you

Re: [Drbd-dev] [PATCH] drbd: Fix kernel_sendmsg() usage

On Wed, Nov 09, 2016 at 04:47:15PM +0100, Richard Weinberger wrote: > > Should I sent two patches, one that applies to 4.5 and later, > > and one that applies to 2.6.33 ... 4.4, or are you or stable > > willing to resolve the trivial "missing comment block" conflict yourself? > > BTW: Why did you

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

On Wed, Nov 09, 2016 at 04:16:17PM +, Gabriele Paoloni wrote: > Hi Liviu > > Thanks for reviewing > [removed some irrelevant part of discussion, avoid crazy formatting] > > > +/** > > > + * addr_is_indirect_io - check whether the input taddr is for > > indirectIO. > > > + * @taddr: the io

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

On Wed, Nov 09, 2016 at 04:16:17PM +, Gabriele Paoloni wrote: > Hi Liviu > > Thanks for reviewing > [removed some irrelevant part of discussion, avoid crazy formatting] > > > +/** > > > + * addr_is_indirect_io - check whether the input taddr is for > > indirectIO. > > > + * @taddr: the io

Re: [PATCH 1/1 V2] mqueue: Implment generic xattr support

> +/* > + * Callback for security_inode_init_security() for acquiring xattrs. > + */ > +static int mqueue_initxattrs(struct inode *inode, > + const struct xattr *xattr_array, > + void *fs_info) > +{ > + struct mqueue_inode_info *info =

Re: [PATCH 1/1 V2] mqueue: Implment generic xattr support

> +/* > + * Callback for security_inode_init_security() for acquiring xattrs. > + */ > +static int mqueue_initxattrs(struct inode *inode, > + const struct xattr *xattr_array, > + void *fs_info) > +{ > + struct mqueue_inode_info *info =

[PATCH] kvm: kvmclock: let KVM_GET_CLOCK return whether the master clock is in use

Userspace can read the exact value of kvmclock by reading the TSC and fetching the timekeeping parameters out of guest memory. This however is brittle and not necessary anymore with KVM 4.11. Provide a mechanism that lets userspace know if the new KVM_GET_CLOCK semantics are in effect,

[PATCH] kvm: kvmclock: let KVM_GET_CLOCK return whether the master clock is in use

Userspace can read the exact value of kvmclock by reading the TSC and fetching the timekeeping parameters out of guest memory. This however is brittle and not necessary anymore with KVM 4.11. Provide a mechanism that lets userspace know if the new KVM_GET_CLOCK semantics are in effect,

Re: [PATCH 2/2] ASoC: axentia: tse850: add ASoC driver for the Axentia TSE-850

On 2016-11-09 14:38, Mark Brown wrote: > On Tue, Nov 08, 2016 at 05:20:57PM +0100, Peter Rosin wrote: > >> +++ b/sound/soc/axentia/Kconfig >> @@ -0,0 +1,10 @@ >> +config SND_SOC_AXENTIA_TSE850_PCM5142 >> +tristate "ASoC driver for the Axentia TSE-850" >> +depends on ARCH_AT91 && OF >> +

Re: [PATCH 2/2] ASoC: axentia: tse850: add ASoC driver for the Axentia TSE-850

On 2016-11-09 14:38, Mark Brown wrote: > On Tue, Nov 08, 2016 at 05:20:57PM +0100, Peter Rosin wrote: > >> +++ b/sound/soc/axentia/Kconfig >> @@ -0,0 +1,10 @@ >> +config SND_SOC_AXENTIA_TSE850_PCM5142 >> +tristate "ASoC driver for the Axentia TSE-850" >> +depends on ARCH_AT91 && OF >> +

[PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid

According to the datasheet, VF610 uses revision r3p2 of the L2C-310 block, same as i.MX6Q+, which does not require a software workaround for ARM errata 769419. Signed-off-by: Andrey Smirnov --- arch/arm/mach-imx/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH] i.MX: Kconfig: Drop errata 769419 for Vybrid

According to the datasheet, VF610 uses revision r3p2 of the L2C-310 block, same as i.MX6Q+, which does not require a software workaround for ARM errata 769419. Signed-off-by: Andrey Smirnov --- arch/arm/mach-imx/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [PATCH 1/3] tuntap: rx batching

On Wed, Nov 09, 2016 at 03:38:31PM +0800, Jason Wang wrote: > Backlog were used for tuntap rx, but it can only process 1 packet at > one time since it was scheduled during sendmsg() synchronously in > process context. This lead bad cache utilization so this patch tries > to do some batching before

Re: [PATCH 1/3] tuntap: rx batching

On Wed, Nov 09, 2016 at 03:38:31PM +0800, Jason Wang wrote: > Backlog were used for tuntap rx, but it can only process 1 packet at > one time since it was scheduled during sendmsg() synchronously in > process context. This lead bad cache utilization so this patch tries > to do some batching before

Re: [RFC v3 1/6] Track the active utilisation

On Tue, 8 Nov 2016 17:56:35 + Juri Lelli wrote: [...] > > > > @@ -947,14 +965,19 @@ static void enqueue_task_dl(struct rq *rq, struct > > > > task_struct *p, int flags) > > > > return; > > > > } > > > > > > > > + if (p->on_rq ==

Re: [RFC v3 1/6] Track the active utilisation

On Tue, 8 Nov 2016 17:56:35 + Juri Lelli wrote: [...] > > > > @@ -947,14 +965,19 @@ static void enqueue_task_dl(struct rq *rq, struct > > > > task_struct *p, int flags) > > > > return; > > > > } > > > > > > > > + if (p->on_rq == TASK_ON_RQ_MIGRATING) > > > > +

Re: [PATCH] x86/cpuid: Deal with broken firmware once more

On 11/09/2016 11:03 AM, Peter Zijlstra wrote: On Wed, Nov 09, 2016 at 04:35:51PM +0100, Thomas Gleixner wrote: Both ACPI and MP specifications require that the APIC id in the respective tables must be the same as the APIC id in CPUID. The kernel retrieves the physical package id from the

Re: [PATCH] x86/cpuid: Deal with broken firmware once more

On 11/09/2016 11:03 AM, Peter Zijlstra wrote: On Wed, Nov 09, 2016 at 04:35:51PM +0100, Thomas Gleixner wrote: Both ACPI and MP specifications require that the APIC id in the respective tables must be the same as the APIC id in CPUID. The kernel retrieves the physical package id from the

Re: [PATCH 1/1 V2] mqueue: Implment generic xattr support

On Mon, Nov 7, 2016 at 4:23 PM, Paul Moore wrote: > On Mon, Nov 7, 2016 at 3:46 PM, David Graziano > wrote: >> This patch adds support for generic extended attributes within the >> POSIX message queues filesystem and setting them by

Re: [PATCH 1/1 V2] mqueue: Implment generic xattr support

On Mon, Nov 7, 2016 at 4:23 PM, Paul Moore wrote: > On Mon, Nov 7, 2016 at 3:46 PM, David Graziano > wrote: >> This patch adds support for generic extended attributes within the >> POSIX message queues filesystem and setting them by consulting the LSM. >> This is needed so that the

Re: [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr

On Mon, Nov 7, 2016 at 11:06 PM, Cao jin wrote: > When running as guest, under certain condition, it will oops as following. > writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr > is NULL. While other register access won't oops kernel because they

Re: [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr

On Mon, Nov 7, 2016 at 11:06 PM, Cao jin wrote: > When running as guest, under certain condition, it will oops as following. > writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr > is NULL. While other register access won't oops kernel because they use > wr32/rd32 which have

[PATCH -next 0/2] ipc/sem: semop updates

Hi, Here are two small updates to semop(2), suggested a while ago by Manfred. Both patches have passed the usual regression tests, including ltp and some sysvsem benchmarks. Thanks! Davidlohr Bueso (2): ipc/sem: simplify wait-wake loop ipc/sem: avoid idr tree lookup for interrupted semop

[PATCH -next 0/2] ipc/sem: semop updates

Hi, Here are two small updates to semop(2), suggested a while ago by Manfred. Both patches have passed the usual regression tests, including ltp and some sysvsem benchmarks. Thanks! Davidlohr Bueso (2): ipc/sem: simplify wait-wake loop ipc/sem: avoid idr tree lookup for interrupted semop

[PATCH -next 1/2] ipc/sem: simplify wait-wake loop

Instead of using the reverse goto, we can simplify the flow and make it more language natural by just doing do-while instead. One would hope this is the standard way (or obviously just with a while bucle) that we do wait/wakeup handling in the kernel. The exact same logic is kept, just more

[PATCH -next 1/2] ipc/sem: simplify wait-wake loop

Instead of using the reverse goto, we can simplify the flow and make it more language natural by just doing do-while instead. One would hope this is the standard way (or obviously just with a while bucle) that we do wait/wakeup handling in the kernel. The exact same logic is kept, just more

Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue

On Wed, Nov 09, 2016 at 08:18:08AM -0500, Jeff Layton wrote: > On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote: > > On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote: > > > > > > Hello, Bruce. > > > > > > On Tue, Nov 08, 2016 at 04:39:11PM -0500, J. Bruce Fields wrote: > > > >

Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue

On Wed, Nov 09, 2016 at 08:18:08AM -0500, Jeff Layton wrote: > On Tue, 2016-11-08 at 20:27 -0500, J. Bruce Fields wrote: > > On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote: > > > > > > Hello, Bruce. > > > > > > On Tue, Nov 08, 2016 at 04:39:11PM -0500, J. Bruce Fields wrote: > > > >

[PATCH -next 2/2] ipc/sem: avoid idr tree lookup for interrupted semop

We can avoid the idr tree lookup (albeit possibly avoiding idr_find_fast()) when being awoken in EINTR, as the semid will not change in this context while blocked. Use the sma pointer directly and take the sem_lock, then re-check for RMID races. We continue to re-check the queue.status with the

[PATCH -next 2/2] ipc/sem: avoid idr tree lookup for interrupted semop

We can avoid the idr tree lookup (albeit possibly avoiding idr_find_fast()) when being awoken in EINTR, as the semid will not change in this context while blocked. Use the sma pointer directly and take the sem_lock, then re-check for RMID races. We continue to re-check the queue.status with the

Re: [PATCH 22/25] x86/mcheck: Do the init in one place

On 2016-11-09 16:38:07 [+0100], Borislav Petkov wrote: > On Wed, Nov 09, 2016 at 03:22:21PM +0100, Sebastian Andrzej Siewior wrote: > > I want to get rid of non-symmetrical part and the arch hook which should > > be part of the hp notifier itself. I wouldn't be too much afraid about > > the when

Re: [PATCH 22/25] x86/mcheck: Do the init in one place

On 2016-11-09 16:38:07 [+0100], Borislav Petkov wrote: > On Wed, Nov 09, 2016 at 03:22:21PM +0100, Sebastian Andrzej Siewior wrote: > > I want to get rid of non-symmetrical part and the arch hook which should > > be part of the hp notifier itself. I wouldn't be too much afraid about > > the when

Re: [RFC 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio host controller sub-vended by NI

On Wed, Nov 09, 2016 at 03:24:24PM +0200, Adrian Hunter wrote: > On 08/11/16 22:07, Zach Brown wrote: > > On NI 9037 boards the max SDIO frequency is limited by trace lengths > > and other layout choices. The max SDIO frequency is stored in an ACPI > > table, as MXFQ. > > > > The driver reads the

Re: [RFC 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio host controller sub-vended by NI

On Wed, Nov 09, 2016 at 03:24:24PM +0200, Adrian Hunter wrote: > On 08/11/16 22:07, Zach Brown wrote: > > On NI 9037 boards the max SDIO frequency is limited by trace lengths > > and other layout choices. The max SDIO frequency is stored in an ACPI > > table, as MXFQ. > > > > The driver reads the

Re: [PATCH] vxlan: hide unused local variable

On Mon, 7 Nov 2016 22:09:07 +0100, Arnd Bergmann wrote: > A bugfix introduced a harmless warning in v4.9-rc4: > > drivers/net/vxlan.c: In function 'vxlan_group_used': > drivers/net/vxlan.c:947:21: error: unused variable 'sock6' > [-Werror=unused-variable] > > This hides the variable inside of

Re: [PATCH] vxlan: hide unused local variable

On Mon, 7 Nov 2016 22:09:07 +0100, Arnd Bergmann wrote: > A bugfix introduced a harmless warning in v4.9-rc4: > > drivers/net/vxlan.c: In function 'vxlan_group_used': > drivers/net/vxlan.c:947:21: error: unused variable 'sock6' > [-Werror=unused-variable] > > This hides the variable inside of

RE: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

Hi Liviu Thanks for reviewing > -Original Message- > From: liviu.du...@arm.com [mailto:liviu.du...@arm.com] > Sent: 09 November 2016 11:40 > To: Yuanzhichang > Cc: catalin.mari...@arm.com; will.dea...@arm.com; robh...@kernel.org; > bhelg...@google.com; mark.rutl...@arm.com;

RE: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

Hi Liviu Thanks for reviewing > -Original Message- > From: liviu.du...@arm.com [mailto:liviu.du...@arm.com] > Sent: 09 November 2016 11:40 > To: Yuanzhichang > Cc: catalin.mari...@arm.com; will.dea...@arm.com; robh...@kernel.org; > bhelg...@google.com; mark.rutl...@arm.com;

[tip:x86/urgent] x86/cpu/AMD: Fix cpu_llc_id for AMD Fam17h systems

Commit-ID: b0b6e86846093c5f8820386bc01515f857dd8faa Gitweb: http://git.kernel.org/tip/b0b6e86846093c5f8820386bc01515f857dd8faa Author: Yazen Ghannam AuthorDate: Tue, 8 Nov 2016 09:35:06 +0100 Committer: Ingo Molnar CommitDate: Wed, 9 Nov 2016

[tip:x86/urgent] x86/cpu/AMD: Fix cpu_llc_id for AMD Fam17h systems

Commit-ID: b0b6e86846093c5f8820386bc01515f857dd8faa Gitweb: http://git.kernel.org/tip/b0b6e86846093c5f8820386bc01515f857dd8faa Author: Yazen Ghannam AuthorDate: Tue, 8 Nov 2016 09:35:06 +0100 Committer: Ingo Molnar CommitDate: Wed, 9 Nov 2016 17:06:08 +0100 x86/cpu/AMD: Fix cpu_llc_id

Re: [PATCH 2/4] mfd: palmas: Reset the POWERHOLD mux during power off

On Thu, 27 Oct 2016, Keerthy wrote: > POWERHOLD signal has higher priority over the DEV_ON bit. > So power off will not happen if the POWERHOLD is held high. > Hence reset the MUX to GPIO_7 mode to release the POWERHOLD > and the DEV_ON bit to take effect to power off the PMIC. > > PMIC Power

Re: [PATCH 2/4] mfd: palmas: Reset the POWERHOLD mux during power off

On Thu, 27 Oct 2016, Keerthy wrote: > POWERHOLD signal has higher priority over the DEV_ON bit. > So power off will not happen if the POWERHOLD is held high. > Hence reset the MUX to GPIO_7 mode to release the POWERHOLD > and the DEV_ON bit to take effect to power off the PMIC. > > PMIC Power

Re: [PATCH 6/8] block: add scalable completion tracking of requests

On 11/09/2016 02:01 AM, Jan Kara wrote: On Tue 08-11-16 08:25:52, Jens Axboe wrote: On 11/08/2016 06:30 AM, Jan Kara wrote: On Tue 01-11-16 15:08:49, Jens Axboe wrote: For legacy block, we simply track them in the request queue. For blk-mq, we track them on a per-sw queue basis, which we can

Re: [PATCH 6/8] block: add scalable completion tracking of requests

On 11/09/2016 02:01 AM, Jan Kara wrote: On Tue 08-11-16 08:25:52, Jens Axboe wrote: On 11/08/2016 06:30 AM, Jan Kara wrote: On Tue 01-11-16 15:08:49, Jens Axboe wrote: For legacy block, we simply track them in the request queue. For blk-mq, we track them on a per-sw queue basis, which we can

Re: [PATCH 1/4] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

On Thu, 27 Oct 2016, Keerthy wrote: > GPIO7 is configured in POWERHOLD mode which has higher priority > over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON > bit is turned off. This property enables driver to over ride the > POWERHOLD value to GPIO7 so as to turn off the PMIC in

Re: [PATCH 1/4] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition

On Thu, 27 Oct 2016, Keerthy wrote: > GPIO7 is configured in POWERHOLD mode which has higher priority > over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON > bit is turned off. This property enables driver to over ride the > POWERHOLD value to GPIO7 so as to turn off the PMIC in

Re: [PATCH 7/8] blk-wbt: add general throttling mechanism

On 11/09/2016 01:40 AM, Jan Kara wrote: So for devices with write cache, you will completely drain the device before waking anybody waiting to issue new requests. Isn't it too strict? In particular may_queue() will allow new writers to issue new writes once we drop below the limit so it can

Re: [PATCH 7/8] blk-wbt: add general throttling mechanism

On 11/09/2016 01:40 AM, Jan Kara wrote: So for devices with write cache, you will completely drain the device before waking anybody waiting to issue new requests. Isn't it too strict? In particular may_queue() will allow new writers to issue new writes once we drop below the limit so it can

Re: [PATCH] x86/cpuid: Deal with broken firmware once more

On Wed, Nov 09, 2016 at 04:35:51PM +0100, Thomas Gleixner wrote: > Both ACPI and MP specifications require that the APIC id in the respective > tables must be the same as the APIC id in CPUID. > > The kernel retrieves the physical package id from the APIC id during the > ACPI/MP table scan and

Re: [PATCH] x86/cpuid: Deal with broken firmware once more

On Wed, Nov 09, 2016 at 04:35:51PM +0100, Thomas Gleixner wrote: > Both ACPI and MP specifications require that the APIC id in the respective > tables must be the same as the APIC id in CPUID. > > The kernel retrieves the physical package id from the APIC id during the > ACPI/MP table scan and

Re: [lustre-devel] [PATCH] staging: lustre: ldlm: pl_recalc time handling is wrong

On Wednesday, November 9, 2016 3:50:29 AM CET Dilger, Andreas wrote: > On Nov 7, 2016, at 19:47, James Simmons wrote: > > > > The ldlm_pool field pl_recalc_time is set to the current > > monotonic clock value but the interval period is calculated > > with the wall clock.

Re: [lustre-devel] [PATCH] staging: lustre: ldlm: pl_recalc time handling is wrong

On Wednesday, November 9, 2016 3:50:29 AM CET Dilger, Andreas wrote: > On Nov 7, 2016, at 19:47, James Simmons wrote: > > > > The ldlm_pool field pl_recalc_time is set to the current > > monotonic clock value but the interval period is calculated > > with the wall clock. This means the interval

[ppdev] sysfs warning on qemu boot

Hi Sudip, I hit a sysfs_warn_dup inside QEMU running 4.9.0-rc4 (I suspect earlier versions as well, but this is the first upstream I've run in a while). This warning looks like something the kernel test robot ran into a few months ago: http://marc.info/?t=14726777333=1=2 I'm running

[ppdev] sysfs warning on qemu boot

Hi Sudip, I hit a sysfs_warn_dup inside QEMU running 4.9.0-rc4 (I suspect earlier versions as well, but this is the first upstream I've run in a while). This warning looks like something the kernel test robot ran into a few months ago: http://marc.info/?t=14726777333=1=2 I'm running

Re: [Patch V6 2/6] irqchip: xilinx: Clean up irqdomain argument and read/write

On 01/11/16 11:05, Zubair Lutfullah Kakakhel wrote: > Hi, > > Thanks for the review. > > On 10/31/2016 07:51 PM, Thomas Gleixner wrote: >> On Mon, 31 Oct 2016, Zubair Lutfullah Kakakhel wrote: >>> The drivers read/write function handling is a bit quirky. >> >> Can you please explain in more

Re: [Patch V6 2/6] irqchip: xilinx: Clean up irqdomain argument and read/write

On 01/11/16 11:05, Zubair Lutfullah Kakakhel wrote: > Hi, > > Thanks for the review. > > On 10/31/2016 07:51 PM, Thomas Gleixner wrote: >> On Mon, 31 Oct 2016, Zubair Lutfullah Kakakhel wrote: >>> The drivers read/write function handling is a bit quirky. >> >> Can you please explain in more

Re: [PATCH] perf/x86: Fix overlap counter scheduling bug

On Wed, Nov 09, 2016 at 03:25:15PM +0100, Robert Richter wrote: > On 08.11.16 19:27:39, Peter Zijlstra wrote: > > The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if > > the counter mask of such an event is not a subset of any other counter > > mask of a constraint with an equal

Re: [PATCH] perf/x86: Fix overlap counter scheduling bug

On Wed, Nov 09, 2016 at 03:25:15PM +0100, Robert Richter wrote: > On 08.11.16 19:27:39, Peter Zijlstra wrote: > > The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if > > the counter mask of such an event is not a subset of any other counter > > mask of a constraint with an equal

Re: [PATCH 1/2] backlight: arcxcnn: add support for ArticSand devices

Jingoo? On Wed, 26 Oct 2016, Olimpiu Dejeu wrote: > Resubmition of arcxcnn backliught driver adding devicetree entries > for all registers > > Signed-off-by: Olimpiu Dejeu > > --- > drivers/video/backlight/Kconfig | 7 + > drivers/video/backlight/Makefile

Re: [PATCH 1/2] backlight: arcxcnn: add support for ArticSand devices

Jingoo? On Wed, 26 Oct 2016, Olimpiu Dejeu wrote: > Resubmition of arcxcnn backliught driver adding devicetree entries > for all registers > > Signed-off-by: Olimpiu Dejeu > > --- > drivers/video/backlight/Kconfig | 7 + > drivers/video/backlight/Makefile | 1 + >

Re: [PATCH] x86/cpuid: Deal with broken firmware once more

On Wed, 9 Nov 2016, Thomas Gleixner wrote: > + if (pkg != c->phys_proc_id) { > + pr_err(FW_BUG "CPU%u: Using firmware package id %u instead of > %u\n", > +cpu, pkg, c->phys_proc_id); > + c->phys_proc_id = pkg; > + } > + c->logical_proc_id =

Re: [PATCH] x86/cpuid: Deal with broken firmware once more

On Wed, 9 Nov 2016, Thomas Gleixner wrote: > + if (pkg != c->phys_proc_id) { > + pr_err(FW_BUG "CPU%u: Using firmware package id %u instead of > %u\n", > +cpu, pkg, c->phys_proc_id); > + c->phys_proc_id = pkg; > + } > + c->logical_proc_id =

Re: linux.git: printk() problem

On Mon 2016-10-24 19:22:59, Linus Torvalds wrote: > On Mon, Oct 24, 2016 at 7:06 PM, Linus Torvalds > wrote: > > On Mon, Oct 24, 2016 at 6:55 PM, Sergey Senozhatsky > > wrote: > >> > >> I think cont_flush() should grab the

Re: linux.git: printk() problem

On Mon 2016-10-24 19:22:59, Linus Torvalds wrote: > On Mon, Oct 24, 2016 at 7:06 PM, Linus Torvalds > wrote: > > On Mon, Oct 24, 2016 at 6:55 PM, Sergey Senozhatsky > > wrote: > >> > >> I think cont_flush() should grab the logbuf_lock lock, because > >> it does log_store() and touches the

Re: [PATCH] drbd: Fix kernel_sendmsg() usage

On 09.11.2016 16:32, Lars Ellenberg wrote: > On Tue, Nov 08, 2016 at 09:52:04AM -0700, Jens Axboe wrote: This should go into 4.9, and into all stable branches since and including v4.0, which is the first to contain the exposing change. It is correct for all stable branches

Re: [PATCH] drbd: Fix kernel_sendmsg() usage

On 09.11.2016 16:32, Lars Ellenberg wrote: > On Tue, Nov 08, 2016 at 09:52:04AM -0700, Jens Axboe wrote: This should go into 4.9, and into all stable branches since and including v4.0, which is the first to contain the exposing change. It is correct for all stable branches

<    5   6   7   8   9   10   11   12   13   14   >