From: Andrew Murray
DT bindings for PCI host bridges often use the ranges property to describe
memory and IO ranges - this binding tends to be the same across architectures
yet several parsing implementations exist, e.g. arch/mips/pci/pci.c,
arch/powerpc/kernel/pci-common.c,
Hi,
These patches add a few device tree helpers that are used are partially
shared by Thomas' Marvell PCIe controller and my Tegra PCIe controller
series. In an attempt to decrease the number of dependencies between
trees, it would be nice to get these in for 3.9. There are a few ARM
specific
This function can be used to parse the number of a device's parent PCI
bus from a standard 5-cell PCI resource.
Signed-off-by: Thierry Reding
---
drivers/of/of_pci.c| 21 +
include/linux/of_pci.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/of/of_pci.c
This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.
Signed-off-by: Thierry Reding
---
Changes in v2:
- rename devfn and err
On Mon, Feb 11, 2013 at 10:21:18AM +0200, Luciano Coelho wrote:
> In commit 0d2e7a5c (wireless: Remove unnecessary alloc/OOM messages,
> alloc cleanups) OOM messages after alloc were removed from the wlcore
> modules.
>
> Commit afb43e6d (wlcore: remove if_ops from platform_data)
> reintroduced a
From: Namjae Jeon
This patch is a follow up on below patch:
[PATCH] exportfs: add FILEID_INVALID to indicate invalid fid_type
commit: 216b6cbdcbd86b1db0754d58886b466ae31f5a63
Signed-off-by: Namjae Jeon
Signed-off-by: Vivek Trivedi
Acked-by: Steven Whitehouse
---
fs/btrfs/export.c |4
-replace "baud" with "current-speed"
-if uart alias doesn't exist in DT, don't abort, pick 0
Signed-off-by: Vineet Gupta
Cc: Greg Kroah-Hartman
Cc: Grant Likely
Cc: Arnd Bergmann
Cc: devicetree-disc...@lists.ozlabs.org
Cc: Rob Herring
Cc: Rob Landley
Cc: linux-ser...@vger.kernel.org
Cc:
On Sun, Feb 10, 2013 at 06:58:15AM +0100, Len Brown wrote:
> From: Len Brown
>
> pm_idle() and idle() served no purpose on cris --
> invoke default_idle() directly.
>
> Signed-off-by: Len Brown
> Cc: linux-cris-ker...@axis.com
Looks good!
Acked-by: Jesper Nilsson
> ---
>
On 02/09/2013 02:08 AM, Len Brown wrote:
> From: Len Brown
>
> This field is no longer used.
>
> Signed-off-by: Len Brown
Acked-by: Daniel Lezcano
> ---
> include/linux/cpuidle.h | 22 --
> 1 file changed, 22 deletions(-)
>
> diff --git a/include/linux/cpuidle.h
On Sunday 10 February 2013 at 17:30:47, Wolfram Sang wrote:
> > what happend to this one ? It was a patch updating Kconfig help for
> > at24.
>
> Do you know linux-next? Have a look there...
Thank you for the hint and for commiting it.
Lars
--
To unsubscribe from this list: send the line
On 02/09/2013 02:08 AM, Len Brown wrote:
> From: Len Brown
>
> Cosmetic only.
>
> Replace use of MWAIT_MAX_NUM_CSTATES with CPUIDLE_STATE_MAX.
> They are both 8, so this patch has no functional change.
>
> The reason to change is that intel_idle will soon be able
> to export more than the 8
Some of the platform devices rely on the name of their driver to match with. In
the current implementation, if platform id table is needed, they have to add
the name to the platform id table which sounds alogical. The patch adjustes the
logic of the id table matching to make sure we will fall-back
* Fengguang Wu wrote:
> Greetings,
>
> I got the below oops and the first bad commit is
It's a one-time warning, not an actual crash, right?
> commit b29f39c7c3e75a741a7da88244ec707f293ec04c
> Author: Chuansheng Liu
> Date: Wed Feb 6 23:18:21 2013 +0800
>
> smp: Give WARN()ing if
On Tue, Feb 05, 2013 at 07:57:22PM -0700, Shuah Khan wrote:
> Fix the following compile warning in kvm_register_steal_time():
> CC arch/x86/kernel/kvm.o
> arch/x86/kernel/kvm.c: In function ‘kvm_register_steal_time’:
> arch/x86/kernel/kvm.c:302:3: warning: format ‘%lx’ expects argument of
On 11 February 2013 14:22, Fengguang Wu wrote:
> Greetings,
Hi Fengguang,
> I got the below oops and the first bad commit is
>
> commit 50f6802f8dccb7bbad29010e57973d46b7e7a07e
> Author: Viresh Kumar
> Date: Thu Feb 7 10:55:00 2013 +0530
There is something really wrong. This problem was
On Mon, Feb 11, 2013 at 10:03:09AM +0100, Ingo Molnar wrote:
>
> * Fengguang Wu wrote:
>
> > Greetings,
> >
> > I got the below oops and the first bad commit is
>
> It's a one-time warning, not an actual crash, right?
Yes, it is.
Thanks,
Fengguang
--
To unsubscribe from this list: send the
On Sat, Feb 09, 2013 at 06:54:45PM +0100, Geert Uytterhoeven wrote:
> s390 allmodconfig:
>
> drivers/gpu/drm/udl/udl_fb.c:237:52: error: 'PAGE_SHARED' undeclared (first
> use in this function)
> drivers/media/pci/zoran/zoran_driver.c:2955:14: error: 'PAGE_SHARED'
> undeclared (first use in this
On 02/10/2013 06:58 AM, Len Brown wrote:
> From: Len Brown
>
> Update APM to register its local idle routine with cpuidle.
>
> This allows us to stop exporting pm_idle to modules on x86.
>
> The Kconfig sub-option, APM_CPU_IDLE, now depends on on CPU_IDLE.
>
> Compile-tested only.
>
>
* Oleg Nesterov [2013-02-04 18:20:10]:
>
> But so far I think that a chain of multiple consumers makes no sense.
> Each consumer->handler() will use the same call->perf_events list, this
> will only complicate the code for no reason.
>
> > However with allowing prefiltering, we need to have
* Oleg Nesterov [2013-01-31 20:18:29]:
> trace_uprobe->consumer and "struct uprobe_trace_consumer" add the
> unnecessary indirection and complicate the code for no reason.
>
> This patch simply embeds uprobe_consumer into "struct trace_uprobe",
> all other changes only fix the compilation
* Oleg Nesterov [2013-01-31 20:18:32]:
> Move tu->nhit++ from uprobe_trace_func() to uprobe_dispatcher().
>
> ->nhit counts how many time we hit the breakpoint inserted by this
> uprobe, we do not want to loose this info if uprobe was enabled by
> sys_perf_event_open().
>
> Signed-off-by: Oleg
* Fengguang Wu wrote:
> Greetings,
>
> I got the below oops in linux-next and the first bad commit is
>
> commit 455e987c0c2eb2c9045dc854559474cf41509965
> Merge: 7c17e48 fd6da69
> Author: Linus Torvalds
> Date: Sat Dec 1 13:07:48 2012 -0800
>
> Merge branch 'perf-urgent-for-linus' of
On Friday 08 February 2013 21:15, Michael Kerrisk (man-pages) wrote:
> >> >Damn. But after I wrote this email I realized that llseek() probably can't
> >> > work. Because peek_offset/f_pos/whatever has to be shared with all
> >> > processes
> >> > which have this file opened.
> >
> > Yes. but I
* Yinghai Lu wrote:
> Hi,
>
> Current x86 code does not support iapic hotplug yet.
Please give a better high-level description: outline how an
IO-APIC will be hotplugged physically and what changes the
user will experience.
That needs at least 2 paragraphs, not one cursory sentence. Then
On 11 February 2013 08:26, Vineet Gupta wrote:
>
> The only downside of this patch is that userspace signal stack grows in size,
> since signal frame only cares about scratch regs (pt_regs), but has to
> accommodate
> unused placeholder for callee regs too by virtue of using user_regs_struct.
* Mike Travis wrote:
> This patch checks current hub support to avoid panicing the
> system until all the GRU changes for UV3+ are in place.
>
> Signed-off-by: Dimitri Sivanich
> Signed-off-by: Mike Travis
That's a weird signoff sequence. It should either also include a
From: Dimitri tag
* Oleg Nesterov wrote:
> OK, nobody has comments. Ingo, please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc uprobes/core
>
> Changes:
> - fix the conflict with d24d7dbf which added the (unsafe) check
> into create_trace_uprobe()
>
> - drop "Kill
* Oleg Nesterov [2013-02-04 20:02:50]:
> Currently it is not possible to change the filtering constraints after
> uprobe_register(), so a consumer can not, say, start to trace a task/mm
> which was previously filtered out, or remove the no longer needed bp's.
>
> Introduce uprobe_apply() which
* Oleg Nesterov [2013-02-04 20:02:46]:
> sys_perf_event_open()->perf_init_event(event) is called before
> find_get_context(event), this means that event->ctx == NULL when
> class->reg(TRACE_REG_PERF_REGISTER/OPEN) is called and thus it
> can't know if this event is per-task or system-wide.
>
>
* Oleg Nesterov [2013-02-04 20:02:54]:
> Introduce "struct trace_uprobe_filter" which records the "active"
> perf_event's attached to ftrace_event_call. For the start we simply
> use list_head, we can optimize this later if needed. For example, we
> do not really need to record an event with
* Oleg Nesterov [2013-02-04 20:02:58]:
> Finally implement uprobe_perf_filter() which checks ->nr_systemwide or
> ->perf_events to figure out whether we need to insert the breakpoint.
>
> uprobe_perf_open/close are changed to do uprobe_apply(true/false) when
> the new perf event comes or goes
On Fri, Feb 08, 2013 at 06:38:39PM +0100, Stephen Warren wrote:
> On 02/08/2013 05:44 AM, Peter De Schrijver wrote:
> > Unlike Tegra30, Tegra20 does not have a 7.1 divider for the CPU superclk.
> > Remove the clocks related to the divider.
>
> I assume there's no particular need to take this for
On 02/11/2013 06:46 AM, Mike Turquette wrote:
Quoting Sebastian Hesselbarth (2013-02-09 04:59:32)
This patch adds a common clock driver for Silicon Labs Si5351a/b/c
i2c programmable clock generators. Currently, the driver supports
DT kernels only and VXCO feature of si5351b is not implemented.
* Clark Williams wrote:
> I figured that was coming. :)
;-)
> I'll look at it again and see about pulling the
> autogroup/cgroup stuff into it's own header. After that it's
> probably going to require some serious changes.
>
> Any suggestions?
I'd suggest doing it as finegrained as
* Oleg Nesterov [2013-02-04 20:03:01]:
> Change uprobe_trace_func() and uprobe_perf_func() to return "int". Change
> Change uprobe_dispatcher() to return "trace_ret | perf_ret" although this
> is not really needed, currently TP_FLAG_TRACE/TP_FLAG_PROFILE are mutually
> exclusive.
>
> The only
* Oleg Nesterov [2013-02-04 20:03:05]:
> uprobe_perf_open/close call the costly uprobe_apply() every time,
> we can avoid it if:
>
> - "nr_systemwide != 0" is not changed.
>
> - There is another process/thread with the same ->mm.
>
> - copy_proccess() does inherit_event().
* Frederic Weisbecker wrote:
> > I'm worried about the proliferation of not easily separable
> > config options. We already have way too many timer and
> > scheduler options to begin with.
>
> Like Steve said, this is for overhead reasons. The syscall
> uses the slow path so that's ok. But
On Fri, Feb 08, 2013 at 03:03:02PM +0100, Felipe Balbi wrote:
> * PGP Signed by an unknown key
>
> Hi,
>
> On Fri, Feb 08, 2013 at 03:36:40PM +0200, Peter De Schrijver wrote:
> > tegra_car: clock {
> > - compatible = "nvidia,tegra114-car, nvidia,tegra30-car";
> > +
* Gleb Natapov wrote:
> On Tue, Feb 05, 2013 at 07:57:22PM -0700, Shuah Khan wrote:
> > Fix the following compile warning in kvm_register_steal_time():
> > CC arch/x86/kernel/kvm.o
> > arch/x86/kernel/kvm.c: In function ?kvm_register_steal_time?:
> > arch/x86/kernel/kvm.c:302:3: warning:
On Mon, Feb 11, 2013 at 11:04:39AM +0100, Ingo Molnar wrote:
>
> * Gleb Natapov wrote:
>
> > On Tue, Feb 05, 2013 at 07:57:22PM -0700, Shuah Khan wrote:
> > > Fix the following compile warning in kvm_register_steal_time():
> > > CC arch/x86/kernel/kvm.o
> > > arch/x86/kernel/kvm.c: In
* Ingo Molnar wrote:
>
> * Gleb Natapov wrote:
>
> > On Tue, Feb 05, 2013 at 07:57:22PM -0700, Shuah Khan wrote:
> > > Fix the following compile warning in kvm_register_steal_time():
> > > CC arch/x86/kernel/kvm.o
> > > arch/x86/kernel/kvm.c: In function ?kvm_register_steal_time?:
> >
On Fri, Feb 08, 2013 at 03:37:29PM +0100, Benjamin Tissoires wrote:
> so, here is the hid drivers cleanup. The aim is to remove as much as possible
> direct calls to usbhid for hid drivers. Thus, other transport layers can use
> the existing hid drivers (like I2C or uhid).
We also found out that
On Mon, Feb 11, 2013 at 12:31 AM, Rafael J. Wysocki wrote:
> On Sunday, February 10, 2013 07:55:05 PM Pavel Machek wrote:
>> Well, from freezer you need:
>>
>> 1) user process frozen.
>>
>> 2) essential locks _not_ held so that block devices are still functional.
>>
>> > > > mmap... what is
On Monday 11 February 2013 03:06 PM, Jonas Bonn wrote:
> On 11 February 2013 08:26, Vineet Gupta wrote:
>
>> The only downside of this patch is that userspace signal stack grows in size,
>> since signal frame only cares about scratch regs (pt_regs), but has to
>> accommodate
>> unused
Hi Anton,
> diff --git a/mm/vmpressure.c b/mm/vmpressure.c
> new file mode 100644
> index 000..7922503
> +struct vmpressure_event {
> + struct eventfd_ctx *efd;
> + enum vmpressure_levels level;
> + struct list_head node;
> +};
> +
> +static bool vmpressure_event(struct
On 02/11/2013 07:40 AM, Yinghai Lu wrote:
> Can you try attached debug patch?
FWIW this fixes it for me. No more 'derived' or 'nobody' in dmesg.
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Sun 10-02-13 21:42:32, Michel Lespinasse wrote:
> Hi Jan,
>
> On Thu, Jan 31, 2013 at 1:49 PM, Jan Kara wrote:
> > Implement range locking using interval tree.
>
> Yay! I like to see interval trees being put to good use.
Yeah, you saved me some coding of interval tree implementation :) The
On 11/02/13 10:13, Vineet Gupta wrote:
> On Monday 11 February 2013 03:06 PM, Jonas Bonn wrote:
>> On 11 February 2013 08:26, Vineet Gupta wrote:
>>
>>> The only downside of this patch is that userspace signal stack grows in
>>> size,
>>> since signal frame only cares about scratch regs
We now have two transport mediums: USB and I2C, where sensor hubs can
exists. So instead of constraining the driver to only these two we let it
to match any HID bus as long as the group is HID_GROUP_SENSOR_HUB.
Signed-off-by: Mika Westerberg
---
drivers/hid/hid-sensor-hub.c |3 ++-
1 file
Since the advent of HID over I2C protocol, it is possible to have sensor
hubs behind I2C bus as well. We can autodetect this in a same way than USB
sensor hubs.
Signed-off-by: Mika Westerberg
---
drivers/hid/hid-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This table is not used anywhere in the driver so kill it.
Signed-off-by: Mika Westerberg
---
drivers/hid/hid-sensor-hub.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index c06e933..2643bce9 100644
---
On 11 February 2013 11:13, Vineet Gupta wrote:
> On Monday 11 February 2013 03:06 PM, Jonas Bonn wrote:
>> On 11 February 2013 08:26, Vineet Gupta wrote:
>>
>>> The only downside of this patch is that userspace signal stack grows in
>>> size,
>>> since signal frame only cares about scratch regs
2013/2/8 Arnd Bergmann :
> On Thursday 07 February 2013, Michal Simek wrote:
>> Subject: "asm-generic: io: Fix ioread16/32be and iowrite16/32be"
>
> Ok, thanks. If you don't mind, I think this can just go with the other patches
> for xsysace that come out of this discussion.
I want to move
In preparation to support the regmap debugfs ranges functionality
factor this code out to a separate function. We'll need to ensure
that the value has been correctly calculated from two separate places
in the code.
Signed-off-by: Dimitris Papastamos
---
drivers/base/regmap/regmap-debugfs.c |
This file lists the register ranges in the register map. The condition
to split the range is based on the actual register attributes. A range
is a contiguous block of registers with the same register attributes.
Signed-off-by: Dimitris Papastamos
---
Hi,
This is applied on top of commit
On Sat, Feb 09, 2013 at 05:15:43AM +0800, Shawn Joo wrote:
> Resending sine Liam's email is invalid, adding linux-kernel.
>
> Hi Liam and Mark,
> Here is commit message for my attached change.
> Please review it to make easy world, thanks!
Please follow the process for submitting patches
Hi!
> > > > > > The whole memory shrinking we do for hibernation is now done by
> > > > > > allocating
> > > > > > memory, so the freezer is not necessary for *that* and there's
> > > > > > *zero*
> > > > > > difference between suspend and hibernation with respect to why the
> > > > > >
On 11 February 2013 11:28, James Hogan wrote:
> On 11/02/13 10:13, Vineet Gupta wrote:
>> On Monday 11 February 2013 03:06 PM, Jonas Bonn wrote:
>>> On 11 February 2013 08:26, Vineet Gupta wrote:
>>>
The only downside of this patch is that userspace signal stack grows in
size,
On 11/02/13 10:53, Jonas Bonn wrote:
> On 11 February 2013 11:28, James Hogan wrote:
>> On 11/02/13 10:13, Vineet Gupta wrote:
>>> On Monday 11 February 2013 03:06 PM, Jonas Bonn wrote:
On 11 February 2013 08:26, Vineet Gupta wrote:
> The only downside of this patch is that
On Mon, Feb 11, 2013 at 10:29:50AM +0100, Denys Vlasenko wrote:
> On Friday 08 February 2013 21:15, Michael Kerrisk (man-pages) wrote:
> > >> >Damn. But after I wrote this email I realized that llseek() probably
> > >> >can't
> > >> > work. Because peek_offset/f_pos/whatever has to be shared with
Hi Jonas,
On 11/02/13 10:53, Jonas Bonn wrote:
> And now that I think about it some more, I think this is done
> incorrectly in the openrisc arch, too, as the fast-path for
> rt_sigreturn probably only restores the call-clobbered regs.
> sigreturn probably needs to be special-cased to _always_
On Sun, Feb 10, 2013 at 08:36:23AM -0800, Greg KH wrote:
> On Sun, Feb 10, 2013 at 04:32:18AM +0100, Samuel Ortiz wrote:
> > Hi Greg,
> >
> > On Fri, Feb 08, 2013 at 03:55:24PM -0800, Greg KH wrote:
> > > On Fri, Feb 08, 2013 at 02:28:15PM +0200, Tomas Winkler wrote:
> > > > From: Samuel Ortiz
>
On Mon, Feb 11, 2013 at 2:27 AM, Jan Kara wrote:
> On Sun 10-02-13 21:42:32, Michel Lespinasse wrote:
>> On Thu, Jan 31, 2013 at 1:49 PM, Jan Kara wrote:
>> > +void range_lock_init(struct range_lock *lock, unsigned long start,
>> > +unsigned long end);
>> > +void
From: Borislav Petkov
Hi,
so this is a rough first version to collect some initial comments. It is
lightly tested in kvm.
Thanks.
Borislav Petkov (4):
x86, cpu: Expand cpufeature facility to include cpu bugs
x86, cpu: Convert F00F bug detection
x86, cpu: Convert FDIV bug detection
From: Borislav Petkov
... to using the new facility and drop the cpuinfo_x86 member.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 2 ++
arch/x86/include/asm/processor.h | 1 -
arch/x86/kernel/cpu/intel.c | 4 ++--
arch/x86/kernel/cpu/proc.c| 2 +-
From: Borislav Petkov
... to the new facility.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/include/asm/processor.h | 1 -
arch/x86/kernel/cpu/bugs.c| 5 +++--
arch/x86/kernel/cpu/proc.c| 2 +-
4 files changed, 5 insertions(+), 4
On Mon, Feb 11, 2013 at 11:13 AM, Mika Westerberg
wrote:
> On Fri, Feb 08, 2013 at 03:37:29PM +0100, Benjamin Tissoires wrote:
>> so, here is the hid drivers cleanup. The aim is to remove as much as possible
>> direct calls to usbhid for hid drivers. Thus, other transport layers can use
>> the
From: Borislav Petkov
We add another 32-bit vector at the end of the ->x86_capability
bitvector which collects bugs present in CPUs. After all, a CPU bug is a
kind of a capability, albeit a strange one.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 34
From: Borislav Petkov
... to the new facility. Drop the padding too since it becomes
unnecessary now.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/include/asm/processor.h | 2 --
arch/x86/kernel/cpu/cyrix.c | 5 +++--
arch/x86/kernel/cpu/proc.c
On Mon, Feb 11, 2013 at 11:31 AM, Mika Westerberg
wrote:
> Since the advent of HID over I2C protocol, it is possible to have sensor
> hubs behind I2C bus as well. We can autodetect this in a same way than USB
> sensor hubs.
>
> Signed-off-by: Mika Westerberg
Reviewed-by: Benjamin Tissoires
On Mon, Feb 11, 2013 at 11:31 AM, Mika Westerberg
wrote:
> This table is not used anywhere in the driver so kill it.
>
> Signed-off-by: Mika Westerberg
> ---
Yep, it's rather strange that the compiler didn't complained...
Anyway, Reviewed-by: Benjamin Tissoires
Cheers,
Benjamin
--
To
On Mon, Feb 11, 2013 at 11:31 AM, Mika Westerberg
wrote:
> We now have two transport mediums: USB and I2C, where sensor hubs can
> exists. So instead of constraining the driver to only these two we let it
> to match any HID bus as long as the group is HID_GROUP_SENSOR_HUB.
>
> Signed-off-by: Mika
On Sun 10-02-13 17:46:19, azurIt wrote:
> >stuck in the ptrace code.
>
>
> But this happens _after_ the cgroup was freezed and i tried to strace
> one of it's processes (to see what's happening):
>
> Feb 8 01:29:46 server01 kernel: [ 1187.540672] grsec: From 178.40.250.111:
> process
On Monday 11 February 2013 04:23 PM, Jonas Bonn wrote:
> On 11 February 2013 11:28, James Hogan wrote:
>> On 11/02/13 10:13, Vineet Gupta wrote:
>>> On Monday 11 February 2013 03:06 PM, Jonas Bonn wrote:
On 11 February 2013 08:26, Vineet Gupta wrote:
> The only downside of this
On Mon, Feb 11, 2013 at 12:19:13PM +0100, Benjamin Tissoires wrote:
> On Mon, Feb 11, 2013 at 11:13 AM, Mika Westerberg
> wrote:
> > On Fri, Feb 08, 2013 at 03:37:29PM +0100, Benjamin Tissoires wrote:
> >> so, here is the hid drivers cleanup. The aim is to remove as much as
> >> possible
> >>
On Fri, Feb 08, 2013 at 12:47:14PM +, Dimitris Papastamos wrote:
> We are keeping track of the maximum register as well, this will make
> things easier for us in sharing this code with the code implementing
> the register ranges functionality. It also simplifies a bit the
> calculations when
On 2013-02-11 00:58, Grant Likely wrote:
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 2390ddb..e1120a2 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1025,12 +1025,13 @@ EXPORT_SYMBOL(of_parse_phandle);
* To get a device_node of the `node2' node you may call this:
*
On Fri, Feb 08, 2013 at 12:47:20PM +, Dimitris Papastamos wrote:
> Optimize this so that we can better guess where to start scanning
> from. We know the length of the register field format, therefore
> given the file pointer position align to the nearest register
> field and scan from there
On Mon, Feb 11, 2013 at 10:50:59AM +, Dimitris Papastamos wrote:
> In preparation to support the regmap debugfs ranges functionality
> factor this code out to a separate function. We'll need to ensure
> that the value has been correctly calculated from two separate places
> in the code.
Hi Vineet,
On 24/01/13 10:50, Vineet Gupta wrote:
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> new file mode 100644
> index 000..b0b09ae
> --- /dev/null
> +++ b/arch/arc/Kconfig
> @@ -0,0 +1,328 @@
> +#
> +# Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com)
>
On Mon, Feb 11, 2013 at 4:28 AM, Alex Courbot wrote:
> On 02/09/2013 07:34 PM, Grant Likely wrote:
>>
>> The debugfs files really need to hold the gpiolib spinlock before
>> accessing the list. Otherwise chip addition/removal will cause an oops.
>>
>> Cc: Alexandre Courbot
>> Cc: Linus Walleij
Hello,
On Thu, Feb 07, 2013 at 04:02:41PM +, Roger Quadros wrote:
> The PHY clock, clock rate, VCC regulator and RESET regulator
> can now be provided via device tree.
>
> Signed-off-by: Roger Quadros
> Acked-by: Felipe Balbi
> ---
> .../devicetree/bindings/usb/usb-nop-xceiv.txt |
On Monday 11 February 2013 04:59 PM, James Hogan wrote:
> Hi Vineet,
>
> On 24/01/13 10:50, Vineet Gupta wrote:
>> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
>> new file mode 100644
>> index 000..b0b09ae
>> --- /dev/null
>> +++ b/arch/arc/Kconfig
>> @@ -0,0 +1,328 @@
>> +#
>> +#
On Thu, Feb 07, 2013 at 04:02:47PM +, Roger Quadros wrote:
> Allows the OHCI controller found in OMAP3 and later chips to
> be specified via device tree.
>
> Signed-off-by: Roger Quadros
> Acked-by: Alan Stern
> ---
> .../devicetree/bindings/usb/omap3-ohci.txt | 17
On Sunday 10 February 2013, Samuel Ortiz wrote:
> > >
> > > /**
> > > + * mei_bus_client
> >
> > I don't really understand this structure, please explain it better.
> This is a structure that links the MEI bus client pointer passed to the driver
> with the actual ME client. It also allows the
On Thu, Feb 07, 2013 at 04:02:48PM +, Roger Quadros wrote:
> Allows the OMAP EHCI controller to be specified via device tree.
>
> Signed-off-by: Roger Quadros
> Acked-by: Alan Stern
> ---
> .../devicetree/bindings/usb/omap-ehci.txt | 34 ++
>
From: Lars Poeschel
This converts the mcp23s08 driver to be able to be used with device
tree.
Explicitly allow -1 as a legal value for the
mcp23s08_platform_data->base. This is the special value lets the
kernel choose a valid global gpio base number.
There is a "mcp,chips" device tree property,
On Thursday 07 February 2013, Samuel Ortiz wrote:
> On Thu, Feb 07, 2013 at 10:34:44PM +, Arnd Bergmann wrote:
> > On Thursday 07 February 2013, Tomas Winkler wrote:
> > > +
> > > +struct mei_bus_ops {
> > > + int (*send)(struct mei_bus_client *client, u8 *buf, size_t
> > > length);
> >
The series introduces a VFIO support on POWER.
The QEMU support is required, the real mode acceleration patches are coming
later.
Alexey Kardashevskiy (2):
vfio powerpc: enabled on powernv platform
vfio powerpc: implemented IOMMU driver for VFIO
arch/powerpc/include/asm/iommu.h
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also implements an API for mapping/unmapping pages for
guest PCI drivers and
VFIO implements platform independent stuff such as
a PCI driver, BAR access (via read/write on a file descriptor
or direct mapping when possible) and IRQ signaling.
The platform dependent part includes IOMMU initialization
and handling. This patch implements an IOMMU driver for VFIO
which does
Hi Stephen,
On 12/11/12 21:26, Stephen Rothwell wrote:
> Make if easier for more architectures to select it and thus disable
> drivers that use virt_to_bus().
>
> Signed-off-by: Stephen Rothwell
I was just wondering what the status of this patch is? It was in -next
for a while but seems to
Hi Srivatsa,
I can try to run some of our stress tests on your patches. Have you
got a git tree that i can pull ?
Regards,
Vincent
On 8 February 2013 19:09, Srivatsa S. Bhat
wrote:
> On 02/08/2013 10:14 PM, Srivatsa S. Bhat wrote:
>> On 02/08/2013 09:11 PM, Russell King - ARM Linux wrote:
>>>
On Thu, Feb 07, 2013 at 04:02:49PM +, Roger Quadros wrote:
> Allows the OMAP HS USB host controller to be specified
> via device tree.
>
> CC: Samuel Ortiz
> Signed-off-by: Roger Quadros
> ---
> .../devicetree/bindings/mfd/omap-usb-host.txt | 80 ++
>
On Monday, February 11, 2013 11:11:40 AM Miklos Szeredi wrote:
> On Mon, Feb 11, 2013 at 12:31 AM, Rafael J. Wysocki wrote:
> > On Sunday, February 10, 2013 07:55:05 PM Pavel Machek wrote:
>
> >> Well, from freezer you need:
> >>
> >> 1) user process frozen.
> >>
> >> 2) essential locks _not_
On Monday, February 11, 2013 03:42:55 PM Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/acpi/Kconfig between commit cb2b212bc7ff ("ACPI / scan: Make
> container driver use struct acpi_scan_handler") from the pm tree and
> commit
On 11/02/2013 09:13, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/net/ethernet/mellanox/mlx4/en_rx.c: In function
> 'mlx4_en_process_rx_cq':
>
On 11 February 2013 12:22, Vineet Gupta wrote:
> On Monday 11 February 2013 04:23 PM, Jonas Bonn wrote:
>> On 11 February 2013 11:28, James Hogan wrote:
>>> On 11/02/13 10:13, Vineet Gupta wrote:
On Monday 11 February 2013 03:06 PM, Jonas Bonn wrote:
> On 11 February 2013 08:26, Vineet
From: Alexey Kardashevskiy
The first 2 patches in this set add a multi-tce support feature
(adding/deleting several TCE records at once) in real and virtual mode.
The last 2 patches enable real mode acceleration for VFIO and
extend the multi-tce feature to be available for VFIO devices.
The
From: Alexey Kardashevskiy
The lookup_linux_pte() function returns a linux PTE which
is required to convert KVM guest physical address into host real
address in real mode.
This convertion will be used by upcoming support of H_PUT_TCE_INDIRECT
as TCE list address comes from the guest directly so
601 - 700 of 1182 matches
Mail list logo