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 Documentation/devicetree/bindings/iio/adc/twl4
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 a/drivers/mfd/
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
10064
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 trac
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 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 exe
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 ju
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 Tue
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, ple
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 executabl
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 side
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
> ---
> drivers/misc/m
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.
>>
>> Sig
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 to
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 rli
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 standard
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 compi
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 miss
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 attac
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
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, s
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 bac
> 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 co
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 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 als
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 stupi
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 Documentation/acpi/initrd_table_o
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 need
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.
Signed-of
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 c
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 al
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 r
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 anyw
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 mucking
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 the
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 manage
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 http://www.tux.org/lkm
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 cur
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,
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 new
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 followin
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
+
[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.c2013-12
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
+++ linux/d
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
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
__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 da
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
+++ linux/i
[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 pro
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
===
--- linux.orig/arch/avr3
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 da
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 Tegra114
[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 pro
__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 da
__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 da
__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 da
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 -0
__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 da
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 ma
* 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
--
__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 da
[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 2
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 14:20:5
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
---
arch/mips/include/
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 14:
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
===
--- linux.orig/arch/x86/kernel/cpu
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 s
[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 pro
[Patch depends on another patch in this series that introduces raw_cpu_ops]
Most of these are the uses of &__raw_get_cpu_var for address calculation.
touch_softlockup_watchdog_sync() uses __raw_get_cpu_var to write to
per cpu variables. Use __this_cpu_write instead.
Cc: Wim Van Sebroeck
Cc: lin
[Patch depends on another patch in this series that introduces raw_cpu_ops]
These are generally replaced with raw_cpu_ptr. However, in
gic_get_percpu_base() we immediately dereference the pointer. This is
equivalent to a raw_cpu_read. So use that operation there.
Cc: nicolas.pi...@linaro.org
Cc:
[Patch depends on another patch in this series that introduces raw_cpu_ops]
__this_cpu_ptr is being phased out. So replace with raw_cpu_ptr.
Cc: Russell King
Cc: Catalin Marinas
CC: Will Deacon
Signed-off-by: Christoph Lameter
Index: linux/arch/arm/kernel/smp_twd.c
==
[Patch depends on another patch in this series that introduces raw_cpu_ops]
Replace uses of get_cpu_var for address calculation through this_cpu_ptr.
Cc: net...@vger.kernel.org
Cc: Eric Dumazet
Acked-by: David S. Miller
Signed-off-by: Christoph Lameter
Index: linux/net/core/dev.c
[Patch depends on another patch in this series that introduces raw_cpu_ops]
__this_cpu_ptr is being phased out.
One special case is increment_cpu_stall_ticks().
A per cpu variable is incremented so use raw_cpu_inc().
Cc: Dipankar Sarma
Cc: "Paul E. McKenney"
Signed-off-by: Christoph Lameter
[Patch depends on another patch in this series that introduces raw_cpu_ops]
Convert all uses of __get_cpu_var for address calculation to use
this_cpu_ptr instead.
Cc: Peter Zijlstra
Acked-by: Ingo Molnar
Signed-off-by: Christoph Lameter
Index: linux/include/linux/kernel_stat.h
===
Two new uses introduced in 3.14-rc1.
Signed-off-by: Christoph Lameter
Index: linux/kernel/time/tick-sched.c
===
--- linux.orig/kernel/time/tick-sched.c 2014-02-03 13:36:18.968910485 -0600
+++ linux/kernel/time/tick-sched.c 2014
[Patch depends on another patch in this series that introduces raw_cpu_ops]
__this_cpu_ptr is being phased out.
Cc: Jens Axboe
Signed-off-by: Christoph Lameter
Index: linux/fs/ext4/mballoc.c
===
--- linux.orig/fs/ext4/mballoc.c
Another case was merged for 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
13:48:07.334069941 -0600
+++ linux/drivers
[Patch depends on another patch in this series that introduces raw_cpu_ops]
Convert uses of __get_cpu_var for creating a address from a percpu
offset to this_cpu_ptr.
The two cases where get_cpu_var is used to actually access a percpu
variable are changed to use this_cpu_read/raw_cpu_read.
CC: T
Replace __get_cpu_var uses for address calculation with this_cpu_ptr().
Acked-by: James Hogan
Signed-off-by: Christoph Lameter
Index: linux/arch/metag/kernel/perf/perf_event.c
===
--- linux.orig/arch/metag/kernel/perf/perf_event.c
Use this_cpu_ptr for the address calculation instead of __get_cpu_var.
Acked-by: Bryan Wu
Signed-off-by: Christoph Lameter
Index: linux/drivers/leds/trigger/ledtrig-cpu.c
===
--- linux.orig/drivers/leds/trigger/ledtrig-cpu.c
A single case of using __get_cpu_var for address calculation.
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Signed-off-by: Christoph Lameter
Index: linux/drivers/char/random.c
===
--- linux.orig/drivers/char/random.c2013-12-02 16:0
All of these are for address calculation. Replace with
this_cpu_ptr().
Cc: Daniel Lezcano
Cc: linux...@vger.kernel.org
Acked-by: Rafael J. Wysocki
[cpufreq changes]
Signed-off-by: Christoph Lameter
Index: linux/drivers/cpuidle/governors/ladder.c
Replace the uses of __get_cpu_var for address calculation with this_cpu_ptr.
Cc: Robert Richter
Cc: oprofile-l...@lists.sf.net
Signed-off-by: Christoph Lameter
Index: linux/drivers/oprofile/cpu_buffer.c
===
--- linux.orig/drivers/o
Replace places where __get_cpu_var() is used for an address calculation
with this_cpu_ptr().
Cc: a...@linux-foundation.org
Cc: linux...@kvack.org
Signed-off-by: Christoph Lameter
Index: linux/lib/radix-tree.c
===
--- linux.orig/lib/
Replace uses of &__get_cpu_var for address calculation with this_cpu_ptr.
CC: Steven Rostedt
CC: Frederic Weisbecker
CC: Ingo Molnar
Acked-by: Masami Hiramatsu
Signed-off-by: Christoph Lameter
Index: linux/include/linux/kprobes.h
==
Replace uses of __get_cpu_var for address calculation with this_cpu_ptr.
Cc: a...@linux-foundation.org
Signed-off-by: Christoph Lameter
Index: linux/kernel/printk/printk.c
===
--- linux.orig/kernel/printk/printk.c 2014-02-03 13:20
[Patch depends on another patch in this series that introduces raw_cpu_ops]
With the preempt checking logic for __this_cpu_ops we will get false
positives from locations in the code that use numa_node_id.
Before the __this_cpu ops where introduced there were
no checks for preemption present eith
[Patch depends on another patch in this series that introduces raw_cpu_ops]
The RT_CACHE_STAT_INC macro triggers the new preemption checks
for __this_cpu ops.
I do not see any other synchronization that would allow the use
of a __this_cpu operation here however in commit
dbd2915ce87e811165da0717f
[Patch depends on another patch in this series that introduces raw_cpu_ops]
We define a check function in order to avoid trouble with the
include files. Then the higher level __this_cpu macros are
modified to invoke the preemption check.
Acked-by: Ingo Molnar
Signed-off-by: Christoph Lameter
I
[Patch depends on another patch in this series that introduces raw_cpu_ops]
The initialization of a structure is not subject to synchronization.
The use of __this_cpu would trigger a false positive with the
additional preemption checks for __this_cpu ops.
So simply disable the check through the u
The patches following this one will add preemption checks to __this_cpu
ops so we need to have an alternative way to use this_cpu operations
without preemption checks.
raw_cpu_ops will be the basis for all other ops since these will be the
operations that do not implement any checks.
Primitive o
2014-02-14 23:16 GMT+04:00 Eric W. Biederman :
> 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
Currently, there's nothing explicitly preventing
cgroup_enable_task_cg_lists() from missing set PF_EXITING and race
against cgroup_exit(), and, depending on the timing, cgroup_exit()
seemingly may finish with the task still linked on css_set leading to
list corruption because cgroup_enable_task_cg_
On Fri, 2014-02-14 at 15:23 -0500, Richard Guy Briggs wrote:
> 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 compa
From: Emil Goode
Date: Thu, 13 Feb 2014 19:30:39 +0100
> The struct driver_info ax88178_info is assigned the function
> asix_rx_fixup_common as it's rx_fixup callback. This means that
> FLAG_MULTI_PACKET must be set as this function is cloning the
> data and calling usbnet_skb_return. Not setting
On 14/02/14, Eric Paris wrote:
> On Fri, 2014-02-14 at 15:23 -0500, Richard Guy Briggs wrote:
> > 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=1238
On 14/02/14, Richard Guy Briggs wrote:
> On 14/02/14, Eric Paris wrote:
> > On Fri, 2014-02-14 at 15:23 -0500, Richard Guy Briggs wrote:
> > > The AUDIT_SECCOMP record looks something like this:
> > >
> > > type=SECCOMP msg=audit(1373478171.953:32775): auid=4325 uid=4325 gid=4325
> > > ses=1 subj
[+cc Aaron]
On Thu, Jan 30, 2014 at 12:20:38PM -0700, Bjorn Helgaas wrote:
> This reverts commit e8de1481fd71 ("resource: allow MMIO exclusivity for
> device drivers"), removing these exported interfaces:
>
> pci_request_region_exclusive()
> pci_request_regions_exclusive()
> pci_request_sel
401 - 500 of 670 matches
Mail list logo
