Re: [PATCH] fs/buffer: simplify the code flow of LRU management algorithm

On 09/28/15 at 02:52pm, yalin wang wrote: > why not change like this: > > diff --git a/fs/buffer.c b/fs/buffer.c > index 82283ab..d6769f1 100644 > --- a/fs/buffer.c > +++ b/fs/buffer.c > @@ -1287,40 +1287,31 @@ static inline void check_irqs_on(void) > */ > static void bh_lru_install(struct

Re: [PATCH v7 07/60] PCI: kill wrong quirk about M7101

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > Meelis reported that qla2000 driver does not get loaded on one sparc system. > > schizo f00732d0: PCI host bridge to bus 0001:00 > pci_bus 0001:00: root bus resource [io 0x7fe0100-0x7fe01ff] (bus > address [0x-0xff]) > pci

Re: [PATCH v7 11/60] PCI: Check pref compatible bit for mem64 resource of PCIe device

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > We still get "no compatible bridge window" warning on sparc T5-8 > after we add support for 64bit resource parsing for root bus. > > PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8 > PCI: Claiming :00:01.0: Resource 15:

Re: [PATCH v7 10/60] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > For device resource PREF bit setting under bridge 64-bit pref resource, > we need to make sure only set PREF for 64bit resource, so set > IORESOUCE_MEM_64 for 64bit resource during OF device resource flags > parsing. > > Link:

Re: [PATCH v7 02/60] sparc/PCI: Use correct bus address to resource offset

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > After we add 64bit mmio parsing, we got some "no compatible bridge window" > warning on anther new model that support 64bit resource. > > It turns out that we can not use mem_space.start as 64bit mem space > offset, aka mem_space.start !=

Re: [PATCH v7 12/60] PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > If any bridge up to root only have 32bit pref mmio, We don't need to > treat device non-pref mmio64 as as pref mmio64. > > We need to move pci_bridge_check_ranges calling early. > for parent bridges pref mmio BAR may not allocated by BIOS,

Re: [PATCH v7 01/60] sparc/PCI: Add mem64 resource parsing for root bus

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > Found "no compatible bridge window" warning in boot log from T5-8. > > pci :00:01.0: can't claim BAR 15 [mem 0x1-0x4afff pref]: no > compatible bridge window > > That resource is above 4G, but does not get offset correctly

Re: [PATCH v4] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

On 09/10/2015 18:01, Måns Rullgård wrote: > Marc Gonzalez wrote: > >> Måns Rullgård wrote: >> >>> Marc Gonzalez wrote: >>> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. >>> >>> Given the nature of this hardware,

Re: [PATCH] debugfs: Add debugfs_create_ulong()

On 10/09, Viresh Kumar wrote: > @@ -87,6 +89,8 @@ struct dentry *debugfs_create_x32(const char *name, umode_t > mode, > struct dentry *parent, u32 *value); > struct dentry *debugfs_create_x64(const char *name, umode_t mode, > struct

Re: [PATCH v3] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

On Fri, 9 Oct 2015, Daniel Lezcano wrote: > On 10/09/2015 03:46 PM, Marc Gonzalez wrote: > > On 09/10/2015 15:24, Daniel Lezcano wrote: > > [ ... ] > > > On a tangential subject, it would seem that platforms with verbose logs > > at init might benefit from marking as __initconst strings used in

Re: [PATCH] clk: add support for Sigma Designs SMP86xx/87xx clocks

On 09/10/2015 14:35, Mans Rullgard wrote: > This adds support for most of the clocks in the Sigma Designs > SMP86xx (tango3) and SMP87xx (tango4) chips. > > Signed-off-by: Mans Rullgard > --- > I'm sending this now to avoid the maintainers wasting more time reviewing > the

Re: [PATCH] dmaengine: zxdma: fix memset that is currently doing nothing

On Thu, Oct 08, 2015 at 06:01:34PM +0100, Colin King wrote: > From: Colin Ian King > > The size and value arguments are swapped in the call to memset > effectively making it a no-op because of the zero size. Swap > these arguments around to do the memset correctly.

[PATCH] ARM: tegra: Comment out gpio-ranges properties

From: Thierry Reding While the addition of these properties is technically correct it unveils a bug with deferred probe. The problem is that the presence of the gpio- range property causes the gpio-tegra driver to defer probe (it needs the pinctrl driver to be ready). That's

Re: linux-next: Tree for Oct 9 (bluetooth/bpa10x.c)

Hi Randy, >> Changes since 20151008: >> > > on i386: > > warning: (BT_HCIBPA10X) selects BT_HCIUART_H4 which has unmet direct > dependencies (NET && BT && BT_HCIUART) > > drivers/built-in.o: In function `bpa10x_rx_complete': > bpa10x.c:(.text+0x2ac5e2): undefined reference to `h4_recv_buf'

Re: [PATCH v4 3/6] iommu: add ARM short descriptor page table allocator.

On Tue, Sep 22, 2015 at 03:12:47PM +0100, Yong Wu wrote: > I would like to show you a problem I met, The recursion here may > lead to stack overflow while we test FHD video decode. > > From the log, I get the internal variable in the error case: the > "size" is 0x10, the "iova" is

Re: [PATCH v8 0/9] Goodix touchscreen enhancements

On Thu, 8 Oct 2015 17:23:42 +0300 Irina Tirdea wrote: > Add several enhancements to the Goodix touchscreen driver. > > The new functionality is only available for devices that > declare named gpio pins for interrupt and reset in their > ACPI/DT configuration. > I

Re: [PATCH 1/3] doc: dt: fpga: Added Documentation for Xilinx Zynq FPGA manager.

On Fri, Oct 09, 2015 at 12:45:05AM +0200, Moritz Fischer wrote: > Signed-off-by: Moritz Fischer > --- > .../bindings/fpga/xilinx-zynq-fpga-mgr.txt | 26 > ++ > 1 file changed, 26 insertions(+) > create mode 100644 >

Re: [PATCH v2 3/3] stop_machine: change cpu_stop_queue_two_works() to rely on stopper->enabled

On Thu, Oct 08, 2015 at 07:01:41PM +0200, Oleg Nesterov wrote: > @@ -261,12 +276,8 @@ int stop_two_cpus(unsigned int cpu1, unsigned int cpu2, > cpu_stop_fn_t fn, void * > set_state(, MULTI_STOP_PREPARE); > > /* > - * If we observe both CPUs active we know _cpu_down() cannot yet

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

On Fri, Oct 09, 2015 at 05:32:52PM +0100, Mark Rutland wrote: > On Fri, Oct 09, 2015 at 05:09:10PM +0100, Liviu Dudau wrote: > > On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote: > > > On Friday 09 October 2015 16:44:08 Mark Rutland wrote: > > > > On Fri, Oct 09, 2015 at 03:11:07PM

Re: [Bugfix v4 2/2] ACPI, PCI: Prevent binding other PCI drivers to IOAPIC PCI devices

On Fri, Oct 09, 2015 at 10:07:32PM +0800, Jiang Liu wrote: > The ACPI IOAPIC driver makes use of IOAPIC PCI devices, so prevent > binding other PCI drivers to IOAPIC PCI devices used by ACPI IOAPIC > driver. > > Signed-off-by: Jiang Liu > --- > drivers/acpi/ioapic.c |

Re: [PATCH v2] spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message

On Fri, Oct 09, 2015 at 05:29:26PM +0200, Neil Armstrong wrote: > On 10/09/2015 05:26 PM, Michael Welling wrote: > > On Fri, Oct 09, 2015 at 03:47:41PM +0200, Neil Armstrong wrote: > >> Since the "Switch driver to use transfer_one" change, the cs_change > >> behavior has changed and a channel chip

Re: [PATCH v2 4/5] firmware: generalize reading file contents as a helper

On Fri, Oct 09, 2015 at 08:46:42AM -0400, Josh Boyer wrote: > On Thu, Oct 8, 2015 at 6:54 PM, Luis R. Rodriguez wrote: > > On Thu, Oct 08, 2015 at 01:36:53PM -0400, Josh Boyer wrote: > >> On Thu, Oct 1, 2015 at 1:44 PM, Luis R. Rodriguez > >> wrote: > >>

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

On Friday 09 October 2015 16:44:08 Mark Rutland wrote: > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote: > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote: > > Or maybe I can claim the use of the string on account on being the first on > > arm64 > > > > I can add a

Re: [PATCH v2] dmaengine: xgene-dma: Disable memcpy operation due to performance drop

On Thu, Oct 08, 2015 at 02:36:57PM +0530, Rameshwar Prasad Sahu wrote: > The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other > computations. But the bandwidth of the entire DMA engine is shared > among all channels. This patch re-configures operations availability > such that one

Re: [PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver

On Fri, Oct 09, 2015 at 01:02:11PM -0300, Fabio Estevam wrote: > On Fri, Oct 9, 2015 at 1:00 PM, Russell King - ARM Linux > wrote: > > >> Thanks, Russell! > >> > >> Got audio to play on my HDMI TV :-) > >> > >> For the entire series: > >> > >> Tested-by: Fabio Estevam

Re: [PATCH v5 1/4] Docs: dt: Add PCI MSI map bindings

On 10/09/2015 06:20 AM, Rob Herring wrote: On Thu, Oct 8, 2015 at 5:10 PM, David Daney wrote: From: Mark Rutland Currently msi-parent is used by a few bindings to describe the relationship between a PCI root complex and a single MSI controller,

Re: [RFD] pstore: pmsg: ramoops: add multiple pmsg instances

On 10/08/2015 06:52 PM, Hiraku Toyooka wrote: > Hello, > > I'm trying to make the feature of multiple pmsg instances for ramoops. I like it, in fact I encourage it. This is somewhat/exactly what I did when I first created pmsg, but decided to simplify to one instance for the first release because

Re: [PATCH v2 1/2] devicetree: add binding for generic mmio clocksource

Måns Rullgård writes: > Rob Herring writes: > >> On Wed, Oct 7, 2015 at 11:47 AM, Måns Rullgård wrote: >>> What would be a proper way to select a sched_clock source? I realise >>> it's a Linux-specific thing and DT is supposed to be

Re: [PATCH v7 05/60] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > For device resource PREF bit setting under bridge 64-bit pref resource, > we need to make sure only set PREF for 64bit resource, so set > IORESOUCE_MEM_64 for 64bit resource during of device resource flags > parsing. > > Link:

Re: [PATCH v7 04/60] sparc/PCI: Reserve legacy mmio after PCI mmio

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > On one system found bunch of claim resource fail from pci device. > pci_sun4v f02b894c: PCI host bridge to bus :00 > pci_bus :00: root bus resource [io 0x2007e-0x2007e0fff] (bus > address [0x-0xfff]) > pci_bus

Re: [PATCH v7 14/60] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > If host bridge does not have mmio64 above 4G, We don't need to > treat device non-pref mmio64 as as pref mmio64. > > Signed-off-by: Yinghai Lu Tested on sparc platforms Tested-by: Khalid Aziz

Re: [PATCH v7 15/60] PCI: Restore pref MMIO allocation logic for host bridge without mmio64

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > From 5b2854155 (PCI: Restrict 64-bit prefetchable bridge windows to 64-bit > resources), we change the logic for pref mmio allocation: > When bridge pref support mmio64, we will only put children pref > that support mmio64 into it, and will

Re: [PATCH v7 13/60] PCI: Add has_mem64 for struct host_bridge

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > Add has_mem64 for struct host_bridge, on root bus that does not support > mmio64 above 4g, will not set that. > > We will use that info next two following patches: > 1. Don't treat non-pref mmio64 as pref mmio, so will not put >it under

Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on Juno R1

On Fri, Oct 09, 2015 at 05:09:10PM +0100, Liviu Dudau wrote: > On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote: > > On Friday 09 October 2015 16:44:08 Mark Rutland wrote: > > > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote: > > > > On Fri, Oct 09, 2015 at 08:54:33AM

Re: [PATCH] mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD

Awesome! Thanks Ulf! :) cheers grant On Mon, Oct 5, 2015 at 3:55 AM, Ulf Hansson wrote: > On 24 September 2015 at 03:30, Grant Grundler wrote: >> MMC_IOC_CMD and MMC_IOC_MULTI_CMD ioctl() code currently bails on >> any eMMC errors. However, in

Re: [PATCH v2] dmaengine: xgene-dma: Disable memcpy operation due to performance drop

Hi Vinod, On Fri, Oct 9, 2015 at 9:42 PM, Vinod Koul wrote: > On Thu, Oct 08, 2015 at 02:36:57PM +0530, Rameshwar Prasad Sahu wrote: >> The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other >> computations. But the bandwidth of the entire DMA engine is shared

Re: [PATCH v7 06/60] sparc/PCI: Keep resource idx order with bridge register number

On Thu, 2015-10-08 at 14:38 -0700, Yinghai Lu wrote: > On one system found strang "no compatible bridge window" warning > > PCI: Claiming :00:01.0: Resource 14: 00020001..000200010fff > [10220c] > PCI: Claiming :01:00.0: Resource 1: 00020001..00020001 >

Re: [PATCH v2 3/3] stop_machine: change cpu_stop_queue_two_works() to rely on stopper->enabled

On 10/09, Peter Zijlstra wrote: > > I stuck that on top.. Yes, exactly! Plus I'll send another (minor) cleanup on top of this if everything goes right. > I'll have a closer look at the 7 patches later > when I might be more coherent (mad head-ache atm.) Thanks! Hmm... but please please see

[PATCHv3] ARM64:Fix MINSIGSTKSZ and SIGSTKSZ

MINSIGSTKSZ and SIGSTKSZ for ARM64 are not correctly set in latest kernel. This patch fixes this issue. This issue is reported in LTP (testcase: sigaltstack02.c). Testcase failed when sigaltstack() called with stack size "MINSIGSTKSZ - 1" Since in Glibc-2.22, MINSIGSTKSZ is set to 5120 but in

pidns: Make pid accounting and pid_max per namespace

I started multiple docker containers in centos6.6(linux-2.6.32-504.16.2), and there's one bad program was running in one container. This program produced many child threads continuously without free, so more and more pid numbers were consumed by this program, until hitting the pix_max limit

Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

On Fri, 9 Oct 2015, Miroslav Lichvar wrote: > On Fri, Oct 09, 2015 at 10:46:16AM +0100, Thomas Gleixner wrote: > > On Thu, 8 Oct 2015, Miroslav Lichvar wrote: > > > Applications are not allowed to rely on system time being sane? > > > To me the current behavior looks like the kernel is throwing

[PATCH] pcnet32: fix a logic error with pci_set_dma_mask

pcnet32 can't work on my machine recently. It says "architecture does not support 32bit PCI busmaster DMA". There is a logic error in it: pci_set_dma_mask() return 0 means return successfully. Signed-off-by: Geliang Tang --- drivers/net/ethernet/amd/pcnet32.c | 2 +- 1 file

Re: [PATCH v2 07/22] arm64: Keep track of CPU feature registers

On 08/10/15 10:55, Suzuki K. Poulose wrote: On 07/10/15 18:16, Catalin Marinas wrote: On Mon, Oct 05, 2015 at 06:01:56PM +0100, Suzuki K. Poulose wrote: diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 1ae8b24..d42ad90 100644 ---

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote: > > > - RELEASE -> ACQUIRE _chains_ (on shared variables) preserve causality, > >(because each link is fully ordered) but are not transitive. > > Yup, and that's the same for UNLOCK -> LOCK, too. Agreed, except RELEASE/ACQUIRE is

Hello

Chevrolet auto mobile company selected your email for the electronic Balloting. 900,000.00 USD was issued to you as winner send name,address and mobile for claim: chev.cla...@yandex.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus --

RE: [PATCH 04/12] mwifiex: use ktime_get_real for timestamping

Hi Arnd, > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Wednesday, September 30, 2015 4:57 PM > To: net...@vger.kernel.org > Cc: y2...@lists.linaro.org; linux-kernel@vger.kernel.org; David S. > Miller; Arnd Bergmann; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; >

[PATCH v5 0/7] arm64: berlin: add pinctrl support

This series adds support for Marvell berlin4ct pin-controller, allowing to configure the pin muxing from the device tree. Since v4: - drop ARCH_BERLIN dependency for it has been met - drop COMPILE_TEST dependency but make berlin pinctrl driver visible if COMPILE_TEST=y, and let this change

[PATCH v5 4/7] arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs

This is to add the pinctrl dependency for Marvell Berlin SoCs. Signed-off-by: Jisheng Zhang --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index c6e2c75..3d17ee2 100644 ---

[PATCH v5 6/7] arm64: dts: berlin4ct: add the pinctrl node

Add the avio, soc, sm pinctrl nodes for Marvell berlin4ct SoC. Signed-off-by: Jisheng Zhang --- arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi

[PATCH v5 2/7] pinctrl: berlin: Make berlin pinctrl driver visible if COMPILE_TEST=y

It is good to allow berlin pinctrl driver to build with COMPILE_TEST, so make the it menu visible when compile-testing. Signed-off-by: Jisheng Zhang --- drivers/pinctrl/berlin/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c

async_pf_execute() seems to be missing a memory barrier which might cause the waker to not notice the waiter and miss sending a wake_up as in the following figure. async_pf_executekvm_vcpu_block

[PATCH] regulator: core: avoid unused variable warning

The second argument of the mutex_lock_nested() helper is only evaluated if CONFIG_DEBUG_LOCK_ALLOC is set. Otherwise we get this build warning for the new regulator_lock_supply function: drivers/regulator/core.c: In function 'regulator_lock_supply': drivers/regulator/core.c:142:6: warning: unused

[PATCH] netfilter: turn NF_HOOK into an inline function

A recent change to the dst_output handling caused a new warning when the call to NF_HOOK() is the only used of a local variable passed as 'dev', and CONFIG_NETFILTER is disabled: net/ipv6/ip6_output.c: In function 'ip6_output': net/ipv6/ip6_output.c:135:21: warning: unused variable 'dev'

Re: [PATCH v2 4/5] firmware: generalize reading file contents as a helper

On Thu, Oct 8, 2015 at 6:54 PM, Luis R. Rodriguez wrote: > On Thu, Oct 08, 2015 at 01:36:53PM -0400, Josh Boyer wrote: >> On Thu, Oct 1, 2015 at 1:44 PM, Luis R. Rodriguez >> wrote: >> > From: David Howells >> > >> > We'll want to

Re: [PATCH v2] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c

On Fri, Oct 09, 2015 at 12:21:55PM +, Kosuke Tatsukawa wrote: > + * Memory barrier is required here to make sure change to > + * vcpu->async_pf.done is visible from other CPUs. This memory > + * barrier pairs with prepare_to_wait's set_current_state() That is not how memory

Re: [RFC]: Possible race condition in kernel futex code

Hans, On Fri, 9 Oct 2015, Hans Zuidam wrote: > On 9 okt. 2015, at 11:06, Thomas Gleixner wrote: > > You cannot use an explicit 32bit read. We need an access which > > handles the fault gracefully. > > The reason for the explicit read suggestion is to avoid the >

Re: [PATCH] x86/PCI: Don't alloc pcibios-irq when MSI is enabled

On Fri, 9 Oct 2015, Joerg Roedel wrote: > From: Joerg Roedel > > The pcibios-irq and MSI both use dev->irq to store the IRQ > number. While the MSI code checks for that and frees the > pcibios-irq before overwriting dev->irq, the > pcibios_alloc_irq function does not. > >

Re: [PATCHv3] ARM64:Fix MINSIGSTKSZ and SIGSTKSZ

On Friday 09 October 2015 11:33:52 Will Deacon wrote: > Acked-by: Will Deacon > > Arnd: are you planning to take this via asm-generic, or shall I queue it > on the arm64 fixes branch? > Please merge it for arm64 with my Acked-by: Arnd Bergmann

Re: [PATCH v3] tpm, tpm_crb: fix unaligned read of the command buffer address

Hi This would desperately neeed Tested-by's (with Haswell PTT). /Jarkko On Tue, Sep 15, 2015 at 08:05:40PM +0300, Jarkko Sakkinen wrote: > The command buffer address must be read with exactly two 32-bit reads. > Otherwise, on some HW platforms, it seems that HW will abort the read > operation,

Re: [PATCH 1/5] thermal: exynos: Fix unbalanced regulator disable on probe failure

W dniu 09.10.2015 o 01:45, Alim Akhtar pisze: > Hello, > > On Thu, Oct 8, 2015 at 11:04 AM, Krzysztof Kozlowski > wrote: >> During probe if the regulator could not be enabled, the error exit path >> would still disable it. This could lead to unbalanced counter of >>

Re: Re: [PATCHv3] ARM64:Fix MINSIGSTKSZ and SIGSTKSZ

>> MINSIGSTKSZ and SIGSTKSZ for ARM64 are not correctly set in latest kernel. >> This patch fixes this issue. >> >> This issue is reported in LTP (testcase: sigaltstack02.c). >> Testcase failed when sigaltstack() called with stack size "MINSIGSTKSZ - 1" >> Since in Glibc-2.22, MINSIGSTKSZ is set

[PATCH v3] arm: Adding support for atomic half word exchange

Hello Will, Thank you so much for your patience. My sincere apologies with the issues with formatting. I have taken care of them and hope now things are ok. - Included patchesATarm.linux.org.uk. - Removed the changelog from commit message. - Moved the patch to "superseded" in patch system. -

Re: [PATCH] kvm: svm: Only propagate next_rip when guest supports it

On 09/10/2015 11:51, Joerg Roedel wrote: > From: Joerg Roedel > > Currently we always write the next_rip of the shadow vmcb to > the guests vmcb when we emulate a vmexit. This could confuse > the guest when its cpuid indicated no support for the > next_rip feature. > > Fix

Re: [PATCH 1/5] leds: core: Drivers shouldn't enforce SYNC/ASYNC brightness setting

On Fri 2015-10-09 10:08:12, Jacek Anaszewski wrote: > On 10/09/2015 09:02 AM, Pavel Machek wrote: > >On Fri 2015-10-09 08:28:44, Jacek Anaszewski wrote: > >>On 10/08/2015 05:50 PM, Pavel Machek wrote: > >>>On Mon 2015-09-21 16:29:26, Jacek Anaszewski wrote: > This patch removes

Re: [RFC V3] regmap: change bool to 1 bit variable in struct regmap

On Fri, Oct 09, 2015 at 03:51:22PM +0800, yalin wang wrote: > This patch change some bool variables in struct regmap { } > to be u8 v : 1 type, so that we can shrink the sizeof of struct regmap. This still doesn't apply against current code - I'm looking for something that applies at least

Re: [PATCH V1 0/2] Add DA9021 support to the existing DA9052/53 driver

On Thu, Oct 08, 2015 at 04:17:52PM +0100, Steve Twiss wrote: > From: Steve Twiss > > Two patches to add missing registers and add support for DA9053-BB > silicon in the regulators component. These patches modify existing > files for the Dialog Power Management IC

PLS I NEED YOUR HELP!

I am Mrs Zaara Heyet an oil-servicing equipment merchant, am writing this mail to you with tears and love from my heart of charity work i could not fulfill before the end of my days due to my present healness ,Please do not think of this letter as one of those being sent around to ask for

[PATCH v3] mm,thp: reduce ifdef'ery for THP in generic code

- pgtable-generic.c: Fold individual #ifdef for each helper into a top level #ifdef. Makes code more readable - Converted the stub helpers for !THP to BUILD_BUG() vs. runtime BUG() Signed-off-by: Vineet Gupta --- Somehow the msg didn't make it to mailing list ! ---

Re: [PATCH v2 net-next 1/3] bpf: enable non-root eBPF programs

Hi, Alexei Starovoitov writes: > On 10/8/15 11:20 AM, Hannes Frederic Sowa wrote: >> Hi Alexei, >> >> On Thu, Oct 8, 2015, at 07:23, Alexei Starovoitov wrote: >>> The feature is controlled by sysctl kernel.unprivileged_bpf_disabled. >>> This toggle defaults to off (0), but

Re: [PATCH v8 0/9] Goodix touchscreen enhancements

On Friday 09 October 2015 11:02:01 Tirdea, Irina wrote: > > -Original Message- > > From: linux-input-ow...@vger.kernel.org > > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Arnd Bergmann > > Sent: 08 October, 2015 17:32 > > To: Tirdea, Irina > > Cc: Dmitry Torokhov; Bastien

[PATCH] HID: hiddev: change hiddev_connect() to return bool

Since hid_connect() only cares about hiddev_connect() succeeding or failing, there is no need for this function to return an int and it can return a bool instead. Suggested-by: Jiri Kosina Signed-off-by: Luis de Bethencourt --- Hi, The suggestion to

Re: [PATCH] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c

On 09/10/2015 11:04, Kosuke Tatsukawa wrote: > smp_store_mb() called from set_current_state(), which is called from > prepare_to_wait() should prevent reordering such as below from > happening. wait_event*() also calls set_current_state() inside. Ah, I missed that set_current_state has a

Re: [PATCHv3] ARM64:Fix MINSIGSTKSZ and SIGSTKSZ

On Fri, Oct 09, 2015 at 03:59:40PM +0530, Manjeet Pawar wrote: > MINSIGSTKSZ and SIGSTKSZ for ARM64 are not correctly set in latest kernel. > This patch fixes this issue. > > This issue is reported in LTP (testcase: sigaltstack02.c). > Testcase failed when sigaltstack() called with stack size

Re: [PATCH] can: at91: remove at91_can_data

On 09/10/2015 at 12:07:40 +0200, Marc Kleine-Budde wrote : > On 10/08/2015 04:56 PM, Alexandre Belloni wrote: > > struct at91_can_data was used to pass a callback to the driver, allowing it > > to switch the transceiver on and off. As all at91 boards are now using DT, > > this is not used anymore,

Re: [PATCH v2 0/2] KVM: x86: fix edge EOI and IOAPIC reconfig race

On 08/10/2015 20:23, Radim Krčmář wrote: > v2: > * rewritten [1/2] and > * refactored [2/2], all thanks to Paolo's comments > > This problem is not fixed for split userspace part as I think that it > would be better to solve that by excluding edge interrupts from > eoi_exit_bitmap (see the

Re: [PATCH v9 2/3] tpm: move the PPI attributes to character device directory.

This would need Tested-by's. I've run it both with dTPM 2.0 and fTPM based platforms. It would require testing with TPM 1.2 chip to make sure it doesn't break anything. Thank you. /Jarkko On Tue, Sep 29, 2015 at 10:36:32AM +0300, Jarkko Sakkinen wrote: > Moved PPI attributes to the character

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote: > Stepping back a second, I believe that there are three cases: > > > RELEASE X -> ACQUIRE Y (same CPU) >* Needs a barrier on TSO architectures for full ordering +PPC > UNLOCK X -> LOCK Y (same CPU) >* Needs a

Re: [PATCH v2 01/12] leds: core: Use EXPORT_SYMBOL_GPL consistently

On Fri 2015-10-09 10:19:48, Jacek Anaszewski wrote: > On 10/08/2015 05:51 PM, Pavel Machek wrote: > >On Mon 2015-09-28 17:13:39, Jacek Anaszewski wrote: > >>This patch isn't going to be applied since it can cause > >>legal implications for existing users. > >> > > > >Are there any? Best do this

[PATCH 1/6] staging: comedi: don't poll_wait on same subdevice twice

Comedi subdevices that support asynchronous acquisition commands have a wait queue head used for blocking reads or writes and for the poll file operation. The comedi device may have several subdevices that support "read" and/or "write" commands, but each open file object has at most one "read"

[PATCH 6/6] staging: comedi: don't use mutex when polling file

The main mutex in a comedi device can get held for quite a while when processing comedi instructions, so for performance reasons, the "read" and "write" file operations do not use it; they use use the `attach_lock` rwsemaphore to protect against the comedi device becoming detached at an

[PATCH 3/6] staging: comedi: add new comedi_buf_write_n_available()

Add a new function `comedi_buf_write_n_available()` to return the amount of buffer space available for writing, including space already allocated by `comedi_buf_write_alloc()` plus any unallocated space available. This is currently just for internal use by the comedi core, so is not exported.

[PATCH 2/6] staging: comedi: rename comedi_buf_write_n_available

Rename the local function `comedi_buf_write_n_available()` to `comedi_buf_write_n_unalloc()`. It is the amount of unallocated space available in the buffer that is available to be allocated for writing and does not include the space that has already been allocated for writing. This is unlike the

[PATCH 5/6] staging: comedi: check command started by file being polled

Currently, the "poll" file operation checks if an asynchronous "read" (or "write" command is active on the "read" (or "write" subdevice, but does not consider whether the command was started from the file object being polled. Since that is the only file object able to read (or write) data, take

Re: [PATCH v4 5/8] clk: rockchip: Allow the RK3288 SPDIF clocks to change their parent

Hey Heiko, On Thu, 2015-10-08 at 17:10 +0200, Heiko Stuebner wrote: > Am Donnerstag, 8. Oktober 2015, 15:31:16 schrieb Sjoerd Simons: > > The clock branches leading to sclk_spdif and sclk_spdif_8ch on > > RK3288 > > SoCs only feed those clocks, allow those clocks to change their > > parents > >

RE: [PATCH 05/12] mwifiex: avoid gettimeofday in ba_threshold setting

Hi Arnd, > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Wednesday, September 30, 2015 4:57 PM > To: net...@vger.kernel.org > Cc: y2...@lists.linaro.org; linux-kernel@vger.kernel.org; David S. > Miller; Arnd Bergmann; Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; >

Re: [PATCH] thermal: exynos: fix register read in TMU

2015-10-08 23:21 GMT+09:00 Sudip Mukherjee : > On Fri, Oct 02, 2015 at 08:43:52AM +0900, Krzysztof Kozlowski wrote: >> 2015-10-01 23:12 GMT+09:00 Sudip Mukherjee : >> > On Thu, Oct 01, 2015 at 10:18:57PM +0900, Krzysztof Kozlowski wrote: >>

Re: [RFC]: Possible race condition in kernel futex code

On Fri, Oct 09, 2015 at 11:25:09AM +0100, Thomas Gleixner wrote: > Hans, > > On Fri, 9 Oct 2015, Hans Zuidam wrote: > > On 9 okt. 2015, at 11:06, Thomas Gleixner wrote: > > > You cannot use an explicit 32bit read. We need an access which > > > handles the fault gracefully. >

Re: [PATCH v2] block: flush queued bios when the process blocks

Hi Mike, [auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore] config: x86_64-lkp (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): In file included from

Re: [PATCH] thermal: exynos: fix register read in TMU

Hi Krzysztof, > 2015-10-08 23:21 GMT+09:00 Sudip Mukherjee > : > > On Fri, Oct 02, 2015 at 08:43:52AM +0900, Krzysztof Kozlowski wrote: > >> 2015-10-01 23:12 GMT+09:00 Sudip Mukherjee > >> : > >> > On Thu, Oct 01, 2015 at 10:18:57PM +0900,

[PATCH] md: fix 32-bit build warning

On 32-bit architectures, the md code produces this warning when CONFIG_LDAF is set: drivers/md/md.c: In function 'check_sb_changes': drivers/md/md.c:8990:10: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'sector_t {aka long long unsigned int}'

Re: [PATCH] HID: hiddev: change hiddev_connect() to return bool

Hi Luis, [auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore] config: x86_64-lkp (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >>

[PATCH v3] clocksource/drivers/tango_xtal: Add new timer for Tango SoCs

Sigma Designs Tango platforms provide a 27 MHz crystal oscillator. Use it for clocksource, sched_clock, and delay_timer. Signed-off-by: Marc Gonzalez --- I have a nagging feeling that the QUIT_IF macro will get this patch NAKed ;-) My rationale: error-handling

Re: [PATCH v2 2/5] mmc: sdhci-pxav3: enable usage of DAT3 pin as HW card detect

On Fri, 9 Oct 2015 03:03:52 +0200 Marcin Wojtas wrote: > Marvell Armada 38x SDHCI controller enable using DAT3 pin as a hardware > card detection. According to the SD sdandard this signal can be used for > this purpose combined with a pull-up resistor, implying inverted

Re: [PATCH] panic: release stale console lock to always get the logbuf printed out

Vitaly Kuznetsov writes: > Andrew Morton writes: > >> On Thu, 08 Oct 2015 12:03:25 +0200 Vitaly Kuznetsov >> wrote: >> >>> > If we picked up patch "kernel: Avoid softlockups in >>> > stop_machine() during heavy printing"

Re: [RFCv5 PATCH 25/46] sched: Add over-utilization/tipping point indicator

On Tue, Sep 29, 2015 at 01:08:46PM -0700, Steve Muckle wrote: > On 08/14/2015 06:02 AM, Morten Rasmussen wrote: > > To be sure not to break smp_nice, we have defined over-utilization as > > when: > > > > cpu_rq(any)::cfs::avg::util_avg + margin > cpu_rq(any)::capacity > > > > is true for any cpu

[PATCH] net: HNS: fix MDIO dependencies

The newly introduced HNS_MDIO Kconfig symbol selects 'MDIO', but that is the wrong symbol as the code used by this driver is provided by PHYLIB rather than the MDIO driver. Also, there is no need to make this driver user selectable, because it is already selected by all drivers that need it. This

Re: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote: > > > I realize that building things as modules is a hassle, it is so for > > some things more than for others, so I keep asking the question > > to everyone to find out what a good balance is to make as much as > > possible modules without

Re: [PATCH][RFC] mm: Introduce kernelcore=reliable option

On 2015/10/9 17:24, Kamezawa Hiroyuki wrote: > On 2015/10/09 15:46, Xishi Qiu wrote: >> On 2015/10/9 22:56, Taku Izumi wrote: >> >>> Xeon E7 v3 based systems supports Address Range Mirroring >>> and UEFI BIOS complied with UEFI spec 2.5 can notify which >>> ranges are reliable (mirrored) via EFI

Re: [tip:irq/core] genirq: Handle force threading of irqs with primary and thread handler

On Tue, 6 Oct 2015, Felipe Balbi wrote: > this commit causes a performance regression for the USB driver on > several platforms (anybody using drivers/usb/dwc3, basically). > > Here's the USB throughput with linux-next in 3 different scenarios: > > 1) Linux next without threadirqs cmdline > >

Re: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

W dniu 09.10.2015 o 19:28, Arnd Bergmann pisze: > On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote: >> >>> I realize that building things as modules is a hassle, it is so for >>> some things more than for others, so I keep asking the question >>> to everyone to find out what a good balance

<    8   9   10   11   12   13   14   15   16   17   >