On Wed, Jul 23, 2014 at 8:52 AM, Christian König
wrote:
>> In the preliminary patches where I can sync radeon with other GPU's I've
>> been very careful in all the places that call into fences, to make sure that
>> radeon wouldn't try to handle lockups for a different (possibly also radeon)
>> car
On 2014年07月15日 18:58, Zhou Wang wrote:
Signed-off-by: Zhou Wang
---
.../devicetree/bindings/mtd/hisi-nand.txt | 40
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/hisi-nand.txt
Hi Randy Dunlap,
Is there anything
On 07/23/2014 05:15 AM, Kees Cook wrote:
On Tue, Jul 22, 2014 at 2:14 AM, AKASHI Takahiro
wrote:
Arm64 holds a syscall number in w8(x8) register. Ptrace tracer may change
its value either to:
* any valid syscall number to alter a system call, or
* -1 to skip a system call
This patch impl
Am 23.07.2014 08:50, schrieb Oded Gabbay:
On 22/07/14 14:15, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
On 22/07/14 12:21, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay
wrote:
Exactly, just prevent userspace from submitting more. And
On Wed, Jul 23, 2014 at 8:50 AM, Oded Gabbay wrote:
> On 22/07/14 14:15, Daniel Vetter wrote:
>>
>> On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
>>>
>>> On 22/07/14 12:21, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay
wrote:
>>
>> Exactl
op 23-07-14 08:52, Christian König schreef:
> Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
>> op 22-07-14 17:59, Christian König schreef:
>>> Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
wrote:
> Drivers exporting fences need to prov
Hi,
On Tue, Jul 22, 2014 at 04:33:54PM -0500, Bin Liu wrote:
> On Wed, Jul 9, 2014 at 5:17 AM, Antoine Ténart
> wrote:
> > diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
> > index 7cccab6ff308..9a9702773e43 100644
> > --- a/drivers/usb/chipidea/debug.c
> > +++ b/drivers/
On 07/23/2014 05:16 AM, Kees Cook wrote:
On Tue, Jul 22, 2014 at 2:14 AM, AKASHI Takahiro
wrote:
(Please apply this patch after my audit patch in order to avoid some
conflict on arm64/Kconfig.)
This patch enables secure computing (system call filtering) on arm64.
System calls can be allowed or
On Mon, Jul 21, 2014 at 06:39:00PM +0300, Tuomas Tynkkynen wrote:
[...]
> diff --git a/drivers/cpufreq/tegra124-cpufreq.c
> b/drivers/cpufreq/tegra124-cpufreq.c
[...]
> +static int tegra124_cpu_switch_to_dfll(void)
> +{
> + struct clk *original_cpu_clk_parent;
Maybe just "parent"?
> + un
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
wrote:
>> Can we somehow avoid the need to call fence_signal() at all? The interrupts
>> at least on radeon are way to unreliable for such a thing. Can
>> enable_signalling fail? What's the reason for fence_signaled() in the first
>> place?
> I
Am 23.07.2014 09:09, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
wrote:
Can we somehow avoid the need to call fence_signal() at all? The interrupts at
least on radeon are way to unreliable for such a thing. Can enable_signalling
fail? What's the reason for fence_
On 07/23/2014 09:58 AM, Peter Zijlstra wrote:
> On Wed, Jul 23, 2014 at 09:07:32AM +0300, Adrian Hunter wrote:
>> On 07/22/2014 05:11 PM, Peter Zijlstra wrote:
>>> On Tue, Jul 22, 2014 at 11:00:34AM -0300, Arnaldo Carvalho de Melo wrote:
Em Tue, Jul 22, 2014 at 04:17:10PM +0300, Adrian Hunter
On Mon, Jul 21, 2014 at 9:09 PM, Tuomas Tynkkynen wrote:
> Add a new cpufreq driver for Tegra124. Instead of using the PLLX as
> +
> +static int tegra124_cpu_switch_to_dfll(void)
> +{
> + struct clk *original_cpu_clk_parent;
> + unsigned long rate;
> + struct dev_pm_opp *opp;
On Wed, Jul 23, 2014 at 12:28:21PM +0530, Viresh Kumar wrote:
> On 23 July 2014 12:24, Thierry Reding wrote:
> > On Wed, Jul 23, 2014 at 10:14:44AM +0530, Viresh Kumar wrote:
> >> On 21 July 2014 21:09, Tuomas Tynkkynen wrote:
> >>
> >> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq
On Wed, 2014-07-23 at 08:57 +0200, Peter Zijlstra wrote:
> On Wed, Jul 23, 2014 at 06:55:03AM +0200, Mike Galbraith wrote:
> > On Mon, 2014-07-21 at 09:42 -0700, Andi Kleen wrote:
> >
> > > FWIW the main problem is currently that switch-through-idle is so
> > > slow. I think improving that would
Am 23.07.2014 09:06, schrieb Maarten Lankhorst:
op 23-07-14 08:52, Christian König schreef:
Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
op 22-07-14 17:59, Christian König schreef:
Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
wrote:
Drivers
On Wed, Jul 23, 2014 at 12:26:20AM +0200, Rafael J. Wysocki wrote:
> All of that indicates that the machine in question has WoL based on native
> PCIe
> PME signaling. In that case it doesn't wake up from the "freeze" state,
> because
> some code is missing.
Didn't wake, but it did show:
:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
wrote:
> It's not a locking problem I'm talking about here. Radeons lockup handling
> kicks in when anything calls into the driver from the outside, if you have a
> fence wait function that's called from the outside but doesn't handle
> lockups you
op 23-07-14 09:15, Christian König schreef:
> Am 23.07.2014 09:09, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
>> wrote:
Can we somehow avoid the need to call fence_signal() at all? The
interrupts at least on radeon are way to unreliable for such a thing
On Wed, 23 Jul 2014, Stephen Rothwell wrote:
> On Tue, 22 Jul 2014 10:22:08 +0100 Lee Jones wrote:
> >
> > Can I have another branch in -next please?
> >
> > > Sure, if you think you meet the criteria, then send me a URL:
> > >
> > > You will need to ensure that the patches/commits in your tree/
On Wed, Jul 23, 2014 at 09:25:46AM +0200, Mike Galbraith wrote:
> I also resurrect mwait_idle(), as while you may consider it obsolete, I
> still love my lovely little Q6600 box (power sucking pig) dearly :)
Yeah, I keep forgetting about that one.. we should get that fixed.
--
To unsubscribe from
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
wrote:
It's not a locking problem I'm talking about here. Radeons lockup handling
kicks in when anything calls into the driver from the outside, if you have a
fence wait function that's called from the
On Wed, 2014-07-23 at 09:35 +0200, Peter Zijlstra wrote:
> On Wed, Jul 23, 2014 at 09:25:46AM +0200, Mike Galbraith wrote:
> > I also resurrect mwait_idle(), as while you may consider it obsolete, I
> > still love my lovely little Q6600 box (power sucking pig) dearly :)
>
> Yeah, I keep forgettin
Many thanks Tony! And thanks goes to Borislav and Robert too.
Regards,
Tomasz
On 22.07.2014 23:08, Tony Luck wrote:
On Tue, Jul 22, 2014 at 2:20 AM, Tomasz Nowicki
wrote:
APEI is currently implemented so that it depends on x86 hardware.
The primary dependency is that GHES uses the x86 NMI for
Hi Jiri,
On Mon, 21 Jul 2014 11:07:55 +0200, Jiri Olsa wrote:
> On Wed, Jul 09, 2014 at 02:28:08PM +0900, Namhyung Kim wrote:
>> Hello,
>>
>> This patchset is to control perf report/top output column width by
>> -w/--column-widths option so that it can fit into the terminal size.
>> The -w option
Am 23.07.2014 09:32, schrieb Maarten Lankhorst:
op 23-07-14 09:15, Christian König schreef:
Am 23.07.2014 09:09, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
wrote:
Can we somehow avoid the need to call fence_signal() at all? The interrupts at
least on radeon are
Make of_device_id array const, because all OF functions handle it as const.
Signed-off-by: Kiran Padwal
---
drivers/usb/phy/phy-msm-usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 78cc870..e4108ee 10
On 22 July 2014 20:45, Rik van Riel wrote:
> Currently update_sd_pick_busiest only returns true when an sd
> is overloaded, or for SD_ASYM_PACKING when a domain is busier
> than average and a higher numbered domain than the target.
>
> This breaks load balancing between domains that are not overlo
This patch only handle "L1 and L2 vm share one apic access page" situation.
When L1 vm is running, if the shared apic access page is migrated, mmu_notifier
will
request all vcpus to exit to L0, and reload apic access page physical address
for
all the vcpus' vmcs (which is done by patch 5/6). And
gfn_to_page() will finally call hva_to_pfn() to get the pfn, and pin the page
in memory by calling GUP functions. This function unpins the page.
Will be used by the followed patches.
Signed-off-by: Tang Chen
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 17 -
2
We have APIC_DEFAULT_PHYS_BASE defined as 0xfee0, which is also the address
of
apic access page. So use this macro.
Signed-off-by: Tang Chen
---
arch/x86/kvm/svm.c | 3 ++-
arch/x86/kvm/vmx.c | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arc
On 2014-07-22 at 17:00:44 +0200, Suman Anna wrote:
> Hi Tobias,
>
> On 07/22/2014 07:13 AM, Tobias Klauser wrote:
> > Use the module_platform_driver to omit module init/exit boilerplate code.
> >
> > Signed-off-by: Tobias Klauser
> > ---
> > drivers/mailbox/mailbox-omap1.c | 13 +
>
On Wed 23-07-14 01:29:32, Andreas Bombe wrote:
> On Mon, Jul 21, 2014 at 12:04:34PM +0200, Jan Kara wrote:
> > On Sat 19-07-14 00:50:05, Andreas Bombe wrote:
> > > I don't see anything in /sys/kernel/debug/tracing/trace_pipe or
> > > .../trace (besides the header) with your patch applied. In case y
In init_rmode_identity_map(), there two variables indicating the return
value, r and ret, and it return 0 on error, 1 on success. The function
is only called by vmx_create_vcpu(), and r is redundant.
This patch removes the redundant variable r, and make init_rmode_identity_map()
return 0 on succes
kvm_arch->ept_identity_pagetable holds the ept identity pagetable page. But
it is never used to refer to the page at all.
In vcpu initialization, it indicates two things:
1. indicates if ept page is allocated
2. indicates if a memory slot for identity page is initialized
Actually, kvm_arch->ept_i
Le 21/07/2014 06:13, David Miller a écrit :
> From: Cyrille Pitchen
> Date: Fri, 18 Jul 2014 16:21:14 +0200
>
>> +if (tx_skb->mapped_as_page) {
>> +dma_unmap_page(&bp->pdev->dev, tx_skb->mapping,
>> + tx_skb->size, DMA_TO_DEVICE);
apic access page is pinned in memory. As a result, it cannot be
migrated/hot-removed.
Actually, it is not necessary to be pinned.
The hpa of apic access page is stored in VMCS APIC_ACCESS_ADDR pointer. When
the page is migrated, kvm_mmu_notifier_invalidate_page() will invalidate the
corresponding
* Nick Krause [140722 14:12]:
> static void __init irq_pm_init(void)
> 382 {
> 383 /* FIXME: Remove this when MPU OSWR support is added */
> 384 if (!soc_is_omap54xx())
> 385 cpu_pm_register_notifier(&irq_notifier_block);
> 386 }
> I am wondering is this omap suppor
ept identity pagetable and apic access page in kvm are pinned in memory.
As a result, they cannot be migrated/hot-removed.
But actually they don't need to be pinned in memory.
[For ept identity page]
Just do not pin it. When it is migrated, guest will be able to find the
new page in the next ept
op 23-07-14 09:37, Christian König schreef:
> Am 23.07.2014 09:31, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:26 AM, Christian König
>> wrote:
>>> It's not a locking problem I'm talking about here. Radeons lockup handling
>>> kicks in when anything calls into the driver from the outside,
On Wed, Jul 23, 2014 at 09:39:03AM +0200, Mike Galbraith wrote:
> On Wed, 2014-07-23 at 09:35 +0200, Peter Zijlstra wrote:
> > On Wed, Jul 23, 2014 at 09:25:46AM +0200, Mike Galbraith wrote:
> > > I also resurrect mwait_idle(), as while you may consider it obsolete, I
> > > still love my lovely li
We need interrupts disabled when calling console_trylock_for_printk()
only so that cpu id we pass to can_use_console() remains valid (for
other things console_sem provides all the exclusion we need and
deadlocks on console_sem due to interrupts are impossible because we use
down_trylock()). Howeve
Regardless of the fence implementation, why would it be a good idea to do a
full lockup recovery when some other driver is
calling your wait function? That doesn't seem to be a nice thing to do, so I
think a timeout is the best error you could return here,
other drivers have to deal with that an
Hi Kishon,
On 07/22/2014 09:23 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 21 July 2014 01:09 PM, Lee Jones wrote:
>> Hi Kishon,
>>
This patchset is based on the two core patches you sent to the
list which facilitate creating PHYs residing on multi-channel
controllers. T
On Wed, Jul 23, 2014 at 9:37 AM, Christian König
wrote:
> Am 23.07.2014 09:31, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:26 AM, Christian König
>> wrote:
>>>
>>> It's not a locking problem I'm talking about here. Radeons lockup
>>> handling
>>> kicks in when anything calls into the driv
On Wed, Jul 23, 2014 at 9:58 AM, Christian König
wrote:
> Just imagine an application using prime is locking up Radeon and because of
> that gets killed by the user. Nothing else in the system would use the
> Radeon hardware any more and so radeon gets only called by another driver
> waiting patie
>>> On 11.07.14 at 00:58, wrote:
> On 07/03/2014 07:35 AM, Jan Beulich wrote:
>> Relying on static functions used just once to get inlined (and
>> subsequently have dead code paths eliminated) is wrong: Compilers are
>> free to decide whether they do this, regardless of optimization level.
>> With
On 23/07/14 07:06, Yoshihiro YUNOMAE wrote:
> Current code allocates too much data for tty_groups member of uart_port
> struct,
> so fix it.
>
> Signed-off-by: Yoshihiro YUNOMAE
> CC: Greg Kroah-Hartman
> CC: Dan Carpenter
Reviewed-by: Daniel Thompson
(using linux-next tree for context).
--
This driver is a general version for tps611xx backlgiht chips of TI.
It supports tps61158, tps61161, tps61163 and tps61165 backlight driver
based on EasyScale protocol(1-Wire Control Interface).
EasyScale
EasyScale is a simple but flexible one pin interface to configure the current.
The interface
This commit is about tps611xx device tree documentation.
Signed-off-by: Daniel Jeong
---
[v6]
Nothing changed from v5. Driver files were changed
---
.../video/backlight/tps611xx-backlight.txt | 26
1 file changed, 26 insertions(+)
create mode 100644
Documentation
This driver a general version for tps611xx backlgiht chips of TI.
It supports tps61158, tps61161, tps61163 and tps61165 backlight driver
based on EasyScale protocol.
Daniel Jeong (2):
[RFC v6 1/2] backlight: add new tps611xx backlight driver
[RFC v6 2/2] backlight: device tree: add new tps611x
On 2014/7/22 1:47, Nishanth Aravamudan wrote:
> On 11.07.2014 [15:37:45 +0800], Jiang Liu wrote:
>> Current kernel only updates _mem_id_[cpu] for onlined CPUs when memory
>> configuration changes. So kernel may allocate memory from remote node
>> for a CPU if the CPU is still in absent or offline
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
drivers/infiniband/hw/cxgb4/device.c between commit da388973d4a1
("iw_cxgb4: fix for 64-bit integer division") from the net-next tree
and commit "drivers/infiniband/hw/cxgb4/device.c: fix 32-bit builds"
from the akpm tree.
I f
Am 23.07.2014 10:07, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:58 AM, Christian König
wrote:
Just imagine an application using prime is locking up Radeon and because of
that gets killed by the user. Nothing else in the system would use the
Radeon hardware any more and so radeon gets only
On śro, 2014-07-23 at 10:40 +0900, Chanwoo Choi wrote:
> This patch add missing REGMAP_I2C/REGMAP_IRQ dependency on extcon provider
> driver to protect build break.
>
> Signed-off-by: Chanwoo Choi
> ---
> drivers/extcon/Kconfig | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/driver
On 2014/7/22 1:57, Nishanth Aravamudan wrote:
> On 21.07.2014 [10:41:59 -0700], Tony Luck wrote:
>> On Mon, Jul 21, 2014 at 10:23 AM, Nishanth Aravamudan
>> wrote:
>>> It seems like the issue is the order of onlining of resources on a
>>> specific x86 platform?
>>
>> Yes. When we online a node t
On Wednesday 23 July 2014 01:28 PM, Maxime Coquelin wrote:
> Hi Kishon,
>
> On 07/22/2014 09:23 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Monday 21 July 2014 01:09 PM, Lee Jones wrote:
>>> Hi Kishon,
>>>
> This patchset is based on the two core patches you sent to the
> list whic
On Wednesday 23 July 2014 03:03 AM, Bjorn Helgaas wrote:
> On Thu, Jul 17, 2014 at 02:30:39PM +0530, Kishon Vijay Abraham I wrote:
>> Changes from v2:
>> * Added myself as MAINTAINER of pcie dra7xx driver
>>
>> Changes from v1:
>> * fixed dw_pcie_prog_viewport_io_outbound() to use untranslated ad
On 23 July 2014 12:54, Thierry Reding wrote:
> ARM_TEGRA_CPUFREQ is still optional, so the select only applies when the
> Tegra cpufreq driver is enabled. This is mostly just out of convenience,
> though. The Tegra cpufreq driver uses the generic CPU0 cpufreq driver so
> a select will automaticall
op 23-07-14 10:20, Christian König schreef:
> Am 23.07.2014 10:07, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 9:58 AM, Christian König
>> wrote:
>>> Just imagine an application using prime is locking up Radeon and because of
>>> that gets killed by the user. Nothing else in the system would
On Wed, Jul 23, 2014 at 08:03:47AM +0100, AKASHI Takahiro wrote:
> On 07/23/2014 05:15 AM, Kees Cook wrote:
> > On Tue, Jul 22, 2014 at 2:14 AM, AKASHI Takahiro
> > wrote:
> >> asmlinkage int syscall_trace_enter(struct pt_regs *regs)
> >> {
> >> + unsigned long saved_x0, saved_x8;
> >> +
ACPI 5.0 resource types like FixedDMA will fail pnpacpi_allocated_resource().
pnpacpi_add_device() has to return error in that case.
On 23 July 2014 03:42, Rafael J. Wysocki wrote:
> On Wednesday, July 23, 2014 12:43:39 AM Arjun Sreedharan wrote:
>> Handle error condition since pnpacpi_parse_allo
From: Varka Bhadram
> On 07/23/2014 11:31 AM, Alexei Starovoitov wrote:
> > BPF is used in several kernel components. This split creates logical
> > boundary
> > between generic eBPF core and the rest
> >
> > kernel/bpf/core.c: eBPF interpreter
> >
> > net/core/filter.c: classic->eBPF converter, c
On Wed, Jul 23, 2014 at 05:05:24PM +0900, Michel Dänzer wrote:
> On 23.07.2014 15:49, Peter Zijlstra wrote:
> Attached. No FAIL messages yet.
> [0.467570] __sdt_alloc: allocated 8802155ea4c0 with cpus:
> [0.467574] __sdt_alloc: allocated 8802155ea3c0 with cpus:
> [0.467576] _
>>> On 16.07.14 at 17:19, wrote:
> Hi Jan, Michal,
>
> I am not sure who maintains genksyms officially, so I am sending this
> question to the two of you as folks who seemed to have contributed to the
> tool. :-)
>
> I noticed with genksyms that a symbol is opaquely defined in a
> public header
Am 23.07.2014 10:01, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:37 AM, Christian König
wrote:
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
wrote:
It's not a locking problem I'm talking about here. Radeons lockup
handling
kicks in when any
Add basic support for rx busy polling. Instead of introducing new
states and spinlock to synchronize between NAPI and polling method,
this patch just reuse NAPI state to avoid extra overhead for fast path
and simplified the codes.
Test was done between a kvm guest and an external host. Two hosts w
Move common receive logic to a new helper virtnet_receive(). It will
also be used by rx busy polling method.
Cc: Rusty Russell
Cc: Michael S. Tsirkin
Cc: Vlad Yasevich
Cc: Eric Dumazet
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 19 ++-
1 file changed, 14 inserti
Hi all:
This series introduces the support for rx busy polling support. This
was useful for reduing the latency for a kvm guest. Instead of
introducing new states and spinlocks, this series re-uses NAPI state
to synchonrize between NAPI and busy polling. This grealy simplified
the codes and reduce
On 23/07/14 10:05, Daniel Vetter wrote:
On Wed, Jul 23, 2014 at 8:50 AM, Oded Gabbay wrote:
On 22/07/14 14:15, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
On 22/07/14 12:21, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:19 AM, Oded Gabbay
wrote:
On Tue, Jul 22, 2014 at 03:48:02PM -0400, Peter Hurley wrote:
> [ +cc Tejun ]
>
> On 07/22/2014 03:26 PM, Jesse Brandeburg wrote:
> > This is a repeatable panic, happens every boot (and prevents starting my
> > system)
> >
> >
> >
> > [8.732993] sd 6:0:1:0: [sdb] Attached SCSI disk
> > [
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
wrote:
> In this case if the sync was to i915 the i915 lockup procedure would take
> care of itself. It wouldn't fix radeon, but it would at least unblock your
> intel card again. I haven't specifically added a special case to attempt to
> unb
Hi,
I am wondering if we could improve the design of the system call a bit
to prevent programming errors.
Right now, EINVAL is returned in case of invalid flags (or in the older
version of getrandom() also if buflen is too large), EFAULT if buf is an
invalid address and EAGAIN if there is not enou
On Tue, Jul 15, 2014 at 12:48 AM, Bjorn Andersson wrote:
> On Wed, Jul 9, 2014 at 2:32 AM, Linus Walleij
> wrote:
>> On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson
> [...]
>> "direction" also seems a bit bool ... even "output_value".
>>
>
> "direction" is 2 bits that can be both be set, unfort
Hi Linus,
After merging the gpio tree, today's linux-next build (powerpc
allyesconfig) produced these warnings:
drivers/gpio/gpio-ucb1400.c: In function 'ucb1400_gpio_remove':
drivers/gpio/gpio-ucb1400.c:92:2: warning: ignoring return value of
'gpiochip_remove', declared with attribute warn_unus
On Wed, Jul 23, 2014 at 10:45 AM, Stephen Rothwell
wrote:
> After merging the gpio tree, today's linux-next build (powerpc
> allyesconfig) produced these warnings:
>
> drivers/gpio/gpio-ucb1400.c: In function 'ucb1400_gpio_remove':
> drivers/gpio/gpio-ucb1400.c:92:2: warning: ignoring return val
Am 23.07.2014 10:42, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
wrote:
In this case if the sync was to i915 the i915 lockup procedure would take care
of itself. It wouldn't fix radeon, but it would at least unblock your intel
card again. I haven't specifically
This driver also supports S2MPU02 now, thus update module description and
Kconfig accordingly.
Signed-off-by: Axel Lin
---
drivers/regulator/Kconfig | 4 ++--
drivers/regulator/s2mps11.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/
* Nishanth Menon [140722 11:34]:
> On 07/22/2014 11:47 AM, Felipe Balbi wrote:
> > On Tue, Jul 22, 2014 at 10:39:54AM -0500, Nishanth Menon wrote:
> >> The DRA74/72 control module pins have a weak pull up and pull down.
> >> This is configured by bit offset 17. if BIT(17) is 1, a pull up is
> >> s
Hi all,
Changes since 20140721:
New trees: backlight, signal-cleanup
The net-next tree lost its build failure and gained a conflict against
the wireless tree.
The drm tree gained a conflict against the drm-intel-fixes tree.
The drm-intel tree gained conflicts against the drm tree.
The scsi tr
On 07/23/2014 08:11 AM, Varka Bhadram wrote:
On 07/23/2014 11:31 AM, Alexei Starovoitov wrote:
BPF is used in several kernel components. This split creates logical boundary
between generic eBPF core and the rest
kernel/bpf/core.c: eBPF interpreter
net/core/filter.c: classic->eBPF converter, cl
On Wed, 23 Jul 2014, Jassi Brar wrote:
> Introduce common framework for client/protocol drivers and
> controller drivers of Inter-Processor-Communication (IPC).
>
> Client driver developers should have a look at
> include/linux/mailbox_client.h to understand the part of
> the API exposed to clien
On Wed, Jul 23, 2014 at 10:46 AM, Christian König
wrote:
> Am 23.07.2014 10:42, schrieb Daniel Vetter:
>
>> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
>> wrote:
>>>
>>> In this case if the sync was to i915 the i915 lockup procedure would take
>>> care of itself. It wouldn't fix radeon, b
(2014/07/22 17:04), Wanpeng Li wrote:
> [ 220.262093] BUG: unable to handle kernel NULL pointer dereference at
> 0004
> [ 220.262104] IP: [] find_busiest_group+0x2b9/0xa30
> [ 220.262111] PGD 5a9d5067 PUD 13067 PMD 0
> [ 220.262117] Oops: [#3] SMP
> [...]
> [ 220.262245] Call
Currently, although IP_MULTICAST_ALL and IP_MSFILTER ioctl calls succeed on
raw sockets, there is no code to implement the functionality on received
packets; it is only implemented for UDP sockets. The raw(7) man page states:
"In addition, all ip(7) IPPROTO_IP socket options valid for datagram sock
Hi Felipe,
On Monday 21 July 2014 08:45 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jul 21, 2014 at 05:04:57PM +0200, Laurent Pinchart wrote:
>> Hi Felipe,
>>
>> What happened to these two patches ?
>
> looks like I lost them.
>
>> On Monday 16 December 2013 17:48:29 Felipe Balbi wrote:
>>> On Mo
* Marek Belisko [140722 12:32]:
> Following patchset add various improvements to gta04 devicetree.
>
> Changes from v1:
> - added description to all patches
>
> Marek Belisko (7):
> arm: dts: omap3-gta04: Add nand support
> arm: dts: omap3-gta04: Fix magnetometer model
> arm: dts: omap3-gt
On 07/23/2014 02:50 AM, Rafael J. Wysocki wrote:
On Monday, June 30, 2014 07:59:32 PM Stratos Karafotis wrote:
Hi all,
This patchset changes slightly the calculation of target frequency to
eliminate the deadband effect (explained in patch 2 changelog) that it
seems to slow down the CPU in low a
On 07/23/2014 06:11 AM, Tejun Heo wrote:
> Hello,
>
> Can you please test the following patch?
Tested-by: Alexey Kardashevskiy
on POWER8 + IBM IPR SCSI.
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index d19c37a7..773f4e6 100644
> --- a/drivers/ata/libata-core.c
This adds a driver for the backlight controlled by the microcontroller
on the Compaq iPAQ series of handheld computers: h3100, h3600
and h3700.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Add a comment to clarify message format
- Coding format and style fixes
- Drop driver announce boile
I am seeing a bug in clone() on the Alpha architecture. Reported to
Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755397
The test suite of glibc sometimes fails in the nptl/tst-eintr3 test
with a segmentation fault. I have tracked it down to the thread
pointer returned by the rduni
In the current world, all nonboot cpus are enabled serially during system
resume. System resume sequence is that boot cpu enables nonboot cpu one by
one and then resume devices. Before resuming devices, there are few tasks
assigned to nonboot cpus after they are brought up. This waste cpu usage.
T
On 07/23/2014 05:25 PM, Will Deacon wrote:
On Wed, Jul 23, 2014 at 08:03:47AM +0100, AKASHI Takahiro wrote:
On 07/23/2014 05:15 AM, Kees Cook wrote:
On Tue, Jul 22, 2014 at 2:14 AM, AKASHI Takahiro
wrote:
asmlinkage int syscall_trace_enter(struct pt_regs *regs)
{
+ unsigned long s
On Tue 22-07-14 15:47:53, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> vm_insert_mixed() will fail if there is already a valid PTE at that
> location. The DAX code would rather replace the previous value with
> the new PTE.
>
> Signed-off-by: Matthew Wilcox
This looks good to me although
Changed in v5:
- add "*chan_dev = dma->chan_using->device->dev" for reduce the call time.
- add the test logs.
Changed in v4:
- cancelled "i2c_imx->use_dma".
- changed "Dma" to "DMA".
- add Timeout handling for Transfer complete.
Changed in v3:
- fix a bug when request the dma faild.
- some mi
Add dma support for i2c. This function depend on DMA driver.
You can turn on it by write both the dmas and dma-name properties in dts node.
Signed-off-by: Yuan Yao
---
drivers/i2c/busses/i2c-imx.c | 377 +--
1 file changed, 324 insertions(+), 53 deletions(
KSM thread to scan pages is getting schedule on definite timeout.
That wakes up CPU from idle state and hence may affect the power
consumption. Provide an optional support to use deferred timer
which suites low-power use-cases.
To enable deferred timers,
$ echo 1 > /sys/kernel/mm/ksm/deferred_time
Add i2c dts node properties for eDMA support, them depend on the eDMA driver.
Signed-off-by: Yuan Yao
---
Documentation/devicetree/bindings/i2c/i2c-imx.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt
b/Documentation/devicetr
On Wednesday, July 23, 2014 4:38 PM, Kiran Padwal wrote:
>
> Make of_device_id array const, because all OF functions handle it as const.
Hi Kiran Padwal,
The same patch was already submitted and merged to USB tree.
Thank you.
Best regards,
Jingoo Han
>
> Signed-off-by: Kiran Padwal
> ---
>
于 2014年07月23日 00:40, Peter Hurley 写道:
> On 07/22/2014 07:52 AM, xinhui.pan wrote:
>>
>> 于 2014年07月21日 23:38, Greg KH 写道:
>>> On Mon, Jul 21, 2014 at 08:47:16PM +0800, pp wrote:
As reuse the cdev may cause panic. After we unregister the tty device, we
may use tty_hangup() o
other s
1 - 100 of 892 matches
Mail list logo
