Re: [PATCH] KVM: x86: fix kvmclock breakage from timers branch merge
Il 05/09/2014 17:14, Thomas Gleixner ha scritto: > So that means the code is correct. Now where is the bug? In kernel/time/timekeeping.c? We know that we should have base_mono = wall_to_monotonic + xtime_sec Instead it is base_mono = wall_to_monotonic + xtime_sec - seconds from boot time which is... zero. Given this is the only use of base_mono in a notifier, I wonder if it is as simple as this (which I don't have time to test right now): diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index fb4a9c2cf8d9..f6807a85b8c9 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -443,9 +443,9 @@ static void timekeeping_update(struct timekeeper *tk, unsigned int action) ntp_clear(); } update_vsyscall(tk); - update_pvclock_gtod(tk, action & TK_CLOCK_WAS_SET); tk_update_ktime_data(tk); + update_pvclock_gtod(tk, action & TK_CLOCK_WAS_SET); if (action & TK_MIRROR) memcpy(_timekeeper, _core.timekeeper, :) Paolo > Well hidden and still so obvious that it's even visible through the > brown paperpag I'm wearing ... -- 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/lkml/
[GIT PULL] at91: drivers for 3.18 #2
Arnd, Olof, Kevin, This pull-request is focused on the work that Maxime did for migrating our timer (PIT) to the clocksource sub-system. A big cleanup happened which allows us to be even closer to the point when we have only the bare minimum in our formerly crowded mach-at91 directory. This pull-request goes on top of the "drivers" one already sent to you on Sept. 01st. Thanks, best regards, The following changes since commit 405a72c5e78b5c560c8b2711d4000fa5eb063e1b: power: reset: at91-poweroff: fix wakeup status register index (2014-09-01 18:40:44 +0200) are available in the git repository at: git://github.com/at91linux/linux-at91.git tags/at91-drivers2 for you to fetch changes up to 5c1406f573f0f13b85c738a21030aadc9bb36bdd: ARM: at91: PIT: Move the driver to drivers/clocksource (2014-09-03 10:55:46 +0200) Second drivers series for AT91/3.18: - move of the PIT (basic timer) from mach-at91 to its proper location: drivers/clocksource - big cleanup of this driver along the way Maxime Ripard (14): ARM: at91: PIT: Follow the general coding rules ARM: at91: generic.h: Add include safe guards ARM: at91: PIT: Use DIV_ROUND_CLOSEST to compute the cycles ARM: at91: PIT: Use of_have_populated_dt instead of CONFIG_OF ARM: at91: PIT: Rework probe functions ARM: at91: dt: Remove init_time definitions ARM: at91: PIT: Use consistent exit path in probe ARM: at91: PIT: Use pr_fmt ARM: at91: PIT: use request_irq instead of setup_irq ARM: at91: PIT: (Almost) remove the global variables ARM: at91: soc: Add init_time callback ARM: at91: Convert the boards to the init_time callback ARM: at91: PIT: Convert to an early_platform_device ARM: at91: PIT: Move the driver to drivers/clocksource arch/arm/mach-at91/Kconfig | 5 - arch/arm/mach-at91/Makefile | 1 - arch/arm/mach-at91/at91sam9260.c| 34 +++- arch/arm/mach-at91/at91sam9261.c| 34 +++- arch/arm/mach-at91/at91sam9263.c| 34 +++- arch/arm/mach-at91/at91sam926x_time.c | 294 -- arch/arm/mach-at91/at91sam9g45.c| 34 +++- arch/arm/mach-at91/at91sam9rl.c | 34 +++- arch/arm/mach-at91/board-afeb-9260v1.c | 2 +- arch/arm/mach-at91/board-cam60.c| 2 +- arch/arm/mach-at91/board-cpu9krea.c | 2 +- arch/arm/mach-at91/board-dt-sam9.c | 10 -- arch/arm/mach-at91/board-dt-sama5.c | 9 - arch/arm/mach-at91/board-flexibity.c| 2 +- arch/arm/mach-at91/board-foxg20.c | 2 +- arch/arm/mach-at91/board-gsia18s.c | 2 +- arch/arm/mach-at91/board-pcontrol-g20.c | 2 +- arch/arm/mach-at91/board-sam9-l9260.c | 2 +- arch/arm/mach-at91/board-sam9260ek.c| 2 +- arch/arm/mach-at91/board-sam9261ek.c| 4 +- arch/arm/mach-at91/board-sam9263ek.c| 2 +- arch/arm/mach-at91/board-sam9g20ek.c| 4 +- arch/arm/mach-at91/board-sam9m10g45ek.c | 2 +- arch/arm/mach-at91/board-sam9rlek.c | 2 +- arch/arm/mach-at91/board-snapper9260.c | 2 +- arch/arm/mach-at91/board-stamp9g20.c| 4 +- arch/arm/mach-at91/generic.h| 8 +- arch/arm/mach-at91/setup.c | 5 + arch/arm/mach-at91/soc.h| 1 + drivers/clocksource/Kconfig | 4 + drivers/clocksource/Makefile| 1 + drivers/clocksource/timer-atmel-pit.c | 304 32 files changed, 505 insertions(+), 345 deletions(-) delete mode 100644 arch/arm/mach-at91/at91sam926x_time.c create mode 100644 drivers/clocksource/timer-atmel-pit.c -- Nicolas Ferre -- 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/lkml/
[PATCH] Put each per-cpu kdump ELF notes into a single page
On architectures that use percpu-vm, the percpu region is not guaranteed
to be contiguous in physical space. However, fs/proc/vmcore.c expects
all ELF notes to be contiguous. If the ELF note happens to occupy
two non-adjacent physical pages, part of the note may be read from an
incorrect memory location by the kdump kernel, resulting in failure to
initialize /proc/vmcore (if the content of the following physical page,
incorrectly interpreted as an ELF note specifies a large number), wrong
register values or other apparent random memory corruption.
There is currently no mechanism to pass the virtual-to-physical mapping
of the percpu allocation to the kdump kernel. So, instead, I'm changing
the alignment of the ELF note buffer. Since sizeof(note_buf_t) is less
than PAGE_SIZE, aligning the buffer to the nearest higher power of 2
is enough to make sure that the buffer cannot cross a page boundary,
effectively ensuring that the whole buffer is contiguous in physical
space.
Signed-off-by: Petr Tesarik
---
kernel/kexec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 2bee072..cdab59d 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1610,7 +1610,8 @@ void crash_save_cpu(struct pt_regs *regs, int cpu)
static int __init crash_notes_memory_init(void)
{
/* Allocate memory for saving cpu registers. */
- crash_notes = alloc_percpu(note_buf_t);
+ crash_notes = __alloc_percpu(sizeof(note_buf_t),
+roundup_pow_of_two(sizeof(note_buf_t)));
if (!crash_notes) {
pr_warn("Kexec: Memory allocation for saving cpu register
states failed\n");
return -ENOMEM;
--
1.8.4.5
--
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/lkml/
Re: read()/readv() only from page cache
On Fri, Sep 05, 2014 at 12:27:21PM -0400, Milosz Tanski wrote: > I would prefer a interface more like recv() where I can specify the > flag if I want blocking behavior for this read or not. Let me explain > why: > > In a VLDB like workload this would enable me to lower the latency of > common fast requests and. By fast requests I mean ones that do not > require much data, the data is cached, or there's a predictable read > pattern (read-ahead). Obviously it would be at the expense of the > latency of large/slow requests (they have to make 2 read calls, the > first one always EWOULDBLOCK) ... but in that case it doesn't matter > since the time to do actual IO would trump any kind of extra latency. This is another good suggestion. I've actually heard people asking for allowing per-I/O flags for other uses cases. The one I cane remember is applying O_DSYNC only for FUA writes on a SCSI target, the other one would be Samba again, as SMB allows per-I/O flags on the wire as well. > Essentially, it's using the kernel facilities (page cache) to help me > perform better (in a more predictable fashion). I would implement this > in our application tomorrow. It's frustrating that there is a similar > interface (recv* family) that I cannot use. > > I know there's been a bunch of attempts at buffered AIO and none of > them made it into the kernel. It would let me build a buffered AIO > implementation in user-space using a threadpool. And cached data would > not end up getting blocked behind other non-cached requests sitting in > the queue. I know there's other sources of blocking (locking, metadata > lookups) but direct AIO already suffers from these so I'm fine to > paper over that for now. Although I still think providing useful AIO at the kernel level would be better than having everyone reimplement it it still would be useful to allow people to sanely reimplement it. If only to avoid the discussion about what API to use between the non-standard and not really that nice Linux io_submit and the utterly horrible Posix aio_ semantics. -- 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/lkml/
Re: [Patch v4 1/2] freezer: check OOM kill while being frozen
On Fri, Sep 5, 2014 at 7:08 AM, Tejun Heo wrote: >> + /* It might not be safe to check TIF_MEMDIE for pm freeze. */ > > This is just another representation of the following code which isn't > particularly useful. Wouldn't it be better if the comment actually > explains why this might not be safe? > I don't know actually, I never understand pm code, just don't want to take the risk of breaking it as you told. :) -- 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/lkml/
Re: read()/readv() only from page cache
I would prefer a interface more like recv() where I can specify the flag if I want blocking behavior for this read or not. Let me explain why: In a VLDB like workload this would enable me to lower the latency of common fast requests and. By fast requests I mean ones that do not require much data, the data is cached, or there's a predictable read pattern (read-ahead). Obviously it would be at the expense of the latency of large/slow requests (they have to make 2 read calls, the first one always EWOULDBLOCK) ... but in that case it doesn't matter since the time to do actual IO would trump any kind of extra latency. Essentially, it's using the kernel facilities (page cache) to help me perform better (in a more predictable fashion). I would implement this in our application tomorrow. It's frustrating that there is a similar interface (recv* family) that I cannot use. I know there's been a bunch of attempts at buffered AIO and none of them made it into the kernel. It would let me build a buffered AIO implementation in user-space using a threadpool. And cached data would not end up getting blocked behind other non-cached requests sitting in the queue. I know there's other sources of blocking (locking, metadata lookups) but direct AIO already suffers from these so I'm fine to paper over that for now. On Fri, Sep 5, 2014 at 11:48 AM, Christoph Hellwig wrote: > On Fri, Sep 05, 2014 at 12:09:27PM +0100, Mel Gorman wrote: >> I suggest you look at the recent fincore debate. It did not progress much >> the last time because the author wanted to push a lot of functionality in >> there where as reviewers felt it should start simple. The simple case is >> likely a good fit for what you want. The primary downside is that it would >> be race-prone in memory pressure situations as the page could be reclaimed >> between the fincore check and the read but I expect that your application >> is already avoiding reclaim activity. > > I've actually experimentally hacked up O_NONBLOCK support for regular > files so that it only returns data from the page cache, and not > otherwise. Volker promised to test it with Samba, but we never made > any progress on it, and just last week a customer told me they would > have liked to use it if it was available. > > Note that we might want to also avoid blocking on locks, and I have some > vague memory that we shouldn't actually implement O_NONBLOCK on regular > files due to compatibility options but would have to use a new flag > instead. > > Note that mincor/fincore would not help for the usual use case where you > have a non blocking event main loop and want to offload actual blocking > I/O to helper threads, as you it returns information that can be stale > any time. > > One further consideration would be to finally implement real buffered > I/O in kernel space by something like the above and offloading to > workqueues in kernelspace. I think our workqueues now are way better > than any possible user thread pool, although we'd need to find a way to > temporarily tie the work threads to a user address space. -- Milosz Tanski CTO 16 East 34th Street, 15th floor New York, NY 10016 p: 646-253-9055 e: mil...@adfin.com -- 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/lkml/
Re: [PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family
On Friday 05 September 2014 15:22:46 Mark Rutland wrote: > > > A common pattern these days is to do dependencies like > > > > arch/*/Kconfig: > > config ARCH_FOO > > bool "Enable support for Foo platform" > > help > > ... > > > > > > drivers/*/Kconfig > > config SUBSYS_FOO > > bool "SUBSYS driver for Foo" > > depends on ARCH_FOO || COMPILE_TEST > > depends on OF && REGULATOR && GENERIC_PHY # or whatever > > Russell's comments w.r.t. Kconfig warnings when config names change > still holds regardless of select vs depends on. Yes, that's what I wrote in my reply as well. > > That way we can enable everything in the defconfig, but someone > > who likes to build a more specialized kernel can disable the > > other platforms and won't get the drivers that are specific to > > those. > > > > I personally think this is a bit more verbose than what we need, but > > I don't strongly object doing it that way. > > You'd still be able to do this without ARCH_FOO, though you would need > to know which drivers are necessary for a particular SoC. That seems to > be the way things are handled on x86; I don't recall having to select > support for specific machines there, just the individual drivers. The main difference is that there are very few drivers on x86 that are specific to one of the two chip makers. Almost everything is a PCI device that can actually be plugged in anywhere. On ARM64 there is going to be a lot of stuff that really makes sense only for one of the 50 licensees. Arnd -- 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/lkml/
INFO: possible irq lock inversion dependency detected
Hello,
I noticed, with next/master tree, this lockdep splat and at least I could not
find any discussion about this by googling:
[ 33.105722] =
[ 33.105722] [ INFO: possible irq lock inversion dependency detected ]
[ 33.105724] 3.17.0-031700rc3-generic #201409031132 Not tainted
[ 33.105724] -
[ 33.105725] swapper/0/0 just changed the state of lock:
[ 33.105726] (&(>event_lock)->rlock#2){-.}, at:
[] input_event+0x45/0x70
[ 33.105733] but this lock took another, HARDIRQ-unsafe lock in the past:
[ 33.105734] (&(>alloc_lock)->rlock){+.+...}
[ 33.105734]
[ 33.105734] and interrupts could create inverse lock ordering between them.
[ 33.105734]
[ 33.105736]
[ 33.105736] other info that might help us debug this:
[ 33.105737] Chain exists of:
[ 33.105737] &(>event_lock)->rlock#2 -->
&(>buffer_lock)->rlock --> &(>alloc_lock)->rlock
[ 33.105737]
[ 33.105740] Possible interrupt unsafe locking scenario:
[ 33.105740]
[ 33.105740]CPU0CPU1
[ 33.105741]
[ 33.105742] lock(&(>alloc_lock)->rlock);
[ 33.105743]local_irq_disable();
[ 33.105743]
lock(&(>event_lock)->rlock#2);
[ 33.105745]
lock(&(>buffer_lock)->rlock);
[ 33.105746]
[ 33.105747] lock(&(>event_lock)->rlock#2);
[ 33.105748]
[ 33.105748] *** DEADLOCK ***
[ 33.105748]
[ 33.105749] no locks held by swapper/0/0.
[ 33.105750]
[ 33.105750] the shortest dependencies between 2nd lock and 1st lock:
[ 33.105755] -> (&(>alloc_lock)->rlock){+.+...} ops: 30838 {
[ 33.105757] HARDIRQ-ON-W at:
[ 33.105758] []
__lock_acquire+0x538/0xb50
[ 33.105761] []
lock_acquire+0xa9/0x200
[ 33.105763] []
_raw_spin_lock+0x39/0x50
[ 33.105766] []
__set_task_comm+0x2a/0x150
[ 33.105769] []
kthreadd+0x30/0x220
[ 33.105772] []
ret_from_fork+0x7c/0xb0
[ 33.105774] SOFTIRQ-ON-W at:
[ 33.105775] []
__lock_acquire+0x2f3/0xb50
[ 33.105776] []
lock_acquire+0xa9/0x200
[ 33.105778] []
_raw_spin_lock+0x39/0x50
[ 33.105780] []
__set_task_comm+0x2a/0x150
[ 33.105782] []
kthreadd+0x30/0x220
[ 33.105783] []
ret_from_fork+0x7c/0xb0
[ 33.105785] INITIAL USE at:
[ 33.105786] []
__lock_acquire+0x344/0xb50
[ 33.105787] []
lock_acquire+0xa9/0x200
[ 33.105789] []
_raw_spin_lock+0x39/0x50
[ 33.105791] []
__set_task_comm+0x2a/0x150
[ 33.105792] []
kthreadd+0x30/0x220
[ 33.105794] []
ret_from_fork+0x7c/0xb0
[ 33.105796] }
[ 33.105796] ... key at: [] __key.51772+0x0/0x8
[ 33.105799] ... acquired at:
[ 33.105799][] __lock_acquire+0x418/0xb50
[ 33.105801][] lock_acquire+0xa9/0x200
[ 33.105802][] _raw_spin_lock+0x39/0x50
[ 33.105804][] do_prlimit+0x9b/0x200
[ 33.105806][] SyS_getrlimit+0x2a/0x70
[ 33.105808][] system_call_fastpath+0x1a/0x1f
[ 33.105810]
[ 33.105811] -> (tasklist_lock){.+.+..} ops: 26419 {
[ 33.105813]HARDIRQ-ON-R at:
[ 33.105813] []
__lock_acquire+0x2d1/0xb50
[ 33.105815] []
lock_acquire+0xa9/0x200
[ 33.105817] []
_raw_read_lock+0x3c/0x50
[ 33.105818] []
do_wait+0xb6/0x340
[ 33.105820] []
SyS_wait4+0x64/0xe0
[ 33.105822] []
wait_for_helper+0x4b/0x70
[ 33.105824] []
ret_from_fork+0x7c/0xb0
[ 33.105825]SOFTIRQ-ON-R at:
[ 33.105826] []
__lock_acquire+0x2f3/0xb50
[ 33.105828] []
lock_acquire+0xa9/0x200
[ 33.105829] []
_raw_read_lock+0x3c/0x50
[ 33.105831] []
do_wait+0xb6/0x340
[ 33.105833] []
SyS_wait4+0x64/0xe0
[ 33.105834] []
wait_for_helper+0x4b/0x70
[ 33.105836] []
ret_from_fork+0x7c/0xb0
[ 33.105837]INITIAL USE at:
[ 33.105838][]
__lock_acquire+0x344/0xb50
[ 33.105840][]
lock_acquire+0xa9/0x200
[ 33.105842][]
Re: [PATCH] bpf: fix a false positive kmemcheck warning
Hi Mikulas,
On 09/05/2014 06:01 PM, Mikulas Patocka wrote:
This patch fixes false positive kmemcheck warning in bpf.
When we try to write the variable len, the compiler generates a code that
reads the 32-bit word, modifies the bits belonging to "len" and writes the
32-bit word back. The reading of the word results in kmemcheck warning due
to reading uninitialized memory. This patch fixes it by avoiding using bit
fields when kmemcheck is enabled.
Signed-off-by: Mikulas Patocka
You need to submit this patch to netdev (Cc'ed).
---
include/linux/filter.h |5 +
1 file changed, 5 insertions(+)
Index: linux-2.6/include/linux/filter.h
===
--- linux-2.6.orig/include/linux/filter.h 2014-09-04 23:04:26.0
+0200
+++ linux-2.6/include/linux/filter.h2014-09-04 23:43:05.0 +0200
@@ -325,8 +325,13 @@ struct sock;
struct seccomp_data;
struct bpf_prog {
+#ifdef CONFIG_KMEMCHECK
+ booljited;
+ u32 len;
+#else
u32 jited:1,/* Is our filter JIT'ed? */
len:31; /* Number of filter blocks */
+#endif
struct sock_fprog_kern *orig_prog; /* Original BPF program */
unsigned int(*bpf_func)(const struct sk_buff *skb,
const struct bpf_insn *filter);
I don't really like this if-def. If you really want to fix it, can't
you just use :
kmemcheck_bitfield_begin(bpf_anc_data)
...
kmemcheck_bitfield_end(bpf_anc_data)
et al infrastructure as container (in case in future we will add some more
bit flags, since len doesn't really need all 31 bit universe)?
Note, there are currently some patches pending in patchwork that also fill
the u32 hole thus the extra bool would introduce a new hole after that.
Therefore, I think above would be better.
Thanks,
Daniel
--
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/lkml/
Re: [PATCH] bpf: fix a false positive kmemcheck warning
On Fri, Sep 5, 2014 at 9:01 AM, Mikulas Patocka wrote:
> This patch fixes false positive kmemcheck warning in bpf.
>
> When we try to write the variable len, the compiler generates a code that
> reads the 32-bit word, modifies the bits belonging to "len" and writes the
> 32-bit word back. The reading of the word results in kmemcheck warning due
> to reading uninitialized memory. This patch fixes it by avoiding using bit
> fields when kmemcheck is enabled.
It will conflict with pending Hannes's patch.
Once it's in, I can rebase and actually make it unconditional.
These bit savings probably not worth it, since bpf_prog is
dominated by program anyway.
JITs would need to be updated as well, since they're now do
->jited = 1;
I can fix this all up.
Do you mind sharing the kmemcheck warning you see?
> Index: linux-2.6/include/linux/filter.h
> ===
> --- linux-2.6.orig/include/linux/filter.h 2014-09-04 23:04:26.0
> +0200
> +++ linux-2.6/include/linux/filter.h2014-09-04 23:43:05.0 +0200
why diff says 2.6 ? Kinda odd.
> @@ -325,8 +325,13 @@ struct sock;
> struct seccomp_data;
>
> struct bpf_prog {
> +#ifdef CONFIG_KMEMCHECK
> + booljited;
> + u32 len;
> +#else
> u32 jited:1,/* Is our filter JIT'ed? */
> len:31; /* Number of filter blocks */
> +#endif
> struct sock_fprog_kern *orig_prog; /* Original BPF program */
> unsigned int(*bpf_func)(const struct sk_buff *skb,
> const struct bpf_insn *filter);
--
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/lkml/
Re: bit fields && data tearing
On 09/05/2014 08:37 AM, David Laight wrote:
> From: Peter Hurley
>> On 09/05/2014 04:30 AM, David Laight wrote:
>>> I've seen gcc generate 32bit accesses for 16bit structure members on arm.
>>> It does this because of the more limited range of the offsets for the 16bit
>>> access.
>>> OTOH I don't know if it ever did this for writes - so it may be moot.
>>
>> Can you recall the particulars, like what ARM config or what code?
>>
>> I tried an overly-simple test to see if gcc would bump up to the word load
>> for
>> the 12-bit offset mode, but it stuck with register offset rather than
>> immediate
>> offset. [I used the compiler options for allmodconfig and a 4.8
>> cross-compiler.]
>>
>> Maybe the test doesn't generate enough register pressure on the compiler?
>
> Dunno, I would have been using a much older version of the compiler.
> It is possible that it doesn't do it any more.
> It might only have done it for loads.
>
> The compiler used to use misaligned 32bit loads for structure
> members on large 4n+2 byte boundaries as well.
> I'm pretty sure it doesn't do that either.
>
> There have been a lot of compiler versions since I was compiling
> anything for arm.
Yeah, it seems gcc for ARM no longer uses the larger operand size as a
substitute for 12-bit immediate offset addressing mode, even for reads.
While this test:
struct x {
short b[12];
};
short load_b(struct x *p) {
return p->b[8];
}
generates the 8-bit immediate offset form,
short load_b(struct x *p) {
0: e1d001f0ldrsh r0, [r0, #16]
4: e12fff1ebx lr
pushing the offset out past 256:
struct x {
long unused[64];
short b[12];
};
short load_b(struct x *p) {
return p->b[8];
}
generates the register offset addressing mode instead of 12-bit immediate:
short load_b(struct x *p) {
0: e3a03e11mov r3, #272; 0x110
4: e19000f3ldrsh r0, [r0, r3]
8: e12fff1ebx lr
Regards,
Peter Hurley
[Note: I compiled without the frame pointer to simplify the code generation]
--
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/lkml/
[PATCH] dcache: fix kmemcheck warning in switch_names
This patch fixes kmemcheck warning in switch_names. The function
switch_names swaps inline names of two dentries. It swaps full arrays
d_iname, no matter how many bytes are really used by the strings. Reading
data beyond string ends results in kmemcheck warning.
We fix the bug by marking both arrays as fully initialized.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org # v3.15
---
fs/dcache.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6/fs/dcache.c
===
--- linux-2.6.orig/fs/dcache.c 2014-09-04 23:04:21.0 +0200
+++ linux-2.6/fs/dcache.c 2014-09-04 23:43:11.0 +0200
@@ -2407,6 +2407,8 @@ static void switch_names(struct dentry *
*/
unsigned int i;
BUILD_BUG_ON(!IS_ALIGNED(DNAME_INLINE_LEN,
sizeof(long)));
+ kmemcheck_mark_initialized(dentry->d_iname,
DNAME_INLINE_LEN);
+ kmemcheck_mark_initialized(target->d_iname,
DNAME_INLINE_LEN);
for (i = 0; i < DNAME_INLINE_LEN / sizeof(long); i++) {
swap(((long *) >d_iname)[i],
((long *) >d_iname)[i]);
--
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/lkml/
Re: [PATCH 1/2 V4] irqchip: gic: Add supports for ARM GICv2m MSI(-X)
On 28/08/14 09:59, Suravee Suthikulpanit wrote: > > > On 08/15/2014 09:03 AM, Marc Zyngier wrote: >>> + >>> +static struct irq_chip gicv2m_chip; >>> + >>> +#ifdef CONFIG_OF >> >> Is there any reason why this should be guarded by CONFIG_OF? Surely the >> v2m capability should only be enabled if OF is. > > [Suravee] > We are also planning to support ACPI in the future also, which will be > using a different init function. Also, there is the same #ifdef in the > irq-gic.c for the gic_of_init(). So, I am just trying to be consistent > here. > > >>> + >>> + memcpy(_chip, gic->irq_chip, sizeof(struct irq_chip)); >>> + gicv2m_chip.name = "GICv2m", >>> + gicv2m_chip.irq_mask = gicv2m_mask_irq; >>> + gicv2m_chip.irq_unmask = gicv2m_unmask_irq; >>> + gic->irq_chip = _chip; >> >> I liked it until this last line. You're overriding the irq_chip for the >> whole GIC. I was expecting you'd only use it for the MSI range >> (basically return a range to the caller, together with your brand new >> irq_chip). > > [Suravee] > I'm not sure if I understand you point here. Actually, I don't see the > whole point of the need to have a whole different irq_chip for v2m > stuff. All I need is just a way to overwrite the irq_chip.irq_mask() > and irq_chip.irq_unmask() with the v2m version which should check for > MSI before calling mask/unmask_msi_irq(). I should be able to just do: > > gic->irq_chip.irq_mask = gicv2m_mask_irq; > gic->irq_chip.irq_unmask = gicv2m_unmask_irq; You should only do it for the few interrupts that are actually routed via the v2m widget, not inflict the overhead on all interrupts. This is why I insist on having a separate irqchip, and for this irqchip to be only used for the MSI-generated interrupts. Have a look at what I do for GICv3: http://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/tree/drivers/irqchip/irq-gic-v3.c?h=gicv3/its-split=b717e532c4312a410a8ee0cb2349baa2769c6b94#n712 and how this gets used when routing the interrupts: http://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/tree/drivers/irqchip/irq-gic-v3.c?h=gicv3/its-split=b717e532c4312a410a8ee0cb2349baa2769c6b94#n589 The ITS gets its own irqchip, entirely separate from the rest of the GIC. This gives you the flexibility you require, and let the other interrupts free of any overhead. Thanks, M. -- Jazz is not dead. It just smells funny... -- 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/lkml/
Re: [PATCH v3 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver
On Fri, Sep 5, 2014 at 6:38 PM, Johan Hovold wrote:
> On Fri, Sep 05, 2014 at 06:17:59PM +0300, Octavian Purdila wrote:
>
>> +static int dln2_do_remove(struct dln2_gpio *dln2)
>> +{
>> + /* When removing the DLN2 USB device, gpiochip_remove may fail
>> + * due to i2c drivers holding a GPIO pin. However, the i2c bus
>> + * will eventually be removed triggering an i2c driver remove
>> + * which will release the GPIO pin. So retrying the operation
>> + * later should succeed. */
>> + int ret = gpiochip_remove(>gpio);
>> + struct device *dev = dln2->gpio.dev;
>> +
>> + if (ret < 0) {
>> + if (ret == -EBUSY)
>> + schedule_delayed_work(>remove_work.work, HZ/10);
>> + else
>> + dev_warn(dev, "error removing gpio chip: %d\n", ret);
>> + } else {
>> + kfree(dln2);
>> + }
>> +
>> + return ret;
>> +}
>
> Apparently, the return value from gpiochip_remove is going away:
>
> "Start to kill off the return value from gpiochip_remove() by
> removing the __must_check attribute and removing all checks
> inside the drivers/gpio directory. The rationale is: well what
> were we supposed to do if there is an error code? Not much:
> print an error message. And gpiolib already does that. So make
> this function return void eventually."
>
> https://www.mail-archive.com/linux-gpio@vger.kernel.org/msg03468.html
>
Oh, I missed this, thanks for pointing it out.
> Also, have you considered what happens if there are gpios exported
> through sysfs? These may never be released.
>
> In general, how well have these patches been tested with disconnect
> events? At least gpiolib is known to blow up (sooner or later) when a
> gpiochip is removed when having requested gpios.
>
I do disconnect tests regularly. Since switching to the new irq
interface the following patch is needed:
https://lkml.org/lkml/2014/9/5/408
With it and the current patch sets things seems to work well.
--
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/lkml/
Re: [PATCHv2] watchdog: imx2_wdt: Convert to use regmap framework's endianness method.
On Fri, Sep 05, 2014 at 07:11:31AM +, li.xi...@freescale.com wrote:
> Hi,
>
> Ping :)
>
Wim usually picks up patches shortly before the next release window opens.
It is in my watchdog-next branch, so it is not forgotten. I'll send a pull
request to Wim after -rc5.
Wim, I am wondering - should I ask Stephen to add my watchdog-next branch to
linux-next ? I know it isn't really perfect, and there is no guarantee that
you will accept the patches in my branch, but it would expose the pending
patches to earlier visibility in -next.
Thanks,
Guenter
> Thanks,
>
> BRs
> Xiubo
>
>
> > -Original Message-
> > From: Xiubo Li [mailto:li.xi...@freescale.com]
> > Sent: Monday, August 25, 2014 3:55 PM
> > To: w...@iguana.be; li...@roeck-us.net; m...@pengutronix.de; linux-
> > watch...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Xiubo
> > Li-B47053
> > Subject: [PATCHv2] watchdog: imx2_wdt: Convert to use regmap framework's
> > endianness method.
> >
> > Regmap framework will contain some patches to handle endianess, and there
> > does not need any parsing of endianness DT properties of individual driver,
> > so we can savely remove it here.
> >
> > Signed-off-by: Xiubo Li
> > Cc: Markus Pargmann
> > Reviewed-by: Guenter Roeck
> > ---
> >
> > Changes in v2:
> > - Remove useless header file.
> >
> >
> >
> >
> > Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt | 4 ++--
> > drivers/watchdog/imx2_wdt.c| 9 +
> > 2 files changed, 3 insertions(+), 10 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> > b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> > index e52ba2d..9e1ebe2 100644
> > --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> > +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> > @@ -6,8 +6,8 @@ Required properties:
> > - interrupts : Should contain WDT interrupt
> >
> > Optional property:
> > -- big-endian: If present the watchdog device's registers are implemented
> > - in big endian mode, otherwise in little mode.
> > +- big-endian: Boolean property, required if all the i.MX WDT registers
> > + are big-endian rather than little-endian.
> >
> > Examples:
> >
> > diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> > index 68c3d37..afc8738 100644
> > --- a/drivers/watchdog/imx2_wdt.c
> > +++ b/drivers/watchdog/imx2_wdt.c
> > @@ -28,7 +28,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -182,7 +181,7 @@ static struct watchdog_ops imx2_wdt_ops = {
> > .set_timeout = imx2_wdt_set_timeout,
> > };
> >
> > -static struct regmap_config imx2_wdt_regmap_config = {
> > +static const struct regmap_config imx2_wdt_regmap_config = {
> > .reg_bits = 16,
> > .reg_stride = 2,
> > .val_bits = 16,
> > @@ -191,12 +190,10 @@ static struct regmap_config imx2_wdt_regmap_config = {
> >
> > static int __init imx2_wdt_probe(struct platform_device *pdev)
> > {
> > - struct device_node *np = pdev->dev.of_node;
> > struct imx2_wdt_device *wdev;
> > struct watchdog_device *wdog;
> > struct resource *res;
> > void __iomem *base;
> > - bool big_endian;
> > int ret;
> > u32 val;
> >
> > @@ -204,10 +201,6 @@ static int __init imx2_wdt_probe(struct platform_device
> > *pdev)
> > if (!wdev)
> > return -ENOMEM;
> >
> > - big_endian = of_property_read_bool(np, "big-endian");
> > - if (big_endian)
> > - imx2_wdt_regmap_config.val_format_endian = REGMAP_ENDIAN_BIG;
> > -
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > base = devm_ioremap_resource(>dev, res);
> > if (IS_ERR(base))
> > --
> > 1.8.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/lkml/
Re: read()/readv() only from page cache
On Fri, Sep 05, 2014 at 12:02:19PM -0400, Jeff Moyer wrote: > > One further consideration would be to finally implement real buffered > > I/O in kernel space by something like the above and offloading to > > workqueues in kernelspace. I think our workqueues now are way better > > than any possible user thread pool, although we'd need to find a way to > > temporarily tie the work threads to a user address space. > > Do you mean real buffered AIO? Yes. -- 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/lkml/
Re: read()/readv() only from page cache
Christoph Hellwig writes: > On Fri, Sep 05, 2014 at 12:09:27PM +0100, Mel Gorman wrote: >> I suggest you look at the recent fincore debate. It did not progress much >> the last time because the author wanted to push a lot of functionality in >> there where as reviewers felt it should start simple. The simple case is >> likely a good fit for what you want. The primary downside is that it would >> be race-prone in memory pressure situations as the page could be reclaimed >> between the fincore check and the read but I expect that your application >> is already avoiding reclaim activity. > > I've actually experimentally hacked up O_NONBLOCK support for regular > files so that it only returns data from the page cache, and not > otherwise. Volker promised to test it with Samba, but we never made > any progress on it, and just last week a customer told me they would > have liked to use it if it was available. > > Note that we might want to also avoid blocking on locks, and I have some > vague memory that we shouldn't actually implement O_NONBLOCK on regular > files due to compatibility options but would have to use a new flag > instead. FWIW, here's a discussion from an old attempt at O_NONBLOCK for regular files: http://www.gossamer-threads.com/lists/linux/kernel/477936?do=post_view_threaded#477936 I recall it blowing up in various situations, so yeah, a new flag would be a good idea. > Note that mincor/fincore would not help for the usual use case where you > have a non blocking event main loop and want to offload actual blocking > I/O to helper threads, as you it returns information that can be stale > any time. > > One further consideration would be to finally implement real buffered > I/O in kernel space by something like the above and offloading to > workqueues in kernelspace. I think our workqueues now are way better > than any possible user thread pool, although we'd need to find a way to > temporarily tie the work threads to a user address space. Do you mean real buffered AIO? Cheers, Jeff -- 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/lkml/
[PATCH] bpf: fix a false positive kmemcheck warning
This patch fixes false positive kmemcheck warning in bpf.
When we try to write the variable len, the compiler generates a code that
reads the 32-bit word, modifies the bits belonging to "len" and writes the
32-bit word back. The reading of the word results in kmemcheck warning due
to reading uninitialized memory. This patch fixes it by avoiding using bit
fields when kmemcheck is enabled.
Signed-off-by: Mikulas Patocka
---
include/linux/filter.h |5 +
1 file changed, 5 insertions(+)
Index: linux-2.6/include/linux/filter.h
===
--- linux-2.6.orig/include/linux/filter.h 2014-09-04 23:04:26.0
+0200
+++ linux-2.6/include/linux/filter.h2014-09-04 23:43:05.0 +0200
@@ -325,8 +325,13 @@ struct sock;
struct seccomp_data;
struct bpf_prog {
+#ifdef CONFIG_KMEMCHECK
+ booljited;
+ u32 len;
+#else
u32 jited:1,/* Is our filter JIT'ed? */
len:31; /* Number of filter blocks */
+#endif
struct sock_fprog_kern *orig_prog; /* Original BPF program */
unsigned int(*bpf_func)(const struct sk_buff *skb,
const struct bpf_insn *filter);
--
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/lkml/
[PATCH] staging: binder: cmd_name must be initialised
Variable cmd_name must be initialised as variable name is.
Signed-off-by: Dmitry Voytik
---
drivers/staging/android/binder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index 4f34dc0..93b067f 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -2233,7 +2233,7 @@ retry:
case BINDER_WORK_NODE: {
struct binder_node *node = container_of(w, struct
binder_node, work);
uint32_t cmd = BR_NOOP;
- const char *cmd_name;
+ const char *cmd_name = "BR_NOOP";
int strong = node->internal_strong_refs ||
node->local_strong_refs;
int weak = !hlist_empty(>refs) ||
node->local_weak_refs || strong;
--
1.9.1
--
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/lkml/
[GIT PULL] at91: fixes for 3.17 #1
Arnd, Olof, Kevin, Little pull-request for fixing CCF conversion done during 3.17. The use of at91sam9g20 proper compatibility string is useful when booting without U-Boot (this is why we discover it now). Thanks, best regards, The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f: Linux 3.17-rc3 (2014-08-31 18:23:04 -0700) are available in the git repository at: git://github.com/at91linux/linux-at91.git tags/at91-fixes for you to fetch changes up to ea4fc621adec8956944ecdb9a36c549cba8718c0: ARM: at91/dt: rm9200: fix usb clock definition (2014-09-05 17:36:12 +0200) First AT91 fixes batch for 3.17: - compatibility string precision - clock registration and USB DT fix for at91rm9200 Alexandre Belloni (2): ARM: at91: rm9200: fix clock registration ARM: at91/dt: rm9200: fix usb clock definition Gaël PORTAY (1): ARM: at91/dt: sam9g20: set at91sam9g20 pllb driver arch/arm/boot/dts/at91rm9200.dtsi| 2 +- arch/arm/boot/dts/at91sam9g20.dtsi | 1 + arch/arm/mach-at91/board-dt-rm9200.c | 11 ++- 3 files changed, 12 insertions(+), 2 deletions(-) -- Nicolas Ferre -- 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/lkml/
Re: [RFC] memory cgroup: my thoughts on memsw
On Fri, Sep 05, 2014 at 11:20:43PM +0900, Kamezawa Hiroyuki wrote: > Basically, I don't like OOM Kill. Anyone don't like it, I think. > > In recent container use, application may be build as "stateless" and > kill-and-respawn may not be problematic, but I think killing "a" process > by oom-kill is too naive. > > If your proposal is triggering notification to user space at hitting > anon+swap limit, it may be useful. > ...Some container-cluster management software can handle it. > For example, container may be restarted. > > Memcg has threshold notifier and vmpressure notifier. > I think you can enhance it. [...] > My point is that "killing a process" tend not to be able to fix the situation. > For example, fork-bomb by "make -j" cannot be handled by it. > > So, I don't want to think about enhancing OOM-Kill. Please think of better > way to survive. With the help of countainer-management-softwares, I think > we can have several choices. > > Restart contantainer (killall) may be the best if container app is stateless. > Or container-management can provide some failover. The problem I'm trying to set out is not about OOM actually (sorry if the way I explain is confusing). We could probably configure OOM to kill a whole cgroup (not just a process) and/or improve user-notification so that the userspace could react somehow. I'm sure it must and will be discussed one day. The problem is that *before* invoking OOM on *global* pressure we're trying to reclaim containers' memory and if there's progress we won't invoke OOM. This can result in a huge slow down of the whole system (due to swap out). And if we want to fully make use of soft limits, we currently have no means to limit anon memory at all. It's just impossible, because memsw.limit must be > soft limit, otherwise it makes no sense. So we will be trying to swap out under global pressure until we finally realize there's no point in it and call OOM. If we don't, we'll be suffering until the load goes away by itself. > The 1st reason we added memsw.limit was for avoiding that the whole swap > is used up by a cgroup where memory-leak of forkbomb running and not for > some intellegent controls. > > From your opinion, I feel what you want is avoiding charging against > page-caches. > But thiking docker at el, page-cache is not shared between containers any > more. > I think "including cache" makes sense. Not exactly. It's not about sharing caches among containers. The point is (1) it's difficult to estimate the size of file caches that will max out the performance of a container, and (2) a typical workload will perform better and put less pressure on disk if it has more caches. Now imagine a big host running a small number of containers and therefore having a lot of free memory most of time, but still experiencing load spikes once an hour/day/whatever when memory usage raises up drastically. It'd be unwise to set hard limits for those containers that are running regularly, because they'd probably perform much better if they had more file caches. So the admin decides to use soft limits instead. He is forced to use memsw.limit > the soft limit, but this is unsafe, because the container may eat anon memory up to memsw.limit then, and anon memory isn't easy to get rid of when it comes to the global pressure. If the admin had a mean to limit swappable memory, he could avoid it. This is what I was trying to illustrate by the example in the first e-mail of this thread. Note if there were no soft limits, the current setup would be just fine, otherwise it fails. And soft limits are proved to be useful AFAIK. Thanks, Vladimir -- 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/lkml/
Re: [PATCH v3] ARM: dts: qcom: Add initial IFC6540 board device tree
Am 05.09.2014 17:20, schrieb Kumar Gala:
> On Sep 5, 2014, at 9:26 AM, Andreas Färber wrote:
>> Am 03.09.2014 18:50, schrieb Georgi Djakov:
>>> diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
>>> b/arch/arm/boot/dts/qcom-apq8084.dtsi
>>> index 21d01e5..1f130bc 100644
>>> --- a/arch/arm/boot/dts/qcom-apq8084.dtsi
>>> +++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
>>> @@ -3,6 +3,7 @@
>>> #include "skeleton.dtsi"
>>>
>>> #include
>>> +#include
>>>
>>> / {
>>> model = "Qualcomm APQ 8084";
>>> @@ -203,5 +204,27 @@
>>> clock-names = "core", "iface";
>>> status = "disabled";
>>> };
>>> +
>>> + sdhci@f9824900 {
>>> + compatible = "qcom,sdhci-msm-v4";
>>> + reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
>>> + reg-names = "hc_mem", "core_mem";
>>> + interrupts = <0 123 0>, <0 138 0>;
>>
>> I see that you've used GPIO_ACTIVE_* above. Is the trailing zero here
>> possibly IRQ_TYPE_NONE?
>>
>>> + interrupt-names = "hc_irq", "pwr_irq";
>>> + clocks = < GCC_SDCC1_APPS_CLK>, <
>>> GCC_SDCC1_AHB_CLK>;
>>> + clock-names = "core", "iface";
>>> + status = "disabled";
>>> + };
>>> +
>>> + sdhci@f98a4900 {
>>> + compatible = "qcom,sdhci-msm-v4";
>>> + reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
>>> + reg-names = "hc_mem", "core_mem";
>>> + interrupts = <0 125 0>, <0 221 0>;
>>> + interrupt-names = "hc_irq", "pwr_irq";
>>> + clocks = < GCC_SDCC2_APPS_CLK>, <
>>> GCC_SDCC2_AHB_CLK>;
>>> + clock-names = "core", "iface";
>>> + status = "disabled";
>>> + };
>>
>> If you assign labels to these two nodes, you can reference them in the
>> .dts as {...};. Same for the uart node. That avoids
>> duplicating the hierarchy, detects spelling mistakes at compile time and
>> reduces indentation. Cf. the recent ifc6410 patch.
>
> Got no issues with introducing the labels, but I’d like to keep the hierarchy
> in the .dts file.
Any explanation why? The Samsung guys have been very strict to adopt
this new style, with inherited nodes sorted alphabetically after / {};,
and the ifc6540 is a new .dts we could apply the new pattern to.
But if you don't reference the node anywhere, there's no real benefit to
adding a label in the first place. It can still be done once needed.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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/lkml/
Re: [PATCH v3] ARM: dts: qcom: Add initial IFC6540 board device tree
Hi
On 09/05/2014 05:26 PM, Andreas Färber wrote:
<...>
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 123 0>, <0 138 0>;
I see that you've used GPIO_ACTIVE_* above. Is the trailing zero here
possibly IRQ_TYPE_NONE?
Yes, it is. Will update it. Thanks!
+ interrupt-names = "hc_irq", "pwr_irq";
+ clocks = < GCC_SDCC1_APPS_CLK>, <
GCC_SDCC1_AHB_CLK>;
+ clock-names = "core", "iface";
+ status = "disabled";
+ };
+
+ sdhci@f98a4900 {
+ compatible = "qcom,sdhci-msm-v4";
+ reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <0 125 0>, <0 221 0>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ clocks = < GCC_SDCC2_APPS_CLK>, <
GCC_SDCC2_AHB_CLK>;
+ clock-names = "core", "iface";
+ status = "disabled";
+ };
If you assign labels to these two nodes, you can reference them in the
.dts as {...};. Same for the uart node. That avoids
duplicating the hierarchy, detects spelling mistakes at compile time and
reduces indentation. Cf. the recent ifc6410 patch.
Sure, adding a label will not hurt.
Also, is sdhci the best node name here? Usually it's not supposed to
reflect the exact interface used (e.g., usb vs. ehci).
Ok, I'll figure out something better.
};
};
Otherwise looks good.
Thanks for reviewing!
BR,
Georgi
--
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/lkml/
Re: [PATCH 4/4] watchdog: st_wdt: Add new driver for ST's LPC Watchdog
On Thu, Sep 04, 2014 at 03:39:52PM +0100, Lee Jones wrote:
Some text may be useful here.
> Signed-off-by: David Paris
> Signed-off-by: Lee Jones
> ---
> drivers/watchdog/Kconfig | 16 +++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/st_wdt.c | 314
> ++
> 3 files changed, 331 insertions(+)
> create mode 100644 drivers/watchdog/st_wdt.c
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index f57312f..c8abf57 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -432,6 +432,22 @@ config SIRFSOC_WATCHDOG
> Support for CSR SiRFprimaII and SiRFatlasVI watchdog. When
> the watchdog triggers the system will be reset.
>
> +config ST_WATCHDOG
> + tristate "STMicroelectronics LPC Watchdog"
> + depends on ARCH_STI && OF
> + depends on !RTC_DRV_ST_LPC
> + select WATCHDOG_CORE
> + help
> + Say Y here to include Watchdog timer support for the watchdog
> + existing in the LPC of STMicroelectronics SOCs.
> + !!! BE CARREFUL !!!
> + This driver shares hardware resources with RTC Alarm part of the
> + LPC. Both LPC Watchdog driver and LPC RTC driver cannot be
> + used together.
> +
Is this mandatory or an implementation choice ?
Or, in other words, could the resources be shared among drivers ?
> + To compile this driver as a module, choose M here: the
> + module will be called st-wdt.
> +
> config TEGRA_WATCHDOG
> tristate "Tegra watchdog"
> depends on ARCH_TEGRA || COMPILE_TEST
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 468c320..eb19937 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
> obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
> obj-$(CONFIG_MOXART_WDT) += moxart_wdt.o
> obj-$(CONFIG_SIRFSOC_WATCHDOG) += sirfsoc_wdt.o
> +obj-$(CONFIG_ST_WATCHDOG) += st_wdt.o
> obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o
> obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
>
> diff --git a/drivers/watchdog/st_wdt.c b/drivers/watchdog/st_wdt.c
> new file mode 100644
> index 000..b5dbc7d
> --- /dev/null
> +++ b/drivers/watchdog/st_wdt.c
> @@ -0,0 +1,314 @@
> +/*
> + * st-wdt.c -- ST's LPC Watchdog
> + *
> + * Copyright (C) 2014 STMicroelectronics -- All Rights Reserved
> + *
> + * Author: David Paris for STMicroelectronics
> + * Contributor: Lee Jones for STMicroelectronics
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
MODULE_LICENSE says GPL v2 explicitly. No idea if that is relevant, though.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Low Power Alarm */
> +#define LPC_LPA_LSB_OFF 0x410
> +#define LPC_LPA_START_OFF0x418
> +
> +/* LPC as WDT */
> +#define LPC_WDT_OFF 0x510
> +
> +#define WATCHDOG_MIN 1
> +#define WATCHDOG_MAX32 4294967 /* 32bit resolution */
Nitpick, but the '32' is really unnecessary here since you don't
have a separate define for a different resolution.
> +
> +#define WDT_ENABLE 1
> +#define WDT_DISABLE 0
> +
> +struct st_wdog_syscfg {
> + struct regmap *regmap;
> + unsigned int type_reg;
> + unsigned int type_mask;
> + unsigned int enable_reg;
> + unsigned int enable_mask;
Wondering ... why do you have regmap, type_reg, and enable_reg here
and not in the st_wdog structure ?
Logically all values in this structure could (should) be const,
and it doesn't really make sense to allocate static memory for it.
I can see the argument of having 'nice' looking code and retrieve,
say, enable_reg and enable_mask from the same structure, but that
doesn't really make much sense from a practical perspective.
If you want that you could as well copy type_mask and enable_mask
into st_wdog.
> +};
> +
> +struct st_wdog {
> + void __iomem *base;
> + struct st_wdog_syscfg *syscfg;
> + struct clk *clk;
> + int warm_reset;
unsigned int ? Also see below.
> +};
> +
> +static struct st_wdog_syscfg stid127_syscfg = {
> + .type_mask = BIT(2),
> + .enable_mask= BIT(2),
> +};
> +
> +static struct st_wdog_syscfg stih415_syscfg = {
> + .type_mask = BIT(6),
> + .enable_mask= BIT(7),
> +};
> +
> +static struct st_wdog_syscfg stih416_syscfg = {
> + .type_mask = BIT(6),
> + .enable_mask= BIT(7),
> +};
> +
> +static struct st_wdog_syscfg stih407_syscfg = {
> + .enable_mask= BIT(19),
> +};
> +
> +static struct of_device_id st_wdog_match[] = {
> + {
> +
Re: [PATCH v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Fri, Sep 05, 2014 at 10:47:01AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 05, 2014 at 04:36:30PM +0100, Peter Griffin wrote:
> > +static int st_dwc3_remove_child(struct device *dev, void *c)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > +
> > + of_device_unregister(pdev);
> > +
> > + return 0;
> > +}
> > +
> > +static int st_dwc3_remove(struct platform_device *pdev)
> > +{
> > + struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
> > +
> > + device_for_each_child(>dev, NULL, st_dwc3_remove_child);
>
> same as before, of_platform_depopulate(). I can fix this one myself this
> time.
it's in my testign/next branch, please make sure it looks alright.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR
On Fri, 2014-09-05 at 08:41 -0700, H. Peter Anvin wrote: > On 09/05/2014 08:22 AM, Toshi Kani wrote: > > On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote: > >> On 09/05/2014 07:00 AM, Toshi Kani wrote: > >>> > >>> That's a fine idea, but as Ingo also suggested, I am going to disable > >>> this feature on all Pentium 4 models. That should give us a safety > >>> margin. Using slot 4 has a benefit that it keeps the PAT setup > >>> consistent with Xen. > >>> > >> > >> Slot 4 is also the maximally problematic one, because it is the one that > >> might be incorrectly invoked for the page tables themselves. > > > > Good point. I wonder if Xen folks feel strongly about keeping the PAT > > setup consistent with the kernel. If not, we may choose to use slot 6 > > (or 7). > > > > Who cares what the Xen folks "feel strongly about"? If strong feelings > were a design criterion Xen support would have been pulled from the > kernel a long, long time ago. > > The important thing is how to design for the situation that we currently > have to live with. I see. Then, I am going to use slot 7 for WT as suggested by Andy. I think it is the safest slot as slot 3 is UC and is not currently used. Thanks, -Toshi -- 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/lkml/
Re: read()/readv() only from page cache
On Fri, Sep 05, 2014 at 12:09:27PM +0100, Mel Gorman wrote:
> I suggest you look at the recent fincore debate. It did not progress much
> the last time because the author wanted to push a lot of functionality in
> there where as reviewers felt it should start simple. The simple case is
> likely a good fit for what you want. The primary downside is that it would
> be race-prone in memory pressure situations as the page could be reclaimed
> between the fincore check and the read but I expect that your application
> is already avoiding reclaim activity.
I've actually experimentally hacked up O_NONBLOCK support for regular
files so that it only returns data from the page cache, and not
otherwise. Volker promised to test it with Samba, but we never made
any progress on it, and just last week a customer told me they would
have liked to use it if it was available.
Note that we might want to also avoid blocking on locks, and I have some
vague memory that we shouldn't actually implement O_NONBLOCK on regular
files due to compatibility options but would have to use a new flag
instead.
Note that mincor/fincore would not help for the usual use case where you
have a non blocking event main loop and want to offload actual blocking
I/O to helper threads, as you it returns information that can be stale
any time.
One further consideration would be to finally implement real buffered
I/O in kernel space by something like the above and offloading to
workqueues in kernelspace. I think our workqueues now are way better
than any possible user thread pool, although we'd need to find a way to
temporarily tie the work threads to a user address space.
Index: xfs/include/linux/mm.h
===
--- xfs.orig/include/linux/mm.h 2012-09-21 17:50:32.243490371 +0200
+++ xfs/include/linux/mm.h 2012-09-21 17:50:43.333490305 +0200
@@ -1467,6 +1467,12 @@ void page_cache_async_readahead(struct a
pgoff_t offset,
unsigned long size);
+void page_cache_nonblock_readahead(struct address_space *mapping,
+ struct file_ra_state *ra,
+ struct file *filp,
+ pgoff_t offset,
+ unsigned long size);
+
unsigned long max_sane_readahead(unsigned long nr);
unsigned long ra_submit(struct file_ra_state *ra,
struct address_space *mapping,
Index: xfs/mm/filemap.c
===
--- xfs.orig/mm/filemap.c 2012-09-21 17:50:32.243490371 +0200
+++ xfs/mm/filemap.c2012-09-21 18:35:53.343474115 +0200
@@ -1107,6 +1107,9 @@ static void do_generic_file_read(struct
find_page:
page = find_get_page(mapping, index);
if (!page) {
+ if (filp && filp->f_flags & O_NONBLOCK)
+ goto short_read;
+
page_cache_sync_readahead(mapping,
ra, filp,
index, last_index - index);
@@ -1218,6 +1221,12 @@ page_not_up_to_date_locked:
}
readpage:
+ if (filp && filp->f_flags & O_NONBLOCK) {
+ unlock_page(page);
+ page_cache_release(page);
+ goto short_read;
+ }
+
/*
* A previous I/O error may have been due to temporary
* failures, eg. multipath errors.
@@ -1293,6 +1302,10 @@ out:
*ppos = ((loff_t)index << PAGE_CACHE_SHIFT) + offset;
file_accessed(filp);
+ return;
+short_read:
+ page_cache_nonblock_readahead(mapping, ra, filp, index,
+ last_index - index);
}
int file_read_actor(read_descriptor_t *desc, struct page *page,
@@ -1466,7 +1479,8 @@ generic_file_aio_read(struct kiocb *iocb
do_generic_file_read(filp, ppos, , file_read_actor);
retval += desc.written;
if (desc.error) {
- retval = retval ?: desc.error;
+ if (!retval)
+ retval = desc.error;
break;
}
if (desc.count > 0)
Index: xfs/mm/readahead.c
===
--- xfs.orig/mm/readahead.c 2012-09-21 17:50:32.243490371 +0200
+++ xfs/mm/readahead.c 2012-09-21 17:50:43.336823641 +0200
@@ -565,6 +565,22 @@ page_cache_async_readahead(struct addres
}
EXPORT_SYMBOL_GPL(page_cache_async_readahead);
+void
+page_cache_nonblock_readahead(struct address_space *mapping,
+ struct file_ra_state *ra, struct file *filp,
+ pgoff_t offset, unsigned long req_size)
+{
+ /*
+* Defer asynchronous read-ahead on IO congestion.
Re: [PATCH] clk-rcar-gen2: RCAN clock support
On 09/05/2014 01:17 PM, Geert Uytterhoeven wrote:
Add RCAN clock support to the R-Car generation 2 CPG driver. This clock
gets
derived from the USB_EXTAL clock by dividing it by 6. The layout of
RCANCKCR
register is close to those of the clocks supported by the 'clk-div6'
driver
but has no divider field, and so can't be supported by that driver...
I'm not a clock expert (pulling in Laurent), but it looks fine to me.
While you did add the rcan clock to the dtsi in "[PATCH v3 1/3] ARM:
shmobile: r8a7791: add CAN clocks", I couldn't find a patch to update
the renesas,rcar-gen2-cpg-clocks binding doc?
Thanks, I didn't know I need to update the bindings as well...
Gr{oetje,eeting}s,
Geert
WBR, Sergei
--
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/lkml/
Re: [PATCH v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi,
On Fri, Sep 05, 2014 at 04:36:30PM +0100, Peter Griffin wrote:
> +static int st_dwc3_remove_child(struct device *dev, void *c)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> +
> + of_device_unregister(pdev);
> +
> + return 0;
> +}
> +
> +static int st_dwc3_remove(struct platform_device *pdev)
> +{
> + struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
> +
> + device_for_each_child(>dev, NULL, st_dwc3_remove_child);
same as before, of_platform_depopulate(). I can fix this one myself this
time.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] perf tools: Fix build-id matching on vmlinux
Em Sat, Sep 06, 2014 at 12:16:40AM +0900, Namhyung Kim escreveu: > Hi Adrian and Arnaldo, > > 2014-09-05 (금), 11:11 -0300, Arnaldo Carvalho de Melo: > > Em Fri, Sep 05, 2014 at 10:22:40AM +0300, Adrian Hunter escreveu: > > > On 09/05/2014 07:59 AM, Namhyung Kim wrote: > > > > +++ b/tools/perf/util/machine.c > > > > @@ -1060,10 +1060,14 @@ static int > > > > machine__process_kernel_mmap_event(struct machine *machine, > > > > strlen(kmmap_prefix)); > > > > /* > > > > * Should be there already, from the build-id table in > > > > -* the header. > > > > +* the header (but maybe with a different name: > > > > "vmlinux"). > > > > */ > > > > - struct dso *kernel = > > > > __dsos__findnew(>kernel_dsos, > > > > -kmmap_prefix); > > > > + struct dso *kernel = dsos__find(>kernel_dsos, > > > > + "vmlinux", true); > > > > > Isn't "vmlinux" just the basename of the original file name, so if it had > > > a > > > different name this wouldn't work e.g. if the filename had been > > > /boot/vmlinuz-3.11.0-26-generic then you would need > > > "vmlinuz-3.11.0-26-generic" for this to work? > > > > Yeah, looking for well known pathnames to then check if the build-id > > matches the one we're looking for, be it because we obtained it from > > /sys/kernel/notes (for the running kernel), or from the perf.data file > > build-id table is ok, as we don't know where it is. > > > > Plain sticking "vmlinux" there is not. > > I don't get it. AFAIK when perf record runs, it uses [kernel.kallsyms] > name for kernel map. But it can be changed only if it found a "vmlinux" > file in the vmlinux_path[]. So short name will always be "vmlinux" - > okay, it might be vmlinux-$(uname -r) too; I can add it. > > As you know, the vmlinux file is a ELF image that created during kernel > build process so I guess its name is fixed. It's different from the > vmlinu"z" which resides in /boot directory. > > Am I missing something? [acme@zoo linux]$ perf report --help 2>&1 | grep vmlin -k, --vmlinux= vmlinux pathname [acme@zoo linux]$ Yes, it is using [kernel.kallsyms].ref_reloc_sym for the synthesized KERNEL mmap event, but it stores the full path in the build-id table. It seems we need a way to state that an entry in the build-id table is for the kernel, without looking at its file name. That or to put the build-id into the synthesized kernel mmap event. Which is better, because: That leads to another problem that needs to get solved eventually: We need to have the build-id into PERF_RECORD_MMAP, because we're now using just the mmap filename as the key, not the contents, and for long running sessions, DSOs can get updated, etc. - Arnaldo -- 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/lkml/
Re: [PATCH] ARM: MVEBU: Netgear RN102: Use Hardware BCH ECC
(Fixing Cc list: dropping devicetree guys, and adding Brian and MTD instead) On 05 Sep 04:23 PM, klightsp...@killerwolves.net wrote: > The bootloader on the Netgear ReadyNAS RN102 uses Hardware BCH ECC > (strength = 4), while the pxa3xx NAND driver by default uses > Hamming ECC (strength = 1). > Hm, I guess the device (Hynix H27U1G8F2BTR) does not support ONFI, and the kernel is just taking the legacy ECC. The flash specs makes no mention to ONFI, so probably no ONFI here. > This patch changes the ECC mode on these machines to match that > of the bootloader and of the stock firmware, so that for example > updating the kernel is possible without requiring a serial > connection. > > This patch depends on commit 5b3e507 (mtd: nand: pxa3xx: Use ECC > strength and step size devicetree binding) > > Signed-off-by: Ben Peddell Looks good to me, since Arnaud reports this is the correct ECC scheme: http://natisbad.org/NAS2/index.html#hw-nand Acked-by: Ezequiel Garcia Thanks for the fix, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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/lkml/
Re: bit fields && data tearing
On 09/05/2014 08:31 AM, Peter Hurley wrote: > > Which is a bit ironic because I remember when Digital had a team > working on emulating native x86 apps on Alpha/NT. > Right, because the x86 architecture was obsolete and would never scale... -hpa -- 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/lkml/
Re: [GIT PULL] bcache changes for 3.17
On 05/09/14 15:17, Jens Axboe wrote: (from oldest to newest). And that's just from 3.16 to 3.17-rc3, going all the way back to 3.10 would be a lot of work. If there's anyone that cares about bcache on stable kernels (and actually use it), now would be a good time to pipe up. Just "piping up" as I care about bcache and actually use it in production on 3.10! Shame I don't have the knowledge to try and backport these though :-) Eddie -- 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/lkml/
Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR
On 09/05/2014 08:22 AM, Toshi Kani wrote: > On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote: >> On 09/05/2014 07:00 AM, Toshi Kani wrote: >>> >>> That's a fine idea, but as Ingo also suggested, I am going to disable >>> this feature on all Pentium 4 models. That should give us a safety >>> margin. Using slot 4 has a benefit that it keeps the PAT setup >>> consistent with Xen. >>> >> >> Slot 4 is also the maximally problematic one, because it is the one that >> might be incorrectly invoked for the page tables themselves. > > Good point. I wonder if Xen folks feel strongly about keeping the PAT > setup consistent with the kernel. If not, we may choose to use slot 6 > (or 7). > Who cares what the Xen folks "feel strongly about"? If strong feelings were a design criterion Xen support would have been pulled from the kernel a long, long time ago. The important thing is how to design for the situation that we currently have to live with. -hpa -- 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/lkml/
Re: Possible race between CPU hotplug and perf_pmu_migrate_context
On Fri, Sep 5, 2014 at 8:16 AM, Peter Zijlstra wrote: > > How horrible is the below patch (performance wise). It does pretty much > the same thing except that percpu_rw_semaphore is a lot saner, its > read side performance should be minimal in the absence of writes. Ugh. Why do any locking at all (whether a new 'perf_rwsem' or using 'get_online_cpus()'). Wouldn't it be much nicer to just do what memory management routines are *supposed* to do, and get a reference count to the context while having a pointer to it? IOW, why doesn't put_event() just have a get_ctx(ctx); .. put_ctx(ctx); around its use of the context pointer? So if the context ends up being migrated during this time, it doesn't get freed. However, the more fundamental question is "what protects accesses to 'events->ctx'". Why is "put_event()" so special that *it* gets locking for the reading of "event->ctx", but none of the other cases of reading the ctx pointer gets it or needs it? I'm getting the feeling that this race is bigger than just put_event(). Linus -- 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/lkml/
Re: [PATCHv2 1/4] Clocksource: Flextimer: Use internal clocksource read API.
On Fri, 5 Sep 2014, Xiubo Li wrote: > Since the Flextimer device will be implemented in BE mode on > LS1 SoC, and in LE mode on Vybrid, LS2 SoCs, so here we need > the endianness judgment before doing the mmio. WTF? I explained you in great length HOW you should solve that, but you just ignore it. Instead of trying to understand what I say you just resend the same nonsense again. Keep that attitude up, if you want to make sure, that your patches are ignored in the future. Thanks, tglx -- 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/lkml/
Re: [PATCH] pseries: Make CPU hotplug path endian safe
On Fri, Sep 5, 2014 at 7:38 PM, Nathan Fontenot
wrote:
> On 09/05/2014 04:16 AM, bharata@gmail.com wrote:
>> From: Bharata B Rao
>>
>> - ibm,rtas-configure-connector should treat the RTAS data as big endian.
>> - Treat ibm,ppc-interrupt-server#s as big-endian when setting
>> smp_processor_id during hotplug.
>>
>> Signed-off-by: Bharata B Rao
>> ---
>> arch/powerpc/platforms/pseries/dlpar.c | 10 +-
>> arch/powerpc/platforms/pseries/hotplug-cpu.c | 4 ++--
>> 2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/dlpar.c
>> b/arch/powerpc/platforms/pseries/dlpar.c
>> index 2d0b4d6..dc55f9c 100644
>> --- a/arch/powerpc/platforms/pseries/dlpar.c
>> +++ b/arch/powerpc/platforms/pseries/dlpar.c
>> @@ -48,11 +48,11 @@ static struct property *dlpar_parse_cc_property(struct
>> cc_workarea *ccwa)
>> if (!prop)
>> return NULL;
>>
>> - name = (char *)ccwa + ccwa->name_offset;
>> + name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
>> prop->name = kstrdup(name, GFP_KERNEL);
>>
>> - prop->length = ccwa->prop_length;
>> - value = (char *)ccwa + ccwa->prop_offset;
>> + prop->length = be32_to_cpu(ccwa->prop_length);
>> + value = (char *)ccwa + be32_to_cpu(ccwa->prop_offset);
>> prop->value = kmemdup(value, prop->length, GFP_KERNEL);
>> if (!prop->value) {
>> dlpar_free_cc_property(prop);
>> @@ -78,7 +78,7 @@ static struct device_node *dlpar_parse_cc_node(struct
>> cc_workarea *ccwa,
>> if (!dn)
>> return NULL;
>>
>> - name = (char *)ccwa + ccwa->name_offset;
>> + name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
>> dn->full_name = kasprintf(GFP_KERNEL, "%s/%s", path, name);
>> if (!dn->full_name) {
>> kfree(dn);
>> @@ -148,7 +148,7 @@ struct device_node *dlpar_configure_connector(u32
>> drc_index,
>> return NULL;
>>
>> ccwa = (struct cc_workarea *)_buf[0];
>> - ccwa->drc_index = drc_index;
>> + ccwa->drc_index = cpu_to_be32(drc_index);
>
> I need to look at this some more but I think this may cause an issue for
> partition migration. If I am following the code correctly, starting in
> pseries_devicetree_update(), the drc_index value passed to
> dlpar_configure_connector is pulled directly out of a buffer we get from
> firmware. This would mean the drc_index value is already in BE format.
Yes I see that now.
>
> Whereas for cpu hotplug the drc_index value is passed in from userspace
> via the cpu probe interface in sysfs. I assume that you are seeing the
> drc_index value getting passed in in LE format.
Yes I am seeing drc_index in LE format for an LE guest during CPU
hotplug operation.
Regards,
Bharata.
--
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/lkml/
Re: [PATCH v3 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver
On Fri, Sep 05, 2014 at 06:17:59PM +0300, Octavian Purdila wrote:
> +static int dln2_do_remove(struct dln2_gpio *dln2)
> +{
> + /* When removing the DLN2 USB device, gpiochip_remove may fail
> + * due to i2c drivers holding a GPIO pin. However, the i2c bus
> + * will eventually be removed triggering an i2c driver remove
> + * which will release the GPIO pin. So retrying the operation
> + * later should succeed. */
> + int ret = gpiochip_remove(>gpio);
> + struct device *dev = dln2->gpio.dev;
> +
> + if (ret < 0) {
> + if (ret == -EBUSY)
> + schedule_delayed_work(>remove_work.work, HZ/10);
> + else
> + dev_warn(dev, "error removing gpio chip: %d\n", ret);
> + } else {
> + kfree(dln2);
> + }
> +
> + return ret;
> +}
Apparently, the return value from gpiochip_remove is going away:
"Start to kill off the return value from gpiochip_remove() by
removing the __must_check attribute and removing all checks
inside the drivers/gpio directory. The rationale is: well what
were we supposed to do if there is an error code? Not much:
print an error message. And gpiolib already does that. So make
this function return void eventually."
https://www.mail-archive.com/linux-gpio@vger.kernel.org/msg03468.html
Also, have you considered what happens if there are gpios exported
through sysfs? These may never be released.
In general, how well have these patches been tested with disconnect
events? At least gpiolib is known to blow up (sooner or later) when a
gpiochip is removed when having requested gpios.
Johan
--
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/lkml/
Re: regression caused by cgroups optimization in 3.17-rc2
On Fri 05-09-14 10:47:23, Johannes Weiner wrote:
> On Fri, Sep 05, 2014 at 11:25:37AM +0200, Michal Hocko wrote:
> > @@ -900,10 +900,10 @@ void lru_add_drain_all(void)
> > * grabbed the page via the LRU. If it did, give up:
> > shrink_inactive_list()
> > * will free it.
> > */
> > -void release_pages(struct page **pages, int nr, bool cold)
> > +static void release_lru_pages(struct page **pages, int nr,
> > + struct list_head *pages_to_free)
> > {
> > int i;
> > - LIST_HEAD(pages_to_free);
> > struct zone *zone = NULL;
> > struct lruvec *lruvec;
> > unsigned long uninitialized_var(flags);
> > @@ -943,11 +943,26 @@ void release_pages(struct page **pages, int nr, bool
> > cold)
> > /* Clear Active bit in case of parallel mark_page_accessed */
> > __ClearPageActive(page);
> >
> > - list_add(>lru, _to_free);
> > + list_add(>lru, pages_to_free);
> > }
> > if (zone)
> > spin_unlock_irqrestore(>lru_lock, flags);
> > +}
> > +/*
> > + * Batched page_cache_release(). Frees and uncharges all given pages
> > + * for which the reference count drops to 0.
> > + */
> > +void release_pages(struct page **pages, int nr, bool cold)
> > +{
> > + LIST_HEAD(pages_to_free);
> >
> > + while (nr) {
> > + int batch = min(nr, PAGEVEC_SIZE);
> > +
> > + release_lru_pages(pages, batch, _to_free);
> > + pages += batch;
> > + nr -= batch;
> > + }
>
> We might be able to process a lot more pages in one go if nobody else
> needs the lock or the CPU. Can't we just cycle the lock or reschedule
> if necessary?
Is it safe to cond_resched here for all callers? I hope it is but there
are way too many callers to check so I am not 100% sure.
Besides that spin_needbreak doesn't seem to be available for all architectures.
git grep "arch_spin_is_contended(" -- arch/
arch/arm/include/asm/spinlock.h:static inline int
arch_spin_is_contended(arch_spinlock_t *lock)
arch/arm64/include/asm/spinlock.h:static inline int
arch_spin_is_contended(arch_spinlock_t *lock)
arch/ia64/include/asm/spinlock.h:static inline int
arch_spin_is_contended(arch_spinlock_t *lock)
arch/mips/include/asm/spinlock.h:static inline int
arch_spin_is_contended(arch_spinlock_t *lock)
arch/x86/include/asm/spinlock.h:static inline int
arch_spin_is_contended(arch_spinlock_t *lock)
Moreover it doesn't seem to do anything for !CONFIG_PREEMPT but this
should be trivial to fix.
I am also not sure this will work well in all cases. If we have a heavy
reclaim activity on other CPUs then this path might be interrupted too
often resulting in too much lock bouncing. So I guess we want at least
few pages to be processed in one run. On the other hand if the lock is
not contended then doing batches and retake the lock shouldn't add too
much overhead, no?
> diff --git a/mm/swap.c b/mm/swap.c
> index 6b2dc3897cd5..ee0cf21dd521 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -944,6 +944,15 @@ void release_pages(struct page **pages, int nr, bool
> cold)
> __ClearPageActive(page);
>
> list_add(>lru, _to_free);
> +
> + if (should_resched() ||
> + (zone && spin_needbreak(>lru_lock))) {
> + if (zone) {
> + spin_unlock_irqrestore(>lru_lock, flags);
> + zone = NULL;
> + }
> + cond_resched();
> + }
> }
> if (zone)
> spin_unlock_irqrestore(>lru_lock, flags);
> diff --git a/mm/swap_state.c b/mm/swap_state.c
> index 3e0ec83d000c..c487ca4682a4 100644
> --- a/mm/swap_state.c
> +++ b/mm/swap_state.c
> @@ -262,19 +262,12 @@ void free_page_and_swap_cache(struct page *page)
> */
> void free_pages_and_swap_cache(struct page **pages, int nr)
> {
> - struct page **pagep = pages;
> + int i;
>
> lru_add_drain();
> - while (nr) {
> - int todo = min(nr, PAGEVEC_SIZE);
> - int i;
> -
> - for (i = 0; i < todo; i++)
> - free_swap_cache(pagep[i]);
> - release_pages(pagep, todo, false);
> - pagep += todo;
> - nr -= todo;
> - }
> + for (i = 0; i < nr; i++)
> + free_swap_cache(pages[i]);
> + release_pages(pages, nr, false);
> }
>
> /*
--
Michal Hocko
SUSE Labs
--
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/lkml/
[PATCH v6 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
This patch documents the device tree documentation required for
the ST usb3 controller glue layer found in STiH407 devices.
Signed-off-by: Giuseppe Cavallaro
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
Documentation/devicetree/bindings/usb/dwc3-st.txt | 68 +++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
b/Documentation/devicetree/bindings/usb/dwc3-st.txt
new file mode 100644
index 000..f9d7025
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
@@ -0,0 +1,68 @@
+ST DWC3 glue logic
+
+This file documents the parameters for the dwc3-st driver.
+This driver controls the glue logic used to configure the dwc3 core on
+STiH407 based platforms.
+
+Required properties:
+ - compatible : must be "st,stih407-dwc3"
+ - reg : glue logic base address and USB syscfg ctrl register offset
+ - reg-names : should be "reg-glue" and "syscfg-reg"
+ - st,syscon : should be phandle to system configuration node which
+ encompasses the glue registers
+ - resets : list of phandle and reset specifier pairs. There should be
two entries, one
+ for the powerdown and softreset lines of the usb3 IP
+ - reset-names : list of reset signal names. Names should be "powerdown" and
"softreset"
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property
+
+ - pinctl-names: A pinctrl state named "default" must be defined
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - pinctrl-0 : Pin control group
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - ranges : allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Sub-nodes:
+The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
+example below. The DT binding details of dwc3 can be found in:
+Documentation/devicetree/bindings/usb/dwc3.txt
+
+NB: The dr_mode property described in [1] is NOT optional for this driver, as
the default value
+is "otg", which isn't supported by this SoC. Valid dr_mode values for dwc3-st
are either "host"
+or "device".
+
+[1] Documentation/devicetree/bindings/usb/generic.txt
+
+Example:
+
+st_dwc3: dwc3@8f94000 {
+ status = "disabled";
+ compatible = "st,stih407-dwc3";
+ reg = <0x08f94000 0x1000>, <0x110 0x4>;
+ reg-names = "reg-glue", "syscfg-reg";
+ st,syscfg = <_core>;
+ resets = < STIH407_USB3_POWERDOWN>,
+ < STIH407_MIPHY2_SOFTRESET>;
+ reset-names = "powerdown",
+ "softreset";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_usb3>;
+ ranges;
+
+ dwc3: dwc3@990 {
+ compatible = "snps,dwc3";
+ reg = <0x0990 0x10>;
+ interrupts = ;
+ dr_mode = "host";
+ phys-names = "usb2-phy", "usb3-phy";
+ phys= <_picophy2>, <_port2 MIPHY_TYPE_USB>;
+ };
+};
--
1.9.1
--
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/lkml/
[PATCH v6 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
This patch adds the new dwc3-st.c glue driver found on STMicroelectronics stih407 consumer electronics SoC's into the STI arch section of the maintainers file. Signed-off-by: Peter Griffin Acked-by: Lee Jones --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index cf24bb5..55381955 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1398,6 +1398,7 @@ F:drivers/media/rc/st_rc.c F: drivers/i2c/busses/i2c-st.c F: drivers/tty/serial/st-asc.c F: drivers/mmc/host/sdhci-st.c +F: drivers/usb/dwc3/dwc3-st.c ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT M: Lennert Buytenhek -- 1.9.1 -- 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/lkml/
[PATCH v6 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
This patch adds the ST glue logic to manage the DWC3 HC
on STiH407 SoC family. It manages the powerdown signal,
and configures the internal glue logic and syscfg registers.
Signed-off-by: Giuseppe Cavallaro
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
drivers/usb/dwc3/Kconfig | 9 ++
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-st.c | 377 +
3 files changed, 387 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-st.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 785510a..5238251 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -80,6 +80,15 @@ config USB_DWC3_KEYSTONE
Support of USB2/3 functionality in TI Keystone2 platforms.
Say 'Y' or 'M' here if you have one such device
+config USB_DWC3_ST
+ tristate "STMicroelectronics Platforms"
+ depends on ARCH_STI && OF
+ default USB_DWC3
+ help
+ STMicroelectronics SoCs with one DesignWare Core USB3 IP
+ inside (i.e. STiH407).
+ Say 'Y' or 'M' if you have one such device.
+
comment "Debugging features"
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 10ac3e7..11c9f54 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
+obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o
diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
new file mode 100644
index 000..c4c1717
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-st.c
@@ -0,0 +1,377 @@
+/**
+ * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics platforms
+ *
+ * This is a small driver for the dwc3 to provide the glue logic
+ * to configure the controller. Tested on STi platforms.
+ *
+ * Copyright (C) 2014 Stmicroelectronics
+ *
+ * Author: Giuseppe Cavallaro
+ * Contributors: Aymen Bouattay
+ * Peter Griffin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Inspired by dwc3-omap.c and dwc3-exynos.c.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "core.h"
+#include "io.h"
+
+/* glue registers */
+#define CLKRST_CTRL0x00
+#define AUX_CLK_EN BIT(0)
+#define SW_PIPEW_RESET_N BIT(4)
+#define EXT_CFG_RESET_NBIT(8)
+/*
+ * 1'b0 : The host controller complies with the xHCI revision 0.96
+ * 1'b1 : The host controller complies with the xHCI revision 1.0
+ */
+#define XHCI_REVISION BIT(12)
+
+#define USB2_VBUS_MNGMNT_SEL1 0x2C
+/*
+ * For all fields in USB2_VBUS_MNGMNT_SEL1
+ * 2’b00 : Override value from Reg 0x30 is selected
+ * 2’b01 : utmiotg_ from usb3_top is selected
+ * 2’b10 : pipew_ from PIPEW instance is selected
+ * 2’b11 : value is 1'b0
+ */
+#define USB2_VBUS_REG300x0
+#define USB2_VBUS_UTMIOTG 0x1
+#define USB2_VBUS_PIPEW0x2
+#define USB2_VBUS_ZERO 0x3
+
+#define SEL_OVERRIDE_VBUSVALID(n) (n << 0)
+#define SEL_OVERRIDE_POWERPRESENT(n) (n << 4)
+#define SEL_OVERRIDE_BVALID(n) (n << 8)
+
+/* Static DRD configuration */
+#define USB3_CONTROL_MASK 0xf77
+
+#define USB3_DEVICE_NOT_HOST BIT(0)
+#define USB3_FORCE_VBUSVALID BIT(1)
+#define USB3_DELAY_VBUSVALID BIT(2)
+#define USB3_SEL_FORCE_OPMODE BIT(4)
+#define USB3_FORCE_OPMODE(n) (n << 5)
+#define USB3_SEL_FORCE_DPPULLDOWN2 BIT(8)
+#define USB3_FORCE_DPPULLDOWN2 BIT(9)
+#define USB3_SEL_FORCE_DMPULLDOWN2 BIT(10)
+#define USB3_FORCE_DMPULLDOWN2 BIT(11)
+
+/**
+ * struct st_dwc3 - dwc3-st driver private structure
+ * @dev: device pointer
+ * @glue_base: ioaddr for the glue registers
+ * @regmap:regmap pointer for getting syscfg
+ * @syscfg_reg_off:usb syscfg control offset
+ * @dr_mode: drd static host/device config
+ * @rstc_pwrdn:rest controller for powerdown signal
+ * @rstc_rst: reset controller for softreset signal
+ */
+
+struct st_dwc3 {
+ struct device *dev;
+ void __iomem *glue_base;
+ struct regmap *regmap;
+ int syscfg_reg_off;
+ enum usb_dr_mode dr_mode;
+ struct reset_control *rstc_pwrdn;
+ struct reset_control *rstc_rst;
+};
+
+static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
+{
+ return readl_relaxed(base + offset);
+}
+
+static
[PATCH v6 0/3] Add ST dwc3 glue layer driver
This series adds support for the ST glue logic which wraps the DWC3 controller on STiH407 SoC family chipsets. Changes since v5 - Use of_platform_depopulate Changes since v4 - Fix bug with setting bits in usb control register - Remove superflous '\n' - Change default Kconfig to make default same as other platforms - Update dt doc example so that both usb2 and usb3 phys are using generic drivers/phy instead of drivers/usb/phy - Reconfigure ST glue logic regs in resume callback Changes since v3 - Various formating nits Changes since v2 - Use dr_mode for host/device static configuration - Manage shared reset signal to usbss to avoid hang if probing before usb3 phy - Remove DT checks and make driver depend on OF - Change some #define to use BIT macro - Make some comments clearer - Use kerneldoc for struct documentation - Remove udelay - Let DT create platform_devices, and remove legacy alloc - Change some logging levels to dev_dbg - Various whitespace and formatting cleanup - Use SIMPLE_DEV_PM_OPS() - Add const to of_device struct - Reorder header files alphabetically - Use devm_ioremap_resource instead of devm_request_and_ioremap - Remove of_match_ptr() Changes since v1 - Fix Kconfig mistake Peter Griffin (3): usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture Documentation/devicetree/bindings/usb/dwc3-st.txt | 68 MAINTAINERS | 1 + drivers/usb/dwc3/Kconfig | 9 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-st.c| 377 ++ 5 files changed, 456 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt create mode 100644 drivers/usb/dwc3/dwc3-st.c -- 1.9.1 -- 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/lkml/
[PATCH v2 3/5] arm: fiq: Replace default FIQ handler
This patch introduces a new default FIQ handler that is structured in a
similar way to the existing ARM exception handler and result in the FIQ
being handled by C code running on the SVC stack (despite this code run
in the FIQ handler is subject to severe limitations with respect to
locking making normal interaction with the kernel impossible).
This default handler allows concepts that on x86 would be handled using
NMIs to be realized on ARM.
Credit:
This patch is a near complete re-write of a patch originally
provided by Anton Vorontsov. Today only a couple of small fragments
survive, however without Anton's work to build from this patch would
not exist.
Signed-off-by: Daniel Thompson
Cc: Russell King
Cc: Nicolas Pitre
Cc: Catalin Marinas
---
arch/arm/include/asm/smp.h | 3 +
arch/arm/kernel/entry-armv.S | 137 +++
arch/arm/kernel/setup.c | 8 ++-
arch/arm/kernel/smp.c| 4 +-
arch/arm/kernel/traps.c | 28 +
5 files changed, 168 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index 2ec765c..0580270 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -18,6 +18,8 @@
# error " included in non-SMP build"
#endif
+#define SMP_IPI_FIQ_MASK 0x0100
+
#define raw_smp_processor_id() (current_thread_info()->cpu)
struct seq_file;
@@ -85,6 +87,7 @@ extern void arch_send_call_function_single_ipi(int cpu);
extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
extern void arch_send_wakeup_ipi_mask(const struct cpumask *mask);
+extern void ipi_cpu_backtrace(struct pt_regs *regs);
extern int register_ipi_completion(struct completion *completion, int cpu);
struct smp_operations {
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 36276cd..eb37aa5 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -146,7 +146,7 @@ ENDPROC(__und_invalid)
#define SPFIX(code...)
#endif
- .macro svc_entry, stack_hole=0
+ .macro svc_entry, stack_hole=0, call_trace=1
UNWIND(.fnstart )
UNWIND(.save {r0 - pc})
sub sp, sp, #(S_FRAME_SIZE + \stack_hole - 4)
@@ -183,7 +183,51 @@ ENDPROC(__und_invalid)
stmia r7, {r2 - r6}
#ifdef CONFIG_TRACE_IRQFLAGS
+ .if \call_trace
bl trace_hardirqs_off
+ .endif
+#endif
+ .endm
+
+@
+@ svc_exit_via_fiq - similar to svc_exit but switches to FIQ mode before exit
+@
+@ This macro acts in a similar manner to svc_exit but switches to FIQ
+@ mode to restore the final part of the register state.
+@
+@ We cannot use the normal svc_exit procedure because that would
+@ clobber spsr_svc (FIQ could be delivered during the first few instructions
+@ of vector_swi meaning its contents have not been saved anywhere).
+@
+@ Note that, unlike svc_exit, this macro also does not allow a caller
+@ supplied rpsr. This is because the FIQ exceptions are not re-entrant
+@ and the handlers cannot call into the scheduler (meaning the value
+@ on the stack remains correct).
+@
+ .macro svc_exit_via_fiq
+
+#ifndef CONFIG_THUMB2_KERNEL
+ mov r0, sp
+ ldmib r0, {r1 - r14} @ abort is deadly from here onward (it will
+ @ clobber state restored below)
+ msr cpsr_c, #FIQ_MODE | PSR_I_BIT | PSR_F_BIT
+ add r8, r0, #S_PC
+ ldr r9, [r0, #S_PSR]
+ msr spsr_cxsf, r9
+ ldr r0, [r0, #S_R0]
+ ldmia r8, {pc}^
+#else
+ add r0, sp, #S_R2
+ ldr lr, [sp, #S_LR]
+ ldr sp, [sp, #S_SP] @ abort is deadly from here onward (it will
+ @ clobber state restored below)
+ ldmia r0, {r2 - r12}
+ mov r1, #FIQ_MODE | PSR_I_BIT | PSR_F_BIT
+ msr cpsr_c, r1
+ sub r0, #S_R2
+ add r8, r0, #S_PC
+ ldmia r0, {r0 - r1}
+ rfeia r8
#endif
.endm
@@ -295,6 +339,15 @@ __pabt_svc:
ENDPROC(__pabt_svc)
.align 5
+__fiq_svc:
+ svc_entry 0, 0
+ mov r0, sp @ struct pt_regs *regs
+ bl handle_fiq_as_nmi
+ svc_exit_via_fiq
+ UNWIND(.fnend )
+ENDPROC(__fiq_svc)
+
+ .align 5
.LCcralign:
.word cr_alignment
#ifdef MULTI_DABORT
@@ -305,6 +358,46 @@ ENDPROC(__pabt_svc)
.word fp_enter
/*
+ * Abort mode handlers
+ */
+
+@
+@ Taking a FIQ in abort mode is similar to taking a FIQ in SVC mode
+@ and reuses the same macros. However in abort mode we must also
+@ save/restore lr_abt and spsr_abt to make nested aborts safe.
+@
+ .align 5
+__fiq_abt:
+ svc_entry 0, 0
+
+ ARM( msr cpsr_c, #ABT_MODE | PSR_I_BIT | PSR_F_BIT )
+ THUMB( movr0, #ABT_MODE | PSR_I_BIT | PSR_F_BIT )
+ THUMB( msrcpsr_c, r0 )
+ mov r1, lr @ Save lr_abt
+ mrs r2, spsr
[PATCH v2 5/5] irqchip: gic: Add support for IPI FIQ
This patch provides support for arm's newly added IPI FIQ. It works
by placing all interrupt sources *except* IPI FIQ in group 1 and
then flips a configuration bit in the GIC such that group 1
interrupts use IRQ and group 0 interrupts use FIQ.
All GIC hardware except GICv1-without-TrustZone support provides a means
to group exceptions into group 0 and group 1. However the hardware
functionality is unavailable to the kernel when a secure monitor is
present because access to the grouping registers are prohibited outside
"secure world" (a feature that allows grouping to be used to allow
hardware peripherals to send interrupts into the secure world). However
when grouping is not available we can rely on the GIC's RAZ/WI semantics
and avoid conditional code.
Tested on Freescale i.MX6 (quad A9, GICv1-with-TrustZone running in
secure mode).
Signed-off-by: Daniel Thompson
Cc: Russell King
Cc: Thomas Gleixner
Cc: Jason Cooper
---
arch/arm/kernel/traps.c | 4 +
drivers/irqchip/irq-gic.c | 165 +---
include/linux/irqchip/arm-gic.h | 3 +
3 files changed, 163 insertions(+), 9 deletions(-)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index f8189c2..40b1de7 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -479,6 +480,9 @@ asmlinkage void __exception_irq_entry
handle_fiq_as_nmi(struct pt_regs *regs)
nmi_enter();
+#ifdef CONFIG_ARM_GIC
+ gic_handle_fiq_ipi();
+#endif
#ifdef CONFIG_SMP
ipi_cpu_backtrace(regs);
#endif
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 4b959e6..f554ee5 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -39,8 +39,10 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -48,6 +50,10 @@
#include "irq-gic-common.h"
#include "irqchip.h"
+#ifndef SMP_IPI_FIQ_MASK
+#define SMP_IPI_FIQ_MASK 0
+#endif
+
union gic_base {
void __iomem *common_base;
void __percpu * __iomem *percpu_base;
@@ -71,6 +77,8 @@ struct gic_chip_data {
};
static DEFINE_RAW_SPINLOCK(irq_controller_lock);
+/* A fiq-safe spinlock must only be locked when the FIQ is masked */
+static DEFINE_RAW_SPINLOCK(fiq_safe_migration_lock);
/*
* The GIC mapping of CPU interfaces does not necessarily match
@@ -325,6 +333,94 @@ static struct irq_chip gic_chip = {
.irq_set_wake = gic_set_wake,
};
+/*
+ * Shift an interrupt between Group 0 and Group 1.
+ *
+ * In addition to changing the group we also modify the priority to
+ * match what "ARM strongly recommends" for a system where no Group 1
+ * interrupt must ever preempt a Group 0 interrupt.
+ *
+ * If is safe to call this function on systems which do not support
+ * grouping (it will have no effect).
+ */
+static void gic_set_group_irq(void __iomem *base, unsigned int hwirq,
+ int group)
+{
+ unsigned int grp_reg = hwirq / 32 * 4;
+ u32 grp_mask = BIT(hwirq % 32);
+ u32 grp_val;
+
+ unsigned int pri_reg = (hwirq / 4) * 4;
+ u32 pri_mask = BIT(7 + ((hwirq % 4) * 8));
+ u32 pri_val;
+
+ /*
+* Systems which do not support grouping will have no bits
+* set in IGROUP[0] (and all systems which do will have set bits).
+*/
+ grp_val = readl_relaxed(base + GIC_DIST_IGROUP + 0);
+ if (!grp_val)
+ return;
+
+ raw_spin_lock(_controller_lock);
+
+ grp_val = readl_relaxed(base + GIC_DIST_IGROUP + grp_reg);
+ pri_val = readl_relaxed(base + GIC_DIST_PRI + pri_reg);
+
+ if (group) {
+ grp_val |= grp_mask;
+ pri_val |= pri_mask;
+ } else {
+ grp_val &= ~grp_mask;
+ pri_val &= ~pri_mask;
+ }
+
+ writel_relaxed(grp_val, base + GIC_DIST_IGROUP + grp_reg);
+ writel_relaxed(pri_val, base + GIC_DIST_PRI + pri_reg);
+
+ raw_spin_unlock(_controller_lock);
+}
+
+/*
+ * Test which group an interrupt belongs to.
+ *
+ * Returns 0 if the controller does not support grouping.
+ */
+static int gic_get_group_irq(void __iomem *base, unsigned int hwirq)
+{
+ unsigned int grp_reg = hwirq / 32 * 4;
+ u32 grp_val;
+
+ grp_val = readl_relaxed(base + GIC_DIST_IGROUP + grp_reg);
+
+ return (grp_val >> (hwirq % 32)) & 1;
+}
+
+/*
+ * Fully acknowledge (both ack and eoi) any outstanding FIQ-based IPI,
+ * otherwise do nothing.
+ */
+void gic_handle_fiq_ipi(void)
+{
+ struct gic_chip_data *gic = _data[0];
+ void __iomem *cpu_base = gic_data_cpu_base(gic);
+ unsigned long irqstat, irqnr;
+
+ if (WARN_ON(!in_nmi()))
+ return;
+
+ while ((1u << readl_relaxed(cpu_base + GIC_CPU_HIGHPRI)) &
+ SMP_IPI_FIQ_MASK) {
+ irqstat = readl_relaxed(cpu_base +
[PATCH v2 4/5] arm64: Introduce dummy version of asm/fiq.h
Drivers that are shared between arm and arm64 and which employ FIQ on arm cannot include asm/fiq.h without #ifdef'ing. This patch introduces a dummy version of asm/fiq.h to arm64 to avoid this. Signed-off-by: Daniel Thompson Cc: Catalin Marinas Cc: Will Deacon --- arch/arm64/include/asm/fiq.h | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 arch/arm64/include/asm/fiq.h diff --git a/arch/arm64/include/asm/fiq.h b/arch/arm64/include/asm/fiq.h new file mode 100644 index 000..909ec54 --- /dev/null +++ b/arch/arm64/include/asm/fiq.h @@ -0,0 +1,18 @@ +/* + * arch/arm64/include/asm/fiq.h + * + * Placeholder to reduce #ifdef'ing in shared arm/arm64 drivers. + */ + +#ifndef __ASM_FIQ_H +#define __ASM_FIQ_H + +/* + * This placeholder allows code of the following form to be simplified: + * + * #ifdef CONFIG_FIQ + * #include + * #endif + */ + +#endif -- 1.9.3 -- 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/lkml/
[PATCH v2 2/5] ARM: add basic support for on-demand backtrace of other CPUs
From: Russell King
Add basic infrastructure for triggering a backtrace of other CPUs
via an IPI, preferably at FIQ level. It is intended that this shall
be used for cases where we have detected that something has already
failed in the kernel.
Signed-off-by: Russell King
---
arch/arm/include/asm/irq.h | 5
arch/arm/kernel/smp.c | 62 ++
2 files changed, 67 insertions(+)
diff --git a/arch/arm/include/asm/irq.h b/arch/arm/include/asm/irq.h
index 53c15de..be1d07d 100644
--- a/arch/arm/include/asm/irq.h
+++ b/arch/arm/include/asm/irq.h
@@ -35,6 +35,11 @@ extern void (*handle_arch_irq)(struct pt_regs *);
extern void set_handle_irq(void (*handle_irq)(struct pt_regs *));
#endif
+#ifdef CONFIG_SMP
+extern void arch_trigger_all_cpu_backtrace(bool);
+#define arch_trigger_all_cpu_backtrace(x) arch_trigger_all_cpu_backtrace(x)
+#endif
+
#endif
#endif
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 9388a3d..94959f9 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -72,8 +72,12 @@ enum ipi_msg_type {
IPI_CPU_STOP,
IPI_IRQ_WORK,
IPI_COMPLETION,
+ IPI_CPU_BACKTRACE,
};
+/* For reliability, we're prepared to waste bits here. */
+static DECLARE_BITMAP(backtrace_mask, NR_CPUS) __read_mostly;
+
static DECLARE_COMPLETION(cpu_running);
static struct smp_operations smp_ops;
@@ -539,6 +543,21 @@ static void ipi_cpu_stop(unsigned int cpu)
cpu_relax();
}
+static void ipi_cpu_backtrace(struct pt_regs *regs)
+{
+ int cpu = smp_processor_id();
+
+ if (cpumask_test_cpu(cpu, to_cpumask(backtrace_mask))) {
+ static arch_spinlock_t lock = __ARCH_SPIN_LOCK_UNLOCKED;
+
+ arch_spin_lock();
+ printk(KERN_WARNING "FIQ backtrace for cpu %d\n", cpu);
+ show_regs(regs);
+ arch_spin_unlock();
+ cpumask_clear_cpu(cpu, to_cpumask(backtrace_mask));
+ }
+}
+
static DEFINE_PER_CPU(struct completion *, cpu_completion);
int register_ipi_completion(struct completion *completion, int cpu)
@@ -618,6 +637,12 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
irq_exit();
break;
+ case IPI_CPU_BACKTRACE:
+ irq_enter();
+ ipi_cpu_backtrace(regs);
+ irq_exit();
+ break;
+
default:
printk(KERN_CRIT "CPU%u: Unknown IPI message 0x%x\n",
cpu, ipinr);
@@ -712,3 +737,40 @@ static int __init register_cpufreq_notifier(void)
core_initcall(register_cpufreq_notifier);
#endif
+
+void arch_trigger_all_cpu_backtrace(bool include_self)
+{
+ static unsigned long backtrace_flag;
+ int i, cpu = get_cpu();
+
+ if (test_and_set_bit(0, _flag)) {
+ /*
+* If there is already a trigger_all_cpu_backtrace() in progress
+* (backtrace_flag == 1), don't output double cpu dump infos.
+*/
+ put_cpu();
+ return;
+ }
+
+ cpumask_copy(to_cpumask(backtrace_mask), cpu_online_mask);
+ if (!include_self)
+ cpumask_clear_cpu(cpu, to_cpumask(backtrace_mask));
+
+ if (!cpumask_empty(to_cpumask(backtrace_mask))) {
+ pr_info("Sending FIQ to %s CPUs:\n",
+ (include_self ? "all" : "other"));
+ smp_cross_call(to_cpumask(backtrace_mask), IPI_CPU_BACKTRACE);
+ }
+
+ /* Wait for up to 10 seconds for all CPUs to do the backtrace */
+ for (i = 0; i < 10 * 1000; i++) {
+ if (cpumask_empty(to_cpumask(backtrace_mask)))
+ break;
+
+ mdelay(1);
+ }
+
+ clear_bit(0, _flag);
+ smp_mb__after_atomic();
+ put_cpu();
+}
--
1.9.3
--
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/lkml/
[PATCH v2 1/5] ARM: remove unused do_unexp_fiq() function
From: Russell King
do_unexp_fiq() has never been called by any code in the last 10 years,
it's about time it was removed!
Signed-off-by: Russell King
---
arch/arm/kernel/traps.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index c8e4bb7..a447dcc 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -460,12 +460,6 @@ die_sig:
arm_notify_die("Oops - undefined instruction", regs, , 0, 6);
}
-asmlinkage void do_unexp_fiq (struct pt_regs *regs)
-{
- printk("Hmm. Unexpected FIQ received, but trying to continue\n");
- printk("You may have a hardware problem...\n");
-}
-
/*
* bad_mode handles the impossible case in the vectors. If you see one of
* these, then it's extremely serious, and could mean you have buggy hardware.
--
1.9.3
--
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/lkml/
[PATCH v2 0/5] arm: Implement arch_trigger_all_cpu_backtrace
This patchset implements arch_trigger_all_cpu_backtrace for arm. Non-maskable signalling relies on the kernel being able to access FIQ and therefore, for devices that implement TrustZone, it will work only on systems that boot the kernel in secure mode. Tested on Freescale iMX.6 (both via SysRq-l and by deliberately locking up the kernel with CONFIG_DEBUG_SPINLOCK=y). Changes since v1: * Restructured to sit nicely on a similar FYI patchset from Russell King. It now effectively replaces the work in progress final patch with something much more complete. * Implemented (and tested) a Thumb-2 implementation of svc_exit_via_fiq (review of Nicolas Pitre) * Dropped the GIC group 0 workaround patch. The issue of FIQ interrupts being acknowledged by the IRQ handler does still exist but should be harmless because the IRQ handler will still wind up calling ipi_cpu_backtrace(). * Removed any dependency on CONFIG_FIQ; all cpu backtrace effectively becomes a platform feature (although the use of non-maskable interrupts to implement it is best effort rather than guaranteed). * Better comments highlighting usage of RAZ/WI registers (and parts of registers) in the GIC code. Changes *before* v1: * This patchset is a hugely cut-down successor to "[PATCH v11 00/19] arm: KGDB NMI/FIQ support". Thanks to Thomas Gleixner for suggesting the new structure. For historic details see: https://lkml.org/lkml/2014/9/2/227 * Fix bug in __fiq_abt (no longer passes a bad struct pt_regs value). In fixing this we also remove the useless indirection previously found in the fiq_handler macro. * Make default fiq handler "always on" by migrating from fiq.c to traps.c and replace do_unexp_fiq with the new handler (review of Russell King). * Add arm64 version of fiq.h (review of Russell King) * Removed conditional branching and code from irq-gic.c, this is replaced by much simpler code that relies on the GIC specification's heavy use of read-as-zero/write-ignored (review of Russell King) Daniel Thompson (3): arm: fiq: Replace default FIQ handler arm64: Introduce dummy version of asm/fiq.h irqchip: gic: Add support for IPI FIQ Russell King (2): ARM: remove unused do_unexp_fiq() function ARM: add basic support for on-demand backtrace of other CPUs arch/arm/include/asm/irq.h | 5 ++ arch/arm/include/asm/smp.h | 3 + arch/arm/kernel/entry-armv.S| 137 ++--- arch/arm/kernel/setup.c | 8 +- arch/arm/kernel/smp.c | 64 arch/arm/kernel/traps.c | 32 +++- arch/arm64/include/asm/fiq.h| 18 + drivers/irqchip/irq-gic.c | 165 +--- include/linux/irqchip/arm-gic.h | 3 + 9 files changed, 412 insertions(+), 23 deletions(-) create mode 100644 arch/arm64/include/asm/fiq.h -- 1.9.3 -- 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/lkml/
Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR
On Fri, 2014-09-05 at 08:07 -0700, H. Peter Anvin wrote: > On 09/05/2014 07:00 AM, Toshi Kani wrote: > > > > That's a fine idea, but as Ingo also suggested, I am going to disable > > this feature on all Pentium 4 models. That should give us a safety > > margin. Using slot 4 has a benefit that it keeps the PAT setup > > consistent with Xen. > > > > Slot 4 is also the maximally problematic one, because it is the one that > might be incorrectly invoked for the page tables themselves. Good point. I wonder if Xen folks feel strongly about keeping the PAT setup consistent with the kernel. If not, we may choose to use slot 6 (or 7). Thanks, -Toshi -- 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/lkml/
Re: [PATCH] ARM: at91: rm9200: fix clock registration
On 05/09/2014 17:26, Nicolas Ferre :
> On 05/09/2014 16:15, Alexandre Belloni :
>> Actually register clocks from device tree when using the common clock
>> framework.
>>
>> Signed-off-by: Alexandre Belloni
>
> Indeed, thanks: I'll queue it in at91-3.18-fixes.
s/18/17/
Sorry.
>
> Acked-by: Nicolas Ferre
>
>
>> ---
>> arch/arm/mach-at91/board-dt-rm9200.c | 11 ++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-at91/board-dt-rm9200.c
>> b/arch/arm/mach-at91/board-dt-rm9200.c
>> index 61ea21445664..a598481a3570 100644
>> --- a/arch/arm/mach-at91/board-dt-rm9200.c
>> +++ b/arch/arm/mach-at91/board-dt-rm9200.c
>> @@ -14,6 +14,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -24,13 +25,21 @@
>> #include "at91_aic.h"
>> #include "generic.h"
>>
>> +static void __init rm9200_dt_timer_init(void)
>> +{
>> +#if defined(CONFIG_COMMON_CLK)
>> +of_clk_init(NULL);
>> +#endif
>> +at91rm9200_timer_init();
>> +}
>> +
>> static const char *at91rm9200_dt_board_compat[] __initdata = {
>> "atmel,at91rm9200",
>> NULL
>> };
>>
>> DT_MACHINE_START(at91rm9200_dt, "Atmel AT91RM9200 (Device Tree)")
>> -.init_time = at91rm9200_timer_init,
>> +.init_time = rm9200_dt_timer_init,
>> .map_io = at91_map_io,
>> .init_early = at91rm9200_dt_initialize,
>> .dt_compat = at91rm9200_dt_board_compat,
>>
>
>
--
Nicolas Ferre
--
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/lkml/
Re: [PATCH 2/3] dmaengine: pl330: Fix NULL pointer dereference on probe failure
On 09/05/2014 05:04 PM, Krzysztof Kozlowski wrote: If dma_async_device_register() returns error and probe should clean up and return error, a NULL pointer exception happens because of dereference of not allocated channel thread: [...] Signed-off-by: Krzysztof Kozlowski Reviewed-by: Lars-Peter Clausen -- 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/lkml/
Re: bit fields && data tearing
On 09/04/2014 10:08 PM, H. Peter Anvin wrote: > On 09/04/2014 05:59 PM, Peter Hurley wrote: >> I have no idea how prevalent the ev56 is compared to the ev5. >> Still we're talking about a chip that came out in 1996. > > Ah yes, I stand corrected. According to Wikipedia, the affected CPUs > were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164 with no > suffix (EV5). However, we're still talking about museum pieces here. > > I wonder what the one I have in my garage is... I'm sure I could emulate > it faster, though. Which is a bit ironic because I remember when Digital had a team working on emulating native x86 apps on Alpha/NT. -- 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/lkml/
Re: [PATCH 3/3] dmaengine: pl330: Fix NULL pointer dereference on driver unbind
On 09/05/2014 05:04 PM, Krzysztof Kozlowski wrote: [...] Signed-off-by: Krzysztof Kozlowski Reviewed-by: Lars-Peter Clausen -- 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/lkml/
Re: [PATCH 1/3] dmaengine: pl330: Do not dereference pl330_thread pointer before non-NULL check
On 09/05/2014 05:04 PM, Krzysztof Kozlowski wrote:
Do not dereference the 'struct pl330_thread *thrd' before the check for
non-NULL value.
This fixes following warning:
drivers/dma/pl330.c:1376 pl330_submit_req() warn: variable dereferenced before
check 'thrd' (see line 1367)
I think we can just drop that whole line of checks, none of them will ever
be true.
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma/pl330.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index d5149aacd2fe..47d82070848d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1364,7 +1364,7 @@ static inline u32 _prepare_ccr(const struct pl330_reqcfg
*rqc)
static int pl330_submit_req(struct pl330_thread *thrd,
struct dma_pl330_desc *desc)
{
- struct pl330_dmac *pl330 = thrd->dmac;
+ struct pl330_dmac *pl330;
struct _xfer_spec xs;
unsigned long flags;
void __iomem *regs;
@@ -1376,6 +1376,7 @@ static int pl330_submit_req(struct pl330_thread *thrd,
if (!desc || !thrd || thrd->free)
return -EINVAL;
+ pl330 = thrd->dmac;
regs = thrd->dmac->base;
if (pl330->state == DYING
--
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/lkml/
Re: [PATCH 3/4] watchdog: st_wdt: Provide binding documentation for ST's LPC Watchdog driver
On Thu, Sep 04, 2014 at 03:39:51PM +0100, Lee Jones wrote:
> Signed-off-by: David Paris
> Signed-off-by: Lee Jones
You might want to copy the devicetree mailing list for bindings approval.
> ---
> .../devicetree/bindings/watchdog/st-lpc-wdt.txt| 27
> ++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/st-lpc-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/st-lpc-wdt.txt
> b/Documentation/devicetree/bindings/watchdog/st-lpc-wdt.txt
> new file mode 100644
> index 000..f0e57ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/st-lpc-wdt.txt
> @@ -0,0 +1,27 @@
> +STMicroelectronics LPC Watchdog
> +===
> +
> +Required properties
> +
> +- compatible : "st,-watchdog"
Is this acceptable ? I thought the supported bindings have to be listed
explicitly.
> +- reg: LPC registers base address + range
> +- reg-names : Register map "base" and "syscfg-en" are compulsory "type" is
'.' after compulsory ?
> + platform dependent and not required for the STiH407.
> +- clock-names: Should be "lpc_wdt"
> +- clocks : Clock used by LPC device
> +- timeout-sec: Qatchdog timeout in seconds
Watchdog
> +- st,syscfg : Syscfg node used to configure cpu reset type and mask
> +- st,warm_reset : If present, reset type will be 'warm'. If not, it
> will be cold
s/cold/cold./ ?
> +
> +Example:
> + watchdog@fde05000 {
> + compatible = "st,stih416-lpc-watchdog";
> + reg = <0xfde05000 0x1000> <0x204 0x4>;
> + reg-names = "base", "syscfg-en"
> + clock-names = "lpc_wdt";
> + clocks = <_s_d3_flexgen CLK_LPC_0>;
> + timeout-sec = <600>;
> + st,syscfg = <_core>;
> + st,warm_reset;
> + };
> +
Empty line at the end results in a whitespace error when applying.
Guenter
--
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/lkml/
Re: [PATCH] ARM: at91/dt: rm9200: fix usb clock definition
On 05/09/2014 16:45, Alexandre Belloni :
> The atmel,clk-divisors property is taking 4 divisors, if less are
> provided, the clock registration will fail.
>
> Signed-off-by: Alexandre Belloni
Acked-by: Nicolas Ferre
Stacked on at91-3.17-fixes.
> ---
> arch/arm/boot/dts/at91rm9200.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
> b/arch/arm/boot/dts/at91rm9200.dtsi
> index 65ccf564b9a5..6c97d4af61ee 100644
> --- a/arch/arm/boot/dts/at91rm9200.dtsi
> +++ b/arch/arm/boot/dts/at91rm9200.dtsi
> @@ -149,7 +149,7 @@
> usb: usbck {
> compatible = "atmel,at91rm9200-clk-usb";
> #clock-cells = <0>;
> - atmel,clk-divisors = <1 2>;
> + atmel,clk-divisors = <1 2 0 0>;
> clocks = <>;
> };
>
>
--
Nicolas Ferre
--
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/lkml/
Re: [PATCH] ARM: at91: rm9200: fix clock registration
On 05/09/2014 16:15, Alexandre Belloni :
> Actually register clocks from device tree when using the common clock
> framework.
>
> Signed-off-by: Alexandre Belloni
Indeed, thanks: I'll queue it in at91-3.18-fixes.
Acked-by: Nicolas Ferre
> ---
> arch/arm/mach-at91/board-dt-rm9200.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-at91/board-dt-rm9200.c
> b/arch/arm/mach-at91/board-dt-rm9200.c
> index 61ea21445664..a598481a3570 100644
> --- a/arch/arm/mach-at91/board-dt-rm9200.c
> +++ b/arch/arm/mach-at91/board-dt-rm9200.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -24,13 +25,21 @@
> #include "at91_aic.h"
> #include "generic.h"
>
> +static void __init rm9200_dt_timer_init(void)
> +{
> +#if defined(CONFIG_COMMON_CLK)
> + of_clk_init(NULL);
> +#endif
> + at91rm9200_timer_init();
> +}
> +
> static const char *at91rm9200_dt_board_compat[] __initdata = {
> "atmel,at91rm9200",
> NULL
> };
>
> DT_MACHINE_START(at91rm9200_dt, "Atmel AT91RM9200 (Device Tree)")
> - .init_time = at91rm9200_timer_init,
> + .init_time = rm9200_dt_timer_init,
> .map_io = at91_map_io,
> .init_early = at91rm9200_dt_initialize,
> .dt_compat = at91rm9200_dt_board_compat,
>
--
Nicolas Ferre
--
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/lkml/
Re: [PATCH] scsi_debug: deadlock between completions and surprise module removal
On 09/05/14 15:56, Douglas Gilbert wrote: With scsi-mq I think many LLDs probably have a new race possibility between a surprise rmmod of the LLD and another thread presenting a new command at about the same time (or another thread's command completing around that time). Does anything above the LLD stop this happening? Looking at mpt3sas and hpsa module exit calls, they don't seem to guard against this possibility. The test is pretty easy: build the LLD as a module, load it and fire up a multi-thread, libaio fio test on one or more devices (SSDs would probably be good) on that LLD. While the test is running, do 'rmmod LLD'. An LLD must call scsi_remove_host() directly or indirectly from the module cleanup path. scsi_remove_host() triggers a call to blk_cleanup_queue(). That last function sets the flag QUEUE_FLAG_DYING which prevents that new I/O is queued and waits until previously queued requests have finished before returning. Bart. -- 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/lkml/
Re: [PATCH] audit: vfs: fix audit records error when write to a file
Hi Jeff,
I don't know if we can keep audit_inode() in do_last(). I've tried
this but found
the only way to enable both write() and create() is moving it to lookup_open().
I know this is not good, but I think we have no choice.
The current patch really miss the ROFS condition as you said. How about
moving audit_inode() to the beginning of the O_CREAT case in lookup_open()?
That's my mistake. After this, it seems no creating records will be missing.
I would like to change this and resend a new patch. I'm worry about if we miss
something. Before I do this, do you have any suggestions? Or do you have a
better way to keep audit_inode() in do_last()?
Thank you~!
Hu
2014-09-05 18:50 GMT+08:00 Jeff Layton :
> On Fri, 5 Sep 2014 14:55:53 +0800
> hujianyang wrote:
>
>> commit 33e2208acfc1
>>
>> audit: vfs: fix audit_inode call in O_CREAT case of do_last
>>
>> fix a regression in auditing of open(..., O_CREAT) syscalls but
>> import a new problem which lead the records of write operation
>> confusion.
>>
>> This error can be reproduced by these steps:
>>
>> touch /etc/test
>> echo "-w /etc/test" >>/etc/audit/audit.rules
>> /etc/init.d/auditd restart
>>
>> echo "abc" >> /etc/test
>>
>> audit_name records are:
>>
>> type=PATH msg=audit(1409764556.196:67): item=0 name="/etc/" inode=5097
>> dev=00:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT
>> type=PATH msg=audit(1409764556.196:67): item=1 name=(null) inode=23161
>> dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
>> type=PATH msg=audit(1409764556.196:67): item=2 name=(null) inode=23161
>> dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
>>
>> but if we revert commit 33e2208acfc1, records are correct:
>>
>> type=PATH msg=audit(1409763058.192:219): item=0 name="/etc/test" inode=1275
>> dev=00:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
>>
>> We shouldn't leave audit_inode(.., LOOKUP_PARENT) in O_CREAT case
>> of do_last() because this branch don't really know if vfs need to
>> create a new file. There is no need to do vfs_create() if we open
>> an existing file with O_CREAT flag and write to it. But this
>> audit_inode() in O_CREAT case will record a msg as we create a new
>> file and confuse the records of write.
>>
>> This patch moves the audit for create operation to where a file
>> really need to be created, the O_CREAT case in lookup_open().
>> We have to add the pointer of struct filename as a parameter of
>> lookup_open(). By doing this, the records of both create and write
>> are correct.
>>
>> Signed-off-by: hujianyang
>> ---
>> fs/namei.c | 9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/namei.c b/fs/namei.c
>> index a996bb4..0bc7734 100644
>> --- a/fs/namei.c
>> +++ b/fs/namei.c
>> @@ -2808,7 +2808,8 @@ looked_up:
>> static int lookup_open(struct nameidata *nd, struct path *path,
>> struct file *file,
>> const struct open_flags *op,
>> - bool got_write, int *opened)
>> + bool got_write, int *opened,
>> + struct filename *name)
>> {
>> struct dentry *dir = nd->path.dentry;
>> struct inode *dir_inode = dir->d_inode;
>> @@ -2854,6 +2855,9 @@ static int lookup_open(struct nameidata *nd, struct
>> path *path,
>> error = -EROFS;
>> goto out_dput;
>> }
>> +
>> + audit_inode(name, dir, LOOKUP_PARENT);
>> +
>> *opened |= FILE_CREATED;
>> error = security_path_mknod(>path, dentry, mode, 0);
>> if (error)
>> @@ -2926,7 +2930,6 @@ static int do_last(struct nameidata *nd, struct path
>> *path,
>> if (error)
>> return error;
>>
>> - audit_inode(name, dir, LOOKUP_PARENT);
>> error = -EISDIR;
>> /* trailing slashes? */
>> if (nd->last.name[nd->last.len])
>> @@ -2945,7 +2948,7 @@ retry_lookup:
>>*/
>> }
>> mutex_lock(>d_inode->i_mutex);
>> - error = lookup_open(nd, path, file, op, got_write, opened);
>> + error = lookup_open(nd, path, file, op, got_write, opened, name);
>> mutex_unlock(>d_inode->i_mutex);
>>
>> if (error <= 0) {
>
> I'm not sure about this. Won't this cause us to miss creating audit
> records in some error conditions?
>
> For instance, if you end up not being able to create the file due to
> the fs being read-only, then I think this patch would make you miss the
> audit record for the parent.
>
> Might it be better to not plumb an extra pointer into lookup_open and
> just move the audit_inode calls around do_last in the appropriate
> places instead?
>
> --
> Jeff Layton
--
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
Re: [RFC PATCH] dma: pl330: add Power Management support
On 09/05/2014 05:06 PM, Krzysztof Kozlowski wrote:
[...]
@@ -2168,11 +2199,23 @@ static void pl330_issue_pending(struct dma_chan *chan)
{
struct dma_pl330_chan *pch = to_pchan(chan);
unsigned long flags;
+ bool power_up;
spin_lock_irqsave(>lock, flags);
+ power_up = list_empty(>work_list);
list_splice_tail_init(>submitted_list, >work_list);
spin_unlock_irqrestore(>lock, flags);
+ if (power_up) {
+ /*
+* Warn on nothing pending. This may break our pm_runtime
+* usage counter as it is updated on work_list emptiness
+* status.
+*/
+ WARN_ON(list_empty(>work_list));
+ pm_runtime_get_sync(pch->dmac->ddma.dev);
Unfortunately this does not work. pm_runtime_get_sync() may sleep, where as
the issue_pending callback needs to be able to run from contexts in which
sleeping is not possible.
+ }
+
pl330_tasklet((unsigned long)pch);
}
[...]
--
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/lkml/
Re: [PATCH] ARM: at91/dt: sam9g20: set at91sam9g20 pllb driver
On 01/09/2014 23:29, Gaël PORTAY :
> The at91sam9g20 SOC uses its own pllb implementation which is different
> from the one inherited from at91sam9260 SOC.
>
> Signed-off-by: Gaël PORTAY
Acked-by: Nicolas Ferre
Stacked on at91-3.17-fixes. Thanks!
> ---
> arch/arm/boot/dts/at91sam9g20.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi
> b/arch/arm/boot/dts/at91sam9g20.dtsi
> index 31f7652..4e0abbd 100644
> --- a/arch/arm/boot/dts/at91sam9g20.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g20.dtsi
> @@ -40,6 +40,7 @@
> };
>
> pllb: pllbck {
> + compatible =
> "atmel,at91sam9g20-clk-pllb";
> atmel,clk-input-range = <200
> 3200>;
> atmel,pll-clk-output-ranges = <3000
> 1 0 0>;
> };
>
--
Nicolas Ferre
--
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/lkml/
Re: [PATCH v5 00/16] perf, x86: Haswell LBR call stack support
On Fri, Sep 5, 2014 at 4:25 PM, Liang, Kan wrote: > Hi Peter and all, > > Did you get a chance to review these patches? > Zheng is away. Should I re-send the patches? > Please resubmit rebased to tip.git and I'll take another look. > Thanks, > Kan > >> >> For many profiling tasks we need the callgraph. For example we often need >> to see the caller of a lock or the caller of a memcpy or other library >> function >> to actually tune the program. Frame pointer unwinding is efficient and works >> well. But frame pointers are off by default on 64bit code (and on modern >> 32bit gccs), so there are many binaries around that do not use frame >> pointers. >> Profiling unchanged production code is very useful in practice. On some CPUs >> frame pointer also has a high cost. Dwarf2 unwinding also does not always >> work and is extremely slow (upto 20% overhead). >> >> Haswell has a new feature that utilizes the existing Last Branch Record >> facility >> to record call chains. When the feature is enabled, function call will be >> collected as normal, but as return instructions are executed the last >> captured >> branch record is popped from the on-chip LBR registers. The LBR call stack >> facility provides an alternative to get callgraph. It has some limitations >> too, >> but should work in most cases and is significantly faster than dwarf. Frame >> pointer unwinding is still the best default, but LBR call stack is a good >> alternative when nothing else works. >> >> When profiling bc(1) on Fedora 19: >> echo 'scale=2000; 4*a(1)' > cmd; perf record -g fp bc -l < cmd >> >> If this feature is enabled, perf report output looks like: >> 50.36% bc bc [.] bc_divide >> | >> --- bc_divide >> execute >> run_code >> yyparse >> main >> __libc_start_main >> _start >> >> 33.66% bc bc [.] _one_mult >> | >> --- _one_mult >> bc_divide >> execute >> run_code >> yyparse >> main >> __libc_start_main >> _start >> >> 7.62% bc bc [.] _bc_do_add >> | >> --- _bc_do_add >> | >> |--99.89%-- 0x2000186a8 >> --0.11%-- [...] >> >> 6.83% bc bc [.] _bc_do_sub >> | >> --- _bc_do_sub >> | >> |--99.94%-- bc_add >> | execute >> | run_code >> | yyparse >> | main >> | __libc_start_main >> | _start >> --0.06%-- [...] >> >> 0.46% bc libc-2.17.so [.] __memset_sse2 >> | >> --- __memset_sse2 >> | >> |--54.13%-- bc_new_num >> | | >> | |--51.00%-- bc_divide >> | | execute >> | | run_code >> | | yyparse >> | | main >> | | __libc_start_main >> | | _start >> | | >> | |--30.46%-- _bc_do_sub >> | | bc_add >> | | execute >> | | run_code >> | | yyparse >> | | main >> | | __libc_start_main >> | | _start >> | | >> | --18.55%-- _bc_do_add >> | bc_add >> | execute >> | run_code >> | yyparse >> | main >> | __libc_start_main >> | _start >> | >> --45.87%-- bc_divide >>execute >>run_code >>yyparse >>main >>__libc_start_main >>_start >> >> If this feature is disabled, perf report output looks like: >> 50.49%
[PATCH] gpiolib: fix a few issues with gpiochip_remove
The current implementation of gpiochip_remove() does not check to see
if the GPIO pins are busy before removing the associated irqchip and
this is causing the following warning:
WARNING: CPU: 3 PID: 553 at fs/proc/generic.c:521
remove_proc_entry+0x19f/0x1b0()
remove_proc_entry: removing non-empty directory 'irq/24', leaking at least
'bmc150_accel_event'
Call Trace:
[] dump_stack+0x4e/0x7a
[] warn_slowpath_common+0x7d/0xa0
[] warn_slowpath_fmt+0x4c/0x50
[] remove_proc_entry+0x19f/0x1b0
[] unregister_irq_proc+0xce/0xf0
[] free_desc+0x31/0x70
[] irq_free_descs+0x3c/0x80
[] irq_dispose_mapping+0x36/0x50
[] gpiochip_remove+0x5a/0x160
[] dln2_do_remove+0x18/0x80
[] dln2_gpio_remove+0x2a/0x30
[] platform_drv_remove+0x1d/0x40
...
and bug:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
in_atomic(): 1, irqs_disabled(): 1, pid: 553, name: khubd
Preemption disabled at:[] gpiochip_remove+0x22/0x160
Call Trace:
[] dump_stack+0x4e/0x7a
[] __might_sleep+0x10f/0x180
[] mutex_lock+0x20/0x3d
[] free_desc+0x3d/0x70
[] irq_free_descs+0x3c/0x80
[] irq_dispose_mapping+0x36/0x50
[] gpiochip_remove+0x5a/0x160
[] dln2_do_remove+0x18/0x80
[] dln2_gpio_remove+0x2a/0x30
[] platform_drv_remove+0x1d/0x40
...
The current implementaion also does a partial cleanup if one of the
pins is busy, which makes it impossible to retry the remove operation
later.
A retry operation is needed in the case of MFD devices that bundles a
GPIO device and another device that is an indirect consumer of the
GPIO device (typical an I2C bus).
In this case, when the MFD device is removed, if an I2C device
associated with the I2C bus of the MFD device is using a GPIO pin (as
an interrupt source for example), and the remove routine for the GPIO
device is called first, then the removal of the gpio chip will fail.
However, we can later retry the gpio chip removal, as the I2C bus will
eventually be removed which will cause the I2C device to release the
GPIO pin.
This patch modifies gpiochip_remove to be atomic (i.e. if it fails no
partial cleanup is done) and it also moves gpiochip_irqchip_remove()
out of the spinlock to avoid the bug above.
Signed-off-by: Octavian Purdila
---
drivers/gpio/gpiolib.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 15cc0bb..0f53bef 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -314,14 +314,8 @@ int gpiochip_remove(struct gpio_chip *chip)
int status = 0;
unsignedid;
- acpi_gpiochip_remove(chip);
-
spin_lock_irqsave(_lock, flags);
- gpiochip_irqchip_remove(chip);
- gpiochip_remove_pin_ranges(chip);
- of_gpiochip_remove(chip);
-
for (id = 0; id < chip->ngpio; id++) {
if (test_bit(FLAG_REQUESTED, >desc[id].flags)) {
status = -EBUSY;
@@ -337,8 +331,13 @@ int gpiochip_remove(struct gpio_chip *chip)
spin_unlock_irqrestore(_lock, flags);
- if (status == 0)
+ if (status == 0) {
+ gpiochip_irqchip_remove(chip);
+ gpiochip_remove_pin_ranges(chip);
+ of_gpiochip_remove(chip);
+ acpi_gpiochip_remove(chip);
gpiochip_unexport(chip);
+ }
return status;
}
--
1.9.1
--
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/lkml/
[PATCH v3 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver
From: Daniel Baluta
This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 2.9 for the GPIO
module commands and responses.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Daniel Baluta
Signed-off-by: Octavian Purdila
---
drivers/gpio/Kconfig | 12 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-dln2.c | 537 +++
3 files changed, 550 insertions(+)
create mode 100644 drivers/gpio/gpio-dln2.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 9de1515..6a9e352 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -897,4 +897,16 @@ config GPIO_VIPERBOARD
River Tech's viperboard.h for detailed meaning
of the module parameters.
+config GPIO_DLN2
+ tristate "Diolan DLN2 GPIO support"
+ depends on USB && MFD_DLN2
+ select GPIOLIB_IRQCHIP
+
+ help
+ Select this option to enable GPIO driver for the Diolan DLN2
+ board.
+
+ This driver can also be built as a module. If so, the module
+ will be called gpio-dln2.
+
endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 5d024e3..eaa97a0 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_GPIO_CRYSTAL_COVE) += gpio-crystalcove.o
obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o
obj-$(CONFIG_GPIO_DA9055) += gpio-da9055.o
obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
+obj-$(CONFIG_GPIO_DLN2)+= gpio-dln2.o
obj-$(CONFIG_GPIO_DWAPB) += gpio-dwapb.o
obj-$(CONFIG_GPIO_EM) += gpio-em.o
obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
new file mode 100644
index 000..f8c0bcb
--- /dev/null
+++ b/drivers/gpio/gpio-dln2.c
@@ -0,0 +1,537 @@
+/*
+ * Driver for the Diolan DLN-2 USB-GPIO adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "dln2-gpio"
+
+#define DLN2_GPIO_ID 0x01
+
+#define DLN2_GPIO_GET_PORT_COUNT DLN2_CMD(0x00, DLN2_GPIO_ID)
+#define DLN2_GPIO_GET_PIN_COUNTDLN2_CMD(0x01, DLN2_GPIO_ID)
+#define DLN2_GPIO_SET_DEBOUNCE DLN2_CMD(0x04, DLN2_GPIO_ID)
+#define DLN2_GPIO_GET_DEBOUNCE DLN2_CMD(0x05, DLN2_GPIO_ID)
+#define DLN2_GPIO_PORT_GET_VAL DLN2_CMD(0x06, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_VAL DLN2_CMD(0x0B, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_OUT_VAL DLN2_CMD(0x0C, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_OUT_VAL DLN2_CMD(0x0D, DLN2_GPIO_ID)
+#define DLN2_GPIO_CONDITION_MET_EV DLN2_CMD(0x0F, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_ENABLE DLN2_CMD(0x10, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_DISABLE DLN2_CMD(0x11, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_DIRECTIONDLN2_CMD(0x13, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_DIRECTIONDLN2_CMD(0x14, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_EVENT_CFGDLN2_CMD(0x1E, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_EVENT_CFGDLN2_CMD(0x1F, DLN2_GPIO_ID)
+
+#define DLN2_GPIO_EVENT_NONE 0
+#define DLN2_GPIO_EVENT_CHANGE 1
+#define DLN2_GPIO_EVENT_LVL_HIGH 2
+#define DLN2_GPIO_EVENT_LVL_LOW3
+#define DLN2_GPIO_EVENT_CHANGE_RISING 0x11
+#define DLN2_GPIO_EVENT_CHANGE_FALLING 0x21
+#define DLN2_GPIO_EVENT_MASK 0x0F
+
+#define DLN2_GPIO_MAX_PINS 32
+
+struct dln2_irq_work {
+ struct work_struct work;
+ struct dln2_gpio *dln2;
+ int pin, type;
+};
+
+struct dln2_remove_work {
+ struct delayed_work work;
+ struct dln2_gpio *dln2;
+};
+
+struct dln2_gpio {
+ struct platform_device *pdev;
+ struct gpio_chip gpio;
+
+ DECLARE_BITMAP(irqs_masked, DLN2_GPIO_MAX_PINS);
+ DECLARE_BITMAP(irqs_enabled, DLN2_GPIO_MAX_PINS);
+ DECLARE_BITMAP(irqs_pending, DLN2_GPIO_MAX_PINS);
+ struct dln2_irq_work irq_work[DLN2_GPIO_MAX_PINS];
+ struct dln2_remove_work remove_work;
+};
+
+struct dln2_gpio_pin {
+ __le16 pin;
+} __packed;
+
+struct dln2_gpio_pin_val {
+ __le16 pin;
+ u8 value;
+} __packed;
+
+static int dln2_gpio_get_pin_count(struct platform_device *pdev)
+{
+ __le16 count;
+ int ret, len = sizeof(count);
+
+ ret = dln2_transfer(pdev, DLN2_GPIO_GET_PIN_COUNT, NULL, 0, ,
+ );
+ if (ret < 0)
+ return ret;
+
+ if (len < sizeof(count))
+
Re: [PATCH] i2c: rk3x: fix divisor calculation for SCL frequency
Addy,
On Fri, Sep 5, 2014 at 3:17 AM, addy ke wrote:
> The following modifications is reasonable?
>
> static void rk3x_i2c_set_scl_rate(struct rk3x_i2c *i2c, unsigned long
> scl_rate)
> {
> unsigned long i2c_rate = clk_get_rate(i2c->clk);
> unsigned int div;
>
> /* set DIV = DIVH = DIVL
> * SCL rate = (clk rate) / (8 * (DIVH + 1 + DIVL + 1))
> * = (clk rate) / (16 * (DIV + 1))
> */
> div = DIV_ROUND_UP(i2c_rate, scl_rate * 16) - 1;
>
> i2c_writel(i2c, (div << 16) | (div & 0x), REG_CLKDIV);
> }
Yes, that looks much cleaner and is a nice solution, thanks! Can you
send up a new patch version?
-Doug
--
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/lkml/
Re: [PATCH v3] ARM: dts: qcom: Add initial IFC6540 board device tree
On Sep 5, 2014, at 9:26 AM, Andreas Färber wrote:
> Hi,
>
> Am 03.09.2014 18:50, schrieb Georgi Djakov:
>> Add basic support for the IFC6540 single-board computer boards, that are
>> based on the APQ8084 SoC. This patch adds the initial device tree and the
>> neccessary nodes required for enabling the serial port and eMMC.
>>
>> Signed-off-by: Georgi Djakov
>> ---
>> Changes since v2:
>> - Squashed all patches into one. (suggested by Kumar Gala)
>>
>> Changes since v1:
>> - This time add linux-arm-msm list to the CC.
>> - Include a third patch for enabling the eMMC.
>>
>> arch/arm/boot/dts/Makefile |1 +
>> arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 23 +++
>> arch/arm/boot/dts/qcom-apq8084.dtsi| 23 +++
>> 3 files changed, 47 insertions(+)
>> create mode 100644 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index b022972..df8453a 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -345,6 +345,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
>> dtb-$(CONFIG_ARCH_QCOM) += \
>> qcom-apq8064-ifc6410.dtb \
>> qcom-apq8074-dragonboard.dtb \
>> +qcom-apq8084-ifc6540.dtb \
>> qcom-apq8084-mtp.dtb \
>> qcom-msm8660-surf.dtb \
>> qcom-msm8960-cdp.dtb
>> diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
>> b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
>> new file mode 100644
>> index 000..c9ff108
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
>> @@ -0,0 +1,23 @@
>> +#include "qcom-apq8084.dtsi"
>> +
>> +/ {
>> +model = "Qualcomm APQ8084/IFC6540";
>> +compatible = "qcom,apq8084-ifc6540", "qcom,apq8084";
>> +
>> +soc {
>> +serial@f995e000 {
>> +status = "okay";
>> +};
>> +
>> +sdhci@f9824900 {
>> +bus-width = <8>;
>> +non-removable;
>> +status = "okay";
>> +};
>> +
>> +sdhci@f98a4900 {
>> +cd-gpios = < 122 GPIO_ACTIVE_LOW>;
>> +bus-width = <4>;
>> +};
>> +};
>> +};
>> diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
>> b/arch/arm/boot/dts/qcom-apq8084.dtsi
>> index 21d01e5..1f130bc 100644
>> --- a/arch/arm/boot/dts/qcom-apq8084.dtsi
>> +++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
>> @@ -3,6 +3,7 @@
>> #include "skeleton.dtsi"
>>
>> #include
>> +#include
>>
>> / {
>> model = "Qualcomm APQ 8084";
>> @@ -203,5 +204,27 @@
>> clock-names = "core", "iface";
>> status = "disabled";
>> };
>> +
>> +sdhci@f9824900 {
>> +compatible = "qcom,sdhci-msm-v4";
>> +reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
>> +reg-names = "hc_mem", "core_mem";
>> +interrupts = <0 123 0>, <0 138 0>;
>
> I see that you've used GPIO_ACTIVE_* above. Is the trailing zero here
> possibly IRQ_TYPE_NONE?
>
>> +interrupt-names = "hc_irq", "pwr_irq";
>> +clocks = < GCC_SDCC1_APPS_CLK>, <
>> GCC_SDCC1_AHB_CLK>;
>> +clock-names = "core", "iface";
>> +status = "disabled";
>> +};
>> +
>> +sdhci@f98a4900 {
>> +compatible = "qcom,sdhci-msm-v4";
>> +reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
>> +reg-names = "hc_mem", "core_mem";
>> +interrupts = <0 125 0>, <0 221 0>;
>> +interrupt-names = "hc_irq", "pwr_irq";
>> +clocks = < GCC_SDCC2_APPS_CLK>, <
>> GCC_SDCC2_AHB_CLK>;
>> +clock-names = "core", "iface";
>> +status = "disabled";
>> +};
>
> If you assign labels to these two nodes, you can reference them in the
> .dts as {...};. Same for the uart node. That avoids
> duplicating the hierarchy, detects spelling mistakes at compile time and
> reduces indentation. Cf. the recent ifc6410 patch.
Got no issues with introducing the labels, but I’d like to keep the hierarchy
in the .dts file.
> Also, is sdhci the best node name here? Usually it's not supposed to
> reflect the exact interface used (e.g., usb vs. ehci).
probably just use sdhc
>
>> };
>> };
>
> Otherwise looks good.
>
> Regards,
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux
[PATCH v3 2/3] i2c: add support for Diolan DLN-2 USB-I2C adapter
From: Laurentiu Palcu
This patch adds support for the Diolan DLN-2 I2C master module. Due
to hardware limitations it does not support SMBUS quick commands.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 6.2.2 for the I2C
master module commands and responses.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Laurentiu Palcu
Signed-off-by: Octavian Purdila
---
drivers/i2c/busses/Kconfig| 10 ++
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-dln2.c | 301 ++
3 files changed, 312 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-dln2.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..4873161 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1021,4 +1021,14 @@ config SCx200_ACB
This support is also available as a module. If so, the module
will be called scx200_acb.
+config I2C_DLN2
+ tristate "Diolan DLN-2 USB I2C adapter"
+ depends on USB && MFD_DLN2
+ help
+ If you say yes to this option, support will be included for Diolan
+ DLN2, a USB to I2C interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-dln2.
+
endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 49bf07e..3118fea 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -100,5 +100,6 @@ obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
obj-$(CONFIG_I2C_PCA_ISA) += i2c-pca-isa.o
obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
+obj-$(CONFIG_I2C_DLN2) += i2c-dln2.o
ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-dln2.c b/drivers/i2c/busses/i2c-dln2.c
new file mode 100644
index 000..93e85ff
--- /dev/null
+++ b/drivers/i2c/busses/i2c-dln2.c
@@ -0,0 +1,301 @@
+/*
+ * Driver for the Diolan DLN-2 USB-I2C adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ * i2c-diolan-u2c.c
+ * Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define DRIVER_NAME"dln2-i2c"
+
+#define DLN2_I2C_MODULE_ID 0x03
+#define DLN2_I2C_CMD(cmd) DLN2_CMD(cmd, DLN2_I2C_MODULE_ID)
+
+/* I2C commands */
+#define DLN2_I2C_GET_PORT_COUNTDLN2_I2C_CMD(0x00)
+#define DLN2_I2C_ENABLEDLN2_I2C_CMD(0x01)
+#define DLN2_I2C_DISABLE DLN2_I2C_CMD(0x02)
+#define DLN2_I2C_IS_ENABLEDDLN2_I2C_CMD(0x03)
+#define DLN2_I2C_SET_FREQUENCY DLN2_I2C_CMD(0x04)
+#define DLN2_I2C_GET_FREQUENCY DLN2_I2C_CMD(0x05)
+#define DLN2_I2C_WRITE DLN2_I2C_CMD(0x06)
+#define DLN2_I2C_READ DLN2_I2C_CMD(0x07)
+#define DLN2_I2C_SCAN_DEVICES DLN2_I2C_CMD(0x08)
+#define DLN2_I2C_PULLUP_ENABLE DLN2_I2C_CMD(0x09)
+#define DLN2_I2C_PULLUP_DISABLEDLN2_I2C_CMD(0x0A)
+#define DLN2_I2C_PULLUP_IS_ENABLED DLN2_I2C_CMD(0x0B)
+#define DLN2_I2C_TRANSFER DLN2_I2C_CMD(0x0C)
+#define DLN2_I2C_SET_MAX_REPLY_COUNT DLN2_I2C_CMD(0x0D)
+#define DLN2_I2C_GET_MAX_REPLY_COUNT DLN2_I2C_CMD(0x0E)
+#define DLN2_I2C_GET_MIN_FREQUENCY DLN2_I2C_CMD(0x40)
+#define DLN2_I2C_GET_MAX_FREQUENCY DLN2_I2C_CMD(0x41)
+
+#define DLN2_I2C_FREQ_FAST 40
+#define DLN2_I2C_FREQ_STD 10
+
+#define DLN2_I2C_MAX_XFER_SIZE 256
+
+struct dln2_i2c {
+ struct platform_device *pdev;
+ struct i2c_adapter adapter;
+};
+
+static uint frequency = DLN2_I2C_FREQ_STD; /* I2C clock frequency in Hz */
+
+module_param(frequency, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(frequency, "I2C clock frequency in hertz");
+
+static int dln2_i2c_set_state(struct dln2_i2c *dln2, u8 state)
+{
+ int ret;
+ u8 port = 0;
+
+ ret = dln2_transfer(dln2->pdev,
+ state ? DLN2_I2C_ENABLE : DLN2_I2C_DISABLE,
+ , sizeof(port), NULL, NULL);
+
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+#define dln2_i2c_enable(dln2) dln2_i2c_set_state(dln2, 1)
+#define dln2_i2c_disable(dln2) dln2_i2c_set_state(dln2, 0)
+
+static int dln2_i2c_set_frequency(struct dln2_i2c *dln2, u32 freq)
+{
+ int ret;
+ struct tx_data {
+ u8 port;
+ __le32 freq;
+ } __packed tx;
+
+ tx.port = 0;
+ tx.freq = cpu_to_le32(freq);
+
+ ret = dln2_transfer(dln2->pdev, DLN2_I2C_SET_FREQUENCY, , sizeof(tx),
+
[PATCH v3 0/3] mfd: add support for Diolan DLN-2
This patch series adds support for Diolan USB-I2C/GPIO Master Adapter DLN-2. Details about device can be found here: https://www.diolan.com/i2c/i2c_interface.html. Changes since v2: * MFD driver: fix a few obsolete comments for the DLN2 I/O API * GPIO driver: retry the chip remove call if -EBUSY is returned, see the comments in dln2_do_remove for more details; also removed a redundant !dln2->pdev check from dln2_irq_event - we do it in dln2_transfer already * I2C driver: add I2C_FUNC_SMBUS_I2C_BLOCK support Changes since v1: * rewrite the drivers as an MFD * rewrite the irq part of the gpio driver to use GPIOLIB_IRQCHIP * cleanup the I/O interface * various fixes and cleanps: check received message sizes before parsing, error handling for usb_submit_urb, check URB status, use single bit manipulation functions instead of bitmap_*, move GFP_KERNEL URB submit away from under lock Daniel Baluta (1): gpio: add support for the Diolan DLN-2 USB GPIO driver Laurentiu Palcu (1): i2c: add support for Diolan DLN-2 USB-I2C adapter Octavian Purdila (1): mfd: add support for Diolan DLN-2 devices drivers/gpio/Kconfig | 12 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-dln2.c | 537 ++ drivers/i2c/busses/Kconfig| 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-dln2.c | 301 +++ drivers/mfd/Kconfig | 9 + drivers/mfd/Makefile | 1 + drivers/mfd/dln2.c| 653 ++ include/linux/mfd/dln2.h | 61 10 files changed, 1586 insertions(+) create mode 100644 drivers/gpio/gpio-dln2.c create mode 100644 drivers/i2c/busses/i2c-dln2.c create mode 100644 drivers/mfd/dln2.c create mode 100644 include/linux/mfd/dln2.h -- 1.9.1 -- 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/lkml/
[PATCH v3 1/3] mfd: add support for Diolan DLN-2 devices
This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
Master Adapter DLN-2. Details about the device can be found here:
https://www.diolan.com/i2c/i2c_interface.html.
Information about the USB protocol can be found in the Programmer's
Reference Manual [1], see section 1.7.
Because the hardware has a single transmit endpoint and a single
receive endpoint the communication between the various DLN2 drivers
and the hardware will be muxed/demuxed by this driver.
Each DLN2 module will be identified by the handle field within the DLN2
message header. If a DLN2 module issues multiple commands in parallel
they will be identified by the echo counter field in the message header.
The DLN2 modules can use the dln2_transfer() function to issue a
command and wait for its response. They can also register a callback
that is going to be called when a specific event id is generated by
the device (e.g. GPIO interrupts). The device uses handle 0 for
sending events.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Octavian Purdila
---
drivers/mfd/Kconfig | 9 +
drivers/mfd/Makefile | 1 +
drivers/mfd/dln2.c | 653 +++
include/linux/mfd/dln2.h | 61 +
4 files changed, 724 insertions(+)
create mode 100644 drivers/mfd/dln2.c
create mode 100644 include/linux/mfd/dln2.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf2..7bcf895 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -183,6 +183,15 @@ config MFD_DA9063
Additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_DLN2
+ tristate "Diolan DLN2 support"
+ select MFD_CORE
+ depends on USB
+ help
+ This adds support for Diolan USB-I2C/SPI/GPIO Master Adapter DLN-2.
+ Additional drivers must be enabled in order to use the functionality
+ of the device.
+
config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..591988d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_DLN2) += dln2.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
new file mode 100644
index 000..81ff58e
--- /dev/null
+++ b/drivers/mfd/dln2.c
@@ -0,0 +1,653 @@
+/*
+ * Driver for the Diolan DLN-2 USB adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ * i2c-diolan-u2c.c
+ * Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"usb-dln2"
+
+struct dln2_header {
+ __le16 size;
+ __le16 id;
+ __le16 echo;
+ __le16 handle;
+} __packed;
+
+struct dln2_response {
+ struct dln2_header hdr;
+ __le16 result;
+} __packed;
+
+#define DLN2_GENERIC_MODULE_ID 0x00
+#define DLN2_GENERIC_CMD(cmd) DLN2_CMD(cmd, DLN2_GENERIC_MODULE_ID)
+#define CMD_GET_DEVICE_VER DLN2_GENERIC_CMD(0x30)
+#define CMD_GET_DEVICE_SN DLN2_GENERIC_CMD(0x31)
+
+#define DLN2_HW_ID 0x200
+#define DLN2_USB_TIMEOUT 200 /* in ms */
+#define DLN2_MAX_RX_SLOTS 16
+#define DLN2_MAX_MODULES 5
+#define DLN2_MAX_URBS 16
+
+#define DLN2_HANDLE_GPIO_EVENT 0
+#define DLN2_HANDLE_CTRL 1
+#define DLN2_HANDLE_GPIO 2
+#define DLN2_HANDLE_I2C3
+
+/* Receive context used between the receive demultiplexer and the
+ * transfer routine. While sending a request the transfer routine
+ * will look for a free receive context and use it to wait for a
+ * response and to receive the URB and thus the response data. */
+struct dln2_rx_context {
+ struct completion done;
+ struct urb *urb;
+ bool connected;
+};
+
+/* Receive contexts for a particular DLN2 module (i2c, gpio, etc.). We
+ * use the handle header field to indentify the module in
+ * dln2_dev.mod_rx_slots and then the echo header field to index the
+ * slots field and find the receive context for a particular
+ * request. */
+struct dln2_mod_rx_slots {
+ /* RX slots bitmap */
+ unsigned long bmap;
+
+ /* used to wait for a free RX slot */
+ wait_queue_head_t wq;
+
+ /* used to wait for an RX
Re: [3.16.1 REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16
On 5 Sep 2014, Oliver Neukum verbalised: > On Fri, 2014-09-05 at 00:40 +0100, Nix wrote: >> I'm working around this confusing morass by rebooting into each test >> kernel, unplugging and replugging the entropy key if it was fubared, >> then rebooting into the same kernel again and seeing if it was still >> fubared. But this is not terribly fast, particularly not on a headless >> compact-flash-based Geode box which doesn't even complete booting >> without the entropy source which this bug cuts off :) so it'll be >> sometime tomorrow before I can get this bisection done, I'm afraid. > > Ugh. My sympathies. I cannot suggest a better method, I am afraid. Well, that method doesn't work. I've found pairs of kernels (e.g. 59a3d4c3631e553357b7305dc09db1990aa6757c and b05d59dfceaea72565b1648af929b037b0f96d7f) where each kernel works on its own (rebooting from that kernel into the same kernel keeps a working key, so I would normally assume that each kernel is OK) but rebooting from the first into the second yields a broken one if it was working before (so one of them must, in fact, be broken, but I have no clue which one). So I can't figure out how to bisect this. Any suggestions as to what failure-test I might use, or what other methods I might use to figure out what's going wrong? Not knowing anything about USB doesn't help here. I don't know for sure that this is a cdc-acm problem -- bisecting just the cdc-acm driver was fruitless -- so it might be something more generally USBish. -- NULL && (void) -- 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/lkml/
Re: [PATCH v2] perf tools: Fix build-id matching on vmlinux
Hi Adrian and Arnaldo, 2014-09-05 (금), 11:11 -0300, Arnaldo Carvalho de Melo: > Em Fri, Sep 05, 2014 at 10:22:40AM +0300, Adrian Hunter escreveu: > > On 09/05/2014 07:59 AM, Namhyung Kim wrote: > > > +++ b/tools/perf/util/machine.c > > > @@ -1060,10 +1060,14 @@ static int > > > machine__process_kernel_mmap_event(struct machine *machine, > > > strlen(kmmap_prefix)); > > > /* > > >* Should be there already, from the build-id table in > > > - * the header. > > > + * the header (but maybe with a different name: "vmlinux"). > > >*/ > > > - struct dso *kernel = __dsos__findnew(>kernel_dsos, > > > - kmmap_prefix); > > > + struct dso *kernel = dsos__find(>kernel_dsos, > > > + "vmlinux", true); > > > Isn't "vmlinux" just the basename of the original file name, so if it had a > > different name this wouldn't work e.g. if the filename had been > > /boot/vmlinuz-3.11.0-26-generic then you would need > > "vmlinuz-3.11.0-26-generic" for this to work? > > Yeah, looking for well known pathnames to then check if the build-id > matches the one we're looking for, be it because we obtained it from > /sys/kernel/notes (for the running kernel), or from the perf.data file > build-id table is ok, as we don't know where it is. > > Plain sticking "vmlinux" there is not. I don't get it. AFAIK when perf record runs, it uses [kernel.kallsyms] name for kernel map. But it can be changed only if it found a "vmlinux" file in the vmlinux_path[]. So short name will always be "vmlinux" - okay, it might be vmlinux-$(uname -r) too; I can add it. As you know, the vmlinux file is a ELF image that created during kernel build process so I guess its name is fixed. It's different from the vmlinu"z" which resides in /boot directory. Am I missing something? Thanks, Namhyung -- 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/lkml/
Re: Possible race between CPU hotplug and perf_pmu_migrate_context
On Thu, Sep 04, 2014 at 12:07:40PM +0100, Mark Rutland wrote:
> Thanks for taking a look. If you have any ideas I'm happy to try another
> approach.
How horrible is the below patch (performance wise). It does pretty much
the same thing except that percpu_rw_semaphore is a lot saner, its
read side performance should be minimal in the absence of writes.
---
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1573,6 +1573,7 @@ config PERF_EVENTS
depends on HAVE_PERF_EVENTS
select ANON_INODES
select IRQ_WORK
+ select PERCPU_RWSEM
help
Enable kernel support for various performance events provided
by software and hardware.
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -3418,12 +3419,14 @@ static void perf_remove_from_owner(struc
}
}
+static struct percpu_rw_semaphore perf_rwsem;
+
/*
* Called when the last reference to the file is gone.
*/
static void put_event(struct perf_event *event)
{
- struct perf_event_context *ctx = event->ctx;
+ struct perf_event_context *ctx;
if (!atomic_long_dec_and_test(>refcount))
return;
@@ -3431,6 +3434,9 @@ static void put_event(struct perf_event
if (!is_kernel_event(event))
perf_remove_from_owner(event);
+ percpu_down_read(_rwsem);
+ ctx = event->ctx;
+
WARN_ON_ONCE(ctx->parent_ctx);
/*
* There are two ways this annotation is useful:
@@ -3447,6 +3453,7 @@ static void put_event(struct perf_event
mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
perf_remove_from_context(event, true);
mutex_unlock(>mutex);
+ percpu_up_read(_rwsem);
_free_event(event);
}
@@ -7534,6 +7541,8 @@ void perf_pmu_migrate_context(struct pmu
struct perf_event *event, *tmp;
LIST_HEAD(events);
+ percpu_down_write(_rwsem);
+
src_ctx = _cpu_ptr(pmu->pmu_cpu_context, src_cpu)->ctx;
dst_ctx = _cpu_ptr(pmu->pmu_cpu_context, dst_cpu)->ctx;
@@ -7559,6 +7568,8 @@ void perf_pmu_migrate_context(struct pmu
get_ctx(dst_ctx);
}
mutex_unlock(_ctx->mutex);
+
+ percpu_up_write(_rwsem);
}
EXPORT_SYMBOL_GPL(perf_pmu_migrate_context);
@@ -8198,6 +8209,7 @@ void __init perf_event_init(void)
idr_init(_idr);
+ percpu_init_rwsem(_rwsem);
perf_event_init_all_cpus();
init_srcu_struct(_srcu);
perf_pmu_register(_swevent, "software", PERF_TYPE_SOFTWARE);
--
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/lkml/
Re: [PATCH] KVM: x86: fix kvmclock breakage from timers branch merge
On Thu, 4 Sep 2014, Paolo Bonzini wrote: > Il 04/09/2014 22:58, Thomas Gleixner ha scritto: > > This is simply wrong. > > It is. > > > Now I have no idea why you think it needs to add xtime_sec. If the > > result is wrong, then we need to figure out which one of the supplied > > values is wrong and not blindly add xtime_sec just because that makes > > it magically correct. > > > > Can you please provide a proper background why you think that adding > > xtime_sec is a good idea? > > It's not a good idea indeed. I didn't fully digest the 3.16->3.17 > timekeeping changes and messed up this patch. > > However, there is a bug in the "base_mono + offs_boot" formula, given > that: > > - bisection leads to the merge commit of John's timers branch > > - bisecting within John's timers branch, with a KVM commit on top to > make the code much easier to trigger, leads to commit cbcf2dd3b3d4 > (x86: kvm: Make kvm_get_time_and_clockread() nanoseconds based, > 2014-07-16). > > - I backported your patch to 3.16, using wall_to_monotonic + > total_sleep_time + xtime_sec (wtm+xtime_sec as in pre-cbcf2dd3b3d4 > code, total_sleep_time from 3.16 monotonic_to_bootbased) and it works > > - In v2 of the patch I fixed the bug by changing the formula > "base_mono + offs_boot" to "offs_boot - offs_real" (and then adding > xtime_sec separately as in the 3.16 backport), but the two formulas > "base_mono + offs_boot" and "offs_boot - offs_real + xtime_sec" ought > to be identical. So lets look at the differences here: 3.163.17 inject_sleeptime(delta) inject_sleeptime(delta) xtime += delta; xtime += delta; wall_to_mono -= delta; wall_to_mono -= delta; offs_real = -wall_to_mono; offs_real = -wall_to_mono; sleeptime += delta; offs_boot = sleeptime; offs_boot += delta; getboottime() tmp = wall_to_mono + sleeptime; boottime = -tmp; So: boottime = -wall_to_mono - sleeptime; Because of the above: offs_real = -wall_to_mono; offs_boot = sleeptime; The result is: boottime = offs_real - offs_boot; boottime = offs_real - offs_boot; monotomic_to_bootbased(mono)monotomic_to_bootbased(mono) return mono + sleeptime; Because of the above: offs_boot = sleeptime; The result is: return mono + offs_boot; return mono + offs_boot; Now on KVM side he have update_pvclock_gtod() update_pvclock_gtod() mono_base = xtime + wall_to_mono; boot_base = mono_base + offs_boot; and do_monotonic() do_monotonic_boot() mono_now = mono_base + delta_ns; boot_now = boot_base + delta_ns; kvm_get_time_and_clockread() mono_now = do_monotonic() boot_now = mono_to_boot(mono_now); So that means on both side the same: boot_now = mono_base + offs_boot + delta_ns; So that means the code is correct. Now where is the bug? Well hidden and still so obvious that it's even visible through the brown paperpag I'm wearing ... Thanks, tglx diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index fb4a9c2cf8d9..ec1791fae965 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -442,11 +442,12 @@ static void timekeeping_update(struct timekeeper *tk, unsigned int action) tk->ntp_error = 0; ntp_clear(); } - update_vsyscall(tk); - update_pvclock_gtod(tk, action & TK_CLOCK_WAS_SET); tk_update_ktime_data(tk); + update_vsyscall(tk); + update_pvclock_gtod(tk, action & TK_CLOCK_WAS_SET); + if (action & TK_MIRROR) memcpy(_timekeeper, _core.timekeeper, sizeof(tk_core.timekeeper)); -- 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/lkml/
pull request: wireless 2014-09-05
Dave, Please pull this batch of fixes intended for the 3.17 stream... For the mac80211 bits, Johannes says: "Here are a few fixes for mac80211. One has been discussed for a while and adds a terminating NUL-byte to the alpha2 sent to userspace, which shouldn't be necessary but since many places treat it as a string we couldn't move to just sending two bytes. In addition to that, we have two VLAN fixes from Felix, a mesh fix, a fix for the recently introduced RX aggregation offload, a revert for a broken patch (that luckily didn't really cause any harm) and a small fix for alignment in debugfs." For the iwlwifi bits, Emmanuel says: "I revert a patch that disabled CTS to self in dvm because users reported issues. The revert is CCed to stable since the offending patch was sent to stable too. I also bump the firmware API versions since a new firmware is coming up. On top of that, Marcel fixes a bug I introduced while fixing a bug in our Kconfig file." Please let me know if there are problems! Thanks, John --- The following changes since commit c66517165610b911e4c6d268f28d8c640832dbd1: rtlwifi: rtl8192cu: Add new ID (2014-08-25 15:39:23 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git tags/master-2014-09-04 for you to fetch changes up to 1bd3fa7b8c9b2936c16c6e6452f9cc991c405872: Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2014-09-04 13:12:02 -0400) Bob Copeland (1): mac80211: mesh_plink: handle confirm frames with new plid Denton Gentry (1): mac80211: fix start_seq_num in Rx reorder offload Eliad Peller (1): regulatory: add NUL to alpha2 Emmanuel Grumbach (2): Revert "iwlwifi: dvm: don't enable CTS to self" iwlwifi: bump firmware API version to 10 for 7000 and 8000 Felix Fietkau (2): mac80211: ignore AP_VLAN in ieee80211_recalc_chanctx_chantype mac80211: fix smps mode check for AP_VLAN Johannes Berg (2): Revert "mac80211: disable uAPSD if all ACs are under ACM" mac80211: fix agg_status debugfs file alignment John W. Linville (2): Merge tag 'mac80211-for-john-2014-08-29' of git://git.kernel.org/.../jberg/mac80211 Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes Marcel Holtmann (1): iwlwifi: Remove module build requirement for Intel Wireless WiFi drivers/net/wireless/iwlwifi/Kconfig| 2 -- drivers/net/wireless/iwlwifi/dvm/rxon.c | 12 drivers/net/wireless/iwlwifi/iwl-7000.c | 4 ++-- drivers/net/wireless/iwlwifi/iwl-8000.c | 2 +- include/net/regulatory.h| 2 +- net/mac80211/chan.c | 2 ++ net/mac80211/debugfs_sta.c | 2 +- net/mac80211/iface.c| 4 ++-- net/mac80211/mesh_plink.c | 7 ++- net/mac80211/mlme.c | 3 +-- net/mac80211/sta_info.c | 7 +-- 11 files changed, 33 insertions(+), 14 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/Kconfig b/drivers/net/wireless/iwlwifi/Kconfig index 6451d2b6abcf..824f5e287783 100644 --- a/drivers/net/wireless/iwlwifi/Kconfig +++ b/drivers/net/wireless/iwlwifi/Kconfig @@ -51,7 +51,6 @@ config IWLWIFI_LEDS config IWLDVM tristate "Intel Wireless WiFi DVM Firmware support" - depends on m default IWLWIFI help This is the driver that supports the DVM firmware which is @@ -60,7 +59,6 @@ config IWLDVM config IWLMVM tristate "Intel Wireless WiFi MVM Firmware support" - depends on m help This is the driver that supports the MVM firmware which is currently only available for 7260 and 3160 devices. diff --git a/drivers/net/wireless/iwlwifi/dvm/rxon.c b/drivers/net/wireless/iwlwifi/dvm/rxon.c index 6dc5dd3ced44..ed50de6362ed 100644 --- a/drivers/net/wireless/iwlwifi/dvm/rxon.c +++ b/drivers/net/wireless/iwlwifi/dvm/rxon.c @@ -1068,6 +1068,13 @@ int iwlagn_commit_rxon(struct iwl_priv *priv, struct iwl_rxon_context *ctx) /* recalculate basic rates */ iwl_calc_basic_rates(priv, ctx); + /* +* force CTS-to-self frames protection if RTS-CTS is not preferred +* one aggregation protection method +*/ + if (!priv->hw_params.use_rts_for_aggregation) + ctx->staging.flags |= RXON_FLG_SELF_CTS_EN; + if ((ctx->vif && ctx->vif->bss_conf.use_short_slot) || !(ctx->staging.flags & RXON_FLG_BAND_24G_MSK)) ctx->staging.flags |= RXON_FLG_SHORT_SLOT_MSK; @@ -1473,6 +1480,11 @@ void iwlagn_bss_info_changed(struct ieee80211_hw *hw, else ctx->staging.flags &= ~RXON_FLG_TGG_PROTECT_MSK; + if (bss_conf->use_cts_prot) + ctx->staging.flags |= RXON_FLG_SELF_CTS_EN; + else + ctx->staging.flags
Re: [PATCH 1/5] x86, mm, pat: Set WT to PA4 slot of PAT MSR
On 09/05/2014 07:00 AM, Toshi Kani wrote: > > That's a fine idea, but as Ingo also suggested, I am going to disable > this feature on all Pentium 4 models. That should give us a safety > margin. Using slot 4 has a benefit that it keeps the PAT setup > consistent with Xen. > Slot 4 is also the maximally problematic one, because it is the one that might be incorrectly invoked for the page tables themselves. -hpa -- 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/lkml/
[PATCH 3/3] dmaengine: pl330: Fix NULL pointer dereference on driver unbind
Fix a NULL pointer dereference after unbinding the driver, if channel
resources were not yet allocated (no call to
pl330_alloc_chan_resources()):
$ echo 1285.mdma > /sys/bus/amba/drivers/dma-pl330/unbind
[ 13.606533] DMA pl330_control: removing pch: eeab6800, chan: eeab6814,
thread: (null)
[ 13.614472] Unable to handle kernel NULL pointer dereference at virtual
address 000c
[ 13.622537] pgd = ee284000
[ 13.625228] [000c] *pgd=6e1e4831, *pte=, *ppte=
[ 13.631482] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 13.636859] Modules linked in:
[ 13.639903] CPU: 0 PID: 1 Comm: sh Not tainted
3.17.0-rc3-next-20140904-4-g7020ffc33ca3-dirty #420
[ 13.649187] task: ee80a800 ti: ee888000 task.ti: ee888000
[ 13.654589] PC is at _stop+0x8/0x2c8
[ 13.658131] LR is at pl330_control+0x70/0x2e8
[ 13.662468] pc : []lr : []psr: 6093
[ 13.662468] sp : ee889e58 ip : 0001 fp : 000bab70
[ 13.673922] r10: eeab6814 r9 : ee16debc r8 :
[ 13.679131] r7 : eeab685c r6 : 6013 r5 : ee16de10 r4 : eeab6800
[ 13.685641] r3 : 0002 r2 : r1 : 0001 r0 :
[ 13.692153] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment
user
[ 13.699357] Control: 10c5387d Table: 6e28404a DAC: 0015
[ 13.705085] Process sh (pid: 1, stack limit = 0xee888240)
[ 13.710466] Stack: (0xee889e58 to 0xee88a000)
[ 13.714808] 9e40:
0002 eeab6800
[ 13.722969] 9e60: ee16de10 eeab6800 ee16de10 6013 eeab685c c020649c
c040280c
[ 13.731128] 9e80: ee889e80 ee889e80 ee16de18 ee16de10 eeab6880 eeab6814
00200200 eeab68a8
[ 13.739287] 9ea0: 00100100 c0208048 c0409fc4 eea80800 eea808f8
c0605c44 000e
[ 13.747446] 9ec0: 000e eeb3960c eeb39600 c0203c48 eea80800 c0605c44
c0605a8c c023f694
[ 13.755605] 9ee0: ee80a800 eea80834 eea80800 c023f704 ee80a800 eea80800
c0605c44 c023e8ec
[ 13.763764] 9f00: 000e ee149780 ee29e580 ee889f80 ee29e580 c023e19c
000e c01167e4
[ 13.771923] 9f20: c01167a0 c0115e88
ee0b1a00 000e
[ 13.780082] 9f40: b6f48000 ee889f80 000e ee888000 b6f48000 c00bfadc
0003
[ 13.788241] 9f60: ee0b1a00 ee0b1a00 000e
b6f48000 c00bfdf4
[ 13.796401] 9f80: 000e b6f48000 b6edc5d0
0004 c000e7a4
[ 13.804560] 9fa0: c000e620 000e b6f48000 0001 b6f48000
000e
[ 13.812719] 9fc0: 000e b6f48000 b6edc5d0 0004 000e b6f4c8c0
000c3470 000bab70
[ 13.820879] 9fe0: bed2aa50 b6e18bdc b6e6b52c 6010 0001
c0c0c0c0 c0c0c0c0
[ 13.829058] [] (_stop) from [] (pl330_control+0x70/0x2e8)
[ 13.836165] [] (pl330_control) from []
(pl330_remove+0xb0/0xdc)
[ 13.843800] [] (pl330_remove) from []
(amba_remove+0x24/0xc0)
[ 13.851272] [] (amba_remove) from []
(__device_release_driver+0x70/0xc4)
[ 13.859685] [] (__device_release_driver) from []
(device_release_driver+0x1c/0x28)
[ 13.868971] [] (device_release_driver) from []
(unbind_store+0x58/0x90)
[ 13.877303] [] (unbind_store) from []
(drv_attr_store+0x20/0x2c)
[ 13.885036] [] (drv_attr_store) from []
(sysfs_kf_write+0x44/0x48)
[ 13.892928] [] (sysfs_kf_write) from []
(kernfs_fop_write+0xc0/0x17c)
[ 13.901090] [] (kernfs_fop_write) from []
(vfs_write+0xa0/0x1a8)
[ 13.908812] [] (vfs_write) from [] (SyS_write+0x40/0x8c)
[ 13.915850] [] (SyS_write) from []
(ret_fast_syscall+0x0/0x30)
[ 13.923392] Code: e5813010 e12fff1e e92d40f0 e24dd00c (e590200c)
[ 13.929467] ---[ end trace 10064e15a5929cf8 ]---
Terminate the thread and free channel resource only if channel resources
were allocated (thread is not NULL).
Signed-off-by: Krzysztof Kozlowski
Cc:
Fixes: b3040e40675e ("DMA: PL330: Add dma api driver")
---
drivers/dma/pl330.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 04c2f39227f1..66e89f04504c 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2785,8 +2785,10 @@ static int pl330_remove(struct amba_device *adev)
list_del(>chan.device_node);
/* Flush the channel */
- pl330_control(>chan, DMA_TERMINATE_ALL, 0);
- pl330_free_chan_resources(>chan);
+ if (pch->thread) {
+ pl330_control(>chan, DMA_TERMINATE_ALL, 0);
+ pl330_free_chan_resources(>chan);
+ }
}
pl330_del(pl330);
--
1.9.1
--
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/lkml/
[RFC PATCH] dma: pl330: add Power Management support
This patch adds both normal PM suspend/resume support and runtime PM
support to pl330 DMA engine driver.
The runtime power management for pl330 DMA driver allows gating of AMBA
clock (PDMA) in FSYS clock domain, when the device is not processing any
requests. This is necessary to enter W-AFTR low power mode on Exynos3250.
The patch is based on previous work of Bartlomiej Zolnierkiewicz
.
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma/pl330.c | 78 ++---
1 file changed, 74 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 66e89f04504c..bdc6ff8ee2bf 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "dmaengine.h"
#define PL330_MAX_CHAN 8
@@ -1966,6 +1967,7 @@ static void pl330_tasklet(unsigned long data)
struct dma_pl330_chan *pch = (struct dma_pl330_chan *)data;
struct dma_pl330_desc *desc, *_dt;
unsigned long flags;
+ bool power_down = false;
spin_lock_irqsave(>lock, flags);
@@ -1980,10 +1982,17 @@ static void pl330_tasklet(unsigned long data)
/* Try to submit a req imm. next to the last completed cookie */
fill_queue(pch);
- /* Make sure the PL330 Channel thread is active */
- spin_lock(>thread->dmac->lock);
- _start(pch->thread);
- spin_unlock(>thread->dmac->lock);
+ if (list_empty(>work_list)) {
+ spin_lock(>thread->dmac->lock);
+ _stop(pch->thread);
+ spin_unlock(>thread->dmac->lock);
+ power_down = true;
+ } else {
+ /* Make sure the PL330 Channel thread is active */
+ spin_lock(>thread->dmac->lock);
+ _start(pch->thread);
+ spin_unlock(>thread->dmac->lock);
+ }
while (!list_empty(>completed_list)) {
dma_async_tx_callback callback;
@@ -1998,6 +2007,12 @@ static void pl330_tasklet(unsigned long data)
if (pch->cyclic) {
desc->status = PREP;
list_move_tail(>node, >work_list);
+ if (power_down) {
+ spin_lock(>thread->dmac->lock);
+ _start(pch->thread);
+ spin_unlock(>thread->dmac->lock);
+ power_down = false;
+ }
} else {
desc->status = FREE;
list_move_tail(>node, >dmac->desc_pool);
@@ -2012,6 +2027,10 @@ static void pl330_tasklet(unsigned long data)
}
}
spin_unlock_irqrestore(>lock, flags);
+
+ /* If work list empty, power down */
+ if (power_down)
+ pm_runtime_put(pch->dmac->ddma.dev);
}
bool pl330_filter(struct dma_chan *chan, void *param)
@@ -2077,10 +2096,12 @@ static int pl330_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd, unsigned
unsigned long flags;
struct pl330_dmac *pl330 = pch->dmac;
struct dma_slave_config *slave_config;
+ bool power_down = false;
LIST_HEAD(list);
switch (cmd) {
case DMA_TERMINATE_ALL:
+ pm_runtime_get_sync(pl330->ddma.dev);
spin_lock_irqsave(>lock, flags);
spin_lock(>lock);
@@ -2107,10 +2128,18 @@ static int pl330_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd, unsigned
dma_cookie_complete(>txd);
}
+ if (!list_empty(>work_list))
+ power_down = true;
+
list_splice_tail_init(>submitted_list, >desc_pool);
list_splice_tail_init(>work_list, >desc_pool);
list_splice_tail_init(>completed_list, >desc_pool);
spin_unlock_irqrestore(>lock, flags);
+ pm_runtime_put(pl330->ddma.dev);
+
+ /* If work list empty, power down */
+ if (power_down)
+ pm_runtime_put(pl330->ddma.dev);
break;
case DMA_SLAVE_CONFIG:
slave_config = (struct dma_slave_config *)arg;
@@ -2146,6 +2175,7 @@ static void pl330_free_chan_resources(struct dma_chan
*chan)
tasklet_kill(>task);
+ pm_runtime_get_sync(pch->dmac->ddma.dev);
spin_lock_irqsave(>lock, flags);
pl330_release_channel(pch->thread);
@@ -2155,6 +2185,7 @@ static void pl330_free_chan_resources(struct dma_chan
*chan)
list_splice_tail_init(>work_list, >dmac->desc_pool);
spin_unlock_irqrestore(>lock, flags);
+ pm_runtime_put(pch->dmac->ddma.dev);
}
static enum dma_status
@@ -2168,11 +2199,23 @@ static void pl330_issue_pending(struct dma_chan *chan)
{
struct dma_pl330_chan *pch = to_pchan(chan);
unsigned long flags;
+ bool power_up;
Re: [PATCH] kernel: add support for gcc 5
On 09/04/2014 02:25 PM, Andrew Morton wrote: >> >> CC'ing Hannes, he sent a much simpler gcc5 patch a few days ago. >> https://lkml.org/lkml/2014/8/26/710 > > That approach won't last for long - as soon as we add some > gcc5-specific thing, we'll need a new file. > > Let history be a guide: > > diff -u include/linux/compiler-gcc3.h include/linux/compiler-gcc4.h It seems much saner to do that branching when we actually need to. In the meantime I suspect that a handful of redefinitions would actually be cleaner. -hpa -- 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/lkml/
[PATCH 1/3] dmaengine: pl330: Do not dereference pl330_thread pointer before non-NULL check
Do not dereference the 'struct pl330_thread *thrd' before the check for
non-NULL value.
This fixes following warning:
drivers/dma/pl330.c:1376 pl330_submit_req() warn: variable dereferenced before
check 'thrd' (see line 1367)
Signed-off-by: Krzysztof Kozlowski
---
drivers/dma/pl330.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index d5149aacd2fe..47d82070848d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1364,7 +1364,7 @@ static inline u32 _prepare_ccr(const struct pl330_reqcfg
*rqc)
static int pl330_submit_req(struct pl330_thread *thrd,
struct dma_pl330_desc *desc)
{
- struct pl330_dmac *pl330 = thrd->dmac;
+ struct pl330_dmac *pl330;
struct _xfer_spec xs;
unsigned long flags;
void __iomem *regs;
@@ -1376,6 +1376,7 @@ static int pl330_submit_req(struct pl330_thread *thrd,
if (!desc || !thrd || thrd->free)
return -EINVAL;
+ pl330 = thrd->dmac;
regs = thrd->dmac->base;
if (pl330->state == DYING
--
1.9.1
--
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/lkml/
[PATCH 2/3] dmaengine: pl330: Fix NULL pointer dereference on probe failure
If dma_async_device_register() returns error and probe should clean up
and return error, a NULL pointer exception happens because of
dereference of not allocated channel thread:
Dmesg log (from early printk):
dma-pl330 1268.pdma: unable to register DMAC
DMA pl330_control: removing pch: eeac4000, chan: eeac4014, thread: (null)
Unable to handle kernel NULL pointer dereference at virtual address 000c
pgd = c0004000
[000c] *pgd=
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 2 PID: 1 Comm: swapper/0 Not tainted
3.17.0-rc3-next-20140904-5-g6cc4c1937d90-dirty #427
task: ee80a800 ti: ee888000 task.ti: ee888000
PC is at _stop+0x8/0x2c8
LR is at pl330_control+0x70/0x2e8
pc : []lr : []psr: 6193
sp : ee889df8 ip : 0002 fp :
r10: eeac4014 r9 : ee0e62bc r8 :
r7 : eeac405c r6 : 6113 r5 : ee0e6210 r4 : eeac4000
r3 : 0002 r2 : 0002 r1 : 0001 r0 :
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 4000404a DAC: 0015
Process swapper/0 (pid: 1, stack limit = 0xee888240)
Stack: (0xee889df8 to 0xee88a000)
9de0: 0002 eeac4000
9e00: ee0e6210 eeac4000 ee0e6210 6113 eeac405c c020623c c020725c
9e20: ee889e20 ee889e20 ee0e6210 eeac4080 00200200 00100100 eeac4014 0020
9e40: ee0e6218 c0208374 ee9bb340 ee0e6210 c0605cd8
9e60: ee97 c0605c84 ee9700f8 c05c4270 c0203b3c
9e80: ee97 c06624a8 c0605c84 c023f890 ee97 c0605c84
9ea0: ee970034 c05b23d0 c023fa3c c0605c84 c023f9b0 c023e0d4
9ec0: ee947e78 ee9b9440 c0605c84 eea1e780 c0605acc c023f094 c0513b50 c0605c84
9ee0: c05ecbd8 c0605c84 c05ecbd8 ee11ba40 c0626500 c0240064 c05ecbd8
9f00: c05ecbd8 c0008964 c040f13c 009f c0626500 c057465c ee80a800 6113
9f20: c05efdb0 6113 ef7fc89d c0421168 008f c003787c
9f40: c0573d6c 0006 ef7fc8bb 0006 c05efd50 ef7fc800 c05dfbc4 0006
9f60: c05c4264 c0626500 008f c05c4270 c059b518 c059bcb4 0006 0006
9f80: c059b518 c003c08c c040091c
9fa0: c0400924 c000e7b8
9fc0:
9fe0: 0013 c0c0c0c0 c0c0c0c0
[] (_stop) from [] (pl330_control+0x70/0x2e8)
[] (pl330_control) from [] (pl330_probe+0x594/0x75c)
[] (pl330_probe) from [] (amba_probe+0xb8/0x120)
[] (amba_probe) from [] (driver_probe_device+0x10c/0x22c)
[] (driver_probe_device) from [] (__driver_attach+0x8c/0x90)
[] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
[] (bus_for_each_dev) from [] (bus_add_driver+0xd4/0x1d0)
[] (bus_add_driver) from [] (driver_register+0x78/0xf4)
[] (driver_register) from [] (do_one_initcall+0x80/0x1d0)
[] (do_one_initcall) from []
(kernel_init_freeable+0x108/0x1d4)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
[] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
Code: e5813010 e12fff1e e92d40f0 e24dd00c (e590200c)
---[ end trace c94b2f4f38dff3bf ]---
This happens because the necessary resources were not yet allocated - no
call to pl330_alloc_chan_resources().
Terminate the thread and free channel resource only if channel thread is not
NULL.
Signed-off-by: Krzysztof Kozlowski
Cc:
Fixes: 0b94c5771705 ("DMA: PL330: Add check if device tree compatible")
---
drivers/dma/pl330.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 47d82070848d..04c2f39227f1 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2756,8 +2756,10 @@ probe_err3:
list_del(>chan.device_node);
/* Flush the channel */
- pl330_control(>chan, DMA_TERMINATE_ALL, 0);
- pl330_free_chan_resources(>chan);
+ if (pch->thread) {
+ pl330_control(>chan, DMA_TERMINATE_ALL, 0);
+ pl330_free_chan_resources(>chan);
+ }
}
probe_err2:
pl330_del(pl330);
--
1.9.1
--
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/lkml/
Re: [PATCH 3.10.y+] PM / sleep: Use valid_state() for platform-dependent sleep states only
On 09/05/2014 09:45 AM, Brian Norris wrote: > On Fri, Sep 05, 2014 at 08:29:09AM +0200, Francis Moreau wrote: >> On 09/04/2014 11:21 PM, Brian Norris wrote: > [...] >>> Signed-off-by: Rafael J. Wysocki >>> Cc: # 3.10+: 27ddcc6596e5: PM / sleep: Add state >>> field to pm_states[] entries >>> Cc: # 3.10+ >>> --- >>> This is a backport request for these two commits upstream: >>> >>> 27ddcc6596e5 PM / sleep: Add state field to pm_states[] entries >>> 43e8317b0bba PM / sleep: Use valid_state() for platform-dependent sleep >>> states only >>> >> >> Wouldn't it be cleaner to have 2 separate backports then ? > > The first is purely a dependency for the second. It has no value on its > own. So I thought the above form made sense and followed the process > mentioned in Documentation/stable_kernel_rules.txt. > > Admittedly, it's a little asymmetric. But I really don't know what the > "best" option is, since I'd prefer not having to send around any patch > text at all, unless the backport is not trivial (these apply cleanly). I don't know, I just find cleaner to cherry-pick upstream commits when possible so I can retrieve them easily later when inspecting a stable kernel. My 2 cents. -- 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/lkml/
Re: regression caused by cgroups optimization in 3.17-rc2
On Fri, Sep 05, 2014 at 11:25:37AM +0200, Michal Hocko wrote:
> @@ -900,10 +900,10 @@ void lru_add_drain_all(void)
> * grabbed the page via the LRU. If it did, give up: shrink_inactive_list()
> * will free it.
> */
> -void release_pages(struct page **pages, int nr, bool cold)
> +static void release_lru_pages(struct page **pages, int nr,
> + struct list_head *pages_to_free)
> {
> int i;
> - LIST_HEAD(pages_to_free);
> struct zone *zone = NULL;
> struct lruvec *lruvec;
> unsigned long uninitialized_var(flags);
> @@ -943,11 +943,26 @@ void release_pages(struct page **pages, int nr, bool
> cold)
> /* Clear Active bit in case of parallel mark_page_accessed */
> __ClearPageActive(page);
>
> - list_add(>lru, _to_free);
> + list_add(>lru, pages_to_free);
> }
> if (zone)
> spin_unlock_irqrestore(>lru_lock, flags);
> +}
> +/*
> + * Batched page_cache_release(). Frees and uncharges all given pages
> + * for which the reference count drops to 0.
> + */
> +void release_pages(struct page **pages, int nr, bool cold)
> +{
> + LIST_HEAD(pages_to_free);
>
> + while (nr) {
> + int batch = min(nr, PAGEVEC_SIZE);
> +
> + release_lru_pages(pages, batch, _to_free);
> + pages += batch;
> + nr -= batch;
> + }
We might be able to process a lot more pages in one go if nobody else
needs the lock or the CPU. Can't we just cycle the lock or reschedule
if necessary?
diff --git a/mm/swap.c b/mm/swap.c
index 6b2dc3897cd5..ee0cf21dd521 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -944,6 +944,15 @@ void release_pages(struct page **pages, int nr, bool cold)
__ClearPageActive(page);
list_add(>lru, _to_free);
+
+ if (should_resched() ||
+ (zone && spin_needbreak(>lru_lock))) {
+ if (zone) {
+ spin_unlock_irqrestore(>lru_lock, flags);
+ zone = NULL;
+ }
+ cond_resched();
+ }
}
if (zone)
spin_unlock_irqrestore(>lru_lock, flags);
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 3e0ec83d000c..c487ca4682a4 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -262,19 +262,12 @@ void free_page_and_swap_cache(struct page *page)
*/
void free_pages_and_swap_cache(struct page **pages, int nr)
{
- struct page **pagep = pages;
+ int i;
lru_add_drain();
- while (nr) {
- int todo = min(nr, PAGEVEC_SIZE);
- int i;
-
- for (i = 0; i < todo; i++)
- free_swap_cache(pagep[i]);
- release_pages(pagep, todo, false);
- pagep += todo;
- nr -= todo;
- }
+ for (i = 0; i < nr; i++)
+ free_swap_cache(pages[i]);
+ release_pages(pages, nr, false);
}
/*
--
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/lkml/
[PATCH] ARM: at91/dt: rm9200: fix usb clock definition
The atmel,clk-divisors property is taking 4 divisors, if less are
provided, the clock registration will fail.
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/dts/at91rm9200.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
b/arch/arm/boot/dts/at91rm9200.dtsi
index 65ccf564b9a5..6c97d4af61ee 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -149,7 +149,7 @@
usb: usbck {
compatible = "atmel,at91rm9200-clk-usb";
#clock-cells = <0>;
- atmel,clk-divisors = <1 2>;
+ atmel,clk-divisors = <1 2 0 0>;
clocks = <>;
};
--
1.9.1
--
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/lkml/
[PATCHv3 3/4] ARM: at91/tclib: mask interruptions at shutdown and probe
Shutdown properly the timer counter block by masking interruptions. Otherwise, a segmentation may happen when kexec-ing a new kernel (see backtrace below). An interruption may happen before the handler is set, leading to a kernel segmentation fault. Furthermore, we make sure the interruptions are masked when the driver is initialized. This will prevent freshly kexec-ed kernel from crashing when launched from a kernel which does not properly mask interruptions at shutdown. The backtrace below happened after kexec-ing a new kernel, from a kernel that did not shut down properly leaving interruptions unmasked. Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 8005 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0+ #144 task: c1828aa0 ti: c182a000 task.ti: c182a000 PC is at 0x0 LR is at ch2_irq+0x28/0x30 pc : [<>]lr : []psr: 00d3 sp : c182bd38 ip : c182bd48 fp : c182bd44 r10: c0373390 r9 : c1825b00 r8 : 6053 r7 : r6 : r5 : 0013 r4 : c036e800 r3 : r2 : 2004 r1 : c036e760 r0 : c036e760 Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 20004000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc182a1c0) Stack: (0xc182bd38 to 0xc182c000) bd20: c182bd7c c182bd48 bd40: c0045430 c01db8ec c18c6f40 c182bd74 c1825b00 c035cec4 bd60: c182be2c 6053 c1825b34 c182bd94 c182bd80 c0045570 c0045408 bd80: c1825b00 c182bdac c182bd98 c0047f34 c0045550 0013 c036619c bda0: c182bdc4 c182bdb0 c0044da4 c0047e98 007f 0013 c182bde4 c182bdc8 bdc0: c0009e34 c0044d8c fefff000 c0046728 6053 c182bdf4 c182bde8 bde0: c00086a8 c0009ddc c182be74 c182bdf8 c000cb80 c0008674 0013 be00: 00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34 be20: c182be74 c182be20 c182be40 c0047994 c0046728 6053 be40: 0013 c036e800 c182be64 c1825b00 0013 c036e800 c035ed98 c03874bc be60: 0004 c036e700 c182be94 c182be78 c004689c c0046398 c036e760 c18c6080 be80: c035ed10 c182bedc c182be98 c0348b08 c004684c 000c c034dac8 bea0: 004c4b3f c028c338 c036e760 0013 c014ecc8 c18e67e0 c035b9c0 c0348884 bec0: c035b9c0 c182a020 c182bf54 c182bee0 c00089fc c0348894 bee0: c00da51c c1ffcc78 c182bf0c c182bef8 c002d100 c002d09c c1ffcc78 bf00: c182bf54 c182bf10 c002d308 c0336570 c182bf3c c0334e44 0003 0003 bf20: 0030 c0334b44 c0044d74 0003 0003 c034dac8 c0350a94 c0373440 bf40: c0373440 0030 c182bf94 c182bf58 c0336d24 c000890c 0003 0003 bf60: c0336560 c182bf64 c182bf64 6e616e0d c0272fc8 bf80: c182bfac c182bf98 c0272fd8 c0336bd8 c182a000 bfa0: c182bfb0 c00095d0 c0272fd8 bfc0: bfe0: 0013 374d27cd 33cc33e4 Backtrace: [] (ch2_irq) from [] (handle_irq_event_percpu+0x38/0x148) [] (handle_irq_event_percpu) from [] (handle_irq_event+0x30/0x40) r10: r9:c1825b34 r8:6053 r7:c182be2c r6: r5:c035cec4 r4:c1825b00 [] (handle_irq_event) from [] (handle_fasteoi_irq+0xac/0x11c) r4:c1825b00 r3: [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x28/0x38) r5:c036619c r4:0013 [] (generic_handle_irq) from [] (handle_IRQ+0x68/0x88) r4:0013 r3:007f [] (handle_IRQ) from [] (at91_aic_handle_irq+0x44/0x4c) r6: r5:6053 r4:c0046728 r3:fefff000 [] (at91_aic_handle_irq) from [] (__irq_svc+0x40/0x4c) Exception stack(0xc182bdf8 to 0xc182be40) bde0: 0013 be00: 00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34 be20: c182be74 c182be20 c182be40 c0047994 c0046728 6053 [] (__setup_irq) from [] (setup_irq+0x60/0x8c) r10:c036e700 r9:0004 r8:c03874bc r7:c035ed98 r6:c036e800 r5:0013 r4:c1825b00 [] (setup_irq) from [] (tcb_clksrc_init+0x284/0x31c) r6:c035ed10 r5: r4:c18c6080 r3:c036e760 [] (tcb_clksrc_init) from [] (do_one_initcall+0x100/0x1b4) r10: r9: r8:c182a020 r7:c035b9c0 r6:c0348884 r5:c035b9c0 r4:c18e67e0 [] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x224) r9:0030 r8:c0373440 r7:c0373440 r6:c0350a94 r5:c034dac8 r4:0003 [] (kernel_init_freeable) from [] (kernel_init+0x10/0xec) r9: r8: r7: r6: r5:c0272fc8 r4: [] (kernel_init) from [] (ret_from_fork+0x14/0x24) r4: r3:c182a000 Code: bad PC value ---[ end trace 5b30f0017e282e47 ]--- Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Gaël PORTAY Signed-off-by: Boris Brezillon
Re: [PATCH] kernel: add support for gcc 5
On 09/05/2014 12:08 AM, Hannes Frederic Sowa wrote: > On Do, 2014-09-04 at 23:37 -0400, Sasha Levin wrote: >> > On 09/04/2014 07:47 PM, Joe Perches wrote: >>> > > On Fri, 2014-09-05 at 00:43 +0200, Hannes Frederic Sowa wrote: > > >> > Most statements are already depending on GCC_VERSION, maybe we can > > >> > just > > >> > unify all gcc specific headers to one, still trying to keep the > > >> > file > > >> > organized? ;) >>> > > Maybe something like: >>> > > >>> > > gnu development of gcc will be more frequent and the use of >>> > > compiler-gcc.h likely will not be convenient anymore. >>> > > >>> > > Integrate the individual compiler-gcc.h files into >>> > > compiler-gcc.h. >> > >> > Please no. We have a similar file we maintain in our team that's supposed >> > to >> > do something very similar for kernel versions. It goes all the way back to >> > 2.6.9 and it's a *horrible* mess. >> > >> > This is how compiler-gcc.h will end up looking in a while. > Something along these lines? We can make '4' a macro describing it > references the latest possible compiler-gccX.h file. I agree, something along those lines would be great. We'd still have all this mess split into smaller headers and we won't be forced to add compiler-gccX.h until we actually need it. The problem it causes is that if you want to figure out what specific line of code in one of those headers affects your kernel you may need to browse through multiple headers (-gcc3.h ... -gccX.h) but I suspect that we won't have too many conflicting declarations, as Joe pointed out - they are mostly upward compatible. Thanks, Sasha -- 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/lkml/
Re: [GIT PULL] bcache changes for 3.17
On 09/05/2014 04:17 PM, Jens Axboe wrote: > > We need to do something about this. From this latest pull, looks like > all should go to stable: > > 5b1016e62f74c53e0330403025954c8d95384c03 > 9aa61a992acceeec0d1de2cd99938421498659d5 > dbd810ab678d262d3772d29b65844d7b20dc47bc > 8b326d3a2a76912dfed2f0ab937d59fae9512ca2 > e5112201c1285841f8b565ece5d6ae7e0d7947a2 > a664d0f05a2ec02c8f042db536d84d15d6e19e81 > c5aa4a3157b55bdca18dd2a9d9f43314470b6d32 > 9e5c353510b26500bd6b8309823ac9ef2837b761 > bcf090e0040e30f8409e6a535a01e6473afb096f > 501d52a90cbe652b41336c206ff0e95799d5a9b5 > 8e0948080670f6330229718b15a6a1a011d441ce > 60ae81eee86dd7a520db8c1e3d702b49fc0418b5 > 913dc33fb2720fb5f979011664294137ddd8b13b > 6b708de64adb6dc8319e7aeac922b46904fbeeec > 400ffaa2acd72274e2c7293a9724382383bebf3e > d83353b319d47ef8cce82467da6a25c2d558253f > bf0c55c986540483c34ca640f2eef4c3314388b1 > c9a78332b42cbdcdd386a95192a716b67d1711a4 > 2452cc89063a2a6890368f185c4b6d7d8802175b > 25abade29616d42d60f9bd5e6a5ad07f7314e39e > 5b25abade29616d42d60f9bd5e6a5ad07f7314e3 > 789d21dbd9d8889e62c79ec19585fcc97e42ef07 > 0781c8748cf1ea2b0dcd966571103909528c4efa > > (from oldest to newest). And that's just from 3.16 to 3.17-rc3, going > all the way back to 3.10 would be a lot of work. If there's anyone that > cares about bcache on stable kernels (and actually use it), now would be > a good time to pipe up. > Then if it's too much work, it just confirmed what was asked previously: bcache is still experimental so mark it such for stable kernels. I wouldn't have used bcache in that case. Thanks -- 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/lkml/
[GIT PULL] ACPI and power management fixes for 3.17-rc4
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm+acpi-3.17-rc4 to receive ACPI and power management fixes for v3.17-rc4 with top-most commit 9aa4e2f6ac2e5d0729f5982fd0b070123808381e Merge branches 'pm-sleep', 'powercap', 'pm-domains' and 'pm-cpufreq' on top of commit 69e273c0b0a3c337a521d083374c918dc52c666f Linux 3.17-rc3 These are regression fixes (ACPI sysfs, ACPI video, suspend test), ACPI cpuidle deadlock fix, missing runtime validation of ACPI _DSD output, a fix and a new CPU ID for the RAPL driver, new blacklist entry for the ACPI EC driver and a couple of trivial cleanups (intel_pstate and generic PM domains). Specifics: - Fix for recently broken test_suspend= command line argument (Rafael J Wysocki). - Fixes for regressions related to the ACPI video driver caused by switching the default to native backlight handling in 3.16 from Hans de Goede. - Fix for a sysfs attribute of ACPI device objects that returns stale values sometimes due to the fact that they are cached instead of executing the appropriate method (_SUN) every time (broken in 3.14). From Yasuaki Ishimatsu. - Fix for a deadlock between cpuidle_lock and cpu_hotplug.lock in the ACPI processor driver from Jiri Kosina. - Runtime output validation for the ACPI _DSD device configuration object missing from the support for it that has been introduced recently. From Mika Westerberg. - Fix for an unuseful and misleading RAPL (Running Average Power Limit) domain detection message in the RAPL driver from Jacob Pan. - New Intel Haswell CPU ID for the RAPL driver from Jason Baron. - New Clevo W350etq blacklist entry for the ACPI EC driver from Lan Tianyu. - Cleanups for the intel_pstate driver and the core generic PM domains code from Gabriele Mazzotta and Geert Uytterhoeven. Thanks! --- Gabriele Mazzotta (1): cpufreq: intel_pstate: Remove unneeded variable Geert Uytterhoeven (1): PM / domains: Make generic_pm_domain.name const Hans de Goede (3): ACPI / video: Fix use_native_backlight selection logic ACPI / video: Add a disable_native_backlight quirk ACPI / video: Disable native_backlight on HP ENVY 15 Notebook PC Jacob Pan (1): powercap / RAPL: change domain detection message Jason Baron (1): powercap / RAPL: add support for CPU model 0x3f Jiri Kosina (1): ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lock Lan Tianyu (1): ACPI / EC: Add msi quirk for Clevo W350etq Mika Westerberg (1): ACPICA: ACPI 5.1: Add support for runtime validation of _DSD package. Rafael J. Wysocki (1): PM / sleep: Fix test_suspend= command line option Yasuaki Ishimatsu (1): ACPI / scan: not cache _SUN value in struct acpi_device_pnp --- drivers/acpi/acpica/nsprepkg.c | 39 drivers/acpi/ec.c | 4 drivers/acpi/processor_idle.c | 4 ++-- drivers/acpi/scan.c| 15 +++--- drivers/acpi/video.c | 45 -- drivers/cpufreq/intel_pstate.c | 4 drivers/powercap/intel_rapl.c | 8 include/acpi/acpi_bus.h| 1 - include/linux/pm_domain.h | 2 +- kernel/power/power.h | 1 + kernel/power/suspend.c | 2 +- kernel/power/suspend_test.c| 31 ++--- 12 files changed, 122 insertions(+), 34 deletions(-) -- 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/lkml/
mm: invalid memory deref in page_get_anon_vma
Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel, I've stumbled on the following spew: [12191.987737] BUG: unable to handle kernel paging request at 88035615eca8 [12191.988865] IP: page_get_anon_vma (./arch/x86/include/asm/atomic.h:27 ./arch/x86/include/asm/atomic.h:197 include/linux/atomic.h:17 mm/rmap.c:417) [12191.990071] PGD 2ed4b067 PUD 9753bd067 PMD 97530c067 PTE 80035615e060 [12191.991578] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC [12191.991578] Dumping ftrace buffer: [12191.991578](ftrace buffer empty) [12191.991578] Modules linked in: [12191.991578] CPU: 5 PID: 3079 Comm: khugepaged Not tainted 3.17.0-rc3-next-20140903-sasha-00034-g33e7ae9 #1108 [12191.991578] task: 8802729f3000 ti: 880272b0c000 task.ti: 880272b0c000 [12191.991578] RIP: page_get_anon_vma (./arch/x86/include/asm/atomic.h:27 ./arch/x86/include/asm/atomic.h:197 include/linux/atomic.h:17 mm/rmap.c:417) [12191.991578] RSP: 0018:880272b0f7b8 EFLAGS: 00010246 [12191.991578] RAX: RBX: 88035615ec00 RCX: 0001 [12191.991578] RDX: 88035615ec01 RSI: a72e2182 RDI: a71ebfd4 [12191.991578] RBP: 880272b0f7d8 R08: 0001 R09: [12191.991578] R10: R11: R12: ea000a72aa40 [12191.991578] R13: 880272b0f8f8 R14: ea000a72aa40 R15: 0029cc00 [12191.991578] FS: () GS:8804c9e0() knlGS: [12192.020146] CS: 0010 DS: ES: CR0: 8005003b [12192.020146] CR2: 88035615eca8 CR3: 2c032000 CR4: 06a0 [12192.020146] Stack: [12192.020146] a72e2135 880272b0f8f8 ea000a72aa60 ea000d2b7780 [12192.020146] 880272b0f888 a730d27a 880272b0f7f8 8b880a00 [12192.020146] 8804c5e00340 8802729f3000 0001 [12192.020146] Call Trace: [12192.020146] ? page_get_anon_vma (mm/rmap.c:405) [12192.020146] migrate_pages (mm/migrate.c:853 mm/migrate.c:941 mm/migrate.c:1122) [12192.020146] ? __reset_isolation_suitable (mm/compaction.c:947) [12192.020146] ? isolate_freepages_block (mm/compaction.c:918) [12192.020146] compact_zone (mm/compaction.c:1209) [12192.020146] compact_zone_order (mm/compaction.c:1258) [12192.020146] try_to_compact_pages (mm/compaction.c:1323) [12192.020146] __alloc_pages_direct_compact (mm/page_alloc.c:2313) [12192.020146] __alloc_pages_slowpath (mm/page_alloc.c:2760) [12192.020146] __alloc_pages_nodemask (mm/page_alloc.c:2838) [12192.020146] ? collapse_huge_page.isra.31 (mm/huge_memory.c:766 mm/huge_memory.c:2336 mm/huge_memory.c:2435) [12192.020146] collapse_huge_page.isra.31 (mm/huge_memory.c:2336 mm/huge_memory.c:2435) [12192.020146] ? debug_smp_processor_id (lib/smp_processor_id.c:57) [12192.020146] ? put_lock_stats.isra.12 (./arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254) [12192.020146] ? khugepaged_scan_mm_slot (include/linux/spinlock.h:349 mm/huge_memory.c:2604 mm/huge_memory.c:2700) [12192.020146] ? preempt_count_sub (kernel/sched/core.c:2626) [12192.020146] khugepaged_scan_mm_slot (mm/huge_memory.c:2704) [12192.020146] khugepaged (include/linux/spinlock.h:349 mm/huge_memory.c:2784 mm/huge_memory.c:2817) [12192.020146] ? bit_waitqueue (kernel/sched/wait.c:291) [12192.020146] ? khugepaged_scan_mm_slot (mm/huge_memory.c:2810) [12192.020146] kthread (kernel/kthread.c:210) [12192.020146] ? kthread_create_on_node (kernel/kthread.c:176) [12192.020146] ret_from_fork (arch/x86/kernel/entry_64.S:348) [12192.020146] ? kthread_create_on_node (kernel/kthread.c:176) [12192.020146] Code: ee ff 0f 1f 00 49 8b 54 24 08 48 89 d0 83 e0 03 48 83 f8 01 0f 85 cb 00 00 00 41 8b 44 24 18 85 c0 0f 88 be 00 00 00 48 8d 5a ff <8b> 8b a8 00 00 00 85 c9 0f 84 ac 00 00 00 8d 71 01 89 c8 48 8d All code 0: ee out%al,(%dx) 1: ff 0f decl (%rdi) 3: 1f (bad) 4: 00 49 8badd%cl,-0x75(%rcx) 7: 54 push %rsp 8: 24 08 and$0x8,%al a: 48 89 d0mov%rdx,%rax d: 83 e0 03and$0x3,%eax 10: 48 83 f8 01 cmp$0x1,%rax 14: 0f 85 cb 00 00 00 jne0xe5 1a: 41 8b 44 24 18 mov0x18(%r12),%eax 1f: 85 c0 test %eax,%eax 21: 0f 88 be 00 00 00 js 0xe5 27: 48 8d 5a ff lea-0x1(%rdx),%rbx 2b:* 8b 8b a8 00 00 00 mov0xa8(%rbx),%ecx <-- trapping instruction 31: 85 c9 test %ecx,%ecx 33: 0f 84 ac 00 00 00 je 0xe5 39: 8d 71 01lea0x1(%rcx),%esi 3c: 89 c8 mov%ecx,%eax 3e: 48 8d 00lea(%rax),%rax Code starting with the faulting instruction
Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver
Hi Rob, On 02/09/14 18:38, Rob Herring wrote: > On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann wrote: >> On Tuesday 02 September 2014 08:20:53 Rob Herring wrote: > > This alone is not okay. There is no such implementation of hardware. But the SBSA explicitly allows this. I don't know of any vendor who just implements the subset, but I've been told that this has been asked for. >>> >>> To use baudrate as an example, that must be configurable somehow >>> either with pl011 registers or in a vendor specific way. I suppose you >>> could do an actual implementation with all those things hardcoded in >>> the design, but that seems unlikely. >> >> Why does the baudrate need to be configurable? I think it's completely >> reasonable to specify a console port that has a fixed (as in the >> OS must not care) rate, and that can be implemented either as a UART >> with a programmable rate or as a set of registers that directly talks >> to a remote system management device over whatever hardware protocol >> they choose. > > Sure. It is also completely reasonable that baudrate is configurable > and vendors can implement it however they choose since the SBSA does > not specify it. But this would be a different driver for a different hardware then and not covered by the SBSA version - so to some degree not our problem ;-) I don't see how we could really cover this problem for every possibly upcoming implementation. If I got the spec correctly, then exposing the baudrate setting for SBSA hardware is not meaningful in the sense of the spec. If you want to go with a configurable UART complying to the spec, you'd probably use a full featured PL011. > IIRC, the enabling and disabling bits are not > specified either. Correct, also the FIFO is always on and the word format is fixed to 8n1. Regards, Andre. > > Not having configurability is simply one variation on possible > implementations. > > Rob > -- 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/lkml/
[PATCHv3 4/4] clocksource: tcb_clksrc: sanitize IRQ request
The clock is not unprepared in case of the request IRQ fails.
Also update to request_irq.
Signed-off-by: Gaël PORTAY
Acked-by: Daniel Lezcano
Acked-by: Boris Brezillon
---
drivers/clocksource/tcb_clksrc.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index f922e81..8bdbc45 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -178,12 +178,6 @@ static irqreturn_t ch2_irq(int irq, void *handle)
return IRQ_NONE;
}
-static struct irqaction tc_irqaction = {
- .name = "tc_clkevt",
- .flags = IRQF_TIMER,
- .handler= ch2_irq,
-};
-
static int __init setup_clkevents(struct atmel_tc *tc, int clk32k_divisor_idx)
{
int ret;
@@ -198,15 +192,16 @@ static int __init setup_clkevents(struct atmel_tc *tc,
int clk32k_divisor_idx)
clkevt.regs = tc->regs;
clkevt.clk = t2_clk;
- tc_irqaction.dev_id =
timer_clock = clk32k_divisor_idx;
clkevt.clkevt.cpumask = cpumask_of(0);
- ret = setup_irq(irq, _irqaction);
- if (ret)
+ ret = request_irq(irq, ch2_irq, IRQF_TIMER, "tc_clkevt", );
+ if (ret) {
+ clk_disable_unprepare(t2_clk);
return ret;
+ }
clockevents_config_and_register(, 32768, 1, 0x);
--
1.9.3
--
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/lkml/
[PATCHv3 1/4] ARM: at91/tclib: prefer using of devm_* functions
Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
---
drivers/misc/atmel_tclib.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/atmel_tclib.c b/drivers/misc/atmel_tclib.c
index c8d8e38..b514a2d 100644
--- a/drivers/misc/atmel_tclib.c
+++ b/drivers/misc/atmel_tclib.c
@@ -150,17 +150,15 @@ static int __init tc_probe(struct platform_device *pdev)
if (irq < 0)
return -EINVAL;
- tc = kzalloc(sizeof(struct atmel_tc), GFP_KERNEL);
+ tc = devm_kzalloc(>dev, sizeof(struct atmel_tc), GFP_KERNEL);
if (!tc)
return -ENOMEM;
tc->pdev = pdev;
- clk = clk_get(>dev, "t0_clk");
- if (IS_ERR(clk)) {
- kfree(tc);
- return -EINVAL;
- }
+ clk = devm_clk_get(>dev, "t0_clk");
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
/* Now take SoC information if available */
if (pdev->dev.of_node) {
@@ -171,10 +169,10 @@ static int __init tc_probe(struct platform_device *pdev)
}
tc->clk[0] = clk;
- tc->clk[1] = clk_get(>dev, "t1_clk");
+ tc->clk[1] = devm_clk_get(>dev, "t1_clk");
if (IS_ERR(tc->clk[1]))
tc->clk[1] = clk;
- tc->clk[2] = clk_get(>dev, "t2_clk");
+ tc->clk[2] = devm_clk_get(>dev, "t2_clk");
if (IS_ERR(tc->clk[2]))
tc->clk[2] = clk;
--
1.9.3
--
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/lkml/
[PATCHv3 2/4] ARM: at91/tclib: move initialization from alloc to probe
Move resource retrieval from atmel_tc_alloc to tc_probe to avoid lately
reporting resource related issues when a TC block user request a TC block.
Moreover, resources retrieval are usually done in the probe function,
thus moving them add some consistency with other drivers.
Initialization is done once, ie not every time a tc block is requested.
If it fails, the device is not appended to the list of tc blocks.
Furhermore, the device id is retrieved at probe as well, avoiding parsing
DT every time the user requests of tc block.
Signed-off-by: Gaël PORTAY
Acked-by: Thierry Reding
Acked-by: Boris Brezillon
---
drivers/clocksource/tcb_clksrc.c | 2 +-
drivers/misc/atmel_tclib.c | 71 +---
drivers/pwm/pwm-atmel-tcb.c | 2 +-
include/linux/atmel_tc.h | 8 +++--
4 files changed, 29 insertions(+), 54 deletions(-)
diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index a8d7ea1..f922e81 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -279,7 +279,7 @@ static int __init tcb_clksrc_init(void)
int i;
int ret;
- tc = atmel_tc_alloc(CONFIG_ATMEL_TCB_CLKSRC_BLOCK, clksrc.name);
+ tc = atmel_tc_alloc(CONFIG_ATMEL_TCB_CLKSRC_BLOCK);
if (!tc) {
pr_debug("can't alloc TC for clocksource\n");
return -ENODEV;
diff --git a/drivers/misc/atmel_tclib.c b/drivers/misc/atmel_tclib.c
index b514a2d..d505d1e 100644
--- a/drivers/misc/atmel_tclib.c
+++ b/drivers/misc/atmel_tclib.c
@@ -35,60 +35,31 @@ static LIST_HEAD(tc_list);
/**
* atmel_tc_alloc - allocate a specified TC block
* @block: which block to allocate
- * @name: name to be associated with the iomem resource
*
* Caller allocates a block. If it is available, a pointer to a
* pre-initialized struct atmel_tc is returned. The caller can access
* the registers directly through the "regs" field.
*/
-struct atmel_tc *atmel_tc_alloc(unsigned block, const char *name)
+struct atmel_tc *atmel_tc_alloc(unsigned block)
{
struct atmel_tc *tc;
struct platform_device *pdev = NULL;
- struct resource *r;
- size_t size;
spin_lock(_list_lock);
list_for_each_entry(tc, _list, node) {
- if (tc->pdev->dev.of_node) {
- if (of_alias_get_id(tc->pdev->dev.of_node, "tcb")
- == block) {
- pdev = tc->pdev;
- break;
- }
- } else if (tc->pdev->id == block) {
+ if (tc->allocated)
+ continue;
+
+ if ((tc->pdev->dev.of_node && tc->id == block) ||
+ (tc->pdev->id == block)) {
pdev = tc->pdev;
+ tc->allocated = true;
break;
}
}
-
- if (!pdev || tc->iomem)
- goto fail;
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r)
- goto fail;
-
- size = resource_size(r);
- r = request_mem_region(r->start, size, name);
- if (!r)
- goto fail;
-
- tc->regs = ioremap(r->start, size);
- if (!tc->regs)
- goto fail_ioremap;
-
- tc->iomem = r;
-
-out:
spin_unlock(_list_lock);
- return tc;
-fail_ioremap:
- release_mem_region(r->start, size);
-fail:
- tc = NULL;
- goto out;
+ return pdev ? tc : NULL;
}
EXPORT_SYMBOL_GPL(atmel_tc_alloc);
@@ -96,19 +67,14 @@ EXPORT_SYMBOL_GPL(atmel_tc_alloc);
* atmel_tc_free - release a specified TC block
* @tc: Timer/counter block that was returned by atmel_tc_alloc()
*
- * This reverses the effect of atmel_tc_alloc(), unmapping the I/O
- * registers, invalidating the resource returned by that routine and
- * making the TC available to other drivers.
+ * This reverses the effect of atmel_tc_alloc(), invalidating the resource
+ * returned by that routine and making the TC available to other drivers.
*/
void atmel_tc_free(struct atmel_tc *tc)
{
spin_lock(_list_lock);
- if (tc->regs) {
- iounmap(tc->regs);
- release_mem_region(tc->iomem->start, resource_size(tc->iomem));
- tc->regs = NULL;
- tc->iomem = NULL;
- }
+ if (tc->allocated)
+ tc->allocated = false;
spin_unlock(_list_lock);
}
EXPORT_SYMBOL_GPL(atmel_tc_free);
@@ -142,9 +108,7 @@ static int __init tc_probe(struct platform_device *pdev)
struct atmel_tc *tc;
struct clk *clk;
int irq;
-
- if (!platform_get_resource(pdev, IORESOURCE_MEM, 0))
- return -EINVAL;
+ struct resource *r;
irq = platform_get_irq(pdev, 0);
if (irq < 0)
@@ -160,12 +124,21 @@ static int __init
Re: [GIT PULL] bcache changes for 3.17
On 09/05/2014 08:28 AM, Vasiliy Tolstov wrote: > 2014-09-05 18:17 GMT+04:00 Jens Axboe : >> >> We need to do something about this. From this latest pull, looks like >> all should go to stable: >> >> 5b1016e62f74c53e0330403025954c8d95384c03 >> 9aa61a992acceeec0d1de2cd99938421498659d5 >> dbd810ab678d262d3772d29b65844d7b20dc47bc >> 8b326d3a2a76912dfed2f0ab937d59fae9512ca2 >> e5112201c1285841f8b565ece5d6ae7e0d7947a2 >> a664d0f05a2ec02c8f042db536d84d15d6e19e81 >> c5aa4a3157b55bdca18dd2a9d9f43314470b6d32 >> 9e5c353510b26500bd6b8309823ac9ef2837b761 >> bcf090e0040e30f8409e6a535a01e6473afb096f >> 501d52a90cbe652b41336c206ff0e95799d5a9b5 >> 8e0948080670f6330229718b15a6a1a011d441ce >> 60ae81eee86dd7a520db8c1e3d702b49fc0418b5 >> 913dc33fb2720fb5f979011664294137ddd8b13b >> 6b708de64adb6dc8319e7aeac922b46904fbeeec >> 400ffaa2acd72274e2c7293a9724382383bebf3e >> d83353b319d47ef8cce82467da6a25c2d558253f >> bf0c55c986540483c34ca640f2eef4c3314388b1 >> c9a78332b42cbdcdd386a95192a716b67d1711a4 >> 2452cc89063a2a6890368f185c4b6d7d8802175b >> 25abade29616d42d60f9bd5e6a5ad07f7314e39e >> 5b25abade29616d42d60f9bd5e6a5ad07f7314e3 >> 789d21dbd9d8889e62c79ec19585fcc97e42ef07 >> 0781c8748cf1ea2b0dcd966571103909528c4efa >> >> (from oldest to newest). And that's just from 3.16 to 3.17-rc3, going >> all the way back to 3.10 would be a lot of work. If there's anyone that >> cares about bcache on stable kernels (and actually use it), now would be >> a good time to pipe up. > > > I'm interesting on backporting this to 3.14.y Before that can happen, you would probably need to comb the 3.15 and 3.16 bcache inclusions and dig out any potential stable candidates there too. -- Jens Axboe -- 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/lkml/
Re: [PATCH] pinctrl: single: fix freudian slip
Hi,
Linus Walleij wrote:
> commit 03e9f0cac5da6af85758276cb4624caf5911f2b9
> "pinctrl: clean up after enable refactoring"
> renamed the vtable callback .enable to .set_mux. The
> renaming was done manually, and one of the alterations
> contained a freudian slip. I confess, I am human.
>
> Signed-off-by: Linus Walleij
> ---
> drivers/pinctrl/pinctrl-single.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c
> b/drivers/pinctrl/pinctrl-single.c
> index 9032422ad18f..fb94b772ad62 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -519,7 +519,7 @@ static const struct pinmux_ops pcs_pinmux_ops = {
> .get_functions_count = pcs_get_functions_count,
> .get_function_name = pcs_get_function_name,
> .get_function_groups = pcs_get_function_groups,
> - .set_mux = pcs_sex_mux,
> + .set_mux = pcs_set_mux,
> .gpio_request_enable = pcs_request_gpio,
> };
>
Congrats, you passed the Turing test! ;)
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
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/lkml/
Re: [GIT PULL] bcache changes for 3.17
2014-09-05 18:17 GMT+04:00 Jens Axboe : > > We need to do something about this. From this latest pull, looks like > all should go to stable: > > 5b1016e62f74c53e0330403025954c8d95384c03 > 9aa61a992acceeec0d1de2cd99938421498659d5 > dbd810ab678d262d3772d29b65844d7b20dc47bc > 8b326d3a2a76912dfed2f0ab937d59fae9512ca2 > e5112201c1285841f8b565ece5d6ae7e0d7947a2 > a664d0f05a2ec02c8f042db536d84d15d6e19e81 > c5aa4a3157b55bdca18dd2a9d9f43314470b6d32 > 9e5c353510b26500bd6b8309823ac9ef2837b761 > bcf090e0040e30f8409e6a535a01e6473afb096f > 501d52a90cbe652b41336c206ff0e95799d5a9b5 > 8e0948080670f6330229718b15a6a1a011d441ce > 60ae81eee86dd7a520db8c1e3d702b49fc0418b5 > 913dc33fb2720fb5f979011664294137ddd8b13b > 6b708de64adb6dc8319e7aeac922b46904fbeeec > 400ffaa2acd72274e2c7293a9724382383bebf3e > d83353b319d47ef8cce82467da6a25c2d558253f > bf0c55c986540483c34ca640f2eef4c3314388b1 > c9a78332b42cbdcdd386a95192a716b67d1711a4 > 2452cc89063a2a6890368f185c4b6d7d8802175b > 25abade29616d42d60f9bd5e6a5ad07f7314e39e > 5b25abade29616d42d60f9bd5e6a5ad07f7314e3 > 789d21dbd9d8889e62c79ec19585fcc97e42ef07 > 0781c8748cf1ea2b0dcd966571103909528c4efa > > (from oldest to newest). And that's just from 3.16 to 3.17-rc3, going > all the way back to 3.10 would be a lot of work. If there's anyone that > cares about bcache on stable kernels (and actually use it), now would be > a good time to pipe up. I'm interesting on backporting this to 3.14.y -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- 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/lkml/
Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver
On 02/09/14 20:34, Arnd Bergmann wrote: > On Tuesday 02 September 2014 12:38:23 Rob Herring wrote: >> On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann wrote: >>> On Tuesday 02 September 2014 08:20:53 Rob Herring wrote: >> >> This alone is not okay. There is no such implementation of hardware. > > But the SBSA explicitly allows this. I don't know of any vendor who just > implements the subset, but I've been told that this has been asked for. To use baudrate as an example, that must be configurable somehow either with pl011 registers or in a vendor specific way. I suppose you could do an actual implementation with all those things hardcoded in the design, but that seems unlikely. >>> >>> Why does the baudrate need to be configurable? I think it's completely >>> reasonable to specify a console port that has a fixed (as in the >>> OS must not care) rate, and that can be implemented either as a UART >>> with a programmable rate or as a set of registers that directly talks >>> to a remote system management device over whatever hardware protocol >>> they choose. >> >> Sure. It is also completely reasonable that baudrate is configurable >> and vendors can implement it however they choose since the SBSA does >> not specify it. IIRC, the enabling and disabling bits are not >> specified either. >> >> Not having configurability is simply one variation on possible >> implementations. > > It's not obvious to me though that we are served better by a > pl011 driver that allows any possible subset of the features, > rather than having the existing driver for pl011, and a new driver > for the sbsa subset, which then won't allow any of the optional > features. > > Yes, there is some duplication, but a driver for this kind of > dumb console port should be doable in very little code, at > least less than the proposed implementation. I see your point, but as long as this means to introduce another serial prefix I would rather avoid it. As said in the other mail, I think the integration into PL011 does not look too bad, so we can discuss again this when I post the code later. Cheers, Andre. -- 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/lkml/
Re: [PATCH v3] ARM: dts: qcom: Add initial IFC6540 board device tree
Hi,
Am 03.09.2014 18:50, schrieb Georgi Djakov:
> Add basic support for the IFC6540 single-board computer boards, that are
> based on the APQ8084 SoC. This patch adds the initial device tree and the
> neccessary nodes required for enabling the serial port and eMMC.
>
> Signed-off-by: Georgi Djakov
> ---
> Changes since v2:
> - Squashed all patches into one. (suggested by Kumar Gala)
>
> Changes since v1:
> - This time add linux-arm-msm list to the CC.
> - Include a third patch for enabling the eMMC.
>
> arch/arm/boot/dts/Makefile |1 +
> arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 23 +++
> arch/arm/boot/dts/qcom-apq8084.dtsi| 23 +++
> 3 files changed, 47 insertions(+)
> create mode 100644 arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b022972..df8453a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -345,6 +345,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
> dtb-$(CONFIG_ARCH_QCOM) += \
> qcom-apq8064-ifc6410.dtb \
> qcom-apq8074-dragonboard.dtb \
> + qcom-apq8084-ifc6540.dtb \
> qcom-apq8084-mtp.dtb \
> qcom-msm8660-surf.dtb \
> qcom-msm8960-cdp.dtb
> diff --git a/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
> b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
> new file mode 100644
> index 000..c9ff108
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-apq8084-ifc6540.dts
> @@ -0,0 +1,23 @@
> +#include "qcom-apq8084.dtsi"
> +
> +/ {
> + model = "Qualcomm APQ8084/IFC6540";
> + compatible = "qcom,apq8084-ifc6540", "qcom,apq8084";
> +
> + soc {
> + serial@f995e000 {
> + status = "okay";
> + };
> +
> + sdhci@f9824900 {
> + bus-width = <8>;
> + non-removable;
> + status = "okay";
> + };
> +
> + sdhci@f98a4900 {
> + cd-gpios = < 122 GPIO_ACTIVE_LOW>;
> + bus-width = <4>;
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
> b/arch/arm/boot/dts/qcom-apq8084.dtsi
> index 21d01e5..1f130bc 100644
> --- a/arch/arm/boot/dts/qcom-apq8084.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
> @@ -3,6 +3,7 @@
> #include "skeleton.dtsi"
>
> #include
> +#include
>
> / {
> model = "Qualcomm APQ 8084";
> @@ -203,5 +204,27 @@
> clock-names = "core", "iface";
> status = "disabled";
> };
> +
> + sdhci@f9824900 {
> + compatible = "qcom,sdhci-msm-v4";
> + reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
> + reg-names = "hc_mem", "core_mem";
> + interrupts = <0 123 0>, <0 138 0>;
I see that you've used GPIO_ACTIVE_* above. Is the trailing zero here
possibly IRQ_TYPE_NONE?
> + interrupt-names = "hc_irq", "pwr_irq";
> + clocks = < GCC_SDCC1_APPS_CLK>, <
> GCC_SDCC1_AHB_CLK>;
> + clock-names = "core", "iface";
> + status = "disabled";
> + };
> +
> + sdhci@f98a4900 {
> + compatible = "qcom,sdhci-msm-v4";
> + reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
> + reg-names = "hc_mem", "core_mem";
> + interrupts = <0 125 0>, <0 221 0>;
> + interrupt-names = "hc_irq", "pwr_irq";
> + clocks = < GCC_SDCC2_APPS_CLK>, <
> GCC_SDCC2_AHB_CLK>;
> + clock-names = "core", "iface";
> + status = "disabled";
> + };
If you assign labels to these two nodes, you can reference them in the
.dts as {...};. Same for the uart node. That avoids
duplicating the hierarchy, detects spelling mistakes at compile time and
reduces indentation. Cf. the recent ifc6410 patch.
Also, is sdhci the best node name here? Usually it's not supposed to
reflect the exact interface used (e.g., usb vs. ehci).
> };
> };
Otherwise looks good.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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/lkml/
Re: [PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family
Hi Arnd, [...] > A common pattern these days is to do dependencies like > > arch/*/Kconfig: > config ARCH_FOO > bool "Enable support for Foo platform" > help > ... > > > drivers/*/Kconfig > config SUBSYS_FOO > bool "SUBSYS driver for Foo" > depends on ARCH_FOO || COMPILE_TEST > depends on OF && REGULATOR && GENERIC_PHY # or whatever Russell's comments w.r.t. Kconfig warnings when config names change still holds regardless of select vs depends on. > That way we can enable everything in the defconfig, but someone > who likes to build a more specialized kernel can disable the > other platforms and won't get the drivers that are specific to > those. > > I personally think this is a bit more verbose than what we need, but > I don't strongly object doing it that way. You'd still be able to do this without ARCH_FOO, though you would need to know which drivers are necessary for a particular SoC. That seems to be the way things are handled on x86; I don't recall having to select support for specific machines there, just the individual drivers. > The code size really should not matter much on ARM64 though: it's > unlikely we will see a lot of systems with less than a few gigabytes > of memory, and I expect that a generic kernel would be e.g. 6 MB > instead of 4 MB for a platform specific kernel. Agreed. If there kernel size begins looking unwieldy we either need to be compiling more things as modules or a more drastic kernel weight loss program. Mark. -- 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/lkml/
[PATCHv3 0/4] ARM: at91/tclib: fix segmentation fault
Hi every one, This set of patches fix a segmentation fault happening when kexec-ing kernel on an at91 platform (see backtrace below). While the previous kernel shuts down, the tcb_clksrc driver leaves its interruptions unmasked. When the new kernel initiliazes any tclib making use of a TC block, an interruption may happen before the interrupt handler is set, causing a kernel segmentation fault. To prevent from such cases from happening, the last patch sets up the shutdown callback which masks interruptions when the machine is shutdown. Furthermore, it also masks the interruptions at probe to make sure no interruption happens before the handler is set. This will prevent freshly kexec-ed kernel from crashing when launched from a kernel which does not properly mask interruptions at shutdown. Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 8005 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0+ #144 task: c1828aa0 ti: c182a000 task.ti: c182a000 PC is at 0x0 LR is at ch2_irq+0x28/0x30 pc : [<>]lr : []psr: 00d3 sp : c182bd38 ip : c182bd48 fp : c182bd44 r10: c0373390 r9 : c1825b00 r8 : 6053 r7 : r6 : r5 : 0013 r4 : c036e800 r3 : r2 : 2004 r1 : c036e760 r0 : c036e760 Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 20004000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc182a1c0) Stack: (0xc182bd38 to 0xc182c000) bd20: c182bd7c c182bd48 bd40: c0045430 c01db8ec c18c6f40 c182bd74 c1825b00 c035cec4 bd60: c182be2c 6053 c1825b34 c182bd94 c182bd80 c0045570 c0045408 bd80: c1825b00 c182bdac c182bd98 c0047f34 c0045550 0013 c036619c bda0: c182bdc4 c182bdb0 c0044da4 c0047e98 007f 0013 c182bde4 c182bdc8 bdc0: c0009e34 c0044d8c fefff000 c0046728 6053 c182bdf4 c182bde8 bde0: c00086a8 c0009ddc c182be74 c182bdf8 c000cb80 c0008674 0013 be00: 00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34 be20: c182be74 c182be20 c182be40 c0047994 c0046728 6053 be40: 0013 c036e800 c182be64 c1825b00 0013 c036e800 c035ed98 c03874bc be60: 0004 c036e700 c182be94 c182be78 c004689c c0046398 c036e760 c18c6080 be80: c035ed10 c182bedc c182be98 c0348b08 c004684c 000c c034dac8 bea0: 004c4b3f c028c338 c036e760 0013 c014ecc8 c18e67e0 c035b9c0 c0348884 bec0: c035b9c0 c182a020 c182bf54 c182bee0 c00089fc c0348894 bee0: c00da51c c1ffcc78 c182bf0c c182bef8 c002d100 c002d09c c1ffcc78 bf00: c182bf54 c182bf10 c002d308 c0336570 c182bf3c c0334e44 0003 0003 bf20: 0030 c0334b44 c0044d74 0003 0003 c034dac8 c0350a94 c0373440 bf40: c0373440 0030 c182bf94 c182bf58 c0336d24 c000890c 0003 0003 bf60: c0336560 c182bf64 c182bf64 6e616e0d c0272fc8 bf80: c182bfac c182bf98 c0272fd8 c0336bd8 c182a000 bfa0: c182bfb0 c00095d0 c0272fd8 bfc0: bfe0: 0013 374d27cd 33cc33e4 Backtrace: [] (ch2_irq) from [] (handle_irq_event_percpu+0x38/0x148) [] (handle_irq_event_percpu) from [] (handle_irq_event+0x30/0x40) r10: r9:c1825b34 r8:6053 r7:c182be2c r6: r5:c035cec4 r4:c1825b00 [] (handle_irq_event) from [] (handle_fasteoi_irq+0xac/0x11c) r4:c1825b00 r3: [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x28/0x38) r5:c036619c r4:0013 [] (generic_handle_irq) from [] (handle_IRQ+0x68/0x88) r4:0013 r3:007f [] (handle_IRQ) from [] (at91_aic_handle_irq+0x44/0x4c) r6: r5:6053 r4:c0046728 r3:fefff000 [] (at91_aic_handle_irq) from [] (__irq_svc+0x40/0x4c) Exception stack(0xc182bdf8 to 0xc182be40) bde0: 0013 be00: 00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34 be20: c182be74 c182be20 c182be40 c0047994 c0046728 6053 [] (__setup_irq) from [] (setup_irq+0x60/0x8c) r10:c036e700 r9:0004 r8:c03874bc r7:c035ed98 r6:c036e800 r5:0013 r4:c1825b00 [] (setup_irq) from [] (tcb_clksrc_init+0x284/0x31c) r6:c035ed10 r5: r4:c18c6080 r3:c036e760 [] (tcb_clksrc_init) from [] (do_one_initcall+0x100/0x1b4) r10: r9: r8:c182a020 r7:c035b9c0 r6:c0348884 r5:c035b9c0 r4:c18e67e0 [] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x224) r9:0030 r8:c0373440 r7:c0373440 r6:c0350a94 r5:c034dac8 r4:0003 [] (kernel_init_freeable) from [] (kernel_init+0x10/0xec) r9: r8: r7: r6: r5:c0272fc8 r4: [] (kernel_init) from [] (ret_from_fork+0x14/0x24)
