[PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

There are several reports of freeze on enabling HWP (Hardware PStates) feature on Skylake based systems by Intel P states driver. The root cause is identified as the HWP interrupts causing BIOS code to freeze. HWP interrupts uses thermal LVT. Linux natively handles thermal interrupts, but in

[PATCH v4] acpi: Issue _OSC call for native thermal interrupt handling

There are several reports of freeze on enabling HWP (Hardware PStates) feature on Skylake based systems by Intel P states driver. The root cause is identified as the HWP interrupts causing BIOS code to freeze. HWP interrupts uses thermal LVT. Linux natively handles thermal interrupts, but in

Re: [PATCH v6 3/4] i2c: i801: add support of Host Notify

On Wed, Mar 16, 2016 at 9:39 AM, Benjamin Tissoires wrote: > The i801 chip can handle the Host Notify feature since ICH 3 as mentioned > in > http://www.intel.com/content/dam/doc/datasheet/82801ca-io-controller-hub-3-datasheet.pdf > > Enable the functionality

Re: [PATCH v6 3/4] i2c: i801: add support of Host Notify

On Wed, Mar 16, 2016 at 9:39 AM, Benjamin Tissoires wrote: > The i801 chip can handle the Host Notify feature since ICH 3 as mentioned > in > http://www.intel.com/content/dam/doc/datasheet/82801ca-io-controller-hub-3-datasheet.pdf > > Enable the functionality unconditionally and propagate the

[PATCH 3.19.y-ckt 44/70] drm/radeon/pm: update current crtc info after setting the powerstate

v3.19.8-ckt17 -stable review patch. If anyone has any objections, please let me know. ---8< From: Alex Deucher commit 5e031d9fe8b0741f11d49667dfc3ebf5454121fd upstream. On CI, we need to see if the number

[PATCH 3.19.y-ckt 44/70] drm/radeon/pm: update current crtc info after setting the powerstate

v3.19.8-ckt17 -stable review patch. If anyone has any objections, please let me know. ---8< From: Alex Deucher commit 5e031d9fe8b0741f11d49667dfc3ebf5454121fd upstream. On CI, we need to see if the number of crtcs changes to

[PATCH 2/2] bcma: use of_dma_configure() to set initial dma mask

While fixing another bug, I noticed that bcma manually sets up a dma_mask pointer for its child devices. We have a generic helper for that now, which should be able to cope better with any variations that might be needed to deal with cache coherency, unusual DMA address offsets, iommus, or limited

[PATCH 2/2] bcma: use of_dma_configure() to set initial dma mask

While fixing another bug, I noticed that bcma manually sets up a dma_mask pointer for its child devices. We have a generic helper for that now, which should be able to cope better with any variations that might be needed to deal with cache coherency, unusual DMA address offsets, iommus, or limited

Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios

Radim Krcmar writes: > 2016-03-18 13:33+0100, Vitaly Kuznetsov: >> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always >> delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD >> from. vmbus_wait_for_unload() doesn't account for the fact that

Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios

Radim Krcmar writes: > 2016-03-18 13:33+0100, Vitaly Kuznetsov: >> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always >> delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD >> from. vmbus_wait_for_unload() doesn't account for the fact that in case >> we're

Re: [PATCH] mac80211: fix order of flag descriptions

On Fri, 2016-03-18 at 16:35 +, Luis de Bethencourt wrote: > Fix order of mac80211_rx_flags description to match the enum. > > Signed-off-by: Luis de Bethencourt > --- > Hi, > > I want ahead and fixed the order of the descriptions. checkpatch.pl was giving > a warning

Re: [PATCH] mac80211: fix order of flag descriptions

On Fri, 2016-03-18 at 16:35 +, Luis de Bethencourt wrote: > Fix order of mac80211_rx_flags description to match the enum. > > Signed-off-by: Luis de Bethencourt > --- > Hi, > > I want ahead and fixed the order of the descriptions. checkpatch.pl was giving > a warning to my previous patch

Re: [RFC PATCH v4 3/7] PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set

On 2016/3/17 0:31, Alex Williamson wrote: On Mon, 7 Mar 2016 15:48:34 +0800 Yongji Xie wrote: The resource_alignment will releases memory resources allocated by firmware so that kernel can reassign new resources later on. But this will cause the problem that no

Re: [RFC PATCH v4 3/7] PCI: Ignore resource_alignment if PCI_PROBE_ONLY was set

On 2016/3/17 0:31, Alex Williamson wrote: On Mon, 7 Mar 2016 15:48:34 +0800 Yongji Xie wrote: The resource_alignment will releases memory resources allocated by firmware so that kernel can reassign new resources later on. But this will cause the problem that no resources can be allocated by

Re: [PATCH] Revert "arm64: Increase the max granular size"

Catalin Marinas wrote: >Yes, that's exactly it. Ours is an ACPI system, and so we have to have our >own defconfig for now. We're holding off on pushing our own defconfig >changes (enabling drivers, etc) until ACPI is enabled in >arch/arm64/configs/defconfig. Is there anything that prevents

Re: [PATCH] ARC: build: Turn off -Wmaybe-uninitialized for ARC gcc 4.8

On Friday 18 March 2016 16:13:28 Vineet Gupta wrote: > On Friday 18 March 2016 03:59 PM, Arnd Bergmann wrote: > > On Friday 18 March 2016 15:50:11 Vineet Gupta wrote: > >> Sure, but I prefer this to be only for gcc 4.8 as this warning seems to be > >> healthy in small doses At least it keeps the

Re: [PATCH] Revert "arm64: Increase the max granular size"

Catalin Marinas wrote: >Yes, that's exactly it. Ours is an ACPI system, and so we have to have our >own defconfig for now. We're holding off on pushing our own defconfig >changes (enabling drivers, etc) until ACPI is enabled in >arch/arm64/configs/defconfig. Is there anything that prevents

Re: [PATCH] ARC: build: Turn off -Wmaybe-uninitialized for ARC gcc 4.8

On Friday 18 March 2016 16:13:28 Vineet Gupta wrote: > On Friday 18 March 2016 03:59 PM, Arnd Bergmann wrote: > > On Friday 18 March 2016 15:50:11 Vineet Gupta wrote: > >> Sure, but I prefer this to be only for gcc 4.8 as this warning seems to be > >> healthy in small doses At least it keeps the

[PART1 RFC v3 00/12] KVM: x86: Introduce SVM AVIC support

CHANGES FROM RFCv2: == (https://lkml.org/lkml/2016/3/4/746) * Do not use bit-field in VMCB. * Get rid of struct svm_vm_data, and consolidate the struct members into struct kvm_arch. * Do not abbreviate AVIC vmexit function and structure names. * Adding VM

[PART1 RFC v3 00/12] KVM: x86: Introduce SVM AVIC support

CHANGES FROM RFCv2: == (https://lkml.org/lkml/2016/3/4/746) * Do not use bit-field in VMCB. * Get rid of struct svm_vm_data, and consolidate the struct members into struct kvm_arch. * Do not abbreviate AVIC vmexit function and structure names. * Adding VM

Re: [PATCH 2/2] pinctrl: sh-pfc: IPSRx and MOD_SELx should be set before GPSRx

Hi Geert > > From: Kuninori Morimoto > > > > Gen2 / Gen3 datasheet will have below note in next version. > > This patch follows this note. > > > > IPSRx and MOD_SELx registers shall be set before setting GPSRx > > registers in case that they need to be

Re: [PATCH 2/2] pinctrl: sh-pfc: IPSRx and MOD_SELx should be set before GPSRx

Hi Geert > > From: Kuninori Morimoto > > > > Gen2 / Gen3 datasheet will have below note in next version. > > This patch follows this note. > > > > IPSRx and MOD_SELx registers shall be set before setting GPSRx > > registers in case that they need to be configured. > > MOD_SELx registers can be

[PATCH] mmc: card: don't use PF_MEMALLOC

PF_MEMALLOC is assigned to processes by mm. If drivers prevent memory reclaim and mm is not in control, strange hang-up or OOM Killer invocation could happen. Signed-off-by: Martin Kepplinger --- I use MMC cards with this change perfectly fine. As I understand it, even *if*

[PATCH] mmc: card: don't use PF_MEMALLOC

PF_MEMALLOC is assigned to processes by mm. If drivers prevent memory reclaim and mm is not in control, strange hang-up or OOM Killer invocation could happen. Signed-off-by: Martin Kepplinger --- I use MMC cards with this change perfectly fine. As I understand it, even *if* PF_MEMALLOC has a

[PATCH] cpufreq: rockchip: add driver

This driver will directly use cpufreq-dt driver as backend. As there is not a generic devicetree board file(rockchip.c) on ARM64 architecture, so remove platform_device_register_simple in rockchip.c and add a new cpufreq driver to support for all Rockchip SoCs. Signed-off-by: Feng Xiao

[PATCH] cpufreq: rockchip: add driver

This driver will directly use cpufreq-dt driver as backend. As there is not a generic devicetree board file(rockchip.c) on ARM64 architecture, so remove platform_device_register_simple in rockchip.c and add a new cpufreq driver to support for all Rockchip SoCs. Signed-off-by: Feng Xiao ---

Re: linux-next: build failure after merge of the kbuild tree

On 2016-03-16 12:29, Stephen Rothwell wrote: > Hi Michal, > > On Wed, 16 Mar 2016 08:56:50 +0100 Michal Marek wrote: >> >> Right. Stephen, could you perhaps move the kbuild tree down in your list >> a bit, so that the fixes are present? > > Done. > > Now you just need to make

Re: linux-next: build failure after merge of the kbuild tree

On 2016-03-16 12:29, Stephen Rothwell wrote: > Hi Michal, > > On Wed, 16 Mar 2016 08:56:50 +0100 Michal Marek wrote: >> >> Right. Stephen, could you perhaps move the kbuild tree down in your list >> a bit, so that the fixes are present? > > Done. > > Now you just need to make sure Linus gets

Re: [PATCH] sound/usb: Fix memory leak in media_snd_stream_delete() during unbind

Adding Takashi Iwai On 03/16/2016 08:58 PM, Shuah Khan wrote: > media_snd_stream_delete() fails to release resources during unbind. This > leads to use-after-free in media_gobj_create() on a subsequent bind. > > [ 1445.086410] BUG: KASAN: use-after-free in media_gobj_create+0x3a1/0x470 >

Re: [PATCH] sound/usb: Fix memory leak in media_snd_stream_delete() during unbind

Adding Takashi Iwai On 03/16/2016 08:58 PM, Shuah Khan wrote: > media_snd_stream_delete() fails to release resources during unbind. This > leads to use-after-free in media_gobj_create() on a subsequent bind. > > [ 1445.086410] BUG: KASAN: use-after-free in media_gobj_create+0x3a1/0x470 >

Re: [ANNOUNCE] 3.14.64-rt67

On Tue, Mar 15, 2016 at 10:50:31PM -0400, Paul Gortmaker wrote: > On Tue, Mar 15, 2016 at 7:25 PM, Paul Gortmaker > wrote: > > On Tue, Mar 15, 2016 at 5:45 PM, Paul Gortmaker > > wrote: > >> On Mon, Mar 14, 2016 at 11:49 AM, Steven

Re: [ANNOUNCE] 3.14.64-rt67

On Tue, Mar 15, 2016 at 10:50:31PM -0400, Paul Gortmaker wrote: > On Tue, Mar 15, 2016 at 7:25 PM, Paul Gortmaker > wrote: > > On Tue, Mar 15, 2016 at 5:45 PM, Paul Gortmaker > > wrote: > >> On Mon, Mar 14, 2016 at 11:49 AM, Steven Rostedt > >> wrote: > >>> > >>> Dear RT Folks, > >>> > >>>

Re: arch/x86/um/user-offsets.c:8:24: fatal error: asm/ptrace.h: No such file or directory

On 18.03.2016 12:19, Philip Li wrote: > On Mon, Mar 14, 2016 at 09:53:06AM +0900, Krzysztof Kozlowski wrote: >> On Sun, Mar 13, 2016 at 7:45 AM, kbuild test robot >> wrote: >>> Hi Al, >>> >>> FYI, the error/warning still remains. >>> >>> tree:

Re: arch/x86/um/user-offsets.c:8:24: fatal error: asm/ptrace.h: No such file or directory

On 18.03.2016 12:19, Philip Li wrote: > On Mon, Mar 14, 2016 at 09:53:06AM +0900, Krzysztof Kozlowski wrote: >> On Sun, Mar 13, 2016 at 7:45 AM, kbuild test robot >> wrote: >>> Hi Al, >>> >>> FYI, the error/warning still remains. >>> >>> tree:

[PATCH v4 3/3] x86/iopl: Fix iopl capability check on Xen PV

iopl(3) is supposed to work if iopl is already 3, even if unprivileged. This didn't work right on Xen PV. Fix it. Cc: sta...@vger.kernel.org Reviewewd-by: Jan Beulich Signed-off-by: Andy Lutomirski --- arch/x86/kernel/ioport.c | 12 +--- 1 file

[PATCH 3/5] usb: host: xhci: add broken pe quirk flag to pdata

From: Felipe Balbi Let platform_data users pass broken pe flag to xhci driver. Signed-off-by: Felipe Balbi Signed-off-by: Sekhar Nori Signed-off-by: Roger Quadros --- include/linux/usb/xhci_pdriver.h | 2 ++ 1 file changed,

[PATCH v4 3/3] x86/iopl: Fix iopl capability check on Xen PV

iopl(3) is supposed to work if iopl is already 3, even if unprivileged. This didn't work right on Xen PV. Fix it. Cc: sta...@vger.kernel.org Reviewewd-by: Jan Beulich Signed-off-by: Andy Lutomirski --- arch/x86/kernel/ioport.c | 12 +--- 1 file changed, 9 insertions(+), 3

[PATCH 3/5] usb: host: xhci: add broken pe quirk flag to pdata

From: Felipe Balbi Let platform_data users pass broken pe flag to xhci driver. Signed-off-by: Felipe Balbi Signed-off-by: Sekhar Nori Signed-off-by: Roger Quadros --- include/linux/usb/xhci_pdriver.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/usb/xhci_pdriver.h

[PATCH 1/8] lib/mpi: mpi_write_sgl(): fix skipping of leading zero limbs

Currently, if the number of leading zeros is greater than fits into a complete limb, mpi_write_sgl() skips them by iterating over them limb-wise. However, it fails to adjust its internal leading zeros tracking variable, lzeros, accordingly: it does a p -= sizeof(alimb); continue; which

[PATCH 1/8] lib/mpi: mpi_write_sgl(): fix skipping of leading zero limbs

Currently, if the number of leading zeros is greater than fits into a complete limb, mpi_write_sgl() skips them by iterating over them limb-wise. However, it fails to adjust its internal leading zeros tracking variable, lzeros, accordingly: it does a p -= sizeof(alimb); continue; which

[RFC/RFT PATCH 2/2] mfd: max14577: Allow driver to be built as a module

The driver's Kconfig symbol is a boolean but nothing prevents the driver to be built as a module instead of built-in. It is true that most system integrators will choose the latter but the config should not restrict it. Suggested-by: Krzysztof Kozlowski Signed-off-by:

[RFC/RFT PATCH 2/2] mfd: max14577: Allow driver to be built as a module

The driver's Kconfig symbol is a boolean but nothing prevents the driver to be built as a module instead of built-in. It is true that most system integrators will choose the latter but the config should not restrict it. Suggested-by: Krzysztof Kozlowski Signed-off-by: Javier Martinez Canillas

Re: [RFC PATCH 0/4] ACPI based PCI host driver with generic ECAM

On Fri, Mar 18, 2016 at 1:48 AM, Jayachandran C wrote: > Hi Bjorn, > > Here is a new patchset for the ACPI PCI controller driver based on the > earlier discussion[1]. > > The first two patches in the patchset implements pci/ecam.c for generic > config space access and uses

Re: [RFC PATCH 0/4] ACPI based PCI host driver with generic ECAM

On Fri, Mar 18, 2016 at 1:48 AM, Jayachandran C wrote: > Hi Bjorn, > > Here is a new patchset for the ACPI PCI controller driver based on the > earlier discussion[1]. > > The first two patches in the patchset implements pci/ecam.c for generic > config space access and uses it in

Re: dynamic ftrace/recordmcount.c problem on ARMv5

Hi, On Fri, Mar 11, 2016 at 10:21:59AM +0100, Uwe Kleine-König wrote: > Hello, > > On Wed, Jan 13, 2016 at 09:51:28AM +0100, Marc Kleine-Budde wrote: > > Hello, > > > > I'm on a ARMv5 (freescale mx25) and seeing this ftrace bug during bootup: > > > > > [0.059235] [ cut here

Re: dynamic ftrace/recordmcount.c problem on ARMv5

Hi, On Fri, Mar 11, 2016 at 10:21:59AM +0100, Uwe Kleine-König wrote: > Hello, > > On Wed, Jan 13, 2016 at 09:51:28AM +0100, Marc Kleine-Budde wrote: > > Hello, > > > > I'm on a ARMv5 (freescale mx25) and seeing this ftrace bug during bootup: > > > > > [0.059235] [ cut here

Re: livepatch: Update maintainers

+++ Josh Poimboeuf [16/03/16 10:03 -0500]: Seth and Vojtech are no longer active maintainers of livepatch, so remove them in favor of Jessica and Miroslav. Also add Petr as a designated reviewer. Signed-off-by: Josh Poimboeuf --- MAINTAINERS | 5 +++-- 1 file changed, 3

Re: livepatch: Update maintainers

+++ Josh Poimboeuf [16/03/16 10:03 -0500]: Seth and Vojtech are no longer active maintainers of livepatch, so remove them in favor of Jessica and Miroslav. Also add Petr as a designated reviewer. Signed-off-by: Josh Poimboeuf --- MAINTAINERS | 5 +++-- 1 file changed, 3 insertions(+), 2

Re: [PATCH 2/6] net: arc_emac: add phy-reset-* are optional for device tree

On Fri, Mar 11, 2016 at 06:55:27PM +0800, Caesar Wang wrote: > This patch adds the following property for arc_emac. > > 1) phy-reset-gpios: > The phy-reset-gpios is an optional property for arc emac device tree boot. > Change the binding document to match the driver code. > > 2)

Re: [PATCH 2/6] net: arc_emac: add phy-reset-* are optional for device tree

On Fri, Mar 11, 2016 at 06:55:27PM +0800, Caesar Wang wrote: > This patch adds the following property for arc_emac. > > 1) phy-reset-gpios: > The phy-reset-gpios is an optional property for arc emac device tree boot. > Change the binding document to match the driver code. > > 2)

[RESEND] [PATCH v11 6/6] add-TC-G210-pci-driver

This patch adds a glue pci driver for the Synopsys G210 Test Chip. Signed-off-by: Joao Pinto --- Changes v10->v11 (Arnd Bergmann): - tc_type is now initialized to TC_G210_INV - probe function checks if the test chip version is specified Changes v0->v10: - This patch only

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On 17-Mar 06:55, Steve Muckle wrote: > On 03/17/2016 02:40 AM, Juri Lelli wrote: > >> Could the default schedtune value not serve as the out of the box margin? > >> > > I'm not sure I understand you here. For me schedtune should be disabled > > by default, so I'd say that it doesn't introduce any

[RESEND] [PATCH v11 6/6] add-TC-G210-pci-driver

This patch adds a glue pci driver for the Synopsys G210 Test Chip. Signed-off-by: Joao Pinto --- Changes v10->v11 (Arnd Bergmann): - tc_type is now initialized to TC_G210_INV - probe function checks if the test chip version is specified Changes v0->v10: - This patch only appeared in v10

Re: [PATCH 4/8] cpufreq/schedutil: sysfs capacity margin tunable

On 17-Mar 06:55, Steve Muckle wrote: > On 03/17/2016 02:40 AM, Juri Lelli wrote: > >> Could the default schedtune value not serve as the out of the box margin? > >> > > I'm not sure I understand you here. For me schedtune should be disabled > > by default, so I'd say that it doesn't introduce any

Re: [PATCH v2 02/18] dt-bindings: timer: sp804: add timer-width property

Hi Rob, On 17/03/16 17:09, Rob Herring wrote: On Wed, Mar 09, 2016 at 11:24:04AM +0100, Neil Armstrong wrote: Add timer-width optional property to specify a different vendor specific timer counter bit-width. Signed-off-by: Neil Armstrong ---

[PATCH 0/2] mcb: export FPGA information via sysfs

The following series adds a way to obtain information about a MCB FPGA via sysfs. This is viable i.e. for a field technician to check if the latest FPGA bitstream version is applied to the hardware. The first patch layes the foundation in order to get sysfs correctly working with MCB and the

[PATCH v4 0/3] Xen iopl fixes

Hi all- For those who are seeing this for the first time: any 64-bit Xen PV domain with IO port access privileges (in practice, this means dom0 AFAIK) and any user programs that use iopl(3) (various old X drivers, presumably) is probably vulnerable to privilege escalations by unprivileged

[PATCH 0/2] mcb: export FPGA information via sysfs

The following series adds a way to obtain information about a MCB FPGA via sysfs. This is viable i.e. for a field technician to check if the latest FPGA bitstream version is applied to the hardware. The first patch layes the foundation in order to get sysfs correctly working with MCB and the

[PATCH v4 0/3] Xen iopl fixes

Hi all- For those who are seeing this for the first time: any 64-bit Xen PV domain with IO port access privileges (in practice, this means dom0 AFAIK) and any user programs that use iopl(3) (various old X drivers, presumably) is probably vulnerable to privilege escalations by unprivileged

Re: [PATCH v2 02/18] dt-bindings: timer: sp804: add timer-width property

Hi Rob, On 17/03/16 17:09, Rob Herring wrote: On Wed, Mar 09, 2016 at 11:24:04AM +0100, Neil Armstrong wrote: Add timer-width optional property to specify a different vendor specific timer counter bit-width. Signed-off-by: Neil Armstrong ---

[PATCH 06/15] irqdomain: Ensure type settings match for an existing mapping

When mapping an IRQ, if a mapping already exists, then we simply return the virtual IRQ number. However, we do not check that the type settings for the existing mapping match those for the mapping that is about to be created. It may be unlikely that the type settings would not match, but check for

[PATCH 06/15] irqdomain: Ensure type settings match for an existing mapping

When mapping an IRQ, if a mapping already exists, then we simply return the virtual IRQ number. However, we do not check that the type settings for the existing mapping match those for the mapping that is about to be created. It may be unlikely that the type settings would not match, but check for

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

On Tue, Mar 15, 2016 at 8:48 PM, Andy Lutomirski wrote: > > Why is it safe to rely on interrupted_kernel_fpu_idle? That function > is for interrupts, but is there any reason that KVM can't be preempted > (or explicitly schedule) with XCR0 having some funny value? KVM

Re: [PATCH 0/1] KVM: x86: using the fpu in interrupt context with a guest's xcr0

On Tue, Mar 15, 2016 at 8:48 PM, Andy Lutomirski wrote: > > Why is it safe to rely on interrupted_kernel_fpu_idle? That function > is for interrupts, but is there any reason that KVM can't be preempted > (or explicitly schedule) with XCR0 having some funny value? KVM restores the host's xcr0 in

[PATCH v4 03/13] clk: sunxi: Add APB1 clock for A83T

APB1 is similar to sun4i-a10-apb0-clk, except different dividers. This adds support for apb1 on A83T. Signed-off-by: Vishnu Patekar Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/sunxi.txt | 1 + drivers/clk/sunxi/clk-sunxi.c

[PATCH v4 03/13] clk: sunxi: Add APB1 clock for A83T

APB1 is similar to sun4i-a10-apb0-clk, except different dividers. This adds support for apb1 on A83T. Signed-off-by: Vishnu Patekar Acked-by: Rob Herring --- Documentation/devicetree/bindings/clock/sunxi.txt | 1 + drivers/clk/sunxi/clk-sunxi.c | 13 + 2 files

Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

On Wed, Mar 16, 2016 at 08:47:52AM +0100, Peter Zijlstra wrote: > On Tue, Mar 15, 2016 at 03:27:21PM -0700, Michael Turquette wrote: > > I'm happy with it as a stop-gap, because it will initially work for > > arm{64} and x86, but we'll still need run-time selection of > > arch_scale_freq_capacity

Re: [PATCH 8/8] sched: prefer cpufreq_scale_freq_capacity

On Wed, Mar 16, 2016 at 08:47:52AM +0100, Peter Zijlstra wrote: > On Tue, Mar 15, 2016 at 03:27:21PM -0700, Michael Turquette wrote: > > I'm happy with it as a stop-gap, because it will initially work for > > arm{64} and x86, but we'll still need run-time selection of > > arch_scale_freq_capacity

[RFC v3 1/3] dt-bindings: soc: Add documentation for the MediaTek GCE unit

This adds documentation for the MediaTek Global Command Engine (GCE) unit found in MT8173 SoCs. Signed-off-by: HS Liao --- .../devicetree/bindings/soc/mediatek/gce.txt | 34 1 file changed, 34 insertions(+) create mode 100644

[RFC v3 1/3] dt-bindings: soc: Add documentation for the MediaTek GCE unit

This adds documentation for the MediaTek Global Command Engine (GCE) unit found in MT8173 SoCs. Signed-off-by: HS Liao --- .../devicetree/bindings/soc/mediatek/gce.txt | 34 1 file changed, 34 insertions(+) create mode 100644

[PATCH 3.19.y-ckt 43/70] USB: qcserial: add Sierra Wireless EM74xx device ID

v3.19.8-ckt17 -stable review patch. If anyone has any objections, please let me know. ---8< From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= commit 04fdbc825ffc02fb098964b92de802fff44e73fd upstream. The MC74xx and EM74xx modules

Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts

On Thursday 17 March 2016 05:29 PM, Sergei Shtylyov wrote: > Hello. > > On 3/17/2016 2:41 PM, Vineet Gupta wrote: > > Following commit broke DW GMAC functionality on AXS10x boards: >

[PATCH 3.19.y-ckt 43/70] USB: qcserial: add Sierra Wireless EM74xx device ID

v3.19.8-ckt17 -stable review patch. If anyone has any objections, please let me know. ---8< From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= commit 04fdbc825ffc02fb098964b92de802fff44e73fd upstream. The MC74xx and EM74xx modules use different

Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts

On Thursday 17 March 2016 05:29 PM, Sergei Shtylyov wrote: > Hello. > > On 3/17/2016 2:41 PM, Vineet Gupta wrote: > > Following commit broke DW GMAC functionality on AXS10x boards: >

Re: [PATCH] Staging: rtl8192e: fix line length coding style issue in rtllib_softmac.c

On Fri, 2016-03-18 at 17:48 +, Yousof El-Sayed wrote: > This is a patch to the rtllib_softmac.c file that fixes up all instances of >  the 'line over 80 characters' warnings found by the checkpatch.pl tool. [] > diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c >

Re: [PATCH] Staging: rtl8192e: fix line length coding style issue in rtllib_softmac.c

On Fri, 2016-03-18 at 17:48 +, Yousof El-Sayed wrote: > This is a patch to the rtllib_softmac.c file that fixes up all instances of >  the 'line over 80 characters' warnings found by the checkpatch.pl tool. [] > diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c >

[PATCH] staging: rtl8712: Removed copyright notice

Removed copyright notice as per checkpatch check warning. Signed-off-by: Parth Sane --- drivers/staging/rtl8712/drv_types.h | 4 1 file changed, 4 deletions(-) diff --git a/drivers/staging/rtl8712/drv_types.h b/drivers/staging/rtl8712/drv_types.h index

[PATCH] staging: rtl8712: Removed copyright notice

Removed copyright notice as per checkpatch check warning. Signed-off-by: Parth Sane --- drivers/staging/rtl8712/drv_types.h | 4 1 file changed, 4 deletions(-) diff --git a/drivers/staging/rtl8712/drv_types.h b/drivers/staging/rtl8712/drv_types.h index 29e47e1..ae79047 100644 ---

Re: [patch] direct-io: propagate -ENOSPC errors

This looks good to me. Reviewed-by: Carlos Maiolino On Mon, Mar 14, 2016 at 05:10:00PM -0400, Jeff Moyer wrote: > dio_bio_complete turns all errors into -EIO. This is historical, > since you used to only get 1 bit precision for errors (BIO_UPTODATE). > Now that we get

Re: [patch] direct-io: propagate -ENOSPC errors

This looks good to me. Reviewed-by: Carlos Maiolino On Mon, Mar 14, 2016 at 05:10:00PM -0400, Jeff Moyer wrote: > dio_bio_complete turns all errors into -EIO. This is historical, > since you used to only get 1 bit precision for errors (BIO_UPTODATE). > Now that we get actual error codes, we

Re: [PATCH] qla2xxx: avoid maybe_uninitialized warning

On Wed, 2016-03-16 at 16:03 +0100, Tomas Henzl wrote: > On 15.3.2016 22:40, Arnd Bergmann wrote: > > The qlt_check_reserve_free_req() function produces an incorrect warning > > when CONFIG_PROFILE_ANNOTATED_BRANCHES is set: > > > > drivers/scsi/qla2xxx/qla_target.c: In function

Re: [PATCH] qla2xxx: avoid maybe_uninitialized warning

On Wed, 2016-03-16 at 16:03 +0100, Tomas Henzl wrote: > On 15.3.2016 22:40, Arnd Bergmann wrote: > > The qlt_check_reserve_free_req() function produces an incorrect warning > > when CONFIG_PROFILE_ANNOTATED_BRANCHES is set: > > > > drivers/scsi/qla2xxx/qla_target.c: In function

[PATCH] PKCS#7: fix missing break on OID_sha224 case

From: Colin Ian King The OID_sha224 case is missing a break and it falls through to the -ENOPKG error default. Since HASH_ALGO_SHA224 seems to be supported, this looks like an unintentional missing break. Fixes: 07f081fb5057 ("PKCS#7: Add OIDs for sha224, sha284 and

[PATCH] PKCS#7: fix missing break on OID_sha224 case

From: Colin Ian King The OID_sha224 case is missing a break and it falls through to the -ENOPKG error default. Since HASH_ALGO_SHA224 seems to be supported, this looks like an unintentional missing break. Fixes: 07f081fb5057 ("PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos and use

[PATCH 1/2] of: Implement iterator for phandles

From: Joerg Roedel Getting the arguments of phandles is somewhat limited at the moement, because the number of arguments supported by core code is limited to MAX_PHANDLE_ARGS, which is set to 16 currently. In case of the arm smmu this is not enough, as the 128 supported

[PATCH 1/2] of: Implement iterator for phandles

From: Joerg Roedel Getting the arguments of phandles is somewhat limited at the moement, because the number of arguments supported by core code is limited to MAX_PHANDLE_ARGS, which is set to 16 currently. In case of the arm smmu this is not enough, as the 128 supported stream-ids are encoded

Re: Suspicious error for CMA stress test

Hi Vlastimil, Joonsoo, Am Freitag, den 18.03.2016, 00:52 +0900 schrieb Joonsoo Kim: > 2016-03-18 0:43 GMT+09:00 Vlastimil Babka : > > On 03/17/2016 10:24 AM, Hanjun Guo wrote: > >> > >> On 2016/3/17 14:54, Joonsoo Kim wrote: > >>> > >>> On Wed, Mar 16, 2016 at 05:44:28PM +0800,

Re: Suspicious error for CMA stress test

Hi Vlastimil, Joonsoo, Am Freitag, den 18.03.2016, 00:52 +0900 schrieb Joonsoo Kim: > 2016-03-18 0:43 GMT+09:00 Vlastimil Babka : > > On 03/17/2016 10:24 AM, Hanjun Guo wrote: > >> > >> On 2016/3/17 14:54, Joonsoo Kim wrote: > >>> > >>> On Wed, Mar 16, 2016 at 05:44:28PM +0800, Hanjun Guo wrote:

[PATCH v3 2/3] ARM: DTS: da850/am4372/am33xx: Use generic node name for ehrpwm

When possible generic node names should be used. So change the node name from ehrpwm to pwm. Signed-off-by: Franklin S Cooper Jr --- Version 3 changes: Also update am335x-shc.dts arch/arm/boot/dts/am335x-shc.dts | 2 +- arch/arm/boot/dts/am33xx.dtsi| 6 +++---

[PATCH v3 2/3] ARM: DTS: da850/am4372/am33xx: Use generic node name for ehrpwm

When possible generic node names should be used. So change the node name from ehrpwm to pwm. Signed-off-by: Franklin S Cooper Jr --- Version 3 changes: Also update am335x-shc.dts arch/arm/boot/dts/am335x-shc.dts | 2 +- arch/arm/boot/dts/am33xx.dtsi| 6 +++---

Re: kernel/irq: Null-ptr deref on handle_irq_event_percpu function

On Wed, 16 Mar 2016, Baozeng Ding wrote: > +linux-kernel and irq maitainer. > > On Thu, Feb 25, 2016 at 04:16:10AM -0500, Red Hat Product Security wrote: > > > > > > I cannot produce the bug, but by taking a look at the > > > code(irq/handle.c line176), it may > > > casue a null pointer deref: >

Re: kernel/irq: Null-ptr deref on handle_irq_event_percpu function

On Wed, 16 Mar 2016, Baozeng Ding wrote: > +linux-kernel and irq maitainer. > > On Thu, Feb 25, 2016 at 04:16:10AM -0500, Red Hat Product Security wrote: > > > > > > I cannot produce the bug, but by taking a look at the > > > code(irq/handle.c line176), it may > > > casue a null pointer deref: >

Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

On 03/14/2016 08:37 PM, Toshi Kani wrote: [... snip ...] >> Joe at Stratus also hit this issue but on a system where MTRR is enabled. >> He sent his report only to me as he thought it was caused by the >> ioremap_wc() changes and his driver was one that got it. In his case >> though he modified

Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

On 03/14/2016 08:37 PM, Toshi Kani wrote: [... snip ...] >> Joe at Stratus also hit this issue but on a system where MTRR is enabled. >> He sent his report only to me as he thought it was caused by the >> ioremap_wc() changes and his driver was one that got it. In his case >> though he modified

[PATCH v3 3/3] pwm: pwm-tiehrpwm: Update dt binding document to use generic node name

Now that the node name has been changed from ehrpwm to pwm the document should show this proper usage. Also change the unit address in the example from 0 to the proper physical address value that should be used. Signed-off-by: Franklin S Cooper Jr --- Version 3 changes: N/A

[PATCH v3 3/3] pwm: pwm-tiehrpwm: Update dt binding document to use generic node name

Now that the node name has been changed from ehrpwm to pwm the document should show this proper usage. Also change the unit address in the example from 0 to the proper physical address value that should be used. Signed-off-by: Franklin S Cooper Jr --- Version 3 changes: N/A Version 2 changes:

Re: [PATCH] mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case

On 4 March 2016 at 10:41, Ulf Hansson wrote: > On 3 March 2016 at 16:28, Ulf Hansson wrote: >> On 16 February 2016 at 05:06, Magnus Damm wrote: >>> From: Magnus Damm >>> >>> This patch adds

Re: [PATCH] mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case

On 4 March 2016 at 10:41, Ulf Hansson wrote: > On 3 March 2016 at 16:28, Ulf Hansson wrote: >> On 16 February 2016 at 05:06, Magnus Damm wrote: >>> From: Magnus Damm >>> >>> This patch adds comments to describe the various ways card detection >>> may be implemented and when polling is needed.

[PATCH 1/1] linux-firmware: Update AMD microcode patch firmware

For AMD Family 15h Processors to fix bugs in prior microcode patch file: amd-ucode/microcode_amd_fam15h.bin md5sum: 2384ef1d8ec8ca3930b62d82ea5a3813 Version: 2016_03_16 Signed-off-by: Sherry Hurwitz --- WHENCE | 2 +-

[PATCH 1/1] linux-firmware: Update AMD microcode patch firmware

For AMD Family 15h Processors to fix bugs in prior microcode patch file: amd-ucode/microcode_amd_fam15h.bin md5sum: 2384ef1d8ec8ca3930b62d82ea5a3813 Version: 2016_03_16 Signed-off-by: Sherry Hurwitz --- WHENCE | 2 +- amd-ucode/microcode_amd_fam15h.bin |

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