Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
On Wed, Feb 05, 2014 at 01:23:45PM -0800, David Rientjes wrote:
> On Wed, 5 Feb 2014, Andrew Vagin wrote:
...
>
> You've clipped the most interesting part of the trace, we don't know what
> was calling mempool_alloc() and must have used a ton of stack.
Sorry. You can find the full trace bellow
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
The following method of CPU hotplug callback registration is not safe
due to the possibility of an ABBA deadlock involving the cpu_add_remove_lock
and the cpu_hotplug.lock.
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&f
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifie
Hi,
Many subsystems and drivers have the need to register CPU hotplug callbacks
from their init routines and also perform initialization for the CPUs that are
already online. But unfortunately there is no race-free way to achieve this
today.
For example, consider this piece of code:
get_
On 02/05/2014 01:41 PM, Thomas Gleixner wrote:
> On Wed, 5 Feb 2014, Alexey Perevalov wrote:
>> On 02/04/2014 08:10 PM, Thomas Gleixner wrote:
>>> On Mon, 27 Jan 2014, Alexey Perevalov wrote:
On 01/21/2014 11:12 PM, John Stultz wrote:
> Thomas: Any thought here? Should we be trying to unif
On Wed, Feb 5, 2014 at 12:20 AM, wrote:
> From: Stefani Seibold
>
> This patch add the VDSO time support for the IA32 Emulation Layer.
>
> Due the nature of the kernel headers and the LP64 compiler where the
> size of a long and a pointer differs against a 32 bit compiler, there
> is some type h
On Tue, 4 Feb 2014 16:02:30 -0800 Laura Abbott wrote:
> Appart from setting the limit of memblock, it's also useful to be able
> to get the limit to avoid recalculating it every time. Add the function
> to do so.
Looks OK to me. Your "[PATCHv2 2/2] arm: Get rid of meminfo" did not
make it into
On Tue, 4 Feb 2014 12:43:49 -0800 Sebastian Capella
wrote:
> kstrdup_trimnl creates a duplicate of the passed in
> null-terminated string. If a trailing newline is found, it
> is removed before duplicating. This is useful for strings
> coming from sysfs that often include trailing whitespace
On Fri, Jan 31, 2014 at 03:23:18PM +0100, Borislav Petkov wrote:
> And now my question:
>
> How can I reliably find out which region contains that
> uv_systab.function call?
>
> I need it so that I can map it in the EFI page table and you can
> continue to call that function and you can get back
On 01/29/2014 06:51 AM, Peter Zijlstra wrote:
On Tue, Jan 28, 2014 at 02:51:35PM -0800, Jason Low wrote:
But urgh, nasty problem. Lemme ponder this a bit.
OK, please have a very careful look at the below. It survived a boot
with udev -- which usually stresses mutex contention enough to explode
> > +/* Tegra 20 timers */
> > +#define TEGRA20_TIMER1_BASE0x0
> > +#define TEGRA20_TIMER2_BASE0x8
> > +#define TEGRA20_TIMER3_BASE0x50
> > +#define TEGRA20_TIMER4_BASE0x58
> > +
> > +/* Tegra 30 timers */
> > +#define TEGRA30_TIMER1_BASETEGRA20_TIMER1_BASE
>
On Wed, 5 Feb 2014, Alexey Perevalov wrote:
> On 02/04/2014 08:10 PM, Thomas Gleixner wrote:
> > On Mon, 27 Jan 2014, Alexey Perevalov wrote:
> > > On 01/21/2014 11:12 PM, John Stultz wrote:
> > > > Thomas: Any thought here? Should we be trying to unify the timerfd flags
> > > > and the posix timer
On Wed, 2014-02-05 at 22:49 +0100, Rafael J. Wysocki wrote:
> On Wednesday, February 05, 2014 08:52:49 AM Toshi Kani wrote:
> > On Wed, 2014-02-05 at 11:05 +, Rafael J. Wysocki wrote:
> > > On Tuesday, February 04, 2014 05:48:28 PM Toshi Kani wrote:
> > > > When an eject request is sent to an e
> On 02/05/2014 01:06 PM, Andrew Chew wrote:
> >> On 02/03/2014 05:17 PM, Andrew Chew wrote:
> >>> There are some differences between tegra20's timer registers and
> >>> tegra30's (and later). For example, tegra30 has more timers. In
> >>> addition, watchdogs are not present in tegra20.
> >>>
> >
On Monday, January 20, 2014 04:44:34 PM Liu, Chuansheng wrote:
> Hello,
>
> This patch series are for enabling the asynchronous threads for the phases
> resume_noirq, resume_early, suspend_noirq and suspend_late.
>
> Just like commit 5af84b82701a and 97df8c12995, with async threads it will
> redu
On Wed, 5 Feb 2014, Steven Rostedt wrote:
> > Looks like you've got something prepared already! Mind sending it to
> > Pekka as a patch based on linux-next?
>
> Sure, and there's another lockdep splat that I'm working on too.
>
If it's coming from slub, make sure you've applied
http://marc.i
Those callbacks are not mandatory, so it's better to add inliners
to use them safely.
Reviewed-by: David Herrmann
Signed-off-by: Benjamin Tissoires
---
include/linux/hid.h | 45 +
1 file changed, 45 insertions(+)
diff --git a/include/linux/hid.h b/in
hidp uses its own ->hidinput_input_event() instead of the generic binding
in hid-input.
Moving the handling of LEDs towards hidp_hidinput_event() allows two things:
- remove hidinput_input_event definitively from struct hid_device
- hidraw user space programs can also set the LEDs
Reviewed-by: Dav
All the different transport drivers use now the generic event handling
in hid-input. We can remove the handler definitively now.
Reviewed-by: David Herrmann
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-input.c | 4 +---
include/linux/hid.h | 4
2 files changed, 1 insertion(+),
- Move hidp_output_report() above
- Removed duplicated code in hidp_output_raw_report()
Reviewed-by: David Herrmann
Signed-off-by: Benjamin Tissoires
---
net/bluetooth/hidp/core.c | 68 ---
1 file changed, 11 insertions(+), 57 deletions(-)
diff --git
Well, no use to keep twice the same code.
Reviewed-by: David Herrmann
Signed-off-by: Benjamin Tissoires
---
drivers/hid/usbhid/hid-core.c | 64 ---
1 file changed, 11 insertions(+), 53 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid
dev->hid_get_raw_report(X) and hid_hw_raw_request(X, HID_REQ_GET_REPORT)
are strictly equivalent. Switch the hid subsystem to the hid_hw notation
and remove the field .hid_get_raw_report in struct hid_device.
Reviewed-by: David Herrmann
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-inpu
On Wednesday, February 05, 2014 08:52:49 AM Toshi Kani wrote:
> On Wed, 2014-02-05 at 11:05 +, Rafael J. Wysocki wrote:
> > On Tuesday, February 04, 2014 05:48:28 PM Toshi Kani wrote:
> > > When an eject request is sent to an ejected ACPI device, the following
> > > panic occurs:
> > >
> > >
Add David Herrmann's documentation for the new low-level HID transport driver
functions.
Signed-off-by: Frank Praznik
Signed-off-by: David Herrmann
Signed-off-by: Benjamin Tissoires
---
Documentation/hid/hid-transport.txt | 316
1 file changed, 316 insertio
Add a helper to access hdev->hid_output_raw_report().
To convert the drivers, use the following snippets:
for i in drivers/hid/*.c
do
sed -i.bak "s/[^ \t]*->hid_output_raw_report(/hid_output_raw_report(/g" $i
done
Then manually fix for checkpatch.pl
Reviewed-by: David Herrmann
Signed-off-by:
hid-logitech-dj uses its own ->hidinput_input_event() instead of
the generic binding in hid-input.
Moving the handling of LEDs towards logi_dj_output_hidraw_report()
allows two things:
- remove hidinput_input_event in struct hid_device
- hidraw user space programs can also set the LEDs
Signed-off-
Hi guys,
well, here comes the promised v2 of the ll_transport cleanup.
As I said, I removed patches which need some more work, and kept only the
trivial ones. I also added David's documentation, which gives us a net
difference of +210 lines of code :(
Let's say that we still have a net worth of -
On Wed, 5 Feb 2014 13:25:28 -0800 (PST)
David Rientjes wrote:
> Looks like you've got something prepared already! Mind sending it to
> Pekka as a patch based on linux-next?
Sure, and there's another lockdep splat that I'm working on too.
But first, I need to shovel my driveway yet again (We
On Wed, 5 Feb 2014, Steven Rostedt wrote:
> Then add the comment that clears this up. But lets not add spinlocks
> just to quiet something if they truly are not needed.
>
> We use "__" variants all the time. That's really not extra code.
>
> Heck, if you want, call it remove_freed_partial() that
Hi,
If you run perf top on 3.14 but you force --stdio mode, perf top
goes crazy and constantly refreshes the output.
It does that with many older versions of the perf as well on 3.14.
It runs fine with newt mode.
Works fine with my 3.11 kernel. So something must be broken
with 3.14.
Can you rep
From: Kees Cook
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On Wed, 5 Feb 2014, Andrew Vagin wrote:
> [532284.563576] BUG: unable to handle kernel paging request at
> 35c83420
> [532284.564086] IP: [] cpuacct_charge+0x97/0x1e0
> [532284.564086] PGD 116369067 PUD 116368067 PMD 0
> [532284.564086] Thread overran stack, or stack corrupted
> [532284.5
On Wed, 5 Feb 2014 13:07:05 -0800 (PST)
David Rientjes wrote:
> The functions that manipulate the partial lists was modified by
> c65c1877bd68 ("slub: use lockdep_assert_held") which replaced commentary
> with runtime checking on debug kernels with lockdep enabled. I'm not sure
> adding more
From: Eric Paris
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
---
From: Romain Francoise
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Alex Williamson
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Nick Bowler
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
--
From: Herbert Xu
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
---
From: Alex Williamson
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Kees Cook
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Weiping Pan
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
--
From: Kees Cook
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Wu Fengguang
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Paolo Bonzini
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Kees Cook
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
---
T
From: Paolo Bonzini
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Neil Horman
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
--
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Kees Cook
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Eryu Guan
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Hannes Frederic Sowa
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Tommi Rantala
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Daniel Borkmann
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On 02/03/2014 05:17 PM, Andrew Chew wrote:
> Added timers that are present in tegra30 and later, that are NOT in tegra20.
>
> Also, some of these timer bases are needed in the tegra watchdog driver, so
> separate them out into a header file that both the clocksource driver and
> the watchdog drive
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
From: Paul Moore
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
---
On Wed, 5 Feb 2014, Steven Rostedt wrote:
> > There's an extremely small overhead of taking this lock, the cache has
> > been destroyed and is the process of being torn down, there will be
> > absolutely no contention on n->list_lock.
>
> But why add it if it isn't necessary? You're even disabl
From: Daniel Borkmann
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
From: Hiroaki SHIMODA
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
On Wed, Feb 05, 2014 at 01:41:48PM -0700, Shuah Khan wrote:
> On 02/04/2014 11:39 PM, Guenter Roeck wrote:
> >On 02/04/2014 01:06 PM, Greg Kroah-Hartman wrote:
> >>This is the start of the stable review cycle for the 3.12.10 release.
> >>There are 133 patches in this series, all will be posted as a
From: David Ward
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
---
From: Jesper Dangaard Brouer
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
From: stephen hemminger
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: "David S. Miller"
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
From: Stefan Hasko
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
From: Stephen Hemminger
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
From: Jiri Kosina
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
--
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
On 02/03/2014 05:17 PM, Andrew Chew wrote:
> There are some differences between tegra20's timer registers and tegra30's
> (and later). For example, tegra30 has more timers. In addition, watchdogs
> are not present in tegra20.
>
> Add this compatibility string in order to be able to distinguish
>
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Mathias Krause
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
From: Eric Dumazet
---
This is a commit scheduled for the next v2.6.34 longterm release.
http://git.kernel.org/?p=linux/kernel/git/paulg/longterm-queue-2.6.34.git
If you see a problem with using this for longterm, please comment.
-
201 - 300 of 890 matches
Mail list logo
