[Patch depends on another patch in this series that introduces raw_cpu_ops]
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current
On Thu, Feb 13, 2014 at 10:48:24AM +0100, Sander Eikelenboom wrote:
> Hi Bjorn,
>
> I have given it another email and another week, but without gaining any
> reviewed or acked-by's.
> It seems the only way forward is to shovel it in linux-next earlier, give it
> a good soak and see if
> anyone
From: David Daney
The use of __this_cpu_inc() requires a fundamental integer type, so
change the type of all the counters to unsigned long, which is the
same width they were before, but not wrapped in local_t.
Signed-off-by: David Daney
Signed-off-by: Christoph Lameter
---
Use __this_cpu_read instead.
Cc: Hedi Berriche
Cc: Mike Travis
Cc: Dimitri Sivanich
Signed-off-by: Christoph Lameter
Index: linux/arch/x86/include/asm/uv/uv_hub.h
===
--- linux.orig/arch/x86/include/asm/uv/uv_hub.h 2014-02-03
More were added recently.
Cc: Thomas Gleixner
Cc: x...@kernel.org
Cc: H. Peter Anvin
Cc: Ingo Molnar
Signed-off-by: Christoph Lameter
Index: linux/arch/x86/kernel/cpu/perf_event_intel_rapl.c
===
---
[Patch depends on another patch in this series that introduces raw_cpu_ops]
Use raw_cpu_ptr instead.
Signed-off-by: Christoph Lameter
Index: linux/arch/s390/include/asm/percpu.h
===
--- linux.orig/arch/s390/include/asm/percpu.h
Signed-off-by: Christoph Lameter
Index: linux/arch/s390/kernel/perf_cpum_sf.c
===
--- linux.orig/arch/s390/kernel/perf_cpum_sf.c 2014-01-20 16:18:06.634974387
-0600
+++ linux/arch/s390/kernel/perf_cpum_sf.c 2014-02-03
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving
* Thomas Gleixner | 2014-02-13 23:57:45 [+0100]:
>If we really end up with unwinding then the few cycles to follow the
>stack are not that important anymore. We really want that output.
Here you go.
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 2af232d..bbafc67 100644
The AUDIT_SECCOMP record looks something like this:
type=SECCOMP msg=audit(1373478171.953:32775): auid=4325 uid=4325 gid=4325 ses=1
subj=unconfined_u:unconfined_r:unconfined_t:s0 pid=12381 comm="test" sig=31
syscall=231 compat=0 ip=0x39ea8bca89 code=0x0
In order to determine what syscall 231
Signed-off-by: Christoph Lameter
Index: linux/arch/powerpc/kernel/irq.c
===
--- linux.orig/arch/powerpc/kernel/irq.c2014-02-03 14:16:29.028411561
-0600
+++ linux/arch/powerpc/kernel/irq.c 2014-02-03 14:27:59.283978219
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving
On 02/14/2014 12:42 PM, Stephen Warren wrote:
> On 02/12/2014 11:50 PM, Viresh Kumar wrote:
>> This patchset creates/calls cpufreq suspend/resume callbacks from
>> dpm_{suspend|resume}()
>> for handling suspend/resume of cpufreq governors and core.
BTW, I also happened to test these on a
[Patch depends on another patch in this series that introduces raw_cpu_ops]
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving
No user is left in the kernel source tree. Therefore we can
drop the definitions.
[Patch should not be merged until all the replacement patches have been
merged. Probably this means hold until the 3.16 merge window]
Signed-off-by: Christoph Lameter
Index: linux/include/asm-generic/percpu.h
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current processor
based on an offset.
Other use cases are for storing and retrieving
The __this_cpu_ptr macro is no longer in use so drop it.
Signed-off-by: Christoph Lameter
Index: linux/include/asm-generic/percpu.h
===
--- linux.orig/include/asm-generic/percpu.h 2013-12-18 13:41:37.359646058
-0600
+++
Replace the single use of __get_cpu_var in avr32 with
__this_cpu_write.
Cc: Haavard Skinnemoen
Acked-by: Hans-Christian Egtvedt
Signed-off-by: Christoph Lameter
Index: linux/arch/avr32/kernel/kprobes.c
===
---
[Patch depends on another patch in this series that introduces raw_cpu_ops]
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is address calculation via the form &__get_cpu_var(x). This calculates
the address for the instance of the percpu variable of the current
Convert to the use of this_cpu_ptr().
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-par...@vger.kernel.org
Signed-off-by: Christoph Lameter
Index: linux/arch/parisc/lib/memcpy.c
===
--- linux.orig/arch/parisc/lib/memcpy.c
Replace __get_cpu_var used for address calculation with this_cpu_ptr.
Acked-by: James Hogan
Signed-off-by: Christoph Lameter
Index: linux/drivers/clocksource/metag_generic.c
===
--- linux.orig/drivers/clocksource/metag_generic.c
[Patch depends on another patch in this series that introduces raw_cpu_ops]
__this_cpu_ptr is being phased out.
Signed-off-by: Christoph Lameter
Index: linux/drivers/md/dm-stats.c
===
--- linux.orig/drivers/md/dm-stats.c
Replace with this_cpu_ptr.
Acked-by: Chris Metcalf
Signed-off-by: Christoph Lameter
Index: linux/drivers/net/ethernet/tile/tilegx.c
===
--- linux.orig/drivers/net/ethernet/tile/tilegx.c 2014-02-03
13:55:50.504361347 -0600
Seems to have been introduced in 3.14-rc1.
Signed-off-by: Christoph Lameter
Index: linux/drivers/net/ethernet/tile/tilegx.c
===
--- linux.orig/drivers/net/ethernet/tile/tilegx.c 2014-02-03
14:00:01.159103055 -0600
+++
One case of using __get_cpu_var in the get_cpu_var macro
for address calculation.
Signed-off-by: Christoph Lameter
Index: linux/include/linux/percpu.h
===
--- linux.orig/include/linux/percpu.h 2014-01-30 14:40:02.667473594 -0600
Can we please get this merged? The first patch alone would at least define
the functions required to enable the merging of the rest in any order and
through any tree.
There is a git tree that can be pulled at
https://git.kernel.org/cgit/linux/kernel/git/christoph/percpu.git/
It has the
Cyrill Gorcunov writes:
> On Fri, Feb 14, 2014 at 11:47:13PM +0400, Pavel Emelyanov wrote:
>> >> Maybe we could improve this api and provide argument as a pointer
>> >> to a structure, which would have all the fields we're going to
>> >> modify, which in turn would allow us to verify that all
On Fri, Feb 14, 2014 at 9:27 AM, Daniel Borkmann wrote:
> On 02/14/2014 05:47 AM, Alexei Starovoitov wrote:
> ...
>>>
>>> Do you see a possibility to integrate your work step by step? That is,
>>
>>
>> Sure. let's see how we can do it.
>>
>>> to first integrate the interpreter part only; meaning,
This version looks good to me from a quick read.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Fri, Feb 14, 2014 at 12:01 PM, Andy Lutomirski wrote:
> On Thu, Feb 13, 2014 at 6:50 AM, Peter Zijlstra wrote:
>> On Wed, Feb 12, 2014 at 05:40:12PM -0800, Andy Lutomirski wrote:
>>> This is a strawman proposal to simplify the idle implementation, eliminate
>>> a race
>>>
>>> Benefits over
On Fri, Feb 14, 2014 at 08:48:25PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 February 2014, Courtney Cavin wrote:
> > On Tue, Feb 11, 2014 at 09:35:01AM +0100, Arnd Bergmann wrote:
> > > On Monday 10 February 2014 16:23:48 Courtney Cavin wrote:
>
> > Then again, I think that the context
Hi Andrew,
On Fri, Feb 14, 2014 at 12:03:05PM -0800, Andrew Chew wrote:
> Add a driver for the hardware watchdogs in NVIDIA Tegra SoCs (Tegra30 and
> later). This driver will configure one watchdog timer that will reset the
> system in the case of a watchdog timeout.
>
> This driver binds to
Pavel Emelyanov writes:
> On 02/14/2014 11:16 PM, Eric W. Biederman wrote:
>> Cyrill Gorcunov writes:
>>
>>> On Fri, Feb 14, 2014 at 09:43:14PM +0400, Andrew Vagin wrote:
> My brain hurts just looking at this patch and how you are justifying it.
>
> For the resources you are
At Sat, 15 Feb 2014 03:01:24 +0800,
Jeff Chua wrote:
>
> On Fri, Feb 14, 2014 at 9:57 PM, Takashi Iwai wrote:
> > The other possible change in hda_intel.c is the enablement of runtime
> > PM for Panther Point. But it's been working for other chips, so
> > wondering why it hits anything. In
On Fri, Feb 14, 2014 at 11:47:13PM +0400, Pavel Emelyanov wrote:
> >> Maybe we could improve this api and provide argument as a pointer
> >> to a structure, which would have all the fields we're going to
> >> modify, which in turn would allow us to verify that all new values
> >> are sane and fit
On 02/14/2014 11:59 AM, Thomas Gleixner wrote:
> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
>> On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
>>> I'm fine with ACPI tables if we can provide simple means for embedded
>>> users to load one via grub or just attach it to the kernel image.
>>
>> That
Add a driver for the hardware watchdogs in NVIDIA Tegra SoCs (Tegra30 and
later). This driver will configure one watchdog timer that will reset the
system in the case of a watchdog timeout.
This driver binds to the nvidia,tegra30-timer device node and gets its
register base from there.
On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds
wrote:
>
> Why are we still discussing this idiocy? It's irrelevant. If the
> standard really allows random store speculation, the standard doesn't
> matter, and sane people shouldn't waste their time arguing about it.
Btw, the other part of this
On Thu, Feb 13, 2014 at 6:50 AM, Peter Zijlstra wrote:
> On Wed, Feb 12, 2014 at 05:40:12PM -0800, Andy Lutomirski wrote:
>> This is a strawman proposal to simplify the idle implementation, eliminate
>> a race
>>
>> Benefits over current code:
>> - ttwu_queue_remote doesn't use an IPI unless
On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
> > I'm fine with ACPI tables if we can provide simple means for embedded
> > users to load one via grub or just attach it to the kernel image.
>
> That already exists, see
On Wednesday 12 February 2014, Courtney Cavin wrote:
> On Tue, Feb 11, 2014 at 09:35:01AM +0100, Arnd Bergmann wrote:
> > On Monday 10 February 2014 16:23:48 Courtney Cavin wrote:
> Then again, I think that the context management stuff is the exception as
> well,
> and I think that can/should
On Fri, Feb 14, 2014 at 9:29 AM, Paul E. McKenney
wrote:
>
> Linus, Peter, any objections to marking places where we are relying on
> ordering from control dependencies against later stores? This approach
> seems to me to have significant documentation benefits.
Quite frankly, I think it's
On 02/14/2014 11:16 PM, Eric W. Biederman wrote:
> Cyrill Gorcunov writes:
>
>> On Fri, Feb 14, 2014 at 09:43:14PM +0400, Andrew Vagin wrote:
My brain hurts just looking at this patch and how you are justifying it.
For the resources you are mucking with below all you have to do is
> On Fri, Feb 14, 2014 at 09:09:52AM +0200, Jani Nikula wrote:
>
> It seems that it will be better to track this in bugzilla rather than
> the mailing lists. Please file a bug on DRM/Intel component at
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI. Attach these
> files.
Done. We can
On 02/12/2014 11:50 PM, Viresh Kumar wrote:
> This patchset creates/calls cpufreq suspend/resume callbacks from
> dpm_{suspend|resume}()
> for handling suspend/resume of cpufreq governors and core.
Are these patches for 3.14 or 3.15?
I ask because I just tested Linus's master from a few days
The frame PC value in the unwind code used to just take the saved LR
value and use that. That's incorrect as a stack trace, since it shows
the return path stack, not the call path stack.
In particular, it shows faulty information in case the bl is done as
the very last instruction of one label,
On Fri, Feb 14, 2014 at 11:23 AM, Russell King - ARM Linux
wrote:
>> https://lkml.org/lkml/2014/2/12/662
>
> It's not that simple, because APX in section descriptors doesn't exist
> on pre-v6 ARMs. This needs to be conditional upon the CPU arch.
Ah! Okay, do we need a single #define to describe
On 02/14/2014 11:15 AM, Thomas Gleixner wrote:
>
>
> On Fri, 14 Feb 2014, H. Peter Anvin wrote:
>
>> We could also just add an ACPI table... same concept. Still need to find it.
>
> I'm fine with ACPI tables if we can provide simple means for embedded
> users to load one via grub or just
On Fri, Feb 14, 2014 at 11:13:53AM -0800, Kees Cook wrote:
> On Fri, Feb 14, 2014 at 2:17 AM, Catalin Marinas
> wrote:
> > On Thu, Feb 13, 2014 at 07:52:30PM +, Kees Cook wrote:
> >> On 2-level page table systems, the PMD has 2 section entries. Report
> >> these, otherwise ARM_PTDUMP will
On Fri, 2014-02-14 at 09:29 -0800, Paul E. McKenney wrote:
> On Thu, Feb 13, 2014 at 08:43:01PM -0800, Torvald Riegel wrote:
> > On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote:
>
> [ . . . ]
>
> > > Another option would be to flag the conditional expression, prohibiting
> > > the
On Fri, 2014-02-14 at 10:50 +0100, Peter Zijlstra wrote:
> On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote:
> > That depends on what your goal is.
First, I don't know why you quoted that, but without the context,
quoting it doesn't make sense. Let me repeat the point. The
Cyrill Gorcunov writes:
> On Fri, Feb 14, 2014 at 09:43:14PM +0400, Andrew Vagin wrote:
>> > My brain hurts just looking at this patch and how you are justifying it.
>> >
>> > For the resources you are mucking with below all you have to do is to
>> > verify that you are below the appropriate
On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> We could also just add an ACPI table... same concept. Still need to find it.
I'm fine with ACPI tables if we can provide simple means for embedded
users to load one via grub or just attach it to the kernel image.
Sure, the user needs to know how
On Fri, Feb 14, 2014 at 2:17 AM, Catalin Marinas
wrote:
> On Thu, Feb 13, 2014 at 07:52:30PM +, Kees Cook wrote:
>> On 2-level page table systems, the PMD has 2 section entries. Report
>> these, otherwise ARM_PTDUMP will miss reporting permission changes on
>> odd section boundaries.
>>
>>
On Wed, Feb 12, 2014 at 09:41:53PM +0200, Tomas Winkler wrote:
> A client has to acquire host buffer
> before writing, we add lock like wrapper
> to replace the code snippet
>
> if (dev->hbuf_is_ready)
> dev->hbuf_is_ready = false;
>
> Signed-off-by: Tomas Winkler
> ---
>
On Fri, Feb 14, 2014 at 7:46 AM, Steven Newbury wrote:
>>
>> Oh, never mind! I didn't notice pref_bar has been renamed to
>> assign_pref_bars. It's working now! :)
>
> There's no pci bridge/bus hotplug though. Docking doesn't reveal the
> pci-e->pci bridge or the (radeon) devices on the other
On Fri, Feb 14, 2014 at 8:22 AM, Dave Martin wrote:
> On Thu, Feb 13, 2014 at 05:04:10PM -0800, Kees Cook wrote:
>> Introduce "CONFIG_DEBUG_RODATA" to mostly match the x86 config, though
>> the behavior is different: it depends on STRICT_KERNMEM_PERMS, which
>> sets rodata read-only (but
On Fri, Feb 14, 2014 at 11:01 AM, Jeff Chua wrote:
> On Fri, Feb 14, 2014 at 9:57 PM, Takashi Iwai wrote:
>> The other possible change in hda_intel.c is the enablement of runtime
>> PM for Panther Point. But it's been working for other chips, so
>> wondering why it hits anything. In anyway,
On 02/14/2014 01:20 AM, Johannes Weiner wrote:
> On Thu, Feb 13, 2014 at 09:33:32PM +0400, Vladimir Davydov wrote:
>> On 02/13/2014 02:01 AM, Johannes Weiner wrote:
>>> On Wed, Feb 12, 2014 at 10:05:43PM +0400, Vladimir Davydov wrote:
On 02/12/2014 12:19 AM, Johannes Weiner wrote:
> On
On 14.02.2014 19:23, Stefan Bader wrote:
> On 14.02.2014 18:33, Borislav Petkov wrote:
>> On Fri, Feb 14, 2014 at 06:02:32PM +0100, Stefan Bader wrote:
>>> Okaaay, I think I did what you asked. So yes, there is sse2 in the cpu
>>> info. And
>>> there is a mfence in the disassembly:
>>
>> Btw, I
On 02/13/2014 12:26 PM, Peter Zijlstra wrote:
On Thu, Feb 13, 2014 at 05:35:46PM +0100, Peter Zijlstra wrote:
On Tue, Feb 11, 2014 at 03:12:59PM -0500, Waiman Long wrote:
Using the same locktest program to repetitively take a single rwlock with
programmable number of threads and count their
On Thu, Feb 13, 2014 at 3:26 AM, Matt Fleming wrote:
> On Wed, 05 Feb, at 05:03:57PM, Leif Lindholm wrote:
>> From: Roy Franz
>>
>> Add the get_dram_base() function and efi_call_physN() macros
>> that are shared by arm/arm64.
>>
>> Signed-off-by: Roy Franz
>> Signed-off-by: Leif Lindholm
>>
On Fri, Feb 14, 2014 at 9:57 PM, Takashi Iwai wrote:
> The other possible change in hda_intel.c is the enablement of runtime
> PM for Panther Point. But it's been working for other chips, so
> wondering why it hits anything. In anyway, please give the full
> Oops messages not only the stack
On 02/14/2014 07:26 PM, Laurent Pinchart wrote:
Enable the CMT0 device and configure channel 0 as a clock event
provider.
Signed-off-by: Laurent Pinchart
diff --git a/arch/arm/mach-shmobile/include/mach/r8a7790.h
b/arch/arm/mach-shmobile/include/mach/r8a7790.h index 0b95bab..62b31f3
This converts twl4030-madc module to use the Industrial IO ADC
framework and adds device tree support.
Signed-off-by: Sebastian Reichel
---
drivers/mfd/twl4030-madc.c | 121 ++---
1 file changed, 114 insertions(+), 7 deletions(-)
diff --git
On Fri, 14 Feb 2014, Joonsoo Kim wrote:
> Now, we have separate alien_cache structure, so it'd be better to hold
> the lock on alien_cache while manipulating alien_cache. After that,
> we don't need the lock on array_cache, so remove it.
Acked-by: Christoph Lameter
--
To unsubscribe from this
Add devicetree binding documentation for twl4030-madc
analog digital converter.
Signed-off-by: Sebastian Reichel
---
.../devicetree/bindings/iio/adc/twl4030-madc.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
On Fri, 14 Feb 2014, Joonsoo Kim wrote:
> Currently, we use array_cache for alien_cache. Although they are mostly
> similar, there is one difference, that is, need for spinlock.
> We don't need spinlock for array_cache itself, but to use array_cache for
> alien_cache, array_cache structure should
Update twl4030-madc driver to use managed resources.
Signed-off-by: Sebastian Reichel
---
drivers/mfd/twl4030-madc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 4c583e4..5458561 100644
---
This is a driver for an A/D converter, which belongs into
drivers/iio/adc.
Signed-off-by: Sebastian Reichel
---
drivers/iio/adc/Kconfig| 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/twl4030-madc.c | 922 +
drivers/mfd/Kconfig
On Fri, 14 Feb 2014, Joonsoo Kim wrote:
> I haven't heard that this alien cache lock is contended, but to reduce
> chance of contention would be better generally. And with this change,
> we can simplify complex lockdep annotation in slab code.
> In the following patch, it will be implemented.
On 02/14/2014 02:43 AM, Thomas Gleixner wrote:
On Thu, 13 Feb 2014, Fernando Lopez-Lezcano wrote:
On 02/13/2014 03:55 PM, Thomas Gleixner wrote:
On Thu, 13 Feb 2014, Fernando Lopez-Lezcano wrote:
On 02/13/2014 02:25 PM, Thomas Gleixner wrote:
On Wed, 12 Feb 2014, Fernando Lopez-Lezcano
On Fri, 14 Feb 2014, Joonsoo Kim wrote:
> @@ -921,7 +784,7 @@ static int transfer_objects(struct array_cache *to,
> static inline struct alien_cache **alloc_alien_cache(int node,
> int limit, gfp_t gfp)
> {
> - return (struct alien_cache
On 02/13/2014 11:35 AM, Peter Zijlstra wrote:
On Tue, Feb 11, 2014 at 03:12:59PM -0500, Waiman Long wrote:
Using the same locktest program to repetitively take a single rwlock with
programmable number of threads and count their execution times. Each
thread takes the lock 5M times on a 4-socket
On Wed, Feb 05, 2014 at 12:21:07PM -0500, Jason Cooper wrote:
>
> + Bjorn, linux-pci
>
> Bjorn,
>
> It looks like this didn't get Cc'd to linux-pci. Here's a link:
>
> http://www.spinics.net/lists/arm-kernel/msg299721.html
Thanks for the heads-up; I had indeed missed this (I mostly rely on
On 02/14/2014 08:31 AM, Gene Heskett wrote:
> Which is required for my $290 ASUS M2n-SLI Deluxe motherboard to boot.
>
> Not finding the option in any kernel tree that exists on my system,
> except it appears its been replaced or something.
>
> This once in a lifetime boot, to 3.12.9, shows
On Fri, 14 Feb 2014, Joonsoo Kim wrote:
> Factor out initialization of array cache to use it in following patch.
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Fri, 14 Feb 2014, Joonsoo Kim wrote:
> In free_block(), if freeing object makes new free slab and number of
> free_objects exceeds free_limit, we start to destroy this new free slab
> with holding the kmem_cache node lock. Holding the lock is useless and,
> generally, holding a lock as least
We could also just add an ACPI table... same concept. Still need to find it.
On February 14, 2014 10:38:24 AM PST, Thomas Gleixner
wrote:
>On Fri, 14 Feb 2014, H. Peter Anvin wrote:
>> On 02/14/2014 10:21 AM, Thomas Gleixner wrote:
>> > I wish we could just use devicetree for such cases and
The kcmp system call was ported to ARM in
commit 3f7d1fe108dbaefd0c57a41753fc2c90b395f458
"ARM: 7665/1: Wire up kcmp syscall".
Signed-off-by: Christopher Covington
---
arch/arm/include/asm/unistd.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/include/asm/unistd.h
On Fri, 14 Feb 2014, H. Peter Anvin wrote:
> On 02/14/2014 10:21 AM, Thomas Gleixner wrote:
> > I wish we could just use devicetree for such cases and fix the crud
> > ourself.
> >
>
> We'd have to identify the platform, which is the main problem. Right
> now we support quirking for DMI or PCI,
From: Richard Cochran
Date: Fri, 14 Feb 2014 10:06:01 +0100
> People want to be able to configure the auxiliary functions on the
> pins of their PTP devices. My preference for supporting this is:
>
> 1. additional ioctl on the PTP character device
> 2. ethtool ioctl
> 3. DT and/or ACPI
>
> The
Pages allocated from MIGRATE_RESERVE migratetype pageblocks
are not freed back to MIGRATE_RESERVE migratetype free
lists in free_pcppages_bulk()->__free_one_page() if we got
to free_pcppages_bulk() through drain_[zone_]pages().
The freeing through free_hot_cold_page() is okay because
freepage
On 02/13/2014 09:28 PM, Stephen Rothwell wrote:
> Hi all,
>
> If you see failures in building this tree due to missing declarations of
> k..alloc/free, then it may be caused by commit 2bd59d48ebfb ("cgroup:
> convert to kernfs"). Please send Tejun Heo a patch
> adding an inclusion of
On Thu, Feb 13, 2014 at 01:39:54PM +0900, Simon Horman wrote:
> On Thu, Feb 13, 2014 at 12:03:02PM +0900, Magnus Damm wrote:
> > PCI: rcar: Recent driver patches from Ben Dooks and me
> >
> > [PATCH 01/08] PCI: rcar: check platform_get_irq() return code
> > [PATCH v2 02/08] PCI: rcar: add error
From: "Srivatsa S. Bhat"
Date: Fri, 14 Feb 2014 13:30:58 +0530
> 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:
...
> This is wrong, since it is prone to ABBA deadlocks involving the
From: "Srivatsa S. Bhat"
Date: Fri, 14 Feb 2014 13:30:43 +0530
> 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:
...
> This is wrong, since it is prone to ABBA deadlocks involving the
From: "Srivatsa S. Bhat"
Date: Fri, 14 Feb 2014 13:22:05 +0530
> 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:
...
> This is wrong, since it is prone to ABBA deadlocks involving the
From: Alex Elder
Replace the "fake" clocks defined in the "bcm11351.dtsi" device tree
file with real definitions backed by the new BCM281xx clock driver.
Signed-off-by: Alex Elder
Reviewed-by: Matt Porter
Reviewed-by: Tim Kryger
---
arch/arm/boot/dts/bcm11351.dtsi | 192
Add the CLK_IGNORE_UNUSED flag when setting up a peripheral clock.
This prevents unused clocks from getting disabled, and by doing
this we can use the common clock code even before we've resolved
all the spots that need to get a reference to their clock.
Signed-off-by: Alex Elder
Reviewed-by:
> On 02/14/2014 10:13 AM, Conrad Kostecki wrote:
> >>
> >> Does it have DMI?
> >
> > Unfortunately not.
> >
> > # dmidecode 2.12
> > # No SMBIOS nor DMI entry point found, sorry.
> >
>
> Sigh. Does anyone have contacts at Soekris who can complain about this
> stuff?
I don't think, that Soekris
On Fri, 14 Feb 2014, Joonsoo Kim wrote:
> clear_obj_pfmemalloc() takes the pointer to the object pointer as argument
> to store masked value back into this address.
> But this is useless, since we don't use this stored value anymore.
> All we need is just masked value. So makes
On Thu, Feb 13, 2014 at 04:34:32PM +0100, Heiko Stübner wrote:
> From: Heiko Stuebner
>
> Commit 934624d6e9f0 ("regulator: gpio-regulator: do not open-code counting
> and access of dt array elements") forgot to convert the recently added
> gpios-states property using the same pattern.
Applied,
On Fri, Feb 14, 2014 at 10:16:05AM +0200, Ivan T. Ivanov wrote:
> "SPI transfer length should be multiple of SPI word size, where SPI
> word size should be power-of-two multiple"
Yes, that's clearer though you could in theory have a three byte word
(I'm not sure that anyone would actually do
On Fri, Feb 14, 2014 at 10:28:38AM +, Opensource [Steve Twiss] wrote:
> The previous silicon was only sent out in sample form to selected customers
> and will no longer be available. I have been informed that the new silicon
> has been sent out, and everybody should have received the new
On Thu, Feb 13, 2014 at 04:46:46PM +0200, Ivan T. Ivanov wrote:
> + /* No partial transfers accepted */
> + if (!n_words || xfer->len & (w_size - 1))
> + return -EINVAL;
Please write this using % rather than the & - it's a lot clearer what
it's
201 - 300 of 1340 matches
Mail list logo
