[PATCH] perf config: Fix a bug about permission checking state of config file

perf_config_set__init() check state of user config file before opening it. But there is a bug when checking uid and euid of current user. Although current user have superuser permission, a error occurs as below. Before: user01@localhost:~$ ls -l ~/.perfconfig -rw-rw-r-- 1 user01 user01 89

[PATCH] perf config: Fix a bug about permission checking state of config file

perf_config_set__init() check state of user config file before opening it. But there is a bug when checking uid and euid of current user. Although current user have superuser permission, a error occurs as below. Before: user01@localhost:~$ ls -l ~/.perfconfig -rw-rw-r-- 1 user01 user01 89

[PATCH] perf diff: Introduce the new rules of colored printing of delta.

From: SeongSoo Cho As you know, there are the common colored printing of percents so overhead(%) can be c$ But Delta means difference percents from percents of overhead between two files e.g. p$ Although the rule is for overhead(%), Delta value also follow the same rule.

[PATCH] perf diff: Introduce the new rules of colored printing of delta.

From: SeongSoo Cho As you know, there are the common colored printing of percents so overhead(%) can be c$ But Delta means difference percents from percents of overhead between two files e.g. p$ Although the rule is for overhead(%), Delta value also follow the same rule. So, I think that it

Re: [RFC PATCH 0/3] kvm: x86: speedups for APICv

2016-09-27 23:20+0200, Paolo Bonzini: > The difficult one is patch 2. I find the new code easier to follow than > the old one, but it doesn't mean it works. :) The aim is for APICv to > not use KVM_REQ_EVENT at all for interrupts, therefore turning APICv's > weakness (having to look at PIR on

Re: [RFC PATCH 0/3] kvm: x86: speedups for APICv

2016-09-27 23:20+0200, Paolo Bonzini: > The difficult one is patch 2. I find the new code easier to follow than > the old one, but it doesn't mean it works. :) The aim is for APICv to > not use KVM_REQ_EVENT at all for interrupts, therefore turning APICv's > weakness (having to look at PIR on

Re: [PATCH] mfd: arizona: Mark AIFx_TX_BCLK_RATE as readable for cs47l24

On Tue, 13 Sep 2016, Charles Keepax wrote: > From: Praveen Kumar Vegivada > > This register is used in the AIF code but is missing from the register > tables. > > Signed-off-by: Praveen Kumar Vegivada > Signed-off-by: Charles Keepax

Re: [PATCH] mfd: arizona: Mark AIFx_TX_BCLK_RATE as readable for cs47l24

On Tue, 13 Sep 2016, Charles Keepax wrote: > From: Praveen Kumar Vegivada > > This register is used in the AIF code but is missing from the register > tables. > > Signed-off-by: Praveen Kumar Vegivada > Signed-off-by: Charles Keepax > --- > drivers/mfd/cs47l24-tables.c | 6 ++ > 1 file

[PATCH v2 2/2] x86/asm: Get rid of __read_cr4_safe()

We use __read_cr4() vs __read_cr4_safe() inconsistently. On CR4-less CPUs, all CR4 bits are effectively clear, so we can make the code simpler and more robust by making __read_cr4() always fix up faults on 32-bit kernels. This may fix some bugs on old 486-like CPUs, but I don't have any easy way

[PATCH v2 0/2] CR4 fixes (one is urgent)

Hi Ingo, etc: Patch 1 fixes a boot regressions that's new in 4.8. Patch 2 cleans the whole mess up. It's probably not 4.8 material, but I'm sending it as part of this series for ease of review. If you like, you could apply patch 1 to x86/urgent, merge into x86/asm, and apply patch 3 on top.

Re: [RESEND PATCH v2 1/4] mmc: core: switch to 1V8 or 1V2 for hs400es mode

Hi, On Thu, Sep 22, 2016 at 5:12 PM, Shawn Lin wrote: > When introducing hs400es, I didn't notice that we haven't > switched voltage to 1V2 or 1V8 for it. That happens to work > as the first controller claiming to support hs400es, arasan(5.1), > which is designed to

Re: [PATCH v2 4/4] mmc: sdhci-of-arasan: add sdhci_arasan_voltage_switch for arasan,5.1

Hi, On Thu, Sep 22, 2016 at 5:03 PM, Shawn Lin wrote: > Per the vendor's requirement, we shouldn't do any setting for > 1.8V Signaling Enable, otherwise the interaction/behaviour between > phy and controller will be undefined. Mostly it works fine if we do > that, but

[PATCH v2 2/2] x86/asm: Get rid of __read_cr4_safe()

We use __read_cr4() vs __read_cr4_safe() inconsistently. On CR4-less CPUs, all CR4 bits are effectively clear, so we can make the code simpler and more robust by making __read_cr4() always fix up faults on 32-bit kernels. This may fix some bugs on old 486-like CPUs, but I don't have any easy way

[PATCH v2 0/2] CR4 fixes (one is urgent)

Hi Ingo, etc: Patch 1 fixes a boot regressions that's new in 4.8. Patch 2 cleans the whole mess up. It's probably not 4.8 material, but I'm sending it as part of this series for ease of review. If you like, you could apply patch 1 to x86/urgent, merge into x86/asm, and apply patch 3 on top.

Re: [RESEND PATCH v2 1/4] mmc: core: switch to 1V8 or 1V2 for hs400es mode

Hi, On Thu, Sep 22, 2016 at 5:12 PM, Shawn Lin wrote: > When introducing hs400es, I didn't notice that we haven't > switched voltage to 1V2 or 1V8 for it. That happens to work > as the first controller claiming to support hs400es, arasan(5.1), > which is designed to only support 1V8. So the

Re: [PATCH v2 4/4] mmc: sdhci-of-arasan: add sdhci_arasan_voltage_switch for arasan,5.1

Hi, On Thu, Sep 22, 2016 at 5:03 PM, Shawn Lin wrote: > Per the vendor's requirement, we shouldn't do any setting for > 1.8V Signaling Enable, otherwise the interaction/behaviour between > phy and controller will be undefined. Mostly it works fine if we do > that, but we still see failures.

[PATCH v2 1/2] x86/boot: Fix another __read_cr4() case on 486

The condition for reading CR4 was wrong: there are some CPUs with CPUID but not CR4. Rather than trying to make the condition exact, using __read_cr4_safe(). Reported-by: da...@saggiorato.net Fixes: 18bc7bd523e0 ("x86/boot: Synchronize trampoline_cr4_features and mmu_cr4_features directly")

[PATCH v2 1/2] x86/boot: Fix another __read_cr4() case on 486

The condition for reading CR4 was wrong: there are some CPUs with CPUID but not CR4. Rather than trying to make the condition exact, using __read_cr4_safe(). Reported-by: da...@saggiorato.net Fixes: 18bc7bd523e0 ("x86/boot: Synchronize trampoline_cr4_features and mmu_cr4_features directly")

Re: NMI for ARC

On 09/29/2016 11:54 AM, Andy Lutomirski wrote: >> So lets first see how a single priority intr works on ARC (maybe on other >> arches >> > as well). >> > >> > 1. task t1 enters kernel syscall (Trap Exception on ARC), handler drops >> > down to >> > pure kernel model and proceeds into syscall

Re: [RESEND PATCH v2 2/4] mmc: core: changes frequency to hs_max_dtr when selecting hs400es

Hi, On Thu, Sep 22, 2016 at 5:12 PM, Shawn Lin wrote: > Per JESD84-B51 P69, Host need to change frequency to <=52MHz Technically Page 49. In the PDF you go to page 69, but the heading on the top of the page says 49. > after setting HS_TIMING to 0x1, and host may

Re: NMI for ARC

On 09/29/2016 11:54 AM, Andy Lutomirski wrote: >> So lets first see how a single priority intr works on ARC (maybe on other >> arches >> > as well). >> > >> > 1. task t1 enters kernel syscall (Trap Exception on ARC), handler drops >> > down to >> > pure kernel model and proceeds into syscall

Re: [RESEND PATCH v2 2/4] mmc: core: changes frequency to hs_max_dtr when selecting hs400es

Hi, On Thu, Sep 22, 2016 at 5:12 PM, Shawn Lin wrote: > Per JESD84-B51 P69, Host need to change frequency to <=52MHz Technically Page 49. In the PDF you go to page 69, but the heading on the top of the page says 49. > after setting HS_TIMING to 0x1, and host may changes frequency > to <=

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

On Thu, 2016-09-29 at 08:01 -0700, Joe Perches wrote: > $Constant there is any number and the match regex is > any upper case variable. Why doesn't that regex match on "ORIGIN_HASH_SIZE"? Paul Bolle

Re: [PATCH 01/10] dm snapshot: Use kmalloc_array() in init_origin_hash()

On Thu, 2016-09-29 at 08:01 -0700, Joe Perches wrote: > $Constant there is any number and the match regex is > any upper case variable. Why doesn't that regex match on "ORIGIN_HASH_SIZE"? Paul Bolle

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

On Thu, Sep 29, 2016 at 12:34:39PM -0400, Olimpiu Dejeu wrote: > Resubmition of arcxcnn backliught driver adding definitions of the > internal registers of the chip. s/backliught/backlight/ [...] > +#ifdef CONFIG_OF > +static int arcxcnn_parse_dt(struct arcxcnn *lp) > +{ > + struct device

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

On Thu, Sep 29, 2016 at 12:34:39PM -0400, Olimpiu Dejeu wrote: > Resubmition of arcxcnn backliught driver adding definitions of the > internal registers of the chip. s/backliught/backlight/ [...] > +#ifdef CONFIG_OF > +static int arcxcnn_parse_dt(struct arcxcnn *lp) > +{ > + struct device

Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

On Thu, 29 Sep 2016, Paul E. McKenney wrote: > On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote: > > How about something like so on PPC? > > > > P0(int *x, int *y) > > { > > WRITE_ONCE(*x, 1); > > smp_store_release(y, 1); > > } > > > > P1(int *x, int *y) > > { > >

Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

On Thu, 29 Sep 2016, Paul E. McKenney wrote: > On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote: > > How about something like so on PPC? > > > > P0(int *x, int *y) > > { > > WRITE_ONCE(*x, 1); > > smp_store_release(y, 1); > > } > > > > P1(int *x, int *y) > > { > >

Re: linux-next: Tree for Jul 21

On Thu, Jul 21, 2016 at 07:52:43PM -0400, Paul Gortmaker wrote: > A new i386-allmodconfig fail showed up relating to VDSO: > > I tried to reproduce it locally with x86-64 build host and could > not, so I wonder if it is a missing HOSTCC vs. CC since next > coverage is power host... > > VDSO2C

Re: linux-next: Tree for Jul 21

On Thu, Jul 21, 2016 at 07:52:43PM -0400, Paul Gortmaker wrote: > A new i386-allmodconfig fail showed up relating to VDSO: > > I tried to reproduce it locally with x86-64 build host and could > not, so I wonder if it is a missing HOSTCC vs. CC since next > coverage is power host... > > VDSO2C

RE: [PATCH] dma/fsldma : Unmap region obtained by of_iomap

> -Original Message- > From: Arvind Yadav [mailto:arvind.yadav...@gmail.com] > Sent: Wednesday, September 28, 2016 5:45 AM > To: le...@freescale.com; z...@zh-kernel.org; vinod.k...@intel.com > Cc: dan.j.willi...@intel.com; linuxppc-...@lists.ozlabs.org; > dmaeng...@vger.kernel.org;

RE: [PATCH] dma/fsldma : Unmap region obtained by of_iomap

> -Original Message- > From: Arvind Yadav [mailto:arvind.yadav...@gmail.com] > Sent: Wednesday, September 28, 2016 5:45 AM > To: le...@freescale.com; z...@zh-kernel.org; vinod.k...@intel.com > Cc: dan.j.willi...@intel.com; linuxppc-...@lists.ozlabs.org; > dmaeng...@vger.kernel.org;

Re: [PATCH 4/6] vfio_pci: use pci_irq_allocate_vectors

On Thu, 29 Sep 2016 21:24:04 +0200 Christoph Hellwig wrote: > On Thu, Sep 29, 2016 at 01:21:01PM -0600, Alex Williamson wrote: > > Sorry for the delay, slipped by me. Overall a really nice cleanup. > > One tiny nit, the commit log mis-names the function as > >

Re: [PATCH 4/6] vfio_pci: use pci_irq_allocate_vectors

On Thu, 29 Sep 2016 21:24:04 +0200 Christoph Hellwig wrote: > On Thu, Sep 29, 2016 at 01:21:01PM -0600, Alex Williamson wrote: > > Sorry for the delay, slipped by me. Overall a really nice cleanup. > > One tiny nit, the commit log mis-names the function as > > pci_irq_allocate_vectors instead

put_page vs release_pages

Hi, Can someone explain to me what is the difference between put_page and release_pages and which one should be used when ? To explain my case: We have a PCIe driver than transfers data between user process (read/write scalls) to a PCI device, using DMA. We followed the DMA guide so the code

put_page vs release_pages

Hi, Can someone explain to me what is the difference between put_page and release_pages and which one should be used when ? To explain my case: We have a PCIe driver than transfers data between user process (read/write scalls) to a PCI device, using DMA. We followed the DMA guide so the code

Re: [PATCH 4/6] vfio_pci: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 01:21:01PM -0600, Alex Williamson wrote: > Sorry for the delay, slipped by me. Overall a really nice cleanup. > One tiny nit, the commit log mis-names the function as > pci_irq_allocate_vectors instead of pci_alloc_irq_vectors. With that, > > Acked-by: Alex Williamson

Re: [PATCH 4/6] vfio_pci: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 01:21:01PM -0600, Alex Williamson wrote: > Sorry for the delay, slipped by me. Overall a really nice cleanup. > One tiny nit, the commit log mis-names the function as > pci_irq_allocate_vectors instead of pci_alloc_irq_vectors. With that, > > Acked-by: Alex Williamson >

Re: [PATCH 2/2] backlight: arcxcnn: devicetree bindings for ArticSand devices

On Thu, Sep 29, 2016 at 12:35:37PM -0400, Olimpiu Dejeu wrote: > Resubmition of arcxcnn backliught driver bindings correcting the file > location, device name, and proper use of reg for device address > > Signed-off-by: Olimpiu Dejeu > > --- >

Re: [PATCH 2/2] backlight: arcxcnn: devicetree bindings for ArticSand devices

On Thu, Sep 29, 2016 at 12:35:37PM -0400, Olimpiu Dejeu wrote: > Resubmition of arcxcnn backliught driver bindings correcting the file > location, device name, and proper use of reg for device address > > Signed-off-by: Olimpiu Dejeu > > --- > .../bindings/leds/backlight/arcxcnn_bl.txt

Re: [PATCH 4/6] vfio_pci: use pci_irq_allocate_vectors

On Sun, 11 Sep 2016 15:31:26 +0200 Christoph Hellwig wrote: > Simply the interrupt setup by using the new PCI layer helpers. > > Signed-off-by: Christoph Hellwig > --- > drivers/vfio/pci/vfio_pci_intrs.c | 45 > + >

Re: [PATCH 4/6] vfio_pci: use pci_irq_allocate_vectors

On Sun, 11 Sep 2016 15:31:26 +0200 Christoph Hellwig wrote: > Simply the interrupt setup by using the new PCI layer helpers. > > Signed-off-by: Christoph Hellwig > --- > drivers/vfio/pci/vfio_pci_intrs.c | 45 > + > drivers/vfio/pci/vfio_pci_private.h |

Re: [PATCH v6 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

Hi Lee, [add Rob and Mark] > Lee Jones hat am 29. September 2016 um 19:15 > geschrieben: > > > On Thu, 29 Sep 2016, Stefan Wahren wrote: > > > Lee Jones hat am 28. September 2016 um 03:05 > > > geschrieben: > > > > > > > > > On Sat, 17 Sep 2016,

Re: [PATCH v6 1/4] mfd: mxs-lradc: Add support for mxs-lradc MFD

Hi Lee, [add Rob and Mark] > Lee Jones hat am 29. September 2016 um 19:15 > geschrieben: > > > On Thu, 29 Sep 2016, Stefan Wahren wrote: > > > Lee Jones hat am 28. September 2016 um 03:05 > > > geschrieben: > > > > > > > > > On Sat, 17 Sep 2016, Ksenija Stanojevic wrote: > > > > > > > + >

Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote: > On Thu, Sep 29, 2016 at 11:10:15AM -0700, Paul E. McKenney wrote: > > > > > > > > P0(int *x, int *y) > > > > { > > > > WRITE_ONCE(*x, 1); > > > > smp_wmb(); > > > >

Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote: > On Thu, Sep 29, 2016 at 11:10:15AM -0700, Paul E. McKenney wrote: > > > > > > > > P0(int *x, int *y) > > > > { > > > > WRITE_ONCE(*x, 1); > > > > smp_wmb(); > > > >

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

Hi Guenter, > -Original Message- > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > ow...@vger.kernel.org] On Behalf Of Guenter Roeck > Sent: Wednesday, August 24, 2016 5:11 AM > To: Felipe Balbi > Cc: Chandra Sekhar Anagani

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

Hi Guenter, > -Original Message- > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > ow...@vger.kernel.org] On Behalf Of Guenter Roeck > Sent: Wednesday, August 24, 2016 5:11 AM > To: Felipe Balbi > Cc: Chandra Sekhar Anagani ; Bruce > Ashfield ; Bin Gao ; > Pranav Tipnis ;

Re: [PATCH 2/3] x86/boot: Fix another __read_cr4() case on 486

On Thu, Sep 29, 2016 at 4:48 AM, Borislav Petkov wrote: > On Wed, Sep 28, 2016 at 12:34:15PM -0700, Andy Lutomirski wrote: >> The condition for reading CR4 was wrong: there are some CPUs with >> CPUID but not CR4. Rather than trying to make the condition exact, >> using

Re: [PATCH 2/3] x86/boot: Fix another __read_cr4() case on 486

On Thu, Sep 29, 2016 at 4:48 AM, Borislav Petkov wrote: > On Wed, Sep 28, 2016 at 12:34:15PM -0700, Andy Lutomirski wrote: >> The condition for reading CR4 was wrong: there are some CPUs with >> CPUID but not CR4. Rather than trying to make the condition exact, >> using __read_cr4_safe(). >> >>

Re: [PATCH] Adding Support for Coresight Components on Zynq 7000.

Hi Muhammad, On Thu, 2016-09-29 at 12:26:13 +0200, Muhammad Abdul WAHAB wrote: > The Coresight components are present on the Zynq SoC but the corresponding > device tree entries are missing. This patch adds device tree entries for > coresight components while explaining how it was done in order

Re: [PATCH] Adding Support for Coresight Components on Zynq 7000.

Hi Muhammad, On Thu, 2016-09-29 at 12:26:13 +0200, Muhammad Abdul WAHAB wrote: > The Coresight components are present on the Zynq SoC but the corresponding > device tree entries are missing. This patch adds device tree entries for > coresight components while explaining how it was done in order

Re: [PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

Hi, On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote: > Default memory settings of da850 do not meet the throughput/latency > requirements of tilcdc. This results in the image displayed being > incorrect and the following warning being displayed by the LCDC > drm driver: > >

Re: [PATCH 6/6] ARM: da850: adjust memory settings for tilcdc

Hi, On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote: > Default memory settings of da850 do not meet the throughput/latency > requirements of tilcdc. This results in the image displayed being > incorrect and the following warning being displayed by the LCDC > drm driver: > >

Re: [PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution

Hi, On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote: > Add svga timings for 1024x768 resolution to the da850-lcdk > device tree. > > Signed-off-by: Bartosz Golaszewski > --- > arch/arm/boot/dts/da850-lcdk.dts | 15 +-- > 1 file

Re: [PATCH 4/6] ARM: dts: da850-lcdk: add support for 1024x768 resolution

Hi, On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote: > Add svga timings for 1024x768 resolution to the da850-lcdk > device tree. > > Signed-off-by: Bartosz Golaszewski > --- > arch/arm/boot/dts/da850-lcdk.dts | 15 +-- > 1 file changed, 13 insertions(+), 2

Re: NMI for ARC

On Thu, Sep 29, 2016 at 9:47 AM, Vineet Gupta wrote: > On 09/28/2016 11:43 PM, Peter Zijlstra wrote: >> On Wed, Sep 28, 2016 at 06:20:29PM -0700, Vineet Gupta wrote: >>> On 09/28/2016 03:26 PM, Andy Lutomirski wrote: > >> >> >> userirq nmi >> >> |

Re: NMI for ARC

On Thu, Sep 29, 2016 at 9:47 AM, Vineet Gupta wrote: > On 09/28/2016 11:43 PM, Peter Zijlstra wrote: >> On Wed, Sep 28, 2016 at 06:20:29PM -0700, Vineet Gupta wrote: >>> On 09/28/2016 03:26 PM, Andy Lutomirski wrote: > >> >> >> userirq nmi >> >> | >> | >> `-> .

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

Christoph Hellwig writes: > On Thu, Sep 29, 2016 at 03:45:29PM -0300, Gabriel Krisman Bertazi wrote: >> I'm stepping up to assist with the genwqe_card driver just now, since we >> (ibm) missed some of the last patches that went in. I'll add myself to >> maintainers file. > > Can

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

Christoph Hellwig writes: > On Thu, Sep 29, 2016 at 03:45:29PM -0300, Gabriel Krisman Bertazi wrote: >> I'm stepping up to assist with the genwqe_card driver just now, since we >> (ibm) missed some of the last patches that went in. I'll add myself to >> maintainers file. > > Can your forward it

Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

On Thu, Sep 29, 2016 at 11:10:15AM -0700, Paul E. McKenney wrote: > > > > > > P0(int *x, int *y) > > > { > > > WRITE_ONCE(*x, 1); > > > smp_wmb(); > > > smp_store_release(y, 1); > > > } > > > > > > P1(int *y) > > > { > > > WRITE_ONCE(*y, 2); > >

Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

On Thu, Sep 29, 2016 at 11:10:15AM -0700, Paul E. McKenney wrote: > > > > > > P0(int *x, int *y) > > > { > > > WRITE_ONCE(*x, 1); > > > smp_wmb(); > > > smp_store_release(y, 1); > > > } > > > > > > P1(int *y) > > > { > > > WRITE_ONCE(*y, 2); > >

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 03:45:29PM -0300, Gabriel Krisman Bertazi wrote: > I'm stepping up to assist with the genwqe_card driver just now, since we > (ibm) missed some of the last patches that went in. I'll add myself to > maintainers file. Can your forward it to Greg together with whatever

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 03:45:29PM -0300, Gabriel Krisman Bertazi wrote: > I'm stepping up to assist with the genwqe_card driver just now, since we > (ibm) missed some of the last patches that went in. I'll add myself to > maintainers file. Can your forward it to Greg together with whatever

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

Christoph Hellwig writes: > On Thu, Sep 29, 2016 at 03:28:02PM -0300, Gabriel Krisman Bertazi wrote: >> Christoph Hellwig writes: >> >> > Simply the interrupt setup by using the new PCI layer helpers. >> >> Good clean up. Tested and: >> >> Acked-by: Gabriel Krisman

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

Christoph Hellwig writes: > On Thu, Sep 29, 2016 at 03:28:02PM -0300, Gabriel Krisman Bertazi wrote: >> Christoph Hellwig writes: >> >> > Simply the interrupt setup by using the new PCI layer helpers. >> >> Good clean up. Tested and: >> >> Acked-by: Gabriel Krisman Bertazi > > Which tree

Re: [PATCH 4/6] vfio_pci: use pci_irq_allocate_vectors

On Sun, Sep 11, 2016 at 03:31:26PM +0200, Christoph Hellwig wrote: > Simply the interrupt setup by using the new PCI layer helpers. > > Signed-off-by: Christoph Hellwig Any chance to get a review for this one? Vfio seems to be actively maintained, so the silence seems odd. I'm

Re: [PATCH 4/6] vfio_pci: use pci_irq_allocate_vectors

On Sun, Sep 11, 2016 at 03:31:26PM +0200, Christoph Hellwig wrote: > Simply the interrupt setup by using the new PCI layer helpers. > > Signed-off-by: Christoph Hellwig Any chance to get a review for this one? Vfio seems to be actively maintained, so the silence seems odd. I'm still hoping to

Re: [PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller

Hi, On Thu, Sep 29, 2016 at 06:31:52PM +0200, Bartosz Golaszewski wrote: > From: Karl Beldan > > This adds the pins used by the LCD controller, and uses 'tilcdc,panel' > with some default timings for 800x600. > > Tested on an LCDK connected on the VGA port (the LCDC is

Re: [PATCH 3/6] ARM: dts: da850-lcdk: enable the LCD controller

Hi, On Thu, Sep 29, 2016 at 06:31:52PM +0200, Bartosz Golaszewski wrote: > From: Karl Beldan > > This adds the pins used by the LCD controller, and uses 'tilcdc,panel' > with some default timings for 800x600. > > Tested on an LCDK connected on the VGA port (the LCDC is connected to > this port

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 03:28:02PM -0300, Gabriel Krisman Bertazi wrote: > Christoph Hellwig writes: > > > Simply the interrupt setup by using the new PCI layer helpers. > > Good clean up. Tested and: > > Acked-by: Gabriel Krisman Bertazi Which tree

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

On Thu, Sep 29, 2016 at 03:28:02PM -0300, Gabriel Krisman Bertazi wrote: > Christoph Hellwig writes: > > > Simply the interrupt setup by using the new PCI layer helpers. > > Good clean up. Tested and: > > Acked-by: Gabriel Krisman Bertazi Which tree should this go in through?

Re: [PATCH] KVM: VMX: Better name x2apic msr bitmaps

2016-09-23 19:17+0800, Wanpeng Li: > Renames x2apic_apicv_inactive msr_bitmaps to x2apic and original > x2apic bitmaps to x2apic_apicv. > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Signed-off-by: Wanpeng Li > --- Applied to

Re: [PATCH] KVM: VMX: Better name x2apic msr bitmaps

2016-09-23 19:17+0800, Wanpeng Li: > Renames x2apic_apicv_inactive msr_bitmaps to x2apic and original > x2apic bitmaps to x2apic_apicv. > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Signed-off-by: Wanpeng Li > --- Applied to kvm/queue, thanks.

Applied "ASoC: Intel: Skylake: fix memory leak of module on error exit path" to the asoc tree

The patch ASoC: Intel: Skylake: fix memory leak of module on error exit path has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "ASoC: Intel: Skylake: fix memory leak of module on error exit path" to the asoc tree

The patch ASoC: Intel: Skylake: fix memory leak of module on error exit path has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

Christoph Hellwig writes: > Simply the interrupt setup by using the new PCI layer helpers. Good clean up. Tested and: Acked-by: Gabriel Krisman Bertazi > One odd thing about this driver is that it looks like it could request > multiple MSI vectors,

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

Christoph Hellwig writes: > Simply the interrupt setup by using the new PCI layer helpers. Good clean up. Tested and: Acked-by: Gabriel Krisman Bertazi > One odd thing about this driver is that it looks like it could request > multiple MSI vectors, but it will then only ever use a single

Re: [PATCH] kvm/x86: Fix unused variable warning in kvm_timer_init()

2016-09-04 19:13+0200, Borislav Petkov: > From: Borislav Petkov > > When CONFIG_CPU_FREQ is not set, int cpu is unused and gcc rightfully > warns about it: > > arch/x86/kvm/x86.c: In function ‘kvm_timer_init’: > arch/x86/kvm/x86.c:5697:6: warning: unused variable ‘cpu’ >

Re: [PATCH] kvm/x86: Fix unused variable warning in kvm_timer_init()

2016-09-04 19:13+0200, Borislav Petkov: > From: Borislav Petkov > > When CONFIG_CPU_FREQ is not set, int cpu is unused and gcc rightfully > warns about it: > > arch/x86/kvm/x86.c: In function ‘kvm_timer_init’: > arch/x86/kvm/x86.c:5697:6: warning: unused variable ‘cpu’ >

[tip:x86/urgent] x86/init: Fix cr4_init_shadow() on CR4-less machines

Commit-ID: e1bfc11c5a6f40222a698a818dc269113245820e Gitweb: http://git.kernel.org/tip/e1bfc11c5a6f40222a698a818dc269113245820e Author: Andy Lutomirski AuthorDate: Wed, 28 Sep 2016 12:34:14 -0700 Committer: Ingo Molnar CommitDate: Thu, 29 Sep 2016

[tip:x86/urgent] x86/init: Fix cr4_init_shadow() on CR4-less machines

Commit-ID: e1bfc11c5a6f40222a698a818dc269113245820e Gitweb: http://git.kernel.org/tip/e1bfc11c5a6f40222a698a818dc269113245820e Author: Andy Lutomirski AuthorDate: Wed, 28 Sep 2016 12:34:14 -0700 Committer: Ingo Molnar CommitDate: Thu, 29 Sep 2016 19:08:30 +0200 x86/init: Fix

Re: [PATCH v3 00/11] re-enable DAX PMD support

On Wed, Sep 28, 2016 at 02:55:50PM +1000, Dave Chinner wrote: > On Tue, Sep 27, 2016 at 07:08:42PM -0700, Christoph Hellwig wrote: > > On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote: > > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > > > locking. This

Re: [PATCH v3 00/11] re-enable DAX PMD support

On Wed, Sep 28, 2016 at 02:55:50PM +1000, Dave Chinner wrote: > On Tue, Sep 27, 2016 at 07:08:42PM -0700, Christoph Hellwig wrote: > > On Tue, Sep 27, 2016 at 02:47:51PM -0600, Ross Zwisler wrote: > > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > > > locking. This

[PATCH][V2] dmaengine: coh901318: fix integer overflow when shifting more than 32 places

From: Colin Ian King Currently U300_DMA_CHANNELS is set to 40, meaning that the shift of 1 can be more than 32 places, which leads to a 32 bit integer overflow. Fix this by using 1ULL instead of 1 before shifting it. Also add braces on the for-loop to keep with coding

[PATCH][V2] dmaengine: coh901318: fix integer overflow when shifting more than 32 places

From: Colin Ian King Currently U300_DMA_CHANNELS is set to 40, meaning that the shift of 1 can be more than 32 places, which leads to a 32 bit integer overflow. Fix this by using 1ULL instead of 1 before shifting it. Also add braces on the for-loop to keep with coding style conventions.

[tip:perf/core] perf tools: Make perf_evsel__append_filter() generic

Commit-ID: b15d0a4c828eafc82ea68fcf88db6fa93eeb23d7 Gitweb: http://git.kernel.org/tip/b15d0a4c828eafc82ea68fcf88db6fa93eeb23d7 Author: Mathieu Poirier AuthorDate: Fri, 16 Sep 2016 08:44:03 -0600 Committer: Arnaldo Carvalho de Melo

[tip:perf/core] perf intel-pt: Add support for recording the max non-turbo ratio

Commit-ID: fa8025c37454501a2df4a90ae84ff01f4aff8ba8 Gitweb: http://git.kernel.org/tip/fa8025c37454501a2df4a90ae84ff01f4aff8ba8 Author: Adrian Hunter AuthorDate: Fri, 23 Sep 2016 17:38:42 +0300 Committer: Arnaldo Carvalho de Melo CommitDate:

[tip:perf/core] perf intel-pt: Add support for recording the max non-turbo ratio

Commit-ID: fa8025c37454501a2df4a90ae84ff01f4aff8ba8 Gitweb: http://git.kernel.org/tip/fa8025c37454501a2df4a90ae84ff01f4aff8ba8 Author: Adrian Hunter AuthorDate: Fri, 23 Sep 2016 17:38:42 +0300 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 29 Sep 2016 11:17:03 -0300 perf

[tip:perf/core] perf tools: Make perf_evsel__append_filter() generic

Commit-ID: b15d0a4c828eafc82ea68fcf88db6fa93eeb23d7 Gitweb: http://git.kernel.org/tip/b15d0a4c828eafc82ea68fcf88db6fa93eeb23d7 Author: Mathieu Poirier AuthorDate: Fri, 16 Sep 2016 08:44:03 -0600 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 29 Sep 2016 11:16:58 -0300 perf

[tip:perf/core] perf tests: Add dwarf unwind test for powerpc

Commit-ID: d18019a53a07e009899ff6b8dc5ec30f249360d9 Gitweb: http://git.kernel.org/tip/d18019a53a07e009899ff6b8dc5ec30f249360d9 Author: Ravi Bangoria AuthorDate: Mon, 19 Sep 2016 02:38:20 -0400 Committer: Arnaldo Carvalho de Melo

[tip:perf/core] perf tests: Add dwarf unwind test for powerpc

Commit-ID: d18019a53a07e009899ff6b8dc5ec30f249360d9 Gitweb: http://git.kernel.org/tip/d18019a53a07e009899ff6b8dc5ec30f249360d9 Author: Ravi Bangoria AuthorDate: Mon, 19 Sep 2016 02:38:20 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 29 Sep 2016 11:18:21 -0300 perf tests:

Re: pull-request: wireless-drivers-next 2016-09-29

On Thu, Sep 29, 2016 at 07:57:28PM +0300, Kalle Valo wrote: > Hi Dave, > > this should be the last wireless-drivers-next pull request for 4.9, from > now on only important bugfixes. Nothing really special stands out, > iwlwifi being most active but other drivers also getting attention. More >

[tip:perf/core] perf probe: Match linkage name with mangled name

Commit-ID: d5a00296a63fdd049273f86d0a0cdef6b230f8e6 Gitweb: http://git.kernel.org/tip/d5a00296a63fdd049273f86d0a0cdef6b230f8e6 Author: Masami Hiramatsu AuthorDate: Sat, 24 Sep 2016 00:35:31 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Thu,

[tip:perf/core] perf probe: Ignore the error of finding inline instance

Commit-ID: f8da4b5155ed9a639ee4250746b5f7ffa6302bf6 Gitweb: http://git.kernel.org/tip/f8da4b5155ed9a639ee4250746b5f7ffa6302bf6 Author: Masami Hiramatsu AuthorDate: Sat, 24 Sep 2016 00:34:57 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Thu,

[tip:perf/core] perf probe: Skip if the function address is 0

Commit-ID: 0ad45b33c58dca60dec7e1fb44766753bc4a7a38 Gitweb: http://git.kernel.org/tip/0ad45b33c58dca60dec7e1fb44766753bc4a7a38 Author: Masami Hiramatsu AuthorDate: Sat, 24 Sep 2016 00:35:07 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Thu,

Re: pull-request: wireless-drivers-next 2016-09-29

On Thu, Sep 29, 2016 at 07:57:28PM +0300, Kalle Valo wrote: > Hi Dave, > > this should be the last wireless-drivers-next pull request for 4.9, from > now on only important bugfixes. Nothing really special stands out, > iwlwifi being most active but other drivers also getting attention. More >

[tip:perf/core] perf probe: Match linkage name with mangled name

Commit-ID: d5a00296a63fdd049273f86d0a0cdef6b230f8e6 Gitweb: http://git.kernel.org/tip/d5a00296a63fdd049273f86d0a0cdef6b230f8e6 Author: Masami Hiramatsu AuthorDate: Sat, 24 Sep 2016 00:35:31 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 29 Sep 2016 11:17:08 -0300 perf

[tip:perf/core] perf probe: Ignore the error of finding inline instance

Commit-ID: f8da4b5155ed9a639ee4250746b5f7ffa6302bf6 Gitweb: http://git.kernel.org/tip/f8da4b5155ed9a639ee4250746b5f7ffa6302bf6 Author: Masami Hiramatsu AuthorDate: Sat, 24 Sep 2016 00:34:57 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 29 Sep 2016 11:17:07 -0300 perf

[tip:perf/core] perf probe: Skip if the function address is 0

Commit-ID: 0ad45b33c58dca60dec7e1fb44766753bc4a7a38 Gitweb: http://git.kernel.org/tip/0ad45b33c58dca60dec7e1fb44766753bc4a7a38 Author: Masami Hiramatsu AuthorDate: Sat, 24 Sep 2016 00:35:07 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 29 Sep 2016 11:17:07 -0300 perf

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